ひょんな事からJava版Sparkをいじる機会があって、JavaRDDのmapメソッドにラムダ式を渡したら通るのにメソッド参照を渡したら実行時に例外が発生するという事態にぶち当たった。
これはラムダ式とメソッド参照の挙動の違いを発見か？！と思ったが、結果的にはEclipseのバグだった。
で、そのバグを再現する最小限のプログラムを作ろうとしたら、別の挙動（これもEclipseのバグ）に当たってしまった。
（前者はメソッド参照のシリアライズに関するEclipse新バージョンのバグで、後者は旧バージョンのバグ。バグを修正したら新しいバグが生まれてしまった感じに見える＾＾；）
これに関連して、ashigeruさんからメソッド参照のキャプチャーに関する話を聞いたが、これは知らなかった。知らないとハマることがありそう。
『現場で役立つシステム設計の原則』が話題になっていたので、（流し読み程度だけど）読んでみた。
基本的にはJavaがベースで、前半（というか最初の2章くらい）はコーディングレベルの話、残りはオブジェクト指向ベースの設計方法の話。
あ、ちなみに自分は最近はAsakusa Frameworkというバッチフレームワークを使う仕事が多いのでバッチ寄りの考え方で読んでいるけど、本書は基本的にウェブ寄り（Spring Framework）の思想っぽい。
コーディングレベルの話はとても納得。Javaでプログラミングする人は全員これを確認しておくべきという感じ。
（とても細かいレベルの事を言うと、if文の処理部分は波括弧で囲んだ方が（余計なバグが入る余地を減らせるので）いいと思う。ただ、書籍なので、行数を減らすために波括弧で囲んでいないのかもしれない）
（p.60でenumの列挙子が小文字なのはJavaの慣習からすると違和感がある。ただ、これもそういうコーディング規約だというなら、それでいいかも）
p.32の値を扱うための専用クラスを作る話とかは、理想はその通りだと思うんだよね～。java.timeなんかはそういう思想っぽいし。
ただ、Javaだとそのクラスを使った演算とか書くのが面倒なんだよねorz（c = a.plus(b)みたいな）
Scalaだと+等の記号を使った演算子が定義できるけど、実行速度はプリミティブ型よりは落ちる気がするし…。
（こういうのが得意なプログラミング言語はそろそろ有りそうな気はするけど、聞いた事は無いな…）
p.75の「データクラスが広く使われているのはなぜか」では、StrutsやJ2EEを真っ向からdisっていて、すげー！って感じ(笑)
後半からは設計に関する話になっていく。
クラス設計だけではなく、DBのテーブル設計や画面設計、Rest APIの話題まである。
ただ、この辺りから自分の常識とは違う内容が多くなってきて、戸惑う。
ただ単に自分の頭が固くなって受け入れられないだけなのか。別の人の評価を聞いてみたいところ。
p.137の「用語集が育っていく」という話は超同意。
初めて入るプロジェクトでは、まず用語集を確認するし。（と言っても、用語集が作られているプロジェクトなんてほぼ皆無だけど(苦笑)）
そして、プロジェクトが進んで業務理解が深まってくると、用語もきちんと分かってきて、メソッド名とかクラス名とかシェル名を直したくなる(爆)
（余談だけど、AsakusaFWでは、処理（フロー）の為のメソッドをvocabulary（語彙）と呼ぶ。これは業務用語を意味し、「フロー上は業務用語を使って処理を記述する」という思想の表れだと思う）
6章のデータベースの設計は、一番戸惑いが多い。
本来なら、理解できない所ほどちゃんと読むべきなんだけど、流し読みしかしてないせいか＾＾；
p.183の取り消しデータの作成って、履歴系のテーブルならそうかもしれないけど、マスター系もそれだと、最新の情報を取得するのが面倒になるのでは？ プライマリキーにも履歴項目が増えそうだし。
p.184のカラムの追加はテーブルの追加でって、恐ろしいな＾＾；
パフォーマンスの悪影響は大きそうだし、そのテーブルを使うアプリケーションの修正もカラム追加より大きくなるのでは？
虚データを入れないようにするという事自体はとても正しいと思う。本来は追加したカラムに移行データとして何らかの値を入れるべきで、ただ、そう出来ないケースの事を考えているのだと思うけど。追加したカラムのnullチェックの代わりにテーブルの有無チェックが入るだけだろうから、全般的に利点があまり感じられないっす。
自分はDBのテーブルもオブジェクト指向のクラスと同様に「責務」があると思っていて、本来その責務の範疇のカラムなのに、値が無いかもしれないから別テーブルとする、というのは、どうかなーと思う。
p.186のUPDATEを使わずDELETE/INSERTにするというのも、最初はえーっ！と思ったけど。
DBMSによってはパフォーマンスが違うだろうし、DBMSによってはUPSERT（MERGE文）という構文があったりするし。
ただ、よく考えてみると、AsakusaFWだとDBアクセスはDELETE/INSERTが基本なんだよね。
というかバッチなので、テーブルから全対象データをバルクリード（SELECT）し、処理をメモリー（あるいはシンプルなファイル）上でまとめて行い、結果をバルクロード（DELETE/INSERT）する。
本書はたぶんウェブ想定なので、プライマリキー毎にDELETE/INSERTであって、AskusaFWの使い方とは違うだろうけど。
とかくDBアクセスはボトルネックになりやすいので、自分としては、どうしてもパフォーマンスのことが先に来てしまう＾＾；
パフォーマンスのことを気にしないなら、表面上はオブジェクト指向のクラスに載せて、いくらでも綺麗にコーディングできるんだよねぇ。（そしてN+1問題とか発生するorz）
（AsakusaFWを使うようになってからは、DBアクセスは最初と最後のバルク処理だけ済むので、とても楽になったｗ）
7章の画面（ウェブ）で印象的だったのは、p.215 HTMLのclass属性の値を決めるのがドメインオブジェクトだ、というところ。
画面を作る責務を担うオブジェクト、だったらHTMLの内容をいくら持っていても全く違和感ないんだけど、そういう事なのかな？
8章のアプリケーション連携では、Rest APIについても触れられていた。
Rest APIはあまり携わった事が無いんで何とも言えないんだけど、p.259の日付の話はダウトな気がする。
そもそもRest APIは人間が見るものではない（JSONだから見ようと思えば見られるけどさ）と思うので、日付は世界標準の形式で出力した方が良いのではないかと思う。
（人間が見られる形に変換するのは、Rest APIでデータを取得した側の責務では？）
少なくとも、年月日であればタイムゾーンは関係ないというのは、違うんじゃないかなぁ。（日本でしか使わないRest APIなら、それでいいのかもしれないけど）
9章の開発プロセス、p.276のソースを第一級のドキュメントとして活用する話は、下手すると物議を醸しそうですなぁｗ
（自分も『設計書は必要』ってブログを書いた事があるしな～ｗ）
実際、顧客に見せる/同意を取る為のドキュメントを除けば、基本的にはソースとソースの説明書（ソースで表現しきれない部分を補う）があれば事足りる、というか、楽だよねぇ。
本書では打ち合わせでホワイトボードに書いた内容は写真で撮っておけばいいじゃんみたいな感じっぽいので（たぶん語弊有り＾＾；）、そういう面まで含めて考えているのかなぁ？
（ちなみに、今の自分の仕事ではホワイトボードの写真を見せられることが結構あるんだけど、写真だけで説明が無いと、その打ち合わせに出ていなかった人には伝わらない事の方が多いですよorz）
以上、なかなか刺激的な本なので、ぜひ他の人の感想を聞きたいｗ
2017年4～6月期のアニメの感想。
今期は粒揃いというか、見るのが楽しみなものがとても多かった。
特にSFが多かったのが嬉しい。
SFは、現実と異なる法則があって、それがある事によるメリット、デメリット（および、それに伴う人物たちの葛藤）、最終的にどう解決するか、というのが上手いと面白い。これに謎解きと意外性があれば完璧。
あと、再放送で『ノーゲーム・ノーライフ』をやってたけど、これ本当に良いよなぁ。特に10番目の盟約最高！
昔途中から見た記憶があるんだけど、今回最初から見られて良かった。最近全然映画館に行ってないけど、これの映画は見たいなぁ。
