{少し変える}{当てはめる}{常識を変える}{最初の葛藤}{動揺させている}{とんとん拍子}{見合っている}{成功の大きさ}{意味している}{事の大きさ}...=}(93)

{希哲16年5月19日の日記 K#F85E/A-E74C-1B04}

昨日脳爆発気味だったせいか,少しぼーっとしてしまった。それなりに収穫大きかったので仕方ない


ここ一週間ほど,また少し心境の変化感じているやはりデライトの歩み」のせいだろう。あの文章書きながらこれまでの達成重みをより強く感じるようになった。それは良いが,これからの達成もより重く感じるようになった。

サービス経営観点から言えばデライトの問題はいま,用者数が伸びないことだけに絞られている。それ以外は限りなく理想に近い状態にある。つい先日まで,この問題新生デライトの完成解決するだろうとほぼ確信していたつまり新生デライトの完成デライトの完全な成功そのものだと思っていた。そしてそれは,希哲館事業未曾有の成功収めることを意味している

ただ,これまでの歩み振り返っているうちに,少し不安になってきたわずか15年事業で,そんな成功ありうるのだろうか。事の大きさ考える非現実的な早さだ。成功の大きさ苦労見合っている全くしない作り話のようなとんとん拍子だ。

書きかけではあるが,あの文章書いたことが,思いがけず自分動揺させている

理論技術として完成させられるかどうかは時間の問題だと考えていた本当の問題その先にあった。地動説にせよ進化論にせよ,世界の見方大きく変える考えには無理解反発付き物だ。常識を越えた考えであればあるほど,その大きくなる(後略)

確かに最初の葛藤陥いった原因は,輪郭法理論技術として完成させることの難しさではなかった。常識を変えることの難しさだ。これを現状当てはめれば,新生デライトの完成過信してはいけない,ということになる。

だからといって,やること大きく変わるわけではない。一日一文想定以上時間を割いたのも,この理屈でいえば正しかったことになる。ただ,心構え少し変える必要があるのかもしれない。

{知能増幅技術}{希哲16年5月の一日一文}{知能増幅メモサービス}{知能増幅}{叫び続けている}{大きなビジョン}{願って}{気付いてくれる}{本当の可能性}{一人でも多くの人}...=}(276)

