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ą

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.

Github to wspaniały serwis! Nic nowego tym nie odkryłem. Można nie używać gita, można go nie lubic, ale sam Github fajny jest i basta!
Próbowałem ostatnio wysłać do githuba zmiany, które miały być stworzyć nową wersję gema, którego sobie piszę. Po zrobieniu git push dostałem maila

The gem build failed with the following error: /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': Insecure operation - gem_original_require

Okazało się, że to nie jest nic niezwykłego, kilka osób przede mną też się z tym spotkało. Okazuje sie, że Github nie na wszystko pozawala przy budowaniu gema. Proponuję używać tego skryptu walidacji gemspeca zanim wyśle się zmiany do Githuba. Całość moich poprawek zamknęła się w jednym commitcie (usunięcie require i Dir.glob).

Innym ciekawym rozwiązniem na które trafiłem przy tym problemie jest Jeweler. Jest to takie cudeńko, które po krótkiej konfiguracji da nam do dyspozycji kilka pożytecznych zadań rake. Jewelera można również używać jako generatora nowych projektów, który posiada całkiem fajne opcje (tworzenie repo, rodzaj pisanych testów, wybór sposobu hostowania gema).

Trzy dni temu otrzymałem od a devver.net klucz do mojego konta beta, a dziś już dostałem informację, że serwis jest dostępny jako publiczna beta i każdy może założyć konto. Czyżby mało osób było zainteresowanych usługami devver.net?

devver.net jest serwisem, który pozwala uruchamiać testy aplikacji napisanych w Ruby na swoich własnych serwerach. Dzięki temu testy wykonują się szybciej. Jak bardzo szybciej? Mi osobiście ciężko powiedzieć bo jeszcze nie korzystałem (nie posiadam też projektu, który by miał na tyle długie testy). Jednak na stronie http://devver.net/documentation/performance można zobaczyć małe porównanie. Osobiście uważam, że sens używania takiego rozwiązania pojawia się dopiero przy projektach do których testy wykonują się kilka minut. W firmie mamy dwa projekty, których testy wykonują się 9 i 12 minut.
W tej chwili nie ma żadnych informacji o cenie, ale wiadomo, że opłaty na devver.net będą.

Wprowadzenie tego w swoim projekcie również jest proste. Po założeniu konta trzeba zainstalować gema, przypisać do projektu swoj API key, ściągnąć devver.rake i można testować. Jedyną różnicą (poza tym, że testy wykonują się na innej maszynie) jest zadanie rake, które trzeba uruchomić: davver:test lub davver:spec.

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.

Za polską Wikipedią

Vim według oficjalnej interpretacji oznacza vi improved. Jest to najpopularniejszy, najbardziej rozbudowany, wieloplatformowy klon edytora tekstu vi, napisany przez Brama Moolenaara, holenderskiego programistę. Vim należy do grupy wolnego oprogramowania o otwartym kodzie źródłowym. Pierwsza wersja została wydana w 1991 roku.

Chyba każdy zna. W pracy, w domu, w szkole używam NetBeans i jestem zadowolony. Jednak ostatnio zewsząd atakuje mnie vimowa propaganda!

Najpierw Jamis Buck powrócił do Vima. Potem , że prawie wszyscy tam używają Vima właśnie. Przy okazji podali kilka wskazówek jak go używają, wszystkie te palcołamańce itp. Na początku roku Fabio Akita zademonstrował jak ładnie i wygodnie można pisać w Rubym i Railsach korzystając w Vima. Ale już największym vimopropagatorem stał się Zibi w pracy. Zbyszek argumentuje to przedewszystkim ogólnym dostępem do Vima (,,jest wszędzie''), oraz tym, że czasem jak trzeba się zalogować z domu to w konsoli NetBeansa się nie odpali (a to ci odkrycie) i trzeba sobie radzić w innym edytorze. W najliższym wolnym czasie :) też dam szansę Vimowi. W sieci jest sporo zasobów: rails-vim, git-vim i inne ....

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.

