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

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

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

昨年に続いて今年もLTさせていただきました。
 
 
去年話せてもらった頃はLTそのものに対する慣れが相当あったのですが、どうもここ最近は人前で話すことからご無沙汰気味…
 
技術的な話は、先日jshellの記事として記載したものです。

IntelliJ IDEAハンズオンに参加しました #ideahandson #jbugj

サムライズムさん開催の、IntelliJ IDEAハンズオンに参加してきました。

今月はあと一回、3月24日にも開催されるようです。
開催予定イベント一覧 - 株式会社サムライズム | Doorkeeper

 

まとめも兼ねて、特に「へー!」と思ったものをご紹介させていただきます。(使ってる人には常識なことなのかも…)

 

Shift2回押しの検索が強力

今までClass検索くらいにしか使っていなかったのですが、もっと「なんでも検索できる」機能です。

例えば、エディタの行番号表示はどこでONにすれば… というとき。

"line number"などで検索すると…

f:id:taichiw:20160312222349p:plain

その場でON/OFFの切り替えまでできちゃうよ!

 

また、キーワードの一致もとても柔軟。

「Get"なんとか”Timelineクラス」を探したいんだけど…という時は

f:id:taichiw:20160312222743p:plain

さらに『ght』でもGetHomeTimelineクラスが探せる!

f:id:taichiw:20160312222817p:plain

 

Live Templates と Postfix Completionが楽しい!

psvm と打って tab で public static void main(String[] args) メソッドが。

sout と打って tab で System.out.println() が自動的に入力されます。

 

さらに、

f:id:taichiw:20160312223224p:plain

あー 左に戻って返り値用の変数宣言しないと… というとき。

末尾に.varとつけてtabで…

f:id:taichiw:20160312223528p:plain

f:id:taichiw:20160312223443p:plain

宣言を自動補完!

 

同様に、
コレクションに .for と打てば for文が、
booleanに .if と打てばif文が自動的に生成されます。

 

Live Template, Postfix Completion ともに、非常に多くのものがデフォルトで登録されている上、独自のカスタマイズも可能です。

f:id:taichiw:20160312223906p:plain

f:id:taichiw:20160312223916p:plain

 

「巻き戻せるデバッガ」Chronon

デバッガを使ったデバッグをしている時に、「あー 行き過ぎたー!!」という経験、ありますよね。

そこでStep overどころかStep backwardを提供してくれるプラグイン、Chrononです。

IntelliJ IDEA 13.1 EAPのChronon Debuggerをお試しください! | JetBrains ブログ

本来は有償ツールですが、IntelliJ IDEAのUltimateを使っている場合は無償で利用可能とのこと。

 

普通のデバッガも強力

標準で付属しているデバッガも強力です。

ぱっと見わかりづらいのですがこの「電卓」ボタンを押すと起動できるEvaluater.

f:id:taichiw:20160312224729p:plain

単に変数の現在値を確認するだけでなく、例えば.toString()をつけてみるなどの評価「式」が記述可能。

さらに、= で代入文を書けば、変数値を任意の値に変更することも可能です。

 

おまけ:「保存」がない

IntelliJ IDEAは常にオートセーブのため、ほかのテキストエディタにあるような「保存」機能がないそう。

今までなんとなくCtrl+Sを打っていたのですが意味がなかったのですね…。

 

 

 

jshellを使ってみた

ちょっとしたプログラミングに、jshellを使ってみました。

jshellとは、Java9から導入される、簡易実行環境。REPLっていうらしい。Rubyでいうirbに相当します。


jshell JDK 9 quick peek

 

使ってみた感想。

良いところ

・ワンラインサクッと書いて動かせるのは便利。自分は未だに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

XP祭りに参加してきました 2 LTした/LT聞いた #xpjug

俺も!LT

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

自分の中では痛恨の失敗作…
言いたいことを一つにまとめられていないのがずっと不安だったのですが、案の定、伝えたい事がうまく伝えられなかったのかな という感触です。

言いたかったこと

  • E2Eテストを作りこんで、リグレッション0にした (自動テストの話)
  • E2Eテストを作るのをフローにしたら、メンバーの意識が変わってきた (チームビルディングの話)
  • GUI作るチームに移って困ってる。誰か助けて (ヘルプがほしい話)

自分の中で本当に話したかったところはチームビルディングの話、しかも自分の中では、「エンジニアである自分」と「管理職である自分」が融合した瞬間だった という話なのですが、XP祭だしあんまりチームビルディングよりな話するのも微妙かなぁ… ということで、先ほどの「~融合した」みたいな話には触れず、自動テスト寄りにしてしまった結果、中途半端な話で終わってしまった感がありました。

 

そして! この後の方々のLTを聞いて、「LTとはこうであろう」というものをまざまざと突きつけられたのです。

ネタに走る必要はなかったけど言いたいことだけ詰め込んでもしょうがないなぁ… っていう、去年も思ったことをまたやってしまった。

修行不足ですね。

みんなのLT

まさかの一番バッターだったので、自分のが終わったあとは存分に皆さんの発表を楽しませていただきました!

f:id:taichiw:20150914003841j:plain


ぐっと来たものを紹介させていただきます!

スクラムマスター2ヶ月生がチームの自己組織化に挑戦して:川鯉 光起さん

奮闘記。「お試し期間」って話が出てきて、すげえわかるなー!って思いました。

私も新しいことをチームでやりたい時、「2週間だけやらせてください! ふりかえりの時にどうだった?って聞くから気に入らなかったらその時言って欲しい」 って何度かやったことがある。

 

タイトルからぶっ放しすぎだし、「これぞLT」を見せつけられたLTでした。

 

すごく良い発表でした。まさかの「総務」話。

KPTを使ったふりかえりで、どんどん良くなっていったっていう話。アジャイルプラクティスは開発以外にも使える。

発表者の方が、「細かいことは覚えていない → これってカイゼンが日常化しきたってこと」って言われていたのも印象的でした。

今は当たり前のようにやってることが、ふと振り返るとカイゼンの中で生まれてきたことで、ちょっと前までは全然やってなかったこと… って言うの、私も経験あります。

 

正のループと負のループが8の字になって… という話。

テストのコストが増えて云々の、負のループが表面化してくるところとか、そこからどうするのか!? とかすげー気になる…! のだけど懇親会いけなかったので話せず。

是非続き聞きたい。

 

てらひでさん 

デイリースクラムで、

昨日◯◯やりました → 今日も◯◯やります → 特に困っていることはないです

みたいな流れになって困るので(すげーわかる!)

昨日やってること → その中で困っていること → 今日やること

の順番で話してください! って言った話。

カイゼンネタのストックとしていただきました。ここぞというタイミングでこれ使ってみたい。

 

 

 

…ということで。

自分のLTの失敗も含めて、学ばなければいけないことが大量にあることに気付かされた一日でした。

 

前夜、緊急の深夜メンテで、果たして行けるのか!?という状況だったのですが、会社で3時間仮眠してから(会議室はなかなか快適でした)の強行参加、してよかった!

XP祭り2015 に参加してきました 1 (講演・ワークショップ) #xpjug

今年もXP祭りに参加させていただきました!

http://xpjug.com/xp2015/

 

7月まで仕事もプライベートもバタバタだったのもあって、久しぶりにまともな勉強会に参加した感じ。

たくさん刺激を頂きました。

基調講演

角さんの基調講演。

一番ググっときたのはこれ。

TDD - ときめき駆動開発!
語呂が良かったからか、このあと一日バズワードみたいになっていましたが、ここにこんまり先生のトキメキという言葉を持ってきたのすごい。
 
このスライドで上がっている、「プラクティスの選定」にしても、ときめくかどうかって非常に重要だと思うんですよね。何かしらの課題を抱えていて、それを解決してくれるかもしれないものに出会った瞬間にときめく!はずなので。
 
ときめきっていう言葉の選定にときめきました。
 
ところで、「エクストリームプログラミング」。昨年のXP祭りで これも読まずに何を俺はXP祭りに参加してるのだ… と思って購入したのに(第2版が出る前だったのでAmazonで売ってた古本を購入した)、未だに浅くしか読めてない… 読まないとなぁ…。
 

ワークショップ ”共感”でつながるアジャイルチーム

