Rails 3.0 beta

Opublikowane przez Jarosław Zabiełło Wed, 24 Feb 2010 02:30:00 GMT

Muszę przyznać, że wydana parę tygodni temu wersja beta Ruby on Rails 3.0 wygląda bardzo obiecująco. Choć to dopiero beta, to wprowadzone razem z nią ulepszone zarządzanie gemami za pomocą Bundler'a robi dobre wrażenie. Aby ułatwić sobie eksperymentowanie z nowym RoR 3.0, najlepiej zainstalować wpierw RVM...

RVM (Ruby Version Manager)

RVM (http://rvm.beginrescueend.com/) wprowadza nową jakość do niezbyt wygodnego zarządzania wersjami Ruby’ego jakie było do tej pory stosowane. Pozwala na instalację, izolację i błyskawiczne przełączanie się między różnymi wersjami (i implementacjami!) Ruby’ego – od stabilnych po rozwojowe, od Ruby 1.8.0 po 1.9.2 preview1, JRuby, IronRuby, MacRuby (dla OS-X), MagLev czy Rubinius.

  • rvm list known – wyświetli listę wszystkich dostępnych instalacji
  • rvm install 1.9.1 – zainstaluje Ruby 1.9.1
  • rmv use 1.9.1 --default – ustawi Ruby 1.9.1 jako domyślną wersję (dla nowej konsoli)
  • rvm use system – powróci do ustawień systemowych
  • rvm help – wyświetli dostępne komendy
     
$ rvm install 1.9.1              
$ rvm use 1.9.1
$ which ruby
/Users/adm/.rvm/rubies/ruby-1.9.1-p378/bin/ruby 
$ which gem
/Users/adm/.rvm/rubies/ruby-1.9.1-p378/bin/gem

Instalacja i przełączenie się na najnowszego JRuby’ego:

$ rvm install jruby-head
$ rvm use jruby-head

$ which ruby
/Users/adm/.rvm/rubies/jruby-head/bin/ruby

$ which gem
/Users/adm/.rvm/rubies/jruby-head/bin/gem

$ ruby -v
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2010-02-23 944db04) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_17) [x86_64-java]

Powrót do Ruby 1.9.1:

       
$ rvm use 1.9.1
$ ruby -v
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.2.0]

Proste i wygodne. Nigdy więcej paskudnych nazw typu ruby1.8, ruby1.9, gem1.9 itp. Koniec też z niespójnością skryptów które mają taką samą nazwę ale różną linijkę shebang (wskazującą jaki interpreter Ruby’ego należy użyć dla odpalenie skryptu).

Zobacz też screencast Rails 3 Beta and RVM.

Uwaga: w wypadku używania RVM nie należy używać komendy sudo (dla systemów POSIX) gdyż wszystkie wersje Ruby’ego wraz ze swymi gemami są instalowane w katalogu domowym użytkownika ~/.rvm.

Updated 2010-02-28:

W wypadku korzystania z wersji rozwojowych, np. jruby-head lub maglev-head, aktualizacja do najnowszej wersji polega na usunięciu i zainstalowaniu danego interpretera Ruby’ego. Ta operacja jednak nie wymaga reinstalacji gemów bo nie są one kasowane.

       
rvm remove maglev-head
rvm install maglev-head

Rails 3 i bundler

Instalacja bety Rails 3.0 jest prosta. Zakładając że mamy wiele wersji Ruby’ego, i wiedząc że Rails 3 wymaga Ruby w wersji minimum 1.8.7, cała instalacja sprowadza się do krótkiego polecenia:

gem install rails --pre

Z tego co sprawdziłem, nie ma już potrzeby instalowania całej listy wcześniejszych gemów, jak to podawano na oficjalnym blogu Rails.

Razem z instalacja Rails 3 beta zostanie zainstalowany gem bundler. Od tego momentu, można używać skryptu bundle zamiast gem. W Rails 3 zależności między gemami dla aplikacji są ustawianie w pliku Gemfile. To jest główne miejsce gdzie są ustawiane wszystkie zależności. Jeśli nasza aplikacja potrzebuje do swej pracy jakiegoś konkretnego gemu, to tam należy to sobie dodać. Wybrane komendy:

  • bundle check – sprawdzi czy nie brakuje nam jakiegoś gemu niezbędnego do działania aplikacji RoR3
  • bundle install – instaluje wszystkie gemy niezbędne do działania aplikacji RoR3
  • bundle lock – “zamraża” gemy potrzebne dla aplikacji RoR3 tworząc plik Gemfile.lock. Nie jest możliwe instalowanie gemów (wcześniejsze )
  • bundle pack – kopiuje gemy potrzebne do aplikacji do vendor/cache
  • bundle show – wyświetli listę gemów używanych przez aplikację RoR3
  • bundle install --relock – instaluje najnowsze (jeśli trzeba) wersje gemów i ponownie zamraża listę gemów.

