{希哲16年5月17日の開発}{希哲16年5月17日の進捗}{新しい目印}{変わらなくなった}{目立たなくなる}{動的に}{効果は大きい}{発見しやすくなる}{機能の違い}{自然に学べる}...=}(89)

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

中景輪符改良

輪郭ページ知名選り手以外の知番輪結最大化アイコン追加していったん終了小さい変化だが効果は大きいだろう。

中景輪符知名輪結知番輪結役割動かしようがない旧デルン実装では,知名輪結輪郭ページび,再検索用に ?輪結置いていたが,再検索多用するので直感的な方がいい。輪符における知名知番役割から考えても単純性保ちつつ整合性を取るとこの形になってしまう。問題点として,初心者にはそれぞれの役割分かりにくかった

他方高さ固定解除する方法分かりにくいという問題もあった。最近最大化アイコン使った輪結をどこかに置くことを考えていたが,知番輪結同じ機能を別の輪結持たせる混乱を招く結局知番輪結固定輪結であり特定の輪郭注目する機能兼ねている,ということを自然に学べる用合い望ましい。ということで知番輪結一部であることが分かるようにした。

これによって,知番輪結機能分かりやすくなり,知名輪結との機能の違い発見しやすくなるだろう。

最近の一日一文で,読者高さ固定解除する方法気付きにくいという問題尚更気になっていた動的に解除する手段考えているが,これはこれで先々でも使えるだろう。

第零番節の省略自我知番の省略可能になることで知番目立たなくなるが,これで丁度良い感じになりそうだ。3月31日の開発輪郭ページ前後景検索ページ外観変わらなくなったため,新しい目印としても丁度良い

=}
{新生デライト}{知能増幅メモサービス}{一日一文}{希哲16年4月の一日一文}{森を見て木を見る}{向けた}{研究期間}{科学的な}{粘り続ける}{粘り続けた}...=}(326)