Chyba każdy z piszących w Ruby używa czasem irb. Niedawno odkryłem całkiem fajne dopalacze dla tej przyjemnej konsolki. Od dawna używałem Wirble, ale teraz poużywałem trochę Utility belt. Standardowe dopełnianie nazw metod, czy nazw zmiennych to nic szczególnego. Z poziomu Utility-belt można odrazu uruchomić edytor, czy wysłać jakiś kawałek kodu do Pastie. Ten gem szczególnie powinien zainteresować posiadaczy systemu spod znaku jabłuszka bo wiele jego funkcji działa tylko z Mac OS X. Ale co ja będę pisał, najlepiej zobaczyć filmik (lektor po portugalsku - chyba).
Ruby IRB + Utility Belt from Fabio Akita on Vimeo.

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.

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.

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

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?

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.

Dziś chciałem znowu ponarzekać na ActiveRecord. Słówko 'narzekać' jest tu zastosowane na wyrost, więc proszę nie robić ze mnie zaraz wiecznego malkontenta. Problem, który dziś chcę tu opisać zauważyłem już wcześniej, ale potem zapomniałem o nim i nie czułem chęci i potrzeby opisywania go.

Wyobraź sobie drogi czytelniku, że masz takie zadanie: ,,poszukaj wszystkie projekty użytkownika o loginie 'quentin'. Modele wyglądają tak: class Project < ActiveRecord::Base belongs_to :user end class User < ActiveRecord::Base has_many :projects end Można rzucić zapytaniem z JOIN Project.find(:all, :joins => "JOIN users ON users.id = projects.user_id AND users.login LIKE 'quentin'") i znaleźć ... Ale co właściwie znajdzie takie zapytanie? Obiekty klasy Project? Tak. Dla uproszczenia załóżmy, że powyższy Project.find zapakowałem do metody Projects.find_by_sql. Project.find_by_login('quentin').map{ |p| p.id }
=> [1, 1] Jeśli przez głowę przeszła Ci myśli, że to ten sam projekt znaleziony jakimś cudem dwa razy to nic mylnego. To dwa różne projekty wyciągnięte z bazy danych! Podanie :joins => w parametrach metody find tworzy hybrydę kolumn z tabel projects i users. Zapytanie SQL w wynikach zwróci dwa razy kolumnę id, a ActiveRecord zmapuje sobie wartość, którą napotka jako ostatnią czyli id użytkownika. Myśląc logicznie to AR zachowuje się dobrze SQL zwraca połączone talibce, AR je mapuje na swój użytek, robi sieczkę na kolumnach, których nazwy się powtarzają i zwraca jako obiekt szukanej klasy. Ta ostatnia część podoba mi się najmniej. Warto też zwrócić uwagę, że obiekty powstałe w wyniku takiego wyszukiwania mają ustawioną opcje readonly!

Innym rozwiązaniem jest wyszukanie użytkownika o pożądanym loginie i iterowanie po wynikach zwracając należące do niego projekty.

Bardziej jest eleganckie użycie w zapytaniu LEFT JOIN Project.find(:all, :include => :user, :conditions => ["users.login LIKE ?", 'quntin']).map{ |p| p.id } [1, 3] => Konia z rzędem temu, kto po wywołaniu czegoś takiego zerknie w logi railsowe i zaraz będzie wiedział co to zapytanie robi. W takim wywołaniu metoda find rzuca sobie dość długi SQL i zwraca obiekt Project wraz z użytkownikiem. Ale zwrócony obiekt nie jest już zbitką atrybutów z obu klas ale faktycznie czystym obiektem Project.

Nie mam pretensji o takie zachowanie ActiveRecorda. Nie mam doświadczenia z innymi ORM takimi jak Sequel czy DataMaper jestem ciekaw czy one zachowują się tak samo w takich zapytaniach.

