Xoft

Ok, w poprzednim odcinku okazało się, że daje się zainstalować Rubyego i Railsy. Zobaczymy teraz, że nasz naiwny obraz Świata zostanie zburzony.

Będziemy chcieli utworzyć aplikację blog, taką samą, która jest w tutorialu Railsów na ich stronie, tyle, że działającą z normalną bazą danych, czyli w tym wypadku z Postgresem. Brzmi prosto? O nie, nie, nie. Może pod Linuksem albo MacOs-em idzie to normalnie, ale nie pod Windowsem.

Pierwsza rzecz to instalacja Postgresa. Lepiej się nie rzucać na wersję 9 (nie jest oficjalnie wspierana przez Rails – chyba nie jest), i nie należy dotykać się wersji 64 bit. Jeżeli ktoś nie lubi ćwiczeń w rodzaju podawanie w różnych, losowo wybranych miejscach ścieżki do Postgresa jako C:\Progra~1\PostgreSQL\8.4\bin to lepiej nie instalować Postgresa w Program Files tylko gdzieś, gdzie nie ma spacji w ścieżce.

Druga rzecz, to sterownik (czyli w ichniej terminologii, adapter) Rubyego do Postgresa. W Rubym instalacja jest tożsama z instalacją odpowiedniego gem-a. Wchodzimy więc na stronę wiki, żeby się dowiedzieć, jak się ten gem nazywa. I od razu człowiek się cieszy, bo ma do wyboru aż 4 adaptery. Prawda, że super?

Sytuacja się na szczęście upraszcza. Rozwijanie adaptera postgres znudziło się jego twórcą w 2008 roku. Jego następcą jest pg, który jest “natywnym” adapterem, który wymaga zainstalowania kawałka linuksa pod Windowsem.

Jest też postgres-pr, który jest adapterem napisanym tylko w Rubym, co wróży nędzną wydajność, ale powinno pozwolić uniknąć kłopotów z instalacją. Dodatkowo ostatnio ktoś się do niego dotykał w marcu 2009, co jest według autora wiki “sign of active development”. Zdaje się, że ostatnia wersja jest z grudnia 2009.

Jest jeszcze ruby-postgres, ale strona projektu wskazuje, że wszyscy jego deweloperzy zajęli się dawno czymś innym.

Najbardziej sensowną opcją jest użycie pg. Weźmy się więc za to.

Pierwsza rzecz, to adapter ten jest napisany w C (czyli jest “natywny”), w związku z tym pod Windowsem trzeba sobie zainstalować Developnent Kit. Instrukcję na tej stronie należy wykonać dokładnie, sprawdzając czy się gdzieś nie pomyliliśmy. Tutaj problemów nie napotkałem.

Następnie instalujemy gem pg: gem install pg? He, he, he. Takie rzeczy to tylko działają w tutorialach na stronie Railsów. To, co trzeba zrobić to:

gem install pg --platform=mswin32 --version=0.9.0 -- --with-pg=c:\programs\PostgreSQL\8.4\

Uwagi:

1. mimo, że najnowszą wersją pg jest 0.10.0, to nie udało mi się z nią ruszyć, zresztą nie tylko mi,
2. te dodatkowe dwa minusy za numerkiem wersji a przed --with-pg są potrzebne, to nie literówka,
3. ukośnik na końcu ścieżki Postgresa też jest potrzebny.

Ja wiem, że niektórzy teraz przecierają oczy, że jakiś kawałem teoretycznie produkcyjnego kodu ma numer wersji 0.10, ale najwyraźniej tak jest.

Jak się wszystko poinstalowało, to możemy zająć się utworzeniem aplikacji.

Piszemy w konsoli
rails new c:\katalog\z\projektami\blog -d postgresql

Railsy generują gotowy do uruchomienia szkielet projektu. To znaczy niby on jest gotowy do uruchomienia, ale nie jest. Można się o tym łatwo przekonać wchodząc do utworzonego katalogu blog i pisząc w konsoli rails server.

