「「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～」の批判

こちらのエントリに違和感があったのでちょっと書いてみたいと思います。

PHP Mentors -> 「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～

SalesOrder（受注）クラスの導入について

上記のコードが問題を含んでいる原因は、このコードが「値引きは数量のみに基づいて行われる」という知識を適切に隠蔽していないことにあるわけです。

本来は、値引き判定のロジックをどのオブジェクトに配するかを決めるにあたって、どのような知識を隠蔽すべきか、あるいは裏返して言えば、どのような知識は開示して構わないかという点に思いをめぐらすべきでした。

値引き条件などというものは、ビジネス上の都合により変更されやすいものです。このケースのように注文数量だけで値引き可否が決まるというケースもあるかもしれませんが、発注金額も考慮し、あるいは発注者が上得意かどうかも判断要素に含める、というように変更されるかもしれません。一方で、注文数量・金額・発注者が誰かなども含む受注内容に応じて値引き可否が決まる、という点はたぶん変わらないだろうと考えられます。

であれば、このケースで開示してよい知識と隠蔽したい知識とは以下のようになるでしょう：

開示してよい知識

受注ごとにその内容に応じて値引き可否が決まるという知識。

隠蔽したい知識

注文数量・金額等にもとづく具体的な値引き決定ルール。

これを踏まえれば、isDiscountable()は、Quantityクラスにではなく、呼び出し元であるamount()メソッドを含むSalesOrder（受注）といったクラスのメソッドであるべきだということになります

PHP Mentors -> 「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～

「現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法」のP.37ページのサンプルについて、こちらのブログのエントリでは情報隠蔽が適切でないからSalesOrder（受注）クラスを導入して情報隠蔽を適切にすべきだという流れになっています。

しかし、SalesOrder（受注）は一体どこからやってきたのでしょうか。「という点はたぶん変わらないだろうと考えられます。」と書かれているところからエントリを書かれた方の想像と考えられます。「現場で役立つシステム設計の原則」の方でもP.37ページの付近には「受注」という言葉がでてきません。割引という言葉が出てきているので受注も必然的にとついつい考えてしまいますが、明らかになっていない概念になります。なので、このサンプルの世界ではまだ受注というものがないと考えられます。

そうなるとSalesOrderクラスを導入することで値引きに関するロジックが隠蔽されるかもしれませんが、存在していないSalesOrderに関する知識を持たなければならないことになります。これでは過剰な設計になってしまいます。

ですので、P.37ページの時点では「値引きは数量のみに基づいて行われる」ということがコードで表現できていれば妥当である考えられます。

実務では想像による先取りは避けるべきでしょう。もっとドメインを確定させて同意を得てからでも遅くないはずです。同意が得られているのであれば話は変わってくるので、SalesOrder（受注）も良い案かもしれません。

なので、このエントリも「受注」という概念があると仮定してということであれば違う形で納得できるのかもしれません。

「ルール信奉の落とし穴」のところについて

こちらも気になったので。

しかも実践者である著者ご自身、たぶん本ケースを、良くない設計の例と見ておられない。ルールに従ってパズルを解くとそれだけで達成感が得られるので、ルールを超える視点は頭の隅に追いやられてしまうという傾向が生じるのかもしれません。

「ルールを超える視点は頭の隅に追いやられてしまうという傾向が生じる」といったところはその人の能力の問題でしょう。ルールや原則が現在の業務に対応できるか否かをしっかりと判断するのがエンジニアの仕事であると思います。

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

｢JJUG_CCC_2017_Spring」へ行ってきた

• タイトル: JJUG CCC 2017 Spring
• 日時: 2017-05-20（土）9:30 - 18:30
• 会場: ベルサール新宿グランド コンファレンスセンター（5F）
• URL: http://www.java-users.jp/ccc2017spring/
• 資料: TBD

「JJUG CCC 2017 Spring」へ行ったので参加レポート書きます。

