本 on oinume journal

2023年に読みたい本

Mon, 30 Jan 2023 09:00:00 +0900

最近読書量が減ってきたので、今年は読書を頑張ろう！と思ったのでまずは読みたい本をリストアップしてみる。

プロを目指す人のためのTypeScript入門

仕事でTypeScript書いてるんだけど、型システムが難しすぎて詰まっているので、体系的に理解したい。

Chapter 5 - Information Hiding (and Leakage) / A Philosophy of Software Design

Tue, 15 Mar 2022 09:00:00 +0900

A Philosophy of Software Design, 2nd Edition (English Edition)

作者:Ousterhout, John K.

Amazon

第5章はInformation Hiding (and Leakage)というタイトル。いいモジュールを作るには情報の隠蔽(カプセル化)を行うことが大事だよ、という話。

Chapter 4 - Modules Should Be Deep / A Philosophy of Software Design

Mon, 27 Dec 2021 09:00:00 +0900

A Philosophy of Software Design, 2nd Edition (English Edition)

作者:Ousterhout, John K.

Amazon

第4章はModules Should Be Deepというタイトル。

4.1 Modular Design

ソフトウェアの複雑性を管理するためのもっとも大事なテクニックの一つとして、全体の複雑性の一部分だけに直面するようにシステムを設計するということが挙げられる。このアプローチは modular design と呼ばれている。
この手法を用いると、ソフトウェアシステムは複数のモジュール(クラス, サブシステム, サービス)に分解される。
それぞれのモジュールは相互に依存せず独立しているため、開発者はあるモジュールの開発をしている時に他のモジュールのことを考えなくて良い
しかし、上記の独立性の話はあくまで理想で実際にはそんなことはない
- 例えば、あるメソッドに引数を追加した場合はその呼び出し元のコードも変更しないといけない
依存の認識と管理をするためには、モジュールをinterfaceとimplementationの2つに分けることが大事である
Typically, the interface describes what the module does but not how it does it.
- interfaceはそのモジュールが「何をするか」を表明し、それを「どうやるか」については表明しない
あるモジュールの開発者は、そのモジュールのinterfaceと実装、およびそのモジュールが依存している他のモジュールのinterfaceを知っている必要があるが、他のモジュールの実装については知らなくても大丈夫である
interfaceが実装に比べてとてもシンプルに表現されているモジュールがベスト
上記のようなモジュールは2つのメリットがある
- シンプルなインタフェースを提供するモジュールは、他のモジュールにもたらす複雑性を少なくする
- インターフェースが変更されない限り、他のモジュールには影響がない。

4.2 What's in an Interface?

interfaceにはformal, informalな情報がある
formal: メソッドのシグネチャ(引数およびその型、戻り値およびその型)
- プログラミング言語の機能によってもたらされる
informal: そのメソッドを呼び出した時にもたらされる結果など
- eg) 引数で与えられたファイル名のファイルを削除するなど
- informalな情報はメソッドのコメントで説明されることが多い
- Method Bを呼ぶ前にMethod Aを呼ぶ必要がある、みたいなものもinformalな情報である。

4.3 Abstraction

Abstractionとは、実体から重要ではない詳細を除外したもの
間違った抽象化には以下の2つがある
- 抽象化したが、重要ではないものを含んでしまう
  - 結果的に他の開発者の認知負荷をあげてしまう
- 抽象化して重要なものを隠してしまう(false abstraction)
  - そのモジュールがシンプルなものだと誤解させてしまう
良い抽象化の例として、ファイルシステムが挙げられる
- ファイルにデータを書き込む時に、ユーザーはそのデータがストレージデバイスのどのブロックに書き込まれるかなどは意識しない
- これはファイルシステムがうまく抽象化されていて、ユーザーにとっての不必要な情報を除外しているから
- 一方で、書き込んだデータのフラッシュについての情報は除外されていない
  - 例えばデータベースのようなソフトウェアだと、「システムがクラッシュしてもファイルに必ず書き込まれているか」を保証するために、「実際のストレージにいつデータが書き込まれるか(=フラッシュされるか)」は知っておく必要がある。そのためこの情報は抽象化されても利用者からわかるようになっている。

4.4 Deep Modules

モジュールの深さはコストとベネフィットで考える

