List of Design [text.Baldanders.info]

「おもしろい技術書」

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

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

原著者の一人は前節で紹介した 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; 評価

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

いつの間にか発行元が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 は習ったが，お遊び程度だったと言っておこう。 ↩︎

「識別、認証、許可」

2022-10-15T02:43:48+00:00

セキュリティ・システムを組む際の肝は識別（identification），認証（authentication），許可（authorization）の3つを（設計概念上）きちんと分離し，かつそれらを上手く組み合わせることである。

この辺の話は Bruce Schneier さんの名著『セキュリティはなぜやぶられたのか（原著名 “Beyond Fear”）』の13章で詳しく解説されている。

セキュリティはなぜやぶられたのか: ブルース・シュナイアー (著), 井口耕二 (翻訳); 日経BP 2007-02-15; 単行本; 4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN); 評価

[Comment] 原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので，そのへんを加味して読むとよい。

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

これによると識別・認証・許可の各機能は以下の通り。

識別：あなたは誰？

認証：証明しろ

許可：この範囲のことはしてもよい

『セキュリティはなぜやぶられたのか』 p269より

さらに言うと，コンピュータ・システムでは識別・認証・許可はそれぞれ「トークン（token）」として符号化されることが多く，これらトークンを認証（certification）する機能も要求される。

たとえば映画館の入場券は純粋に許可トークンである。このトークンがあれば誰が入場しようと問題ない。たとえそれが他者から奪い取ったものだとしても。

ライブチケットも同様に許可トークンだが，近年では転売屋対策で，「誰」が購入したものか特定するために識別トークンを兼ねていることが多い。この場合，入場時にチケットを持っているのが本人かどうか証明する必要があるため何らかの認証トークンと紐付けることになる。

これで識別・認証・許可について何となくイメージできただろうか。では本題へ。

昨今，「個人番号 (マイナンバー) 」が某日本政府の無茶振りによりまたぞろ話題になっているが，個人番号自体はただの識別トークンであり，それ単体では何も認証しないし何も許可されない。個人番号はお役所などの窓口で提示することで（主にお役所側の都合で）各種業務フローを簡素化できると期待されている。つまり個人番号と本人がセットになることではじめて認証も許可も機能し始めるのだ¹。

私も引っ越しをした時に個人番号カードを提示するだけで各種届け出を全部やってもらったので有り難かった記憶がある。もっとも引っ越すたびに個人番号カードを書き換えないといけないので，利用者にとってホンマに便利か微妙なところであるが（笑）

その個人番号カードであるが，これには「利用者証明用電子証明書」が組み込まれている。また希望者には住基ネットの「署名用電子証明書」を組み込むこともできる。署名用電子証明書は，確定申告をネットで行う人にはおなじみのやつだ。つまり「個人番号カード」のほうは認証トークンを兼ねているのである。これは非常に重要な機能である。

署名用電子証明書はある程度長いパスワードで秘匿できるが²，利用者証明用電子証明書のほうは4桁の暗証番号のみでロックされている。さらに言うと昨今では個人番号カードの3つの暗証番号を同一にするよう勧められるらしい。

認証トークンとしての個人番号カードが（住基周りを除いて）こんなに緩いのは「個人番号」自体が所詮はお役所サービスのためのシステムに過ぎないからだと認識しているのだが，どうだろう。

でも，ここで個人番号カードに健康保険証や運転免許証を統合し，これによって個人番号カード所持を事実上強制しようという動きがある。健康保険や運転免許のシステムを個人番号の下に統合しようというのなら分かる（実装の仕方にもよるが）。しかし個人番号カードは単なる情報（数字列）ではなく物理媒体であり，かつ行政サービス向けの重要な（割に運用の緩い）認証トークンである点が問題である。

私は個人番号カードは普段持ち歩かないようにしている（当然だよね）。一方で持病持ちの私は健康保険証は肌身離さず持ち歩かざるを得ない。運転免許証についても身分証明証代わりに持ち歩いている人もいればクルマのダッシュボードに入れっぱなしの人もいるだろう。また紛失・盗難が起きた際のインパクトも「事後」の取り扱いも利用者およびサービスによって全く異なる。

たとえば個人番号カードに健康保険証を組み込んだ場合，個人番号カード紛失時の再取得に手間と時間がかかるし（平日に有給休暇を取ってお役所詣で），その上で健康保険証機能も再発行してもらわないといけない。私のような持病持ちには無視できないインパクトだ。年に1回利用するかしないか程度のお役所サービスのせいで日常的に使っているサービスが巻き添えになるのである。

まとめよう。

カード媒体は紛失・盗難リスクが高い。付随するサービスによって扱いは異なるし，可能であれば「所持しない」のが最善と言える。それを「お買い物ポイント」で釣って運用リスクやコストの高いものを所持させるとかどこの詐欺師かって感じだし，ましてや利用ドメインの異なるサービスを抱き合わせにしようとか鬼畜としか言いようがない。

できれば勘弁して欲しいところであるが，どうなるやら。

ブックマーク

個人番号は秘密情報ではないが重要な個人情報のひとつではある。個人番号がもたらすプライバシー上のリスクは当然あるが，この記事で書くとカオスになるので言及しない。 ↩︎
住基関連の機能を使う場合は専用の暗証番号でアンロックし，その上で署名のためのパスワードを入力する必要がある。つまり二重にロックされているわけだ。 ↩︎

個人番号と個人番号カード

2020-09-21T10:30:40+00:00

どうしても TL に脊髄反射コメントを書いてしまう。

というわけで。

いろいろおかしいマイナンバーカード｜青野慶久@サイボウズ｜note

気持ちは分かる。共感できる。

だが「個人番号」と「個人番号カード」の問題は（関連してるけど）きちんと切り分けて考えないとワケワカメになる。

「個人番号」の問題

「個人番号」の問題は，ひとことで言うなら（ゼロ年代に議論になった）固有 ID の問題である。

ID (Identity) には有効な「目的」と「範囲」と「期間」が必ずある。これを逸脱するとセキュリティおよびプライバシーの問題となる。

ゼロ年代に批判された「住基番号」問題の核心は，目的と範囲と期間を超えて（認証および許可トークンとして）単一の ID を使いまわしていることだ。そして個人番号でも，当時の批判から何も学ぶことなく同じ失敗を繰り返している。

