List of Programming [text.Baldanders.info]

今日はいつ？ — goark/today v0.1.0 をリリース

2026-09-09T11:27:24+00:00

いまだにお役所関連の書類（の一部）は元号での記載を要求してくる。ほんで「今日って令和何年だっけ？」ってなる。今年ももう9月になるというのに和暦が覚えられないよ。

大抵は西暦-和暦変換表をググって確認するのだが，今回はちょっとキれた（笑）

やってらんねー！！！

というわけでコマンドで today って打ったら今日の日付を西暦と和暦で表示するようにした。

GitHub - goark/today: Show information for today: Show information for today. Contribute to goark/today development by creating an account on GitHub.

Go 製シングルバイナリのコマンドラインツールで Linux/Windows/macOS 用のビルド済みバイナリを用意している。

バイナリを PATH が通ってるディレクトリに放り込んで，こんな感じに使う。

$ today
2026-09-09 Wednesday
令和8年 (丙午) 9月9日 水曜日 (丙戌)

引数で日付を指定することもできる。

$ today 2019-04-30
2019-04-30 Tuesday
平成31年 (己亥) 4月30日 火曜日 (丁酉)

$ today 2019-05-01
2019-05-01 Wednesday
令和1年 (己亥) 5月1日 水曜日 (戊戌)

オプションはこんな感じ。

$ today --help
Usage of today

Usage:
  today [flags] [yyyy-mm-dd]

Flags:
  -a, --all-events          show all events information
      --debug               enable debug mode
      --event-file string   path to the event file (default "/home/username/.config/today/event.json")
  -h, --holiday             show holiday information
  -j, --json                output information in JSON format
  -e, --other-events        show other events information
  -s, --solar-term          show solar term information
      --temp-dir string     path to the temporary directory (default "/home/username/.cache/today")
  -v, --version             show version information

たとえば，以下のように -h オプションを付けて祝日を表示する。

$ today -h 2026-09-23
2026-09-23 Wednesday
令和8年 (丙午) 9月23日 水曜日 (庚子)
秋分の日

他のオプションは以下の通り¹。

	意味
`-h, --holiday`	祝日・休日を表示
`-s, --solar-term`	二十四節気＋雑節および朔望月を表示
`-e, --other-events`	その他のイベント情報を表示（イベントファイルで定義）
`-a, --all-events`	すべてのイベント情報を表示

イベントファイルは --event-file で指定できる（指定がない場合はデフォルトのファイルを開こうとする）。イベントファイルが見つからない場合はイベント情報がないものと見なす。

たとえばイベントファイルの中身が

[
  {
    "start": "2026-09-25",
    "end": "2026-09-25",
    "title": "中秋の名月"
  }
]

であれば

$ today -e 2026-09-25
2026-09-25 Friday
令和8年 (丙午) 9月25日 金曜日 (壬寅)
中秋の名月

という感じに表示される。

んー。作ったはいいけど，あまり使わんか？でもイベントファイルは色々と使い道がありそう？そういえば CSV や JSON などのテキストデータを SQL で操作するパッケージがあったな。

面白そうだし，ちょっと検討してみようかな。

今回もあまり AI のお世話にならず（初期ファイルの配置とレビューとドキュメントは AI にやってもらった）楽しくコードを書いて遊んだ。ちょっとは気が済んだかな（笑）

参考

プログラミング言語Go - 丸善出版理工・医学・人文社会科学の専門書出版社: 明解で効率的なプログラムを描くための書。柴田　芳樹訳; Release 2016-06-15; 評価

[Comment] 著者のひとりは，あの “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

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

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

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

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

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

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

祝日・休日，二十四節気＋雑節，朔望月の情報は国立天文台のデータから取得している。 ↩︎

Go 1.27 のリリース

2026-08-30T05:40:23+00:00

先日 Go 1.27 がリリースされた。

個人的には encoding/json/v2 が（実験的実装じゃなくて）正式にリリースされたことが注目点かな。今はじっくり検証する暇がないので，とりあえずブックマークのみ載せておく。

go fix コマンドについては手持ちのパッケージで一度試したほうがいいかもなぁ。

参考図書

プログラミング言語Go - 丸善出版理工・医学・人文社会科学の専門書出版社: 明解で効率的なプログラムを描くための書。柴田　芳樹訳; Release 2016-06-15; 評価

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言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス 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)

我々は何者か？ — 『我ら、プログラマー』オンライン読書会第1回目

2026-08-22T09:06:11+00:00

技術書読書会にて，今日から新しい本の読書会が始まった。

