System.Exit

Ruby と Java についてあとで書く。

追記:

結論

どっちもやってみたらいいと思うよ！

いやほんと、これにつきる。
とりあえずそれぞれの言語にどっぷりつかってみるべき。

優劣

どちらの言語が優れているとか、そういうレイヤーの話って不毛なんですよ。
Ruby という言語のことを知らずして Ruby のことをとやかく言うことはできないよね。
逆に Ruby やってる人間はだいたい Java のことはよくわかってる。
むしろ、Java やってる人以上によくわかってるかもしれない。
（想像だけど）

適材適所

ていうか、適所適材ですよ。
Java を使うべき所で Java を使い、Ruby を使うべき所で Ruby を使う。
PHP を使うべき所では PHP を使う。
えーっと、だから逆に言うと、いくら Ruby がいいからといって、Ruby を使うべきではない所では Ruby を使うべきではないということ。
エンジニアたるもの、そのくらいの見極めができないとダメだと思う。

Ruby vs Java

実際の所、Ruby を仕事でバリバリ使ってる人ってまだ結構少ないと思う。
Ruby が好きとは言っても、ほとんどの人が仕事では Ruby 以外の言語（Java, PHP, Perl とか？）をメインに使っているんじゃないかな。
だから例えば、Ruby を知らない Java 屋さんが、Ruby プログラマと何らかの形で張り合おうとした場合、Java 屋さんは圧倒的に不利。
Rubyist は相手のことをちゃーんと把握してるから。
それに比べて Java 屋さんは Ruby のことを何にもわかっちゃいない。
この状況でどちらが勝つか。
考えるまでもないですね？

冗談はさておき。
どのプログラミング言語を使えるのか、という程度のことで他人との間に軋轢が生まれてしまうような状況ってのが実にくだらないと思うのです。
自分の考えが正しくあるためには、相手の考えが間違っていなくてはならない、みたいなね。

…

ああ、
もうちょっとまともな文章かけるようにならないと。

スクリプトを手軽に実行するためのツールを作ってみました。
ファイルに保存するまでもないような、ちょっとしたスクリプトを書くときなんかに便利です。

ダウンロード

ScriptConsole.jar

仕組み

内部的には、一時ファイルにスクリプトの内容を保存してスクリプト実行用のコマンドを直接叩いてるだけです。
Ruby とか PHP とか、その他にも、システムにインストールされていればだいたい動くと思います（なんせコマンド叩いてるだけなんで）。

動作イメージ:

スクリーンショット

実行の仕方

実行方法は以下のようにコマンドプロンプト等から実行するか、

java -jar ScriptConsole.jar

もしくは jar ファイルをダブルクリックして直接実行できるような環境になっていればダブルクリックして実行してください。

あ、java 1.5 じゃないとたぶん動かないと思います。

ソースコード

http://svn.jugyoo.org/public/ScriptConsole

これ読みました。

JavaからRubyへ ―マネージャのための実践移行ガイド Bruce A. Tate 角谷 信太郎 オライリー・ジャパン 2007-04-21 売り上げランキング : 6640 Amazonで詳しく見る by G-Tools

誤字が多いのが気になりますが、大変面白かったです。

いやー、ほんと、システム開発っていろいろあって面白い。
一体何が真実なんだか。
ま、なんにせよ、選択肢は複数あった方が良い。
テクノロジーでは解決できない問題もたくさんあるだろうけど。

Martin Fowler氏へのインタビューより引用。

Q : Javaはどこで道を誤ったのでしょうか？
Java界は、スキルの未熟な開発者にもシステムを台無しにされないようにすることに力点を置きすぎています。結果から言えば、この考えは破綻しています。銃で自分の足を打ち抜かないようにするという考え方は魅力的ですが、現実に私たちが目にしているものは理想からは程遠いものです。あまりにも複雑でひどいJavaアプリがそこら中に転がっています。

