InfoQ: JSR-299 と Weld 1.0 の Java EE と JBoss への影響についての Gavin King との Q&A
原文(投稿日：2009/11/18)へのリンク Red Hat の JBoss 部門は、JSR-299: Contexts and Dependency Injection for Java EE(以降では CDI とする) のための Java EE 6 参照実装である、Weld 1.0.0 を出荷した。Weld は、Sun の GlassFish Application Server バージョン 3 および、来たる JBoss AS 5.2.0 で使われている実装である。しかしながら、完全なアプリケーションサーバを必要としない。Weld は、Jetty 6.1 や Tomcat 6 のようなサーブレットコンテナにおいて動作させることができるし、Java SE 5.0 以上とですらも動作する。後者を示すために、Weld 配布には、コンソールアプリケーションの例と Swing アプリケーショ
InfoQ: Bobおじさんが述べるTDDの適用可能性
原文(投稿日：2009/11/04)へのリンク "TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。 氏はまず"TDDはアーキテクテャの代替物か？"という大きな問題を取り上げ、実例を背景に「そうではないですが、しかし...」と答えている。 いちから始めて次々にテストケースを書いていくことで実行可能なアーキテクチャを生成できるという意見は全くばかげたことです。テストしないという決断を下す必要もあります。 もちろんこれらの決断の多くはできるだけ先延ばしにすることができるし、そうすべきです。例えば、データベーススキーマは恐らく長い時間待つことが可能なものです。Spring、JSF、Hibernate、JPAなどを使うかどうかの決
ハイパフォーマンスチーム - チーム殺しを避けるには
原文(投稿日：2009/6/5)へのリンク Steven Denning氏は近頃、ハイパフォーマンスチームに関する一連の記事を書いた。ハイパフォーマンスチームは、アジャイル組織が効率的であることを裏付けるのに必要だとされている。 Denning氏によると「ハイパフォーマンスチームは職場にあるチーム全体の2％にすぎない」そうだが、彼は次のように語っている。 「マネジメント慣行が正しいときには、たくさんのハイパフォーマンスチームがいます。それがトヨタとホンダ、そしてソフトウェア開発で起こっていることなのです。どれくらい"たくさん"なのか？正確に言うのは難しいことです。トヨタとホンダは自動車産業の4分の1を占めています。ソフトウェアにおいては、おそらくソフトウェア開発全体の3分の1が、今や"アジャイル"や"Scrum"、"XP"という名札を付けて、ハイパフォーマンスチームになるべく進歩している、
アプリケーション構築、Workflowの利用法
原文(投稿日：2009/6/10)へのリンク David Chappell氏は、彼の新しい論説「Workflow way」の書き出しとして、優れたサーバー・サイド・ソフトウェアを書くとは何を意味するのかを論じるている。 コードを書く人なら誰でも優れたソフトウェアを作りたいと思っています。サーバー・アプリケーションの場合、拡張性に優れ、多くのリソースを使うことなく大量の負荷をこなすことが優れているという意味の一部分でしょう。また、優れたアプリケーションは作成者とメンテナンスを担当する人双方が理解できるものでなければなりません。これらの２つを同時に実現することは簡単ではありません。アプリケーションに拡張性を持たせるためのアプローチとして、ロジックをばらばらの理解しずらい断片に分割するという手法がとられることがよくあります。一カ所で実行される一つにまとめられたロジックを書くことでアプリケーション
Google Wave アーキテクチャ
原文(投稿日：2009/6/1)へのリンク Google Waveは3つの要素で成り立っている: ツール、プラットフォーム、そしてプロトコルである。そのアーキテクチャの核は、並行制御をサポートするための理論的フレームワーク、オペレーショナルトランスフォーメーション（OT=Operational Transformation）である。 まず最初に定義が必要だろう。Google Waveとは: （ウェーブと呼ばれる）ホストされたXMLドキュメントをベースとした、並行に行われる変更と遅延の少ない更新をサポートする、新しいコミュニケーションとコラボレーションのプラットフォームである。 ツール Google Waveは「電子メールプログラム＋インスタントメッセンジャー＋協調的な文書共有と編集ツール」である。クライアントサイドではJavaScriptとHTML5を使っており、Chrome、Firefo
InfoQ: 複数のアジャイルチームでのバージョン管理
複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント（イテレーション）だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図（壁張り用） この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ
アジャイル認定批判の新たな波
原文(投稿日：2009/4/1)へのリンク 長い間、アジャイル認定の話題はコミュニティで何度も繰り返し議論の中心となっている。これは望ましいものなのだろうか？可能なのだろうか？茶番、詐欺なのだろうか？近頃、認定に反対の主張をする議論の波が起きているが、それは主に、そのような「アジャイル認定」を与えることを主張する新しい企業に対する反対である。 Elisabeth Hendrickson氏は、このアジャイル認定批判の波を最初に起こし、この話題に関する自身の考え(リンク)を投稿した。記事の中で彼女は、認定がアジャイル開発を構成するものの大部分に与える価値はほとんど無いという意見を述べるとともに、いつどれほど認定が役に立つかを明らかにしている。過去の認定プログラムに関する自身の経験をまとめ、彼女は次のように述べている： 私には、ソフトウェアのテストができることとISTQBの認定を持っていることに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JUnit 4.7: Per-Test rules
受入テストの自動化 - 理論にすぎないのか、それとも実践的なのか
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
なぜTDDとペアプログラミングで生産量が増えるのか
機敏さ、職人的技能、そして成功の評価
Scott Ambler氏がアジャイル・プロセス成熟度モデルを再考する
塹壕より Scrum と XP
Recommended TDD Tutorials
InfoQ: TDDを根づかせる:導入の問題と解決策
ユースケースの父がアジャイルはもっと賢くなる必要があると語る
Erich GammaによるJazz、Eclipse、JUnit、そしてデザインパターンに関する議論
Javaトランザクションモデルをベースにしたトランザクション戦略
多難な2009年、ビジネスに価値をもたらすアーキテクチャのトレンド