第1回『我ら、プログラマー』オンライン読書会 (2026/08/22 13:00〜): ### 書籍『我ら、プログラマー』をオンラインで読む読書会です。 * 毎月1回開催します。 * 読書会なので、書籍を読んでいきます。 * 基本的に（紙の本の）ほぼ1頁単位で、参加者に読んでもらいながら、内容に関して必要に応じて議論する形式で進めます。 * 書籍『我ら、プログラマー』（Amazon）は、各人で購入してください。 ### オンライン開催について * Zoomを使って開催しますので、参加者がZoomを各人のPCやタブレットなどに事前に準備をお願いします。 * Zoomへの参加URLは、connpassの参加者へのメッセージ送信機能を使ってメールで送...

ターゲットとなる書籍はこれ。

我ら、プログラマー　AdaからAIまで、コーダーたちの年代記 | ZEN大学出版会: 我ら、プログラマー　AdaからAIまで、コーダーたちの年代記について、詳細・ご購入はこちらから; Release 2026-06-29; 評価

[Comment] 「ボブおじさん」による最新刊？かな。2世紀以上に渡るコンピュータとプログラマの歴史と回顧録。気楽な読み物として楽しめる。デジタル化希望！

ボブおじさん（Uncle Bob）こと Robert C. Martin 氏の最新著作？でいいのかな。原書 “We, Programmers” は2025年出版とある。ちなみに奥付に「Pearson は、コンテンツ制作の支援を含め、 AI を使用しています」と書いてある（Pearson Education, Inc. は原書の出版社）。日本語版は紙の本のみ出ている。目次を除いて315頁ほどだが，文字が詰め詰めで見た目よりボリュームがある。

今の人数だと1年以上（もしかして2年？）かかるかもって話も出てるので，興味のある方は次回以降，ぜひご参加を（笑）

我々は何者か？

『我ら、プログラマー』は4部構成で，第1部は第1章の「我々は何者か？」のみ。ということで，今回は第1部をさくっと読み終えた。

「プログラマって何？」というのはかなり根源的な問いで，当事者を抉る言葉だよね。

プログラマの最初期、プログラマは目に見えない存在だった。注目されていたのは、コンピューターとその大いなる可能性だった。脚光を浴びていたのは、機械とそれを作った人々だった。機械を動かすだけのプログラマーにはだれも注目していなかった。我々は単なるバックグラウンドノイズだった。

『我ら、プログラマー』第1章 p.31より

たとえば，プログラマは EC サイトのコードを書くことはできるが，経済学者ではないし，商品の専門家でも物流や通貨の専門家でもない（逆はあるかもだけど）。家電や自動車の制御コードは書けるが，家電や自動車の専門家ではない。

セキュリティの専門家ではないし，法律の専門家でもない。裁判官ではないし，政治家や官僚でもない。数学者でも科学者でも工学者でもないし，心理学者でも文学者でも哲学者でもない。

じゃあ，プログラマって何やねん？

では、質問を変えよう。我々はなぜ必要とされるのか？我々の仕事になぜ報酬が支払われるのか？報酬を支払う人たちは、なぜ自分でやらずに我々に仕事を依頼するのか？

『我ら、プログラマー』第1章 p.32より

これに関連して，私たちプログラマについての以下の考察が面白かった。

我々は詳細を愛する。我々は詳細を楽しむ。我々は詳細の川を上流へ泳ぐ。我々は詳細の沼を苦労しながら進む。我々はそれを愛している。我々はそのために生きている。我々は喜び満ちて賢明に取り組む。我々は……詳細の管理者である。

『我ら、プログラマー』第1章 p.33より

ここに私たちの存在理由のヒントがある。

再度、問いたい。我々はなぜ必要とされるのか？なぜならば、社会には詳細のことを気にかけずにはいられない人々が必要だからだ。

[…]

大多数の人々が詳細から逃げ出す限り、詳細に向かって走る我々のことを必要とするだろう。それが我々なのだ。我々は全世界のための詳細の管理者である。

『我ら、プログラマー』第1章 p.35より

でも社会は「詳細の管理者」を余計な存在と考える。

長年にわたり、我々は必要悪だった。経営幹部やプロダクトマネージャーは、プログラマーが不要になる日を夢見ていた。それには理由があった。機械の能力と性能が成長し続けていたからだ。ほんの少しの成長ではない。桁違いの成長だ。

だが、プログラマーを不要とする社会の夢は実現しなかった。それどころかプログラマーの必要性が減少することはなかった。むしろ機械のパワーに追いつくために、その必要性は増加するばかりだった。

『我ら、プログラマー』第1章 p.32より

そもそも「人月」の発想がプログラマを（人材ではなく）コストとする考え方だからね。

でもこれって，最近もどこかで聞いた話だよね。そう，企業経営者による「AI でプログラマは不要になる」という話だ。

現在、彼らは AI が新しい解決策になると考えている。だが、私を信じてほしい。結果は同じだ。パワーが大きくなればなるほど、プログラマーの必要性と地位は高まるばかりである。

