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シャツ
　年末までにバウチャー　３５％オフ
　１２月１０日に筆者が解説

JavaEEはリアクティブ、マイクロサービスに行くみたいよ（MVCはぶっち）

きのう（１０月１５日）JavaOne2016報告会に行ってきた！
その内容をメモメモ
（表題の件は、中ごろの寺田さんの発表の印象）

---

■ごあいさつとOverview
JavaOne サンフランシスコ 2016年９月１８日～２２日
・セッションのほうが中心：テクニカルカンファレンスとして成熟
・土曜日：JavaOneForKids　金曜日：Javaチャンピオン　サミット
・Java Your Next(Cloud)
　クラウドに向かうぞというのは、だれでもわかっていること
　キーノート
　　１時間丸まるゲストスピーカー：火星に行く話
　ジョージサーブから
　　JavaSE9は４ヶ月遅れる
　　Dockerコンテナベース：現在のインストーラーベースに加え
　　　→詳細はわからない
　アニールガー：JavaEE系
　　　→詳細は寺田さんへ
　　　EE8リバイス、
　　　EE9の提案
　　　　　来年末までにEE9の骨組み
　　　　　１８年末までには、マイクロサービス化されたもの提供
　そのために２０１６年
　　　コミュニティに提案
　日本からの登壇者　５名
　　　松田、損保ジャパン、富士通、日立、NEC
　　　木曜日、コミュニティーキーノート、
　　　　スターウォーズの学芸会のり（JUGのリーダーとか
　　　　　ゴスリンさんは台本よみまくり！
　JavaOne4Kids
　サーベイ：glassfish.org　（英語で）
　来年は１０月１日～５日

■JavaSE Feedback
・スライドは公開予定です
・自己紹介
　HeapStatsの開発　JavaのHeapのプロファイリング
　　→賞をいただいた、セッションで発表

・JavaSEの未来
　スケジュール
　　JDK9：延長かかった（まえに）
　　　　　全然機能完了してない
　　　　　また延長きまった　２０１７年７月２３日
　　JDK10：スケジュールあがっていない

　JDK9セッション：いっぱいあった、よかったけど・・・

・主な機能
　JDK9
　　Project Gigsaw
　　Project Kulla(JShell)
　　Reactive Stream
　JDK10以降
・Project Valhalla
・Project Panama

・ジグソーに関して
　jarの依存性が複雑→かけたとき・同じ名前の競合
　→新しいコンテナ
　JDK内部のモジュール化；これがジグソー
　　Jlink：必要最低限のJRE
　結構更新された
　　英語表示でヘルプを出す（日本語だと古い）

・Project Kulla(JShell)
　　REPL for Java→CLI上で実行できる
　　　：教育

・Reactive Stream(The Flow API)
　Reactive programming：依存j関係と関数の国あわせ
　Reactive Streams

・Project Valhalla
　バリューらいぷのシンプル化
　（今回はキャンセル）

・Project Panama
　ネイティブコードを操作しやすく

・９の変更点
　ジグソーの変更によるもの
　　大半の内部APIがカプセル化
　　　jdepsを使って影響あるか、確認を推奨
　　→ライブラリが影響受けていないか
　Critical APIはpublic

　クラスローダーメカニズム
　　クラスの継承
　　モジュール化してクラスパスで配置しろ
　　削除済み、非推奨オプションをVMで使うと、起動できない
　　３世代前まではコンパイルできるけど、それ以前は指定できない
　　バージョンを確認して起動する
　　　　バージョンの表記方法かわる
　　　　JDKのディレクトリ構造が変わる
　　Webに関して
　　　　AppletAPI非推奨
　　　　セキュリティ
　　暗号化の変更　
　　　JKSからPKCS12
　　　証明書が変わる
　　ロギング方法
　　　パーサーはだいたい全滅
　　　でこレーター
　　　出力方法は変わる

・範囲が狭いがささったらいたい
　　非推奨APIを削除
　　グラフィック関係
　　Thread.stop
　　toArrays()はくローンを返していたのに、
　　１文字のめいめい禁止
　　String 内部データがcharからbyte[]へ
　　　→ライブラリで
　　GCの組み合わせ
　　　→G1GC
　　ｊｃｍｄの機能強化
　　JavaDBの廃止など

■JavaEEの今後について　寺田さん
・マイクロソフトの社員です（＾＾；）
・この資料、１１０か２０か。。。
　なぜこんなに？
　　Java Oneの内容
　　　３つのセッションをまとめた
　　　　　知っている前提でしゃべっている
　　　　　　マイクロサービス：しらないと全員置いてきぼり→つくりかえた
　エンタープライズJava→従来セッション減らされた
　マイクロサービス（３００セッション中、５０～６０セッション）とReactiveが採用

・あジャンだ
　　よかったこと
　　やばいぞ
　　これからどうなる

