Presentation slide for #pyconjp2014

1. "Continuous Publication"
with Python:
Another Approach
This presentation will be in JAPANESE

2. 英語必須と勘違いした orz

3. 発表者自己紹介
• 宮川大輔 (@amedama)
• 株式会社 mokha 取締役
• 「もか」 (もくは)
• 前職: Google Inc. (U.S, Android部門)

4. Continuous Publication
継続的出版

5. 造語

6. 「書籍」ビルドシステム
を作ってみた

7. 「書籍」ビルドシステム
Griflet
• PDF, epub, InDesign, …
• Re:VIEWを採用
• 同人誌～商業書籍の「ビルド」
• 「書籍執筆」を支援

8. Re:VIEW
• 書籍執筆に強い軽量マークアップ言語
• https://github.com/kmuto/review
• @kmuto, @takahashim, @kdmsnr, …
• TeX, epub, HTML, InDesign, …
• 参考図書: https://github.com/TechBooster/FirstStepReVIEW

9. Grifletのきっかけ
• 同人誌『Effective Android』
• C84 (2013年 夏コミ)
• 著者22人, 184ページ
• Re:VIEW + GitHub → すごい！
• だが……
TechBooster代表
@mhidaka

10. ビルド失敗に
気づかない

11. ビルド失敗に気づかない
• 執筆中はビルド結果に無頓着なことが多い
• 「HTMLが作れてるのでコミット」
→PDFのビルドが成功するとは限らない
• Continuous Integration 環境が( ﾟдﾟ)ﾎｽｨ…

12. 自分で作った

13. (2) WebHook
(1) commit
(3) Build Req.
(4) Build
(6) Download
(5) Notify
Linux
Re:VIEW

14. デモ

15. ……のサブセット

21. 割と手探り
• Django, Celery初めて
• 「virtualenvって何 (́・ω・｀)」
• 当初、1プロジェクトのみサポート

22. 同人誌 → 商業書籍
• 『Effective Android』(TechBooster) = 同人誌
『Effective Android』(達人出版会) = 電子書籍
『Effective Android』(インプレスジャパン) = 紙商業
• 共著者 22人 → 33人
• epub もサポート
• Re:VIEW偉大 (＞ヮ＜)

23. 次のお題
• TechBooster @ C85 (2013年 冬コミ)
• 4冊同時刊行
• 合計1書籍 -> 合計5書籍

24. ビルドが
たまに止まる orz

25. 「たまに止まる」問題
• たまに … 1週間に一回とか
• 原因: Celery + GitPythonの組み合わせ
• 根本原因は未解明
• 迂回策: subprocess.Popen + git

26. Re:VIEWが暴走する

27. Re:VIEW暴走事件
• Re:VIEW側のバグ (正規表現が無限ループ化)
• Celeryのタイムアウトも効かず……

28. 動かなくなったら
すぐ教えて欲しい

29. Zabbix
• OSSの監視ソフト

30. C85 も無事に終了

31. そこそこ評判が良い