『我ら、プログラマー』第1章 p.32より

ボブおじさんによると，プログラマはなくならないらしいっスよ（笑）まぁ，組織内の役回りは変わるかも知れないけどね。

というわけで，つかみはOKということで。第2部は19世紀の「バベッジの階差機関」から始まる（実はちょっとだけ読み進めている）。

参考

Clean Architecture 達人に学ぶソフトウェアの構造と設計 | ZEN大学出版会: Clean Architecture 達人に学ぶソフトウェアの構造と設計について、詳細・ご購入はこちらから; Release 2026-07-10; 評価

[Comment] 実務に即効性があるわけではないが，ものの「考え方」を示す本としてはよく出来ている。ソフトウェア技術史の読み物としても面白い。デジタル化希望！

「おもしろい技術書」

2026-07-28T06:06:01+00:00

またまた Bluesky で見かけたネタだが，「おもしろいと思った技術書教えてください」に対する結城浩さんの回答が面白かった。

おもしろいと思った技術書教えてください | mond

そういや，子どもは夏休みに入ってるんだよね。読書感想文に悩む季節ですなぁ。これは度々書いてるけど，私は小学生の時に学習参考書の読書感想文を書いて，市のコンクールで賞をもらった男です。どやっ！

というわけで，個人的に面白いと思った技術関連本をいくつか挙げてみる。子どもが読んでも全然構わないけど，たぶん子ども向けではないのであしからず。

K&R

結城浩さんの回答にもあった『プログラミング言語C』がこれ。

プログラミング言語C - 共立出版: Brian W.カーニハン著; Release 1989-06-15; 評価

[Comment] 通称 “K&R”。初版当時のプログラマには「バイブル」と呼ばれた名著。現在は ANSI 準拠の第2版。

原著者の頭文字を取って “K&R” と呼ばれたりする（著者のひとりである Dennis M. Ritchie さんは C 言語の作者でもある）。現在は C 言語の規格バージョンも ISO/IEC 9899:2024 (C24) まで進み K&R よりも優れた技術参考書がたくさんあるが，当時は国際規格すらなく C 言語の教科書と言える本は殆どこれだけで，それ故に「バイブル」などと呼ばれてもいた。

私は真面目にプログラミングを習ったのが IT 業界に入ってからで¹ しかもアセンブラからの入門だったので，初めて C 言語を習ったときは「なんて素晴らしい言語なんだ」と感動したものである。特に感動したのがポインタ演算。たとえば char 型のポインタ変数をインクリメントしたときと short 型のポインタ変数をインクリメントしたときで，ポインタ値の増分が異なるんだよ。凄くね！

同じく Brian W. Kernighan さんによる『カーニハンのUNIX回顧録』に C 言語が誕生した経緯や『プログラミング言語C』執筆当時の話が載っている。

デニスに本作りに関わってもらうようにしたことは，私の技術的な経歴において最も賢明で，あるいは最も幸運なことだった．デニスが共著者となり，彼のリファレンスマニュアルを含めることができたため，本は信頼のおけるものとなったのである．

[…]

本文のテキストは何度も互いにやり取りしたため，二人の文体は融合しているが，リファレンスマニュアルは，デニスの文章の純粋な見本として，ほぼ元あったままにした．この部分は，かつてビル・プラウガーが評した「ぞくぞくするような精密さ」をもって言語を解説している．リファレンスマニュアルは，Cそれ自身のように，正確で，洗練され，簡潔である．

『カーニハンのUNIX回顧録』第4章 p.86より

プログラミング言語の技術参考書を探すときに苦労するのが，言語の使い方を解説したものは多くあるのに言語そのものを解説した本は少ないということだ。どんな言語であれ，プログラミング言語にはそれぞれ作者の思想が根底にあり，それに基づいて言語仕様上の制約が課せられている。これを理解しないと次のステップ（イディオムとかライブラリ・フレームワークとか）に進めないと思う。

プログラミング言語 Go

プログラミング言語Go - 丸善出版理工・医学・人文社会科学の専門書出版社: 明解で効率的なプログラムを描くための書。柴田　芳樹訳; Release 2016-06-15; 評価

原著者の一人は前節で紹介した Brian W. Kernighan さんである。 Go 言語そのものについて丁寧かつ誠実に書かれた良書であるが，残念ながら内容が古くなってしまった。しかも日本語版は絶版状態らしい。改訂版の予定はないとのこと。

Go 言語は非常にシンプルな言語で，いまだに言語固有のキーワード（予約語）が25個で変わらない。

The following keywords are reserved and may not be used as identifiers.

break        default      func         interface    select
case         defer        go           map          struct
chan         else         goto         package      switch
const        fallthrough  if           range        type
continue     for          import       return       var

via The Go Programming Language Specification - The Go Programming Language

