Javascript szturmem zdobywa popularność jako język ogólnego rażenia. Nie jest to już język do wstawiania zabawnych skryptów na stronie. Coraz częściej jest on używany również po stronie back-endu.

Rosnąca popularność nie zmienia jednej rzeczy, mianowicie tego, że:

Javascript jest brzydki jak noc!

Rozwiązaniem tego problemu jest CoffeeScript. Jest to prosty język, który kompiluje się do poprawnego JavaScriptu, a składnią przypomina Rubiego lub Pythona. Poniżej próbka:

# Assignment:
number   = 42
opposite = true

# Conditions:
number = -42 if opposite

# Functions:
square = (x) -> x * x

# Arrays:
list = [1, 2, 3, 4, 5]

# Objects:
math =
  root:   Math.sqrt
  square: square
  cube:   (x) -> x * square x

# Splats:
race = (winner, runners...) ->
  print winner, runners

# Existence:
alert "I knew it!" if elvis?

# Array comprehensions:
cubes = (math.cube num for num in list)

Prawda, że wygląda nieźle? Jeśli wam się to podoba, to polecam zajrzeć na oficjalną stronę lub do prezentacji, którą wygłosiłem na ostatnim wrugu.

Dla tych którym nie chcę się instalować Kawoskryptu poprzez Node Package Managera (co jest sugerowanym sposobem instalacji) polecam Railsy 3.1 – tam CoffeeScript jest na dzień dobry.

Czytelnicy tego bloga dobrze znają i cenią sobie zalety języka Ruby. Wysoka ekspresywność, zwięzła składnia, dynamiczne dopisywanie metod, mechanizmy refleksji i ogromna, aktywna społeczność to tylko niektóre z nich. Niestety w życiu nic nie ma za darmo. Ruby to niemal przysłowiowy przykład języka o bardzo niskiej wydajności. Zmiany wprowadzone w wydaniu 1.9 poprawiły w pewnym stopniu szybkość wykonania ale nie przyniosły rewolucji. MRI nadal zajmuje ostatnie miejsca w rankingach wydajności różnych języków programowania.

Na przestrzeni ostatnich lat podejmowano różne próby poradzenia sobie z tym problemem. Jako przykład należy wskazać aktywnie rozwijany projekt JRuby, kompilujący Ruby to bytecode’u JVM. Podobne rozwiązanie zaproponował Microsoft przedstawiając projekt IronRuby oparty o .NET Framework. Własną maszynę wirtualną zaprojektowali autorzy Rubinius, którzy pracują nad implementacją Ruby wykorzystującą LLVM do kompilacji JIT.

Wspólnie z Julianem Zubkiem, moim kolegą z wydziału, postanowiliśmy podejść do zagadnienia z innej strony. Spojrzeliśmy na przeciwległy koniec rankingów wydajności, gdzie dominują języki kompilowane do kodu maszynowego. Zdecydowaliśmy się stworzyć własną implementację Ruby tłumaczącą wejściowy kod do C. Wyjściowy kod miał być następnie kompilowany przez GCC lub inny kompilator do pliku wykonywalnego z natywnym kodem maszynowym.

Na dobrą sprawę jedyną cechą wspólną Ruby i C jest pisanie kodu od lewej do prawej i z góry na dół. Poza tym podobieństwem dzieli je przepaść. W C ze świecą szukać obiektowości, wyjątków, mechanizmów refleksji, automatycznego odśmiecania pamięci czy domknięć, w Ruby znanych jako bloki. Wyróżnia go jednak jedna istotna zaleta – powstały zeń kod maszynowy jest wyjątkowo szybki. Stąd nasza decyzja o wybraniu go jako język docelowy.

Przetwarzanie drzew

Nasz projekt został zaimplementowany w Ruby. Jego ogólna architektura jest dość prosta. Wejściowy kod w Ruby przetwarzamy przy pomocy gema ruby_parser uzyskując z niego tzw. AST, abstract syntax tree, czyli drzewiastą reprezentację struktury programu ułatwiającą dalszą manipulację. Otrzymane drzewo jest następnie przekazywane do serca naszego kompilatora, który analizuje je i stopniowo buduje z niego AST wyjściowego kodu C. Odpowiadający za to zadanie moduł to kluczowy element naszego projektu, w którym zawarta jest cała logika translacji. W oparciu o powstałe AST C generowany jest właściwy kod wyjściowy. Na koniec otrzymany kod jest kompilowany przez GCC i linkowany z zaimplementowanym przez nas skrawkiem biblioteki standardowej Ruby.

Moduł przetwarzający drzewo Ruby na drzewo C analizuje wejściowy kod w sposób naśladujący proces jego wykonania. Najpierw zapoznaje się z deklaracjami wszystkich klas i ich metod, ale nie analizuje od razu ich wnętrza. Analizę kodu wewnątrz danej metody rozpoczyna dopiero przy napotkaniu jej wywołania. Podejście to ma pewną istotną zaletę. Analizując metodę w momencie jej wywołania uzyskujemy wiedzę na temat typów przekazywanych do niej argumentów. Dzięki temu możemy poczynić pewne optymalizacje w kodzie wynikowym, które omówię w dalszej części artykułu.

Statyczna analiza całego kodu przed jego wykonaniem pozwala uzyskać wiele innych cennych informacji. Dzięki niej możemy ustalić na etapie kompilacji nazwy wszystkich zmiennych klasowych i instancyjnych. Jesteśmy też w stanie sprawdzić czy metody w obrębie danej klasy są nadpisywane lub czy klasa jest rozszerzana. Możemy też jednoznacznie przewidzieć typy obiektów, na które wskazywać będą poszczególne zmienne. Wszystkie te informacje są bardzo przydatne. Mogą być wykorzystane do zastąpienia wielu dynamicznych i – co za tym idzie – wolnych operacji statycznymi i szybkimi rozwiązaniami.

Do rzeczy, co działa?

