nekoTheShadow’s diary

IT業界の片隅でひっそり生きるシステムエンジニアです(´・ω・`)

『Oracleの基本: データベース入門から設計/運用の初歩まで 』(技術評論社)

Oracleの基本 ~データベース入門から設計/運用の初歩まで

Oracleの基本 ~データベース入門から設計/運用の初歩まで

Oracle Databaseの存在はもちろん知っているし、利用したこともある。ただ"利用したことがある"といっても、インフラエンジニアがインストールしてくれたものを使うだけで、利用するのはもっぱらSQL Developer。管理運用はまるっとDBAならびに運用オペレータにお任せ--というのが、この本を読んだときのわたしのスペックでした。要するに「Oracleに触ったことがある」という程度の人間だったのですが、何の因果なのか、新しく入ったプロジェクトで、Oracleを含むミドルウェアのローカル開発環境構築要員に抜擢(´;ω;`)ウゥゥ 割かれた工数もかなり少なめということもあって、Oracle Databaseについて突貫で勉強する必要があり、本書を手に取ったのでした。

本番環境や大規模な運用になると、本書だと物足りないのかもしれませんが、ローカルPCに開発環境を構築する程度であれば、本書で十分すぎるほど。Oracle Databaseに関して最低限知っておくべき知識が過不足なく簡潔に、かつわかりやすくまとめられており、初めてOracle Databaseに触るという人はもちろんのこと、「Oracleをなんとなくで使ってきた」「その場その場のGoogle力で乗り切ってきた」というわたしのような人間にとっても知識を体系的に整理できるよい機会でした。ちなみに自分が構築したのはOracle 18cでした。本書はOracle 12c対応となっていますが、18cでもちゃんと通用する内容になっています。もしバージョン違いで買うことをためらっている人がいるなら、迷わずGO!

本書のおかげでOracleの基礎的な知識を身に着けることができ、ローカル開発環境の構築と手順書の作成を無事終えることができました。感謝! まあそのプロジェクトはなくなったけどね(´・ω・`)

柚月裕子『凶犬の眼』(角川書店)が面白かった

少し前に読んだ『孤狼の血』が面白かったので、その続編である本作を読んだのですが、読みごたえがあって面白かったです。GW帰省の新幹線の車中で一気に読み切ってしまった(´・ω・`)

孤狼の血 (角川文庫)

孤狼の血 (角川文庫)

孤狼の血』は実在のやくざ組織や事件を参考にしたと思われる個所は存在するものの、全体としては映画『県警対組織暴力』や『仁義なき戦い』を下敷きにしていました。両映画、とりわけ『仁義なき戦い』は実在の抗争事件をもとにした映画なので、そういう意味では『孤狼の血』は実際の広島抗争をもとにしているといえなくはないのですが、作品全体の雰囲気としては"実録"感はうすめ。あくまで映画・フィクションのオマージュ感が強い一方、本作はかなり"実録"感は強い印象でした。ありていにいうと、本作はいわゆる山一抗争、および、そのさなかに発生した四代目山口組組長射殺事件が元ねたです。とりわけ国光寛郎という人物。彼は作品中の最重要人物なのですが、このモデルはあきらかに一和会系の有力組織の組長で、四代目山口組組長と若頭を射殺した、とある人物です(あいまいな書き方ですが、山一抗争を多少知っている人であれば、すぐわかるほどの超有名人)。そのほかにも登場するやくざのモデルが明らかすぎるほどだったり、ディティールを彩る事件が実際に山一抗争で発生したものとうりふたつであったりと、現実の山一抗争をかなりにおわせる書き方をしています。誤解をおそれずにいうと、本作の完全なるフィクション部分を除けば、『実話時代』のような実話雑誌に掲載されている実録小説と内実はほとんど変わりません。それほどまでに"実録"色が色濃く出ています。

