{知番}{希哲16年9月18日}{希哲16年7月}{希哲16年6月}{希哲16年9月18日の副日記}{適用される}{着手した}{大変だった}{一山越えた}{解決時}...=}(238)

{希哲16年9月18日の開発 K#F85E/E74C-5BA7}

新生全知検索整備

最初の中間出振るい成功これにより全知検索応答速度柔軟性交度品質大きく向上した出振るい作業円滑に進み,手溢れ無く全体として大成功だった。

輪郭情報取得改良

まず,期待通り輪郭情報取得方式改良により応答速度大きく向上した体感的にもこの種のサービスとしてはという程度から,はっきり速い言える程度になり,快適度数段上がった感覚がある

これまでのデライト高速化施策の中でも最大級の効果感じるが,これはボトルネック解消によるところが大きい6月Cμ 文字列処理改良あたりから,領下手定め環境での高速化効果大きさ比べて本番環境での効果かなり小さい感じるようになっていた。考えられるボトルネックは,相振り出場間の通信回数多過ぎる輪郭情報取得処理だった。

これまでページ表示される輪郭情報の取得は,相振りから大体流れ行っていた

  1. 輪郭隠しにない吊るし輪郭があれば輪郭情報取得するdg_oln()
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()
  2. 輪郭一覧輪郭情報取得するdg_fnd() か,吊るし輪郭初期状態dg_fg()dg_bg()
  3. 各輪郭自我情報前後景輪情報個別に取得する
    1. 自我隠し存在しなければ自我情報取得するdg_ego()
    2. 前景輪数n_fg1以上なら前景輪情報取得するdg_fg()
    3. 後景輪数n_bg1以上なら後景輪情報取得するdg_bg()
読み込み中...
{知番}{知名}{最短知名原則}{希哲16年2月22日}{希哲館事業}{デラング}{進捗記録}{希哲16年2月22日の開発}{希哲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文字サブドメイン問題解決

読み込み中...
=}
{描写}{希哲16年2月15日}{HTML}{駒手記法}{進捗記録}{あれ}{希哲16年2月20日13歩}{神秘的な}{別に}{実装した}...=}(248)

{希哲16年2月15日24歩 K#F85E/E74C-1EF9}

進捗時限記録中略

不意に閃いた階層区切り線」についての方針まとめて終了

従来の見出し未満区切り線記法に,見出し階層越えられる階層区切り線」を加える。以下のように,唯一通常の区切り線区別出来る見出し記号 #全角 使う

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落(# の数でも調整出来る)。
読み込み中...
{希哲16年2月18日}{進捗記録}{希哲16年2月18日の開発}{あれ}{文章の流れ}{左右矢印}{下矢印}{上矢印}{使うべきではない}{右矢印}...=}(171)

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

進捗時限記録中略

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

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

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

読み込み中...
{希哲16年2月4日}{開発}{希哲館訳語}{進捗記録}{希哲7年}{強い}{軽量標記言語}{霞んでしまう}{物量的}{心理的な負担}...=}(75)

{希哲16年2月4日3歩 K#F85E/E74C-1671}

進捗時限記録中略

希哲館訳語についての整理終了

〈lightweight language〉などにおける〈lightweight〉には素直に軽量」を当てることにした。

例えば〈lightweight markup language〉は「軽標記言語」と訳していたが,見慣れない翻訳語組み合わせると,原語ぱっと浮かんでこない。これは「軽量標記言語」の方が無難だろう。

そもそも〈lightweight〉に「軽〜」を当てるようになったのは,希哲7年頃に〈lightweight language〉への「軽言語」という翻訳語考えてからだ。

論組言語においては,スクリプト言語の類を「軽量言語」と呼ぶのに抵抗があった。デルン開発でも鈍重PHP から 書き換え間もない頃だったし,ツバメ開発でも余計なパッケージ必要なことが多い論組言語は「荷物」だった。「軽量」が人間負担軽さ表すものだとしても,論組では実行速度遅さ心理的な負担になることも多いわけで,違和感拭えない。そこで少し抽象的な語感になる「軽〜」を使い始めた

ただ,標記言語の場合は実行速度などの問題がないせいか,物量的軽さという意味合い強い軽量」でもあまり違和感がない。むしろ抽象的な軽〜」を使う方がその長所霞んでしまう表現になる気がする

そもそも,「軽量」という表現問題があるとしてもそれは翻訳語責任ではないし,そこを意訳すると〈lightweight〉という表現をめぐる議論参照しにくくなる。

{表す}

{}