Po trzech miesiącach prac nasz projekt wspiera strukturalną i obiektową składnię Ruby, nadpisywanie metod, proste bloki i odśmiecanie pamięci. Różnice między wejściowym a wyjściowym językiem wymusiły na nas zaimplementowanie powyższych wysokopoziomowych funkcjonalności w czystym C. Postaram się pokrótce przedstawić realizację każdej z nich.

Obiektowość Ruby została zrealizowana w C przy pomocy dostępnych w nim struktur i funkcji. Obiekty reprezentowane są jako struktury zawierające informację o swoim typie oraz wskaźniki na zawarte w nich pola. Pozwala na to analiza całego kodu na etapie kompilacji, w trakcie której jesteśmy w stanie ustalić wszystkie zmienne instancyjne w obrębie danej klasy.

Metody są realizowane jako funkcje, do których jako pierwszy argument przekazywany jest wskaźnik na obiekt self a następnie przekazywane są właściwe argumenty wywołania. Ze względu możliwość pominięcia w Ruby return na końcu ciała metody, nasz translator zapamiętuje ostatnie wyrażenie i automatycznie zwraca je z wynikowej funkcji w C. Dotyczy to też bardziej złożonych konstrukcji, jak choćby if na przykładzie wartości bezwzględnej:

def abs(x)
  if x > 0
    x
  else
    -x
  end
end

W tym miejscu warto wspomnieć o innej ciekawej cesze Ruby. Poza nielicznym wyjątkami, każda instrukcja jest wyrażeniem, co na polski tłumaczy się jako ,,wszystko zwraca jakąś wartość”. Widać to na przykładzie powyższej metody abs. Zwraca ona wartość ostatniego wyrażenia, czyli if, który zwraca z kolei wartość ostatniego wyrażenia z jednej ze swoich odnóg. Cała ta funkcjonalność również musiała zostać sztucznie przeniesiona w C. Nasz kompilator zapamiętuje wartości zwracane przez wszystkie wyrażenia na wypadek konieczności zwrócenia lub wykorzystania ich na późniejszym etapie.

Bloki są traktowane podobnie jak metody. Każdy z nich jest tłumaczony do funkcji w C. Podczas wykonania, przed wywołaniem metody do której przekazujemy blok, umieszczamy odpowiadający mu wskaźnik na funkcję go na specjalnym stosie. Metoda wykorzystująca blok pobiera wskaźnik w momencie skorzystania z instrukcji yield. Dzięki rozwiązaniu ze stosem rozwiązanie pozwala na zagnieżdżone bloki, wszechobecne m.in. w testach utworzonych przy pomocy RSpeca. Obecna implementacja nie pozwala jeszcze na korzystanie ze zmiennych zdefiniowanych poza blokiem, ale jest to jedna z priorytetowych pozycji na naszej liście zadań do zrobienia.

Automatyczne odśmiecanie pamięci jest bardzo skomplikowanym zagadnieniem. Śledzenie wszystkich odwołań do obiektów, ustalanie, czy są nadal używane, czy też efektywne algorytmy zarządzania alokacją to tylko wierzchołek góry lodowej jaką stanowi utworzenie własnego garbage collectora. Na szczęście istnieją jednak gotowe rozwiązania, które rozwiązują ten problem.

W naszym projekcie wykorzystaliśmy Boehm GC — dojrzałą bibliotekę pozwalającą na bardzo proste dołączenie automatycznego odśmiecania pamięci do swoich projektów w C. Dzięki temu cały proces zwalniania pamięci odbywa się w tworzonych przez nasz kompilator programach automatycznie i efektywnie, a my mogliśmy bez przeszkód poświęcić całą swoją uwagę procesowi translacji.

Metody po raz wtóry

Dynamiczne wiązanie metod, które pozwala między innymi na pisanie bardzo zwięzłych testów przy pomocy RSpeca, jest operacją wyjątkowo kosztowną. Przeanalizujmy proces wywoływania metody w Ruby. Najpierw musimy ustalić klasę obiektu. Następnie, znając typ, możemy sprawdzić w odpowiedniej strukturze danych, czy dana klasa ma metodę o zadanej nazwie. Jeśli nie, przechodzimy do nadklasy i powtarzamy procedurę aż do Object. W przypadku niepowodzenia wołamy method_missing. Jeśli uda nam się znaleźć odpowiednią metodę, możemy wreszcie przekazać do niej argumenty. Zainteresowanych szczegółami odsyłam do pliku vm_method.c w źródłach MRI.

Zwróćcie uwagę, że wspomniana struktura przechowująca informacje o metodach musi pozwalać na modyfikacje. Jak wiemy, w Ruby metody klas możemy zmieniać niczym rękawiczki, co każdorazowo wymusza naniesienie zmian w owej tablicy. Stawiając wymaganie możliwości rozszerzania i modyfikowania tablicy metod musimy liczyć się z tym, że odbije się to na wydajności operacji przeszukiwania.

Zastanówmy się teraz co możemy zyskać przy pomocy statycznej analizy kodu dokonywanej przez nasz kompilator. Zakładając, że nie użyta zostanie metoda send lub eval, jesteśmy w stanie ustalić nazwy wszystkich metod danej klasy. Jeśli nie miały miejsca żadne nadpisania, możemy nawet na etapie kompilacji przypisać poszczególnym nazwom konkretne funkcje w C. Zysk jest oczywisty. Zamiast całej przedstawionej wyżej procedury wywołanie metod sprowadza się do wykonania funkcji C.

Powyższej optymalizacji nie można zastosować we wszystkich przypadkach. Bardzo często nie potrafimy w czasie kompilacji ustalić typu danej zmiennej. Przykład takiej sytuacji to metoda, która w pewnych warunkach zwraca nil a w innych obiekt String. W takim wypadku musimy zastosować inną strategię. Na etapie kompilacji zapisujemy w pliku wynikowym strukturę danych pozwalającą na możliwie szybkie skojarzenie typu i nazwy metody ze wskaźnikiem na funkcję C. Dodatkowe informacje uzyskane na etapie kompilacji pozwalają nam na poczynienie w tym miejscu kolejnych usprawnień.

