Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
GitHubで

雑誌・書籍を作る
稲尾尚徳
WEB+DB PRESS編集部(技術評論社)
2014/06/01 GitHub Kaigi
どんな雑誌・書籍を
作っているか
WEB+DB PRESS
• 初公開! 6月24日発売
• 明日入稿だけどたぶん

この表紙で確定
• @naoyaさんのGitHubの記事
もあります
WEB+DB PRESS plus
• 現在40冊
• @hirocasterさんのGitHubの本もあります
どんな人と

作っているか
執筆陣は一流のエンジニア
@naoyaさん :雑誌、書籍( 3冊!)、ムック
@hirocasterさん:雑誌、書籍、ムック
@amatsudaさん :雑誌、ムック
@miyagawaさん :雑誌( Vol.2から!)、ムック
@kenchan...
どのように
作っているか
使っているツール
• GitHubで原稿管理とやりとり
• md2inaoで原稿テキストの変換
• Adobe InDesignで紙面レイアウト
md2inaoとは何か
• Markdownで書かれたテキストを、

WEB+DB PRESS/WEB+DB PRESS plus用の
InDesignテキストに変換するツール
• ソースコードの文字数チェック機能なども備えて
いる
md2inaoの

簡単な歴史
詳細はこちら
https://gist.github.com/inao/baea09bc6fc53551886b
md2inao以前(∼2010年)
プログラミング雑誌の原稿中でもぜったいに登場しない

全角を駆使した編集記号での執筆をお願いしていた。
• ■大見出し
• ◆b/◆太字◆/b◆
• ◆i/◆イタリック◆/i◆
• ◆ルビ/◆技評◆ぎひょう◆...
markdown2inao.plの誕生
(2010年)
「そんなわけのわからない記法で書けるか!」

ってことで、@typesterさんが自身の執筆用に
Markdownから編集記号に変換するスクリプトを
作り、Gistでも公開してくださった。
markdown2inao.plの成長
(2010∼2012年)
その後、@hsbtさん、@hokacchaさん、

@suzukiさん、@syohexさんといった方が、

Gist上で少しずつ、そして時には大きく改善してく
ださった。
markdown2inao.plから
md2inaoへ(2013年)
昨年春、@naoyaさんが連載スタートを機に

GistからGitHubに移行し、名前もmd2inaoにあら
ため、マニュアル、テスト、Travis CI、Web版な
どもそ...
もはやinaoではない
現在のmd2inaoは、InDesignテキストに変換する
機能も備えたため、編集もMarkdownで行い、
MarkdownからInDesignテキストに直接変換して
います。
ですので実態としては、もはやmd2ina...
md2inaoの近況
2013年春の@naoyaさんの怒涛の更新ラッシュが
去ったあと、しばらく沈黙が続いていましたが、
ここ最近、@gfxさんの特集の執筆を機に、@gfx
さんによるCPAN化、@naoyaさんによるHeroku
への自動デプ...
md2inaoの今後、あるいは

おんぶにだっこな開発の未来
@gfxさんの記事も明日印刷所に入稿しちゃうの
で、再びの沈黙も予想されています。
なお、現在Issueは14個ほど挙がっています。
https://github.com/naoya...
InDesignテキストとは
何か
正確には

InDesignタグ付きテキスト
• 文字周りのスタイルをひと通り設定できる
• 画像周りは取り扱えない
• Re:VIEWなどが対応しているInDesignのXML
だと、画像なども扱える
• ただXML版でも、2段組のWEB+D...
md2inaoで変換したこんな感じの
テキストをInDesignに取り込むと
<ParaStyle:大見出し>GitHub
<ParaStyle:本文> GitHubはもはやお馴染みですね。GitHub
はGitのリモートリポジトリとして利用で...
こんな簡易PDFができます
※前述した@naoyaさんの
原稿をサンプル用に切り
貼りしたため、文章はつ
ながっていません
GitHubをどのように
使っているのか
詳細はこちら
http://d.hatena.ne.jp/naoya/20140127/1390815492
ブランチモデル
• 作業者が、WIP(Work In Progress)な

