Hatena::Groupbugrammer

蟲!虫!蟲!

Esehara Profile Site (by Heroku) / Github / bookable.jp (My Service)
過去の記事一覧はこちら

なにかあったら「えせはら あっと Gmail」まで送って頂ければ幸いです。
株式会社マリーチでは、Pythonやdjango、また自然言語処理を使ったお仕事を探しています

 | 

2013-06-18

[][][] Python(というわりには少なめな)で土日を使ってサービスを作るための中途半端なモダン環境構築メモ 02:45

 というわけで、土日を使ってサービスを作ってみました。

f:id:nisemono_san:20130618013959p:image

FXでの失敗ケース | Just another WordPress site

 サービスの内容としては、過去にブックマークされた本を、ユーザー毎にカラムに分けてランダムに表示するという、非常にシンプルな作りとなっています。レイアウトおよび配色は、知人である豊井さんに指定してもらいました。ありがとうございます!

 で、今回の記事は、サービスの宣伝もかねて、どういう環境で開発したか、という話をメモがてら、ブログの記事にしようと思います。

tmux, あるいはscreenの薦め

 自分は、秘伝のタレ的なものとして、tmuxの画面分割を使って、それぞれのプロセスを立ち上げて監視しています。実際に監視しているものとしては、下の通りになります。

  1. django server
  2. compassの自動生成
  3. testの結果表示
  4. その他コンソール

 で、実際に生成される画面としては、下の通りになります。

f:id:nisemono_san:20130618040139p:image

 このように、画面に情報を一括することにより、便利な感じになります。

testはwatchr.rbで一括管理

 もちろん、言語を統一したほうがはかどるのではあるんですが、自分はwatchrを使ったりしています。watchrはRubyで書かれており、ファイルの更新があるごとに、任意のコマンドを実行するという優れたものです。自分は、ファイルを保存するたびにテストを走らせることで、テスト駆動にできるだけモチベーションを保とうと思っています。

 ただ、このwatchrは、新規ファイルは、変更を見てくれないという欠点があるので、その辺に注意が必要です。

 とはいえ、変更がされるたびにテストを動したとしても、結果をいちいち見に行くのは面倒くさいので、自分はballonを表示するようにしています。その方法については、下のレポジトリが参考になるので、その辺を見ると早いでしょう。

GitHub - hirocaster/phpunit-stack: 車窓からの TDD

蛇足: Pythonのwatchdogについて

 twitterで「watchdogについてはどうなの」というご指摘を頂きました(Thanks!!)。

 で、過去にちょっとwatchdogを使ってみたのですが、少し癖があるところが多いのが欠点なのかなーと思ったりします。具体的には、下のissueを見て頂ければわかりやすいかもしれません。

 恐らくファイル管理で発火するイベントを取得しているのですが、mac osでVimを使うと習得できないとか、その辺が割とだるかった記憶があったり、あるいはVimでファイルを更新すると、createdとmodifedが同時に発火するとかよくわからないことが起きたりとかして、ちょっと避けていたというのも大きかったです。

 このあたりについては上手く使える方法があるのならば、是非こちらのほうを採用したい、という気持ちはあります。なぜならPythonで書かれていますからね! :)

上記の解決について

……と思ったら、解決を教えてくれた人が!(thanks by @kashew_nuts )

どうやらこんな感じらしい。

djangoのテンプレート引数は便利だ

Pythonの情報が少ないよバカ、もっと真面目にやれ」(意訳)というご指摘を頂きました(Thanks!!)

自分はdjangoを使っているのですが、各人に、djangoスケルトン的な、秘伝のタレがあると思います。(例えば、どんなライブラリを普段使っているのか、とか)。そのタレを使って初期状態でプロジェクトをスムーズにするのに、startprojectのオプションとして--templateを渡してあげると超便利です。

例えば、django1.4であるならば、下のようなスケルトンが作られています。

このあたりを使うと、いちいち面倒くさい設定をしなくても、過去のスケルトンで作った設定を使いまわしできるので、とても便利です :)。こういう風にタレを作っておくのも、土日に気軽にサービスを作るときに、効率的になります。

バッチ処理するならdjangoにカスタムコマンドを追加するとはかどるぞ

 ここは常識の範囲かと思われるのですが、バッチ処理に関しては、個別にPythonスクリプトを書くよりも、djangoのmanage.pyにコマンドを追加したほうがはるかに便利です。特にModelなんかでやりとりをする場合は、コマンドを発行して、その上で実行するというのがベターな気がしています。実際に、自分ははてなブックマークを習得するさいに、個別にコマンドを切って、それを実行することによって対応していました。