言語仕様全体も1枚の Web ページに収まる分量である。言い方を変えると，このシンプルさ（を保つこと）こそが Go 最大の制約なのである。

私は仕事では様々なプログラミング言語を変遷しているが「母国語」と言えるものは C 言語だった。でも Go 言語を知って以降「母国語」が Go 言語になった。五十路に入って「母国語」が変わるとかそうそうないだろう。

そうなったのも『プログラミング言語Go』の影響が大きいと思っている。そのくらい私にとってインパクトのある本である。

デザインパターン本

Java言語で学ぶデザインパターン入門第3版 | SBクリエイティブ: 「GoF」の『デザインパターン』で紹介された23個のパターンを、オブジェクト指向の初心者にもわかるようにやさし; Release 2021-11-13; 評価

[Comment] なんと！結城浩さんのデザパタ本の第3版が出た。古典的な GoF のデザインパターン23個はそのままに，最近の Java の言語仕様に合わせてコードが一新されている。

いわゆる Gang of Four（GoF）による古典的なデザインパターンを解説した本である。ちなみに，結城浩さんのデザパタ本にはマルチスレッド編もある。

原典の翻訳本もあるが，結城浩さんの著書はどれも平易な文章で読みやすくお勧めである。

Java を前提に書かれているが，もちろん他の言語でも応用できる。デザインパターンでググったら様々な言語で実装している例が見つかると思う。

ただし古典なだけあって，今では使わないほうが良いとされるパターンがあったり，言語によっては実装が難しいものもある。

Go 言語で Factory Method Pattern を構成できるか

先日『実用 Go言語第2版』の読書会で

なお、昔は GoF のデザインパターンに取り上げられたこともあり、テンプレートメソッドパターンが王道とされてきましたが、このパターンを使うには、必ずサブタイプを実装しなければなりません。近年では、クロージャやラムダといった要素を備えた言語が増えています。C++ も C++11 からクロージャが使えるようになり、GUI フレームワークの Qt も、関数オブジェクトでハンドラーが記述できるようになりました。このストラテジーパターンへの移行は Go に限らず、プログラミング言語の全体的な流れと言えます。

『実用 Go言語第2版』3章 p.83より

という記述があって「GoF って知ってる？」という話からデザパタ本の話になった。デザパタ本って GoF 版をベースにしているせいか出版年がどれも古くて，若い人だと知らなかったりするんじゃないだろうか。

とはいえ Iterator とか Factory とか Proxy とか Decorator とか Adapter とか… 今でもよく目にする（けど初見で面食らう）単語も多いので，読んでおいて損はないと思う。

その他の読み物

これは技術参考書と言うより読み物に近いかな。

Clean Architecture 達人に学ぶソフトウェアの構造と設計 | ZEN大学出版会: Clean Architecture 達人に学ぶソフトウェアの構造と設計について、詳細・ご購入はこちらから; Release 2026-07-10; 評価

いつの間にか発行元がZEN大学出版会に変わっとるがな。 ASCII 版は Kindle 版が引き上げられてて絶版になってるのか？慌てて私の Kindle ライブラリの中を見たが，既に買っているものはまだ見れるようだ。そのうち読めなくなるのかね。理工系の本でデジタル版がないとかありえないのだが。

中身は良書。原著は2017年に出版されている。

「明日から Clean Architecture で実装するぞ」とはいかないと思うけど，ものの「考え方」を示す本としてはよく出来ていると思う。「構造化プログラミングとかオブジェクト指向とか関数型とかって何？」ってあたりから SOLID などの原則の説明まで一通り網羅されていて用語の勉強にもなるだろう。回顧録みたいにもなってるので，ソフトウェア技術史の読み物としても面白い。

ちょうぜつソフトウェア設計入門 | 技術評論社: SoftwareDesign誌での連載と技術アドベントカレンダー24回ぶんに収まらなかった関連知識を徹底解説。いわゆる「オブジェクト指向」と呼ばれる考え方から発展した分野は、どのようにソフトウェア設計の役に立つのかを、よく知られた原則、テスト駆動開発、デザインパターンなどを通じて理解できる一冊です。上級者には定番の知識を体系的に整理するヒントとして、初級者には可愛いイラストで覚えるキーワード集として、幅広く活用していくことができます。なお、サンプルコードはPHPで書かれていますが、他の言語に置き換えて読めるコードばかりです。PHPを使っているかどうかを問わず、全ての開発者にオススメです。; Release 2022-12-07; 評価

[Comment] 祝♪ #ちょうぜつエンジニアめもりーちゃん単行本化！絵は可愛いが読み応えあり。「SoftwareDesign」連載分も収録されていて超お得！

𝕏 を見なくなったのだが，めもりーちゃんの更新は細々と行われているようだ。

