generated at
公式のサポートが期待しにくいインターフェースの使用を減らしたい
公式(ツール等の提供元)が破壊的変更を行う可能性のある部分に対する、ハック的な対応への依存を減らすようにしている

yanmaは次のような状況を見ると嫌な予感がする
プロプライエタリなソフトウェアに対する、そのソフトが提供する範囲を超えた設定変更
ソフトウェアの提供元が後方互換性をどの程度保証してくれるのか分からない部分の利用

公式側のアップデートである日突然動かなくなる危険性がある
こういう問題は公式に問い合わせても「仕様です」と返ってくる可能性が高い
ハックしている側も、ハックなのでアップデートに追いつくのに時間がかかる(ことがある)

最近は公式が提供している範囲の設定変更も、本当に必要か考えるようになった
デフォルト設定から遠ざかるほど公式がきちんとテストしている確率が減っていく
他の人が同じような問題を踏む確率も減っていく
とはいえこの辺まで来ると程度問題なので、リスクと必要性を自己判断している。転んでも泣かない
OSSの場合は「ソース読む」や「古いバージョンから自分でビルド」という最終手段がある

Webサイトの構造を利用したスクレイピング
保守コストを必ず考える必要がある

> 開発者の想定を超えた使い方が産まれやすい
> 想定を超えてほしくない(レジとか券売機とか)では不要だが
> 創造的な作業をするための道具では重要な事だ
公開されている範囲内の機能を色々組み合わせて想定外の使い方を生み出すのは面白い
これはyanmaも面白いと思う
/shokai/汎用的な小さな機能で言及されているのは、ちゃんとサポートされている機能の組み合わせ・応用
公式が想定している・いないではなく、サポートされている・いないという切り口のほうが適切かも
ハック的なところまでいくとコストのほうが大きいだろうけど

マルチバイトやIMEのある環境もややこういう気配を感じるinajob
マルチバイトはUnicodeの普及でそこまで心配しなくて良くなったかな

関連