プログラマーとエンジニアの民俗学（パート1）

これは、バグが完全に信じられないほどの症状を示すことがあるというインターネットからのストーリーのコレクションです。おそらくあなたにも伝えるべき物語があります。

バニラアイスクリームに対する車のアレルギー

明白なことが常に解決策であるとは限らず、事実がどれほど信じ難いものであっても、それらは事実であることを理解しているエンジニアのための物語。ジェネラルモーターズコーポレーションのポンティアック部門は苦情を受けました：

, , , . : . , , , , . Pontiac, . , , , . , . , , : « Pontiac, - , , , ?».

ご想像のとおり、課長はその手紙に懐疑的でした。しかし、念のため、エンジニアを派遣して確認しました。彼は、美しい地域に住む裕福で教育水準の高い男性に出会ったことに驚いた。彼らは夕食の直後に会って一緒にアイスクリーム店に行くことに同意した。その夜はバニラでした、そして彼らが車に戻ったとき、それは始まりませんでした。



エンジニアはさらに3夜来ました。初めてアイスクリームがチョコレートでした。車が始動した。二度目はストロベリーアイスクリームでした。車が始動した。 3日目の夜、彼はバニラを求めました。車は始動しませんでした。



賢明な理由で、エンジニアはバニラアイスクリームに対する車のアレルギーを信じることを拒否しました。したがって、私は車の所有者が問題の解決策を見つけるまで彼が訪問を続けることに同意しました。そして途中で、彼はメモを取り始めました：彼はすべての情報、時刻、ガソリンの種類、店の到着と帰りの時間などを書き留めました。



すぐに、エンジニアは車の所有者がバニラアイスクリームを購入するのに費やす時間が少なくなっていることに気づきました。その理由は、店内での商品のレイアウトでした。バニラアイスクリームが最も人気があり、店の前にある別の冷凍庫に保管して、見つけやすくしました。そして、他のすべての品種は店の後ろにあり、適切な品種を見つけて支払うのにはるかに長い時間がかかりました。



さて、問題はエンジニアに向けられました。エンジンがオフにされた瞬間から時間が経過しないのに、なぜ車が始動しなかったのですか？問題はバニラアイスクリームではなく時間だったので、エンジニアはすぐに答えを見つけました。それはガスロックでした。毎晩発生しましたが、車の所有者がアイスクリームを探すのに時間がかかると、エンジンが十分に冷えて静かに始動しました。そして、男性がバニラアイスクリームを購入したとき、エンジンはまだ熱すぎて、ガスプラグは溶解する時間がありませんでした。



道徳：完全に正気でない問題でさえ、時には現実になることがあります。

クラッシュバンディクー

これを経験するのは辛いです。プログラマーとして、あなたは自分のコードを最初、2番目、3番目...そして1万のどこかでコンパイラーのせいにすることに慣れています。そして、リストのさらに下に、あなたはすでに機器のせいにしています。



これがハードウェアのバグについての私の話です。



Crash Bandicootゲームでは、メモリカードにロードして保存するコードを作成しました。そのような自己正義のゲーム開発者にとって、それは公園を歩いているようなものでした。作業には数日かかると思いました。しかし、その結果、私は6週間コードをデバッグしました。途中で他の問題を解決しましたが、数日おきに数時間このコードに戻りました。苦痛でした。



症状は次のようになりました。ゲームの現在のプレイスルーを保存してメモリカードにアクセスすると、ほとんどの場合すべてがうまくいきます...しかし、明らかな理由なしにタイムアウトによって読み取りまたは書き込み操作が完了する場合があります。短い録音はしばしばメモリカードを損傷します。プレイヤーが保存しようとすると、保存に失敗するだけでなく、マップを破壊します。パンケーキ。



しばらくすると、ソニーのプロデューサーであるコニーバスがパニックになり始めました。このバグでゲームを出荷することができず、6週間後、この問題の原因が何であるかがわかりませんでした。 Connieを通じて、他のPS1開発者に連絡しました。同様の問題が発生した人はいますか？番号。誰もメモリカードに問題はありませんでした。



デバッグのアイデアがない場合、ほとんど唯一のアプローチは「分割して征服する」ことです。比較的小さなフラグメントができるまで、エラーのあるプログラムからコードをどんどん削除しますが、それでも問題が発生します。つまり、バグを含む部分が残るまで、プログラムから1つずつ切り取ります。



しかし、要点は、ビデオゲームから断片を切り出すことは非常に難しいということです。重力エミュレーションコードを削除した場合、どのように実行しますか？または文字を描く？



したがって、モジュール全体を、何か便利なことをしているふりをするスタブに置き換える必要がありますが、実際には、エラーを含めることができない非常に単純なことを行います。ゲームを機能させるには、そのようなクラッチを作成する必要があります。それは遅くて苦痛なプロセスです。



要するに、私はそれをしました。ゲームを開始するようにシステムをセットアップしたり、レンダリング用の機器を初期化したりする初期コードができるまで、コードをどんどん削除していきました。もちろん、この段階では、すべてのグラフィックコードのスタブを作成する必要があるため、保存と読み込みのメニューを作成できませんでした。しかし、（非表示の）保存と読み込み画面を使用して、保存してからメモリカードに書き込むように要求するユーザーのふりをすることはできます。



その結果、前述の問題がまだ発生している小さなコードが残っていましたが、これまでのところ、ランダムに発生していました。ほとんどの場合、すべてが正常に機能しましたが、クラッシュが発生することもありました。ほとんどすべてのゲームコードを削除しましたが、バグはまだ残っていました。これは不可解でした。残りのコードは実際には何もしませんでした。



ある時点で、おそらく朝の3時に、私は思いついた。読み取りおよび書き込み（I / O）操作は、正確なタイミングを想定しています。ハードディスク、メモリカード、またはBluetoothモジュールを使用する場合、読み取りと書き込みを担当する低レベルのコードは、クロックパルスに従って実行します。



クロックの助けを借りて、プロセッサに直接接続されていないデバイスは、プロセッサで実行可能なコードと同期されます。時計はボーレート、つまりボーレートを決定します。タイミングに混乱がある場合は、ハードウェアまたはソフトウェア、あるいはその両方も混乱します。そして、これは非常に悪いことです。データが破損する可能性があるからです。



