2013-03-24

『〔改訂〕Trac入門』が良書の件

書評 Trac

遅くなってしまいましたが、『〔改訂〕Trac入門』を献本いただいたので、書評というか感想を兼ねて内容の紹介をしたいと思います。

はじめに

僕は初期バージョン（白本）を読んでいないので、前と比べてどうだったかという見解は一切ありません。ご了承ください。白本をお持ちの方は id:kanu-orzさんの Trac入門 - almost nearly dead の方が参考になるかと思います。

良かった点

良かったところはたくさんあるのですが、本書は Trac の入門書の側面とプロジェクト管理のガイドラインとしての側面を持ち合わせており、またバージョン管理ツール(VCS) や CIツールとの連携についても一章を割いているので、ここでは Trac に関する内容、プロジェクト管理に関する内容、ツール連携に関する内容に分けて述べたいと思います。

Trac に関する内容

Trac に関しては１、２、６、８章の内容が特に充実しています。１章では前半の説明と後半のケーススタディを通じて、Trac の特徴とどのような導入メリットがあるのかを理解できるようになっています。Trac をはじめとする問題管理ツールを全く知らない人が読んでも、１章だけで大体のイメージは掴めるのではないでしょうか。

２章は Trac の情報の基となるプロジェクト、マイルストーン、コンポーネント、バージョンの概念とその登録方法の説明が中心となっていて、手っ取り早く使い始めたい人は２章まで読めば、Trac のスタートラインに立てるかと思います。初歩的な入門書としての内容はここまでとなっており、１、２章は導入編として非常に良くまとまっているなと感じました。

６章は実際に使っていく中で必要になったり、やりたくなるようなことが逆引き形式で書かれています。Trac のようにベースがシンプルなツールは、本格利用していくと自然とカスタマイズしていくことになるので、この構成は非常に良いと感じました。Tips も35個もあり、しかもどれもが実用的なところは素晴らしいなと思いました。著者達の実プロジェクトでの経験やノウハウが詰まっていて、Trac を利用して運用管理する人にとって参照する機会が最も多くなる章だと思われます。

８章のリファレンスは、システム構成、インストール手順、コマンド、設定ファイルの説明と申し分の無い内容になっています。設定については対応バージョンも記載されていて、利用バージョンの違いにも配慮してあるとこは嬉しいところですね。

プロジェクト管理に関する内容

プロジェクト管理に関しては３、４、７章の内容が参考になります。もちろん、これらの章でも Trac のxx機能で実現できます、と書いてあるのですが、Trac を他のツールに置き換えて読めば、一般的なプロジェクト管理の書籍として違和感ない内容かと思います。

３章は Tracを使用して問題管理を行う際の一連の流れを具体例で説明しています。問題発生後からチケット登録〜解決までの流れと登場するロールは、他のツールを利用する場面でもそのまま当てはめることができるので、ガイドラインとして非常に良いと思います。

４章はプロジェクト管理で必要となるであろうxx管理について、何に対してどのような観点で管理(コントロール)したら良いかというガイドライン的な内容が充実しています。これから管理業務を行う人、既にやっているがうまくいっていない人には参考になると思いますし、記載されてるフローを雛型として現場向けに流用することで、円滑なプロジェクト運営ができるのではないでしょうか。

７章は Trac を他のツールに置き換えて考えると、汎用的なプロジェクトでの問題管理ツールの使い方のプラクティスとして捉えることができます。普段できているようで意外とできていないことなど、何かしら気づきが得られるのではないかと思います。

ツール連携に関する内容

ツール連携については５章に書かれています。本書では VCS の Subversion と Git、CIツールとして Jenkins を取り上げています。最近では Git を業務で使用することも珍しくなくなってきていますが、まだまだ Subversion を使う機会は多いと思いますので、VCS に関してはいい選択だと思います。Jenkins はデファクトの CI ツールの地位を築きつつありますので、こちらの記載も嬉しいところです。ツールの詳細は専門書を参照する必要がありますが、とっかかりとして必要十分な説明があり、各ツールと Trac との連携方法が書かれていますので、併用する際には参考になると思います。

良くなかった点

いいことばかり書いてると「宣伝乙」と思われてしまうので、もうちょっとあると良かったなぁというところを二点あげます。

５章に書かれている他のツールとの連携は、今時のソフトウェア開発で Trac を使用する際には、避けて通れないところですが、もう一歩踏み込んで書いてあるともっといいなぁと思いました。連携するツールについてどこまで書くのか、というのは非常に難しかっただろうなと想像しますが、シンプルなものでも Trac と VCS と Jenkins を絡めた一連の流れの例があったら、より良かったと思います。あとは Git や Jenkins との連携についての Tips などがあればさらにグッときただろうなと。

