{『阿部寛のホームページ』}{最悪の事態}{実装可能}{遅かった}{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『阿部寛のホームページ』のように,速さを楽しんでもらえるくらいにしたいと思っている。是非楽しみにしていてほしい。

=}
{デライト高速化}{希哲15年4月14日の日記}{希哲15年4月14日の開発}{高度な機能}{修正回数}{重くなる}{当たり外れ}{作業分類}{機能整備}{速いデライト}...=}(174)

{デライト高速化前の現状整理 K#F85E/A-E74C-A2D0}

希哲15年4月14日本格的デライト高速化に入る前の現状整理について,ここに記録しておく。

2月後半を預っていたこともあり開発集中しにくかったが,3月の頭からデライト開発はいわば「快調期」に入った。この想定外快調でそれ以前の計画良い意味狂うことが多くなり,3月8日からは計画にとらわれず直感に従って作業を進めていくことにしていた(日記)。

この快調によって,より高い完成度での新生デライトを目指すことが出来るようになり(第三次デライト市場戦略),3月20日収益目標達成努力期限5月1日延長28日にはこれを必達期限として,同時に短期集中生活に入った(日記)。短期集中生活は今月10日に終え,やり残した待っ読ボタン実装昨日一段落した。これが「デライトこれまでのあらすじ」といったところか。

少し落ち着いたところで,次の作業に入る前に現状整理することにした。収益目標達成期限まで残すところ半月,作業の優先順位見極める必要があった。短期間にこれだけのことがあると,流石に頭の中も混乱気味だ。もやもやしたものを晴らしておきたかった。

現在のデライト開発速さ予測不可能性を考えると,やはり中途半端な計画足枷にしかならない。「黄金循環高速化」としてのデライト高速化中心に,機能追加文書整備宣伝等々,全てを臨機応変巻き込みながら片付けていく,というのが現状での最適解結論付けた。

デライトにとって最大の付徴輪郭法であって,枝葉末節機能ではない。それを磨き上げ伝わりやすくする作業でもある。


作業項目としての「デライト高速化」を意識し始めたのは2月17日の開発からだった。当初は機能追加よりも優先し,文書整備並行させることを考えていた。その後,快調期に入ってから機能追加優先順位が上がり,特に Dex によるデラング整備優先するようになっていった。

今月頭の時点での大まかな見通しは,10日までに必要な機能追加20日までに新生デライト仕上げ,文書整備を終え,21日から第三次宣伝攻勢を開始,並行してデライト高速化を進める,というものだった(1日の日記)。

ところが,@icl() 周辺整備をきっかけに入った小理腑が,1〜2日という想定よりも長引き(6日間),上旬がほぼ潰れた。更に,これが思わぬ体感表示速度向上に繋がったことで,一気に高速化への持ち辺が高まった。この頃から,どちらかといえば後回しにするつもりだった高速化を最優先にすべきではないか,と考えるようになっていた。待っ読ボタン実装を終えた昨日の時点でほぼ腹が決まっており,最終確認のためにこの現状整理をしているわけだ。この判断収益目標達成成否直結するだろう。


デライト高速化の主な意義としては,用者体験の向上,SEO負荷軽減の3つを当初から見込んでいた。

小理腑後は,これに開発効率描出効率向上という意義が加わった。手定め時間短縮にもなるし,より描出を上げを増やすことにも繋がるだろう。頭では分かっていたことだが,速いデライト体験して実感が出てきた。この「先行体験」をさせてくれた小理腑の影響が大きい。

Dex 以後,デラング活用することにした文書整備にも寄与することになる。


高速化に並ぶ大きな作業分類であるデラングを含む機能整備機能追加),文書整備と比べても,やはり高速化が優位だろう。何より,高速化は技術面でも設計面でもデライト向きであり,この中で最も「伸ばせる」ところだ。本領発揮と言ってもいい。

機能追加が訴求するかどうかは当たり外れが大きい。開発者が求めているものと用者が求めているものは異なることが多いが,用者が求めているものと必要としているものも往々にして異なる。要望に応えても,思ったより必要なかったということもある。これは用者が馬鹿だからではない。開発者ですら,思ったより要らなかった,要らないと思っていたが意外と便利だった,ということは多々ある。人間そんなものだ。それでも,十分な時間があれば「数撃ちゃ当たる」で成功確率を高めることは出来るが,今はそうではない。

そもそも,現状デライト活動用者極端に少なく,動向分析する標本にもならない。まずは入り口の手前にいる人達を呼び込む必要がある。そのためには,一部の用者しか使わない高度な機能よりも第一印象重要であり,これに寄与するのは高速化だ。

