Beginning Java EE 6 GlassFish 3で始めるエンタープライズJava

ここんとこJBoss使ってるんだけどJava EEのこと良く知らんのよね、ということで本書を買ってきた。読み進め方としては、気になるトピックに関しては実際に環境作ってHello Worldレベルのこと試す、それ以外は読むだけに留める、というやり方にした。あと、使うコンテナは本書で取り上げてるGlassfishではなくJBoss AS 7を使用した。これは俺の趣味の問題。

実際に試してみた時にやったことは下記エントリを参照。Hello Worldレベルのことしかやってないけど。試したのは、EJB, Arquillian*1, JAX-WS, JAX-RS ぐらいかな。

• JAX-RSさわる - kagamihogeのblog
• WildFly 8でWeb Serviceさわる - kagamihogeのblog
• JBoss AS 7.1 + EJB 3.1 + Arquillian動かすところまで - kagamihogeのblog

EJB 3になってホントそれ以前のEJBとはベツモンになったなぁと。CDIとのあわせ技で、他のJave EEのコンポーネントとのハブになる感じ。トランザクションをコンテナ任せにできるのも面倒が無くてよい。ただ、O/Rマッパーっていうか他のミドルウェアとの通信はRDBMSしかないんでJPAだけDIしてくれればいいんや、っていう場合だとワザワザEJB使うメリットあまり無さそうだけども。トランザクション手動orコンテナ管理っていう利点があるか。

JPAについて。Hibernate使ってるんで適当に読み飛ばしたけど。個人的にはS2JDBC的なアプローチが好きなんだけど、好みの問題に過ぎないかなぁ？　という印象。SQLに加えJPQLとか独自の言語を更に持ち込んじゃうのは、うーん……SQLよりシンプルな記述が出来るのがウリとはいえ、ってまぁその辺の文化圏になかなか慣れることが出来ないゆえのグチみたいなもんですはい。

JAX-RS(RESTeasy)はともかくJAX-WSは超簡単になってたのは驚いた。JAX-WSは、むかしの死ぬほどXML書かなきゃならん頃の印象しかなかったんで。なんでこんな面倒くさい思いしてまでAPIを作るメリットがわからなかったけど、今なら選択肢として上がってきそう。ただ、RESTの方がもっと簡単なのだけど……

JSFは……ビミョウすぎるというか……俺は独自のタグ使うの好きじゃないというかHTMLテンプレートの方が好きだし、webデザイナさんに対しても頭が沸騰せずに済むので。ただ、画面もプログラマがやる体制なら別にいいとは思う。ただライフサイクルとか、ややこしい仕組みの必要性がどうにもメリットが感じられない。SwingとかJavaFXとかマルチ対応できるのがウリってあるので、そういう場合には使えるのかなぁ？　という感じ。申し訳ないがプレゼンテーション層だけは別のフレームワークを使わせて頂きたい、って感じ。

全般的に着実な進化してるんだなーという感想。確かに、新技術を即効で取り入れて早いスピードで発展していく、というわけではない。ただし、必要なものを足場を固めて着実に取り入れていく、というJavaらしさが良く出ている。古くて使われなくなった仕様は削除対象にして、Java EEコンテナのメンテナンス負荷を下げる活動についても本書は触れている。地味だけども長期的に見ればやった方が良い活動をやってるあたり、こなれてる感じが一層強まる。

まーぶっちゃけ目新しさとか面白みとかはマッタク無いけれど。しかし、Java EEの手堅い進化をサラッと見るにはとても良い本でした。

Beginning Java EE 6 GlassFish 3で始めるエンタープライズJava (Programmer’s SELECTION)

*1:これはJava EE 6とは一応無関係だけどもまぁ多少はね？

Webエンジニアのための データベース技術実践入門

俺が最近RDBMS関連の勉強をしているのは、Oracleの運用で痛い目にあったからである。危機感というか、いくらなんでもDB知らなさすぎやばい、という感情に背中を押されてのことである。ところで、本書の対象読者として、既に現場で技術者として働いておりデータベースを勉強したいが、何から勉強したものか分からない方、を上げている。俺ももれなくその例の一人となっている。つまり、データベースの重要性に気付かされるのは、本格的にデータベースを実際の業務で触れるようになってから、というケースは割とポピュラーなようである。

そんなわけで、本書はまず、なぜデータベースとりわけRDBMSを使わなければならないのか？　から始まる。なぜ、データをただ保存するためだけにこんな大仰な仕組みが必要なのか、CSVファイルとかエクセルではダメなのか？　とかに答える形で導入部は始まる。俺もかつては抱いていた疑問だけに、苦々しい表情になりながら読み進めることになった。しかし、著者の生々しい実体験に支えられているだけに、本書の持つ説得力は高いものがある。

