JJUG CCC 2019 Spring

・JJUG 基調講演 現代に求められるJavaコミュニティとは #ccc_e1
　・Java→半年毎のリリースモデル。求められる学習スピードが従来よりも早くなる。
　・ライセンスモデルの変更とそれに伴う混乱は防ぎたい。
　　→コミュニティの場でアップデート内容とグッドプラクティスの共有が
　　　できるようにしたい。
　・海外JUGとの連携
　　・新技術は海外からやってくることが多い。
　　　　新技術の紹介はエンジニアの選択肢が増える。
　　・使い込んだ技術を共有する。→これは逆に選択肢を狭める
　　・両者のバランスが大事。両方をうまく発信したい。
　　・JJUGでも海外からの登壇者による英語セッションを増やしている。
　　・逆に日本からも世界に発信したい。
　　　　日本の現場で培われたノウハウは海外に輸出できる価値にある。
　　　　(最大規模を誇るJUGはBrazilというのは意外だった。)
　・初心者向けコンテンツ→足りない！
　・JJUG CCCを分けた。運営側リソース不足によるもの。
　・インターネットの普及によって欧米の技術と一緒に文化も入りやすくなった。
　・ITエンジニア←欧米の文化に触れやすい。
　　インターネットに触れてない人々と比べると進んだ価値観を持ちやすい。
　　QR決済はまだ一般的じゃないよ
　・新旧価値観の違いによるいがみ合いが見えてしまう。
　　人は他人の価値観を否定しがち。特に大義名分があると思いこんでいると暴走しがち。
　・昔のマジョリティが時間とともにマイノリティに変化することもある。
　　例：専業主婦のためのPTA
　　→コミュニティがマイノリティを受け入れられる場にしたい。
　　　（いがみ合いは確かに見ていて辛いなぁと思う。）

・大企業運営の法人向けサービスにおけるOpenJDK移行事例　#ccc_g2a
　スライド資料：https://slides.com/hiroyuki_onaka/jjug-ccc-2019-spring/#/
　・OpenJDKの移行事例が増加。
　・PATH、JAVA_HOMEを差し替えればいいというわけではない話。
　　・OpenJDK 11.0.1→11.0.2で起動しなくなった。
　　　java.net.URLStreamHandlerに非互換変更が入っていた。
　　・マイナーリリースでも互換性がなくなるような変更が入ることがある。
　　　・リリースノートの提供は11.0.3からだった
　　・OSSになっているので今後はGithubのコミットログ、Issueから変更を洗い出せる
　　　→トラブル発生時の切り分け、調査方法も変わってくる。
　・OpenJDKに移行すると古いDBのバージョンはサポート対象外になる。
　　DBのバージョンアップ、マイグレーションが必要になる。
　・同様にアプリケーションサーバ(Tomcatなど)も。
　　→デプロイも必要になる。
　　バージョンアップに伴うアプリケーションサーバの仕様変更に注意する。
　　8.5以降だとファイル作成時のパーミッションの違いなどがある。
　　(昔、tomcatのバージョンアップに伴い、パラメータのデフォルト長が設定されるようになって、
　　　長いリクエストを投げるところで動かなくなった苦い経験がある。リリースノートの確認は大事だと思う。)
　・OSのバージョンアップも必要。
　・継続的にインフラをメンテしているシステムはうまく行っているが、
　　そうでないケースは苦戦している印象とのこと。今がラストチャンス。

・開発リーダー1年目。メンバーのスキルアップのためにやっていること。#ccc_g2b
　スライド資料：https://docs.google.com/presentation/d/1Xx5UPJkmy2dgzRloe8zaGGpEPWk1rhLiAMypK4TKRz8/edit
　・メンバーのスキルアップ
　　・輪読会
　　　　題材は「リーダブルコード」「レガシーソフトウェア改善ガイド」。
　　　　本の内容がすべて正しいわけではない。参加者で議論できるが良いところ。
　　　　業務中に発表資料の作成可とした。一人で読み込むよりは粗くなるのがデメリット。
　　・心理安全性の確保。雑談できる雰囲気。ランチタイム、仕事のことは話さない。
　　(輪読を業務の一環と認めてるのは良い。チーム全体の技術レベルの底上げは見返りが見込めそう。)

