{『阿部寛のホームページ』}{最悪の事態}{実装可能}{遅かった}{9年}{デライト高速化}{デライト高速化前の現状整理}{一日一文}{実装難度}{デライト史}...=}(95)

{デライトはなぜ速いのか K#F85E/A-E74C-1187}

いまデライトでは,「高速化」の作業最優先取り組んでいる。その理由デライトの現状については,昨日,「デライト高速化前の現状整理」にまとめた。そちらは個人的覚え書きだが,興味があれば覗いてみて欲しい。

今日は,デライトの「速さ」の歴史について簡単に振り返ってみたい。


「デライトはなぜ速いのか」というに,デライト用者ユーザーは少し違和感を覚えるかもしれない。個人知識管理(PKM)サービスとしてのデライトは,速いと言えるほど速くはない。せいぜい「」だ。ただ,並の速さで動いているのが奇跡的に「速い」と言えるほど,実装難度が高いのだ。普通に実装すれば,遅過ぎてまず実用にならないだろう。

サービスとしてのデライトは,「デルン」という全く独自CMS で動いている。Wikipedia に対してウィキがあるようなものだと思ってもらえばいい。このデルンの実用化成功したのは,希哲6(2012)年,もう9年ほど前のことだ。

実は,最初にデルンが動いた時,使っていた論組プログラミング言語PHP だった。そして,あまりにも遅かった。ある程度のが出来たあと,すぐに C++書き直した。

これが出来たのは,当然,準備していたからだ。元々,デルン開発にあたっては速度重視していた。それは体感出来る速さのためというより,「遅さで使いものにならない」事態を避けるためだった。ほとんど前例が無く,全てが未知数手探りという状況だったので,そもそもデルンのようなものが現実的に実装可能なのかどうかすら分からなかった。作ってみたがまともに動かない……これを最悪の事態想定していた。

そうなると,利用する技術は少しでも速い方が良かった。手探りの開発過程でいわゆる技術的負債蓄積していくことも想定していたため,それを補ってくれるだけの速さが必要だった。言語で言えば,今なら Rust あたりも選択肢に入ったかもしれないが,デルンを構想し始めた当時は C++ くらいしか無かった。

一方で,当時の私はウェブ開発経験に乏しく,デルンに何が必要なのか把握出来ていなかった。そこで,PHP を使って試作品プロトタイプを作ってみることにしたわけだ。

案の定,PHP で出来たデルンは実用的速度で動かず,すぐに準備していた C++ に切り替えた。この移行作業円滑に進み,やがて という独自言語に変貌していく。

今のデライトは,この Cμ に FastCGIマルチスレッドnginx 等々と徹底的に速度を重視した構成で動いている。PostgreSQL出場(DB)側も Cμ で外充て(ストアド)函数にしている。徹底して単純化された設計も手伝い,ほぼ極限まで高速化出来る可能性がある。

これまでのデライトにとって,「速さ」は遅さを補うためのものだった。そして今,この速さを武器にするために高速化作業を進めている。どうせやるなら,有名dev.to『阿部寛のホームページ』のように,速さを楽しんでもらえるくらいにしたいと思っている。是非楽しみにしていてほしい。

=}
{略語を使わない}{略さず}{共有しにくい}{一日一文}{略す}{略さない病}{JavaScript の beforebegin,afterbegin,beforeend,afterend に代わる要素位置記法}{デライト一日一文}{kbd 要素}{素交}...=}(110)

