{終わってみれば}{従ってきた}{増え始める}{残してある}{集客面}{一段落させた}{希哲16年6月30日}{第二次知番改良}{出場整理}{見ながら}...=}(69)

{希哲16年6月30日の日記 K#F85E/E74C-5CF8}

{デライト}{OFFSET}{減らせる}{付けたかった}{ts_upd}{利用しやすくなった}{実装しておいた}{一覧部分}{整備した}{隠し効率}...=}(210)

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

デライト高速化における KNEST 隠し実装一段落した。18日作業方針検討のみで20日から,休日除いてちょうど10日間での達成だった。出振るい済み

全体としては大成功だった。

必要以上に固め過ぎるのも良くないため,隠し化現時点最低限必要範囲留めたが,期待以上安定性期待通り高速化得られた次の施策出来たので,まだまだ高速化出来るKNEST 隠しDex匹敵するデライト武器になるだろう。

交度整理しっかり進めたこともあり最初の輪数取得改良想定以上に長引いたものの,ここで KNEST 隠し共通の問題ほとんど解決したため,自我隠し輪郭隠し半日ほどで終わった。この交度整理収穫として大きかった輪郭操作系の kn の外充て函数整備したことで関連交度一気に整理された

影響範囲確率的に大きな問題はないだろうと見て排他制御甘い部分あえて残して出振るい急いだが,出振るい直後壊衝多発して少し焦ったすぐに論軸的問題気付修正し,その後むしろ想定以上に安定して動いている。この判断結果として正解だった。

輪数取得改良

輪数隠しに関しては,第二次知番改良中に固まった輪数取得改良」として,輪数取得仕組み全体的に改良した

これまでデルンではいちいち厳密な輪数表示をしていたが,これが大きな低速化要因になっていた。デライト以前まで,count()遅さ対する認識が甘かったデライト以後そもそも出場における件数計算原理的に遅いもの,と気付いてページ付けOFFSET上限設けるなどの対策はしていた希哲13年10月14日の開発記録が,輪数一筋縄ではいかない部分があり放置してきた

厳密な同期必要性隠し効率から,次のように整理することにした。

この通りに実装終え上手く動いている

また,この過程で各輪郭操作での輪数更新必要になったため,ほとんど未実装だった輪郭操作系の外充て函数整備した

自我隠し輪郭隠しから次の施策

自我隠しに関しては昨年4月中途半端な実装をしていたため,これを整理した輪郭隠しは,現時点一覧部分には適用出来ないものの一応実装しておいた

自我隠し出来たことで自我情報利用しやすくなったため,自我アイコンts_upd使った隠し破り付けたかったが,自我情報取得部分がまだ非効率なので見送った

輪郭情報求頼分割し過ぎているので,これを統合することを考えているうちに,次の施策まとまった

輪郭一覧については,まず知番のみで中景輪取得し,輪郭隠し照合してから三景輪郭情報同時に取得することにした。これで輪郭隠し効率的に利用出来求頼大幅に減らせる予定していた検索属性もここで盛り込む

{完成の域に達した}{表記的}{写し取りたい}{共有目的}{貼り付けたい}{外部媒体}{適当な時期}{整理中}{省略された}{写し取り時}...=}(145)

{希哲16年6月17日の開発 K#F85E/E74C-9EA6}

自我知番省略機能実装終え第二次知番改良完了とした20歩ここでやっておこう思ったのも,途中で第零番節の削除転換したのもあまりにだったが,その割には終始円滑にり,収穫想定はるかに越えて多大だった。全体として大成功言っていいだろう。

第二次知番改良経て知番表記的にも内部的にも完成の域に達した。あとは仕様実装微調整繰り返していく

まず,当初の目的だった知番の簡略化言うまでもなく大きいこれまで一般のデライト用者最短でも K#9-XXXX/A-YYYY という15文字知番輪郭扱う必要があった。それが第零番節の削除によって11文字K#XXXX/YYYY になり,自我知番の省略によって7文字K#/YYYY になった。知番表記仕様に関しては理想的な形だ。

第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度出場整理劇的に進んだ。これにより,効率性保守性大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫繋がった未実装だった自動知番拡張もここで実装出来た今のところ第二番節しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。

波及効果想定以上に大きかった出場見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮見込めるようになった特に見通しが悪い課題だった KNEST 隠し出与え構造がこの期間固まり,一気に実装可能性高まった自我知番省略機能Dex との連携必要になったことで,他の記法でも活かせる出与え共有機構整った。これが無番輪符改良などにも繋がっている

将来的に長い知番増えた時のための「知番略記法」を中心とした第三次知番改良方針固まった。この長年の課題にも解決の見通しが立った。

一つ見送ったこともある。自我知番省略された知番写し取り時自我知番付け自輪郭描写欄などへの貼り付け時自我知番の省略をする4月8日の開発記録,というのは,やはり用合いとしては理想的盛り込みたかったが,今回見送った。このあたりの事象Aejs整理中なので,どうしても場当たり的交度になってしまう。他輪郭素出から写し取りたい時や,外部媒体厳密な知番貼り付けたいという時には便利だが,現時点必要としている人少ない共有目的なら共有ボタンがある。交度整理しながら適当な時期実装することにした。

{用者}{希哲16年4月28日の進捗}{気を取り直す}{頭に入っていた}{外して}{書き上げた}{引っかかった}{執筆効率}{起こった}{連続多量握接}...=}(61)