Zauważmy, że biorąc pod uwagę znajomość nazw wszystkich metod podczas translacji, struktura przechowująca metody nie musi wspierać operacji dodawania. Jest tworzona tylko raz, podczas kompilacji, a na późniejszym etapie nie potrzebujemy dodawać do niej nowych elementów. Stawiamy przed nią tylko dwa wymagania. Po pierwsze, ma pozwalać na bardzo szybkie znajdowanie elementów – funkcji – po kluczu – nazwie metody – a po drugie ma pozwalać na nadpisanie wartości przypisanej kluczowi w razie nadpisania metody wewnątrz klasy.

Okazuje się, że wymagania te pozwalają nam na wykorzystanie struktury o lepszych właściwościach od drzewa czy tablicy z haszowaniem. Do przechowywania informacji o metodach stosujemy tzw. perfekcyjne tablice z haszowaniem. Nie chcę w tym miejscu rozpoczynać szczegółowego opisu tych struktur – zainteresowanych odsyłam na Wikipedię. Podkreślę tylko, że podobnie jak tradycyjne tablice z haszowaniem struktury te zapewniają nam dostęp w czasie stałym. Na ich korzyść świadczy brak kolizji, zagwarantowany przez funkcję haszującą zoptymalizowaną pod kątem zadanego zestawu kluczu, który w naszym wypadku jest zbiorem nazw metod danej klasy.

Połączenie wyszukiwania metod w perfekcyjnych tablicach z haszowaniem ze statycznym wywoływaniem funkcji tam, gdzie jest to możliwe, pozwala nam na osiągnięcie zdecydowanego zysku w porównaniu z MRI. Wynik ten da się jeszcze poprawić przy pomocy cache’owania wyników przeszukiwania tablic metod lub zastosowania w ich miejsce tradycyjnych tablic C. Jest to jedno z głównych zagadnień, któremu chcemy stawić czoła w trakcie dalszego rozwoju naszego projektu.

Wyniki i plany na przyszłość

Mógłbym dalej mnożyć przykłady ciekawych cech Ruby, których translacja do C nie była oczywista. Każda z nich stanowiła dla nas ciekawe zadanie wymagające przemyślenia i eksperymentów z różnymi podejściami. Czas jednak nagli, a ja nie przedstawiłem jeszcze wyników.

Poza garniturem testów funkcjonalnych weryfikujących poprawność naszej implementacji w porównaniu z Ruby 1.9.2 przygotowaliśmy kilka testów wydajnościowych. Są to proste, akademickie testy, jak choćby mnożenie macierzy, dwa różne sortowania, operacje na liczbach zmiennoprzecinkowych czy test głębokiej rekurencji przy pomocy funkcji Ackermanna. Uruchomiliśmy je na naszej implementacji oraz porównaliśmy ich czas wykonania z wynikami osiągniętymi przez Ruby 1.9.2.

W kilku spośród powyższych testów uzyskaliśmy zdecydowaną, niemal pięciokrotną przewagę. Były jednak przypadki, w których to MRI osiągnęło lepsze wyniki. Motywuje nas to do dalszej pracy, tym bardziej, że mamy jeszcze wiele pomysłów na dalsze usprawnienia i optymalizacje.

Wyniki profilowania testów pokazały, że koszt dynamicznego wołania metod przy braku znajomości typu obiektu jest dość wysoki. Podczas dalszych prac mamy zamiar skupić się na rozwiązaniach, które pozwoliłyby go zredukować. Poza optymalizacją mechanizmów wyszukiwania odpowiednich funkcji do wywołania, kluczowe jest tutaj uzyskanie na etapie translacji jak najwięcej informacji o typach obiektów, których metody wołamy. Zysk wydajności można by uzyskać na przykład ustalając typy obiektów przechowywane w kolekcjach takich jak Array czy Hash. Śledząc wszystkie operacje wykonywane na tych strukturach moglibyśmy stwierdzić, że niektóre z nich przechowują obiekty tylko jednego typu, np. String, co pozwoliłoby na przyspieszenie wołania ich metod.

Poza próbami wyciśnięcia z generowanego przez nas kodu jak najlepszych wyników musimy również zabrać się ze implementację niewspieranych jeszcze cech Ruby. Przykłady to m.in. system wyjątków, moduły, lambdy i praca nad biblioteką standardową. Mamy już pomysł na implementację niektórych spośród tych funkcjonalności, jak np. wyjątków czy modułów, więc już wkrótce powinny zostać dodane do listy obsługiwanych przez nasz kompilator elementów Ruby. Z drugiej strony wielowątkowość jest bardzo skomplikowanym zagadnieniem, którego obsługa niesie za sobą konieczność wielu kosztownych zmian w naszym projekcie, zarówno z punktu widzenia czasu programisty jak i czasu wykonania wyjściowych programów.

Obecnie staramy się doprowadzić nasz kod do stanu, w którym będziemy mogli bez obciachu pochwalić się nim przed społecznością. Tu i ówdzie potrzeba refaktoringu, przyda się napisać trochę dokumentacji. Poza tym czeka nas wybór licencji. Nadal nie mamy też nazwy dla projektu – pomysły mile widziane. Liczymy na to, że projekt uda się opublikować w drugim kwartale tego roku.

Cały czas zastanawiamy się w którą stronę skierować nasz projekt. Czy ma być to kolejna implementacja Ruby? Czy też jedynie narzędzie pozwalające na statyczną kompilację wybranych fragmentów projektów w Ruby w celu ich przyspieszenia, co zaproponował Tomasz Stachewicz? Jesteśmy otwarci na pomysły. Bardzo chętnie poznamy opinie i pomysły czytelników.

Dobrzy kelnerzy potrafią zapamiętać nasze ulubione zamówienia i witają nas słowami „Podać to co zwykle?”. Kto tego nie lubi?

