XP祭りに参加してきました 2016 #xpjug
ろくにブログを書けていないので、つい数件前のエントリが去年のXP祭りについてです。こんにちは。
今年も無事(?)参加させていただきました!
基調講演:牛尾剛さん
これを聴いただけでも来てよかった! という内容でした。
資料
https://docs.com/ushio-tsuyoshi/3779
【アイスブレイク的な話】
「マイクロソフト最高のDevOpsチーム」の話
詳細はこちらのブログにまとめられています。
http://simplearchitect.hatenablog.com/entry/2016/08/22/080010
F-Team / L-Teamの話が興味深かったです。
- F-Team : 新規開発に専念。集中が許されている。メールも見なくてもいいくらい。クオリティ大事なので常にペアプロ。
- L-Team : LiveSite 割り込みある。改善。
牛尾「どう考えてもL-Teamイヤですよね?」
→ 定期的に交換する。一番在籍が長いメンバーが交換する
F-Team:常にペア・プロしているので一人抜けても問題ない。
この、新機能開発にフォーカスするチームと、メンテナンスを請け負うチームに分けようっていう考え方、まさに今の部署で議論に上っています。
定期的に交換する、ペアプロしているからチーム内で知識が共有されている、 っていうのは素晴らしいですね。
【本題】
日本文化のままではどうにもAgileとかDevOpsとか導入できない。「薄まったカルピス」みたいになってしまう。
アメリカと日本では生産性が100に対して62しかない!
ということで、西洋文化を理解しよう!
1. 生産性マインド
2. 主体性マインド
3. 雇用形態マインド
を変えよう!
というお話だったんですが、生産性マインドの話が自分的にはガツン。
アメリカと日本では
「物量が違う」
とのこと。
どういうことかというと、日本では本質的でない作業、やらなくて良い作業を頑張ってやっていると。
例えば、インターナショナルなカンファレンスにいくと… 会社に対してレポートを出すのは一緒なのですが、
アメリカ:何枚か写真張ってちょっとキーワード書いて ダン!
→ 2時間位
日本 :出たカンファレンスのビデオを見直して、パワポをちゃんと作って、みんなの前で発表して…
→ 何日もかかった
でもこれって本当にかかった時間分のバリューの差がありますか? って言うと多分ないんですよね。
もう少し開発的よりな例は何かありますか? と懇親会のときに質問させてもらったところ
お客さんに提案するときに
アメリカ:最高の案を一つ
日本 :松竹梅を揃えていく
とのことでした。
「西洋文化」では「いかに少ない作業量でバリューを出せるか」を常に考えられている。
とのことでこちらの本が紹介されていました。
エッセンシャル思考 最少の時間で成果を最大にする【電子書籍】[ グレッグ・マキューン ]
- ジャンル: 本・雑誌・コミック > ビジネス・経済・就職 > 経営 > 経営学
- ショップ: 楽天Kobo電子書籍ストア
- 価格: 1,728円
セッションの終わりには、ブログをリアルタイム公開。
「それ、アジャイルできてないんちゃいますか」
http://simplearchitect.hatenablog.com/entry/2016/09/24/113117
これを昼休みに読んでたら、今進めてる案件に対して思うことがふつふつと…
「1.2. 進化型設計」から
ビックバンリリースを避けたかったのに、今の計画だとビックバンリリースになってしまっている
(しかも終わらなそうな感じ…)
途中でスコープを広げないといけないことに気づいたんだけど、
その際に、「ファーストリリースのサイズを保ったままできないか?」ということに気づけなかった。
「2. ビルドが中心になっていない」から
デイリーでビルド&デプロイ&簡易E2Eテスト のようなことをしたかったんだけど、
いつまでたってもできていない。
わりと初期の段階で、完全でなくても動いてデモができる状態にしていたのに、
それを以降継続できていない。
気づきが得られてよかったのですが無性に悔しくて悲しくなってしまいました。
自ら学ぶ力をチームに取り入れるワークショップ (川鯉 光起さん、高柳 謙さん、新井 剛さん)
午後参加させてもらったワークショップ。
こちらの本の一年間の読書会を経て、内容を紹介したいという思いで開かれたとのこと。
- ジャンル: 本・雑誌・コミック > 人文・地歴・哲学・社会 > 教育・福祉 > 教育心理
- ショップ: 楽天ブックス
- 価格: 2,268円
知識構成ジグソー法 という手法を体験するセッションでした。
3人の組で「チームの学びを促すためには何をしますか?」ということについて考えるのがお題。
まず、3人がそれぞれ、別々の3人のエキスパートから話を聞きました。
そちらでもちょうど3人ずつの組みができたため、エキスパートと、参加者3人の4人で、話を聞いたり質問したり。
終わると、元の席に戻り、今度は自分が聞いてきた話をメンバーに紹介。一通り聴いた上で、チームとしてお題に対する結論を出していきました。
私達のチームから出た結論は
・チーム内でお互いに学び合える関係づくりが大事だよね
と言うもの。
(だけじゃなかったけど。これが一番印象深かった)
チームなので経験がある人もいればない人もいる。でもみんなそれぞれ強みを持っているはずで、うまくそれが相互作用するチームにしていきたいなぁと思いました。
LT
楽しみにしていたLTコーナー!
過去2年は参加させてもらったのですが、今年は聴きにまわらせてもらいました…!
が やっぱり何か話したかったなー。
最近はインプットもアウトプットも足りてないので意図的にやっていかないとですね。
LTですが、ぐっと来たのは伊藤宏之さんの、海外カンファレンスにキーノートとして招待された話。
思えば、自分がXP祭りに毎年参加するようになったのとか、挙句LTやらせてもらったりとかって、
2012年にふらっと参加したときに(多分facebookかなんかで誰かが参加しているのを見て、面白そうだなーと途中から飛び入りで行った記憶が)、
伊藤さんのAgileConferenceに行ってきたって言う野良LTを聴いて
「俺は英語でヒーヒー行ってるのに何だこの人! 行動力ハンパねぇ」
って思ったのがきっかけだったと思います。
それから偶然知り合いにならせてもらって一緒に仕事させてもらったり何だり。
そこから4年で、今度はキーノートで話してきたとかいう話で、ほんと突っ走ってるなぁこの人と思った次第です。
こういう方の話を聞くと刺激になりますね! ネガティブなこと言ってる場合じゃない。
レガシーコードを JDK 8 でビルドしようとしたら "The system is out of resources" が出た話
今までJDK7でビルドされていたJavaプログラムをJDK8でビルドしようとしたところ、コンパイル時にこんなエラーが出ました。
The system is out of resources. Consult the following stack trace for details. java.lang.StackOverflowError at com.sun.tools.javac.code.Type.hasTag(Type.java:112) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1967) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955) at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786) at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571) at com.sun.tools.javac.code.Types.asSuper(Types.java:1952) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1968) at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955) at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786) at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571) at com.sun.tools.javac.code.Types.asSuper(Types.java:1952) at com.sun.tools.javac.code.Types.unboxedType(Types.java:3987) at com.sun.tools.javac.code.Types.unboxedTypeOrType(Types.java:3998) at com.sun.tools.javac.comp.DeferredAttr$ArgumentExpressionKind.standaloneKind(DeferredAttr.java:1135) at com.sun.tools.javac.comp.DeferredAttr$DeferredChecker.visitLiteral(DeferredAttr.java:1296) at com.sun.tools.javac.tree.JCTree$JCLiteral.accept(JCTree.java:2037) at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) at com.sun.tools.javac.comp.DeferredAttr$FilterScanner.scan(DeferredAttr.java:913) at com.sun.tools.javac.comp.DeferredAttr.isDeferred(DeferredAttr.java:1100) at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:660) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1806) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566) at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226) at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566) at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226) at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815) at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465) (以降、繰り返し)
事象
・チームで使っているJenkinsと私のマシンのローカルだと本事象が発生
・他の2人に、ローカルでビルドを試してもらったら正常ビルドできた
mavenビルド時にjavacのログを出す方法を見つけたので試してみる。
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.8</source> <target>1.8</target> <compilerArguments> <verbose/> </compilerArguments> </configuration> </plugin>
[checking xx.xx.xxxxx.xxxxx.xxxx..XxxxxXxxxxxXxxxx] The system is out of resources. Consult the following stack trace for details. java.lang.StackOverflowError at com.sun.tools.javac.comp.Resolve.findIdent(Resolve.java:2104)
数回試したけど毎回同じクラスで落ちてる!
で、そのクラスを覗いてみると…
private static String SQL = new StringBuilder().append(LINE).append( "SELECT XXXXXXXX ").append(LINE).append( " , XXXXXXXXXXXXXXXX").append(LINE).append( " , XXXXXXXXXXXXXXXX").append(LINE).append( " , XXXXXXXXXX ").append(LINE).append( " , XXXXXXXX ").append(LINE).append( " , XXXXXXXXXXXX ").append(LINE).append( " , XXXXXXXXXX ").append(LINE).append( " , XXXXXXX ").append(LINE).append(
※以降、400行ほど続く
800を超えるappendによって作られた超巨大SQL。
こいつはくせえッー!ゲロ以下のにおいがプンプンするぜッーーーーッ!!
試しにごそっと削ってみたら…
private static String SQL = "";
あっさりビルドが通りました。
Java Day Tokyo 2016 参加レポート2 マイクロサービスについて #javadaytokyo
今回のもう一つの参加目的、
「マイクロサービスの実践例と、支援するようなJavaのアーキテクチャについて」です。
モジュールによるマイクロサービス?
はじめに、「1-A Java SE 9 Overview」より。
Project jigsaw によるModulanizeの目的の一つは、「開発者が、マイクロサービスなアプリケーションを開発できるようにする」「デプロイできるようにする」ことだと話されていました。
(通訳と俺の日本語聞き取りが間違ってなければ)
これって、モジュールのjar単位でデプロイしていく運用を想定されてるのでしょうか。
ちょっと「俺の知ってるマイクロサービスと違う」感があるのですが、必要な(Javaで言うところの)APIだけが適切にexportsされているのであれば、安全にモジュールの差し替えも可能なのかな…
DDLをとっかえてるみたいでおっかないのですけど。
実践して分かったJavaマイクロサービス開発
続いて、谷本心氏による発表「実践して分かったJavaマイクロサービス開発」より。
実在する、レガシーでモノリシックなECサイトをマイクロサービスに解体していった体験記でした。
セッションの内容自体は後で資料公開されるそうなのでそちらを見ていただくとして、セッション中に出てきた、衝撃を受けた言葉を衝撃を受けた順にご紹介したいと思います。
アクセサとコントローラで共通のInterface(Javaの)を実装した話
Client側サービスのItemAccesssorクラスが、Itemサービスを呼び、ItemControllerクラスが起動するような仕組みの時に、
ItemAcessorクラスとItemControllerクラス双方に、ItemServiceというインタフェースを実装するようにした という話。
良かったこと
・依存がIDEのHierarchy検索で簡単に探せる
・おなじIFなのでコントローラをDIするとサービス間の結合テストがJunitでできる!(なにこれすごい)
これ、おもしろい工夫だし実用的なのですが、
マイクロサービスのメリットの一つである、Polyglot(多言語性)完全に捨てる話で、すごい割り切りだなと思いました。
谷本さん曰く
「各サービス基盤が標準化されている方にメリットが有る」とのこと。
確かに、マイクロサービス化してサービスの数が増えたところで、いちいち選択言語は変えないでしょうから、Javaで統一する、と割りきった設計にするのは一理ありますね。
そしてその場合、Modelのクラスはなんとなく一緒のものを使いそうですが、アクセサとコントローラで同じIFを実装する、と言うのは考えたことがありませんでした。
AWSを使ってないとマイクロサービスのメリットが引き出しにくい
特にスケーリングについて言及されてました。高負荷の際にすぐにスケールできるような状況でなければマイクロサービスのメリットが得にくいのではないか、と。
私自身はマイクロサービスのメリットは、各サービスごとの凝縮度を上げる&サービス間の結合度を下げる ことで得られるメンテナンス性の高さが最大のメリットだと思っているので、クラウドでなければ意味が無い とまではいかないと思いますが、スケーリングし易い という恩恵は確かに受けずらいですね。
どうしてもAPIの設計が画面に引きずられる
その結果、APIは再利用性が低いものに。
結果、「フロントサービス」と「ドメインサービス」が分割され、「フロントサービス」が「ドメインサービス」を必要に応じて呼ぶようになった。
来た! これはまさにここ最近私も悩み続けていた点で、とりあえず落ち着いた結論もほぼ同じ感じ。
RESTfulなマイクロサービスを作ろうとすると、画面に必要なロジックがどうしてもどこかに必要になるんですよね。
Java Day Tokyo 2016 参加レポート1 今後のJavaの動向、特にJava9について #javadaytokyo
3年ぶりにJavaDayTokyoに参加しました。
今回の自分のテーマは2つ
・今後のJavaの動向、特にJava9について
・マイクロサービスの実践例と、支援するようなJavaのアーキテクチャについて
前者については、Java8導入直前にSan FranciscoでのJavaOneに参加させてもらった時に感じた、以下の気付きによります。
「いざ導入となった時にその素晴らしさを理解し、メンバー全員で使い始めるには、ある程度の事前知識を、自分はもちろん、メンバー皆が持っていることで、導入のハードルを下げることができるだろう」
http://taichiw.hatenablog.com/entry/2013/10/01/065607
(とは言え、いろんな外的要因があって、実際に自分のチームでJava8を使いはじめるまで2年はかかりましたが…)
後者については、今まさに日々、サービスの切り方やら作り方やらについて悩んでいるところなので、なにかヒントがあればなーという思いでした。
この記事では前者、「今後のJavaの動向、特にJava9について」に関わるところをご紹介したいと思います。
Cloud
Keynote および 「1-A Java SE 9 Overview」を聞いて、「クラウド」を非常に意識していると感じました。
Java9、及び今後Javaが注力することとして挙げられていたことの多くが、クラウドでの利用へ繋がっているようでした。
・セキュリティ
→ クラウド上で動かすならセキュリティが重要である
Java9での実装としては、モジュール化による隠蔽があたる。PublicがPublic過ぎる問題を解決。
・Density(密度)
必要なもののみを含むアプリケーションの動作。
→ メモリフットプリントを削減。クラウド上では数%の効率化が、何万ドルものコスト削減に繋がる。
Java9での実装は同じくProject Jigsaw関連。Javaのランタイムコアrt.jarが小さなモジュールに解体され、必要な物だけ使用してアプリを作ることができるようになった。
また、jlink(http://openjdk.java.net/jeps/282)により、Custmoized JREを作成可能。実行に必要な機能だけ揃えた、小さなJREを作ることができる。
・Start upの速度
クラウドにおいて、プロビジョニングが高速になったのでJVMの起動がボトルネックになっている。
コンテナが数ミリ秒で作られるのに、JVMの起動に数百ミリ秒かかってしまっている。
などなど。
Project Jigsaw Module
Java9の目玉であるModuleについては、「A-2 Project Jigsawではじめるモジュール開発」で櫻庭さんが丁寧に背景、作り方、使い方を説明してくださいました。
実は、昨日の夜、「予習しとかんと明日絶対ヤバイ!」と思ってProject Jigsawでググッて出てきた記事が、まさに今櫻庭さんがItproに連載されているもので
http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/040500010/?ST=upper
http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/042000011/?ST=upper
http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/050900012/?ST=upper
セッションの内容はかなり「これゼミに出てたところだ!」的でしたw
モジュールごとに内部APIを隠蔽できる考え方はとても良いのですが、
・そもそもマイクロサービス化が進んでいるので、1アプリケーションに含まれるクラスは減りつつある
・一方、周りを見れば(自分も含めて)残念ながら今のクラスやメソッドのpublic/privateすらちゃんと考えられてるのか怪しい
背景を考えると、これそこまでちゃんと使われるのかなぁ… と思ったり。
一部、Mavenのようなパッケージ管理ツールの代わりの機能になりそうですが、完全に置き換えられるものでもないですし…。
正直なところ
Java8のLambdaがパラダイムシフトすぎたので比較すると、ではありますが、
言語仕様的には「是非Java9を使いたい」、とはまだ思えてないのが正直なところでした。
パフォーマンス面を中心に攻めているようなので、こちらの効果に期待ですが、あまり現在のプロダクトでは困ってるところではないんですよね。
自分の理解が追いついていないところも激しくあると思うので、今日をきっかけに今後も情報をキャッチアップしていきます。
いずれにしても(一夜漬けとはいえ)予習して、最新の話が聞けて、とても良い日でした。
Baseball Play Study で話させていただきました! #bpstudy
IntelliJ IDEAハンズオンに参加しました #ideahandson #jbugj
サムライズムさん開催の、IntelliJ IDEAハンズオンに参加してきました。
今月はあと一回、3月24日にも開催されるようです。
開催予定イベント一覧 - 株式会社サムライズム | Doorkeeper
まとめも兼ねて、特に「へー!」と思ったものをご紹介させていただきます。(使ってる人には常識なことなのかも…)
Shift2回押しの検索が強力
今までClass検索くらいにしか使っていなかったのですが、もっと「なんでも検索できる」機能です。
例えば、エディタの行番号表示はどこでONにすれば… というとき。
"line number"などで検索すると…
その場でON/OFFの切り替えまでできちゃうよ!
また、キーワードの一致もとても柔軟。
「Get"なんとか”Timelineクラス」を探したいんだけど…という時は
さらに『ght』でもGetHomeTimelineクラスが探せる!
Live Templates と Postfix Completionが楽しい!
psvm と打って tab で public static void main(String[] args) メソッドが。
sout と打って tab で System.out.println() が自動的に入力されます。
さらに、
あー 左に戻って返り値用の変数宣言しないと… というとき。
末尾に.varとつけてtabで…
↓
宣言を自動補完!
同様に、
コレクションに .for と打てば for文が、
booleanに .if と打てばif文が自動的に生成されます。
Live Template, Postfix Completion ともに、非常に多くのものがデフォルトで登録されている上、独自のカスタマイズも可能です。
「巻き戻せるデバッガ」Chronon
デバッガを使ったデバッグをしている時に、「あー 行き過ぎたー!!」という経験、ありますよね。
そこでStep overどころかStep backwardを提供してくれるプラグイン、Chrononです。
IntelliJ IDEA 13.1 EAPのChronon Debuggerをお試しください! | JetBrains ブログ
本来は有償ツールですが、IntelliJ IDEAのUltimateを使っている場合は無償で利用可能とのこと。
普通のデバッガも強力
標準で付属しているデバッガも強力です。
ぱっと見わかりづらいのですがこの「電卓」ボタンを押すと起動できるEvaluater.
単に変数の現在値を確認するだけでなく、例えば.toString()をつけてみるなどの評価「式」が記述可能。
さらに、= で代入文を書けば、変数値を任意の値に変更することも可能です。
おまけ:「保存」がない
IntelliJ IDEAは常にオートセーブのため、ほかのテキストエディタにあるような「保存」機能がないそう。
今までなんとなくCtrl+Sを打っていたのですが意味がなかったのですね…。
jshellを使ってみた
ちょっとしたプログラミングに、jshellを使ってみました。
jshellとは、Java9から導入される、簡易実行環境。REPLっていうらしい。Rubyでいうirbに相当します。
使ってみた感想。
良いところ
・ワンラインサクッと書いて動かせるのは便利。自分は未だにJava8のStreamAPIとかLocalDateとかうまく書けないので、一行単位でいろいろ試せるのはよかった
・/openコマンドで、ファイルに書き出してあるスクリプトが読み込めるので、スクリプト言語のような実行の仕方ができる。
使いにくいと思ったところ
・importが大変。IDEじゃなくて適当なテキストエディタで書いていたのだけど、いちいちパッケージを調べないといけない。
・/openコマンドで100行くらいのものを読むと、エラーがどこで起こっているのかわかりにくい。エラーの行番号が出ない。クラスを作り始めるともうわけわからん。
・jshellに限らず他のREPLもそうみたいなんだけど、メソッドチェーンを書きたければ改行前にドットを打たないとシンタックスエラーになる
などなどありまして、1-2行を試すのはいいけれど、100行くらいのものを動かしたかったら、おとなしくIDE使って書いて、junitでキックするなり、普通にmainメソッド作るなりして動かしたほうがいいのかなぁと思いました。
全然いいコードじゃないけどこんな感じ
https://github.com/taichiw/baseball/blob/master/201603pitcher/makecalendar.java