コード内の何かがタイミングを混乱させた場合はどうなりますか？テストプログラムのコードでこれに関連するすべてをチェックしたところ、PS1のプログラム可能なタイマーが1 kHzの周波数（1000サイクル/秒）に設定されていることに気付きました。これは非常に多く、デフォルトでは、セットトップボックスの起動時に100Hzで実行されます。そして、ほとんどのゲームはこの周波数を使用します。



ゲームの開発者であるAndyは、動きがより正確に計算されるように、タイマーを1kHzに設定しました。アンディは過度になりがちです、そして私たちが重力をエミュレートするならば、私たちはそれを可能な限り正確に行います！



しかし、タイマーを高速化すると、プログラムの全体的なタイミング、つまりメモリカードのボーレートを調整するクロックに何らかの影響があった場合はどうなるでしょうか。



タイマーコードをコメントアウトしました。エラーは二度と起こりませんでした。ただし、クラッシュがランダムに発生したため、これは修正したことを意味するものではありません。運が良ければどうなりますか？



数日後、私は再びテストプログラムを試しました。バグは繰り返されませんでした。フルゲームコードベースに戻り、保存コードとロードコードを変更して、プログラム可能なタイマーがメモリカードにアクセスする前に元の値（100Hz）にリセットされ、その後再び1kHzに戻るようにしました。これ以上のクラッシュはありませんでした。



しかし、なぜこれが起こったのですか？



再びテストプログラムに戻りました。 1kHzのタイマーでエラーが発生する際の規則性を見つけようとしました。最終的に、誰かがPS1コントローラーで遊んでいるときにエラーが発生することに気づきました。自分でこれを行うことはめったにないので、保存コードとロードコードをテストするときにコントローラーが必要になるのはなぜですか？ -それから私はこの依存に気づかなかった。しかし、ある日、私たちのアーティストの1人が、私がテストを終了するのを待っていました。おそらくその瞬間、私は呪いをかけていました。エラーが発生しました。 「待って、なに？！じゃあ、またやりなさい！」



これらの2つのイベントが相互に関連していることに気付いたとき、エラーを簡単に再現できました。メモリカードへの書き込みを開始し、コントローラを移動し、メモリカードを損傷しました。私にはそれはハードウェアのバグのように見えました。



私はコニーに行き、私の発見について話しました。彼女はPS1を設計したエンジニアの1人に情報を伝えました。 「不可能だ」と彼は答えた、「それはハードウェアの問題ではありえない」。コニーに話してもらいました。



エンジニアが私に電話し、私たちは彼の壊れた英語と私の（非常に）壊れた日本語で彼と議論しました。最後に、「コントローラーの動きによってバグが発生する30行のテストプログラムを送信します」と言いました。彼は同意した。それは時間の無駄であり、彼は新しいプロジェクトに取り組むのにひどく忙しかったが、私たちがソニーにとって非常に重要な開発者であるために諦めるだろうと言った。私は自分のテストプログラムを片付けて彼に送った。



次の夜（私たちはロサンゼルスにいて、彼は東京にいました）、彼は私に電話して恥ずかしそうに謝罪しました。それはハードウェアの問題でした。



バグが正確に何であるかはわかりませんが、ソニー本社で聞いたところによると、タイマーを十分に高い値に設定すると、タイマークリスタルの近くのマザーボード上のコンポーネントに干渉します。これらの1つは、メモリカードのボーレートコントローラで、コントローラのボーレートも設定しました。私はエンジニアではないので、何か混乱したかもしれません。



しかし、肝心なのは、マザーボード上のコンポーネント間に干渉があったということです。また、1 kHzの周波数で動作するタイマーを使用して、コントローラーポートとメモリカードポートを介してデータを同時に送信すると、ビットが消え、データが失われ、カードが損傷しました。

悪い牛

1980年代に、私のメンターであるセルゲイは、PDP-11のソビエトクローンであるCM-1800用のソフトウェアを作成しました。このマイクロコンピュータは、ソ連の重要な輸送ハブであるスヴェルドロフスク近くの鉄道駅に設置されたばかりです。新しいシステムは、ワゴンと貨物の流れのルーティング用に設計されました。しかし、それはランダムなクラッシュとクラッシュにつながる厄介なバグであることが判明しました。誰かが夕方に家に帰ったとき、常に転倒が起こりました。しかし、翌日慎重に調査したにもかかわらず、コンピューターはすべての手動テストと自動テストで正しく機能しました。これは通常、特定の条件下で現れるレース条件またはその他の同時実行バグを示します。深夜の電話にうんざりしていたセルゲイは、問題の根底に立ち、まず第一に、マーシャリングヤードのどのような状況がコンピューターの故障につながったかを理解することにしました。



最初に、彼は原因不明のすべての転倒に関する統計を収集し、日付と時刻ごとにグラフを作成しました。パターンは明白でした。さらに数日間見た後、セルゲイは将来のシステム障害の時間を簡単に予測できることに気づきました。



彼はすぐに、駅がウクライナ北部とロシア西部から近くの食肉処理場に牛の荷馬車を仕分けしているときにのみ混乱が発生したことを知りました。食肉処理場はカザフスタンにはるかに近い農場から供給されていたため、これ自体は奇妙でした。



チェルノブイリ原子力発電所は1986年に爆発し、放射性降下物により周辺地域は居住できなくなりました。ウクライナ北部、ベラルーシ、ロシア西部の広い地域が汚染されています。到着した車の高レベルの放射線を疑って、セルゲイはこの理論をテストする方法を開発しました。人口は線量計を持つことを禁じられていたので、セルゲイは鉄道駅に数人の軍人を置きました。ウォッカを数杯飲んだ後、彼は何とか兵士を説得して、疑わしい車の1つで放射線のレベルを測定させました。レベルは通常の値の数倍であることが判明しました。



牛は強い放射線を発するだけでなく、そのレベルが非常に高かったため、駅の隣の建物にあったCM-1800のメモリのビットが誤って失われました。



USSRでは食糧が不足していたため、当局は「チェルノブイリ」肉を国内の他の地域の肉と混合することを決定しました。これにより、貴重なリソースを失うことなく、放射能の全体的なレベルを下げることが可能になりました。これを知ったセルゲイは、すぐに移民書類に記入しました。そして、放射線のレベルが時間とともに減少したとき、コンピューターの落下は自然に止まりました。

パイプを通して

