2012年6月30日土曜日

LOG.debug("nice catch!") に参加してきました #java_ja

LOG.debug("nice catch!")
http://connpass.com/event/607/

2012/06/27 java-ja 『LOG.debug("nice catch!")』#java_ja #javaja
http://togetter.com/li/328035

前回の温泉回に引き続いて、通常回(?)に参加しました。

きっかけ


今回の主催者である@yamashiroさんのtweetからたどってまず目に入った以下の内容。
try {
    java-jaで例外とロギングについて勉強します
    話していただくのは
    俺たちのt-wadaこと和田さんと
    PFIの田中英行さん
    歩く萌え要素こと西尾泰和さん
    歩くモヒカン太一
    です
    try {
         LT.add(ヨシオリ)
         LT.add(crexista, 'クライアント側でナイスキャッチ')
         LT.add(@shomah4a, 'PyconJPのCfPの宣伝')
    } catch (LTTimeoutException lte) {
        LOG.debug(ドラ)
    }
    try {
        他にも発表いただくかもです
        あとLTやりたい人連絡ください
        発表、LTしていただける方は、人数が埋まっていても参加可能です。
    } catch (Exception e) {
        //OK
    }
    例のごとく懇親会をそのまま会場でビアバッシュ形式でやりたいと思います。
    2000円の予定です
} catch (Exception e) {
    //nice catch
}
今回のテーマに相応しいjavaらしい告知なので即、登録しました。

@t_wadaさんの講演は昨年のTDDBC横浜以来なので、約半年ぶりになります。
前回の温泉回でお世話になった方々の話が聞けるというのも、楽しみでした。

資料

[勉強会][Java]java-ja『LOG.debug("nice catch!")』に参加してきた #java_ja
@shinyaa31さんのブログに詳細な資料があるので、そちらを参照してください。
(@shinyaa31さんありがとうございます)

例外設計における大罪

「契約による設計」は、一番印象に残った内容でした。
実装していく上で呼び出し側と呼ばれた側の関係のそれぞれの役割を考えていないと、それぞれで同じような処理を書いてしまいがちです。
青いレンガについては、ジュンク堂あたりで探して見たいと思います。
Effective Javaを読んでいても活かしきれていないと実感しました。
特に「例外状態の時だけ例外を使用する」については、技術的例外とビジネス例外の振り分けを考えていないとJTAを利用して例外発生時にロールバックが発生するようにしたい・させたくないといったことができなくなります。
そのインターフェースのメソッドにthrow句がついていないのはなぜかということを意識して、実装していかないと非チェック例外でラップして無理やり投げて、呼び出し側でcatchしたり、nice catchして握りつぶしたりしてしまいます。また、インターフェースを作る場合もそれを考えて投げなければいけない例外を投げるようにしなければと感じました。

ログ、その時の為に。

ロギングポリシーが曖昧だと必要な場合に限って欲しいログがないということがありがちです。
すでに運用しているシステムの場合、足りないことのほうが多いのも関わらず増やす手段を取るのを忌避されてしまいます。
ログ系のミドルウェアとの連携を考慮して他のインターフェースとの境界を厚めにするというのは、意識していきたいと思います。

SLF4JのMarkerの話があって早速やって使ってみたのですが、同じクラス内の処理でも処理の境界がはっきり見えてくるので、ソースを追わなくても流れをつかむことができます。
出来ればAOPでも使えるようになるとさらにいいと思いました。
SLF4J + logbackは、他のロギングライブラリに比べて使いやすいし、他のロギングライブラリのブリッジも充実しているので、是非新規の場合は利用しましょう。

エラー処理の抽象化

「すごいH本」こと「すごいHaskellたのしく学ぼう!」の翻訳者のかたが基調講演をしてくださいました。
戻り値に処理結果とエラー結果を入れて返すということをやったことありますが、受け取り側で状態ごとで分岐しなければいけないので、めんどくさいですね。
Haskellではモナドというものを使えばできるそうですが、javaにおける例外処理抽象化ライブラリってどんな感じになるんでしょうか。
「すごいH本」に興味が湧いたので読んでみたいと思います。

最後に

