Firma Compendium Centrum Edukacyjne zaprasza miłośników języka Ruby do wzięcia udziału w konkursie na aplikację webową w Ruby on Rails. Do wygrania jest tablet CTAB (specyfikacja). Ponieważ lubimy takie inicatywy, Rubysfera została patronem konkursu.

Aplikację należy stworzyć korzystając z zasobów thedatahub.org, a następnie opublikować ją na githubie. Prace konkursowe będą oceniane według następujących kryteriów (w skali od 1 do 5):

• opcje i funkcjonalność
• użyteczność aplikacji
• szybkość działania
• wizualizacje
• zakres danych z thedatahub.org wykorzystywanych przez aplikację
• innowacyjność
• udogodnienia dla niepełnosprawnych

Zwycięzca otrzyma tablet CTAB, urządzenie specjalnie wyprodukowane dla Compendium CE.

Zgłoszenia

Aplikacje biorące udział w konkursie należy zgłosić za pomocą pobranego formularza do 11 maja (termin został przesunięty na 25 maja) na adres mark@compendium.pl.

Aplikacja webowa powinna spełniać następujące wymagania:

• pracować bezawaryjnie na urządzeniach mobilnych
• korzystać z jednego lub więcej źródła danych z thedatahub.org (o wielkości co najmniej 1000 wpisów). Istnieje również możliwość skorzystania z własnego źródła danych, ale wcześniej należy je zgłosić do thedatahub.org.
• być opublikowana za zasadach jednej z licencji open software (GPL, MIT/X11, BSD etc.)

Pełny regulamin i skład Jury dostępny jest na stronie konkursu.

Co prawda pogoda na razie nie zachęca, ale podobno pod koniec tygodnia ma być oziębienie. Mashupowa aplikacja może być ciekawym zajęciem na długi weekend, a interesująca nagroda przypadnie do gustu fanom Andorida, zatem do dzieła!

Zwycięzcy gratuluję (skontaktujemy się z nim mailowo), a wszystkim uczestnikom dziękuję gorąco za udział. Dla niezdecydowanych informacja: kilka biletów jest jeszcze dostępnych.

Nie można ostatnio narzekać na rubiowe konferencje w Polsce. Po jesiennym RuPy (przy okazji: dostępne są już nagrania), już za miesiąc 10 i 11 marca zapowiada się świetna konferencja we Wrocławiu o wdzięcznej nazwie wroc_love.rb. Przygotowaliśmy dziś konkurs, w którym można wygrać bilet na konferencję, więcej szczegółów na końcu artykułu.

Czego się można spodziewać?

Dużo merytorycznej dyskusji, o którą dba Andrzej Krzywda, jeden z organizatorów konferencji. Na pewno warto będzie posłuchać Avdi Grimma – między innymi autora Exceptional Ruby. Przejrzyjcie jego blog, tematy które porusza stoją na wysokim poziomie.

Będzie też między innymi Nick Suterrer, którego prezentacje zawsze polecam – Nick jest świetnym mówcą i ma o czym opowiadać, uważajcie tylko z nim na afterparty, jeśli macie ambitne plany na dzień następny. Oprócz nich można się spodziewać gorących europejskich nazwisk takich jak: Steve Klabnik (RubyHero ’11), czy Jim Gay – core team member Radiant CMS.

Z polskich nazwisk będzie można usłyszeć między innymi Piotrka „Drogusa” Sarnackiego, „naszego człowieka” w Railsach, Piotra Szotkowskiego, który występował między innymi na RubyConf za oceanem, ScotlandOnRails, czy RubyAndRails, a także Michała Taszyckiego, który poprowadził ostatnio CodeRetreat w Warszawie.

Bilety

Pierwsza tura biletów rozeszła się w ciągu jednego dnia, dziś o 18 startuje druga i ostatnia tura. Bilety ostatnio były dostępne w cenie 239 złotych. Prawdopodobnie teraz będą droższe, ale i tak cena nie powinna odstraszać. Jak na dwudniową konferencję z niezłymi nazwiskami szkoda nie kupić, bo zapowiada się świetny weekend we Wrocławiu. My już bilety kupiliśmy, do zobaczenia na miejscu.