ゴゴイチはワークショップに参加。裏も気になるものばかりだったのですが、こういうの選ぶあたり、現状で自分の興味が強いところは、チームビルディングとか人と話すとかそういうところなのかなぁ…。

共感コミュニケーション とは、マーシャル・ローゼンバーグ博士によって提案された、相互理解を深め、自分や相手とより繋がるためのコミュニケーション「プロセス」 で、次の4段階のプロセスからなるそうです。

4つのプロセス
1.観察
 ビデオカメラのように事実のみを観察する
2.感情
 自分/相手が感じていること
3.ニーズ
 何を必要としているか
 例えば、イラッとしていたら何か満たされないものがあるのではないか
4.リクエスト
 具体的なお願い。かなわなくてもいいのでしてほしいことをクチに出して言う。

 

今回のワークショップでは、2の感情 と 3のニーズ の部分について行われました。

f:id:taichiw:20150912130229j:plain

左側の「感情」と右側の「ニーズ」を結びつける練習。

例えば

  • 私は基調講演を聞いて「ワクワクした」。なぜなら、「刺激がほしい」というニーズが「満たされた」からだ
  • 私は基調講演を聞いて「ショックを受けた」。なぜなら一部理解できない話があり、「情報や知識がほしい」というニーズが「満たされなかった」からだ

というように、どのように感じているか、という感情から、その感情の元となるニーズを探ることで、自身/相手が欲しているものは何か ということを探っていくことをしました。

一般的に、ポジティブな感情の裏には、なにかニーズが満たされた という事実があり、逆にネガティブな感情の裏には、なにかニーズが満たされなかった という事実があるそうです。

初めは自分自身の感情に対してこれを行い、次に、他の人の話を聞いて、その裏にある感情とニーズを探る という訓練を行いました。

さらに、ふりかえりも、「◯◯と感じた。なぜならば◯◯だからだ。」の形式で行われました。

こういったことは、普段からある程度無意識にやっていると思うのですが、プロセスとして体系立てて学ぶことで、改めて自分の中で手法が整理されると感じました。

NVCの本、アマゾンの書評を見るとなかなか骨のある本のようなのですが、読んでみたいなぁ…

 

ユーザーストーリーマッピング入門

弊社アジャイルコーチ、川口さんのセッション。

川口さんが監訳された『ユーザーストーリーマッピング』について。

スクラムのプロダクトバックログには、
 ・今どこにいるかがわかりにくくなる
 ・チケット間の関連性が見えづらい
 ・長めマイルストーンが見えづらい

などの弱点があり、それを解決する方法としてJeff Patton氏がユーザーストーリーマッピングを考案したという話。

この弱点、私も感じる所あるのですが、何より、ここ数年一緒に仕事をさせていただいている、自分よりベテランな方数名が、こういうことを言われている気がする… というところでググッと惹かれました。

周りの皆さんが読んでいる中、取り掛かれていなかったのですが、読まないとなぁ…

モデリングもしないでXPとは何事だ

モデリングというものをちゃんと勉強したこと無いながら、ここ数年間、ちゃんと勉強したほうがいいんだろうなぁ… と思っている昨今。

モデリングとは?」のような話はなかったので、自分にはちょいハードル高めだったのですが、最近会社でよく先輩から教えられている、「issue driven」な考え方にとても通ずるものがあると感じました。

なにか新しい機能を考える際に、いきなり「方法」にいくのではなく、そもそもの問題から考える流れです。

普段なかなかできていないので、もっとこういう考え方を身に着けていかなくてはと感じました。
そしてモデルそのものも、知識としてもっと知りたい…

 

ということで あの本ちゃんと読まないと とか ここちゃんと勉強しないと とか 自分の不勉強さばかり気になった一日でした。

 

ちょっと辛くなりかけましたが、ちょっと寝ぼけていたところにたくさん刺激を頂いたということで、早速エクストリーム・プログラミングを読み返すところから始めました!

今日は、チーム9人全員で「プライベートメソッドのユニットテストは書くべきなのか? ディスカッションができた」記念日

今日はとても素敵な一日になりました。

私を含めたチームメンバー9人が、一つの技術的な話題に対して30分話し合う会を開けた日。

何より嬉しかったのは、この会そのものが、メンバー間でのやり取りからほぼ自然に出てきたことなんです。

