UIE Japan Staff Blog

*二日目 ================================================== * 「Ruby anywhere ～Ruby普及のためにアプリケーションができること」 ただただしさん(tDiaryの作者) ================================================== *本日の内容に関する注意点 -昔話です。 -技術的な話ではありません。どちらかというとマーケティング。 -一般的な話ではありません。 *普及ということ 普及に対してなぜか消極的なコミュニティ。平和主義者が多いから？ 普及を目指すのはかっこ悪いか？　そんなことはない。 *場所への普及と人への普及 :場所:あらゆるレンタルサーバに最新のRubyが入っているとか、LinuxディストリビューションにRubyのパッケージがあるとか。 :人:ライブラリやアプリケーションが増える。Rubyのお仕事が増える。 アプリケーションで場所と人の両面から普及を目指す。 *tDiary Web日記システムtDiary。2001年=BR((before rails))3年誕生。tDiary開発の狙いは日記コミュニケーションを加速すること。コミュニケーションのことなら貪欲にやる。ツッコミ、いわゆるコメント機能。リンク元表示。HTTP_REFERERを集計しページ内に表示。一種のTrackBack。携帯電話からの投稿、閲覧にデフォルトで対応。今は当たり前だが当時からやっていた。 *テーマ デザインをCSSに分離し、テンプレートを固定。CSSをユーザー間の共有財産化。テーマが300個以上。Blog,Wiki,はてな,ゆびとま、MyWikiなどの他のアプリでも利用。普通の人にアピール。普通の人重要。 *当時の時代背景 Rubyが使えるレンタルサーバは片手で済むくらい。Ruby関連書籍がようやく増え始めた。CGIと言えばPerl。そういう時代。知名度も環境もまだまだ。Rubyで何か書いても使ってもらえない。場所を増やすには、魅力的に見えるアプリケーションの登場が必要。使いたい人が増える。インストールする業者が増える、という良循環が起こる。 そのためにはEasy to Install。Ruby入れてもらうのも一苦労なのに、その他のライブラリを要求するなんて問題外。ERBだけが問題だったが、tDiaryのパッケージにERbLightを同梱させてもらうことで解決。のちに標準添付ライブラリに。 *露出を増やす 急にユーザが増えると、はやっているかのような錯覚を与える。tDiary.Netというレンタルサービス開始。一気に数百人のユーザを獲得。急速に目立つようになる。制約を嫌って流出する人もいたが。人を増やすために、プログラミングでもしてみようかという気にさせる簡単なプラグインにした。TDiary::Pluginのインスタンスにinstance_evalするだけで、名前空間の分離なし。実行順序がファイル名依存（ださい）。しかし思い切り敷居を下げることの方が重要。Rubyプログラミングを学ぶプラットフォームとして雑誌記事になった。 *まとめ 普及は善。場所を増やせ。人を増やせ。 *next -Railsは人を増やす戦略がうまい。 -Railsが使える場所はまだまだ少ない。 -Rails普及を促すアプリケーションの登場を期待。 *質疑 Q.テンプレートをユーザが変更できるのは危ないのでは？tdiary.netのような用途では。 A.当時は軽いテンプレートエンジンがなかったので、ERBを採用したが今なら別の選択をするだろう 。 Q.パスワードの管理を.htpasswdではなくwebベース等簡単にできないか？ A.httpdにまかせられるものはまかせる方針でベーシック認証にした。一般ユーザがベーシック認証のダイアログを見ると引くことは知っている。.htpasswdを書き換えるwebインターフェイスを誰かが作れば良いかもしれない。 ================================================== *ActiveRecord を詳しく 西 和則 (ヽ( ・∀・)ノくまくまー) ================================================== スピーカーの西さん自身がものすごく楽しでる印象をうけたセッションでした(笑 流れ -for Ruby users エラー内容をデータベースに保存するとかすると便利。 find_or_create_by_#{カラム名}ですでに存在する場合は、select, 存在しない場合は、insertを発行してくれる。 -for Rails users ARのwith_scopeを使えば、テーブルの操作対象を限定できますよ。不正な操作の防止にも使えるかも。 with_scopeで条件が衝突した場合は、findの場合は条件を追加, createの場合は、with_scope優先。 -for Rails developers scoped_accessプラグインを使えばコントローラのアクション全てにwith_scopeを適用できる。 ActiveRecord.allow_concurrensyをtrueにしていないとスレッドセーフでなくなるので注意。（Rails1.1ではデフォルトがfalse）

class ActiveRecord::Base def self.acts_as_view(options) scoped_methods << MethodScoping.new(options) end end class ActiveGrade2Member < ActiveMember acts_as_view :grade=>2 end

とクラスメソッドを定義すれば簡単に定義できてしまう！ すばらしい。 生成したSQLを文字列で受け取るメソッドがほしい 実行前のSQLをダンプする。サブクエリに便利。 ================================================== One controller, many ins, many outs David Heinemeier Hansson ================================================== DHHオトコマエ！ プレゼンもうまくて非常に盛り上がるセッションでした。 **REST HTTPメソッドだけでCRUDできるよね。複数個所に分かれているのはDRYじゃないし、

POST /people GET /people/1 PUT /people/1 DELETE /people/1

map.connect ':controller/:id'と宣言しておく。 form_forでmethodを定義 ブラウザのformでputやdeleteできないのでmethodはhiddenで渡す (javascriptで～～と言いかけて訂正していたのでjsのputやdeleteも使うようになるのかも) また、CRUDはゴールでなくゴールを目指す肝であり設計の技法ですよ。 **has_many :throughを使って交差エンティティを表現 多対多は取り除こう。 def join_users() endとかdef leave_group() endというメソッドはよろしくない。 **一つのコントローラで複数のMIMEタイプに対応してあげよう 拡張子、request.evn["Accept"]で判断して、respond_to {|format|}で返せばOK 携帯電話等は、before_filterでUAやIPで判断しmimetypeを追加 **ActiveResource DHH > 「XMLRPCもSOAPも使いたくない」 Rails1.2のtrunkにもまだ上がっていない様子のActiveRecordからCRUDを操作できるActiveResourceの話が面白い。URLをモデルの中に隠蔽して後は気にせず、AR同様に使うことができる。認証周りは、HTTP Authentication, Digest認証, SSLを誰かが作ってくれるかも。

Person = ActiveResorce::Struct.new do |p| p.uri "http;//www.example.com/people" p.credentials :name => "dhh", :password => "secreat" end david = Person.new(:name => "David") # GET http://www.example.com/people # David # => Location: http://www.exapmle.com/people/2 david.find(:name => "David") # PUT http://www.example.com/people # David Heinemeier Hasson # => (200 OK) david.save class ActiveResource::Base uri "http://www.example.com" credentials :name =>"dhh", :password => "" end