Jag heter Dmitry. Och jag vill prata om hur vårt team nådde finalen i Urban Tech Challenge hackathon på Big Data-banan. Jag ska genast säga att detta inte är det första hackathon jag deltog i, och inte det första jag tog priser i. I detta avseende vill jag i min berättelse uttrycka några allmänna observationer och slutsatser om hackathonbranschen som helhet, och ge min synpunkt i motsats till de negativa recensionerna som dök upp online direkt efter slutet av Urban Tech Challenge (för exempel ).
Så först några allmänna iakttagelser.
1. Det är förvånande att ganska många människor naivt tror att ett hackathon är någon form av sporttävling där de bästa kodarna vinner. Detta är fel. Jag överväger inte fall när hackathon-arrangörer själva inte vet vad de vill (jag har också sett det). Men som regel strävar företaget som anordnar ett hackathon efter sina egna mål. Deras lista kan vara annorlunda: det kan vara en teknisk lösning på vissa problem, ett sökande efter nya idéer och människor, etc. Dessa mål bestämmer ofta evenemangets format, tidpunkt, online/offline, hur uppgifterna kommer att formuleras (och om de överhuvudtaget kommer att formuleras), om det kommer att bli en kodgranskning på hackathon, etc. Både lagen och vad de gjorde bedöms utifrån denna synvinkel. Och de lag som bäst träffar den punkt företaget behöver vinner, och många kommer till denna punkt helt omedvetet och av misstag och tror att de verkligen deltar i en sporttävling. Mina observationer visar att för att motivera deltagarna bör arrangörer åtminstone skapa en idrottsmiljö och lika villkor, annars kommer de att få en våg av negativitet, som i ovanstående recension. Men vi avviker.
2. Därav följande slutsats. Arrangörerna är intresserade av att deltagare kommer till hackathonet med sitt eget arbete, ibland anordnar de till och med speciellt en korrespondensscen online för detta ändamål. Detta möjliggör starkare utgångslösningar. Begreppet "eget arbete" är mycket relativt; alla erfaren utvecklare kan samla tusentals rader kod från sina gamla projekt i sin första commit. Och kommer detta att vara en förberedd utveckling? Men i alla fall gäller regeln, vilket jag uttryckte i form av ett berömt meme:
För att vinna måste du ha något, någon form av konkurrensfördel: ett liknande projekt som du gjorde tidigare, kunskap och erfarenhet inom ett specifikt ämne, eller ett färdigt arbete gjort innan hackathonet startade. Ja, det är inte sportigt. Ja, det här kanske inte är värt ansträngningen (här bestämmer var och en själv om det är värt att koda i 3 veckor på natten för ett pris på 100 tusen, fördelat på hela laget, och även med risken att inte få det). Men ofta är detta den enda chansen att ta sig framåt.
3. Lagval. Som jag märkte i hackathon-chattar, närmar sig många denna fråga ganska oseriöst (även om detta är det viktigaste beslutet som kommer att avgöra ditt resultat på hackathon). Inom många verksamhetsområden (både inom idrott och hackathon) har jag sett att starka människor tenderar att förenas med de starka, de svaga med de svaga, de smarta med de smarta, ja, i allmänhet förstår du... Det här är ungefär vad som händer i chattar: mindre starka programmerare blir de omedelbart snappade upp, människor som inte har några kunskaper värdefulla för ett hackathon hänger länge i chatten och väljer ett lag på principen att om bara någon skulle ta det . Vid vissa hackathon tränas slumpmässiga tilldelningar till lag, och arrangörerna hävdar att slumpmässiga lag inte presterar sämre än befintliga. Men enligt mina observationer hittar motiverade människor som regel ett lag på egen hand; om någon måste tilldelas, kommer ofta många av dem inte till hackathon.
När det gäller sammansättningen av teamet är detta väldigt individuellt och mycket beroende av uppgiften. Jag skulle kunna säga att den minsta genomförbara teamsammansättningen är en designer - front-end eller front-end - back-end. Men jag känner också till fall då team som bara bestod av front-endrar vann, som lade till en enkel back-end i node.js, eller gjorde en mobilapplikation i React Native; eller bara från backenders som gjorde enkel layout. I allmänhet är allt väldigt individuellt och beror på uppgiften. Min plan för att välja ett lag för hackathon var följande: Jag planerade att sätta ihop ett team eller gå med i ett team som front-end - back-end - designer (jag är själv en front-end). Och ganska snabbt började jag chatta med en pythonbackender och en designer som tackade ja till inbjudan att gå med oss. Lite senare anslöt sig en tjej, en affärsanalytiker, som redan hade erfarenhet av att vinna ett hackathon, och detta avgjorde frågan om att hon skulle gå med oss. Efter ett kort möte bestämde vi oss för att kalla oss U4 (URBAN 4, urban fyra) i analogi med den fantastiska fyran. Och de satte till och med en motsvarande bild på avataren på vår telegramkanal.
4. Välja en uppgift. Som jag redan sa så måste du ha en konkurrensfördel, uppgiften för hackathon väljs utifrån detta. Baserat på detta, efter att ha tittat och utvärderade deras komplexitet, bestämde vi oss för två uppgifter: en katalog över innovativa företag från DPiIR och en chatbot från EFKO. Uppgiften från DPIiR valdes av backendern, uppgiften från EFKO valdes av mig, eftersom hade erfarenhet av att skriva chatbots i node.js och DialogFlow. EFKO-uppdraget involverade även ML, jag har viss, inte särskilt omfattande, erfarenhet av ML. Och enligt villkoren för problemet verkade det för mig att det var osannolikt att det skulle lösas med ML-verktyg. Denna känsla förstärktes när jag gick på Urban Tech Challenge meetup, där arrangörerna visade mig ett dataset på EFKO, där det fanns cirka 100 bilder av produktlayouter (tagna från olika vinklar) och cirka 20 klasser av layoutfel. Och samtidigt ville de som beställde uppgiften uppnå en klassificeringsgrad på 90 %. Som ett resultat förberedde jag en presentation av lösningen utan ML, backendern förberedde en presentation baserad på katalogen och tillsammans, efter att ha avslutat presentationerna, skickade vi dem till Urban Tech Challenge. Redan i detta skede avslöjades graden av motivation och bidrag från varje deltagare. Vår designer deltog inte i diskussionerna, svarade sent och fyllde till och med i information om sig själv i presentationen i sista stund, i allmänhet uppstod tvivel.
Som ett resultat klarade vi uppgiften från DPiIR, och var inte alls upprörda över att vi inte klarade EFKO, eftersom uppgiften verkade konstigt för oss, för att uttrycka det milt.
5. Förberedelser inför hackathon. När det äntligen blev känt att vi kvalificerat oss till hackathon började vi förbereda förberedelserna. Och här förespråkar jag inte att börja skriva kod en vecka innan hackathonstart. Som ett minimum bör du ha en pannplatta redo, med vilken du omedelbart kan börja arbeta, utan att behöva konfigurera verktyg och utan att stöta på buggar av något lib som du bestämde dig för att prova för första gången på ett hackathon. Jag vet en historia om kantiga ingenjörer som kom till ett hackathon och tillbringade 2 dagar med att sätta upp projektbygget, så allt borde vara förberett i förväg. Vi hade för avsikt att fördela ansvaret enligt följande: backendern skriver sökrobotar som letar igenom internet och lägger all insamlad information i databasen, medan jag skriver ett API i node.js som frågar denna databas och skickar data till fronten. I detta avseende förberedde jag en server i förväg med hjälp av express.js och förberedde en front-end i react. Jag använder inte CRA, jag anpassar alltid webpack för mig själv och jag vet mycket väl vilka risker detta kan innebära (kom ihåg historien om kantiga utvecklare). Vid det här laget begärde jag gränssnittsmallar eller åtminstone mockups från vår designer för att få en uppfattning om vad jag skulle lägga ut. I teorin borde han också göra sina egna förberedelser och samordna dem med oss, men jag fick aldrig något svar. Som ett resultat lånade jag designen från ett av mina gamla projekt. Och det började fungera ännu snabbare, eftersom alla stilar för det här projektet redan hade skrivits. Därav slutsatsen: en designer behövs inte alltid i ett team))). Vi kom till hackathon med den här utvecklingen.
6. Jobba på hackathon. Första gången jag såg mitt lag live var bara vid öppningen av hackathonet på Central Distribution Center. Vi träffades, diskuterade lösningen och stadierna av arbetet med problemet. Och även om vi efter öppningen var tvungna att åka buss till Red October, gick vi hem för att sova och kom överens om att vara framme vid 9.00. Varför? Arrangörerna ville tydligen få ut så mycket som möjligt av deltagarna så de ordnade just ett sådant schema. Men enligt min erfarenhet kan du koda normalt utan att sova en natt. När det gäller den andra är jag inte längre säker. Ett hackathon är ett maraton, du måste beräkna och planera din styrka tillräckligt. Dessutom hade vi förberedelser.
Därför, efter att ha sovit bort, klockan 9.00 satt vi på sjätte våningen i Dewocracy. Då meddelade vår designer oväntat att han inte hade en bärbar dator och att han skulle jobba hemifrån och att vi skulle kommunicera via telefon. Detta var droppen. Och så vände vi från en fyra till en trea, även om vi inte ändrade lagnamnet. Återigen, detta var inte ett stort slag för oss, jag hade redan designen från det gamla projektet. I allmänhet gick allt till en början ganska smidigt och enligt plan. Vi laddade in i databasen (vi bestämde oss för att använda neo4j) en datauppsättning av innovativa företag från arrangörerna. Jag började skriva, tog upp node.js och sedan började saker och ting att misslyckas. Jag hade aldrig arbetat med neo4j förut, och först letade jag efter en fungerande drivrutin för den här databasen, sedan kom jag på hur man skriver en fråga, och sedan blev jag förvånad över att upptäcka att den här databasen, när den frågas, returnerar entiteter i form av en array av nodobjekt och deras kanter. De där. När jag begärde en organisation och all information om den av TIN, istället för ett organisationsobjekt, fick jag tillbaka en lång rad objekt som innehöll data om denna organisation och relationerna mellan dem. Jag skrev en kartläggare som gick igenom hela arrayen och limmade alla objekt enligt deras organisation till ett objekt. Men i strid, när man begärde en databas med 8 tusen organisationer, utfördes den extremt långsamt, cirka 20 - 30 sekunder. Jag började fundera på optimering... Och sedan stannade vi i tid och bytte till MongoDB, och det tog oss cirka 30 minuter. Totalt gick ca 4 timmar förlorade på neo5j.
Kom ihåg, ta aldrig tekniken till ett hackathon som du inte är bekant med, det kan bli överraskningar. Men i allmänhet, bortsett från detta misslyckande, gick allt enligt planerna. Och redan på morgonen den 9 december hade vi en fullt fungerande ansökan. Under resten av dagen planerade vi att lägga till ytterligare funktioner till den. I framtiden gick allt relativt smidigt för mig, men backendern hade en hel massa problem med förbudet av sina sökrobotar i sökmotorer, i skräpposten från sammanställare av juridiska personer, som kom på de första platserna i sökresultaten när de begärde för varje specifikt företag. Men det är bättre för honom att berätta om det själv. Den första extra funktionen jag lade till var sök med fullständigt namn. Generaldirektör för VKontakte. Det tog flera timmar.
Så på företagets sida i vår ansökan dök en avatar av generaldirektören upp, en länk till hans VKontakte-sida och lite annan information. Det var ett gott körsbär på kakan, även om det kanske inte gav oss vinsten. Sedan ville jag köra lite analyser. Men efter en lång sökning av alternativ (det fanns många nyanser med användargränssnittet), bestämde jag mig för den enklaste aggregeringen av organisationer efter ekonomisk aktivitetskod. Redan på kvällen, under de senaste timmarna, höll jag på att lägga ut en mall för att visa innovativa produkter (i vår applikation ska det finnas en avdelning för produkter och tjänster), även om backend inte var redo för detta. Samtidigt svällde databasen med stormsteg, sökrobotarna fortsatte att arbeta, backendern experimenterade med NLP för att skilja innovativa texter från icke-innovativa))). Men tiden för slutpresentationen närmade sig redan.
7. Presentation. Av egen erfarenhet kan jag säga att du bör gå över till att förbereda en presentation cirka 3 till 4 timmar innan den ska. Speciellt om det handlar om video tar det ganska lång tid att fotografera och redigera. Vi skulle ha en video. Och vi hade en speciell person som sysslade med detta, och även löste en rad andra organisatoriska frågor. I detta avseende distraherade vi inte oss själva från kodning förrän i sista stund.
8. Pitch. Jag gillade inte att presentationerna och finalerna hölls på en separat vardag (måndag). Här fortsatte med största sannolikhet arrangörernas policy att pressa ut maximalt av deltagarna. Jag tänkte inte ta ledigt från jobbet, jag ville bara komma till finalen, även om resten av mitt lag tog ledigt. Men den känslomässiga fördjupningen i hackathonet var redan så hög att jag klockan 8 skrev i chatten för mitt team (arbetsteamet, inte hackathonteamet) att jag tog dagen på egen bekostnad och gick till centralen kontor för ställplatser. Vårt problem visade sig ha många rena datavetare, och detta påverkade i hög grad hur vi skulle lösa problemet. Många hade en bra DS, men ingen hade en fungerande prototyp, många kunde inte komma runt förbuden av sina sökrobotar i sökmotorer. Vi var det enda teamet med en fungerande prototyp. Och vi visste hur vi skulle lösa problemet. Till slut vann vi banan, även om vi hade väldigt tur att vi valde den minst konkurrenskraftiga uppgiften. När vi tittade på planerna i andra banor insåg vi att vi inte skulle ha någon chans där. Jag vill också säga att vi hade mycket tur med juryn, de kontrollerade noggrant koden. Och, att döma av recensionerna, hände detta inte i alla spår.
9. Final. Efter att vi kallats till juryn flera gånger för en kodgranskning, tänkte vi att vi äntligen hade löst alla problem, och åt lunch på Burger King. Dit ringde arrangörerna oss igen, vi fick snabbt packa våra beställningar och åka tillbaka.
Arrangören visade oss vilket rum vi behövde gå in i, och när vi kom in befann vi oss på en träning för att tala inför de vinnande lagen. Killarna som skulle uppträda på scenen var bra laddade, alla kom ut som riktiga showmen.
Och jag måste erkänna, i finalen, mot bakgrund av de starkaste lagen från andra banor, såg vi bleka ut, segern i regeringens kundnominering gick helt välförtjänt till laget från fastighetsteknikbanan. Jag tror att nyckelfaktorerna som bidrog till vår seger på banan var: tillgängligheten av ett färdigt ämne, på grund av vilket vi snabbt kunde göra en prototyp, närvaron av "höjdpunkter" i prototypen (sök efter VD:ar) på sociala nätverk) och NLP-kunskaperna hos vår backender, vilket också mycket intresserade juryn.
Och avslutningsvis, traditionellt tack till alla som stöttat oss, juryn för vår bana, Evgeniy Evgrafiev (författaren till problemet som vi löste på hackathonet) och naturligtvis arrangörerna av hackathonet. Det här var kanske det största och coolaste hackathon jag någonsin deltagit i, jag kan bara önska att killarna håller en så hög standard i framtiden!
Källa: will.com