山一抗争は戦後最大の暴力団抗争、もしかするとやくざ史上最大の暴力団抗争で、民間人を含む多数の死傷者を出し、挙句の果てには山口組の組長と若頭までが同時に殺されるという、まさに「血で血を洗う」というにふさわしい戦争でした。しかし抗争を振り返ってみると、繰り返し述べている四代目山口組組長射殺事件を除くと、終始山口組が一和会を圧倒しており、「弱いものが智謀と度胸をふるって、強いものを倒す」というような映画的カタルシスはほとんどありません。確かに規模は史上最大であり、また部分部分を見れば刺激的なトピックもあるのですが、全体を通してみれば「強い奴が勝つ」という現実的で面白みに欠けるのが山一抗争です。これをどのようにしてエンターテイメント小説とするのか。それも敗軍である一和会側の人物を主軸に添えるとなると、かなり難易度が上がりますが、本作はそれを軽々超えていました。しかも、基本ラインは『孤狼の血』と一緒。『孤狼の血』は「一癖もふた癖もある人物に感化されて、青年が成長していく」というホモソーシャル的なビルドゥングスロマンが主軸でしたが、本作でもそうした構造は取り入れられており、作者の物語作者としての手腕を強く感じました。

このてのやくざものは本作で打ち止めというようなことを作者は述べているようですが(媒体失念)、もっと書いてくれないかしらん(´・ω・`)

曽根壮大『失敗から学ぶRDBの正しい歩き方』(技術評論社) を読んだ。

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

Twitterのタイムラインで話題になっていたので読みました(ミーハー)が、とても良い本でした。「失敗から学ぶ」「RDB」とタイトルにある通り、本書はRDBSQLに関するアンチパターン集で、1章に1個の割合で、合計20個のアンチパターンが紹介されています。「RDBSQLに関するアンチパターン」というと『SQLアンチパターン』という名著があり、本書でもたびたび言及されています。正直なところをいうと、重複している部分もあるのですが、『SQLアンチパターン』はどちらかといえばDBやテーブルの設計に関する記述が多かったのに対し、本書はDBの運用やアプリケーションとの連携といった部分にまで話が及んでおり、『SQLアンチパターン』と比べると、話題のスコープが広いように感じました。

SQLアンチパターン

SQLアンチパターン

タイトルに関連して述べておくと、表紙には大きく「MySQLPostgreSQLの設計・運用を見直す」とありますが、基本的には特定のRDBMSに限定されない記述になっています。「どういう設定をすればよいのか」「どこを確認すればよいのか」など、具体的な部分でMySQLPostgreSQLを例示している部分はありますが、そこはある程度読み流してしまっても、本書の価値を大きく損なわないと思います。事実、こう書いているわたし自身、MySQLPostgreSQLを本番環境で使ったことがありません……。SIer勤務だとどうしても商用DBが中心になるんや(´・ω・`)

個人的に本書を読んでいて感心したのは、各アンチパターンを紹介する前に「そのアンチパターンを採用すると、どういう場面で困るのか」をストーリー形式で示していること。「XXXはアンチパターンなのでやめましょう」するにあたって、そのアンチパターンがもたらすデメリットが具体的に述べられていれば述べられているほど、その主張は説得的になりますし、読者も自分事のように感じて、まじめに読むようになるはずです。また「どういう場面で困るのか」を示したストーリーですが、目を閉じれば情景が浮かんできそうなほど「あるある」な内容になっています。わたしも似たような場面を経験したことがちらほら……。そうした「あるある」なストーリーを描くことができるということは、筆者のRDBに関する経験の豊かさや造詣の深さをうかがわせており、これも本書の説得力を増強していると思いました。

個人的な経験で申し訳ないのですが、DBやテーブルについて奇妙な設計をしてしまっても、開発自体は意外と何とかなったりします。ただし運用は死ぬ。また本書でも言及されていますが、アプリケーションに比べるとデータはずっと長生きで、「新しいシステムを作ったが、データは古いシステムから引き継いで使う」という話はよく聞きます。要はテーブルやDBやSQL関連の考慮不足が問題として爆発するまでにはタイムラグがあって、開発者はその遠い未来の爆発が起きないような手法を身に着ける必要があります。その点で、本書は量も手ごろに、アンチパターンとその対策が説得的にまとめられていると感じました。

『エンジニアリング組織論への招待: 不確実性に向き合う思考と組織のリファクタリング』を読んだ。

