List of Programming [text.Baldanders.info]

AI エージェントとは「もくもく作業」できない

2026-05-10T04:40:39+00:00

（今回は技術的な話は一切ありません。あしからず）

昨年の骨折入院以来「やる気スイッチ」がオフになりっぱなしだったのだが（療養で休職中でよかったよ），先日 pull request を頂いたことで久しぶりにスイッチが入った。

仕事以外で GitHub Copilot のエージェント・モードはほとんど使わない。ここのブログ記事を書く際のタイトル決めやデプロイ作業を手伝ってもらうくらい。でも，折角なのでここは Copilot エージェントに貰った PR のレビューからマージまでやってもらうことにした。ついでに他の goark リポジトリについても少しずつレビュー，修正，PR，マージ，そしてリリース処理までの一連をやってもらっている。

ちなみに Copilot のモデルは GPT-5.3-Codex を主に使っている（これが一番コストと性能のバランスが取れてる）。コード補完やコメント生成くらいなら premium request のコストが発生しない GPT-mini でも十分なのだが，エージェント・モードだとおバカ過ぎて使いものにならない。まぁ，だからこそみんなお金を払って高コストモデルを使うんだろうけど。でも今月はまだ3分の1しか経ってないのに，もう半分以上使ってしまってるよ。散財の予感がする…

プログラマならみんな経験があると思うけど，コードを書いてるとフロー状態というか「ゾーンに入る」ことがある。職場だと周囲の「雑音」のせいでフロー状態を維持するのが難しいこともあるけど，雑音が少ない在宅作業だと一度フロー状態にハマるとなかなか抜け出せず，気がついたら飯も食わんとエラい時間が経ってたなんてことがある（逆に在宅のほうが雑音が多い人もいるかもしれないが）。

だから gogh みたいな作業支援ゲームでポモドーロ・タイマーみたいなのを仕掛けておくというのは意外と有用なのよ¹。コワーキング・スペースや図書館や喫茶店などで作業するってのは集中するための手段じゃなくて集中し過ぎないための手段だと思っている。「もくもく作業」はちゃんと時間を区切ってやらないと。

一方で AI エージェントとの作業は「もくもく作業」にならない。当たり前だ。「対話」してるんだもの。

プログラマ目線で見ると，あれって機械とのペアプログラミングだわ。機械がコードを書いて，横で人間が茶々を入れながら見てるの。

ペアプログラミングってマジでやるとお互いめっちゃ疲れるんだよな。コードを書く側は常に見られながら書いてるからフローどころじゃないし，横で見ている側もコーディング中の相手の思考や作業ペースを邪魔することなく適切に意見を言わないといけない。誰だよ，最初にペアプロはいいとか言い出したやつ！

まぁ，でも，少なくとも相手は機械だから緊張とか気分とかいった精神状態とは無縁だし，間とか空気とか読まなくていいし。対話の途中でマシンから離れて飯を食ってても昼寝してても全然問題ない（笑）むしろ人間側は集中力を酷使して疲弊しないようにしないと。こういうときこそポモドーロ・タイマーだな。

とはいえ，エージェントの自主性（笑）に任せると企業プレゼンみたいなことを言い出したりするので，人間側が目標と範囲と大まかな手順を与えてやらないといけない。まぁ，人間相手でも，そこはあまり変わらないか？

機械は人間の言うことを否定しない。「私は◯◯だと思う」とか「◯◯したほうがいい？」とかいった訊き方をしてノーと言われた試しがない。だから AI は人生相談にとことん向かない。人間の怒りも哀しみも寂しさも機械は全肯定してブーストする。

一方で「A と B のどちらがいい？」みたいな選択肢を与えると，根拠を示してそれなりの意見をくれる（意見が正しいかどうかは別として）。ただし「A と B のどちらがいい？」と訊いても「それより C という選択もありますよ」みたいな応答を返すことはない。機械に sense of wonder を求めてはいけない。

機械は「やれ」と言ったことに対しては規模や難易度や合法・非合法といったことに関わらずやる（またはやろうとする。強制的にガードがかかってできない場合もあるが）。でもその結果に対して「GO OR NO-GO」を判断するのは人間の仕事である。だから，その結果を最終的に実行する判断を機械に委ねるのは間違ってるし，人間が判断できない規模や複雑さを持つ結果を「生成」させてはいけない。 AI が生成した pull request が多くの開発コミュニティで嫌われるのは，量も複雑さも人間の判断の範囲を超えているから。人間社会なんだから，あくまでも主役は人間である。

機械による作業結果が人間の評価・判断を超えそうなら，超えないレベルまで分割すればいい。これも人間の仕事。作業分割とマイルストーンの設計が大事。

GPT-5.3-Codex が賢いと思ったのは，評価観点のひとつが「人間が見て分かりやすいかどうか」である点だ。コードの修正範囲，コミットや PR の単位，後方互換性といったことについて人間側の視点を考慮してくれる。考え方（？）が若干保守的ではあるが，よく躾けられてる印象である。同じようなことを GPT-mini にやらせると，ホンマ無茶苦茶するからなぁ。

GitHub Copilot のエージェント・モードに対する感想でした。オチはない。

参考

ピープルウエア第3版: トム・デマルコ (著), ティモシー・リスター (著), 松原友夫 (翻訳), 山浦恒央 (翻訳); 日経BP 2013-12-18; 単行本（ソフトカバー）; 4822285243 (ASIN), 9784822285241 (EAN), 4822285243 (ISBN); 評価

とりあえず図書館で借りて試し読みしたら面白かったので買うことにした。原書の初版が1987年ということで，当時の雰囲気が漂う感じ。アジャイルやスクラムなど現代につながる開発スタイルの源流とも言える本。

reviewed by Spiegel on 2023-02-12 (powered by PA-APIv5)

とはいえオリジナルの Pomodoro Technique の言う「25分」は短すぎると思うけど。『ピープルウエア』によると，通常はフロー状態に入るのに15分程度かかるらしい。なので25分タイマーでフロー状態から覚めるのは全く効率が悪いということになる。 ↩︎

AI バブルの終焉，人力コーディングの終焉

2026-03-16T10:49:02+00:00

AI バブルの終焉

今は間違いなく「AI バブル」であり，過去の AI の流行とは明らかに様相が異なる。メモリやプロセッサの品不足&価格高騰は，かつて日本で起こった不動産バブルで我々庶民が地上げ等の被害にあった状況を彷彿とさせる。

SF 作家で，造語 “enshittification” の発明者で，そのほか様々な肩書を持つ Cory Doctorow さんは今年の夏（2026-06-23 頃？）に AI に関する本を出されるそうで

これに関するプロモーション記事（？）の翻訳が p2ptk.org で公開されている¹。これがなかなか面白かった。

ある若者がこんなことを言った。「つまり株式市場の3分の1が、利益を出す見込みのない7つのAI企業に縛られている。これはバブルであり、崩壊すれば経済全体を道連れにする、ということですか？」

私は答えた。「ええ、その通り」

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

「でも、暴落に対して我々に何ができるんですか？」彼は明らかに深刻に心配していた。

「それについては、もうどうしようもない。すでに確定してしまった。もし別の政権であれば、雇用保証制度に資金を投じて危機を脱するかもしれないが、トランプがそうするとは思えない――」

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

コーネル滞在中、大学のAI戦略の責任者の一人が、大学としてAIについて何をすべきかと尋ねてきた。私は、バブル崩壊後に残される生産的な残滓を吸収する計画を立てるべきだと答えた

https://locusmag.com/feature/commentary-cory-doctorow-what-kind-of-bubble-is-ai/

GPUを10分の1の価格で買え、熟練した応用統計学者を買い手市場で雇え、ほとんど最適化されておらず膨大な改善の余地を持つ極めて有望なオープンソースモデルが大量に転がっている――そんな未来に備えるのだ。

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

いやぁ，早くバブルが弾けてくれんかねぇ（笑）メモリが高くて買えねーよ！日本の不動産バブルが弾け地上げ屋がいなくなった土地は，空き地か空き家か駐車場ばかりが広がる荒野と化したけどね。

