playframeworkを試し実装の感想

きっかけ

下記の記事を見て、そういえばPlayframework使ったことねぇな。。。って思って、とりあえず、サンプル実装に乗り出した。

employment.en-japan.com

サンプル実装

とりあえず、下記のサイトを参考に実装

はじめての Play Framework - Qiita

Javaは、もともと入っていたので、特に入れ直したりはしてない。
Scalaはちょっと知ってるくらいで、ほぼ初心者。
Scalaの知識は、なくても始められたのが意外だった。

やり方は、上記サイトを参照。
やってみた結果だけ書く。

環境情報

OSは、Windows10

Microsoft Windows [Version 10.0.15063]

Javaは9。たぶん、互換性があるはずだから、Java8じゃなくても問題ないはず。

java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

sbtのバージョン sbt sbtVersionで確認できる。自分は[info] 1.0.2だった。

ハマったこと・気になったこと

sbtをしらないので、環境準備に手間取った。。。
Windowsようのmsiを落とすのにかなり時間がかかった。
他の方法あるのだろうか？
最初の一歩目で時間がかかると、諦める人がいそうな気がしないでもない。

そのあとの初期起動がものすごくかかったのは、気になった。
sbtの作り的な問題なのだろうか？
ビルドツールは、mavenかgradleしか使ったことがなかったから、あとで調べてみる。

作ってみて思ったのは、ビューが他のやつとは違うなという印象。
編集すれば即反映されるのは、再起動の手間がかからなくて良さそう。
ビューの定義方法も、HTMLベースで分かりやすかった。
JSP見たいなことやられてたら、学ぶ気が失せてたと思う。

環境準備がネックかな？
始めるのに時間がかかるのは、たしかに意欲が削がれる。
SpringBoot見たいなヤツがあるのだろうか？
それがあれば、もっと楽にできたかも。

nowをTypescriptで試し実行

きっかけ

CodeIQの記事を見て。
そのままやったら面白くないので、とりあえず、Typescriptで試した。

codeiq.jp

実行した環境

nowをTypescriptで試し実装

Webページの作成

まずは通常のWebページを作成。
※Typescriptのインストールとかは、各自でお願いします！

適当にディレクトリ掘って、いつも通りの初期化

npm init -y
tsc --init

server.js を作成する。

import * as http from "http";

const PORT = 8000;

http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/plain;charset=utf-8" });
  res.end("now test for typescript");
}).listen(PORT);

console.log(`Server running at ${PORT}`);

ほんで持って実行。
npm startで実行。
実行され、localhost:8000 にアクセスすれば、now test for typescriptって表示されるはず。

とりあえず、ベースとなるものはできた。

nowでデプロイ

$ npm i -g now
$ now

とりあえず、インストールして実行。
メールアドレスの入力を求められるので、入力すると認証メールが飛んでくる。
飛んできたメールのURLを叩いて認証すると、設定ファイルが作成される。 ※すでに設定ファイルがある場合、たぶん、メール入力とかはなく、すぐに実行される。

その後、もう一回nowを実行すると、デプロイされて起動できる。
途中でどのURLに紐付いているか出力されるので、そのURLをコピってブラウザで開くと、now test for typescriptって表示されるはず。
※コピるURLの箇所は、Ready! https://nowtest- のところ。

こんだけでアプリ公開ができるから、凄い。。。

アプリケーションの確認と消去

無料プランの場合は月に20個までデプロイ可能。

起動状態の確認は、now lsを実行する。
すると、実行状態が表示される。
アプリを消去したい場合は、now lsで確認したurlを使って、now rm <url> を実行する。
確認を求められるので、yで実行すれば、削除される。
ブラウザで開くと、アクセスできなくなってるハズ。

感想

すごく簡単にアプリが公開できる。
有料化と思いきや、無料で出来るのが凄い。
指定した環境にデプロイとか出来るのだろうか？
コレ使って自前環境にデプロイできるようになれば、楽に開発できそうな気がする。
個人向けで、サービス作って検証する分には、なかなかいい感じだと思う。
とくにインフラの知識を得たいときなんかは、まず手始めにやってみるといいかもね。

【書評】エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

読書開始日

2017/10/16

もくじ

• 第Ⅰ部　エラスティックリーダーシップを理解する
  • 1章　チームリーダーマニフェストに向かって努力する
  • 2章　リーダーシップスタイルをチームのフェーズに合わせる
  • 3章　バス因子に対処する
• 第Ⅱ部　サバイバルモード
  • 4章　サバイバルモードに対処する
• 第Ⅲ部　学習モード
  • 5章　学習することを学ぶ
  • 6章　コミットメント言語
  • 7章　メンバーを成長させる