・よかったこと
　日本企業がJavaOne基調講演で数多く登壇

・JavaEE
　　いい印象を持ってる人：シーン
　　　→オラクルさんがんばんないと・・・
　JavaEE GUARDIANS
　　去年の秋ぐらいからストップした
　　JavaEEの将来が危ないという情報が流れた https://javaee-guardians.io
　→オラクルさんに届いた
　　アニールガー：ことしのJavaOneで語ります
　　　JavaEE８　MVC採用をドロップ
　　クラウド、マイクロサービスは詳しく出ていない
　　　→やばいんじゃない？
　火星の話をするよりも、不安を払拭するためにJavaEEの話をすべき

　ブレークアウトセッションの参加で不安は払拭・戦略的にはよい方向へ
　（詳細はのちほど）

　でも、べつの不安が！！
　９月２２日　ヒルトン　サンフランシスコ　フィナンシャル　ディスとリクと
　MicroProfile　https://microprofile.io/
　ベンダー・コミュニティーが集結
　　ぱやら
　　レッドハット
　　TOM EE　tomcat+webプロファイル
　→いままでJavaEEを推進してきたベンダーが入ってる

　背景
　　各ベンダーの個別会話から始まった
　　JavaEE技術におけるマイクロサービス対応
　　マイクロサービス重要だよね！
　　将来のJava大丈夫という思い
　　JavaEEをよりよく、より早く
　MicroProfile1.0
　　アジャイル的な方法で
　→いままでのJavaEEの仕様から出るのが長い
　　　→実装依存はある
　　JSRに登録
　　やりたいことを取り上げて、一個づつつぶしていくという考え方
　標準化には時間を要す！！
　　　Spring,Netflix　標準化はイノベーションではない（両方必要）
　開発の進め方・戦略はMicroProfileの方が時代に適応！！（個人的に支援）
　　オープンでやっている

　MicroProfile.io or/and JavaEE 8/9

・JavaEE　戦略的にはよい！！
　個々に記載する内容は、あくまでも提案内容（未決定）！！

　Cloud対応（Microservice対応）

・２年前と世界が変わった
　　クラウド化・マイクロサービス化
　　　マイグレーション・パスを用意
　　　JavaEEの後方互換性を維持
　　　REST(JAX-RS)は、今後重要→いままで以上
　　　　いままでは、サーバー：待ち受け口を作るのが多かった
　　　　今後、クライアント側：呼び出しでもRESTが重要
　　　　　非同期ノンブロッキングでつなぐ

・JavaEE9がメイン
　　JavaEE8はつなぎ
　　JavaEE9はクラウド

　JavaEE8の提案内容
　　マネジメントAPIとJMS,MVCはドロップアウト
　　　JMS２．０のまま
　　コンフィグレーションとヘルスチェック

　今後はリアクティブプログラミング
　リアクティブ宣言
　　即応性
　　耐障害性
　　弾力性
　　メッセージ駆動

　EE8では非同期、ノンブロッキング
　http2.0→複数のレスポンス

・JAX-RS 2.1　クライアント側の大幅な更新
　リアクティブ・プログラミング
　　非同期処理の改善：実装方法の改善
　　ノンブロッキング対応：リソース消費を防ぐ

　　RESTでよんでいく

