著作一覧 |
Enterprise Integration with Ruby。
著者のMaikからrjbについて質問(これ自体は秋頃)されたので知った。出版は4月(実際には3月らしい)の予定。ほぼ脱稿したそうで、今は仕上げに入ったのでacknowledgments とかを書いてるそうです。
既存のエンタープライズシステムとの統合とか、Rubyをアプリケーション統合のグルーとして利用するとか、企業価値を高めたりアプリケーション寿命を延ばしたりとかといった(ある意味では)挑戦的な内容のようです。
#って言うか僕が昼間にやってることとある程度は被る内容のようだ。
車が買える価格と評判でクリック数だけは多いけれども、誰も注文をしないアマゾンリンク集。最新情報として、Visual Studio 2005 Express Editionをダウンロードしてユーザー登録をすると、アップグレード価格で買えるらしいと言われている(GOT DOT NET Japan掲示板)
Visual Studio 2005 Standard Edition アップグレード(-)
を追加。
読者数より広告主の問題なんじゃないかなぁ。でもマガジンハウスの雑誌とは違うから違うのかな……。
っていうか、Cの雑誌に広告うつ意味があるとこなんてちょっと思いつかないのだが。(Perlの雑誌にはてなやらYahooやらが将来に備えて広告を出し続ける−−というようなシナリオを考えてみたり。ではGoogleが広告を出し続けるとしたら、それはどのような雑誌となるか?)
どうも、COBOLでどうしようもないものを作っているうちに誰かがこのやり方はだめですな、と気づいたらしい。そして最終的にRDBMSとSQLが生まれた、というようなことを読んだ。(COBOLとデータベース)
ありそうな話だ。細かい経緯なんかを抜きにすれば、そりゃそうだろうとは思う。
でもCOBOLは死ななかった。なぜなら手続きが必要だからだ。SQLだけで解決できるわけではない。
というわけでまだまだプログラムする領域は残っていた。とは言えCOBOLそのものじゃなくて、COBOLの代替としてJavaが行き渡ったわけだが。
考えられる事務処理全般を包括するプログラムを作り、それを利用して事務処理を行なうことが当然考えられる。つまり、プログラムを作る手順を、プログラマという人間が覚えるのではなく、コンピュータに覚えさしてしまえば、もう自動的にプログラムができる訳だ。
の2番目(いや、プログラミング言語の登場を1番目としても良い気もするけど、エンタープライズシステムへの適用について数えればCOBOLの存在は前提として良いだろうから、やはり2番目−−確かに飽きたけど、一応、エンタープライズ2.0と言っておくか)のやつが来るよね?
というか、来なければならないだろう。
で、それにうまく乗れれば
注:blockquoteしているけど引用じゃなく、変形だ。
XXXを売りまくっている会社の社長が、XXXを利用して事務処理プログラム開発の受注をとるときの苦労を語ったのを聞いたことがある。
「Javaで開発している会社よりも何分の1かの期間でプログラムはできる。簡単なのであれば、お客との打ち合わせをしながらだって作れる。難しいのは、ある程度の時間を寝かせてから、お客に渡さなければならない。これが大変だ」
大変お客を馬鹿にした話だ。
が、できるってわけだ。
というわけで、XXXは何かをさっさと見つけてXXXを売りまくるなり(でも、これはRDBMSと同じく大手の寡占になるんじゃなかろうか。だって彼らは間違いなくそれを認識していてXXXを製品化しつつある/しているはずだから)、XXXを利用するなりにならなければならないだろう。
じゃないと
とにかく、JavaとXXXは対等に競争することはできなくなった。コンピュータが進歩し、プログラムの自動化が進んだためにJavaが衰退してきたのだ。これは必然の流れで、もはや逆戻りすることはないだろう。
これにより、大量のJavaプログラマが不要になってしまった。ときどき、就職情報誌などで、JavaプログラマのRuby(じゃなくてもいいけど)プログラマへの転職の話が載っているが、こういう事情があったのである。
となるということだ。
sumimさんといい、babieさんといい、いいものを知っているなぁ。と感心した(んだが、「感心する」っていうのはなんか不遜な物言いに見えるけど、じゃあどう言えば良いかと言うとぱっとは思いつかないのでこのまま。っていうか、おれは無知だなぁと思ったと言ってもいいわけだけど)。
WHATWGとか試しにやってみた。
ジェズイットを見習え |