golden-luckyの日記

ツイッターより長くなるやつ

『RubyでつくるRuby』の読み方(私論)

本記事は、ラムダノートで発売している『RubyでつくるRuby』を買っていただいた方に「読んで」とお願いするための「私家版、読み方のおすすめ」です。また、この本は当社の本のなかでも過小評価されているところがあると思うので、「気になるけど買ってない」という方に興味を持ってもらうことも目的としています。


本書『RubyでつくるRuby』を買った人にも、まだ買っていない人にも、とにかくまず意識してほしいのですが、この本はRubyの解説書ではありません

じゃあなんの本かっていうと、これは「そもそもプログラミング言語でプログラムを書くって、なに?」という根本的な問いへの取り組み方を教えてくれる本です。

もう一度言いますが、この本はRubyの解説書ではありません。なので、「Rubyを使うつもりはなくて、PythonとかJavaScriptが好き」っていう人や、「それらのプログラミング言語をいままさに勉強している」という駆け出しエンジニア、その段階から抜け出すための次の一歩を探している人、そういう、「Rubyとあんまり関係ない人」にも読んでほしい本です。いやむしろ、そういう人こそが読むべき本だとさえ言いたい。

もう一度繰り返しますが、この本はRubyの解説書ではありません。なので、この本を読んでも、Rubyによるプログラミングには詳しくなれません(Rubyに詳しくなりたい人には『研鑽Rubyプログラミング』がおすすめ)。その代わり、たった100ページちょっとで「(Rubyに限らず)プログラミング言語はどういう仕組みになっているのか」を知る入口に立てます。

というわけで、以降では、Rubyに興味があるかないかに関係なく次のような悩みを抱えている方々が本書をどう読むのがおすすめか個人的な意見を書いてみたいと思います。

「プログラムの書き方がいつまでたっても覚えられない」という人

「プログラミングの勉強をしてる」という人の話を聞いてみると、「やりたいことを解決するための書き方」を覚える努力をしているように見えることがあります。覚える努力をしているわけでなくても、「プログラミングできる」と「プログラムの書き方を知ってること」を半同一視してしまっている人も少なくないのではないでしょうか。

「特定のプログラミング言語でアプリケーションをささっと作れるようになる」ためには、そういう勉強も必要なのは言うまでもありません。でも、そこでちょっと立ち止まってみてほしいのですが、昨今、「特定のプログラミング言語の書き方に詳しい」だけで済むことはそう多くありません。さまざまなプログラミング言語について知る必要があるたびに、「その言語での書き方をたくさん覚える」をがんばるしかないのでしょうか?

これが英語や中国語のような自然言語だと、わりとそういう感じに「特定の言語の使い方を覚える」をがんばるしかないところだと思います。 でもプログラミング言語は、かならずしもそうではありません。多くのプログラミング言語は、それなりに共通する考え方の基盤に沿って作られているので、その考え方を知っているだけで、だいぶ「新しい言語」に対する見え方が変わります。

実を言うと、大学の情報科とかで勉強するのも特定のプログラミング言語の書き方ではなく、そういう「多くのプログラミング言語の作りの背景にある共通する考え方」だったりします。なので、大学で使うような計算機科学の教科書とかを読むと、それを勉強できたりします。でも、教科書を一人で読むのはなかなか大変ですよね。

その点『RubyでつくるRuby』なら、説明を頭から読んで練習問題を一通りやってみることで、そういう計算機科学の教科書に書かれてるような話のさわりを体験できます。この本でつくるのは本物のプログラミング言語Rubyのうちでも「多くのプログラミング言語の作りの背景にある共通する考え方」の部分だけですし、教科書的に退屈な部分は潔くカットしつつ、飲み込みにくい概念にはイラストもたくさん入っているので、なんとか踏ん張って第6章までは読みとおしてみてください。

「どうしてプログラミング言語でプログラムが書けるのかわからなくて夜しか眠れない」という人

プログラミングの入門書にある例題を書き写して「なるほど同じ結果になるな」って確認できたけど、「だから何?」って思ってしまうこと、ありますよね。「"Hello World" を出力しろ」というプログラムを書いて、それをコンピューターで実行したら "Hello World" が出力されるっていうのは、それだけを見ると面白くもなんともありません。

