Mitt navn er Dmitry. Og jeg vil snakke om hvordan teamet vårt nådde finalen i Urban Tech Challenge hackathon på Big Data-banen. Jeg vil si med en gang at dette ikke er det første hackathonet jeg deltok i, og ikke det første jeg tok premier i. I denne forbindelse vil jeg i min historie gi uttrykk for noen generelle observasjoner og konklusjoner angående hackathon-industrien som helhet, og gi mitt synspunkt i motsetning til de negative anmeldelsene som dukket opp på nettet umiddelbart etter slutten av Urban Tech Challenge (for eksempel ).
Så først noen generelle observasjoner.
1. Det er overraskende at ganske mange naivt tror at et hackathon er en slags sportskonkurranse der de beste koderne vinner. Dette er feil. Jeg vurderer ikke tilfeller der hackathon-arrangører selv ikke vet hva de vil (jeg har sett det også). Men som regel forfølger selskapet som arrangerer et hackathon sine egne mål. Listen deres kan være annerledes: det kan være en teknisk løsning på noen problemer, et søk etter nye ideer og mennesker, etc. Disse målene bestemmer ofte formatet på arrangementet, tidspunktet for arrangementet, online/offline, hvordan oppgavene skal formuleres (og om de i det hele tatt skal formuleres), om det vil være en kodegjennomgang på hackathonet osv. Både lagene og det de gjorde blir vurdert ut fra dette synspunktet. Og de lagene som best treffer det punktet selskapet trenger vinner, og mange kommer helt ubevisst og ved et uhell til dette punktet og tenker at de virkelig deltar i en sportskonkurranse. Mine observasjoner viser at for å motivere deltakerne, bør arrangører minst skape et idrettsmiljø og like forhold, ellers vil de motta en bølge av negativitet, som i anmeldelsen ovenfor. Men vi går bort.
2. Derav følgende konklusjon. Arrangørene er interessert i at deltakere kommer til hackathon med sitt eget arbeid, noen ganger organiserer de til og med spesielt en elektronisk korrespondansescene for dette formålet. Dette åpner for sterkere produksjonsløsninger. Konseptet med "eget arbeid" er veldig relativt; enhver erfaren utvikler kan samle tusenvis av linjer med kode fra sine gamle prosjekter i sin første forpliktelse. Og vil dette være en forhåndsforberedt utvikling? Men i alle fall gjelder regelen, som jeg uttrykte i form av et kjent meme:
For å vinne må du ha noe, en slags konkurransefortrinn: et lignende prosjekt som du gjorde tidligere, kunnskap og erfaring innen et spesifikt tema, eller et ferdig arbeid gjort før starten av hackathonet. Ja, det er ikke sportslig. Ja, dette er kanskje ikke verdt innsatsen (her bestemmer alle selv om det er verdt å kode i 3 uker om natten for en premie på 100 tusen, fordelt på hele laget, og til og med med risiko for ikke å motta den). Men ofte er dette den eneste sjansen til å komme videre.
3. Lagvalg. Som jeg la merke til i hackathon-chatter, nærmer mange seg dette problemet ganske useriøst (selv om dette er den viktigste avgjørelsen som vil avgjøre resultatet på hackathonet). På mange aktivitetsområder (både innen idrett og hackathon) har jeg sett at sterke mennesker har en tendens til å forene seg med de sterke, de svake med de svake, de smarte med de smarte, ja, generelt sett skjønner du... Dette er omtrent det som skjer i chatter: mindre sterke programmerere blir de umiddelbart snappet opp, folk som ikke har noen ferdigheter som er verdifulle for et hackathon, henger lenge i chatten og velger et lag på prinsippet om at hvis bare noen ville ta det . På enkelte hackathons øves det tilfeldig tildeling til lag, og arrangørene hevder at tilfeldige lag ikke presterer dårligere enn eksisterende. Men i følge mine observasjoner finner motiverte mennesker som regel et lag på egenhånd; hvis noen må tildeles, kommer ofte mange av dem ikke til hackathon.
Når det gjelder sammensetningen av teamet, er dette veldig individuelt og svært avhengig av oppgaven. Jeg kan si at den minste levedyktige teamsammensetningen er en designer - front-end eller front-end - back-end. Men jeg kjenner også til tilfeller der lag som kun består av front-enders vant, som la til en enkel back-end i node.js, eller laget en mobilapplikasjon i React Native; eller bare fra backenders som gjorde enkel layout. Generelt er alt veldig individuelt og avhenger av oppgaven. Planen min for å velge et lag for hackathonet var som følger: Jeg planla å sette sammen et team eller bli med i et team som front-end - back-end - designer (jeg er selv en front-end). Og ganske raskt begynte jeg å chatte med en python-backender og en designer som takket ja til invitasjonen om å bli med oss. Litt senere ble en jente, en forretningsanalytiker, som allerede hadde erfaring med å vinne et hackathon, med oss, og dette avgjorde spørsmålet om at hun skulle bli med oss. Etter et kort møte bestemte vi oss for å kalle oss U4 (URBAN 4, urban fire) analogt med de fantastiske fire. Og de la til og med et tilsvarende bilde på avataren til telegramkanalen vår.
4. Velge en oppgave. Som jeg allerede har sagt, må du ha et konkurransefortrinn, oppgaven for hackathon er valgt ut fra dette. Basert på dette, etter å ha sett og vurderer kompleksiteten deres, bestemte vi oss for to oppgaver: en katalog over innovative bedrifter fra DPiIR og en chatbot fra EFKO. Oppgaven fra DPIiR ble valgt av backender, oppgaven fra EFKO ble valgt av meg, pga. hadde erfaring med å skrive chatbots i node.js og DialogFlow. EFKO-oppgaven innebar også ML, jeg har en del, ikke særlig omfattende, erfaring innen ML. Og i henhold til betingelsene for problemet, virket det for meg at det var usannsynlig å bli løst ved hjelp av ML-verktøy. Denne følelsen ble forsterket da jeg dro til Urban Tech Challenge meetup, hvor arrangørene viste meg et datasett på EFKO, hvor det var ca 100 bilder av produktoppsett (tatt fra forskjellige vinkler) og ca 20 klasser med layoutfeil. Og samtidig ønsket de som bestilte oppgaven å oppnå en suksessrate på 90 %. Som et resultat forberedte jeg en presentasjon av løsningen uten ML, backender utarbeidet en presentasjon basert på katalogen, og sammen, etter å ha fullført presentasjonene, sendte vi dem til Urban Tech Challenge. Allerede på dette stadiet ble motivasjonsnivået og bidraget til hver enkelt deltaker avslørt. Designeren vår deltok ikke i diskusjonene, svarte sent og fylte til og med ut informasjon om seg selv i presentasjonen i siste øyeblikk, generelt oppsto tvil.
Det førte til at vi besto oppgaven fra DPiIR, og var slett ikke lei oss for at vi ikke bestod EFKO, siden oppgaven virket merkelig for oss, for å si det mildt.
5. Forberedelse til hackathon. Da det endelig ble kjent at vi hadde kvalifisert oss til hackathon, begynte vi å forberede forberedelsene. Og her tar jeg ikke til orde for å begynne å skrive kode en uke før starten av hackathonet. Som et minimum bør du ha en boilerplate klar, som du umiddelbart kan begynne å jobbe med, uten å måtte konfigurere verktøy, og uten å støte på bugs av noen lib som du bestemte deg for å prøve for første gang på et hackathon. Jeg kjenner en historie om kantete ingeniører som kom til et hackathon og brukte 2 dager på å sette opp prosjektbyggingen, så alt burde være forberedt på forhånd. Vi hadde til hensikt å fordele ansvar som følger: Backenderen skriver crawlere som gjennomsøker Internett og legger all innsamlet informasjon i databasen, mens jeg skriver en API i node.js som spør etter denne databasen og sender dataene til fronten. I denne forbindelse forberedte jeg en server på forhånd ved å bruke express.js og forberedte en frontend i react. Jeg bruker ikke CRA, jeg tilpasser alltid webpack for meg selv og jeg vet godt hvilke risikoer dette kan utgjøre (husk historien om vinkelutviklere). På dette tidspunktet ba jeg om grensesnittmaler eller i det minste modeller fra designeren vår for å få en ide om hva jeg ville lage. I teorien skulle han også gjøre sine egne forberedelser og koordinere dem med oss, men jeg fikk aldri noe svar. Som et resultat lånte jeg designet fra et av mine gamle prosjekter. Og det begynte å gå enda raskere, siden alle stilene for dette prosjektet allerede var skrevet. Derav konklusjonen: en designer er ikke alltid nødvendig på et team))). Vi kom til hackathon med denne utviklingen.
6. Arbeid på hackathon. Første gang jeg så laget mitt live var bare ved åpningen av hackathonet på Central Distribution Center. Vi møttes, diskuterte løsningen og stadier av arbeidet med problemet. Og selv om vi etter åpningen måtte reise med buss til Red October, dro vi hjem for å sove, og ble enige om å ankomme stedet kl 9.00. Hvorfor? Arrangørene ønsket tilsynelatende å få mest mulig ut av deltakerne, så de arrangerte nettopp en slik timeplan. Men etter min erfaring kan du kode normalt uten å sove en natt. Når det gjelder den andre, er jeg ikke lenger sikker. Et hackathon er et maraton; du må beregne og planlegge styrken din. Dessuten hadde vi forberedelser.
Derfor, etter å ha sovet av, satt vi klokken 9.00 i sjette etasje i Dewocracy. Da annonserte designeren vår uventet at han ikke hadde en bærbar datamaskin og at han ville jobbe hjemmefra, og vi ville kommunisere på telefon. Dette var dråpen. Og så snudde vi fra en firer til en treer, selv om vi ikke endret lagnavnet. Igjen, dette var ikke et stort slag for oss, jeg hadde allerede designet fra det gamle prosjektet. Generelt gikk alt i begynnelsen ganske greit og etter planen. Vi lastet inn i databasen (vi bestemte oss for å bruke neo4j) et datasett med innovative selskaper fra arrangørene. Jeg begynte å skrive inn, så tok jeg opp node.js, og så begynte ting å gå feil. Jeg hadde aldri jobbet med neo4j før, og først lette jeg etter en fungerende driver for denne databasen, så fant jeg ut hvordan jeg skulle skrive en spørring, og så ble jeg overrasket over å oppdage at denne databasen, når den ble spurt, returnerer enheter i form av en rekke nodeobjekter og deres kanter. De. når jeg ba om en organisasjon og alle dataene på den av TIN, i stedet for ett organisasjonsobjekt, ble jeg returnert en lang rekke objekter som inneholdt data om denne organisasjonen og relasjonene mellom dem. Jeg skrev en kartlegger som gikk gjennom hele arrayet og limte alle objektene i henhold til deres organisasjon til ett objekt. Men i kamp, når du ba om en database med 8 tusen organisasjoner, ble den utført ekstremt sakte, omtrent 20 - 30 sekunder. Jeg begynte å tenke på optimalisering... Og så stoppet vi i tide og byttet til MongoDB, og det tok oss omtrent 30 minutter. Totalt gikk ca 4 timer tapt på neo5j.
Husk, aldri ta teknologi til et hackathon som du ikke er kjent med, det kan dukke opp overraskelser. Men generelt, bortsett fra denne fiaskoen, gikk alt etter planen. Og allerede om morgenen 9. desember hadde vi en fullt fungerende søknad. Resten av dagen planla vi å legge til flere funksjoner til den. I fremtiden gikk alt relativt greit for meg, men backenderen hadde en hel haug med problemer med forbudet mot crawlerne sine i søkemotorer, i spam fra aggregatorer av juridiske enheter, som kom på de første stedene i søkeresultatene når de forespurte for hvert enkelt selskap. Men det er bedre for ham å fortelle om det selv. Den første tilleggsfunksjonen jeg la til var søk med fullt navn. Daglig direktør for VKontakte. Det tok flere timer.
Så på selskapets side i applikasjonen vår dukket det opp en avatar av generaldirektøren, en lenke til hans VKontakte-side og noen andre data. Det var et godt kirsebær på kaken, selv om det kanskje ikke ga oss seieren. Så ville jeg kjøre litt analyser. Men etter et langt søk etter alternativer (det var mange nyanser med brukergrensesnittet), slo jeg meg på den enkleste aggregeringen av organisasjoner etter økonomisk aktivitetskode. Allerede på kvelden, de siste timene, holdt jeg på å lage en mal for å vise innovative produkter (i vår applikasjon skal det være en Produkter og Tjenester-seksjon), selv om backend ikke var klar for dette. Samtidig svulmet databasen med stormskritt, crawlerne fortsatte å jobbe, backenderen eksperimenterte med NLP for å skille innovative tekster fra ikke-innovative))). Men tiden for den endelige presentasjonen nærmet seg allerede.
7. Presentasjon. Av egen erfaring kan jeg si at du bør gå over til å forberede en presentasjon ca 3 til 4 timer før den skal. Spesielt hvis det involverer video, tar opptak og redigering ganske mye tid. Vi skulle ha en video. Og vi hadde en spesiell person som tok oss av dette, og også løste en del andre organisatoriske spørsmål. I denne forbindelse distraherte vi oss ikke fra koding før i siste øyeblikk.
8. Pitch. Jeg likte ikke at presentasjonene og finalen ble holdt på en egen ukedag (mandag). Her fortsatte mest sannsynlig arrangørenes politikk med å presse maksimalt ut av deltakerne. Jeg planla ikke å ta fri fra jobben, jeg ville bare komme til finalen, selv om resten av laget mitt tok fri. Imidlertid var den emosjonelle fordypningen i hackathon allerede så høy at klokken 8 skrev jeg i chatten til teamet mitt (arbeidsteamet, ikke hackathonteamet) at jeg tok dagen for egen regning, og gikk til sentralen. kontor for plasser. Problemet vårt viste seg å ha mange rene dataforskere, og dette påvirket i stor grad tilnærmingen til å løse problemet. Mange hadde en god DS, men ingen hadde en fungerende prototype, mange kunne ikke komme utenom forbudene til crawlerne sine i søkemotorer. Vi var det eneste teamet med en fungerende prototype. Og vi visste hvordan vi skulle løse problemet. Til slutt vant vi banen, selv om vi var veldig heldige at vi valgte den minst konkurransedyktige oppgaven. Når vi så på banene i andre spor, innså vi at vi ikke ville ha noen sjanse der. Jeg vil også si at vi var veldig heldige med juryen, de sjekket koden nøye. Og etter anmeldelsene å dømme skjedde ikke dette i alle spor.
9. Finale. Etter at vi ble kalt til juryen flere ganger for en kodegjennomgang, tenkte vi at vi endelig hadde løst alle problemene, og spiste lunsj på Burger King. Der ringte arrangørene oss igjen, vi måtte raskt pakke bestillingene og gå tilbake.
Arrangøren viste oss hvilket rom vi trengte å gå inn i, og da vi kom inn, befant vi oss på en talertrening for vinnerlagene. Gutta som skulle opptre på scenen var godt ladet, alle kom ut som ekte showmenn.
Og jeg må innrømme, i finalen, på bakgrunn av de sterkeste lagene fra andre baner, så vi bleke ut; seieren i regjeringens kundenominasjon gikk helt fortjent til laget fra eiendomsteknologibanen. Jeg tror at nøkkelfaktorene som bidro til seieren vår på banen var: tilgjengeligheten av en ferdig laget blank, på grunn av hvilken vi raskt kunne lage en prototype, tilstedeværelsen av "høydepunkter" i prototypen (søk etter administrerende direktører på sosiale nettverk) og NLP-ferdighetene til backenderen vår, som også interesserte juryen sterkt.
Og avslutningsvis, tradisjonell takk til alle de som støttet oss, juryen på banen vår, Evgeniy Evgrafiev (forfatteren av problemet som vi løste på hackathonet) og selvfølgelig arrangørene av hackathonet. Dette var kanskje det største og kuleste hackathonet jeg noen gang har deltatt på, jeg kan bare ønske at gutta holder en så høy standard i fremtiden!
Kilde: www.habr.com