でぃべろっぱーず・さいど

↓このエントリ読んでWicket 使いたくなっちゃいましたよ。

ウェブ・アプリケーションの革命がここにある - Apache Wicketユーザーグループを始めます - 矢野勉のはてな日記

そういやJavaのフレームワークって、がっつり使ったことあるのstrutsくらいだもんなぁ。

Tapestryは、2年くらい前にSNS作って（友達登録くらいまでしかできなかったけど）それっきりだし、Seaser2 もやりたいやりたいと思ってちゃんと触ってないし。

その発想の根底にあるのは、デザインとプログラムのほぼ完全な分離と、「JavaプログラマはJavaで書くのが一番楽なんだ」という考え方です。WicketはHTMLはHTMLのまま、HTMLエディタで編集できる形式のままテンプレートとして使用します。Wicketは各種設定をすべてJavaソース内で行います。Wicketはウェブ・ページをステートフルにし、デスクトップアプリケーションを作るときのように、普通にインスタンス変数を使えるようにします*1。Ajaxによる画面のコンポーネント更新を、JavaScriptではなくJavaソースから行うことが出来ます。

そうだよねー。やっぱ言語は1つの方が作りやすいよねー。

そういう意味では、サーバサイドJavaScriptにも興味があります。

Wicketおもしろそうなんだけど、Javaアプリは、作ったアプリを簡単に公開できない（スクリプト言語に比べて）という点でちょっと二の足を踏んじゃうんだよなぁ。

安くでJavaのアプリをホスティングしてくれるサーバはないものか。

自前サーバ立てちゃうか？　それはそれで結構な決心が必要なんだよね。

S2JDBCについて言及されているひがさんのブログエントリ。

2007-10-26 - ひがやすを blog

仕事でJava を使いつつも Seaser2 まわりについては割とノーマークだったんだけど（便利で良いモノだと言うことは知っている）、このS2JDBC ってちょっとおもしろそう。

何でもJavaで書こうとすればきっとはまると思いますよ。でも、S2JDBCはそうじゃない。

・from()
・join()
・where()
・orderBy()
・limit()
・offset()

でかける範囲に限定して自動でSQLを生成し、それ以外は、明示的にSQLを書けというスタイルです。

そうなんだよなー。

結局のところ、DBへのアクセスって、生成されるSQLをそこまで意識する必要のない簡単なアクセスか、いくつものテーブルが結合した複雑なSQL の2種類がメインで、中間の適度に複雑なSQLってのはあまりない気がします（僕がそういうのを書かないだけかもしれないけど。いや、そうだな）。

外部にSQLを出せるってことで、O/Rマッパーとしては個人的にiBATISを推してきたけど、S2JDBCに手を出しちゃおうかな。

Rails熱もそろそろ落ち着いてきた頃だし、とりあえず知っているJavaの地盤を固めておこうかなと思ったり。

ほんと今更感のある話ですが、今日改めて「そうかー」と納得したので。

struts のタグを使ってimgタグを書き出すときは以下のように指定します。

<html:img src="hoge.jpg" />

でもって、この画像タグにclass属性を付けてstyleを指定したいときは、class ではなく、styleClass属性に指定します。

<html:img src="hoge.jpg" styleClass="moge"/>

なんでclassじゃだめかというと、classがJavaの予約語だから。

上記タグの指定だと、strutsのImgTagクラスで、getStyleClass が実行されるわけです。当然styleClassプロパティもあります。

これがclassだと、getClass とか、class というプロパティとかが存在することになって、それってNGですよね。

ほんと何を今更的な話ですが、strutsのタグ周りのソースを眺めていてなるほどなぁと感心。

stringbufferとかでベタにimgタグを作って書き出す部分とかあったりして、生々しいなぁと。

フレームワークって便利なんで、ただ使うだけってことになりがちですが、、ちゃんとソースを見るってのも重要ですね。

---

トラックバックスパムの量があまりに酷いのでトラックバックを一旦閉じました。

以前にこのブログでも紹介したことのあるiBATIS が CodeZine で特集されていました。

CodeZine：iBATISを使ったO/RマッピングによるDBアクセスの実例（O/Rマッピング, フレームワーク, java）

まとめに書かれている4点の中で、以下の3点は重要だと思います。

・SQL文をJavaソースコードから分離することができます
・SQLの埋め込みパラメータを、JDBCよりも分かりやすく指定できます
・検索結果をオブジェクトに格納する機能が付いています

SQLがソースから分離されていることで、開発中のSQLの修正がやりやすくなりますし、埋め込みパラメータもパラメータの順番を意識することなく指定することができます。

O/Rマッピングフレームワークとしては、Hibernate や S2Dao が注目されていて、iBATIS は今ひとつの知名度なので、もう少し利用者が増えればなぁと思います。

プログラミングの中でStringをあれやこれやこねくり回すシーンは良くあります。

文字を分割したり、トリムしたり、固定長にしたり。

