{希哲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月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月18日の副日記}{迫られなかった}{目の前のこと}{多い方が良い}{取り戻せる}{触れなかった}{よく弄っていた}{反省した}{希哲17年1月18日}{軽視していた}...=}(58)

{希哲17年1月18日の開発 K#F85E/E74C-404E}

{希哲17年1月19日の開発}{希哲17年1月19日の進捗}{希哲17年1月19日}{時間をかけてしまった}{確認出来た}{過去の自分}{置き換えられた}{これほど}{再評価し始めた}{そんなもの}...=}(253)

{希哲17年1月19日14歩 K#F85E/E74C-3191}

進捗時限記録中略

highlight.js版存更新終了

10.6.0 からスクリプト最新版11.7.0 へ,Zenburn装体書最終版10.7.3上げた出振るい手定め済み

希哲15年7月18日10歩更新検討したが,当時対応言語検証必要判断し見送り,以来そのままだった。約2年前版存なので,流石に対応言語云々より弊害の方が大きいだろうと更新決めた

作業自体あっという間に終わる見込んで昨日深夜着手したが,最新版従来の Zenburn事実上消えていたため,カラーテーマ検討時間を取られてしまった散々考えた結果Zenburn最終版利用して現状維持とすることにした。

カラーテーマ検討

最新版Zenburnstyles/zenburn.min.css から styles/base16/zenburn.min.css移動していた上に,従来とはほとんど別物になっていた様子Base16 になったからなのか事情よく分からないが,読みにく過ぎるのでいずれにせよ使い物にならない

気になる部分装体上書きして調整出来なくもないが,そこまでするならデライト独自カラーテーマ作りたくなってくる取り急ぎ代替テーマ探すことにした。highlight.js 導入時それなりに時間をかけ検討した希哲15年3月9日11歩ので,当時の記憶からある程度見当付いた

読み込み中...
=}
{ぽんと}{寄りかかる}{何十倍}{自分の年齢}{自分の仕事}{揺らがなくなった}{成長した}{必死に}{目をやる}{一年間}...=}(74)

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

{}{希哲17年1月20日}{輪郭整備}{ロングパス}{思ってしまった}{デザイン要素}{方針を決める}{全力疾走}{視野が広がった}{冷やされてきた}...=}(111)

{希哲17年1月16日の日記 K#F85E/E74C-0180}

少し作業方針見直し,実作業また捗り出したここから新生デライトの完成向けて加速させたい。

ひょんなことから組計整理進んだ

まずは新生デライトの「成立」し,デライト3周年までの完全な成功目指すというのが現行方針だったが,6日頃からの脳爆発新生デライト開発一変し,気付けば「成立」「完成」大差ない距離感になっている。

「完成」遠さから生み出した現行方針であることを考えると,もう無理にデライト3周年意識すべきではないのかもしれない。例えばには良い結果出せるように,2月中の「完成」目指す,というのも良いかもしれない考え始めた

とりあえず中旬このまま全力疾走し,20日までには方針を決めることにした。


これから作業だという昼頃トイレ用を足して立ち上がったら,ウォシュレットかけられてしまった誤操作なのか誤作動なのか分からないほど考え事ぼんやりしていた

まさにひょんなこと」かつ初めての経験面食らい,水道水とはいえ気持ち悪いので,射雨を浴び洗濯したり周辺掃除したりしているうちに,最近の脳爆発過熱止まらなかった少し冷やされてきた

読み込み中...
{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{二輪鎖}{希哲17年1月15日}{こうなったら}{縮小する}{計算した}{応用出来た}{詰め込める}{余地が無い}...=}(168)

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

進捗時限記録中略

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

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


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

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

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

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

読み込み中...
{考える}

{}