Mit navn er Dmitry. Og jeg vil gerne tale om, hvordan vores hold nåede finalen i Urban Tech Challenge hackathon på Big Data-banen. Jeg vil med det samme sige, at dette ikke er det første hackathon, jeg deltog i, og ikke det første, hvor jeg vandt præmier. I denne henseende vil jeg i min historie give udtryk for nogle generelle observationer og konklusioner vedrørende hackathon-industrien som helhed og give mit synspunkt i modsætning til de negative anmeldelser, der dukkede op online umiddelbart efter afslutningen af Urban Tech Challenge (for eksempel ).
Så først nogle generelle bemærkninger.
1. Det er overraskende, at en del mennesker naivt tror, at et hackathon er en form for sportskonkurrence, hvor de bedste kodere vinder. Det er forkert. Jeg overvejer ikke tilfælde, hvor hackathon-arrangører ikke selv ved, hvad de vil (det har jeg også set). Men som regel forfølger virksomheden, der arrangerer et hackathon, sine egne mål. Deres liste kan være anderledes: det kan være en teknisk løsning på nogle problemer, en søgen efter nye ideer og mennesker osv. Disse mål bestemmer ofte arrangementets format, dets timing, online/offline, hvordan opgaverne vil blive formuleret (og om de overhovedet bliver formuleret), om der vil være en kodegennemgang ved hackathonet osv. Både holdene og hvad de lavede bliver vurderet ud fra dette synspunkt. Og de hold, der bedst rammer det punkt, virksomheden har brug for, vinder, og mange kommer helt ubevidst og ved et uheld til dette punkt og tror, at de virkelig deltager i en sportskonkurrence. Mine observationer viser, at for at motivere deltagerne bør arrangørerne mindst skabe et udseende af et sportsmiljø og lige vilkår, ellers vil de modtage en bølge af negativitet, som i ovenstående anmeldelse. Men vi afviger.
2. Derfor følgende konklusion. Arrangørerne er interesserede i, at deltagere kommer til hackathonet med deres eget arbejde, nogle gange arrangerer de endda specielt en online korrespondancefase til dette formål. Dette giver mulighed for stærkere output-løsninger. Konceptet "eget arbejde" er meget relativt; enhver erfaren udvikler kan akkumulere tusindvis af linjer kode fra sine gamle projekter i sin første commit. Og vil dette være en på forhånd forberedt udvikling? Men under alle omstændigheder gælder reglen, som jeg udtrykte i form af et berømt meme:
For at vinde skal du have noget, en form for konkurrencefordel: et lignende projekt, som du lavede tidligere, viden og erfaring inden for et specifikt emne eller et færdigt arbejde udført før starten af hackathonet. Ja, det er ikke sport. Ja, det er måske ikke indsatsen værd (her bestemmer alle selv, om det er værd at kode i 3 uger om natten til en præmie på 100, fordelt på hele holdet, og endda med risiko for ikke at få det). Men ofte er dette den eneste chance for at komme videre.
3. Holdvalg. Som jeg bemærkede i hackathon-chat, nærmer mange sig dette problem ret useriøst (selvom dette er den vigtigste beslutning, der vil bestemme dit resultat ved hackathonet). På mange aktivitetsområder (både i sport og i hackathons) har jeg set, at stærke mennesker har en tendens til at forene sig med de stærke, de svage med de svage, de kloge med de kloge, ja, generelt forstår du ideen... Dette er nogenlunde, hvad der sker i chats: mindre stærke programmører, de bliver straks snappet op, folk, der ikke har nogen færdigheder, der er værdifulde for et hackathon, hænger i chatten i lang tid og vælger et hold ud fra princippet om, at hvis bare nogen ville tage det . Ved nogle hackathons øves tilfældig tildeling af hold, og arrangørerne hævder, at tilfældige hold ikke præsterer dårligere end de eksisterende. Men ifølge mine observationer finder motiverede mennesker som regel et hold på egen hånd; hvis nogen skal tildeles, så kommer mange af dem ofte ikke til hackathonet.
Med hensyn til sammensætningen af teamet er dette meget individuelt og meget afhængig af opgaven. Jeg kunne sige, at den mindste levedygtige teamsammensætning er en designer - front-end eller front-end - back-end. Men jeg kender også til tilfælde, hvor teams, der kun består af front-enders, vandt, som tilføjede en simpel back-end i node.js eller lavede en mobilapplikation i React Native; eller kun fra backenders, der lavede simpelt layout. Generelt er alt meget individuelt og afhænger af opgaven. Min plan for at vælge et hold til hackathon var som følger: Jeg planlagde at samle et hold eller slutte mig til et hold som front-end - back-end - designer (jeg er selv front-end). Og ret hurtigt begyndte jeg at chatte med en python-backender og en designer, der tog imod invitationen til at slutte sig til os. Lidt senere sluttede en pige, en forretningsanalytiker, som allerede havde erfaring med at vinde et hackathon, sig til os, og dette afgjorde spørgsmålet om, at hun sluttede sig til os. Efter et kort møde besluttede vi at kalde os U4 (URBAN 4, urban fire) i analogi med de fantastiske fire. Og de satte endda et tilsvarende billede på avataren på vores telegramkanal.
4. Valg af en opgave. Som jeg allerede har sagt, skal du have en konkurrencefordel, opgaven til hackathon er udvalgt ud fra dette. Baseret på dette, efter at have kigget og vurderer deres kompleksitet, besluttede vi os for to opgaver: et katalog over innovative virksomheder fra DPiIR og en chatbot fra EFKO. Opgaven fra DPIiR er valgt af backender, opgaven fra EFKO er valgt af mig, pga. havde erfaring med at skrive chatbots i node.js og DialogFlow. EFKO-opgaven involverede også ML, jeg har en del, ikke særlig omfattende, erfaring med ML. Og i henhold til betingelserne for problemet forekom det mig, at det var usandsynligt, at det ville blive løst ved hjælp af ML-værktøjer. Denne følelse blev forstærket, da jeg var til Urban Tech Challenge meetup, hvor arrangørerne viste mig et datasæt på EFKO, hvor der var omkring 100 billeder af produktlayouts (taget fra forskellige vinkler) og omkring 20 klasser af layoutfejl. Og samtidig ønskede de, der bestilte opgaven at opnå en klassificeringssuccesrate på 90 %. Som et resultat udarbejdede jeg en præsentation af løsningen uden ML, backenderen udarbejdede en præsentation baseret på kataloget, og sammen, efter at have afsluttet præsentationerne, sendte vi dem til Urban Tech Challenge. Allerede på dette stadium blev motivations- og bidragsniveauet for hver deltager afsløret. Vores designer deltog ikke i diskussionerne, svarede sent og udfyldte endda oplysninger om sig selv i præsentationen i sidste øjeblik, generelt opstod der tvivl.
Det resulterede i, at vi bestod opgaven fra DPiIR, og var slet ikke kede af, at vi ikke bestod EFKO, da opgaven mildest talt forekom os underlig.
5. Forberedelse til hackathon. Da det endelig blev kendt, at vi havde kvalificeret os til hackathon, begyndte vi at forberede forberedelsen. Og her er jeg ikke fortaler for at begynde at skrive kode en uge før starten af hackathonet. Som minimum bør du have en kedelplade klar, som du straks kan begynde at arbejde med, uden at skulle konfigurere værktøjer og uden at støde ind i fejl af en eller anden lib, som du besluttede at prøve for første gang ved et hackathon. Jeg kender en historie om kantede ingeniører, der kom til et hackathon og brugte 2 dage på at opsætte projektet, så alt burde være forberedt på forhånd. Vi havde til hensigt at fordele ansvaret som følger: Backenderen skriver crawlere, der gennemsøger internettet og lægger al den indsamlede information i databasen, mens jeg skriver en API i node.js, der forespørger på denne database og sender dataene til fronten. I denne forbindelse forberedte jeg en server på forhånd ved hjælp af express.js og forberedte en front-end i react. Jeg bruger ikke CRA, jeg tilpasser altid webpack til mig selv, og jeg ved godt, hvilke risici dette kan udgøre (husk historien om kantede udviklere). På dette tidspunkt anmodede jeg om grænsefladeskabeloner eller i det mindste mockups fra vores designer for at få en idé om, hvad jeg ville lave. I teorien skulle han også lave sine egne forberedelser og koordinere dem med os, men jeg fik aldrig noget svar. Som følge heraf lånte jeg designet fra et af mine gamle projekter. Og det begyndte at fungere endnu hurtigere, da alle stile til dette projekt allerede var skrevet. Deraf konklusionen: en designer er ikke altid nødvendig på et team))). Vi kom til hackathon med denne udvikling.
6. Arbejde ved hackathon. Første gang jeg så mit hold live, var kun ved åbningen af hackathonet i Central Distribution Center. Vi mødtes, diskuterede løsningen og stadier af arbejdet med problemet. Og selv om vi efter åbningen skulle med bus til Røde Oktober, gik vi hjem for at sove, og blev enige om at ankomme til stedet kl. 9.00. Hvorfor? Arrangørerne ønskede tilsyneladende at få mest muligt ud af deltagerne, så de arrangerede netop sådan et skema. Men efter min erfaring kan du kode normalt uden at sove i en nat. Hvad angår den anden, er jeg ikke længere sikker. Et hackathon er et maraton; du skal beregne og planlægge din styrke tilstrækkeligt. Desuden havde vi forberedelser.
Derfor, efter at have sovet ud, sad vi klokken 9.00 på sjette sal i Dewocracy. Så annoncerede vores designer uventet, at han ikke havde en bærbar computer, og at han ville arbejde hjemmefra, og vi ville kommunikere via telefon. Dette var dråben. Og så vendte vi fra en firer til en treer, selvom vi ikke ændrede holdnavnet. Igen var dette ikke et stort slag for os; jeg havde allerede designet fra det gamle projekt. Generelt gik alt i starten ganske glat og efter planen. Vi indlæste i databasen (vi besluttede at bruge neo4j) et datasæt af innovative virksomheder fra arrangørerne. Jeg startede med at skrive, tog så node.js op, og så begyndte tingene at gå galt. Jeg havde aldrig arbejdet med neo4j før, og først ledte jeg efter en fungerende driver til denne database, så fandt jeg ud af, hvordan man skriver en forespørgsel, og så blev jeg overrasket over at opdage, at denne database, når den forespørges, returnerer entiteter i form af et array af nodeobjekter og deres kanter. De der. da jeg anmodede om en organisation og alle data på den af TIN, i stedet for ét organisationsobjekt, blev jeg returneret en lang række objekter, der indeholdt data om denne organisation og relationerne mellem dem. Jeg skrev en mapper, der gik gennem hele arrayet og limede alle objekterne i henhold til deres organisation til ét objekt. Men i kamp, når man anmodede om en database med 8 tusinde organisationer, blev den udført ekstremt langsomt, omkring 20 - 30 sekunder. Jeg begyndte at tænke på optimering... Og så stoppede vi i tide og skiftede til MongoDB, og det tog os omkring 30 minutter. I alt gik der ca. 4 timer tabt på neo5j.
Husk, tag aldrig teknologi til et hackathon, som du ikke er bekendt med, der kan være overraskelser. Men generelt, bortset fra denne fiasko, gik alt efter planen. Og allerede om morgenen den 9. december havde vi en fuldt fungerende ansøgning. Resten af dagen planlagde vi at tilføje yderligere funktioner til det. I fremtiden gik alt relativt glat for mig, men backenderen havde en hel masse problemer med forbuddet af sine crawlere i søgemaskiner, i spam fra aggregatorer af juridiske enheder, som kom på de første steder i søgeresultaterne, når de anmodede for hver enkelt virksomhed. Men det er bedre for ham selv at fortælle om det. Den første ekstra funktion, jeg tilføjede, var søgning efter fulde navn. Generaldirektør for VKontakte. Det tog flere timer.
Så på virksomhedens side i vores ansøgning dukkede en avatar af generaldirektøren op, et link til hans VKontakte-side og nogle andre data. Det var et godt kirsebær på kagen, selvom det måske ikke gav os sejren. Så ville jeg køre nogle analyser. Men efter en lang søgning af muligheder (der var mange nuancer med brugergrænsefladen), besluttede jeg mig for den enkleste sammenlægning af organisationer efter økonomisk aktivitetskode. Allerede om aftenen, i de sidste timer, var jeg ved at lave en skabelon til visning af innovative produkter (i vores applikation skulle der være en Produkter og Tjenester sektion), selvom backend ikke var klar til dette. Samtidig svulmede databasen med stormskridt, crawlerne fortsatte med at arbejde, backenderen eksperimenterede med NLP for at skelne innovative tekster fra ikke-innovative))). Men tiden for den endelige præsentation nærmede sig allerede.
7. Præsentation. Af egen erfaring kan jeg sige, at du bør skifte til at forberede en præsentation cirka 3 til 4 timer før den skal. Især hvis det involverer video, tager dets optagelse og redigering ret meget tid. Vi skulle have en video. Og vi havde en særlig person, der beskæftigede os med dette, og også løste en række andre organisatoriske problemer. I denne henseende distraherede vi ikke os selv fra kodning indtil allersidste øjeblik.
8. Pitch. Jeg kunne ikke lide, at præsentationerne og finalerne blev afholdt på en separat hverdag (mandag). Her fortsatte højst sandsynligt arrangørernes politik med at presse det maksimale ud af deltagerne. Jeg havde ikke tænkt mig at tage fri fra arbejde, jeg ville kun komme til finalen, selvom resten af mit hold tog fri. Men den følelsesmæssige fordybelse i hackathonet var allerede så høj, at jeg kl. 8 skrev i chatten på mit team (arbejdsteamet, ikke hackathonholdet), at jeg tog dagen for egen regning og gik til den centrale kontor for pladser. Vores problem viste sig at have en masse rene data scientists, og det påvirkede i høj grad tilgangen til at løse problemet. Mange havde en god DS, men ingen havde en fungerende prototype, mange kunne ikke komme uden om deres crawlers forbud i søgemaskiner. Vi var det eneste team med en fungerende prototype. Og vi vidste, hvordan vi skulle løse problemet. Til sidst vandt vi banen, selvom vi var meget heldige, at vi valgte den mindst konkurrencedygtige opgave. Da vi så på pladserne i andre baner, indså vi, at vi ikke ville have nogen chance der. Jeg vil også sige, at vi var meget heldige med juryen, de tjekkede omhyggeligt koden. Og efter anmeldelserne at dømme skete dette ikke i alle spor.
9. Finale. Efter at vi flere gange var blevet kaldt til juryen til en kodegennemgang, troede vi, at vi endelig havde løst alle problemerne, og spiste frokost på Burger King. Der ringede arrangørerne til os igen, vi måtte hurtigt pakke vores ordrer og gå tilbage.
Arrangøren viste os, hvilket rum vi skulle ind i, og da vi kom ind, befandt vi os i en talertræning for de vindende hold. De fyre, der skulle optræde på scenen, var godt ladet, alle kom ud som rigtige showmen.
Og jeg må indrømme, at vi i finalen, på baggrund af de stærkeste hold fra andre baner, så blege ud; sejren i regeringens kundenominering gik ganske fortjent til holdet fra ejendomsteknikbanen. Jeg tror, at nøglefaktorerne, der bidrog til vores sejr på banen, var: tilgængeligheden af et færdiglavet emne, på grund af hvilket vi hurtigt var i stand til at lave en prototype, tilstedeværelsen af "højdepunkter" i prototypen (søg efter administrerende direktører på sociale netværk) og vores backenders NLP-færdigheder, hvilket også interesserede juryen meget.
Og afslutningsvis, traditionel tak til alle dem, der støttede os, juryen på vores bane, Evgeniy Evgrafiev (forfatteren af problemet, som vi løste ved hackathonet) og selvfølgelig arrangørerne af hackathonet. Dette var måske det største og fedeste hackathon jeg nogensinde har deltaget i, jeg kan kun ønske gutterne at holde så høj en standard i fremtiden!
Kilde: www.habr.com