Jarmark.org

Z końcem września na oficjalnym blogu railsów pojawiła się informacja o nadchodzącej wersji 2.0. Przeskok od wersji 1.0 do 2.0 to zawsze jest trauma i dla projektu i dla jego użytkowników. O zmianach i ZMIANACH w railsach 2.0 mówiło się od jakiegoś czasu. Nie ma się co dziwić - projekt wyrósł z lokalnej anomalii do popularnego frameworka używanego przez wiele serwisów. Zmiany są więc konieczne zwłaszcza, gdy coraz częściej przebąkuje się o enterprajsowych zapędach RoR. Sam także miałem przygotowaną swoją prywatną listę oczekiwań wobec nowych railsów. Dopiero dziś miałem odrobinę czasu i zaległem w wannie, aby na spokojnie poczytać o tym co nadchodzi. Poczytałem i… przyznam trochę się rozczarowałem.

Odnosząc się w sposób subiektywny (jak przystało na zgreda) do poszczególnych akapitów wpisu DHH:

Action Pack: Resources
Rozumiem fascynację koncepcją traktowania aplikacji jako zasobu - przyznam jest wielce atrakcyjna… jako koncept intelektualny. Patrząc na fascynację railsowców tą koncepcją trochę mam wrażenie deja vu. Pamiętacie? Czyż to nie XML, XML-RPC, SOAP, WSDL miały być rewolucją na miarę wynalazku pilota do telewizora?? I co? Nic. Developerzy trochę się po podniecali, zmarnowano trochę budżetów, powstało trochę książek, paru konsultantów zarobiło swoje ale życie developera nie stało się łatwiejsze. Patrząc z tym bagażem doświadczenia na podniety jakie wywołuje koncepcja Active Resources dziś, trochę mi zgrzytają zęby. Gdy widzę rozwiązania na siłę budujące RESTfullny dialog przeglądarka-serwer za pomocą wydumanych konstrukcji formularzowo-javascriptowych - myślę sobie - ooo na pewno nie, moja noga tam nie postanie!
Znacie powiedzenie o młotku - mam wrażenie, że w railsach zaczyna pojawiać się takie myślenie - wszystko MUSI być zasobem. Tylko po co? Jasne są sytuacje w których REST Is The Best ale obawiam się, że nie jest ich aż tak wiele.
Patrząc na zmiany w RoR2 martwi mnie trochę to mapowanie wielu kontekstów wykorzystania zasobów do jednego kontrolera. Koncepcyjnie super, ale pomyślmy co szukaniem i rozwiązywaniem błędów w aplikacji z wieloma kontrolerami?! To zaczyna pachnieć średnio przyjemnie. I nie, nie wierzę, że internet da się traktować w niedługiej przyszłości jako Jeden Wielki Zasób :)
Ocena plus ujemny: -1 :)

Action Pack: Multiviews
Proponowane jest przebudowanie sposobu nazywania plików w View - mają być nazywane wg klucza: action.format.renderer - czyli zamiast feed.rxml będzie feed.atom.builder, ale już index.erb jako ogólny. Rozbudowana będzie obsługa wielu formatów (respond_to). Pomysł może być - nie jest to rewolucja - raczej jakaś próba uporządkowania. Zakładając oczywiście, że końcowa wersja RoR 2.0 będzie wyposażona w narzędzia do miłej migracji aplikacji.
Warunkowy plus dodani: +1

Action Pack: Record indentification
No comments. Jazda na zasoby dotyka metod pomocniczych z View redirect_to, link_to itd. Jedno co mogę oddać - przynajmniej utrzymany jest stały poziom amoku zasobowego :)
Ocena - bez emocji: 0

Action Pack: HTTP Loving
No pierwsza rzeczywiście przydatna rzecz. Wygodna obsługa uwierzytelniania komunikacji po HTTP - może wreszcie zacznie się wygodnie tworzyć prywatne feedy które będą za loginem i hasłem. Dziś jedynym zabezpieczeniem jest generowanie absurdalnie długich i asemblerowo wyglądających urli do takich feedów.
Ocena plus dodani: +1

