{『希哲日記』}{希哲17年}{日記}{輪郭整備}{サービス}{希哲17年3月}{希哲17年1月}{進捗}{デライトの完全な成功}{KNS}(155)

{希哲17年3月18日の日記 K#F85E/E74C-1C1B}

開発作業しっかり進めつつ少し気持ちの整理をした。

今月入ったあたりから,ぼんやり考え事をしてしまう時間増え進捗そこまで悪くないものの,思うように集中力高まらなかった上手く言い表せないが,「迫り来る何か」に揺さぶられている感覚ずっとある

まず考えられる原因は,1月脳爆発反動疲労だ。1月だけで半年分仕事はしてしまった感があるその後雑務上手く片付いた解放感手伝ってちょっと気が抜けてしまったのかもしれない。そういう意味では,必要な休息でもあったのだろう。

もう一つは,新生デライト開発における「マラソン終盤効果」とでもいうべき心理だ。1月脳爆発以降予定になかった当努多数挿入してしまったとはいえ,それを差し引いても新生デライトの完成遠く感じるここ数ヶ月だけでも明らかに多くのこと実現しているのに,もう少しだという意識が高まれば高まるほど残り当努重く感じる

加えて,「デライトの完全な成功」が意味するものの微妙ながら小さくない変化がある。イーロン・マスクによる Twitter 買収以降SNS 戦国時代で,デライト一気に大舞台引っ張り出されてしまった。

ほとんどの競合が「次の SNS」に留まる中,KNS として「SNS の次」のビジョン明確に提示出来る世界で唯一サービスデライトだ。それを世の中伝えることが出来れば世界一の大富豪制し世界情勢をも左右するネット文化大革新果せる

希哲館事業長年目指してきたことが,ここ数ヶ月ほどのあいだに急速に目前に迫ってきている昨年の日記にも似たようなこと書いているが,その時の「デライトの完全な成功」と「世界史上最大の成功」が定義上の,やや観念的結び付きだったのに比べて,今のそれはずっと生々しい世俗的な現実感伴っているいまデライトの完全な成功果すことと,世界中注目を集めること,莫大な利益得ることが直結しているからだ。これも当努同じで,もう少しだと思えば思うほど時間長く感じる


この難しい状況平常心保つために,とりあえず目の前当努輪郭整備極力強く意識することにした。考えても疲れるだけのことは考えないようにする。

今年入ってから新生デライトの完成への意識が高まったこともあり輪郭整備ほとんど時間を割けなかった今日開発作業合間ちょこちょこ輪郭整備をしてみたが,やはり精神衛生上効果大きい感じた

19日振り返り日記

{開発記録}{一段落}{十分}{}{前後}{デライト}{対応出来る}{希哲17年1月25日の副日記}{多大な効果}{表示速度向上}(402)

{希哲17年1月25日の開発 K#F85E/E74C-7E8A}

23日の開発から急速に進展したデライト高速化一段落した

テーマ切り替えボタン用合い検討4歩新規描出フォームへの移動機能として吹き描き外背景ダブルクリック用合い復活10歩全知検索ページャー周りの調整16歩こまごまとした領当て装体調整17歩といった雑多ながら充実した作業片付けついに描写後略機能一段落させた21歩出振るい手定め済み

描写後略機能により,デライト最初期から吹き描き構造的問題だった「不必要な出与え読み込み多さ」という問題解消した表示速度向上通信量削減SEO 強化迷惑行為対策など多大な効果見込める

デライト高速化現状今後

昨年末の壊衝不具合修正以後デライト速度安定性ともにウェブ相振りとして十分な水準達していたが,今回の高速化経て明らかにもう一つ壁を越えた感がある体感として,「ウェブ相振りなら特に不満のない速さ」から「単動相振り比べても遜色のない速さ」になった。

一昨年4月9日掲げた全ページ0.3秒以内表示」という目標埋め込み利素考えると現実的ではない気がしてきたものの,軽いページでは200ms台重いページでも概ね300ms台応答出来るようになっている。実感として欲しかった速度手に入れられたし,最適化余地まだまだ残しているので「埋め込み利素除いてほぼ全てページ0.3秒以内表示」なら十分手が届くいよいよ本格的に速さデライトの武器になってきた。

ここで新生デライト開発におけるデライト高速化一段落とし,今後機能追加トラフィック応じた微調整留め別の機能整備集中することにした。

その先デライト高速化については,大きなところでは CDN 導入KNEST による水平拡大請い手隠し機能整備描写 HTML 隠し以外HTML 隠し実装,そして中途半端な状態放置しているページ付け求頼改良があるが,どれも現時点での優先順位低い

読み込み中...
{進捗記録}{波括弧}{進捗}{デライト}{希哲17年1月22日の開発}{希哲17年1月22日の進捗}{希哲17年1月22日}{似た形態}{似た機能}{錆びついている}(119)

{希哲17年1月22日7歩 K#F85E/E74C-DD27}

進捗時限記録中略

デラング整備化学記法見直し終了

現時点ではやはり \ce( ... \)\ce[ ... \]最も無難な記法であると結論付けた


昨日直感的にこの記法思いついたが,実際に使ってみると,閉じ括弧前の \忘れやすいという問題気付いた慣れの問題もあるので欠点結論付けるのは早いが,数式記法\( ... \)比べて \ce( ... \)括弧対応関係直感的に認識しにくいというのはありそうだ。

TeX では \ce{ ... }数式模動内側書く必要無いため,いっそのこと,これだけでもいいのではないかと思った

しかし,これだと化学記法というよりは TeX 風記法mhchem使っているように見えてしまうTeX ではバックスラッシュ波括弧多用されるからこれが自然に見えるだけで,デライトでこれがぽつんとあっても違和感が大きい特に波括弧デライトにおいて特別な記号なので,濫用避けたいいずれにせよ行内別行立て書き分け出来ず書き分けせずに文脈挙動変えれば TeX 的でもなくなるので,良い案ではなかった。

似た機能似た形態に」という言語設計原則立ち返ると,やはり化学記法数式記法似ているべきだろう。

では,閉じ括弧前のバックスラッシュ省略可にするかと考えたが,これは実装上の問題大きい入れ子になりうる閉じ記号処理出来なくはない一気に面倒になる。しかも,化学記法でそれをすると数式記法でもしないと整合的ではなくなる。現時点化学記法使い勝手のためにそこまでの実装コスト払う意義見出せない

読み込み中...
{開発記録}{十分}{悪い意味}{希哲17年1月20日の副日記}{概念的に}{両記法}{とらわれない}{態勢に入っていた}{理解しやすくする}{増やせる}(164)

{希哲17年1月20日の開発 K#F85E/E74C-D455}

全知検索演算子についての検討1歩交度埋め込み記法実装方針検討数式記法含めた概念整理5歩知名デラング対応方針についての検討7歩交度記法対応言語スクリプト動的に追加する方法についての検討12歩など,検討作業よく捗った

実作業も,交度写し取りボタン実装13歩16歩交度埋め込み記法調整などそこそこ捗ったが,特に大きかったのは,交度埋め込み記法数式記法概念整理出来たことだった。

交度埋め込み記法数式記法概念整理

交度埋め込み記法では,対応言語texlatexkatex追加したこれまで katex のみを追加するつもりだったが,意図の明示という観点から使い分けられる方が望ましい例えばKaTeX という実装こだわらず LaTeX書きたいということは十分に考えられる

また,これまで数式記法KaTeX 交度埋め込み記法糖衣構文程度考えていたが,ここで「数式のための TeX 風記法」と位置付け直すことにした。これにより,例えば mhchem などの数式以外応用交度埋め込み記法使うといった使い分け可能になる


Mermaid 対応以後交度埋め込み記法KaTeX対応する機会を窺っていた。これは同記法考案した時点考えていたこと希哲16年2月15日18歩で,いずれ対応するつもりではあったが,30分もあれば十分だろうという実装コストの低さにもかかわらずいまいち気が乗らなかった

数式記法糖衣構文として再定義する,それ以上意義見出せなかった整合性という大義名分はあったが,悪い意味での冗長性加えるような感覚もあり,なんとなくぼんやりしたすっきりしないものを感じていた

読み込み中...
{開発記録}{}{サービス}{デライト}{デライトはoEmbedに対応している?}{描写下見機能}{希哲17年1月16日の副日記}{この手の}{埋め込み献典}{検討しておく}(243)

{希哲17年1月16日の開発 K#F85E/E74C-6ADB}

作業方針検討4歩閲覧専用模動実装検討5歩デラング整備埋め込み記法処理改良8歩13歩

埋め込み記法処理改良

これまで埋め込み記法処理の中でも oEmbed利用したものについては,Dex 内で埋め込み交度取得直接描写 HTML埋め込んで返していたが,埋め込み交度取得処理専用 API /mbd委ね前縁 Aejs から利用することにした。結果として応答速度改善成功した

埋め込み記法+[URL]URLoEmbed必要とする場合Dex では適当な分類名付与した <div>出与え属性URL埋め込んで描写 HTML返すAejs ではそれを検知し,URL/mbd転送する/mbdURL対応したサービス埋め込み交度oEmbed取得して返す,という流れになる。過剰な立求抑止するため,Aejs には簡易的な隠し持たせておいた

想像していたよりすっきり実装出来た


そもそもきっかけは,先日の SlideShare 対応だった。oEmbed必要になったので,埋め込みツイート使っていた Dex 内の oEmbed 埋め込み方法取り急ぎ使った。ただ,記法処理範枠同期通信処理組み込むというのは正気の沙汰ではないなんでこんな実装になっているのか,引っかかりはあった。

KNEST 隠し使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状そこまで最適化する必要時間も無い出来たとして,隠し有効利用出来る握接パターン限られているいずれにせよこの種の埋め込み記法利用増えてくれば破綻目に見えている。ということで,いったん埋め込み処理前縁移すことにした。

読み込み中...
{進捗記録}{}{右下}{}{進捗}{デライト}{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{二輪鎖}{希哲17年1月15日}(168)

{希哲17年1月15日18歩 K#F85E/E74C-2F5F}

進捗時限記録中略

全知検索窓固定機能吊るし輪郭への輪結新規描出フォームへの輪結加えるアイデアについてまとめ終了

画像素材は,背景用二輪鎖上矢印アイコンといずれも既存のものを使い,自我アイコン左側配置する幅狭領当てでは,入力欄への捕活時隠れ入力欄伸長するようにする開発者通類で作った案


新規描出フォームへの素早い握接長いあいだ課題だったが,これも急に解決してしまった新規描出フォーム固定機能との関連考えることがく,今回先の検討中に考え始めた

右下あたりに輪結固定させるのがよくある方式だが,何度考えてもデザイン的まとまり欠ける何より幅狭領当てでは重なり気になる明らかに邪魔だろう。

新規描出フォーム左上にある+ボタン元々新規描出フォーム固定機能兼ねていたので,これをスクロール追随させて,どこでも新規描出フォーム呼び出せるようにするか……等々これまでとにかくあらゆる検討したが,どのにも何かしら問題があったさっき方針固まった全知検索窓固定機能合わせ下スクロール現れるバーにしても,せっかく占有領域減らす工夫相殺されてしまう。

デライト構造上仕方ないこと,と新規描出フォーム固定機能のように諦めかけたが,こうなったらもう全知検索窓何とか利用するしかないのではないか,と再び考え出したのが良かった

読み込み中...
{一気に}

{}