æ ªå¼ä¼šç¤¾ã‚¨ã‚¹ãƒ—ãƒ©ãƒ‹ãƒ³ã‚°ã‚’é€€è·ã—ã¾ã—ãŸ

7月31日付で2年半ほど在籍した株式会社エスプラニングを退職しました。退職系のエントリーはブクマが稼げると聞いて、状況報告を書こうかなと思います。

前職でやっていたこと

前職は主にJavaによるアプリケーション開発が主業務でしたが、珍しくWeb系というわけでもありません。入社した頃は、Swingでのデスクトップアプリケーションが主プロダクトでした。最近はWebアプリケーションやスマフォ系もやっています。そんな会社で自分が行ってきたことは、開発環境の整備、コード品質の向上、プロジェクト全体の進め方の改善などです。
具体的には、ユニットテスト、読みやすいコード、リファクタリング、レビュー、KPT、カンバン、Trac/Redmine、バージョン管理、継続的インテグレーション、ユースケース駆動開発などなどです。
ぶっちゃけ言えば、入社した当時はお世辞にも技術レベルは高いと言えませんでした。バージョン管理はCVSでしたし、Excelの課題管理表や意味の無いチェックシートなどを、お客さんに言われるまま使っていた、どこにでもあるような開発現場です。
ですが、2年半ほど経過し、ユニットテストやCIが自然にある開発環境にまでなっています。少なくとも札幌のような地方都市で、そのような開発環境が整備されている会社は少ないと思います（もし、そんな開発環境で仕事したいのであればコンタクトしてみてください）。

なぜ、新しい手法を導入したいのか？

新しい手法は、当然のように古い手法の問題点を解決するために生まれました。なので、新しい事を導入していくと効率よく品質も高くなっていきます。
というのは建前で、新しい手法を導入していく方が楽しいからです。
ずっと同じやり方をやっていく保守的な環境は刺激がありません。新しい事を試せば失敗もします。失敗から学ぶことも多いですし、それを乗り越えれば効率もよくなります。学ぶことは大変ですし、新しい事を学ぶのはプライベートの時間を使います。それを職場で導入します。問題があれば自宅で対策を練ることもあります。
でも、それが楽しい。

新しい手法を導入したことによる良い点

何はともあれ、自分が楽しいです。好きなエンジニアリングを仕事にする以上、楽しめなくなったら業界から身を引きたいと考えています。仕事を続けるモチベーション、それが一番です。
次に良い点として、社員間などで沢山の技術的な話ができます。ああでもないこうでもないと議論して、一緒に解決するってチームによる開発の醍醐味です。時には意見がぶつかります。それでも、保守的に事なかれ主義でいるよりずっと楽しいです。そして、気がつけば仲間も新しい事を見つけてきます。そうなれば自分も成長できます。
勿論、最新の手法を駆使しているので、品質や生産性もよくなります。TDDまでは完全に導入していませんでしたが、ユニットテストを根ざした影響で、各自で作るクラスやメソッドの意味を考えるようになりました。後で困らないように相談するシーンも増えました。CIで常にビルドとテストが走るようになったため、緊急リリースにも落ち着いて対応できるようになりました。ユースケースの導入により、無駄な機能を省くことやテストケースの抽出もスムーズになりました。必要な事を一通りできるようになったため、作業見積もりの精度も高くなりました。

新しい手法を導入したことによる悪い点

ところが、新しい手法を導入していくと、悪い意味でも化学反応が起きるわけです。基本的に「なんで変えるの？今までのやり方でいいじゃん」との戦いです。
保守派としては、新しい事を覚えるモチベーションはありません。それは無駄な努力ですから。努力せずに今の状況が続けられるならばそれで良いのです（勿論、保守的なことが重要なドメインもあります）。
この解決方法はひとつだけあります。改革派多数にしてしまえば良いのです。６人チームであれば、改革派が２人いれば充分です。保守派の中には完璧な保守派の他に、多数派が多く居ます。影響力の強い方につく人を含めて６人中４人になってしまえば、純粋な保守派も押さえ込めます。そして、そんな保守派もやってみたくないだけで、やってみれば意外と楽しんでくれます。食わず嫌いみたいなもんですね。まあ、中にはどうにもならない人もいると思いますが・・・。