Nie dalej jak dwie godziny temu natrafiłem na problem pisząc dodawanie kontaktów w serwisie opartym o Ruby on Rails. Samo zadanie wydawało mi się raczej proste. HABTM z odwołaniem do samego siebie. Napisałem. class User < ActiveRecord::Base has_and_belongs_to_many :contacts, :class_name => "User", :join_table => "contacts_users", :association_foreign_key => :contact_id, :foreign_key => :user_id, :uniq => true end
Nie działa. Poszukałem w ,,Rails recipes'' Chada Fowlera, tak samo. Przepisałem na wszelki wypadek. Nie działa. Nadszedł czas by popatrzeć głębiej.

W konsoli irb wpisuję User.find(3).contacts << User.find(6) zaglądam w log/developmeng.log i jakież wielkie było moje zdziwienie, gdy zobaczyłem INSERT INTO contacts_users () VALUES ()
Dzięki pomocy Comboya z kanału #rubyonrails.pl trafiłem na zgłoszenie błędu 9774: HABTM inserts empty rows. Problem polegał na tym, że do nazywania kolumn używałem symboli zamiast Stringów. Po zamianie działa bez problemu.

Jednak dało mi to trochę do myślenia. Zgłoszenie nastąpiło ponad 3 miesiące temu. W Railsowym tracu priorytet zgłoszenia został zmieniony z dużego na mały. W ciągu tych 3 miesięcy, pojawiły się trzy wydania linii 1.2.x i pojawiło się wydanie 2.0.2 Railsów. A błąd nadal występuje. Nie próbowałem nigdy wczytywać się w źródła ActiveRecorda, ale to chyba nie jest jakiś błąd super trudny do usunięcia? Po premierze dwójki dało się przeczytać opionie, że RoR 2.0 to nic wielkiego. Wielu spodziewało się więcej zmian w kwestii domyślnego railsowego ORM. Chyba jednak praca nad ORM jest odłożona gdzieś na boczne tory. Mam nadzieję, że to się zmieni i ticketów będzie mniej.

Dzisiejszy wpis będzie bardziej z kręgów linuksowych. Oglądając Railscasty bardzo spodobała mi się sprawność z jaką Ryan Bates operował edytorem TextMate. Postanowiłem zrobić sobie coś podobnego na Linuksie używając domyślnego edytora tekstu w Gnome Gedita.

Czcionka

Mi najbardziej do gustu przypadła czcionka Monaco. Można ten krój łatwo pobrać z internetu szukając frazy ,,monaco font''. O czcionkach pisał kiedyś już - Czcionki dla programistów: aby kod był czytelniejszy.

Kolory

Kolory jakie są używane w TextMate bardzo mi przypadły do gustu. Biała czcionka na czarnym tle, spokojne kolory wykorzystywane do kolorowania skladni specyficznej dla pliku. Kolory zabrałem z któregoś z gotowych zestawów ustawień dla Gedita. Był to albo gedittextmate, albo gedit-mate. Można właściwie wykorzystać gotowce i nie czytać już dalej.

Wtyczki

Gedita na już całkiem spory wybór wtyczek, warto sobie coś z tego wybrać. Ja opiszę te, które sam używam.

Class browser. Wtyczka umożliwa przeglądanie klas w plikach źródłowych ich metod i pól w bocznym panelu. Przydatne dla programistów

Lista znaczników umożliwa wstawienie gotowego do uzupełnienia szkieletu znacznika. Do wyboru znaczniki używane w XSLT, HTML, XUL jak również LaTeX (o tym dalej). Wtyczka ta dostępna jest standardowo z Geditem

Gemini. Zaznacza pasujące do siebie nawiazy, cuszysłowy, aposrtofy. Czasem tylko uda się wpisać podwójny zamykający nawias, ale poza tym działa fajnie.

