技術書のレビューの経験則
出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。 専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「制作サイド」の一部とみなしていいだろう。 一方、基本的に無償で、完成した書籍の献本と謝辞への掲載くらいを前提に、あくまでもベストエフォートで発行前の本の内容を見てくださいというお願いを第三者にすることもある。 この場合の第三者というのは、制作中の書籍の想定読者だったり、出版後の書籍を対象読者へ紹介してくれそうな立場の人だったりする。 このようなプロセスを制作に取り入れる習慣は、とくにここ数年のIT系の出版社ではめずらしくなくて、界隈では「レビュー」などと呼ばれている。 というわけで、技術書の制作における「レビュー」につ
なぜ原稿をテキストで書かなければいけないのか
これは編集とライティングにまつわるアレコレ Advent Calendar 2017の23日めの記事です。 原稿をどういう形式・記法で書くべきなのか、という質問をときどき受けます。 一瞬だけ悩むけど、だいたい答えはこうなります。 「記法はなんでもいいけど、できればテキスト形式で」 今日は、この答えの背景を話します。 まずは「なんでもいい」の部分から。 記法はなんでもいい 出版社や編集者によっては細かく原稿の記法を指定しているようですが、ぼくは特に原稿の記法を決めていません。 これは、そういう記法を決めることができずにここまできた、というのが正直な理由です。 つまり、ぼくの怠慢なんですが、なにも考えずに怠慢であったというよりは、積極的に怠慢になろうと考えた結果なので、そのへんを少し吐露してみます。 原稿の記法を決めるということは、執筆者の脳内にあるものを吐き出してもらうための形を決めるという
編集というサービスの内容（技術書編）
技術書の編集者が原稿に対して何を提供するものなのか、整理してみた。順番には意味があります。 原稿をDTP担当者が作業できるデータにする 誤字脱字、非標準的な表記を直す 表記を統一する 文法の間違い、不適切な言い回しを直す 構成の不備、内容の間違いを指摘する 構成の不備、内容の間違いを直す 冗長な内容、文脈から外れる記述を欄外に追い出したり、段落構成を手直ししたりする 段落や文を、文脈に合わせた相に書き直す 行間をうめる 解説画像やイラスト、索引などのメタ情報を作る 原稿を書く 【番外】企画する どこまでやってほしいか、できるか、追加料金がいくら必要なのかというのを、著者・版元編集者・下請け編集者の間ではっきりさせると、みんなが幸せになる気がする。（だいたい編集外注するときって「編集作業一式」の「ページあたりの単価」になりがちで、しかしその「一式」には上記のような幅があるわけだから、人によっ
主観でプログラミング言語5種類をあっさり解説
現在プログラミング言語は200種類存在していると言われてるようですが、これはたぶんLisp族の言語だけを数えた値です。 あるプログラミング言語（汎用のもの）がどんな用途に適しているかは、人によって大きく意見が分かれるので、用途を絞ったからといって適したプログラミング言語が決められるわけではありません。そもそも今日の世界における用途が明日の世界にも存在するとは限らないし。 この記事では、ぼくがHello Worldくらいは書いたことがある言語5種類をあっさりと解説しようと思ったけど、そんな知識もないので、「プログラミングしてみたい人向け、言語に関する5つのアドバイス」です。学習しない言語の選択に役立ててください。 Go それなりに具体的で明確な「Cを使う」理由があるのでない限り、Cで学べるようなプログラミングはGoで学んだほうがいいと思います。 HaskellかOCaml これといった目的も
Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ
これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。 とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。 しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。 まず「認識が違う」と思うのは、プレインオールド
執筆・編集のためのGit（GitHub）ワークフローを考えてみた
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
職務経歴書
いろいろあって職務経歴書を作成してみることにしました。お便りお待ちしています！ 要約すると 理工系出版社の開発部という部署で約13年間半、主にコンピュータネットワークとプログラミングの本を企画し、制作してきました（「企画制作に携わった主なコンテンツ」および「企画者として公式に社内に名前が出ている、かつ、制作でも中心だった書籍の一覧」を参照）。 特にTCP/IP関連書籍と、翻訳技術書は、たくさんの技術者の方に手に取ってもらえた（願わくば役に立てた）と思います。 読者が読んだことを後悔しない本を作るのは当然として、著者や訳者が出版したことを後悔することがないように、編集制作プロセスの透明化にも努めました。 通常、著者や訳者は、出版物に対する責任があるにもかかわらず、その最終的なデータを手にすることがありません。 著者による校正の終了後に編集者が内容のデグレにつながるような修正を勝手に加えてしま
「版管理＋自動組版」イベントの雑感
2014年12月6日、「版管理＋自動組版」と題した勉強会というかイベントいうか集まりを開きました。 「同じようなことをバラバラにやってる人たちの横のつながりのきっかけが欲しいな」という程度の軽い気持ちで声を上げてみたら、予想以上に興味を持ってくれる人が膨らんで、様々な背景の方から発表に手を上げていただき、当日も会場から次々と質問が飛び交うという、実に活発で刺激的ですごく楽しい集まりになりました。ありがとうございました！ 発表内容や概要は、公開されている各スライドや、武藤さんによる素晴らしいまとめを見ていただくとして、ここには個人的な感想文を晒しておこうと思います。参加してないと文脈が分かりづらい内容なのはご了承ください。 発表では、自分のゆるい話のあと、 @amedama こと宮川さんに Grifletという書籍のビルドシステムを紹介していただきました。 出版に継続的インテグレーションを適
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