{第四次宣伝攻勢に向けて K#F85E/A-E74C-668D}

デライトは,黄金週間初日となる明日29日4度目の宣伝攻勢第四次宣伝攻勢始めるこれを機に中断していた一日一文」の日課再開することにした。

デライトはいま,包括的な改良構想によって「新生デライト」に生まれ変わろうとしている。今回の宣伝攻勢コンセプトは“新生デライト開発実況”だ。この一日一文含めて開発状況開発者考えなどについて積極的に発信していきたい。

森を見て木を見る

3度宣伝攻勢から得た教訓色々とあるが,4度目の宣伝攻勢目前にしてつくづく感じていることは,結局やってみなければ分からない,ということだ。

ソフトウェア開発やっていると,ここが悪い,あそこが分かりにくいなどといったことばかり考えてしまいがちだ。とりわけデライト新奇見える代物なので,開発者利用者も,“デライトの問題点”について考え込み過ぎる嫌いがある。

問題点地道に改善していくのは当たり前のことだが,問題点ばかり見ていると,「問題があることが問題」であるかのような錯覚に陥りがちだ。問題のないソフトウェアなど存在しないので,これは「木を見て森を見ず」でもある。広く使われている全てのソフトウェアは,それぞれに問題抱えながらそれぞれの役割を果たしている。その全体像見ず問題の大きさ正しく見ることは出来ない

そもそも使いやすい UI分かりやすい文書……などと全て兼ね備えた優等生的なソフトウェア世の中どれだけあるだろうか。使いにくかろうが分かりにくかろうが,バグだらけであろうが,“使う必要”があれば使われる。それが現実だ。ツール文書も,必要ならユーザー作り始める昔からそうやってソフトウェア共有されてきた。

そこに革新性があればなおのことだ。誰でも戸惑いなく使える革新的なソフトウェア──そんなものは夢の中にしか存在しないデライトがそうであれば,私はとっくに世界一の有名人にして世界一の大富豪になっている。冷静に考えれば馬鹿馬鹿しい話だが,知らず知らずのうちにそれに等しいことを考えてしまうのが認知バイアス怖さだ。

最大の課題

デライト普及させる上で最大の課題換言すれば,最も手っ取り早い道筋は何かといえば,デライト目指していること理解してもらい,共感してもらい,必要としてもらうことに他ならない。またこういう文章書き始めた理由だ。

デライトは,よくあるメモサービス出来るだけ近付けた知能増幅(IA)サービス名付けて知能増幅メモサービス」だ。一時期「最も使いやすいメモサービスを目指す最も使いやすい知能増幅サービス」表現していたこともあるが,研究室臭いものになりがちなこの種のソフトウェアとしてはすでに驚くほど簡易的で,その点の達成度決して低くないはずだ。

とはいえ,全く新しい領域目指している以上,新しいやり方理解して慣れてもらうしかない部分どう頑張っても残るデライト初心者戸惑いがちなところは,デライトの目的のためにあえてそうしていることが多い多くの人にとっての分かりやすさだけを基準にして最終的に出来るのは,微妙に使いにくいよくあるメモサービスだ。レーシングカー難しさだけを問題視してオモチャの車にするわけにはいかない。

2年ほど前に公開してから,デライトにはそれなりに多くの人来てくれた例に漏れず大半の人黙ってり,一部の人サービスの問題点指摘して去っていった。私が開発者として一番痛切に感じていたことは,そうした問題点大きく感じさせるほどの利用動機小ささだった。「ここが使いにくい」などと言い残して去っていった人達本当に言いたかったことは,「それでもと使うほどの意義見出せなかった」ということなのだと思う

事実デライト使いにくさ分かりにくさ改善して利用者が増えた試しがない。いま日常的に利用してくれているのは,あらゆる面でいまとは比べ物にならないほどデライト貧弱だった時期に,どこかで私がデライトについて語っているのを見て,その可能性興味を抱いてくれた人達だ。

デライトの意義理解したにとってデライトの問題決して大きくない開発者として,そう確信出来る地点ようやく来られた気がしている。あとは伝え方問題なのだろう。

結局は運

もう一つ,商売において陥いりがちに,「生存者バイアス」としてよく知られた認知バイアスがある。成功例背後にある屍の山に,気付きにくい。そして,成功失敗要因として語られることは,結果論でしかないことが多いデライト成功するもしないも,結局は「」によるところが大きい,ということだ。

例えば,売れっ子芸能人がみんな親しみやす万人受けするタイプかといえば,全くそんなことはない。癖が強く,とっつきにくそう多い。彼らは売れたから「それが良い」と言ってもらえるけれども,同じ特徴持っていても売れずに「だから駄目なんだ」と言われているごまんといる万人受けしそうなタイプならタイプで,売れなければ無個性つまらない」などと言われる。そのは,巡り合わせとしか言いようがない

勝てば官軍ではないが,デライトの“とっつきにくさ”とされていることも,何かのきっかけ話題になってしまえば“面白さ”になりうる。その程度のことでしかないのかもしれない。

結局は運」というのは投げ遣りなようでいて,実は非常に前向き覚悟必要な考え方でもある。粘り強く試行繰り返していくこと以上に成功確かなものにするはない,ということだからだ。奇跡のような偶然も,サイコロ振り直し続ければ必然近付いていく

そしてこのデライト自体,すでにソフトウェア開発における奇跡的な生存例だ。ソフトウェア開発世界では,デライトよりずっと低い目標掲げていても,成功どころか動く物すら出来ず頓挫していくプロジェクトごまんとある。その中にあって,これだけの大風呂敷を広げ,この品質実装運用され,少ないながらも利用者がいて,ちょっとした収益化まで出来ている。こんなサービス世界見渡しても他にない

そんな奇跡がなぜ起きているのか。それはやはり,「粘り続けたから」としか科学的な説明のしようがない。デライト自体は公開から2年越えたばかりのサービスだが,研究期間含める20年近い歴史がある。その全て無駄なくデライト結実している。

味方に付けデライトの成功という奇跡起こすために,ひたすら粘り続ける。これを新生デライトの完成向けた宣伝攻勢所信表明としたい。


=}(1){あれ}
{俗っぽさ}{堅苦しさ}{かといって}{弱過ぎる}{興味を抱かせる}{フォーム全体}{表現出来ていない}{デライト扉の様子・ログイン}{超かんたん無料登録}{円滑に}...=}(51)

