Nie spodziewałem się by z najbliższym czasie pojawił się serwis, który potrafiłby przyciągnąć moją uwagę. Ale jak powszechnie wiadomo w życiu należy spodziewać się niespodziewanego. Netguru zaserwowała mi Flakera. Nie fuckera, a zwyczajnie flakera. Nie jestem high skill in english ale ta nazwa ma chyba coś wspólnego z rzecznikiem prasowym. W gruncie rzeczy jest to taki rzecznik, bo rozpowiada wkoło co zrobiliśmy w sieci. Wyślesz coś na Blipa, Joggera - informacja o tym pojawi się na Flakerze.

Star mają imponujący. Flaker zaistniał już na ,,głównej wykopu'', a w tej chwili strona flaker.pl dość wolno odpowiada. Można to porównać z godzinami szczytu w naszej klasie ;-)

Co dalej? Pewnie publiczne API pozwalające na przedstawieniu swoich aktywności na swoim blogu lub stronie.

Na koniec gratuluję Netguru pomysłu.

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.

Kończę ostatni semestr informatyki właśnie teraz. Wiąże się z tym napisanie pracy dyplomowej. Temat mojej pracy brzmi ,,Internetowy system egzaminacyjny''. Pisać do ,,ma pałę'' i modlić się by źródłom aplikacji trzymanym lokalnie na dysku twardym nic się nie stało to trochę niemądre. We wrześniu udało mi się dorwać darmowy testowy okres hostingu z megiteam.pl. Okres testowy trwa 6 (słownie: sześć) miesięcy, więc jest całkiem przyjemnie. To miejsce hostingowe postanowiłem przeznaczyć na trzymanie tam repozytorium SVN kodu aplikacji i źródeł tex mojej pracy. Na serwerze dostępny Ruby, więc idealne miejsce dla takiego zastosowania.

W czwartek wieczorem wydałem polecenie: svn import . -m "Initial import" i szkielet aplikacji, zaczątek (2 strony) pracy pisanej w LaTeXu, oraz jakiś projekt UML wylądowały w repozytorium. Teraz tylko trzeba brać się do pisania.

To teraz w czego użyję:

• Rails 2.0.2 (lub nowsze), pisanie w duchu REST
• LaTeXa do pisania pracy
• bazy danych nie wybrałem jeszcze, do tej pory używałem MySQL, ale może warto spróbować Postgresa
• pisanie aplikacji wspomagać będzie NetBeans 6.0