読者です 読者をやめる 読者になる 読者になる

覚えたら書く

IT関係のデベロッパとして日々覚えたことを書き残したいです。 twitter: @yyoshikaw

JJUG CCC 2016 Fall 行ってきた #jjug_ccc

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を使ってない場合利用する実装クラスを切り替えるのは困難
  • サーブレットとフレームワークの仕組みを知ろう
    • 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 導入ステップ
    1. DevOps プレゼンテーション&デモ
    2. Value Stream Mapping
    3. 文化とギャップ要素のインストール
    4. DevOpsハックフェスト
    5. モニタリングと継続的改善
  • Value Stream Mapping
    • リードタイムに関係するプロセスの可視化と共有、課題の共有
    • 上位マネージメント・関係者の巻き込み
  • 文化とギャップ要素のインストール
    • 文化の違いによるAgile導入何度
      • Agile/DevOpsの日本導入はそのままでは難しい
    • DevOpsは西洋文化の上に成り立っている⇒文化をインストールすればよい
    • インターナショナルチームの生産性の秘密
      • 物量が違う(やる仕事が少ない。人間の能力の差ではない)
    • Be Lazy
      • より少ない時間で成果を最大化する(「エッセンシャル思考」)
      • 何を捨てるべきかを常に考えている
    • Just do it!
      • 日本人は準備しすぎている
      • 自分が知っているか知らないかは重要ではない、その場で以下にValuwを出すかが重要
  • イケてるベンダ / アジャイルコーチの選定
  • 定期的にリードタイム等の改善状況を共有する


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でワンチャンありますか?
      • なくはない
      • ただし必ずしも「ユーザの数」が全てではない
        • 特定のコミュニティ内での知名度が重要
  • 今後の展望
    • コアを小さくシンプルに保つ
    • プラグイン開発の促進
      • プラグインの開発が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
      • 漸進的型付けをある程度実装できているプログラミング言語
  • 論文の概要
    • 漸進的型付けをFJに導入したFJ?を定義した
    • ?型
      • ワイルドカード的な扱い
      • Objectとは違って、?型で宣言されている部分は実行時に型検査される
    • 実行時の?型
      • 実行時にはリフレクションを用いて評価する
    • FJ構文
      • クラステーブルCTと項eの組からなる
      • CTはクラス名とクラス定義への写像でObjectだけは含まない。
  • Groovy:漸進的型付け
    • 基本は動的型検査、メソッド、クラス、コンストラクタにアノテーションをつけて静的型検査を指定する
    • @CompileStatic/@TypeCheck
      • @CompileStatic/@TypeCheckアノテーションを使うことで静的型検査を行える
      • @TypeCheckは静的型検査をするだけ
      • @CompileStaticは静的型検査して、動的型検査が不要なようにコードを変更する



その他セッションの資料は以下を参照ください