{進捗記録}{一通り}{一箇所}{十分}{}{サービス}{進捗}{デライト}{希哲17年4月10日の開発}{希哲17年4月10日の進捗}(148)

{希哲17年4月10日12歩 K#F85E/E74C-A47E}

進捗時限記録中略

隠し破りKNEST一部として体系化することにし,仕様まとめ交度修正などを一通り終えた緊急性低いため未出振るい

KNEST では,%Y%m%d%H%M%S 形式求頼変数隠し破りとして扱い(例:?20230101000001デライトでもこれで統一することにした。この時印形式を「詰め込み時印ts_jam呼んでおく

隠し破り導入以後スクリプト装体書などの主要静的譜類には ?upd=K170101.1 のように,希哲紀元での日付連番形式基本的に使ってきたが,自我アイコン隠し破り対応では ?icon&upd=[Unix 時間] になったり,添付譜類では ?[Unix 時間] になったりと,統一感なくなってきていた

実用上なんでも良かったが,譜類添付機能実装以降用者目に触れやすくなったため,簡潔さ分かりやすさ両立させる必要性感じていたUnix 時間では非技術者理解しにくいし,技術者でも意図理解するのに時間がかかるそれが不安繋がることは好ましくない特に簡潔というわけでもない。

確実性重視するならハッシュ使うのが定石だが,抽象性が低いということでもあり,擬制的扱いにくく融通が利かない場面出てくる冗長さ一部省略何とかなるにしても,やはり分かりにくい

総合的に詰め込み時印のみが一番無難だろうと結論付けた更新時印でも整合性を保つやり方いくらでもある用者意図推測しやすく,開発者手動ったり異常に気付いたりしやすい。

強いて欠点を挙げるなら,更新日時知られたくないいるかもしれない,ということくらいだが,デライトでは大きな問題ではないだろう。そもそも更新履歴見られるサービス投稿同時に上信される SNS なら秘密情報ではない。

ウェブ捌き設定などで小細工しやすいように,upd= なり mod= なり ts= なりのとして表現することも再考したが,として扱うことを想定していない文字列という特殊性鑑みると,それはそれで違和感がある14桁数字列求頼変数隠し破り,と明確に決めておけば十分だろう。


これを機にこれまでいちいち書き換えてきた主要静的譜類用の隠し破り更新も,mkbld-etc自動化したテンプレート一箇所書き換えればいいようになっていたものの,積み重なるそれなりの手間だった。

自動化するまでもない隠し破り記述いくつか残っているが,これは ?upd=K170101.1 なら ?20230101000001 というように置換しておいた

{進捗記録}{末尾}{日本語}{進捗}{WebP}{拡張子}{希哲17年4月5日の開発}{希哲17年4月5日の進捗}{譜類添付機能調整}{譜類添付機能}(115)

{希哲17年4月5日8歩 K#F85E/E74C-5EA8}

進捗時限記録中略

譜類添付機能調整

調整手定め終えここでいったん出振るい昨日うっかり中途半端な状態全体出振るいしてしまったため,譜類添付機能周り不具合があったかもしれない)

添付代置子追加し貼り付けドロップによる添付使えるようになった用合い面でもほぼ完成形か。

添付代置子

3月27日の開発考案した送信中挿入しておく添付代置子は,最終的に <!-- +[拡張子] [文言]...[追加ピリオド] -->形式となった。日本語WebP であれば,<!-- +webp 送信中... --> となる3月27日の開発記録で「読み込み中」と書いていたのは単なる間違い

まず描写内探索し埋め込み済みでなければ添付代置子挿入する。この時,添付代置子固有文字列となるように,必要であればピリオド追加していく送信完了時成功なら埋め込み記法置換失敗なら消去する貼り付けのために,描写欄捕活中カーソルの位置代置子挿入するようになっているが,捕活していない場合末尾追記する。また,送信中代置子書き換えられた場合無視して埋め込み記法末尾追記する

これで送信中状態直感的に分かりやすくなった

その他

読み込み中...
{開発記録}{十分}{}{知番}{WebP}{拡張子}{描写下見機能}{譜類添付機能}{cwebp}{譜類添付機能の様子}(187)

{希哲17年3月24日の開発 K#F85E/E74C-A57A}

譜類添付機能実装一段落させた出振るい手定め済み

いくつか課題残ったものの,これで譜類添付機能基礎出来た輪郭選り手領当てほぼ完成形言っていいだろう。本当努通して関連仕様検討や,中途半端だった libxtd譜類操作関連交度整備なども大きく進んだ

用合いとしては,録入り中描写選り手左下譜類添付ボタン置き譜類選択同時に上信開始完了したら埋め込み記法+[拡張子]追記下見開く開いている場合更新するというになった。すでに同拡張子添付譜類存在する場合上書きする予定通り描写内参照消し描き出し描き直しまたは輪郭削除削除されるようにした。

当初譜類選択後専用下見機能付き小窓開き確認してから送信,という用合い考えていたが,素早く描き出したい場合煩雑になり,交度複雑化見合わない可能性があるため見送った「送信中...」,「+[拡張子] を追記しました。」,「.[拡張子] で保存しました。」上書き場合3種類メッセージ@msg表示し下見関しては既存の下見機能利用すれ十分なことに気付いた描き出し前には上信せずスクリプト保持することも検討したが,これもページ遷移などへの対応考える無駄な複雑化招く可能性があるため見送った

対応形式とりあえず JPEGPNGGIFWebP のみ。WebP 以外場合長辺1920px以下WebP変換するWebP上信関してはImageMagick未対応パッケージまだ多いことなどから,1MiBサイズ上限のみで対応することにした。その他譜類サイズ上限原則として5MiBサイズ上限以外基本的に kn upl仕様合わせたが,cwebpICC プロファイル捨ててしまう問題気付いて kn upl ともども -metadata icc加えた

埋め込み記法では,拡張子のみ,知番拡張子組み合わせ加えて輪符拡張子組み合わせにも対応した

下見機能利用するために添付譜類舞覧隠し戦略見直した結局譜類更新時印から隠し破り付与出来るようにし,隠し破り有無Cache-Controlpublicno-cache切り替えられるようにした5歩これまでは一律 no-cache だった)Dex実譜類依存するのは水平拡大考えるとどうかと思ったが,そのうち KNEST 隠し化すればいいと判断した

最後の最後で,領下手定め環境問題なかった新規描出フォーム添付譜類本番環境では 404 Not Found になるという問題はまったが,これは systemdPrivateTmp による問題であることが分かり一時的に無効化してから問題無いように修正し元に戻した新規描出フォームでは無駄に永続譜類残さないように /tmp/利用していたことが原因だった。最終的に,これが大して意味を持たない設計になったので再描出フォーム同じ自我台録利用することにした。

{『希哲日記』}{日記}{心身に悪い}{適度な刺激}{再評価し始めている}{戻してから}{支えてきた}{睡眠導入}{2時間前}{デライトのダークテーマ}(55)

{希哲17年3月3日の日記 K#F85E/E74C-3BC4}

{進捗記録}{}{進捗}{希哲17年1月25日の開発}{希哲17年1月25日の進捗}{希哲17年1月25日}{縦方向}{誤タップ}{ページ内移動}{定かではない}(109)

{希哲17年1月25日10歩 K#F85E/E74C-7A41}

進捗時限記録中略

吹き描き外背景ダブルクリックダブルタップ新規描出フォーム移動出来るようにして終了出振るい手定め済み

デライト最初期新規描出フォーム固定機能試していた希哲13年8月1日4歩用合いだったが,自分でも驚くほど忘れていた固定機能削除以後何度か再活用検討した記憶はあるが,今ほど全体的な用合い方向性定まっていなかったからか放置していた新規描出フォームへの握接について先日あれだけ検討していたのに全く思い出さなかったついさっきふと思い出した灯台下暗しというやつか。

初見分かりやすい用合い必要なので全知検索窓固定機能輪結予定通り実装するが,スマートフォン右手持ちではタップしにくい位置だとは思っていた個人機でもマウスカーソル移動距離短くない。しかし,これならよくある固定表示ボタンよりよほど賢い上手い補完手段出来た

面白い発見二つあった。

現状幅狭領当てでは吹き描き外背景小さ過ぎ誤タップしやすいが,これは縦方向吹き描きマージン調整していくことにした。

{開発記録}{一通り}{知番}{点検}{希哲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 となる。第二次知番改良経て司組生成する知番はこれで統一するようになったが,デラングでは大量にある第零番節付き輪符第零番節付き輪結生成していたため,クロール効率への悪影響懸念された出与え属性通して輪郭小窓知番表示にも反映されていたため,用合い上の問題なくはなかった

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

読み込み中...
{『希哲日記』}{知名の付け方}{希哲15年}{希哲13年}{}{方向}{一助}{日記}{十分}{}(193)

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

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


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

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

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

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

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

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

読み込み中...
{『希哲日記』}{}{日記}{}{}{無し}{輪郭整備}{一日一文}{希哲16年10月}{デライトの完全な成功}(159)

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

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

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

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


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

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

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


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

読み込み中...
{開発記録}{一段落}{}{知番}{デライト}{希哲16年6月30日}{希哲16年6月18日}{壊衝}{OFFSET}{減らせる}(211)

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

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

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

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

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

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

輪数取得改良

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

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

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

読み込み中...
{基本的に}

{}