JUnit4とJUnit5の違い（境界値テストのパラメータ化の際等、いろいろと）を聞いてきた！

５月２６日、JJUG CCC 2018 Springに行ってきた！ので、その内容をメモメモ

はじめに

まだまだこれからJUnit5入門

をメモメモ

---

・まあ、まだそんなに使ってないよねJUnit5
・JUnit5とは
　Javaのテスティングフレームワーク
　ながらく４が使われていたが、その光景
　API/アーキテクチャの全面的な再設計
　１７年９月からGAリリース
　１．８いこうでないとX、ラムダ式のアサーション

・テスティングフレームワークに何を求めますか
　簡潔さ
　可読性
　一貫性

・イントロダクション
　　何がよくなったのか
　　　テスティングフレームワークにとって大事な部分がちゃんと進化

　　　代わりに失ったもの：互換性
　　　　１．８＋、パッケージ異なる。構造化テスト、パラメータテスト異なる
　　　　フレームワーク、IDEの対応状況
　　　　mavenはびみょーなところも

・セットアップ(maven前提）
　　JUnit4 pom.xml シンプル
　　JUnit5 pom.xml なんか増えてる・・これ何？
　　　　→マルチモジュール構成：用途、環境に合わせて適切なものをインポート
　　JUnit5 = JUnit Platform　　　実行基盤
　　　　　　　＋　JUnit Jypiter　新テストAPI
　　　　　　　＋　JUnit Vintage　マイグレーション

　代表的なモジュール
　　　JUnit jupiter-api アノテーション多い
　　　JUnit Jupiter -engin
　　　JUnit platform launcher これないと、eclipseで動かない

モジュール間の依存関係：公式に出てる・・・よくわかんない
　　　pomで指定するのは多くない

　pom.xml
　　　junit jupter engin
junit platform lancher
Mavenならjunit platform surefine provider
Gradleは４．６からネイティブサポート
　→５．２からはBOMを使う

・シンプルなテスト
　@Test
　　JUnit４と、ほぼ同じだか、パッケージ異なる
　　@org.junit.jupiter.api.Test ハブリックでなくてもOK（プライベートはX）

　事前処理、事後処理
　　　@BeforeAll
　　　@BeforeEach
　　 afterもおなじ

　実行を無視する　@Disabled reasonにメモ書きできる

　テスト名の表示：@DisplayName（Mavenではまだ）

　--- ここまでは大体JUnit4と同じ ------

・アサーション
　org.junit.jupiter.api.Assertions
　assertEquals 基本使い方は同じだが、引数の順番が変わった
　グループ化：
　　　JUnit4：途中のassertに失敗すると、次のassertは実行されない
　　　JUnit5:assertAllラムダ式を渡す。渡した式が、検証に成功すると、成功になる

　例外の検証
　　　JUnit4:@Testのexpectedに例外クラスを指定する→投げられたメッセージの検証はできない
　　　　　　　→外側でcatchしてしまう
　　　JUnit5:assertThrows　例外を投げるメソッドは、ラムダ式の中で実行

・使いたくなってきました？

・構造化テスト・パラメータ化テスト
　構造化テスト
　　テストクラスは複雑になりがち→似たようなテストは何とかしてまとめたい
　　JUnit5: @Nested
　　　　　　@Testと並べて書ける

　パラメータ化テスト
　　引数だけ違うテストをまとめて実行したい
　　　境界値テストなど
　　JUnit4:@Theory
　　JUnit5:pom.xmlにパラメータを追加
　　　@ParameterlizedTest
　　　@ValueSource：ほかにもソースの指定あり（@methodSource)

・拡張モデル
　　JUnit4では拡張方法２つ
　　　Runner
　　　Rule
　　JUnit5
　　　extention
　　　　@extendsWithで指定する（複数可）
　　　　BeforeEachCallbackなど拡張ポイントいろいろある

・マイグレーション
　戦略
　　１．JUnit5で書き換える
　　２．Vintageで動かす

　書き換える場合
　　　引数の順番が変わった

　JUnit Vintage
　　　既存はVintage,新規はJupiter
　　　４と５、ごちゃませにしないようにしたい

・まとめ
　　（おぼえるのが）はやい、（かき）やすい、うまい
　　IDEの対応状況
　　ユーザーガイド一読

「なくなるJava SE無償版」って、まじ！（＠＿＠！）

米オラクル（Oracle）はこれまで、Java開発実行環境「Java SE」（Java Platform, Standard Edition）を無償で提供してきた。ところが、2018年9月からは有償版しかなくなる

ま、まじ（＠＿＠！）

【詳しくは＆上記引用元（５月２４日５時まで見れる）】
なくなるJava SE無償版、ユーザーはどうなる
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00294/051700002/

JavaEE8の後、Eclipseが引き取り、EE4JじゃなくってJakarta EEになった？

前に、

JavaEE8のあと、Eclipseが引き取って、EE4Jになる件
https://blog.goo.ne.jp/xmldtp/e/5bcbb2505950b26418ab54bf615079d6

っていうのを書いたけど、

Jakarta EEをサポートするワーキンググループがEclipse Foundation内に設立
http://www.fujitsu.com/jp/products/software/middleware/business-middleware/interstage/resources/news/topics/2018/0424/

の話をみると、EE4Jじゃなく、Jakarta EEになった？

イマドキのJavaScript

書き方まとめがあったので、ＵＲＬをメモ

イマドキのJavaScriptの書き方2018
https://qiita.com/shibukawa/items/19ab5c381bbb2e09d0d9

JavaSE9のつぎは、18.3じゃなく、やっぱ10にする、テヘペロ（＾＾；）だって

１１月１８日にJJUG CCCに行ってきた！
つづき
（表題の件は、一番初め「JDK新しいリリースモデル」）

---

■JDK新しいリリースモデル
・Java One前後から情報が出ている
　この資料は、共有できません
　→情報的に動くため

・ＪａｖａＳＥ９
　けいでんす：リリースモデルを変えるぞ！
　JDK 9
　　　７のとき、理想高かった
　　　７で考えていたものが乗った
　９１の機能ＵＰ

・リリースサイクル長い
　大きな機能を待つ：小さい機能が待たされる
　言った通りに出してくれ！！！
　　　２年おき、本当かよ！（理想です）
　ライセンスモデルの問題：再配布不可

・他の言語と比べてみる
　　Ｇｏ：半年に一度
　　Ｊａｖａ：間延びしてきている

・ＪａｖａＳＥの選択肢
　　Ｏｒａｃｌｅから
　　ＯｐｅｎＪＤＫ

・ＪＣＰがＯＫすると出せる
　　ジグソー：１回目ひけつ

・新しいリリースモデル（きのう現在）
　まえから・・・だいぶかわった！！

　より計画的なリリースサイクル：６か月ごとメジャーバージョン

　だすのはＯｐｅｎＪＤＫ
　削除提案と、削除も６か月の中で行う

　OpenJDK＝無償で使ってもらうもの、バイナリーも出す
　オラクルも暫定期間出しているが、ゆくゆくは。。。
　同じ機能に機能強化：１年後

　ＧＰＬにする
　　＆　クラスパスえくせぷしょん
　
　商用サポート継続、コミュニティ継続

・ＯｐｅｎＪＤＫの強化
　　アプリケーションクラスデータ共有
　　Ｚガベージコレクター

・従来のリリースモデル
　　従来：技術的な差があった
　　２年に１度のリリースが目標だった
　　長期サポート
　　更新リリース

・新しいリリース
　技術的な差なくなる
　６か月に１度
　リリース重複期間なくなる
　Ｏｒａｃｌｅはサポート８年間、帰納更新はしないセキュリティパッチ

・１１が出てくるタイミングでＯｒａｃｌｅ　ＪＤＫはなくなり、
　ＬＴＳ版のみになる

・１８．３、１８．９を、インクリメンタルな数字に戻した
　JavaSE9のつぎは、18.3じゃなく、やっぱ10にする、テヘペロ

・これからは、シングルソースコード

・いまは、ＯｒａｃｌｅＪＤＫもバイナリ提供

リリース情報
・ＯｐｅｎＪＤＫ：いままでどおり
　１０のearly access版も
・リリースノート
　削除されるＡＰＩがリストアップ
　　　CORBA関連なくなる
→１年後に機能がなくなる

・ＪＣＰが仕様の承認は今のところ変わってない

・公式アップデート終了のスケジュール
　８　無償アップデート終了　２０１８年９月
　９　無償アップデート終了　２０１８年３月
１０　無償アップデート終了　２０１８年９月

８までのバージョンの移行先は、１１以降

商用サポート

デプロイメントテクノロジー：サポート短くなる
　（アプレット使ってる場合注意）

・直近のアップデート
　ＪＤＫ　１０　Early Access ビルド
　ＯｐｅｎＪＤＫでもＬＴＳサポートという話が出てきた
　　今後の情報に期待
　jlinkを使ったパッケージ
　３２ビット版のバイナリ提供はない（９でもない）

■ついにきたリアルタイムSpark
　ビッグデータ処理の新定番SnappyDataとは

・SnappyData知ってる人・・・０
・自己紹介
・現在のビッグデータ処理の課題
　　複数プロダクトを組み合わせて複雑
　　時間かかる
　　パフォーマンス悪い
　　キャッシュだと速いが・・・

　よくある要求

　　ＲＤＢ→分析はＤＷＨ

　ビッグデータ
　　ＮＯＳＱＬでスケールアウト→分析ＳＱＬおんHadoop→ストリーミング

・技術を積み上げると、つぎはぎのシステムになりがち
　　ＴＣＯ増大
　　非効率
　Ｓｐａｒｋ登場後はかなりシンプルになったものの
　　Ｓｐａｒｋ，ふりんく
　→SnappyＤａｔａは１つでできる

・SnappyData：データベース機能を備えたSpark
　ベースとなっている製品がインメモリ

・主要機能
　Sparkのコア、マイクロバッチ
　分散インメモリ：ローテーブル、インデックス

・ＳｎａｐｐｙＤａｔａ
　インメモリデータベース
　データ保持形式
　クラスター統合
　ＳｐａｒｋＳＱＬを高速化

・（１）インメモリデータベースにデータを保持している


