Hackathon dla 2500 osób: relacja teamu DataArt

Hackathon dla 2500 osób: relacja teamu DataArt
Pod koniec listopada w Warszawie odbył się HackYeah, hackathon uważany za największą tego typu imprezę na świecie odbywającą się w jednym miejscu. Czterech naszych kolegów reprezentujących oba polskie centra rozwoju oprogramowania podzieliło się z nami wrażeniami na temat udziału w wydarzeniu.

ALEXANDER ZAMKOVY, SENIOR JAVA DEVELOPER, WROCŁAW, (BACKEND, DATA ARCHITECTURE, DESIGN):

Decyzja o udziale była spontaniczna – Segey Golubov zobaczył ogłoszenie i zaproponował nam udział w hackathonie. Na początku nasz wrocławski team miał liczyć 4 osoby, ale jeden z kolegów ostatecznie nie mógł z nami pojechać. Do naszej trójki – mnie, Sergeya Golubova i Alexeya Eraskina dołączył Taras Tomishch z Lublina. Udało mu się wykonać swoje zadanie i znalazł czas, by pomóc nam! Byłem zaskoczony skalą hackathonu – ogromna liczba uczestników, interesujący format kodowanie, strefa mentorów, strefa prezentacji i dużo zabawy. Wieczorem pojawił się nawet DJ.

Pomysły przedyskutowaliśmy kilka dni przed wyjazdem – było ich wiele – aplikacja do optymalizacji warunków pożyczki, domowy asystent kuchenny… Wybraliśmy taki, który nie tylko jest ciekawy, ale ma również znaczenie społeczne: asystent nadzorujący przyjmowanie leków z umiejętnością analizy zgodności wyrobów medycznych, który jest w stanie proponować tańsze odpowiedniki. Pracowaliśmy na bazie otwartego katalogu leków i statystyk dotyczących ich sprzedaży. Okazało się, że najtrudniej zidentyfikować najważniejsze cechy produktu – dużo o tym myśleliśmy, ale musieliśmy zdążyć na czas, a on nas mocno ograniczał.

Teraz, z własnego doświadczenia, mogę podpowiedzieć, że warto stworzyć team z wyprzedzeniem, zwracać uwagę na sposób komunikacji z mentorami i to jak reklamujecie swój produkt. Techniczny aspekt zwycięstwa nie jest tak ważny, istotne, jak pokażecie swój produkt i uargumentujecie swoje wybory. Niektóre drużyny przedstawiły prototypy z zestawem slajdów bez żadnej działającej funkcjonalności i trafiły do finału. U nas funkcjonalności działały, ale nie zdążyliśmy popracować z mentorami.

TARAS TOMISHCH, SENIOR .NET DEVELOPER, LUBLIN (BACKEND, FRONTEND):

Wszystko zaczęło się od tego, że nasza PR Manager przesłała nam propozycję udziału w hackathonie od kolegów z Wrocławia. Do listy kategorii podchodziłem sceptycznie, ale spontanicznie wpadłem na pomysł dla LOTTO – organizatorów loterii. Przedstawiłem swój pomysł kolegom – spodobał im się, a ja nabrałem jeszcze większej ochoty na uczestnictwo. Mam w domu malutkie dziecko, przez co moja żona też miała prawdziwy hackathon – i za to oczywiście bardzo jej dziękuję.

W Warszawie spotkałem chłopaków z Wrocławia, których pomysł też mi się spodobał. Chciałem też być częścią drużyny DataArt, ale mieliśmy pracować z różnymi technologiami i szkoda było mi porzucać plan z loterią. Dlatego wziąłem udział w burzy mózgów z kolegami, przekształciłem arkusz kalkulacyjny w relacyjną bazę danych (dlatego w zespole zostałem Data Scientist) i wróciłem do zajmowania się LOTTO.

Organizatorzy wykonali kawał dobrej roboty, biorąc pod uwagę właściwie symboliczny koszt udziału. Byliśmy pod wrażeniem liczby sponsorów i wartości nagród (rzędu 100 000 Euro).

Jednocześnie poczucie, że rywalizuję z dwoma tysiącami ludzi było dla mnie nieco przytłaczające. Okazało się, że tworząc loterię, sam w pewnym stopniu uczestniczę w loterii. A nie przepadam za tym. Można było rozwinąć wiele pomysłów, ale nie było wiele czasu na przygotowanie. Zmusiłem się więc do tego, by się nie rozpraszać, tylko skoncentrować na jednej rzeczy.

