ラベル book review の投稿を表示しています。 すべての投稿を表示
ラベル book review の投稿を表示しています。 すべての投稿を表示

2017年5月13日

書評: 「Docker実践入門」

書誌情報: 中井悦司、「Docker実践入門」、技術評論社、2015, ISBN978-4-7741-7654-3

(本書は2015年9月に技術評論社Software Design編集部の池本様よりご恵贈いただきました。書評が大変遅れて申し訳ありません。)

Dockerは今やLinuxのエンジニアなら誰でも知っているコンテナ技術を稼動させるためのプラットフォームである。この本は2015年9月に出版されたもので最新の情報は反映されてはいないが、それでも内容については今でも読むに耐えるものが多く含まれている。

私自身はLinuxとは現在に至るまであまり親密な関係ではなく、研究開発にはもっぱらFreeBSDを使っている。コンテナといえばFreeBSDのJailという(いささか物騒な)名前の技術の印象が強く、単なるコンテナという観点ではDockerにあまり新しさは感じていない。

しかし、Dockerの魅力は、コンテナの利用の仕方に対して一定の定義を与えたところにあるのだと思う。用途を限定した単一機能サービスを提供するコンテナを組み合わせるサービスモデルと、開発結果と動作環境を併わせてコンテナに封じこめ継続開発を可能にする開発モデルを明確に打ち出し、それらを複数統合して管理し運用する(オーケストレーションの)ためのサポートツールを整備することで、それまでのハイパーバイザベースだった仮想マシンの管理の手間を省いて大規模運用を行えるようにしたのが、Dockerが流行り普及しつつある理由ではないかと思っている。

本書でもDockerの基本的な考え方に最初の第1章を割いて詳細に説明している。大規模な開発運用テスト環境の維持管理、デプロイの効率化、そして 運用サーバー基盤を変えずにアプリケーションの更新をしたいという3つの要請に対して、Dockerがどんな技術をもってそれに応えているのかが詳説されている。この章だけでも読んでおく価値はあるだろう。(この章はDockerを運用する上で不可欠なGitについても概要を説明している。)本書の第2章以降は、実際にDockerでどのようにしてコンテナを生成し連携させて動かすのかについての具体的手法が示されている。

Dockerを取り巻く技術は常に変化しており、最近はLinuxだけでなくWindowsやmacOSでの動作や、Moby projectという、よりOS間の可搬性を高めた動作環境の追求という方向へ向かっている(Publickeyによる2017年4月の記事)。書評が2年近く遅れた者がこういうことを書く 資格がないことを承知であえて書くなら、ぜひ本書をアップデートした第2版を読んでみたい。

2016年10月9日

書評: 「ITエンジニアのための機械学習理論入門」

書誌情報: 中井悦司、「ITエンジニアのための機械学習理論入門」、技術評論社、2015, ISBN978-4-7741-7698-7

(本書は2015年10月に技術評論社Software Design編集部の池本様よりご恵贈いただきました。書評が大変遅れて申し訳ありません。)

現在「機械学習」と称されるニューラルネットワークの技術は、私が過去25年以上にわたって遠ざけてきた苦手なものの1つである。大量のパーセプトロンの組み合わせで特性情報が得られるという「夢のような話」に納得することは、「コンピュータというのはアルゴリズムで説明し得る作業のみが行えるもの」という定義で生きてきた私自身の考え方では極めて困難である。2016年現在得られているニューラルネットワークの成果全般に反駁するつもりはもちろんないし、その有用性を否定するものではないが、単にニューラルネットワークの説明を受けただけでは残念ながら私の疑問は消えない。申し訳ないがこの疑問は死ぬまで消えないだろう。(法的にもこの「なんで?」という問題は存在しており、「判断過程の不透明性に関わる問題」として現在も議論が続いている。)

本書はこの「なんで?」という部分に、統計学の観点から光を当てて解説しようとしたものであり、どういう計算手法を使えば結果がより目的にかなったものに近づくかの判断例が記されている。具体的には以下の流れで示されている。

  • 最小二乗法の推定から複数のデータセットを使ったクロスバリデーションとオーバーフィッティングの問題の説明
  • 尤度関数による確率モデル(最尤推定法)の導入
  • 勾配降下法による多次元ベクトルへの適用(概念としてのパーセプトロンの導入)
  • ロジスティック関数と偽陽性率の関連
  • 教師なし学習におけるk平均法とEMアルゴリズム(期待値最大化法)
  • ベイズ推定の適用と最尤推定法との比較

