希哲館事業は,5月から“長期安定体制”への転換を始め,この7月で新体制を完成させた。
長期安定体制の完成は,「デライトの完全な成功」を果すため質・量ともに十分な時間を確保出来たということを意味する。この体制で,デライトの改良,コンテンツ整備,宣伝はもちろん,希哲館事業全体にかかわる環境整備,私自身の生活の質改善など,あらゆる要素の改善をじっくり,バランス良く進めていきたい。
サービス開発・運営の経験を積んでみてつくづく思うのは,サービスは生き物だということだ。複製されたスタンドアローン型のソフトウェアと違って,サービスは常に生きていなければならない。健全で活力あるサービスは健全で活力ある人間にしか維持出来ない。私はデライトを名実ともに世界最高のサービスとして成功させたいので,私自身がそれに見合う人間でなければならないと思っている。
何より,ここまでデライト開発を成功させ,この SNS 戦国時代 に KNS という唯一無二の構想を持って立っている奇跡にお腹いっぱいだ。宝くじを何百回と当てては宝くじに注ぎ込むような綱渡りをしてきたが,すでに得たものが大き過ぎて,それを賭けるに値する博打もなくなってきた。流石にそろそろ堅実に生きるべきではないか。そんな心境の変化と,この期に及んで安定を取り戻す選択肢があった幸運ぶりを象徴する出来事になりそうだ。
SVG スプライトの手法を取り入れ,SVG アイコンの定義は icn.svg
に集約することにした。
SVG 出与えも Aejs に組み込んで直接挿入してしまうことを考えていたが,舞覧隠しの適切な分離が出来なくなる,要素の再利用に必要な id
属性が使いにくい,といった問題があった。外部 SVG を <use>
で利用すれば Shadow DOM になるので,id 属性の衝突などを気にせず要素を整理しやすくなる。
スプライト画像として background-image
で利用しやすいというのも大きい。:target
とフラグメント識別子を利用して表示要素を変化させる技術があることを知ったが,舞覧によっては効率的に隠し出来ないことがあるらしく,今回は見送った。<view>
が使えればいいが,Safari の対応に難がある。当面は古典的な座標指定で行くことにした。
アイコン制作では,アイコンを並べて全体のばら成しを見ながら調整することが多いため,見本を兼ねられるのも便利だ。
SVG スプライトだけで十分かもしれないと思いかけたが,<use>
1つでも若干冗長な上に,1つのアイコンの要素を細かく制御したい場合に <use>
が複数必要になるため,やはりスクリプトでの補完は欲しい。
添付譜類はあくまでも添え物として最小限の役割に留め,エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。
元々添付譜類は添え物として設計しているが,実際に譜類添付機能が出来,エクスポート機能を実装しようとしてみると,実質的な役割の落とし所が意外に難しい。意図に反して,変に使われ過ぎるのも問題だ。
エクスポート機能では,とりあえずは代替 HTML などで済ませ,ゆとりが出来たら実譜類にも対応するか,などと考えていた。そもそも,どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし,そこまで神経質な人が手元に抜控を持っていないということも考えにくいので,実はさほど必要性の高い付徴ではない。とはいえ,エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから,将来的に対応しないというほどの動機もない。
しかし,添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え,それに伴い譜類保全の責任が増せば,将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様,ここは割り切った用者文化を育てていくべきだろう。
これに気付いてみて,最近,添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが,これも最小限に留めることにした。拡張子制限は制危面もあるが,献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める(例えば .bmp
をそのまま上信して欲しくはない)。
デライトの強みは,知番による意味符号化で文字献典の情報密度を極限まで高め,その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降,その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら,どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。
描出公開原則のように何かこの方針に名前を付けたくなったが,「譜類添付機能」という名前で趣旨は表現出来ているので,それに立ち返るということで十分だろう。