Git jest potężnym narzędziem. Potężnym w podobny sposób jak potężny jest Emacs albo VIM. Git tak jak Emacs czy VIM potrafi przysporzyć kłopotu z najprostszymi czynnościami. Wiele osób korzysta z Gita nie rozumiejąc jego filozofii i znając tylko podstawowe polecenia, tak jak wiele osób korzysta z VIMa używając tylko <ESC>:wq oraz i. Komendy w gicie posiadają setki możliwych kombinacji argumentów. Część komend nazwana jest tak, żeby za nic nie dało się zgadnąć do czego służą (Emacs „auto-fill-mode” anybody?).

Wszystkie te programy po przeskoczeniu początkowych trudności, związanych z nauką nowego sposobu myślenia, powodują znaczny wzrost produktywności u użytkownika.

Jest jeszcze jedna rzecz łącząca Gita z VIMem i Emacsem. Wiele osób nie wie o istnieniu monstrualnej ilości trików pozwalających przyspieszyć i uprzyjemnić swoją pracę z tymi programami. Są to zwykle „sztuczki” rozwiązujące konkretny drobny problem. Na tyle drobny, że osobie napotykającej na niego nie opłaca się szukać bezpośredniego rozwiązania, więc zwykle problem zostaje rozwiązany „na około”.

Postanowiłem zebrać w jednym miejscu kilka takich „sztuczek”.

diff

Jedną z najprzydatniejszych komend w każdym porządnym systemie kontroli wersji jest diff.

Git pozwala porównać ze sobą pliki, commity, branche.

Nie wszyscy jednak wiedzą, że gitowy diff przyjmuje wiele opcji konfigurujących sposób w jaki różnice zostaną wyświetlone na ekranie. Jedną z nich jest –word-diff.

Typowy przypadek użycia tego przełącznika to np. próba wyświetlenia drobnych zmian w bardzo długiej linii. Problem ze zwykłym diffem jest taki, że zmiany zostaną pokazane linia do linii.

git diff

def too_big_if_to_be_true
-    some_very_long_method_name arg_firct, arg_second
+    some_very_long_method_name arg_first, arg_second
end

Patrząc na powyższy kod nie widać od razu co zostało zmienione i na co. Z pomocą przychodzi –word-diff. Po dodaniu tego przełącznika do wywołania git diff otrzymamy następujący rezultat:

git diff --word-diff

def too_big_if_to_be_true
some_very_long_method_name [-arg_firct,-]{+arg_first,+} arg_second
end

W tym wypadku sytuacja wygląda trochę lepiej. Nawias kwadratowy i znaki ‘-’ pokazują nam zastępowany wyraz, nawias klamrowy i znaki ‘+’ pokazują wyraz zastępujący. Wciąż nie jest to jednak forma najbardziej czytelna, szczególnie jeśli trafi nam się kawałek kodu, w którym intensywanie korzystamy z tablicy ([]) albo hasha ({}). W tym wypadku sprawdza się flaga –color-words:

git diff --color-words

def too_big_if_to_be_true
some_very_long_method_name arg_firct,arg_first, arg_second
end

Jeśli odpalimy tą komendę w terminalu, który obsługuje kolory, jakiekolwiek wątpliwości co do wprowadzonych zmian zostaną natychmiast rozwiane. Wyraz zastępowany zostaje pokolorowany na czerwono, wyraz zastępujący na zielono.
Istnieje również możliwość połączenia –word-diff z kolorowaniem:

git diff --word-diff --color

def too_big_if_to_be_true
some_very_long_method_name [-arg_firct,-]{+arg_first,+} arg_second
end

Oczywiście nie ma sensu za każdym razem wpisywać ręcznie –word-diff. Od czego mamy aliasy:

git config alias.dic 'diff --color-words'

ustawia alias ‘dic’ działający w bieżącym repozytorium. Jeśli dodamy –global:

git config --global alias.dic 'diff --color-words'

zmiany zostaną zapisane w naszym pliku .gitconfig, przez co będą działały również w pozostałych repozytoriach.

status

Dużą pomocą dla początkujących użytkowników gita jest wiadomość pokazująca się każdorazowo podczas odpalenia komendy status. Poniżej widać przykładowe wywołanie git status w repozytorium, w którym został zmieniony tylko jeden plik.

git status

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:   app/controllers/application_controller.rb
#
no changes added to commit (use "git add" and/or "git commit -a")

Jak widać więcej niż same zmiany w repozytorium zajmuje tekst objaśniający co z tymi zmianami można zrobić, jak je cofnąć, jak wykonać commit. Ten widok, uszyty specjalnie dla początkujących, nie jest jedynym możliwym sposobem wyświetlenia statusu zmian.

Z pomocą przychodzi opcja –short (w skrócie -s). Jej użycie powoduje, że zamiast wielkiego tekstowego bloba pojawia się zgrabne:

git status -s

M app/controllers/application_controller.rb

Jeśli nie mamy ustawionego wyświetlania bieżącego brancha w shellu warto jeszcze dodać przełącznik –branch. Dzięki niemu na górze wyświetlą się informacje na temat bieżącego brancha.

git status -sb
## master
M app/controllers/application_controller.rb

Można ułatwić sobie życie i dodać powyższą komendę jako alias.

git config --global alias.st 'status -sb'

log

Jedną z częściej używanych, a przy tym mocno niedocenianych komend, jest w gicie log. Większość z nas w normalnej pracy ogranicza się do odpalenia git log bez parametrów, ew. z nazwą pliku, którego log chcemy zobaczyć. git-log to idealny przykład komendy, która w 90% przypadków robi dokładnie to czego od niej oczekujemy bez żadnej pomocy z naszej strony. Na pozostałe 10% przypadków twórcy gita przygotowali mnóstwo opcji pozwalających nam zdecydować co właściwie chcemy zobaczyć, w jakim formacie i w jakiej kolejności.

git-log domyślnie wypisuje historię zmian dokonanych na danym branchu w formacie HASH, AUTOR, DATA, COMMIT_MESSAGE.

Tak naprawdę najbardziej interesujące w logu są treści commitów. Nie zawsze jednak same teksty wystarczają do znalezienia tego czego szukamy (kto nigdy nie wpisał bzdurnego COMMIT_MESSAGE niech pierwszy rzuci kamień!).

Bardzo przydana jest możliwość wypisania nie tylko samych commitów, ale także pokazania ich zawartości w formie patchy. Służy do tego polecenie:

git log -p


commit 69dc58e59f11436b4a153537f63d7db3baa8552e
Author: Maciej Gajewski <email>
Date:   Fri Sep 16 16:24:34 2011 +0200

Message 1

diff --git a/abc b/abc
index 11921d5..d8a2f87 100644
--- a/abc
+++ b/abc
@@ -1,3 +1,7 @@
Master

Master end
+
+Master 1
+
+Master 2


commit aa1d275d9c9cba634297c864301238c6903c5e08
Author: Maciej Gajewski <email>
Date:   Fri Sep 16 16:23:08 2011 +0200

added to master

diff --git a/abc b/abc
index e69de29..11921d5 100644
--- a/abc
+++ b/abc
@@ -0,0 +1,3 @@
+Master
+
+Master end

Odpalone bez parametrów pokaże nam logi bieżącego brancha łatka po łatce, co kiedy zostało dodane i przez kogo. Jeśli wpiszemy po -p nazwę pliku będziemy mogli zobaczyć zmiany w podanym pliku – poprawka po poprawce.

Zdarzają się sytuacje, że log -p zwraca za dużo informacji. Czasami chcemy po prostu zobaczyć jakie pliki były zmieniane, a nie koniecznie każdą jedną zmianę w nich. W tym celu musimy odpalić git-log z parametrem –stat

commit 78dbfbe86609759c33f9c59362f6a2813d2c3e13
Author: Maciej Gajewski <mail>
Date:   Fri Sep 16 16:28:53 2011 +0200

Added config and index files

config.xml |    9 +++++++++
index.html |   17 +++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)


commit fa0950503af962cccdccd1bcb9b9380501faed28
Author: Maciej Gajewski <mail>
Date:   Fri Sep 16 16:27:36 2011 +0200


Added main ruby file


main.rb |    3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

Git-Log pozwala nam na na wyświetlenie listy zmian na wszystkich branchach, nie tylko na bieżącym. Co więcej, możemy wyświetlić zmiany tylko na niektórych branchach.