昨今あたり前になりつつある「セロトラスト・セキュリティ」と照らし合わせても「個人番号」の設計が如何にダサいか分かるだろう。ダメダメな設計を運用（マイナンバー関連法）でカバーするってのは「動かないシステム」の典型である。

「個人番号カード」の問題

「個人番号カード」の問題は「情報格差 (digital divide) 」の拡大だ。

5月の「特別定額給付金」でのドタバタを見れば分かるように，オンライン申請によって「できる人」と「できない人」で明確に色分けされてしまった。もっと言うと現在稼働中の「マイナポイント」はキャッシュレス決済手段を持ってない人は（できるできない以前に）構造的に排除されている。ぶっちゃけ，お役所内部のお些末さは枝葉末節に過ぎない。

これで思い出すのが，最近見かけた以下の記事だ。

アフターコロナの中国でネット弱者の老人にどう対応したのか - ZDNet Japan

この記事では「コロナ」と「老人」を切り口に語られているが，情報格差は世代格差よりも経済格差による影響が大きい。

つまり，「個人番号カード」により拡大した情報格差は経済階級構造と結びつき「情報力」を背景にした階級社会を強化することになるだろう。

ブックマーク

参考文献

グリゴリの捕縛: 白田秀彰; 2001-11-26 (Release 2014-09-17); 青空文庫; 4307 (図書カードNo.); 評価

[Comment] 白田秀彰さんの「グリゴリの捕縛」が青空文庫に収録されていた。内容は ~~怪獣大決戦~~ おっと憲法（基本法）についてのお話。古代社会 → 中世社会 → 近代社会 → 現代社会と順を追って法と慣習そして力（power）との関係について解説し，その中で憲法（基本法）がどのように望まれ実装されていったか指摘してる。その後，現代社会の次のパラダイムに顕現する「情報力」と社会との関係に言及していくわけだ。

reviewed by Spiegel on 2019-03-30 (powered by aozorahack)

つながりっぱなしの日常を生きる：ソーシャルメディアが若者にもたらしたもの: ダナ・ボイド (著), 野中モモ (翻訳); 草思社 2014-10-09 (Release 2015-07-21); Kindle版; B0125TZSZ0 (ASIN); 評価

[Comment] 読むのに1年半以上かかってしまった。ネット，特に SNS 上で自身のアイデンティティやプライバシーを保つにはどうすればいいか。豊富な事例を交えて考察する。

reviewed by Spiegel on 2016-05-10 (powered by PA-APIv5)

ダーク・スタイルにしてみた

2020-07-24T06:47:14+00:00

思うところがあってこのブログのスタイルを（近年の流行りにのっとって）ダーク・スタイルにしてみた。

いやね。既に Twitter とか Facebook とかダーク・テーマで表示してるわけよ。更にデスクトップ画面もテキスト・エディタもダーク・テーマにしてるの。

その状態で自分のサイトを見ると目がチカチカするのね，数秒程度だけど。ここ数年で眼が衰えてるのは自覚してたし，自サイトもダーク・スタイルにしちゃえ！って感じで替えてみた。

元のスタイルはとってあるし， Hugo なので戻すことは簡単にできる。まぁ，様子を見ながらチューニングしていく予定。

きっかけは以下の記事。

トイレのドアの鍵の話は「なるほど！」と思ったよ。

私は（少なくとも検査で異常なしと言われる程度には）色弱ではないが，近視で乱視で若干の弱視傾向がある。そんでもってここ5年位で老眼も進んでいる。だから明度や彩度が急激に変わると眼が追いつかなくなるのね。暗いところに眼を慣らすのに時間がかかるため，学生時代にやってた天体観測はなかなか大変だった（でも楽しかったよ）。

私は色弱の人の感覚は分からない。でも「誰もが同じように見えているわけではない」という点では共感できる。同じように，聴覚も味覚も嗅覚も触覚も，誰もが同じように感じているとは限らないのだ。

最初に紹介した記事にもあるように，これらの差異を緩和するような工学デザイン上の定石と言えるものはある。ただ，自分にない感覚を補完して設計するのはなかなか大変だと思う。私のように色彩や見た目のデザイン・センスが壊滅している人はなおさらである。

というわけで，色設計とか validation できるツールとかサービスとかあればいいのに，と思ってたら， Android アプリ開発なんかでは実際にあるらしい。

（Facebook で教えてもらったスクリーンショットを許可をもらってコピペしています）

他にもこういうツールとか・サービスとかあるといいよね。知ってる！という方は教えてください m(_ _)m

今回は主に自分用の変更だけど，弱視の方とか多少は楽に見れるようになっているといいねぇ。

ブックマーク

WEB色見本原色大辞典 - HTMLカラーコード

パッケージの管理（モジュール対応版）

2019-12-20T09:01:26+00:00

随分前に「go get コマンドでパッケージを管理する」を書いたのだが，内容が古すぎて使い物にならなくなっている。この記事を全面改訂してもいいのだが，個人的には当時の試行錯誤っぷりに懐かしい気分になったので，これはそのまま手を加えず新たに記事を起こすことにした。特にパッケージとモジュールの関係に注意して読んでいただければ幸いである。

【2021-02-25 追記】 なお，このブログで書き散らした内容をまとめる形で以下の Zenn 記事を書いた。こちらも併せてどうぞ。

Go のモジュール管理【バージョン 1.16 改訂版】

前提条件

作業プラットフォームは Ubuntu で Go コンパイラのバージョンは 1.13.x (またはそれ以上) とする。環境構築手順は以下を参考にどうぞ。

中古 PC に Ubuntu 環境を導入する

各環境変数の値（一部）は以下の通り。

$ go env GOPATH
GO111MODULE=""
GOARCH="amd64"
GOCACHE="/home/username/.cache/go-build"
GOENV="/home/username/.config/go/env"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/username/go"
...

プラットフォームによって環境変数の値は異なるが凡その振る舞いは同じなので，適当に読み替えていただきたい。

ちなみに GO111MODULE の値として以下を設定できる。

値	内容
`on`	常にモジュール対応モードで動作する
`off`	常に GOPATH モードで動作する
`auto`	`$GOPATH` 以下のディレクトリにあるパッケージは GOPATH モードで，それ以外はモジュール対応モードで動作する

