{希哲17年1月19日の開発}{希哲17年1月19日の進捗}{希哲17年1月19日}{時間をかけてしまった}{確認出来た}{過去の自分}{置き換えられた}{これほど}{再評価し始めた}{そんなもの}...=}(253)

{希哲17年1月19日14歩 K#F85E/E74C-3191}

進捗時限記録中略

highlight.js版存更新終了

10.6.0 からスクリプト最新版11.7.0 へ,Zenburn装体書最終版10.7.3上げた出振るい手定め済み

希哲15年7月18日10歩更新検討したが,当時対応言語検証必要判断し見送り,以来そのままだった。約2年前版存なので,流石に対応言語云々より弊害の方が大きいだろうと更新決めた

作業自体あっという間に終わる見込んで昨日深夜着手したが,最新版従来の Zenburn事実上消えていたため,カラーテーマ検討時間を取られてしまった散々考えた結果Zenburn最終版利用して現状維持とすることにした。

カラーテーマ検討

最新版Zenburnstyles/zenburn.min.css から styles/base16/zenburn.min.css移動していた上に,従来とはほとんど別物になっていた様子Base16 になったからなのか事情よく分からないが,読みにく過ぎるのでいずれにせよ使い物にならない

気になる部分装体上書きして調整出来なくもないが,そこまでするならデライト独自カラーテーマ作りたくなってくる取り急ぎ代替テーマ探すことにした。highlight.js 導入時それなりに時間をかけ検討した希哲15年3月9日11歩ので,当時の記憶からある程度見当付いた

読み込み中...
=}
{希哲17年1月16日の副日記}{この手の}{埋め込み献典}{検討しておく}{発生しうる}{客体変数}{無駄な通信}{タグ削除}{通信時間}{従来の方式}...=}(242)

{希哲17年1月16日の開発 K#F85E/E74C-6ADB}

作業方針検討4歩閲覧専用模動実装検討5歩デラング整備埋め込み記法処理改良8歩13歩

埋め込み記法処理改良

これまで埋め込み記法処理の中でも oEmbed利用したものについては,Dex 内で埋め込み交度取得直接描写 HTML埋め込んで返していたが,埋め込み交度取得処理専用 API /mbd委ね前縁 Aejs から利用することにした。結果として応答速度改善成功した

埋め込み記法+[URL]URLoEmbed必要とする場合Dex では適当な分類名付与した <div>出与え属性URL埋め込んで描写 HTML返すAejs ではそれを検知し,URL/mbd転送する/mbdURL対応したサービス埋め込み交度oEmbed取得して返す,という流れになる。過剰な立求抑止するため,Aejs には簡易的な隠し持たせておいた

想像していたよりすっきり実装出来た


そもそもきっかけは,先日の SlideShare 対応だった。oEmbed必要になったので,埋め込みツイート使っていた Dex 内の oEmbed 埋め込み方法取り急ぎ使った。ただ,記法処理範枠同期通信処理組み込むというのは正気の沙汰ではないなんでこんな実装になっているのか,引っかかりはあった。

KNEST 隠し使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状そこまで最適化する必要時間も無い出来たとして,隠し有効利用出来る握接パターン限られているいずれにせよこの種の埋め込み記法利用増えてくれば破綻目に見えている。ということで,いったん埋め込み処理前縁移すことにした。

読み込み中...
{デライトに熱中しながら周囲とデライトを共有しようとしない人}{輪郭整備}{目的を果たした}{書きつつ}{世界を一新する}{逆算する}{潜在市場}{違ってくる}{求めるもの}{レイトマジョリティ}...=}(228)

