Node.js w 48 godzin

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!



Komentarze


O autorze

Aleksander Dąbrowski

Od 2008 zawodowo programuje w Ruby i Railsach. Jest maniakiem prostych i eleganckich rozwiązań, nie boi się usuwania brzydkiego kodu. Uwielbia dzielić się wiedzą, a w wolnych chwilach naprawia samochody.