・Javaコミュニティなう　#ccc_cl
　　・用語の整理
　　　・Java SE 12：仕様、 OpenJDK12：実装　
　　　・Javaの仕様策定プロセス
　　　　 ・JCP：Java Community Process。仕様を策定するプロセス。
　　　　　 ・RI：参照実装、TCK：技術互換キットを作る
　　　　 ・JEP：実装ベース。仕様ではなく提案。並行して実装を進める。
　　　　　　　　使えそうならJSRに組み込まれる。ZGCとかはこっちの流れ
　　　　・OpenJDK ... Java SEのRIとして実装されるJDK。Oracleメンバーが80％を開発。
　　・JavaEE ... 開発停滞→ JakarutaEEへ。
　　　Jakaruta EE8→2019年後半にリリース予定。TCKも移管された。
　　　 ・ 新機能はjavax名前空間は使えない→商標問題。
　　　 ・javax.*はjakaruta.*に移行する方向性→ただし、いつ、どのようにやるのか具体策は未定。
　　　　　→全てのwebフレームワークに影響が入る。
　　　　　影響範囲が広いのでリグレッションテストができるようになっていたほうが良い。
　　・Javaのリリースサイクル
　　　・半年に1回定期アップデート。開発が間に合わない機能はドロップされる。
　　　・サポートは6ヶ月間←限られたリソースを言語の進化の方向に投入したいから。
　　　　 Javaエンジニアとしては追いつくようにしたい。
　　　・LTSは8→11→17→23。LTSだから大規模なアップデートになるということはない。
　　　　　 ...が、LTSだからなるべく機能を入れる、ドロップさせないようにする力が働くかもしれない。
　　　　　 今はVMの改良を頑張っているフェーズ。
　　　（dockerなどのコンテナ技術、サーバレスアーキテクチャだと
　　　 起動時のフットプリントの軽さを求める流れになっているからだろう。）
　　　・カンファレンス参加時の心構え
　　　　→don't　be shy. 周りの人とコミュニケーション取る。

・マルチテナントECシステムにおける拡張性と最新性の両立　#ccc_c3
　スライド資料：https://www.slideshare.net/ssusera756b0/ec-146376859
　　・標準ロジックの上にテナント毎のカスタマイズロジックを組み込む為の実装方法
　　　やり方は2つ
　　　・組込版→継承を用いた方法
　　　　・クラスローダーを用いて店舗毎にロードさせるクラスを変更させる。
　　　　・クラスローダーを用いる正当な目的とは
　　　　　・同一JVM内部でのスコープ分離。別のクラスローダーにロードされると
　　　　　　同一クラスでも別クラス扱い。今回のケースはコレ。
　　　　　・クラス定義の動的取得、変更→ネットワーク経由でクラスを動的ロードとか。
　　　　・URL→店舗情報→ファクトリメソッドにてカスタマイズクラスのインスタンスを取得。
　　　・API版→AOP、アノテーションを用いた方法
　　　　・AOPの仕掛けを作るときにJavassistを利用。
　　・セッション情報の維持
　　　・最近はjson形式でのエンコードが多いかも。
　　　・Javaのシリアライズ機構を使っている。
　　　　・やり方は以下の3パターン
　　　　　・デフォルト
　　　　　・シリアライズ対象外オブジェクトが含まれているケースなどカスタマイズが必要な時
　　　　　　・writeObject/readObject
　　　　　　・writeReplace/readResolve→インスタンスそのものをすげ替える
　　・テナント毎にDB情報はどのように切り分けしている？
　　　→スキーマによって分けている。

・テストエンジニアが教える JUnitを書き始める前に考えるべきテスト　#ccc_e4
　スライド資料：https://speakerdeck.com/nihonbuson/jjug-ccc-2019-spring