Movietech Solutionsはかつて、発券、発券、および一般的な管理のための映画館用のソフトウェアを作成しました。フラッグシップアプリケーションのDOSバージョンは、北米の中小規模の劇場チェーンで非常に人気があります。したがって、Windows 95バージョンが発表され、最新のタッチスクリーンとセルフサービスキオスクと統合され、あらゆる種類のレポートツールが装備されたとき、それも急速に普及したのは当然のことです。ほとんどの場合、更新はスムーズに行われました。現場のITプロフェッショナルが新しいハードウェアをインストールし、データを移行し、ビジネスを継続しました。それが継続しなかったときを除いて。これが起こったとき、会社はジェームズ・ザ・クリーナーを送りました。



このニックネームは悪意のあるタイプを暗示していますが、クリーナーはインストラクター、インストーラー、そしてあらゆる業界のジャックの組み合わせにすぎません。ジェームズは、クライアントの場所ですべてのコンポーネントをまとめるのに数日を費やし、その後数日間、新しいシステムの使用方法をスタッフに教え、発生する可能性のあるハードウェアの問題を修正し、実際にソフトウェアの形成期間を支援しました。



したがって、この忙しい時期に、ジェームズが午前中にオフィスに来て、通常よりもカフェインで満たされた上司に迎えられたとき、彼の机に着く時間がなかったのは当然のことです。



「恐れ入りますが、できるだけ早くノバスコシアのアナポリスに行く必要があります。彼らのシステム全体がダウンし、彼らのエンジニアと一緒に夜を過ごした後、私たちは何が起こったのか理解できません。サーバーにネットワーク障害があるようです。しかし、システムが数分間機能した後でのみ。



-彼らは古いシステムに戻らなかったのですか？ -ジェームズは非常に真剣に答えましたが、彼の心の中で彼は驚いて目を広げました。



-その通り：彼らのITスペシャリストは「優先順位を変更」し、彼は古いサーバーを離れることに決めました。ジェームズ、彼らは6つのサイトにシステムをインストールし、プレミアムサポートの料金を支払ったばかりで、彼らのビジネスは現在1950年代に行われています。



ジェームズは少しまっすぐになりました。



-これは別の問題です。さて、始めましょう。



彼がアナポリスに到着したとき、彼が最初にしたことは、問題を抱えたクライアントの最初の映画館を見つけることでした。空港で撮った地図では、すべてがまともなように見えましたが、目的の住所の周辺は疑わしいようでした。ゲットーではありませんが、フィルムノワールを彷彿とさせます。ジェームズが中央の縁石に駐車すると、売春婦が彼に近づきました。アナポリスの大きさを考えると、それはおそらく街全体で唯一のものでした。彼女の姿はすぐに大画面でお金のためにセックスを提供した有名なキャラクターを思い出させました。いいえ、ジュリア・ロバーツについてではなく、ジョン・ヴォイトについて[映画「ミッドナイト・カウボーイ」のヒント-約。あたり。 ]。



売春婦を家に送った後、ジェームズは映画館に行きました。周囲は良くなりましたが、それでも怪しげな印象があります。ジェームズが心配しすぎたわけではありません。彼はすでに不潔な場所に行っていました。そして、これはカナダでした。そこでは、強盗でさえ、彼らがあなたの財布を受け取った後、あなたに感謝を言うのに十分丁寧です。



映画館の横の入り口は、ぼんやりとした路地にありました。ジェームズはドアに行ってノックした。すぐに彼女はきしみ音を立てて少し開いた。



-あなたはきれいですか？内からかすれた声が聞こえてきました。



「はい、それは私です…私はすべてを直すために来ました。



ジェームズは映画館のロビーに入った。おそらく他に選択肢がないので、スタッフは訪問者に紙のチケットを発行し始めました。これは、より興味深い詳細は言うまでもなく、財務報告を困難にしました。しかし、スタッフはジェームズに安心して挨拶し、すぐにサーバールームに連れて行った。



一見、すべてが順調でした。ジェームズはサーバーにログインし、通常の疑わしい場所をチェックしました。問題ない。ただし、予防措置として、Jamesはサーバーをシャットダウンし、NICを交換して、システムをロールバックしました。彼女はすぐに完全に働き始めました。スタッフは再びチケットの販売を開始しました。



ジェームズはマークに電話し、状況を報告しました。ジェームズがここにとどまり、予期しないことが起こるかどうかを確認したいと思うかもしれないと考えるのは難しいことではありません。彼は階段を下り、何が起こったのかスタッフに質問し始めました。明らかに、システムは動作を停止しています。彼らはそれをオフにしてからオンにしました、それはうまくいきました。しかし、10分後、システムは落ちました。



ちょうどその瞬間、同様のことが起こりました。突然、発券システムがエラーを出し始めました。スタッフはため息をついて紙のチケットを手に取り、ジェームズは急いでサーバールームに向かった。サーバーはすべて良さそうだった。



その後、従業員の1人が入りました。



-システムは再び機能しています。



ジェームズは何もしなかったので戸惑いました。より正確には、システムを機能させるものは何もありません。彼はログアウトし、電話を取り、会社のサポートチームに電話しました。すぐに同じ従業員がサーバールームに入りました。



-システムは嘘をついています。



ジェームズはサーバーをちらっと見た。色とりどりの形の面白くてなじみのあるパターンが画面上で踊りました-無秩序にねじれ、絡み合ったパイプ。このスクリーンセーバーは一度見たことがあります。それは美しくレンダリングされ、文字通り催眠術をかけられました。





ジェームズがボタンを押すと、パターンが消えました。彼は急いで切符売り場に行き、途中で彼に戻ってきた従業員に会いました。



-システムは再び機能しています。



あなたが精神的にfacepalmを作ることができるならば、それはまさにジェームズがしたことです。スクリーンセーバー。 OpenGLを使用します。したがって、動作中はサーバープロセッサのすべてのリソースを消費します。その結果、サーバーへの各要求はタイムアウトになります。



ジェームズはサーバールームに戻り、ログインして、美しいパイプのスクリーンセーバーを空白の画面に置き換えました。つまり、プロセッサリソースを100％消費するスクリーンセーバーの代わりに、リソースを消費しない別のスクリーンセーバーをインストールしました。それから私は私の推測をチェックするために10分待った。



ジェームズが次の映画館に到着したとき、彼はスクリーンセーバーをオフにするためにちょうど800km飛行したことを上司に説明する方法を考えました。

特定の月のフェーズでクラッシュする

