🥇Koda–pizza | ProHoster

Hej, Habr. Vi genomförde spontant vår första interna hackathon. Jag ville dela med mig av mina smärtor och insikter om förberedelserna under två veckor, samt de projekt som kom till stånd.

Tråkiga delen för dem som är intresserade av marknadsföring

Jag börjar med en liten historia.

Början av april. På vårt kontor pågår den första hackathonen för MskDotNet Community. Slaget om Tatooine är i full gång, i vår galax den här gången. Lördag. 20 lag. Pizza. Allt är mycket gemytligt (bevis). En uppblåsbar R2-D2 syns i rummet. Lag skriver de mest korrekta algoritmerna för att klara av det farligaste loppet på kartan. Vi skjuter på starten för de första loppen. Kakor och kaffe räddar oss. Vi, arrangörerna, trodde att många skulle gå hem efter lunch på lördagen. Men nej. 12 timmar kodning bakom oss. Finalen. Något faller bort, något startar inte. Men alla är glada. Vårt lag vinner. Vi är glada dubbelt.

Jag delar glädjen i Slack och får en idé: "Vi måste göra vår egen hackathon". Jag skriver till vår CTO Sasja. Tystnad.

Morgon. Jag dricker kaffe på kontoret. Jag ser Sasja närma sig bakifrån. "Liza, det här är utmärkt! Vi har precis den 21 april en viktig datum. Låt oss göra det!" Vad!? Så snabbt? Va? Jag måste flyga till Syktyvkar för praktik i mitten av april. Men skit i det! Låt oss köra.

Två veckor kvar. Jag har aldrig varit ensam arrangör av en hackathon. Även om det är en intern. Jag läser artiklar om det. Hep. Det krävs flera månader. Det krävs flera personer. Man måste tänka på merch, priser, förutsättningar, schema, intressera, förstå syftet, budgetar. Kanske till och med gräva i livets mening. Jag kommer definitivt inte att hinna. Och medan du läste och förberedde dig har redan en vecka gått. Det är hög tid att sluta läsa artiklar och börja göra något.

Här är vår checklist för att arrangera en intern hackathon på en vecka

Plan: sätt dig lugnt ner och skriv en lista över vad som måste göras för hackathonen. 30 minuter.
Uppgift: deltagarna föreslår själva och väljer projekt de vill skapa i Google Sheets. Bakgrundsuppgift, 2 timmar.
Schema: skriver snabbt en kort tidsplan med hänsyn till 3 pauser och finalen. 20 minuter.
Kommandon: publicera meddelandet om hackathonen med schemat från CTO i IT-kanaler i Slack/e-post/etc och skapa en separat kanal för hackathonen. I den delar alla upp sig i lag, och de som är osäkra gör det inom de första 5 minuterna av hackathonen. Bakgrundsuppgift, 2 timmar.
Fördelar: du kommer på merch med två utvecklare, ger det till designern för illustration, får det klart. Bakgrundsuppgift, 3 dagar.
Hackathon: du kommer till kontoret, koordinerar alla i början, sysslar med dina grejer, läser Reddit, med ett viktigt uttryck meddelar du varje paus om ny pizza, fotograferar solnedgången, annonserar finalen, röstar tillsammans och väljer vinnaren. 1 dag.
Under stjärnorna: självklart tänker du hela tiden på att allt ska gå bra. Självklart får inte alla se ditt meddelande och med vissa är det bättre att prata personligen. Självklart, om någon hjälper dig, blir allt dubbelt så enkelt (jag fick fantastisk hjälp av Alena).

Mindre tråkig del om hackathonets datum

Varför den 21 april? Denna dag är viktig för oss. Exakt ett år sedan, den 21 april, kollapsade vi under belastning under de första helgerna efter starten av den Federala Reklamekampanjen. Dagen efter, på söndagen, var vårt team på jobbet från klockan 8 på morgonen. Då skapade vi en Trello-tavla som hette sundayhackathon och veckan av 12 timmars skiftarbete började. Situationen var så kritisk att vi inte ens hade tid att äta och andra team matade oss.

En mer detaljerad berättelse kan du läsa på Fjodor Ovtsjinnikovs sida (vår CEO). Sedan dess har vi förändrat mycket, men datumet kommer vi definitivt inte att glömma.

I år bestämde vi oss för att detta evenemang förtjänar att bli ihågkommet och i bästa tradition arrangerade vi det första interna hackathonet i Dodo-historien som pågick i 10 timmar.

Den mest spännande delen om hackathonprojekten

Disclaimer: alla beskrivningar skrevs av killarna själva, så textens författarskap är inte mitt.

Oleg Learning (maskininlärning)

Dima Kochnev, Sasha Andronov (@alexandronov)

Vi ville skapa ett neuronnät som kunde avgöra vilken pizza som fanns på fotot utan några förkunskaper. Slutresultatet blev en väldigt enkel och leksaksliknande – den känner igen 10 olika pizzor, vi fick en ungefärlig förståelse för hur allt fungerar, så långt det är möjligt på en dag (~10 timmar).