Pull Requestを送る
• 執筆時は、著者さんがWIP Pull Requestを出す
• 編集時は、編集者がWIP Pull Requestを出す
• これ...
たとえばこんなPull Request
コミット
• コミット数は、特集でだいたい500くらい
• 基本的な校正時には見出し単位でコミット
• <見出し名>を校正した
• 意図を伝えたい変更は、ピンポイントでコミット
• ○○と重複しているので削除した
• 話題が変わったので段落分け...
フィードバック方法
• Pull Requestの確認時に気がついたものは、
GitHub上でコメント
• テキスト上での校正時に気がついたものは、

テキスト中に直接書き込み
• ★○○などの★ライブラリがあります。
• ★なぜ、☓☓なのかが...
これくらいの活用状況
プライベートリポジトリなので
みなさんから見るとこんな感じ
GitHubで何が変わったか
• 進 状況が見える化された
• 従来はアウトライン、草稿、完成原稿の3回くらい
• Issue/Pull Requestによりメールを使わなくなった
• 特集だと100を超えるメールをやりとりしていた
• コミッ...
どれくらいGit/GitHub
を使いこなしているか
ごく基本的なことしか

できません
• そのときどきで、著者さんに教えていただきなが
ら習得していっています
• 著者さんの寛容さに助けられています
• 使い方が適当でも許してくださる
• 使い方がわからないときは教えてくださる
Git/GitHubの習得
• Gitの学習(2009年)
• GitメンテナのJunio C Hamanoさんに

「はじめてのGit」を書いていただいて
(「開発ツール徹底攻略」にアップデート版を収録)
• Gitの実戦投入(2009年)
...
プライベートリポジトリをforkしてPull Request
がきたけど、fork先のプライベートリポジトリ
にはアクセス権がないのでcheckoutできない
急にmasterが
pullできなくなった
まとめとして

背景にある経験・考え
雑誌・書籍作りは、ソフトウェア
開発に近づけたほうがうまくいく
• 著者さんの普段のワークフローに近いから?
• 雑誌や書籍もソフトウェアだから?
おんぶにだっこされながらも
できるだけ取り入れたい
• GitHubによる常時共有、バージョン/課題管理
• Markdownという書き慣れた記法による執筆
• HTMLや簡易PDFの作成による常時結合
• 簡易PDFは常時ではないですけど><...
編集者はゼロを1にはできないけど、1を2にする
お手伝いはできるかもなので(とゆうかそれがお
仕事なので)、著者さんが一人で苦闘しないよう、
こまめな成果物やフィードバックを。
ご注意事項
GitHubのプライベートリポジトリ
はご用意いただく必要があります
• 現時点で当社でご用意できるのは、試験運用中
のGitLabのみ(バックアップなし)
• 1媒体1リポジトリとすると、当社全体だと年間
約400のプライベートリポジトリが必...
ご参考:Vol.81での勢力図
あくまで私の場合のお話です
• 今回の発表内容はあくまで僕の場合のお話です
• WEB+DB PRESS編集部の人は

だいたい同じようなやり方でいけます
最後に
ハブでありたい
GitHubさんにはとうてい及びませんが、

WEB+DB PRESSはエンジニアの方々の

ハブの一つでありたいと願っています。
読者の方同士、著者さん同士、読者の方と著者さん、
さまざまなプログラミング言語や技術、

誌面を...
書いてください
or
読んでください
ご静聴ありがとう

ございました
Upcoming SlideShare
Loading in …5
×

GitHubで雑誌・書籍を作る

74,966 views

Published on

