  |
はてなキーワード: javaとは
資格取得向けではない
賛否両論もあると思うが、IT系現場で働いていたり交流すると話に上がる本がメイン
勉強ももちろんだが、現場の話題についていくという点において読んでおいて損はなさそう
| 書籍 | 主なテーマ | 現在の位置づけ |
| ------------------------ | -------------------- | -------------- |
| 人月の神話 | ブルックスの法則、概念的完全性、銀の弾丸 | ソフトウェア工学の最重要古典 |
| ピープルウエア | 生産性、組織、作業環境、チーム形成 | 開発組織論の古典 |
| 達人プログラマー | 技術者の姿勢、抽象化、自動化、変更容易性 | 現代でも読みやすい準古典 |
| Code Complete | コーディング、設計、レビュー、品質 | 実装技術の百科事典 |
| ソフトウェア作法 | UNIX的なプログラム設計と思考法 | プログラミング文化の古典 |
| プログラミング作法 | 命名、デバッグ、テスト、性能、移植性 | C中心だが原則は普遍的 |
| 珠玉のプログラミング | アルゴリズム的問題解決 | 計算量・問題分解の古典 |
| 計算機プログラムの構造と解釈 SICP | 抽象化、評価、言語処理系 | コンピュータ科学寄りの古典 |
| 書籍 | 内容 |
| ------------------------------------------------------- | ------------------- |
| リファクタリング 第2版 | 振る舞いを変えずに内部設計を改善する |
| レガシーコード改善ガイド | テストのない既存コードを安全に変更する |
| Clean Code | 命名、関数、クラス、可読性 |
| テスト駆動開発 | TDDの基本的な進め方 |
| Growing Object-Oriented Software, Guided by Tests | テストからオブジェクト設計を成長させる |
| Working Effectively with Unit Tests | 単体テストの設計とテスト容易性 |
| A Philosophy of Software Design | 複雑性を減らす設計 |
| The Programmer’s Brain | コードを読むときの認知負荷 |
| 書籍 | 位置づけ |
| --------------------------------- | ------------------ |
| オブジェクト指向における再利用のためのデザインパターン | GoFデザインパターンの原典 |
| Head Firstデザインパターン | パターンの入門書 |
| アジャイルソフトウェア開発の奥義 | SOLID、パターン、アジャイル設計 |
| エンタープライズアプリケーションアーキテクチャパターン | 業務アプリの設計パターン |
| 実践UML | オブジェクト指向分析・設計 |
| オブジェクトデザイン | 責務駆動設計 |
| 書籍 | 内容 |
| ------------------------------------------- | ------------------- |
| ソフトウェアアーキテクチャの基礎 | アーキテクチャ特性、スタイル、意思決定 |
| ソフトウェアアーキテクチャ・ハードパーツ | 分割、粒度、データ、トレードオフ |
| Clean Architecture | 依存関係、境界、ユースケース |
| エンタープライズアプリケーションアーキテクチャパターン | 業務システムの設計パターン |
| Domain-Driven Design | 複雑な業務領域のモデル化 |
| 実践ドメイン駆動設計 | DDDの実践的な適用 |
| Building Evolutionary Architectures | 変更可能なアーキテクチャ |
| Fundamentals of Software Architecture | 現代アーキテクチャの概論 |
唯一の正解ではない
「依存関係を内側に向ける」「業務ルールをフレームワークから分離する」という考え方を学ぶ本であり、すべてのアプリを同じ円形の構造にする本ではない
| 書籍 | 内容 |
| ------------------------------------------- | -------------------- |
| データ指向アプリケーションデザインDDIA | DB、分散処理、一貫性、レプリケーション |
| 分散システムタネンバウム | 分散システム全般の教科書 |
| Designing Distributed Systems | 分散システムの設計パターン |
| Release It! | 本番障害、安定性、回復性 |
| Site Reliability Engineering | SRE、SLI、SLO、運用 |
| Building Secure and Reliable Systems | セキュリティと信頼性 |
| Web Scalability for Startup Engineers | Webシステムのスケーリング |
| System Design Interview | システム設計の考え方を広く学ぶ |
| 書籍 | 内容 |
| -------------------------------- | ----------------- |
| マスタリングTCP/IP 入門編 | 日本で最も定番のTCP/IP入門書 |
| コンピュータネットワークタネンバウム | ネットワーク全般の教科書 |
| コンピュータネットワーキング トップダウンアプローチ | アプリケーション層から学ぶ |
| ネットワークはなぜつながるのか | ブラウザからサーバーまでの流れ |
| 書籍 | 内容 |
| ----------------------------------------- | ------------------- |
| 詳解TCP/IP | TCP/IPの古典 |
| TCP/IP Illustrated | パケットレベルの詳細 |
| High Performance Browser Networking | TCP、TLS、HTTP、ブラウザ通信 |
| パケットキャプチャの教科書 | Wiresharkなどを使った解析 |
| 書籍 | 内容 |
| -------------------------------- | ---------------- |
| Real World HTTP | HTTPの歴史と現代的機能 |
| Webを支える技術 | HTTP、URI、REST |
| HTTP: The Definitive Guide | HTTP/1.1時代の体系的解説 |
| Web API: The Good Parts | Web API設計 |
| 書籍 | 内容 |
| -------------------------------- | --------------- |
| オペレーティングシステム 3つの簡単なピースOSTEP | 仮想化、並行性、永続性 |
| Operating System Concepts恐竜本 | OSの標準的教科書 |
| 詳解UNIXプログラミング | UNIXシステムコール |
| Linuxプログラミングインタフェース | Linux APIの詳細 |
| Linuxのしくみ | Linux内部の入門 |
| ふつうのLinuxプログラミング | Linux上でのプログラム実行 |
| 30日でできる！OS自作入門 | OSの動作を作りながら学ぶ |
| コンピュータシステムの理論と実装Nand2Tetris | 論理回路からOSまで |
| 書籍 | 内容 |
| ------------------------------ | --------------- |
| データベースシステム | DB理論の教科書 |
| Database System Concepts | DBの標準的教科書 |
| SQLアンチパターン | よくあるDB・SQL設計の失敗 |
| 達人に学ぶDB設計 徹底指南書 | 論理設計、正規化、性能 |
| 達人に学ぶSQL徹底指南書 | SQLの考え方 |
| SQLパフォーマンス詳解 | インデックスと実行計画 |
| High Performance MySQL | MySQLの性能設計 |
| PostgreSQL徹底入門 | PostgreSQL固有機能 |
| 書籍 | 内容 |
| ------------------------------------------- | -------------- |
| 体系的に学ぶ 安全なWebアプリケーションの作り方徳丸本 | Webセキュリティの国内定番 |
| Web Application Security | Webアプリの脆弱性と防御 |
| The Web Application Hacker’s Handbook | Web攻撃手法の古典 |
| Security Engineering | セキュリティ工学全般 |
| 暗号技術入門 | 暗号、ハッシュ、署名、証明書 |
| マスタリングTCP/IP 情報セキュリティ編 | ネットワークセキュリティ |
| Threat Modeling | 脅威モデリング |
| Building Secure and Reliable Systems | セキュアで信頼できる運用 |
| 書籍 | 内容 |
| ------------------------------------ | -------------- |
| アルゴリズムイントロダクションCLRS | アルゴリズム分野の標準教科書 |
| アルゴリズムとデータ構造 | 大学教科書的な基礎 |
| 珠玉のプログラミング | 問題解決の古典 |
| プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 | 実装を伴う学習 |
| 問題解決力を鍛える！アルゴリズムとデータ構造 | 日本語での実践的入門 |
| The Algorithm Design Manual | 問題に適したアルゴリズム選択 |
| 書籍 | 内容 |
| --------------------------- | ------------- |
| テスト駆動開発 | TDDの原典 |
| ソフトウェアテスト技法ドリル | 同値分割、境界値など |
| はじめて学ぶソフトウェアのテスト技法 | テスト技法の定番 |
| 実践ソフトウェアエンジニアリング | 開発工程と品質全般 |
| Googleのソフトウェアエンジニアリング | 大規模開発、テスト、保守 |
| 単体テストの考え方／使い方 | 良い単体テストの設計 |
| xUnit Test Patterns | テストコードのパターン集 |
| Continuous Delivery | 自動テストからリリースまで |
| 書籍 | 内容 |
| ----------------------------------- | ------------------ |
| The DevOps ハンドブック | DevOpsの実践体系 |
| Accelerate | 開発組織とデリバリー性能の研究 |
| Continuous Delivery | 継続的デリバリーの原典的書籍 |
| Site Reliability Engineering | GoogleのSRE |
| The Site Reliability Workbook | SREの実践 |
| LeanとDevOpsの科学 | Accelerateの日本語版 |
| Infrastructure as Code | IaCの原則 |
| Kubernetes Patterns | Kubernetes上の設計パターン |
| Release It! | 本番耐性と障害対策 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
| Kubernetes完全ガイド | Kubernetesの体系的な理解 |
| Kubernetes Patterns | Kubernetesの設計パターン |
| 入門 Kubernetes | Kubernetesの概念 |
| Docker系の入門書 | コンテナの操作 |
| Infrastructure as Code | インフラのコード化 |
| Cloud Native Patterns | クラウドネイティブ設計 |
| クラウドデザインパターン | クラウド上の設計パターン |
AWS、Azure、Google Cloudについては、以下を優先する
| 書籍 | 内容 |
| ------------------------------------- | -------------- |
| 要求工学系の教科書 | 要求の抽出・分析・管理 |
| ソフトウェア要求 | 要求定義の体系 |
| ユーザーストーリーマッピング | ユーザー行動と開発計画 |
| ユースケース実践ガイド | ユースケース記述 |
| RDRA2.0ハンドブック | 要求とシステム構造の整理 |
| 実践ドメイン駆動設計 | 業務モデリング |
| Domain Modeling Made Functional | 型を使ったドメインモデリング |
| イベントストーミング | 業務知識の探索 |
| 書籍 | 内容 |
| ------------------------- | ------------ |
| 誰のためのデザイン？ | 人間中心設計の古典 |
| インタフェースデザインの心理学 | 認知心理とUI |
| ノンデザイナーズ・デザインブック | レイアウト・配色・文字 |
| Don’t Make Me Think | Webユーザビリティ |
| About Face | インタラクションデザイン |
| デザインシステムの育て方 | デザインシステム |
| Lean UX | 仮説検証型のUX開発 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
ドライバ開発においてAI（LLM）が生成したコードをそのまま信頼するのが危険な理由は、単に「コードが間違っている可能性がある」というレベルを超え、**「AIが物理世界（ハードウェア）の挙動を直接観測できない」**という根本的な制約に起因します。
具体的に、なぜ不安定になりやすいのか、4つの技術的な視点から解説します。
ハードウェアには、マニュアルに書かれていない挙動や、特定の条件下でのみ発生するバグ（エラッタ）が必ずと言っていいほど存在します。
AIの限界: AIは「公開されている一般的な情報」を学習していますが、特定のチップの特定のバージョンにおける隠れた不具合（エラッタ）への対策コードを生成することは困難です。
リスク: 仕様通りに書いているのに、特定のタイミングでチップがハングアップする、といった現象を防げません。
通信処理（I2C、SPI、UARTなど）では、信号を「HIGH」にしてから「LOW」にするまでの待ち時間など、厳密なタイミングが求められます。
AIの限界: AIは論理的な手順は書けますが、実行環境（CPUクロック、OSのスケジューリング）における実時間の経過を考慮したウェイト処理を正確に組み込むのが苦手です。
影響: 通信波形が乱れ、データ化けやデバイスの認識失敗が頻発する原因になります。
ドライバは通常、OSの核心部（カーネル空間 / Ring 0）で動作します。
致命的な違い: アプリケーション層のプログラム（PythonやJavaなど）であれば、エラーが出ても「アプリが落ちる」だけで済みますが、ドライバの不備は**OS全体のクラッシュ（ブルースクリーンやカーネルパニック）**に直結します。
AIの弱点: 割り込みハンドラ内での禁止事項（メモリ割り当ての制限やスリープ不可など）を、AIが完璧に守り切るのは非常に難易度が高いです。
ドライバは、メモリの特定の番地（レジスタ）に値を書き込むことでハードウェアを動かします。
AIの弱点: AIはよく似た型番のチップのレジスタマップを混同することがあります。
結果: 全く別の機能を操作してしまったり、予約済みの領域を上書きしてハードウェアを物理的に損傷（過熱や過電圧など）させたりするリスクもゼロではありません。
AIをドライバ開発に使う場合は、**「コードを書かせる」のではなく「レビューの壁打ち相手」や「定型文の生成」**に限定するのが賢明です。