やれることは、だいたい終わった

それほど大きな会社でもありません。入社して２年もすると、開発環境周りのアップデートもほとんど終わりました。最近では、Mercurial + Jenkins + Redmine の環境も整っていましたし、最後のプロジェクトではCucumeber + Seleniumでのテストの自動化も試しました。まったく改善点がないわけでもありませんが、やりたいことはだいたいやったかなという所です。去年は、勢いに任せて、プライベートでJUnit実践入門も執筆しました。
JUnit実践入門の執筆後あたりからでしょうか、やりたいことはだいたい終わったと感じはじめます。

キッカケは突然、でも必然

色々な経緯で転職して２年ほど過ぎました。新しいことをどんどんと導入してカンフル剤になるような役割もだいたい終わったかなと感じ、新しい事を探し始めます。MongoDBなどに興味持ったり、ユニットテストから受入テストの自動化をもっと調べたり、どうしても今のスキルの延長で考える事が多かったかと思います。
そんな中で、執筆の前後から東京に行く機会もあり、JavaOne Tokyoの懇親会で都元ダイスケさんと出会いました（ネットでは知っていたけどリアルという意味で）。その後、Facebookなどとかで絡んでいたのですが、ふとしたキッカケで、氏が転職したばかりのクラスメソッド株式会社へ電撃転職するような流れになりました（そのあたりの経緯は後日）。
本当に偶然と勢いだったのですが、ここ２年半を振り返ると、それなりに意味のあるステップを踏んできたからこそ、この機会に巡り会えたと感じます。もし、和田さんに会ってなかったら、もし、TDDBCを主催しなかったら、もし、ユニットテストをもっと勉強しなかったら、もし、前職に新しい技術を導入しなかったら、もし、その導入が失敗していたなら、もし、JUnit実践入門を執筆していなかったら・・・と。

新しいことにチャレンジしたい

次職では主にAWSを扱うエンジニアとなります。
Google App Engineは少し触っていましたが、AWSはVPS程度にいじったことがある程度です。基本的にまったく未知の領域です。勿論、基本的なLinuxコマンドは使えますが、JavaのWebアプリ開発で環境構築をするとかそんなレベルです。しばらくは学び、役に立つレベルのスキルを習得することに注力するでしょう。
その方がぬくぬくとしているよりも刺激があって楽しいということで、レベル０から再出発です。ツライと思います。
失敗するかもしれません。それはひとつの経験として受け止めます。その時は、どこか拾ってください（笑）

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

追記

