2012-01-10
昨日は、ActionDispatch::Reloader で使われている ActiveSupport::Callbacks のドキュメントを読みました。 今日はそれが ActionDispatch::Reloader でどう使われているのかを追いかけたいと思います。 https://github.com/rails/rails/blob/3-1-stable/actionpack/lib/action_dispatch/middleware/reloader.rb まず定義されているコールバックは、 :prepare と :cleanup の２つです。 どちらも :scope => :name というオプションが指定されているので、コールバックで呼び出されるのがオブジェクトの場合、それぞれ#prepare と #cleanup メソッドが呼び出されます。 で、コールバックを登録するのは、
developmentを実現したいのでコードを読んでみる#2 - akimatter
昨日はRails::Applicationの継承関係をはっきりさせて、初期化のあたりをどうなっているのかRails Guideのドキュメントをみつけてわーいってところまで行きました。 Rails::Railtie <|---- Rails::Engine <|---- Rails::Applicationhttp://guides.rubyonrails.org/initialization.html で、本題は何だったのかっていうと、 ./application.rb:168: middleware.use ::ActionDispatch::Reloader unless config.cache_classesでございます。 初期化周りは上のドキュメントとコードをざっくり読んで分かった気になったけど、実はたぶん分かっていないことが分かってはいるけど、あえて分かったように振る舞ってみる
developmentを実現したいのでコードを読んでみる#1 - akimatter
Railsのdevelopmentモードのように特定のディレクトリ以下のソースコードを適切なタイミングで読み直す機能を作りたいのですが、実際Railsって何やっているのか分からんので調べます。 cache_classes railsアプリの config/environments/development.rb には大抵 config.cache_classes = false と書いてあります。クラスのキャッシュを無効にするって意味っすね。 この設定がどこで使われているのか、railsの設定はrailtiesに書いてあるのでgrepしてみました。 -*- mode: grep; default-directory: "~/.rvm/gems/ruby-1.9.2-head@tengine_console/gems/railties-3.1.3/lib/rails/" -*- Grep st
Rails3.1アプリの本番サーバにJSのエンジンを入れない方法 - akimatter
rails-3.1 いえーい！っていうわけでついついcoffee scriptを使ったんだけど、ステージング環境のRedhatにデプロイしてみたら、画面上で動くはずのJSが動かない。 見てみるとapplication.jsの中身が throw Error("ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes.\n (in /home/tengine/sources/tengine_console/app/assets/javascripts/application.js)")という一行だけ。 で https://github.com/sstephenson/exec
えせMVC？ - akimatter
[Ruby on Railsの「えせMVC」の弊害] というエントリが話題になっているので釣られてみます。 http://satoshi.blogs.com/life/2009/10/rails_mvc.html MVC まず結論から。Railsが本当にMVCかどうかですが、僕は真っ当なMVCだと思います。 MVCが指すもの 例のエントリの次のエントリ[O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」]で、 MVCのコンセプトは「はやりすたり」とは関係のない良いアプリケーションを設計する上での基本中の基本。Ruby on RailsやJ2EEを使ったウェブアプリケーションにも、Cocoa/UIKitの上のiPhoneアプリケーションにも通じる話だということを覚えておいてほしい。 確かにMVCは重要だけど、「「はやりすたり」とは関係のない」というのは言い過ぎだと思います。
今度こそinstance_evalとmodule_evalを理解してもらった - akimatter
ような気がするのでメモ。 「instance_evalとmodule_evalを理解」というのは特異メソッド、インスタンスメソッドの違いを理解して、 必要に応じてinstance_evalとmodule_evalを使い分けられる、ということかと思います。 なので、ゴールとしては、 block = Proc.new do def foo 'foo' end end というブロックがあったときに、これを使って特異メソッド、インスタンスメソッドを追加できるようになる、ってことでいいのかなと思った。 以下、その前提と問題。答えはきっとid:t-tairaが書いてくれます。 (2010/03/01追記) id:t-tairaさん回答ありがとー http://d.hatena.ne.jp/t-taira/20100227/1267232880 特異メソッドとインスタンスメソッド 特異メソッドは「特定の
2010-02-18
developmentモードとproductionモード 今日チームのメンバーに聞かれて気付いたことですが、developmentモードが便利過ぎるからか、リクエストが来るたびにコントローラのクラスがロードされるように勘違いする人もいるみたいです。 プラグインを作るときにはproductionモードとdevelopmentモードの違いを把握しておかないと、プラグインを作るのに困るので、念のため書いておきます。 考え方としては、基本はproductionモードです。productionモードで各ファイルは基本的に一度しかロードされません。それだとコードを変更するたびに反映させるためにはにいちいちサーバーを再起動させなければならないので、開発時はあまりにも大変なので、Railsのdeveloppmentモードでは特殊な仕組みで、リクエストが来るたびに必要なファイルをロードします。 const_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