・JAX-RS 2.0の非同期処理（コールバック地獄）
　EE8
　JAX-RS 2.1 Completable-Future<T>を利用
　　非同期処理をより簡単に、RxJavaも利用可
　　Jersey(じゃーじー）では

　JAX-RS 2.1:ノンブロッキング対応

　ヘルスチェック
　　サービスが生きているかどうかを監視できる

　コンフィグレーション：外部設定
　　設定情報を分けて管理する
　　Apache Tamayaなどを参考

　マルチ手ナンシー対応
　　テナントごとにカスタマイズ
　　マルチテナンシー対応：データ・アクセス
　　　データソースの実装も変えないと・・

　セキュリティ　JSR375
　　EE8とEE9（メインは９）

　　OpenID　コネクト

・JavaEE9　マイクロ・サービス
　　ラジブさん
　マイクロサービス開発の標準にしたい
　MicroService

　今まで：モノリシック（一枚岩）
　　　小さなプロジェクトなら楽
　　　一回作ったら、変えられない
　　　プロジェクトの全体はあくが大変になる

　マイクロサービス
　　それぞれの機能を分けて作る：疎結合
　　個々のサービスで個々のプログラミング
　　どっちを適用すべきか→必要なところで

　標準的な実装がない
　　開発者が選択→標準化

　マイクロサービス・デザイン・パターン
　　APIゲートウェイ：標準化するものではない
　　サービスレジストリ・ディスカバリ
　　　　　→サービスを登録する→ロードバランサが問い合わせ
　　サーキットブレーカー
　　　　　→負荷が高い・障害発生：リクエストをきる
　　　JAX-RSクライアントAPI拡張、アノテーション
　　　バルクヘッド
　ポリグロット・パーシステンス
　　JPA：RDBの永続化
　　　→NoSQL：カテゴリーわけをしたAPI
　　　　カテゴリ指定（Key/Valueの例）
　　JPAと似たような感じ

　CQRS:データの参照と更新を分離
　　分散アプリではリードはリード、ライトはライトでわける

　　Tolerant Reader（寛容な読み込み）→実装者が考慮（EE9未対応）

　チェインド・サービス

　非同期メッセージング
　　kafka,RabbitMQ
　　pub,sub用意

　サービスインスタンス
　　JavaEE9　JavaSE9のあと
　　　　　　　１つのJarファイル（Jigsawを使って
　　　A,Bが繋がっている場合、分けるとパフォーマンス悪くなる
　　　　　→プロビジョン方法の提供
　　　グルーピング

　コンシューマードリブン：　EE9未対応
　　Spring Cloud Contract、Pact

　ドメインイベント
　　マイクロサービス：分散ネットワーク
　　分散環境でのトランザクション

・その他
　クラウドプロバイダが提供するサービスを呼び出せる
　Auto Scale
　JavaEE9のリアクティブ対応：包括的なAPIを提供
　　　JDK9のFlowAPI

・動画もある（英語）

・MicrosoftがJavaOneに出展
・IBMさんがJavaをもう一度すばらしいものにしましょうよ
・コグニティブサービス

　マイクロソフトのビデオもみられる

　アイデアひとつでできる

　もうつぶやいている
　JJUG　CCCで紹介したい。足を運んでくれれば・・

■JavaOne２０１６総括
・自己紹介
・標準Java：特に進展なし
　JavaME,JavaFXはキーノート発表なし
　JavaME:SE Embeded
・今後への懸念
　JavaEE Guardians
　ロードマップは出たけど、リリースできるの？
　問題はEEだけではない
・Make Java Great Again　IBM
　IBM　SDK For Javaをオープンソースへ
　OpenJ9→OpenJ9ベースのOpenJDKがでてくる
　OMRの上にかぶせてOpenJ9
　Eclipse OMR
　　JITコンパイラ、GC,スレッドライブラリなど、言語に非依存な形で提供
　　CRubyで提供。CPythonは公開予定有り
　→COBOLもマイクロソフトCMRと同じアイデア
　Apache Harmony論争再び？
　JavaVMがIBMを主導したい？→戦いの場でないものはオープンソースにしたい
　だれがJavaを偉大にするのか

　標準Javaが遅い：誰かが追い越していく
　OSSとコミュニティが進化を加速していく
　標準が前に進まないなら、別の標準
　コミュニティーキーノート
　　エピソード２１：コーダーの覚醒
　　相変わらずの学芸会のり
　　ベンダー主導の情報発信の場→コミュニティ交流する場
　JavaOne
　　エンタープライズ職が強い

・トレンド
　DevOps,クラウド、マイクロサービス、リアクティブ
　アジャイルは常識：リリースサイクルの話
　DevOps：Jenkinsが一般的　一週回って次の課題
　コンテナ前提：Docker
　　パイプライン設計、テスト時間を短くするには、メトリクスが重要
　　テスト時間をどれだけ短く。メトリクス
　クラウド：使って当たり前。サーバーレス
　マイクロサービス：分けたサービスをどう管理するか
　イベントソーシング
　疎結合を優先し、非同期処理での不整合を許容する
　　Amazonは処理に失敗したらクーポン出してるよ
　Reactive
　　用語定義やメリットの議論が継続的
　　通信するという概念がボトルネックに

・未来予測
　数千数万のサービスで構成されたシステム
　　境界線があいまい
　　サーバーレスの延長
　サービスの制御は、全てプラットフォームに任せる

・まとめ
　誰がJavaを偉大にするのか
　　コミュニティやOSSと協業できる企業
　JavaOneはコミュニティの交流の場として機能している
　　もちろん、行く価値はあります

・おしらせ
　１２月３日　JJUG CCC　Fall

■Road to Duke's Choice Award
・自己紹介
・Heap Stats
・おことわり：思いで話メイン。主観が入ってるかも。技術的な話しない
・Duke's Choice Award
　　４つもらえる：参加チケット、Duke像、バッジ、Oracleプレスリリース登場権？
・HeapStatsって何？
　　JDP:マルチキャストで飛ばす
・挑戦の歴史
　２０１４年のJavaOne
　　　申請；落選
　２０１６年
　　　再挑戦
　意識したこと
　　バズワード入れてみた（IoT,ARM)
　　審査員がぐっときそうな技術　JavaFX
　　Javaへの暑い思い
　受賞
・連絡
　　英語でメールがきます
　　副賞は来年に繰り越し可能
　　住所と電話番号
　　授賞式まで内緒にしててね
・授賞式
　　JavaOne期間中
　　関係者全員で行ってよい
　　事前打ち合わせなし
・トリビア
　　Duke像はさわれない
　　２回ステージ
　　英語しゃべらなくてOK
・変わったこと
　　GitHubのStar数増えた
　　HeapStatsが記事にでた
・つづき
　Java Community Keynote
　　HeapStatsが登場
・コミュニティの中でのHeapStats
　　コミュニティ、メディア
・HeapStatsを作ったきっかけ
　Javaのメモリーリークディテクター作って
・ポリシー
　軽く・速く