Konkurs

Do wygrania jest jeden bilet, ufundowany przez organizatorów. Zasady są proste: Napisz na twiterze lub w inny sposób daj znać światu o wroc_love.rb i w komentarzu pod tym artykułem umieść link do tweeta, lub informacji, którą zamieściłeś. Spośród wszystkich zgłoszeń, zostanie rozlosowany jeden darmowy bilet. Konkurs trwa do 20 lutego do godziny 12:00. Powodzenia!

Spróbuję trochę opowiedzieć o tym co wydarzyło się 14 stycznia i wczesnego 15 stycznia. Jakbym był speakerem, to musiałbym w tym momencie powiedzieć „it was remarkable event”, ale nie jestem, więc rozwinę myśl w moim natywnym języku.

Organizatorzy

Rejestracja, obsługa, pomoc techniczna – wszyscy w przewidywalnych miejscach i chętni do pomocy, nawet tym trudniejszym do współpracy. Chylę czoła. Sponsorzy również dopisali, ciepłe napoje, catering w porze lunchu i świetne stoisko allegro z xboxem na którym można było się sprawdzić w Mortal Kombat.

Rozłożenie wykładów (chociaż niektóre bardziej przypominały warsztaty) pod względem wymaganej energii i zaangażowania słuchaczy było moim zdaniem dobre. Stosunek teoretycznych prezentacji do praktycznych zajęć z kodem był niemal doskonały. Każdy mógł znaleźć coś dla siebie, niezależnie od tego czy miał ochotę na chwilę inspiracji nowoczesnymi technologiami, czy też posłuchać o optymalnym wykorzystaniu kodu w dwóch miejscach aplikacji jednocześnie.

Najciekawsze prezentacje

Michal Budzynski

„How not to reinvent the wheel” była dobrą zachętą do korzystania z gotowych frameworków i engine’ów, nawet dla zagorzałych zwolenników autorskich rozwiązań. Atrakcyjna forma prezentacji (Prince of Persia w tle) i dynamiczny prowadzący – dwa ważne czynniki udanej prezentacji. Kolejnym mocnym punktem było krótkie omówienie wybranych oraz co ważne, przetestowanych przez prowadzącego, rozwiązań.

Bartek Szopka – CSS 3d Transforms

Bartaz używając do prezentacji impress.js zaskoczył mnie tym jak spójnie i gładko potrafił wpleść w slajdy demonstracje tego o czym mówi. Dowiedzieliśmy się jak można złożyć sześcian z divów, obracać je, sprawiać że są przezroczyste, co to jest według CSS3 perspektywa oraz kilka innych, a wszystko to w obrębie slajdów, co robiło jeszcze większe wrażenie.

Kamil Trebunia

Niesamowicie pomysłowa formuła prowadzenia warsztatu, dzięki któremu każdy mógł na żywo śledzić postępy (ale nie w mozolnym tępie pisania) powstawania prostej gry, dzięki zastosowaniu innowacyjnego podejścia revertowania do odpowiednich commitów.

Aleksander Dąbrowski

Obrazkowe slajdy, subtelne poczucie humoru i emfaza na najważniejsze elementy tego o czym mówił Aleks sprawiły, że w mojej głowie zostało kilka ważnych koncepcji o których warto pamiętać. Bezpieczeństwo jest ważne. Daj serwerowi to co należy do serwera, klientowi co jest klienta. Nie duplikuj kodu. Nie duplikuj kodu.

Patrick H. Lauke