また,機能追加には程度の差こそあれ通信処理上の負荷が伴なう。予定している機能を現状のデライトに全て詰め込めば明らかに重くなるのは目に見えている。


文書整備に関しては,ある程度機能整備が済んだところか,少なくとも機能整備と並行させなければ作業効率上の問題がある。これだけ仕様変更機能追加が激しい状況でなまじ文書を追随させても修正回数が増えるだけだ。先の理由で機能整備を後回しにするなら文書整備も後回しにするほかない。

現状,「使い方」などの文書は離立補完を最後にほとんど更新しておらず,実装との乖離が激しくなっているが,逆に言えば,無駄な修正作業が省けたということだ。新生デライトが熟れるまで放っておくのも一つの手だろう。

宣伝においても体験重視するようになる中で,相対的な重要性が低下していたということもある。「良い文書のある悪い体験」よりは「悪い文書しかない良い体験」の方がマシだ。


黄金循環」は,1月から再認識し,2月までよく言及していたが,3月からは快調期目まぐるしさ横に置いていた。

振り返ってみると,2月20日の日記高速化との結合予期するようなことを書いている。ただ,それほど強く両者の結合意識していたわけではなく,黄金循環高速化手段明確ではなかった。「全知検索の改良」と言っても,基本的な部分で問題の多かった希哲13年頃に比べ,今では範囲が広過ぎる。

快調期以後,計画ではなく直感に従うという戦法難局を上手く切り抜けてきたが,「次の作業」を意識するようになった短期集中生活終盤あたりから,作業になるものが欠けていると感じていた。

ここで高速化黄金循環結合してそのとして機能し始めるのだから,劇的な展開と言うほかない。ここまでの経験が全て一つに繋がったことになる。

{お目汚し}{世にも珍しい}{人気サービス}{有名サービス}{一日一文}{デライト収益目標達成}{デライトの現状}{安定拡大戦略}{超低経費}{用合い設計}...=}(147)

{ネットサービスにおける「成功」とは何か K#F85E/A-E74C-A43E}

ネットサービスで「成功」と聞くと,有名で,人気があって,という感じにイメージする人が多いだろう。ただ,サービス開発現実はそこまで単純ではない。企業は,顧客投資家の手前,明るい側面ばかり見せようとするものだ。世の大抵のサービスは,何らかの意味で「火の車」だと思って間違いない。

デライトも一応ネットサービスに含まれるし,今は収益目標達成に向けて邁進しているところだ。利用者の方から色々な助言を頂くこともある。その中で,外から見た「成功」と内から見た「成功」の違いについて考えさせられることが多い。


デライトは,「安定拡大戦略」と呼ぶ戦略を取っている。その名の通り,急拡大を避け,制御可能な範囲で安定的拡大を続けていく,という戦略だ。つまり,世間でイメージされるような,バズって有名になって上場するなり売却するなりして大儲け,というような「成功」は,元よりデライトの目指すところではない。それどころか,避けたいとすら思っている。

これは,デライトが希哲館事業一環として開発されているからだ。希哲館事業は,知能増幅(IA)技術による民主主義資本主義革新目的とした事業であり,その性質上,独立性生命線にも等しい。

ソクラテスが何と闘い,何に殺されたのかを引き合いに出すまでもなく,権力権威大衆は,どれもが従ってはならないものだ。出資に頼ることも寄付に頼ることも出来ない。となれば,自分で稼げる範囲で運営していくしかないわけだ。

投稿で賑わっているのが成功しているサービスかというと,それも難しいところがある。閑古鳥が鳴くような状態も困りものだが,低質悪質な投稿であふれ返っているような状態がデライトにとって望ましいとも言えない。特に恐れているのは,よくいう「コミュニティ空洞化」だ。悪貨が良貨を駆逐するような状況に陥いることは何としても避けたい。

個人開発サービスによくあるのが,何かの拍子に爆発的人気を得たものの,運営費などが捻出出来ず,どこかの企業売却あるいは譲渡せざるを得なくなった,という例だ。それなりの金額で売却出来れば成功と見る人もいるが,デライトでは最悪の失敗として想定している。

デライトは,希哲館事業心臓のようなものであり,万が一にも手放すことはない。手放すくらいなら心中するという覚悟開発している。


デライトは,今のところ,有名サービスでもなければ人気サービスでもない。では上手く行っていないのかというと,面白いことに,世にも珍しいほど上手く行っているサービスなのだ。

世界初の実用的な知能増幅技術を実現した輪郭法という基礎理論は,私が17歳の頃に考案したものであり,デライト実装も全て私の手によるものだ。周辺技術もオープンソース基礎として独自開発最適化したものを応司(OS)から論組プログラミング言語範枠フレームワークにいたるまで整備している。

例えば,用合い(UI)設計語体ロゴタイプアイコン制作といったことから,論組プログラミングサーバー管理広報経営まで,とにかく何でも一人でやっている。デライト上にある中核的献典コンテンツも私が書いている。

別に自慢話をしているわけではない。これが意味することは,デライト驚異的高効率開発運営されているということだ。普通の開発現場というものを知らなければなかなか想像出来ないことかもしれないが,サービス開発者にとっては喉から手が出るほど欲しいような環境を,すでに手にしているのだ。こればかりは,GAFA のような超大企業が金を積んで手に入れられるものでもない。

人件費がかからないのは言うまでもないが,中核となる全ての権利権限開発者が保有しているので,組織ならどんなに早くても3日かかるような意思決定が,目を瞑って3分で出来たりする。

サービスそのものも,利用者の方々のおかげで,開発快調治安良好トラフィックは安定的に成長しているという理想に近い状態にある。

収益目標達成というのは,まともに稼げていないという点以外はほぼ完璧デライト完全無欠にするための挑戦だ。それも,決して非現実的目標ではなく,見通しは明るく,時間は十分にある。しかも,超低経費のおかげで,仮にずっと稼げないままでも開発者が生きている限り潰れる心配は無い,ときている。

華々しく成功しているように見えるサービスのほとんどは,人間的金銭的技術的な何らかの問題を抱えながら運営されている。それを考えれば,まだ成功と言うには早いが,「デライトが目指す成功に最も近付いているのはデライトである」とは言える。


……昨日,早くも3日目にしてサボってしまった一日一文だが,今日は取り返そうと少し長めに書いた。

気合い空回り疲労のせいか,思っていたよりくどく,何が書きたかったのか分からない文章になってしまった。お目汚しだが,開発者デライト現状をどう見ているかの参考までに残しておく。

{希哲15年4月10日の開発}{単純な実装}{動的切り替え}{省略表示}{希哲15年4月10日の進捗時限}{希哲15年4月10日の進捗}{希哲15年4月10日}{凝り過ぎ}{出振るい済み}{1ページ目}...=}(39)