{“知能増幅メモサービス”はなぜいま最も重要なのか K#F85E/A-E74C-CDB9}

人工知能仮想通貨暗号通貨仮想現実仮想世界……等々様々な分野世界的な注目を集める中,これらを凌ぐ潜在力あるにもかかわらずまともに語っているのは私だけなのではないか,と思えてしまう分野がある。それが「知能増幅IA: intelligence amplificationだ。

知能増幅というのは,文字通り工学的に人間知能増幅させることを指す古くからある研究分野だが,人工知能などに比べてその話題性著しく乏しい参考。この言葉に「人体改造」に近い響き感じる多いだろう。実際脳にチップを埋め込む遺伝子を書き換えるといった人体改造的な研究これまでの主流で,まず倫理的課題大きかった倫理的課題大きければ技術的課題解消するための実験などもしにくく,実用段階にある技術存在しなかったデライト登場するまでは古典的な SF域を出ず,語れること大して無かったわけだ。

先日の「デライトの使い方の考え方」で少し触れたように,デライトは,その知能増幅誰でも簡単に触れるメモサービスとして実現した知能増幅メモサービス」であり,「世界初の実用的な知能増幅技術」だ。どのように実現しているかはあの文章ざっと書いたので,今回は,この知能増幅メモサービス意義について書いてみよう思う

知能増幅の世紀

私は,ビッグ・テックGAFAM などと呼ばれる世界最大の企業群Google, Apple, Facebook, Amazon, Microsoft合併して「Microappglezonbookマイクロアップグルゾンブック」となり,自分がその経営思うまま出来たらどうするか,という思考実験をすることがある。答えいつも変わらないiPhoneGoogle 検索Windows も,世界最大の SNS世界最大の通販サイトも,何もかも売り払って知能増幅メモサービス開発全てをかける

最近何かと話題イーロン・マスク氏と入れ替わったとしても,やることは同じだ。テスラSpaceXTwitter も,何もかも売り払って知能増幅メモサービス開発全てをかける。ちなみに,氏の事業一つには,まさに脳にチップを埋め込む系の知能増幅技術扱うニューラリンク」があるものの,やはり,他の事業ほど目立った成果もなく,あまり知られていない

つまるところあらゆる分野の中で,「知能増幅」が群を抜いて大きな可能性持っていると私は考えている。これを多くの人理解すれば,21世紀間違いなく知能増幅の世紀」になるだろう。世界初の実用的な知能増幅技術であるデライトは,その嚆矢だ。

知識を生み出す技術

長い前置き似合わず知能増幅メモサービスなぜいま最も重要なのかという本題は,拍子抜けするほど単純明快な話だ。知識最も価値を持つ時代において,最も価値のある知識は「知識を生み出す知識」であり,最も価値のある技術は「知識を生み出す技術」だからだ。まさにそれを研究開発するのが知能増幅という分野だ。そして,知能増幅メモサービスは,最も実現性の高い実際にデライト実現している知能増幅技術なのだ。

例えば人工知能がいかに発達しようと,それを開発管理利用していくのはあくまでも人間だ。人間愚かなまま機械だけが賢くなっても,人間社会にとってのボトルネック必ず人間の愚かさになる。知能増幅技術は,人間あらゆる知的活動最も根源的な部分から持ち上げる技術であると言える

……と,この単純明快な話を私がしたのは,昨日今日でもなければ一度や二度でもない昔から何度端的に語っても意図するところ伝わった試しがない。どうもピンと来ていないというのか,大体反応が「なるほど,で?」という感じだ。理屈なんとなく理解出来ても,それが意味すること大きさ想像出来ていないのだ。その大きさ先に書いた理由だ。

節穴

思えば,この“ピンと来ていない感じ”というのは,「個人知識管理PKM: personal knowledge managementとして認知されつつある分野感じるものと似たところがあるその名の通り個人自らの知識効果的に管理することに関してすでに色々な方法論技術集められている。その代表的手段として「メモ」があり,メモアプリメモサービスなどと呼ばれるものも盛んに研究開発されている。

このメモサービス知能増幅結び付けたのが「知能増幅メモサービス」というデライト位置付けだが,これが,私が思っていたより変わった発想だったらしい,とデライトの宣伝始めてから気付いた個人知識管理技術発展させていけば,それは当然知能増幅繋がる。この単純な発想が,意外にも共有しにくい。「デライトではこんな新しいこと出来る」と言っても,「なるほど,でも○○間に合ってるから」という反応受けることが多かった。そこには,想像していたよりずっと大きな温度差があった。

このあたりの分野よくよく観察してみると,開発者にせよ愛好家にせよ,そこまで大きなビジョン持っているほとんどいないことが分かる要は,「生活術」とか「仕事術」とか「ライフハック」の範疇でしかとらえていない個人知識管理知能増幅繋がり,それが世界を変える,なんて大それたことを考えている人間は,全くいないわけではないだろうが異端者だ。

私の立場からは「節穴同然眼力」としか言えない分野体たらくだ。「趣味の問題」で済むでもない。そう思ったとしたら,ここまでの理解出来ていないか,想像力があまりにも足りないただただ一人でも多くの人がこの分野本当の可能性気付いてくれることを願って,私は叫び続けている


{希哲16年4月6日の開発}{希哲16年4月6日の進捗}{領当てが崩れる}{足りず}{然るべき時期}{ごつい}{ボタン装体}{もともと}{過度に}{重々しく}...=}(101)

{希哲16年4月6日16歩 K#F85E/A-E74C-04AD}

進捗時限記録中略

フォーム部品装体調整デライト扉装体調整

一段落したため出振るい手定めして終了


まず,2日の開発思い付いた全知検索ボタン改良案導入した装体調整前

この検索ボタン装体は,もともと全知検索演算子連動させることを考えていたため,入力欄切り離したようなデザインになっている。一体感ボタンとしての分かりやすさ両立させたもので方向性としては悪くない。ただ,若干無駄があった2日の開発合体選り手同じ見せ方使えそうなことに気付き,これでまとめた

全知検索窓デライト最初期作り込んだ部分だったため,基本的にフォーム部品はこの装体間に合わせ継承していたが,全知検索窓以外では過度に重々しく見える問題があった先日描出ボタン改良好感触得たため,汎用的なボタン装体はそれに合わせてまとめることにした。

ボタン装体軽くなったことで全体的な釣り合い変わったため,一通り関連する装体調整行った設定ページ装体調整前だいぶ良い感じになったが,特に装体調整前大きく洗練されたこれまでの重々しくごつい印象が,だいぶ軽く柔らかく見えるようになった。スクリプト挙動おかしい所もいくつか修正した

新生デライト完成目前丁度良い然るべき時期出来て良かった


下見アイコンもここで出振るい出来た

足りず領当てが崩れることに気付いたため,幅狭領当てでは字数計をいったん非表示にすることにした。

{希哲16年4月5日の開発}{希哲16年4月5日の進捗}{CSS 変数}{生み出した}{伝証}{合理化した}{呼ぶべき}{汚い現実}{ウェブの理想と現実}{もたらされる}...=}(208)

