Jmenuji se Dmitry. A chci mluvit o tom, jak se náš tým dostal do finále hackathonu Urban Tech Challenge na trati Big Data. Hned řeknu, že to není první hackathon, kterého jsem se zúčastnil, a ani první, na kterém jsem získal ceny. V tomto ohledu chci ve svém příběhu vyjádřit několik obecných postřehů a závěrů týkajících se odvětví hackathonu jako celku a předložit svůj názor na rozdíl od negativních recenzí, které se objevily online bezprostředně po skončení Urban Tech Challenge (např. příklad ).
Nejprve tedy několik obecných postřehů.
1. Je překvapivé, že si spousta lidí naivně myslí, že hackathon je nějaká sportovní soutěž, kde vyhrávají nejlepší kodéři. To je špatně. Neberu v úvahu případy, kdy organizátoři hackathonu sami nevědí, co chtějí (také jsem to viděl). Společnost, která hackathon pořádá, si ale zpravidla sleduje své vlastní cíle. Jejich seznam se může lišit: může to být technické řešení některých problémů, hledání nových nápadů a lidí atd. Tyto cíle často určují formát akce, její načasování, online/offline, jak budou formulovány úkoly (a zda vůbec budou formulovány), zda na hackathonu proběhne code review atd. Z tohoto pohledu se hodnotí jak týmy, tak to, co dokázaly. A ty týmy, které nejlépe dosáhnou bodu, který společnost potřebuje, vyhrávají a mnozí se do tohoto bodu dostanou zcela nevědomě a náhodou v domnění, že se skutečně účastní sportovní soutěže. Z mých postřehů vyplývá, že pro motivaci účastníků by měli organizátoři vytvořit alespoň zdání sportovního prostředí a rovných podmínek, jinak se na ně dostane vlna negativity, jako ve výše uvedené recenzi. Ale to jsme odbočili.
2. Z toho plyne následující závěr. Pořadatelé mají zájem, aby účastníci na hackathon přijeli s vlastní tvorbou, někdy pro tento účel dokonce speciálně organizují online korespondenční stage. To umožňuje silnější výstupní řešení. Pojem „vlastní práce“ je velmi relativní, každý zkušený vývojář může ve svém prvním odevzdání nashromáždit tisíce řádků kódu ze svých starých projektů. A bude se jednat o předem připravený vývoj? Ale v každém případě platí pravidlo, které jsem vyjádřil v podobě slavného memu:
Abyste vyhráli, musíte mít něco, nějakou konkurenční výhodu: podobný projekt, který jste dělali v minulosti, znalosti a zkušenosti v konkrétním tématu nebo hotovou práci hotovou před začátkem hackathonu. Ano, není to sportovní. Ano, to nemusí stát za vynaloženou námahu (zde se každý sám rozhodne, zda se mu vyplatí kódovat 3 týdny v noci za cenu 100 tisíc, rozdělenou mezi celý tým, a to i s rizikem, že ji nedostane). Ale často je to jediná šance, jak se dostat dopředu.
3. Výběr týmu. Jak jsem si všiml v hackathonech chatech, mnozí k této otázce přistupují docela lehkovážně (ačkoli je to nejdůležitější rozhodnutí, které určí váš výsledek na hackathonu). V mnoha oblastech činnosti (jak ve sportu, tak v hackathonech) jsem viděl, že silní lidé mají tendenci se spojovat se silnými, slabí se slabými, chytří s chytrými, no, obecně, máte představu... Zhruba to se v chatech děje: méně silní programátoři jsou okamžitě zaskočeni, lidé, kteří nemají žádné dovednosti cenné pro hackathon, visí na chatu dlouho a vybírají si tým na principu, že kdyby to někdo vzal . Na některých hackathonech se cvičí náhodné přidělování týmům a organizátoři tvrdí, že náhodné týmy si nevedou o nic hůř než ty stávající. Motivovaní lidé si ale podle mých pozorování zpravidla najdou tým sami, pokud má být někdo přidělen, tak jich na hackathon často mnoho nepřijde.
Co se týče složení týmu, to je velmi individuální a velmi závislé na úkolu. Mohl bych říci, že minimální životaschopné složení týmu je designér – front-end nebo front-end – back-end. Znám ale i případy, kdy vyhrály týmy složené pouze z front-enderů, kteří přidali jednoduchý back-end v node.js, nebo udělali mobilní aplikaci v React Native; nebo pouze od backenderů, kteří dělali jednoduché rozložení. Obecně je vše velmi individuální a závisí na úkolu. Můj plán pro výběr týmu pro hackathon byl následující: Plánoval jsem sestavit tým nebo se připojit k týmu typu front-end - back-end - designer (sám jsem front-end). A docela rychle jsem začal chatovat s python backenderem a designérem, který přijal pozvání, aby se k nám přidal. O něco později se k nám připojila dívka, obchodní analytička, která již měla zkušenosti s vítězstvím v hackathonu, a to rozhodlo o tom, že se k nám přidá. Po krátké schůzce jsme se rozhodli, že si budeme říkat U4 (URBAN 4, městská čtyřka) analogicky s fantastickou čtyřkou. A dokonce umístili odpovídající obrázek na avatar našeho telegramového kanálu.
4. Výběr úkolu. Jak jsem již řekl, musíte mít konkurenční výhodu, na základě toho se vybírá úkol pro hackathon. Na základě toho, když jsem se podíval a po posouzení jejich složitosti jsme se rozhodli pro dva úkoly: katalog inovativních podniků od DPiIR a chatbot od EFKO. Úkol od DPIiR vybral backender, úkol od EFKO jsem vybral já, protože měl zkušenosti s psaním chatbotů v node.js a DialogFlow. Úkol EFKO se týkal i ML, s ML mám určité, nepříliš rozsáhlé zkušenosti. A podle podmínek problému se mi zdálo, že je nepravděpodobné, že by se dal vyřešit pomocí nástrojů ML. Tento pocit se umocnil, když jsem šel na setkání Urban Tech Challenge, kde mi organizátoři ukázali dataset na EFKO, kde bylo asi 100 fotek layoutů produktů (pořízených z různých úhlů) a asi 20 tříd layoutových chyb. A zároveň ti, kteří si úkol objednali, chtěli dosáhnout úspěšnosti klasifikace 90 %. Ve výsledku jsem připravil prezentaci řešení bez ML, backender připravil prezentaci na základě katalogu a společně jsme je po finalizaci prezentací poslali do Urban Tech Challenge. Již v této fázi byla odhalena míra motivace a přínosu každého účastníka. Náš designér se neúčastnil diskuzí, reagoval pozdě a dokonce na poslední chvíli vyplňoval informace o sobě v prezentaci, obecně se objevily pochybnosti.
Výsledkem bylo, že jsme úkol z DPiIR zvládli a nebyli jsme vůbec naštvaní, že jsme neprošli EFKO, protože se nám tento úkol zdál mírně řečeno podivný.
5. Příprava na hackathon. Když se konečně provalilo, že jsme se kvalifikovali na hackathon, začali jsme připravovat přípravu. A tady neobhajuji začít psát kód týden před začátkem hackathonu. Minimálně byste měli mít připravený kotel, se kterým můžete okamžitě začít pracovat, aniž byste museli konfigurovat nástroje a nenaráželi na chyby nějaké lib, které jste se rozhodli poprvé vyzkoušet na hackathonu. Znám příběh o úhlových inženýrech, kteří přišli na hackathon a strávili 2 dny nastavováním sestavení projektu, takže by mělo být vše připraveno předem. Měli jsme v úmyslu rozdělit odpovědnosti následovně: backender píše prohledávače, které prohledávají internet a ukládají všechny shromážděné informace do databáze, zatímco já píšu API v node.js, které se dotazuje na tuto databázi a posílá data dopředu. V tomto ohledu jsem předem připravil server pomocí express.js a připravil front-end v reakci. CRA nepoužívám, webpack si vždy upravuji pro sebe a moc dobře vím, jaká rizika to může představovat (vzpomeňte si na příběh o úhlových vývojářích). V tuto chvíli jsem si od našeho návrháře vyžádal šablony rozhraní nebo alespoň makety, abych měl představu o tom, co budu rozkládat. Teoreticky by si měl také udělat vlastní přípravy a koordinovat je s námi, ale nikdy jsem nedostal odpověď. V důsledku toho jsem si vypůjčil design z jednoho ze svých starých projektů. A začalo to fungovat ještě rychleji, protože všechny styly pro tento projekt již byly napsány. Proto závěr: designér není vždy potřeba v týmu))). S tímto vývojem jsme přišli na hackathon.
6. Práce na hackathonu. Poprvé jsem svůj tým viděl naživo až při zahájení hackathonu v Centrálním distribučním centru. Sešli jsme se, probrali řešení a fáze práce na problému. A přestože jsme po otevření museli jet autobusem do Červeného října, šli jsme domů spát s tím, že dorazíme na místo do 9.00. Proč? Pořadatelé zřejmě chtěli z účastníků dostat maximum, a tak zařídili právě takový harmonogram. Ale podle mých zkušeností můžete kódovat normálně, aniž byste jednu noc spali. Co se týče toho druhého, už si nejsem jistý. Hackathon je maraton, musíte si svou sílu adekvátně spočítat a naplánovat. Navíc jsme měli přípravy.
Proto jsme po vyspání v 9.00:4 seděli v šestém patře Dewocracy. Pak náš designér nečekaně oznámil, že nemá notebook a že bude pracovat z domova a budeme komunikovat po telefonu. Tohle byla poslední kapka. A tak jsme ze čtyřky přešli na trojku, i když jsme název týmu nezměnili. Opět to pro nás nebyla velká rána, návrh už jsem měl ze starého projektu. Obecně šlo zpočátku všechno docela hladce a podle plánu. Nahráli jsme do databáze (rozhodli jsme se použít neo4j) dataset inovativních firem od organizátorů. Začal jsem sázet, pak jsem se pustil do node.js a pak se věci začaly kazit. Nikdy předtím jsem s neo8j nepracoval a nejprve jsem hledal funkční ovladač pro tuto databázi, pak jsem přišel na to, jak napsat dotaz, a pak jsem byl překvapen, když jsem zjistil, že tato databáze při dotazu vrací entity v tvar pole uzlových objektů a jejich hran. Tito. když jsem požádal o organizaci a všechna data o ní pomocí TIN, místo jednoho organizačního objektu mi bylo vráceno dlouhé pole objektů obsahujících data o této organizaci a vztazích mezi nimi. Napsal jsem mapovač, který prošel celé pole a slepil všechny objekty podle jejich organizace do jednoho objektu. Ale v bitvě, při požadavku na databázi 20 tisíc organizací, byla provedena extrémně pomalu, asi 30 - 30 sekund. Začal jsem přemýšlet o optimalizaci... A pak jsme se včas zastavili a přešli na MongoDB a trvalo nám to asi 4 minut. Celkem se na neo5j ztratilo asi XNUMX hodin.
Pamatujte, že nikdy neberte na hackathon technologii, kterou neznáte, může dojít k překvapení. Ale obecně, kromě tohoto selhání, šlo všechno podle plánu. A už 9. prosince ráno jsme měli plně funkční aplikaci. Na zbytek dne jsme plánovali přidat do něj další funkce. Do budoucna mi šlo vše relativně hladce, ale backender měl spoustu problémů se zákazem svých prohledávačů ve vyhledávačích, ve spamu agregátorů právnických osob, které se při žádosti dostaly na první místa výsledků vyhledávání pro každou konkrétní společnost. Ale je lepší, aby o tom řekl sám. První doplňkovou funkcí, kterou jsem přidal, bylo vyhledávání podle celého jména. Generální ředitel VKontakte. Trvalo to několik hodin.
Na stránce společnosti v naší aplikaci se tedy objevil avatar generálního ředitele, odkaz na jeho stránku VKontakte a některá další data. Byla to pěkná třešnička na dortu, i když nám to možná výhru nedalo. Pak jsem chtěl spustit nějakou analýzu. Ale po dlouhém hledání možností (v uživatelském rozhraní bylo mnoho nuancí) jsem se rozhodl pro nejjednodušší agregaci organizací podle kódu ekonomické činnosti. Už večer, v posledních hodinách, jsem vytyčoval šablonu pro zobrazování inovativních produktů (v naší aplikaci má být sekce Produkty a služby), i když na to backend nebyl připraven. Databáze se přitom mílovými kroky zvětšovala, crawlery fungovaly dál, backender experimentoval s NLP, aby odlišil inovativní texty od neinovativních))). To už se ale blížil čas závěrečné prezentace.
7. Prezentace. Z vlastní zkušenosti mohu říci, že na přípravu prezentace byste měli přejít zhruba 3 až 4 hodiny před jejím termínem. Zejména pokud jde o video, jeho natáčení a úprava zabere poměrně dost času. Měli jsme mít video. A měli jsme speciálního člověka, který se tím zabýval a řešil i řadu dalších organizačních záležitostí. V tomto ohledu jsme se do poslední chvíle od kódování neodváděli.
8. Rozteč. Nelíbilo se mi, že se prezentace a finále konaly v samostatný všední den (pondělí). Zde s největší pravděpodobností pokračovala politika organizátorů vymáčknout z účastníků maximum. Neplánoval jsem si vzít volno z práce, chtěl jsem jen na finále, i když zbytek mého týmu si volno vzal. Emocionální ponoření do hackathonu však bylo již tak vysoké, že jsem v 8 hodin ráno napsal do chatu svého týmu (pracovního týmu, nikoli týmu hackathonu), že si den beru na vlastní náklady, a šel jsem do centrály kancelář pro hřiště. Ukázalo se, že náš problém má mnoho čistě datových vědců, a to výrazně ovlivnilo přístup k řešení problému. Mnozí měli dobrý DS, ale nikdo neměl funkční prototyp, mnozí nedokázali obejít zákazy svých crawlerů ve vyhledávačích. Byli jsme jediným týmem s funkčním prototypem. A věděli jsme, jak problém vyřešit. Trať jsme nakonec vyhráli, i když jsme měli velké štěstí, že jsme zvolili nejméně soutěživou úlohu. Při pohledu na hřiště v jiných tratích jsme si uvědomili, že tam nebudeme mít šanci. Chci také říci, že jsme měli velké štěstí na porotu, která pečlivě zkontrolovala kód. A soudě podle recenzí se to nestalo ve všech skladbách.
9. Konečná. Poté, co jsme byli několikrát zavoláni do poroty k přezkoumání kódu, jsme v domnění, že jsme konečně vyřešili všechny problémy, šli na oběd do Burger King. Tam nás organizátoři opět zavolali, museli jsme rychle zabalit objednávky a vrátit se zpět.
Pořadatel nám ukázal, do které místnosti musíme jít, a po vstupu jsme se ocitli na veřejném školení pro vítězné týmy. Kluci, kteří měli na pódiu vystoupit, byli pořádně nabití, všichni vyšli jako opravdoví showmani.
A musím přiznat, že ve finále jsme na pozadí nejsilnějších týmů z jiných tratí vypadali bledě, vítězství v nominaci vládních zákazníků si zcela zaslouženě odnesl tým z realitní tech trati. Myslím, že klíčové faktory, které přispěly k našemu vítězství na trati, byly: dostupnost hotového polotovaru, díky kterému jsme byli schopni rychle vyrobit prototyp, přítomnost „highlights“ v prototypu (hledání generálních ředitelů na sociálních sítích) a NLP dovednosti našeho backendera , což porotu také velmi zaujalo.
A na závěr tradiční poděkování všem, kteří nás podpořili, porotě naší trati Evgeniy Evgrafiev (autor problému, který jsme na hackathonu řešili) a samozřejmě organizátorům hackathonu. Tohle byl snad ten největší a nejskvělejší hackathon, kterého jsem se kdy zúčastnil, můžu jen klukům přát, aby si tak vysoký standard udrželi i do budoucna!
Zdroj: www.habr.com