オブジェクト指向プログラミングを学ぶのに適切な書籍と私がおすすめする読む順番

オブジェクト指向プログラミングを学ぶのに適切な書籍と私がおすすめする読む順番

何故かいたか

同僚Aが緑のデザパタ本読んでたり、同僚Bが他の人が読んでる本が気になるっていってたり、後輩Cが会うたびにおすすめの本を聞いてくるので、それらにちなんで、オブジェクト指向プログラミングを習得するためにこの順番でこの本を読むと良いのではないかということを伝えるために、私的な案を考えてみました。

短くまとめてはいますが真剣に考えています。

真剣に考えてみた結果、彼らに伝えて終わりにするのがもったいなくなってしまったのでブログに書いておくことにしました。

オブジェクト指向プログラミングが学べる書籍たち

私が読了済みの本の中から選んでいます。スムーズに理解が進むと思われる順番に並べています。

前提言語はJavaで言語構文にも十分詳しいことが大前提です。

  1. 現場で役立つシステム設計の原則
    • OOPらしさの雰囲気がわかります
    • 入り口に最適です。OOPがどう良くて嬉しいのか、平易でわかりやすく書かれています。
  2. テスト駆動開発
    • OOPらしいコードにたどり着く道筋がなんとなく見えます
    • そういう用途にも使えるというだけで、主題はテストコードです。
  3. リファクタリング
    • 手続き型からOOPらしいコードへ導く道筋のカタログです(リファクタリングが主題の本ですもんね)
    • リファレンスとして手元においておくとよいでしょう。
  4. パターン指向リファクタリング(絶版だが頑張ればまだ手に入る…)
    • さらにもう一歩踏み込んで、落とし所となるデザインパターンへ導く手法を主題にしています。
    • (3)と同じくカタログ化されています。リファレンスとして手元においておくとよいでしょう。
  5. Java言語で学ぶデザインパターン入門
    • (1)から(4)である程度OOPデザインパターンに対する理解が深まっているはずなので、このタイミングでやっとアカデミックにアプローチします。
    • 断片化しているデザインパターンの知識をここで体系的に纏めます。
  6. ドメイン駆動設計
    • ここからOOPを離れていきます
    • OOPをベースに、価値あるソフトウェアを戦術的に・戦略的に構築していく方法論が学べます。
    • いわゆる鈍器です。高いです。しかも抽象的で難解です。覚悟をもって読んで下さい。
  7. 実践ドメイン駆動設計
    • (6)の10年後に出た書籍です。DDDを具体的にコードに落とし込むとどうなるかにフォーカスしています。
    • 相変わらず、鈍器です。高いです。
    • CQRSやイベントソーシングなど技術的な観点が強めに入ってきます。
    • 実装例が出てきますが正解例ではないです。参考にするのはいいですが利用する場合は状況やプロジェクトの嗜好に合わせてアレンジしましょう。
    • これ読んだらもう一度#6読み直したほうが良いです。

その他のおすすめ(未読)

以下の書籍は私もまだ読んでいませんが、レビューなどを見る限りではなかなか良さそうです。これから読みます。

以上。

『今あえてDRY原則に向き合い』のスライドを見て考えるところ

『今あえてDRY原則に向き合う』

https://speakerdeck.com/shinpeim/jin-aetedryyuan-ze-nixiang-kihe-u

はてブ見てて、そうだよね!と共感する記事を見つけたので、私の考えている事と共にシェアします。

スライドの概要

DRY原則ってタイトルにはついてますが、DRY原則を実践するためのノウハウなスライドではないです。

DRY、DRYって言われる理由ってなんだっけ?ただ実践すれば幸せになれるんだっけ?本当にそれだけ考えれば良いんだっけ?と、いろいろな気づきを与えてくれる内容になっていますので、ぜひご一読ください。

私の考えたこと

Fuga原則だとかHogeパターンだとか、良いとされている設計原則やデザインパターンはいろいろありますが、これらはコードを鍛え上げた結果として、共通して現れてくることの多い特徴やパターンに名前をつけただけだと思っています。
※実際に世の中でどういう定義付けがされているかは知りません、私がそう理解し、また実感しているという話です。