• 第Ⅳ部　自己組織化モード
  • 8章　自己組織化を促進させるためにクリアリングミーティングを行う
  • 9章　影響パターン
  • 10章　管理職のためのマニフェスト
• 第Ⅴ部　チームリーダシップについて知るべきこと
  • 11章　フィードバック
  • 12章　衝突を学習へと導く
  • 13章　おそらく技術的な問題ではない
  • 14章　コードをレビューしよう
  • 15章　空気、食料、水をドキュメントする
  • 16章　査定とアジャイルは仲が良くない
  • 17章　学習を通して導くということ：チームリーダーの責務
  • 18章　 Coreプロトコルの紹介
  • 19章　考えを改めよう：あなたはチームを作っている
  • 20章　リーダーシップと成熟したチーム
  • 21章　作業負荷を分散する
  • 22章　メンバーが自分たちで仕事を管理できるようにする
  • 23章　見守り、尋ね、敬意を示す
  • 24章　開発者が幸せな状態であれば、質の高い仕事が得られる
  • 25章　彼らの仕事をするのをやめる
  • 26章　コードを書こう。ただしやりすぎないこと
  • 27章　マネージャーからリーダーに進化する
  • 28章　変化のペースに影響を与える
  • 29章　近接マネジメント
  • 30章　バベルフィッシュ
  • 31章　あなたはリーダーであって、すべてを知る者ではない
  • 32章　行動は言葉よりも雄弁
• 第Ⅵ部　日本人執筆者によるチームリーダーシップについて知るべきこと
  • 33章　リードについて
  • 34章　チームに成長してもらうためのリーダーシップ
  • 35章　コミュニケーションメンテナになる
  • 36章　困難に立ち向かうチームのリーダーへ
  • 37章　コンセプチュアル・リーダーシップ
  • 38章　 OSS開発のリーダーシップ
  • 39章　「刀は堂々と抜け」〜兼任リーダーの心得'17
  • 40章　リーダーシップは誰のものか
  • 41章　一緒に成長できるリーダーを育てよう
  • 42章　採用プロセスについてもっと考えよう
  • 43章　あなたは少なくともあなた自身のリーダーである
  • 44章　うまくいったらどうなるの
  • 45章　現場リーダーのための6つの原則
  • 46章　大事な問題にフォーカスする

まとめノート

第Ⅰ部　エラスティックリーダーシップを理解する

1章　チームリーダーマニフェストに向かって努力する

チームは、常に変わり続ける。
そのための目標も、変わる。

チームの最大の目標は、自己組織化・自己管理させること。つまり成長を促すこと。
そのためには、学習時間の創出し、安全よりリスクを取らせる必要がある。
一番ダメなのは、現状維持。

2章　リーダーシップスタイルをチームのフェーズに合わせる

チームリーダーの役割は、優れた人材が育つことを助けること。
問題は、全て解決してはならない。なぜなら、その行為はあなたしか成長しないから。
そして、それは、あなたがボトルネックになることを意味する。
なるべく挑戦を促し、成長機会を与える。

リーダーシップとは、状況によって発揮させるものが変わってくる。
主に３タイプに別れる。

• 指揮統制
• ファシリテート
• コーチ

特徴

指揮統制

• 意志の決定は得意。
• 全員の問題を解決したがる。
• 過程の共有はほぼない。
• チャレンジの機会は少ない。

誰でもできる仕事を集団ですることには長けている。

コーチ

• 教えることに重きを置く
• 学習には時間がかかることを容認できる
• 炎上時は力の発揮が難しい

ファシリテーター

• 現状が成果を出せる状態か見極める
• 問題は解決しない。（チームに解決させる）

リーダーシップスタイルとフェーズ

プロジェクト状況に応じて、発揮すべきリーダーシップは変わる。

サバイバルフェーズ

チームに学習の時間がない。
ゆとり時間を作って、学習時間を捻出する必要がある。
指揮統制型が一番能力を発揮する。

学習フェーズ

十分なゆとりがあり、学習・検証ができる。
問題を自力で解決、他人の力を借りて解決することで、自己組織化を促すことが目標。
コーチ型が主体だが、指揮統制が必要なときもある。

自己組織化フェーズ

リーダーがいなくてもいい状態。
この状態を維持するのが重要。
リーダーは、手が空いてるスキに、実験や開発アプローチの模索、チームの目標を探す。

フェーズの移動

チームがどんなリーダーシップを欲しているのか把握しなければいけない。
移動するには、不足しているスキルの人材を連れてくるか、目標の期限を変える必要がある。

3章　バス因子に対処する

バス係数とは、チームメンバーの内、何人がバスに轢かれたら、プロジェクトが破綻するかを示す値。
一人轢かれたら止まる場合は、係数１。

バス因子とは、バス係数が１に近い人。

