| キーワードシソーラス （同義語・類義語） このページは 2007 年 09 月 07 日 18時15分56秒 にクロールしたキャッシュ情報です。 |
本物
[ 37] The Real Programmer Stories
[引用サイト] http://www.genpaku.org/realprogrammerj.html
|
html-lintを使って体裁を修正。わ〜い 100点だ〜。Ｄ論発表が１週間後だってのに、いったいなにやってんだおれ。 本物のプログラマに関する物語を送ってくれた皆さん、ありがとう。正直言って、私が思ってた以上のバージョンが存在してました。 たくさんの人がこの文書を forward してくれと頼んできたので、ここにpost するのがいちばんいいと思いました。 古き良き時代にたちかえってみよう--男たちと少年たちを簡単に見分けられた、コンピュータの「黄金時代」に (文学的には ``本物の男たち'' と ``Quiche Eaters [訳注 1]'' とよばれることもあった)。この時代、本物の男たちはコンピュータプログラミングを理解していたし、Quiche Eaters はそうじゃなかった。本物のコンピュータプログラマは ``DO 10 I=1,10'' とか ``ABEND'' といった具合に物事を話し(かれらはふつう、大文字、大声で話していたんだ、わかるね)、それ以外の連中は``コンピュータは難しすぎるよ'' とか、``コンピュータには馴染めないね、非人間的すぎるんだ'' なんて話していた (過去の研究 [1]では、本物の男たちは何ものにも馴染むことはしなかったし、非人間的であることを恐れなかったと指摘されている)。 しかし、何ごともそうであるように、時代は変わった。私たちが今日直面しているのは、ちっちゃなおばあちゃんがコンピュータ内蔵式の電子レンジを買い、12歳の坊主どもがアステロイドやパックマンで遊ぶために本物の男たちをはじき飛ばす、そして誰もが自分用のパーソナルコンピュータを買って使いこなすことさえできる、そんな世界なのだ。本物のプログラマは絶滅の危機に瀕しており、TRASH-80 [訳注 2] を使う高校生にとって替わられようとしている。 パックマンで遊ぶ典型的な高校2年生と、本物のプログラマの違いを指摘しておく必要があるだろう。この違いを明らかにすることで、こうしたゲーム少年たちに大いなる希望となるような役割モデル、つまりは理想の父親像を与えることができるだろう。また、本物のプログラマの雇用者にとっては、(人件費を大幅に抑えられるからといって) 本物のプログラマ要員を12歳のパックマンプレイヤーに置き換えるのがなぜ誤りであるのかを説明することにもなるだろう。 [訳注 1] Quiche（キッシュ）とは甘くないタルトのような菓子で、軟弱な女子供の典型的な食べ物。Quiche Eater とは、女々しい軟弱者の意味。 大衆の中から本物のプログラマを選り分けるには、彼(彼女)の使う言語をきいてみたらよい。本物のプログラマは FORTRAN を使う。Quiche Eater たちは PASCAL を使う。PASCAL を設計した Nicklaus Wirth は、かつて``あなたのお名前はどう発音したら良いのでしょう？''ときかれて、こう答えた。``名前そのまま `Veert' と読んでもらってもいいし、その返り値のとおり `Worth' と読んでもらってもいい。'' このコメントから、Nicklaus Wirth は Quiche Eater だということがわかるだろう。本物のプログラマが支持するパラメータ受渡しのメカニズムは、IBM/370 FORTRAN G and H コンパイラに実装されているように call-by-value-return だけなのだ。本物のプログラマは、ジョブをこなすのに、そんな抽象概念をまったく必要としない -- 彼らはキーパンチャーとFORTRAN IV コンパイラ、そしてビールがあれば完璧に幸福になれるのだ。 もし FORTRAN で出来なければ、アセンブリ言語でやる。アセンブリ言語で出来なきゃ、それはやる価値がないのだ。 コンピュータサイエンスの学者連中は、過去何年にもわたってさかりがついたように``構造化プログラミング''にのぼせ上がっている。連中は、プログラマが特製の言語構成と技法を使えば、プログラムはもっと解りやすくなるのだ、と主張している。連中は、どういう構成が一番良いのかはいうまでもなく、特定条件下での知見をわかりづらい学術誌の1ページにぴったり収めて出してくる場合でさえ、意見がわかれている -- 誰もが納得するには、明らかに証拠不足なのだ。学校を卒業したとき、著者は自分が世界一のプログラマだと考えていた。必勝の tic-tac-toe プログラムを書けたし、5種類のプログラミング言語をこなし、1000行のプログラム、それもちゃんと動くやつも書けたからだ (本当だ!)。そこで著者は本物の世界に飛び込んだ。本物の世界で最初の任務は、200,000 行の FORTRAN プログラムを読んで理解し、そしてそれを2倍にまで高速化することだった。本物のプログラマは誰だって、世界中にある構造化コーディングが、こんな場合には何の手助けにもならないってことを教えてくれるだろう -- 本物の、実力が、必要なのだ。本物のプログラマと構造化プログラミングに関する観察から、以下のことがわかる： 本物のプログラマは自己拡張コードを書く。とりわけ、タイトなループの途中で 20 ナノセカンドを節約できる場合には。 FORTRAN では IF 文や REPEAT...UNTIL、や CASE 文が構造化されていないので、本物のプログラマはこれらを使わないことを気に病む必要はない。そのうえ、これらの文は GOTO 指定で必要に応じて代替可能である。 最近はデータ構造にもいろいろな型がある。抽象データ型や構造体、ポインタ、リスト、文字列などは、一部のグループでは普及しつつある。Wirth (前述の Quiche Eater) は、プログラムをデータ構造に基づいて書くことが出来ると主張して、実際に本まで出している。だが、本物のプログラマなら誰でも知っているとおり、有用なデータ構造は配列しかないのだ。文字列も、リストも、構造体も、セットも -- これらはすべて、配列の特殊な場合であり、プログラミング言語をやたらと複雑化したりしなくても、そのとおり扱うことが出来るのだ。こうした突飛なデータ型の最悪な点は、使うたびにいちいち宣言してやらなければならないというところだ。本物のプログラミング言語は、ご存知のとおり、変数名 (6文字) の最初の1文字に基づいた明示的な型設定を備えているものだ。 本物のプログラマは、どんなオペレーティングシステムを使うのだろうか? CP/M? 禁断の−CP/M は、なんといっても基本的に玩具OSである。CP/M など、ちっちゃなおばあちゃんや小学生でも理解して使うことが出来る。 もちろん、Unix はもう少し複雑だ -- 典型的な Unix ハッカーは、今週の PRINT コマンドがなんて名前になってるか憶えていられない -- しかしはっきり言って、Unix はテレビゲームの豪華版だ。Unix システムで本気で仕事をする奴はいない：UUCPネットでジョークを世界中に飛ばし、冒険ゲームとリサーチペーパーを書くだけの話だ。 いいや、本物のプログラマはOS/370を使うのだ。良きプログラマなら、IJK305I というエラー出力の意味するところを JCL マニュアルから導き出すことが出来るだろう。優れたプログラマなら、JCL をマニュアルをまったく見ずに書くことが出来よう。真に傑出した能力を持つプログラマなら、6メガバイトのコアダンプに埋もれたバグを、16進計算機を使わずに見つけ出すことも出来よう。(著者は実際にその現場を目撃したことがある) OSは間違いなく素晴らしいオペレーティングシステムだ。スペースの位置をたった1箇所間違えるだけで、過去何日分もの仕事をすべて消滅させてしまうことも出来る。だからプログラミング要員への注意喚起もスムーズだ。このシステムを扱うには、キーパンチを使ってやるのが一番いい。OS/370で走る時分割システムがあるなどと主張する輩がいるが、著者は慎重に研究を重ねた結果、彼らが誤っていると結論づける。 本物のプログラマは、どんなプログラミングツールを使うのだろう? 理論的には、本物のプログラマはその手になるプログラムを、コンピュータの前面パネルから直接入力して動かすことができる。コンピュータが前面パネルを備えていた頃、これは時おり、一般的に行なわれていたのだ。典型的な本物のプログラマはブートストラップローダの16進コードを丸ごと憶えていて、プログラムエラーでシステムが破壊されるたびにトグルスイッチで入力したのだ。(その頃は、メモリはメモリだった -- スイッチを切っても、どこかへいったりはしなかった。今日では、メモリは忘れてほしくないことを忘れてしまうか、あるいは忘れてほしいものまで長いあいだ抱え込んでしまうかのどちらかだ.) シーモア・クレイこそは伝説の人物だ。スーパーコンピュータ クレイ I と、コントロールデータ社のほとんどのコンピュータの発明者である彼は、実際に CDC7600 用の最初のオペレーティングシステムを、電源を入れたあと前面パネルのトグルスイッチからメモリへ直接入力したのだ。シーモア、言うまでもなく、彼こそ本物のプログラマだ。 私の好きな本物のプログラマに、テキサスインスツルメンツのシステムプログラマがいる。ある日、重要な仕事を保存している最中にシステムがクラッシュしたというユーザから、長距離電話を受けた。ジムは電話で損傷を修復することができた。彼はまずユーザに指示して、ディスクI/Oのインストラクションコードをトグルスイッチから入力させて、システムテーブルを16進で修復し、レジスタの内容を電話での会話だけで読みとることができたのだ。教訓：本物のプログラマはふつうキーパンチャーとラインプリンタをツールとして使うが、緊急時には前面パネルと電話でこなしてしまう。 ある会社では、テキスト処理はもはや1列に並んで 029 キーパンチャーを使う 10人のエンジニアによってのみ行なわれている。実際に、著者が働くビルにはキーパンチャーは1台もない。この場合、本物のプログラマは``テキストエディタ''プログラムで仕事をこなさねばならない。ほとんどのシステムでは数種類のテキストエディタが選べるようになっているが、本物のプログラマは選ぶときに注意する必要がある。なぜなら、エディタは個人のスタイルを反映するからだ。多くの人は、世界最高のテキストエディタはゼロックスのパロアルト研究所が Alto と Dorado コンピュータで使うよう書いたもの[3]だと考えている。残念ながら、本物のプログラマならば誰も SmallTalk などという名前のオペレーティングシステムはけっして使わないし、コンピュータとマウスで対話したりすることもけっしてないだろう。 ゼロックスエディタのコンセプトは、もっとまっとうな名前のついたオペレーティングシステムで走るエディタに取り込まれている -- EMACS と VI はその2つだ。こうしたエディタは困りものだ。本物のプログラマは``what you see is what you get''なんて、テキストエディタと女については邪悪なコンセプトとしか考えていないのだ。いや、本物のプログラマがほしいのは、``頼んだら、やってくれる (you asked for it, you got it)'' そんなテキストエディタだ -- 複雑で、神秘的で、強力で、情け容赦なく、そして危険なエディタ。TECO は、そんな貴重なエディタだ。 TECO のコマンドシークエンスは、可読テキストと言うよりは、むしろ送電線の輻射雑音に近いと言う観察が報告されている[4]。TECO でとても楽しめるゲームのひとつに、コマンドラインに自分の名前を入力して、何が起こるか当てる、と言うものがある。TECO と対話している間は、ほんのわずかのタイプミスでもプログラムはたいてい破壊されるし、もっと深刻なことも起こりうる -- 繊細かつ神秘的なバグが、それまで動いていたサブルーチンに混入するのだ。 こうした理由から、本物のプログラマは一般にちゃんと動いているプログラムをいじるのを好まない。彼らは、SUPERZAP (か IBM 互換機ではその同等品) という素晴らしいプログラムを使って、バイナリー化されたオブジェクトコードを直接パッチとして当てる方が容易なことを知っているのだ。このプログラムはとてもうまく働くので、IBM上での多くの実行プログラムは、もとの FORTRAN コードとほとんど無縁なものとなっている。多くの場合、オリジナルのソースコードはもはや存在しない。このようにプログラムを fix するときが来たら、本物のプログラマをジョブに投入する以上のことを、マネージャーは考えもしないだろう -- どこから手をつけたらいいかさえ、Quiche Eating な構造化プログラマには解らないだろう。これを ``ジョブ・セキュリティ'' と呼ぶ。本物のプログラマが使わ`ない'ツールを以下に示す： FORTRAN プロセッサ。MORTRAN とか RATFOR といったもの。プログラミング作法 -- Quiche を作るにはいいが。構造化プログラミングに関する上述コメントを参照。 配列のバインドをチェックできるコンパイラ。これらは創造性を失わせ、EQUIVALENCE の面白い用法のうちほとんどを駄目にし、そして negative subscript を使ってオペレーティングシステムのコードを改変することをできなくする。最悪なのは、バインドのチェックが不完全なことだ。 ソースコードのメンテナンスシステム。本物のプログラマなら、自分のコードはカードファイルにきっちり打ち込んでおくものだ。なぜなら、こうすることでプログラムのオーナーは重要なプログラムを無防備な状態でおいておくことができなくなるからだ [5]。 典型的な本物のプログラマは、どこで働いているのだろうか? これほど有能な人物が努力してなすに値するプログラムとは、一体どんなものだろうか? 本物のプログラマの誰一人としてCOBOLで会計プログラム書きやピープル誌の発送先リストのソートに没頭したりしないということは、誰でも知っている。本物のプログラマは地球が震え上がるような任務(それも文字通りのやつ!)をほしがっているのだ。 本物のプログラマはロスアラモス国立研究所に勤めて、クレイ I で走らせる原爆のシミュレーションを書いている。 我々の同胞が露助どもより先に月へ行って帰ってこられた、その大部分は、NASA にいる何千人もの本物のプログラマが努力したおかげだ。 本物のプログラマのうちで最も素晴らしい何人かが、カリフォルニアのジェット推進研究所で働いている。彼らの多くは、パイオニアやボイジャーのオペレーティングシステムを、すみからすみまで知りつくしている。地上の大規模 FORTRAN プログラムと、宇宙機に搭載されたアセンブリ言語のプログラムを一体化して、彼らは操縦と即興演奏の傑作を生み出すことができる -- 打ち上げてから 6年も経過した後で宇宙船を土星の10キロ四方の範囲にヒットさせて、損傷したセンサープラットフォームや通信機やバッテリを修理・バイパスしたりするのだ。うわさによると、本物のプログラマのある1人はなんとかやりくりして、ボイジャー宇宙機に搭載された数百バイトの未使用メモリに、パターンマッチングプログラムを組み込んだという。そのときボイジャーは木星にいて、新しく発見された月を撮影していたのだ。 現在のプランでは、ガリレオ宇宙機は火星を通過して木星にいたるまで、重力アシスト軌道を用いることになっている。この軌道は火星表面からわずか 80±3 キロを通過する。これほど厳しい条件では、誰も PASCAL プログラム(と PASCAL プログラマ)を信用して航法を任せようとはしないだろう。 知ってのとおり、世界中にいる本物のプログラマの多くは合州国政府 -- 主に国防総省 -- のために働いている。いるべき場所にいる、というわけだ。しかしながら最近、本物のプログラマの地平に暗雲がたちこめはじめた。どうやら国防総省にいる高位の Quiche Eater たちが、国防プログラムはすべて ``ADA''((r)国防総省) という大規模統合型言語で書くべきだと決定したようだ。しばらくのあいだ、ADA は本物のプログラミングから得られた教訓に真向から対決する言語 -- 構造化言語、データ型を持つ言語、強力なタイピング、そしてセミコロン -- となるよう運命づけられていると思われた。手短に言って、典型的な本物のプログラマの創造性をすり潰すために設計された言語だ。幸いにして、国防総省が採用した言語は挑むに足るよう改変できる程度には十分に面白い機能を持っている -- それはおそろしく複雑で、オペレーティングシステムをぐちゃぐちゃにしたりメモリを再構成する手法を備えていて、それに Edsgar Dijkstra がこいつを気に入ってない [6]。(Dijkstra は知ってのとおり、``GoTos Considered Harmful'' -- プログラミング技法の画期的作品で、PASCAL プログラマやQuiche Eaterたちに拍手喝采を浴びた本 -- の著者だ。) その上、意志の堅い本物のプログラマなら、どんな言語の上でも FORTRAN を書ける。 本物のプログラマがその信念に妥協して、私たちと同様に、生活破綻よりはましと、充分な金銭的見返りと引き替えに、少しばかりくだらないことがらに手を染めることはあるかもしれない。たとえば、アタリ社でテレビゲームを作っている本物のプログラマもいる。(だけど、テレビゲームでは遊ばない -- 本物のプログラマはコンピュータをいつでも倒せるからね：チャレンジ精神は湧いてこないわけだ。)ルーカスフィルムで働く連中は、みんな本物のプログラマだ。(スタートレックファン 5000万人の金を拒絶するとはいい度胸だ。) コンピュータグラフィックスの世界では、本物のプログラマの割合はやや少ない。これはおそらく、コンピュータグラフィックスの用途がまだ限られているせいだろう。一方、コンピュータグラフィックスはすべて FORTRAN で行なわれているので、COBOL プログラムを書くはめになるのを避けてグラフィックをやっている人が存在する。 一般に、本物のプログラマは仕事するのと同じように遊ぶ -- コンピュータで。彼は、仕事であれ遊びであれ、いずれにせよ楽しんでやっていることなのに雇用主が金を払ってくれることに、常に驚きを感じている (しかし、彼はこの意見を大声で表明しないよう注意を払っている)。本物のプログラマはたまにオフィスの外へ出て、新鮮な空気と1、2杯のビールを取り込む。コンピュータ ルームの外で本物のプログラマを識別するコツを以下に記す： パーティーでは、部屋の隅でオペレーティングシステムのセキュリティとその実現方法について話してるのが本物のプログラマだ。 フットボールの試合観戦では、11x14 インチのファンフォールド紙に出力したシミュレーションと実際のプレイと比較してるのが本物のプログラマだ。 葬儀では、``可哀想なジョージ。心臓病になるまではソートルーチンもちゃんと動いていたのに'' と言ってるのが本物のプログラマだ。 雑貨屋では、缶詰をレジのレーザー読みとり機に自分の手でかけると言い張ってるのが本物のプログラマだ。彼はキーパンチ係が一発で入力に成功するなんて絶対に信じていないからだ。 本物のプログラマがその機能を最大限に発揮するのは、どんな環境だろうか? 本物のプログラマのマネージャーにとって、これは重要な問題だ。要員を 1人雇用するのにかかる費用を考えてみてほしい。彼(または彼女)を、仕事ができるような環境におくのが、一番良いのだ。 本物のプログラマがいままでこなしたプログラムのリスト。各部門ごとに、おおまかな時系列順に束ねられている。 冷めたコーヒーがカップに半分ほど入っている。たまに、コーヒーにタバコの吸殻が浮いていたりする。場合によってはオレンジスカッシュが入っていることもある。 よほど優秀でない限り、OS JCL マニュアルとPrinciple of Operationが、とくに興味のあるページを開いて置いてある。 床にばらまいてあるのはピーナツバター入りチーズバーの包装 -- パン屋で腐る直前にしてあるタイプのやつで、自販機で並んでも、これ以上傷むことはないだろう。 オレオの下にあるのはフローチャート用定規で、この職場の前任者の忘れものだ。(本物のプログラマはプログラムを書くのであって、書類を書くわけではない。そんなのは維持管理屋にやらせろ。) 本物のプログラマは30や40時間、50時間でも、連続して強い緊張のもとで働くだけの能力を持っている。実際、そうすることを望んでいる。本物のプログラマにとっては、トロい反応速度もたいした問題ではない -- それは彼に仮眠をとるチャンスを与えてくれるのだ。スケジュールの密度が充分でない場合、本物のプログラマは細々としてはいるが面白いと思う部分を最初の 9週間をかけてやってしまい、それから最終週に50時間マラソンを 2、3発こなして残りの全部を仕上げる。こうしたやりかたは、プロジェクトを締切どおりに仕上げるのに汲々とするマネージャーから地獄のような言葉を浴びることになるが、文書化してないことの格好の言い訳となる。一般に以下のことがいえる： 本物のプログラマは妻の名を知らないかもしれない。しかし、ASCIIコードテーブル(か EBCDIC)はしっかり憶えている。 本物のプログラマは料理の仕方を知らない。食料品店は午前3時に開いてはいないからだ。本物のプログラマは Twinkies [訳注 3]とコーヒーで生き延びる。 未来だって? 何の? 本物のプログラマは、最近の若い世代のコンピュータプログラマが古い世代と必ずしも同じようには育ってきていないことに、少々危惧しているのだ。彼らの多くはフロントパネルのついたコンピュータを見たことがない。最近学校を卒業した連中には、計算機なしで16進の算術計算ができる奴はめったにいない。最近の大卒連中は作りがヤワだ -- ソースレベルデバッガーや括弧をチェックしてくれるテキストエディタ、それに``ユーザーフレンドリー'' なオペレーティングシステムに守られて、本物のプログラミングを見てない。最悪なのは、FORTRAN をまったく習わずになんとかやりくりして学位まで取っている ``コンピュータ科学者さま'' がいるってことだ! 我々は Unix ハッカーと Pascal プログラマになるよう運命づけられてるのか? 私の経験からは、本物のプログラマの未来は明るい、とだけ報告できる。プログラマはどこにでもいる。OS/370 も FORTRAN も、Pascal プログラマがその世界に幕を引こうと努力しているにも関わらず、死に絶える気配は微塵もない。もっと陰湿な試み、たとえば FORTRAN の構造化なども失敗した。ああ、もちろんいくつかのベンダーが FORTRAN 77 コンパイラとともに現れたが、どれも FORTRAN 66 コンパイラへ変換するようにオプションカードを備えているのだ -- DO ループを、神がお望みのとおりコンパイルするために。 Unix だって、かつて本物のプログラマがそう感じたほどにはひどくないかもしれない。Unix の最新リリースは、本物のプログラマすべてにとっても価値あるオペレーティングシステムになる、そんな潜在能力を秘めている -- 細かいところで互換性のない2つのユーザーインターフェース、難解で複雑なテレタイプドライバ、仮想記憶。``構造化されている'' という事実にさえ目をつぶれば、`C' プログラミングでさえ、その良さがわかるだろう：結局のところ変数型のチェックはないし、変数名は最長7文字だし(10文字か? 8文字か?)、それにボーナスとしてポインタデータ型が加わった -- FORTRAN とアセンブリ言語のいちばんおいしい部分が一緒に入っているようだ。(#define のより創造的用法については何も言うまい.) いいや、未来はけっして暗いわけじゃない。過去数年間にわたって、名のある雑誌までがコンピュータおたくやハッカーの明るい未来について M.I.T. やスタンフォードをまるで僻地扱いしてまで報道した([7], [8])。一体なぜだ? その理由はつまり、本物のプログラミングの精神はこうした若い``男たち女たち''に受け継がれてるからなんだ。この世に悪夢のような仕様要求や、奇怪なバグや、非現実的なスケジュールがある限り、本物のプログラマが存在して、問題を解決し、後世のために文書を救おうと飛び込むんだ。FORTRAN 万歳! 本物のプログラマは仕様書を書かない。ユーザーはどんなプログラムも手に入る身の上を幸運と思い、ありがたくおしいただくべきである。 本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。 本物のプログラマは quiche を喰わない。本物のプログラマは quiche のスペルも知らない。Twinkies と、コーラと、焼けるように辛い四川料理を喰う。 本物のプログラマはフローチャートなぞ書かない。フローチャートは、結局のところ文盲のための文書フォームである。穴居人はフローチャートを描いた；どれだけ描いたか見てみるがいい。 本物のプログラマはマニュアルなぞ読まない。リファレンスへの依存度は初心者と臆病者のバロメーターだ。 本物のプログラマのプログラムは、けっして最初からまともに働かない。しかしマシンに投げ込むと、30時間の連続デバッグをほんの何度か繰り返してパッチが当たり、動くようになる。 本物のプログラマは Fortran を使わない。Fortran は白靴下を履いた臆病者のエンジニアや、パイプ圧フリークや、結晶解析のチビどもが使うものだ。奴らは有限要素解析と核反応炉シミュレーションで喜ぶ。 本物のプログラマはCOBOLを使わない。COBOL はちんけなアプリケーションプログラマが使うものだ。 本物のプログラマは9時から5時まで働かない。もし本物のプログラマが朝 9時に居たら、それは徹夜していたのだ。 本物のプログラマはBASICなど書かない。一般に、12歳以上になってBASIC を書くプログラマはいない。 本物のプログラマは文書を書かない。文書は一覧表や object deck を読めない馬鹿のためにあるのだ。 本物のプログラマは Pascal だの Bliss だの Ada だの、その他もろもろのアカじみたコンピュータ科学用言語は使わない。強力な変数型はオツムの弱い奴らのためのものだ。 本物のプログラマはスケジュールを使わない。スケジュールはマネージャーのゴマすりのためにある。本物のプログラマはマネージャーを未決箱の中に置いておくのを好む。 本物のプログラマは PL-I など使わない。PL/I は COBOL と Fortran のどちらも選べない過保護なガキのためにあるのだ。 本物のプログラマは構造化プログラミングを潔しとしない。構造化プログラミングは強迫症で、早期にトイレを躾られ、ネクタイを締めてよく削った鉛筆を机の上にきれいに並べておくような神経症のためにあるのだ。 本物のプログラマはチームプログラミングという概念を好まない。もちろん、自分がチーフプログラマなら別だ。 本物のプログラマにマネージャーは無用の長物だ。マネージャーは必要悪。マネージャーは同僚連中や小言の生成装置や、上級プランナーやその他の精神欠格者と付き合うときのためにある。 本物のプログラマは浮動小数点演算を軽蔑する。浮動小数点は ``器の小さい'' ニヤけた寝小便たれどものためにあるのだ。 本物のプログラマはオンボロのマーヴェリックなど運転しない。BMWやリンカーンや、フロアシフトのピックアップトラックを好む。かっ飛べるバイクは高く評価される。 本物のプログラマはスケジュールを信用してない。プランナーがスケジュールを作る。マネージャーはスケジュールを ``引き締める''。コーダーは恐がって、スケジュールに合わせようとがんばる。本物のプログラマはスケジュールを無視する。 本物のプログラマは自販機のポップコーンを好む。並のコーダーはそれを電子レンジで熱するが、本物のプログラマはCPUの熱を使う。コーンの破裂をきいて、いまどのジョブが走っているかが解るのだ。 本物のプログラマはインストラクション1つ1つのニュアンスを区別して、どのプログラムでも実際に使い分ける。仔犬並の設計では、例外インストラクションが他の実行プログラムをターゲットインストラクションとしてアドレスするのを認めないだろう。本物のプログラマは、こうしたセコい制限を軽蔑する。 本物のプログラマは茶色いランチバッグを職場に持ち込まない。自販機があればそこで買う。自販機がなければ食べない。自販機は quiche を売ったりしないからだ。 本物のプログラマはディスクが diskであり、disc でないと知っている。Disc と書くのは泣き虫の quiche eater に後押しされたアカの陰謀だ。 そのアナウンスがあったとき、コンピュータ産業は凍りついた。ケン・トンプソン、デニス・リッチー、そしてブライアン・カーニハンが Unix オペレーティングシステムとプログラミング言語C を作ったのは、エイプリルフールの手の込んだ悪ふざけで、どうしたことか20年も続いてしまった、と認めたのだ。最近の UnixWorld ソフトウェア開発フォーラムで、トンプソンは以下のことがらを明らかにした： ``1969年、AT&T は GE/ハネウェル/AT&T 共同の Multics プロジェクトを打ち切ったところだった。ブライアンと私はちょうど、スイスのチューリヒ工科大学の Nichlaus Wirth 教授が作成した Pascal の 早期リリースに向けて、仕事を始めたところだった。私たちはそのエレガントなまでのシンプルさと能力に感銘を受けた。デニスはちょうど、トールキンの有名な 'Lord of the Rings (指輪物語)' の爆笑モノ政治風刺パロディー 'Bored of the Rings (指輪は飽きた)'を読み終えたところだった。そこで私たちは、Multics 環境と Pascal のパロディーという悪ふざけを考えることにした。デニスと私はオペレーティングシステムを担当した。私たちはまず Multics を見て、それから新しいシステムは普通のユーザのフラストレーションができるだけ溜るように、できるだけ複雑怪奇な代物になるようデザインした。これに Multics をもじって Unix という名前をつけ、きわどいけども遠回しにパロディーだとわかるようにもしておいた。それから、デニスとブライアンは Pascal を本当にひねったものを作り、'A' という名前をつけた。他の連中が'A'をもとにして本気でプログラムを書き始めてしまったので、私たちはあわててもっと複雑怪奇な機能を追加していって、B から BCPL、そしてついに C へと進化させた。下に示す文がきっちりコンパイルできるのを確認すると、私たちは進化を止めた： こんな文法を許容してしまうような言語を、まさか現代のプログラマが使うだろうとは、私たちは思っていなかったんだ! 私たちはただ、このシステムをソ連に売れば、連中のコンピュータサイエンスは少なくとも20年ほど退化するだろうなぁ、とか考えてたんだ。AT&T その他の米国企業が本気で Unix と C を使いはじめたときは、驚いたのなんの! この1960年代の技術のパロディーを使って、ほんのちょっとでもまともなプログラムを書こうと思ったら20年の経験がいるんだから。だけど、私たちは Unix と C プログラマの不屈の精神を思い知ることになった (ふつうそんなことはしないが)。ブライアンとデニスと私は、ここ数年来どんな場合でも、ずっと Apple Macintosh 上の Pascal で仕事してきたし、この私たちがずっと昔やったバカなイタズラが、混沌と混乱と、じつに無作法なプログラミングを生んだ責任を痛感してたんだ。'' AT&T、マイクロソフト、ヒューレット-パッカード、GTE、NCR、DECなど、主要な Unix ベンダーとその顧客は、現在のところコメントを控えている。ボーランドインターナショナルは Turbo Pascal、Turbo C、Turbo C++ など著名な製品を擁する Pascal と C 開発環境の最大ベンダーだが、この件については数年前から疑惑を持っており、今後は Pascal 製品の増強をさらに進める一方で、Cの開発は行なわない方針だと語った。IBMのスポークスマンは大笑いを止めることができず、RS-6000 の運命に関する緊急招集会議のニュースは聞くことができなかった。ただ、'VM は本当に、もうすぐ、出る'とだけ伝えた。Pascal や Modula 2、Oberon など構造化言語の生みの親である、チューリヒ工科大学の Wirth 教授は、ただ ``P. T. バーナムは正しかった''とだけ答えた。 関連する最新情報：信頼できる情報筋(ふだんは)によると、上記と同様の告白が、今度はウィリアム・ゲイツ氏の口からMS-DOSとウィンドウズオペレーティングシステムについて行なわれる模様だ。IBM スポークスマンは仮想マシン (VM) 関連製品は内輪の冗談が誤って外部に洩れたものだという噂を否定している。 本物のコンピュータ科学者はコードを書かない。たまにプログラミングシステムをいじり回すが、レベルが高すぎるのでけっしてカウントしない。(そしてめったに正しくカウントできない、正確さはアプリケーション次第)。 本物のコンピュータ科学者はコードにコメントを入れない。識別子が長すぎて、ディスク容量が足りないのだ。 本物のコンピュータ科学者はユーザーインターフェースを書かない。見ためについて考えるなど、滅多にない。 本物のコンピュータ科学者は quiche など食べない。彼らは四川料理を避ける。ハッカーどもが見つけたからだ。本物のコンピュータ科学者の多くは実装のディテールを食べようとする。(その他は切り刻んでハッカーと一緒に食べるが、それはデザートにアイスクリームが出るときだけだ) 対話式のデバッガと、構造エディタと、拡張されたクロスモジュール形式のタイプチェックが完全に揃っていないプログラミング環境では、コンピュータ科学者は手も足も出ないだろう。でも連中は、こうした環境で小切手の収支計算をしなければならないかもしれない。自分のシステムではできないからだ。 本物のコンピュータ科学者はアセンブラでプログラムしない。彼らは2Bの鉛筆以上にポータブルなものでしか書かないのだ。 本物のコンピュータ科学者はプログラムをデバッグしない。動的に変更していくのだ。FORTRAN でも COBOL でも BASIC でも、動的変更の方法を誰も開発していないので、この方が安全なのだ。 本物のコンピュータ科学者はCの構造化のコンセプトを好むが、これに懐疑的でもある。コンパイルされて構造が消えてしまうからだ。(バッチ処理フリークと効率気違いはコンパイラーに腹をたてている。ぜんっぜん動的じゃないからだ。) 本物のコンピュータ科学者は囲碁を好む。山登りに反対する気はないが、実際に登るのは仕様の実装であって、プログラマに任せて放ってある、というわけだ。 本物のコンピュータ科学者はADAをその高い美学的価値ゆえに尊敬する。しかし実際にプログラムするのが至難だとわかった。実装するにはあまりに大きすぎたのだ。ほとんどのコンピュータ科学者はこのことに気づいていない。ADAに追加すべき機能をまだ探しているのだ。 本物のコンピュータ科学者はPM5時からAM9時まで働く。仕様変更に必要な 8メガバイトの主記憶は、その時間にしか使えないからだ。(本物の仕事は動的システムに必要なMIPSが得られる午前2時に始まる)。本物のコンピュータ科学者は、3081s をシェアしていては本物の仕事ができないと知ってるのだ。 本物のコンピュータ科学者は、未来のハードウェアで動く言語の仕様しか書かない。ホモサピエンスなるハードウェアが、たかだか1個の惑星に適合するための仕様でさえ、彼らが書けるかどうか疑わしいのだが。 本物のコンピュータ科学者は、自分の環境でビットマップグラフィックスを使えるように計画をたてるのを好む。ビットマップグラフィックスは素晴らしい。高すぎて誰も買えないだろうから。したがって、彼らのシステムは試作品で終るだろう。 本物のコンピュータ科学者は、PL/1 や PASCAL、LISP などが世に出たことを後悔している。ADAもまたその中に入ろうとしているが、Ada 女史はまだ人々が過ちをおかすのを黙って見ている。 本物のコンピュータ科学者はユーザーのコンセプトを愛する。ユーザーはいつも、同僚のコンピュータ科学者が語ることに驚嘆する；たしかに、それはいま彼らのシステムを使うよう強制されているスタッフの言い分よりは美しく聞こえる。 本物のコンピュータ科学者は現行ハードウェアのアイデアを嫌う。ハードウェアには制限があるが、ソフトウェアにはないからだ。チューリングマシンなど、I/Oまわりがおそろしく貧弱で、実に恥ずかしい代物だと思う。 本物のコンピュータ科学者は会議を愛する。3081 にビットマップスクリーンをつなぎ、それを会議場まで引きずっていくなど、誰も想像できないだろう。だから、連中のシステムがどれだけ遅いか、誰も知らないのだ。 本物のソフトウェアエンジニアはダンプを読まない。ダンプなど絶対にできないし、ごくまれにダンプに出くわしたときは、喜んでヒマつぶしの道具にしてしまうからだ。 本物のソフトウェアエンジニアはコードにコメントを入れない。識別子はコメントする必要がないところまでニーモニックにされてるからだ。 本物のソフトウェアエンジニアはアプリケーションプログラムを書かない。アルゴリズムを実装するのだ。誰かが自分のアルゴリズムを使えそうなプログラムを抱えていたら、喜ぶのだ。だが、彼らにユーザーインターフェースを書けと頼んではいけない。 本物のソフトウェアエンジニアはプログラムをデバッグしない。プログラムの妥当性を確認するのだ。このプロセスでは、必ずしもコンピュータ上で何かを実行するわけではない。おそらく、妥当性確認支援パッケージを走らせる以外は。 本物のソフトウェアエンジニアは C の構造化のコンセプトを好むが、懐疑的でもある。C は``よりマシンに近い''ところをいじれると聞いているからだ。 本物のソフトウェアエンジニアはテニスをする。一般に、彼らは体が熱くなって汗をかくようなスポーツを嫌い、シャワーに当たれないほどデブだ。(だから登山は論外)。たまに職場でもテニスシャツを着ているが、それはよほど熱い日だけだ。 本物のソフトウェアエンジニアは、その理念と徹底した純粋性ゆえに PASCAL を尊ぶが、実際にプログラミングするのは難しいとよくわかった。だがそうなると自分が無価値だということになってしまう。だから、このことは友達にも言っていない。 本物のソフトウェアエンジニアは9時から5時まで働く。仕様だからだ。夜中に働くのは、文書化されてない外部手続きを使うようなものだと感じてるのだ。 本物のソフトウェアエンジニアはどんなマシンにも現実に実装されていない言語で書くが、その言語は公式仕様だけが (BNFで) 決まったものだけだ。こうすることで、彼らはマシン依存性を考慮する煩わしさから逃れているのだ。マシン依存性は本物のソフトウェアエンジニアを憂鬱にする。 本物のソフトウェアエンジニアは ADA を書かない。標準文法が公式な仕様として全然決まってないからだ。 本物のソフトウェアエンジニアは自分専用のコンパイラーを書くのを好む。それも出来ればPROLOGで。(PROLOG 自身を、それも実装されてない言語で書くのも好むが、実際に走らせるのが難しいということがわかったのだ。) 本物のソフトウェアエンジニアは、COBOL と FORTRAN と BASIC が世に出たことを残念だと思っている；PL/1 もその中に入ろうとしているが、批判するほどのものじゃない；組み込み関数が多すぎるのだ。 本物のソフトウェアエンジニアはユーザーの存在にもそれほど幸せを感じていない。ユーザーはアルゴリズムの実装とその検証について、いつも間違ったアイデアを抱えているみたいだからだ。 本物のソフトウェアエンジニアは通路の向うに鎮座していつも仕事を中断させる、不可解で脂ぎったハードウェアを好まない。彼らはハードウェア屋をまったく信用しておらず、マシンがあらゆる階層で仮想化できればいいと思っている。彼らはパーソナルコンピュータを好むかもしれない (こいつらは転送途中に DFA を killして他へ移ったりできないって知ってるね)。もっとも、妥当性検証支援パッケージを走らすには、8メガバイト必要だということを除けばだが。 本物のプログラマは仕様書を書かない -- ユーザーはどんなプログラムも、それが手に入る身の上を幸運と思い、ありがたくおしいただくべきである。 本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属版にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。 本物のプログラマは COBOL を使わない。COBOL はちんけなアプリケーションプログラマが使うものだ。 本物のプログラマのプログラムは、けっして最初からまともに働かない。しかしマシンに投げ込むと、``たった30時間''のデバッグ作業をほんの何度か繰り返すだけでパッチが当たり、動くようになるのだ。 本物のプログラマは Fortran を使わない。Fortran はパイプ圧フリークや、結晶解析のチビどもが使うものだ。 本物のプログラマは9時から5時まで働かない。もし本物のプログラマが朝 9時に居たら、それは徹夜していたのだ。 本物のプログラマはBASICなど書かない。一般に、12歳以上になって BASIC を書くプログラマなどいない。 本物のプログラマはPL/1など使わない。PL/1 は COBOL と Fortran のどちらも選べないプログラマのためのものだ。 本物のプログラマは APL など使わない。どんな馬鹿でも APL を隠れみのにして潜んでいられるからだ。 本物のプログラマはテニスみたいな、いちいち服を着替えなきゃならないスポーツはしない。登山は OK だ。本物のプログラマはマシンルームが突然盛り上がって山になったときに備えて、いつも登山靴を履いている。 本物のプログラマは Pascal だの Bliss だの Ada だの、その他もろもろのアカじみたコンピュータ科学用言語は使わない。強力な変数型はオツムの弱い奴らのためのものだ。 本物のプログラマは自分のマイコンでPASCALコーディングして楽しむ。だが、それは改良するためであって自分自身はけっして使わない。 本物のプログラマは 370 マシンで CP/M を動かしたり、自分の ZX81 マイコンに MVS を載せたりして遊ぶ。 本物のプログラマはセキュリティーシステムを恐れない。セキュリティーデータセットでも RACF ビットを切り、未署名のメッセージを残すのだ。 本物のプログラマはソースをアップデートして ZAP に反映したりしない。つまり ZAP も明日には変更されるわけだ。 この文書は、かつてUSENETを通じて世界中に無償配信されたものの翻訳である。訳者の意向としては内容を不当に改竄しない限り自由に複写、再配布、再利用を認めるものだが (つまり翻訳の改良ならＯＫってことだ)、原著者の意向については不明である。この点を知った上で、読者の責任において利用してほしい。もし原著作権者から何らかのクレームがついた場合は、ただちに削除する予定であることを、あらかじめおことわりしておく。 |
[ 38] 本物と偽物のサイトを組み合わせるフィッシング詐欺
[引用サイト] http://www.atmarkit.co.jp/fsecurity/special/65phishing/phishing01.html
|
特集「いまさらフィッシング詐欺にだまされないために」が掲載されてから約半年が経過した。その間、日本語のフィッシング詐欺メールが数多く出回るようになったり、国内でフィッシング詐欺によるものと思われるクレジットカードの偽造事件が発生したりしている。半年前、「フィッシング」は、「fishing」ではなく「phishing」と綴ると書いたが、もはや、そんな説明は不要なほどメジャーになった。 「いまさらフィッシング詐欺にだまされないために」では、フィッシング詐欺の定義から対策まで、一般的な内容を網羅したが、実際のフィッシング詐欺の手口については深く触れることができなかった。今回は、注意すべきフィッシング詐欺の手口を詳しく解説する。被害に遭わないために相手の手口を知ることは重要である。手口を知ることでどう防御するかを考えることができるからだ。 「ログイン画面はポップアップウィンドウで表示されるもの」と思っている人が多いのではないだろうか。実際に、インターネットバンキングにログインしようとすると、表示中のページの上にログインIDやパスワードを入力するためのウィンドウを表示する銀行がいくつか存在する。 また、「ポップアップウィンドウにはアドレスバーがない」と思っている人も少なくないだろう。そこまで思っていなくとも、アドレスバーが隠されていても気付かなかったり、不審に思わないという人は結構いるのではないだろうか。確かに、以前の銀行のWebサイトなどではログイン画面がアドレスバーを隠したポップアップウィンドウになっていることが多かったので、そう勘違いしてしまう人がいてもおかしくはない。 そこで登場したのが、本物のサイトをバックグラウンドにし、偽サイトをポップアップウィンドウで表示するフィッシング詐欺である。例として、HSBC Bankの本物のWebサイトと偽物のポップアップウィンドウを使ったフィッシング詐欺を見てみよう。 まず、HSBC Bankをかたったメールが送られてくる。本文中のリンクをクリックすると、HSBC BankのトップページとBanking IDなどの情報を入力させるポップアップウィンドウが現れる（ポップアップブロックを無効にしている場合）。HSBC BankのWebページは本物でポップアップウィンドウは偽物だ。バックグラウンドに本物のWebページが表示されていれば、ポップアップの入力画面を疑う人は少ないだろう。それを狙っているのだ。 偽の入力画面を本物らしく見せるため、バックグラウンドに本物のWebサイトを表示している (クリックして拡大) 上記に例として挙げたHSBC Bankの担当者のメールアドレスは、「@」を「＠」に置換してあります テキストメールのように見えるがHTMLメール。偽サイトへは、GoogleとMSNのリダイレクト機能を使って接続する（クリックして拡大） 本文は一見テキストメールのようだが、実はHTMLメールである。テキストのみを使ってテキストメールのふりをしているのである。内容はメールアドレスの確認作業と偽って、フィッシング詐欺サイトに誘導するというものだ。ロゴマークを盗用したり、Webサイトのデザインを模倣したりするフィッシング詐欺メールが多い中、テキストのみのシンプルなものになっている。 最近、こうした手口が増えているが、その理由の1つとして、金融機関などのフィッシング詐欺対策が進んだことが挙げられる。配信するメールをHTMLからテキストに切り替えたり、テキストメールしか送らないことを利用者に知らせたりしている。ウイルスや不正アクセスと同様に、ユーザーの対策意識が高まったり、対策技術が進化したりすると、フィッシング詐欺の手口も巧妙かつ悪質に進化するという“いたちごっこ”が続くのである。 リンクのパス名は、ランダムに選択された無意味な文字の羅列である。これは、スパムフィルタを回避するためだ。リンクをクリックすると、GoogleとMSNのリダイレクト機能を悪用して偽サイトに接続する。 Googleなどが提供しているリダイレクト機能は、本来クリック件数をカウントするためのものだが、フィッシング詐欺ではユーザーを欺くために使われている。一見、Googleにアクセスするかのように見えるからだ。GoogleやMSNだけでなく、eBayやYahoo!などのリダイレクト機能を利用した手口も存在する。 また、この例では、リダイレクト先（href属性値の「target=」の後ろ）をパーセントエンコーディング（URLエンコーディング）して分かりにくくしている。 リンクをクリックすると、GoogleとMSNを経由してフィッシング詐欺へとジャンプするようにしたソース メール本文中のリンクをクリックし、フィッシャー（フィッシング詐欺師）が用意した偽サイトにアクセスすると、HSBC Bankのトップページへ自動的にリダイレクトされる。これは、META要素のhttp-equiv属性でHSBC Bankのトップページをロードするように指定する、という単純な仕掛けだ。 その後、onloadイベント（ページが読み込まれたときに発生する）でwindows.openを呼び出し、本物のサイトの上に偽の入力画面を表示している。このウィンドウのツールバーとアドレスバーはwindows.openのオプションで非表示になっている。アドレスバーが隠されているので、マウスボタンを右クリックし、ページのプロパティを表示させるなどをしなければサイトのURLを確認できない。 ピンク色の部分で本物のサイト（http://www.hsbc.co.uk/1/2/hsbc/about）を表示。緑色の部分で個人情報を入力させる偽のポップアップウィンドウを表示。ツールバー、アドレスバー、スクロールバーを非表示にし、サイズ変更を無効にしている Internet Explorer 6では、［インターネットオプション］−［セキュリティ］−［レベルのカスタマイズ］をクリックすると表示される［セキュリティの設定］ダイアログボックスで、［ページの自動読み込み］を［無効にする］に設定すればMETA refreshによるページの自動読み込みを無効にすることができる。 偽の入力画面に情報を入れて［Verify］ボタンを押すと、確認作業終了のメッセージが表示される。未入力の情報があるとエラーメッセージが表示されるが、でたらめに入力しても確認作業終了のメッセージが表示されるので、入力されたデータのチェックは行われていない。別件では、入力データを本物のサーバに中継して真偽を確認するといった手の込んだ悪質な手口も存在する。 図3 入力画面で［Verify］ボタンを押すと、確認作業終了のメッセージを表示 正式版も公開されたSE-PostgreSQL。今回はTEによる行や関数へのアクセス制御、条件変数のカスタマイズを体験します クライアントには重要な情報がいっぱい。だからこそ彼らは狙うのです。あなたがワナにかかるのをじっと待っている「受動的攻撃」を見抜く！ 「SELinuxは行儀が悪い」のウワサは本当なの？ 代表的な運用監視ツールである、MRTGやNagiosでSELinuxクライアントを監視してみました ApacheでIndexesオプションを削除している管理者は多いはず。その設定を行うべき理由を、“彼ら”の視点とともに考えてみましょう ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠ITトップ｜Security&Trustフォーラム トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
