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

「JJUG CCC 2016 Fall」へ行った その2

セミナー参加レポート

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

その1はこちら ttomioka.hatenablog.com

F-3 メンバーのスキルアップ、どうしてる? -Java 100本ノックで新加入メンバーを鍛えてみた- 福嶋航(株式会社ジャストシステム)

資料: http://www.slideshare.net/JSUXDesign/java-100

  • Java100本ノックを用いたトレーニング事例
    • トレーニング内容
      • 毎日Pull Requestしてもらってそれをレビュー
        • 力を付けるにはレビューが大事
        • 1行ずつ、1文字ずつに意味がある
        • ほっておいても伸びない
        • 調べてわかったつもりになるだけでなく、なんでこうなるのかを理解する
        • オンデマンドで相談に乗る
      • レビューで鍛える
        • レビューの場はスキルアップの場
        • 指摘だけでは無く、よくできたところを伝える
          • 悪いところは違和感があるから発見しやすい
          • 良いところは違和感なく過ぎてしまうから発見が難しい
  • ソフトウェア開発アンチパターン7つ
    • シャイ・メッセージ
      • ログにメッセージを書かない
        • 例外をスローするときは何がおきたかをメッセージに入れる
        • ログ出力時にどこで何の処理ができなかったかを記述する
    • リ・インベンティング・ザ・ホイール
      • ムダな独自ロジック
        • 標準SDKやよく使われているライブラリを使用する
    • リーゾンレス・トラスト
      • nullチェックしない(実は、現場でおきている例外で一番多いのがNullPointerExceptionでは)
        • nullチェックする
    • デコイ・コード
      • ソースコードのコピペ
        • コードが重複しないように工夫する
        • リファクタリング前にテストコードを書いてデグレ防止対策する必要がある
    • ナム・トゥ・イエロー
      • 警告無視
        • コンパイラが出す警告は全て解消する
    • エングリッシュ
      • 奇妙な英語
        • 便利なサイトを利用する
        • ATOK F4
    • ミミック
      • おかしいコードの増殖
      • あなたが書いたコードはコピペであってもあなたのモノですから

AB-4 Spring CloudでDDD的なマイクロサービス作ってみる 椎葉 光行

資料: http://bufferings.hatenablog.com/entry/2016/12/04/135752

  • 境界づけられたコンテキスト
    • レイヤーをしっかり作っても4-5年経つとうまくいかない
    • データモデルがだんだんと大きくなっていって手が付けられなくなる
    • 境界の中だけでAPIだけのやり取りでやろうとしたらうまくできた
  • ユビキタス言語
    • 話した言葉がそのままコードになっている
    • 違和感があれば気づけるようになる

GH-5 クラウド、クラウドというけれどJavaのシステムにとってクラウドってメリットあるの?

資料: TBD

  • 日本のJavaクラウドは普及していない
  • 二つの文化に分かれる日本のIT企業
  • SIでよく使われるのはJava
  • クラウドのメリット色々
  • システムがクラウドに対応しなければならない
  • JavaEEシステムのクラウド化が困難な理由
  • アプリケーションサーバー
  • アプリケーションのクラウド化
  • バックエンド対応

「JJUG CCC 2016 Fall」へ行った その1

セミナー参加レポート

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

その2はこちら ttomioka.hatenablog.com

F-1 新人研修や本では教えてくれない Java!〜フレームワークの仕組みと実 務必須ツールを学ぼう〜 多田真敏

