読書ログ on blog.kyu08.com

1.1 Getting Started に、例として掲載されている"hello, world"プログラムは、あらゆる「プログラミングの最初の例題」として定番となった。

https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9EC

とあるように、hello, worldの生みの親としても有名らしい。（！）

各章に演習問題が豊富に用意されているので手を動かしながら学びやすかった。

また、付録を除くと231ページと比較的コンパクトなので、Cの全体像をざっと把握するのにちょうどいいボリューム感だった。

読み方

1,2章は演習問題をやりつつ読み、他の章は演習問題をスキップして本文だけ読んだ。
- Cを完全理解したり人に教えられるレベルになりたい、というよりはOSTEPでの実装がスムーズになれば嬉しいなーくらいの温度感だったのと、手を動かすのはOSTEPでできそうだったので知らない文法や仕組みを軽く頭に入れておくくらいの感じで読んだ。
#includeなしでboolが使えると多少楽そうだったのでC23で動かした。
- 演習問題を解いた実装はこちら。

sunaba/c/k_and_r at d15fb4fa20d3e478cc0f5ac6f9e89e7d0c668b21 · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/tree/d15fb4fa20d3e478cc0f5ac6f9e89e7d0c668b21/c/k_and_r

学び

変数、関数の可視性の制御方法(static、extern)
#includeの機能("foo.h"と<foo.h>の違いなど)
aが配列のときa[i]と*(a + i)は同じ
共用体
- 結構使うのが難しそうなので相当パフォーマンスを重視したいときにしか使わないかも…?
関数ポインタ
マクロの基礎
etc.

まとめ

(すべての演習問題をやったわけではないのもあって)1週間ちょっとでCについて一通り簡単に学べて、ちょうどいいボリューム感だった。

ということでOSTEPに取り組む準備ができたので次は実際に着手していこうと思う。

『ネットワークはなぜつながるのか』を読んだ

Sat, 04 Apr 2026 16:45:52 +0900

ネットワークはなぜつながるのか第2版を読んだので感想などをまとめる。

どんな本か

ブラウザにURLを入力してからサーバーから返ってきたレスポンスをブラウザで表示するまでの間に起きることを順を追って説明してくれる本。

章の構成は以下。

Chapter Number	Title	Summary
第1章	Webブラウザがメッセージを作る―ブラウザ内部を探検	ブラウザにURLを入力してからブラウザがIPアドレスを解決し、HTTPメッセージを作成してプロトコルスタックに渡すまでに行うこと
第2章	TCP/IPのデータを電気信号にして送る―プロトコル・スタックとLANアダプタを探検	ブラウザから依頼を受けたプロトコルスタックがソケットを作成してから通信を終えてソケットを抹消するまでの流れ
第3章	ケーブルの先はLAN機器だった―ハブとスイッチ、ルーターを探検	LANケーブルへと送り出されたパケットがリピータハブ、スイッチングハブ、ルーターなどの機器を経由してインターネットに向かって進んでいく流れ
第4章	アクセス回線を通ってインターネットの内部へ―アクセス回線とプロバイダを探検	パケットがインターネット接続用ルーターを経由してインターネットの中に入って進んでいく様子
第5章	サーバー側のLANには何がある	サーバー側のPOPに入ったパケットがサーバーの手前にあるファイアウォール、キャッシュサーバー、負荷分散装置などを通過する様子
第6章	Webサーバーに到着し、応答データがWebブラウザに戻る―わずか数秒の「長い旅」の終わり	サーバーがリクエストを受信してからクライアント側のブラウザが結果を表示するまでの流れ

特に第1章 ~ 第3章の内容が普段のWeb開発と関わりが大きいかつ自分の知識が浅い領域だったのでとても面白かった。

なぜ読んだか

そもそも自分はコンピューターサイエンスをこれまで(大学などで)体系的に学んできていないのもあり、以下の目的でコンピューターサイエンスの勉強を隙間時間に進めている。

ソフトウェアエンジニアリング文脈の問題解決やスキル獲得の速度を上げたい
知的好奇心を満たしたい

去年はコンピュータシステムの理論と実装を読んでコンピューターについて広く浅く理解することができたので次はネットワーク周りを強化しようと思い、読んでみた。(他にはセキュリティ、データ構造とアルゴリズム、データベース、プロトコルスタック、シェルなどが気になっている)

『コンピュータシステムの理論と実装第2版』を読んだ

『コンピュータシステムの理論と実装第2版』を読んだので感想を書く。割と長いので得られた学びだけ読みたい方は## 学び、得た経験までジャンプして

https://blog.kyu08.com/posts/nand2tetris/

学びや気付き

「ブラウザにURLを打ち込んでエンターキーを押すと何が起こるか」という質問に暗記ではなく理解をもとに答えられるようになった。(はず) 特に以下に関しては今までより詳しく理解できた。

ブラウザが何をしているか
DNSが何をしているか
TCP接続においてプロトコルスタックが何をしているか
IPが何をしているか
イーサネットとは何か
インターネットとは何か

ネットワークの基礎を学んだことで今後の問題解決や技術理解の助けにもなってくれそう。

それぞれ現時点での自分の理解を書いてみる。

1. ブラウザが何をしているか

FQDNをもとにDNSにIPアドレスを問い合わせて解決する
HTTPリクエストを作成する
ソケットを作成する
プロトコルスタックにTCPコネクションの確立を依頼する
プロトコルスタックにリクエストの送信を依頼する
通信が終わったらソケットを抹消する

どんなシステムコールを呼ぶ必要があるのか気になったのでCで簡単なHTTP Clientを書いてみた。

sunaba/network/how_networks_work/myhttpclient-c/main.c at ea1ba354678e5c1616ea13a62ddcdb04ed34859f · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/blob/ea1ba354678e5c1616ea13a62ddcdb04ed34859f/network/how_networks_work/myhttpclient-c/main.c

今回自分が実装したHTTP Clientでは以下のような流れでシステムコールや関数が呼ばれる。

getaddrinfo(3) を使ってドメイン名に合致するIPアドレス(の配列)を取得
socket(2)でソケットを作成しソケットへのファイルディスクリプタを取得する
connect(2)サーバーへの接続を確立する
2.で取得したファイルディスクリプタに対してwrite(2) でリクエストを書き込む
read(2) でレスポンスを読み込む
サーバー側がソケットをクローズしたらクライアント側でもclose(2)を使ってソケットをクローズする

なお、実装はgetaddrinfo(3)のEXAMPLESを参考にしたらほとんど完成してしまった。

getaddrinfo(3) - Linux manual page

https://man7.org/linux/man-pages/man3/getaddrinfo.3.html#EXAMPLES

比較のためにGoでもsyscallパッケージを使って書いてみた。

sunaba/network/how_networks_work/myhttpclient-go/main.go at ea1ba354678e5c1616ea13a62ddcdb04ed34859f · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/blob/ea1ba354678e5c1616ea13a62ddcdb04ed34859f/network/how_networks_work/myhttpclient-go/main.go#L1

2. DNSが何をしているか

DNSサーバーに格納されているデータ

DNSサーバーには以下のようなデータが格納されている。

名前
- サーバーやメール配送先の名前
クラス
- 常にINが格納される。
- DNSができた当初はインターネット以外のネットワークでも利用も検討されていたが、現在はインターネット以外のネットワークが消滅したのでINしか入らない。
タイプ
- 名前にどのようなタイプの情報が対応付けられているかを表現した値。
- 具体例
  - A
    - IPアドレス(AddressのAらしい)
  - MX
    - メール配送先
  - CNAME
    - 名前にエイリアスを設定する

以下はDNSレコードの例。

名前	クラス	タイプ	クライアントに返答する項目
example.com	IN	A	192.0.2.226
example.test	IN	MX	10 mail.example.test
mail.example.test	IN	A	192.0.2.227

世界中のDNSサーバーが協調する仕組み

blog.example.comというドメインのIPアドレス解決を例に考える
DNSサーバは階層構造でレコードを分散管理しており、以下のように階層ごとに別々のDNSサーバーに格納されている(同じになることもあるが)
- ルートドメイン
- .com
- example.com
- blog.example.com
問い合わせはルートドメインから順番にたどるので以下のような流れになる
1. 最寄りのDNSサーバがルートドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - レコードのIPアドレスはわからないが、comドメインのDNSサーバのIPアドレスはわかるからそっちに聞いてくれ、とcomドメインのDNSサーバのIPアドレスが返ってくる
2. 最寄りのDNSサーバがcomドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - 同じ要領で example.com のDNSサーバのIPアドレスが返ってくる
3. 最寄りのDNSサーバがexample.comドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - 同じ要領で blog.example.com のDNSサーバのIPアドレスが返ってくる
4. 最寄りのDNSサーバがblog.example.comドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - blog.example.com のIPアドレスが返ってくる
DNSサーバにはキャッシュ機能があるので必ずしも毎回このようなステップになるとは限らない。
- 当然TTLも存在するので最新のデータが返ってくるとも限らない。

3. TCPでの接続の場合にプロトコルスタックが何をしているか

プロトコルスタックとはプロトコル(e.g. TCP, UDP, IP, etc.)を役割ごとに階層化して積み重ねたソフトウェア群を指す。ネットワークの文脈では主にSocketライブラリとLANドライバの橋渡しの役割を担う。

                   +---------------------------------------------------+
Application Layer->|  +---------------------------------------------+  |
                   |  | Network Applications                        |  |
                   |  | (Web Browser, Mailer, Web Server, etc.)     |  |
                   |  +----------------------------+----------------+  |
                   |  | Socket Library             | Resolver       |  |
                   |  +----------------------------+----------------+  |
                   +---------------------------------------------------+
OS Layer---------->| Protocol Stack                                    |
                   |  +----------------------+  +--------------------+ |
                   |  | TCP                  |  | UDP                | |
                   |  | (Connection-based)   |  | (Connectionless)   | |
                   |  +----------------------+  +--------------------+ |
                   |  +---------------------------------------------+  |
                   |  | IP (Route & Forward)                        |  |
                   |  |  +------------+              +------------+ |  |
                   |  |  | ICMP       |              | ARP        | |  |
                   |  |  +------------+              +------------+ |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+
Driver Layer------>|  +---------------------------------------------+  |
                   |  | LAN Driver (Controls LAN Adapter)           |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+
Hardware Layer---->|  +---------------------------------------------+  | 
                   |  | LAN Adapter                                 |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+

『ネットワークはなぜつながるのか第2版』P96 図2.1 をもとに再構成

getaddrinfo(3) を使ってドメイン名に合致するIPアドレス(の配列)を取得
1. UDP担当部分にDNSサーバーへの問い合わせを依頼する
socket(2)でソケットを作成しソケットへのファイルディスクリプタ(以下fd)を取得する
1. ソケット1つ分のメモリを確保しそこに初期状態であることを記録して
2. アプリケーションにfdを返す。
connect(2)サーバーへの接続を確立する
1. アプリケーションからsocketのfdとサーバー側のIPアドレスとポート番号を受け取る
2. 以下の手順で3ウェイハンドシェイクを行う
  1. (クライアント側)送信元と宛先のポート番号やコントロールビット(SYN=1, ACK=0)を含んだTCPヘッダーを作成する
  2. (クライアント側)IP担当部分に送信を依頼する
  3. (サーバー側)IP担当部分がパケットを受け取ってTCP担当部分に渡す
  4. (サーバー側)TCP担当部分がTCPヘッダーを調べてそこに記載されている宛先ポート番号に相当するソケットを探し出す
  5. (サーバー側)該当するソケットに必要な情報を記録して、接続動作が進行中だという状態にする
  6. (サーバー側)送信元と宛先のポート番号やコントロールビット(SYN=1, ACK=1)を含んだTCPヘッダーを作成する
  7. (サーバー側)IP担当部分に送信を依頼する
  8. (クライアント側)IP担当部分がパケットを受け取ってTCP担当部分に渡す
  9. (クライアント側)TCP担当部分がTCPヘッダーを調べてサーバー側の接続動作が成功なら(SYN=1, ACK=1)「サーバーのIPアドレスやポート番号」と「接続完了を示す制御情報」等をソケットに記録する
  10. (クライアント側)サーバー側に接続成功を示すTCPヘッダー(SYN=0, ACK=1)を送り返す
2.で取得したfdに対してwrite(2) でリクエストを書き込む
1. 送信データを受け取ったプロトコルスタックはデータを相手に送る
  1. データが大きいときは分割して送る
  2. ウィンドウ制御方式(ACK番号の到着を待たず、複数のパケットを連続して送る方式) で効率化を図る。ウィンドウの大きさは受信側のバッファの空き容量をもとに調整される。
2. 送信するすべてのパケットにシーケンス番号(何バイト目か)を付与し、受信側はACK番号(受け取ったシーケンス番号の中でその時点で最大のものに1を足した数値)を返し、「ここまでは受け取ったのでこの番号のパケットを送ってください」というメッセージを伝える
3. 送信側はACK番号を見て必要に応じてパケットを再送する
データを受信した場合、受信したデータ断片とTCPヘッダーを途中でデータが抜けていないか検査し、問題なければACK番号を送り返す
read(2) でレスポンスを読み込む
1. 受信バッファに積まれたデータをアプリケーションに渡す
サーバー側がソケットをクローズしたらクライアント側でもclose(2)を使ってソケットをクローズする(なお、クライアントが先にソケットをクローズすることもあり、どちらになるかはアプリケーション次第になる。)
1. (サーバー側)がcloseを呼び出す
2. (サーバー側)プロトコルスタックがコントロールビットのFINを1にセットしたTCPヘッダーを作成し、IP担当部分に送信を依頼する
3. (クライアント側)FIN=1であるTCPヘッダーが届いたのを確認して、自分のソケットにサーバー側が接続動作に入ったことを記録する
4. (クライアント側)FIN=1であるパケットを受け取ったことをサーバー側に知らせるためにACK番号をサーバー側に送り返す
5. (クライアント側)サーバーからすべてのデータを受け取ったことをアプリケーション側に知らせる
6. (クライアント側)コントロールビットのFINを1にセットしたTCPヘッダーを作成し、IP担当部分に依頼してサーバーに送ってもらう
7. (サーバー側)クライアント側からFIN=1なパケットを受け取ったらACK番号を返す
8. (クライアント側)サーバーからACK番号が返ってきたことを確認し、サーバーとのやり取りを終了する

4. IPが何をしているか

IPの主な役割は宛先IPアドレスをもとにパケットの転送先を決定し、次のホップへ届けること。

IPヘッダー、MACヘッダーの作成
- 送信元・宛先IPアドレス、TTL(Time To Live)などを含むIPヘッダーをTCPパケットに付与する
  - TTLはルーターを経由するたびに1減らされ、0になったらパケットは破棄される(ループ防止)
- IPヘッダーの前にMACヘッダーを付与する
  - MACヘッダーには宛先MACアドレスと送信元MACアドレスが含まれる
- MACアドレスの解決にはARPを使う
  - ARPとは、IPアドレスからMACアドレスを解決するためにLAN内でブロードキャストを行い、対象IPアドレスのMACアドレスを特定するためのプロトコルである
  - キャッシュ機能もあるので毎回ブロードキャストするわけではない
ルーティング
- ルーティングテーブルを参照して「次にどのルーターにパケットを渡すか」を決定する
- 宛先IPアドレスとルーティングテーブルのエントリを比較し、最長プレフィックスマッチで転送先を選ぶ
- 宛先が同一LAN内であればそのままL2で届けられる
- あくまでIPは「どこに届けるか」を決める仕組みで、実際の転送はイーサネットを用いて行うためMACアドレスが必要になる

IPはベストエフォートの転送のみを担い、信頼性の保証はしない(それはTCPの責務)

ICMPとARPはIPの動作を補助する形で動く。

ICMP: エラー通知(宛先到達不能など)や疎通確認(ping)に使われる
ARP: IPアドレスからMACアドレスを解決するためにLAN内でブロードキャストされる

5. イーサネットとは何か

イーサネットはLAN内の機器間でデータをやり取りするための規格。IPがネットワーク間の転送を担うのに対し、イーサネットは同一LAN内の転送を担う。

アドレス体系
- MACアドレス(48ビット)を使って送受信先を識別する
- MACアドレスは原則的にはNICに割り当てられた固有の識別子
- IPアドレスが「建物の住所」なら、MACアドレスは「人の名前」に相当する
フレーム
- イーサネットではデータを「フレーム」という単位で送受信する
- フレームには送信元MACアドレス、宛先MACアドレス、データ、エラー検出用のFCSが含まれる
スイッチングハブ
- MACアドレスと接続ポートの対応表(MACアドレステーブル)を持ち、宛先MACアドレスに対応するポートにだけフレームを転送する
- 最初は対応表が空なのでブロードキャストし、応答を受け取ることでテーブルを学習していく

6. インターネットとは何か

なお「インターネット」は広範な意味を持つ言葉だが、ここでは本書のスコープ(ISP・POP・IXあたりの話)に限定して整理する。

インターネットとは、世界中のISP(インターネットサービスプロバイダ)のネットワークが相互接続された巨大なネットワークの集合体。

ISPとPOP
- ISP(Internet Service Provider)はインターネット接続サービスを提供する事業者
- POP(Point of Presence)はISPの設備が置かれた接続拠点。ユーザーのパケットはまずここに届く
- POP内にはルーターが置かれており、パケットを次の拠点に転送する
NOC
- POPから入ってきたパケットが集まる
- プロバイダの中核となる設備
- データ転送能力が数テラビット/秒を超えるルーターが使われることもある
IX(Internet eXchange)
- 複数のISPが相互に接続するための中立的な施設
- IXを介することでISP間のパケットのやり取りが効率化される
パケットの経路
- ユーザーのパケットはISPのPOP → ISPバックボーン → IX → 相手ISP → サーバーという流れで届く
- 経路上のルーターがBGP(Border Gateway Protocol)で経路情報を交換し合うことでインターネット全体のルーティングが成立している

Q&Aメモ

こちらのポストを参考にしてClaudeに質問を作成してもらい、都度Claudeに相談しながら回答を考えてみた。

あくまで「この質問に対しては暗記ではなく理解をもとに答えられるようになった」ということをメモしておくための自分用学習メモです。

No	質問	回答
1	TCPの3ウェイハンドシェイクはなぜ「2ウェイ」ではダメなのか	サーバーからクライアントへの経路が機能しているかどうかをサーバーが確認できないため。双方向の疎通を双方が確認するには3メッセージ必要になる。
2	DNSキャッシュのTTLを短くするデメリットは何か	キャッシュDNSサーバーから権威DNSサーバーへのリクエスト数が増加する。その結果以下が発生する。 • 権威DNSサーバーが処理しなければならないリクエストの量が増えるため、権威DNSサーバーのレイテンシが増加する • キャッシュDNSサーバーがキャッシュを返す割合が減るため権威DNSサーバーへのリクエスト分のレイテンシが増加する
3	NATがエンドツーエンド通信に何をしているか図で説明せよ	送信時はプライベートIPとポート番号をルーターのグローバルIP+任意のポート番号に変換し、受信時はその逆の変換を行う。結果として通信相手はNATを意識することなく、単一のグローバルIP+ポート番号とやりとりをしているように見える。
4	TCPとUDPの使い分けを「信頼性」以外の観点で説明せよ	前提として、UDPは接続確立や再送のオーバーヘッドがなく、輻輳制御も行わないため高速に通信を行うことができる。信頼性を多少犠牲にしてでも高速性を重視したい場面ではUDPの利用が有効なケースがある。たとえば遠隔運転システムでは、一瞬映像が途切れたとしてもリアルタイムに映像が表示され続けることが重要になるためUDPのメリットを享受しやすいと考えられる。
5	ルーティングテーブルの「最長プレフィックスマッチ」とは何か、なぜその方式か	ルーティングの際にルーティングテーブルの中から宛先IPアドレスとマッチする範囲が一番長いレコードにあるネットワークを次のルーティング先とする方式。 `10.0.0.0/8`に向けるデフォルト経路と`10.1.2.0/24`に向ける特定経路が存在する場合は後者を優先しないと意図したルーティングにならないため。
6	HTTPSでサーバー証明書が必要な理由を、鍵交換から説明せよ	MITMへの対策のため。証明書がないと鍵の交換相手が本物のサーバーなのか攻撃者なのかわからないため必要になる。
7	パケットロスが0%でもアプリが遅い理由を説明せよ	ここでは「アプリが遅い」 == 「クライアント側で見ているWebアプリの動作が想定よりも遅い」と仮定する。 • DNSサーバーのレイテンシが大きい • クライアントのマシンの動作が遅く、リクエスト送信までに時間がかかっている • アクセス回線にADSLが含まれるなどがそもそも低速な回線がボトルネックになっている • クライアントとサーバーが地理的に離れており、そもそも通信に時間がかかる • 経路上のネットワーク機器が古く、非効率な通信を行っている • サーバーの負荷が高く、CPUがスロットリングした結果、サーバーの処理全体が遅くなっている • マイクロサービス構成になっておりそもそも必要なネットワークIOの数が多い
8	サブネットマスクはなぜ必要か、IPアドレスだけでは何が足りないか	IPアドレスのうち、どこまでがネットワーク部でどこからがホスト部なのかがわからなくなるため。
9	ARPはなぜIPレイヤーではなくL2に属するのか	ARPはIPアドレスをMACアドレスに解決するプロトコルだが、L2のフレームで直接ブロードキャストし、IPルーティングを経由しない。つまりL3の仕組みに依存せずに動作する必要があるためL2に属する。
10	ping が通るのにHTTPが失敗するとき、最初に何を疑うか	ファイアウォールによるポートのブロックを疑う。 pingはICMPプロトコルを利用しており、そもそもポート番号を指定する必要がない。一方でHTTPはポート番号を指定する必要があるため。他にはサーバー側でサーバープログラムが起動していない可能性やTLSの証明書エラーの可能性も考えられる。

まとめ

読む前の期待以上にネットワークの解像度を上げられたので読んでよかった。

次はOperating Systems: Three Easy PiecesでOS周りの深堀りをしていこうと思っている。メモリ管理やプロセス、スレッド周りの解像度を上げたい。あと課題でCを書く必要があるのも若干良さそうに感じたポイントでもある。(Cを書くのは辛いが、その分頑張りが身になる感覚があり…)¹

Operating Systems: Three Easy Pieces

https://pages.cs.wisc.edu/~remzi/OSTEP/

軽く読んだ感じ、英語ではあるもののかなり平易に書いてくれているので読みやすそうだった。やっていく。²

(C言語はCS50で軽くさらった程度なのでせっかくなので『プログラミング言語C 第2版』あたりの入門書を一冊読むのもいいかもしれない)

“you will also learn the practical, including how an operating system does things like schedule the CPU, manage memory, and store files persistently.” とのこと。 ↩︎
なお、内容は無料でWebで公開されているので無課金で学習することも可能。自分は移動時間に読んだり書き込んだりしたかったのでPDFを購入した。(それでも$10という破格) ↩︎

『解像度を上げる』を読んだ

Wed, 11 Feb 2026 13:00:41 +0900

おすすめしていただいて気になっていた『解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と行動法』を読んだ。

起業家に向けて書かれている記述が多かったが、いちソフトウェアエンジニアとしても非常に参考になる部分が多かったので自分に刺さったポイントを書いていく。

なお、引用は特別に断りがない限りすべて同書からのものです。

「解像度」の構成要素

解像度の高さが何によって構成されているかを考えたときに見えてきたのが、「深さ」「広さ」「構造」「時間」の４つの視点です。

解像度の構成要素を「深さ」「広さ」「構造」「時間」の4つと整理する視点を得られたのが本書を読んで一番良かったポイントかもしれない。

この視点があると「なんか解像度が低いぞ…」となったときにどの要素が足りていないかを考えることで効率的に再現性高く解像度を上げることができそう。他の人のアウトプットへのFBにもかなり便利に使えそう。