全体的に、Javaは複雑すぎるのです。「銀の弾丸はない」 [略] というのは、本質的複雑性と偶発的複雑性とを区別するということです。たとえば、給与支払システムの開発では、給与支払の業務ルールは本誌的な複雑性です。しかし、Javaの労力のほとんどを占めているのは偶発的複雑性です。EJBの大失敗はこの最たる例です。EJBは、それ自体がとんでもなく複雑なフレームワークであるばかりでなく、私たちが経験してきたアプリケーションのほとんどにとって複雑すぎます。SpringとHibernateはEJBに比べれば格段に進歩していますが、それでもまだ、偶発的複雑性に満ち満ちている印象を拭えません。
– p.28

「本質的複雑性」と「偶発的複雑性」っていうのは良い表現だなぁ。

プログラマって、複雑なものに惹かれる本能を持ってる気がする。
「こんな複雑なことをやってのけちゃう俺すげー！」みたいな。
それがバッドノウハウにつながったりもする。
あとは、焦り。
「この新技術をマスターしないと時代に乗り遅れる！」みたいな。
そういうのが問題を生んだりする。

以下、その他諸々コピペ。

EJBはだんだん良くはなっていますが、それでもまだ難しすぎます。 [略] EJBは象を撃つ大砲のなかでも最高級品なのです。しかし、筆者の知るEJB開発者のほとんどは、EJBをWebインターフェイスを備えたリレーショナルデータベースアプリケーションの開発に使っています。どんなに贔屓目に見ても、EJBに適しているのは、分散トランザクションのような高度な機能が要求されるニッチな分野です。
– p.30

[略] Javaで言語を拡張するために（Dependency Injection やアスペクト思考プログラミングといったバズワードや、XMLベースの設定を利用するような）厄介で複雑な方式が必要不可欠なのは、動的言語のような方式ではJavaの拡張が難しいからです。
– p.52

要は、DIって「苦肉の策」的なものなんじゃないかなぁ。

Javaの良くないところは、もっと素朴なテクノロジを使うべきユーザに対しても、エンタープライズフレームワークを使うように働きかけていることです。
– p.60

Javaは言語の選択肢としては安全かもしれません。しかし、正しいフレームワークの選定は、たとえ専門家であっても難しいのです。
– p.68

確かに、Javaにおいてはフレームワークの選択は非常に難しい。

ていうか、RubyがJavaに取って代わるかはどうでもよく、現時点でのJavaの問題点をきちんと把握しておくことが重要だな、と思った次第。

それでも僕は設定を書くね (arclamp.jp アークランプ)

たぶん、これからのエンタープライズ開発では「ロジックコンポーネントを書く人」と「それを使う人」が今まで以上に明確に分離してくるはずです。そのためには「それを使う人」が、いわゆる設定ファイルの記述やSOAのビジュアルツールみたいに痒いところに手が届かない方法ではなくて、スクリプトや宣言的記述のように”良い感じ”に書けるようになるようになる必要があります。

やっぱ XML でプログラミングってのはキツいと思う。

SOA の失敗はエンドユーザーには難しく開発者として大雑把過ぎる中途半端なツールにあったわけです。これはビジョンや問題設定が理想論過ぎてしまったことが原因です。そこからのゆり戻しとしてRonRを捕らえると、設定の重要性が増すなかで「いかにいい感じに設定するのか」という挑戦として僕には見えています。

SOAについてはよくわからない。
よくわからないものがよくわからないままに失敗していたのね。

アークランプ氏が「設定、設定」っていうのがどうも引っかかる。
結局はプログラミングでしょ、どれも。

…

この辺の話って、どれも抽象的すぎる気がして好きになれないな。
あーだこーだ考えてるよりもプログラミングしたほうが有意義な気がする。
そういえば最近仕事以外でプログラミングしてないなぁ。

ふと思ったけど、良いものを作ったからといってそれが普及するかどうかはまた別の話だと思う。
万人受けする魅力がないとだめなんじゃないかなぁ。Railsみたいな。

…

そういえば最近、 Spring がなかなかすごいと思い始めている。
なんと言っても便利。
RMI とか JMS とか使うのがすごく楽。
ていうか、これらに関しては Spring 使わない普通のやり方が面倒くさすぎるだけなんだけど。

Java ってライブラリはたくさんあって良いけど、言語としては柔軟性がないというか融通がきかない部分があるので Spring 等の DI コンテナでそこを補わないともうだめなんだろうなぁ、というのが今のところの僕の認識。
それにしても、XML であんなプログラミングチックな設定をがりがり書くなんて、どこか間違っている気がするんだよなぁ。

追記:
天使やカイザーと呼ばれて: DIコンテナの設定ファイル書くの？書かないの？
この記事がなかなかわかりやすくて参考になった。
うまく問題を切り分けていてすばらしい。

矢野勉のはてな日記 - そろそろRuby/PythonのようなLLを褒めるのにJavaを貶めるのは止めません？

僕ならこう書く。

public class Sample {
    public static void main(String[] args) {
        System.out.println(1+2+3+4+5);
    }
}

いちいちループさせる意味がわからない。

ちなみに、オリジナルのコードはこんなの。

import java.util.ArrayList;
import java.util.List;

public class Sample {
  public static void main(String[] args) {
    int total = 0;
    List list = new ArrayList();
    list.add(new Integer(1));
    list.add(new Integer(2));
    list.add(new Integer(3));
    list.add(new Integer(4));
    list.add(new Integer(5));
    for (int i = 0; i < list.size(); i++) {
      total += ((Integer)list.get(i)).intValue();
    }
    System.out.println(total);
  }
}

狂ってるねw。

補足:
ま、単にサンプルコードだから深く考えずに作ったんでしょうけど、Java にとって不利なところばかりを集めてきてそれで比較するのもフェアじゃない気がするんですね。
JavaがどうとかLLがどうとかじゃなくて、要は住み分けですよ。
お互い得意な分野で頑張ればいい。

Wicket について超簡単に説明してみる。
ていうか初歩の初歩すぎて、あまり有益な情報にはならないと思われる。
正しくない部分もあるかも。

WebApplication クラスがアプリケーションのエントリポイント。
実際には WebApplication クラスは抽象クラスで、これを継承したクラスを自分で定義する必要がある。

WebApplication クラスには getHomePage() というメソッドがある。
getHomePage() メソッドの返り値の型は「Class」。
フレームワークはこのメソッドを呼び出してトップページを生成する。
例えば、Page1 というページをトップページにしたい場合は Page1.class を返すようにしておく。

Wicket ではクラス(java)とページ(html)は一対一に結びついている。
ページとして機能するクラスは、WebPage というクラスを継承して作る。

WebPage から 他の WebPage に遷移することができる。

セッション情報を保持するオブジェクトは WebApplication クラスによって生成される。
正確には、WebApplication の実装クラスにて getSessionFactory() メソッドをオーバーライドし、適切なセッションオブジェクトを生成して返すファクトリーを返すようにしておく。
そうすることでフレームワークがセッションオブジェクトを管理できるようになる。
（たぶん）

各ページからセッションオブジェクトにアクセスすることができる。
（たぶん）

Webアプリケーションフレームワークの調査をしてる。
今後仕事に使うことがあるかもしれないので。

なにはともあれ「Hello World!」ですよ。
ってことで、以下のページを参考にしてやってみた。
【レポート】Wicket入門 - JavaとHTMLだけで作るWebアプリケーション (1) Wicketとは? (MYCOMジャーナル)

必要なファイルは以下の三つ。

• Main.html
• MainApplication.java
• Main.java

MainApplication.java

package helloworld;

import wicket.protocol.http.WebApplication;

public class MainApplication extends WebApplication {

	@Override
	public Class getHomePage() {
		return Main.class;
	}
}

Main.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-JP">
<title>HelloWorld</title>
</head>
<body>

<span wicket:id="message">ここにメッセージが表示される。</span>

</body>
</html>

Main.java

package helloworld;

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;

public class Main extends WebPage {

	public Main() {
		super.add(new Label("message", "Hello World!"));
	}
}

必要なライブラリや「web.xml」の説明は端折ってます。
実際に試す場合には、上で紹介した「MYCOMジャーナル」の記事が参考になると思います。