ごきげんよう、人間関係でボロボロになって療養中のえるきちです。最近はリハビリにとあるJavaScriptのプロダクトを作っております。近いうちにアルファリリースとかできたらいいな。
今年の秋に技術書典3というイベントが開催されます。7/23が申込期限です。みなさん申し込みましょう。本の内容が決まってない？受かってから考えてもいいんですよ！
技術書同人誌を書くといいよの話
皆さんもQiitaに記事を書いたりしてるじゃないですか？それと同じです。アウトプットするために、知識や経験をまとめたり調べたりしてブラッシュアップする過程自体経験としてとても有意義です。ブログ記事よりももっと体系的にまとめるので、得られる経験値はblogの比じゃないです。文章の組み立て方、考え方、技術に対する視点、そういったものにいい影響を与える……かもしれません。
商業誌に記事を書くというのもいい経験だと思いますが、同人誌では好きなものを書けます。自分の中の好きなモノ、欲求、ルサンチマンなんでもいいから本にたたきつけましょう。心の叫ぶままに、欲望の赴くままにキーボードを叩けばいいのです。
技術書典最高
技術書典は、技術書オンリーの同人イベントです。過去に開催された技術書典1や、技術書典2はとてもいいイベントでした。何がいいかというと、技術書を欲しい人しか来ないので、サークル側としてもターゲットを絞りやすいからです。その点、コミケなんかよりもよほどやりやすいイベントです。超技術書典は参加してないのでよく知らないです。
ちなみにうちのサークル、東京ラビットハウスはModern JavaScriptという本を技術書典2で出したところありがたいことに200部完売いたしました。まぁサークル配置場所が神がかっていたというのはあるとは思います（なにせ入り口真っ正面）。加筆修正したものが、最新JavaScript開発~ES2017対応モダンプログラミング (技術書典シリーズ(NextPublishing))という本として8/11に発売になります。
もちろん参加者としても、秋葉原というとてもアクセスしやすい場所で、ニッチなものからメジャーなものまで、様々なマニアックな技術書を入手できるというとても良いイベントです。技術書典2は雨天にも関わらず3000人以上来場してたとか。
まずは一通り体験してみましょう
技術書を出す時、僕が一番言っておきたいのは「まずはフローを全部体験してみましょう」です。リポジトリのセットアップから印刷までです。ベストは16ページ位の薄い本を印刷所で印刷してもらうことです。なぜかというと、出版や印刷の経験が無い人が同人誌を出そうとすると、「これでもか！」というくらいにトラブルに見舞われるからです。「Re:Viewでカスタマイズした奥付どうやって出すの！？」「なんかTeXでエラー出まくるんですけど！」「印刷所に送るPDFってフォント埋め込み必須なの」「4の倍数ページ」「表紙・裏表紙はわかるけど背表紙って何よ！しかも紙の厚さとページ数からmm単位で考えてピクセル数を指定しないといかんの！？」とか。
なので、適当なヤツを作ってめっちゃ余裕あるスケジュールでささっと作って印刷まですべきです。まぁ印刷所の人は親切っぽいので、分からないことがあったら都度聞けばいいだけっぽいですけどね。
あ、表紙絵とか誰かに発注するなら、思いっきり早め(今のうち)にお願いをしておきましょう。僕が教えてもらった手としてはCrowdWorksで発注です。
技術書を書くために必要な技術
githubにリポジトリ作って、(書籍向けの)処理系を準備して、CI回すという、いつもの流れですよ！
エンジニアの皆さん、技術系同人誌を描きませんか - takanakahiko’s blogという記事では、HTML+CSSでPDFを生成するVivliostyleが使われた話が書いてありました。こういうのも手かなーと思います。
というのも、以下に書くRe:Viewは、同人及び出版、そしてTeX未経験の僕にはハードルが高かったです。クォリティとか色々得るものは多いので時間的余裕があるならチャレンジしてみるといいです。
Re:View
僕が前回Modern JavaScriptで使ったのは、Re:VIEWです。出版社関係に強いやつみたいです。少し特殊なマークアップ記法で記事を書けば、PDFやEPUBが作成できるやつです。
= はじめに
皆さんは「モナドって何？」って思ったことはありませんか？少し怖い人に聞いてみるときっと真顔で「モナドは単なる自己関手の圏におけるモノイド対象だよ。何か問題でも？」とでも言ってくるでしょう。まぁ、この説明で分かった人ならば、きっとこの本を読む必要はありません。
他にもScalaやHaskellの世界には怖い人がいっぱいいて「それ単なる○○だよ？論文読んだ？」とかカジュアルに言ってくる人がいるイメージです。（もしかしたら僕の偏見かもしれません）
本書はその手の怖い説明を抜きにして、でもちゃんと関数型言語やモナドというものがどういうものなのか、そもそも何がうれしいものなのか、そのモチベーションはどこにあるのかというのをフレンズたちと一緒に学んでいくための本です。
関数型言語には利点がいっぱいあります。難しさを取っ払えば他の言語のプログラマとしても大きな糧になると思います。
次の本の序章こんな感じにしようかなというヤツのサンプルです。
まずここらへんを読むと良いです。
個人的な感想としてはRe:View記法、マークアップがめんどいので、次の同人誌はMarkdownで書いてから変換しようと思っています。あと割と変なクセがあるので、ちゃんとコンパイルして都度、動作確認してクセをつかんだ方がいいです。
Re:View -> PDF = TeX
Re:ViewでPDFを出力する場合、TeXが必須です。印刷所にPDFを提出するためには
- サイズを指定する (B5とか)
- フォントを埋め込む
- トンボが必要なトンボを出力する (やったことないからわからない)
などなど格闘する内容はいっぱいあります。TeX避けて通れないので、TeXとちゃんと格闘してください。
Markdown -> Re:View
md2reviewというツールを使えば、MarkdownからRe:Viewに変換が可能です。
リポジトリ作ってみよう
$ review-init <名前>
でさっくり作業ディレクトリを作ってしまいましょう。あとはgithubでプライベートリポジトリでも作ってpushしましょう。
CI
今時はCIぶん回すのが当たり前です。
box: vvakame/review
build:
steps:
- script:
name: apt install
code: apt-get -y install build-essential ruby-dev
- bundle-install
- script:
name: build PDF
code: review pdfmaker config.yml
- script:
name: build EPUB
code: review epubmaker config.yml
- script:
name: artifacts
code: cp *.pdf *.epub $WERCKER_REPORT_ARTIFACTS_DIR/
これはwercker.ymlです。werckerはOracleが買収しちゃったんで心配ですけど、後発でDockerベースのモダンな素直なCIなので割と好みです。github.comのプライベートリポジトリも無料でCIやってくれます。
複数人で原稿を書いたり、校正者が付く場合githubやCIは超絶便利です。めちゃめちゃ捗ります。あとはSlackとか建ててもいいかもしれません。
textlintとかprhとか
textlintとかprh使いましょう。機械でもできる校正は機械にやらせてしまいましょう。(もちろん機械ではまだできない部分もありますが、それはそれ)
個人的にはtextlintよりはprhの方が技術書の執筆では有益というか楽でした。今後はもうちょっとtextlint周りも調べてみたいところではありますが。
さて、校正はCIに仕込んでもいいですが僕はAtomのプラグインでlanguage-reviewというのを使ってました。これだとエディタ上で校正が可能です。
本を書く
もくもく執筆会で東京及び横浜で定期的に執筆のもくもく会が開催されているので是非とも参加してみましょう。技術者、ライター、編集者など色々な方がいらっしゃいます。技術書典の開催するイベントももちろんお勧めです。
締め切り駆動開発
締め切りが無いと馬力がでない人は頑張ってラスト二週間くらいで80P書いちゃいましょう。書けます書けます。
ただその場合は「安くなる締め切り」と「一応安くなる締め切り」と「安くならない締め切り」の三段階くらいで予防線を貼っておきましょう。原稿は落としてはいけません。締め切りは破るものです。締め切りを破っても最終的に落とさない、そういう予防線は必須です！
アウトライン駆動執筆
僕は部分的にしか採用してないですが、目次から書き始める人多いと聞きます。アウトラインを決めてから詳細を作っていくやり方ですね。
これ説明したっけ？
僕が本を書く上で、意識していたのはこれですね。初出の概念を唐突に出すと読み手が混乱するかもしれません。何らかの形で初出のモノには簡単でもいいから説明を付けるようには考えていました。コラムであったり脚注だったり、何かしら説明の順番は考えるべきです。
ちなみにこのやり方に慣れてる人なら、Qiitaの記事とかでもそうですけど、途中や断片から雑に記事を書き始めることができます。アウトライン駆動執筆とは逆ですかね。
準備
- テーブルに引く布
- ポスタースタンド (たとえばこれ)
- ブックスタンド (たとえばこれ)
- 付箋、ボールペン、マーカー、はさみ、カッター、ガムテープ、マスキングテープ
- クリアファイルいくつか
- メッシュケース (たとえばこれ)
- 100均でOK。お金入れたり色々使い勝手がある。
- 小銭のやりとりが発生するなら、コインケース、事前にコインの用意
- お金受け渡しの皿
- ポップ・ポスター
- キャッチコピー考える
- 本を書いてる時のエピソードや、本を読んでくれる人の心に響く何か。フック
Keynote最強 (パワポやExcelでもいいけど)
エンジニアの皆さんならmacOSを使ってると思うのでKeynoteがインストールされてるはずですが、図や表紙をでっち上げるのに最高に便利です。Windowsな人ならExcelやパワポでも同様の事はできるはずです。これも、早めに練習しておかないとギリギリで焦るかもしれないのでご注意を。
まぁ最近だとタブレットとかの方がいいアプリが色々そろってそうな気はします…。
まとめ
- 本を印刷するところまで一度やってみましょう
- Re:ViewでもMarkdownでもTeXでもHTML/CSSでも、どれでもいいけど一通り罠はあらかじめ踏み抜いておきましょう
- Macならヒラギノフォントが楽 (同人誌の印刷に利用可能！)
一通り罠踏み抜いてるので、質問でもなんでもお気軽にお声掛けてください。あともくもく執筆会で僕と握手！
予告
技術書典3では当選するかはわかりませんが「フレンズと学ぶ怖くない関数型言語・モナドの本(仮称)」と「ECMAScript AST本」の予定です。誰か表紙絵とか描いていただけませんか！？前者はけものフレンズで、後者は… 何モチーフがいいかしら。
最新JavaScript開発~ES2017対応モダンプログラミング (技術書典シリーズ(NextPublishing))という本が出ます！モダンなJavaScriptプログラミングは楽しいです！
VALUはじめてみました。