資料: https://speakerdeck.com/masatoshitada/wan-quan-ban-xin-ren-yan-xiu-yaben-dehajiao-etekurenaijava

  • 新人研修で教えるJava、教えないJava
    • Java SE 5以降の新機能をほとんど教えない
    • カリキュラムが15年ぐらい変わってないのでは
    • そもそもJavaは量が多い
      • 1-3ヶ月の新人研修で全部は教えきれない
      • 研修以上の自己学習が必須
      • 良書は多いので自己学習は可能
  • Maven
    • Javaオープンソースのライブラリが充実しているが、管理上の問題は多い
      • どうやってそれらのライブラリを集めるか
      • 依存性の管理
      • バージョンアップへの対応
    • それを解決してくれるMaven
      • XMLに必要なライブラリを書くだけ
      • Maven CentralからXML指定されたモノをダウンロードしてくれる
      • 公式サイトにいちいち行かなくていい
      • Javaの開発におけるデファクトスタンダード
    • Mavenでおさえておくこと
      • IDEにMavenが内包されているが、コマンドから使うことも多いので個別インストールすべき
      • pom.xmlの編集
      • Mavenプロジェクトのフォルダ構造は超重要
  • Webフレームワーク・DIコンテナ・ORマッパー
    • サーブレット・JSP・JDBCには問題がある
      • MVCを混在させることができてしまう
        • サーブレットにビューが書ける
        • JSPにロジックをかける
      • サーブレットの単体テストが困難
      • JDBCは似たようなコードを毎回書くことになりやすい
    • そこで3種の神器をを使う
      • Webフレームワーク
        • Spring MVC or JSFあたりがデファクトスタンダード
        • JSPは避けたい
          • セキュリティ的にもJSPは敬遠される
  • リフレクションとアノテーション
    • リフレクションを知っている必要はある
    • アノテーションとリフレクションは合わせて使われている
  • ロギングライブラリLogback
    • ログを新人研修でほとんどやらない
    • トラブル時はログが頼り
    • Logbackが 一番メジャー
  • これからどう学習するのか
    • 本による勉強が必要
      • 新人研修は期間が限られるので全てを扱うのは無理
    • 資格を目標にするのもいい
    • ブログ、スライド、勉強会も

GH-2 SIerもはじめる わたしたちのDevOps しょぼちむ / 阿佐志保

  • しょぼちむさん
    • 資料: http://www.slideshare.net/syobochim/sier-devops-jjugccc-69780604
    • SIerでもDebOpsは必要
    • ビジネスを加速するためにリードタイムを短くするしたい
    • 事例
      • アプリケーションの使用状況を収集してレポーティング
        • Kibanaでユーザーの行動を可視化
          • これで問題が見えてくる
        • エラー率から使い方を改善する
        • 仮説に合わせてログ収集の仕組み自体も変更
    • リードタイムを短くしなければ価値を届けられない
  • 阿佐志保さん
    • 資料: https://docs.com/asashiho/8906/jjug-ccc-2016-fall
    • 変化に強よいシステムとは変化することに強いシステム
    • Docker
      • 極めて高い拡張性
    • コンテナの運用には注意が必要
      • ぶっちゃけコンテナは良く落ちる
    • Googleはdockerではdocker+kubernatesが標準化され必須になっているらしい
    • Dockerは銀の弾丸ではない
    • エンジニア自身が変化に強くなければならない
      • 攻守が重要
        • 攻めていいシステムと攻めてはいけないシステムがあるはず

「QCon Tokyo 2016」へ行った その2

セミナー参加レポート
  • タイトル: QCon Tokyo 2016
  • 日時: 2016年10月24日(月)9:45~19:00
  • 会場: ベルサール新宿グランド コンファレンスセンター
  • URL: http://www.qcontokyo.com/index.html

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

その1はこちら

ttomioka.hatenablog.com

B-2 DDDとマイクロサービスの現実と可能性

現場からの実践報告 上坂 貴志

資料: TBD

  • オブジェクト指向をエンタープライズに展開がDDD
  • ユーザーとシステム開発側の双方が持つ暗黙知が悪さする
    • ユーザーの言葉を一緒に定義しなくてはいけない
    • 言葉は境界が違えば定義が変わる
  • モデル駆動が重要
    • モデリング→実装イメージができてなかった
    • 貧血ドメインになった
    • ER図がダメ
  • 最大のうまくいかない理由は恐らく不安
    • 「オブジェクト指向を勉強したけど役に立たない」という感覚
    • オブジェクト指向ができる = モデリングができるではない
    • モデリング = ER図 ではない
    • サンプルを用意。過去とのマッピングが重要。
  • モデルと実装が連動すればとりあえずはOK

DDD&モデリング導入のコツ 増田 亨

