ラベル 勉強会 の投稿を表示しています。すべての投稿を表示

2013年3月29日金曜日

#java_ja java-ja.ddd いってきた

去る2013/3/22(金)にjava-ja.DDDに行って来ました。

プレゼン資料は

http://www.slideshare.net/digitalsoul0124/ddd-17678116

http://www.slideshare.net/masuda220/ddd-forname

だそうです。

おわり。

これで、終わってたら、ブログの意味ないですね。

僕はドメインエキスパートと聞いて違和感があったので、

単純に「そんな人いるんですか？」と質問したら、

まあそれなりの質疑応答が始まってしまいました。

結論としては増田さんの「そんな人いない」の一言に尽きると思います。

僕も過去に大手企業の受託開発でいろいろと

Excel方眼紙による設計書を書いていたことがあるわけで、

かつて「顧客」に「敬称」をつけられるようにするという

案件がありました。

通常、僕らが「敬称」といった場合には

「～さん」「～様」「～殿」くらいしか使いませんが、

英語圏であれば

「Mr.～」「Mrs.～」「Dr.～」などがあります。

その案件が発生する元になったインドネシアかタイかでは、

前、後につける敬称があったりするんだとか、しないんだとかで、

いろいろぐぐってはみたものの何がなんだかよくわからんから、

「前敬称」「後敬称」とかいう謎のデータ項目が出来上がりました。

で、僕がこの案件の見積りとかしたとき、

入力画面だけにしか注目していなくて、

２画面を変更する程度の見積りでやりました。

だけど実際は「顧客」の「名前」を表示するというのは

入力画面だけでなくて、

帳票だとか顧客検索結果だとか所謂CRMだとか、

いろんな分野に登場するわけで、

実際にかかった工数は２画面以上の工数がかかったんだとか…

赤字ですな。

まあ、今考えると、

「顧客」の「姓名」「名前」、それと最終的な「顧客表示名」という

オブジェクトに分かれていれば、

この案件、比較的影響範囲が小さかったかななどと思っていたりします。

(実際はそうなっていないということをご想像ください…)

ただ、まあ、一点だけ気になるというか、

後になって考えると質問しておけばよかったなーと思ったのは、

オブジェクトを小さく作っていくことで楽になるとはいえ、

システム全体でクラスがどれくらいになるのか気になりました。

規模にもよると思いますが、

1,000～2,000くらいはあるんじゃなかろうかと推定される気がします…

最後に、

会場を提供してくださったGREEさんありがとうございます。

ピザのサイドメニューでついてきたオリーブ美味しかったです。

2013年3月16日土曜日

G*ワークショップZ Mar 2013 に参加してきた #jggug

みけです。

昨日確定申告の書類を中野税務署に提出したら、

ちょうど中野税務署の門が閉じたところでした。

ギリギリセーフ。

そのあと行って来ました。

G*ワークショップZ Mar 2013 Gradleハンズオン

内容はgithubにあるので、そちらを参考にどうぞ。

https://github.com/nobusue/GradleHandson

あとツイッターの実況中継はまとめられています。

