カテゴリ別 2003年 | 2004年 | 2005年 | 2006年 | 2007年 | 2008年
知り合いサイト: よんだもの / 暴想 / Linuxでやる夫 / 新宿Vipper / 僕だけが幸せになればいいのに。
IPA の OSS iPedia で公開されています。
資料は、RubyCityMATSUE こと松江市の基幹業務システムの構築プロジェクトに関するものです。「Rubyの普及を目指した」と題されているように、Ruby による堅いシステムの構築の実績とノウハウを作るのがテーマだったのでしょう。項目としては、
でした。個人的には、
実運用に向けた考察 ・システム連携に関する考察 ・システム導入（調達）に関する考察
が気になります。既存システムとの連携やシステム調達で、Ruby を採用するとどのような制限が生じるのか。私はそういった制限の少ないウェブアプリしか作ったことがないので、想像しかできないところですから。
また、
人材育成を通じて作成した「Ruby コーディング規約」、「つまづき集」、セキュリティ検証を通じて作成した「ハーデニングガイドライン」といったドキュメントについても、今後RubyやOSS を活用した業務システム構築の際の参考になるものと期待している
とありますが、これは公開されるんでしょうかね。社内規定としてコーディング規約やセキュリティ規約を定めている会社は多いと思いますので、社内規定を作成する元ネタとして活用できるんじゃないでしょうか。
ruby 1.8.7 pre2 で activerecord-2.0.2 のテストを実行すると割りと失敗してる件の続きです。
Edge Rails ならすでに 1.8.7 対応しているかもと思って試してみました。
1452 tests, 5139 assertions, 2 failures, 1 errors
1422 tests, 5086 assertions, 0 failures, 1 errors
1452 tests, 5139 assertions, 2 failures, 1 errors
1422 tests, 5086 assertions, 0 failures, 1 errors
失敗やエラーがあるのはまあ edge なのでしょうがないとして、1.8.6 でも 1.8.7 pre2 でも結果が変わりませんでした。もちろん以前の日記に書いたような 1.8.7 での仕様変更に伴うエラーもありません。
いまの Edge Rails は 2.1.0 になるのでしょうから、おそらく Ruby 1.8.7 は Rails 2.1.0 以上推奨ということになりますね。Rails ユーザが Ruby 1.8.7 にバージョンアップするのは Rails 2.1.0 がリリースされるまで待ち（どっちが先になりますかね）、既存の Rails アプリは Ruby 1.8.6 以下のままで動かすのが無難でしょう。
ついでに他のコンポーネントのテストも実行してみました。
ActionPack で落ちるのは[ruby-dev:34532] ruby_1_8でform_tagが動かないの件でしょうか。他は問題なさそうですね。
やはり、[ruby-dev:34532] ruby_1_8でform_tagが動かないの件でした。r15856 の変更を戻した ruby 1.8.7 pre2 で EdgeRails の ActionPack のテストを実行したところ、正常に終了しました。
1907 tests, 9146 assertions, 0 failures, 0 errors
[BUG] と出て落ちますし、ActionPack の修正で回避するよりも、Ruby 側を直した方がいいんじゃないですかね。
Ruby 1.8.7 preview3 でも結果は同じでした。
helper_method で定義されたヘルパーメソッドを呼ぶと落ちるみたいです。つまり、form_tag ではなくて、
% rails sample
% cd sample
% ruby18 ./script/generate controller sample index
% echo '<% protect_against_forgery? %>' >> app/views/sample/index.html.erb
% ruby -pi~ -e 'sub(/assert.*/){"get :index"}' test/functional/sample_controller_test.rb
% ruby18 test/functional/sample_controller_test.rb
で落ちます。protect_against_forgery? の代わりに form_authenticity_token でも同様。
しかし、これを最小コードに落とし込むのは結構面倒そうですね。。。
Ruby on Railsのスケーラビリティ強化製品、続々 − ＠ITという翻訳記事がありました。どうも雑多な記事ですがちょっと読んでみます。
その生産性に開発者から全幅の信頼を寄せられているRuby on Railsだが、人気の高いこのWebプラットフォームに対しては、高負荷に対応するスケーラビリティが低いという批判の声も多く出ている。そのような中で、単にRailsとも呼ばれるRuby on Railsの可用性を高めようと、一部の新興企業が事業を展開している。
Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT
ということで、Rails は生産性は高いがスケーラビリティが不足しているという問題があり、それを解決しようとするベンチャー企業が現れ始めているという内容です。
こと日本では「Rails はスケーラビリティが不足している」という認識はもっぱら twitter によってもたらされている気がしますが、
最近は多数のエンタープライズアプリケーションにも採用され始めた。だが、相応の成功を収めているにもかかわらず、Railsを使った開発プロジェクトはエンタープライズスケーラビリティの理想形を95％までは具現化できるのに、負荷の大きい環境でアプリケーションを使用するにはほかの言語の力を借りなければならないという苦言も、しばしば聞こえてくる。
Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT
ということで、エンタープライズ分野での採用も進んでおり、そこで問題となっているようです。とはいえ、昔 Martin Fowler が Martin Fowler's Bliki in Japanese - エンタープライズRails で言ってたように Rails の「コア機能」はエンタープライズ向けというわけではなくて、plugin など周辺で補おうという考えですから、一口で「エンタープライズアプリケーション」と言っても分野は限られていると思いますが。具体例がほしいですね。
負荷の大きい環境でアプリケーションを使用するにはほかの言語の力を借りなければならない
というのは、この間の「twitter が Rails 使うの止めるよ騒動」で Evan Williams が言った「twitter はすでに多くのコードがRailsではない」を思い起こさせます。
Ruby は、速度が要求される部分は C で書いて拡張ライブラリにしちゃえという技が比較的容易なので、ほかの言語の力を借り
て済むならそれでいいのではと思います。ただ、ボトルネックが Rails そのものにあった場合には、Rails のようなフルスタックのフレームワークのボトルネック部分だけ C で書き直すというのも現実的とはいえないですね。Ruby 処理系や Rails に手を入れられないという前提ならアプリのロジックやアプリケーションサーバ（apache/lighty/mongrel/thin）、物理サーバでパフォーマンスの確保やスケーリングさせないといけないことになります。
で、スケール問題に対するソリューションの一つ目として紹介されているのが New Relic です。
New Relicがサブスクリプション形式で販売するRailsパフォーマンス管理ソリューション「RPM」は、開発者によるリアルタイムでのアプリケーションパフォーマンス問題検出、診断、修復を迅速に、かつ低コストで実現すると、New Relicは説明している。同SaaS（Software as a Service）は現在、限定的な顧客にプライベートベータ版として配布されているが、間もなくRuby on Railsコミュニティ全体に向けた一般提供が始まる見込みだ。
Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT
ということですが、この説明ではよく分からないので、TechCrunch Japanese アーカイブ » New Relic、Ruby on Railsアプリのパフォーマンス・モニタ開発へを読むのがいいでしょう。
稼動中の Rails アプリのパフォーマンスモニタリングをして、ボトルネックを発見できるサービスですね。「Hoge コントローラの foo アクションが遅い」といったことが一目で分かるので、そういったボトルネックを解消していくことでパフォーマンスの問題を解決できると。まあ、「スケーラビリティ強化」に対する直球の回答ではないですけれども。
MySQL のエンタープライズ版は、MySQL Enterprize Monitor というツールが利用できます。MySQL サーバの稼動状況を多くの項目で網羅的に監視できたり、最適な設定を提案してくれたりします。
New Relic や（いずれ現れるかもしれない）その競合が育てば「Rails Enterprize Edition」のようなサポート付きのサービスというのも生まれるんじゃないかと思います。特に日本では金払ってサポートしてもらうのが好まれますけど、NaCl や CTC あたりがやったりしないですかね。
New Relicは、30〜60日以内に新製品をリリースするという。同社のプライベートベータプログラムには約50社の顧客が参加しており、各社は同製品を利用してRailsアプリケーションのスケーラビリティ向上に役立てている。同社はさらに、RPMの実働用バージョンを補完する開発者向けのソリューションを提供する予定
Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT
蓄積されるノウハウがコミュニティに還元されると嬉しいですね。Rails Conf でセッションするとかで。
さて次に紹介されているソリューション？はプラットフォームです。
Rails実装プラットフォームプロバイダのEngine Yardは4月29日、先日リリースされた、分散化バージョン管理システムの「GitHub」サービスと、人気の高いバグ追跡アプリケーション「Lighthouse」をサポートすることを明らかにした。Engine Yardのスケーラビリティの高いプラットフォーム上でGitHubおよびLighthouseをホスティングし、Rails開発者のソースコードとチケットトラッキングの両方を安全に使用できるようにすると、同社は述べている。
Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT
Engine Yard は Rails が稼動するサーバを提供するサービスをしているところです。詳細は例によって、TechCrunch Japanese アーカイブ » Benchmark、Ruby on Railsに賭ける―「Engine Yard」に$3.5Mを投資を参照ください。New Relic も Engine Yard も同じ Benchmark が投資しているんですね。Rails に期待しているのかな。しかし、Engine Yard は別に「スケーラビリティ強化製品」じゃあないですね。
続けて読んでいくと、
Engine Yardの最高技術責任者を務めるトム・モーニニ氏は、eWEEKに対し次のように語っている。
「Railsのスケーラビリティに根本的な問題はないと、われわれは考えている。それでもこの点を批判する人々は、効率性とスケーラビリティを混同しているのだろう。RubyとRailsは、ランタイムにおける効率性こそ従来のプラットフォームに劣るが、これはほかの新しい開発プラットフォームすべてに言えることだ。Javaも登場した当時はひどく遅く感じられたのを思い出してほしい。Rubiniusなどの新たなRubyランタイムは、ネイティブコード生成といった、Javaでも多用されているのと同じ最適化技術を採用しており、効率性の向上を実現してくれる。現在われわれは、一月あたり数百万人ものユニークビジターが使用するRailsアプリケーションを、わずか数台の最新サーバ上で運用しており、ビジター数が数千万人になっても、将来的に数億人になっても大丈夫だという自信を持っている」（モーニニ氏）
Ruby on Railsのスケーラビリティ強化製品、続々 − ＠IT
なんとスケーラビリティ問題はないということです。ただ、Java を引き合いに出している件を注意深く読むと、「問題はないが気にする人も今後はより良くなるので心配しなくて良い」という読み方と、「サービスを提供している以上問題があるとはいえないが、やはりこの辺が良くなってほしい」という穿った読み方がありそうです。どちらにしても改善すべき点は存在するわけですね。JVM の進化と同様の進化が Ruby にも必要ということなのでしょう。
Ruby1.9(YARV)、JRuby、Rubinius、MagLev と VM ベースの Ruby 処理系はいくつかありますが（MagLev はまだ実物ないですが）、VM の利点として捉えられているのはやはりパフォーマンスです（今のところ Rubinius はちょっと違いますけどね）。YARV の目的はパフォーマンス向上でしたし、JRuby の Charles Nutterが事あるごとに書いているのは、Java とのシナジー効果などというものではなくパフォーマンスです。MagLev もインタビュー記事ではスケーラブルというキーワードでパフォーマンスについて語っています。
Ruby 処理系のパフォーマンス競争で現時点で先頭にいるのは Ruby1.9 ですが JRuby が急速に迫りつつあります。将来的にはいずれかの処理系が、ハードウェア性能を勘案した相対的な速度では、現在の Java に追いつくかもしれません。でも、それまではやはりパフォーマンスが「問題」として取り上げられ続けるのでしょう。
元記事最後の DHH 御大の台詞については割愛。
ところで、Ruby on Railsのスケーラビリティ強化製品、続々 − ＠ITですが、結局「スケーラビリティ強化製品」なるものは、せいぜい New Relic の RPM くらいしか上げられてないですね。続々というのは一体なんだったのでしょう……原題は「Making Ruby on Rails Scale」なので単なる誤訳というのが結論？
私は活動しなかったのですが、今年もうちの会社はスポンサーをやるようです。ということで行くことにしました。
10 時少し前から近くのローソンのロッピーに陣取って、「混み合っています。少し経ってからやり直してください」を繰り返すこと数度、10:12 ごろに買えました。
（テストを書いて開発している場合、）トランザクションをサポートしていないデータベースを使うときには、test/test_helper.rb で、
self.use_transactional_fixtures = falseしましょう。
開発している Rails アプリに全文検索を実装するため、Tritonn を試していました。
全文検索対象のテーブルは InnoDB ではなく、MyISAM で作る必要があります。で、テーブルを作り直してテストを実行したところ失敗多数。
acts_as_tritonn を使っていたので、migration 周りのメソッドを再定義している部分が怪しいのかなと調べましたが空振り。テストの失敗の内容をよく読んでみると、どうやら他のテストの結果が影響しているような挙動をしていました。
teardown でデータベースの状態が元に戻ってないのだなと思いましたが、そもそも Rails はどうやってデータベースの状態をテストメソッドごとに戻しているのか疑問に思いました。調べてみたところ、teardown 時に rollback していることが分かりました。
以下がコードの該当箇所です。
# Rollback changes if a transaction is active. if use_transactional_fixtures? && Thread.current['open_transactions'] != 0 ActiveRecord::Base.connection.rollback_db_transaction Thread.current['open_transactions'] = 0 end
use_transactional_fixtures だったらロールバックしてるわけですね。ということで、use_transactional_fixtures を調べたらtest/test_helper.rb に記述されている設定項目でした。このトランザクションに対応してないデータベースでは、use_transactional_fixtures を false にすべしというのは、割と知られてる話のようで、不勉強なために時間を結構消費してしまいました。。。
use_transactional_fixtures を false にするとテストはちゃんと実行されるようになりましたが、どうもテストの実行速度が遅くなった気がします。fixture を毎回読み直すためかもしれません。
activerecord-2.0.2/lib/active_record/fixtures.rb の rdoc に以下のような一節があります。transactional fixtures を使わないのはどのような時かという説明で、その一はネストしたトランザクションを使っているとき、もう一つがデータベースがトランザクションをサポートしていないときです。
# 2. Your database does not support transactions. Every Active Record database supports transactions except MySQL MyISAM. # Use InnoDB, MaxDB, or NDB instead.
ということで、InnoDB などを使ってほしいみたいですね。
はてなで質問して諦めた件です。データベースに Tritonn 使っているときは Senna の全文検索が有効だけれども、SQLite などでも一応動作するという Rails アプリを作ろうとしています。
Tritonn (MySQL+Senna) で全文検索するには、テーブルを MyISAM で作成しなくてはなりません。Rails の migration はデフォルトでテーブルを InnoDB にするので、create_table の引数で MyISAM を指定してやる必要があります。そうすると必然的に MySQL でしか動かない migration になります。
とりあえずどうしたかといいますと、きれいな書き方ではないですが、ActiveRecord::Base.connection.adapter_name を使って MySQL の時だけ options を指定するようにしました。
例えば、記事テーブルを全文検索対象にするなら、以下のような migration クラスになります。
class CreateEntries < ActiveRecord::Migration
def self.up
options = {}
if ActiveRecord::Base.connection.adapter_name == 'MySQL'
options = { :options => 'ENGINE=MyISAM DEFAULT CHARSET=utf8' }
end
create_table :entries, options do |t|
t.text title, body
t.timestamps
end
end
def self.down
drop_table :entries
end
endさらに全文検索用のインデックス作成なども必要に応じて分岐しますが、もうちょっと抽象度の高い書き方にならないものかなと思います。
あと、MyISAM を使うと Rails に MyISAM エンジンは向いてないと思った次第 で書いたような問題も発生します。うーん。そもそも Senna じゃない全文検索エンジンを使うべきなのかも……
これの続きです。
[ruby-dev:34813] Re: ruby_1_8でform_tagが動かない で修正されたとのことなので試してみました。環境は 1_8 ブランチ最新と edgerails 最新です。
$ cd actionpack/ $ rake187 ... 1954 tests, 8436 assertions, 0 failures, 25 errors
落ちなくなりましたが、エラーが出るようになりました。出ているエラーは全部 uninitialized constant なので後一歩な感じです。
ちなみに、1.8.6 では、
1954 tests, 9503 assertions, 0 failures, 0 errors
と 0F0E です。
今日の edgerails で試したところ、
1954 tests, 9498 assertions, 0 failures, 0 errors
でした。テスト結果からすれば、Ruby 1.8.7 で Rails 2.1.0 が動くのは確実ですね。
なんとなく、ちょっと気になったのですが、この人力検索はてなって一日にどのくらいの質問が来ているんでしょうか。という質問をしたところ、大体100件くらい質問が来ているとのことでした。意外と少ないですね。
ヘルプによれば、ユーザが支払ったポイントの 5% がはてなへ手数料として支払われます。
id が 1211357719 から 1211447749 までの終了した質問 100 件のポイントの平均は約 180 でした。つまり 180 (ポイント) * 0.05 (手数料レート) * 100 (件/日) * 30 (日) = 27000 ポイント/月 が人力検索はてなでのポイント収入の概算です。
ポイント制度について - はてなを眺めて、他のサービスと比較しますと、
ということで、はてなダイアリー有償ユーザ 150 人分、はてなグループ最上級一つ分くらいの売上ではないかと推測されます。もちろんポイント手数料のみを考慮した計算で、広告収入などは計算に入れていませんが、桁が二つ変わる（誤差100倍）こともないんじゃないかなと。
売上規模だけで考えれば後輩サービスに抜かれているというか、利用数や売上で判断すれば営利企業としては切るという選択肢も大いに考えられるわけです。とはいえ、出自となっており社名にも関係しているサービスですからさすがに無くなることもないでしょうね。
Webアプリ開発フレームワーク「Ruby on Rails」の新版が今週末リリースへ という翻訳記事なんですが、何か読んでて変だなと思って原文にあたったところ、翻訳記事で「拡張性」となっているところは原文では scalability でした。
まあ、辞書を引けば、「拡張性、スケーラビリティ」とは書いてありますが、アプリケーションフレームワークの文脈で拡張性と言われると機能の拡張性のことだと思ってしまうので、素直にスケーラビリティとしてほしいところです。
一日のダウンロード数世界一でギネスに挑戦するという、Firefox3 のキャンペーンが昨日始まりました。この日記も左上にバナーを載せています。
が、キャンペーン開始を伝える記事（Firefox 3 Download Day キャンペーンでギネス世界記録に挑戦! ）には、対馬が韓国になっている、北方領土がロシア領になっているといった指摘のコメントがついています。これは早速バグ登録されて、Tsushima needs to be included in Japan で議論されて、対馬については修正されたようです。北方領土については政治的にも決着がついてない問題が bugzilla で決着がつくわけもなく、今のところ元データ（Ammap）そのままになってます。今後おそらくネットニュースが取り上げるでしょうから、下手すると炎上する可能性もありますね。
しかし、データがベクターじゃなくてドット絵だったら解像度的に島嶼は省略されるでしょうから、こんな問題は起きなかったと思います。情報量が増えて現実に近くなったことで、意図しなかった現実の問題に巻き込まれるというパターンは地図以外にも存在するのかな。
最近のコメント：
RSS
This work is licensed under a
Creative Commons License
(note: text only. w/o web design, citations, (re)distributed softwares).