・（２）Ｓｐａｒｋと同一のデータ形式で保持している
　違う形式だと：型変換、シリアライズ・でシリアライズ

・（３）Ｓｐａｒｋとインメモリ―ＤＢのクラスターを統合できる
　もう一つのクラスターモード（参考）
　　別々にして個別にスケールアウトもできる

・（４）ＳｐａｒｋＳＱＬを高速化している
　ＤＡＧがそもそもちがう
　ステージまとまってる：通信起きていない
　ＳＱＬワークロードを一部いじって高速化


・ＳｎａｐｐｙＤａｔａの使い方
　クレジットカード不正使用検知システム
　　ＳＱＬで書ける
　・ストリームデータ処理：マイクロバッチストリーミング
　　コンテニュアスクエリー：Window指定
　　テーブルをつくるのもＤＤＬと同じ
　　
　・トランザクション処理
　　データの追加。更新、削除が可能

　　データの特性によっててーうる形式を使い分けることも可能
　　　Row table,column table

　　レプリケーション、パーティションを使い分ける

　　トランザクション処理もＲＤと同様に使用可能
　　　一部出来ないものもあるが、近い形で

　　Ｐ２Ｐ型アーキテクチャ
　　　書き込みもスケールアウト

　・アナリティクス処理
　　リアルタイム分析：近似クエリ、ＴＯＰ　Ｋテーブル

　　サンプリング技法を活用
　　　→サンプルテーブルを作る方法と直接クエリーする方法がある

　　ＴＯＰＫテーブル
　　　→ＣＲＥＡＴＥ　ＴＯＰＫテーブルでＯＫ
　　　　たぶろう、ちぇっぺりん、ずーむでーたでみよう
　　
　　ＪＤＢＣアクセス

　・サマリー
　　Ｓｐａｒｋ１００％コンパチブル
　　ＳｐａｒｋといんめもりーＤＢ統合
　　テーブルとＳＱＬ
　　高速化

■最近のDeep Learning事情とJava
・自己紹介

・仕事でDeepLearningしてるひと　ちらほら

・DeepLearningの歴史と経緯
　人工知能：１９５６～
　機械学習：
　深層学習：

2012年のDeepLearning
　ILSVRC：ヒントン教授（２００６年から）
　Googleの猫

2014年のDeepLearning
　ＡＩに仕事がう会われる
　ＤｅｅｐＭｉｎｄ買収
　ドワンゴ人工知能研究所
　画像から文章

2015年　あるふぁごー

ＡＩの定義は明確に決まっていない

・アトム：強いＡＩ
・弱いＡＩ：これだけならできる、専用機：ディープラーニング

・ディープラーニング

・ディープラーニングの基本的な原理
　基本的な原理の一部のみです

　ニューラルネットワーク
　ニューロンモデルをつなげた
　　入力層：データのベクトル化
　　出力層：どう表現するか

　学習するとは：落ち着くところに向かっていく

　畳み込みニューラルネットワーク
　　畳み込み層　プーリング層

　再帰型ニューラルネットワーク（ＲＮＮ）

・ディープラーニングの教科書が出た
　パターン認識と機械学習は９年前
　ディープラーニング

　これならわかる深層学習入門
　仕事で始める機械学習（Ｐｙｔｈｏｎ前提）

　ハード面
　　ＧＰＵ
　　なぞのＵＳＢ
　　Ａｌｐｈａｇｏ　Ｚｅｒｏ

　DeepLearning資格
　　ジェネラル、エンジニア

・DeepLearningとJava

　DeepLearning for Java
　ＤＬ４Ｊ
　
　Python：ライブラリ豊富

　フレームワーク
　　exampleでやれることを確認（今日からＤＬ４Ｊ）
　　githuで質問
　　ユーザーグループある
　　１１月３０日にイベントある

JavaSE9に移行するには、module-info.java書いてrequires等するとか

11月18日にJJUG CCCに行ってきたので、
その内容をメモメモ
まずは、前半（表題の件は、最後のほう
「JavaSE9の紹介：モジュール・システムを中心に」で記述）

---

■サンプルアプリケーションで学ぶ
Apache Cassandraを使ったJavaアプリケーションの作り方

・コード Github スライドslideshareにあがっているよ
・Cassandraなにか知ってること前提
・自己紹介
・今日の目標
　→サンプルアプリケーションがあるというところを持って帰ってください
・アプリケーションの変遷
　モバイル、ＩｏＴ：ユーザー増えてきた
　→スケールするアプリケーションを支える
　　データベースもスケールしないと

・Cassandra：スケールしてもパフォーマンスを落とさない
・サンプルになるソース　あります
　http://killrvideo.com
　　→https://killrvideo..github.io/
　　→これを、持って帰ってください

・KillrVideo
　スケーラブルなマイクロサービスアーキテクチャ
　アーキテクチャ
　　スケーラブルにできるように想定
　Javaでも環境
https://github.com/killervideo/killrvideo-java
　　デモ：起動してみる

・Ｗｅｂ層
　node.jsで実装（フロントエンド）
　React,Rcore
　セッション管理にCassandra利用：CassandraSession
　ユーザー認証はマイクロサービス利用
　→Javaだろ、spring-session,apache shiro

・マイクロサービス
　gRPCを利用
　　プログラミング言語非依存
　　プロセスを分けるならKafka連携とか

・gRPCとは
　Googleの内部RPC(Stubby)をもとにオープンソース
　ProtocolBuffer v3を利用、HTTP/2、双方向ストリーミング
　　gRPCサービスの定義
　　スタブの自動生成：mavenプラグインで
　基本はStreamObserverを利用した非同期呼び出し、
　　非同期実行、同期実行
　Springから呼び出し、

・Cassandraに接続
　ドライバ作っているよ（やりとりは、こみにてぃで議論）
　　クラスタービルダーを作って、接続するＩＰアドレス、認証情報などを設定
　　クラスター作る
　　生成
　セッション：コネクションプーリングを管理

・Cassandraのデータモデリング
　データモデリングの原則
　　データを知る
　　クエリを知る
　　非正規化
　　　データをネストする
　　　データを重複してもつ
　　→Joinの機能がない

　なぜ：クエリがスキーマのデザインを決める
　　→クエリの変更はスキーマの変更を伴う
　　→特異なアクセスパターンは限られている
　　　　Ｘテーブルスキャン、複数テーブル
　詳しくは
　　RDB開発者のための・・・　スライドシェアでみてね！

・ドライバーの利用
　バッチ登録
　クエリービルダーの利用：ステートメントの組み立て
　ページング：取得件数の指定とページング resultsetで
　　　オフセットページング（いきなり５ページに飛ぶとか）は実装されてない
　実行結果の取得：resultsetの中に、自動ページング機能→裏側で自動フェッチ
　データマッパー：エンティティクラスの準備、マッパーの準備

・まとめ

　　https://killrvideo..github.io/

　マイクロサービスを利用したスケーラブルなアプリケーションを作るときの参考に
　　アーキテクチャ
　　フレームワーク・ドライバー
　　データモデリング

■サーバーサイドkotlin
・書けば普通に動く
・日本語の響き：かわいい→そこがネック
・まえおき
　kotlinはそれほどとがった言語ではない
・結論
　サーバーサイドでも問題なくkotlinは使えます
・今日喋ること
　なぜkotlinメインに
・自己紹介

・作ってるもの、秘密（Ｗｅｂアプリ）
　AWS、バックエンドPostgres,認証cogniteに任せてる
　思い処理はらむだに
　webアプリケーションサーバー、らむだ、でkotlin使う
　→クライアント側は書いていない

・なぜkotlinを採用したか
　Javaの言語について：２０年以上たっている。冗長
　　classのなかにメソッドを書くのはめんどくさい
　　検査例外：kotlinはない（上に投げられる）
　　Lombok：冗長性をある程度解放
　　　Javaでもある程度ハッピー
　　　関数がオブジェクトでない
　　　荒ぶるlombok
　不満があっても、ＪＶＭ自体は悪くない
　　python２→３の互換性に比べて
　Ｊａｖａの豊富なライブラリ
　JVM言語でBetter Java→学習コストが低いこと

・Scalaは悪くない、でも、難しい…
　型合わせゲーム

・そこでkotlin
　Javaの不満をある程度解消、scalaほど複雑でない
　Androidの正式開発言語
　Javaとの相互運用性
　
・開発環境・フレームワーク・ライブラリ
　ＩＤＥ：Eclipse,IntelliJAndroid Studio
　フレームワーク：
　　　kotlin製　kter、から、わさび
　　　Java製：Spring Boot
　ＯＲマッパー
　　　Exposed：バｇつが多い
　ビルド
　　　基本的にgradle（こだわりない）
　　　finalを外した状態で

・使ってみて
　kotlinのstream的なもの
　　ベンチマークのテストやってみた
　　kotlinおそい→asシーケンスで早くなる
　annotationの違い
　デフォルト引数とＤＩ

・不満なところ
　ぱいぷらいんがほしい
　（）は省略したい

・けつろん。もんだいないだいじょうぶだ。


■JavaSE9の紹介：モジュール・システムを中心に
・自己紹介
・あらまし
　JavaSE9：モジュールシステム
　地味なアップデートも外観

・そもそもＪａｖａＳＥって？
　ＪａｖａＳＥ　処理系の規格（すたんだーど　えでぃしょん）
　ＪａｖａＥＥ　エンタープライズえでぃしょん　サーブレット、ＪＭＸ，ＥＪＢなど

　ＪａｖａＳＥタイムライン
　　２００４　ＪａｖａＳＥ５　じぇねりくす、マルチスレッド
　　２０１４　ＪａｖａＳＥ８　ラムダ式、ストリームＡＰＩ
　　２０１７　ＪａｖａＳＥ９　モジュールシステム　じぐぞー
　→字面は比較的地味、基盤はおおきい

・目的
　心の準備ができること
　
・CCC_E4のハッシュタグにリンク貼ってある
　そのスライドで「高度」な話観てね

・背景
　Jave8までの課題
　　　JAR地獄
　　　内部パッケージ
　Java8内部向けパッケージ

・モジュールシステムの基本
　ＪＡＲファイルを配置の単位に
　　モジュール単位で依存関係を整理
　内部向けパッケージを使えないようにする