Chapter 3 - Working Code Isn’t Enough / A Philosophy of Software Design

Wed, 01 Dec 2021 09:00:00 +0900

A Philosophy of Software Design, 2nd Edition (English Edition)

作者:Ousterhout, John

Amazon

第3章はWorking Code Isn’t Enough (Strategic vs. Tactical Programming)というタイトル。

Chapter 2 - The Nature of Complexity / A Philosophy of Software Design

Tue, 30 Nov 2021 09:00:00 +0900

A Philosophy of Software Design, 2nd Edition (English Edition)

作者:Ousterhout, John

Amazon

第2章は"The Nature of Complexity"というタイトルで、ソフトウェアのComplexityつまり複雑性についてじっくり説明されている。

Chapter 1 - Intruduction / A Philosophy of Software Design

Mon, 29 Nov 2021 09:00:00 +0900

A Philosophy of Software Design, 2nd Edition (English Edition)

作者:Ousterhout, John

Amazon

A Philosophy of Software Design の第1章を読んだのでそのまとめ。

Intro

プログラムは機能が増えるごとに複雑さが増していく。複雑さが増えると、開発スピードが遅くなりバグが増える
開発ツールは複雑性に対処するに役立つが、これには限界がある。一方、シンプルなソフトウェアのデザインはより大きくてパワフルなプログラムを導いてくれる。
複雑性に対処するには2つのアプローチがある。
- 1つ目はコードをシンプルかつ明らか（わかりやすく）すること。例えば複雑性は特殊ケースを削除することで減らすことができる。
- 2つ目のアプローチはカプセル化でmodular design とよばれている。
  - Modular designではソフトウェアをモジュールに分割して管理して(OOPだとクラスとか)それぞれのモジュールは他のものに依存しない。
  - そのため、プログラマーはあるモジュールの開発をするときに、他のモジュールの詳細を知らなくて済む。

ウォーターフォールモデルの紹介

ウォーターフォールだと基本的には設計フェーズではすべてを設計し、開発のフェーズでは設計をしない。ソフトウェアは物理的なシステムより複雑で目に見えないので、特に大きなシステムであるほど全体を細部まで理解することは難しい。
開発フェーズで初めて問題がわかるケースもよくあり、場合によっては設計のやり直しが発生する。ウォーターフォールモデルだとこれは大きな手戻りになってしまう。
この問題があるため、最近のソフトウェア開発ではアジャイルのようなインクリメンタルなアプローチが使われている。

How to use this book

ソフトウェアの設計スキルを向上させるための良い手法の一つは、"red flags"という複雑なソースコードの断片のサインを認識することである。この本ではその"red flags"を、メジャーな設計の問題を通じて説明する。

A Philosophy of Software Designを読み始めた

Sun, 28 Nov 2021 14:54:17 +0900

タイトル通りで、最近第2版が発売されたのと、いろんなところでオススメされていたのでこの本を読んでいる。やっと第6章まで読み終わったので、それぞれの章のまとめをブログにアップしていく予定。

読書: 新しい文章力の教室

Thu, 12 Jul 2018 09:00:00 +0900

新しい文章力の教室　苦手を得意に変えるナタリー式トレーニングできるビジネスシリーズ

読書感想「ルポ MOOCS革命」

Thu, 09 Mar 2017 09:00:00 +0900

ルポ MOOC革命――無料オンライン授業の衝撃

作者: 金成隆一
出版社/メーカー: 岩波書店
発売日: 2013/12/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (8件) を見る

を読んだので、メモと感想。

2016年に読んだ本

Sat, 31 Dec 2016 23:20:00 +0900

本当は「2016年に買ったもの」という記事を書こうと思ったけど、日用品以外で買ったものがあまりなかったので読んだ本(技術書以外)を晒してみる。

「謀略法廷」を読みました

Thu, 30 Jul 2009 14:07:46 +0900

ジョン・グリシャムの最新作が文庫本で発売になっていたので、すごく久々に小説を読みました。今回のこの小説は法廷モノというよりかは裁判の外での駆け引きがメインなので、いわゆる「弁護士と検事の闘い」というものではありません。

「ウェブユーザビリティの法則改訂第2版」を読みました

Wed, 06 May 2009 09:05:25 +0900