LTでは、クライアント側での例外処理はユーザのこと考えてやろうね。とか運用から見たログについてとかLTじゃもったいない内容が多かったという印象を受けました。
今後DevOpsが増えていくのであれば、地味な印象を受けてしまうログが一番重要なのではないかと思うのでそういった観点での勉強会とかセミナーとか面白そうだと思いました。
fluentdは名前しか知らなかったので、実際にどうやって使っていけばいいのかとか調べてみたいと思います。

主催してくださったjava-jaの皆さん、登壇者の方々、会場を提供して下さったGREE様ありがとうございました。

GREEさんパネェな!

2012年6月22日金曜日

アジャイルサムライ読書会 横浜道場 「荒ぶる四天王」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「荒ぶる四天王」
http://kokucheese.com/event/index/41309/

アジャイルサムライ読書会 横浜道場 「荒ぶる四天王」 #agilesamurai #横浜道場
http://togetter.com/li/325229

今回は「5.4 何を諦めるのかをはっきりさせる」からでした。

何を諦めるのかをはっきりさせる

一時的に持ち出しまでして人員を増やしてスコープを守ろうとするけど、途中で出入りすることのデメリットは無視されがちだし、最終的に四天王全員に打ちのめされる結果に陥りがちだなと感じました。
プロジェクトで追い詰められる状況に陥る前に、最初の段階で優先順位を決めておくことで、逐次リソースを投入したり、品質を犠牲にしたり、納期を伸ばす交渉に全勢力を注ぐといったことを軽減出来るのでは無いかと思います。
このスライダーの意味は、相対的にどの価値を優先するかを表した「度合い」ということで、最小とはいえ、無視していいものではないということが分かりました。

前回捉えどころのないものでモヤッとした箇所が晴れました。
例えばイケてるデザインとユーザビリティならどちらを優先するのか等、プロジェクトの今後を左右しそうなものなど優先順位をつけなければならないような要素を出して、チームで話し合うということでした。

何がどれだけ必要なのか

Aチームを作るには、チームに必要な役割は何かを洗い出す必要があり、足りない部分をどうするのかをチームで決めなければなりません。
もし欲しい人材を迎えることが出来なかった場合、チームで教育していくのを選択することが多いと思います。その教育のコストをちゃんと計画に入れられることがなかなか出来ないのが現状だと思います。
また、チームにとって重要なのは「アジャイルな顧客」です。
プロジェクトの運転手として振る舞える顧客であればいいのですが、権限移譲が充分でない場合、優柔不断な場合は、どうするのか。
他のチームの発表では、チームがサポートするのをフィーチャーに組み込んでしまうという意見がありました。
それでもダメな場合もあるので、それは政治的な手段を取ることも止む得ないと思われます。
また、権限を持つ人に対してアジャイルサムライを読んでほしいという意見もありました。
私もアジャイルで開発する・しないに関わらず読んで欲しいと思います。

第5章を終えて

インセプションデッキを作ったとしてもまだ見積もりでコミットメントではないということが強調されていました。確かに話し合ったとしても粗削りな部分しか見えていないし、向かう方向を一緒にした程度で一緒に歩き出すにはまだ足りない部分が多いと思います。
インセプションデッキがチームビルディングに使えるという意見が出ました。
叩き台を元に自分たちがここにいる理由や不安に思っていること、やらないこと等大雑把でも話し合うことで、お互いに考えていることを知ることが出来ます。
コンテキストを共有出来れば、より同じ方向を向くのに役に立つと思いました。

まず、自分自身のインセプションデッキを作るのをやってみようと思います。

最後に

ウォーターフォールの歴史は全く知らなかったので、懇親会の闇LTはとても勉強になりました。


懇親会で興味深いLTをして下さった‏@shin_semiyaさん、初めて参加された方もいた参加者の皆様、横浜道場のスタッフの皆様、会場を提供して下さった株式会社アットウェア様ありがとうございました。
次回もよろしくお願いします。

2012年6月19日火曜日

Scrum Boot Camp 東京 に参加してきました #scrumbc

Scrum Boot Camp 東京
http://kokucheese.com/event/index/37041/

2012-06-16 ScrumBootCamp 東京のまとめ
http://togetter.com/li/321772

きっかけ

アジャイルサムライの読書会でscrumのboot campを行うイベントが開催されるという告知があったので、楽しみにしていました。
講師が@ryuzeeさんということで、ぜひとも参加したいと思っていました。
当日も横浜道場で見かけたことのある方が多かったので、アウェーという感じが全くしませんでした。

講演

