Seasar って日本で既に成功しているものだとばかり思っていました。

Seasarはなぜ日本から巣立たない? - 2007-10-12 - ひがやすを blog

だから、私は先に日本で成功するまでは、海外には進出しない。日本人に選ばれたものが、海外でもまた成功すれば、日本人も「舶来信仰」の呪縛が解けることでしょう。

たぶん、Seasar 自身はすでに日本で成功しているし、海外に出してもそれなりに成功する気がします。私は Spring も Seasar も深く触ったことはないですが、使っていて Seasar の方が気持ちがいいんですよね。

問題は周辺プロダクトのドキュメントなどを英語化する際に、ペースがまちまちになってしまいそうなことでしょうか。東工大の千葉先生は、最初から英語でドキュメント化しておけば日本人のだれかが勝手に日本語化してくれるから、自分で日本語も英語も準備するよりも楽的な話を未踏のミーティングでしていた気がします。それはそれで敷居が高いですけどね。。。
# そういえば、Kodougu の英語ドキュメントのバージョンが古いままだ。。。orz

そういう意味では、日本語で今のスピードを維持しながら・・・というのも一つの作戦なのかもしれません。

欲を言うと、日本人向けに海外から技術を輸入するビジネスをしている人たちが、逆に日本のものを英語に翻訳して輸出すればいいのですが。

長いこと積読になっていた「JavaからRubyへ」をようやく読み終わりました。（※ この本を買ったのは 4 月か 5 月。）この本は、日本で Java の案件をこなしているマネージャが読んでピンを来るものなのでしょうか。マネージャ級の人に聞いてみたいところです。

大筋要約してしまえば以下の通り。
・ Java で対処するとコストが大きくなるプロジェクトもある。なんでも Java じゃリスクが高いよ
・ Ruby（というか Rails）はその中のいくつかのプロジェクトに対処できる
・ Ruby の導入にあたって、パイロットプロジェクトの実施方法
・ Ruby の導入手順（教育、リクルーティングなど）
・ そのほか Ruby や Rails の紹介（ある意味、どうでもいい）

多分、そこそこの規模のある SI 企業であれば、将来有望そうな新技術のパイロットプロジェクトを走らせて、定量的、定性的なデータの収集を行っていることでしょう。この本の位置づけとしては、その対象に Ruby（というか Rails）を含めた方が良いという啓発本なのかも。

Amazon のレビューより（tDiary のたださんがかいてらっしゃる？）：

だいたいマネージャ層には、本書に登場するDave ThomasやMartin Fowlerの名前などなんの威光も持たない。

この本がこうしたヴィジョナリーを挙げているということは、海外では威光をもつということなのでしょうか。ちょっと気になります。誰かわかる人いないかな。

日本ではこうした改善はボトムアップに上がっていくところがあるので、この本は末端の開発者が手にとったらいいのかもしれませんね。

■ 追記（2007/6/28 5:41）
はてブにコメントがついていました。どうやら、訳者の方のようです。

はてブコメントより、「この本は、日本で Java の案件をこなしているマネージャが読んでピンを来るものなのでしょうか。」：

弊社経営陣にはリーチしました

これは素晴らしい話ですね。確かに、永和システムマネジメントさんは、Ruby に対して非常に熱心（会社として熱心）という印象があります。まったく同じというわけにはいかないのでしょうが、この本で書かれているような段階を踏んで、会社として「Ruby やりますよ」って宣言しているわけなのでしょうから、やはり凄い話です。

最近、C# と Ruby と JavaScript を使っているせいか、コーディング・スタイルが混ざります。つまり、JavaScript なのに Ruby の作法で書いてしまったり。これまでも、複数の言語を併用することは多かったと思うのですが、コーディング・スタイルが混ざるなんてあまりなかったのですが。(^^;
# しばらく仕事でコーディングしていなかったせいかな。

Ruby の場合（メソッド）：

update_attributes