　・テストの目的（JSTQBによる）
　　・欠陥の検出。→デバッグして要員特定・修正はテストに含まれない
　　・対象ソフトウェアの品質レベルが十分であることの確認
　　　 ・十分≠完璧。バグがないことを示すことはできない。
　　・意思決定のための情報提示
　　　 ・顧客に製品の品質を示す。上司に意思決定の判断材料を提供する
　　・欠陥作り込みの防止
　　　 ・早期にテストすることの重要性。開発フェーズの早い段階で間違いに気づくことが重要。
　　・参加者ペアでチェックリスト作成ハンズオン
　　　・テストを先に作ることで、プログラムはないけど仕様の不明な点が洗い出せる。
　　・テストケースを作るときに何故それが必要か説明することはできるか。
　　　・よくある都道府県を選ぶドロップダウンリストの例だと...
　　　　・2つ。リストの最初と最後を選択できるか。
　　　　・4つ。都・道・府・県のいずれか。
　　　　・文字数のパターンで抽出
　　　　・各地位毎。例えば送料計算があるからなど。
　　　　・極端な例だと47全て。コード上に47パターンをswitch caseで実装しているところがあるから...等。
　　・テストケース名、テストドライバメソッド名を日本語の表記にするとわかりやすい。
　　・QAチームとの連携
　　　・単体、結合→開発者が品質を担保しなければいけない。
　　　・システムテスト→業務一連の流れ。QAチームが見たいのはこのレベル。
　　　　単体・結合テストの肩代わりをさせてはいけない。
　　　・checkとtestの違い
　　　　・checking→意図通りに動くか確認。自動化テストとはcheckingの自動化を指す。
　　　　・testing→製品破壊的なことをしても問題がないか確認。QAチームがやりたいのはこっち。
　　　　　・開発者はQAチームにcheckingをさせることがないように心がけること。
　　　　　　 →QAチームがtestingに注力できるように。開発者の心構え。
　　　　・自動化テスト→本当に肝心な部分、お金のかかる部分を自動化する。
　　　　　手動でやっても意味のないテストを自動化しない。
　　　　・オススメ本
　　　　　・ソフトウェアテスト技法ドリル―テスト設計の考え方と実際
　　　　　・[改訂新版]マインドマップから始めるソフトウェアテスト
　　　　　・ソフトウェアテスト教科書 JSTQB Foundation 第3版

　（・発表内容と直接関係はしないが、セッション中にリアルタイムでアンケートを取って、結果をみんなで共有できる仕掛けが面白いと思った。）

・ゴールドマン･サックスにおけるApache Beamを用いたビッグデータ処理の紹介と実例　#ccc_a5
　・GSの社員構成→社員の1/4以上はテクノロジー部門所属の技術者。
　　 社内で利用するソフトウェアの9割を内製→他社との差別化。
　・Githubでも様々なソフトウェアを公開している。Eclipse-collections、reladomo(Java ORM)等
　・Apache Beam
　　・GoogleがApacheに寄贈したデータフロー向けフレームワーク。Batch＋strEAM
　　・複数言語に対応しているが、日本語向けの文献は少ない。
　　・バッチとストリームの使い分け
　　　・バッチ：データセットが限定的かつ不変
　　　・ストリーム：データセットが限定的ではない、または可変
　　　　　 → GSで利用してるのは主にバッチ。月次レポート処理等に利用
　　・構成要素は主に3つ
　　　・Pipeline
　　　・Pcollection
　　　・Transform
　　　　　 Input　→　 Pcollection　→　 Pcollection... → Output
　　　　　　　　Transform
　　　　　　　　　　　　　　　　Pipeline
　　 ・対応 I/O
　　　 ・file-based、messaging、database
　　 ・構築したパイプラインの上でSQLを実行できる。
　　　　Beam SQLと呼ぶ。joinもできる。
　　　　クエリのオプティマイズも内部で行なっている。
　　　 ・Apache calsite
　　　 ・SqlTransform
　　　 ・Row
　　 ・コードの構築
　　　 ・pipelineを作る
　　　 ・pipelineを設計する
　　　　　・読込
　　　　　・変換
　　　　　・出力
　　　 ・pipelineを実行する
　　　　 ・これらをJavaのコード上で行う。
　　　　　　パッと見た感じはFluent Interfaceを多用し、
　　　　　　がしがしメソッドを繋げるような感じのコードだった。
　　　　 ・元々はこれらを構築する担当がいたようだが、pipelineの構成を
　　　　　　GUIで組めるようにカスタマイズしたらしい。デモを拝見したが、
　　　　　 今は亡きYahoo Pipesのイメージだ。GUIを使って作成したジョブは
　　　　　 Flinkに渡して実行される構成のようだ。Flinkの他Sparkでも実行できる。
　　　・質疑応答
　　　　・どのぐらい処理時間が短縮したか
　　　　　→重いレポートだと40-50分だったものが1分以内で応答が返る
　　　 ・テストはどうやっているのか
　　　　 → Transformに対してテストを行なっている。