{希哲17年1月9日の日記 K#F85E/E74C-D79B}

いよいよ脳爆発本格化したようで,四方八方拡がる思考の整理時間がかかっている収穫は多いが,脳疲労感隠せなくなってきた


当努整理組計整理大きく進んだが,デライト市場戦略についての頭の整理進んだのが特に大きかった

昨日の日記書きつつ,「デライト熱中しながら周囲デライト共有しようとしない」の最たる例としての自分自身について考えていた公開しているのだから見られて困ることは書いていないが,それと積極的に見せたいかどうかは別問題だ。重用者であればあるほど,デライト扱っている情報は,現実の人間関係にとって深過ぎる重過ぎる

ここでイノベーター理論対して抱いていた疑問氷解し始めた

最近,「デライトのキャズム」という表現使っていたのは,イノベーター理論でいう「キャズム」とは違うデライトにはあるのではないか,と感じていたからだ。これは恐らく正しかったデライトのキャズムは,アーリーアダプターアーリーマジョリティではなく,イノベーターアーリーアダプターにある。典型的なイノベーション大きく越えているデライト独自性が,キャズムイノベーター側に引き寄せてしまっている

物珍しさデライト使ってくれるイノベーターなのであって,趣味嗜好特殊性から比較的孤立しており,そもそも潜在用者への影響力期待出来るではない。影響力を持つのはアーリーアダプターであり,デライトこれから獲得しようとしているだ。私はここを少し混同していた。そして,アーリーアダプターというのは実利重視するだ。

イノベーターどれだけ喜ばせても,それだけでは横の広がりにはならない。誰よりもデライト価値を見出している私自身証明するように,デライトではなおのこと内にこもりやすい。周囲共有出来ないようなものをいくらネット宣伝しても,縁遠い誰かがよく分からないものについて語っているとしか思われない

読み込み中...
{輪郭整備}{希哲17年1月7日の開発}{希哲17年1月7日の進捗}{希哲17年1月6日の開発}{抑止する}{数十分}{損ねている}{無反応}{ほとんどの要素}{採用出来ない}...=}(210)

{希哲17年1月7日20歩 K#F85E/E74C-370E}

進捗時限記録中略

知名欄描写欄捕活フォーカス関する仕様検討結果ともにマウスオーバー捕活する仕様確定実装した出振るい手定め済み

なお,知名欄自動全選択については正式に廃止決定した


仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活全選択描写欄では捕活,という方針だった。これは実用上の都合というのも大きく,こうでなければ単純に描出効率悪かった

昨年9月までの第二次用合い改良中の交度整理で,知名欄捕活全選択機能しなくなっていた。これは確か中景輪符事象イベント改良したことで干渉懸念があり,再実装後回しにしたという経緯だった気がするもっと地味な描写欄捕活過去に何度か再実装した記憶があるものの,どの時点機能しなくなっていたのかは曖昧だが,いずれにせよ第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた

もしかしたらこれはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率重要な作業になると,クリックでの捕活やはりまどろっこしく,鈍重感じる。そこで最近はかつての挙動復活させる機会窺っていた

懸念は,他要素他機能との干渉誤操作だったが,これは昨日の検討から急速に氷解した今のデライトで,マウスオーバー捕活移動すること自体前提のようなところがあるので用者体験大きな悪影響はないだろうということ,むしろほとんどの要素マウスオーバー反応するのに知名欄描写欄無反応なことが直感性損ねているとも言えること,スクロールとの干渉実際の舞覧ブラウザでは生じないこと,誤編集問題については,そもそも閲覧編集用合い切り分けていることが一定の保護機能になっており,更に取り消しボタン変更有無分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した

そこでまず,知名欄全選択含めてマウスオーバーでの捕活機能復活させてみたところが知名欄全選択については数十分廃止決定することになった。実装上の問題としては,選択状態やはり周辺要素干渉する干渉しないようにマウスアウト解除すると,今度は選択状態意図せず解除されやすくなる。もっと問題なのは,誤入力上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態好都合だが,知名欄での利点写し取り素早く行えることくらいでさほど大きくない

これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても熟練用者向け過ぎ採用出来ない

次に知名欄全選択機能し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら編集軽快感明らかに向上している捕活さえしてくれれば Ctrl + A写し取り十分効率的に行える今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時発生するスクロール意図しない場合多く考えられるため抑止する

どこまで普遍的な現象分からないが,常用している LinuxFirefox では,<textarea>選択状態残して捕活解除すると,再選択のつもりが未捕活状態のせいで)意図しない文字列ドラッグ発生しやすいため,これがなくなったのは個人的に嬉しかった近頃多用している複数輪符引き入れ欄への写し貼り障害になっていた。

とにかく第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった

{<script>}{希哲16年12月19日の副日記}{付かない}{https:}{ツイートの埋め込み交度}{不正出与え修正}{〈delloon〉}{添えて}{新しかった}{兼ねさせる}...=}(192)