初っ端がマンガなので面食らうが，中身は割とハード。技術系の読み物としてお勧めである。版元でなら PDF で買えるし（←重要）。

前節でちょろんと紹介した Template パターンと Strategy パターンの比較の話も載っている。

ブックマーク

「読書感想文は、ただちに「面白かった本のお勧め文」に名目を変えるべき」ではない

参考

カーニハンのUNIX回顧録 - 丸善出版理工・医学・人文社会科学の専門書出版社: Unixとは何であり，どのように生まれ，なぜ重要なのかを説明する，コンピュータ史上でも特に生産的だった形成期の素晴らしい物語ブライアン・カーニハン著; Release 2025-09-24; 評価

実用 Go言語第2版: 文法はシンプルで学びやすいという特徴を持つGo言語。システム開発の現場でも使われる機会が増えていますが、複雑な要件を実現するにはプログラミング言語が提供するシンプルな構成要素（文法やライブラリ）を、さまざまに組み合わせます。本書は「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点からGoを使うポイントを紹介します。構造体やインタフェース、またJSON、CSVファイル、Excel、固定長ファイルの扱い方、ログやテスト、環境構築など、また初版の発行後、Goに追加されたジェネリクスについても紹介。現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」を、その背景と共に教えてくれる先輩のような書籍です。; Release 2025-12-01; 評価

最初に入った会社の3ヶ月研修で情報処理1種資格相当の座学とアセンブラと C 言語を叩き込まれた。一応，学生時代に BASIC と Fortran は習ったが，お遊び程度だったと言っておこう。 ↩︎

バージョンの埋め込みと表示

2026-07-17T09:15:52+00:00

まずは，こんな感じにバージョン情報を表示するコードを考える。

package main

var Version = "v1.2.3"

func main() {
    println(Version)
}

これを実行すれば v1.2.3 と表示される。

実際の運用としてバージョンが上がるたびに変数 Version の内容を書き換える必要がある。また Git でソースコード管理する場合はリリースバージョンに対してバージョンタグを付けることが多いので，それとの整合を保つ必要がある。実はこれが割と煩雑な作業なのである。

そこで Go でビルドしたツールのバージョン表記について，以下の2つの方法を記しておく。

ビルド時にバージョン文字列を埋め込む

これは割と昔からある方法で， go build コマンドの -ldflags オプションを使って変数に値を埋め込む。

$ go build -ldflags="-X main.Version=v9.9.9" -o a.out

$ ./a.out
v9.9.9

Git でバージョンタグを打っている場合は

$ go build -ldflags="-X main.Version=`git describe --tags`" -o a.out

などと Git コマンドの出力を埋め込む手もある（bash シェルの場合）。

もしビルドに GoReleaser を使っているのであれば .goreleaser.yml の中で

builds:
-
  ldflags: -X main.Version=v{{ .Version }}

のように書くことで対応できる。

GoReleaser はマルチプラットフォームのコマンドラインツールで，複数プラットフォーム向けの実行バイナリを一度に作ってくれるので重宝している。また GitHub Actions にも対応していて，ビルドしたバイナリを GitHub Release に自動でアップロードし，リリースノートまで書いてくれる。ホンマ助かる。

ただし，この方法は go install では使えないし，そもそもユーザに「go build 時に -ldflags でバージョンを埋め込んでね」とお願いするのもおかしな話である¹。

ビルド情報を表示する

これは Go 1.18 から追加されたらしいのだが runtime/debug パッケージの ReadBuildInfo() 関数を使うと，ビルド時の情報を取得できる。たとえば，こんな感じ。

package main

import "runtime/debug"

var Version = ""

func replaceVersion(v string) string {
    if v != "" {
        return v
    }
    if info, ok := debug.ReadBuildInfo(); ok {
        if info.Main.Version != "" {
            return info.Main.Version
        }
        var revision, dirty string
        for _, v := range info.Settings {
            switch v.Key {
            case "vcs.revision":
                revision = v.Value
            case "vcs.modified":
                if v.Value == "true" {
                    dirty = "+dirty"
                }
            }
        }
        if revision != "" {
            return revision + dirty
        }
    }
    return "(version not set)"
}

func main() {
    println(replaceVersion(Version))
}

debug.ReadBuildInfo() 関数の返り値である BuildInfo 構造体の内容は以下の通り。

type BuildInfo struct {
    // GoVersion is the version of the Go toolchain that built the binary
    // (for example, "go1.19.2").
    GoVersion string `json:",omitempty"`

    // Path is the package path of the main package for the binary
    // (for example, "golang.org/x/tools/cmd/stringer").
    Path string `json:",omitempty"`

    // Main describes the module that contains the main package for the binary.
    Main Module `json:""`

    // Deps describes all the dependency modules, both direct and indirect,
    // that contributed packages to the build of this binary.
    Deps []*Module `json:",omitempty"`

    // Settings describes the build settings used to build the binary.
    Settings []BuildSetting `json:",omitempty"`
}