{希哲16年4月5日14歩 K#F85E/A-E74C-6431}

CSS 変数(カスタムプロパティ)の導入舞覧ブラウザ五年対応原則採用決め終了今後デライトでは,「5年以内離立された版存主要舞覧」を中心に対応していく

希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義考えてはいたが,当時は,古い舞覧対応努力はするが推奨はしない程度の,もっと緩やかなものを想定していた


希哲13年ECMAScript 2015HTML5CSS3比較的新しいウェブ標準導入決めてからだいぶモダンにはなったが,まだデライトの舞覧対応方針には感覚的保守的なところがあった。感覚的に影響範囲の広い付徴主要舞覧対応から10年影響範囲の狭い付徴5年目安導入考えていたrem ですら必要以上には使わなかった

先日前次記法実装グリッド領当て導入したが,これはちょうど主要舞覧使えるようになってから5年ほど経つ機能だった。一記法装体過ぎなかったこともあり,ここまで辛うじて良かったが,他にも色々応用したいことが出てき舞覧対応方針見直し必要を感じていた

決め手は,デライトのダークテーマ対応見据えて CSS 変数の導入考え始めたことだった。CSS 変数主要舞覧対応から5年ほど経つが,本格的に導入するとなると影響範囲広がり過ぎる


Can I use対応舞覧よく調べるようになってから,「5年以内離立された版存主要舞覧」が意外に普及していることに気付いた大体90%以上はある。

地域にもよるだろうが,確かに今時古い舞覧使い続ける方が難しいかもしれない。個人機なら5年平均的な買い替え周期であり,スマートフォンなら古い部類だろう。自動更新標準的になった昔と違って多数派の“普通の人”ほど新しい舞覧使っている

あえて古い舞覧使い続ける場合というと,一昔前なら古い個人機再利用というのがあったが,格安インターネット端末普通に流通している今,新しい舞覧使えないほど古い端末使い続ける費用対効果疑わしく,制危考えれば推奨出来ることではない

一番面倒なのが舞覧の更新許されない企業内利用だが,そもそもそんな保守的な環境デライト利用出来るとは考えにくい

こう考えていくと,デライトにとって古い舞覧への対応重要性極めて低い言わざるをえない

奇しくも新生デライトの完成目指している6月15日に,IE11 のサポート終了がある。中途半端気もする内容だが,いわゆるモダンではない舞覧最後の砦崩壊する新しいウェブ標準への社会的移行象徴的な出来事にはなる。


ある程度古い舞覧への対応考慮してきたのは,企業体力がついた将来対応拡充することを考えていたからだったが,これもよく考えると合理性怪しい

技術的負債”は簡単に返せるものではない。大企業肥大化した交度にいかに苦しめられているかを考えれば合理的に古い舞覧への対応出来る来るかどうかも分からないむしろ組織大きくなった時にこそ見通しの良さ重要になる


もっと根本的なこと言えばデライトウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準普及牽引していくくらいの考えがなくてはいけない。

その伝証デモ足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。


舞覧五年対応原則導入によって,ウェブの理想と現実における汚い現実大部分だった古い舞覧正しく切り捨てることが出来るようになり,前縁整備はもちろん,デライト文書整備でも大きな効率化もたらされるだろう。文書整備では,対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明すっきりする

デライト開発劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則デライト正式離立という大きな節目目前にして生み出したものだった。


=}
{新生デライト}{上手くまとめる}{一定の水準}{大きな印迫}{暫定実装}{争っている}{具体的な作業}{大きな当努}{合間合間}{どうであれ}...=}(113)

{希哲16年4月3日の日記 K#F85E/A-E74C-2AE0}

のんびり作業しながら開発組計について整理した最近の脳爆発でまた混沌としてきた頭の中がだいぶ整理出来脳疲労感一気に和らいだ良い休日の過ごし方だ。


まず,第四次宣伝攻勢は,遅くとも黄金週間初日29日には始める多少の助走期間欲しいので,下旬出来るだけ早い内始めたい。その前に新生デライトの完成,と行きたいところだが,やや無理がある無理をして不眠不休やれば出来ないこともないだろうが,今のところそこまでの必要感じていない

無理のないところで,6月までの新生デライトの完成目指すことにした。ちょうど6月まで様子を見ることにしていたが,新生デライトさえ出来れば収益どうであれどうとでもなる。これが現状の最適解だろう。

宣伝認知されてから実際に流入始まるまでには多少の時間差もある。第四次宣伝攻勢前には,新生デライト当努のうち,訴求効果必要性高いものを優先して詰め込む

こまごまとした問題合間合間片付けるとして,大きな当努では,まず輪郭選り手抜控機能整備片付けたい今のところ最も長く中途半端なまま引きずっている当努で,心理的負担大きい先日終えた Aejs 整備目的でもあった。KNEST 隠し実装昨年から中断しているが,これは具体的な作業がほとんど出来なかったため,状態としては他の当努大差ない

その次は,Aejs 整備の再開前の Cμ 文字列処理改良り,1月29日12歩決めた通り,続いて描写渡括実装入る。さらにその次の優先順位をめぐって頭の中争っているのが,輪郭小窓暫定実装公開設定機能部分実装だ。どちらも用者体験にとって大きな印迫がある。集客する以上,高速化文書整備デラング整備一定の水準以上に進めておく必要がある

これらを黄金週間前に上手くまとめることが当面の目標になりそうだ。

{デラング}{進捗記録}{数式記法}{軽量標記言語}{越化参照}{希哲16年2月4日の開発}{希哲16年2月4日21歩}{良い代替案}{深く考えず}{変更する}...=}(139)

