Big Joltがやってくる

Fearless Change

いよいよ来週がAgile Japan 2011が開催されますね。僕はスタッフとか、実行委員とか、そういう立場の人間ではありません。ただ、今回基調講演されるお二方の一人、リンダ・ライジングさんと、その講演「Fearless Change - 不安を乗り越えて組織改革を推進するには」が楽しみでブログを書いています。
この「Fearless Change」とは、リンダ・ライジングさんとマリリン・マンスさんのお二人で書かれた書籍のタイトルでもあります。書籍では人々の集まっている場所に新しいアイディアを広めるための48のパターンと、その戦略が270ページ足らずにまとまっています。

Fearless Change: Patterns for Introducing New Ideas

Fearless Change: Patterns for Introducing New Ideas


僕はAgile本読部というコミュニティでこの書籍を継続して読み続けており、毎度毎度とてもエネルギーをもらっています。会のメンバーの一人であるid:wayaguchiさん*1によるとその書籍をAgile本読部の中で21ヶ月読み続けているらしいです。出版が2003年なので古いように思えますが、全くそんな事はなく、読むたびに新しい事に気づかされる本です。そのせいか、原著は結構いろいろな本から引用されています。例えば手元で確認できただけで、下記の2冊見つかりました。
アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)


実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)


残念な事に日本語版は出版されていません。なぜ日本語版が出版されていないのかと言うと、どうも大人の事情らしいです。ただ、この本のファンは本当にたくさんいるので、出版されない事が残念でしかたありません。

さて、このブログのタイトルは「Big Joltがやってくる」としましたが、「Big Joltってなんぞ？」って思われた方もいるかと思います。Big JoltとはFearless Changeに書かれているパターンの一つで、一言にまとめると、「高名な人を招いてお話頂く事でその場にいる人に衝撃を与えること」です。*2元々Introducing Patterns into Organizationsというタイトルで論文が書かれており、その邦訳をされている方がいるので、興味のある方はこのリンク先も見てみてください。

で、せっかくなんで、Fearless Changeの目次の一部(Part1)を訳してみました。括弧付きは原文です。直訳になっていないのは、本文を読み返して感じた事を付け足しています。

I. 概要(OVERVIEW)
1. 組織と進歩(Organizations and Change)
    チェンジエージェント(The Change Agent)
    進歩のスピードを早める文化(The Culture)
    アイディアを広めたい人々(The People)
2. 戦略かパターンか(Strategies or Patterns)
    パターンのフォーマット(Pattern Formats)
    パターンの使い方(Using Patterns)
3. どこから始めよう？(Where Do I Start?)
    信念を持ってアイディアを伝える事こそ成功の要。(Evangelism Is Critical for Success.)
    次の1歩となるいくつかのパターン(A Small Package of Patterns.)
