ソフトウェア開発に長い間従事していると、問題が発生した時に、手がかり（エビデンス、ログ、事象を見た人の報告 etc...）から、問題に対しまず仮説を立て、事象を再現させたり仮説を裏打ちさせる証拠（ログ、モジュール差分、バグリポート、取り調べ etc...)を見つける事で問題の解決を図るまでのプロセスの質とスピードが研磨されていく。
プログラマーやSEは刑事や探偵に向いてるんじゃないかとよく思う。

仮説は、時に99.9%、時に1%(はまっている時）という確信度を要素に従えており、そのうち、だいたい1%〜80%くらいというレンジの広いそれで表現されるのが

「キャッシュかな？」

である。

修正したはずの画面やJSの挙動が反映されなかったりした時にとりあえず「キャッシュかな」と言えばいいと思っている。

キャッシュは僕の中で何年経っても動きがよく分からないもので、また、たいがい問題が発生した時くらいしか認識する場面がない。

昔、HTTPでXMLを取りに行って、XMLの中身の情報を軸として処理する日次バッチをリリースした。
XMLはあるサービスの有効期間を管理しており、新しいサービスが変わる2、3か月くらいに1度の頻度で更新される、そのバッチに取っては非常に重要なXMLだ。
新しいXMLに変わって2、3日は新しいXMLが取得出来てたが、ある日1日、というかバッチの中で2、3回呼ぶ（その作りもバカだがw)内の1回だけ古いXMLを取得してしまい、後続処理に影響が出てしまった事があった。
その時も僕は「キャッシュですかね？」とひとまずみんなを煙に巻くように、決してプログラムのせいでは無いことをほのかに主張しつつ、解析はインフラ担当に任せた。
結果、プロキシか、XMLを保持するサーバかは分からないが、そこがキャッシュを返す設定になってたらしいので、キャッシュを返さない設定にしたという事をそれとなく聞いた。結局1日2回、日中にHTTPで取得し、ローカルに保存したXMLを実際に処理する際に見に行くというよく分からない修正をさせられた。（古いXMLが取れてしまった場合に対処すべきなのだが、そんな仕掛けにも運用にもしていないw）
リリース前に、バグが出るならXMLだろうなとは思っていたのでそれはそれでハンター冥利に尽きる。

話がそれた。
とまあそれくらいキャッシュはよく分からない謎の動きをする。それに慣れてくると、

「キャッシュが効いてて修正が全然反映されねえじゃねえかクソが」

といいつつ、全く別の場所の資材を修正していたというのは誰しも経験があるのではないだろうか。二重管理はダサいし、何でもキャッシュのせいにしてはダメだということである。

こんなに長々と書くつもりがなかったのだが、以下が本題。

TwitterAPIを使用しようとする場合は、アカウントに電話番号を紐付けなければならないのだが、Twitterの設定画面で、携帯に送られてきた認証番号を入力して設定しようとした際に、

電話番号を登録できませんでした。再度お試しください。

と謎エラーが出てしまい、困惑してググってたら「画面を更新すると良い」とあったので、「おいおいまさか、、、そんな、、、バカなっ、、、」と思いつつ半信半疑でCtrl + Rで画面更新後、設定したら見事に出来てしまったので、きっとキャッシュが効いていたんだろーなーと思いつつ、結局のところよく分からない自分も認識している。

よく分からないけど直った。たまにこういう経験をする事で、人は不完全である事を認識するのである。