JJUG CCC 2016 Fallに参加してきました。
以下自分用のメモです。
概要
JJUG CCCは、春と秋に開催される日本最大のJavaコミュニティイベント。Java関連の技術や事例に関するセッションが行われる。
- 主催: 日本Javaユーザーグループ
- 日程: 2016/12/3(土) 10:00~19:30 (開場 9:30)
- 場所: ベルサール新宿グランド コンファレンスセンター
- 参加費: 無料
- ハッシュタグ: #jjug_ccc (セッションごとにハッシュタグあり)
以下各セッションの内容
新人研修や本では教えてくれないJava! ~フレームワークの仕組みと業務必須ツールを学ぼう~
カサレアル 多田真敏 氏
- 新人研修で教えるJava、教えないJava
- そもそもJavaは学習量が多い
- ライブラリを簡単に使おう!ビルドツールMaven
- Javaはオープンソースが充実
- ライブラリの依存関係を解決するためにMaven
- Mavenは現在では、Javaビルドツールのデファクトスタンダード
- Maven Central Repositoryにほとんどのオープンソースライブラリが集まっている
- pom.xmlのdependencyは、Maven Central Repositoryで検索してコピペする
- Mavenプロジェクトのフォルダ構造が決まっている
- Web三種の神器!Webフレームワーク・DIコンテナ・O/Rマッパー
- Servlet・JSPの問題点
- M・V・Cが混在する場合がある
- サーブレットの単体テストが困難
- JDBCはDBアクセスのコードがボイラープレートコードだらけになりやすい
- Webフレームワーク
- フレームワーク内のフロントコントローラが各コントローラへ振り分けている
- ビュー
- 最近ではThymeleafが人気
- JSFではすでにJSPが非推奨
- セキュリティ的にもJSPは敬遠される
- O/Rマッパー
- 代表例: JPA, Hibernate
- 開発者から見えない部分も多くハマりどころも多い
- 一般的に正規化されてないDBには向かないとされている
- DIコンテナ
- DIの何が嬉しいか?
- 単体テストがやりやすくなる
- DIを使ってない場合利用する実装クラスを切り替えるのは困難
- DIの何が嬉しいか?
- Servlet・JSPの問題点
- サーブレットとフレームワークの仕組みを知ろう
- WebフレームワークやDIコンテナ、O/Rマッパーはリフレクションをフル活用している
- アノテーションも重要な要素
- ロギングライブラリLogback
- トラブル時にはログが唯一の頼りになる
- なぜロギングライブラリを使うのか?
- ログレベルを設定できる
- 統一したフォーマットを指定できる
- ファイルへの出力や別サーバへの転送などができる
- これからどう学習するか?
- 市販書籍をしっかり勉強する
- 資格を目標にする
- 「Javaフレームワーク開発入門」
- JJUGナイトセミナーに行きましょう
SpringはどうやってDIしているのか?
ファームノート かりや 氏
ファームノートとJava
- 酪農・畜産の牛群管理
SpringのDIのステップ
- Bean定義の登録
- コンポーネントスキャン
- Bean生成(+コンストラクタインジェクション)
コンポーネントスキャン
- classファイルをかき集めた後に、classファイルのバイトコードを解析している
コンストラクタインジェクション
- ConstructorResolver
ふりかえり
- DIにアレコレをやるのに必要なのはBeanFactoryとBeanDefinitionReader
- DefaultListabeBeanFactoryの仕事多すぎ。継承が複雑。
日本でも出来る!最先端のDevOpsを導入する方法
日本マイクロソフト 牛尾剛 氏
- 日本でも本当に最先端のDevOpsg実現できる可能性を実感してもらいたい
- 日本はUSの5年遅れ、8年遅れという海外からの意見あり
- ざっとわかるDevOps
- DevOpsは明確な定義がない
- マイクロソフトの定義
- 人・プロセス・プロダクトの集合体で継続的にエンドユーザに価値を提供すること
- 10デプロイ/day も可能に
- MicroserviceはDevOpsが出来てなければ実現できないはず
- DevOpsのメリット
- コードのデプロイ速度 30倍
- リードタイム 1/200
- エラー 1/60
- エラーからの復旧 168倍
- 標準的なDevOpsのビュー
- リードタイムの短縮
- 本番環境 / ユーザからのフィードバック
- 本番環境は聖域ではない
- Test in production
- 継続駅な実験と学び
- マイクロソフトのチーム構成
- Dev + QA = エンジニアリングチーム
- エンジニアリング + Ops + ビジネス企画 = サービスチーム(Feature team)
- サービスチームに強い権限が渡されている
- 顧客との直接のコラボレーショ
- 日本向け DevOps 導入ステップ
- DevOps プレゼンテーション&デモ
- Value Stream Mapping
- 文化とギャップ要素のインストール
- DevOpsハックフェスト
- モニタリングと継続的改善
- Value Stream Mapping
- リードタイムに関係するプロセスの可視化と共有、課題の共有
- 上位マネージメント・関係者の巻き込み
- 文化とギャップ要素のインストール
- 文化の違いによるAgile導入何度
- Agile/DevOpsの日本導入はそのままでは難しい
- DevOpsは西洋文化の上に成り立っている⇒文化をインストールすればよい
- インターナショナルチームの生産性の秘密
- 物量が違う(やる仕事が少ない。人間の能力の差ではない)
- Be Lazy
- より少ない時間で成果を最大化する(「エッセンシャル思考」)
- 何を捨てるべきかを常に考えている
- Just do it!
- 日本人は準備しすぎている
- 自分が知っているか知らないかは重要ではない、その場で以下にValuwを出すかが重要
- 文化の違いによるAgile導入何度
- イケてるベンダ / アジャイルコーチの選定
- 定期的にリードタイム等の改善状況を共有する
GitBucketを支えるJava技術とグローバルで使われるOSSの作り方
ビズリーチ 竹添直樹 氏
- GitBucketの紹介
- Scalaで実装されたOSSのGitサーバ
- Gitbucketの開発
- 必ず月1回リリース
- 使用しているフレームワークの開発にも積極的に関与している
- GitHub社から警告のメールが来た
- GitHubが使えない人たちのためのプロダクト
- 改善のプランを提示
- 技術スタック
- JGit
- Slick
- タイプセーフなクエリDSL
- Jetty
- Apache MINA SSHD
- Scalatra
- Twirl
- タイプセーフなテンプレートエンジン
- Scalaの特徴
- Javaよりも強力な型安全性
- スクリプト言語のような柔軟性
- 既存の膨大なJavaの資産を利用可能
- 最新のScala2.12ではJava8のサポートも強化
- Scalaが少人数での開発を支えている
- 大規模なコードでも型によるチェックで修正漏れを防ぐことができる
- Javaでは複雑な生SQLやHTMLテンプレートなどにおいて型安全性を活かせない
- Scalaはコンパイルが遅いが、GitBuckeにおいてはそれ以上に圧倒的にメリットがある
- 既存のJava資産を使えるのは大きい
- プラグインシステム
- Scalaで記述できる
- 様々な拡張ポイントを利用可能
- OSSの成長に必要なもの
- OSSの成長に必要なもの
- ユーザ
- 開発者
- コミュニティ
- エコシステム
- GitBucket
- 全て英語でやっている
- GitHubによるところが大きい
- ASFで感じたこと
- メリット
- リーガル面でのサポート
- デメリット
- 官僚的なルール、レガシーな開発インフラ
- 協力者の敷居が高く、開発速度も遅くなってしまう
- メリット
- GitHubによってもたらされたもの
- 使いやすく必要最低限の機能
- 自然とコミュニティの構築が促進される
- ソフトウェアとして大事なこと
- 継続性
- 自分が必要しているものを作る
- 自分が使い続ける限り開発が継続される
- 開発コミュニティを作る
- 拡張性
- コアを小さく保つことでメンテナンスコストを下げる
- 開発者のコミュニティ、さらにエコシステムの構築を促進できる
- 継続性
- 最も大事なのは英語でやること
- すべてを英語で行う
- UI,ドキュメント,ブログ,GitHubでのやりとり
- すべてを英語で行う
- GitHubのテンプレート機能を活用
- OSSでワンチャンありますか?
- なくはない
- ただし必ずしも「ユーザの数」が全てではない
- 特定のコミュニティ内での知名度が重要
- OSSの成長に必要なもの
- 今後の展望
- コアを小さくシンプルに保つ
- プラグイン開発の促進
- プラグインの開発がScalaに触れるきっかけになってほしい
- 技術的な課題
- パフォーマンス、スケーラビリティ
- フロントエンド技術のレガシー化
Clojureを用いたWebアプリケーション開発
サイボウズスタートアップス あやぴー 氏
- 普通のベンチャー企業がなぜColjureを選んだのか?
- 良いサービスを世の中に提供したい ⇒ 優秀なエンジニアが必要 ⇒ ブランドの構築が必要 ⇒ 技術マーケティングの必要性
- 条件
- すぐに廃れないこと
- エンジニアが成長できるテーマであること
- ニッチでも良い(大量の採用は必要ない)
- 安否確認サービスについて
- 企業向けのシステム
- 緊急時に高い可用性が求められる
- 外部サービスと連携している
- どちらかといえば堅いサービス
- Clojureでリプレース
- Closureを採用してよかったところ
- シンプルさ
- 不変性
- オブジェクトは不変
- 関数呼び出しで引数を変更される恐れがない
- デフォルトでミュータブルなのは早すぎる最適化
- Java資産の活用
- Clojureを呼び出すように自然にJavaを呼び出せる
- Server/Clientを同一言語で
- コンテキストスイッチがなくなる
- プラットフォームに依存するようなコードがあってもも共通化できる
- 拡張性の高さ
- ライブラリに拡張ポイントが残されている
- Protocols / Multimethods
- 既存のJavaクラスも拡張できる
- 高い後方互換性
- バージョン上げても、ほとんど影響がない
- 関数の名前が衝突することは稀にある
- 古いライブラリでもたいてい問題なく動作する
- Clojureは互換性を大事にした設計になっている
- 組み合わせの容易性
- 少ないデータ型に対して大量の関数がある
- 個々のライブラリは独立している
- 特定のフレームワークを前提に設計されていない
- and more
- 覚えることが少ないのにパワフル
- 単純なマップやベクタを渡せばいいのでテストが容易
- Nil PunningによってNPEをある程度回避できる
- Clojureを利用して苦労したこと
- 大きなアプリの作り方が分からなかった
- フレームワークがなかった
- スタックトレースが難しかった
- Jar地獄に陥った(フレームワーク使わない分ライブラリの依存関係で苦労した)
- なんだかんだでJavaの知識が欲しくなる
- 日本のコミュニティが小さかった
- 日本語の情報が少なかった
- まとめ
- Clojureを選んだのは良いサービスを作るため
- シンプルさは選ばないと手に入らない
- Clojureを使っても立派なWebアプリは作れる
Javaでつくる低レイテンシ実装の技巧 ~GCはさだめ、さだめは死~
山崎良祐 氏 (@nappa)
- レイテンシとは
- パフォーマンスの評価基準
- スループット
- 単位時間あたりの処理能力
- レイテンシ
- 要求してから結果が返ってくるまで
- 人間に例えると・・わんこそば1杯を食べるのに必要な時間
- スループット
- パフォーマンスの評価基準
- レイテンシが非常に重要なアプリ
- 医療系
- 宇宙系
- 時間内にタスクが終了しないとタスク処理結果の価値がなくなる
- レイテンシがわりと重要なアプリ
- LINEのメッセージ
- ゲーム
- バナー広告の配信
- 時間内にタスクが終了しないとタスク処理結果の価値が減少する
- ネット広告のオークション
- 広告枠のオークション開始からオークションの終了まで100ミリ秒以内
- 電気信号の速度=高速の6割
- 東京からネットワークレイテンシ
- 東京~台湾:65ミリ秒
- ハードウェア的な制約
- HDD遅い
- コードを最適化しよう
- 「Javaパフォーマンス」を読もう
- 速すぎる最適化は悪
- とりあえずJava Filght Recoder
- 負荷をかけて測定
- なるべく本番に近い負荷をかける
- しばらく放置して十分にJIT Compileさせる
- perf
- Linux向けのプロフィラ
- キャッシュミスの発生している箇所を特定できる
- flame graph
- Javaの問題かLinuxのカーネルの問題か切り分けできるようになる
- 正規表現で検索できる
- メモリはすごく遅い
- メモリアクセスが多いと計算ユニットが空回りする=CPU使用率100%でも遊んでいる場合あり
- メモリアクセスは64バイト。隣接するデータも一緒にとってくる
- IPC
- 1を割っているなら改善できるはず
- HashMap#getはL2キャッシュミス発生源
- Eclipse Collectionsを使うことで解決
- GCの悪影響をなんとかしよう
- G1GCしかない
- Java Flight Recoder
- GCLocker Initialted GC
- 見かけたら要注意
- JVMがクラッシュ
- 見かけたら要注意
- モニタリング
- GCログを監視
- HTTPレスポンスのパーセンタイル値を監視
個人的に最も面白かったセッションでした
Featherweight Javaの漸進的型付け と Groovyの紹介
@kyon_mm 氏
- 単語の整理
- Featherweight Java(FJ)
- Java言語のコアとなりそうな部分を抜き出して形式化したもの(型付け規則や操作的意味論)
- FJがあることによって、机上で言語拡張の実験をしやすくなるメリットがある
- Genericsには対応していない
- Genericsに対応したFeatherweightGenericJava(FGJ)というのもある
- 漸進的型付け(Gradual Typing)
- 静的型付き、動的型付きのいいところを両立させるための仕組み
- Groovy
- 漸進的型付けをある程度実装できているプログラミング言語
- Featherweight Java(FJ)
- 論文の概要
- 漸進的型付けをFJに導入したFJ?を定義した
- ?型
- ワイルドカード的な扱い
- Objectとは違って、?型で宣言されている部分は実行時に型検査される
- 実行時の?型
- 実行時にはリフレクションを用いて評価する
- FJ構文
- クラステーブルCTと項eの組からなる
- CTはクラス名とクラス定義への写像でObjectだけは含まない。
- Groovy:漸進的型付け
- 基本は動的型検査、メソッド、クラス、コンストラクタにアノテーションをつけて静的型検査を指定する
- @CompileStatic/@TypeCheck
- @CompileStatic/@TypeCheckアノテーションを使うことで静的型検査を行える
- @TypeCheckは静的型検査をするだけ
- @CompileStaticは静的型検査して、動的型検査が不要なようにコードを変更する
その他セッションの資料は以下を参照ください