Moje ime je Dmitrij. Želim govoriti o tem, kako je naša ekipa dosegla finale hackathona Urban Tech Challenge na progi Big Data. Takoj bom rekel, da to ni prvi hackathon, v katerem sem sodeloval, in ne prvi, v katerem sem prejel nagrade. V zvezi s tem želim v svoji zgodbi izraziti nekaj splošnih opažanj in zaključkov v zvezi s celotno industrijo hackathona in podati svoje stališče v nasprotju z negativnimi ocenami, ki so se pojavile na spletu takoj po koncu Urban Tech Challenge (za primer ).
Torej najprej nekaj splošnih ugotovitev.
1. Presenetljivo je, da kar nekaj ljudi naivno misli, da je hackathon nekakšno športno tekmovanje, kjer zmagujejo najboljši koderji. To je narobe. Ne upoštevam primerov, ko organizatorji hackathona sami ne vedo, kaj hočejo (tudi to sem videl). Toda podjetje, ki organizira hackathon, praviloma sledi svojim ciljem. Njihov seznam je lahko drugačen: lahko je tehnična rešitev nekaterih težav, iskanje novih idej in ljudi itd. Ti cilji pogosto določajo format dogodka, njegov čas, online/offline, kako bodo oblikovane naloge (in ali bodo sploh oblikovane), ali bo na hackathonu pregled kode itd. S tega vidika se ocenjujeta tako ekipi kot tudi to, kar sta naredila. In zmagajo tiste ekipe, ki najbolje zadenejo točko, ki jo podjetje potrebuje, mnogi pa pridejo do te točke povsem nezavedno in po naključju, misleč, da res sodelujejo v športnem tekmovanju. Moja opažanja kažejo, da bi morali organizatorji za motivacijo udeležencev ustvariti vsaj videz športnega okolja in enakopravnih pogojev, sicer bodo deležni vala negativnosti, kot v zgornjem pregledu. Ampak smo se oddaljili.
2. Od tod naslednji sklep. Organizatorji so zainteresirani, da udeleženci pridejo na hackathon z lastnim delom, včasih celo posebej za ta namen organizirajo spletno korespondenčno fazo. To omogoča močnejše izhodne rešitve. Koncept »lastnega dela« je zelo relativen; vsak izkušen razvijalec lahko nabere na tisoče vrstic kode iz svojih starih projektov v svoji prvi objavi. In ali bo to vnaprej pripravljen razvoj? A v vsakem primeru velja pravilo, ki sem ga izrazil v obliki znanega mema:
Če želite zmagati, morate imeti nekaj, nekakšno konkurenčno prednost: podoben projekt, ki ste ga delali v preteklosti, znanje in izkušnje na določeni temi ali že pripravljeno delo, opravljeno pred začetkom hackathona. Ja, ni športno. Da, to morda ni vredno vloženega truda (tukaj se vsak sam odloči, ali je vredno kodirati 3 tedne ponoči za nagrado 100 tisoč, razdeljeno med celotno ekipo in celo s tveganjem, da je ne dobi). Toda pogosto je to edina možnost za napredovanje.
3. Izbor ekipe. Kot sem opazil v hackathon klepetih, se mnogi tega vprašanja lotevajo precej lahkomiselno (čeprav je to najpomembnejša odločitev, ki bo določila vaš rezultat na hackathonu). Na mnogih področjih delovanja (tako v športu kot na hackathonih) sem videl, da se močni ljudje radi združijo z močnimi, šibki s šibkimi, pametni s pametnimi, no, na splošno razumete ... Približno tako se dogaja v klepetalnicah: manj močni programerji jih takoj pograbijo, ljudje, ki nimajo nobenih veščin, vrednih za hackathon, dolgo visijo v klepetalnici in izbirajo ekipo po načelu, če bi le kdo vzel . Na nekaterih hackathonih se izvaja naključno razporejanje v ekipe in organizatorji trdijo, da naključne ekipe ne delujejo nič slabše od obstoječih. Toda po mojih opažanjih si motivirani ljudje praviloma sami najdejo ekipo, če je treba koga dodeliti, jih velikokrat ne pride na hackathon.
Kar zadeva sestavo ekipe, je ta zelo individualna in močno odvisna od naloge. Lahko bi rekel, da je minimalno uspešna sestava ekipe oblikovalec - front-end ali front-end - back-end. Poznam pa tudi primere, ko so zmagale ekipe, sestavljene samo iz front-enderjev, ki so v node.js dodali preprost back-end ali naredili mobilno aplikacijo v React Native; ali samo od podpornikov, ki so naredili preprosto postavitev. Na splošno je vse zelo individualno in odvisno od naloge. Moj načrt za izbiro ekipe za hackathon je bil naslednji: načrtoval sem sestaviti ekipo oziroma se pridružiti ekipi tipa front-end - back-end - designer (sam sem front-end). In zelo hitro sem začel klepetati s python backenderjem in oblikovalcem, ki je sprejel povabilo, da se nam pridruži. Malo kasneje se nam je pridružilo dekle, poslovna analitikinja, ki je že imela izkušnje z zmago na hackathonu in to je odločilo, da se nam pridruži. Po kratkem sestanku smo se odločili, da se po analogiji s fantastično četverico poimenujemo U4 (URBAN 4, urbana četverica). In celo postavili ustrezno sliko na avatar našega telegram kanala.
4. Izbira naloge. Kot sem že rekel, moraš imeti konkurenčno prednost, na podlagi tega se izbere naloga za hackathon. Na podlagi tega, ko sem pogledal in ocenjevanju njihove kompleksnosti smo se odločili za dve nalogi: katalog inovativnih podjetij iz DPiIR in chatbot iz EFKO. Nalogo iz DPIiR je izbral backender, nalogo iz EFKO sem izbral jaz, ker imel izkušnje s pisanjem chatbotov v node.js in DialogFlow. Naloga EFKO je vključevala tudi ML; imam nekaj, ne zelo obsežnih izkušenj z ML. In glede na pogoje problema se mi je zdelo, da ga z orodji ML verjetno ne bo mogoče rešiti. Ta občutek se je okrepil, ko sem šel na srečanje Urban Tech Challenge, kjer so mi organizatorji pokazali nabor podatkov na EFKO, kjer je bilo okoli 100 fotografij postavitev izdelkov (posnetih iz različnih zornih kotov) in približno 20 razredov napak v postavitvi. In hkrati so naročniki naloge želeli doseči 90-odstotno uspešnost klasifikacije. Posledično sem pripravil predstavitev rešitve brez ML, backender je pripravil predstavitev na podlagi kataloga in skupaj smo po dodelavi predstavitev poslali na Urban Tech Challenge. Že na tej stopnji se je pokazala stopnja motivacije in prispevka vsakega udeleženca. Naš oblikovalec ni sodeloval v razpravah, se je odzval pozno in celo v zadnjem trenutku v predstavitvi izpolnil podatke o sebi, na splošno so se pojavili dvomi.
Posledično smo opravili nalogo iz DPiIR in sploh nismo bili razburjeni, ker nismo opravili EFKO, saj se nam je naloga zdela milo rečeno čudna.
5. Priprave na hackathon. Ko se je končno izvedelo, da smo se uvrstili na hackathon, smo se začeli pripravljati. In tukaj ne zagovarjam, da začnete pisati kodo teden dni pred začetkom hackathona. Najmanj bi morali imeti pripravljeno osnovo, s katero lahko takoj začnete delati, ne da bi morali konfigurirati orodja in ne da bi naleteli na hrošče kakšne lib, ki ste se jo odločili prvič preizkusiti na hackathonu. Poznam zgodbo o angular inženirjih, ki so prišli na hackathon in 2 dni pripravljali gradnjo projekta, zato je treba vse pripraviti vnaprej. Odgovornosti smo nameravali porazdeliti na naslednji način: backender piše pajke, ki prebrskajo internet in vse zbrane informacije shranijo v bazo podatkov, medtem ko jaz v node.js napišem API, ki poizveduje po tej bazi podatkov in pošlje podatke naprej. V zvezi s tem sem vnaprej pripravil strežnik z uporabo express.js in pripravil front-end v reactu. CRA ne uporabljam, webpack vedno prilagodim zase in zelo dobro vem, kakšna tveganja lahko to predstavlja (spomnite se zgodbe o angular razvijalcih). Na tej točki sem od našega oblikovalca zahteval predloge vmesnika ali vsaj modele, da bi imel predstavo o tem, kaj bi postavil. Teoretično bi moral tudi sam narediti priprave in jih uskladiti z nami, a odgovora nisem nikoli prejel. Kot rezultat, sem si sposodil dizajn iz enega svojih starih projektov. In začelo je delovati še hitreje, saj so bili vsi slogi za ta projekt že napisani. Od tod sklep: oblikovalec ni vedno potreben v ekipi))). S tem razvojem smo prišli na hackathon.
6. Delo na hackathonu. Svojo ekipo sem prvič v živo videl šele na otvoritvi hackathona v Central Distribution Center. Sestali smo se, pogovorili o rešitvi in fazah dela na problemu. In čeprav smo po otvoritvi morali z avtobusom do Rdečega oktobra, smo odšli domov spat in se dogovorili, da bomo na kraj prispeli do 9.00. Zakaj? Organizatorji so očitno želeli iz udeležencev potegniti največ, zato so sestavili prav tak urnik. Toda po mojih izkušnjah lahko normalno kodirate, ne da bi spali eno noč. Glede drugega pa nisem več prepričan. Hackathon je maraton, potrebno je ustrezno izračunati in načrtovati svojo moč. Poleg tega smo imeli priprave.
Tako smo po spanju ob 9.00 sedeli v šestem nadstropju Dewocracy. Nato je naš oblikovalec nepričakovano sporočil, da nima prenosnika in da bo delal od doma, komunicirali pa bomo po telefonu. To je bila kaplja čez rob. In tako smo s štirice prešli na trojko, čeprav imena ekipe nismo spremenili. Tudi to za nas ni bil velik udarec, načrt sem imel že iz starega projekta. Na splošno je sprva vse potekalo dokaj gladko in po načrtih. V bazo podatkov (odločili smo se za neo4j) smo naložili nabor inovativnih podjetij organizatorjev. Začel sem tipkati, nato sem prevzel node.js, nato pa so se stvari začele zapletati. Nikoli prej nisem delal z neo4j in sprva sem iskal delujoč gonilnik za to zbirko podatkov, nato sem ugotovil, kako napisati poizvedbo, nato pa sem bil presenečen, ko sem ugotovil, da ta zbirka podatkov, ko je poizvedena, vrne entitete v obliki niza objektov vozlišč in njihovih robov. Tisti. ko sem zahteval organizacijo in vse podatke o njej po TIN, mi je bil namesto enega objekta organizacije vrnjen dolg niz objektov s podatki o tej organizaciji in odnosih med njimi. Napisal sem preslikavo, ki je pregledal celotno matriko in zlepil vse predmete glede na njihovo organizacijo v en objekt. Toda v bitki, ko je zahtevala bazo podatkov 8 tisoč organizacij, je bila izvedena zelo počasi, približno 20 - 30 sekund. Začel sem razmišljati o optimizaciji ... In potem smo se pravočasno ustavili in preklopili na MongoDB, kar nam je vzelo približno 30 minut. Skupaj je bilo na neo4j izgubljenih cca 5 ur.
Ne pozabite, na hackathon nikoli ne ponesite tehnologije, ki je ne poznate, lahko pride do presenečenj. Toda na splošno je razen tega neuspeha vse šlo po načrtih. In že 9. decembra zjutraj smo imeli popolnoma delujočo aplikacijo. Za preostanek dneva smo načrtovali dodajanje dodatnih funkcij. V nadaljevanju mi je šlo vse razmeroma gladko, backender pa je imel cel kup težav z banom njegovih pajkov v iskalnikih, v spamu agregatorjev pravnih oseb, ki so se ob zahtevah znašli na prvih mestih iskalnih rezultatov. za vsako posamezno podjetje. Vendar je bolje, da o tem pove sam. Prva dodatna funkcija, ki sem jo dodal, je bilo iskanje po polnem imenu. Generalni direktor VKontakte. Trajalo je nekaj ur.
Tako se je na strani podjetja v naši aplikaciji pojavil avatar generalnega direktorja, povezava do njegove strani VKontakte in nekateri drugi podatki. To je bila lepa češnja na torti, čeprav nam morda ni prinesla zmage. Nato sem želel izvesti nekaj analitike. Toda po dolgem iskanju možnosti (pri uporabniškem vmesniku je bilo veliko odtenkov) sem se odločil za najenostavnejše združevanje organizacij po šifri dejavnosti. Že zvečer, v zadnjih urah, sem postavljal predlogo za prikazovanje inovativnih izdelkov (v naši aplikaciji naj bi bil razdelek Izdelki in storitve), čeprav zaledje ni bilo pripravljeno na to. Istočasno se je zbirka podatkov skokovito povečevala, pajki so še naprej delali, backender je eksperimentiral z NLP, da bi ločil inovativna besedila od neinovativnih))). A že se je bližal čas končne predstavitve.
7. Predstavitev. Iz lastnih izkušenj lahko povem, da bi morali preklopiti na pripravo predstavitve približno 3 do 4 ure pred rokom. Sploh če gre za video, njegovo snemanje in montaža vzameta precej časa. Morali bi imeti video. In imeli smo posebno osebo, ki se je s tem ukvarjala, rešila pa je še vrsto drugih organizacijskih vprašanj. V zvezi s tem se nismo odvrnili od kodiranja do zadnjega trenutka.
8. Smola. Ni mi bilo všeč, da so bile predstavitve in finale na ločen delovni dan (ponedeljek). Tu se je najverjetneje nadaljevala politika organizatorjev, da iz udeležencev iztisnejo maksimum. Nisem nameraval vzeti dopusta v službi, želel sem le priti na finale, čeprav so ostali v moji ekipi vzeli prost dan. Vendar je bila čustvena potopljenost v hackathon že tako visoka, da sem ob 8. uri zjutraj v klepetu svoje ekipe (delovne ekipe, ne ekipe hackathona) napisal, da si vzamem dan na lastne stroške, in odšel v centralo pisarna za parcele. Izkazalo se je, da ima naš problem veliko čistih podatkovnih znanstvenikov, kar je močno vplivalo na pristop k reševanju problema. Mnogi so imeli dober DS, vendar nihče ni imel delujočega prototipa, mnogi se niso mogli izogniti prepovedim svojih pajkov v iskalnikih. Bili smo edina ekipa z delujočim prototipom. In vedeli smo, kako rešiti problem. Na koncu smo progo dobili, čeprav smo imeli veliko srečo, da smo izbrali najmanj konkurenčno nalogo. Ob pogledu na igrišča na drugih progah sva ugotovila, da tam ne bova imela možnosti. Povedati želim tudi, da smo imeli veliko srečo z žirijo, natančno so preverili kodo. In sodeč po ocenah se to ni zgodilo v vseh skladbah.
9. Končno. Potem ko so nas večkrat poklicali v žirijo na pregled kode, smo se, misleč, da smo dokončno rešili vse težave, odpravili na kosilo v Burger King. Tam so nas organizatorji spet poklicali, morali smo na hitro spakirati naročila in nazaj.
Organizator nam je pokazal, v katero sobo moramo iti, in ob vstopu smo se znašli na treningu javnega nastopanja za zmagovalne ekipe. Fantje, ki bi morali nastopiti na odru, so bili dobro nabiti, vsi so prišli ven kot pravi šovmani.
In moram priznati, da smo v finalu, v ozadju najmočnejših ekip iz drugih smeri, izgledali bledo, zmaga v nominaciji državni kupec je povsem zasluženo pripadla ekipi iz smeri nepremičninske tehnologije. Mislim, da so ključni dejavniki, ki so pripomogli k naši zmagi na progi, bili: razpoložljivost že pripravljene praznine, zaradi katere smo lahko hitro naredili prototip, prisotnost "poudarkov" v prototipu (iskanje izvršnih direktorjev na družabnih omrežjih) in NLP spretnosti našega backenderja , ki so zelo zanimale tudi žirijo.
In na koncu tradicionalna zahvala vsem, ki ste nas podpirali, žiriji naše proge, Evgeniyu Evgrafievu (avtorju problema, ki smo ga reševali na hackathonu) in seveda organizatorjem hackathona. To je bil morda največji in najbolj kul hackathon, ki sem se ga kadarkoli udeležil, fantom lahko le želim, da tako visoke standarde ohranijo tudi v prihodnje!
Vir: www.habr.com