Railsy też są takim dobrym kelnerem i oferują mechanizm generatorów. Powiedziałem dobrym? Przecież zawsze tworzą mi testy w test/unit (a chciałbym w rspecu), widoki są w erb zamiast w hamlu, do tego te nieszczęsne helpery. To zdecydowanie nie jest tak jak lubię.

Wpisywanie za każdym razem kombinacji w stylu:

rails generate controller products --helper -t rspec -e haml

nie jest rozwiązaniem. To ja już wolę sam tworzyć te pliki zamiast zapamiętwać ich składnię i opcję. Nie można Railsom powiedzieć jak najbardziej lubimy podane nasze danie? Ależ można.

Konfiguracja generatorów

Aby podać domyślne ustawienia w Rails 3 należy dodać do pliku config/application.rb sekcję dotyczącą generatorów. Może ona zawierać poniższe opcje:

config.generators do |g|
  g.orm :data_mapper
  g.template_engine :haml
  g.test_framework  :rspec, :fixture => true
  g.fixture_replacement :factory_girl
  g.helper false
  g.stylesheets false
end

Potrzebujemy jeszcze odpowiednich generatorów (zakładam, że odpowienie gemy są już zainstalowane), dodajmy więc do Gemfile odpowiedni wpis:

gem "rails3-generators", :group => :development

Powyższy gem nie zawiera generatorów dla hamla. PaulBarry przygotował odpowiednią paczkę, wystarczy ją sklonować:

git clone git://github.com/pjb3/rails3-generators.git lib/generators

Więcej informacji o generatorach znajdziecie poniżej:
Railscast 216
Zbiór najpopularniejszych generatorów
Generatory w kodzie Railsów
Kolejny generator dla Hamla

Zachęcam do poświęcenia ten raz kilku minut na konfigurację. Bardzo szybko się zwracają.

Jak samemu znaleźć właściwy gem?

Całkiem pokaźna lista kategorii i rozwiązań jest zgromadzona na ruby-toolbox.com. Warto zwrócić uwagę na liczbę osób, które danego rozwiązania używają. Przy szukaniu odpowiedniego gemu warto kierować się:

• dostępnymi funkcjami – nie wymaga komentarza.
• dokumentacją – nawet najlepszy gem będzie na nic, jeśli nie będziemy potrafili z niego skorzystać. Chociaż w ostateczności można zawsze zajrzeć do kodu.
• jakoś kodu (testy) – im ważniejsza jest dla nas jakaś biblioteka, tym ważniejsze jest, by przyjrzeć się jak jest napisana. Pozwoli nam to zorientować się, czy można twórcom zaufać i czy będziemy w stanie coś w niej poprawić lub zmienić, gdy zajdzie taka potrzeba.
• rozszerzalność – jak wyżej.
• czy projekt żyje – głupio by było, gdyby się okazało, że rozwój użytego gemu zatrzymał się wiele miesięcy temu. Bardzo ważna jest możliwość otrzymania pomocy, gdy znajdziemy bug, lub będziemy mieli z czymś problem.

Zawsze można również zadać pytanie na blipie z tagiem #ruby lub forum.

Uwierzytelnianie

Devise jest obecnie najprostszym rozwiązaniem, jego jedyną wadą (zaletą?) jest to, że bardzo dynamicznie się zmienia.

Wyszukiwanie

Thinking Sphinx. Kropka.

Przechowywanie plików i obrazków

Paperclip. Warto zajrzeć również do innych projektów ze stajni thoughtbot, bo są to zawsze produkcje warte polecenia.

Testowanie

Użyj Rspeca, Cucumbera i Capybary. Ponieważ można ten zestaw uznać za standardowy, warto się nimi pobawić i ewentualnie dopiero gdy zauważymy jego wady, poszukać alternatywy. Warto się również zaprzyjaźnić z factory girl.

Layouty

Erb jest brzydki i passe. Haml jest ładny i dżezi.

Inherited resources

Kiedy już zostaniesz fanatykiem REST’u, dobrze zacząć się rozglądać za czymś w stylu Inherited Resources i zacząć pisać kontrolery w bardziej deklaratywnym stylu.

Continuous Integration

Chyba nikogo nie trzeba przekonywać do korzyści jakie daje CI. Najprościej postawić serwer continous integration można z użyciem Integrity.

Deploy

Mam nadzieję, że nie wrzucasz kodu na serwer poprzez FTP? Do tego służy Capistrano. I tyle w tym temacie.

Obsługa błędów

Instalacja Hoptoadapp sprowadza się do kilku komend, dzięki którym dostaniesz email z każdym błędem, który się pojawił na produkcji i jedno miejsce, w którym tymi błędami możesz zarządzać. Jeśli wystarczy Ci jeden użytkownik i projekt, to jest również plan darmowy.

Mierzenie wydajności

Sposób w jaki New Relic zbiera i prezentuje informacje o obciążeniu jest imponujący. Często jeden rzut oka wystarczy, by zorientować się, co powoduje problemy z wydajnością. W wersji podstawowej daje podgląd ostatnich 30 minut.

Serwer www

Użyj Nginxa z mod_rails. Zużywa trochę mniej zasobów niż Apache, jest banalny w instalacji i konfiguracji i napisany przez człowieka z naszej wschodniej granicy (w sumie północnej).

Paginacja

Na koniec niepodważalny kanon służący do paginacji: Will Paginate.

Na koniec

Jeśli uważasz że do czegoś istnieje lepsze rozwiązanie napisz w komentarzu (flame! flame!) A jeśli uważasz, że ta lista jest przydatna i myślisz, że warto, by było regularnie aktualizowana, to napisz tym bardziej.

Po co mi to?