Java/JavaScript の場合（メソッド）：

updateAttributes()

C# の場合（メソッド）：

UpdateAttributes()

どうも、Ruby の書き方が気持ち良いらしく、JavaScript でも Ruby のような書き方をしてしまうことが多くあります。不思議と、C# で他の言語の書き方になってしまうことはありませんでした。

そろそろしっかりとしたコードを書くように心がけなくては。

JavaScript で文字列の比較を行うにはどうしたら良いのか気になったので調べました。

JavaScript

s1 == s2

プログラミング言語を変えるとき、どうしても神経質になるのが文字列の比較です。メジャーな言語によって推奨される方法が異なるのです。

Java（参照の比較は == を使う）

s1.equals(s2)

C#

s1 == s2

（C# は Java スタイルでも良いが、こちらを参照せよ。）

Ruby（参照の比較は equal? を使う。）

s1 == s2

C/C++（参照というかアドレスの比較は == を使う。）

strcmp(s1, s2) == 0

Delphi（参照というかアドレスの比較は @s1 = @s2 ・・・だっけ？？？）

s1 = s2

・・・誰か統一してくれ！

ひがさんのブログにスクリプト言語とタイプセーフな言語の生産性という記事が載っていて、Ruby と Java の生産性に関する話題に触れていました。SOA をやってて強く思ったのですが、やはりこの世界 Java な人は多く、タイプセーフな言語の強みを語って Ruby などのスクリプト言語の盛り上がりに対抗しようとする人が多い気がします。
# 会社でもそういう人の話を何回も聞かされたし。

ひがさんの指摘されているとおり、いろいろ道具立てがそろってきた今、Ruby（Rails）と Java の間に生産性の有意な差があるとは思えません。というか、最近仕事で軽くではありますが、Eclipse + Ruby（Rails）と Eclipse + Java（Seasar）を使いましたが、生産性という観点でそれほどの差は感じませんでした。

どっちがアジャイルかと聞かれると、「うーん、似たり寄ったりかなぁ」と答える気がします。プログラミング 2.0でオライリーの意見を紹介したとおりです。この記事にしても、あくまでマーケティング的な意味合いで、書かれているのでしょうね。

もっとも、無理に対決話に持っていく必要はないですけど。

Java SE6 が出たみたいですね。個人的にはスクリプト言語との連携が気になっています。でも、当面さわっている余裕はないなぁ・・・。

以下、参考情報。

Java Platform, Standard Edition 6 Release
http://java.sun.com/javase/6/

秋元@サイボウズラボ・プログラマー・ブログ
http://labs.cybozu.co.jp/blog/akky/archives/2006/12/java_se_6.html

米Sun，Java SE 6を正式リリース
http://itpro.nikkeibp.co.jp/article/NEWS/20061212/256732/

最近の仕事を振り返っておきます。10/10 ～ 11/10 までちょっとしたプロジェクトの PL をやっていました。最年少なのに！
# はてなの偉くない管理職みたいな話で面白いですけど。

社内に閉じたプロジェクトではなかったので、社外の人に気を使ったり、途中でメンバーが異動になったり、最終日の成果発表では意外な人が飛び入りしてきたり、私の年齢詐称疑惑が出たりと。短いのに波乱万丈でした。(^^;
# だから若いんだってば！

よかった点は、進捗管理やプロジェクトの都合上会議が多かったので、ファシリテータチックな動きもそこそこできたのではないかなと感じています。よくなかった点は、メンバー内の作業負荷にばらつきが出てしまったことか。拠点が会社をまたがって2箇所になるとプロジェクト運営は難しいなぁ・・・。

以下、アーキテクチャです。

サーバ構成：Windoes2003 Server + Apache + Tomcat + axis2 + MySQL
サーバアプリ：s2axis + s2dao
クライアント：rails

Web サービス（SOAP）には、soap4r 経由でアクセスしました。

うん、今回は久々の Java で楽しかった！