Myn namme is Dmitry. En ik wol prate oer hoe't ús team de finale berikte fan 'e Urban Tech Challenge hackathon op' e Big Data-baan. Ik sil daliks sizze dat dit net de earste hackathon is dêr't ik oan meidie, en net de earste dêr't ik prizen oan helle. Yn dit ferbân wol ik yn myn ferhaal wat algemiene observaasjes en konklúzjes útsprekke oangeande de hackathon-yndustry as gehiel, en myn stânpunt jaan yn tsjinstelling ta de negative resinsjes dy't direkt nei it ein fan 'e Urban Tech Challenge online ferskynden (foar foarbyld ).
Dus earst wat algemiene observaasjes.
1. It is ferrassend dat nochal in pear minsken naïv tinke dat in hackathon is in soarte fan sport kompetysje dêr't de bêste coders winne. Dit is ferkeard. Ik beskôgje gjin gefallen as hackathon-organisatoaren sels net witte wat se wolle (ik haw dat ek sjoen). Mar, yn 'e regel, it bedriuw dat in hackathon organisearret, stribbet har eigen doelen. Har list kin oars wêze: it kin in technyske oplossing wêze foar guon problemen, in syktocht nei nije ideeën en minsken, ensfh. Dizze doelen bepale faaks it formaat fan it evenemint, de timing, online/offline, hoe't de taken formulearre wurde (en oft se überhaupt formulearre wurde), oft der in koadebeoardieling komt by de hackathon, ensfh. Sawol de teams as wat se diene wurde út dit eachpunt beoardiele. En dy ploegen dy't it bêste berikke it punt dat it bedriuw nedich is winne, en in protte komme folslein ûnbewust en per ûngelok op dit punt, tinke dat se echt meidogge oan in sportkompetysje. Myn observaasjes litte sjen dat om dielnimmers te motivearjen, organisatoaren op syn minst it uterlik fan in sportomjouwing en gelikense betingsten moatte kreëarje, oars krije se in welle fan negativiteit, lykas yn 'e boppesteande resinsje. Mar wy ferdwine.
2. Dêrom de folgjende konklúzje. De organisatoaren binne ynteressearre yn dielnimmers dy't mei eigen wurk nei de hackathon komme, soms organisearje se sels spesjaal in online korrespondinsjepoadium foar dit doel. Dit soarget foar sterkere útfieroplossingen. It konsept fan "eigen wurk" is heul relatyf; elke betûfte ûntwikkelder kin tûzenen rigels koade sammelje fan syn âlde projekten yn syn earste commit. En sil dit in foarôf tare ûntwikkeling wêze? Mar yn alle gefallen jildt de regel, dy't ik útdrukte yn 'e foarm fan in ferneamde meme:
Om te winnen moatte jo wat hawwe, in soarte fan konkurrinsjefoardiel: in ferlykber projekt dat jo yn it ferline dien hawwe, kennis en ûnderfining yn in spesifyk ûnderwerp, of in klear wurk dien foar it begjin fan 'e hackathon. Ja, it is net sportyf. Ja, dit is miskien net de muoite wurdich (hjir bepaalt elkenien foar harsels oft it de moeite waard is om 3 wiken nachts te kodearjen foar in priis fan 100 tûzen, ferdield oer it heule team, en sels mei it risiko dat se it net krije). Mar faaks is dit de ienige kâns om foarút te kommen.
3. Team seleksje. Lykas ik yn hackathon-chats opmurken, komme in protte dit probleem frij frivol oan (hoewol dit it wichtichste beslút is dat jo resultaat sil bepale by de hackathon). Op in protte gebieten fan aktiviteit (sawol yn sport as yn hackathons) haw ik sjoen dat sterke minsken de neiging hawwe te ferienigjen mei de sterke, de swakken mei de swakken, de tûken mei de tûken, no, yn 't algemien krije jo it idee ... Dit is rûchwei wat bart yn petearen: minder sterke programmeurs wurde se fuortendaliks oppakt, minsken dy't gjin feardichheden hawwe dy't weardefolle binne foar in hackathon hingje lang yn 'e chat en kieze in team op it prinsipe dat as ien it mar nimt . By guon hackathons wurdt willekeurige opdracht oan teams oefene, en de organisatoaren beweare dat willekeurige teams net minder prestearje as besteande. Mar neffens myn waarnimmings, motivearre minsken, yn 'e regel, fine in team op har eigen; as immen moat wurde tawiisd, dan faak, in protte fan harren net komme nei de hackathon.
Wat de gearstalling fan it team oangiet, dit is heul yndividueel en tige ôfhinklik fan 'e taak. Ik soe sizze kinne dat de minimale leefbere teamkomposysje in ûntwerper is - front-end of front-end - back-end. Mar ik wit ek fan gefallen doe't teams besteande allinnich út front-enders wûn, dy't tafoege in ienfâldige back-end yn node.js, of makke in mobile applikaasje yn React Native; of allinnich fan backenders dy't dien ienfâldige opmaak. Yn 't algemien is alles heul yndividueel en hinget ôf fan' e taak. Myn plan foar it selektearjen fan in team foar de hackathon wie as folget: ik wie fan plan om in team te sammeljen of mei te dwaan oan in team lykas front-end - back-end - ûntwerper (ik bin sels in front-end). En frij gau begon ik te petearjen mei in python-backender en in ûntwerper dy't de útnoeging oannaam om mei te dwaan. In bytsje letter kaam by ús in famke, in saaklike analist, dy't al ûnderfining hie mei it winnen fan in hackathon, en dit besleat it probleem fan har by ús. Nei in koarte gearkomste hawwe wy besletten om ússels U4 (URBAN 4, urban fjouwer) te neamen nei analogy mei de fantastyske fjouwer. En se sette sels in oerienkommende ôfbylding op 'e avatar fan ús telegramkanaal.
4. Selektearje in taak. Lykas ik al sei, moatte jo in konkurrinsjefoardiel hawwe, de taak foar de hackathon wurdt selektearre op basis fan dit. Op grûn fan dit, hawwen sjoen en beoardielje harren kompleksiteit, wy fêstigen op twa taken: in katalogus fan ynnovative bedriuwen út DPiIR en in chatbot út EFKO. De taak fan DPIiR waard keazen troch de backender, de taak fan EFKO waard keazen troch my, om't hie ûnderfining mei it skriuwen fan chatbots yn node.js en DialogFlow. De EFKO-taak befette ek ML; Ik haw wat, net heul wiidweidige, ûnderfining yn ML. En neffens de betingsten fan it probleem like it my dat it net wierskynlik soe wurde oplost mei ML-ark. Dit gefoel waard fersterke doe't ik gie nei de Urban Tech Challenge meetup, dêr't de organisatoaren lieten my in dataset op EFKO, dêr't der wiene sa'n 100 foto's fan produkt layouts (nommen út ferskate hoeken) en sa'n 20 klassen fan layout flaters. En tagelyk woene dejingen dy't de taak bestelden in suksessifer foar klassifikaasje fan 90% berikke. As gefolch haw ik in presintaasje fan 'e oplossing taret sûnder ML, de backender hat in presintaasje taret basearre op' e katalogus, en tegearre, nei it finalisearjen fan 'e presintaasjes, stjoerde wy se nei de Urban Tech Challenge. Al op dit stadium waard it nivo fan motivaasje en bydrage fan elke dielnimmer iepenbiere. Us ûntwerper hat net meidien oan de diskusjes, reagearre let, en sels ynfolje ynformaasje oer himsels yn 'e presintaasje op it alderlêste momint, yn it algemien, twifels ûntstienen.
As gefolch hawwe wy de taak fan DPiIR trochgien, en wiene der hielendal net fan oertsjûge dat wy de EFKO net passe, om't de taak ús frjemd like, om it myld te sizzen.
5. Tariede op de hackathon. Doe't úteinlik bekend waard dat wy ús kwalifisearre hiene foar de hackathon, begûnen wy de tarieding ta te rieden. En hjir pleite ik net om in wike foar it begjin fan 'e hackathon koade te skriuwen. Op syn minst moatte jo in boilerplate klear hawwe, wêrmei jo daliks kinne begjinne te wurkjen, sûnder ark te konfigurearjen, en sûnder bugs fan guon lib te stoarten dy't jo besletten hawwe om foar it earst te besykjen op in hackathon. Ik wit in ferhaal oer hoekige yngenieurs dy't nei in hackathon kamen en 2 dagen bestege oan it opsetten fan it projektbou, dus alles moat fan tefoaren wurde taret. Wy wiene fan doel om ferantwurdlikheden te fersprieden as folget: de backender skriuwt crawlers dy't it ynternet skodzje en alle sammele ynformaasje yn 'e databank sette, wylst ik in API yn node.js skriuw dy't dizze databank freget en de gegevens nei de foarkant stjoert. Yn dit ferbân, ik taret in tsjinner fan tefoaren mei help fan express.js en taret in front-end yn react. Ik brûk gjin CRA, ik oanpasse webpack altyd foar mysels en ik wit hiel goed hokker risiko's dit kin posearje (ûnthâld it ferhaal oer hoekige ûntwikkelders). Op dit punt haw ik ynterface-sjabloanen of op syn minst mockups oanfrege fan ús ûntwerper om in idee te hawwen fan wat ik soe útlizze. Yn teory soe er ek syn eigen tariedings dwaan moatte en dy mei ús ôfstimme, mar ik krige noait in antwurd. As gefolch haw ik it ûntwerp liend fan ien fan myn âlde projekten. En it begon noch flugger te wurkjen, om't alle stilen foar dit projekt al skreaun wiene. Dêrfandinne de konklúzje: in ûntwerper is net altyd nedich yn in team))). Wy kamen mei dizze ûntjouwings nei de hackathon.
6. Wurkje by de hackathon. De earste kear dat ik myn ploech live seach, wie allinich by de iepening fan 'e hackathon yn it Central Distribution Center. Wy moete, besprutsen de oplossing en stadia fan wurkjen oan it probleem. En hoewol't wy nei de iepening mei de bus nei Reade Oktober moasten, giene wy nei hûs om te sliepen, ôfpraat om om 9.00 oere op it plak te kommen. Wêrom? De organisatoaren woenen blykber it measte út de dielnimmers helje, dus regele se krekt sa'n skema. Mar, yn myn ûnderfining, kinne jo normaal koade sûnder ien nacht sliepe. Wat de twadde oangiet, bin ik net mear wis. In hackathon is in maraton; jo moatte jo krêft adekwaat berekkenje en planne. Boppedat hiene wy tariedings.
Dêrom sieten wy nei it útsliepen om 9.00 oere op de sechsde ferdjipping fan Dewocracy. Doe kundige ús ûntwerper ûnferwachts oan dat hy gjin laptop hie en dat hy fan hûs út soe wurkje, en dat wy telefoanysk kommunisearje. Dit wie de lêste strie. En sa draaiden wy fan in fjouwer nei in trije, al hawwe wy de ploechnamme net feroare. Nochris wie dit gjin grutte klap foar ús; ik hie it ûntwerp al fan it âlde projekt. Yn 't algemien gie ynearsten alles frij flot en neffens plan. Wy laden yn 'e databank (wy besletten om neo4j te brûken) in dataset fan ynnovative bedriuwen fan' e organisatoaren. Ik begon te setten, naam doe node.js op, en doe begon dingen te misfire. Ik hie noch noait earder mei neo4j wurke, en earst socht ik nei in wurkjende stjoerprogramma foar dizze databank, doe fûn ik út hoe't ik in fraach skriuwe, en doe wie ik ferrast om te ûntdekken dat dizze databank, as frege, entiteiten werombringt yn 'e foarm fan in array fan node-objekten en har rânen. Dy. doe't ik frege in organisaasje en alle gegevens derop troch TIN, ynstee fan ien organisaasje foarwerp, Ik waard werom in lange rige fan foarwerpen mei gegevens oer dizze organisaasje en de relaasjes tusken harren. Ik skreau in mapper dy't troch de hiele array gie en alle objekten neffens har organisaasje yn ien objekt plakke. Mar yn 'e striid, by it oanfreegjen fan in databank fan 8 tûzen organisaasjes, waard it ekstreem stadich útfierd, sawat 20 - 30 sekonden. Ik begon te tinken oer optimalisaasje ... En doe stopten wy op 'e tiid en skeakelen oer nei MongoDB, en it duorre ús sawat 30 minuten. Yn totaal binne sa'n 4 oeren ferlern gien op neo5j.
Unthâld, nim technology noait nei in hackathon wêrmei jo net bekend binne, d'r kinne ferrassingen wêze. Mar yn 't algemien, ôfsjoen fan dit mislearjen, gie alles neffens plan. En al op 'e moarn fan 9 desimber hiene wy in folslein wurkjende oanfraach. Foar de rest fan 'e dei hawwe wy plannen om der ekstra funksjes oan ta te foegjen. Yn 'e takomst gie alles relatyf soepel foar my, mar de backender hie in hiele protte problemen mei it ferbod fan syn crawlers yn sykmasines, yn' e spam fan aggregators fan juridyske entiteiten, dy't op 'e earste plakken fan sykresultaten kamen by it oanfreegjen foar elk spesifyk bedriuw. Mar it is better foar him om der sels oer te fertellen. De earste ekstra funksje dy't ik tafoege wie sykjen op folsleine namme. Algemien direkteur fan VKontakte. It duorre ferskate oeren.
Dat, op 'e side fan it bedriuw yn ús applikaasje ferskynde in avatar fan' e algemien direkteur, in keppeling nei syn VKontakte-side en wat oare gegevens. It wie in moaie kers op 'e taart, hoewol't it miskien net joech ús de winst. Doe woe ik wat analytiken útfiere. Mar nei in lange syktocht nei opsjes (d'r wiene in protte nuânses mei de UI), haw ik fêstige op 'e ienfâldichste aggregaasje fan organisaasjes troch ekonomyske aktiviteitskoade. Al yn 'e jûn, yn' e lêste oeren, lei ik in sjabloan foar it werjaan fan ynnovative produkten (yn ús applikaasje soe d'r in seksje Produkten en tsjinsten wêze moatte), hoewol de backend hjir net klear wie. Tagelyk swolde de databank mei sprongen en grinzen, de crawlers bleaunen wurkje, de backender eksperimintearre mei NLP om ynnovative teksten te ûnderskieden fan net-ynnovative))). Mar de tiid foar de lêste presintaasje kaam al oan.
7. Presintaasje. Ut myn eigen ûnderfining kin ik sizze dat jo moatte oerskeakelje op it tarieden fan in presintaasje sawat 3 oant 4 oeren foardat it moat. Benammen as it om fideo giet, nimt it sjitten en bewurkjen in protte tiid. Wy moasten in fideo hawwe. En wy hiene in bysûndere persoan dy't hjirmei omgie, en ek noch in oantal oare organisatoaryske problemen oploste. Yn dit ferbân hawwe wy ússels net ôfliede fan kodearring oant it lêste momint.
8. Pitch. Ik fûn it net leuk dat de presintaasjes en finales op in aparte wikedei (moandei) hâlden waarden. Hjir, nei alle gedachten, it belied fan de organisatoaren fan squeeze it maksimum út de dielnimmers bleau. Ik wie net fan plan om frij te nimmen fan it wurk, ik woe allinnich nei de finale komme, hoewol de rest fan myn team de dei frij naam. De emosjonele ûnderdompeling yn de hackathon wie lykwols al sa heech dat ik om 8 oere yn it petear fan myn ploech (it wurkteam, net it hackathonteam) skreau dat ik de dei op eigen kosten naam, en gie nei de sintrale kantoar foar plakken. Us probleem die bliken in protte suvere gegevenswittenskippers te hawwen, en dit hie in protte ynfloed op de oanpak fan it oplossen fan it probleem. In protte hiene in goede DS, mar gjinien hie in wurkjend prototype, in protte koenen net om 'e ferbod fan har crawlers yn sykmasines komme. Wy wiene it ienige team mei in wurkjend prototype. En wy wisten hoe't it probleem op te lossen. Uteinlik wûnen wy de baan, hoewol wy tige gelok hiene dat wy de minste kompetitive taak keazen hawwe. Doe't wy nei de plakken yn oare spoaren sjogge, realisearren wy dat wy dêr gjin kâns hawwe. Ik wol ek sizze dat wy tige gelok hiene mei de sjuery, dy hawwe de koade sekuer kontrolearre. En, te oardieljen nei de resinsjes, dit barde net yn alle spoaren.
9. Finale. Nei't wy ferskate kearen nei de sjuery oproppen wiene foar in koadebeoardieling, gongen wy, mei it idee dat wy alle problemen einliks oplost hiene, nei de lunch by Burger King. Dêr bellen de organisatoaren ús wer, wy moasten gau ús bestellingen ynpakke en werom.
De organisator liet ús sjen yn hokker keamer wy moasten gean, en doe't wy binnenkamen, fûnen wy ússels op in training foar it sprekken foar de winnende teams. De jonges dy't op it poadium optrede soene, wiene goed beladen, elkenien kaam út as echte showmen.
En ik moat tajaan, yn 'e finale, tsjin' e eftergrûn fan 'e sterkste teams fan oare spoaren, seagen wy bleek; de oerwinning yn' e nominaasje fan 'e regearingsklant gie frij terjochte nei it team fan' e realisaasjetechbaan. Ik tink dat de kaaifaktoaren dy't bydroegen oan ús oerwinning op it spoar wiene: de beskikberens fan in klear makke blank, wêrtroch't wy fluch in prototype koene meitsje, de oanwêzigens fan "hichtepunten" yn it prototype (sykje nei CEO's op sosjale netwurken) en de NLP-feardigens fan ús backender, dy't de sjuery ek tige ynteressearre.
En ta beslút, tradisjonele tank oan al dyjingen dy't ús stipe, de sjuery fan ús spoar, Evgeniy Evgrafiev (de skriuwer fan it probleem dat wy hawwe oplost by de hackathon) en fansels de organisators fan 'e hackathon. Dit wie faaks de grutste en coolste hackathon dêr't ik oait oan meidien haw, ik kin de jonges allinnich mar winskje dat se yn 'e takomst sa'n hege standert hâlde!
Boarne: www.habr.com