{希哲16年12月19日の開発 K#F85E/E74C-E210}

自我ページ風船輪郭

長いこと課題だった自我ページ風船輪郭について良い閃きがあり,急速に実装方針まとまった

現状自我ページURL のみ正規化している/KNo.XXXX内容単なる自我知番での検索結果であり,プロフィールページとしては貧弱過ぎる自我輪郭などのはあったが,既存機能領当てとの整合性をとるのが難しく,自我ページとしてはなかなかイメージまとまらなかったかなり難航しそうだったため,新生デライトの要件にも入れなかった

最近の大輪郭整備必要性強く感じるようになっていたこともあり,もう少し現実的に低コスト実現出来るまとめてみることにした。

まず,他自我内検索用合い既存の自自我内検索整合させるため,以下のように,自我アイコン並べる重ねるかして,& ボタン段階的な切り替え出来るようにする。さらに,自我アイコンの下に「○○さん K#XXXX の描き出しです。」と表示する

これで,全知検索機能性そのままに,プロフィールページ最低限必要アイコン名前表示出来る自我アイコン複数表示自体かなり以前から他自我内検索用合いとしてあったが,これに名前添えてプロフィールページ見出し兼ねさせるというアイデア新しかった

大した作業ではなく,新生デライトの完成遅れ今更なので,これは新生デライトの要件追加することにした。

読み込み中...
{希哲16年12月18日の副日記}{小さく感じる}{越化参照化}{復活させた}{いったん無効化}{なくはなかった}{用合い上の問題}{反映されていた}{知番表示}{生成していた}...=}(253)

{希哲16年12月18日の開発 K#F85E/E74C-8AE4}

新生全知検索整備中間出振るい

領下手定め環境概ね問題なさそうだったため,新生全知検索整備中間出振るい踏み切った首尾良く完了し,大成功だった。これにより後縁最新の状態同期され自由自在開発体制取り戻した

21時30分出振るい作業開始断帯21時30分から約5分23時頃までには一通り点検不具合修正終えた

その後動作極めて安定しているdg_fnd() への輪数取得処理組み込み今回初出振るいとなるが,高速化効果は,毎回輪数計算必要になる場合検索数十ms求頼1回分短縮なので体感速度向上あまり期待していなかったしかし意外と検索時軽快感増している気がする最初はプラセボ効果近い開発者心理かと思ったが,自分の全知検索歴検索頻度考えれば感じ取れてもおかしくはない嬉しい誤算だった。

輪符知番輪結改良

安心して後縁手を入れられるようになったので,手始めに輪符生成する輪結で,第零番節付き知番そのまま輪結先などに反映されてしまう問題修正した

これにより,輪符知番K#9-XXXX/A-YYYY記述されていても,輪結先第零番節の削除をした /?fg=KNo.XXXX/YYYY/KNo.XXXX/YYYY となる。第二次知番改良経て司組生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符第零番節付き輪結生成していたため,クロール効率への悪影響懸念された出与え属性通して輪郭小窓知番表示にも反映されていたため,用合い上の問題なくはなかった

とりあえずは量が多い基本形輪符重い強調輪符でのみの対応

読み込み中...
=}
{描写}{大輪郭整備}{知番}{知名}{希哲16年12月14日}{説明出来る}{大きな障害}{軟らか過ぎず}{硬過ぎず}{狭過ぎず}...=}(193)

{希哲16年12月14日の日記 K#F85E/E74C-B161}

ちょっとした用事片付け第二次快調期からまともに出来なくなっていた書類整理少し進め,あとは大輪郭整備考え事をして過ごした


考え事での大きな収穫として,文書整備かかわるデライト用語体系方針まとまった

デライト用語体系関しては従来の輪郭法新用語体系基礎に,初心者向け分かりやすい代替用語導入などを検討していたが,これはやめ基本的に新用語体系そのまま踏襲し,説明体系洗練させていくことにした。

例えば知名を「輪郭名」,知番を「輪郭番号」などと説明することを考えていたが,元々技術としての固有性独立性高い知番関しては早々に断念していた。「輪郭名」などを補助的に導入するかどうかで最後まで迷っていたのが知名だった。この問題考える上で,「知名」という用語妥当性についても再考する必要があった。

知名」の必然性について直感的な確信はあったものの,言語化意外と難しかった。それを象徴するかのように,いつからか輪郭知名」の選り手開きっぱなしで,再描出下書き抜控一覧実装した頃から常に表示されている唯一の輪郭になっている。

知名単なる記事名」でも「題名」でもなく,森羅万象付けることが出来る認知上名前であり,その性質既成語では表現出来ない更に,「輪郭の名前」として輪郭従属するものではなく,あくまでも知の名前」として理解される必要がある。そうでなければ,そもそも輪郭目的として扱っているのか分からなくなってしまうし,自己目的化しかねない。ここに知名という用語必然性がある。輪郭とは,知の名前知の番号そのもの具現化するものだ。

この方向説明体系洗練させていけば,代替用語複雑化招くだけのものになる。「急がば回れ」で,多少時間はかかってもデライト正しく理解出来る説明をしていくべきだろう。この点において,特に輪郭」「知名」「知番」「描写」といった基礎用語には動かしがたい正しさ”があり,それは十分わかりやすく説明出来るようやくその確信持てた

読み込み中...
{輪郭整備}{SNS}{希哲16年11月24日}{希哲16年10月}{振り返り日記}{日記}{Twitter アカウントの削除}{眠たくなる}{外務帰り}{蒔ける}...=}(159)

