flickr2015/09/24『あなたの知らない超絶技巧プログラミングの世界』は誰が読むべきか遠藤侑介さんといえば、Quineをはじめとする変態プログラムの世界的なタツジンとして有名ですが、そのむかし遠藤さんに向かって「Quineの本とか、売れないことが確実ですね」という趣旨の発言をしたことがあります。遠藤さんがブログやコンテストで発表していた変態プログラムには個人的にとても魅力を感じていて、翻訳書で一緒にお仕事をする前から楽しませてもらっていたのですが、さすがに書籍の企画ネタにするのは難しいなあ(売れるようにするのが難しいという意味で)と思っていたのです。企画を担当した編集者もずいぶんな変態に違いありません。いうわけで、今月発売された遠藤侑介著『あなたの知らない超絶技巧プログラミングの世界』という本をさっそく読みました(下のリンクはアマゾンで、9/24現在ではまだ予約中だけど、なぜか都内の大型書店にはふつうに配本されている)。読んだといっても、ざっと目を通したレベルであって、内容をきちんと咀嚼できるほどには読み込んでいません。いうか、本書の内容をきちんと咀嚼できる日が自分の人生にやってくるのだろうか、というのが率直ないまの気持ちです。本書は、いうなればリストやパガニーニが懇切丁寧に自分の楽器演奏テクニックを言語化して解説してくれているようなものです(実際、本書のタイトルの「超絶技巧」はリストの同名の練習曲に由来するようです)。シューマッハが自分のドライビングテクニックを教本としてまとめてくれているようなものです。その意味では、この本、けっして「わかりやすい」とは言えないと思います。「わからない」ことをわざわざ楽しむための本なので、「わかりやすくない」のが必然なんでしょう。解説自体はとても丁寧に書かれているので、必要になったときに必要な箇所を真剣に読めば大丈夫そうだなと判断して順調に読み飛ばしました。しても、この本の内容が「必要になるとき」なんて自分にあるんだろうか......。(という読者の葛藤を見越して「必要になるとき」を強制発動するための「練習問題」がついているところに著者の心意気を感じました。)「この本が必要なのは誰だろう」という、おそらく書籍企画にとって根源的な問題は、著者の遠藤さんをだいぶ悩ませたんではないかと思います。本文を読んでいると「実益は期待しないで」といった趣旨の開き直りにちょくちょく出くわすし、「まえがき」に至っては「実用性という観点は雑念」とまで言い切られています。「雑念」だと言った鼻の先が乾かないうちに「ある種の気づきを与えてくれる」とか言って実用性がほのめかされています。独断ですが、本書の対象読者は大きく次の3つに設定できる気がします。超絶技巧なプログラムを愛めでたい人たぶんこの本のいちばんありがちな楽しみ方は「めでる」でしょう。実際、第1章は超絶技巧プログラムを眺めて楽しむという位置づけだし、後続の章も眺めているだけで楽しくなります。ヴィンテージコンピュータの美』なんかと同様に、計算機とその周辺にある種の美を感じる人はとりあえず購入して損はしないはずです。超絶ではないにせよプログラミングの技巧に興味がある人この本は、Quineのようなプログラムを書きたい人だけでなく、ある種の技巧的なプログラムを書きたい人にとってはそこそこ実用的です。CUIのアプリでアニメーションをする方法のような実用的で具体的な内容が丁寧に解説されている本は、ほかにあまりない気がします。zlibを使わずにPNGを作る例など、プログラミングに必要な潔さ(教科書には書いていない)を学べます。プログラミングコンテストとかで応用できたりできなかったりする気がします。出たことがないので憶測です。数学基礎論や計算機科学の深めの話に踏み込んだコラムの数々が実に有益な読みどころです。Quineの存在証明をRubyで書き下してくれている本なんて、たぶん世界中でほかにはなかったし、これからもないと思います。Programmers)』とかが大好きな人はコラムだけでも興奮できると思います。まとめると、本書は(ほぼ)世界一の人がそのテクニックを披露し、伝授してくれて、さらに深堀するという貴重な本です。遠藤さんが書いたこの本を読みたい人は世界中に少なからずいるでしょう。いまのところ本書は日本語でしか楽しめないので、日本語ネイティブで本当によかった。9月28日にはジュンク堂池袋店でサイン会もあるそうなので、Quineなサインをもらいにいこうと思います。全体を通してRubyがメインで使われているので「Ruby限定の内輪テクニック集」に見えるかもしれませんが、それに終始する本ではないのはさすが遠藤さんだと思いました。唯一残念なのは索引がないところです(上記の2と3が対象読者なら必須だと思う)。Grahamのカタカナ表記は「ポール・グレアム」のほうがいいと思いました。共有2015/09/10Wikipediaのエントリを束ねてEPUBを作れるようにしてみたWikipediaには好きなページを集めて本を作れる機能があります。左側のメニューにある[印刷/書き出し]から[ブックの新規作成]というメニューをクリックすると、それ以降に閲覧する各ページで「ブッククリエーター」というツールバーが以下のような感じで有効になって、そのツールバーで自分が本に収めたいページを追加していけるという機能です。追加したページを並べて自分だけのオリジナルの本が作れます、というサービスです。何年か前はこのブッククリエーターの出力形式としてPDFのほかにEPUBを選べたのですが(参考)、いつの間にかPDFとプレーンテキストのみになってしまっていてEPUBを作れません。これは日本語版だけでなく英語版でも同様です。べつにWikipediaをEPUBで読めないからといって困ることはないのですが、自分が開発して自分で使っているEPUB作成ツールのテスト用にWikipediaのページを使えたらいいなと思って、Wikipediaのエントリをいくつか指定してEPUBを生成できる仕組みを作ってみました(参考)。動機が動機なのでローカルでのみ使うつもりだったのですが、AWSでデモが動くようにしてみました(ただしエントリの上限を3つにしているので3章までの本しか作れません。ダウンしてたらごめんなさい。あと英語版Wikipediaのみに対応)。以下のような感じにEPUBが生成されてダウンロードできるようになるはずですが、Mediawikiのパーズで力尽きたので、WebアプリとしてもEPUBジェネレータとしてもまだぐだぐだです。低品質の勧めに従って公開してみます。共有2015/09/01職務経歴書いろいろあって職務経歴書を作成してみることにしました。お便りお待ちしています!要約すると理工系出版社の開発部という部署で約13年間半、主にコンピュータネットワークとプログラミングの本を企画し、制作してきました(「企画制作に携わった主なコンテンツ」および「企画者として公式に社内に名前が出ている、かつ、制作でも中心だった書籍の一覧」を参照)。TCP/IP関連書籍と、翻訳技術書は、たくさんの技術者の方に手に取ってもらえた(願わくば役に立てた)と思います。読者が読んだことを後悔しない本を作るのは当然として、著者や訳者が出版したことを後悔することがないように、編集制作プロセスの透明化にも努めました。通常、著者や訳者は、出版物に対する責任があるにもかかわらず、その最終的なデータを手にすることがありません。著者による校正の終了後に編集者が内容のデグレにつながるような修正を勝手に加えてしまった、という話もよく聞きます。そのような悲劇を駆逐するため、すべての制作データをSubversionやGitのリポジトリを介して著者と最後まで共有し、ありとあらゆる編集内容が全員にとって透明な制作フローを採用しました(「バージョン管理システムを利用した制作システムの開発・運用」を参照)。この制作フローにとって欠かせないのが、誰かが作業をリポジトリに反映するたびに最終的な本と同じ組版結果が自動的に生成される仕組みです。書籍の構成や組版は毎回異なるので、そのような仕組みを実際の現場で運用していくために、自分でカスタマイズしやすい自動組版システムを開発しました(「社外での活動」を参照)。必然的に、プロジェクト単位ではありますが、夢のワンソース・マルチアウトプットも実現しました。直近の書籍の多くでは、印刷用PDFとデータ販売用PDFに加え、EPUBも単一のソースからmake一発で生成しています。Requestを活用することで、編集に必要な意見のすり合わせにかかるコストを大幅に低減しました。これらの取り組みにより、原稿の頻繁な見直しが可能になったことで、書籍の品質が大きく向上しました。著者と編集者(組版者)との意思疎通に起因する書籍の不具合もほぼゼロにできました。多人数が同時に並行して書籍制作に関与できることから、外部レビュアーによる協力も得やすくなり、書籍内容のさらなる改善にもつながりました。書籍制作にかかる時間的および金銭的コストも大幅に削減できました。制作に携わった書籍のプロモーションも積極的に行いました。いまどき、どんなに自分が良い本を作ったつもりでも、潜在的な読者にその本の存在が伝わらなければ読んでもらえません。書籍の内容を、必要な人に、できるだけ魅力的に伝えるべく、会社のブログや個人のツイッター/ブログ(これな)を使ってアピールしました。一つ、自分の企画や制作とはまったく別の話として、他者の企画書籍に対するサポートにも貢献しました。具体的には、著者あるいは原稿にとって適切な目次構成案を提案したり、より販売力のある書名を考案したり、カバーの選定に協力したりしました。マンガを用いた技術書シリーズでは、コンセプトに対する提言やコンテンツの技術査読を担いました。企画制作に携わった主なコンテンツ以降、書籍などのリンク先は、無職につきすべてAmazonアソシエイトです。「マスタリングTCP/IP」シリーズなどTCP/IP関連書の企画制作とメンテナンス。同シリーズはネットワーク技術の定番解説書シリーズとして教科書としての採用も多い。第5版』は累計40万部を超えている(はず)。プログラミング言語についての翻訳解説書を多数企画制作。Haskell本とErlang本については、日本語による主要な解説書のトップシェア(当時)。プログラミング理論についての翻訳書籍を多数企画制作。−プログラミング言語と型の理論−』を企画制作。Railsの普及の一助ともなった定番書『RailsによるアジャイルWebアプリケーション開発』をいち早く翻訳企画、改訂のメンテナンス。ソフトウェア開発者の幸せな生き方』など)に多数関与。Amazonで最も売れていた線形代数の参考書『プログラミングのための線形代数』とその姉妹編『プログラミングのための確率統計』の企画制作。自分の会社生活が社会にもたらした価値があるなら、この2冊がたぶんそのハイライト。日本で最初のGit解説書『入門git』の企画制作。SERIES)』など、アジャイル型開発手法に関連した解説書の企画制作。オーム社開発部の出版システムでの書籍執筆」)。原稿の形式は(La)TeXとは限りません。前の記事なのでSubversionベースとなっていますが、最終的にはGitHubベースのシステムを使っていました)。perfect")企画者として公式に社内に名前が出ている、かつ、制作でも中心だった書籍の一覧2006年以降は、ほとんどの制作も自分でやっています(自動組版でな)。このほか、企画に名前が出ているけど制作はほかの人がやった本、どこにも名前が出ていないけど全部制作した本、タイトルや目次構成を提供した本、技術査読をした本などが無数にあります。仁2002/9/24企画制作についてのふりかえり前に勤めていた会社がなくなって、「マスタリングTCP/IPみたいな本を作ってる人がいる会社なら大丈夫だろう」くらいの感覚で応募書類を送ったのが2001年。第2版」と「応用編」、それになぜか「マルチキャスト編」というラインナップでした。MPLS編』の新刊制作が進行中というタイミングだったらしく、そんな縁もあって「マスタリングTCP/IP」の企画制作をやっていた「開発部」に配属されました。その後は、ずっと開発部で本を作ってきました。入社後すぐに企画したのはSIPの解説書でした。QoS制御とかをキャリア網でも本気でやろうっていう機運があったころで、SIP解説書の企画とかぜったいあるだろうと思ってたのですが、社内の誰もSIPすら知らないという真空状態だったので、自分でやることになったのです。SIP編』)の企画制作をとおして、「需要がありそうな技術の解説書を計画し、適切な著者や監修者を探して、制作して売る」という商売の基本的な流れを学んだ気がします。幸いにして、とてもたくさんの方に読んでもらいました。最初の年は、平行して半持ち込み企画もいくつか担当しました。Rubyで極める正規表現』は、かなり手を入れた思い出があります。後者は、自分がRubyを学ぶきっかけになりました(それまではPerlを使っていた)。して振り返ると、「マスタリングTCP/IP」シリーズの担当者みたいな立ち位置が固まってきたのは入社2年目の2003年だったようです。当時のシリーズは、自分の入社時にちょうど第3版が出版された「入門編」こそメンテが続いていたものの、おなじタイミングで出版された「MPLS編」のほうはあまり芳しくありませんでした。そんな中で、「SIP編」の成功をきっかけに、なんとなく自分がテコ入れをはじめることになったのだと思います。RTP編』は、書籍そのもの以上に、あきみちさんとはじめて仕事できたという意味で自分にとっては大きな出来事でした)。低レイヤの解説も欲しいよねということで「ネットワークデザイン編」を企画。マスタリングTCP/IPという枠ではフォローできてなかったソケットプログラミングの入門書も企画しました。余談ですが、このころは外部のプロダクションに依頼して普通にDTPで本を作ってもらっていました。著者校でどうしても入る修正による手戻りの絶望的な困難さを回避したくて、「SSL/TLS編」と「RTP編」では自分で原稿をHTML化してCSSでゼロ校を作り、それを最初の著者校にするという進行を導入していました。このへんの経験は、後年、XML版管理+LaTeXによる自動組版で生きてきます。この入社2年目には企画の失敗も経験しました。Web周りの入門書も必要だよね、という素朴な発想で、CGIとかサイト管理の入門書も何冊か企画したのですが、どれもあまり成功しませんでした。ほめられた話ではないかもだけど、これらを通して「技術書の企画に失敗する方法」を学べたと自覚しています(この年以降で赤字に終わった企画は1冊だけです。翌2004年は、いまになって思うと、このあと数年間の技術書企画制作者としての道を決定づける仕事ばかりだった一年でした。なんといっても大きいのは『プログラミングのための線形代数』で、この本の企画制作では著者の二人から本当にたくさんのことを学びました。「コンピュータ書のように読める数学の教科書が作りたい」という恥ずかしいほど素朴な思い付きだけで平岡さんに話を持ちこんだら鳥肌が立つような原稿が書きあがってきたのは、今思い返しても興奮する体験です。LaTeXで本を作ったのも、轟木さんにカバーをお願いしたのも、原稿の版管理(CVSだけど)を始めたのも、この本が最初でした。メイン企画者ではないのだけど、『マンガでわかる統計学』の企画立ち上げや技術レビューにかかわったのも2004年でした。Software』とか『ITRONプログラミング入門』といった自分にとって名刺代わりになるラインナップを少しずつ増やしていった年だったようです。2006年は、XML原稿からのLaTeXによる自動組版で売り物になる本を作った最初の年でした。それが『RailsによるアジャイルWebアプリケーション開発』です。この本の原著出版社であるPragProg社では、独自のXMLを原稿の形式にしていて、これを翻訳版でもそのまま最大限に使ってやろうと思って正月にGaucheでLaTeXへのコンバータを書いたのでした。India』も、やはりPragProg社の本の翻訳だったので、このときの仕組みをそっくり流用して制作しました。Software』でしょう。自分の企画でもっとも大きな赤字を出した本です。この本からは、内容の良さと利益はまったく相関しないんだという事実を思い知りました。翌2007年あたりから、だんだん、作りたい本を作りたい形に作れるようになってきた気がします。Lisp』と『プログラミングErlang』のように、爆発的には売れないけど意義があったりブランドにつながったりする本(しかも着実に利益が出る本)を企画できるようになってきました。2007年末のオブジェクト倶楽部のイベントで自分たちの本の作り方をプレゼンする機会があったり(登壇したのは同じチームの高尾さん。2008で発表したり、アジャイル界隈の方々やLisp界隈の方々に少しずつ自分たちチームの存在を認知してもらい始めたころです。Haskell"が翻訳企画になったり、自分たちの制作環境でSubversionからの移行を始めていたGitの解説書を出せたり、いろいろタイミングが良かった年でした。発行はこの翌年になる『内科診療ヒントブック』の話を、ブログの一読者として一方的に知っていたmedtoolzさんからいただいたのも、この年のことです。『Scheme手習い』とか『関数プログラミングの楽しみ』とかを通して、価値があると信じる本だけで商売ができるし、そうすべきなんだなという実感を強めました。Schemer"の翻訳とか、『インターネットのカタチ』、『すごいHaskell』、TAPLの翻訳、Bird先生の関数プログラミング本の翻訳、あのカーニハン先生の著書などなど、ものすごい経歴の著者訳者の方々と一緒に、内容も責任も重い、でも楽しい仕事をたくさんしてきました。それまで手探り状態でがんばっていた自動組版化も、良い意味でルーチン化でき、効率よくチームで仕事を回せていたと思います。最後の数年は、自分たちのチーム以外の企画も技術面でサポートできる余裕もでき、開発部全体でよい仕事ができていたと思います。出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「...職務経歴書いろいろあって職務経歴書を作成してみることにしました。機能を使うのが一番お手軽です。編集をお手伝いしました。Blogger.自己紹介Unknown詳細プロフィールを。