そんなとき、自前でUtilクラスを作る前に、Jakarta Commons Langを利用してみましょう。

便利なメソッドが揃っていて、プログラミング効率は格段にアップするはずです（知っている人は知っている話なので、そんな人は読み飛ばしてください）。

ダウンロードはこちら↓から。

The Jakarta Site - Commons Lang Downloads

数あるクラス／メソッドの中から、今回はベーシックなStringUtilsクラスの split()、substringBefore()、substringAfter()、substring()を紹介します。

ということで、

String test = "hoge=1&moge=2";

のようなパラメータっぽい文字列を処理するときを想定してみます。

こういうときは、"="の前と後ろをそれぞれkeyとvalueに対応させてMapに格納していくのが定石なので、そのように処理してみます。

String test = "hoge=1&moge=2";
Map result = new HashMap();
String[] l = StringUtils.split(test, "&");
for (int i = 0; i < l.length; i++) {
result.put(StringUtils.substringBefore(l[i], "="), StringUtils.substringAfter(l[i], "="));
}

3行目のsplit()で、文字列を"&"で分割し、Stringの配列を取得します。

その後、配列の長さ分だけfor文を回して、配列に格納された"key=value"の文字列を処理してきます。

今度はその"key=value"を"="の前と後ろで分けて値を取得するのですが、ここでsubstringBefore()とsubstringAfter()を利用します。

これで、hogeの値を取得したいときは、

result.get("hoge");

で取得できます。簡単ですよね。

これをStringクラスのsubstring()を使って実装しようとすると、結構面倒です。文字列長を誤ると、StringIndexOutOfBoundsExceptionなんかも発生しやすかったりするので、バグも発生しやすいです。

ちなみに、StringUtilsクラスのsubstring()メソッドは、この文字列長の扱いが割とゆるやかで、

String test = "abcdefg";

このような文字列の4文字目から20文字目を取得しようとしたとき、

test.substring(4,20);

だと、StringIndexOutOfBoundsExceptionが発生しますが、

StringUtils.substring(test,4,20);

だと、"defg"が取得できます。

初心者Javaプログラマが一歩ステップアップするために、このようなAPIを積極的に利用するようにしましょう。

Jakarta Commons クックブック―Javaプロジェクト必須のレシピ集

posted with amazlet on 07.02.07

ティモシー・M. オブライエン Timothy M. O’Brien 長瀬 嘉秀 テクノロジックアート
オライリージャパン
売り上げランキング: 39496

Amazon.co.jp で詳細を見る

JavaWorldが廃刊になり、Javaの専門誌がなくなりました。

最近立て続けに起きたJava専門誌の廃刊。時代の流れだとは思いつつも、その理由を考えてみました。

１．業務において"最新の"Javaの技術を利用することはなくなった。

先日、Java6が発表され、「Scripting for Javaの使いどころがわからないが、なんだかおもしろそうだ」なんて熱い技術者の間では話題になっていますが、実際のシステム構築業務において、"最新"のJavaの技術はもはや必要なくなっています。

「Javaのバージョンは1.4系だし、Webアプリ構築ならstrutsでしょ」という妙な暗黙の了解があります。

システム構築の現場には、「いくらがんばって新しい知識を身につけても、実践で使う場がない」という閉塞感が漂っています。

当然、安くない専門誌をわざわざ買って勉強しようと言う若いエンジニアは少なくなっていきます。

そんな状況なので、1.4系のことしか知らない技術者・プログラマ達に、急に「5系を使って構築してみて」と言ったところで、「GENERICS？　メタデータ？　Annotation？　何それ？」の世界になっちゃうのは仕方ない話です。

２．Java1.4系の技術のお話ならネット上にいくつも情報がある。

で、求められる知識がJava1.4系のもの（しかも基礎レベル）であれば、ネット上に情報は腐るほどあるわけです（実際腐っているものもありますが）。

３．開発環境の向上（Eclipseなど）により、詳しい知識がなくても簡単に動くものが作れるようになった。

さらに、ソース補完や構文チェック、自動ビルドを行ってくれる統合開発環境のおかげで、詳しい知識がなくてもプログラミングできて、動くものが作れてしまう時代になってしまいました。結果、わざわざ雑誌を買ってまで調べなくても良くなってしまいます。

上記の内容を要約すると、技術力がない技術者でも簡単に「動くもの」が作れるようになってしまった、ということです。

いわゆる「専門誌」は、かなーりできる上級の技術者と、初心者～中級者の技術者をつなぐメディアだったわけです。その「つなぎ」がなくなることで、上級者とそれ以下の技術者の技術力格差はどんどん広がる一方です。

Javaもいつかは廃れていくのだとは思いますが、まだもうしばらくは一線でがんばっていける言語なわけで。優秀な技術者を育てるという意味でも、最新のJavaのバージョンで、最新の機能を使ったアプリをどんどん作っていけるような環境を作っていかないとなぁと思いました。