プロジェクトは、単一障害点を無くすことが必要。
重要な作業を知っている人が少ないほど、その人がいなくなったときの代償は大きい。
バス係数が必ずしも悪いわけではない。
容認しなければいけないこともある。
一番の問題は、バス係数が１に近い人にプロジェクトの制約が全て従ってしまう。
許容できる範囲内に納める努力が必要。

バス因子になる人は、教えることに消極的になりやすい。
蔓延すると大量の無駄時間ができ、学習意欲の減退を引き起こす。

バス因子を取り除くには、ペア作業、コーチングが必要。
できるだけ知識は共有する文化づくりが必須。

第Ⅱ部　サバイバルモード

4章　サバイバルモードに対処する

サバイバルモードとは、学習時間がない状態。

サバイバルモードは理想ではないが、達成感が麻薬のように作用して、常態化しやすい。
抜け出すのには、ゆとり時間を作るのに気配りする必要がある。
ただし、創出した時間を学習に当てる必要がある。

ゆとり時間の作り方

成果物を作る作業をやめる。
ただし、やめるには説明責任がついて回る。
ただ単にやめるのは、ダメ。

やめるためには、やるべきことの取捨選択。
許容ラインの策定とデットラインを決める必要がある。

第Ⅲ部　学習モード

5章　学習することを学ぶ

成長とは、常に右肩上がりではない。
学習が大きく進むときと、学習が安定して成長が鈍化する時がある。
安定から更に成長するには、逆境に入り新しいことを学ぶ必要がある。
不快かも知れないが、成長には必要なもの。

「北風が勇者バイキングをつくった」というのは、まとを得ている。
温室育ちより、極寒の地で育ったほうが、強くなる。

6章　コミットメント言語

コミットメント言語とは、言質を与える言葉遣い。
約束が守れなかった場合、問題を見つけることができる。
それを対応するためにも、言質を与える言葉遣いは、必要。
誠実さの始まりでもある。

チームメンバーは、必ずしも誠実とは限らない。
完全に制御できることではないので、確約をしにくい。
確約を取らせるには、フォローを入れたり、言質を取る聞き返しがする必要がある。
約束を果たせないとわかった時は、即アラートをあげる。
そうしないと不誠実に見える。
また、メンバーのスキルが明らかに足りない常態で言質を取るのは、いい結果を生まない。

7章　メンバーを成長させる

挑戦的課題が必要。
仕事の委任とは違う。
時間もかかり、フォローが必要なことを考慮する。
間違った方向に進もうとした場合には、軌道修正する必要があるので、監視はしておくこと。

第Ⅳ部　自己組織化モード

8章　自己組織化を促進させるためにクリアリングミーティングを行う

クリアミーティングとは、チームが持つ悪感情や共有事項を、全員で対処していくためのミーティング。
クリアミーティングをすることで、問題に対処していくための文化を作る。

9章　影響パターン

個人	能力	実行するスキルの有無
	やる気	やりきる意志と自制心の有無
社会	能力	フォロー体制
	やる気	周囲の人が正しい行動を促し、間違いを抑制できるか
環境	能力	正しい行動を簡単かつ安全にできるようになっているか
	やる気	正しい行動をしたときの報酬

全ての要因が解決しないと、今の状態が維持される。

10章　管理職のためのマニフェスト

管理職の本質は、自己組織化と自己管理スキルを身に着けさせること。
そのためにやるべきことは、いくつかある。

やるべきこと

• ゆとり時間の創出と指導
• 取れるリスクを見つける
• 実験と学べる環境作り
• 横断したスキルの習得
• 対面での会話
• 対人関係の技術を学ぶ

第Ⅴ部　チームリーダシップについて知るべきこと

11章　フィードバック

フィードバックとは、助言の技術。
効果的に使うには、信頼できる人間が、建設的な会話をするように心がける必要がある。

また、貰い方にも問題がある。
人からもらうのは、少なからず感情というバイアスがかかる。
逆に機械（コンパイラなど）からもらうものは、客観的に情報を見ることが出来る。
関係性のフィルタを考慮してフィードバックする。 フィードバックは、双方向であることを意識する。

12章　衝突を学習へと導く

パフォーマンスの高いチームで、意見の対立は必要不可欠。
衝突が学習に向かない場合、チームが問題に対処する選択スキルに欠けている状態にある。

13章　おそらく技術的な問題ではない

困難な問題のほとんどは、技術以外の問題にある。
だから、当事者以外からの視点で解決することもある。

14章　コードをレビューしよう

信賞必罰は、成果があるかも知れないが、誰に功績があるのか見極めるのは難しい。
コードレビューを通して、功績を見逃さないようにする。

15章　空気、食料、水をドキュメントする

