{完成の域に達した}{表記的}{写し取りたい}{共有目的}{貼り付けたい}{外部媒体}{適当な時期}{整理中}{省略された}{写し取り時}...=}(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整理中なので,どうしても場当たり的交度になってしまう。他輪郭素出から写し取りたい時や,外部媒体厳密な知番貼り付けたいという時には便利だが,現時点必要としている人少ない共有目的なら共有ボタンがある。交度整理しながら適当な時期実装することにした。

{第二次知番改良}{kno_T}{残しておくべき}{活用出来なかった}{今後の開発}{なりつつあった}{離れていた}{出場周り}{温存する}{望める}...=}(67)

{希哲16年6月8日の開発 K#F85E/E74C-352F}

{用者}{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{`}{解釈出来る}{完了させた}{中途半端な実装}{使用経験}{書き換えずに済む}{意図の明示}...=}(133)

{希哲16年3月12日7歩 K#F85E/E74C-8A2F}

交度記法改良

以下の作業終えたため,ここでいったん終了

これにより,デラング記法例示洗練された

```txt
これまでのデラング記法の例示
```

``dlng
これからのデラング記法の例示
``

交度部区記法開始記号終了記号については,これまで ``` 固定だったため,交度部区記法内で交度部区記法について例示出来ないという問題があった

行内交度記法逆括点の数を調整出来るようにして1月17日15歩から,この方式統一することを考えていた

これを機に逆括点の数は2個でもとした。区切り線記法最初から Markdown などで一般的な3個以上ではなく2個以上-導入したが,交度部区記法では確信が持てなかった

交度部区記法実装からちょうど一年経ち3個以上でなければならない理由はない,と使用経験から判断したなんなら1個でも解釈上問題はないはずだが,目印としての機能考える2個限度だろう。他の記法との統一感もある。


これまで外部ライブラリhighlight.js任せだった交度部区記法言語名自主的に管理する第一歩として,取り急ぎデラングνS対応した

デラングdelangdlngdlntxt に,cuucppに,νsvsjs に,それぞれ Dex 側で変換するとりあえず大文字小文字区別しない

これまではデラングtxt などと書いていたが,意図の明示という観点から問題があった。これなら今後構文ハイライト対応した時に書き換えずに済む

言語名対応関係については実装委ねるべきかとも考えたが,将来的に混乱の元になりそうな部分なので,対応関係言語仕様規定し,構文ハイライトなどは任意実装とすることにした。

また,用者未定義言語名使用出来るように,例えば ```newlang(oldlang) のように代替言語名指定出来る記法検討開始している


1月17日15歩で,外側逆括点の数を調整出来る仕様にしたが,`` `a` `` のように外側より少ない個数でないと上手く解釈出来ないなど中途半端な実装だったことを思い出し実装完了させた

これで ` ``a`` ` でも `` `a` `` でも `` `a`` でも,対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。


全て手定め出振るい済み

=}
{希哲館事業}{デラング}{進捗記録}{希哲16年2月22日}{希哲16年2月22日の開発}{希哲16年2月22日の進捗}{担わせる}{4ja}{有名無実化}{意識しない}...=}(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文字サブドメイン問題解決

サブドメイン活用していく上で,一つ,「2文字サブドメイン問題」とでもいうべき問題があった

例えば,サブドメイン与えるなら cu.kitetu.com とするのが自然だが,CUキューバ国家符号だ。

ドメイン名統一によって ccTLD使わなくなっているため,将来的に地域別ドメイン欲しくなった時にはサブドメイン使うことになる。2文字サブドメイン使用避けるべきかもしれない,と考えていたキット*メーネmn.kitetu.comモンゴルMN被っているのが少し気になってはいた

ただ,その懸念も「もやもや」の域を出ていなかった明らかに紛らわしいサブドメイン最初から使わないので,被るとしたら普段意識しないようなものだ。被ったとして,ドメインハックccTLD有名無実化している今,そこまで神経質になることでもないだろう。そんなことのために,わざわざ不自然な表現もしたくない。とはいえ,サブドメイン選択肢多い越したことはない

そこで,国家符号表す何らかの接子導入考えたFacebook のように,ja-jp言語符号付きを基本として,言語符号がいらない場合は x-jp のように表記出来るようにするかとも考えたが,少し野暮ったい

最終的に4 接頭子導入する方向検討進めることにした。例えば,キューバ向けのドメイン4cu.kitetu.com として cu.kitetu.com区別出来るようにする。衝突しなければ 4 接頭子省略してもいいし,4ja のように言語符号に代えられてもいいだろう。4ja-jp のような表現が出来てもいい。これなら十分な簡潔性柔軟性兼ねられる

例えば 4jp.kitetu.com なら www.kitetu.com変わらない標準的な長さだし,むしろお洒落感すらあるので,これで統一して,4 接頭子無しは転送用にしてもいいくらいかもしれない。

いまのところ地域別ドメイン必要は感じておらず,将来的に必要になるかもしれない,という程度の問題なので,細かいこと追い追い決めるとりあえず理論上すっきりしたので良かった

=}
{デラング}{『希哲日記』}{Google 検索}{強い}{分かる}{高い}{語感が良い}{作り込んだ}{裏目に出た}{検索に強い商標}...=}(126)

