{デライト}{希哲16年5月の一日一文}{一日一文}{エクスポート機能}{新生デライト}{順調に行って}{“知能増幅メモサービス”はなぜいま最も重要なのか}{受け付けている}{解決したい}{緩やかに}...=}(136)

{新生デライトとは何か K#F85E/E74C-AEC2}

最近デライトでは「新生デライト」という表現多用している簡単に言えば使いやすく生まれ変わったデライトのことだ。

デライトの使い方の考え方」や「“知能増幅メモサービス”はなぜいま最も重要なのか」でも書いたように,前例のない目的持ったデライトには,どうしても特有の難しさがある。

それでもシステムの実用化から10年以上サービス公開から2年以上ち,その有用性十分に実証されている多くの人様々なメモツールブログSNS などを行ったり来たりしながらやってきた情報蓄積発信を,私は10年以上前からほとんどこのシステムだけで実現しているサービス公開後は,デライトでしか出来ないこと見出して使い続けてくれる利用者もいる。

使える人には使える”ことは分かっている残る問題は,使える人少なさだ。そこでいま,多くの人親しめる快適なサービスにするため,文書整備機能整備高速化,そして独自の軽量マークアップ言語デラング」の整備といった包括的な改良構想推し進めている。その完成形を「新生デライト」と呼ぶ

順調に行って6月中,ずれ込んでも7月中には完成見通しだ。


機能整備という点では,すでに使いこなしている利用者にとっての利便性向上もちろん,他のメモツールなどに慣れ親しんだ初心者戸惑いがち機能不足補うことを意識している

例えば,輪郭非公開近い未公開状態」に出来る公開設定機能編集中にリンクしたい輪郭を検索出来る機能全文検索機能検索語提案(サジェスト)機能ファイル添付機能輪郭を削除する機能自動ページ展開機能インポートエクスポート機能高度なアカウント管理機能などの追加予定している

これまでにない密度人の頭の中保存するようなサービスの性質上いわゆる非公開機能導入特に難しい問題だった。AppleGoogle のような世界最大級の企業でも個人情報流出事件起こしているわけで,一事業者安全性保証することは不可能考えている。これに関しては,他の利用者からの閲覧緩やかに制限する未公開状態」の導入と,知番ファイル名として利用したローカルでのファイル管理手法広めることで解決したい

質問要望常に受け付けているので,“世界を変える新生デライト開発どんどん参加してほしい。


=}
{デライト}{OFFSET}{減らせる}{付けたかった}{ts_upd}{利用しやすくなった}{実装しておいた}{一覧部分}{整備した}{隠し効率}...=}(210)

{希哲16年6月30日の開発 K#F85E/E74C-A106}

デライト高速化における KNEST 隠し実装一段落した。18日作業方針検討のみで20日から,休日除いてちょうど10日間での達成だった。出振るい済み

全体としては大成功だった。

必要以上に固め過ぎるのも良くないため,隠し化現時点最低限必要範囲留めたが,期待以上安定性期待通り高速化得られた次の施策出来たので,まだまだ高速化出来るKNEST 隠しDex匹敵するデライト武器になるだろう。

交度整理しっかり進めたこともあり最初の輪数取得改良想定以上に長引いたものの,ここで KNEST 隠し共通の問題ほとんど解決したため,自我隠し輪郭隠し半日ほどで終わった。この交度整理収穫として大きかった輪郭操作系の kn の外充て函数整備したことで関連交度一気に整理された

影響範囲確率的に大きな問題はないだろうと見て排他制御甘い部分あえて残して出振るい急いだが,出振るい直後壊衝多発して少し焦ったすぐに論軸的問題気付修正し,その後むしろ想定以上に安定して動いている。この判断結果として正解だった。

輪数取得改良

輪数隠しに関しては,第二次知番改良中に固まった輪数取得改良」として,輪数取得仕組み全体的に改良した

これまでデルンではいちいち厳密な輪数表示をしていたが,これが大きな低速化要因になっていた。デライト以前まで,count()遅さ対する認識が甘かったデライト以後そもそも出場における件数計算原理的に遅いもの,と気付いてページ付けOFFSET上限設けるなどの対策はしていた希哲13年10月14日の開発記録が,輪数一筋縄ではいかない部分があり放置してきた

厳密な同期必要性隠し効率から,次のように整理することにした。

この通りに実装終え上手く動いている

また,この過程で各輪郭操作での輪数更新必要になったため,ほとんど未実装だった輪郭操作系の外充て函数整備した

自我隠し輪郭隠しから次の施策

自我隠しに関しては昨年4月中途半端な実装をしていたため,これを整理した輪郭隠しは,現時点一覧部分には適用出来ないものの一応実装しておいた

自我隠し出来たことで自我情報利用しやすくなったため,自我アイコンts_upd使った隠し破り付けたかったが,自我情報取得部分がまだ非効率なので見送った

輪郭情報求頼分割し過ぎているので,これを統合することを考えているうちに,次の施策まとまった

輪郭一覧については,まず知番のみで中景輪取得し,輪郭隠し照合してから三景輪郭情報同時に取得することにした。これで輪郭隠し効率的に利用出来求頼大幅に減らせる予定していた検索属性もここで盛り込む

{同時に進めていく}{時間はかかる}{探索処理}{見通しが悪くなる}{捗り始めた}{事象処理整理}{希哲16年4月21日}{Aejs の事象委譲}{開発}{さることながら}...=}(68)

