昨日,X(旧 Twitter)のダークモード以外の配色モードを廃止するとイーロン・マスク氏が表明し,反対意見が殺到するという騒動があった。結局,ダークモードをデフォルトにしてライトモードも一応残すという方向に軟化させたようだ。
デライトでは,今年2月にダークモード(ダークテーマ)対応を実現したばかりなので,個人的に色々思うことがあった。前回予告した KNS についての文章に時間がかかり過ぎているため,今回の一日一文はつなぎとして,開発者の視点からこの騒動の背景について書いてみたい。
デライトは元々明るい配色,いわゆるライトモードのみでやってきた。大きな理由の一つに,イメージの問題がある。白背景を基本としたデザインにはやはり明るく清潔な印象がある。サービスがメディアで紹介される時など,イメージ戦略を考えるとこれは馬鹿にできない。
個人的には黒背景が好きだが,この種のネットサービスではどうしてもアングラ感が出てしまう。背景色を微かな灰色にすることも試したが,白背景と比べるとちょっとくすんだような,地味な印象になってしまう。なるほど,ダークモードが流行しても大手サービスの多くがデフォルトで眩しい白背景を採用している理由はこれかと思ったものだ。
今年2月,満を持してダークモード対応を完了し,私もテストがてらダークモードを常用していた時期がある。最初は新鮮さもあって,それこそダークモードだけでやっていけそうな気がしたが,慣れてくると,眠気が強くなったり,いまいち調子が上がらないことに気付いて,結局ライトモードを常用する生活に戻った。
ライトモードもダークモードも,どう感じるかは個人差や環境差によるところが大きい。どちらかが万能だと思ってしまうのは,単純な経験不足なのだろう。今回の騒動は,ソフトウェア開発におけるマスク氏の経験不足と,新しいロゴに象徴される偏った趣味に起因する出来事とも言える。
ただ,もう少し踏み込むと,マスク氏をこの拙速に追い込んだ X の切実な開発事情が見えてくる。
配色モードの追加や維持というのは,見かけよりずっとコストがかかる。例えば,外観に絡むような機能追加をした時,それぞれの配色モードで問題が生じていないか確認する必要があるし,問題があれば個別に調整する必要がある。そして,このコストは,既存のコードの保守状況が悪ければ悪いほど,変更の程度が多大であればあるほど高くなる。
デライトの場合,開発者である私自身が一から書いて保守し続けている HTML や CSS で,ほとんどサービスとしての形が出来た状態だったので,最小限のコストでダークモードを追加出来た。
X の事情は,デライトとは正反対だ。長年他人が保守してきたコードを引き継ぐというのが,それだけで気の遠くなるような作業であることは,それなりのソフトウェア開発経験者なら誰でも知っている。マスク氏は,その X を大改造しようとしているわけだ。複数の配色モードの維持は,多くの人が想像しているよりはるかに重い足枷だろう。
X の方向性には全く共感しないが,マスク氏の立場を想像するに,出来れば当面は好きなダークモードだけで,それが駄目ならせめてダークモード以外の品質保証はしない方向で開発を進めたい,と考えてしまうのは無理もないことだと思う。
.zip
}{希哲17年4月14日の開発}{希哲17年4月14日の進捗}{希哲17年4月14日}{含められる}{確実ではない}{移動される}(125)サイクリング中に良い思い付きがいくつかあり,エクスポート機能も想定以上に洗練されたものになりそうだ。
KNo.[自我番号].[作成日].[期間開始日]-[期間終了日].zip
とすることにした。README.txt
を加えることにした。添付譜類代替 HTML については,以下のような形式で早速固まった。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>添付ファイルについて</title>
</head>
<body>
<p>この添付ファイルは下記 URL に保存されています。</p>
<p><a id="here" href="https://dlt.kitetu.com/KNo.XXXX/XXXX.webp">
<code>https://dlt.kitetu.com/KNo.XXXX/XXXX.webp</code>
</a></p>
<p><strong>大切なファイルはご自身で別途保存してください。</strong></p>
</body>
</html>
これならあらゆる状況で人間も読みやすく,<a#here>
としておけば機械的処理もしやすい。
さらに,正規表現(PCRE) id="here" href="(.*?)"
で添付譜類の URL を抽出出来るように保証することにした。つまり,以下の駒手が常に成り立つようにする。
$ grep ' id="here"' XX.webp.html | perl -pe 's/.* id="here" href="(.*?)".*/\1/'
https://dlt.kitetu.com/KNo.XXXX/XXXX.webp
場筋から導出出来なくもないが,移動される可能性もあり,確実ではない。特に,自我知番が確実に場筋に含まれる保証が無い。
新着確認機能実装を一段落させた。10日12歩の修正とともに出振るい・手定め済み。
新着確認機能により輪郭一覧の更新状況がぐっと把握しやすくなった。サービスの性質上,自動更新など気が散る実装を避けてきたが,あちこちページや画面を切り替えながら作業していると,輪郭一覧の鮮度が気になることが多々あった。必要以上に輪郭一覧を更新する癖がつく問題もあった。
@DG.upd
に集約し,他機能からも輪郭一覧更新を促すなどの目的で利用しやすくなっている。filter
をかけて使っている。新生デライト開発の当努としての新着確認機能実装は優先順位が低く,最後の方になるかと思っていた。最近になって,メニューのアイコンが使えること,輪数は必要ないこと,交差監視が使えること,と立て続けに実装上の気付きがあり,高い時間対効果・負荷対効果が望めるようになっていた。
マイクロブログなどの投稿数と異なり,1輪の長文もあれば10輪の知名のみの輪郭もあるのがデライトの輪数なので,文脈を限定せず,ましてや2桁程度の表示幅では情報量の尺度として機能しないことに気付いた。
全知検索窓固定機能で採用した交差監視が使えることに気付いたのが駄目押しだった。無駄な再読み込みを抑制する効果も望めるとはいえ,多少なりとも立求が増える機能なので,悪影響の懸念が拭えずにいた。交差監視によって無駄なく効果的に待機状態を制御出来る見通しが立った。流石に高速化までは行かないにしても,十分な低負荷実装になった。
pdftoppm
}{希哲17年4月6日の開発}{希哲17年4月6日の進捗}{譜類添付機能}{希哲17年4月6日}{7倍}(38)