「エンジニアリング組織論の招待」というタイトルを見たとき「どこぞの企業の偉い人が自分の武勇伝に基づいた『俺の考えた最強の組織』を披露するのか」という邪推をしたくなるかもしれない。本書は残念ながらそういう本ではない。仮にそのような本であれば、タイトルは「エンジニアリング組織への招待」とするはずだ。つまり「論」が抜けるはずで、本書は「論への招待」であることに着目する必要がある。

副題は「不確実性に向き合う思考と組織のリファクタリング」で、本書を手に取ったときはこれを次のように区切るものだと思っていた: 「不確実性に向き合う思考/と/組織のリファクタリング」。これだと意識高めの自己啓発と「俺の考えた最強の組織」の紹介で終始する本のように感じられるが、本書を読んでいく中で、この副題はこう区切るのが正しいということがわかった:「不確実性に向き合う/思考と組織の/リファクタリング」。すなわち本書は「不確実性に向き合う」ために「思考と組織」を「リファクタリング」する方法論が示された1冊である。

プログラマにはおなじみの概念だが、リファクタリングとは「外部仕様を変更しないで、内部実装を変更し、処理効率を高めたり、保守性を向上させたりする」ことをいう。大事なのは「外部仕様を変更しない」というところで、ではエンジニアリング組織の外部仕様とは何だろうか? あるいはエンジニアリング組織に所属するソフトウェア・エンジニアの外部仕様とは何か? これに明快に答えることは難しいが、本書はひとつの答えを提示している。すなわち「不確実性に向き合う」ということである。すなわち、このでのリファクタリングとは、外部仕様をより効率的に達成するために「思考や組織」をブラッシュアップしていく行為であり、本書はそのブラシュアップに役立つさまざまな手法を紹介している。

もっとも「さまざまな手法を提示している」といっても、たとえば筆者の経験談や武勇伝はまったくといっていいほど紹介されない。さまざまな手法はそこかしこのプラクティスやメソトロジーから引っ張られてきており、経験談や武勇伝に比べると、読んでいて納得感がある。また一般論ばかりが陳列されているというわけでもない。紹介される方法論は有名なものから、さほど知られていないものまでさまざまだが、そのすべてがさまざまな企業で実践されていたり、社会科学的な研究に裏付けられていたりすることが明らかなものである。「論」を紹介するといっても、なんでもかんでも紹介すればよいというものではない。その「論」はそれ自体で説得的な裏付けを有している必要があり、そうした正統性を有した「論」を中心に話を組み立てているからこそ、本書は強い説得力を得ているのである。


ここからは本書の感想というよりは現役SIマンの愚痴に近いのだが、本書が対象にしているような領域はSI系のプロジェクトでは一般に「管理工数」として人月計算に計上される。管理工数というのは見た目にわかりづらいというか、KPIにしづらいというか、少なくとも直接何かを生み出しているわけではないため、たとえばプロジェクトが炎上した場合、管理工数はまっさきに削減の対象になる。しかしもとをただしてみれば、なぜプロジェクトが炎上したのかを考えてみると、多くの場合、それは管理不行き届きである。ただでさえ管理が行き届いていないのに、くわえて管理工数を削減するとなると、炎上がひどくなるだけである。