{希哲16年4月28日20歩 K#F85E/E74C-4FDB}

{HTML}{::after}{文字サイズ}{進捗記録}{目立ってしまう}{制御しにくい}{double}{果した}{調整余地}{font-weight}...=}(121)

{希哲16年2月6日12歩 K#F85E/E74C-06F4}

デライト装体調整終了

見分けにくかった見出し装体視認性大きく向上した修正前修正後

見出し装体固定化

まず,これまで中景輪符<h1>始まる<h2> で始まる前後景輪一覧かで描写内見出し装体1階層ずつずれていたが,これはいったん固定することにした。

ずれるのも HTML文書構造からみれば間違った表現ではなく,中景輪符表現も少し変えるべきかと考えていたが,これもなかなか難しい中景輪符知名部は,現状 <h1> でも <h2> でも font-size: 1.4emfont-weight: boldletter-spacing: 0.05em という装体になっている。輪郭という情報単位粒度考えた時,これ以下は小さ過ぎ,これ以上は大き過ぎという所だ。

他の要素も,要素同士の対比考えて細かく装体調整しているため,それらまで見出し装体変化合わせる保守性悪影響を及ぼす。将来的にどうかはともかく,現時点でそこまでする利点は無いだろう。

CSS では h1 ~ .dln h2, h2 ~ .dln h3 のように兄弟結合子使えば簡単に実装出来る。

装体調整

あくまでも描写内での見出し階層装体固定することにした上で,第1階層から第4階層までの描写内見出しには二本線一本線破線点線4種類下線を付けることにした。これまでは第1階層2px第2階層1px一本下線のみだった。

二本線border-styledouble では制御しにくいため ::after使い,1px2px間隔をあけた。また,点線舞覧によって破線より目立ってしまう場合があるため,調整することにした。

最初は,第1階層二本線第2階層一本線があれば十分かと思ったが,結局文字サイズだけの変化ではぱっと見分かりにくい。各描写内見出し図形的特徴があった方が良い。

文字サイズは,これまで 1.3em1.2em1.1em1.05em1em だったのを 1.3em1.2em1.15em1.1em1.05em とした。

1.3em から 1.1em まで0.05em刻みの方が数字的には綺麗かと思ったが,下線特徴を付けても,特に第1階層第2階層一見して見分けにくかった画面撮り。それ以下は使用頻度も低いので0.05em刻みでも大きな問題はないだろう。

letter-spacingfont-weight調整余地はもう少しありそうだが,視認性改善という目的十二分果したのでここで一段落とした。

2px一本線よりも1px二本線の方がすっきりした印象になるのが意外だった。

{rgx_T}{s_T の補助函数}{進捗記録}{幸いした}{書き換え作業}{置換作業}{必要な時期}{置換した}{冗長版}{置換する}...=}(69)

{希哲16年1月28日16歩 K#F85E/E74C-C804}

進捗時限記録中略

Cμ 文字列処理改良rgx_T の置換道手の引数順序変更

作業方針再検討終了

あとは rgx_T::rpl()引数順序変更rgx_T の置換道手の引数順序変更完了だが,これまでの道手呼び出し箇所Dexごく一部限られていたのに対し,.rpl()Cμ 初期からあちこち使っている置換道手なので,少し複雑な作業になる。

まず,いったん .rpl()適当な名前変えて無効化し,呼び出し箇所引数順序変更済みの .rpl_glb() あるいは客体表現置換するか,正規表現客体表現使うまでもない処理なら s_T の補助函数置換する現時点.rpl_glb().rpl()冗長版に過ぎないため,置換したままにしておいて問題ない交度整理をしていけば自然に戻るはずなので,あえて再置換はしないことにした。

置換作業に入る前に,作業必要s_T の補助函数整備必要だが,既存の「類型化正規表現rgx_x_T置換道手旧式引数順序にならっているため,まず最初に客体表現ojx_x_Tへの書き換え作業済ませることにした。rgx_T直接使った交度から類型化正規表現への書き換え作業想定より遅滞していたことが幸いして,現時点類型化正規表現多くない

いずれにせよ正規表現総点検客体表現への書き換え必要な時期であり,保守性効率性大きな向上見込める良い機会だ。

=}
{現時点}

{}