GO111MODULE 未定義時の既定は auto。なお，バージョン 1.13 からは auto で $GOPATH 以下のディレクトリで作業していても go.mod によるモジュール定義がされている場合はモジュール対応モードで動作するようになった。

ありのまま今おこった事を話すぜ！

パッケージ hello を作って実行してみる

まずは $GOPATH/src/hello ディレクトリを作成し，以下のソースコード hello.go を記述する。

package hello

import "fmt"

func Hello(s string) {
	if s == "" {
		s = "there"
	}
	fmt.Println("Hello", s)
}

ついでに動作確認を兼ねてテスト用に example_test.go ファイルも作っておこう。中身はこんな感じ。

package hello_test

import "hello"

func ExampleHello() {
	hello.Hello("World")
	//Output:
	//Hello World
}

これで

$ go test ./...
ok  	hello	0.001s

とかなればパッケージ hello の完成である。

次にパッケージ hello を使うコードを書いてみる。 $GOPATH/src/sample ディレクトリを作成し，以下のソースコード sample.go を記述する。

package main

import "hello"

func main() {
	hello.Hello("World")
}

先程のサンプル関数 ExampleHello() と同じ内容なので出力結果は同じになる筈である。このコードをコンパイル&実行してみる。

$ go run sample.go 
Hello World

うんうん。ここまでは問題なし。

パッケージをモジュール化する

では，パッケージ hello と sample をモジュール化してみよう。

まずはパッケージ hello から。

$ go mod init hello
go: creating new go.mod: module hello

$ go test ./...
ok  	hello	(cached)

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

つぎはパッケージ sample。

$ go mod init sample
go: creating new go.mod: module sample

$ go run sample.go 
build command-line-arguments: cannot load hello: cannot find module providing package hello

ありゃりゃーん。コンパイルに失敗しちゃったよ。パッケージ hello をロードできないと言っている。ロード？

ここで $GOPATH/pkg/linux_amd64 ディレクトリを見るも hello に対応するコンパイル済みバイナリは存在しない。それもその筈で，最近の Go コンパイラは外部パッケージのロードとコンパイルをモジュール毎に $GOPATH/pkg/mod および $GOCACHE ディレクトリ下で行っている¹。したがってモジュール対応モードでは $GOPATH/src 下にある外部パッケージのコードは参照しないのだ。

さて，困ったね。

解決法1：強制的に GOPATH モードにする

環境変数 GO111MODULE の値を off にすることにより， go.mod の有無に依らず強制的に GOPATH モードでビルドすることができる。上述の例であれば

$ go env -w GO111MODULE=off

$ go run sample.go 
Hello World

とすればよい²。

ただし Go コンパイラの開発側は GOPATH を将来的に無くす方向で議論および開発を進めているため（後方互換性の観点からバージョン 1.x のうちは大丈夫だろうが）このやり方はあまりオススメできない。暫定措置というやつである。

解決法2： replace ディレクティブを使う

sample パッケージの go.mod に以下のディレクティブを追記することで，ローカルにある hello パッケージのコードを参照するようになる。

replace hello => ../hello

replace ディレクティブは非常に便利なのだが，どうしても環境依存の記述になってしまうのが欠点である。たとえば外部の CI/CD サービスと組み合わせる場合はローカルの環境と同じになるように設定をチューニングする必要があるかもしれない。これも暫定措置だよね。

解決法3：モジュール・パッケージ構成を再設計する

まぁ，身も蓋もない話だが，最終的にはモジュールおよびパッケージの構成を再設計するしかないだろう。

今回の例で言えば sample パッケージの構成を

$ tree sample
sample
├── go.mod
├── hello
│   ├── example_test.go
│   └── hello.go
└── sample.go

1 directory, 4 files

として sample.go を

package main

import "sample/hello"

func main() {
	hello.Hello("World")
}

と書き換えればいい。 hello パッケージを sample モジュール内のサブ・パッケージとして再構成するのである。

Go 言語における「モジュール」は「パッケージ（群）＋バージョン」であり，しかもバージョン管理は git 等 VCS の機能に依るところが大きい。故に「1モジュール＝1リポジトリ」を目安にすべきだろう（でないとバージョン管理が煩雑になる）。その上で「モジュール＝リポジトリ」内に関係の密なパッケージ（群）を組み込んでいくというのが Go 言語プログラミング設計の基本的な進め方になると思うのだが，どうだろう。

ブックマーク

Goモジュールモードでモジュール内に作ったモジュールを扱う - Qiita : モジュール内にサブ・モジュールを構成すること自体は可能である
cmd/go: default to GO111MODULE=on · Issue #41330 · golang/go · GitHub : Go 1.17 より GO111MODULE の既定が on になるらしい
モジュール対応モードへの移行を検討する
Go モジュールのバージョン管理

参考図書

プログラミング言語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 コンパイラでは環境変数 GOCACHE に off をセットすることでキャッシュ利用を無効化することができたが，最近のバージョンでは off は設定できなくなっている。 ↩︎
コマンド go env -w で設定した環境変数の値を削除するには -u オプションを使う。例えば go env -u GO111MODULE のように使う。 ↩︎

技術的負債としての「オブジェクト指向」

2019-07-28T11:47:23+00:00

「オブジェクト指向プログラミングは1兆ドル規模の大失敗なのか？ - YAMDAS現更新履歴」より。

邦訳を公開してくださった方，マジ感謝です。英語不得手な私には大変ありがたい。

「1兆ドル」という見積もりが妥当かどうかはともかく¹，オブジェクト指向設計あるいはプログラミングが究極ではないという意味なら同意できるし「その先」に進むべきというのも分かる。更にこれからプログラミング言語を学ぶなら関数型を学べという点についても激しく同意する。

どういうわけか日本人は Java が大好きで，確かにあと数年は飯の種になるだろうが，将来を見据えれば Java は間違いなく COBOL と同じ道をたどる。

Java はやめておけより

そういう意味で Java のようなレガシーなプログラミング言語が将来的な技術的負債になるのは間違いないと思う。まぁ「みずほ」のような大災害はそうそう起こらないだろうけど（笑）

でもそれが「オブジェクト指向」故の問題かと言われれば，ちょっと考えるところでもある。

オブジェクト指向設計とオブジェクト指向プログラミング

