クイープの作品一覧
「クイープ」の「Pythonによるディープラーニングと生成AI・LLM」「今すぐ実践！ カンバンによるアジャイルプロジェクトマネジメント」ほか、ユーザーレビューをお届けします！
- 作者をフォローする
- フォローすると、この作者の新刊が配信された際に、お知らせします。
作品一覧
-
Pythonによるディープラーニングと生成AI・LLM
ビジネス・実用
-1巻4,994円 (税込)※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。 生成AI時代のエンジニア必須知識を Keras開発者が"コードファースト" で解説！ ベストセラーとなったManning刊 "Deep Learning with Python" が全面的に書き直され、Transformer、GPTライクなLLMの構築、拡散モデルを用いた画像生成などの新章も追加されました。ディープラーニングを段階的に理解できる実践的なプロジェクトとコード例が各章で紹介されます。 ●目次 1章 ディープラーニングとは何か 2章 ニューラルネットワークの数学的要素 3章 Tensorflow、PyTorch、JAX、Keras 4章 分類と回帰 5章 機械学習の基礎 6章 機械学習の普遍的なワークフロー 7章 Kerasを深く理解する 8章 画像分類 9章 ConvNetアーキテクチャパターン 10章 ConvNetが何を学習するのかを解釈する 11章 画像セグメンテーション 12章 物体検出 13章 時系列予測 14章 テキスト分類 15章 言語モデルとTransformer 16章 テキスト生成 LLM（大規模言語モデル） 17章 画像生成 18章 実務におけるベストプラクティス 19章 AIの未来 20章 本書のまとめ ●著者 Francois Chollet（フランソワ・ショレ）：2012 年に学術界でディープラーニングが注目を集めるようになって以来、ディープラーニングに取り組んでいる。最も広く使われているディープラーニングフレームワークの1 つであるKeras の作成者。Keras は、大学の授業、Google、Netflix、Spotify などの企業、そしてCERN やNASA などの科学機関で使われている。最先端AI システムを研究するNdea 研究所の共同設立者であり、機械知能を測定するARC-AGI チャレンジを創設した。 Matthew Watson（マシュー・ワトソン）：2018 年以降、Gemini モデルやGoogle のオープンソースディープラーニングエコシステムの開発を含め、Google 全体で機械学習に携わっている。Keras のコアメンテナーであり、自然言語処理のためのKeras ツールの開発に注力している。スタンフォード大学でコンピュータサイエンスの修士号を取得し、Stanford Graphics Lab で手続き型モデリング技術の研究を行った。 ［監訳］巣籠 悠輔（すごもり ゆうすけ）：株式会社MIRA代表取締役、株式会社マルイユナイトCTO。医療AIベンチャーを創業・CTOを務め、同社エグジット後は生成AI活用やDX等の技術支援を大手企業・ベンチャー問わず行う。2018年にForbes 30 Under 30 Asia 2018 に選出。著書に『詳解ディープラーニング』、監訳書に『つくりながら学ぶ！LLM 自作入門』（マイナビ出版刊）等がある。 ［翻訳］株式会社クイープ： コンピュータシステムの開発、ローカライズ、コンサルティングを手がけている。最近の主な訳書に『つくりながら学ぶ！ LLM 自作入門』『Python による時系列予測』（マイナビ出版）、『Python ではじめるクリーンアーキテクチャ』『LLM 本番システム構築ノウハウ』『グランドマスター三冠のKaggle ノートブック開発術』（インプレス）、『Exercise Go プログラマ脳を鍛える至高の問題集』『Exercise Python プログラマ脳を鍛える至高の問題集』『Exercise JavaScript プログラマ脳を鍛える至高の問題集』『Exercise C++ プログラマ脳を鍛える至高の問題集』『なっとく！アルゴリズム第2 版』『爆速Python』（翔泳社）、『Python クイックリファレンス 第4 版』（オライリー・ジャパン）、『犯罪捜査技術を活用したソフトウェア開発手法』（秀和システム）、などがある。 ※この商品は固定レイアウト型の電子書籍です。 ※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字列のハイライトや検索、辞書の参照、引用などの機能が使用できません。 ※お使いの端末で無料サンプルをお試しいただいた上でのご購入をお願いいたします。 ※本書内容はカラーで制作されているため、カラー表示可能な端末での閲覧を推奨いたします -
More Effective Agile “ソフトウェアリーダー”になるための28の道標
ビジネス・実用
3.81巻2,970円 (税込)開発者必読のロングセラー『Code Complete（コードコンプリート）』の著者として著名なスティーブ・マコネルの新刊が15年ぶりに登場！ 本書は“More Effective Agile: A Roadmap for Software Leaders”（Construx Press、2019年）の日本語版です。企業活動やビジネスが今後ますます「ソフトウェアファースト（ソフトウェア主導）」になっていく中で、リーダーシップを発揮できる人材である「ソフトウェアリーダー」を目指すために、アジャイルから「価値を引き出す」ための実践的なプラクティスを解説します。監訳者にはアジャイル分野で著名であり、『Adaptive Code（旧名『C#実践開発手法』）』で実績のある長沢智治氏を起用しました。 -
なっとく！ディープラーニング
ビジネス・実用
-1巻2,860円 (税込)機械に学習させる調教師への道 【本書の内容】 本書は Andrew W. Trask, "Grokking Deep Learning", Manning Publications 2019 の邦訳版です。 本書は「機械が学習する」というテーマのもと、 その根幹を成す「ディープラーニング」という手法を平易に解説した書籍です。 一般に「ディープラーニング」というと、その背景となる数学的厳密性を全面に押し出し、 微に入り細に入る解説が仇となって、面白くなるとばぐちでリタイアすることになりがちです。 本書は数学的厳密性はそこそこに、むしろディープラーニングの全体像を俯瞰し、 ディープラーニングがカバーする範囲とその構築方法、 そしてそのための基礎知識をイメージしてもらえるように工夫しています。 Webアプリケーションを開発する際に、フレームワークによってインフラを意識することなく サービスを構築できるようなスタイル、と言えばいいでしょうか。 なにはともあれ、最初に提示されるPythonコードを「暗記」してみてください。 それを拡張することで、機械に学習させる「調教師」になれることが分かるはずです。 【本書のポイント】 ・数式を使った基礎理論ではなく「扱える」ディープラーニングを学べる ・線形代数、微積分、凸最適化はもちろん、機械学習の知識も前提としない ・ニューラルネットワークの基礎から上位層やアーキテクチャを学べる ・Python 3.x系で実際に試せる 【読者が得られること】 ・ディープラーニングの全体像 ・ニューラルネットワークの基礎 ・学習精度の上げ方 ※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。 ※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。 ※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。 ※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。 -
入門Haskellプログラミング
ビジネス・実用
5.01巻4,180円 (税込)「コンピュータのプログラミング」から脱却し、 “学術”ではない、実用度重視のHaskell入門書 Haskellは、関数型プログラミングを研究する対象としての側面が強すぎ、一般的なアプリケーション構築を目的とした開発言語の側面が、おざなりにされがちでした。そのため、他の言語（JavaとかC/C++とかC#とか）がこなす、ありふれたアプリケーションをHaskellで構築しようとすると、キーボードを叩く指が止まってしまうことがありました。本書は関数型プログラミングの基本を押さえつつ、実用的なプログラムを書けるようなレベルに誘う一冊です。 もちろん、そのためにはプログラミング言語としての基礎的な知識や、Haskellならではの技法・手法の理解が欠かせません。本書では、最終的にI/Oを使用し、乱数を生成し、DBアプリケーションを作れるところまで道筋を示します。 二度とHaskellに触れないとしても、この言語（と、その思想）に触れることで、 ・安全で機能的なコードを書くこと ・問題を注意深くモデル化すること を身につけることができます。 この本は、 ・プログラミングスキルとプログラミング言語の理解を次のレベルに引き上げたい、既存のプログラミング経験のある人 を対象としていますが、根気強く読み解いていけば、必ず視野は広がります。 本書は Will Kurt , "Get Programming with Haskell" ISBN 9781617293764, Manning Publications Co., 2018 March の日本語版です。 ※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。 ※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。 ※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。 ※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。 -
マイクロサービス with Docker on Azure
ビジネス・実用
3.01巻3,300円 (税込)本書の対象読者は、マイクロサービスベースのアプリケーションをAzureで構築することに関心がある人全員です。本書を読んだ後は、マイクロサービスベースのアプリケーションの利点と課題の両方をしっかり理解できているはずです。Azureでマイクロサービスベースのアプリケーションを一から設計するか、既存のモノリシックなアプリケーション（モノリス）を徐々にマイクロサービスに分割するにあたって応用できる知識が得られるでしょう。 本書では、以下の情報を提供します。 ・マイクロサービスベースのアプリケーションと従来のモノリスとの違い、およびそれぞれのアプローチの長所と短所。 ・マイクロサービスアーキテクチャのコンテキストにおけるDockerコンテナー、Dockerの基本的な操作、およびAzureでDockerホストを作成する方法。 ・マイクロサービスベースのアプリケーションの開発環境とDevOps環境をセットアップするためのベストプラクティス。 ・Azureのクラスターとコンテナーのオーケストレーション機能。 ・コンテナー化されたマイクロサービスアプリケーションを監視するためのベストプラクティスと、Azureで利用可能な監視ツール。 ・Azure Service Fabricの概要と、Azure Service Fabricを使ってマイクロサービスベースのアプリケーションを開発する仕組み。 -
今すぐ実践！ カンバンによるアジャイルプロジェクトマネジメント
ビジネス・実用
4.01巻2,750円 (税込)理論から実践へ！ アジャイルに踏み出せなかった現場に贈る、効率的なチーム運営の秘訣とは？ ソフトウェア開発における「カンバン」（英語でもKanban）は、トヨタのジャストインタイムスケジュール管理メカニズムに基づくプロジェクト管理手法のこと。本書は“Agile Project Management with Kanban”（Microsoft Press, 2015）の日本語版で、カンバン方式によるソフトウェア開発プロジェクトの実践方法を、著者自身の実体験に基づいて具体的に解説します。 ――――――――――「監訳者あとがき」より抜粋―――――――――― 本書は、最初から最後まで、「現場目線」を貫いています。「現場目線」とは、現場がカンバンを理解し、実践するための自然かつ最短距離な構成であるということです。具体的には、カンバンを現場に導入するとしたらこの順番に理解したほうがいいという構成になっています。各章とも、実践的な解説、よくある質問と回答、トラブルシューティング、そしてチェックリストという構成になっています。 -
脱オンプレミス！ クラウド時代の認証基盤 Azure Active Directory 完全解説
ビジネス・実用
-1巻4,070円 (税込)アイデンティティ管理の新たな選択肢、IDaaS（Identity as a Service）を実現する、 クラウド版Active Directoryを徹底解説！ “Modern Authentication with Azure Active Directory for Web Applications”（Microsoft Press, 2016）の、待望の日本語版が実現しました！ Webアプリケーション向けに、Azure Active DirectoryによるID管理の仕組みと、その方法を解説します。原著者は米国マイクロソフト本社でAzure Active Directoryのプロダクトマネージャーを務めるVittorio Bertocci氏。日本語版の監訳は、日本マイクロソフトのインフラ系エバンジェリストである安納順一氏と、Microsoft MVPで、アイデンティティ分野で数多くの解説記事を執筆する富士榮尚寛氏が担当。米国と日本のスペシャリストたちがガッチリとタッグを組んだ1冊です。クラウド時代の企業システムを担う開発者、システムアーキテクト、インフラエンジニアにぜひお勧めします。 -
Code Complete 第2版
ビジネス・実用
4.51～2巻6,710円 (税込)ソフトウエア開発の方法論を幅広く網羅した入門書。上巻は設計やプログラミング、下巻はテストやデバッグを扱う。1993年発行の第1版を、Webアプリケーションの普及などを踏まえて大幅に改定した。著者はソフトウエア工学の第一人者で、知識体系「SWEBOK」の構築を主導する。計1200ページを超える大部だが、ソフト開発プロセスを建築設計にたとえるなど、難解になりがちな内容を分かりやすくまとめている。
ユーザーレビュー
-
-
-
Posted by ブクログ
# 1周目 読み終えた
タイトルである「CODE COMPLETE」からは、どうやって優れたコードを書くかに書かれた本であるかのような印象を与えられる。それに間違いはないけど、こういうところこうかくべきとか、直接的な指示を与えるようなものではない。最終的には品質の高いソフトウェア、すなわちコードを生み出すのが目的となる。それには、単にプログラミング言語のルールを覚えて、盲目的にコードを書けばいいというわけではない。最終的なコードに至るまでの道のりは、思っている以上に長い。この本は、それらを体系的にまとめてあって、信頼できるガイドラインとして利用できる。読み終えて、コードに対して違った見方をするようになったかもしれない。大きな組織で大人数で開発する場合でも、小さな組織で少人数で開発する場合でも、一人で開発する場合であっても、役に立ちそうなことが書かれていた。
## 35章を読んだ
「さらに情報を得るには」
参考文献、というか、参考程度ではなく、読むべきであるという推奨文献の紹介になっている。著者の会社では、開発者の段階によって読まないといけないものが読書計画として組み込まれているらしい。初級、実践、プロフェッショナルという段階になっていて、この本は初級に位置している。
この本で利用された本当の意味での参考文献は、最後にリストとして大量に掲載されている。読者を誘導するためというより、情報の正確さを裏付けるためのものではあるだろうが、情報源の広さに驚かされる。
## 34章を読んだ
「ソフトウェア職人気質とは」
実質最後の章となる。これまでの長い旅の総まとめみたいな内容になっている。これから先、読み直したいけど時間がないというときは、この章をまず読むと良さそうだ。
プログラミングは芸術か科学かという問が上巻の最初の方にあった。ここで、完全な芸術でも科学でもなく、どちらにも分類されない職人技だと答えを出している。そうしたラベル付がさして重要なわけではないが、芸術家気分で、芸術作品を作るほどには独創的にはいられないし、科学者気分で、厳密な実験と検証のプロセスによってプログラミングをすることもできないことを考えれば、職人技に分類するのは的を得ている。どちらにせよ、プログラミングはプログラミングであって、どのような職人仕事とも違っている。別のところから、そのまんま仕事の鉄則を持ってくることなどできない。しかし、職人気質というと根本的なところで、何か共通するものがあると思わされる。
## 33章を読んだ
「個人の資質」
ただ資質といわれてもよくわからない。才能と混同してはいけないようだ。才能と資質はあまり関係が内容で、才能は重要ではない。自分に才能があると思い込んでいるようなのは、そこら中にありふれている。そして、たいていそれらの資質はひどいように思う。謙虚さや知的な誠実さが完全に欠けてているからだと、そういうことだと思う。自分はどうなのかというと、控えめに言っても才能も資質もなく、正式な教育を受けたわけでもなく、適正が高いとは言い難い。それでも、好き好んで楽しくソフトウェアに関わっているのだから、別にいいかと思う。
プログラマーの3大美徳という名称で、傲慢、怠惰、短気というのが知られている。謙虚さや知的な誠実さに一見相反するようにも思える。しかし、それほど相性が悪いものではないように思える。本当にだめなのは、奮闘や努力のようなものらしい。
この章は、自己啓発的な内容で、ちょっと戸惑う部分があった。普段、自己啓発など全くしないし、そのような本を読む機会がない。読みたいとも思わない。それじゃだめだということで、もし必要であるなら、この章をベースにしとくのが良さそうだ。
## 32章を読んだ
「読めば分かるコード」
コメントの書き方を中心に議論されている。ここまで徹底的にやっているのを他に見つけるのは難しいだろう。悪いコードをコメントで説明するな、コードを直せというのが基本になる。ただし、これはコメントを全く書かないでも良いということを意味するのではない。単純なget/set以外のルーチンには、その簡単な概要をつけるべきとある。ファイル、クラスなども同じで、全体像を把握するのに役立つ概要を添えるべきとなっている。コメントは多すぎても少なすぎても逆効果になりうる。常識的な範囲でやれば良いようだけど、常識というのは人によって異なるところもあり、あまり当てにならない。この章はそのガイドラインとなるだろう。
最近Pythonを少し書いているのだけど、テキストエディタにflake8というコードを検査するツール、要はLintみたいなのが統合されている。それによって、すべてのファイル、クラス、メソッドにdocstringという文書化されるコメントのようなものを記述することが要供される。エラーになるわけではないけど、書かないとその場所がハイライトされて見苦しいので、無視するのは得ではない。鬱陶しいと思わずに、良いコメントを書く練習にすると良いかもしれない。
## 31章を読んだ
「レイアウトとスタイル」
レイアウトとスタイルとは、代表的なのはインデントをどうするかとか、空白文字をどこに入れるかとか、ブロックの始まりと終わりのカッコをどこに置くかとか、そういう厄介な話。ほとんどは美的感覚や、よく見かけるコードをお手本として経験を積んでいくうちに形成される嗜好と、それほどかけ離れたものは推奨されていない。加えて、単に好みや感覚からだけ良い悪いを判断するのでなく、きっちりとなぜ良いのか、悪いのかの理由が示されている。C++のレイアウトスタイルは、開発者によってかなりばらつきがある。別々の個人やプロジェクトが、全く同じレイアウトとスタイルになっているもののほうが稀だろう。clang-formatのような整形ツールでも、細部まで細かく調整できるようになっていることからも、細部までこだわるプログラマの習性が反映されている。何も考えずにGoogleスタイルを選択するケースのほうがまれかもしれない。
この章では、きっちり理由をしめして、いくつかのスタイルを推奨している。しかし、全部に賛同できるような人はまれだろう。最初に「ここでは読者の同意をえることよりも、フォーマットスタイルの問題について検討してもらうことに重点をおいている。」と書かれている。今、自分が採用しているスタイルが本当に優れているのか意識しておくきっかけになれば良い。ある種の原則のようなものを確立して、それに一貫して従うことの方がずっと重要になる。
## 30章を読んだ
「プログラミングツール」
これまでとちょっと毛色が違う章で、話題が順に展開されていくのではなく、箇条書き的に各ツールが担当する役割を紹介していっている。具体的な製品名は挙げられていない。
あまり、あるいは全く馴染みのないもの：
設計ツール
テンプレート
相互参照ツール
測定結果を報告するツール
再構築ツール
コード翻訳ツール
データディクショナリ
コード生成ウィザード
テストツールにリストアップされているうちの多く
実行プロファイラ
最後に、画期的なツールの登場によってプログラミングが不要になるかという点にかかれている。最初にそのようなことが言われたのはFORTRANの登場で、FORTRANによってプログラマが不要になって、科学者やエンジニアが自由にプログラムを書けるようになるといわれていたらしい。実際にはそうはなっていない。現代ではAIがプログラミングを不要にするかどうかという面白い話題があるが、おそらく同じところに行き着くのではないかという感じがする。何かしら良い方向での影響はあるだろうけど、AIを利用したプログラミングスキルが求められるようになるというところでとどまるのではないかと思っている。
## 29章を読んだ
「統合」
「統合」とは一体なんなのか。「分割されているソフトウェアコンポーネントを一つのシステムに統合するソフトウェア開発のアクティビティを指す。」と書かれている。一番愚直な方法は、コンポーネントを個別に完成させて、全部出来上がったらばーんとくっつけてうまくいくことを祈るというもので、フェーズ型と名付けられている。これはほとんど良い方法ではない。どこでエラーが発生したのか、発見が困難になる。それに対して、少しずつ統合していく方法をインクリメンタル型といって、これが現実的な方法になっている。さらにインクリメンタル統合は、システムのどの部分から順番に統合していくかによって、いくつかの手法が考案されている。どれも利点と欠点があって、常に最適となるものはない。各手法をミックスさせたハイブリッドなアプローチが好まれているらしい。
統合をどのように行うかというと、デイリービルドとスモークテストによって行う方法が挙げられている。デイリービルドは、そのまんま、毎日ビルドすることで、スモークテストは、煙が出ていないかをテストするという意味で、比較的簡単な検査のことだ。デイリービルドは1日1回のビルドを推奨している。それ以上、つまりcontinuousだとやり過ぎだと書かれている。最近の流行は継続的インテグレーションで、頻繁にビルドを行うことが流行している。この本の書かれた当時はまだ地位を築いていなかったようで、もし、改訂版が出るとしたらそのことにも触れられるのだろう。スモークテストは軽視してはならず、これなしではデイリービルドは意味がないらしい。具体的な方法までは書かれてないので、気になるところだった。
## 28章を読んだ
「コンストラクションの管理」
プログラマとしては、管理しようとするものとどうやって向き合っていくかのヒントになる。そのような管理しようとする力には違和感を覚えることが多く、そうでなければ幸運だ。かといって、全く力を加えずに無秩序であるほうが良いということは意味しない。たとえプログラマ一人だけのプロジェクトであっても、自分自身でプロジェクトを管理しなければいけないわけで、その場合、管理の失敗は自分の責任であって、影響は少ないが、やはりないよりはマシだ。管理者を管理する必要があり、自分自身の場合を除いて、割と高度な人間スキルが要求される。管理と称して現場で力を振りかざしているのは、「技術的な進化が遅れているものー単細胞生物と氷河期に絶滅したマンモスの中間にある何かー程度」でしかなかった。この章でも、コードチューニングで出てきたように、測定をすることが重要だと説かれれている。測定に反対することは、プロジェクトに何が起きている知らない方が良いといっているようなものだ、とまで書かれている。ただ、プログラムの性能と違って、プロジェクトの測定というのにはあまり馴染みがない。この章は興味深い。プロジェクトが遅れたらどうするかに対して、「プロジェクトが失った時間は、取り戻すことはできない。ますます遅れるだけである。」と書かれているのは記憶に残った。
## 27章を読んだ
「プログラムサイズが及ぼす影響」
プロジェクトの規模が大きくなると、エラーの数が多くなる。このことは直感的に理解できる。しかし、さらに悪いことに、プロジェクトの規模をコードの行数で考えたとして、同じ量のコードあたりのエラーの割合、言い換えればエラーの密度も高くなるので、単純に規模に比例してエラーが増えるわけではない。例えば、1000行あたりのエラーの数は4倍以上にもなることがある。また、プロジェクトの規模が大きくなると、生産性も落ちる。エラーはコンストラクションだけでなく、それ以外のアクティビティでの方もエラーの発生が大きくなり、その増加倍率はコンストラクションよりも高い。
これらのことから、小規模なプロジェクトの実績から類推して、単純に大規模な掛け算でプロジェクトのコストを見積もると、少なく見積もることになってしまうことになる。
プログラマが50人もいるような、そんな大規模なプロジェクトに従事したことがないし、これからもおそらくないだろうからあまり危機感がわかない、というのが本音だ。
## 26章を読んだ
「コードチューニングテクニック」
前章を踏まえて、本当にコードに手を加える必要があるのかどうかかを検討した上で、必要ならばやっていく。ここでも絶対に忘れてはいけないのは、必ず測定をするということだ。測定をしていないチューニングは効果は全く見込めず、コードを見にくくして保守性を下げる効果がついてくる。測定を行って最適化が必要なポイントが明らかにする。そして、禁断の扉を開けると、チューニングを行うためのテクニックはたくさん存在している。しかし、どのようなテクニックでも画一的に適用できるものではなく、ある環境では改善するが、別の環境では待った効果がなかったり、悪化してしまうことすらある。直感は全く当てにならない。必ず結果も測定しなければいけない。この章で紹介されているテクニックは、かなり簡単に施せるものだけど、言語の環境によって効果が予測困難であることを、データで見せてくれている。個々のテクニックを道具として引き出しに入れておくことは良いことだけど、どのようなテクニックも、いつでも使えるものではないことをしっかりと認識しておくことのほうが重要だ。
## 25章を読んだ
「コードチューニング戦略」
コードチューニングとは、大雑把に言うとコードの最適化のことを指している。2章に分けられていて、この章ではどういう姿勢で望むべきか、何をチューニングするのか、その判断基準は何なのかなど、一歩下がったしてから見たガイド、要は見出しにあるとおり「戦略」が語られている。最適化に移動もうとするときに思い出される「早まった最適化は諸悪の根源である」という定番の警句が例にもれず、ここでも掲載されていた。これまで最適化を扱うところでこの名言が引用されなかったものを見たことがない。また、コードをチューニングすることよりも、要求、設計、アルゴリズムの選択を変えることの方が効果が高いことが多いこと、プログラムの実行時間の大半を占めているのがコードの僅かな部分であること、パフォーマンスの測定をせずに行うチューニングは全く持って無意味である、むしろ逆効果であることなど、直感に反するが、プログラマの間では広く浸透しているアドバイスが書かれている。さらにデータも提示されているので反論するところは殆どない。
面白い段落があった。「完璧さを追求すると、完成にたどり着けないことがある。まず完成させてから、完璧なものにする。完璧でなければならない部分は通常わずかである。」この本のタイトルるに反するようで皮肉だが、これが正しい現実の認識だろう。
## 24章を読んだ
「リファクタリング」
この章はかの有名なマーチン・ファウラーの本を要約したものになっているらしい。2019年に第2版が出版されていて、所有しているのだけど、読まないといけないなと思いつつ未読なままだ。リファクタリングという言葉は独り歩きしている感がある。少なくともその本を読んでちゃんとトレーニングを積んでからでなければ、自分は今リファクタリングをしているのだと自信を持って言うことはできないだろう。うまく行くことを願って、手当り次第に変更を加えていくだけのことをリファクタリングと呼ぶことはできない。せっかく本も買ったので、今年中に一度しっかりと取り組んでおきたい。
## 23章を読んだ
「デバッグ」
デバッグは関心の高いアクティビティだ。プログラムの誤りをすぐに見つけて、原因を特定する能力が上がれば、プログラミングの生産性もずっと向上するのに、と思わせられることが幾度もある。それ以上に、プログラムの動作を徹底的に調べ上げるというのはなかなか楽しいものでもある。ただし、これはあくまで個人的な楽しみとしてプログラミングをしている場合のみ、好意的な嗜好だといえる。納期が迫っている状況で、謎のエラーと戦うことを楽しいと思っているなら、正常さを疑われかねない。良いデバッグと悪いデバッグには10倍以上のパフォーマンス差があると書かれている。できれば良いデバッグを行う側に立ちたいものだ。
## 22章を読んだ
「デベロッパーテスト」
この本のサブタイトルは、「完全なプログラミングを目指して」だけど、プログラミングでエラーが一切発生しないことを目指すものではない。必ずエラーは紛れ込むものであって、テストは不可欠なプロセスであることを前提としている。そのテストに対する考え方は、一口で語れるような軽いものではない。単にテスティングフレームワークを採用して、ユニットテストを書いておけばいいというだけには済まない。よく知られたテストファーストの方針を推奨してはいるけど、それが全てではなく、何をテストすればいいのか、どのような手順でテストを実行すればいいのか、そもそもテストとは何かを知っておかないといけない。
## 21章を読んだ
「コラボレーティブコンストラクション」
なかなか高度な話題だ。複数人での活動になるので、一人ではトレーニングすることができない。企業で活動しているとしても、環境によってはトレーニングのためだけにそのようなことをする決定権を持たない場合もあるし、実験的に取り入れてもすぐに効果が出るとは思えないので、採用に至るまでの道のりはなかなか険しいものだろうと思われる。大きな企業では、一部を除いて、プログラマの思いつきでで現状のやり方を変えることは難しいだろう。結局の所、経営に関わる政治的な力と向き合わなければならない。この章が「コードの改良」というパートに含まれているのは皮肉だ。もちろん全てが悪いことばかりではなく、積極的かつ慎重にソフトウェアの品質を高めるためにとっくにこの古い本に書かれているようなことはとっくに実行済みで、より優れた方法を開発している集団や組織もたくさんあるだろうけど。
## 20章を読んだ
「ソフトウェアの品質」
品質と言っても様々な特性がある。ある特性は別の特性と結びつきがあって、一方を上げると別の方が下がるということもあり、すべての特性を同時に完璧にすることができない。
品質を改善するコストを下げるためには、できるだけ早い段階、つまり、コ
ンストラクションより前の段階ででエラーを検出するのが良い。
というようなことが書いてあった。久しぶりに、約3ヶ月ぶりに読み進めるので微妙に飲み込みが悪い。
## 下巻 はじめにを読んだ
上と同じ内容と思われる。
コンストラクションの重要性、コンストラクションに関する書籍が殆どないこと、研究において軽視されている状況などについての鋭い指摘がなされている。 -
-