実話。かつて、月の位相に依存するソフトウェアのバグがありました。月の真の位相の近似値を計算するために、さまざまなMITプログラムで一般的に使用される小さなサブルーチンがありました。 GLSは、このサブルーチンをLISPプログラムに組み込み、ファイルの書き込み時に80文字近くのタイムスタンプ付き文字列を出力します。メッセージの最初の行が長すぎて次の行に進むことは非常にまれでした。そして、プログラムがこのファイルを読むと、それは呪われました。最初の行の長さは、正確な日付と時刻、およびタイムスタンプが印刷されたときのフェーズ仕様の長さによって異なります。つまり、バグは文字通り月の位相に依存していました！ジャーゴンファイルの



最初の紙版（Steele-1983）には、説明されているバグにつながるそのような行のサンプルが含まれていましたが、コンポジターはそれを「修正」しました。それ以来、「ムーンフェイズバグ」と呼ばれています。



ただし、仮定には注意してください。数年前、CERN（European Center for Nuclear Research）のエンジニアは、Large Electron-PositronColliderで実行された実験でエラーに遭遇しました。コンピュータは、科学者に結果を表示する前に、このデバイスによって生成された膨大な量のデータを積極的に処理しているため、多くの人は、ソフトウェアが月の位相に何らかの形で敏感であると想定しています。何人かの絶望的なエンジニアが真実の底に達した。月の通過中に地球が変形したため、長さ27 kmのリングの形状がわずかに変化したため、エラーが発生しました。この物語は、「粒子物理学に対するニュートンの復讐」として、そして最も単純な物理法則と最も古い物理法則と最も進んだ科学的概念との関係の例として、物理学者の民俗学に登場しました。

トイレを洗うと電車が止まります

私が聞いた中で最高のハードウェアバグは、フランスの高速列車でした。バグは列車の緊急ブレーキにつながりましたが、乗客が乗っていた場合に限りました。いずれの場合も、列車は運行を停止され、チェックされましたが、何も見つかりませんでした。それから彼はラインに送り返されました、そして彼はすぐに緊急停止しました。



チェックの1つで、電車で移動しているエンジニアがトイレに行きました。すぐにそれはそれ自体の後に洗い流されました、ブーム！緊急停止。



エンジニアは運転手に連絡して尋ねました：



-ブレーキをかける直前に何をしましたか？



-ええと、



下り坂で減速しました…普通の走行中、坂道で何十回も減速するので不思議でした。列車は進み、次の降下で運転手は警告しました：



-私は減速するつもりです。



何も起こらなかった。



-最後のブレーキングで何をしましたか？-運転手に聞いた。



-ええと...私はトイレにいました...-



さて、トイレに行って、また降りたときにあなたがしたことをしてください！



エンジニアはトイレに行き、運転手が「ブレーキをかけている」と警告したとき、彼は水を洗い流した。もちろん、電車はすぐに止まりました。



今、彼らは問題を再現することができ、原因を見つける必要がありました。



2分後、彼らはエンジンブレーキ用のリモートコントロールケーブル（列車の両端に1つのエンジンがある）が電気キャビネットの壁から外れ、トイレプラグソレノイドを制御するリレーに置かれていることに気づきました...リレーがオンになると、ブレーキケーブルとシステムに干渉しました衝突保護には、緊急ブレーキが含まれていました。

FORTRANを嫌ったゲートウェイ

数か月前、本土（これはハワイにありました）のネットワーク接続が非常に遅くなっていることに気づきました。それは10〜15分続き、その後突然再び現れる可能性があります。しばらくすると、私の同僚から、本土のネットワーク接続がまったく機能していないと不満が出ました。彼は、本土のマシンにコピーする必要のあるFORTRANコードをいくつか持っていましたが、「ネットワークがFTPダウンロードを完了するのに十分な長さではなかった」ため、機能しませんでした。



はい、同僚がFORTRANソースファイルを本土のマシンにFTPで転送しようとしたときに、ネットワークの停止が発生したことが判明しました。ファイルをアーカイブしようとしましたが、静かにコピーされました（ただし、ターゲットマシンにアンパッカーがなかったため、問題は解決しませんでした）。最後に、FORTRANコードを非常に小さなチャンクに「分割」し、一度に1つずつ出荷しました。ほとんどのフラグメントは問題なくコピーされましたが、一部は機能しなかったか、何度も試行した後に機能しました。



問題のフラグメントを調べたところ、共通点があることがわかりました。すべて、大文字のC文字で構成される行で開始および終了するコメントのブロックが含まれています（同僚がFORTRANにコメントすることを好むため）。本土のネットワーキングスペシャリストにメールを送り、助けを求めました。もちろん、彼らはFTP経由で送信できないファイルのサンプルを見たいと思っていました...しかし私たちの手紙は彼らに届きませんでした。最後に、転送されないファイルがどのように見えるかについての簡単な説明を思いつきました。それはうまくいきました：）[FORTRANに関する問題のあるコメントの1つの例をここに追加しますか？おそらくそれだけの価値はありません！]



結局、私たちはそれを理解することができました。最近、キャンパスの私たちの部分と本土のネットワークの間に新しいゲートウェイが設置されました。彼は、大文字のCが重複しているパケットを送信するのに非常に苦労しました。これらのパケットのうち、ゲートウェイのすべてのリソースを使用して、他のほとんどのパケットの突破を防ぐことができるのはごくわずかです。私たちはゲートウェイメーカーに不平を言いました...そして彼らは私たちにこう言いました：「ああ、はい、あなたは重複したCバグに遭遇しました！私たちはすでに彼について知っています。」結局、別のメーカーから新しいゲートウェイを購入することで問題を解決しました（前者を守るために、誰かのためにプログラムをFORTRANに転送できないことは利点かもしれません！）。

厳しい時代

数年前、フェーズ3の臨床試験のコストを削減するように設計されたPerl ETLシステムに取り組んでいる間、私は約40,000の日付を処理する必要がありました。それらのうちの2つはテストに合格しませんでした。これらの日付はクライアントから提供されたデータから取得されたため、これはあまり気になりませんでした。これは、たとえば、驚くべきことでした。しかし、初期データを確認したところ、2011年1月1日と2007年1月1日であることがわかりました。今書いたプログラムにバグがあると思いましたが、すでに30年前のものでした。これは、ソフトウェアエコシステムに慣れていない人には不思議に聞こえるかもしれません。別の会社がお金を稼ぐという長年の決定のために、私のクライアントは、ある会社が誤って導入したバグと別の会社が意図的に導入したバグを修正するために私に支払いました。これが何であるかを理解するために、その結果バグとなった機能を追加した会社と、私が修正した不思議なバグの原因となった他のいくつかの奇妙なイベントについて説明する必要があります。



