読者です 読者をやめる 読者になる 読者になる

エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

チームのKPTをちょっとだけ深堀すること

ふりかえりの手法としてKPTはメジャーな方法の一つだと思います。

私がチームでふりかえりする際に、ファシリテータとして少しだけ気を使っている事があります。

KやPは少しだけ掘り下げる

メンバーに意見を挙げてもらうときに、「うすい」意見が出ることが、どうしてもあります。

  • XXが予定通りリースできてよかった
  • YYが難しかった

これだとあまり話が広がらないため、このような意見が出たときは、出してくれた人に問いかけるようにしています。

 

「予定通りリリース亅なら、

「それができた要因ってなんですか?」「どんなところを頑張りました?」

 

「難しい」なら、「どうしてそう感じました?」「何が難しさの原因でした? スキル不足か、知識不足か、周りのせいか…」

 

と、単なる事象の共有だけでなく、その背景にある理由を挙げてもらえるようにします。

挙げてもらったものが、またまた単なる事象の共有の場合もありますので、その際はさらに「その原因は?」ときくようにしています。(いわゆる『ツメている』状況にならない程度に。ここの見極めが難しい)

 

KとPはスコープを広めに

毎回ではないのですがKPTを始める際の枕詞がありまして、

「このスプリントで良かった(or あんまり良くなかった)ことを挙げてください。『自分のこと、チームのこと、プロダクトのこと、環境のこと、何でもいいです』」と言っています。

特に、最後の環境の要因で問題が発生している場合を個人的には重視しています。当人はどうにもならないと思っていても、意外と他の人が聞いたらどうにかなるケースもあり、とりあえず挙げてもらうことが大事だと思っています。

例えば、

PCのスペックが低すぎるとその人は感じているけど変えられないと思っていた。→実は申請すればもっとハイスペックなマシンが使える

的な。

(どうにもならないことも多いので、その際は共感だけして終了です… が、その思いをみんなで共有できる事にも意義はあると思います。)

 

Pを挙げるときにTを考えない

Pを考える際、いきなり解決方法を出してしまうケース多いですよね。

「三回遅刻しました。次から目覚し時計を増やします。」

それで解決できるならいいのですが、何か問題が発生している場合、本人が思いついたTryでは解決できないので問題になっているケースが多いのではないでしょうか。

まず、「遅刻した」と言うのはただの事象なので、先程挙げたとおり、根本的な理由を見つけたいところです。

  • 本人が単に夜更かしして遊んでいたのか
  • 仕事量が多すぎて毎日帰宅が遅いのか
  • 何か心配事があってよく眠れていないのか
  • そもそも遅刻って問題なの?うちフレックス制じゃなかったっけ?

いきなりTryに行ってしまうと、このようにProblemを掘り下げることが難しくなります。

そのため、KやPとを考える時間と、Tを考える時間は分けたほうがいいと思います。

【裏話】チームとプロダクトをぶっ壊した話 の 裏側 #DevLOVE

DevLOVEに初めて参加させていただき、初参加にも関わらず登壇させていただきました。

www.slideshare.net


今回こちらを発表させて頂くにあたっても、色々と「越境」したことや思ったことがありましたので、忘れないうちに書き溜めておこうと思います。

メンバーに感謝

発表内容は「どうだ、僕、すげーリーダーだろ!?」というような内容になってしまっていますが、本当の主役は一緒に頑張ってくださったメンバーの皆さんだと思っています。
はてブのコメントに、
f:id:taichiw:20170130005005p:plain
というものがありました。本当にその通りだと思います。

本来お一人お一人に事前に話を通すべき所、ダマで発表のような形になってしまったのは私が「越境」できてない所で申し訳なく思います。
…とはいえ 「どや、お前のリーダーできるやつだろ?」みたいな発表を時間を割いて聴いてもらうのも気が引けたのでできなかったのですが…。
「俺達いいチームだろ!?」的な内容にもっていけばよかったですね。いまさら気がつきました。

