Nie kryję się z tym, że od jakiegoś czasu próbuję swoich sił przy nauce Clojure. Ostatnio próbowałem napisać swój pierwszy projekt z użyciem narzędzia Leiningen. Gdyby przyrównać go do rubiowego ekosystemu to jest to jakby połączenie Bundlera i rake. Ale właściwie chciałem napisać o czymś innym.

Jak można przeczytać w internecie Ruby 2.0 ma być nieco odchudzony. Sporo bibliotek ze stdliba ma być wyciągniętych do gemów, co mi się całkiem podoba. Tego typu zmianę przeszedł Clojure w wersji 1.3. Clojure normalnie jest rozpowszechniany w dwóch paczkach - clojure-main i clojure-contrib. Właśnie ten clojure-contrib przeszedł takie zmiany w wersji 1.3. Na przykład biblioteka clojure.contrib.math została wydzielona do clojure.math.numeric-tower i jest rozpowszechniana jako oddzielna "paczka".

A co to ma wspólnego z Leiningen? Otóż w pliku-manifeście (nie wiem czy to dobra nazwa) w grupie :dependencies wpisuje się: A w Ruby 2.0 mogłoby być coś takiego: Całkiem ładnie to wygląda, przynajmniej według mnie. Idea by Ruby nie ciągnął za sobą wielkiego ogona bibliotek, których i tak nie chcę używać wydaje mi się bardzo dobra i interesująca. Z drugiej strony może powstać małe dependency-hell, gdy jakieś gemy będą musiały robić sobie zależności do libów, które kiedyś były w standardzie.

Po Eloquent Ruby Russa Olsena sporo sobie obecywałem, może nawet trochę za wiele. Czy jestem zawiedziony? Chyba trochę tak. Ale z drugiej strony ciężko pewnie o książkę o Ruby, która mogłaby zaskoczyć programistę z pięcioletnim doświadczeniem. Chociaż Eloquent Ruby w pewnych miejscach był zaskakujący i bardzo ciekawy (rozdziały o operatorach). Czasami miałem pretensje o autora, że opisuje kompletne podstawy. Czemu każda książka o Ruby musi opisywać takie rzeczy jak if, until, while? Autor chyba mógł załóżyć, czytający zna chociaż podstawy Rubiego. Zastanawiające jest to, że w poprzedniej książce tego autora Design Patterns in Ruby też mi się to nie podobało.

Podsumowując całą książkę trzeba ją uznać za pozycję dobrą, nawet tak na 4+. Książka w dobry sposób pokazuje niektóre bardziej 'magiczne' aspekty języka. Kolejna książka, która bardzo dużo może zaoferować komuś kto już zna Rubiego, ale nie ma jeszcze dużego doświadczenia.

Ostantio odkryłem, dość przypadkiem przyznam, jedną ciekawostkę związaną z forkowaniem procesów w Ruby. Problem dzięki, któremu odkryłem metodę Kernel#at_exit polegał na tym, że aplikacja oparta na Sinatrze i Thin w momencie odpalania innego procesu poprzed fork w pewnym momencie usuwała swój pidfile.

Winowajca

Winowajcą, w cudzysłowie, była metoda daemonize z modułu Thin::Deamonizing, która definiuje blok at_exit. Blok robi super prosta rzecz: usuwa pidfile. Cała zagwozdka polega na tym, że blok at_exit jest uruchamiany również po zakończeniu procesów potomnych. Prościej mówiąc wszystko co uruchomimy przez fork w aplikacji opartej o Thin (sprowadzonym do demona) prędzej czy później dojdzie do tego at_exit i usunie pidfile

Rozwiązanie

Rozwiązanie jest super hiper proste:

RTFMTTE!

W dokumentacji jak byk jest napisane, że jeśli chce się uniknąć uruchomienia at_exit należy zakończyć proces metodą exit!, co spowoduje jego natychmiastowe zakończenie. Przygotowałem krótkie streszczenie - gist.

To co najbardziej mi się podoba w społeczności stworzonej wokół języka Ruby to kultura testowania pisanego oprogramowania. Obojętnie czy jest do duży serwis internetowy pisany w Rails, mała stronka wydziergana w Sinatra czy bilioteka do realizowania konkretnych zadań prawie zawsze ma napisany dobry zestaw testów. Brak takich testów bardzo często jest piętnowany i uważany za skazę na jakości tworzonego oprogramowania.

Książka Growing Object Oriented Software, Guided by Tests to doskonała pozycja dla wszystkich, którzy chcieli by ugruntować swoją wiedzę o TDD lub chcą poznać techniki związane z automatycznym testowaniem oprogramowania. Książka pokazuje krok po kroku co i jak testować. Na co zwrócić szczególną uwagę, co testować na którym poziomie testów. Według mnie pozycja obowiązkowa dla każdego programisty. Robert 'Ruper' Pankowiecki w swojej recenzji tej książki pisze, że książka powinna być obowiązkowa na studiach. Trudno mi się z tym nie zgodzić!

Jeśli nie czytałeś tej książki kup ją i przeczytaj. Zamów do firmowej biblioteczki. Jestem pewien, że na tym skorzystasz.

rvm znam i używam od jakiegoś czasu. Jednak nigdy nie miałem go porządnie skonfigurowanego. Dopiero kilka dni temu porządnie się nim zająłęm. Nie będę pisał o tym czy rvm jest bo to już bardzo dobrze opisał Łukasz Adamczak na stronach Rubysfery. Ja dziś opiszę kilka spraw, które tam umknęły, a które u mnie się fajnie sprawdzają.

Gemsety

Gemsety były opisywane przez Łukasza, ale kilka słów więcej nie zaszkodzi. Czasami zdarza się, szczególnie w starszych projektach, że mając zainstalowane kilka wersji gema - jedną święzą, drugą starą (powiedzmy, że sprzed 2 lat) - iż projekt nijak nie chce ruszyć. Ja nazywam gemsety jak jak projekty przy których pracuję. Każdy projekt dostaje swój wyizolowany zestaw gemów - gemset i tak mam gemsety: @getresponse, @multiconverter, @clickmeeting_partners i kilka innych ...

Aliasy

Ileż to razy zadarzyło mi się wpisywać rvm use ruby-1.8.7-p330 i zawsze myliłem się do co numeru patchelevla. Musiałem sprawdzić listę zainstalowanych wersji i dopiero poprawnie wpisywałem rvm use ... Aliasy to rozwiązują. rvm alias create 1.8.7 ruby-1.8.7-p334 Powyższe polecenie tworzy alias 1.8.7 i nidy nie będzie już trzeba wpisywać patchlevela, wystarczy rvm use 1.8.7. Podoby alias mam stworzony na najnowszą wersję z lini 1.9.

Nie chce mi się tego pisać

I bardzo dobrze! Bo nie musisz. Jeśli stworzysz w katalogu z projektem mały pliczek .rvmrc będzie on odczytywany przy każdym wejściu do katalogu i dzięki niemu rvm może automatycznie przełączyć wersje Rubiego i gemset. Taka zawartość .rvmrc: rvm use 1.8.7@getresponse spowoduje automatyczne przełączenie na alias '1.8.7' i gemset 'getresponse'. Czysta magia! ;-)

