ぼくが見ているレール(map.resouces編) - moroの日記
先日のQConで大場さんもおっしゃっていたことですが、Railsで開発をする上でものすごく重要なポイントに、Railsの敷いたレールから降りないというのがあります。別にコレはRailsが不自由だというわけでなく*1、通り一遍のものしかできないというわけでもなく、ただ基盤と相性の悪い設計すればあとで苦労するという、当然の話なわけです。 最近、私を含めいろいろな方が「レールから降りないで作るのが重要」と話しています。が。じゃあそのレールはどこにあるのかという話はあまり聞かれません。ということで、ふだん私がRailsアプリを設計するときに意識しているレールを言語化してみて、議論なりのたたき台にしたいな、と思った次第です。 とはいえDB周りは「羽生さんのERDレッスン嫁」で7割くらい済む話*2なので、まずはコントローラから。 設計指針としてのmap.resouces Rails 2.xにおいて、コ
ネストしたリソースの扱いの話とか - moroの日記
Rails勉強会@東京の月刊Merbで瀧内さんがサンプルを示しながらMerbの使い方を説明してくれました。 で、そのときにブログのようなものを実例に使っていまして、そのCRUDの設計についてプチ議論になっています。 まとめ なんかコードを書いてみたりしたらえらい長くなったので、私の考えを簡単に要約すると とりあえずこの前提に興味があるならDHHのプレゼンを見るといいと思います map.resource使うといいよ ビューの事情なんだからAjaxとテンプレート差し替えで何とかするのがいいかと それを簡単にするプラギンが欲しい という。あと読み返して思ったんですが、ネストしたリソースの扱いについての議論に対して、そのリソースはネストしていない、という主張が来てるのか。それはすれ違うなー、と思いました。 ここから意見いろいろ データ構造としてはよくあるブログを想起していただければいいんですが、P
WEBrickをつかってActiveResourceのダミーサーバを作る - moroの日記
ActiveResouceなんかを使ったり、認証サーバと連携したりといった外部サーバとの通信が必要なアプリケーションを書く場合、ローカルで動かせるダミーサーバが欲しくなります。このところ仕事でそういうシーンが多かったのですが、そういったときにWEBrick(とActiveSupport)を使うとものすごく簡単にダミーサーバを作れます。 今日はActiveResouceを使うためにAResT API*1をしゃべるダミーサーバが欲しかったんですが、以下のような感じで簡単に書けました。実物はもうちょっと複雑だったので、所要時間10分くらい。 使う側はこんな感じです。 WEBrickすごい。「まるごとWEBrick」とか「初めてのWEBrick」とか「WEBrickレシピブック」が出版されるべき。 *1:ActiveResouceの規約に沿ったAPIをこう呼ぼう運動中
moroの日記 - resourceすごすぎる
map.resources( :users, :has_many => :friends, :member=>[:contact] ) do |users| users.resources :todos endが、rake routesで↓となる。誰か使いこなせるんでしょうか。。まぁもちろん馬鹿正直に全部に対応する必要はないんですが。それにしてもねぇ。 (in /Users/moro/dev.build/todo_2_0) users GET /users {:action=>"index", :controller=>"users"} formatted_users GET /users.:format {:action=>"index", :controller=>"users"} POST /users {:action=>"create", :controller=>"users"
ProxyにもなるRailsアプリ - moroの日記
このあいだWEBrick::HTTPProxyServerを使ってみてすごく簡単にProxyが書けることに感激したんですが、ふと「Proxyにしつつ自身へのリクエストはRailsで処理できないか」と思いました。 で、某WEBrickハッカーに聞いてみたところ、「できるよ。てかProxyってそもそも(ry」とのことでしたのでちょっと試してみましたら動いてこりゃすごい。 rails-1.2.3/lib/webrick_server.rbとrails-1.2.3/lib/commands/servers/webrick.rbを見ながら適当にスクリプトを作ったら動きました。 Proxyの側から直でRailsのモデルを使いまくれるかはまだ未確認ですが(でもできるよね、常識的に考えて)、これをベースにいろいろいじってみたいと思います。 以下実際に動作する起動スクリプトです。script/proxy_r
RSpec を使うための4つの語彙 - moroの日記
年末年始にスライドを作ろうと思って挫折しました。 RSpec のテストコードは見慣れない "should" なんかが出てきて難しそうに見えますが、実は覚えなきゃいけないのは 4つ程の語彙だけです。*1 Object#should_xxx [args] Object#should_have(n).items Object#should_not_xxx Proc#should_raise() Object#should_xxx [args] 超基本の書き方です。should_ の後に続いたメソッドを呼び出し、その結果が真ならパスします。args で、そのメソッドヘの引数も与えられます。これだけだとイメージし辛いと思いますのでいくつか例を。 "?"は付いても付かなくても OK だったと思います。 1.should_equal 1 Fixnum#equal を呼び出してます。上記の例では下記の判定
ABD飲み会実施しました - moroの日記
羽生さんはじめ、出席してくださった皆様、ありがとうございました。おかげさまで無事に開催できました。 今回は羽生さんがABDについてまとめてくださった資料をいただいたんですが、それを見ながらお話を聞いて、これまでの理解がそれなりに正しかったことを確認できました。ただ、実戦投入はまだ早いかもしれないという由、確かに前にちょっとだけ試した感じでは、(少なくともRailsでは)まだ難しい感はありました。ERDレッスンがちょうど良いというのも実感してます。 で、Rails界隈の人がABDに興味津津なのは何か不思議、という話を高井さんがおっしゃってたんですが、それはたぶんRailsではDB設計の部分がすっぽり抜けてるんですよね。 「DBのデザインを決めたらあとはカッコよくいけるよ」というDavidさんですが、じゃあどうやってデザインすんのよ、と。いい替えると、他の部分が楽になりすぎたので、必然、残りの
Seasar Conference 2006 Autumn行ってきました - moroの日記
最近Javaづいてるから〜というのとは決して関係なく、SC2006/Autumnに行って来ました。自分なりの感想を。 イベント自体の感想 やっぱりコミュニティの色が出るのか、かなりイベント然としたイベントでした。うまくはいえませんが。明確な言葉にはまとめられてませんが、来年のRK7なんかでも参考になることがありそうな感じ。 あとはだいぶアウェーかなぁ、と思っていたんですが、見知った顔がいっぱいいたので安心でした。うん。 ちなみにメイドブースを探してたのは会場が乾燥してて飲物が欲しかったからですよ＞ヤドカリの人 ちょっと私用でパネルと懇親会にはでなかったんですが、いろいろと違った文化に触れられて楽しかったです。 あと、プレゼンする方々のMac率の低さにびっくりしました。 Seasar2.4 ちょっと遅れて途中から聴講。ナマのひがさんを初めて拝見しましたが、カッケーですね。 Hot deplo
moroの日記 - Railsでテストを書く勘所
昨日はOSCに行ってきました。セミナーやブースはほとんど行かず、例によってRubyの会のあたりでだらだらしてたわけですが。 思いがけず師匠の師匠、id:t-wadaさんにもお会いできてびっくり。 で、そこでRailsとTDD(BDD)の話なんかしたので、一週間で思ったことをつらつらと。たぶん不正確というか、理解の足りないところもいろいろあるので、そのへんのツッコミをいただけると感謝です。 書いてたら長くなったのでagenda モデルのテストでは、とにかくロジックを書いたらテストを書く*1。def..endブロック(wを書いたら必ずテストもあるはず。 RailsのMVCコンポーネントの中では一番テストし易いので、そういう意味でもモデルを厚くすると幸せになりやすい。 コントローラのテストでは、基本的にリクエストを受けてから表示対象のオブジェクトを導出するまでをテストしたい。 ビューのテストでは
ABDとRailsと。現状の理解。 - moroの日記
ちょっと最近まじめにABDとRailsをいじっていて、いくつか気づいたことのメモ。今まで気づいてなかったのかよ、と突っ込まれそうなこともたくさんありますが。 ActivityとEventとResourceは鼎立するわけでなく、Activity:(Event:Resource)と言う分類。Activityは他に比べて特異なもの。 関連テーブル/交差エンティティの役割を果たすわけで当然ですが、Activityは一つの業務の塊の中で複数レコードできますよね。 一つの業務を見るときの入口はActivityじゃなくEventかも。 Railsでいえば、DBヘの書き込みは、イベントをsave!したうえで、has_manyの:throughな交差エンティティ(Activity)を必要な個数分save!する、というのをAR::Base.transaction{}の中でやればOK。 もちろん毎回書くの繁雑な
RailsとABDとCRUDとワークフロー - moroの日記
羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと＝イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ
日本Rubyカンファレンス2006 二日目 - moroの日記
二日目も大盛況のうちに終了。熱かったです。盛り上がった。 DHHのActiveResourceの話なんてスタンディングオベーションものでしたし。 "素敵だな"と思ったことをチラシの裏*1に書き留めていたので、感激備忘録として書き留めておきます。詳細かつ客観的なログはYuguiさん始め他の方々に期待。 全体の感想としてはとにかく楽しかったです。スタッフの方、発表者の方、本当にありがとうございました。 来年こそは*2なんか喋るなりスタッフになるなりします。是非。 たださん「Ruby anywhere 〜Ruby普及のためにアプリケーションができること」 初めて拝見しましたが、たださんカッコイイ。プレゼン中の立ち振舞が渋かったです。 「普及を目指すのはカッコ悪いですか？」普及は善という考えに同意。自分を含めてみんながもっとハッピーになれるはず、と信じていることを着実に推し進めていきたいです。 咳
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