古き良き時代には、Appleコンピューターは時々自発的に日付を1904年1月1日にリセットしました。理由は単純でした。バッテリー駆動の「システムクロック」を使用して日付と時刻を追跡しました。バッテリーが切れるとどうなりましたか？コンピュータは、時代の始まりから秒数で日付を追跡し始めました。エポックは参照元の日付を意味し、Macintoshの場合は1904年1月1日でした。バッテリーが切れた後、現在の日付は指定された日付にリセットされました。しかし、なぜこれが起こったのですか？



以前は、Appleは元の日付からの秒数を格納するために32ビットを使用していました。 1ビットは2つの値の1つを格納できます-1または0。2ビットは4つの値の1つを格納できます：00、01、10、11。3ビット-8つのうちの1つの値：000、001、010、011、100、101、 110、111など。そして、32は2つの³²値の1つ、つまり4 294 967296秒を格納できます。 Appleの日付の場合、これは約136年前のものであったため、古いMacは2040以降の日付を処理できません。また、システムバッテリーがなくなると、日付はエポックの開始から0秒にリセットされ、コンピューターの電源を入れるたびに（または新しいバッテリーを購入するまで）手動で日付を設定する必要があります。



ただし、エポックの開始から秒単位で日付を保存するというAppleの決定は、エポックの開始前の日付を処理できないことを意味しました。これは、後で説明するように、広範囲にわたる影響を及ぼしました。 Appleは、バグではなく機能を導入しました。とりわけ、これは、Macintoshオペレーティングシステムが「ミレニアムバグ」（制限を回避するための独自の日付システムを備えた多くのMacアプリケーションについては言えない）の影響を受けないことを意味しました。



進め。アップルのコンピューターにはVisiCalcが搭載されていたため、パーソナルコンピューターは成功しましたが、IBMが開発したPC革命の開始を支援した「キラーアプリケーション」であるLotus1-2-3を使用しました。公平を期すために、1-2-3が登場していなかったら、PCはほとんど離陸しなかったでしょうし、パーソナルコンピュータの歴史は非常に異なって発展していたでしょう。 Lotus 1-2-3は、1900を飛躍の年として誤って扱いました。 Microsoftが最初のMultiplanスプレッドシートをリリースしたとき、市場シェアは小さかった。また、Excelプロジェクトを立ち上げたとき、Lotus 1-2-3から行と列の命名スキームをコピーするだけでなく、バ​​グとの互換性を確保することを決定し、意図的に1900を飛躍の年として扱いました。この問題は今日まで続いています。つまり、1-2-3ではそれはバグであり、Excelではそれは保証された意図的な決定でした1-2-3のすべてのユーザーは、間違っていても、データを変更せずにスプレッドシートをExcelにインポートできます。



しかし、別の問題がありました。マイクロソフトは、Macintosh用のExcelを最初にリリースしましたが、1904年1月1日まで日付を認識しませんでした。Excelでは、時代の始まりは1900年1月1日でした。そのため、開発者は、プログラムがエポックのタイプを認識し、目的のエポックに従ってデータを内部に格納するように変更を加えました。マイクロソフトはこれについての説明記事さえ書いた。そして、この決定は私のバグにつながりました。



私のETLシステムは、Windowsで作成されたExcelスプレッドシートを顧客から受け取りましたが、Macでも作成できました。したがって、表の時代の始まりは、1900年1月1日または1904年1月1日のいずれかである可能性があります。見つける方法は？ Excelファイル形式には必要な情報が表示されますが、使用したパーサーは表示されず（現在は表示されます）、特定のテーブルの時代を知っていることを前提としています。おそらく、Excelバイナリを理解し、パーサーの作成者にパッチを送信することにもっと時間を費やすことができましたが、クライアントのためにやることがたくさんあったので、エポックを決定するためのヒューリスティックをすばやく作成しました。簡単でした。



Excelでは、1998年7月5日の日付は、「07-05-98」（役に立たないアメリカのシステム）、「98年7月5日」、「1998年7月5日」、「98年7月5日」などの形式で表すことができます。別の役に立たないフォーマット（皮肉なことに、私のバージョンのExcelが提供しなかったフォーマットの1つはISO 8601標準でした）。ただし、テーブル内では、フォーマットされていない日付は、エポック-1900の場合は「35981」、エポック-1904の場合は「34519」として格納されていました（数字はエポックの開始からの日数を表します）。単純なパーサーを使用してフォーマットされた日付から年を抽出し、次にExcelパーサーを使用してフォーマットされていない日付から年を抽出していました。両方の値が4年異なる場合、私はera-1904でシステムを使用していることを理解しました。



フォーマットされた日付だけを使用しなかったのはなぜですか？ 1998年7月5日は、日付を省略して「98年7月」とフォーマットできるためです。非常に多くの企業からテーブルを受け取り、さまざまな方法でテーブルを作成したため、私たち（この場合は私）は日付を処理する必要がありました。さらに、Excelがそれを正しく行うのであれば、そうすべきです！



それから私は39082に出くわしました。ロータス1-2-3は1900年を飛躍の年と見なし、これはExcelで忠実に繰り返されたことを思い出させてください。そして、これにより1900年に1日が追加されたため、その日には多くの日付関数が間違っている可能性があります。つまり、39082は2011年1月1日（Macの場合）または2006年12月31日（Windowsの場合）である可能性があります。私の「年パーサー」がフォーマットされた値から2011を抽出していた場合、すべてが正常です。ただし、Excelパーサーは使用するエポックを認識しないため、デフォルトでepoch-1900になり、2006が返されます。私のアプリケーションは、5年の違いがあることを確認し、それをエラーと見なし、ログに記録して、フォーマットされていない値を返しました。



これを回避するために、私はこれを書きました（疑似コード）：

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

そして、40,000の日付すべてが正しく解析されました。

大規模な印刷ジョブの真っ只中に

1980年代初頭、私の父は、高速テープ送り用のテープドライブと空気圧システムを構築していた廃止されたビジネスユニットであるStorageTechnologyで働いていました。