Patrick błysnął demonstracjami i lekkością przedstawiania tego o czym mówi. Rozpoczął od video w html5, jak można nim manipulować przy pomocy javascriptu i kompatybilności z przeglądarkami. Mnie bardzo zainteresował wywód o kodekach i kierunku w którym zmierza standaryzacja wideo w sieci. Niesamowite dema z dostępem do kamerki przy pomocy JS i przekształcanie obrazów przy pomocy canvas zrobiły na mnie i z tego co widziałem na pozostałych uczestnikach duże wrażenie. Patrick bardzo optymistycznie nastawił na przyszłość i zamknął część wykładową konferencji.

Wszystkie prezentacje są dostępne w tym miejscu, a nagrania mają być wkrótce.

Afterparty

Wieczorem spotkaliśmy się w mniejszym już gronie w klubie Alcatraz gdzie integrowaliśmy się w najlepsze do późnych godzin nocnych, a co twardsi wczesnych rannych. Sponsorowanych napojów było tyle, że nawet najwytrawniejsi smakosze byli zaspokojeni, a towarzystwo dopisało wyśmienicie, wymyślając coraz to bardziej japońskie toasty, od Takanai poczynając.

Uwagi:

Kilka uwag ode mnie, żeby przyszłe edycje meetjs (i nie tylko) były jeszcze lepsze.

• System wifi, jak da się, omijać szerokim łukiem autoryzację w formule „1 urządzenie = 1 użytkownik”. Po pierwsze ten system zawiódł (mnie), po drugie, jakbym chciał mieć dodatkowo na telefonie dostęp do sieci, to zablokowałbym sobie go na komputerze, jakby mi się udało go jakoś wcześniej uzyskać.
• Automaty z ciepłymi napojami nie powinny znikać wszystkie naraz, a przynajmniej nie bez ostrzeżenia.
• Wymagajcie od speakerów przedstawienia prezentacji i skróconej formy tego co powiedzą przed prezentacją, żeby nie było sytuacji w której ktoś mówi coś innego niż zapowiedział, że powie. Albo co gorsza, dzień wcześniej zmieni zdanie i wykład będzie nieadekwatny do prezentacji.
• W przypadku dwóch tracków, na przeciwległych trackach proponujcie tematy, które na podstawie prawdopodobieństwa nie będą oba interesowały jednej osoby (Accessibility vs Warsztat z backbone.js)
• W przypadku dwóch tracków, wymagajcie od speakerów ustalania tytułów adekwatnych do tematyki, żebym zawsze wiedział na co ide, albo żebym wiedział dlaczego nie idę.
• W przypadku dwóch tracków, 5 minutek więcej na zmianę sali.
• Nie róbcie dwóch tracków. Mniej prezentacji maksymalnie dobrej jakości obejrzanych w całości to lepszy pomysł niż ich większa ilość i plucie sobie w brodę, że się źle strzeliło do której sali wejść. O sytuacji gdy chciałoby się być w dwóch miejscach naraz nie wspomnę, bo to na prawdę rozdziera serce i przyspiesza procesy starzenia.

Pozdrawiam,

@pavelloz

Pałac Potomkina

Miałem jesienią przyjemność uczestniczyć w konferencji Rubyshift, która odbyła się w Dniepropietrowsku na Ukrainie. Parę osób mnie prosiło o relację, oto ona:

Miejsce

Dniepropietrowsk to miasto (koło miliona mieszkańców) położone nad brzegami Dniepru, we wschodniej części Ukrainy. W czasie zimnej wojny znajdowała się tam największa fabryka rakiet (w tym balistycznych) w ZSSR, z tego powodu miasto to było przez kilkadziesiąt lat zamknięte dla cudzoziemców. Dziś przypomina trochę taką biedniejszą wersję Łodzi, widać, że najlepsze lata ma już za sobą. W centrum znajduje się Pałac Studentów – chyba najciekawsze miejsce w całym mieście, w którym odbyła się konferencja. Główna sala bardziej przypominała teatr i było to niesamowiecie klimatyczne miejsce, co objawiło się tym, że obok Rubistów przewinęło się kilkanaście par młodych, które miały tam sesje ślubne.

Takie panny młode pojawiały się na miejscu imprezy.