　（・有用なライブラリを用いてただコーディングするのではなく、
　　　GUI使って構築作業自体を一段メタ化しているのがすごい。
　　・並列性の高い参照処理なら確かにマシンパワーお金をつぎ込めば
　　　つぎ込んだ分だけ、処理短縮に効果を発揮ししそうだ。）

・JJUG会長と一緒に考えたSpring Boot x JavaScript x IntelliJ x アジャイルというモダンな新人研修を今まさにやっている話　#ccc_e6
　スライド資料：https://speakerdeck.com/masatoshitada/modern-new-employees-training-spring-boot-javascript-intellij-agile
　・従来型の新人教育と現場との乖離
　・従来型教育の課題
　　・設定された課題を達成することがゴールになっている。
　　・チーム内コミュニケーションが文書、口頭伝達のみ
　　・技術がダサい(Java＋Servlet＋SQL only)
　　・学習が受け身→技術変革が次々と発生するので主体的な学習が求められる。
　　・コミュニケーション
　　　 ・従来型 → フォルダをバージョンごとに切る
　　　 ・モダン → git、gitlab、チャットツール(slack)
　　 ・研修のカリキュラム例
　　　　・IT基礎
　　　　・Java(15年変わってない。日付に関する内容もJava8導入のDatetime APIには触れない)
　　　　・web(JS扱わないけど、最近はクライアントサイドの開発が必須)
　　　　・開発演習(EC or予約サイトが定番。構成管理(git)は使わない)
　　　　 →登壇者の感覚だと、世間の9割がこのタイプの研修。
　　・モダンな研修にする際の課題(カサレアルは研修を作る会社なので踏み切れない)
　　　・モダンな研修にしても売れるかわからない
　　　・Strutsな現場が多い
　　　・人事が技術に疎い
　　・モダンな研修
　　　・クライアントサイドからサーバサイドまで一通り自力で作れる
　　　・各種公式ドキュメントが調べられる。英語読めなくても翻訳する姿勢が大事。

　　・研修で用いたシステム構成
　　　 ・SPAアーキテクチャ
　　　　　クライアント　｜　サーバ
　　　　　React　 　　　｜ Spring Boot
　　　　　material-UI　 ｜ JDK11
　　　・Servlet APIは隠蔽される
　　　　 新人教育レベルならServletの知識は不要と判断
　　　　 ・Servlet、JSP、JDBCは扱わない→SpringDataJDBC、MyBatisを利用
　　　　　・JDKはAdaptOpenJDKを使用→自宅学習でもライセンスを気にせず利用できる。
　　　　　・開発環境
　　　　　　　 受講生ローカル 　　研修サーバ
　　　　　　　IntelliJ＋git　 ⇆　docker(擬似クラウド)＋GitLab(講座内容)
　　　・講座スケジュール
　　　　・技術研修は4月中旬から6月中旬まで。2ヶ月ぐらい
　　　　　・全体概要説明とGit(2日)
　　　　　・クライアントサイド(8日)
　　　　　・サーバサイド(13日 Java含む。Java自体は軽めの2日)
　　　　　・開発ワークショップ(13日)
　　　　　　・ソースコード静的解析ツールを導入(esLint、CheckStyle)
　　　　　　　 →明らかにコードは綺麗になる。レビュー負担の軽減。
　　　　・研修を変えたことに変化
　　　　　・現場の技術に馴染むのが早い
　　　　　・SPA API アーキテクチャ 用語の理解
　　　　　・理解度は例年通り。Servletを学んだケースと変わらないが、学んだ幅が広いので、
　　　　　　受講生の学ぶ意欲は高い。→学ぶ範囲が広いので要所要所でまとめ、復習する時間を設けた。
　　　　　・クライアントサイドからサーバサイド技術を学ぶ順番が良かった。
　　　　　　GUIで自分たち作ったものに対する実行結果が早く確認できる。興味を引きやすい。
　　　　　・ServletやJSP、JDBCは触れなくても問題がなかった。
　　　　　　SpringでもServlet技術を要するのはフレームワークの動作自体に手を加える限られた人。
　　　　　・企業によってこの方法に合うケースと合わないケースがあるだろう。
　　　　　　 ・今回の形で実施したケースはまだ3社のみ。
　　　　　・質疑応答(登壇者と同じようにプログラミング研修に関わっている方が会場内には多かった)
　　　　　　 ・プログラム初心者の反応はどうだったか
　　　　　　　 ・Servlet研修時の反応と変わらない。ルールが多いので伝える必要あり。
　　　　　　 ・研修を始める前の受講者のレベルは
　　　　　　　 ・一例での研修対象者は10人弱。
　　　　　　　　　経験者は半分、トップクラスだと学生からコーディングをたくさん
　　　　　　　　 やっていたメンバーもいる。少し触れた程度の経験者は1/4。残り1/4が未経験者
　　　　　　　 ・今回の研修は全員名経験者を想定して作成している。
　　　　　　　 ・講師一人で20人見ている。でも静的解析などのツールの助けが必須。
　　　　　 ・受講者と講師の役割分担
　　　　　　 ・元々はサブ講師がスクラムマスターとプロダクトオーナー役を兼ねた。
　　　　　　　　→受講生側に作成側の意識を醸成するためにプロダクトオーナー役は
　　　　　　　　　 別チームの受講生としている。

