{デラング}{進捗記録}{最善}{方向}{知番}{知名}{与える}{進捗}{最短知名原則}{希哲16年2月22日}(159)

{希哲16年2月22日9歩 K#F85E/E74C-BABF}

進捗時限記録中略

kitetu.comサブドメイン設計についての検討終了

今後デラングのように独立して参照出来るべき献典には積極的にサブドメイン与えていくことにした(例:dlng.kitetu.com


デラング的転回同時にデラング文書dlng.kitetu.com与えることを決めたが,これを機に知番SLFS 等々の公式文書にもサブドメイン与えることを考え始めた

これまでサブドメイン追加には消極的で,例えば技術系献典tech.kitetu.com集約することを考えていた。ただ,この手の URL 設計は,運営者にとっても閲覧者にとっても直感的でなく情報過多になりやすい上,階層的な整理難しいことも多々あり,変更に弱く参照可能性の低い URL が出来がちであるという問題があった。

こういう場合対策として,経験上最短原則」が最善であることは分かっていて,最近駒手にせよ各種識別子にせよ知名最短知名原則にせよ最短化する流れにある。サブドメインについてもこれに従うことにした。希哲館事業要素全て kitetu.com階層下にある,ということだけは確かだ。もちろん,これとは別に,階層的な情報源もあった方がいいので,そこは tech.kitetu.com などに担わせる

献典ドメインとしての独立性統一感同時に持たせられるのだから,むしろ,ここからがドメイン名統一本領発揮になりそうだ。

2文字サブドメイン問題解決

読み込み中...
{進捗記録}{}{右開き}{右矢印}{}{十分}{}{記号}{自然言語}{進捗}(171)

{希哲16年2月18日13歩 K#F85E/E74C-E223}

進捗時限記録中略

前後記法」として検討していた記法を「前次記法」に改め仕様再検討して終了

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

以上のように,<- 前 | 次 ->基本形とし,改行区切り<- 前次 -> のみでの記述可能にすることにした。

読み込み中...
{進捗記録}{}{十分}{初期}{与える}{進捗}{拡張子}{廃止}{希哲15年12月13日の開発}{冗長過ぎる}(113)

{希哲15年12月13日4歩 K#F85E/E74C-143E}

アンダースコア略記法内包子におけるアンダースコア記法廃止についての検討終了

現状譜類名(例:._acv台録名(例:/_kn/駒手名(例:_knなどにアンダースコア接頭子略記法として多用していた時期名残り多くあるが,ほとんど活用していないため,いったん廃止することを決めた

アンダースコア略記法やその応用記法問題は,明示性簡潔性ともに中途半端で,現実には使いにくいというにある。より簡潔な記法冗長な記法があると使い分け方無駄増えややこしいし,使い所無い

知機駒手では大分前から _kn よりも kn使うようになっているが,9月9日13歩以後はこの kn省けるようにしたため,_出番完全に無くなってしまった結局 _ よりも kn使ってしまう理由は,どうせ面倒臭いなら分かりやすい方が良い,ということだった気がする

これまでの経験上十分明示的な冗長記法短縮記法2つまとめていくのが一番良さそうだ。


KNIF使っていたアンダースコア記法廃止し,代わりに kn- 接頭子導入することを決めた

例えば,これまでの ._acv冗長表記.kn-acv短縮表記.acv となる。知機駒手同様,混同の恐れが無い場合は原則として短縮表記用いる

.kn.acv のようにすることも考えたが,一つの拡張子として認識されないと不都合なこともあるので,MIME 型application/x-kn-acv正式名称初期合わせるKNIF の各形式与える正式名称は,旧称 KFF の時は KFF- 接頭子KNIF になってから KN-ACV のような KN- 接頭子になり,一時 KNIF_ 接頭子揺らいだこともあったが冗長過ぎる,これを機に KN- 接頭子確定する


アンダースコア記法依存した実装排除しながら段階的置換進めていく

{進捗記録}{進捗}{デラング文書}{希哲15年6月28日の開発}{表組み記法}{希哲15年6月28日の進捗}{希哲15年6月28日の進捗時限}{希哲15年6月28日}{テーブル記法}{定表記法}(21)

{希哲15年6月28日9歩 K#F85E/E74C-2595}

進捗時限記録中略)

デラング整備表組み記法仕様検討

およそ6歩分3時間ほどかかっていったん終了。

簡潔性柔軟性直感性を兼ね備えた記法の全体像が概ね出来た。

表組み記法」に覚え書き程度にまとめたが,いちいち解説している時間は無いので実装してからデラング文書にまとめる。

今日から,これまで使っていた「定表記法」や「テーブル記法」の代わりに「表組み記法」とすることにした。

{}{和文}{希哲館訳語}{希哲14年3月17日}{希哲14年3月17日のツイスト}{ツイスト}{表現力}{簡潔性}{活用}{課題}(10)
{進捗記録}{〈right〉}{進捗}{ref_}{r_}{希哲14年1月9日の進捗時限}{希哲14年1月9日の進捗}{希哲14年1月9日}{p_}{進捗時限記録}(14)
{知番}{PostgreSQL の外充て函数}{理腑}{希哲13年12月24日のツイスト}{希哲13年12月24日}{輪郭}{ツイスト}{簡潔性}{実感}{震撼}(13)
{開発}{開発記録}{理腑}{デライト正式離立}{構築函数}{希哲13年12月15日}{目標意識}{SQL 類型群}{希哲13年12月11日}{出場}(21)

{希哲13年12月11日の開発 K#F85E/5B28-815C}

出場周辺の理腑新知番実装換装続き。

かねてから検討していた SQL 類型群の導入実験を始めた。SQL を構成する諸要素を類型化し,各類型毎に構築子構築函数演算子を設定することで,DGDBI保守性を向上させる。

一日がかりで基本的な部分を書き換え終え,想像以上に直感性簡潔性厳密性が向上することが分かった。

大きな収穫ではあったが,デライト正式離立への目標意識が稀薄になってきたため,15日に目標を再設定した。

{簡潔性}

{}