Specifikt förstod vi att industrin har nått en nivå där en vanlig utvecklare kan ta färdiga bibliotek, läsa dokumentationen och träna sitt neuronnät utan djupgående ämneskunskaper. Och det fungerar tillräckligt bra för att lösa verkliga problem.

Verktygen som användes:

imageai — ett bekvämt och enkelt bibliotek för arbete med maskininlärning och datorseende.
Vi testade två modeller – ResNet50, Yolo.
Koden skrevs, förstås, i Python.

Vi hade 11000 bilder, men bland dem visade sig nästan 3/4 vara skräp, och bland de återstående var det olika, olämpliga vinklar. Så småningom använde vi en färdig modell (som bara kan hitta pizza) och med dess hjälp sorterade vi ut det mest usla. Dessutom, i bildens namn fanns namnet på pizzan — så vi delade upp dem i mappar, men det visade sig att namnen inte överensstämde med verkligheten och här fick vi hålla på och rensa för hand. I slutändan återstod cirka 500-600 bilder, det är uppenbart att detta är en försvinnande liten mängd, men ändå var det tillräckligt för att särskilja 10 pizzor från varandra.

För att träna nätverket använde vi den billigaste virtuella maskinen i Azure på NVIDIA Tesla K80. Vi tränade den i 100 epoker, men det var tydligt att nätverket översvämmat redan efter 50 epoker, på grund av att datasetet var litet.

Problemet ligger helt enkelt i bristen på bra data.

Vi kanske blandade ihop termerna lite, men man måste ta hänsyn till att vi överhuvudtaget inte har någon erfarenhet av att arbeta med allt detta.

GUI för NOOBS (terminal för att beställa pizza)

Misha Kumachev (Ceridan), Zhenya Bikinin, Zhenya Vasiliev

Vi byggde en prototyp av en konsolapplikation för nördar, som gör att man kan beställa pizza via terminalen eller kommandoraden, eller till och med integrera den i deploy-pipelinen och vid framgångsrik release leverera pizza till kontoret.

Arbetet delades upp i flera delar: vi hade problem med att förstå hur vår API för mobilappar var uppbyggd, vi samlade vårt eget CLI med hjälp av oclif och konfigurerade publiceringen av vårt skapade paket. Den senaste uppgiften var relaterad till några obehagliga minuter nära slutet av hackathonet. Allt fungerade lokalt och till och med äldre publicerade versioner av paketet fungerade, men de nya (där fler coola funktioner och emojis lades till) ville inte fungera. Vi spenderade ungefär 40 minuter för att förstå vad som hade gått fel, men till slut fungerade allt magiskt av sig själv).

Vårt maxmål för hackathonet var att göra en verklig pizzaorder till kontoret via vårt CLI. Vi testade det flera gånger på testservern, men jag var fortfarande nervös när jag skrev in kommandon på produkten.

Som resultat – vi gjorde det faktiskt!

CourierGo

Anton Bruzhmelëv (författare), Vanya Zverev, Gleb Lesnikov (entropy), Andrey Sarafanov

Vi tog idén "App för kuriren".

Bakgrundshistorien om förberedelserna.Jag började med att tänka på vilka funktioner som kan finnas i appen? Det blev ungefär en sådan lista med funktioner:

Appen loggar in i leveranssystemet med en kod.
I appen syns omedelbart tillgängliga beställningar, de beställningar som måste hämtas.
Kuriren markerar beställningen och tar den med på resan.
Han får se beräknad tid och om han hinner eller inte.
Kunden ser att kuriren har gett sig av.
Kunden börjar se kurirens position på kartan och beräknad tid.
Kuriren kan skriva till kunden i chatten från appen.
Kunden kan skriva till kuriren i chatten från appen.
Fem minuter innan ankomst får kunden ett meddelande att kuriren är nära, var beredd.
Kuriren markerar i appen att han har anlänt och väntar.
Kuriren kan ringa från appen med ett klick och informera att (han kommit, är på väg, etc.)
Kunden accepterar beställningen och anger pin-koden från appen eller SMS för att bekräfta leveransen. (som ett digitalt kvitto) Så att kuriren inte kan avsluta leveransen i förväg om han är sen.
Beställningen markeras som levererad i systemet.

Plus ett par alternativa scenarier:

Kuriren kan markera beställningen som ej levererad och välja anledning.
Kuriren kan, vid försening, skicka ett elektroniskt certifikat via SMS med ett klick. Eller så kommer certifikatet automatiskt vid överskridande av leveranstiden.

Känslan av potential och behovet av detta projekt gav verkligen energi.

Nästa dag gick vi med teamet på lunch och diskuterade hur den minimala funktionen av appen skulle se ut.

Resultatet blev följande lista över vad som skulle göras under hackathonet:

Inloggning i leveranssystemet.
Visa aktuell position.
Skicka data till extern API (koordinater, plockade beställningar, levererade beställningar).
Hämta data från extern API (aktuella beställningar för kuriren).
Skicka en händelse om att en beställning har tagits för leverans/levert.
Visa kurirens aktuella position på kartan på webbplatsen.