Module 構造体はこんな感じかな。

type Module struct {
    Path    string  `json:",omitempty"` // module path
    Version string  `json:",omitempty"` // module version
    Sum     string  `json:",omitempty"` // checksum
    Replace *Module `json:",omitempty"` // replaced by this module
}

つまり go.mod でモジュールとして定義・管理されている場合は BuildInfo.Main.Version にバージョンが入っている。

作成した replaceVersion() 関数を含むコードを Git で commit し v0.1.0 のバージョンタグを打った状態でビルド&実行すると以下のように表示された。

$ go build -o a.out && ./a.out
v0.1.0

ちなみに go.mod でモジュールとして定義されている場合でも，バージョン管理されていない場合は (devel) という文字列が返ってくるようだ。

$ go build -o a.out && ./a.out
(devel)

replaceVersion() 関数では BuildInfo.Main.Version で値を取れない場合には BuildInfo.Settings 配列から情報を取得している。 BuildSetting 構造体は以下の通り key-value 形式になっている。

type BuildSetting struct {
    // Key and Value describe the build setting.
    // Key must not contain an equals sign, space, tab, or newline.
    Key string `json:",omitempty"`
    // Value must not contain newlines ('\n').
    Value string `json:",omitempty"`
}

このうち Key には以下の値が入ってるらしい。

Key の値	Value の内容
`-buildmode`	the buildmode flag used (typically `"exe"`)
`-compiler`	the compiler toolchain flag used (typically `"gc"`)
`CGO_ENABLED`	the effective `CGO_ENABLED` environment variable
`CGO_CFLAGS`	the effective `CGO_CFLAGS` environment variable
`CGO_CPPFLAGS`	the effective `CGO_CPPFLAGS` environment variable
`CGO_CXXFLAGS`	the effective `CGO_CXXFLAGS` environment variable
`CGO_LDFLAGS`	the effective `CGO_LDFLAGS` environment variable
`DefaultGODEBUG`	the effective `GODEBUG` settings
`GOARCH`	the architecture target
`GOAMD64/GOARM/GO386/etc`	the architecture feature level for `GOARCH`
`GOOS`	the operating system target
`GOFIPS140`	the frozen FIPS 140-3 module version, if any
`vcs`	the version control system for the source tree where the build ran
`vcs.revision`	the revision identifier for the current commit or checkout
`vcs.time`	the modification time associated with `vcs.revision`, in RFC3339 format
`vcs.modified`	`"true"` or `"false"` indicating whether the source tree had local modifications

replaceVersion() 関数では VCS (Version Control System) のリビジョン情報（vcs.revision および vcs.modified）を使ってバージョンを表示している。ここまで至れり尽くせりなら，大抵のパターンで使えるだろう。

go run ではビルド情報がセットされない

以上は go build あるいは go install でビルドした場合の話だが go run で即時実行した場合はビルド情報がセットされないようだ。先程のコード例の場合は

$ go run main.go
(version not set)

と表示されビルド情報からバージョンを取得できなかったことが分かる。まぁ go run による実行でバージョンを気にする人はいないと思うので，これはこれで問題ないだろう。

ブックマーク

参考図書

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

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

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言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス 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言語第2版: 文法はシンプルで学びやすいという特徴を持つGo言語。システム開発の現場でも使われる機会が増えていますが、複雑な要件を実現するにはプログラミング言語が提供するシンプルな構成要素（文法やライブラリ）を、さまざまに組み合わせます。本書は「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点からGoを使うポイントを紹介します。構造体やインタフェース、またJSON、CSVファイル、Excel、固定長ファイルの扱い方、ログやテスト、環境構築など、また初版の発行後、Goに追加されたジェネリクスについても紹介。現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」を、その背景と共に教えてくれる先輩のような書籍です。; Release 2025-12-01; 評価

プロダクトによっては Makefile やビルド用のスクリプトを用意してるものもある。まぁ，大抵はそれなりの環境を用意しないとビルドできないことが多いのだが。 ↩︎

任意のイテレータを作る

2026-07-06T13:53:06+00:00

Go でイテレータを組む機会があったので，思い出しつつ，簡単なメモを残しておく。なお Go のイテレータは 1.23 から導入されている。

たとえば配列（または slice）や連想配列（map）であれば for-range 構文で以下のように書ける。

package main

func main() {
	nums := []int{1, 2, 3}
	for _, num := range nums {
		println(num)
	}

	planets := map[string]float64{
		"Mercury": 0.055,
		"Venus":   0.815,
		"Earth":   1.0,
	}
	for planet, mass := range planets {
		println(planet, ":", mass)
	}
}

