2011年6月19日日曜日

Android埼玉でJUnitのセッションをしてきました。

Android埼玉でJUnitについてセッションの時間を設けていただいたので、私見ながらJUnitの紹介をしてきました。

まず、その前に、Android埼玉、オレ遅刻してきましたorz
ひどいですね。発表者なのに…
進藤さんご迷惑をおかけいたしました。

埼玉Androidの会の方は藤原さん(@zegenvs)さんが主催するﾓｸﾓｸ会をメインに参加していて、定例会の方は実は二回目でした。
というのも、埼玉Androidの定例会はたいていテスト部MTGとかぶることが多くて、テスト部メインなオレは泣く泣く埼玉Androidに参加できなかったのです。(半分ウソつきました。)

以下、今回セッションの時間をいただけた経緯です。

社内用にJUnitの資料をGoogle Docsで作成
特に秘匿にする必要性を感じなかったので、Twitterでアドレス付きでつぶやいた
埼玉支部長の進藤さんから埼玉Androidの会でぜひと…

という感じですね。
30分時間をいただけるなんて光栄です。
ありがとうございます。

あと、資料の誤りを指摘してくださった、千葉Androidの会(#chibandroid)のnouzui2007さんありがとうございます。

で、他の方の発表ですが、一人未完の資料をどう持っていくか作戦を練っていて
ﾓｸﾓｸしていやがったので、左耳から入って右耳から出て行っててあまり覚えていません。
あいかわらず失礼なやつだ、オレ。

一応、記憶に残っているプレゼンで以下の二つがあります。

めーめー会
@chocokanpanさんが2～3ヶ月に一度開催する、ジンギスカンを食べる会のLTです。
実は埼玉Androidの会でLTするのが実は二回目で、その初回が第二回埼玉Androidの会だったそうです。
で、それの何が印象に残っているかというと、オレの勉強会デビューがまさにその第二回埼玉Androidの会だったわけです。
そして、埼玉Androidの会のセッションデビュー日とめーめー会の二回目のLTが重なるあたり、奇遇だな～と感心していた次第であります。

スマフォビジネスの事情
Androidアプリ開発者の皆様ならご存知のアプリ紹介サイト[アンドロイダー]を運営するトリワークスさんによるスマートフォンのビジネスモデルのおはなしです。

Androidアプリでビジネスを展開するための非常に有益な情報が提供されたと思います(スルーっと解説)。
で、実はトリワークスさんも埼玉Androidの会で講演するのは二回目でして、その初回はなんと、第二回埼玉Androidの会。これまた偶然ですね。トリワークスさんも@chocokanpanさんに「奇遇ですね」とおっしゃっていました。

そいで、私のプレゼンですが、
いつものTwitter口調でずっとやっていました。
そして、人生初のライブコーディングしましたが、あれは、練習が必要ですね。
内容はすでに頭の中にあるんですけど、手が追いつかないのと、クビが痛いのと、焦るのとで、、、いい経験させてもらいました。
資料はこんな感じです。

オレとしては珍しく、懇親会に参加しました。
土曜日サイコー！

主だった話は埼玉Androidの会でロゴマークを作るということで、
おざわ(@osa030)さんのロゴの話題になりました。

おざわさん曰く、

タマといえば「○んたま」でしょ！

かなり大爆笑でした。

愉快な方達がいる埼玉Androidの会、とても楽しかったです。
埼玉Androidの皆様、今後とも宜しくです。

2011年6月18日土曜日

第16回 G*ワークショップ＋JGGUG総会に行ってきました。

第16回 G*ワークショップ＋JGGUG総会に行ってきました。

まあ、内容についてはTogetterにまとめられているので、こちらを参照ください。@kimukou_26さんグッジョブです。

以下、所感つーか、簡単な内容紹介。

2010年度JGGUG総会

Japan Grails / Groovy User Groupの活動の報告です。
内容をざっくばらんに言うと、「JGGUGは2010年、頑張ったよ」とのことです。

「レッツゴーデベロッパー2011」レポート
@bikisukeさんによる、仙台でおこなわれたイベントの報告です。
5セッション中、2セッションがGroovyという盛況ぶりだそうです。(Groovyから見て)

なかでも「モデルを書いてください」というお題が出されたそうです。これに会場の皆さん真剣に考えたようで、会場全体で各テーブル(2人で1テーブル)で山ができている(二人が向い合っていろいろ考えている)様子は壮観でした。関東、というか東京~~のtoo shy boy達~~ではとてもお目にかかれない光景ですね。

今日からはじめるGPars
@fumokmmさんによる、GParsの紹介。

GParsは簡単に言うと、Groovyの並列処理ライブラリーです。

並列処理ですので、単純なシングルスレッドよりもCPUを効率よく割り当てられます。
Map/Fork/Reduceなどの処理もできます。
Actorを使うと他のスレッドにメッセージを送ることもできます。

というわけで、Hadoopなどの並列処理プログラミングを検討していて、サンプルでプログラムを書きたい時に非常に便利な感じがしました(正確に言うとHadoopのMap/Reduceとは異なりますが…)。現在(2011/06/18)のバージョンは0.12です。なお、Groovy1.8には0.11がバンドルされているとのことですので、ぜひともそのパワーを体感してみてください。というか、オレがまず体感したい！

ちなみに@fumokmmさんはプログラマーですか？いいえ、猫です。

(2011/06/18 9:12追記)テストの分散実行をGParsでやるとか、サーバーの負荷試験とかそういった用途にも気軽に使えそうですね。

Groovy 1.8の新機能～ま、まさか、今までのGroovyが予告だったとでも言うのか…～
@uehajさんによる、Groovy1.8の新機能の紹介です。

参加者の殆どがすでに1.8を触っているという、すごい状況の中でさらにコアな解説をしていただきました。

…

Groovy始めたときには既に1.8が出ていたオレには何がどう違うかよくわかりませんでした…orz
なお、現在はGroovy1.9の開発も始まっているらしく、Java7の機能が取り込まれるそうです。
オレの勝手な憶測で、秋くらいには1.9出るのではと思っています。

そういえば、時間の都合上かなり詳細な情報は省かれていました。それらについては、『プログラミング Groovy』を買ってくださいということだそうですって、おいこら、これ宣伝じゃねーか…orz

Java SE 7 Launch イベント全国キャラバン開催
寺田さんによるJava SE 7 Launch イベント全国キャラバンの宣伝です。

2011/7/28にJava SE 7がリリースされます。そのLaunchイベントで寺田さんが全国各地で行脚するそうです。
(↑2011/06/18 12:06訂正しました。関係者の皆様ごめんなさい)

早速会社で登録しましたが、登録完了のメールがhtmlメールなのにプレインテキストとして届いていて、読めない…orz

第二部LT大会
LTの時間です。

1: ksky 2: なひ 3: 速水康晴 4: kyon_mm 5: tyama 6: mkawa 7: 杉浦孝博 8: jack 9: nobeans
の順番で行われました。

kiy0takaさん GroovyConsoleの拡張をした→失敗した
なひさん ~~JRuvy~~JRubyの紹介とJRuby会議の宣伝
速水さん : 覚えてない←失礼だろ
きょんさんうさみみ付けて一言、「GroovyはprivateにアクセスできるJavaです」
tyamaさん : Grails1.4-M1の話 = 真剣に使うのはやめましょう。あとで安定版が出るとがっかりするので。ちなみにオレはM1使っているorz
mkawaさん : MCViewのお話
杉浦さん : 『もしトラ』の話(『もしも女子高生がバートランド・メイヤーの『契約プログラミング』を読んだら』)
jackさん : 一句「Groovy Javaにほんのり薄化粧」
nobeansさん : 「とりあえず、猫出しときゃよろこぶ」。釣れた人はこちら

という感じでした。
コーラが切れかかっていたので、コーラ非常に助かりました。

勉強会といえば、普段はTwitterなどでしかお話をしない人との対話ですが、今日もいろいろな方とお会いいたしました。
メインセッションでGParsのお話をされた猫のふもさんと、『達人プログラマーを目指して』の@ryoasai74さん、下の名前が同じだった@absj31さん、これまた猫のtyuki39さん。

みなさん見識もあり、技術もあり、人格者であり、素晴らしいですね。
私などは口だけのSE(すべてExcel)なので、もっともっと勉強しなければいけないなと思いました。

それと、

Groovy ネコのアイコン多いぃぞ

猫だらけ、ネコまっしぐら…Groovy道

2011年6月16日木曜日

Groovyでenumで遊んでみる。

Groovyでenumで遊んでみた。

まずは簡単なコードから。



enum Fruit{
    APPLE, ORANGE, BANANA, MANGO
}
Fruite.each(){
    println it
}

これの出力結果は次のとおりです。



APPLE
ORANGE
BANANA
MANGO

つぎは、『Effective Java』の項目30「int定数の代わりにenumを使用する」から写経してみました。



enum Planet{
    MERCURY(3.302e+23, 2.439e6),
    VENUS  (4.869e+24, 6.052e6),
    EARTH  (5.975e+24, 6.378e6),
    MARS   (6.419e+23, 3.393e6),
    JUPITER(1.899e+27, 7.149e7),
    SATURN (5.685e+26, 6.027e7),
    URANUS (8.683e+25, 2.556e7),
    NEPTUNE(1.024e+26, 2.477e7);
    
    private final double mass;   // kg
    private final double radius; // metre
    private final double surfaceGravity; // m / s*s
    // Gravitational Constant
    private static final double G = 6.67300E-11
    
    // Constructor
    Planet(double mass, double radius){
        this.mass = mass
        this.radius = radius
        surfaceGravity = G * mass / (radius * radius)
    }
    
    public double surfaceWeight(double mass){
        mass * surfaceGravity
    }
}

Planet.each(){
    println "${it.toString()}"
    println "mass -> ${it.mass}"
    println "radius -> ${it.radius}"
    println "surfaceGrabity -> ${it.surfaceGravity}"
    print "surfaceWeight -> "
    println "${it.surfaceWeight(20.0 / Planet.EARTH.surfaceGravity)}"
    println ""
}

println 20.0 / Planet.EARTH.surfaceGravity

私、これ書いていて気付いたんですけど、enumってコンストラクター持てるんですね。

実行結果は以下のとおりです。



MERCURY
mass -> 3.302E23
radius -> 2439000.0
surfaceGrabity -> 0.0
surfaceWeight -> NaN

VENUS
mass -> 4.869E24
radius -> 6052000.0
surfaceGrabity -> 0.0
surfaceWeight -> NaN

EARTH
mass -> 5.975E24
radius -> 6378000.0
surfaceGrabity -> 0.0
surfaceWeight -> NaN

MARS
mass -> 6.419E23
radius -> 3393000.0
surfaceGrabity -> 0.0
surfaceWeight -> NaN

JUPITER
mass -> 1.899E27
radius -> 7.149E7
surfaceGrabity -> 0.0
surfaceWeight -> NaN

SATURN
mass -> 5.685E26
radius -> 6.027E7
surfaceGrabity -> 0.0
surfaceWeight -> NaN

URANUS
mass -> 8.683E25
radius -> 2.556E7
surfaceGrabity -> 0.0
surfaceWeight -> NaN

NEPTUNE
mass -> 1.0239999999999999E26
radius -> 2.477E7
surfaceGrabity -> 0.0
surfaceWeight -> NaN

Infinity

どうも、surfaceWeightの値がNaNになるので、調べてみたら、20 / Planet.EARTH.surfaceGravityが無限だったようで、そりゃNaNになるわな。

2011年6月13日月曜日

97 things Every Project Manager Should Know を読んでみた(3)

A Word Can Make You Miss Your Deadline

たかが言葉、されど言葉

第三回目です。
いつもどおり、ゆる～く翻訳、意訳します。逐語訳ではないです。

プロジェクトのマネージメントについて。
これを読むと日本のプロジェクトマネージメントと
考え方が若干違うなと思いました。

だからアメリカ発祥のPMPだやらの考えを
日本に適用しても無理だと思う気がしました。

では、以下本文

WHICH WORD CAN MAKE YOU MISS YOUR DEADLINE? The answer is "any word." When you are developing a product that will be released in languages other than English, you are adding numerous new risks and constraints to your project.

どの言葉が締切りを破らせてしまうのか？答えは、「どの言葉で」もそうなる。英語以外の言葉でもリリースされる予定のあるプロダクトを開発している場合、そのプロジェクトには多くの未知のリスクや制約がかかっている。

Some are technical and obvious. For example, if your product will be released in Japanese, it has to support the appropriate fonts. If it doesn't, the Japanese version won't work, even if the English one works perfectly. But font compatibility is not under your control. You and your team need to be aware of translation quirks and consider them before coding. Make sure that the development practices follow international standards that will eliminate such issues.

いくつかの問題は技術的なものだし、明らかなものであったりする。たとえば、今制作しているソフトウェアが日本でも発売されることとしよう。その場合、ソフトウェアは適切なフォントを扱えなければならない。もしそれができなければ、日本版は動くことはないでしょう。たとえ、英語版がどんなにすばらしくても。しかしフォントの互換性はコントロール可能な課題ではない。このような翻訳にまつわる問題は事前に考慮して開発する必要がある。つまり、国際的な標準に則ることがこのような問題を解決するのである。

However, the mere need for alternate language versions also constrains what decisions you can make and when. Typically, localization (Japanese, Swedish, German, etc.) happens in parallel with English development, with a certain lag. It can be a few days, weeks, or even months. However, at some point the translation of the foreign version has to "catch up" with the English version.

しかし、他の言語版を作成するという単純な要求がいつ何を決定するのかという問題に制約を課しているものなのである。よくあることだが、国際化(日本語化、スウェーデン語化、ドイツ語化など)は英語版の開発とほぼ同時に、いくらかの時間差の後に発生しているものなのである。その時間差は数日、数週間、ひと月などになるかもしれない。しかし、あるタイミングで他言語版は英語版と同等になるときが来るのである。

You need to make sure during testing and reviews that:
- What is in the English version can be properly translated
- What is translated truly corresponds to the English version
- The translated product works flawlessly
Here's the catch. These three things may be tested after the English version is finished and signed off on. During the testing and reviewing of a localized version, you will always find at least one challenging issue that can't be solved except through a change to the English product.

以下に示すことだけははっきり確認しておいて欲しい。テスト中や、レビュー中のうちに。
- 英語版のうち何が正しく翻訳されうるのか
- 翻訳されたものは英語版と同じ意味をもっているか
- 翻訳された製品は確実に動作するか
どうだろう。ここに挙げられた事柄は英語版が完成して出荷された後にもテストをしなければならない。各言語版対応へのテストおよびレビューの最中に、たいてい英語版にも改修が必要になるような問題を発見してしまうものなのだ。

簡単なActivityInstrumentationTestCase2の書き方

Androidのプログラムの作成方法については、いろいろなサイトで有用な情報が得られます。
しかし、テストとなるとあまり情報が多くありません。

というわけで、
簡単なActivityInstrumentationTestCase2<T extends Activity>の書き方を
記事にしました。

今回のテスト対象のアプリケーションはこんな感じです。

概要

EditView、ButtonとTextViewで構成されている。
EditViewに文字を入力して、Buttonを押すと、TextViewに「Hello, + [EditViewの文字]」が表示される。

まあ、百聞は一見にしかずなので、画面イメージ出しましょう。

これが最初の画面です。

そして、これに文字を入れて、ボタンを押すとこうなります。

では、早速テストを書きましょう。
まずは、コンストラクターとsetUp()から。



class HelloAndroidTest
        extends ActivityInstrumentationTestCase2<HelloActivity>{

    private Activity activity;

    private Instrumentation instrumentation;

    public HelloAndroidTest(){
        super(HelloActivity.class);
    }

    @Override
    public void setUp() throws Exception {
        super.setUp();
        activity = getActivity();
        instrumentaion = getInstrumentation();
        setActivityInitialTouchMode(false);
    }        
}

まず、ここのポイントは

コンストラクター
setUp()中にあるActivityInstrumentationTestCase2#getActivity()
同様にsetUp()中にあるActivityInstrumentationTestCase2#getInstrumentation()

ですね。

コンストラクターではテスト対象のアクティビティ・クラスをActivityInstrumentationTestCase2に渡してやります。「総称型(ジェネリクス)でクラスを指定しているんだから、なんでわざわざクラスを通知してやる必要があるの？」という声も聞こえそうですね。すこしだけ解説すると、タイプパラメーター<T>というのは、ただただタイプとして機能するだけで、java.lang.Class<?>オブジェクトのような機能や、役割を一切持ちません。

したがって、



        Class clz = T.class;

とか、



        boolean isInstance = object instanceof T;

とか、



        T object = T.newInstance();

などはすべてコンパイルエラーになります。

これよりも詳しい説明は私が説明するよりも他にもっと優れた解説があります。Java総称型メモなどを参考にしてください。

話を元に戻すと、ActivityInstrumentationTestCase2で、テスト対象のアクティビティを起動するために、そのクラスの情報が必要なわけですね。さて、これジェネリクスで指定したクラスと異なるクラスを渡したらどうなるのか？わかりませんねぇ。あとでやってみましょう。まぁ、予想できる結果として、この後の解説で述べる#getActivity()でjava.lang.ClassCastExceptionが発生するように思います。

setUp()中にあるActivityInstrumentationTestCase2#getActivity()はActivityを起動して、参照を返すメソッドです。これにより、テストコードはテスト対象のアクティビティをそのコンテクスト上で起動することが可能になります。テストはそれ自体でひとつのアプリケーションですが、テストアプリケーションとは別のスレッド上にテスト対象のアプリケーションが起動するのです。これをsetUp()に置くことで、毎回のテストがアクティビティを起動した状態で実行できます。

最後に、setUp()中にあるActivityInstrumentationTestCase2#getInstrumentation()です。このInstrumentationは、アクティビティの起動とは何の関係もありませんが、アクティビティのUIスレッドと同期をとるような場合や、UIに対して操作を行う場合に必要になるオブジェクトです。今回のテストアプリケーションでも使いますので、最初にその参照を取得しておきます。

では、テストコードをどうぞ。



    public void testPressButton() {
        // EditText にフォーカスを当てる ---- (1)
        EditText editText = (EditText)activity.findViewById(
                orz.mikeneck.hello.R.id.edit_text);
        activity.runOnUiThread(new Runnable() {
            @Override
            public void run() {
                editText.requestFocus();
            }
        });
        // UIとの同期をはかる ---- (2)
        instrumentation.waitForIdleSync();
        // UIにキーを送る ---- (3)
        sendKeys(KEYCODE_SHIFT_LEFT);
        sendKeys(KEYCODE_A);
        sendKeys(KEYCODE_N);
        sendKeys(KEYCODE_D);
        sendKeys(KEYCODE_R);
        sendKeys(KEYCODE_O);
        sendKeys(KEYCODE_I);
        sendKeys(KEYCODE_D);
        // 前提条件の確認 ---- (4)
        assertEquals("Android", editText.getText().toString());
        // Button をクリックする ---- (5)
        Button button = (Button)activity.findViewById(
                orz.mikeneck.hello.R.id.button);
        activity.runOnUiThread(new Runnable() {
            @Override
            public void run() {
                button.performClick();
            }
        });
        // UIとの同期をはかる ---- (6)
        mInstrumentaion.waitForIdleSync();
        // TextView の値をテストする ---- (7)
        TextView textView = (TextView)findViewById(
                orz.mikeneck.hello.R.id.edit_text);
        assertEquals("Hello,Android", textView.getText());
    }

大雑把な解説ですが、

EditTextにフォーカスを当てます。これはUI上の操作に当たるので、Activity#runOnUiThread(java.lang.Runnable)を使用します。
UIとの同期をはかります。別スレッド(アクティビティ)との同期はInstrumentationwaitForIdleSync()を用います。
UIにキーを送ります。android.view.KeyEventをstatic importしておいてください。
EditTextにキーを送ったので、それが反映されていることをテストします。想定される値は「Android」です。
Buttonをクリックします。これはUI上の操作に当たるので、Activity#runOnUiThread(java.lang.Runnable)を使用します。
UIとの同期をはかります。別スレッド(アクティビティ)との同期はInstrumentationwaitForIdleSync()を用います。
Buttonをクリックしたので、仕様通りにTextViewのテキストが変更されているかテストします。想定される値は「Hello,Android」です。

となります。

ポイントは

UI上の操作は必ずActivity#runOnUiThread(java.lang.Runnable)を使用する。
UI操作後はInstrumentationwaitForIdleSync()を用いる。

です。

#runOnUiThread(java.lang.Runnable)を使わないとUIが操作できないのは、他のアプリケーションからいくらでも値を変更するなどの改変が行われてしまうからというセキュリティ的な側面があるのかと思われます。(Javaそんなに詳しいわけではないので、そのあたりを突っ込んでくれる人、大募集)

二番目のInstrumentationwaitForIdleSync()がActivityInstrumentationTestCase2の真骨頂です。UIスレッドとの同期をはかりスムーズにテストを実行出来るようなオブジェクト類が提供されており、それがActivityInstrumentationTestCase2です。別スレッドのUIと同期するこの能力はテストの実行においてかなり強力な機能です。

こんな感じで、非常に簡単なテストでしたが、みなさまもUI上で不具合を発見したら、なるべくテストコードを書いて、それらを再現できるようにしてみてください。きっと、素晴らしいUIをもつアプリケーションが作成できると思います。

2011年6月9日木曜日

会社でJUnit勉強会をやってみたよ

会社でJUnit勉強会なるものを開いてみました。

JUnit勉強会と言っても、なんか高度なことをやる意図は持ってなく、単純にJUnitの使い方、実際のプログラムへの適用、TDDのやり方の紹介みたいな感じでやってみました。

資料はここを参照。

で、結果ですが、

かなり失敗だった

と思います。

原因

JUnitの動作を図解したほうが分かりやすかったと思われる。
最初のテストをHello Worldにしたのがまずった。
さらにボウリングスコアの計算というTDD定番のネタで研修したあたりがまずった。

1.については対象者がJavaを始めて1ヶ月というAさんと、入社3年目でJava経験2年のBさんであり、まだ、Javaのmainメソッドからの起動を追いかけるというレベルでのsetUpなどの動きを伝えるには、やや高度であったあたりが、厳しかったという感じです。

2.についても同様で、Aさんはもちろんですが、レガシープロジェクトで育ったBさんにも、インターフェースを使ったプログラムの記述を説明するのはなかなか厳しかった。(もちろんこれは覚えてもらわないといけないと思っていますが…)

3.についてはTDDの考え方、というか動き方、これを説明しておかなければならなかったというのがあります。

とはいっても、みなさんテストコードの重要性は理解していただいているので、(毎日オレがうるさくテストコード、テストコードと言っているうちに、テストコードマンセイになった)徐々に実力を向上させていきたいと思う次第であります。

それと同時にIntefaceを介在させることの説明について、
まだまだ自分がうまく説明出来ていないというのを
発見できたので、今後自分ももっと噛み砕いて説明できるようになりたいと思う次第であります。

というわけで、明日はより高度なAndroidのActivityInstrumentationTestCase2<? extends Activity>の
勉強会をやりたいと思います。

つ～か、ActivityInstrumentationTestCase2<? extends Activity>はジェネリクスを使っているあたりで、説明が頓挫しそうな予感がする。

さらに、JUnit勉強会資料を公開した瞬間に@ryu_compin(日本Androidの会埼玉支部、支部長)さんから、埼玉Androidの会でセッションやってというオファーが来ました。30～40分枠をいただけるということで、なんとも光栄の至りでございます。

ん～、でも皆さん、あくまで単なるJUnitでございますよ…

2011年6月7日火曜日

第2回テスト駆動開発入門読書会（ペアプロ写経大会）に参加してきたよ

第2回テスト駆動開発入門読書会（ペアプロ写経大会）に参加してきました。

会場は早稲田大学で、実は人生初早稲田。
会場についたのは30分前でしたが、
まだ誰もいませんでした…orz

さて、開始からですが、
微妙に手際が悪くて10分遅れでスタート。

席の配置を円形に直して、
適当に座ったとなりの人とペアを組むという感じでスタートでした。

オレとペアを組んだのは組込み系に勤める今年一年目の社員の方で、
ノパソに入っていたEclipseが完全にまっさらで、
とてもビックリしました。
(よくある…)

なんか真新しいEclipseにこれから~~汚いコードを~~ゴリゴリコードを書いていって
いいのか、やや戸惑いつつも、まあいずれ書くんだから
新鮮なテストが書かれていればいいじゃんという感じでやり始めました。

やったのは

ペアプロ
TDD本を一章から写経する
Kent Beckの本の内容を読みつつ、半分納得する。(三角測量はオレが簡単に説明)
2～3章ごとに交代する

という感じです。

オレが最初にナビゲーターになりましたが、
とりあえず、操作がおぼつかないので、
「Ctrl + N」とか言いながら(ゴメンね~~…とはあまり思っていない~~)、
ショートカットを覚えてもらいました。

でも、やはりペアの方は若いので、
ショートカットをどんどん覚えるし、
少し羨ましい感じがしました。
(オレのように老いると、物覚えが悪くなって頑固になるのよ…)

2章を終わったあたりで、
ドライバーとナビゲーターを交代しました。

いつものボッチのような感じで、
ブツブツつぶやきながらコードを書きました。
なるべくナビゲーターに身を委ねつつ。

で、Dollar#equals(java.lang.Object)メソッドの
オーバーライドで、
どうしても気になって仕方がないので、nullのパターンを実装してしまいましたが、
これは本質出来ではありませんね。
ToDoリストに記載しておいて、
TDDではないテストコードを記述するときに、別途実装するべきでした。

この辺はナビゲーターの方にToDoに記録してもらいたいのですが、
ナビゲーターの真に難しいとろこは、
二人してコーディングにのめり込んでしまうあたりですね。

この点については、残り20分程度の感想戦で、
議論させていただきました。

頂いたアドバイスとしては、

ToDoに記録しておくかどうかはともかく、ポイントはドライバーとナビゲーターが対話をすることである
ナビゲーターが距離を少し置くためにポスト・イットを活用する

などがありました。

ぜひ、今後試させていただきたいと思います。

あと、気になった議論として、SIerの現場に同普及するべきかというのがありました。

たしかにSIのプロジェクトの現場ではペアプロする = 二人の稼働でひとり分の成果しかでない
と考えてしまうので、正直のところ導入には非常に慎重的な態度になります。

とは言うものの、SIerの現場にてよく見る光景で、

御前レビュー会議 : えらい人だけが発言・指摘するだけの5～6人による1.5h程度のレビュー - 約7.5hの稼働の無駄
デバッグ、皆で考え込む症候群 : なんかうまく動かないが、どこが動かないかわからない(特に新人などが引き起こす)ので、なぜか2～4人が集まってきて2～3時間くらいあ～だこ～だ議論して、なんかよくわからないけど動いて、「あ～よかった」とか言って終りにしてしまうやつ - やっぱり7.5hの稼働の無駄

こう言うのがあるわけで、
意外と無駄に時間を過ごしているパターンは多いわけです。

だったら、無駄な7.5hを二回に分けてペアプロをするだけで、より進むと考えれば、
御前レビューとか、謎の動かない症候群よりも効果はあるように思います。

ま、現場の~~エロイ~~エライプロマネの方々は、
こんなことを言っても(ﾟДﾟ)ﾊｧ?って顔しますがね。

次回は再来週あたりを想定しているとのことです。
ので、今回参加されなかった皆さんも参加してみてはいかがでしょう。

全然読書会の雰囲気が表現できていませんが、
全体的にはまったりしていましたよ。

登録: 投稿 (Atom)