compassは使え、絶対だ

 実は、このサービス、割とNexusやipadなどの「タブレット」からも、ちゃんとレイアウトしてくれます。場合によっては、タブレットの方が使いやすいかもしれません。これは、compass + susyという組み合わせによって実現されています。

 自分は、sassではなく、scssというのを使っていました。sassはほぼyamlなんですが、scssのほうがcssと近い感じで書けるので、最初から結構書きやすいです。

 まず一つに変数が使えるということ、またmix-inという関数っぽいものが使えること、またネストして構造化できるという、既存のcssではどうしても足りなかった部分を補完してくれます。また、compassは、border-radiusなどの、指定が面倒くさいものに対しても、一括してやってくれます。

 さらにsusyは、それにプラスとしてグリットデザイン、それにレスポンシブな機能を追加してくれるという、至れり尽くせりなので、覚えておいて損はなく、逆に言うならば、普通のCSSなんて書いてらんないよー!と思ったりする部分が出てくるのは避けられないなーと。

サーバーの設定、デプロイfabricを使う

 最近だと、サーバーの環境構築も出来るだけ自動化しようというわけで、例えばChefだったり、Pappetだったりなどのオープンソースが出てきていますが、この両者はよく指摘される通り、学習コストが余りにも高くなってしまうという欠点があります。で、比較的学習コストは低くても力を発揮してくれるものの一つにfabricがあります。そして、このfabricをもっと使いやすくしたものにfabtoolsというものが存在しています。

fabricのいいところは、単に「ssh先で動かしてくれるシェルスクリプト」を構築できるという点にあるでしょう。なので、必要なパッケージであったり、あるいはライブラリをまとめておくことで、構築漏れを防ぐことができます。

デプロイには、.git hookにpost-commitを追加しておくと便利だぞ

 恐らく、gitを使う場合は、何らかのGUIソフトを使う場合か、コンソール画面からいじるかのどちらかだと思うのですが、今回は、post-commitにスクリプトを書いて引っ掛けておきました。その内容は下の通りです。

  1. コミットが走ったら、テストを実行する
  2. テストが成功したら、そのままレポジトリに反映させる
  3. レポジトリに反映させたら、fabricで本番環境に反映させる
  4. Supervisorなど、レポジトリの内容をちゃんと送信できるようにする

 そういう感じでコマンドを書いていると、commitするたびに反映が走るのが面倒くさくなる部分もあるのですが、ただリアルタイムに更新している感覚は出てくるので、そのあたりはデメリットとメリットを比較する必要がありそうです。

蛇足

 サーバー本番環境で、git pullで反映させるのもいいんですけど、ただそれだけだとサーバーに入ってちょっと検証のためにコードを足した場合、余計なコンフリクトが起きてどうしようもないということもあると思うので、git reset --hardとか、その辺を使ってサーバー本番環境のソースは潰してます(もちろん、本番を直接いじるのはよくないですし、それが正論です)。サーバーにあるのは、レポジトリの内容にあるものである必要があるので、むしろ余計な衝突を避けるためにはいいのかなと。

さらなる蛇足

 例えば、継続的デリバリーに関しては、Jenkinsでビルド・パイプラインを作るという手もあるのですが、どちらかというと、これは共同開発の部分において重要になってくるところではあって、一人でやっていて、かつ常にテストをぶんなげていると、その辺の利点が実は薄いのかな、という気はしたので、上記のアプローチになっています。もちろん、何かしらの共同開発の環境では、Jenkinsは便利だし導入するべきだと思います。

Supervisor + gunicorn + nginxで作成

 基本的にフロントに立っているのは軽量なもので足っているのでいいだろう、というのが一つと、どうせgunicornと連携するんだったら、連携しやすいものがいいだろう、ということでこういう構成になっていたりする。で、Supervisorは、daemontoolsの強力版と考えると正しい。例えば、死んだプロセスを自動的に立ち上げたりなどの管理を一括してやってくれるので便利だ。gunicornは、Rubyunicornみたいなもので、とにかく早いのが特徴(?)と言うべきだろうか。

 さらには、Supervisorのコマンドツール(Supervisorctl)を使うことによって、持ってきたソースを反映させるということが非常に楽になるというところも利点だろう。

Vim限定

Vimのプラグインであるsyntasticは超絶便利なので導入するといいかと。とりあえず、pip8標準であったり、あるいは静的解析(pyflakes)を使うならば、入れておいて損はないでしょう。もちろん、単独のpep8というコマンドや、pyflakesを入れて定期的にぶんなげるのもいいでしょう。

まとめ

今回は、とりあえず「今のところこういう環境で作っています」ということを解説してみましたが如何でしょうか。次回は、個別の情報に関して共有することで、実際にはどういう風なプロセスで書いたのか、あるいはどういう風に企画をFixされたのかなどを考えたいと思っています。

あともうちょっとだけ続くんじゃよ……

takano32takano322013/06/18 05:38pyflakes のかわりに vim-flake8 を使っているなぁ。

 |