Jeszcze bardziej DRY

Po zainstalowaniu kolejnej wersji Rubiego rvm domyślnie zainstaluje takie gemy jak rake i rdoc. Stworzysz swój gemset, wydasz polecenie bundle install w swoim katalogu z projektem i ... nic. Bundler nie jest zainstalowany. Czar pryska. Rozwiązanie: @global gemset. Ten gemset zawiera gemy, które będa dostępne nawet gdy zadeklarujemy, że chcemy używać naszego gemseta. Idealne miejsce na tak powszechnie używany gem jak bundler. Gemy, które mają być zainstalowane automatycznie najlepiej wpisać do pliku ~/.rvm/gemsets/global.gems. Jakby tego mało można zdefiniować gemy, które mają być zainstalowane w @global oddzielnie dla JRuby, Rubinius, REE.

Give my some prompt ...

Jeśli trochę dłużej popracujemy przełączając się pomiędzy różnymi gemsetami, wersjami Rubiego łatwo się zgubić i stracić orientację jakiego gemsetu i Rubiego teraz się używa. rvm rozwiązuje ten problem - rvm-prompt. W połączeniu z zsh i pewnie z każdym innym shellem potrafi dać niezłe rezultaty. Mój prompt wygląda tak: uzyskuje go korzystając z takiego zlogin

To właściwie byłoby na tyle. Jeśli znacie jakieś inne sztuczki, których używacie z rvm to chętnie je poznam.

Ostatnio sporo radności i satysfakcji daje mi zabawa z nowymi Railsami. Pisząc nowymi mam na myśli nowinki jakie pojawiły się w Rails 3. Ponieważ mam podejście do "jeśli piszę coś w domu i nikt mnie nie ogranicza to użyję coś czego nie mam okazji używać nacodzień". W końcu trzeba się czegoś nowego czasem nauczyć ;). I tak ostatnio trochę bawiłem się jQuery w Rails 3.

Każdy kto śledził nowości w Rails 3 wie, że teraz na topie jest "unobtrusive JavaScript" i korzystanie z niestandardowych atrybutów data-*. I tak to co w wcześniejszych wersjach wypluwał helper:

link_to 'Delete', object_path(object), :confirm => "Are you sure?", :method => :delete

wstawiało jakieś wstrętne i rozwlekłe kody JS, a teraz wygląda tak:

<a href="/object/1024" data-method="delete" data-confirm="Are you sure?">Delete</a>

Przez to kod wypluwany przez metody pomocnicze nie ma bezpośrednio do czynienia z kodem JavaScript i nie ma znaczenia czy jest używany Prototype, jQuery czy coś jeszcze innego. Obsługa tego typu helperów umieszczona jest standardowo w pliku public/javascripts/rails.js. Poniżej zademonstruję jak zaimplementować obsługę własnych atrybutow data-*.

Przykładowe zadanie: wyświetlać ilość wpisanych w textarea znaków.
W widoku będzie coś takiego:

= form_for(:message, :url => messages_path, :html => { :class => "form", :id => "new_message_form" }) do |f|
  = f.text_area :body, "data-counter" => "span#message-counter"
  # bla bla bla

W rezultacie zostanie wypluty HTML:

 
<form action="/messages">
  <textarea name="message_body" data-counter="span#message-counter" />
</form>
 

Aby licznik automatycznie się odświeżał należy dopisać jego obsługę w JS, ja użyłem jQuery i zrobiłem to tak:

$(document).ready(function() {
  $(document).find('*[data-counter]').each(function(element) {
    var counter = $($(this).attr('data-counter'));
    $(this).keyup(function(event) { counter.html($(this).val().length) })
  })
})

Trzeba tylko pamiętać by plik JS ładować w szablonie za pomocą javascript_include_tag.

Ciekawe linki na podobny temat:

• Dynamically removing some website content in Rails 3 Way (Prototype, UJS) Robert Pankowecki opisał coś takiego przede mną, nie ukrywam, że wzorowałem się na nim i jego wpis trochę otworzył mi oczy. Dzięki Robert!
• jQuery with Rails 3 - opis jak zastąpić standardowy rails.js tym, który korzysta z jQuery

Jak powszechnie wiadomo Rails 3 zostało wydane. Niektórzy niecierpliwi (w tym ja) już wcześniej bawili się wersjami beta i release candidate. Kilka osób już chwaliło się udanymi przejściami z wersji 2.3 na 3.0. Dla mnie Rails 3 to przede wszsytkim okazja na przejście z Ruby 1.8 do 1.9. Dziś opiszę w jaki sposób uruchomiłem tandem Rails 3.0 - Ruby 1.9.2 na hostingu współdzielonym Megiteam.

Ruby 1.9.2

Moja ulubiona firma hostingowa - Megiteam już od dłuższego czasu dawała możliwość korzystania z Ruby 1.9.1-p0. Jak zrobić to krok bo kroku w pomocy Megiteam. Bułka z masłem. Napisałem maila do Pani Magdy i po godzinie wersja była podbita do 1.9.2. Jedyną rzeczą jaką musiałem zrobić, a której nie ma w ww. artykule to dopisanie katalogu z plikami wykonywalnymi gemów do PATH: /home/seban/www/.ruby/gems/1.9/bin/. Pierwszy sukces! Tak, pewnie można zrobić to za pomocą rvm, jednak ja nie próbowałem.

Bundler

Jeśli nie wiesz co to jest Bundler zachęcam do przeczytania artykułu w serwisie rubysfera.pl.
Instalacja bundlera: gem install bundler. Nie powinno być najmniejszych problemów. Drugi sukces!

Thin

Megiteam daje trzy możliwości uruchamiana aplikacji Rails:

• Mongrel, Ruby 1.8
• Thin, Ruby 1.8
• Thin,Ruby 1.9

Jak widać wybór dla Ruby 1.9 jest bardzo prosty ;). Wybrałem thin. Jednakże tutaj pojawił się problem. Po zdeployowaniu aplikacji (o tym za chwile) aplikacja nie wstawała. Według mnie problemem okazała się wersja thina, domyślnie jest to 1.2.2. Po zainstalowaniu (zwykłe gem install) najnowszej wersji 1.2.7 aplikacja wstała już bez problemu. Dodatkowo trzeba pamiętać by ustawić zmienną środowiskową RACK_ENV na żądane przez nas środowisko - 'production'.

Deploy

Deploy za pomoca Capistrano nie różni się specjalnie od standardowego. Musimy jedynie zmienić dwie rzeczy:

• deploy musi uwzględniać użycie bundlera
• restart aplikacji musi się odbyć za pomocą meigteamowego skryptu 'restart-app'

Pierwszą sprawę załatwiłem metodą copy-paste. Kacper Bielecki przedstawił już działające rozwiązanie połączenia bundlera i capistrano. Wszystko jest tam całkiem proste i dobrze wytłumaczone.
Restart aplikacji już kiedyś opisywałem. Cały Capfile dostępny jest w formie gista.

Ostatnio piszę o książkach. Właściwie tylko i wyłącznie o książkach. Dziś nie będzie inaczej - kontunuję książkowy temat. Dziś kilka moich spostrzeżeń o książce Distributed Programming with Ruby Marka Batesa. Wspomniana ksiązka wydana jest przez wydawnictwo Addison-Wesley. Wcześniej opisywałem kilka książek z tego wydawnictwa Refactoring. Ruby Edition i Ruby. Wzorce Projektowe Miałem również kontakt z innymi ksiązkami tego wydawnictwa takimi jak The Ruby Way i The Rails Way, które według mnie są na wysokim poziomie. Niestety Distributed Programming with Ruby to najsłabsza książka z wyżej wymienionych. Jeśli tamte mogłem oceniać na 4.5/5 lub nawet 5/5 to ta książka może liczyć na 3/5.

Książka to fajny przekrojowy materiał przez kilka bibliotek, które można wykorzystać. Ale mam wrażenie, że gdyby wyciąć połowę z tych 250 stron to książka nic by nie straciła. Książka ogólnie bardzo pomagała mi w zaśnięciu. Szczególnie druga część, gdzie były omawiane takie biblioteki jak:

• RingyDingy - brzmi jak imie dla pasa, ostatni commit 15.12.2006.
• Starfish - ostatni commit 06.12.2007
• Distribunaut - autorstwa tego samego Pana co cała książka
• Politics - też wielkiej kariery ten gem nie zrobił

Najciekawszą częścią książki było omówienie Starlinga i AMQP.

Jeśli jesteś programistą na dorobku to odpuść sobie - nie warto kupować tej książki za (o zgrozo!) $ 39.99. Jeśli zamawiasz książki do firmowej biblioteczki to można to dorzucić, pewnie i tak będzie w rabacie z czymś lepszym.

Ostatnio jakoś same książki opisuję. Dziś chciałem opisać książkę Ruby. Wzorce projektowe Russa Olsena. Inaczej niż "Refactoring, Ruby edition" książka jest wydana po polsku i można ją kupić choćby w księgarni Helionu. Ja czytałem zarówno polską jak i angielską wersję i muszę powiedzieć, że obie czyta się dobrze. Książka niestety zawiera wstęp do języka Ruby. Według mnie to lekkie przegięcie by wpychać wszędzie "szybkie wprowadzenie do Ruby". Kompletny Ruby-laik pewnie po tym krótkim kursie (50 stron) będzie rozumiał wszystkie przykłady zamieszczone w książce.

W książce mamy opisane kilka standardowych wzorców projektowych pokazanych już przez "gang of four" jak np. singleton, strategia, fasada, ... Ale jest też kilka specyficznych takich jak: metaprogramowanie, Domain Specific Language. Każdy wzorzec jest opisany, pokazany na przykładzie i dodatkowo dla fanów UMLa dołączony jest prosty diagramik.

Uważam, że książka jest dobrą pozycją dla programistów, którzy nie są nowicjuszami, ale też nie da wymiataczy. Ale pewnie wielu "wymiataczy", którzy produkują kod znajdą w książce trochę nowości dla siebie. Ja czytałem tą książkę pierwszy raz po kilkunastu miesiącach znajomości Rubiego i bardzo dużo dobrych treści w niej znalazłem. Bez powszechnego w wielu książkach wodolejstwa i robienia słodkiego "pitu-pitu" zamiast konkretnych informacji. Jak ktoś pisze w Ruby i jeszcze nie zna wzorców projektowych to musi to przecztać.

Dziś chcę napisać o książce Refactoring: Ruby Edition. Stety albo niestety książka nie jest dostępna w języku polskim. Książka nie jest przeznaczona dla początkujących programistów Ruby. Nie ma w niej szybkiego kursu języka, jednak nie trzeba być "wyjadaczem" by zrozumieć treść. Już pierwszy rozdział, który jest jednym wielkim przykładem - podsumowaniem całej książki jednoznacznie pokazuje czego ta książka ma nauczyć. W pierwszym rozdziale autor pokazuje krok po kroku zmiany w gorszym kodzie, które czynią, że jest on lepszy. Każda decyzja, zmiana implementacji jest omawiana i wyjaśniana. Podobnie jest w dalszej części książki. Rozdziały podzielone są tematycznie. Jest rozdział mówiący o uproszczeniu złożonych wyrażeń, generalizacji obiektów czy przesuwaniu metod pomiędzy klasami.

Książkę właściwie można polecić wszystkim, którzy chcą skończyć z Burdel Driven Development. Którzy znają Rubiego już na tyle, że potrafią z nim napisać trochę bardziej skomplikowane programy. Po przeczytaniu tej książki programista powinien łatwiej wyczuwać tzw. "code smells" i powinien znać sposoby jak się ich pozbyć.

Warto zwrócić uwagę, że wydawnictwo Addison-Wesley posiada chyba najlepszy zestaw książek o Ruby w tej chwili. A nad cała serią piecze sprawuje Obie Fernandez. Co chyba jest dodatkową rekomendacją

Wczoraj pobuszowałem trochę w Android markecie. Wyszukiwałem aplikacji pod konkretne frazy. Z ciekawości poszukałem aplikacji dla frazy agile i scrum.

Aplikacji niewiele, ale moją uwagę przykuły aplikacje do planning pokera. Osobiście nigdy nie korzystałem z tej techniki, ale wydaje się mi ona ciekawa. Aplikacja BC Planning Poker jest bardzo prosta. Jej głównym zadaniem jest pokazywanie obrazka przypominającego kartę z esytmacją. Domyślną skalę esytmacji (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, coffee) można dowolnie zmieniać. Według mnie może to być całkiem fajna aplikacja dla kogoś kto używa tej techniki, a nie ma wydrukowanych ładnych karteczek.

Jestem pewien, że użytkownikcy iPhone również mają taką aplikację, ktoś używał może czegoś podobnego i może pochwalić się sowimi wrażeniami?

Ostatnio pisałem o swoim punkcie widzenia na standard kodowania w Ruby. Jakoś dziwnie się to zbiegło z czasem, gdy jeden z project managerów w firmie mocno wziął sobie do serca pisanie dokumentacji. Zaowocowało to serią commitów z opisami typu: Comments, Comments fix. Jeden z impliksowych perlistów podesłał mi przykład jak to oni dokumentują swój kod. W przykładzie znalazłem coś co mi się strasznie spodobało: dokumentacje w wyrażeniu regularnym!

Ruby zapewnia wbudowaną obsługę dopasowania wyrażeń regularnych. W Ruby wyrażenia regularne są instancjami klasy Regexp. To co mnie szczególnie ostatnio zainteresowało to tryb Regexp::EXTEND, w którym to ignorowane są białe znaki i dopuszczone są komentarze. By Regexp pracował w tym trybie: regexp = Regexp.new('dopasowanie', Regexp::EXTENDED) regexp = /dopasowanie/x

