なぜ原稿をテキストで書かなければいけないのか
これは編集とライティングにまつわるアレコレ Advent Calendar 2017の23日めの記事です。 原稿をどういう形式・記法で書くべきなのか、という質問をときどき受けます。 一瞬だけ悩むけど、だいたい答えはこうなります。 「記法はなんでもいいけど、できればテキスト形式で」 今日は、この答えの背景を話します。 まずは「なんでもいい」の部分から。 記法はなんでもいい 出版社や編集者によっては細かく原稿の記法を指定しているようですが、ぼくは特に原稿の記法を決めていません。 これは、そういう記法を決めることができずにここまできた、というのが正直な理由です。 つまり、ぼくの怠慢なんですが、なにも考えずに怠慢であったというよりは、積極的に怠慢になろうと考えた結果なので、そのへんを少し吐露してみます。 原稿の記法を決めるということは、執筆者の脳内にあるものを吐き出してもらうための形を決めるという
Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ
これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。 とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。 しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。 まず「認識が違う」と思うのは、プレインオールド
技術書編集者として「これはやられた！」2015年の本
技術書の年間ランキング的なものについて、編集者たちに「これはやられた！」と思う他社の本を候補として出させたら面白いのでは、という会話を小耳にはさみました。これはまたとないアマゾンアソシエイトの機会！ということで、勝手に自分の候補を上げてみます。 と思ったものの、新刊の技術書をそんなにたくさん読んでいないうえに、去年「これはやられた！」と思った本はいずれも技術書ではなく、どちらかというと数学書っぽい本ばかりでした。それでも、ジュンク堂池袋本店の「新春座談会 このコンピュータ書がすごい！ 2015年版」で取り上げられた本ばかりだし、たぶん技術者が読む（べき）本としても妥当なはずです。 『コンピュータは数学者になれるのか? -数学基礎論から証明とプログラムの理論へ-』 いま自分の本棚を見返したら、この本の隣にたまたま『日本の著作権はなぜこんなに厳しいのか』が並んでいて、一瞬だけ姉妹書に見えました
多値で簡単パーサーコンビネーター（Shibuya.lisp TT#6）
Shibuya.lispのテクニカルトーク#6に参加しました。仕事半分以下、趣味半分以上です。 まず仕事の部分について、直売で書籍を購入いただいた皆さん、本当にありがとうございました。Lispそのものの本よりも『鉄道ダイヤの回復技術』や『日本のコンピュータ史』のような本が想定以上に売れてしまうあたり、さすがShibuya.lispだと思った。 ただ、前回も直販をしたのだけど、そのときの反省として、販売員をやるとどうも外野っぽくなってしまう。自分としては、普段からSchemeを使っているので、いちLispユーザーとしてもShibuya.lispに参加したい。それで今回はLTに応募した。LTのトピックはなんでもよかったのだけど、具体的にコードが見えるもののほうが面白かろうということで、個人プロジェクトの中で利用したアイデアを切り出して、多値を使って自分の目的にあったパーサーコンビネーターを簡単
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
