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

「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 報告会!」へ行った

先日参加したのでまとめを書きます。全ての内容についていけたわけではないので個人的に注目だった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」推しの記事ですが、フレームワーク選定の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アプリケーション開発

ルール9(getterを使用しない)を考える

ttomioka.hatenablog.com

先日行ったセミナーでオブジェクト指向エクササイズのルール9(getterを使用しない)が曖昧だったと感じたので、課題を仮定して考えてみました。OOエクササイズの一つの考え方としてにご覧下さい。

課題について

商品価格、数量、割引率があって総合価格(割引後価格)を計算する。
ただこれだけでは不足なので、次のルールも加える。

  • 注文は1商品のみしかできない。ただし複数量は注文できる。
  • 注文には必ず割引がある。
  • 割引額は通常価格 x 割引率。小数点以下は四捨五入。
    通常価格は商品価格 x 数量。通常価格-割引額が割引後価格。

エクササイズ

第0段階 最初の思いつき

一番初めではないがここは通りそうな道。

f:id:tmk463:20160602115044p:plain

ちなみに注文の計算するコード。
注文に必要な値を全てgetして計算している。

public int 割引後価格を計算する() {
    int 商品価格 = product.getPrice().getValue();
    int 数量 = quantity.getValue();
    BigDecimal 割引率 = discountRate.getValue();

    int 通常価格 = 商品価格 * 数量;
    int 割引 = BigDecimal.valueOf(通常価格).multiply(割引率)
                                   .setScale(0 ,RoundingMode.HALF_UP).intValue();
    int 割引後価格 = 通常価格 - 割引;
    return 割引後価格;
}

注文に計算ロジックがまとまっているが、集中しすぎている。
今後肥大化しすぎて手に負えなくなる可能性が高い。

第1段階 不足している概念を追加1

このままでは概念が不足しているので「通常価格」を導入する。
通常価格は商品価格x数量なので、商品に計算を依頼できるようにする。

f:id:tmk463:20160602115920p:plain

これで商品と商品価格のgetterを撲滅。
ただし通常価格にgetterが増えた。

第2段階 不足している概念を追加2

続いて「通常価格」と同様に「割引後価格」を導入する。
割引後価格は割引率がからむので、割引率に計算を依頼できるようにする。

f:id:tmk463:20160602120638p:plain

これで割引率のgetterを撲滅できた。

この段階の注文の計算コード。

public DiscountedPrice 割引後価格を計算する() {
    UsualPrice 通常価格 = 商品.通常価格を計算する(数量);
    DiscountedPrice 割引後価格 = 割引率.割引後価格を計算する(通常価格);
    return 割引後価格;
}

getせずに割引後価格を求められている。
また通常価格と割引後価格があるということを、コードで表現できた。

ここで終わってもいい気がするが、
まだ数量と通常価格にgetterは残っているので続行。

第3段階 最後のgetterを削除

数量と通常価格のgetterを削除したいが、ここからが難しい。
最終的に何らかの計算はしないといけないので自クラスで保持している以外の値が必要になる。
迷った結果、掛算をするメソッドを導入した。

f:id:tmk463:20160602121420p:plain

これで数量、通常価格のgetterを撲滅できたが、
ルール3(すべてのプリミティブ型文字型をラップすること)違反になった。

ただ、内部状態をさらすというカプセル化違反からは脱却できた。
何かと掛け算して使われるということも把握できる。(少なくとも自由奔放には使われない)

この他に検討した内容については次の通り。

  • intを返さずに通常価格オブジェクトを返すようにする。
    • 数量になんでもint型を渡すと通常価格を計算できるという解釈が
      生まれてしまう気がするので避けた。
  • 商品価格自体を渡してしまう。
    • 結局は数量の中でgetしてしまうので問題が解決しない。
  • getValue()ということではなくintValue()のように型を制限した形にする。
    • 内部状態をさらしていない解釈もできるのでよいのかもしれない。
      ただ用途があまり制限されないので今回は避けた。

とりあえず、getterを使わないを達成できたので終了。

