{方向}{}{}{}{}{一日一文}{サービス}{希哲17年2月}{希哲17年7月の一日一文}{時間がかかり過ぎている}(204)

{X(旧 Twitter)はなぜライトモードを捨てたかったのか K#F85E/0758-FB71}

昨日X旧 Twitterダークモード以外配色モード廃止するイーロン・マスク氏が表明し反対意見殺到するという騒動があった。結局ダークモードデフォルトにしてライトモード一応残すという方向軟化させたようだ。

デライトでは,今年2月ダークモード(ダークテーマ)対応実現したばかりなので,個人的に色々思うことがあった。前回予告した KNS についての文章時間がかかり過ぎているため,今回の一日一文つなぎとして,開発者の視点からこの騒動背景について書いてみたい


デライト元々明るい配色いわゆるライトモードのみでやってきた大きな理由一つに,イメージ問題がある白背景基本としたデザインにはやはり明るく清潔印象がある。サービスメディア紹介されるなど,イメージ戦略考えるとこれは馬鹿にできない

個人的には黒背景好きだが,この種のネットサービスではどうしてもアングラ感出てしまう背景色微かな灰色にすることも試したが,白背景比べるちょっとくすんだような,地味印象になってしまう。なるほどダークモード流行しても大手サービス多くデフォルト眩しい白背景採用している理由はこれかと思ったものだ。

今年2月満を持してダークモード対応完了し,テストがてらダークモード常用していた時期がある。最初新鮮さもあって,それこそダークモードだけでやっていけそう気がしたが,慣れてくると,眠気が強くなったり,いまいち調子が上がらないことに気付いて結局ライトモード常用する生活戻った

ライトモードダークモードも,どう感じるかは個人差環境差によるところが大きいどちらかが万能だと思ってしまうのは,単純な経験不足なのだろう。今回の騒動は,ソフトウェア開発におけるマスク氏の経験不足と,新しいロゴ象徴される偏った趣味起因する出来事とも言える

ただもう少し踏み込むと,マスク氏をこの拙速追い込んだ X切実な開発事情見えてくる

配色モード追加維持というのは,見かけよりずっとコストかかる例えば外観絡むような機能追加をしたそれぞれの配色モード問題生じていない確認する必要があるし,問題があれば個別に調整する必要があるそして,このコストは,既存のコード保守状況ければ悪いほど,変更程度多大であればあるほど高くなる

読み込み中...
{『希哲日記』}{デライト3周年}{日記}{}{デライトの完全な成功}{迎えに来れる}{やるべきことはやった}{共に}{社会の雰囲気}{一役買っている}(120)

{希哲17年5月17日の日記 K#F85E/E74C-156B}

開発では地味な作業積み重ね目に見える成果になってくる一番楽しいところ来たが,ふと思い立って雑務抜本的な見直し始めたいよいよ本格的にデライト以前のような生活戻れそうだ。

ここ半年ほど希哲館事業外での体験求めるもの増えてきたような,不思議な心境の変化感じていたが,その原因少しずつ掴めてきたやはり長期戦態勢切り替えたあたりから精神的なゆとり出来たのだろう。

新生デライトの完成目前第五次デライト市場戦略固まり,気付けばデライトの完全な成功希哲館事業の成功対する焦り無くなっている油断するわけではないが,もうここまで来たら,あとはばら成し良く色々なもの磨きをかけながらその時を待つしかない,という心境になっている。少なくとも最低限やるべきことはやったし,時代迎えに来れるところまでは来た

思えば私の人生17歳の頃から希哲館事業の不可能性との闘いだった。特にデルンの実用化向けて本格的に走り出したからは,希哲館事業外使うあらゆる力あらゆる時間惜しかったそんな呪縛からも解き放たれたようだ。

今はこのデライトがあり,知識経験十二分得て多くの迷い無くなり,希哲荘中心とした理想的な生活環境整っている。これでデライト以前のような安定感取り戻せるならそれほど心強いことはない。もはや無敵だ。

そんなこと考えていたら高揚してきなかなか寝付けなかった

デライト3周年コロナ収束誕生日……と何かと大きな節目重なる時期だが,それも気分の切り替え一役買っているのかもしれない。デライト正式離立からの3年コロナ禍社会の雰囲気共にあった,というのが特に大きいのかもしれない。

18日振り返り日記

{開発記録}{十分}{}{知番}{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/利用していたことが原因だった。最終的に,これが大して意味を持たない設計になったので再描出フォーム同じ自我台録利用することにした。

{出来た}

{}