Narzędzia zewnętrzne. Pozwala używać zewnętrznym programów. Np. przetrawienie właśnie edytowanego pliku za pomocą pdflatex, pozwala na używanie make. Ogólnie przydatny bywa. Również ta wtyczka jest jakoby w standardzie.

Przeglądarka plików. Wtyczka sprawia, że w bocznym panelu pojawia się drzewko z katalogami i plikami, wśród których można wybrać ten do edycji. Ta wtyczka jest w zestawie, ale jeśli komuś z jakiś względów się nie podoba to można wybrać Eddt. Wtyczka, której używanie według mnie jest konieczne.

Quick Highlightmode. Za pomocą kombinacji klawiszy Ctrl-Shift-H możemy wybrać styl podświetlania składni dla edytowanego pliku. Dla mnie bardzo fajna sprawa. Piszę sobie wpis na bloga ustawiam mu podświetlanie składni na HTML i wszystko wygląda ładnie.

SnapOpen. To jest wtyczka kopijuąca takie małe okienko otwierania pliku, z którego pomocą w szybki sposób mogę wybrać plik do edycji wpisując część jego nazwy. Pliki do edycji szukane są albo w katalogu z którego uruchomiliśme edytor lub w katalogu otwarym w panelu przeglądania plików. Zdecydowania fajna rzecz.

Snippets, czyli wstawki kodu. Coś absolutnie wspaniałego. Rzecz bez której nie wyobrażam sobie pisania jakiegokolwiek kodu. Za pomocą odpowiedniego skrótu lub przycisku Tab można wstawić do edytowanego dokumentu odpowiedni kawałek kodu np. szkielet konstrukcji if. Dużą ilość wstawek pryznoszą z sobą gotowe zestawy ustawień o których pisałem wyżej.

Gedit-LaTeX. To wtyczka przydatna tylko użytkownikom LaTeXa. Jeszcze z jej pomocą nie składałem większego dokumentu, ale wydaje się mieć spore możliwości. Przy najbliższej okazji napewno będę z niej korzysał.

Bardzo przyjemną sprawą może też być Auto completion plugin, dzięki któremu słowa były uzupełnianie za pomocą klawisza Tab. Ja go przestałem używać bo wciskanie tabulatora kolidowało czasem z używanymi wstawkami.

Tak jak chciał Night zrobiłem jakieś video z tego jak wygląda mój Gedit. Video nie jest najlepszej jakości. Można je zobaczyć w serwisievideo.google.com lub Gedit.ogg w formacie Ogg Theora.

Kto zna już Rails? Kto jeszcze nie zna? Dobra, dobra. Pytanie właściwie nie ma znaczenia bo dzisiejszy wpis będzie i dla jednych i dla drugich. Jak wiele lini kodu się powtarza w źródle twoich klas? Jak wiele z nich umieściłeś w osobnej metodzie? Dziś napiszę jak chociaż trochę w prosty sposób uporządkować kontroler. To dalej bo szkoda czasu.

Nazewnictwo

Łatwo sobie wyobrazić jakis serwis z podcastami. Są ludzie dodają sobie swoje podcasty, komentują je, tagują i co tam jeszcze można robić teraz w serwisach internetowych ery 2.0. Ale zaimijmy się bardziej szczegółowo podcastem. Co użytkownik może z nim zrobić: może go dodać, może go potem edytować, by poprawić jakieś literówki, inni mogą przeglądać szczegóły podcasu: jego opis i wszystko inne co ma opisywać podcast. Każdy chce mieć wartością treść w swoim serwisie, więc przyda nam się jakiś moderator by usuwał to co jest złe. Jakieś bluzgi czy bekanie do mikrofonu. Cztery proste czynności tworzenie, usuwanie, przeglądanie, edycja. Na ilę sposóbów mogę nazwać akcję tworzącą nowy podcast? Nawet ograiczając się do angielskiego bardzo łatwo podać kilka słów oznaczających prawie to samo: new, add, create. A jeśli w takim kontrolerze są wszystkie trzy nazywy to która tak napawdę tworzy nowy podcast w serwisie? DHH mówił o tym problemie a ja chcę powtórzyć. Sięgnij po CRUD. Zatem nazywajmy zawsze te podstawowe metody tak samo: create, show, update, destroy.
class PodcastController < ApplicationController def create end def show @podcast = Podcast.find(params[:id]) end def update Podcast.update_attributes(params[:id]) end def destroy Podcast.destroy(params[:id]) end end
Pozwoliłem sobie dodać już częściową implementację tych akcji, brakuje tylko create.