今回のCCCもとても充実していた。同時に開催されるセッション数が最大8もあるので、選択肢は多いし内容もバラエティに富んでいる。公式サイトによるとCCCは20回目を迎えたらしく、順調に成長している感もあるし、参加者も1,000人を超えていてまだまだ成長しそうな勢いがある。

個人的にはJava SE 8あたりがリリースされたあたりから徐々にJavaに人が戻ってきたかんじがする。その戻ってきた感じのところにJJUG CCCがしっかりはまっているのではと思う。

セッションのラインナップとしてはJava SE 9がまだ正式リリースされないので9関連はまだ多くない。Spirng Boot関連が複数あり相変わらず人気。コードの書き方系も複数あって勉強になるし人気だった。その他にもscalaやらAndroidやら豊富で偏ってないのもよかった。

1,000人を超えて会場のキャパ問題があるようだが狭いのはしかたない気がする。ただ立ち見や入れないなどを極力なくすってことかな。人気がそれほどなかったときのCCCも知っているので、ここまで盛り上げてきた現会長や幹事さんたちを信じて次回の改善を期待するのみ。

以降は各セッションごとのまとめ

非機能要件とSpring Boot

• 梅澤 雄一郎 さん
• https://speakerdeck.com/garbagetown/jjug-ccc-2017-spring-ccc-g1

非機能要件のおさらいからSpring Boot ActuatorやSpring Securityでそれらをどう実装していくかというお話。

非機能要件のおさらいの部分はわかりやすくてとてもよい復習になった。ActuatorとSecurityの話は個人的にドンピシャな内容なのでありがたかった。Actuatorの拡張するポイントやSecurityの使い方なんかがつかめた気がする。

Spring Securityは設定が大変なイメージがあるけど、昨今のセキュリティ検査を通すにはCSRFなどを自作していく方が遥かに大変なので、寄り添う必要はあるなあって思った。

メモ

• 非機能要件
  • 「マイクロサービスアーキテクチャ」では機能横断要件といっている
    • まあ確かにAOPなんかで実装できる部分もある
  • IPAの非機能要求グレードが参考になる
    • http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html
• Actuator
  • 1.5からSSHは非推奨
  • ポートで入り口を縛る
  • atuditevent
    • 認証認可のイベントログ
  • info
    • デフォルトでは何も表示されない
    • application.propertiesなどで設定できる
  • エンドポイントを自作可能
    • CustomeEndpointクラス
  • エンドポイントの拡張も可能
• Security
  • パスワードポリシーにはPassyが使える
  • アカウントロック
    • @EventListenerでイベントをハンドリングできるので、そのときに回数をカウントする
  • パスワードハッシュ化
    • SHAではなく、Bcrypt Scryptを使う。
  • 接続情報の暗号化
    • jasyptが使える
  • セッションIDの書き換え、CSRFなどはSpring Securityに備わっている
  • TymeleafではデフォルトでXSS対策される

Javaエンジニアに知って欲しいRDBアンチパターン

• soudai soneさん
• http://soudai.hatenablog.com/entry/jjug_ccc

RDBアンチパターンのお話。曽根さんの熱さが伝わってきて思わず引き込まれた。「データベースの寿命はアプリケーションよりも長い」「DBが停止するとサービスが止まる」は今後もかみしめていきたいと思った（とりあえずでテーブル設計しないようにする）。

メモ

• データベースの寿命はアプリより長い
• アンチパターンを知り同じ過ちを繰り返さない
• データベースの迷宮
  • 名前がデタラメでは困る
    • コードではデータの中身が見られないから要注意
  • リレーショナルモデルに基づいた設計をしていないとツールが使えなくなる
    • ちゃんとリレーションを張っておけばテーブル図等自動生成できる
  • データにロジックを埋め込まない
  • 処方箋としてはリファクタリングをし続けること
• 強すぎる制約
  • 例
    • トリガーが多くのテーブルに影響を与える
    • ストアドがロジック持ちすぎ
    • マテビューやDB Linkの多用しすぎ
  • 処方箋
    • その機能を利用する期間を検討する
      • 一時的？一生？
    • その機能を影響範囲を理解する