彼らは、1つの中央ドライブ「A」を7つのドライブ「B」に接続できるようにドライブを再設計し、ドライブ「A」を制御するRAM内の小さなOSが、すべてのドライブ「B」に読み取りおよび書き込み操作を委任できるようにしました。



ドライブ「A」が起動するたびに、オペレーティングシステムをメモリにロードするために、「A」に接続された周辺ドライブにフロッピーディスクを挿入する必要がありました。それは非常に原始的でした：処理能力は8ビットマイクロ波によって提供されました。



このような機器の対象読者は、銀行や小売チェーンなど、非常に大規模なデータストアを持ち、多くの住所ラベルや銀行の明細書を印刷する必要のある企業でした。



1人のクライアントに問題がありました。印刷ジョブの途中で、特定のドライブ「A」が動作を停止し、ジョブ全体が起動する可能性があります。ドライブを動作に戻すには、スタッフがすべてを再起動する必要がありました。そして、これが6時間のタスクの途中で発生した場合、膨大な量の高価なコンピューター時間が無駄になり、操作全体のスケジュールが中断されました。



StorageTechnologiesは技術者を派遣しました。彼らの最善の努力にもかかわらず、彼らはテスト条件でバグを再現することができませんでした：それは大規模な印刷ジョブの途中で発生したようです。問題はハードウェアにあるのではなく、RAM、マイクロコンピューター、フロッピードライブ、テープドライブの考えられるすべての部分など、可能な限りすべてを交換しました。問題は解決しませんでした。



次に、技術者は本部に電話し、専門家に電話しました。



審査官は椅子と一杯のコーヒーを手に取り、コンピューター室に座りました-当時はコンピューター専用の部屋がありました-そしてスタッフが大きな印刷物の仕事を列に並べるのを見ました。専門家は失敗が起こるのを待ちました-そしてそれは起こりました。誰もがエキスパートを見ました-そして彼はなぜこれが起こったのか分かりませんでした。そのため、彼はタスクを再びキューに入れるように命令し、技術者を持つすべての従業員が仕事に戻りました。



専門家は再び椅子に腰を下ろし、失敗を待ちました。約6時間かかり、故障が発生しました。専門家は、すべてが人でいっぱいの部屋で起こったことを除いて、再び考えを持っていませんでした。彼は任務を再開するように命じ、再び座って待った。



3番目のグリッチまでに、エキスパートは何かに気づきました。担当者が外付けドライブのベルトを交換したときに障害が発生しました。さらに、従業員の1人が床の特定のタイルを通過するとすぐにクラッシュが発生しました。



隆起した床は、高さ6〜8インチのアルミニウムタイルでできていました。誰かが誤って重要なケーブルを踏まないように、多数のコンピューターケーブルが隆起した床の下を走っていました。タイルは、破片が隆起した床の下に入るのを防ぐために非常にしっかりと置かれました。



専門家は、タイルの1つが変形していることに気づきました。従業員がその角を踏んだとき、タイルは隣接するタイルに対してその端をこすりました。彼らはまた、タイルを接続しているプラ​​スチック部品をこすり、それが静的な微小放電を引き起こし、それが無線周波数干渉を引き起こした。



今日、RAMは無線周波数干渉からはるかによく保護されています。しかし、当時はそうではありませんでした。専門家は、これらの干渉がメモリを妨害し、それによってオペレーティングシステムの動作が妨害されることに気づきました。彼は護衛サービスに電話し、新しいタイルを注文し、自分で取り付けたところ、問題は解決しました。

潮だ！

物語は、ドックサイドエリアのポーツマス（私は思う）のオフィスの4階または5階にあるサーバールームで行われました。



ある日、メインデータベースを備えたUnixサーバーがクラッシュしました。彼は再起動されましたが、喜んで何度も何度も転倒し続けました。サポートサービスから誰かに電話することにしました。



サポート男...彼の名前はマークだったと思いますが、それは問題ではありません...私は彼を知っているとは思いません。本当に関係ありません。マークにとどまりましょうね 優れた。



それで、数時間後、マークが到着し（リーズからポーツマスまで、パスは近くありません）、サーバーの電源を入れ、すべてが問題なく機能しました。典型的なクソサポート、顧客はそれについて非常に腹を立てます。マークはログファイルを調べて、問題のないものを見つけました。それからマークは電車に戻ります（または彼が取った輸送手段が何であれ、私が知る限りそれは足の不自由な牛だったかもしれません...まあ、それは問題ではありません、いいですか？）そしてリーズに戻って一日を無駄にします。



その夜、サーバーが再びクラッシュします。話は同じです...サーバーは上昇しません。マークはリモートで支援しようとしますが、クライアントはサーバーを起動できません。



別の電車、バス、レモンメリンゲまたは他のでたらめ、そしてマークはポーツマスに戻ってきました。ほら、サーバーは問題なく起動します！奇跡。マークは、オペレーティングシステムまたはソフトウェアにすべてが正常であることを数時間チェックし、リーズに行きます。



日中頃、サーバーがクラッシュします（気楽に！）。今回は、ハードウェアサポート担当者を招いてサーバーを交換するのが賢明なようです。しかし、いや、約10時間後にも落ちます。



この状況は数日間繰り返されました。サーバーは稼働しており、約10時間後にクラッシュし、次の2時間は起動しません。彼らは冷却、メモリリークをチェックし、すべてをチェックしましたが、何も見つかりませんでした。その後、クラッシュは停止しました。



気にせず一週間が過ぎました...みんな幸せでした。すべてが再び始まるまで幸せです。写真は同じです。 10時間の作業、2〜3時間のダウンタイム..。



そして、誰か（この人はITとは何の関係もないと私に言ったと思います）



は、「これは潮流です！」と言いました。



叫び声は真っ白な視線で迎えられ、おそらく誰かの手がボタンを振って警備員を呼んだ。



「彼は潮流で働くのをやめます。」



これは、コーヒーを飲みながらタイドイヤーブックをほとんど読まないITサポートスタッフにとっては、まったく異質な概念のように思えます。サーバーは問題なく1週間稼働していたため、潮流とは何の関係もないと彼らは説明しました。



「先週は低潮で、今週は高潮でした。」



