本站声明: 我们成立于美利坚合众国,对全球华人服务,受北美法律保护。中国大陆用户或者未满18岁,被误导来这里的,请立即离开! 联系我们: Telegram:zutuandayez@gmail.com
prologue I implement Rjb-JDBC adapter, based on JRuby jdbc adapter(gem search --remote jdbc). This is very mock up code. I have little incentive to more. Please test your self and use this code. usage save such a place that "/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/rjb_jdbc_adapter.rb" Open "active_record.rb", 'rjb_jdbc' append to RAILS_CONNECTION
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規模サイト構築が話題になってるのが面白い。 Twitter trouble (Loud Thinking - DHH) まずTwitterの高負荷について言及、Twitterは11,000リクエスト/秒 の高負荷で問題となっているらしい。 そしてスケーラビリティの鍵はDB分割だ、と言っている。Railsは基本一つのDBを見るのでスケーラビリティの問題になる (確かにWebサーバはロードバランサがあればいくらでもスケールするしね、Sessionの共有だけ気を付ければ) ↓ Dr Nic » Magic Multi-Connections: A “facility in Rails to talk to more than o
1.1→1.2の乗り換えでみんな苦労してるようで、だんだんと改悪に対してグチるスレな流れに。auto loading と multibye 対応だけは、本当に改悪だよね。とか言って。 おさらってる間に残り10分。慌てて REST の話に。 route も対応したけど、キモは respond_to 1.1 から使えているため 1.2 では新鮮味がない respond_to でかなり DRY になるけど最後の表示部分の処理が煩雑 そこで perform_filters perform_filters がない間は片手落ち (→ 本体に取り込ませようキャンペーン) ● 後半: RBatis 元は iBATIS という Java での実装で、それを Ruby へ移植したのが RBatis。ORM の実装らしいので、Rails の AR と何が違うの?競合するの?一緒に使えるの?あたりが気になるところ
1/20に開かれた第6回RubyOnRails関西へ行ってきた。 場所は神戸電子専門学校。目の前にオランダ館、風見鶏館などの異人館があり、華やかな場所でした。 このたびの発表の中で最も興味を引いた講演が「やさしいRailsの育て方」(by 西和則さん)。 講演内容は、Railsでもテーブル設計をきちんと考えましょう、ということなのだが、それは昨年8月の渡辺さんの指摘に対する回答になっているように思う。 【1】RDBのテーブル設計におけるアンチパターン Railsをやっていると、例えば、下記のアンチパターンに囚われてしまう。 1・無限FK地獄や列破綻 テーブルに他テーブルの外部キーをどんどん持たせると列が増えていく。 西さんの例では、社員テーブルに派閥1、派閥2のカラムを増やしていた。 2・フラグステータスとバタフライ効果 「北京で蝶が羽ばたくとニューヨークで嵐が起きる」がその意味だが、「小
An occasionally updated repository of thoughts, past work, and links. Topics include programming, web ventures, and writing. dbmodel is a tool to generate Rails files (models, scaffolds) from a free graphic database design tool, DBDesigner 4. You can create tables in DBDesigner, specify table relations, synchronize the model with a MySQL database, and then use dbmodel to automatically generate cod
MySQLのあるテーブルにINDEXをつけていたのだけれど、フィールドの型がTEXTだったので、「最初の500文字まで」という制限をかけていた。(MySQLではINDEXをつけられる文字数に制限がある)ところがこの文字数制限、RailsのSchemaDumperではダンプできない。 で、Schema中にはSQLを直接書いていたのだけれど、それだとテストができないのだ。 rakeでテストを走らせると、「開発用DBからRuby形式でテーブル形式をダンプ→それをテスト用データベースに適用」する。のだけれど、上述の制限がうまく動いていない。SQL形式でダンプするやり方があるだろうと探したのだけれど、見つける前にRuby形式に適当に手を入れた方が早そうだと思った。ので、作った。 # インデックスの制限もDumpできるようにする module ActiveRecord module Connectio
おぉ、ガチだ。 [RDBMS]複合主キー? 18:57 ・・・まだそんなこと言ってる人いるのか。 id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。 いや、お互いものすごく優秀で有名な方だし大人なのでガチの勝負はしてくれないとは思うのだけれど、ぜひ世の多くのさまよえるSEのためにガチンコ勝負して決着つけてくれんかなぁ。てゆうか、今回の案件でもID派(=私)と複合主キー派(=モデラー)でもろに喧嘩してるし、前のプロジェクトでも他の人が同じようなことやってたし、さらに前の案件でも(w そろそろ、IDを使うべきかそうでないかくらいベストプラクティスを決めてほしいなぁと思う今日この頃*1。 たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるよ
「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるORマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次TTMレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ
Rails 勉強会@関西 第5回 では、渡辺幸三さんの「アジャイルにデータモデリング」という演題でもお話を伺いました。 これだけはというポイントは、 1.業務システムやるなら『簿記3級』は必須。でないと業務システムでは話が通じない。 2.『関数従属性』これがデータベース諸問題で一番重要。 業務モデル > 機能モデル > データモデル データモデルの話では、文法がある。 データ項目(それ単一で意味をもつ単位)同士の関係づけが基本。 【例】 会員No. と 会員名 会員No. が決まれば、会員名が決まる。これが関数従属性。 数学の関数の例 y = f(x) = 2x + 3 ↓ データモデリング関数 会員名 = f(会員No.) とかいろいろ勉強させて頂きました。 企業システム開発に特化した,フリーのモデリング支援ツールXEADが登場 http://itpro.nikkeibp.co.jp/
デスマーチ・プロジェクトに束の間の休日ができたので、RubyOnRails 勉強会@関西に初参加してきた。 Ruby勉強会@関西と同じく、女子学生や女性エンジニアも多くて、華やかな雰囲気で、講演も甘辛だった。 僕はRubyOnRails初心者なので、聞きやすかった。 聴講の目的は、もちろん渡辺さんの「アジャイルにデータモデリング」。 「何故、RubyにDOAの第一人者の渡辺さんがいるの?」みたいな。 【1】RubyOnRailsに、複合キー(複数の識別子)を持つテーブルはない!? 渡辺さんのお話は、業務システムとデータモデリングの関係から始まり、テーブルの項目の関数従属性の説明と演習まで、というとても初心者向けの講義。 懇親会で業務に携わっていると言うエンジニアの女性が、 「私はRailsのインストール方法も知らない初心者だが、渡辺さんが話した関数従属性や正規化の話はとても基本的な話です」
http://event.seasar.org/sc2006spring/viewAttachment.do?_pageName_=Materials%2FD4.ppt 今さらながら、はぶさんのSeasar Conference 2006 Springの資料を見て、 その分かりやすさに鱗が落ちまくりました。 で、WEB+DB PRESS Vol.21のはぶさんの記事を読み返すと、これまた素晴らしい。何がいいかって、その記事を周りの人への説明にそのまま使えることです。佐藤正美さんのT字型ERだと、その難解な表現ゆえに、「これ通りやってみて」ではどうにもなりません。(同じようなことを言ってるんですけどね) で、このコードとは別にIDを付けろとか、交差エンティティを作れなどはRailsのモデリングには最適なのです。Railsの流行とともに良いDBモデリング手法も流行りますように…
_ まとめ 良くわからなくなったのでまとめてみた。わかる粒度が名前を知ってるだけ、概念を理解している、実際に利用したまでばらけているので、嘘八百のような気もする(というか、嘘は確実にある)。 こういうときにマインドマップってのを使うんだろうか? EA(全体統合) BA …… プロセス DA …… データ AA …… 制約 TA …… 実装 DOA(AS IS重視)—フラット—物理モデル—ボトムアップ まずモノ(エンティティとリレーション) 検証手段:エンティティの整合性 思考法:join 抽象的 T字型派……純粋抽象派(ここに含めるべきではないのでは) ↑ 伝統派……業務分析 ↓ TH派……帳票上のエンティティ 具象的 はぶ派……UI(Webのページ、帳票など)上のエンティティ+業務フロー (頂いたコメントを元に修正:7/1) 伝統派……業務分析 TH派……帳票上のエンティティ
RubyKaigi2006 RESTのPOST,GET,PUT,DELETEとDB(というかリソース)のCRUDの類似。Webアプリケーションにおける殆どの操作は、リソースのCRUDに対応させることができる。*1 実際のアプリのレベルに落として考えると、例えばユーザをグループに追加する際に、ユーザコントローラに対して「グループに加入させよ」メッセージを送る*2のではなく、メンバシップコントローラに、ユーザ-グループ間のメンバシップをCREATE(REST的にはPOSTで依頼)してもらう事になる。*3。 上記を徹底すればWeb(アプリ|サービス)が、外部からDBのように扱えるようになる。多分、この話がActiveResourceに繋がる。(のだと思う) なんか学ぶべき点が多そうです。 あと個人的には、DBのように扱うためには、ユーザ(や他のアプリ)との対話の中で、適切な単位でCRUDを纏め上
RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く