　（・研修のアップデートは大事だけどかなり思い切った構成だと感じた。特にSpring採択。
　　・一応未経験者向け研修とのことだったが、最初から割と知識がある集団がいるからよりうまく回っていたのでは
　　　無いかなぁと想像。会社によって合う合わないはかなり意見が分かれそう。
　　・受講生側のスキルも世間一般よりも高いのでは無いかと感じる。

・Functional Spring Cookbook　#ccc_a7
　スライド資料：https://docs.google.com/presentation/d/1-0NopTfA-CGiCNvKPDOH9ZDMHhazKuoT-_1R69Wp8qs/edit#slide=id.g566754e519_6_0　
　・Functional Springという用語があるわけでは無い。
　・annotation style→easy
　・Functional style→simple
　・simple(必要なものだけ)≠easy(最小限の作業)

　・Spring は二つ通りのやり方がある
　　・Spring MVC Mvc.fn
　　・Spring WebFlux.fn(Spring 5.1から)
　・アノテーションではなく、関数でルート定義を書く。
　　(このスタイル、Angularのrouter定義を彷彿とさせるやり方だと感じた。)
　・Githubにサンプルあり。
　・Bean Registlation
　　・application context→あまり書かない
　　・＠Compornent →scanさせる方法
　　・＠Bean → これをprogramaticにさせる。
　・HTTP Client reactiveに使う方法の紹介。cash→メモ化
　・Bean Validation 標準で用意されているものは使いづらい
　　→作った。YAVI；やばい Yet Another Validation
　 ・Either API Either...モナド
　・DataBaseAccess
　　 WebFlux.fnではR2DBCが使える(rはReactiveから来ている)
　・＠によるアノテーションを取り除くと...フットプリントが小さくなる。起動が速くなる。
　　・サーバ起動デモ→アプリケーションサーバの立ち上げ0.7秒！
　・SpringFu　実験レベル。まだプロダクトで使ってはいけない。
　　・ServletとSpringのコードが同じようにかける。サンプル例だと1行違うだけ。フレームワーク固有の書き方をうまくラッピングしてくれている。
　　(このような仕掛けが発展すれば一個前のセッションで話していたServletの技術は無視しても良くなるのかもしれない。)

・海外からの参加メンバーが多いけど、相変わらず言語の壁を感じてしまう。もったいない。今回はOracleの開発カードの電池をもらえたぐらいのコミュニケーションしか取れなかった。開発者が多いけど英語のセッションが増えてきている。次回は挑戦してみたい。（会社の同僚はグイグイ話していた。すごいなぁ...。）