でもよくよく考えてみると、「あるプログラミング言語ソースコードを書くと、それがコンピューターで実行されて結果が出てくる」って、ちょっと不安になるくらい何が起きているのか意味不明じゃないですか? そもそも、「プログラミング言語で書いたソースコード」と、「コンピューターで動くプログラム」は、同じものなんでしょうか? PythonRubyで書くソースコードは違うけど、どちらも「コンピューターで動くプログラム」なんでしょうか?

そういえば、PythonRubyで書いたプログラムを実行するには、pythonとかrubyみたいなコマンドを使います。そういうコマンドで「プログラミング言語で書いたソースコード」を「コンピューターで動くプログラム」にしてる気がしますが、pythonとかrubyみたいなコマンドはどうやって動いてるんでしょうか? っていうか、pythonとかrubyみたいなコマンドはどうやって作られてるんでしょうか?

こういう不思議の連鎖って、いったん躓くとなかなか抜けられず、先に進めなくなりがちですよね。

RubyでつくるRuby』は、そういう「プログラミング言語というものの不思議さ」を直接味わえるようになっています。この本でつくるRuby(の機能縮小版)は、pythonとかrubyみたいなコマンドのように、「プログラミング言語で書いたソースコード」を「コンピューターで動くプログラム」として実行するための機能を持ったプログラムです。しかも「この本でつくるRuby」というプログラミング言語で書いたソースコードも、「この本でつくるRuby」というプログラムで動かせます。

この不思議な関係は、実のところ、現代のコンピューターにおいてプログラムを開発したり実行したりする世界観そのものでもあります。『RubyでつくるRuby』は、わずか100ページちょっとでそこまで辿りつけてしまう本なのです。ぜひ、自分でコードを書きつつ、最後の第9章まで通読してみてください。

プログラミング言語を作ってみたい」という人

しつこく繰り返しますが、この本はRubyの本ではありません。そうはいっても、みなさんが使えるようになりたいプログラミング言語PythonとかJavaScriptかもしれず、残念ながらこの本にはPythonJavaScriptのことは書かれていません。最近ではRubyというプログラミング言語のことを「Webのエンジニア募集でたまに名前を見かけるやつ」くらいにみなしている人もいるような気がします。そういう人にとって『RubyでつくるRuby』は役に立たない本なのでしょうか?

そういう方におすすめなのは、『RubyでつくるRuby』を読みながら『PythonでつくるPython』とか『JavaScriptでつくるJavaScript』を自分でやってみることです。これには次の2つの意味でものすごい教育効果があると思います。

  • それぞれの言語のソースコードの文字列を読み込んで抽象構文木に変換するパーザを自分で書くことになる
  • それぞれの言語の挙動を、とくにRubyとの対比で、いま以上によく知れる

1つめの話は、本書を読むだけでは手が出ない話題なので、これは上級コースになります。でも、裏を返すと、本書はそういう上級コースの人でも楽しめる内容だとも言えます。

さらに、「この本でつくるRuby」を拡張していろいろな実験をしてみるのもおすすめの上級コースです。たとえば著者本人の手で漸進型が導入された拡張が作られたりしています。Rubyといえば動的型付き言語なので、これはもはやRubyではありません。でも、そんな感じで「Rubyよりむしろプログラミング言語そのものに興味があるすべての人」にとっておすすめの本が『RubyでつくるRuby』なのです。


最後に、『RubyでつくるRuby』がRubyに興味のない人にとっても価値がある本であるにもかかわらずRubyを題材として採用している理由についても触れておきましょう。これは、本書の著者である @mametter 氏の強みがRubyだからです。

しかし、著者はRubyしか知らない人ではありません。C言語のある種のプログラムに関しては世界の第一人者で、なんなら「"Hello World" のように自明なアプリケーションではないコードを書くのに使ったプログラミング言語の数」でも世界でトップクラスに入るような人です。このことからも、本書がRubyの入門というわけではなく、プログラミング言語そのものという泥沼トピックへの入口として書かれた本であることがうかがい知れるでしょう。

2023年賀状(PostScript定期)

ちょっと趣向を変えて、今年は具象です。 乱数を使って1枚ずつ仕上がりを変えるみたいな小細工も今年はやめた。

github.com