ひとくちに「オブジェクト指向」と言うが「設計」と「プログラミング」は分けて考える必要がある。「プログラミング」はどうしても言語仕様に依存してしまうが，「設計」は言語に依存しないしするべきではない。

研究分野についてはよく知らないのでスルーするが，産業分野に於いて「オブジェクト指向」とは制御単位としての「オブジェクト」と「オブジェクト」同士の関係を「記述」することだ。つまり「制御」を主体に設計するならば「オブジェクト」そのものに着目せざるを得ない。

これが，それまでの「構造化プログラミング」からの発展としての「オブジェクト指向」である。

さぁ，例外（おまえ）の罪を数えろ！

私が数年前に Go 言語を習い始めて驚いたのは「例外がない」ことだった²。

例外が抱える問題というのは本質的に goto 文の問題と同じ。オブジェクトの状態ごと脱出するため，（脱出前ではなく）脱出後にオブジェクトの後始末を記述せざるを得ないし，記述するためには脱出前の状態（の可能性）を「知識」として知っていなければならない。もし後始末をきちんとしないと，それがバグやリークやその他の脆弱性のもとになる。

エラー・ハンドリングについてより

例外処理を行うためにはオブジェクトの内部状態に外部からアクセスする手段を実装する必要がある。これが「オブジェクト指向」プログラミングを狂わせる要因のひとつになっている，と思う。

Go 言語ではエラー・ハンドリングの問題を tupple と defer 構文というシンプルな言語仕様によって解決している。これを知ったときはマジで感動したね。ほんでもって，私が Go 言語に傾倒する理由のひとつになっている。

具象から抽象へ記述する

これも以前に書いたことだが Go 言語では汎化・特化の関係を記述する手段として interface 型が存在する。 Interface 型は duck typing と勘違いされることもあるが（私もそう思っていた），実は「構造的部分型（structural subtyping）」と呼ばれるもので，オブジェクトの「ふるまい」のみを定義する³。

たとえばウォータフォール型の開発スタイルでは実装を開始するまでに設計が終わることが（建前上は）保証されているため「抽象→具象」へと書き進めることが容易な言語が向いている。一方，要件が絶えず変わったり実験的な製品の場合は設計が終わるまで待っていられないため Go 言語のような言語が向いてるかもしれない。

きみは Generics がとくいなフレンズなんだね，または「制約は構造を生む」より

私が「プログラマも要件定義から参加すべき」と思うようになったのは Go 言語を知ってからだ。他の流行りの言語でもそうだろうが，今やプログラミングは文芸的になりつつありプログラマ間のコミュニケーション「言語」にもなりつつある。

Don’t Talk to Strangers

「オブジェクト指向」設計およびプログラミングには don't talk to strangers の原則があり，いわゆる「友達の友達」のことは知らないふりをするのがよい設計と言われている。つまり「オブジェクト指向」で重要なのは「オブジェクト」ではなく，その「関係」であるというわけだ。

I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.
- Alan Kay, the inventor of OOP

via Object-Oriented Programming — The Trillion Dollar Disaster

引用の引用でスマン。

たとえば REST (REpresentational State Transfer) と呼ばれる分散システムにおける設計原則がある。でも REST って上で言うところの「オブジェクト指向」そのものだよね。 REST の背景には多分「オブジェクト指向」の考え方があるのかもしれないが，そもそも分散システムの設計における必然から生まれたものでもある。

結局のところ…

「オブジェクト指向」が云々なんてのは些末なことで，その時のトレンドによって要求は変わるし，要求の変化に伴って設計やプログラミングも変化するのだから拘っても仕方がない。

大事なことは，そうした「変化」のタイムスケールが，かつて感覚で考えていたよりもずいぶん小さいものであり，サボることなく対応していかなければあっという間に技術的負債になってしまうということだろう。そのための DevOps や OODA や PDCA なんじゃないの，と思うわけだ。

まぁ，既に職業エンジニアを廃業し現場から遠ざかったロートルが言うことじゃないけどさ。

ブックマーク

「null 参照」の損失を10億ドルと見積った人もいたな。こういう競馬の予想屋 (経済アナリスト) みたいなやり口は好かんのだがなぁ。 ↩︎
Go 言語には panic という「例外」に似た仕組みはあるが，これは文字通りプログラム続行不可能な状態で強制終了させるための仕組みであり「例外」のように運用すべきではないとされている。 ↩︎
Duck typing は主に動的型付け言語における型推論方式（のひとつ）で，クラス間の関係を記述するものではないらしい。ちなみに構造的部分型に対する言葉として「公称型（nominal subtyping）」というのがあって C++ や Java におけるテンプレート・クラスやインタフェース・クラスを使った汎化・特化関係を指す場合に使うそうだ。 ↩︎

エラー・ハンドリング再考

2019-02-24T06:57:44+00:00

前回は golang.org/x/xerrors パッケージを紹介かたがた簡単なコードをお試しで書いてみたのだが，大雑把に言って golang.org/x/xerrors パッケージの特徴は以下のようなものだと言えるだろう。

エラーの発生位置を取得・表示できる
エラーの等値性（equality）を検証できる
エラー・チェイン内の指定した型のインスタンスを抽出できる

であるならエラー・ハンドリングの設計もこれらの特徴を活かしたいものである。

errors 標準パッケージからの置き換え

たとえば以下のような

func foo() error {
    ...
}

func bar() error {
    ...
}

関数 foo() と bar() から返却される error が等値であれば処理をまとめられる筈である。今までは errors.New() 関数を使って

var (
    ErrInstance1 = errors.New("error instance 1")
    ErrInstance2 = errors.New("error instance 2")
    ErrInstance3 = errors.New("error instance 3")
)

のように，あらかじめ必要な error インスタンスを作成しておき

func errorHandling(err error) {
    switch err {
    case ErrInstance1:
        fmt.Fprintln(os.Stderr, "Error number 1 was triggered.")
        return
    case ErrInstance2:
        fmt.Fprintln(os.Stderr, "Error number 2 was triggered.")
        return
    case ErrInstance3:
        fmt.Fprintln(os.Stderr, "Error number 3 was triggered.")
        return
    default:
        fmt.Fprintln(os.Stderr, "Unknown error")
        return
    }
}

みたいな感じにインスタンごとに処理を書いていけばよかった。しかし errors を xerrors に置き換えた場合，このままでは上手くいかないことが分かる。

