Plack──PSGIユーティリティ PSGIのおかげで、フレームワークはCGIやFastCGI、mod_perlといった環境の差異を吸収するためのコードを書く必要はなくなり、PSGIのインタフェースだけを実行すればよくなりました。実際に多くのフレームワークがすでにPSGIをサポートしていますが、さて、そうしたアプリケーションをどうやって動かせばよいのでしょうか。 Apacheなど既存のWebサーバでPSGIアプリケーションを動かすには、CGI、FastCGI、mod_perlなどのインタフェースをPSGIに変換する必要があります。また、PSGIをネイティブで実行できるPerlベースのHTTPサーバもほしいところです。 Plackはそうした要件を満たすためのユーティリティで、リファレンス実装としてのPSGIサーバやそれらへのアダプタ、周辺ライブラリや後述するミドルウェアが含まれています。
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回は普段Webアプリケーションの開発を行っているtokuhiromさんで、テーマはWebアプリケーションフレームワークAmon2です。 Amon2とは？ こんにちは。tokuhiromです。本稿では、筆者が中心となって開発を進めているAmon2というWebアプリケーションフレームワークについて説明します。 Amon2は、次のような特徴を持つWebアプリケーションフレームワークです。 PSGI/Plackベース Amon2はHTTP::Engine/PSGI/Plackの開発／制定に初期のころから関わっている筆者が作成したWebアプリケーションフレームワークです。そのため、Plackの部品をできる限り利用することにより、少ないコードベースでWebアプリケーションフレームワークを実現しています。これにより学習コストが低くなってい
本連載では、第一線のPerlハッカーが回替わりで執筆していきます。記念すべき第1回は、WEB+DB PRESS本誌ではVol.2から執筆しており、長らく連載も担当していた宮川達彦さんです。 はじめに PerlでWeb開発をするためのフレームワークは百花繚乱、人気を集めています。本稿では、これらのフレームワークが共通して利用するためのインタフェース仕様であるPSGIと、そのエンジンとしての実装であるPlackを紹介します。 PSGIに至る道 PerlとWebアプリケーション開発の親和性 Perlは「インターネットのグルー（糊：のり）言語」とも言われ、CGIによる開発がメインだった1990年代から、Webアプリケーション開発に最も関わりのあるプログラミング言語の一つと言ってよいでしょう。2000年代に入っても、Ruby on RailsやPHPなどの他言語からの影響も取り入れながら、Web開発
すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの？」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること！ まずこのお話の前提：mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基本的な構造は何も変えてない（←ここポイント）。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう？ まずアプリケーションを組む側が「やっちまったなぁ？」な件：P
あるプログラミング言語で実際にWebAppを開発できるようになるまで、何が必要だろうか。言語仕様の習得は終えているとしよう。おそらく、最低限以下のような知識が必要だと思われる。とりあえずPerlについて知っていることを書いた。 パッケージマネージャ まずライブラリの管理。モジュールをインストールし、可能であればバージョンを固定し、適切にロードする機能が必要だ。Perlの場合は cpanm というCPANクライアントでライブラリをインストールする。バージョンの固定とライブラリパスの設定は carton で行う。 https://github.com/miyagawa/cpanminus https://github.com/miyagawa/carton アプリケーションサーバ Webサーバへのインターフェイスとしては、PSGIという仕様がある。PSGIに準拠したツールキットとしてPlack
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
こんにちわ。昨今、ウェブ開発の進化はすざましいですね。PythonやPerlやJava、色んな言語で書かれていると思います。 もちろん編集にはVimを使っているかと思います。 でも編集だけ？ 違うよね！ Vim scriptはウェブアプリケーション記述言語なんだよ！ Plack::App::Vim package Plack::App::Vim; use strict; use warnings; use parent qw/Plack::Component/; use Plack::Request; use Encode; use JSON::PP; sub prepare_app { my $self = shift; $self->{vim} ||= 'vim'; if (!$self->{server}) { open(my $f, "vim --serverlist|"); my
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