振り返り

  • 第2段階まではスッとできた。
    足りないクラスやメソッドを導入することで、コードに知識が広がるしgetterの削除につながる。
  • 第3段階ではどの道に行ってもプリミティブ型を受け取ったり返したりする案しかうかばなかった。
    Valueオブジェクトとしてルール3違反はどうしようもないかもしれない。
    仕方が無いというのが現時点での結論。もっとエレガントな方法があるのだろうか。

「Java Day Tokyo 2016」へ行った

先日参加したのでまとめを書きます。

基調講演

所感

  • 特に衝撃的な話は無かった気がする。本日のセッションのカタログショー的な感じ。
  • CEOの話がレベル高すぎてついていけなかった。
  • 損保さんがCOBOL→JavaEEでリプレイス。
    巨大な会社が旧資産を刷新する美談ともとれるが、
    そこで喜んでしまうのはレベルが低い気もする(そこを自慢しに来たわけではないが…)。
    ただ巨大な会社を知っている人からすれば、やはり凄いことか。
    新技術も取り入れて、積極的にITに取り組むユーザー会社の責任者さんがいたことは
    喜ばしいこと。
  • ドローンのデモは引きつけられた。
    ソフトウェアOnlyではああいう感じのことはできない。うらやましい。
    昨年ペッパーのデモやっていて「なんだこれ」と思ったけれど、
    そこそこ売れたみたいだったからドローンも。

1-A Java SE 9 Overview

メモ

  • Java9
    • Jigsawの話。OpenJDKで確認を。
    • GCはG1がデフォルト。
    • バージョニングがJDK9.○.○。
    • JShell。インタラクティブにコマンド実行できるもの。
    • インターナルAPIを削除していく。sun.misc.など。
  • Java9以降
    • value型の導入。10or11。
    • JNIの改善版。プロジェクトパナマなど。

所感

  • Java9は来年。Jigsawがやはりメイン。
    Java8みたいに標準ライブラリが相当変わるというタイプの変更は少なめか。
  • value型はその次の中心的な話題になるのだろう。

2-A Project Jigsawではじめるモジュール開発

メモ

  • Jigsawが必要になった背景や変遷の話。
  • module,requires,exportなど具体的な使用方法。

所感

  • Jigsawの雰囲気が少しつかめた。
  • モジュールに対応したビルドはどうなるのか気になる。
    Mavenのセントラルリポジトリにmoduleが追加されるのか?

3-C Java Concurrency, A(nother) Peek Under the Hood

メモ

  • 直接並列処理を書いていなくても、多かれ少なかれ並列処理を意識する必要はある。
  • ルールとして覚えてもダメ。原理をわかった方が効率的。
  • Javaのメモリモデル。happened-beforeなど。
  • 抽象度の高いAPIから使っていく。volatileよりjava.util.concurrentを優先。

所感

  • 並列処理についてちゃんと基礎部分を聞けた貴重な体験だった。

4-E 実践して分かったJavaマイクロサービス開発

メモ

  • マイクロサービスは目指すのではなく結果論。
  • デプロイの自動化は必須。
  • 巨大なSQLがドメイン分割できない足かせ。
  • マイクロサービスありきではなく、自組織に合わせた最適化が必須。

所感

  • 現場の経験を語っていただけたことが何よりありがたい。
  • 巨大なSQL→悪ではなく、
    それを書かなくてはいけないドメイン設計やデータ設計が悪な気がする。

5-D オラクルコンサルが語るJava SE 8新機能の勘所

メモ

  • Date And Timeやラムダ式やStreamを使っても、
    基本的に大きくパフォーマンスやメモリ使用量などを損なわない。

所感

  • (当然かも知れないが)分析が丁寧でよかった。
  • streamは外部変数参照したやつも比較に加えるともっとよかった。

NS パネル・ディスカッション - Java Day Night Session with NightHacking Tour

メモ

  • 日本のJavaコミュニティの話。
  • アジアでは英語で発信できる人が少ないのでJavaチャンピオンが少ない。
  • JCPに参加をしよう。
    • Javaの仕様に不満があれば、JCPにフィードバックする。
  • MSコミュニティとの違い。
    • MSではMVPが多く、MVPを中心に勉強会が開かれる。
    • MSはMVPの選出に口を出すので、Javaチャンピオンとも違うモノ。
    • もっとJavaに興味を持っている人を活動しやすくするのが
      Javaコミュニティの一つの課題。
  • nesエミュレータの話。