もう一点。発表の構成上、どうしても、以前の状態は「間違い」であったような書き方になりました。ただ、何が「良いチーム・良いプロダクト」かは、その時その時の状況によって大きく変わると思います。また、何が「最優先か」も、その時点その時点で大きく変わると思います。

正直に言えば、過去を「敵」とみなして自信のモチベーションを上げることはしてきましたし、今もしています。

しかしながら、私がこんなにドヤ顔で、“してやったり”的な発表ができるのも、それ以前のチーム・プロダクトの歴史があるからこそ。私が取り組んだ箇所とは別の箇所に対して、それまでの人が必死に取り組んできてくださった結果だと思います。

レビューしてくださった皆さんに感謝

元々今回の発表のモチベーションが、「ここ2年間頑張ってきたことをまとめて、何なら俺スゲーアピールをしたい」というものだったので、一週間前に資料の初版ができた際は、本当にただただやったことを書き連ねただけのものでした。
篭ってるメッセージも、「こんなにひどい状況だったけど変えてやったぜ!」程度で、レビューしてくださった弊社広報部からも、「全体的にネガティブ」とコメントをいただくほどでした。

そんな中、今回基調講演をした及部くんから
f:id:taichiw:20170130005935p:plain
というコメントを貰って。

そう言われてみると俺、何で辛いと思いながらも続けてきたんだろう…

と思いながら過去の日記などを漁った所、今回の発表冒頭で使ったエピソードが見つかりました。

更に発表前日。上長に(今更)内容を確認してもらった所、
「何を伝えたいのか。伝えたい事が『事例共有』ではふわっとしすぎているので一つに絞ったほうがいい」
という問いかけをいただき、“One team”を作って行った事をメッセージの核とすることを引き出していただきました。

ここが大きなターニングポイントで、結局今回の資料、その後の6時間ほどでほぼ全部作り直しました。
それまでは資料も字ばかりで「前はもっといい感じなビジュアルなのが作れてたはずなのになー なんでかなー」と思っていたのですが、テーマが明確になった瞬間に急にイメージが頭に湧いてきて、(元と比べれば)それなりにビジュアルで訴える資料になったのではないかと思います。


日記は面倒だが役に立つ

私、毎日ではないのですが、あとからふりかえりができるように、日記をつけています。

とはいっても、非常にものぐさでまともな日記なんて書けないので、「ひとりKPT」的なものを会社の社内ブログに書きなぐって終わりです。

例ですがこんな感じ。

20170129
K: 発表の裏側のブログが書けた。忘れないうちに思ったことを書き残せてよかった
P: 内容がチラシの裏すぎる。 書くのに時間がかかる。改善したいけどどうしたらいいんだろう…
T: ブログを早く書く方法って 昔何かで読んだ気がするのでもう一度読んでみようかな…。

人に見せるものでもないので、本当に書きなぐりです。
ただ今回、この書きなぐりが非常に役に立ちました。
人間、「この2年間苦労してきた。まとめて発表したい!」と常日頃思っていても、やっぱり2年間のエピソードなんて忘れているものですね。読み返したことで思い出したことが多く、今回の発表を作っていく上で貴重な資料、と言うか思い出すきっかけになりました。

実はちゃんと書いている日よりもサボっている日のほうがずっと多いのですが… 日々書き留めることの大切さを改めて実感しました。

発表当日の服装で「越境」

www.slideshare.net
勢いでやった懇親会LTより。
ごちゃごちゃグダグダ言っていますが、好きなものはひと目を気にせず好きだと思っていればいいですね。

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時間位
日本  :出たカンファレンスのビデオを見直して、パワポをちゃんと作って、みんなの前で発表して…
 → 何日もかかった

でもこれって本当にかかった時間分のバリューの差がありますか? って言うと多分ないんですよね。 

もう少し開発的よりな例は何かありますか? と懇親会のときに質問させてもらったところ

お客さんに提案するときに

アメリカ:最高の案を一つ
日本  :松竹梅を揃えていく

とのことでした。


「西洋文化」では「いかに少ない作業量でバリューを出せるか」を常に考えられている。
とのことでこちらの本が紹介されていました。



