プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

可燃プロジェクトに飛び込むことになりました。下記のような炎上する要素満載。 関係者各社に告知済みのためカットオーバーは伸ばせない 外部仕様を策定した会社は行方不明 外部仕様はあるが、OS も AP サーバも環境もアーキテクチャーも未定 外部仕様を分かる人がいないw 開発は 3 社合同なのにソース管理方式も決まってない DB アーキテクト不在っぽい フレームワークに詳しい人がいない AJAX っぽいのたくさん お金がない、規模はわりとでかい、納期短い、残業禁止、増員不可 最初このエントリを見たとき、4/1だったこともあり、一瞬ネタかなと思ったんですが、その後に、SAStrutsとS2JDBCに対する具体的な質問がいくつもあり、私のほうもできる限り質問に答えました。 その後、どうなったのか気がかりだったんですが、今見たらこんな書き込みが 開発メンバからは、簡単で楽でいい！ 1 機能が 1 時間

クロスコミュニティカンファレンスの「ITゼネコンをぶっつぶせ」BOFですが、時間が参加しにくいという意見があったので、18:40分開始に変更しました。また、時間も90分に延長し、後半の4,50分は、会場の皆さんとのディスカッションにあてたいと思います。 ITゼネコンの問題点を指摘したい方、ITゼネコンを倒すアイディアがある方、是非、会場にお越しください。 http://www.java-users.jp/contents/events/ccc2008spring/sessions.html#BOF2 また、当日参加できない方でも、いろんな意見をお持ちの方がいらっしゃると思います。「はてぶ」や「はてだ」のコメントなり、トラックバックなりで、引き続きみんなで考えましょう。 「ISIDだってITゼネコンじゃん」と思う方もいらっしゃるでしょう。昔は、そんなこともありましたが、最近は違います。「丸投

今月末ぐらいに、Springsource Application Suite Enterprise Editionというのを発表する予定。これは、Springアプリ用のコンフィグ済みコンテナみたいなもんで、アプリケーションサーバとして、 JBOSSの対抗馬として出すようです。 ウェブサーバはカスタマイズしたTomcatを使って、クローズドソースを含んで、GPLとコマーシャルデュアルライセンスで、コマーシャルの場合はサブスクリプションベースのサポートつきだそうです。 これまでも、あまり仲のよくない(ようにみえる)SpringとJBossですが、ついに全面対決をはじめるみたいですね。 いままで、JBoss上でSpringを使っていたユーザーも多いと思うので、それがSpringのサーバに流れたら、JBossも苦しいでしょう。 このサーバ対決は、その上で使われるフレームワーク対決になるんじゃないで

私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。 liftを開発した人へのインタビューなんだけど、ちょっとひ

Springは2.5からコンポーネントの自動登録も実装され、HOT deploy以外は、Seasar2との差もほとんどなくなりました。私の願いは、「多くの開発者に楽しく開発してもらうこと」なので、Springを使っている人に楽しく開発してもらうことも、もちろん私の願いです。 そこで開発したのが、Super Agile Spring。Seasar2のSMART deploy(HOT deployを含む)のエンジンをSpringに移植したもので、ApplicationContext(Springのコンテナ)のラッパーとして機能します。 例えば、getBean("fooService")した場合、最初、SpringのコンテナにそのBeanが存在するか尋ね、存在している場合は、そのままSpringのBeanを返します。存在していない場合は、名前から自動的に、ルートパッケージ.service.imp

その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの

id:wyukawaさんのSAStruts Pluginの開発開始のお知らせ。 JavaソースからJSPファイルへポップアップメニューかショートカットキーで飛べる。 たとえば、チュートリアルのtutorial.action.AddActionで、 @Execute(input = "add.jsp") public String submit() { result = Integer.valueOf(arg1) + Integer.valueOf(arg2); return "add.jsp"; }の「add.jsp」を選択すると、webapp/add/add.jspに飛ぶ。 DoltengのHTMLとPageクラスを行き来する機能は、とても便利なので、 それがSAStrutsでできるようになるとうれしいですね。 後、/xxx/yyy.jspからXxxActionクラスyyy()メソッドに

> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、 > フレームワーク全体を把握していて、残りのメンバーは >「限定されたことだけやっとけ」みたいなことは好きではありません。 大規模だと好き嫌いに関わらずこういったアプローチになるのでは？ アーキテクト以外の学習コストはむしろ減ると思いますが… きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。 一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。 二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長して

データベースにコードの形で格納されている値を、名称に変換して表示する場合にどう書くのか、試してみました。 それも、コードテーブルをデータベース上でなく、アプリ内部で保持しているような場合です。 proustさんの方法は、ちょっと大げさかなぁ。プレゼンテーション用のモデルを用意するってのは、ほとんどの場合、うまくいきますが、手間がかかるのが難点です。 Converterを使う方法をアドバイスしたのは実は私です(^^;)。最初聞いたときは、単一のエンティティを表示する場合だと思っていたので、Converterでも別に大げさではなかったんですけど、複数のエンティティを扱おうとすると大げさになっちゃいますね。 一番簡単な方法は、エンティティにgetBloodTypeLabel()を用意して、そこで変換する方法です。 public class Employee { protected static

Super Agile Strutsとは、StrutsとSeasar2を使った開発をAgileに行なうためのフレームワークです。今回は、開発中に考えたことをそのまま書いてみようと思います。 Actionは、もちろんPOJOだよね。ActionFormなんていならない。リクエストパラメータは、Actionクラスのプロパティに格納されたほうがシンプル。 リクエストパラメータは、Actionに格納されるので、Actionのスコープはrequest。 URLも*.doなんてかっこ悪い。/ユースケース名/アクション名で書けるようにします。 今の実装だと、/greeting/inputに対するリクエストは、rootpackage.web.greeting.InputActionにマッピングされます。 現状は、ここまでの実装しかできてなくて、次は、ActionForwardの実装を入れます。Action

流暢なインターフェースという訳になってみたいなので、今後は、流れるようなインターフェースではなく、流暢なインターフェースという言い方に変えたいと思います。 流れるようなインターフェースにかわったようなので元に戻します。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FluentInterface http://d.hatena.ne.jp/higayasuo/20071018#1192681950 ぶくまのコメントで、 http://www.objectclub.jp/community/codingstandard/ このあたりのJava規約だとチェインさせるような書き方は避けるべき、となっているとあります(うちの会社のドキュメントじゃん)が、これはいろんな人が思うことだと思うので、私の意見を書いておきます。 まず、可読性が悪くなるという話は、昨日の

Seasarカンファレンスで、Seasar2入門セッションを、いろんな方に喜んでいただけるようにSeasar2ロードマップと復活のStrutsのセッションに変えるよというアナウンスをしたのですが、Seasar2の入門セッションはやはり必要だということで、元に戻すことになりました。 期待していた方ごめんなさい。でも、入門セッションのほうも面白いネタをいろいろしゃべるつもりなので、是非お越しください。 今後はやるフレームワークは「流れるようなインターフェース」を持ったものになるんじゃないかなぁと思います。流れるようなインターフェースの説明は、ファウラーたんのFluentInterfaceを参照してください。 Seasar2の新O/R Mapper(以後S2JDBCと呼びます)もこの「流れるようなインターフェース」を実現しています。例えば、JdbcManagerを使った検索はこんな感じになります

10/19にJavaデベロッパーのためのAIRセミナーが開催されます。 https://g203.secure.ne.jp/~g203204/Adobe/Flex/20071019/ 私も下記のような感じのセッションをやります。 Adobe AIR / Adobe Flex を使って、Java/データベースと連携するアプリケーションをいかにすばやく作るかについて、ALLライブデモでお見せします。実は、私にとってAIR/Flexのデモは鬼門で、まだ一度も(完全に)成功したことはないんですが、今回は、強いマシンを調達したので、大丈夫だと思います。 去年のデブサミのリベンジがんばります。 来週出す予定のSeasar2の次のバージョン(2.4.18)で、S2Daoが統合されます。 正確に言うとS2Daoの後継といわれていた(S2Dao2.0 or S2Persistence)がSeasar2に統合

Seasarファウンデーションとその傘下プロジェクトそれぞれに、このカルトが薄まってきているような気がしてならないのです。 私がチーフコミッタをやってるSeasarプロジェクトに関していえば、カルトはいらないと思います。だって、求められていないもの。全ユーザにヒアリングしたわけではありませんが、「安定して動くこと」「情報が豊富であること」「実績があること」が最も求められていることだと思います。 プロジェクトの立ち上げ期には、ある種のカルトも必要でしょう。しかし、今のSeasarプロジェクトは、キャズムを超えて、アーリーマジョリティが相手です。アーリーマジョリティが重要視するのは、実績でしょう。今月のSeasar-user MLには、既に700通のメールが流れています。これほど活発な技術系のMLはそうはないでしょう。これらのメールに一通一通丁寧に答え、ユーザのプロジェクトを成功させ、実績を積

http://d.hatena.ne.jp/higayasuo/20070416#1176719022の続き。 それでは、DIContainerの機能で本当に必要な2つの機能って何でしょうか。一つは、インスタンスのスコープ管理です。スコープとは、singletonだとかprototypeのようにインスタンスが存在する範囲のことです。たとえば、singletonの場合は、いつ取得しても同じインスタンスが返ってきて、prototypeの場合は、取得するたびに新しいインスタンスが返ってきます。 このスコープ管理は、単純にオブジェクトをnewしているだけでは達成できません。以前のコードを見てみましょう。 Service service = new Service();これは、ある意味prototypeですが、これをsingletonにしたい場合、次のようなコードにする必要があります。 Servic

デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 Flex2では、モデルとUIコンポーネントと間の自動バインディングがサポートされています。自動バインディングとは､モデルの値が更新されたら自動的にUIコンポーネントの表示が更新されたり､UIコンポーネントに入力している値が変わったら､自動的にモデルの値を更新する機能です。 デフォルトではバインディングは単方向です。基本的には､モデルの変更をUIコンポーネントが検知するだけ。例えば､次のようなMXMLがあったとします。 <?xml version="1.0" encoding="utf-8"?> <![CDATA[ [Bindable] private var hoge:String; ]]>

JPAには非常に期待している人も多いでしょう。私もその一人です。実際にプロジェクトで使ってみて、見えてきた問題点を書いてみます。JPAの実装としては､Hibernate3.2を使っています。 学習コストが高い。 JPAの全機能のうち､プロジェクトで使うものに絞り込んで教育すると、3日程度で教えることができるのですが､そこそこ使えるようになるには､2〜4週間かかります。これは、Hibernate in Actionにも書いているのでそういうものなんでしょう。 トラブルシューティングが難しい。 多くのプロジェクトで実際にハマルのはこれでしょう。うちのプロジェクトでは､Hibernate職人である小林さんがいるにもかかわらずいろいろ苦労しました。Hibernate職人のいないプロジェクトで使うのは厳しいのではないかと思います。 SQLの扱いが貧弱。 JPQLは、SQLのかなり貧弱なサブセットなの

RailsやChuraのいけてないところ Churaのこと Web屋さんと業務屋さん はぶさんの「DBからの自動生成って客寄せパンダじゃん」という疑問に答えるのがページ駆動開発とテーブル駆動開発です。基本はUI(ページ)を起点にして開発。マスターメンテ系はテーブル駆動で開発するということです。 はぶさんに、物を出さない前にあれこれ言っても誤解を招くといわれていたので､今回のChuraは、秘密裏に開発を進めました(笑)。 scaffoldも客寄せパンダではないと思いますよ。マスタメンテ系ならあれで十分だと思います。業務系の画面をテーブル駆動で開発するのはちょっと辛いですね。ユーザから情報を引き出しやすいのはUIなので。

Seasar2.3の時代は､Goyaと言われる開発手法がありました。Goyaのアーキテクチャは､JavaEEの基本にのっとったレイヤモデルアーキテクチャです。詳しくはこの辺。 http://d.hatena.ne.jp/higayasuo/20050817#1124260949 http://d.hatena.ne.jp/higayasuo/20050818#1124338844 役割分担がきちんとされているきれいなアーキテクチャだと思うのですが、CRUD(Create Read Update Delete)しかないような単純な画面でもそこそこクラスが必要で重い感じがするのも事実です。 過去のDIではインターフェース中心の設計が強く推奨されていたため､レイヤモデルアーキテクチャは重く感じられても非常にDIにフィットしていました。 しかし、Javaでさらに生産性を高めるためには､レイヤモデル