{交度英語のすすめ K#F85E/A-E74C-244F}

希哲館における珍奇語彙といえば「日本語史上最大の翻訳語体系」こと希哲館訳語ばかりが注目されがちだが,実は,もう一つそれに負けず劣らず珍奇な言語関連望事プロジェクトがある。それが「交度英語」(Code English),略して「交語」(Codish)だ。

これは主に希哲館情報技術体系利用しているもので,簡単に言えば,「英語勘報機コンピューター向けに簡略化した人工言語」だ。


勘報コンピューティング世界では,技術者であれば誰でも理解出来るような略語というものが多数存在する。例えば,std〈standard〉int〈integer〉str〈string〉……といった具合だ。多くは「歴史的経緯」で定着したものだ。

一方で,こうした略語使用を避けるという文化優勢になっている。その主な理由は,「共有しにくい」からだ。特に新しい論組プログラミング言語では,英語略さずに使う傾向があるため,妙に冗長交度コードが増えた。

はっきり言おう。私は,これが非常に馬鹿げた考え方,いわば「略さない病」であると思っている。この病気によって世界から失われた効率性金額換算すれば天文学的なものになるに違いない。

よく考えてもみてほしい。略語というのは,どんな専門分野でも記録情報交換効率化のために自然発生するものだ。数学の一見意味不明略語記法は,数学者本質的仕事専念するために編み出したものだろう。日夜神経を磨り減らして交度と向き合う情報技術者がそれを封じるのは,狂気の沙汰と言ってもいい。

実際のところ,「略語を使わないルール徹底されているかというと,そうではない。例えば,String str; なんて記述は世の中に溢れかえっている。C++ には shared_ptr(pointer)Java には println()(line)なんてものがある。「モダン」なはずの HTML5 にも img(image)やら kbd(keyboard)やら残っている。こうした混在が当たり前になっているのが現状だ。なぜなら,「略語を使わない」というのは本来不自然なこと,無理のあることだからだ。

長い方に合わせるのは無理なのだから,短い方に合わせればいい。共有しにくいなら,「略語を使わない」のではなく,「略語の辞書を作る」ことを考えればいい。頻繁に使うものなら人間は慣れる。これがつまり,交度英語考え方だ。

交度英語では,すでに定着している英略語を基礎に,実践を通じて新しい略語提案問題があれば修正しながら語彙を作り上げていく。

具体的には,論組をしながら,どうせばいいのか分からない英単語にあたった時,私はまず適当に略してみて,それをデライト検索する。他に前例があればそれと突き合わせて修正することもあるし,無ければどういう意図で使ったかを描き出していく。これを繰り返すことで,デライトが自然と辞書役割を果し,妥当略語の使い方に導いてくれるようになる。

これは基本的に希哲館訳語で行っていることと同じであり,デルンデライトがはじめて可能にしたことでもあるのだろう。

希哲館ではまだ素交ソースコード公開などはしていないので,交度英語を使った交度の実例としてすぐに見せられるものは少ないが,最近書いた「JavaScript の beforebegin,afterbegin,beforeend,afterend に代わる要素位置記法」などにはその片鱗が見えるかもしれない。

いずれ『希哲辞典』のように辞典として整えて公開することも考えているが,まずは考え方を紹介しておきたかった。

{Perl スクリプト}{希哲15年4月5日のツイスト}{希哲15年4月5日}{ツイスト}{Markdown}{理由}{拡張}{興味深い}{模倣}{軽量マークアップ言語}...=}(12)
{defer 属性}{希哲15年4月1日の開発}{描画速度}{二度手間}{link rel="preload"}{速度差}{DOM 構築}{Document.readyState}{Node.appendChild()}{デルン初期実装}...=}(53)

{希哲15年4月1日17歩 K#F85E/A-E74C-FE68}

Aejs@icl() とその周辺見直し

いったん終了。

デルン初期実装からか,@icl() では Document.write() 相当の @doc.wr() を使って script 要素を書き出していたが,これは様々な面で好ましくない。こんな実装にした経緯失念したが,装体書で同じようなことをする @apd_ss()@elm.bld..apd()Node.appendChild())を使っているところをみるに,テンプレート上で書き出し位置を指定しやすいといった理由があったのだろう。

特に,昨日まで Aejs にあった干渉不具合を回避するのに有用ではあったが,もはや不要なのでここで周辺とともに整理しておいた。

まず,@icl() を @elm.bld..apd() を利用した実装にし,スクリプト調整を行なった。AdSense より前の位置に配置していたため,これを body 要素末尾のその他ライブラリ前に移動した。非同期になったことで DOMContentLoaded が終わっている可能性があるため,Document.readyState を利用して DOM 構築完了後であれば即実行する処理を @() に加えた。

更に,各スクリプトに defer 属性を付け,直書きしている部分は addEventListener() で DOMContentLoaded を待ってから実行するようにした。ここはスクリプトを通さず捌き手側で直接書き出してもいいかと思ったが,試してみたところ大して速度差が無かったため,現状維持とした。