ヨットを操作するライセンスを持っていない人のためのちょっとした用語。潮流は月の周期に依存します。そして、地球が回転すると、12.5時間ごとに、太陽と月の引力が津波を発生させます。 12.5時間のサイクルの開始時に満潮があり、サイクルの途中に引き潮があり、満潮の終わりに再び満潮があります。しかし、月の軌道が変わると、引き潮と流れの違いも変わります。月が太陽と地球の間にあるとき、または地球の反対側（満月または月がない）にあるとき、私たちはSyzygy潮を取得します-最高潮と最低潮。半月になると、直交潮流、つまり最低潮流が発生します。 2つの極端な違いは大幅に減少します。月の周期は28日間続きます：syzygy-quadrature-syzygy-quadrature。



潮汐力が技術者に説明されたとき、彼らはすぐに警察を呼ぶことを考えました。そしてそれは非常に論理的です。しかし、その男は正しかったことが判明しました。2週間前、駆逐艦がオフィスの近くにドッキングしていました。潮がそれを特定の高さに上げるたびに、船のレーダーポストはサーバールームの床のレベルになります。そして、レーダー（または電子戦闘装置、または軍の他のおもちゃ）はコンピューターに混乱を引き起こしました。

ロケットの飛行任務

新しいバージョンのオペレーティングシステム、コンパイラ、および言語用に、大規模な（約40万行）ミサイル発射制御および監視システムを移植するように指示されました。より正確には、Solaris7上のSolaris2.5.1から、およびAda83で記述されたVerdixAda Development System（VADS）からAda95で記述されたRationalApex Adaシステムへ。VADSはRationalによって購入され、その製品は廃止されましたが、Rational Apexコンパイラへの移行を容易にするために、VADS固有のパッケージの互換性のあるバージョンを実装しようとしました。



きれいにコンパイルされたコードを取得するために、3人の人が私を助けてくれました。 2週間かかりました。そして、私は自分でシステムを機能させるために働きました。要するに、これは私が今まで遭遇した中で最悪のアーキテクチャとソフトウェアシステムの実装だったので、移植を完了するのにさらに2か月かかりました。その後、システムはテストのために引き渡され、さらに数か月かかりました。テスト中に見つけたバグをすぐに修正しましたが、その数はすぐに減少しました（ソースコードは実稼働システムであったため、その機能は非常に確実に機能し、新しいコンパイラに適応するときに発生したバグを削除する必要がありました）。結局、すべてが正常に機能したとき、私は別のプロジェクトに移されました。



そして感謝祭の前の金曜日に、電話が鳴った。



約3週間後、ロケットの発射がテストされ、カウントダウンの実験室テストでは、コマンドのシーケンスがブロックされました。実生活では、これはテストの中断につながり、エンジンを始動してから数秒以内に閉塞が発生した場合、補助システムでいくつかの不可逆的なアクションが発生し、ロケットの再準備に時間がかかり、費用がかかります。それは始まりませんが、多くの人々は時間の損失と非常に非常に大きなお金に非常に腹を立てるでしょう。国防省が不用意にお金を使っていると誰にも言わせないでください。予算が最初でも2番目でもない、スケジュールが続く1人の契約マネージャーにまだ会っていません。



前の月に、このカウントダウンテストは多くのバリエーションで何百回も実行されましたが、わずかな問題がありました。したがって、これが発生する可能性は非常に低いですが、その結果は非常に重要でした。これらの両方の要素を掛け合わせると、ニュースが私と数十人のエンジニアとマネージャーにとって台無しにされた休日の週を予測したことが理解できます。



そして、システムを移植した人として私に注目が集まった。



ほとんどのセキュリティクリティカルなシステムと同様に、多くのパラメータがここに記録されたため、システムがクラッシュする前に実行された数行のコードを特定するのはかなり簡単でした。そしてもちろん、それらについてはまったく異常なことは何もありませんでした。同じ実行中に、同じ式が文字通り何千回も正常に実行されました。



彼らがコンパイラを開発し、彼らが開発したルーチンのいくつかが疑わしいコードで呼び出されたので、私たちはApexからRationalに人々を呼びました。彼ら（そして他のすべての人）は、文字通りの国家的重要性の問題の原因を見つける必要性に感銘を受けました。



ログには何も面白いものがなかったので、地元の研究所で問題を再現することにしました。イベントは約1000回の実行ごとに発生するため、これは簡単な作業ではありませんでした。考えられる理由の1つは、ベンダーが開発したミューテックス関数（VADS移行バッチの一部）の呼び出しでした。Unlockロック解除には至りませんでした。呼び出し元のスレッドは、名目上1秒ごとに到着するハートビートメッセージを処理しました。周波数を10Hz、つまり1秒間に10回に上げて、実行を開始しました。約1時間後、システムはロックされました。ログでは、記録されたメッセージのシーケンスが失敗したテスト中と同じであることがわかりました。さらに数回実行すると、システムは開始後45〜90分で安定してブロックされ、ログに同じトラックが含まれるたびにブロックされました。現在、技術的に異なるコードを実行していましたが（メッセージレートが異なりました）、システムの動作が繰り返されたため、このロードシナリオで同じ問題が発生することを確認しました。



ここで、一連の式のどこでブロッキングが発生したかを正確に把握する必要がありました。



この実装はAdaタスクシステムを使用しており、非常によく使用されていませんでした。タスクは、Adaで同時に実行可能な高レベルの構造であり、実行スレッドのようなものであり、言語自体に組み込まれています。 2つのタスクが相互作用する必要がある場合、それらは「ランデブー」し、必要なデータを交換してから、ランデブーを停止して、独立したパフォーマンスに戻ります。ただし、システムの実装は異なります。ターゲットがランデブーした後、そのターゲットは他のターゲットとランデブーし、次に3番目のターゲットとランデブーし、以下同様に、いくつかの処理が完了するまで続きます。その後、これらのランデブーはすべて終了し、各タスクは実行に戻らなければなりませんでした。つまり、私たちは世界で最も高価な関数呼び出しシステムを扱っていました。これにより、入力データの一部を処理している間、「マルチタスク」プロセス全体が停止しました。以前は、スループットが非常に低いという理由だけで問題が発生することはありませんでした。



このタスクメカニズムについて説明したのは、ランデブーが要求されたとき、または完了すると予想されたときに、「タスクの切り替え」が発生する可能性があるためです。つまり、プロセッサは、実行の準備ができている別のタスクの処理を開始できます。あるタスクが別のタスクとランデブーする準備ができると、まったく異なるタスクの実行が開始され、最終的に制御が最初のランデブーに戻ることがわかります。また、タスクの切り替えにつながる他のイベントが発生する可能性があります。そのようなイベントの1つは、ミューテックスの印刷や実行などのシステム関数呼び出しです。



