Nie ma to jak mieć wybór
Kurcze.
Mój nauczyciel informatyki w liceum opowiadał czasem taką anegdotkę:
"Kiedyś, jak wchodziłem do sklepu kupić dyskietki, to sprawa była
prosta. Mówiłem 'Poproszę o 10 dyskietek' i dostawałem paczkę. Teraz
wchodzę do sklepu, proszę o 10 dyskietek i słyszę 'Których?'."
Jasne, anegdotka ma ponad 10 lat, trochę się od tego czasu zmieniło, a
dyskietkę ostatni raz widziałem podczas porządków w szufladzie. Była
zakurzona, wylądowała w koszu. Ale nie o tym chciałem.
Jeszcze kilka lat temu, jak człowiek chciał stworzyć serwis www, to
sprawa była prosta – perl, CGI.pm i template toolkit. Z braku
lepszych możliwości nie miał się nad czym zastanawiać, siadał i
zabierał się do pracy. A teraz? Bibliotek napisanych specjalnie na
potrzeby www są tysiące, kombinacji "język, system szablonujący,
warstwa dostępu do bazy danych, kontroler" jeszcze więcej, a na
dodatek ciągle pojawiają się nowe. I właśnie ostatnio dość dobitnie
się o tym przekonuję.
A wszystko przez to, że od prawie pół roku (sprawdziłem – trac mówi
mi, że pierwszy plik w repozytorium pojawił się 2 marca 2005) powoli i
z przerwami tworzę serwis
[http://rekomendacje.pl/](http://rekomendacje.pl/). Kiedy zaczynałem
podjałem szereg decyzji technicznych, przede wszystkim:
* chciałem język skryptowy – na co dzień mam więcej niż dosyć
czekania na kompilację. Padło na [Pythona][url_python], głównie
dlatego że dobrze i szybko mi się w nim pisze. Ma swoje wady, ale
ma też dużą grupę ludzi wykorzystujących właśnie go do tworzenia
serwisów www, więc jest duża szansa że każdy poważniejszy problem,
jaki mogę napotkać, trafił już do google.
* chciałem system szablonujący podobny do [Template
Toolkit][url_tt] – nigdy nie przepadałem za szablonami
starającymi się upodabniać do HTML czy XML – ASP, JSP, PHP,
HTML::Mason i cała reszta wydawała mi się zawsze mało czytelna.
Wybrałem [Cheetah][url_cheetah].
* _nie_ chciałem pisać samemu kodu przepisującego zawartość bazy na
obiekty i z powrotem. Przejrzałem kilka takich bibliotek i żadna
nie spodobała mi się specjalnie, skończyło się na tym że wybrałem
najprostszą – db_row.
I tyle. Nie twierdzę, że wybrałem najlepiej jak mogłem – z powodu
olbrzymiej ilości bibliotek wybrałem najlepiej, jak byłem w stanie po
wyczerpaniu czasu, jaki chciałem poświęcić na poznawanie kolejnych
możliwości.
Do teraz zaimplementowałem jakieś 3/4 funkcjonalności niezbędnej do
pierwszej wersji publicznej. Nie licząc szablonów www i plików
pomocniczych dało to 2933 linie kodu, z czego 1333 to sama obsługa
bazy danych. Podczas ich pisania dowiedziałem się paru interesujących
rzeczy, między innymi tego że użycie sensowniejszej biblioteki do
obsługi bazy danych oszczędziłoby mi przynajmniej 900 linii, a
sensownego kontrolera aplikacji – kolejne 500 (tyle poszło na dość
ogólne rzeczy typu obsługa sesji i autoryzacja). Razem to prawie
połowa kodu. _Połowa_. Kurcze.
A powodem, dla którego nad tym teraz się zastanawiam, jest to że
niedawno przyjrzałem się [Ruby on Rails][url_ror] (RoR). Obejrzałem
[krótki filmik][url_ror_15min] (50MB), przejrzałem tutoriale, po czym
poświęciłem cztery wieczory na próbne przepisanie części rekomendacji.
Wniosek pierwszy: w tym można pisać naprawdę szybko. Bardzo duża
część pracy, między innymi wspomniane wyżej mapowanie danych i
kontrola zachowania aplikacji są za darmo. W większości przypadków do
napisania pozostaje tylko szablony stron i logika aplikacji, plus
drobna pomoc po stronie modelu danych – większość informacji RoR
wyciąga sobie z bazy, ale zależności między tabelami trzeba podawać
ręcznie. Jest niezła dokumentacja, z paroma błędami (np. zamiast
find(:all) trzeba używać find\_all) ale opisuje co trzeba w bardzo
zrozumiały sposób. [Istnieją][url_ror_generators]
[gotowe][url_ror_libs] [moduły][url_ror_helpers], które można łatwo
dołączyć do aplikacji – na przykład [system autoryzacji
użytkowników][url_ror_login], z zakładaniem nowych kont i przesyłaniem
potwierdzeń pocztą.
Najpdawdopodobniej byłbym w stanie przepisać mój kod na Rails i
dopisać brakujące 25% w czasie porównywalnym z tym, jaki zajmie mi
samo dopisanie brakującego kawałka przy pomocy tego, co mam teraz.
Tak, takiego kopa daje RoR.
Problemem jest jednak Ruby – język porównywalny z Pythonem, ale
znacznie mniej popularny, co oznacza mniej bibliotek i mniej serwerów,
na których można z niego skorzystać. Składnia różni się od Pythona
dokładnie na tyle, ile trzeba, żeby była irytująca i wymuszała nieco
inny sposób myślenia. Nie jestem przekonany, że chcę się uczyć i
systematycznie używać kolejnego języka różniącego się od już znanego
prawie wyłącznie wyglądem. Bo tego, że Pythona będę nadal używał (nie
tylko do www) jestem pewien.
A dzisiaj dowiedziałem się o kolejnej możliwości. Za pośrednictwem
[lesscode.org](http://lesscode.org) trafiłem na porównanie RoR z
[Django](http://www.djangoproject.com/), będące z grubsza jego
pythonowym odpowiednikiem. Trzeba będzie się przyjrzeć w tym
tygodniu, może zaoszczędzić dużo czasu później. Kilka spostrzeżeń już
mam, ale to temat na kolejny wpis za kilka dni.
[url_ror_login]: http://wiki.rubyonrails.com/rails/show/SaltedHashLoginGenerator
[url_ror_generators]: http://wiki.rubyonrails.com/rails/show/AvailableGenerators
[url_ror_libs]: http://wiki.rubyonrails.com/rails/show/3rd+Party+Libs
[url_ror_helpers]: http://wiki.rubyonrails.com/rails/show/3rd+Party+Helpers
[url_ror_15min]: http://www.rubyonrails.com/media/video/rails_take2_with_sound.mov
[url_python]: http://www.python.org/
[url_tt]: http://www.template-toolkit.org/
[url_cheetah]: http://www.cheetahtemplate.org/
[url_ror]: http://www.rubyonrails.com/
O autorze: nazywam się Marcin Kaszyński i od ponad 10 lat zajmuję się tworzeniem oprogramowania, od projektowania przez programowanie do zarządzania projektami włącznie. Prowadzę warsztaty Django, będące szybkim i łatwym sposobem na poznanie tego środowiska i rozpoczęcie pracy z pełnym wykorzystaniem jego możliwości.