実際にコードを書いて確かめてみよう。 errorHandling() 関数ではエラーの発生位置も出力するようにしてみる。

package main

import (
    "fmt"
    "os"

    "golang.org/x/xerrors"
)

var (
    ErrInstance1 = xerrors.New("error instance 1")
    ErrInstance2 = xerrors.New("error instance 2")
    ErrInstance3 = xerrors.New("error instance 3")
)

func errorHandling(err error) {
    switch err {
    case ErrInstance1:
        fmt.Fprintf(os.Stderr, "Error number 1 was triggered.\n%+v\n", err)
        return
    case ErrInstance2:
        fmt.Fprintf(os.Stderr, "Error number 2 was triggered.\n%+v\n", err)
        return
    case ErrInstance3:
        fmt.Fprintf(os.Stderr, "Error number 3 was triggered.\n%+v\n", err)
        return
    default:
        fmt.Fprintf(os.Stderr, "Unknown error.\n%+v\n", err)
        return
    }
}

func foo() error {
    return ErrInstance1
}
func bar() error {
    return ErrInstance1
}

func main() {
    err1 := foo()
    err2 := bar()
    fmt.Println("foo() error == bar() error ?", err1 == err2)
    errorHandling(err1)
    errorHandling(err2)
}

これを実行すると以下のようになる。

$ go run handling1/handling1.go
foo() error == bar() error ? true
Error number 1 was triggered.
error instance 1:
    main.init
        /tmp/xerrors/handling1/handling1.go:11
Error number 1 was triggered.
error instance 1:
    main.init
        /tmp/xerrors/handling1/handling1.go:11

これは xerrors.New() 関数を起動した行がエラー発生位置になるためで，これでは本当のエラー発生位置が分からない。それじゃあ，というので

func foo() error {
    return xerrors.New("error instance 1")
}
func bar() error {
    return xerrors.New("error instance 1")
}

と書き換えても駄目である。 xerrors.New() 関数はインスタンスへのポインタ値を返すが foo() や bar() 関数で返される error と ErrInstance1 は異なるインスタンスなので Go 言語の等値演算子（equality operator）では（ポインタ値を比較するだけで）等値であることを示せない。したがって実行結果も

$ go run handling1b/handling1b.go
foo() error == bar() error ? false
Unknown error.
error instance 1:
    main.foo
        /tmp/xerrors/handling1b/handling1b.go:34
Unknown error.
error instance 1:
    main.bar
        /tmp/xerrors/handling1b/handling1b.go:37

と “Unknown error” になる。もちろん Error() 関数で出力される文字列を比較するなんてのは論外である。

Is 関数をカスタマイズする

上述の問題を解決する方法は色々あると思うが，今回はエラーメッセージのメンテンスのしやすさも考慮して，以下の方法を紹介してみる。

まず基本となる error インスタンスを以下のように定義する。

package werror

type Num int

const (
    ErrInstance1 Num = iota + 1
    ErrInstance2
    ErrInstance3
)

var errMessage = map[Num]string{
    ErrInstance1: "error instance 1",
    ErrInstance2: "error instance 2",
    ErrInstance3: "error instance 3",
}

func (n Num) Error() string {
    if s, ok := errMessage[n]; ok {
        return s
    }
    return "unknown error"
}

インスタンスの比較を簡単にするために数値型の Num を定義し，値と値に紐づくエラーメッセージを定義する。

次に Num 型を埋め込む形で xerrors 互換の wrapError 型を定義する。

type wrapError struct {
    Num
    frame xerrors.Frame
}

func New(n Num) error {
    return &wrapError{Num: n, frame: xerrors.Caller(1)}
}

func (we *wrapError) Format(s fmt.State, v rune) {
    xerrors.FormatError(we, s, v)
}

func (we *wrapError) FormatError(p xerrors.Printer) error {
    p.Print(we.Error())
    we.frame.Format(p)
    return nil
}

Format() および FormatError() 各関数については前回を参照のこと。これで

return werror.New(werror.ErrInstance1)

などとすれば定義された error 値を使って werror.New() 関数の起動位置で error インスタンスを生成することが出来る。ただし，このままでは xerrors.Is() 関数によるインスタンスの等値性を正しく検証できない。

そこで Num および wrapError に以下の関数を追加する。

func (n Num) Is(target error) bool {
	var t1 *wrapError
	if xerrors.As(target, &t1) {
		return n == t1.Num
	}
	var t2 Num
	if xerrors.As(target, &t2) {
		return n == t2
	}
	return false
}

func (we *wrapError) Is(target error) bool {
    var t1 *wrapError
    if xerrors.As(target, &t1) {
        return we.Num == t1.Num
    }
    var t2 Num
    if xerrors.As(target, &t2) {
        return we.Num == t2
    }
    return false
}

これで等値演算子 == の代わりに Num.Is() および wrapError.Is() 関数がインスタンスの等値性をチェックしてくれる。

この werror パッケージのクラス図はこんな感じかな。

werror.png

この werror パッケージを使って最初のコードを書き換えてみよう。

package main

import (
    "fmt"
    "os"

    "demo-xerrors/handling2/werror"

    "golang.org/x/xerrors"
)

func errorHandling(err error) {
    switch true {
    case xerrors.Is(err, werror.ErrInstance1):
        fmt.Fprintf(os.Stderr, "Error number 1 was triggered.\n%+v\n", err)
        return
    case xerrors.Is(err, werror.ErrInstance2):
        fmt.Fprintf(os.Stderr, "Error number 2 was triggered.\n%+v\n", err)
        return
    case xerrors.Is(err, werror.ErrInstance3):
        fmt.Fprintf(os.Stderr, "Error number 3 was triggered.\n%+v\n", err)
        return
    default:
        fmt.Fprintf(os.Stderr, "Unknown error.\n%+v\n", err)
        return
    }
}

func foo() error {
    return werror.New(werror.ErrInstance1)
}
func bar() error {
    return werror.New(werror.ErrInstance1)
}

func main() {
    err1 := foo()
    err2 := bar()
    fmt.Println("foo() error == bar() error ?", xerrors.Is(err1, err2))
    errorHandling(err1)
    errorHandling(err2)
}

これを実行すると以下のような結果になる。

$ go run handling2/handling2.go
foo() error == bar() error ? true
Error number 1 was triggered.
error instance 1:
    main.foo
        /tmp/xerrors/handling2/handling2.go:30