32. クチコミヽ(=́▽`=)ﾉ

33. クチコミ
• 「友人の友人」のプロジェクトも扱い始める

34. ……えっ (ﾟДﾟ)

35. 知らない人の
Re:VIEWプロジェクト

36. is 脅威

37. あるいは

38. Re:VIEW is 脆弱性

39. 「Re:VIEWは脆弱性」問題
• Re:VIEWではRubyコードで命令を拡張出来る
• OSコマンドインジェクションそのものじゃね？
• サンドボックスが( ﾟдﾟ)ﾎｽｨ…

40. • Immutable Infrastructure
• 「軽量VMでOSを囲って実行 -> 廃棄」
• ぴったり(●́ω｀●)
• ……と油断していると

41. ＿人人人人人人＿
＞ 突然の死 ＜
‾Y^Y^Y^Y^Y^Y‾

42. Dockerは不安定？
• あくまで過去形 = 今は比較的安定している
• 実際、Dockerのバグには何度か出会った
• 自分のミスという部分も多々あった
• モニタリング大事

43. (2) WebHook
(1) commit
(3) Build Req.
(4) Build
(6) Download
(5) Notify
Linux
Re:VIEW

44. (2) WebHook
(1) commit
(3) Build Req.
Re:VIEW
(4) Build
(6) Download
(5) Notify
Linux

45. C86 (2014年 夏)
• またもやTechBooster
• 他サークルの同人誌も

46. 粛々と開発

47. 開発上の課題

48. 「片手間」開発

49. 「片手間」開発
• 長いスパンで少量の実装をちまちま
• 一人で「1ヶ月に2～3日。まとめて」

50. そして忘れる
• 設計・実装・運用の詳細を、忘れる
• どのような問題が発生していたかを、忘れる
• ユーザフィードバックを、忘れる
• 自分が何を達成したいのかまで、忘れる
• しばしばここで作るのをやめてしまう

51. よくあるよね

52. 諦めない(｀･ω･́)

53. 対策を考えてみる

54. 対策 1

55. メモる

56. 対策 1: メモる
!
• Redmineのチケットに、メモる
• ソースコードへのコメントに、メモる

57. 「古くてアホくさいメモ」
忘れるよりマシ

58. 見るのはﾊｽﾞｶｼｨ (∩∀｀*)

59. Redmineのチケット
• 作りたい機能、設計上の課題、未解明な点を記録
• 現在: 合計200チケット超 (未完了100超)
• 不定期の見直しで「思い出す」

60. コードへのコメント
• 「理由」「意図」「疑問」をなるべく残す
• 含「よく分かってないんだけど何故かこうなる」
• 「何をしているか」のコメントは避ける
• 整合性がとれなくなると余計に混乱する

61. 対策 2

62. ログる

63. 対策 2: ログる
• = ログに残す
• 「ここ通ったら、あかーん」というログも
• コメントの代わりにログにしてしまう
• RotatingFileHandlerでサイズを抑える
• 注: サービス規模が大きくなったらもちろん無理

64. それでも見失う
• print() になってる
• logging.debug() って書いてる

65. Loggerを活用する
• print()を避ける
• “logging”自体
インポートしない
• 関数の仮引数にlogger
• http://qiita.com/amedama/items/
b856b2f30c2f38665701
from logging import getLogger, DEBUG
from logging import NullHandler
local_logger = getLogger(__name__)
handler = NullHandler()
handler.setLevel(DEBUG)
local_logger.setLevel(DEBUG)
local_logger.addHandler(handler)
!
def some_func(…, logger=None):
logger = logger or local_logger
logger.error(u“some_func() なう”)

66. 「開発ログ」と「運用ログ」
• Logging Context が与えられない
• 1つの関数で2つのloggerを管理したくはない

67. テスト……？

68. ユニットテスト
• モックアウトが「無駄」になりやすい
• 「外部ツールのリアルな挙動」が問題の発生源
• Viewについて重点的に

69. 回帰テスト/結合テスト
• 外部の世界: Docker, Re:VIEW, ……
• 片手間の最中に「変わってしまう」ことがある
• 効率的にこの変化を捉える(́・ω・｀)

70. Python処理系も外部に？
• 例: Python 2 v.s. Python 3

71. Linux
Re:VIEW
Re:VIEW
Re:VIEW
Python 2.7
Python 3.4
Python 3.5
(願望です)

72. 今後について

73. 今後のGriflet
• 未だ「粛々と開発」
• 「一般公開」出来る水準にしたい
• 一部オープンソース化
• https://github.com/dmiyakawa/pyrev
• Re:VIEWのメタデータ解析 + Lintチェッカ

74. ありがとうございました
この後オフィスアワーにいます

75. This page is
intentionally left blank

76. ……

77. まだまだ続くんじゃ
(｀･ω･́)
発表で使わなかったスライドが延々続きます

78. 「片手間」開発
≒ 趣味

79. 問題を愉しむ

80. 運用環境の裏でテストしたい
• 新しい原稿データでその場で「A/B テスト」
• ここはあくまで今後の「希望」

81. Re:VIEW
Linux

82. Re:VIEW
Linux
(WSGI)

83. Linux
(WSGI)
Re:VIEW

84. Linux
Re:VIEW
Re:VIEW
Re:VIEW

85. Linux
Re:VIEW
Re:VIEW
Re:VIEW
Python 2.7
Python 3.4
Python 3.5

86. Linux
Re:VIEW
Re:VIEW
Re:VIEW
Python 2.7
Python 3.4
Python 3.5

87. あくまでアイディア

88. 楽か？(́・ω・｀)

89. バージョン管理の苦悩
• 分離した部分でのセキュリティは自分で責任を持つ
• 他人 (OSディストリビューション等) に
どこまで頼って、どこから自分でやるのか？
• 全環境を expose するわけではないので……
• ただ、考えておく必要はある

90. 新しい何か
≒ 新しい問題
≒新しい発見
• 「検証 ~= 実装」
• 公開サービスではないので落ちてても切れる赤の
他人がいない (今回助かるポイント)
• 簡単な部分で敢えて一歩踏み出す
• 経験値目当て
• ただし、ヤバそうな点は忘れないようにメモする

91. ライブラリなのか
それより下なのか
• 多様な条件を切り替えられると気分が楽
• CentOSに乗っける？問題ないだろ(｀･ω･́)
• ……systemdコワイ(́・ω・｀)
• OS固有の問題、Python環境の問題、ライブラリの
問題、外部サービスの問題
• 切り分けられるポイントで切り替える練習

92. 実際、環境の一本化に
やや難を感じている
• 個人の事情もあるものの
• 開発マシン: Debian 7 (wheezy)
• 個人サーバ: Debian 7 (wheezy)
• テスト環境: Ubuntu 12.04 LTS / Ubuntu 14.04 LTS
• 「これも経験」と割り切る
• (仕事の運用環境は一本化するのがベター)
• BSDマダー

93. 違うLinux
細かいところでズレる
!
• Ubuntu 12.04 -> django 1.3
• 使っていた reverse_lazy() がない
• Pythonから上のレベルではせめて統一……

94. 分離

95. virtualenv / venv
• Python実行環境分離
• 実行環境を(言語バージョン同じで)もう一つ作る
• PyPiのパッケージも別管理
• 最近 (3.3以降) なら(py)venv
• 以降 venv = virtualenv or pyvenv
• ……というか、どう呼ぶのがベストなの？

96. Django + venv の苦悩
• activate忘れ (Apache, Celery含めて)
• しかもある程度動作してしまうこともある……
• OS本体側にsudo pip全くしないのはどう？
• あるいはmanage.pyの段階で強制？

97. Python環境も
選びたくなる

98. Python環境も選びたい
• virtualenvはPythonバージョン固定
• make install すればいいのだが
• 何かラフにでいいから管理したい

99. pyenv + venv
• pyenv で任意のPython実行環境を(ユーザレベルで)用意
• virtualenvのPython実行環境まるごと版みたいなの
• https://github.com/yyuu/pyenv
• rbenvのPython版なのでpyenv
• 注意: pyenv ≠ pyvenv
• venvを用いて、プロジェクト固有の環境をもう一つ作る
• 3.系のpyvenvでは--copyを付けた方がベター

100. pyenv 実用例
• Debian 7 のPython 2.7.3にマイナーなバグが……
• PyPiへのWindowsバイナリがアップ出来ない？
• pyenvで2.7.6を入れることで回避出来た様子
• 言語環境の軽いA/Bテストに使える

101. 3種類のPython環境
• システムレベル (OSパッケージ管理)
• 保守的、OSに付属する環境が使う
• ユーザレベル (pyenv)
• 複数のPython環境をユーザが切り替える
• OS付属のマイナーバージョンに不満がある場合にも便利
• プロジェクトレベル (pyenv + venv)
• プロジェクト毎にPython (+ PyPi) 環境を独立して持つ

102. mod_wsgiの苦悩
• venvはApache + mod_wsgi のバージョンを
強制できるわけではない
• mod_wsgiのPythonバージョンはOS毎に異なる
• 特に2と3の両立は不可
• 他のWSGI依存のプロジェクトに影響する
• 安易に変更はできない

103. WSGIを境界に

104. 今試していること
• pyenv + venv + Supervisor + tornado +
Apache mod_proxy
• どんどん複雑化していておじさん悲しいな

105. Supervisor
• daemon管理のためのdaemon
• Celeryを複数のDjangoプロジェクトで使いたいなら必須
• 後述するtornadoの管理にも使う
• OSによっては標準のバージョンが超古くアレなことが？
• Debian 7 -> 2010年の頃のもの
• 必要なら sid (unstable) からソースビルド

106. tornado
• スタンドアローンWeb(WSGI)サーバ
• http://www.tornadoweb.org/en/stable/
• Apacheのmod_wsgiを迂回するために使う。
• Django 1.7 + tornadoでの注意
• django.setup() 忘れるなや
• 古い「tornado + Djangoを試してみた」系の記事内容だけだとハマる
• http://qiita.com/amedama/items/a8f511bd75a14aac0277
• 「異なるバージョンのPython(wsgi)アプリを一つの開発環境上で動かす」

107. 素朴な疑問
Supervisor v.s. systemd
• 全く分からん(́・ω・｀)

108. 気軽に試せる環境が嬉しい
• 「Python 3.X + Django 1.Y」をさっくり用意
• /opt 下に一度に飼える
• http://qiita.com/amedama/items/a8f511bd75a14aac0277
• http://qiita.com/amedama/items/79994598d9f4daa69d13

109. 楽しい!!!
✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌

110. ふたたび
ありがとうございました

111. 想定問答集

112. なぜmd/rst/etc.じゃない？
• 極端な話、非常に抽象的なXMLを定義すれば
なんでも書ける……はず。
• それをしたくない適切な「軽量マークアップ」は何か
• Re:VIEWは複数種類のアウトプット向け
• 新しい文法的に拡張をし易い
• 文法定義毎に固有の命令を埋め込みやすい
• ただし「HTML出たけどPDFとInDesignが死んでる」が起こる
• 日本の書籍事情に関与している方々が主導している
• 参考: https://github.com/TechBooster/FirstStepReVIEW

113. Sphinx？
• あ、ほら、最初良く知らなかったし(́・ω・｀)

114. それ使ってみたい
• Ask @amedama (Facebook dmiyakawa)

115. ☆（ゝω・）vｷｬﾋﾟ