Poniżej przykład zastosowania, prosty bo prosty ale ideę chyba prezentuje. Wyrażenie regularne sprawdzające poprawność adresu email (niezastanawiaj się drogi czytelniku nad skutecznością, ale nad formą wyrażenia). Kiedyś, ktoś napisał fajny "sprawdzacz" do wyrażeń regularnych w Ruby: rubular.com, ale dość słabo radzi on sobie z rozszerzonymi wyrażeniami. Na koniec polecam jeszcze zapoznać się z dokumentacją klasy MatchData

A teraz mała odskocznia, ale tylko mała. Ostantio kiedy szukaliśmy do Implix programisty Ruby napisałem o tym na blogu zamieszczając zdjęcie. Programistę znaleźliśmy, ale zdjęcie żyło własnym życiem ... Co prawda to miejsce jest już zajęte, ale tuż obok możesz siedzieć Ty. Bo właśnie szukamy programisty Ruby. Nie wymagamy doświadczenia. Chcemy tylko byś orientował się w temacie i znał trochę Ruby i Rails. Gwarantujemy, że dużo się nauczysz i napewno nie zaśniesz z nudów. Praca w Gdyni, blisko morza (300 metrów). Zapraszamy.

Chyba każdy kto pracował przy jakimś projekcie, w którym uczesniczy więcej niż jeden programista czuł potrzebę zapanowania w jakiś sposób nad pisanym kodem. Według mnie pierwszą rzeczą jaką trzeba stalić w takiej sytuacji jest standard kodowania. Taki standard to nic innego jak zasady, których należy się trzymać by kod był czytelny i zrozumiały dla wszystkich.

W firmie w której pracuję Implix są standardy kodowania zarówno dla PHP jak i dla Ruby. Standardu nie można ot tak sobie narzucić. Standard powinien zostać wypracowany przy współpracy wszystkich zainteresowanych. W naszym przypadku standard został zaproponowany przez najbardziej doświadocznego programistę, pozostali mogli się z nim zapoznać, zgłosić uwagi ..., aż w końcu powstała wersja zaakceptowana. Standard kodowania obejmował konwencje nazewnictwa, wcięcia, białe znaki, nawiasy, instrukcje i komentarze. Oczywiście na końcu dokumentu znajdował się przykład całej klasy napisanej zgodnie z standardem i w całości udokumentowanej.

Standard kodowania istnieje już ponad 2 lata. Każdy w zespole tworzy kod zgodnie ze standardem lub przynajmniej się stara. Kod źródłowy powstający w firmie wygląda zawsze podobnie, a nie każda klasa inaczej. Każdy nowozatrudniony pracownik dostaje taki standard do przeczytania. W każdej chwili można zajrzeć do standardu (jest spisany na firmowym wiki). Wszelkie niezgodności ze standardem kodowania są wytykane podczas inspekcji kodu.

Poniżej kilka punktów:

• linia nie powinna mieć więcej niż 100 znaków
• nie używam tabulacji, zamiast tego 2 znaki spacji
• 2 puste linie przed i po modifikatorach dostępu
• 2 puste linie oddzielają definicje metody
• każda metoda publiczna powinna mieć dokumentację
• jeśli metoda przyjmuje więcej niż 1 argument, powinna być wywołana z użyciem nawiasów
• dodatkowo lubię jak metody klasy są definiowane przed metodami instancji
• jeśli z nazwy klasy nie wynika wprost do czego służy powinna mieć opis w postaci komentarza

Ten tekst napisałem sugerując się moimi doświadczeniami wynikającymi z pracy z kodem pisanym przez wielu programistów. Czasem lepszych, czasem gorszych, czasem z szerszym, czasem z węższym monitorem ... Ale każdy z nich pisał kod inaczej. Jeden wstawiał tabulacje, inny spacje. Hardkorowcy mieszali metody publiczne z tymi ukrytymi. Programiści! Starajcie się pisać w jakiś spójny, uporządkowany sposób. Nie chcesz odziedziczyć niedbale napisanego kodu, prawda? W takim razie sam zacznij dbać o jego estetykę i nie traktuj każdego projektu na zasadzie "napisz, zgarnij kasę i zapomnij"!

Jeśli ktoś czyta na bieżąco blog highscalability to pewnie zauważył co jakiś czas pojawiające się hasło noSQL, lansowane przez SQL hejterów. Jedną z kilku alternatyw dla relacyjnych baz danych jest MongoDB, więcej informacji na temat samej bazy danych można przeczytać na jej stronie. W naszym małym, polskim grajdołku gdzie dostęp do nieograniczonej ilości baz danych MySQL/PostreSQL w ramach hostingu współdzielonego jest rarytasem na próżno szukać wsparcia dla baz danych takich jak MongoDB lub CouchDB. Na szczęście MegiTeam pozwala zarówno na nieograniczoną ilość baz MySQL/PostresSQL jak i na instalację MongoDB.

Do zbudowania MongoDB używane jest narzędzie Scons, które wymaga Python 2.5. Domyślnie na współdzielonym hostinguMegiTeam zainstalowany jest Python 2.4, ale można łatwo to zmienić. W pliku ~/.environment należy dopisać linię: PATH=$HOME/.python/bin:/usr/local/python2.5/bin:$PATH:/var/lib/gems/1.8/bin/ A co do Scons, po ściągnięciu i rozpakowaniu źródeł powinno wystarczyć coś takiego: python setup.py install --prefix=$HOME/.python. Ja osobiście skorzystałem z przychylności admina, ktory mi zaisntalował Sconsa. Ponieważ mam współdzielony hosting możliwe, że inni użytkownicy serwera również mają dostęp do scons, radzę sprawdzić.

Po ściągnięciu źródeł MongoDB w katalogu wydajemy polecenie scons all Budowanie MongoDB trochę trwa, więc radzę zrobić sobie w tym czasie herbatę lub zając się czymś innym. Warto też upewnić się, że na hostingu współdzielonym starczy nam miejsca. Trzeba mieć przygotowane ok. 270 MB. Po zbudowaniu należy skopojować pliki do jakiegoś katalogu ujętego w PATH. cp mongo mongod mongodump mongoexport mongofiles mongoimportjson mongorestore mongos ~/bin

Zabawki

• sterowniki pozwalające połączyć się z MongoDB z poziomu PHP, Ruby, Python, Java, Perl, C++, ...
• kilka slajdówz prezentacji o MondoDB
• Mongo Mapper ORM (?) korzystający z MongoDB
• małe wprowadzenie do MongoDB napisane na blogu EngineYard

Po co to komu?

Czy aplikacja oparta na MongoDB ma szanse dobrze działać?. Osobiście ciężko mi coś na ten temat powiedzieć. Tomasz Stachewicz z Aenimy odgrażał się, że przed RuPy postara się pokazać "pierwszą w Polsce" aplikację w Railsach używającą MongoDB. Trzymam kciuki! Na RuPy 2009 mają odbyć się dwie prezentacje poświęcone MongoDB. Mike Dirolf zrobi wstęp do MongoDB, a Obie Fernandez pokaże jak połączyć Rails i MongoDB.