楕円を三つ組み合わせているだけなんだけど、文字列のパスと楕円のパスとで切り出しが入れ子になってるのと、それを楕円ごとにやらないといけないので、丁寧なgsave/grestoreが必要でめんどくさい。 グラデーションは、色空間をRGBではなくHSVにするだけで途中にどす黒い領域は発生しなくなるんだけど、一次関数で変化をつけるといまいち知覚的にきれいに見えなかったので、対数を使っている。文字列と背景とでそれぞれ別々にグラデーションを適用するのもめんどくさかった。 例年に比べて地味なのに、めんどくさい度は高かった気がする。

『プロフェッショナルSSL/TLS』の読み方(私論)

本記事は、ラムダノートで発売している『プロフェッショナルSSL/TLS』を買っていただいた方向けに「読んで」とお願いするための「私家版、読み方のおすすめ」です。本なので、どう読んでもらってもいいんですが、「買ったはものの積読になっている」という方の背中を押せればと思います。


この本は、プロトコルであるTLSの解説書であると同時に、「インターネットで安全にやっていく」ための感覚のベースラインを与えてくれる本です。 そういうつもりで、まずは第1章を読んでみてください。 知ってる話も知らない話もあると思いますが、20ページくらいしかないので、とりあえず読みましょう。 ここを読むと、現代のTLS以前の古典的な暗号、ハッシュ、認証について、安全かどうかを考えるためのフレームワークが得られます。 カタログ的ではないので、そういうのは期待しないでください。 なお、現在のバージョンには「認証付き暗号」という重要な概念が抜けていますが、これについては次の第2章(および最新の電子版に収録された付録A)で出てきます。

第1章を読んだら、TLS 1.3に関する付録AがあるPDFをおもちであれば、そこを読みましょう。 ない人は、TLS 1.2ベースになりますが、そのまま第2章へ。 本書はTLSの「プロトコルとしての仕様」を説明する本ではないんですが、なにはともあれTLSプロトコルとしてのノリは把握しておく必要があります。 この章(もしくは付録)については、多少ぴんとこない話があっても読み飛ばして、とりあえず目をとおしてください。 そういう「この章だけを読んでもぴんとこない」部分も、あとの章を読むと「そういうことね」と思えるはずです。

次の第3章も、とりあえず「ぴんとこない部分」は飛ばしていいので、目をとおしましょう。 TLSというプロトコルは、インターネットにおいてはPKIというインフラの上で使うことを前提になっていて、ここはそのPKIの話です。 この章も、どのみちあとで何度も立ち戻ってくることになるので、初見は「だいたいこういうことが書いてあるんだな」という軽い気持ちでまずは目を通してください。

第4章から第7章は、主に歴史の話です。 ほんとは歴史の話というわけではなく、歴史をとおして「なんでいまのTLSPKIがこういう姿になっているか」を知るための章なんですが、歴史の話と思って読むとさらさら読めるはずです。 この部分を読みながら、「あれこれはなんの話だっけ?」とおもったら第1章から第3章や付録Aの該当部分に検索や索引を頼りに立ち戻って「なるほどね」と思う、というのが、本書の効率的な読み方かと思います。

が、実はもっと効率的な読み方もあります。それは、次の第8章を中心とした読み方です。 第4章から第7章は、分脈を知るには不可欠なんですが、分脈はいいからまずは具体的な話をしてくれ、というときもあるでしょう。 そういうときは、「第8章から読む」というかなり乱暴な読み方もありです。 もちろん、それで意味がわからない部分については第1章から第3章や付録A、あるいは第4章から第7章に向き合ってください。

第9章以降は、かなりボリュームはあるものの、最初はボーナスステージという扱いで、「実務で必要になったら読む」でもいいと思います。 とくに第13章以降は、現在ではすべての人に必要な情報というわけでもないので、ここを読み切らなくても「読んだ」といって大丈夫です。

というわけで、この本は、ふつうのエンジニアがTLSについて知っておくと捗るすべてのことが書かれた本です。 文字通り「すべて」なんですが、「ふつうのエンジニアが知っておくといいこと」っていうのがポイントで、「前のほうに書いてある細部を全部を頭に入れておかないと読み進められない」という本ではないので、上記のような「本の構成」を把握しながらさくさく読み進めると、ボリュームのわりには「よめるよめるぞ」となる本ではないかと思います。 もちろん、実際に手を動かす段になるとわからないことがいろいろ出てくるはずですが、少なくとも「なにを調べたらいいか」あたりの勘はつくはず。