Zadanie polegało na stworzeniu gry hazardowej (w której szczęście, a nie umiejętności, decyduje o wyniku) z użyciem geolokalizacji. Idea mojego rozwiązania była taka: LOTTO ogłasza akcję w określonym przedziale czasowym i kapitał początkowy. Uczestnik kupuje los na loterię za pośrednictwem telefonu. Procent ze sprzedaży każdego losu podwyższa kwotę wygranej. Uczestnicy podzieleni są na klastry z uwzględnieniem rzeczywistego położenia geograficznego. Na przykład – grupa osób, która zgromadzona na Starym Mieście w Lublinie może być takim klastrem. W momencie losowania serwer wybiera klaster, który wygrywa nagrodę. Im większa grupa uczestników, tym większe prawdopodobieństwo wygranej. Drugą podstawową zasadą jest to, że pieniądze z wygranej są dzielone między uczestników – duża grupa więc ma większą szansę wygrać, ale jedna osoba zgarnie wyższą kwotę! W zależności od konfiguracji maksymalnego rozmiaru klastra można wziąć pod uwagę dzielnice miasta (150-200 m) albo konkurencję między miastami (20-30 km).

Rezultatem mojej pracy była prosta strona z trzema podstronami, która ilustruje pomysł – pracowałem nad projektem samodzielnie. Myślę, że w przyszłości dobrym krokiem byłoby zebranie drużyny, która składa się nie tylko z developerów, by opracować pomysł z wyprzedzeniem i przygotować infrastrukturę. Warto także prezentować projekt w taki sposób, by zabłysnąć przed mentorami. Poszedłem spać o drugiej w nocy i to był dobry pomysł. Najważniejsza rzecz, którą zrozumiałem jest taka: jesteśmy w stanie wygrać, albo – co najmniej – dotrzeć do finału.

SERGEY GOLUBOV, SENIOR JAVA DEVELOPER, WROCŁAW (BACKEND, FRONTEND):

Wracając pociągiem z Warszawy zobaczyłem reklamę hackathonu. Zainteresowała mnie, bo wcześniej nie miałem okazji brać udziału w tego typu imprezie. Zaproponowałem kolegom, by do mnie dołączyli – Alexander i Alexey zainteresowali się od razu, niektórzy również rozważali wyjazd, ale ostatecznie z Wrocławia wybrała się tylko nasza trójka. Spotykaliśmy się przed hackathonem kilka razy, by wygenerować pomysły i wybraliśmy najbardziej obiecujące. Rozmawialiśmy o tym przez całą drogę do Warszawy i na miejscu już wiedzieliśmy, co będziemy robić.

Pierwsze godziny poświęciliśmy na modele danych i projektowanie interfejsu. Kolejne 22 – rozwój rozwiązania. Pracowałem nad interfejsem, a chłopaki zajęli się backendem. Sasha był jednocześnie zaangażowany w budowanie aplikacji i prezentację projektu.

Podobał mi się nasz zapał i to, jak walczyliśmy, by wykonać plan. Zaskoczyło mnie, że jesteśmy w stanie nie spać przez 25 godzin i to, jak szybko minęła nam ta doba. Wydawało nam się, że wszystko robimy w zaplanowanym czasie, ale z upływem dnia było go coraz mniej, a zadania zostawione na koniec okazały się trudniejsze niż nam się wydawało. Mieliśmy też problem z wdrożeniem. W rezultacie zintegrowaliśmy aplikację 5 minut przed deadlinem i nagraliśmy demo na telefonie. Niestety nie był to najlepszy sposób prezentacji naszego produktu.

Oczywiście lepiej zebrać drużynę i zawczasu znaleźć pomysł, poświęcając więcej uwagi interfejsowi (jeśli aplikacja ma go posiadać). Bardzo dokładnie opracowaliśmy wszystkie funkcje produktu, staraliśmy się, by wszystko działało prawidłowo. W związku z tym spędziliśmy dużo czasu na ich implementację i nie daliśmy rady zaprezentować bardzo długiej listy innych wymyślonych przez nas funkcji w interfejsie. Byliśmy zaskoczeni, że do finału dostają się drużyny z zestawami statycznych stron. Strony obiecywały wiele, ale tak naprawdę nic za nimi nie stało. Następnym razem planuję jak najwięcej przekazać mentorom, rozmawiać z opiekunami poszczególnych kierunków, sędziami. Mają tylko kilka minut, by ocenić twoją aplikację i jeśli nie zauważą cię w trakcie trwania hackathonu, najprawdopodobniej nie poświęcą ci dodatkowego czasu.

ALEXEY ERASKIN, SENIOR JAVA DEVELOPER, WROCLAW (BACKEND):

Przede wszystkim podobał mi się duch przedsiębiorczości, który towarzyszył nam od pomysłu do implementacji. Ważne, żeby na bieżąco priorytetyzować zadania i decydować co warto robić, a co odpuścić.

Najtrudniejsza była chyba decyzja o wzięciu udziału. W przyszłości pojechałbym jako członek bardziej przygotowanej i pełniejszej drużyny, w której role rozdzielone byłyby z wyprzedzeniem. Uważam, że dobrze byłoby mieć kogoś, kto zajmie się PR-em oraz komunikacją z mentorami i innymi drużynami i specjalistę JS/UI, by zadbał o warstwę wizualną. Powinno się też od razu wiedzieć, gdzie projekt będzie wdrażany i – jeśli to możliwe – mieć szablony.

Ale całość mi się podobała. Było niesamowicie!