Jarosław Zabiełło - BLOG: Tag datamapper

Merb 0.9.6

Jarosław Zabiełło — Thu, 11 Sep 2008 00:22:00 +0200

Ci, co instalowali sobie Merba i robią sobie czasem aktualizację gemów Rubiego, mogą zauważyć że, co dwa tygodnie pojawia się kolejna jego wersja (w tej chwili jest to 0.9.6). Tak ma być aż do październikowej wersji 1.0. Co ciekawe, synchronicznie z Merbem pojawia się zbliżona wersja DataMappera. Nie jest to przypadek, bo deweloperzy obu projektów ściśle ze sobą współpracują (DataMapper 1.0 ma wyjść razem z Merbem 1.0).

Wydaje się, też że DataMapper zaczyna stawać się preferowanym ORM’em dla Merba, mimo że Merb nie jest od niego uzależniony (tak jak Rails od Active Record) i równie dobrze współpracuje z innymi ORM’ami napisanymi w Ruby, jak (b. dobry) Sequel czy wspomniany Active Record.

Merb aktualnie jest intensywnie szlifowany. Publiczne API jeszcze może ulec zmianie, więc ci co używają wersji bieżących muszą śledzić to, co się zmienia. Po wyjściu wersji 1.0 publiczne API ma być zamrożone aż do kolejnej wersji 2.0.

Bardzo ciekawie wygląda dodany niedawno do Merba radykalnie nowy, modularny i 100% wielowątkowy cache. Dodano też inteligentniejszą regenerację cache’a. Aplikacja nie jest zwalniana procesem regeneracji cache’a. Jeśli czas odświeżenia przeglądarki zbiegnie się z czasem odświeżenia danych, Merb uruchamia taki proces dopiero po wcześniejszym odesłaniu starszych danych do klienta. Ulepszono też sposób generowania projektu. Np. stworzenie nowego projektu, gdzie system testowania będzie oparty na RSpec, silnikiem szablonów będzie Haml, a ORM’em – DataMapper można odpalić za pomocą opcji generatora:

merb-gen app projekt --testing-framework=rspec \
                     --template-engine=haml \
                     --orm=datamapper

Jednak to, co stawia Merba wyrażnie wyżej od Rails to jego modularna budowa. Nie tylko można zamienić cały projekt w gema. Dzięki slices można całą aplikację dosłownie poskładać z gemów. Moim zdaniem, jest to nawet lepiej zrobione niż w Django.

Git rządzi

Jarosław Zabiełło — Sun, 18 May 2008 18:28:00 +0200

Jeśli miałem wcześniej jakieś wątpliwości czy przejść na Gita czy trzymać się SVN’a, to już dziś ich nie mam. Wygoda tworzenia lekkich branchy Gita jest powalająca. Dzisiaj podczas tworzenia aplikacji z użyciem Sequel’a postanowiłem sprawdzić DataMappera...

Wiele osób sądzi, że następcą Active Record będzie DataMapper. Wykorzystuje podobne podejście odnośnie relacji między modelami, lecz działa dużo szybciej. Miałem jednak już trochę kodu w modelach opartych na Sequelu. Pierwsze, co trzeba zrobić to odpalić w katalogu projektu

git init

Powstanie folder .git. W przeciwieństwie do SVN, Git nie śmieci milionem katalogów .svn w każdym z podkatalogów. Git tworzy tylko jeden, na najwyższym poziomie – nice, isn’t it? Następny krok to wrzucenie wszystkiego do lokalnego repozytorium (ten folder .git jest właściwym repozytorium)

git add *
git commit -a

Nasz kod zostanie zachowany. Teraz tworzymy sobie lekki branch (w tym wypadku o nazwie “datamapper”). Opcję -b używa się podczas tworzenia gałęzi.

git checkout -b datamapper

Za pomocą generatorów wywaliłem wszystkie modele i stworzyłem nowy kod. W każdej chwili możliwy jest powrót do poprzednich plików. Wszystko dzieje się w mgnieniu oka

# przełączam się na pierwotny kod:
git checkout master

# teraz jestem znowu w gałęzi datamapper
git checkout datamapper

# grzebię w kodzie
# zapisuję w repozytorum zmiany
git commit -a

# i z powrotem do głównego kodu :)
git checkout master