• 監視されないデータベース
  • 監視は3段階ある
    • いち早く障害発生を確認する（死活監視）
    • 復旧のための原因を確認する（チェック監視）
    • 状況の変化を時系列で監視して、障害の予兆を把握する（モニタリング監視）
  • インフラは生き物、日々の成長記録を見る。
  • 処方箋
    • しっかりモニタリングする

Introduction of Project Jigsaw

• 櫻庭 祐一 さん
• https://www.slideshare.net/skrb/introduction-of-project-jigsaw

Java SE 9のJigsawの話。櫻庭さんの話は背景なんかもしっかり話してくれるのでわかりやすい。Jigsaw自体の背景やモジュールの作り方やなどはそろそろわかってきたのであとは実際どうなることやらやってみてベストプラクティスを探すことになる。Mavenはどう対応されるかとかも今後だろう。

あとJCPにおけるJigsawが否決された状況が聞けて勉強になった。IBMやRedhatの反対って状況だけはわかっていたが、なるほどAutomatic Moduleの件が大きいのか…。

メモ

• Jigsawの背景
  • jar hellの問題
  • バージョンのゴチャゴチャとか
  • 本当に必要なjarがわからない
  • publicがpublicすぎて、少しパッケージを超えたいだけでも全部に公開されてしまうなど。
• モジュールの導入
  • module-info.javaがあったらモジュールとなる
    • これによりjarは今までのjarとモジュールのjarで2種類になる
  • requiresで依存するモジュールを記述
  • exportsで公開するパッケージを記述
  • public ≠ accessibleとなるので、これまでリフレクションを利用している場合は要注意。
    • JDKのライブラリにも一部使えなくなるモノが出てくる
  • モジュールじゃないライブラリ
    • Automaticモジュールで扱える予定
    • そのときjarファイル名をモジュール名として扱うみたいな話が否決におけるポイント。
      • そんなんでいいの？
    • 修正案としてマニフェストファイルに書くが提案されそう。
      • これが通れば…

VMの歩む道。Dalvik、ART、そしてJava VM

• yy_yank さん
• https://www.slideshare.net/yyyank/vm-dalvikartjava-vm

JavaVMとアンドロイド（Dalvik/ART）の話。アンドロイドのVMについては個人的にさっぱりだったのでそれらの違いがまとまっていって良かった。やっぱりアンドロイドはHotSpotからみるとだいぶ違うなぁ。

メモ

• Dalvik/ARTはJLSは満たしているようだが、JVMSを満たしていない。
  • 標準ライブラリなども違う
• マシン命令も違う
  • HotSpotはスタックマシン
  • Dalvik/ARTはレジスタマシン
• バイナリ形式も違う
  • HotSpotはクラスファイル
  • Dalvik/ARTはdexファイル
• JIT or AOTも違う
  • HotSpotはJIT/Interpreter
  • DalvikはJIT/Interpreter
  • ARTはAOT
    • JIT/Interpreterも選べる（Android7からAOT+JIT）
• プラットフォームを優先した結果独自VMとして別々の道を歩んでいる

SQLアンチパターン

Seaser2終了から学ぶフレームワークとの付き合いかた

Seasar2が終わってしまって、フレームワークとどう付き合うべきなのかなど思うところがあったのでまとめました。

2016年9月26日に終わりを迎えた

この日Seaser2が正式にメンテナンスおよびサポートが終了になった（ただし「DBFlute」「Doma」「Mayaa」など続いているプロジェクトはある。詳しくは公式サイトを参照 → http://www.seasar.org/ ）。

この発表自体に驚きはなかった。その1年前から終わる告知みたいなものはされていたし、もっと前から積極的な新規開発は行われていなかった。なので数年前から徐々に使わなくなっていたし、そんな雰囲気は感じていた。

当時はそれがよい選択だった

心情的にはさみしさと感謝がある。私はSeaser2が流行っていたころに20代中盤で、数々のプロジェクトでお世話になったからだ。

Seaser2が流行っていた頃はStrutsによってフレームワークやOSSという概念が浸透してきた時期で、プロジェクトでどのフレームワークを選ぶのかが一つの大きな関心事だった。「Seaser2」「Struts」「Spring」あたりが有力な選択肢だったと思うが、その中でも「Seaser2」は人気だった。

国産であったことが人気の一番の理由だったと思う。日本語資料の充実などは国産ならではで、MLも中心は日本語だったのでなんかあったらすぐに直してくれそうという考えもあった。なんだかんだ安心感は大きかった。もちろんプロダクト自体もよかった。DIコンテナやAOPなど先端のモノは含まれていたし、個人的にはS2Daoはとても使いやすかった。

フレームワークの選定は難しい

ここでSeasar2を選択したことについてふりかえると、当時、2016年頃終わるかなぁと予想できた人はいなかっただろうし、文句なんか出なかった、妥当だと思えた。これが例えば今だったら「おいおい」ということになる。

継続されるフレームワークを選べなかったという点で言えば、結果的にはSeasar2を間違えであった。ただそれは予想しきれない部分も多いことなので、結果論でしかない気がする。新規開発が停滞してきたあたりに察するぐらいしかなかったのだと思う。

ただ、ここまでの規模感のSeasar2が終わる可能性があるということを真剣には考えていなかった気がする。そんな雰囲気もなかった。

こう考えて行くと、継続されるフレームワークを選ばなければいけないということが無理な話かもしれない。同じフレームワークでも下位互換が確保されないバージョンアップがされる可能性もある。なので選択自体に重きをおくより、フレームワークもいざとなったら切り替えるという覚悟が必要かも知れない。

フレームワークを含めたメンテが必要。それができないプロジェクトはアップデートしないことを覚悟させるor自分たちで直す。

こうなるとSeaser2資産が心配になるが、みんなどうしているのだろうか。私のように数年前から徐々に離れていったのだろうか。全社をあげて使っていくと宣言していた会社もあったような…。

基本的な考え方としては流行りのフレームワークであっても何らかの理由で終わることはある。終わらないにしても実質的に死んでしまっているような状態になってしまうことがある。なので、フレーワークを含めてメンテし続けてプロジェクトを運用していくのが正論なのだろう。

Seasar2ぐらいの規模感であっても終わるのだから、数年単位でフレームワークごと見直す機会を設けるべきなのだろう。予算は前もって確保しておきたい。フレームワーク変更なんて表向きに変化が現れないやっかいな作業だが、やるときはやらないとしょうがない。それがなんとかできるプロジェクトはそうとう必要とされているプロジェクトということ。

Webのフレームワークなんてもはや開発やメンテがいらないと思われるかも知れないがそんなことない。セキュリティ系のメンテは必要だし、スマホやクラウドなど新しいモノは出てくるわけだからそれに対応した新機能はやっぱり必要。

それができないプロジェクトは実質使わなくなったものになっているか、アップデートされないことを覚悟させなくてはいけないってことかな。いやいや、OSSの基本に立ち返って自身でメンテや開発するもの一つの選択肢。ソースは公開されているのだから。

Javaフレームワーク開発入門

「Illuminated Keyboard K740」は最高の有線パンタグラフキーボード

職業柄とてつもなく長い時間PCを使うことになるので、キーボードはいろいろこだわってきたつもりで、最近たどり着いたのが「Illuminated Keyboard K740」になります。今回はそのレビューを書きます。

LOGICOOL イルミネートキーボード K740

レビュー

• （USB接続の）有線であること
  • 電波状況の悪さや電池の残量を一切気にしなくていい
  • 線が邪魔に思えるが、机が整っていれば１本ぐらいであればそんなに気にならない
• パンタグラフ式であること
  • これは好みかもしれませんが、メンブレン式より打感が低いのが楽
  • ノーパソはほとんどパンタグラフなので、それとも相性がいい
• パームレスト付き
  • これは意外とうれしい。手首が楽。