更に,link rel="preload"導入,ついでに cfg.vs で設定していた隠し破りテンプレート側で設定し,@icl() や @apd_ss() に引数として渡すようにした。テンプレート側で直接記述している URI に利用出来ず,修正作業でよく二度手間が発生していた。

ここまでの作業で体感的描画速度向上が見られた。ただし,速くなった分描画過程が見えてしまうようになったため,明日装体書調整を行うことにした。

未出振るい

=}
{心掛ける}{3ヶ月に1回}{ただの風邪}{主力機の不調}{若返った}{Cμ 流}{C 風}{アイコン制作}{希哲15年3月16日}{挿し直し}...=}(59)

{希哲15年3月16日の開発 K#F85E/A-E74C-838E}

昨日の主力機清掃後の耐久試験も兼ね,Windows 仮想機共有ボタンフィードボタンに使うアイコン制作2歩5歩)。


その後はデラング整備Dex 実装作業没頭

あえて C 風に書いていた Dex_T内部実装を思い切って Cμ 流に書き換えた。

設計に関しては行くところまで行ったという感じだ。


主力機若返ったように安定してきびきび動いており,最近の小さくない不安材料が消えた。

ここ数年の経験総合してみるに,主力機の不調原因は「」だった可能性が高い。

昨日は一応記憶器挿し直しもしたが,疑っていた接触不良という感じではなかった。1年以上前ではあるものの,同じ現象は Memtest86+通過しても起こることを確認している。

落ちてから10分ほど後に蓋を開けてみると,思いのほか内部がこもっているのが分かった。負荷室温高低にかかわらず起きていた記憶があったが,本体内部の熱を甘く見ていた。

人間でいえば80歳前後かという高齢個人機で,いつ壊れてもおかしくないという覚悟で使っていたせいで,問題複雑に見過ぎていたかもしれない。たまにする埃取りからしばらくは安定する,ということを繰り返していたが,流石に「ただの風邪」だとは思えなかった。

酷使してきたような気はするが,ほぼ SlackwareSLFS で使っていたことも長生き理由にあるだろう。

これからは少なくとも3ヶ月に1回埃取り心掛ける

{希哲15年3月15日の開発}{なんとなく}{最新のブラウザ事情}{希哲15年3月15日の進捗時限}{希哲15年3月15日の進捗}{希哲15年3月15日}{ブラウザ研究}{思いつき}{上等訳語}{消極的ウェブ戦略}...=}(31)

{希哲15年3月15日5歩 K#F85E/A-E74C-1D7A}

最新のブラウザ事情に疎くなっていることもあり,デライトのためのブラウザ研究必要を感じている。

そこで,かつて使っていた「舞覧」という翻訳語再評価上等訳語として採用することにした。

この翻訳語は希哲11年9月3日考案し,一時期よく使っていた。これといった理由もなく,いつからかなんとなく使わなくなっていた。

振り返ってみると,使わなくなったのは積極的ウェブ戦略への転換からだった。

それ以前の消極的ウェブ戦略ではウェブをそこまで重視しておらず,「舞覧」も思いつきに近いものだった。ウェブに対する姿勢が変わったことでそのまま使う気分ではなかった。

少し落ち着いたいま再検討してみるに,やはり「舞覧」を越える翻訳語は出てきそうにない。

これから積極的に使っていくことにした。

=}
{希哲15年2月11日の開発}{spn.kno}{spn.knm}{spn.knob.l}{spn.spc}{輪符要素省略形}{輪符要素正規形}{中景輪符}{希哲15年2月11日の進捗時限}{希哲15年2月11日の進捗}...=}(30)

{希哲15年2月11日1歩 K#F85E/A-E74C-49EB}

昨日の中景輪符見直しdiv.r(正確には spn.r)の仮導入を決めたが,これに伴ない,輪符要素仕様整理することにした。

新しい要素の導入を避けてきた理由として,場当たり的文書構造複雑化させたくないというのがあった。

そこで,spn.lspn.knob.l, spn.knm), spn.spc, spn.rspn.kno, spn.knob.r)という構造を「輪符要素正規形」として,spn.lspn.r は適宜省略してもいいことにした(輪符要素省略形)。

これなら柔軟性を持たせつつ理論的にもすっきりし,輪符周りの交度整理しやすくなる。