ただここには重大な示唆が含まれていて、それは「管理」という行為の見えづらさである。本書の内容にやや即すると「組織や思考がよくなったということをどうやって判断するのか」ということである。たとえばKPIやチェックシートのような形で、組織や思考のリファクタリング具合を常日頃からトラッキングしておき、上昇傾向なら採用している手法を継続すべきだし、逆に下降気味なら別の手段を試してみるなどの対策が必要になる。本書はこの部分がややあいまい、というよりそもそも本書が語るべき領域ではないのだが、SIだとこれがシビアに求められるケースがあり、つらい場合がある--というお話でした(´・ω・`)

細川義洋『なぜ、システム開発は必ずモメるのか?: 49のトラブルから学ぶプロジェクト管理術』(日本実業出版社)

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

「どのようにしてプロジェクトをうまく進めるのか」に関する手法やメソトロジーは世間にさまざまあって、たとえばPMBOKなどはその王道であるし、システムの保守運用フェイズであればITILも有名である。アジャイルスクラムエクストリームプログラミングなどもそれぞれ焦点は違えど、極言すればプロジェクト運営のための方法論だといってよい。

ところで日本のIT業界の保守本流はいわゆるSIであり、わたしもその末席に名前を連ねているが、そうした世界では上記であげたような手法が必ずしも有効活用されているわけではないと感じている。現場のSE、なかでもPMは忙しすぎて、そうした知識を学ぶ時間がないから--というのは冗談。日本のSI業界が特殊--というのは言い過ぎだが、プロジェクトマネジメント系の手法の大半は外国生まれ外国育ちで、それを四角四面に日本のSIプロジェクトに適用するのが難しい場合があるのは確かだと思う。

本書がよいところは視点が極めて日本的というか、日本的商慣習のもと実施されるシステム開発プロジェクトにおいて、はまりやすいポイントが適切に解説されているところにあると思う。とりわけ対顧客折衝や下請け管理など、THE JAPANESE SIにおいて重要とされ、ゆえにおうおうにして火薬庫になりやすいポイントについて、その原因と対策をここまで簡潔に書き出されている書籍は珍しいのではないか?

また筆者が裁判所の調停員のようなことをやっているらしく、その関係で「こういうトラブルのときに裁判所はどのように判断するのか」という視点が盛り込まれているのも本書の長所のひとつである。システム開発プロジェクト炎上の究極系は裁判であり、いってしまえばSIerとしてはトラブったとしても、この裁判に勝ちさえすればよい。裁判所の判断というのは、国家権力という極限の実行力を有した判断基準であり、それに従いつつ仕事を進めていくのは悪いことではないと思う。

本書は小説形式、というよりはネットスラングでいうところのSS形式を採用していて、読みやすいといえば読みやすい。ただキャラクタ類型がやや古いというか、正直なところ「10年ぐらい前の感覚で書いているな」という感想を持ってしまった。物語作品としてまじめに読もうとすると厳しい面はある。そこは本作の大事な部分ではないし、もとがSIのトラブルとその対策集をSS化するという無茶をやっているわけで、まあ許容範囲ではある。

Scala挫折しそう

ここ数年、毎年新しい言語をひとつは学ぶという習慣を続けています。2018年はC#コンパイラの出来がよいのか、雑に書いてもそこそこの性能が出るし、なによりLINQが書いていて気持ちいい。またLINQの存在を知ったあとで、JavaのStream APIをあらためて勉強しなおしてみると、こちらはこちらでなかなかよくできていることに気づくなど、たいへん勉強になりました。これからもC#で遊んでいこうと思います。

さて2018年も年の瀬。来年学ぶべき言語を考え始める時期でもあります。そこでここ1か月は予行演習として、前々から関心があったScalaに触れていたのですが、そうそうに挫折しそう、というか多分挫折すると思います(´・ω・`)

①挫折の最大原因がIntelliJ IDEA。ネットの記事や入門書によると、Scalaを書くにはIntelliJ IDEAが最適、というよりそれ以外の選択肢はほぼないらしい。ならばと使ってみたところ、自分のPCとの相性が悪いのか、自分の使い方が悪いのか、妙にもっさりしていて、コード補完がうまくきかなかったり、コンパイルエラーの検出ができなかったりと、ストレスがたまることが多い。ショートカットや見た目のフィーリングが妙に気に食わない、無償版とはいえ商用製品をただで使うのは気が引けるなども、IntelliJ IDEAから遠ざかる要因になっています。なおPluginを導入すればEclipseでもよいそうですが、自分の環境ではろくに動きませんでした(そのPluginがもともとあまり安定していないらしい)。