I już jestem z powrotem. Git pozwala na błyskawiczne tworzenie nieograniczonej ilości takich odgałezień kodu. Bardzo to się przydaje przy różnych eksperymentach z kodem. Można się przełączać, i jeśli chcemy, szybko scalać zmiany z głowną gałęzią (master). Bardzo mi się to spodobało. Oczywiście, możliwość dłubania w kodzie z zachowanie historii zmian w sytuacji kiedy nie mamy dostępu do internetu nie jest żadnym problemem dla Gita. To jest cecha wszystkich rozproszone systemów wersjonowania. Dlaczego Git a nie Mercurial? Można używać i Mercurial, ale Git jest najszybszy, mam do tego świetnego githuba i nie interesuje mnie używanie win32 do tworzenia oprogramowania. Anyway, “bye, bye Subversion”.

Co z DataMapperem? Na dzień dzisiejszy ma za mało dokumentacji aby można było szybko go opanować. Sequel jest dużo łatwiejszy do opanowania i przydaje się bardziej tam gdzie mamy bardziej złożone struktury tabel. Złożone zapytania SQL dla Sequela to bułka z masłem. W DataMapper trochę się pogubiłem. Dam mu ponowną szansę może za 2 miesiące, jak będzie trochę więcej dokumentacji.

BTW, ci, co używają najnowszego Merba (wersja edge w chwili pisania tego tekstu nosi numer 0.9.4), nie znajdą w kodzie merb-plugins biblioteki merb_datamapper. Merb już nie zajmuje się tym modułem, chłopaki z DataMapper’a przejęli nad nim kontrolę i trzeba go ściągać z innego miejsca, został dodany do dm-more. Sam gem datamapper można spokojnie wyrzucić bo stara wersa (0.3.x) została poważnie przebudowana i jest dostępna (aktualnie jako 0.9) pod inną nazwą jako dm-core i dm-more (trochę wzorowali się tu na Merbie)

Wściekły Zed i dyskusja wokół Rubiego i Railsów

Jarosław Zabiełło — Sun, 06 Jan 2008 23:49:00 +0100

Ostatnio jest trochę szumie w branży po bezpardonowym (i niewybrednym) ataku Zeda Shaw uderzającym w kilka znanych postaci z kręgów Rubiego i Rails. Pewnie nikt by na to nie zwrócił uwagi gdyby nie to, że Zed jest autorem znanego projektu Mongrel. Choć wpis się źle czyta (bo jest rozwlekły i niepotrzebnie przeplatany ciągłymi przekleństwami autora) to zwrócił uwagę na kilka istotnych problemów.

Autor zwraca uwagę, że core team Railsów dosyć opornie i wolno reaguje na podsyłane uwagi i poprawki. Fakt, jedną z poprawek jaką kiedyś podesłałem odnośnie źle działającej funkcji render_to_string uwzględniono po.. ośmiu miesiącach. Zed się wkurzył, że ignorowano jego uwagi a potem i tak wychodziło na jego. Tak z połowa core teamu to wg niego banda idiotów z wypłukanymi przez PHP mózgami. Ze swej strony bym mógł do tej listy niekompetencji owej “bandy” też coś dołożyć, ale to nie jest najważniejsze. Jest reszta, która dobrze robi swoją robotę. Ale może taka krytyka podziała jak kubeł zimnej wody i w końcu cały core team zacznie skupiać się na jakości i optymalizacji już istniejącego kodu. Bo jak nie, to programiści Rails zaczną sukcesywnie przesuwać się do konkurencyjnego projektu Merb. Ezra Zygmuntowicz udowodnił, że można napisać “lepsze Railsy” (szybsze, wielowątkowe i bardziej przejrzyste). Podoba mi się inżynieryjne podejście Ezry Zygmuntowicza. Jego Merb jest bardzo ładny, przejrzysty i szybki. Co ciekawe, Ezra zatrudnił kilku developerów Rubiniusa. Zapowiada się że Railsy w końcu spotkały bardzo trudną konkurencję (i bardzo dobrze). Sytuację Ralsów pogłębia to, że nowe ORM’y takie jak DataMapper i Sequel również stanowią zagrożenie dla dominacji Active Record nawet w kontekście Railsów.

PickAxe i inne książki

Zed przeprowadził bardzo ciekawą krytykę chwalonej PickAxe. Ostro rozjechał autora za używanie głupich przykładów, niezgodnego z konwencjami Rubiego nazewnictwem zmiennych, i co najważniejsze, ominięcie szerokim łukiem najważniejszej i najbardziej atrakcyjnej cechy Rubiego – łatwości metaprogramowania. PickAxe, zdaniem Zeda, odwołuje się do starych praktyk projektowania obiektowego z roku 2001. Zed idzie nawet dalej, uważa że ta książka promuje złe nawyki programistyczne i zachęca do pisania złego kodu. Twierdzi nawet, że ta książka zamiast pomóc, zaszkodziła Rubiemu aby wcześniej wypłynął na szeroką scenę.