資料: http://www.slideshare.net/masuda220/ss-67660572

  • 利用者の満足するものではなく、技術者が満足していた
  • 習得したときはスピードが上がる
  • 会話が重要
  • 2つのブレークポイント
    • オブジェクト指向
      • データクラス+機能クラスの世界から脱却
        • クラスを作ったからってオブジェクト指向ではない
    • インクリメンタルな設計
      • 最初に綺麗に設計したがる
      • オブジェクト指向→インクリメンタルな設計の順番
      • オブジェクト指向に自信が無いとできない
  • 体で覚えるオブジェクト指向設計
    • 名前=何のためのコード化がわかるので重要
    • Getしているということはどっかにロジックを書いているはず
    • プログラムのしたいことをメソッド名を通して表現する
    • クラスとテーブルをぶった切りに行かないとダメ
    • リファクタリングを多用するので静的型付けが必要
  • インクリメンタルな設計
    • もっと速くコードを書こう
    • 最初からいい設計が見つからない
    • 設計書だって下書きしてからアウトラインができていく。コード一緒
  • できない理由はいくらでも考えられる。

DDD実践ベストプラクティス 加藤 潤一

資料: https://t.co/oNSqA6kLPX

  • CQRSとは
    • 質問をすることで回答を変化させてはいけない
    • DBを分けなくても、CQRSはありえる
    • 形式変換を行う。ドメインはライトだけにする
    • ライドでも状態を問い合わせることはありえる
  • イベントソーシング
    • 発生したイベントを全て永続化する
    • Updateはスケールしない
    • イベントが10万件あったら、Journalとsnapshotで解決
    • 今はAkkaだけ、Springもこの方向
  • マイクロサービスとコンウェイの法則
    • 複数サービスにまたがる変更がデリバリーコストを上げてしまう
  • コンウェイの法則とDDDの関係性
    • 言葉の持つ意味は使われ方によって変わる
    • 主語が一番見捨てられる可能性が高い

A-4 サーバーレスアーキテクチャ 伊藤 直也

資料: https://speakerdeck.com/naoya/serverless-architecture

  • サーバーレスアーキテクチャとは
    • 単純にはFaaSを使ったシステム
      • 必要になったときだけ計算する
    • ハード的な意味でサーバーがない
    • 常駐プロセス的な意味でサーバーがない
  • AWS Lambda
    • イベントごとにその関数を実行できる
    • コンテナで実行、終了時に破棄される
    • CGIに近いモデル
    • 基本的にステートレス(Shared Nothing)
    • AWSLambdaはスケールするし早い
    • EC2でたちあげっぱなしをAWSLambdaでやると安くなるのでは
  • 事例から
    • イベント駆動が結合
    • Bot常駐などで使える
    • 複数のイベントを連携させる
  • アーキテクチャの性質を解剖
    • CGIはShared Nothing で安全、簡単だった。
    • ただCGIはアプリケーション全体を毎回forkがとても非効率で
      遅くなった原因を調べると、アクセスカウンタなんてことも
    • Node.jsでは並行性のが高いが可用性に難。
    • よく考えると、起動に伴うオーバーヘッドが少なければ毎回実行で構わないのでは
    • AWSLambdaは毎回実行だが、コンテナで起動にともなうオーバーヘッドが小さいのが特徴。
  • LambdaからMicroserviceが見えてくる
    • Lambda 関数はイベントへの反応として記述する
    • 完全な疎結合になる
    • リアクティブである
    • FaaSは自然とMicroserviceになる
  • オーケストレーション(リクエスト、リプライ)
    • コレオグラフィ(イベント駆動)
      • パブとサブの間に関係はない
    • スターバックスは2フェーズコミットを使わない
      • トランザクションが失敗したらどうするのか?
      • スループットが最大化できる
  • Fassは自然とコレオグラフィを指向する
    • デバッグが大変
    • オーバーヘッドは少しかかる
  • サーバーレスアーキテクチャとはイベント駆動で系を設計した、 リアクティブでコレオグラフィなマイクロサービスのこと
  • ぶっちゃっけどうなの
    • はまれば強い
      • EC2より超安い
      • 自然と良いアーキテクチャに向かう
    • 開発工数はそこまで削減できないかも
      • FaaS特有の(バッドを含む)ノウハウが必要
      • ピタゴラスイッチになるのでデバッグが大変
      • 結合テストが難しい