■（LT）SideStory
・学芸会に参加して・・・
・ばんゆう：むこうみずのゆうき

Javaのラムダ式とStream APIを聞いてきた！

１０月１２日、Java SE 8:ラムダ式 & Stream API 入門セミナーにいってきた！
その内容をメモメモ・・・

---

年内に資格とると、Tシャツがもらえる

●関数型インターフェースとラムダ式
・なぜラムダ式がはいったのか
JavaSE8：関数型スタイルの処理への対応
　背景：CPUアーキテクチャの変化
　マルチコア化→並列処理
　並列処理を効率化するには、関数スタイルの処理のほうが便利
　　関数＝入力した値に対して必ず同じ結果を返すもの
　JavaSE8：関数型インターフェースの導入
　　オブジェクト指向にはなじみにくい
　　でも、関数型いいよ
　　関数をオブジェクトで扱う→関数型インターフェース
　　→単純化できる
　　パターンはjava.util.functionパッケージを使う

・関数型インターフェース
　単一のabstructメソッドを持つインターフェース（SAMインターフェース）
　　staticメソッドとデフォルトメソッドはOK
　　　staticメソッド
　　　デフォルトメソッド：デフォルト実装を与える
　　java.lang.ObjectのpublicメソッドもOK
　Java8の新機能
　　SAM；しんぐるあぶすとらくとめそっど
　　　@functionalInterface　をつけると、関数型と思っていることを示す
　　　→そうでなかったら、エラーになる

・ラムダ式の前に
　無名クラス：見通し悪い
　　→ラムダ式導入

　ラムダ式
　　関数型インターフェースを実装するクラスのインスタンスかを簡略化する
　　ための構文
　　　関数型インターフェースのメソッドにフォーカスして実装を記述できる
　　　　メソッド名は書かなくても推論できる
　　　　変数Xはどこで宣言している　引数名

　ラムダ式は何を簡略化している？
　　引数リストとメソッドを書けばOK

　→バイトコードレベルでは無名クラスとラムダ式は違う

・省略記法
　　がた省略OK
　　引数がない場合（）
　　引数１個は括弧省略可能
　　１行なら中括弧も省略OK
　　returnも省略OK
　　ラムダ式のメソッド呼び出しは
　　　System.out::println
　　でOK

→書き方を決めないと安定しない
　コード読みにくくなる

・汎用的な関数スタイルの操作
　　基本形は５つ
　　Function
　　Consumer：void
　　Supplier：値を返す
　　Unary（ゆーなりー）Operator：演算
　　pridicate:ぶーりあんで返す
　ひきすう２つの関数型bifunction

●StreamAPI
　StreamAPI
　　データをパイプラインで処理するAPI
　　　Streamの生成
　　　中間操作：遅延評価
　　　終端操作

　Streamの作り方
　　コレクションから
　　配列から
　　数値範囲から
　　任意の要素 Stream.of

　IntStreamを使った繰り返し処理
　　for文を使った繰り返し
　　IntStreamを使った繰り返し
　→for文は並列処理が難しい
　　並列処理は
　　.parallel().forEach()とすればいい
　→１００件とかならfor文のほうが早い

　中間操作のためのメソッド
　　filter
　　map
　　flatMap
　　distinct
　　peek：なにもしないけど
　　limit
　　skipというメソッドもあるので、先頭から何個～何個というのができる

　終端操作
　　forEach
　　reduce　２つパターン
　　collect
　　min/max
　　count
　　以下は、ショートサーキット操作（全要素処理しないかも？）
　　findFirst
　　findAny
　　anyMatch
　　allMatch
　　noneMatch

※Optionalクラス：JavaSE8から
　値がNULLかもしれないコンテナオブジェクト

・StreamAPIの例
　Personクラス：年齢５０より小さい
　カンマ区切で出だす→collectでリダクション処理
　１０１以上２００未満の要素の合計を求める：リダクション処理

　リダクション処理の考え方
　（じつは、IntStreamのmapToInt().sum()でおわる）
　　IDEは型が違うことしか教えてくれない：何を変えればいいのかは教えない

