吹き描き外背景のダブルクリック/ダブルタップで新規描出フォームに移動出来るようにして終了。出振るい・手定め済み。
デライト最初期,新規描出フォーム固定機能で試していた(希哲13年8月1日4歩)用合いだったが,自分でも驚くほど忘れていた。固定機能の削除以後,何度か再活用を検討した記憶はあるが,今ほど全体的な用合いの方向性が定まっていなかったからか放置していた。新規描出フォームへの握接について先日あれだけ検討していたのに全く思い出さなかった。ついさっきふと思い出した。灯台下暗しというやつか。
初見で分かりやすい用合いも必要なので全知検索窓固定機能の輪結も予定通り実装するが,スマートフォン右手持ちではタップしにくい位置だとは思っていた。個人機でもマウスカーソルの移動距離は短くない。しかし,これならよくある固定表示ボタンよりよほど賢い。上手い補完手段が出来た。
現状の幅狭領当てでは吹き描き外背景が小さ過ぎて誤タップしやすいが,これは縦方向の吹き描き間マージンを調整していくことにした。
新たに,強調記法,文字装飾記法,小書き記法,化学記法に対応した。
デラング周りの作業はここで一段落とし,別の作業に入る。デラング関連で次の主要当努は9日の検討通りタグ記法整備の見通し。
知名デラングの拡充については,知名の役割を誤解させかねないという懸念から消極的にすべきかもしれないと考えていたが,20日7歩で極力拡充していく方針を決めた。
実用性の観点でいえば,やはり最短知名原則が有用で,知名に情報を詰め込んだり装飾したりということは推奨出来ない。ただ,間口を広げることを考えなければならない今のデライトには遊びも必要だろう。
デラングを学び始めた人が知名にデラングを使いたくなるのは自然なことであり,そこから学べることもある。知名の役割については,分かりやすい文書を整えることが本筋だ。
手定め中,知名で強調記法を使うと中景輪符の強調部分の文字サイズが大きくなることに気付いた。
<h1>
以下の <strong>
に font-size: 120%
が設定してあることが原因だった。意図は忘れたが,何かの目的でこんな細工をしたような記憶はうっすらある。
直そうかと思ったが,ちょっと面白い効果でもあるので,いったん置いておき仕様化するか検討することにした。見出しで太字や強調を使う意味は無いだろうと思っていたが,意外と表現方法はあるものだと過去の自分と偶然に気付かされた。
主にデラング整備,デラング関連スクリプト読み込み改良。出振るい・手定めを終え一段落した(20歩)。交度整理が大きく進み,想定外の体感速度向上も得られた。
最近,応答速度の向上ばかりに気を取られ前縁高速化を軽視していたことを反省した。
その他,開発環境整備(11歩,12歩),Aejs 不具合修正(14歩)など。
開発環境整備では,久しぶりに knu-mode
の調整をした。希哲13年頃まではよく弄っていたが,デライト開発が本格化してからは目の前のことに精一杯でろくに触れなかった。知機駒手整備ほど必要にも迫られなかった。
今なら辛うじて記憶を取り戻せるし,十分な経験の蓄積も出来ているので,定期的に調整していくことにした。時間対効果は考える必要があるが,新生デライトの完成に向けて開発を加速させるために選択肢は多い方が良い。
作業方針検討(4歩),閲覧専用模動実装検討(5歩),デラング整備・埋め込み記法処理改良(8歩〜13歩)。
これまで,埋め込み記法処理の中でも oEmbed を利用したものについては,Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが,埋め込み交度の取得処理を専用 API /mbd
に委ね,前縁 Aejs から利用することにした。結果として,応答速度改善に成功した。
埋め込み記法(+[URL]
)の URL が oEmbed を必要とする場合,Dex では適当な分類名を付与した <div>
に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し,URL を /mbd
に転送する。/mbd
は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す,という流れになる。過剰な立求を抑止するため,Aejs には簡易的な隠しも持たせておいた。
そもそものきっかけは,先日の SlideShare 対応だった。oEmbed が必要になったので,埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ,記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか,引っかかりはあった。
KNEST 隠しを使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
9日の SlideShare 対応後,意外にもすぐに若干の応答速度低下を感じるようになり,作業の優先順位が上がった。スライドの埋め込み自体はデライト公式での紹介輪郭でしか使われておらず,因果関係は不明だったものの,時期があまりにも一致していた。Google のクロール統計でも,9日以後はそれ以前と比べて100ms以上の平均応答時間増加が連日見られ,体感とも一致していた。
ざっと Aejs で oEmbed を利用する交度を書いて実行してみると,CORS の違了が発生し,一気に記憶が蘇ってきた。
元々前縁でやろうとしていたのを,CORS 問題が面倒で後縁完結にしたのだった。よほど高尚な理由がないとこの実装はありえないだろうと深読みしていたが,なるほど,単なる一時凌ぎという線があった。当時の記録も残っていた。
仕方ないので,当時面倒臭がってやらなかった専用 API を作ることにし,/mbd
を追加した。Aejs には埋め込み記法処理を集約する @mbd
を追加した。
中継サービスを利用するのが一番簡単な方法だが,信頼性や使い勝手などで不確実性が高い。
出振るい後,すぐに明らかな体感速度向上が見られた。もう少し様子見は必要だが,見込みは正しかったか。だとしても,応答速度低下の原因ははっきりしていない。原因究明にかけられる時間も無い。
一つの輪郭中の一つの oEmbed 通信がサービス全体の応答速度低下を招いたとは考えにくい。考えられるとすれば,握接集中で立求処理が詰まった,あたりか。SlideShare 対応によって気付かない内に何らかの問題を持ち込み,埋め込み記法処理改良によって解消したか,全く別の問題が偶然同時期に発生していただけ,という可能性もなくはない。
いずれにせよ,今回の埋め込み記法処理改良によってデライトの安定性・効率性が大きく向上したのは間違いない。従来の方式では,ページ内で oEmbed を利用する回数×通信時間の応答速度低下があった上に,描写 HTML のタグ削除をしている RSS でも無駄な通信が発生していた。
これは方式によらず発生しうる問題だが,下見機能などで頻繁に更新する場合,その都度 oEmbed 通信が発生していたことに気付き,@mbd
に客体変数を使った隠しを持たせておいた。役割分担が進んだことで今後はこうした最適化もやりやすくなる。/mbd
に隠しを持たせることも検討しておくことにした。
少し懸念していたのが埋め込み献典の描画速度だったが,これも全く気にならなかった。そもそもこの手の埋め込み献典の描画は遅いものなので,多少の変化では分からない。