🥇Kodning–pizza

Hej, Habr. Vi holdt spontant den første interne hackathon. Jeg vil dele mine smerter og indsigter om forberedelsen til det over de sidste 2 uger samt de projekter, der kom ud af det.

Den kedelige del for dem, der interesserer sig for marketing

Jeg starter med en lille historie.

Det er begyndelsen af april. Vores kontor holder den første hackathon for MskDotNet Community. Kampen om Tatooine er i gang, i vores galakse denne gang. Lørdag. 20 hold. Pizza. Det hele er meget hyggeligt (beviser). En oppustelig R2-D2 svømmer rundt i lokalet. Holdene skriver de mest korrekte algoritmer for at gennemføre det mest farlige løb på kortet. Vi skyder startskuddet for de første heats. Småkager og kaffe gør underværker. Vi, arrangørerne, forventede, at mange ville gå hjem efter frokost om lørdagen. Men nej. 12 timer med kodning bag os. Finale. Noget går i stykker, noget vil ikke starte. Men alle er glade. Vores hold vinder. Vi er dobbelt så glade.

Jeg deler glæden i Slack, og en idé dukker op i mit hoved: «Vi skal holde vores egen hackathon». Jeg skriver til vores CTO Sasha. Stilhed.

Morgen. Jeg drikker kaffe på kontoret. Jeg ser Sasha nærme sig bagfra. «Liza, det er fantastisk! Vi har lige den 21. april en vigtig dato. Lad os gøre det!» WTF!? Så hurtigt? Hvad? Jeg skal rejse til Syktyvkar for et praktikophold midt i april. Men for resten! Lad os gøre det.

Der er 2 uger tilbage. Jeg har aldrig været den eneste arrangør af en hackathon. Selvom det er en intern. Jeg læser artikler om emnet. Vildt. Det kræver flere måneder. Det kræver flere personer. Jeg skal tænke over merchandise, præmier, vilkår, tidsplan, engagere folk, forstå formålet, budgetter. Måske endda finde ud af meningen med livet. Jeg vil bestemt ikke nå det. Og mens du læste og forberedte dig, er ugen allerede gået. Det er på tide at glemme artiklerne og begynde at gøre noget.

Fang vores tjekliste til afholdelse af intern hackathon på 1 uge

Plan: du sætter dig roligt ned og skriver en liste over, hvad der skal gøres til hackathon. 30 minutter.
Regler for godkendelse af merge-requests: deltagerne foreslår og vælger selv de projekter, de ønsker at oprette i Google Sheets. Baggrundsopgave, 2 timer.
Tidsplan: du skriver hurtigt en kort tidsopdeling med 3 pauser og finalen i tankerne. 20 minutter.
Kommandoer: du offentliggør en meddelelse om hackathon med tidsplanen fra CTO i IT-kanalerne i Slack/e-mail osv. og opretter en separat kanal til hackathon. Her deles alle op i hold, mens de usikre gør det i de første 5 minutter af hackathon. Baggrundsopgave, 2 timer.
Goder: du opfinder merch med to udviklere, giver det til designeren til illustration, og modtager det færdige produkt. Baggrundsopgave, 3 dage.
Hackathon: du kommer ind på kontoret, koordinerer alle i starten, arbejder med dine opgaver, læser Reddit, meddeler med et vigtigt udtryk om den nye pizza hver gang, tager billeder af solnedgangen, annoncerer finalen, og stemmer sammen på vinderen. 1 dag.
Under stjernen: selvfølgelig tænker du hele tiden på, at alt skal gå godt. Selvfølgelig vil ikke alle se din besked, og nogle skal bedre tale med personligt. Selvfølgelig, hvis nogen hjælper dig, bliver det to gange nemmere (jeg havde den fantastiske Alena til at hjælpe mig).

Den mindre kedelige del om datoen for hackathonet