Konferencja

Keynote o tytule „Open Source life” poprowadził Sven Fuchs, który na swoim przykładzie opowiedział ile korzyści może przynieść udzielanie się w ruchu otwartego oprogramowania. Przyznam, że było to bardzo inspirujące i zachęcające do działania. Josh Kaldermis opowiadał o Travis CI, po EuRuKo i RuPy, był to trzeci raz, kiedy natknąłem się na tę prezentację. Jednym zdaniem: jeśli macie publiczne projekty z testami i nie korzystacie z Travisa, to robicie coś źle. Konfiguracja jest banalna i darmowa, a CI reagujące na każdy push działa świetnie i pozwala testować Twój projekt z różnymi wersjami Rubiego.

Z ciekawszych prezentacji warto wspomnieć również o Nicku Sutterze, który pokazał swój sposób na prawdziwe MVC w Railsach za pomocą frameworku Apotomo. Pablo Dejuan, który przyleciał z Urugwaju, zwrócił uwagę na to by, przemyśleć podejście do testowania i skupić się na sprawdzaniu tylko najważniejszych funkcji zamiast poświęcania czasu na drobiazgowym maglowaniu trywialnych i mało potrzebnych rzeczy.

Na uwagę zasługuje prezentacja Jona Leightona, który w świetny sposób opowiedział o swojej przygodzie z refaktyzacją Active Recordu. I treśc i wykonaniuebyło brawurowe, więc jeśli będziecie mieli chwilkę, warto je obejrzeć.

Alka seltzer dla każdego

Organizacja i atmosfera były świetne. Co prawda kilka raz były problemy z mikrofonem, a wifi potrafiło przycinać, ale za to drugiego dnia rano obok przekąsek dostępny był Alka Seltzer. I słusznie. Część wystąpień można już obejrzeć pod tym adresem. Nagranie z mojej prezentacji jest jeszcze niedostępne, ale sądząc po pozytywnym feedbacku wyszło całkiem nieźle.

Ludzie

Największe wrażenie zrobili na mnie ludzie; bardzo otwarci, życzliwi i ciekawi. To dzięki nim mogłem zwiedzić zamknięte w poniedziałek muzeum kosmiczne. Doktorant z miejscowego uniwesytetu wprowadził mnie na miejsce i powiedział kustoszowi, że jestem gościem z polskiej uczelni, mieliśmy więc wszystkie rakiety tylko dla siebie. Oprócz tego miałem okazję zwiedzić ukraiński akademik (temat na osobną notkę niezwiązaną z tematyką tego bloga) i wylądować w jednym z Dniepropietrowskich klubów, gdzie głównym drinkiem była wódka w szklankach. Wszystko to razem ze świetną atmosfera na konferencji sprawiło, że jeśli będzie kolejna edycja Rubyshift, to z radością się na nią wybiorę.

Sobotni Global Day of Coderetreat w Warszawie udał się świetnie. Była to część światowego wydarzenia, w którym brało udział 2200 programistów w 90 miastach. Zasady coderetrat opisaliśmy w poprzednim poście. Teraz czas na podsumowanie i uwagi, ponieważ pierwszy raz brałem udział w tym specyficznym szkoleniu.

Sesje

Po wprowadzeniu w temat przystąpiliśmy do 45 minutowych sesji, których było razem 6. W każdej z niej próbowaliśmy napisać grę w życie, za każdym razem zaczynając od nowa z inną osobą i innymi wytycznymi (ograniczeniami), wszystko oczywiście w duchu test driven development. Często też zmienialiśmy edytory, języki oraz środowiska, by poszerzeszyć swoje horyzonty.

Pierwsza sesja polegała po prostu na oswojeniu się z tematem i udowodeniu uczestnikom, że nie da się zrealizować tego zadania w 45 minut. Przez pomyłkę sesja ta zakończyła się raptem po 25 minutach, ale pokazało to nam tylko, jak mało czasu jest na iterację i przyzywczaiło do usuwania kodu na końcu.

W następnych sesjach skupiliśmy się na prostym projekcie, dobrym nazywaniu zmiennych i próbie napisania gry, bez używania pętli lub rozgałęzień (czyli funkcji w stylu if oraz switch) – okazało się, że jest na to sposób. Było to wyzwaniem i pozwoliło na spojrzenie na implementację z innej perspektywy.

Najciekawsza okazała się czwarta sesja o nazwie „evil coder”. Polegała ona na tym, że jedna osoba pisała tylko testy, a druga kod, ale w najbardziej złośliwy i leniwy sposób. Na przykład jeśli test sprawdzał, czy jakaś funkcja zwraca wartość 2, to wystarczyło napisać metodę, która wypisuje 2. Dodatkowo w czasie tej sesji, nie można było rozmawiać, więc była to świetna nauka jak napisać nazwę testu i jego treść, tak by druga osoba była w stanie zrozumieć nasze intencje. Złośliwy programista z kolei pokazywał, jak pisać jednoznaczne testy, które rzeczywiście sprawdzają wszystkie przypadki.

Dwie ostatnie sesje polegały na obiektowym potraktowaniu odległości i koncepcji sąsiednich komórek, oraz na zastasowaniu zasady tell, don’t ask. Więcej czasu niż na implementacji spędziliśmy na rozważaniu nad koncepcją i strukturą kodu. Dodatkowo zmęczenie dało o sobie znać i z mojego punktu widzenia były to najmniej owocne iteracje.

Na koniec zrobiliśmy wspólne podsumowanie, wymieniając czego się nauczyliśmy i co wprowadzimy w poniedziałek w życie, po czym udaliśmy się na zasłużone piwo.

Uwagi

Mimo kilku problemów organizacyjnych (w ostatniej chwili wycofał nam się sponsor) udało nam się zorganizować fajne wydarzenie. Wielkie brawa należą się Michałowi Taszyckiemu za brawurowe poprowadzenie szkolenia, przekazał nam naprawdę dużo cennych wskazówek. Chciałbym również podziękować Pawłowi, Maćkowi i Darkowi, z którymi miałem przyjemność zrealizować coderetreat w Warszawie.

Z kilkudniowej perspektywy muszę przyznać, że programuję nieco lepiej, niż tydzień temu i zwracam uwagę na kilka nowych aspektów testowania. Warto było spędzić całą sobotę w świetnej atmosferze z ciekawymi ludźmi, tworząc doskonały kod. Myślimy o kolejnej edycji na wiosnę!

Więcej zdjęć z imprezy jest dostępna w albumie Dariusza Gorzęby.

Masz dość gonienia terminów i chciałbyś kiedyś po prostu napisać kawałek dobrego kodu, programując w parach i zgodnie z TDD? CodeRetreat to coś dla Ciebie!

CodeRetreat to całodniowe darmowe ćwiczenie, w czasie którego będziesz programował zgodnie z dobrymi praktykami; liczy się dążenie do perfekcji, a nie wynik. Całe ćwiczenie podzielone jest na 45 minutowe sesje, w czasie których w możliwie najlepszy sposób będziesz implementował grę w życie. Każdą sesję krótko podsumujemy, po czym usunisz kod, zmienisz parę i podejdziesz do problemu od innej strony.

Więcej szczegółów dostępnych jest na stronie wydarzenia.

Oprócz świetnej zabawy będziesz doskonalić swoje umiejętności. Skupiamy się na powrocie do podstaw programowania obiektowego. Baw się kodem!

Co oferujemy w sobotę:

• Mnóstwo hackowania
• Pisanie czystego kodu
• Design – programowanie obiektowe
• Test driven development
• Programowanie w parach
• Dobry i darmowy lunch

To wydarzenie jest częścią Global day of code retreat i odbędzie się 3 grudnia w ponad 70 miastach na całym świecie, łącząc ponad 1500 pasjonatów programowania. Będziemy częścią tego wydarzenia w Warszawie.

