Moje spostrzeżenia i uwagi na temat nowej wersji, o której wcale nie jest tak głośno w sieci jak się spodziewałem. A ta wersja akurat jest tego warta.
http://blog.altsabon.com/ruby-on-rails-22-a-nawet-222/
Mnie akurat ten release nie powalił, bo nie ma nic zmieniającego moją pracę:
JRuby nie używam (nie planuję), takoż 1.9 (to już planuję 
),
migracje nigdy mi się nie posypały w połowie,
i18n jest niedorobionym wciągnięciem globalite (którego i tak za bardzo nie lubię) i zaledwie zapowiada łatwiejszą pracę z dobrymi pluginami do internacjonalizacji,
dokumentacja wystarcza taka jak jest teraz (google skills!),
cachowanie widoków i tak w większości sajtów z dynamiczną zawartością nie będzie stosowane,
warunki w złączeniach wolę jednak w postaci “tabela.pole = cośtam”,
find_last_by jest tak małe i słabe, że aż wstyd robić z tego ficzer,
helpery #second-#tenth to żenada obśmiana przez chyba wszystkich na Reddicie.
Szkoda że nie wspomniałeś o tym, że 2.2 są thread-safe i idącemu za tym wprowadzeniu puli połączeń z bazą - to akurat może sporo zrobić dla Railsów, może nie w sensie istniejących setupów, co przynajmniej PR (obśmiewano railsy za thread-unsafeness).
Ogólnie skok 2.0 -> 2.1 był o wiele bardziej rewolucyjny i przyjemny dla programistów 
Tomash:
Ja bym się nie zgodził z tym, że i18n nic nie wnosi. Wsparcie dla i18n po stronie frameworka, to bardzo duży plus - wcześniej te wszystkie pluginy, to był jeden wielki hack wpinający się gdzie można w kod railsów. Oczywiście jeżeli ktoś chce czegoś więcej, to i tak zainstaluje sobie globalize2, czy jakiś inny plugin, ale spójrz na kod tych pluginów teraz, a na kod tych starszych wersji. Jest naprawdę dużo lepiej.
Swoją drogą wrzuciłem swoje ostatnie eksperymenty w plugin, strasznie wkurzało mnie, że muszę po polskiemu klepać każdy komunikat błędu oddzielnie, albo pisać jakieś twory typu “tytuł nie może być puste”, albo “tytuł nie może być pusty/e/a”. Genderized: http://github.com/drogus/genderized/tree/master Kilkanaście linijek kodu, a ile przyjemności Dodatkowo plugin ma w zależnościach gema russian, co załatwia od razu polską pluralizację.
Z tym thread-safe to takie bardziej na siłę było zrobione, więc to pominąłem. Pula połączeń z bazą w sumie może być w pewnych przypadkach dość ważna, mogłem to dodać, ale też pominąłem.
i18n nie nazwałbym jednak niedorobionym. Nie możesz mieć wszystkiego we frameworku. A to co jest teraz, jest dostatecznie dobrą bazą początkową, więc pod tym względem ten release jest ważny.
A tak w ogóle to ktoś wie lub doczytał się o co chodziło z tym #second-#tenth? Bo ja nie widziałem tych dyskusji ani nie znam argumentacji stojącej za wprowadzeniem tego, a sam na cokolwiek sensownego za cholerę nie mogę wpaść.
DHH tłumaczył, że na przykład w konsoli tego często używa, w kodzie też czasami mu się zdarza.
Ludzie byli podzieleni na “co za syf, zaśmieca framework”, “właściwie co to za różnica” i “a mi się podoba, bardzo fajne ułatwienie”.
Ogólnie wytworzyła się długa dyskusja pod commitem na githubie, ale github w tym momencie ma przerwę, więc nie zarzucę linkiem.
W sumie nie ma to znaczniea, to samo bylo z default_scope, nie trzeba uzywac, pewnie niektorzy znajda zastosowanie a inni beda psioczyc.
Co do l18n to wnosi to bardzo duzo poniewaz API zostalo tak aprojektowane aby mozna bylo w latwy sposob rozszerzyc mozliwosci w zaleznosci od backendu jaki bedziemy stosowac. Tomash zajrzyj do kodu gettext’a do rails, to jeden wielki MP, dzieki l18n w rails 2.2 kod stanie sie znaczne znacznie prostrzy.
O, a o tym na reddicie nawet nie wiedziałem
To stąd tyle komentarzy na githubie pod commitem (i mi szkurde zaśmiecają dashboard zbóje jedne).
Środowisko redditowe (konkretnie programmit reddit) jest doskonałe - banda inteligentnych trollujących programistów, mój ulubiony typ 
(wiecie, Zed Shaw, te okolice )
Cos jak #rubyonrails.pl ;-)))
Aż chyba odświeżę Chatzillę / znajomość z IRCami, bo mi smaku narobiłeś
Zapraszamy ;]