• キー配列
  • 大きなクセもなく問題ない
• 価格もそこまで高くない
  • 執筆時の相場（2017年4月現在）で8,000円ぐらい
• イルミネーション
  • あってもなくてもいい。そんなに暗い場所で作業しないので…。

有線のパンタグラフとしてはいままでで一番いいと思っています。

有線がいいとかパンタグラフがいいとかは好みの部分が大きいですが、やはり電波や電池のことは気を使いたくないので有線でパンタグラフを選んでしまいます。その中でも「Illuminated Keyboard K740」がベスト。

パームレストがついていることをはじめとして、長く使っていても疲れにくい工夫がされているところが感覚的に使いやすいことにつながっているのかなあと思います。うまく表現しづらいですが全体の総合点がとても高いです。キー配列も申し分ないので最近は手放せなくなっていて自宅と職場で使っています。

イルミネーションはあってもなくてもいいかな。そんなにくらい場所で作業することはあまりないので、まあ暗がりで光るのが最初は面白いですが…。

LOGICOOL イルミネートキーボード K740

プログラムコメントはもっと書かないべき

「プログラムコメントはたくさん書くべき」の方が一般的かもしれませんが、リスクも考えましょう。この記事はプログラムコメントを極力書かないようにしている私のスタンスをまとめてみました。

プログラムコメントのリスクを考えると、書かない方がいい

私はプログラムコメントがリスクの方が高くあまり意味が無いと思うようになってから、なるべく書かないようにしている。例えば次のようなリスクがある。

• コメントがメンテされず、コードと乖離してしまう
• 書くこともないのにやっつけで書いてしまいただのノイズになる

｢コメントがメンテされず、コードと乖離してしまう｣については、他人の作成したコードを改修作業したことがある人なら理解できると思うが、コードを改修するとしてもそのコメントの方が改修しづらい。今行っている改修がこのコメントにどう影響しているのかが判断しづらいので、コメントは放っておきたくなる。そんなことを重ねていると、コメントとコードが乖離してしまってとても困った状況になっていく。

また｢ 書くこともないのにやっつけで書いてしまいただのノイズになる｣もよくある。プロジェクトの決まり事でとりあえずかくとこんな感じになる。

/**
 * 口座クラス
 */
public class Account {
    …
}

クラス名をみればわかることをわざわざ日本語にしても仕方ない。ほんとにこれだけなら書かない方がいいのに、決まりだから書いたりすることがある。

このように考えていくと、プログラムコメントはとてもリスクが高くて意味の無いことが多いことに気がつく。

プログラミングでコメント機能を最初に教わるときに、こういったリスクの説明をおそらくされない。むしろ講師の人は｢コメントはなるべく書きましょう｣という言い方をする方が多い。それをずっと引きずる人が多いので、コメントをたくさん書きましょうという風潮になっている気がする。ただよく考えると、そんなにウェルカムなものでもない。リスクを考えるべきである。

コメントを書くより｢コードを直す｣を優先すべき

私はコメントを書きたくなってしまったら｢コードを直す｣ことを考えるようにしている。

コメントを書こうとしているときは｢このコードでは他の人に伝わらないかもしれない｣と考えているということなので、根本としてはコードが悪い状態なはず。なのでコメントに頼らないコードにすることを第1に考える。これはその状況になったときだけ考えるのではなく、常日頃から考えているし、考えておかないといけない。

コメントを書くぐらいだったら、ドキュメントを書く

コメントでは直近のコードの説明以外にも、全体像の説明であったり仕様の説明であったりを書きたくなることがある。ただこれはそもそもコメントに書くべき事ではない。ドキュメントにすべきことである。

ただドキュメントにしたところで、ドキュメントがメンテされないとコードと乖離してコメントと同じ問題を抱えてしまう。私はこの問題を｢ドキュメントはそのとき（作成時時点）の考えのスナップショットとする｣という考え方で対処している。時間が経ちすぎていれば参考にしないし、必要な物は何度も作り直すので、更新される。本当に更新され続けるのはほんの一部にしておけば、負担も少ない。