Hvorfor 21. april? Denne dag er vigtig for os. Nøjagtigt et år siden, den 21. april, gik vi ned under belastning i forbindelse med de første weekenddage efter starten på den Føderale Reklamekampagne. Dagen efter, på søndag, var vores team på arbejde fra kl. 8 om morgenen. Da skabte vi en Trello-tavle sundayhackathon, og en uge med skiftende arbejde på 12 timer om dagen begyndte. Situationen var så kritisk, at vi ikke engang havde tid til at spise, og folk fra andre teams sørgede for mad til os.

Du kan læse en mere detaljeret beretning på Fjodor Ovchinnikovs side (vår CEO). Siden da har vi ændret meget, men vi vil bestemt ikke glemme denne dato.

I år besluttede vi, at dette arrangement skulle mindes af de kommende generationer, og i bedste tradition afholdt vi det første interne hackathon i Dodo, som varede 10 timer.

Den mest interessante del om hackathonprojekterne

Disclaimer: alle beskrivelser er skrevet af drengene, så forfatterretten til teksten er ikke min.

Oleg Læring (maskinlæring)

Dima Kochnev, Sasha Andronov (@alexandronov)

Vi ønskede at lave en neuralt netværk, som ville kunne identificere, hvilken pizza der var på billedet uden nogen forkundskaber. I sidste ende lavede vi en meget simpel og legetøjsagtig – det kan genkende 10 pizzaer, og vi fandt nogenlunde ud af, hvordan det hele fungerer, i hvert fald så meget som muligt på en dag (~10 timer).

Specifikt forstod vi, at industrien er nået til et punkt, hvor en almindelig udvikler kan tage færdige biblioteker, læse dokumentationen og træne sit neurale netværk uden dyb forståelse af emnet. Og det vil fungere ret godt til løsningen af reelle opgaver.

Værktøjerne, vi brugte:

imageai — et praktisk og enkelt bibliotek til arbejdet med maskinlæring og computer vision.
Vi prøvede to modeller – ResNet50, Yolo.
Koden blev, som man kan forstå, skrevet i Python.

Vi havde 11000 billeder, men næsten 3/4 viste sig at være affald, og blandt de resterende var der forskellige, uacceptable vinkler. I sidste ende tog vi en færdig model (som bare kan finde pizza) og brugte den til at adskille det værste affald. Desuden var navnet på billedet navnet på pizzaen — sådan sorteredes de i mapper, men det viste sig, at navnene ikke stemte overens med virkeligheden, og der måtte vi rydde op manuelt. I sidste ende var der omkring 500-600 billeder tilbage, hvilket helt klart er et ubetydeligt antal, men alligevel var det tilstrækkeligt til at skille 10 pizzaer fra hinanden.

Til træning af netværket brugte vi den billigste virtuelle maskine i Azure med NVIDIA Tesla K80. Vi trænede i 100 epoch, men det blev tydeligt, at netværket var blevet overmættet allerede efter 50 epoch, fordi datasættet var for lille.

Problemet ligger reelt i manglen på gode data.

Vi har måske lidt rodet med termerne, men man skal huske, at vi slet ikke har erfaring med alt dette.

GUI for NOOBS (konsollen til bestilling af pizza)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Vi samlede en prototype af et konsolapplikation for nørder, som gør det muligt at bestille pizza via terminalen eller kommandolinjen, eller endda integrere det i deployment-pipelinen og få leveret pizza til kontoret ved succesfuld udgivelse.

Arbejdet blev opdelt i flere dele: vi undersøgte, hvordan vores API til mobilapplikationer fungerede, og samlede vores egen CLI med hjælp fra oclif og satte publiceringen af vores samlede pakke op. Den sidste opgave involverede nogle ubehagelige minutter tættere på slutningen af hackathonen. Alt fungerede lokalt, og selv de gamle offentliggjorte versioner af pakken fungerede, men de nye (hvor der var tilføjet flere fede funktioner og emojis) nægtede at virke. Vi brugte 40 minutter på at finde ud af, hvad der gik galt, men i sidste ende fungerede alt magisk af sig selv).