問題の原因となっているコード行を理解するには、タスクの切り替えをトリガーせずに式のシーケンスの進行状況を記録する方法を見つける必要がありました。これにより、クラッシュの発生を防ぐことができます。だから私は利用できませんでしたPut_Line()I / O操作を実行しない。カウンタ変数などを設定することもできますが、画面に表示できない場合はどうすればその値を確認できますか？



また、ログを調べたところ、ハートビートメッセージの処理がフリーズし、プロセスのすべてのI / O操作がブロックされ、他の処理を実行できなくなったにもかかわらず、他の独立したタスクが引き続き実行されていることがわかりました。つまり、作業は完全にブロックされるのではなく、（重要な）一連のタスクのみがブロックされました。



これは、ブロッキング式を評価するために必要なフックでした。



タスク、列挙型、およびその型のグローバル変数を含むAdaパッケージを作成しました。列挙リテラルは、特定の表現問題の配列（例えば、に接続されましたIncrementing_Buffer_Index、Locking_Mutex、Mutex_Unlocked）、次に割り当て式を挿入し、対応する列挙をグローバル変数に割り当てました。これらすべてのオブジェクトコードは単にメモリ内で一定に保たれているため、実行の結果としてタスクが切り替わる可能性はほとんどありません。まず、実行中にブロッキングが発生し、タスクを元に戻すときに戻らないため、タスクを切り替えることができる式を疑った（いくつかの理由で）。



追跡タスクは単にループで実行され、グローバル変数の値が変更されたかどうかを定期的にチェックしました。変更するたびに、値がファイルに保存されました。その後、少し待って、新しいチェックを行います。問題のある領域でタスクを切り替えるときに、システムが実行対象として選択した場合にのみタスクが実行されたため、変数をファイルに書き込みました。このタスクで何が起こっても、他の無関係なロックされたタスクには影響しません。



システムが問題のあるコードの実行に達すると、グローバル変数は次の式ごとにリセットされることが期待されていました。その後、何かが起こり、タスクの切り替えが発生し、その実行頻度（10 Hz）が監視タスクの頻度よりも低いため、モニターはグローバル変数の値を固定して書き込むことができます。通常の状況では、列挙のサブセットの繰り返しシーケンスを取得できます：タスク切り替え時の変数の最後の値。ハングしているとき、グローバル変数はそれ以上変更されるべきではなく、最後に書き込まれた値は、どの式が実行を完了しなかったかを示します。



トラッキングコードを起動しました。凍っています。そして、監視は時計仕掛けのように機能しました。



ログは予期されたシーケンスで終了しました。これは、ミューテックスが呼び出さUnlockれ、タスクが保留中であったことを示す値によって中断されました。これは、以前の何千もの呼び出しの場合と同様です。



この時点でApexのエンジニアは必死にコードを分析し、理論的にはロックが発生する可能性のあるミューテックス内の場所を見つけました。しかし、特定の時間に発生する特定の一連のイベントのみが閉塞につながる可能性があるため、その確率は非常に小さかった。マーフィーの法則、男の子、それはマーフィーの法則です。



このコードを保護するために、（OSミューテックス機能の上に構築された）ミューテックス関数の呼び出しを、このピースへのミューテックスアクセスを制御する小さなネイティブAdaミューテックスパッケージに置き換えました。



それをコードに貼り付けて、テストを実行しました。 7時間後、コードは引き続き機能しました。



私のコードはRationalに渡され、そこでコンパイル、逆アセンブルされ、問題のあるミューテックス関数で使用されたのと同じアプローチを使用していないことが確認されました。



それは私のキャリアの中で最も混雑したコードレビューでした:)私と一緒の部屋には約10人のエンジニアとマネージャーがいて、さらに12人が会議の電話でつながりました-そして彼らはすべて約20行のコードを調べました。



コードがレビューされ、新しい実行可能ファイルが作成され、正式な回帰テストのために送信されました。数週間後、カウントダウンテストが成功し、ロケットが離陸しました。



さて、これはすべて良くて美しいですが、この話のポイントは何ですか？



それは完全に嫌な問題でした。数十万行のコード、並列実行、12を超える相互作用するプロセス、不十分なアーキテクチャと不十分な実装、組み込みシステムのインターフェイス、および数百万ドルの費用。プレッシャーはありませんよね。



この問題に取り組んでいるのは私だけではありませんでしたが、移植を行っているときに脚光を浴びていました。しかし、私がそれを行ったとしても、これは、私が数十万行のコードすべてを理解した、または少なくともそれらをざっと読んだという意味ではありません。コードとログは全国のエンジニアによって分析されましたが、彼らが失敗の原因について彼らの仮説を私に言ったとき、私はそれらを論駁するのに30分かかりました。そして、理論を分析するように頼まれたとき、私はそれを他の誰かに渡しました。なぜなら、これらのエンジニアが間違った方向に進んでいることが私には明らかだったからです。傲慢に聞こえますか？はい、そうですが、私は別の理由で仮説と要求を拒否しました。



私は問題の性質を理解しました。それがどこにあるのか、なぜなのか正確にはわかりませんでしたが、何が起こっているのかは正確にわかっていました。



長年にわたり、私は多くの知識と経験を蓄積してきました。私はエイダを使用するパイオニアの一人であり、その長所と短所を理解していました。 Adaランタイムライブラリがタスクを処理し、並列実行を処理する方法を知っています。そして、私はメモリ、レジスタ、アセンブラのレベルでの低レベルのプログラミングが得意です。言い換えれば、私は自分の分野に深い知識を持っています。そして、私はそれらを使用して問題の原因を見つけました。バグを回避するだけでなく、非常に機密性の高い実行環境でバグを見つける方法を見つけました。



コードとの闘いのそのような話は、そのような闘争の特殊性と条件に精通していない人にとってはあまり興味深いものではありません。しかし、これらのストーリーは、本当に難しい問題を解決するために何が必要かを理解するのに役立ちます。



本当に難しい問題を解決するには、単なるプログラマーではない必要があります。コードの「運命」、コードがその環境とどのように相互作用するか、および環境自体がどのように機能するかを理解する必要があります。



そして、あなたはあなたの甘やかされて育った休日の週を持っています。

---

つづく。