Uporządkujmy

Pół biedy jeśli to wygląda tak jak na załączonym wyżej obrazku. Dużo gorzej jeśli na początku każdej z metod jest:
@podcast = Podcast.find(params[:id])
Przynajmniej trzy razy piszesz to samo! Mój sposób by sobie z tym poradzić to before_filter. Piszę sobie metodę: find_podcast
private def find_podcast @podcast = Podcast.find(params[:id]) end
Spokojnie, spokojnie, nie podpalać się i nie wpisywać tej metody na początku każdej z metod. To też bez sensu. Pamiętajcie o before_filter.
before_filter :find_podcast, :except => :create
To według mnie jest DRY. Eliminacja powtarzającego się kodu, oszczędzanie palców czy jak jeszcze to nazwać. Paradoksalnie na napisanie find_podcast użyłem więcej linii niż zaoszczędziłem, ale według mnie tak jest estetyczniej, czytelniej. Ale DRY to nie tylko pisanie metod podobnych do find_podcast, to również ,,widoki częściowe'' - partiale (o których pisałem już na Jabbie), oraz metody pomocnicze.

Postanowiłem uzupełnić kod kontrolera jeszcze o metodę list, która będzie pokazywała listę wszystkich podcastów. Teraz find_podcast będzie wywoływane przed każdą metodą oprócz create.
class PodcastController < ApplicationController before_filter :find_podcast, :except => :create def create Podcast.create(params[:podcast]) end def show # show record end def update @podcast.update_attributes(params[:id]) redirect_to :action => "show", :id => @podcast end def destroy @podcast.destroy redirect_to :action => "list" end def list @podcasts = Podcast.find(:all) end private def find_podcast @podcast = Podcast.find(params[:id]) end end
Spostrzegawczy lub tacy, którzy już pisali w RoR powiedzą: ,,no dobra, ale teraz każdy może usunąć podcast''. Tak w tym momencie każdy może usunąć podcast. A nawet więcej! Teraz użytkownik może edytować wszystkie podcasty. Wolna amerykanka! A co jeśli nie uda się zapisać podcastu? Ale to jeśli będzie ktoś chciał przeczytać mogę napisać w sobotę.

Literatura

Na sam koniec przydatne artykuły, video czy textareazentacje:

• DHH tłumaczy czym jest REST i CRUD
• textareazentacja opisująca REST

Masz konto na flickr, a nie wiesz jak przesłać tam swoje zdjęćia z f-spot? Nie chcesz do tego używać linuksowej Picasy (która według mnie wcale taka fajna nie jest)? Masz notatki w Tomboy na swoim pececie, ale chcesz mieć je jednocześnie na laptopie? Albo jeszcze lepiej, chcesz je mieć online w swoim ,,plecaczku'' na Backpackit. Albo chcesz zwyczajnie zsynchronizować swoje ~/documents z pamięcią USB, albo z laptopem, czy może znowu wysłać je w sieć na Box.net. Na te wszystkie pytania jest jedna krótka odpowiedź! A brzmi ona: Conduit!

Conduit