②あとは些末なところで、Scalaの文法が自分の好みに合わないというのも挫折の理由にあったりなかったり。

  • Listの添字アクセスが[]ではなく()
    • VBAと同じですが、VBAにトラウマがあるので、それを思い出してつらい(´;ω;`)ウゥゥ
    • []は別の用途で利用されるのだが、これはこれは違和感がぬぐえない。
  • やたらに記号を多用するスタイルで、書くのも読むのも慣れないと厳しそう。少なくともググラビリティは低い。
    • 無名関数ではプレースホルダが使えるのだが、その記号が_。ほかの言語だと変数名_は"無視"を意味することが多いので、違和感がある。
    • :+とか+++とか、ほかのプログラミング言語だとあまり見慣れない記号が妙に出現する。
    • 同じ記号に違う意味がありすぎて、覚えきれる自信がない。
  • def methodName() = {}=はいらなくない? =は束縛の意味なのかなあ?

ここに挙げたのは一部で、ほかにもいくつあるのですが、ただこうした違和感は学習期間が短いゆえの現象、要するに「慣れてないだけ」。とはいえ、ひとたび違和感を持ってしまうとそれをぬぐうのはなかなか難しいのも現実ではあります。

③まあこれは覚悟していたことではあるのですが、Scalaは学習コストが高く、はやくもわたしのIQではついていけなさそうな雰囲気を醸し出しています。1か月触れた程度ではあるのですが、それでもimplicitや型クラスなどなど、抽象度が高い概念がぽんぽん出現し、このペースで難しい概念が現れるとなると、ついていけるのかがとても心配になります。


Scalaからは戦略的撤退を決めるとして、ではどの言語を勉強すべきか。そもそもScalaを選んだ要因のひとつがJVM系言語に興味があったからでした。Scala以外のJVM系言語となると、Groovy/Kotolin/Clojureあたりかしらん。Groovyはグルー言語としての用途はよく聞くのですが、アプリケーション構築にどれだけ利用されているのかわからないので、パス。KotolinはAndroidに関心が薄いのと、前述したようにIntelliJ IDEAがだめ。となると消去法的にClojureが最有力候補になりますね……。ただLISP系ということぐらいしかわかっていないので、環境構築とか入門書とか、周辺の情報を集めることが先ですね。過去にSchemeに取り組んだことがあって、LISP系の文法には抵抗ないので、そこは無問題。ただ万が一はまってしまうと、通常世界にかえってこれなさそうな感じがする(LISPプログラマに対する偏見)。

JVMにこだわらずともPHPPerlでもいいですし、昨今の動向を考えるとフロントエンドに取り組むのもありのような気がします。個人的にはとりわけCSSに苦手意識があって、なんとなくフロントエンドからは逃げ回ってきたのですが、最近はそうもいっていられない雰囲気があり、迷うところではあります。また言語ではなく、何かしらのフレームワークを学ぶ選択肢も考えています。ちなみに学ぶとすればRuby on RailsかSpring Bootですね。ただフレームワークを学ぶとなると、何かしらのアプリケーションを作成することになるのですが、どう頭をひねってみても、特別作りたいものがない。よさげなハンズオンを探してみようかしら。

なかなか迷いは尽きないですね(´・ω・`)

Joshua Bloch『Effective Java 第3版』(丸善出版)を読んだ。

Effective Java 第3版

Effective Java 第3版

Javaプログラマの必携書として名高い『Effective Java』の新版である第3版の日本語訳が発売されたということで、さっそく買って読みました。第2版は2008年出版で、Java6を対象としていましたが、それ以降もJavaにはさまざまな機能が追加されてきました。『Effective Java』はいわば「Javaプログラミングのベストプラクティス集」といった位置づけですが、Java6以降に追加された機能の中には、その"ベストプラクティス"のありようをかえてしまったものもあります。第3版は原則として第2版の内容を踏襲しつつ、そうしたJavaの進化に伴って一部修正&大幅追加するというスタンスのもと執筆された--と個人的には理解しました。

Javaプログラマであれば読まないという選択肢はない、というと過言ですが、少なくとも読んで損はない内容であると思います。ジュニアプログラマにとっては新しい知識の源泉であり、シニアプログラマにとっては、ふだん無意識的・経験的に実践しているテクニックを整理して言語化するきっかけになるはずです。前述したとおり、第2版とは内容的な重複がかなりあるため、第2版とは違う斬新な内容を期待していると、期待外れということになります。そこだけは注意しましょう。