GitHubで雑誌・書籍を作る

  1. 1. GitHubで
 雑誌・書籍を作る 稲尾尚徳 WEB+DB PRESS編集部(技術評論社) 2014/06/01 GitHub Kaigi
  2. 2. どんな雑誌・書籍を 作っているか
  3. 3. WEB+DB PRESS • 初公開! 6月24日発売 • 明日入稿だけどたぶん
 この表紙で確定 • @naoyaさんのGitHubの記事 もあります
  4. 4. WEB+DB PRESS plus • 現在40冊 • @hirocasterさんのGitHubの本もあります
  5. 5. どんな人と
 作っているか
  6. 6. 執筆陣は一流のエンジニア @naoyaさん :雑誌、書籍( 3冊!)、ムック @hirocasterさん:雑誌、書籍、ムック @amatsudaさん :雑誌、ムック @miyagawaさん :雑誌( Vol.2から!)、ムック @kenchanさん :雑誌、ムック @yandodさん :雑誌、書籍( 2冊!) ! ※本日の登壇者・運営チームより(登場順。漏れがあったらすみません) ※会場にはもっとたくさん!
  7. 7. どのように 作っているか
  8. 8. 使っているツール • GitHubで原稿管理とやりとり • md2inaoで原稿テキストの変換 • Adobe InDesignで紙面レイアウト
  9. 9. md2inaoとは何か • Markdownで書かれたテキストを、
 WEB+DB PRESS/WEB+DB PRESS plus用の InDesignテキストに変換するツール • ソースコードの文字数チェック機能なども備えて いる
  10. 10. md2inaoの
 簡単な歴史 詳細はこちら https://gist.github.com/inao/baea09bc6fc53551886b
  11. 11. md2inao以前(∼2010年) プログラミング雑誌の原稿中でもぜったいに登場しない
 全角を駆使した編集記号での執筆をお願いしていた。 • ■大見出し • ◆b/◆太字◆/b◆ • ◆i/◆イタリック◆/i◆ • ◆ルビ/◆技評◆ぎひょう◆/ルビ◆ この編集記号からInDesignテキストに変換するプログラム を、別途編集部で持っていた。
 https://github.com/inao/idtagreplacer
  12. 12. markdown2inao.plの誕生 (2010年) 「そんなわけのわからない記法で書けるか!」
 ってことで、@typesterさんが自身の執筆用に Markdownから編集記号に変換するスクリプトを 作り、Gistでも公開してくださった。
  13. 13. markdown2inao.plの成長 (2010∼2012年) その後、@hsbtさん、@hokacchaさん、
 @suzukiさん、@syohexさんといった方が、
 Gist上で少しずつ、そして時には大きく改善してく ださった。
  14. 14. markdown2inao.plから md2inaoへ(2013年) 昨年春、@naoyaさんが連載スタートを機に
 GistからGitHubに移行し、名前もmd2inaoにあら ため、マニュアル、テスト、Travis CI、Web版な どもそろえてくださった。 md2inao.plができるまで - Togetterまとめ http://togetter.com/li/465621
  15. 15. もはやinaoではない 現在のmd2inaoは、InDesignテキストに変換する 機能も備えたため、編集もMarkdownで行い、 MarkdownからInDesignテキストに直接変換して います。 ですので実態としては、もはやmd2inaoではなく md2indesignです。
  16. 16. md2inaoの近況 2013年春の@naoyaさんの怒涛の更新ラッシュが 去ったあと、しばらく沈黙が続いていましたが、 ここ最近、@gfxさんの特集の執筆を機に、@gfx さんによるCPAN化、@naoyaさんによるHeroku への自動デプロイ機能など、再び進化しました。
  17. 17. md2inaoの今後、あるいは
 おんぶにだっこな開発の未来 @gfxさんの記事も明日印刷所に入稿しちゃうの で、再びの沈黙も予想されています。 なお、現在Issueは14個ほど挙がっています。 https://github.com/naoya/md2inao/issues?state=open
  18. 18. InDesignテキストとは 何か
  19. 19. 正確には
 InDesignタグ付きテキスト • 文字周りのスタイルをひと通り設定できる • 画像周りは取り扱えない • Re:VIEWなどが対応しているInDesignのXML だと、画像なども扱える • ただXML版でも、2段組のWEB+DB PRESS のレイアウトまでを行うのは難しそうとのこと
  20. 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
  21. 21. こんな簡易PDFができます ※前述した@naoyaさんの 原稿をサンプル用に切り 貼りしたため、文章はつ ながっていません
  22. 22. GitHubをどのように 使っているのか 詳細はこちら http://d.hatena.ne.jp/naoya/20140127/1390815492
  23. 23. ブランチモデル • 作業者が、WIP(Work In Progress)な
 Pull Requestを送る • 執筆時は、著者さんがWIP Pull Requestを出す • 編集時は、編集者がWIP Pull Requestを出す • これを繰り返していくことで完成させる • 複数人での執筆、複数章に分かれた執筆、同時進 行の作業などの場合は、Pull Requestからさらな るPull Requestを派生させることもある
  24. 24. たとえばこんなPull Request
  25. 25. コミット • コミット数は、特集でだいたい500くらい • 基本的な校正時には見出し単位でコミット • <見出し名>を校正した • 意図を伝えたい変更は、ピンポイントでコミット • ○○と重複しているので削除した • 話題が変わったので段落分けを行った • SourceTreeだと、hunkより細かい行単位で選択 したコミットがやりやすい • revertする/される可能性がある変更も、その変更のみ でコミット
  26. 26. フィードバック方法 • Pull Requestの確認時に気がついたものは、 GitHub上でコメント • テキスト上での校正時に気がついたものは、
 テキスト中に直接書き込み • ★○○などの★ライブラリがあります。 • ★なぜ、☓☓なのかがちょっとわかりませんで した★ • これらのコメントは簡易PDFでは赤字になる
  27. 27. これくらいの活用状況
  28. 28. プライベートリポジトリなので みなさんから見るとこんな感じ
  29. 29. GitHubで何が変わったか • 進 状況が見える化された • 従来はアウトライン、草稿、完成原稿の3回くらい • Issue/Pull Requestによりメールを使わなくなった • 特集だと100を超えるメールをやりとりしていた • コミットメッセージで変更意図を伝えやすくなった • メールあるいは原稿テキスト中に書く必要があっ たので、従来は大きなものしか伝えなかった • 思い切った変更の提案が行いやすくなった • Pull Requestの破棄やrevertがあるので
  30. 30. どれくらいGit/GitHub を使いこなしているか
  31. 31. ごく基本的なことしか
 できません • そのときどきで、著者さんに教えていただきなが ら習得していっています • 著者さんの寛容さに助けられています • 使い方が適当でも許してくださる • 使い方がわからないときは教えてくださる
  32. 32. Git/GitHubの習得 • Gitの学習(2009年) • GitメンテナのJunio C Hamanoさんに
 「はじめてのGit」を書いていただいて (「開発ツール徹底攻略」にアップデート版を収録) • Gitの実戦投入(2009年) • @tyanoさん、@yoshioriさんの特集原稿で • GitHubの実戦投入(2013年) • @amatsudaさん、@idesakuさんの特集原稿、
 @naoyaさんの連載原稿で • Joined on Nov 19, 2008でした
  33. 33. プライベートリポジトリをforkしてPull Request がきたけど、fork先のプライベートリポジトリ にはアクセス権がないのでcheckoutできない
  34. 34. 急にmasterが pullできなくなった
  35. 35. まとめとして
 背景にある経験・考え
  36. 36. 雑誌・書籍作りは、ソフトウェア 開発に近づけたほうがうまくいく • 著者さんの普段のワークフローに近いから? • 雑誌や書籍もソフトウェアだから?
  37. 37. おんぶにだっこされながらも できるだけ取り入れたい • GitHubによる常時共有、バージョン/課題管理 • Markdownという書き慣れた記法による執筆 • HTMLや簡易PDFの作成による常時結合 • 簡易PDFは常時ではないですけど>< • レビューによるフィードバック
  38. 38. 編集者はゼロを1にはできないけど、1を2にする お手伝いはできるかもなので(とゆうかそれがお 仕事なので)、著者さんが一人で苦闘しないよう、 こまめな成果物やフィードバックを。
  39. 39. ご注意事項
  40. 40. GitHubのプライベートリポジトリ はご用意いただく必要があります • 現時点で当社でご用意できるのは、試験運用中 のGitLabのみ(バックアップなし) • 1媒体1リポジトリとすると、当社全体だと年間 約400のプライベートリポジトリが必要 • 増刷や改定もあるので、1年だけ維持すれば良 いわけではない • 実際には雑誌は1記事1リポジトリほしいので、 僕一人でも年間50リポジトリ程度必要
  41. 41. ご参考:Vol.81での勢力図
  42. 42. あくまで私の場合のお話です • 今回の発表内容はあくまで僕の場合のお話です • WEB+DB PRESS編集部の人は
 だいたい同じようなやり方でいけます
  43. 43. 最後に
  44. 44. ハブでありたい GitHubさんにはとうてい及びませんが、
 WEB+DB PRESSはエンジニアの方々の
 ハブの一つでありたいと願っています。 読者の方同士、著者さん同士、読者の方と著者さん、 さまざまなプログラミング言語や技術、
 誌面を通して、これらをつなぐハブになりたいです。 そのためには、、、
  45. 45. 書いてください or 読んでください
  46. 46. ご静聴ありがとう
 ございました

×