Rails 3.1 wydane

To już oficjalne: Rails 3.1 pozbyło się znaczka RC i jest teraz najświeższą wersją frameworka. Prawie rok po pojawieniu się Ruby on Rails 3.0 pora na upgrade. Szczerze mówiąc, ja się przesiadłem gdzieś w czerwcu i owszem, na początku pojawiało się kilka problemów, ale teraz nie pownno już być niekompatybilności z żadnymi (utrzymywanymi) bibliotekami.

Co nowego w Rails 3.1?

Zmiany pracowicie zbierał Ryan Bytes w tym miejscu. Oto najciekawsze z nich:

  • Jquery zostało domyślnym frameworkiem do js. Oczywiście zawsze można ustawić prototype.
  • Również Sass, został domyślnie ustawiony jako narzędzie do generowania CSS. Niestety to samo nie dotyczy Hamla, którego chętnie bym widział jako standardowy silnik w widokach. Nie wiem jakie są inne przesłanki oprócz tego, że DHH nie lubi hamla, pewnie to tylko kwestia gustu.
  • Do pisania javascriptu służy teraz CoffeeScript. Ta zmiana wzbudziła chyba największe kontrowersje w środowisku, ale znów: przecież nie trzeba z niego korzystać.
  • Pliki css, js i obrazki są teraz obsługiwane przez sprockets i zostały przeniesione do katalogu app/assets gdzie otrzymały własną strukturę katalogów. Ładnie zostało to wyjaśnione w tym poście.
  • ActiveRecord zyskał identity map; oznacza to, że pojedyńczy wpis w bazie będzie reprezentowany przez pojedynczy obiekt w Rubym. Poniższy kod w starym ActiveRecordzie zwróci fałsz, w nowym będzie to prawda. Ta zmiana powinna zmniejszyć użycie pamięci Railsowych projektów (ale na cuda nie liczmy).
@parent = Tree.first(:conditions => { :name => 'bob' })

@parent.children.each do |child|
  puts @parent.object_id == child.parent.object_id
end
  • Streaming HTTP powinien znacznie skrócić czas ładownia stron po stronie przeglądarki. Polega to na tym, że wyrenderowane części strony od razu są przesyłane do przeglądarki, a nie dopiero na koniec requestu. Dzięki temu, możliwe jest np. przygotowanie nagłówka i przesłanie go do przeglądarki, przed wyrenderowaniem widoku. Przeglądarka może wtedy zacząc pobierać statyczne pliki (np. obrazki i style) i wyświetlić je od razu gdy dostanie pozostałą część widoku.
  • Odwracalne migracje – mała rzecz, a cieszy. Od teraz zamiast dwóch metod up i down w migracji wystarczy napisać jedną, a zostanie ona odpowiednio wykonana w zależności od tego czy wykonujemy, czy wycofujemy migracje. Magiczna metoda nazywa się change. Nie trzeba wtedy pisać metody down:
  
class CreatePosts < ActiveRecord::Migration
  def change
    create_table :posts do |t|
      t.string :title
      t.text :body

      t.timestamps
    end
  end
end

Podsumowanie

To jest subiektywna lista najciekawszych zmian, widać na niej, że twórcy skupili się na dopieszczeniu assetsów. (Nie wiem jak to przetłumaczyć - jakieś pomysły?) Z minusów, zauważalny jest wolniejszy start aplikacji w Rubym 1.9.2. Bardzo przydatne okazują się sprockets, które wszystkie CSSy i javascripty automatycznie kompresują do pojedynczych plików. Nowe domyślne narzędzia mi się bardzo podobają i już z nich korzystam. Kontrowersje można zbyć stwierdzeniem, że zawsze można je wyłączyć. Z drugiej jednak strony ustawienie w ten sposób domyślnego stosu spowoduje, że dużo programistów (zwłaszcza początkujących) zacznie korzystać z tych narzędzi, stosując się chociażby do zasady konwencji ponad konfiguracją. Pozostaje też pytanie, czy bariera wejścia w Railsowy projekt nie została z najnowszymi zmianami podniesiona zbyt wysoko?



Komentarze

  1. hipertracker 31.08.2011

    Comment Arrow

    Przesłanką aby NIE czynić Haml domyślnym językiem szablonów jest chociażby problem ze kaskadowym przetwarzaniem szablonów. Np. w Erb można stworzyć assets/stylesheets/application.scss.erb. Taki plik jest wstępnie przetwarzany przez Erb, a następnie przez Sass. Nie wiem jak by tu można było użyć Haml zamiast Erb…


  2. Kamil 31.08.2011

    Comment Arrow

    Tutaj ( http://guides.rubyonrails.org/3_1_release_notes.html ) trochę więcej o zmianach 😉


  3. Seban 31.08.2011

    Comment Arrow

    Warto dodać, że HTTP streaming działa tylko na Ruby 1.9. Kolejny powód by się przesiąść na 1.9.x z 1.8.7.


  4. Bragi 31.08.2011

    Comment Arrow

    @hipertracker Dla mnie ERB i Haml to dwa różne zastosowania. Erb to preprocesor a Haml to język szablonów HTML. Dla reprezentacji HTML widziałbym domyślnie Haml, wszędzie indziej ERB może pozostać.


  5. Piotr Sarnacki 31.08.2011

    Comment Arrow

    Czuję się pominięty 😉


  6. tjeden 31.08.2011

    Comment Arrow

    @Kamil To samo jest w pierwszym linku, ale dzięki za wytłuszczenie.

    @Hipertacker Chociaż Twoje wytłumaczenie jakoś do mnie przemawia, to widzę to tak, jak Bragi,

    @Piotr Argh, pokajam się w następnym wpisie.


  7. hipertracker 31.08.2011

    Comment Arrow

    Ależ ja też lubię Hamla, ale rozumiem DHH dlaczego wolał zostać przy Erb i mieć jedną zamiast dwóch składni dla warstwy widoku (Haml nie nadaje się do przetwarzania tych plików scss)


  8. Piotr Sarnacki 31.08.2011

    Comment Arrow

    @tjeden, nie no, bez przesady, tak tylko jojczę 😉


  9. Robert Pankowecki 1.09.2011

    Comment Arrow

    Czy ten przykład dla Identity Map nie działalby aby już przy użyciu opcji :inverse dla has_many ?


  10. tjeden 6.09.2011

    Comment Arrow

    Wygląda na to, że tak. Ale już dla has_many_throug nie.




O autorze

Aleksander Dąbrowski

Od 2008 zawodowo programuje w Ruby i Railsach. Jest maniakiem prostych i eleganckich rozwiązań, nie boi się usuwania brzydkiego kodu. Uwielbia dzielić się wiedzą, a w wolnych chwilach naprawia samochody.