　パッケージ衝突の検知
　モジュール名を付ける
　module-info.java
　exports命令で公開パッケージを指定できる
　　→自分自身が使うモジュールをrequires命令で指定する
　　　require先がないと、コンパイルエラーになる

　標準ライブラリもモジュールに
　　java.baseはrequireされている

・リフレクション
　こまるときＤＩ
　　パッケージをexportしたくない、publicしたくないけど、リフレクションしたい
　　→opens命令
　→リフレクションは魔法の杖ではない

・コンパイルと実行
　モジュールパスという配置方法
　　クラスパスとは別
　実行：初期モジュール（mainモジュール）から推移位的に参照されるモジュール
　だけが実行モジュールに入る

・経過措置
　無名モジュール：クラスパスのクラスは、無名モジュールに入る
　自動モジュール：モジュールパス上にありながらmodule-infoにない
　　　オートマチックモジュールネームまたはjarファイル名から

・移行
　ライブラリ：今すぐモジュール化
　プラグイン
　ＡＰサーバー上のアプリケーション
　
・ライブラリのモジュール化
　jarファイル名ベースの自動モジュールをrequiresしてはいけない！
　８以前のサポート

・テスト
　２種類のテスト
　　ブラックボックステスト
　　ホワイトボックステスト
　JUnitなんかにどうやって入れる？

　方法
　　正攻法：一時的に書き換える
　　次善の策：クラスパスに入れる

　Java9モジュラりてぃ　おらいりー

・他のＵＰＤＡＴＥ
　コレクションのファクトリ
　try-with-resources
　インターフェースのprivateメソッド
　匿名クラスにダイヤモンド演算子
　リソースバンドル：いままでlatin1だったが、ＵＴＦ－８でＯＫになった
　（プロパティはlatin1のまま）
　Reactive Streamsサポート

　プロセスＡＰＩの強化

JavaEE8のあと、Eclipseが引き取って、EE4Jになる件

１０月２１日、
Java SE 9/EE 8リリースイベント 兼 JavaOne 2017 報告会 @ 東京
https://jjug.doorkeeper.jp/events/66256
に行ってきた！話のつづき（表題の件は、真ん中からうしろのほうにかけて）

---

（前の話のあとから）

■Java9 and Future
・情報保障
　Web公開
https://www.slideshare.net/YujiKubota/java9-and-future-jjug
　コードはgithubに公開
github.com/ykubota/jigsaw-sample_jp

・自己紹介

・Ｊａｖａ９リリース、１か月たったけど、
　アンケート
　　　プロダクションで使っている人：１人
　　　ローカルで使った人：結構いる
　　　調べた人：おおくいる
　今回は詳しく
　次のJavaちら見 18.3

・追加された機能の確認方法
　JEP(Java Enhancement Proposal）を見る

・移行する際に注意するポイント
　Migration Guideを読む
　　・非互換性、マイグレーション手順が書いてある

・全体的な解説
　「Java9に備えよう」の資料

・より細かく見る（サポートレベル）
　SpecificationやRelease Noteを読む

・ログが変わる
「Unified JVM Logging」で発表した

・メリット
　モジュール化
　REPL(JShell)
　ライブラリ改善：Collection初期化、Stream機能拡張
　セキュリティ強化
　付属ツールの刷新（診断とコンパイル）　ＡＯＴ
　Ｇ１ＧＣコンパイラなどの性能改善（デフォルト化）
　　→おおきなヒープ

・デモ
　JIGSAW
　　いままで内部ＡＰＩをそのまま実行できた
　　→モジュール化すると：公開ＡＰＩを限定できる
　ひとつひとつビルドすることも可能
　どのモジュールのメインクラスを実行するか指定して実行
　結構強力な機能が備わった・・・らしい？

■JShell with JDK9 Libraries
・自己紹介
・JShellの説明
　９入れた人はJShell使っている
　Java言語に向けたREPLツール
　　Lisp,Python,haskellなど
　教育分野ではREPLツールがある環境が人気
　　ＡＰＩ・構文挙動確認
　https://tryjshell.org
　　Web上からJShellが使える
　Jshellにようこそ
　　補完機能：利用できるimport、変数定義の保管
・Java9ライブラリ
　コレクションのファクトリ
　Streamの評価
・コレクションのファクトリ
　　List.of,Set.of
　特徴
　　いみゅーたぶる：もとが変わっても変わらない、変更もできない
　　ふぇいるせーふ：例外として検出できる
　　最適化
・ストリーム：いままでむげんにやっていたものを
　　dropWhile：条件が出たら、処理を終了する

■（Java9 and Futureつづき）
・これからのJava Java18.3→走り始めている
　JDK Projectで確認できる
　スケジュールと機能の一覧
・Project Amberが入る予定
　将来 　
　Project Panama
　　Project vaslhalla

・リポジトリやバイナリ（ＥＡ）は独立予定

・Project Amber
　varで変数宣言できる
　switch caseで型推論

■Intel's Persistent Memory
・パーシステントメモリー
　知らない人多い：新しいタイプのメモリー
　　容量４倍、２分の１の価格で求められるメモリー
　　電源が切れても、内容保持
　　市場に登場するのは、来年頃
　Oracle Open worldでも話しあった：
　　Oracle DataBase18cでＰＭサポート
　３Ｔバイトのデータベース、１．５Ｔ　ＤＲＡＭ＋ＰＭ
　　→クエリ５倍速くなる
・ＰＭ in Java Platform
　Java oneのセッション
　２つのつかいかた
　　　ぼらたいる（揮発性）：メモリ
　　　パーシステント　ストレージ

・ボラタイルな使い方
　１　ヒープを全部のせる→データが大きいアプリ：インメモリ、ビッグデータ
　　　　JVMのオプションにマウントポイント指定

　２　ヒープを一部のせる→ユーザーが指定できるまたはプロファイリングで自動指定
　　　アクセス頻度高い：ＤＲＡＭ
　　　頻度低い、データ大きい：ＰＭ

　プロトタイプ

・パーシステントメモリ
　https://github.com/pmem/pcj にデモ
　（絶賛開発中）プロトタイプ

　デモ：ＲＡＭディスクでエミュレートできる
　　高速に書き込み、読み込みができる

・パーシステントに書き込む：永続化可能なクラスの定義
　extends PersistentObject
　Panamaでやろうとしているクラス定義の仕方

・まとめ
　PMすごい：IntelがJavaに力いれてる
　PMをメモリとして使うか、ストレージとして使うか
　　メモリと使うなら結構早くに
　　ストレージはPanamaまち？

---

ここからJavaEE8

■JavaEE/EE4J
・ここで聞いたことが変わっても、ごめんねっていうかんじ
・自己紹介
・あじぇんだ
　ＥＥ８でましたね
　ＥＥ４Ｊってなに
　ＪａｖａＯｎｅのはなし

・まずＥＥ８
　９月２１日、でました（４年かかった）
　去年のＪａｖａＯｎｅ　：８やる
　　どれやるという投票
　　　ＭＶＣ１．０おちて、こみにゅてぃに引き渡し
　　　ＷｅｂＰｒｏｆｉｌｅ：へる
　メインはＪＡＸ－ＲＳでリアクティブ、ＣＤＩ、非同期イベント
　セキュリティひとまず
　メンテナンスリリース
　　→Ｊａｖａ　ＳＥ９でアップデートの物も

　→JavaEE、Githubに移管

・JavaEE８→参照実装GlassFish 5.0
　オープンソースでも
　Java9　５．０．１で動作保障
　Dockerイメージ使える

・赤いJava、アオイＪａｖａ
　ことし：Glassfish
　赤いJava(Oracle)：WebLogic来年
青いJava（くらうど）：そのさき

　→あかいJavaおしまい

・Eclipse Enterprise for Java(EE4J)
　Java
　　オープン
　　evolving
　　Nimble
　　Scalable

　ＥＥ８
　　オープンか？
　　にんぶるか？
　→eclipseファウンデーションに移管。
　　移管プロジェクトがＥＥ４Ｊ
　　ブランド名ではない

　移管して
　　Open
　　Compatible
　　Flexible
　　Nimble

・Ｏｐｅｎ
　プロセスを透明化。たくさんの人、みんなでつくる
　→Oracleはスペックリードの座から降り、ほかの会社と同じ立場で
　　スポンサーはeclipseファウンデーション
　プロジェクトチャーター（憲章）を作る

・コンパチブル：互換性を持たせる
　　GlassFishを再ライセンス、
　　ただし、資産自身はすべてOracle

・フレキシブル
　ハードルを下げる
　配布もEclipseライセンス

・Nimble
　２０１８年中旬までに移管したい

→マルチベンダー

・EE4J　ＦＡＱがある

・EEをどうサポートするの？
　今の段階でわかっていること
　既存の契約は尊重
　ライセンス契約も
　ＪａｖａＥＥ８　
　　２０２５年までにＥＥ４Ｊに移行するように計画
　　その先はＥＥ４Ｊの情報

・そのあと
　　ＭＶＣ１．０→ＥＥ４Ｊに入る
　　Yasson,EclipseLink→ＥＥ４Ｊに入る

・ＪａｖａＯｎｅのパネルディスカッション
　　　eclipse,IBM,Redhat,tomitribe
　去年のマイクロプロファイルとJavaEE8のパネルディスカッション
　　　payara,oracle,IBM,Redhat,tomitribe

・マイクロプロファイル：タイムボックスリリース
　　→将来的にはマージ
　　　ＥＥ８の機能が入っていないので、今後はいる
　標準化団体：できればつくりたくない→スピードを上げる

・まとめ
　ＥＥ８でた
　ＥＥ４Ｊはじまった（なにもきまっていない）

■JavaOne2017参加報告
・自己紹介
・行って分かったこと
　ホテルは早めに予約する：宿泊料高い
　なるべく疲れないようにする：Ｕｂｅｒいい
　参加セッションは必ず事前登録する
　技術系・飼料ありセッションは分かりやすい

・参加したセッションの紹介
　マイクロサービス系
　　１２Ｆａｃｔｏｒｓ系
　　Microservice Data Patterns CQRS：データの扱い
　　spotify：組織、文化の話、独自フレームワーク

・マイクロサービスの話題や取り組み事例
　モノリスからマイクロサービスへ
　　スタート時点はモノリス
　　サービス拡大でスケール
　　それにともないマイクロサービス
　　組織・文化漏れに合わせて変わる
・組織、文化
　システムのスケールに合わせて、組織も変わるには
　コンウェイの法則
　　自主性、自立性：Autonomy　squad：非セントラライズで自主的
　　非同期型を同期型よりも推奨
　　
・マイクロサービスを取り巻く仕組み
　　ＣＩ／ＣＤ
　　コンテナとオーケストレーション；Ｄｏｃｋｅｒとくーばねーてぃぶ
　　サービスレジストリ：ポート隠ぺい
　　とにかく非同期推奨
　　フォールトトレラント（サーキットブレーカー）
　　モニタリング：ぷろめてうす
　　トレーシング

・議論の対象の変化
　　フレームワークやライブラリより
　　サービスや部品をどう強調させるか

・同期＜非同期

・データ処理パターン
　　Eventual Consistencyでよくないか？→マイクロサービスと相性がいい
　　Event Sourcig：Insertのみ、Updateしない。ひたすらログを取る
　　ＣＱＲＳ：登録と問い合わせ処理の責任分離

・マイクロプロファイル
　１．２：１０月３日に公開
　今後

・複数サービスにまたがったトランザクション
　　Long Running Action

・考察
　必要性を考える
　　　→最初からマイクロサービスを考えたわけではない
　組織や文化とセットで考える
　トレードオフも考える

・まとめ
　ホテルははやく
　必要性とトレードオフ

■サーバーレス＠Ｏｒａｃｌｅ
・Function使っている人！
　１割いない
・Functions
　Function as a serviceのプラットフォームで動く
　プラットフォーム
　　あまぞん
　　あじゅーる
　　　：
　問題
　　プロプラエタリ
　　Ｊａｖａの実装甘い

・理想のfunction
　オープンソース
　Docker クーバネーティブ

。ｆｎプロジェクト
　　function as a serviceのオープンソース
　　dockerでもうごかせる
・Ｊａｖａ用
　　ＦＤＫで開発できる
・ＣＩツール、ＣＤ
　　９割は使っている
　　数分間
・フロー：複数の処理をまとめられる
　　コンカレントＡＰＩ
・より細かい詳細
　www,fnproject.io
・情報発信：ソーシャル使っている
・デモ

■Attend JavaOne as a Community Master
・自己紹介
・１１月１８日、ＪＪＵＧ　ＣＣＣやるよ！
・ＪａｖａＯｎｅ初参加
　ＪａｖａＤａｙＴｏｋｙｏ：ＣｆＰだしなよ～
　はじめてづくし
・コミュニティＤａｙ
　コミュニティの紹介、技術セッション有（求められるレベル低そう）
　話したこと　Ｊａｖａ女子部のこれまでとこれから
　よかったこと
　　　Ｊａｖａ女子部が新しいことに挑戦できた
・コミュニティキーノート
　　Ｊａｖａコミュニティ用の楽しい場
　　ＩｏＴ系のおもしろいやつのしょうかい
　　帰りの会
　Ｊａｖａコミュニティ大集合！爆笑寸劇
　　　お楽しみ会：おととしはじまった
　　　４分の１を日本が獲得
　　　　からておしえておんせんいく
　　　　　BulletTimeDemo：ラズパイを使って３６０度画像を作る
　　　　　JOnsenの紹介
　よくなかったこと
　　　はずかしずぎる
　　　ゆるふわすぎる
　よかったこと
　　　いろんな人に声をかけてもらえた：日本のイベントで登壇したい
　日本のコミュニティアツい：特殊で活発
・所感・まとめ
　絶対また行きたい
　なぜいかないんですか？
　　費用：スピーカーになればチケット無料
　　海外：日本人多い
　　英語：１ねんある。
　　興味：なんで今日来ている？

Javaのリリース方法とバージョン、サポートが来年から大幅に変わる件

今、
Java SE 9/EE 8リリースイベント 兼 JavaOne 2017 報告会 @ 東京
https://jjug.doorkeeper.jp/events/66256
に行っていて、話聞いてる最中だけど、大きな話なので、ここでメモメモ
（上記の件は後半）

---

■JavaOne2017 Overview & announcements
・JavaOne2017　イベント的には、ほぼほぼ１週間
　Javaキーノート：ゲストスピーカーが出てきて中核の話
　デベロッパーキーノート：クラウド
　コミュニティーキーノート：Javaチャンピオンとたのしくすごす

・まーくきゃべっじ　キーノートしきっていた
　Ｒ＆Ｄのトップ
　じょーじさーぶ
　まーく：機嫌よかった。（きょねんぴりぴり）９出たので

　ステージ　４０００人くらい入るホールで
　ＳＥ９、今後のプロジェクト
　JavaEE
　チーフアーキテクトコメント
　くーばねーてぃすの人のスピーチ

・今年のメッセージ
　より、速度を上げていこう：進化を早く
　Core Foundation
　Javaチャンピオンふえてる
　コントリビューションも増えている　OpenJDK
　現在の状況：世界で一番使われている。１２００万人のでべろぱー３８０億のＶＭ
　くらうどだけでも２１０億のＶＭ

　これからの方向性
　　オープン
　　進化の加速（evolving)
　　にんぶる（軽量化）

