{開発}{開発記録}{}{サービス}{デライト}{デライトは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月7日の開発}{つながっていた}(189)

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

無理をしない書いたそばから,調子が良い通り越して過熱気味で,また寝るのが遅くなってしまった

開発では輪郭選り手改良熱中し,輪郭整備またお預けとなった。ただ,描出効率大きな向上見込める改良となり,今後輪郭整備考えればむしろ良かったきっかけ昨日の開発での不具合修正で,これも怪我の功名だった。

輪郭選り手改良意識が向いたのは,最近執筆環境としてのデライトへの期待が高まっていたからかもしれない。もちろんデライト文書整備念頭にある


デライトの完全な成功までの「最後の壁」だと思っていたものを突破しては次の壁ぶつかるということを繰り返してきたので,“その時”が来るまで,結局何が最後の壁」なのかは分からないだろう。

用者大きく増えないままデライト進歩し,洗練されるたびに不思議な感覚覚えてきたこんなに凄いものこんなに少人数使っていることに,罪悪感近いものを覚える隠しているわけでもないのに独占しているみたいだ。事実デライトほど構想的技術的高度で,高品質で,なおかつ無名なサービス他に無いだろう。

現在のデライト俯瞰した時,明らかに欠けている大きな部分もはや一つしかない。それが“文書”だ。

正式離立から適当な状態のまま,ほとんど手を入れていないデライト文書整備遅らせてきたことには,修正回数最小限抑えるという戦略的な理由があった。実際ここまでのデライト急激な変化いちいち文書追随させていたら,デライト開発自体がここまでの速さ進んでいないだろう。第二次快調期第四次宣伝攻勢経て安定感出てきた一番効率的効果的に文書整備進められる時期なのは間違いない

読み込み中...
{間違いない}

{}