（翻訳） WSGIは死んだ: WSGI Liteバンザイ！ - YAMAGUCHI::weblog
はじめに こんにちは、Python界の情弱クレイジー野郎です。この間Armin Ronacherが書いたWSGIに関する記事から、あちこちでWSGIに関する議論が起きてますが、とりあえずその返答記事として書かれたWSGI Liteに関する記事を訳しました。 WSGI Is Dead: Long Live WSGI Lite! (dirtSimple.org) WSGI Is Dead: Long Live WSGI Lite! ほぼ10年前、Web-SIGにはじめてWSGIのアイデアを提案したときに遡ると、WSGIがどう「フレームワーク分解機」になり得るかということに対して、私はいまよりもずっと理想主義的な展望を期待していました。すべてがプラガブルで、モノリシックなアプリケーションフレームワークを持つ理由がもはや一つもないような未来を思い描いていました。すべてライブラリ、ミドルウェア、デコ
superfcgiがよさげ - スコトプリゴニエフスク通信
The only one true way to run WSGI apps through fastcgihttp://pypi.python.org/pypi/superfcgi/superfcgiは「WSGIアプリケーションをFastCGIで動かすための唯一正しい方法」という意欲的なライブラリ。superfcgiはfastcgi.comが提供しているfastcgiappというCライブラリを使っているので、あらかじめインストールが必要。Fedoraの場合は、 $ sudo yum install fcgi-devel fastcgiappをインストールしたならば、 $ pip install superfcgi superfcgiはDjango用のコマンドも用意しているので、settings.pyのINSTALLED_APPSに、 INSTALLED_APPS = ( 'superfc
Spawningを使ってDjangoを動かす - スコトプリゴニエフスク通信
http://pypi.python.org/pypi/Spawning/以下はシングルプロセス・シングルスレッドの場合。プロセス数を増やすには-sオプションを、スレッド数を増やすには-tオプションを指定。 $ cd /paht/to/my_django_project/ $ PYTHONPATH=.. spawn --factory=spawning.django_factory.config_factory -s 1 -t 1 -p 8000 settings 「マルチプロセス・シングルスレッド」か「シングルプロセス・マルチスレッド」の択一になってしまうFastCGI(flup)や、単一のPythonバージョンしか利用できないmod_wsgiと比べるとあなどり難い存在。特定のファイルのタイムスタンプを監視して自動的に再起動、使用する最大メモリ量を制限するといった機能もある。が、どうして
Passenger で Trac
先日開発サーバを準備することになって、Trac を入れる必要があったんですが、そういえば Passenger が WSGI に対応したなぁ、動くかなぁ、と思ったのでさっそくやってみました。 /var/www/vhosts/trac.example.com 内にバーチャルホストを作るという前提です。 Trac 自体はインストール済みで、/var/www/vhosts/trac.example.com/trac に initenv してあるものとします。ここでは説明しません。 Trac ホスト用のディレクトリを準備 $ mkdir -p /var/www/vhosts/trac.example.com/public $ mkdir -p /var/www/vhosts/trac.example.com/tmp/eggs public はドキュメントルート、tmp/eggs は PYTHON_E
mod_passengerでWSGIアプリケーションを動かす - スコトプリゴニエフスク通信
Passenger(mod_passenger)は言わずと知れたRuby on Rails/Rackアプリケーションを動かすための定番サーバーのひとつ。 Phusion Passengerhttp://www.modrails.com/実はPassengerではPython WSGIを動かすこともできる。誰が得するか分からないから誰もほとんど言及していないけど。本番環境でPassengerを使ってWSGIアプリケーションを動かそうとは思わないけど、virtualenvとの親和性が高い、複数のバージョンのPythonを使って開発ができるというメリットもあるから、開発環境では使ってみてもいいかもしれない。あと、すでにmod_passengerの環境が構築済みならば、Trac等の定番アプリケーションを動かす場合でも、mod_wsgiやFastCGIよりも設定が楽な気がする。まあ、こういったケース
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
Django Projectを開発サーバーの使い心地のままにApacheでデプロイする - When it’s ready.
ずーっと、デプロイが苦手だった。 自分でやると全然動いた事が無い。 でも気づけば、いつの間にか出来る様になってた。 今後忘れてしまわないようにメモ。 昨日作った環境でデプロイを行う。 機能的なところ 作成したプロジェクトがきちんと動く事 自動作成されたAdminサイトのデザインもきちんと動く事 静的ファイルはApacheより配信する事 ソースを変更した際には、自動でapacheを再起動する事 下準備 作成したDjangoのプロジェクトは「djangoProject」 /var/www内に、プロジェクトと.wsgiファイルを公開するディレクトリ（django)を作成する。 プロジェクトのソースを展開する（実際はローカルリポからのリンク） /var/www/django/djangoProject アプリケーション名は以下の通り djangoProject.core wsgiの自動再起動用のス
Django1.1 + Ubuntu9.04 + Apache2 +mod_wsgi での環境構築メモ - When it’s ready.
年末の為に、手順を記す。for me Ubuntuのいんすこから終了まで目標20分以内 追記：実際にインスコからやってみた時間を計ってみた Ubuntuインストール 8分 アップデート 8分 インスコsh 4分 ぎりぎり20分という感じ。この程度であれば何回でも出来るな。 Ubuntuインストール file ubuntu-ja-9.04-desktop-i386-20090510.iso インストール後 アップデートを実行する パッケージインストール zsh vim openssh-server easy_install python_all_dev apache2 mod_wsgi ntp memcached django1.1 mercurial1.3.1 python_memcache プロキシーがある場合 export http_proxy=http://proxy.domain.
第4回 Google App EngineでWSGIを使う | gihyo.jp
はじめに 前回までで、WSGIアプリケーションの仕様、アプリケーションの作成、ミドルウェアの利用などの、WSGIの基本的な部分の説明が終わりました。 今回は、作成したWSGIアプリケーションを実行するプラットフォームとして、Google App Engine（GAE) を取り上げます。 Google App Engineとは Google App Engineとは、Googleが提供しているWebアプリケーションのプラットフォームです。基本的に無料でGoogleのスケーラブルなWebアプリケーションインフラで、自作のWebアプリケーションを動作させることができます。アプリケーションはアカウントごとに10個まで利用できます。アプリケーションごとに利用可能なストレージ容量、 CPU 処理時間、データ転送量などのサーバリソースの制限はありますが、月500万ページビュー規模までは利用できる程度の制
WSGIServerを3行でマルチスレッド化する : DSAS開発者の部屋
WSGIとは PythonでWebアプリを作るときに必ず出てくる単語にWSGIがあります。 WSGIとは、Web Server Gateway Interface の略で、WebサーバーとPython製Webアプリを つなげる標準インタフェースです。 WSGIの上で動くようにアプリケーションを作ると、そのアプリケーションは修正無しに Apache+mod_wsgi, Apache+mod_python, fastcgi, scgi, cgi, 等の環境で動かせるように なります。 他にもミドルウェアという考え方があります。例えばOpenID認証機能をWebフレームワークの プラグインとして開発した場合では他のWebフレームワークでは利用できないのですが、 WSGIミドルウェアとして開発すればWebフレームワークを問わずに利用できるようになります。 標準ライブラリのwsgirefモジュール
ajp-wsgiでDjangoを動かす - スコトプリゴニエフスク通信
ajp-wsgi http://www.saddi.com/software/ajp-wsgi/ajp-wsgiはAJPプロトコルでWSGIアプリケーションを動かすためのゲートウェイサーバ。flupと同じようなもの。ajp-wsgiとflupは作者も同じだし、flupもAJPをサポートしているけど、ajp-wsgiはすべてCで書かれているから、flupより速いらしい。作者自身が「もうflupなんて使わねーよww」(意訳)と書いているのを読んだ記憶がある。というわけで、ずっとflupからajp-wsgiに乗り換えたかったのだが、「AJPプロトコルだとフロントはApacheを使わないといけないのか？」と思うと二の足を踏んでいた。 ところが今日、lighttpd 1.5にはAJPプロトコルのProxyがあるということを知り、さっそく試してみた。lighttpd 1.5Subversionでソース
Google App Engineでテスト駆動開発を行うための3つのTips | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記
Google App Engineの開発ではPythonを使います。GAEを使ったWebアプリの開発でテスト駆動開発を行う際にも，Python的なユニットテストの文脈を活用できます。 ただし，GAEでユニットテストを行うためにはいくつかのツールやトリックが必要です。ここでは，そのテクニックを簡単に紹介します。 その1 : NoseGAEを使う Pythonのテスト用ツールにNoseがあります。このツールは，複数のディレクトリを渡り歩いて，複数のテストコードを一気に実行してくれる便利なツールです。 NoseのプラグインNoseGAEをインストールすることで，GAEアプリのテストを楽に行うことができます。「nose --with-gae」というようにオプション指定をすることでNoseGAEを利用できます。NoseGAEでは，テストコード上でGAEのモジュールやパッケージをインポートするために必
第2回 WSGIを使ったもう少し複雑なアプリケーションの作成 | gihyo.jp
はじめに 第1回では「Hello, world.」を出力する簡単なアプリケーションを作成し、WSGIの仕様について説明しました。 しかし、「Hello, world.」のような簡単なアプリケーションからは、実際に作成するアプリケーションの雰囲気のを掴むのは難しいと思いますので、第2回では、もう少し実用的なアプリケーションを例にして、解説をしたいと思います。 MessageBoardアプリケーション 今回作成するアプリケーションは、MessageBoardアプリケーションです。フォームからタイトル、名前、本文を入力して投稿すると、それまでに投稿されたメッセージが一覧される掲示板のようなアプリケーションです。 アプリケーションのソースコードはこちらにZIP圧縮版があります。まずは、ダウンロードして以下のように実行してみてください。 ■注意 サンプルソースmessage.pyで、マルチバイト文
WSGIとしても、CGIとしても動作する環境変数表示アプリ - ぱいそにすたん!
WSGI アプリは iterable を返すという規約が面白い. ジェネレータ関数で iterable が簡単に返せる Python ならではだなあ. #!/usr/bin/env python # -*- coding: utf-8 -*- def application(environ, start_response): status = '200 OK' response_headers = [('Content-type','text/plain')] start_response(status, response_headers) return ('%s: %s\n' % (i, environ[i]) for i in environ) if __name__ == '__main__': from wsgiref.handlers import CGIHandler CGIH
第1回 WSGIの概要 | gihyo.jp
PythonのWebアプリケーションフレームワーク Pythonには、Zope、Twisted、Django、TurboGearsなどのさまざまなWebアプリケーションフレームワークが存在します。以前は、このような幅広い選択肢は、新しくPythonを使用しようとするユーザにとって都合が悪いことがありました。使用するフレームワークによって、利用可能なサーバが制限されてしまったり、逆にサーバによって利用可能なWebアプリケーションフレームワークが制限されるといったことがあったためです。 そのようなPythonの状況とは対照的に、Javaにおいては、多数のWebアプリケーションフレームワークがあるにもかかわらず、サーバとWebアプリケーションをつなぐ際に、統一されたJava Servelet APIを用いることで、アプリケーションフレームワークを気にせずにServelet APIが利用できる環境
mod_wsgi 導入完了(たぶん) - つくば日記 (仮)
以前書いた通り，keyaki での Trac の動作が異常に遅いので mod_python から mod_wsgi に切り替えを試みているのですが，どうにも苦戦しておりました。 が，試行錯誤の果てに何とか導入を完了しました。全プロジェクトが再稼働しています。 結局，次の2つの対策を打つことで「別のTracサイトのデータが表示される」問題を解決することにしました。 Trac環境ディレクトリを .wsgiで os.environ に設定するのではなく，httpd.conf の SetEnv ディレクティブで指定する。 mod_wsgi を Embedded モードではなくDaemon Processモードで稼働させ，機密度の高いプロジェクトと一般プロジェクトを隔離する。 1番目は前回やった通り。一応1週間ほど様子を見たんですが，とりあえずこの方法で問題なく動作しているっぽくはあります。 ただ，
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DEV日記: Pythonの勉強 その13 (macのapacheでmod_wsgiを動かす その2)
Google App Engine 一人勉強会 第一回 とりあえず動かしてみる - Twisted Mind
http://wiki.pylonshq.com/display/pylonsja/PEP333-ja