Trzeba zrobić dwie rzeczy:

• w pliku blog\config\database.yml podajemy poprawne ustawienia dla baz danych: Rails pracuje z trzema bazami: deweloperską, testową i produkcyjną (i bardzo słusznie) – trzeba ustawić poprawnie nazwę użytkownika, nazwę bazy, itp,
• w pliku blog\Gemfile poprawiamy gem 'pg' na gem 'pg', '0.9.0', w innym przypadku Rails sobie doinstaluje sam najnowszą wersję pg, która nie chciała mi działać.

Uff teraz piszemy w konsoli, w katalogu projektu, bundle install, a następnie rails server i na http://localhost:3000 powinna się pojawić strona powitalne naszej aplikacji.

Póki co aplikacja nic nie robi, ale to już temat na kolejny wpis.

Ruby to podobno fajny, miły i przyjemny język programowania. Spędziłem trochę czasu na pisaniu aplikacji w Ruby-on-Rails (zdaje się 90% wszystkiego pisanego w Ruby jest aplikacją Ruby-on-Rails) i chciałbym się podzielić swoimi doświadczeniami. Także z samym sobą, jak bym musiał sobie coś za rok przypomnieć.

Zacznijmy od instalacji. Dla porządku: instaluję wersję Rails 3.0.3, jak się przekonamy nawet zmiana na wersję 3.0.4 może spowodować, że poniższą instrukcję będzie sobie można wsadzić w railsa. Takie tu panują zwyczaje.

Dodatkowo używam Windows 7 64 bit, warto od razu zaznaczyć, że nie ma sensu instalować czegokolwiek 64 bit. Ruby, Railsy itp. pod Windowsem żyją w świecie x86. Ale ogólnie, to instalacja na wszystkich platformach wygląda podobnie.

Zacznijmy wreszcie. Wchodzę na stronę http://rubyonrails.org/ i klikam dużą ikonę Get Started (wiadomo, Web 2.0, duże ikony, pastelowe kolorki).
Ruby ma całkiem sympatyczny instalator windowsowy. Od razu mają plus. Ale co ja widzę:

We recommend Ruby 1.8.7 or Ruby 1.9.2 for use with Rails. Ruby 1.8.6 and earlier are not supported, neither is version 1.9.1.

Ok, rozumiem, że wersja wcześniejsza niż 1.8.7 nie jest wspierana (w Open Source to norma), ale dlaczego wersja 1.9.1 nie jest wspierana, a 1.9.2 jest??? Jak się człowiek przyzwyczaja, że aplikacja napisana w Java 10 lat temu ruszy na Java 6 z 2010, to się może lekko zdziwić.

Następna rzecz to RubyGems, czyli taki sprytny menadżer pakietów. Coś jak Maven.

Download (extract, then run “ruby setup.rb”)

I co?

source_index.rb:62:in `installed_spec_directories’: undefined method `path’ for Gem:Module (NoMethodError)

No pięknie, jeszcze nic nie zacząłem robić, a już dostaję wyjątek, tfu, error. Szukam w googlu i okazuje się, że to wszystko moja wina. Przecież powinienem wyśledzić w changelogach itp. miejscach, że wersja 1.4.2 Rubygems nie współpracuje z Ruby 1.9.2. Oczywiście można wykonać szereg hakierskich sztuczek, odpowiednich upgradów i downgradów, żeby można było użyć… no dobrze, nie ważne.

RubyGems jest dostarczony z Ruby 1.9.2, więc można sobie krok instalacji Gems odpuścić. Nie to, żeby w instrukcji było to napisane.

Szukam programu gem w katalogu bin instalacji Rubyego i wpisuje magiczne gem install rails i czekam, czekam, czekam. Wreszcie, bez dalszych niespodzianek, wszystko się pięknie instaluje. W katalogu bin rubyego pojawia się program rails. Czas na test:

rails new c:\TRASH\testapp
cd c:\TRASH\testapp
rails server

Pierwsza linijka powoduje utworzenia szkieletu aplikacji (jak by ktoś nie wiedział, to Rails jest sprytnie wymyślonym generatorem aplikacji i frameworkiem Model-View-Controller w jednym – JBoss Seam, Grails, Spring Roo właśnie z tego rżnęli pomysły); trzecia linia uruchamia serwer WWW z gotową do działania aplikacją. To znaczy nie uruchamia, bo dostajemy

Could not find gem ’sqlite3-ruby (>= 0, runtime)’ in any of the gem sources listed in your Gemfile.
Try running `bundle install`.

Jak ktoś chce być cool i używać dżezi technologies, to się musi trochę napocić.

Może porada Try running `bundle install’ pomaga? Pomaga, jeżeli mamy zainstalowaną bazę sqlite. Ja nie mam i nie mam zamiaru mieć, więc poprzestańmy na tym, co mamy: jest Ruby, są Railsy, coś tam działa.

Konfiguracją normalnej bazy danych i odpaleniem prostego projektu zajmiemy się następnym razem. Dopiero wtedy zacznie się prawdziwa zabawa.

Najpierw będzie przydługi wstęp, w którym popastwię się nad Rubim, a na końcu będzie interesujące porównanie wydajności czasu tworzenia aplikacji w Javie i Rubim na Rejlasach.

Ostatnio sporo szumu pojawiło się w związku z językiem programowania Ruby, a zwłaszcza frejmłorkiem do tworzenia dynamicznych stron WWW Ruby on Rails. Przypomina to bardzo przedostatni szum związany z językiem Python i serwerem Zope – te ostatnie dwie technologie jakoś popadły w niełaskę ostatnio u “trend seterów”.

Przyjrzałem się ciepło Rubiemu, bardzo przyjemny język, bardzo obiektowy i można w nim bardzo dziki kod tworzyć. Na przykład dodawanie 2 + 3 można zapisać w postaci 2.+(3) itp. sztuczki. Kod można pisać w dowolnie niedbały sposób, co ma swoje wady i zalety.

Tak na serio, Ruby jest na prawdę fajny, tylko co z tego.

Grzebiąc w sieci na jego temat (zwłaszcza Ruby on Rails) znalazłem to . I własnym oczom nie mogłem uwierzyć. Tam jest napisane: “Please note that right now Rails basically knows nothing about Unicode and pretends everything is just bytes”. Co? Cooo? Ten ficzer Rubiego faktycznie znakomicie ułatwia tworzenie aplikacji, które mają pecha i używają czegoś więcej niż US-ASCII.

Zwolennicy Rubiego, np. Bruce Tate, autor książki “Beyond Java” twierdzą, że podstawową zaletą Rubiego i Ruby on Rails jest dziesięciokrotne przyspieszenie czasu tworzenia aplikacji w stosunku do Javy.

10 razy robi wrażenie.

Jest nawet w sieci tutorial pokazujący jak szybko można w Rubym on Rails utworzyć aplikację WWW opartą o bazę danych z szybkością 10. Przetrawiłem ten tutorial i rzeczywiście, jedna godzina i prosta aplikacja dodająca i modyfikująca dane w bazie jest gotowa.

Tyle, że to samo w Javie można zrobić szybciej i przyjemniej, nie tracąc tego wszystkiego, co nam daje technologia Java EE: deklarowalną politykę bezpieczeństwa, deklarowalną transakcyjność, komponenty EJB, z którymi może rozmawiać klient GUI i wiele innych. Potrzebujemy do tego Netbeans 5.5 (narazie jest beta) i to w zasadzie wszystko. Demo we flashu jest tutaj.

Parę kliknięć i prosty CRUD w EJB 3.0 i JSF jest gotowy.

Wpis umieszczony na portalu JDN [link]