もう一点は７章の「Trac あるある」です。ここだけ他の章に比べるとやや淡白というか、さらっと書いてあるので少し物足りない感がありました。「チケットの概要・説明を見ても意味がわからない」や「１つのチケットに２つ以上の関心事が書いてある」などといったネタは、地味ながらもあると面倒な問題ですが、どこのプロジェクトでも高い確率で見かけるものなので、どのように書くと良いかを具体的な例を示して書いてあったら、もっと良かったろうなぁと思います。

まとめ

以上、ざっくりと内容をご紹介しましたが、読む前の予想より良書だったと感じました。何よりも「読みやすさ」「分かりやすさ」においては文句の付けようのないレベルなので読む人を選びません。それでいて実用的な Tips、充実したリファレンス、プロジェクト管理のガイドラインと揃っているので、様々な場面で重宝する書籍だと思います。これからリーダーや管理業務を担う若手エンジニアには、必読の一冊と言っても過言ではないですね。

もちろん「うちは Trac じゃないから」という方もいるかもしれませんが、プロジェクト管理のガイドラインの内容の多くは、Redmine でも JIRA でも Backlog でも通用します。そういう意味ではシステム開発会社に一冊置いてあっても良いのではないでしょうか。これくらいの書籍代をケチるような会社はないですよね？:-P

ということで、まだ読んだことのない方は、ご自身で買われるか会社で買ってもらうかして、是非一度お手に取ってみてください。

〔改訂〕Trac入門 ~ソフトウェア開発・プロジェクト管理活用ガイド (Software Design plus)

作者: 菅野裕,今田忠博,近藤正裕,杉本琢磨
出版社/メーカー: 技術評論社
発売日: 2013/03/08
メディア: 大型本
購入: 1人クリック: 13回
この商品を含むブログ (5件) を見る

2012-12-20

[Spock] Spock 関連でゴニョゴニョしてる件

JGGUG

こんばんは。[twitter:@bikisuke] です。

今日の Advent Calendar ネタは、Spock です。
僕は G* 一派だからという贔屓目は抜きにしても、Java のテスティングフレームワークとして Spock はもっと評価されるべきじゃないかと思ってます。
なので、今回はその辺りに触れつつ、密かに企んでいることについて書きたいと思います。

Spock のいいところ

何と言っても、シンプルな記述ができるところは Spock の大きな魅力ではないでしょうか。もちろん、テスト対象クラス（機能）によっては複雑になることもあるかもしれませんが、可読性に関しては JUnit の比ではないと思ってます。
# これは Groovy と Java の言語特性や制約に依るところが大きいので、Spock が良くて JUnit がダメと言ってるわけではないです。念のため。

あと、拡張の仕組みもいい感じだと思いますね。現状だとサンプルとかソースを読まないと、どう拡張すればいいのか分からないのが残念なとこですがw
Spring を使ってる人は Spring 用の拡張ライブラリは既にあるので、導入をオススメします。

Spock の弱点

とは言いつつも、情報が少ないとか受け入れテスト（UAT）に不向きとか弱点もいくつかあります。
個人的には、特に UAT に使えないのはもったいないなぁと思ってます。
今、Java で UAT の自動化をやろうとすると、Cucumber ぐらいしかないような気がします。でも、Cucumber は自分的にはちょっと無いんですね…

なぜCucumber じゃダメなのか？

単に個人的な好みに依るのですが、Cucumber はフィーチャファイルとテストコードを正規表現でマッピングさせる必要があります（僕の知る限りでは）。

これがね・・・やっぱり好きくない。自分が Ruby に後ろ向きなのも一因ですけど、やはり可読性の面で良くないし正規表現は直感的とは言い難いですよね。
＃これも自分が正規表現を得意としていないってこともありますけど...

でも、UAT をプロダクトオーナーとかユーザーに書いてもらって、それをそのまま利用できるってのは UAT として非常に魅力的なこと（というより必須？）だし、[twitter:@shuji_w6e] さんが現状では Cucumber 一択、と言われるのも理解できます。

Spock を活用するために

前置きが長くなりましたが、そんなこともあって、今 Spock を UAT で使えるようにするサポートツールを作っています。
本当は [twitter:@nobeans] さんのように Advent Calendar のタイミングで公開したかったのですが、いろいろ問題を抱えていて、只今絶賛開発中です。

