Scalable Event Analytics with MongoDB & Ruby on Rails
The document discusses scaling event analytics applications using Ruby on Rails and MongoDB. It describes how the author's startup initially used a standard Rails architecture with MySQL, but ran into performance bottlenecks. It then explores solutions like replication, sharding, key-value stores and Hadoop, but notes the development challenges with each approach. The document concludes that using
Railsで勝手にSession持ってきていじっちゃう方法 : やむにやまれず
2007年08月18日17:28 by 山崎泰宏 Railsで勝手にSession持ってきていじっちゃう方法 カテゴリRuby Tweet sparklegate Comment(9)Trackback(0) 殆ど使うことは無いと思いますが。 Session IDさえ分かれば、好きなときにSessionオブジェクトが取って来れます。require 'active_support' session_id ='xxx' session_options = HashWithIndifferentAccess.new session_options.merge!({ :session_id => session_id, :database_manager => CGI::Session::PStore, }).merge!(ActionController::Base.session_option
ホワット・ア・ワンダフル・ワールド Ruby や Rails が遅くなるのには理由がある
という主張ならば，全く正しいと思います． やむにやまれず:2007年07月20日 Rubyは遅いから使えるのです (1) Ruby が遅いから Rails が遅いというのは間違い． C で書いても，汎用フレームワークを目指そうとすれば，かならずオーバヘッドが積み重なって遅くなる． むしろ，下手なプログラマが書いたら，Ruby よりも遅くなる． というか Ruby は，Rails を書くための，C のフレームワークとさえ言える． (2) 言語の効率よりも，開発効率の方が，昨今の Web アプリケーションを取り巻く潮流からしてはるかに重要 あと，一般的に，開発効率は処理効率に直結する． プロトタイプは，効率度外視で作ることが多い． 最適化は，ある程度完成度が上がってきてからの話だから． 作りこめば作りこむほど処理効率は上がっていくのが普通． ゆえに 「言語の速度 joel のメタメタメタ… フ
Ruby on Railsの処理俯瞰図 : やむにやまれず
2007年07月15日15:54 by 山崎泰宏 Ruby on Railsの処理俯瞰図 カテゴリRuby Tweet sparklegate Comment(0)Trackback(0) 左側にWebクライアントを配し、受けたリクエストからレスポンスを生成するまでの流れを概念的な画にしてみた。 入力：Content-Type毎にparamsを構成する処理：ビジネスロジックは、このparamsを参照することで動作する出力：respond_toにてAccept毎のレスポンスを構成して返すと言った大枠の流れがあり、URI毎にユニークな形で定義されることからこうした入出力の切り替えを可能した思想で組み立てられているというところは面白い。 こうした流れはちょうどRailsがRESTfulなアプリ作りもやれると盛んに言い出した頃、少なくとも昨年の早い時期から実装されていました。 Web APIが最た
Ruby なんて遅くて使えないよねって言ってみる - Akasata's Page（あかさたのページ）
2007-07-03 16:25 : Ruby なんて遅くて使えないよねって言ってみる 「Ruby なんて遅くて使えない」という意見が出ます。（昔、Java も似たようなことを言われましたっけ。）これに対して、Ruby 好きな人からは、「大抵の Web アプリではボトルネックは IO になるからアプリの言語は遅くても構わない」「CPU 時間よりも開発者の時間の方が重要」というような反論が展開されます。 Rails 厨にならないためにも、ここは Ruby に批判的な目を持って、この問題を考えてみたいと思います。 ■ 前提 Ruby を採用するとなると Rails 絡みで Web アプリでしょうから、Web アプリについて考えてみます。（でも、DLR とか話に出てくるわけですから、クライアントで使う場合もそろそろ検証した方がいいと思いますけどね。） ■ Ruby は遅
まとめ：「Ruby なんて遅くて使えないよねって言ってみる」 - Akasata's Page（あかさたのページ）
2007-07-20 21:17 : まとめ：「Ruby なんて遅くて使えないよねって言ってみる」 私が書いたにしては妙に反応のあった「Ruby なんて遅くて使えないよねって言ってみる」についてです。 釣りっぽいタイトルと整理されていない内容のおかげで誤読が出るとまずいので、念のため補足します。このエントリの趣旨は、Ruby は遅いけど、Web アプリにおいてはその遅さがシステムのトータルなパフォーマンスに与える影響はそれほど大きくは無いので、Ruby を使っても問題はないということです。ついでに言えば、私は「プロトタイプは Rails、本番はパフォーマンス／スケーラビリティを考慮して Java」とか「Rails を採用すると運用フェーズでコストが増大する」という意見も鵜呑みにはできないと考えています。本当に Ruby/Rails がボトルネックになっているのかと聞いてみたいと
Rubyは遅いから使えるのです : やむにやまれず
2007年07月20日13:00 by 山崎泰宏 Rubyは遅いから使えるのです カテゴリRuby開発スタイル Tweet sparklegate Comment(1)Trackback(0) 「Ruby なんて遅くて使えないよねって言ってみる」を読んで： 逆でしょう。RubyやRailsは遅いから使えるんです。 論点を整えますが、設計者、主にプログラマから見て「使える」と表現しています。 経営やプロジェクトマネジメントの観点まで広げると、Railsを採用するということは端的に言えば、「開発フェーズを効率化して運用フェーズでコストとして被る」ということです。 ビジネスプランも加味した上でのトレードオフになります。 言語のパフォーマンスを重視してみたところで無駄 - 開発者はみんなフレームワークを欲しがる：文句無しにパフォーマンスが良いので、Cで全てを書くとどうなるかです。 設計の初期段階で
prototype.js + Railsでテキストファイルをやり取りする方法 : やむにやまれず
2007年07月10日16:58 by 山崎泰宏 prototype.js + Railsでテキストファイルをやり取りする方法 カテゴリJavaScriptRuby Tweet sparklegate Comment(2)Trackback(1) またしても変なところでハマったのでそのメモを。orz 要件としては、「prototype.jsにてAjaxを使ってTextファイルをサーバに送信、サーバ側はRailsで受信したい」というだけです。 思いつくままに実装してもダメで、クライアントとサーバそれぞれに少しだけやらなければならないことがありました。 クライアント側ではAjax.Requestのパラメータ指定が重要：パラメータとして２つのポイントがあります。 contentTypeを指定することContent-Typeヘッダとして付与されるようになります。ここではtext/plainを指定し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.cnet.com/blog/yam/2007/12/21/entry_25003277/