・コレクションAPIのデフォルトメソッド
　　removeif predicateの結果をみて、のぞく

●JavaSE8の資格のお話
　ゴールドがラムダ式つかえますか？みたいなはなし
　今３５％オフで受けられる
　　クレジット決済
　　オラクルからチケットを買う

「Springをなんとなく使っている人が抑えるべきポイント」などを聞いてきた！

１０月５日、JSUG勉強会　２０１６年その８～今から始めるSpringに言ってきたので、その内容をメモメモ・・・するんだけど、

もう、ちゃんとしたメモがネットにでていた

「JSUG勉強会 2016年その8 ～ 今から始めるSpring」に行った
http://qiita.com/y_q1m/items/d8e12d5ad1b7b71aeef5

ので、ちゃんとしたいのが見たい人はそちら！
（ここのメモは、ろりぽじさんんIT用語説明レベルのアバウトさ＝雰囲気レベルです）・・・
なので、ここでは、最後に「所感」を書いておこう！

---

■DI/AOPについて学んでみた
・自己紹介
・会社紹介（TIO）
・Springと私
　基礎知識なしでなんとなく使っていたレベル
　インターフェース、applicationContext.xml
　右に倣え
・なぜ
　DI/AOPを調べれば分かるよ
・DIについて調べてみました
　概要
　　依存性の注入：外部の設定ファイルなど※
　　※ApplicationContext.xml　アノテーションで設定
　メリット
　　結合性低下によるコンポーネント化の促進
　　単体テストの効率化
　手法
　　インターフェース注入
　　Setter注入など
・DIとは（イメージ）
　class Service 利用:Dao　　class DaoImple
　　　　注入　　　　　　　で異性
　　　　　　DIコンテナ
　　　　　　　参照
　　　　　　ApplicationContext.xml→依存関係を定義
　→newすることがなくなる

・これっておいしいの
　　脳内アプリ；会員サイトの検索機能
　　イメージ：ブラウザ→アプリケーション→DB
　　登場クラス
　　　Action
　　　サービス
　　　DAO
　　　user：値格納・情報返却

・DIを使わない構成
　　利用する側のクラスが必ずnewする→密結合
　　利用する側・される側が密結合している

・DIを使った構成
　　DIコンテナで生成して利用する側に注入する
　　利用する側、される側が疎結合になっている
　　　DIコンテナ→ApplicationContext.xml

・で、メリットは
　クラスの関係が疎結合
　　変更に対応しやすい
　　試験を実施しやすい
　　　　固定された値でテスト

・AOPについてしらべてみた
　本来すべき処理とすべきでない処理
　本来すべきではない処理をあとから呼びだす

・AOPを使った場合と使わない場合の確認
　AOPを使う→トランザクション管理クラスを作る
　　本来すべきではない処理の実装ミスを防げる
　　一元管理できる
　　処理を変更せずに後から追加できる

・まとめ
　SpringにはDI/AOPを利用する機能が備えられている
　疎結合ナシステムを構築できる

■Springをなんとなく使っている人が抑えるべきポイント
・自己紹介
・概要
　Springｗ９おなんとなく使っていませんか
　　上手く動かないときの対応ができない
　　応用が利かない
　　面白くない
　主要なポイントを抑えて、開発を面白くしましょう
・主要なポイント
　　Beanのコンフィギュレーション：３通りある
　　DI/AOPの使いどころ
　　データアクセス

・コンフィグレーションの方法
　３種類選べる：結果は同じ
　　XML
　　アノテーション　@Compornemt
　　JavaConfig　@Bean
　→DIコンテナが管理するオブジェクトをBeanと呼ぶ

XML
　　メリット：分離できる。一元的に管理、再ビルド不要
　　デメリット：メンテが大変
アノテーション
　　メリット；記述が楽
　　デメリット：プログラムとBeanの定義が混在
JavaConfig
　　メリット：分離できる、タイプセーフ
　　デメリット：メンテが大変

　一般的と思われる使い分け
　　業務個別のBean(コントローラー、サービス、Dao)はアノテーション
　　裏方のBeanはXMLまたはJavaConfig
　　　　→そもそも、アノテーションが付けられない

・DI/AOPの使いどころ
　DI：すべてをBeanで管理するわけでない
　　ステートレスなオブジェクト（コントローラー、サービス、Dao）　
　　　→BeanにしてDIで紐付け、ASOP
　　処理のたびにオブジェクトが生成され、個別のフィールド値を設定する
　　　Entity,DTOはBeanにしない

　AOP：
　　レイヤー間にAOPで共通処理（BeanにしかAOPできないという事情も）
　　業務的な処理は基本的にAOPは使わない
　　　→わかりにくくなる（例：税率かける）