買った人はぜひ読んでみてください!

ラムダノート第8期を迎えました

2015年12月に自分で出版社を立ち上げたとき、うっすらと決めていた覚悟は、「ひとまず10年は続ける」でした。

それまで15年くらい、技術系版元として歴史も規模もそこそこある出版社で企画編集をやっていたので、「だいたい何部くらい売れれば一人なら食っていける」といった程度の雑な算段はあったものの、かっちりした事業計画があったわけでもなく、「まあ、しばらくは前職の退職金を食いつぶしながら最初の何冊かを作ればいいかな」などと気軽に考えながら、むかし作った本の読者だったり有識者レビュアーだったりでお世話になっていた時雨堂という会社に遊びにいき、そんな浮ついた起業計画を雑談のつもりでしたら、社長の @voluntus に「お金出すよ」と言われ、「えっ」って戸惑っているうちに税理士さんを紹介してもらい、定款ができて、気づいたら ラムダノートという出版社 ができていました。

あれから満7年。2022年12月にラムダノートは第8期を迎えることになりました。会社をスタートできたのは時雨堂のおかげ、本を出せたのは著者や訳者のおかげ、なによりもこうして「本を売ってやっていく」ができているのは本を買ってくれる読者のおかげです。

10年という当初のぼんやりした目標まではもうひと頑張りありますが、よく考えたらコンピューターとネットワークの出版社なんだから節目の基数は2であるべきだし、1000_2周年をむかえるこのタイミングで感謝祭として大セールをやっています。協賛は再び時雨堂です。クーポンコード「時雨堂と一緒にラムダノートの8周年突入をお祝いしよう!」を入力すると電子書籍がほぼすべて半額。ほんとうにありがとうございます。

余談ですが、この「クーポンコードによる宣伝」という協賛の企画を思いついたのも時雨堂社長の @voluntus です。天才かと思った。

このクーポンコードの文字列「時雨堂と一緒にラムダノートの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. その一方で、出版業界という粒度で見ると、ちっとも変わる気配がないし…

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 にぜひお声がけください。

*1:実際にはこれに加えて「自動組版」という技術も重要なんですが、今日はこの話はなし。

プログラミングにおける「納得」と『Goならわかるシステムプログラミング 第2版』

「納得」欲

パソコンやブラウザ、あるいはスマホで使うアプリケーションを作っているとき、自分がやっている「プログラミング」という行為にどこまで「納得」できているでしょうか?

「プログラミングという行為への納得」、ちょっと耳慣れない概念ですよね。実をいうと、さっきこの記事を書き始めたときに思いつきました。プログラムを書いていると、エラーみたいな露骨な躓きがない場合でも、なんかもやもやすることがあります。このもやもや、少なくとも自分は、以下のような側面で一定の「納得」に至っていないことが原因であるような気がしています。

  1. アプリケーションの仕組みをデータ構造やアルゴリズムの言葉で説明しきれるぞ、という側面での「納得
  2. 意図通りの挙動になることに設計レビューやユニットテストや動作検証を通じて確信が持てるぞ、という側面での「納得
  3. コードがコンピュータやネットワークという物理的な装置の上でどう処理されるのか想像できるぞ、という側面での「納得

アプリケーションを書くために、プログラマー個人がこれらすべての「納得」を満たす必要はありませんプログラマー個人が「納得」できていなくても、コンピューターと計算機科学の圧倒的な力によって、多くの課題は解決できてしまうからです。

というかむしろ、課題解決にとって必要なのは上記のような意味での「納得」である必要はない、と言うほうが適切かもしれません。「ある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定期)

毎年のやつです。

github.com

f:id:golden-lucky:20211225211702p:plain

昨年一昨年は描画よりアルゴリズムに走ったけど、今年は初心に戻って描画系です。「2022」という文字のアウトラインに沿って「2022」という文字列を繰り返しています。flattenpath でパスを lineto の列にして pathforall するという、わりと古典的な手法なので、とくに芸はない(ソース)。本番はもうちょっとカッコいい書体を選びたい。