A-5 HTML5/フロントエンド開発 白石俊平

  • Webはいまだに重要なのか
    • Web is Dead
    • ザッカーバーグ「HTML5を過大評価したのはわれわれ最大の失敗」
    • スマフォの利用時間の8割がアプリ
    • 昔はWeb100%だったのと比べると落ちた
    • Chromeアプリは2018年終了
    • 技術トレンドとしても減少傾向
      • HTML↓
      • W3C↓
    • HTML5は問題だらけ(特にAPI)
      • 2009-11年にAPIが増えた
      • ユースケース始動だった
      • ユースケースにはまらないと使いにくい
      • HTML5のAPIが使われない
        • APIの抽象度が高い
        • 低レベルのAPIをそろえよう→Extensible Web→盛り上がらない
    • Webの利用時間は減ってきている
      • Webの重要度は、以前に比べて下がっている。「モバイル・オンリー」という選択も珍しくない。
      • モバイル中心で考えると、Webはオプショナルな存在になった。
  • WebとWeb技術の利点を再評価
    • Webの利点を再評価
      • SLICE
      • Webブラウザ上のURLを踏んだらアプリを起動できる
      • Webとアプリをシームレスにつなぐ
    • Web技術の利点を再評価
      • クロスプラットフォーム
      • JavaScriptは世界で最も人気のある言語
      • まだまだ進化がやまない
        • AMP
          • 制約を守ると早く表示
          • グーグルがキャッシュしている
        • HTTP/2
          • 1つのサイトにつき1つのTCP接続で高速化
          • クライアントの差し替えなく導入可能
        • ES.next
          • トランスペアレント
          • クラスとモジュール
            • 今までは人によっていた
          • モジュールハンドラー
          • JavascriptはWebの性質上非同期
            • promise
            • async/await
            • let/const
          • オブジェクトリテラル
          • TypeScript
        • コンポーネント指向開発の本格化
          • これまでは基盤技術が足りなかった
          • Web Components
          • template要素
          • shadow DOM
          • HTML template
        • プログレッシブウェブアプリ

「QCon Tokyo 2016」へ行った その1

セミナー参加レポート
  • タイトル: QCon Tokyo 2016
  • 日時: 2016年10月24日(月)9:45~19:00
  • 会場: ベルサール新宿グランド コンファレンスセンター
  • URL: http://www.qcontokyo.com/index.html

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

その2はこちら

ttomioka.hatenablog.com

基調講演1エンジニアリングの物語り(ストーリーテリング) ~人に語るに値するカルチャー Pete Soderling 

資料: http://www.qcontokyo.com/data_2016/pdf/K1_PeteSoderling.pdf

  • アメリカでの採用関連の話題
    • アメリカではチームの多様性が問題。女性など。
    • データサイエンティストにどうやってプログラミングを教えるのか
  • IT企業における採用の工夫
    • ハッカソンが流行っている
    • オープンソースでアピール
    • エンジニアをリモートで。オープンオフィスはうるさすぎる
    • カジュアルをアピール。犬を連れてきていいや卓球など。
  • ストーリーを語って文化を説明しよう
    • ハートに訴える
    • 物語はとてもパワフル。モチベーションを高めてくれる。
    • 自律性が重要。あまり管理されたくない。
  • 各有名企業の例
    • Google
      • Googleはマネージャを認めない。ただマネージャを0にしたら1方向に進めなくなった。
      • Googleは実験をする。20%ルールなど。
      • 社内でハッカソンを数時間。業務以外のことをやってみる。
      • Googleは文化を破壊して新しく作る。マネージやバジェットなど。
    • Facebook
      • リリーストレイン
      • 入社2日目でトレインに乗せなくてはいけない。
    • Esty
      • 自分で構築し、自分で所有し、バグにも責任を持つ。
    • Netflix
      • AWSを利用して躍進。
      • その過程におけるアーキテクチャの変更が組織が買われる
    • Pivotal
      • XPを導入。 ペアプログラミング。
      • 人件費が倍かかる。売り込みかたとしてはこれしかできないと説得した。
      • 新人をペアにして勉強。それを仕組み化した。
  • 求人にストーリーを持たせる
    • フォーカスを絞る
    • つまらない箇条書きを捨てる
    • なぜその人はその会社に入るのか。

基調講演2ポスト・ムーア法則時代のコンピューティング 佐藤一郎

