Jak są jacyś chętni do potestowania to z przyjemnością wysłucham uwag.
Esto es muy bueno! Zaraz zobaczę czy rzeczywiście działa, na większym projekcie. Jedno pytanie: czy nie myślałeś żeby zamiast sprawdzać mtime plików, użyć guarda https://github.com/guard/guard ?
Działa na pierwszy rzut oka bardzo dobrze i przyspiesza Railsy niemiłosiernie w developmencie. Przetestujemy w boju i damy znać jeśli pojawią się jakieś błędy.
Podoba mi się też podejście: przeładowywanie całej aplikacji, a nie pojedynczych klas. Kiedyś był jakiś gem który próbował przeładowywać pojedyncze klasy w developmencie, ale tak na prawdę to nie dizałało. Twoje podejście ma znacznie lepsze szanse na powodzenie.
Miałem podejście z watchr (skomplikowane bardzo) opisane tutaj : http://blog.robert.pankowecki.pl/2011/05/get-faster-rails-development.html , później obejrzałem na railscasts o guard i postanowiłem go użyć. Testowałem u siebie w boju ale co jakiś czas przestawało działać (z nieznanych mi powodów, których zdebugować mi się nie udało) i stwierdziłem, że olać to i zróbmy to po filozofi “simplest possible thing that can work” i o dziwo rezultaty są najlepsze z dotychczasowych jak sądze. Jest to bardzo proste i przenaszalne, mogliby to wciągnąć do rails-core. Sprawdzenie mtime 700 plików na moim paroletnim kompie trwa 0.1 sekundy. Być może to rozwiązania z nasłuchiwaniem eventowym jeszcze wrócę, póki co staram się zarysować temat i edukować ludzi, że problem istnieje i praca w trybie development przy dużym projekcie w aktualnym kształcie mocno kuleje moim zdaniem a rozwiązania są w zasięgu ręki. Niedługo pewnie napiszę post na blogu nt tego rozwiązania. Nie jest pewny (a mało się w tej kwesti znam) czy ten mtime nie idzie aby z cache.
Inne konkurencyjne rozwiązania, które coś w tym temacie próbują robić też mi nie działały zbyt dobrze.
Tutaj kod drugiego podejścia i takie tam info : http://blog.robert.pankowecki.pl/2011/06/faster-rails-development-part-2.html
To drugie podejście testowałeś na Linuksie czy MacOS X?
O ile go znam to na linux 
Linux. Czasem po 5 minutach przestawało działać, czasem po pół godziny. Jak przysiadłem, żeby zobaczyć dlaczego tak się dzieje to akurat nie mogłem ani razu buga powtórzyć. Miałem jeszcze takie problemy, że mam stronę która po załadowaniu zaraz wysyła ajaxowy request i zarówno pierwszy hit głownej strony jak i ajaxowy request były wolne bo kod się przeładowywał. W 3 podejściu, które stało się gemem nie mam takich zonków.
Jak rozwiązujesz problem zależności między plikami? Tzn. w jednym pliku wykorzystuję klasę z innego. Zmieniam ten plik, więc on się przeładowuje - ten drugi pozostaje niezmieniony, więc zostaje taki jak był. Nie ma z tym problemów?
Nie ma z tym problemów, gdyż w ogóle się w takie cuda nie bawiłem.
Zamiast
a) Rails way - reload kodu po każdym request
jest
b) Robert way - reload kod przed request jeśli jakiś plik *.rb z autoload_path się zmienił.
Reload tak jak w Railsach oznacza zapomnij cały kod bez bawienia się.
Innymi słowy tak jak wspomniałem zysk masz tylko na tych requestach w trybie development kiedy nic się nie zmieniło. Jak się zmieniło to trwa to dokładnie tyle samo co w Rails.
A jak to działa że jak zmieniasz pliki *erb czy *haml, to zmiany są też widoczne. Czy templates nie są wcale cachowane w trybie development?
Templates’y nie są. Routes’y też mają jakiś swój osobny mechanizm wykrywania zmian. W 3.1 templates’y są cachowane w development ale chyba tylko na czas 1 requestu (głowy sobie uciąć nie dam).
[quote=paneq]Nie ma z tym problemów, gdyż w ogóle się w takie cuda nie bawiłem.
Zamiast
a) Rails way - reload kodu po każdym request
jest
b) Robert way - reload kod przed request jeśli jakiś plik *.rb z autoload_path się zmienił.
Reload tak jak w Railsach oznacza zapomnij cały kod bez bawienia się.
Innymi słowy tak jak wspomniałem zysk masz tylko na tych requestach w trybie development kiedy nic się nie zmieniło. Jak się zmieniło to trwa to dokładnie tyle samo co w Rails.[/quote]
W sumie wykorzystujesz ten sam mechanizm i API, IMHO +1 jako patch do rails master zmoże na 3.1 zdążysz?
Próbowałem z nimi na mailach na ten temat gadać ale opornie to szło więc poszedłem w stronę, która gwarantuje chyba największe prawdopodobieństwo sukcesu. Zrób gem, niech ludzie go używają w takiej liczbie, że trzeba będzie go wciągnać do core 
Na razie staram się zwrócić uwagę świata Rails, że jest taki problem i jest rozwiązanie. Czy się to uda to zobaczymy. Jakby ktoś to przeportował do rails-core to nie miałbym z tym problemu. Nie wiem czy core podałby się fakt sprawdzania co request mtime wszystkich plików. To trochę ugly a z drugiej strony jak widać bardzo pragmatic.
Problem jest zdecydowanie, przy projekcie który ma kilkadziesiąt modeli (41) widać zdecydowaną różnicę, pracuje się po prostu przyjemniej.
Próbowałem z nimi na mailach na ten temat gadać ale opornie to szło więc poszedłem w stronę, która gwarantuje chyba największe prawdopodobieństwo sukcesu. Zrób gem, niech ludzie go używają w takiej liczbie, że trzeba będzie go wciągnać do core Na razie staram się zwrócić uwagę świata Rails, że jest taki problem i jest rozwiązanie. Czy się to uda to zobaczymy. Jakby ktoś to przeportował do rails-core to nie miałbym z tym problemu. Nie wiem czy core podałby się fakt sprawdzania co request mtime wszystkich plików. To trochę ugly a z drugiej strony jak widać bardzo pragmatic.[/quote]
Z doświadczenia wiem że lepiej najpierw zgłosić patch a dopiero później dyskutować czy się może znaleść w repo. To co jest w active_reload ale jako opcja on/off(default off) i bez tych notyfikacji imho powinno się znaleść w rails, nawet w production miało by to spory sens, chociaz nie wiem czy nie było by jakichś regresji.
@hubertlepicki - Mogłbyś powiedzieć ile u ciebie wynosi:
ActiveSupport::Dependencies.autoload_paths.map do |p|
Dir["#{p}/**/*.rb"]
end.flatten.size
?
Notyfikacje są bardziej dla mnie bym widział czy dziala to tak jak trzeba. Dzięki nim właśnie łatwo było mi zauważyć, że czasem wersja 2 rozwiązania przestawała działać. W production nie ma w ogóle code reloading bo jest eager_load robiony na początku by później mógł fork używać COW.
Wiem, ja mówie o odpaleniu production jako development z tym jeśłi się wogóle da.
Będę musiał wypróbować - myślałem, że przeładowujesz tylko te pliki, które się zmieniły
Co do 3.1, to już od dawna jest feature freeze, więc nie ma raczej takiej opcji, ale można będzie ponapierać core team, żeby do 3.2 dorzucić.