Kazdy serwis internetowy, który zdobył popularność w sieci w końcu staje przed problemem wydajności. Problem często daje się dość prosto rozwiązać, stosując proste zasady opisane chociażby w książce Steve Soundersa High Performance Web Sites. Głównym przesłaniem jest: zmniejsz ilość żądań wysyłanych do twojego serwera. Przeglądarka wysyła żądanie za każdym razem, gdy musi coś pobrać z serwera. Plik html, css, js, jpg, ... Dla każdego obrazka, arkusza stylu, skryptu JavaScript wyśle żądanie. Im mniej będzie żądań tym szybciej klient zobaczy stronę. Logiczną wydaje się potrzeba minimalizacji ilości plików JS lub CSS. Chcę pokazać plugin do Ruby on Rails asset_packager, który potrafi spakować dla nas pliki CSS i JS w jeden duży.

Plugin ma w zasadzie prostą ideę: złącz pliki w jeden i usuń to co nie jest w nich potrzebne (komentarze etc.). Jednak nie jest to taki zwykły prosty skrypcik do łączenia plików. Plugin ma możliwość tworzenia wielu paczek z plików, które zostaną mu wskazane. Takie ustawienia pluginu zapisane w pliku config/asset_packager.yml sprawią, że zostaną utworzone dwie paczki dla JavaScriptu i stylów. Pierwsza paczka JS "base" składa się z pięciu plików, druga "secondary" z dwóch. Pojedyńczy plik CSS/JS może znajdować się w wielu paczkach. Możemy serwować różne paczki dla zalogowanych użytkowników i inne dla niezalogowanego użytkwonika odwiedzającego stronę. Taką polityke stosuje serwis pomagający zarzadzać finansami - benefi.pl. Złączone paczki nie są generowane w locie kiedy trzeba, należy je utworzyć ręczkie poprzez odpowiednie zadanie rake: rake assets:build_all. W layoutcie należy użyć helpera javascript_include_merged i stylesheet_link_merged.

Wrzucanie takich połączonych paczek do repozytorium i przebodowywanie ich za każdym razem gdy zmienimy cokolwiek w CSS lub JS to jakieś nieporozumienie i aż prosi się o sytuację "zapomniałem przebudować pliki". Zamiast tego proponuję dodać małe zadanie do Capfile: Zadanie będzie wykonywało się automatycznie zawsze gdy zrobimy deploy aplikacji na zdalny serwer. Proste i przyjemne.

Na blogu Jacka Laskowskiego piszącego ostatnio sporo o groovy znalazłem informację o egzaminie Java Black Belt. Poza egzaminem z groovy jest również możliwość sprawdzenia się z Javy, SQL, XML i również istnieje egzamin z Ruby. Lista wszystkich egzaminów jest pokaźna.

Co do egzaminu z Ruby nie był on ani łatwy, ani trudny. Składa się z 34 pytań na które trzeba odpowiedzieć w ciągu 51 minut (każdy powinien spokojnie dać radę), by zdać egzamin trzeba mieć minimum 70% poprawnych odpowiedzi. Jednak nie od razu można podejść do egzaminu - trzeba uzbierać 15 punkcików by móc przystąpić do egzaminu.
Punkty można zdbowyać na kilka sposobów. Najłatwiejszy to pisanie pytań - 2 punkty za dodanie. 2 punkty za to, że pytanie wyjdzie z wersji beta (10 osób musi zagłosować na pytanie). Szczegółowy opis przyznawanych punktów powinien wszystko wyjaśnić. 15 punkcików czyli minimum 5 nowych pytań ... Mam nadzieję, że wkrótce wzrośnie liczba pytań do Ruby.

Skoro jest już egzamin do Ruby i nie jest on jakoś szczególnie nowy to może warto by zainteresować się stworzeniem zestawu pytań bardziej skierowanego na Ruby on Rails lub może Ruby - Advanced? Tak czy inaczej powodzenia na egzaminie ;-)

Szuku to dobrze zapowiadająca się wyszukiwarka ludzi, która dostała się do finału Seedcamp. Niedawno startup uruchomił zamkniętą bete do której mam 20 zaproszeń. Prośby o zaproszenia prosze wysyłać do mnie mailem z tematem "[SZUKU.PL]" lub przesłac adres email do mój JID.
Zapytałem Tomasza Kolinko o to jakich technologii używają do tworzenia szuku.pl.

Z tego co dowiedziałem się od Tomka Kolinko całość pracuje mocno korzystjąc z Amazon Web Services. W tej chwili serwis osbługiwany jest przez 1 - 2 serwery EC2, docelowo planowan jest praca na 10 serwerach stawianych i zdejmowanych w zależności od zapotrzebowania na zasoby. Bardzo skalowalna i elastyczna architektura. Ciekawe ile startupów z tego korzysta? Całość jest zarządzana dzięki Elastic Fox
Jako baza danych używany jest popularny mysql. Choć baza danych ,,daje rade'' w tej chwili to autorzy są świadomi, że za jakiś czas przyjdzie na zmianę.
Całość napędzana przez Javę i Groovy. Ajaksowa magia dzieje się za pomocą Dojo. Panel administracyjny zbudowany jest w oparciu o Grails.
Zbieranie informacji o ludziach to dłuższy temat, ale Tomek Kolinko zdradził mi, że przeszkują między innymi:

• profeo.pl
• goldenline.pl
• linkedin.com

Opracowana jest równiez wersja beta modułu analizującego Wikipedię. Wszystkie strony są analizowane z uwzględnieniem typu (artykuł, aukcja itp.), powiązanych osób.
Serwis był rozwijany przez dwie osoby: Tomka Kolinko i Michała Kłujszo, oboje pracowali nad nim full-time. W tej chwili Michał poświęca więcej czasy na biznes. W niedalekiej przyszłości możliwe są zatrudnienia programistów.

Wszyscy programiści słyszeli chyba kiedyś o IDE NetBeans. Kiedyś strasznie go nie lubiłem, na studiach byłem prawie zmuszany do pisania właśnie z jego pomocą. Od bety wersji 6.0 nie wyobrażam sobie pisać w czymś innym. To tyle wstępu.

Projekt NetBeans obchodzi swoje 10 urodziny i z tej okazji organizowane są NetBeans day. Impreza nie ominie Gdańska (poza tym również Poznań).
Kiedy: 26 października
Gdzie: Wydział Matematyki, Fizyki i Informatyki UG
Agenda pokazuje, że głównie poruszane będą tematy okołojavowe.

Ja niestety mam zajęty weekend i pewnie się nie pojawię. A chętnie bym posłucham ludzi z NetBeans Dream Team pomimo, że codziennie używam innej technologii niż Java.

