Volám sa Dmitrij. A chcem hovoriť o tom, ako sa náš tím dostal do finále hackathonu Urban Tech Challenge na trati Big Data. Hneď poviem, že toto nie je prvý hackathon, na ktorom som sa zúčastnil, a nie prvý, na ktorom som získal ceny. V tejto súvislosti chcem vo svojom príbehu vyjadriť niekoľko všeobecných postrehov a záverov týkajúcich sa odvetvia hackathonu ako celku a vyjadriť svoj názor na rozdiel od negatívnych recenzií, ktoré sa objavili online hneď po skončení Urban Tech Challenge (napr. príklad ).
Takže najprv niekoľko všeobecných postrehov.
1. Je prekvapujúce, že si veľa ľudí naivne myslí, že hackathon je nejaký druh športovej súťaže, kde vyhrávajú najlepší kóderi. Toto je nesprávne. Neberiem do úvahy prípady, keď organizátori hackathonu sami nevedia, čo chcú (aj ja som to videl). Ale spravidla spoločnosť, ktorá organizuje hackathon, sleduje svoje vlastné ciele. Ich zoznam môže byť odlišný: môže ísť o technické riešenie niektorých problémov, hľadanie nových nápadov a ľudí atď. Tieto ciele často určujú formát podujatia, jeho načasovanie, online/offline, ako budú formulované úlohy (a či vôbec budú formulované), či bude code review na hackathone atď. Z tohto pohľadu sa hodnotia tímy aj to, čo dokázali. A tie tímy, ktoré najlepšie zasiahnu bod, ktorý spoločnosť potrebuje, vyhrávajú a mnohé sa do tohto bodu dostanú úplne nevedome a náhodou, mysliac si, že sa skutočne zúčastňujú športovej súťaže. Z mojich postrehov vyplýva, že aby organizátori motivovali účastníkov, mali by vytvoriť aspoň zdanie športového prostredia a rovnakých podmienok, inak dostanú vlnu negativity, ako vo vyššie uvedenej recenzii. Ale to sme odbočili.
2. Z toho vyplýva nasledujúci záver. Organizátori majú záujem, aby účastníci prišli na hackathon s vlastnou tvorbou, niekedy na tento účel dokonca špeciálne organizujú online korešpondenčnú stage. To umožňuje silnejšie výstupné riešenia. Koncept „vlastnej práce“ je veľmi relatívny; každý skúsený vývojár môže vo svojom prvom odovzdaní nazhromaždiť tisíce riadkov kódu zo svojich starých projektov. A to bude vopred pripravený vývoj? Ale v každom prípade platí pravidlo, ktoré som vyjadril v podobe známeho mému:
Ak chcete vyhrať, musíte mať niečo, nejakú konkurenčnú výhodu: podobný projekt, ktorý ste robili v minulosti, znalosti a skúsenosti v konkrétnej téme alebo hotovú prácu vykonanú pred začiatkom hackathonu. Áno, nie je to šport. Áno, nemusí to stáť za vynaložené úsilie (tu sa každý sám rozhodne, či sa mu oplatí kódovať 3 týždne v noci za cenu 100 tisíc, rozdelenú medzi celý tím, a to aj s rizikom, že ju nedostane). Ale často je to jediná šanca, ako sa dostať dopredu.
3. Výber tímu. Ako som si všimol na hackathon chatoch, mnohí pristupujú k tejto problematike dosť ľahkomyseľne (hoci toto je najdôležitejšie rozhodnutie, ktoré určí váš výsledok na hackathone). V mnohých oblastiach činnosti (ako v športe, tak aj v hackathone) som videl, že silní ľudia majú tendenciu spájať sa so silnými, slabí so slabými, inteligentní s inteligentnými, no, vo všeobecnosti máte predstavu... Zhruba to sa deje v chatoch: menej silní programátori sú okamžite zaskočení, ľudia, ktorí nemajú žiadne schopnosti cenné pre hackathon, dlho visia na chate a vyberajú si tím na princípe, že keby to niekto zobral . Na niektorých hackathonoch sa praktizuje náhodné prideľovanie tímov a organizátori tvrdia, že náhodné tímy nedosahujú horšie výsledky ako tie existujúce. Ale podľa mojich pozorovaní si motivovaní ľudia spravidla nájdu tím sami, ak treba niekoho prideliť, tak veľa z nich na hackathon často nepríde.
Čo sa týka zloženia tímu, toto je veľmi individuálne a veľmi závislé od úlohy. Mohol by som povedať, že minimálne životaschopné zloženie tímu je dizajnér – front-end alebo front-end – back-end. Ale poznám aj prípady, keď vyhrali tímy pozostávajúce len z front-endov, ktorí pridali jednoduchý back-end v node.js, alebo spravili mobilnú aplikáciu v React Native; alebo len od backenderov, ktorí robili jednoduchý layout. Vo všeobecnosti je všetko veľmi individuálne a závisí od úlohy. Môj plán na výber tímu na hackathon bol nasledovný: Plánoval som zostaviť tím alebo sa pripojiť k tímu typu front-end - back-end - dizajnér (sám som front-end). A celkom rýchlo som začal chatovať s python backenderom a dizajnérom, ktorý prijal pozvanie, aby sa k nám pridal. O niečo neskôr sa k nám pripojilo dievča, obchodná analytička, ktorá už mala skúsenosti s víťazstvom v hackathone, a to rozhodlo o tom, že sa k nám pridá. Po krátkom stretnutí sme sa rozhodli nazvať sa U4 (URBAN 4, urban four) analogicky s fantastickou štvorkou. A dokonca umiestnili zodpovedajúci obrázok na avatar nášho telegramového kanála.
4. Výber úlohy. Ako som už povedal, musíte mať konkurenčnú výhodu, na základe toho sa vyberá úloha na hackathon. Na základe toho som sa pozrel a posúdení ich komplexnosti sme sa rozhodli pre dve úlohy: katalóg inovatívnych podnikov od DPiIR a chatbot od EFKO. Úlohu od DPIiR vybral backender, úlohu od EFKO som si vybral ja, pretože mal skúsenosti s písaním chatbotov v node.js a DialogFlow. Úloha EFKO sa týkala aj ML, v ML mám určité, nie veľmi rozsiahle skúsenosti. A podľa podmienok problému sa mi zdalo, že je nepravdepodobné, že by sa dal vyriešiť pomocou nástrojov ML. Tento pocit sa umocnil, keď som išiel na stretnutie Urban Tech Challenge, kde mi organizátori ukázali dataset na EFKO, kde bolo asi 100 fotiek layoutov produktov (fotených z rôznych uhlov) a asi 20 tried chýb layoutu. A zároveň objednávatelia úlohy chceli dosiahnuť úspešnosť klasifikácie 90%. Výsledkom bolo, že som pripravil prezentáciu riešenia bez ML, backender pripravil prezentáciu na základe katalógu a spoločne po finalizácii prezentácií sme ich poslali do Urban Tech Challenge. Už v tejto fáze sa odhalila miera motivácie a prínosu každého účastníka. Náš dizajnér sa nezúčastnil diskusií, reagoval neskoro a dokonca na poslednú chvíľu vypĺňal informácie o sebe v prezentácii, vo všeobecnosti sa objavili pochybnosti.
Výsledkom bolo, že sme prešli úlohou z DPiIR a vôbec sme neboli naštvaní, že sme neprešli EFKO, pretože sa nám táto úloha zdala, mierne povedané, divná.
5. Príprava na hackathon. Keď sa konečne prevalilo, že sme sa kvalifikovali na hackathon, začali sme pripravovať prípravu. A tu neobhajujem začať písať kód týždeň pred začiatkom hackathonu. Minimálne by ste mali mať pripravený štandard, s ktorým môžete okamžite začať pracovať bez toho, aby ste museli konfigurovať nástroje a bez toho, aby ste narazili na chyby nejakej knižnice, ktorú ste sa rozhodli prvýkrát vyskúšať na hackathone. Poznám príbeh o uhlových inžinieroch, ktorí prišli na hackathon a strávili 2 dni nastavovaním zostavenia projektu, takže všetko by malo byť pripravené vopred. Mali sme v úmysle rozdeliť zodpovednosti takto: backender píše prehľadávače, ktoré prehľadávajú internet a ukladajú všetky zozbierané informácie do databázy, zatiaľ čo ja píšem API v node.js, ktoré sa dotazuje na túto databázu a posiela údaje dopredu. V tomto smere som vopred pripravil server pomocou express.js a v reakcii pripravil front-end. CRA nepoužívam, webpack si vždy prispôsobujem pre seba a veľmi dobre viem, aké riziká to môže predstavovať (spomeňte si na príbeh o uhlových vývojároch). V tomto bode som si vyžiadal šablóny rozhrania alebo aspoň makety od nášho dizajnéra, aby som mal predstavu o tom, čo by som rozložil. Teoreticky by si mal robiť aj vlastné prípravy a koordinovať ich s nami, ale nikdy som nedostal odpoveď. V dôsledku toho som si požičal dizajn z jedného z mojich starých projektov. A začalo to fungovať ešte rýchlejšie, keďže všetky štýly pre tento projekt už boli napísané. Preto záver: dizajnér nie je vždy potrebný v tíme))). S týmto vývojom sme prišli na hackathon.
6. Pracujte na hackathone. Prvýkrát som svoj tím videl naživo až pri otvorení hackathonu v Centrálnom distribučnom centre. Stretli sme sa, prediskutovali riešenie a fázy práce na probléme. A hoci sme po otvorení museli ísť autobusom do Červeného októbra, šli sme domov spať s tým, že na miesto prídeme do 9.00. prečo? Organizátori zrejme chceli z účastníkov vyťažiť maximum, a tak zariadili práve takýto harmonogram. Ale podľa mojich skúseností môžete kódovať normálne bez spánku na jednu noc. Čo sa týka toho druhého, už si nie som istý. Hackatón je maratón, musíte si svoju silu primerane vypočítať a naplánovať. Navyše sme mali prípravy.
Preto, keď sme sa vyspali, o 9.00 sme sedeli na šiestom poschodí v Dewocracy. Potom náš dizajnér nečakane oznámil, že nemá notebook a bude pracovať z domu a budeme komunikovať telefonicky. Toto bola posledná kvapka. A tak sme zo štvorky prešli na trojku, hoci názov tímu sme nezmenili. Opäť to pre nás nebola veľká rana, návrh som už mal zo starého projektu. Vo všeobecnosti išlo spočiatku všetko celkom hladko a podľa plánu. Nahrali sme do databázy (rozhodli sme sa použiť neo4j) dataset inovatívnych firiem od organizátorov. Začal som sádzať, potom som sa chopil node.js a potom to začalo zlyhávať. Nikdy predtým som s neo4j nepracoval a najprv som hľadal funkčný ovládač pre túto databázu, potom som prišiel na to, ako napísať dotaz, a potom som bol prekvapený, keď som zistil, že táto databáza pri dotaze vracia entity v forma poľa uzlových objektov a ich hrán. Tie. keď som požiadal o organizáciu a všetky údaje o nej prostredníctvom TIN, namiesto jedného organizačného objektu mi bolo vrátené dlhé pole objektov obsahujúcich údaje o tejto organizácii a vzťahoch medzi nimi. Napísal som mapovač, ktorý prešiel celé pole a zlepil všetky objekty podľa ich organizácie do jedného objektu. Ale v boji, keď si vyžiadali databázu 8 20 organizácií, to bolo vykonané extrémne pomaly, asi 30 - 30 sekúnd. Začal som rozmýšľať nad optimalizáciou... A potom sme sa včas zastavili a prešli na MongoDB a trvalo nám to asi 4 minút. Celkovo sa na neo5j stratilo asi XNUMX hodín.
Pamätajte, že nikdy neberte na hackathon technológiu, ktorú nepoznáte, môžu tam byť prekvapenia. Vo všeobecnosti však okrem tohto zlyhania išlo všetko podľa plánu. A už 9. decembra ráno sme mali plne funkčnú aplikáciu. Na zvyšok dňa sme plánovali pridať ďalšie funkcie. V budúcnosti mi išlo všetko relatívne hladko, no backender mal kopu problémov so zákazom svojich prehľadávačov vo vyhľadávačoch, v spame agregátorov právnických osôb, ktoré sa pri dopytovaní dostali na prvé miesta výsledkov vyhľadávania pre každú konkrétnu spoločnosť. Ale je lepšie, aby o tom povedal sám. Prvá doplnková funkcia, ktorú som pridal, bolo vyhľadávanie podľa celého mena. Generálny riaditeľ VKontakte. Trvalo to niekoľko hodín.
Na stránke spoločnosti v našej aplikácii sa teda objavil avatar generálneho riaditeľa, odkaz na jeho stránku VKontakte a niektoré ďalšie údaje. Bola to pekná čerešnička na torte, aj keď víťazstvo nám to možno neprinieslo. Potom som chcel spustiť nejakú analýzu. Ale po dlhom hľadaní možností (s používateľským rozhraním bolo veľa nuancií) som sa rozhodol pre najjednoduchšiu agregáciu organizácií podľa kódu ekonomickej činnosti. Už večer, v posledných hodinách, som vyskladal šablónu na zobrazovanie inovatívnych produktov (v našej aplikácii má byť sekcia Produkty a služby), hoci backend na to nebol pripravený. Zároveň sa databáza míľovými krokmi rozrástla, prehľadávače pokračovali v práci, backender experimentoval s NLP, aby rozlíšil inovatívne texty od neinovačných))). To sa už ale blížil čas záverečnej prezentácie.
7. Prezentácia. Z vlastnej skúsenosti môžem povedať, že na prípravu prezentácie by ste mali prejsť cca 3 až 4 hodiny pred jej termínom. Najmä ak ide o video, jeho natáčanie a úprava zaberie pomerne veľa času. Mali sme mať video. A mali sme špeciálneho človeka, ktorý sa tým zaoberal a riešil aj množstvo iných organizačných záležitostí. V tomto smere sme sa do poslednej chvíle neodpútavali od kódovania.
8. Smola. Nepáčilo sa mi, že prezentácie a finále sa konali v samostatný pracovný deň (pondelok). Tu s najväčšou pravdepodobnosťou pokračovala politika organizátorov vyžmýkať z účastníkov maximum. Neplánoval som si vziať voľno z práce, chcel som prísť len na finále, hoci zvyšok môjho tímu si zobral deň voľna. Emocionálne ponorenie do hackathonu však bolo už také vysoké, že som o ôsmej ráno napísal do chatu svojho tímu (pracovného tímu, nie tímu hackathonu), že si deň beriem na vlastné náklady a išiel som do centrály kancelária pre ihrisko. Ukázalo sa, že náš problém má veľa čistých dátových vedcov, čo výrazne ovplyvnilo prístup k riešeniu problému. Mnohí mali dobrý DS, ale nikto nemal funkčný prototyp, mnohí nevedeli obísť zákazy svojich prehľadávačov vo vyhľadávačoch. Boli sme jediný tím s funkčným prototypom. A vedeli sme, ako problém vyriešiť. Nakoniec sme trať vyhrali, aj keď sme mali veľké šťastie, že sme si vybrali najmenej súťažnú úlohu. Pri pohľade na ihriská v iných dráhach sme si uvedomili, že tam nebudeme mať šancu. Chcem tiež povedať, že sme mali veľké šťastie na porotu, ktorá starostlivo kontrolovala kódex. A podľa recenzií sa to nestalo vo všetkých skladbách.
9. Záverečná. Po tom, čo nás niekoľkokrát zavolali do poroty na preskúmanie kódu, sme v domnení, že sme konečne vyriešili všetky problémy, išli na obed do Burger King. Tam nás organizátori opäť zavolali, museli sme rýchlo zbaliť objednávky a vrátiť sa späť.
Organizátor nám ukázal, do ktorej miestnosti musíme ísť a po vstupe sme sa ocitli na školení rečníkov pre víťazné tímy. Chalani, ktorí mali vystúpiť na pódiu, boli poriadne nabití, všetci vyšli ako skutoční šoumeni.
A musím priznať, že vo finále sme na pozadí najsilnejších tímov z iných dráh vyzerali bledo, víťazstvo v nominácii vládneho zákazníka si celkom zaslúžene odniesol tím z dráhy realitných technológií. Myslím si, že kľúčové faktory, ktoré prispeli k nášmu víťazstvu na trati, boli: dostupnosť hotového polotovaru, vďaka ktorému sme boli schopní rýchlo vyrobiť prototyp, prítomnosť „highlights“ v prototype (hľadanie generálnych riaditeľov na sociálnych sieťach) a NLP zručnosti nášho backendera, čo tiež veľmi zaujalo porotu.
A na záver už tradične ďakujem všetkým, ktorí nás podporili, porote našej trate Evgeniy Evgrafiev (autor problému, ktorý sme riešili na hackathone) a samozrejme organizátorom hackathonu. Toto bol možno najväčší a najúžasnejší hackathon, na ktorom som sa kedy zúčastnil, môžem len zaželať chalanom, aby si takýto vysoký štandard udržali aj v budúcnosti!
Zdroj: hab.com