最後の部分で「Joe」を「John」にしていたら、この文書が少なくとも5回は継ぎはぎされてきたことの間接的な証拠になっていた気がする。しかも、そもそも最初からちゃんと理解して説明できていたのは John だけだったのに、結局その彼も去ってしまった。「3年前（John が辞めたとき）」と「John に聞け（まだ在籍していれば）」という部分に、そのヒントが出ている。
もうやめてくれ！ Confluence の文書を参照しないといけないが、まだ全部が新しい構造に移行していないので、あちこち検索しなければならず、詳しい文書は Sharepoint にある。更新されたらまた PDF に変換して、特定のチケット番号で顧客サポートシステムに上げないといけない。しかもそのシステムは検索が弱いので、その番号を必ず覚えておかなければならない。
StackOverflow Jobs にはもう Joel のチェックリストがない。そのチェックリストには、開発環境を一発で立ち上げられる単一スクリプトが含まれていた。
信頼できるデータベースのコピーが必要なら、リポジトリに入っている DB は使わず、Steven に最新のバックアップを依頼しなければならない。そのファイルは彼のクラウドドライブにあるはずだ。それからマイグレーションを進められるが、20259999-9 とラベルされたマイグレーションは飛ばさなければならない。これは本番の緊急修正用として残してある。マイグレーションテーブルを直接編集して除外する必要があり、そのテーブルは status コマンドを実行すると作成される。
Ducati のオートバイについてなら、私も書けたと思う。自分のバイクが盗まれ、フラットベッドトラックに載せて持ち去られたうえ、始動しようとしてイグニッションと燃料キャップに穴を開けられたが、Ducati には何十年も前からイモビライザーが内蔵されているので失敗した。もう少しレベルの高い泥棒を期待したいが、その程度の IQ があるなら、こんな古いオートバイは盗まないだろう。結局バイクは見つけて修理したが、その後ほとんど Uber の運転手に殺されかけたので、もうやめた。泥棒にどう壊されたかはここで見られる。
昔、引退したオートバイ泥棒の reddit AMA があった。読んでいて本物のプロという感じがした。彼は、人々がオートバイ盗難だと思っているやり方の大半は、実際のプロの泥棒は使わないと強調していた。プロの泥棒は別のやり方を使う。たとえば OEM ECU を自作 ECU に交換してその場ですぐ始動し、シールドされたトラックに移し、その場で買い手が待っていて支払いを済ませ、すぐ引き渡すといった具合だ。
まだバイクに乗っているのか気になる。
昔 MG B GT を持っていたので、いつも故障している英国車には慣れていた。ある日いいレストランに行ったらバレーパーキングしか認められず、例外を頼んだが断られた。降りた途端に車はエンストし、バレットにチョークの使い方や、ギアを入れる前にスロットルを少し開ける必要があることなどのコツを教えて、後ろから見守った。彼は苦労しながら運転して隅に停めた。後で車を取りに行ったとき、彼はどこにもおらず、キーだけ受け取って、遠くから始動を試みる音が聞こえた。結局彼はあきらめ、私が自分で車を出した。
人がなぜ回避策を解決策と取り違えるのか、だんだん気になるようになってきた。自分も昔はよくそうしていたが、今はそうならないよう気をつけている。たとえばノートPCで Linux のスピーカー音質がひどく、直そうとしていたとき、友人から「ヘッドホンを使えば」や「外付けスピーカーを使え」と勧められた。たしかにそうすれば音は良くなるが、本当の問題は解決せず、ただ無視しているだけだ。この記事は、その考え方の極端な例を示していて興味深い。
1件のコメント
Hacker Newsのコメント
外部製のさまざまなフレームワーク（たとえば UI フレームワークや Auth フレームワークなど）にも、こういうやり方は当てはまると思う。おめでとう！ このチームに加われたのは幸運だと思うかもしれないが、実のところこの役職はここ5か月採用できていなかった。候補者に私たちが作った認証フレームワークを見せると、みんなすぐ逃げ出した。それでも逃げずに一度使ってみてほしい。まだ帰っていないということは、最近の就職市場は厳しいのだろう。プロジェクトの文書は見つけただろうが、最後に更新されたのは3年前（John が辞めたとき）だ。心配はいらない、Perforce リポジトリにサンプルはたくさんある。Perforce は Git に似たものだが、その話はまた今度。コードをチェックアウトしたなら、
makeコマンドを打つ前に、特定バージョンの Python を入れて LD パスを設定しないといけない。もし Python に依存する別のものがあるなら、二度とまともに動かなくなるかもしれない。"std::vector<std::__cxx11::basic_string<char> > >'} is not derived from 'const char*'"というエラーが出たら Joe に聞く必要がある（まだ在籍していれば）。どのヘッダーファイルをいじればいいか教えてくれるはずだ。昔サーバービルドが壊れていて、リポジトリに入っていないコードだ。誰か続きの説明を頼む :-)Python に依存する何かが出てくると、いつも不安になる。オープンソースツールを見ていて Python 製だとわかると、そのままブラウザを閉じて見なかったことにする。Python を安全に使う方法がいろいろあるのは知っているが、プルトニウムを扱うのに鉛の手袋を用意するくらい複雑に感じる。そして、その手袋をコマンドラインからどう呼び出すかを毎回思い出せない。
最後の部分で「Joe」を「John」にしていたら、この文書が少なくとも5回は継ぎはぎされてきたことの間接的な証拠になっていた気がする。しかも、そもそも最初からちゃんと理解して説明できていたのは John だけだったのに、結局その彼も去ってしまった。「3年前（John が辞めたとき）」と「John に聞け（まだ在籍していれば）」という部分に、そのヒントが出ている。
もうやめてくれ！ Confluence の文書を参照しないといけないが、まだ全部が新しい構造に移行していないので、あちこち検索しなければならず、詳しい文書は Sharepoint にある。更新されたらまた PDF に変換して、特定のチケット番号で顧客サポートシステムに上げないといけない。しかもそのシステムは検索が弱いので、その番号を必ず覚えておかなければならない。
StackOverflow Jobs にはもう Joel のチェックリストがない。そのチェックリストには、開発環境を一発で立ち上げられる単一スクリプトが含まれていた。
信頼できるデータベースのコピーが必要なら、リポジトリに入っている DB は使わず、Steven に最新のバックアップを依頼しなければならない。そのファイルは彼のクラウドドライブにあるはずだ。それからマイグレーションを進められるが、20259999-9 とラベルされたマイグレーションは飛ばさなければならない。これは本番の緊急修正用として残してある。マイグレーションテーブルを直接編集して除外する必要があり、そのテーブルは
statusコマンドを実行すると作成される。Ducati のオートバイについてなら、私も書けたと思う。自分のバイクが盗まれ、フラットベッドトラックに載せて持ち去られたうえ、始動しようとしてイグニッションと燃料キャップに穴を開けられたが、Ducati には何十年も前からイモビライザーが内蔵されているので失敗した。もう少しレベルの高い泥棒を期待したいが、その程度の IQ があるなら、こんな古いオートバイは盗まないだろう。結局バイクは見つけて修理したが、その後ほとんど Uber の運転手に殺されかけたので、もうやめた。泥棒にどう壊されたかはここで見られる。
昔、引退したオートバイ泥棒の reddit AMA があった。読んでいて本物のプロという感じがした。彼は、人々がオートバイ盗難だと思っているやり方の大半は、実際のプロの泥棒は使わないと強調していた。プロの泥棒は別のやり方を使う。たとえば OEM ECU を自作 ECU に交換してその場ですぐ始動し、シールドされたトラックに移し、その場で買い手が待っていて支払いを済ませ、すぐ引き渡すといった具合だ。
まだバイクに乗っているのか気になる。
昔 MG B GT を持っていたので、いつも故障している英国車には慣れていた。ある日いいレストランに行ったらバレーパーキングしか認められず、例外を頼んだが断られた。降りた途端に車はエンストし、バレットにチョークの使い方や、ギアを入れる前にスロットルを少し開ける必要があることなどのコツを教えて、後ろから見守った。彼は苦労しながら運転して隅に停めた。後で車を取りに行ったとき、彼はどこにもおらず、キーだけ受け取って、遠くから始動を試みる音が聞こえた。結局彼はあきらめ、私が自分で車を出した。
数年前、「バレー専用」の駐車場でマニュアル車だと言ったら、20代のバレットが顔面蒼白になって「ご自分で停めてください」と言った。MG のオーナーはいつも何か壊れた状態に慣れているものだと思うが、ポイントが固着したときに叩くためのハンマーを持ち歩いていたのか気になる。私も昔 65年式 Triumph Spitfire に乗っていたが、以前のオーナーたちがめちゃくちゃにした部分を全部直したら、かなりまともだった。
友人に MG Mini を買った人がいて、バンパーステッカーに「この車から落ちるすべての部品は最高の British 製造業者製」と書いてあった。
「クラッチ安全スイッチがないので、始動前に必ずクラッチを踏むこと」という機能があった。友人の父親は、これを Datsun で渋滞中に車が止まったときの脱出機能のように使っていた。1速に入れてクラッチを離しながらスターターで始動し、車を動かしていた。
記憶が正しければ、英国の Highway Code（あるいはオーストラリア版）でも、踏切で車が故障したときにこういう方法を使うよう勧めていたはずだ。マニュアルトランスミッション車に限られる。80年代の英国ではオートマはまだ一般的ではなかった。
4か月ほど前にこの方法を読んだことが、実際に自分の車の燃料ポンプが壊れたとき役に立った。レッカー車が中途半端な位置に停まっていて、手で押すかスターターを酷使するしかなかった。
79年式 Datsun に乗っている友人がいたが、よく始動しなかったり止まったりしていた。だからいつも坂道に駐車して備えていた。
踏切で車が止まったとき、この方法は最後の手段だと聞いたことがある。でも実際に大人になってみると、これほどまれにしか起こらない危機は流砂くらいだ。
スターターモーターで「運転」するのは、一瞬だけ電気自動車になったような感じだ。
開発者オンボーディング風に整理した文書のバージョンみたいだ。
筆者が Miata の Concept Engineer だったという点から、あらゆるノウハウをうまく注ぎ込んだことがわかる。Miata が再帰的頭字語だと知っていたか（Miata Is Always The Answer）？
筆者の Miata 関連寄稿が同じサイトにほかにもあるので共有する: I helped make the first Miata, and now I love its ancestor
参考までに、「Miata Is Always The Answer」は実際の頭字語ではなく、ファンが作ったジョークだ。
この話を読んで、繰り返し見る悪夢を思い出した。車のブレーキがほとんど効かず、運転しながらずっと恐怖に襲われる悪夢だ。これは最初の車だった VW マイクロバスのふにゃふにゃしたブレーキに由来している。
ずっと昔、高速道路を走っていてブレーキを踏んだら、ペダルがそのまま床まで沈んだ。サイドブレーキでようやく停車できた。整備不良で、走行中にブレーキが外れてしまっていたことがわかった。前日に点検してもらったのに異常なしと言われていた。二度とその店には行かなかった。
私もその繰り返しの悪夢を見たことがある！ 現実ではほとんど経験していないのに、ほかの人もそうなのか気になる。私の80年代後半の Corolla は後輪がドラムブレーキで、山道を下るとすぐブレーキがフェードした。そういうときに限って、山のふもとでは大型ピックアップがぴったり張り付いてもっと速く行けと迫ってきた。牽引された経験も思い出す。ロープが短くて適切ではなく、ずっとブレーキを踏みながら何とか止まっていて、途中でブレーキが空を切る感じになり、心臓に悪かった。
まったく同じ悪夢を見たことがある。ブレーキを強く踏むほど、かえって効かなくなる、まるで対数曲線のような感覚だ。ただ、その悪夢がどんな実体験に由来しているのかはよくわからない。
私も似たような、ブレーキがふにゃふにゃでほとんど効かない悪夢をよく見る。
最初の彼女が 200 ドルで中古の VW Bug を買ったことがあった。私もその頃 Toyota Corolla に乗っていて、後に横転したことがある。当時は 70年代の Corolla はよく横転するという噂があった。VW Bug の後ろを下っていたら、ほとんどブレーキを使っていないように見えたので見ていたら、信号を無視してトラックに側面衝突した。幸い大きな被害はなく、フェンダーを交換しただけでまた乗っていた。ブレーキ以外にもエンジンの調子が悪く、自分でキャブレターを整備し、うまくいったのに気を良くしてエンジン全体を分解したが、組み直せそうになくて整備士に渡したところ、「こうやって仕事を増やされるのは困る」と言われた。昔は車に名前を付けていて、Bug は Gus、MGB-GT は Maggie、Fiat 124 Spyder にはもともと特別な名前があった。Spyder はブレーキラインに気泡が入って、走っているうちにブレーキがどんどんかかり、最後には止まってしまう厄介な症状があった。各ホイールにブリードバルブがあったので、レンチを持ち歩いてはこまめに圧を抜いていた。VW と Porsche の共同開発だった 914 モデルを見ると、「Vorp!」と叫んでいた。
筆者は私が通っていた大学の内燃機関の教授だった。授業では楽しさと知識の両方を与えてくれた。
人がなぜ回避策を解決策と取り違えるのか、だんだん気になるようになってきた。自分も昔はよくそうしていたが、今はそうならないよう気をつけている。たとえばノートPCで Linux のスピーカー音質がひどく、直そうとしていたとき、友人から「ヘッドホンを使えば」や「外付けスピーカーを使え」と勧められた。たしかにそうすれば音は良くなるが、本当の問題は解決せず、ただ無視しているだけだ。この記事は、その考え方の極端な例を示していて興味深い。
この話は前にも見かけて面白く読んだ。ただ、2022年の記事だと知って驚いた。少なくとも2016年ごろ、あるいはもっと前の記事だと確信していたし、最初に見たときからすでに再掲のように感じていた。