Minu nimi on Dmitri. Ja ma tahan rääkida sellest, kuidas meie meeskond jõudis Big Data rajal Urban Tech Challenge häkatonil finaali. Ütlen kohe, et see pole esimene häkaton, millel osalesin, ja mitte esimene, millel auhindu võitsin. Seoses sellega tahan oma loos avaldada mõningaid üldisi tähelepanekuid ja järeldusi häkatonitööstuse kui terviku kohta ning avaldada oma seisukohta erinevalt negatiivsetest arvustustest, mis ilmusid veebis vahetult pärast Urban Tech Challenge'i lõppu (näiteks näide ).
Nii et kõigepealt mõned üldised tähelepanekud.
1. On üllatav, et päris paljud arvavad naiivselt, et häkaton on mingi spordivõistlus, kus võidavad parimad kodeerijad. See on vale. Ma ei võta arvesse juhtumeid, kui häkatoni korraldajad ise ei tea, mida nad tahavad (olen ka seda näinud). Aga reeglina ajab häkatoni korraldav ettevõte oma eesmärke. Nende nimekiri võib olla erinev: see võib olla tehniline lahendus mõnele probleemile, uute ideede ja inimeste otsimine jne. Need eesmärgid määravad sageli ürituse formaadi, ajastuse, online/offline, kuidas ülesanded formuleeritakse (ja kas üldse sõnastatakse), kas häkatonil toimub koodiülevaade jne. Sellest vaatenurgast hinnatakse nii meeskondi kui ka nende tegemist. Ja võidavad need meeskonnad, kes tabavad kõige paremini ettevõttele vajalikku punkti ja paljud jõuavad selleni täiesti alateadlikult ja juhuslikult, arvates, et osalevad tõesti spordivõistlusel. Minu tähelepanekud näitavad, et osalejate motiveerimiseks peaksid korraldajad looma vähemalt sportliku keskkonna välimuse ja võrdsed tingimused, vastasel juhul saabub negatiivsuse laine, nagu ülaltoodud ülevaates. Kuid me kaldume kõrvale.
2. Siit järgmine järeldus. Korraldajad on huvitatud sellest, et osalejad tuleksid häkatonile oma tööga, mõnikord korraldavad nad selleks isegi spetsiaalselt veebipõhise kirjavahetuse etapi. See võimaldab tugevamaid väljundlahendusi. Mõiste "oma töö" on väga suhteline; iga kogenud arendaja võib oma vanadest projektidest oma esimese ülesande täitmisega koguda tuhandeid koodiridu. Ja kas see on eelnevalt ettevalmistatud arendus? Kuid igal juhul kehtib reegel, mida väljendasin kuulsa meemi kujul:
Võitmiseks peab sul olema midagi, mingisugune konkurentsieelis: sarnane projekt, mis sa varem tegid, teadmised ja kogemused konkreetsel teemal või enne häkatoni algust tehtud valmis töö. Jah, see pole sport. Jah, see ei pruugi olla kulutatud jõupingutusi väärt (siin otsustab igaüks ise, kas tasub 3 nädalat öösel kodeerida 100 tuhande suuruse auhinna nimel, mis jagatakse kogu meeskonna vahel, ja isegi riskiga, et seda ei saa). Kuid sageli on see ainus võimalus edasi jõuda.
3. Meeskonna valik. Nagu häkatoni vestlustes märkasin, lähenevad paljud sellele küsimusele üsna kergemeelselt (kuigi see on kõige olulisem otsus, mis määrab sinu tulemuse häkatonil). Paljudel tegevusaladel (nii spordis kui ka häkatonidel) olen näinud, et tugevad inimesed kipuvad ühinema tugevatega, nõrgad nõrkadega, targad nutikatega, noh, üldiselt saate aru... Jututubades juhtub umbes nii: vähem tugevad programmeerijad napsatakse kohe ära, inimesed, kellel pole häkatoni jaoks väärtuslikke oskusi, istuvad pikalt vestlusringis ja valivad meeskonna põhimõttel, et kui keegi võtaks. . Mõnel häkatonil harjutatakse meeskondadele juhuslikku jaotamist ning korraldajate väitel pole juhuslikud meeskonnad sugugi kehvemad kui olemasolevad. Aga minu tähelepanekute järgi leiavad motiveeritud inimesed reeglina ise meeskonna, kui kedagi tuleb määrata, siis tihtipeale paljud häkatonile ei tulegi.
Mis puutub meeskonna koosseisu, siis see on väga individuaalne ja sõltub suuresti ülesandest. Võin öelda, et minimaalne elujõuline meeskonna koosseis on disainer – esiots või esiots – tagaosa. Kuid tean ka juhtumeid, kus võitsid ainult esiotsatest koosnevad meeskonnad, kes lisasid node.js-is lihtsa taustaprogrammi või tegid React Native'is mobiilirakenduse; või ainult backenderilt, kes tegid lihtsa küljenduse. Üldiselt on kõik väga individuaalne ja oleneb ülesandest. Minu plaan häkatonile meeskonna valimisel oli järgmine: Plaanisin kokku panna võistkonna või liituda sellise meeskonnaga nagu front-end - back-end - designer (olen ise esiots). Ja üsna kiiresti hakkasin vestlema python backenderi ja disaineriga, kes võttis vastu kutse meiega liituda. Veidi hiljem liitus meiega üks ärianalüütik, kellel oli juba häkatoni võitmise kogemus, ja see otsustas tema liitumise küsimuse. Pärast lühikest kohtumist otsustasime end nimetada U4 (URBAN 4, urban four) analoogia põhjal fantastilise nelikuga. Ja nad panid isegi vastava pildi meie telegrammi kanali avatarile.
4. Ülesande valimine. Nagu ma juba ütlesin, peab teil olema konkurentsieelis, selle järgi valitakse häkatoni ülesanne. Selle põhjal olles vaadanud ja nende keerukust hinnates otsustasime kahe ülesandega: DPiIR-i uuenduslike ettevõtete kataloog ja EFKO vestlusbot. Ülesande DPIiR-ist valis backender, EFKO ülesande valisin mina, sest oli kogemusi vestlusrobotite kirjutamisel node.js-is ja DialogFlow's. EFKO ülesanne hõlmas ka ML-i, mul on ML-s mõningane, mitte väga ulatuslik kogemus. Ja vastavalt probleemi tingimustele tundus mulle, et seda ML-i tööriistu kasutades tõenäoliselt ei lahendata. See tunne tugevnes, kui käisin Urban Tech Challenge kohtumisel, kus korraldajad näitasid mulle EFKO andmestikku, kus oli umbes 100 fotot toodete paigutustest (mis on tehtud erinevate nurkade alt) ja umbes 20 klassi küljendusvigu. Ja samal ajal soovisid ülesande tellijad saavutada klassifitseerimise edukuse määra 90%. Selle tulemusena koostasin lahenduse esitluse ilma ML-ita, backender koostas esitluse kataloogi põhjal ning koos, peale esitluste lõplikku vormistamist, saatsime need Urban Tech Challenge’ile. Juba selles etapis selgus iga osaleja motivatsioonitase ja panus. Meie disainer ei osalenud aruteludes, vastas hilja ja isegi täitis esitluses enda kohta teavet viimasel hetkel, üldiselt tekkisid kahtlused.
Selle tulemusel saime DPiIR-i ülesande läbi ega olnud üldse ärritunud, et me EFKO-t ei läbinud, kuna ülesanne tundus meile pehmelt öeldes kummaline.
5. Hackathoniks valmistumine. Kui lõpuks sai teatavaks, et oleme häkatonile kvalifitseerunud, asusime ettevalmistusi ette valmistama. Ja siinkohal ei soovita ma hakata koodi kirjutama nädal enne häkatoni algust. Minimaalselt peaks teil olema valmis katlaplaat, millega saate kohe tööle asuda, ilma et peaksite tööriistu konfigureerima ja ilma mõne lib-i vigadeta, mida otsustasite häkatonil esimest korda proovida. Ma tean lugu nurgainseneridest, kes tulid häkatonile ja veetsid 2 päeva projekti ehitamise seadistamisel, nii et kõik tuleks eelnevalt ette valmistada. Kavatsesime kohustused jaotada järgmiselt: tagaprogramm kirjutab indeksoijaid, mis uurivad Internetti ja panevad kogu kogutud teabe andmebaasi, mina aga kirjutan node.js-i API-d, mis teeb sellest andmebaasist päringu ja saadab andmed ette. Sellega seoses valmistasin eelnevalt serveri, kasutades express.js'i, ja valmistasin reactis ette esiotsa. Ma ei kasuta CRA-d, kohandan veebipakke alati enda jaoks ja tean väga hästi, milliseid riske see endaga kaasa tuua võib (meenutagem lugu nurgelistest arendajatest). Siinkohal küsisin meie disainerilt liidese malle või vähemalt makette, et saada aimu, mida ma välja paneksin. Teoreetiliselt peaks ta ka ise ettevalmistusi tegema ja meiega kooskõlastama, aga vastust ma ei saanudki. Selle tulemusena laenasin kujunduse ühest oma vanast projektist. Ja see hakkas veelgi kiiremini toimima, kuna kõik selle projekti stiilid olid juba kirjutatud. Siit järeldus: disainerit pole meeskonnas alati vaja))). Nende arendustega tulime häkatonile.
6. Töö häkatonil. Esimest korda nägin oma meeskonda otse-eetris alles häkatoni avamisel Keskjaotuskeskuses. Kohtusime, arutasime lahendust ja probleemi kallal töötamise etappe. Ja kuigi pärast avamist pidime bussiga Punasesse Oktoobrisse sõitma, läksime koju magama, leppides kokku, et jõuame kella 9.00-ks kohale. Miks? Korraldajad tahtsid ilmselt osalejatest maksimumi võtta, mistõttu korraldasid nad just sellise ajakava. Kuid minu kogemuse kohaselt saate normaalselt kodeerida ilma ühe öö magamata. Mis puudutab teist, siis ma pole enam kindel. Häkaton on maraton, oma jõudu tuleb adekvaatselt arvutada ja planeerida. Pealegi tegime ettevalmistusi.
Seetõttu istusime pärast maha magamist kell 9.00 Dewocracy kuuendal korrusel. Siis teatas meie disainer ootamatult, et tal pole sülearvutit ja ta töötab kodus ning me suhtleme telefoni teel. See oli viimane piisk karikasse. Ja nii saimegi neljast kolmene, kuigi meeskonna nime me ei muutnud. Jällegi, see polnud meie jaoks suur löök, mul oli juba vana projekti kujundus. Üldiselt läks esialgu kõik üsna libedalt ja plaanipäraselt. Laadisime andmebaasi (otsustasime kasutada neo4j) korraldajate innovaatiliste ettevõtete andmekogumi. Hakkasin laduma, siis võtsin faili node.js ja siis hakkasid asjad valesti minema. Ma polnud kunagi varem neo4j-ga töötanud ja algul otsisin selle andmebaasi jaoks töötavat draiverit, siis mõtlesin välja, kuidas päringut kirjutada ja siis avastasin üllatusega, et see andmebaas tagastab päringu tegemisel olemid sõlmeobjektide ja nende servade massiivi kujul. Need. kui taotlesin organisatsiooni ja kõiki sellel olevaid andmeid TIN-i järgi, tagastati mulle ühe organisatsiooniobjekti asemel pikk hulk objekte, mis sisaldasid andmeid selle organisatsiooni ja nendevaheliste suhete kohta. Kirjutasin kaardistaja, mis käis läbi kogu massiivi ja liimis kõik objektid vastavalt nende korraldusele üheks objektiks. Kuid lahingus 8 tuhande organisatsiooni andmebaasi taotlemisel täideti see äärmiselt aeglaselt, umbes 20–30 sekundit. Hakkasin mõtlema optimeerimise peale... Ja siis peatusime õigel ajal ja läksime üle MongoDB-le ning see võttis meil umbes 30 minutit. Kokku läks neo4j peal umbes 5 tundi kaduma.
Pidage meeles, et ärge kunagi viige tehnoloogiat häkatonile, millega te pole tuttav, seal võib ette tulla üllatusi. Aga üldiselt, peale selle ebaõnnestumise, läks kõik plaanipäraselt. Ja juba 9. detsembri hommikul oli meil täiesti töötav rakendus. Ülejäänud päeva plaanisime sellele lisafunktsioone lisada. Edaspidi läks mul kõik suhteliselt libedalt, kuid tagatöötlejal oli terve hunnik probleeme oma roomajate keelamisega otsingumootorites, juriidiliste isikute koondajate rämpspostis, mis päringu esitamisel otsingutulemuste esimestele kohtadele jõudis. iga konkreetse ettevõtte jaoks. Kuid parem on tal sellest ise rääkida. Esimene lisafunktsioon, mille ma lisasin, oli täisnime järgi otsing. VKontakte peadirektor. Kulus mitu tundi.
Niisiis ilmus meie rakenduses ettevõtte lehele peadirektori avatar, link tema VKontakte'i lehele ja mõned muud andmed. See oli kena kirss tordil, kuigi see ei pruugi anda meile võitu. Seejärel tahtsin teha analüüsi. Kuid pärast pikka valikute otsimist (kasutajaliidesega oli palju nüansse) otsustasin lihtsaima organisatsioonide koondamise majandustegevuse koodi järgi. Juba õhtul, viimastel tundidel, panin paika uuenduslike toodete kuvamise malli (meie rakenduses peaks olema jaotis Tooted ja teenused), kuigi taustaprogramm polnud selleks valmis. Samal ajal paisus andmebaas hüppeliselt, roomajad jätkasid tööd, tagaprogramm katsetas NLP-ga, et eristada uuenduslikke tekste mitteuuenduslikest))). Aga lõpuesitluse aeg oli juba lähenemas.
7. Esitlus. Omast kogemusest võin öelda, et esitluse ettevalmistamisele tuleks üle minna umbes 3–4 tundi enne selle tähtaega. Eriti kui tegemist on videoga, võtab selle pildistamine ja monteerimine üsna palju aega. Meil pidi olema video. Ja meil oli eriline inimene, kes sellega tegeles ja lahendas ka mitmeid muid korralduslikke küsimusi. Sellega seoses ei seganud me end kodeerimisest kuni viimase hetkeni.
8. Pitch. Mulle ei meeldinud, et esitlused ja finaalid peeti eraldi tööpäeval (esmaspäeval). Siin jätkus suure tõenäosusega korraldajate poliitika osalejatest maksimum välja pigistada. Ma ei plaaninud töölt puhkust võtta, tahtsin tulla ainult finaali, kuigi ülejäänud meeskond võttis päeva vabaks. Emotsionaalne süvenemine häkatonis oli aga juba nii suur, et kell 8 hommikul kirjutasin oma meeskonna (töökollektiivi, mitte häkatoni meeskonna) vestlusesse, et võtan päeva enda kulul ja läksin kesklinna. büroo väljakute jaoks. Selgus, et meie probleemis oli palju puhtaid andmeteadlasi ja see mõjutas suuresti lähenemist probleemi lahendamisele. Paljudel oli hea DS, kuid kellelgi polnud töötavat prototüüpi, paljud ei saanud otsingumootorites roomajate keeldudest mööda. Olime ainuke meeskond, kellel oli töötav prototüüp. Ja me teadsime, kuidas probleemi lahendada. Lõppkokkuvõttes võitsime raja, kuigi meil vedas väga, et valisime kõige vähem võistlusliku ülesande. Vaadates teiste radade väljakuid, saime aru, et meil pole seal mingit võimalust. Tahan ka öelda, et meil vedas žüriiga väga, nad kontrollisid koodi hoolikalt. Ja arvustuste põhjal otsustades ei juhtunud seda kõigil radadel.
9. Lõplik. Pärast seda, kui meid mitu korda žüriisse koodi ülevaatamiseks kutsuti, läksime Burger Kingisse lõunatama, arvates, et oleme lõpuks kõik probleemid lahendatud. Seal kutsusid korraldajad meid uuesti, pidime kiirelt tellimused pakkima ja tagasi minema.
Korraldaja näitas, millisesse ruumi peame minema ja sisenedes sattusime võitjameeskondade avaliku esinemise koolitusele. Tüübid, kes pidid laval esinema, olid hästi laetud, kõik tulid välja nagu tõelised showmehed.
Ja tuleb tunnistada, et finaalis nägime teiste radade tugevamate meeskondade taustal kahvatud välja, valitsuskliendi nominatsiooni võit läks täiesti vääriliselt kinnisvaratehnoloogia raja meeskonnale. Arvan, et peamised tegurid, mis meie võidule rajal kaasa aitasid, olid: valmis tooriku olemasolu, tänu millele saime kiiresti prototüübi teha, prototüübi "esiletõstmiste" olemasolu (otsige tegevjuhte sotsiaalvõrgustikes) ja meie taustamängija NLP-oskused, mis pakkusid ka žüriile suurt huvi.
Ja lõpetuseks traditsiooniline tänu kõigile, kes meid toetasid, meie raja žüriile Jevgeni Evgrafiev (häkatonil lahendatud probleemi autor) ja loomulikult häkatoni korraldajatele. See oli võib-olla suurim ja lahedaim häkaton, millel osalenud olen, jään vaid soovida, et kutid edaspidigi nii kõrgel tasemel püsiksid!
Allikas: www.habr.com