W większości porządnych systemów operacyjnych Ruby jest instalowany domyślnie lub dostępny na wyciągnięcie ręki (czyt. na wywołanie apt-get, yum czy innego port). Trzeba jednak pogodzić się z – jedyną słuszną – wersją dostępną w pakietach systemowych lub podjąć walkę i konfigurować, kompilować i instalować żądaną wersję ręcznie. Tu nie koniec schodów, gdyż któregoś radosnego dnia przychodzi czas na instalację 1.9 i mamy kłopot. Siedem rozgrzebanych projektów wykorzystujących 1.8 pewnie nie będzie zadowolonych kiedy nagle ?o zwróci "o" zamiast 111. Niektóre dystrybucje przygotowały się na to i dystrybuują pliki binarne z suffixami 18 lub 19. Mamy wtedy już 2 opcje. Ale co z JRuby? A co z gemami?

I tak narodził się RVM.

Dla niecierpliwych:

$ rvm install 1.9.2
$ rvm use 1.9.2
$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.3.0]
$ rvm use system
$ ruby -v
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10]

Jak zacząć?

Sugerowaną metodą instalacji jest wykorzystanie skryptu dostarczonego przez autora. Jedna komenda załatwi 95% instalacji – sklonuje repozytorium z GitHuba, przygotuje katalog w $HOME i wgra wszystkie skrypty RVMa:

$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

Po zakończeniu skryptu należy tylko dodać jedną linię na końcu .profile (lub .bash_profile etc):

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

Pamiętaj, aby dodać tę linię po wszystkich zmianach w $PATH. Inaczej mogą one nadpisać ścieżki ustawianie przez RVM (tak dzieje się np. z MacPortsami, które zawsze doklejają swoje ustawienia ścieżek na końcu .bash_profile).

Aby zobaczyć listę dostępnych środowisk wywołaj:

$ rvm list known

Lista aktualnie zawiera MRI w wersjach 1.8.6, 1.8.7, 1.9.1 i 1.9.2 (każda w kilku odmianach), kilka wersji JRuby, Rubiniusa, REE, MagLev i MacRuby. Instalujemy wywołując jedynie:

$ rvm install 1.9.2

Jeśli życzysz sobie konkretną wersję, wpisz np:

$ rvm install 1.9.2-head

RVM ściągnie, skonfiguruje i skompiluje wybrany wariant. Cała instalacja odbywa się w katalogu domowym bieżącego usera, pamiętaj więc aby nie używać sudo! Wszystkie wersje Ruby’ego będą sobie grzecznie mieszkały w $HOME/.rvm/rubies, zaś gemy dla każdej z nich w $HOME/.rvm/gems.
Po zakończeniu instalacji przełącz się do wybranej używając:

$ rvm use 1.9.2

Sprawdźmy czy zadziałało

$ which ruby
/Users/Czak/.rvm/rubies/ruby-1.9.2-p0/bin/ruby
$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.3.0]

Co dalej?

W każdej chwili możemy przywrócić stan przed-RVM, czyli wrócić do wykorzystania systemowego interpretera:

$ rvm use system

RVM nie narzuca wykorzystania żadnej z zainstalowanych wersji. Domyślnie każda sesja shella wykorzystuje systemowy interpreter, a dopiero po użyciu rvm use jest on przełączany na jedną z zainstalowanych wersji. Aby wymusić domyślną wersję możesz jednak wywołać:

$ rvm --default 1.9.2

Komenda rvm daje potężną możliwość pracy na wielu interpreterach na raz. Modelowym przykładem jest uruchomienie skryptu na wszystkich – lub niektórych – zainstalowanych wersjach Ruby’ego:

$ rvm list
rvm rubies
=> ruby-1.8.7-p302 [ x86_64 ]
   ruby-1.9.2-p0 [ x86_64 ]
$ echo "puts RUBY_VERSION" > version.rb
$ rvm version.rb
1.8.7
1.9.2

Analogicznie można pracować z gemami, instalując wymagane na kilku wersjach jednocześnie:

$ rvm 1.8.7,1.9.2 gem install rails --no-ri --no-rdoc

Bardzo przydatną funkcją są gemsety, czyli zestawy gemów, między którymi można wygodnie przełączać się i w ten sposób testować np. współpracę naszej aplikacji z nową wersją Rails. Chcąc np. uaktualnić aplikację z 2.3.5 do 2.3.9 możemy utworzyć niezależny zestaw gemów nazwany np. rails239 i w trakcie migracji przełączać się między nim a domyślnym:

$ rvm 1.8.7
$ rails --version
Rails 2.3.5
$ rvm gemset create rails239
'rails239' gemset created (/Users/Czak/.rvm/gems/ruby-1.8.7-p302@rails239).
$ rvm 1.8.7@rails239
$ gem install rails -v 2.3.9
$ rails --version
Rails 2.3.9

Co (jeszcze) dalej?

Powyższe wprowadzenie bynajmniej nie wyczerpuje możliwości RVM. Zachęcam do czytania świetnej dokumentacji dostępnej na stronie domowej projektu. W razie pytań możecie też śmiało walić na nasz rubysferowy blip lub stronę Rubysfery na Facebooku.

Wraz z nadchodzącymi wielkimi krokami Rails 3 sporo mówi się o jednym konkretnym gemie. Ma ułatwić zarządzanie zależnościami w aplikacjach. Ma uprościć pracę przy tworzeniu i korzystaniu z gemów. Generalnie ma zbawić świat, uzależnić wszystkich developerów od siebie, a następnie odpalić cap deploy:skynet i po sprawie… OK, może bez tego ostatniego.

Warto jednak wiedzieć, że Bundler nie jest jedynie częścią Rails 3. Jest niezależnym, potężnym narzędziem, które można – i warto – używać przy tworzeniu wszelkich aplikacji w Rubym.

Dlaczego?