Error number 1 was triggered.
error instance 1:
    main.bar
        /tmp/xerrors/handling2/handling2.go:33

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

ブックマーク

参考図書

プログラミング言語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)

「オブジェクト指向」の黒歴史

2018-10-11T09:54:19+00:00

（もちろんタイトルは釣りです）

Qiita で面白い記事を見かけた。

まだ「オブジェクト指向はこうあるべき」で消耗してるの?

この記事にあるオブジェクト指向の価値を利便性に置くという考え方には激しく同意する。その上で，私の黒歴史を交えて，戯れ言をいくつか書いてみよう。

「プログラミング」で最初に何を学びましたか？

最近の子らは「プログラミング」で何を学ぶのだろう。

私が学生の頃（昭和時代）， FORTRAN の授業で真っ先にやらされたのがフローチャートを書くことだった¹。ちなみに授業の最初のお題は素数を求めるプログラムだった（ありがちw）。

そもそも「コンピュータ」っていうのは，名前の通り，「計算をする機械」なわけですよ。つまりフローチャートというのは「計算する」ことをモデル化したものなわけ。だから「計算する」ことに関してはフローチャートで全て表現できる。

そう思ってた時代がありました。

それから，まぁ，紆余曲折あって（バブル最盛期に）某システムハウスに潜り込んだのだが，初仕事の設計書で書かせられたのはフローチャートではなく状態遷移表だった。むしろ「フローチャートなんか要らん（コードを見れば分かる）」と言われましたよ。これが「社会の現実」ってやつですね，分かります。

ここで社会に出たての小僧は気づくわけですよ，「コンピュータ」っていうのは「計算をする機械」ではなく「情報を処理する機械」なんだということを。そして少年は「オブジェクト指向」と出会う（笑）

「情報」ってなに？

少なくともノイマン型コンピュータにおいては，基本的に以下の3つの機能しかない。

指定したアドレスから命令をフェッチして計算する
指定したアドレスからデータを読む
指定したアドレスへデータを書く

指定したアドレス（メモリとは限らない）に何があるのか決めるのはコードを書く人間側の責務であり，それを可能とするプログラミング言語であれば「情報を処理する」ことに関しては何でもできる。

じゃあ「情報」ってなに？

「オブジェクト指向」以前の「構造化プログラミング」の時代において，情報とは「データ」と「機能」だった。しかし「データ」と「機能」だけではコードは簡単に破綻する。以前に「ハード屋が書く C ソースコードが凄まじかった思い出」という記事を書いたが，これは情報を「データ」と「機能」と考えた場合の極端例と言える。

では「構造化プログラミング」時代のソフトウェア・エンジニアのコードは何故破綻しなかったのか²。ソフトウェア・エンジニアが暗黙的に考えていたこととはなにか。その答えのひとつが情報を「オブジェクト」と考える「オブジェクト指向」設計ないしはプログラミングである。

「オブジェクト指向」設計ではオブジェクトを以下の3つの組み合わせと考えた。

名前
状態（属性）
機能（操作，手段）

特に重要なのが「名前」である。「名前」とは自と他を区別する識別子で，区別することでそこに「関係」が生まれる。

たとえば「犬は動物の一種である」というのは，「犬」と「動物」の関係が「一種である³（is-a）」ことを示す。 C++ や Java では「一種である」という関係を「クラス・オブジェクトの継承」という形で記述するが，継承は「オブジェクト指向」に必須の記述ではない。 Go 言語の構造的部分型（structural subtyping）のような記述だってあるのだ⁴。

つまり「オブジェクト指向」においてはオブジェクトとその関係をモデル化することが重要で，それを記述することができるのであればどんな言語でも構わないのである。

ちなみに「オブジェクト指向」プログラミングはアセンブラや C 言語でも記述できるし実際にそういうプロジェクトに関わったこともある（大昔の話だよ）。プログラミング言語はプログラミングの手段に過ぎないということだ。

「オブジェクト指向」の先へ

しかし今さらアセンブラや C 言語で「オブジェクト指向」なコードを書こうという人は少ない（いや，ほぼいない？）だろう。では，当時オブジェクト指向プログラミング言語と呼ばれた C++ や Java によって私達ソフトウェア・エンジニアは幸せになれたのだろうか？否である！

これは私見だけど，「オブジェクト指向」の恩恵は「オブジェクト指向」で設計・記述できるようになったことではなく「オブジェクト指向」からの派生でコード記述が文芸的⁵ になり意図や文脈を記述するようになってきたことだと思う。

こうした発展はプログラミング言語のトレンドがオブジェクト指向言語だけではなく関数型言語など複数のパラダイムをブレンドした「マルチパラダイム・プログラミング言語」へシフトしていることからも言えるんじゃないだろうか。また FOSS が主流となりプログラムコードがエンジニア同士の対話手段として使われるようになったことも影響しているかもしれない⁶。

そういう意味で「オブジェクト指向はこうあるべき」という議論は不毛で非生産的な行為と言える。私達はもはやその先に足を踏み入れているのだから。

ブックマーク

参考図書

あなたはコンピュータを理解していますか? 10年後、20年後まで必ず役立つ根っこの部分がきっちりわかる！ (サイエンス･アイ新書): 梅津信幸 (著); ソフトバンククリエイティブ 2007-03-16; 新書; 4797339497 (ASIN), 9784797339499 (EAN), 4797339497 (ISBN); 評価

[Comment] 2002年に技術評論社から出た同名タイトルのリニューアルらしい。

reviewed by Spiegel on 2017-11-24 (powered by PA-APIv5)

数学ガール／乱択アルゴリズム: 結城浩 (著); SBクリエイティブ 2011-02-25 (Release 2014-03-12); Kindle版; B00I8AT1FO (ASIN); 評価

[Comment] 工学ガール，リサちゃん登場！

reviewed by Spiegel on 2015-04-19 (powered by PA-APIv5)