資料: https://t.co/hNe8c1ft8u

  • ムーアの法則の限界が来ている
    • ムーアの法則おさらい
      • 1つのチップ上の半導体の数は毎年倍増するという予想
      • Intelがこれを体現してきた。
      • ムーアの法則が実現されたことにより、半導体の高性能化の恩恵が受けられた。
      • 遅いソフトウェアもいずれPCが速くしてくれる
    • 迫り来る限界
      • ムーアの法則の微細化が遅くなっている
        • 半導体技術の限界
          • 5nmを切ると物理的限界。すでに10nmは実用化。
          • ブレイクスルーがなければ微細化は止まる。
        • 電力的な限界
          • 半導体を微細化しても消費電力辺りの計算量が上がらない
          • 発熱を考えると100wを超えるチップはつくれない
          • ダークシリコン
          • 発熱の関係で使えない回路が増える。
        • 経済的限界
          • 14nmクラスの半導体工場は1兆円越え
          • 月産100万枚以上でもペイしない。
          • 100万枚以上はスマフォ用ぐらいしかない。
          • 割に合わない
  • ポストムーア時代におきること
    • ファインテック
      • 技術的な新しさはブロックチェーンぐらい
      • ビジネスプロセスが重い業界向けで、ブームになることで重役の意見を変えられるか
      • マイニング事業者が寡占にはいると公平性は保たれるか
    • クラウド
      • 計算量辺りのクラウド利用量の下げ止まり
    • ベンダーとSI
      • 最新のコンピュータにしても性能が上がらない
        • 長期運用が中心になる
        • 保守中心。新規は厳しい。
    • 性能改善
      • 半導体による性能改善に頼らない改善策
      • メニーコア化
        • 32個以上は増やしてもいいことない
        • マルチスレッドプログラミングは難しい
        • テストでバグが見つからない。
      • 大容量メモリを行かす
      • GPU汎用化
  • ポストムーア時代に求められること
    • 余計なトランジスタを使わない
    • ソフトウェアの改良による性能改善は、ソフトウェア技術者の貢献として評価されるようになる

「JavaOne 2016 報告会@東京」へ行った

セミナー参加レポート
  • タイトル: JavaOne 2016 報告会@東京
  • 日時: 2016-10-15(土)13:30 - 20:00
  • 会場: 日本オラクル青山本社 13階セミナールーム
  • URL: https://jjug.doorkeeper.jp/events/52639

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

JavaOne 2016 Keynote紹介 by 伊藤 敬さん

  • 今年は9月に開催
  • JavaOne4Kidsは300人ぐらい参加
  • JavaChampionサミットが開催された
  • Java+dockerで配布。詳細は不明。当日に追加された様子。
  • 日本人が多く登壇
  • Duke's Choice Award を HeapStats が受賞
  • 来年は10月開催。報告会も多分やる。

Java SE フィードバック by 久保田 祐史さん (@sugarlife)

資料: http://www.slideshare.net/YujiKubota/javaone-2016-java-se-feedback-jjug-j1jp

  • JDK9は2017/7/23予定(再延長される)。
    • 経緯
      • 2016/5/26にFeatureCompleteが出される
      • 2016/6/10にnot yet Feature Completeとなり
      • 2016/9/20 2017/7/23リリースにリスケジュール
      • JavaOne直前にリリースが延長された
    • これによりJDK9のセッションがほとんど来年に持ち越し
  • JDK10はまだまだ先
  • JDK9の主な新機能
    • Jigsaw
      • モジュールの概念が加わる
    • JShell
      • 教育よりもCLIフレームワークとして使えるかも?
    • The Flow API
      • リアクティブのベースになっていくAPI群。
  • JDK9による変化いろいろ
    • 大半の内部APIがカプセル化される
    • ライブラリが隠蔽されているAPIを使っている場合は注意
    • クラスローダーの挙動が変更
    • javacできるのは3世代前(JDK9なら1.6)まで
    • バージョン表記が変わる
    • Appletが非推奨へ
    • JVM・GCログのフォーマットが変更
  • JDK9による範囲が狭いが刺さったら痛い変更
    • JDK8から非推奨になっていたAPIを削除
    • Arrays.asList(x).toArrays()の挙動が変わる
    • Stringの内部データがchar→byte など

Java EE フィードバック by Java Champion 寺田 佳央さん (@yoshioterada)

