Nimeni on Dmitry. Ja haluan puhua siitä, kuinka tiimimme pääsi finaaliin Urban Tech Challenge -hackathonissa Big Data -radalla. Sanon heti, että tämä ei ole ensimmäinen hackathon, johon osallistuin, eikä ensimmäinen, jossa voitin palkintoja. Tässä suhteessa haluan kertoa tarinassani joitain yleisiä hackathon-alaa koskevia yleisiä havaintoja ja johtopäätöksiä ja esittää oman näkemykseni toisin kuin negatiiviset arvostelut, jotka ilmestyivät verkossa heti Urban Tech Challengen päättymisen jälkeen (esim. esimerkki ).
Joten ensin muutamia yleisiä huomioita.
1. On yllättävää, että aika monet ihmiset ajattelevat naiivisti, että hackathon on jonkinlainen urheilukilpailu, jossa parhaat koodaajat voittaa. Tämä on väärin. En ota huomioon tapauksia, joissa hackathon-järjestäjät eivät itse tiedä mitä haluavat (tämänkin olen nähnyt). Mutta pääsääntöisesti hackathonin järjestävä yritys tavoittelee omia tavoitteitaan. Heidän luettelonsa voi olla erilainen: se voi olla tekninen ratkaisu joihinkin ongelmiin, uusien ideoiden ja ihmisten etsiminen jne. Nämä tavoitteet määräävät usein tapahtuman muodon, ajoituksen, online/offline-tilassa, miten tehtävät muotoillaan (ja muotoillaanko niitä ollenkaan), käydäänkö hackathonissa koodiarviointia jne. Sekä joukkueita että niiden tekemistä arvioidaan tästä näkökulmasta. Ja ne joukkueet, jotka osuvat parhaiten siihen pisteeseen, mitä yritys tarvitsee, voittavat, ja monet pääsevät tähän pisteeseen täysin tiedostamatta ja vahingossa luullen, että he todella osallistuvat urheilukilpailuun. Havaintoni osoittavat, että osallistujien motivoimiseksi järjestäjien tulisi luoda vähintään urheilullisen ympäristön ilme ja tasavertaiset olosuhteet, muuten he saavat negatiivisuuden aallon, kuten yllä olevassa katsauksessa. Mutta poikkeamme.
2. Tästä seuraa seuraava johtopäätös. Järjestäjät ovat kiinnostuneita osallistujista, jotka tulevat hackathoniin omilla töillään, joskus jopa järjestävät tätä tarkoitusta varten verkkokirjeenvaihtovaiheen. Tämä mahdollistaa vahvemmat tuotantoratkaisut. "Oman työn" käsite on hyvin suhteellinen: jokainen kokenut kehittäjä voi kerätä tuhansia rivejä koodia vanhoista projekteistaan ensimmäisessä sitoumuksessaan. Ja onko tämä ennalta valmisteltu kehitys? Mutta joka tapauksessa sääntö pätee, jonka ilmaisin kuuluisan meemin muodossa:
Voittaaksesi sinulla on oltava jotain, jonkinlainen kilpailuetu: samanlainen projekti, jonka olet tehnyt aiemmin, tietoa ja kokemusta tietystä aiheesta tai valmiita töitä, jotka on tehty ennen hackathonin alkua. Kyllä, se ei ole urheilua. Kyllä, tämä ei ehkä ole käytetyn vaivan arvoista (tässä jokainen päättää itse, kannattaako koodata 3 viikkoa yöllä 100 tuhannen palkinnon saamiseksi, joka jaetaan koko tiimin kesken, ja jopa sillä riskillä, ettei sitä saa). Mutta usein tämä on ainoa mahdollisuus päästä eteenpäin.
3. Joukkueen valinta. Kuten huomasin hackathon-chateissa, monet suhtautuvat tähän asiaan melko kevytmielisesti (vaikka tämä on tärkein päätös, joka määrittää tuloksesi hackathonissa). Monilla toiminta-alueilla (sekä urheilussa että hackathoneissa) olen nähnyt, että vahvoilla ihmisillä on tapana yhdistyä vahvojen kanssa, heikoilla heikkoihin, älykkäillä älykkäisiin, no, yleensä ymmärrät... Näin käy suunnilleen chateissä: vähemmän vahvat ohjelmoijat napsautetaan heti, ihmiset, joilla ei ole hackathonille arvokkaita taitoja, roikkuvat chatissa pitkään ja valitsevat joukkueen sillä periaatteella, että jos joku ottaisi sen. . Joissakin hackathoneissa harjoitetaan satunnaista jakamista joukkueisiin, ja järjestäjät väittävät, että satunnaiset joukkueet eivät suoriudu huonommin kuin olemassa olevat. Mutta havaintojeni mukaan motivoituneet ihmiset löytävät joukkueen pääsääntöisesti itsekseen, jos joku on määrättävä, niin usein monet heistä eivät tule hackathonille.
Mitä tulee joukkueen kokoonpanoon, se on hyvin yksilöllistä ja riippuu suuresti tehtävästä. Voisin sanoa, että pienin toimiva tiimikokoonpano on suunnittelija - front-end tai front-end - back-end. Mutta tiedän myös tapauksia, joissa voittivat joukkueet, jotka koostuivat vain eturimista, jotka lisäsivät yksinkertaisen taustan node.js:ään tai tekivät mobiilisovelluksen React Nativessa; tai vain taustatekijöiltä, jotka tekivät yksinkertaisen asettelun. Yleensä kaikki on hyvin yksilöllistä ja riippuu tehtävästä. Suunnitelmani hackathonin joukkueen valinnassa oli seuraava: Suunnittelin koota tiimin tai liittyä tiimiin kuten front-end - back-end - suunnittelija (olen itse front-end). Ja melko nopeasti aloin chattailla python-taustailijan ja suunnittelijan kanssa, joka hyväksyi kutsun liittyä meihin. Hieman myöhemmin joukkoomme liittyi tyttö, yritysanalyytikko, jolla oli jo kokemusta hackathonin voittamisesta, ja tämä ratkaisi kysymyksen hänen liittymisestä joukkoomme. Lyhyen tapaamisen jälkeen päätimme kutsua itseämme U4:ksi (URBAN 4, urban four) analogisesti fantastisen neljän kanssa. Ja he jopa laittoivat vastaavan kuvan sähkekanavamme avatariin.
4. Tehtävän valinta. Kuten jo sanoin, sinulla on oltava kilpailuetu, hackathonin tehtävä valitaan tämän perusteella. Tämän perusteella katsottuaan ja arvioiden niiden monimutkaisuutta, päädyimme kahteen tehtävään: DPiIR:n innovatiivisten yritysten luetteloon ja EFKO:n chatbotiin. DPIiR:n tehtävän valitsi backender, EFKO:n tehtävän valitsin minä, koska oli kokemusta chatbottien kirjoittamisesta node.js:ssä ja DialogFlow'ssa. EFKO:n tehtävään kuului myös ML, minulla on jonkin verran, ei kovin laajaa kokemusta ML:stä. Ja ongelman ehtojen mukaan minusta tuntui, että sitä ei todennäköisesti voitu ratkaista ML-työkaluilla. Tämä tunne vahvistui, kun menin Urban Tech Challenge -tapaamiseen, jossa järjestäjät näyttivät minulle EFKO-aineistoa, jossa oli noin 100 valokuvaa tuoteasetteluista (otettuina eri näkökulmista) ja noin 20 asetteluvirheluokkaa. Ja samaan aikaan tehtävän tilaajat halusivat saavuttaa 90 prosentin luokittelun onnistumisprosentin. Lopputuloksena tein esityksen ratkaisusta ilman ML:ää, backender valmisteli esityksen katalogin perusteella ja yhdessä esitelmien viimeistelyn jälkeen lähetimme ne Urban Tech Challengeen. Jo tässä vaiheessa jokaisen osallistujan motivaatiotaso ja panos paljastettiin. Suunnittelijamme ei osallistunut keskusteluihin, vastasi myöhään ja jopa täytti tiedot itsestään esityksessä aivan viime hetkellä, yleensä heräsi epäilyksiä.
Tämän seurauksena läpäisimme tehtävän DPiIR:ltä, emmekä olleet ollenkaan järkyttyneet siitä, että emme läpäisseet EFKO:ta, koska tehtävä tuntui meistä lievästi sanoen oudolta.
5. Valmistautuminen hackathoniin. Kun vihdoin selvisi, että olimme kelpuutettu hackathoniin, aloimme valmistautua. Ja tässä en suosittele koodin kirjoittamisen aloittamista viikkoa ennen hackathonin alkua. Ainakin sinulla pitäisi olla valmiina kattilalevy, jonka kanssa voit aloittaa työskentelyn välittömästi ilman työkalujen konfigurointia ja törmäämättä joidenkin libien bugeihin, joita päätit kokeilla ensimmäistä kertaa hackathonissa. Tiedän tarinan kulmainsinööreistä, jotka tulivat hackathonille ja viettivät 2 päivää projektin rakentamiseen, joten kaikkiin pitäisi valmistautua etukäteen. Tarkoituksenamme oli jakaa vastuut seuraavasti: backender kirjoittaa indeksoijia, jotka selailevat Internetiä ja laittavat kaikki kerätyt tiedot tietokantaan, kun taas minä kirjoitan node.js:ssä API:n, joka kyselee tästä tietokannasta ja lähettää tiedot etupuolelle. Tässä suhteessa valmistelin palvelimen etukäteen express.js:n avulla ja valmistelin käyttöliittymän reactissa. En käytä CRA:ta, räätälöin aina webpackin itselleni ja tiedän erittäin hyvin, mitä riskejä tämä voi aiheuttaa (muistakaa tarina kulmikkaasta kehittäjistä). Tässä vaiheessa pyysin suunnittelijaltamme käyttöliittymämalleja tai ainakin malleja, jotta saisi käsityksen siitä, mitä asettaisin. Teoriassa hänen pitäisi myös tehdä omat valmistelunsa ja koordinoida ne kanssamme, mutta en koskaan saanut vastausta. Tämän seurauksena lainasin suunnittelun yhdestä vanhasta projektistani. Ja se alkoi toimia entistä nopeammin, koska kaikki tämän projektin tyylit oli jo kirjoitettu. Tästä päätelmä: suunnittelijaa ei aina tarvita tiimissä))). Tulimme hackathoniin näiden kehityskulkujen myötä.
6. Työskentele hackathonissa. Ensimmäisen kerran näin tiimini livenä vasta hackathonin avajaisissa Keskusjakelukeskuksessa. Tapasimme, keskustelimme ratkaisusta ja ongelman työskentelyn vaiheista. Ja vaikka avajaisten jälkeen piti mennä bussilla Red Octoberiin, menimme kotiin nukkumaan sovittuamme saapuvamme paikalle klo 9.00 mennessä. Miksi? Järjestäjät halusivat ilmeisesti saada osallistujista kaiken irti, joten järjestivät juuri tällaisen aikataulun. Mutta kokemukseni mukaan voit koodata normaalisti nukkumatta yhden yön. Mitä tulee toiseen, en ole enää varma. Hackathon on maraton, sinun täytyy laskea ja suunnitella voimasi riittävästi. Lisäksi meillä oli valmisteluja.
Siksi nukuttuamme kello 9.00 istuimme Dewocracyn kuudennessa kerroksessa. Sitten suunnittelijamme ilmoitti odottamatta, että hänellä ei ole kannettavaa tietokonetta ja että hän työskentelee kotoa, ja kommunikoimme puhelimitse. Tämä oli viimeinen pisara. Ja niin muutimme neljästä kolmeen, vaikka emme vaihtaneet joukkueen nimeä. Jälleen, tämä ei ollut meille iso isku, minulla oli jo suunnittelu vanhasta projektista. Yleisesti ottaen kaikki sujui aluksi hyvin ja suunnitelmien mukaan. Latasimme tietokantaan (päätimme käyttää neo4j:tä) tietojoukon innovatiivisista yrityksistä järjestäjiltä. Aloin ladontaa, otin sitten node.js:n, ja sitten asiat alkoivat epäonnistua. En ollut koskaan aiemmin työskennellyt neo4j:n kanssa, ja aluksi etsin toimivaa ajuria tälle tietokannalle, sitten keksin kirjoittaa kyselyn, ja sitten yllätyin huomatessani, että tämä tietokanta palauttaa kyselyn yhteydessä entiteetit solmuobjektien ja niiden reunojen joukon muodossa. Nuo. Kun pyysin organisaatiota ja kaikkia sen tietoja TIN-tunnuksella, yhden organisaatioobjektin sijasta minulle palautettiin pitkä joukko objekteja, jotka sisälsivät tietoja tästä organisaatiosta ja niiden välisistä suhteista. Kirjoitin kartoittajan, joka kävi läpi koko taulukon ja liimasi kaikki objektit niiden järjestyksen mukaan yhdeksi objektiksi. Mutta taistelussa, kun pyydettiin 8 tuhannen organisaation tietokantaa, se suoritettiin erittäin hitaasti, noin 20 - 30 sekuntia. Aloin miettiä optimointia... Ja sitten pysähdyimme ajoissa ja vaihdoimme MongoDB:hen, ja siihen meni noin 30 minuuttia. Yhteensä neo4j:llä hävisi noin 5 tuntia.
Muista, älä koskaan vie tekniikkaa hackathonille, jota et tunne, sillä voi tulla yllätyksiä. Mutta yleisesti ottaen, tätä epäonnistumista lukuun ottamatta, kaikki meni suunnitelmien mukaan. Ja jo aamulla 9. joulukuuta meillä oli täysin toimiva hakemus. Loppupäivän aioimme lisätä siihen lisäominaisuuksia. Jatkossa kaikki sujui minulle suhteellisen sujuvasti, mutta taustalla oli koko joukko ongelmia indeksointirobottien kieltämisen kanssa hakukoneissa, juridisten henkilöiden aggregaattoreiden roskapostissa, joka tuli hakutulosten ensimmäisille paikoille pyydettäessä. jokaiselle tietylle yritykselle. Mutta hänen on parempi kertoa siitä itse. Ensimmäinen lisäominaisuus, jonka lisäsin, oli haku koko nimellä. VKontakten pääjohtaja. Kesti useita tunteja.
Joten sovelluksemme yrityksen sivulla ilmestyi pääjohtajan avatar, linkki hänen VKontakte-sivulleen ja joitain muita tietoja. Se oli mukava kirsikka kakun päällä, vaikka se ei ehkä antanut meille voittoa. Sitten halusin suorittaa analytiikkaa. Mutta pitkän vaihtoehtojen etsimisen jälkeen (käyttöliittymässä oli monia vivahteita) päädyin yksinkertaisimpaan organisaatioiden yhdistämiseen taloudellisen toiminnan koodin mukaan. Jo illalla, viimeisinä tunteina, laitoin mallia innovatiivisten tuotteiden esittelyyn (sovelluksessamme pitäisi olla Tuotteet ja palvelut -osio), vaikka taustajärjestelmä ei ollut valmis tähän. Samaan aikaan tietokanta kasvoi harppauksin, indeksointirobotit jatkoivat työtä, taustakone kokeili NLP:tä erottaakseen innovatiiviset tekstit ei-innovatiivisista))). Mutta loppuesityksen aika lähestyi jo.
7. Esittely. Omasta kokemuksestani voin sanoa, että esityksen valmisteluun kannattaa siirtyä noin 3-4 tuntia ennen sen eräpäivää. Varsinkin jos kyseessä on video, sen kuvaaminen ja editointi vie melko paljon aikaa. Meillä piti olla video. Ja meillä oli erityinen henkilö, joka käsitteli tätä ja ratkaisi myös useita muita organisatorisia kysymyksiä. Tältä osin emme häirinneet itseämme koodaamisesta aivan viimeiseen hetkeen asti.
8. Pitch. En pitänyt siitä, että esitykset ja finaalit pidettiin erillisenä arkipäivänä (maanantai). Täällä todennäköisimmin jatkui järjestäjien politiikka puristaa maksimi osallistujista. En aikonut pitää vapaata töistä, halusin vain tulla finaaliin, vaikka muulla tiimilläni oli vapaapäivä. Kuitenkin emotionaalinen uppoutuminen hackathoniin oli jo niin korkea, että kirjoitin kello 8 tiimini (työryhmä, ei hackathon-tiimin) chattiin, että vietän päivän omalla kustannuksellani ja menin keskustaan. toimisto kentille. Ongelmamme osoittautui olevan paljon puhtaita datatieteilijöitä, ja tämä vaikutti suuresti lähestymistapaan ongelman ratkaisemiseen. Monilla oli hyvä DS, mutta kenelläkään ei ollut toimivaa prototyyppiä, monet eivät voineet kiertää indeksointirobottien kieltoja hakukoneissa. Olimme ainoa tiimi, jolla oli toimiva prototyyppi. Ja tiesimme kuinka ratkaista ongelma. Lopulta voitimme radan, vaikka olimmekin onnekkaita, että valitsimme vähiten kilpailukykyisen tehtävän. Tarkastellessamme muiden ratojen kenttiä ymmärsimme, että meillä ei olisi siellä mitään mahdollisuuksia. Haluan myös sanoa, että meillä oli erittäin onnea tuomariston kanssa; he tarkastivat koodin. Ja arvostelujen perusteella tämä ei tapahtunut kaikilla kappaleilla.
9. Lopullinen. Kun meidät kutsuttiin tuomaristolle useita kertoja koodinarviointiin, menimme lounaalle Burger Kingiin, koska luulimme, että olimme vihdoin ratkaisseet kaikki ongelmat. Siellä järjestäjät soittivat meille uudelleen, meidän piti nopeasti pakata tilauksemme ja palata.
Järjestäjä näytti meille, mihin huoneeseen meidän piti mennä, ja sisään astuessamme löysimme itsemme voittajajoukkueiden julkisen puheen harjoittelusta. Kaverit, joiden piti esiintyä lavalla, olivat hyvin ladattuja, kaikki tulivat ulos kuin todellisia showmiehiä.
Ja täytyy myöntää, että finaalissa muiden ratojen vahvimpien joukkueiden taustalla näytimme kalpealta, voitto valtion asiakasehdokkuudesta meni aivan ansaitusti kiinteistötekniikan radan joukkueelle. Uskon, että avaintekijät, jotka vaikuttivat voittoomme radalla, olivat: valmiin aihion saatavuus, jonka ansiosta pystyimme nopeasti tekemään prototyypin, "kohokohtien" läsnäolo prototyypissä (toimitusjohtajien haku sosiaalisissa verkostoissa) ja taustatyöntekijämme NLP-taidot, jotka myös kiinnostivat tuomaristoa suuresti.
Ja lopuksi perinteinen kiitos kaikille meitä tukeneille, radamme tuomaristolle, Evgeniy Evgrafieville (hackathonissa ratkaisemamme ongelman kirjoittaja) ja tietysti hackathonin järjestäjille. Tämä oli ehkä suurin ja siistein hackathon, johon olen koskaan osallistunut, voin vain toivoa, että kaverit pitävät jatkossakin näin korkealla tasolla!
Lähde: will.com