今どきの子は知らないかも知れないので念のために解説すると，「フローチャート」というのはコンピュータの処理の流れ（工程）を図式した一種のモデリング言語と思っていただいて構わない。 ↩︎
いや「動かないコンピュータ」なんてザラにあったけど。むしろ今も見かけるけど（笑） ↩︎
ちなみに「A は B の一種である」という関係を「汎化（または特化）」と言う。 “A is a B” と当て嵌めて考えれば分かりやすいだろう。 ↩︎
むしろ継承にこだわって菱形継承のような弱点や例外処理のような歪な構造を生み出したことは初期のオブジェクト指向プログラミング言語の黒歴史と言えるだろう。 ↩︎
これはいわゆる「文芸的プログラミング」とは意味が異なる。紛らわしくてゴメンペコン。 ↩︎
まさしく著作権による知的独占からの解放がもたらした好例のひとつですな。 ↩︎

「自動販売機の気持ちになって考える」

2017-11-24T03:07:09+00:00

結城浩さんの tweet で

プログラミングの課題で「自動販売機のシミュレータを作れ」というのはいい問題ではないかとよく思う。易しいものから、難しいものまで、仕様しだいでいろいろできる。GUIの有無、商品の種類、在庫管理、金種管理、各種アラート…
— 結城浩 (@hyuki) 2017年11月24日

というのがあって，続きの tweets から見ても（プログラミングというよりは）システム設計（もしくは base design）のことを指しているのは明らかなんだけど，私が連想したのは梅津信幸さんの『あなたはコンピュータを理解していますか？』だった。

この本は2002年に出版されていて，これ自体は恐らく絶版なのだが，2007年にリニュール本が出ているようだ。さっそく発注してしまった（笑）

この本で一番印象に残っていたのが第3章の「自動販売機はコンピュータ理解の始まり」である。この章では

客がお金を入れる
客が商品（ジュース1本）を注文する
自動販売機が商品を出す
自動販売機がお釣りを返す

という流れを人間がシミュレーションしていて，特に「機械がお金を計算する」方法について図解で説明されているのが秀逸だった。つまり「自動販売機の気持ちになって考える」わけだ。

機械は人間のようには考えない。「機械（＝コンピュータ）が考える」というのはどういうことなのか。これを過不足なく説明するのは意外に難しい。用語を並べ立てて煙に巻くか，頭の悪い擬人化でお茶を濁すのがせいぜいだろう。私もちゃんと説明できるか自信がない。でも，それを考えるのがプログラミングの最初の1フィートである。

どうせ学校教育でプログラミングを教えるのなら，「自動販売機の気持ちになって考える」からやっていただきたいものだ。「プログラミング言語」なんか必要ないのである。機械が人間の書いたプログラムを「理解」して実行する，というのは大いなる誤解である。たとえば，そうした誤解が「シンギュラリティ神話」へ向かわせるのなら「プログラミング言語」を習うとかむしろ有害かもしれない。

学生の時に読んだ「日経サイエンス」の記事にティンカートイで3目並べを解くプログラムを組む話があったが¹，どんなにコンピュータ技術が発達しても（量子コンピュータが登場しても）スタートラインは常に「ここ」なので，それを忘れないでほしいのですよ。

まぁ，本気で AI が発達してノイマン型コンピュータが廃れたら説明の根本が変わるだろうけど，それは当分先の話（多分）。

参考図書

あなたはコンピュータを理解していますか? 10年後、20年後まで必ず役立つ根っこの部分がきっちりわかる！ (サイエンス･アイ新書): 梅津信幸 (著); ソフトバンククリエイティブ 2007-03-16; 新書; 4797339497 (ASIN), 9784797339499 (EAN), 4797339497 (ISBN); 評価

[Comment] 2002年に技術評論社から出た同名タイトルのリニューアルらしい。

reviewed by Spiegel on 2017-11-24 (powered by PA-APIv5)

この話「三目並べをするティンカートイ・コンピュータ」は『別冊日経サイエンスコンピューターレクリエーション 4 遊びの展開』に収録されていたのだが，絶版本とは言え，どえらい値段がついてるな（笑） ↩︎

「改憲」という要求開発

2017-10-23T08:45:41+00:00

やぁ，選挙が終わりましたよ。ようやくこれで胡乱なことが喋れるよ（笑）みんなよく選挙期間中に公衆空間で具体的な候補者を名指しでこき下ろしたり礼賛したりできるな。私は選管や選管に密告するネットユーザが怖いので無理です。

さっそく頭のなかでトグロを巻いてる色々な雑念を Scrapbox に吐き出していく（外部記憶に書いて忘れるため）。そこで半分無意識に書いた

普通は逆。国家の主権者のアイデンティティを担保するものとして憲法がある。太平洋戦争で何もかもぶっ壊された当時の日本人には自分たちを肯定するものが天皇と憲法しかなかったのかもしれないが。改憲議論を含めて憲法について考えるなら，自分たちの行動規範や慣習の源泉（ルーツ）について突き詰めていく作業が不可欠だが，突き詰めていくと当の憲法にぶち当たって，そこより以前とは断絶状態になっている

改憲 - Spiegel's Branch - Scrapboxより

を眺めていて（我ながら珍しいことを書くなぁ）ふと思いついた。

「これってコーランのことなんじゃね¹？」

なんでこんな明後日の方向に思考が飛んだかというと，以下の記事を思い出したからだ。

対話する「未来論」：イスラームの宗教と脳の機能は交差する。

正直な話，最初にこれを読んだときにはうまく脳に馴染まなかった。ただ，この中で西欧（ギリシア哲学）的な思考とイスラーム教的な思考の違いが分かりやすく例示されている。

例えば高校で数学の問題集をわれわれは渡されて、解答は渡されずに、数学的な真理を見出していく。後で先生が解答集から答えを見せてくれて、それ以前の人間がすでに見出していた真理と照らし合わせて理解する、そういうやり方でわれわれは数学を学びますよね。これはギリシア哲学の時代の、つまり近代的な自我を課題にするようになる以前の、科学としての哲学の方法論です。それに対して、コーランは神が啓示で真理を下した、いわば「解答集」であって、人間はそこから逆算して世界に存在する問題を認識する。問題を認識すると同時に答えも与えられている。そもそも答えが先にあって、答えにあるように世界に存在する問題読み取るのですから、答えがあるのは当たり前なのですが、しかしとにかくそのように解答と問いを同時に受け取って、世界と人間の生命に対する確信を得る。究極のマニュアルなんですね。

対話する「未来論」：イスラームの宗教と脳の機能は交差する。より

