{希哲17年1月28日の開発}{希哲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日}{良いばら成し}{排除した}{詰まり過ぎていた}{ボタン類}{自分向け}{渡りに船}{差を付ける}...=}(206)

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

進捗時限記録中略

輪郭ページ改良装体調整終了

取り急ぎテンプレート整理して輪郭ページ吊るし輪郭入れていた要素<header> から <main> へ,輪郭ページ輪郭一覧<main> から <div>切り替えた前後景一覧ページでは従来通り

特に急ぎたかった部分上手く片付き残る内部的な問題のみなので,輪郭ページ改良ここで中断することにした。


閲覧専用模動実験をしていた時,輪郭ページ輪郭一覧隠す<header> だけのページになってしまうことに気付いたのが事の発端だった15日14歩

あまり意識してこなかったが,輪郭ページ概念実装大きな不一致生じていた一時凌ぎつもり後景一覧ページ輪郭ページ使うようにしたのはデライト離立補完中の希哲14年8月5日だった。当時とでは輪郭ページ捉え方輪郭充実度全く違う

予てから検索模動輪郭模動内部的な切り分け中途半端なまま進んでいない問題もあったため,抜本的な輪郭ページ改良方針まとめた17日8歩

最近の検索演心そこまで神経質ではないと言っても,<header><main>違い流石に小さくないだろう。何より気付いてしまう表現として気持ち悪いので早く解決したかった

読み込み中...
=}
{希哲17年1月22日の開発}{希哲17年1月22日の進捗}{希哲17年1月22日}{似た形態}{似た機能}{錆びついている}{煩雑過ぎた}{勉強していた}{引装した}{TeXworks}...=}(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分もあれば十分だろうという実装コストの低さにもかかわらずいまいち気が乗らなかった

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

読み込み中...
{希哲17年1月21日の開発}{希哲17年1月21日の進捗}{希哲17年1月21日}{仕様化}{設定してある}{font-size: 120%}{<strong>}{強調部分}{分かりやすい文書}{学び始めた人}...=}(106)

{希哲17年1月21日16歩 K#F85E/E74C-E642}

進捗時限記録中略

知名デラング調整関連交度整理終了

新たに強調記法文字装飾記法小書き記法化学記法対応した

いったん全て出振るい手定め済み

デラング周り作業はここで一段落とし,別の作業入るデラング関連次の主要当努9日の検討通りタグ記法整備見通し


知名デラング拡充については,知名の役割誤解させかねないという懸念から消極的にすべきかもしれないと考えていたが,20日7歩極力拡充していく方針決めた

実用性観点でいえば,やはり最短知名原則有用で,知名情報詰め込んだり装飾したりということは推奨出来ない。ただ,間口を広げることを考えなければならない今のデライトには遊び必要だろう。

デラング学び始めた人知名デラング使いたくなるのは自然なことであり,そこから学べることもある。知名の役割については,分かりやすい文書整えることが本筋だ。


手定め中知名強調記法使う中景輪符強調部分文字サイズ大きくなることに気付いた

<h1> 以下の <strong>font-size: 120%設定してあることが原因だった。意図忘れたが,何かの目的でこんな細工をしたような記憶うっすらある。

直そうかと思ったが,ちょっと面白い効果でもあるので,いったん置いておき仕様化するか検討することにした。見出し太字強調使う意味無いだろうと思っていたが,意外と表現方法はあるものだと過去の自分偶然気付かされた

=}
{気付いた}

{}