{希哲16年4月21日の開発 K#F85E/E74C-FDDC}

=}
{デライト}{用者}{デラング}{進捗記録}{希哲16年2月19日}{希哲16年2月19日の開発}{本来の意味}{自サービス}{止めておく}{独自に}...=}(131)

{希哲16年2月19日11歩 K#F85E/E74C-D1B5}

進捗時限記録中略前後

何気なくマイクロブログサービス用者ユーザー示せる記法欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので,軽くまとめ終了

とりあえず分散型 SNS使われている記法拡張し,@[用者名]@[ドメイン名]汎用記法整備する方向進めることにした。


要は@user書いたTwitter輪結したり,@user@example.com書いた分散型マイクロブログ捌き手輪結してもいいのではないか,と考えたことがきっかけだった。

ここで一つ,@user@example.comhttps://example.com/@user必ず対応するのだろうかという疑問湧いた以前にもなんとなく考えたことはあったが,ActivityPub というか WebfingerURL引き出したり,面倒臭そう気がし進展しなかった。このあたりの仕様がどうなっているのか,いまだによく分からない

もっとも,ざっと見渡す限り分散型マイクロブログ捌き手は大体 https://example.com/@user になっているし,自分で Mastodon 捌き運営していた時も出放りはこれだったので,事実上の標準とみなしていいのかもしれない。


Twitter@user でいいかと思っていたが,いくら普及しているとはいえ,これは特定サービス寄り過ぎだろうということで,@user@twitter.com統一することを考えた。ただ,Twitterプロフィールページ正規 URLhttps://twitter.com/user だ。https://twitter.com/@user でも転送されるとはいえ,若干気持ち悪い

さらに,この時点では @user@twitter.com と書けば @user表示されるという仕様考えていたため,いずれにせよ特定サービス向けの処理追加出来るようにする必要があった

ここまで考えたところで,いっそのこと @[用者名]@[ドメイン名] として,外部サービス用者指すための汎用的な記法にしてしまえばいいのではないか,と思えてきた。これは, 氏が独自に同様記法使っているのを見ていたことが大きかった

[ドメイン名] は,@[用者名]@twitter のように自明なら短縮出来るようにしてもいいかもしれない。対応サービス毎に用者名解釈輪結先調整し,それ以外は https://[ドメイン名]/@[用者名]輪結する。


少し困ったのは,簡潔分かりやすい名前見つからないことだ。一応平たく外部サービス利用者記法」を仮称としておく。

異邦人記法」というのも面白いかもしれないと思ったが,一見して意味分かりにくいので別名としてしか使えないだろう。「宛名記法」はどちらかというとメールアドレス向きか。


デライト使う予定が全くなかったため,@[用者名] という表示Twitter のために使うつもりだったが,これは止めておく

そもそも SNS などでは自サービス上の用者に対する言及メンションという意味を持つ記法から来ているデライト使わなかったとしても,この種の記法必要とするサービスにはデラング応用出来ないことになってしまう。

ここから @[用者名]本来の意味考え始め知番輪符などと組み合わせる可能性気付いた。これは「言及記法」として別途検討することにした。

{整備}

{}