Rackについて調べても、「ではまず簡単なRackアプリケーションを作ってみましょう。config.ruを開いて……」みたいな資料しか出てこなくて、サーバー側からみたRackインターフェースがどうなってるかという記事が全然見当たらなかった。んだけど、何やら外国の人のブログでちょうど望んでる内容のものがあったのでざっくり翻訳と紹介します(許可とった)。言い回しとかで解釈わかんないところがあって飛ばしたりしているので本文とニュアンスだいぶ変わってしまっているかもなのですが、まあ最低限の内容が伝われば……ご了承ください。 元記事:http://www.blrice.net/blog/2015/05/31/make-your-own-rack-server/ 自分のRackサーバーを作ってみよう Ruby触ってたら必然Rackについて学ぶよね。RailsとかSinatraとかRubyのWAFの心臓
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
Rack::Multiplexerという、複数のRackを束ねるものをつくった。 Plack寄せ この前Perl界隈の人達と鍋を囲む機会があって、 !!1;の話、livedoor BlogのPlack化の話、ISUCONの話、 各社古いアプリ抱えていて辛いね苦しいね頑張ろうね若者に1日で書き換えさせようといった話をして、 結局、何となくこの界隈は全体的に「Plack寄せ」が進んでいるねという話に落ち着いた。 Rack寄せ 一方Ruby界隈だと比較的皆Rackに寄っている傾向にはあると思うけど、 もっと寄せてみると面白いんじゃないかと思って、Rack::Multiplexerをつくった。既にありそう。 Rack::Multiplexerは、所謂WebアプリのRouter(=Dispatcher)の処理を行うための実装で、 メソッドやパスの規則に従って受け取ったリクエストを別のRack app
何番煎じ変わりませんが、WSGI/Rack/PSGIに関して、何でこれらが必要とされるようになったのか、歴史的経緯を踏まえて色々調べたので、記録しておきます。ただし、特に歴史的な話に関しては、ネットで自分が納得できるまで探りはしましたが、正確性を欠くかもしれません*1。間違っていたらご指摘下さい。 実行環境の多様化とWAFの乱立 結論としては、この見出しがWSGI/Rack/PSGIが生まれることとなった動機といえます。 実行環境の多様化 私が小学生ぐらいの頃、20世紀終盤でしょうか、通信速度も今に比べ格段に遅く、多分スケーラビリティなんて考えも浸透していなかった頃、WebアプリといえばCGIでPerlな時代がありました*2。そんな頃の実行環境はレガシーなApacheとmod_cgiでした。 しかし、時代と共に、数多くのリクエストを捌くことが要求されるようになると、CGIでリクエスト時に毎
開発環境と本番環境で favicon を変える というのに感動したのでRack middlewareでやってみました。というか、昨日のPlack::Middleware::DevFaviconをRackに移植しただけですけど。 Plack版とおなじく単に favicon.ico ないし favicon.png という名前にマッチしたらグレースケールにして返すというだけの代物ですが、Rack middlwareなので簡単に導入できるのが楽かなと。 使い方は以下のとおり。faviconを配信するミドルウェアよりも先にuseしてください。 if ENV['RACK_ENV'] != 'production' require 'rack-devfavicon' use Rack::DevFavicon end map "/favicon.ico" do run Rack::File.new("#{
WebアプリケーションのインタフェースxSGI(WSGI, Rack, JSGI, PSGI)のメモ。 Webアプリケーションのインタフェースといっても、いろいろな切り口があるとは思いますが、アプリケーションとサーバー(実行環境)間のインタフェース。PythonのWSGIと、その仲間(Ruby版, Javascript版, Perl版)のこと。シンプルなCGI/Fast CGI/SCGIとも異なるし、古風なxSP系(PHP/ASP/JSP)とも違う感じ。（ここのインタフェースは、それにあわせることで、Webアプリケーションを作る人はいろんなところで動かせる、Webアプリケーション実行環境を作る人はいろいろな人に使ってもらえる、と言うことになります。例えば、WSGIのpythonアプリは、自前のApacheでもクラウドのGoogle App Engineでも、動かせる、みたいな。さらに、中間
本記事は英語版ブログで2010年5月18日に公開された記事の翻訳版です。 Engine Yard のお客様や開発者の友人の多くが Unicorn を愛用し、推奨しているので、これについて兼ねてから勉強したいと思ってました。そんな矢先に、幸いにもその学習機会が自然と訪れました。最初は無料のリソースをいろいろと見ながら疑問を解決しようとしましたが、思ったより難しく、結局は大元のソースに当たることにしました。 まず、十分な時間をかけて Unicorn の README ファイルを熟読しました。このファイルには総合情報が網羅されていますが、読み終えた後でも疑問が解決しなかったので、すべてまとめて Unicorn の開発チームに E メールで送ってみました。有難いことに、返信には私の全質問に対する答えが詳しく書かれていました。そのおかげで内情に通じることができたので、この素晴らしいリソースを皆さんと
先日ご案内していた通り2017年5月31日を持ちまして、サービスを終了いたします。 長らくご愛顧賜りまして、誠にありがとうございました。 サービス終了に伴いまして、ユーザー様からお預かりしていた個人情報やプログラム、各種データなどは、 当社が責任を持って削除いたします。 当社では様々なインターネットサービスを提供しておりますので、 機会がございましたら、 ご利用いただけますと幸いです。 Sqaleに関するお問い合わせは、こちらのお問い合わせフォームからお願いいたします。 平素はSqale（スケール）をご利用頂き、誠にありがとうございます。 2012年8月より運営してまいりました「Sqale」でございますが、2017年5月末日を持ってサービスを終了することとなりました。 ご利用中のユーザー様にはご迷惑をおかけし、誠に申し訳ございません。 現在ご利用中のプログラムやデータベースのデータにつきま
(追記：2012-12-25) 本記事およびこれに続くRackの記事（全４本）をまとめて電子書籍化しました。「Gumroad」を通して100円にて販売しています。内容についての追加・変更はありませんが、誤記の修正およびメディア向けの調整を行っています。 電子書籍「エラーメッセージから学ぶRack」EPUB版 このリンクはGumroadにおける商品購入リンクになっています。クリックすると、オーバーレイ・ウインドウが立ち上がって、この場でクレジットカード決済による購入が可能です。購入にはクレジット情報およびメールアドレスの入力が必要になります。購入すると、入力したメールアドレスにコンテンツのDLリンクが送られてきます。 詳細は以下を参照して下さい。 電子書籍「エラーメッセージから学ぶRack」EPUB版をGumroadから出版しました！ 購入ご検討のほどよろしくお願いしますm(__)m Rac
Rackとは、Rubyで実装したアプリケーションとウェブサーバとを繋ぐインターフェースです。Rackプロトコルに従って実装したアプリケーションは、利用するウェブサーバを自由に選択する事が可能となります。 Rackの開発元へは、以下のリンクから。 Rack: a Ruby Webserver Interface Rackプロトコルについて、簡単に説明します。 Rackプロトコルに従ったアプリケーションとは、環境変数envを引数にとるメソッドcallを持つRubyオブジェクト(インスタンス)を意味します。callは、3つの要素を持つArrayオブジェクトを返します。これは順に、『HTTPステータスコード』『HTTPレスポンスヘッダ』『HTTPボディ』となります。 環境変数 アプリケーションは、環境変数を読み書きする事で、入出力操作等を行える様になります。環境変数は、いわゆるCGI環境変数や、R
知っている人には常識な話ですが、Railsでのリクエストパラメータの扱いについて。 Railsでは、ルーティング情報とクエリパラメータをハッシュマップ（パラメータ情報というらしい）に格納して、コントローラへ渡します。コントローラからは、params という変数でこのマップにアクセスします。 たとえば、"key"というリクエストパラメータを取得するには、 params[:key] と書きます。 ※このとき、:key がルーティング定義(config/routes.rb)で使われていてはいけない。 ハッシュマップなので、ひとつのクエリパラメータ名に複数の値を対応させようとして、 http://foo.com/controller/action?key=val1&key=val2 とすると後の値（この場合 "val2" で params[:key] が上書きされてしまいます。 （仕組みを知らない
今日の悩みの種。なんとなく解決したけど、、、 Sinatraで同名の複数パラメータってどうやってとるんだろ。どっちかというとrackの話になってくるっぽいのだけど、 いくつか試したのにうまくいかない。。。 お試しコード。/sample?aaa=bbb&aa=bb&aaa=ccc みたいな感じでテスト get '/sample' do erb :sample, :layout => false end <hr> パターン１<br> <% message = "" params.keys.each do |k| message += "[#{k}][#{params[k].class}]<br>" end %> <%= message %><br> <hr> パターン２<br> <%= @env["rack.request.query_string"] %><br> <% message =
Rack ってなに？ Rack は Web サーバと Ruby プログラムや Ruby で書かれた Web アプリケーションフレームワークとの間に、最小限のインターフェースを提供します。 http://rack.rubyforge.org/ Rack のインストール gem install rack Rack の簡単な始め方 Rack を使うには、まず call されるアプリケーションを書きます。call メソッドを定義し、引数に env を取ります。 # app.rb require 'rack' class TinyCaller def call(env) [200, {'Content-Type' => 'text/html'}, ["Hello, World."]] end end 続いて、Rack を使うための DSL ファイルとなる .ru ファイルを作成します。 # tiny
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/
■ [ruby][rack] 5分でわかるRack RackはRubyのためのWebサーバインターフェイスだ。 RubyでWebっていうとRailsが有名だけど、実はRails以外にもいろんなRuby用のWebアプリ用フレームワークが存在する。 Ramaze Merb Camping Waves などなど…。 一方Webを実際に動かすにはWebサーバが必要だ。RubyのためのWebサーバも、これまたいろんなものがある。 Apache(CGI, FastCGI..) WEBrick Mongrel Ebb Thin などなど…。 ここで問題が一つ。それは「フレームワークが増えるたびに、いろんなサーバをサポートするためのコードが必要になる」ってとこだ。 各フレームワークの作者がみんなそれぞれにCGIやMongrelに対応するためのコードを書いてるなんて、無駄だと思わないか？ RackはWebア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く