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

28
継続的執筆 Continuous Writing GitHub + Re:VIEW + Jenkinsによる 同人誌執筆システムのご紹介 2015/08/29 第4回OpenIL 株式会社インフィニットループ 水野 源 [email protected]

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

継続的執筆Continuous Writing

GitHub + Re:VIEW + Jenkinsによる同人誌執筆システムのご紹介

2015/08/29 第4回OpenIL株式会社インフィニットループ

水野 源[email protected]

A long time ago in a Japan far,far away...

—遠い昔、日本の片隅で

Ubuntu Magazine Japan

という雑誌があったのよ……

● 日本で唯一のUbuntu専門誌● 編集長がガチUbuntuユーザー● Ubuntuの中の人が完全監修● 発行印税の1%をUbuntuコミュニティに寄付● バックナンバーはCCライセンスで無料公開

と、割と(出版業界的に)すごい雑誌でした

ところが色々あり、この号を最後に休刊

商業誌が出ないなら同人誌を作ればいいじゃない

できました

そんな同人誌もこの夏で3冊目

今回から執筆が大幅にシステム化されました

そもそも何が必要か?

● 本を作るには– 原稿フォーマット– PDFとePUBを生成できる仕組み

→Re:VIEW

そもそも何が必要か?

● 執筆は複数人で– 原稿を取り纏めるためのコラボレーションシステム– 差分管理– 手マージはもうしたくない

→GitHub

Re:VIEWってなに?

● テキストマークアップ原稿フォーマット● WikiやRDのような簡易マークアップ言語

● LaTeX→PDFやePUBでの出力が可能

● Ruby製● 青木峰郎さんが開発、武藤健司さんがメンテ

例 Re:VIEW原稿

= 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環境で物理マシン上のハードウェアデバイスを仮想マシンに提供する方法に取り組んでみたいと思います。

== 前置き

これをコンパイルすると

こうなる

Re:VIEWファイル

Re:VIEWコンパイラ

LaTeX

dvipdfmx

review-epubmaker

ePUBおよびPDFの生成

印刷に耐えうる品質

まあ裏はLaTeXだしね……

コラボレーションツール

● 執筆は複数人で同時に進行する● 追記、修正、ロールバックなどは随時発生● 編集長はマージ、差し戻しを判断、実行● Re:VIEWのコンパイルエラーを起こしてはいけない

要求されることはプログラミングと同じ!

→ GitHubが超有効

ただしGitHubを使うのは今回が最初で最後

GitHub プライベートリポジトリ

GitHub Flowベースの作業

● masterブランチの編集、pushは避ける● 編集する時は必ずトピックブランチを作る● masterブランチへの反映Pull Request経由で

● Pull Reqのテストが通った時のみマージを行う

● masterへのマージはGitHub API経由で

masterブランチは神聖である

● masterは常にデプロイ可能でなければいけない● テストをパスしてないものはマージしない

– 言い換えると……– マージ前にはブランチのテストが必須– マージ後もリグレッションテストが必須

→ やっぱりプログラミングと同じ!CI(Continuous Integration)が必要

そこで執事Jenkins

Juju + LCX + Jenkins

● Amazon EC2上にJujuを用いて構築– Ubuntu 14.04 LTS 64bit

– Ruby 1.9.1(公式リポジトリのパッケージ)

– TeX Live 2013(公式リポジトリのパッケージ)

– GemでインストールしたRe:VIEW

Juju + LCX + Jenkins

● GitHub Pull Request Builder Pluginを利用– masterにマージされたものを自動ビルド

– organization所属メンバーのPRを自動ビルド

– 「ok to test」とコメントされたPRをビルド

– 「test this please」とコメントされたら再ビルド

→ Continuous Writing! (継続的執筆)

まとめ

● エンジニアはアウトプットするの大事– 最近はTwitterとかで満足しがちだけどね

● 締切に追われないとなかなか手は動かない– 締切駆動開発

● テーマを決めて新しいことに挑戦するの楽しいよ● 原稿書くの楽しいよ

執筆に集中できるシステムの構築大事!

Happy Writing!

未承諾広告

うぶんちゅ! まがじん ざっぱ〜ん Vol.3

もくじ

1. OpenNebulaでPCI passthrough

2. Let’s note CF-RZ4にUbuntuをインストールしてみる話

3. 21世紀のDevice Tree

4. ちょーなんさんちのノートPC事情

5. かよちんとボクと、時々、録画

6. 磁気センサーを使った冷蔵庫監視システムの構築

7. 新し目のMozcをビルドする

PDF/ePUB3700円

「ざっぱ〜んブログ」で検索!