具体的には算数で「$1+1=\,?$」という問題と「$2$」という解答のセットがあるとする²。そこで「$1+1$」について考察し解答である「$2$」を導き出すのが西欧的思考で，「$1+1=2$ である」を絶対として無条件に受け入れるのがイスラーム教的思考と考えればいいのだろうか（算数に関しては日本の学校教育は後者な気もするが³）。

実はコンピュータ・エンジニアも似たようなことをする。それは TDD (Test-Driven Development) である。

TDD では先に「テスト」を書く。つまり「問題と解答」のセットを先に作るのである。そして入力した問題に対して必ず「正しい」解答が出力されるよう手順（algorithm）を記述するのがプログラミングである。

たとえば「20と32の最大公約数は4」を導く手順としては「ユークリッド互除法」が有名だが，なぜ「ユークリッド互除法」で最大公約数が解けるのかエンジニアは考えない⁴。テストが要求する $gcd(20,32)=4$ を実装できることが重要なのである。そもそも大抵の数学ライブラリに入ってるしね（笑）

現在の日本国憲法が日本人にとって「最後の憲法⁵」であるなら「改憲」議論そのものがナンセンスだろう。実際そのように考えている政治家（やその支持者）は多そうだ。

憲法に関しては，私はそっちに与しないが。

たとえば，上で挙げた TDD は「テストは正しい」ことが必要条件である。「テストは正しい」と信じられなければ，そもそも TDD は成立しないのだ。

エンジニアがアルゴリズム偏重になることについては苦言を呈する人もいる。

プログラミングにおける何らかの問題に取り組むとき、まず私たちはその問題が何であるのか、そしてそれは本当に問題であるのかを見極めなければならない。その問題が本当にプログラミングで解決できる問題かどうかを考慮せず、プログラミングで解決することに固執し、「なぜ問題なのか」という視点を失ってしまっては、そこから何も得ることはできない。それがプログラミングで解決できる問題であろうと、なかろうとだ。

頼むからプログラミングを学ばないでくれ | TechCrunch Japanより

これは全くもってそのとおり。エンジニアリングの世界ではこれを「要求定義」もしくはもう少し推し進めて「要求開発」と呼ぶ。

私たち日本人に日本国憲法を「最後の憲法」たらしめんとする圧力の源は何なのか。そこから考え始めるべきではないのだろうか。それも「要求開発」である。

ブックマーク

参考図書

要求開発~価値ある要求を導き出すプロセスとモデリング: 山岸耕二 (著), 安井昌男 (著), 萩本順三 (著), 河野正幸 (著), 野田伊佐夫 (著), 平鍋健児 (著), 細川努 (著), 依田智夫 (著), ［要求開発アライアンス］ (著); 日経BP 2006-03-02; 単行本; 4822282686 (ASIN), 9784822282684 (EAN), 4822282686 (ISBN)

[Comment] 「要求定義」から「要求開発」へ

reviewed by Spiegel on 2015-08-31 (powered by PA-APIv5)

いかにして問題をとくか: G. ポリア (著), Polya,G. (原著), 賢信, 柿内 (翻訳); 丸善 1975-04-01; 単行本; 4621045938 (ASIN), 9784621045930 (EAN), 4621045938 (ISBN); 評価

[Comment] 数学書。というか問いの立てかたやものの考え方についての指南書。のようなものかな。

reviewed by Spiegel on 2014-09-26 (powered by PA-APIv5)

いや，イスラーム教徒の方は怒らないでね。この手の「思考の横滑り」は私にはいつものことなので笑って許してください。私はエンジニアだけど，いつも論理的に考えているわけじゃあないんだよ。 ↩︎
厳密には $1+1=2$ というのは「$1+1$ と $2$ は常に等しい」という意味の恒等式であるが，細かいことは言わないでおく。 ↩︎
そうでなければ「掛け算は順序が大事」みたいな大惨事にはならないだろう。 ↩︎
いや，さすがに現場のエンジニアは学生時代に一度くらいは「ユークリッドの互除法」を証明したことがあるだろけど。やったことないって人や忘れてしまった人は結城浩さんの「数学ガールの秘密ノート」の連載で「ユークリッドの互除法」が登場するので読むといいだろう。 ↩︎
「イスラームの宗教と脳の機能は交差する。」には「最後」について「宗教的に画期的な「発明」」と書かれている：「イスラーム教徒は「最後の預言者であるムハンマドに託された最後の啓示の言葉」としてコーランを認識することで、「最後の次」の啓示というものが出てくることを、単に認識しません。誰かがどれだけよく考え抜いて、現代のグローバル化した人類社会の新たな環境に適合した新たな啓示の法はこうだ、と新しい宗教を提示しても、コーランの内容と比べてその新しい宗教が優れているか否か、ということをイスラーム教徒の側は誰も論じません。論じる必然性を全く感じないからです」 ↩︎

List of Design [text.Baldanders.info]

「おもしろい技術書」

K&R

プログラミング言語 Go

デザインパターン本

その他の読み物

ブックマーク

参考

「識別、認証、許可」

ブックマーク

個人番号と個人番号カード

「個人番号」の問題

「個人番号カード」の問題

ブックマーク

参考文献

ダーク・スタイルにしてみた

ブックマーク

パッケージの管理（モジュール対応版）

前提条件

ありのまま今おこった事を話すぜ！

パッケージ hello を作って実行してみる

パッケージをモジュール化する

解決法1： 強制的に GOPATH モードにする

解決法2： replace ディレクティブを使う

解決法3： モジュール・パッケージ構成を再設計する

ブックマーク

参考図書

技術的負債としての「オブジェクト指向」

オブジェクト指向設計とオブジェクト指向プログラミング

さぁ，例外（おまえ）の罪を数えろ！

具象から抽象へ記述する

Don’t Talk to Strangers

結局のところ…

ブックマーク

エラー・ハンドリング再考

errors 標準パッケージからの置き換え

Is 関数をカスタマイズする

ブックマーク

参考図書

「オブジェクト指向」の黒歴史

「プログラミング」で最初に何を学びましたか？

「情報」ってなに？

「オブジェクト指向」の先へ

ブックマーク

参考図書

「自動販売機の気持ちになって考える」

参考図書

「改憲」という要求開発

ブックマーク

参考図書

解決法1：強制的に GOPATH モードにする

解決法3：モジュール・パッケージ構成を再設計する