これらの手法は、ニューラルネットワークが「なぜそうなるか」を説明するものではない。しかし、どのように使えばより統計学的に筋の通った結果を得られるかについての手法としては一貫しており、ニューラルネットワークを「どうやって使えばマトモな結果が出るのか」についての実践的な説明になっている。アルゴリズムからの演繹的説明が不可能な以上、このような「結果が統計的にこうなるのでアルゴリズムはこう使うべき」という説明が、現時点では最も有用であると思う。その意味で本書は(統計も大の苦手である私のような者を含め)ニューラルネットワークの結果を評価する上の第一歩を知りたい人には大いに役立つであろう。そして本書は基礎理論の解説書であり、大学での教科書に使えるだけの中身のある力作である。

なお、本書にはサンプルコードが用意されているが、書籍の中ではサンプルコードがどのような概念を示しているか、そしてその動作結果が何を意味するかの説明に徹しており、サンプルコードの表面的な解説がなされているわけではない。言い換えれば、プログラマとしての知識は要求されず、数学の基本的知識があれば読めるようになっている。その意味でプログラミングの苦手な人にもおすすめできる。

書評: 「ニッポンの個人情報」

書誌情報: 鈴木正朝、高木浩光、山本一郎、「ニッポンの個人情報」、翔泳社、2015、ISBN 978-4-7981-3976-0

(本書は2015年2月に翔泳社の井浦様よりご恵贈いただきました。書評が大変遅れて申し訳ありません。)

鈴木正朝、高木浩光、山本一郎。

この3人の名前のうち、一人でも見て恐怖を感じないようであれば、日本のプライバシー問題、特に個人情報の扱いが実務者にとってどれほど難しいかについての、理解が不十分と思ったほうがいい。正直いってこの御三方のうち一人と対峙しなければならなくなったら、シッポを巻いて逃げたい。その3人がまとめて鼎談しているこの本は、正直いって重い。重すぎる。怖くて読めない。「ニッポンの個人情報」とか、「プライバシーフリーク」とか、そんな軽そうな言葉に騙されてはいけない。

しかし、現状の混沌と矛盾、法律の手抜き、そしてそもそもの「プライバシー権」への認識がバラバラになっている現状を知るには、この本に書かれている内容ぐらいは知っておかなくてはならないだろう。その意味では対談形式で重要な論点が各所にタップリと含まれているこの本は貴重な存在といえる。重要なポイントは全部QRコードでURLへのアクセスがしやすくなっているのも良い。

この書籍の発刊後、個人情報保護法は改正され、「平成27年9月9日から2年以内に全面施行」される予定である(日本政府の個人情報保護委員会のページより)。この法律改正により、「個人情報」を仕事に使うすべての事業者(個人も例外ではない)がこの法律の適用対象となる。そういう意味では、もう誰も逃げられなくなっているのである。今までの経緯と問題点をふまえた基本をおさえる上では、必読であろう。

2016年8月18日

祝「プログラミングElixir」刊行

このたび,Programming Elixir 1.2の日本語版がオーム社より「プログラミングElixir」として刊行される。この本は2nd editionであり、すでに3rd editionであるProgramming Elixir 1.3のプロジェクトが進行中だが、それでも日本語で初の本格的なElixir並行プログラミングシステムの書籍が出版されるのは大変喜ばしいことである。著者のDave Thomas、翻訳者の笹田さんと鳥井さん、編集者の方々、レビュアーの方々、そしてその他関係者の方々の努力に深く敬意を表したい。私もErlang/OTPに関わってきた者として、微力ながらレビュアーとして参加することができた。

以下は、「プログラミングElixir」発刊にあたっての、個人的なポエムである。