Wszystko zaczęło się w 428 r. p.n.e… nie wróć to znowu nie to. Budowa aplikacji, choćby najmniejszych, wymaga od programisty korzystania z wielu narzędzi. Dzięki dobrodziejstwom open-source mamy do dyspozycji tysiące bibliotek napisanych przez tysiące innych developerów. Każda z nich to żyjący własnym życiem twór, który w trakcie rozwoju i działania naszego projektu może przechodzić przez multum zmian. Jak zapewnić, że zmiana w zewnętrznym module nie wpłynie negatywnie na działanie naszej aplikacji? Jak zadbać o to, by każdy developer w zespole miał identyczne środowisko? Railsy radziły sobie do tej pory korzystając z wpisów config.gem w pliku environment.rb – możliwość określenia specyficznej wersji i źródła gema daje pewne zabezpieczenie, choć mocno ogranicza.

Ale świat nie kończy się na Rails, rozbudowane zależności mogą mieć wszystkie aplikacje w Rubym. Co więcej, same gemy zależą nierzadko od innych gemów i tu zaczynają się poważne schody. Developerzy wynajdowali patenty na zapewnienie zgodności, m.in. hardkodując je w źródle swoich bibliotek. Takie potworki zamiast sprawę rozwiązywać, tylko ją komplikowały.

Bundler ma na celu wszystkie te problemy rozwiązać.

Jak?

Weźmy na warsztat prosty skrypt z jedną zależnością:

require "rubygems"
require "nokogiri"
require "open-uri"

doc = Nokogiri::HTML(open('http://www.google.com/search?q=lukasz+adamczak'))
link = doc.css('h3.r a.l').first
puts link.content

Jeśli w systemie mamy nokogiri, program powinien wypisać:

lans musi być

Jeśli nie, przeczytamy całkiem słuszny komunikat:

no such file to load -- nokogiri

Idąc tradycyjną ścieżką, moglibyśmy teraz zainstalować gem install nokogiri i problem rozwiązany. Pojdźmy jednak The Bundler Way. Instalujemy bundlera (na dzień dzisiejszy aktualna wersja to 1.0.0.rc.2, więc trzeba użyć --pre)

gem install bundler --pre

Otrzymujemy bardzo potężne polecenie bundle, którego możemy użyć już teraz. bundle init utworzy w bieżącym katalogu prosty wzorcowy plik Gemfile, który będzie opisywał wszystkie zależności naszego projektu. Drugi krok to użycie Bundlera w kodzie. Zmieniamy układ require‘ów na:

require "rubygems"
require "bundler/setup"
require "nokogiri"
require "open-uri"

require "bundler/setup" gwarantuje, że projekt będzie wykorzystywał do zarządzania zależnościami właśnie bundlera. W tym momencie cały projekt stał się odizolowaną „bańką”. Całe środowisko jest opisane przez Gemfile. Nie mają znaczenia gemy jakie masz w systemie. Tylko to, co wyraźnie zaznaczysz w Gemfile‘u będzie należało do projektu. Aby się przekonać zainstaluj:

sudo gem install nokogiri

Mogłoby się wydawać, że teraz skrypt wykona się poprawnie. Błąd! Bundler sprawdzi plik Gemfile (domyślnie pusty) i uzna, że nie wie co to nokogiri:

no such file to load -- nokogiri (LoadError)

Dodaj więc do Gemfile linię:

gem "nokogiri"

Teraz skrypt wykonuje się poprawnie. Standardowa kolejność pracy z Bundlerem powinna jednak być odwrotna. Po dodaniu lub zmianie czegokolwiek w Gemfile, pamiętaj o odpaleniu polecenia bundle install. Zajmie się ono instalacją brakujących gemów, w razie potrzeby prosząc nawet o hasło do sudo. Zainstalowane w ten sposób gemy trafiają domyślnie w to samo miejsce gdzie instalowane przez gem install.

bundle ma też kilka innych ciekawych opcji. check do sprawdzenia czy posiadamy wszystko co wymagane.

$ bundle check
Could not find gem 'nokogiri (= 1.4.3.1, runtime)' in any of the gem sources.

(a po instalacji)

$ bundle check
The Gemfile's dependencies are satisfied

console uruchamia irb z wczytanym kompletnym środowiskiem:

$ bundle console
ruby-1.8.7-p249 > Nokogiri
 => Nokogiri

bundle exec umożliwia uruchomienie wykonywalnego skryptu z gema – z tej konkretnej wersji, którą podaliśmy w Gemfile:

$ bundle exec nokogiri http://rubysfera.pl
Your document is stored in @doc...
ruby-1.8.7-p249 >

show i open pozwalają znaleźć i otworzyć katalog ze źródłem gema:

$ bundle show
Gems included by the bundle:
  * bundler (1.0.0.rc.2)
  * nokogiri (1.4.1)

$ bundle show nokogiri
/Users/Czak/.rvm/gems/ruby-1.8.7-p249/gems/nokogiri-1.4.1

$ bundle open nokogiri  # otwiera powyższy katalog w domyślnym edytorze

Aha!

Bundler podczas pracy tworzy automatycznie plik Gemfile.lock na bazie Gemfile oraz stanu Twojego aktualnego środowiska. Jeśli w Gemfile nie określisz wymaganej wersji nokogiri, a w systemie masz zainstalowaną 1.4.1, wtedy do Gemfile.lock trafi:

GEM
  remote: http://rubygems.org/
  specs:
    nokogiri (1.4.1)

Należy pamiętać aby Gemfile.lock dodać do repozytorium wraz z źródłowym Gemfile. To zagwarantuje, że cały zespół będzie pracował na identycznym środowisku. Jeśli w którymś momencie wymusisz w Gemfile wersję:

gem "nokogiri", "1.4.3.1"

wtedy Gemfile.lock zostanie uaktualniony automatycznie przez bundlera i obie zmiany należy wcommitować. Po każdej zmianie w Gemfile (a właściwie jak często się da, np. po git pull) warto uruchamiać bundle install aby zsynchronizować oba pliki i – w razie potrzeby – uaktualnić lokalne środowisko.

Na koniec

