2012年4月8日日曜日

#junitbc JUnit Boot Camp に参加してきた

最近、burnを飲み始めました。

みけです。

いきさつ


私のATND notifier には単語「JUnit」が登録されているので、

誰かがJUnitというキーワードのあるイベントが登録すると自動通知するようになっています。

というわけで、参加してきました。

JUnit強化キャンプ


内容


非常に内容が濃いので、何回かにわけて報告しようと思います。

個人的にはJUnitの応用編が大変勉強になりました。

そして、主催の @shuji_w6e さんが実は熟練したGroovyistであることもわかりました。


Groovy…エ


ざっくりしたGroovyの紹介でした。

POGOをJavaで使う際に便利なアノテーションで

コンストラクタやtoStringなども自動生成できることを教えてもらいました。

例えば、このようなアノテーションを付与したクラス



は、このようにコンパイルされます。




toStringやコンストラクターが自動で生成されるんですね。



AppengineTestCase


JUnitの応用編で教えてもらったRuleアノテーションの利用方法です。

Slim3にてテストクラスを作成する場合は、AppengineTestCaseクラスを継承して作成するのが一般的です。

そこで、下記のようなユーティリティクラスを作成します。




これは、単純にAppengineTestCaseクラスを真似したようなクラスです。

このユーティリティクラスにRuleアノテーションを付与して次のようにテストクラスを作成します。




すると、不思議なことにAppengineTestCaseを継承していなくてもテストクラスが作成できます。

これのお陰でBeforeアノテーションを付与したsetUpメソッドを別途作成することができ、super.setUp()を呼び出さなくても良くなります。

なお、ものにもよりますが、Ruleアノテーションを付与したExternalResourceのbeforeメソッドはBeforeアノテーションより前に実行されます。


明日、また内容についてブログを書きます。

それでは。



参考

junitにデフォルトであるExternalResourceクラス



statementメソッドでbefore()→evaluate()→after()の順番で実行されています。

このevaluate()にて@Before→@Test→@Afterが実行されていきます。



#なごやこわい #うさみみ NagoyaTestingに参加してきた。

将来、娘の名前には「姫」と名付けたいみけです。

結婚する予定も付き合っているお姉様もおりません。

参加するきっかけ


なんかツイートが回ってきたから。

ちなみに参加したイベントはこれ。

Nagoya.Testing in Tokyo


後付で、上流テストをよく知らないとか言ったけど、

本当は無職になることがわかっていて、

どうせ暇だから参加すると決定した次第です。


Nagoya.Testingとは


うさみみこと @kyon_mm自説を長々としゃべるオフ会上流テストについて詳しく説明し、実際に手を動かしてテストをいかに作るかを学ぶ勉強会です。

なお、当日の資料については公開されています。



実習


おおたけさんおおわしさん紅千鳥さんと同じチームでした。

実習内容はテストを設計し、実装し、実施報告をするというもの。

みんな優秀で(、とくにおおわしさん)、関心してしまいました。

そんなわけで、テスト実施までこじつけることが出来ましたが、境界値とかの設計が足りなかったのと、異常系のテストがなかったかな。

比較的コンパクトなテスト設計ができて、それはいいところだと言われました。