Gdy ostatnio zacząłem pisać kolejny projekcik ,,do szuflady'' postanowiłem, że nauczę się przy nim czegoś noweog. Chciałem nauczyć się czegoś nowego o testowaniu, a w tym czasie sporo czytałem o Shoulda. Shoulda ma wprowadzić trochę BDD do standardowych testów z biblioteki Test::Unit. O Shoulda było już pisane dużo wcześniej, między innymi Dave Thomas, oraz po polsku Jarosław Zabiełło. Pewnie nie tylko oni, ale o tych dwóch tylko pamiętałem. Dużym plusem według mnie są makra testów. Są makra dla ActiveRecord oraz makra dla kontrolera. Jest też dodatkowy zestaw asercji np. assert_sent_email. Po krótkim oswojeniu testy pisze się wygodnie i szybko.

Shoulda można zainstalować jako plugin do Railsów jak i jako gem.

Osobiście nie pracowałem z innym ORM niż ActiveRecord, ale ciekaw jestem czy i jakie jest zapotrzebowanie na takie metody-makra testów dla innych ORM np. dla Data Mapper.

Czy szukaliście kiedyś rozwiązania jakiegoś problemu programistycznego, potrafiliście go dokladnie opisać, ale nie mogliście znaleźć odpowiedzi w przepastnych zasobach internetu? Z jeśli już znajdowaliście jakieś rozwiązanie to dostęp do niego był płatny? Co za ból ... Albo rozwiązanie problemu dotyczyło jakiś prehistorycznych wersji bibliotek lub czegokolwiek innego i oczywiście w waszym przypadku nie działało? Frustrujące. Dziś na Joel on Software przeczytałem o stackoverflow.com.

Stack Overflow jest serwisem przeznaczonym dla programistów wszelkiej maści. Idea jest prosta: zadajesz konkretne pytania, ludzie piszą odpowiedzi. Odpowiedzi można oceniać, edytować. Oczywiście wszystko ładnie podane na tagowej chmurce. Sami autorzy określają to jako ,,wikipedia dla programistów''. Jeśli aktualnie nie masz problemów żadnych (szczęściarz z Ciebie!) to możesz sprawdzić swoją wiedzę i odpowiedzieć na pytania zadane przez innych. Czyż to nie proste? Keep It Simple, Stupid!
Warto chyba wiedzieć o tym serwisie i dodać do zakładek. Kto wie, może w przyszłości będzie to pokaźny zbiór wiedzy.

Tydzień temu opublikowałem ankietę z której chciałem się dowiedzieć czegoś więcej o polskim światku wokół języka Ruby. Dziś prezentuję jej wyniki.

Ogólnie

Tutaj nie ma co się łudzić na inne wyniki, prawie sami faceci (82) i tylko 2 kobiety.
Więszość odpowiadających się z wieku ,,studenckim'' między 19, a 24 rokiem życia.

Większość odpowiadających mieszka w dużym mieście. Osobiście spowiedziałem się więcej osób z Warszawy. Zaskoczeniem dla mnie jest duża ilość (13) osób z małych miasteczek poniżej 20 tysięcy mieszkańców.

Wśród odpowiadających zdecydowanie dominuje wykształcenie wyższe (32) i można to tłumaczyć wiekiem biorących udział w ankiecie. Wyniki się pokrywają.

Programowanie

Jak długo programujesz?

Czym dla Ciebie jest programowanie?

Zaznacz języki programowania, które znasz

Pytania dotyczące Rubiego

Rubiego ...

Jak długo znasz Ruby?

Jakiego edytora/IDE używasz?

W Twojej pracy Ruby jest?

Czy wiążesz swoją przyszłość zawodową z Ruby?

Skąd czerpiesz swoją wiedzę na temat Ruby?

Z których narzędzi korzystasz?

Raczej nie czuję się zaskoczony przez ogólne wyniki tej ankiety. Chociaż pewne rzeczy mnie dziwią. Spodziewałem się, że jednak Java będzie popularniejsza od C/C++. Na plus mogę zaliczyć to, iż wiedza jest poszukiwana w wielu miejscach i rozkłada się to w miarę równo. Nadal wielu ludzi nie piszde testów z tego co widzę. Narzędzia, które nie są mainstremowe (RoR 2.X, Mongrel) są raczej niepopularne.

Dokładniejsze wyniki opublikowane w Google Docs

Dziś pokażę kilka metod używanych przez sadystycznych programistów to znęcania się nad swoim kodem źródłowym ... i sobą czasem też.

Flog

Flog to zabaweczka przygotowana przez ruby.sadi.st, a jej zadaniem jest ,,punktowanie'' kodu źródłowego.

% flog model.rb
Total score = 14.1985433422944

Finance#none: (11.8)
     2.2: named_scope
     2.2: belongs_to
     1.6: month
     1.4: ago
     1.3: branch
     1.3: lambda
     1.1: assignment
     1.1: validates_numericality_of
     1.1: validates_length_of
     0.8: lit_fixnum

,,Najciężyszym'' kodem według Floga jest named_scope. Może nie jest to najlepszy przykład na pokazanie jak działa Flog, ale idea myślę jest jasna. Oczywiście byłem ciekaw dlaczego coś otrzymuje 6.0 (eval), a coś innego tylko 0.8. Zapytałem autora, oto odpowiedź:

Because that's what I decided felt right based on experience.

Heckle

Heckle to kolejna zabawka od ruby.sadi.st. Zadaniem Heckla jest mutować napisany przez nas kod tak by if zmienił się na < texttt>unless itp. Nasz kod po zmutowaniu powinien zawalić wszystkie testy. Czasem jego wywołanie może trwac bardzo długo. Przyznaję, że nie jest to moje ulubione narzędzie, praktycznie nie używam.

rcov

O tak! rcov jest tym co lubię i tym czego często używam. Rcov służy do sprawdzenia pokrycia kodu przez testy. W uproszczeniu jest to uruchomienie testu i sprawdzanie, które linie kodu źródłowego zostały uruchomione. Wyniki mogą być prezentowane bezpośrednio na wyjściu lub generowania plików HTML pokazujących pokrycie.

Kolejną zabawką jest Saikuro - analizator złożoności kodu. Sprawdza on długość metod (ilość linii) oraz złożoność tychże. Przykładowe rezultaty Saikuro. Czym większy współczynnik złożoności tym gorzej. Taka metoda jest ciężka do zrozumienia i przetestowania np. by ją w pełni przetestować trzeba uwzględnić 20 przypadków testowych.

Narzędziem, które integruje to wszystko w jedno jest Metric_fu plugin do Railsów. Bardzo fajne efekty można osiągnąć łącząc go z narzędziami do ciągłej integracji.

Może mały konkurs kto ma najwięcej punktów we Flogu i największy wynik w saikuro? Kto się odważy? ;)

W jednnym z projektów wykonywanych w pracy musiałem zadbać o poprawność wprowadzanego Europejskiego numeru VAT. Numer jak numer, kilka liter, kilka cyfr, łatwo sprawdzić za pomocą validates_format_of. Jednak sam numer to coś więcej. Musiałem weryfikować jego poprawność z centralnym zbiorze tych europejskich numerów. Na szczęście jest coś takiego jak VIES, który udostepnia nie tylko formularz na stronie, ale także webservice.