{希哲16年4月9日の開発 K#F85E/A-E74C-CAE0}

{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{多段化}{進めて}{後縁の対応}{追加取得}{フラグ化}{確定出来る}{余計な検索}{目に見えている}...=}(109)

{希哲16年4月7日10歩 K#F85E/A-E74C-B300}

進捗時限記録中略

全知検索整備方針検討終了

2月23日頃から検索結果改良について本格的に考え始めていたが,「検索属性」を導入し,検索結果多段化進めていくことにした。

現状例えば括弧類自動付加した検索は出来るが,その出来ない括弧付き描出したい場合括弧無し検索して既存輪郭無いことを確認した後,括弧を付け再検索するということがく,とりあえずこの手間無くしたかった全知検索演算子制御任意の括弧類使える好都合ということもあった。

文字数昇順揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが,上手く行かない場面多々あるので一時凌ぎ域を出ない

将来的な拡張性考える検索結果多段化好ましい風船輪郭輪括内検索にも応用出来る希哲14年7月30日8歩から輪括内検索輪括内のみにすると使いにくいという理由中途半端な状態になっていたが,優先表示解決出来ることに気付いた

整数値揃え兼ねた役割を与え,これを「検索属性」として利用出来るようにする。

ここまでは良いが,効率的な実装難しい単純に全ての検索パターンUNION結合すればひどいことになるのは目に見えている外充て函数余計な検索省くようにする,挿入更新時に確定出来る情報フラグ化しておくといったことに加えて後縁での出力最低限にして前縁追加取得するといった工夫必要になるかもしれない。

いずれにせよ後縁の対応進めて問題ないだろう。設計方針さえ固まれば最適化どうとでもなる

=}
{希哲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 のサポート終了がある。中途半端気もする内容だが,いわゆるモダンではない舞覧最後の砦崩壊する新しいウェブ標準への社会的移行象徴的な出来事にはなる。


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

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


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

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


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

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


=}
{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{積極的な活用}{完成した}{編み出した}{面白いこと}{どちらも}{出来ていなかった}{付加的}{避けられない}...=}(143)

{希哲16年3月12日14歩 K#F85E/A-E74C-2A34}

進捗時限記録中略

今後の Dex 設計方針についての検討終了これから越化参照大活躍しそうだ。


まず,課題だった脚注記法実装方針について検討している内に,越化参照部区間通信活用出来ることに気付いた

部区毎に越化条件変化などがあることから,各記法解釈部区個体任せたい。しかし,脚注記法のように最上位部区との出与え共有必要記法もある。

このような場合単純に考えれば指示体通して部区個体間で変数共有するということになるが,この種の記法増えるたびに目的別指示体増やすのは設計として美しくない汎用的な変数一つ集約するのも,効率性厳密性観点から難がある

ここでふと,越化参照使えることに気付いた下位部区個体中途解釈した記法には目印となる越化参照を付け,上位部区個体変換処理完了させる

これに似た部区間通信手法Dex 初期実装から現 &_skp;使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲広げなかった紆余曲折を経て,これが一番単純性効率性保守性バランスが良いということが分かった

これで脚注記法目次記法実装容易になった。他にも,輪郭情報参照必要記法など,部区間通信必要場面全般越化参照活用出来るだろう。


もう一つ,処理済み対象識別に関しても進展があった。

1月21日4歩で,&_tgt;&_fin; のような目印付加することを考えていたが,付加的越化参照では結局正規表現の複雑化避けられないため,実用化出来ていなかった

昨日終えた客体表現への書き換えDex 初期実装交度整理している時,再置換避けるため記法一部越化参照当時の疑似実体参照置換する手法使っていたことを思い出した。これもあまり積極的に応用範囲広げなかった手法だが,思っていたより合理的であることに気付いた

例えばhttp&_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが,灯台下暗しのごとく単純なこと真価理解するには時間がかかるということを改めて学んだ経験不足だと,どうしてもより高度そうなことに目移りしてしまう。


面白いことに,どちらも原点回帰のような発見だった。

直感編み出した Dex 初期実装手法再評価する十分な経験出来たこともあるが,「越化参照」という概念完成し積極的な活用考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

=}
{使える}

{}