資料: https://docs.com/terada-yoshio/1777/javaone-2016-report-for-javaee

  • 日本企業が基調講演で多く登壇。
  • JAVA EE GURADIANDS
    • JavaEEの取り組みが昨年秋からどっと減ったことに端を発して発足。
    • 世界中の企業などがオラクル対しメッセージ(警笛)を出している状態。
  • 火星の話よりも、基調講演でJavaEEの不安を払拭するために時間を割くべきだった。
  • MicroProfile
    • JavaEEに関連する新たな動き。
    • ベンダーや有力コミュニティが集結して発足。
    • アジャイル手法を用いて製品を作成→標準化をしていくのが哲学。
    • これによりJavaEEのリリースの遅さを解消させるという考え。
    • JavaEEはいいけど、リリースが遅い。ただし標準化も重要と考えている。
    • 現行のJavaEEとは大きく異なるプロセスで、JavaEEに影響を与える可能性があるので、今後の動きに注目。
    • 時間をかけて標準化するのか、あるいは早期に市場に投入を優先するのかはどちらがいいのかは結論が出ない。 標準化された堅牢なものでシステムを作りたいという需要はある。
  • JavaEEについて
    • JavaEEは戦略的にはいい。
    • JavaEE8はJavaEE9へのつなぎ
    • JavaEE9はクラウド&マイクロサービス+リアクティブ。 これが本当にできるなら現状の不安は一掃されるぐらい期待できる。
  • リアクティブはレイテンシ向上のために必要
    • 非同期処理
    • ノンブロッキング
  • MVCがドロップ。他の仕様に注力するため仕方が無いか?
  • JavaEE9
    • マイクロサービスの様々なパターンにも対応できるようになる
    • リリースは2018年予定。ホント?

JJUG鈴木会長によるJavaOne 2016総括 by 鈴木雄介 (@yusuke_arclamp)

資料: http://www.slideshare.net/yusuke/javaone-2016-jjug

  • 標準Javaについて
    • 特に進展無し
    • Java ME、Java FXについてはキーノート発表なし
    • JavaEEの今後の不安は払拭されず。これはEEだけの問題でも無い。
  • IBMの取り組み
    • OpenJ9をOSS化
    • Eclipse OMR
      • 任意の言語の実行環境を開発するためのツールキット
    • IBMによる言語ランタイムのOSS化
    • 戦いの場ではないものをOSS化するIBMの戦略。
  • 誰がJavaを偉大にするのか
    • 標準の開発が遅れていても、誰かが追い越していく。それはコミュニティがやること。
  • JavaOneの総括
    • ベンダー主導の製品発表の場→Javaエンジニアの情報交換の場に変わってきている。
    • 雰囲気はオープンでエンタープライズ色が強めなのが特徴。
  • トレンド
    • DevOps、Cloud、Microservices、Reactive
    • Agile
      • もはや議論すらない。常識の範疇。
      • どういうリリースサイクルにするのかや具体的なツールの話。
    • DevOps
      • 定義はそんなに重要ではない。
      • ツールとしてはJenkisやBambooが一般的
      • マイクロサービス環境におけるデプロイなどが最近の話題。
    • Cloud
      • 使ってて当たり前
      • AWS勢が圧倒的
    • マイクロサービス
      • 一般的な概念として定着しつつある
      • いかに分けるかより、分けたサービスをいかに管理するかという議論へ
      • 500以上あるサービスをどうやって管理するのかな
    • Reactive
      • 用語定義やメリットの議論が継続中
      • 通信するという概念がボトルネック
      • コードにランタイムを組み込んだ状態でデプロイすることさえ今後ありえる
  • JJUG CCC Fall 2016
    • 12/3(土)開催
    • 冬じゃないかという指摘はうけつけられない?

Duke's Choice Award 受賞記念 HeapStats講演 by 末永 恭正さん (@YaSuenag)

HeapStats: https://github.com/HeapStats/heapstats

  • HeapStatsがDuke's Choice Awardを受賞
  • HeapStatsはJavaの障害解析支援ツールでOutOfMemoryErrorなどに対応できる
  • 受賞すると、JavaOneのチケットやDuke像などもらえる
  • 実は2014年に落選してからの再挑戦
  • 授賞式では写真撮影などがある。英語はそんなにしゃべれなくても大丈夫。

