Nadchodzi Rails 2.1

Posted by Jarosław Zabiełło Thu, 03 Apr 2008 02:58:00 GMT

Jest bardzo bardzo niewiele książek opisujących aktualny stan Railsów 2.0.2 a już szykuje się kolejna wersja – 2.1 (nawet The Rails Way nie opisuje 2.0.2, ale tylko trochę z wersji edge, sprzed wydania 2.0) Jaką książkę nie zaczęto by pisać, staje się szybko nieaktualna. Co za czasy…

Zmian jest całkiem sporo, do ważniejszych należą różne poprawki w Active Record. Np. w końcu ma być możliwa selektywna aktualizacja wybranych kolumn (do tej pory AR, podczas zmiany jedneego atrybutu aktualizował je wszyskie w bazie) Co prawda tą funkcjonalność od dawna mają DataMapper i Sequel, ale dobrze że AR się wkońcu tu obudził.

article = Article.find(:first)
article.changed?  #=> false

# Zmiany poszczególnych atrybutów możliwe jest za 
# pomocą akcesora attr_name_changed?
article.title  #=> "Title"
article.title = "New Title"
article.title_changed? #=> true

# Jest też dostęp do poprzedniej wartości atrybutu 
# zapomocą akcesora attr_name_was
article.title_was  #=> "Title"

# Zobacz wcześniejszą i późniejszą wartość za pomocą
# akcesora attr_name_change
article.title_change  #=> ["Title", "New Title"]

# Zapis atrybutu wykonuje zapytanie dotyczące tylko jednej, 
# odpowiadającej mu kolumny w tabeli:
article.save
  #=>  "UPDATE articles SET title = 'New Title' WHERE id = 1"

Dodano też coś, co funkcjonalnie “od zawsze” było obecne w Sequel’u, SQLAlchemy czy Django ORM, mianowicie tu nazywa się to named scope (Rails wchłonęło popularny plugin has_finder pozwalając w końcu na łatwiejsze budowanie bardziej skomplikowanych warunków odpytywania bazy).

class User < ActiveRecord::Base
  named_scope :active, :conditions => {:active => true}
  named_scope :inactive, :conditions => {:active => false}
  named_scope :recent, lambda { { :conditions => ['created_at > ?', 1.week.ago] } }
end

# Typowe użycie:
User.active    # to samo co User.find(:all, :conditions => {:active => true})
User.inactive # to samo co User.find(:all, :conditions => {:active => false})
User.recent   # to samo co User.find(:all, :conditions => ['created_at > ?', 1.week.ago])

# Możliwe są w końcu kolejne zagnieżdżenia warunków:
User.active.recent
  # to samo co:
  # User.with_scope(:conditions => {:active => true}) do
  #   User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
  # end

Autorzy Rails pozazdrościli Merbowi i dodali też możliwość ładowania gemów o konkretnej wersji (być może będzie to też początek końca pluginów w obecnej postaci i Rails pójdzie i tu ścieżką Merba?)

Rails::Initializer.run do |config| 

  # Załaduj najnowszą wersję haml
  config.gem "haml"

  # Załaduj konkretną wersję chronic
  config.gem "chronic", :version => '0.2.3'

  # Załaduj gem z repozytorium innego niż RubyForge
  config.gem "hpricot", :source => "http://code.whytheluckystiff.net"

  # Załaduj gem którego nazwa pliku jest inna niż nazwa gemu
  # Np. można załadować gem który potrzebuje require 'aws/s3' zamiast 
  # require 'aws-s3'
  config.gem "aws-s3", :lib => "aws/s3" 
end

Cieszy też, że poprawiono sposób działania buforowania oraz wbudowano lepszą obsługę dat i stref czasowych.

Ale z tego wszystkiego najbardziej mnie cieszy informacja inna informacja. Wspominałem o tym trzy dni temu, teraz zostało to oficjalnie ogłoszone: Rails migruje z Subversion na Gita. W końcu będzie można liczyć na poważniejsze przyśpieszenie prac i szybsze nanoszenie zgłaszanych poprawek (do tej pory to było tragicznie wolne, np. zgłoszony przeze mnie patch uwzględniono po 8 miesiącach). Rails, identycznie jak Merb, będzie używał tego samego serwera GitHub dla kodu i LightHouse. Więc ci, co nie mają tam kont, mogą już teraz o to zadbać. Praca z Git różni się też bardzo do SVN. Trochę przydatnych linków:

W komentarzach do newsu na stronie Railsów można znaleźć głosy rozczarowania tych, co używają system Windows. Woleli by aby wybrano bardziej multiplatformowy Mercurial, ale DHH uciął dyskusję mówiąc, że decyzja została już podjęta a kolejne wersje Rails będą i tak dostępne standardowo w gemach. Poza tym na razie Git może być od biedy używany pod Cygwinem i jest też projekt msysgit. No cóż, mnie to mało interesuje. Każdy wie, że windows i tak sucks i najlepiej pracuje tylko ze samym sobą. Rails ma zaś silniejsze związki z światem POSIX, dlatego najlepiej używać Ubuntu, Mac OS X czy innych systemów uniksowych. BTW, nowy Kubuntu 8.0.4 beta nawet nieźle śmiga na VMWare pod Win32. :)

Tags ,  | 10 comments

Comments

Leave a response

  1. Avatar Paweł Kondzior said about 6 hours later:

    Git wyrasta na króla vcs’ow. Rok temu tylko x.org i linux kernel uzywaly go do zarzadzana kodem, a dzis :)

  2. Avatar Seban said about 7 hours later:

    A dziś jest na pewno buzz word: ’’git’’ ;-)

  3. Avatar Jiima said about 11 hours later:

    Nie jest tak źle i nie wiem czemu windowsiarze jojczą. Mercurial świetnie “gada” z GIT-em w obydwie strony, więc niech używają Mercuriala…

  4. Avatar RobertG said 1 day later:

    To właśnie ból języków skryptowych, czy technologi z nimi związanych, ze tak szybko się zmieniają i że działający kod po jakimś czasie staje się (czesto) już niepoprawny.

  5. Avatar Paweł Kondzior said 1 day later:

    Robert: Ale co jest niepoprawne ? Czy Java 1.2 bedzie kompatybilna z 1.6 ? Czy php 4 bylo kompatybilne z 5 ? Czy ruby 1.8.x bedzie kompatybilny z 1.9.x ?

    To sa pytania retoryczne, technologia ewoluuje. To ze w przypadku jezykow skryptowych wysoki poziom abstrakcji pozwala na wieksze tempo tej ewolucji, to swiadczy raczej dobrze o danym jezyku prawda?

    Lepszy jezyk ktory jest dobry ale rozwija sie raz na 5 lat ?

  6. Avatar salciarz said 1 day later:

    Wlasnie chcialbym sobie kupic jakas ksiazke o railsach. Czekam wiec na jakas po polsku, ktora bedzie opisywac przynajmniej wersje 2.0.

  7. Avatar Tomash said 2 days later:

    Jarek, nic osobistego, ale – czekam z utęsknieniem na notkę, która nie będzie przepisaniem/przetłumaczeniem notki z anglojęzycznych blogów o Ruby/Railsach (z nawet identycznymi przykładami).

  8. Avatar Arek said 4 days later:

    Tomash: widze ze nie tylko ja to zauwazylem :) pozdr

  9. Avatar Damian said 5 days later:

    Tomash,Arek czepiacie się, nie każdy zna angielski perfekt, ja czasem wolę przeczytać dobre tłumaczenie tutaj, nie szukając po blogach! Łatwo krytykować, pokażcie co potraficie i dajcie też coś od siebie. Pozdrawiam

  10. Avatar gertas said 17 days later:

    Paweł Kondzior: RobertG ma na myśli kompatybilność wsteczną – w przypadku Javy, kod napisany w 1.2 lub 1.1 będzie działał na 1.6, bez rekompilacji nawet. W przypadku PHP kompatybilność wsteczna jest niepełna dlatego hostingi zazwyczaj oferują interpretery w wersji 4 i 5. W przypadku Rubiego jest podobnie, inaczej Railsy dawno by już działały na 1.9. To o czym Ty wspominasz to kompatybilność “w przód” – niestety to już jest wróżenie z fusów. Kompatybilność wsteczna nie jest zaprzeczeniem ewolucji – język może dowolnie się rozwijać, ale powinien wspierać stary kod (legacy), choćby przez emulację lub konwersję. Wg mnie technologia, która nie wspiera tego nie jest dojrzała i nie ma szans na zaistnienie w większych przedsięwzięciach, gdzie cykl budowy i życia projektu jest dłuższy niż wersja języka/interpretera.

    Ale nie o język tu chodziło tylko o framework – Railsy – w tym wypadku Robert słusznie zwrócił uwagę, iż sporo aplikacji i rozszerzeń napisanych pod Rails 1.2 nie zadziała pod 2.0 bez zmian w kodzie. Zdaje mi się, iż obawia się tego, iż może też tak być z 2.0 i 2.1.

    Pożyjemy, zobaczymy. Pozdrawiam.

RSS feed for this post

(leave url/email »)

   Comment Markup Help Preview comment