{進捗記録}{}{}{}{知名}{過去}{描写}{進捗}{希哲17年1月28日の開発}{希哲17年1月28日の進捗}(158)

{希哲17年1月28日21歩 K#F85E/E74C-46A3}

進捗時限記録中略

また新生デライトの要件ではあるが,ついさっき急に実装イメージまとまってしまった輪郭複製機能実装終了出振るい手定め済み

描写欄状態新規描出フォームで,自輪郭輪符知名欄貼り付けるドロップすると輪符から知名描写複写される

複写成功する「複写完了」表示「複写失敗:自分の輪郭ではありません」「複写失敗:描写が空ではありません」違了表示付け自我知番の省略にも対応済み使い勝手非常に良好

これまで通り輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが,眠気考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが,「輪郭複製のための機能」という意味ではそこまで間違っていない


輪郭複製機能については,昨年5月18日の開発で「知名描写複製して新規描出フォーム移動するボタン」として実装することを考えたが,その後用合い改良経て抵抗感募っていた

輪郭直接複製するような機能やはり避けたい手軽し過ぎる誤操作濫用可能性高まる適切な手間というで,新規描出フォームへの複写というアイデア悪くなかった。ただ,現状の輪郭選り手理想的にまとまっているので,極力ボタンのような要素追加したくない思うようになった

さっきふと,「知名欄への輪符貼り付け」というについて考えていたら,これが急速にまとまってしまった過去にも何度か脳裏をよぎっただが,その時いまいち気乗りしなかった

貼り付け方式最初の懸念誤入力だった。復元ボタンだけでは心許ないので,知名であることを条件にしようとしたが,空の知名書き始めることは少なくないので中途半端だ。複製したい輪郭検索してから写し取り貼り付けという流れ考えると,知名欄いちいち空にしなければならないのは煩雑過ぎる

間もなく描写欄という条件なら全く問題ないことに気付いた誤操作懸念なくなったので,ドラッグ&ドロップにも対応することにした。

もう一つ自輪郭のみという制限付けることにした。描写内自我知番の省略Aejs対応するのが難しいという問題もあるが,濫用され著作権上手溢れ増えることが予想される他人の描写扱い慎重に,という意味でもこれくらい適切だろう。

こうしてするする実装イメージまとまり一通りの機能付けた実装難なく完了した余計な視覚要素追加せず,それでいて直感的という,理想的な輪郭複製機能あっという間に出来てしまった

{開発}{開発記録}{一段落}{十分}{}{前後}{デライト}{対応出来る}{希哲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 的でもなくなるので,良い案ではなかった。

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

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

読み込み中...
{開発}{開発記録}{}{サービス}{デライト}{デライトは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 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状そこまで最適化する必要時間も無い出来たとして,隠し有効利用出来る握接パターン限られているいずれにせよこの種の埋め込み記法利用増えてくれば破綻目に見えている。ということで,いったん埋め込み処理前縁移すことにした。

読み込み中...
{進捗記録}{進捗}{希哲15年12月30日の開発}{いちいち}{希哲15年12月30日の進捗時限}{希哲15年12月30日の進捗}{希哲15年12月30日}{o}{kn opn}{kn shot}(29)

{希哲15年12月30日13歩 K#F85E/E74C-7801}

kn shotkn capt使い勝手調整して終了

いちいち譜類名を付けるのが面倒なことが多いため,無指定の場合は shot.[日時].pngcapt.[日時].gif形式自動保存することにした。日時date +'%Y%m%d_%H%M%S' としておいた。

更に保存先出力するようにし,kn opno標準入力対応shot | ocapt | o とするだけで確認しながら画面撮りしていけるようになった。

{使い勝手}

{}