2013/03/15(#jggug)G*ワークショップZ Mar 2013

最近はまとめ職人が洗練されてきていますねｗ

で、おまいは何をやってたんだ？

何も特にしていないです。

とりあえず、gradleにhelloWorkタスク作って

「hello work」というビルドスクリプト作りました。

毛虫本

Gradle Effective Implementation Guide

この本、翻訳やりたいです。

一ヶ月でやるので、どなたか出版社の人を紹介してくだされ～。

おわり

2013年3月10日日曜日

#GroovyBase Groovy基礎勉強会で発表してきたらしい

みけですう。

昨日(2013/03/09)にGroovy基礎勉強会で発表してきました。

僕の発表内容

例の如く(?)発表資料はありません。

gistのリビジョンでGroovyASTTransformationのAnnotation Based ASTTransformation

例をいくつか掲載していますので、御覧ください。

https://gist.github.com/mike-neck/5114818/revisions

まあ、GroovyASTTransformationという題で発表したけど

Annotation Based ASTTransformationを中心に発表しました。

なぜかってそれしか知らなかったGroovyASTTransformationを初めて書く場合には非常に導入しやすいからです。

基本的な(基礎的ではない)ASTTransformationの実装
(@ToString、@EqualsAndHashCode、@Canonical、
@Log、@Log4j、@Slf4j、@Singleton、@Delegate)

を知っておくことは、それよりもさらに進んだASTTransformation
(Spockとか、Spockとか、GContractsとか)

を読んで、活用して、新たなASTTransformationに移行することの足がかりになるからです。

実際に僕の発表の後のいくつかの黒魔術(Spock、GContracts)では、

ほとんどがASTTransformationを活用していました。

さて翻って、もう一度ASTTransformationの基礎…

GroovyにおけるASTTransformationの構成要素は次の３つです(かなり端折ってます)。

Expression

変数の宣言 (String namedef ageのようなもの)
定数の表現(0"groovy"true)
メソッドの呼び出し(list.size()、builder.append('c'))

Statement

変数の初期化(String name = "hoge";)
変数への代入(String name = builder.toString();)
制御文(if (condition) {//do something} else {//do another thing} )
return文(return builder.toString();)

Node

フィールド
メソッド
クラス
インポート

これら以外にもまだまだたくさん要素があるのですが、

おおよそこれらを把握しておくと、

ASTTransformationを書きやすいです。

所感

上原さんのGroovy Compilerの話

面白かったし、わかりやすい資料でした。

ASTTransformationをやるならこの辺りの知識も持っていないと

厳しい感じがします。

特にコンパイルフェースに対する理解は重要かと思われます。

自分の話

ヒィヒィしてました。

gdgdもいいところです。

須江さんのGradleの話

Gradleを理解したければ、プラグインを書けというのは

納得する。

きよたかさんのSpockの話

なるほど、アレはよくわからん

ポケットバーサーカーさんのGParsの話

GPars出てきてないしｗ

nobeansさんのGrailsの話

nobeansさん何気にIntelliJ IDEAガチ勢ということが判明

杉浦さんのGConstractsの話

杉浦さん「今季のおすすめアニメは『レイルガン』と『ニャル子さん』」きょん「( ´Д｀)=3」

懇親会

ピザと肉食ったら、トイレ行きたくなったので、

トイレで２０分くらい過ごしていました。

おわり。

2012年9月24日月曜日

Android温泉2012夏の陣＆つ部温泉に行ってきた #drospa2012

ドラクエ廃人のみけです。

ドラクエをやっている人は是非、ひめちゃんを雇ってあげて下さい。

温泉

Android温泉2012夏の陣＆つ部温泉に行ってきました。

当日の様子については、ツイートがまとめられています。

やったこと

まあ、適当にモクモクするという趣旨の合宿なので、

皆、適当にモクモクしている中、

僕は本を読んでいました。

読んでいた本はこれです。

内容

本の中身ですが、

普通のプログラマーならやってて当たり前だよねという内容でした。

合宿の方は…

大きな部屋で３５人が雑魚寝するとか、

ちょっとありえない経験ができました。

また、雑魚寝とかやってみたいですね（白目

2012年8月13日月曜日

JsonPullParser勉強会に行って来ました。 #jppatk

ドラクエのレベル上げ辛いです。

みけです。

ひょんなことから

わかめ氏のつくった軽量のJSONパーサーである、

JsonPullParserの勉強会に行って来ました。

なお、当日の参加者によるツイートはまとめられています。

宗教戦争

このブログをご覧の方はご存知のことかと思いますが、

わかめ氏はeclipseユーザーですが、

僕やイケメンこと山本裕介氏は最強のJava IDEである、

IntelliJ IDEAのユーザーです。

というわけで、アノテーションプロセッサーの設定方法で若干、

戸惑いました。

わかめ
mvn eclipse:eclipseして、mavenプロジェクトをeclipseで読み込めるようにします。

イケメン
ま、僕らIntelliJ IDEAユーザーだからpom.xmlをそのまま読み込めるんだけどね。

わかめ
なにーーー！

…30分後

わかめ
IntelliJ はわからないけど、eclipseで Java Compiler > Annotation Processing を選んで…

イケメン
IntelliJ でどうやるんだろう？

みけ
う〜ん、どうやるんだろう？

わかめ
ドヤァ

こんなやりとりがあったとか、なかったとか…

IntelliJ IDEAでの設定

正しくは次のように設定します。

IntelliJ IDEAのPreferenceを選びます。
Compiler > Annotation Processors を開きます。
Enable Annotation Processing にチェックを入れます。
Processor Pathにjsonpullparser-apt-1.4.11.jarのパスを入力します。
Annotation Processorsのところで + ボタンを押して、次のとおり入力します。
- Processor FQN に net.vvakame.util.jsonpullparser.factory.JsonAnnotationProcessorと入力します。
- Processor Options に JsonPullParserClassPostfix=Generatedと入力します。
Processed Modules にて + ボタンを押して、 Generated Source Directory Name に .apt_generated(ここは好きに入れて下さい)と入力します。
OKボタンを押します。
次にProject Structureを開きます。
Modules > Sources を選びます。
.apt_generatedディレクトリーを選択して、Sourcesボタンを押します。
OKボタンを押します。

以上で設定は完了です。

ソースを自動生成

Eclipseではファイルを保存するという行為が必要ですが、

IntelliJ IDEAは勝手にファイルを保存してくれます。

(「手動でファイルを保存するのが許されるのは小学生までだよねぇ、キャッキャッ」とは言いませんが…)

そのため、Eclipseではファイル保存というトリガーによって、

Annotation Processorが起動しますが、

IntelliJ IDEAではトリガーがないので、

手動でAnnotation Processorを起動する必要があります。

手順は以下のとおり。

Build > Rebuild Projectを選択します。

簡単ですね。

JsonPullParserのアノテーションたち

JsonPullParserで重要なアノテーションは以下の二つです。

@JsonModel
- 一つのオブジェクトを表象するアノテーション
- Javaのクラスに付与する
@JsonKey
- 一つのキー-バリューペアを表象するアノテーション
- Javaのクラスのプロパティに付与する
- decamelizeをtrueにすると、Javaではあまり望まれないような体裁のキー(例：first_name)をJavaのスタイルのプロパティー(例firstName)に合わせてくれます。
- valueにキー値を設定することで、classなどJavaで予約語となっているようなキーのマッピングを指定することができます。
- converterを指定すると、JsonPullParserを直接操作することが可能になります。

まあ、やってみよう！

というわけで、さっそくモデルクラスを書いて、

パーサーを作ってもらいましょう！

このモデルを書いた後、一度ビルドします。

その後にテストを書きます。

実行結果は…

おお、成功しました(∩´∀｀)∩ﾜｰｲ

ちなみに、Groovyクラスタの方は自重して下さい。

さて、ここまでできることがわかると、

Groovy使いの僕としては、

アノテーションプロセッサーの設定を手でするのが面倒になってきます。

というわけで、アノテーションプロセッサーをビルドに含める、build.gradleを作成しました。

こんな感じ。

あ、そういえば、Annotation Processingって、gradleでどうやるんだろう… T.B.D.

2012年7月30日月曜日

Jenkinsハッカソンに参加してきました。

私がヴィムである。

そろそろこのネタ飽きてきましたね。

ビーサンとボロボロのジーンズで…

熱いオッサンのできるビジネスマンの溢れる街

溜池山王で開催された

Jenkinsハッカソンに行ってきました。

内容はプラグインを作ってみること

川口さんやJenkinsのコミッターの皆さんと一緒の部屋で、

Jenkinsプラグインを作成するという

非常に濃ゆいハッカソンでした。

具体的な手順などは

ここを参照して下さい。

僕は二度三度と同じ事をやらないと覚えられないくらい

残念な頭の持ち主なので、

Hello World的なプラグインを2回ほどつくりました。

プラグインのUI(jellyファイル)とhudson.tasks.Builder

あたりはなんとか理解できた気がします。

作りたいもの

本当はFxJsJUnit用のプラグインを作りたいと思っています。

で、そんな話をしたら、参加していたインド出身のエンジニアの方に

興味を持っていただきました。

嬉しいですね！

8月のオレオレタスク早めに終わらせて、

FxJsJUnit作りを早めようかな！

2012年7月29日日曜日

Jenkinsカンファレンス2012に行ってきたよ

私がヴィムである。

あじ～、だりぃと言う猛暑の中、

Jenkinsカンファレンス2012を聴講しに行って来ましたよ。

え、おい！

会場に到着して、前の方の席に言った途端、

いんだれさんに声かけられました。

「みけ、手伝って！」

というわけで、そのまま拉致られて

即席スタッフになりました。

その結果

JenkinsのTシャツもらいました。

ありがとうございます。

印象

参加申込みは1,000人を超えているようでした。

実際は少ないと思いますが…。

凄いですね。

というわけで、Jenkinsに対する関心が高いことがよくわかりました。

セッション？

まあ、スポンサーセッション担当ということで、

スポンサーセッションをずっと聞いていました。

とはいえ、スタッフなので全体がうまく流れることのほうが

気がかりで、とても話を聞いているような状態ではなかったのですが…

内容としてはプロジェクトやチームに

Jenkinsをどのように適用していくか？

という話題が多かったと思います。

懇親会

行きませんでした(´・ω・｀)

結論

JenkinsはContinuous Integration/Delivery の

デファクトスタンダードツールとしての地位を

獲得していますね。

というわけで、明日はもう少し詳細を知るべく、

ハッカソンに参加してきます(｀・ω・´)

2012年7月27日金曜日

夏サミ行ってきましたよ。

ワ・タ・シ・がヴィムだ！

夏といえば…

夏サミですよ！

ということで、『Developers [Enterprise] Summit 2012』に

行ってきました。

結論

Yammerとかchatterを使って業務システムを構築しているところは、

今のところアーリーアダプターのようなので、

ソーシャルな業務システムを取り込めば、

ビジネスで先手を打てるかもしれません。

という感じで押していました。

自分的には…

まあ、逐次ツイートなので、そのままなんですが、

トップダウンで社員がなにをやっているかを管理するのなんて無理ゲー #SocialEnterprise #natsumiA4
— ヴィムさん (@mike_neck) 7月 27, 2012

新人は恐縮せずに先輩に聞け！Rubyについてわからないことがあったらmatzさんに答えてもらえるかも。そう、ソーシャルプラットフォームならね！ #SocialEnterprise #natsumiA4
— ヴィムさん (@mike_neck) 7月 27, 2012

スケールとかの課題はどの会社も抱えているので、ライブラリーやフレームワークを作ったら、オレオレのままにするのでなく、公開して他の企業とも共有してWin-Winになろう！ #SocialEnterprise #natsumiA4
— ヴィムさん (@mike_neck) 7月 27, 2012

githubに面白いコードをあげているような会社でないといいエンジニアが来てくれない #SocialEnterprise #natsumiA4
— ヴィムさん (@mike_neck) 7月 27, 2012

優秀な人材を求めている会社は、

自分のところのソースを公開して、

エンジニアに興味を持ってもらう。

一方、エンジニアは自分のコードを公開して、

積極的に発信して世間にアピールする。

そういうオープンな(言い換えると自ら発信していく)姿勢が

今後生き残るために、求められるのかなと思います。

因縁の場所

実は会場ですがそのビルですが、

前の前に務めていた会社で一時期そこに勤務していました。

前の前の会社はいわゆるSIerであり、

そこで僕は出来損ないの社畜だったわけで、

そんな僕が今こうして無職で自由な身で

先端を行く人達の話を聞けるとは、

社畜だった頃には想像がつかなかったとおもいます。

ｇｄｇｄ

一つ前のエントリーと関連するかもしれませんが…

エンジニアを名乗るには、その主たる商品である

お客様であるユーザーや企業に買ってもらえるために

自らを磨いていかないと厳しいですよね。

それはマルクスの『資本論』にも書いてあることですね。

一方買う側の心理学は投下資本の回収をメインに書いてあって、

そのあたりに対する皮肉を色々と書いてあったりします。

今回の夏サミの結果を以って、もう一度『資本論』を読み直したら、

再発見ができそうです。

終わり

ConfluenceのTシャツを着ていたので、

大沢さんにお声がけいただきました。

ありがとうございます。

今度、AtlassianのTシャツください！

2012年7月22日日曜日

TDD in Actionに参加してきた

涼しいですね。体調が悪くて死にそうです。

みけです。

JavaScriptで参加してきた

最近はJavaとかGroovyは毎日やっているので、

たまには違うものをやりたかったので、

JavaScript + qunitでの参加となりました。

ペアプロ

ペアを組んでやりましょうということで、

@tomy_kairaさんと組んでやりました。

トミー君はemacs的な人で、僕はWebStormなので、githubを介してTDDしてました。

僕はここ二日間の調子が悪くて、頭がどっか行っていたので、

「あー、いいねー…あー、うー」という感じでしたので、

トミー君の頭の回転には脱帽という感じです。

成果物

途中までできました。

github上にあるので、まあ見てみて下さい。

mike-neck/Tdd-In-Action

qunit

今回使ったのはqunitですが、

まだ使い始めたばっかりだったので、

うまく使いこなせていない感が半端無かったです。

ここで、実現できている機能とかは、Fx-Js-JUnitでは最低限実現したいところではあります。

Erlang

後半のほうでｇｄｇｄな時間が発生していたので、

一人でErlangの勉強していました。

こっちは大した成果はありません…

2012年7月7日土曜日

JGGUG G*ワークショップ行ってきた

咳が止まりません。

みけです。

JGGUG G*ワークショップ行ってきました。

ちなみにtogetterとかはこちらにあります。

Rod JohnsonがSpring Sourceを卒業したそうです。

ソース1

ソース2

CSPとは？

今回の目玉はCommunicating Sequential Processes(CSP)です。

Occamなどの言語はCSPの思想から作られているそうです。

ちなみにOcamlではありません。

言語的にはErlangに近いそうです。

なお、日本語の解説ページがあります。

こちらを参照して下さい。

JCSP

CSPモデルをJavaで実装したのが、JCSPです。

jarファイルはMavenおよびGradleから取得可能なようです。

下記を参考にして下さい。

pom.xml

build.gradle

サンプルコード

まあ、僕は文章を書くのが(文卒のくせに)苦手なので、

早速サンプルコードを書いてみました。

(正確にはコピペです。)

で、実行結果がコレ。

ログの出力の仕方からわかるのは、Parallelの通信が

出力→入力で一対一になっているところですね。

ChannelはQueueのような溜め込むという

操作を提供はしていないようです。

(まあ、そういうChannelもあるかもしれませんが…)

スレッドの遅い方(Readクラス)の速度に合わせて、

通信が行われているあたりが特徴的だと思います。

Groovy

Groovyで実行する場合は、Parallelクラスが

PARというgparsにあるラッパークラスに置き換わる

ところです。

PARクラスはgparsの中にあるやつか！ #jggug
— mike_neckさん (@mike_neck) 7月 6, 2012

結論

java.util.concurrentパッケージにあるクラスを

用いて、同様の処理を書くことができると思いますが、

それに比べると結構簡単に並列処理が書けそうです。

ちょっと面白そうなので、もう少しいじってみたいと思います。

2012年6月28日木曜日

Java 7 の try-with-resources をさわってみる

こんにちわ。みけです。

Java6のEOLが今年(2012年)の11月に迫っています。

なので、Java6を使っている人はJava7に切り替え始めましょう。

Javaの最新7の5分の1のバージョンを使っている人(つまりJava1.4を使っている人)はとっととアップデートして下さい。

Java1.4のEOLは2008年10月30日です。

Sunと契約している場合を除いて、契約していない人たちは泣き言を言わずアップデートしましょう。

…以前も同じ事書いた記憶が…

本題

昨日(2012/06/27) java-jaの『Log.debug("nice catch!")』に行って来ました。

開催者のよしおりさん、やましろさん、いつもご苦労さまです。

まあ、ツイッターとかまとめられているので、当日の様子については

そっちを御覧ください。しんやさん本当ご苦労さまです。

で、例外ハンドリングということで、Java7の例外ハンドリング、

try-with-resourcesが話題になったので、少し調べてみました。

ｇｇｒｋｓ

まあ、調べるったって、ｇｇｒだけなんですが、

たくさんエントリーありますね（白目。

なので、詳しい話はそっちを見て下さい。

そうは言っても

僕は自分の指を動かしたことしか理解できない単純な構造をしているので、

他のブログのエントリーと同様にコードを書いてみました。

まあ、テストの形をとっているのが他のブログと少しだけ違うかな。

で、テスト条件は次のWhen.javaというenumです。

enumにメソッドが実装できるのは周知の話で、

今回はenumの各値に条件を返すような実装を与えました。

onConstructorメソッドはコンストラクターで例外が発生する・しないを表します。
onMethodメソッドはメソッドの途中で例外が発生する・しないを表します。
onCloseメソッドはjava.lang.AutoCloseableで定義されているvoid close()メソッドで例外が発生する・しないを表します。

まあ、コード見ればわかりますが、

テスト条件を日本語でメモっとくとこんな感じ。

OnConstructorOnly

コンストラクター : 発生する
メソッド : 発生しない
クローズ : 発生しない

OnConstructorWithClose

コンストラクター : 発生する
メソッド : 発生しない
クローズ : 発生する

OnMethodOnly

コンストラクター : 発生しない
メソッド : 発生する
クローズ : 発生しない

OnMethodWithClose

コンストラクター : 発生しない
メソッド : 発生する
クローズ : 発生する

OnCloseOnly

コンストラクター : 発生しない
メソッド : 発生しない
クローズ : 発生する

NoException

コンストラクター : 発生しない
メソッド : 発生しない
クローズ : 発生しない

そうそう、これやってて気づいたんですが、

enum使えば、デシジョンテーブル系のテストをすんなり記述できますね。

まあ、enumをテスト対象に挟みこむにはインターフェースを使わないと難しいですが…

テスト実行

テスト実行しました。

コンソール出力は次のとおりです。

これをみててわかるのはclose()メソッド中に例外が発生した場合、

例外発生後に例外が発生した場合は握りつぶす！
正常に終了しているときに例外が発生した場合は例外を通知する

という動きをしていますね。

まあ、リソース処理系の例外の処理ってだいたいそうですけどね…

ロギング

ちなみにSlf4jでログを出力していますが、

ログ実装はLog4jです(´・ω・｀)

なお、ログ実装については

Marker使っていない人はSlf4jもう使うなよ #java_ja
— mike_neckさん (@mike_neck) 6月 27, 2012

ってことで、Markerについても覚えておきたいですね。

ちなみに日本語で最も正しいMarkerの使い方は

たいちさんの『設計と実装の狭間』でだそうです。

2012年5月3日木曜日

#shikadriven 鹿駆動勉強会に行ってきた、しゃべってきた

4/29に鹿駆動勉強会に行って来ました。

鹿駆動ってなんぞ？という人はあまりいないでしょうが、

一応、説明しておくと、

奈良で勉強会が開催されないので、

勢いで開催しちゃいました！しかも、能楽堂で！

って感じの勉強会です。

詳しくはこちら。

参加者のブログはいろいろとあるようです。

ITとともに生きよう - 「鹿駆動　勉強会　参加してきた　#shikadriven」

人生、気合いと具合 - blog - 鹿駆動勉強会(4/29)

システムアーキテクトのごった煮 - 鹿駆動勉強会で人生初LTしました！

koeだめ - 鹿駆動勉強会で奈良時代の技術について話をしてきた #shikadriven

他多数…

togetterにもまとめができております。

実は、自分も発表してきました。

資料はこちらになります。

Groovy joint

View more presentations from mike_neck

まあ、タイトルはJavaFXとJavascriptになっていますが、

中身はコンパイルのためのDIコンテナの話です。

GradleのコンパイルモデルはJavaをコンパイル→Groovyをコンパイルという順番なので、

JavaがGroovyの実装に依存している場合は、

コンパイルエラーが発生するというものです。

これを避けるために、インターフェースから実装クラスを指定できるようなものが欲しいと思って、

DIコンテナを作りました。

というところまで話したかったけど、

まあ、全くもって話できませんでしたね。

なお、作成したDIコンテナはこちらで公開しております。

https://github.com/mike-neck/gj-groovy-joint

しかし、皆さん、LTうまかったですな〜。

オレももっとLT訓練しないとと思った次第です。

2012年4月8日日曜日

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

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

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

参加するきっかけ

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

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

Nagoya.Testing in Tokyo

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

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

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

Nagoya.Testingとは

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

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

The outlineoftestprocess

View more presentations from Kyon Mm

実習

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

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

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

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

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

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

感想

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

勉強会の形式について

聴講型の勉強会は成功事例などを通して、勉強へのモティベーションを上げる
ハンズオン形式の勉強会は実際に作業を通して勉強することで、座学では得られないスキルアップを体験する

ハンズオン形式の勉強会について

積極的な発表をすることによって、作業内容を振り返ることができるので、発表の機会があったら積極的に挑戦してみる
わからないことは積極的に質問する。これによって、テキスト等からは得られないより具体的なアドバイスを得られる

商品の品質は計画的に作る

顧客からの要求は曖昧なので、具体的な品質に再定義する
WF型でやると品質がおざなりになるので、早い段階からテスト計画を立てる
ある程度設計が完了してくると工数の見積が可能になってくる

JSTQB関連の勉強はしておいたほうが良い

開発というのは方法論が盛んに議論されていて、成熟したものである一方、テストはまだまだプロセスとして未成熟な領域である。
ある程度体系化したJSTQBに依拠することで先ずは標準的なプロセスを覚える
プロジェクトに応じてJSTQBのフレームを活用することで、プロセスモデルのテストを実施して、よりテストプロセスを強化する。
情報を発信する

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

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

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

2012年3月26日月曜日

java-ja温泉行ってきました。

こんちは。

java-ja温泉行ってきました。

感想を140文字程度で…それって、ブログ書く必要なくね？？？

java-jaの人たち

みんなPythonやってました。Javaやっている人殆どいませんしたｗ

参加者の面々

ドワンゴ多すぎだろ、おいｗ

勉強になったこと

javascriptをdisるためにjavascriptを書いている人とか、pypyについて熱く語ってくれる人とか面白い人多いですね。

僕もEclipseをdisるためにEclipseを勉強したくなりました。

やましろさん

PHPに関するお話、面白うございました。「もう、動いてんだよ、問題ある？」

よしおりさん

すごい面々の中、司会進行などお疲れ様でした。

Java的に

concurrent utilを使えば、FxJsJUnitうまく行くのではとアドバイスをいただきました。

よしおりさん、太一さんありがとうございます。

あとでフォローします。

以上。

2012年3月8日木曜日

"291 things every developer should know"でLTしてきた

デベロッパーが知るべき291のことというイベントに参加してきました。

ニコニコ生放送でも放映されていたようです。

監訳者の紹介とコメント
監訳者たちがデベロッパーとして課題だと思っていることを議論する
読者達による98個目の知るべきこと(LT)

という内容でした。

当日のtogetterが@sinyaa31さんによって既にまとめられています。

当日の議論

同じテーブルに座らせてもらった@sue445さん、いわおさん、澈さんと議論しました。

1.チームワーク

まあ、メンバーの他の人に仕事してもらいやすいようにやりたいよねっていった感じの話をしましたが、

他の人(他者)っていうのは何だろうという、エマニュエル・レヴィナスばりの問いが立てられた所で終わってしまいました。

チームワークというのは、今眼の前にいるメンバーだけのことではなくて、

どこの誰だかわからない人も含めてチームメンバーではないのかという意味ですね。

そういえば、『プログラマー97』本で、恥ずかしいテストデータを作らないというのがあったと思いますが、

これはまさに、どこの誰だかわからない人も含めたチームメンバーのために仕事をする

というのに当てはまる気がします。

また、どこの誰だかわからない人をメンバーとして考えるという点で行くと、

最近よく言われるソーシャルコーディングというのも含まれると思います。

PM、アーキテクト、プログラマーあえて一番重要な役割を選ぶならどの人？

これは答えは出ませんでした。

この３つの役割がうまく回ってこそのプロジェクトであり、プロダクトだろうということで。

ちなみに私の中での勝手な物理的形態ですが…

PM … デリバリー
アーキテクト … 品質
プログラマー … 製品

という感じです。

少子化、国際化、ユーザー企業の意識の変化におけるプログラマーの生きる道

内容的には一番シビアなものでした。

ソフトウェアは価格の叩き合い、運用コストについても価格の叩き合い、データセンターは土地が大きい所(アメリカ)が有利という中で、

日本の情報産業というのは生き残れるのか？もし生き残るとしたらどのようにして生き残るべきなのか？

少子高齢化という現状において、日本の労働力をどのように支えていくのか？

また、外国人労働者の占める割合が極端に低い日本でどのように労働力を確保するのか？

一つ一つが重たい内容だったと思います。

私はわずかではありますが、英語が話せますので、海外に行ってやっていくという自信はあります。

したがって、それほどこの問題への自分への影響はないのかなと考えています。

ただ、まあ、社会問題として考えるなら、結構私は極論を走っていて、

「どんどん外国人を受け入れればいいじゃないの？」と思っていたりします。

イタリア系ブラジル人なアレッサンドラ・アンブロジオみたいなお姉様大歓迎でございます。

人口が少子高齢化で減ってしまう分、補給しなければ、サービスが廃れていくわけですし、新たなサービスの創出などもできないわけで、

小さな島国といえど純血度を下げてでも、海外の人口を受け入れなければやっていけないのではないかと思っています。

まあ、そうは言っても、これには高度に政治的な判断もあるでしょうし、

言葉の問題もあるでしょう。

なので、私が考えるほど単純な問題ではないと思っています。

懇親会 + LT

LTでお話をさせて頂きました。

実は私97本のうちのひとつ『97 things every Project Manager should know』だけは英語版で持っていて、

邦訳が発売される前に既に読んでいました。

そのようなことを元に、英語で英語の本を読もうというようなテーマでLTをしました。

One more thing every Japanese developer should try

View more PowerPoint from mike_neck

しかし、英語の本を見ていると、

日本では某◯山先生が注目したことによってオワコン感たっぷりなSpring Rooに

cookbookとか出ていたりして、海外と日本とで技術の流行(?)に差があることがよくわかります。

Groovyなんかも同様で、やはり英語の文献は数が多いですね。

Groovyは日本だとマイナーな言語ですが、海外ではそうでもないみたいです。

懇親会の方

オライリーの方がいらっしゃったので、Gradle本とRoo本の翻訳をやりたいんですけどと申し出てみました。

オライリー・ジャパンでは薄い本についての翻訳は今対応を検討しているところだそうですが、

もし面白い本であればいってくださいとの回答でした。

この辺の本の邦訳があるといいなと思ったりするんですけどね

実は英語の本を漁っていると面白そうな本ばかりで、逆に最近の日本の書籍に興味を持てなくなりつつあったりします…

2012年3月6日火曜日

JavaFX + JUnit で javascriptのunit testできるようにしてやるんで、これからハマっていってやんよ - 1

こんちわ。

大分暖かくなって来ました。

暖かくなってくると、旅に出たくなります。

特に、春なら鹿がお勧めです。

ついでに勉強会にも参加しましょう。

というわけで、

鹿駆動勉強会

とかいうのにエントリーすることになりました。

能楽堂でLTをするらしいです。

で、ネタ

JavaFX1のときはあまり惹かれなかったんですが、

JavaFX2になって、Webkit搭載となったので、

おお、JUnitでjavascriptのテストできんじゃね～と思ったので、

試してみることにしました。

まあ、その辺の経緯はtogetterにまとめてます。

事前にJavaFXとThreadにハマった言い訳を書いておく

もともと業務SEだったオレなので、

JavaのGUIとかはあまり触ったことがないというか、

ほとんど触ったことがないというか、

Javaを勉強した時にチョコっと触っただけです。はい。

なので、かなりクソいコードになっています。

サーバーサイドのJavaは書いたことありますです。

テスト対象のJavascript

特に大したことのないコードです。

数字を返す関数、文字列を加工して返す関数、オブジェクトを返す関数です。

テスト戦略？？？

テスト対象のJavascriptは大したことのないものですが、

ajaxアプリケーションのテストもやっていきたいので、

サーバーを立てていこうと思います。

JUnitでテストサーバーを立てる場合、

以前のエントリにも書きましたが、

Jettyエンベデッドサーバーを用いていきます。

サーバーが立ち上がった後で、ブラウザを立ち上げて、javascriptのテストをしていくという流れになります。

したがって、書いていくJUnitのコードは次のようになります。

@BeforeClassにてJettyサーバーを立ち上げる。
@Beforeにてブラウザーを立ち上げる。
@TestにてJavascriptのテストを実行する。
@Afterにてブラウザーを終了させる。
@AfterClassにてJettyサーバーを終了する。

JUnitのコード

次のような感じです。

なお、ハンドラーをJUnitに書くと若干読みづらくなるので、ハンドラーは別クラスにしてあります。

ハマる様子をとくと見よ

さて、JsJUnitを実行してみるとこんな感じになる。

JavaFXのWebViewはJavaFXのThreadで立ち上げなければならないらしいだって(´・ω・｀)

さて、まだまだハマるのだが、それは後日。

2012年2月18日土曜日

Developers Summit 2012 17-D-7 実践Androidデベロッパーズテストにて講演してきました。

通称デブサミ2012の二日目最終セッションでAndroidテスト部の一員として講演してきました。

講演資料はスライドシェアにあります。
こちらの26ページから56ページを担当させて頂きました。

また、その期間のツイートはtogetterにまとめてあります。

なお、今回の講演にあたってサンプルで作成していたアプリケーション「お小遣い・ログ」のソースコードはGitHubにて公開しています。

Twitter上で私をフォローしていただいている方はご存じの方も多いかもしれませんが、最近の私のTwitterのプロファイルは「冬眠中」となっています。

実は、これは文字通り意味していまして、若干過眠症気味な状態になっています。

そういったわけで、今回資料を作成するにあたっては、メンバーの皆さん @snskさん、@nowsprintingさん、@ussy00さんには大変ご迷惑をおかけいたしました。

ここで感謝を表したいと思います。

また、今回の資料を作成するにあたって、何度か会社を休んでしまいました。

相談に乗っていただいた株式会社トップゲートの加藤社長ならびに同僚の皆様にも大変感謝しております。

2012年1月9日月曜日

#日本鼻メガネの会に参加してみた的な

参加までの経緯

なんのことやらわからず参加しました。

多分、参加することになった理由は謎のハッシュタグ

#日本鼻メガネの会

ですね。

なんですかこの怪しげな響きは…と調べていくと、

日本鼻メガネの会新年会

十分に怪しい…

謳い文句もなんだか怪しい…

IT系勉強会でひそかなブームになりつつある鼻メガネを愛でる会です

え、ブーム、そんなのブームなのか？！

だが、もっと怪しいのが参加者の面々。

Twitterでよく見かける人ばっかり…

定員15人で、参加者14人、キャンセル1人だったので、参加できるっぽかったので、とりあえず趣旨はよくわからんが参加ポチった。

当日

とりあえず、鼻メガネは必要そうだったので、歌舞伎町のドンキホーテで鼻だけ購入。

会場は新宿角海老の裏。参考：新宿角海老(R-20限定)

とりあえず、店の名前よく覚えていなかったので(今でも思い出せない…)新宿角海老のあたりをウロウロしていたら、風俗関連のお兄さんに「お兄さん、どのお店探しているの？」と声をかけられました。

いや、おっ◯いパブとか興味ないから…

とりあえず、@shinyaa31さんのおかげで会場にたどり着きましたが、

ツイッターアイコンしか知らんので顔が誰が誰かようわからん…

いつもどおり、コーラをがぶ飲みしておきました。

当日の様子などは以下のエントリーなどが詳しいのでそちらを参照下さい。

他にも多数あるけど、まあ、ようまとめきれんです。

結論

勉強会で知り合ったクラスタとか、Twitterで知り合ったクラスタとの、ｇｄｇｄなオフ会意見交換会も面白いですね。

2011年10月16日日曜日

第4回Jenkins勉強会に行って来ました

第4回Jenkins勉強会に行って来ました。

さて、内容の詳細ですが、
ブログまとめ職人の@shinyaa31さんが素晴らしいものを書いていますので、
そっち読んでください。

あと、トゥギャッターもまとめられているので、読んでみてください。

togetter - 10月15日第4回Jenkins勉強会(東京都)
2011/10/15_第4回Jenkins勉強会( #jenkinsstudy )

当日のUST録画もありますので、興味のある方は御覧ください。

以上、報告終わり！

(´・ω・｀)