ユースケースとしては、Gherkin 書式っぽいテキストをユーザーに記述してもらい、それをインプットにして Spock のテストコードスケルトンを吐き出す、という利用方法を想定しています。

スクリーンショットを見てもらうのが一目瞭然ですかね？こんなイメージです。

HelloSpock.feature ファイルを用意してですね、

FeatureFileParser に喰わせるとメソッド化するって感じです。
これを HelloSpockSpec.groovy として出力させようという魂胆です。

実際にこれが有効アプローチかどうか分かりませんが、ニーズがあるなら、grails プラグイン化とかIDE対応とか考えていきたいなと思ってます。
まぁ、まずはベースとなるエンジンを完成させるのが直近の目標ですね。

まとめ

ということで、できれば来月中に公開したいなと思ってますが、早く試してみたい方は「はよ！」と急かしてください。
#そしたら、もうちょっと力を入れて頑張ります。:-P
来年は Spock の普及活動をもっとやってこうと思うので、賛同いただける方は一緒に Spock 盛り上げていきましょう！

明日は、名古屋のにゃんこパパで御馴染み？の [twitter:@bluepapa32] さんです。よろしくお願いしまーす。

2012-02-19

デブサミのコミュニティLTやりました

Event JGGUG

先日のデブサミでJGGUGを代表してLTをさせていただきました。
自分の中ではやらかしてしまった感がいっぱいなので、スライドを闇に封印しようかとも思いましたが、今後の糧とするために、あえて公開しておくことにします。

Devsumi2012 JGGUG LT

View more presentations from bikisuke

銅鑼が鳴った後のスライドについて少し補足すると、今週水曜の2月22日 JJUG Night Seminar 2012年2月(東京都)ではid:nobusueさんがJGGUGを代表して登壇します。InvorkDynamicへのGroovyの対応についてお話されるようですので、興味深い内容になると思います。

4/4-5の地鎮祭とは | 地鎮祭お届け隊ではJGGUG関連のセッションが２枠あります。１つはJavaプロジェクトをよりアジャイルにするために、G* なプロダクトを導入しませんか？といった内容の一般セッションです（詳細は未定）。もう１つはJRuby, Scalaコミュニティと合同で行うBOFで、こちらもまだどう転ぶのかわかりませんが、様々な言語バトルが繰り広げられるかもしれません。

通常、告知スライドは前に持ってくるのがセオリーですが、流れを重視して最後に持ってきたら時間切れとなってしまいました。ここまで話せれば内容の薄さはともかく、それなりの形にはなったと思うのですがね。。。

デブサミ関係者、LTを聴きに来られた方々、そしてJGGUGの皆さん、
しょっぱいLTですいませんでした。

もう少し場に相応しい内容でやれたら良かったのですが、あのような場は全く想像できませんでした。
というより、想像しようとしてなかった、の方が正しいかもしれません。所詮どこでやろうがLTはLTだろ？と甘く見ていた自分がいましたから。

ただ、結果的に失敗はしたものの、貴重な経験をさせていただき、すごく勉強になったなと思っています。
今回機会をくださったデブサミ関係者の方々に、深く御礼申し上げます。

ありがとうございました。

2011-12-11

resolveStrategy の基礎

Groovy JGGUG

G* Avent Calendar の11日目です。

たぶん、この記事を読む人は大体知ってると思いますが、先ほどロンドンから帰国したばかりです。

だいぶライフが減ってる状態なので、凝った内容は他の人に任せて、先の Groovy & Grails eXchange 2011 の Jeff Brown さんのセッション「Powerful Metaprogramming Techniques with Groovy」で説明があった Closure の resolveStrategy について軽くまとめます。

resolveStrategy とは

Closureクラスには owner と delegate という重要なプロパティがあります。owner はクロージャを宣言したオブジェクト、delegate はメソッド呼び出しの委譲先オブジェクトへの参照が保持されます。で、通常は delegate と owner と同じなので、特に気にする必要はないんですが、メソッド呼び出しの際に owner と delegate のどちらから先に見に行くか、どちらしか見ないかなどの戦略を resolveStrategy というプロパティに保持しているのです。

戦略の違いによる差異

では、動作の違いを見てみましょう。時間的にアレなので、ここではJeffさんのセッションデモのサンプルをそのままパクります。

    class SomeGroovyClass {
        def append(String arg) {
            println "append was called with arg: $arg"
        }

        def doit() {
            def mc = {
                append 'Hello'
                append ' London'
            }

            def sb = new StringBuffer()
            mc.delegate = sb

            mc()
            println "SB: $sb"
        }

        public static void main(args) {
            def sgc = new SomeGroovyClass()
            sgc.doit()
        }
    }