Faktycznie, w latach 2001-2004 o Ruby praktycznie nikt nie słyszał. Jakieś nieliczne wyjątki uczyły się Rubiego na książce Dave’a Thomasa ale język jako taki był czymś bardzo malo znanym. Sytuację zmieniło dopiero pojawienie Ruby on Rails w 2005 roku, ktore spowodowały znaczący wzrost popularności Rubiego (ja sam też zainteresowałem się też Railsami, a dopiero później Rubim). Dopiero Railsy pokazały piękno i moc metaprogramowania w Ruby, coś co zachwyciło rzesze ludzi, coś czego nie mają inne języki. I nie wiem jak by się wysilano, nie da się uzyskać tak pięknego i eleganckiego metaproramowania w PHP, Javie, czy nawet Pythonie. Zed bezpardonowo stwierdził, że PickAxe tylko zaszkodził Rubiemu zamiast mu pomóc.

Wpierw mnie zaskoczyła ta opinia, ale później, jak się zastanowiłem, to muszę przyznać że dużo w tym racji. Nigdy do mnie nie przemawiały użyte w książce przykłady. Ceniłem ją głównie za to, że w ogóle jest cokolwiek na temat Rubiego, i że opisano bibliotekę standardową Rubiego. Jestem ciekaw, co Zed by powiedział na książkę Hala Fultona “The Ruby Way”. Jej drugie wydanie właśnie zostało wydane po polsku. Szkoda tylko, że ma w polskim wydaniu mylący tytuł sugerujący, że to tylko jakiś zestaw 400 przykładów. Książkę się dosyć dobrze czyta. Lepiej niż PickAxe. Tą pierwszą trochę traktuję jak podręcznik do bibliotek Rubiego.

Co ciekawe, dostało się też trochę książce Agile :) Ale generalnie dużo nie ma co się przyczepić. Książka jest raczej dobrze napisana, szkoda tylko, że opisuje starsze Rails 1.2 a nie 2.0. No cóż, nie wiadomo czy wyjdzie trzecie wydanie, bo DHH jakoś się do niego nie pali.

Z ciekawości sprawdziłem inną książkę, polecaną przez Zeda, The Rails Way. Faktycznie wygląda na dobrze napisaną i uwzględnia nowsze cechy Railsów. Jest dostępna online (choć nie za darmo) przez O’Reilly Safari Books Online (tak w ogóle to świetny serwis, który warto sobie zaprenumerować).

Rubinius, JRuby i Jubinius

Zed się wkurzył, nabluzgał, ale zwrócił uwagę na kilka ważnych kwestii. Także odnośnie samego Rubiego to pochwała dostała się JRuby i Rubiniusowi. Szczególnie ten drugi może wkrótce kompletnie zagrozić dominacji MRI jaki jest używany w dzisiejszej, opartej na C, implemementacji Rubiego. Jeśli szybko nie powstanie kompletnie ukończony YARV (włączony do Ruby 1.9), to Rubinius zwycięży. Temat Rubiniusa jest on tematem naszych dyskusji na kanale IRC #rubyonrails.pl. Podejście jest tu trochę podobne do pythonowego PyPy, choć Rubinius nawiązuje bardziej do 30 lat doświadczeń Smalltalka. Celem jest stworzenie najszybszej wirtualnej maszyny Rubiego oraz łatwego i szybkiego rozwoju dla samego Rubiego. Dzięki temu, że mamy tu do czynienia z Ruby którego implementacja napisana jest w Ruby, znacznie łatwiej jest rozwijać język.

Co ciekawe, autorzy JRuby zastanawiają się czy nie zrobić podobnie. I już są dyskusję o tym aby stworzyć analogicznie Jubiniusa. Tak jak Rubinius w łatwy sposób wciąga biblioteki napisane w C, Jubinius wciągałby te napisane w Javie. Jubinius miałby dodatkowo o tyle wygodniejszą sytuację, że implementacja całej biblioteki standardowej Rubiego jest już przepisana do Rubiego. Jubinius mógłby z marszu wykorzystać ten kod.

Sphinx i Merb - silna konkurencja dla Ferreta i Railsów

Jarosław Zabiełło — Fri, 30 Nov 2007 18:18:00 +0100