Huvudarbetet, som jag såg det, skulle vara att skapa backend, själva appen (efter diskussioner valde vi ReactNative för utveckling av appen, närmare bestämt ett paket ovanför det — expo.io, vilket gör att man nästan inte behöver skriva någon egen kod). När det gäller backend fanns det från början förhoppningar på Vanya Zverev, som är erfaren i arbetet med vår tjänstmall och k8s (det arbete som han tog på sig). ReactNative testade jag och Andrei Sarafanov.

Jag beslutade mig för att försöka skapa ett arbetsrepository för själva projektet direkt. Vid midnatt stötte jag på problemet att geolokalisering fungerar dåligt i bakgrunden i ReactNative utan att skriva nativ kod, vilket gjorde mig lite frustrerad. Men jag lugnade mig när jag insåg att jag läste dokumentationen för expo.io-ramverket istället för ReactNative. I slutet av kvällen förstod jag hur jag skulle få den aktuella positionen i expo.io och rita separata skärmar (för inloggning, visning av beställningar osv.).

På morgonen på hackathonet drogs Gleb in i deras superlovande projekt. De skissade snabbt upp en plan för vad som behövde göras.

Vi gjorde ett misstag när vi, enligt projektmallen, försökte kommunicera inte via HTTP utan via GRPC, eftersom ingen visste hur man skulle bygga en GRPC-klient för JavaScript. Till slut, efter att ha lagt cirka en och en halv timme på det, övergav vi den idén. På grund av detta började killarna i backend renovera den färdiga servern från GRPC till WebApi. Efter en halvtimme lyckades vi äntligen ställa in kommunikationen mellan applikationen och backend, vilket var en otrolig lättnad. Men under samma tid höll Gleb på att få klar sin deployment till k8s, plus autodeployment vid commit till master. 🙂

Som lagring valde vi MySQL för att inte riskera med databasen (vi hade tankar om CosmosDb).

Slutsatsen:

Vi implementerade sparandet av kurirens aktuella koordinater från applikationen till databasen.
Vi kopplade in RabbitMQ och anmälde oss till meddelanden om att kuriren tagit emot en beställning, för att omedelbart visa beställningen för kuriren i applikationen.
Vi började spara tiden för leverans av beställningen i vår databas, efter att kuriren tryckt på knappen i applikationen. Vi hann inte lägga till att skicka tillbaka händelsen till RabbitMQ om att beställningen var levererad.
Jag gjorde en kartvisning på sidan currentorder på webbplatsen med kurirens aktuella position. Men denna funktionalitet förblev något ofullständig, eftersom vi på miljön inte lyckades ställa in CORS för att hämta koordinater från vår nya tjänst.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Vi ville implementera en OpenID Connect-leverantör, eftersom vi för närvarande använder ett autentiseringsprotokoll av egen utveckling, vilket skapar en rad svårigheter: skräddarsydda klientbibliotek, besvärlig hantering från externa partners och eventuella säkerhetsproblem (även om OAuth2.0 och OpenID Connect i sin standardimplementation anses vara säkra, är jag osäker på vår lösning).

Vi skapade en separat tjänst som emulerar en tjänst för lagring av personuppgifter, för att skapa en liten modell av en land-agnostisk autentiseringstjänst, som skulle hämta personuppgifter från en separat tjänst (detta skulle i framtiden möjliggöra att ha en tjänst med vilken man kan logga in med ett konto i vilket land som helst, samtidigt som man följer GDPR och andra lagar). Denna del byggde vi, liksom leverantören, och kopplade dem framgångsrikt samman. Nästa steg var att göra ett API som skulle skyddas med tokens som tillhandahålls av leverantören, stödja deras introspektion via leverantören och ge ut skyddade data om förfrågan uppfyllde behörighetsvillkoren (vi verifierar att användaren är autentiserad enligt Bearer-schemat, att deras token innehåller en specifik scope + att användaren har tillståndet som tillåter anropet). Denna del genomfördes också. Den sista komponenten var en JavaScript-klient, som skulle få en token, med hjälp av vilken den skulle anropa det skyddade API:et. Denna del hann vi inte klart med. Det vill säga, hela den funktionella delen var förberedd, men den front-end del som behövdes för att demonstrera systemets funktionalitet var inte klar.

E-E-E (spel)

Dima Afontjenko, Sasha Konovalov

Vi gjorde en mini-lek på Unity där snabba händer slänger korv på pizzan. Om du slänger korven felaktigt visas en sorglig text på skärmen "Ogiltig", men om hela korven slängs korrekt dyker en slumpmässig faktum om pizza upp.

Vi ville göra en andra nivå där man slänger tomater, men hann inte.

Kort fortsättning: vem vann?

Innan hackathonet pratade vi med killarna och jag frågade vad för pris de skulle vilja ha om de vann. Det visade sig att det mest värdefulla priset skulle vara "vägen till produktion".

Därför kan ni snart förvänta er en tillkännagivande av spelet med kontrollen som kastar pepperoni på pizzan.