つまり、アカデミックに理論を組み立てて作られたというわけではなく、何度もコードが変更されていく過程で、変化に対して柔軟に対応できるソフトウェアにするにはどうしたらよいか、その都度真剣に考えて鍛え上げていく、そういう実践の中で自然発生的に生まれたものなのでしょう。
※実際に世の中で(ry

そうして出来た良いコードにFuga原則だとかHogeパターンだとかという名前をつけてカタログ化することで、私のような凡人エンジニアでもそれを参照し真似することをでき、スキルとして身につけていくことができます。

しかしながら、現実問題としてFuga原則とか1つ2つ知ってるだけじゃ良いコードを書けるスキルなんて身につかないんですよね。

Aな傾向ではこのデザパタ、Bな傾向ではこの原則、Cの傾向ではある原則とデザパタを組み合わせる、といったように引き出しを増やして、組み合わせるスキルを磨いておかないと、何でもかんでも1つか2つの原則・デザパタで解決することになってしまうからです。

解法を1つしか持っていなければ、目の前にある問題に対してその解法でしか解決できないわけですから、そりゃ効率的で変更に強い良いコードなんて書けるわけがありません。
※かくいう私もまだまだ修行中です。頑張ります。

1234を55回足した答えは掛け算を知らなくても足し算で解決できますが、掛け算を知っていれば効率的に解けるのと同じです。『金槌しか持っていなければ、すべての問題は釘に見えてくる』ってやつです。

私は『DRYにしなきゃ』しか考えないエンジニアが書いたコードが○○コードと言われてしまう所以はここにあると思っています。

まとめ

『筋の良い分割とはどういう分割なのか?』らへんに触れることがこのスライドの主題だと思います。その主題に沿ってまとめるならば『筋の良い分割を実践の中で導き出すためには、多くの設計原則とデザインパターンを知っておき、それらが何を解決してくれるのかを理解しておくこと』が重要だと私は考えていると主張しておきます。

読書時の便利グッズご紹介

読書時の便利グッズご紹介

今日は短めのエントリーです。

技術書読むのに使ってる便利グッズをご紹介します。

ブックマーク

f:id:kogayushi:20180120170056j:plain

マーキングクリップをブックマーク代わりに使っています

並行して複数読んでいるとその数だけブックマーク揃えるのお金かかるし、買うのも面倒ですよね?

そこで私は全ての本にこれをつけています。
本を閉じるとき、読み進めたページにつけておくわけです。

ただし、注意点があります。
紙が薄いと挟んでいるカバンの中で他のものに押されたりして、食い込んでページに傷がつくことです。
2頁以上まとめて挟み込むと割りと平気です。

気をつけていても傷がつくので借り物の本には使用しないようにしましょう。

書見台

f:id:kogayushi:20180120170109j:plain

ほんたったが有名だと想いますが、
私はactto BST-02BKを使用しています。

本の角度が細かく調整できる点が良いです。 ほんたったは使ったことがないので断言はできませんが、きっと同じような機能はあると思います。

似たような別のものでも良いので、一つあると写経が捗ります。

デスクライト

f:id:kogayushi:20180120170120j:plain

山田照明 Z-LIGHT Z-108LEDを使っています。

ほしい位置に簡単に光源をセットできるので良いですよ。
私は夫婦ともに読書量が多く、デスクで本を読む時はライトを譲り合いながら使う必要があるのですが、
Z-108LEDは簡単に位置を変えられるので重宝しています。

以上、便利グッズご紹介でした。

新装版リファクタリング感想(第1章だけ)

印象に残った部分のメモを残します。

第1章 リファクタリングー最初の例

メソッドの抽出

page 9より引用

最初に、抜き出そうとする部分でローカルなスコープをもつ変数に着目し、それらが新規に作られるメソッドの一時変数かパラメータにならないか検討します。

ここまで言語かできてないし、全く同じことではないけど似たようなことはやってる!と思った。

条件によって代入する値が変わる場合にswitch文の中でそれをやるコードを良く見る。
しかし、スコープが比較的広く、再代入が可能なローカル変数は値が再代入されるのかを気にしなければならない。
それが嫌なため、該当処理をprivateメソッドや別クラスに括りだすようなことをよくやる。

自分が実践しているテクニックと似たようなものが紹介されていて少しテンションがあがった。

問い合わせによる一時変数の置き換え

page 21より引用

そこで、「問い合わせによる一時変数の置き換え」を適用することにします。

私はいままではオブジェクトから値を取り出すときはパフォーマンスを考慮して一時変数を利用していた。
しかしこの本によるとメソッドから取り出すことがパフォーマンスに影響することをリファクタリング時には気にしすぎなくて良いらしい。
さらには

しかし実際には、コードは適切に分割することで、もっと効率よく最適化できるのです。

とのこと。

実際のコード例はこんな感じ。

Before

            double thisAmount = 0;
            Rental each = (Rental) rentals.nextElement();

            thisAmount = each.getCharge();

            // レンタルポイントを加算
            frequentRenterPoints++;
            // 新作を2日以上借りた場合はボーナスポイント
            if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) && each.getDaysRented() > 1)
                frequentRenterPoints++;

            // この貸出に関する数値の表示
            result += "\t" + each.getMovie().getTitle() + "\t" + String.valueOf(thisAmount) + "\t" + "\n";
            totalAmount += thisAmount;

After

            Rental each = (Rental) rentals.nextElement();

            // レンタルポイントを加算
            frequentRenterPoints++;
            // 新作を2日以上借りた場合はボーナスポイント
            if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) && each.getDaysRented() > 1)
                frequentRenterPoints++;

            // この貸出に関する数値の表示
            result += "\t" + each.getMovie().getTitle() + "\t" + String.valueOf(each.getCharge()) + "\t" + "\n";
            totalAmount += each.getCharge();

本当に問題にならないかについては業務で試してみようと思う。
パフォーマンステストをちゃんとやる前提で。

まとめ

第1章の内容はテスト駆動開発の第1部多国籍通貨のようにペアプロをしているように感じさせる書き方だった。
ただ、テストコードがないため自分で書いたものを使った。

後半で「ポリモーフィズムによる条件記述の置き換え」の例が出ていた。 私もswitch文が登場したら不吉な匂いを感じて多くの場合は書き換えるのだが、それをほかの人に説明するための具体例に困っていた。
今後はこの書籍の例を引用したいと思う。

私は手続き型で書かれたコードをリファクタリングする際にこのテクニックは頻出だと思っているが、自分の経験の中には「誰にでも」しっくり来る例がなかったので良い例を知れたことが嬉しい。1

年齢の割にプログラミング歴が浅い&詳しい業務が偏っている私にとって、書籍から得られる汎化された知識・テクニックはとても有り難い。

全編を通して読んだが、(直前で言ってることとは矛盾するが)経験を積んだおかげか大部分を理解できた(と思う)。
だいぶ前に増補改訂版Java言語で学ぶデザインパターン入門を読了済みだったため、予備知識があったからだと思われる。

DDD本と同じく2〜3回再読してしっかりを知識を染み込ませよう。

ちなみに、今まで我流で身につけた方法にこの本の手順を組み入れたやり方2を既に現場で実践し始めた。

以上。


  1. 私は一番長く関わっている業務分野が認証なのだが、この文脈の中から例を取り出してもわかってもらえることが少ない

  2. 組み入れたと言ってみたが、大部分はほんのやり方に置き換わった

ITエンジニアに読んでほしい!俺的技術書大賞2017

ITエンジニアに読んでほしい!俺的技術書大賞2017

タイトルは完全にパクリです。 http://www.shoeisha.co.jp/campaign/award/2017/

前置き

今年も結構な数の本を読みました。読書メーターで読んだ本を振り返ると技術書だけでも11冊、その他は3冊でした。再読と技術書以外の書籍も含めると合計で20冊読んだようです。