新しく入った人が知るべきことというのは、チーム・プロジェクトにとっての水・食料。
誰でも使えるように、ドキュメント化すべき。

16章　査定とアジャイルは仲が良くない

査定は、ほぼ上長主導。
本来は、定期的改善を計る機会のはずだが、その場だけいい評価を得ようとする輩がいる。
なので、日常的に記録やフィードバックを行い、査定のタイミングで振り返って決める。

17章　学習を通して導くということ：チームリーダーの責務

企業に成長を期待するのは、無理。
成長を期待できなくなった。
キャリアには、自分で責任を持たなければならない。

18章　 Coreプロトコルの紹介

Coreプロトコルとは、優秀な結果を出してくるチームの行動パターン

19章　考えを改めよう：あなたはチームを作っている

チームリーダーやマネージャーは、築いてきた考えを押し付けるのはやめるべき。
違う考えを受け入れる。
やらなければならないことは、チームの状況把握と、どこに向かっているのか知ること。
プロダクトを良くするには、メンバー同士が強調しなければいけない。
それができないと、プロダクトは良くなることはない。

20章　リーダーシップと成熟したチーム

21章　作業負荷を分散する

チームメンバーには、不平を訴えるやつと、信頼できるやつとに大別できる。
信頼できるメンバーにだけ、負荷を多くかけるのは、ＮＧ。
平等に負荷を分散して、メンバーに安全地帯から抜け出すきっかけを与える。

このやり方が有効なのは、サバイバルモードの場合だけ。

22章　メンバーが自分たちで仕事を管理できるようにする

メンバーが自己管理ができないということは、チームリーダーとして努力と投資する余地がある。
指示より期待を表明し、実現方法を確認する。
そのためには、作業を１箇所に集めて、実現方法の共有をしやすくする。

23章　見守り、尋ね、敬意を示す

チームに敬意を示すには、質問しやすい環境を作る。
質問の是非を考え、フィードバックを与えたりもらったりする。
そうすることで、自然と自己組織化したチームになる。

24章　開発者が幸せな状態であれば、質の高い仕事が得られる

質の高い仕事をする条件

• コーディング標準の確立
  みんなで同じことをすれば、違反はしにくい。
• 専用の学習時間の確保
  新しいスキルの習得は、最終的に経営を助ける。
  賞賛し、行動を促す。学習欲を阻害するものは、除外・代価を考える。
• 量より質
  実践は難しい。仕事の内容は把握する。指示を出す側は意外とわかってないことがあるのを理解する。

25章　彼らの仕事をするのをやめる

チームリーダーがなんでもすると、サバイバルモードからいつまでたっても抜け出せない。

26章　コードを書こう。ただしやりすぎないこと

チームリーダーがコードを書くことは、状況次第だが、開発知識を与えるために必要なこと。
できるメンバーが揃ったら、問題を分解することに専念し、分解した問題を渡す。
最終的には、メンバーが行動できるようになればいい。

27章　マネージャーからリーダーに進化する

28章　変化のペースに影響を与える

自己組織化には、長い年月がかかる。
多くのフィードバックをしても、不安から壁ができたりもする。
変化させるには、テクニックが必要になる。

• 他チームに参加させる。
  リーダーが常に変化材料を出す必要はない。
  メンバーから変化を起こさせることもあり。そのためには、情報収集のクセをつけさせて、インスピレーションを受ける機会を設ける。
• 衝突は受け入れる
  改善していく中で必ず起こる。
  防御策を講じるために守りに入らず、受け入れた方が、チーム的にも精神的にも楽

29章　近接マネジメント

チームの問題は、現場を見ないと分からない。
場所は重要な概念。
距離が遠くなれば、問題は発見しにくくなる。

30章　バベルフィッシュ

バベルフィッシュとは、他チームの情報をうまくメンバーに伝えるスキル・役割。
やるには、幅広く会話できる必要がある。
最終到達点は、相手の立ち位置を理解し、考えるスキルを身につけること。

31章　あなたはリーダーであって、すべてを知る者ではない

チームリーダーは、技術的に優秀である必要はない。
メンバーの能力を引き出す方が重要。
ただ、状況次第では、技術的優秀さも必要であることは、忘れてはならない。

32章　行動は言葉よりも雄弁

間違えてもいいから行動する。
間違えが評価されるなら、それはその組織がカス。

第Ⅵ部　日本人執筆者によるチームリーダーシップについて知るべきこと

33章　リードについて

リードするには、言いにくいことを言う必要がある。

34章　チームに成長してもらうためのリーダーシップ

学び成長させるには、自分でやる必要がある。
自分のことだけ集中すると、チームの成長は期待できない。
成長の仕方が分からなければ、他人から学ぶ。

