Line 1: Error: Invalid Blog('by Esehara' )

または私は如何にして心配するのを止めてバグを愛するようになったか

>> Zanmemo

あと何かあれは 「esehara あっと じーめーる」 か @esehara まで

俺が25歳の頃にプログラマーになる機会があった話、そしてプログラマーにならなかった話

 いま、『計算機プログラムの構造と解釈』 を読んでいたりしていた関係で、その辺について書かれた「Javaスクールの危険 - The Joel on Software Translation Project」の文章を興味深く読んでいた。この文章を読みながら、「そういえば俺も知人の紹介でJavaを教えて派遣するという奴を受けたな」ということを思い出した。今回はそのことについて書いておこうと思った。もう時効だからいいと思う。

25歳の頃の俺

 25歳の頃、俺は無職だった。当時、グッドウィルというものがあって、今じゃてんで気かなくなった企業だけど(Wikipediaを見たら廃業していた)、当時は日雇いということでブイブイ言わせていた企業だ。そこで俺は毎日をすごすための小銭を得ていた。そのときに、知人に「もしプログラマーになりたければ、Javaを教えていているところがあるよ」と言われた。俺はそれに興味を持ち、紹介してもらうことにした。一応、そのとき以前にはPerlやVisual Basicをさわっていて、プログラムのことなら多少知っているつもりだったので、それが仕事になるのならば、いいことだと思った。

 その会社では『Javaの絵本 増補改訂版』を使って最終的にはいわゆる台帳システムを三人で組むというところをやる、ということまでを実装する、ということをしていた。それを業務履歴として使い(!)派遣するというシステムをとっていた。

 Javaは、いわゆるオブジェクト志向型プログラミングの先駆的存在としての言語だ、というのが自分の現状の認識ではあるものの、当時はオブジェクト志向の「オ」の字も理解できてはいなかったように思われる。のちのちに、Pythonをやって、その辺をちゃんとわかりやすく教えてくれる人がいたから、やっとオブジェクト志向を覚えられたように思う。

「出来ない奴」

 どうやら周りの人間は、本当にプログラミング初心者であるらしい。それはよかったように思う。例えば、課題として「素数を作成し、それを出力するプログラム」というところだった。課題時間1時間程度あった。

 数をforで回し、溜めておいた素数の数で任意の数を割り、すべて割り切れなかったら素数として登録する、とりあえずのロジックは10分で出来てしまった。目の前に出力される数字を見ながら、余りにも暇であったので、手元の『Javaの絵本』を読んでいた。すると、その講師から「何かわからないことでもあるの?」と聞かれたりしていた。俺がまったく作業しないから、まったくわかっていないんだろうと思われてたのかも知れない。

 「いえ、実はもう素数のプログラムは出来ちゃっているんですよ」と言われ、「だったらもう少し改良したらいいんじゃないか?」と言われたりしていた。他の課題を解けた人は、さらなる課題を与えられていた。俺はこの学校でどう振る舞えばいいかわからなかった。それだけ社会性が無い人間であった(だから無職だったのかもしれないが)。俺はただJavaを見ていた。

 そのあと、Javaアプレットで台帳システムを作ることになり、最後のおさめが入るのだが、しかしそのとき、丁度祖父が倒れて危篤状態になったので、福岡に帰っていった。そのときから、もう縁は無くなってしまった。

そして『計算機プログラムの構造と解釈』に出会う

 今、そして『計算機プログラムの構造と解釈』を読んでいる。これを読みながら、当時のことを思い出していた。今は並列したプロセスの章を読んでいる。

 その話を要約するならば、二つのプロセスが存在している場合、二つのプロセスが同時にデータを読み書きしようとすると、お互いがその「読んだ時点」でのデータを参照するため矛盾というか不正確になってしまう問題が存在してしまう。

 例えで、よく入金管理の話が出てくるので、それで考えてみる。

 俺と貴方が同じ口座を使用している。俺はある時点、つまり口座が10000円のときに引き落とそうとしたとき、同時に貴方が入金しようとする。俺と貴方のプロセスは、口座には10000円入っていると思い込んでいる。そこから俺が3000円引き出すので10000円引く3000円で7000円と書き込もうとするのだが、貴方のコンピューターは10000円に3000円入金し、13000円になると思い込む。従って、13000円と上書きされてしまう。

 これではまずい。

 これを回避するため、Aプロセスがデータを書きこむことをロックしたりするのだが、たまにAプロセスの最中にBプロセスが走り、Aプロセスの終わる前提とBのプロセスが終わる瞬間が循環してしまう(つまり、Aプロセスが終わるためにはBプロセスを、Bプロセスが終わるためにはAプロセスを)ということが起きることがあった。

 そして、なるほど、HttpRequestというのは、その本質として並列プログラムであるのか、ということに驚いてしまった(要するに、同時にアクセスしている人間が、同時にデータをRead/Writeするということはどういうことなのか、という話だったのかということに気がついた)。ただ、その部分は自分たちは意識しないようなインフラが整っている、そういう話なんだなと思う。

 恥ずかしいことに、このプロセスに関して、簡単な掲示板のスクリプトくらい書いている自分は気がつかなかった。そういう問題はあるとは知りつつも、曖昧な形で考えてしまっていた。

実務と理論の問題

 この辺りの問題は難しい。

 デットロック自体の話は、確かに俺が言っていたJavaのスクールで教えられてはいたが、それはデータベースへアクセスするという、いわば実務的な問題でしかなかったように感じる。そのJavaスクールでは、その2ヶ月の研修を経て、実際の現場へと投入されるわけだ。そして、今になって急に、このコンピューターの裏側について知らなかったことを恥じた。

 なぜこの問題が難しいのか、といえば、実務的なプログラムにとって、まず必要なことは、恐らく「つつましくコードが書かれること」であって、このように「理論を把握する」ということではないし、いやむしろ「理論」をしっていても、実際の実務に活かせなければ、意味がないだろうし、そもそもお金にならない、という現実はシビアにある(もちろん、実務をしながら、理論も勉強するという二つのプロセスが必要なのだが)。

 恐らく、多くの場合は、そういう話であるよりも、どれだけ作品を作っているかという部分でしか、つまり業務としてどれだけこなしたか、という部分でしかその基準を作れない点にあるのだろうと思う。その人が何を意識して、何を作るのか。その部分に関してはなかなか判断が出来ないのだろうし、しようがないのだろう。

最後に

 色々この話について思うことはあるだろう。現場に派遣されてきた人材が、一年の業務があるという「偽装」が行なわれて、コードを書かせてみると、逆に酷いバグを生み出すという話は、たまに噂として聞く。俺自身は、派遣はされていないものの、実際に業務になって酷いコードを書いてしまって、自分の無能さに頭を抱えることはある。

 上がどういう風にこの「業界」に影響を与えているのか、俺はよくわからない。ただ、そのように、25歳の頃にプログラマーに「なりそこねた」俺が、今はプログラマーをやっていて、そして俺に足りないことに関して、『計算機プログラムの構造と解釈』は教えてくれている。それは楽しいことであり、それでいいのだと、今は思う。

計算機プログラムの構造と解釈

計算機プログラムの構造と解釈

  • 作者: ジェラルド・ジェイサスマン,ジュリーサスマン,ハロルドエイブルソン,Gerald Jay Sussman,Julie Sussman,Harold Abelson,和田英一
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/02
  • メディア: 単行本
  • 購入: 35人 クリック: 1,149回
  • この商品を含むブログ (489件) を見る