最近の Rack サーバ事情について - おもしろwebサービス開発日記
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
第25回 Rackとは何か（3）ミドルウェアのすすめ | gihyo.jp
前回、前々回の記事では、Rackの生まれた背景、Rackとは何か、実際にRackアプリケーションを作る際に使えるものをご紹介しましたが、もう一つまだ説明していない重要な要素がRackにはあります。今回は、そのミドルウェアという仕組みについてご紹介します。 ミドルウェアとは ミドルウェアとは何かを一言で言うと、「別なアプリケーションをラップして、リクエストやレスポンスを加工したり、処理を切り換えたりするRackアプリケーション」です。 この仕組みがあることで一体何ができるのでしょうか。Webアプリケーションを作っていると、リクエストやレスポンスをアプリケーションに行く前やアプリケーションの処理の後に加工したくなることはよくあります。例えば、条件に応じてURLの書き換えをしたり、エンコーディングの変換をしたり、Cookieの処理をしたり…といったことが日常茶飯事です。こういう処理を、サーバと
PHPerがRailsデビューしてWebAPIを作りRSpecでテスト書いてCap3/CircleCIでデプロイして分かった事を1ヶ月前の自分に教えたいので、まとめてみた - Qiita
PHPerがRailsデビューしてWebAPIを作りRSpecでテスト書いてCap3/CircleCIでデプロイして分かった事を1ヶ月前の自分に教えたいので、まとめてみたRubyPHPRailsRSpec タイトル長い。すまぬ。PHPerとして約10年近く。Ruby自体は案件によってちょこっとだけ触ったことがある程度。Rails自体を本格的にさわるのは今回が初めて。PHPだとCakePHPを中心にZend／Symfonyなどいくつか。そんな僕が今回、Rails4デビューをして、WebAPIを作り、RSpecでテスト駆動開発風味で、GitHubプルリクベースの、CircleCI経由デプロイをするまでの開発の流れをひと通りやってみて、分かったことがいくつかあったので、それをまとめてみた。過去の自分のために。 注意点としては、今回作ったのはWebサービスではなく、スマホゲーム（ネイティブ）のサー
そうだRack作ろう。
超簡単！？ ActiveAdminで作る管理画面@Ruby / Ruby on Rails ビギナーズ勉強会 第３回 「Ruby / Ruby on Rails ビギナーズ勉強会 第３回」で発表した内容です。 簡単に管理画面が作成できるActiveAdminについて発表しました。 他の管理画面系Gemの紹介や、導入を説明しています。 また、カスタマイズするに必要な知識のDSLについて概要を解説しています。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 「Ruby / Ruby on Rails ビギナーズ勉強会」は初心者が集まって発表したり、自主学習する勉強会です。定期開催しています。 開催の連絡は以下の方法で受け取ることができます。 ## DoorKeeperグループ イベント申し込みを受け付けている、DoorKeeper でのグループです。 http://ror-beginners.doork
第23回 Rackとは何か（1）Rackの生まれた背景 | gihyo.jp
はじめに SinatraやRamazeといったRubyのWebアプケーションフレームワークに興味をお持ちの方であれば、Rackという名前をしばしば目にしているかもしれません。どうやら様々なフレームワークに使われているらしいのだけど、そいつが一体なんなのかよくわからない、そんなあなたのために今日はそのRackをご紹介したいと思います。 様々なフレームワーク、様々なアプリケーションサーバ しばらく前なら、Ruby on Railsブームの真っ只中、Rubyと言えばRails、Webアプリケーションを作るならRails、といったイメージを持たれていた方も多かったと思います。実際にWebアプリケーションを作ったり、Rubyに触れたりしたきっかけがRailsだったという方も多いでしょう。 しかし最近は、RubyのWebアプケーションフレームワークと一口に言っても、非常に簡単にアプリケーションが書けて
RailsでAPIをつくるときのエラー処理 - Qiita
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
Kibana 3 + Rails + Fluentdのサンプルアプリを作ってみた - y_310's diary
miyagawaさんのPodcast Rebuild: 19でKibanaの話があってちょっと盛り上がり始めてるので、簡単に動作を試せるサンプルアプリセットを作ってみました。 https://github.com/y310/kibana-trial git cloneしてREADMEに書いてある手順を実行していくと大体動くと思います。 railsからfluentdにログを送る部分は、こんな感じでrack middlewareを使って送ります。 # application_controller.rb class ApplicationController < ActionController::Base around_filter :collect_metrics def collect_metrics yield # ensureを使うのは例外時のログも捕捉するため ensure # co
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rubyでウェブアプリ〜Rack | | Scimpr Blog