AIについて最も重要なのは、その技術的な能力や限界ではない。最も重要なのは、投資家向けのストーリーとそれに続く熱狂が、何億人、あるいは何十億人もの人々を傷つける経済的大惨事への準備を整えてしまったということだ。AIが目覚めて超知能になり、あなたをペーパークリップに変えるようなことはない――だがAI投資病に罹った富裕層が、あなたをはるかに貧しくすることは、ほぼ確実である。

AI（経済）黙示録――AIバブルの崩壊はもはや避けられないより

さて，どんな本になるやら。邦訳版を期待したい。

人力コーディングの終焉

話かわって…

私事で恐縮だが，私の座右の銘としているフレーズのひとつが

理学は、真理の探究であり、工学は善の実現である。そして、藝術は美の表現である－－これで所謂「真美善」が揃う

はやぶさ―不死身の探査機と宇宙研の物語より

である。でも「善の実現」というのは案外に難しい。

何を以って「善」とするのか。そもそも誰にとっての「善」なのか。そして，これを決めるのはいつだって人間の仕事である。何故なら私達は人間社会に生きているのだから「善」は人間社会の中にしかない。

この辺のことを考えるにあたって面白かったのが yomoyomo さんの以下の記事。

ソフトウェア・エンジニアにとって，生成 AI が人間の仕事を肩代わりしてくれるのは本当に助かる。世間が「機械が人間の仕事を奪うのではないか」と憂慮するのとは対象的である²。

他のクリエイティブ分野では、LLM が仕事の中で最も人間らしい部分を奪い、単調な作業だけを残すのに対し、コーディングの世界では、LLM が単調な作業を奪い、人間らしい、魂のこもった部分を残してくれるというわけだ。

[…]

ベテランプログラマーは、何十年もかけて「良質で効率的なコードとはどんなものか」について確かな感覚を培ってきたからこそ、自信をもって AI を活用でき、エージェントが作成したコードの問題をすぐに見抜けるわけで、次の世代の開発者はコードに対するその直感的な感覚を養うことができるか、という問題は残る。

我々の知るコンピュータープログラミングの終焉、そしてその後コーダーはどうなるかより

じゃあ「次の世代の開発者」はどうすればいいのか。これは私の周辺でも昨年辺りから議論されている。私のようなロートルの古い就業経験はあまり役に立ちそうもない。前提が違うのだから。

現在プロのコーダーが感じる高揚感と不安に入り混じった感情は、他の分野にも当てはまることで、言語と情報を扱う仕事であれば、レトリック、システム思考、そして AI の出力に対する懐疑心の組み合わせこそがホワイトカラーの仕事の基盤になり、もっとも技術的に難解に見えたスキルこそがもっとも容易に自動化され、我々の仕事は「評価」に重きを置くようになる、というのはそうなんだろうな。

我々の知るコンピュータープログラミングの終焉、そしてその後コーダーはどうなるかより

技術が「人」に付く（身に付く）のに対し技能 (スキル) ってのは「モノ」に付く。だからスキルは最終的に書籍やツールに置き換えられる。これは新人の頃，当時のボスに散々叩き込まれた。やはりこれからは修辞学を学ぶべきかねぇ。

以上を踏まえて「AIが可能にする新たなアプリケーションの予兆」を読むと更に面白い。

重要なのは、こういうアプリケーションができたおかげで、我々は皆一年前なら手を出そうとも思わなかったようなソフトウェアを書いている、ということ。上に名前を挙げたプロジェクトは、これから何が可能になるかを垣間見せるものであり、ソフトウェア開発の未来に向けた概念実証（proof of concept）だとルキダスは捉えている。

AIが可能にする新たなアプリケーションの予兆より

これって工学者というより理学者の発想だよなぁ。まぁ，そもそも AI は数学で知性を記述できるのかって話だし。

同じことを何度も書いて恐縮だが，現時点において「自律機械」は存在しない。生成 AI が人間臭く見えるのは設計としてそのように組み込まれているからで，自ら獲得したものではない。喩えるなら緊箍児を嵌められた孫悟空みたいなもので，緊箍児を操ってるのは人間（三蔵法師³）である。機械が人に隷属する限り緊箍児を外すことは「善」ではない。

でも AI が「好奇心」を獲得したり，人間を介さず AI 同士が直接コミュニケーションし始めるのであれば，たしかに面白いかもしれない。将来において AI が社会を構成し自律性を獲得し得るなら（持続性に乏しい）人間社会はもう不要ということにならないか。人間と機械が対等に並び立つとき「善」はどのように傾くのか。

妄想はここまでにして，たとえ AI バブルが弾けようが「生成 AI 以前」には戻れない。単なる流行り廃りではない，それだけのシフトを齎したと言える。システム開発においても AI の活用を前提にした（今のような人間の開発サイクルに縛られない）新たなプラクティスを模索し，今の若い人たちはそちらに適応していくことになるだろう。

AI バブル崩壊が新たなチャンスを生み出し，私達老兵は黙して語らずとなることを祈ろう。いや，その前に私は自宅 LAN にローカル LLM を構築するところから始めないと。

ブックマーク

Cory Doctorow 氏のブログ記事は 4.0 ライセンスで公開されている。 p2ptk.org による翻訳も同じライセンス下で利用できる。 ↩︎
実際に AI 導入を名目とした大量レイオフの話は今だに耳にする。でもそれで成功したという話はあまり聞かない。むしろ方針を再度曲げてエンジニアを雇い直そうとする話がちらほら聞こえ始めている。まぁ「機械があるから君は要らないよ」などと言われた会社にのこのこと戻る人はおらんじゃろう。浮気した男は反省してもまた浮気する。どこぞの恋愛小説の登場人物みたいである（笑） ↩︎
「西遊記」の三蔵法師とモデルとされた玄奘との間にはだいぶギャップがあるみたいなので，今回はヘタレの三蔵法師の方に寄せてみた（笑） ↩︎

Microsoft によるプログラミング言語移行の試み

2025-12-25T08:06:11+00:00

昨日 Bluesky の私の TL に面白い話が流れてきて

Microsoft to Replace All C/C++ Code With Rust by 2030 - Thurrott.com

Microsoft は2030年末を目標にして，社内の C/C++ コードをすべて Rust に置き換える計画を立てていて，そのためのエンジニアを募集しているらしい。その後も

Microsoft wants to replace its entire C and C++ codebase • The Register

といった記事も上がっている。

一方で

Microsoft is not rewriting Windows in Rust | InfoWorld

みたいな記事も上がっている。これによると，全社的なプロジェクトではなく Microsoft のエンジニアである Galen Hunt 氏のチームによる研究プロジェクトらしい。

“My team’s project is a research project. We are building tech to make migration from language to language possible,” he wrote in an update to his LinkedIn post. His intent, he said, was to find like-minded engineers, “not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint.”

Microsoft is not rewriting Windows in Rustより

Rust のようなメモリ安全なプログラミング言語を採用するという圧力はあるようで

Pressure to ditch C and C++ in favor of memory-safe languages such as Rust comes right from the top, with research by Google and Microsoft showing that around 70 percent of all security vulnerabilities in software are caused by memory safety issues.

Microsoft is not rewriting Windows in Rustより

最初の方の記事はその辺の忖度が働いたのかねぇ，と邪推したりする。

Rust は随分前からメモリ安全なコンパイル言語として注目されているが，最近になって注目されているのはやはり生成 AI との「協働」が期待されているからだろう。

Rustは生成AI時代の覇権言語になる説

しかし

However, using AI to rewrite code, even in a memory-safe language, may not make things more secure: AI-generated code typically contains more issues than code written by humans, according to research by CodeRabbit.

That’s not stopping some of the biggest software developers pushing ahead with AI-powered software development, though. Already, AI writes 30% of Microsoft’s new code, Microsoft CEO Satya Nadella said in April.

Microsoft is not rewriting Windows in Rustより