{希哲16年11月24日の日記 K#F85E/E74C-DFA1}

一夜明けて特に未練無かったので,ツイストの無期限停止と,それに伴う Twitter アカウントの削除決めた

やはりデライトの用者体験向上し過ぎて,他のサービス全く気が向かない,ということに自分で気付いてしまったのが決定的だった。この調子では今後もツイスト優先順位上がりそうにないTwitter関しては拡散力といってもデライトとの相性による限界もあり,蒔けるだけの蒔いたという感覚がある

第二次快調期最高の開発者体験だったが,10月頃から輪郭整備時間増やしたことで最高の用者体験得られたのも大きかった小手先宣伝活動もいいが,ここに唯一無二体験があるという事実示し続けること以上に重要な市場活動無い


今後はデライト開発と,輪郭整備一日一文などでの献典整備ひたすら進めてデライトの完全な成功目指す飛んで火に入る夏の虫というべきか,鴨が葱を背負って来るというべきか,ちょうど世界一の富豪分の良い勝負持ち込んでくれたところだ。これに勝てば世界がひっくり返る

その希望外部サービス依存せず持てていることに大きな成長感じた同時にツイスト役目を終えたことを悟った希哲12年1月17日考案してからおよそ5年ツイストのある生活デライト育てた

多くの人SNSロックインされ,独自の価値持った新しいサービス育たない中にあって,発信力だけ利用して自サービス蓄積出来た戦略としての正しさ再確認したツイストをしていなければ出会えなかった人多いし,普通に SNS利用していたSNS同化してしまっただろう。


解放感達成感によるものか,から晴れ晴れとした気分で,顔色非常に良かったそもそも SNS という性に合わないものなんとか利用するための折衷案ツイストであり,それ相応精神的負担だったのだろう。

読み込み中...
{輪郭整備}{希哲16年11月6日}{振り返り日記}{日記}{定休日}{喜んでもらえない}{開けそう}{新しい道}{二方面}{考えていたこと}...=}(125)

{希哲16年11月6日の日記 K#F85E/E74C-5CA2}

定休日なので輪郭整備をしながらのんびり過ごした

非常に収穫の多い気分転換として輪郭整備時間を割くようになったが,やっているうちにむしろこれこそやるべきことなのではないかという気がしてきた

もともと輪郭量対して輪括量描写量少な過ぎるという問題があったが,優先順位問題でなかなか本格的な輪郭整備進まなかった第二次快調期経て描出効率発信能力飛躍的に向上し,十分な時間対効果期待出来るようになっている。

もう一つ他用者への波及効果意外と大きい感触がある。やはり,私自身活発に描出しているかどうかで他用者賑わい違う気がする。この用者の少なさ一番重用者なので,当然といえば当然だ。

開発に没頭していた期間大きな収穫があっても用者の反応乏しいということがよくあり,違和感を覚えていた一つの理由として,そういう時期待欄進捗記録などの事務的な記録埋まりがちで,献典として面白くないということがあったのかもしれない。


デライト市場戦略についての面白い気付きもあった。

先日の日記では,Twitter騒動利用することに関して消極的な見方をしていたが,よく考えるとそもそもTwitter ではない Twitter のようなもの」が失敗してきた理由は,Twitter との差別化出来ていなかったからだ。この場合,KNS としてのデライトの革新性は,障害ではなく近道として機能するかもしれない。積極的に利用することを考えるべきか。

面白いのは,デライトのキャズムについて最近考えていたこととの対比だ。個人知識管理通類用者層意外と保守的であり,大きな変化望んでいない多い。それはメモ自己保存欲求相性の良さから来ているのではないか,と考えていた。先述の用者の反応乏しい問題にも通じるが,新機能追加しても意外と喜んでもらえない。こうした向けには,印迫よりも安心感与える施策必要なのだろう。

この二方面への売り込み方上手く使い分け組み合わせることで新しい道開けそうだ。

7日振り返り日記

{そもそも}

{}