成長は可視化しておく。きっかけや成長を促す材料になる。
なるべく長く続けることが、成長につながる。

35章　コミュニケーションメンテナになる

リーダーとは、会話の中継役になりやすい。
メンバーには、ルールを強制するより、柔軟に許容することを選んだほうがいい。

会話には、同期・非同期がある。
同期的会話は、強制的なので、使う場合には相手の時間を奪うことも考慮する。
非同期的な場合は、前提がわからないことを考慮して、情報を残す。

情報は、無駄なものでも排除しないほうがいい。
意外なところで価値を生み出す可能性がある。
投資だと思って、雑談も許容する。

36章　困難に立ち向かうチームのリーダーへ

• 考えを公開し、チームに浸透させる
• 本質を見抜く
• 1on1の対話を重視し、情報を引き出し、本質を見抜くことに使う

37章　コンセプチュアル・リーダーシップ

生産性の向上は、早いだけでは無理。
しかし、速さには価値がある。
速さの後に、巧妙さが付いてくればいい。
コンセプトを発揮するのは、リーダーだけではない。
各人が目標を考え、各レイヤーで行動することが大切。

38章　 OSS開発のリーダーシップ

立場・役割とつけると、人はそれに適用しようとする。

39章　「刀は堂々と抜け」〜兼任リーダーの心得'17

堂々と刀を抜くには、積極的に開発に参加して、実力を発揮する必要がある。
成長するには、一緒に働き、刀を見せる。

40章　リーダーシップは誰のものか

リーダーシップには、目標の掲示が必要。
やるには、掲示だけでなく、そこに連れて行く努力もいる。

41章　一緒に成長できるリーダーを育てよう

リーダーとして成長するには、リーダーを育てればいい。
一人で試行錯誤するより、チームで試行錯誤したほうが、効率がいい。
成長と育成はセットで考える。

42章　採用プロセスについてもっと考えよう

採用でやってはいけないことは、間違って人を採用すること。
迷うくらいなら、採用は見逃したほうがいい。

なるべく、チームの文化と合う人を探す。
最初の段階で食い違いを無くすために、文化の明文化は必須。

43章　あなたは少なくともあなた自身のリーダーである

リーダーとは特別な存在ではなく、誰でもなれる。
少なくとも自分の行動は自分で決めているので、既に自分自信のリーダーではある。

44章　うまくいったらどうなるの

何かすると決める場合、成功したらどうなるかを考える。
リスクは考えやすいが、メリットは見えにくい。
メリットの説明は、やることの具体化につながる。

45章　現場リーダーのための6つの原則

• 見える化
  ものごとの共有に必須
• 名前付け
  ラベルを張ることで、知識の引き出しが楽になる
• 始め良ければすべてよし
  簡単なことから初めて、成功を積み重ねれば、難しい問題も解決できる
• リズム
  定期的にものごとに取り組むのは、何をするにも必須
• 問題 vs 私達
  チーム内の抗争をせず、問題に意識が行くように仕向ける
• 改善
  現状を壊して新しくするのではなく、現状を少しでもいいから良くすることが大事。
  日々それをすれば、いずれは大きな変化になる。

46章　大事な問題にフォーカスする

チームが良くなっても、プロダクトがよくなることはない。
良いチームを作るのは、リーダーの目的に対する手段。
チームに大切なのは成果を出すこと。
リーダーは、メンバーを問題に向かわせることが必要。

感想

リーダーに必要とされる能力はいろいろあるが、現状の把握、目標へとメンバーを誘導が大切なのだと思われる。

各人、いろいろな意見があるが、成長機会を奪ったり、目標に向けて行動せさてないことは悪だと言う点では、全員一致しているように思われる。
あとは、やり方を考える必要があると感じた。

目標を立てるのはいいが、現状を理解したうえで目標を立てる必要があるのは、目標を立てることに失念し勝ち。
冷静な判断を下すためにも、現状の理解は必要不可欠。
現状を理解するためにも、日々の記録をとったり、現地で情報収集することは大切。
リーダーの役を演じる場合は、現状の理解と目標を見誤ると、だいたいは失敗する。
思い返してみると、サバイバルモード以外のチームにいたことがない気がする。。。

自己組織化するために必要なことが何かをすることはできたが、適用は難しそう。
まずは、現状分析のために情報を集めてどうとらえるかの目を養った方がいいと、個人的には感じている。

Slackで気になった動作

きっかけ

最近、どこの開発現場に言っても使うことが増えてきた。
使っていく上で、バグっぽい動きをしたところ、期待と違う動作をまとめておく ※随時更新予定

内容

editしてメンション付けても通知されない

凄く不便。
delete -> 新規書き込み すればいいんだけど、使い方に凄く違和感がある。

11/1 接続障害

