技術書のレビューの経験則
出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。 専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「制作サイド」の一部とみなしていいだろう。 一方、基本的に無償で、完成した書籍の献本と謝辞への掲載くらいを前提に、あくまでもベストエフォートで発行前の本の内容を見てくださいというお願いを第三者にすることもある。 この場合の第三者というのは、制作中の書籍の想定読者だったり、出版後の書籍を対象読者へ紹介してくれそうな立場の人だったりする。 このようなプロセスを制作に取り入れる習慣は、とくにここ数年のIT系の出版社ではめずらしくなくて、界隈では「レビュー」などと呼ばれている。 というわけで、技術書の制作における「レビュー」につ
なぜ原稿をテキストで書かなければいけないのか
これは編集とライティングにまつわるアレコレ Advent Calendar 2017の23日めの記事です。 原稿をどういう形式・記法で書くべきなのか、という質問をときどき受けます。 一瞬だけ悩むけど、だいたい答えはこうなります。 「記法はなんでもいいけど、できればテキスト形式で」 今日は、この答えの背景を話します。 まずは「なんでもいい」の部分から。 記法はなんでもいい 出版社や編集者によっては細かく原稿の記法を指定しているようですが、ぼくは特に原稿の記法を決めていません。 これは、そういう記法を決めることができずにここまできた、というのが正直な理由です。 つまり、ぼくの怠慢なんですが、なにも考えずに怠慢であったというよりは、積極的に怠慢になろうと考えた結果なので、そのへんを少し吐露してみます。 原稿の記法を決めるということは、執筆者の脳内にあるものを吐き出してもらうための形を決めるという
昔のTeX環境をDockerのコンテナ化する
大きく進化した日本語TeX環境 新しいLinuxマシンで、とりあえず日本語TeXを使えるようにするまでの時間は、ここ数年で信じられないほど短くなりました。それもこれも、TeX Liveが2010で日本語に完全対応してくれたおかげです。 いまのように「TeX Liveをインストールするだけ」となる以前、Linuxで日本語TeX環境を整備するのは、ほとんど腫物に障るようなものでした。 ディストリビューションの各種パッケージから必要なものを適切な順番にインストール、フォントの実体ファイルへのシンボリックリンクをTEXMF以下に作成、mktexlsrを実行、otfパッケージを手動でインストール、mktexlsrを実行、dvipdfmxの設定ファイル群を編集、mktexlsrを実行。 なんとかインストールを終えてplatexを実行し、dvipdfmxにかけると、なぜかPDFのしおりが文字化けしてしま
k16's note
濵津誠 著『ゼロから創る暗号通貨』（2018年10月、PEAKS発行）の編集をお手伝いしました。この本はどんな本かというと…… 土台となるP2Pネットワークから暗号通貨を自前で作ってみることで、ブロックチェーンを応用したまったく新しいサービスと未来を創るところまで意識できる本 著者の濵津さん自身が教師役となり、ブロックチェーンの「うさんくさくない」部分の全体がわかるように、読者をひっぱっていってくれる本 要するに、ブロックチェーンの技術を通して、濵津さんという凄腕技術者が読者のメンターになってくれる本です。これまでクラウドファンディングで出資者しか読めなかったのが、今日から一般にも購入できるようになりました！ 以下は、個人的な回想と、本書でぼくが何をしたかの舞台裏。 暗号通貨についてざっくりと知りたいなと思って、「暗号通貨」で検索してみると、投資して儲けたい人向けの記事と、通貨としての側面
Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ
これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。 とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。 しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。 まず「認識が違う」と思うのは、プレインオールド
執筆・編集のためのGit（GitHub）ワークフローを考えてみた
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