内容は、【Agile Japan 再演】アジャイルな開発からアジャイルな組織へに参加してきました #aj12returnを今回のboot campに合わせたものでした。
特に印象に残ったのは、アジャイルソフトウェア開発宣言に対するよくある誤解とトヨタ生産方式の箇所でした。
  • ドキュメントも作らないのではなく、必要な物は作る。無駄なドキュメントは作らない。
  • 価値のある出荷可能な製品を継続的に届けることを重視する。

紹介された「トヨタ生産方式―脱規模の経営をめざして」の本を持っている方が意外と多かったので、探してみます。

ワークショップ -スクラム-

最初のワークショップは、ジェフ・サザーランドさんが行った紙飛行機のワークショップでした。

チーム名は、1番テーブルだったので「○太郎」にしました。(○に入る文字は想像にお任せします。)
他のチームでも会場が日本マイクロソフトなのにチャレンジャーな名前がいらっしゃったので安心しました。

スプリントは4回行われました。
やはり、スプリント1はタイムボックスの感覚に慣れず、プロセスもバラバラでした。
振り返りで
  • ゴール(完成品の形態)の共有
  • プロセスの改善
を行うことで、着実に成功数を上げていくことが出来ました。
途中、制約が変わる際は成功率を上げる選択しました。
最後のスプリントまで成功数がだんだん上がっていく過程は、とても楽しいものでした。
振り返りの際に、共通認識を広げていくこととアイデアを出すことでもっと良いアイデアが出てくる部分は、チームとして同じゴールを見ているからこそだと感じました。

ワークショップ -プロダクトバックログ-

プロダクトオーナーってこんなに大変なのかと思いました。
確かに、始めのうちはスクラムマスターにサポートしてもらわないと厳しいと感じました。
優先順位をつけるための業務知識も必要だし、チームの開発スピードに併せてバックログの提供しなければならないので、従来の放り投げ型しか知らない場合はかなり大変だろうなと思いました。
特に、一つづつのバックログの価値についてチームに伝えなければならないので、曖昧だったり自分自身が理解していないとそこで停滞が生じてしまうということを身をもって体験しました。

社内の小規模プロジェクトから始める際のプロダクトオーナー向け勉強会とかあったら、参加してみたいと思いました。

ワークショップ -プランニングポーカー-

日本マイクロソフトさんご提供のプランニングポーカーを利用して、上記のプロダクトバックログで起こしたものにチームとして見積もりを出しました。
全員がプログラミング経験者だったので、話し合う内容も実装よりでした。
受け入れテストが明確だとポーカーの数字も収束しやすいというのを感じました。

ここでは、一回で揃ったから安心ではなくて全員で根拠を話し合うことで、漏れを見つけあったり、よりよいアイデアを生み出せるということが出来るのだと教えられました。

ワークショップ -スプリントバックログ-

優先順位上位3つのバックログに対して、それぞれタスクに分割してそれぞれの理想時間を付けました。
ここで興味深かったのは、ストーリーポイントと理想時間の合計に相関が無いようにみえたことでした。
大きすぎる機能を分割した場合、どこまで後のバックログに影響を考えるのか、言語やらフレームワークに依存してしまうのだと思いました。変化に対応しやすいものであれば、目の前のタスクに集中できます。そういった意味でも最近のフレームワークを勉強して変化に強いものを取り入れていくことは、重要だと考えます。

エピローグ

タスクボードやバーンダウンチャートをなぜアナログで行うのかという質問に対する返答で、自然に視界に入ってくるというのがありました。
やったことがない人間からすると、ツールがあるんだからソッチの方がいいのではと考えてしまいますが、ちょっとした変更や追記も簡単に出来るということも大事なのだなと思いました。
記録もデジカメでやればいいという程度で、清書は重要ではないということでした。



一日でここまで濃い内容のワークショップをしたのは初めてでした。
今回のboot campで実感したのは、scrumではまるでアスリートのように自分の持っているものをどれだけ絞り出せるのかを考えて実践するということでした。
その為にも、基礎体力とも言えるスキルや経験がまだまだ足りないと思いました。

今回bootしたので次のステップに登るためにも、日々の改善の努力を続けて参ります。

最後に、講師の@ryuzeeさん、スタッフのスクラム道の皆様、会場を提供して下さった日本マイクロソフト様ありがとうございました。

2012年6月9日土曜日