Na przykład:

git log b1 b2

wyświetli wszystkie commity, które występują na branchu b1 i te które występują na branchu b2.
Niezwykle przydaje się możliwość wyświetlenia commitów, które znajdują się na jednym branchu, ale nie ma ich jeszcze na drugim.
Pisząc:

git log master..b1

możemy zobaczyć które commit są na branchu b1, ale nie zostały jeszcze zmergowane do mastera.

Git potrafi filtrować historię po dacie.

git log --since=2.hours.ago --until=10.minutes.ago

Co robi powyższy kod jest w miarę jasne. Wyświetla wszystkie commity powstałe najwyżej dwie godziny temu i nie później niż dziesięć minut temu. Zamiast hours i minutes można wstawić m.in. days, years, months, weeks itd.

Na koniec zostawiłem coś o co chyba najczęściej pojawiają się pytania w kontekście polecenia „log”.

git log -S "def login"

wyświetli wszystkie commity, które zawierają „def login”. Zawierają nie w COMMIT_MESSAGE tylko w plikach dodanych w konkretnym commicie.

Szukania ciąg dalszy

Załóżmy, że mamy jakąś zmianę ale nie wiemy na ilu gałęziach ona się znajduje. Ten problem rozwiązuje git-brach –contains.

git branch --contains=8d38c3ec11ee6247ff929f264815b3f508fc47b2
b1
b2
* master

Polecenie to wypisuje nazwy branchy na których znajduje się commit o podanym SHA1.

Wszystkie powyższe argumenty można łączyć, a więc możliwe jest znalezienie np. definicji funkcji dodanej w zeszłym tygodniu przez autora A, która nie została jeszcze z mergowana z masterem. Nie jest ważne, żeby nauczyć się koniecznie tych poleceń na pamięć (chociaż warto!). Najważniejsze jest żeby wiedzieć, że git posiada takie możliwości. Po detale można sięgać w razie potrzeby

Dla wzrokowców

Na koniec tej sekcji bonus. Jeśli nie znasz jeszcze – wpisz do konsoli w swoim największym projekcie

git log --oneline --graph

Aha! Istnieje jeszcze jeden „hack” pasujący do kategorii „log” chociaż nie mający z git-log wiele wspólnego.

git show :/regexp

znajduje i wyświetla ostatni commit które COMMIT_MESSAGE pasuje go wzorca regexp.

Takich trików jest naprawdę mnóstwo i naprawdę warto się zabrać za solidną naukę obsługi gita. To się opłaca.

RVM to narzędzie, bez którego ciężko sobie wyobrazić pracę z Rubym. Począwszy od instalacji języka, przez szybkie i wygodne przełącznie się między różnymi konfiguracjami, a na eksperymentowaniu z najnowszymi wydaniami kończcc. Oto 10 porad, które przydadzą się przy codziennej pracy z RVM. Jeśli nie wiesz dlaczego warto korzystać z RVM, zajrzyj do artykułu opisującego Ruby Virtual Machine.

1. .rvmrc

Plik .rvmrc uważam za niezbędny w codziennej pracy z RVM. Jeśli w dowolnym katalogu umieścisz plik .rvmrc, to przy wejściu do tego katalogu, automatycznie zostanie załadowana odpowiednia wersja rubiego i gemset. Bardzo szybko można utworzyć taki plik poleceniem:

echo 'rvm use 1.9.2@projekt_x' > .rvmrc

Utworzony zostanie plik o zawartości:

rvm use 1.9.2@projekt_x

Teraz przy każdym wejściu do tego katalogu ładowana będzie wersja rubiego 1.9.2 z gemsetem projekt_x.

2. Globalny gemset

Zazwyczaj dla każdego projektu tworzę osobny gemset, zazwyczaj potrzebuję wtedy bundlera, by zainstalować potrzebne gemy, niestety bundlera trzeba za każdym razem instalować wcześniej ręcznie. RVM dostarcza globalnych gemsetów, dla każdego zainstalowanego intepretera. Użycie komend:

rvm use gemset global
gem install bundler

sprawi, że w każdym gemsecie w danej wersji rubiego bundler będzie dostępny.

3. Importowanie/eksportowanie gemsetów

Jeśli chcesz stworzyć zapisać aktualny gemset, możesz wyeksportować listę gemów do pliku. Możliwe jest kilka sposobów.

# eksportuje aktualny gemset do pliku defaults.gem
rvm gemset export     

# eksportuje konkrenty gemset do pliku projekt_x.gem
rvm 1.9.2@projekt_x   

# eksportuje aktualny gemset do pliku projekt_x.gem
rmv gemset export projekt_x.gem

Importowanie pliku jest zgodne z konwencją:

rvm gemset import projekt_x

Polecenie to zaimportuje gemy z pliku projekt_x.gems do aktualnego gemsetu.

4. Kopiowanie gemsetów między róznymi wersjami Rubiego

Kopiowanie może się odbyć również bez importowania i eksportowania. Wystarczy jedno polecenie.

rvm gemset copy 1.8.7@rails3 1.9.2-head@rails3

5. Rubinius i inne wersje Rubiego.

RVM daje Ci szansę bezproblemowego zainstalowania rzedziej używanych wersji, takich jak Rubinius, lub Jruby. Wpisz:

rvm install rbx

I zobacz jak twój projekt zachowuje się z Rubiniusem, tak to jest takie proste. Pełna lista obsługiwanych interpreterów dostępna jest na oficjalnej stronie RVM.

6. Haki (hooks)

Możliwe jest zdefiniowanie akcji, które zostaną wywołane przed i po określonych komendach RVMa, takich jak after_use before_install, after_install, after_do oraz after_cd. Na przykład można utworzuć plik ~/.rvm/hooks/after_install z zawartością:

echo "Ścieżka interpretera $rvm_ruby_home"

Skrypt ten zostanie wywołany po każdym zainstalowaniu nowej wersji Rubiego. Korzysta on ze zmiennej środowiskowej $rvm_ruby_home (pełna lista zmiennych dla RVM wraz z opisami).

7. Uruchamianie programów (i testów) na wielu wersjach Rubiego

Jeśli mamy program pinkie_pie.rb, następująca komenda uruchomi go na wszystkich zainstalowanych wersjach Rubiego.

rvm ruby pinkie_pie.rb

Możliwe jest ograniczenie wykonywania do konkretnych wersji. Jeśli chcemy sprawdzić tylko 1.9.2 i Rubinusa, to piszemy:

rvm 1.9.2,rbx ruby pinkie_pie.rb

Jest to szczególne przydatne przy odpalaniu testów (np. do sprawdzania pod jakimi wersjami działa Twój gem):

rvm rake test

Możliwe jest ustalenie formatu raportu przy pomocy opcji --json oraz --yaml. Oczywiście działa to też z Rspeckiem.

8. Przydatne komendy

Można użyć konkrentego gemsetu i przy okazji stworzyć plik .rvmrc:

rvm use 1.9.2@rails3 --rvmrc

Krok dalej. Stworzenie gemsetu wraz z plikiem .rvmrc:

rvm --create --rvmrc 1.9.2@projekt_x

Instalacja gemów dla różnych wersji Rubiego naraz:

rvm 1.8.7,1.9.2 gem install rails

Aby automatycznie tworzyć gemset przy pierwszym użyciu można w pliku ~/.rvmrc ustawić następującą flagę:

rvm_gemset_create_on_use_flag=1

9. Graficzna nakładka

Ostatnio powstało GUI do RVM, dostępne tylko na OS X. Co prawda jest bardzo ładne, ale skoro przebrneliście przez ten artykuł, to raczej nie powinno być wam potrzebne.

10. Alternatywa

Jeśli z jakichś względów RVM Ci nie odpowiada, zawsze możesz użyć lżejszego narzędzia o nazwie Rbenv. Osobiście nie widzę powodu by z niego korzystać.

Macie do dodania inne ciekawe rady odnośnie RVM?

Aplikację stworzoną w poniższym artykule można ściągnąć z githuba lub zobaczyć jak działa na heroku. Do jej stworzenia wykorzystałem aplikację stworzoną w railscaście 258.

Aby dodać nowego autora możemy przejść pod adres /author/new, ale gdy dodajemy książkę i chcemy przypisać do niej jeszcze nie istniejącego autora, lepiej będzie wyświetlić formę dodawania autora używając ajax’a. Do wyświetlenia formy użyjemy faceboxa, napisanego w jquery przez Chris’a Wanstrath’a.