Obsługa assetów
Druga pozytywna grupa zmian. Doświadczenia przeprowadzone przez chłopaków z Yahoo dowodzą, że spore przyspieszenie ładowania aplikacji można uzyskać jeżeli dane (JS, CSS, grafika) dociągane są z różnych hostów (wynika to z ograniczenia w przeglądarkach - na raz z jednego hosta ciągnięte są dwa ’strumienie’ danych) - teraz railsy będą wspierały obsługę wielu adresów wskazujących na te same pliki.
Czyli nie jest źle, ale liczyłem na znacznie więcej - miałem nadzieję na mechanizm który umożliwi wygodne rozdzielenie np JS z poszczególnych części aplikacji od siebie nawzajem oraz od biblioteki wspólnych funkcji. Taki podział znacząco ułatwia utrzymanie kodu (bez znaczenia czy to JS czy CSS)
Ocena: 0 dobry początek ale gdzie reszta??

Action Pack: Security
No nareszcie implementacja request tokenów wbudowana w sam framework. Zmienione ma być też beznadziejne działanie metody sanitize zamiast zakazów będzie white lista - tak powinno być od dawna!
Bezpieczeniej więc +1

Action Pack: Exception handling
Możliwość obsługi wyjątków zadanego typu przez wskazaną metodę (per kontroler). Bardzo przyjemny pomysł - koniec z gmeraniem w rescue_action_in_public
Pozytwnie: +1

Action Pack: Miscellaneous
Rozbudowa obsługi formatu Atom. Myślę, że to dobry ruch zwłaszcza, że Google buduje swoje API używając zmutowanego Atoma (GData). Powinno to ułatwić budowę połączeń pomiędzy aplikacjami - internet jako zasób? :)). Zmiana głowy nie urywa, ale ogólnie miła dla oka.
Ocena: +1

Active Record: Performance
Nooo tu się poważnie rozczarowałem. Miałem cichą nadzieję, że ORM railsowy ulegnie istotnemu rozwojowi. Tymczasem dodana jest obsługa cache’a dla SQLi - rzuciłem okiem na kod i khm khm nooo nazwa Cache to brzmi dumnie - liczyłem na coś lepszego niż hash z kluczem w postaci SQL a wartością w postaci obiektów. Owszem będzie to działało tylko co jeżeli aplikacja wykonuje raz na dobę zapytanie o milion rekordów….
Ocena: -1

Active Record: Sexy migrations
Zmiana w sposobie definiowania recept migracyjnych - zamiast t.column ‘name’, :string bedzie t.string :name. Jakoś nie specjalnie mnie to podkręciło - aplikacja to jednak nie tylko migracje, więc to jak się je opisuje nie ma wielkiego znaczenia. A jeszcze jedno, każda rozrastająca się aplikacja i tak traci swoją bazodanową niezależność (zauważyliście? przenośne miedzy bazami są tylko proste przykładowe aplikacyjki, jak zacznie się prawdziwa walka to kończy się ta uniwersalność)
Ocena: 0

Active Record: XML in, JSON out
Możliwość inicjalizacji obiektów modelu danymi w XML. Może być przydatne (w połączeniu z różnymi API zewnętrznymi które korzystają z XML jako formatu danych).
Ocena: +1

Active Record: Shedding some weight
Pomysł z wyjęciem wszelkich acts_as_xxx z kodu i umieszczeniem jako pluginy chyba nie jest zły. Choć zastanawiam się nad tymi nerwami które będą się napinały podczas walk z niedziałającym modelem - bo zapomnieliśmy użyć install acts_as_list. Ale ogólnie to chyba jednak dobry ruch. Wyrzucenie adapterów do baz innych niż PostgresQL, MySQL i SQLite do pluginów to zdecydowanie dobry ruch.
Ocena: +1

Active Record: with_scope with a dash of syntactic vinegar
Metoda with_scope zmieniła widoczność - stała się protected. Uzasadnienie mnie przekonuje. Sam korzystam z niej intensywnie ale tyko w obrębie modelu.
Ocena: +1