そうして出会った本達の中で『これは良い!』というものを見つけたら、その都度身近にいる方々にはすすめているのですが、せっかくなのでこの場で共有してみたいと思います。

今回書評を紹介したいのは、2017年発行の4冊です。

どれも良書でしたので、おすすめ度が高い順番に紹介します。

2017年発行の書籍おすすめランキング

まずは、おすすめ順の一覧でどうぞ。

  1. 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
  2. Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで
  3. テスト駆動開発
  4. アプリケーションアーキテクチャ設計パターン

各書評

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

初級者と初級者を卒業したばかりの中級者のエンジニアと初中級者を指導する立場のエンジニアに、強く強くおすすめします。

オブジェクト指向らしく書いたほうが良いという話はよく聞きますしそういう人に出会うことも多いですが、具体的な例でわかりやすく説明してくれる(できる)人って出会ったことがありません。身近にそんな人って周りにごろごろいますか?

可読性大事っていうけど実践できる人ややり方を具体的に教えてくれる人ってめったにいませんよね。

かくいう私も現場で地道にOOPの布教活動をする側ですが、いつも上手に伝えられているかというとその自信はありません。口頭で伝えきれない場合はどうしても具体的にコードを書いて示してしまいます。

でもそれをやりすぎると『自分で書いたほうが早い』となってしまうので都度やり方を伝えて覚えてもらうにしても、どれほどそのコストをかけるのか、かければよいのか1という点が難しいところです。

そういう場合、悩むのは『もっと手早くかつわかいりやすく伝えるにはどういう言い回しや例の出し方があるのだろう』だとか『この本読んどいてって渡せる書籍があると楽だなぁ』といったことではないでしょうか。

少なくとも私はそうでした2

そんな教える側にとっても教えられる側にとっても役に立つ本、それがこの本だと想います。

OOPらしく書くときにコードで気をつける点を端的に纏めてありますし、気をつけている何かに気づいた場合にどう対処したらよいのかをPolicy/StrategyやStateといったデザインパターンを使って説明してくれています。

例えば。

ビジネスでよく出てくる満たすべき条件はPolicy/Strategyパターンを使えばif文を使わずに簡潔に表現できること、ある状態からある状態へ遷移可能かどうかをEnumとMap(連想配列)を使って簡潔に表現できること、子どもや大人といった区分で変わる振る舞い(書籍の例だと料金)には専用に用意したクラス(enumなど)に振る舞いを与えれば良い3などなど、役立つパターンが数多くわかりやすく紹介しています。

『あぁ、はいはい。デザインパターン、小難しいやつね』とちょっと思ってしまった人もしかしていませんか?

そんな人にこそおすすめです。

名前がついてしまうと小難しいような感じがしますが、実際は『なんだかよくわからないけど、ちょっと見てみるか』程度の覚悟でもちょっと中身を覗いてみると一度か二度は自分でも書いたことのある構造になっているもので、そんなに難しいものではありません。

食わず嫌いをせずにぜひ手にとって見てください。3ヶ月後にはコードの質が変わっているかと思います。

具体的な中身についての書評はググるとたくさん出てきますのでこれ以上はやめておきます。

ぜひ、みなさんも読んでみてください。絶対に後悔させません。こう強くいい切れる程度にはおすすめです。

ちなみに私は都合3回読みました。


Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

最初に断っておきますが、『入門』と題する割にはそこまで初級者向けではありません。

これも中級者の入り口くらいにいる人におすすめの書籍です。

Javaの言語としての仕様・構文の説明もありますが、どちらかというと経験豊富な著者らが現場で培った『Javaをうまく使うにはどうしたらよいか』の知見を広める書籍の側面が強いように思えます。そうかくとちょっとEffective Javaっぽいですが、もっと簡単な内容です。

そのため、『Javaの構文や言語特性はある程度覚えた。でもそれらをどう使いこなせばわからない』という人に状況にいる人に特におすすめです。

レベル感としては業務でコードを書き始めて1年経過したくらい4のエンジニアに特に適していると思います。

私は認証関係を扱うことが多いのですが、認証系の業務であまり扱う機会のないファイル操作に関しての章がとても勉強になりました。

一番役立っているのはListをimmutableに使えるドSのCollections#unmodifiableListを知れたことです。

原則としてインスタンスはimmutableにしたいのですが、Listとなるとそうはいかないのがこの本をよむまでの悩みでした。しかし、このAPIを知れたことで簡単にimmutableなListを作ることができるようになり、いまはとても捗っています。

と言った具合に現場で役立つ情報が盛り沢山です。

この本のタイトルにも『現場で役立つ』の冠をつけたほうがよかったかもしれませんね。


テスト駆動開発

言わずとしれた名著の新訳版です。JUnit5でも動くように書き直されており、コードサンプルも省略されている部分がないせいで全体像が見えなくなる(読者が迷子になる)ことがないように細かい所まで配慮されています5
もはや古典と言って良いこの本ですが、翻訳者のt-wadaさんの手で見事に生まれ変わっています。

さて、この書籍はテスト駆動開発というタイトルが付いてはいるものの、この本の本質はテスト自体にはなく『プロダクションコードがもつ意図をテストコードでどう表明するか』を具体的に示している点ではないでしょうか。
その点を付録Cでの『TDDのテストとは、いわばプログラミングの補助線、治具です』と言う言葉が端的に表しているような気がします。

私達が普段書いているテストには回帰テストの意味合いがあります。
しかし、それより重要なのは『意図していた・期待していた振る舞いをプロダクションコードが正しく表現できいるか』を確認するすべなのだということを示している点ではないでしょうか。

3番目に挙げてはいますが、この本も本当に良書です。
ぜひ、手にとって見てください。


アプリケーションアーキテクチャ設計パターン

この本はアーキテクチャ寄りのエンジニアにおすすめです。

業務で普通に話されているが、実はよくわかってない用語やよくある一般的なアーキテクチャについて知るにはとても良い書籍です。
しかし、(ただの印象ではあるが、ちょっとだけ)Java EE贔屓に感じる6ところがあり、またドメイン駆動設計の説明が薄く、手続き型を前提にしている点が少しだけ残念に感じました。
ただ、それ以外は現場で役立つ情報が満載で本当に勉強になる書籍です。

万人向けではありませんが、方式設計などにも興味がある人にはおすすめします。

終わりに

以上、4冊の書籍を紹介しました。 興味を持った本はありましたか?

もしあれば、ぜひ買ってみてください。

ちなみに私は紹介したほとんどの本を会社の書籍購入補助を利用して買いました7
良い会社ですよ、本当に。

以上。



  1. 相手が自社のプロパーの場合は話は別で、スキルアップすればするほど会社の資産・利益につながるので時間と都合が許す限りはリソースを割いています。相手が伸びるのを見ているのも楽しいですしね。

  2. ちょっと偉そうに書いてみましたが、どちらかといえば私も教えられる側の中級者だと思っています。

  3. 著者は区分オブジェクトと表現しています。私はStateパターンの亜種だと思っています。一般的に知られたデザインパターンでしょうか?私は知りませんでした。

  4. 根拠のないただの感覚値ですがステップ数に換算して4000行、クラス数に換算して30-50程度でしょうか。

  5. この点で良書なのにもったいないと感じたのはClean Codeが挙げられます。リファクタリングの様子を紹介している節があるのですが、コンパイルが通る完全なコードが載っておらず、私は写経ができませんでした。やる気をなくしてしまったあとに付録にコードがあることに気づきましたが、借りていた本ということもあり時間の都合でトライする前に返してしまいました。

  6. 著者はマスタリングJavaEE5の人なので、ポジショントーク的なところもあるのかなという気はしています。のでまぁ、私は仕方ないと思いました。どこにそう感じたのか時間があればもう一度振り返りたいと思います。

  7. 年間で10冊以上技術書を買っていると結構な金額になるので、この制度はとても助かっています。感謝しかありません。

JJUG CCC Fall 2017に行ってきました

JJUG CCC Fall

まえがき

自分用のメモではありますが、役に立つ人がいるかもしれないと思いメモったことと簡単な感想をブログに乗せておきます。 間違いに気づいたら後から訂正しますが、速度優先と自分用メモなので正確な情報は登壇者があとからあげているスライドを見ることをおすすめします。


Selenide or Geb ? あなたはその時どちらを使う?

はじめに

  • Seleniumを使う上でSelenide, Gebどちらを使えば良いのかを考える

Codezin

  • selenideとgebの本が出る

概略

Selenide

  • エストニアのcodeborne社のandreiが作ったJava製WebDriverラッパー
  • DSLを用いたjQueryセレクタ
  • IDEによる補完機能を駆使
  • 要素取得時の待ちを暗黙的に行う
    • AJAXなどの非同期処理の返りの処理記述が容易
  • 呼び方は?
    • せれないど?せれにど?
      • 英語だと「せれにど」、ロシア語だと「せれないど」
        • 製作者的には「どっちでもいい」
      • 日本語だと「せれにど」だからせれにどでいいのかなぁ

Geb

  • 読み方は「じぇぶ」
  • Groovy製のSeleniumラッパー
    • バージョンは2.0
  • DSLを用いたjQueryセレクタ(selenideと一緒)
  • groovyの機能をふんだんに利用した、簡潔な記述が売り
  • selenideよりもより簡潔にかける

selenide Pros and Cons

Pros

  • 簡単に利用できて学習コストが低い
  • Seleniumの知識はほぼ不要
  • IDEとの親和性が高い
  • 標準でAJAXの待ち処理対応
  • Enterprise Support
  • Java(JVM上で動くと言う意味で)

Cons

  • 日本語情報がまだ少ない
  • 対話的に使うことができない

ちょっと質問

  • コンソールでjQueryで書いてみて、それをコピペする
  • developerツールで検討をつけてから、コードを書く
  • selenideは補完が強いので初見でも書ける
  • eclipseも補完効く?
    • 効く

geb Pros and Cons

Pros

  • 簡潔な記述
  • 豊富な機能
  • 豊富なエコシステム
    • 特にgradleか
  • 日本語情報はselenideよりも多め
  • 簡単に利用できる

Cons

  • 学習コストが高い
    • Gebそのものもそうだが、GroovyやGradleも手を出すと大変
      • 今書いている機能がgebなのかgroovyなのかgradleのタスクランナーからきたのかわからなくて混乱することがある
  • IDEの補完が弱い
    • Intellij IDEAを利用したり、多少を補完は効かせる方法はある

体験談

初めてのSelenium(Selenide)

  • SeleniumでのE2Eテスト導入を担当
    • Selenium,Selenide未経験
    • サイト見ただけ
  • Selenideのサンプル通りに書いたら、特につまずかずにかけた

Jenkinsで不安定

  • 手元で通るのにJenkinsだと失敗
  • デフォルトで待ち処理が入ってるのに。
  • 録画機能などを使わないと原因追求が困難
  • 生のSeleniumよりましだけど、安定化はやはり大変
  • 画面キャプチャが残る
    • キャプチャじゃわからないような原因でfailしていたりする
  • waitがうまく入らない、でハマる事が多い
    • 都度都度waitを差し込んで対策していく

geb/selenideが話が出て来る文脈

  • レガシーなシステムのQAコスト下げたい、とか
    • QAは6時間が20分になるかもしれないけどシナリオのメンテナンスはしなきゃなので、それはそれで辛い
    • シナリオを作り込むのにも時間かかる

マルチブラウザテストの導入

  • マルチブラウザのテストがしたい
    • でも最初に辛い思いはしたくない
      • 開発時にphantomjsを利用
    • chrome -> firefoxと展開
    • 開発中はphantomjs -> chromeでも動くようにする -> firefox、、、とやっていったほうが良い
      • IEはやるな
  • クラウド上のブラウザでやりたい
    • sauce labs
  • GebConfigの書き換え(Driverの生成処理の変更)で実現でき、対応が楽
    • Selenideも似たようなことができる
      • Configと起動引数のどちらかが使える

ちょっとQA

  • phantomjsが早い?
    • phantomjsのほうが早かった経験はまだ無い
    • chromeのほうが早かった…
    • seleniumって本物のブラウザを操作していることがウリ
      • phantomjsは偽物だから、使うなっていう話がある
  • seleniumはE2Eテストなんだからユーザが使う本物のブラウザを使いなさい

Selenide or Geb

外的要因

  • groovyが使えるか
  • 知名度/利用実績
    • 実績はある
    • Selenideは弱い
  • 商用サポートの有無
    • Selenideは日本語ではないが、商用サポートがある
      • 今は問合せベースなので、サポートプランが具体的にあるわけじゃない
    • gebはまったくない

読むか書くか

  • 記述量/記述性どちらを優先させるか
    • Gebは記述量が少ない
    • Selenideは記述性(IDEの保管)が良い

学習コスト

  • SelenideはIDEのちからを借りやすく、所見でもある程度かける
  • Gebは相対的に習得コストは高め。ただし機能は豊富なのでなれると手放せない

テスティングフレームワーク

  • Spockが使える
  • SelenideはJUnit/TestNG
  • データ駆動などをするならSpockが優位
  • Junit5は両方対応している

さくっと動かす

  • 対話環境
  • Gebはgroovysh

まとめ

  • コンテクストはさまざま
    • その時時で良し悪しは変わる

感想

  • 学習コストの低さという意味ではSelenideのほうが導入しやすそう
  • jQueryライクということなので、どちらを使うにしてもそこは勉強すべきか
  • QAコストを下げるために導入したとしても今度はメンテナンスコストが発生する
    • ただし、シナリオが変わればテストケースも変更が入るのだからそこは相殺な気がする
    • ただ、シナリオをコードに落とし込むところが時間がかかりそう
      • エクセルでテストケース書くのに比べたらそれすらも楽しい気はする

Aapache Camel + howtio + Spring Bootによるモダンなインテグレーション・マイクロサービス

howtio

  • 「ほーとあいおー」と読むらしい

AGENDA

  1. インテグレーションマイクロサービス
  2. Apache Camelとは
  3. インテグレーションマイクロサービスの作り方
  4. howtioによるモニタリング

インテグレーションマイクロサービス

  • 賢いエンドポイント単純なパイプ(Smart endpoints and dumb pipes)
    • マイクロサービスの中に連携するためのロジックが入り込んでくる
    • 連携するためのプロトコルにはhttpやメッセージキューイングなどのパイプ役をライトウェイトな技術をを使っていく
  • SOAはEnterpriseService Busと言われるプロセスが間に入って、各サービスを統合する
  • MSAでは各サービスの中にルーティングのロジックが入ってる
    • 他のサービスをいろいろ叩いて一つのサービスを提供するようなものを出て来る
      • そういうのを指してインテグレーションマイクロサービスと呼んでいる
      • SOAではインテグレーションスパゲッティと揶揄されてアンチテーゼだった流れからESB導入された
        • 揺り戻しっぽい
  • MSAを推し進めると各サービスが十分小さくなり、それを担当するチームなら十分複雑さに立ち向かえるだろうという流れがありそう

Apache Camel

  • 軽量なインテグレーションフレームワーク
    • camel-core.jar 4.8M
  • 直感的なルーティングDSL
    • 流れるようなインターフェース
  • Enterprise Integration Patterns
  • 軽量だが汎用性も高い
  • 280+の接続コンポーネント
    • まだ日本で流行ってないようなものでも既に公式サポートされてたりする
  • GUI開発環境(Eclipse)
  • マイクロサービスのサポート

Camelでできることの例

  1. Http/RESTで受け取ったリクエストをTwitterにツイートする
  2. SOAPで受け取ったリクエストをKafkaへ流す
  3. ActiveMQから受け取ったJMSメッセージを、データの内容に応じて

Java DSL

  • RouteBuilderを継承してconfigure()メソッドをoverrideする
  • fromは一つ、toは複数書ける
  • ルートの定義は、fromから始まるメソッドチェーンをまた書けば良い。
  • 別のクラスを書いてもよい
  • ALT JAVAでもOK
  • Spring XML DSL
    • の中に定義する
    • Eclipse pluginはこの形式しかサポートしてないのでGUIで書きたいならこれ一択

Enterpise Integration Patternsをサポートしてる

  • システム間連携のベストプラクティス
  • 65のパターン
例えばCONTENT-BASED ROUTER
  • choice/whenで条件分岐できる

280+のコンポーネント

  • 殆どの物があるので見つかると思う

ECLIPSE プラグイン

インテグレーションマイクロサービスの作り方

CAMEL Spring Boot

  1. Spring Bootプロジェクトを作成
  2. CamelコンポーネントStarterを依存に追加
  3. @ComponentをつけたCamelルートを定義

ComponentをつけたCamelルートを定義

  • RouteBuilderをかいて@Componentをつければよい
  • xmlでやるときは@ImportResourceで。

howtioによるモニタリング

JVMの監視といえば

howtio

howtio x Spring Boot

  • 依存に追加するだけ

Demo

  • Camelのサポートが充実している
  • グラフィカルにルートを見ることができる

QA

  • 単体テストのサポートはどんなふうになってる?
    • あるよ。CamelTestSupport
  • 失敗談や落とし穴は?
    • コンポーネント毎に癖がある
      • 認証コードをどうやって渡すかとか、そこが超えなきゃいけないハードルではある

感想

  • パイプとなるprotocolを強く意識せずに透過的に扱えそう
    • 調べる価値がある ‐ちゃんとCamelのサポートが熱い監視ライブラリの紹介があったのがとてもgoodだと思った

