なにかあったら「えせはら あっと Gmail」まで送って頂ければ幸いです。
株式会社マリーチでは、Pythonやdjango、また自然言語処理を使ったお仕事を探しています
というわけで、土日を使ってサービスを作ってみました。
サービスの内容としては、過去にブックマークされた本を、ユーザー毎にカラムに分けてランダムに表示するという、非常にシンプルな作りとなっています。レイアウトおよび配色は、知人である豊井さんに指定してもらいました。ありがとうございます！
で、今回の記事は、サービスの宣伝もかねて、どういう環境で開発したか、という話をメモがてら、ブログの記事にしようと思います。
自分は、秘伝のタレ的なものとして、tmuxの画面分割を使って、それぞれのプロセスを立ち上げて監視しています。実際に監視しているものとしては、下の通りになります。
で、実際に生成される画面としては、下の通りになります。
このように、画面に情報を一括することにより、便利な感じになります。
もちろん、言語を統一したほうがはかどるのではあるんですが、自分はwatchrを使ったりしています。watchrはRubyで書かれており、ファイルの更新があるごとに、任意のコマンドを実行するという優れたものです。自分は、ファイルを保存するたびにテストを走らせることで、テスト駆動にできるだけモチベーションを保とうと思っています。
ただ、このwatchrは、新規ファイルは、変更を見てくれないという欠点があるので、その辺に注意が必要です。
とはいえ、変更がされるたびにテストを動したとしても、結果をいちいち見に行くのは面倒くさいので、自分はballonを表示するようにしています。その方法については、下のレポジトリが参考になるので、その辺を見ると早いでしょう。
hirocaster/phpunit-stack ? GitHub
実は、このサービス、割とNexusやipadなどの「タブレット」からも、ちゃんとレイアウトしてくれます。場合によっては、タブレットの方が使いやすいかもしれません。これは、compass + susyという組み合わせによって実現されています。
自分は、sassではなく、scssというのを使っていました。sassはほぼyamlなんですが、scssのほうがcssと近い感じで書けるので、最初から結構書きやすいです。
まず一つに変数が使えるということ、またmix-inという関数っぽいものが使えること、またネストして構造化できるという、既存のcssではどうしても足りなかった部分を補完してくれます。また、compassは、border-radiusなどの、指定が面倒くさいものに対しても、一括してやってくれます。
さらにsusyは、それにプラスとしてグリットデザイン、それにレスポンシブな機能を追加してくれるという、至れり尽くせりなので、覚えておいて損はなく、逆に言うならば、普通のCSSなんて書いてらんないよー！と思ったりする部分が出てくるのは避けられないなーと。
最近だと、サーバーの環境構築も出来るだけ自動化しようというわけで、例えばChefだったり、Pappetだったりなどのオープンソースが出てきていますが、この両者はよく指摘される通り、学習コストが余りにも高くなってしまうという欠点があります。で、比較的学習コストは低くても力を発揮してくれるものの一つにfabricがあります。そして、このfabricをもっと使いやすくしたものにfabtoolsというものが存在しています。
fabricのいいところは、単に「ssh先で動かしてくれるシェルスクリプト」を構築できるという点にあるでしょう。なので、必要なパッケージであったり、あるいはライブラリをまとめておくことで、構築漏れを防ぐことができます。
恐らく、gitを使う場合は、何らかのGUIソフトを使う場合か、コンソール画面からいじるかのどちらかだと思うのですが、今回は、post-commitにスクリプトを書いて引っ掛けておきました。その内容は下の通りです。
そういう感じでコマンドを書いていると、commitするたびに反映が走るのが面倒くさくなる部分もあるのですが、ただリアルタイムに更新している感覚は出てくるので、そのあたりはデメリットとメリットを比較する必要がありそうです。
git pullで反映させるのもいいんですけど、ただそれだけだとサーバーに入ってゴニョるときに面倒くさいことになるので、git reset --hardとか、その辺を使ったりしています。サーバーにあるのは、レポジトリの内容にあるものである必要があるので、むしろ余計な衝突を避けるためにはいいのかなと。
例えば、継続的デリバリーに関しては、Jenkinsでビルド・パイプラインを作るという手もあるのですが、どちらかというと、これは共同開発の部分において重要になってくるところではあって、一人でやっていて、かつ常にテストをぶんなげていると、その辺の利点が実は薄いのかな、という気はしたので、上記のアプローチになっています。もちろん、何かしらの共同開発の環境では、Jenkinsは便利だし導入するべきだと思います。
基本的にフロントに立っているのは軽量なもので足っているのでいいだろう、というのが一つと、どうせgunicornと連携するんだったら、連携しやすいものがいいだろう、ということでこういう構成になっていたりする。で、Supervisorは、daemontoolsの強力版と考えると正しい。例えば、死んだプロセスを自動的に立ち上げたりなどの管理を一括してやってくれるので便利だ。gunicornは、Rubyのunicornみたいなもので、とにかく早いのが特徴（？）と言うべきだろうか。
さらには、Supervisorのコマンドツール(Supervisorctl)を使うことによって、持ってきたソースを反映させるということが非常に楽になるというところも利点だろう。
Vimのプラグインであるsyntasticは超絶便利なので導入するといいかと。とりあえず、pip8標準であったり、あるいは静的解析(pyflakes)を使うならば、入れておいて損はないでしょう。もちろん、単独のpep8というコマンドや、pyflakesを入れて定期的にぶんなげるのもいいでしょう。
今回は、とりあえず「今のところこういう環境で作っています」ということを解説してみましたが如何でしょうか。次回は、個別の情報に関して共有することで、実際にはどういう風なプロセスで書いたのか、あるいはどういう風に企画をFixされたのかなどを考えたいと思っています。
あともうちょっとだけ続くんじゃよ……
takano322013/06/18 05:38pyflakes のかわりに vim-flake8 を使っているなぁ。