ほぼすべての個人が専用の情報端末を持ち歩く社会でありながら、印刷製本された「紙書籍」というパッケージの形で知識や物語に接することを好む人がまだまだ十分に多く、その小売りに特化した店舗が「書店」として成立できていた2024年、それでも年々縮小する需要の前に小規模な書店はすでに次々と姿を消し、紙書籍を求める人たちの受け皿として役割を果たしていたのは都市部に残された大型書店だった。それら大型書店の広大な店頭には無数の紙書籍が並び、しかもそれは毎日のように増大していく。なぜなら紙書籍は、それを生み出すことを生業とする出版社にとって、たとえ読者の手に渡ることがなくても流通に載せさえすれば収益になる商材でもあったからだ。産業の末路である。 紙書籍を好む人の多くは大型書店が好きだったと思う。コンセプトが明確でエッジを効かせた小規模書店への憧れはあるけれど、必ずしも選書や店主が個人のバイブスに合うとは限ら

「うちの学校でもついにプログラミングの授業が始まったよ」 「それは興味深いね。どんなふうに教えてるの？ やっぱりScratchとか？」 「Scratch？ ああ、プログラミング言語のことか。プログラミング言語は使わなくていいんだよ」 「え？」 「小学校で学ぶプログラミングっていうのは、プログラミング言語を覚えさせることが目的じゃないからね。システム思考力とかロジカルシンキングって聞いたことあるだろ？」 「あるかないかでいったら、あるよ」 「プログラミング言語みたいなのは、単なる技術だ。それは仕事で必要な人だけが覚えればいい。子どもたちに教えるべきことは、プログラミング言語みたいな技術じゃなくて、システム思考やロジカルシンキングの延長といえるプログラミング的思考なんだよ」 「プログラミング的思考っていうのが、システム思考やロジカルシンキングとどう違うのか、いまいちよくわからないんだけど…」

かつては出版社の中に編集者という職業があって、著者に執筆を依頼したり、そうして書いてもらった原稿を取りに行ったり、誤字脱字や「てにをは」を矯正したり、漢字や送り仮名の表記を出版社のルールに従って統一したり、それを印刷製本する指示を出したり、そういう仕事をしていました。 誰もが自分のSNSを持ち、ブログのプラットフォームで記事を公開し、中には自分で印刷製本して本の形にして売買している現代、「自分で文章を書いて世間に出す」のに出版社は不要です。いわんや編集者をや。 自分は出版社を作り、そこで編集者をやっているので、この「出版社も編集者も不要」という世界で何をすべきかという問題についてよく考えます。毎度たどり着くのは「必須ではないけど不要というほどでもない」という答えなんだけど、特に「不要というほどでもない」に対する根拠をあまり明確にしてきていない気がするので、少し言葉にしてみようと思います。

昨晩、『コンビニ人間』という原作の存在を知らずになぜか買って積読していた“Convenience Store Woman”を一気に読んだ。英訳されたほうを読んでよかった。たぶん日本語だったら中盤でつらくなって、短い小説だけどきっと挫折していた。 この小説で主人公は、コンビニ店員として生きていることに不満がない、というかむしろコンビニ店員に生きがいを感じているんだけど、同時にそのマインドは周囲からは決定的な社会性の欠如であり欠陥だと見なされている。主人公のマインドは、任意の専門職における「一生現場で働きたい」とまったく同じだ。それが「コンビニ店員」という非正規雇用しか選択肢がない業界であるばかりに、どんなにプロフェッショナルであっても、社会的弱者と同義にされ、それに甘んじているダメな人間という扱いしか受けない。もちろん、勤務先のコンビニでは圧倒的な戦力なので評価はされているんだけど、ある事件

昨日までこのアドベントカレンダーでは、PDFの内部の話から始めて、XMLという構造化文書の話、Pandocで記法を変換する話、EPUBで本というパッケージを作る話というように、徐々にレイヤを上げてきました。今日と明日はさらにレイヤを上げて、出版社の立場の話で締めくくろうと思います。 現在、日本の出版事業の中心は、「版元」「取次」「書店」という3者（いわゆる業界三者）が担っています。 メーカーと小売りの間に卸しがいるという構造は特別なものではありませんが、業界三者がちょっとだけ他と違うところがあるとしたら、書店と版元との柔軟な直接取引が少なく、取次-書店間、取次-版元間での委託取引が中心になっていることです。 この構造を支えているひとつの柱は再販価格維持制度による書籍の定価販売なんですが、この構造のおかげで、日本はかなり書店の数が多い国であり続けました。 2000年代初頭には全国で2万店くら

「2つのgitリポジトリがあって、その片方をもう一方に取り込みたい」という状況を考えます。依存ライブラリのソースを自分のプロジェクトで保持したい、といった状況が典型的でしょう。 この場合、通常は git submodule を使うと思います。 git submodule であれば、他のプロジェクトを履歴ごと自分のソースの一部として管理できて、かつ双方の履歴をきれいに分離できます。 Git - Submodules ただ、双方の履歴が分離できるということは、双方の履歴を混ぜられないということでもあります。そのため、 git submodule は、他のプロジェクトのソースに自プロジェクト独自の変更を加えて管理するといった用途には向かないように思います。ではどうすればいいだろうか、という試行錯誤の記録です。 git submodule で取り込む 「Aのcloneにおけるsubmoruleへの

PDFからテキストを取り出すのは、意外と大変です。 それにはいくつかの理由があるのですが、もっとも根本的な点で真っ先に解決が必要になるのは、人間が雑に文字としてみなしている絵（「グリフ」）をコンピューターで扱えるような「文字」にする方法です。 これには2つのアプローチが考えられます。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る PDFファイルの中身を解析してテキストを抜き出す このうち2つめの話は明日以降にして、今日は1つめの話をします。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る方法 この方法は、言ってみれば、人間もしくは人間のように振る舞うソフトウェアによりPDFビューワーの表示を「視覚的に読む」ということです。 これはPDFの本来の使い道に即した手法です。 PDFというのは、グリフ（文字の形）をページ上に表示するための汎用の仕組

ある出版社が電子書籍の直販サービスを一方的に打ち切るというニュースが今日あり、自分は前にその出版社で編集者をしていて、打ち切られることになった電子書籍の直販サービスにもわりと近いところにいたし、たぶんぼくが作ったいた本は、その電子書籍の直販サービスでいまだにとてもよく売れているはずで、それなのにどうやら著者や訳者に一切の連絡もなく打ち切られたらしく、まあ、一カ月前にくだんの直販サービスを立ち上げたぼくの先輩であるフルスタック編集者がやめたことを考えると、遅かれ早かれこうなるのは目に見えていたので、このニュース自体にまったく驚きはなかったんだけど、こうやってその日がくると、あのときの編集チームを社内政治にからめてつぶした人たちにはほんとうにあきれるし、当時のポジティブな気持ちとか、誇らしさとか、楽しさとか、そういうのを思い出してしょっと憤慨するし、でも、こうしてぼくは自分で編集チームをまた持