その後の章では、そうした疑問やデータベースに求められる要件とその回答としてのRDBMSとRDBMSの各機能の解説、という形で進んでいく。本書の目的は、データベースの持つおおまかな役割や思想をつかむことにある。なので、この本を読んで即座にMySQLのスキルが上がるとか、そういうことはない。RDBMSの個々の分野、インデックスやモデリング、トランザクションや排他制御、バックアップやリカバリ……などなどは一つ一つだけで充分複雑なものになっている。それらは別途、学習する必要がある。そのため、この本の使用法は、本書を起点に自分に足りない分野に挑んだり、全般的な知識に不足がないかを確認するために使うのが良いと思われる。複雑巨大なデータベースの山脈を、まずこの本で俯瞰する。それから個々のトピックに取り組んで、山を一つ一つ登っていく。本書は、そういうアプローチを推奨している。

本書の独特な部分としておもしろかったのは、MySQLのソースコードを読んで障害解析したり新しい機能を追加したりしてみる章が上げられる。本書は特定のRDBMSに依存しないように書かれているが、具体的な話が必要な場面ではMySQLを使用している。その真骨頂がその章である。といっても、ソースコードの静的解析はlinuxのgrepやらを使用した一般的なファイル操作で、動的解析はgbdを使用したもので、使う技術そのものはごく一般的なもの。俺が驚いたのは、RDBMSという複雑巨大なミドルウェアも、linux上で動くC言語のアプリケーションに過ぎず、オープンソースなので自由に見れるし、手も入れられる、というところ。もちろん、トランザクションとか高度に複雑なものはそうおいそれと読めないんだろうけど、内部動作をソースで追えてしまうのは新鮮な感じであった。

最後になったが、サンプルデータにP3,P4の人物名使っちゃうあたりに深い親近感を覚える一冊であった。

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

JUnit実践入門 体系的に学ぶユニットテストの技法

イマサラJUit 4よく知らないんですよね、とは言い出しにくい情勢なので本書を手に取った。さすがに実践入門と銘打たれてるだけあり、明日すぐ使えるような構成になっている。実践的だと感じたのは大きく二つの理由からなる。一つは、JUnit 4の各機能をサンプルコードと共にこういう状況でこれを使えと指針があること。一つは、テストケースをどのように作っていけばよいのかについて指針があること。もちろん、どちらも本格的な理論の域にまでは達していないが、まず使い始めるには充分な記述量だと思われる。

本書読むまで存在知らなかったJUnitの機能を見ていると、フツーにJUnit使ってしばらく経つと困る点が順次解消されてるんだな、という印象を受ける。Encloseでテストケースまとめるのとか、Categoriesでテストケースの分類と実行とか、そのへん。本書の良いとこは、ただasssertの使い方紹介して終わり、でなく、大量にテストケース作っていけばぶつかる点とそれに対処するにはJUnitのこの機能使いましょう、という書き方になっている点。細かいことはともかくまずはJUnitのこの機能こんな感じに使って頑張ろうぜ、という指針であり、単純ではあるが取り組み始め人間にとっては強力な考え方であろう。

機能の使い方だけではテストケースは書くことができず、テストケースをどのように組み立てればよいのか、という問題がある。本書のアプローチとしては、共通のデータに着目する、同値クラス分析で入力と出力の組み合わせからテストケースを作る、など。これもやはり簡易なものでしかないが、最初は意外と何をテストケースとすべきか分からないものなので、まずはこうやっとけ、っていう書き方には好感を覚える。俺自身、コピペすればいくらでもテストケース増やせることに悩んだ時期があるので、ユニットテストの基本かくあるべしという本書のアプローチは参考になった。

以上二点のように、大雑把な指針を示しているのが実践入門という名前に繋がっているのだな、と俺は感じた。もちろん、上級者はそれらの指針に従う必要は無い。より高度なことをしようとしたとき、基本から逸脱するのは自然なことと考えられる。また、テストそのものの学習ははじめて学ぶソフトウェアのテスト技法等で別途行う必要がある。が、まずはユニットテストを好きになってから、というのは現実的なアドバイスだろう。

個人的にちょっと驚きだったのがDbUnitなりなんなり、クラス以外のミドルウェアに依存するテストも単体テストで扱う世の中になってしまってるんだなぁ、というところ。俺が本格的にユニットテストを勉強するきっかけになったレガシーコード改善ガイド - kagamihogeのblogでは、ユニットテストはクラス単体で動かせるテストであること、という思想だったと記憶している。なぜなら、すばやいフィードバックが得られないから。

当然、本書もスローテスト問題なを切り口として、原則的にはユニットテストは外部依存しないことが望ましい、という書き方ではある。しかし、現実的にはDBなりミドルウェア前提の機能も多いので、それに合わせてユニットテストに対する認識も変わってきている、といったとこなんでしょうかね？

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)