{譜類添付機能の様子}{意味を持たない}{永続譜類}{はまった}{最後の最後}{実譜類}{舞覧隠し戦略}{ともども}{捨ててしまう}{-metadata icc}...=}(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/利用していたことが原因だった。最終的に,これが大して意味を持たない設計になったので再描出フォーム同じ自我台録利用することにした。

{とらわれず}{精神の最適化}{長年の}{無茶な話}{デライトの文化}{長い年月}{大きな苦労}{思わなくもない}{直面している}{人を選ぶ}...=}(115)

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

最近SNS 戦国時代観察しながらオタク文化」についてよく考えていたが,これまでオタクというものを漠然としか理解していなかったことに気付いた

同時に自分オタクではないということにも気付いてしまった昔からオタク文化には抵抗が無いのにネットオタク交鳴体コミュニティやたら苦手だった。それはオタク嫌いだからではなく,元々子供時代から特定の集団属することが苦手だったからだ。

教室の隅漫画を描いているような勉強好きな子スポーツ少年不良少年……誰とでも遊びたいし,なんでも知りたいなんでもやりたい,そういう子供だったよな,なんてことを思い出していた私にとって,それが「自由」の原体験だった。やがてそれは人生観世界観となり,希哲館事業にもデライトにも繋がっている。「なんでもメモ」の真意は,分野とらわれず,この世界について網羅した百科全書自分の中で育てようということだ。

そもそもこんなことを考え始めたのは,オタク交鳴体味方に付けられるSNS地盤作りには有利だなと感じることがあったからだ。人を選ぶ側面もあるが,デライト直面しているキャズム早さ深さ考えると,隣の芝生的に羨ましい思わなくもない

結局私自身は,オタク文化つまみ食いするのは好きでも,オタク文化囲まれるのは嫌い人間であって,いわゆるオタクとは言えないのだということに気付いてしまうと,何か期待していたことも滑稽思えてくる

巨大なオタク交鳴体味方に付けても SNS立ち上げには長い年月大きな苦労伴うというのに,デライトの文化一から広めるってどれだけ無茶な話なんだ,という気重気付きでもあった。前向き考えれば長年のもやもや晴れすっきりした部分もあるので,精神の最適化進んだとも言えるか。

2日振り返り日記

{希哲17年1月28日の開発}{希哲17年1月28日の進捗}{希哲17年1月28日}{こうして}{追加せず}{余力が無い}{著作権上}{濫用される}{対応済み}{「複写失敗:描写が空ではありません」}...=}(158)

{希哲17年1月28日21歩 K#F85E/E74C-46A3}

進捗時限記録中略

また新生デライトの要件ではあるが,ついさっき急に実装イメージまとまってしまった輪郭複製機能実装終了出振るい手定め済み

描写欄状態新規描出フォームで,自輪郭輪符知名欄貼り付けるドロップすると輪符から知名描写複写される

複写成功する「複写完了」表示「複写失敗:自分の輪郭ではありません」「複写失敗:描写が空ではありません」違了表示付け自我知番の省略にも対応済み使い勝手非常に良好

これまで通り輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが,眠気考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが,「輪郭複製のための機能」という意味ではそこまで間違っていない


輪郭複製機能については,昨年5月18日の開発で「知名描写複製して新規描出フォーム移動するボタン」として実装することを考えたが,その後用合い改良経て抵抗感募っていた

輪郭直接複製するような機能やはり避けたい手軽し過ぎる誤操作濫用可能性高まる適切な手間というで,新規描出フォームへの複写というアイデア悪くなかった。ただ,現状の輪郭選り手理想的にまとまっているので,極力ボタンのような要素追加したくない思うようになった

さっきふと,「知名欄への輪符貼り付け」というについて考えていたら,これが急速にまとまってしまった過去にも何度か脳裏をよぎっただが,その時いまいち気乗りしなかった

貼り付け方式最初の懸念誤入力だった。復元ボタンだけでは心許ないので,知名であることを条件にしようとしたが,空の知名書き始めることは少なくないので中途半端だ。複製したい輪郭検索してから写し取り貼り付けという流れ考えると,知名欄いちいち空にしなければならないのは煩雑過ぎる

間もなく描写欄という条件なら全く問題ないことに気付いた誤操作懸念なくなったので,ドラッグ&ドロップにも対応することにした。

もう一つ自輪郭のみという制限付けることにした。描写内自我知番の省略Aejs対応するのが難しいという問題もあるが,濫用され著作権上手溢れ増えることが予想される他人の描写扱い慎重に,という意味でもこれくらい適切だろう。

こうしてするする実装イメージまとまり一通りの機能付けた実装難なく完了した余計な視覚要素追加せず,それでいて直感的という,理想的な輪郭複製機能あっという間に出来てしまった

=}
{対応出来る}{希哲17年1月25日の副日記}{多大な効果}{表示速度向上}{通信量削減}{不必要な出与え読み込み}{見つけられた}{抑えつつ}{後略条件}{少なそう}...=}(402)

{希哲17年1月25日の開発 K#F85E/E74C-7E8A}

23日の開発から急速に進展したデライト高速化一段落した

テーマ切り替えボタン用合い検討4歩新規描出フォームへの移動機能として吹き描き外背景ダブルクリック用合い復活10歩全知検索ページャー周りの調整16歩こまごまとした領当て装体調整17歩といった雑多ながら充実した作業片付けついに描写後略機能一段落させた21歩出振るい手定め済み

描写後略機能により,デライト最初期から吹き描き構造的問題だった「不必要な出与え読み込み多さ」という問題解消した表示速度向上通信量削減SEO 強化迷惑行為対策など多大な効果見込める

デライト高速化現状今後

昨年末の壊衝不具合修正以後デライト速度安定性ともにウェブ相振りとして十分な水準達していたが,今回の高速化経て明らかにもう一つ壁を越えた感がある体感として,「ウェブ相振りなら特に不満のない速さ」から「単動相振り比べても遜色のない速さ」になった。

一昨年4月9日掲げた全ページ0.3秒以内表示」という目標埋め込み利素考えると現実的ではない気がしてきたものの,軽いページでは200ms台重いページでも概ね300ms台応答出来るようになっている。実感として欲しかった速度手に入れられたし,最適化余地まだまだ残しているので「埋め込み利素除いてほぼ全てページ0.3秒以内表示」なら十分手が届くいよいよ本格的に速さデライトの武器になってきた。

ここで新生デライト開発におけるデライト高速化一段落とし,今後機能追加トラフィック応じた微調整留め別の機能整備集中することにした。

その先デライト高速化については,大きなところでは CDN 導入KNEST による水平拡大請い手隠し機能整備描写 HTML 隠し以外HTML 隠し実装,そして中途半端な状態放置しているページ付け求頼改良があるが,どれも現時点での優先順位低い

読み込み中...
{気付いた}

{}