Zaczynamy – instalacja faceboxa!

Ściągnijmy faceboxa z githuba, rozpakujmy i umieśćmy odpowiednio pliki w naszej aplikacji: facebox.css w public/stylesheets, facebox.js w public/javascripts, loading.gif i closelabel.png w public/images.

Teraz wpiszemy ścieżki do obrazków faceboxa w pliku public/javascripts/facebox.js:

loadingImage: '/images/loading.gif',
closeImage: '/images/closelabel.png'

oraz umieścimy arkusz css i plik z kodem javascript w pliku layoutu app/views/layouts/application.html.erb:

<%= stylesheet_link_tag "application", "token-input-facebook","facebox" %>
<%= javascript_include_tag :defaults, "jquery.tokeninput","facebox" %>

Formularz na faceboxie – jakie to proste

Teraz przejdźmy do wyświetlenia formularza dodawania nowego autora za pomocą faceboxa.
Musimy dodać odpowiedni link w pliku app/views/books/_form.html.erb:

<%= f.label :author_tokens, "Authors" %>
<%= link_to 'Add new author', new_author_path, :remote => true %>

Powyższy link posiada opcję :remote, która spowoduje wywołanie akcji new za pomocą ajaxa. Aby to zadziałało, musimy lekko zmodyfikować akcję w kontrollerze AuthorsController.

Osługa naszego żądania js w kontrolerze dzieki Railsom jest bardzo prosta. Wystarczy dodać nowy widok app/views/authors/new.js.erb. Po kliknięciu linku, metoda rozpozna, że żądanie jest w formacie js i wyświetli widok formatu js. Teraz dodajmy do widok kod który wyrenderuje nową akcję za pomocą faceboxa:

$.facebox('<%= escape_javascript(render :template => 'books/new.html') %>');

Powyższy kod wygeneruje formę dodawania nowego autora na faceboxie (app/views/books/new.html.erb ). Podając argument dla opcji :template musimy wskazać html-owy widok. Tworząc aplikację Rails z rozbudowaną obsługą Ajaxa znacznie częściej używany partiali, jednak nasze zadanie można wykonać bez modyfikacji istniejącego kodu używając opcji template.

Jeśli chcecie się dowiedzie więcej na temat używania faceboxa, w pliku public/javascripts/facebox.js są bardzo dobrze opisane wszystkie możliwości użycia.

Dodawanie autora – wreszcie coś działa!

Teraz chcemy wysłać nasz formularz i stworzyć nowego autora. Normalnie użylibyśmy opcji

:remote => true

w definicji formularza, ale w naszym przypadku chcemy użyć ajax’a jedynie na faceboxie. Aby uczynić tylko formularz na faceboxie ajaxowym, dodajmy poniższą linijkę w pliku app/views/books/new.js.erb:

$('#facebox form').data('remote','true');

Kod doda htmlowy atrybut data-remote=’true’ w znaczniku form, dzięki czemu plik public/javascript/rails.js przechwyci wysłanie formularza i wykona żądanie ajaxowe. Formularz jest wysyłany do akcji create w AuthorsController i potrzebuje templata w formacie js. Zatem tworzymy plik app/views/authors/create.js.erb, za pomocą którego zamykamy faceboxa:

$(document).trigger('close.facebox');

Ponieważ akcja create inaczej zachowuje się przy żądaniu html i js, musimy użyć bloku respond_to. W przypadku żądania html przekierowujemy użytkownika na stronę autora, a przy żądaniu js wyświetlamy opisany wyżej widok js.

def create
  @author = Author.new(params[:author])
  if @author.save
    respond_to do |format|
      format.html { redirect_to @author, :notice => "Successfully created author." }
      format.js
    end
  else
    render :action => 'new'
  end
end

Gotowe? Jeszcze parę poprawek…

Osiągnęliśmy nasz cel, ale musimy jeszcze wprowadzić parę usprawnień. Kiedy obiekt @author nie może być zapisany, powinniśmy wyświetlić formularz dodawania ponownie na faceboxie. W app/models/author.rb dodajmy walidację:

validates :name, :presence => true

Od teraz nie możemy dodać autora bez nazwy. Kiedy spróbujemy, dostaniemy błąd walidacji, który chcemy wyświetlić na faceboxie.

Na początku zmieńmy akcję create aby użyć widoku js,  wprzypadku gdy nie uda nam się zapisać rekordu:

def create
  @author = Author.new(params[:author])
  if @author.save
    respond_to do |format|
      format.html { redirect_to @author, :notice => "Successfully created author." }
      format.js
    end
  else
    respond_to do |format|
      format.html { render :action => 'new' }
      format.js
    end
  end
end

I zmodyfikujmy plik app/views/books/create.js.erb aby wyświetlić formularz z błędami na facebox’ie przy nie udanym zapisie obiektu @author:

<% if @author.save %>
  $(document).trigger('close.facebox')
<% else %>
  $('#facebox .content').html('<%= escape_javascript(render :template => 'authors/new') %>')
  $('#facebox form').data('remote','true');
<% end %>

Wreszcie mamy działające ajaxowe dodawanie autorów, wprowadzając minimalne zmiany w kodzie.

Jeszcze jedno malutkie usprawnienie.

Wprowadźmy jeszcze jedną małą zmianę – usuńmy link ‘Back to list’ z formy na faceboxie. Na faceboxie ten link jest kompletnie bezużyteczny. Zrobimy to za pomocą poniższej linijki jQuery:

$('#facebox .content p:last').remove();

Po prostu usuwamy ostatni tag w formularzu generowanym na faceboxie.

Powyższy kod dodajemy na końcu pliku app/views/authors/new.js.erb i na końcu sekcji else w app/views/authors/create.js.erb. To już naprawdę koniec!

Na heroku możesz zobaczyc demo aplikacji, a jej kod na githubie.
Wszystkie zmiany znajdują się w commicie cf13adacdff595059dc6eba0fcb33c0204ad6714

Jeśli chcesz wiedzieć więcej o działaniu javascripta w Rails 3, odwiedź poniższe linki:
http://rubysfera.pl/2010/11/javascript-w-rails-3/
http://www.simonecarletti.com/blog/2010/06/unobtrusive-javascript-in-rails-3/
http://www.alfajango.com/blog/rails-jquery-ujs-now-interactive/

Jakiś czas temu przetoczyło się w blogosferze dyskusja o wyższości test/unit nad rspekiem. Uważam, że to tak naprawdę kwestia gustu, ale ponieważ dużo osób jest zmęczonych rspekiem, dziś pora na pokazanie przykładowej sesji TDD właśnie w oparciu o test/unit.

Teoria TDD w wielkim skrócie

Dla tych którzy nie wiedzą na czym polega Test Driven Development (a są tacy), przypominam, że to proces produkcji oprogramowania, który składa się z trzech etapów:

1. Napisz test, który sprawdza funkcję, którą piszesz. Test powinien zakończyć się błędem.
2. Napisz kod, który sprawi, że test zacznie działać.
3. Zrefaktoryzuj otrzymany kod, posiłkując się przygotowanym testem.

Po wykonaniu takiej iteracji otrzymuje sensowny, otestowany kod i możemy zająć się pisaniem kolejnej funkcji.

Praktyka testowania

W tym przykładzie napiszemy metodę average dla klasy Array. Zacznijmy od przygotowania testu, który sprawdzi dwa proste przypadki.

Przygotujemy dwa pliki: lib/average.rb – który będzie zawierał kod (na razie pusty) oraz test/test_average.rb, w którym umieścimy nasz test:

require 'lib/average'
require 'test/unit'

class TestAverage < Test::Unit::TestCase

  def test_simple
    assert_equal '4,5', [4,5].average
    assert_equal '3', [2,2,3,5].average
  end

end

Na potrzeby testu ładujemy plik z naszym kodem i bibliotekę test/unit. Klasa testowa musi dziedziczyć po Test::Unit::TestCase. Metoda testowa powinna zaczynać się od słowa test, dzięki czemu zostanie ona wywołana. Wszystkie metody bez tego przedrostka traktowane są jako pomocnicze i nie są automatycznie wywoływane przy uruchomienia. Tak przygotowany test uruchamiamy poleceniem:

ruby test/test_average.rb