所感

  • JCPといわれても英語の壁は高い。
  • ステファンさんのnesエミュレータは思った以上に考えられている。
    もっと単純に作れると思っていた。あなどれない。
  • ストリーム配信していたみたいだけれど、ソフトの権利大丈夫?

全体の所感

  • 机がほしかった。イスも何だか堅い。
  • 満席セッションも多く、トイレ混雑などキャパが合っていなかったのでは。
  • 来年も期待します。

「DDD Alliance! ドメインオブジェクトの見つけ方・作り方・育て方」へ行ってきた

先日参加したのでまとめを書きます。

メモ

  • 設計の基本
    • アジャイルとオブジェクト指向のつながりはたまたまではない。
      変更容易性を突き詰めていった結果の側面。
    • 仕様変更とプログラムの変更が一致しないのはダメなモジュール。
      モジュール性における連続性が低い。
    • 機能分割が機能クラス+データクラスなら、オブジェクト指向は抽象データ型。
    • メイヤーの本は鈍器。
    • 機能分割はモジュール評価における「わかりやすさ」や「連続性」が低いので変更が大変。
      (メイヤーによると)
    • オブジェクト指向なら変更に強いので仕様変更が怖くない。
      むしろお客さんの興味のあったことを理解できたはずなのでムダではない。
  • 見つけ方
    • 何気ない用語からドメインの学びは始まっている。
    • 利用規約はドメインそのもの。クラスやその振る舞いの要素そのもの。
    • アソビューはDDDで開発している。CEOの理解もある。
    • とりあえずひな型8点セットや業務の関心事発見パターンを参考にする。
  • 作り方
    • getして自分で判断・加工・計算するのはNG。
      これによりロジックの置き場の整理にもつながる。
    • nullを渡さない戻さない。全員が守れればチェックはいらない。
      信用できずにチェックをするとなると、それによってコードが汚れるので、
      可能であれば約束事にすべきだ。
    • ドメイン層以外は常にシンプルにしておく。
      ドメイン層以外が汚くなったらそれは怪しい箇所としてチェックできる。
    • DBや画面はデータをどう扱いたいかだけだからデータをフラットにしたがる。
      オブジェクト指向と相容れないのは仕方が無い。
    • ドメインの表現にこだわるためにフレームワークを活用する。
      ドメインが守れるなら、多少の苦労はいとわない。妥協しない。
  • 育て方
    • メソッドの抽出を頑張る。
    • 2個以上の引数は怪しい。
    • 一時変数を値オブジェクトへ。
    • 区分オブジェクト。
  • QA
    • コンテキストを超えた範囲での共通化をどうするのか。(名前、電話番号など)
      • コピーがいい。コンテキストごとでドメインが成長するので共通モジュールにしにくい。
    • ドメイン層が深いとテストしにくい。
      • 深い階層になるのはドメイン設計に問題がある。
        (増田さんは)ドメイン自体にテストは書かない派。サービスなどはテストを書く。

所感

  • メイヤー本の話が出た。
    昔オブジェクト指向を深く知りたくて読んだけれど、理解できなかったり読み飛ばしたりしたところが多かったのでもう一度トライしてみたい。
    いやDDD本の再読の方が先か。
  • 「オブジェクト指向なら変更に強いので仕様変更が怖くない。
    むしろお客さんの興味のあったことを理解できたはずなのでムダではない。」あたりは増田さんらしい。(他ではあまり聞けない)
  • nullを渡さない戻さないは挑戦しているけれど、チェックしないという発想はなかった。
    習慣でLombokの@NonNullつけていたけれど 信用できる範囲内ならいらない気がする。
    挑戦してみよう。
  • 個人的にオブジェクト指向エクササイズのルール9の考え方(getterを使わない)が
    曖昧なことに気がついた。
    例えば、商品価格、数量、割引率があって総合価格を計算するときに、どっかにまとめて計算するメソッドを作ってgetしてしまいそう。
    そこからのリファクタリングがぱっとは浮かばない。自身の中で整理が必要。
  • 今回は最終補欠が24人いた。次回以降、普通に落選して繰り上がれないことも覚悟が必要。

謝意

増田さん、DDD Allianceさん。このような会を定期的に開いていただいて感謝します。
次回も期待しています。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)