Czymże Conduit jest? to program synchronizujący docelowo wszystko ze wszystkim. Brzmi cudownie, ale ciągle brakuje pewnych rzeczy. Dokładnie możemy zobaczyć co da się synchronizować na stronie statusów. Na oficjalnych obrazkach Conduit widziałem jednak synchronizację ustawień Gnome, bardzo ciekawe. Ja już go używam jakiś czas synchronizowałem z jego pomocą sporo zdjęć z wakacji z serwisem Picasaweb, nie było żadnych problemów.

Może Conduit jeszcze nie powala możliwościami synchronizacji, ale za jakiś czas może mieć potężne możliwości. To co jest planowane na kolejną wersję można sprawdzić na liście do zrobienia Conduit. Szczególnie pożądana przeze mnie jest synchronizacja w dwóch kierunkach wpisów z Backpack z moim Tomboyem GTD.

Możliwości i kombinacji jest ... bardzo dużo. Ja mam kilka (większość na przyszłe wersje)

• Zsynchronizować muzykę na Ipodzie, Odtwarzaczu MP3, z playlistą z Rhythmboxa. Może jeszcze jakaś synchronizacja z Jamendo?
• Zsynchronizowanie wpisow z Joggera z jakimś katalogiem, każdy wpis to jeden plik tekstowy
• Wspomniane wyżej ustawienia Gnome z inną maszyną poprzez sieć lokalną
• Synchronizacja dokumentów Openoffice
• Synchronizacja kontaktów w telefonie komórkowym z programem pocztowym lub Gmailem (lub czymś jeszcze innym)

Mało? To jaki Ty masz pomysły?

Wszyscy, którzy interesują się Ruby on Rails pewnie dobrze znają screencasty, których autorem jest Ryan Bates. Ci którzy nie znają, muszą poznać.

Całkiem niedawno zapragnąłem mieć wszystkie odcinki (nie widziałem wszystkich) u siebie na dysku i oglądać je w wolnej chwili. Jednak przechodzenie po koleji ze strony odcinka na stronę kolejnego epizodu to nie jest ciekawe zajęcie. Ale kim byłby programista, który robiłby to ręcznie? Chwilę pomyślałem i już wiedziałem.

Co potrzebowałem: Railscasts RSS, REXML, net/http, Wget jako mały pomocnik do ściągania plików, no i Ruby oczywiście. Całość trochę zamieszałem, wrzuciłem do jednego skryptu i voila! Skrypt ściąga wszystkie wydane epizody w formacie mov (cały Railsowy światek jest raczej makowy), a na dzień dzisiejszy jest ich 69. Da dysku sporo zajmują, ale chyba warto.

# Download all screencasts from railscasts.com require 'rexml/document' require 'net/http' rss_content = Net::HTTP.get(URI.parse("http://feeds.feedburner.com/railscasts")) railsacasts_rss = REXML::Document.new(rss_content) @railscasts = {} # Prepare titles and URLs railsacasts_rss.elements["rss"].elements["channel"].elements.each("item") do |item| @railscasts["#{item.elements['enclosure'].attributes['url']}"] = item.elements['title'].text end # Download all @railscasts.sort.each do |url, title| puts "Downloading: #{title} ..." system("wget",url) end

Warto też odnotować istnienie serwisu peepcode.com. Udostępnia on również screencasty o tematyce Ruby/Ruby on Rails, ale z tą jedyną różnicą, że są one płatne. Jeden odcinek kosztuje 9$. Jest jednak możliwość obejrzenia ,,free samples''. Ja osobiście nie widziałem żadnego odcinka, więc nie będę się pisał nic więcej na temat tej serii.

Barcamp to poznańskie spotkanie ludzi z branży IT, spotkanie wzorowane jest na wrocławski spotkaniach branżowych GrillIT. Pierwsza edycja poznańskiego Barcampu odbyła się w ostatni weekend, 1 września. Pojechałem tam razem z Bartkiem Rycharskim. Według listy uczestników zamieszczonej na stronie imprezy powinno się zjawić około 130 osób. W rzeczywistości było ich chyba trochę mniej, ale i tak frekwencja mile zaskoczyła organizatorów. Zaplanowanych było sześć prezentacji, odbyło się pięć. Nie będę na to narzekał bo końcówka była trochę nużąca dla mnie, dla Bartka również.