Jeśli dobrze napisaliśmy test, to powinniśmy otrzymać błąd. Jeśli test jest spełniony bez pisania kodu, to znaczy, że albo gdzieś już mamy odpowiednie metody, albo (co bardziej prawdopodobne), test został napisany błędnie.

Loaded suite test/test_average
Started
E
Finished in 0.000278 seconds.

  1) Error:
test_simple(TestAverage):
NoMethodError: undefined method `average' for [4, 5]:Array
    test/test_average.rb:5:in `test_simple'

1 tests, 0 assertions, 0 failures, 1 errors

Test klarownie mówi nam, że nie posiadamy metody average w klasie Array. Aby ją dodać należy otworzyć klasę Array. Istnieją bardziej eleganckie sposoby jej dodania, my wykorzystamy najbardziej prymitywny z nich, to jest artykuł o TDD i kropka. W pliku lib/average.rb zdefiniujmy naszą metodę.

class Array

  def average
  end

end

Ponownie odpalamy test i widzimy, że nasza metoda zwraca niewłaściwy wynik:

Loaded suite test/test_average
Started
F
Finished in 0.024466 seconds.

  1) Failure:
test_simple(TestAverage) [test/test_average.rb:6]:
<"4,5"> expected but was
.

1 tests, 1 assertions, 1 failures, 0 errors

Pora zatem zaimplementować średnią w najbardziej prosty i prymitywny sposób:

class Array

  def average
    sum = 0
    count = 0
    self.each do |element|
      sum += element
      count += 1
    end
    sum/count
  end

end

Loaded suite test/test_average
Started
F
Finished in 0.004176 seconds.

1) Failure:
test_simple(TestAverage) [test/test_average.rb:7]:
<"4,5"> expected but was
<4>.

Prawie zadziałało. Niestety ponieważ sum jest liczbą całkowitą, otrzymany wynik, też jest całkowity. Pora to naprawić.

class Array

  def average
    sum = 0
    count = 0
    self.each do |element|
      sum += element
      count += 1
    end
    sum.to_f/count
  end

end

Loaded suite test/test_average
Started
F
Finished in 0.004232 seconds.

1) Failure:
test_simple(TestAverage) [test/test_average.rb:7]:
<"4,5"> expected but was
<4.5>.

1 tests, 1 assertions, 1 failures, 0 errors

Ponieważ jesteśmy gapy, w teście podaliśmy, że wynik ma być łańcuchem znaków, a przecież również powinien być liczbą. Poprawiamy test, usuwając cudzysłowy.

require 'lib/average'
require 'test/unit'

class TestAverage < Test::Unit::TestCase

  def test_simple
    assert_equal 4.5, [4,5].average
    assert_equal 3, [2,2,3,5].average
  end

end

Loaded suite test/test_average
Started
.
Finished in 0.000239 seconds.

1 tests, 2 assertions, 0 failures, 0 errors

Hurra! Udało się, teraz warto zastanowić się nad ciekawszym przypadkiem: np. co się stanie, gdy tablica będzie pusta. W takim przypadku wynik powinien być nilem, dodajemy zatem drugi test.

require 'lib/average'
require 'test/unit'

class TestAverage < Test::Unit::TestCase

  def test_simple
    assert_equal 4.5, [4,5].average
    assert_equal 3, [2,2,3,5].average
  end

  def test_empty_array
    assert_nil [].average
  end

end

Loaded suite test/test_average
Started
F.
Finished in 0.00441 seconds.

1) Failure:
test_empty_array(TestAverage) [test/test_average.rb:12]:
 expected but was
.

2 tests, 3 assertions, 1 failures, 0 errors

Test nam przypomniał o wierszyku: pamiętaj cholero, nie dziel przez zero. Musimy obsłużyć taki przypadek.

class Array

  def average
    sum = 0
    count = 0
    each do |element|
      sum += element
      count += 1
    end
    sum.to_f/count if count != 0
  end

end

Loaded suite test/test_average
Started
..
Finished in 0.000383 seconds.

2 tests, 3 assertions, 0 failures, 0 errors

Jest dobrze; mamy test, mamy działający kod, to jest ten moment, w którym należy na kod spojrzeć krytycznie. Nie musimy ręcznie liczyć elementów tablicy, możemy skorzystać z metody size.

class Array

  def average
    sum = 0
    each do |element|
      sum += element
    end
    sum.to_f/size unless size == 0
  end

end

O dwie linijki prościej. Sprawdźmy, czy to działa:

Loaded suite test/test_average
Started
..
Finished in 0.000383 seconds.

2 tests, 3 assertions, 0 failures, 0 errors

Czy można to jeszcze skrócić? Przy pomocy inject tak.

class Array

  def average
    inject{ |sum, element| sum + element }.to_f / size unless size == 0
  end

end

Loaded suite test/test_average
Started
..
Finished in 0.000383 seconds.

2 tests, 3 assertions, 0 failures, 0 errors

Zadziałało, może jeszcze bardziej?

class Array

  def average
    inject(:+).to_f / size unless size == 0
  end

end

Inject otrzymał symbol operacji, którą ma przeprowadzić na wszystkich elementach tablicy. Ponieważ operacją tą jest dodawanie, to należy operator dodwania + poprzedzić znakiem symbolu :. Gdyby metodą, którą chcemy wykonać było foo, to kod musiałby wyglądać tak: inject(:foo). Sprawdźmy, czy ta przypominającą emotikonkę konstrukcja zadziała:

Loaded suite test/test_average
Started
..
Finished in 0.000312 seconds.

2 tests, 3 assertions, 0 failures, 0 errors

Tak oto przeszliśmy przez trzy fazy TDD. Napisaliśmy test; napisaliśmy kod, który przechodzi ten test; a potem poprawiliśmy ten kod, żeby wyglądał lepiej. I wcale nie było to takie trudne.

Sporo jednak się zmieniło. Rozwiązania oparte o onclick czy generowanie wymyślnych formularzy są wyjątkowo passé, a na domiar złego faworytem wielu webdeveloperów stało się w ostatnich latach jQuery. Team Rails zdawał się te drobiazgi mieć w głębokim poważaniu. Aż nadeszła wersja 3.

Wreszcie

Najważniejszą nowością w tym temacie jest uniezależnienie Railsów od Prototype.js. Jeśli chcemy korzystać z jQuery, nic nie stoi nam na przeszkodzie i wcale nie musimy rezygnować z railsowych helperów. Co więcej, odpowiedni moduł rails.js w wersji dla jQuery jest rozwijany przez Rails Team równolegle z wersją dla Prototype. Użytkownicy innych bibliotek znajdą również – już nieoficjalne acz w pełni sprawne – wersje dla MooTools, Ext.js czy YUI.

Warto też zwrócić uwagę na gem jquery-rails, który upraszcza migrację Prototype → jQuery do wywołania generatora:

rails generate jquery:install

Komenda usunie pozostałości po Prototypie, pobierze świeże jQuery i odpowiedni rails.js i zadba by javascript_include_tag :defaults właśnie te dwa pliki wczytywało.

Jak to działa?

Po pierwsze, zapominamy o link_to_remote i jego pobratymcach. W 3.x mamy tylko opcję :remote => true. Dodajemy ją do link_to, button_to lub form_for i tym prostym sposobem otrzymujemy ajaksowy – miast zwykłego – link, przycisk lub formularz.

Powyższa opcja zdaje się robić bardzo niewiele. Do wygenerowanego linku lub formularza dodaje jedynie atrybut data-remote="true". Co to za cudo i gdzie podział się mój onclick?!

Atrybuty data-* to wprowadzony w HTML5 standard wiązania dowolnych danych z elementami HTML. Całkowicie poprawny (w rozumieniu poprawności HTML5) jest przykładowy element:

<li data-villain="Kapitan Wyspa">Wilq</li>

…w którym to przebiegle powiązałem superbohatera z jego adwersarzem. Railsy zaadoptowały ten mechanizm m.in. do oznaczenia linków lub formularzy jako ajaksowe (remote).

Nie byłoby jednak magii Ajaksu bez wspomnianego wcześniej pliku rails.js. W nim zaimplementowano mechanizmy wysyłania zapytań i submitowania formularzy w tle. Tutaj odpowiednie handlery podpinane są do linków i formularzy z data-remote="true". I każda z rozwijanych oddzielnie wersji robi dokładnie to samo we własnym dialekcie Javaskryptu.

remote to nie wszystko