配列や連想配列以外でも for-range 構文が使えれば何かと便利だろう。 Go ではこれを range over function という仕組みで実現している。

Range Over Function Types - The Go Programming Language

Range Over Functions

具体的には以下の3つの関数型を使う。

The improved for/range statement doesn’t support arbitrary function types. As of Go 1.23 it now supports ranging over functions that take a single argument. The single argument must itself be a function that takes zero to two arguments and returns a bool; by convention, we call it the yield function.
func(yield func() bool)
func(yield func(V) bool)
func(yield func(K, V) bool)

via Range Over Function Types

例として，3つの乱数を返すイテレータを作ってみよう。こんな感じかな。

package main

import "math/rand/v2"

func randoms(count int) func(func(int) bool) {
	return func(yield func(int) bool) {
		for range count { // range over int (from 0 to count-1)
			if !yield(rand.Int()) {
				return
			}
		}
	}
}

func main() {
	for n := range randoms(3) {
		println(n)
	}
}

強調部分がイテレータの本体である。これを実行すると，以下のような出力になる。

$ go run sample1a.go
27723168966634698
2343875658410196265
4739277610031835691

このように yield() 関数を呼び出した回数だけ for-range ループが回っていることが分かる。 yield() 関数は何をしているかというと，引数の値をループに push して，処理を継続する場合は true を返している。

ちなみに yield() 関数の返り値のチェックをサボるとどうなるかというと，たとえば

package main

import "math/rand/v2"

func randoms2(count int) func(func(int, int) bool) {
	return func(yield func(int, int) bool) {
		for i := range count { // range over int (from 0 to count-1)
			yield(i+1, rand.Int())
		}
	}
}

func main() {
	for i, n := range randoms2(3) {
		println(i, n)
		if i >= 2 {
			break
		}
	}
}

のように，3回出力するイテレータに対して何らかの理由で2回で中断したとすると

$ go run sample1b.go
1 5146054532611686492
2 7588979459646265126
panic: runtime error: range function continued iteration after function for loop body returned false

goroutine 1 [running]:
main.main-range1(...)
	/path/to/sample1b.go:16
main.main.randoms2.func1(...)
	/path/to/sample1b.go:10
main.main()
	/path/to/sample1b.go:16 +0xcd
exit status 2

などと panic を吐く。怖いですねぇ（笑）

試しに上のコードの randoms2() 関数を

func randoms2(count int) func(func(int, int) bool) {
	return func(yield func(int, int) bool) {
		for i := range count { // range over int (from 0 to count-1)
			println("calling", i+1)
			if !yield(i+1, rand.Int()) {
				println("return false from yield")
				return
			}
		}
	}
}

などとデバッグ文を入れて書き直すと

$ go run sample1c.go
calling 1
1 682324887426579321
calling 2
2 5758210549060056534
return false from yield

のように出力される。 yield() 関数の呼び出しは2回までで，2回目に false を返していることが分かるだろう。

iter パッケージ

イテレータを比較的簡単に取り扱えるようにするため iter パッケージが用意されていて，イテレータを以下のように定義している。

type Seq[V any] func(yield func(V) bool)

type Seq2[K, V any] func(yield func(K, V) bool)

前節の randoms() 関数であれば

import (
	"iter"
	"math/rand/v2"
)

func randoms(count int) iter.Seq[int] {
	return func(yield func(int) bool) {
		for range count { // range over int (from 0 to count-1)
			if !yield(rand.Int()) {
				return
			}
		}
	}
}

のように書き直せる。ん？大して変わらんな（笑）

もうひとつ。 iter パッケージには iter.Pull() および iter.Pull2() 関数が用意されていて，たとえば先程の randoms() 関数の呼び出し側で，以下のように，push-style から pull-style に変形できる。

func main() {
	next, stop := iter.Pull(randoms(3))
	defer stop()
	for {
		n, ok := next()
		if !ok {
			break
		}
		println(n)
	}
}

これはアリだろう。

slices パッケージ

slices パッケージにもイテレータ関連の関数が追加された。たとえば All() 関数を使って

package main

import "slices"

func main() {
	nums := []int{1, 2, 3}
	for i, num := range slices.All(nums) {
		println(i, ":", num)
	}
}

のように slice をイテレータに変換する。記述が増えただけで見た目は変わらんやんけ！と思うかも知れないが

package main

import (
	"iter"
	"slices"
)

func main() {
	nums := []int{1, 2, 3}
	next, stop := iter.Pull(slices.Values(nums))
	defer stop()
	for {
		num, ok := next()
		if !ok {
			break
		}
		println(num)
	}
}

のように pull-style に変形できるのはいいかもしれない。また，イテレータに変換する際に Backward() 関数で逆順に並び替えたり Chunk() 関数で slice を分割することもできる。