Zapisz się! (mamy tylko 30 miejsc).

Wydarzenie to jest organizowane przez grupę zapaleńców, przy pomocy firmy innov8on, a Rubysfera objęła patronat medialny.

Znudzeni kolejnym przełomowym CMSem i innowacyjną aplikacją social media w pracy? Świetnie, mam coś dla was. Codebrawl to cykliczny konkurs małych programów napisanych w Rubym. Żadnych Railsów, żadnych rozbudowanych projektów, tylko szybki skrypt do napisania. Co dwa tygodnie publikowane jest małe zadanie, na które odpowiedź należy zamieścić w prywatnym giście. Liczy się kreatywność i elegancja rozwiązania. Na zgłaszanie pomysłów jest pierwszy tydzień, w drugim trwa głosowanie nad najciekawszym rozwiązaniem. Zasady są następujące:

• Pierwsza reguła Codebrawl: Nie rozmawiasz o Codebrawl. Trzymaj swoje rozwiązanie w sekrecie, aż do końca głosowania, to nie jest konkurs popularności.
• Nie używaj swojego imienia w giście, to ujawnia twoją tożsamość.
• Nie forkuj przykładowych gistów
• Wyjaśnij swoje rozwiązanie dokładnie w README (nie zapomnij uwzględnić przykładowego kodu)
• Doszlifuj swoje zgłoszenie, możesz je edytować aż do rozpoczęcia głosowania

Czemu mi się to tak podoba?

Popatrzcie sami na najwyżej oceniane wyniki w zadaniach takich jak: baza klucz wartość – wygrało rozwiązanie oparte o gita, mikroframework testowy, czy też TODO listę obsługiwaną z terminala. Zadania są naprawdę ciekawe, rozwiązania bywają bardzo kreatywne, a co najlepsze, nie musisz zarwać całego popołudnia, żeby coś napisać, czasem wystarcza godzinka, lub dwie.

Dzisiaj na tapecie jest stworzenie metody, która może przyjmować wiele bloków kodu. Do dzieła!

W zeszłym tygodniu miałem przyjemność uczestniczyć w DevMeetings.pl, czyli bezpłatnych spotkaniach dla deweloperów. Jest to warta promowania inicjatywa całodniowych, prowadzonych na bardzo wysokim poziomie szkoleń, które odbywają się w soboty w kilku miastach Polski (Poznań, Kraków, Warszawa). Tematyka kręci się głównie wokół serwerowego javascriptu i technologii z nim związanych. Tym razem szkolenie dotyczyło baz NoSQL czyli „Not only SQL”.

NoSQL

Spotkaliśmy się na 16 piętrze Millenium Plaza w Warszawie (genialny widok) w sobotę rano. Po dwugodzinnym, skondensownym wstępie teoretycznym podzieliliśmy się na kilkuosobowe grupy, by zająć się przewidzianym na resztę dnia kodowaniem. Tym razem celem było wzbogacenie napisanego w node.js na poprzednim DevMeetingu, prostego klona API twittera o nierelacyjną bazę danych. Do wyboru były: MongoDB, Cassandra, Redis oraz CouchDB. Wylądowałem w zespole, który używał tej ostatniej.

Większość czasu zjadła nam migracja ze źródłowej bazy w MySQLu do CouchDB. Początkowo wydawało się, że obsługa MySQL w nodzie jest dramatycznie wolna, przyczyna długiej migracji leżała jednak gdzie indziej i mogę ją streścić w jednym zdaniu: Zawsze zakładaj indeksy na bazie. Plik który otrzymaliśmy ich nie miał, co powodowało problemy z szybkością wyszukiwania danych. Synchroniczność noda dała o sobie tutaj również znać. Kolega z zespołu po zakończeniu migracji zamiast 10 000 rekordów, miał ich w bazie tylko około 6 tysięcy. Gdy uruchomił migrację jeszcze raz otrzymał ich 2 tysiące. Podobnie jak podczas Node Knockout, zapomnieliśmy o asynchroniczności. Po prostu skrypt zdążył pobrać dane z MySQLa i uruchomić wywołania zwrotne (callbacks) zapisujące je do CouchDB, a następnie (gdy callbacki wciąż się wykonywały w osobnych wątkach) natrafiał na instrukcję zakończenia przetwarzania. Ostatecznie rzutem na taśmę udało nam się zaimplementować minimalną liczbę funkcji. Nie wszystkim zespołom to się udało, ale trzeba przyznać, że ci, którzy wybrali Redisa nie mieli z tym większych problemów.

