Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
Djangoチュートリアル（前編）
Djangoの紹介 いよいよ本稿の主役であるDjangoについて紹介します。Djangoはもともとは、アメリカの新聞社の社内ツールとして2003年頃に開発され、2005年7月にBSDライセンスのもとで、オープンソースとして公開されました。 Djangoのコアの部分は、データモデルとリレーショナルデータベース（以下、RDB）との間を仲介するO/Rマッパー、正規表現を活用したURLディスパッチャ、リクエスト要求を処理するビュー、データを表示するテンプレートシステムなどから構成され、Webアプリケーションフレームワークとして、フルスタックの機能を搭載しています。 「The Web framework for pefectionists with deadlines（デッドラインにいる完璧主義者のためのウェブフレームワーク）」とDjango本家サイトのトップタイトルにも記載されているように、忙しい
render_to_responseよりもdirect_to_template？ - 偏った言語信者の垂れ流し
辞書でコンテキストを渡してて気付いたのだが、render_to_responseだとTEMPLATE_CONTEXT_PROCESSORSのコンテキストがテンプレートに渡されていない気がする。 def index(request): return render_to_response('index.html', {'mycontext': 'context'}) これだとMEDIA_URLなどが空になった。 汎用ビューのdirect_to_templateでextra_contextに拡張コンテキストを辞書として渡したほうがいいかもしれない。 def index(request): return direct_to_template(request, 'index.html', extra_context={'mycontext': 'context'})
はてなブログ | 無料ブログを作成しよう
日記_2024.8.29 鞍馬と貴船 29日は鞍馬と貴船に行ってきました。こんな天気でバイクは無理、でも引きこもるのも嫌なので前々から行きたかった鞍馬と貴船に行くことにしました。ただ、いつ大雨が降っても全くおかしくないので天気がヤバそうなら帰ることにします。普通に日帰りできる距離ですから…
django-pistonとbpmappersでWebAPIを作る - 偏った言語信者の垂れ流し
hfunaiの記事に便乗。 http://blog.monospace.jp/2010/10/31/django_piston_intro/ django-pistonを使うとDjangoで簡単にWebAPIを作れます。 jespern / django-piston / wiki / Home — Bitbucket fields/excludeにフィールド名を指定すると、必要なフィールドのみを出力したりできます。 ただ、APIで提供するデータの構造とモデルの構造が一対一の対応にならない場合、辞書を頑張って生成するか、ハンドラのフックポイントを実装するか、Emitterクラスをゴリゴリ書くなど、ちょっと面倒です。 そういう場合に、bpmappersと組み合わせるといいかも、という話です。 今回はGETでデータを取得(参照)する場合のみを想定してます。保存する場合はFormで頑張ろう・・・
Djangoでmodels.pyの分割 - matabii's blog
最近Pythonフレームワーク、Djangoを触ってます。 そこそこ軽量で、テスト用Webサーバやタスクなんか揃ってて気に入っているのですが、使ってると不満も出てきます。その1つがMVCのモデルを表すmodels.pyです。 これ、普通に作ってるとアプリ毎にmodels.pyという名前で用意しないといけないので、沢山のモデルがある場合に巨大なファイルになってしまうし、アプリがいくつかあると、どこに何のモデル置いてたかわからなくなってしまうのです。 希望としては、テーブル名＋.pyとして、プロジェクトに対して1箇所のディレクトリにまとめたいです。まぁそれは出来るのですが、manage.pyタスクのsqlやsyncdbも有効に使いたいです。 これが良い方法かはまだ分かりませんが、何とか出来たのでその方法です。 ディレクトリ構造です。modelsディレクトリを作成して、モデルは全てそこに置きます
Djangoを学ぶのにおすすめの本orサイトは？ - ANS-prog
PyCon JP 2011 Call for Papers:演題募集中 8月27日(土) 9:30～17:10 （仮） 産業技術大学院大学 (品川シーサイド駅から徒歩3分)
ブログ内のDjango記事リンクまとめ - 偏った言語信者の垂れ流し
昨日のリンクまとめが使いやすかったので、Djangoについてもまとめてみた。数が多いのでちょっと大変だった。 各項目の上のほうが新しい記事で下に行くほど古いです。 古い記事は、Djangoのバージョンも古いので役に立たない可能性有り。内容が酷い物もあるけど気にしない。 Tips PostGISのST_SimplifyをGeoDjangoから使う - 偏った言語信者の垂れ流し Django1.3のClass-based generic viewsを使う - 偏った言語信者の垂れ流し 3次元の座標を扱う - 偏った言語信者の垂れ流し Debianで標準のPythonを切り替えてpostgis/python-gdal周りでハマった - 偏った言語信者の垂れ流し djangoのセッションキーについて調べてた - 偏った言語信者の垂れ流し SortedDict - 偏った言語信者の垂れ流し modw
DjangoのORMを使って検索フォームを作るときに少しでも楽をしたい - 今川館
02:14djangoのQuerySet.filterを都度呼ぶのは面倒くさいdjangoで検索画面を作るとき、よくこういうプログラムを書くと思う。 検索条件を入力する為のFormを作る。 Formの入力値で入力されているものだけ条件指定する。入力されていない条件は絞り込みしない。そういうとき、こんな風にプログラムを書くのが結構な苦痛だ。 from django.db.models import Q persons = Person.objects.all() dct = {"name" : "oyakata"} if dct.get("name"): persons.filter(name=dct["name"]) if dct.get("age"): # ORの条件指定にしなければならない -> 面倒くさい # 自分のフィールドだけでなく、ForeignKeyのフィールドも見なければな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
djangoでmodelの図を描いて見る。 - podhmoの日記