Vores største mål til hackathonen var at foretage en reel bestilling af pizza til kontoret via vores CLI. Vi testede det en halv snes gange på testplatformen, men mine hænder rystede stadig, når jeg indtastede kommandoerne i produktionen.

Som resultat — fik vi det trods alt gjort!

CourierGo

Anton Bruzhmelëv (forfatter), Vanya Zverev, Gleb Lesnikov (entropy), Andrei Sarafanov

Vi tog ideen "App til kureren".

Baggrundsoplysninger om forberedelsen.Jeg overvejede oprindeligt, hvilke funktioner der kunne være i appen. Der opstod omtrent denne liste over funktionalitet:

Appen logger ind i leveringskassen med en kode.
I appen ses de tilgængelige ordrer med det samme, ordrer som skal tages.
Kureren markerer ordren og tager den med på turen.
Han får vist den beregnede tid og om han når det eller ej.
Klienten får vist, at kureren er afsted.
Klienten begynder at se kurers position på kortet og den beregnede tid.
Kureren kan skrive til klienten i chatten fra appen.
Klienten kan skrive til kureren i chatten fra appen.
Fem minutter før ankomsten får klienten en besked om, at kureren er tæt på, vær klar.
Kureren markerer i appen, at han er ankommet og venter.
Kureren ringer fra appen med et klik og informerer om, at han (kommer op, er ankommet osv.)
Klienten accepterer ordren og indtaster pin-koden fra appen eller SMS’en for at bekræfte leveringen. (som en signatur) Så kureren ikke kan afslutte leveringen for tidligt, hvis han er forsinket.
Ordren markeres som leveret i systemet.

Plus et par alternative scenarier:

Kureren kan markere ordren som ikke leveret og vælge årsag.
Hvis kureren er forsinket, kan han med et klik udstede et elektronisk certifikat via SMS. Eller certifikatet sendes automatisk, hvis der ikke overholdes leveringsfristen.

Fornemmelsen af perspektiv og nødvendighed i dette projekt var selvfølgelig opløftende.

Næste dag gik vi ud at spise med teamet og diskuterede, hvordan den minimale funktionalitet i appen ville se ud.

Resultatet blev følgende liste over, hvad der skulle gøres under hackathonen:

Login til leveringskassen.
Vise den aktuelle position.
Send data til eksternt API (koordinater, har taget ordren, har leveret ordren).
Modtag data fra eksternt API (nuværende ordrer til kureren).
Send en begivenhed om, at ordren er taget til levering/levert.
Vise kurers nuværende position på kortet på hjemmesiden.

Det primære arbejde, som jeg så det, skulle finde sted i oprettelsen af backend, selve appen (efter diskussionerne valgte vi ReactNative til udviklingen af appen, mere præcist indpakningen over det — expo.io, som gør det muligt slet ikke at skrive nativer kode). I backend var der oprindeligt håb på Vanya Zverev, som har erfaring med vores service skabelon og k8s (som han påtog sig). Jeg og Andrey Sarafanov tog fat på ReactNative.

Jeg besluttede mig for straks at oprette et arbejdsrepository til selve projektet. Klokken 12 om natten stødte jeg på, at geolokation i ReactNative fungerer dårligt i baggrunden, hvis man ikke skriver nativer kode, og blev en smule frustreret. Men det lettede, da jeg indså, at jeg læste dokumentationen for expo.io-rammen i stedet for ReactNative. Til sidst forstod jeg på en aften, hvordan man får den aktuelle position i expo.io, og tegner separate skærme (til login, visning af ordre osv.).

Om morgenen i hackathonet trak vi Gleb ind i vores super lovende projekt. Vi skitserede hurtigt planen for, hvad der skulle gøres.