Takim krótkim tekstem ledwo musnąłem powierzchnię Bundlera. Może jednak przekonałem kogoś, że jest to narzędzie warte uwagi i jednocześnie łatwe w użyciu. Warto już teraz wyrobić sobie nawyk wywoływania bundle init zaraz po git init, niezależnie od rodzaju budowanej aplikacji. Bundler może w niedługim czasie wprowadzić trochę ładu do Rubinowego światka, na czym skorzysta każdy developer.

Aby dowiedzieć się więcej:

• http://gembundler.com/v1.0/index.html
• http://github.com/carlhuda/bundler
• http://railscasts.com/episodes/201-bundler
• http://asciicasts.com/episodes/201-bundler
• http://yehudakatz.com/2010/07/26/whats-new-in-bundler-1-0-0-rc-1/

Zainspirowani komentarzem Huberta pod naszym ostatnim postem dotyczącym cucumbera, postanowiliśmy bliżej się przyjrzeć jego alternatywie, czyli Steakowi.

Co to?

Jednym zdaniem: Steak umożliwia pisanie testów akceptacyjnych w czystym Rubim.

Dla kogo?

Steak jest dla wszystkich, którym przeszkadza narzut związany z pisaniem testów przy użyciu Cucumbera. Jedną z największych zalet “ogórka”, jest jego naturalny język. Teoretycznie umożliwia on nietechnicznym osobom przygotowywanie scenariuszy, które po drobnych modyfikacjach mogą być przekształcone przez programistę w pełnoprawne testy akceptacyjne. Prawda jest jednak taka, że w większości przypadków scenariusze pisane są przez programistów dla programistów. Z takiego założenia wyszli twórcy Steaka. Pozbyli się więc pisania kroków i konieczności ich późniejszego definiowania, scenariusze są po prostu kodem. Oczywiście stek możemy podać z Capybarą (to coś pokrewnego do świnki morskiej), Webratem, Rspec, Factory Girl itp.

Jak to wygląda?

Przykładowy scenariusz cucumbera:

Scenario: User signs in with invalid email address
  Given a user exists with email: "email@person.com", password: "password"
  When I go to the sign in page
  And I fill in "email" with "somewrongemail"
  And I fill in "password" with "password"
  And I press "Login"
  Then I should see "Invalid e-mail address"

Ten sam scenariusz z użyciem steaka może mieć następującą składnię (doprawione capybarą):