4. 次に何をしよう？(What Do I Do Next?)
    ターゲットのグループに助けを求めよう(Target Groups to Ask for Help.)
    感謝を伝える事を忘れずに(It's Important to Say "Thanks".)
5. 集まりをより良くする方法(Meetings and More.)
    集まろう！(Let's Meet!)
    もう一歩進めるために情報を使おう(Using Information That's Out There.)
    連絡を取り続けよう(Stay Connected.)
6. 行動しよう(Take Action!)
    学ぶための別の方法(Other Ways to Learn.)
7. すべてはみんなのためにある(It's All About People.)
    組織のためにできることはなんですか？(What's in It for the Organization?)
    あなたも感じるんですか？(You Have Feelings, Too!)
8. あなた専用の役割が新設されました！(A New Role: Now You're Dedicated!)
    ボスからむしろ業務でやってと任せられました！(You Have Convinced Them–You Are a Dedicated Champion.)
9. 多数派を説得する(Convince the Masses.)
    達人や有名人から信頼を得る(Enlist Gurus and Famous People.)
10. より広めるための戦略(More Influence Strategies.)
    行動を見えるように保つ(Keep Things Visible.)
    お土産(It's Just a Token.)
    開催場所も数えよう(Location Also Counts.)
    ハミングでも歌いながら(Things Are Humming.)
11. 辛抱強く続けよう(Keep It Going.)
    一歩先を見よう(Be Proactive!)
12. 抵抗勢力を相手にする(Dealing with Resistance.)
    橋渡しを築く(Build Bridges.)
    懐疑派の親分(A Champion Skeptic.)
    全ては政治(It's All About Politics.)

興味を持った方はAmazonでお買い上げくださいませ。どうもKindle版も発売されているそうですよ。そちらは10ドルくらいらしいのでお得です。
このブログを読んで興味を持ってくださった出版社の方がいらっしゃいましたら agilebooks-reading@googlegroups.com にご連絡いただけると幸いです。

2年近く読み続けてきて自分はどうChangeしたか？

なんかツイートしておいて、大事な事を書いていなかった事に気づきました。僕はこの本を読む前から新しいアイディアを自分の職場へ広める事をしていました。なのでこの本を読む前と読んだ後で何が変わったか、ふりかえってみると、本当に大切なアイディアであればうまく行かなかった時にすぐに投げ出すことはなくなりました。少なくとも共感してくれる人がいれば、その人とうまく連絡を取り合い、少しずつでも前進するようにしていました。2年たって、やっと芽が出始めている、と言う段階なので、チェンジプロセスにかかる時間は長いのですが、一旦文化を形成できれば、その文化はなかなかなくならないだろう、という事も感じています。
Fearless ChangeのパターンにはShoulder To Cry Onというパターンがあります。これは壁にぶつかった時に悩みを共有できる場を作るというパターンなのですが、まさに本読部がその場となっていたのです。継続的に参加しているメンバーはそれほど多くないのですが、職場の悩みをオブラートに包んだ形ではあるのですが、吐き出せる場があった事で自分の思うチェンジプロセスを継続できた事はただの勉強会では得られないものになりつつあります。端から見ているとDevLoveなんかは、同じ想いを持った仲間達が集う場所と言う意味で、Shoulder To Cry Onパターンに当てはまる場になってるんだろうなー、と思ってます。

Agile本読部のメンバーにとってそういう場になった読書会が、今後Agile Japan 2011をきっかけにより全国に広まるように、何かできないか、考えています。詳細は近い将来にお知らせできると思います。(全然時間がない事に今気づいた。ごめんなさい＞＜)

*1:非公式らしいですが、[http://d.hatena.ne.jp/wayaguchi/20110409/1302321264:title=1章の翻訳が公開されているみたいです。]

*2:驚く事にFearless Changeの中には勉強会(Study Group)もパターンとして入っています!よく言われるブラウンバッグ・ミーティングもFearless Changeのパターンの一つです。

Google Chromeで英辞郎を便利に使う

Chrome

Googleさまで「和英 ご飯」と検索すると以前は英辞郎へのリンクが表示されていたようですが、最近は表示してくれなくなりました。非常に不便です。そういう時はつぶやいてみるといいみたいです。


すると@さんから

と言われたので、設定してみたところめっちゃ便利だったのでまとめました。最終的には

と言う感じに「英」とアドレスバーに入力してtabキーを押して日英検索できる感じに僕はしました。そのやり方をまとめます。

まずオプションを開きます。

続いて検索の管理画面を開きます。Macの場合は「個人設定」タブの「検索」のところの「管理」ボタンですが、OSごとにより異なるみたいです。

お次は検索エンジンの追加です。左下のボタンを押しましょう。(例によってOSごとに異なります。)

ここで英辞郎を追加します。キーワードを僕は「英」にしましたが、お好きなものを追加してください。

すると、アドレスバーで先ほど入力したキーワードを受け付けるようになります。こんな感じで。

で調べたい言葉を入力してtabキーを押すと

そのまま検索できるのです。

便利！！


@さんありがとうございました！

追記

後で見つけたんですが、こちらのブログのほうが先にまとめられていますね。
http://techblog.ecstudio.jp/tips/useful_search_by_google-chrome.html

Test Doubleを使うとテストの信頼性/保守性が下がるのか？

テスト

最近はユニットテストを行うテストコードにおいて、Test Doubleを多用してます。Test DoubleとはMockとStubを合わせた総称です。Test Doubleを用いると、信頼性や保守性が下がると言われることがあります。しかし、それはTest Doubleの用法を誤っているためではないかと僕は思うのです。Test Doubleの用途はユニットテストのスコープをテスト対象のクラスに限定するために用いるべきものです。実感として、Test Doubleを使っているからと言って、ユニットテストの信頼性/保守性が下がったとはあまり感じていません。

良く誤解されていますが、Test Doubleはスローテスト問題を解決するための手段ではありません。Test Doubleをうまく利用すれば、結果的にスローテスト問題を解決できます。しかし、スローテスト問題を解決するための手段ではないのです。スローテスト問題の手段としてTest Doubleを用いてしまうと、DBのセットアップが不要などの理由により、安易にファンクショナルテストやシステムテストなど、複数のクラスを串刺ししたテストにも用いようと考えます。そうしたより高いテスティングのレイヤにおいてTest Doubleを用いてしまうと、インタフェースの不整合がおき、想定していたデータと違うデータがTest Doubleから与えられてしまい、信頼性や保守性が下がってしまうのではないでしょうか。

ユニットテストにおいて、検証すべき事柄は、そのクラスに実装されているロジックが意図した通りに動作しているか、と言う事です。なので、相手にするスコープに限定してあれば十分です。UIのテストをしているのに、DBやファイルのセットアップが必要だとすれば、そのテストはユニットテストとしてのスコープを越えてしまっています。UIのユニットテストでは描画や操作に必要なオブジェクトのモックで十分テストができます。

クラスとクラスを串刺しにしたテストは、ユニットテストよりも上のレイヤーのテストで確認します。すなわちファンクショナルテストなり、全てのテストをまたいだ統合テストで確認します。それぞれのレイヤではユニットテストで行うほど、細かな観点でテストすべきではありません。いくつかのクラスを結合したテストですから、それぞれのオブジェクトのインタラクションを確認し、エンドツーエンドでの動作を確認することが目的です。

ところで、読みやすく、分かりやすいコードを書くには、実装時にクラスとAPIが担う責務を明確にし、それぞれを小さく保つことはもはや定石の一つと言ってよいでしょう。単一責務の原則も、1メソッド辺りの行数の指標も、変数のスコープを制限し、カプセル化しておくことも実は同じことを言っています。一度に考えなければならないことを減らすように実装をする事を指しているのです。
ユニットテストにおいても同じです。確認すべき事項を細かくあげ、一度に多くの事柄を相手にしない、というのは、一つ一つの確認において、複雑に考えなくてもよいようにするためなのです。

そう捉えてみると、Test Doubleの使いどころが見えてきます。テスト対象以外のクラスからの振る舞いに影響をできる限り受けないように実装するのです。そのためのMockであったり、Stubです。だから、ユニットテストでDBを直接操作するクラスのテストを書いている訳でもないのに、DBのセットアップを行うのは、ユニットテストの役割を考えると過剰な作業です。普段は起きないような例外が起きたとき、それがきちんと扱えているかチェックするテストコードをリグレッションテスト出来る方が重要です。

と言う事で、自分のTest Doubleに対する考えをまとめてみました。

5分でEclipse PluginをGroovyで書くよー。

Groovy Eclipse Plugin開発

ぼーっとしていたらEclipse PluginをGroovyで書いてました！他のJVM言語でもEclipse Plugin書けるんです！
Eclipseはe4プロジェクトでJava以外の言語(例えばJavaScript)でもPluginの実装を実現しようと頑張ってますが、なんか3系でもできちゃった。

必要なもの(環境)

こっからはほぼ画像ペタペタ貼っているだけです。この通りに作業すれば同じようにプラグインが作れます。

ほいじゃ、実際に作っていくよー。

まずGroovyプロジェクトを作るー

プロジェクト名は「 eclipse-plugin-by-groovy 」って作りました｡

GroovyプロジェクトをPluginプロジェクトにコンバート


MANIFEST.MFを編集してGroovyのライブラリやらEclipseのライブラリを追加するっす。



下記のダイアログが出るので、次のプラグインを追加するっす。

こんな感じで追加したらこんなんなります。

続いてメニューの拡張ポイントのテンプレートを追加するよー。


テンプレートの内容をカスタマイズするページが表示されるっす｡そのままでOKっす。

テンプレートが出力されたので、Javaのファイルができました。groovyにするっす。



ソースを編集するよー



完全版のソースコードはこんな感じ。

package eclipsepluginbygroovy.handlers;

import org.eclipse.core.commands.AbstractHandler;
import org.eclipse.core.commands.ExecutionEvent;
import org.eclipse.core.commands.ExecutionException;
import org.eclipse.ui.IWorkbenchWindow;
import org.eclipse.ui.handlers.HandlerUtil;
import org.eclipse.jface.dialogs.MessageDialog;

class SampleHandler extends AbstractHandler {
	/**
	 * The constructor.
	 */
	SampleHandler() {
	}

	/**
	 * the command has been executed, so extract extract the needed information
	 * from the application context.
	 */
	def execute(ExecutionEvent event) throws ExecutionException {
		def window = HandlerUtil.getActiveWorkbenchWindowChecked(event);
		MessageDialog.openInformation(
				window.getShell(),
				"eclipse-plugin-by-groovy",
				"Hello, Eclipse world");
		return null;
	}
}
実行してみよー。

Eclipse Applicationを追加するよー。左側のEclipse Applicationを選んで､ノートに+がついたようなアイコンをクリック

「Eclipse Plugin by Groovy」と言う感じでNameをつけてあげよう。Macユーザーの方は、Arguments(引数)タブを開いて､VM Arguments(VM引数)に-d32を追加してください。そんでOKを押してみる｡

するともう一つEclipseが立ち上がるので、ツールバーのこのボタンを押してみよー。

うまくいくとこのダイアログが出るよー。


おしまい。

今回はメニューやツールバーのテンプレートを使いましたが、ビューやらエディタやらも各拡張ポイントに対応するクラスを指定すれば同様に動作するはずです。

種明かし

と書いてみましたが、特に種はありません。Groovy Eclipse環境下では、groovyのソースコードがコンパイルされclassファイルになります。groovyのクラスファイルは、実行時にgroovyのランタイムが必要ですが、プラグインの実行時に依存関係にgroovyのライブラリを含んでいるため、意図したとおりクラスが実行できるのです。

これってば他のJVM言語でもうまくいくのではないか!?

Groovyの場合、Javaとソースコード変換をするプラグインがあるのでさくっと行きますが、他のJVM言語でも依存ライブラリにその言語のライブラリを指定すれば動くはず。近いうちにScalaとかJRubyとか試してみたいと思います。それができれば、ポリグロット(多言語)eclipse環境が実現されますね。ではではー。

Eclipse Plugin開発のチュートリアルを公開します。

Eclipse Plugin開発

1/28に僕のふるさとの名古屋でEclipse Plugin開発セミナーが開催され、講師として参加してきました。そのために作成したEclipseプラグイン開発のチュートリアルを公開します。

http://kompiro.org/nagoya-seminar/html

このチュートリアルはチュートリアルを通じて手を動かしてみる事でプラグイン開発とはどういったものかを、一通り学ぶ事を目的にしています。手順通りに実施すると二つ小さなプラグインを作成できるチュートリアルです。

このチュートリアルではまだテストコードを書いたり、ビルドサーバを立てたCIのやりかたなどは取り上げていませんが、その辺りも追加できればと思っています。

Eclipse Orionのためし方

Eclipse Orion

Eclipse Orionのためすための手順はたった3つです。(あ、試す前にJavaはインストールしておいてくださいね。)

  1. 0.2 M4のサイトからOrionサーバを起動したいプラットフォームのパッケージをダウンロードする。
  2. できるだけパスの短い適当なフォルダに展開する
  3. eclipse何チャラをダブルクリック

・・・これだけです。ソースコードが配布されているなんてもんじゃないです。実際多少ですが動くもんも公開されてました。
動かしてみると、サーバ内のワークスペースにあるファイルを編集できるのですが、色づけやら文法エラー解析やらはできてました。(日本語があると解析がうまくできていないようですが。)
パッケージの展開後のものを見ていたければ分かるように、Orionはサーバ側のテクノロジはEclipseプラットフォームをそのまま使ってます。EquinoxというOSGiコンテナ上にJettyがHttpをサーブし、その上にOrionのアプリケーションが乗っかってると言う。e4はJavaScriptもファーストクラス言語になりそうなので、だいぶいろいろ出来そうです。
ブラウザ上で動くIDEは正直デスクトップのIDEとはやっぱり利用用途が違う気がするんですが、こういう環境が整ってくるといろいろ妄想が膨らみますね。お試しを。

次第に腐るテストコード

自動化 テスト

結論を最初に書くと、
テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。
最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。

「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。
なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テストコードは毎朝結果を確認しないといけないくらいセンシティブな生き物なのでしょう。

なので、テストコードを書いているから、「テスト自動化してます」なんて言ってたら微妙なのではないかと。そう。気づいた時にはリグレッションで動かないテストコードだらけ。あなたの周りに腐ったテストコードないですか？

と言う事で2011年初エントリ。みなさま、今年もよろしくお願い致します。