{希哲16年11月23日}{日記}{Twitter アカウントの削除}{今まで以上に}{低質な情報}{開いたら開いたで}{集積場}{戻ってみる}{始める前}{見ていない}...=}(92)

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

最近気が乗らなくなっていたツイストだが,重い腰を上げ一つ書いてみて面白い心境の変化気付いたもう宣伝目的ですら Twitter使い続ける意味見失っているかといってMastodon をまた使うにもなれない。想像以上に気持ち冷めていたことに少し驚いた

輪郭整備生産性重要性上がったことで,ツイスト役割を終えたのかもしれない。世の中状況も,いま必要なこと把握し切った感があり,情報収集というでもあまり必要性を感じない

主観的情報価値集積場だったデライト客観的情報価値繋げることを強く意識するようになり,献典拡充のことを考えると,とにかく時間が足りないTwitter開いているないし,開いたら開いたで低質な情報今まで以上に気になって精神衛生上良くない

今はデライト開発輪郭整備ひたすら進めるのみだ。出来れば一日一文再開したい

というわけで,時期尚早かと思っていた Twitter アカウントの削除急速に傾いている告知してから少し時間を置いてとか,更新停止だけにするとかも考えていたが,それでずるずる引きずってしまうのも良くないここまでのデライト宣伝本当にデライト興味を持ったTwitter しか見ていないということも考えにくい

一度ツイストMastodon始める前戻ってみるのも良さそうだ。最新のデライトというこの上ない土産もある。

{希哲16年11月6日}{振り返り日記}{日記}{定休日}{喜んでもらえない}{開けそう}{新しい道}{二方面}{考えていたこと}{デライトの革新性}...=}(125)

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

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

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

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

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

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


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

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

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

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

7日振り返り日記

{希哲16年11月2日}{振り返り日記}{日記}{求められているもの}{忘れつつあった}{見つめ過ぎる}{手中にある}{開発してきた}{欲しくて}{何よりも}...=}(71)

{希哲16年11月2日の日記 K#F85E/E74C-33FA}

開発を進めようと思っていたものの,輪郭整備楽し過ぎ一日熱中してしまった。まあ,こういう時期があってもいいだろう。


イーロン・マスクによる Twitter 買収への拒絶反応思いのほかく,これはもしかしたらデライトにとって大きな追い風かもしれないと考え始めた明らかにこれまでとは異なるMastodon などの話題見られる

多くの人Twitter ではない Twitter のようなもの探している状況で,KNS としてのデライト発見されれば,それは決定的な瞬間になるだろう。ただ,容易ではない飛躍なので,過度な期待はせずに状況注視したい


そんなこと考えていたら,いまこの状況デライト存在していることの意義の大きさ久しぶりに実感した

世界中権力者富豪SNS支配権巡って熾烈な闘争続けている中で,唯一その先示せているのがデライトだ。目論見正しさ証明されている

何よりも欲しくて開発してきたデライトが,何よりも求められているものとしていま手中にあるこの頃,あまりにも近く見つめ過ぎていて忘れつつあったことを思い出せた。これがこの日最大の収穫だった。

3日振り返り日記

{希哲16年9月22日}{希哲16年9月22日の副日記}{解決している}{設けた}{直接指定}{最近の出振るい}{下がった}{急いでいた}{発生しやすい}{適った}...=}(164)

{希哲16年9月22日の開発 K#F85E/E74C-FB21}

新生全知検索整備ページ付け求頼改良サイトマップ改良不具合修正など。

サイトマップ改良急進展

特に長いこと課題だったサイトマップ改良急進展した。

これまでサイトマップ全知検索ページャー同様,一定輪数LIMITOFFSET区切ったページ返していたOFFSET多くなる遅くなるため,最大でも最新10,000輪100輪×100ページ限度だった。upub 導入後更に低速化したため,9,000輪まで減らしていたが,それでも後半になると応答時間10秒以上になることがあった。

今回のページ付け求頼改良時印使ったページ付け移行しようとしていたため,これをサイトマップにも応用出来るのではないかと考えていたが,サイトマップ場合サイトマップインデックスサイトマップ URL一覧生成する必要があり,この効率性問題だった。HTML 隠し利用考えたが,タイミング難しく,大袈裟過ぎる気がしていた

サイトマップ場合各ページ輪数揃っている必要はないのだから,一定期間区切ってしまえばいいのではないか,ということに気付いてからは速かった

まず,デライト上最古の時印2012-02-10 19:09:33から現在時刻までを30日って必要なページ数割り出し,サイトマップインデックス従来通り形式/see?pg=[n]生成するdg_see() ではページ番号から期間計算してその範囲内上限輪数までの最新輪郭情報返す上限輪数とりあえず10,000輪にしておいた。数値様子を見ながら調整していく

インターフェイスそのまま利用したため修正最小限み,互換性維持出来たが,元々 dg_see()余計な多い問題があったのでそのあたり最適化しておいた。

実作業出振るい手定めまで正味3時間ほどで済み結果としてサイトマップ速度ページ数対応期間の長さはるかに向上した現在時刻基準なので,上限輪数から漏れた分待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性効率性完全に両立させることは不可能なので,ここが良い落とし所だろう。デライト特有の要求適ったサイトマップ設計という,大きな問題また一つ解決した

輪数取得改良前後景時印導入などを経てサイトマップ高負荷求頼発生しやすい最後の箇所になっていたため,これでデライト安定稼動における不安要素払拭出来たページ付け求頼改良急いでいた理由でもあったが,最近の出振るいで,全知検索でもページ番号直接指定上限設けたため,高負荷求頼問題一応解決している。これでページ付け求頼改良優先順位少し下がった

{希哲16年9月20日}{希哲16年9月10日}{希哲16年9月3日}{希哲16年8月}{希哲16年6月}{振り返り日記}{日記}{難工事}{最大級の}{こだわっている}...=}(138)

