Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ
これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。 とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。 しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。 まず「認識が違う」と思うのは、プレインオールド
技術書の索引にかける3つの覚悟
技術書の索引を作るのは、一筋縄ではいかない仕事です。「IT書籍の索引について考える」（KeN's GNU/Linux Diary） 矢吹さんのtweetから始まって、まとまりはないけど索引について思考実験。オチはないよ。まず索引というのは、そもそも正しいページを参照するものでなければなりません。42ページを見よとなっているのに、そのキーワードも関連する概念の説明も42ページに出現しないのはまずい。また、キーワードAに対して「キーワードBを見よ」などとなっている場合もありますが、これが循環しているのもまずいです。Aの項にもBの項にも具体的なページ番号がないのは論外ですが、「…も見よ」が循環しているのもまずいです。こうした参照先について要求されることがらを「索引の健全性」と呼びます。（いま作った用語。このほか、キーワードが正しく五十音順に並んでいることなんかも健全性に含まれますね。） 一方、索
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
