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

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

進捗時限記録中略

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


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

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

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

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

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

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


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

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

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

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


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

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

{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}...=}(94)

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

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{希哲館事業}{一夜革命}{開発}{『希哲日記』}{嬉しい発見}{かくれんぼ}{あれ}{希哲15年1月18日の日記}{希哲館累新}{希哲15年1月19日}...=}(45)

{希哲15年1月19日の日記 K#F85E/E74C-F70C}

昨日の日記を付けながら,デライト累新希哲館累新でもあり,「千年の集約」でいうところの累新に,希哲館黄金期近代化過程相当することに気付いた。

最近,こんなことをぼんやり考えながら時が過ぎてしまうことが多い。がよほど情報整理しようとしているのか,少し思考に引っかかりを感じて手を止めると,そのまま何時間も経っていたりする。そのせいで開発も少し停滞気味だ。

経験上,こういう時は「待つ」以外にこれといった対処法が無いことは分かっているが,流石にそろそろ手を動かしたい。

そう思いながら,デライト公式希哲館訳語についてツイストを書いていた。相変わらず,独自性という言葉陳腐に感じるほどの異形ぶりに,自分は日本の中心部にありながらどんな環境で育ってきたのだろうと改めて感じていた。

あるツイストを書き終えた瞬間、なぜか,幼少期かくれんぼで大人達を困らせた記憶が蘇えってきた。希哲館事業というのは,自分にとってずっとそんな「わくわく」する悪戯だったのかもしれない。一夜革命なんて,やたら壮大なだけでまさにかくれんぼではないか。久しぶりに「三つ子の魂百まで」という言葉を思い出した。

急に童心にかえったような気分になり,すっと肩の力が抜けてなんだか笑えてきた。

気付いてみればこんな単純なことに今まで気付かなかったのか,気付いたことを忘れているのか,灯台下暗しということもあるから分からないが,変に嬉しい発見だった。

これだから思索はやめられないのだろう。

{Aejs}{開発}{開発記録}{交度}{渡括記法}{希哲15年3月31日10歩}{公開連絡先}{暗証語忘れ対策}{ツイート埋め込み}{Twitter Publish}...=}(46)

{希哲14年7月16日の開発 K#F85E/5B28-1CB3}

今日は前後景輪一覧実装を始める予定だったが,深刻不具合などに気を取られ準備程度のことしか出来なかった。

しかし,交度整理しながら描写選り手周りの改良をよく進めることが出来た。特に,描き直し挙動はこれまで自分で気に入らないところだったので,洗練されたのが嬉しかった。

以前から怪しかった AdSenseAejs干渉問題も根本的解決策を施すことが出来た。

昨日の開発記録をまとめていて,公開連絡先を使った新しい暗証語忘れ対策を思いつき,この方向でまとめていくことにした。

もう一つ大きな作業方針上の進展として,自我登録時の知番予約改良一括挿入バルクインサート)から試すことにした。初歩的なことだが,余裕がなかったのか 外充て函数過信していたのだろう。これも灯台下暗しだった。ずっと非同期化の方向で検討していたが,そもそも非同期化しないと困るような処理が自我登録のたびに走っていたら捌き手がもたない,かといって予約範囲の分割も煩雑化を招く,といった懸念があったため,これで済めば万々歳だ。

その他,Twitter Publish+ 記法を使ってツイート埋め込みをする方法について検討など。

{開発}{開発記録}{デライト}{引き入れ}{デライトの学習}{引き入れボタン}{希哲14年7月14日}{最大の課題}{諸場}{諸場用合い}...=}(26)

{希哲14年7月14日の開発 K#F85E/5B28-66DF}

デライト諸場用合い最大の課題だった引き入れ操作性だが,ふと,旧全知検索実装していた引き入れボタンを思い出した。

引き放ち(ドラッグ&ドロップ)式重視したデライト新全知検索に移行する過程で消えたが,スマートフォンなどの諸場用合いで快適に引き入れするにはこれしか無さそうだ。ちょうど前後景輪一覧整備しようとしているところなので,引き入れボタンを改良して復活させ,諸場用合いではこれを推奨する方針をまとめた。

当初は引き放ち式にとらわれ過ぎていて灯台下暗しになっていた。その後,写し貼り式に焦点を移すが,試してみるとこれも諸場では煩わしいことに気付き,しばらく出口が見えない状態が続いていた。結局原点回帰になった。

{灯台下暗し}

{}