Java Fan Meeting 2014 event report.
まえがき
Java Fan Meeting 2014というイベントに参加してきました。
イベントレポートを書きました。かなり殴り書きですが、、、w
ここ2年ほど、サンフランシスコで行われている
JavaOneに参加させて頂き、
その経緯でOracleの寺田さんと繋がって,FBで情報を頂いたので、参加させて頂きました。
また、来週に実施されるJava Day Tokyoやそのハンズオンセッションも参加する予定なので、
その準備運動も兼ね。
今回が初めてとのことですが、
OracleがJavaの若い方向けのイベントを行うというのも面白い試みですね。
(僕は今27歳なので、あんまり若いといっていいのかどうか不明ですが笑)
また、20名程度の小規模な会でしたので、落ち着いて話が聞けました。
コンテンツは、
という構成でした。開始時間も19:30からとやや遅めでしたので、少し短めですかね。
伊藤さんからの挨拶
Java Day Tokyoと同じように、伊藤さんからご挨拶がありました。
若手の小規模イベントながら、こういった方も来てくれるんですね。
ちょっとびっくりしました（いい意味で）
短いお話でしたが、実は少し気になった言葉があります。
「日本には日本のJavaのはやり方がある」
という言葉。どういうことだろうか。気になりました。
寺田さんからJava Day Tokyoに繋がる色々
今回は、若手向けのイベント、初心者歓迎のイベントということもありまして、
Javaの歴史を振り返る所から話がスタートしました。
でも、その前に発表PCのNetBeansが落ちましたwww
一番のハイライトw
最初はJavaの歴史について説明がありました。
僕はここら辺の知識が全くないので、面白かったです。
1990年にJavaがGreen Projectという社内プロジェクトから始まったとか、そんなこともちゃんと知りませんでした。
ごめんなさいw
下記いくつか話の中でピックアップして所感を書いておきます
2011年 SE7
SwingはJava7からメンテナンスモードに入って、JavaFXに移行した。(からSwing使ってないでFX使ってね)
これを聞いて思ったのは、会社のプロダクトでも、
JDKのバージョンがあがってもコードが古いってのはちょこちょこあったなーということ。
JDKのバージョンが上がったとしても、それに合った最適なコードがかけなければバージョンアップの恩恵は完全には受けれないという話。(が頭によぎりました)
Javaの3つのやめましょう
1つ目は同意。同意しかないw
この前の脆弱性の話もありますしね。
2つ目。
議論すればそれだけで記事になりそうなので、細かいことはいいませんが、
これはケースバイケースだとは思う。
お金の話もあるし。
でも、それを鑑みてもGlassFishやWebLogicの方がいいよっていうのはOracleとして当たり前。
3つ目。
Eclipseはたしかに好きではない。特に年一回しかメジャーアップデートしないため、
Java8の対応が他のIDE(NetBeans,IntelliJ)に比べて格段に遅いので、
Java8の色々な機能を試すという点でも候補に上がりようがなかった。
社内勉強会のDEMOは全部IntelliJでやった。勉強会も。
今度の新バージョンで対応はするけど、まだまだ足りない所もきっとある。
Java8が使われだしたら、今までEclipse使っていたのが他のIDEに移る可能性は否めない。
Java8から劇的にコードがかわる
これは本当にそう思う。別に今までのコードが動かなくなる訳ではない。
ただ、スタンダートな書き方、というのがかなり変わる。
Java8ならこう書ける。というのが多い。
(λ式絡みをはじめとして)
ここについていけるかどうかは、Javaのエンジニアとしては一つの分かれ目だと思う。
つか逆パターンですが、Java8からJava使い始めた人が、もし古いバージョン触るってことになったらまじで嫌なんだろーなー
といらぬ妄想
色々なデバイスでJavaが使われるようになる
raspberry piとかね
これは個人的な感想ですが、
Java系のカンファレンス行くと、今のトレンドは組み込み系なのかなーと感じることは多々ある。
そして、今自分はWebサービスしか作ってない。
もっと組み込み系とかにも目を向けて、何か作っていかないと視野が狭まりそう。
ビジネスチャンスを逃しそう。そんな気がする。
今はまだ、組み込み系が爆発的に流行るという所までは来てない。
でも、近い将来、そういったタイミングは必ず来るである事は容易に想像出来る。
下記メモ程度ですが。
- GitHub/StackOverFlowではJavaが一番多い(たしかによくみる)
- Java8でちゃんとコード書けばCPU256個だって使い切れるんだぜ
- 詳細は記載しませんが(Java Day Tokyoで見れます)デモ面白かったです
とかとか。
懇親会
あんまりこういうの行く機会なかったから変な緊張はあったけど、楽しかったです。
後は、やっと寺田さんと直接お話しました。初対面w
大学生でこの話を聞くために北海道から来た方とかなんかもいて、凄いなーと思いました。
応援したくなる。
ちょっと前までは懇親会では、上の人から、色々話しを聞くのが楽しいよなーと思っていたのが、
今では若い人たちと話すのも凄く楽しいです。年をとった証拠だけど、大事なことw
Oracleの新卒の方も結構いらっしゃいました。せっかくだからもう少し話せば良かったな。
Start coding Java8(early access) simple 3 step.
Impressed JavaOne2013
1.download & install Java8(early access)
You can download Java8 early access version from here.
https://jdk8.java.net/download.html
2.choose IDE
You can use NetBeans or IntelliJ for coding by Java8.
Now, Eclipse doesn't support Java8 yet.
NetBeans
http://bits.netbeans.org/dev/nightly/latest/
IntelliJ(Community version is free)
http://www.jetbrains.com/idea/download/
3.(IntteliJ)Using java8 in IDE
Create new project
Add jdk8(Project SDK) you installed.
Here is the default java path(mac).
ls -ltr /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -rwxrwxr-x 1 root wheel 99296 6 14 06:57 /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java
Create Java class.
Let's Cording.
JavaOne2013レポート003-プレゼンスタイルの違い
JavaOne FB report.
※本レポートはJavaOneの個々の発表内容とは無関係のエントリーとなります。
0#まえおき
先月、会社の制度を利用して、
年1回サンフランシスコで行われる「JavaOneカンファレンス」に参加してきました。
このカンファレンスは、
Oracle社が主催する、Java関連のカンファレンスの中で世界最大のカンファレンスです。
JavaOneカンファレンス自体は年に数回、様々な地域で開催されますが、
サンフランシスコで行われるものが最も大きな規模となります。
カンファレンスは5日間に渡って開催され、
延べ500以上のセッションが開催されます。
Oracle社主催ということもあり、キーノートセッションでは、
Javaの最新動向についての話を聞くことが出来ます。
各セッションは、Oracleの人だけではなく、
世界的に有名なJavaエンジニアや新進気鋭の方など、
様々な方が、様々なテーマでセッションを開催します。
詳細な内容や、各セッションの内容については別の記事で説明させて頂くこととし、
本記事ではカンファレンスに参加してみて、
プレゼンの違いについて感じたことについてまとめることとします。
1#プレゼン中の違いについて
海外のカンファレンスって、日本と何が違うのか。
自分の感じたことをまとめます。
-
- 熱量が違う --
KeyNoteカンファレンスでは、プレゼンの端々で歓声、
時にはスタンディングオペーションが起きます。
これは国内のカンファレンスではあまり起きないことだと思います。
これは海外の方が日本と比べてよりプログラミングに対する思いが強いわけではなく、
自分たちで盛り上げて、お祭り感を造る習慣があるということだと感じました。
-
- がんがん退席する --
つまらないセミナーとあれば、すぐに退席します。
素直です。逆によいプレゼンには拍手喝采です。
-
- プレゼンの途中でもがんがん質問が入る --
プレゼンしながらでも質問します。手をあげるとかないっす。
ただ、これもプレゼンの流れの一つとして受入れられていて、
ここから議論が発展したりするのも面白いです。
プレゼンの最後にもQAセッションはありますし、
セッション終了後に個別に質問することも出来ます。
個々の判断で、という所でしょうか。
-
- codeベースのハンズオンが多い --
これは、海外がAgileのやり方がより浸透していることが要因の一つだと感じました。
Agileではデモを非常に大事にしています。同じく各プレゼンターも実際にコードをその場で
動かす方が多いのも特徴の一つです。
事前に用意したコードをIDEでローカルで立てて動かすことはもちろん、
その場でがんがんコードを書く人もいます。
【Agileにおけるデモについて(英語)】
Team Demo « Scaled Agile Framework
ちなみに、IDEでEclipse使っているひとはほとんどいない気がしています。。
IntelliJかNetBeansが多い印象です。
2#感想(編集中)
個人的に一番共感するのは、やはり最後のデモを見せるプレゼンが多いということ。
この点に関して非常に共感出来ました。
当然内容にもよりますが、動くものが見せられるのであれば、見せた方がいいです。
そのメリットとしては下記が上げられます。
#説得力
自分は社内で若い方ですが（といっても少し年をとってきましたが）、
先輩や、自分よりも上の立場に対して話す際に、実際に動かすものを見せた方が圧倒的に説得力がまします。
プレゼンに組み込まなくとも、質問に対して実際に動して見せる為に用意しておくのもいいでしょう。
質問に対して、実際に動くもので回答出来たら格好いいですよね。
#具体的
パワポのテキストの何倍も具体的ですよね。
自分より知識が無い人や、プレゼンの内容に対してあまり詳しくない人を考慮する場合、
デモがあると各人の助けになるでしょう。
デメリットは下記です。
#時間がかかる
あたり前すぎますが、時間がかかります。
特に、慣れないうちは前もって用意する必要があります。
環境の用意、データの用意など。。
時間が足りなければデモはしないという判断も時には必要です。
といった所でしょうか。
JavaOne2013レポート002-Practices and Tools for Building Better APIs(後半)
前半記事はこちらから
JavaOne2013レポート001-Practices and Tools for Building Better APIs(前半) - desi-gneer(designer_engineer)
4# Usableとは
前半に記載したが、Peter氏は、良いAPIの定義として
1.Valuable(always important)
2.Usable(more important if used more)
3.Stable(more important if used more and longer)
を上げている。
API design は human intarface designに似ているとした上で、
APIのUsableを次の5つの項目に分けた。
- 1.Learnability(学びやすさ)
どれだけ早く仕様を把握してもらえますか？
- 2.Efficiency(効率的)
一度ユーザがデザインを把握すれば、「すぐに使える」ことが大切と。
- 3.Memorability(覚えていやすい)
一度使ったら忘れない。そんな設計素敵ですよね
- 4.Errors rate(エラーの評価がされている)
エラーからの復帰しやすさも大切とのこと
- 5.Satisfaction(満足できるものであること)
満足、してますか？
改めて言葉にすると当たり前の要素もあると思いますが、
この5つすべてに不満が無いAPIを作れる人もなかなかいないのでは。
5# Internal Designについて
内部設計については
Example first
Example is most important in API documentation.
と、サンプルがとにかく大事だと述べていた。
これは自分も非常に共感する所で、
APIのドキュメントをみる時はやっぱりまずはサンプルをみます。
あー、大体こんな感じか。。ってのが分かりますもんね。
なければ仕様書を見るわけですが。。
サンプルが充実してると凄く嬉しいですよね、使う側にとっては。
仕様書読めば分かるでしょうというのは、少なからずエゴも含まれていると感じます。
サンプル見ただけで殆ど使い方が分かるAPIは、やっぱり使いやすい。
続いて、
concrete use case,
usability check(具体的なユースケース、ユーザビリティのチェック)
が大切と。
2.Usable(more important if used more)
の
1.Learnability(学びやすさ)
2.Efficiency(効率的)
3.Memorability(覚えていやすい)
を意識してといった所でしょうか。
6# Shapeするために(null check)
繰り返しですが、Peter氏はAPIをshapeすることの重要性を度々述べている。ここから、コードレベルの話に入っていく。
まずは、
Smaller APIs are easier to use.(小さければより使いやすい)
- less classes
- less methods
- less parameters
と。当たり前ですよね。少ない方が使いやすい(usable)、安定する(stable)
本セミナーでは、Null check/Lambda式を例に上げていくつかのコード比較を例に出していました。
pubric void sample(String param){ if (param == null){ return; } //処理 }
こんなコード、書いてませんかって。
あります。うちにはあります。。(涙目
認識してるけど、改めて突きつけられると
JavaOneでの発表ということもあって、
良い例として、
Java SE7で追加されたrequireNonNullを使ったコードが挙げられていました。
Objects (Java Platform SE 7 )
コードが少し短くなることもさることながら、
エラーはちゃんと起こしましょう。
ってのも大事ですよね。
pubric void sample(String param){ Objects.requireNonNull(param); //処理 }
もちろん、googleのguavaを使って、checkNotNullでもいいと思います。
pubric void sample(String param){ checkNotNull(param,"this parameter must be null hogehoge"); //処理 }
こっちだとNullPointerException発生時のエラーメッセージ足せるし。
また、JSR305/FIndbugsを利用して、アノテーションを利用して想定外の
null関連の問題が発生を防ぐことも大切と。
@Nonnull: nullを許容しない
@Nullable: nullを許容する
@CheckForNull: nullになる可能性を考慮してチェックを促す
参考:
FindBugs の @NonNull @CheckForNull アノテーション - あるプログラマの日記
話を聞きながら、当たり前だよねと思いつつ胸が痛む自分が。。
基本、、なんですよね。これは。
続いて、基本的にNullを許容しない方針を前提に、
Nullを許容しないInterfaceを作成して、各クラスに
@ParameterAndReturnsAreNonNullByDefalut
のようなアノテーションをつけると、より管理しやすくなるとのこと。
たしかに。
7#Shapeするために(lambda式)
同じくコードをShapeさせる上でLambda式は威力を発揮すると
知っての通り、コード量は減ることが明らかだが、
ビジネスロジックが分かりやすくなることで、
Learnability(学びやすさ)
の面でも効果があると。
###編集中###
(一応コード例をのせる予定)
8#Cheat Sheet書けよ！
そして最後に、Cheat Sheet書けよ！といって、例を見せてくれた。
作ろう、、すぐ作ろう。。
9#まとめ
改めて見直しても、基本的な話が多かったです。
見ていて「はいはい、当たり前ですね。」と思う方もたくさんいらっしゃるかもしれませんが、
当日の反響がそれなりにあったことからも、
実際こういったことを徹底出来ていないサービスを抱えている人
は結構沢山いらっしゃるのではないでしょうか。
もちろん、自分もその一人でした。
また、個人的な見解でもありますが、Learnabilityは、頭のどこかでは分かりつつも、実際に形にしては何かをしているとか、
指標の一つとして目標にすることは少ないのではないでしょうか。
こういった視点の大切さを改めて認識出来ただけでも、このセミナーは自分にとって有意義なものでした。
(おわり)
JavaOne2013レポート001-Practices and Tools for Building Better APIs(前半)
※JavaOneのレポートを書くにあたり、
ブログが必要だったのでとりあえず一つ開設しました。
JavaOne3日目に聴講した、Peter Hendriks氏の
「Practices and Tools for Building Better APIs」についてのまとめ前半。
本セミナーは、表題の通り
「良いAPIとは何か」について考えを深めると共に、
Javaの最新動向とも関連づけてどのような改善が出来るのか述べている。
下記に話の大枠毎に区切ってまとめていく。
1# 2つの視点
APIの設計を考える上で下記の2つの立場について考えることが鍵である。
それは
Consumer(APIを使う人)とImplementer(APIを実装する人)
であると。
この2つをいきなり並列で出してくることがまず新鮮だった。
我々としては、前者(Consumer)と後者(Implementer)は
それぞれ全く別者として考慮しているからだ。
その上で、下記が大切だと述べた。
1.Reuse(再利用しやすいことが大切)
-先を見据えた実装はとても大切である。APIを設計する場合は、そのAPIの将来像、
あるべき姿について考えることが大切だと考える。これを考えれば、コアなAPIほど再利用出来る形に自然と近づくはずである。
2.Independent change(独立して変更可能であることが大切)
-これは実際に社内のAPIを担当していて感じるが、
様々な用件で、仕様の変更が求められる機会は多々ある。もちろんそこで仕様を変えるかどうかは別問題だが、柔軟な設計であることで仕様変更に耐えられることも事実。
3.Separate concerns(※色々と意味がとれるのですが、リスク分散が大切(としておきます)
-※編集中※
2#APIは使う側にとってはブラックボックス
APIは使用する側にとってブラックボックスになってることが往往としてあるという事。
たしかにその通りで、たしかにAPIの先でエラーが起きたときに、
何が原因でエラーなのか全く分からなくて手詰まりになることは少なくない。
社外連携はもちろんのこと、社内の連携でも、色々なものをまたぐほどに良くわからなくなる。。これは胸が痛い
そういった理由から、とにかく我々は
APIをShape
する必要があるとPeter氏。
個人的にshapeって言葉がぴったりだと思いました。
無駄を削ぎ落として、芸術作品のようなAPIを作りたい。
#3良いAPIとは
#1,#2をふまえた上でPeter氏が良いAPIを次のように定義した。
1.Valuable(always important)
value = benefit - costs
->
ここはやっぱり揺るぎない。
利益を生み出すことはAPIに置いても非常に重要
特に社内APIだと直接ビジネスとの接点が薄い場合もあるので、
忘れがちになる場合もあると思います。コストは計算すると本当に高い
2.Usable(more important if used more)
easy to learn
productive
error-proof
->
使いやすいこと。easy to learnは改めてとても大切だと認識。
easy to learn(学習しやすさ)がAPIを回収する上でコストの面でも
大切だということを再認識させられた。当たり前のことでもこういう事を項目の一つとして、他の観点と同様に重要だと位置づけることが意識の高さだと感じた。
3.Stable(more important if used more and longer)
Able to enhance and grow features without breaking existing consumer code
->
安定していること。
また、安定する為にどのようなコードを書くかということが非常に大切であるとのこと。
2,3についてはコードレベルの話もあるので、その点は後述していきます。
以上で本セッションの前半まとめとさせていただきます。
後半では、良いAPIの定義であるUsableとStableについて実例を
ふまえた説明があったので、引き続きまとめます。
