wozozoのブックマーク - はてなブックマーク

fabfileの構造化 - logiqboard

fabfile.pyって、task数個までならまあ1ファイルでいいんですが、それ以上増えてくるとスクリプト自体がカオスになって収集がつかなくなります。更に似たような、けど微妙に違うtaskをいっぱい定義したりすると名前まで酷くなってきます。こんなかんじに。 @roles('lb') def lbserver_deploy(): """ロードバランサーにデプロイする""" ... @roles('app') def appserver_deploy(): """アプリケーションサーバーにデプロイする""" ... @roles('batch') def batchserver_deploy(): """バッチサーバーにデプロイする""" ... こんなファイルメンテする気が起こらないので、なんとか綺麗にしたいと思って調べたところ、fabric1.1から付いたクラスベースのtaskというのを

wozozo 2011/09/16

fabric

リンク

クラスベースビューとreverseとDjangoのURLディスパッチ - logiqboard

以下、django1.2.0時点の話です。参照: クラスベースビューとデコレータとkwargs - logiqboard viewクラスを使ったURL設計前回の記事でいうところのshopとgoodsのように、URL・機能的にはshopという大枠にまとまってはいるんだけど、その中に小機能がいっぱいあってshopにベタ実装するときたねーという場合は、上位アプリに完全依存するサブアプリみたいのを作るのも一つの手です。再掲ですがurlsのところはこんなイメージ。 class ShopViews(object): @property def urls(self): from django.conf.urls.defaults import url, patterns return patterns("", url("$", self.index, name=u"index"), url("go

wozozo 2010/05/20

リンク

Django+Tritonnで日本語全文検索〜重み付けもあるよ〜 - logiqboard

DBにTritonnを使ってDjangoから全文検索をする　という話 Tritonnってなに？どうやって入れんのかつあいモデル構造 class Book(models.Model): """本""" title = models.CharField(max_length=255) desc = models.TextField() pub_date = models.DateTimeField(auto_now_add=True) class BookSearch(models.Model): """本の検索テーブル""" book = models.OneToOneField(Book) title = models.CharField(max_length=255) desc = models.TextField() 全文検索に使いたいカラムを持った〜〜Searchモデルみたいなの

wozozo 2010/03/21

リンク

mercurialでチケット駆動開発 - logiqboard

本格的にmercurialを使い始めて数ヶ月、色々ノウハウがたまったのでまとめてみる。想定する状況 VCSはmercurial一本で運用 IssueがなにかしらのBTSで管理されており、チケット単位でかつ並列に開発を進めたいリリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない　という状況がありえるリポジトリ配置中央(central) どこかの共有サーバー上にあり、全ての開発成果が集まる場所。中央@個人用(default) ↑と同じ場所にある個人の開発用の中央リポジトリ。個人ローカルと完全に同期する。確認環境(test) 中央からclone, pullされる。リリースチェック、各チケットの動作確認を行う。個人ローカル個人の開発環境上に置かれるリポジトリ。やりたい放題する。ブランチ運用 default リリースブランチ

wozozo 2009/12/07

mercurial

リンク

nullpobug勉強会04 "wsgiってなに" - logiqboard

またも間が空いてしまったnullpobug勉強会と、そのまとめ。今回のテーマはwsgiについて。講師：id:nullpobug 生徒：id:feiz wsgiってなに web server gateway interfaceの略。 webサーバーとアプリケーション間の通信規約を定めたもの。 PEP-333に仕様が記述されている。具体的にサーバー側のきまりごと環境変数をdict形式で提供するよ。アプリを application(env, start_response) って形で呼び出すよ。 envは辞書形式の環境変数、start_responseはレスポンスヘッダを返すためのコールバックだよ。アプリ側のきまりごと envとstart_responseの２つの引数を受け取るcallableとして実装するよ。 envはサーバー側で作った環境変数のdictで、start_respon