Tokyo CabinetTokyo Cabinet is the successor of QDBM, a high performance database library similar to the DBM family. It also supports hash and B-tree databases and does not require any server process. The overall speed is improved compared to QDBM.
[rails][負荷分散]RailsのDB負荷分散調査のための資料 - yoshitetsuの日記
magic_multi_connections Magic Multi-Connections magic_multi_connectionsのページ Magic Multi-Connections: A “facility in Rails to talk to more than one database at a time” magic_multi_connections作った人の記事 Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築 magic_multi_connectionsの使い方がのってる Ruby on RailsでMagic Multi-Connectionsを使う magic_multi_connectionsの使い方がのってる 分散DB対応ライブラリ Magic Multi-Connections を試してみる magic_multi_
![[rails][負荷分散]RailsのDB負荷分散調査のための資料 - yoshitetsuの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/6c5340c5a8cf3ce87fada9122698e67a0a42d1c8/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127121096700%2F17680117127121100502%2F1557249666)
Rails 開発者こそモデリングするべきだって思った - Akasata's Page（あかさたのページ）
2007-10-16 03:24 : Rails 開発者こそモデリングするべきだって思った Rails 開発者こそモデリングすべきだよなぁって唐突に思いました。Rails は DB スキーマさえ作成すれば、そのあとはレールに乗って高速に開発ができるのですが、当たり前の話 Rails は DB スキーマの設計方法は教えてくれません。ましてや、どんなソフトウェアを作ればいいのか教えてくれるわけでもありません。 Rails は「何を作るか決めてからがすごいフレームワーク」なのです。分析工程は開発者自身が自分のやり方で実施しないといけないのです。 何を作るのかを導き出すのはモデリングが得意です。とはいえ、一般的な UML 本に載っているような開発プロセスはどうにも Rails アプリを記述するには重すぎる気がします。（少なくとも私はそう考えています。）往々にして、図解言語というも
Railsの生産性とかDB設計の要否とか - moroの日記
Railsの生産性をめぐるid:habuakihiroさんとのやりとりがありまして、そこで羽生さんのERD本を読んで思ったことや、先週のRubyカンファレンスでのDHHのスピーチなんかから漠然と考えていたことをぜひ書いておきたくなりました。 自動生成(scaffold)について Railsラヴでいちおう色々と触ってきた立場からの感想としては、DBスキーマからの自動生成はかなりの割合で"客寄せパンダ"です。それを強調して"Javaの10倍の生産性"とやったのはマーケティング手法としてはすごく成功を納めたわけですが*1、scaffoldで自動生成できるのは所詮はそれなりのものだと思ってます。 もちろんバックエンドでのマスタ管理なので、多少UIがティピカルでひねりがなくても速く作ってほしい、という案件には十分役に立ちますし、スペジェネのように自動生成部分を作りこまれた面白いものもたくさんあります
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