Oprócz dodania :remote, face-lifting przeszły opcje :method i :confirm. Najbardziej wypasiony link_to z potwierdzeniem i usuwaniem przez Ajax:

link_to "Usuń", @product, :method  => :delete,
                          :confirm => "Czy aby na pewno?",
                          :remote  => true

generuje w Rails 3 całkiem zgrabne:

<a href="/products/7" data-confirm="Czy aby na pewno?" data-method="delete" ↵
data-remote="true" rel="nofollow">Usuń</a>

Analogicznie jak wcześniej, cała logika wywołania confirm("Czy aby na pewno?"); i ustawienia metody zapytania znajduje się w pliku rails.js.

I co dalej?

A dalej jest oczywiście kontroler. I akcja, która musi dany request – ajaksowy czy nie – obsłużyć. Tu warto wspomnieć o jeszcze jednej perełce w Rails 3. Dla mnie osobiście to odkrycie stulecia. Para respond_to i respond_with pozwoli skrócić kod każdego Twojego kontrolera o połowę. Nie ściemniam. Weźmy dość standardowy przykład z Rails 2.x:

def index
  @users = User.all
  respond_to do |format|
    format.html
    format.xml { render :xml => @users }
    format.json { render :json => @users }
  end
end

Jedna akcja renderuje standardowy widok HTML lub, na życzenie, zwraca reprezentację JSON lub XML. Żadna fanaberia. W Rails 3 może to wyglądać tak:

respond_to :html, :xml, :json

def index
  @users = User.all
  respond_with @users
end

respond_to służy do zadeklarowania akceptowanych formatów, a respond_with na podstawie przekazanego obiektu i żądanego formatu wykona odpowiednią operację. A jak się to ma do Javaskryptu? Weźmy inny przykład:

respond_to :html, :js

def create
  @article = Article.create(params[:article])
  respond_with @article
end

Długo by wymieniać ile magii znajduje się w jednej linijce respond_with. Zaczynając od wariantu :html, metoda ta inaczej zachowa się jeśli @article.valid? (przekieruje na article_path(@article)), a inaczej jeśli nie (wyrenderuje akcję new, a jakże). Jeśli zapytanie przyszło z Javascriptu, choćby z formularza z ustawionym :remote => true, akcja wyrenderuje natomiast create.js.erb, w którym mamy dostęp do @article i możemy w UI natychmiast odzwierciedlić zmianę.

Dziękuję, dobranoc. Kwiaty można przysyłać pocztą na adres redakcji Więcej info o respond_with w artykule Ryana Daigle.

Pamiętacie animowane gify z początku Internetu? Kilkanaście lat temu najważniejszą rzeczą w procesie tworzenia strony było wrzucenie na serwer świecącego animowanego gifa, obowiązkowo z widokiem placu budowy i wielkim under construction. Potem wystarczyło już nigdy nie zaglądać na ten serwer i mieliśmy piękną stronę wiecznie w budowie (jak Świątynia Opatrzności Bożej).

W dobie blogów w 15 minut i silinków ala demotywatory za 50zł, o wrzuceniu tekstu „strona w budowie” nikt już nie myśli. Czasem jednak chcielibyśmy mieć możliwość wygodnego poinformowania użytkowników, że robimy migrację lub właśnie coś zmieniamy. Dziś szybki przepis jak to zrobić.

Potrzebne nam będą:

• Nginx z Passengerem jako serwer http.
• Capistrano jako narzędzie do deploymentu.
• Railsowa aplikacja.
• Strona z gifem under construction, może być też jakiś stylowy licznik, że wracamy za 7 dni.
• Butelka piwa – zawsze się przyda.

Nasz plik z gifem nazwijmy maintenance_file.html, umieśćmy w katalogu public i dodajmy go do repozytorium.

public/maintance_file.html

Na serwerze znajdźmy plik konfiguracyjny nginxa. Prawdopodobnie znajduje się w katalogu /opt/nginx/conf/nginx.conf. Wewnątrz dyrektywy server dodajmy następujący wpis:

if (-f $document_root/maintenance.html) {
  rewrite ^(.*)$ /maintenance.html break;
}

Cały dyrektywa server powinien wyglądać wtedy podobnie do poniższego.

server {
    server_name www.foo.com;
    listen 80;
    root /webapps/foo/public;
    passenger_enabled on;

    if (-f $document_root/maintenance.html) {
        rewrite ^(.*)$ /maintenance.html break;
    }
}

Jeśli w katalogu public jest plik maintance.html to wtedy o cokolwiek nie poprosimy, to dostaniemy ten plik. Dlatego plik w naszym repozytorium nazywa się inaczej (maintence_file.html). Zostało teraz tylko tak przygotować capistrano, by przed restartem w naszym katalogu public pojawiał się plik maintance i znikał po jego zakończeniu.

before 'deploy:restart', 'deploy:disable_site'
after 'deploy:restart', 'deploy:enable_site'

namespace :deploy do
  desc "Enables site"
  task :enable_site, :roles => :app do
    run "rm -f #{current_path}/public/maintenance.html"
  end

  desc "Disables site"
  task :disable_site, :roles => :app do
    run "ln -nfs #{current_path}/public/assets/maintenance.html /
     #{current_path}maintenance_file.html"
  end
end

I to wszystko. Osobną kwestią, pozostaje, w którym momencie chcemy pokazywać użytkownikowi informację o niedostępności strony, ale cały mechanizm pozostaje bez zmian. Użytkownicy Appacha, mogą zastosować podobny mechanizm.

Byłbym zapomniał. Jak wszystko zadziała ładnie, to możemy wypić piwo.

Założenia

• Zakładam, że korzystasz z Capistrano. Jeśli nie, to prawdopodobnie powinieneś.
• Posiadasz Railsową aplikację zdeployowaną na jednym serwerze produkcyjnym.
• Korzystasz z Nginxa, jak serwera WWW z zainstalowanym Phusion Passengerem. (Konfiguracja dla Apacha będzie podobna)
• Jako baza danych wykorzystywany jest MySQL. Instrukcje udostępniania połączenia dla innych rodzajów baz danych mogą odbiegać od tego co jest opisane w tym przewodniku.
• Serwer w tym przypadku to Debian, ale na wszystkich systemach *nixowych powinno to wyglądać podobnie.

Schemat konfiguracji

Master serwer – główny serwer, który będzie przyjmował żądania i je rozdzielał (część przekaże na inne serwery, część obsłuży sam). Na nim znajduje się baza i procesy chodzące w tle (backgroundrb, delayed_job, sphinx itp…)
Slave serwer – drugi serwer, służący wyłącznie jako serwer aplikacji, łączy się z bazą znajdującą się na master serwerze.

Schemat konfiguracji

Taka konfiguracja umożliwia dodanie więcej niż jednego równoległego slave serwera. W pewnym momencie warto również pomyśleć o przeniesieniu bazy na osobny serwer.

Ustawienia capistrano

Capistrano oparte jest o system ról, z których skorzystamy. Różnym serwerom możemy przypisać różne role, a poszczególnym rolom różne zadania. Dzięki temu możemy sprawić, by zadania związane z bazą i procesy chodzące w tle pracowały tylko na maszynie z rolą: :db. Jeśli mamy już skonfigurowane Capistrano, to powinniśmy do roli :app przypisać adres ip drugiego serwera.

role :app, "master_serwer_ip", "slave_serwer_ip"
role :db, "master_serwer_ip"

Zadania, które powinny być wykonywane wyłącznie na serwerze głównym należy oznaczyć :roles => :db.

task :restart, :roles => :db do
  run "cd #{release_path} && RAILS_ENV=production rake ts:rebuild &"
end

Tworzenie usera na slave

Na slave serwerze należy stworzyć użytkownika z takim samym hasłem i nazwą jak na serwerze master. Załóżmy, że posiadamy użytkownika capistrano z hasłem some_password. Logujemy się jako root na slave serwer:

useradd capistrano -p some_password
cd /home
mkdir capistrano
chown -R capistrano capistrano
chrgp -R capistrano capistrano

I mamy stworzonego użytkownika.

Przygotowanie deploya

Należy na serwerze slave stworzyć katalog do którego będziemy robić deploye. Najwygodniej nam będzie, jeśli struktura katalogów będzie identyczna jak na serwerze master. Jeśli nasza aplikacja nazywa się facebook_killer wykonujemy:

mdkir /var/www/facebook_killer
chown capistrano /var/www/facebook_killer/
chgrp capistrano /var/www/facebook_killer/

Lokalnie capistrano powinno nam przygotować niezbędne katalogi. Wywołujemy więc

cap production deploy:setup

Robimy deploy i ewentualnie poprawiamy co trzeba (instalujemy gemy, linkujemy katalogi).

cap production deploy

Pliki konfiguracyjne

Pora przygotować pliki konfiguracyjne. Wszystkie pliki oprócz database.yml powinny być identyczne jak na masterze. Należy więc dostosować ich zawartość, po czym zajmujemy się plikiem database.yml:

vim /var/www/facebook_killer/shared/config/database.yml

Ponieważ chcemy się połączyć z bazą na masterze, należy ustawić wszystko tak jak na masterze i dodać dwie linijki w sekcji production (port i adres serwera z bazą danych):

adapter: mysql
encoding: utf8
database: facebook_killer_prd
username: database_user
password: database_password
host: master_serwer_ip
port: 3306

Odpalamy serwer ręcznie w trybie produkcyjnym, żeby zobaczyć czy działa. (W razie potrzeby należy doinstalować brakujące gemy):

cd /var/www/facebook_killer/current/
RAILS_ENV=production script/server production

Jeśli nie możemy teraz połączyć się bazą danych, znaczy to, że mamy odpowiednio zabezpieczony serwer produkcyjny. Wystarczy teraz tylko udostępnić bazę slave serwerowi. Jeśli jednak połączyliśmy się bez problemów, znaczy, to że zbyt łatwo każda osoba znająca hasło do bazy może się z nią zdalnie połączyć. Wnioski co to znaczy, należy wyciągnąć samemu.

Zdalny dostęp do bazy

Na serwerze z bazą (master serwer) należy ustawić dostęp do bazy danych. Poniższe podpunkt to ekstrakt ze świetnego przewodnika jak umożliwić zdalne łączenie się z serwerem bazy danych (w języku angielskim).

Logujemy się na master serwer i szukamy pliku configuracyjnego MySQL: my.cnf. (W zależności od dystrybucji linuxa może być w w różnych katalogach.)

vim /etc/mysql/my.cnf

Należy zmodyfikować sekcję [mysqld], upewaniając się, że linia skip-networking jest wykomentowana, a bind-address wskazuje na adres master serwera.

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
bind-address    = master_serwer_ip
# skip-networking

Następnie należy zapisać plik i zrestartować serwer:

/etc/init.d/mysql restart

Kolejną rzeczą jest nadanie uprawnień użytkownikowi bazy danych łączącemu się z slave serwera. Łączymy się z bazą danych:

mysql -u root -p mysql

I nadajemy niezbędne uprawnienia.

GRANT ALL ON facebook_killer_prd.* TO database_user@'slave_server_ip'
IDENTIFIED BY 'database_password';
exit

Należy jeszcze otworzyć port 3306. Bezpieczniej jest to zrobić umożliwiając wejścia tylko spod adresu ip slave serwera.

/sbin/iptables -A INPUT -i eth0 -s slave_serwer_ip -p tcp --destination-port 3306 -j ACCEPT
service iptables save

Warto teraz odpalić serwer ręcznie i zobaczyć czy poprawnie łączymy się z bazą. Jeśli, występują jakieś problemy, polecam zajrzeć do oryginalnej instrukcji.

Ustawienie load balancingu

Pora na najważniejszą rzecz. Skorzystamy z dyrektywy upstream.

Na master serwerze ustawiamy:

# rozdziela żądania
 upstream www.facebook_killer.com {
     server 127.0.0.1:81;
     server slave_serwer_ip;
 }

 # nasłuchuje żądań i je przekazuje
 server {
     listen 80;
     server_name www.facebook_killer.com;
     location / {
       proxy_pass http://www.facebook_killer.com;
     }
}

 # uruchamia aplikację
 server {
     listen       81;
     server_name www.facebook_killer.com;
     root /var/www/facebook_killer/current/public;
     passenger_enabled on;
}

W skrócie chodzi o to, że pierwsza dyrektywa server nasłuchuje i przekazuje żądania do upstream, które rozdziela je między serwer zdalny (slave_serwer) oraz lokalny (zdefiniowany w drugiej dyrektywie) na porcie 81. Warto zapoznać się z dokumentacją dyrektywy upstream.

Przydatna uwaga: Upstream musi się nazywać tak samo jak domena (bez http), inaczej powyższa konfiguracja nie zadziała.

Na drugim serwerze konfiguracja jest dużo prostsza:

 server {
     listen 80:
     server_name www.facebook_killer.com;
     root /var/www/facebook_killer/current/public;
     passenger_enabled on;
}

Czyli tak naprawdę jest to zwykła konfiguracja nginx. Domena facebook_killer powinna wkazywać oczywiście na adres master serwera. Restartujemy nginxa na obu serwerach i gotowe. Możemy szykować się na wykop effect.

Uwagi końcowe

Domyślnie nginx, wysyła przychodzące żądania do serwerwów po równo, lub zgodnie z wagami, które można przypisać poszczególnym serwerom. Rozwiązanie to może spowodować, że jeden z serwerów dostanie za duże obciążenie, w czasie gdy inny będzie wolny. Warto zatem rozważyć użycie Global Queue. Działa ona w ten sposób, że tworzona jest jedna globalna kolejka żądań i są one przekazywane do serwerów dopiero wtedy, gdy serwery są w stanie obsłużyć kolejny request.

Oczywiście to jest najprostsza wersja takiej konfiguracji, która działa. Myślę, że powyższe wskazówki są dobrym punktem wyjścia do uruchomienia aplikacji działającej na kilku serwerach. Dodanie kolejnego serwera, po jego skonfigurowaniu to już tylko dodatkowa linjka w upstream.

Potrzebne bedą:

• przerwa na kawę
• ruby
• git
• jakiś stary komputer (może być też ten na którym pracujesz i tak, może być nowy)

O Integrity słów kilka

Integrity to zgrabna aplikacja napisana w Sinatrze, pełniąca rolę serwera Continuous Integration. Potrafi ona pobrać kod z repozytorium gita i uruchomić na nim dowolne komendy. Gotowi? Zatem zaczynamy.

Instalacja Integrity

Integrity, do zarządzania zależnościami korzysta z bundlera. Jeśli jeszcze z niego nie korzystaliście, po prosty zainstalujcie go i podążajcie za poleceniami. Pewnie w krótce przyjrzymy się mu bliżej w osobnym poście.

gem install bundler

Integrity najlepiej pobrać z githuba i użyć ostatniej stabilnej wersji (v22):

git clone git://github.com/integrity/integrity
git checkout -b deploy v22

Następnie każemy bundlerowi zainstalować wszystykie potrzebne gemy i idziemy wstawić wodę na kawę/herbatę/yerba matę.

bundle install
bundle lock

Przygotujemy bazę danych.

rake db

Na chwilę obecną dostaniemy jakieś ostrzeżenia odnośnie datamappera, nie przeszkadzają nam one jednak uruchomić Integrity.

bundle exec rackup

Wystarczy teraz zajrzeć pod adres: http://localhost:9292/ i utworzyć swój pierwszy projekt.

Tworzenie nowego projektu

Po podaniu nazwy, adresu repozytorium i komendy do wykonania (spec spec), jesteśmy gotowi przeprowadzić pierwszy build, natykamy się tu jednak na komunikat:

Integrity/.bundle/environment.rb:126:in `gem': rspec is not part of the
bundle. Add it to Gemfile. (Gem::LoadError)

Oznacza to, że wszystkie potrzebne gemy musimy dorzucić do bundlera. Otwieramy zatem plik Gemfile i dopisujemy na jego końcu następującą linijkę:

gem "rspec"

Jeśli twoje testy wymagają innych gemów, musisz je również podać w pliku Gemfile. Następnie każemy bundlerowi zainstalować brakujący gem i idziemy zalać wrzątkiem kawę/herbatę/yerba matę.

bundle install --relock

Restartujemy naszą aplikację i odpalamy build jeszcze raz. Wszystkie testy przechodzą, a build nabiera zielonego koloru. Mamy działający serwer continuous integration. Prawda że szybko?

Skąd Integrity wie, że testy przechodzą?

Integrity korzysta z prostej zasady, że jeżeli unixowy program zakończył się bez błędów, to zwracana jest wartość 0, a jeśli błędy wystąpiły, wynik jest od zera różny. Ponieważ większość, jeśli nie wszystkie narzędzia do testowania w Rubym (test unit, rspec, cucumber) są zgodne z tymi założeniami, Integrity „wie”, czy testy znalazły błedy, czy też nie. Dzięki temu możliwe jest dodanie dowolnych narzędzi o ile zwracają one odpowiedni kod na wyjściu.

Co dalej?

Następnymi krokami powinno być uruchomienie Integrity na swoim ulubionym web serwerze i zautomatyzowaniu procesu. Buildy mogą być przygotowywane zarówno cyklicznie (np co godzinę), jak i z wykorzystaniem Post-Receive Hook. Można również rozważyć ustawienie powiadomień na wypadek wystąpienia błędów. Jak to wszystko zrobić opisane zostało na stronie Integrity, ale to już temat do samodzielnego zgłębienia w czasie kolejnej przerwy na kawę.

W artykule o RSpecu obiecałem drugą część poświęconą mockom i stubom i do tego tematu jeszcze wrócimy. Ale póki co naszła mnie wena na Ogórka. Cucumber to – obok RSpeca właśnie – drugi filar BDD w Rubym i jeśli jeszcze go nie znasz – przyszła już najwyższa pora.

Pierwsze kroki z Ogórkiem pomogą postawić dwie pierwsze części naszego tutoriala.
Poniższe 10 wskazówek przyda się raczej osobom, które miały już wcześniej do czynienia z Cucumberem.

1. pickle

O pickle pisałem już wcześniej i będę pewnie trąbił o nim w nieskończoność. Jeśli masz wynieść z tego artykułu jedną rzecz – niech to będzie to. Przeczytaj, zainstaluj, korzystaj.

Pickle na GitHubie: http://github.com/ianwhite/pickle

2. Szkice scenariuszy i tła

Scenario outlines i Background to jedne z podstawowych funkcji Cucumbera. Nie zaszkodzi jednak powtórzyć. A nuż ktoś usłyszy o tym właśnie pierwszy raz.

Oba te patenty służą do zmniejszenia duplikacji w scenariuszach.

Scenario outline umożliwiają zastąpienie dwóch lub więcej podobnych scenariuszy jednym szkicem, do którego przekazujemy zestawy różnych opcji. Przykladowo zamiast:

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"

Scenario: User signs in with invalid password
  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 "email@person.com"
  And I fill in "password" with "wrongpassword"
  And I press "Login"
  Then I should see "Invalid password"

Możemy napisać:

Scenario Outline: User signs in with invalid data
  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 "<email>"
  And I fill in "password" with "<password>"
  And I press "Login"
  Then I should see "<message>"

  Examples: Variations of invalid login data
    | email            | password      | message                |
    | somewrongemail   | password      | Invalid e-mail address |
    | email@person.com | wrongpassword | Invalid password       |

Dla każdego przykładu z tabeli Examples Cucumber wykona pełen scenariusz, wypełniając bloki <email> itp. odpowiednimi wartościami.

Inną metodą optymalizacji długości feature’ów jest Background. Jeśli w scenariuszach w jednym pliku powtarza się spora ilość Givenów, czasem warto wydzielić je do jednego wspólnego bloku Background.

Wychodząc od początkowych 2 scenariuszy, możemy spróbować tak:

Background:
  Given a user exists with email: "email@person.com", password: "password"
  And I am on the sign in page

Scenario: User signs in with invalid email address
  When 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"

Scenario: User signs in with invalid password
  When I fill in "email" with "email@person.com"
  And I fill in "password" with "wrongpassword"
  And I press "Login"
  Then I should see "Invalid password"

Na początku każdego ze scenariuszy zostanie wywołany w całości blok Background, dzięki czemu efekt pozostaje taki sam.

3. Recycling kroków

Już od pierwszych wersji Cucumbera była możliwość wykorzystania istniejących kroków w definicjach innych. Możliwe było więc wykorzystanie np. całego zestawu web_steps przy definiowaniu własnych, bardziej złożonych, jednak format zapisu był dość niezręczny:

Given /^I log in as "([^\"]*)\/([^\"]*)"$/ do |email, password|
  Given %q{I go to the login page}
  Given %q{I fill in "E-mail" with "#{email}"}
  Given %q{I fill in "Hasło" with "#{password}"}
  Given %q{I press "Zaloguj się"}
end

Na szczęście wprowadzona w wersji 0.4.4 metoda steps znacznie uprzyjemnia korzystanie z tego mechanizmu:

Given /^I log in as "([^\"]*)\/([^\"]*)"$/ do |email, password|
  steps %Q{
    Given I go to the login page
    And I fill in "E-mail" with "#{email}"
    And I fill in "Hasło" with "#{password}"
    And I press "Zaloguj się"
  }
end

4. Popracuj nad regexami

Sporą bolączką większych projektów jest duplikacja kodu. Dużo trąbi się o DRY ale pewna ilość redundancji i tak wkrada się do programów. Nie inaczej jest z testami. Dzięki temu, że kroki Cucumbera definiujemy przy użyciu wyrażeń regularnych, mamy do dyspozycji potężne narzędzie do DRY-owania testów.

Czy na pewno potrzebujesz oddzielne definicje dla Given I am logged in i Given an admin signs in? A co z krokami typu Given I am logged in with email: "lukasz@czak.pl"? Jeśli dobrze przemyślisz regexa, wszystkie możesz zdefiniować w jednym kroku, np:

Given /^I am logged in(?: as (\w+))?(?: with email "([^\"]*)")?$/do |role, email|
  role ||= "user"
  email ||= "lukasz@czak.pl"
  password = "secret"
  steps %Q{
    Given a #{role}: "me" exists with email: "#{email}", password: "#{password}"
    And I go to the login page
    And I fill in "E-mail" with "#{email}"
    And I fill in "Password" with "#{password}"
    And I press "Login"
  }
end

Taka definicja pasuje do kroków w kilku postaciach. Jeśli potrzebujesz w scenariuszu zalogowanego usera (bez wymagań co do jego roli czy emaila) możesz zapisać po prostu:

Given I am logged in

Jeśli potrzebujesz usera w konkretnej roli:

Given I am logged in as admin
Given I am logged in as user

Kiedy potrzebujesz usera z konkretnym emailem (który np. wykorzystujesz w dalszej części scenariusza):

Given I am logged in with email: "ziom@czak.pl"

I wreszcie aby stworzyć usera w konkretnej roli i ze specyficznym adresem e-mail:

Given I am logged in as admin with email: "lukasz@czak.pl"

Cała magia powyższej definicji zawiera się w bloku postaci (?: as (\w+))?. Dzięki niemu człon as admin czy as user zostanie zaakceptowany, a odpowiednia rola przechwycona do zmiennej role. Jednocześnie dzięki ? na końcu cały ten blok jest opcjonalny.

Oczywiście z wyrażeniami regularnymi można tworzyć jeszcze większe cuda – to tylko jeden przykład.

5. Debugger

Długo zbywałem debugger jako narzędzie mało w Rubym przydatne, ale ostatnio przekonuję się do niego coraz bardziej. Kiedy już nie mam pomysłu dlaczego test się wysypuje, wstawiam do niego krok:

Then debug

..a w debug_steps.rb czeka definicja:

Then /^debug$/ do
  debugger
end

Pozostaje tylko odpalić scenariusz i pozwolić debuggerowi we wskazanym miejscu zatrzymać wykonywanie.

6. Before, After i tagi

Cucumber, na wzór RSpeca, posiada metody Before i After, dzięki którym możemy zdefiniować operacje wykonywane przed lub po każdym scenariuszu. Dzięki połączeniu z tagami może się to nam przydać do estetycznego uporządkowania ogórków.

Może się zdarzyć tak, że część naszych scenariuszy wymaga pewnych danych do działania. Z uporem maniaka wstawiamy więc do każdego z nich:

Given a page exists with slug: "hello"
And a blog post exists with permalink: "hello"

Jeśli powtarza się to w kilku scenariuszach, możemy nadać im tag, np @seed:

@seed
Scenario: User reads the "Hello" page

a w support/seed_data.rb wstawić:

Before("@seed") do
  Factory(:page, :slug => "hello")
  Factory(:blog_post, :permalink => "hello")
end

Teraz jeśli będzie potrzebny jeszcze jeden scenariusz wymagający tego samego – wystarczy nadać mu odpowiedni tag.

7. Oszukać delayed_joba

Delegowanie długich zadań do delayed_job jest już pewnym standardem, jednak testowanie takich asynchronicznych mechanizmów wciąż nie. Najprostsze rozwiązanie to małe oszustwo:

Given /the system processes delayed jobs/ do
  Delayed::Job.work_off
end

W żądanym miejscu scenariusza wstawiamy:

...
And the system processes delayed jobs
...

I mamy pewność, że cała dotychczasowa kolejka delayed_joba zostanie wykonana.

Wszystkie biblioteki wykonujące zadania w tle mają synchroniczną metodę wykonującą wszystko i można wykorzystać je analogicznie.

8. Poznaj cucumber.yml

Plik konfiguracyjny Cucumbera – config/cucumber.yml jest dosyć rozbudowany na „dzień dobry”, ale warto przyjrzeć mu się mimo wszystko i z kilku rzeczy skorzystać.

Pierwsza rzecz to --format, który może przyjąć 10 wartości, ale w domyślnej konfiguracji mamy do czynienia tylko z dwoma.

Głównym elementem cucumber.yml są jednak profile. Na starcie otrzymujemy dwa: default i wip. Jeśli w scenariuszach korzystamy aktywnie z tagów, warto utworzyć dodatkowy profil, który będzie uruchamiał jedynie te oznaczone (lub nie oznaczone) wskazanymi.

Wychodząc od domyślnego:

default: <%= std_opts %&gt
wip: --tags @wip:3 --wip features

Często dodaję dodatkowy profil javascript i zmieniam układ na:

default: <%= std_opts %&gt --tags ~@javascript
wip: --tags @wip:3 --wip features
javascript: <%= std_opts %&gt

Dzięki temu „normalne”, regularne uruchamianie ogórków pomija długo wykonujące się scenariusze wymagające @javascript, zaś uruchomienie pełnego zestawu – wraz z Selenium/Culerity wymaga wywołania:

cucumber --profile javascript

9. Pamiętaj o supporcie

Pamiętaj, że każdy plik z features/support jest wczytywany przed wykonaniem całego zestawu testów. Nie ma więc potrzeby zapychać features/support/env.rb, skoro można np. dodać plik features/support/capybara.rb, a w nim:

Capybara.default_driver     = :rack_test
Capybara.javascript_driver  = :culerity

10. Pożegnanie z ogórkiem

Nie mniej ważną umiejętnością od wszystkich powyższych jest świadoma rezygnacja z Cucumbera i wybór lepszego narzędzia do określonego celu.

Modelowym przykładem jest testowanie integracji z zewnętrznymi usługami, np. z systemami płatności. Choć może kusić wysoki poziom abstrakcji Cucumbera i przeświadczenie, że „może wszystko to co i user”, bez spec’ów kontrolerów się w tym wypadku nie obejdzie.

Tydzień temu JRuby osiągnął spory milestone w wersji 1.5.0, co utwierdziło mnie w przekonaniu, że jest to jeden z poważniejszych projektów w świecie Ruby’ego. Jest kilka przyczyn, dla których warto się nim zainteresować. Mówi się o wysokiej wydajności tej implementacji – nie ustępującej MRI 1.9. W środowiskach z rozbudowaną infrastrukturą JavaEE JRuby stanowi świetny punkt zaczepienia dla Ruby’ego.

Dla mnie podstawowym atutem JRuby’ego jest wygodny dostęp do multum bibliotek Javy, z których niejedna dojrzałością przewyższa znane gemy w Rubym.

Decydując się na JRuby on Rails w budowanym właśnie przeze mnie projekcie obawiałem się, że będę musiał przeprosić się z Tomcatem czy Jettym, grzebać się w XMLach i innych WARach. Obcując z wersją sprzed kilku miesięcy miałem też przykre doświadczenia z kompatybilnością niektórych gemów. Na szczęście JRuby 1.4.0 – a 1.5.0 tym bardziej – wszystkie te problemy rozwiązał.

Pojawiły się też w międzyczasie narzędzia ułatwiające deployment do tego stopnia, że nie jest on ani trochę trudniejszy od wdrożenia aplikacji na Passengerze. Nie trzeba też rezygnować z Capistrano.

Dla potomnych poniżej najprostszy scenariusz wdrożenia aplikacji JRuby on Rails.

Przygotowanie

Przed wdrożeniem upewnij się, że aplikacja na localhoście działa w pełni na JRubym. W moim projekcie tylko mały fragment korzysta z Javy, mam więc tendencję do odpalania:

./script/server

zamiast

jruby script/server

Nic nie stoi na przeszkodzie aby na komputerze mieć zarówno Ruby’ego MRI (czy EE) obok JRuby. Możesz też oczywiście skorzystać z rvm. Pamiętaj, że każdy interpreter ma swój własny zestaw gemów.

JRuby i glassfish

Na serwerze musi być oczywiście zainstalowany JRuby – ja zawsze instaluję do /opt/jruby-1.x.x, a wersję która mnie interesuje symlinkuję do /opt/jruby. Do $PATH dochodzi /opt/jruby/bin.

Zainstaluj gem glassfish:

jgem install glassfish

I w sumie na tym koniec… serwer jest gotowy Glassfish to serwer aplikacji Java stworzony przez Suna, a dzięki jednemu developerowi jest dostępny w postaci gema.

Z katalogu aplikacji możesz teraz wywołać:

jruby -S glassfish

…i aplikacja działa na porcie 3000. Przydałoby się jednak odpalić serwer w tle. I może zmienić port? I restartować przy deployu… Pora więc na…

Capistrano

Do współpracy z Capistrano potrzebne są 2 kroki. Po pierwsze musimy przygotować plik konfiguracyjny Glassfisha – tak aby odpalał się jako daemon i w odpowiednim miejscu zapisywał plik z pidem. Wywołaj w katalogu aplikacji:

gfrake

Komenda wygeneruje podstawowy plik config/glassfish.yml z domyślnymi ustawieniami. Ustaw poniższe wartości:

...
environment: production
...
port: 3000  # (wedle uznania)
...
daemon:
  enable: true
  pid: tmp/pids/glassfish.pid
...

Konfig koniecznie przenieś do shared i pamiętaj o symlinkowaniu przy deployu (to temat na inną rozmowę).

Teraz pozostaje tylko przygotować kroki deploy w przepisie Capistrano:

namespace :deploy do
  desc "Start Glassfish Gem from a shutdown state"
  task :cold do
    start
  end

  desc "Stop a server running Glassfish Gem"
  task :stop do
    pid = "$(cat #{current_path}/tmp/pids/glassfish.pid)"
    run "if ps -p #{pid} > /dev/null; ↩
         then kill -INT #{pid}; ↩
         else echo 'Glassfish not running'; ↩
         fi"
  end

  desc "Starts a server running Glassfish Gem"
  task :start do
    run "cd #{current_path} && glassfish"
  end

  desc "Restarts a server running Glassfish Gem"
  task :restart, :roles => :app do
    stop
    start
  end
end

start to po prostu uruchomienie glassfish. Dzięki konfigowi uruchomi się w tle, a pid zapisze do tmp/pids/glassfish.pid.

stop to sprawdzenie czy proces o danym pidzie istnieje i – jeśli tak – ubicie go.

Żadna filozofia.

W takiej konfiguracji Glassfish serwuje wszystko – również zasoby z public. Teoretycznie nie ma w tym nic złego, ale z punktu widzenia wydajności warto (warto?) tę funkcję zrzucić np. na Apache’a. Miało być jednak prosto więc na tym skończymy.

Czarne chmury

Glassfish gem jest stabilny, wydajny i super prosty w użyciu, ale ma jedną sporą wadę… nie jest już aktywnie rozwijany. W świetle zmian jakie ostatnio przeszedł Sun, projekt ten – do tej pory wspierany przez firmę – nie „przeżył”.

Na horyzoncie widać już jednak potencjalnego następcę. A może raczej konkurenta. trinidad to Tomcat opakowany w gem i przygotowany do użycia prawie w taki sam sposób, który opisałem. Warto mieć na oku.

Kombinacja JRuby+Glassfish bardzo pozytywnie mnie zaskoczyła i zdecydowanie polecam ją wszystkim obawiającym się pierwszego kontaktu z JRubym.