エキスパートPythonプログラミング改訂2版 作者:Michal Jaworski,Tarek Ziade発売日: 2018/02/26メディア: 単行本 はじめに — Webアプリケーションフレームワークの作り方 in Python の資料が最近になってホットエントリー入りし、思ったよりも多くの方に読んでいただけているようです。見返しているとWSGIサーバーを作りながらHTTPについて学べる章があってもいいかもとふと思いました。書くとすれば内容的には id:shimizukawa さんのPyCon JP 2018の発表をもう少し詳しく説明する資料になりそうな気がします。 PyCon JP 2018: Webアプリケーションの仕組み - 清水川のScrapbox とはいえ自分もWSGIサーバーを一度も書いたことがないので、気分転換にシンプルなWSGIサーバーを書いてみました。 4時間ぐら
PythonのWebアプリケーションフレームワーク Pythonには、Zope、Twisted、Django、TurboGearsなどのさまざまなWebアプリケーションフレームワークが存在します。以前は、このような幅広い選択肢は、新しくPythonを使用しようとするユーザにとって都合が悪いことがありました。使用するフレームワークによって、利用可能なサーバが制限されてしまったり、逆にサーバによって利用可能なWebアプリケーションフレームワークが制限されるといったことがあったためです。 そのようなPythonの状況とは対照的に、Javaにおいては、多数のWebアプリケーションフレームワークがあるにもかかわらず、サーバとWebアプリケーションをつなぐ際に、統一されたJava Servelet APIを用いることで、アプリケーションフレームワークを気にせずにServelet APIが利用できる環境
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
便利で超強力なWSGIサーバー uWSGI を使ってみよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Nginxをダウンタイム・ゼロで入れ替える方法」で書いたように、/usr/local/nginx/ のNginxを version 1.0.13 に更新しました。これとは別に、catyというユーザーアカウントのホームディレクトリ内にNginxをインストールして、Nginx+uWSGIとCatyの実験をしようとしています。 Nginx+uWSGIは、Catyに限らず一般的なWSGIアプリケーションを稼働させる良い環境を提供します。簡単に紹介しましょう。 内容： WSGIとuWSGI なぜ Nginx+uWSGI にしたのか uWSGIについて少し インストール とりあえず動かしてみる ソレナリに動かしてみる プロセスの制御など WSGIとuWSGI WSGI（Web Server Gateway Interface）*1は、Pythonで書かれたWebアプリケーションとアプリケーションサー
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
Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It's a pre-fork worker model. The Gunicorn server is broadly compatible with various web frameworks, simply implemented, light on server resources, and fairly speedy. Installation Here's a quick rundown on how to get started with Gunicorn. For more details read the documentation. $ pip install gunicorn $ cat myapp.py def app(environ,
kuma8さんが簡潔かつ的確なまとめを書いてくださっているが、とりあえず記録しておく。今回試した環境は、CentOS 5.2Python 2.6 Django 1.0.1-beta 必要なライブラリをインストールするServer版のCentOSを普通にインストールしたらApache2は入っているはずなので、この点は省略。今回はCentOS標準のPythonではなく、独自にインストールしたPythonを使うという前提で話を進めるので、python-develは必要ではない。 $ sudo yum install apr-devel apr-util-devel mod_wsgiをビルドするmod_wsgiの最新版2.3をダウンロードしてビルドする。使用するPythonのパスは、/usr/local/bin/python-2.6であるとする。 $ http://modwsgi.googleco
Rack や WSGI の代わりになる仕様を考えてみました (ライブラリ (rack.rb や wsgiref.py) のほうではなく、プロトコル仕様のほうです)。自分のアイデアを書き連ねただけなので、まとまってないかもしれませんがご了承ください。 なお本稿は、今後何度か改訂すると思います。ご意見があればご自由にコメントしてください。 【対象読者】Rack や WSGI に興味のある人 【必要な知識】Rack や WSGI の基礎知識 Rack と WSGI の概要 Ruby の Rack や Python の WSGI は、HTTP のリクエストとレスポンスを抽象化した仕様です。 たとえば Rack では: 引数として、リクエストを表す Hash オブジェクトを受け取り、 戻り値として、レスポンスのステータスコードとヘッダーとボディを返します。 class RackApp def cal
Welcome | Werkzeug (The Python WSGI Utility Library)
Werkzeug¶ werkzeug German noun: “tool”. Etymology: werk (“work”), zeug (“stuff”) Werkzeug is a comprehensive WSGI web application library. It began as a simple collection of various utilities for WSGI applications and has become one of the most advanced WSGI utility libraries. Werkzeug doesn’t enforce any dependencies. It is up to the developer to choose a template engine, database adapter, and ev
AppServerはWSGI等にインスパイアされたPHP製のWebアプリケーションサーバ。 AppServerはPHP製のオープンソース・ソフトウェア。PHPはWebサイトの開発でおそらく最も利用されているプログラミング言語だろう。10年前ならともかく、今では企業の基幹システムでさえ利用されるようになっている。Apache + mod_phpという組み合わせが一般的だ。 デモ画面 それをデファクトと受け止めるのは良いが、それ以外の選択をなくしてしまうのは発展性がない。Apache以外、例えばnginxで動かす場合や他のWebサーバを想定するならば依存関係がない方が良い。それを実現するのがAppServerだ。 AppServerはRubyでいうRack、PythonでいうWSGIにインスパイアされて開発が行われている。APIを通じてWebアプリケーションとWebサーバをつないでくれる。アプ
今までuWSGIをシングルスレッド、マルチプロセスで使っていたのだけれども、昔に比べて外部のAPI呼び出しが増えているのでマルチスレッド化を検討している。 uWSGI uWSGIでマルチスレッドを有効にした時は、各workerスレッドがacceptする形で動作する。スレッド数以上の接続をacceptすることがないので安心。 プロセス内のスレッド間ではmutexで排他されて、同時にacceptを実行するのは1スレッドのみに制限されている。つまりthendering herd問題はプロセス間でしか起こらない。マルチスレッド化でプロセス数はむしろCPUコア数まで減らせるので、thendering herd問題はむしろ今よりも軽減できる。（ちなみにプロセス間でもロックしてthendering herdを許さないオプションもあるけど、プロセス間同期は怖いので使っていなかった。） ただしuWSGIのマ
PSGI - Perl WSGI
bulknews.typepad.com Tatsuhiko Miyagawa's blog to discuss mostly tech and nerdy stuff. Info: if you come from Google and want to know what PSGI and Plack are: take a look at our PSGI/Plack project web page that has links to PSGI spec and FAQ, and then Plack git repo for the actual code. HTTP::Engine is the best thing that happened in the Perl web application development land lately. It's a port of
ISUCON の季節ですね。 ISUCON では慣習的に各言語で代表的なマイクロフレームワークが使われるのですが、 Python では今のところ Flask がずっと使われています。 Flask は確かに、簡単なサンプルアプリを書くときの見た目はマイクロフレームワークになっています。 しかし、構造的には沢山のフック、シグナルがあったりしていて、重量級の設計になっています。 Flask 本体と Werkzeug を合わせると数万行のサイズです。単なる Hello World アプリでも、数十の関数呼び出しが裏で動いています。 Bottle も、 Flask と同じくマルチスレッド対応で、スレッドローカルを使ったコンテキストスタックがある、拡張機能もあるフレームワークですが、構造は Flask よりも大分質素です。 ソースコードも1ファイル3000行代で、その分フレームワークのオーバーヘッドも
はじめに こんにちは、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がどう「フレームワーク分解機」になり得るかということに対して、私はいまよりもずっと理想主義的な展望を期待していました。すべてがプラガブルで、モノリシックなアプリケーションフレームワークを持つ理由がもはや一つもないような未来を思い描いていました。すべてライブラリ、ミドルウェア、デコ
Django・WSGIミドルウェア入門/django-congress-jp-2018-talk
Django Congress JP 2018の発表資料です
Web Server Gateway Interface(WSGI,Rack,PSGI) - よねのはてな
Java屋さんが、他言語でのWebアプリケーション開発する際に押さえておくと良い仕様をメモ。 多くのWebアプリケーションフレームワークが存在して、使用可能なWebサーバを制限したりその逆があるのは よろしくないのでWebサーバとフレームワーク間で統一されたインターフェース仕様が必要となります。 まさに Web Server Gateway Interface です。 Python WSGI WSGI（Web Server Gateway Interface）は、Python向けの統一されたインターフェース仕様 WSGI supported web frameworks Django, Pylons, TurboGears, CherryPy, web.py, web2.py, Zope3, ... see http://www.python.org/dev/peps/pep-0333/
この記事は CAMPHOR- Advent Calendar 2016 の1日目の記事です. Python の WSGI ミドルウェアとして使えるラインプロファイラ wsgi_lineprof を作成しました. wsgi_lineprof は Django や Pyramid, Flask, Bottle などの WSGI 互換のアプリケーションやフレームワークと組み合わせて利用できるようになっています. 背景 Web アプリケーションを作成する際に, ボトルネックとなっている部分を発見するために, ラインプロファイラは有用です. Ruby での WSGI に対応する Rack には rack-lineprof というライブラリがあり, Rack の middleware として簡単にラインプロファイラを利用できます. ISUCON の参加記事等を見ていると, Ruby ユーザーはこのライ
YappoLogs: HTTP::Engine - Perl版 WSGI のような物、 Catalyst::Engine を抜き出したような物
HTTP::Engine - Perl版 WSGI のような物、 Catalyst::Engine を抜き出したような物 先週のCatalystConでHTTP::Server::Wrapperというのを発表したのですが、やっぱり名前長いしわかりにくいよねということで、HTTP::Engineという名前でやり直して CPAN に上げました。 http://search.cpan.org/dist/HTTP-Engine/ 実は Catalyst の svn repos に HTTP-Engine のディレクトリ掘ってある事は知っていたんだけども、4ヶ月くらい前に作ってからそれっきりっぽいので、DISられ覚悟でうpたわけです。 簡単に説明すると、mod_perlやfastcgiやHTTP::Server::SimpleやPOEやCGIなど様々なWebエンジンを透過的に扱って簡単にフレームワー
mod_wsgi には embeded mode (Apache のプロセスと一心同体) とdaemon mode があるのですが、小さなWSGIスクリプト以外では daemon mode を使った方が応用が利きます。 そこで、mod_wsgi の daemon mode について調べてみました。 まず、 mod_wsgi の daemon mode (以降、WSGIDaemonProcess で表します) を図で表すと次のようになります(たぶん)。WSGIDaemonProcess と Apache は Proxy でゆるくつながっていて、設定ファイルでの WSGIDaemonProcess 宣言1つにつき複数の DaemonProcess が存在し、それぞれにまた複数のスレッドがぶら下がっています。 以下、 WSGIDaemonProcess の特徴です。 Apache のプロセスとは
#pyconjp でWeb(WSGI)フレームワークの作り方について話してきました - c-bata web
昨年のPyConJPでは pandas-validator について話していたのですが、今回はトークセッションをしてきました。 Twitter見てると早速スライドを見ながら実装してくださってる方もいらっしゃって嬉しいかぎりです。 日本語のWSGIフレームワークの作り方の資料としては最もまとまっているものになっていると思うので、ぜひご活用ください。 基礎から学ぶWebアプリケーションフレームワークの作り方 WSGIの解説から始まり、ルーティング・リクエスト・レスポンス・HTMLテンプレートやミドルウェアについて順番に解説しながら、ボトムアップでフレームワークを作り上げていく話をしてきました。 半分ライブコーディングみたいな形だったので、少し不安もありました。 もう少しこうやればスムーズだったかなと反省点も少しありますが、スライドとかTogetterまとめがホッテントリ入りしていたらしく、周り
あらかじめ必要なもの aptitude install python-setuptools # for ubunutu easy_install werkzeug 注釈 環境によってはsudoなどを用いて管理者権限に昇格する必要があります。 Windows版でのsetuptoolsのインストールについては http://python.matrix.jp/modules/setuptools.html などを参照してください。 WSGIってなんじゃらほい（おさらい） WSGIはPython文化から生まれのHTTPサーバーインターフェース規格。 基本のサーバーを実現するのに一個の関数を決められた形で記述するだけという 超シンプルで素敵な規格なのです。 この規格を「WSGIアプリ規格」と呼びましょうか。 「WSGIアプリ規格」の最小のサンプルを以下に示します。 def application(e
PythonとWSGIによるフォトギャラリーの作成：CodeZine
PythonにおけるWebフレームワーク 数年前にPythonでWebアプリケーションを書こうとした人たちは、選択肢の多さに戸惑ったことでしょう。一群のWebフレームワークの中からどれかを選び、アプリケーションをプロダクション環境にデプロイする妥当な方法を考えなければならなかったはずです。そういうわけで、Pythonは千個のフレームワークを持つ言語だというジョークが流布することになったのです。 Pythonコミュニティには、この問題の解決策として、フレームワークの数を絞るか、それとも多様性を良しとするかという選択がありました。コミュニティの性格上、フレームワークを絞り込むのは魅力的なオプションに見えなかったので、Webの開発にPythonを使用するための障壁を低くする方法としてPEP 333が書かれ、Web Server Gateway Interface（WSGI）が生まれました。WSG
＿＿＿_ ／ ＼ ／＼ ｷﾘｯ . ／ （ー） （ー）＼ ／ ⌒（__人__）⌒ ＼ ＜Webアプリケーションフレームワーク(以下 WAF)を公開したお。 | |r┬-| | これでやる夫もギークの仲間入りだお。 ＼ `ー'´ ／ ノ ＼ ／´ ヽ | ｌ ＼ ヽ -一''''''"〜〜｀`'ー--､ -一'''''''ー-､. ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒)) ＿＿＿_ ／:::::::::: u＼ ／:::::::::⌒ 三. ⌒＼ ／:::::::::: （ ○）三（○）＼ |::::::::::::::::⌒（__人__）⌒ | ＿＿＿＿＿＿＿_ ＼:::::::::: ｀ ⌒´
Pythonにはフレームワークが数多く存在する。それぞれ得手不得手があるので、自分の得意とするものを選択すれば良いのだろうが、それによってWebサーバの選択肢が狭まってしまうと厄介だ。それを克服するために生まれたのがWSGIであり、共通インタフェースだ。 動作している様子 WSGIの登場によって、WebアプリケーションとWebサーバの祖結合が可能になった。必要に応じてWebアプリケーションを組み合わせられれば、資産の有効利用にもつながるだろう。 今回紹介するオープンソース・ソフトウェアはWsgiDAV、WSGIで実装されたWebDAVサーバだ。 WsgiDAVはPyFileServerをベースとして開発されている。PyFileServerが2005年08月で開発が停止しているようであり（branchレベルでは2009年05月にも更新されているが）、それをリファクタリングして開発されているの
2019-05-16 メールサーバー構築 2018-11-01 Unix-テキスト処理(1) 2018-10-01 android-kotlin-dataBinding 2018-09-27 android-kotlin-ModelView 2018-09-12 Kotlin android-kotlin-WorkManager 2018-09-11 android-kotlin-Room 2018-09-10 Kotlin-Coroutines 2018-09-04 letsencrypt 2018-09-03 Kotlinの基本 Kotlin-関数オブジェクト 2018-08-31 android-kotlin-SQLiteOpenHelper Kotlin-SpringBoot android-kotlin-SharedPreferences 2018-08-28 kotlin-例外
はじめに 前回までで、WSGIアプリケーションの仕様、アプリケーションの作成、ミドルウェアの利用などの、WSGIの基本的な部分の説明が終わりました。 今回は、作成したWSGIアプリケーションを実行するプラットフォームとして、Google App Engine（GAE) を取り上げます。 Google App Engineとは Google App Engineとは、Googleが提供しているWebアプリケーションのプラットフォームです。基本的に無料でGoogleのスケーラブルなWebアプリケーションインフラで、自作のWebアプリケーションを動作させることができます。アプリケーションはアカウントごとに10個まで利用できます。アプリケーションごとに利用可能なストレージ容量、 CPU 処理時間、データ転送量などのサーバリソースの制限はありますが、月500万ページビュー規模までは利用できる程度の制
"mod_python 終了のお知らせ" を受け、もともとリソース不足だった既存の Django アプリケーション郡のサーバをリプレイスすることにしました。リプレイス要件↓ パフォーマンスが高いのにしたい アプリケーションの変更は必要最小限にしたい URL 類は既存のアプリケーションを引継ぐ: 複数プロジェクトをサブディレクトリーで運用していて、 "django.root" で複数プロジェクトを切り分けている 環境設定について これは apache - mod_wsgi が簡単すぎます。 nginx - fastcgi nginx - fastcgi 構成の場合は、init.d への登録、 daemontools を利用 (弊社は mod_python 以外はこれ)。 nginx の設定 /etc/nginx/fastcgi_params fastcgi_read_timeout 180;
はいこんばんは。 生きてます生きてます。 ここ一週間、またPythonごりごりやってます。 今度は小さーいシステムなんでFlask (Python製マイクロフレームワーク)でさくっと作ってます。 Flaskはマイクロと名前がついているだけあって、インストールは楽だしアプリ作成手順もシンプルだし…で、触ってて楽しいですね(・∀・)。 今回、Flaskをサーバーにインストールして動かしたのでそのメモ。 環境: サーバー： EC2, Apache + mod_wsgi Pythonバージョン: Python2.6.6 (EC2デフォルトのバージョン) あ、ついでなので、PythonでできたWebアプリケーションを扱う時に言われる 「ファイル更新したらApacheリロードしなきゃいかんのめんどくさー！」 って誤解も解いておきますね。 2012.5.20 追記 —- httpd.confに「WSGI
Ubuntu Linux 10.10出ましたね！ 丁度Flask使っててデプロイの練習をしてみたかったので、環境を作ってみました。 参考 Ubuntu/apache2 - TOBY SOFT wiki mod_wsgi (Apache) — Flask 0.9dev documentation 文系にも出来るDjango(mod_wsgi)@ubuntu8.10のデプロイ方法 - When it’s ready. (a2c.get.diary) →Apache2+mod_wsgi環境作成の参考にさせていただきました Google App Engine 一人勉強会 第一回 とりあえず動かしてみる - Twisted Mind →動作テストアプリの参考にさせていただきました。 環境 VirtualBox 3.2.8 ubuntu10.10 64bit python2.6.6(標準） aptで導
NGINX Unitが公開されて、Python用のWSGIを動かすアプリケーションサーバーとして使っていけるかなぁという感じです。とりあえずHello Worldを動かしてみました。 ためした環境 vagrant ubuntu/xenial64 python3.5 NGINX Unitのインストール こちらを参考にubuntuパッケージ版をインストール。 https://github.com/nginx/unit#ubuntu-packages そして起動 $ sudo service unitd start pythonアプリケーションの作成 pythonアプリケーションはwsgiで作成する。指定したパスにwsgi.pyというファイルを配置して、あとはwsgiの流儀に従うだけ。wsgiで作ればいいのでフレームワークなんかは自由。 def application(environ, star
はじめに 第1回では「Hello, world.」を出力する簡単なアプリケーションを作成し、WSGIの仕様について説明しました。 しかし、「Hello, world.」のような簡単なアプリケーションからは、実際に作成するアプリケーションの雰囲気のを掴むのは難しいと思いますので、第2回では、もう少し実用的なアプリケーションを例にして、解説をしたいと思います。 MessageBoardアプリケーション 今回作成するアプリケーションは、MessageBoardアプリケーションです。フォームからタイトル、名前、本文を入力して投稿すると、それまでに投稿されたメッセージが一覧される掲示板のようなアプリケーションです。 アプリケーションのソースコードはこちらにZIP圧縮版があります。まずは、ダウンロードして以下のように実行してみてください。 ■注意 サンプルソースmessage.pyで、マルチバイト文
Circus is now able to bind and manage sockets, and in cunjunction with Chaussette you can run a full web stack behind your favorite Web Server (Nginx, Apache etc.) -- read more about Circus stacks here. In other words, Circus can spawn as many Chaussette processes as you want, each one will act as a web worker: they'll all accept requests on the same socket. Why would you want to do this? Because
Almost a decade ago, back when I first proposed the idea of WSGI to the Web-SIG, I had a rather idealistic vision of how WSGI could be a kind of “framework dissolver”. I envisioned a future in which everything was pluggable, and there would no longer be any reason to have monolithic application frameworks, because everything could be done with libraries, middleware, and decorators. Alas, that ide
複数の VPS で Python を使えるようにする簡単なお仕事。 りょうのすけにとっては簡単じゃないし、同じ作業の繰り返しは苦痛。 なので、あっさりさっくり終わらせられるように手順を書いておこう。 最後はどうなる？ この手順で進めていくと以下のような環境になります。 サーバーOS CentOS 5.5 32bit （この VPS は CentOS 5 32bit しか使えない） Python 2.6 mod_wsgi 3.3 Django 1.3 CentOS 5.6へのバージョンアップ 以下コマンドで現在のバージョンを確認 # rpm -qa | grep centos-release centos-release-notes-5.5-0 centos-release-5-5.el5.centos # yum upgrade Loaded plugins: fastestmirror
![[Python] 10分でCentOS+mod_wsgi+Django](https://cdn-ak-scissors.b.st-hatena.com/image/square/3f78246c64d29ed8e5465f6b25d9610add1056bb/height=288;version=1;width=512/http%3A%2F%2Fwww.rnsk.net%2Fblog%2Fwp-content%2Fuploads%2Fdjango01.png)
JavaScript V8 Seeker Server and WSGI This is nodeJuice. It is a tool which allows you to develop with a push connection to your web browser. Automatic browser refresh on file change or update is what you can call it. Develop on one to many browsers simultaneously without needing to reload manually. NodeJuice Video on Vimeo Watch the video to see what NodeJuice can do. 2010.04.23 - Updated to Node
dmsolutions blog » WSGI ことはじめ
WSGI (Web Server Gateway Interface) は Django や Google App Engine を始めたくさんの Python Web フレームワークが準拠している仕様で、これについての秀逸なチュートリアルの翻訳。日本語訳が秀逸かどうかは知らないので、怪しい部分は原文にあたって教えてください。 WSGI ことはじめ ==================== 著者(Author): Armin Ronacher 原文(Original Text): http://lucumr.pocoo.org/articles/getting-started-with-wsgi 翻訳(Japanese Translation): hkurosawa ライセンス(Lisence): http://creativecommons.org/licenses/by-nc
はじめに 前回は、 WSGIアプリケーションを動作させるためのプラットフォームとして、Google App Engine（GAE）を紹介しました。今回は、Webアプリケーションを作る上で役に立つ、WSGIが利用可能なWebアプリケーションフレームワークを紹介します。 Webアプリケーションフレームワークとは アプリケーションフレームワークとは、簡単に言ってしまえば便利なライブラリの集まりです。ライブラリと違うのは、単に機能を提供するだけでなく、アプリケーションの組み立て方、ファイルの配置など、ライブラリとしての機能以上の概念を伴うことです。これは、アプリケーションの組み立て方を明確にすることでアプリケーションの作成を簡単にする、プログラマが道に迷わないようにする、という意味があります。 ひと口にWebアプリケーションフレームワークと言っても、Pythonに限定してもTurboGears、P
WSGIことはじめ
WSGI (Web Server Gateway Interface) は Django や Google App Engine を始めたくさんの Python Web フレームワークが準拠している仕様で、これについての秀逸なチュートリアルの翻訳。日本語訳が秀逸かどうかは知らないので、怪しい部分は原文にあたって教えてください。 WSGI ことはじめ ==================== 著者(Author): Armin Ronacher 原文(Original Text): http://lucumr.pocoo.org/articles/getting-started-with-wsgi 翻訳(Japanese Translation): hkurosawa ライセンス(Lisence): http://creativecommons.org/licenses/by-nc-sa/2
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.
Pythonで、URLルーティング機能だけがあるWSGIフレームワークを自作してみた - メモ的な思考的な
以前、 WSGI準拠のWebサーバ WSGIアプリケーション を自作しました。 これらの自作により、「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」の第3章以降もPythonで書く見通しが立ちました。 gihyo.jp 第3章以降では、URLルーティングやクッキー・セッションなどの機能が登場します。 ただ、それらの機能を WSGIアプリケーションを1つ作り、すべてを入れる WSGIフレームワークとWSGIアプリケーションの2つを作り、機能を分担する のどちらの形で実装するか悩みました。 それでも、せっかくなので、後者のWSGIフレームワークを自作してみようと考えました。 そこで今回、URLルーティング機能だけがあるWSGIフレームワークを自作してみました。 なお、学習用途で作ったため、セキュリティ面は考えていませんのであしからず。 目次 環境 復習：単純なWSGI
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pythonで約100行のシンプルなWSGIサーバーを書いてみる
第1回 WSGIの概要 | gihyo.jp
WSGIとPythonでスマートなWebアプリケーション開発を 記事一覧 | gihyo.jp
TokuLog 改め最適なフレームワークで快適なくらしを創造する会 - あっというまにゼロからWSGI
Gunicorn - Python WSGI HTTP Server for UNIX
mod_wsgiでDjangoを動かすまでを淡々と記録する - スコトプリゴニエフスク通信
次世代の Rack や WSGI を考えてみる - Qiita
PHPをApacheから切り離す。WSGI対応のPHP製アプリケーションサーバ·AppServer MOONGIFT
PythonのマルチスレッドWSGIサーバーの選定 - methaneのブログ
wsgi, Bottle, Flask の速度差 - Qiita
（翻訳） WSGIは死んだ: WSGI Liteバンザイ！ - YAMAGUCHI::weblog
WSGI ミドルウェアとして使えるラインプロファイラを作った話 - ymyzk’s blog
mod_wsgi: WSGIDaemonProcess - Pyxis 開発ブログ
「werkzeug」でWSGIアプリをつくろう！ — PythonMatrixJp
やる夫で学ぶ WSGI - present
WSGIを使って実装されたWebDAVサーバ·WsgiDAV MOONGIFT
python-ブラウザ利用(apache mod_wsgi) - toridgeWiki
第4回 Google App EngineでWSGIを使う | gihyo.jp
fastcgi-nginx vs mod_wsgi-apache
Apache+mod_wsgi+Flaskインストール
Flaskをapache+mod_wsgiで動かす - Keep on moving
NGINX Unitでpython wsgiサーバーを動かす - Qiita
第2回 WSGIを使ったもう少し複雑なアプリケーションの作成 | gihyo.jp
WSGI Web Servers Bench
WSGI Is Dead: Long Live WSGI Lite! - dirtSimple.org
[Python] 10分でCentOS+mod_wsgi+Django
nodeJuice - JavaScript V8 Seeker Server WSGI
第5回 WSGIで利用可能なWebアプリケーションフレームワーク | gihyo.jp