これを実行すると・・

append was called with arg: Hello
append was called with arg: London
SB:

と出力されます。

これの戦略を変えて、delegate を先に見るようにすると

    class SomeGroovyClass {
        def append(String arg) {
            println "append was called with arg: $arg"
        }

        def doit() {
            def mc = {
                append 'Hello'
                append ' London'
            }

            def sb = new StringBuffer()
            mc.delegate = sb
            mc.resolveStrategy = Closure.DELEGATE_FIRST

            mc()
            println "SB: $sb"
        }

        public static void main(args) {
            def sgc = new SomeGroovyClass()
            sgc.doit()
        }
    }

delegate で解決されました。

SB: Hello London

もっと詳しく知りたい方

『Groovyイン・アクション』の121-123ページがとても良いです。あとは Closureクラスのソースコードを読むのも良いかと思います。

え、『Groovyイン・アクション』もってない？

一時期法外な値段になっていましたが、今は良心的なお値段になっているので持っていない方はこの機会に入手されてはいかがでしょうか。

まとめ

ということで、かなりおおざっぱではありますが、resolveStrategy の説明をしました。
まぁ、こういう内容は id:uehaj さんとか id:fumokmm さんに深く解説してもらった方がいいと思うのですが、ロンドン帰国直後ということで大目に見てください。

次はその @fumokmm さんですね。

2011-02-27

２月のイベント総括

Event JGGUG

いろいろ忙しかった２月も終わりなので、今月のイベントについてちょっとふりかえり。

2/17 デブサミ2011
デブサミ2009の時に発足したJGGUGにとって３年目となったデブサミ2011ですが、今年はOpenJamという野良セッションでLTをやってきました。内容は今月創刊した「G*Magazine」の紹介。

G*Magazineを読もう

View more presentations from bikisuke

わざわざ以前の会社の友人が２人も見に来てくれたのに、やっつけ丸出しな資料でサーセンって感じでした。「G*Magazine」の記事を書くので精根尽きてしまいまして・・・という言い訳をしてもしょうがないのですけど。

結局、今年のデブサミは２時間半ぐらいしかいられなくて、セッション１つも見れませんでした。お友達のスピーカーだった皆さん、すいません。
年々参加時間が短くなってきてるので来年は未参加かも。セッションの内容もだいぶ変わってきたし、カンファレンス的なイベントにワクワクしなくなってきたので、ちょうど良い引き際なのかもしれませんな。

とか言って、来年も普通にJGGUGブースにいるかもしれませんが。

2/17 第15回 G*ワークショップ
前々から、川口さんが来日した際に講演をお願いしたいね、と言っていた企画がついに実現しました。今までのワークショップで一番人が集まったんじゃないかな？予想通りに川口さん目当てで来た人がかなり多かったと思います。

講演も素晴らしかったですし、参加された方々のツイートやブログなどを拝見すると、多くの皆さんに満足いただけたようで、スタッフ冥利に尽きますね。

こちらでもLTやりました。

Spockを使おう！

View more presentations from bikisuke

こっちはJGGUGメンバでやった「Java プログラマが知るべき9.7のこと」というパクリネタの一つで、Spockをちょろっと紹介しました。
他の人達が結構しっかり技術紹介してた中、薄っぺらい内容でサーセンって感じです。内容が薄っぺらかったせいか、LTが下手だったせいか、テストネタだったせいかはわかりませんが、あんまり響かなかったようでした。やっぱLTは笑いが取れて、かつそれなりの内容がないとダメだよね。

でも、もうLTもいいか。準備面倒だし。

来月はイベントの予定はないからコード書こう。

あと翻訳とGマガ記事とEmacsな。
やることいっぱいだ。

2010-12-31

今年のふりかえり

日記

早いもので2010年もあと数分ということで、今年のふりかえりをしておこうと思います。

仕事編

昨年はトレーニングテキスト執筆を引き受けたことが大きなネックとなり、まともに仕事ができなくなってしまい大赤字に転落したのですが、今年は一年間切れ目なく仕事をさせていただくことができました。
また、今年はコミュニティで知りあった方からの紹介であったり、友人に紹介してもらった方からお話をいただいたりと、今までとは違う流れで仕事をする機会が多くなってきたなという印象があります。

何れにしても、いろいろな方にご支援いただいたおかげで、今こうして穏やかに大晦日を過ごせているわけで、感謝の気持ちでいっぱいです。本当にありがとうございました。