scenario "User signs in with invalid email address" do
  User.create!(:email => "email@person.com", :password => "password"
  visit '/sign_in'
  fill_in "email", :with => "somewrongemail"
  fill_in "password", :with => "password"
  press "Login"
  page.should have_content("Invalid e-mail address")
end

Całkiem zgrabne, prawda?

Co dalej?

Wszystkich zainteresowanych odsyłamy na stronę projektu oraz polecamy szybki tutorial.

Mimo tego, że w naszym zespole scenariusze oglądają tylko programiści i scrum master, na razie nie zanosi się na to, żebyśmy zaczęli przyrządzać surowe steki. Przyzwyczaiłem się do składni Cucumbera, a przy użyciu pickle i odrobinie wprawy, można naprawdę szybko pisać scenariusze. Podoba mi się również warstwa abstrakcji, którą narzuca Cucumber, ponieważ pozwala mi lepiej skupić się na opisaniu i zrozumieniu zadania z punktu widzenia użytkownika. Widocznie jestem wegetarianinem.

O DataMapperze, czyli ORM w Rubym, zaczęło być głośno przy okazji Merba. Mogłoby się wydawać, że ogłoszenie połączenia Railsów z Merbem, sprawi, że DataMapper przestanie być rozwijany. Tak się jednak nie stało i stał się on chyba drugim po ActiveRecordzie ORMem w Rubiowym środowskiu. W trakcie tegorocznego RailsConf została opublikowania wersja 1.0.

Przecież jest już ActiveRecord

Po co nam DataMapper? Po pierwsze oczywiście można ograniczyć się do stwierdzenia, że konkurencja jest dobra i wymusza rozwój. Ale kilka konkretnych cech, które mogą zachęcić do przyjrzenia się mu bliżej to:

• Jeden rekord = jeden obiekt – każdy rekord w tabeli jest reprezentowany przed tylko jeden obiekt. Pozwala to na zwiększenie szybkości i oszczędza pamięć.
• Czysty Ruby – nie da się używać SQL’a w DataMapperze, wszystko jest pisane w Rubym. Chroni to przed nadużywaniem zapytań SQL i daje większą niezależność od konkretnej bazy danych. Mimo, że można pisać SQL’owe zapytania, to twórcy uważają, że dostarczone helpery sprawiają, że w większości przypadków nie jest to konieczne.
• Adaptery – nie jest wymagane korzystanie z relacyjnej bazy danych. Istnieje ponad 40 adapterów, umożliwiających podłączenie DataMappera między innymi do CouchDB, YAMLa, CVS, Sphinxa, albo np API google video.
• Kolumny definiowane jawnie – wszystkie kolumny należy zdefiniować w modelu. Na pierwszy rzut oka wydaje się to niepotrzebnym wysiłkiem, ale dzięki temu znika ActiveRecordowa “magia” i wszystkie pola są od razu widoczne. Nie ma również potrzeba pisać migracji, wystarczy użyć metody auto_migrate, a baza zostanie uaktualniona do wersji przechowywanej w modelach.
• Domyślne opóźnione ładowanie (lazy loading) – rekordy ładowane są w tle dopiero w momencie, gdy wymagany jest do nich dostęp, pozwala to DataMapperowi na zwiększanie wydajności, poprzez zastosowanie prostych reguł. Na przykład dzięki temu poniższa linijka wykona tylko dwa zapytania, niezależnie od tego ile rekordów jest w bazie.

 Zoo.all.each { |zoo| zoo.exhibits.to_a }

Oczywiście punkty te można potraktować zarówno jako wady i zalety, zależy czego oczekujemy od ORMa. Ale jeśli jeszcze nie jesteście przekonani by spróbować, można zajrzeć na stronę Why DataMapper.

Jak wypróbować?

Najprościej po prostu zacząć od przewodnika na oficjalnej stronie. Miłej zabawy.

Zmuszenie Authlogica do współpracy z kontami Google i Facebook Connectem jednocześnie było jednym z bardziej frustrujących doświadczeń w mojej pracy z Railsami. Z pozoru wszystko wygląda pięknie – Authlogic daje się rozszerzać i istnieją moduły OpenID, Facebook Connect czy OAuth współpracujące z nim. W rzeczywistości każdy taki moduł, pisany przez kogo innego wymaga dodatkowych śmieci w modelu użytkownika i po miesiącu nikt już nie pamięta skąd w Userze te 10 dziwnych metod…

I tak przeglądając alternatywy dla Authlogica na piątym miejscu listy w Ruby-Toolboksie znalazłem wybawienie – rpx_now

Co to?

RPX to usługa, która dość powoli zdobywa popularność w Internecie. Jej podstawową rolą jest ułatwienie integracji budowanych aplikacji (stron, serwisów, …) z kontami Facebook, Google, Twitter i innymi – kompletna lista zawiera 12 sytemów uwierzytelniania. Decydując się na RPX, po stronie developera pozostaje jedynie prosta konfiguracja usług w panelu RPX oraz wykorzystanie jednego – a nie dwunastu – API. Cała robota w obsłużeniu wszystkich 12 back-endów spada na RPX i – nie ma co ukrywać – system robi to znakomicie, zapewniając jednolity user experience dla każdego użytkownika, niezależnie od wybranej przez niego opcji.

A na dokładkę dla leniwego (jak ja) developera powstał gem rpx_now.

Jak to?

Opis całej funkcjonalności gema mieści się w krótkim README, a zapamiętać wystarczy 4 punkty:

• załóż konto i pobierz klucz API ze strony RPX
• uruchom migrację
• przygotuj widok z logowaniem
• pobierz dane użytkownika z RPX aby zalogować lub zarejestrować Usera

Migracja dodaje jedno pole identifier do modelu User. W widoku należy wstawić skrypt RPX’a z użyciem helperów RPXNow.embed_code lub RPXNow.popup_code, a w jedynej akcji kontrolera zalogować lub zarejestrować użytkownika przy użyciu danych otrzymanych z usługi.

Na koniec

RPX oferuje darmowy plan, który moim zdaniem wystarcza do większości zastosowań. Dopiero bardziej zaawansowane, społecznościowe funkcje zintegrowanych serwisów są dostępne w taryfach płatnych. Jest też haczyk – wersja bezpłatna wyświetla link “Powered by RPX” w okienku logowania. Żadne jednak z tych ograniczeń nie osłabiły mojego zapału do korzystania z RPX i gem rpx_now na pewno trafi do niejednego przyszłego railsowego projektu.

• http://github.com/grosser/rpx_now
• http://github.com/grosser/rpx_now_example

W sekcji “Warte uwagi” prezentujemy narzędzia, biblioteki, gemy, pluginy, które naszym zdaniem na uwagę zasługują, a być może nie są dobrze znane i doceniane wśród developerów. Nie będzie tu dogłębnych tutoriali – tylko kilka słów na zaciekawienie i zaostrzenie apetytu.

W dzisiejszym odcinku: pickle

Co to?

Pickle to gem, który znacznie ułatwia pisanie scenariuszy Cucumbera dla aplikacji railsowych. Nie da się ukryć, że “ogórki” w RoR bywają do siebie podobne. Jest sobie użytkownik, loguje się, klika w przycisk i na końcu widzi napis “Dziękujemy”. Lwią część tych kroków dostajemy za darmo od cucumber-rails – w szczególności wszystkie typu When symulujące interakcję użytkownika z aplikacją i kilka kroków Then sprawdzających zawartość strony po wykonaniu akcji. Pozostaje jednak sporo Givenów i Thenów, które trzeba zdefiniować samemu.

Chyba, że użyjemy pickle.

Jak to?

Instalacja to 3 kroki:

• dodanie wpisu config.gem w environments/cucumber.rb
• instalacja gema
• odpalenie generatora script/generate pickle

Od tego momentu możemy pisać takie cuda:

  Given a user: "Ala" exists with email: "ala@makota.pl"
  And another user: "Marek" exists with email: "marek@zegarek.pl"
  And an admin exists with email: "site@admin.com"
  And user: "Ala" is in that admin's contacts
  ...
  ...
  Then 0 users should exist with email: "marek@zegarek.pl"
  But a user should exist with email: "ala@makota.pl"
  And that user should be happy

Wszystkie powyższe kroki pickle “zrozumie” i obsłuży jak swoje. Wystarczy, że mamy odpowiednie modele i/lub fabryki, pierwsze cztery Giveny przygotują stan “przed”, a trzy ostatnie Theny sprawdzą stan “po”.

Ten mało wyszukany przykład to dopiero początek. Polecam przejrzeć dokumentację i rzucić okiem na multum form, które akceptuje pickle.

Warto wiedzieć

Choć dokumentacja sugeruje, że moduły paths i email są opcjonalne, zdecydowanie polecam dołączenie ich bez zastanowienia. Generator pickle’a jest bardzo ostrożny z nadpisywaniem plików, a dodatkowe funkcjonalności z tych modułów są warte zachodu.

Od razu polecam też odkomentować linię w pickle.rb:

config.map 'I', 'myself', 'me', 'my', :to => 'user: "me"'

Dzięki temu możemy używać zamiennie określeń “I”, “me” itd, a kolejne kroki będą wiedziały o którym użytkowniku mowa.

Pickle świetnie współpracuje z fabrykami Factory Girl lub Machinist. Powyższy przykład z użytkownikami i adminem to w najprostszym przypadku jeden model User i dwie fabryki: user i admin, obie powiązane z tym modelem, a różniące się np. tylko flagą admin lub polem status.

Wszystkie potrzebne informacje – na stronie projektu: http://github.com/ianwhite/pickle