回想:本当に「スモール」だった時期

私の今のチームは総勢9名のチームなのですが、大まかに分けても4種類くらいののサービス(検索から予約、管理画面も。)を担当している、プロダクト的にはかなりマッチョなチームです。

これらのサービスはどれも「似ている」のですが、歴史的にバラバラに作られてきたため、アーキテクチャフレームワーク、コードの思想は全部バラバラです。

以前は、このバラバラなプロダクトを、チーム内でもバラバラに担当がついていて、2~3人の少人数チームが3つ、という状態でした。

「似ている」ものをバラバラに作っているので、同じようなものをお互い作っていたり、同じようなことでお互い困っていたり。
しかも1つ1つに対して、到底足りない人数で必死にサービスを回している。

なんとかこの状況を変えたい、という思いで、少しずつ少しずつ、バラバラだった組織を混ぜ始めました。

初めはデイリースクラムも、振り返りも、3回ばらばらでやっていたのを、ちょっとずつくっつけてみたり、隣のを覗いてもらったり。

お仕事も、少しずつ隣のプロダクトを触ってもらったり、コードレビューしてもらったりしていました。

いい感じで衝突し始める

さて、気づけばすっかり一緒にやるのが当たり前になった我がチームのふりかえりミーティング。一昨日のミーティングでこんな意見が出ました。

ユニットテストで使うライブラリや、書き方を統一したい。人によって違いがあることで、問題が起きた」

キターーーーーーー!!

以前は2~3人でキレイに分担されていたのが、どんどん混ぜこぜににされている昨今。当然こういう衝突は起こりますよね。
解決すべき問題なので、Tryとして、改めてみんなで話し合う場を後日持ちましょう! ということにしていたのですが…

コードレビューでもぶつかる!

その翌日、さらなる『事件』は起こりました。ある案件のコードレビューで、「プライベートメソッドユニットテストは書くべきではない」というレビューがつけられ、これに対してレビューイから「自分は書くべきだと思う」という『反撃』がありました。

おそらく自分がこのチームに来てから、コードレビューで『反撃』を見たのは初めてだったと思います。

これ以外は
「◯◯に直してください」→「直しました」
しか本当に見てこなかったような。

 

ユニットテストについて話し合う場を持ちましょう といっている矢先に こんなホットなトピックが起こったのですから放っておく手はありません。
第一回ユニットテストについて議論する会 という会議依頼を勝手にメンバーに送信。
議題は、「プライベートメソッドユニットテストは書くべきなのか?」です。

みんな意見は持っている

きっと落とし所は見つからないだろうな と思っていたので、今日の私の目標は、とにかくみんなに意見を出してもらって、お互いの考えを知ってもらうことでした。

はじめに、皆さんどっち派ですか?と聞いたところ、ちょうど半々くらいに。いい具合に、コの字型の素敵なソファーのオープンスペースでミーティングしていたので、左と右で別れて座ってもらいました。
とっさの思いつきでしたが、各自の立ち位置が可視化されて(そしてちょっとテレビのバラエティ的なおもしろさもあって)、これは良かったと思います。

f:id:taichiw:20150905022954p:plain

はじめは言い出しっぺの彼に「なぜプライベートメソッドユニットテストを書くべきではないと思うのか」を話してもらいました。
それに対して、「賛成でも反対でもいいけど、彼の言っていることの意味はわかりましたか?」と確認したうえで(+私からちょっと補足したうえで)、意見がある人に、自由に発言してもらいました。

そこからは、賛成も反対もどんどん意見が出る出る。

どうしても声の大きい人と物静かな人がいるので、さり気なく全員一回は話してもらえるようにちょっと振りつつ、皆さんに意見を出してもらうと…

 

・あれ、賛成派も反対派も同じ事言ってない?

・そもそもPrivateメソッドって何よ?

・俺のPrivateメソッドとお前のPrivateメソッドと、サイズが違う…?

・実はPublicとかPrivateとかが問題では無いのでは!?

 

という感じになってきたところで30分終了。もっとまとまらないと思っていたのですが、いい感じで次に繋がるトピックが出たところで終了したのでした。

 

なるべく自分の意見は入れずにファシリテータに徹してたつもりなんですが…

すげー楽しかったなぁ!