この本の「推薦のことば」にも書いたのだが、Dave ThomasがErlang Factory SF Bay 2014に現れたとき、「なんでRubyの人がErlangに関係あるのか」が、正直いってよくわからなかったのは当時の率直な実感だった。この時の彼とJosé Valimが共同して行ったプレゼンテーションは、"Catalyze Change"、つまり「変化を触媒となって加速しよう」というものだった。内容は、Erlangを読み慣れていない入門者にとって、Erlangのエコシステム全体がいかにわかりにくいかというのを徹底して糺弾するという、Erlang/OTPのファンにとってはかなり耳の痛い内容で、現場の空気は少なからず殺伐とした感じになったことを覚えている。そこでは、Erlangの文法のわかりにくさ、レコードの使いにくさ、マニュアルの読みにくさが強調された。これらの傾向は2016年の今でも直ったとはいえないだろう。Erlangのいわばドス黒い部分である。もちろんこの悪条件を越えている人達はいっぱいいるし、私もそれほどは気にならないが、多くのErlangを勉強しようとした人達を敬遠させる原因になったことは否定できないだろう。そういう意味でDave Thomasがやったのは、かなりキツいプレゼンだった。「Erlang/OTPにはこんなに未来があるのに、なんでこんな状況を放っておくんだ」というDave Thomasの不満は相当なものだったと思う。

しかし、Dave Thomasはそこで終わるような人ではなかった。なにしろThe Pragmatic Programmerという本を書き、Pragmatic Bookshelfを作った人である。彼はErlang/OTPに持っていた不満について、おそらくElixirに救いを見出したのだと私は思っている。そして彼はElixirを普及させる本を自分で書いてしまった。それがProgramming Elixirという本だった。かつてRubyに対して熱心だったDave Thomasは、今度はその情熱をElixirに向けたのだと私は思っている。残念ながらRubyに関する本は私はほとんど読めていないのだが、Pragmatic Bookshelfのラインアップを見ても、そのことは証明されているだろうと思う。なにしろMetaprogramming Elixirなんていう、Elixirのマクロを知らないと読めないような本、そしてPhoenixフレームワークのProgramming Phoenixという解説書まで出版させているのだから。こんなElixirに対してマニアックな人が他にいるだろうか?

Elixirが有名になってきた過程で、Erlang/OTPの側にいた人達は、かなり当惑していたように思う。ElixirにはErlang/OTPにない要素がたくさん詰まっている。そういう意味で私はまだElixirはほとんど使えていない。たぶん死ぬまで使えるようにはならないだろう。それくらいElixirは奥が深い。Erlang/OTPも2008年からつき合っているが、おそらく死ぬまでまともに使えるようにはならないだろう。どちらも奥が深すぎる。並行プログラミングシステムは、人類にはまだ早いのかもしれない。そんなことを思いながら、少ない時間の中で何度も実験を繰り返し、失敗し続けているのが現状だ。でもErlang/OTP単独ではできないことがElixirでできる。そのことは確かだ。だからElixirを支持しようと思った。その判断は間違っていなかったと思う。なにしろElixir、Erlang、どちらのコミュニティも小さすぎる。仲違いしている余裕なんかない。誰がErlang/OTPを維持し続けるのかということを考えたら、ElixirをきっかけにErlang VMを使うようになった人達を、仲間として歓迎こそすれ、絶対に敵にしてはいけない。今のところ、そういう判断でコミュニティは上手く回っているように私は思っている。共存共栄である。幸い、Erlang/OTPのプログラマの多くは、自分達のツールをElixirにも対応させている。

残念ながら未だにDave Thomas本人と個人的に話をしたことはない。しかし、Elixirを引っ張ってきた設計者でありErlang/OTPの辣腕プログラマでもあるJosé Valim、Phoenixフレームワークの作者Chris McCord、hex.pmパッケージマネージャの作者Eric Meadows-Jönsson、今はErlang/Elixirから離れているように見えるがビルドツールkerlを作りElixirの初期の普及に尽力したYurii Rashkovskii(この4人は皆若い!)、そして私同様のオッサンではあるがElixirの普及に力を注いできたBruce Tateなど、多くの強者達と話をし、彼等の作品に触れた経験で考える限り、ElixirはErlangが作ってきたエコシステムの可能性を大きく広げたことは間違いないと私は確信している。そのことをずっと前から見抜いていたDave Thomasについては、さすがとしかいいようがない。