Sphinx to alternatywny wobec Lucene/Ferreta silnik wyszukiwania pełnotekstowego. Charakteryzuje się ogromną szybkością działania i małym zużyciem zasobów komputera. Różnica jest tak kolosalna, że jak ktoś pierwszy raz słyszy że Sphinx indeksuje teksty miliony razy szybciej to nie chce wierzyć. Nazywają go odpowiednikiem Nginksa dla wyszukiwania pełnotekstowego. W obu przypadkach autorami są rosyjscy programiści.

Trochę czasu mi zajęło zanim się przekonałem, że do webowego wyszukiwania tekstów, używanie mechanizmów opartych na relacyjnej bazie danych i skryptach Rubiego/Pythona, to raczej kiepski pomysł. W artykule Full text search in Ruby on Rails elegancko wypunktowano różnice między Ferretem MySQL. Ruby on Rails (a właściwie Active Record) posiada nawet gotowy plugin acts_as_ferret który bardzo upraszcza integrację Ferreta z bazą MySQL. W sieci można spotkać sporo artykułów osób zachwyconych możliwościami Ferreta i łatwością użycia plugina acts_as_ferret. Jest tylko jeden drobny problem. Czas indeksowania tekstów.

Próbowałem zaindeksować tabelę (dla MySQL 5) składającą się z ok. 2.5 mln rekordów (zebranych z ponad 100 przekładów Biblii w 19 wersjach językowych). Prób a postąpienia wg wskazówek z pliku README do tego pluginu okazała się strzałem w stopę. Mój dwurdzeniowy MacBook Pro 2.2GHz, 2GB RAM jak rozpoczął tworzenie indeksów jednego dnia po południu, to nie skończył go na drugi dzień. Przerwałem to szaleństwo. Wygenerował jakieś 250 MB indeksów na 1.2GB do stworzenia. Znacznie szybciej było napisać sobie własny skrypt Rubiego do indeksacji. Pomielił jakieś dwie godziny, ale za to nie 2-3 doby! W sumie indeksowanie większych plików do Ferreta blokuje komputer na dłuższy czas. Mało ciekawie.

I wtedy spróbowałem Sphinksa. Różnica byla tak kolosalna, że wpierw myślałem, że jest jakiś błąd w programie. Sphinx tą samą tabelę poindeksował mi w niecała minutę. Wszelkie operacje wyszukiwania różnych boolowskich kombonacji słów trwa niezmiennie 1-2 ms. Jest po prostu natychmiastowe! Algorytm Sphinksa jest niezrównanie lepiej przemyślany. Co z tego, że teoretycznie Lucene czy Ferret mają więcej możliwości, skoro w praktyce 95% z nich posiada też Sphinx? Jak ktoś chce, to do Active Record jest również plugin acts_as_sphinx.

Jestem ciekaw kiedy będą gotowe pluginy acts_as_ferret i acts_as_sphinx do DataMapper’a, znacznie szybszego i ogólnie lepiej przemyślanego ORM’ niż Active Record.

Tak w ogóle, to Railsom wyrasta groźna konkurencja w świecie Rubiego. To nie Nitro, ale Merb może podciąć dominację Railsów. Korzysta z railsowej filozofii, ale dużo szybszy, w pełni wielowątkowy, komponentowy i w wielu punktach lepiej przemyślany (ma lepswzy resolver URL, domyślnie korzysta z Erubis, najszybszego systemu szablonów jaki jest do Rubiego). Merb przypomina mi trochę filozofię leżącą u podstaw pythonowego Pylons. Jest tak samo z definicji nastawiony na elastyczność i łatwość wymiany swych komponentów oraz duży nacisk położono na wydajność. Czyli to, co nagminnie było od zawsze lekceważone przez developerów Railsów skupiających się za bardzo na wymyślaniu nowej funkcjonalności. Nie bez znaczenia jest to, że proces migracji aplikacji z Rails do Merba jest raczej prosty, bo ten drugi potrafi pracować z Active Record. Więc w zasadzie modele można przerzucać bez większego problemu. Może Merb nie zdetronizuje Rails, bo ten tak całkiem nie stoi w miejscu i lada dzień ma wyjść wersja finalna 2.0 (w momencie pisania tekstu jest już RC2). Ale może zmobilizuje developerów Railsów aby trochę popracowali nad jakością już stworzonego kodu. A jak nie, to nic straconego. Dobra konkurencja dla Railsów nie zaszkodzi.