Skrypt ten uruchamiamy przez:

rake db: schema: load db/schema.rb

Warto zauważyć, że przedstawiona definicja tabeli nie zawiera wzmianki o kluczu głównym, bo zostaje on utworzony automatycznie (domyślnie jako "id"). Prawdziwą efektywność RoR poznajemy jednak po wygenerowania rusztowania dla tabeli z postami i uruchomieniu serwera:

ruby script/generate scaffold Post

ruby scripts/server

Po wpisaniu w przeglądarce adresuhttp://127.0.0.1: 3000/posts uzyskujemy dostęp do strony, na której możemy zarządzać wpisami w tabeli. Wprawdzie efekt końcowy daleki jest od ideału, ale można go łatwo dostosować do własnych potrzeb już po krótkiej analizie kodu kontrolera i widoków.

Podobną stronę możemy wygenerować znacznie szybciej za pomocą kilku kliknięć myszy w istniejących środowiskach typu RAD (Rapid Application Development). Dalsze utrzymanie takiego projektu będzie jednak trudniejsze niż w RoR, głównie z powodu wymieszania ze sobą warstw prezentacji i dostępu do danych (nagminne choćby w ASP .Net 2.0).

Mocna strona RoR - migracje

Poważny problem w projektach tworzonych przez kilka osób stanowi zarządzanie zmianami w strukturze bazy danych. Dodanie lub usunięcie nowego pola w tabeli może pociągać za sobą np. konieczność wygenerowania nowych danych testowych, a dystrybucja tych zmian do programistów jest bardzo kłopotliwa.

W Rails problem ten został rozwiązany dzięki "migracjom". Wszelkie zmiany w strukturze bazy są zapisywane w kodzie Ruby i odpowiednio wersjonowane. Za pomocą jednego polecenia możemy bardzo szybko wrócić do poprzedniej wersji bazy lub wprowadzić do niej modyfikacje. Kod ten jest niezależny od konkretnego dostawcy systemu baz danych, zatem późniejsze wdrożenie aplikacji na bazie Oracle czy DB2 nie nastręcza większych problemów.

Rubin ze skazą?

Każda z platform programistycznych jest obarczona pewnymi wadami. W wywiadach twórca Rails nie ukrywa, że framework ten jest zorientowany głównie na programistę (wykonanie dynamicznego kodu Ruby jest dodatkowo obarczone narzutem). Cecha ta może niekorzystnie stawiać RoR pod względem jego zastosowania do tworzenia złożonych i wymagających aplikacji.

Kolejne argumenty przeciwko RoR, które wytacza Cédric Beust, inżynier pracujący w Google, to: Rails jest jedynym frameworkiem webowym pracującym z Ruby (nie funkcjonuje dobór naturalny, który mógłby eliminować słabej jakości rozwiązania); zwolennicy RoR to fanatycy. To ostatnie ma swoje wady i zalety - w razie problemu bardzo szybko uzyskamy pomoc na forum czy grupie newsowej, choć wywyższanie na forach Pythona nad Ruby nie jest najlepszym pomysłem. Opinie użytkowników RoR przybierają niekiedy wymiary humorystyczne, jak np. we wzorowanych na kampanii Maca (Mac vs PC) reklamach porównujących Rails z PHP i Javą (railsenvy.com).

Pojawiają się także głosy krytyki odnośnie do dokumentacji frameworku. Wielu programistów przyzwyczajonych jest do solidnej dokumentacji Suna czy Microsoftu, natomiast istniejąca dokumentacja RoR ma bardzo nierówny poziom.

IronRuby, JRuby- przyszłość RoR?

Dobra znajomość Javy czy języka C# wiąże się z wieloma zyskami: naszą wiedzę o bibliotekach i konwencjach programowania możemy przenieść także na aplikacje mobilne czy desktopowe, działające na różnych platformach sprzętowo-programowych (w przypadku C# i .Net, to głównie rodzina systemów Windows). Za pomocą samego Ruby nie stworzymy więc oszałamiającej aplikacji wykorzystującej Windows Presentation Foundation, ale to może się diametralnie zmienić wraz z nadejściem IronRuby.

W trakcie konferencji Mix'07 inżynierowie z Microsoftu zaprezentowali testową implementację Ruby na platformie .Net - IronRuby. Możliwość wykorzystania .Net Framework, solidnego IDE (Visual Studio) z intellisense (podpowiedzi dla programisty) oraz wygodą debugowania, pozwoli na swobodny wybór platformy programistycznej w zależności od potrzeb programistów i zleceniodawców. Dodajmy jeszcze do tego rozszerzalność serwera webowego - IIS 7 i kto wie, być może już niedługo będziemy się mogli cieszyć także z "IronRuby on Rails"? Oczywiście pojawiają się też sceptyczne opinie; Ola Bini (jeden z twórców JRuby) prognozuje, że prace nad IronRuby będą trwały jeszcze przynajmniej 1,5 roku, głównie ze względu na brak kompletnej specyfikacji języka Ruby.

Znacznie bardziej zaawansowane są prace nad JRuby - implementacją Ruby na platformie Java. Nie dość, że wspiera ona Rails już od maja 2006 r., to ma pełne wsparcie ze strony środowiska NetBeans 5 (milestone 7). Fani RoR mają przy tym swobodę wyboru - mogą pracować z natywnym Ruby (czyli zyskują jedynie solidne IDE) lub z JRuby (co daje dostęp do istniejących bibliotek napisanych w języku Java).

Przede wszystkim wysoka efektywność

Ruby on Rails to doskonałe połączenie sprawdzonych praktyk i kompromisów. Bardzo prosty do nauczenia język, większa produktywność programistów to powody, dla których coraz więcej programistów PHP i Javy interesuje się tym frameworkiem. Zwolennicy Rails twierdzą, że pozwala on dziesięciokrotnie skrócić czas tworzenia aplikacji, ale jak te założenia mają się do praktyki?

Na blogu firmy Relevance, tworzącej projekty zarówno w Javie, jak i RoR, przedstawiono ciekawe porównanie: realizacja aplikacji za pomocą RoR zajmuje od 30% do 50% mniej czasu niż analogicznej aplikacji pisanej w Javie. To o wiele niższy niż prognozowany, ale nadal bardzo dobry wynik, który może być jeszcze poprawiony za pomocą porządnego IDE. To nie wszystko. Martin Fowler, znany autorytet w zakresie wzorców projektowych i kierownik techniczny ThoughtWorks zauważył, że niemal 40% nowych projektów realizowanych przez jego firmę jest obecnie opartych na Ruby on Rails!