DDD x CQRS - コマンドとクエリでORMを使い分けた話

  • 既に資料があがってるので細かいメモは割愛

  • CQRSはイベントソーシングとセットだと誤解されている?

    • CQRSは単独でも使えるよ
  • twitterで質問受付

感想

  • モデルが参照に引っ張られるって話は、「そうだよね!」って思った
    • 参照にモデルが引っ張られてるな‐と思ったらCRQS(チックな)パターンを導入してみようと思う

劇的改善 CI4時間から5分へ〜私がやった10のこと〜

スライド

対象のアプリ

  • Spring Boot / Web APIアプリ
  • Controller -> Service -> Repository
  • 主にRDBへ接続してデータを取得
  • CIで主に実行していたのはビルドとテスト

テストクラスの責務の明確化

  • 層をまたいだテスト、クラスを結合したテストは禁止
    • クラス単位のテスト
  • ただし、RDBへのアクセス(SQL含む)は業務上十分にテストすべき
    • Repository -> RDBはまとめてテスト

Controllerテストのアノテーション変更

  • こんな感じの表があった
@SpringBootTest @WebMvcTest
概要 Spring applicationを起動してテストする Spring MVC infrastructureをAuto-configurerdしてテストする
bean 全てのBean @Controller,@ControllerAdvice,@JsonComponent, Filter,WebMvcCOnfigurer,HandlerMethodArgumentResolver
テスト時間 Webサーバまで起動するため非常に遅い Spring MVCに必要なBeanしか登録されないため早い
類似 - @JsonTest, @DataJpaTest, @JdbcTest ... etc

ServiceテストでDIを使わない

  • Service層はアプリケーション外とのやり取りがないようにする
    • Springを使わない、シンプルなJunitテスト
    • 依存しているオブジェクトはMock

RepositoryはfilterによるBean選択

  • @MyBatisTestで必要なBeanのみを登録できるようになった
  • 必要ならBeanをフィルタリングする必要はあると思う

負債となったテストの改善

  • テストはある程度の規模の開発では爆発的に増える。結果、負債となる。
    • ひとつひとつ潰すしかないよ

テストの削除

  • 時にはテスト自体を削除する決断も必要
    • 不安定
    • 保守しにくい
    • テスト責務が広すぎる
    • 過度なもの

CIの再構築&並列テスト環境の構築

  • 性能が良くない社内サーバからWAWSへ(性能&安定性UP)
  • ジョブ数に応じて、AMIからNodeを自動生成するようにして自動でスケール
  • RDS内部でスキーマを切り、Node毎に別の仮想DBを用意
  • テストの並列実行が可能に

テストサイズの導入

  • こんな感じの表があった
Small Medium Large
時間的目標(メソッドごと) 100ms未満で実行 1s未満で実行 出来る限り高速に実行
ネットワーク モック localhostのみ
データベース モック
他システムへのアクセス モック 非推奨
実行タイミング プルリクエストごと ベースブランチにマージ 任意、またはリリース毎に
  • JUnitの@Categoryとmaven-surefire-pluginのgroupsで実現
  • mvnのprofileで切り替える
$ mvn -P Small
$ mvn -P Mediam
$ mvn

プルリクエストFeedBack

  • プルリクエスト単位でCIの結果をフィードバックできるようにした
    • Lintの指摘(lint-review)
    • カバレッジの可視化(CodeCov)
    • 負債の指摘(SonarQube)
    • チーム独自のルール(Danger)

感想

  • テストサイズという概念を知ることができてよかった
    • 普段テスト書くときにモックするかどうか悩んだりするけど、自分がどのサイズのテストを書きたいと思っているのかで判断してもいいかも

Spring Securityにできること・できないこと

感想

  • とても良くまとまっていて自身の知識の整理になった
  • Spring Securityが具体的に何に対してよしなにやってくれてるのか把握してなかったが、そこが明確化された
  • opengl 8080さんのQiitaの存在をしれたことも良かった
    • いろいろなことをよくまとめてあるので、眺めると勉強になりそう

入社してから運用しているサービスの運用改善奮闘記

感想

  • The Twelve-Factor Appという言葉をしれたことが良かった
  • frontend maven pluginなるもののgradle版はあるのか疑問
    • あとで調べてみる
  • guageが良さそう
    • 部品をエンジニアは書くけど、それを組み合わせたシナリオを日本語で非エンジニアにシナリオ書いてもらえたりする
      • それでも抵抗はあるだろうけど、非エンジニアにテスト参加させられる
    • まだベータなのが残念

Spring BootとKafkaでCQRSなアプリを動かしてみる

CQRS

  • Command and Query Responsibility Segregation
    • コマンドクエリ責務分離
    • named by Greg Young
    • だいたいマーチン・ファウラーがかかわってる
  • コマンドとクエリを別のオブジェクトに分ける
  • 更新するやつはvoid、クエリは副作用無いようにする
    • クラスを分ける
  • コマンドとクエリを分けるという点だけがCQRSの定義

今日のお話

  • 業務で使いたいことを勉強してることを発表

今日のゴール

  • CQRS面白そうっておもらいたい

第1話:僕とDDD

DDDの印象

  • 依存関係を切り離して複雑さを閉じ込めているっぽい

境界づけられたコンテキスト

  • コンテキストを切り離す

ドメインモデル

  • DBやUIに関係することを切り離す

集約

まとめ

  • 複雑さを凝縮

感想

  • DBからの開放、最高
  • UIからの開放、むずい
    • 複数の集約を繋いだ情報が必要だったり
    • 集約から導出した値で検索が必要だったり

第2話:CQRS

  • 書き込みも参照も一つのモデルにとらわれる必要がない!
  • DB分けても良いし
  • Query側にはDomain Modelを置かないという方法も取れる
  • 書き込み用のモデルが参照のモデルに引っ張られてたな、というのはある
  • クエリからの開放!

