公式のサポートが期待しにくいインターフェースの使用を減らしたい
公式(ツール等の提供元)が破壊的変更を行う可能性のある部分に対する、ハック的な対応への依存を減らすようにしている
yanma.iconは次のような状況を見ると嫌な予感がする
APIの公開されていない実装仕様的な部分を利用した解決策
プロプライエタリなソフトウェアに対する、そのソフトが提供する範囲を超えた設定変更
ソフトウェアの提供元が後方互換性をどの程度保証してくれるのか分からない部分の利用
userchrome.css、about:config、、
公式側のアップデートである日突然動かなくなる危険性がある
こういう問題は公式に問い合わせても「仕様です」と返ってくる可能性が高い
ハックしている側も、ハックなのでアップデートに追いつくのに時間がかかる(ことがある)
最近は公式が提供している範囲の設定変更も、本当に必要か考えるようになった
デフォルト設定から遠ざかるほど公式がきちんとテストしている確率が減っていく
他の人が同じような問題を踏む確率も減っていく
とはいえこの辺まで来ると程度問題なので、リスクと必要性を自己判断している。転んでも泣かない
OSSの場合は「ソース読む」や「古いバージョンから自分でビルド」という最終手段がある
例
デフォルト設定はよくできている#60078f4ddb62ad000048a892
TeX#6007b4dcdb62ad000021781b
Webサイトの構造を利用したスクレイピング
保守コストを必ず考える必要がある
/shokai/汎用的な小さな機能
開発者の想定を超えた使い方が産まれやすい
想定を超えてほしくない(レジとか券売機とか)では不要だが
創造的な作業をするための道具では重要な事だ
公開されている範囲内の機能を色々組み合わせて想定外の使い方を生み出すのは面白い
これはyanma.iconも面白いと思う
/shokai/汎用的な小さな機能で言及されているのは、ちゃんとサポートされている機能の組み合わせ・応用
公式が想定している・いないではなく、サポートされている・いないという切り口のほうが適切かも
タイトルを公式のサポートが期待しにくいインターフェースの使用を減らしたいとしてみた
ハック的なところまでいくとコストのほうが大きいだろうけど
マルチバイトやIMEのある環境もややこういう気配を感じるinajob.icon
マルチバイトはUnicodeの普及でそこまで心配しなくて良くなったかな
関連
デフォルト設定はよくできている
環境構築おじさん