セッションの終わりには、ブログをリアルタイム公開。
「それ、アジャイルできてないんちゃいますか」
http://simplearchitect.hatenablog.com/entry/2016/09/24/113117

これを昼休みに読んでたら、今進めてる案件に対して思うことがふつふつと…
「1.2. 進化型設計」から
ビックバンリリースを避けたかったのに、今の計画だとビックバンリリースになってしまっている
(しかも終わらなそうな感じ…)

途中でスコープを広げないといけないことに気づいたんだけど、
その際に、「ファーストリリースのサイズを保ったままできないか?」ということに気づけなかった。


「2. ビルドが中心になっていない」から
デイリーでビルド&デプロイ&簡易E2Eテスト のようなことをしたかったんだけど、
いつまでたってもできていない。

わりと初期の段階で、完全でなくても動いてデモができる状態にしていたのに、
それを以降継続できていない。


気づきが得られてよかったのですが無性に悔しくて悲しくなってしまいました。

自ら学ぶ力をチームに取り入れるワークショップ (川鯉 光起さん、高柳 謙さん、新井 剛さん)

午後参加させてもらったワークショップ。

こちらの本の一年間の読書会を経て、内容を紹介したいという思いで開かれたとのこと。

知識構成ジグソー法 という手法を体験するセッションでした。

3人の組で「チームの学びを促すためには何をしますか?」ということについて考えるのがお題。

まず、3人がそれぞれ、別々の3人のエキスパートから話を聞きました。
そちらでもちょうど3人ずつの組みができたため、エキスパートと、参加者3人の4人で、話を聞いたり質問したり。

終わると、元の席に戻り、今度は自分が聞いてきた話をメンバーに紹介。一通り聴いた上で、チームとしてお題に対する結論を出していきました。

f:id:taichiw:20160924163238j:plain
私達のチームから出た結論は
・チーム内でお互いに学び合える関係づくりが大事だよね
と言うもの。
(だけじゃなかったけど。これが一番印象深かった)


f:id:taichiw:20160924163212j:plain
チームなので経験がある人もいればない人もいる。でもみんなそれぞれ強みを持っているはずで、うまくそれが相互作用するチームにしていきたいなぁと思いました。

LT

楽しみにしていたLTコーナー!
過去2年は参加させてもらったのですが、今年は聴きにまわらせてもらいました…!

が やっぱり何か話したかったなー。

最近はインプットもアウトプットも足りてないので意図的にやっていかないとですね。


LTですが、ぐっと来たのは伊藤宏之さんの、海外カンファレンスにキーノートとして招待された話。

www.slideshare.net
思えば、自分がXP祭りに毎年参加するようになったのとか、挙句LTやらせてもらったりとかって、

2012年にふらっと参加したときに(多分facebookかなんかで誰かが参加しているのを見て、面白そうだなーと途中から飛び入りで行った記憶が)、
伊藤さんのAgileConferenceに行ってきたって言う野良LTを聴いて
「俺は英語でヒーヒー行ってるのに何だこの人! 行動力ハンパねぇ」
って思ったのがきっかけだったと思います。

それから偶然知り合いにならせてもらって一緒に仕事させてもらったり何だり。

そこから4年で、今度はキーノートで話してきたとかいう話で、ほんと突っ走ってるなぁこの人と思った次第です。
こういう方の話を聞くと刺激になりますね! ネガティブなこと言ってる場合じゃない。

レガシーコードを JDK 8 でビルドしようとしたら "The system is out of resources" が出た話

Java

今まで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>

http://stackoverflow.com/questions/2210005/config-maven-2-to-print-out-javac-commands-during-compile-phase

[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 JavaDayTokyo2016

今回のもう一つの参加目的、

「マイクロサービスの実践例と、支援するような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

Java JavaDayTokyo2016

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

昨年に続いて今年もLTさせていただきました。


去年話せてもらった頃はLTそのものに対する慣れが相当あったのですが、どうもここ最近は人前で話すことからご無沙汰気味…

技術的な話は、先日jshellの記事として記載したものです。