Parę słów o CouchDB

CouchDB posiada RESTowy interfejs dostępu do danych. Jest on prosty, gdy wystarczy nam pobranie prostych danych. Jeśli chcemy jednak wykonać skomplikowane zapytanie, musimy naszą bazę odpowiedni przygotować i utworzyć widok, przy pomocy którego wywołujemy zapytanie. Powoduje to, że dla osób, które mają doświadczenie ze zwykłymi bazami relacyjnymi, dużo prostsze do nauki od CouchDb jest chociażby MongoDB, które pozwala na używanie zapytań, podobnych do tych w SQLu. Wygląda jednak na to, że dobrze opanowane widoki mogą stać się całkiem niezłą bronią w walce o szybkośc odczytu.

Opinia o szkoleniu

Warto było spędzić ponad 10 godzin na praktycznym poznawaniu CouchDB; nic tak nie motywuje do nauki jak zapalona grupa osób wokół Ciebie i konkretny problem do rozwiązania. Mimo, że na sali był spory przekrój programistów od frontendowych Javascriptowców, po ludzi programującyh w Javie i C, to niewiele osób przyznało się do korzystania z baz NoSQL. Jedna osoba wdrożyła Redisa, kilka Mongo, nikt nie bawił się Cassandrą. Nawet prowadzący (świetnie tłumaczący David de Rosier) przyznał się, że nie ze wszystkimi z tych baz pracował. Tak więc nierelacyjne bazy danych kryją przed nami wiele tajemnic i można sporo odkryć, poznając je. DevMeeting i Node Knockout, to świetne okazje by się ich nauczyć. Jeśli będziesz miał okazję przejść się na DevMeeting, nie wahaj się, tylko idź. Nie pożałujesz.

Dwa tygodnie temu wzieliśmy udział w Node.js Knockout – konkursie, który polega na napisaniu aplikacji w 48 godzin przy użyciu node.js. Sama idea konkursu i jego zasady praktycznie są identyczne z tymi podczas Rails Rumble. Zachęcony świetną zabawą podczas ostatniego Rails Rumble (udało nam się napisać grę w 48 godzin), namówiłem kolegów z pracy, byśmy razem usiedli i zrobili coś świetnego. A raczej nie musiałem ich długo namawiać, powiedziałem tylko: serwer side javascript, konkurs, weekend programowania. Przyszli.

Aplikacja

Tak powstał GitBroker – giełda projektów Open Source. Kilka razy dziennie projekty na githubie są wyceniane w zależności od ich popularności (szczegółowy algorytm znamy tylko my); użytkownik na start dostaje 1000 GitCoinów (to nasza waluta) i może je inwestować w rozwijające się repozytoria, zarabiając i wspinając się na górę rankingu.

Oprócz jednego użytkownika, który złamał system (już się z nim skontaktowaliśmy i komisja nadzoru GitCoinów bada sprawę) sporo osób zarobiło już swoje pierwsze GitCoiny. Jeśli chcesz się pobawić w githubowego Gordona Gecko, to zaloguj się i znajdź projekt, który niedługo podbije świat.

Technicznie

