長尾高弘のレビュー一覧

世界でもっとも強力な9のアルゴリズム

ひたすらただの感想。
暗号の話は詳しくなかったのでなるほど、勉強になった。パターン認識と演繹思考は馴染みがあるので、普段やってることはそんなに間違ってないんだなと確認。
量子コンピュータについても軽く触れてるだけだけど、なぜ高速なのか=ゼロイチじゃないから、というのもなるほど。
思えば、20歳くらいからずっと、ささやかなことばかりだけど、どうやったらコンピュータにやってもらえるかを考えてて、自分はこの分野が好きだったんだな。

CAREER SKILLS ソフトウェア開発者の完全キャリアガイド

解説にもあるように、日本とは異なる状況下での振る舞い方について書かれているので、そのまま適用できないこともある。
ただ、現実的に取れる手を列挙してくれているので、キャリアガイドの名に恥じない内容だと思った。

一方で、本書の(特に対人面での)内容を素直に受け入れられない気分もある。
そこまで合理的に振舞えない、というより、振る舞いたくないという感情面の抵抗感が拭えない。
多分、利害を見据えて打算的に振る舞う、というのが、自分の目指すところとは違うのだろう。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミングの導入、実践、継続、改善など、モブプログラミングを実のあるものにするためのありとあらゆる術が書かれた本。

AIは「心」を持てるのか 脳に近いアーキテクチャ

AI、人工知能。最近、よく目にするようになったキーワードについて理解が深まるかと思ったが、「心」とは何か、「心」をプログラムによって再現できるか、という内容が印象的だった。(タイトルで気づくべき)
　
科学技術としての側面だけではなく、哲学や脳科学の見地から考察と解説がされており、ぼんやりしたAIや人工知能のイメージがより具体化される。

AIはビックデータの解析やアナリストのような機能的役割と映画に出てくるようなアンドロイドのような人間的役割の二つに分かれるが、本著は後者における考察がメイン。
　
技術的な転用に対する考察について学ぶには、関連書籍を併読する必要がありそう。

テストから見えてくるグーグルのソフトウェア開発 テストファーストによるエンジニアリング生産性向上

グールグでのプログラマ、テスタのレスポンシビリティがよくわかる。また、マネージャの仕事内容もよくわかる。これらを総合すると、グーグルのソフト開発能力の源泉が理解できる。こういうことができない、もしくは理解できないと（要は現在のソフトに対するリテラシイが高くないと）、近い将来ソフト屋として存在意義を失う可能性が高いと思う。

テストから見えてくるグーグルのソフトウェア開発 テストファーストによるエンジニアリング生産性向上

　サブタイトルにもあるとおり、Googleではテストファーストによりエンジニアリング生産性を向上させているというもの。正直、今の自分の知識では、本書の1/3も理解できなかったと思う。しかしながら、今携わっているシステム開発で、ちょうど受け入れテストを実施していて、想像以上に骨の折れる作業であることを痛感している最中に読んだため、Googleが進んでいることが際立って感じた。少なくとも、システム開発においてテストがいかに重要かという点は充分に学ぶことができた気がする。Chrome、Gmail、Youtube等に実際に携わっている人々のインタビューが収録されているから、その説得力は半端ない。