「プログラミングElixir」は、どちらかといえばProgramming Erlang(第2版)(日本語版は「プログラミングErlang」(第1版の翻訳))同様、リファレンスではなく、最初から最後まで読んで手を動かしていくことで、プログラミングシステムの基本が身についていくようになっている本である。中にErlangのコードはほとんど出てこない。やっぱりErlangはDave Thomasには嫌われているのかもしれない(笑)。でも、OTPという単語は出てくる。だからOTPは知らないとこの本はわからないかもしれない。ということは、Elixirのマニュアル同様、Erlang/OTPのマニュアルを読まないと結局はいけなくなるのだろうと思う。Elixirは多くのElixirで書かれたモジュールを持っているが、実際はErlang/OTPのモジュールにも多くの機能を依存しているからだ。そういう意味で、この本を読んで先に進むには、Erlang/OTPの本が必要かもしれない。幸い、オーム社からは「すごいErlangゆかいに学ぼう!」(このblogで紹介した記事へのリンク)という本が2014年に出ている。両方読んでみることを、ぜひお勧めしたい。

これを機に日本でもElixirとErlangに触れる人達がますます増えることを願っている。

2014年6月20日

祝「すごいErlangゆかいに学ぼう!」刊行

(Signature: by Fréd Hébert at Erlang Factory SF Bay Area 2014) (Text by Fréd: "À Kenji, l'une des personnes que j'ai le plus hâte de revoir à chaque conference" - "To Kenji: one of the people I most look forward to seeing at each conference" - 「どのカンファレンスでも一番会いたいと思う人々の一人,Kenjiへ」)

このたび,Learn You Some Erlang for Great Good!の日本語版がオーム社より「すごいErlangゆかいに学ぼう!」(リンクは日本のアマゾン,アフィリエイトはありません)として刊行される.かなり大変なプロジェクトだったと思うが,著者のFréd(敬称略),翻訳者の山口さん,編集者の方々,レビュアーの方々に深く敬意を表したい(私も微力ながらレビュアーとして参加させていただいた).

この本はとにかく内容が盛りだくさんで,原著者の情熱が伝わってくる文体になっている.教科書らしくはないが,Erlangについて必要なことは一通り網羅してある恐ろしい本である.情熱を量と質で証明するのは容易なことではないが,この本ではそれができている.若くて元気な人達が本を書いたり訳したりすると,ここまで元気になるのかという良い例である.その意味で,Armstrong御大のProgramming Erlang(第2版)とは,まったく別のアプローチの本ということができるだろう.(こちらの翻訳もオーム社より「プログラミングErlang」(第1版の翻訳)として出ている(第2版の翻訳を期待したい).)

これを機に日本でもErlang/OTPに触れる人達がますます増えることを願う.

2011年5月8日

相互排除問題,際どい部分,そして並行プログラミング

複数の実行中のプログラム(プロセス)が関わる処理では,必ず排他制御が問題になる. 複数のプロセスがあらかじめ許容された同時アクセス数を越えて共有資源を使おうとすれば, どのプロセスにアクセスを許し,どれに許さないかを,決めなくてはならない. これを mutual exclusion problem 日本語では相互排除問題という.

この相互排除問題について,最近岩波書店より 「相互排除問題」(以下「本書」とする) というそのものズバリの本が先月2011年4月に出版された. 著者は土居範久先生.日本におけるこの分野の第一人者である.

本書の参考文献リストを見ると,ほとんどの文献が 1990年以前に書かれている.しかし,内容はいささかも古いものではなく, 現在のマルチコア環境,あるいは分散ネットワーク環境において課題となっている 同期と相互排除に関する問題のほとんどを網羅している. 言い換えれば,現時点の課題の大多数は,20年前に解かれていると 言い切れるかもしれない. (もちろん,アルゴリズムの効率化や,実行環境の速度等に合わせた最適化は 現在も引き続き行われているが.)

本書では,アルゴリズムの説明にPascalに似た疑似コードを使っている. しかし,本書の本文中では逐次処理にとどまらず,HoareのCSPや分散プロセス, メッセージ通信など現在の並行処理や分散処理の基本となる概念が くまなく網羅されており,疑似コードも書籍を読み進めるに従って, 内容が拡張されていく仕組みになっている.そういう意味では,読んでいて楽しい. もっとも,例示されているそれぞれの疑似コードを咀嚼して理解するには, かなりのプログラミングの経験が必要だが.

本書のページ数は256と少ないものの,気軽に片手間で読める本ではない. 本書のテーマである「際どい部分」(critical section)や 「際どい資源」(critical resource)の扱いは, 一歩間違えれば,大変な事故を引き起こしかねないものだからだ. 別の言い方をすれば,この本を一通り理解できるようになったら, ソフトウェアエンジニアとしては一人前と言えるかもしれない. 日本語で並行処理を理解する上で,本書は必読といえるだろう.