アジャイルサムライ読書会 横浜道場 「具現化させる」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「具現化させる」
http://kokucheese.com/event/index/39780/

アジャイルサムライ読書会 横浜道場 「具現化させる」 #agilesamurai #横浜道場
https://yukar.in/note/ckF3TE

特別編を挟んだので通常回は約一ヶ月ぶりです。

今回は、第5章「具現化させる」からでした。
5章は以下の課題を解決する内容になっています。
  1. 解決案を描く
  2. 夜も眠れなくなるような問題はなんだろう?
  3. 期間を見極める
  4. 何を諦めるのかはっきりさせる
  5. 何がどれだけ必要なのか
今回は、上記の4つまで進めました。

解決案を描く

DSC_0226

解決案をチームで洗い出しておくことで、ご近所さんややらないことリスト等で漏れていた部分が見えてくると思います。
一番大切なことは、チームでアーキテクチャを選択するということだと思います。
チームに関係ない人たちによって勝手に決められたものを使うと、
失敗する可能性や、誰も知らないから学習するための時間が必要だったり、その時間すらスケジュールに組み込んでもらえなかったりすると時間外にやらなければならない等余計にコストが掛かります。
もちろん新しい技術を導入してよりよいものを作っていくためには、必ずチーム全体で共有していくことが前提となるはずです。

夜も眠れなくなるような問題はなんだろう?

DSC_0227

チームで不安に思っていることを余裕のある最初のうちに洗い出しておくことで、取り戻せない状況に陥る前に対処できると思います。
そのリスクも手が届く範囲のものであれば、先手を打つことも出来るし、ショックを緩和することも出来ると思います。
「低スペックの開発マシン」というリスクは、取り組む価値のあるリスクなので、積極的に解決して行きましょう。

期間を見極める

DSC_0228

ランドール(ランディ)・D・モット
http://h50146.www5.hp.com/info/company/execteam/bios/mott.html

半年前から見た場合、現在を予想出来るかと言われた場合、去年から見た場合に比べて出来る部分が多いと思われます。
例え大規模なプロジェクトでも6ヶ月以内に区切ることで、要件の膨張率も抑えられますし、本当に価値のあるものを提供するには、
優先順位を付けなければならないという強制力が働くと思われます。
ここ一番大切なのは、この計画がコミットメントではないということです。
あくまでも予測でフィードバックを得ながら変えていく必要があるというのが重要です。

何を諦めるのかはっきりさせる

DSC_0229
DSC_0230
案件によっては、固定されるものが変わってくるというのは確かにあります。
品質の定義を決めておくことで、変更しやすいと言われているスコープを見極めやすくなると思います。
ゴールを見据えながら、四天王と戦う方法を考えなければなりません。

ここで出てきた「捉えどころのないもの」をどうやって俎上に載せるのかが、モヤッとしました。

最後に

今回の各チームのシートはこちらです。
http://flic.kr/s/aHsjzUmYsq

今回のKPTはこちらです。
http://flic.kr/s/aHsjzNTbPg

初めて参加された方もいらっしゃったようなので、これからも横浜道場を継続して参加できるような雰囲気にしていきたいですね。
道場主不在にも関わらず運営して下さったスタッフの皆様、参加者の皆様、会場を提供して下さった株式会社アットウェア様
ありがとうございました。

GlassFish Users Group Japan 勉強会 June 2012 に参加してきました #glassfishjp

GlassFish Users Group Japan 勉強会 June 2012
みんなの Java EE 6/GlassFish 再入門
http://atnd.org/events/28235

GlassFish Users Group Japan 勉強会 June 2012 #glassfishjp
http://togetter.com/li/315293


JavaOne2012に参加してからJavaEEについて、もっと知りたいと思うようになり、
Beginning JavaEE6を購入しました。
それ以来、少しづつBeginning JavaEE6の内容を進めてみました。
出来れば自分が携わっている今のプロダクトをJavaEEに置き換えていきたいと思っています。
GlassFishであれば参照実装なので、知っておくと他のアプリケーションサーバでも使えるのではないかと思います。

加藤田 益嗣 (@den2sn) 氏「GlassFishを4年間使ってきて思う事」




GlassFishを使っている方がどういった使い方をしているかなど体験談を聞く機会を持てたのが今回一番の収穫でした。
プレゼンのサービスも動きがあって面白いので、一度使ってみたいと思います。