全体所感

  • 初耳という感じのことはほとんどないが、まとめてみるといろいろあるのでJava周りはそこそこ活況。
  • DevOps、クラウド、マイクロサービス、リアクティブなどやることや考えることは多い。
    数年はここら辺の対応でトピックがなくなることはなさそう。
  • リアクティブについては個人的に手を出せてないので、いつやれるのやら。
  • JavaEEについては寺田さんはあまりディスってなかったが、やっぱり期待できない。
    JavaEE9はよいと思うが、これが2018年というのが問題。
    個人的にはSpring Bootで行こうと改めて感じた。
  • JAVA EE GURADIANDSやMicroProfileの動きはOracleの方に影響を与えるという意味で注目したい。

「JSUG勉強会〜SpringOne Platform 2016 報告会!」へ行った

セミナー参加レポート Spring Boot

先日参加したのでまとめを書きます。全ての内容についていけたわけではないので個人的に注目だったorまとめられるものだけ書きます。

イベント全体・キーノート

メモ

  • Spring Oneは2006年頃から開催されている。
  • 今年からPivotal主催。
  • Onsiさん曰く、Springのツールだけでなくカルチャーが必要。
  • Philさん曰く、Springは2002年からその時代のニーズに合わせた最適な設計をし続けている。
  • Spring Framework 5.0
    • 来春予定。
    • リアクティブに対応。
    • Java SE 9 が遅れそうなので、9は5.1で対応予定。
    • Spring 4.3 は2019年まで対応。

所感

  • まだ先だと思っていた5が来春かって思った。バージョンアップはもちろん歓迎だがリアクティブに自分自身が対応できてないので焦らずそろそろ勉強しようかなぁ。いや5がでたタイミングでリアクティブも勉強するということでいいのかも。

Spring Core

メモ

  • 4.3の新規の振り返りいろいろ
    • 合成アノテーションと属性の上書き。
    • 暗黙的なコンストラクタインジェクション。
    • Java Config クラスのコンストラクタインジェクション。

所感

  • Springのアノテーション増の傾向は仕方が無い気がするので合成アノテーションはいい解決になる。ただこれも適度にしておかないと、合成アノテーション地獄になってしまうので注意したい。

Reactive

メモ

  • Ractiveはかまえなくていい。
  • 速度の違う通信が増えていたりでリソースのフル活用にReactiveが適している。
  • リアクティブのデメリット
    • オーバーヘッドを忘れてはいけない。
    • 非同期特有の難しさ。
    • DBのIOは要注意。

所感

  • Reactive3セッションで満足でした。
  • なんとなく概要はつかめた気がする。
  • DBとの関係が気になる。Reactiveをする場合はDB側もイベントソーシングが実質必須となるのかは現時点でよくわかってない。

Micorservices

メモ

  • マイクロサービスでDBを分けた場合の複数ドメイン参照。
  • 2PCはよくない。
  • イベントドリブンで結果整合性で頑張る。
  • 局所的なイベントソーシングを頑張る。

所感

  • 確かにスッキリ解決する問題がまだよくわからない。
  • イベントソーシングは敷居が高い気がするけど、そうしたほうが楽なシチュエーションは多くありそう。ただこれまでずっとステートソーシングだった頭を変革するのは大変だ。

全体所感

  • 盛りだくさんなセッションありがとうございました。
  • ただ長丁場なので中間休みを長めに取れるとよいと思います。あとイスの堅さ。
  • Spring Day 2016も期待しています。

最近JavaのWebフレームワークは「Spring Boot」1択でいいと思うようになった

Spring Boot

「Spring Boot」推しの記事ですが、フレームワーク選定の1つの意見として参考になればと思います。

フレームワークの変遷

まずは現状のフレームワークの選択肢を確認するために変遷を振りかえります。(リストは筆者の記憶によるものなのでいい加減です。詳しい変遷は他を参照して下さい。)

  • 2003年~2005年
    • Struts登場。フレームワークという概念が浸透する。
  • 2005年~2010年
    • Spring登場。脱EJBのDIコンテナ。
    • Seaser2登場。日本発ということもあり日本語資料が充実で人気だった。
  • 2010年~2016年
    • Strutsが衰退。
    • Seaser2が衰退。
    • Java EE 6登場。CDIなどを取り入れ、生Java EEもFWの選択肢に。
    • Spring Boot登場。Springが劇的に使いやすくなる。