ActionWebService out, ActiveResource in
Zasobowej jazdy kolejne wcielenie. Ciężko mi być tu szcześliwym. Chciałbym mieć wybór - realnie patrząc już go nie będzie - jak pisze autor w wojnie SOAP vs REST railsy już wybrały stronę. A szkoda.
Ocena: -1

ActiveSupport
Skoro nie ma wielu zmian, nie ma też co oceniać.
Ocena: 0

Action Mailer
Także żadnych wielkich zmian nie ma.
Ocena: 0

Rails: The debugger is back
Dobry ruch. Dalej nie jest to okienkowy :) debugger (korzysta z gema ruby-debug) ale już znacznie lepiej niz sama konsola IRB.
Ocena: +1

Rails: Clean up your environment
Uporządkowanie sposobu konfigurowania aplikacji. Zamiast puchnącego environment.rb jest katalog config/initializers w którym umieszczane mogą być własne konfigi. Problem mi doskwierał - dlatego powstał AppConfig - rozwiązanie z katalogiem to krok w dobrym kierunku ale za mały. Brak mi konfigurowalności takiej jaką daje AppConfig czyli oprócz inicjacji konfiguracji dostęp do konfiga w aplikacji.
Ocena: 0

Rails: Easier plugin order
Czytając o tej pluginizacji poszczególnych elementów frameworka już myślałem że to koniec. Problem z kolejnością ładowania pluginów już trochę przypomina jazdy z JARami pod Cocoonem 1 (zmieniało sie xml.jar na zml.jar zeby ładował się na końcu:)) Na szczęście kolejność ładowania pluginów będzie można wskazywać. Ufff
Ocena: +1

Podsumowanie
Nie, nie będzie tabelki z podsumowaniem ocen - jestem zbyt leniwy :) Patrząc na oceny widać jednak więcej plusów niż minusów - skąd więc moje rozczarowanie? Sądziłem że zmiany pójdą w kierunku upraszczającym/porządkującym tworzenie większych aplikacji (na równi z małymi/średnimi). Niestety - lista zmian to raczej tuning plus promocja RESTa.
Moja własna lista życzeń wobec railsów wygląda tak:

• dla Active Record
  
• usprawnienie działania i wydajność ORMa np. przez wprowadzenie prawdziwego 2nd Level Cache (wzorem może być tu Hibernate)
• ponieważ tworzenie obiektu w Rubym jest operacją kosztowną ciekawym podejściem byłoby użycie puli obiektów dla danych z bazy
  
• dodanie abstrakcji do tworzonych zapytań - sam robiłem małą przymiarkę do tego problemu, później odkryłem ez_where, a ostatnio pojawił się jeszcze Ambition
• przyspieszenie działania trybu developerskiego - tu jest ciekawy plugin w temacie - przydałoby się dodanie tego do bazy kodu railsow
• modułowość - mam tu na myśli dwie sprawy:
• wsparcie dla podziału aplikacji na części/moduły które mogą być wykorzystane w wielu miejscach albo tej samej aplikacji albo wręcz różnych - problem jak zauważyłem trapi nie tylko mnie
  
• możliwość budowy UI z komponentów; to już marzenie z górnej półki - ale byłoby miło gdyby Railsy dawały możliwości podobne do Tapestry czy Echo.
• naturalne wsparcie dla I10N - czyli jedno preferowane rozwiązanie ściślej związane z frameworkiem,
  
• dodanie NDC (nested diagnostic contexts) do loggera railsowego. O co chodzi? W skrócie o to aby można było w logach znaleźć zapisy tworzące jedną całość przyczynową-skutkową. Czyli od samej góry czyli wykonania akcji w kontrolerze przez wszystkie warstwy niżej każdy zapis do logów miałby dodatkowe pole (kontekst) pozwalający je razem zgrupować (a kolejność to timestamp wpisu). Więcej szczegółów jest w artykule ‘Patterns for Logging Diagnostic Messages’