Mano vardas Dmitrijus. O aš noriu pakalbėti apie tai, kaip mūsų komanda Big Data trasoje pateko į Urban Tech Challenge hakatono finalą. Iš karto pasakysiu, kad tai ne pirmas hakatonas, kuriame dalyvauju, ir ne pirmas, kuriame laimėjau prizus. Šiuo atžvilgiu savo pasakojime noriu išsakyti keletą bendrų pastebėjimų ir išvadų apie visą hakatonų industriją ir pateikti savo požiūrį, o ne neigiamus atsiliepimus, kurie pasirodė internete iškart pasibaigus Urban Tech Challenge (pvz. pavyzdys ).
Taigi pirmiausia keletas bendrų pastebėjimų.
1. Stebina tai, kad nemažai žmonių naiviai galvoja, kad hakatonas yra kažkokios sporto varžybos, kuriose laimi geriausi programuotojai. Tai yra blogai. Nesvarstau atvejų, kai patys hakatono organizatoriai nežino, ko nori (mačiau ir aš). Tačiau, kaip taisyklė, hakatoną organizuojanti įmonė siekia savo tikslų. Jų sąrašas gali būti skirtingas: tai gali būti techninis kai kurių problemų sprendimas, naujų idėjų ir žmonių paieška ir pan. Šie tikslai dažnai nulemia renginio formatą, laiką, online/offline, kaip bus suformuluotos užduotys (ir ar iš viso bus formuluojamos), ar hakatone bus kodo peržiūra ir t.t. Šiuo požiūriu vertinamos ir komandos, ir tai, ką jos padarė. Ir laimi tos komandos, kurios geriausiai pataikė į įmonei reikalingą tašką, ir daugelis iki šio taško patenka visiškai nesąmoningai ir atsitiktinai, manydami, kad tikrai dalyvauja sporto varžybose. Mano pastebėjimai rodo, kad organizatoriai, norėdami motyvuoti dalyvius, turėtų sukurti bent jau sportinės aplinkos vaizdą ir vienodas sąlygas, antraip susilauks negatyvo bangos, kaip ir minėtoje apžvalgoje. Bet mes nukrypstame.
2. Taigi tokia išvada. Organizatoriai domisi, kad dalyviai į hakatoną atvyktų su savo darbais, kartais net specialiai tam surengia internetinį susirašinėjimo etapą. Tai leidžia priimti stipresnius išvesties sprendimus. „Savo darbo“ sąvoka yra labai santykinė; bet kuris patyręs kūrėjas gali sukaupti tūkstančius kodo eilučių iš savo senų projektų per pirmąjį įsipareigojimą. Ir ar tai bus iš anksto paruošta plėtra? Bet bet kuriuo atveju galioja taisyklė, kurią išreiškiau garsaus meme forma:
Norėdami laimėti, turite ką nors turėti, tam tikrą konkurencinį pranašumą: panašų projektą, kurį darėte anksčiau, žinių ir patirties konkrečioje temoje arba paruoštą darbą, atliktą iki hakatono pradžios. Taip, tai ne sportas. Taip, tai gali neapsimokėti išleistų pastangų (čia kiekvienas pats sprendžia, ar verta 3 savaites naktį koduoti už 100 tūkst. prizą, padalintą visai komandai, ir net su rizika negauti). Tačiau dažnai tai yra vienintelė galimybė patekti į priekį.
3. Komandos atranka. Kaip pastebėjau hakatono pokalbiuose, daugelis į šią problemą žiūri gana lengvabūdiškai (nors tai yra svarbiausias sprendimas, nulemsiantis jūsų rezultatą hakatone). Daugelyje veiklos sričių (tiek sporte, tiek hakatonuose) mačiau, kad stiprūs žmonės linkę vienytis su stipriais, silpni su silpnais, protingi su protingais, na, apskritai supranti... Maždaug taip ir nutinka pokalbiuose: ne tokie stiprūs programuotojai juos iš karto išgraužia, žmonės, neturintys hakatonui vertingų įgūdžių, ilgai kabinasi pokalbyje ir renkasi komandą tokiu principu, kad jei kas imtų. . Kai kuriuose hakatonuose praktikuojamas atsitiktinis priskyrimas komandoms, o organizatoriai tvirtina, kad atsitiktinės komandos pasirodo ne ką prasčiau nei esamos. Bet, mano pastebėjimais, motyvuoti žmonės, kaip taisyklė, patys susiranda komandą, jei tenka ką nors paskirti, tai dažnai daugelis į hakatoną neateina.
Kalbant apie komandos sudėtį, tai labai individualu ir labai priklauso nuo užduoties. Galėčiau pasakyti, kad minimali perspektyvi komandos sudėtis yra dizaineris – front-end arba front-end – back-end. Tačiau taip pat žinau atvejų, kai laimėjo komandos, susidedančios tik iš front-enderių, kurios pridėjo paprastą back-end į node.js arba sukūrė mobiliąją programą React Native; arba tik iš backenders, kurie padarė paprastą maketą. Apskritai viskas yra labai individualu ir priklauso nuo užduoties. Mano planas renkantis komandą hakatonui buvo toks: planavau suburti komandą arba prisijungti prie tokios komandos kaip front-end - back-end - dizaineris (aš pats esu front-end). Ir gana greitai pradėjau kalbėtis su python backender ir dizaineriu, kuris priėmė kvietimą prisijungti prie mūsų. Kiek vėliau prie mūsų prisijungė mergina, verslo analitikė, jau turėjusi hakatono laimėjimo patirties, ir tai išsprendė jos prisijungimo prie mūsų klausimą. Po trumpo susitikimo nusprendėme pasivadinti U4 (URBAN 4, urban four) pagal analogiją su fantastiniu ketvertu. Ir jie netgi įdėjo atitinkamą paveikslėlį į mūsų telegramos kanalo avatarą.
4. Užduoties pasirinkimas. Kaip jau sakiau, turi turėti konkurencinį pranašumą, pagal tai parenkama užduotis hakatonui. Remiantis tuo, pažiūrėjęs ir įvertinę jų sudėtingumą, apsisprendėme ties dviem užduotimis: novatoriškų įmonių katalogu iš DPiIR ir pokalbių roboto iš EFKO. Užduotį iš DPIiR pasirinko backender, užduotį iš EFKO pasirinkau aš, nes turėjo patirties rašant pokalbių robotus node.js ir DialogFlow. EFKO užduotis taip pat buvo susijusi su ML; Turiu šiek tiek, ne itin didelės, ML patirties. Ir pagal problemos sąlygas man atrodė, kad vargu ar ji bus išspręsta naudojant ML įrankius. Šis jausmas sustiprėjo, kai nuėjau į Urban Tech Challenge susitikimą, kur organizatoriai man parodė EFKO duomenų rinkinį, kuriame buvo apie 100 produktų išdėstymo nuotraukų (darytų iš skirtingų kampų) ir apie 20 klasių išdėstymo klaidų. Ir tuo pačiu metu tie, kurie užsakė užduotį, norėjo pasiekti 90% klasifikavimo sėkmės procentą. Dėl to aš paruošiau sprendimo pristatymą be ML, backender parengė prezentaciją pagal katalogą ir kartu, užbaigę pristatymus, išsiuntėme juos į Urban Tech Challenge. Jau šiame etape atsiskleidė kiekvieno dalyvio motyvacijos lygis ir indėlis. Mūsų dizaineris diskusijose nedalyvavo, reagavo pavėluotai, o informaciją apie save pristatyme net užpildė paskutinę akimirką, apskritai kilo abejonių.
Dėl to mes išlaikėme užduotį iš DPiIR ir nė kiek nenusiminome, kad neišlaikėme EFKO, nes užduotis mums atrodė keista, švelniai tariant.
5. Pasiruošimas hakatonui. Kai pagaliau tapo žinoma, kad patekome į hakatoną, pradėjome ruoštis. Ir čia aš ne propaguoju kodą pradėti rašyti likus savaitei iki hakatono pradžios. Turėtumėte turėti bent jau paruoštą katilinę, su kuria galėtumėte iš karto pradėti dirbti, nekonfigūruodami įrankių ir neatsitrenkdami į kai kurių lib, kurias nusprendėte pirmą kartą išbandyti hakatone, klaidas. Žinau istoriją apie kampinius inžinierius, kurie atvyko į hakatoną ir praleido 2 dienas kurdami projekto statybą, todėl viskam reikia pasiruošti iš anksto. Atsakomybes ketinome paskirstyti taip: backender rašo robotus, kurie naršo internetą ir sudeda visą surinktą informaciją į duomenų bazę, o aš rašau API į node.js, kuri užklausia šios duomenų bazės ir siunčia duomenis į priekį. Šiuo atžvilgiu iš anksto paruošiau serverį naudodamas express.js ir paruošiau sąsają react. Nenaudoju CRA, visada tinkinu internetinį paketą sau ir puikiai žinau, kokią riziką tai gali kelti (prisiminkite istoriją apie kampinius kūrėjus). Šiuo metu aš paprašiau mūsų dizainerio sąsajos šablonų ar bent maketų, kad galėčiau įsivaizduoti, ką aš išdėstysiu. Teoriškai jis taip pat turėtų pasiruošti ir su mumis derinti, bet atsakymo taip ir nesulaukiau. Dėl to dizainą pasiskolinau iš vieno iš savo senų projektų. Ir tai pradėjo veikti dar greičiau, nes visi šio projekto stiliai jau buvo parašyti. Taigi išvada: dizaineris ne visada reikalingas komandai))). Mes atvykome į hakatoną su šiais pokyčiais.
6. Darbas hakatone. Pirmą kartą savo komandą gyvai pamačiau tik hakatono atidaryme Centriniame skirstymo centre. Susitikome, aptarėme problemos sprendimą ir darbo etapus. Ir nors po atidarymo į Raudonąjį spalį turėjome važiuoti autobusu, namo grįžome miegoti, susitarę iki 9.00 į vietą. Kodėl? Organizatoriai, matyt, norėjo iš dalyvių išnaudoti kuo daugiau naudos, todėl suplanavo būtent tokį tvarkaraštį. Bet, mano patirtimi, galite normaliai koduoti nemiegoję vieną naktį. Dėl antrojo nebesu tikras. Hakatonas yra maratonas, reikia tinkamai apskaičiuoti ir planuoti savo jėgas. Be to, ruošėmės.
Todėl išsimiegoję 9.00 sėdėjome šeštame Dewocracy aukšte. Tada mūsų dizaineris netikėtai pranešė, kad nešiojamojo kompiuterio neturi ir dirbs iš namų, o mes bendrausime telefonu. Tai buvo paskutinis lašas. Ir taip iš ketverto tapome trejetu, nors komandos pavadinimo nepakeitėme. Vėlgi, tai nebuvo didelis smūgis mums, aš jau turėjau dizainą iš seno projekto. Apskritai iš pradžių viskas klostėsi gana sklandžiai ir pagal planą. Į duomenų bazę įkėlėme (nusprendėme naudoti neo4j) iš organizatorių inovatyvių įmonių duomenų rinkinį. Pradėjau spausdinti, tada paėmiau node.js ir tada viskas pradėjo blogėti. Niekada anksčiau nebuvau dirbęs su neo4j ir iš pradžių ieškojau veikiančios tvarkyklės šiai duomenų bazei, tada sugalvojau, kaip parašyti užklausą, o tada nustebau sužinojęs, kad ši duomenų bazė, kai užklausa, pateikia objektus mazgo objektų ir jų kraštų masyvo forma. Tie. kai paprašiau organizacijos ir visų jos duomenų pagal TIN, vietoj vieno organizacijos objekto man buvo grąžinta daugybė objektų, kuriuose buvo duomenys apie šią organizaciją ir jų tarpusavio ryšius. Parašiau kartografą, kuris perėjo visą masyvą ir visus objektus pagal jų organizavimą suklijavau į vieną objektą. Tačiau mūšyje, užsakius 8 tūkstančių organizacijų duomenų bazę, ji buvo vykdoma itin lėtai, apie 20–30 sekundžių. Pradėjau galvoti apie optimizavimą... Ir tada mes sustojome laiku ir perėjome į MongoDB, tai užtrukome apie 30 minučių. Iš viso neo4j buvo prarasta apie 5 valandas.
Atminkite, kad niekada nesiimkite technologijų į hakatoną, su kuriuo nesate susipažinę, gali būti netikėtumų. Bet apskritai, išskyrus šią nesėkmę, viskas vyko pagal planą. O jau gruodžio 9 dienos rytą turėjome pilnai veikiančią aplikaciją. Likusią dienos dalį planavome pridėti papildomų funkcijų. Ateityje man viskas klostėsi gana sklandžiai, tačiau backender turėjo aibę problemų dėl savo tikrintuvų uždraudimo paieškos sistemose, juridinių asmenų agregatorių šlamšte, kuris užklausant atsidūrė pirmosiose paieškos rezultatų vietose. kiekvienai konkrečiai įmonei. Bet geriau jam pačiam apie tai papasakoti. Pirmoji papildoma funkcija, kurią pridėjau, buvo paieška pagal visą vardą. „VKontakte“ generalinis direktorius. Tai užtruko kelias valandas.
Taigi įmonės puslapyje mūsų programoje pasirodė generalinio direktoriaus avataras, nuoroda į jo „VKontakte“ puslapį ir kai kurie kiti duomenys. Tai buvo graži vyšnia ant torto, nors galbūt tai ir nedavė mums pergalės. Tada norėjau atlikti analizę. Bet po ilgų variantų ieškojimo (su UI buvo daug niuansų) apsistojau ties paprasčiausiu organizacijų agregavimu pagal ekonominės veiklos kodą. Jau vakare, paskutinėmis valandomis, dėliojau inovatyvių produktų rodymo šabloną (mūsų programoje turėtų būti skyrius Produktai ir paslaugos), nors backend tam nebuvo pasiruošęs. Tuo pačiu metu duomenų bazė sparčiai išsiplėtė, tikrinimo programos toliau dirbo, užpakalinė programa eksperimentavo su NLP, kad atskirtų naujoviškus tekstus nuo nenovatyvių))). Tačiau galutinio pristatymo laikas jau artėjo.
7. Pristatymas. Iš savo patirties galiu pasakyti, kad turėtumėte pereiti prie pristatymo rengimo likus maždaug 3–4 valandoms iki jo numatyto termino. Ypač jei tai susiję su vaizdo įrašu, jo filmavimas ir montažas užima gana daug laiko. Turėjome turėti vaizdo įrašą. Ir mes turėjome specialų žmogų, kuris tuo užsiėmė ir sprendė daugybę kitų organizacinių klausimų. Šiuo atžvilgiu iki pat paskutinės akimirkos neatsiribojome nuo kodavimo.
8. Pikis. Man nepatiko, kad pristatymai ir finalai vyko atskirą darbo dieną (pirmadienį). Čia greičiausiai tęsėsi organizatorių politika išspausti iš dalyvių maksimumą. Neplanavau atostogauti nuo darbų, norėjau tik ateiti į finalą, nors likusi mano komanda laisvą dieną pasiėmė. Tačiau emocinis pasinėrimas į hakatoną jau buvo toks didelis, kad 8 valandą ryto savo komandos (darbo komandos, o ne hakatono komandos) pokalbyje parašiau, kad dieną skiriu savo lėšomis, ir nuėjau į centrinę. biuras aikštelėms. Paaiškėjo, kad mūsų problema turi daug grynųjų duomenų mokslininkų, ir tai labai paveikė požiūrį į problemos sprendimą. Daugelis turėjo gerą DS, bet niekas neturėjo veikiančio prototipo, daugelis negalėjo apeiti savo tikrinimo programų draudimų paieškos sistemose. Buvome vienintelė komanda, turinti veikiantį prototipą. Ir mes žinojome, kaip išspręsti problemą. Galiausiai trasą laimėjome, nors mums labai pasisekė, kad pasirinkome mažiausiai konkurencinę užduotį. Žvelgdami į aikštes kitose trasose supratome, kad ten šansų neturėsime. Taip pat noriu pasakyti, kad mums labai pasisekė su žiuri, jie kruopščiai patikrino kodą. Ir, sprendžiant iš atsiliepimų, tai įvyko ne visose trasose.
9. Finalas. Po to, kai kelis kartus buvome iškviesti į žiuri dėl kodo peržiūros, galvodami, kad pagaliau išsprendėme visus klausimus, nuėjome papietauti į „Burger King“. Ten mums vėl paskambino organizatoriai, teko greitai susikrauti užsakymus ir grįžti atgal.
Organizatorius parodė, į kurį kambarį reikia eiti, o įėję atsidūrėme viešo kalbėjimo treniruotėje, skirtoje nugalėtojų komandoms. Vaikinai, kurie turėjo pasirodyti scenoje, buvo gerai įkrauti, visi išėjo kaip tikri šoumenai.
Ir, turiu pripažinti, finale kitų trasų stipriausių komandų fone atrodėme išblyškę, pergalė valdiškų klientų nominacijoje visai pelnytai atiteko nekilnojamojo turto technologijų trasos komandai. Manau, kad pagrindiniai veiksniai, prisidėję prie mūsų pergalės trasoje, buvo: paruošto ruošinio, dėl kurio galėjome greitai sukurti prototipą, buvimas, prototipo „paryškinimų“ buvimas (vadovų paieška socialiniuose tinkluose) ir mūsų backender NLP įgūdžius, kurie taip pat labai sudomino žiuri.
Ir pabaigai tradicinė padėka visiems mus palaikantiems, mūsų trasos žiuri, Jevgenijui Evgrafiev (problemos, kurią išsprendėme hakatone, autoriui) ir žinoma hakatono organizatoriams. Tai buvo bene didžiausias ir šauniausias hakatonas, kuriame esu dalyvavęs, galiu tik palinkėti vaikinams ir ateityje išlaikyti tokį aukštą lygį!
Šaltinis: www.habr.com