Nazywam się Dmitry. A ja chcę opowiedzieć o tym, jak nasz zespół dotarł do finału hackatonu Urban Tech Challenge na torze Big Data. Od razu powiem, że to nie pierwszy hackaton, w którym brałam udział i nie pierwszy, w którym zgarnęłam nagrody. W związku z tym w mojej historii chcę wyrazić kilka ogólnych obserwacji i wniosków dotyczących całej branży hackatonów oraz przedstawić swój punkt widzenia w przeciwieństwie do negatywnych recenzji, które pojawiły się w Internecie bezpośrednio po zakończeniu Urban Tech Challenge (np. przykład ).
Na początek kilka ogólnych obserwacji.
1. Zaskakujące jest to, że sporo osób naiwnie uważa, że hackaton to pewnego rodzaju rywalizacja sportowa, w której wygrywają najlepsi programiści. To jest źle. Nie biorę pod uwagę przypadków, gdy sami organizatorzy hackathonu sami nie wiedzą, czego chcą (też to widziałem). Ale z reguły firma organizująca hackaton realizuje własne cele. Ich lista może być różna: może to być techniczne rozwiązanie niektórych problemów, poszukiwanie nowych pomysłów i ludzi itp. Cele te często determinują format wydarzenia, jego harmonogram, online/offline, sposób formułowania zadań (i czy w ogóle zostaną sformułowane), czy na hackatonie będzie przegląd kodu itp. Z tego punktu widzenia oceniane są zarówno zespoły, jak i to, czego dokonały. Wygrywają te zespoły, które najlepiej trafią w potrzebny firmie punkt, a wiele z nich dociera do tego punktu zupełnie nieświadomie i przez przypadek, myśląc, że tak naprawdę biorą udział w sportowej rywalizacji. Z moich obserwacji wynika, że aby zmotywować uczestników, organizatorzy powinni stworzyć przynajmniej pozory środowiska sportowego i równych warunków, w przeciwnym razie spotkają się z falą negatywności, jak w powyższej recenzji. Ale odkopujemy.
2. Stąd następujący wniosek. Organizatorom zależy na tym, aby uczestnicy przyszli na hackaton z własną twórczością, czasem nawet specjalnie organizują w tym celu etap korespondencyjny online. Pozwala to na stosowanie silniejszych rozwiązań wyjściowych. Pojęcie „własnej pracy” jest bardzo względne; każdy doświadczony programista może zgromadzić tysiące linii kodu ze swoich starych projektów przy pierwszym zatwierdzeniu. Czy będzie to z góry przygotowane opracowanie? Ale w każdym razie obowiązuje zasada, którą wyraziłem w formie słynnego mema:
Aby wygrać, trzeba mieć coś, jakąś przewagę konkurencyjną: podobny projekt, który realizowałeś w przeszłości, wiedzę i doświadczenie w konkretnym temacie lub gotową pracę wykonaną przed rozpoczęciem hackatonu. Tak, to nie jest sportowe. Tak, może to nie być warte włożonego wysiłku (tutaj każdy sam decyduje, czy warto kodować przez 3 tygodnie w nocy za nagrodę w wysokości 100 tys., podzieloną między cały zespół i nawet ryzykując, że jej nie dostanie). Ale często jest to jedyna szansa na awans.
3. Wybór zespołu. Jak zauważyłem na czatach hackathonowych, wielu podchodzi do tego tematu dość niepoważnie (choć jest to najważniejsza decyzja, która zadecyduje o wyniku na hackathonie). W wielu obszarach działalności (zarówno w sporcie, jak i podczas hackatonów) widziałem, że silni ludzie mają tendencję do jednoczenia się z silnymi, słabi ze słabymi, mądrzy z mądrymi, cóż, ogólnie rzecz biorąc, rozumiesz... Tak mniej więcej dzieje się na chatach: słabsi programiści są od razu łapani, ludzie, którzy nie mają żadnych umiejętności przydatnych w hackathonie, siedzą na czacie przez dłuższy czas i wybierają zespół w oparciu o zasadę, że gdyby tylko ktoś się podjął . Na niektórych hackatonach praktykuje się losowe przydzielanie zespołów, a organizatorzy twierdzą, że losowe zespoły radzą sobie nie gorzej od istniejących. Ale z moich obserwacji wynika, że zmotywowani ludzie z reguły sami znajdują zespół, a jeśli trzeba kogoś przypisać, to często wielu z nich nie przychodzi na hackaton.
Jeśli chodzi o skład zespołu, jest on bardzo indywidualny i w dużym stopniu zależny od zadania. Mógłbym powiedzieć, że minimalny realny skład zespołu to projektant – front-end lub front-end – back-end. Ale znam też przypadki, gdy wygrywały zespoły składające się wyłącznie z frontendowców, które dodały prosty backend w node.js, albo stworzyły aplikację mobilną w React Native; lub tylko od backenderów, którzy stworzyli prosty układ. Generalnie wszystko jest bardzo indywidualne i zależy od zadania. Mój plan na wybranie zespołu na hackaton był następujący: planowałem skompletować zespół lub dołączyć do zespołu na wzór frontend - backend - projektant (sam jestem frontendem). Dość szybko zacząłem rozmawiać z backenderem Pythona i projektantem, który przyjął zaproszenie do dołączenia do nas. Nieco później dołączyła do nas dziewczyna, analityk biznesowy, która miała już doświadczenie w wygraniu hackatonu i to zadecydowało o jej dołączeniu do nas. Po krótkim spotkaniu postanowiliśmy nazwać się U4 (URBAN 4, miejska czwórka) przez analogię do fantastycznej czwórki. I nawet umieścili odpowiednie zdjęcie na awatarze naszego kanału telegramu.
4. Wybór zadania. Jak już mówiłem, trzeba mieć przewagę konkurencyjną, na tej podstawie dobierane jest zadanie na hackaton. Na tej podstawie po obejrzeniu i oceniając ich złożoność, zdecydowaliśmy się na dwa zadania: katalog innowacyjnych przedsiębiorstw od DPiIR oraz chatbot od EFKO. Zadanie z DPIiR wybrał backender, zadanie z EFKO wybrałem ja, bo miał doświadczenie w pisaniu chatbotów w node.js i DialogFlow. Zadanie EFKO dotyczyło także ML, mam pewne, niezbyt duże doświadczenie w ML. I biorąc pod uwagę warunki problemu, wydawało mi się, że jest mało prawdopodobne, aby można go było rozwiązać za pomocą narzędzi ML. To uczucie wzmocniło się, gdy poszedłem na spotkanie Urban Tech Challenge, gdzie organizatorzy pokazali mi zbiór danych na temat EFKO, w którym znajdowało się około 100 zdjęć układów produktów (wykonanych pod różnymi kątami) i około 20 klas błędów układu. Jednocześnie zleceniodawcy chcieli osiągnąć skuteczność klasyfikacji na poziomie 90%. W efekcie przygotowałem prezentację rozwiązania bez ML, backender przygotował prezentację na podstawie katalogu i wspólnie po sfinalizowaniu prezentacji wysłaliśmy je do Urban Tech Challenge. Już na tym etapie ujawniono poziom motywacji i wkładu każdego uczestnika. Nasz projektant nie brał udziału w dyskusjach, odpowiadał z opóźnieniem, a nawet w ostatniej chwili uzupełniał informacje o sobie w prezentacji, w ogóle pojawiały się wątpliwości.
W rezultacie przekazaliśmy zadanie z DPiIR i wcale się nie zmartwiliśmy, że nie zdaliśmy EFKO, bo zadanie wydawało nam się, delikatnie mówiąc, dziwne.
5. Przygotowanie do hackatonu. Kiedy w końcu okazało się, że zakwalifikowaliśmy się do hackatonu, zaczęliśmy przygotowywać się do niego. I tutaj nie jestem zwolennikiem rozpoczynania pisania kodu na tydzień przed rozpoczęciem hackatonu. Jako minimum powinieneś mieć gotowy szablon, z którym możesz od razu przystąpić do pracy, bez konieczności konfigurowania narzędzi i bez wpadania na błędy jakiejś biblioteki, którą postanowiłeś wypróbować po raz pierwszy na hackatonie. Znam historię o inżynierach angular, którzy przyjechali na hackaton i spędzili 2 dni na przygotowaniu kompilacji projektu, więc wszystko powinno być przygotowane wcześniej. Zamierzaliśmy podzielić obowiązki w następujący sposób: backender pisze roboty, które przeszukują Internet i umieszczają wszystkie zebrane informacje w bazie danych, natomiast ja piszę API w node.js, które odpytuje tę bazę danych i wysyła dane na przód. W tym celu przygotowałem wcześniej serwer przy użyciu express.js oraz przygotowałem front-end w React. Nie korzystam z CRA, zawsze dostosowuję webpack pod siebie i doskonale wiem, jakie może to stwarzać ryzyko (pamiętajcie historię o programistach angularnych). W tym momencie poprosiłem naszego projektanta o szablony interfejsów lub przynajmniej makiety, aby mieć pojęcie, co będę układał. Teoretycznie powinien także poczynić własne przygotowania i skoordynować je z nami, ale nigdy nie otrzymałem odpowiedzi. W rezultacie pożyczyłem projekt z jednego z moich starych projektów. I zaczęło działać jeszcze szybciej, ponieważ wszystkie style dla tego projektu zostały już napisane. Stąd wniosek: nie zawsze w zespole potrzebny jest projektant))). Z tymi zmianami przybyliśmy na hackaton.
6. Praca na hackatonie. Pierwszy raz zobaczyłem mój zespół na żywo dopiero na otwarciu hackathonu w Centralnym Centrum Dystrybucji. Spotkaliśmy się, omówiliśmy rozwiązanie i etapy pracy nad problemem. I choć po otwarciu musieliśmy jechać autobusem do Czerwonego Października, poszliśmy spać do domu, umawiając się na miejsce o 9.00:XNUMX. Dlaczego? Organizatorom najwyraźniej zależało na wydobyciu z uczestników jak najwięcej, dlatego ułożyli właśnie taki harmonogram. Ale z mojego doświadczenia wynika, że możesz kodować normalnie, nie śpiąc przez jedną noc. Co do tego drugiego, nie jestem już pewien. Hackaton to maraton, trzeba odpowiednio obliczyć i zaplanować swoje siły. Poza tym mieliśmy przygotowania.
Dlatego po przespaniu się o godzinie 9.00 siedzieliśmy na szóstym piętrze Demokracji. Wtedy nasz projektant niespodziewanie oznajmił, że nie ma laptopa i że będzie pracował z domu, a my będziemy komunikować się telefonicznie. To była ostatnia kropla. I tak z czwórki przeszliśmy na trójkę, choć nazwy zespołu nie zmieniliśmy. Znów nie był to dla nas duży cios, projekt miałem już ze starego projektu. Generalnie na początku wszystko szło całkiem sprawnie i zgodnie z planem. Do bazy danych (zdecydowaliśmy się skorzystać z neo4j) załadowaliśmy zbiór danych innowacyjnych firm od organizatorów. Zacząłem pisać, potem zająłem się node.js i wtedy coś zaczęło szwankować. Nigdy wcześniej nie pracowałem z neo4j i na początku szukałem działającego sterownika dla tej bazy danych, potem wymyśliłem, jak napisać zapytanie, a potem ze zdziwieniem odkryłem, że ta baza danych na zapytanie zwraca jednostki w w postaci tablicy obiektów węzłowych i ich krawędzi. Te. kiedy poprosiłem o organizację i wszystkie dane na jej temat poprzez NIP, zamiast jednego obiektu organizacji, zwrócono mi długą tablicę obiektów zawierających dane na temat tej organizacji i relacji między nimi. Napisałem mapper, który przeszedł przez całą tablicę i skleił wszystkie obiekty zgodnie z ich organizacją w jeden obiekt. Ale w bitwie, gdy zażądano bazy danych 8 tysięcy organizacji, zostało to wykonane niezwykle wolno, około 20–30 sekund. Zacząłem myśleć o optymalizacji... A potem zatrzymaliśmy się w czasie i przeszliśmy na MongoDB, co zajęło nam około 30 minut. W sumie na neo4j stracono około 5 godzin.
Pamiętaj, nigdy nie zabieraj na hackaton technologii, której nie znasz, mogą pojawić się niespodzianki. Ale ogólnie poza tą porażką wszystko poszło zgodnie z planem. I już rankiem 9 grudnia mieliśmy w pełni działającą aplikację. Przez resztę dnia planowaliśmy dodać do niego dodatkowe funkcje. W przyszłości wszystko szło mi stosunkowo gładko, ale backender miał całą masę problemów z blokowaniem swoich robotów w wyszukiwarkach, w spamie agregatorów osób prawnych, który przy żądaniu pojawiał się na pierwszych miejscach wyników wyszukiwania dla każdej konkretnej firmy. Ale lepiej, żeby sam o tym opowiedział. Pierwszą dodatkową funkcją, którą dodałem, było wyszukiwanie według pełnego imienia i nazwiska. Dyrektor generalny VKontakte. Zajęło to kilka godzin.
Tak więc na stronie firmy w naszej aplikacji pojawił się awatar dyrektora generalnego, link do jego strony VKontakte i kilka innych danych. To była miła wisienka na torcie, choć być może nie zapewniła nam zwycięstwa. Następnie chciałem przeprowadzić analizę. Jednak po długich poszukiwaniach opcji (w interfejsie użytkownika było wiele niuansów) zdecydowałem się na najprostszą agregację organizacji według kodu działalności gospodarczej. Już wieczorem, w ostatnich godzinach, układałem szablon do wyświetlania innowacyjnych produktów (w naszej aplikacji ma znajdować się sekcja Produkty i Usługi), choć backend nie był na to gotowy. W tym samym czasie baza danych rosła skokowo, roboty kontynuowały pracę, backender eksperymentował z NLP, aby odróżnić teksty innowacyjne od nieinnowacyjnych))). Ale czas końcowej prezentacji już się zbliżał.
7. Prezentacja. Z własnego doświadczenia mogę powiedzieć, że do przygotowania prezentacji należy przejść na około 3-4 godziny przed jej terminem. Zwłaszcza jeśli dotyczy to materiału wideo, jego nagrywanie i montaż zajmuje sporo czasu. Mieliśmy mieć filmik. I mieliśmy specjalną osobę, która się tym zajmowała, a także rozwiązała szereg innych kwestii organizacyjnych. W związku z tym do ostatniej chwili nie odrywaliśmy się od kodowania.
8. Skok. Nie podobało mi się, że prezentacje i finały odbywały się w osobny dzień powszedni (poniedziałek). Tutaj najprawdopodobniej kontynuowana była polityka organizatorów polegająca na wyciskaniu z uczestników maksimum. Nie planowałem brać wolnego w pracy, chciałem tylko dotrzeć do finału, choć reszta mojej drużyny wzięła dzień wolny. Jednak emocjonalne zanurzenie w hackatonie było już tak duże, że o godzinie 8 rano napisałem na czacie mojego zespołu (zespołu roboczego, a nie zespołu hackatonu), że jadę na własny koszt i udałem się do centrali biuro dla boisk. Nasz problem okazał się mieć wielu analityków zajmujących się czystymi danymi, co znacząco wpłynęło na podejście do rozwiązania problemu. Wielu miało dobrego DS, ale nikt nie miał działającego prototypu, wielu nie mogło obejść zakazów swoich robotów w wyszukiwarkach. Byliśmy jedynym zespołem, który miał działający prototyp. I wiedzieliśmy, jak rozwiązać problem. Ostatecznie wygraliśmy tor, choć mieliśmy dużo szczęścia, że wybraliśmy najmniej konkurencyjne zadanie. Patrząc na wyciągi na innych torach, zdaliśmy sobie sprawę, że tam nie mielibyśmy żadnych szans. Chcę też powiedzieć, że mieliśmy dużo szczęścia do jury, które skrupulatnie sprawdzało kod. I sądząc po recenzjach, nie stało się to we wszystkich utworach.
9. Finał. Po kilkukrotnym wezwaniu do jury na recenzję kodu, myśląc, że w końcu udało nam się rozwiązać wszystkie problemy, poszliśmy na lunch do Burger Kinga. Tam organizatorzy znowu do nas zadzwonili, trzeba było szybko spakować zamówienia i wracać.
Organizator pokazał nam, do którego pomieszczenia mamy się udać, a po wejściu znaleźliśmy się na szkoleniu z wystąpień publicznych dla zwycięskich drużyn. Chłopaki, którzy mieli wystąpić na scenie, byli nieźle naładowani, wszyscy wyszli jak prawdziwi showmani.
I trzeba przyznać, że w finale na tle najsilniejszych drużyn z innych torów wypadliśmy blado, a zwycięstwo w rządowej nominacji klienta w pełni zasłużenie przypadło zespołowi ze ścieżki real estate tech. Myślę, że kluczowymi czynnikami, które przyczyniły się do naszego zwycięstwa na torze były: dostępność gotowego blanku, dzięki któremu mogliśmy szybko wykonać prototyp, obecność „najważniejszych elementów” w prototypie (wyszukiwanie dyrektorów generalnych na portalach społecznościowych) oraz umiejętności NLP naszego backendera, co również bardzo zainteresowało jury.
I na zakończenie tradycyjnie dziękujemy wszystkim, którzy nas wspierali, jury naszego utworu, Evgeniyowi Evgrafievowi (autorowi problemu, który rozwiązaliśmy na hackatonie) i oczywiście organizatorom hackatonu. To był chyba największy i najfajniejszy hackaton, w jakim kiedykolwiek brałem udział. Mogę tylko życzyć chłopakom utrzymania tak wysokiego poziomu w przyszłości!
Źródło: www.habr.com