Book

「データベース実践入門」]] を読んでいて、これは論理学を学んでおかないと歯が立たないなと感じ、急遽読むことにしました。 論理学はプログラマが勉強すべき内容として、こちら でも紹介されていますね。

難しさに挫折するのは悔しい所ですが、ここは自分の知識のなさを素直に認めて急がば回れで行くことにしました。

内容

命題論理を中心に進めながら、述語論理にも触れていく構成になっています。 この本自体は著者も書かれていますが、式をバンバン出していくのではなく、敷居を下げつつ nnある程度内容を絞った上で論理学の入り口に連れていってくれます。

特に面白かった所

この本で扱う論理学では、公理と呼ばれる前提とされるもの、つまり証明せずに使って良いものは非常に少ないです。 否定、連言、選言、条件。この4つです。 この4つを用いて証明を進めていくことになります。

使って良いものが少ないので、証明の過程は最初は回りくどく感じます。

どれくらい回りくどいかというと、 「((Aではない) ではない) かつ B」 から 「AかつB」を証明するのに、 4ステップ必要なのです。

(1) ((Aではない) ではない) かつ B  ...前提
(2) (Aではない)ではない ...(1)より
(3) A ... (2)より
(4) B ... (1)より
(5) AかつB ... (3),(4)より

読み進めていくうちに、この回りくどさが納得感に変わっていくのが不思議な感覚でした。

仮定として述べられていないことはしつこいくらいに証明を重ねていく考え方は、 論理学に限らず非常に有用に感じました。 「AならばB」とした時に「BならばA」(逆) 「AでないならばBではない」(裏)は、必ずしも成り立たないのですが、 裏とか逆とかは日常では曖昧にされつつ、暗黙的に成り立つとみなされることもあります。 この辺りをはっきりしていくと、いろんな誤解も防げそうですね。

まとめ

とにかく論理学の雰囲気を楽しんでほしいという、著者の意図が非常にありがたい一冊でした。 おかげで論理学で使われる堅苦しい言葉にも少しは慣れました。 ド・モルガンの定理などは昔習ったことのあるものでしたが、 この本にそって再度学び直すことで、また違った景色を手に入れた気分です。

この本を読み終わって 「データベース実践入門」 を再度眺めて見ました。 ありがたいことに「読める、読めるぞ！」という気分に浸れました。 この本はデータベースの理論を学ぶ上で非常に良い導入になるんだと思います。

実際に仕事でも使ってるAnsibleだけど、使い始めた頃から本書にはお世話になってます。

改めて読み返してみると、最初のハードルから様々なプロダクトとの連携や高速化など、 痒いところに手がとどく内容だなと思います。

初めてAnsibleを触る人にも良いと思います。 あまり馴染みのないPython製のCRMをベースに話が進んでいく箇所は若干難儀しましたが。

特に面白かった所

前述の通りAnsibleの初歩から丁寧に解説してくれた上で、応用までしっかり導いてくれる一冊でした。 ある程度仕事で使った今でも、変数の付け方や高速化の手法など、細かな書き方の指針なんかも書いてくれていて、 はっとさせられます。

考えたこと

DockerやVagrantとの連携に関してはやはり実際に書いてみるのが一番だなと感じました。 それぞれのツールの役割が読んでるだけではよくわからなくなってしまいます。 写経の大事さが身にしみました。 ただ、Dockerのサンプルソースが一部分現時点では動かなくなっていました。 本書は1系の頃に書かれたこともあり、賞味期限も切れかけているのかなとも思います。

まとめ

この分野も日々進化しており、原著は2nd Editionが出ているようです。 まだ翻訳は出ていませんが、GitHubのサンプルソースをちらっとみた限り、 章立てもだいぶ変わっているようです。翻訳版は出るのでしょうかね、楽しみですね。

これまで、Googleの成長をリアルタイムで体験しながらネットを利用してきたわけですが、 Googleが企業し、小さな企業から大企業へとなっていく華やかな成長の裏で、 中の人は何を考え、苦悩してきたのかがわかる本です。

内容

検索エンジンのキラーアイデアとなったページランクから始まり、打ち出の小槌のAdwardsにより、お金の心配なく企業を運営してきたGoogle。 そんなGoogleが「邪悪になるな」をモットーにしながらも、プライバシーや著作権の問題で、リアル世界では批判にさらされていく様子が克明に描かれています。 小さな企業だった頃はグレーゾーンを突き進んでイノベーションを起こしてきたGoogleが、 大企業になって無茶はできなくなっていき、リアルな世界と調整していくに当たって保守的にならざる得なくなるところが印象的でした。

特に面白かった所

ペイジが書いた初期の検索エンジンはJavaで書かれていたが、バグだらけで後にPythonで書き直されたそうです。 また、インデックスの更新に非常に時間がかかったりと、技術的には今のGoogleからは考えにくいようなレベル感の話がありました。 そんな中で、今では常識となっているメモリを使った高速化の手法を編み出していくわけですが、 当時としては画期的な訳で、それをゼロから考えついたというところは流石と思いました。

また、自由に見えるGoogleも思ったよりと不自由な状況になっている点も印象的でした。 大企業のしがらみからか、徐々にイノベーションを起こすだけの小回りが効かなくなっていく様が本書でも克明に描かれています。 そんな中でYoutubeという、著作権ギリギリの中でサービスを展開していく存在が非常に対照的に描かれています。 色々配慮したGoogle Videoは敗れ、Youtubeを買収することでイノベーションに乗っかることを選んだGoogle。 今後のGoogleはどうなっていくか考えさせられる買収劇でした。

考えたこと