{希哲15年4月10日3歩 K#F85E/A-E74C-22BD}

前後景輪数表示不具合修正のついでに,吹き描き前後景部省略表示導入した。

吹き描き前後景部前後景輪10輪を越えた場合に,省略記号...)を表示し,前後景輪一覧2ページ目への輪結とした。

これまで,省略されていても特に表示が変わらなかったため,初見では把握しにくかった。また,省略された輪郭を見たい場合に,いったん1ページ目を開いてから2ページ目に移動する必要があった。

問題としては当初から認識していたが,今回の方法に近いことは昨年考えた希哲14年6月30日の開発後でいったん白紙にして動的切り替え検討する希哲14年7月18日8歩など,仕様複雑化してなかなか実装に入れなかった。

無くても何とかなっていたことではあるので,あまり凝り過ぎず,とりあえずは最も単純な実装採用することにした。

出振るい済み

{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 に利用出来ず,修正作業でよく二度手間が発生していた。

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

未出振るい

=}
{希哲15年3月30日の開発}{希哲15年3月30日の進捗時限}{希哲15年3月30日の進捗}{希哲15年3月30日}{見出し記法}{デラング}{仕様検討}{装体}{検討}{進捗記録}...=}(22)

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

デラング見出し記法仕様検討

見出し記法に関しては,アスタリスクの数と見出し要素階層を合わせる単純な実装検討していたが,実際の階層の深さによって装体を変えることも検討に加えた。

つまり,第一階層を最大の見出しとして表示するのではなく,第二階層・第三階層と階層が深くなるにつれ上位階層の装体を大きくした方がいいかもしれない。階層と装体の関係が固定されていると,短い文章の中でちょっとした見出しが欲しい時に大袈裟になってしまう。更に,小さな装体のために上位階層を飛ばした見出しが作られると文書構造上の問題がある。

最初に現れた見出しを最上位階層の基準にすれば文書構造上の問題は解決出来るか。

装体を可変にするのは直感的ではないかもしれないために留めておく。特に,文書全体を見なければ階層の深さが分からないのは大きな欠点か。

=}
{実装}{じっそう}{}{}{素描}
{}