slackに接続障害が発生

原因は究明中

分かったことは、slackを言い訳に仕事をサボると、凄い幸福感に包まれるってこと。

原因

Slack、11月1日に発生した大規模障害の原因は、定期デプロイによるソフトウェア障害が原因 － Publickey

障害の原因は同社内で行われていた定期デプロイによってサーバにデプロイされたソフトウェアの障害とのことです。

本家サイト

Slack System Status

Java SE 9/EE 8リリースイベント兼JavaOne2017報告会@東京 参加報告

Java SE 9/EE 8リリースイベント 兼 JavaOne 2017 報告会 @ 東京

公式サイト

https://jjug.doorkeeper.jp/events/66256

開催概要

日時

2017-10-21（土）13:00 - 19:30

場所

ヤフー株式会社 紀尾井町オフィス 17Fセミナールーム
東京都千代田区紀尾井町１ 東京ガーデンテラス紀尾井町

タイムテーブル

時間	内容
13:00-13:30	JavaOne 2017 Overview & Announcements by 伊藤 敬さん (日本オラクル)
13:30-14:20	JDK9, Release Cadence & Future by 久保田 祐史さん (inc. JShell Demo by @bitter_fox) (@sugarlife)
14:20-14:50	Intel's Persistent Memory by 吉田 真也さん(@bitter_fox)
15:05-15:45	Java EE 8 by 西川 彰広さん (日本オラクル)
15:45-16:25	Microservices Topic & Approach by 森下 大介さん(ヤフー株式会社)
16:40-16:50	Fn Project by 伊藤 智博さん(@chiroito)
16:50-17:10	Community&総括 by 横田 紋奈さん(@ihcomega)

動画

www.youtube.com

行こうと思った理由

今は、Java使ってないけど、一番得意な言語であるので、最新情報をキャッチしたかったから。
あと、Javaのリリースがよく分からなかったから、聞きに来たのが大きい。

ちなみに、今は、Typescriptおじさんです。
Javaやってる人なら、簡単に出来るので、第二言語としてはオススメだと思うよ？

感想・まとめ

コードギアスの映画を見に行くか迷ったけど、ギアスは明日でも見に行けるから、こっちを優先。

JavaOne 2017 Overview & Announcement

今年のJavaOneは、機能追加をより早くがテーマだったみたい。

これからの活動方針は、進化の加速と軽量化が主目的なる。
もっと簡単にリリースの提供していくというのが新しく方針に加わった。

Java9への道

もともとはJDK7で考案として、Coin&Lambda&Jigsawがあったが、Java7に載せるのは無理だった。
そのため、以下のような形になった。
java7 - Coin
java8 - Lambda
java9 - Coin完成 Jigsaw

リリースモデル

従来のリリースモデル

機能リリース：２年だが、守れたことはない。。。

その結果、細かな機能追加が遅れてしまい、Javaが時代遅れになりつつある。

新しいリリースモデル

OpenJDKとOracleJDKの差分をなくす
機能リリースを６ヶ月に一回に変更
バージョン表記は、YY.M
更新リリース：３ヶ月（メンテナンス用）
OpenJDKのバイナリで配布。次のバージョンまでの６ヶ月は無償サポート

わかりにくいな。。。。
話を聞く限り、リリースとサポートのサイクルは違っているようだ。
長期サポートは、３年サイクルで決まる。
３年経ったら、その間にリリースされたものは、その後に３年サポート保証する。
そのサポートサイクルが、既存のリリースと同じ感じだな。
新しいリリースは、半年ペースで行われるので、６回のリリースを経た後、３年サポートになる。
20:53の図を見る限り、その認識で問題ないはず。
ただし、無償サポートについては、次のバージョンがリリースされるまで。

ソース管理は、従来だとバージョンごとにブランチがあった。 新モデルだと、リリースラインが１本化。 おそらく、ソース管理がそのほうが楽だからと思われる。 たぶん、svnチックなブランチ管理のせいで、摩耗していることが多かったのだろうな。

どれを使うか、かなりシビアな気がしてきた。 アナウンスにそうなら、３年ごとの最後のバージョンに合わせるのが良さそうな気がする。
サポート単位で、やっぱりJava10とかの命名が必要な気がしてならない。
今のリリースサイクルだと、短すぎて説明が面倒くさいような気がする。

ロードマップの把握がかなり重要になってきそう。 いままでは２年以上のリリースサイクルがあるので、後追いでも十分追いつけたが、これからの新モデルだと、常に情報を追ってないと不味そうだね。 最新機能を追うか／追わないかで、エンジニアの力に差がつきそう。
Java今使ってないけど、主力武器には違いないので、なるべく追う。

JDK9, Release Cadence & Future