とはいえ、コメントを書くことはある

ここまでの書いたとおり私はコメントを極力書かないようにしているが、次の場合はコメントを書くことがある。

• 言語の勉強

新しい言語や久しぶりに使う言語の場合はコメントを書きながら勉強することがあるし、ブログなどでコードを説明する場合には使う。

コメントを極力書かないスタンスの人が、どの場面はコメントを書くべきかはまだ研究中。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

「APIって全部覚えるの？」というプログラミング初心者の疑問にちゃんと答える

プログラミング講師をやっていた時期あり、そのころ聞かれた疑問をちゃんと答えてみたくなったのでまとめました。プログラミングをこれから始めますという人向けです。

A.「APIを全部覚えようとしてはいけません」

理由を上げるとすると次の2つ。 - 全部覚えられるモノではないので、全部を覚えている人はいない - 実際に使うモノは限られるので、全部を覚えようとしてはいけない

まずそもそも全部覚えることは不可能です。数が信じられないぐらい多いからです。例えばJava SE 8のAPIリファレンス(こちら→http://docs.oracle.com/javase/jp/8/docs/api/)を見ていただければわかりますが、覚えようとすると途方に暮れるレベルです。クラス名だけでも無理でしょう。これがある期間でアップデートされたり追加されたりするので無理なはなしです。

それに、実際に使う範囲はかなり限られます。というより標準APIなどは相当広い範囲をカバーしたいという考えがあるためかなりの汎用性を持たせています。ただそれが、使う側にとってはどうしても関係ないAPIになります。毎日プログラミングをやっていても一生使いそうにないなというAPIが山ほどあります。また使う側の側も毎日プロジェクトを移り変わるなんてことがないので、そのプロジェクトで扱わなければやはり使わないAPIになっていきます。ということを考慮するとかなり限られた範囲しか使わないので、全部を覚える必要はないということになります。

どんなAPI（クラス・メソッド・関数など）があるのかをなんとなく把握して、実際に使う時には調べる

実際には、こういうかんじです。

｢使う時には調べる｣とサラッと書きましたが重要です。まずは公式のリファレンスをしっかり見られるようして、確認するクセをつけましょう。人の記憶は曖昧なので使ったことあるものでも自信が無ければ必ず調べるようにした方がいいでしょう。学校の学力テストをやっているわけではないので、わからなかったらその場で調べればいいのです。

書籍の解説書などもいくつか机においておきたいところです。公式リファレンスも慣れていないとわかりにくい場合などあるので、書籍やWebなんかも頼っていきましょう。ただし、書籍やWebなどは書かれている文脈が違って通用しなかったり、間違えもあったりするので公式のリファレンスや実際に動かしてみて確認はするようにするのが原則です（書籍やWebの内容が間違っていても責任はとってくれません）。

また、全く存在すら知らなければさすがに使えるようになることにはならないのでなんとなく把握する必要はあります。初心者であれば入門書に出てくるようなクラスはなんとなくおさえるところからスタートしましょう。経験を重ねるごとに把握するクラス数は増えるし、必要になりそうなクラスもわかってきます。暇なときにリファレンスをうろうろするのもオススメです。いろいろな発見があって面白いです(人によりますが)。さらに実際にサンプルなど動かしておくと記憶に残りやすくなります。経験を積み上げた人であればバージョンが上がったときにリリースノートなどを確認して変更点をしっかり把握しておきます。

｢JJUG CCC 2016 Fall｣へ行った その2

• タイトル: JJUG CCC 2016 Fall
• 日時: 2016-12-03（土）10:00 - 22:00
• 会場: ベルサール新宿グランド
• URL: http://www.java-users.jp/ccc2016fall/
• 資料: https://github.com/jjug-ccc/slides-articles-2016fall

先日参加したのでまとめを書きます。個人的に注目だった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システムのクラウド化が困難な理由
• アプリケーションサーバー
• アプリケーションのクラウド化
• バックエンド対応