Wczesniejsze komendy rake rails:freeze:gems czy rake rails:unfreeze nie są zalecane. Zamiast nich należy używać bundler’a.

Zobacz też screencast Bundler.

Rails 3 – zmiany

Poza większą wydajnością i modularnością, w Rails 3 wprowadzono szereg innych zmian i ulepszeń. M.in. zlikwidowano grupę skryptów z katalogu script/ i zastąpiono go jednym – rails. ActiveRecord, dzięki nowemu gemowi http://github.com/nkallen/arel uzyskał bardziej obiektową składnię oraz opóźnione (lazy) wywoływanie połączeń z bazą. Dane są pobierane z bazy dopiero w momencie kiedy są potrzebne. To ułatwia ich buforowanie, składanie z warunków oraz testowanie. Nowy AR doczekał się, wzorowanego na Sequelu, polecenia .to_sql dzięki któremu można wyświetlić generowany kod SQL przed jakimkolwiek połączeniem z bazą. Zobacz też screencast Active Record Queries in Rails 3.

Rails 3 wspiera również tzw. nieiwazyjny JavaScript (czyni to za pomocą składni z HTML5) dzięki czemu helpery widoku nie generują już więcej wstawek JavaScriptu w kodzie HTML. Łatwiej zatem przełączyć się z (domyślnego) Prototype na inną bibliotekę, np. jQuery.

Wspomniana wcześniej modularność Rals 3 to też silna strona nowej wersji tego frameworka. Każdy wcześniejszy główny moduł składający sie na Rails został gruntownie przebudowany i odizolowany. Rails 3 nie posiada znanych z wersji 2.x zależności frameworka od Active Record. Zarówno Active Record jaki i Action Controller czy Action Mailer są niezależnymi modułami które można sobie wyłączyć lub wymienić (np. teraz jest łatwiej wymienić Active Record na inny ORM). Z perspektywy Rails 3 wszystkie te moduły są nowymi pluginami (zobacz Railtie). Rails 3 wprowadził także montowalne aplikacje. Każda aplikacja Rails 3 może być użyta jako komponent wchodzący w część kolejnej aplikacji Rails 3. W zasadzie to nie dotyczy tylko Rails 3 ale dowolnego frameworka zgodnego z webowym interfejsem Rack. Tzn. w Rails 3 można wpiąć sobie w wybrane adresy URL zarówno inna aplikację Rails 3 jak i Sinatrę, Merba, Ramaze czy inny framework zgodny z Rack (teraz praktycznie wszystkie są z tym zgodne).

Dokładniejsza lista zmian jest dostępna na

Zobacz też artykuły Yehuda Katz’a na blogu oraz na stronach firmy Engine Yard:

Tagi , , , ,  | 6 comments

