2007-06-14 Thu
id:secondlifeのRuby会議プレゼン資料
id:secondlifeのRuby会議のプレゼン資料が公開されていた。
僕はこの資料が好き。
Rubyではじめて画像処理をしようとする人が読むと幸せになれそう。
川o・-・）＜2nd life - モテる Ruby! - Ruby会議
Ruby で画像編集を身につけたらモテるかも？ * 画像編集ライブラリの紹
介 o ライブラリを使うと、こんなの作れるよとか * RMagick についての
Tips
介 o ライブラリを使うと、こんなの作れるよとか * RMagick についての
Tips
「画像編集できてもモテない」という結論のようなので、
更なるモテを探さなきゃいけませんよ。次は何ですかね。（笑
投稿者:としのり 日時:23:59:59 | パーマリンク | コメント | トラックバック() |
2007-04-23 Mon
Railsで複数DBを使い分けるためのライブラリ magic_multi_connections
「magic_multi_connections」というRailsで複数DBを使い分けるためのラ
イブラリについて、まとめている記事がありました。
Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体
も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規
模サイト構築が話題になってるのが面白い。
も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規
模サイト構築が話題になってるのが面白い。
基本一つのDBを見るRailsを、複数DBを使えるようにできるようです。
さらに、acts_as_readonlyableという同じように複数DBを使うための
ライブラリについても言及されていました。そのうち使うと思うのでメモ。
[2007-04-27]：追記
この話題に対する言及を見かけました。
みかログ: DBの分散方法
2種類のモジュールがあるようだけど，readonlyable 方式はすぐ問題が
出てきそうな気がする．
たとえば，ユーザ登録時にIDの重複判定をするような場合，read_only 指
定をしていると，masterからslaveへの更新反映が遅延するため，正しく
重複判定出来ない可能性が出てしまいそう．
かといって，read_only 指定をしないと，アクセスが多そうなユーザ情報
のテーブルが分散されない．
その辺を考えると，多少面倒でも magic_multi_connections のやり方が
正解じゃないのかなぁ，と思う．
出てきそうな気がする．
たとえば，ユーザ登録時にIDの重複判定をするような場合，read_only 指
定をしていると，masterからslaveへの更新反映が遅延するため，正しく
重複判定出来ない可能性が出てしまいそう．
かといって，read_only 指定をしないと，アクセスが多そうなユーザ情報
のテーブルが分散されない．
その辺を考えると，多少面倒でも magic_multi_connections のやり方が
正解じゃないのかなぁ，と思う．
なるほど、やっぱり用途しだいということですかね。
投稿者:としのり 日時:23:59:59 | パーマリンク | コメント | トラックバック() |