相手のいいところを探して、さらにこうすればいいと説明するうさみみ、素敵です。でも、こわくなくなるともっと(ry。


感想


勉強会に参加したことのブログを書くのは、感想を読者の皆さんと共有して何かを得てもらうというのと同時に、自分にとっても何らかの感想を自分の次のステップへ導くための礎とするものだと思いまうす。

  • 勉強会の形式について
    • 聴講型の勉強会は成功事例などを通して、勉強へのモティベーションを上げる
    • ハンズオン形式の勉強会は実際に作業を通して勉強することで、座学では得られないスキルアップを体験する
  • ハンズオン形式の勉強会について
    • 積極的な発表をすることによって、作業内容を振り返ることができるので、発表の機会があったら積極的に挑戦してみる
    • わからないことは積極的に質問する。これによって、テキスト等からは得られないより具体的なアドバイスを得られる
  • 商品の品質は計画的に作る
    • 顧客からの要求は曖昧なので、具体的な品質に再定義する
    • WF型でやると品質がおざなりになるので、早い段階からテスト計画を立てる
    • ある程度設計が完了してくると工数の見積が可能になってくる
  • JSTQB関連の勉強はしておいたほうが良い
    • 開発というのは方法論が盛んに議論されていて、成熟したものである一方、テストはまだまだプロセスとして未成熟な領域である。
    • ある程度体系化したJSTQBに依拠することで先ずは標準的なプロセスを覚える
    • プロジェクトに応じてJSTQBのフレームを活用することで、プロセスモデルのテストを実施して、よりテストプロセスを強化する。
    • 情報を発信する

私が気になったところはこのようなところでしょうか。

あと、やはり開発者なので、今回のテストの勉強はひさびさな感じで、テスト力の衰えを感じました。

こういう勉強会は定期的に開かれると良いですね。

2012年4月6日金曜日

#てらだよしおがんばった JavaOne Tokyo2012 に行ってきました

二日間熱いセッションが繰り広げられたJavaOne Tokyo 2012に行ってきました。

僕の参加したセッション


僕は事情もあったため、参加登録をした頃には

ほとんどのセッションが満員で、

空いているものを適度に参加しました。

  • 4月4日(水)
    • 基調講演 Java Strategy Keynote
    • JS1-01 : Introduction to JavaFX2.0
    • JS1-31 : Project Lambda : To Multicore and Beyond
  • 4月5日(木)
    • The Java EE6 Programming Model Explained

以下、大雑把な感想

基調講演 Java Strategy Keynote

大体2015年までのJavaの開発予定についての説明。

個人的にはJava EEの発展が気になりました。 ( Java EE 7 )

で、ところで、残念なことに、基調講演の後、

◯山先生が「Java EE 7には期待しております( ー`дー´)キリッ」と

仰られたあたりが… おや、こんな時間にお客様が…

このあたりまでがツイッターで反応が最高潮に達したと思います。


JS1-01 : Introduction to JavaFX2.0

これはたまたま空いていて、事前予約したセッションです。

スレッドまわりの話を期待していましたが、

まあ、タイトル通りJavaFXでこんなことできるよって内容でした。


JS1-31 : Project Lambda : To Multicore and Beyond

これは面白かった。なぜこのセッションが空いていたのか

わからないレベルで面白かった。

これはもともと分散処フレームワークのFork/Joinからの要請で

出来た内容で、

コレクションなどに適用されるワンメソッドインターフェースの

記述方法を簡略化しようとするものです。


例えば、ファイルにフィルターをかける

FileFilterインターフェースについての

記述はラムダでは次のようになると思われます。


someMethod ( new FileFilter {
    @Override
    public boolean accept(File file) {
        return file.isDirectory();
    }
});

Lambda投下後
someMethod ({f -> f.isDirectory()});


明らかに記述量が減ります。


私にはこれは結構なパラダイムシフトを含んでいると思われます。


今、現在Java1.4で開発しているプロジェクトなどにLambdaを導入しようとするには、

二つの壁があると思っています。

  • ジェネリクス
  • ラムダ

前者は型安全を保証する大事な仕組みでJava5から導入されたものですが、

前々職でも何度も質問を受けました。


そして、ラムダはこの型安全の上に位置する機能だと思っています。

引数として何が渡されているか、推論した上でコードを記述するので、

ジェネリクスがわかっていないと、正直きついと思います。

言い換えると、何のインターフェースを記述しているか

パッと見では理解出来ないので、

導入できない現場もあるのではないかと思います。


ただ、Javaとしては非常に面白い試みなので、期待しています。


The Java EE6 Programming Model Explained

Java EE6の概要の説明。

web.xmlをCDIで不要にするというアイデアはなかなか面白いと思いました。

プレゼンターが中国系の方で、若干英語が聞き取りづらかったです。

ただ、こういう英語も聞けるようにしておかないと、

後々淘汰されていくと思います。


JJUG主催パーティー


こちらにも参加して参りました。

Groovyコミュニティーからの参加が多かったため、

Groovy非常に人気がありました。

そして、私、ビンゴで当たった時に、

Groovy サイコー

と叫びました。


最後の寺田さんの男泣きよかったですね。

しかし、このイベント自体、

寺田さんが居なければ成立していなかったと思います。

その意味で、本当にお疲れ様でした。

寺田さん、ありがとうございました。


ご挨拶させていただいた方たち


こういうでかいイベントは普段ツイッターで

お世話になっている方と出会うチャンスです。


今回もいろいろな方とご挨拶させて頂きました。

@yamadamanさん、@shuji_w6eさん、@daisuke_mさん、

@razonさん、@j5ik2oさん、cero_tさん、その他様々な方、

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


結構、人見知りの激しい性格なので、

お声をかけていただいて感激です。


参加者


結構、年齢が上がってきているのでしょうか、

20代の方が少なめでした。

このあたりは業界全体の問題なのかな…


結論


Javaもまだまだ捨てたものではないです。

ぜひ、みなさんもJavaをやってみましょう。

そして、積極的に情報収集をしましょう!

2012年4月4日水曜日

gradle + IntelliJ IDEAでプロジェクトをGit管理下に置く方法

JavaOne初日の申し込んでいたセッションがすべて終わって、

おとなしくしているみけです。


プロジェクトをGit管理下に置く


git cloneしてbuild.gradleを落としてきたのに、

gradle ideaした後に、

IDEAにGitの管理下に置くかと聞かれるのは嫌ですよね?


そんなときこそ、gradleがあるわけで、

build.gradleファイルに次のような記述を追加しておけば、

いちいちそんなこと聞かれなくなります。






IntelliJとGitの甘い関係-1

22時間単位でせいかつしているみけです。

バージョン管理


皆さんはバージョン管理に何を使っていますか?

僕は不勉強でGitをすこしかじっただけなので、

Gitを多少触れる程度です。

今日はIntelliJ IDEAのGit連携についての記事です。


デフォルトでGitサポート


IntelliJ IDEAの公式ページを見ると、

IntelliJ IDEAは有償版、無償版共にGitをサポートしているようです。

なので、特別にプラグインを入れるなどの

作業が必要ありません。


どんな感じ?


プロジェクトを作成した後に、

以下のコマンドを実行して初期化します。

$ git init

次にIntelliJ IDEAを立ち上げて

プロジェクトを開きます。


プロジェクトを開くと、右上の方にダイアログが表示されます。


右上の「Configure」というリンクをクリックすると、

設定画面が開きます。


ここで「Add root」というリンクをクリックすると、

VCS管理の対象に入ります。




ここで「OK」ボタンを押すと、

IntelliJ IDEAとGitとの連携の設定は完了です。


使ってみる


変更を加える

最新のコミットがなされている状態です。



この状態でIntelliJ IDEAの画面を見ると、

特に何もない状態となっています。




この状態から既存のコードを変更します。




青で囲った部分を見るとわかるように、

変更が加わった箇所にはマークがついて、

ファイル名の色が変わります。


git diffがデフォルトでされているわけですね。


新規ファイルを加える

Alt + Insert(MacではCtrl + N)を押してクラスファイルを追加します。




クラス名を入力します。




「OK」ボタンを押すと、Git管理下に置くかどうかダイアログが表示されます。




「Yes」ボタンを押してGit管理下に置きます。




あたらしく出来たファイルはファイル名が緑になっています。

変更したファイルとは何が違うのでしょうか?

コマンドで確認してみます。




新しく作成したファイルはインデックス上に、

変更したファイルはワークツリーにそれぞれいる状態です。


したがって、先ほどのGit管理下に置くという操作は、

git add ファイル名をした状態と同じ状態になります。


では、引き続きコーディングします。




コーディングが終わった状態です。

コマンドで状態を確認してみます。




git addした状態で、さらにワークツリーに変更が入った状態になっています。

これはIntelliJ IDEA特有の自動セーブのお陰ですね。



コミットしてみる

では、おもむろにコミットしてみます。



コミットするとIntelliJ IDEAでの表示が変わります。



先ほどまでは変更を表していた色のマークが無くなり、

Gitワークツリーとコミットが同じ状態になっていることを表すようになります。


あれ、GUIないの?


ここまでくると、GUIがあるのではないかと思われるので、

設定を探してみたいと思います。


とりあえず、先ほどのコミットにはテストがなかったので、

テストを追加します。




テストが通ったので、

メニューから VCS → Git → Commit File を選びます。




そうすると、コミット用の画面が表示されます。



これからコミットするファイルを選んで、

コメントを入力してコミットすれば完了です。

他にもimportのOptimizeや、コード分析などをコミットの前に実施してくれるようです(オプション)。




コードに問題があるとメッセージを表示してくれます。



問題箇所が表示されますので、対応します。



再度コミットをかけます。

するとコミット完了が通知されます。



まだまだ、調べると色々ありそうです。


おお、もう6時、子供は寝る時間ですね。それでは。

2012年4月1日日曜日

会社員、辞めました。

一応、今日は真面目モードで。

みけです。

TopGate、辞めました。


以前にもお伝えしたとおり、

昨日、3月31日を以って、

株式会社TopGateを退職いたしました。


社長の加藤昌樹氏、

Google API Expertの小川信一氏や、

Android全般に詳しいわかめまさひろ氏、

世界の揺下こと山下武志氏、

をはじめとする優秀な技術集団の一員として

いっしょに働けたことを誇りに思います。


会社員を辞める?


さて、これも私をTwitterでフォローしている方や、

ブログを読まれている方、

実際に私とお会いしたことのある方などには、

ご存知の方も多いと思いますが、

私は所謂普通の人と比べてみると、

ムラの多い人間であるようです。


実際、今冬の冬眠状態や、

今私が認識している睡眠相前進症候群状態を始めとして、

所謂普通の人と比べてメンタル面で

非常に奇異な特性を持っているようです。


そういった特性は認識しているのは

まあ、どうでもよくって???

問題は所謂普通の人との付き合い方にあります。


睡眠相がずれていくのは、

昼間、普通の人に対して資本が求める働きを

私は応えられないとか、

冬はほとんど成果が出せないなどという

問題をはらんでいます。


そのうえで、身体を普通の人に合わせるのか、

生活を身体に合わせるのかという問いを立てた時に、

私としては後者のほうを選択することにしました。


私自身としては、もし下記の条件でも雇っていただける会社があるなら、

お話だけは伺いたいと思っています。

  • 一日の勤務時間は6時間まで。延長は一切なし
  • 週の勤務日数は4日まで
  • 覚醒時間が常にずれていくので、自宅勤務可能
  • 夏季休暇はいらないですが、冬季休暇を3ヶ月いただける
  • Groovyをやらせていただける

おそらく、この条件を満たせるような会社はないと

思っていますので、

会社員を辞めるという決断をいたしました。


身体に合わせるという選択肢


私と同様に身体的な問題で成果を発揮できない状態で

いる人間というのは、

資本の側から見ると厄介な存在だと思う一方で、

その人間の側からしても資本の欲求に応えられないという

フラストレーションの溜まるものであります。


そのフラストレーションにより自身がなくなり、

またさらに成果を発揮できなくなって、

フラストレーションが溜まるという状態は、

おそらく私がこの30数年の間に何回も経験したものです。


いい加減、この課題に対して何らかのアクションを

取らないといけないわけで、

そのアクションとして、先程も記述しましたが、

生活を身体に合わせるという選択肢を採択することにしました。


個物と一般


もちろん、皆さんも自分の身体というのをご存知なわけで、

私のような選択をすることは、

「みんな頑張っているのに、なぜお前は…」

と言いたくなるところもあるでしょう。


私自身、このブログで幾度か表明していますが、

マルクスを信望しています。

マルクスの考え方というのは非常に徹底的なもので、

交換が成立しないなら価値はなかったという考え方は

非常に説得力があります。


マルクスの思想の背景には、

「個物はいかにして一般性を獲得するか」

という問題設定があるような気がします。


そうした個別唯物的な考え方に照らした時に、

「みんなが…」という社会主義的な考え方には

相容れないものがあります。


私は個物と一般という対立は無意味なものだと考えていて、

その両項の差異を明確にしていくという方法があるのではないかと思っています。


ちょっと最後の部分はうまく伝えられていない気がしますが…


欲望


経済的な行為であれ、なんであれ、

人間には欲望があって、欲望が行動のすべての源泉であると思います。


私も何かを動かすことや、何がどう動いていることを理解すること、

こういったことに非常に欲望を感じています。

(他にもありますけどね)


GroovyというJavaでできた言語が動いていることへの興味、

そして何かを動かせるという興味から

受け取る欲望の充足が非常に大きいということを私は感じています。


もっとこの欲望とその充足を満たしてみたいと思います。


そこで、以前表明したように

5月くらいには会社として登記できるように

会社を作ることにします。


計画


私はgradle_jaというコミュニティを立ち上げて、

gradleというGroovyのプロダクトの普及を当面やっていこうと思っています。

が、5月スタートアップに向けて4月はその準備、

そのあとは当面の資金稼ぎのためのサービス開発、

GrailsというGroovyのプロダクトの研究・調査、

Spring RooというJavaプロダクトの研究・調査、

という感じで一カ月を過ごしていこうと考えています。


以上、能書きが多かったと思いますが、

今後とも皆様よろしくお願いします。