実は第2版は読んだことがあり、そのときの読書記録をこのブログの記事として残しているのですが、第2版に比べるとフォントのサイズが大きくなって、読みやすくなっているような気がします(勘違いだったらごめんなさい)。また紙の質も第2版よりやや良くなっている、具体的にはより明るい白で、かつ1枚あたりの重さが軽くなっているように思います(これも勘違いだったらすみません)。内容はともかく、物理的な読みやすさは第3版のほうがよかったような。

さて以下は本書を読みながら残していた読書メモ(というか日記)を整理したものになります。よかったらどうぞ。


第2章 オブジェクトの生成と消滅

  • 項目5 資源を直接結び付けるよりも依存性注入を選ぶ
  • 項目8 ファイナライザとクリーナーを避ける
  • 項目9 try-finallyよりもtry-with-resourcesを選ぶ

第2版と比べて、追加・変更があったのはこのあたりかしらん。項目5については「その通り」のひとことで、本書にも書かれてはいますが、依存性の注入を利用すると、手スタビリティが上がるのが個人的には大きい。また項目9も禿同(←古い)で、try-withy-resoucesはぜひ使いましょう。ただ意外にベテランを自称しているプログラマほど知らなかったりする。

Javaプログラマにとってガベージコレクションとは「確実にそこに存在し、機能を果たしているが、いつ・どこで・どのように動いているかはわからない」という、いわば神がかり的な存在です。よってその「神がかり的な」動きに依存するファイナライザを利用すべきではなく、ましてやその存在をコントロールしようとするなど、もってのほか。ちなみにJava9からfinalizerがdeprecateになったのは本書で知りました。

第3章 すべてのオブジェクトに共通のメソッド

Objectに定義されていて、自作クラスでオーバライドする類のメソッドに関する章。この章は本書でいうところの「一般契約」の解説が中心で、「一般契約」はJavaのバージョンが少し上がったぐらいではほとんど変わらないということもあり、第2版とほとんど違いがないように感じました。

Javaプログラマとしては当然知っておくべきですし、わたしも本書(第2版)を読んで知ったのですが、現実のプログラミングではIDEの機能やLombokなどのライブラリで自動生成することが多い。というか、そのほうが安全なので。

第4章 クラスとインターフェイス