[tmkm-amazon]4797339098[/tmkm-amazon]

いまさら感が漂いますが、会社の同僚に借りて読んでみました。結論からいうとユーザビリティについて当たり前のことが簡潔にまとまっている良書です。自分用に一冊買おうかと思うぐらいでした。この本から学んだことはたくさんありましたが、記憶に残っている部分を箇条書きにしておきます。

「すべての「見える化」で会社は変わる」を読みました

Sat, 25 Apr 2009 04:04:27 +0900

[tmkm-amazon]4788907534[/tmkm-amazon]

会社経営に興味があるわけではないのですが、Amazonでやたら評価が高かったので気になって読みました。21世紀の会社経営について、どうしていけば良いのかを明確にしていてすごくわかりやすかったです。この本から学んだことを箇条書きにしてみます。

「Web担当者現場のノウハウ SEOスペシャル 2009 冬号」を読みました

Tue, 03 Mar 2009 14:03:11 +0900

[tmkm-amazon]4844326503[/tmkm-amazon]

発売されてから2ヶ月ぐらい経ってしまったのですが、ようやっと読み終わりました。雑誌ということで、普通の書籍より先端的な情報が入っていて非常に参考になる雑誌でした。

「アクセス解析徹底活用術 ~ネットで売上を増やす!~」を読みました

Mon, 09 Feb 2009 17:02:38 +0900

[tmkm-amazon]4839926018[/tmkm-amazon]

仕事でサイトの運営をやっているのですが、こういうアクセス解析の教科書的な本を真面目に読んだことがなかったので買いました。

構成としては

アクセスログ解析の必要性

「入門Redmine Linux/Windows対応」を読みました

Sun, 08 Feb 2009 03:02:50 +0900

[tmkm-amazon]4798021377[/tmkm-amazon]

Redmineがソフトウェアの開発管理を行う上で気になっていたので買って読んでみました。読み終わって思ったのは**これ、便利そう！**ということ。似ているソフトウェアとしてはTracというものがありますが、Redmineが優れている点として

SubversionなどのSCMの対応状況。Git, Mercurial, Bazaar, CVSにも対応している。TracはSubversionのみプラグインを入れることでTracでもこれらのSCMに対応できるようです。

「できる100ワザ SEO & SEM」読みました

Sat, 07 Feb 2009 04:02:41 +0900

[tmkm-amazon]4844323024[/tmkm-amazon]

SEOの基本中の基本を理解したかったので買いました。

まずは検索エンジンで「実際に検索されているキーワード」を見極めてそれをHTMLに落とし込んでいくやり方が書いてあります。初版が2006年なので最新の情報はカバーされていませんが、Google Analyticsによるアクセス解析の方法（のさわり）まで盛り込まれています。

本 on oinume journal

2023年に読みたい本

プロを目指す人のためのTypeScript入門

Chapter 5 - Information Hiding (and Leakage) / A Philosophy of Software Design

Chapter 4 - Modules Should Be Deep / A Philosophy of Software Design

4.1 Modular Design

4.2 What's in an Interface?

4.3 Abstraction

4.4 Deep Modules

Chapter 3 - Working Code Isn’t Enough / A Philosophy of Software Design

Chapter 2 - The Nature of Complexity / A Philosophy of Software Design

Chapter 1 - Intruduction / A Philosophy of Software Design

Intro

ウォーターフォールモデルの紹介

How to use this book

A Philosophy of Software Designを読み始めた

読書: 新しい文章力の教室

読書感想「ルポ MOOCS革命」

2016年に読んだ本

「謀略法廷」を読みました

「ウェブユーザビリティの法則 改訂第2版」を読みました

「すべての「見える化」で会社は変わる」を読みました

「Web担当者 現場のノウハウ SEOスペシャル 2009 冬号」を読みました

「アクセス解析 徹底活用術 ~ネットで売上を増やす!~」を読みました

「入門Redmine Linux/Windows対応」を読みました

「できる100ワザ SEO & SEM」読みました

「ウェブユーザビリティの法則改訂第2版」を読みました

「Web担当者現場のノウハウ SEOスペシャル 2009 冬号」を読みました

「アクセス解析徹底活用術 ~ネットで売上を増やす!~」を読みました