{希哲16年2月4日17歩 K#F85E/A-E74C-503B}

進捗時限記録中略

デラング整備越化記法越化参照疑似実体参照についての検討終了

越化エスケープ基本的な仕様について記法内部実装両面から急速にまとまった

単一文字越化

まず,バックスラッシュ使った単一文字越化では,全ての文字越化することにした。ただし,この「越化」は,「通常とは異なる特殊な解釈試みること」であり,論組言語等でのそれと同様必ずしもデラング記法としての解釈避けることではない。

非特殊文字扱い

軽量標記言語単一文字越化対象非特殊文字に付けた場合の挙動としては,「不明なエスケープシーケンス」などと違了出すわけにはいかないので,以下の2つ考えられる

普段非特殊文字にあえて越化文字を付けてみることなどないので,一般的にどう実装するものなのか分からなかったが,特に定石があるわけではなさそうだ。

当初なんとなく前者想定していたが,この場合,全ての特殊(になりうる)文字予め定義しておく必要があり,挙動変則性用者混乱させる懸念もある。デラングの場合は文脈によって特殊文字になったりならなかったりすることも多いため,その対応も含めるとかなり複雑化してしまう。

後者の方が分かりやすいといえば分かりやすく,先日交度記法出来た代置子方式応用すれば実装単純化出来る。数式記法などでは越化対象文字判別する必要があるが,これは代置子への置換処理の前に制御子置換すればいい。

いずれにせよ後から変更するのが難しい仕様ではないので,まずは実装単純性を取るべきだろう。

数式記法との整合性

越化記法との整合性深く考えずLaTeX 方面の慣習従い導入した数式記法\[ ... \]\( ... \) をどうするかという問題に少し手間取った

これまで越化記法も「デラング記法としての解釈避ける」ためのものとして想定していたが,ここで本来越化という概念立ち返り,「通常とは異なる特殊な解釈試みる」ためのものとすることで整合させることにした。

越化参照

単一文字越化で「越化」という概念捉え直した結果,これまで Dex で「疑似実体参照」と呼んでいたものを「越化参照」として再定義することが出来た。

これに伴い,疑似実体参照では &_foo; としていた記法を,越化直感的に分かりやすい &^foo;統一することにした。代置子&^[連番];,「制御子(ここで命名&^[名前]; となる。

越化用の代置子に関しては &^1; などと書き分けるかと考えたのとほぼ同時に前述越化概念拡張があり,そもそもこれまで「疑似実体参照」と呼んでいたものが越化列役割同じであることに気付いた

参照先実体があるわけではないので「疑似実体参照」という名称にはずっと違和感があったものの,良い代替案見つからなかった。これで越化記法課題同時に解決してしまった。

{進捗記録}{希哲15年12月21日の開発}{円滑な移行}{熟れてきた}{仕切り直す}{構想段階}{大きくなってきた}{SLFS 環境}{再現性の低い}{本格的に検討}...=}(61)

{希哲15年12月21日4歩 K#F85E/A-E74C-B8F6}

SLFS 開発手法についての検討終了

主力機更新本格的に検討するようになり再現性の低い SLFS 環境問題がより大きくなってきたため,円滑な移行のためにも SLFS整理急ぎたい。ここで,構想段階のまま中断していた SLFS 0.003お蔵入りにし,SLFS 0.004 として仕切り直すことにした。

SLFS 実機フジ型場当て利用するつもりだったが,やはり試行錯誤実機でするのは負担が大きい仮想機利用するのも出与え管理などをどうするかという問題があった。

この際親環境SLFS 実機との完全な出与え共有考えず1つSLFS 仮想機を作りそのフジ型場当て実験繰り返し,構築手順熟れてきたところで SLFS 実機再現試みることにした。この時にもフジ型場当て重要なので,親子二重利用することになる。

現行SLFS 環境混沌としていて移植しにくいため,作業用Linux 出来採りとして先日救出用 DVD採用した Slax使うことにした。

=}
{先日}

{}