技術書をクラウドファンディングで出版してみた
あきみちさんから、「IPv6本を出すということで、クラウドファンディングで協賛を呼びかけよう」（原文ママ）というアイデアを聞いたのは、TwitterのDMのやり取りを読み返すと2016年11月23日のことだったらしい。 DMには時刻が表示されないので正確な時間はわからないけど、その後のやり取りがいつの間にか11月24日になっているので、たぶんそういう時間帯だ。 それに対するぼくの最初の返答は、「それは既存の出版社だと面倒そうだ」（原文ママ）だ。 言外に「うち（ラムダノート）ならできるよ」が含意されていることは、起業前からいろいろ相談にのってくれていたあきみちさんには間違いなく伝わる。 とはいえ、そのころはまだ『プロフェッショナルSSL/TLS』も制作中だったし、直販ストアもなかったし、ラムダノートは胸を張って「出版社」と言える状態ではなかった。 そもそも、あきみちさんやぼくは技術自体という
なぜ原稿をテキストで書かなければいけないのか
これは編集とライティングにまつわるアレコレ Advent Calendar 2017の23日めの記事です。 原稿をどういう形式・記法で書くべきなのか、という質問をときどき受けます。 一瞬だけ悩むけど、だいたい答えはこうなります。 「記法はなんでもいいけど、できればテキスト形式で」 今日は、この答えの背景を話します。 まずは「なんでもいい」の部分から。 記法はなんでもいい 出版社や編集者によっては細かく原稿の記法を指定しているようですが、ぼくは特に原稿の記法を決めていません。 これは、そういう記法を決めることができずにここまできた、というのが正直な理由です。 つまり、ぼくの怠慢なんですが、なにも考えずに怠慢であったというよりは、積極的に怠慢になろうと考えた結果なので、そのへんを少し吐露してみます。 原稿の記法を決めるということは、執筆者の脳内にあるものを吐き出してもらうための形を決めるという
英語圏のIT系技術書ブランドについての雑感
この記事はpyspa Advent Calendar 2017の6日めのために書きましたが、アマゾンアソシエイト目的です。 『退屈なことはPythonにやらせよう』が出た 2017年にブレイクしたPythonの本といえば、オライリー・ジャパンから発行された『退屈なことはPythonにやらせよう』ですよね。 実はこの本、そのむかし、自分でも翻訳発行をひそかに検討していたのです。 当時の翻訳者候補の方とのDMをさかのぼってみたら、少なくとも2015年7月以前の話でした。 「非プログラマーでもプログラミングしようぜ」という趣旨で著された本書は、わたし自身の書籍企画の方向性によくマッチしていました。 それで本書に目を付けたのですが、いかんせん分量は多いし、Pythonは日本だと入門者向け言語としていまいち盛り上がらないし（当時の話です）、なにより例題があんまりぐっとこないねという話で、そのときは企
Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ
これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。 とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。 しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。 まず「認識が違う」と思うのは、プレインオールド
職務経歴書
いろいろあって職務経歴書を作成してみることにしました。お便りお待ちしています！ 要約すると 理工系出版社の開発部という部署で約13年間半、主にコンピュータネットワークとプログラミングの本を企画し、制作してきました（「企画制作に携わった主なコンテンツ」および「企画者として公式に社内に名前が出ている、かつ、制作でも中心だった書籍の一覧」を参照）。 特にTCP/IP関連書籍と、翻訳技術書は、たくさんの技術者の方に手に取ってもらえた（願わくば役に立てた）と思います。 読者が読んだことを後悔しない本を作るのは当然として、著者や訳者が出版したことを後悔することがないように、編集制作プロセスの透明化にも努めました。 通常、著者や訳者は、出版物に対する責任があるにもかかわらず、その最終的なデータを手にすることがありません。 著者による校正の終了後に編集者が内容のデグレにつながるような修正を勝手に加えてしま
Re:VIEWで売り物の本を作ってみた（InDesign抜き）
本を作って出版する仕事をしています。 今回、はじめてRe:VIEWを実際の仕事に使ってみたので、忘れないうちに感想とメモを殴り書きしておきます。 ちなみに、作ったのは『エクストリームプログラミング』という本です。 公式サイトのREADMEに「an easy-to-use digital publishing system for books and ebooks」とあるように、 Re:VIEWは日本語の技術書をできるだけ簡単に作るための仕組みです。 テキスト原稿に比較的簡便なマークアップをマニュアルどおりに施し、本全体の構造をYAMLに書けば、それなりに体裁が整った日本語の技術書PDFを編纂してくれます。 同じソースからepubも出せます。InDesignへネイティブに取り込めるような出力もはけるので、テキスト原稿をInDesignに流し込んでバッチ組版とかも可能です。 自分が今回使ったの
TUG 2013で日本語の巻末索引について発表しました
TUG 2013という、世界中からTeX関連の開発者と利用者が日本に集まるイベントで、日本語書籍の索引について発表する機会がありました。「発表してみないか」と実行委員の黒木さんに誘われたときは、仕事でやってることを10分くらいで紹介すればいいのかなと思って軽い気持ちで引き受けたのですが、実は「海外からの参加者向けに用意する日本語チュートリアルの一環なのでよろしく」という話でした。当日は早口でいろいろ詰め込んでしまったせいか、話の筋を見失った方もいると聞いたので（すみません）、いまさらですが発表のストーリーをまとめておきます。（TeX & LaTeX Advent Calendar 2013の2日目の記事です。1日目はzrさん、3日目はdoraTeXさん。） いろいろな言語の本の索引を比べてみると、索引項目（一般には単語）の「自然な」並べ方がある言語とない言語がある アルファベットを使う言語
parsec で極める文章編集
正規表現をまったく使えない編集者はひとにぎりだと思いますが、正規表現だと原稿の半角丸括弧を全角に変換する作業とか頭痛いですよね。わたしもいつも困ってました。 というわけで、いまや編集者必須ツールといってもいい parsec を新人編集者にぜひ使ってもらおうということで、 「Haskell Advent Calendar 2012」18日目という場を借りた素人チュートリアル記事です。 Haskeller が書いてるわけではないので、 「その考え方は違う」とか「もっと効率的な書き方がある」といったコメントがもらえるとうれしいです。 ちなみに、わたしの周りに新人編集者はもう何年もいません。まだ見ぬ新人へ向けて書きます。 parsec で最速テキストフィルター 最初に parsec を使おうと思ったときにぶちあたるのは、プログラマ向けの解説しかないことだと思います。 編集者というものは、 CSV
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