Do tego celu napisałem własny walidator - validates_as_vat_number. Całość leży sobie na Githubie i można spokojnie używać. Przykład:

class TestRecord < ActiveRecord::Base
    def self.columns; []; end
    attr_accessor :vat_number, :country_code
    validates_as_vat_number :vat_number,
      :scope => :country_code
  end
 

By poprawnie zwalidować number potrzebny jest samo numer i kraj dla którego będziemy ten numer sprawdzać, dlatego niezbędny jest scope.

W wolnej chwili chcę jeszcze dopisać możliwość ustawiania scope przez jakiś Proc ponieważ najczęsciej walidowany model nie ma pola zawierającego kod kraju w standardzie ISO 3166.

Ostatnio pisałem o nowych książkach, a dziś napiszę o pierwszej z nich jaką przeczytałem. A przeczytałem coś co można chyba uznać już za klasykę książek z półki dla ,,agile developers''. Mianowicie mam tutaj na myśli Practices of an Agile Developer autorstwa Subramaniama i Hunta, całość wydana oczywiście w Pragmatic Bookshelf. Czy oni wydają jakieś złe książki?

Dla kogo jest ta książka? Nie tylko dla programisty co mógłby sugerować tytuł. Kadra zarządzająca niższego szczebla powinna też znaleźć ciekawe informacje w tej książce. W ostatnim rozdziale książki można znaleźć wskazówki skierowane do programisty i oddzielne dla menadżera. Czym ta książka nie jest. Nie dowiesz się z niej nic o podstawach Javy, Rubiego, .Net, czy jakiegokolwiek języka. Właściwie nie dowiesz się z niej nic technicznego. Jeśli chcesz jakąś książkę, dzięki której nauczysz się pisać w którymś z ww. języków to nie kupuj Praktyk Zwinnego Programisty. Ale jeśli umiesz już klepać kod, ale jesteś świadom, że często ma błędy, często piszesz nie to czego oczekują inni lub zespół którym kierujesz nie radzi sobie z zadaniami powinieneś właśnie przeczytać tą książkę. Autorzy opisują co to znaczy ,,agile'', jakie mechanizmy wprowadzić by pracować sprawniej, a produkowane oprogramowanie było właśnie tym czego oczkują klienci. Programiści dowiedzą się czemu muszą pisać testy i nigdy nie spoczywać na laurach.

Ja książkę zdecydowanie polecam. Z tego co wiem nie jest ona wydana po polsku, ale to niczemu nie szkodzi, wręcz przeciwnie według mnie. Angielski to teraz podstawowy język na świecie, a już na pewno w branży IT, więc czytanie tej książki to okazja by się poduczyć, a nie jest napisana jakąś skomplikowaną angileszczyzną. Practices of an Agile Developer pomoże czytelnikom spojrzeć na oprogramowanie z nieco innej strony. Szczerze polecam!

Deployment na Megiteam już kiedyś opisywałem. Wtedy Magda Zarych obiecywała specjalny skrypt do restartowania aplikacji by ich brutalnie nie ubijać. Na początku czerwca obiecany skrypt został udostępniony. Trzeba było zmienić trochę zadania Capistrano.
Ponownie wszystko sprowadziło się do nadpisania deploy:restart

namespace :deploy do
  desc "Restart aplikacji przy pomocy skryptu Megiteam"
  task :restart, :role => :app do
    run "restart-app #{ application }"
  end
end

By mieć spokój z hasłami i nie klepać ich kilka razy pod rząd dodałem klucze RSA do ~/.ssh/authorized_keys na serwerze Megiteam

Z pisaniem bloga u mnie prawdziwy ,,sezon ogórkowy'', ale może teraz będę miał więcej czasu i samozaparcia by pisać coś regularnie. Według mnie sporo przeglądam rssów i czasem trafię na coś ciekawego, postaram się regularnie tworzyć listę ciekawych newsów, stron w sieci, które odwiedziłem w ostatnim tygodniu. No to do dzieła!

50 More Excellent Blog Designs

Na Smashing Magazine zacząłem zaglądać dzięki Maciowi, z którym pracuję. W linkowanym artykule jest mowa o 50 odczapowanych szablonach dla blogów. Niektóre to cacka niesamowite. Ogólnie polecam dodać Smashing Magazine do swoich czytników RSS.

Ruby Banter - Rubinowe Pogawędki

Kolejny link, które dostałem od Macia. Ruby Banter to screencasty, których przewodnim tematem jest pokazanie ciekawych sztuczek w Rubim. Odcinki są którkie, treściwie i opatrzone omawianym przez autorów kodem źródłowym. Ale uważajcie, niektóre rzeczy wymagają czegoś więcej niż tylko znajomość Rails.

Martin Fowler: Articles

Tym razem coś czego nie dostałem od Macia. Martin Fowler to jeden z twórców Agile Manifesto, twórca wielu ciekawych artykułów poświęconych programowaniu i projektowaniu. Polecam się z nimi zapoznać.

Przez 12 lat pozwoliłem gamoniom robić sobie ze mnie jaja

Coś dla czytelników interesujących się piłką nożną w naszym małym polskim wydaniu. Trener opowiada o ,,spółdzielniach'', bezstronnych sędziach. Mnie ten tekst trochę zszokował, chociaż w polskiej piłce informacje o korupcji są bardziej powszechne niż sukcesy polskiej piłki.

Design patterns czyli wzorce porjektoww

Właściwie ekipa z Webusability.pl daje kilka linków do interesujących stron z wzorcami jak powinny być skontruowane użyteczne, funkcjonalne elementy stron internetowych w podziale na konkretne zadania np. formularz sprzedaży itp.

Dynamically created method in Ruby

Ola Bini opisuje sposoby definiowania metod w Rubim. Lektura obowiązkowa dla wszystkich których interesuje meta w programowaniu. ;-). Zalety i wady def, define_method i coś o eval

To wszystko na dziś. Na następne wydanie postaram się znaleźć więcej i lepszych stron.

Gituję. Dziś poraz pierwszy użyłem Gita. Nie zamierzam póki co porzucić Subversion. Założyłem konto na Githubie i nawet napisałem coś, wysłałem i jest publicznie dostępne. Co do Githuba: podoba mi się, nawet całkiem podoba. Szkoda, że obsługuje tylko Gita.

Powody, które mnie skłoniły do spróbowania Gita i Githuba

• oficjalne otwarcie Githuba
• przeniesienie Ruby on Rails na Gita
• występ Ezry Zygmuntowicza na MWRC podczas, których Ezra powiedział trochę ciepłych słów o Gitcie. Polecam obejrzeć!
• nieuniknione wydaje się zrozumienie tego jak on działa i jak się to obsługuje