　ＪａｖａＥＥ
　　８のリリース
　　オープンで
　　にんぶる
　→Eclipseへの移行(Eclipse Enterprise for Java)

　ＪａｖａＳＥ
　　９リリース
　　より早いタイミングで→OpenJDKの位置づけ

・JDKリリースモデルの変更
　ＪＤＫ９
　　９月リリース
　　７のときにcoin,Lambda,Jigsawはあった
　　　→実際には一部
　→段階を踏んで、９にはいった。

・従来のリリースモデル
　OpenJDK：ソースコード提供、OracleJDKと技術的な差
　機能リリース　２年に１度のリリースが目標
　　→まもれたためしない：だいじょうぶなの？
　Oracle JDK前後のバージョン１年間のダブりがある
　セキュリティパッチ３か月

・新しいリリースモデル
　OracleJDKとOpenJDKの技術的な差分なくなる
　６か月に１回にリリース：固定
　バージョンの表記；来年の３月から１８．３、１８．９のように
　　リリースノート、ドキュメントで新しい機能、削除される機能
　OpenJDKのバイナリ配布　無償配布の場合
　　→ＧＰＬ

・長期サポート　２０１８年９月から開始
　１８．９から
　更新リリース　３か月ごと
　OpenJDK,OracleJDKとも、機能更新はいらない（セキュリティパッチ）

・Oracle JDKの無償利用
　今は可能だが、将来辞める→評価、開発の利用はできるが、
　ただで、今まで通り利用したいなら、OpenJDKつかってね！

・ソースコードの管理モデル
　OpenJDK、OracleJDKの２つ
　→新しいモデル、１本のソースコードへ

・ＪａｖａＳＥ１８．３のスケジュール
　３月２０日のＧＡ、
　２月２２日のファイナルキャンディテートにはアーリーアクセスでる

・OpenJDKバイナリダウンロード始まっている

・公式アップデートの終了（無償でアップデート）
　　８　　１８年９月終了
　　９　　１８年３月終了
１８．３　１８年９月終了

・商用サポート
　　プレミアポート８、９もあるけど。。
　　エクステンデッドサポート　８はあるけど、９はない

・お知らせ　ＪａｖａＳＥ９日本語ドキュメント公開

ドメイン駆動設計 powered by Springを聞いてきた！

３月２８日、

JSUG勉強会 2017年その3 ～ ドメイン駆動設計 powered by Spring

を聞いてきた！ので、内容をメモメモ

---

■ドメインロジックに集中せよ
・ドメイン駆動設計
　ソフトウェアの核心にある複雑さに立ち向かう

・設計を複雑にする要因
　　技術的な複雑さ
　　ドメインの複雑さ

・核心の複雑さに立ち向かう
　ドメインロジックに集中する
　モデルに基づき設計する
　インクリメンタルに開発する

・ドメインロジックに集中する
　ビジネスルール　：分析の対象→遵守すべき約束事
　ドメインロジック：実装の対象→ビジネスルールのサブセット
　　　　　　　　　　　　　　　　プログラミング言語で記述

・モデルに基づき設計する
　モデルとオブジェクト
　モデルのない開発プロセス
　　情報収集
　　分析整理
　　仕様　　モデル（アドオンの作業）
　　設計
　　実装
　→ドメインモデルを一切持っていない

　モデリングという作業を入れる
　→全体の見通しがよくなる

・インクリメンタルに開発する
　フェーズに分ける開発
　　担当者が変わる：伝言ゲーム
　　一方向　つじつまあわせ
　インクリメンタルな開発
　　すべては発展途上になる
　　同じチームで対応する

・素敵なお知らせ
　複雑さに立ち向かう強力な援軍
　Spring Framework Spring Boot
　Spring Framework
　　ドメインモデル以外のことを全部用意するフレームワーク

　Spring Boot
　　いったんは動かせ。Github作って。

・残念なお知らせ
　こんな開発もできる
　　技術課題に集中する
　　バックログをせっせと消化する
　　フェーズに分けて伝言ゲーム・基盤とアプリの分離

・アンチパターン
　データ処理に焦点をあてる
　　プレゼンテーション層：画面の入出力 @Controller
　　アプリケーション層　：データベースの更新・参照の手続き @Service
　　データソース層：データベースの入出力 @Repository
　　　　｜
　　　　↓　ドメインロジックを
　　ドメインモデル
　　　　　ここに集約する

・ドメインモデル
　マーチンファウラー
　　オブジェクトモデル
　　振る舞いとデータ

・ドメインモデル
　ドメインロジックをオブジェクトで表現する

・ドメインモデルだと何がよいのか
　変更が楽で安全になる

・ドメインモデル：変更容易性
　　ドメインロジックが重複しない
　　どこにロジックが書いてあるか特定しやすい
　　変更の影響を狭い範囲に限定できる

・トランザクションスクリプト
　同じロジックが重複する
　データ処理の流れを追いかけて探し回る
　後続の処理をすべて追いかける

・ドメインオブジェクト設計パターン
　　ビジネスルール
　　ドメインロジック