「テストは、イノベーションと開発のペースを遅らせるような摩擦を作るものであってはならない。」
「グーグルテストは、大軍ではなく、優れた戦術と高度な武器で百戦百勝を実現する少数精鋭の特殊部隊なのだ。軍の特殊部隊と同様に、グーグルテストの特徴はこの人材の少なさにある。ラリー・ペイジが『希少性は明確性をもたらす』と言っているように、人数が少ない分、私たちは必然的に優先順位をうまく付けなければならなくなる。」
「グーグルでは、形態よりも規模を強調するために、コード、統合、システムテストという区別をせず、Sテスト、Mテスト、Lテストという表現を使う。」
「グーグルのSWE(ソフトウェアエンジニア)は、顧客のもとに届けられるコンポーネントの開発に責任を負う機能デベロッパーだ。彼らは機能コードとその機能コードのための単体テストコードを書く。
　グーグルのSET(ソフトウェアエンジニアインテスト)は、単体テストに関してSWEを助け、SWEがSテストより広範な品質問題を評価するMテストを書くときに使う大規模なテストフレームワークも各テストデベロッパーだ。
　グーグルのTE(テストエンジニア)は、品質に関係するあらゆる問題でユーザーの立場で動くユーザーデベロッパーだ。」
「グーグルはコードレビューを開発プロセスの中心に置いている。コードを書くことよりもレビューすることの方がずっと大切なこととして大々的に取り扱われる。」
「ACC(アトリビュートコンポーネントケーパビリティ)は、製品の3つの側面を通じて立案者を導いていく。すなわち、?製品の目的と目標を説明する形容詞と副詞、?製品のさまざまな部分や機能を表す名詞、?製品が実際に何をするのかを示す動詞の3つだ。そして、これらの機能が働いていること、書いたコンポーネントがアプリケーションの目的、目標を満たすことをテストで確かめていく。」
「グーグルはイノベーティブな会社として知られるが、テストチームは確かにその評価にふさわしい。グーグルの社内で生み出され、使われているテスト実践やツールの数(そしてその多くは社外にも公開されている)は、このイノベーティブな精神がテストチーム同士を固く結びつけていることをよく示している。」
「私は自動化には懐疑的になってきているんですよ。テスターは自動化の大きなビジョンに情熱を傾け、自動化の作成に何カ月もかけますが、結局製品かプラットフォームが変わって、してきたすべてのことが否定されてしまいます。時間の試練に耐えられない自動化を書くこと以上にひどい資源の無駄遣いはありません。私の考えでは、自動化はすぐに書けてすぐに実行でき、非常に限定的な問題を解決するものでなければなりません。自動化されたテストの目的がすぐに理解できないようであれば、それは複雑すぎます。単純にして、範囲を限定し、何よりもまず、価値を追加するものにしなければなりません。」
「（グーグルに入ったころと比べてテストでもっとも大きく変わったことは？）
　まず第１に、平均的なデベロッパーが以前よりもテストプロセスに関わり、自動化を書くようになったことです。彼らは単体、API、統合、フルシステムテストの知識を持っています。…第２に、テスト専門の職務に数百もの最高のエンジニアたちを引きつけられるようになりました。私は、この２つは関係があると思っています。これはテストを尊重する文化であり、テストを行うことは、そのために評価を受けることになったのです。」
しかし、一方、テストファーストも行き過ぎると問題となることも認識している点が追う立場の我々も考えなくてはならない点である。
「グーグルのように開発とテストを分離していると、職務によるつながりが強くなり、テスターが製品に一体化しにくくなってしまう。」

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

独特の言い回しの文章で、読む人選ぶかもしれません。
プログラマを経ずに、ソフトウェア開発のマネジメントをする人は是非読むべきだと思う。ほかのマネジメント本とは違い、ソフトウェア開発を社会学としてとらえ、現場の問題に即した本となっている。
メモしたい言葉は、「人は期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りにできそうもないことがわかったときに、非難から身を守るために残業するのだ」

The DevOps ハンドブック 理論・原則・実践のすべて

読みにくい本だ…。それほど目からウロコでもないような話題をタラタラタラタラ、翻訳書独特のの長ったらしい文章で説明し、「章タイトルは【最初に手をつけるバリューストリームの選択方法】なんだけど、バリューストリームのカテゴリの話ばかりして選択方法の話が出てこないぞ…」こんなのばっかりで、「これ何の話だったっけ？」と戻り読みすることが多くなかなか先へ進まない。

理想はそうなんだけどさー、どうやって実現にこぎつけりゃいいのよ？ケーススタディとやらも「日常業務の一部として問題を見つけ、修正していくことで、技術的に負債をマネジメントしていった」みたいな抽象的記述ばっかりで、いやいやクソ忙してくてそれどころじゃない職場で具体的にどうやってそれ進めたのか知りたいんだけど、という気持ちになりイライラして読むのが止まる。全然先に進まない。

p. 167 【第9章 デプロイパイプラインの基礎の構築】ほとんどすべての場合において、コードよりも環境のほうが帰られる設定が何桁分も多いからである。そのため、もっともバージョン管理システムが必要なのは環境なのだ。
→「修理するよりも再構築するほうが簡単なインフラストラクチャを作る」につながる。
“イミュータブルインフラストラクチャ”＝本番環境に対する手作業の変更はもはや認められない。本番環境に変更を加えるときは、変更をバージョン管理システムに格納し、ゼロからコードと環境を作り直す以外の方法は許されない。そうすれば、本番環境に差異が紛れ込むことは絶対になくなる。

p.181 【第9章 デプロイパイプラインの基礎の構築】継続的インテグレーションの実践に必要な3つ
・デプロイできる状態になっていることをチェックする包括的で信頼性の高い自動テストセット
・チェックのためのテストが失敗したときには「生産ラインを全面ストップする」文化（＝アンドン）
・寿命の長い機能ブランチではなく、トランクに小規模な変更を加えていくデベロッパー

