2023年賀状（PostScript定期）
ちょっと趣向を変えて、今年は具象です。 乱数を使って1枚ずつ仕上がりを変えるみたいな小細工も今年はやめた。
楕円を三つ組み合わせているだけなんだけど、文字列のパスと楕円のパスとで切り出しが入れ子になってるのと、それを楕円ごとにやらないといけないので、丁寧なgsave/grestoreが必要でめんどくさい。 グラデーションは、色空間をRGBではなくHSVにするだけで途中にどす黒い領域は発生しなくなるんだけど、一次関数で変化をつけるといまいち知覚的にきれいに見えなかったので、対数を使っている。文字列と背景とでそれぞれ別々にグラデーションを適用するのもめんどくさかった。 例年に比べて地味なのに、めんどくさい度は高かった気がする。
『プロフェッショナルSSL/TLS』（現『プロフェッショナルTLS&PKI 改題第2版』）の読み方（私論）
［2024/04/29 追記］
本書は2023年12月に改訂改題され、『プロフェッショナルTLS&PKI 改題第2版』となっています。改訂により次のようなブラッシュアップが施されていますが、書籍の大きな流れ自体は本記事の旧版と変わっていませんので、引き続き参考にしていただければと思います。
- TLS 1.3ベースの解説になった
- 一方で、TLS 1.2以前について知っているべきことも厳選して残されている
- ウェブでTLSとPKIを安全に使うための課題と対策についての解説が拡充され、整理された
- 書籍後半の設定や運用に関する詳細説明がOpenSSLベースに一本化され、整理された
- 新たに明らかになった脆弱性やインシデントの解説が追加された
［ここまで2024/04/29 追記］
本記事は、ラムダノートで発売している『プロフェッショナルSSL/TLS』を買っていただいた方向けに「読んで」とお願いするための「私家版、読み方のおすすめ」です。本なので、どう読んでもらってもいいんですが、「買ったはものの積読になっている」という方の背中を押せればと思います。
（［2024/04/29 追記］下記は『プロフェッショナルTLS&PKI 改題第2版』の公式ページです）
この本は、プロトコルであるTLSの解説書であると同時に、「インターネットで安全にやっていく」ための感覚のベースラインを与えてくれる本です。 そういうつもりで、まずは第1章を読んでみてください。 知ってる話も知らない話もあると思いますが、20ページくらいしかないので、とりあえず読みましょう。 ここを読むと、現代のTLS以前の古典的な暗号、ハッシュ、認証について、安全かどうかを考えるためのフレームワークが得られます。 カタログ的ではないので、そういうのは期待しないでください。 なお、現在のバージョンには「認証付き暗号」という重要な概念が抜けていますが、これについては次の第2章（および最新の電子版に収録された付録A）で出てきます。（［2024/04/29 追記］『プロフェッショナルTLS&PKI 改題第2版』では第2章がTLS 1.3、第3章がTLS 1.2の解説となり、認証付き暗号についても第2章と第3章で説明されています。）
第1章を読んだら、TLS 1.3に関する付録AがあるPDFをおもちであれば、そこを読みましょう（［2024/04/29 追記］『プロフェッショナルTLS&PKI 改題第2版』では第2章がTLS 1.3の説明です。そのまま読みましょう）。 ない人は、TLS 1.2ベースになりますが、そのまま第2章へ。 本書はTLSの「プロトコルとしての仕様」を説明する本ではないんですが、なにはともあれTLSのプロトコルとしてのノリは把握しておく必要があります。 この章（もしくは付録）については、多少ぴんとこない話があっても読み飛ばして、とりあえず目をとおしてください。 そういう「この章だけを読んでもぴんとこない」部分も、あとの章を読むと「そういうことね」と思えるはずです。
次の第3章（［2024/04/29 追記］『プロフェッショナルTLS&PKI 改題第2版』では第4章）も、とりあえず「ぴんとこない部分」は飛ばしていいので、目をとおしましょう。 TLSというプロトコルは、インターネットにおいてはPKIというインフラの上で使うことを前提になっていて、ここはそのPKIの話です。 この章も、どのみちあとで何度も立ち戻ってくることになるので、初見は「だいたいこういうことが書いてあるんだな」という軽い気持ちでまずは目を通してください。
第4章から第7章は、主に歴史の話です（［2024/04/29 追記］『プロフェッショナルTLS&PKI 改題第2版』では第5章から第9章）。 ほんとは歴史の話というわけではなく、歴史をとおして「なんでいまのTLSやPKIがこういう姿になっているか」を知るための章なんですが、歴史の話と思って読むとさらさら読めるはずです。 この部分を読みながら、「あれこれはなんの話だっけ？」とおもったら第1章から第3章や付録Aの該当部分に検索や索引を頼りに立ち戻って「なるほどね」と思う、というのが、本書の効率的な読み方かと思います。
が、実はもっと効率的な読み方もあります。それは、次の第8章（［2024/04/29 追記］『プロフェッショナルTLS&PKI 改題第2版』では第11章）を中心とした読み方です。 第4章から第7章は、分脈を知るには不可欠なんですが、分脈はいいからまずは具体的な話をしてくれ、というときもあるでしょう。 そういうときは、「第8章から読む」というかなり乱暴な読み方もありです。 もちろん、それで意味がわからない部分については第1章から第3章や付録A、あるいは第4章から第7章に向き合ってください。
第9章以降は、かなりボリュームはあるものの、最初はボーナスステージという扱いで、「実務で必要になったら読む」でもいいと思います。 とくに第13章以降は、現在ではすべての人に必要な情報というわけでもないので、ここを読み切らなくても「読んだ」といって大丈夫です（［2024/04/29 追記］『プロフェッショナルTLS&PKI 改題第2版』では、第9章が暗号のパフォーマンス、第10章がウェブなどでTLSとPKIを使うときの課題、第12章と第13章がOpenSSLのコマンドラインツールの使い方という形で整理されたので、読まなくていい箇所はなくなったと言えます。むしろここのほうが実務をやっている人には読みやすいと思うので、ぜひ読んでください！）。
というわけで、この本は、ふつうのエンジニアがTLSについて知っておくと捗るすべてのことが書かれた本です。 文字通り「すべて」なんですが、「ふつうのエンジニアが知っておくといいこと」っていうのがポイントで、「前のほうに書いてある細部を全部を頭に入れておかないと読み進められない」という本ではないので、上記のような「本の構成」を把握しながらさくさく読み進めると、ボリュームのわりには「よめるよめるぞ」となる本ではないかと思います。 もちろん、実際に手を動かす段になるとわからないことがいろいろ出てくるはずですが、少なくとも「なにを調べたらいいか」あたりの勘はつくはず。
買った人はぜひ読んでみてください！
ラムダノート第8期を迎えました
2015年12月に自分で出版社を立ち上げたとき、うっすらと決めていた覚悟は、「ひとまず10年は続ける」でした。
それまで15年くらい、技術系版元として歴史も規模もそこそこある出版社で企画編集をやっていたので、「だいたい何部くらい売れれば一人なら食っていける」といった程度の雑な算段はあったものの、かっちりした事業計画があったわけでもなく、「まあ、しばらくは前職の退職金を食いつぶしながら最初の何冊かを作ればいいかな」などと気軽に考えながら、むかし作った本の読者だったり有識者レビュアーだったりでお世話になっていた時雨堂という会社に遊びにいき、そんな浮ついた起業計画を雑談のつもりでしたら、社長の @voluntus に「お金出すよ」と言われ、「えっ」って戸惑っているうちに税理士さんを紹介してもらい、定款ができて、気づいたら ラムダノートという出版社 ができていました。
あれから満7年。2022年12月にラムダノートは第8期を迎えることになりました。会社をスタートできたのは時雨堂のおかげ、本を出せたのは著者や訳者のおかげ、なによりもこうして「本を売ってやっていく」ができているのは本を買ってくれる読者のおかげです。
10年という当初のぼんやりした目標まではもうひと頑張りありますが、よく考えたらコンピューターとネットワークの出版社なんだから節目の基数は2であるべきだし、1000_2周年をむかえるこのタイミングで感謝祭として大セールをやっています。協賛は再び時雨堂です。クーポンコード「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう！」を入力すると電子書籍がほぼすべて半額。ほんとうにありがとうございます。
余談ですが、この「クーポンコードによる宣伝」という協賛の企画を思いついたのも時雨堂社長の @voluntus です。天才かと思った。
クーポンコードに社名を入れて会社宣伝するというのを思いついた。例えば「SHIGUREDO」って入れると TLS 本が割引になるとか。ラム社に広告宣伝費払う感じで。 https://t.co/ywV5WagBTG
— V (@voluntas) 2022年8月30日
このクーポンコードの文字列「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう！」は、お買い物で使ってもらうたびに当社のバックヤードに流れるので、みなさんにお祝いしてもらっている感も半端ありません。ほんとうにほんとうにありがとうございます。
さて、今回の大セールは12月19日まで引き続き開催中なので、ふりかえりにはちょっと気が早いのですが、今日までの段階で個人的に感じたいろいろをいったんダンプしておこうと思います。
セールの効果1：売り上げがすごい
ある程度は期待していた部分ではあるのですが、すでに直販サイトの平均的な売り上げの数か月分に達しています。おかげで、おそらく創業以来はじめて、期初の現金にやや余裕がある状態を迎えることができそうです。だいたい毎年、年末から年初にかけて現金が枯渇するのですよね…。当社の支払いサイクルの事情ではあるのですが、1月～2月と8月～9月にまとまった現金が必要で、メンタルがつらい。今年は例年になく穏やかな気持ちで正月を迎えられそうです。キーボードつくろうかな。
セールの効果2：潜在需要がすごい
売り上げについては、実は怖い気持ちもあって、「これ、来月からみんな本買ってくれないんじゃないかな…」という。アパレル系は年2回のセールで年間の売り上げを稼ぎ出すというし、電子書籍の世界でも半額セールや無料セールを定期的にやっているし、これはもうそういうものと考えるべきなのかもしれないけれど、セールをやるとわかっているショップではどうしたってセールを待ってしまいますよね…。当社の直販サイトでこれからセールを定期的にやるつもりはまったくないのですが、これだけ長期間のセールをやっていると、潜在的にラムダノートの本に興味があった人がすべて本を手にしてしまうかもしれない。
しかし、これは逆に考えると、「潜在的にラムダノートの本に興味があった人」がこんなにいたのかという素朴な驚きでもありました。専門書の編集者みたいな仕事を長年していると、「需要は限られている」という意識が骨の髄までしみついていて、ついつい実売部数についても「こんなものだろう」で思考停止してしまうんですが、そんなことなかったんだなあと。いつもよりお得っていう効果はあるにせよ、そもそも興味がないものに払えるお金はゼロ円なわけで、需要がしっかりあるという事実を目の当たりにさせてもらいました。
セールの効果3：知ってもらえた、思い出してもらえた
潜在需要が見えた背景には2つの要因があると考えています。1つは、当社が本として販売している情報に対価を払う意思はあったけど、それを当社で買えるという事実にそもそも気づいていなかった人がいたということ。もう1つは、当社で売ってる本のことは知っていたけど、買う機会を逃していた人がいたということ。いずれも、セールをやる前から「そういう人もいるだろうなあ」とぼんやりは想像していたわけですが、実際にセールを開始した後のツイッターなどの反響や、いわゆる直販サイトへのセッション流入数やコンバージョン率の上昇、まったく新規のお客様の割合などから類推するに、ぜんぜん想像以上でした。今回のセールは、短期での売り上げや、協賛の時雨堂を知ってもらう機会になったのみならず、「ラムダノート」という出版社の名前を知る人を中長期でかなり増やしてくれたのだろうなと実感しています。忘れないでね！
セールの効果4：刺激
当社としては、今回のセールを機に当社を新しく知ってもらった人や思い出してくれた人は、これから「当社が出す本」に期待していただいている状態だと考えています。正直なところ、丸7年間走りっぱなしだったので個人的にはちょっとお疲れ気味ではあるのですが、ここでめげずに新しい企画をやっていくぞという気持ちをセールへの反響や「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう！」というクーポンの文字列に支えてもらっている自覚があります。まだセール期間が1週間あるので、引き続きどんどんご利用ください！ あと、これからまたべらぼうに面白い新刊も出していくので、セール終了後も引き続き新刊情報をお見逃しなく！ 今年は結局新刊を出せなかったn月刊ラムダノートもやるよ！ 新刊情報については、メールとかはしていないので、 公式Twitter もしくは 直販サイトのお知らせページ をRSS購読してね。
本の原稿のバージョン管理を始めて20年たちました
「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。
目次です。
前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。
なんで「テキスト原稿のバージョン管理」の話をしなくなったか
いまからちょうど10年くらい前までは、「このスタイルでの書籍制作を自分以外にも広めるべきだ」という考えがうっすらありました。 当時在籍していた出版社の中でほかの編集者に勧めたり、外で発表したりすることも何度かありました。
www.slideshare.net
しかし、今はもうこのスタイルでの編集をあんまり内外で特別に喧伝することはなくなっています。理由は3つ。
- 自分の中では当たり前になってしまったので
- テキスト原稿のバージョン管理を個人ではじめる編集者がぽつぽつ増えてきたから
- その一方で、出版業界という粒度で見ると、ちっとも変わる気配がないし…
1つめの理由は、ようするに、自分が外向けに積極的に情報発信するくらい強い関心をもつ対象がもっと別のところにいった、ということです。飽きたともいう。
2つめの理由は、いい話です。中には、自分が過去にした情報発信を見てくれているような人もいて、ふつうにうれしい。そういう人たちが自分よりうまいことやってくれたら、それを真似できるので、さらにうれしい。
3つめの理由は、かっこよくいえば、諦観です。いくら情報発信しても変わらないなら、その人たちには不要ということです。 現状のまま、つまり「誌面レイアウトしたPDFとか紙に赤字を入れる」というスタイルでの編集でうまく回っているなら、自分がしゃしゃり出て「テキスト原稿のバージョン管理のノウハウとか共有します」って言っても迷惑なだけだろうなって。
「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理…
なんか最近になって再び、文芸系の著者サイドから「誌面レイアウトしたPDFとか紙に赤字を入れる」というスタイルについての恨みつらみが漏れ聞こえてくるようになりました。 編集者との赤字の共有が大変とか、手元ではテキスト原稿をバージョン管理しているけれど編集部には使ってもらえないとか、組版されるともうバージョン管理できないとか、そういう声です。
「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集のスタイルには、編集者や著者による濫用で、組版をお仕事にしている人たちが泣き寝入りすることになるという問題もあります。 これは組版業界では昔ながらの恨みつらみなので、SNSで顕在化されやすくなっただけではありますが、むしろ課題としては根深いやつだと言えます。
同じような恨みつらみは、著者や組版担当者だけでなく、編集者サイドの目線でももちろん存在しています。
- 初校に対する著者の赤字を転記しそこねて、再校出しで平謝りすることになった
- 組んだ状態で読んで文章構成から直したくなった著者が全面に赤を入れ、ほぼ組み直しになってしまった
- 赤字が意図通りに反映されていなかったので、指示をやり直すことになった
- 校了後にはじめて編集による修正に気づいた著者とトラブルになった
- 全体に同じパターンの修正指示が必要だが、数百カ所すべてに赤書きするのも、その赤字引き合わせをするのもつらい…
従来、これらのありがちな事態を防ぐために取られてきたのは、「著者との円滑なコミュニケーション」や「組版担当者との責任境界の明確化」、あるいは「余裕をもった入稿スケジュール」といった「人間の心がけ」ベースでの対策でした。 紙への赤字をスキャンしてやり取りできるようになったり、PDFのコメント機能の導入でテキストのコピペができるようになったり、パソコンやDTPソフトの機能向上で作業が効率的になったり、そういう意味では「コンピューターを活用」することで緩和している面もありますが、問題そのものの氷解には程遠いのが現状です。
そこでテキスト原稿のバージョン管理
上記に挙げたような各種の問題を根本的に消滅させるには、「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集の進め方を捨てるのが手っ取り早そうです。 なので、ぼくは20年くらい前に「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集スタイルを本づくりから段階的に廃止しました。 その代わりとして採用したのが、「テキスト原稿のバージョン管理」という編集スタイルです*1。
テキスト原稿のバージョン管理による編集の最大の強みは、「一連の編集フローにおいて徹頭徹尾コンピューターを活用できること」です。 おかげで、上記のような辛い事態が原理的に起こりにくくなります。
ただし、編集スタイルが従来とはまったく違うので、書籍に携わるステークホルダー全員がその変化を抱擁する必要があります。 実際、自分もいきなり従来の編集スタイルからこの編集スタイルに切り替えたわけではなく、最初の数年間は自分が直接関与する部分だけで小さく始めました。 そこから徐々に「自分が直接関与する部分」を増やしていって、完全に切り替えできるまでにはおそらく数年かかっています。
具体的にどうすればいいのさ
こういう話をすると、往々にして、「そうはいってもGitのようなバージョン管理システムは本の編集には向かないのでは？」という方向に議論が進みがちです。 実際、「Gitでテキスト原稿を共有してみたけど、著者とのコラボレーションがうまくできてる気がしない。どうすれば…」と感じたことのある編集者は少なくない気がしています。 これまでの自分の経験でも、バージョン管理システムをそれまでの編集フローに導入しても、新たなフラストレーションを生むだけに終わることが多々あります。
しかしこれは「Gitのようなバージョン管理システムは本とかの編集には向かない」ことは意味していません。 あくまでも、「従来の編集フローをサポートしてくれるツールではない」というだけです。 というか、前節で触れたように、ぼくがテキスト原稿のバージョン管理を採用しているのは、もともと「誌面レイアウトしたPDFとか紙に赤字を入れる」という従来の編集のやり方を捨てるためです。 従来のやり方を捨てる勢いがなければ、テキスト原稿のバージョン管理も、そのためのツールであるGitのようなシステムも、本領を発揮できないというだけです。
従来のやり方を捨てるといっても、具体的にはどうすればいいんでしょうか？
ここで、編集という仕事がそもそも何をする仕事だったかに立ち返りましょう。
私見では、編集とは「原稿のありうべき形」をいろいろ検討し、そのなかで最適な姿を著者と選択していくという仕事です。 原稿→脱稿→初校→再校→…という進行をこなしていると、どうしても「原稿を段階的に改善していく」という発想になりがちですが、実際にそのフローの各段階でやっているのは、原稿を修正しうる無数の可能性を吟味し、それを赤字やコメントという形にして著者や組版担当者と共有しつつ適用する、という作業なはずです。
バージョン管理システムが有効なのは、この作業、つまり「原稿にありうる無数の可能性を追求する」という部分です。 無数の可能性は、Gitのようなバージョン管理システム上では「ファイル間の差分」という形をとります。 「原稿にありうる無数の可能性」を、コメントや赤字のようなコンピューターで管理しにくい形でなく、ファイル間の差分として見ることが、テキスト原稿のバージョン管理という編集スタイルの勘所です。 言ってみれば、「修正案を作りまくっても、Gitが勝手にうまいこと管理してくれてるんだから、なにも気にしなくていいぞ、ひゃっはー」という感覚です。
まとめます。
- 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する
- そのために、「原稿はコンピューターで差分を自動取得可能な状態でなければならない」という感覚に慣れる
- それらの「差分」をうまいこと管理してくれるのがGitのようなバージョン管理システムだと理解する
- 著者と編集者が互いにこの感覚を持てるようになれば、「テキスト原稿に対する書き換え案を出しまくる」ことで編集ができるようになる
最後に宣伝です。もし「自社で積極的にテキスト原稿のバージョン管理を検討したいから、このへんのノウハウを聞かせてほしい」という出版社がありましたら、info@lambdanote.com にぜひお声がけください。
プログラミングにおける「納得」と『Goならわかるシステムプログラミング 第2版』
「納得」欲
パソコンやブラウザ、あるいはスマホで使うアプリケーションを作っているとき、自分がやっている「プログラミング」という行為にどこまで「納得」できているでしょうか？
「プログラミングという行為への納得」、ちょっと耳慣れない概念ですよね。実をいうと、さっきこの記事を書き始めたときに思いつきました。プログラムを書いていると、エラーみたいな露骨な躓きがない場合でも、なんかもやもやすることがあります。このもやもや、少なくとも自分は、以下のような側面で一定の「納得」に至っていないことが原因であるような気がしています。
- アプリケーションの仕組みをデータ構造やアルゴリズムの言葉で説明しきれるぞ、という側面での「納得」
- 意図通りの挙動になることに設計レビューやユニットテストや動作検証を通じて確信が持てるぞ、という側面での「納得」
- コードがコンピュータやネットワークという物理的な装置の上でどう処理されるのか想像できるぞ、という側面での「納得」
アプリケーションを書くために、プログラマー個人がこれらすべての「納得」を満たす必要はありません。プログラマー個人が「納得」できていなくても、コンピューターと計算機科学の圧倒的な力によって、多くの課題は解決できてしまうからです。
というかむしろ、課題解決にとって必要なのは上記のような意味での「納得」である必要はない、と言うほうが適切かもしれません。「あるAPIに従ってコードを書けば解決する」ような課題なら、「APIリファレンスどおりにコードが書けている」ことが「納得」になるでしょう。フレームワークの規約や設定も同様です。そうやってアプリケーションを書くプログラマーが「納得」しやすい側面を課題に合わせてうまく再定義してあげられるのが、プログラミングという行為のすごいところだとも言えます。
そうはいっても、やはり上記に挙げた3つの側面に対する「納得」はちょっと別格に思えます。特に3つめの「納得」が曲者です。自分が書いたアプリケーションと、CPUと、その間でなにかしているっぽいOSとの関係について考えると、あまりにもギャップが大きすぎて、ちょっとどこから「納得」すればいいのかさえわかりません。そういうとき人は、OSを作ってみればわかるかもと期待してそういう本を買ったり、CPUを作ってみればわかるかもと期待してそういう本を買ったりするのだと思います（ぼくも買いました）。
ここで厳しいのは、「納得」したいという欲求は「原理から知りたい」という欲求とはやや違っているので、すべてを自分で作ってみるとなると往々にして「重い」ことです。もちろん、自分でも作ってみたいという気持ちは富士山並に高いんですが、いかんせん重い。これが富士山であれば、Googleマップで山頂までの登山道が見られて「こんな道を歩いてくのかー」と納得できます。コンピューターについてはどうでしょうか。自分がふだん書くようなアプリケーションからOSやCPUの世界を手軽に納得するすべはないでしょうか？
『Goならわかるシステムプログラミング』が改訂しました
そんな「手軽な納得」を目指して書かれた本、『Goならわかるシステムプログラミング』が改訂しました。本書は、アプリケーションプログラマーの「OSやらCPUやらの仕事について納得したい」という欲求に効くように書かれています。つまり、ものすごく雑にいうと、「プログラムとか書けるけど、よくよく考え始めると理解できてなくて釈然としないあれこれ」に答えてくれる本です。なんでそれが本来の意味ではシステムプログラミングできない（OSを作れない）はずのGo言語という枠組みで可能なのか、その裏にGoのどんな抽象化が潜んでいるのかについては、本書を実際に読んで確かめてください。今回の改訂で、全体にこまごまと古い情報が見直されているので、「すでに『Goならわかるシステムプログラミング』を読んで後輩に進めたいけどちょっと前の情報もあるからなあ」と思っていた方には安心して他の方に推薦してもらえるようになっています。
さらに今回の改訂版では、ひととおりの「納得」が得られた最後の最後に、さらに「デバッガーがどうしてそんな行為に使えるのか」についての解説も追加されました。本書では「OSやらCPUやらの世界」を覗くツールとして「デバッガー」を使います。富士山をGoogleマップで登るように、本書ではアプリケーションからデバッガーで下層に降りていくわけです。そうやって、ふつうのプログラムが実行されるまでの流れを見るのに、デバッガーを使うわけです。しかし、よく考えるまでもなく、そんなことができるデバッガーもそれ自体またプログラムなわけで、当然、そういうことが可能なプログラムのための仕組みもコンピュータというシステムには組み込まれています。本書を通じてふつうのプログラムの裏側を「納得」できたら、最後にそのツール自体にも「納得」できるようになったのが、今回の改訂の面白いところだと思っています。
もうひとつ大きな加筆として、そうしたプログラムの実行を陰で支える存在のひとつである「シェル」にも新たに一章が割り当てられました。もちろん、この章でコマンドシェルの使い方が説明されているわけではありません。この新しい章は、「bashの使い方を学ぶことがLinuxを学ぶことではない」といった事実に改めて「納得」するための章だと言えるでしょう。シェルをめぐる話がコンピューターシステムについて「納得」するための本に入っているのは、個人的にとてもポイントが高いバージョンアップだと思っています。
最後にもうひとこと。本書は2016年-2017年ごろにAscii.jpで連載していた記事からのスピンオフで、ほとんどの内容については当時のままそちらでも読めます。興味はあるけど本を買う気はないよという方も、ぜひAscii.jpの連載をご覧ください。きっと、「アプリケーション作ってるときのアレはこういうことだったのか！」って納得できる話が少なからず見つかるはずです。
2022年賀状（PostScript定期）
リンゴの話
（pyspa Advent Calendar 2021 17日めの記事です。昨日は@aodagによる「swayでwayland」でした。swayよさそうと思ってapt installしたらbusterにはなかったので、bullseyeに上げている間に書いています）
大学を出てニートをしていた時分には、リンゴ1個で昼ご飯を済ませることがあった。 そこだけ切り取るとアメリカの小学生っぽいけど、父方の実家である弘前の叔母がリンゴを箱で送ってくれて、でもすでに家族の団欒でリンゴを食べるような機会もなく、悪くなる前にがんばって毎日1個ずつでも食べていた、というのが実態に近い。 バイト先で昼休みにリンゴを丸かじりするのは、片手で済ませられるし、一人で過ごしたい自分の性にも合っていた。
就職して自分の家族をもってからは、わざわざ自分でリンゴを買って食べることもあまりなくなった。 20代までに一生分のリンゴを食べたつもりでいたし、リンゴジュースは好きだけど、それはどちらかというと香料産業のパワーだ。 リンゴはまあリンゴだし、わざわざ買って食べることもないな、という温度感。 余談だけど、台湾に行くと当地でのリンゴの人気がすごくて、「リンゴを食べに札幌に行くツアー」とか見かける。 なんでリンゴのために日本に行きたいのか、素で疑問だった。 そもそも札幌はリンゴの産地じゃないし。 まあ、こっちもマンゴーを食べに玉井まで行ったりしているので、どっちもどっちではあるのだけれど。
一年前までの自分のリンゴ観はこんな感じ。 そんな中、2020年の晩秋に近所のスーパーでたまたま「ぐんま名月」という銘柄のリンゴを見かける。 それまで群馬をリンゴの産地として意識したことがなかったし、なにより群馬だし、その名前を冠する心意気がおもしろくてつい買ってみた。 つまり、とくにリンゴが食べたかったわけではなく、いわばジャケ買いした。
そしたら、これがびっくりするほどうまいでやんの。
とくにすごいのは香り。 すごくリンゴ。 リンゴそのもの。 リンゴなんだからリンゴなのは当然なんだけど、香料に慣らされた自分の感覚さえ裏切るリンゴらしい華やかな香りがある。
しばらくは、そのスーパーでぐんま名月を見かけるたびに買って帰り、夕飯後に家族で食べるのが楽しかった。 ぼくがリンゴをなかば無視していた20年のあいだにリンゴ業界は確実に進化していたという再発見の興奮みたいな高揚感もあった。
もっとも、あとで調べたところ、ぐんま名月は実際には1991年にはすでに品種登録されている。 だから、この20年で進化したのはむしろ流通なのかもしれない。 実際、ぐんま名月ショックを経て町で売られているリンゴに自分の意識が向くようになると、現在ではわりといろいろな種類のリンゴが流通していることに気が付いた。 12月になると、ぐんま名月はあまり店頭に出回らなくなるが、「シナノゴールド」や「王林」のようなリンゴはまだまだ買える。 これらがまたうまい。 うまいし、いろいろな種類を食べていると味や触感のバラエティが見えてきて楽しい。
そうやって自分の感度が上がってくると、ごくふつうのありきたりなリンゴ、つまり「サンふじ」の完成度の高さを知ることになる。 サンふじ、見た目はぱっとしないけど、甘味と酸味のバランスに安定感があって、じわじわおいしい。 それでも固体や産地による差があって、これがまた楽しめる。さらに12月になると「蜜入り」と銘打った完熟のサンふじも出回る。 情報量があがって解像度が高くなることで、ありきたりと思っていた食べ物がこうも楽しくなるのだな。
年が明けると、さらにいろいろな品種のリンゴが出てくる。 そのころから、それまで放置気味だったInstagramのアカウントをリンゴ記録帳として運用するようになった。 そして珍しいリンゴに出会ったら必ず買う。これは「なかのきらめき」という2018年に品種登録されたばかりのリンゴで、柑橘類的な酸味がうまい。 今年も流通し始めている。インターネットによると「なかののきらめき」らしいんだけど、近所のスーパーでは「なかのきらめき」で、いろいろ謎が多い。
ほどなくして、小学館から出ている『りんご だんめん図鑑』という本を知り、リンゴへの関心がさらに高まった。 この本には固さと甘味-酸味の2軸四象限でリンゴを分類した図がついており、それをみながら「今年リンゴを再発見する前にシーズンが終わってしまった「秋映」とかを来年は食べてみたいね」という感じで夢が膨らむ。
そして待ちに待った2021年のリンゴシーズン到来である。
10月末には複数の入稿＆締め切りを控えながらも我慢できずリンゴ狩りに行った。
これは「陽光」という希少品種で、もちろん甘いし、酸味もはっきりしているし、見た目の赤も鮮やかだしで、トータルな迫力がある。生で食べられる紅玉という趣き。
そして、もぎたては本当にうまいな。 来年はぜったい、ぐんま名月を狩りに行くぞ。
2021年のリンゴシーズンはまだまだ続くので、この記事をみてリンゴが気になった方は、いまからでもいろいろ楽しめます。 ちなみに食べ方だけど、皮ごと8分の一にカットする（以下のインスタの写真の2枚めみたいな感じ）のが風味がもっとも楽しめる気がするのでおすすめ。
