【勉強会メモ】JavaOne 2017 報告会 in 大阪
日時：2017/10/28(土) 13:00 〜 18:00
場所：日本オラクル株式会社 関西支社
毎年サンフランシスコで開催されているJavaOneの報告会。実際に現地で参加してきた方々によるJavaの最新動向。タイミング的にJDK 9の話が中心だと思ってはいたが、リリースが延期される間に主要な機能については関ジャバでも既に取り上げていたこともあり1つ1つの詳しい解説は少なめ（Moduleぐらい）だった。
Javaエンジニアの関心事としては今後のリリースサイクルとOracleのサポート、技術的にはModuleどうすんねん？というあたりだろうか。今まで1,2年単位で新機能に追従していたのに、半年のサイクルに追従できるのかというのは少し不安ではある。従来のリリースモデルからの移行期間もそれほど猶予があるわけではないので、まずは影響の大きそうなModuleにどう対応するかが大きな課題になりそう。さらに半年単位で新たな機能も入ってくるので今後の動向にも注意が必要。
ポジティブな面ではコンテナ技術への対応は期待感があった。fn projetは簡単に試すことができるので触っておきたい。Persistent Memoryについても今後のサーバサイドJavaのあり方に影響を与えそうなので動向を見守りつつ抑えておきたい技術だ。
Graal/OpenJ9についてはちょっと理解が追いついておらず粗いメモになっている気もしますがご容赦ください。長丁場の勉強会の最後にこのテーマは正直しんどかった。。
JavaOne 2017 overview & announcements（伊藤 敬さん）
伊藤 敬さん（日本オラクル株式会社）
Java One 2017 Event Schedule
Java Kyenote
- Mark Cavage…Java SEとEEの開発トップ
- 去年就任してから色々動きがあった
- もともとAWSにいたりEaasの人
- EEとSEをうまくまとめている
- Georges Saab…EE
- Mark Reinhold…SE
これからのJavaの方向性
- Open
- Evolving
- Nimble…軽量化
- Scalable
- 8がリリース
- さらなるOpen化
- 軽量性
- Eclipseへの移行
Java SE
- OpeJDK活用
- リリースサイクルの高速化
Announcement New Release Model of JDK
従来のリリースモデル
- JDK 9⇒過去最多の機能追加
- 従来のリリースモデルは2年に一度を目標
- 機能リリース
- 実際は2年以上かかっている
- SE8は9ヶ月遅れ
- SE9は計画発表時で既に6ヶ月遅れ、最終的に1年7ヶ月遅れ
- １年間のサポート
- 実際は2年以上かかっている
- 更新リリース（セキュリティパッチ）
- Oracle製品は全部3ヶ月ごと（1月、4月、7月、10月）
- 長期サポート
- OcaleJDKは1年以降も長期サポート
- OpenJDK
- ソースコードで提供、研究目的的な位置づけ
新しいリリースモデル（JDK9から開始）
- 機能リリース⇒6ヶ月に一度のリリースに固定
- OpenJDK
- 更新リリース：３ヶ月ごと⇒サイクルは今まで通り
- OpenJDK & OracleJDK
- メンテナンスのみで機能更新は行わない
- 長期サポート（LTS、有償）⇒18年9月から開始
- Olacle JDKのみ
- 3年ごとの機能リリースをサポート
ソースコードの管理モデル
- 従来のモデル
- 新しいモデル
- JDK 9⇒18.3⇒18.9⇒19.3...
- 18.9 LTS商用サポート（26年9月まで）
- 21.9 LTS商用サポート（29年9月まで）
Java SE 18.3のスケジュール
- 2017/12/14⇒Rampdown Phase One
- 2018/1/11⇒All Tests Run
- 2018/1/18⇒Rampdown Phase Two
- 2018/2/22⇒Final Release Candidate
- 2018/3/20⇒General Avilability
公式アップデート終了スケジュール
- SE 8⇒2018年9月…ここを目指してモジュール対応し18.9に向けて対応するのが現実的かも？
- SE 9⇒2018年3月
- SE 18.3⇒2018年9月
新しいリリースモデルに伴う変更
- Java SE 8 から後継バージョンへの自動更新は行われない
- Java SE 9 の32ビット版のバイナリ提供の予定は無い
- Java Plug-inおよびJava Web Startのサポート期間はJava SE 8まで
- 無償は18年3月まで、有償は19年3月まで
- Java SE 18.3からはバンドルされない
Javaの商用サポート
SE 8⇒Premier：22/3、Extend：25/3 SE 8 Deployment Technology⇒Premier：19/3 SE 9 ⇒Premier：18/3、Extend：設定なし 18.3 ⇒Premier：18/9、Extend：設定なし 18.9 ⇒Premier：23/9、Extend：26/9
Java SE 9 日本語ドキュメント公開済み
Java EE 8
Java One 2018
2018年は10/28〜11/1予定
HeapStatsとProject Jigsaw
久保田 祐史さん
www.slideshare.net
Web+DB Press vol.101のJava9 のModuleの記事を執筆
- 作者: 森本利博,武井優己,SPY,久保田祐史,大倉香織,石川雅之,袴田類,山下和彦,牧大輔,穴井宏幸,加藤隆一郎,加藤佑典,金昌熙,佐藤健太,のざきひろふみ,うらがみ,久田真寛,ひげぽん,池田拓司,はまちや2,竹原,牟田裕太郎,粕谷大輔,陶山嶺,長谷川智希,石田和太郎,小林純一,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2017/10/24
- メディア: 大型本
- この商品を含むブログを見る
HeapStats
Project Jigsaw
- JAR HELL⇒依存性が複雑怪奇
- 標準ライブラリ⇒巨大かつ分割不可
- 紛失したライブラリはどれ？
- コンフリクトがどこで発生？⇒依存性を定義できないのが問題
- 内部APIを安全に変更できる？⇒内部だけで使いたいけどPublicにしないといけない
- PublicがPublic過ぎる
⇒解決策を測るのがProject Jigsaw
Module⇒パッケージが入っているコンテナのようなもの
module-info.java の定義
- モジュールの依存関係
- 公開するパッケージと公開先
標準ライブラリもモジュール化
モジュールの確認や使用
jdepsコマンドで依存性を確認可能module-info.javaの雛形を作成も可能⇒たくさんのパッケージに公開する時などに漏れがなくなる
jlinkでライブラリ化
デモ
src/配下にModule- Moduleごとに従来の構成でパッケージを配置
- Moduleもパッケージ同様ユニークな名前にする
- どのモジュールのどのクラスを実行するかを指定して実行
jlinkでライブラリ化- Javaが入っていない環境でも実行可能
- 今後はコンテナで実行しやすくする
Q：モジュール名もユニークにするとあったがパッケージ名のようにドメインのような形になるのか？
A：YES 構成的にはパッケージ名の下にまたパッケージ名が入るイメージ
アンチパターン
classpathとmodule(path)を同時に指定してはいけない- 実行はできるが、エラーがわけわからなくなる
- モジュール化していないライブラリをmoduleパスで呼び出すことはできる
- モジュール化するまではclasspathで指定するほうがおすすめ
3年目のJavaOneぐらい大目にみてよ
佐々木さん
- JavaOne2017で登場したライブラリやツールの紹介
- JavaOne2015からJavaOne2017まで3回の参加で得た経験や感想について
Ten Simple Rules for Writing Great Test Cases
www.slideshare.net
- Think before you act⇒まずは考える
- Make your test understandable⇒テストはわかりやすいように
- テストされるコードよりテストコードをわかりやすく
- コメントをたくさん書く
- 失敗時の理由が分かりやすいように
- Keep your test small and simple⇒テストは小さく単純に
- Test one thing only⇒テストは１つずつ
- Fast test only⇒テストの実行時間は短く
- ユニットテストはなるべく頻繁に実行する
- 結果がすぐわかるように
- 遅いテストは頻繁に実行したくない
- Absolute repeatability⇒テストはいつも同じ結果になるように
- Independent test only ⇒テストは他のテストに依存しないように
- どんな順番でテストを実行しても同じ結果になるように
- 一部のテストのみを実行して素早くデバッグできるように
- Provide diagnostic data on failure⇒テスト失敗時の状況を出力する
- No hard-coding of your environment⇒環境をハードコートしない
KISSの原則
- Keep it simple, stupid
- Keep it short and simple
⇒テストコードにかぎらずシンプルにしておくことは重要
Compiling Java to JavaScript How to Replace Applets Without the Plugin
Session Catalog | JavaOne 2017
Javaでゲームのような画面でプログラミングする
TeaVM
- JavaからJavascriptへのトランスパイラ
- VMではない
- マルチスレッドをサポート
- Lambdaを含む全ての言語構造をサポート
- 主要なJavaAPIクラスを実装
- バイトコードからJavascriptに変換
- JavaにかぎらずScalaやKotlinからも変換可能
トランスパイル
- トランスパイルは完璧ではない
- AppletをHTML5アプリに変換したいときに試してみてもいいかも
3年目のJavaOne
ホテルの予約
- サンフランシスコは平均宿泊料金が世界一
- JavaOne開催期間は値段が跳ね上がる
- ホテルは早めに予約⇒ほぼ1年前
英語
- ほとんどのセッションはスライドがある
- 基本的な技術バックボーンがあれば理解しやすい
- 日常生活のほうが大変
- バーボンが通じない⇒銘柄を言っていくことでありつけた
2年目はU.S Citizensで入国審査できる
- 到着した日の過ごし方で全てが決まる⇒野球を観て過ごす
- 到着した日は晩まで寝ない
- バーボンをリベンジ⇒1回の発音で通じた（ブーブン）
- ⇒ダイキリが通じなかった⇒違うバーで翌日リベンジ成功（ダイキュリー）
３年目も晩まで寝ない
- カリフォルニア科学アカデミーに行く
- 戦争記念オペラハウスに行く（オペラのシーズンらしい）
- Google Mapに周辺の食事のマップ
- バーでアメリカ人と友達になる
JavaOneで感じたJavaの今とこれから
きしださん
Javaが変わった
OpenJDK ライフサイクルおよびサポートポリシー - Red Hat Customer Portal
18.3にvarが入る
- 言語仕様ですら6ヶ月でかわる
- なにが変わるか事前に把握しづらい
- なにが変わったか事後に把握しづらい
- なにが動かせるか把握しづらい
fn project
fn projet は簡単に試せる
※メモ qiita.com
サーバレス
- 要するにCGI
- ゲートウエイだけが立っていてアプリケーションはその都度プロセスを動かす
- サーバ管理の必要性が低い
- スケールアップが容易
- 多重化はしたいけど不可はそう高くないみたいなところにいいかも
- 企業規模が多ければ案外多いのでは
Javaの欠点
- プロセス起動が重い
- 一度しか実行されないので実行時最適化が無駄
プロセス起動が重い
- 読み込むクラスを減らす⇒モジュール化
- 実行時の最適化が無駄⇒予め最適化⇒AOTやOpenJ9
色々変わるけどモジュール化が大事
- プロジェクトごとにリリース可能
- Dockerに対応しやすくなるのもモジュール化によって実現
JUnit5
- 再設計した
- だいぶ便利になった
- Nestedが便利⇒見やすく書ける
- メタアノテーション⇒tagを使って書きやすくなった
- パラメタライズテスト⇒パラメータを変えたテストが書きやすくなった
Intel's Persistent Memory in Java Platform
きつねさん
IntelとOpenJDK
Persistent Memory（PM）
- Oracle Database 18c でPMサポート
- OOW'17でアナウンス⇒5倍ぐらい早くなる
PM in Java
- Volatile usage
- 大容量量メモリ
- Persistant usage
- 高速ストレージ
2 kind of Volatile Usage
1 DAXでPM上の仮想アドレス空間に配置（全部PMに載せる）
- 割り当て方を考えなくて良いので簡単
- メモリアクセス速度＜大容量メモリの場合に有効
例） - BigData - In-memory db
java実行時のオプションで指定できるようにする予定
2 一部をDRAMに乗せて残りをPM
- ユーザーが割当を指定
- プロファイリング結果をもとに自動で割り当てて最適化
- ⇒実際に自動でやるにはまだ難しいので割当指定が現実的
-Xmp500gのようにオプション指定- 以降はPM使うというようなコードも書ける
Persistent(Storage) usage
Persistent Collections for Javaを使ったデモ
-ObjetDirectory - putでオブジェクトを永続化 - getでクラスを指定して取得 - 永続化しているので違うJVMでもgetで取得できる - Transaction - 永続化のトランザクション制御 - サンプルはRAMディスクを使ってエミュレートする
永続化可能なクラス定義
⇒永続化されているオブジェクトを取得後にオブジェクト内の値を変更すると永続化されたObjectDirectory上のオブジェクトの値も変わる
まとめ
- IntelがめちゃくちゃJavaに力を入れている
- メモリとして使うほうは早くJavaでも使えるかも
- ストレージとして使うAPIはPanama待ち
- APIは今でも試せる
- RAMデスクでエミュレート
- 対応するOSS DBが出て来るのはもう少し先かも
JVM関連の最近の出来事 Graal/OpenJ9
じゅくちょーさん
www.slideshare.net
Graal
Twitterが既に利用
- すでに本番環境でGraal使っている
- OpenJDK8ベースの独自JDKを使っている
Graal VM
JVM上で他の言語が動いている
- Graal VM上の言語は相互に呼び出し可能
Truffle
- 言語実装要フレームワーク
- ASTインタプリタとして言語を実装できる
- JVM言語以外はTruffleを通じてインタープリタを作る
- C,C++,FortranはさらにLLVMが間にはいる⇒Sulongというのがある
オレオレ言語をTruffleで動かす⇒JJUG CCCで続きをやる予定
Graal & Truffle
パフォーマンス
まとめ
OpenJ9
JVMの実装
など
⇒JavaエンジニアとしてはJVMの実装もアプリケーションに合わせて実装したい
OpenJ9
J9の特徴
などなど
OpenJ9はOMRを使用する
Eclipse OMR
OpenJ9ではクラスファイルを扱いやすくなっている
Conversion to ROM
- J9がROMクラスに変換している
- プラットフォームに合わせてROMクラスができる
From ROM to RAM
- 書き込むときにはRAMに変換
クラス共有
- JVMをまたいでROMクラスを共有
- 起動が早い
- フットプリントが小さい
J9のパフォーマンス
- スタートが35%早くなる
など
Ahead-Of-Time(AOT)コンパイル
- OpenJDK/OracleJDK9にexperimentalで含まれる
- Linuxのみ
jaotcコマンド
Startup time
- AOTを使うと早くなる
J9のツール
DDR(Direct Dump Reader)
- J9用コアダンプ解析ツール
- DDR Interactiveというフロントエンドもある
Open J9ではできなさそう
DDRが提供すること
- そのアドレスの構造を出力する
- その他の情報を出力する
- ユーティリティ
- データ解析
⇒GDB弱者にはやさしいかも
まとめ
【勉強会メモ】Deep Learning Lab コミュニティ イベント 第4回
日時：10/24（火）15:00-18:30
場所（大阪サテライト会場）：Blue+（ブルータス）貸しスペース（5F） 大阪府大阪市北区芝田2-9-17 マエダビル
東京会場：日本マイクロソフト株式会社 東京都港区港南 2-16-3 品川グランドセントラルタワー
Deep Learning Lab とは
ディープラーニングに関連する技術とビジネスの両面に精通したプロフェッショナルたちが開発事例や最新技術動向を情報発信するコミュニティ
Microsoft Ignite! AI ソリューションアップデート
発表：MS畠山さん
Igniteで発表された内容の共有
Microsoft Ignite | Orlando, FL | September 25-29, 2017
Igniteとは
ビジネスを推進するために必要とされる、Microsoftの最新テクノロジーに関する情報を、ITリーダーとITプロフェッショナルなどを対象に提供するイベント
DSVM(Data Science Virtual Machine)
データ サイエンス仮想マシン | Microsoft Azure
搭載しているGPU
- NC
- NCv2
- ND⇒今回Igniteで発表
DNN modelsのトレーニング⇒スピードは最大21倍
Azure Machine Learning
Azure Mchine Learning Workbench
Mac,Winのデスクトップツール
SQL Server Linux版
Pythonのモジュールが使える
IoT Edge
クラウドとエッジのIoT
VS Code
満足度100％ ディープラーニングハンズオンで始めるAI ビジネス
AI人材セミナーを実施
- とにかく手を動かす
- 数学とプログラミング
実践的なカリキュラム
- 環境構築
- データの前処理
- 実装
ディープラーニングのビジネス活用の実際
発表者：ALBERT 上村さん
ビジネス活用事例の紹介
画像を解析して自動でタグ付け
- 大手アパレル会社
- レディース、メンズ、キッズなどを正しく認識させる
- 従来は手動でタグ付けしていたがDLで学習させて自動化
自動車メーカー向け物体認証
- 検出…歩行者、車両などを特定
- セグメンテーション問題…複数の車両を１つの塊ととらえるか個別にとらえるか
建物外壁の劣化度を判別
- 古い建物の劣化度合いを分析
- 天候による映像の違いを吸収
- ドローンを使って同じ位置から写真を撮って解析
細胞のクラス分類
- 細胞の正しい状態をクラス分類
- 家畜、畜産分野で元気な細胞の特定
- 血液中から特定の細胞の割合を抽出して病名を判定
獣医療の皮膚病判定
- VDT社と協業して犬の皮膚病をDLで学習し自動判定
- 症例の多い病名を抽出
- 画像データ…約2500枚
- 症例の個体…約260個体
- ペットの数は増えているがお医者さんの数が不足している⇒自動化で貢献
ビジネス応用支援
独自プロダクト
Gripper
- 自動ターゲティングサービス
- 商品の見た目の特徴、商品に付与されているテキストの特徴を学習
- 顧客が興味を持っているニュースも考慮
集英社のFLAG SHOPで活用⇒広告効率が1.6倍
PROAVTIVE AI
- Chat Bot接客ツール
- ユーザーへの回答を学習し自動応答
- ユーザーの行動を学習しチャット側から教えてあげる
渋谷区のOne to One子育て支援サービス
- LINEを使った自動応答サービス
- 問い合わせに24時間365日応答
いくつか質問をして好きなワインを教えてくれる
Deepsearch LOGO
- 自分たちと似ているロゴと似ているものはないか探す
- 特許庁に登録しているロゴから探す
DL以外の機械学習手法の活用
- 状態空間モデルを用いた異常部位検出
- Macnica社と提携しIoT分野で機械学習手法を活用
2017.07.04ALBERTとマクニカ、人工知能（AI）とIoTを駆使した スマートファクトリー事業で業務提携 | マクニカ
一般社団法人 日本ディープラーニング協会の取り組み
日本ディープラーニング協会 事務局長岡田さん
- DLを中心とする技術による日本の産業競争力の向上を目指す
- DLを第三次ブームで終わらせないように
- 10/4に設立発表したばかり
主な活動
- 活用促進
- 社会提言
- 人材育成
- 国際連携
- 理解促進
産業応用促進に期待されること
- ノウハウ不足⇒事例の共有
- 事業者不足⇒業界連携
- スケール不足⇒組織化
産業応用促進活動
- ハンドブック発行
- シンポジウム
- ワークショップ主催・公園
- マッチングイベント開催
- 学習の体系化
- 公的機関・産業への提言
人材育成
推薦図書
- AI白書
- 人工知能は人間を超えるか
- 深層学習
資格
http://www.jdla.org/business/certificate.html#education
G検定
- JDLA Deep Learning for GENERAL 2017
- 受験料12,960円
- 12/16開催
- 申し込み期間：11/17-12/9
- オンライン受験可能
E資格
- JDLA Deep Learning for ENGINEER 2018
- 来年4月
- 教習所のような形
ChainerMNが即座に使える環境を提供するXTREME DNA HPC Cloud
エクストリームデザイン株式会社 奥野さん
ChainerMN⇒9/1正式版リリース
Preferred Networks、民間企業の計算環境として 国内最大級のプライベート・スーパーコンピュータを9月から稼働 – Preferred Networks
XTREME DNA
DLの大きな壁
- お金
- 知識
- 時間
⇒XTREME DNA で分散環境の構築を自動化
DLの高い壁
誰でも気軽にスーパーコンピューターのリソースを活用できるように
- 並列処理こそがスパコンの得意分野
- テンプレートで構築・運用の自動化
- ChainerMNテンプレートも提供開始
AI時代の新しい教育 これから求められる人材像
株式会社UEI 清水さん
圧倒的な人材不足をどう補うか
- 大学の研究室の不足
- ディープラーニングが虐げられてきた時代があって研究室が少ない
- 大学の先生が深層学習を嫌い
- 教員の不足
- 学生が教えて欲しいと来ても先生が教えられない
- やりたい人はすごく多い
⇒本当は教えることは少ないし、数式はあまり必要ない
小中学生向けに人工知能のセミナー実施
⇒NNまでなら中学生にでもできた
深層学習は人工知能技術のいち分野
- 研究しづらい
- 論文書きづらい
- 特許取りづらい
アンサンブル学習⇒別々に複数学習させた結果を元に１つの結果を出す
深層学習に必要なのは学力ではなく経験とセンス
- レースゲームの強化学習
- 報酬の設計が大事
- あんまり数学使わない
- ネズミに芸を教えるのと変わらない
- 3D迷路の学習
- アルゴリズムとハイパーパラメータの組み合わせだけで膨大な数になる
- 最適解はやらないとわからない
- ハイパーパラメータは全探索（グリッドサーチ）しないと問題に対してどの組み合わせが最適なのか予測できない
経験とセンス⇒努力と根性が必要
⇒小さい組織でたくさん問題を解くほうがAIフレンドリーになれる
人工知能時代に決定的に大事なこと
データ＞＞＞アルゴリズム
計算資源＞＞＞アルゴリズム
データ＞＞＞＞＞＞＞計算資源
AIの性能を左右するデータをクラウドソーシングに頼るのは危険
これからの人材は個性・独創性のある子どものほうが貴重
⇒AIのある時代の理想的な生き方
⇒学校を学びの場から遊びの場に
深層学習よもやま話
www.slideshare.net
- AlphaGo Zero
- 強化学習で70時間後に人間を凌駕
- 40日の学習で最強に
- 音声によるロボットコントロール
- 茶色い人形を右の箱に移す
- 音声認識＆画像認識
- 6本足のロボット
- 歩行学習後に2本足を切り取る
- 6本足歩行の学習をするまでの学習結果をもとに2本の足が切り取られた状態に合わせたよい歩き方を考える
- GPU 1,024基搭載のスーパーコンピューター稼働
- Chainer V3／Cupy V2リリース
- 高階微分が可能
機械学習工学として体系化
- 再利用
- Neural Network Exchange Format(NNEF)
- KHRONOSグループが仕様検討中（１２月にパブリックベータ予定）
- Open Neural Network Exchange
- MS,Facebook
- このようなものが整備されてくれば再利用が進む
- Neural Network Exchange Format(NNEF)
- 品質の担保
- 新しいタイプの脆弱性
- STOP標識に黒と白のテープを貼ると40Kｍ制限の標識と見間違える
- DLはテストデータをうまく使って客観的に品質評価
- 新しいタイプの脆弱性
- 要求の厳密化
- 衝突のペナルティを無限大にすると車は動かない
- 効用と安全性のバランスを定量的に要件として書き出す必要がある
IJCAIにおける自律性に関する議論
- コーヒーを取ってきてと言うと列に並んでいる客を全員殺してコーヒーを取ってくる
⇒人の指示は不完全
機械学習とソフトウェア工学をどう結びつけるかの議論が盛り上がっている
深層学習の導入で抱える課題とユースケース実例
Ridge-i 柳原さん
NHKのモノクロ映像の彩色AI
AI導入の課題
相談検討開始⇒活用戦略⇒技術詳細⇒開発PoC⇒周辺開発、実業務にデプロイ⇒AI導入達成
あるべき姿
- この課題はAIなら解決できるのか
- インパクトは何か
- 必要なデータは何か
有りがちな問題
- とにかくAI入れたい
- 今あるデータから宝が見つからないか
⇒データが汚い状態でモデルを作ってもだめ
AIが意味することろは玉石混合
開発
- 汎用最強ではなくで課題毎に複数試す必要
- アンサンブル、ブースティングみたいに組み合わせも重要
ケース1：ビックデータ活用あるある
- データが不整形
- 教師データを抜き出すだけでも大変
- 入力データにモデル構築するのに必要な情報が入っていない
- 現状の誤った出力にモデルをあわせるという本末転倒な結果にも
いまあるデータに拘らない柔軟な姿勢
ケース２：多目的は無目的
- 白黒動画のカラー化⇒目的に特化すれば精度が上がる
- ビジネス要件を満たす条件の見極め
- 目的が定まれば技術の最適化が可能
ケース3：AIが理由を説明できないと問い合わせがあった時に困る
どのAI技術を使うのか見極めが重要
GPUディープラーニング最新情報
エヌビディア合同会社 佐々木さん
世代：Kepler⇒Maxwell⇒Pascal⇒Volta
Azureでは
NDはDeepLearningに特化している
Tesla V100
ChainerがどうすればTensorコアを使えるか
- Voltaが必要
- CUDA9,cuDNN7が必要
- モデルのFP16向けに書き換え
- ChainerとCuPyの最新のmasterブランチが必要
DGX Station
- パーソナルDGX
- Tesla V100 4基搭載
Deep Learning Institute
ハンズオントレーニング
QWIKLABS：クラウドベースのハンズオンラボ
エヌビディア DIGITS
自習ガイド公開
www.slideshare.net
PGU Technology Conf
DL ラボ コミュニティアップデート
日本マイクロソフト株式会社廣野さん
怒りのマネジメント
特集2 怒りのマネジメントが決め手 ”ブチ切れない” リーダー
チームを率いるリーダーとして怒りをコントロールするスキル＝「アンガーマネジメント」をしましょうという話。この特集ではアンガーマネジメント診断をしてリーダーとしてのタイプを把握することができる。試しにやってみたところ「自由人リーダータイプ」だった。この手の分析で自由人に分類された事は今までになかったけど、アンガーマネジメント的には分類のされ方が違うのかもしれない。怒りを持ったときに自由人で分かりにくく怒ってしまうタイプという事であれば、自分では気づきにくそうなので気をつけないといけない気がした。
とっさに役立つ実践的な10の対処法
怒りだけではないかもしれないが、仕事で感情的になってしまうことは誰にでもある。これら10の対処法を知っておけばどれか1つでもやってみて心を落ち着かせることができるかもしれない。
- 頭を真っ白にする
- 数を数える
- 今に釘付け（怒りから意識を逸して目の前の何かに集中）
- 怒りの温度を測る
- 落ち着く言葉を唱える
- 前向きな言葉を唱える
- 息を吐き切る
- その場を離れる
- 怒りをイメージ化する（頭の中で視覚化してみる）
- 24時間穏やかに振る舞う（徹底して穏やかに振る舞ってみる）
【勉強会メモ】関西Javaエンジニアの会(関ジャバ) '17 10月度
日時：2017/10/21(土) 13:30 〜 17:30
場所：エムオーテックス新大阪ビル 2F
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
今回のテーマは「現場で役立つシステム設計の原則」の著者である増田さんをゲストに迎えてのDDD特集。関ジャバですがScalaの話が多くてJavaの話は少なめ。Scala Kansai Summitのトートバッグを頂きました。
以前投稿済みだが「現場で役立つシステム設計の原則」は読んだものの、「理想はそうだがうまくいくのか？」という懐疑的な思いも若干あったが、パネルディスカッションを聞いてみると結局のところ、理論も大事だがどれだけ本気で向き合ってチームづくり、文化づくりができるかも重要だと感じた。その上で、DDDに向き合うためにしっかり書籍を読むなどで知識を得て自分の中に定着させておく事ももちろん重要。理論や仕組みや標準の言語仕様に依存するのが一番まずくて、それらを活用して何年もメンテして付き合っていくシステムを作るための状態を作ることが本質であると改めて感じた。
DDD失敗談を発表して学んだこと
@aa7th さん
とあるプロジェクトでDDDをやってみたがうまく行かなかった話
もらった意見とわかったこと
そもそもきれいにモデリングしたかったのかクリーンアーキテクチャで作りたかったのか？
⇒ごっちゃにしていた
モデリングには知識の噛み砕きのフェーズが必要
⇒クライアントとの話の詰め方が圧倒的に甘かった
※ICONIXプロセスというものもある
DDDは使用とコードじゃなくて頭の中のコードと一致させる
次に機会があれば実践したいこと
- DDDが向いているかどうか検討する
- DDDを実践する場合、本質を見誤らないように
- きれいな設計で作るためにDDDでやる
- 最初からきれいなものを作ることにこだわりすぎない
実践ScalaでDDD
DDDとは
オブジェクト指向で変更が容易なソフトウェアを開発するための体系化された原則集
参考書籍
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (131件) を見る
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
DDDのコンポーネント
※CQRSパターンを使う場合は下記も
- クエリモデル
- イベントサブスクライバ
- クエリプロセッサ
ScalaとDDDは相性がいい
- ドメインの仕様を自然に表現できる
- コードが自然分の仕様書になる
- オブジェクト指向と関数型
- 静的な型を持つオブジェクト指向＋関数型言語でもある
- case classで簡単に型が作れる
- 変数と関数の区別がない
- 関数（メソッド）をネストできる
Scalaの実装スタイル
- イミュータブルに作る
- 再代入不可にする
- 値を書き換えず、別インスタンスを作って返す
- 副作用を起こさない（局所化する）
- 副作用…戻り値として戻らないもの
- for内包式を使いこなす⇒ Scalaのfor文について考える - Qiita
- implicitパラメタを活用する
- case classのcopy()は外から使わない
- 変数はむやみに略さない
- Option型の変数はmaybeを付ける
- 自動コードフォーマッタを利用
アーキテクチャ
レイヤ構成
- ドメイン
- アプリケーション
- インフラストラクチャ
- インターフェース
レイヤ化アーキテクチャ
ドメイン中心アーキテクチャ
- ドメインから副作用排除
- アプリケーションはインフラストラクチャに依存したまま
オニオンアーキテクチャ
※参考
エラー処理
Scalaの値をラップする型
- Option
- Some or Noneのいずれか
- Either
- Right or Left⇒予測可能なエラー
- Try
- Success or Failure⇒予測不能なエラー
レイヤごとに発生するエラーの特性がある
ユーザー向けにはユーザーフレンドリーなエラーを返したいが、ドメインやインフラストラクチャでユーザーインターフェースを意識すべきではない
⇒上位レイヤでユーザーフレンドリーなエラーに変換する必要がある
コンポーネントの実装
アプリケーションサービスのコードが仕様書（ユースケース記述）になることを目指す
アプリケーション
- ドメインレイヤを使ってユースケースを実現することが責務
- ドメインの知識がアプリケーションサービスに漏れ出さないようにする
- インフラストラクチャレイヤに依存しない
- メソッドの処理の流れをfor内包式でつなげる
エンティティ
- 集約の中でエンティティは1つ
- プリミティブな型は使わない
- ドメインの振る舞いはエンティティのメソッドとして実装
バリューオブジェクト
- タイプエイリアスは型安全にならないのでちゃんと型を作る
- オブジェクトの集合はファーストクラスコレクションを作る（ListやSq,Mapをコレクション型のまま扱わない）
ロールオブジェクト
- 集約をまたいだエンティティとエンティティの関連をモデル化
- implicit classで定義することでエンティティを自動的にロールオブジェクトに変換
- エンティティの肥大化を防ぐ
ファクトリ
- エンティティの生成は2パターン
- 単独で生成⇒コンパニオンオブジェクトにファクトリメソッドを実装
- 他の集約のエンティティから生成⇒ロールオブジェクトにファクトリメソッドを実装
DDDの実践
さらにこの先にあるもの
- イベントソーシング
- アクターモデル⇒Akka Streamを使う
- DDDに正解はない
- MSAならコンテキストごとにサービスを分割して開発するので新しい学びを段階的に導入しやすい
各レイヤーからのエラーについて考える
エラーの分類
- ユーザーの操作起因
- システムの障害起因
ユーザーの操作
- 契約に違反するような操作
- 必須、長さ、型、重複
- 画面側で確認
- APIを直接呼び出すことを想定
システムの障害
- IO例外
- Network、System Down
- バグ
- ぬるぽ
- ユーザー操作…400番台
- システム障害…500番台
ドメイン駆動設計
ドメイン層のエラー
- 契約違反
- 必須
- 長さ、短さ
- 重複
- 型チェック
- DomainError型
- ドメインの永続化
- 再生成
- I/O例外をよく扱う
- 楽観的排他とNotFoundを型で表明
ファクトリはドメインと同じ
イベントパブリッシャ
- ドメインイベントのパブリッシュ
- 契約違反の検証は終わった状態
- I/O例外のみの考慮で良い
ドメインサービス
ドメイン層のエラー型
- DomainError型
- RepositoryError型
- 例外（Try）
インフラストラクチャ層
- リポジトリ実装
- ドメイン層の定義に従う
- RDB,KVS,AWS(Kinesis,SQS,S3)
- Java Library
- 例外をtry/catchしてConvert
- Libraryの依存型は閉じ込める
イベントパブリッシャ実装
- 例外をそのまま扱う
- 特別に型を定義して扱わない
インフラストラクチャサービス
- ドメインで表現する必要のないインフラ操作
- ファイルアップロードをテンポラリーに一時保存
- 暗号化／復号化
インフラストラクチャ層のエラー型
- RepositoryError型
- 例外
アプリケーション層
アプリケーションサービス
- ユースケース記述を書くように
- ユースケースとしてエラーを表明する
DomainError,RepositoryError,例外をConvert
ユースケースとしてのエラー表明
- NotFound
- Bad Request
- System Error
Convertを整理
- DomainError⇒ApplicationError
エラー型を表明したことでConvertが大変 全てApplicationErrorにする Convertをうまく実装しないと辛い
インターフェース
Application ErrorをConvertする
HTTPステータスに変換
- NotFound：404
- Bad Request：400
- Internal Server Error：500
HTTP以外のインターフェース
- Subscriber
- Reciever
- Command Line Interface
インターフェースに依存する
- インターフェースがHTTPならHTTPにする
- Sub/RecieverならSkipかRetry
isolating-the-domainの紹介
@haljik さん
Isolating the domainとは
エリック・エヴァンスのドメイン駆動設計における第２部第４章のタイトル
「ドメインを隔離する」をプロジェクトにしたもの
読むべきところ
設計ガイドのwiki
Home · system-sekkei/isolating-the-domain Wiki · GitHub
骨格となるパッケージに配置されたpackage-info.javaの記述
⇒いかにしてドメインを隔離しているか
骨格となるパッケージに配置されたpackage-info.javaの記述
いかにしてドメインを隔離しているのか
⇒ドメインで定義したインターフェースの実装をインフラストラクチャ層で実装しています
実際のプロジェクトではある程度の規模になるとほとんどの場合はマルチプロジェクト構成になる
参考資料
設計のスタイル、開発のスタイル -ドメイン駆動設計を実践するために、知っておきたい基礎知識
@masuda220 さん
本日のキーワード：型
- 言語に用意された型…boolean,int...
- Java標準ライブラリに用意された型…String,BigDecimal,...
- 独自に型を定義する仕組み…class,interface,enum,package
型
値の集合＋操作の集合
- boolean型
- true,falseの2つだけ
- 可能な操作は論理演算だけ（Javaの場合）
- LocalDate型
- 正しい日付
- 日付演算
プログラミングの2つのスタイル
- 型の利用者
- 言語の組み込み型を使う
- 標準ライブラリの型を使う
- 誰かが作ってくれたユーザ定義型を使う
- 型の生産者
- 基本データ型を使って独自の型を定義する
- 独自の型を組み合わせてさらに型を定義する
- 基本データ型への執着⇒諸悪の根源
- 長いメソッド
- 大きなクラス
- たくさんの引数
- コード重複
- 変更の分散
※リファクタリング 不吉な臭いより
オブジェクト指向良い習慣
- 基本型をラップして独自の型を定義する
- コレクションをラップして独自の型を定義する
基本データ型より独自の型が良い理由
- 正しさ
- 表現力
- Find Usage
正しさ
- 基本データ型
- 値の範囲が広い
- 可能な操作が汎用的
- 特定の目的のためには、間違った範囲、間違った操作を含んでいる
- ユーザー定義型
- 値の範囲を用途に合わせて制限する
- 可能な操作を用途に合わせて限定する
- 間違いが減る
- 安全・安心
表現力
- 基本データ型
- いろいろな用途に同じ型を使う
- 10種類ぐらいの単語（型）だけでなんでもかんでも説明されても意味がわからない
- ユーザー定義型
- 用途が具体的で明確な型が増える
- 引数の型、メソッドの型、シンプルなメソッド名
- 型をレビューすればコードの内容を推測できる（わかっているか、勘違いしているか）
⇒intelliJのdiagramで確認できるのは便利
Find Usage
- 修正や拡張をする時に、影響範囲を的確に判定できる
- 型はリファクタリング＝設計改善の最強ツール
ポリモーフィズム
良い単純化、良い部品化に役立つ仕組み（型を使ったポリモーフィズム）
⇒ポリモーフィズムが何かは基本的にはあまり重要ではない
-（暗黙的な）型変換
- long+int, "value:" + int
- int<->Integer
- オーバーロード
- BigDecimal(int), BigDecimal(String),BigDecimal(BigInteger),...
- 型変換の責任を使う側から使われるクラスに移動する
- 型のパラメータ化（ジェネリクス）
- List
型の使い方について
- どの仕組みもとても便利
- しかし誤った使い方は事故の元
- 上手に使うのが設計の腕の見せどころ
設計のスタイル
- モジュール化
- 型（データ＋操作）に分解するか
- 手続き（サブルーチン）に分解するか
- 独自の型
- 積極的に独自の型を定義するかできるだけ基本データ型でがんばるか
- 型の記述
- 明示的に書くか、型推論に頼るか、暗黙化か（型を書かない・型を書けない）
- 型の検査
- 設計中（IDE）、実行前（静的）、実行時（動的）
ドメイン駆動設計の開発スタイル
- ドメイン（問題領域）に特化した型の探求活動
- 良い型は最初からは見つからない
- 実験的に探求する
良い型は最初からは見つからない
- 問題領域の知識が不足している
- 問題領域を深く分析できない
- 型でビジネスロジックを表現する設計パターンの知識不足／経験不足
- 初期の型の使い勝手の悪さ⇒ソフトウエアはだいたいそう
- 型の成長性（変更容易性）⇒使っていく中で成長させる
実験的に探求し進化させる
- 型のアイデアの発見
- 雑談、ラフスケッチ⇒これがきっかけになることが多い
- 型のアイデアをコードで書いてみて試してみる⇒考えただけでは仕方ない
- だめなら捨てる
- いけそうなら改善を続ける
- もやもやしたら別のアイデアを試してみる⇒何が正解かはわからないけどよくなさそうだと感じることは多い
- 新たな発見 and/or 元のアイデアの再評価
- 小さなステップの繰り返し
- アイデア出し、実験、改善にdoneはない
- タイムボックスで先に進む⇒自分で時間を決める、延長しない（あと少し考えてみたらできそうというのは罠）
⇒最初から見積もりやここまでできそうという話をするならある程度実験してみる作業を見込んでおく。
ドメイン（問題領域）に特化したユーザー定義型の見つけ方
ドメインに特化したユーザー定義型
- 汎用の基本型の用途を限定
- 値の範囲
- メソッドの型
- メソッドの名前
↑これが一番最初にやることで最も重要
型の振る舞いの設計パターン
- 判定（同値、大小、最大／最小）
- 加工（型変換、短縮形、合成）
- 計算（四則演算）
↑どういう振る舞いがあるか実験してみる
既存のアイデアの流用／カスタマイズ
- 分析パターン⇒これはずっと後
- 過去に経験したシステムの設計内容
- データモデリングのカタログ
↑有名な本、モデリングなどを使う
ユビキタス言語
- 業務の用語
- 画面
- 業務マニュアル
↑ユビキタス言語を使えば良い設計ができるわけではない
型
参考
Java SE Specifications 4.2と2.10
⇒1章の無料サンプルがとても良い
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)
- 作者: バートランド・メイヤー,酒匂寛
- 出版社/メーカー: 翔泳社
- 発売日: 2007/01/10
- メディア: 単行本（ソフトカバー）
- 購入: 11人 クリック: 307回
- この商品を含むブログ (131件) を見る
パネルディスカッション
Q： 知識がない人がいる中でどうやって広めるか
- システムを作る目的はあるはず⇒そこから想像する
- 具体的に想像できるようになると話がしやすいかも
- 口頭だけで伝えるとわからなくなる
- 書いてもらうと伝わるようになる
- 言葉が実際の動きと合ってないこともある（クライアントがうまく言語化できていない）
- 実際に動いているものを見てもらう
- 法律が絡む場合は法律を知る（制約があるケース）
- 紙に図を書いてみる。
- 設計だけ先にしないといけない場合は辛いかも
- 概念レベルのクラス図、ユースケース図ぐらいなら作れるかも
- 繰り返しの発見のプロセスがあるので気づいたことをお互いに言える環境が重要
Q：どういうふうにDDDにたどり着いたか
- 大炎上プロジェクトに入った
- 3000行のSQL
- マルチクライアントで複数の会社に提供
- A社の画面がB社に見える
- アーキテクチャやモデルを参考に
- 効果があったのはリファクタリング⇒即効性があった
- そこから本を読んだ
- オブジェクト指向は嫌いだったが必要性を感じ始めた
- 手続き型に戻ることはなかった
- 炎上していたので何をしても自由だった
- 設計を変えていくのが楽しかった
- 技術力やパフォーマンスの発揮で解決できる面もある
- 画面ドリブンで設計してはダメ
- モデルから設計したほうがいいと思ってたまたまDDD本を読んだ
Q：どういうところに取り入れるか
- インフラストラクチャ寄り
- パフォーマンスを要求されていないところ
- バックオフィスを考えると複雑になるケースはある
- 問題領域を区別してプログラムに反映するという意味では向いていない領域はない
- 実装上は向かないことはあるかも
Q：DDDと負債化
- ボーイスカウトルールしかないかも
- Scalaで置き換えたが10年戦える仕組みを手に入れたかというと不安
- 2,3年なら思想や文化を知っているメンバーがいる
- 思想や文化は重要
- 自分が抜けた時にどうなるかは不明で不安がある
- 納品した後でお客さんが触り始めるとぐちゃぐちゃになるかも
- 10年の長いスパンで考えたときにソースコード自体よりもソースコードから読み取れる知識が重要
- Scalaって10年後にコミュニティ大丈夫か？
- コミュニティ含めて支えられると判断する
- チームづくり⇒文化が残るようなチームにすることを重要視している
- 自分が抜けるにはどうしたらいいか考える
- スキルが無い人に渡してもうまくいくというのは無理がある⇒渡せるチームづくりが先
Q：テーブルの再設計ができない場合はどうするか
- DDDで言うとインフラストラクチャが複雑になる
- ドメインモデルへのConvertが複雑になる
- テーブルとの結合度が複雑なフレームワークを使わなくする
- リード用のテーブルを用意する
- 名前がflagなのに区分になっている⇒テーブルを変えるの大変なのでモデリングでなんとかする
- リポジトリパターンの中に隠す
- データベースのリファクタリングも考える
- ロギングのような形で今のテーブル設計とは別で操作を記録する新しい設計のテーブルに入れる
- テーブルをビューで名前を変える
- 最終的にテーブルを変えれない、しょうがない事はあるかもしれないがマインド的にはリファクタリングする方向で動く
- 頑張ろうとした形跡はあるけどメンバーが変わって途中で止まる⇒ 負債ではなく財産ととらえる
Q：短期的な視点と長期的な視点のバランスについて
- モデルの構造を変えざるを得ないことも起こる
- ある程度長期的な視点で設計しておかないと破綻することがある
- バリューオブジェクトの負債化
- DDDじゃなくても時間がかかるかも
- DDDのほうが発見しやすくなる
- 100個中100個が全てだめになるというようなことは経験上ない
- 組み換え可能な設計にしておく
- 独立したものをどれだけ小さくできるかが重要
Q：DDDの失敗談
- きれいにやろうとしすぎた
- お客さんがちゃんと見てくれていなかった
- 開発後半になって色々言われた
- ある程度作るまでフィードバックがもらえなかったのはなぜ？
- アナログなツールに頼ったほうがよかったかも
- もっと一緒にやる姿勢を見せる
- DDDも設計の外側のコミュニケーションが重要
- どうやって話をするか認識を揃えるか
- 1回作ったコードは二度と触るなみたいな文化もダメ
- 日本語も英語も両方使えるようにする
Q：メンバーがDDDへの関心が薄い場合はどうするか
【勉強会メモ】【京都開催】LINE Developer Meetup in Kyoto #21
日時：2017/10/20(金) 19:00 〜 21:15
場所：京都烏丸コンベンションホール
2018年に京都に新たな開発拠点を設立するとのことで、それ向けたキックオフ的な開発者向けイベント。開発者向けとはいえ参加者の半分くらいは学生だったので、そういう意味合いが強そうな印象。現時点で何も構えていない土地にこれから乗り込んでくる中で初めて開催したイベントに100人以上の人を集める影響力はさすがとしか言いようがない。イベントの中で京都オフィスでClova開発チームを立ち上げることが決定したとの発表もあり、力の入れようが感じられた。
セッションの内容はClovaと機械学習についての二本立てで、学生も多かったため難しい内容ではなかったが、注力している分野だけあって経験に基づく知見は込められていたように思う。
AIプラットホームClovaについて／taiichiさん
Clova と近々発売されるnewデバイスの紹介。既に発表されているCHAMPなどが紹介された。
Clovaアーキテクチャ
⇒全て自社で開発
プラットフォーム開発
Clova Interface Connect(CIC)
Clovaを利用できるデバイスやアプリを開発するためのSDKやAPI
Clova Extension Kit(CEK)
自分たちがClovaに新しいサービスを提供できる
課題
音声認識の難しさ
- 音声認識間違い
- 読み上げ間違い
言語処理の難しさ
- 言語理解の間違い
- 正しい応答って何？
- こんにちわ？こんばんわ？
- コンテンツは無限
Skills
- 音楽、天気、チャットなど
- 来週リリース：ラジオなど
- 近日リリース：カレンダー、リモコン、LINEなど
機械学習を始めるための第一歩／tkengoさん
機械学習のイメージ…数学が必須、難しいなど
⇒というイメージをいったん捨てる
まずは理解できる楽しさを知ろう
機械学習を理解する
すごいけどなんでもできるわけではない
パターン（ルール）の発見
例） 広告費が増えれば増えるほどクリック数も増える ⇒関係性を考える y=ax+b パターンからの予測 a=100でb=1000だったら… aがいくつの時bがいくつになるという未知の状態を予測する
機械学習の本質
パターン（ルール）の発見
パターン＝未知のパラメータ を見つけていく
- データから探していく
- 発見したパラメータを使って将来を予測
⇒ これがイメージできるようになることが大事
未知のパラメータを理解する手法を理解するために数学の知識が必要
理論を理解する
やさしく学ぶ 機械学習を理解するための数学のきほん
やさしく学ぶ 機械学習を理解するための数学のきほん ~アヤノ&ミオと一緒に学ぶ 機械学習の理論と数学、実装まで~
- 作者: LINE Fukuoka株式会社立石賢吾
- 出版社/メーカー: マイナビ出版
- 発売日: 2017/09/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
※発表されたtkengoさんの著書
実装までの道のり
- 理論を理解する
- 理論を理解した次のステップでアイデア
- 理論と実装のギャップ
理論と実装のギャップ
- 実際は勾配法や正規化の実装などしない⇒既に先人たちが実装している
- データ前処理⇒だいたい一発ではうまくいかない（データマエショリストとう言葉もある）
- アルゴリズム、素性、ハイパーパラメータの選定が重要
⇒実際は実験と改善の繰り返し
- いろんなものを試して、試行錯誤をして進めていく
- アプリ開発をするようにやってみて手を動かして理解することも多い
座学だけでなんとかなるほど甘くない
手を動かしていくうちにわからないことが出てきてまた調べる
まとめ
- 理解できる楽しさを知る
- 実装できる楽しさを知る
プログラミングのはじめたてのころを思い出してみる
- 仕組みを理解できた頃の楽しさ
- プログラムが動いた時の楽しさ
- 勉強を継続できたモチベーション
⇒ 環境は既に整っている
理論と実装はどっちも大事