東京に引っ越すの？という話ですが、当面は在宅を予定しているため、札幌在住は変わりません。むしろ、札幌に(ry

追記2

転職エントリーは転職先会社ブログでご覧ください。

ニセコ開発キャンプまとめ

Twitterやら地元やらで集まった開発系のメンツを集め、ニセコで遊んできました。
最初は4泊くらいしようという話だったんですが、予定を合わせたりどうこうしているうちに2泊3日に。当初はノートPCを開いてゴソゴソもやる予定でしたが、最終的にすべてリア充系の遊びをすることになりました。
最終的な参加者は以下の通り。

• @shuji_w6e
• @irasally
• @fel97048
• @gishi_yama
• @tmaeda1981jp
• ï¼ megascus
• @irof
• @grimrose
• @Posaune

上5名が道内の人、下4名が道外の人。

0日目

＠megascusが木曜日に札幌入していたので、パークゴルフとフッズでレンタルMTBでちょろっと遊び、スープカレーを食す。

1日目

午前中に道外組（@irof @grimrose @Posaune）が新千歳に到着し、自分と@gishi_yamaの車に分乗して余市へ。目的地は柿崎商店。

さらにカニを購入したので水曜日あたりに着弾予定。

その後は余市のニッカウヰスキー工場の見学試飲。

自分と@gishi_yamaはドライバーなので飲めず・・・。悔しいのでアップルワインとウイスキーの原酒を購入。

4時頃にニセコ（正確には倶知安だけど）に移動したら、クロスバイクをレンタルしてサイクリング。だいたい20kmほどのアップダウンを走る。

なお、＠megascusが暴走し、行方不明になるイベントが発生。・・・曲がるポイント教えたよね・・・、他の人は全員まがったよorz

7時くらいからバーベキュー。肉を食う。

よほど疲れたのか喰いまくって酒はあまり減らなかった。

11時就寝。

2日目

自分だけは4時半に起床し、5時から朝練。ニセコのヒルクライムコースを走り、さらにパノラマラインを周回し、55kmほどをロードバイクで疾走。


絶景カナ

宿に戻り、9時半からNACのMTBに参加。京極あたりの山奥までハイエースで移動し、そこから軽い山道を走る感じ。ここで、@tmaeda1981jp合流。


羊蹄山カッコイイ。草原の中を走ったりダート走ったり楽しかった。

昼はハンバーガー。ここで@irasally、@fel97048合流。

結構なボリュームで良い塩加減。芋も旨い。

ここで@gishi_yamaは離脱し、午後はラフティング。ゴムボートに５−８人くらいで乗り込んで川下り。

これはもの凄く面白い。端から見たら単に流されているだけであまり楽しそうに見えないけど、自分から落ちて楽しんでみたり、他のボートに水をかけたり、岩にぶつかってみたりと。
ちなみにMTBでもラフティングでもインストラクターが、オリバーって外人だった。悪ノリ大好きのテンションMAXで面白すぎたｗ

と、丸1日遊んで、夜は再びバーベキュー。2日目は肉控えめ、酒多め。
ホタテが旨い！

3日目

@tmaeda1981jpと自分は朝練。それぞれ別のコースで30km/20kmほどをロードバイクで走った。1日目に比べるとあまり天気良くなかった。

7時くらいから移動を開始し、五色温泉へ。そこからニセコアンヌプリへトレッキング。1時間40分ほど登って、山頂。

雲海の中の羊蹄山。

すばら！
1時間20分くらいで下山したらば、温泉へ・・・。疲れを癒やす。

ランチはコロッケと思っていたが、混雑していて食べられず…。いくつか店を回ったけど、どこも混雑。ちょっと想定外。最終的に回転寿司に寄ってランチ。結構アタリだったので結果オーライ。

14時頃に倶知安に道外組を送り、道内組はそれぞれ帰路に着き、全行程を完了。

まとめ

開発者の体力を開発するキャンプでした。また来年やろうと思います。

『JUnit実践入門』正誤表(6) #junitbook

誤植速報その6です。
その1からその5までは初刷のみの誤植で2刷では修正済みです。
その1（2刷反映済）,その2（2刷反映済）,その3（2刷反映済）, その4（2刷反映済）, その5（2刷反映済）, 技評さんの公式サイトです（おって反映されます）。

P362 テストケースのリスト５番目（最後）

誤）

Itemが1つ追加されている状態で、addで同じItemオブジェクトを追加するとgetNumで1が取得できる

正）

Itemが1つ追加されている状態で、addで異なるItemオブジェクトを追加するとgetNumで1が取得できる

リスト18.10のテストコード（最後のテストケース）に対応するテストケースです。テストコードに誤植はありません。

P19.9 複数行テキストのアサーション

テストコード中の期待値に誤りがあります。
誤）

public class MultiLineStringTest {
    @Test
    public void joinで文字列が連結される() throws Exception {
        String ls = System.getProperty("line.separator");
        String expected = "Hello" + ls + "World";
        assertThat(MultiLineString.join("Hello", "World"), is(text(expected)));
    }
}

正）

public class MultiLineStringTest {
    @Test
    public void joinで文字列が連結される() throws Exception {
        String ls = System.getProperty("line.separator");
        String expected = "Hello" + ls + "World" + ls;
        assertThat(MultiLineString.join("Hello", "World"), is(text(expected)));
    }
}

公開済みのサンプルコードは正しいコードとなっており、書籍のみ誤植になります。

ご迷惑をおかけして申し訳ありません。

(7)に続く...

SQLアンチパターンにおけるPostgreSQLパッチ #sqlap

SQLアンチパターンはMySQLがベースになっているのでPostgreSQLではそのまま動かない。とりあえずサンプルデータベースの変更ポイント。

• BLOBã‚’BYTEAに変更
• UNSIGNGEDがないので省略
• DATETIMEã‚’TIMESTAMPに変更

テーブルを削除したい場合はDROP文をIF EXISTSオプションを付けて冒頭に書いておけばOK。

DROP TABLE IF EXISTS 
  Accounts, BugStatus, Bugs, 
  Comments, Screenshots, Tags, 
  Products, BugsProducts;

修正後のSQLって公開してもいいのかな？
id:t-wada さんに公開OKといただきました。

（追記）リポジトリ公開しました

写経しながらとなりますが、こちらのリポジトリにおいておきます。
https://bitbucket.org/shuji.w6e/sqlap

最初のセットアップスクリプトはこちら。

北海道Devキャンプ2013 ーニセコのお知らせ

7月の連休（予定）となりますが、ニセコのコテージとかを数日借りて、TDDBCをベースとした開発合宿を行う予定です。

とは言っても、TDDBC関係者が中心となっているだけで、TDDとかやらなくても全く問題ありません。やることが特に決まっていないならば、TDDBCのお題を解いてみたり、その辺の話題で盛り上がったりできればいいな、という程度です。

また、今回のキャンプでは開発合宿だけではなく、温泉・サイクリングやラフティングといったアクティビティ・バーベキューなど北海道を楽しんで、仲間と一緒にリフレッシュしようというのがテーマです。
遊ぶものはおって決めていきたいと思いますが、サイクリングだけは確定。1人でも朝走りますｗ
なお、遊ぶための道具については持ち込んでもらっても、ニセコでレンタルしてもOKです（実費）。

と、こんなノリで、北海道に遊びに来たいと感じた人は、こちらから参加表明を！なお、この参加登録は本登録ではなく、だいたいの人数把握のためです。本登録のための募集は3月以降になります。

JavaのテストコードからはじめるGroovy #gadvent2012

本エントリーは、G* Advent Calendar 2012の24日目のエントリーです。前日は、@tetsurokitaharaさんのGroovyにProcessingを！でした。

何をネタに書こうかなと悩んだのですが、思うほどG*なネタは持っておらず、JUnitネタとなりました。実は、書籍「JUnit実践入門」でもGroovyを活用するトピックを入れる予定だったのですが、紙面の都合上、入れる事ができませんでした*1。そこで、少しだけですが、本エントリーで補足したいなと思います。

テストコードでGroovyを使う

Groovyは、Javaと親和性の高いプログラミング言語です。上司を説得する場合は「GroovyはJavaの拡張ライブラリです（ｷﾘｯ」と言っても良いでしょう。本当は開発環境やビルドツールの設定などで一工夫しなければ利用できませんが、その辺は裏でしれっとやってしまえばOKです。
とはいっても、いきなりGroovyやるぞと言ってもチームのメンバーはびっくりしてしまうかもしれません。そこで少しずつ洗脳していくために、テストコードをGroovyで書くところから始めるとスムーズに導入できる可能性が高まると思います。
なぜならば、Groovyはこれまで書いていたJUnitのテストコードを、同じように、簡単に、楽して書くことができるからです*2。

なお、EclipseでGroovyの開発を行うには、Market Placeで「Groovy」を検索し、Groovy-Eclipseをインストールするのが簡単です。お使いのEclipseに合わせて「Groovy-Eclipse for Juno」か「Groovy-Eclipse for Indigo」を選択してください。

テストコードの比較

Javaを利用したテストコードのサンプルは次のようになります。

public class CalculatorTest {
    @Test
    public void _4を2で割ると2を返す() throws Exception {
        Calculator sut = new Calculator();
        assertThat(sut.divide(4, 2), is(2.0));
    }
}

一方、Groovyで記述すると次のように書けます。

class CalculatorTest {
    @Test
    void "4を2で割ると2を返す"() {
        def sut = new Calculator()
        assertThat(sut.divide(4, 2), is(2.0))
    }
}

違いをみていきましょう。

publicの省略

Groovyでは、クラスやメソッドのアクセス修飾子を省略した場合、publicとなります。したがって、classの前のpublicやメソッド定義のpublicを省略できます。書いてあっても問題ありません。

セミコロンの省略

Groovyでは、黒魔術を使わなくとも、セミコロンを省略できます。

メソッド名の先頭に数字の利用

Groovyでは、メソッド名を文字列のようにダブルクオーテーションで囲むことができます。すると、Javaでは定義できなかったメソッド名を定義できます。例えば、先頭に数字を使うことや、小数点・カンマ・句点などが利用できるため、テストケース名（メソッド名）が理解しやすくなります。

throws Exceptionの省略

Groovyでは、例外はすべて非チェック例外のように振る舞います。したがって、Javaで必要であったthrows句やtry-catch句を省略可能です。
このことは、プロダクションコードを書く場合には、チェック例外を使用するか非チェック例外を使用するかで議論の分かれる部分かもしれません。しかし、テストコードでは議論の余地無く、throws Exceptionでしょう。でも、書くのが面倒…ならばGroovyです。

変数の型を省略

Groovyでは、変数をdefというキーワードを使い、宣言することができます。Java的にはObject型として宣言されていることと等価であるため、「Object sut」と宣言していることと変わりません。
Groovyでは、実行時に呼び出されたメソッドがあるかをチェックし、ない場合は例外を送出します。これはコンパイル時のチェックが甘くなるため、Javaの静的メリットを小さくするかもしれません。
ですが、ここで書いているのはテストコードです。メソッドが存在しないで例外が発生することは全くデメリットになりません。

それGroovyならできるよ

これから書くJavaのテストコードの拡張子はgroovyとし、簡単に省略できるところをGroovy化しましょう。
そして、テストコードを書いていくと、様々な「こんなこと出来たらなぁ」が発生します。特に、Rubyなどスクリプト言語を扱った経験があれば、ヒアドキュメントが書きたい、リストを簡単に宣言したいといった気分になるはずです。
そんな時は、「プログラミングGROOVY 」を開き、解決できないか確認してみてください。

少しずつGroovyっぽいコードになってくはずです。

もう、プロダクションコードもGroovyでいいんじゃね？

Yes!

明日は @kazuchikaです。

プログラミングGROOVY

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

*1:Groovyの解説やインストール方法などを書くと少なく見積もっても後50Pは必要となったので

*2:テストコードを書いてない人は、まずJUnit実践入門をお買い求めください

『JUnit実践入門』正誤表(5) #junitbook

誤植速報その5です。
その1,その2,その3, その4, 技評さんの公式サイトです（おって反映されます）。

P286 ソースコードのエンコーディング設定（本文6行目）

誤）

POMのpropertiesセクションにproject.build.sourceEncofingタグを追加して指定します

正）

POMのpropertiesセクションにproject.build.sourceEncodingタグを追加して指定します

fとdのtypoです。

P421 テキストファイルのエンコーディング設定（本文6行目）

誤）

「テスト・ファイルのエンコード」の「その他」で「UTF-8」を選択します

正）

「テキスト・ファイルのエンコード」の「その他」で「UTF-8」を選択します

テキストの「キ」が抜けています。

ご迷惑をおかけして申し訳ありません。

報告して頂いた@hakuu0さん、@tomix55さん、ありがとうございます！

(6)に続く...