WEB+DBの告知。自分は電子書籍の定期購読してるんで大丈夫です。
前は本を買ってたけど、ソースをコピペできるPDF形式の配布は、かなりいいｂ

追加機能は、JEPで確認する。 もしくは、Bugzilla issuetype=JEP

移行は、Migration Guideを読む。 ★あとで翻訳、もしくは読んで見る。

Java9のメリット

• モジュール化
• RPEL
• ライブラリ改善（Coinの残り対応）
• セキュリティ強化
• 付属ツールの刷新
• G1GCやコンパイラの性能改善

そういえば、G1GCはデフォルト化されたので、メモリが小さいところで動作させるのは注意しなきゃな。
すっかり忘れてた。。。

どのライブラリの参照がなくなったのか、コンパイル時に発見することができるようになった。 今まではしらみつぶしに参照していたものがなくなって、楽に解決できるようになったはず。

JShell

REPLツール
LISP, Python, Ruby, Scala, Groovyなどの人気があるのに使われていた。

主な用途は、APIの挙動確認、デモ、プロトタイプ確認。

下記サイトで、Java9入れなくても試せる事ができる。
今後のリリースサイクルは短いので、インストール不要で試せるのはかなり楽。
バージョン指定が今後欲しい機能だな。
もしかしたら、もうあるのかな？

tryjshell.org | Java 9's JShell

コマンドは使い方は以前まとめたので、そちら参照

suzaku-tec.hatenadiary.jp

jshellの特徴

• 保管機能が強い
• importの自動補完、変数定義の補完がなされる

コレクションのファクトリ

かなりコード量が減った。
コレクション系は、使う機会が多いので、覚えておいて損はない。
コードと関数を紐付けたり、グルーピングに使ったりする。
以前にブログでまとめた。

suzaku-tec.hatenadiary.jp

イミュータブルでフェールセーフ、最適化された状態 2要素→フィールド実装になったりしている。

StreamAPI iteratorの終了条件や継続条件が使えるようになり、while文に近いことができるようになった。

今後の予定

次はProject Amber
ローカル変数の型推論が加わる。
var url とかできるようになる。
コード記述の煩わしさを解消するのがメインの内容になる。

Intel's Persistent Memory

大容量で割安、不揮発性
Persistent MemoryにオラクルDB乗っけたり、Java動かすようにしてくよ？みたいなアナウンスがあったらしい。

用途

揮発性の大容量メモリとして使う

ヒープをすべてPMに乗っける。

設定簡単。メモリアクセス速度＜大容量メモリのシーンで使える

一部のヒープをDRAMに乗っける

設定が細かく設定できる。速度重視なもので使える。

不揮発性のローカルストレージとして使う

永続化可能なクラス・コレクション・API・トランザクション、ユーザ定義可能なクラス定義が提供されている。

話を聞いて

Persistent Memoryがプログラミング言語に与える影響はデカそう メモリとして使うか、ストレージとして使うか選べるのは強い。

Java EE 8

JavaEE8

Reactive-API, HTTP/2, JSON java binding...

開発は、java.netから　Githubに移行。

Eclipse Enterprise for Java (EE4J)

おそすぎる進化。オープンでNimbleな開発をする必要があるとOracle&コミュニティで判断が出た。
そしてEclipse Fundactionに移管される。

EE4Jは移管のプロジェクト名らしい。
別個に名前がつくのか、このままブランド名採用されるのかは、まだ未定。

EE4Jは、まだ始まったばかりで何も決まってない。

移管することのメリット

• 開発プロセスの透明化
• 多くの人に参加してもらう。オラクルも１ベンダーとして参加する。

Microservices Topic & Approach

話題・取り組み事例

最初はモノリス。サービスの拡大でスケール必要になると、結果としてマイクロサービスアーキテクチャになった。
組織と文化は、後追いで対応。数年がかりで継続してやらないと難しい。
技術的なことより、組織と文化をどう変えていくかが焦点になる。
コンウェイの法則が注目されている。
自主性や自立性を重視する考え方が必要。

サービスが連携しなうので、破壊的変更は、手続きをする。
それ以外なら、ある程度の裁量を与えてサービスを拡張させていく。
やるなら、同期＜非同期を推奨。

重要ワード

• CI/CD
• コンテナ
• オーケストレーション
• 非同期
• フォールトトレラント
• モニタリング・可視化
• トラッキング

今のマイクロサービスの流れ

議論は、フレームワークやライブラリの開発ではなく、サービスという部品の連携をどうするかに考えがシフトしていっている。

マイクロサービスで話題になること

同期処理

同期処理は呼び出しだと、エラー制御が難しく、インタフェースがもろくなりやすい。　　

結果整合性

