Java EE6で単体テストや結合テストを自動化する方法について - 達人プログラマーを目指して
今週水曜日に、オラクル青山センターで行われたGlassfish Japanユーザーグループの勉強会でJava EE6のお話をさせていただきました。勉強会のスライドとビデオは以下のリンク先にあります。 Glassfish勉強会（JavaEE6について） View more presentations from Ryo Asai http://www.ustream.tv/recorded/16552906 今回は基本的に私がこのブログで書いてきたJava EE6関連の情報について紹介させていただきました。欲張って少し内容を詰め込み過ぎたところがあったかもしれませんが、Java EE6を使った単体試験や結合試験の自動化については、説明をスキップしてしまい、ちょっとわかりにくくなってしまいました。ここで、あらためてJava EE6上のアプリケーションのテスト自動化について簡単に補足させていただき
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指して
Twitterでフォローさせていただいている@chok12jaさんのつぶやき がきっかけで、外国人の視点から日本のSI業界の問題について分析した面白い英文の記事を見つけました。 How the Japanese IT Industry Destroys Talent | Japan -- Business People Technology | www.japaninc.com [ThinkIT] 第2回：なぜ日本のIT業界ではスーパーSEを育てられないのか (1/4)（New 日本語訳が見つかりました。） 2007年に書かれた記事なのでもう４年も前に書かれたものですが、日頃から私が感じてきた業界の問題点について鋭く批評を加えており、非常に共感する内容が書かれていました。本ブログの主な読者の方々にとっても興味深い内容だと思いますので、ここで簡単に内容について紹介させていただきたいと思います
Java5の型システムを理解するにはリフレクションAPIを使ってみるのが最短の近道になる - 達人プログラマーを目指して
Java5における総称型（generics）の導入に伴い、Javaの型システムは以前と比べて高機能になった反面、理解するためのハードルが高くなっています。もちろん、Javaの型についてきちんと理解するためには言語仕様を勉強すればよいのですが、手っ取り早く理解するための方法としてリフレクションAPIを使ってみるというのが有効です。リフレクションAPIの先祖はJava1.xのころから存在しており、フィールド、メソッド、クラスなどの情報を実行時に取得するためのものですが、総称型に合わせてJava5から新しいAPIが追加されています。ここではリフレクションAPIを使い、Java5の新しい型システムについてまとめてみたいと思います。 JDK1.4までの型はすべてClassクラスのインスタンスに一対一対応する JDK1.4までに存在していた型はパターンに分けると以下の3通りに分類できます。 基本型（i
ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家（ドメインエキスパート）ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJava、C++、C#、Visual Basicといっ
業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
OSS Javaフレームワークはどんどん高度化している - 達人プログラマーを目指して
以前、いつまでStruts1を使い続けるの？という記事を書きました。技術から離れているSEの方は、いまだにJavaのオープンソースフレームワークと聞くとStrutsくらいしか思い浮かばないという人も多いと聞きますが、その記事では、Strutsの問題点をあげて、そろそろ新しいフレームワークを使いましょうという話をしました。 しかし、単にSpring MVCに移行しましょうということではなくて、OSSを利用したエンタープライズJava開発の世界*1では、もっと根本的なレベルで進化が起こっているのではないかということを最近考えます。単純にOSSのJavaフレームワークといっても、時代によって考え方が大きく変わってきているという事実があるのです。この点についてちょっとまとめてみたいと思います。 第1世代（2000年〜2003年） いわゆるStrutsとかHibernateといったフレームワークで、
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
Ant + Ivy vs Maven - 達人プログラマーを目指して
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指してに関連して、開発プロジェクトで決定しなくてはならないことの一つに、Antを使うかMavenを使うかという判断があります。この両者に関してはそれぞれに信者の方がいて宗教論争のようなところもあるのですが、実際どちらの方が人気が高いのでしょうか？ Mavenの熱烈なファンの方もいる一方で、Maven地獄などという言葉もあるようにMavenでひどい目にあった人もいるようです。そういう人はAnt+Ivyの方が軽くてよいと言います。さらに、 議論：Mavenはビルドに適したツールか？ などを見るとなんとなくMavenはいまいちな印象を受けてしまいますし、Springも当初Maven化するという予定であったのに、 Spring switching to Maven? Oh no, think twice! などの発言もあり、結局Spring
いつまでStruts1を使い続けるの？ - 達人プログラマーを目指して
営業支援で提案中の案件があるのですが、現状CGI＋Perlで作られているコンシューマー向けサイトがあるが、 CGIなので性能が悪い コンテンツの修正が大変なのでMVCできちんと作りたい 実績のあるJavaとStrutsをメインに検討している とのことです。今時多くのコンシューマー系のサイトで、コンテンツの管理を容易にしたいならオープンソースも含めてPHPベースのCMSが星の数ほどあるという事実はおいておくとしても、とにかく、実績重視ということでStrutsということになってしまうのでしょうか？お客様もMVCなど相当技術を勉強されていることは感心なのですが、JavaのMVCフレームワークというとStrutsしか考えないというのは問題ではないのでしょうかね。多くのStrutsベースの既存システムを自社で抱えているなどの理由があるのであれば、それも一つの選択なのかもしれませんが、実績重視とか社内
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