・同じオブジェクトが使われている
　　リクエストのたびに、コントローラー、サービス、Daoのオブジェクトが
　　　作成されるわけではない
　　リクエスト間でデータ共有（キャッシュ）
　　スレッドセーフにする必要

・インターフェースは必須じゃない
　　インターフェースを介さなくてもDIは可能
　　用途の例：各レイヤーの補助的なBean

・コネクション・トランザクション周りの仕組み
　　トランザクションの開始・終了はSpringが行う
　　　ソースは書かなくていい

　画面周りの処理の流れ
　　Dispatcher Servlet
　　　HandlerMapping：コントローラー特定
　　　HandlerAdapter：引数の値を用意
　　　ViewResolver：Viewの形式ファイルを特定

　コントローラー
　モデル
　View

・認証・認可の仕組み
　認証とURLの認可はServletFilterで行われている
　DispacherServletに依存していない（SpringMVCに依存しない）
　認可の主な対象はURL、メソッド、画面描画の３種類

　認証のサーブレットフィルターなど
　　セキュリティコンテキスト：HTTPSession.ThreadLocalなど
　　SpringMVCを使わなくても使える

・サーバーを起動しなくてもBeanをテストできる
@before
public void setup()
　{
　　　ApplicationContext ctx = new AnnotationConfigApplicationContext(TestConfig.class);
fooserve = ctx.getBean(Fooservice.class);

・Spring Bootが行っていること
　　　必要なJarファイルのダウンロード、
　　　Beanのコンフィグレーション、
　　　サーバーの実行
　業務固有のBeanのプログラムつくりは変わらない
　組み込みじゃないTomcatにデプロイ可能

・最後に
　　おすすめ
　　　改訂新版Spring入門
　　　Spring徹底入門

■悩めるJava初心者のためのSpringをどーんとやってみよう
　「よい子・悪い子・普通の子」

・自己紹介
　よい子のやまざきさん
　普通の子　ときさん
　わるいこ　てらひでさん

・どうやってSpringを勉強したか
　よい子
　　仕事で使うのが一番！SpringOne
　　苦労：良くも悪くもドキュメントが豊富
　普通の子
　　本を読んで独学。Springを使う開発現場がなかった
　わるいこ
　　勉強などしていない。
　　　　勉強しなくても使えるフレームワークがよいフレームワーク
　　苦労したこと：仕事にならない

・事前に勉強することはあるか
　JSP-Servlet、DDDとか
　よい子
　　Reactive！
　普通の子
　　Java文法（例外などのややマイナー部分）
　　DBまわり、Webまわり、JSP-Servlet、JUnit
　　→ローカル変数の生成と消滅
　わるいこ
　　男気のある優しい先輩の見分け方
　　　たばこをすうか、おさけをのむか
　　　姉御みたいなひと
　　→会社にいますか？
バージョンは６の人は
　　よいこ
　　　８にする
　　普通の子
　　わるいこ
　　　いいんだよ、すごくいいんだよ
　→８にあげられない場合は
　　わるいこ：８に使える現場にうつる

Spring初級者になるための勉強範囲は
　よいこ
　　・だめだ、全部だ、ドキュメント全部読め
　ふつうのこ
　　・データアクセス、トランザクション、SPりんｇMVC
　わるいこ
　　・難しいことは全部Springがやってくれる

初心者にぜひ理解してほしいこと、１つ上げるとしたら何
　よい子
　　理解して使うこと！なんとなくでは、正しく動いてないぞ
　普通の子
　　newが１つもなくなるわけではない
　だめなこ
　　Springは開発者が仕事をサボる生産性をあげるための
　　便利な道具

SpringBootから勉強するのはあり
　よいこ
　　　いいんじゃないか。興味を持つため
　ふつうのこ
　　　おすすめはしない。何が起こっているかわからない
　わるいこ
　　　超おすすめ。Gradle最高！

初級者・中級者になったことは、どう確認すればよいか
　よいこ
　　システム作って、誰かに売る
　普通の子
　　すう画面のWebアプリを自分で設計・実装して、上級者に見てもらう
　悪い子
　　GitHubにソースコードを公開してTwitterで自慢する

発表するのはどのレベル
　よいこ
　　いつでも
　普通の子
　　いつでも
　悪い子
　　難しいことをする前に、ビアハッシュでLTだ

最後の一言
　よいこ
　　JSUGに参加しましょう
　普通の子
　　本を買って・・・
　悪い子
　　こまったら、つぶやく

SpringDay2016
　１１月１８日
　すごいセッション
　全て無料、懇親会、LT

---

■所感
　DIの「依存性」や「AOP」などはソフトウェア工学から来ている用語だと思う。
　なので、そこから入らないと、？？？になってしまう。

　たとえば、AOPのとことで、「本来すべきでない処理」のところで、
　ログ処理が入っているのはいいとして、
　「トランザクション処理」は、どうなのどうなの？
　いや、それは、しなきゃだめな子な処理でしょ！

　これは、「横断的関心事」というソフトウェア工学の概念を
　テキトーに言い換えてしまったから起こることで、
　ソフトウェア工学的に言うと、

　処理は

　　　その機能内で閉じて考えてすべき処理（局所化すべき処理）
　　　その機能内で閉じて考えず、（横断的に考えて）すべき処理（横断的関心事）

　にわけられる。

　前者は、機能要件で記載されるもので、受注なら受注、発注なら発注のオブジェクトが
担当するというように、担当するオブジェクトが決められ、そのオブジェクトが、他オブジェクト
を監視・制御することで、処理が決定できる。

　後者は、主に非機能要件で議論されるもので、受注・発注のみならず、横断的に
調停するオブジェクトが必要となるものである。これが横断的関心事
　たとえば、トランザクションは、受注・発注・取引先など、いくつもの機能に
同時にかかわり、矛盾ないように調停しないといけない。これが横断的関心事
　ログも、受注と発注が別々だと、わかりにくい（時間がずれてたりすると、
前後関係不明になる）
　このほかには、セキュリティなどがある（受注はセキュリティばっちりだけど、
発注はザルとかだと、意味ない）

　Diについても、ソフトウェア工学的に、背景がある（文脈＝コンテキスト）
そのへんについては・・・いつか、かく

位置をGoogleMapに表示するためのAPI利用法

場所とタグを含んでTweetし、みんなの位置をGoogleMapに表示するために必要なＡＰＩ
http://blog.goo.ne.jp/xmldtp/e/a741445a4bfde8e7ce03dca78db360f7

の後半、「位置をGoogleMapに表示する」を行います。

■お題
前の

Yelp APIを使って、東京のマクドナルドを検索する方法
http://blog.goo.ne.jp/xmldtp/e/f307a7f1a7d24b4c8983da873411d17f

で出てきた、

某マックの緯度経度
　latitude": 35.6977588049412, "longitude": 139.707627867968

にマーカーをつけ、その周辺の地図を表示する。
（地図は、lat: 35.6977, lng: 139.70762　を中心に出す）

---

■手順

Google Mapsの表示にはAPI登録が必須になりました
http://design-plus1.com/tcd-w/2016/06/google-maps.html

にある

・「APIキーの取得」
　をします
　（googleアカウントは持っているという前提を置きます。
　もっていない場合は、googleアカウントの取得が必要です）

次に
・「プログラムを作成」

して、
・ブラウザで表示

します。以下詳細に説明します。

---

■APIキーの取得

まず、Googleアカウントでログインします。

https://accounts.google.com/servicelogin?hl=ja


その後、そのブラウザで

Google Maps APIs for Web
https://developers.google.com/maps/web/


キーを取得をクリック

続けるをクリック

適切に選択して「同意して続行」

キーの制限「なし」でよければそのまま、いやなら適当に設定して「作成」。次にAPIキーが出てくる。

閉じる前に、キーの値をコピーして、どこかに保存する。

---

■プログラムを作成
まず、

https://developers.google.com/maps/documentation/javascript/

にある「デモとサンプルコード」のソースをコピー

そして、

https://developers.google.com/maps/documentation/javascript/markers

マーカーを参考に
（サンプルコード中、上の var markerは、引数内に
map: map,
　がある。これは初期表示などに使う。一方下のvar markerは、
　引数内にそれがない。その場合は、
　　marker.setMap(map);
　と、動的にマーカーをつける)