ことなるデータストアの整合性は、いつかは一致するという考え。
これを許容することがマイクロサービスにとって重要みたいな話になっているらしい

Event sourcing

データストアをイベント記録に使う。
記録をためていくだけ。追加だけで、更新はしない。

CQRS

登録処理と参照処理は、必ずサービスを分断しましょうって考え。

まとめ

マイクロサービスは、サービス拡張の結果なるもの。 モノリスが悪ではない。最初から分割して作るは、ドメイン境界を見極める必要がある。 ただ、それは非常に難しい。初期から要らぬところで悩む必要がある。

Fn Project

Function実行環境。
Fnの告知な気がする。

あんまり内容は覚えてない。。。

Community&総括

日本と世界でIT業界の男女比が違いすぎる。。。
残業ありきだから、女性がこないのだろうか？
逆に考えるんだ、残業しちゃっても誰もクレームつけないんだぜって。
残業代貰い放題！

Java女子部って５００人もいるのか。。。
１０分の一くらいかと思ってた。。。

今後やるべきタスク

• Migration Guideの査読
• 今後のリリース内容を収集・確認する方法を確立する
• Persistent Memoryについて、情報収集・シミュレータを試してみる
• Fn Projectの情報収集

しまったぁぁぁぁ！！！！

リリースを理解して満足してしまったから、すっかり忘れていた。
Java10とかの呼称がなくなったから、OracleのJava認定試験がどうなるのか、聞くのを忘れてた。。。

Javaの認定試験はすごく大事。 もってると会社で威張れて給料が高くなるから！
どうなるんだろう？
JJUG CCC 2017で聞けるのかな？
機会があったら質問しておこう。。。

JavaScriptのsetTimeoutのデバックでハマったこと

きっかけ

setTimeout使ったフェールセーフな実装をしていたのだが、デバッグでハマってしまった。。。
１時間位悩んでしまったので、晒す。

ネタソース

お題となるソース。
実際はもっと複雑だけど、簡略化するとこんな感じ。
※本当はTypeScriptでソース書いてるんで、JavaScriptはなんとなく分かる程度です。。。

<html>

<head>
</head>

<body>
    <script language="JavaScript">
       var test = function () {
           var timer = function () {
               console.log("timer fire!");
           };
           console.log("process start");
           setTimeout(timer, 1000);
           console.log("process end");
       };
   </script>

    <button onclick="test();">execute</button>
</body>

</html>

やりたきこととしては、 console.log("process end"); の処理に時間がかかったら、 console.log("timer fire!"); が実行されるよね？を確認したかった。
そのために、 console.log("process end"); のところで、ブレークポイントを張って、処理を止めて確認した。

検証環境

• Google Chrome 61.0.3163.100
• Firefox 56.0

どっちも同じ結果。

実行結果

process start が表示され、 console.log("process end"); でブレークポイント張ってるんで処理がとまる。
しかし、待てど暮らせど setTimeout(timer, 1000); は発火しない。

理由

理由は簡単。JavaScriptはシングルスレッドなので、ブレークポイントで処理を止めると、全て止まる。
まるで、DIOのザ・ワールドだね！全ての時が止まるなんて！
自分の理解では、setTimeoutはJavaのスレッドみたいに並列処理してるんやろな～みたいに思っていた。。。

JavaScriptは、シングルスレッドだということは知っていたけど、こいうことなんですね。。。
冷静に考えれば、たしかにそうだねって分かるけど、業務中だとあんまり頭が回ってないのかも知れない。

Firefox57で気づいてしまった。。。

Firefox 57 for developers - Mozilla | MDN

気づいてしまった

自分が使っているアドオンがほぼ利用できないという事実に。。。

代価アドオンは、探しているけど、見つからない。。。
正直、速度向上しても利便性を捨てるなら、バージョンアップしたくないのだが。。。
使えなくなってしまう理由は、WebExtentionsのせいですね。

コレで一番痛いのが、TabMixPlusが使えないこと。
提供されるAPIでは、実現無理だと言われていますからね。。。

他にも使えなくなるアドオンがてんこ盛り。。。
これ、本当にリリースまでに全アドオンが対応できるの？
果たしていい結果を生むのか、かなり疑問が沸く。
速度向上しましたと言っても、現状の機能維持してないから、今の機能が実現できるようになるころには、chromeさんあたりに速度向かれてそうな気がする。

今後

Webブラウザ乗り換えようかな～って、本気で考え出してきたわ。。。

Firefoxの利点だったアドオンを捨てるのは、個人的にはダメだと思うんですけどね。。。
キャビアがのっかった残飯料理が出てくるのを待っている気分。

Firefoxは好きだし、使い続けたいけど、今回のバージョンアップでchromeさんに乗り換えるかも知れない。
使ってみてダメだったら乗り換えます。。。