Vi begik en fejl, da vi i overensstemmelse med projektets skabelon forsøgte at opnå kommunikation ikke via HTTP, men via GRPC, da ingen kunne samle en GRPC-klient til JavaScript. Efter at have brugt omkring halvanden time på det, droppede vi denne idé. På grund af dette begyndte folkene på backend at ændre den færdige server fra GRPC til WebApi. Efter en halv time kunne vi endelig konfigurere kommunikationen mellem applikationen og backend, herregud. Men samtidig var Gleb næsten færdig med deployment i k8s og plus autodistribution ved commit til master. 🙂

Vi valgte MySQL som datalager for ikke at risikere med databasen (vi overvejede CosmosDb).

I sidste ende:

Vi implementerede lagringen af couriers nuværende koordinater fra applikationen i databasen.
Vi tilsluttede RabbitMQ og tilmeldte os meddelelser om, at courieren tager ordren, så vi straks kan vise ordren hos courieren i applikationen.
Vi begyndte at gemme leveringstiden for ordren i databasen, efter at courieren har trykket på knappen i applikationen. Vi nåede ikke at tilføje sendingen af en hændelse tilbage til Rabbit om, at ordren er leveret.
Jeg lavede visningen af kortet på siden currentorder på hjemmesiden med courierens nuværende position. Men denne funktionalitet blev lidt ufuldstændig, da vi ikke kunne konfigurere CORS til at hente koordinater fra vores nye service i miljøet.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artem Trofimushkin

Vi ønskede at implementere en OpenID Connect-udbyder, da vi i øjeblikket bruger en autentifikationsprotokol fra egen udvikling, hvilket skaber en række udfordringer: brugerdefinerede klientbiblioteker, besvær for eksterne partnere, muligvis sikkerhedsproblemer (OAuth2.0 og OpenID Connect i deres standardimplementering betragtes som sikre, men hvad angår vores løsning — det er jeg ikke sikker på).

Vi har oprettet en separat tjeneste, der emulerer en tjeneste til opbevaring af personlige data, for at skabe en lille model for en landsuafhængig autentifikationsudbyder, der kunne anmode om personlige data fra en separat tjeneste (dette ville i fremtiden give mulighed for at have én tjeneste, som man kunne logge ind med uanset land, samtidig med at man overholder GDPR og andre relevante love). Denne del har vi gjort, ligesom udbyderen, og har succesfuldt koblet dem sammen. Dernæst var vi nødt til at lave et API, der ville være beskyttet med tokens, som udbyderen udstiller, støtte deres introspektion gennem udbyderen og returnere beskyttede data, hvis anmodningen opfyldte autorisationspolitikkerne (vi kontrollerer, at brugeren er autentificeret via Bearer-skemaet, at hans token indeholder en bestemt scope + at brugeren selv har tilladelse til at udføre anmodningen). Denne del blev også fuldført. Den sidste komponent var en JavaScript-klient, som ville modtage et token, der ville blive brugt til at anmode om det beskyttede API. Denne del nåede vi ikke at færdiggøre. Så alle funktionaliteter var klar, men den front-end, der skulle demonstrere systemets funktionalitet, var ikke klar.

E-E-E (spillet)

Dima Afonchenko, Sasha Konovalov

Vi har lavet et mini-spil på Unity, hvor hurtige hænder kaster pølse på pizzaen. Hvis du kaster pølsen forkert, vises der en trist besked på skærmen "Forkastet", og hvis hele pølsen er korrekt kastet, vises en tilfældig fakta om pizza.

Vi ville have lavet et andet niveau med kast af tomater, men nåede det ikke.

Kort fortsættelse: Hvem vandt?

Før hackathonen talte vi med drengene, og jeg spurgte, hvilken præmie de gerne ville have, hvis de vandt. Det viste sig, at den mest værdifulde præmie ville være "vejen til produktion".

Så hold øje med os for snart at annoncere et spil med håndtag, der smider pepperoni på pizzaen.