=}
{開発者コミュニティ}{リスク低減}{費用削減}{困難さ}{隠すべきものを持たない強み}{希哲15年2月1日3歩}{きっとん}{素交非公開原則}{素交公開原則}{素交公開}...=}(89)

{希哲15年1月30日の日記 K#F85E/A-E74C-E10D}

日本の情技業界を騒がせている業務素交流出事件に思うところあり,希哲館でも原則として素交公開していく「素交公開原則」の採用本格的検討し始めた。

昨年の今頃もそんなことをぼんやりと考えていたが,特にこの頃,描出公開原則成功確信が持てるようになったり,政治参加方針公開が考えられるようになったり,「隠すべきものを持たない強み」を実感することが多くなっていた。となれば,素交公開自然流れだろう。

もともと虎哲関係の素交独自性が強過ぎ,動作環境備立方法も特殊文書込め言には独自用語と希哲館訳語満載という状態であり,盗んだところでまともに運用するのは不可能だ。これを「自然難読性」と呼び,ある種の強みと考えていた。

それでもいわば「素交非公開原則」で来た理由はいくつかある。

第一には,私自身の完璧主義的な性格であり,見せる必要もないところで不完全なものを晒したくなかった。

次に,希哲館事業収益化不可能に近い困難さがあった。万が一にもなさそうだった成功可能性を探る上で,万が一でもその障害になりそうな要素排除しなくてはならなかった。手札は一つでも多い方が良かった。

これについては,デライト収益化実現してしまえば無用心配になる。

もう一つ,技術的問題もある。昔から,デルン基礎にした版存管理司組構想してきたこともあり,素交公開するなら独自基盤でと考えていた。無論,そんなものを開発する時間は無かった。

色々な意味で余裕が必要になるので,いずれにせよデライト収益化後に決断することになるだろう。

素交公開原則利点はいくつも考えられる。献典としては死蔵してきた希哲館技術体系宣伝デライトも含めた希哲館事業全体の透明性信頼性向上機密保持に関する費用削減リスク低減,そして最も大きいのは開発者コミュニティを作れることだろう。

KitHub」というのは一昨年思いついたことだが,それこそ GitHub のように成長すればそれだけで希哲館事業の強力な武器になる。

この日は久しぶりに希哲館マスコット構想「きっとん」を思い出し,具体的なイメージを練ったりもした。これがのらくろに似ていることに気付いたのは収穫だった。

2月1日振り返り日記

{デライトに議論特化の機能は求めない}{編集中}{考えよう}{面白いテーマ}{デライトにおける議論}{変更履歴}{描出履歴}{デライト}{輪郭}{空欄}...=}(47)

{デライトでの議論について K#F85E/A-E74C-E1B1}

デライトにおける議論,というのは面白いテーマだと思います。歴史浅いので,開発者にとっても未知数な部分があります。

実は,デライトにも変更履歴描出履歴)を残す仕組みはあり,近いうちにそれを閲覧出来るようにする予定もあったのですが,開発上の都合保留にしています。

空欄上書き」を削除代わりにしている現状,残したくない履歴もあるだろう,というのも理由の一つです。

もともと輪郭大意を捉えるためのものとして設計されており,それゆえに最初は適当に書いて後から完成させる,という作業がしやすくなっているのですが,おっしゃる通り,議論の細かい過程を残すことには向きません。

ただ,これは考えようで悪くないかもしれない,とも思っています。

ネット上での議論でありがちな言葉尻の掴み合い,というのはあまりデライトには持ち込みたくない文化だからです。デライトでは,互いに相手の真意を汲み取ろうとしない議論成立しません。常に相手が編集中かもしれないので,ある程度の距離感を保って言及することも必要になってきます。

履歴にせよ編集中にせよ,システム側である程度サポートすることは出来ますが,単純に対応出来るケースには限りがあり,柔軟性を持たせようとすれば複雑化します。

編集中であれば末尾にでも(書きかけ)のように書いておくか,重要な修正をしたらそのことを書いておくなど,ユーザー文化で補えなくもないので,当面はそういう工夫で凌いで頂いて,出来るだけ早く洗練された機能導入したいと考えています。

{理由}{類義語}{わけ}{りゆう}{}{}
{}