{希哲16年9月3日の日記 K#F85E/E74C-3F90}

一時脳疲労感が強かったが,現状整理組計検討急速にみ,だいぶ頭がすっきりした

8月第二次用合い改良輪郭小窓実装によって用合い上最大の革新果したので,内部的最後の大革新となるであろう新生全知検索整備完了と,文書整備一段落をもって「新生デライトの成立」とすることにした。遅くとも開発専念出来る20日までにこれを実現する

具体的な当努設定している新生デライトの完成」については,もう少し長い目で見着実に歩を進めることにした。先述目標まで漕ぎ着ければ比較的小さな機能実装調整残すのみなので開発時間多少減っても大きな問題にならない。

状況の変化に対する即応性必要な時期であるため,10日以後5日刻み現状評価組計見直しい,月内結果出せるかどうか判断する出せそうならこのまま突っ込むし,出せそうになければそこで律動的集中生活解除長期戦備える


新生デライトの完成」が「新生デライトの成立」の十分条件であることも必要条件ではないことも自明だが,ではいつ新生デライトの成立」と言えるのか,ということはたまに考えていた。ただ,いずれにせよ先の話だったので,そこまで深刻な問題ではなかった

8月第二次用合い改良輪郭小窓実装以後,この問題無視出来なくなっていた。「新生デライトの完成」までの進捗よりずっと早く思い描いていた新生デライト」に近付いた感覚があった。実際残りの当努印迫はここまで大きくないだろう。

そもそも新生」というのは「生まれ変わったような」という意味だ。「新生デライトの成立」と言える時点があるとすれば,新生デライト開発過程特に大きな革新果し終えたということになる。その時デライトは「未完成の新生デライト」となる。今回の組計検討ではその要件絞り込んだ

現実問題として,短期的に新生デライトの完成」を目指すことが合理的ではなくなってきたというのもある。製品価値大きく寄与しない細部こだわっている時間が無い第二次用合い改良予定外展開だったが,6月第二次知番改良など予定外作業多過ぎた

その代わり最大級の難工事成功という予定外収穫得てきた。これを活かす方向舵を切るべきだろう。

4日振り返り日記

{希哲16年8月21日}{希哲16年8月20日}{希哲16年8月の開発}{_dg}{調査する}{特有の問題}{根本的な解決}{無理そう}{負荷抑制}{選択肢が増える}...=}(102)

{希哲16年8月20日の開発 K#F85E/E74C-1175}

応答速度異常に遅い輪郭についての不具合調査から求頼改良出場改良アイデアまとまり,一気に実装した

_dg_dg_oln結合しないと揃え出来ず揃え極端に遅くなる場合があることは認識していたが,時印追加することは正規化観点から避けてきた

公開設定機能導入必要性が低くなった揃え用時印廃案にすることを最近考えていたが,これに近い役割持たせた ts_fgts_bg追加することを思い付き,急速にまとまった単なる複製ならやはり避けたかったが,より抽象的な時印_dg持っていることは不自然ではなく,同期引き入れ再描出処理行うだけでいい。

手定めしてみると,低負荷求頼では索引使われず有意差見られなかったものの,高負荷求頼では数倍から十倍程度までの高速化見られた求頼最適化選択肢が増えることでサービス全体負荷抑制見込める

領下での実装手定め終えたが,稼動させながらの _dg修正無理そうなので明日早朝出振るいすることにした。


これにより応答速度異常に遅い輪郭についても改善見られたが,異常であることは変わらず根本的な解決にはならなかった。

当初輪括膨大な輪郭特有の問題だろうと思っていたが,一見何でもなさそうな輪郭でも発生している

これは別途調査することにした。


ここで,検討していた揃え用時印ts)は正式に廃案とすることにした。

簡単な時印更新可能になり,公開設定機能目立たせない再描出可能になったので必要性感じなくなった。となると実装用合い複雑化懸念大き過ぎる

{考えていた}

{}