{希哲16年2月20日の日記 K#F85E/E74C-DA06}

日曜日なので半休にして,のんびり15日分のまとめでも片付けよう思ったが,想像以上に時間がかかった最後の24歩

よくあることだが,描き出してみて初めて膨大な思考量だったことが分かる


デラング的転回の後,デライト市場戦略におけるデラング重要性一気に高まったことで,「デラング」の検索語としての利点気付いた

いま Google 検索してみると,外国地図と「もしかして」が表示されてしまっているが,一応最上位になっている"デラング" の Google 検索結果この調子なら間もなく独占出来そうだ。さほど期待していなかったので棚から牡丹餅みたいなものだが,第四次デライト市場戦略への期待がさらに高まった

他方,もっと長く多用してきた「デライト」や「デルン」の方は完全に埋もれてしまっている

デライト」に関しては,「デライト メモ」のように検索すれば最上位に出てくる。そもそも普通のカタカナ英語なので,埋もれやすいことを想定して「なんでもメモ、デライト」という獲句考えたのだが,それにしても「デライト」単独での上昇思ったより遅い認知度高い固有名詞が無いからそこまで上位表示難しくないだろうと思ったが,中小規模用例意外に多い将来的にはともかく,立ち上がりには厳しい検索語だった。

デルン」の方は,あえて耳慣れないように造語したのだからすぐ独占出来るだろうと思っていたが,10年以上使ってい全く上位表示されなかった。よくよく検索結果観察してみると,どうも部分一致するページ多い耳慣れな過ぎて,そもそも単独として認識されていないようにすら見える短さ裏目に出たか。

サイト全体への検索流入良好推移してきただけに,逆効果になる可能性考える下手に作為的SEO出来なかった単純に Google 検索してみると,「デライト」で136万件,「デルン」で20万件弱,「デラング」で2,400件と,見事に桁が違う結局競合想定より多かった上に,雑多なページ膨大にあるせいで評価分散したのが原因だったのだろう。

デラング図らずも三度目の正直になったが,ここまで検索に強い商標作るのが難しいことだとは思わなかった市場戦略的なことを考えて作り込んだデルン」や「デライト」よりも,語感が良使いやすいというだけで使い始めたデラング」の方が強いのも皮肉だ。


21日振り返り日記

{進捗記録}{希哲16年2月18日の開発}{あれ}{文章の流れ}{左右矢印}{下矢印}{上矢印}{使うべきではない}{右矢印}{使われない}...=}(171)

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

進捗時限記録中略

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

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

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


デルンにあった類似機能から,「時間(時印)的な前後関係」を表現する記法として「前後記法」と呼んでいたが,文書では新旧にかかわらず読ませたい順序指定出来る方が便利なので,より汎用的な前次記法」と位置付け直した

新旧表すのに「」や「」というのはよく考えるおかしいという意見もあり,私も何か良い代替表現はないかと考えていたが,慣用表現として定着しているのでこれは仕方ない前ページ次ページというように,左開きページめくっていく感覚なのだろう左開き右開き書字方向との相性問題なので,ウェブになることが多いのは一応合理的ではある)


前回の検討では,以下のように書いていた

前 <|> 後
前 <|
|> 後

これは他記法区別しやすく簡潔ではあるが,見本はともかく少し長い文字列が入ると記号埋もれがち直感的とも言い難い視認性考えると,行頭行末分かりやすい記号があってほしい。

また,<|>タグ記法使う予定</>紛らわしい|始まる長い文字列があると,初心者には表組み記法誤認される恐れもある。


他記法との区別しやすさ簡潔性直感性などを総合的に考慮した結果最も素直な記法であろう <- 前 | 次 ->落ち着きつつある

雑多な考慮点列挙しておく。

=}
{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二本線の方がすっきりした印象になるのが意外だった。

{進捗記録}{高い}{希哲16年1月31日の開発}{希哲16年1月31日14歩}{見送ってきた}{別の記法}{必要性に乏しい}{閲覧性}{重い強調輪符}{予想される}...=}(97)

{希哲16年1月31日13歩 K#F85E/E74C-0A95}

進捗時限記録中略

閲覧専用模動強調輪符多重輪括弧についての整理終了


多重輪括弧は,単純に外側の輪括弧をそのまま全て表示する仕様まとめていくことにした。この場合,閲覧専用模動でも輪結になる。役割を考えると,この場合の輪結先閲覧専用模動ではなく後景一覧あるいは重い強調輪符との組み合わせ輪郭ページにすべきか。

直近の検討では,全知検索における多重輪括弧(個数にかかわらず)輪括弧1対だけ表示し,閲覧専用模動における二重輪結化のみ,三重以上で輪括弧表示する,といったように模動によって表示仕方変えるつもりだった。

これは,輪括弧輪結化する“水準”を表すものと考えれば自然な記法思えたが,模動にかかわらず輪括弧表示させたいという時にわざわざ {{{あれ K#XXXX/XXXX}}}書かなければならないなど,実際には煩雑紛らわしくなることが予想される。現に,こう説明してみても分かりにくい

この複雑な仕様必要なことがあるとすれば,閲覧専用模動強調輪括弧表示もせずに輪符輪結化したいという場合だが,閲覧専用模動用途全知検索との使い分け考える必要性に乏しい相応しい別の記法がありそうだ(これは次歩方針解決か)


二重輪符」や「多重輪符」という用語考えたが,このあたりは将来的に輪符の入れ子にもかかわりそうなので,もう少し整理したい。

輪符の入れ子から検討しているものの,必要性に対する複雑化懸念から見送ってきた。ただ,あれば表現の幅広がるのは間違いないので,将来的に対応する可能性高い


強調輪符閲覧専用模動でも輪結化するという方針維持する

最近全知検索では重い強調輪符のみ輪結先後景一覧ではなく輪郭ページにする方針固まり,より文書として読みやすい形で表現出来るようになるだろう。

閲覧専用模動構想初期に比べて,まず全知検索閲覧性十分なものにするという方向軌道修正している昨年12月6日の開発における輪結装体調整もその一環だった)ため,全知検索閲覧専用模動での表現差異必要最小限留め全知検索読みやすいように書いた文書自然に閲覧専用模動にも適したになるようにしたい。

{将来的に}

{}