Collect() 関数を使ってイテレータを slice に変換することもできる。前節の randoms() 関数であれば

func main() {
	randlist := slices.Collect(randoms(3))
	fmt.Println("randlist:", randlist)
}

のように書く。また AppendSeq() 関数で既にある slice インスタンスにイテレータの出力を追加したり，Sorted() 関数等を使った並び替えもできる。

maps パッケージ

maps パッケージにもイテレータ関連の関数が追加された。ここでは簡単に関数名だけ紹介する。

All : map 型を iter.Seq2 型に変換する
Keys : map 型のキーを iter.Seq 型に変換する
Values : map 型の値を iter.Seq 型に変換する
Collect : iter.Seq2 型を map 型に変換する
Insert : 既にある map インスタンスに iter.Seq2 型の出力を追加する

改訂版：土用期間中の干支を数え上げる

以前書いた「第五の季節：土用」という記事で，拙作の goark/koyomi パッケージを使って，土用期間中の干支を数え上げるコードを紹介した。こんな感じ。

package main

import (
	"fmt"
	"time"

	"github.com/goark/koyomi/value"
	"github.com/goark/koyomi/zodiac"
)

func main() {
	start := value.NewDateYMD(2026, time.July, 20)   //土用の入り
	end := value.NewDateYMD(2026, time.August, 7)    //立秋
	for d := start; d.Before(end); d = d.AddDay(1) { //1日単位で立秋の前日まで出力する
		干, 支 := zodiac.ZodiacDayNumber(d)
		fmt.Printf("Day %v is %v%v\n", d, 干, 支)
	}
}

実行結果は以下の通り。

$ go run sample6a.go
Day 2026-07-20 is 乙未
Day 2026-07-21 is 丙申
Day 2026-07-22 is 丁酉
Day 2026-07-23 is 戊戌
Day 2026-07-24 is 己亥
Day 2026-07-25 is 庚子
Day 2026-07-26 is 辛丑
Day 2026-07-27 is 壬寅
Day 2026-07-28 is 癸卯
Day 2026-07-29 is 甲辰
Day 2026-07-30 is 乙巳
Day 2026-07-31 is 丙午
Day 2026-08-01 is 丁未
Day 2026-08-02 is 戊申
Day 2026-08-03 is 己酉
Day 2026-08-04 is 庚戌
Day 2026-08-05 is 辛亥
Day 2026-08-06 is 壬子

次の土用の丑の日は7月26日か。

それはともかく，コード中の for 文がカッコ悪いなぁと以前から思ってたので，今回の勉強ついでに，指定期間の日付を出力するイテレータを実装してみた。これを使うと，こんな感じに書き直せる。

package main

import (
	"fmt"
	"time"

	"github.com/goark/koyomi/value"
	"github.com/goark/koyomi/zodiac"
)

func main() {
	seq, err := value.NewDateYMD(2026, time.July, 20).IterDay( //土用の入りから
		1, //1日単位で
		value.NewDateYMD(2026, time.August, 7).AddDay(-1), //立秋の前日まで出力する
	)
	if err != nil {
		fmt.Println(err)
		return
	}
	for d := range seq {
		干, 支 := zodiac.ZodiacDayNumber(d)
		fmt.Printf("Day %v is %v%v\n", d, 干, 支)
	}
}

どうよ。こっちのほうが少し見やすいべ。 Before() とか After() とか直感的に分かりにくいメソッドが隠蔽できるだけでもだいぶありがたい。

ブックマーク

参考図書

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

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

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

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)

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); 評価

[Comment] とりあえず図書館で借りて試し読みしたら面白かったので買うことにした。原書の初版が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); 評価

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); 評価

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); 評価

[Comment] 第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); 評価

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

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

List of Programming [text.Baldanders.info]

今日はいつ？ — goark/today v0.1.0 をリリース

参考

Go 1.27 のリリース

参考図書

我々は何者か？ — 『我ら、プログラマー』オンライン読書会 第1回目

我々は何者か？

参考

「おもしろい技術書」

K&R

プログラミング言語 Go

デザインパターン本

その他の読み物

ブックマーク

参考

バージョンの埋め込みと表示

ビルド時にバージョン文字列を埋め込む

ビルド情報を表示する

go run ではビルド情報がセットされない

ブックマーク

参考図書

任意のイテレータを作る

Range Over Functions

iter パッケージ

slices パッケージ

maps パッケージ

改訂版： 土用期間中の干支を数え上げる

ブックマーク

参考図書

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

参考

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

AI バブルの終焉

人力コーディングの終焉

ブックマーク

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

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

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

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

余談

参考図書

我々は何者か？ — 『我ら、プログラマー』オンライン読書会第1回目

改訂版：土用期間中の干支を数え上げる