My naam is Dmitry. En ek wil praat oor hoe ons span die eindronde van die Urban Tech Challenge hackathon op die Big Data-baan gehaal het. Ek sal dadelik sê dat dit nie die eerste hackathon is waaraan ek deelgeneem het nie, en nie die eerste waaraan ek pryse gewen het nie. In hierdie verband wil ek in my storie 'n paar algemene waarnemings en gevolgtrekkings oor die hackathon-industrie as geheel uitspreek, en my standpunt gee in teenstelling met die negatiewe resensies wat onmiddellik na die einde van die Urban Tech Challenge aanlyn verskyn het (vir voorbeeld ).
So eers 'n paar algemene waarnemings.
1. Dit is verbasend dat 'n hele paar mense naïef dink dat 'n hackathon 'n soort sportkompetisie is waar die beste kodeerders wen. Dis verkeerd. Ek oorweeg nie gevalle wanneer hackathon-organiseerders self nie weet wat hulle wil hê nie (ek het dit ook gesien). Maar as 'n reël streef die maatskappy wat 'n hackathon reël sy eie doelwitte na. Hul lys kan anders wees: dit kan 'n tegniese oplossing vir sommige probleme wees, 'n soektog na nuwe idees en mense, ens. Hierdie doelwitte bepaal dikwels die formaat van die geleentheid, die tydsberekening daarvan, aanlyn/vanlyn, hoe die take geformuleer gaan word (en of dit hoegenaamd geformuleer sal word), of daar 'n kode-oorsig by die hackathon sal wees, ens. Beide die spanne en wat hulle gedoen het, word vanuit hierdie oogpunt beoordeel. En daardie spanne wat die beste die punt bereik wat die maatskappy nodig het, wen, en baie kom heeltemal onbewustelik en per ongeluk tot hierdie punt en dink dat hulle werklik aan 'n sportkompetisie deelneem. My waarnemings toon dat om deelnemers te motiveer, organiseerders ten minste die voorkoms van 'n sportomgewing en gelyke omstandighede moet skep, anders sal hulle 'n golf van negatiwiteit ontvang, soos in bogenoemde resensie. Maar ons dwaal af.
2. Vandaar die volgende gevolgtrekking. Die organiseerders stel belang daarin dat deelnemers met hul eie werk na die hackathon kom, soms reël hulle selfs spesiaal 'n aanlyn korrespondensiestadium vir hierdie doel. Dit maak voorsiening vir sterker uitsetoplossings. Die konsep van "eie werk" is 'n baie relatiewe een; enige ervare ontwikkelaar kan duisende reëls kode van sy ou projekte ophoop in sy eerste commit. En sal dit 'n vooraf-voorbereide ontwikkeling wees? Maar in elk geval geld die reël, wat ek in die vorm van 'n bekende meme uitgedruk het:
Om te wen, moet jy iets hê, 'n soort mededingende voordeel: 'n soortgelyke projek wat jy in die verlede gedoen het, kennis en ervaring in 'n spesifieke onderwerp, of 'n klaargemaakte werk wat gedoen is voor die aanvang van die hackathon. Ja, dit is nie sport nie. Ja, dit is dalk nie die moeite werd nie (hier besluit elkeen self of dit die moeite werd is om vir 3 weke in die nag te kodeer vir 'n prys van 100 duisend, verdeel tussen die hele span, en selfs met die risiko om dit nie te ontvang nie). Maar dikwels is dit die enigste kans om vooruit te kom.
3. Spankeuse. Soos ek in hackathon-kletse opgemerk het, benader baie hierdie kwessie redelik ligsinnig (hoewel dit die belangrikste besluit is wat jou uitslag by die hackathon sal bepaal). Op baie gebiede van aktiwiteit (beide in sport en in hackathons) het ek gesien dat sterk mense geneig is om te verenig met die sterk, die swakkes met die swakkes, die slim met die slim, wel, in die algemeen, jy kry die idee ... Dit is min of meer wat in kletse gebeur: minder sterk programmeerders word dadelik opgeraap, mense wat nie enige vaardighede het wat waardevol is vir 'n hackathon nie, hang lank in die klets en kies 'n span op die beginsel dat as iemand dit net sou vat . By sommige hackathons word ewekansige toewysing aan spanne geoefen, en die organiseerders beweer dat ewekansige spanne nie swakker presteer as bestaande spanne nie. Maar volgens my waarnemings vind gemotiveerde mense as 'n reël 'n span op hul eie; as iemand aangewys moet word, dan kom baie van hulle dikwels nie na die hackathon nie.
Wat die samestelling van die span betref, is dit baie individueel en hoogs afhanklik van die taak. Ek kan sê dat die minimum lewensvatbare spansamestelling 'n ontwerper is - front-end of front-end - back-end. Maar ek weet ook van gevalle waar spanne wat net uit front-enders bestaan, gewen het, wat 'n eenvoudige agterkant in node.js bygevoeg het, of 'n mobiele toepassing in React Native gemaak het; of slegs van backenders wat eenvoudige uitleg gedoen het. Oor die algemeen is alles baie individueel en hang af van die taak. My plan om 'n span vir die hackathon te kies, was soos volg: Ek het beplan om 'n span saam te stel of by 'n span aan te sluit soos front-end - back-end - ontwerper (ek is self 'n front-end). En redelik vinnig het ek begin gesels met 'n luislang-backender en 'n ontwerper wat die uitnodiging aanvaar het om by ons aan te sluit. 'n Bietjie later het 'n meisie, 'n besigheidsontleder, wat reeds ondervinding gehad het om 'n hackathon te wen, by ons aangesluit, en dit het die kwessie van haar by ons aangesluit. Na 'n kort ontmoeting het ons besluit om onsself U4 (URBAN 4, stedelike vier) te noem na analogie van die fantastiese vier. En hulle het selfs 'n ooreenstemmende prentjie op die avatar van ons telegramkanaal geplaas.
4. Kies 'n taak. Soos ek reeds gesê het, moet jy 'n mededingende voordeel hê, die taak vir die hackathon word op grond hiervan gekies. Op grond hiervan, het gekyk en met die beoordeling van hul kompleksiteit, het ons op twee take besluit: 'n katalogus van innoverende ondernemings van DPiIR en 'n kletsbot van EFKO. Die taak van DPIiR is deur die backender gekies, die taak van EFKO is deur my gekies, want ondervinding gehad met die skryf van chatbots in node.js en DialogFlow. Die EFKO-taak het ook ML behels; ek het 'n mate van, nie baie uitgebreide, ondervinding in ML. En volgens die voorwaardes van die probleem, het dit vir my gelyk asof dit onwaarskynlik is om met ML-gereedskap opgelos te word. Hierdie gevoel is versterk toe ek na die Urban Tech Challenge-byeenkoms gegaan het, waar die organiseerders vir my 'n datastel op EFKO gewys het, waar daar ongeveer 100 foto's van produkuitlegte (uit verskillende hoeke geneem) en ongeveer 20 klasse uitlegfoute was. En terselfdertyd wou diegene wat die taak bestel het 'n klassifikasie-suksessyfer van 90% behaal. Gevolglik het ek 'n aanbieding van die oplossing sonder ML voorberei, die backender het 'n aanbieding gebaseer op die katalogus voorberei, en saam, nadat ons die aanbiedings gefinaliseer het, het ons dit na die Urban Tech Challenge gestuur. Reeds op hierdie stadium is die vlak van motivering en bydrae van elke deelnemer aan die lig gebring. Ons ontwerper het nie aan die besprekings deelgeneem nie, laat reageer en selfs op die laaste oomblik inligting oor homself in die aanbieding ingevul, oor die algemeen het twyfel ontstaan.
Gevolglik het ons die taak van DPiIR geslaag, en was glad nie ontsteld dat ons nie die EFKO geslaag het nie, aangesien die taak vir ons vreemd gelyk het, om dit sagkens te stel.
5. Voorbereiding vir die hackathon. Toe dit uiteindelik bekend word dat ons vir die hackathon gekwalifiseer het, het ons die voorbereiding begin voorberei. En hier bepleit ek nie om 'n week voor die begin van die hackathon kode te begin skryf nie. Op 'n minimum moet jy 'n boilerplaat gereed hê waarmee jy dadelik kan begin werk, sonder om gereedskap te konfigureer, en sonder om foute van een of ander lib te raak wat jy besluit het om vir die eerste keer by 'n hackathon te probeer. Ek ken 'n storie oor hoekige ingenieurs wat na 'n hackathon gekom het en 2 dae spandeer het om die projekbou op te stel, so alles moet vooraf voorberei word. Ons was van plan om verantwoordelikhede soos volg te versprei: die backender skryf crawlers wat die internet deursoek en al die versamelde inligting in die databasis plaas, terwyl ek 'n API in node.js skryf wat hierdie databasis navrae en die data na die voorkant stuur. In hierdie verband het ek vooraf 'n bediener voorberei met behulp van express.js en 'n front-end in reaksie voorberei. Ek gebruik nie CRA nie, ek pasmaak altyd webpack vir myself en ek weet baie goed watter risiko's dit kan inhou (onthou die storie oor hoekige ontwikkelaars). Op hierdie stadium het ek koppelvlaksjablone of ten minste mockups van ons ontwerper aangevra om 'n idee te hê van wat ek sou uitlê. In teorie moet hy ook sy eie voorbereidings tref en dit met ons koördineer, maar ek het nooit 'n antwoord gekry nie. Gevolglik het ek die ontwerp by een van my ou projekte geleen. En dit het selfs vinniger begin uitwerk, aangesien al die style vir hierdie projek reeds geskryf is. Vandaar die gevolgtrekking: 'n ontwerper is nie altyd in 'n span nodig nie))). Ons het na die hackathon gekom met hierdie verwikkelinge.
6. Werk by die hackathon. Die eerste keer wat ek my span regstreeks gesien het, was eers by die opening van die hackathon by die Sentrale Verspreidingsentrum. Ons het ontmoet, die oplossing en fases van die werk aan die probleem bespreek. En alhoewel ons ná die opening per bus na Red October moes gaan, het ons huis toe gegaan om te slaap en ingestem om teen 9.00 by die plek aan te kom. Hoekom? Die organiseerders wou glo die meeste uit die deelnemers haal, daarom het hulle net so 'n skedule gereël. Maar volgens my ervaring kan jy normaalweg kodeer sonder om vir een nag te slaap. Wat die tweede een betref, is ek nie meer seker nie. 'n Hackathon is 'n marathon; jy moet jou krag voldoende bereken en beplan. Boonop het ons voorbereidings gehad.
Daarom, nadat ons uitgeslaap het, het ons om 9.00 op die sesde verdieping van Dewocracy gesit. Toe kondig ons ontwerper onverwags aan dat hy nie 'n skootrekenaar het nie en dat hy van die huis af sal werk, en ons sal telefonies kommunikeer. Dit was die laaste strooi. En so het ons van ’n vier na ’n drie verander, hoewel ons nie die spannaam verander het nie. Weereens, dit was nie 'n groot slag vir ons nie; ek het reeds die ontwerp van die ou projek gehad. Oor die algemeen het alles aanvanklik redelik glad en volgens plan verloop. Ons het 'n datastel van innoverende maatskappye van die organiseerders in die databasis gelaai (ons het besluit om neo4j te gebruik). Ek het begin tik, toe node.js opgeneem, en toe begin dinge misbrand. Ek het nog nooit voorheen met neo4j gewerk nie, en ek het eers 'n werkende drywer vir hierdie databasis gesoek, toe het ek uitgevind hoe om 'n navraag te skryf, en toe was ek verbaas om te ontdek dat hierdie databasis, wanneer navraag gedoen word, entiteite in die vorm van 'n reeks nodus-voorwerpe en hul rande. Dié. toe ek 'n organisasie en al die data daarop deur TIN versoek het, in plaas van een organisasie-objek, het ek 'n lang reeks voorwerpe teruggestuur wat data oor hierdie organisasie en die verhoudings tussen hulle bevat. Ek het 'n karteerder geskryf wat deur die hele skikking gegaan het en al die voorwerpe volgens hul organisasie in een voorwerp vasgeplak het. Maar in die geveg, toe 'n databasis van 8 duisend organisasies aangevra is, is dit uiters stadig uitgevoer, ongeveer 20 - 30 sekondes. Ek het aan optimalisering begin dink... En toe stop ons betyds en skakel oor na MongoDB, en dit het ons omtrent 30 minute geneem. In totaal het ongeveer 4 ure op neo5j verlore gegaan.
Onthou, neem nooit tegnologie na 'n hackathon waarmee jy nie vertroud is nie, daar kan verrassings wees. Maar in die algemeen, afgesien van hierdie mislukking, het alles volgens plan verloop. En reeds die oggend van 9 Desember het ons 'n volledig werkende aansoek gehad. Vir die res van die dag het ons beplan om bykomende kenmerke daarby te voeg. In die toekoms het alles vir my relatief glad verloop, maar die backender het 'n hele klomp probleme gehad met die verbod op sy crawlers in soekenjins, in die strooipos van versamelaars van regsentiteite, wat in die eerste plekke van soekresultate gekom het wanneer hulle versoek het vir elke spesifieke maatskappy. Maar dit is beter dat hy self daarvan vertel. Die eerste bykomende kenmerk wat ek bygevoeg het, was soek op volle naam. Algemene direkteur van VKontakte. Dit het etlike ure geneem.
Dus, op die maatskappy se bladsy in ons aansoek, het 'n avatar van die algemene direkteur verskyn, 'n skakel na sy VKontakte-bladsy en 'n paar ander data. Dit was 'n lekker kersie op die koek, hoewel dit dalk nie vir ons die oorwinning gegee het nie. Toe wou ek 'n paar ontledings uitvoer. Maar na 'n lang soektog na opsies (daar was baie nuanses met die UI), het ek besluit op die eenvoudigste samevoeging van organisasies volgens ekonomiese aktiwiteitskode. Reeds saans, in die laaste ure, was ek besig om 'n sjabloon uit te lê vir die vertoon van innoverende produkte (in ons toepassing is daar veronderstel om 'n Produkte en Dienste-afdeling te wees), hoewel die backend nie hiervoor gereed was nie. Terselfdertyd het die databasis met rasse skrede geswel, die kruipers het voortgegaan om te werk, die backender het met NLP geëksperimenteer om innoverende tekste van nie-innoverende tekste te onderskei))). Maar die tyd vir die finale aanbieding het reeds aangebreek.
7. Aanbieding. Uit my eie ervaring kan ek sê dat jy moet oorskakel na die voorbereiding van 'n aanbieding so 3 tot 4 uur voor dit moet wees. Veral as dit video behels, neem die skiet en redigering daarvan nogal baie tyd. Ons was veronderstel om 'n video te hê. En ons het 'n spesiale persoon gehad wat hiermee gehandel het, en ook 'n aantal ander organisatoriese kwessies opgelos het. In hierdie verband het ons ons aandag nie tot op die laaste oomblik van kodering afgelei nie.
8. Toonhoogte. Ek het nie daarvan gehou dat die aanbiedings en finaal op 'n aparte weeksdag (Maandag) gehou is nie. Hier het waarskynlik voortgegaan met die organiseerders se beleid om die maksimum uit die deelnemers te druk. Ek het nie beplan om tyd by die werk af te neem nie, ek wou net na die eindronde kom, alhoewel die res van my span die dag verlof geneem het. Die emosionele onderdompeling in die hackathon was egter al so hoog dat ek om 8:XNUMX in die klets van my span (die werkspan, nie die hackathon-span nie) geskryf het dat ek die dag op my eie koste vat, en na die sentrale gegaan het. kantoor vir staanplekke. Ons probleem het blykbaar baie suiwer datawetenskaplikes gehad, en dit het die benadering tot die oplossing van die probleem grootliks beïnvloed. Baie het 'n goeie DS gehad, maar niemand het 'n werkende prototipe gehad nie, baie kon nie die verbod van hul crawlers in soekenjins omseil nie. Ons was die enigste span met 'n werkende prototipe. En ons het geweet hoe om die probleem op te los. Op die ou end het ons die baan gewen, hoewel ons baie gelukkig was dat ons die minste mededingende taak gekies het. As ons na die staanplekke in ander bane gekyk het, het ons besef dat ons geen kans daar sou hê nie. Ek wil ook sê dat ons baie gelukkig was met die jurie; hulle het die kode noukeurig nagegaan. En, te oordeel aan die resensies, het dit nie in alle snitte gebeur nie.
9. Finale. Nadat ons verskeie kere na die jurie geroep is vir 'n kode-oorsig, het ons gedink dat ons uiteindelik al die probleme opgelos het, middagete by Burger King gaan eet. Daar het die organiseerders ons weer gebel, ons moes vinnig ons bestellings pak en teruggaan.
Die organiseerder het vir ons gewys in watter kamer ons moet ingaan, en toe ons binnegegaan het, het ons onsself by 'n openbare redevoeringsessie vir die wenspanne bevind. Die ouens wat op die verhoog moes optree, was goed gelaai, almal het soos regte showmen uitgekom.
En ek moet erken, in die eindstryd, teen die agtergrond van die sterkste spanne van ander bane, het ons bleek gelyk; die oorwinning in die regeringskliëntnominasie het heel welverdiend aan die span van die eiendomstegnologiebaan gegaan. Ek dink dat die sleutelfaktore wat bygedra het tot ons oorwinning op die baan was: die beskikbaarheid van 'n klaargemaakte blanko, waardeur ons vinnig 'n prototipe kon maak, die teenwoordigheid van "hoogtepunte" in die prototipe (soek vir HUB's op sosiale netwerke) en die NLP-vaardighede van ons backender, wat ook die jurie baie geïnteresseerd het.
En ten slotte, tradisionele dank aan almal wat ons ondersteun het, die jurie van ons baan, Evgeniy Evgrafiev (die skrywer van die probleem wat ons by die hackathon opgelos het) en natuurlik die organiseerders van die hackathon. Hierdie was dalk die grootste en coolste hackathon waaraan ek nog deelgeneem het, ek kan net wens die ouens moet so 'n hoë standaard in die toekoms hou!
Bron: will.com