Wszystko to zostało napisane w node.js, z wykorzystaniem biblioteki przypominającej Sinatrę – expressa. Pod spodem siedzi MongoDB, a widoki przygotowane są przy pomocy jade (podobne do hamla lub slima). Całość wrzucona jest na Heroku – dobra wiadomość, aplikacje w nodzie hostuje się tam tak samo łatwo jak w Rubym. Nie wykorzystaliśmy prawie asynchroniczności noda, niemniej opanowanie callbacków było sporym wyzwaniem. Kilka razy złapałem się na tym, że kod mi nie działał, bo cały czas próbowałem go pisać synchronicznie. Jedyne miejsce w którym tak na prawdę korzystamy z zalet asynchroniczności, to przeliczanie projektów, w czasie którego odpytujemy githubowe api. Zapytania te wysyłane są w ten sposób, że podczas czekania na odpowiedź, obliczane są wartości już pobranych projektów i przygotowywane są kolejne zapytania.

Maraton

Cóż jest fascynującego w czterech facetach, którzy przez dwie doby programują? Z punktu widzenia pobocznego obserwatora niewiele, z naszego punktu widzenia emocje były. Od początku wyszło nasze słabe przygotowanie i mimo, że każdy coś tam kiedyś bawił się nodem, to pierwsze godziny w sobotę spędziliśmy na naprawdę podstawowych rzeczach. Koło południa przyszło zwątpienie, bo po szybkich szacunkach wyszło nam, że oferowane przez Heroku 5MB na bazę MongoDB w wypadku więcej niż kilkuset użytkowników szybko się skończy. Zastanawialiśmy się już nad realizacją awaryjnego pomysłu, ale okazało się, że w ramach konkursu mamy dostęp do bodajże 1GB na mongohq, co załatwiło sprawę. Przed północą udało nam się stworzyć podwaliny pod serwis, ale do końca było jeszcze daleko.

Zaczęta wcześnie niedziela była pracowita i dopiero koło południa udało się naszemu pomysłowi nadać konkretną formę. Po fali zachwytów „ojej, to naprawdę działa” resztę czasu spędziliśmy na szlifowaniu pomysłu i poprawianiu bugów. Tych ostatnich popełniliśmy sporo, ponieważ było to nasze pierwsze poważniejsze zetknięcie z nodem. Zemściło się na nas też niedbalstwo: mnóstwo rzeczy robione było jako proof of concept i tak na przykład część logiki umieszczona w widoku nie działała jak należy, przez co ostatecznie musieliśmy ją usunąć. Funkcje w modelach zaczeliśmy pisać dopiero koło 19, a wtedy było już za późno, by w pełni je wykorzystać. Przed 23 uznaliśmy, że produkt jest gotowy, nic więcej już nie poprawiamy; wrzuciliśmy go na produkcję i poszliśmy do domu.

Konkurencja

Wystartowało prawie 300 zespołow, z czego 178 nadawało się do głosowania. Uplasowaliśmy się gdzieś w na 30-40 miejscu (nie są one ponumerowane, a nie zależy nam aż tak bardzo by dokładnie liczyć). Z innych pomysłów najbardziej przypadł mi do gustu Metris (massively multiplayer Tetris game) – jak masz dłuższą chwilkę, to zagraj, gdy odkryjesz jak działa, to Cię wciągnie. Z naszych rodzimych zespołów konkurs ukończyło 6. Na szczególną uwagę zasługuję Awesome file downloader, do którego można wkleić link który się chce pobrać, aby otrzymać link, który można pobrać. Serio, nie kumam dowcipu. :/ Warto tu wspomnieć, że w siedzibie Gadu Gadu odbyło się wspólne kodowanie, z którego relację można tutaj przeczytać; szkoda, że chłopakom nie udało się ukończyć więcej projektów.

Wnioski na następny raz

Przyguj się, nie poddawaj się i od początku pisz porządny kod. Callbacki po poznaniu są fajne, tylko, że trzeba używać przy niech zupełnie innych obszarów mózgu niż zazwyczaj. Jak tylko będzie wiadomo coś więcej o nadchodzącym Rails Rumble to się zapisujemy!