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

2013年7月20日土曜日

『JUnit実践入門』写経・実践会 in 横浜 #8 (最終回) に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #8 (最終回) #junitbook
http://connpass.com/event/2590/

2013/07/06 『JUnit実践入門』写経・実践会 in 横浜 #8 (最終回) #junitbook
http://togetter.com/li/529598

はじめに

今回は最終回ということで、書籍全体を通してのディスカッションとTDD/ペアプロ実践が内容でした。

最終回

ディスカッションでは、会社で行なっている新人研修でこの書籍を用いてやっているので、その内容についてと個人的な見解を話すことが出来ました。
主な内容については、Javaの研修が終わった新人に対してこの書籍を利用して、JUnitを利用してどうやってユニットテストを書いていけばよいのかを話しました。
この書籍にはサンプルが公開レポジトリに掲載されていますので、これを解答として行き着く手順をこの会で得られた経験も併せて説明しました。
実際にコードを書いてもらってmavenで動かしてみて確認しながら進めて行き方は、評判も良かったように感じました。

最終回ということで、これまでの参加レポートを列挙してみます。


#1には@kyon_mmさんが、#3には@t_wadaさんが、#6には@irofさん、著者の@shuji_w6eさんがゲストとして参加してくださいました。

個人的に印象に残った回を挙げるとすれば、やはり#6の特別編を挙げたいと思います。
cucumberとseleniumを組み合わせることで、ここまで振る舞いをテストが出来るんだよというのが実際に手を動かすことで実感できました。
そのおかげでGebを用いてSpockで似たようなことが出来るようになりました。

おわりに

今回で、この写経・実践会も終わりとなりました。
この本が出た後の半年で自分自身多くのことを学ぶ事ができました。
それもこれもこの会があったおかげだと思います。
書籍は積読では何も身につかないので、こういった会に参加することで他の方が実践している経験や知見を学ぶことが出来る事を実感出来ました。
他にもまだ読んでいない本があるので読書会が開催されていたら、積極的に参加してみたいと思います。



主催の@shinyaa31さん、参加者の皆さん、会場の横浜タネマキさん、ありがとうございました。

2013年2月4日月曜日

『JUnit実践入門』写経・実践会 in 横浜 #3 に参加して来ました。 #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #3
http://connpass.com/event/1668/

2013/02/02 『JUnit実践入門』写経・実践会 in 横浜 #3 #junitbook
http://togetter.com/li/448707

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #2 に参加してきました #junitbook

今回は「Part.3 ユニットテストの活用と実践 第11章 テストダブル」が対象でした。
範囲はそんなに広くなかったので、写経は早めに終えることが出来ました。
なので、Groovyで書いた場合を試してみました。

レポジトリはこちら→https://github.com/grimrose/junit-boost-camp

一つどうも動かない箇所がありました。



デバッガーで見てみた時


GroovyのmetaClassを使ってみたコードはこちら


どうも、Interceptしてないみたいです。

次のDelegateObjectSampleTestでは、エラーにならなかったので、多分そうかと。


余裕があるときにもう少し突っ込んでみたいと思います。

リファクタリング

ディスカッションの際、privateメソッドをテストするかという質問が挙がったのですが、
突如参加してくださった@t_wadaさんのお陰で、納得することが出来ました。
個人的には、privateメソッドの処理を別のclass(大抵パッケージプライベートのstatic class)として切り出して、
Quick JUnitでテストクラスを作成します。

そうすれば、黒魔術を使うこと無く呼び出し元のメソッドをテストすることが出来ます。
オブジェクト指向養成ギブスとは違う異質な縛りがあるようなプロジェクトもあるそうなのですが、そんなピヨピヨなプロジェクトでも、自動テストと責務に応じたリファクタリングを行うことで、適切に対応できると思います。

モック、スタブ、スパイ

以前にServletRequestに依存したオブジェクトを利用したクラスのテストを実施するためにjmockitを利用したことがありました。
その時は、他のモックライブラリに比べて色々出来るのでいいのかなと思っていましたが、
今回@t_wadaさんのお話を聴いてやりすぎると痛い目に合うということと、それを経験して戻ってくるのがいいのを教えて頂きました。

他のモックライブラリでは日本語の情報がなかなかなかったのですが、今回、この本が出たお陰でプロジェクトに導入するきっかけになるのではないかと思います。

おわりに

今回は、@t_wadaさんのお陰でモックを利用したテストに対してモヤモヤしていた箇所が少しづつ晴れてきたように感じました。
それに、監訳された「SQLアンチパターン」にサインを頂くことも出来ました。

主催の@shinyaa31さん、突然の参加で講師役?までされた@t_wadaさん、参加者の皆様、横浜タネマキさんありがとうございました。
次回もよろしくお願いします。

2013年1月20日日曜日

Yokohama.groovy #11 に参加して来ました #yokohamagroovy

Yokohama.groovy #11
http://connpass.com/event/1604/

2013/01/20 Yokohama.groovy #11 #yokohamagroovy
http://togetter.com/li/442240

はじめに

今回から、もくもく会形式になったYokohama.groovyに行って来ました。
去年までは、「プログラミングGROOVY」の青い本の読書・写経会だったのですが、ひと通り終えてしまったので、これまで学んできた事を自分で課題を見つけてやっていこうということになりました。

もくもくと

Gradle、JPA、JAX-RS、Gebを採用してRESTの勉強をしてみようと思ったので、課題としてみました。
途中まではJavaで書いていたものがあったので、すべてGroovyで書きなおしてそれから始めました。
レポジトリはこちら→https://github.com/grimrose/gradle-jetty-jndi-sample

次の目標は、jettyの設定ファイルをgroovyで生成できるようなのを作ってみたいと思います。
その後は、CDIの参照実装であるweldを試してみようと思います。

おわりに

これまでで参加者が一番多かったYokohama.groovyでした。
今後もいろいろな人が参加してもらえるような場所にしていきたいなと思っているので、今年もYokohama.groovyをよろしくお願いします。

主催の@shinyaa31さん、参加者の皆様、横浜タネマキさん、ありがとうございました。

次回も、よろしくお願いします。

2012年12月1日土曜日

『JUnit実践入門』写経・実践会 in 横浜 #1 に参加してきました。 #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #1
http://connpass.com/event/1487/

『JUnit実践入門』写経・実践会 in 横浜 #1 #junitbook
http://togetter.com/li/415943


はじめに