お題である

某マックの緯度経度にマーカー
　latitude": 35.6977588049412, "longitude": 139.707627867968
地図
　lat: 35.6977, lng: 139.70762を中心
にしてみる。

以下のようなソースになる。

<!DOCTYPE html> <html> <head> <!-- This stylesheet contains specific styles for displaying the map on this page. Replace it with your own styles as described in the documentation: https://developers.google.com/maps/documentation/javascript/tutorial --> <link rel="stylesheet" href="https://developers.google.com/maps/documentation/javascript/demos/demos.css"> </head> <body> <div id="map"></div> <script> function initMap() { // Create a map object and specify the DOM element for display. var map =" new google.maps.Map(document.getElementById('map'), { center: {lat: 35.6977, lng: 139.70762}, scrollwheel: false, zoom: 18 }); var myLatLng = new google.maps.LatLng(35.6977588049412,139.707627867968); var marker = new google.maps.Marker({ position: myLatLng, map: map, title: 'Mac' }); } </script> <script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" async defer></script> </body> </html>

YOUR_API_KEYに、コピーしたAPIのキーを入れて、保存

---

■ブラウザで表示

保存したものをIE等で表示させる。こんなかんじになる

・・・って、このMac知ってる！いったことある！！
多分、よく要求開発アライアンスの会場になる、日本総合システム株式会社の近くにある、東新宿駅前のマック・・・