久保 智 (@megascus) 氏「JavaEE6 First Application」


Beginning JavaEE6読みましょう。
NetBeansで作るときにMavenプロジェクトで作れば、IntelliJ IDEAやeclipseでも取り込めます。
NetBeansの自動生成機能を有効に使いつつ、慣れているIDEでいつもどおりにということもできるので個人的にオススメです。

久保田 (@sugarlife) 氏「Glassfishと他の (OSS) APP Server の取り巻く状況の比較」


コミュニティの状況から見たアプリケーションサーバの違いというのは、面白い発想だと感じました。

Tomcatが生き残り続けているのも、構築手順が他のアプリケーションサーバに比べ枯れているのと、
Linuxであればレポジトリに登録されているというのも大きいのではないかと思います。

蓮沼 賢志 (@btnrouge) 「GlassFishユーザー認証ワンポイントレッスン」

http://www.coppermine.jp/documents/programming/
GlassFishで利用できる認証と認可についてでした。

  • 認証(Authentication)
    • 主にサーバーで行いアクセスしてきたユーザに対して行う処理。
  • 認可(Authorization)
    • 認証されたユーザに対してアプリケーションが役割(Role)を割り当てる処理。
LDAPやJDBCのレルムについてまだわからない部分が多いので、じっくりやって行きたいと思いました。

Toshiaki Maki (@making) 氏 「Pure Java EE or Spring?」

JavaEE6BootCampで大変お世話になったスライドを作った方というのを初めて知りました。

Spring2.xのxmlの多さは異常だと思いますし、今の自社プロダクトもだんだんxmlが増えてきたてちょっと危険な兆候かなと感じてます。
Spring3.xからアノテーションとxmlの役割分担が出来るようになって、だいぶマシになってきているのではないでしょうか。
Springのいい点はDIから始められるということだと個人的には思っています。
徐々に他のコンポーネントと連携していくことが出来るので、こつこつ積み上げていくのが得意な人に向いているのではないでしょうか。

始めたばかりの私が思ったJavaEE6のいいところは、多少、実装によって細かい点は違うかもしれませんが、コンテキストを共有しやすいという点だと思います。
どちらも、チームがメンバーのスキルや保守のことを考えて決められるのが、一番望ましい結果になると思います。
上から押し付けられたとか、予め決まっていてそれしか使えないという理不尽な選択になることが多いと思いますが…

最後に

主催してくださった蓮沼さん、登壇者の皆様、会場を提供して下さった日本オラクル様
ありがとうございました。

2012年6月5日火曜日

みなとRuby会議01 に参加してきました #minatork01

みなとRuby会議01
http://regional.rubykaigi.org/minato01

よろしくお願いします。 #minatork01  on Twitpic


きっかけ

ChefがRubyで書かれているので、使うには知っておく必要があるとずっと思っていました。
TDDBC横浜やアジャイルサムライ読書会 横浜道場で知り合った方が、スタッフをされていたので何かの縁だろうと思い、加えてテーマが「はじめの一歩」ということで参加いたしました。

ソーシャルコーディング

お題はあみだくじの方を選びました。
TDDBC横浜以来のペアプロでしたが、ずっとRubyのレシピブック片手に「Rubyで表現するにはどうしたらいいか」を話し合って進めてたので、交代するの忘れてました。
制限時間内に出来なかったので悔いが残りましたが、一歩づつ進められた実感がありました。

招待講演

Rubyには地域コミュニティが様々あって、それぞれに特徴があるとは知りませんでした。
Railsのいいところをあんなに熱く語れるくらい好きになれるなんて、素晴らしいと思います。
Enumerableは、課題の際にリファレンスでよく引っかかってました。
遅延評価は、関数型言語で聞いたことがありますが、そういったトレンドも取り込んでいく意欲的な言語なのだと感じました。

はじめの一歩

Rubyに初めて触れて、とても楽しい言語だなと感じました。
Fedora17リリースされて、Ruby1.9.3がレポジトリに登録されたのもちょうどいいタイミングでした。
Rubyといい出会いが出来たのが、一番の収穫でした。

最後に
前日にいろいろアドバイスを下さった@joker1007さん、
ペアプロでペアになっていただいた@dasman74さん、
みなとRuby会議を主催して下さったyokohama.rbの皆様
ありがとうございました。

帰ってから、課題続きをやってみました。