p.185 【第10章 高速で信頼性の高い自動テストの実現】理想的な自動テストピラミッドは、大半のエラーをユニットテストで見つけられることである。インテグレーションテストや受入テストでエラーを見つけた場合、デベロッパーに返すフィードバックは桁違いに遅くなる。そして、インテグレーションテストは希少で複雑なインテグレーションテスト環境を使うため、この環境を同時に使えるチームは1つだけに限られたりして、フィードバックはさらに遅くなってしまう。
しかし、多くのテストプログラムは、マニュアルテストやインテグレーションテストに重点を置いており、これとは逆になっている。

p.237 【第12章 自動化とローリスクリリースの実現】「継続的インテグレーション ⊃ 継続的デリバリー ⊃ 継続的デプロイメント」
・継続的インテグレーション： ビルドが成功したら自動的にインテグレーションテストが実行される状態
・継続的デリバリー： トランクがいつでもオンデマンドでデプロイ可能な状態
・継続的デプロイメント： 以上に加え、最後のステップ（本番環境へのデプロイ）まで定期的に行っている状態

p.309 【第16章 フィードバックループおｗ実現して開発と運用が安全にコードをデプロイできるようにする】最初の段階では本番サービスをデベロッパーに管理させる。運用エンジニアに移管後、本番サービスが十分脆弱になってきたら、運用は本番サポートの職務を開発に返上（サービスハンドバック）できるようにする。
こうしたフィードバックループを作ると、本番環境へのデプロイが安全になり、開発が作るコードが本番環境により適したものになる。そして、共通の目標や責任を強化し、共感を強めるように仕向けていけば、開発と運用の間により協力的な関係を築くことができる。

p.336 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】テストが失敗すると、私たちはとかくもっとテストをしようとする。しかし、プロジェクトの終わりの時期にただテストを増やすようなことをすると、かえって結果が悪くなることがある。特に、増やしたのがマニュアルテストだと弊害が起きやすい。デプロイのバッチサイズが大きくなり、変更の成功率が下がり、インシデントの数が増え、MTTRが長くなる。つまり望んでいるのと逆の結果になるということは、理論からも実践からもわかっていることである。
変更凍結期間を設定してバッチサイズの大きい変更をじっくりテストするよりも、スムースで継続出来な本番デプロイのフローの一部としてテストを日常業務に完全に組み込み、デプロイの頻度を上げるようにしよう。そうすれば、作業に品質を組み込み、もっとバッチサイズの小さい変更をテスト、デプロイ、リリースできる。


p.333 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】ピアレビューでもバッチサイズは小さく保つ。変更のサイズが大きくなると、変更に対して意味のある批評を加える能力は下がっていく。「プログラマーに10行のコードのレビューを頼むと10個の問題点を見つけてきますが、500行のコードのレビューを頼むと、まあいいんじゃないと言われるでしょう」

p.342 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】官僚主義的なプロセスを大胆に取り除く。終わるまで何ヶ月もかかる承認プロセス＝ウォーターフォールのこと。

p.355 【第19章 日常業務での学習の実現と日常業務への学習の注入】 避難なしのポストモーテムイーティングにおいて「もっと注意する」「もっと愚かでないようにする」という対応策は認められない。この種のエラーが再び起きるのを妨げる本物の対応策を生み出さなければならないのである。
そのような対応策として考えられるのは、デプロイパイプラインの危険な条件を検出する新しい自動テストの導入、遠隔測定の追加、ピアレビューを追加しなければならない変更タイプの確定、定期的に設定されたGame Dayに実施される同じタイプのエラーのリハーサルなどがある。

世界でもっとも強力な9のアルゴリズム

コンピュータの世界で長く使われているアルゴリズムを、分かりやすい説明でまとめられている一冊。
対象は検索エンジンのページランクや公開鍵暗号、誤り訂正、データ圧縮など。
時に優しい言い回しすぎて、まわりくどく感じる部分もあるけど、全体的に分かりやすいと思う。

DevOps教科書

一般に言われるDevOpsより扱っている範囲は広い（セキュリティ、アカウント管理等）こともあり、少々記述が冗長でまとまりきっていないような印象は受ける。具体的なツールを挙げるというよりは、どういう考え方を持つべきかという点に着目した形なので、読むのにはわりと骨が折れた。もう一段階具体的なレイヤーに落とし込んでくれるとよかったようにも思う。

テストから見えてくるグーグルのソフトウェア開発 テストファーストによるエンジニアリング生産性向上

テストについての考え方を学べたが、インタビューなどはわりと読むのが面倒くさかった(わりと冗長なないようだった)