・ドメインロジックの最小単位
　　演算の対象
　　　数値
　　　日付
　　　文字列
　　演算
　　　等値の判定
　　　大小・順序
　　　範囲内
　　　有効
　　　型変換
　　　四則演算・変換
　　　
・最小単位→３つの型にまとめられる
　値オブジェクト
　　　汎用の型　→　独自に定義した型
　コレクションオブジェクト→リスト、セット
　区分オブジェクト　→　振る舞いを持ったenum
　　　　　　　　　　　　Strategy,Stateパターン

・設計原則
　　モジュール化：複雑さに立ち向かうための工夫
　　　　ドメインモデル：オブジェクトモデル／関心ごと
　　　　トランザクションスクリプト：機能
　　構造化：記述レベルを階層化する
　　　　業務で使う用語
　　　　ドメイン固有API→このレイヤをしっかり書く
　　　　JavaコアAPI
　　　　Java言語仕様
　　※動かすだけならドメイン固有APIはオーバーヘッドだが、
　　　ドメイン駆動設計には必要
　　文書化
　　　ソースコードに自己文書化
　　　　パッケージ名／クラス名／メソッド名

・ドメインロジックの文書化
　ドメインオブジェクトを使うほかの三層のコード
　　　ドメインロジックとの関係性を語るようになる
　　　　（自己文書化が波及する）
　ソースコード以外の文書化
　　　業務マニュアル
　　　利用者ガイド
　　　（不要）開発・保守ドキュメント

・ドメインを隔離する
　　基盤側にドメインロジックを持っていかないこと
　　　→つまり、アノテーションのかかったメソッドに
　　データの入出力とドメインモデル

　　画面やデータベースの都合をドメインに持ち込まない

・プレゼンテーション層とドメインオブジェクト
　　ドメインオブジェクトを直接使う
　　プレゼンテーション層の記述をドメインモデルに依存させる
　　プレゼンテーション層に判断・加工・計算のロジックを置かない
　　　HTTPリクエスト→ドメインオブジェクト：DirectFieldAccess
　　　ドメインオブジェクト→HTTPレスポンス：HTMLテンプレート

・PRG

・DirectFieldAccess
@ControllerAdvice
　@initBinder
あとは#kanjava MVCで検索

・アプリケーション層とドメインオブジェクト
　@Service
　@Validated　：引数にかけてしまう
　リポジトリを@Autowiredする

　ドメインの関心事としての永続化
　　インターフェース宣言
　　データベースの都合をドメインオブジェクトに持ち込まない

・データソース層とドメインオブジェクト
　@Repository
　MyBatisSQLmapping
　　オブジェクトとテーブルは別の世界
　　手作業で明示的にマッピングしている
　resultMapに明示的に書く

・まとめ

■トークセッション
・変える気があるか
・リードする人がいないと・・
・ぐれいるずをつかおう
・数百人にDDDの厚い本を実践する？
・経験者を作る
・リファクタリングの形で書き換える
・本開発が始まる前に作るしかない
　　→縛りをかけてしまうと、
・ウォーターフォールでDDD
　　いけるんじゃないか？
・データさんがかじを切るだけでも変わる
　→てらそるなに「リッチなドメインモデルは書かない」とかの記述に
　　たいして、こういうときならというのをちょこっと書いてくれるだけでも、
　　世の中は変わる。
・自分の知らないドメインは
　　→パクってくる。Day1はできてない。でも１週目にはできていないと・・
　　　用語集とかは渡していない
・業務で使う日本語：横幅いっぱいになる：日本語でクラス作る？
　　enumは日本語で書いている。日本語でやると違和感
　　大規模はローマ字、子音だけはあるけど、
・ドメインモデルを作るコツ
　　値オブジェクト：ドメイン駆動はオーバーヘッド　結果的によくなる
・実装　MyBatisでなくてもJPAでもできるけど、
・オブジェクトの組み合わせでロジックを作る
　順序依存性があるものは、サービスに書いている

　　

Java EE 8とMicroprofileをきいてきた！

３月２１日

JJUG ナイト・セミナー 「Enterprise Java最新動向～Java EE 8とMicroprofile～」
https://jjug.doorkeeper.jp/events/58535

を聞いてきた！のでメモメモ

---

■JavaEE8最新状況について
・JavaEE8 What's coming
・JavaEE8　FIXしていないので、かわるかも

・３月時点での最新情報
　２０１７年３月１３日GlassFish5のPromotedビルド
　２種類のビルド　Promootedビルド、Nightlyビルド

・JavaEE8のスケジュール
　４月５月　パブリックレビュー
　今年７月　ファイならいず
→ことしの９月か１０月にGlassFish５

・JavaEE8の仕様
　JSON-B、セキュリティ
　現状のステータス
　　MVC１．０はドロップ→コミュニティに移管

・Java EE8　各Specificationとサンプルコード
　JAX-RS2.1:REST
　　２．１で追加された
　　　Reactive Client API
　　　サーバーセントイベント
　　　ノンブロッキングIO
　Jax-RS振り返り
　　１．１　サーバーサイドの実装のみ
　　　クライアントは標準化されていない
　　　　Jersey,ApacheCXFが独自に用意しているもの
　　２．０　クライアントAPI登場
　　　　複雑な呼び出しもできる
　　　　同期型
　　　　非同期呼び出し　async()インボーカーを呼び出すだけ
　　　　　　　　　　　　返り値はFuture、コールバックも
　　　　　→リアクティブ・プログラミング・モデル
　JAX-RS2.0
　　リアクティブ・プログラミング・モデル
　　　→コールバックのネストで実装
　　　　コールバック・ヘル
　JaxRS-2.1 rxインボーカー
　　CompletionStageが返り値
　ScalaのFutureはチェインを組めるが、JavaのFutureはできない
　　→そこでCompletionStageが出てきた

・Server Sent Eventの特長
　Jerseyではすでに→標準化を行った
　SseEvent:
　　　SseEventSourceが受ける
　２月時点でのAPI変更：Jersey独自実装がなくなった

・JSON-P1.1
　　JSON新仕様（RFC ７１５９）に対応
　　　JSON-P1.0ではJSON RFC 4627
　→新仕様では、TOPレベルに何でもおける
　　　RFC　６９０１
　　JSONポインタで中を見れる

　　JSON Patch
　　　RFC 6902：部分的変更、演算、JSONドキュメントの変更
　　　Diff
　　　StreamAPIに対応
　　　　JSON collectors

・JSON-B
　コンベンションオーバーコンフィグレーション
　　　アノテーション、コンフィグ不要
　　　プロパティ名のカスタマイズ
　　　　無視する、フィールドの可視化、NULL
　　　　フォーマット指定（ｄｄｍｍｙｙ）
　　　　アダブタ

・プロバイダ
　もきしー
　べうのプロバイダを指定できる

・サーブレット４．０
　HTTP2サポート
　　HTTP1　テキストベース
　　HTTP2　１つの物理接続を論理でいくつもに分ける
　　　→優先度
　　　　HTTPあっぷぐれーど

・JSF2.3
　CDI統合：今までのManaged Bean非推奨
　JavaEEコンテナの外部でもCDI動作

・CDI2.0
　BeanValidation 2.0　JSR380

・セキュリティAPI
　JSR375
　いままで標準化なされていなかった
　　AAuthentication
　　Identity Store
　　セキュリティコンテキスト

---

■MicroProfile　背景と意義、そしてこれから
　講師　富士通の人

・自己紹介
・Microprofile.io
　ミッション
　　エンタープライズじゃヴぁ、マイクロサービス、ゴールは標準化
　→JavaEEでよいのでは？

・マイクロサービスアーキテクチャ
　疎結合、
　意思決定の早さ
　フィードバックループ（OODAループ）を早く

・MSAレイヤーと要素技術
　サービス分割、ステートレス、API　アプリケーション
　メモリー、REST、非同期　アプリケーションサーバー→マイクロプロファイル
　サーバーレス、IaaS,PaaS,Docker　VM/コンテナ

・JavaEEにもプロファイル
　JavaEEにプロファイルを追加できるのはOracleだけ

・JCPステージ
　イニシエーション
　どらふと
　　アーリードラフトレビュー
　　パブリックレビュー
　ファイナルリリース
　　RI（参照実装）&TCK（テスト実装）

・JavaEEでるの？：今EDR
　GlassFishのイシュー　V4以降はない：活発でない？
　JavaEEに乗れない
　　→JCPのプロセスがアジャイル的ではない

・仕様が先？実装が先？
　仕様が先：適切な競争　　　　　JCP
　実装が先：イノベーション向き　Linuxカーネル
　→もともとはOpenJDKで

・JCP　VS　OpenJDK
　OpenJDK
　　JavaSEのRI　JSRによる開発　JCP
　　JDKのオープンソース　JEPによる開発　OpenJDK

・OpenJDKとMicroProfile
　似ているところ
　　Microprofileの仕様がJavaEEの仕様
　　開始からFIXまでの時間が短い→議論しないから
　違い
　　OpenJDK：競争原理働かない
　　Microprofile：競争あり。複数ベンダーで実装

・MicroProfileとは
　２０１６年６月設立　レッドハット、IBM,ぱやらなど
　２０１７年１月　富士通参加表明
　　　　　　２Q　　１．１リリース予定

・アジャイル的にOODAループをまわす。最終的にはJCP
　　マイクロプロファイル提供
　　市場評価→最終的にはJCP

・１．０　２０１６年９月　JavaOneでリリース
　　JAX-RS、CDI,JSON-P
　１．１　２０１７年２Q
　　　フォルトトレランス

・configration API
　設定の外だし、設定動的反映、複数の設定で構成
　アノテーションも使えるように
・JWT RBAC　OpenID ConnectベースのRoleBased Access Control
　優先度高いといわれたが、進んでいない

・サービス　ヘルスチェック
　アプリケーションのヘルスチェックをするREST エンドポイント仕様
　Kubernetes helth check互換
　　プロデューサーとコンシューマー
　　@Healthが書いてあると

・フォルトトレランス
　エラーハンドリングを分離する機能
　　リトライポリシー
　　フォールバック
　　サーキットブレーカー：３つの状態　クローズド、オープン、ハーフオープン
　　バルクヘッド
　　タイムアウト

・サマリ
　オープンイノベーション
　　フィードバックループによるマイクロサービスを実践
　アプリケーションポータビリティ
　　実装を選択可能
・最終的にはJCP