第3話:僕とDomain Event

  • コンテキストや集約を切り離したら、これまでトランザクションで繋いでた情報をどうやって伝えよう?
  • 何かが実際に起こった、という事実をモデル化
    • CoffeeOrdered
    • CoffeeBrewed
    • CoffeeDelivered
  • 発生したイベントを受け取って情報を更新していく
  • 内部の動きを想像するんじゃなくて起きた事象をベースにするとビジネスの人とでも会話できそう

第4話:僕とEvent sourcing

  • 状態自体を書き換えるのはステートソーシング
    • きっとみんながやってる方法
  • イベントの積み重ねによって今の状態があるという考え方がイベントソーシング
  • でもこれやるとクエリ困る
    • ここでCRQSが出てくる
  • イベントストアにイベントを入れてき、そのイベントを拾って今の状態を持つデータベースを持つ

A Decade of DDD, CQRS, Event Sourcing

  • CQRSはEvent SourcingへのStepping-Stone
  • CQRS/Event Sourcingを全体に適用しない
  • いろんな実現方法が合って良い
  • 複雑なので実現にはコストがかかる
    • 必要な箇所だけに局所的に適用していったほうが良さそう

CQRSとEvent Sourcingはセットなの?

  • 共生関係にはあるけど、別々の考え
  • 組み合わせると2PCなくて良さそう

第5話:僕とCQRS

  • 似たようなことやってる
    • クエリ油のDB
    • レポート用のテーブル
    • サーチは別のシステム
  • トリガーはさまざま
    • DBに保存するときに頑張る
    • 定期実行のバッチ
    • APIを呼び出したり
  • それもいいね
  • ドメインイベント駆動型でもやってみたい

第6話:CQRSとKafkaとSpring Boot

Messagin System

  • kafka
    • 過去の分も残ってるのがなんかいいなって。

感想

  • domaはDDDと親和性が低いかと思っていたが、コマンドとクエリを分ける方法なら逆に親和性が高そう
  • 2PCを回避する方法って何かないかな

CPUからみたG1GC

感想

  • 難しくて正直ついていけなかったが、よくわからない(デフォルトだから)G1GCにしとこうという安易な考えは危険だってことだけはわかりました。

以上。

2017 Java One 報告会に行ってきた

2017 Java One 報告会

行ってきました。

後半疲れてメモが取れていませんが、 雑なものでも助かる人はいるかもしれないのでメモを残します。


リリースモデルの変更

従来

  • OpenJDK
    • 仕様のリファレンス実装で、Oracle JDKと技術的な差がある
  • 機能リリース

    • 2年に1度を目標にしていた
      • 守れた例がない
    • Oracle JDKのバイナリで配布
      • 後継バージョンのリリース後1年無償サポート
  • 長期サポート

  • 更新リリース
    • 3ヶ月毎
    • メンテナンス用、機能更新は行われない

新しいリリースモデル

  • OpenJDK

    • Oracle JDKとの技術的な差分をなくなる(2018年後半)
  • 機能リリース

    • 6ヶ月に一度、固定周期でリリース
    • バージョン表記:$YEAR.$MONTH (18.3,18.9)
    • 完成した機能からリリース
    • Open JDKのバイナリで配布
      • 後継バージョンまでの6ヶ月の無償サポート
      • GPlv2 + Vlasspath Exception
  • 長期サポート
    • 2018/9からスタート
    • Oracle JDKのバイナリで配布(有償)
    • 8(5+3)年の長期サポート
  • 更新リリース
    • 3ヶ月毎
    • メンテナンス用、機能更新は行われない

公式アップデート終了のスケジュール

  • 8
    • 2018/9終了
  • 9
    • 2018/3終了
  • 18.3
    • 2018/9終了

Java 9 and Future

今日のお話

  • Java 9の調べ方
  • Java 9のメイン機能について少し詳しく
  • 次のJavaをちら見

Java 9の調べ方

移行する際に注意するポイントは?

より細かく見る

  • SpecificagtionやRelease Noteを読む

メリットの一部

  • モジュール化(Project Jigsaw)
  • RPEL(Jshell)
  • ライブラリ改善
    • Collection 初期化、Stream機能拡張
  • セキュリティ強化
    • ALPN,DRBG,SHA-3
  • 付属ツールの刷新
    • jcmd, jhsdb, jaot(AoT Comppilation)
  • G1 GCコンパイラなどの性能改善

Demo

Jigsaw

  • module名のディレクトリを切って、module-info.javaを書く
    • 同じpublicでも、module-info.javaで公開するしないをきめ細やかに指定できる感じか
    • 依存関係を書くイメージ
  • publicだけど公開されていないAPIを利用しようとするとコンパイル時に検知して、エラーで教えてくれる
  • 依存moduleをmodule-info.javaに書き忘れると、importしてるけどmoduleをmodule-info.javaにdeclareしてないよって教えてくれるよ
  • DDDに有効活用できそう
  • デモの内容はgithubにあるよ

jshell

  • Java言語のRead Eval Print Loop(REPL)ツール
    • like LIST, Python, Ruby, Haskell, Scala, Groovy
    • Java言語のプログラムの一部を入力
    • その場で実行し結果を出力
  • 教育分野ではREPLツールがある環境が人気

    • REPLがないので、Javaの人気の低下
  • 補完機能が協力

    • import
    • 変数定義

Collection Factories

  • List.of(...)
    • Arrays.asList(...)
  • Set.of(...)
    • Collections.unmodifiableSet(new hashSet<>(Arrays.asList(...)))
  • Map.of(...)
    • new hashMap<>(){{put(...);...}}
Properties of Collection Factories
  • imutableになってる
  • フェイルセーフ
    • NPE
    • IAE: Set,Map(key)に重複する要素
  • 最適化されている
Enhancement Stream API
  • Stream.dropWhile
  • Stream.takeWhile
    • 無限loopに終了条件を与えることができる
  • Stream.ofNullable
  • Stream.iterate
    • ほぼfor文

18.3のチラ見

  • Project Amber
    • 型推論が入る
    • 変数の型推論でvarが使えるようになる
    • すごく良さそう!!