Comments

  1. Avatar Jan Koprowski powiedział about 6 hours later:

    Jarku – czy Rails 3 dorównał już Merbowi? Czytając Twojego blipa mam silne wrażenie, że Merb nadal wiedzie prym w dziedzinie Rubowych frameworków, jednak jak się domyślam nie będzie już rozwijany a jakość Rails nadal pozostawia wiele do życzenia :/ Wciąż zastanawiam się czy pierwszą aplikację webową z użyciem Ruby napisać w Rails czy Merb :/ Możesz jakoś rozwiać moje wątpliwości?

  2. Avatar Dentharg powiedział about 9 hours later:

    Hej! Czy zamierzasz pisać aktualizację książki by opisywała v3?

  3. Avatar Piotr Sarnacki powiedział about 14 hours later:

    Jan Koprowski: Nie wiem co Twoim zdaniem pozostawia wiele do życzenia w rails 3 (konkrety!), ale w merbie też było dużo niedociągnięć. Nie ma co się zastanawiać, tylko wybierać railsy (chyba, że kręci Cię pisanie w “martwym” frameworku)

  4. Avatar Jan Koprowski powiedział about 18 hours later:

    Railsy nie są jeszcze “Zabiełło certificated” a Merb jest :D

  5. Avatar Jarosław Zabiełło powiedział 1 day later:

    Jan Kaprowski: Jeśli to ma być pierwsza aplikacja webowa w Ruby to bierz Rails 2.3.5. Głownie dlatego, że jest stabilny, masz do tego dobre IDE (RubyMine, Netbeans, RadRails) oraz co jest b. ważne – masz bardzo dobrą dokumentację, jest pełno książek itp.

    (Rails 3.0.0.beta (jak i Merb 1.1.pre który też używa bundlera i instaluje się podobnie do RoR3: gem install merb --pre) są raczej dla tych co już trochę znają Ruby’ego, lub po prostu nie boją się eksperymentować. Ale raczej bym od nich nie zaczynał pisania swojej pierwszej aplikacji webowej w Ruby z powodów j.w.)

    Nie sprawdzałem jeszcze w ogóle nowego Merba 1.1.0.pre oraz nie skończyłem sprawdzać RoR 3.0.0.beta. Ale z tego, co na razie odkryłem, to nie wiem czy wcześniejsze zapowiedzi że RoR3 to to samo co Merb2 będą prawdziwe. Przydałaby się jakaś oficjalna odpowiedź od Yehudy.

    Np. kwestia renderowania odpowiedzi. RoR3 trochę poprawił sposób generowania odpowiedzi dla różnych nagłówków MIME, ale nadal ma ten swój wyjątek DoubleRender odziedziczony po RoR2. Merb w ogóle takich problemów nigdy nie miał, bo po prostu ostatnie wyrażenie z akcji kontrolera jest od razu zwracane do przeglądarki. Ułatwia to składanie komponentów (z których każdy może niezależnie renderować odpowiedź). Z drugiej strony RoR3 ma Railtie i wbudowane Engines, ale jeszcze nie sprawdzałem jak to działa w praktyce.

    Wiele rzeczy którymi chwali się Yehuda odnośnie RoR3, były od ponad roku obecne w Merbie, więc to jest progres ale bardziej względem RoR2, a nie Merba1. Np. kwestia wymiany ORM’a czy biblioteki do testów. Merb od początku był projektowany modularnie i to nigdy nie było problemem. RoR3 niby może pracować z RSpec, ale trzeba zaczekać na RSpec2, bo RSpec1 nie działa poprawnie z RoR3.

    To, że RoR3 pozwala na wpięcie innej aplikacji RoR3 (lub Sinatry, Merba czy innego rackowego frameworka) pod zadany adres URL to też nic specjalnego. Podobną funkcjonalność od zawsze miało Django. A i w RoR2 łatwo to zasymulować poprzez parę prostych regułek w serwerze HTTP. Bardziej mi brakuje Parts niż mountable applications. Lub lepiej, czegoś takiego co mają pythonowe Mako Templates (gdzie nie tylko można składać ze sobą snippety, to każdy z nich może mieć niezależne reguły buforowania)

    Piotr Sarmacki: Merb nie jest martwy, wychodzą nowe wersje (np. Merb 1.1.0.pre też korzysta z bundlera). Merb się więc rozwija, ale nie wiem z jakiego powodu, stara strona domowa nie informuje o tym że projekt jest kontynuowany w innym miejscu: http://github.com/merb. Gdybym miał robić jakąś bardziej złożoną aplikację w Ruby, to pewnie bym użył Merba1 a nie RoR2, bo RoR2 po prostu jest wolniejszy i ma słabsze możliwości.

    Dentharg: nie wiem czy będę pisał aktualizację do RoR3. Samo pisanie książki zajmuje kupę czasu i jest kompletnie nieopłacalne finansowo. Ale mam jeszcze umowę na drugą książkę (w zamierzeniu miała być bardziej konspektem niż pełną książką) i dogadałem się aby uwzględnić RoR3. Tylko, że RoR3 dopiero co wydano (i to betę, więc jeszcze coś może się zmienić), a opóźnienie jest wielkie w stos. do pierwotnych ustaleń… Zmian w RoR3 jest też co niemiara, właściwie muszę przepisać to, co miałem od nowa. Różnie z tym może być.

  6. Avatar Marioosh powiedział 2 days later:

    Chciałbym dodać tylko, że możemy w rvm zrobić sobie tzw. gemset, czyli zestaw gemów, z którego w danej chwili będziemy korzystać. Wobec tego łatwo sobie dla danego interpretera zrobić dwa sety: jeden dla wersji stabilnej railsów a drugi dla wersji beta. Nie ma strachu, że coś się pochrzani. rvm gemset create rails3beta – tworzenie, a przełanie się potem na taki gemset: rvm use 1.9.1%rails3beta.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz