{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{`Aejs_DG_rev`}{長期的視野に立って}{更新方法}...=}(224)

{希哲16年5月23日の開発 K#F85E/A-E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

=}
{希哲16年4月5日の開発}{希哲16年4月5日の進捗}{CSS 変数}{生み出した}{伝証}{合理化した}{呼ぶべき}{汚い現実}{ウェブの理想と現実}{もたらされる}...=}(208)

{希哲16年4月5日14歩 K#F85E/A-E74C-6431}

CSS 変数(カスタムプロパティ)の導入舞覧ブラウザ五年対応原則採用決め終了今後デライトでは,「5年以内離立された版存主要舞覧」を中心に対応していく

希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義考えてはいたが,当時は,古い舞覧対応努力はするが推奨はしない程度の,もっと緩やかなものを想定していた


希哲13年ECMAScript 2015HTML5CSS3比較的新しいウェブ標準導入決めてからだいぶモダンにはなったが,まだデライトの舞覧対応方針には感覚的保守的なところがあった。感覚的に影響範囲の広い付徴主要舞覧対応から10年影響範囲の狭い付徴5年目安導入考えていたrem ですら必要以上には使わなかった

先日前次記法実装グリッド領当て導入したが,これはちょうど主要舞覧使えるようになってから5年ほど経つ機能だった。一記法装体過ぎなかったこともあり,ここまで辛うじて良かったが,他にも色々応用したいことが出てき舞覧対応方針見直し必要を感じていた

決め手は,デライトのダークテーマ対応見据えて CSS 変数の導入考え始めたことだった。CSS 変数主要舞覧対応から5年ほど経つが,本格的に導入するとなると影響範囲広がり過ぎる


Can I use対応舞覧よく調べるようになってから,「5年以内離立された版存主要舞覧」が意外に普及していることに気付いた大体90%以上はある。

地域にもよるだろうが,確かに今時古い舞覧使い続ける方が難しいかもしれない。個人機なら5年平均的な買い替え周期であり,スマートフォンなら古い部類だろう。自動更新標準的になった昔と違って多数派の“普通の人”ほど新しい舞覧使っている

あえて古い舞覧使い続ける場合というと,一昔前なら古い個人機再利用というのがあったが,格安インターネット端末普通に流通している今,新しい舞覧使えないほど古い端末使い続ける費用対効果疑わしく,制危考えれば推奨出来ることではない

一番面倒なのが舞覧の更新許されない企業内利用だが,そもそもそんな保守的な環境デライト利用出来るとは考えにくい

こう考えていくと,デライトにとって古い舞覧への対応重要性極めて低い言わざるをえない

奇しくも新生デライトの完成目指している6月15日に,IE11 のサポート終了がある。中途半端気もする内容だが,いわゆるモダンではない舞覧最後の砦崩壊する新しいウェブ標準への社会的移行象徴的な出来事にはなる。


ある程度古い舞覧への対応考慮してきたのは,企業体力がついた将来対応拡充することを考えていたからだったが,これもよく考えると合理性怪しい

技術的負債”は簡単に返せるものではない。大企業肥大化した交度にいかに苦しめられているかを考えれば合理的に古い舞覧への対応出来る来るかどうかも分からないむしろ組織大きくなった時にこそ見通しの良さ重要になる


もっと根本的なこと言えばデライトウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準普及牽引していくくらいの考えがなくてはいけない。

その伝証デモ足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。


舞覧五年対応原則導入によって,ウェブの理想と現実における汚い現実大部分だった古い舞覧正しく切り捨てることが出来るようになり,前縁整備はもちろん,デライト文書整備でも大きな効率化もたらされるだろう。文書整備では,対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明すっきりする

デライト開発劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則デライト正式離立という大きな節目目前にして生み出したものだった。


=}
{出振るい}{Aejs 整備}{第四次宣伝攻勢}{省けた}{小さくなかった}{設計面}{第四次生活習慣改善の再開}{暖かくなってきた}{大事を取っていた}{生活習慣の乱れ}...=}(156)