ソーシャルの波にはすかり乗り遅れ、Facebookの後塵を拝しているGoogleですが、 最近は人工知能の分野で盛り返しているように感じます。 ブリンとペイジは創業当初から常にGoogleは人工知能の会社であると定義していたことを考えると、 大きな企業がイノベーションを起こすことは難しいと言われていますが、そこを覆す何かが起こらないかなと期待してしまいます。

まとめ

今となっては息をするように利用しているGoogleのサービスですが、 こんなにも著作権やプライバシーの問題に晒され、苦しんできたのかと驚かされました。 僕の中に漠然とあった、やんちゃなイメージのGoogleは実はもう存在していなくて、大人な会社がそこにはありました。 日本では特にGoogleのこういった苦悩は知られていないのかなとも思います。 多くのインタビューと取材によって書かれた本書は、本当のGoogleを知る上で良い一冊だと思いました。

Infrastructure as Code(IaC)もずいぶん使い古された感のあるワードですね。

出始めの頃は自分もChefとかPuppetを使いさえすればいいもんだと勘違いしていました。

実際はもっと大きな考え方であり、この本は網羅的にIaCの考え方を抑えていってくれるので、 視野狭窄にならないようにするためにも、読んでおいて損はない本だと思いました。

内容

この本はIaCに関する技術的トピッックを取り上げるというよりかは、概念とか思想とかそういったものを教えてくれます。 よくあるアンチパターンとどうやってIoCを取り入れていくか、トピックごとにパターンを提示していきながら、 再現可能でセキュアで品質の高いシステムを作っていく方法が書かれています。

そう、システム。当たり前だけどシステムはインフラだけで動いてるんじゃないんです。

読んでる間は結局うちの組織にどうやって適用すればいいんだよっていう葛藤との戦いでした。 何度この本を読みながら天を仰いだことか。 IaCを適用していく上での組織論みたいな部分もあるにはあるんですが、 100個組織があったら100個の文化があるわけで、そんな綺麗に当てはまるわけもないですし、 そんな細かいところまでこの本も解決するつもりはなく、こんなベストプラクティスがあるよって程度です。

それでも、この本が提示してくれたメリットには夢がありました。

特に面白かった所

結局、アプリケーション開発の良い部分を、インフラに持って行こうという点が、特に後半では強くなります。 ユニットテストやCIをインフラに適応させていく話は、数年前はアプリケーション開発をやってた身としては、非常に納得感のあるものでした。 コードを描いてて、テストがあることによる安心感は相当なもんです。 そしてインフラに何か変更を加えるとき、様々な要素が検証環境と違うことがある中で本番環境に手を入れる時の緊張感も相当なもんです。

考えたこと

自分の組織に如何に適応していくかを考え続けた読書であったことは前述の通りです。 そして最後に思ったのは、結局アプリ・インフラとあまりに分かれている組織はダメなんだなということでした。 アプリはもっとインフラを理解しないといけないし、インフラももっとアプリを理解しないといけない。 これもずっと言われ続けてきていることですけど。

アプリ屋さんがセルフサービでインフラを構築できないと、IoCの求めている姿にはならないし、そのためにはインフラの知識が必要です。 そしてインフラ屋さんは、アプリケーションのニーズを理解しつつ、アプリ屋さんがセルフサービスでインフラを構築できるような基盤を整えていくことが必要になっていくんでしょう。

まとめ

古き良きインフラ運用のデメリットと、IaCがもたらしてくれる明るい未来を予感させてくれました。 まだまだやることがあるなと途方に暮れつつも、ワクワクさせてくれる本でした。

DevOpsは最近ではバズワードでもなんでもなくて、 普通に考えなきゃいけない概念になってきました。

と言っても自分の周辺ではまだまだという感があるので、 とりあえず軽い気持ちで読んでみたのが本書です。 あまり考えずに買ったので、物語調で始まった時には少し面食らいました。

内容

ボロボロのIT組織を立て直していくサクセスストーリーです。 新規開発は遅れに遅れ、リリースしたものは障害を繰り返している中で、 最後にはビジネス・開発・運用の流れをスムーズににし、DevOpsで大逆転という内容です。

DevOpsの周辺技術についての解説書ではありません。 組織の根幹を支えるITをどう作り上げて行くか、組織論的な内容です。

特に面白かった所

同じ業界の人間なので、最初のうちはあまりの試練に身につまされる思いでした。 その分、DevOpsに対する甘い考えだけでなく、そこに至るまでの苦労を追体験することができました。 DevOpsに至るまでに組織をどのように変えていかなければならないかを知るいい手がかりになりました。

考えたこと

新たに動くものを立ち上げること、動いているシステムに手を加えるという変化は、 常になんらかの障害と隣り合わせです。 このリスクをコントロールして変化のスピード上げて行ったところが、ビジネスで成功を納める。 当たり前ではありますが、まだまだできていない組織が大半ではないでしょうか。

本書ではそんな当たり前とは程遠い、ITとビジネスが足を引っ張りあってる状態からスタートしています。 こんなダメな状態がよく聞く話だったりして、共感とともに危機感が湧きました。

こんな足の引っ張り合いは、組織的・技術的両面で解決していかなければならないことなのですが、 今の世の中では技術的側面はずいぶん整備されてきたと感じます。 となると、残る難題は組織的な部分なわけですが、ここはなかなか特効薬はありません。 そこでDevOps完成後の理想である「1日10回リリース」みたいな、わかりやすい指標を持つのが、一つの解だなと感じました。

まとめ

物語とはいえ、組織と技術の両輪がうまく回った時にこれだけの良い流れが作り上げられて行くのかと。 翻って自分の周辺を見渡すと、両輪ともまだまだという感じ。 とはいえあがいて見ようかなという勇気を本書がくれたのも確かでした。