Pierwszą prezentacja mówiła o o serwisie partype.pl. Tematyka serwisu zdecydowanie nie w moich kręgach zainteresowań, ale prezentacja było ok. Nic ponad to. Twórcy mają problem z wypełnieniem serwisu treścią i pozyskaniem użytkowników. ktoś chce im pomóc i się zarejestruje?

Za to druga prezentacja była dla mnie bombowa. Pokazywała serwis dla podróżników. Niby takie nic prawda? Serwis jak wiele innych już w internecie. Ale ten naprawdę mi się spodobał. Bartek Raciborski ma fajny pomysł na realizację tego i w jaki sposób czerpać pieniądze z takiego serwisu. Serwis ma niecodzienną domenę: travels.to, ale Bartek Raciborski bardzo dobrze potrafił obronić zasadność takiej domeny. Po pierwsze domeny takie jak: last.fm czy del.icio.us przyjęły się bardzo dobrze. Po drugie adresy w stylu bartek.travels.to (prowadzący do strony z podróżami Bartka), albo travles.to/china (opisująca podróże do Chin) wydają się być fajnym pomysłem. Twórcy tego serwisu podróżniczego nie mają problemów z wypełnieniem serwisu początkową treścią, czy pozyskiwaniem użytkowników. Jeśli ktoś się zainteresował tym to polecam zajrzeć na bloga Travels.to.

Trzecie wystąpienie to prezentacja LinkLift (strona teraz chyba w przebudowie bo wyglądała ładniej) serwisu pośredniczącego w sprzedaży lików tekstowych. Michał Lisicki i Aleksandra Dobrakowska mówili o znaczeniu linków tekstowych i o serwisie LinkLift. Firma zainteresowała mnie już wcześniej, kto wie czy nie umieszczę jakis linków od nich u siebie na blogu. A myślę, że wielu użytkowników Joggera z tego skorzysta. Zdradzę tyko, że obok słowa ,,współpraca'' Aleksandra wymieniła słowo ,,jogger''.

Potem była przerwa podczas której wszyscy oblegali bar i kupowali napoje różne, różniste. Porozmawiałem chwilę z chłopakami z Hostingrails.pl. Była mała dyskusja, później również o tym rozmawiałem z Wiktorem Schmidtem, o programistach RoR. Wniosek był jeden: programistów brakuje bo nie ma zainteresowania tą technologią firm (zainteresowanie jednak jakieś jest), ale firmy nie wykonują w Railsach projektów bo nie ma programistów. Takie błędne koło. Wymieniłem też kilka zdań na temat Joggera.

Druga część była dla mnie mniej interesująca i opiszę ją bardziej szczątkowo. Wiktor Schmidt mówił o technice ,,długiego ogona'' w AdSense. Temat ciekawy dla ludzi od marketingu, reklamy w internecie. Ja słuchałem, dowiedziałem się kilku nowych rzeczy i to wszystko. Potem Jan Mazurczak, redaktor naczelny portalu Tutej.pl mówił o tworzeniu portalu lokalnego w internecie. Jeśli ktoś interesuje się mediami i dziennikarstwem w internecie to prezentacja ta by go pewnie zainteresowała.

Podsumowując: ,,kupa wiary'', nowe znajomości, dwie dla mnie ciekawe prezentacje, udana impreza.
W sieci można już przeczytać relację z Barcamp i obejrzeć wywiady.
Dziwne by było, gdyby Tutej.pl nie napisało o poznańskim Barcampie.
Na sam koniec już. Na stronie pewnie pojawi się jakieś wideo, jakieś zdjęcia, materiały z prezentacji. Warto zajrzeć.