Cucumberハンズオン際に@shinyaa31さんがJUnit実践入門読書会を受けての開催したいといったことをおっしゃっていたので、
こういうのあったらいいよねとか、こういうのやると面白そうだよとか、いろいろ意見を出してみました。
初回ということで人数や需要も読めない中、無事開催することが出来ました。

いざ実践

条件にTDDBCに参加された方にしたためか、環境設定などほぼ済んだ状態で進めることが出来たのは良かったと思います。
16章から始めてみましたが、TDDBCではあまり触れられていなかった箇所を見ることでいい準備運動になったと思います。
3章までは、Introductionの箇所なので疑問に思ったことだったりしたことを、議論してました。

以下の本の話が出てました。TDDBCに参加された方々だったので自然かもしれませんね。

XUnit Test Patterns
http://xunitpatterns.com/

Growing Object-Oriented Software Guided by Tests
http://www.growing-object-oriented-software.com/

帰ってから気づいたのですが、xUnitの日本語関連のサイトということとなるとコチラを忘れてはならないと思います。

ぺけま
http://devtesting.jp/pekema/


終盤に、突如@kyon_mmさんが来襲されて、いろいろと3章までの内容について話してくださいました。
生業としている方の話が聞けるのはとても勉強になりました。

次回から本格的にJUnitに触れていきますが、個人的には特にルールについて知っていると得するような項目が並んでいるので楽しみです。

おわりに

今後もこの会を続けて行くにあたって、なかなか読んだだけでは分からないところも、
実際に書くことで実感したり、疑問をお互いに解決していけるようなそんな会になればいいなと思います。

@shinyaa31さん、参加された方々、@kyon_mmさんありがとうございました。

2012年11月12日月曜日

JJUG CCC 2012 Fall に参加してきました。 #jjug #jjug_ccc

JJUG CCC 2012 Fall – 開催概要

