翔泳社セール対象商品(PDF)のうち定番ぽいタイトル11冊
翔泳社さんのセールが8/20までだそうなのですが、某所に書いた「定番ぽいやつ（紙で買ってるけどPDFもついでに買っておくと良いかも的な）リスト」をこちらにもかんたんな説明をつけて書いておきます。
なお、この「定番ぽい」というのは、何年も前から良い本として広くおすすめされてきた本や、これから末永くおすすめされそうな本、ということです。一般に書籍の評価は、賞味期限の長短やターゲットの広さ・狭さとは異なるので、別に広くおすすめされない本でもいい本はありますし、将来はさておき今なら必読、という本もあるわけです。が、それらを並べはじめるときりがないので、ここではそういった本はここでは触れません。
そういう縛りがなければ、例えばカイゼン・ジャーニーシリーズ（という言い方でいいのかな？）やルビィのぼうけんシリーズや技術者の数学書シリーズとかもあるわけで、各自探してみるとよいかと思います。
一方、もっとニッチな内容の本が読みたいとか、最新の情報が欲しいとかいう方のために「技術書典」というイベントがあります。突然ここから宣伝になるのですが、次回技術書典9は来月9月にオンラインにて開催予定で、ただいまサークル参加者を絶賛募集中です。読むだけじゃなくて何か書いてみたい！ という方がいればぜひご応募ください。
さらに技術書典ではスポンサーも絶賛募集中なので、興味があるとか持続化給付金が余ってるという方がいらっしゃればぜひお声がけください。宣伝は以上です。
※ COI開示: 翔泳社さんとは業務での取引がありますが、本件については金銭物品その他のやりとりはありません。
レガシーコード改善ガイド
いかにも定番ですね。自動テストが当たり前とは言えなかった時代に「レガシーコードとはテストのないコードである」と喝破した本です。
とはいえ、別に本書が想定する現場としてはテストが当たり前にあるわけではありません。あくまで「レガシーコード」を改善する本なわけで、状況としてはテストがないところから始まるのです。テストがない、あるいは足りてない、と思うあなたのための本なので、安心して読んでいただけるかと思います（当たり前のようにテストがある開発しかしてない人も、いつかテストのないコードと戦わなければいけなくなった日に備えるべく読んでおくとよいでしょう）。
それでも躊躇してしまう人には「第24章 もうウンザリです。何も改善できません」だけでも読んでいただきたいです。直球ど真ん中すぎる章タイトルですが、ひどい状況であっても著者は投げ出したりTwitterで愚痴ったり転職を煽ったりせず、それでもできるコード改善方法を挙げてくれます。いやまあ投げ出すべき状況もあるかとは思いますが、そうしないで頑張ってみるあなたを応援してくれる本です。
エンタープライズアプリケーションアーキテクチャパターン
PoEAA、あるいはPofEAAと呼ばれる本です。エンタープライズと名前がついてますが、エンタープライズはあまり関係なく、主にサーバとクライアントに分かれる環境では一般的なアプリケーションのアーキテクチャパターンが網羅されている本です。
だいぶ前の本ですし、最近はあまり直接的に言及されることは少なくなった気もするのですが、つい油断すると本書のパターンの名前が一般会話で出てきて困ってしまうこともあるかもしれません（トランザクションスクリプトとかサービスレイヤーとか）。特に後述するDDDとかを読むにあたって、本書を読んでないと理解するのは相当大変だと思います。
翻訳は正直微妙というか、私の持ってる紙の本にもちらほら手書きで修正している跡が残っているのですが、そこは目をつぶって頑張って読んでいただきたいです。そんなことで頑張りたくない…という方は原著を読むという選択肢もあります（セール関係なくてすみません）。
エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう
DDD本です。現在では定番中の定番といってよいでしょう。
ドメイン駆動設計については、なんとなく実装パターン的な扱いをされることも少なくなさそうですが、基本的にはドメインモデルをどう作る（＝モデリングする）か、そしてそれを崩さずにソフトウェアアーキテクチャと対応させるか、という手法だと理解しています。「ドメイン駆動設計」であって「ドメイン駆動開発」ではないのは、偶然ではなく意図的なものだと思ってます。
そのドメイン駆動設計を理解するためには、なにはともあれ本書を読まれると良いかと思います。
実践ドメイン駆動設計
IDDD本、でいいんでしたっけ。DDD本を実践してみる、というタイトルそのままの本です。
設計手法といっても開発に落とし込まないといけないのですが、ドメインモデリングの戦略的設計よりも戦術的設計の設計パターンばかりが知られることによって結局単なる設計・実装手法になっているのでは…？ という問題意識と、DDD本刊行から10年たって時代の変化を反映させたいというところから書かれた本だと理解しています。
実は本書はちゃんと読んでなくて（Javaはほとんど使わないので…）、いくつか実装の参考にした程度なのですが、DDD本だけではよく分からない・ピンとこないという方は本書も合わせて読むといいんではないかと思います。
プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに
SQLとSQLプログラミングを、DBA(DB管理者)視点ではなくプログラマ観点から理解する本です。
個人的にお世話になった本の最新版ということであげておきますが、今なら他にも良い本がありそうではあります。が、安心して読める本が継続して出版（そして翻訳）されることは大変ありがたいことなので挙げておきます。
詳解UNIXプログラミング［第3版］
Unixプログラミングの定番書です。
Unixでシステムコールを叩くプログラムを書く場合や、Unixで動くアプリケーションの運用をする場合には絶対に読んでおくとよい、と言われていた本です。困ったときに本書を読むとちゃんと載っているので読んでおけと言われ、本当かなと思いつつ読んでみたら本当に載っててびっくり、という経験をした人は少なくないのではないでしょうか。
Unixと関わる限り、いざという時のために手元においておきたい本です。
ユースケース駆動開発実践ガイド
この文章を書きながら本書があることに気づきました。ICONIXという開発方法論の本です（手元の本が見つからないので記憶で書いてます）。
開発方法論は現在は受難の時代というか、よい入門書とかも少ないんですよね…。みんなどうやって入門しているんでしょうか。 本書は数少ない生き残りの本なのですが、ICONIXは開発プロセスの中では比較的とっつきやすい（主観です）からかもしれません（たまたま偶然かもしれません）。 いきなりDDDとかでモデリングやるよりは、いったんICONIXとかを試してみてからの方が分かりやすいんではないかと思います。
そういう意味で貴重な本なので、クラス設計（関数寄りだと型設計になるんでしょうか？）とかの良し悪しがわからない、という人はぜひ読んでみるといいかと思います。
組織パターン チームの成長によりアジャイルソフトウェア開発の変革を促す
デザインパターン的なパターン言語を組織やプロジェクトマネジメントにも応用してみた、という本です。
ソフトウェアのパターンじゃないパターン言語はなかなか難しいものが多いような気がするのです（主観です）が、本書はその中でも上手くいっている方ではないかと思います。基本として読んでおくとよいかと思います。
モダン・ソフトウェアエンジニアリング
これは新しい本ですね。あらゆる開発方法論を大統一するEssenceを紹介する本です。
まー、正直言ってEssenceは大変ビミョウというか、記述用言語としてなら開発方法論マニア（？）には便利かもしれないけど現場の役に立つかどうかは怪しいところではあるかなあ…というのが率直な感想です。が、せっかくのIvar Jacobson先生最新の集大成っぽい本ですし、「開発方法論、そしてソフトウェア開発とは何なのか」をメタな視点から見てみるのは、そういう機会がない人には一度はやってみた方がよいかとは思います。そういう意味では読んでみる価値はあります。
イノベーションのジレンマ 増補改訂版
これはソフトウェア開発のみならず、ビジネス書としても大定番ですね。ハードディスク業界の例が出てくるのでソフトウェア開発者の方にも親近感が湧きそう…と思ったけど今どきのソフトウェア開発者はハードディスクとか知らなかったりするんでしょうか…どうなんだろう…というのは置いておいて。
この本のミソは、市谷さん風にいうと「正しいものを正しく作る」にも関わらず失敗する（ことがある）、そしてそれには理由がある（！）、というところですね。事業が失敗していく原因を、作り方が間違えていたとか、作るものが間違えていた（顧客の要望を聞かなかった・答えなかった）ということだと考えられていたところに、そうではないという見解をケーススタディと合わせて紹介したところに価値があると言われています。が、素朴に読んでも面白いので、ビジネス書にも興味ある人は読んでみるといいかと思います。
CODE VERSION 2.0
こちらもソフトウェア開発の本ではないですが、ネット黎明期に「自由」と「規制」の関係（規制がなければ自由も死ぬし、規制しすぎても死ぬ、ではどうすればよいのか）を記して評判となった本です。
登場当初からはネットも進化し、そして規制も進化しているのですが、今の方がより両者の関係は深く、そして難しくなっているといえます。その意味では牧歌的なところもあるかもしれませんが、その重要性は高まっているとも言えるでしょう。
以上、ざっと挙げてみましたが、とりこぼし等あるかと思うので、気になる方は他の本も探してみるとよいかと思います。参考になれば幸いです。
技術系イベントにおけるアンチハラスメントポリシーの効果について
技術に関するカンファレンス等のイベントで使われるアンチハラスメントポリシーとは、技術系イベントなどでハラスメントに反対するというポリシーを明示するしくみで、最近では様々なカンファレンスで同様のポリシーが適用されています。私が運営に関わっているRubyKaigiというイベントもその一つです（ちなみにRubyKaigiでは2020年1月14日まで発表者募集中で、また現在スポンサーも募集中です）し、同じく運営に関わっている技術書典というイベントでも導入されています（ちなみに技術書典8サークル当選者の入金は12/22(日)本日締め切りなので、まだの方は今すぐ対応願います。そして技術書典8でもスポンサーを募集中です）。
とはいえ、アンチハラスメントポリシーは必ずしも正しく理解されているわけではないかもしれません。 まあ、正しいかどうかを私が判断するのは適切ではないかもしれませんが、私から見るとこれはちょっと理解されていないのでは、という発言も見かけます。
そのため、アンチハラスメントポリシーを実際に適用しているイベントの関係者として、私のアンチハラスメントポリシーの理解の一端を書いておきます。
アンチハラスメントポリシーを掲げることによって得られる効果
「アンチハラスメントポリシーを掲げれば参加者はハラスメントしないようになる（はず）」、と思われる方もいるかもしれませんが、それは正直誤解というか、過信と言ってよいでしょう。 なぜなら、ハラスメントは本人が意識していなくても行ってしまうものであり、そして意識していないのであればそれを封じるポリシーが提示されていても、言動が変わることが期待できないためです。
それでは、なぜ多くのイベントでアンチハラスメントポリシーが掲げられるのでしょうか。それには様々な理由があります。
ハラスメント遭遇時の報告先を明示できる
ハラスメントに遭遇した者が、ハラスメントがあったので何とかしたい、という場合、まず報告先をどこ・誰にすればよいかを考えるはずです。 ところが、ポリシーがない場合、どこに報告するのが正しいのかは自明ではありません。
とりあえずスタッフに言えばいいのかと思いつつ、そもそも誰がスタッフなのかも分からない場合もあります（イベントでは、スタッフでもないのにスタッフのように仕切ろうとされる参加者の方もたまにいらっしゃいます）。 そもそもハラスメントの報告は、あまり気軽に行えるものではなく、良く分からない人に伝えるのに不安な場合もあるでしょう。
アンチハラスメントポリシーには、多くの場合ハラスメントの報告先が明示されます。スタッフに伝える場合にも、スタッフの特徴（名札、Tシャツ、腕章等）が明記されます。 それによって、正しい報告先がわかります。
さらに、スタッフと思われる人がハラスメント的な言動をしていた、というケースもありえます。その場合、とりあえず問い合わせ先に投げるとしても、普通の問い合わせ先に投げるとその人にも直接伝わるのでは（そして報告者が特定されてしまうのでは）、という恐れがあります。
アンチハラスメントポリシーに特別の連絡先を用意する場合、スタッフの中でも少数の人のみに連絡し、報告者の秘密を守ろうとすることが可能です（それが期待されます）。 さらに慎重な場合には、匿名の報告を受け付ける窓口が別途用意されている場合もあります。
このようにして、ハラスメントの報告先を示すことで、問題があった場合、あるいは問題かどうか判断つかないけれど報告したい場合に、その適切な報告先を参加者全員に伝えることができます。
「ハラスメントに遭遇した」という「報告」を積極的に求めていることを明示できる
先ほどの項目以前の大前提として、そもそもハラスメントを受けた、あるいはハラスメントを見かけたことを通知することが適切な行為として認められており、そのことを参加者とも共有する必要があります。
ハラスメントの問題をより深刻にする、二次的被害をもたらすものとして、「ハラスメントを軽視する」ということがあります。
具体的に言うと、ハラスメントを受けたと報告があった時に、報告された側の人が「そんなの大したことじゃないですよ」とか「それくらいのことならよくあるし、気にすることじゃないのでは」といったような言葉を返したり、そう思わせるような言動をすることがあります。これがハラスメントの軽視です。
（なぜ軽視なのか念の為説明しておくと、ハラスメントが大したことか、気にすることかどうかを判断するのは報告を受けた者ではなく、ハラスメントを受けたその人であるべきだからです。もちろん、よくあることかどうかもハラスメントを受けた人にとってはどうでもいいことです。「私が」「今」「ここで」ハラスメントを受けたことが問題だからです。さらに念の為説明すると、ハラスメントの問題やその報告を重要視することと、そのハラスメントをはたらいた人に対して重い処分を下すかどうかは、直接関係しているわけではありませんし、処分を約束するものでもありません。）
ハラスメントの報告は、基本的にハッピーなものではありません。それは報告を受ける者にとってもそうですが、報告する人にとっても同様です。 何も好き好んで報告したいのではなく、報告することが今後の改善につながると期待して報告する場合が多いはずです。誰も報告しなければ、自浄作用も期待できないからです。
しかし、それをためらわさせる要素があると、報告も期待できません。報告はあくまで報告者の「善意」によるものでしかないためです。
また、報告者自身ですら自分の受けたハラスメントを軽視している場合もあります。残念ながら当たり前のように日々ハラスメント的な言動が行われている場も世の中にはあるようで、そのような経験を重ねた場合、主催者としては重視しているような言動ですら報告を遠慮してしまうかもしれません。しかも、ハラスメントの対応にはそれなりにコストがかかることは事実です。そのような背景を推測してしまうことにより、ハラスメントに遭遇しても、報告をためらってしまう危険性があります。これはハラスメントを防ぎたい主催者の意に反することです。
アンチハラスメントポリシーを提示することにより、その報告者の行為を無碍にせず、主催者としてはコストがかかろうが適切に対処したいと考えていることを明示することができます。
全スタッフにハラスメントを防ぐための権限を与えることができる
アンチハラスメントポリシーは、一般の参加者だけではなく、スタッフへのメッセージにもなります。
多くのイベントでは、スタッフ経験も豊富で、長い時間をかけて深く関わっているスタッフだけではなく、当日のみイベントのお手伝いを行うために参加するスタッフの方もいます。 とはいえ、参加者からみたら当日のみのスタッフもスタッフです。
イベントの発表中にハラスメントと思われる言動が含まれることはあります（実際にありました）。 そのような発表は、場合によっては即座に中止したり、そこまでいかなくても発表中・発表直後にお詫びをお伝えする必要もあるかもしれません。 これは、控えめに言って、発表の場を壊してしまうことになりかねません。
運営チームの代表者であればそのような強い措置の判断もできるはずですが、そうではないスタッフしかその場にいない場合、そんなことをやっていいのか…と躊躇ってしまう可能性は高いです。 そして代表者に情報が伝わり、その場に来たときにはすでに発表も終わっているかもしれません。
そのような状況でも、アンチハラスメントポリシーがあれば発表も中断させることも可能にする、とても強い権限をその場にいるスタッフに与えることの後ろ盾になります。 少なくとも、何もないよりは判断の助けになるでしょう。 もちろん、そのことも含めて、スタッフにはその権限の使用についてしっかりと情報共有し、理解を徹底する必要はありますし、相当頑張っても実際に現場で振る舞えるかどうかは未知数ではあります。そこは本当に難しいところなのですが、上手く運用したいところです。
まとめ
アンチハラスメントポリシーは、掲げることでハラスメントを排除できる、便利な御札ではありません。 このポリシーは、ハラスメントをなくそう、少なくとも減らしたい・見逃さない、という主催者側の意志を伝え、ハラスメントを受けるかもしれないなら参加したくない、という方にも参加してもらい、一緒にハラスメントをなくしていくためのツールの一つです。
もっとも、イベントの主催は簡単なことではありません。アンチハラスメントポリシーがあろうがなかろうが、主催者の苦労は少なからずあります。 正直ハラスメント対応まで気が回らない、想定できない、現実的にコストが割けない、などということもあるかと思います。 ハラスメント対応ができないのであればあらゆる規模のイベントを開催するべきではない、というのも現状では非現実的もしれません（将来的には違ってくるかもしれません）。
実際、比較的小さなコミュニティのイベントでは、ポリシーを明示せずともハラスメントを未然に防いだり、ハラスメントがあってもその対応をうまくハンドリングできることもあります。 しかし、様々な背景を持った、多くの参加者が見込まれるイベントでは、最低限の振る舞いのルールも共有されていない可能性が高いです。
そこで、困難を引き受けてでも、アンチハラスメントポリシーを掲げて、ハラスメントの防止に努めることを宣言し実施することには大きな意義・効果があります。 今後とも、より良いイベントが開催され、技術コミュニティが活発化されることを期待しつつ、イベントを開催される方・イベントに参加される方を応援したいと思っています。頑張っていきましょう。
蛇足
なお、ここに書いたことは、運営視点からのプラクティカルな効果についてであり、ポリシーを提示する本当の理由は「参加者の技術的な興味・関心と参加者自身を大切にし尊重するため」「人権を損なわないため」です。が、それについて書き出すとさらに長い話になるのでここでは省略しました。
開発者向けopenBD関連リンク集
公式
2017/01/23 セミナー資料
GitHub Organization
https://github.com/OpenBD は別物なのに注意
ライブラリ・ツール・アプリ in GitHub
Go
github.com openBD APIライブラリ (Go)
github.com ISBNで書誌情報を取得するツール (Go)
JavaScript
github.com 書誌情報表示サンプル (JavaScript)
github.com 新刊情報アプリ (JavaScript)
openBDの全データを整形しつつ単一ファイルにダウンロード · GitHub 全件取得スクリプト (JavaScript)
Ruby
Crawl all data using openBD API · GitHub 全件取得ダウンローダ (Ruby(Rails))
github.com openBD APIライブラリ (Ruby)
github.com openBD APIライブラリ (Ruby)
github.com openBDの登録データ取得 (Ruby)
Python
github.com 全件取得用ダウンローダ (Python)
PHP
github.com ISBNから書誌情報を表示するサンプル (PHP)
github.com 出版社記号を使って特定出版社の書籍データを抽出するサンプル (PHP)
hontoの書籍ページにISBNでリンクする
hontoの書籍ページは独自IDが振られているので、直接リンクできない。
例えば以下のようなURLになっている。
https://honto.jp/netstore/pd-book_28169493.html
これとは別に、ISBNを指定する方法がある。
http://honto.jp/redirect.html?bookno=(ISBN)という形だが、ここでのISBNは13桁ではなく、末尾のチェックデジットを落とした12桁になるのがポイント。
http://honto.jp/redirect.html?bookno= 9784822239176 ではダメ。
http://honto.jp/redirect.html?bookno= 978482223917 だとうまくいく（冒頭のURLにリダイレクトされる）。
もうちょっと何とかならなかったのか…という仕様としか言いようがない。
textlint-rule-preset-ja-technical-writingが厳しすぎるのではないか問題
というのを某所で見かけたので。
「このルールをエラーなしで通る文章の集合」よりも「特に問題なく読める技術文書」の方がだいぶ大きそうなので、一般的な技術文書のlintの雛形として導入するのは過検出が多発してたいへんとのこと。もうちょっとゆるいサブセットを作るべき？
一般的には外したいルールとしては、
- 1文の長さは90文字以下とする
- カンマは1文中に3つまで
- 読点は1文中に3つまで
- 連続できる最大の漢字長は5文字まで
- 同じ助詞を連続して使用しない
辺りとかでしょうか。
あと、例えば『「ですます調」、「である調」を統一します』辺りは一般的には導入したいけど、引用が入るとどうにもならなくなるので、その辺りは簡単に対応できるようになると幸せになれそうです。つまり引用文は例外にするとか。
2017年のmd2reviewの開発目標
今年はとりあえず2.0をリリースしたいです。2.0での大きな変更点は2つです。
- Kramdownのサポート
- 1ファイルのFrontmatterつきMarkdownをRe:VIEWプロジェクトに変換する機能を追加
1については、Redcarpetよりは手軽にMarkdownの拡張に対応できるのでは…という期待があります。が、全てのオプションが同じように導入できないかもしれません。それもあってメジャーバージョンをあげます。 Kramdownに完全移行するか、Redcarpetとどちらを導入するかを設定で決められるようにするかは未定です。
2についてですが、JekyllやMiddlemanが対応しているやつですね。
MarkdownからRe:VIEWへの変換で問題になるのは「Re:VIEW側のconfig.ymlをどう生成するか」なのですが、Frontmatterで対応できればこれでいけそうな気がします。
実際にはちょっとFrontmatterのparserを書きかけた程度なのですが、まずはエンジンの方を解決した方がよさそう…ということで後回しになっています。