JavaをWindows上で動かす際に「１つのファイルをダブルクリック」にする方法

Javaがインストールされている場合、２通りあると思う
・実行できる形式のjarで渡す場合
・exeファイルにラップして渡す場合

後者は、exeファイルなんだけど、そのexeファイル内部でjavaを呼び出すこと
によって実行するもの。launch4jなどがこれにあたる

launch4jで、Javaプログラム(.jar)をexeファイルでラップする
http://symfoware.blog68.fc2.com/blog-entry-1020.html

で、このlaunch4jで困ったこと。
今久々にあるソフトを立ち上げようとしたら・・・

もう、java6なんて、消してしまいました・・・
また入れるのもなんだしなあ・・・
実行できるjarの形式でくれたほうが、うれしいんだけど・・・
Spring Boot最強！（Spring Bootは、targetの下に、実行できるjarを作ってくれる）

Kotlinについていろいろ聞いてきた

昨日（２月２０日）JJUG ナイトセミナー「Kotlin（ことりん）」に行ってきた！ので、その内容をメモメモ

---

■クラスの作り方に見るKotlinの表現力
・Kotlin入門
・Kotlinとは
　ＪＶＭ言語（すからー、ぐるーびーとかのなかま）
　androidもサポート
　JetBrainsが開発(IntelliJ IDEAを開発している）
　2011年に発表され、２０１６年２月にＶｅｒ１．０（１．１もうじきでそう）
　静的型付け
　簡潔安全Ｊａｖａとの相互運用

・Hello World
package sample

fun main(args: Array<String>){
if(args.isEmpty())return
val name=args[0]
println("うつせなかった・・ここまでしか");
}

・自己紹介
　Kotolinスタートブック

・もくじ
　有理数（分数）
　片方向リストのノード

・題材その1：有理数を表現するクラス
　有理数クラス：Rational
　プロパティ
　　　分子
　　　分母

・クラス定義
//　プライマリコンストラクタ
　class Rational(val numerator : Int,
val denominator: Int)

//使い方
fun main(args:Array<String>){
// newと書かなくても生成
val half = Rational(1,2)
// getter setterが書かないでもいい
printf(half.denominator)
}

・オーバーライド
　class Rational(val numerator : Int,
val denominator: Int){

//オーバーライドのとき
// overrideのことば必須
override fun toString():String
= "${numerator}/$(denominator}"

//式が評価された文字列内に展開
// ストリングテンプレート
}

・イニシャライザイー
　不正なものを生成させない
init{
require・・・・
}

・非公開メソッド private fun

・if elseは、式（値を返す）

・末尾再帰の場合、tailrecとかくと、最適化可能
　　→スタックオーバーフローなくなる

・非公開プロパティ
valとかかないと、非公開プロパティ
　class Rational(numerator : Int,
denominator: Int){

・演算子オーバーロード Operator
　　plus ＋演算子を使ったメソッド呼び出し
　→ユーザー定義クラスにも

・2 * Rational(2,5)
　→拡張関数
　operator fun Int.times

・題材その2片方向リストのノード
　プロパティ
　　　値　value
　　　次のノードへのポインタ next

・抽象クラス
//共変指定
　abstract class Node<out T>{
abstruct val value:T
abstruct val next:Node<T>
}

・継承してノードを表現

・シングルトンオブジェクト object
　クラスとは違う
　Nothing あらゆる型のサブタイプ

・リストを作れる！

・コンパニオンオブジェクト
　　スタティックな宣言に近い

・呼び出し時に引数が省略されるとデフォルト値が使用される

・通常の抽象クラスは見える人なら継承ＯＫ

・クラスの前にsealedとつけると、外側にいる人は継承できない

・ノード数プロパティsize
　　再帰呼び出しで計算
　　when式：switchの強い版

・委譲プロパティによる遅延初期化
　byのあとにかく

■spark Framework with kotlin
・自己紹介
　サーバーエージェントのFresh！(動画配信プラットフォーム）について
　　マイクロサービス
　　フルDocker
　　ＡＷＳのＥＣ２コンテナ（ＥＣＳ）
　　主にＧｏ
・ＧｏとFRESH
　１個のサービス、１個のコンテナ　１個のリポジトリ
　十数個のマイクロサービス
・つらくなってきた
　→基本的に筋力に頼る言語：書く量多い
　　生産性を挙げる：コード生成
　→新たな基軸言語を求めた
・マイクロサービス：言語変えられる
　　ミドル、低レイヤはＧｏ
　　新たに１つの基軸言語（乱立はいけない→学習コスト）
・Ｋｏｔｌｉｎを選択
　ＡＰＩ実装の基軸言語として
　新しいマイクロサービスは基本ことりんで
・選んだ理由
　モダンな文法
　ＩＤＥ（ＩｎｔｅｌｌｉＪ　ＩＤＥＡ）
　一番現実的
　　社内リソース（ＪＶＭ系人材、Ａｎｄｒｏｉｄでの実績）
・助走期間
　サービスをＫｏｔｌｉｎで
　　ＳｐｒｉｎｇＢｏｏｔ
　　Springfox
　　domaframework
　感想
　　生産性高い
　　そこそこの学習コスト
　　もうちょっと薄いものでいいかもしれない？
　　　モノリシックなサービスを作るわけではない
・Spark Framework
　　小規模Ｊａｖａフレームワーク
　　Ｊａｖａ８ベースのマイクロＷｅｂフレームワーク
　　Ａｐａｃｈｅ　Ｓｐａｒｋとは別物
　　ラムダ式
　　ＤＩない

・Ｓｐａｒｋ　Ｆｒａｍｅｗｏｒｋ　Ｗｉｔｈ　Ｋｏｔｌｉｎ
　ラムダ式では満足できない
　ＳｐａｒｋＦｒａｍｅｗｏｒｋとことりんのよさ
　相性の悪さ、迷いはあまりない

・Ｓｐａｒｋ　Ｗｉｔｈ　Ｋｏｔｌｉｎ
　コントローラー・ルーティング
　フィルター（横断的関心ごと）
　レスポンストランスフォーまー（ＪＳＯＮ）
　データクラス
　拡張関数
　Ｇｕｉｃｅ（ＤＩ）：Ｇｏｏｇｌｅ
　愚直なＤＩ（とばす）
　okhttp
　hystrix
　メトリクス

・コントローラー
package io.stormcat.controller
import spark.*

class EchoController{
val echo = Route{ req,res ->
"Hello・・・・

・ルーティングmainからgetで

・Filter
handleをオーバーライドする
　mainメソッドで定義 after
　　→around的なものがない

・レスポンストランスフォーマー
　どのように整形するか
　jacksonのkotlinモジュール
　dataclassをサポート

・data class
　Javaだと入れ物定義
　echoの返すところ EchoResultを作って返す
　ＪＳＯＮにシリアライズ

・拡張関数
　リクエストに対して、authUser
　beforeでユーザーオブジェクト取ってきて
　拡張関数の仕組みを使うと、メソッドに

・じゅーす
　ＳｐａｒｋにＤＩのしくみない→ＤＩほしい
　ＧｕｉｃｅでＤＩを利用
　コンストラクタインジェクション

・愚直なＤＩ
　Ｇｕｉｃｅのインジェクター

・okhttp
　マイクロサービス間の通信
　ことりんのでーたくらすにでしりあらいず

・Hystrix
　ネットフリックスがつくっている
　分散システムにおいて、回復力のアルアーキテクチャを実現するライブラリ
　サーキットブレーカーをサポート

・サーキットブレーカー
　どこかがダウン→ダウンしたところにリクエスト→タイムアウト→連鎖的におかしくなる
　コレを防ぐ
　閾値超えたらアクセス遮断
　ダッシュボード

・Hystrix Command
　をいれていく

・メトリクス（Jolokia　じょろきあ）
　Ｄｏｃｋｅｒビルドの際にいれておいて、とれるようにする

・ＦｒａｓｈにおけるＳｐａｒｋとＫｏｔｌｉｎ
　公開ＡＰＩとして本番稼動

・まとめ
　Ｓｐａｒｋ＋ことりんは現実的な選択肢
　マイクロサービス：シンプルなもの
　サーバーサイドことりんの波は少しずつきている
　Ｋｏｔｌｉｎ気持ちいい

■Ｓｐｒｉｎｇ　はーとまーく　Ｋｏｔｌｉｎ
・自己紹介

・今日のお話
　ＳｐｒｉｎｇＢｏｏｔをＫｏｔｌｉｎで
　Ｓｐｒｉｎｇ５で入っているＫｏｔｌｉｎサポート

・せばすちゃんの受け売り

・ＳｐｒｉｎｇＢｏｏｔをＫｏｔｌｉｎ
　Ｓｐｒｉｎｇ　Ｉｎｉｔｉａｌｉｚｒ
　　→ＩＤＥも裏でコレたたいている
　デフォルトでＪａｖａ
　→スイッチ　フルバージョン
　　→言語Ｋｏｔｌｉｎ選択できる

・ＭＶＣコントローラー

・ＤＩコンテナーに管理してもらいたい
　Ｊａｖａｃｏｎｆｉｇ
　ことりんの場合　openつけないといけない
　→なぜ、Ｏｐｅｎいるの？
　シングルトンオブジェクトになる
　　→同じインスタンス：Ｃｇｌｉｂ
　ことりんは、Ｆｉｎａｌを勝手に付ける
　　→勝手に付けなくするのがopen
　→spring のopen問題

・セバスチャンが解決
　springだったらfinalつけないというspringプラグイン
　→JPAのプラグインも
　→今はOpenいらない。

・Spring5のことりんサポート
　Spring5
　Ｊａｖａ８ベースライン、Ｊａｖａ９コンパチ
　　：
　　：
　Ｈｔｔｐ２サポート
　Ｋｏｔｌｉｎサポート

・ことりんサポート
　拡張関数のサポート
　Reified type parameters

・ことりんＫクラス
　Bar::class.java
　Ｊａｖａのクラスは.javaが必要
　→拡張関数：もともとの関数を書き換えることなく

・Reified（らいふぁいど）type parameters
inline fun <reified T:Any> Foo.create()

　ことりんらしいコード
　idiomatic Kotlin code

・Ｒｅａｃｔｉｖｅサポート
　今：サーブレットベース
　→リアクティブランタイム（ノンブロッキング）
　　→Ｗｅｂｆｌｕｘ
　　　リアクティブストリーム
　サーブレット３．１→Ｎｅｔｔｙ

　いままでと同じようにサーブレット
　　＋
　ルーターファンクションモデル
　ＳｐｒｉｎｇＭＶＣも

・ＷｅｂＭＶＣ＋＠Ｃｏｎｔｒｏｌｌｅｒ
　→いままでどおり：ブロッキング
　ＷｅｂＦｌｕｘ＋＠Ｃｏｎｔｒｏｌｌｅｒ
　→帰り値：ノンブロッキング、引数ちょっと変わる
　ＷｅｂＦｌｕｘ＋ＲｏｕｔｅｒＦｕｎｃｔｉｏｎ　ｉｎ　Ｊａｖａ

　ルーターファンクションはＤＩなしで動く

・mix-it

・そのほかのことりんサポート
　本家見てね

・5.0　Ｍ５がリリースされれば、使えるはず

http://start.spring.io/#!language=kotlin

・JJUG CCC 2017 Spring
　ＣＦＰ募集中

Spring Bootには、入門してきた。Spring Cloudは・・・

1月23日、
JJUG ナイト・セミナー 「入門Spring Boot&Spring Cloud」
を聞いてきた！

SpringMVCを中心とした、フレームワークのフレームワークであるSpring Bootについては
　　確かに入門したが・・・
Springのクラウドを使う為のユーティリティ（ロードバランサとか）のSpring Cloudについては
　　う～ん、入門できなかったかも・・

ということで、とにかく、聞いた内容をメモメモ

---

■さくっと理解するＳｐｒｉｎｇＢｏｏｔのしくみ
・自己紹介
・今日話すこと
　SpringとSpring Bootの関係
　　使われる機会増えた：Bootでてきてから
　Spring Bootがカイゼンする開発プロセス
　Spring Bootの構成要素

・そもそもSpringってなに？
　Springフレームワーク
・SpringとSpring Bootの関係
　ざっくり言えば
　　Spring - spring config（面倒な設定排除） +　Tomcat = Spring Boot

・一般的な開発のプロセス
　１．必要なライブラリのリストアップ
　２．起動に必要なＢｅａｎの定義をする
　３．プログラミング
　４．パッケージング・デプロイ
　５・モニタリング

１．必要なライブラリをリストアップ
　最小限で記述できる仕組み：
　　pom,gradleに記載する記述少なくなる
　　ライブラリのバージョン互換性をキープしたまま依存性注入

２．起動に必要なＢｅａｎの定義をする
　同じようなＢｅａｎ定義→Ｂｏｏｔ側が持っている
　Ｂｅａｎ定義が自動的になされる：オリジナルの動作変更もできる

３．プログラミング
　Ｔｏｍｃａｔ内包。生産性が上がる

デモ：は上手くいかなかったので省略

４．パッケージング・デプロイ
　実行可能Ｊａｒでパッケージングできる

５．モニタリング
　ヘルスチェック、ＲＥＳＴ　ＡＰＩエンドポイント自動生成

・Ｓｐｒｉｎｇ　Ｂｏｏｔの仕組み
　Ｓｐｒｉｎｇ　Ｂｏｏｔの構成要素　７つのコンポーネント
　　core:DIコンテナの起動楽に
　　Starter：ライブラリ同士のバージョン互換
　　AUto-configure：自動でBeanを定義
　　CLI：ＣＬＩで作れる
　　Actuator：エンドポイントを提供（モニタリング）
　　Test：JUintユーティリティ
　　Tools：自動再起動など

・Core
　起動が簡単に
　Ｔｏｍｃａｔがないほうされている
　　Jetty,Undertowに置き換えできる
　　Tomcat7から組み込み版対応→Spring Bootが組み込んだ
　Fully Excutable jar
　　１つにパッケージング
　　　ubar jar(fat jar)→どんなものかわからなくなる
　　→Spring BootはNested jar(Jarの中にJarを入れる）
　　特殊なクラスローダーがある
　Maven Gradle、Excutableをtrueにする

・Starters
　実体：pomしかない
　自分でＳｔａｒｔｅｒを作れる

・Auto-configure
　進化した設定の簡易化
　　いままでＸＭＬで定義→Java config→進化した設定の簡易化Ｂｏｏｔ
　@conditipnalOnClass/Bean
　　必要なＢｅａｎだけを定義
　　クラスパスにクラスがあるかないかでＢｅａｎの定義を切り分け
　　　→実行時に自動的に判断

・Ａｃｔｕａｔｏｒ　アプリのモニタリング
　クラウドネイティブなアプリを付けるとき
　Spring Cloudフレンドリ
　　　マイクロサービスの状態チェック

・Ｔｏｏｌｓ
　Dev Tools：
　　オートマチックリスタート
　　設定で有効になる：２つのクラスローダー（再起動用、非再起動用）
　　２つのクラスローダーの使い分け
　　JRebel Spring Loaded：リロードになっている

　Live Reload
　　自動でリロードしてくれるブラウザのプラグインに対応
　　→Ｆ５を押す手間なくなった

　開発時のデフォルトプロパティ

・Maven/Gradle plugin
　　Maven→Ｇｒａｄｌｅ
　　地味にビルドを助けてくれるプラグイン

・まとめ
　Spring Bootのはじめかた
　ＩＤＥ：いんてりＪ、ＳＴＳ，Ｅｃｌｉｐｓｅ
　イニシャライザー
　ＣＬＩ
　　　　↓
　Ｍａｖｅｎ・Ｇｒａｄｌｅ
　　　　↓
　メインメソッド実行でＴｏｍｃａｔ

・むすびに
　ちょっとしたカイゼンの積み重ねで開発が楽になる
　アイデアがＧｏｏｄ
　クラウドサービスの登場：Ｊａｖａがお手軽に

Ｑ＆Ａ
・内部構造でのポイント
　Ａｕｔｏ－ｃｏｎｆｉｇｕｒｅのソースコード
　Ｂｅａｎ　Ｄｅｆｉｎｉｔｉｏｎｓ

・ＳｐｒｉｎｇＭＶＣとＡＯＰは？
　ＡＯＰ：ＳｐｒｉｎｇフレームワークのＣｏｒｅプロジェクト
　ＭＶＣ：Ｃｏｒｅのソースコード

・ＵＩはTimeleafをつかうけど、ＪＳＰをつかったら？
　ＪＳＰがＨＴＭＬとロジックをまぜこぜにする点で・・・
　不都合はないが、選ぶ理由がない
　マニュアルに避けろと書いてある
　組み込みで動かないことがある

■ぱぱっと理解するSpring Cloudの基本
・自己紹介

・Spring Cloudとは
　クラウドネイティブアプリのツールの集合体

・クラウドネイティブなメリット
　　変化に強い、
　　性能のスケールアウト
　　障害に強い

・Ｓｐｒｉｎｇ　Ｃｌｏｕｄで抑えておきたい基本技術
　そもそもできること
　クラウドネイティブなアプリ
　　マイクロサービスアーキテクチャ→疎結合
　　サービスの多重化：処理性能・耐障害性

・要素を簡素化した題材で基礎技術
　結合した文字列を返す
　　りんごとペンを結合する　Uh
　　もし、爆発的な人気が出たら・・・

・サービスディスカバリとクライアントサイドロードバランシング
　発生しうる問題：集中
　　→多重化

　Eurekaサービス：DNSみたいなもん
　　アプリ名、ＩＰアドレス、ポート番号

【実際のコーディング】
　３ステップ
　　１）Eurekaサービスの立ち上げ　：イニシャライザー
　　　　依存関係にEurekaサーバー追加
　　２）サービス登録：Eurekaディスカバリ
　　３）ロードバランスで負荷分散：リボンを追加　Ｒｅｓｔ　Ｔｅｍｐｌａｔｅを介して

・サーキットブレーカーで障害検知
　１箇所の障害でサービス全体が応答しなくなる可能性
　→障害時の規定の動作を定義、継続性を担保
　　→サーキットブレーカーパターン

【実際のコーディング】
　２ステップ
　　１）EnableCircuitBreaker：Hystrix追加
　　２）HystrixCommandで障害の規定動作の指定


・Config Serverで設定情報の集中管理
　サービスの数だけ設定ファイル：設定変更が大変、不整合の恐れ
　→設定ファイルの集中管理

　configサービスとgit　
　設定ファイルの更新
　　Ｇｉｔ更新
　　refresh要求：管理者→アクチュエーターで
　　設定の再取得

【実際のコーディング】
　２ステップ
　１）EnableConfigServiceでConfigサービス立ち上げ
　　　→イニシャライザーで設定ファイル
　　　Ｇｉｔ側アプリ名.propertiesでプッシュ
　２）EnableConfigClientでクライアント作成
　　アクチュエーター経由で環境変数の確認
　　http://アプリ名/env

Ｓｐｒｉｎｇ　Ｃｌｏｕｄを使ってみて感じた疑問

・信頼性は大丈夫（ＳＰＯＦの問題）
　→必要に応じて冗長化の必要がある　
　実際にはＬＢの後に複数のＣｏｎｆｉｇインスタンスをおく場合が多い

・Eureka冗長化の考え方
　可用性＞整合性
　Eureka動詞の間にお互い登録
　　→障害時、Eureka同士が持っている情報がずれている場合がある

・Config First or Discovery First
　Config firstでしょう（ただし、両方とも動く）
　　config first：Configサーバーを起動→Eurekaへ登録
　　Discovery First：Eurekaを起動→Configを登録
　→必要に応じて検討

・EurekaとＤＮＳの違い
　サービスレジストリと負荷分散
　　Eurekaだと、アノテーションを付けるだけ
　ミドルウエアか、アプリか→検討

・おわりに
　本セッションは基礎に絞って紹介

Ｑ＆Ａ
・パフォーマンスは？
　アプリレイヤでやるので、パフォーマンスは・・
　それなのにアプリでやるのは、柔軟にできる点

・Ｓｐｒｉｎｇ　Ｃｌｏｕｄのデザインパターンみたいなまとめはないの？
　ＣｌｏｕｄＦｏｕｎｄｒｙが流行ってるよね。
　ＳｐｒｉｎｇＣｌｏｕｄ公式ドキュメンテーションにいろいろある

・アクセスキューの動的制御は？
　動的スケールアウト：ないかなあ・・・？

・悪意のあるユーザーがいたら？
　デフォルトで認証機能が有効でない
　認証してね

・ロードバランシングのカスタマイズは？
　メトリクスの取得は？
　クラスで定義、注入する
　パフォーマンス：Ｓｐｒｉｎｇ　Ａｃｔｕａｔｏｒはリアルタイムで情報見える

・開発コスト
　マイクロサービスをどう考えるか

・整合性担保
　おなじリポジトリを見るので、いつかは整合性：Config
　Eureka：一人でも動くようになっている

■ＣＭ
・ＪＳＵＧでＳｐｒｉｎｇ勉強会
・年１回　Ｓｐｒｉｎｇ　Ｄａｙ→１０月中旬

「JAX-RSでCognitive ServiceやExcelを操作しよう」を聞いてきた

今日（１２月３日）JJUG CCC 2016 Fallに行ってきて
JAX-RS REST ClientでCognitive ServiceやExcelを操作しよう
講師：寺田　佳央さん

を聞いてきたのでメモメモ

---

■JAX-RS REST ClientでCognitive ServiceやExcelを操作しよう

・ビデオ
　ＩＴ：仕事の効率化　改善
　ＩＴが人の生活をよりよくしてきたか？
→今日のテクノロジを使うと、よりよい社会を創っていける
　ほんやくコンニャク

・Ｓｐｅｅｃｈ　ＡＰＩ
　　音声（日本語）→（日本語文字）翻訳（英語文字）→音声（英語音声）
　みなさんすぐにどらえもんになれる：エンジニア　ＩＳ　ヒーロー

・コグニティブサービス
　プロジェクト　オックスフォード
　裏でディープラーニングが動いている
　日本語の精度を上げる：日本語試す必要ある
　ＶｉｓｉｏｎＡＰＩ　画像
　ＦａｃｅＡＰＩ　　　顔
　エモーションＡＰＩ　感情

　実ビジネス→監視カメラ　生で情報収集
　教育分野でも使えるかも？　化粧品販売、車販売
　　→ＰｏｗｅｒＢＩでリアルタイム

　Ｃｏｍｐｕｔｅｒ　Ｖｉｓｉｏｎ　画像を８６カテゴリに
　ＯＣＲ：光学式文字認識
　　日本語と英語が混ざった場合は気をつけたほうがいい
　　日本語だけなら精度高い
　ＲＥＳＴで呼び出せる

・使いたい人
　ログイン：Ｍｉｃｒｏｓｏｆｔアカウント以外でも、Ｆａｓｅｂｏｏｋ、Ｇｉｔｈｕｂでも
　各サービスに無料の枠がある
　サービスを有効化すると、キーが取れる：コピペする
　ＦａｃｅＡＰＩ　ＡＰＩリファレンス
　　ＯｐｅｎＡＰＩテストコンソール
　　　　ＪＳＯＮのパラメータ入力
　　　　写真のＵＲＬ
　※明るさによって、年齢変わるかも？

・Ｊａｖａでどうやって？
ＪＡＸ－ＲＳ
　Ｍａｖｅｎのpom.xmlにじゃーじーとか、ＪＡＸＢとか（ＪＳＯＮＢはまだ）
　ＨＴＴＰ　Ｇｅｔによる呼び出し
　ＰＯＳＴ：送るデータをエンティティとして
今回はブロッキング処理→パフォーマンスわるくなる
　ＥＥ８では、ノンブロッキング対応
　ジャージーではＲＸ対応しているので、リアクティブで書ける
　　→サンプルにノンブロッキングおいてある

顔認識のサンプル実装
・サンプル写真ををＡｚｕｒｅＳｔｏｒａｇｅへ
　ＰｒｉｍｅＦａｃｅｓのＪＳＦ　Ｃｏｍｐｏｎｅｎｔを利用
・ＵＲＬをエモーション、Ｆａｃｅに送る
　Ａｓｙｎｃ　ＲＥＳＴ　Invocation　ＵＲＬをおくるFutureつかってる

これが基本。この基本を覚えれば、マイクロサービスでも

Ｅｘｃｅｌ　ＲＥＳＴ　ＡＰＩ
・Ｏｆｆｉｃｅ　３６５のデータの読み書き
　→OAuthが必要

　Ｏｆｆｉｃｅ３６５のデータがＲＥＳＴでアクセスできる（追加もできる）
　ので、ＪＡＸ－ＲＳで操作できる

・サンプルコード
　ＯＣＲ https://github.com/yoshioterada/OCR-Sample-of-Cognitive-Service
　Ｅｘｃｅｌ：Ｔｏｍｃａｔ上でも動く
　　無償で試せる：画面ダンプは取っているので、それみてね
　　認証用、ＯｎｅＤｒｉｖｅ，Ｅｘｃｅｌ操作

Java(SE8 Gold)の認定試験のポイント解説セミナーに行ってきた！

11月16日OCJP Gold SE8 認定資格試験ポイント解説セミナーに行ってきた！
のでその内容をメモメモ

---

＜＜始まる前に＞＞
基礎的なところも出る
・基礎的なところでは、スレッド・ファイルIOがよく出る

＜＜はじまり＞＞
・後日スライドシェアで確認できる
・Dukeのデザイン変わる

■Java資格のご案内
・旧Sunの試験１つ（シルバーとゴールド）
　　→今、ブロンズつけた（新人向け）：ブロンズはオプション
　　→移行のパスがでるのは、Goldのみ

・申し込み
　1Z0-809-JPN(JPNつけないと日本語にならない）
　試験時間とか確認してね：１問あたり２分かけられない

・テスト内容チェックリスト
　１３個トピック
　Javaクラスの設計：復習→設計の仕方は聞かず、どうやってコード書くの？を聞く
　SE8ではインナークラスをよくきく：ラムダ式に関係して

・ラムダ式聞く

・ジェネリックはそんなに

・でもコレクション、ストリームAPIは細かく
　ラムダ式の書き方も含めて

・アサーションと例外処理
　try with リソーシズ

・Date&Time API
　試験では基本をさらっと抑えれば対応できる

・NIO2
　NIO2を聞かれているのか？ストリームAPIを聞かれているのか？
　　→減っている、深さも

・マルチスレッド
　ボリューム：シンクロナイズド、排他、同期：コレクションでも
　スレッドプール、Fork/Join
　　→サンプルコードがかけるくらいに

・JDBC
　　一連の流れ

・ローカライズ

１３個あると、均等に出るけど
・スレッドちょっとおおめ
　　→ストリームAPIとラムダ式わからないと、４０％～５０％答えられない
・ファイルIO
　　NIO2をやったほうがいい
・スレッドは山をはらずに全部

説明の流れ


１．Javaクラスの設計
　青時はむずかしめ
　カプセル化、Objectのハッシュコード
　シングルトンクラス

　Objectメソッドのequals()メソッド→ハッシュ値が同じか
　equals()をオーバーライドしたらhashcode()もあわせてオーバーライドする

　シングルトン：インスタンスが１個しか出来ないつくりかた

２．高度なクラス設計
　enumの使い方
　インナークラス：通常、static、匿名の使い分け
　　→外側からアクセスできるか
　インターフェース：デフォルトメソッドをチェック
　　競合の優先度

　インナークラスのインスタンス化
　　内部クラス
　　staticがついた内部クラス
　→どこにアクセスできるかも
　　実質的finalであること

　関数型インターフェースの要件も確認

３．ジェネリックとコレクション
　List,Set,Map,キュー
　Comparator：ラムダ式もからむ

　自分と他者を比較するときのメソッドの違い
　無名クラス、ラムダ式
　ダイヤモンド演算子

４．コレクション、ストリームおよびフィルタ
・ストリームとリストのforEach
・パイプライン処理、遅延評価
・ラムダ式、フィルター
・メソッド参照

　置き換え問題がでる
　中間操作は遅延実行

　ストリームの作り方
　int stream：for文の置き換え
　メソッド参照：ラムダ式全体が置き換わる

５．ラムダ式
　基礎的なものをカバー：５個の組み込みインターフェース
　プリミティブ型を扱う関数型インターフェース
　２つの引数を扱う関数型インターフェース
　呼べるメソッドfilter,map,forEach→取れるものが決まってくる

６．JavaストリームAPI
　全部むずかしめ：ここ６割くらい取れれば
　→キーワードは何をするか、確実に
　Optional:SE8の新機能

　flatMapの使い方
　map,reduceの使い方

　中間操作・終端操作→終端操作を呼んでしまうと、その後呼べない
　groupBy,partitioningBy

７．例外とアサーション
　try-with-resourcesとAutocloseableって何？
　アサーションの構文
　ファイルIO,JDBC→Autocloseable
　開いたときの逆順で

　アサーション：ルール覚えておく java -ea

８．日付・時刻API：あんまり難しくない
　直感的に計算できる
　タイムゾーンとくにSummerTime
　イミュータブルオブジェクト

９．ファイルIO
　ラップしたReader/Writer
　追記モード false：追記しない
　コンソールからの読み込み

１０．NIO2
　JavaSE7ではおおかったが、トピック的には減った
　基本的操作
　Streamを返すファイルI/O関連メソッド
　　絶対パスと正準表現パスの違い（.の存在）

１１．Javaの同時実効性
　スタベーションの単語の意味に注意
　Executors
　Fork/Joinはコード書いておいたほうがいい（フィボナッチ）
　分割統治アプローチ：map reduce
　スレッドセーフに出来るか：
　　Java.util.concurrent
　よまなきゃいけないところ
　　startしないでrunだけしている場合とか

１２．JDBC
　突っ込んだ出題はしていない
　接続
　select,ResultSet,RowSet
　更新系はあまりない
　Class.forNameいらない

１３．ローカライズ
　リソースバンドルの使い方→ファイルの置き方もあわせて

まとめ
・時間あまりない
・とりあえず、全部答える。これ最優先

補足情報
・問題集の活用　２社
・キャンペーン
　合格したらTシャツ
　年末までにバウチャー　３５％オフ
　１２月１０日に筆者が解説