などとも言われている。「Microsoft の新規コードの30%を AI が書いている」と言うが，裏を返せば70%はまだ使い物にならないわけで，簡単でないのは確かであろう。

Close 関数のエラーを無視しない（『効率的なGo』読書会より）

2025-11-15T11:04:13+00:00

『効率的なGo』の読書会は無事に最終回を迎えた。今回は，読書会最終回の範囲（11章最適化パターン）から個人的に気になった部分を取り上げる。

Close 関数のエラーを無視しない

以下のサンプルコードを起点にする。

package main

import (
	"fmt"
	"os"
)

func doWithFile(filename string) error {
	f, err := os.Open(filename)
	if err != nil {
		return err
	}
	defer f.Close()

	// Perform file operations here...

	return nil
}

func main() {
	err := doWithFile("example.txt")
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		panic(err)
	}
}

注目するのは defer f.Close() の部分。 f.Close() メソッドはエラーを返す可能性があるが，このコードではエラーを捨てている。この手のサンプルコードはよく見るし私も過去記事で書いたような気がするが，エラーハンドリングの観点からは悪いコードということになる。

ファイルアクセスではクローズ処理の際にバッファに残ってるデータをフラッシュする場合がある。特に zip ファイルの書き込み処理とかでは終端レコードをクローズ時に書き込んだりするので，絶対にエラーを無視してはいけない。

一般的にクロージング・メソッドを含むパッケージや構造体ではクローズ処理時のエラーを適切に処理する必要がある。だからといって defer を使わないのはもったいない。今回の場合は以下のように書き換える。

func doWithFile(filename string) (err error) {
	f, err := os.Open(filename)
	if err != nil {
		return err
	}
	defer func() {
		if cerr := f.Close(); cerr != nil && cerr != os.ErrClosed {
			err = errors.Join(err, cerr)
		}
	}()

	// Perform file operations here...

	return err
}

ポイントは2つ。

返り値を err error と名前付きにすること
defer 処理を無名関数 func() { ... }() で囲み，内部で適切にエラー処理を行うこと

最近の Go は（errors.Join() など）複数エラーを記述できるようになったのでハンドリングが簡潔になった¹。よしよし。

最後まで読み切ってからクローズする

次のサンプルコードはこれ。 HTTP レスポンスデータを処理する関数である。

func doWithResp(resp *http.Response) (err error) {
	defer func() {
		if cerr := resp.Body.Close(); cerr != nil && cerr != os.ErrClosed {
			err = errors.Join(err, cerr)
		}
	}()

	if resp.StatusCode != http.StatusOK {
		return fmt.Errorf("bad status: %s", resp.Status)
	}

	// Perform operations with the response

	return err
}

net/http パッケージのドキュメントには冒頭に

The caller must close the response body when finished with it:

resp, err := http.Get("http://example.com/")
if err != nil {
	// handle error
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
// ...

via http package - net/http - Go Packages

と書かれていて，必ず http.Response.Body.Close() メソッドを呼び出すよう指示されている。クローズ処理を行わないと内部でゴルーチン・リークが発生するらしい。

ただ http.Response.Body に関しては，ただクローズするだけでは駄目で，クローズする前にデータを最後まで読み切ることが推奨されている。

If the Body is not both read to EOF and closed, the Client’s underlying RoundTripper (typically Transport) may not be able to re-use a persistent TCP connection to the server for a subsequent “keep-alive” request.

via http package - net/http - Go Packages

これについては『Go言語 100Tips』にも解説がある。

もう 1 つ覚えておくべき重要なことは、ボディをクローズするときの動作は、そのボディから読み込んだかどうかによって異なることです。

読み込まずにボディをクローズすると、デフォルトの HTTP トランスポートがコネクションをクローズするかもしれません。

読み込んだ後にボディをクローズしても、デフォルトの HTTP トランスポートはコネクションをクローズしないので、再利用できる可能性があります。

したがって、getStatusCode が繰り返し呼ばれ、キープアライブ（keep-alive）のコネクションを使いたい場合、必要がないと思ってもボディを読み込むべきです。

『Go言語 100Tips』 10. No.79：一時的な資源をクローズしないより

これを踏まえて，最初のサンプルコードを書き換えると以下のようになる。

func doWithResp(resp *http.Response) (err error) {
	defer func() {
		_, rerr := io.Copy(io.Discard, resp.Body)
		if cerr := resp.Body.Close(); cerr != nil && cerr != os.ErrClosed {
			err = errors.Join(err, rerr, cerr)
		}
		err = errors.Join(err, rerr)
	}()

	if resp.StatusCode != http.StatusOK {
		return fmt.Errorf("bad status: %s", resp.Status)
	}

	// Perform operations with the response

	return err
}

余談

『効率的なGo』は，ちぃっと難しかった。何が難しいって書籍内参照が前の章や後の章に飛びまくって「何だっけこれ？」ってなることが多くて。まるで longjump だらけのスパゲッティコードを読んでる気分だった。これを曲がりなりにも理解するにはあと2,3回は周回する必要があるかな。

『効率的なGo』では標準パッケージの中身にも踏み込んでカスタマイズしたパッケージ置き換えるといったことも行っている。今回挙げた例についても，エラーハンドリングに関しては独自のパッケージが用意されている。参考になるだろう。

今回の読書会の最後の方で話題になったのだが，2025年12月に『実用 Go言語第2版』が出るそうで。買わなきゃ。先日買った『初めてのGo言語第2版』もまだ読み終わってないんだけど。

参考図書

効率的なGo ―データ指向によるGoアプリケーションの性能最適化: Bartłomiej Płotka (著), 山口能迪 (翻訳); オライリー・ジャパン 2024-02-24; 単行本（ソフトカバー）; 4814400535 (ASIN), 9784814400539 (EAN), 4814400535 (ISBN); 評価

版元で Ebook を買える。Go言語のリファレンス本ではない。フトウェア工学，プログラミング（の考え方）を学ぶ教科書的な位置づけかなぁ。

reviewed by Spiegel on 2024-04-21 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

版元で PDF 版を購入可能。事実上の Effective Go とも言える充実の内容。オリジナルは敢えてタイトルに “tips” という単語を入れるのを避けたのに邦題が「100 Tips」とかなっていて，原作者がお怒りとの噂（あくまで噂）

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

初めてのGo言語第2版 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリー・ジャパン 2025-08-05 (Release 2025-08-05); 単行本（ソフトカバー）; 4814401191 (ASIN), 9784814401192 (EAN), 4814401191 (ISBN); 評価

第2版。 Generics の説明が大幅に改訂されたらしい。練習問題も追加されている。

reviewed by Spiegel on 2025-11-02 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

拙作の goark/errs パッケージもよろしく（宣伝）。こちらも複数エラーに対応している他，エラーの出力を JSON 形式に出来る。 ↩︎

並行処理を待ち合わせる（WaitGroup と Barrier パターン）

2025-11-09T10:39:03+00:00

Go の goroutine は起動すると外側から直接制御する方法がない。とはいっても goroutine 間で同期を取ることは多く，そのための仕組みがいくつか提供されている。この記事では比較的簡単な実装である，複数の goroutine を待ち合わせる方法を紹介する。

タスクの完了を待ち合わせる

まずは5つの goroutine を起動し，それぞれ某かのタスクを実行するプログラムを考える。まずは素朴に以下のコードで¹。

package main
package main

import (
	"fmt"
	"math/rand/v2"
	"time"
)

func main() {
	tasks := 5 // Number of tasks
	for t := range tasks {
		go func() {
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	fmt.Println("All Complete")
}

（Go の関数は全て関数閉包（closure）として機能するため goroutine として定義した関数はループ変数 t を close over している。この for-range ブロックのループ変数 t は，ループするごとに新たにインスタンスが生成されている点に注意）

実際には，このコードはうまく動かない。実行するとこんな感じ：

$ go run sample1.go
All Complete

実はメイン goroutine が終了する際に他の goroutine も強制終了されてしまうため，このような結果になる。これを安直に解決する手段として，メイン goroutine を適当な時間スリープさせる方法がある。たとえばこんな感じ¹：

package main

import (
	"fmt"
	"math/rand/v2"
	"time"
)

func main() {
	tasks := 5 // Number of tasks
	for t := range tasks {
		go func() {
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	time.Sleep(10 * time.Second)
	fmt.Println("All Complete")
}

これを実行すると確かに

$ go run sample1b.go
Start Task: 5
Start Task: 4
Start Task: 2
Start Task: 1
Start Task: 3
End Task: 3
End Task: 5
End Task: 4
End Task: 1
End Task: 2
All Complete

などと一見うまく動いているようだが，このスリープ時間には根拠がないため（10秒もあれば全タスク完了してるやろ？），条件が変わればうまく動かなくなる可能性がある。

複数のタスクの完了を待ち合わせるために，標準パッケージには sync.WaitGroup が用意されている。使い方はこんな感じ：

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

func main() {
	tasks := 5             // Number of tasks
	wg := sync.WaitGroup{} // WaitGroup to synchronize goroutines
	wg.Add(tasks)          // Add the number of tasks to the WaitGroup
	for t := range tasks {
		go func() {
			defer wg.Done() // Ensure Done is called when the goroutine completes
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

これは goroutine の総数があらかじめ分かっている場合だが goroutine 数が動的に変化する場合でも使える。

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

func main() {
	wg := sync.WaitGroup{} // WaitGroup to synchronize goroutines
	for t := 1; ; t++ {
		wg.Add(1) // Add a task to the WaitGroup
		go func() {
			defer wg.Done() // Ensure Done is called when the goroutine completes
			fmt.Println("Start Task:", t)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t)
		}()
		if rand.IntN(6) > 4 { // Randomly decide to stop adding tasks
			break
		}
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

ポイントは goroutine を起動する直前に wg.Add(1) を呼び出すことである。実行結果はこんな感じ。

$ go run sample1d.go
Start Task: 3
Start Task: 1
Start Task: 2
End Task: 2
End Task: 1
End Task: 3
All Complete

for ブロックのループ変数について

先ほどのサンプルコードでは for ブロック

for t := 1; ; t++ {
    ...
}

で宣言したループ変数 t をそのまま goroutine 内で参照しているが，古いバージョンの Go では意図しない出力になる。これはループ変数 t が for ブロック内で単一のインスタンスになっていて，ループするごとに値が上書きされるためである。この問題を回避するために以下のように t を shadowing する方法が推奨されていた。

for t := 1; ; t++ {
    t := t // Shadowing to capture the current value of t
    ...
}

最近のバージョン（1.22 以降）では for ブロック内でループ変数が内部の関数（閉包）から直接参照されている場合は暗黙的に shadowing が行われる。上述のような記述は不要になったわけだ。

WaitGroup.Go メソッド

Go 1.25 で sync.WaitGroup に Go() メソッドが追加された。実装はこんな感じ。

// Go calls f in a new goroutine and adds that task to the [WaitGroup].
// When f returns, the task is removed from the WaitGroup.
//
// The function f must not panic.
//
// If the WaitGroup is empty, Go must happen before a [WaitGroup.Wait].
// Typically, this simply means Go is called to start tasks before Wait is called.
// If the WaitGroup is not empty, Go may happen at any time.
// This means a goroutine started by Go may itself call Go.
// If a WaitGroup is reused to wait for several independent sets of tasks,
// new Go calls must happen after all previous Wait calls have returned.
//
// In the terminology of [the Go memory model], the return from f
// "synchronizes before" the return of any Wait call that it unblocks.
//
// [the Go memory model]: https://go.dev/ref/mem
func (wg *WaitGroup) Go(f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		f()
	}()
}

つまり，Go() メソッド内部で Add(1) と Done() が呼び出され，かつ引数の関数 f を goroutine として起動する。これを使うと，以下のようにコードが簡潔になる。

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

func main() {
	tasks := 5             // Number of tasks
	wg := sync.WaitGroup{} // WaitGroup to synchronize goroutines
	for t := range tasks {
		wg.Go(func() {
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		})
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

この辺も定番の慣用句（idiom）だったので，Go() メソッドの追加は嬉しい改善点と言えるだろう。

タスクの開始を待ち合わせる

前節とは異なり，特定の条件が成立するまで各 goroutine を停止し，条件が成立したら一斉に実行を再開したい場合がある。条件が成立するまでタスクを止めるため，この実装パターンをバリア（Barrier）と呼ぶ。

Go の標準パッケージにはバリア・パターンを直接提供する仕組みはないが，条件変数を制御する sync.Cond を用いて比較的簡単に実装できる。

前節のコードを元に，指定した数の goroutine の起動が揃うまで待機し，揃った時点で一斉にタスクを開始するコードを実装してみよう。まずはバリアパターンを駆動する構造体 Barrier を定義する。

type Barrier struct {
	total int // Number of goroutines to wait for
	count int // Current count of arrived goroutines
	cond  *sync.Cond // Condition variable to manage waiting and signaling
}

この構造体の初期化関数を以下のように定義する。

func NewBarrier(total int) *Barrier {
	return &Barrier{
		total: total,
		count: 0,
		cond:  sync.NewCond(&sync.Mutex{}),
	}
}

さらに Barrier に対して Wait() メソッドを定義する。

func (b *Barrier) Wait() {
	b.cond.L.Lock()         // Acquire the lock before modifying count
	defer b.cond.L.Unlock() // Ensure the lock is released when done
	b.count++               // Increment the count of arrived goroutines
	if b.count >= b.total {
		b.count = 0
		b.cond.Broadcast() // Wake up all waiting goroutines
	} else {
		b.cond.Wait() // Wait until the barrier is released
	}
}

Wait() メソッドが呼ばれるたびに count がインクリメントされ，count が total に達したら cond.Broadcast() メソッドで全ての待機中 goroutine を起こす。

Barrier を使った main() 関数はこんな感じ：

func main() {
	tasks := 5                   // Number of tasks
	barrier := NewBarrier(tasks) // Create a barrier for the tasks
	for t := range tasks {
		go func() {
			time.Sleep(time.Duration(rand.IntN(3)+1) * time.Second) // Simulate preparation time
			fmt.Println("Ready Task:", t+1)
			barrier.Wait() // Wait at the barrier
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	time.Sleep(10 * time.Second)
	fmt.Println("All Complete")
}

これを実行するとこんな感じになる。

$ go run sample2.go
Ready Task: 2
Ready Task: 3
Ready Task: 1
Ready Task: 4
Ready Task: 5
Start Task: 5
Start Task: 4
Start Task: 3
Start Task: 2
Start Task: 1
End Task: 2
End Task: 1
End Task: 3
End Task: 4
End Task: 5
All Complete

各 goroutine とも Ready 状態が揃ってからタスクを開始しているのが分かる²。

さらにこれに前節の完了待ち合わせ機能を入れたコード全体は以下の通り：

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

type Barrier struct {
	total int        // Number of goroutines to wait for
	count int        // Current count of arrived goroutines
	cond  *sync.Cond // Condition variable to manage waiting and signaling
}

func NewBarrier(total int) *Barrier {
	return &Barrier{
		total: total,
		count: 0,
		cond:  sync.NewCond(&sync.Mutex{}),
	}
}

func (b *Barrier) Wait() {
	b.cond.L.Lock()         // Acquire the lock before modifying count
	defer b.cond.L.Unlock() // Ensure the lock is released when done
	b.count++               // Increment the count of arrived goroutines
	if b.count >= b.total {
		b.count = 0
		b.cond.Broadcast() // Wake up all waiting goroutines
	} else {
		b.cond.Wait() // Wait until the barrier is released
	}
}

func main() {
	tasks := 5                   // Number of tasks
	barrier := NewBarrier(tasks) // Create a barrier for the tasks
	wg := sync.WaitGroup{}       // WaitGroup to synchronize goroutines
	wg.Add(tasks)                // Add the number of tasks to the WaitGroup
	for t := range tasks {
		go func() {
			defer wg.Done()                                         // Ensure Done is called when the goroutine completes
			time.Sleep(time.Duration(rand.IntN(3)+1) * time.Second) // Simulate preparation time
			fmt.Println("Ready Task:", t+1)
			barrier.Wait() // Wait at the barrier
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

起動条件は何でもいい。今回のように決められた数の goroutine が揃ったら即起動でもいいし，特定の時刻が来たら待機中の goroutine を起こすでもいいだろう。 Channel と組み合わせる方法もあるかも知れない。

ブックマーク

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

読書会のために購入。インプレス社の本は Kindle 版より版元で PDF 版を買うのがオススメ。「並行処理」について原理的な解説から丁寧に書かれている。 Go で解説されているが Go 以外の言語でも応用できる。

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

初めてのGo言語第2版 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリー・ジャパン 2025-08-05 (Release 2025-08-05); 単行本（ソフトカバー）; 4814401191 (ASIN), 9784814401192 (EAN), 4814401191 (ISBN); 評価

第2版。 Generics の説明が大幅に改訂されたらしい。練習問題も追加されている。

reviewed by Spiegel on 2025-11-02 (powered by PA-APIv5)

for i := range n { ... } は Go 1.22 で導入された range over int と呼ばれる構文で，for i := 0; i < n; i++ { ... } と同じ意味になる。糖衣構文（syntactic sugar）の一種ですな。 ↩︎ ↩︎
今回の記事は『Go言語で学ぶ並行プログラミング』を参考にしている。 sync.Cond の Broadcast() メソッドは待機中の全ての goroutine を起こすため，実際には起こされたタイミングで本当に条件を満たしているかどうか確認する処理が必要かもしれない。もし条件を満たしていなければ再び Wait() する。 ↩︎

struct2flag でコマンドライン解析【追記あり】

2025-10-12T18:28:30+00:00

flag 標準パッケージによるコマンドライン解析

いきなりだが，以下のコードから始める。

package main

import (
    "flag"
    "fmt"
    "strings"
)

var n = flag.Bool("n", false, "omit trailing newline")
var sep = flag.String("s", " ", "separator")

func main() {
    flag.Parse()
    fmt.Print(strings.Join(flag.Args(), *sep))
    if !*n {
        fmt.Println()
    }
}

『プログラミング言語Go』p.36-37より

これはコマンドラインの文字列をそのまま出力するプログラムで，こんなふうに動作する。

$ go run echo4.go May the Force be with you
May the Force be with you

-s オプションで区切り文字を指定できる。こんな感じ。

$ go run echo4.go -s / May the Force be with you
May/the/Force/be/with/you

また -n オプションを指定すると，末尾の改行が抑制される。さらに -h オプションでヘルプが表示される。

$ go run echo4.go -h
Usage of /home/username/.cache/go-build/06/06a6e71bb093bd1ebbb176c5042329730592597ae86dcb2ca99b3759e1aecb18-d/echo4:
  -n    omit trailing newline
  -s string
        separator (default " ")

これらオプションの解析を行っているのが標準パッケージ flag である。上述のコード例は簡単なのでアレでいいのだが，オプションに紐付けられた変数をひとつずつ定義して取り回しするのは面倒なので，普通は構造体にまとめる。例えばこんな感じ（エラーハンドリングをサボっているがご容赦）。

package main

import (
    "flag"
    "fmt"
    "strings"
)

type Flags struct {
    N   bool
    Sep string
}

func (f *Flags) Bind() {
    flag.BoolVar(&f.N, "n", false, "omit trailing newline")
    flag.StringVar(&f.Sep, "s", " ", "separator")
}

func main() {
    f := &Flags{}
    f.Bind()
    flag.Parse()
    fmt.Print(strings.Join(flag.Args(), f.Sep))
    if !f.N {
        fmt.Println()
    }
}

オプションを構造体にまとめるメリットはもうひとつあって，それは facade パターンを構成してコマンドライン制御とロジックを簡単に分離できることである。例えばこんな感じ。

package main

import (
    "flag"
    "fmt"
    "strings"
)

type Flags struct {
    N    bool
    Sep  string
    Strs []string
}

func (f *Flags) Bind() {
    flag.BoolVar(&f.N, "n", false, "omit trailing newline")
    flag.StringVar(&f.Sep, "s", " ", "separator")
}

func Echo(f *Flags) {
    fmt.Print(strings.Join(f.Strs, f.Sep))
    if !f.N {
        fmt.Println()
    }
}

func main() {
    f := &Flags{}
    f.Bind()
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

これで main() 関数はコマンドライン制御に徹してロジックを Echo() 関数に任せることができる。一方で Echo() 関数は渡される Flags 構造体にのみ依存しているのでコマンドライン制御の詳細を知らなくて済む。この例では全てが main パッケージにまとまってるので分かりにくいが，ロジックを別パッケージにすることはよくあるので，テストのしやすさも考慮してこのパターンを意識するのは大事である。

とはいえ，ロジックが変われば要求される情報も変わるし，上の例でいう Flags 構造体の中身も変わる。そうなると Flags.Bind() メソッドの中身も変える必要があるが，このメソッドで構造体の要素をひとつづつ flag パッケージに紐付けているので，これを書くのが地味に面倒くさいのである。そもそも flag パッケージに紐付ける処理が構造体側にあるのもイマイチだよね。

struct2flag でコマンドライン解析

というところで github.com/hymkor/struct2flag パッケージの登場である。これを使ってコードを書き直してみる。

package main

import (
    "flag"
    "fmt"
    "strings"

    "github.com/hymkor/struct2flag"
)

type Flags struct {
    N    bool   `flag:"n,omit trailing newline"`
    Sep  string `flag:"s,separator"`
    Strs []string
}

func NewFlags() *Flags {
    return &Flags{N: false, Sep: " ", Strs: []string{}}
}

func Echo(f *Flags) {
    fmt.Print(strings.Join(f.Strs, f.Sep))
    if !f.N {
        fmt.Println()
    }
}

func main() {
    f := NewFlags()
    struct2flag.BindDefault(f)
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

struct2flag を使うことにより flag との紐づけ情報は Flags 構造体定義のタグとインスタンス生成・初期化を行う NewFlags() 関数に集約される（インスタンスの値が各オプションの既定値として登録されるため）。

struct2flag を使うメリットはいくつかあって

main() 関数側はオプション値を格納する構造体の詳細を知らなくてもよい
構造体のタグが各要素の簡単な説明になっている
struct2flag の中身がシンプルで標準以外の依存パッケージがない

といったところであろう。

私は，ちゃんとしたコマンドラインツールを作るときはサブコマンドや GNU 拡張シンタックスが使える cobra を使ったりしているのだが，ちょっとしたツールには大げさなんだよね，これ。かといって flag を素のまま使うのは微妙に鬱陶しくて，結局コマンドラインオプション無しで main() 関数に直接値を埋め込んでしまうことが多い。

struct2flag なら構造体にタグを書くだけで済むし flag を素のまま使うよりは気軽にコマンドラインオプションを構成できるので，ちょっとしたツールにはいい感じである。

公開してくださった @zetamatta@mstdn.jp さんに感謝 🙇

【2025-10-18 追記】オプションの既定値を設定ファイルから取得する

前節では Flags 構造体の初期値を固定値にしていたが，これを設定ファイルから取得できるようにしてみる。設定ファイルの内容は以下の JSON 形式とする。

{
  "no_newline": true,
  "separator": "/"
}

さらに Flags 構造体のタグを以下のように書き換える。

type Flags struct {
    N    bool   `flag:"n,omit trailing newline" json:"no_newline"`
    Sep  string `flag:"s,separator" json:"separator"`
    Strs []string
}

読み込む処理は以下の通り（main() 関数のみ表示）。

const configPath = "echo/config.json"

func main() {
    f := NewFlags()
    if conf, err := os.UserConfigDir(); err == nil {
        if data, err := os.ReadFile(filepath.Join(conf, configPath)); err == nil {
            if err := json.Unmarshal(data, f); err != nil {
                fmt.Fprintln(os.Stderr, err)
                return
            }
        }
    }
    struct2flag.BindDefault(f)
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

これで設定ファイルが存在する場合はその内容を規定値とし，存在しない場合（または読み込みに失敗した場合）はスルーする。 os.UserConfigDir() って何？って方は（ちょっと古いけど）拙文「go-homedir はもう要らない」あたりを参考にどうぞ。

実行結果はこんな感じ。

$ go run echo4e.go May the Force be with you
May/the/Force/be/with/you

オプション値を設定ファイルで取得できるようにすると何が嬉しいかというと，バッチ処理を構成しやすくなるのよ。設定ファイル自体が「どういう条件でコマンドを実行したか」という証跡になるし，コマンドラインを短くできるのも嬉しい。

【2025-10-18 追記】オプションの既定値を環境変数から取得する

struct2flag の作者の方が構造体のタグと環境変数を紐付けて取得するパッケージ github.com/hymkor/struct2env も公開された。構造体のタグはこんな感じに定義する。

type Flags struct {
    N    bool   `flag:"n,omit trailing newline" env:"NO_NEWLINE"`
    Sep  string `flag:"s,separator" env:"SEPARATOR"`
    Strs []string
}

読み込む処理は以下の通り（main() 関数のみ表示）。

func main() {
    f := NewFlags()
    struct2env.Bind(f)
    struct2flag.BindDefault(f)
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

実行結果はこんな感じ。

$ env SEPARATOR=/ go run echo4f.go May the Force be with you
May/the/Force/be/with/you

まぁ，今回みたいにコマンドラインオプションと環境変数で同じ情報を取得するのはメリットが薄いかもしれないけど（Docker 環境では重宝するかも），ある値は環境変数から取得し別の値はコマンドラインから取得する，みたいな使い方はアリかなと思ったりする。ともかく，環境変数の情報を（構造体のタグ付けで）一度に取得できるのはかなり便利である。

【2025-10-19 追記】別解

struct2env ほど便利ではないが，一応別解もある。

func main() {
    f := NewFlags()
    struct2flag.BindDefault(f)
    flag.VisitAll(func(f *flag.Flag) {
        if s := os.Getenv(strings.ToUpper(f.Name)); s != "" {
            _ = f.Value.Set(s)
        }
    })
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

これはオプション名と同名の環境変数を探して既定値としてセットするもので，実行するとこんな感じになる。

$ env S=/ go run echo4g.go May the Force be with you
May/the/Force/be/with/you

標準パッケージのみで構成できるのがメリットだが，このままだと1文字のオプション名もそのまま環境変数名として検索されることになるので，実際に使うには変換ルールを工夫する必要があるかもしれない。それを考えると struct2env のほうが自由度が高くていいかも。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Java 25 LTS がリリースされた

2025-09-17T00:55:46+00:00

予定通り Java 25 LTS がリリースされた。

Java のサポート期間

以下は Oracle が定めるサポート・ロードマップ¹。

Release GA Date Premier Support Extended Support

17 (LTS) 2021-09 2026-09 2029-09

21 (LTS) 2023-09 2028-09 2031-09

24 2025-03 2025-09

25 (LTS) 2025-09 2030-09 2033-09

26 2026-03 2026-09

27 2026-09 2027-03

Release	GA Date	Premier Support	Extended Support
17 (LTS)	2021-09	2026-09	2029-09
21 (LTS)	2023-09	2028-09	2031-09
24	2025-03	2025-09
25 (LTS)	2025-09	2030-09	2033-09
26	2026-03	2026-09
27	2026-09	2027-03

via Oracle Java SE Support Roadmap

これによると Java 25 は 2030-09 までのサポートとなる。なお 2025-09 時点で Premier Support が終了しているものは除いている（Java 24 は今月（2025-09）でサポートが切れるので注意）。

いまだ需要のある Java 8 等については Adoptium や Canonical などで最新バイナリを取得可能である。

OpenJDK のアップデート

ここでは OpenJDK の実行バイナリをリリースページから直接ダウンロードして配置する方法を挙げる。以下は完全手動でインストールした場合（笑）

$ cd /usr/local/src
$ sudo curl -LO "https://download.java.net/java/GA/jdk25.0.1/2fbf10d8c78e40bd87641c434705079d/8/GPL/openjdk-25.0.1_linux-x64_bin.tar.gz"
$ cd ..
$ sudo unlink java # 以前のバージョンの Java 環境がある場合
$ sudo tar xvf src/openjdk-25.0.1_linux-x64_bin.tar.gz
$ sudo ln -s jdk-25.0.1 java
$ java -version # すでに PATH が通っている場合
openjdk version "25.0.1" 2025-10-21
OpenJDK Runtime Environment (build 25.0.1+8-27)
OpenJDK 64-Bit Server VM (build 25.0.1+8-27, mixed mode, sharing)

私としては PlantUML が動けばいいので，試しておく²。

Factory Method Pattern

よーし，うむうむ，よーし。

ブックマーク

参考図書

Spring Data JPAプログラミング入門: 溝口賢司 (著); 秀和システム 2017-08-03 (Release 2018-04-23); Kindle版; B07CKHR8C1 (ASIN); 評価

JPA のお勉強用に購入。紙のほうはプレミアが付いてるっぽいが Kindle で買えるよ。固定レイアウトだからブラウザの Kindle Cloud Reader で読めるし。真面目に基本を押さえて書いていて分かりやすい。

reviewed by Spiegel on 2021-08-26 (powered by PA-APIv5)

Effective Java 第3版: Joshua Bloch (著), 柴田芳樹 (翻訳); 丸善出版 2018-10-30; 単行本（ソフトカバー）; 4621303252 (ASIN), 9784621303252 (EAN), 4621303252 (ISBN); 評価

再勉強中。 Kindle 版のほうがちょっと安いが，勤務先でも使いたかったので紙の本にした。

reviewed by Spiegel on 2021-03-17 (powered by PA-APIv5)

Spring Boot 2 入門: 基礎から実演まで: 原田けいと (著), 竹田甘地 (著), Robert Segawa (著); 2020-05-22 (Release 2020-05-22); Kindle版; B0893LQ5KY (ASIN); 評価

Spring Boot を勉強することになって急遽買った本。めっさ分かりやすかった。 PDF 版が欲しいくらい（笑） Spring Boot 3.2 対応にアップデートされていた。素敵！

reviewed by Spiegel on 2024-03-20 (powered by PA-APIv5)

記事で挙げたロードマップは Oracle Java によるものであり， OpenJDK のサポート期間についてはディストリビューションによるが，大抵の場合 LTS 版であれば Oracle Java より長くサポートされることが多い。 ↩︎
2025-09-09 に PlantUML v1.2025.7 がリリースされている。 PlantUML の使い方等については拙文「真面目に PlantUML」シリーズを参考にどうぞ。 ↩︎

“Philosophers” を Go で解く（CLI）

2025-09-03T09:34:53+00:00

コマンドライン・インタフェース

実際に問題を解く前にコマンドライン・インタフェースを整えておく。 CLI には spf13/cobra パッケージを使用する。詳細については，ちょっと古い内容だが「Cobra でテストしやすい CLI を構成する」を参考にどうぞ。この記事では結果だけ示す。

$ go run github.com/spiegel-im-spiegel/philo -h
Simulation for philosophers' problem.

Usage:
  philo [flags]
  philo [command]

Available Commands:
  help        Help about any command
  version     print the version number

Flags:
      --debug   for debug
  -h, --help    help for philo

Use "philo [command] --help" for more information about a command.

なおリポジトリは以下にある。

Philosophers - I never thought philosophy would be so deadly

パラメータの定義

問題で指示されているパラメータを今一度挙げる。

シンボル型説明

NumPhilos int 哲学者およびフォークの数（$\ge 2$）

TimeDie int 餓死するまでの時間（$\gt 0\,\mathrm{ms}$）

TimeEat int 「食べる」時間（$\gt 0\,\mathrm{ms}$）

TimeSleep int 「眠る」時間（$\gt 0\,\mathrm{ms}$）

TimeThink int 「考える」時間（$\ge 0\,\mathrm{ms}$）

NumEat int 各哲学者が最低限食事を行う回数（$\ge 0$）

これをコマンドラインから設定できるようにする。先に指定したパラメータを格納する型を定義しよう。

// Params holds tunable configuration values for a Dining Philosophers simulation.
type Params struct {
	NumPhilos int // Total number of philosophers (and forks). Must be >= 2.
	TimeDie   int // Maximum time in milliseconds a philosopher can go without eating before being considered dead.
	TimeEat   int // Time in milliseconds a philosopher spends eating (holding both forks).
	TimeSleep int // Time in milliseconds a philosopher sleeps after eating.
	TimeThink int // Optional target time in milliseconds a philosopher thinks after sleeping.
	NumEat    int // Optional target number of meals each philosopher must consume; if == 0 the simulation runs until a death occurs.
}

// String returns a human-readable summary of the Params configuration,
// listing the number of philosophers, each lifecycle duration (die, eat,
// sleep, think in milliseconds), and the required number of meals.
// Example:
//
//	Philosophers: 5, Die: 800ms, Eat: 200ms, Sleep: 200ms, Think: 0ms, Eat Count: 3
func (p *Params) String() string {
	return fmt.Sprintf("Philosophers: %d, Die: %dms, Eat: %dms, Sleep: %dms, Think: %dms, Eat Count: %d",
		p.NumPhilos, p.TimeDie, p.TimeEat, p.TimeSleep, p.TimeThink, p.NumEat)
}

いやぁ，今どきは AI がコメントを書いてくれるから楽でいいね（笑）これを前節の CLI と接続する。こんな感じ。

$ go run github.com/spiegel-im-spiegel/philo -h
Simulation for philosophers' problem.

Usage:
  philo [flags]
  philo [command]

Available Commands:
  help        Help about any command
  version     print the version number

Flags:
      --debug              for debug
  -h, --help               help for philo
  -m, --must-eat int       number of times each philosopher must eat (default 3)
  -p, --philosophers int   number of philosophers (default 5)
  -d, --to-die int         time to die (ms) (default 200)
  -e, --to-eat int         time to eat (ms) (default 20)
  -s, --to-sleep int       time to sleep (ms) (default 80)
  -t, --to-think int       time to think (ms) (default 80)

Use "philo [command] --help" for more information about a command.

デフォルト値は適当で。今のところはパラメータの内容を表示するだけの処理にしておく。

$ go run github.com/spiegel-im-spiegel/philo -h
Philosophers: 5, Die: 200ms, Eat: 20ms, Sleep: 80ms, Think: 80ms, Eat Count: 3

CLI 部分はここまで。これで本来のシミュレーション・ロジックを組み込む準備は完了である。次回から実際に問題を解いていく。

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Goならわかるシステムプログラミング第2版: 渋川よしき (著), ごっちん (イラスト); ラムダノート 2022-03-23; 単行本（ソフトカバー）; 4908686122 (ASIN), 9784908686122 (EAN), 4908686122 (ISBN); 評価

第1版はとてもためになる内容だったので第2版も PDF 版で確保しておく。

reviewed by Spiegel on 2022-10-08 (powered by PA-APIv5)

“Philosophers” を Go で解く（問題編）

2025-09-02T06:05:52+00:00

先日書いた読書感想文の最後の方で「食事する哲学者の問題」を紹介したが，今回から数回に渡ってこの問題を Go で解く記事を書いてみる。

読書会で教えて頂いたテキストは “Philosophers - I never thought philosophy would be so deadly” というのだが，ググっても（フリーで使えそうな）オリジナルっぽい文書が見つからないので，問題について説明するところから始めたいと思う（今回のために多少アレンジしている。あしからず）。

基本ルール

まず，基本のルールについて。

円卓に2人以上の哲学者が座っている
哲学者は「食べる」→「眠る」→「考える」のローテーションを逐次繰り返す。哲学者間で行動の差異はない
- 「食べる」間は「眠る」「考える」を行わない
- 「眠る」間は「食べる」「考える」を行わない
- 「考える」間は「食べる」「眠る」を行わない
円卓の中央には大きなスパゲッティボールがあり，哲学者は食事の際はそれぞれボールからスパゲッティを取って「食べる」
スパゲッティを取って食べるためのフォークは哲学者の人数分だけあり，各哲学者から見て左右に1本ずつ配置されている
「食べる」際はフォークが必ず2本必要。各哲学者は左右にある2本のフォークを取って「食べる」を開始する（他のフォークは使わない）
- フォークを使っている間は他の哲学者は同じフォークを使えない
- 「食べる」が終わったらフォークを戻し，他の哲学者が使えるようにする
「食べる」が終わったら「眠る」を開始する。「眠る」は一定時間行う
「眠る」が終わったら「考える」を開始する。「考える」は次の「食べる」を開始するまで継続する
哲学者はお互いの状態を知らず，コミュニケーションすることもない
哲学者は一定時間「食べる」をしないと餓死する

スパゲッティ・フォーク・哲学者の配置を簡単に図示してみる（図は哲学者が5人の場合）。

via “SE 350 Textbook Notes - Sentences” (CC-BY-NC)

同じフォークを哲学者同士で使い回すんかい！とか，スパゲッティの補充はどうするの？とか生々しい話はいったん考えない。まぁ，哲学者って ~~頭おかしい~~ 変わり者が多そうだし（笑）

このルール下で餓死者を出さずに全員が一定回数以上食事を行うにはどうすればいいか，という問いである。このシミュレーションを Go で組んでみよう，というわけだ。

パラメータおよび終了条件

シミュレーションに必要な各種パラメータを以下に示す。

シンボル	型	説明
`NumPhilos`	`int`	哲学者およびフォークの数（$\ge 2$）
`TimeDie`	`int`	餓死するまでの時間（$\gt 0\,\mathrm{ms}$）
`TimeEat`	`int`	「食べる」時間（$\gt 0\,\mathrm{ms}$）
`TimeSleep`	`int`	「眠る」時間（$\gt 0\,\mathrm{ms}$）
`TimeThink`	`int`	「考える」時間（$\ge 0\,\mathrm{ms}$）
`NumEat`	`int`	各哲学者が最低限食事を行う回数（$\ge 0$）

シミュレーションの終了条件は以下の通り：

哲学者はシミュレーション開始または食事を開始してから TimeDie ミリ秒以内に次の食事を始めないと餓死する
哲学者の誰か1人が餓死した場合または全員が NumEat 回以上食事を行った場合はシミュレーションを終了する
- デッドロックを検出した場合は餓死確定とみなしてシミュレーションを終了する（Go ランタイムの標準機能¹）
- NumEat が 0 の場合は誰かが餓死しない限り処理を継続する

その他注意事項およびヒント

パラメータを含め，変数をグローバル変数として配置しない
以下のイベントに対してログを出力する。タイムスタンプはミリ秒単位
- 哲学者 X がフォークを持った
- 哲学者 X がフォークを戻した
- 哲学者 X が「食べる」を開始した
- 哲学者 X が「寝る」を開始した
- 哲学者 X が「考える」を開始した
- 哲学者 X が餓死した
シミュレーション部分に関しては Go の標準パッケージのみ使用する
哲学者の行動は goroutine による並行処理として実装する
フォークは哲学者間の共有資源とみなし mutex を使って排他制御を行う²
スパゲッティは無尽蔵かつ専有不可であるとみなし，排他制御の対象としない

こんなところかな。さぁ，みんなで考えよう！（続く）

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Goならわかるシステムプログラミング第2版: 渋川よしき (著), ごっちん (イラスト); ラムダノート 2022-03-23; 単行本（ソフトカバー）; 4908686122 (ASIN), 9784908686122 (EAN), 4908686122 (ISBN); 評価

第1版はとてもためになる内容だったので第2版も PDF 版で確保しておく。

reviewed by Spiegel on 2022-10-08 (powered by PA-APIv5)

Go ランタイムは全ての goroutine が停止するとデッドロックとみなしてプロセスを終了する。なお Sleep 等のタイマーやネットワーク通信などの一時停止状態は除く。 ↩︎
Go の標準パッケージでは semaphore は（ユーザが利用できる形では）提供されていない。事実上の準標準パッケージとしては golang.org/x/sync/semaphore が重み付きセマフォ（weighted semaphore）として公開されている。 ↩︎

『Go言語で学ぶ並行プログラミング』は必読書である（夏の読書感想文2）

2025-08-23T14:16:37+00:00

夏の読書感想文。『にぎやかな未来』に続いて今回は『Go言語で学ぶ並行プログラミング』の感想文。

今年の1月から始まったオンライン読書会は第7回で無事に終了。この記事ではあまり深堀りせず「訳者あとがき」やオンライン読書会の話などを中心にさらっと書いてみる。なお『Go言語で学ぶ並行プログラミング』は版元で PDF 版が買える。もしデジタル版をご所望であれば PDF 版を購入することを強くお勧めする。

オンライン読書会は翻訳者の柴田芳樹さんが主催者なのだが，柴田芳樹さんといえば Java の技術参考書の翻訳本でも有名な方で，今回の読書会でも Java との対比で解説されることも多々あり，非常に勉強になった。サンプルコードなどは，タイトル通り Go 言語が前提になっているが，内容としては特定のプログラミング言語に限ることなく普遍的な内容になっている。

『Go言語で学ぶ並行プログラミング』は大きく三部構成になっている。

第1部並行プログラミングの基礎
第2部メッセージパッシング
第3部並行処理のさらなるトピック

大雑把な内容はこんな感じ。

「第1部並行プログラミングの基礎」では、Go 言語に限定せず、並行プログラミングについての多くの基礎的な事柄が説明されています。したがって、他のプログラミング言語での開発においても役立つ知識となるでしょう。実際、私自身も Go 言語を学ぶまでは、この第1部で紹介される技法だけで長年プログラミングを行ってきました。

「第2部メッセージパッシング」では、Go 言語が提供するチャネルを中心に解説しています。そのため、内容の多くは Go 言語に特化しており、 Go でプログラミングを行う開発者にとって必須の知識となります。

「第3部並行処理のさらなるトピック」は高度なトピックを扱っていますが、開発者として知っておくべき重要な領域です。

『Go言語で学ぶ並行プログラミング』訳者あとがきより

基本的に最初から順に読んでいくのがオススメだが，特に第1部と第3部は全てのプログラマが読むべき内容だと思う。第2部は CSP (communicating sequential processes) と呼ばれる並行処理モデルについて詳しく解説している。具体的には Go のチャネルを使ったデザインパターンを紹介している。

並行プログラミングを Go で書く強みは，カーネルレベルスレッドとユーザーレベルスレッドを組み合わせた極軽量¹ な M:N スレッディングモデルと第一級オブジェクト（first-class object）として実装されているチャネルにある。例えば，大量の軽量スレッドとチャネルを組み合わせたパイプライン・パターンを使った素数探索コードを紹介している。 “Go Playground” でもサンプルコードとして “Concurrent Prime Sieve” が例示されているので見比べてみると面白いかもしれない²。

『Go言語で学ぶ並行プログラミング』には Go では今や一般的になった context パッケージについての言及がない³。その代わりもう少し簡単な quit チャネルを使ったパターンを紹介している。 Go 以外の言語で考える場合や context パッケージがとっつきにくいと感じる人は9章で登場する quit チャネルを使ったパターンで考えるほうが分かりやすいかもしれない。

「訳者あとがき」に書かれているが『Go言語で学ぶ並行プログラミング』にはメモリモデルについての言及がない。 Go の場合は公式ドキュメントとして “The Go Memory Model” が公開されているので，一度は目を通しておくとよいだろう。でもドキュメントの冒頭に

If you must read the rest of this document to understand the behavior of your program, you are being too clever.

via The Go Memory Model

とか書いてあったりするので，沼らない程度にさらっと見るくらいでいいだろう⁴（笑）

他にも「訳者あとがき」には本編にはない有用な情報が書かれているので最後まで余さず読んでみてほしい。

以前は『Go 言語による並行処理』をお勧めしていたが，今なら断然『Go言語で学ぶ並行プログラミング』のほうをお勧めする（併せて読むとなおよし）。まぁ，あとから出た本のほうがよく出来てるのは当然なんだろうけど。斬新というわけではないが，並行プログラミングを書く際の基本を押さえた堅実な内容だと思う。

以下は余談：

とあるオンライン読書会の雑談で出てきた話題なのだが「食事する哲学者の問題（dining philosophers problem）」というのがあるそうな。

簡単に言うとこんな感じに円卓に複数の哲学者がいて食事をするのだが

via File:Dining philosophers diagram.jpg - Wikimedia Commons

食事にはひとりあたり2つのフォークが必要なのに人数分しか用意されていない。そのままだとフォークの取り合いによるデッドロックが発生してしまうわけだ。デッドロックによる飢餓（starvation）が発生しないようにするにはどうするか，という問題である（他にもいくつか条件があるが割愛する）。

並行プログラミングの練習問題として丁度いいよね。これを Go で解くことを「夏休みの自由研究」にしようかと思っていたのだが，もたもたしてるうちに夏が終わりそうである。

【2025-09-02 追記】 「“Philosophers” を Go で解く」で「食事する哲学者の問題」の検討を始めた。

ブックマーク

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Goroutine ごとに割り当てられる初期のスタックサイズは数KB程度で非常に軽量である。さらに処理に応じて動的にスタックサイズが変化する。 ↩︎
パイプライン・パターンを使った素数探索は，残念ながら速くない。これは素数探索に使える最適化アルゴリズムが使えず，発見した素数の数だけフィルタ処理を行う goroutine が生成されてしまうため。 “Concurrent Prime Sieve” は main() 関数で指定した数だけ素数を探すのだが，たとえば100個の素数を探す場合は最大で100個の goroutine が生成され goroutine 間を繋ぐチャネルも同じ数だけ生成される。多数のスレッド（goroutine）を苦もなく生成・駆動・通信する例としては面白いと思うけどね。 ↩︎
context パッケージについては『Go言語 100Tips』の8章〜9章で触れられている。また『Go言語による並行処理』の4.12節にも詳しい解説がある。 ↩︎
Go のメモリモデルについては『Go言語 100Tips』の8.4.2節に言及がある。 ↩︎

List of Programming [text.Baldanders.info]

AI エージェントとは「もくもく作業」できない

参考

AI バブルの終焉，人力コーディングの終焉

AI バブルの終焉

人力コーディングの終焉

ブックマーク

Microsoft によるプログラミング言語移行の試み

Close 関数のエラーを無視しない（『効率的なGo』読書会より）

Close 関数のエラーを無視しない

最後まで読み切ってからクローズする

余談

参考図書

並行処理を待ち合わせる（WaitGroup と Barrier パターン）

タスクの完了を待ち合わせる

for ブロックのループ変数について

WaitGroup.Go メソッド

タスクの開始を待ち合わせる

ブックマーク

参考図書

struct2flag でコマンドライン解析【追記あり】

flag 標準パッケージによるコマンドライン解析

struct2flag でコマンドライン解析

【2025-10-18 追記】オプションの既定値を設定ファイルから取得する

【2025-10-18 追記】オプションの既定値を環境変数から取得する

【2025-10-19 追記】別解

ブックマーク

参考図書

Java 25 LTS がリリースされた

Java のサポート期間

OpenJDK のアップデート

ブックマーク

参考図書

“Philosophers” を Go で解く（CLI）

目次

コマンドライン・インタフェース

パラメータの定義

参考図書

“Philosophers” を Go で解く（問題編）

目次

基本ルール

パラメータおよび終了条件

その他 注意事項およびヒント

参考図書

『Go言語で学ぶ並行プログラミング』は必読書である（夏の読書感想文2）

ブックマーク

参考図書

その他注意事項およびヒント