{開発}{開発記録}{十分}{悪い意味}{希哲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分もあれば十分だろうという実装コストの低さにもかかわらずいまいち気が乗らなかった

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

読み込み中...
{進捗記録}{進捗}{希哲16年6月16日}{}{第二次知番改良}{希哲16年6月16日の開発}{希哲16年6月16日の進捗}{優先すべき}{柔軟に}{有効な場面}(80)

{希哲16年6月16日5歩 K#F85E/E74C-2C3A}

進捗時限記録中略

KNEST 隠しについての実装作業方針検討終了

第二次知番改良での交度出場整理経てKNEST 隠し実装イメージ急速にまとまってきた

まず,輪数隠しについては「輪数取得改良」として出場設計見直し含めた包括的な実装方針出来ている

課題だった共通の出与え構造については,任意隠し出与え更新時印持たせた map_ と,更新時印として本体set_持たせた map_基礎とすることを決めた。これで古い隠しから削除していくような処理簡単に実装出来る

探索効率保存効率単純性柔軟性兼ね備えた実装なかなか見つからなかったが,これで解決した昨年4月12日10歩から,「浮上式隠し」として独自の出与え構造考えていたものの,それも課題多く再考せざるをえなくなっていた。

昨年9月から最優先実装することを考えていた HTML 隠しについてはいったん後回しにすることにした。公開設定機能など,自我によってページ内容大きく変わる機能実装間近控えているテンプレート保存するにしても,有効な場面限られる柔軟に利用出来る輪数隠し自我隠し輪郭隠し優先すべきだろう。

{開発}{開発記録}{方向}{希哲16年5月30日}{高さ制限}{内容の高さ}{機能的に}{混乱させない}{用者層}{利用率}(93)

{希哲16年5月30日の開発 K#F85E/E74C-DB91}

自動ページ展開機能実装一段落した細部に課題はあるが,実用出来る水準に達した出振るい手定め済み

これに伴い正式離立前試していた全知検索窓新規描出フォームの固定表示復活させる検討大きく進んだ。また,輪郭一覧動的追加仕組み整えたことで,検索新規描出時にも応用出来るようになった。輪郭一覧の更新効率的に行えるようになり,高速化にも大きく貢献するだろう。


AutoPagerize 対応どうするかというのが難しい問題だったが,これは挿入監視して削除注意書き表示する方向落ち着いた最初以外 .autopagerize_page_elementdisplay: none設定しておくことで表示には影響しない

AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者使っているのを見て私自身使うようになったというのもあり,用者層重なり小さくない出来るだけ混乱させないようにしたかった。


今後広告の調整重要になってくるため,ここで運営者開発者向けダミー広告表示する仕組み整えたダミー広告の様子

AdSense は,設置者によるクリックもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた


機能的に自動ページ展開機能似たところがある描写後略機能実装方針検討ほぼ完了

内容の高さ高さ制限足りない場合どうするか最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した


{実装方針検討}

{}