{開発}{『希哲日記』}{日記}{KNS}{デライト}{適度な難しさだから共有したくなる}{知能増幅と人工知能}{希哲17年2月7日}{共有したくなる}{理解し難い}(93)

{希哲17年2月7日の日記 K#F85E/E74C-0C4A}

SNS における Twitter が,個人知識管理サービスにおける Evernote似た位置付けになってきて,「SNS 戦国時代」の訪れ感じる一時停滞感のあった「メモ戦国時代」も再び盛り上がり見せておりKNS たるデライトにとっては最高の状況出来つつある

GAFAM停滞期り,次の時代模索されている人工知能実用化急速にんだことで,かつての人工知能幻想」は鳴りを潜め人間の知能本当の問題であることに多くの人気付きつつある

KNS として,全知検索演心として,知能増幅技術として,この時代課題最も単純明快最も強力な解答提示出来るデライト快調に開発続けているデライト時代ようやく密致しつつあるのを強く感じる


最近Twitter代替として注目されている Nostr興味深眺めているネット受けするのに,分かりやすさ使いやすさ信頼性効率性高度な機能実は必要ない,ということの好例でもある。

既成概念組み合わせである Nostr難しいといっても多少の知識があれば理解出来る共有出来る適度な難しさだから共有したくなる最も知識のあるにも理解し難いデライトとは出発点違うものの,新生デライトの完成目指した全力疾走通過点として,こういう受容のされ方がすぐそこにあるかもしれないと思える

10日振り返り日記

{開発}{開発記録}{}{サービス}{デライト}{デライトはoEmbedに対応している?}{描写下見機能}{希哲17年1月16日の副日記}{この手の}{埋め込み献典}(243)

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

読み込み中...
{開発}{開発記録}{希哲15年}{}{一段落}{}{}{知番}{知名}{抜控}(225)

{希哲16年5月23日の開発 K#F85E/E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

{信頼性}

{}