各年のいい加減さはさておき、だいたいこんな流れという認識。「Struts」から始まり「Struts」「Seasar2」「Spring」の時代があり「Struts」「Seasar2」が終わっていく。2010年代前半にJava EE 6でCDIが導入され既存のFWに肩を並べてきた感じで生Java EEも立派な選択肢だったが、ただ最近はJava EEのリリースがとても遅いためまた置いてけぼりな感じになってしまった。これにより選択肢から外れてしまう。

そうなると消去法でも「Spring」が有力になっていくが、「Spring Boot」の登場により積極的にこれがいいと思えるようになった。

起動設定の複雑さを克服するSpring Boot

「Spring Boot」は「Spring Framework」を使いやすく使えるようにするためのプロジェクトで、起動設定からデプロイに至るまでよく考えられています。

Spring Frameworkが嫌われていた点は起動設定の複雑さです。特にXMLによるコンフィグレーションでは設定の内容を外部化するのはいいのですが、XMLファイルをほんの少々でも間違えると動かなかったりします。Spring Frameworkもこれに対応するためにアノテーションを利用したり、JavaConfigを導入したりしています。ただこれもまだ不足です。各Springライブラリでは実質必須で設定しなければならないものなどがあり、それをしっかり設定できていないと動かなかったりしました。

Spring Bootはそれを克服します。AutoConfigによる自動設定が動くので必要最低限の設定以外は不要になるからです。これによりほぼ設定関連の記述をしなくなります。自動設定で困るものだけ上書きをしていきます。開発時であればDBの接続先やログの設定を少々書くぐらいです。

さらにSpring Bootでは、実行可能jarを簡単に作成することができます。Webアプリケーションであっても組み込みtomcatが動くのでJ2EEサーバーを用意してデプロイすることなく、jarを実行するだけで起動できます。

これらの工夫によりSpring Bootは起動設定の複雑さを克服し、即デプロイ可能な手軽さまでを兼ね備えつつ既存のSpring Frameworkが使えることになります。ここがSpring Bootを積極的に使いたいポイントになります。

クラウド・VPS、マイクロサービスにマッチするSpring Boot

昨今のクラウド・VPS化によって、1台の高価格サーバーで頑張るよりは、低価格の複数インスタンスをロードバランサーで組み合わせるという方式が主流になってきます。これを実現するためには、デプロイのしやすさや起動のしやすさみたいなものが必要なりますが、まさにこれが先ほど説明したSpring Bootのポイントにマッチしています。マイクロサービスも同様で、Spring Bootを使えばマイクロサービスになるわけではありませんが、強力なツールになるのは間違えないです。必要最低限の設定で起動できるということは、数多くのプロジェクトやサービスを簡単に作成できるからです。

最近はインフラ専門家でなくても運用を意識するのは当然となってきました。これまでのように運用はインフラの専門家にお任せであれば、FWを決めるのにクラウドなどの運用観点をいれることは積極的ではありませんでした。ただ最近は規模にもよりますが、デプロイや初期運用もこっそり開発範囲に含まれるようになった気がします。

そうなってくるとデプロイしやすさや運用しやすさがFWを決める重要なポイントになってきます。その観点からいくとSpring Bootはかなりリードしています。Spring Boot自体がクラウドに寄せていっている部分も大きいですが、よく考えてみるとビルド・デプロイのしやすさまで考えられたFWはこれまで無かったような気がします。他のフレームワークでも頑張ればできそうなことは多いですが、機能として備えているSpring Bootを選んでしまいます。

これから始めるのもオススメ

個人的には最近「Spring Boot」を外せなくなっているので、こんな記事を書くに至りました。この記事だけで全ての良さを伝えられたとは思わないので、1度お試し下さいといったところです。「Spring Boot」はWebの他にも、バッチも自動的に実行記録を取ったりして相当使えます。

ここ1、2年で入門書・日本語書籍も増えてきました。活気づいています。1.4もリリースされます。そういった部分でもいままでSpringには行ってこられなかった人もいいチャンスかと思います。

Spring徹底入門 Spring FrameworkによるJavaアプリケーション開発

Spring徹底入門 Spring FrameworkによるJavaアプリケーション開発