2012/11/10(#jjug)JJUG CCC 2012 Fall_(〜12:00)
http://togetter.com/li/404735

2012/11/10(#jjug)JJUG CCC 2012 Fall(13:00〜16:00)
http://togetter.com/li/404815

2012/11/10(#jjug)JJUG CCC 2012 Fall(16:00〜)
http://togetter.com/li/404881

はじめに

JJUGのクロスコミュニティカンファレンスが休日に開催されるということで参加してきました。
今回は、Twiiterでフォローしている方が登壇されるセッションが多いのが楽しみでした。

セッション

JJUG CCC 2012 Fall – タイムテーブル

午前のセッションは、諸事情によりセッションが前後しましたが、これからどうしてくのかという視点に経った時に役に立つ内容でした。

午後のセッションは以下のセッションを選択してみました。
  • Spock’s World
  • クラウド時代のSpring Frameworkの新たな試み。~Spring Dataの全貌~
  • テストコードのリファクタリング
  • Java プラットフォームにおける HTML 5 対応 !!
  • Twitter4Jのプロモーション戦略
  • 作って学ぶデータベース ~まずスモールデータから始めよう~

どのセッションも興味深いことがたくさんあったのが収穫でした。

一番印象に残ったのは、@yusukeさんの以下のような内容でした。
  • 全てのメソッドに対するテストコードを用意する。
  • スタックトレースにバージョンと検索用のコードを埋め込むこと
自社の商品をオープンソースにしている会社にいても、ここまでしたことはありませんでした。
ここまでしていることで、黎明期にいろいろ存在してた他のJavaライブラリとの差別化ができて、デファクトスタンダードになったのかなと思いました。

テストコードについては、@shuji_w6eさんの本「JUnit実践入門」を購入して、会社の人達にも読んでもらえるようにしていきたいと思います。

おわりに

ほぼ半日まるまるJavaの講演を聞いたのは、JavaOne以来だったので、楽しかったです。
年齢層も幅広くて、改めて歴史のある言語なんだと感じました。

ただ、いくらユーザ会のコミュニティが活発とはいえども、JavaEE6ですらもう3年前の技術なのに未だにStruts1.x使っているところが33%もあるという状況を生み出している会社のマネジメント層に進歩の欠片が見られないというのは、非常に残念で仕方ありません。
言語の進化に合わせて成長できるようになりたいものです。

主催してくださった日本Javaユーザーグループの皆様、ありがとうございました。

2012年10月11日木曜日

SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- に参加してきました。 #devlove

SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-
http://devlove.doorkeeper.jp/events/1733

2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove
http://togetter.com/li/387189

はじめに

業務系のエンジニアとして今後はどのようなスキルや知識を得れば良いのか、戦略を練るために必要だと思い参加しました。
相変わらずdevloveの勉強会はすぐに埋まりますね。

取り巻く環境

素晴らしいまとめ職人方がいらっしゃるので、そちらを見ながら講演を聞いた自分なりの考えを書いてみました。

  • 若年層は減少する
    • 劇的改善は望めないので、このままずっと老人の割合が増えていく一方でしょう。
    • 次の10年を考えても、この業界を希望する若くて優秀な人は取り合いになるでしょうし、優秀で情報の取捨選択出来る人は海外に出ていったほうがいいのではないかと考える人が出てきてもおかしくありません。
    • そうなった場合、自分たちの部下がどういった構成になるのか考えておく必要があると思います。
  • 社会的コストは増大する
    • 労働人口に占める若年層が減り、全体的に生産力は落ちた場合、どう穴埋めをしたらいいのか考えてみて、縮小した状態で維持というのが現実的に取れる手段なのかなと思います。
    • そうなると今でも支える人数が少ないにもかかわらず酷い状況なのに、リタイア組は増える一方なのでどう頑張っても徴収される金額は増えますね。
    • 現在でもそうですが、支えられている人たちの人数と投票率が高いために、支える側の意見が政策に反映されない状況を考えても、好転する可能性は無いに等しいと思います。
  • 実質所得は減少する
    • 所得が増える見込みがないのにもかかわらず、徴収される金額が増えるということは、実質所得は確実に減ります。
    • そうなってくるとどうやって額面も実質も含めて所得を増やせば良いのか考える必要があります。
    • 会社によっては副業を認めはじめたところもあるそうですが、極稀だと思われます。
    • 経営側からしてみたら上げたくても上げられなかったり、上げないことが前提なので、上げる手段が結局会社を移って上げていくしかないのかなと思います。

マーケットと手持ちのチップ

  • 縮小するけどゼロにはならない
    • 業界をマクロな視点で見た場合、縮小傾向になっていて、パイを取るために身を削ってダンピング合戦になっているようにも見えてます。
    • その結果、微妙な大きさの案件だと受注拒否であったり、規模を見誤って撃沈したりしている案件があるそうです。
    • 結局、難しいのも分かってはいますが、身の丈にあった案件を適正価格で受けないと上手くいかないということになってしまうのかなとも思ったりします。
    • もう少し流動性のある労働市場になれば、変わってくるのかなとも思っています。
  • 少ない人数
    • 結果的に少人数で回していく方法を取らざるを得なかった状況になったので、個人で複数の役割を担うというのは、そうなっていくのだろうなと思います。
    • 少人数で回す場合、マネジメント出来る人が複数でサポートしあう環境が理想的なのですが、現実はそうでもないので、会話を増やしてお互いの現状を確認しながら、アジャイルのプラクティスを取り入れると、それなりになんとかやっていけるようになると思います。
  • 手札の質
    • 少人数で回す場合、設計から運用まで携わらないと何も出来ないので必然的に学ぶことが出来ると思います。
    • その場合、どれくらいの失敗までならリカバリー可能か経験できると、なおいいかと思います。確かに、精神的にもコスト的にも痛手を受けますが、いろんな意味でいい経験を積むことができます。
    • 最強より下のランクのカードを複数手にしておくというのも大事ですが、カードの系統は近すぎず遠からずのを揃えるといいのではないかと思います。
    • I/Oがインターフェイスの境界になっている部分が多いので、そのあたりは例外設計の良い勉強材料になると思います。

おわりに

自分のおかれた状況が講演の内容と重なっていた部分が多かったので、これからどのようなスキルを身に着けていけば良いのか大変参考になりました。

登壇された@okachimachiorzさん、devloveのスタッフの皆様、会場を提供して下さった日本マイクロソフト株式会社様、ありがとうございました。

2012年10月7日日曜日

BPStudy#60 に参加してきました。 #bpstudy

BPStudy#60
http://connpass.com/event/887/

BPStudy#60
http://togetter.com/li/366174

はじめに

開催されてからだいぶ経ってしまいましたが、参加してきたので記録として残しておこうと思います。

JJUG CCCに参加しておらず@ikeike443さんによるPlay frameworkでの再演が気になったので参加しました。

Play! Framework - モダンで高速なWeb開発


参加者の方にJavaを扱っている方が結構いらっしゃったのが印象的でした。
その中でも、Play frameworkに触った方も意外といらっしゃいました。
Playの事例もポツポツと出てきているので、自分の使っているプロダクトでも使えるようになればと思ってます。

使ったことや動かしたことがある方にはちょっともの足りないと感じましたが、知らなかったり、触れたことが無い方には興味を持ってもらえるような内容だと思いました。

ECMAScript5時代のJavaScriptライブラリ

BPStudy#60 ECMAScript5時代のJavaScriptライブラリ
IE6に縛られてるプロダクトがまだあるのは、ホント残念です。
JavaScriptについては、メインで使っていないのでECMAScript5になってどう変わるのか知れてよかったです
https://github.com/monjudoh/BeautifulProperties.js
READMEみながらやってみたいと思います。


Let's Play! Let's Study!


実際にPlayを動かされていたのですが、やはり1.2系は早いですね。
千葉のご当地ヒーローをプッシュされていたのが、気になりました。

おわりに

今回記念すべき60回という節目に参加できてよかったと思いました。
登壇者の皆様、主催された株式会社ビープラウド様、ありがとうございました。

2012年9月16日日曜日

XP祭り2012 〜ソーシャルチェンジ!〜 に参加してきました。 #xpjug

XP祭り2012 〜 ソーシャルチェンジ! 〜
http://xpjug.com/xp2012/

XP祭り2012 〜ソーシャルチェンジ!〜
http://kokucheese.com/event/index/45007/

2012/09/15 XP祭り2012 ~ ソーシャルチェンジ! ~ Vol.1(前日まで~本編午前) #xpjug
http://togetter.com/li/360397

2012/09/15 XP祭り2012 ~ ソーシャルチェンジ! ~ Vol.2(本編午後:コンテンツ祭り) #xpjug
http://togetter.com/li/372845

2012/09/15 XP祭り2012 ~ ソーシャルチェンジ! ~ Vol.3(本編午後:基調LT以降) #xpjug
http://togetter.com/li/372846

はじめに

XP祭りは名前だけ知っており、どんなものか見てみたかったので参加してみました。
寝坊してしまって、アジャイルサムライ読書会横浜道場で宣伝されていたアジャイルコーチ・ラウンドテーブルを見ることが出来ませんでした。
togetterを見る限り面白そうだったので、残念です。

C-3 状況打開力を叩き上げるTOCfEブートキャンプ【ワークショップ】

http://xpjug.com/xp2012-contents-c3/

TOCfE Boot Campということでワークショップ形式のセッションでした。
TOC for Educationについてはhttp://tocforeducation.org/に詳しく載っているそうです。
ツールとして「ブランチ、クラウド、アンビシャスターゲットツリー」があり、今回はその中でも「クラウド」のワークショップを行いました。

私達のグループは、分かりやすそうな「空調についてのジレンマ」をテーマにしてやってみました。

DSC_0461.JPG

DSC_0462.JPG

ファシリテーターの方が多かったおかげで、すぐに質問できたりしたので助かりました。

DSC_0460.JPG

特に仮定を設定する際に要望からなぜその手段をとるのかという理由を考えるということが参考になりました。
また、仮定を立てた場合にそれが正しいかどうかチェックすることで、解決策が出てきたり、仮定を変更したりすることが出来るということも参考になりました。

以上のことを踏まえて自分でもやってみました。

DSC_0464.JPG

時間切れで仮定を立てるまでに至らなかったのが残念ですが、対立するような事象があった場合どのように解決策を見いたしていけば良いのかを、知ることが出来たと思います。

TOC自体まだ知ったばかりなので、その他のツールについても知る機会があればいいなと思いますし、「クラウド」も使っていければいいなと思います。

C-4 マチコ先生の白熱風教室 in Waseda.univ 〜45分で分かるBABOK:序章〜【ディスカッション】

http://xpjug.com/xp2012-contents-c4/

このセッションのレポートはまとめ職人の@shinyaa31さんが担当されるとのことなので、安心です。

あの白熱教室風ということで参加者も発言するセッションでした。
このセッションに参加するような人たちだったので、結構興味深い発言が出てきたので楽しかったです。

個人的には、ウォーターフォールもアジャイルも次のステージに上がっていくのではないかなと思ってます。
どういう形態になっていくのか想像できないのですが、それぞれのいいところ、イケてないところも改善されていくと思うので、少なくとも現場レベルでは良い方向に向かうのではないかな、と楽観的に考えてます。
それをどうやって経営側がビジネスと結びつけて、よりよい価値を提供できる事業にしていくのかが、日本でアジャイルが普及していく課題ではないかなと思います。
誤解したり、変化を受け入れないような人たちがいるようなところは、相当厳しいのではないかなと思います。

Business Analysisがどういったものかさらっとしか出て来なかったので、頂いたチートシートを見ながらいろいろ勉強してみたいと思います。

終わりに

クロージングの際、初参加の人達でじゃんけん大会が行われ、本の提供が行われました。
ホントに様々な本があったのですが、私はこの本を選択しました。

DSC_0465.JPG

某界隈では別の呼称があるあの本です。
LOG.debug("nice catch!") に参加してきました #java_ja
この時点では興味はあったのですが、手をつけていませんでした。
Javaから関数型言語へシフトするならScalaだと思うのですが、全く関数型をしらない自分としては、先入観のない関数型言語を知ってからシフトしても問題ないと考えました。
ということで、少しずつでも関数型の勉強を始めたいと思います。
ちょうど学習パターンを使えるいい機会だと思いますので、併せてやってみたいと思います。

主催された日本XPユーザグループの皆様、各セッションの登壇者の皆様、会場を提供して下さった早稲田大学様ありがとうございました。

2012年9月14日金曜日

学び方を学ぶ 〜オブジェクト指向の設計と実装を学ぶ〜に参加してきました。 #devlove

学び方を学ぶ 〜オブジェクト指向の設計と実装を学ぶ〜
http://devlove.doorkeeper.jp/events/1605

2012/09/12 学び方を学ぶ ~オブジェクト指向の設計と実装を学ぶ~ #devlove
http://togetter.com/li/371959

はじめに

オブジェクト指向の設計については、座学的なことはあまりやってきていなかったので、しっかりと学ぶべきだと思い参加しました。

学習パターンをエンジニアの学びに適用するためには

会場に入った際に、冊子を頂いたのですがこの冊子はhttp://learningpatterns.sfc.keio.ac.jp/
を製本したものでした。

@takashiibaさんと@masuda220さんのディスカッション形式での進行だったのですが、pattern languageについては全く知らなかったので、まさに浴びるように情報が流れてきた感じがしました。

一番印象に残ったのは、2つのワークショップのことでした。



まずは、学習パターンの40個の項目についてのワークショップですが、これは一度小さい集まりでやってみたいと思えるような内容でした。
40個すべて経験しているような人は、相当稀だと思うのでぜひ話を聞いてみたいところです。
自分の経験談を話すのは、整理することも出来るし、また思い出すことでまた新しい視点を見つけられるのではないかと思います。

次に、ライターズ・ワークショップについてです。
これが印象に残ったのは、書いた人が発表するのではなく、予め内容を読んできた人たちが内容について話し合うということでした。
発表者は、輪から離れて話し合っている内容を聞いて、誤解されているようなことや漏れていたことなどをメモしたりするそうです。

詳しくはhttp://web.sfc.keio.ac.jp/~iba/sb/log/eid154.htmlを参考にしてください。

これは、ソースコードレビューにおいて魔女狩りに陥ってしまうのを避ける有効な手段の一つではないかなと思います。
または、GitHubやBitbucketに公開して、pull requestでいろんな人と議論するのにも似ているのではないかなと思いました。

オブジェクト指向設計と実装の基本スキルの学び方(学習パターンの実践)



9つのルールについては、いろいろなところで見かけて、それに対する議論も盛んに行われていたのも知ってました。
これを習得しようとすると結構きついと思っていたのですが、学習パターンに当てはめることでどのように始めれば良いのか、どのようにこなしていけばよいかといった道筋が見えるようになりました。

パラメータオブジェクトパターンとメソッドオブジェクトパターンの2つは、リファクタリングするようになると自然にそういう思考になっていくと見えてくるパターンだと思います。

現状では、「小さくする」の途中までは出来ているんじゃないかなと考えているので、今後は「役割ステレオタイプ」を覚えてクラスに役割を与えることを実践してみたいと思います。
その上でまだ小さく出来る方法を習得していければと考えてます。

終わりに

今回の内容は、自分にとって新鮮で目からうろこが落ちるような感覚でした。
特に、学習パターンの冊子は、見やすく分かりやすいので時間を見つけて何度も読み込んでみたいと思います。
また、オブジェクト指向の設計については、まず自分で使うツールのルール違反の箇所から始めたいと思います。
講演して下さった井庭先生、増田さん、主催して下さったDevLoveのスタッフの方々、会場を提供してくださったKDDIウェブコミュニケーションズさん、ありがとうございました。

2012年9月4日火曜日

Java基礎勉強会 に参加してきました #JavaBase

Java基礎勉強会 #JavaBase
http://kokucheese.com/event/index/44210/

Java基礎勉強会 #JavaBase -日本で最もJavaの基礎を勉強する会-
http://togetter.com/li/362176

はじめに

今回は、あの#なごやこわいで有名な名古屋でJavaの勉強会が開かれるということで参加しました。
お盆の後のちょうどいいタイミングということで、帰省も兼ねて名古屋に向かいました。

セッション

  • Javaの基礎
  • ジェネリクスの基礎
  • Java並行処理の基礎
  • スタックマシンとしてのJava VM
  • ClojureではじめるASM入門
  • 無名関数とretrunで小話を一席
  • Javaで(嵐を)呼ぶSML#
  • J2EEの基礎Struts
  • オレオレLINQで学ぶJava基礎
これだけ見ても「基礎≠入門」というのがひしひし伝わってきます。
初めて動く@bleisさんを見ることが出来ました。
あと、前の方に座った方々の熱心な姿を見て、名古屋の人たちとjava-jaの人たちに似たような雰囲気を感じました。
知らなかったり、コードを見たことがない言語がバンバン出てきたので、一瞬なんの言語の勉強会だったのか忘れそうになるほどでした。

特に印象深かったのはJVMに関するセッションでした。
普段使っているにもかかわらず、深いところは全く体系だって勉強したことが無かったので、とても勉強になりました。

日本語の本ですとJava言語仕様は第3版、Java仮想マシン仕様が第2版です。
最新はこちら。
http://docs.oracle.com/javase/specs/
Java8が出る前までには、どれだけかかるか分かりませんが、ひと通り読んでみたいなと思いました。

LINQについては、Java8でも取り入れられるものがあるそうなので、予習しておくのもありかなと感じました。
Javaで実装されたライブラリもあるそうなので探してみたいと思います。

懇親会

マサカリとはどういうものかを見ることができました。やっぱり#なごやこわい

おわりに

次回は言い出しっぺがいない限りないそうなので、残念です。(次回、本当のJava基礎勉強会とかのツイートが流れていたのは気のせいかな…)

主催された@kyon_mmさんのように知りたいから勉強会開いてみるというのは、慣れないと難しいと思いますが、いろいろと勉強会で知り合った人に声かけてとりあえず集まって話しあうだけでもいろんな話を聞けて面白いと思うので、そこから始めてみるのはありなんじゃないかなと思いました。

@kyon_mmさん、発表者の皆様、会場を提供して下さった日本オラクル中部支社様ありがとうございました。

2012年9月3日月曜日

TDD Boot Camp (#TDDBC) 横浜 Second Season に参加してきました

TDD Boot Camp (#TDDBC) 横浜 Second Season
http://kokucheese.com/event/index/46603/

2012/09/01 TDD Boot Camp 横浜 Second Season #tddbc
http://togetter.com/li/360406

TDDBC横浜 Second Season
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C2nd

はじめに

今回は、スタッフとして初めてTDDBCに参加しました。
前回は、運良く抽選で参加者として参加しました。
前回のレポートはこちら -> レポート置き場: TDDBC横浜に参加しました。
それから、現在までいろいろな勉強会やイベントに参加することで、そろそろスタッフとして参加してみたいと思っていました。
また、TDD in Actionでも感じていたのですが、他のペアがどんな感じでやっているのを見てみたいと思っていました。
言語はJavaで参加しても良かったのですが、あえてGroovyで参加してみてることで自分のGroovy力がどの程度なのかを知ってみたかったので、Groovyにしました。

基調講演

@tosikawaさんによる「テスト駆動開発入門」の入門でした。

写経については、@t_wadaさんの連載にもありました。
[動画で解説]和田卓人の“テスト駆動開発”講座 » 第6回 「写経」でTDDの手順や書き方を学ぶ
http://gihyo.jp/dev/serial/01/tdd/0006

誰が言ったのか忘れてしまいましたが、新しい言語を始める際にテスト駆動開発入門を写経することで覚えるといいと聞きました。
それにならって、私自身まだ、テスト駆動開発入門の写経をしていないので、これを機にやってみたいと思います。

ペアプロ中の気づき

一番印象に残ったのはこれでした。


ペアプロをしていると、基本的に閉じた世界になってしまいがちですが、誰かに相談したり一息ついて一旦閉じた世界から離れてみる必要があるなと実感しました。

参加者の方から、言語のTAと言語以外に抽象的な部分に対応できるTAがいてとても良かったという感想をいただきました。
今回は、@t_wadaさんを始め複数の言語が出来たり、実戦経験豊富な方がTAだったので、上手くサポート出来ていたのではないでしょうか(私はあまり役に立っていたとは言えないのですが)。

前日にStep2まで素振りをしていたことで気づいたのは、事前に同じ課題をこなすことで自分の過去をオーバーラップしながらアドバイス出来たことでした。
自分がつまづいた箇所やGroovyでならどう書くのかといったことを出来るだけ伝えたつもりです。

また、その他の言語のテーブルを見て回れたのは、とても勉強になりました。
個人的にはJavaScriptのテーブルが、ドライバー1とナビゲーター2で10分毎に交代しながら行なっていたので印象に残りました。
jasmine + node.jsを利用していたそうです。
http://pivotal.github.com/jasmine/

探してみたところgradleにもjasmineのpluginがあったので、触ってみたいと思いました。
https://github.com/dzhaughnroth/jasmine-gradle-plugin

コードレビュー

コードレビューでは、C++のペアに学ぶことが多かったとおもいます。
テストに対する取り組み方として、慎重に周りを見渡してこのまま前に進んで大丈夫か確認していく大切さを教えていただきました。

Spockの素晴らしさを披露するのが、TDDBCでのコードレビューにおけるGroovyの定番となっているのですね。
あと、gradleでプロジェクトを作った意図を汲んでいただけたのか、参加者の方がgradleのレポートを披露してくださいました。
これも結構好印象だったので良かったです。
ありがとうございました。

最後に

今回、スタッフとして参加して、TDDの知らなかったことや新しいことを学ぶことができました。
特に質問コーナーでスタッフの皆さんが自身の体験から学んだことを話していたことがとても印象に残りました。
まだまだ練度が低いので、もっといろんな「気づき」を出来るまで日々鍛錬したいと改めて思いました。

主催してくださった@setoazusaさん、参加して下さった皆様、スタッフの皆様、会場を提供して下さった株式会社アットウェア様、ありがとうございました。

2012年8月5日日曜日

Twitter 勉強会に参加してきました #twtr_hack

8月1日(水) - Twitter 勉強会 #twtr_hack @デジタルハリウッド東京本校(@dh_tokyo)
http://www.zusaar.com/event/331056

2012/08/01_Twitter 勉強会 #twtr_hack @デジタルハリウッド東京本校(@dh_tokyo)
http://togetter.com/li/348584

今回は、第3回Playframework勉強会 に参加してきました #play_jaで発表されたattaccaの@i2keyさんがクライアント側について発表されるとの事なので、参加してきました。



Railsの環境さえ整えてしまえば、こんなにも簡単にできてしまうのかと思うほど、面白い内容でした。
個人的には、playframeworkでおんなじようにscaffold作ってくれる機能があればなぁと思いました。
この資料を参考にしてやってみようと思います。



テキストマイニングを手動で行われたそうで、とても頭の下がる内容でした。
日本とその他の地域だと使われ方が違うそうなので、コミュニケーションのとり方の違いがそのまま現れているのかなと思いました。
日本語のテキストマイニングに強いフレームワークを利用してみたら、面白そうな企画だと思いました。



今回の勉強会で一番楽しみにしていた内容でした。
外部サービスのAPIが頻繁に変わりやすい場合、非依存にせざるを得ないというのはわかりますが、ここまで大変だと自分たちでラッパーのようなフレームワークを導入していそうなプロダクトが有りそうな気もします。
困ったときにさっそうと現れるTwitterのなんでも屋ことイケメン(@yusuke)さんがカッコ良かった。
OAuth2.0周りでTwitterはお世話になると思うので、よろしくお願いいたします。



チャーハン諸島を初めて知ったきっかけは、ミュ~コミプラスのアカウント(@mc1242)が使ってるクライアントだったということです。
TwitterのAPIと付き合っていくと、クライアントとサーバーとのやり取り、ストリーミングの制御、UI/UX等プログラミングの実践的な部分と向き合うことが出来るということが、印象的でした。
自分が本当に使いたいのかとか、どうやったら出来るのかとかいろいろ悩むのも楽しいので、やってみたいと思いました。

最後に

Paypalの不具合にも関わらず丁寧に対応して下さった主催者である@yusukeさん、講演者の皆様、とても素晴らしいネットワーク環境と会場を提供して下さったデジタルハリウッド東京本校様、ありがとうございました。

2012年7月31日火曜日

Jenkins ユーザ・カンファレンス 2012 東京に参加してきました #juc2012

Jenkins ユーザ・カンファレンス 2012 東京
http://connpass.com/event/467/

Jenkins ユーザ・カンファレンス 2012 東京
http://build-shokunin.org/juc2012/

2012/07/29Jenkins ユーザ・カンファレンス 2012 東京 Vol.1 #juc2012
http://togetter.com/li/346310

2012/07/29 Jenkins ユーザ・カンファレンス 2012 東京 Vol.2 #juc2012
http://togetter.com/li/346736

きっかけ

本格的にJenkinsを使い出したきっかけは、TDDBC横浜でコミットフックでビルドからレポートまで自動で行われていたのを見てからです。
仕事で使うツールを作っていた時、カバレッジを取るためにCoberturaを使っていたのですが、マシンが非力なため欲しい時にすぐに見れないというもどかしさがありました。
JenkinsならSCMと連携してコミットフックスクリプトからジョブを起動することができます。
これで、重たいビルドやレポート処理を別のマシンに任せることが出来、結果、テストの漏れや他のテストを壊していないか確認しながら進めることが出来ました。
その他にも、シェルスクリプトが書けるので、DBのバックアップを定時処理やwgetを実行して任意のタイミングで取る等に利用しています。
そんなに便利なJenkinsさんを使い倒している人たちが集まるカンファレンスなので、自分の知らない使い方を知ることが出来ると思い、参加しました。

セッション

当日は、以下のセッションを受講しました。
  1. Jenkinsプロジェクト現状報告とこれから (基調講演)
  2. Jenkinsによる自動受け入れテストから継続的デリバリーまで
  3. 愛されるJenkins氏になるために
  4. マルチステージ型継続的インテグレーションのすすめ
  5. 毎日が憧れの新築、反復可能なデリバリーによる常時新築システム
基調講演では、現在のJenkinsがどのような状況なのか知ることが出来ました。
特に印象的だったのは、Githubと連携してJenkinsがbuildを開始するデモにおける@kohsukekawaさんのタイプスピードでした。
その他には、プラグインの拡張ポイントの拡充や、Rubyによるプラグイン開発を可能にしたりとよりプラグインを使いやすくしたりする方向にシフトしているとのことです。
また、UIもVersion up毎に変わっていたのを感じていましたが、よりUXを充実したものにしようとする試みがなされていてとても使いやすくなってきています。

継続的デリバリーの話は、@ryuzeeさんの講演でいろいろ聞いていましたので英語でも分からないことが少なくてよかったです。
受け入れテストをコードで書くのは、SpockなりGebなりでやってみようと思います。
Jenkinsさんは、プロセスを改善する際に現状の把握と手助けをしてくれます。
そして、現実と戦うためにはやらないことや優先順位の低いものとして割り切らなければならない選択が必要になってきます。その選択を手伝ってくれるのもJenkinsさんです。
仮想化が出来るようになったおかげで、環境構築のテストも自動化の対象とすることが出来るようになりました。
Chef soloの実運用の話が聞けたのは、とても有意義でした。特に冪等性の話は、一度だけではなく何度でも実行できるようにしておくことで、フィードバックループを早く回せることが出来るので、スクリプトを組む際は考慮して行こうと思いました。

最後に

基調講演でも紹介されたbuildhiveに先日のTDD in Actionで利用したプロジェクトを試しに追加してみました。
自動的にgradleのプロジェクトとして認識されて、普通にtestまで出来てしまいました。
まだgradleでカバレッジ系のプラグインを試していないのですが、多分普通に使えるのでは無いかなと思っているので、試してみたいと思います。
レポジトリにpushされるたびにビルドが実行されるので、pull requestとの相性もバッチリです。

Jenkinsさんを世に出してくれた@kohsukekawaさん、リアルJenkinsさんである@ikikkoさん、講演者の方々、スタッフの皆様、会場を提供してくださった法政大学様ありがとうございました。

2012年7月26日木曜日

TDD in Action に参加してきました #tddact

TDD in Action #tddact
http://kokucheese.com/event/index/44005/

TDD in Action #tddact
http://togetter.com/li/343540

先日のSCMBootCamp in Tokyo 3に引き続いて、参加してきました。

今回は、パートナーにアジャイルサムライ読書会の横浜道場でお世話になっている@y_sumidaさんを迎えて、IntelliJ IDEA + groovy + Spockでやりました。
ドライバーの交代のたびにいちいちPC移動させるのは面倒だし、説明するよりコード書いたほうが分かりやすいので、ペアプロ用にHHKB Lite2を持って行きました。

課題はこちら
TDD Boot Camp 大阪 2.0/課題

当日の成果はこちら
https://github.com/grimrose/tddact_20120722

マウスを持っていかなかったのでちょっと手こずる場面もありましたが、交代もスムーズに出来ましたし、話し合いながら手を動かすことが出来たのでとても楽しかったです。
@y_sumidaさんありがとうございました。

環境設定にはgradleを利用しました。
gradleだとIDEA + groovy + Spockの環境は簡単に出来ますし、gradle wrapperまで用意できればgradleが設定されていないPCでもJDKさえ入っていれば同じことが出来るようになります。
gradleさん、パネェっす。

JPOUGさんのご好意で朝からビールが飲めるビールクズ環境でしたが、アルコールが入ると寝てしまう体なので懇親会まで飲めませんでした。

主宰の@kyon_mmさんと@pocketberserkerさんのライブコーディングは、Thinkから始めていたのでとても勉強になりました。
あの段階は、レポジトリの歴史に載っていないことが多いので、ライブならではだと感じました。
実業務でもあのやり方を取り入れてやってみます。

TDDのイベントで一番面白いのは、他の言語をテストから知ることが出来るということだと思います。
同じ課題をこなすことで他の言語でも、なんとなく文脈を読み取れるのでとても勉強になります。
TDDの課題と実装が言語ごとにまとまっていると、写経するにしても知っている言語との比較で理解できるのでとても参考になると思います。

今回のTDD in Actionは、BootCampと違って、自分のTDDに対する考え方に不安を持っていたり、他のやり方に興味が有るような人にとって、良い場を提供してもらえたのではないかなと思います。
次回あるか分からないとおっしゃっていましたが、関東でも続けていければいいなと思いました。

最後に

2日間イベントを開催してくださった@kyon_mmさんと@pocketberserkerさん、お疲れ様でした。
この2日間とても楽しい時間を過ごすことが出来ました。
スタッフの皆様、ビール等提供して下さったJPOUGさん、会場を提供して下さった日本オラクル様ありがとうございました。

2012年7月24日火曜日

SCMBootCamp in Tokyo 3 に参加してきました #scmbc

SCMBootCamp in Tokyo 3 #scmbc
http://kokucheese.com/event/index/42642/

SCMBootCamp in Tokyo3 #scmbc
http://togetter.com/li/342324


きっかけ

subversionを使っていてコミットせずにローカルの履歴管理出来たら嬉しいのにと思っていたので、分散VCSを知った時はこれで出来ると思っていました。
しかし、なかなか今までの考え方では理解できないこともありました。そこで、githubに触れながらgitに慣れていこうと独りでもくもくとやっていました。
SCMBootCampは2回目の内容が面白そうだったので、次回開催されるのであれば参加したいと思っていました。
準備にGitHubの設定があったので、もしかしたらpull requestの実践も出来るのではないかと期待してました。

世代差で見る履歴管理ツール入門
http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/scmbc-201207/speech.html

Gitチートシート

個人的にコマンドがずらずら並んでいるチートシートより「こういうことしたいならこういうコマンド使うといいよ」みたいなチートシートにすれば必ず見ると思ったので、チームに提案してみました。
その他にも、チームがsubversionに慣れていたので同じ事をする場合、svnとgitのコマンドを並べてみるや、ブランチに関するコマンド、GitHubに関するコマンド等をやることになりました。

成果はこちら。
https://github.com/grimrose/scmbc201207

コンフリクトを狙ったのに、綺麗にマージされたり、macとwinの改行コードや文字コードの問題があったり、コンフリクトの解消に手間取ったり、pushしてもrejectされて(´・ω・`)となったり、といろいろコミットグラフを振り返って見ると思い出されました。

初めはpullを使っていましたが、以下のようにfetchとrebaseを利用することで、コミットグラフを見やすくできるということを教えていただきました。
  • git checkout -b fix_xxx
    • - file edit -
  • git add
  • git commit
  • git checkout master
  • git fetch
  • git rebase origin/master
  • git merge --no-ff fix_xxx

複数のブランチをマージする際に使ってみようと思います。

期待していたpull requestも無事できました。演習とはいえ実際に取り込まれるとやっぱり嬉しいですね。
先日、間違えてgradleをforkしてしまったのですが、いつかはpull requestを投げてみたいと思いました。

最後に

反省点として、うまく伝えたいことを伝えられなくて、同じチームの人に迷惑をかけてしまったのかなと思いました。
中途半端に知っているのが一番良くないというのが、如実に出てしまいました。

懇親会でBitbucketのTシャツをいただきました。なので早速アカウントを作って見ました。
BitbucketってMercurialだけだと思っていましたがgitも使えるので、プライベートなレポジトリを作る際に利用してみたいと思います。

scmbc主宰の@kyon_mmさん、@pocketberserkerさん、スタッフの皆様、会場を提供してくださったニフティ株式会社様ありがとうございました。

2012年7月19日木曜日

Gradleトーキョー に参加してきました #jggug #gradle_ja #gradle_tokyo

Gradleトーキョー
http://atnd.org/events/30137

2012/07/18 Gradleトーキョー #jggug #gradle_ja #gradle_tokyo
http://togetter.com/li/340726

きっかけ

ここ数ヶ月今までant + ivyでビルドしていたプロダクトを徐々にgradleへ切り替える検証を行なっていました。
eclipseのtomcat pluginを前提としたプロダクトだったのですが、柔軟に設定が出来るおかげでなんとか上手くやれそうです。
また、gradleのおかげでgroovyを勉強する勢いがつきました。
gradleは、taskの中でgroovyスクリプトをGroovyShellを利用して呼ぶ出来るので、制約がいろいろあったりする特殊なプロダクトにうってつけです。
そんなgradleの勉強会が開かれると言う事で参加してきました。

gradle入門

gradleの良い点は、IDEのプラグインが優秀なのでeclipse、IDEAであれば簡単にそれぞれのプロジェクトが作れます。
gradleのイマイチな点は、mavenのようなテンプレートプラグインがまだ標準でついていないところです(テンプレートのプラグインは探すと見つかります)。
ただ、propertiesに標準のディレクトリパスを持っているので、それを利用してディレクトリを作るタスクを作ってしまうと言う事も出来ます。
gradleは、antのタスクも利用できますし、build.xmlも利用できます。なので、既存のbuild.xmlをそのまま利用するといったことも出来ます。
そのため、antからmavenへ移行するよりgradleへ移行する方がスムーズに出来ます。

gradle wrapper

gradle wrapperの良い所は、JDK1.6以上さえ入っていれば、環境設定をいじることなく実行できるので、デモ環境を作りやすいとこだと思います。
もちろんgradle wrapperからでも「--gui」のオプションをつけることでGUIで利用することが出来ます。
gradleのデーモン化も出来る等、gradleをインストールしている環境と同じことが出来るので、おすすめです。
wrapperの配置も簡単なので、配布するようなプロダクトでは使いましょう。

最後に

カスタムプラグインの作り方を学ぶことが出来たので、実際に作ってみたいと思いました。
講師の@mike_neckさん、gradle wrapperを解説してくださった@toru_inoueさん、会場を提供してくださったNTTソフトウェア様ありがとうございました。

2012年7月16日月曜日

第3回Playframework勉強会 に参加してきました #play_ja

第3回Playframework勉強会 #play_ja
http://playframeworkja.doorkeeper.jp/events/1231-%E7%AC%AC3%E5%9B%9Eplayframework%E5%8B%89%E5%BC%B7%E4%BC%9A-play_ja

2012/07/14 第3回Playframework勉強会 #play_ja
http://togetter.com/li/337676

きっかけ

告知されてから、あっという間に埋まってしまって、それでも参加したかったのでキャンセル待ちにしていました。
開催数日前になって、キャンセル待ちしてたおかげで参加することが出来るようになりました。

アップデートとロードマップ

1.3のアップデートにHibernate4への対応が含まれているというのが一番嬉しい内容でした。
ただし、DB moduleがHibernate3ベースなので多分使えなくなるのではないかと思います。
1.3以降はメンテナンスモードになってしまうそうなので、Play2も見据えて採用するといいかもしれません。

実例紹介

RESTでJSONを出力するフレームワークでフルスタックのものとなると数えるだけしかなくて、更にサクサク開発できるものとなるとやはりPlayが一番有力になってしまうと思います。
また、pluggableなので無ければ作って対応してしまうといったことも出来るのも良い所だと思います。
AWS使っている事例があったので、AWSでPlayを使ってどこまでスケールアップ出来るのかも今後お話が出てくると思うので楽しみです。

PlayとScala

Play2はNettyとAkkaで構成されているので、Javaで実装したとしても最終的にScalaを知らないとを原因をつかむことが難しいです。
あと厄介というか落とし穴になりやすいScalaTemplateの話もありました。半角スペースの有無でコンパイルが通らなかったりや「}」がパースされてしまったりといった実装周りから、吐き出されるhtmlが予想できないのでデザイナーさんとの連携が難しいといった実態の話もありました。
そのためGroovyTemplateのプラグインや将来velocityを利用したプラグインの公開されるかも?といった内容もあったので、View周りはHelperやFormといったViewModelを他のプラグインでも利用していくような形になっていくとより選択肢が増えていって利用しやすくなっていくのではないかと思います。

LT

LT中にhttp://playdocja.appspot.com/のライブリリースがありました。1.2の頃から翻訳されたドキュメントに助けられていたので2.0でもお世話になりたいと思います。githubに公開されているwikiとの連携もされていくそうなので楽しみです。
他にもプラグインの概要やPlay2でのAuth周り、HerokuとAWSのいいとこ取りの話など、今後詳しい内容を知りたいと思えるような内容ばかりでした。

最後に

今回は、実際に使われている方、運用に至った方の話を聞けたのは、とても勉強になりました。
一番印象に残ったのは、「テスト書かないのは人間レベルに達していない」でした。
人間になるためにもテストを書いて行こうと思います。

こういった勉強会に参加するのは、seedを見つけるためだと考えるようになりました。
そのまま食べてしまっても身にはなると思いますが、それではそれ以外のseedとのつながりを持ちにくいのではないかと思います。
それよりも、自分の土壌にいろいろなseedを植えて育てることで、総合的な果実を得られるのではないかと思います。
そういった意味でplayframeworkは、いろいろなseedが眠っている面白いproductだと思います。
日本Playframeworkユーザー会の皆様、参加された方々、会場を提供してくださったリクルートメディアテクノロジーラボ様ありがとうございました。
次回の勉強会も是非参加したいです。

2012年7月10日火曜日

G*ワークショップ「非同期並列なG*」+JGGUG総会 に参加してきました #jggug

G*ワークショップ「非同期並列なG*」+JGGUG総会
http://kokucheese.com/event/index/41799/

2012/07/06_G*ワークショップ「非同期並列なG*」+JGGUG総会 #jggug
http://togetter.com/li/333348

きっかけ

Startup Groovyから、IntelliJ IDEAでGroovyを使うようになりました。Community Editionのキーマップを慣れているeclipseに変更して使っています。
JGGUGの勉強会は、まだ行ったことがなかったのでステッカーに釣られて申し込みました。

GroovyCSPによる並行処理

Communicating Sequential ProcessesをJavaで実装したJCSPをGroovyでwrapしたのがGroovy CSPです。
GParsで利用できます。

プロセスとチャネルの話と、Ray Tracingのデモがありました。100%使い切ってるのに割り込み制御が即座に実行される様をみると並列処理の凄さを見ることが出来ました。
あと低消費電力のWebServerとしては、スリープ状態からアクションが起きたら実行してまたスリープに戻るといったことが出来るようになるそうです。

CSPモデル自体全く知らなかったので、調べてみたいと思います。

Grails/Groovyの開発活用術~Java EE資産を活かして開発を加速する~

Grailsの導入事例とGrails2.1のお話でした。
Grailsはまだ触っていなかったのですが、面白そうだと感じました。
開発補佐としてGrailsやGebなどのテストフレームワークも含めて徐々に使っていければいいなと思っています。

Grails2.1の詳細は、こちらから。
Grails 2.1.0 GA リリース!
http://d.hatena.ne.jp/mottsnite/20120705/1341495778

G*Magazine Vol.5のepub版はこちらのサービスを利用して作られたそうです。
Mybetabook
http://mybetabook.com/index_ja.html
jggug - 日本Grails/Groovyユーザーグループ
http://beta.mybetabook.com/u/jggug/

最後に

懇親会でgroovyでexcelからxmlに変換する仕事で使うツールを書いていますという話をしたところ、@nobeansさんにGExcelAPIを教えていただきました。ありがたく使わせて頂きます。

JGGUGの皆様、参加された皆様、会場を提供して下さったNTTソフトウェア様ありがとうございました。

2012年7月8日日曜日

第 7 回 JavaFX 勉強会 に参加してきました #jjfxug

第 7 回 JavaFX 勉強会
http://atnd.org/events/29880

2012/07/02_第 7 回 JavaFX 勉強会( #jjfxug )
http://togetter.com/li/330960

きっかけ

JavaOne 2012でJavaFXの紹介があって面白そうと思っていました。
勉強会が開かれるということで、どんなのか知りたいと思ったため参加しました。

NetBeans 7.2とScene Builder

NetBeans 7.2にScene Builderの設定をしておくことで、FXMLをグラフィカルに編集できるようです。
xmlを手動で編集するのは人間には酷な作業だと思いますので、こういうツールが無いまたは、使えないと正直つらいと思います。
ただ、Scene Builderもまだ洗練されていないみたいなので連携が不十分みたいです。今後連携できるようになると楽になりそうです。
表示構成をFXMLに任せることで、イベントの処理をViewModelへ移動して「MVVMモデル」になっているそうです。
個人的にはWebにアクセスする方法が思っていたより簡単だったので、jsonとか吐くサイトからJavaBeansに変換して取り込みとかやってみたいですね。

まとめ

デスクトップアプリは仕事でBiz/Browserでしか作ったことがないので余り経験が無いですが、今回の勉強会でWebと繋がる方法があることが分かったので、仕事用のツールとか使ってみようと思いました。

主催して下さった日本 JavaFX ユーザグループの皆様、LTをして下さった皆様、会場を提供して下さった日本オラクル様ありがとうございました。

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さんパネェな!