コミュニティ編

昨年よりも勉強会参加率は下がったと思いますが、今年は自分が話す機会が多かったので、たくさん勉強会に参加したような気がします。勉強会バブルの今日では誰もがスピーカーをやれる状況があるとはいえ、数多くお話させていただけて嬉しく思います。が、ちょっとやりすぎた感もありますね。僕は資料を作成するのに非常に時間がかかるので、来年はちょっと抑えようかなと思ったり。

ちなみに今年のやったセッション／LTは以下の通りです。

1月	G*ワークショップ：「Groovyたん誕生秘話」
2月	仮面ライダー勉強会：「私が仮面ライダーカブトを好きな理由」
3月	Gワークショップ：「Gにおけるソフトウェアテスト・シーズン２」
5月	DevLOVE：「標準化事例」
7月	DevLOVE：「移行はつらいよ奮闘編」
	Gワークショップ：「Gにおけるソフトウェアテスト・シーズン３」
10月	JGGUG合宿：「JGGUG合宿実行委員長になるための七つの心得」
11月	G*ワークショップ：「JGGUG合宿報告」
12月	G*ワークショップ：「業務で使えるGroovy」
	DevLOVE：「やさぐれPMアンチパターン」

JGGUGとDevLOVEでほぼ占められてますw

今年印象に残った勉強会と言えば、仮面ライダー勉強会とJavaEE勉強会です。

仮面ライダー勉強会は、僕に平成仮面ライダーへの興味を与えてくれた勉強会であり、非常に得るものが多かったです。
これがなければ、狂ったようにDVDを観まくって半年で10作品を制覇したり、「平成仮面ライダー Song BEST」を買うことはなかったと思います。

もう一つは、JavaEE勉強会。
これは前々から参加したいと思いつつも、いつも勇気が出せずに見送っていた勉強会だったのですが、ありったけの勇気をふりしぼり、ついに参加させていただきました。
正直言って、ガチでもっと勉強せなあかんって思わされる勉強会って最近あまりなかったのですが、ものすごい刺激になりました。
なんだか、思いっきり頭はたかれたみたいでしたね。おかげでアドレナリンどっぱどぱになれました。
JavaEE勉強会の皆さん、ありがとうございました。
来年もよろしくお願いします。

プライベート編

なんと言っても、ウィルスによる肝機能障害で入院した事件につきますね。
入院前後も含めて約３週間ぐらいやばかったです。
幸い、仕事ではトラブルにはなりませんでしたが、もうすぐ４０にリーチなので、健康にはもっと気を使わないといけないなと思った次第です。

と、ざっとふりかえってみました。

来年は30代最後の年なので、30代の集大成となるよう頑張ろうと思います。

では皆様、よいお年を。

2010-07-28

JGGUG総会＋スペシャルG*ワークショップふりかえり

Event spock JGGUG

先日のJGGUG総会＋スペシャルG*ワークショップでspockネタでセッションやりました。

G*におけるソフトウェアテスト・シーズンIII

View more presentations from bikisuke.

なんだかんだで資料が完成したのは、id:mottsniteさんの発表最中で、相変わらずひどい学生症候群だなぁと我ながら思いました。

今回はシーズン３ということで、シーズン２であまり話すことができなかったspockをメインにJavaの開発でspockを導入する方法についてまとめてみました。

現在、自分はGroovy/Grails案件に参画していますが、日本の大規模システム開発でGroovyを採用するのは稀で、多くがJava＆Eclipseを使用しているわけです。

spockはそのような状況下において、Groovyの持つ軽快さを活かしつつ、様々なシナリオに対応したテストを書くことができるので、Java開発に携わる人にも使用してもらいたい、というかむしろJava開発で積極的に使うべきじゃないかと思っています。

「それだったらJGGUGじゃなくてJava系のコミュニティで話しろよ」ってツッコミされそうですけど。

あと、今回は懇親会方面でいろいろ動きました。結局オラクル周辺でLTができるお店を貸切予約したのですが、なかなか難しいですねぇ。

事前下見もしていたので、ある程度は予測はしていましたが、ぶっちゃけレイアウト的にLTには不向きだったなという感想ですね。料理は美味しかったと思いますけど。

まぁ参加された方々に楽しんでいただけたようなので、及第点ぐらいかな。

JGGUG運営陣はDevLOVEのようにサムゲタンをケータリングできるほど強力ではないから仕方ないですね。

とりあえず、最終的に予約人数を確保できたし、幹事的に無事に終えられて良かったです。

参加していただいた方々、ありがとうございました。