趣味・読書の最近のブログ記事

Amazonアフィリンク

特にOSレスの規模の組み込みシステム向けのソフトウェア開発の大まかな技術要素を解説した本。経験の浅いソフトウェア開発者や、ソフトウェアに明るくないハードウェア開発者をターゲットに、実開発の経験から、開発の定石やノウハウを語っている。

まえがきにも書かれているんだけど、体系的な技術の獲得というよりも、実開発の経験を詰め込んでいる章立てや内容になっている。また、OSレス程度の規模が対象とはいえ、(2026年から見て)ここ10年ほどの最近のトレンドがいまいち反映しきれていないようにも思える。一方で、日本語の訳者がLinuxに明るいこともあり、注釈が大規模組み込みLinux向けに誘導している風もあって、読んでて想定読者の像がブレてる印象が拭えない。

内容も、パソコンしか知らない(組み込みを知らない)ような初級開発者が組み込み中級を目指す、といったレベルの内容に感じた。細かく読めば、実体験から来る開発の難しさも書いてはあるんだけど、具体的な手法といった深い内容に入るのではなくて、あくまで初級者に向けて一般論を語りとくというか。著者は、DSPなどの信号処理が本当の専門のようで、いっそのことそっちの内容を増やしたほうがよかったのでは、と思わなくもない。「組み込み」と一口に言っても幅が広くてひとまとめにしづらい、という特有の課題なのかもしれない。

というわけで、私としては、組み込みを知らない初級者ソフト開発者が組み込みを本業にするときに読む本、と感じた。残念ながら今の日本ではそれに該当する人って非常に少ないんだよなぁ。

以下は個人的に気になった箇所のピックアップ集。

2.2.2 ブロック図(P11)
＞SPI(スパイと発音)
今までずっと「えすぴーあい」と呼んでた。というか「すぱい」と呼んでる人見たことない...

3.7.1 デジタルマルチメータ(P51)
＞デジタルマルチメータ(DMM)だけは用意してください。
昔ながらのアナログテスターと今どきの簡易ロジアナしか持ってない。1つくらいDMM持っとくべきかなと思った。YouTuberの熊五郎お兄さんが使ってるAstroAI デジタルテスターくらいがニワカにはちょうどいいのかな。

6章付近
割り込み禁止と排他処理(mutex)との違いの説明が怪しかった。OSレスなのでSMP(マルチコア)ではないからこの程度で十分、なのかもしれないけど、逆にマルチコア当たり前なArm Cortex-A(Linux含む)なんかだと困るんだよなぁ。「割り込み禁止だけでクリティカルセクション対応できる」という思い込みをしてしまうと苦労する(経験談)

8.4.3 littlefs
https://github.com/littlefs-project/littlefs/というOSレス環境で使えるFilesystemがあることを知れてよかった。

10 ネットワークとセキュリティ
は、ネットワークに繋がるのが当たり前になりつつある昨今のIoT事情を反映していてよかった。

11.2 RAM不足の対策
コンパイラ最適化の話がなにか古い気がする。GNU gccベースのそこそこ最近のバージョンならば、Cortex-M向けで「ローカル変数の数を減らす」ようなことは意味がない(コンパイラが賢く処理してくれる)ような。Arduinoくらいの規模でこういうのが必要なんだろうか。

Amazonアフィへのリンク

約17年前に発売された「Binary Hacks」の名前を冠する続編本。一般的に「低レイヤー」と呼ばれることの多い、コンピュータソフトウェアの中でも特にOSやCPUに近い部分の技術を、章ごとに1つずつ紹介するという内容になっている。

「Binary Hacks」はそれなりに反響のあった本だったため、その名前を冠するだけで、それ相応に注目を集めることになる。本を読んだ限りでは、名前に恥じることのない程度には濃い内容に仕上がっている。まぁ逆に、こんな内容の濃い本を好き好んで読もうと思うような人がいったいどれだけいるのかというあたりにも疑問を持つ。20年ほど前と比べると、今やこの日本でこういった内容のソフトウェア技術を必要とする仕事やらは本当に減ってしまったなというのが個人的な印象だ。

