GitHubで雑誌・書籍を作る
- 3. WEB+DB PRESS • 初公開！ 6月24日発売 • 明日入稿だけどたぶん この表紙で確定 • @naoyaさんのGitHubの記事 もあります
- 4. WEB+DB PRESS plus • 現在40冊 • @hirocasterさんのGitHubの本もあります
- 5. どんな人と 作っているか
- 6. 執筆陣は一流のエンジニア @naoyaさん ：雑誌、書籍（ 3冊！）、ムック @hirocasterさん：雑誌、書籍、ムック @amatsudaさん ：雑誌、ムック @miyagawaさん ：雑誌（ Vol.2から！）、ムック @kenchanさん ：雑誌、ムック @yandodさん ：雑誌、書籍（ 2冊！） ! ※本日の登壇者・運営チームより（登場順。漏れがあったらすみません） ※会場にはもっとたくさん！
- 7. どのように 作っているか
- 8. 使っているツール • GitHubで原稿管理とやりとり • md2inaoで原稿テキストの変換 • Adobe InDesignで紙面レイアウト
- 9. md2inaoとは何か • Markdownで書かれたテキストを、 WEB+DB PRESS/WEB+DB PRESS plus用の InDesignテキストに変換するツール • ソースコードの文字数チェック機能なども備えて いる
- 11. md2inao以前（∼2010年） プログラミング雑誌の原稿中でもぜったいに登場しない 全角を駆使した編集記号での執筆をお願いしていた。 • ■大見出し • ◆b/◆太字◆/b◆ • ◆i/◆イタリック◆/i◆ • ◆ルビ/◆技評◆ぎひょう◆/ルビ◆ この編集記号からInDesignテキストに変換するプログラム を、別途編集部で持っていた。 https://github.com/inao/idtagreplacer
- 14. markdown2inao.plから md2inaoへ（2013年） 昨年春、@naoyaさんが連載スタートを機に GistからGitHubに移行し、名前もmd2inaoにあら ため、マニュアル、テスト、Travis CI、Web版な どもそろえてくださった。 md2inao.plができるまで - Togetterまとめ http://togetter.com/li/465621
- 19. 正確には InDesignタグ付きテキスト • 文字周りのスタイルをひと通り設定できる • 画像周りは取り扱えない • Re:VIEWなどが対応しているInDesignのXML だと、画像なども扱える • ただXML版でも、2段組のWEB+DB PRESS のレイアウトまでを行うのは難しそうとのこと
- 20. md2inaoで変換したこんな感じの テキストをInDesignに取り込むと <ParaStyle:大見出し>GitHub <ParaStyle:本文> GitHubはもはやお馴染みですね。GitHub はGitのリモートリポジトリとして利用できるWebサービスで、 ほかのユーザに向けてソースコードを共有・公開できます。ほ かの開発者とのコミュニケーションにもよく利用されることか ら、「プログラマのためのソーシャルネットワーク」と呼ばれ ることもあります（<CharStyle:太字>図1<CharStyle:>）。 ── 伊藤直也著「Emerging Web Technology研究室」第8回「GitHubを使った Pull Requestベース開発プロセス」『WEB+DB PRESS Vol.81』、技術評論社、 2014年、p.144
- 23. ブランチモデル • 作業者が、WIP（Work In Progress）な Pull Requestを送る • 執筆時は、著者さんがWIP Pull Requestを出す • 編集時は、編集者がWIP Pull Requestを出す • これを繰り返していくことで完成させる • 複数人での執筆、複数章に分かれた執筆、同時進 行の作業などの場合は、Pull Requestからさらな るPull Requestを派生させることもある
- 25. コミット • コミット数は、特集でだいたい500くらい • 基本的な校正時には見出し単位でコミット • <見出し名>を校正した • 意図を伝えたい変更は、ピンポイントでコミット • ○○と重複しているので削除した • 話題が変わったので段落分けを行った • SourceTreeだと、hunkより細かい行単位で選択 したコミットがやりやすい • revertする／される可能性がある変更も、その変更のみ でコミット
- 26. フィードバック方法 • Pull Requestの確認時に気がついたものは、 GitHub上でコメント • テキスト上での校正時に気がついたものは、 テキスト中に直接書き込み • ★○○などの★ライブラリがあります。 • ★なぜ、☓☓なのかがちょっとわかりませんで した★ • これらのコメントは簡易PDFでは赤字になる
- 27. これくらいの活用状況
- 29. GitHubで何が変わったか • 進 状況が見える化された • 従来はアウトライン、草稿、完成原稿の3回くらい • Issue/Pull Requestによりメールを使わなくなった • 特集だと100を超えるメールをやりとりしていた • コミットメッセージで変更意図を伝えやすくなった • メールあるいは原稿テキスト中に書く必要があっ たので、従来は大きなものしか伝えなかった • 思い切った変更の提案が行いやすくなった • Pull Requestの破棄やrevertがあるので
- 31. ごく基本的なことしか できません • そのときどきで、著者さんに教えていただきなが ら習得していっています • 著者さんの寛容さに助けられています • 使い方が適当でも許してくださる • 使い方がわからないときは教えてくださる
- 32. Git/GitHubの習得 • Gitの学習（2009年） • GitメンテナのJunio C Hamanoさんに 「はじめてのGit」を書いていただいて （「開発ツール徹底攻略」にアップデート版を収録） • Gitの実戦投入（2009年） • @tyanoさん、@yoshioriさんの特集原稿で • GitHubの実戦投入（2013年） • @amatsudaさん、@idesakuさんの特集原稿、 @naoyaさんの連載原稿で • Joined on Nov 19, 2008でした
- 37. おんぶにだっこされながらも できるだけ取り入れたい • GitHubによる常時共有、バージョン／課題管理 • Markdownという書き慣れた記法による執筆 • HTMLや簡易PDFの作成による常時結合 • 簡易PDFは常時ではないですけど>< • レビューによるフィードバック
- 39. ご注意事項
- 40. GitHubのプライベートリポジトリ はご用意いただく必要があります • 現時点で当社でご用意できるのは、試験運用中 のGitLabのみ（バックアップなし） • 1媒体1リポジトリとすると、当社全体だと年間 約400のプライベートリポジトリが必要 • 増刷や改定もあるので、1年だけ維持すれば良 いわけではない • 実際には雑誌は1記事1リポジトリほしいので、 僕一人でも年間50リポジトリ程度必要
- 41. ご参考：Vol.81での勢力図
- 42. あくまで私の場合のお話です • 今回の発表内容はあくまで僕の場合のお話です • WEB+DB PRESS編集部の人は だいたい同じようなやり方でいけます
- 43. 最後に
- 46. ご静聴ありがとう ございました