って、なぜここのマックなんだろう？そんなに有名なのか？

Yelp APIを使って、東京のマクドナルドを検索する方法

げ、食べログAPI使えないんだ。ってことで、Yelp API
http://blog.goo.ne.jp/xmldtp/e/9e5d2883cd932f501296c27b423a40f3

のつづき（実践編）。
yelpAPIを使って、東京のマクドナルドを検索する。
PHPで作ってみる。

---

■システム構成

ロリポップ上にホストがあり、そこにPHP（sample.php）を置いている。
そのPHP（sample.php）が、yelp APIにアクセスしている。
ブラウザで、そのPHPファイル（sample.php）を表示している。

手順は、以下の通り。
・まず、yelpにサインアップ
・APIキー等を取得
・サンプルプログラムをダウンロード
・サンプルプログラム修正
・sample.phpをアップロード、表示
以下、詳細に

---

■まず、yelpにサインアップ

Yelp for Developers
http://www.yelp.com/developers

に行く。

「GetStart」をクリック。
ログインしていなければ（できっこない。まだ登録してないんだから）
以下の画面がでるはず

Sign Upをクリック

名前とかをいれて、Sign UPなんだけど、ここで、ZIP Codeとあるんで、
素直に郵便番号を入れると・・・
エラーになって、郵便番号の下に、国名が入れられるようになる。Japanを選択

なんか、登録できた旨が表示される。
ここで、メールアドレスを入れていると思うんだけど、
そのメールアドレスにメールが来ているかチェック（着ているはず）

メールの「Confirm Email」をクリック。

---

■APIキーを取得
サインアップが成功しているブラウザで（つまり、ログイン後？）

Yelp for Developers
http://www.yelp.com/developers

に行って「GetStart」をクリックしたら、以下の画面になったんだけど、

それでいいのかな？とにかく、この画面から・・・

Your Website URLには、PHPを置くサイト（ロリポのabc.main.jp上に置くのなら、abc.main.jp)
How you will use the APIは、Searchとした。いいのかな？
Industryは、otherで、そうすると、下に空欄が出たから、softwareと入力した。もう適当。
その下のチェックボックスに（同意するか）チェックして、submit

っていう画面が出てきて、キーが入力できる。（実際には、この右側にキーが出る）

コピーをとって控える。後で使う。

---

■サンプルプログラムをダウンロード
　サンプルが以下のサイトにある。

https://github.com/Yelp/yelp-api/blob/master/v2/php/sample.php


Rawをクリックすると、テキストがでてくるので、それをファイル保存して、sample.phpとして
保存する。

　このソースを見ると分かるけど、OAuthのライブラリを使っている。それは

https://github.com/Yelp/yelp-api/blob/master/v2/php/lib/OAuth.php

にある。おなじく

Rawをクリックすると、テキストがでてくるので、それをファイル保存して、OAuth.phpとして
保存する。このOAuth.phpは修正しなくていい。そのまま使う（libフォルダは作成するけど）

---

■サンプルプログラム修正
　ダウンロードしてきたサンプルプログラムsample.phpのほうは、修正する。
　まず、開いて、

はじめのほうにある、$CONSUMER_KEY以下４つは、「APIキーを取得」で取得した、キーとか、トークンとかそのたもろもろ（４つあるはず）をいれる（順番に）。

　その下の、$DEFAULT_TERMを修正すると、本来その言葉、場所を検索するんだけど、このままだと
分かりにくいので、今回は、ここを「直さないで」以下のところを直す。

　まず、110行目あたり、

　　$url_params['term']=$term;
　　$url_params['location']=$location;

と、引数をそのまま入れるようにする。

　そして、最後のあたり

$optionに入れているところからコメントアウトして、
$termに、検索したいマクドナルド（英語で"mcdonalds")、$locationに"tokyo"といれて、
query_apiを呼ぶと加工してしまうので
search($term,$location);を呼んで、プリントアウトする。
こうすれば、JSONがそのまま見える。

---

■sample.phpをアップロード、表示
　今回は、ロリポップを使うという話なので
　sample.phpを直下におき、
　libというフォルダをつくり、その下にOAuth.phpをおく
ことになるけど、他のプロバイダでも、同じように、sample.phpは直接見えるところ、
OAuth.phpはlibの下になるように置く。

　そして、sample.phpをアクセスすると

みたいなかんじで、JSON形式で、検索結果が見れる。

緯度経度指定などは、

https://www.yelp.com/developers/documentation/v2/search_api

を参照。cllだと思うけど、今やっている時間が無いので、また今度。

【参考サイト】

http://imagination-i.net/2014/04/15/javayelp-api%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/

https://www.imamura.biz/blog/20635