テストのベースとなる考え方を作れるので、オススメ。

AIは「心」を持てるのか 脳に近いアーキテクチャ

4万年前の洞窟の壁画からギリシャ時代をへて、「ロボット」や「人間の意識」についての考察をたどり、現代の「脳科学」や「人工知能」へたどり着く。巨人の肩の歴史を哲学やSFそして情報工学や脳科学などから数多くの引用を行い振り返ると共に未来を展望します。AIなどが普及して人間がいちいち判断しなり失敗が無くなると、失敗を通じて成長する私たち人間がどのように変化するのかがとても気になります。

テストから見えてくるグーグルのソフトウェア開発 テストファーストによるエンジニアリング生産性向上

読み終わったー＼(^o^)／
Googleでのテストの考え方、実施手法などの事例集。
コードが書けるテストデベロッパーが必要そうです

世界でもっとも強力な9のアルゴリズム

公開鍵暗号法。

鍵が公開されているのに、なんで暗号化できているんだっけ？
何回読んでも忘れる。
今回もそうだろう。

でも、これまでで一番やさしく、かつ、数学的でした。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
●公開鍵暗号法（P.75-78）
　ステップ1：A、Bが秘密色を選ぶ
　ステップ2：公開色を確認する
　ステップ3：A、Bは自分の秘密色と公開色をまぜた混合色を作り、公開する
　ステップ4：AがBの混合色を持ってくる
　ステップ5：Aは秘密色とBの混合色を混ぜ合わせて、共有用の混合色をBに渡す
　ステップ6：Bは受け取った共有用の混合色から、
　　　　　　　　公開色、Bの秘密色を取り除くと、Aの秘密色がわかる

○混合処理は「離散べき乗」、分散処理は「離散対数」と呼ばれる。
　そして、コンピュータが離散対数を効率よく計算する方法は見つかっていないので、
　離散べき乗は私たちが探している一方通行操作の一種と考えることができる。（P.85）

Effective Ruby

サブタイトルにある「あなたのRubyをより輝かせる48の特別な方法」のとおり、48個のTipsが詳細な解説と考えとともに記されている。数から見るともっとたくさんのTipsが欲しいところではあるが、解説や考えがしっかりと書かれているので、本書を読むのはそこだろう。

対象読者は、Rubyの文法や実行の方法をある程度把握していて、Ruby（含むRails）のプログラムを書いたことがある人のように思う。それまで書いたRubyプログラムの量にしたがって、それぞれ納得する部分が異なるだろう。その面では、繰り返し読むといいかもしれない。

それぞれの項目（Tips）が有用であるかは人それぞれであるが、個人的には、

・項目10 構造化データの表現にはHashではなくStructを遣おう
・項目44から48からなる第8章 メモリ管理とパフォーマンス

が勉強になった。特に第8章は書籍として記されることがあまり無いように思える。

若干解説が分かりにくいところがあるのと、値段が思いの外高いのが気になったので星は3つ。

世界でもっとも強力な9のアルゴリズム

特に新しいものはなかったが復習になった。技術的な用語を使っていないので、人に説明する時の参考にしたい。

テストから見えてくるグーグルのソフトウェア開発 テストファーストによるエンジニアリング生産性向上

テストに関わる仕事の地位向上に寄与し、その分野のスーパースターまで生み出しているGoogleの文化は素晴らしい。開発手法も増えてテストの重要性も上がっていくなかで、まだまだテストに対する意識や重要性の認識が低い気もするため、 良い動きであると思う。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

正論なんだけど、他部署を敵に回すようなことも主張しているので、マネージャーは読んで複雑なのでは。これができれば苦労しないと思いそう。ただメンバーに良い結果出す為の環境を整えてあげると、悪い評価の人をリストラしやすくなりそう。結果に対して言い訳する逃げ道がなくなるからね。ドライな感じはするけど欧米企業はそのあたりも見越して働きやすい環境を作っているのかな。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

人材とは替えがきかない、あるいはきかせるために想像以上にコストを要する。生産性を上げるということはどういうことか。
アメリカの例がふんだんに盛り込まれているので必ずしも日本の事情に当てはまらないが、唸るところの多いエッセイ。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

やる気は大事ってそりゃそうだろうけど、やる気の源泉って環境だったりしてその環境とは何ぞやみたいなぐるぐる回る議論になるのでやる気って言葉は嫌い。でも、デマルコの本を一冊読むたびにソフトウェアのリテラシーが上がることは間違いないのでみなさんぜひ読みましょう。ソフト会社の飲み会みたいなのがあるとしたら、こんなことを話していてほしいというなにか願望のような。