Life『UNIXという考え方』を読んだ『UNIXという考え方』は、UNIXというOSがどのような考え方で設計されているか解説した本。2023年現在、UNIX系OSであるLinuxはサーバの世界を支配している。一方で、クライアントの世界においても、UNIX系OSは広く使われている。iOSやAndroidはもちろん、ゲームコンソールでもUNIX系OSが採用されることは多い。Windowsは今でも大きなシェアを持っているが、以前ほどの支配的な立場にはない。その理由はさまざまに考えられるが、一つの要因に「UNIXの考え方」があるのは間違いないだろう。本書では、「UNIXの考え方」をいくつかの定理にして紹介している。それらの定理を簡単にまとめると、小さなプログラムをいくつも組み合わせて連携させることで、「梃子の原理」でアプリケーションを作り上げる、ということになると思う。UNIXでは、単機能のプログラムが大量に用意されている。それらは「フィルタ」として動作するよう作られているので、簡単に組み合わせることができる。UNIXに習熟したユーザは、これらのプログラムを組み合わせて、自由に高機能なプログラムを作ることができる。UNIXがコンピュータのプロに愛用されているのはこのような理由だろう。一方で、UNIXでは「自分の足を自分で撃ち抜く」ことが簡単にできる。単純なコマンド一つでコンピュータを完全にめちゃくちゃにすることができる。このような自由はコンシューマ向けOSではトラブルの元になるため、モバイル機器やゲームコンソールのOSは、ユーザのできることを大幅に制限している。これらのOSは、UNIX系OSをベースにしているものの、本書でいうところの「OpenVMS的な考え方」で作られている。UNIXの哲学を学ぶことで、UNIX系OSをうまく使えるようになることが期待できる。いう意味で、コンピュータのパワーユーザを目指す人であれば読んで損はないと思う。本書はあくまで「考え方」を解説した本である。明日からの仕事に役立てられる人はそう多くないと思う。実用性を求める場合は『達人プログラマー』などを読んだ方が良いかもしれない。(『UNIXという考え方』を読んだ)『ソフトウェア品質を高める開発者テスト』を読んだ『ソフトウェア品質を高める開発者テスト』は、テストを通してソフトウェアの品質を上げるための方法論について解説した書籍。テストに関する書籍の中には、ソフトウェアテスト技術者をターゲットにしたものが多いが、本書はソフトウェア開発者をターゲットにしている点が特徴。ある程度大きなチームでソフトウェアを開発している場合、ソフトウェアを開発するチームとは別にテストを担当するチーム(いわゆるQAチーム)がいることが多い。そのような環境では、QAがソフトウェアの品質を守るゲートキーパーの役割を果たすことが少なくない。QAチームによるテストでバグを見つけて修正することは効率が悪い。ソフトウェアのバグを修正するコストは、下流工程ほど高くなるから。したがって、バグはできる限り要求仕様やコーディングの段階で修正することが望ましい。現実にはそのような開発体制が取れていることは少ない(と著者は述べている)。どのようにしてソフトウェアの品質を上げ、開発効率を改善していくか、というところが本書の主題になる。本書の提唱する手法のうち、最も効果が高く、ぜひとも導入すべきなのは単体テストである。本書では、単体テストを「関数の網羅率を計測しロジックの確らしさを確認するホワイトボックステスト」と定義している。コードの品質を上げるためには単体テストは欠かせない。単体テストがちゃんと書けていることを確認するには、カバレッジの計測が必要だし、アサーションをちゃんと書いていることをレビューする必要もある。十分なカバレッジを確保できていれば、ミューテーションテストを使って単体テストの抜け漏れを確かめることもできる。この点、本書は「C1カバレッジ(分岐網羅)で80%」という数字を提唱している(医療や自動車などミッションクリティカルなソフトウェアは「100%」)。この数字は決して低くはなく、レガシーアプリケーションにテストを追加しようとする場合には絶望的な数字に思える。そのような場合は、本書でも紹介されているHotSpotという手法を用いて、最もバグの出る可能性の高い部分から単体テストの追加を始めることが望ましい。単体テストに加えて実施すべき手法としては、コードの静的解析による複雑度の計測とリファクタリング、コードレビュー、ペアプログラミングなどがある。これらの手法でコードの品質を高めれば、システムテストで検出されるバグの数は少なくなる。そこで、システムテストを大胆に省略し、探索的テストによって効率的にテストした上でリリースする、という状態まで持っていくことができれば、本書のゴールは達成できたことになる。ソフトウェアの品質に悩んでいる開発者はもちろん、もっと素早く効率的に開発したいと思っている開発者も、一読をお勧めしたい。逆転だ!』は、ITに問題を抱えている企業が、ITを我が物として業績を上げていくまでの物語。原書は2013年、邦訳は2014年。実際、本書の中でDevOpsが登場するのはかなり後半で、デリバリーの速度を上げるための施策として登場するに過ぎない。それよりも前の段階で、まず混乱したITの立て直しが行われる。ここで登場するのがゴールドラットの制約理論。本書の前半ではIT運用のボトルネックを特定し、それを改善するために頭をひねることになる。ITとビジネスを緊密に結びつけることで会社が業績を上げるためにITを活用できるようになっていく。主人公が務めるパーツ・アンリミテッドは自動車部品を製造している企業で、主人公は工場の製造ラインの最適化の方法からさまざまな学びを得てITを改善していく。このような筋書きを見ると思い浮かぶ言葉は「DX」で、実際いまこの本が出版されるならタイトルにこのキーワードが盛り込まれると思う。このように、本書は制約理論やDevOpsを学ぶための参考書なのだが、ITを題材にした小説としても一級品の出来になっている。面白いのは前半で繰り広げられるトラブルの山。会計システムの不具合によって給与が支払えなくなったり、電話システムが壊れて顧客と連絡ができなくなったり、POSシステムが動かなくなってクレジットカード決済を手動でやったりと、とにかく大量の障害に振り回される。そんな中でもなんとか秩序を取り戻そうと奮闘する主人公をついつい応援してしまう。DevOpsや継続的デリバリーについて学びたくて本書を手に取ると、前置きが長くてまだるっこしく感じられると思う。これらを支える理論的背景を学ぶことができる本書は、自分にとっては学びの多い内容だった。次は『ザ・ゴール』を読んでみたい。guide』は、ITエンジニアの採用面接における「システムデザイン面接」への対策方法を解説した書籍。システムデザイン面接とは、例えば「Facebookのようなニュースフィードシステムを設計してください」とか「チャットシステムを設計してください」といった問題について回答する面接のこと。日本語でシステムデザイン面接対策を謳った書籍は見たことがないので、日本でこういった質問をする企業はまだ多くないと思われる。海外では一般化しており、対策書がいくつも出版されている。Zu氏による本書は、定番書として人気がある。Primerというオープンソースのコンテンツも人気があり、日本語訳もされている。個人的には書籍というフォーマットが好きなので、本書を手に取ってみた。本書は、通して読むことでシステムデザインの基本的な考え方(仕様の明確化、見積もり、スケールさせ方など)が身に付くようになっている。システムデザインのキモは、要件に合わせて適切な技術を選択し、スケールするシステムを設計するところにある。Webサービスで利用可能なクライアント・サーバ間の通信技術には色々あるが、チャットのように双方向のコミュニケーションが求められるサービスにはWebSocketが適している。Pollingが適している。このような考え方は、面接だけでなく、業務でシステムを設計するときにも活かすことができる。英語は平易で読みやすく、英語の技術書に挑戦してみたい、という人にもおすすめできる。本書のコンテンツはByteByteGoというサイトでオンラインでも提供されている。全てのコースを見るにはサブスクリプション(¥8,291/年)が必要だが、一部のコンテンツは無料で公開されているので、雰囲気をつかみたい人はまずByteByteGoを覗いてみると良いと思う。2』)のコンテンツがあるので、腰を据えて取り組むつもりならByteByteGoのサブスクリプションに登録するのもおすすめ。guide』を読んだ)『SQL実践入門』を読んだ『SQL実践入門』は、サブタイトル「高速でわかりやすいクエリの書き方」にもあるように、SQLのパフォーマンス改善に焦点を当てた書籍。著者はSQL関係の書籍で定評のあるミック氏。SQLのパフォーマンスチューニングは一朝一夕で身に付く技術ではない。RDBMSのアーキテクチャやSQLの基礎知識はもちろん必要だし、RDBMS製品に応じた実行計画の読み方やチューニングの勘所もある。それに加えて、アプリケーションの要件に合わせたチューニングも必要になる。本書では、特定のRDBMS製品やアプリケーションに依存しない、汎用的なクエリチューニングのテクニックを、その前提となる基礎知識も含めて解説している。SQLのチューニングはトレードオフが色々あるため、one-size-fits-allな解法はない。インデックスが使われていないSELECT文のチューニングではインデックスの活用が第一の選択肢に挙がるが、選択率次第ではフルスキャンの方が速いし、更新性能の劣化も考慮する必要がある。このように、本書に登場する様々なテクニックは、それらが有効になる場面を見極めて活用しなければ効果は見込めない。本書は、JOINのチューニングで困ったら6章を読む、といった風に辞書的に使うこともできるが、前章までの知識が前提となっていることもある。通読しておいて、後で必要に応じて読み返す、という使い方が良さそう。WordPress.。