4要素は以下のように理解した。

深さ: 具体性を上げたり、因果関係を深堀りしたりする
広さ: 網羅性（幅広さ）を上げる
構造: 「深さ」と「広さ」のステップで出した各要素を構造化する（要素を分解したり整理したりする）
時間: 「過去」「現在」「未来」のような時間軸の観点を盛り込む

情報をツリー構造で整理する

ここまで、深さ、広さ、構造、時間の４つの視点で解像度をチェックしてきました。こうしたチェックをやりやすくする一つの方法としてお勧めなのが、一度自分の理解をツリー構造で整理してみることです。　

本書でも幾度となくツリー構造で分析を整理した図が紹介されていた。

ツリー構造で書いていくと色々なメリットがあって良さそうので取り入れてみようと思う。

たとえば思考の現在地が把握しやすくなることでかなり効率よく思考を深めやすくなる気がする。（今自分は仮説1の解決策2について考えているんだな〜みたいなのが一目でわかるので狭くなりがちな思考を広げられたり、他の要素と行ったり来たりしながら思考を深めやすそう。）

あとは目的意識なく深さと広さを広げすぎるとノイズが増えそうなので構造化するのを忘れないことも大事そう。（このあたりは実際にやってみて調節するのがよさそう）

解像度を上げる対象

上げるべきは、課題と解決策の解像度

ビジネスの文脈では特に課題と解決策の解像度を上げることが重要。

（文字にするとそれはそうという感じにはなってしまうが）「解像度が足りない」と感じたときに足りないのが課題の解像度なのか解決策の解像度なのか両方なのかを分けて考えられるとよりスムーズに成果に繋がりそう。

（直感的には課題の解像度が上がらないと解決策の精度や解像度は上がらなそうに思えるので前者が前提になりそう。）

課題の選び方

このように課題や問いが重要視される理由は、良い課題を選べるかどうかで生み出される価値がほぼ決まると言っても過言ではないからです。

『イシューからはじめよ』でもイシュー度が高い課題を解くことの重要性が説かれていたのを思い出した。

そういう意味でもまずは課題の解像度を上げることが重要かもしれない。（緊急度が高く重要度が低い課題とかはぱっと解決して早く次に行きたい種類の課題なので例外かもしれないが）

書くことで考える

まず取り組んでほしいのは、「今、何が最も重要な課題だと思っているのか、それはなぜなのか」を仮説で良いから最初に書くことです。

考え抜いた「結果」を書くのではありません。書くことは思考の「過程」です。書くことで私たちは考えることができます。

ブログに記事を書いたり（まさにこの記事とかがそう）チームで何か意思決定をする際に会議資料を書いたりすることで自分が考えていることがクリアになったり、思考が深まったりすることがよくあるので最後の2文にはすごく共感した。

文字にすることの効果はかなり感じているので今後も悩んだら（というか何かを考えたいときは）書くことで思考を深めていこうと思った。

書くときの留意点

課題の解像度を「深さ」の視点で上げるための方法として「現時点での自分の課題認識を書き出す」という方法が紹介されていた。

その際のポイントとして以下のような点が挙げられていた。

（他の人に読んでもらうための）わかりやすい文章を書くという観点でも非常に参考になりそうだったので一部を引用して紹介する。

最初の書き出しは箇条書きでも構いません。ただし、より詳細に課題を検討するときには、文章として長文で書くことをお勧めします。箇条書きを使うと、論理の飛躍や矛盾などに気づきづらいからです。

箇条書きだと論理的にわかりやすい文書になるかはかなり書き手に依存すると思っているので頷けた。（自分は箇条書き自体がダメだとは思ってないが注意深く使わないと読み手の解釈が一意にならないので気をつけて使おうと思っている派）

よくあるパターンでいうと以下のようなケースがあると思う。¹

（「なので」「とはいえ」「しかし」などの接続詞が省略されることが多く、）論理的なつながりがわかりづらい
列挙された項目がシーケンスなのか選択肢なのか、AndなのかOrなのかがわかりづらい

Amazonでも会議資料に箇条書きだけで構成されたスライドを使うのは禁止らしい。²（さすがに社員全員が同一のルールを実践してるとは限らないと思うが）

なんにせよ読み手が疑問を感じたり2パターン以上の解釈ができてしまうような文章を書かないことを心がけるのがよさそう。

主語が明確な文にする　

これも抜けがちだがクリティカルな齟齬につながりやすいので気をつけたい。（自分の場合はどちらかというと口頭で話してるときに抜けがちかも）

動詞を入れる　──　体言止めではなく、動詞を入れるようにしましょう。

体言止めも読み手に解釈の余地を与えがちなので注意したい。

たとえば「データ移行の切り戻しは手動。」とドキュメントに書かれていた場合、「手動で行う予定」なのか「手動でしか行えない」（制約の共有）なのか「手動で行った」（完了報告）なのかが明確ではなかったりする。³

スタートアップに関するエッセイで有名なポール・グレアムも、エッセイを公開する前には必ず声に出して読み上げて、友達に話すような言い回しになっているかを確認しているそうです（４）。

普段会議資料を書くときに最後は声に出して読んでみて詰まるポイントがないかチェックしているのでこの点も共感できた。うまく話せないところは論理が飛躍していたり変な結論になっていたりするのことが多いので、仕上げとして声に出して読むのは大事そう。

ことこのブログに関しては書いた後に声に出して読んだりはしていないが良さそうなので試してみようと思った。

深める

事例のサーベイが十分できているかどうかの閾値は、関連事例を「１００」程度知っているか

（起業ではなく）ソフトウェアエンジニアリングの場面では必ずしも100個必要とは限らないが、他社の事例を知っておくと引き出しが増えるので、知っておくに越したことはないと思う。

たとえばソフトウェアアーキテクチャのパターンやディレクトリ構成などは書籍やテックブログ、登壇資料で数多く紹介されているのでそういったアウトプットから学べるとよさそう。普段自分が仕事で関わっている領域ではゼロから何も見ずに自分で考えることに価値があるというよりは、効果的な施策や判断に価値があることが多いので重要な意思決定をする際には適切な情報収集をできるとよさそう。

また、そうしたネット上の資料は無料で公開されていることが多く、そうした環境にかなりお世話になっている自覚があるので自分もアウトプットを続けて少しでも業界、エコシステムに恩返しをしていければなと思う。

不慣れな分野のキャッチアップ

本屋に行って、端から端まで本を買う　事例のサーベイがある程度終わったら、次は大きめの書店に行き、自分の課題に関連する業界の本を端から端まで買うことをお勧めします。

著者によって異なる視点から同じ物事を見ることができますし、重複しているのなら、その情報は誰の目から見ても重要だということが分かります。そうして業界の構造やトレンドを深掘りしていくのです。

特に不慣れな分野に飛び込むときにはこのような方法は効果的そう。

同じような内容の書籍は1冊読めばいいのでは？と思っていたが複数の著者で共通した内容がある場合はその内容の重要性が担保されるという観点はなるほどと思った。

教える

教える　対話や質問のさらに一歩先の言語化として、教えるがあります。今考えている課題について、よく知らない人に教えるつもりで話してみましょう。

自分がブログを書いている理由の1つ。あまり人に教えられるような書き方まではできていないが、先の引用でもあったように書くことを通して理解や思考を深められている。社内外の勉強会での登壇などもこれにあたりそう。

コミュニティに参加する

コミュニティに参加すると、深く考えるためのヒントや、情報をもらえます。それに、誰かが近くにいることで、必然的に言語化や壁打ちの機会が生まれます。

これまであまりコミュニティには参加してこなかったが、今年はGoの知識を深めたいのでチャレンジしてみようと思った。（さっそく2/21のGo Conference mini in Sendai 2026に行ってみることにした）

まとめ

主に起業家や起業家を志す人に向けて書かれているように感じたが、いちソフトウェアエンジニアとしても参考になる部分が非常に多く、読んでよかった。

解像度を上げるための4つの視点「深さ」「広さ」「構造」「時間」は非常に有用なフレームワークだと感じたのでしばらくは意識的に使ってみようと思う。

この箇条書き複数パターンの例示であることが伝わっている…と信じたい。 ↩︎
https://forbesjapan.com/articles/detail/38119 ↩︎
文脈を読めばわかるだろという意見もあるかもしれないが、可能な限りローコンテキストに記述することで読み手の認知負荷低減に繋がり、結果としてコミュニケーションコストを下げられると考えています。 ↩︎

『CQRS Documents by Greg Young』を読んだ

Mon, 12 Jan 2026 00:27:58 +0900

CQRSに興味があったのでGreg Young氏のCQRS Documentsを読んでみた。

https://cqrs.wordpress.com/wp-content/uploads/2010/11/cqrs_documents.pdf

CQRSに興味を持ったきっかけ

ドメイン層のメンテナビリティの重要性を感じる中で、ドメイン層は書き込み系の振る舞いだけを担い、読み取り系の責務は別のモジュールに移譲してしまった方がドメイン層をシンプルに保てて良いのではないかと考えるようになった。¹

それってCQRSってやつじゃね？と思ったのでまずは原典に近いドキュメントを読んでみることにした。²

ここからはCQRS Documentsの内容をまとめていく。

“A Stereotypical Architecture”: 典型的なアーキテクチャ

“A Stereotypical Architecture"として、典型的なアーキテクチャが紹介されている。CQRS Documentsではこのアーキテクチャに対して段階的にCQRSを導入していく形で説明が進んでいく。

CQRS Documents by Greg Young P2より引用

このアーキテクチャではシステムはCRUDのみの機能を持ち、クライアントとは常にDTOを介して通信する。

おそらくクライアントがUpdateUserNameのようなエンドポイントに更新後のユーザーネームだけを渡すのではなく/userに更新後のDTOを丸ごと渡す、というようなことだと思われる。

サーバー側では受け取ったDTOをドメインオブジェクトに詰め替えてバリデーションを行い、永続化する。

このような設計ではアプリケーションサービスの責務はDTOとドメインオブジェクトの詰め替えに終始し、ドメイン層はバリデーションを主な責務として受け持つ。データの更新方法はクライアントに委ねられてしまうため、ドメイン知識の一部がクライアント側に漏れ出してしまう。

このようなアーキテクチャでは簡潔性によってオンボーディングコストが低くなるメリットがある代わりに、次のような課題が存在する。

スケーリング: 一般的なシステムでは読み取り操作は書き込み操作よりも2桁以上多い。読み取り操作から見ると非正規化されたデータ構造が適しているが、書き込み操作から見ると正規化されたデータ構造が適している。これらを単一のDBで扱おうとすると垂直スケーリングが必要になるが、垂直スケーリングには非常に高額なコストがかかる。
DDD適用の困難さ: この設計ではAPIがデータ指向のインターフェースを持つため、システム全体がCRUDの4つの動詞に縛られる。（データの更新方法がクライアントまたはユーザー側に漏れ出ておりドメイン知識をソフトウェアで表現することが難しいため）

ここまでの感想

さすがにこういったアーキテクチャのシステムは見たことがないので極端な例では…?とは思いつつ時代や場所によってはこういった設計のシステムも存在するのかもしれない。

CQRSとは

CQRSはBertrand Meyerが提唱した『Command and Query Separation Principle』にその起源を持つ。Wikipediaではこの原則を次のように説明している。

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both.

Command–query separation - Wikipedia より引用

とあり、すべてのメソッドはCommandかQueryのいずれかであるべきであり、両方を兼ねるべきではないと説明されている。

これに対し、Martin Fowlerは以下のようにPopのような操作はCommandでありQueryでもあり、必ずしも上記の原則を厳密に守らなくてもいいのではないか、ということを述べている。

Meyer likes to use command-query separation absolutely, but there are exceptions. Popping a stack is a good example of a modifier that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. So I prefer to follow this principle when I can, but I’m prepared to break it to get my pop. (Fowler)

CQRS Documents by Greg Young P17より引用

ここまでの感想

実際にWebサービスを開発していてもたとえばユーザー作成メソッドが作成したユーザーのIDを返すような処理は普通に書くし、自分もどちらかというと定義ほどは厳密に運用しなくても十分恩恵を受けられるのではないかという立場。

“A Stereotypical Architecture"にCQRSを導入する

“A Stereotypical Architecture"として最初に紹介されたアーキテクチャでは、ドメインモデルがCommandとQueryの両方に使用されていた。このアプリケーションにCQRSを適用するとQuery側とCommand側はそれぞれ次のようになる。

Query

Query処理側にはデータ取得のためのメソッドのみが含まれる。

元のアーキテクチャではドメインモデルを生成し、それをDTOにマッピングしたうえでクライアントに返却していた。多くの場合でドメインモデルとDTOは異なるモデルであるため、以下のような課題があるがこれがCQRSの適用によって解決される。

複数集約から1つのDTOを生成する場合、複数回DBにアクセスする必要がありパフォーマンスが低下する。また、集約の境界が曖昧になる。
ドメイン層にQueryの責務が多く含まれている（e.g. repositoryのinterfaceにQuery系のメソッドが多く含まれ、ページングやソート情報が含まれている）

After CQRS has been applied there is a natural boundary. Separate paths have been made explicit. It makes a lot of sense now to not use the domain to project DTOs. Instead it is possible to introduce a new way of projecting DTOs.

CQRS Documents by Greg Young P20より引用

とあるように、CQRSを適用することでCommandとQueryの処理経路が明確に分離される。この段階ではドメインモデルをDTOの生成に使用しない方が合理的である。

その代わりに"Thin Read Layer"という方法でDTOを生成することができる。

CQRS Documents by Greg Young P21より引用

この層はDBから直接データを読み取り（ドメインモデルを迂回し）DTOを生成する。

こうすることで、ドメイン層からQueryの責務を切り離すことができ、ドメイン層の純度を上げることができる。

Command

CQRSを適用するとCommand側のアーキテクチャは以下のようになる。

CQRS Documents by Greg Young P22より引用

元のアーキテクチャでは書き込み系の処理をする際もDTOをクライアントから受け取っていたが、CQRS適用後はデータ中心ではなく振る舞い中心の契約を採用している点と読み取り処理が分離されている点が大きな違い。（元のアーキテクチャでは書き込み時にクライアントからDTOを渡していたが、ここではメッセージが渡されるようになっている）

また、元のアーキテクチャでドメイン層に存在していた次のような課題が解決されている。

リポジトリに大量の読み取りメソッドが存在する
DTO構築のためにドメインオブジェクトの内部状態を公開するゲッターメソッドが存在する
DTO構築のために複数の集約オブジェクトをそれぞれ読み込むことで、非効率なクエリが実行される

ドメインイベント、イベントソーシング

本文にはドメインイベント、イベントソーシングについても記載があり読んだがここでは割愛。

ここまでの感想

ドメイン層からQuery系の責務を切り離すことでメンテナビリティが向上する、というのが自分が（直近）CQRSに興味を持っていた一番の理由だったのでそうだよなーと思いながら読んだ。

また（書いてあるとおりだが）読み取り単位を必ずしもドメインモデル単位にする必要がないためパフォーマンスの最適化が行いやすい点も大きなメリットだといえそう。

結局CommandとQueryはまったく別の責務なことが多いので両者を分離することでメリットを得られるケースは多そう。

作業習慣の違い

CQRS Documentsを読むまでは意識していなかったが、CQRSを採用することで

ドメイン層
リードモデル
クライアント

の3つの要素に分解して作業を進めることができるため、プロジェクトに関わる開発者数をより効果的に増やすことができる。（サーバーとクライアントの作業分担をできるのはCQRSかどうかにかかわらないが、重要なのは1つのサーバーアプリケーションを2並列で安全に進めやすいという点だろう。）

また、開発者には次のような観点の差異が存在する。

技術的熟練度
ビジネスドメインに関する知識
コスト
ソフトスキル

ドメイン層の実装には4つすべての項目が秀でた人材が最適である一方、リードモデルの実装にはそれらの開発者要件は必ずしも当てはまるとは限らない。

ここまでの感想

開発効率の観点は持ってなかったが、たしかにCQRSを採用することで（1つのアプリケーションが2つのモジュールに分離されるので）コンフリクトせずに開発を進めやすそう。（モジュール設計はプロジェクトによるので厳密には2つのモジュールとは限らないが）

感想

事前のイメージ通り、CQRSを適用することで開発効率を高められそうなイメージが持てた。

CQRS Documents内でも触れられていたが、結局CQRSにしろイベントソーシングにしろ一定のオーバーヘッドはあるので、システムやビジネスの課題や要件、今後の見通しを元に必要性を検討するのが（いつだって）重要そう。

というのはありつつ、ドメイン層のメンテナビリティを高めるためにCQRSを採用するのはかなり有効な選択肢の1つだとも感じているので、ひとまず個人のプロジェクトで検証してみたいと思う。

もちろんアプリケーションの状況にもよるが…。repositoryのRead系メソッドの返り値がドメインモデルと一致しないケースが多くなるような場合では特にCQRSのメリットが効果を発揮しやすいような気がしている。状況にかかわらずCQRSをやったほうがいいのかどうかはまだあまりわかっていない。ちなみにここでのCQRSは基本的には同一DBでCのアプリケーションコードとQのアプリケーションコードが分離されている、くらいの方法をざっくり想定して書いている。（CとQでDBを分けるパターンは流石にtoo muchなケースが多そうなので） ↩︎
厳密にこのドキュメントが原典であることを確認したわけではない。正確な情報をお持ちの方がいたら教えて下さい。 ↩︎

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだ

Mon, 22 Dec 2025 00:13:06 +0900

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだので感じたことをメモしておく。

『ＲｕｓｔによるＷｅｂアプリケーション開発　設計からリリース・運用まで』（豊田　優貴,松本　健太郎,吉川　哲史）　製品詳細　講談社

★Rustによるアプリケーション開発のベストプラクティス！　Rustを現場で使うときがきた！ Rust経験豊富な筆者が、貴重な知識とテクニックを惜しみなく伝授。「蔵書管理アプリケーション」の実装を通じて、Rustによる設計、開発、保守、運用までをハンズオンで学ぶ！コードも丁寧に解説。【目次】第1章　本書で開発するもの第2章　開発環境の構築第3章　最小構成アプリケーションの実装第4章　蔵書管理サーバーアプリケーションの設計第5章　蔵書管理サーバーの実装第6章　システムの結合とテスト第7章　アプリケーションの運用第8章　エコシステムの紹介

https://www.kodansha.co.jp/book/products/0000398182

モチベーション

Rustという言語の開発体験がかなり好きでRustでサーバーサイドを書くのがどんな感じなのか純粋に気になっていたので読んでみた。（筆者がサーバーサイドの開発でガッツリ書いたことがあるのはほぼGoのみで、RustはCLIやTUIの開発にしか使ったことがないというバックグラウンド）

本書の概要

本書はRustで蔵書管理アプリケーションのサーバーサイドを実装しながらRustでのWebアプリケーション開発の仕方を学ぶことができる本。

ただ動くものを作る、というよりは業務の実際のサーバーサイドの開発でよく出くわす課題をRustではどう実装するのかが豊富に紹介されている。(DIやエラーハンドリングなど)

設計面ではレイヤードアーキテクチャを採用しており、レイヤー間の責務などが考慮された設計になっている。その意味でも実務での開発に近い内容になっていると言える。

あとはステップごとのコード差分が丁寧に書かれているので、本書に従って実装を進めるとWeb Serverの実装が出来上がる（はず）。¹

学び

コンパイル時間短縮の工夫
- アプリケーションを複数のクレートに分割することで変更があったクレートだけ再コンパイルすればよくなるためコンパイル時間が短縮できる。
- たとえば本書ではレイヤードアーキテクチャのレイヤーごとにクレートを分割していた。
Web開発で有用なクレート
- derive_new: new関数を実装してくれる。デフォルト値の設定などもできる模様。
- serde: 言わずと知れたシリアライズ/デシリアライズのためのクレート。
- sqlx: SQLを型安全に扱うことができる。
エラーハンドリングの方法
- クライアントに返すエラーはthiserrorで定義し、それ以外のエラーはanyhowを使って表現する。
RustでどうDIを実装すべきか
- ジェネリクスを用いてDIするパターン（静的ディスパッチ）
  - 動的ディスパッチと比較すると記述量が増える
  - 動的ディスパッチと比較するとパフォーマンスが高い
- トレイトオブジェクト（dyn <トレイト名>）を利用するパターン（動的ディスパッチ）
  - 静的ディスパッチと比較すると記述量が減る
  - 静的ディスパッチと比較するとパフォーマンス面で不利
  - 本書ではWeb開発において動的ディスパッチのコストが問題になることは少ないことを理由にこちらを採用していた。

実際にRustでWeb Serverを書いてみた感想（主にGoとの比較）

※なお、筆者のRustスキルは趣味レベルなのでRustを深く理解したうえでの感想ではありません。間違っている点や他の重要な観点などがある可能性があります。また、主には個人的な考えのスナップショットを自分用に残す目的で書いているので説明を端折っている箇所がある可能性があります。

ポジ

enumやパターンマッチ等を使って仕様をスマートに書ける。
null安全なので他の言語のnull相当の概念を型安全に扱うことができる。
if式を始めとした関数型ライクな言語機能のおかげで開発体験が良い。
変数がデフォルトでimmutableなので、mutableな変数を目立たせやすいし、自然とimmutableなコードが書きやすい。
あらゆるシンボルがデフォルトでprivateなのでカプセル化するようなコードが若干書きやすい。（意識的にpubを付けなければprivateになってくれる点で強い理由がなければprivateになりやすくなる、と考えている）

ネガ

コンパイル時間が長い。
コンパイル時間短縮のためにcrate分割が推奨されているが、依存関係の増減があるたびにCargo.tomlを手書きで編集しないといけないのが若干面倒。
- もしかしたらコードアクション等、エディタの支援が得られるのかもしれないがそこまで調べられていない。

Goに慣れているとRustのマクロやアトリビュートが若干黒魔術的に感じる。これらに慣れるまでは認知負荷が高そう。例えば以下。（『RustによるWebアプリケーション開発設計からリリース・運用まで』より引用）

