タグ

ProgrammingとPSGIに関するbeth321のブックマーク (5)

  • 第1回 PSGI/Plack―フレームワークとサーバをつなぐエンジン (2) | gihyo.jp

    Plack─⁠─PSGIユーティリティ PSGIのおかげで、フレームワークはCGIやFastCGI、mod_perlといった環境の差異を吸収するためのコードを書く必要はなくなり、PSGIのインタフェースだけを実行すればよくなりました。実際に多くのフレームワークがすでにPSGIをサポートしていますが、さて、そうしたアプリケーションをどうやって動かせばよいのでしょうか。 Apacheなど既存のWebサーバでPSGIアプリケーションを動かすには、CGI、FastCGI、mod_perlなどのインタフェースをPSGIに変換する必要があります。また、PSGIをネイティブで実行できるPerlベースのHTTPサーバもほしいところです。 Plackはそうした要件を満たすためのユーティリティで、リファレンス実装としてのPSGIサーバやそれらへのアダプタ、周辺ライブラリや後述するミドルウェアが含まれています。

    第1回 PSGI/Plack―フレームワークとサーバをつなぐエンジン (2) | gihyo.jp
  • PSGI/Plack - [Perl Hackers Hub]

    連載では、第一線のPerlハッカーが回替わりで執筆していきます。記念すべき第1回は、WEB+DB PRESS誌ではVol.2から執筆しており、長らく連載も担当していた宮川達彦さんです。 はじめに PerlでWeb開発をするためのフレームワークは百花繚乱、人気を集めています。稿では、これらのフレームワークが共通して利用するためのインタフェース仕様であるPSGIと、そのエンジンとしての実装であるPlackを紹介します。 PSGIに至る道 PerlとWebアプリケーション開発の親和性 Perlは「インターネットのグルー(糊:のり)言語」とも言われ、CGIによる開発がメインだった1990年代から、Webアプリケーション開発に最も関わりのあるプログラミング言語の一つと言ってよいでしょう。2000年代に入っても、Ruby on RailsPHPなどの他言語からの影響も取り入れながら、Web開発

    PSGI/Plack - [Perl Hackers Hub]
  • 第23回 Rackとは何か(1)Rackの生まれた背景 | gihyo.jp

    はじめに SinatraやRamazeといったRubyのWebアプケーションフレームワークに興味をお持ちの方であれば、Rackという名前をしばしば目にしているかもしれません。どうやら様々なフレームワークに使われているらしいのだけど、そいつが一体なんなのかよくわからない、そんなあなたのために今日はそのRackをご紹介したいと思います。 様々なフレームワーク、様々なアプリケーションサーバ しばらく前なら、Ruby on Railsブームの真っ只中、Rubyと言えばRails、Webアプリケーションを作るならRails、といったイメージを持たれていた方も多かったと思います。実際にWebアプリケーションを作ったり、Rubyに触れたりしたきっかけがRailsだったという方も多いでしょう。 しかし最近は、RubyのWebアプケーションフレームワークと一口に言っても、非常に簡単にアプリケーションが書けて

    第23回 Rackとは何か(1)Rackの生まれた背景 | gihyo.jp
  • Perl Hackers Hub:連載|gihyo.jp … 技術評論社

    最終回 Carmelによる依存モジュール管理 CPANモジュールの更新を高速⁠⁠、安全に(2) 宮川達彦[著],牧大輔,福貴之,松木雅幸,大沢和宏[監修] 2023-10-17 最終回 Carmelによる依存モジュール管理 CPANモジュールの更新を高速⁠⁠、安全に(1) 宮川達彦[著],牧大輔,福貴之,松木雅幸,大沢和宏[監修] 2023-10-16 第79回最近Perlに追加された実験的機能 try文⁠⁠、defer文⁠⁠、class文(2) 石垣憲一[著],牧大輔,福貴之,松木雅幸,大沢和宏[監修] 2023-08-18

    Perl Hackers Hub:連載|gihyo.jp … 技術評論社
  • Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>

    すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの?」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること! まずこのお話の前提:mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基的な構造は何も変えてない(←ここポイント)。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう? まずアプリケーションを組む側が「やっちまったなぁ?」な件:P

    Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>
  • 1