低レイヤーは技術の進化が早いわけではないとはいえ、20年近くも時代が進むとそれ相応に変わっていくわけで、その内容を雑多的に情報として知れるというのは実際のとこ個人的には非常にありがたい。書籍として出版されることが減ってきているという時代に、しかも需要がどんどん減ってる日本語での技術情報提供でというあたり、儲かりもしないのにこれだけのレベルでまとめ上げてくれた各位には本当に感謝したい。

著者らは「＊年後にさらにこの本の続編が出ることを期待して」のような記載を残している。これこそ、こういう領域に熱意を持って力を注ぎこむような人が今後も続くのかどうか、もっと言えば、こんな領域のソフトウェア技術開発を未来の時代に行っているほど日本(なのか日本語なのか)がグローバルに競争力を維持できているのかどうか、という話なのかなと思う。

前作と比べるとページ数が約1.5倍になっている。改めて前作を斜め読みするに、あまり細かく丁寧に説明するような文章にはなっていなくて、それに対し本作は文章をかなり丁寧に書いている事が多いので、その分がページ数の差なのかなと感じた。600ページ超えとなるともはや大型本よね。「サクッと読む」には少々重いというのが若干残念なところか。

というわけで、低レイヤー技術を対象に日本語で書かれた非常にレアな本で、その領域に片足を突っ込んでる人は迷わず買っておけというところ。逆に、低レイヤーに興味がない人には全くささらないと思う。

下記は本の内容で気になったところをメモがてらに。

HACK#6 共有ライブラリの検索の実例
P39「AT_SECUREタグを持つエントリが含まれていた場合」
今まではsuなどのときにLD_LIBRARY_PATHが無効になる条件がわからなかったけど、補助ベクトルが効いていることを知れてよかった。
過去の記事のどこかに「わからない」と自分で書いた記憶があるんだけど、探しても見つからなかったので、訂正ができない。。

HACK#10 TLSのしくみを理解する
P58「TLSアクセスモデル」
gdbでattachしている最中にThread Local Storageな変数へアクセスする方法がいつもわからずに苦労していた。このあたりの記載を頼りに調査すれば、今どきのgdbからのアクセス方法を確立できそう。

HACK#17 LIEFを使ってELFバイナリを書き換える
P92あたり
まさに最近はシンボルの書き換えがクソめんどいから、こういう専用のツールがあることを知れてよかった。ただPython製というのはどうなんだろ。特にクロス環境にて、いずれにしてもlibelfに依存することを考えれば、Pythonに追加対応させるためのツール整備も最近なら大した事ない？

HACK#38 cgroupでプロセスのリソースを管理する
P248 「IOCOST」
I/O Schedulerで制御することしか知らなかった私からすると、こんな他の手段もあるんだなぁと知れてよかった。けど、本書での紹介っぷりからすると、必ずしも思い通りにI/O量を制御できるわけではなさげ？I/O Schedulerでも制御が難しいし、やっぱりI/O制御は難しいという話なのか？

HACK#43 /proc/PID/rootからコンテナ内のファイルに直接アクセスする
docker内のファイルへ外から簡単にアクセスする方法、ずっとこれのやり方が知りたかった。わからなかったので、わざわざdocker cp使って毎回中から外へ大量のコピーをしてしまっていた。