#[derive(Error, Debug)]
pub enum AppError {
    #[error("{0}")]
    UnprocessableEntity(String),
    #[error("{0}")]
    EntityNotFound(String),
    #[error("{0}")]
    ValidationError(#[from] garde::Report),
    #[error("トランザクションを実行できませんでした。")]
    TransactionError(#[source] sqlx::Error),
    #[error("データベース処理実行中にエラーが発生しました。")]
    SpecificOperationError(#[source] sqlx::Error),
    #[error("No rows affected: {0}")]
    NoRowsAffectedError(String),
    #[error("{0}")]
    KeyValueStoreError(#[from] redis::RedisError),
    #[error("{0}")]
    BcryptError(#[from] bcrypt::BcryptError),
    #[error("{0}")]
    ConvertToUuidError(#[from] uuid::Error),
    #[error("ログインに失敗しました")]
    UnauthenticatedError,
    #[error("認可情報が誤っています")]
    UnauthorizedError,
    #[error("許可されていない操作です")]
    ForbiddenOperation,
    #[error("{0}")]
    ConversionEntityError(String),
}

DIが若干複雑
- Goならinterface使うだけなので考えることが少なくて済む。
非同期処理
- これもRustの非同期処理の仕組みへの理解²が大変浅いのであまり具体的に書けないが、自分の現状のRustスキルだとGoに比べて意図通りに動く非同期処理を書くのに数倍時間がかかる。

まとめ

本書を読むまではRustがWebサーバーサイド開発の銀の弾丸、とまでは言わないもののかなりいい選択肢の1つのように思えていた。主に型の表現力のおかげでドメインがうまく表現できたり、所有権などの言語機能や発達したリンターによって内部品質を高く保つことができ、その結果開発生産性が高まると考えていた。

しかし実際に本書でRustでサーバーを書いてみると上記のメリットはありつつも意外とRustでの実装でも手間や複雑なポイントがあり、Goのシンプルさや手軽さの良さを改めて認識した。

結果はともあれ実際にRustでサーバーを書くのがどんな感じなのかを知ることが本書を読んだ目的だったので解像度を高めることができてよかった。³

5章の途中までしかやっていないので「はず」と書いている。 ↩︎
あるいは単にコンピュータの仕組みへの理解が浅いとも言えるのかもしれない。 ↩︎
もちろんもっとDeep Diveしたら違う感想を持つかも知れないが、あくまで今時点の自分の感想としては上記のような感じ。 ↩︎

『コンセプトから理解するRust』を読んだ

Mon, 15 Dec 2025 19:21:35 +0900

Rustのことをもっと理解りたくて『コンセプトから理解するRust』を読んだ。

コンセプトから理解するRust | 技術評論社

Rustはメモリ安全、スレッド安全を保ちつつ、高パフォーマンスなプログラムを開発できるプログラミング言語です。また、手続き型、オブジェクト指向型、関数型でのプログラミングに対応できるマルチパラダイムの言語でもあります。ただ、そういったRustのポテンシャルを引き出すには、所有権やライフタイム、ジェネリクスやトレイトといった特徴的な仕様の理解が求められ、これらは初学者の壁にもなっています。本書ではそれら難解な仕様をピックアップし、他のプログラミング言語とコードレベルで比較しながら、「なぜそのような仕様になっているか」という言語のコンセプトからRustの理解を試みます。加えて、Rustのこまやかなエラーメッセージを読みつつ、Rustをうまく書くための知識もお伝えします。

https://gihyo.jp/book/2022/978-4-297-12562-2

前提

筆者のRustの知識はTour of RustやThe Rust Programming Languageを読んだり簡単なツール¹を作ったことがある程度で、非同期処理をスラスラ書けたり、スムーズに人に教えたりできるレベルではない。

過去にThe Rust Programming Languageを読んだときもスマートポインターまわりなどは飛ばしつつ読んでいたので本書での学びは多かった。

学び

Boxについて理解した。
Rc, RefCell, Weak周りをなんとなく理解した。たぶん空では書けないが、エラーになったら調べて解決できるくらいの理解にはなったはず。
トレイト境界についてちょっとわかった。
クロージャ, Fn, FnMut, FnOnceについて理解できた。
簡単な非同期処理の仕組みがわかった。

今まで全然わかっていなかったこれらの概念が少しだけわかった。やはりコードを書き散らかすだけでなく体系的なインプットも大事…。（それはそう）²

おそらく今後Rustを書いたりコンパイラと対話したりしていくともう少し深く理解していけると思う。³

全体を通してコード例が豊富だったので手元で動かしながら理解しやすくてとてもありがたかった。

まとめ

Rustの力がまた少しついた。

Rustを学ぶとRust自体への理解が深まるだけでなく、少なからずコンピュータの仕組みに近い低レイヤな部分の理解も一緒に深まるので勉強になる感覚があって楽しめた。

非同期処理周りはあまりちゃんと勉強したことがないので次はこの本を読んでみようと思う。（サンプルコードが主にRustで書かれているらしいのでこの本での学びも活かせそう）⁴

並行プログラミング入門

複数のプログラムを同時に実行する「並行プログラミング」は、処理速度を飛躍的に向上させる手法で、タスク管理、プロセス管理、スレッド管理をはじめ、複雑な仕組みについての幅広い知識とテクニックが必要となります。本書はRustとアセンブリ、そして一部Cを用い、CPUのアトミック命令、グリーンスレッド、アクターモデル、π計算、ソフトウェア・トランザクショナルメモリ、async/awaitなど、並行プログラミングに関する理論的な背景から実装までをカバー。さらに、アセンブリ実装の理解を深めるため、AArch64とx86-64アーキテクチャの説明も付録として収録。一歩一歩、着実に理解できるように、その仕組みから順を追って詳しく説明します。GitHub上で公開されているソースコードを実際に動かしながら、並行プログラミングの知識と理解を深めることができます。

https://www.oreilly.co.jp/books/9784873119595/

おまけ

The name “Tokio” is derived from Tokyo and mio, and the Tokio logo vaguely resembles the city emblem of Tokyo.

https://en.wikipedia.org/wiki/Tokio_(software)

Rustの非同期ランタイムのtokioの名前の由来の一部は東京らしい。

あとロゴも東京都の紋章を彷彿とさせるデザインになっているらしい。（実際調べてみたら似ているというかほぼ同じだったw）

fzf-makeというTUIツールを書いている。あとそういえばnand2tetrisもRustで書いていた。 ↩︎
趣味のプログラミングなのでRustを覚え始めた頃は楽しさ優先でまあ動けばOKという気持ちで書いていたが最近になってちゃんと理解したくなってきたので学んでいる。 ↩︎
あるいは各種概念を自作するという選択肢もあるかもしれない。Arcとか非同期ランタイムとか…。 ↩︎
他には詳解 Rustアトミック操作とロック、Async Rust 、RustによるWebアプリケーション開発　設計からリリース・運用まであたりもとても気になっている。 ↩︎

『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ

Wed, 10 Dec 2025 00:04:41 +0900

0からKubernetesのキャッチアップがしたくて、高橋あおいさん著の『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ。

つくって、壊して、直して学ぶ Kubernetes入門 | 翔泳社

動かなくっても、もう怖くない！トラブルシューティングを体験しながら学ぶ、実践的入門書。本書は、Kubernetesの実践的な知識をハンズオン形式で解説する書籍です。本書の特徴は、壊れにくいKubernetesをあえて壊しながら学ぶことで、初心者が挫折しやすいトラブルシューティングの知識や対応力が身に付けられることです。初心者でも、経験者でも、今度こそKubernetesがわかる！マンガや図解を多く掲載しているため視覚的に理解したい方にもおすすめです。・つくって、壊して、直して学ぶ - DockerfileからDockerコンテナをつくる - Kubernetesクラスタ上にアプリケーションをつくって、壊す - Serviceを壊す - kubectlでデバッグする - OutOfMemoryを発生させて、直す　... ・Kubernetesの構築、運用だけでなくオブザーバビリティも解説トラブル解決にむけてより多くの情報を得るための「オブザーバビリティ」、そしてトラブルを検知するための「モニタリング」についても説明します。・豊富なイラストとマンガで見てわかる章ごと、ハンズオンごとに導入マンガを掲載し、視覚的にも学習内容を理解できるようにしています。むずかしい概念もイラストで丁寧に図解してあります。 Part 1：つくってみようKubernetes Chapter 1　Dockerコンテナをつくってみる Chapter 2　Kubernetesクラスタをつくってみる Chapter 3　全体像の説明 Chapter 4　アプリケーションをKubernetesクラスタ上につくる Part 2：アプリケーションを壊して学ぶKubernetes Chapter 5　トラブルシューティングガイドとkubectlコマンドの使い方 Chapter 6　Kubernetes リソースをつくって壊そう Chapter 7　安全なステートレス・アプリケーションをつくるために Chapter 8　総復習：アプリケーションを直そう Part 3：壊れても動くKubernetes Chapter 9　Kubernetesの仕組み、アーキテクチャーを理解しよう Chapter 10　Kubernetesの開発ワークフローを理解しよう Chapter 11　オブザーバビリティとモニタリングに触れてみよう Chapter 12　この先の歩み方

https://www.shoeisha.co.jp/book/detail/9784798183961

そもそものモチベーション

今年の2月から仕事でKubernetesを使い始めたが、普段はk9sを使ってデプロイが完了したかどうかを確認するくらいでそれ以上高度なことは全然できていなかった。

そんな状態なのでトラブルシューティングや運用を独力で全然できないことに課題感を感じていた。

新しい技術を学ぶときは手を動かしながら学ぶのが好きなのでこの本を手に取ってみた。

特徴

本書は、Kubernetesの実践的な知識をハンズオン形式で解説する書籍です。本書の特徴は、壊れにくいKubernetesをあえて壊しながら学ぶことで、初心者が挫折しやすいトラブルシューティングの知識や対応力が身に付けられることです。初心者でも、経験者でも、今度こそKubernetesがわかる！

マンガや図解を多く掲載しているため視覚的に理解したい方にもおすすめです。

という書籍説明の通り、ハンズオン形式でKubernetesを学ぶことができる。

また、Kindというツールを使ってローカルでKubernetesクラスタを構築するのでクラウドの登録や課金を気にする必要がないのも手軽でよかった。

GitHub - kubernetes-sigs/kind: Kubernetes IN Docker - local clusters for testing Kubernetes

Kubernetes IN Docker - local clusters for testing Kubernetes - kubernetes-sigs/kind

https://github.com/kubernetes-sigs/kind

1つ1つの解説はそこまで文量がないので結構サクサク進めることができる。なので本書でKubernetesの全体感を本書で学び、深く学ぶのは別のリソースで補うのがよさそうだと感じた。¹

誤解のないように書いておくと、自分のようなKubernetes初心者にとっては各リソースの説明の文量が多すぎないお陰で短期間で全体感を把握できてとてもよかった。(気になったところは別途公式ドキュメントやLLMを使って深堀ったりした)

こんな雰囲気。漫画があって文量も多すぎず読みやすい。

商品ページより引用

以下の画像のように実行すべきコマンドとその結果がどうなるかが書いてあるのでKubernetesの経験が少なくても進めやすい。（実際自分もほぼ知識0で臨んだ）

商品ページより引用

こんな感じでk9sを常時起動しながらコマンドを実行するスタイルで進めたところリアルタイムでPodの変化が見れて理解が捗った。

GitHub - derailed/k9s: 🐶 Kubernetes CLI To Manage Your Clusters In Style!

🐶 Kubernetes CLI To Manage Your Clusters In Style! - derailed/k9s

https://github.com/derailed/k9s/

学び

kubectlの使い方
Pod、Service、Deploymentなどの基本的なリソースの性質や動かし方
Readiness probe, Liveness probe, Startup probeの特徴や使い方
Resource Requests/Limits, HPA, Affinity, HPA, VPAなどの性能やスケールなどに関する機能の使い方
Kubernetes自体のアーキテクチャ
etc.

感想

0からKubernetesの基礎を学ぶことができてとても良い本だった。
ちょうど仕事でmanifestを書くタイミングがあったので本書で学んだことがダイレクトに活きてとても助かった。物事の解像度が上がるのはいつだって楽しいな〜と再確認した。²
次はしばらく積んでしまっていた『体験しながら学ぶネットワーク技術入門』をやっていく。

本書後半でも紹介されているが本で詳しく学ぶならKubernetes完全ガイド第2版がいいらしい。 ↩︎
たとえばリクエストが全然きてないマイクロサービスのPod数が一瞬2倍になっているグラフをみて、maxSurge: 100%でRollingUpdateしてるな〜と思えたりとか。 ↩︎

『デッドライン』を読んだ

Sun, 23 Nov 2025 10:43:53 +0900

少し前にTwitterで紹介されていて気になっていた¹トムデマルコの『デッドライン』を読んだ。新品で売ってるところが見つからなかったのでAmazonで中古を購入した。²

プロジェクトマネジメントをするたびにその難しさを痛感しているので知見が得られたり思考が整理できたりすることを期待して読んだ。

同著者の本だと『ピープルウエア』が有名だがそちらは未読。『ゆとりの法則』とかも面白そうなのでいつか読みたい。

というわけで参考になったところを紹介していく。（なお(P84)のような数字はページ数を示す。）

生産性の向上(P84)

短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。

（本筋ではないが）まずこれを読んだときに手作業の自動化のためのCI/CDを整備したら短期的に生産性はあがるのでは？と思った。

が、ここでの生産性は「期間あたりのアウトプット」のことを指していて、「期間あたりのアウトカム」を指しているわけではないのかもしれないと解釈してひとまず納得した。（そもそもそんなに細かい話はしていない、またはCI/CDのような比較的すぐにできて明らかに生産性に寄与する施策はすでに実施済み、という前提はあるのかもしれない。）

なので「生産性を大きく向上させるためには長期的な投資が重要なことが多い」くらいに捉えてみる。

たしかに長期目線でチームの生産性を大きく向上させるにはチームとしての練度を向上させたり、リアーキテクティングをはじめとした技術的負債を解消したり、スキルアップを図ったりといったことが必要になることが多いように思うのでその意味では同意できる文だった。

スタートアップではリソースが限られる中で短期的にマストでやらなければいけないことをこなす必要があったりするので長期的な施策への投資バランスが本当に難しい。（とはいえ少しでも時間を見つけて長期的な施策を少しずつでも進めていくしかないか）

リスク管理(P84)

リスクを管理することによってプロジェクトを管理せよ。

それぞれのリスクの実現する確率と予想コストを評価せよ

プロジェクトマネジメントをしていると「どう不確実性を取り扱うか」というのが難しく、かつ一番重要度が高いように感じる。

プロジェクト（以下PJと表記）を進めていると様々な不確実性によってスケジュール遅延が発生し、品質が落ちたり、計画を変更してPJ期間を延ばしたり、スコープを削ったり、あるいは人員を追加したりというアクションが必要になる。（場合によっては残業が増えたりもする）

そして何より、当初の見積もりを超過するとエンジニア当人が感じるプレッシャーが増えたりモチベーションが下がったりする。（自分だけかもしれないが）

なので可能な限り見積もりからのズレを減らしたくなる。（見積もりのズレが減って悲しい人はいないはず）

今のところは可能な限り見積もりからのズレを減らすためにはこのあたりのことを意識してみている。

見積もりがズレたらその原因を分析して次回以降に活かす
そもそも見積もりという行為自体が不確実性をはらんでいることを理解する
不確実性を早期に削減することでPJ後半に手戻りや遅延が発生する確率を下げる

1.に関しては組織、人によってまちまちだと思うが最近自分が発見したズレの要因はこのあたり。

（プロマネと実装を兼任する場合に）プロマネタスクのための時間を確保し忘れていた
設計をチームに共有するための資料等の準備時間やレビュワーからもらったフィードバックを反映する時間を見積もりに含めていなかった

特にプロマネと実装者を兼務している場合、状況が変わった際のスケジュールの組み直し、タスク実行順をどうするかの検討、ステークホルダーへの報告や相談などのプロマネタスクに意外と時間がかかることを直近のPJで学んだ。

2.への対策としては2点見積もり、3点見積もりのような手法を用いたり、見積もりをレンジで表現したりすることが考えられそう。（e.g. 「7月1日にリリースできそうです」と伝えるのではなく「7月前半にリリースできそうです」のように範囲で伝える。）

PJが進むに連れて不確実性が下がっていき、見積もりの精度も上がっていくはずなので徐々にレンジも狭くなっていくはず。なのでステークホルダーに一度伝えて終わり、というよりはチェックポイントごとに最新の見積もりを伝えるのが良さそうに思う。

3.については不確実性コーンに従って不確実性が下がっていくようにPJ初期の要件定義や設計の段階で大きな不確実性を潰しておくことが重要そう。

人材管理の智将(P94)

プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。

一日をむだにする方法はいくらでもある…しかし、一日を取り戻す方法は一つもない。

真理みがある。真理過ぎてあまり書くことがない。

これを見て小学校のころのサッカーのコーチの「そのリフティングの1回はもう帰ってこないよ（だから集中して取り組もう）」という言葉を思い出した。

プレッシャーの効果(P200)

プレッシャーをかけても思考は速くならない。

一時的なプレッシャーや残業は、人びとの焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。

自分もプレッシャーが大きすぎるとパフォーマンスが落ちるタイプなのでとてもわかりみがあった。

振り返ってみると特に明示的でないプレッシャーがあるとパフォーマンスが落ちやすい気がした。「xx月yy日までにリリースしたい」のようなものではなく「なんか上司から圧を感じる。今のままだとダメな気がする…」みたいな状態。要求（の理解）が明瞭ではないので目標が定まらず、辛い感じになりがち。（今思えば上司とコミュニケーションをとって明確にするのがよさそうではある）

残業時間を増やすのは、生産性を落とす方法である。

残業が常態化し「あとで残業すればいっか〜」というマインドになってしまうと結局日中の生産性は落ちてしまい無駄が増えてしまうので気をつけたい。

一方で昼夜問わず猛烈にコミットして成果を出しまくっている人も身の回りに複数いるので必ずしも残業が悪とまではいえない気持ちにもなっている。（あくまで今の自分がそう感じるというだけ人/時期によっては残業しないことの重要度が高まることは普通にあるとは思う）

そういえば残業の話は『世界一流エンジニアの思考法』にも書いてあったなーと思い出した。

ここでの示唆は、業務だけに自分の時間を使ってしまうと

学習によって自分の生産性を向上させることがしずらい

残業前提で成果を出すため再現性が低い

ということだと思う。残業しすぎないことで学習の時間を確保したり、開発プロセスの改善やスコープの調整によってうまく成果を出せるようにできていることが重要なのだと思う。

https://blog.kyu08.com/posts/how-world-class-engineers-think/#%E3%82%BF%E3%82%A4%E3%83%A0%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E5%88%B6

スタッフの人数(P259)

初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。

このため、相互依存性が高まり、会議が増え、やり直しが増え、フラストレーションがたまる。

チームの人数が多すぎる場合、設計段階で全員にタスクをふろうとすると対象ソフトウェアへの理解が不十分な段階で人為的にソフトウェアを部分に切り分けて担当をアサインすることになる。

そのため人と人とのインターフェースが無駄に複雑化してしまい、コミュニケーションコストが増大する、ということを言っていると理解した。

そのため設計段階までは少人数で進めてタスクを切り分けられる段階まできたら人数も増やしてもよいのではないか、ということが書かれていた。

ここで得られる示唆としては

対象ソフトウェアへの理解が曖昧な状態では正しく切り分けることができない（マイクロサービス化にもいえそう）
チームの人数をいたずらに増やすべきではない

というようなことかなと思った。（生産性以外にも様々な事情があるケースもあるとは思うので一概には言えないが）

まとめ

プロジェクトマネジメントについていろいろと示唆を得られてよかった。

物語調だったので隙間時間にサクサク読みやすかった。

数冊の積読があるので年内に消化できるようにやっていきたい…。（k8s本³とかネットワークの本⁴とか）

『Tidy First?』を読んだ

Sat, 04 Oct 2025 08:21:10 +0000

『Tidy First?』を読んだ。

勉強になったところをまとめる。

「整頓」という概念

整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。

リファクタリングほど大掛かりなものではなく、数十分でできるような小さな改善を本書では「整頓」と呼んでいる。

具体的にはコードコメントを追加したり適切な位置に空行を配置したり適切な変数名に変更したりすることなどを指している。

この「整頓」という概念を知ることができたのが本書を読んで得られた最大の収穫だった。今までそのような行為に名前をつけたことがなかったが名前をつけることで使い所や意義が明確になり意識的に実践できるようになりそう。

なお本書では「整頓」と「振る舞いの変更」の順番やタイミング、粒度や意義について様々な角度から書かれているので気になる方はぜひ手にとってみてほしい。

第11章ステートメントを小分けにする

大きなコードのチャンクを読んでいると、「ああ、ここはこれをしていて、あそこであれをしているのか」とわかる。そのあいだに空行を入れよう。

長めの関数を読むとき、空行がまったくないことは少ないが空行の位置を改善できそうだと感じることがたまにある。

処理の塊ごとに適切に改行されているだけでそこそこ可読性が上がる実感があるのでやってみようと思う。（空行の追加/削除のみのPRであればレビュワーの負担もかなり少ないはず）

第13章ひとかたまり

細かく分割されているがゆえに、かえって理解を妨げているようなコードに出会うことはないだろうか。

超巨大な関数はテストしづらく可読性も低いので避けたいが、逆にすべての処理を関数として切り出してしまうと毎回定義ジャンプしないと処理の内容がわからないのでかえって読みづらくなってしまう。

テストが書きやすい程度に細かくかつ可読性が落ちない程度には大きく関数を切り出すのがよさそうで、いい塩梅を探るには複数のパターンを実際に書いてみて読みやすいかどうかを判断するのがよさそう。（実際に複数パターンを書いてみると意外とすぐに書けることが多いし、しかも実際に書いてみると事前の想定とは印象が違うことが多いように思う）

小さな部品に分けようとするのは、コードを少しずつ理解できるようにしたいからだ。だが、ときには、このプロセスが間違った方向に進むことがある。小さな部品のやりとりの仕方によっては、コードが理解しにくくなるのだ。明確さを取り戻すには、まずはコードを1箇所に集めて、それから改めて、簡単に理解できる部品を抽出する。

1000行の関数でこれをやるとさすがに辛そうだが、100行前後くらいであればひとまず1つにまとめてから再構成するのはたしかに良さそう。

第14章説明コメント

コードを読んでいて「なるほど、それでこうなっているのか」と声が出ることがある。これは貴重な瞬間だ。記録しよう。

コードリーディングの結果、必要なコメントが欠けていることに気づくことがある。

そういった場面でこれまであまりPRを作ったりはしてこなかったが、説明コメントの追加も立派な整頓であり将来の読者（当然将来の自分を含む）の時間を節約することに繋がるのでやっていきたい。

説明コメントの追加PRはレビュワーの負荷が少ない割にレビュイーとレビュワーのコード理解を深められる点で比較的コスパの良い取り組みな気がした。（正確な説明コメントを書くための調査が大変、とかはあるかもだが）

第19章リズム

1つの整頓にかける時間はここでは1時間くらいまでが許容範囲とされており、それを大幅に超過するようであれば変更の単位が大きすぎる兆候らしい。

こんな話を聞いたことはないだろうか。ある大学がたくさんの建物を造った。計画者は、それを結ぶ歩道をどこに造るか考えていた。だが、そこで経験にもとづいて注意深く推測するのではなく、建物のあいだのエリアに芝生を植えたのだ。数か月後、学生の歩いた跡によって芝生に道ができた。計画者は芝生がなくなったところを舗装した。

コードにおいて、振る舞いの変更は一部に集中する傾向にある。パレートの法則にあるように、80%の変更は20%のファイルで起こる。

（計画者天才すぎワロタ…）

変更の前に整頓することを続けていくと頻繁に変更される20%のコードがどんどん綺麗になっていく、ということを言っているのだと解釈した。

そうした取り組みを続けていくとコードの大部分は手直ししてないにもかかわらず整頓していないコードに出会うことは稀になる。逆に言うと仮にコードの50%を頑張って綺麗にしたところで、その50%に変更がまったく入らないのであれば投資対効果が高いとはいえないかもしれない。（当然、コード全体が複雑に絡み合っていて一部だけ再設計することが難しい場合や全体的に変更しないと一貫性がなくなる場合などはその限りではないと思う）

なのでコードを修正する際は単純にある時点のコードベースだけを見てコード品質に改善点が見つかったというだけの理由で修正する、というよりは修正すべき合理的な理由（e.g. 内部品質が課題で問題が起きている、よく変更が入る箇所が変更しづらくなっているなど）がある箇所から対応していくのがよさそう。

第21章先に整頓、あとに整頓、改めて整頓、整頓しない

整頓を変更の前にやるか、あとにやるか、将来時間がとれたときにやるか、あるいはまったくやらないかについて論じた章。

章のまとめにもあるように結局はビジネスにとって合理的なタイミングでやるのがよい、ということなのだと思った。（言葉にするとそれはそうという感じではあるが）

「改めて整頓する」と「あとに整頓する」の区別はあまり考えたことがなかったが、整頓が完了するまでの必要工数が大きいケース以外は「あとに整頓する」に寄せるのが良さそうに感じた。

第25章明日の1ドルより今日の1ドル

お金を生む振る舞いの変更を今すぐ実装して、あとから整頓できるなら、すぐにお金が手に入り、あとでお金を使うことになる(前述のとおり、ときには先に整頓してから振る舞いを変更するほうが整頓せずに変更するよりも安価なこともある。そんな場合は常に先に整頓する)。

ビジネス的なメリットがあるならば整頓を後回しにすることが合理的になるのは十分にありえる。(e.g. 12/1までにリリースできれば大企業A社の受注に繋がるが、それを超過してしまうと競合他社と契約されてしまい、A社と契約できるチャンスが消滅してしまう)

逆に、先に整頓したほうが変更が楽になるならそうする。コードベースへの理解、ビジネスへの関心と理解（デッドラインは最終的なものなのか、調整可能なのか）、一定の設計スキルなどがあるとこの判断の練度を上げることに繋がりそう。

第26章オプション

「次にどのような振る舞いを実装できるか」は、実装する前から、それ自体に価値がある。

これはあまり考えたことがなかった。「プログラムの変更容易性は将来の実装工数を削減するために重要である」というアイディアと本質的には近いことを言ってそうだが、「価値」という切り口で捉え直すとたしかに変更容易性は価値と等価ともいえそう。

（これが最重要なのだが）価値予測の不確実性が高いほど、オプションの価値は高い（今すぐ実装するのと比べて）。

価値予測の不確実性と変更容易性の価値についてもあまり考えたことがなかったが納得感があった。たとえばよくあるSaaSモデルのプロダクトであれば探索しながら市場の反応を見たり変化に対応したりすることが必要で、そのためには変更容易性が必要なのでその価値がより高まる、ということだと理解した。

第32章凝集

凝集性が低いモジュールの改善方法についての章だが、どちらかというと章の後半に書かれていた下記の記述が参考になった。

次の人のために少しだけコードを整頓しておこう。全員がこのボーイスカウトルール(「来たときよりも美しく」)に従えば、そのうちにより扱いやすいコードになっていくだろう。

これまではボーイスカウトルールというと「触ったコードの負債をできるだけリファクタリングして綺麗にすべし」のような考え方だと認識していた（これ自体は間違いではないと思う）。

本格的なリファクタリングまではいかなくとも、本書で「整頓」として紹介されている「コードコメントの追加」や「空行の調整」なども十分ボーイスカウト的な行為なのだなと考え直して少しハードルが下がる感覚を得た。

第33章結論

本書のタイトルにもなっている、どんなときに先に整頓すべきかについてのまとめの章。

以下の4つの観点で整理して決断するとよい、と書かれている。次に判断に迷った際には参考にしてみたい。

コスト
収益
結合
凝集

まとめ

164ページと全体がコンパクトにまとまっているのと、簡潔に書かれている（かつ、翻訳もとても読みやすい）ので短時間で読みやすかった。

「整頓」 という概念を知れたのが最大の収穫だった。今後は意識的に実践していきたいと思う。

次回作の構想もあるようなので楽しみ。

『コンピュータシステムの理論と実装第2版』を読んだ

Tue, 29 Apr 2025 15:00:00 +0000

『コンピュータシステムの理論と実装第2版』を読んだので感想を書く。割と長いので得られた学びだけ読みたい方は## 学び、得た経験までジャンプしてください。

本書の構成

本書はnand2tetrisという通称の通り、NANDゲートからスタートして、CPUやコンパイラやOSなどを実装し、最終的にはそのプラットフォーム上でテトリス(のようなアプリケーション)¹が動くところまで実装するという内容のコースになっている。

lecture 7.pdf

https://drive.google.com/file/d/1BPmhMLu_4QTcte0I5bK4QBHI8SACnQSt/view

P3より引用

上図のとおりだが、大まかな流れとしては以下。

NANDゲートを使ってnot, and, orなどの基本的なチップを実装
加算機やALUを実装
レジスタ、RAM、Program Counterを実装
Memory、CPU、Computerを実装
アセンブラを実装(機械語の記号表現をバイナリ表現に変換する)
仮想マシンを実装
コンパイラを実装
OSを実装

各章末に課題とそれをパスしたことを確認するテストがある。基本的にはテストコードを使って動作確認ができるようになっているため、自分の実装が合ってるかを機械的に確認できるようになっており、手を動かしながら理解を深めやすいようになっている。

参考までに各章の実装に用いる言語を記しておく。

章	実装言語
第1章ブール論理	HDL(Hardware Description Languageの略で論理回路の構造を記述できる言語)
第2章ブール算術	HDL
第3章メモリ	HDL
第4章機械語	アセンブリ言語(Hackプラットフォーム独自の仕様)
第5章コンピュータアーキテクチャ	HDL
第6章アセンブラ	任意の言語
第7章仮想マシンI：処理	任意の言語
第8章仮想マシンII：制御	任意の言語
第9章高水準言語	Jack言語(本書で実装するJavaライクな独自言語)
第10章コンパイラI：構文解析	任意の言語
第11章コンパイラII：コード生成	任意の言語
第12章 OS	Jack言語

第6章 ~ 第8章と第10章 ~ 第11章は決められた入出力を持つCLIツールを書けばいいので任意の言語で書くことができる。筆者はRustで実装した。特にEnumとパターンマッチのおかげで構文解析関連の処理が書きやすかった。

ここからは各章の学びを簡単に書いていく。

第1章ブール論理

NANDを使って以下の論理回路をHDLを使って実装した。

not
and
or
xor
マルチプレクサ
デマルチプレクサ
not(16bit)
and(16bit)
or(16bit)
マルチプレクサ(16bit)
8入力or
4入力マルチプレクサ(16bit)
8入力マルチプレクサ(16bit)
4入力デマルチプレクサ
8入力デマルチプレクサ

マルチプレクサの実装に悩んだがいい感じの実装を思いついたときの爽快感がすごかった。

真理値表を丁寧めに書きながら進めた結果マルチプレクサの実装以外はそこまで悩まなかった。

第2章ブール算術

以下の論理回路を作成した。

半加算器
全加算器
16bit同士の加算
16bitの入力に1をインクリメントする回路
ALU(Arithmetic Logic Unit: 算術論理演算装置)

学び:

内部ピンにインデックスアクセスするには次のように書く必要がある。

Mux16(a=calculateResult, b=notCalculateResult, sel=no, out=out, out[0..7]=out0To7, out[8..15]=out8To15, out[15]=ng);

愚直な実装をしている箇所があったが、Mux16でスマートに書き直せることを知って感動した。

第3章メモリ

この章では、DFF(Data Flip-Flop)を用いて1-bit registerを作成し、それを組み合わせて16-bit registerを作成し、さらにそれを組み合わせてRAMを作成した。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P47より引用

読み書き可能なメモリを作成したことで、コンピュータを作っている感が強まってきた。

作成した回路は具体的には以下。

Register(1bit)
Register(16bit)
RAM(8bit)
RAM(64bit)
ProgramCounter
RAM(512bit)
RAM(4K-bit)
RAM(16K-bit)

学びメモ

第2章までは時間に依存しない回路のみを扱っていたがこの章では過去の状態を保持する回路を作成した。
ここでは時間をクロックという単位で区切って扱う。
非同期チップ(組み合わせチップ): 入力値の組み合わせのみに反応し時間の進行には影響を受けない
同期チップ(順序チップ): 以前の時間単位での変化に対応する用に設計されたチップ
同期チップを利用することでシステム内のチップ間で信号が伝播するのにかかる時間を無視できる。
ただしクロックサイクルは「システム内のチップ間で信号が伝播するのにかかる時間の最大値」と「1チップ内で最も処理時間がかかる演算を完了するのにかかる時間」の合計値よりも大きく設定する必要がある。

DFFはout(t+1) = in(t)で表される出力を持つ。DFFを用いることで過去の状態を論理回路上で表現できる。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P41より引用

次のようにマルチプレクサとDFFを組み合わせることで1-bit registerを作成できる。

CHIP Bit {
    IN in, load;
    OUT out;

    PARTS:
    Mux(a=dffOut, b=in, sel=load, out=mux);
    DFF(in=mux, out=out, out=dffOut);
}

1-bit registerは時刻tにおいてloadビットがアサートされるとout(t+1)がin(t)の値になり、アサートされていない場合はout(t+1)はout(t)の値になる。換言するとレジスタを利用することで過去の状態を保持できる。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P25より引用

第4章機械語

第4章では以下のプログラムを機械語で書いた。

掛け算を行うプログラム
キーボードが押されているときだけ画面を黒くするプログラム

機械語

ハードウェアプラットフォームが実行するように設計されている基本的な命令セット
高水準言語は表現力やプラットフォーム間の互換性を目標に設計される一方で機械語は特定のハードウェアで直接実行され、そのハードウェアを完全に制御できるように設計されている。
機械語は決められた形式に従いプロセッサとレジスタを用いてメモリを操作するように設計されている。
バイナリ形式、記号形式の2パターンで記述できる。

メモリ

データや命令を保存するハードウェアデバイス。各セルはメモリ位置やメモリレジスタと呼ばれ、それぞれ固有のアドレスを持つ。

プロセッサ

プロセッサは中央演算装置(CPU) と呼ばれ、あらかじめ決められた基本的な命令セットを実行できる。
プロセッサは選択されたレジスタとメモリ位置からデータを取り出し、選択されたレジスタとメモリ位置に出力を書き込む。
プロセッサはALUとレジスタ、バイナリ命令の解析と実行を可能にする論理ゲートによって構成される。

レジスタ

プロセッサとメモリはそれぞれ独立したチップとして実装されており一方から他方へデータを移すには比較的時間がかかる。そのためほとんどのプロセッサにはいくつかのレジスタが備わっており、高速なローカルメモリとして機能する。
CPUに存在するレジスタは2つのタイプに分類される。
- データを保持するデータレジスタ(Dレジスタ)
- アドレスを保持するアドレスレジスタ(Aレジスタ)

Hackコンピュータのアーキテクチャ

Hackコンピュータは以下のようなアーキテクチャを持つ。

lecture 4.pdf

https://drive.google.com/file/d/1HxjPmIZkFHl-BVW3qoz8eD9dqEuEyuBI/view

P23より引用

アセンブラの役割

機械語はバイナリ形式、記号形式の2パターンで記述できると書いたが、記号形式で@xのように変数を宣言した場合にその変数を実際のメモリのどこに置くかを知るのがアセンブラである。アセンブラのおかげで記号形式のプログラム側は実装詳細を意識することなく変数を初期化、利用できる。

命令タイプ

Hack言語には2つの命令タイプがある。

A命令
- A命令はAレジスタに15ビットの値を設定する。
- A命令は1ビットのオペコード + 15ビットの値で構成される。(Hack機械語ではA命令のオペコードは0)
- A命令は3つの目的で使用される。
  - プログラムによってコンピュータに定数を入力する
  - Aレジスタのアドレスを設定することでその次のC命令でRAMレジスタを操作できる
  - Aレジスタにジャンプ先のアドレスを設定することでその次のC命令でジャンプを実行できる
C命令
- C命令では次の3つを指定する。
  - どういう計算をするか(comp)
  - 計算された値をどこに保存するか(dest)
  - 次に何をするか(jump)
- Hack機械語では一番左端の1ビットが1
- C命令は次のような形式で構成される。111accccccdddjjj
  - 111: 先頭の1がオペコードで、左から2,3ビット目は使用されないが慣例として1が設定されている。
  - a: ALUへの入力がAレジスタからの値化Mからの値か決定する(1ビット)
  - c: compフィールド。(6ビット)ALUに対して計算内容を指定する。
  - d: destフィールド。(3ビット)計算結果の値をどこに保存するかを表現する。左から順にDレジスタ、Aレジスタ、RAM[A]に値を保存するかを表現する。

lecture 4.pdf

https://drive.google.com/file/d/1HxjPmIZkFHl-BVW3qoz8eD9dqEuEyuBI/view

P129より引用

外部デバイス

Hackのハードウェアプラットフォームでは画面とキーボードの2つの外部デバイスに接続できる。どちらのデバイスもメモリマップを通してコンピュータと会話する。(メモリの中に画面とキーボード用のメモリ領域があり、そこに画面の各ピクセルの値や押下されているキーのキーコードが格納される。)

Hackプログラムの例

以下は掛け算を行うHackプログラムのソースコード。(Hackアーキテクチャで動作する機械語で書かれている) ハードウェアの構成要素を理解しながら手続き型チックに記述する必要があるため難しかったが理解が進んだ。

// 0に対して(R0-1)回R1を足すことで掛け算を実現する

  // n = 0
  @n
  M=0

  // R2 = 0
  @R2
  M=0
(LOOP)
  // if n == R0 then goto END
  @n
  D=M
  @R0
  D=D-M
  @END
  D;JEQ

  // R2 += R1
  @R2
  D=M

  @R1
  D=D+M

  // R2 = D
  @R2
  M=D

  // n++
  @n
  M=M+1

  // go to LOOP
  @LOOP
  0;JMP
(END)
  @END
  0;JMP

第5章コンピュータアーキテクチャ

第5章では、これまでの章で作成した論理回路を組み合わせてついに1つの汎用コンピュータを作成する。このコンピュータは第4章に登場した機械語のプログラムを実行できる。

ノイマン型アーキテクチャ:
- CPUがメモリデバイスと相互作用する。
- 入力デバイスからデータを受け取り出力デバイスへデータを送信する。
- コンピュータのメモリに保存されるデータはコンピュータが計算したデータだけではなくコンピュータに何を行うべきかを指示する「命令」も含まれる。
メモリ:
- 物理的にはアドレス指定可能な固定サイズのレジスタの並びで、それぞれが固有のアドレスを持つ。
- 概念的にはアドレス空間はデータと命令の保存という2つの役割を果たす。
- ランダムに選択されたメモリレジスタに瞬時に到達できるという要件からRandom Access Memoryと呼ばれている。
  - たしかにRAMはレジスタの木構造になっていたのである程度大きいRAMでも少ないホップ数で指定したレジスタにアクセスできそうだ。
- データ専用のメモリ領域をデータメモリ、命令専用のメモリ領域を命令メモリと呼ぶ。
CPU:
- CPUは現在読み込まれているプログラムの命令を実行する。
- 各命令はCPUに対して以下を指示する。
  - どの計算を実行するか
  - どのレジスタにアクセスするか
  - 次のどの命令をフェッチして実行するか
- CPUはこれらのタスクをALU、レジスタ、制御ユニットを使って実行する。

第5章の課題ではこれまでの章で作成した論理回路を組み合わせて以下を作成した。

Memory
CPU
Computer

正直CPUの実装、デバッグがはかなり大変だったが公式が提供してくれているテストツールとデバッガのおかげで効率的にバグを見つけることができた。

こんな感じで各ピンの出力や期待する結果とのdiffを比較的見やすい形式で表示してくれるのでありがたかった。

ここで作成したCPUの回路は次のようなもの。ここではヒントとして大まかな回路設計が与えられておりそれを参考にしつつ足りない部分を埋めていく形で実装を進めた。

lecture 5.pdf

https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view

P31より引用

第6章アセンブラ

第6章では第5章で書いた機械語の記号表現をバイナリ表現に変換するアセンブラを開発する。

変数やラベルのアドレス管理を行うためにシンボルテーブルを利用する。シンボルテーブルには以下のような情報が格納される。
- ラベルの位置 e.g. (LOOP)
- 変数のアドレス e.g. @i(Hack機械語では変数は16以降のアドレスに順に割り当てられる)
- 定義済みシンボルのアドレス e.g. @SCREEN, @KBD

シンボル処理

アセンブリプログラムではシンボルが定義される前にシンボルラベルを使用できる。(goto命令の行き先を指定するのに利用する)

この挙動も考慮しつつバイナリを生成するには2パス・アセンブラと呼ばれる手法を用いる。

第1パス: シンボルテーブルを作成しすべてのラベルシンボルをテーブルに追加する。
第2パス: 変数シンボルを処理し、シンボルテーブルを使用してバイナリコードを生成する。

第6章からは好きな言語で実装できるのでRustで実装した。構文解析系はenumがある言語だと書きやすくて良い。

第7章仮想マシンI：処理

第7章ではVM変換器の一部を実装した。第8章で残りの部分を実装してVM変換器が完成する。ここまでの課題の中では一番大変で丸3日かかった。

HackプラットフォームのVMアーキテクチャとその利点

Hackプラットフォームにおいて、Hackプログラムは2段階コンパイルによって機械語に変換される。(更にその後アセンブラが機械語(記号表現)を機械語(バイナリ表現)に変換する)

    graph LR
    A[Jackコード
e.g. Foo.jack] -->|コンパイラが変換| B["VMコード(中間コード)
e.g. Foo.vm"]
    B -->|VM変換器が変換| C["機械語(記号表現)
e.g. Foo.asm"]
    C -->|アセンブラが変換| D["機械語(バイナリ表現)
e.g. Foo.hack"]

中間コードは仮想マシン(Virtual Machine; VM) と呼ばれる抽象化されたコンピュータ上で実行されるように設計されている。

高水準言語のプログラムを直接機械語に変換する方式だとハードウェアプラットフォームごとにコンパイラを作成する必要がある。この場合、コンパイラはソース言語(高水準言語)とターゲット言語(機械語)の両方に依存するためそれぞれの変更に追従する必要がある。

2段階でコンパイルする方式を採用するとコンパイラはソース言語の詳細に、VM変換器はターゲット言語の詳細にのみ依存するため変更への追従コストを下げることができる。 この方式ではコンパイラはハードウェアプラットフォームによらず利用することができ、ハードウェアごとにVM変換器さえ実装すればよい。そのためクロスプラットフォーム対応が比較的容易になるという利点がある。

VMフレームワークは上記の利点の代償として効率性が低下するという欠点がある。2段階の変換プロセスで生成するコードは直接コンパイルで生成するコードよりも冗長なことが多く、効率性が落ちる。

VM言語の設計

VM言語の設計にはバランスが重要で以下の要求を同時に満たす必要がある。

高水準側からの要求: 高水準言語のコードを表現できるだけの表現力と構造性を持たなければならない
低水準側からの要求: VMコードから生成される機械語がコンパクトで効率的になるようにVMコードは十分に低水準でなければならない

このような一見矛盾するような要件をスタックマシンが解決する。スタックマシンに基づく中間のVM言語を用いることで高水準言語の表現力と低水準言語の効率性という相反する要求を満たすことができる。

スタックマシンの挙動

スタックマシンの中心はスタックと呼ばれるLIFOのデータ構造にある。ここではいくつかの操作について説明する。(ここではスタックは下方向に成長するように記述する)

push操作の例

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]

pushを行うとスタックの先頭に値が追加される。スタックではSP(スタックポインタ) という値を使ってスタックの先頭位置を保持している。SPはpush操作を行う際に値を追加する領域を指し示している。スタックのメモリアドレスが0からスタートすると仮定すると今回の例ではアドレス0に値がpushされたときにSPの値が0から1になる。

アドレス	値
0	10
1

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]
    B -->|push 20| C[Stack:
10
20]

push操作を行うとスタックの先頭に値が追加される。このときSPの値は1から2になる。(補足:ここではSPは0-originとする)

pop操作の例

graph LR
    A[Stack:
42] -->|pop local 0| B["Stack: empty
local[0] = 42"]

pop segment_name indexと記述するとスタックの先頭の値を取り除き、指定したメモリセグメント、インデックスの位置に値を書き込む。

pop操作はスタックの先頭の値を取り除く。

算術演算(add)の例

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]
    B -->|push 20| C[Stack:
10
20]
    C -->|add| D[Stack:
30]

算術演算の例としてx+yを行うケースを考える。

この処理は次のような流れで行われる。

スタックからオペランドx, yをpopする
x+yを計算する
計算結果をスタックにpushする

graph LR
    A[Stack:
10
20] -->|pop y=20| B[Stack:
10]
    B -->|pop x=10| C[Stack: empty]
    C -->|push x+y=30| D[Stack:
30]

この方法を拡張することで一般的な算術演算をスタックマシンで評価できる。

第7章では、以下の演算子を実装した。

push
pop
算術演算子
- add
- sub
- neg
- eq
- gt
- lt
- and
- or
- not

仮想メモリセグメント

ここで実装するVMにはシンボル変数は存在しない。そのかわりに変数はstatic, local, argument, this, that, pointer, tempのような名前を持つ仮想セグメントの要素として表現される。たとえばコンパイラは高水準言語プログラムで見つかった最初のスタティック変数をstatic 0に、その次に見つかったスタティック変数をstatic 1に、というように変換する。

ここでのVM実装では以下のような仮想メモリセグメントを持つ。

名前場所使用法

SP RAM[0] スタックポインタ：スタック最上位の次のメモリアドレス

LCL RAM[1] localセグメントのベースアドレス

ARG RAM[2] argumentセグメントのベースアドレス

THIS RAM[3] thisセグメントのベースアドレス

THAT RAM[4] thatセグメントのベースアドレス

TEMP RAM[5-12] tempセグメントを保持

R13, R14, R15 RAM[13-15] VM変換器が生成するアセンブリコードに変数が必要な場合、これらのレジスタを使用可能

P175より引用

名前	場所	使用法
SP	RAM[0]	スタックポインタ：スタック最上位の次のメモリアドレス
LCL	RAM[1]	localセグメントのベースアドレス
ARG	RAM[2]	argumentセグメントのベースアドレス
THIS	RAM[3]	thisセグメントのベースアドレス
THAT	RAM[4]	thatセグメントのベースアドレス
TEMP	RAM[5-12]	tempセグメントを保持
R13, R14, R15	RAM[13-15]	VM変換器が生成するアセンブリコードに変数が必要な場合、これらのレジスタを使用可能

LCL, ARG, THIS, THATには各セグメントのベースアドレスが格納されている。たとえば次のように指定されていた場合、pop this 2はスタックの先頭の値をRAM[2202]に書き込む。

アドレス	値	備考
0	256	SP
1	2000	LCL
2	2100	ARG
3	2200	THIS
4	2300	THAT

VM変換器の動作例

例として実際の変換例を示す。

push constant 7
push constant 8
add

今回作成した実装では上記のvmコードは次のようなアセンブリコードに変換される。

// init
@256
D=A
@SP
M=D
// body
// push
@7
D=A
@SP
A=M
M=D
@SP
M=M+1
// push
@8
D=A
@SP
A=M
M=D
@SP
M=M+1
// add
@SP
A=M
A=A-1
A=A-1
D=M
@SP
A=M
A=A-1
D=D+M
@SP
A=M
A=A-1
A=A-1
M=0
@SP
A=M
A=A-1
M=0
@SP
M=M-1
M=M-1
@SP
A=M
M=D
@SP
M=M+1
// end
(END)
@END
0;JMP

VM変換器の実装はハードウェアの構造を意識しながらだいぶ手続き的なコードを書く必要があるので大変だった。(記述量も多いしミスるポイントも多い。)

現代のおいては低レイヤを隠蔽してくれる便利な仕組みがあるおかげでソフトウェアエンジニアが少ない記述量でアプリケーションを動かすことができていることを実感した。

ただ、隠蔽されているからこそ自主的に潜っていかないと構造の理解を深めるのが難しかったりするので引き続きやっていきたい。

第8章仮想マシンII：制御

第7章では

push

pop

算術演算子

add

sub

neg

eq

gt

lt

and

or

not

以下の演算子を実装したが、第8章では以下の演算子を実装し、VM変換器を完成させた。

label
goTo
ifGoTo
call
function
return

これを実装することで次の操作が可能になりよりプログラムっぽい処理を行えるようになる。

任意のラベル位置へのジャンプ
if分岐
関数の宣言と呼び出し

関数の呼び出し(`call`)

Hackプラットフォームにおいてはcall {function_name}コマンドを使って関数呼び出しを行う。

スタックを利用することで関数の呼び出しと戻り値の取得をシンプルに行うことができる。

ここではfunc_aからfunc_bを呼び出すシナリオを例に関数呼び出しをスタックで実現する際の操作を説明する。

(func_aからfunc_bを呼び出す)
func_aの以下の呼び出し側の情報をスタックにpush(これらの情報はフレームと呼ばれる)(画像の灰色の部分)
1. リターンアドレス(: func_bの呼び出しが完了してreturnする際に戻るアドレス)
2. func_aのLCLセグメントのベースアドレス
3. func_aのARGセグメントのベースアドレス
4. func_aのTHISセグメントのベースアドレス
5. func_aのTHATセグメントのベースアドレス
ARG, LCLセグメントの値を更新
func_bのコマンドが定義されているアドレスにジャンプ
リターンアドレスラベルをコードに挿入

lecture 8.pdf

https://drive.google.com/file/d/1BexrNmdqYhKPkqD_Y81qNAUeyfzl-ZtO/view

P58より引用

関数からのreturn(`return`)

呼び出された関数の終了はreturnコマンドで行う。このコマンドが呼ばれることで呼び出し側に処理が戻る。

ここではfunc_aからfunc_bを呼び出した際にfunc_bからfunc_aに戻るシナリオを例にスタックの操作を説明する。

frameのアドレスを一時変数に格納
リターンアドレスを一時変数に格納
ARGに返り値を格納
SPをARG+1に設定
THAT, THIS, ARG, LCLを復元
リターンアドレスにジャンプ

lecture 8.pdf

https://drive.google.com/file/d/1BexrNmdqYhKPkqD_Y81qNAUeyfzl-ZtO/view

P73より引用

第9章高水準言語

第10章、第11章でコンパイラを実装するJackの言語仕様を解説した章。

Javaに近い感じの文法。

class Main {
   function void main() {
      var Array a; 
      var int length;
      var int i, sum;

      let length = Keyboard.readInt("How many numbers? ");
      let a = Array.new(length); // constructs the array
     
      let i = 0;
      while (i < length) {
         let a[i] = Keyboard.readInt("Enter a number: ");
         let sum = sum + a[i];
         let i = i + 1;
      }

      do Output.printString("The average is ");
      do Output.printInt(sum / length);
      return;
   }
}

第10章コンパイラI：構文解析

第10章の内容に入る前にJackのソースコードが実行可能な形式になるまでの流れをおさらいしておく。

    graph LR
    A[Jackコード
e.g. Foo.jack] -->|コンパイラが変換| B["VMコード(中間コード)
e.g. Foo.vm"]
    B -->|VM変換器が変換| C["機械語(記号表現)
e.g. Foo.asm"]
    C -->|アセンブラが変換| D["機械語(バイナリ表現)
e.g. Foo.hack"]

Jackコンパイラは構文解析器とコード生成器からなり構文解析器はトークナイザとパーサ²からなる。

lecture 10.pdf

https://drive.google.com/file/d/1CM_w6cxQpYnYHcP-OhNkNU6oD5rMnjzv/view

P4より引用

トークナイザはソースコードをトークンと呼ばれる「プログラムにおいて意味を持つコードの最小単位」に変換する処理を担う。

トークンのような表現に変換してからパースを行うことでプログラムの複雑性を軽減することができる。

例として以下のJack言語のコードのトークン列をXMLで表記すると以下のようになる。

class Main {
    static boolean test;

    function void main() {
      do Output.printString("Hello world!");
      return;
    }
}

<class>
  <keyword> class </keyword>
  <identifier> Main </identifier>
  <symbol> { </symbol>
  <classVarDec>
    <keyword> static </keyword>
    <keyword> boolean </keyword>
    <identifier> test </identifier>
    <symbol> ; </symbol>
  </classVarDec>
  <subroutineDec>
    <keyword> function </keyword>
    <keyword> void </keyword>
    <identifier> main </identifier>
    <symbol> ( </symbol>
    <parameterList>
    </parameterList>
    <symbol> ) </symbol>
    <subroutineBody>
      <symbol> { </symbol>
      <statements>
        <doStatement>
          <keyword> do </keyword>
          <identifier> Output </identifier>
          <symbol> . </symbol>
          <identifier> printString </identifier>
          <symbol> ( </symbol>
          <expressionList>
            <expression>
              <term>
                <stringConstant> Hello world! </stringConstant>
              </term>
            </expression>
          </expressionList>
          <symbol> ) </symbol>
          <symbol> ; </symbol>
        </doStatement>
        <returnStatement>
          <keyword> return </keyword>
          <symbol> ; </symbol>
        </returnStatement>
      </statements>
      <symbol> } </symbol>
    </subroutineBody>
  </subroutineDec>
  <symbol> } </symbol>
</class>

パーサはトークン列を言語の構文ルールに照らし合わせその構造を構文上の要素に変換する処理を担う。

ここでは再帰下降構文解析というアルゴリズムを使って構文解析を行った。

ちなみに、Jack言語の構文は次のように定義されている。簡単な部類の言語とはいえ実装量はこれまでの課題と比べると多めだった。趣味でCコンパイラを書く人をたまにTwitterで見かけたりするがすごいなぁという気持ちになった。

第11章コンパイラII：コード生成

第11章では、コード生成器を実装する。具体的には構文解析した結果をもとにVMコードを生成する。

lecture 10.pdf

https://drive.google.com/file/d/1CM_w6cxQpYnYHcP-OhNkNU6oD5rMnjzv/view

P4より引用

一般的にはソースコードをVMコードに変換する層をフロントエンド、VMコードを機械語に変換する層をバックエンドと呼ぶらしい。本書では第10章と第11章の内容がフロントエンドに、第6章~第8章の内容がバックエンドに該当する、と言えそう。

シンボルテーブル

コンパイラがlet y = foo(x);のような文に遭遇するたびにx, yが何を表しているのかを知る必要がある。

Jackではクラススコープとサブルーチンスコープの2つのスコープがある。クラススコープの変数にはフィールド変数、スタティック変数の2種類があり、サブルーチンスコープの変数にはローカル変数、引数の2種類がある。

ここではこれらの変数の情報はシンボルテーブルと呼ばれるデータ構造に格納することで管理する手法が紹介されていた。シンボルテーブルは変数の名前、型、スコープ、種類、インデックスを保持する。

lecture 11.pdf

https://drive.google.com/file/d/1CYOcXKxfAwRHaOERvoyuNKSwdlxMo_e3/view

P6より引用

Jackではクラススコープとサブルーチンスコープの2つのスコープがあるのでそれぞれ別のシンボルテーブルを保持する必要がある。Jackでは内側のスコープが外側のスコープよりも優先されるため、コンパイラはxという変数に出会ったときにまずサブルーチンスコープのシンボルテーブルを検索し、見つからなければクラススコープのシンボルテーブルを検索する。

コンストラクタのコンパイル

特定のクラス型の変数を宣言する。e.g. var Point p
クラスのコンストラクタを呼び出して実際にインスタンス化する。 e.g. let p = Point.new(2, 3)
1. 新しいPointインスタンスを表現するために必要な2ワード分のメモリブロックをヒープ上に確保する
2. 確保された2ワードがコンストラクタの引数として与えられた2と3で初期化される
3. pに新しく確保したメモリブロックのベースアドレスを割り当てる

実装自体が難しいというケースは少なかったが、純粋にVM変換器の仕様を忘れて思い出すのに時間がかかったりしたので可能な方は時間を開けずにやると思い出しにかかるコストを減らせておすすめです。

第12章 OS

第12章では最小限のOSを実装した。

ここではOSは以下の役割を果たす。

ハードウェア操作の抽象化
Jack言語でよく使われる処理を関数/メソッドとして提供

それぞれ具体的には次のようなクラスによって実現されている。

ハードウェア操作の抽象化
- Outputクラス: printString, printlnなどのスクリーンへのテキストの書き込み処理を提供
- Screenクラス: drawLine, drawCircleなどのスクリーンへの図形の書き込みを処理を提供
- Keyboardクラス: keyPressed, readLineなどのキーボードからの入力の読み取り処理を提供
- Memoryクラス: alloc, deAlloc, peek, pokeなどのメモリアクセス処理を提供
- Sysクラス: プログラム実行に必要な処理の提供
Jack言語でよく使われる処理を関数/メソッドとして提供
- Mathクラス: abs, devideなどの基本的な算術演算を提供
- Stringクラス: 文字列データ型とlength, setCharAtなどの関連処理を提供
- Arrayクラス: 配列の初期化とメモリの解放を行う機能を提供

この章ではこれまでまったく意識したことがなかったメモリ操作によってハードウェアを制御するという経験が得られた。クラスインスタンスの初期化のためにメモリから任意の大きさの空き領域を探して確保する処理や、2点の座標が与えられたときにそれらを結ぶ直線をスクリーン上に描画する処理など。想像に難くない通り、基本的にかなり泥臭い実装が多かったがその泥臭さを吸収するための層でもあるので仕方ないとは思う。

その過程でメモリ操作やビットを扱う処理に少し慣れられたのは大きな収穫の1つだった。普段のWeb開発ではbit演算やメモリ操作をする機会はなかなかないので貴重な経験だった。

軽く調べた感じでは、現実世界では(Linuxでは)システムコールやデバイスドライバがそれらを担っているらしい。

実装に関しては整数型のオーバーフローが原因で数時間費やしてしまった。CS50でC言語で課題を解いていたときも同様のハマりがあったのであるあるかもしれない。普段書いている言語は簡単にオーバーフローしなかったり場合によっては静的解析で指摘してくれたりするのでなかなか気付くことができなかった。

学び、得た経験

普段はWebアプリケーションばかり触っているので、それよりも数段下のレイヤーの解像度を上げることができた。今後新しい知識の習得やトラブルシューティングがスムーズになるといいなと思う。
- あとは普段触っているソフトウェア、ハードウェアの仕組みを知ることができて純粋に楽しかった。
難しい概念に出会ったときに「順を追って理解を整理したり、労を惜しまずに手を動かしていけばきっと体得できるはず」という感覚を持てるようになった。
- 自分のコンピュータサイエンスの知識と経験が薄いのもあり、本書を通して未知の概念とのたくさんの出会いがあった。
- まったく知らない概念でも、順を追って理解を進めて手を動かすことで知識を自分のものにすることができた。その過程で未知の技術に対する恐れや及び腰になる感覚が減った。
- 余談だが、大学受験のときにセンター試験の数2Bで一見すると難しそうな問題が出ることが多いように感じていて「いけるいける難しくない落ち着いて考えればわかる」と何回も念じながら問題文を読んでいたのを思い出した。「難しそう」と考えるよりも「わかりそう」とか「なんかいけそう」みたいな方向性のマインドを持っていたほうがパフォーマンスも高くなるなーと改めて思うなどした。³
難しい課題も小さい部分に分割して段階的に進めるとうまくいくことを実感できた。
- 0からコンパイラを実装するのは気が引けるが、仕組みを理解していくつかの部品に分解して進めることで、複雑なソフトウェアを着実に構築する経験を得ることができた。
コンパイラやアセンブラの実装で泥臭い処理をたくさん書いたおかげで泥臭さへの耐性が多少ついた。そもそも複雑なものは実装も複雑になりうるのでそういうケースでは特に実装力が大事だなーと思うなどした。

おわりに

『Goならわかるシステムプログラミング』を読んでからかなり気になっていた本だったので無事完走できてよかった。

最近のテーマであるCS力の強化をまた一歩進めることができた。

次は『体験しながら学ぶネットワーク技術入門』でネットワークの理解を深めていこうかなと思う。

あとはソフトスキル系でいうと『エンジニアリングチームのリード術-―Googleに学ぶインディビジュアルコントリビューターとマネージャーのための実践ガイド』も良さそうなので読んでみようと思う。

実際はテトリスではなく別のブロック崩しのようなゲームではある ↩︎
Twitterを見ているとパーザと表記する流派も存在する模様 ↩︎
近い話が何かがそれほど得意でなくても、世の中の平均よりは得意だと思っておいたほうがよい - Lambdaカクテルで綺麗に言語化されている。 ↩︎

『Goならわかるシステムプログラミング第2版』を読んだ

Sun, 03 Nov 2024 12:42:30 +0000

『Goならわかるシステムプログラミング第2版』をサンプルコードを手元で実行しつつ一通り読んだ。(期間としては2024/6/8 ~ 2024/11/4でコミットした日数としてはおおよそ24日ほどだった。)

筆者は情報系の学部を出ておらず、CSなどの基礎知識があまりないので大変勉強になった。また、サンプルコードが豊富なので実際に自分のマシン上で動かしながら学ぶことができ解像度を上げながら理解を深めることができた。

低レイヤ、コンピューターサイエンスの学習に興味がある方にはとてもおすすめなのでぜひ買って読んでみてください。

Goならわかるシステムプログラミング第2版

Go言語による新時代のコンピュータシステム入門渋川よしき著 424ページ A5判 ISBN：978-4-908686-12-2 2022年3月23日第2版第1刷発行いつも開発に使っている言語やライブラリの裏側は、いったいどうなっ

https://www.lambdanote.com/products/go-2

手元で実行したコードは以下のリポジトリにまとめた。

GitHub - kyu08/go-system-programming: 『Goならわかるシステムプログラミング』の写経リポジトリ

『Goならわかるシステムプログラミング』の写経リポジトリ. Contribute to kyu08/go-system-programming development by creating an account on GitHub.

https://github.com/kyu08/go-system-programming

以下読書メモ。

第1章 Go言語で覗くシステムプログラミングの世界

デバッガを使ってfmt.Printlnの動作をシステムコールまで追った。¹
当然だがデバッガを使うと変数の中身に何が入ってるかがわかって便利。
デバッガを使ってみて別パッケージのprivate変数の中身を見ることができるのはプリントデバッグにはないデバッガの利点だと気づいた。

第2章低レベルアクセスへの入口1：io.Writer

io.WriterはOSが持つファイルのシステムコールの相似形
OSでは、システムコールをファイルディスクリプタと呼ばれるものに対して呼ぶ。
ファイルディスクリプタ(file descriptor)は一種の識別子（数値）で、この数値を指定してシステムコールを呼び出すと、数値に対応するモノへとアクセスできる。
ファイルディスクリプタはOSがカーネルのレイヤーで用意している抽象化の仕組み。
OSのカーネル内部のデータベースに、プロセスごとに実体が用意される。
OSはプロセスが起動されるとまず3つの擬似ファイルを作成し、それぞれにファイルディスクリプタを割り当てる。
- 0が標準入力、1が標準出力、2が標準エラー出力。
- 以降はそのプロセスでファイルをオープンしたりソケットをオープンしたりするたびに1ずつ大きな数値が割り当てられていく。

複数のファイルf1, f2をos.Create()する処理をデバッガーで追ってみたところ、それぞれファイルディスクリプタの値が3, 4²となっておりファイルディスクリプタの値が3からインクリメントされる様子を確認できた。

第3章低レベルアクセスへの入口1：io.Reader

エンディアン変換

リトルエンディアンでは、10000という数値(0x2710)をメモリに格納するとき下位バイトから順に格納する。
ビッグエンディアンでは、上位バイトから順に格納する。
現在主流のCPUではリトルエンディアンが採用されている。
ネットワーク上で転送されるデータの多くはビッグエンディアンが用いられている。
そのため多くの環境ではネットワークで受け取ったデータをリトルエンディアンに変換する必要がある。

`io`パッケージのいくつかの関数 / 構造体 / インターフェースの使い方

io.Pipe³
io.LimitReader: 先頭のnバイトだけ読み込む
io.MultiReader: 複数のio.Readerを1つのio.Readerにまとめる
io.SectionReader: offsetとnを指定して一部のデータだけ読み込む

第4章チャネル

普段goroutineを全然使わないので忘れていることが多かった。以下学んだことメモ。

バッファなしチャネルでは、受け取り側が受信しないと、送信側もブロックされる。⁴
for task := range tasks // tasksは任意のchのように書くと、チャネルに値が入るたびにループが回り、チャネルがクローズされるまでループが回る。

第5章システムコール

システムコールとは特権モードでOSの機能を呼ぶこと。

CPUの動作モード

OSの仕事は以下の2つ
- 各種資源（メモリ、CPU時間、ストレージなど）の管理
- 外部入出力機能の提供（ネットワーク、ファイル読み書き、プロセス間通信）
動作モード
- 実行してよいハードウェアとしての機能がソフトウェアの種類に応じて制限されている
- OSが動作する特権モード
- 一般的なアプリケーションが動作するユーザーモード

システムコールが必要な理由

通常のアプリケーションでメモリ割り当てやファイル入出力、インターネット通信などの機能を使うために必要なのがシステムコール
システムコールがなくてもCPUの命令そのものはほとんど使うことができる
しかし、ユーザーモードでは計算した結果を画面に出力したり、ファイルに保存したり外部のWebサービスに送信したりできない。

dtrussコマンドを使ってシステムコールの呼び出しを確認しようとしたがmacOSのセキュリティの設定上何も表示されなかったのでDocker上でLinuxを起動して確認してみることにした。

docker run -it --name stracetest golang:1.22.4-alpine3.19
apk add strace

go mod init kyu08/stracetest
# 任意のgoファイルを作成
go build ./...
strace -o strace.log ./実行ファイル
less strace.log

今回はf, _ := os.Create("test_file.txt")とdefer f.Close()を実行するだけのgoプログラムを実行したときのシステムコールのログを確認した。以下はその一部。

rt_sigaction(SIGRT_32, {sa_handler=0x70d90, sa_mask=~[], sa_flags=SA_ONSTACK|SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0
clone(child_stack=0x400001c000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 890
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=889, si_uid=0} ---
rt_sigreturn({mask=[]})                 = 1139696
rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0
clone(child_stack=0x4000062000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 891
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x4000080148, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x4000048948, FUTEX_WAKE_PRIVATE, 1) = 1
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
fcntl(0, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
futex(0x4000049148, FUTEX_WAKE_PRIVATE, 1) = 1
fcntl(1, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
fcntl(2, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
openat(AT_FDCWD, "test_file.txt", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3
futex(0x115ea0, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0x115db8, FUTEX_WAKE_PRIVATE, 1)  = 1
fcntl(3, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
pipe2([5, 6], O_NONBLOCK|O_CLOEXEC)     = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {events=EPOLLIN, data={u32=1549912, u64=1549912}}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 3, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data={u32=3997171713, u64=18446585726557487105}}) = -1 EPERM (Operation not permitted)
fcntl(3, F_GETFL)                       = 0x20802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE)   = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

openat(AT_FDCWD, "test_file.txt", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3の部分でファイルが作成され、ファイルディスクリプタに3が割り当ている
close(3) = 0の部分でdefer f.Close()に相当する処理が行われている

ということを確認できた。

第6章 TCPソケットとHTTPの実装

ソケットとは

ほとんどのOSではアプリケーション層からトランスポート層のプロトコルを利用するときのAPIとしてソケットという仕組みを利用している
HTTP/1.0と1.1はこのソケットのバイトストリーム上に作られたテキストを使ったプロトコル

ソケットの種類（本書で説明するもののみ）

TCP：一番使われている。安定性が高い。
UDP：通信開始が早い。相手に一方的に送りつける。
Unixドメインソケット：ローカル通信でしか使えないが最速。

ソケット通信の基本構造

どんなソケット通信も基本となる構成は次のような形態
- サーバー：ソケットを開いて待ち受ける
- クライアント：開いているソケットに接続し、通信する
GoではTCP通信が確立されると、送信側、受信側の両方に相手との通信するnet.Connインタフェースを満たすオブジェクトが渡ってくる

Goに組み込まれているTCPの機能（`net.Conn`）だけを使ってHTTPによる通信を実現する

net.Connだけを使ってTCPソケットの初期化や通信の確立などの普段ならnet/httpがやってくれている部分を実装した。
http.ListenAndServe()のコードを読んでみたら、golang/go/src/net/http/server.go#L3258で本書のハンズオンと同じようにTCPソケットの初期化を行っていることを確認できた。

素朴な実装の速度改善

①Keep-Aliveへの対応
- HTTP/1.1から入った規格
- HTTP/1.0ではセットの通信が終わるたびにTCPコネクションが切れる仕様になっていたが、Keep-Aliveを使うことで、しばらくの間はTCP接続のコネクションを維持して使い回すことができる。
- TCP接続の通信には一定のオーバーヘッドがあるが、Keep-Aliveを使うことでそのオーバーヘッドを削減できる。
②レスポンスの圧縮
- レスポンスを圧縮することで、通信量を削減でき速度向上につながる。
- レスポンスヘッダーは圧縮されないため、少量のデータを通信する場合は効率が悪くなる。そのため実際のデータ量に応じて圧縮するかどうかを判断する必要がありそう。
③チャンク形式のボディー送信
- 動画など大きいデータを送信する場合、データを分割して送信することでデータの送信が完了する前に受信側でデータを処理できるようになる。また、すべてのデータをメモリに展開する必要もなくなるのでメモリの使用量を抑えることができるというメリットもある。
- チャンク形式ではヘッダーに送信データのサイズを書かないかわりにTransfer-Encoding: chunkedというヘッダーを付与する。
④パイプライニング
- 送受信を非同期化する方法

第7章 UDPソケットを使ったマルチキャスト通信

UDPとTCPの用途の違い

UDPはTCPと同じトランスポート層のプロトコルで以下のような特徴がある。

誰と繋がっているか管理しない
データロスの検知をすることも通信速度の制限をすることもしない
パケットの到着順序も管理しない
複数のコンピュータに同時にメッセージを送ることが可能な「マルチキャスト」と「ブロードキャスト」をサポートしている。（TCPにはない機能）
UDPの利用例としてはDNSやNTP, WebRTCなどがある。

UDPのマルチキャストの実装例

マルチキャストはリクエスト側の負担を増やすことなく多くのクライアントに同時にデータを送信できる仕組み。

UDPとTCPの機能面の違い

TCPには再送処理とフロー処理がある。

再送処理

TCPでは送信するメッセージにシーケンス番号が入っているので、受信側ではこの数値をみることでパケットの順序を管理できる。
受信側はメッセージを受け取ると、受信したデータのシーケンス番号とペイロードサイズの合計を確認応答番号として返信する。
送信側はこの応答確認番号が受け取れなかった場合に再送処理を行う。

フロー処理

受信側がリソースを用意できていない状態で送信リクエストが集中して通信内容が失われるのを防ぐための仕組みをウィンドウ制御という。
- 具体的には、受信用のバッファ（ウィンドウ）をあらかじめ決めておき送信側ではそのサイズまでは受信側からの受信確認を待たずにデータを送信できる。
受信側のデータの読み込みが間に合わない場合には、受信できるウィンドウサイズを受信側から送信側に伝えて通信量を制御できる。これをフロー制御という。

フレームサイズ

UDPレイヤーで取り扱えるデータは約64キロバイトまで。
UDPではデータの分割などはアプリケーションで面倒を見る必要がある。

輻輳制御とフェアネス

輻輳制御とは、ネットワークの輻輳（渋滞）を避けるように流量を調整し、そのネットワークの最大効率で通信できるようにするとともに複数の通信をお互いにフェアに行うための仕組み。
TCPには輻輳制御が備わっており、そのアルゴリズムにはさまざまな種類がある。
UDPにはTCPのような輻輳制御の仕組みはなく、流量の制御はUDPを利用する各プログラムに委ねられている。そのため、UDPとTCPを利用するアプリケーションがそれぞれあって、UDPを利用するアプリケーションでフェアネスが考慮されていない場合には、両方の通信が重なった時に遠慮する機能が組み込まれたTCPの通信速度だけが極端に落ち込むこともある。

第8章高速なUnixドメインソケット

UnixドメインソケットはPOSIX系OSで提供されている機能で、コンピュータ内部でしか使えない代わりに高速な通信が可能。
Unixドメインソケットには、TCP型（ストリーム型）とUDP型（データグラム型）の両方の使い方ができる。

Unixドメインソケットの基本

TCPとUDPによるソケット通信が外部のネットワークにつながるインターフェースに接続するのに対し、Unixドメインソケットはカーネル内部で完結する高速なネットワークインターフェースを作成する。
Unixドメインソケットを使うことで、ウェブサーバーとNGINXなどのリバースプロキシとの間、あるいはウェブサーバーとデーターベースとの間の接続を高速にできる場合がある。
Unixドメインソケットを開くには、ファイルシステムのパスを指定する。サーバープロセスを起動するとファイルシステム上の指定したパスにソケットファイルが作成される。
Unixドメインソケットで作成されるのはソケットファイルと呼ばれる特殊なファイルであり、通常のファイルのような実体を持たない。あくまでもプロセス間の高速な通信としてファイルというインターフェースを利用するだけ。

以下はソケットファイルが作成されている様子。ソケットファイルは先頭が"s"で始まる。

UnixドメインソケットとTCPのベンチマーク

Unixドメインソケットを使った実装とTCPを経由した実装のベンチマークの比較をすると筆者の環境だとUnixドメインソケットの方が10倍ほど高速だった。

$ go test -bench . -benchmem
goos: darwin
goarch: arm64
pkg: github.com/kyu08/go-system-programming/bench
BenchmarkTCPServer-8                4165            327038 ns/op           52175 B/op        110 allocs/op
BenchmarkUDSStreamServer-8         42742             27837 ns/op           16762 B/op         59 allocs/op
PASS
ok      github.com/kyu08/go-system-programming/bench    4.788s

第9章ファイルシステムの基礎とGo言語の標準パッケージ

この章ではosパッケージとpath/filepathパッケージの主要な関数の使い方が紹介されていた。

ファイル/ディレクトリを扱うGo言語の関数たち

2つのファイルの同一性の判定: os.Samefile()
ファイルのパーミッション、オーナー、タイムスタンプの変更: os.Chmod(), os.Chown, os.Chtimes()
ハードリンク、シンボリックリンクの作成: os.Link, os.Symlink()
ファイル一覧の取得: dir, _ := os.Open(path) -> dir.Readdir()

OS内部におけるファイル操作の高速化

CPUにとってディスクの読み書きはとても遅い処理であり、なるべく最後までやらないようにしたい。LinuxではVFSの内部に設けられているバッファを利用することでディスクに対する操作をなるべく回避している。

`path/filepath`パッケージの関数たち

パスの最後の要素を返す: filepath.Base()
パスのディレクトリ部分を返す: filepath.Dir()
パスをディレクトリとパス名に分割する: filepath.Split()
ファイルの拡張子を返す: filepath.Ext()
/some/../pathやanother//pathのような形式のパスを整える: filepath.Clean()
パターンにマッチするファイルの判定: filepath.Match()
ディレクトリのトラバース: filepath.Walk()

想像よりも標準パッケージでいろんなことができるのでこの辺りの操作をしたくなったら自作関数を書く前に標準パッケージを探してみるのが良さそうだと思った。

第10章ファイルシステムの最深部を扱うGo言語の関数

ファイルの変更監視（`syscall.Inotify`）

プログラムでファイルを監視する方法には次の2種類がある。

監視したいファイルをOS側に通知しておいて、変更があったら教えてもらう（パッシブな）方式
タイマーなどで定期的にフォルダを走査し、os.Stat()などを使って変更を探しに行く（アクティブな）方式

アクティブな方式の方がコード量は少ないが監視対象が増えるとCPU負荷やIO負荷が増える。

パッシブな方式はファイルの変更検知が各OSでシステムコールやAPUIとして提供されている一方で環境ごとのコード差は大きくなる。

ここでは fsnotify/fsnotify.v1を用いてファイルの変更検知プログラムを作成した。

fsnotify.v1では、Linuxの場合はinotify系APIが、BSD系OSの場合はkqueueが使われている。

ファイルのメモリへのマッピング（`syscall.Mmap()`）

syscall.Mmap()を使うことでファイルの中身をそのままメモリ上に展開したり、メモリ上で書き換えた内容をそのままファイルに書き込むことができる。

edsrzf/mmap-goではmmap.Map()を使うことでファイルをメモリに展開できる。mmap.Map()は次のようなシグネチャを持つ。

func Map(f *os.File, prot, flags int) (MMap, error)

2つ目の引数に次のような値を指定することでメモリ領域に対して許可する操作を設定できる。

mmap.RDONLY: 読み込み専用
mmap.RDWR: 読み書き可能
mmap.EXEC: 実行可能にする
mmap.COPY: コピーオンライト

コピーオンライトが指定されると、複数のプロセスが同じファイルをマッピングしているときに、カーネル上は1つ分のみメモリ領域が使用され、それ以上のメモリを消費しない。

しかし、その領域内でメモリ書き換えが発生すると、その領域がまるごとコピーされる。このようにすることでメモリ消費量をうまく節約できる。

同期・非同期 / ブロッキング・ノンブロッキング

同期処理: OSにI/Oタスクを投げて、入出力の準備ができたらアプリケーションに処理が返ってくる
非同期処理: OSにI/Oタスクを投げて、入出力の準備ができたら通知をもらう
ブロッキング処理: お願いしたI/Oタスクの結果の準備ができるまで待つ（自分は停止）
ノンブロッキング処理: お願いしたI/Oタスクの結果の準備ができるのを待たない（自分は停止しない）

select属のシステムコールによるI/O多重化

非同期・ブロッキングは1スレッドでたくさんの入出力を効率よく扱うための手法でありI/O多重化とも呼ばれる。それを効率よく実現するAPIのことを本書ではselect属と総称する。

並行処理を使うことで小さい規模のI/Oの効率化は十分に行えるが、select属はC10K問題と呼ばれる、万の単位の入出力を効率よく扱うための手法として有効。

第11章コマンドシェル101

シェルとは、ユーザーがコンピューターを操作するために使う接点となるシステムにおいてコンピューターシステムの殻（shell）となるプログラムのこと。

シェルがないシステム

Distrolessと呼ばれるコンテナイメージはシェルがないため、セキュリティホールをついてシステムに侵入されることがない。⁵（当然攻撃の脅威がゼロになるわけではない）

シェルがコマンドを起動するまで

シェルがコマンドを起動するまでには次のようなことを行っている。

ユーザーの入力を受け付ける
入力されたテキストの分解
コマンドと引数の前処理
実行ファイルの探索
ワイルドカードの展開
プロセスの起動

「11.5.3コマンドと引数の前処理」で紹介されていたが、$(which nvim)と同様に`which nvim`でもコマンドの実行結果を変数に代入できるのは知らなかった。

第12章プロセスの役割とGo言語による操作

OSが実行ファイルを読み込んで実行するには、そのためのリソース（CPU、メモリ）を用意する必要がある。そのようなリソースをまとめたプログラムの実行単位のことをプロセスと呼ぶ。プロセスはOSが実行ファイルを読み込んで実行するときに新しく作られる。
プロセスにはプロセスごとにユニークな識別子がある。（プロセスID）。Go言語ではos.Getpid()で取得できる。

プロセスの入出力

すべてのプロセスは少なくとも次の3つの入出力データを持っている。

入力：コマンドライン引数
入力：環境変数
出力：終了コード

OSから見たプロセス

OSの仕事はたくさんあるプロセスに効率よく仕事をさせること
Linuxではプロセスごとにtask_struct型のプロセスディスクリプタと呼ばれる構造体を持っている。
- 基本的にはプロセスから見た各種情報と同じ内容だが、そこには含まれていない要素もいくつか存在する。
- 例えば、どこからどこまでが自分のメモリ領域かというメモリブロックの情報やスタック領域がどこにありプログラムが静的に確保するデータや動的に確保するデータがどのようにレイアウトされるかもOSが持つプロセスの情報の中にある。

プロセスの出力に色づけをする

プロセスの出力に色をつけたい場合にはANSIエスケープシーケンスを使うことができる。

自分が利用したことある⁶Rustのcoloredクレートも確認したところ実際にANSIエスケープシーケンスを使ってターミナルに色をつけていた。

    #[cfg_attr(feature = "no-color", ignore)]
    #[test]
    fn compute_style_simple_fg_blue() {
        let blue = "\x1B[34m";

        assert_eq!(blue, "".blue().compute_style());
    }

colored/src/lib.rs at 775ec9f19f099a987a604b85dc72ca83784f4e38 · colored-rs/colored

(Rust) Coloring terminal so simple you already know how to do it ! - colored-rs/colored

https://github.com/colored-rs/colored/blob/775ec9f19f099a987a604b85dc72ca83784f4e38/src/lib.rs#L805-L811

より

調べてみたところ\x1Bでも\eでもエスケープシーケンスを表現できるらしい。⁷

外部プロセスに対して自分が擬似端末だと詐称する

ライブラリによっては、自分が繋がっている先が擬似端末かどうかでエスケープシーケンスを出力するかどうかを決定している。

子プロセスの出力を色づけするためには、親を擬似端末だと詐称することでエスケープシーケンスを出力させることができる。

デーモン化

普通のプログラムはシェルのプロセスの子になってしまうので、ログアウトしたりシェルを閉じたりするだけで終了してしまう。

そのような場合でも終了しないように下記のような特別な細工が施されたプロセスがデーモンである。

セッションID、グループIDを新しいものにして既存のセッションとグループから独立
カレントのディレクトリはルートに移動
フォークしてからブートプロセスのinitを親に設定し、実際の親はすぐに終了
標準入出力も起動時のものから切り離される(通常はdev/nullに設定される)

第13章シグナルによるプロセス間の通信

シグナルには主に2つの用途がある。

プロセス間通信: カーネルが仲介してあるプロセスから別のプロセスへとシグナルを送るケース。自分自身にシグナルを送ることもできる。
ソフトウェア割り込み: システムで発生したイベントがシグナルとしてプロセスに送られる。シグナルを受け取ったプロセスは現在置くなっているタスクを中断してあらかじめ登録しておいた処理を実行する。

システムコールはユーザー空間で動作しているプロセスからカーネル空間にはたらきかけるためのインターフェースだが、その逆方向がシグナルだと考えることができる。

システムコールでは最大7つほどの引数を指定できるのに対し、ソフトウェア割り込みとしてのシグナルで送信できるのはその種類のみ。
プロセスは受け取ったシグナルを無視するか補足して処理する。

シグナルのハンドラを書く

Goでは次のようにsignal.NotifyContext()を使ってシグナルを受け取ることができる。

package main

import (
	"context"
	"fmt"
	"os/signal"
	"syscall"
	"time"
)

func main() {
	ctx := context.Background()
	sigctx, cancel := signal.NotifyContext(ctx, syscall.SIGINT, syscall.SIGTERM)
	defer cancel()
	toctx, cancel2 := context.WithTimeout(ctx, time.Second*5)
	defer cancel2()

	select {
	case <-sigctx.Done():
		fmt.Println("signal")
	case <-toctx.Done():
		fmt.Println("timeout")
	}
}

KubernetesやDockerでは外からタスクを終了させるとき、まずSIGTERMをアプリケーションに対して送信する。(SIGTERM: kill()システムコールやkillコマンドがデフォルトで送信するシグナル。プロセスを終了させるもの)

(GoアプリケーションのGraceful Shutdownの実装例でSIGTERMをハンドリングするのをよく見るのはだからか、と納得した。)

第14章 Go言語と並列処理

並行処理と並列処理の違い

並行処理: 1つのコアで複数のタスクを素早く切り替えながら処理すること
並列処理: 複数のコアを使って複数のタスクを同時に処理すること

チャネル

Go言語で簡単に並列処理を書くための道具としてgoroutineとチャネルがある。
チャネルを使うことでデータの入出力を直列化できる。

スレッドとgoroutineの違い

スレッドとはプログラムを実行するためのものであり、OSによって手配される。
プログラムからみたスレッドは「時間が凍結されたプログラムの実行状態」で、CPUが演算に使ったり計算結果や状態を保持したりするレジスタと呼ばれるメモリとスタックメモリが含まれる。
OSは凍結状態のプログラムの実行状態を復元して各スレッドに短時間ずつ処理をさせる。実行予定のスレッドはランキューと呼ばれるリストに入っている。
スレッドがCPUコアに対してマッピングされるのに対し、gouroutineはOSのスレッドにマッピングされる点が通常のスレッドとgoroutineとの最大の違い。
- goroutineはOSスレッドの1~2MBと比べると初期スタックメモリのサイズが小さい(2KB)ため起動処理が軽い。
- また、gouroutineはOSに処理を渡さずに作成できるのでカーネルとのタスク切り替えのコストも小さい。

goroutineのメリット

大量のクライアントからのリクエストを効率よく捌きたいとき（いわゆるC10K）に、クライアントごとに1つのgoroutineを割り当てたとしても少ないメモリ消費量で処理できる（前述の通りgoroutineは起動時の初期スタックメモリのサイズが小さいため）

第15章並行・並列処理の手法と設計のパターン

代表的な並行・並列処理の手法

マルチプロセス
イベント駆動
マルチスレッド
ストリーミング・プロセッシング

イベント駆動

主に並列化ではなく並行処理のために使われる。
I/Oバウンドなプログラムで用いられる。
OSに依頼したデータ受信の仕事が終わるたびにコールバックが返ってくる仕組み。
単体ではCPUを使いこなしにくい点が欠点。

マルチスレッド

同じメモリ空間内で多くのCPUが同時に実行するための仕組み
- Linuxではプロセスもスレッドもカーネル上は同じ構造体として表現されている。親のプロセスとメモリ空間を共有していなければプロセス、共有していればスレッド。
利点はCPUのパフォーマンスを引き出すことができる点。
欠点はプロセスほどではないが、OSのスレッドの場合は比較的大きなスタックメモリ（1~2MB）を必要とし、起動時間もややかかる。そのためスレッドプールを作っておき、必要になったらすぐ使えるようにする、ということが行なわれている。

Goにおける並行・並列処理のパターン集

アムダールの法則: 並列化を導入するとどれだけ効率が改善するかを表す数式

S(N) = 1 / ((1 - P) + P/N)

ここでPは並列化できる仕事の割合、Nは並列数である。

P = 0.5, N = ∞のとき、S(N) = 2倍になり、P = 0.9, N = ∞のとき、S(N) = 10倍になる。このことからもわかるように、並列数よりも並列化できるタスクの割合が支配的になる。

Pを改善するためのアイディアとして次のような手法が考えられる。

同期処理を非同期にする
非同期にしたものを同期化する
タスク生成と処理を分ける（Producer-Consumerパターン）
開始した順で処理する（チャネルのチャネル）
タスク処理が詰まったら待機（バックプレッシャー）
並列なForループ
決まった数のgoroutineでタスクを消化する（ワーカープール）
依存関係のあるタスクを表現する（Future/Promise）
イベントの流れを定義する（ReactiveX）
自立した複数のシステムで協調動作（アクターモデル）

同期 -> 非同期化

I/O処理などの重いタスクを非同期化する

非同期 -> 同期化

非同期化したタスクはどこかで同期化する必要がある。そのための一番簡単な手法がチャネル。

タスク生成と処理を分ける（Producer-Consumerパターン）

GoではチャネルでProducerとConsumerを接続することで簡単に実現できる。

開始した順で処理する（チャネルのチャネル）

チャネルを用いると複数の処理を終了した順に取り出すことができる。

// 終了した順に書き出し
// チャネルに結果が投入された順に処理される
func writeToConn(responses chan *http.Response, conn net.Conn) {
	defer conn.Close()
	// 順番に取り出す
	for response := range responses {
		response.Write(conn)
	}
}

チャネルのチャネルを使うと処理を開始した順で処理をできる。

// 開始した順に書き出し
// チャネルにチャネルを入れた(開始した)順に処理される
func writeToConn(sessionResponses chan chan *http.Response, conn net.Conn) {
	defer conn.Close()
	// 順番に取り出す
	for sessionResponse := range sessionResponses {
		// 選択された仕事が終わるまで待つ
        response := <-sessionResponse response.Write(conn)
	}
}

タスク処理が詰まったら待機（バックプレッシャー）

以下のようなバッファ付きチャネルを使うことで実現できる。

tasks := make(chan string, 10)

並列Forループ

forループ内の処理をgoroutineで実行することでループ処理を並列化できる。
ループ内部の処理が小さすぎるとオーバーヘッドのほうが大きくなり効率が上がらないことがあるので注意が必要。

決まった数のgoroutineでタスクを消化する（ワーカープール）

特にCPUバウンドな処理ではCPUのコア数以上にgoroutineを作ってもスループットは上がらないため、CPUコア数分のワーカーを作成してタスクを消化するのが効果的な場合がある。

依存関係のあるタスクを表現する（Future/Promise）

Futureをチャネルで表現すると、必要なデータが揃ったらタスクを逐次実行できる。

後続の処理に結果を引き継ぎたいが、処理自体は可能な限り非同期で実行したい場合に有効そう。

func readFile(path string) chan string {
	// ファイルを読み込み、その結果を返すFutureを返す
	promise := make(chan string)
	go func() {
		content, err := os.ReadFile(path)
		if err != nil {
			fmt.Printf("read error %s\n", err.Error())
			close(promise)
		} else {
			// 約束を果たした
			promise <- string(content)
		}
	}()
	return promise
}

func printFunc(futureSource chan string) chan []string { 
    // 文字列中の関数一覧を返すFutureを返す
	promise := make(chan []string)
	go func() {
		var result []string
		// futureが解決するまで待って実行
		for _, line := range strings.Split(<-futureSource, "\n") {
			if strings.HasPrefix(line, "func ") {
				result = append(result, line)
			}
		}
		// 約束を果たした
		promise <- result
	}()
	return promise
}

func main() {
	futureSource := readFile("main.go")
	futureFuncs := printFunc(futureSource)
	fmt.Println(strings.Join(<-futureFuncs, "\n"))
}

また、次のような構造体を定義することで上記のFutureの値を複数回読み取ることができる。（上記の実装ではバッファなしチャネルを使っているので複数回受信してしまうと処理がブロックされてしまう）

type StringFuture struct {
	receiver chan string
	cache    string
}

func NewStringFuture() (*StringFuture, chan string) {
	f := &StringFuture{
		receiver: make(chan string),
	}
	return f, f.receiver
}

func (f *StringFuture) Get() string {
	r, ok := <-f.receiver
	if ok {
		close(f.receiver)
		f.cache = r
	}
	return f.cache
}

func (f *StringFuture) Close() {
	close(f.receiver)
}

イベントの流れを定義する：ReactiveX

ここではRxGoを使ってイベントの流れを定義する方法が紹介されていた。まずこのようにwatcherを定義する。

watcher := observer.Observer{
    NextHandler: func(item any) {
        line := item.(string)
        if strings.HasPrefix(line, "func ") {
            fmt.Println(line)
        }
    },
    ErrHandler: func(err error) {
        fmt.Printf("Encountered error: %v\n", err)
    },
    DoneHandler: func() {
        fmt.Println("Done!")
    },
}

以下のようにするとNextHandlerに登録された関数にlineが渡される。

emitter <- line

そして次のようにするとErrHandlerに登録された関数が呼ばれる。

emitter <- err

渡ってきた値に応じて処理を分岐させたく、かつ何度も同一のイベントが発生するケースではこの方法を使うと良さそう。

自律した複数のシステムで協調動作：アクターモデル

アクターと呼ばれる自律した多数のコンピューターが協調して動作するというモデル。
各アクターは別のアクターから送られてくるメッセージを受け取るメッセージボックスを持つ。

第16章 Go言語のメモリ管理

仮想メモリ

現代のOSではプロセスはメモリを読み書きするのに物理的なアドレスを直接扱うのではなく、プロセスごとに仮想的なメモリアドレス空間があり、それを使ってメモリにアクセスしている。この仮想的なメモリアドレス空間のことを仮想メモリという。

仮想メモリのアドレスから実際の物理メモリにアクセスするためにページテーブルというデータ構造が使われる。ページとはメモリを管理する単位のこと。

仮想メモリのおかげで実際の保存領域が飛び飛びになっていたとしてもプロセスからはフラットなメモリ領域が確保されているように見える。

仮想メモリは物理メモリのアドレスと1対1対応しているわけではなく、物理メモリのあるアドレスが複数の仮想メモリから参照されることもある。こうすることで共有ライブラリなどを複数のプロセスで利用でき省メモリになる。

OSカーネルがプロセスのメモリを確保するまで

プロセスは起動時にOSからメモリをもらう。OSはプロセスごとに仮想メモリの領域を確保する。

ユーザーのメモリ空間は大きく3つの連続したメモリ領域に分かれる。3つの領域の間の空きスペース分はメモリの確保が行われない。

| ①プログラム + 静的データ | ヒープとして使われる領域 | ②共有ライブラリ |      | ③スタックなど |
小さいアドレス                                                                大きいアドレス ->

スタック

関数を呼ぶとリターンアドレスや新しい関数のための作業メモリ領域としてスタックフレームと呼ばれるメモリ領域が確保される。

スタックフレームはスレッドごとにあらかじめ確保されているメモリブロックに対して順番に追加したり削除されたりされるだけなので割当のコストはほぼゼロ。

Go言語でのスタックとヒープの使い分け

Go言語では変数のデータをヒープに置くかスタックに置くかはコンパイラが自動的に判断する。以下はその一部。

newで初期化してもその関数内でしか利用されなければスタックに確保される。
ローカル変数として宣言してもそのポインタを他の関数に渡したり、関数の返り値として返すような場合にはヒープに確保される。

Go言語でメモリがスタックとヒープのどちらに確保されるかを知りたい場合にはビルド時に-gcflags -mを渡すことで確認できる。

ということで次のコードを使って上記の挙動を確認してみる。

package main

import "fmt"

func main() {
	strValue := "Hello, World!" // スタックに確保される(関数内でしか利用されていないため)
	_ = strValue + ""

	strPtr := new(string) // スタックに確保される(関数内でしか利用されていないため)
	_ = *strPtr + ""

	strPtr2 := new(string) // ヒープに確保される(他の関数に渡されているため)
	receiveStrPtr(strPtr2)

	strPtrFromFunc := returnStrPtr() // スタックに確保される(関数内でしか利用されていないため)
	_ = *strPtrFromFunc + ""
}

func receiveStrPtr(argStrPtr *string) {
	fmt.Printf("argStrPtr: %v\n", argStrPtr)
}

func returnStrPtr() *string {
	str := "Hello, World!" // ヒープに確保される(関数の返り値として返されているため)
	return &str
}

-gcflags -mをつけてビルドしてみると次のようになりコードコメント通り、strPtr2とstrがヒープに確保されていることがわかった。

$ go build -gcflags -m main.go
# command-line-arguments
./main.go:19:6: can inline receiveStrPtr
./main.go:23:6: can inline returnStrPtr
./main.go:13:15: inlining call to receiveStrPtr
./main.go:15:32: inlining call to returnStrPtr
./main.go:13:15: inlining call to fmt.Printf
./main.go:20:12: inlining call to fmt.Printf
./main.go:7:15: strValue + "" does not escape
./main.go:9:15: new(string) does not escape
./main.go:10:14: *strPtr + "" does not escape
./main.go:12:16: new(string) escapes to heap
./main.go:13:15: ... argument does not escape
./main.go:16:22: *strPtrFromFunc + "" does not escape
./main.go:19:20: leaking param: argStrPtr
./main.go:20:12: ... argument does not escape
./main.go:24:2: moved to heap: str

ガベージコレクタ

Goをはじめとして多くの言語ではマークアンドスイープという方式が採用されている。

マークアンドスイープ方式では、まずメモリの領域をスキャンして必要なデータか否かをマークしていき、次のフェーズで不要なものを削除する。

マークアンドスイープ方式では、不要なメモリを削除する間にプログラム全体を停止する必要がある。（これをストップザワールドと呼ぶ）

Goではバージョンを重ねる事にストップザワールドの時間の短縮化が進んでいる。

第17章実行ファイルが起動するまで

最終的にCPUで実行されるバイナリはメモリ空間に単に命令が並んだもので、そこにはブロックのような概念は存在しない（Goでいうと{と}で囲まれた処理の塊）。

アセンブリ言語には関数のブロックのような概念はないが、その代わりにラベルという概念がある。

ランタイムの役割

Goに限らずC言語でもRustでも何かしらのプログラミング言語で生成したアプリケーションは「ランタイム」と呼ばれるライブラリを利用したプログラムになるのが一般的。

ラインタイムライブラリが最終的にはOSのカーネルにシステムコールを発行して仕事を依頼し、メモリ管理やファイルやネットワークアクセスを実現する役割を担う。

ラインタイムライブラリがなければ、OSに仕事を依頼するところも自分で作成する必要がある。

リンカーの役割

以下はWikipediaによるリンカーの説明。

a computer program that takes one or more object files generated by a compiler or generated by an assembler and links them with libraries, generating an executable program or shared library

Linker - Wikipedia から引用

上記を翻訳すると「コンパイラまたはアセンブラによって生成された1つ以上のオブジェクトファイルをライブラリと結合し実行可能ファイルまたは共有ライブラリを生成するプログラム」といった感じだろうか。

OSはリンカーが生成した実行ファイルがシェルから起動されると、実行ファイルの内容をメモリに配置する。

ロードが終わったら決め打ちされた「特定のアドレス」からCPUが命令を読み込んで実行が開始される。

実行中に発生する関数呼び出しはすでにリンカーによってアドレスが解決されているので示されたアドレスにジャンプするだけで高速に実行される。

実行ファイルのメモリ配置

OSがアプリケーションの実行ファイルを最初にロードしてくる部分についての解説。

まず、実行ファイルのフォーマットはOSによって異なる。

LinuxなどのPOSIX系OS: ELF形式
Windows: PE(Portable Executable)形式
macOS: Mach-O形式

また、実行ファイルには次のようなデータが格納されている。

この実行ファイルが対象としているCPUアーキテクチャの種類
実行ファイル中に含まれるセクションをどのメモリアドレスに配置するか、そのときのセクション名と実行権限
プログラム起動時に最初に呼び出す命令が格納されているアドレス
実行ファイルの実行に必要な共有ライブラリの情報
実行コードのセクション
静的に初期化された変数のセクション

セクションは実行ファイルフォーマットを構成するバイナリデータのブロックのことで以下のようなものがある。

TEXT: 機械語の実行コードが格納されるセクション
DATA: 実行コードを含まない静的に確保された初期化済み（データがすでに入っている）のメモリ領域
BSS: 変数が置かれる領域で初期化されていない（すべてゼロ）メモリ領域

OSはこの実行ファイルフォーマットに従って実行ファイルに含まれるセクションを適切なアドレスに配置していく。⁸その後実行ファイルフォーマットに書かれた初期実行アドレスを実行することでアプリケーションが起動する。

Goのプログラムの起動

Goで書かれたソースコードが実行されるまでの流れは以下。

Goで書かれたアプリケーションをコンパイルすると実行ファイルが作成される
コンパイル済みのGoプログラムを実行すると実行環境のランタイムにある$GOROOT/src/runtime/asm_(ARCH名).sというファイルのなかにある_rt0_(ARCH名)という関数が呼ばれる。このプロシージャの中では以下のような処理が実行される。
1. 最初のgoroutineの初期化
2. OSから渡されるコマンドライン引数os.Argsのパース
3. コンピュターで利用可能なCPUコア数の取得
$GOROOT/src/runtime/proc.goのschedinit()関数の中で以下のような処理が実行される。
- スタックを初期化
- メモリマネージャを初期化し、Mを初期化
- mapの内部で使われるハッシュアルゴリズムの初期化
- モジュール機能向けのモジュール情報や型情報の取得
- シグナルハンドラの初期化
- コマンドライン引数と環境変数の初期化
- ガベージコレクタの初期化

次に新しいgoroutineを作って$GOROOT/src/runtime/proc.goのmain()関数が呼び出される。そこでは以下のような流れで処理が進む。

runtime.lockOSThread()
(ランタイムの)init()
main・init()(アプリケーションのmainパッケージのinit()関数)
runtime.unlockOSThread()
main・main()(アプリケーションのmainパッケージのmain()関数)

まとめ

ここまでの理解をもとにいくつかの質問に対する答えを書いてみる。

プロセスとスレッドの違いは何か

プロセスはプログラムの実行単位であり他のプロセスとはメモリを共有していない。
プロセスは起動時に仮想メモリが割り当てられるためスレッドに比べて起動コストが高い
スレッドはプロセス内で実行される軽量な実行単位でプロセス内のメモリ空間やリソースを共有する。
複数のスレッドが同じメモリを操作する可能性があるためデータ競合を防ぐ必要がある。

プログラムはどのような流れで実行されるか

コンパイラがソースコードをコンパイルする
リンカーがコンパイル済みのオブジェクトファイルをリンクし実行可能ファイルを生成する
ユーザーが実行可能ファイルを実行する(e.g. ターミナルから呼び出す)
OSがプロセスを生成し、プロセスの実行に必要な仮想メモリ空間を割り当てる
OSが実行ファイルの内容をディスクからメモリに読み込み、仮想アドレス空間に適切に配置する
メインスレッドでプログラムが実行される(プロセスが生成されると自動的にメインスレッドが作成される)

感想

冒頭にも書いた通りCSを体系的に学んだ経験がない自分にとってはとても勉強になった。

次はこのあたりの書籍を読んでみようとおもう。

コンピュータシステムの理論と実装
Go言語による並行処理
つくって、壊して、直して学ぶ Kubernetes入門
Linuxで動かしながら学ぶTCP/IPネットワーク入門
体系的に学ぶ安全なWebアプリケーションの作り方

あるいは、 Webサーバーアーキテクチャ進化論2023 - blog.ojisan.ioを参考に学習ロードマップを立ててみるのもいいかもしれない。

Neovimでのデバッガの環境構築は nvim-dapでGolangのデバッグ環境構築を参考にした ↩︎
Sysfdの定義はgolang/go/src/internal/poll/fd_unix.go#L23(https://github.com/golang/go/blob/c83b1a7013784098c2061ae7be832b2ab7241424/src/internal/poll/fd_unix.go#L23) にある。 ↩︎
io.Pipeの使いどころに関しては Go言語のio.Pipeでファイルを効率よくアップロードする方法が大変参考になった。 ↩︎
cf. kyu08/go-system-programming/4-channel/unbufferedchannel/main.go#L8 ↩︎
Distrolessに対して「コンテナイメージが軽量になる」以外のメリットを感じていなかったが書かれている通りセキュリティ面でもメリットがあると気付いた。 ↩︎
fzf-makeの出力の一部に色を付けるために使っている。 https://github.com/kyu08/fzf-make/blob/12789acd19bc24daa60ba7eb84973dab18fe7a52/src/usecase/execute_make_command.rs#L5 ↩︎
https://ufcpp.net/blog/2023/12/escape-escape/ ↩︎
仮想メモリ空間についてはκeenさんのこちらの記事がとてもわかりやすかった。メモリとスタックとヒープとプログラミング言語 ↩︎

『読み手につたわる文章 - テクニカルライティング』を読んだ

Wed, 05 Jun 2024 15:21:05 +0000

技術書典で購入した『読み手につたわる文章 - テクニカルライティング』を読んだので学びになったトピックについて書く。

1.2 「知らない」と書けない（P14）

そして自分が対象物を思っていたより「知らない」ということに、我々は気付いていないことが多いのです。上手な絵は、対象物のことを知らないと描けません。それと同じように、分かりやすい実用文は、文章力のあるなし以前に 対象物をよく知らないと書けない のです。

文字にすると当たり前のことのように感じるが、ブログを書いているとよく実感する。

技術的な内容であれば、当然対象を理解していないと書けないし、自分の考えでさえもいざ言語化しようと思うとなかなか筆が進まないことが多い。

そうした場合にはまず自分が何を言いたいのかを整理して理解するようにしている。

2.1.4 いつまでに何をしてほしいのか書こう（P25）

何の食べ物だか言わずにいきなり「食べて! ほら食べて!」とスプーンを差し出されると、「え、怖い。なになになに?」となって、とても素直に口を開く気にはなれませんし、食べたところで猜疑心で味もよく分かりません。そんなときは「初めて作ったプリンが思いのほか美味しくできたので一口食べて感想を教えてほしい」というように、どういう意図で読み手に何をして欲しいと思っているのかを先に説明してあげる必要があります。

引用部分の前に書かれていた例示のエピソードがわかりすぎて無限に頷いてしまった。認知負荷が高い文章を読むにはエネルギーを要する。

報告なのでただ把握だけしておいて欲しいのか相談がしたいので意見を求めているのかなど、読み手に求めるアクションを明示すると読み手の認知負荷が低くて良さそう。

結局伝えたいことが伝わらないことには意味がないので書いて満足、ではなくドキュメントを書くことの目的を見失わないようにしていきたい。

2.2 文書構造や文章量が適切だと分かりやすい

2.2.1 大枠から始めてだんだん細かくしていこう（P26）

文章で何かを説明するときには、先に大枠を理解してもらい、それから段々細かい内容にしていくという順番を意識しましょう。

以前上司にレビューで指摘してもらって以来意識するようになった。

コンテキストを共有していない人とコミュニケーションを取る時は特に重要だと感じている。自分と相手が持っている情報の差分を埋めるように情報を提示できるとスムーズにコミュニケーションを取れる印象がある。

2.2.3 既知から未知に繋ごう（P28）

文章を書くとき、「大枠から詳細へ」の他に意識すべきもう1つの順番は「既知から未知へ」です。技術ドキュメントを読んでいても、最初から知らない単語や知らない概念ばかりが次から次へと出てくると、「知らないことについて説明してくれているけど、その説明がまず分からない」という状態になります。

あまり意識したことがなかった。

一度にまとまった情報量を記述したい時にはこのあたりまで意識して書くと認知負荷が減ってよさそう。

2.4 再利用しやすい文章にする

2.4.2 並列はナカグロ（・）で書かない（P34）

文章の中で並列を表そうとして「ホーム・検索・マイページ・ヘルプのタブは非表示にできません」のようにナカグロ(・)を使っていると、再利用されて箇条書きになったときに、次のような見た目になることがあります。
着せかえの設定時、以下の機能は非表示にしたり、見た目を変更したりできません。
・ホーム・検索・マイページ・ヘルプのタブ
・トレンドワード機能
・ID連携機能

対策として、最初から箇条書きにしておくか、読点を使うといいとのこと。

いつもどう書くか迷っていたが・で並列関係を表現すると上記のデメリットがあるので読点を使うようにしてみようと思う。

2.4.4 リンクテキストを「こちら」にしない（P35）

リンク切れになったときやテキストだけコピーされたときにリンク先がどこを指しているのかわからなくなるため、以下のようにどういったページなのかも含めて書くのがいいとのこと。

また「詳しくはShops APIのAPIリファレンスをご覧ください」

また、読み手としてもリンクを踏む前にどんなページへ飛ばされるのかわかるというメリットも紹介されていた。

まとめ

具体的な知見が理由とセットで書いてあってとても勉強になった。¹チームで仕事をする上で認知負荷を下げる工夫の重要性を日々感じるのでこれから意識的に実践していきたい。

紹介したトピック以外にもたくさんの知見が紹介されていたので気になった方はこちらからぜひ購入してみてください。こちら ²

余談だがちゃんと理由まで書かれているとスムーズに理解できるのでちゃんと背景や理由を説明するのは重要だと感じた。 ↩︎
冗談です。リンクテキストにはリンクの内容がわかるようなものにしましょう。購入はこちらから。読み手につたわる文章 - テクニカルライティング - 技術書典マーケット ↩︎

『いちばんやさしいアジャイル開発の教本』を読んだ

Sat, 25 May 2024 15:48:56 +0000

2024/4からチーム異動してスクラムを実践しているチームに移ったのでアジャイル・スクラムのインプットをしたいと思い、『いちばんやさしいアジャイル開発の教本』を読んだ。

本書を読んで自分なりに勉強になったことをLessonごとに書いていく。（カッコ内のPxxはページを表す）

Lesson6. アジャイル開発とは何か（P28-31）

「継続的に改善することが前提」なので逆にいえば作りたいものが決まっているならばアジャイル開発を採用するメリットは薄いかもしれない。

Lesson7. カイゼン（P32）

世界で通じる日本語、“Kaizen”。このKaizenという言葉は日本においてもカタカナで 「カイゼン」 と表現されており、「改善」という単語とはあえて区別されています。

もともと改善という表現は「誤りや欠陥を正し、よりよいものにする」という意味があります。カイゼンは 「いまあるものをよりよいものにしていく」 という精神に基づいており、より前向きで積極的なものだということがわかります。

「カイゼン」という表記を見たことはあったが、文脈によっては「改善」とは別の単語として使われているというこれは知らなかった。

Lesson14. アジャイル開発の構造（P56）

マインドセット： アジャイルソフトウェア開発宣言
マインドセットを実現するための原則： アジャイル宣言の背後にある原則
現場での実践： スクラム・XP・FDD・カンバン・モブプロなど

Lesson17. 個人と対話（P66）

アジャイルソフトウェア開発宣言の 「プロセスやツールよりも個人と対話を」 について書いた章。

対話と議論の違いは何でしょうか。ざっくり説明すると、議論は自分自身の目線から主張を展開するものですが、対話は相手の価値観を尊重し、ともに考えていくものです。

プロダクト開発では不確実性が高いため、必ずしも正解がなく、あらゆる角度から課題を見つめることでより良い解決策を探っていくことが重要で、そのための有効な手段として「対話」があると解釈した。

また、対話を繰り返すなかで互いの認識のズレや齟齬を発見し解消していくことで、議論の前提にズレが生まれることが減り、よりスピーディーに問題解決を行うことができるようになりそう。（これはアジャイルに限らないが）

このように個人を尊重し、対話をしながらチームの課題と全員で向き合うことで相互理解が進み、それぞれが異なる立場からの視点を得ることができます。

盲目的にプロセスやツールに従うのではなく、個人との対話をして相互理解を深めることでチームが強くなる。そのようなチームでは信頼関係があり情報共有が活発に行われるため問題が起きても迅速にリカバリーできる。

Lesson.18 動くソフトウェア（P68）

アジャイルソフトウェア開発宣言の 「包括的なドキュメントよりも動くソフトウェアを」 について書いた章。

ソフトウェア開発においては課題とその解決方法を仮説として立て、実際にリリースして検証するという流れで開発を進めることが多い。

細かくリリースするのではなく、機能を全て作り込んでからリリースした場合、仮説と解決策の確らしさを検証できるのが遅くなってしまう。

なので、仮説を検証するために最低限必要な機能が備わっているプロダクト（MVP）を提供して仮説の検証を行うことでより素早く検証のループを回すことができる。

また、いくら社内で話し合ったところで実際の顧客の反応がわかるわけではないので、一定仮説を煮詰めたらリリースして実際の反応をみることが重要そう。

Lesson.19 顧客との協調（P70）

アジャイルソフトウェア開発宣言の 「契約交渉よりも顧客との協調を」 について書いた章。

自社開発の場合はこの契約交渉はどのような形となって現れてくるのでしょうか。たとえば、顧客からのフィードバックに対して「それは仕様が悪い」「仕様通りの挙動です」というようにいまのソフトウェアの挙動が正しいことを前提として判断してしまう、といった保守的な行動として現れます。

…(中略)…

ユーザーボイスを尊重しながら、そのままいわれたとおりに開発するのではなく、その声の裏側にある本当に要望を見極めていきましょう。

社内外からのフィードバックをフラットに受け取ってフィードバックの裏側の要求を見極めることでよりよいプロダクトを作っていけそう。

Lesson.20 変化への対応（P72）

アジャイルソフトウェア開発宣言の 「計画に従うことよりも変化への対応を」 について書いた章。

プロダクト開発においては常に最新の情報を基に仮説をアップデートすることが重要なので事前に決めた計画通りに進めることよりも、都度変化に適用することが重要そう。(それはそうという感じだが)

Lesson.22 自己組織化チームとリーダーシップ（P76）

図表22-2が示すように自己組織化チームとはひとことでいうと「自走できるチーム」です。自分たちがなぜここにいるのかを理解し、またお互いの得意分野がわかっているため自分たちで最適なフォーメーションを組みながらビジョンへと向かっていきます。リーダーの意思決定を待つことなく自己修復的に課題を解決していく。それが自己組織化チームの底力です。

『いちばんやさしいアジャイル開発の教本』P76より引用

チームの振り返りなんかでも、「どうすれば自己組織化チームに近付けるか」という観点で考えてみてもいいかもしれない。

自己組織化チームにおいて情報共有は重要な要素

よく透明性が大事、と聞くけどそれも個々人が自律的に行動するために情報は不可欠だからなんだろうなーと思った。

理想的な自己組織化チームとは？

(中略) 自己組織化し、それぞれのメンバーがリーダーシップを発揮できるようになると、 外からチームを見た際にはもはや誰がリーダーと呼ばれる役割なのかわからなくなるでしょう。

これは自己組織化されたチームの見え方の1つとして良さそうだとおもったので心に留めておきたい。

まとめ

まずは「自己組織化チーム」を目指していきたい。
実際にアジャイルの入門書を1冊読んでみて、とはいえまずはスクラムガイドをしっかり理解した方がよさそうだと思ったので次はスクラムガイドを読み込んでいこうと思う。

『ベタープログラマ』を読んだ

Wed, 06 Mar 2024 15:27:45 +0000

『ベタープログラマ』を読んだので自分的に刺さった点をまとめる。

6章航路を航行する

新たなメンバーが開発チームに参加する際にどのようにすれば速やかに生産的になることができるかについての章。

最善な策はすでにプロジェクトへの理解があるメンバーに導いてもらうこと。もしそれができなければ次のようなことを調べるとよい。

ソースの取得の容易さ

ソースの取得がどれだけ簡単か。健全なプログラムはコードベース全体を得るための単一のチェックアウトのみを必要とする。

コードのビルドの容易さ

一般的でないツールにビルドが依存していないか
コード自身に適切で簡単なドキュメンテーションがあるか
手作業なしで1つのコマンドでビルドを行うことができか
コードの一部に取り組んでいるときにその部分だけをビルドできるか
ビルド中に潜在的な問題を曖昧にしているかもしれない無数の警告が出ていないか

テスト

単体テスト・インテグレーションテスト・システム全体のテストがどの程度揃っているか
テストは自動で実行されるか。あるいは追加のビルドステップを必要とするか
テストはどれだけ頻繁に実行されているか
カバレッジはどの程度か
テストは適切できちんと作成されているか

コードとテストには普遍的な関連性がある。優れたテストが存在するコードはたいていきちんとリファクタリングされ、きちんと考え尽くされている。

ファイルの構造

ディレクトリの構造が領域・サブシステム・コードの階層を明確に表しているか
ディレクトリの構造が整っているか
サードパーティのライブラリはプロジェクトのコードからきちんと分離されているか

ドキュメンテーション

ドキュメンテーションは存在するか。わかりやすく、かつメンテナンスされているか

要件

プロジェクトの要件文書あるいは機能仕様書があるか。

プロジェクトの依存物

コードは特定のFWやライブラリを使っているか。それらについてどの程度学ぶ必要があるか
コードが言語の標準ライブラリをうまく利用しているか

コードの品質

品質の感触を得るためにざっと目を通す。

コードのコメントの量と質はどうか
多くのデッドコードがあるか
コーディングのスタイルは全体にわたって首尾一貫しているか

アーキテクチャ

ここまでの項目を通して主となる階層群を特定できるか
それらの階層がきれいに分離されているか

上記を実施すれば素早くプロジェクトについて把握できる。では実際にプロジェクトに取り組む際にはどのようにすればいいか。

やってみて学ぶ
- コードを読むことは読むことにすぎない。実際に取り組んでみて、間違いを犯すことによってのみコードベースを学ぶことができる
何か単純で小さな修正から着手する
コードを点検する
- コード検査ツールをコードベースに対して実行してみる
- コンパイルの警告が無効にされいないか調べる。無効にされていれば有効にして警告が表示されないようにコードを修正する。それによってコードベースの構造と品質の理解を深めることができる
調査、そして行動
- コードの小さな部分を調べ、批評してみる。弱点がないか調べ、容赦なくリファクタリングする。正しい命名に修正したり、長いコードを小さくて適正な命名をもつ関数に切り出す
- このような作業を数回行うことで、コードにどれだけの柔軟性があり修正や変更に対してどれだけ従順であるかの感触を得ることができる
維持管理
- ソースファイルを整頓したりディレクトリ階層を正しくしたりする
わかったことを文書化する
- コードに取り組み始める方法を説明しているトップレベルのREADMEは存在するか。しなければ作成してこれまでに学んだことを書く
- そのドキュメンテーションを経験のあるプログラマにレビューしてもらう

新たなコードベースに取り組むほど、新たなコードを効果的に学ぶことができる。

この章はプロジェクトのキャッチアップに必要な観点が多く記述されていてとても参考になった。

新しくプロジェクトに参加した際(業務・OSS関わらず)
既存のプロジェクトの課題点を整理する際

などのタイミングで特に参考にできそう。

14章ソフトウェア開発とは

ソフトウェア開発は退屈な仕事

ソフトウェア開発の仕事の多くは、楽しくありません。魅力的でもありません。(中略)有能なプログラマであるためには、退屈な仕事を恐れてはいけません。(中略)時には、私達はソフトウェアの清掃員にならなければならず、次のことが求められます。…

自分が学生のときには想像できていなかったソフトウェアエンジニアの現実、という感じがする。学生のときには毎日コードを書けるなんて夢みたいだ！と思っていたけれど、実際には楽しくない仕事もあるしコードを書かない日もある。ただ、自分が見てきた優秀なエンジニアたちはそういった仕事であっても着実に丁寧に素早くこなしていた印象がある。

あと、このところは

チームとして成果を出すためにはどうすればいいか
身の回りの人から信頼される振る舞いとはどのようなものだろう

を意識して行動するようにしていて、自分にとってタスクが楽しいかや成長に繋がるかということをいい意味で意識せずに仕事ができている。この意識を持つようにしてから仕事が楽しく感じられるようになったので自分にとってもかなりいい変化だった思う。

15章規則に従って競技する

自分達で決めた規則が必要です。私達が所有権を持つ規則です。特定のチームにおける文化、およびうまく開発できる方法を定めている規則です。これらは、大きくて、扱いにくい厳しい規則である必要はありません。新たなチームメンバーがすぐに一緒に開発できるように、単純なものでよいです。つまり、それらは単なる方法やプロセスよりも詳しく何かを記述している規則であったり、コーディング文化を記述している規則だったりします。すなわち、チームで優れた選手になるための方法を記述している規則です。

この 「チームで優れた選手になるための方法を記述している規則です。」 という部分が特にいいなと思った。チームメンバーとして活躍する方法が言語化されていることで、新しいメンバーが素早く立ち上がることができるだけでなく、すでにチームに所属しているメンバーもことあるごとに立ち返ることができて、方向性がずれかけてもうまく軌道修正できるなどのメリットがありそう。

個人的にチームで共通理解を持つことでチームの方向性がうまく揃い、軌道修正もしやすかった経験を部活のときにしたのでこの章の内容はとても腹落ちした。

18章変わらないものはない

コードのどの領域も、誰にも「所有」されていません。どの領域でも、誰もが変更を行うことが許されています。コードを所有するといった制度は避けてください。それは、変更を抑制します。

サーバーサイドの開発チームに初めて異動したときは「自分よりもサーバーサイドも経験が長いエンジニアたちが書いたコードだからどの部位も意図があり、設計も練られた上で今の実装になってるに違いない…！だから強い理由がないとなかなか変更を加えるべきではないのではないか」という思い込みがあったが、何ヶ月かサーバーサイドの開発の経験を積んで「なんか全然自分でも修正できそうなところあるぞ・・・！」と感じられるようになった。

いい意味でフラットな目線でコードベースに触れる意識を持てるとよさそう。

28章倫理的なプログラマ

プログラミングのキャリアの中で、最も頻繁に出会う人々は、チームメイトです。彼らは、毎日一緒に働くプログラマやテスターなどです。倫理的なプログラマは、彼ら全員と一緒に誠実に働き、各チームメンバーに敬意を払って、できる限り最善の結果を達成することに注意を払っています。

どれだけ成熟しているとか経験を積んでいるとかに関係なく、誰もが貢献できる価値を持っていることを常に信じてください。

誠実で信頼されるようになってください。誰にでも誠意を持って接してください。

大事。

倫理的なプログラマは、燃え尽きるような働き方をしません。それは、個人的に不都合であるだけではなく、チーム全体に対しても悪い影響を与えます。毎週、何十時間も残業すれば、疲れ切ったプログラマになり、必ず不注意な間違いを生み出し、悪い結果となります。驚くほど熱心に働く英雄のように思われるのは素晴らしいですが、倫理的なプログラマは、非現実的な期待に応えようとして、自身が燃え尽きてしまうのは悪い考えであることを理解しています。

直感では理解できるが、プロジェクトの種類によっては残業の量が成果に直結することもあり難しい。残業を最後の手段にしつつ必要なときはやる、くらいの感覚がいいのだろうか。(残業前提でスケジュールを組み出すと工夫をする発想がなくなり、効率が上がらず長期的には損だと思う。もちろん燃え尽きリスクが高まるという面でもそう。)

あとは現実的にビジネス的に絶対に守りたい締切があることはあると思う。現場レイヤー目線だと踏ん張りどこは頑張って、乗り切ったら少し休むようにし、マネジメントレイヤー目線だとそうならないように人員計画をいい感じにするとかがいいのだろうか（？）

ただ、チームをマネジメントする立場からみると長期間安定して働いてくれることも一定嬉しいとは思うので無理をしすぎないことも重要そう。

結び

ひどいプログラマと優れたプログラマを区別しているものは、態度です。それが、単なる適当なプログラマと並外れたプログラマを区別するものです。

態度は、技術スキルに勝ります。プログラミング言語の複雑な知識は、保守可能なコードを保証しません。プログラミングのモデルを多く理解したからといって、必ずしも優れた設計を生み出すとは限りません。あなたのコードが優れているかどうかと、あなたと一緒に働くのが楽しいのかどうかを決めるのは、あなたの態度なのです。

この記述がこの本を通して特に刺さった。シンプルだがとても重要なことだと思う。「何ができるか」も重要だが、それ以上に「どうしたいか」や「どこを目指しているのか」がより重要なのだろうと思った。ついついハードスキルばかりに目がいってしまうがそういった志向性を持つことにも同様に気を配りたい。

自分が見てきた優秀なエンジニアはこれを体現している人ばかりだったように思う。

最悪技術力の不足はレビューなどで他のエンジニアの力を借りて補うことができても、オーナーシップや主体性に限っては自分自身で持つしかない。¹そういった意味でもどのようにすれば良い態度を保ち続けられるか、はふりかえりや環境選びの重要な観点になるように思える。

感想

「優秀なエンジニアはどう振る舞うか」を主題に数多くのトピックが書かれていてとても参考になった。自分がこれまで接してきた優秀なエンジニアの振る舞いとも重なるところが多かった。優秀なエンジニアがなぜ優秀かをあらゆる角度から言語化していて理解を深めることができたし、自分も真似できそうなことが多くあったので実践していきたい。

次は久々に技術寄りの本を読みたくなったので次はRust関連の本を読んでみたいと思う。²

あとは「プログラマー脳」も気になるのでいずれ読みたい。

もちろん日々研鑽して自分の技術力を高めることも当然重要だと思っている。 ↩︎
「コンセプトから理解するRust」でRustの理解を深めて「詳解Rustプログラミング」でRustで低レイヤーを学んでいこうと思っている。 ↩︎

『世界一流エンジニアの思考法』を読んだ

Sun, 19 Nov 2023 01:41:50 +0000

Microsoftのエンジニアとしてアメリカで働いている牛尾剛さんが優秀な同僚から学んだ思考法について書いた著書『世界一流エンジニアの思考法』を読んだので学びになったトピックについて簡単に書こうと思う。

頭がよくても「理解」には時間がかかる

ある若くて優秀な同僚が新しいプロジェクトに参加するときにアーキテクチャの説明ビデオを「難しいので何回も見直している」と言っていたのに対して著者が衝撃を受けたというエピソードが紹介されていた。

なかなか他人の作業過程を観察する機会もないのでついつい「優秀な人は複雑な物事でも一瞬で理解してしまうのだろう」と想像してしまいがちだが、Microsoftの凄腕エンジニアでも理解に時間がかかることがあるという実例を知り、何だかとても励まされた気分になった。

新しい技術や概念の理解に時間がかかるとついつい仮想上の優秀な人と自分を比べて「はやくインプットしてはやくアウトプットを出さなければ」と焦るのをたまにやってしまうが「優秀な人でも物事を正確に理解するには時間がかかることもある」という心持ちでいるだけで焦らず着実にインプットしていけそうだと感じた。

そうして「正確に理解している概念」が増えていくほど新しい概念を理解する速度も向上するはずなので焦らず地道に理解することに努めたい。（もちろん時間的制約があるケースもあるので一概には言えないが）

このトピックに関しては以下の記事にもあるのでもし気になったら読んでみて欲しい。

プログラミングというより物事が出来るようになる思考法｜牛尾　剛

完全に余談だが、優秀な人をリスペクトしすぎると「自分とあの人は違うしな・・・」と自分にはそういった人のような素晴らしいアウトプットは出せないという思い込みを持ってしまいがちなので自分を卑下せずかといって奢りもせずフラットな気持ちで自分を励ましまくっていきたい。

Be Lazy(怠惰であれ)

より少ない時間で価値を最大化するという考え方。これを体現するために習慣として次が紹介されていた。

望んでいる結果を達成するために、最低限の努力をする。

不必要なものや付加価値のない仕事（過剰準備含む）をなくす。

簡潔さを目指す。

優先順位をつける。

時間や費やした努力より、アウトプットと生産性に重点を置く。

長時間労働しないように推奨する。

会議は会議の時間内で効率的かつ生産的に価値を提供する。

自分なりに抽象化すると

成果にフォーカスする
より効率的に成果が出るように工夫する

ということなのかなと思った。

とくに自分は成果を安定的に出せているかと言われると全然そんなことはないので、まずは「成果を出すこと」次に「より効率的に成果を出すこと」というステップで意識していくと良さそうだと思った。（あまり残業しないことばかりに意識を向けると結局期待される成果がでずに会社も自分も不幸せ、という状況に陥ってしまいそう）

ただ、成果を出す手段として長時間労働を第一の選択肢にしてしまうとさまざまな弊害があるとは思うのでそこは気をつけたい。

長期的な生産性を高めるためには

振り返りをして改善し自分 / 自チームの生産性を高めること
振り返りを通して得た気付きを共有して組織の生産性を高めること
自分のスキルアップに一定時間を投資すること

あたりは大事かなと思うのでやっていきたい。

タイムボックス制

以下のように紹介されていた。

タイムボックス制で、学習の時間を確保する

今までは、時短を試みても「アウトカム」重視派だったので、切りのいいところまでやろうと考えて、結局寝る直前までかかってしまうことが頻繁にあった。(中略)ソリューションは簡単だった。「タイムボックス」制だ。例えば、5時になったら仕事が途中でも、どんなに切りが悪くても、すぐに仕事をやめる。いつの間にか時間が過ぎてしまわないよう、5時きっかりにアラームをセットして。

絶対に時間をオーバーすることはないよう、しばらく無理矢理にでも「タイムボックス」で生活してみたらどうなったか？まず、5時に強制終了するようにすると、就業後にランニングできるようになった。頭がすっきりとリフレッシュするのがわかるし、夜に本を読んだり、ギターを弾いたり、ゲームしたりする余裕が生まれた。以前はそうした時間にすごく罪悪感を感じたが、一番イケてる人たちの意見をじることにしたのだ。タイムボックス導入と同時に朝型の生活にシフトして、必ず夜10時には寝るスタイルにしてみた。

すると1週間もしないうちに、というか翌日から頭が冴えて生産性が上がった。正直マジかよ！と思ったが、今までどれだけ働きすぎて頭の切れが鈍くなっていたかを痛感した。運動をしなければ、動物として何かがおかしくなるのも当然だし、深夜まで起きて作業したって、ろくに頭が働いていなかったのだ。人間は週40時間労働が一番生産性が上がるという説もあるし、確かに時間を区切ったほうが合理的だ。

仕事に使える時間を定めることで「たくさん残業して気合いで解決する」みたいな解決方法が第一の選択肢となることを防ぎ、工夫や改善によって生産性を上げることに繋がり持続可能な形で開発生産性を上げる文化に繋がりそうだと思った。

成果が出るならばより少ない時間でその成果が得られる方がいいのはそれはそうなので少し自分なりにアレンジして取り入れたい。具体的には「残業しすぎないように気をつける」くらいのマイルドな感じで取り入れてみようと思う。

ここでの示唆は、業務だけに自分の時間を使ってしまうと

学習によって自分の生産性を向上させることがしずらい
残業前提で成果を出すため再現性が低い

ということだと思う。残業しすぎないことで学習の時間を確保したり、開発プロセスの改善やスコープの調整によってうまく成果を出せるようにできていることが重要なのだと思う。

ときには多少残業をしないと厳しいこともあると思うし個人としても残業を1秒もしたくないというほどでもないのでこういう取り入れ方にしてみようと思った。

まとめ

というわけでマインドセットだけでなく具体的なプラクティスの面でも大いに参考になる内容が多かったのでとても勉強になったので折に触れてまた読み返したい。気になった方はぜひ読んでみてください。

『採用基準地頭より論理的思考力より大切なもの』を読んだ

Sun, 22 Oct 2023 11:00:41 +0000

概要

McKinsey & Company出身の伊賀泰代さんがリーダーシップについて書いた『採用基準地頭より論理的思考力より大切なもの』を読んだ。ちょうど「リーダーシップとは」みたいなことが気になっていたので読んでみた。

コンサルティングファームでの出来事を中心に書かれているが、ITベンチャーでエンジニアとして働く自分にも参考になる点が多かったように思う。

学び

思考力とは

思考力とは以下の3つの要素からなる。

思考スキル
思考意欲
思考体力

このうち思考スキルはトレーニングなどで向上させることができるが、思考意欲と思考体力は一朝一夕で身につけることが難しいため筆者は面接時によく見ているらしい。

この部分を読むまで思考力といえば思考スキルや思考体力が主だと思っていたので思考意欲という概念は自分には目新しかった。

リーダーシップが全員に必要な理由

多くの欧米企業が社員全員にリーダーシップを求める理由が書かれていたので引用する。

マッキンゼーをはじめとする外資系企業の多くでは、すべての社員に高いレベルのリーダーシップを求めます。アメリカの場合は、大学や大学院の入学判定に使われる小論文でも、過去のリーダーシップ体験は常に問われる最重要項目です。(中略)全員がリーダーシップをもつ組織は、一部の人だけがリーダーシップをもつ組織より、圧倒的に高い成果を出しやすいのです。だから学校も企業も、欧米では（もしくは外資系企業では）全員にリーダーシップ体験を求めるのです。(中略)リーダーシップのある人は、「成果を出すこと」を「自説が採用されること」よりも優先します。

「全員がリーダーシップを持つ組織」と聞くと「全員自分の意見ばかり主張していては物事が前に進まないのでは…?」と考えてしまいがちだが、ここではリーダーシップを「チームの使命を達成するために、必要なことをやる人」と定義している。

たしかにそう聞くと多角的な視点からよりよい意思決定ができそうな気がしてくる。チーム・組織の全員がリーダーシップを体現できれば指示待ちが起こらず、生産性が高まりそうだなと感じた。

バリューを出す

まずは自分自身が期待されている(あるいは期待以上の)バリューを出すことでリーダーが最もこだわるべき成果の重要性を理解したりやそれにこだわる姿勢を身につけることができる。

ポジションをとる

自分はどう思うのか。情報を揃えて周りに判断を仰いでばかりではいつまでも指示待ち人間を脱することはできない。

自分の仕事のリーダーは自分

組織図を考える時に上司が上、メンバーが下というように考えるよりは自分を中心に捉えてその周りに他のメンバーや上司やその上司などが放射状に位置していると考える。
上司に決めて貰えばいいと考えるのではなく周りの人をどううまく使って自分の仕事を進めるかを考えることが大切。

まとめ

組織の全員がリーダーシップを体現することの嬉しさを知れたのが自分にとっては大きな収穫だった。

成果を意識してやっていく。

『ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用』を読んだ

Sat, 15 Jul 2023 15:00:00 +0000

田中ひさてるさんの『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』が話題になっていたので読んでみた。

全体を通して平易な日本語で書かれていたのとコード例が豊富だったので理解しやすくてよかった。

以下学びを簡単にまとめていく。

第2章パッケージ原則

より変更に強いパッケージ設計にするために注意すべき点として

パッケージの凝集性を高める
より安定度が高い(=抽象度が高い)パッケージに依存する

などがある。

また、凝集性の低さを表すシグナルとしてそのパッケージが変更される理由が複数あること・1つの変更の際に変更対象となるパッケージが複数あること(それぞれ同じ?)が挙げられる。

「抽象」については以下のように説明されていた。

抽象クラスやインターフェイスなど実装詳細を自身から排除したもの

上記のような詳細を持たないものだけに依存するロジック

固有の業務にも特定技術にも関係しない時刻や配列などの汎用概念とその操作

プログラミング言語そのものや言語標準ライブラリと同等レベルの業界標準

第3章オブジェクト指向

いい抽象を見つけるには

具体的な例を分析してそれらから抽象を見つけることで期待値の高い抽象を発見できる。

逆に先にひとりよがりの哲学をこねくり回して現実をかえりみない抽象化を先行させた場合は、役に立たない概念に縛られる無駄が起きやすくなる。（ペットショップのシステムなのに「Catには野良猫もいるかもしれない。必ずしもPetではないかも……」みたいなことを考えてしまうのは明らかに無駄）（抽象化においてもYAGNIが重要っぽい）

無限の可能性に向かって発散してしまわず、いかに可能性を削ぎ落として最小サイズで実際に起こりうるバリエーションをカバーできるかが汎化のポイント。

そういう意味でもドメインやビジネスの状況を理解しておくことはプロダクトの将来を考慮しながら設計するために必要なんだろうなと思った。

「多」態性がなくても役立つ

抽象と具象は必ずしも1対多の関係である必要はない。

具象と抽象に分けておくことで先に大枠を安定させることができるため、設計の見通しがつきやすくなる。

また、具象の数が複数になったときに対応しやすいというメリットもある。

これまで「抽象と具象が1対1対応なケースはわざわざDIする必要はないのでは」と思っていたが上記のメリットがあるので積極的にDIしていこうと思った。

第5章オブジェクト指向原則 SOLID

5-2 単一責任原則(Single Responsibility Principle(SRP))

クラスと責務は1対1対応すべき、という指針。

単一の責務のみつけかた

クラスの利用者がどんなときに別のクラスや新しいバージョンに交換したいと思うかを想像する。

実際に起こりそうな交換要求への想像が責務(= クラスのカバー範囲)を見極めるヒントになる。

たとえば記事クラスが存在し記事の入稿および購読というユースケースがある例では以下のように考えることができる。

ニュース記事を書く人の事情が変わったけれど、購読ユーザーには従来どおりのサービスを提供したい。逆に、入稿はそのまま、購読ユーザーへのサービスを拡張したい。そんなニーズが起きるのは容易に想像できます。入稿と購読のそれぞれを互いに影響を与えない独立したクラスとしておき、いつでも気兼ねなく別の実装に交換できる単位としておく方が、後で便利に決まっています。なので、ニュース記事管理の場合は、「入稿」と「購読」が、それぞれひとつの責務になります。

5-3 開放閉鎖原則(Open Close Principle)

拡張に対してオープン、変更にたいしてクローズドであるべき、という指針。

これは書籍内で紹介されていたコード例がわかりやすかった。

あとはどこが変化する仕様なのかを考えるために一度要件を抽象化してみる方法が紹介されていた。こちらもコード例が示されていたのでイメージが湧きやすかった。

第7章依存性注入

オブジェクトが使う機能の実体を得る際その解決を自力で行わず、常に外部から与えるようにすべき、という設計方針。

依存性注入を行うメリットの1つは生成の責務と使用の責務を分けられる点がある。

また、テスト容易性とDIについては以下のような記述があった。

単体テストしやすいクラスであることと、DI可能なクラスであるということには、正の相関があります。DIを単に「単体テストのためにやること」といった目的観で考えるのは視野狭窄ではあるのですが、単体テストがアーキテクチャへの気づきの手段として、とても有用なのは間違いありません。

テストが書きずらかったら設計を疑ってみるのも1つの手かもしれない。

まとめ

よく聞くSOLID原則もやっとちゃんと理解できたし依存性注入に対する理解も深まったので今後に活かしていきたい。

『コンサル一年目が学ぶこと』を読んだ

Sat, 25 Dec 2021 16:15:48 +0000

コンサル一年目が学ぶことを読んだ。

何を期待して読んだのか

これまで技術の勉強はしたことがあったが、社会人として普遍的なスキルである

問題解決能力
仕事を円滑に進めるためのコミュニケーションの取り方

あたりをちゃんと学んだことがなく、一度入門書的なものに触れたいと思っていたので読んでみた。

学び

印象に残っているのは以下。

端的に話す
仮説を持って行動する
重要なことに時間を使う
期待値のすり合わせを怠らない
Quick and Dirty

それぞれ簡単に補足していく。

端的に話す(Talk Straight)

聞かれたことに対してストレートに答える。具体的には

端的に喋る
素直に話す

ことが重要。

これは相手の立場に立ってみれば当然で、質問をしたのにその答えがなかなか返ってこないと「結局何がいいたいんだ？」となってしまう。

とは言いつつも、自分自身も自分の思考が整理できていない時は特にだらだらと喋ってしまいがちなので、そういう時はいいチャンスだと思って一旦思考を整理するようにしたい。

仮説を持って行動する

1から10まで調査しきっていては時間が足りない。最低限の調査をして仮説を立てたら、検証 -> 仮説の修正のループを高速で回していくことで限られた時間で精度の高い結論を導くことができる。

仮説思考を身につける第1歩として、仮説を持つクセをつけるためにあらゆる事象に対して「自分はどう思うのか」「なぜそう思うのか」というスタンスを持つことを心がけたい。

重要なことに時間を使う

使える時間は限られているので費用対効果を常に意識して時間の使い方を決める。

仮説思考の話とも繋がるが優先順位を設定して重要な課題から手をつけていきたい。

自分に振ってきたタスクどうしの優先順位だけでなく、もう一段上の視座で自分/自チームが今本当に取り組むべきことは何なのか、という思考を心がけたい。

期待値のすり合わせを怠らない

求められていないことに時間を使っても成果には繋がらない。まずは自分が何を期待されているかを正確に把握することが重要。

自分の認識がズレていて後になって手戻りが発生することが稀によくあるので、タスクを振られた際などにその場で

そのタスクの目的
求められているアウトプット

を明確にするように心がけたい。

Quick and Dirty

3日間かけて100% のアウトプットを出すのではなく、まずは3時間で30% のアウトプットをだすべき。

こまめにアウトプットを行ってフィードバックを得ることができれば間違った方向に進んでしまって時間を浪費する前に軌道修正できる。

まとめ

この本を読んだことの収穫としては、自分の中でぼんやりと課題感としてあった

ただがむしゃらに取り組むのではなく効率よく問題を解決するにはどうすればいいのか

というイシューへの回答の1つである、

重要思考・仮説思考を用いる
Quick and Dirty
期待値のすり合わせを怠らない

という考え方に出会えたことが挙げられると思う。

また、コンサルタントのプロフェッショナリズムに触れて自分も周囲の期待を越え続ける存在でありたいと思った。

おまけ

「仮説思考をやっていこうと思いました」(意訳) という話を上長にしたところ『イシューからはじめよ』をおすすめされたのでこちらも読んでみようと思う。

読書ログ on blog.kyu08.com

『エンジニアのための時間管理術』を読んだ

読もうと思ったきっかけ

まとめ

『プログラミング言語C 第2版』を読んだ

どんな本か

読み方

学び

まとめ

『ネットワークはなぜつながるのか』を読んだ

どんな本か

なぜ読んだか

学びや気付き

1. ブラウザが何をしているか

2. DNSが何をしているか

DNSサーバーに格納されているデータ

世界中のDNSサーバーが協調する仕組み

3. TCPでの接続の場合にプロトコルスタックが何をしているか

4. IPが何をしているか

5. イーサネットとは何か

6. インターネットとは何か

Q&Aメモ

まとめ

『解像度を上げる』を読んだ

「解像度」の構成要素

情報をツリー構造で整理する

解像度を上げる対象

課題の選び方

書くことで考える

書くときの留意点

深める

不慣れな分野のキャッチアップ

教える

コミュニティに参加する

まとめ

『CQRS Documents by Greg Young』を読んだ

CQRSに興味を持ったきっかけ

“A Stereotypical Architecture”: 典型的なアーキテクチャ

ここまでの感想

CQRSとは

ここまでの感想

“A Stereotypical Architecture"にCQRSを導入する

Query

Command

ドメインイベント、イベントソーシング

ここまでの感想

作業習慣の違い

ここまでの感想

感想

『RustによるWebアプリケーション開発 設計からリリース・運用まで』を読んだ

モチベーション

本書の概要

学び

実際にRustでWeb Serverを書いてみた感想（主にGoとの比較）

ポジ

ネガ

まとめ

『コンセプトから理解するRust』を読んだ

前提

学び

まとめ

おまけ

『つくって、壊して、直して学ぶ Kubernetes入門』を読んだ

そもそものモチベーション

特徴

学び

感想

『デッドライン』を読んだ

生産性の向上(P84)

リスク管理(P84)

人材管理の智将(P94)

プレッシャーの効果(P200)

スタッフの人数(P259)

まとめ

『Tidy First?』を読んだ

「整頓」という概念

第11章 ステートメントを小分けにする

第13章 ひとかたまり

第14章 説明コメント

第19章 リズム

『RustによるWebアプリケーション開発設計からリリース・運用まで』を読んだ

第11章ステートメントを小分けにする

第13章ひとかたまり

第14章説明コメント

第19章リズム

第21章先に整頓、あとに整頓、改めて整頓、整頓しない

第25章明日の1ドルより今日の1ドル

第26章オプション

第32章凝集

第33章結論

『コンピュータシステムの理論と実装第2版』を読んだ

第1章ブール論理

第2章ブール算術

第3章メモリ

第4章機械語

第5章コンピュータアーキテクチャ

第6章アセンブラ

第7章仮想マシンI：処理

第8章仮想マシンII：制御

関数の呼び出し(`call`)

関数からのreturn(`return`)

第9章高水準言語

第10章コンパイラI：構文解析

第11章コンパイラII：コード生成

『Goならわかるシステムプログラミング第2版』を読んだ

第2章低レベルアクセスへの入口1：io.Writer

第3章低レベルアクセスへの入口1：io.Reader

`io`パッケージのいくつかの関数 / 構造体 / インターフェースの使い方

第4章チャネル

第5章システムコール

Goに組み込まれているTCPの機能（`net.Conn`）だけを使ってHTTPによる通信を実現する

第8章高速なUnixドメインソケット