{希哲16年3月15日の日記 K#F85E/A-E74C-4AA3}

12日脳爆発引きずってまだ脳疲労感残っていた一ヶ月分にも相当するであろう収穫だったのだから仕方ないと,気分転換兼ねて半年ほど放置していた Aejs 整備再開してみることにした。

まずは交度見直し軽く違了修正程度出来ればいい始めたものの,驚くべきことに,作業の続きよく捗った。これだけ間があくと,作業方針思い出すのと再整理時間がかかるのではないかと思っていたが,むしろ中断前より捗った気がする。この半年間での環境整備設計方針洗練知見の蓄積がそれだけ大きかったのだろう。当時は,ゆとりがなく混沌とした状況でもあった。

金風中断してからなかなか再開出来ず中途半端な状態出振るい出来ず前縁周り作業非常に進めにくい状況ではあったが,この間の収穫考えれば仕方ない思っていた設計面仕様面での変化小さくなかったので,再修正手間省けた唯一懸念だった作業再開にかかる負担全くと言っていいほど無かったのだから,仕方ないどころか大正解だったと言うべきだろう。

Aejs 整備中断経緯について記録振り返っている内に,もう一つの放置課題だった KNEST 隠し実装についても再整理急速に進んだ

輪郭選り手抜控機能整備がなかなか進まなかったことで Aejs 整備入ったのが昨年9月9日だった。14日11歩最後にそれも止まり,代わりに HTML 隠し実装からの KNEST 隠し実装重点を移すことにした。頭の整理をしているうちに18日になり,金風起きた以後は何度か再開試みている継続出来ず,そのまま第二次快調期突入した。

金風があまりに大きい出来事だったので,このあたりで記憶分断されている感覚ずっとあった特に Aejs 整備KNEST 隠し実装は,第二次快調期でも置き去りになっていた部分心残りだった。第四次宣伝攻勢向けて新生デライト開発佳境というところで二つ強力な武器上手く取り戻せた言うまでもなく極めて大きな収穫だ。

ただ,結局どっちを向いても脳爆発で,脳疲労癒えなかった


今日疲労回復のため休みにしたが,次回陶練からランニング再開することにした。

これも第二次快調期からほとんど出来なくなっていた忙しさもあったが,生活習慣の乱れ寒さ重なり,1月には風邪を引いたりもしていたため,大事を取っていた最近は少しずつ生活習慣改善再開出来,暖かくなってきたので大丈夫だろう。

最近の生活習慣改善を「第四次生活習慣改善」とするかと考えたところで,すでに金風以後生活習慣改善して使っていたことを思い出した用語として考えた12月9日から間もなく第二次快調期入ったので,目まぐるしさ忘れていたのだろう。とりあえず第四次生活習慣改善の再開」としておくことにした。


16日振り返り日記

{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{積極的な活用}{完成した}{編み出した}{面白いこと}{どちらも}{出来ていなかった}{付加的}{避けられない}...=}(143)

{希哲16年3月12日14歩 K#F85E/A-E74C-2A34}

進捗時限記録中略

今後の Dex 設計方針についての検討終了これから越化参照大活躍しそうだ。


まず,課題だった脚注記法実装方針について検討している内に,越化参照部区間通信活用出来ることに気付いた

部区毎に越化条件変化などがあることから,各記法解釈部区個体任せたい。しかし,脚注記法のように最上位部区との出与え共有必要記法もある。

このような場合単純に考えれば指示体通して部区個体間で変数共有するということになるが,この種の記法増えるたびに目的別指示体増やすのは設計として美しくない汎用的な変数一つ集約するのも,効率性厳密性観点から難がある

ここでふと,越化参照使えることに気付いた下位部区個体中途解釈した記法には目印となる越化参照を付け,上位部区個体変換処理完了させる

これに似た部区間通信手法Dex 初期実装から現 &_skp;使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲広げなかった紆余曲折を経て,これが一番単純性効率性保守性バランスが良いということが分かった

これで脚注記法目次記法実装容易になった。他にも,輪郭情報参照必要記法など,部区間通信必要場面全般越化参照活用出来るだろう。


もう一つ,処理済み対象識別に関しても進展があった。

1月21日4歩で,&_tgt;&_fin; のような目印付加することを考えていたが,付加的越化参照では結局正規表現の複雑化避けられないため,実用化出来ていなかった

昨日終えた客体表現への書き換えDex 初期実装交度整理している時,再置換避けるため記法一部越化参照当時の疑似実体参照置換する手法使っていたことを思い出した。これもあまり積極的に応用範囲広げなかった手法だが,思っていたより合理的であることに気付いた

例えばhttp&_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが,灯台下暗しのごとく単純なこと真価理解するには時間がかかるということを改めて学んだ経験不足だと,どうしてもより高度そうなことに目移りしてしまう。


面白いことに,どちらも原点回帰のような発見だった。

直感編み出した Dex 初期実装手法再評価する十分な経験出来たこともあるが,「越化参照」という概念完成し積極的な活用考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

=}
{交度}

{}