継続的執筆。GitHub + Re:VIEW + Jenkinsを使った同人誌執筆システムのご紹介。

2015年8月28日に行われた第4回インフィニットループ公開勉強会「OpenIL vol.4」で水野はじめさんが発表したセッション『継続的執筆。GitHub + Re:VIEW + Jenkinsを使った同人誌執筆システムのご紹介。』で使用されたスライド資料です。

Transcript

1. 継続的執筆 Continuous Writing GitHub + Re:VIEW + Jenkinsによる 同人誌執筆システムのご紹介 2015/08/29 第4回OpenIL 株式会社インフィニットループ 水野 源 h-mizuno@infiniteloop.co.jp
2. A long time ago in a Japan far, far away... —遠い昔、日本の片隅で
3. Ubuntu Magazine Japan という雑誌があったのよ……
4. • 日本で唯一のUbuntu専門誌 • 編集長がガチUbuntuユーザー • Ubuntuの中の人が完全監修 • 発行印税の1%をUbuntuコミュニティに寄付 • バックナンバーはCCライセンスで無料公開 と、割と（出版業界的に）すごい雑誌でした
5. ところが色々あり、この号を最後に休刊
6. 商業誌が出ないなら 同人誌を作ればいいじゃない
7. できました
8. そんな同人誌もこの夏で3冊目 今回から執筆が大幅にシステム化されました
9. そもそも何が必要か？ • 本を作るには – 原稿フォーマット – PDFとePUBを生成できる仕組み →Re:VIEW
10. そもそも何が必要か？ • 執筆は複数人で – 原稿を取り纏めるためのコラボレーションシステム – 差分管理 – 手マージはもうしたくない →GitHub
11. Re:VIEWってなに？ • テキストマークアップ原稿フォーマット • WikiやRDのような簡易マークアップ言語 • LaTeX→PDFやePUBでの出力が可能 • Ruby製 • 青木峰郎さんが開発、武藤健司さんがメンテ
12. 例 Re:VIEW原稿
13. = OpenNebulaでPCI passthrough //flushright{ おおたあきひこ //} //lead{ 青羽家はOpenNebulaで家庭内クラウドを構築し、ここなちゃんとママの二人で計算機リソースをやりくりしています。 ここなちゃんは14歳の誕生日に以前から欲しかったMellanoxのConnectX-3 InfiniBand HCAを買ってもらいました。でも彼 女の仮想マシンはホストしている物理マシンから論理的に分離されているため、InfiniBand HCAを物理マシンに挿しても仮 想マシンからはアクセスできません。 ママもせっかくのプレゼントが台無しで大弱りです。 //} == OpenNebulaノススメ OpenNebulaはシンプルで安定したクラウド管理ツールです。簡単な説明やUbuntuでのインストール方法、セットアップ方法 については、gihyo.jpのUbuntu Weekly Recipe 第345回と346回に書かせていただいたので、そちらをご参照ください。 * @<href>{http://gihyo.jp/admin/serial/01/ubuntu-recipe/0345} * @<href>{http://gihyo.jp/admin/serial/01/ubuntu-recipe/0346} OpenNebulaの特徴の一つにカスタマイズの容易さがあります。公式には提供されていない機能でも、なんとなく実装できた りできなかったりします。 今回のざっぱ〜んはハードウェアがテーマということなので、Ubuntu & OpenNebula環境で物理マシン上のハードウェアデ バイスを仮想マシンに提供する方法に取り組んでみたいと思います。 == 前置き
14. これをコンパイルすると
15. こうなる
16. Re:VIEW ファイル Re:VIEW コンパイラ LaTeX dvipdfmx review-epubmaker ePUBおよびPDFの生成
17. 印刷に耐えうる品質 まあ裏はLaTeXだしね……
18. コラボレーションツール • 執筆は複数人で同時に進行する • 追記、修正、ロールバックなどは随時発生 • 編集長はマージ、差し戻しを判断、実行 • Re:VIEWのコンパイルエラーを起こしてはいけない 要求されることはプログラミングと同じ！ → GitHubが超有効 ただしGitHubを使うのは今回が最初で最後
19. GitHub プライベートリポジトリ
20. GitHub Flowベースの作業 • masterブランチの編集、pushは避ける • 編集する時は必ずトピックブランチを作る • masterブランチへの反映Pull Request経由で • Pull Reqのテストが通った時のみマージを行う • masterへのマージはGitHub API経由で
21. masterブランチは神聖である • masterは常にデプロイ可能でなければいけない • テストをパスしてないものはマージしない – 言い換えると…… – マージ前にはブランチのテストが必須 – マージ後もリグレッションテストが必須 → やっぱりプログラミングと同じ！ CI(Continuous Integration)が必要
22. そこで執事 Jenkins
23. Juju + LCX + Jenkins • Amazon EC2上にJujuを用いて構築 – Ubuntu 14.04 LTS 64bit – Ruby 1.9.1（公式リポジトリのパッケージ） – TeX Live 2013（公式リポジトリのパッケージ） – GemでインストールしたRe:VIEW
24. Juju + LCX + Jenkins • GitHub Pull Request Builder Pluginを利用 – masterにマージされたものを自動ビルド – organization所属メンバーのPRを自動ビルド – 「ok to test」とコメントされたPRをビルド – 「test this please」とコメントされたら再ビルド → Continuous Writing! (継続的執筆)
25. まとめ • エンジニアはアウトプットするの大事 – 最近はTwitterとかで満足しがちだけどね • 締切に追われないとなかなか手は動かない – 締切駆動開発 • テーマを決めて新しいことに挑戦するの楽しいよ • 原稿書くの楽しいよ 執筆に集中できるシステムの構築大事！
26. Happy Writing!
27. 未承諾広告
28. うぶんちゅ！ まがじん ざっぱ〜ん Vol.3 もくじ 1. OpenNebulaでPCI passthrough 2. Let’s note CF-RZ4にUbuntuをインストールしてみる話 3. 21世紀のDevice Tree 4. ちょーなんさんちのノートPC事情 5. かよちんとボクと、時々、録画 6. 磁気センサーを使った冷蔵庫監視システムの構築 7. 新し目のMozcをビルドする PDF/ePUB3 700円 「ざっぱ〜んブログ」で検索！