この章で第2版から増えたのが「項目21 将来のためにインターフェイスを実装する」。Java8からインターフェイスにデフォルトメソッドを持たせることが可能になりましたが、項目21はそれを注意して利用するよう警告する項目になります。そもそもデフォルトメソッドの導入により、本章全体の記述が第2版とは変更になっているように思えます。デフォルトメソッドのおかげで、抽象クラスや継承それ自体のプレセンスが下がっている--はずですが、Java6のレガシーシステムをお守りしている自分には関係がなかった(´;ω;`)ウゥゥ

ちなみに第2版を見たところ「項目21 戦略を表現するために関数オブジェクトを使用する」が本章からなくなっているようです。これはいうまでもなく無名関数・ラムダに代替されたからでしょう。

第5章 ジェネリクス

現代的なプログラミングにおいて、ジェネリクスを積極活用しない理由はないと考えています。ジェネリクスというとコレクション関係(ex. List<String>)がまず頭に思い浮かぶのですが、メソッド定義の際に利用すると、型安全でかつ柔軟なAPI設計ができるので、機能をよく把握し、積極的に使いたいと思います。ちなみに第2版から増えたのが「項目32 ジェネリクスと可変長引数を注意して組み合わせる」。ここは@SafeVarargsアノテーション周りのお話ですね。

第6章 enumアノテーション

この章は第2版と比べて、大きい変更なしだと思います。第2版が依拠していたJava6と第3版が依拠しているJava9の間で、enumについては大きな機能追加などはなかったのかな。しかしその裏を返せば、機能追加が不要なほど、enumが強力だということ。enumはシンプルな機構に見えて、工夫次第でいろいろ使える便利屋さん。本書でもいくつも紹介されている--というより、わたしは本書を読んでenumの強さを知ったくちです。

アノテーションについては、もう少し記述があってもよいような気がします。現代的なプログラミングでは何かしらのフレームワークを利用することが多いと思いますが、「アノテーションを使わないJavaフレームワークは存在しない」というほど、アノテーションは多用されます。要するに現代Javaプログラミングとアノテーションは切っても切り離せない関係にあるわけで、それだけの重要性を持つにも関わらず、アノテーションについて扱っている項目が3つだけというのは少し寂しい。

第7章 ラムダとストリーム

第2版と第3版でもっとも大きく変わったのはこの章、というよりこの章自体が丸々追加されています。内容はというと以下の通り。

  • 項目42 無名クラスよりラムダを選ぶ
  • 項目43 ラムダよりもメソッド参照を選ぶ
  • 項目44 標準の関数型インターフェースを使う
  • 項目45 ストリームを注意して使う
  • 項目46 ストリームで副作用のない関数を選ぶ
  • 項目47 戻り値型としてStreamよりもCollectionを選ぶ
  • 項目48 ストリームを並列化するときは注意を払う

はっきりいうと、この章についてはさほど意外性がなかった、というか「関数型プログラミングの世界ではごく当たり前に言われていることが書かれているだけ」という印象を持ちました。ただ「Schemeを中心としてLISP系言語に集中的に取り組んだことがある」「関数型言語の影響が強いRubyを数年にわたって書いている」など、関数型プログラミングに親和的なバックボーンがあるために、余計にそういう感想を持ったのかもしれません。一般的なJavaプログラマは手続き型に慣れているはずで、そういう人に関数型のいろはをJavaの世界に落とし込みつつ、整理して紹介することには大きな意味があるはずです。

第8章 メソッド

「項目55 オプショナルを注意して返す」が追加されていますね。戻り値としてオプショナルが返ってきた場合、メソッドを呼び出した側はこれをある種の異常と受け取るわけですが、Javaではそのような異常を示す際には例外を使ってきました。つまりメソッドを設計するにあたって、オプショナルを返すべきか、あるいは例外を投げるべきかは頭の痛い問題です。

第9章 プログラミング一般 / 第10章 例外 / 第11章 並行性

この3章については第2版との間で大きな変更はないように感じます。もっとも変更がなかったからといって、重要度が低いというわけではなく、単に機能的な変更が少なかったからというだけで、大切な内容が含まれています。

  • 第9章: 「プログラミング一般」というタイトルですが、Java特有の内容も一部含まれています。とりわけ他言語からJavaへ移ってきたプログラマ、そもそもプログラミングに触れ始めたばかりの初心者などは読んで損はない内容だと思います。
  • 第10章: 例外の取り扱いはとにかく難題。しかもJavaには検査例外/非検査例外という、ただでさえ論争的な例外の扱いをさらにややこしくする概念が導入されており、とにかく頭が痛い。本書が示している例外の取り扱い方針はJavaの原理原則に基づいたもので、そういう意味ではまっとうな内容であるといえる--のですが、現実のプログラミングでは基本的に非検査例外を使えばよいと思ったり思わなかったり。
  • 第11章: Javaは意外にマルチスレッドプログラミングに関する機能が充実している一方、慣れていないプログラマ(←わたしのこと)が安易に利用して問題を引き起こしがち。この章はJavaにおけるマルチスレッドプログラミングの機能を紹介したものというよりは、マルチスレッドプログラミングにおけるベストプラクティスを整理したもので、かみしめるように読みました。「項目82 スレッド安全性を文章化する」← とくにこれは実践していこうと思います。

第12章 シリアライズ

シリアライズに深くかかわるようなシステムにかかわったことがなく(せいぜいIIOP程度)、本章は字面だけ読んで終わりとしました。ごめんなさい🙇。この章はシリアライズにおける「べき論」を整理したものだと理解しているのですが、個人的にはこの項目を心にとめておこうと思います: 「項目85 Javaシリアライズよりも代替手段を選ぶ」。年季の入ったシステムならともかく、これから構築するようなシステムであれば、インターフェイスJSONXMLCSVでいいよね……だめ?(´・ω・`)