Moje wrażenia po niecałym dniu zabawy bardzo pozytywne. Bardzo łatwo zacząć: git init, git add i potem już tylko git commit. Trudności przyniosło mi dopiero wysłanie projektu na Githuba, ale po małym szperaniu po serwisie i to się wyjaśniło.
Jeśli ktoś masz trochę wolnego czasu to może się pobawić Gitem, ciekawe doświadczenie. Tymbardziej dla mnie, bo Git to mój pierwszy kontakt z rozproszonym systemem kontroli wersji Bardzo efekciarski, ale też i bardzo pomagający zrozumieć ideę Gita jest ,,network project graph''. Niestety jest to Flash i w projektach dużych takich jak rails jego wyświetlenie sporo trwa.

• Github hosting repozytoriów Git
• Git rozproszony system kontroli wersji
• Git on Rails railscast
• Git on Rails tutorial dłuższy film edukacyjny
• currencies mój pierwszy projekt na Githubie

Czy zdarzyło wam się szukać błędu bardzo, bardzo długo, a na końcu krzyknąć ,,Eureka!''? Mi się w tym tygodniu zdarzyło. Dwa dni szukałem błędu w aplikacji, którą piszę w pracy. Sytuacja była o tyle dziwna, że testy wcale nie powodowały powstania tego błędu ...

Błąd pojawiał się w takiej linii:

 
  item.unit_id = Unit.find_by_name(some_name).id rescue Unit.create!(:name => some_name)
 

Abstrahując już od innych rzeczy w tym kodzie, szczególną uwagę należy zwrócić na rescue. W środowiskach development i test ten kod działał poprawnie. Po uruchomieniu aplikacji na środowisku ,,wstępnie produkcyjnym'' przestawał działać, pięknie rzucając wyjątkiem z poziomu MySQL o błędnym indeksie. Dopisałem sporo testów, ale to ciągle działa. Przejrzałem logi z maszyny produkcyjnej. Napisałem test w identycznymi parametrami jak request wyzwalający błąd, a to mi działa. Porównałem dla pewności jeszcze wersje gemów, nawet MySQL (tak wiem chore, ale tonący brzytwy się chwyta). Dziś rano okazało się, że wszystkiemu winne są whiny nils no i ja po części również. Poniżej przykład działania tej opcji konfigurującej środowisko.

 
# config.whiny_nils = true
>> Unit.find_by_name("bad name")
=> nil
>> Unit.find_by_name("bad name").id
RuntimeError: Called id for nil, which would mistakenly be 4
>> Unit.find_by_name("bad name").id rescue "tworzę nowy"
=> "tworzę nowy"
 

 
# config.whiny_nils = false
>> Unit.find_by_name("bad name")
=> nil
>> Unit.find_by_name("bad name").id
(irb):2: warning: Object#id will be deprecated; use Object#object_id
=> 4
>> Unit.find_by_name("bad name").id rescue "tworzę nowy?"
(irb):3: warning: Object#id will be deprecated; use Object#object_id
 

Czujecie różnicę? W drugim przypadku aplikacja nie miała nawet okazji stworzyć brakującego rekordu w tabeli Units bo nigdy nie mogło tam dojść do wyjątku, tylko ostrzeżenie (które nota bene też nie pojawiało się w logu :(). Jeśli jeszcze nie to spróbujcie kilka razy w konsoli irb nil.id lub nil.object_id. Wynik łatwy do przewidzenia ;-).

Co w tym wszystkim mnie zastanawia najbardziej? Czy domyślna konfiguracja środowisk development i test narzekająca whiny_nils na nil.id jest prawidłowa? Niby zachowanie prawidłowe bo Rails krzyczy do programisty o złym użyciu metody id, ale z drugiej strony ciekaw jestem czy wielu przechwytuje ten wyjątek i w jakiś sposób go obsługuje, nawet nieświadomie. I czemu w środowisku production ta opcja jest wyłączona? A dla Was, które ustawienie wydaje się ciekawe? Wolicie wyjątek czy ostrzeżenie?

Stało się! W minioną niedzielę oddałem moją pracę dyplomową. Oczywiście nie obyło się bez małej przygody. Panią w dziekanacie nie podobała się strona tytułowa założóna w LaTeXu. Ale poza tym, że często robią problemy z niczego, cholernie pilnują godzin zamykania dziekanatu to są bardzo miłe, pomocne i zawsze bardzo milo wspominam moje wizyty w dziekanacie. Dobra! Koniec tego primaaprilisowego pierdzenia! Co do mojej aplikacji dyplomowej.

Do napisania aplikacji potrzebowałem 53 rewizje kodu źródłowego do Subversion, w tym jedno otagowane jako FINAL, które zawiera wersję oddaną do szkoły.
Aplikacja okazała się dużo mniejsza niż przypuszczałem.

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |   501 |   371 |      11 |      51 |   4 |     5 |
| Helpers              |    38 |    33 |       0 |       2 |   0 |    14 |
| Models               |   597 |   255 |      16 |      32 |   2 |     5 |
| Libraries            |   144 |    76 |       0 |      18 |   0 |     2 |
| Integration tests    |     0 |     0 |       0 |       0 |   0 |     0 |
| Functional tests     |  1225 |   959 |      12 |     125 |  10 |     5 |
| Unit tests           |   632 |   473 |      12 |      64 |   5 |     5 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  3137 |  2167 |      51 |     292 |   5 |     5 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 735     Test LOC: 1432     Code to Test Ratio: 1:1.9
  

Pokrycie kodu przedstawia się przywoicie: 96.7 %

I to by było na tyle w kwestii mojej pracy dyplomowej. Pozostaje mi tylko obrona, na której wyznaczenie terminu czekam. Oby jeszcze w kwietniu.

Wdrażanie, przepychanie aplikacji napisanych w Ruby on Rails na serwer produkcyjny lub prezentacyjny bardzo często odbywa się za pomocą Capistrano. Głównym zadaniem Capistrano jest automatyzacja tego procesu. Dziś udało mi się wykonać deploy na serwery Megiteam.

Co właściwie chciałem osiągnąć automatyzując proces przepychania aplikacji na zdalny serwer? Nie szczególnie wielkiego. Pobrać świeży kod z repozytorium na zdalny serwer, zrestartować mongrela. Nic wielkiego. Jednak na Megiteam mongrel jest uruchamiany przez panel użytkownika dostępny poprzez przeglądarkę i gdyby taka instancja mongrela ,,padła'' natychmiast zostanie podniesiona

Repozytorium znajduje się na tym samym serwerze, w katalogu obok desc 'Zaktualizuj kod źródłowy' task :update_code, :roles => :app do run "svn co -q file:///home/seban/www/repos/dyplom/trunk/src #{deploy_to}/releases/#{Time.now.strftime("%Y%m%d%H%M%S")}" end Restart mongrela zapewnia mi inne zadanie: desc 'Restart aplikacji umieszczonej na serwerach megiteam.pl' task :restart, :roles => :app do invoke_command "killall mongrel_rails" end Tak wiem. Brutalne, ale skuteczne. :-)

Od źródła wiem, że nie tylko ja miałem pytania związane z Capistrano. Megiteam obiecało ,,specjalny skrypt, który będzie można użyć z Capistrano''. Pozostaje tylko czekać, około miesiąca.