HACK#49 ftraceを使ってカーネル内で起こっていることをトレースする
P341あたり、
KernelShark trace-cmd、あたりは過去に使ってみたことはあるんだけど、これ、目的を定めて使わないと逆に迷走するなと感じた。GUIで可視化すると一部のエライ幹部に受けが良くて、かえって性能改善活動のジャマになって(以下略

セキュリティの大章は全般的にツールを使った力技的な話が多くて「HACKしている」感があまりしないと感じた。数値表現の大章はいわゆる数値計算の分野だというイメージが強くて「まぁ知らなくてもいいかな」と読み飛ばし気味になってしまった。

Amazonアフィリンク

IT技術を活用できるように変革をするべきとうったえる本。ビジネスは顧客の利益となるよう常に変化していかなければならないと前置きした上で、IT技術が社会の変革をもたらすからこそ、IT技術を生かしたビジネスモデルやマインドや組織づくりをしていく必要がある、と主張している。

「ソフトウェア」と本書では言っているものの、あまりソフトウェア特有の視点が多くなく、どちらかというとネットワークやシステムづくりも含めたIT技術と主張したほうが本書の論調にあっているように思う。それらは、IT部門や現場だけでなく、管理層や役員も含めた全社員にかかわるような変革をもたらすからこそ、担当者任せにせず、各々がビジネスの進め方を常に見直していくべきで、またそのために、内製化や内製化とはいかなくても自社でIT基盤をコントロールできるような組織へと変化していかなければならない、という主張が特に強調したい点なのだと思う。

ただ、個人的にその主張がいまいち響かなかった。確かに言ってる内容はそのとおりだと思うし、それらをていねいに主張してはいるんだけど、個人的にはそれらが「当たり前のことを言っているだけ」に感じられた。私はかなり前から根っからのソフトウェア開発者(だと思っている人)なので、主張そのものはもう大昔から何度も聞いてきたことの繰り返しにしか思えなかった。

著者は、DEC・Microsoft・Googleという経歴とのことで、根っこのマインドとしては私に近いはずだと思う。そんな著者が、いわゆる日本の大企業を相手にコンサルしていった先に本書のような主張が出るということは、逆に、私や著者が当たり前と思っているそんなマインドが全然当たり前になっていないというのがまだまだ現在の実情なんだろうなというように思う。

というわけで、IT技術がビジネスモデルや組織をどう変えていかざるをえないように追いやっているのかの話を今一度ちゃんと学び直したい人向けの本。逆に、データサイエンティストやAI技術といった新しく盛り上がっているソフトウェア技術がもたらす新たなパラダイムシフト、みたいなのを期待する人はあまり読まなくてもいいかと思う。

P91「本来、自動車は移動のための手段です。」 走る歓び、みたいな主張をするメーカもあり、変革したくない・変革する必要がないという振り戻しが起こっていたりもしていて、象徴的な文章だなぁと思った。

P109「内製化するのは現実的ではないと思う方もいらっしゃるでしょう」 日本の大企業を相手にしたときにこういう主張が必要になるのだろうなと感じた。開発終わっても社員だと切れないとか、多重下請け問題とか、そういうことを言っている間にもはや自部門や自社でやりきるというマインドすら失われてしまった組織や会社も当たり前のように目にしてしまう今日このごろ。

P271「リモートワーク」 この本はコロナの前に書かれた本だからどちらかというと必要性については抑制的だけど、逆に今は著者はどう考えているのだろうかとも思った。人手人材不足も待ったなしになった今の日本だと、皆が平等に働くようなやり方ではなく、アメリカのように少数の猛烈に働く人を中心とした開発体制にでもしないと厳しいのだろうか。

Amazonアフィリンク

TCP輻輳制御アルゴリズムについての本。インターネットとTCPの位置づけを歴史踏まえながら概要説明し、TCPの輻輳とそれに対処するアルゴリズムを解説し、近年の輻輳対策のトレンドを紹介している。

ほぼタイトルしか見ずに買った私のせいではあるけど、本書はTCPの本ではなくてTCP輻輳の本だった。TCP輻輳制御アルゴリズムの話で2/3くらいを占める。さすがに私も細かいとこはもういいやとなってしまった。読んでて予感はしたけど著者はやっぱりNTT本社研系の人だった。

インターネットのようなノード間通信の延長にあるネットワークでは輻輳他のトラブルに対する制御が極めて難しい、という話はもはや説明するまでもない前提で話が始まるけど、一般人には「輻輳」という用語すら知られていないのが実際なので、このあたりはもっと丁寧に書くべきだったのではと思った。まぁこの本は一般人を相手にしていないから気にしてないというだけなのかもしれない。

本書を読んだ感想として、専門家でもない人が抑えておくべきポイントは、輻輳制御は難しい、Reno CUBIC そして新顔のBBR、広帯域高遅延や無線(ケータイ)をどうするかがトレンド、というあたりまでかなとは思っている。第7章は、成果アピールや予算獲得的な話にしか見えなかったのでスルーで。

というわけで、TCP輻輳制御アルゴリズムに入門したい人におすすめする本。逆に、そうでない人は正直読まなくていいんじゃ、とも思ってしまった。

P107「Linuxにおける輻輳制御アルゴリズムの実装」LinuxだけでなくWindowsやBSDについても触れてほしかった。私は理論上の話ではなくて現実世界の話のほうに興味があるので。

P177「既存アルゴリズムとの親和性」理論屋さんがハマりやすい話なのかなと思った。皆が新しいアルゴリズムに一気に乗り換えるのが理想だけど、現実はそうはいかない、進化論のような生存競争だと他者を押しのけるのが正解だけど、ネットワークだとそれがいいとは限らない。既存アルゴリズムのままの人もそれなりに通信できるように公平性を保つにはどうやればよいのか。

P201「パケットロスのおもな要因はバッファ溢れによるものです」近年は通信機器も高性能化したので、信頼性が上がっている反面、安易にバッファを増やして遅延増加を招いているだけでなく、溢れたときにバースト的にパケロスを起こしてしまう、という実情の話、あまり考えたこともなかったので参考になった。確率的に早めにロスさせたり帯域制御したりして基幹のノードでパケロスが頻発しないように対処したりしているのだろうか。

Amazonアフィリンク

Linux上でのPCM音の入出力の標準となっているALSAについての入門書。音をデジタルデータとして扱うための導入、ALSAの役割とその基本的なAPIについて、ALSAを使ったサンプルプログラミングの解説、という構成になっている。

プログラミングというタイトルになってはいるものの、音をハードウェアから出力する部分を扱うため、比較的低レイヤーなプログラムの話になるし、同時に音をどのような形でデジタル表現しているかについての知識を要する内容になっている。たしかに入門書的な説明の本とはいえ、このへんの分野のことを学ぶんだという心構えは最低限必要かと思う。

プログラミングという触れ込みの本ではあるが、サンプルコードを見る限り、著者はどうもコーディングに慣れていないように見受ける。分野が分野なだけに、信号処理やリアルタイム処理やDSPといったハードよりの分野から流れてきたのかなと推測される。サンプルプログラムは、処理のフローを理解するのにはよいが、細かなコーディングの手癖はマネしない方がよい。

ハイレゾやらUSB Audio Device Classやらの話が登場するが、ハイレゾは本書ではほとんど関係ないし(ビットレート計算くらい)、また現代ではalsaがUSB限定というわけでもないので、このへんは差し引いて読んだほうがよい。

入門書にケチを付けても仕方ないのだけど、実践的な内容にまでは触れられていない。いつでもどこからでもデータを拾い放題な音声ファイルをALSAのクロック任せで出力すれば良いケースは一番シンプルな例で、現実は、音声ってストリームなリアルタイムのデータなので、アンダーラン・オーバーランやレイテンシやASRC(asynchronous sample rate convert)なんかを気にしないといけないのだけど、さすがにそういう内容を求めるのは酷か？とはいえ、P79のNoteにあるniceで優先度をあげようの部分なんか、ごまかすにしてももう少し書きようがあるだろうにと思ってしまう。ここはSCHED_FIFOのキーワードくらいは記載すべき。

と酷評気味に書いてしまったが、ALSAをていねいに解説したものなんて、書籍でもネット上の記事でも皆無に近いので、そういう意味では非常に貴重な本となっている。逆に、ALSAなんて公式ドキュメント読めばいいだろ(当然英語)、というくらいの心構えがある人はやっぱりあえて読まなくても良いとなってしまうか。

Amazonアフィリンク

完結したはずの前作(みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」)のまさかの続編。前途多難で非常に苦労し全面刷新して構築したシステム「MINORI」が稼働したものの、その後も断続的にシステム障害を起こしているみずほ銀行のシステム障害の詳細を掘り下げようという趣旨の本。

立て続けに障害が起こったものの、それらをわかっている範囲で個別に原因を項目化するだけでなく、なぜそのような事象に至ってしまったのかについてもできるだけ掘り下げようとしている。他の例と比較しながら、銀行システムならではの事情や、海外での似たような障害の例も紹介しつつ、1つ1つは他のシステムでも起こっている問題でありつつ、みずほの場合はそれが波及的に連鎖して大規模システム障害に至ってしまっている点を指摘している。

これまでの本は、経営者層がシステム開発と運用を軽視しているという論調が多かったけど、今回の本はその色は弱めた内容だった。とはいえ、テストや運用にさく工数をケチってるんじゃないかの指摘はしており、特に小さなシステム障害が起こった場合の対処マニュアルや実施訓練がほかと比べて不十分というのを具体例を出して述べている。

なんというか、批判するのは簡単なんだけど、じゃどうすればよいのかを大規模開発を対象に語る難しさというのを感じる。規模の差はあれ、私自身も似たように多人数の関わる大規模プロジェクトが迷走する実例をよく見るだけに、この本から何を教訓にすべきかを意識して読まざるを得なかった。プロジェクトなんて成功するか失敗するかは水ものだから、どれだけ小さく早く開発を回せるようにするかがキーなのかなぁ。もしくは、ある程度見識を持った少人数の集団で集中的に開発しコア部分を作り上げてしまうべきなのかなぁ。OSS類をモジュールとしてたくさん利用するのが当たり前な昨今、いくらモジュール志向をもって開発したとしても特定プロジェクトでしか使われないのならば汎用性が低いものしかできあがらない、それを洗練させるには複数のプロジェクトの採用例を増やしてアダプトさせるしかないのかなぁ。などなど。

以下はこれまでと同様に読んでて気になった項目をずらずらと。

第3章p133「二重エラーが発生している旨を伝えた」「二重エラーの報告は受けていない」、障害発生時の情報共有を口頭でのみ行っているという決定的な例かな。エラーメッセージなんて1字1句間違わないようにコピペしてテキストで共有するのが当たり前ですね。

第3章p167「オールフラッシュのストレージ装置に移行していれば、ハードディスクの故障という前時代的なトラブルに遭遇しなかった可能性」、いやそれはさすがに主張がおかしいだろと。SSDも壊れる。HDDより壊れにくいなんてことはない。ただ、頻繁な読み書きをするストレージ部位をSSDにすれば圧倒的な性能でシステムのボトルネックを取り除けるのは確か。

第4章p178「自らの持ち場でやれることはやっていたといえる」、部分最適の極みは実は相当難しい。というのも、システムの開発や運用をやっている末端は、子会社や孫会社どころかそこの孫請けやひ孫請けで、彼らは仕事を受けた単位が自分の持ち場だけなので持ち場を離れて横断的に作業をする義理もないしお金ももらっていない、むしろ契約書に書かれた担当をおろそかにしたと責められる。かといって全体責任を持つ上位の人は指示を出す仕事だけでいっぱいいっぱいになりとても現場の実情をチェックすることもできない。組織の壁でさえよく批判を受ける話なのにそれが会社や契約をまたぐととてもじゃないけどそうはいかない。権限を持った人も現場に入っているような体制でないとこれはそう簡単には解決しない。

第5章p183、みずほのシステム開発の歴史表は参考になる、
第5章p185、銀行各社の統合とそれに連動したシステム統合も参考になる、
どちらも、20-30年といった人のキャリアすべてを費やすような単位で進行するので、人生をかけてシステム開発に携わる覚悟のある人を何人も囲い込まないと成功させるのは難しいよなぁと思う。

第6章p262「(セブン銀行は)東阪交互運用方式を導入する」、予備システムをホットスタンバイさせるのをさらに進めて、何もなくてもメインサブを定期的に入れ替えてシステム運用するの、ウワサには聞いたことあるけど本当にやってるのかなぁこれ。

Amazonアフィリンク

合併に伴うシステム統合がうまくいかず、二度の大規模障害を起こし、20万人月と揶揄された新システムへの一本化開発(本によれば最終的に35万人月らしい？)、というSI的システム開発の苦悩の象徴的なみずほ銀行の内情を描いた本。日経コンピュータが、みずほの中の人に怒られること承知で、内部の分析や推測や提言にまで踏み込んで意見している点が特徴となっている。

銀行にとって中央にある勘定系システムは心臓部であり装置産業であるから経営者層で適切にマネジメントしなければいけない、という点を強調している。お金の流れをシステムで一元管理しているからこそ、必要な業務を正しく定義し、それに寄り添うためのシステムを定義し開発し運用していかなければいけない、というある意味根っこのところを主張している。間違っても、合併に伴う各行の主導権争いやらリスクの先延ばしに注力して目を背けるようなことをしてはいけない、と記している。

過去のシステムトラブルのときにも本が出ていて(二度目の本と一度目の本)、それを読んでいる人からするとあまり目新しい話は出てないと思う。期待に反して(？)、ようやくシステム一新できたのでこれから新サービスに注力していくよ、という宣伝なのか応援なのかな内容が付け加えられた点が新しいか。

もはや神話とも都市伝説ともなっているみずほ銀行の話だけど、ふつうの人にとって見れば「どことどことどこが合併したんだったっけ？」「三連休たびにATM止めやがって」程度なのかなと思う。IT革命とか言われたのもはや20年前、その当時とは比べ物にならないくらいIT技術ありきの社会となっている現在では、ふつうの人でもこの手のシステムの裏側の話は一般教養として知っておいたほうがいいのかもしれないと感じる。

ITだコンピュータだソフトウェア開発だといっても、こういうたくさんの人が関わる開発だとならではの苦悩がたくさん出てくる。そういう開発に苦悩したりする実例を知ることができるという意味では貴重な本。ただ過去の本を読んでいるならあえてこれを買う必要もないのかなと思う。

以下気になった点の列挙。

P61 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「三行で用語を統一するところから」 大きな会社やプロジェクトほどありがちで、用語や意味が違うからすれ違いが起こる。言葉が企業文化でもあるため、開発初期ほど言葉遣いには十分に注意したいと思った。

P64 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「開発のベンダが異なる」 先の用語と同じで、所変われば考え方や文化が変わるので、ここでも十分な意思疎通をとっておく必要性をよく感じる。

P73 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「ツールでしかプログラムを生成しない方針」 うーん、個人的にはこれはどうなのかな。一歩譲ってその方針を受け入れるとしても、ツールの仕様に口出ししたり場合によっては変更したりすることができないと個人的には辛いと感じそう。

P77 第3章「参加ベンダー千社、驚愕のプロジェクト管理」より「開発拠点の確保にも苦労した」 これは最近良く感じる事が多い。いくら音声通話やテレビ会議システムが充実してても、意思疎通の限界を感じることが多く、同じ場所に集まれるに越したことはない。

P83 第4章「緊張と重圧、一年がかりのシステム移行」より「重要な移行作業に三連休を充てた」 リアルタイムにATM休止のお知らせがアナウンスされるのを見ていたけど、障害だけは何が何でも避けようとコストをかける覚悟を持って作業しているのがよくわかった。

P153 第7章「検証、昆明の十日間」より「四億円の未回収が生じている」 銀行はこの手の締めに非常に厳しいというイメージを持ってるんだけど、それが出ること承知で、10万円まで引き出せる特別対応を行ったというあたり、トラブルのときの影響範囲がハンパないんだなと思わされる。

P168 第8章「重なった三十の不手際」より「システム装置産業とも言える金融機関」 結局ここなんよね、お金を扱う業界だったけど、今やコンピュータ上で数値を計算して決済するだけの業界になりつつあって、融資も銀行以外から行うことが増えた結果、銀行なのに紙幣や貨幣を扱いたくないというのが実情だったりと。「AIに置き換わる」とか象徴的に報じられるけど、そうじゃなく、銀行の役割が終わりつつあるのが実情よね。

P170 第8章「重なった三十の不手際」より「ハードウェアではないからだ」 未だにハードウェアとしてのコンピュータを提供してるベンダが全責任を追っているような開発をイメージしてしまう人っているのかな、と疑問に思いつつも、まぁ＊年前はそれが当たり前だったわけだし、古い人向けにはこういう説明が必要なのかとも思った。

P183 第9章「一年をかけた再発防止策」より「情報伝達体制を見直し」 夜間バッチ処理って、タイムリミット...というかタイムラインが必要な作業なので、この手の決まりごとを決めておくのは必要不可欠だよねと思った。

P207 第10章「現場任せが諸悪の根源」より「四行統合」 形としては合併したのに中の組織が全然合併していない、てのはよくある話で、P212「割り勘にできないという理由で、三千九百万円に値切った」とかいう信じがたい話も信憑性が増してしまう。

P237 第12章「大混乱の二〇〇二年四月」より、いい顔してるねこの写真、このあと地獄のようなシステム障害が発生するわけだけど。

...縦書きの本って個人的には受け付けない体になりつつある...