Intel's persistent memory

  • 揮発性じゃないメモリ、電源が切れてもデータが保存されてる
  • 市場に出るのが2018
  • Oracle Databaseで使えるように

Oracle DB + PM

  • だいたい5倍早くなった

使いみち

  • Volatile Strage
    • 普通の使い方ではある
      1. Heapを全部のせる
        • メモリアクセス速度<大容量
          • 優先度がひくい
          • BigData application
          • in-memory db
        • 使い方
          • javaコマンドの引数に入れる
      2. heapを一部のせる
        • ユーザが割り当てを指定
        • プロファイリング結句ぉ元に自動で割り当て、移動
        • アクセス頻度が高く、小さい→DRAM
        • アクセス頻度が低く、でかい→PM
        • xmpオプションを追加するxmxとかみたいな感じで。
  • Persistent Strage

まとめ

  • OSS DBが出てくるのはまだまだになりそう

Java EE 8

概要

Java EE 8

source

Glassfish

  • 5.0が出た
  • ほぼ4.1.2の機能はサポートしてる
  • Java 8はサポートできてる
  • Java 9はGlass fish 5.1.0からサポートするつもり
  • Dockerイメージあるよ

Weblogic

  • Java EE 8サポート版は来年出す予定になってる

Eclipse Enterprise for Java(EE4J)

  • 以下にしたい
    • 8 available
    • open
    • nimble
  • eclipseに移管
  • 移管プロジェクトの名前がEE4J
    • Java EEの後がまではない(ブランド名は決まってない)
    • もしかしたらそのままEE4Jになるかもしれないけど、現時点でそうとは決まってない

どうありたいか

  • Open
    • たくさんのひとに参加してもらいたい
    • コミュニティドリブンなプロセスを作っていきたい
    • oracleはリーダーの立ち位置ではなくメンバーに変わる
  • Comppatible
    • 互換性
    • transition from java ee 8 to new offering
    • javaxパッケージはそのまま移管するのでご完成はある
    • 新規で作るのはeclipseの流儀で作る
    • 今まであったものはそのまま使えるよ、新しいものはEclipseのやり方に変わるよ
  • Flexible
    • Modern open source process and licensing
  • Nimble
    • Morerapid evoution of the technology
    • リリースサイクルを早くする、仕様作成プロセスとかも。

その他

  • Micro Profileと(Next) Java EEはマージする予定
  • JSRのやり方は踏襲する

まとめ

  • Java EE 8 was released.
  • EE4J has started.

Microservices topic & approach

ゴール

  • いってみてわかったこ
  • 今、全体的に何が議論されているのか

行ってみてわかったこ

  • 10月のサンフランシスコはホテルは高い(普段の2〜3倍)
  • 会場近くのホテルはすぐ埋まるし、高い
  • 疲れたらすぐ戻れるように会場近くがよし
    • 長丁場で、体力勝負

なるべく疲れないようにする

  • 16時間の時差、慣れない環境で5日間は体力勝負
  • きつければ、適宜休むこと
  • 割と寒い
  • 移動はUberが楽

必ずセッションは事前登録

  • 優先で入れる
  • 未登録の場合は、並んで空いてたら入れる

技術系・資料ありセッションはわかりやすい

  • 技術系のお話や資料に沿って解説は英語でもわかる
  • 資料がタイトル程度だったりパネルディスカッション系はしんどい

Microserviesの話題や取り組み事例

モノリスからMiroservicesへ

  • まずモノリスだった
  • サービスの拡大によりスケールする必要に
  • Microservicesアーキテクチャ
  • 組織と文化もそれに合わせてかわった
  • 数年かけて継続していて、なお続く

組織、文化

  • システムのスケールに合わせて組織のスケール
  • コンウェイの法則
    • 組織のコミュニケーション構造がシステムに反映
    • 逆法則も(Service間コミュニケーションの形が組織に反映)
  • Automy(自主・自立性)を何より重視
    • Squad(分隊)と呼ぶチームにメンバーが所属
    • 独立リリース可能な状態を維持する、破壊的な変更はちゃんと手続きを経る
      • 同期型APIならエンドポイントの移行期間を設ける
      • 非同期型を同期型よりも推奨

Microservicesをとりまく仕組みについて

  • CI/CD
    • 小さく、頻繁にデプロイする
  • Container, Orchestration
    • Docker,kubernetesが常に登場
  • Service Registry
    • Serviceのホスト名・ポート番号を名前で抽象化
  • Asynchronous
    • 可能な限り同期より非同期
  • Fault Tolerant
    • 一部のエラーで全体が影響を受けないように
  • Monitoring
    • 現状がどうなっているかを可視化する
  • Tracing

議論の対象の変化

  • FrameworkやLibraryは自前で開発したりラッピングするものではない
  • それらはConsumeするもの
  • 議論の対象はServiceという部品をどう協調動作させるか?になっている

同期 < 非同期

データ処理パターン

Eventual Consistency(結果整合性)
  • 異なるデータストア間の内容の整合性がEcentual Consistencyでも良い場合は非同期連携で各データストアに反映すれば良いため、相性が良い
Event sourcing
  • データストアをイベント記録に使う
  • insertのみし、updateはしない
  • ひたすらログを取っていくやり方
CQRS
  • 更新用のStrageと参照用のStrageは別だったりもする
    • 更新用のStrageからEvent sourcingで参照用のStrageに現状のデータを反映する?
複数ServiceにまたがったTransaction
  • Long running action

考察

必要性を考える

  • スケーラビリティやリリースの速度アップの必要性に迫られてそうなった
  • どこでもスモールスタートだった、そしてMicroserviceを想定していない
  • 必要に迫られてるか?を自問したほうが良い

組織や文化とセットで考える

トレードオフも考える

以上! Java 9の話が特に勉強になりました。 パッケージの一つ上の階層としてモジュールって概念が登場して設計の選択肢が広がるのかなって思ったの一番強く残った印象です。