Kodim-pizza

Hej, Habr. Vi afholdt spontant vores første interne hackathon. Jeg besluttede at dele mine smerter og konklusioner med jer om at forberede mig på det om 2 uger, såvel som de projekter, der viste sig at være.

Den kedelige del for dem, der er interesserede i markedsføring

Jeg starter med en lille historie.

Begyndelsen af ​​april. Det første MskDotNet Community hackathon finder sted på vores kontor. Slaget ved Tatooine er i fuld gang i vores galakse denne gang. Lørdag. 20 hold. Pizza. Alt er meget oprigtigt (beviser). En oppustelig R2-D2 flyder rundt i hallen. Hold skriver de mest korrekte algoritmer for at bestå det farligste løb på kortet. Vi flytter lanceringen af ​​de første løb. Småkager og kaffe er livreddere. Arrangørerne og jeg forventede, at mange ville tage af sted efter frokost lørdag. Men nej. 12 timers kodning bagud. Finalen. Noget falder af, noget starter ikke. Men alle er glade. Vores hold vinder. Vi er dobbelt glade.

Jeg deler min glæde i Slack, og ideen kommer til at tænke på: "Vi skal lave vores eget hackathon." Jeg skriver til vores servicestation Sasha. Stilhed.

Morgen. Jeg drikker kaffe på kontoret. Jeg ser Sasha nærme sig bagfra. "Lisa, det er fantastisk! Vi har en vigtig dato den 21. april. Lad os gøre det! " WTF!? Så hurtig? EN? Hvad? Jeg skal flyve til Syktyvkar i praktik i midten af ​​april. Og for helvede med det! Lad os.

2 uger tilbage. Jeg har aldrig været den eneste arrangør af et hackathon. Lad det være internt. Jeg læste artikler om dette emne. Hård. Det tager flere måneder. Der er brug for flere mennesker. Du skal tænke på merch, præmier, betingelser, tidsplan, interesse, forstå målet, budgetter. Eller måske endda finde ud af meningen med livet. Jeg når bestemt ikke i tide. Og mens du læste og forberedte dig, var der allerede gået en uge. Det er tid til at glemme artiklerne og begynde at gøre noget.

Se vores tjekliste til afholdelse af et internt hackathon om 1 uge

• plan: Du sætter dig roligt ned og skriver en liste over, hvad der skal laves til hackathonet. 30 minutter.
• Opgave: Deltagerne foreslår og vælger de projekter, de vil oprette i Google Sheets. Baggrundsopgave, 2 timer.
• Tidsplan: på dit knæ skriver du en kort oversigt over tid, der tager højde for 3 pauser og den endelige. 20 minutter.
• Команды: offentliggør en besked om hackathon med tidsplan fra servicestationen i IT-kanaler i Slack/mail/etc og opret en separat kanal til hackathon. I den er alle opdelt i hold, og de, der er usikre, gør dette i de første 5 minutter af hackathonet. Baggrundsopgave, 2 timer.
• Boller: du kommer med merch med to udviklere, giver det til designeren til gengivelse og modtager det klar. Baggrundsopgave, 3 dage.
• Hackathon: du kommer til kontoret, koordinerer alle i begyndelsen, går i gang med din virksomhed, læser Reddit, bekendtgør vigtigst af alt hver pause om frisk pizza, tager billeder af solnedgangen, annoncerer finalen, stem sammen og vælg vinderen. 1 dag.
• Under stjernen: Selvfølgelig tænker man hele tiden på, at alt går godt. Selvfølgelig vil ikke alle se din besked, og det er bedre at tale med nogle personligt. Selvfølgelig, hvis nogen hjælper dig, bliver alt 2 gange nemmere (den vidunderlige Alena hjalp mig).

Den mindre kedelige del om hackathon-datoen

Hvorfor 21. april? Denne dag er vigtig for os. For præcis et år siden, den 21. april, faldt vi under belastning i den første weekend efter starten af ​​den føderale reklamekampagne. Næste dag, søndag, var vores team på arbejde fra kl. Så lavede vi en sundayhackathon-tavle i Trello, og en uge med skifteholdsarbejde begyndte, 8 timer om dagen. Situationen var så kritisk, at vi ikke engang havde tid til at spise, og vi blev fodret af fyre fra andre hold.

Du kan læse en mere detaljeret historie på Fjodor Ovchinnikovs side (vores administrerende direktør). Siden har vi ændret en del, men nu glemmer vi bestemt ikke datoen.

I år besluttede vi, at denne begivenhed var værd at fastholde i eftertidens hukommelse, og i de bedste traditioner organiserede vi det første interne hackathon i Dodo-historien, som varede 10 timer.

Den mest kedelige del om hackathon-projekter

Ansvarsfraskrivelse: alle beskrivelserne er skrevet af fyrene selv, så forfatterskabet til teksten er ikke mit.

Oleg Learning (machine learning)

Dima Kochnev, Sasha Andronov (@alexandronov)

De ønskede at lave et neuralt netværk, der ville bestemme, hvilken slags pizza der er på et billede uden nogen viden. Som et resultat lavede vi en meget enkel og legesyg - den genkender 10 pizzaer, vi fandt nogenlunde ud af, hvordan alting fungerer, så vidt muligt på en dag (~10 timer).

Vi indså især, at branchen har nået et niveau, hvor en almindelig udvikler kan tage færdige biblioteker, læse dokumentationen og træne sit neurale netværk uden dybt kendskab til emnet. Og det vil fungere godt nok til at løse reelle problemer.

Brugte værktøjer:

• imageai — et praktisk og enkelt bibliotek til at arbejde med maskinlæring og computersyn.
• Vi prøvede to modeller - ResNet50, Yolo.
• Koden blev selvfølgelig skrevet i Python.

Vi havde 11000 billeder, men næsten 3/4 af dem viste sig at være skrald, og resten havde andre, upassende vinkler. Som et resultat tog vi en færdiglavet model (som simpelthen ved, hvordan man finder pizza) og med dens hjælp adskilte vi skraldespanden. Dernæst indeholdt titlen på billedet pizzaens navn - så vi sorterede den i mapper, men det viste sig, at navnene ikke faldt sammen med virkeligheden, og vi måtte rydde op med hænderne. Til sidst var der omkring 500-600 billeder tilbage, det er tydeligt, at det er et ubetydeligt antal, men ikke desto mindre var det nok til at adskille 10 pizzaer fra hinanden.

For at træne nettet tog vi den billigste virtuelle maskine i Azure på en NVIDIA Tesla K80. De trænede på det i 100 epoker, men det var tydeligt, at netværket var overmættet efter 50 epoker, på grund af at der var et lille datasæt.

Faktisk er hele problemet manglen på gode data.

Vi har måske forvirret begreberne lidt, men vi skal tage højde for, at vi slet ikke har erfaring med at arbejde med alle disse forhold.

GUI til NOOBS (konsol til bestilling af pizza)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Vi har sammensat en prototype af en konsolapplikation til nørder, takket være hvilken du kan bestille pizza gennem terminalen eller kommandolinjen, eller endda integrere den i implementeringspipelinen og, efter vellykket udgivelse, levere pizza til kontoret.

Arbejdet var opdelt i flere dele: vi fandt ud af, hvordan vores API til mobile applikationer fungerer, sammensatte vores egen CLI vha. oclif og konfigurerede udgivelsen af ​​den pakke, vi indsamlede. Den sidste opgave indebar et par ubehagelige minutter mod slutningen af ​​hackathonet. Alt fungerede lokalt for os, og selv de gamle offentliggjorte versioner af pakken virkede, men de nye (som tilføjede flere fede funktioner og humørikoner) nægtede at virke. Vi brugte omkring 40 minutter på at finde ud af, hvad der gik galt, men i sidste ende fungerede alt på magisk vis af sig selv).

Vores maksimale program for hackathonet var en rigtig pizzabestilling til kontoret gennem vores CLI. Vi kørte alt et dusin gange på testbænken, men mine hænder rystede stadig, da jeg indtastede kommandoer i produktionen.

Som et resultat gjorde vi det endelig!

CourierGo

Anton Bruzhmelev (forfatter), Vanya Zverev, Gleb Lesnikov (entropi), Andrey Sarafanov

Vi tog ideen om en "App for Courier".

Baggrund om forberedelse.Til at begynde med spekulerede jeg på, hvilken slags funktioner der kunne være i applikationen? Følgende liste over funktioner dukkede op:

• Applikationen logger på leveringskasseapparatet ved hjælp af koden.
• Applikationen viser med det samme tilgængelige ordrer og ordrer, der skal tages.
• Kureren noterer bestillingen og tager den med på turen.
• Han får vist den estimerede tid og om han kommer til tiden eller ej.
• Viser kunden, at kureren er gået.
• Kunden begynder at blive vist kurerens punkt på kortet og den estimerede tid.
• Kureren kan skrive til klienten i chat fra applikationen.
• Kunden kan skrive til kureren via chat fra applikationen.
• Fem minutter før ankomst modtager klienten en besked om, at kureren er tæt på, vær forberedt.
• Kureren noterer i ansøgningen, at han er ankommet og venter.
• Kureren ringer fra applikationen med et enkelt klik og rapporterer, at (er stigende, er ankommet osv.)
• Kunden accepterer ordren og indtaster en pinkode fra applikationen eller SMS for at bekræfte levering.(som signatur) Så kureren ikke kan gennemføre leveringen på forhånd, hvis han er forsinket.
• Ordren er markeret som leveret i systemet.

Plus et par alternative scenarier:

• Kureren kan markere ordren som ikke-leveret og vælge årsagen.
• Er du forsinket, kan kureren udstede et elektronisk certifikat via SMS med én knap. Eller certifikatet kommer automatisk, hvis leveringsfristen ikke overholdes.

Følelsen af ​​løfte og nødvendighed af dette projekt var selvfølgelig energigivende.

Næste dag gik vi til frokost med teamet og diskuterede, hvordan applikationens minimumsfunktionalitet ville se ud.

Som et resultat blev følgende liste over, hvad der skulle gøres ved hackathonet, dannet:

• Log ind på leveringskassen.
• Vis den aktuelle position.
• Send data til en ekstern API (koordinater, modtog ordren, leverede ordren).
• Modtag data fra ekstern API (aktuelle kurerordrer).
• Send en begivenhed, der angiver, at du har taget ordren til levering/leveret.
• Vis kurerens aktuelle position på kortet på hjemmesiden.

Hovedarbejdet, som det så ud til, lå i at skabe backend, selve applikationen (efter diskussioner valgte vi ReactNative til at udvikle applikationen, eller rettere rammen for den - expo.io, som giver dig mulighed for slet ikke at skrive indbygget kode). Med hensyn til backend var der i starten håb i Vanya Zverev, da han havde erfaring med at arbejde med vores serviceskabelon og k8'er (hvilket job han påtog sig). Andrey Sarafanov og jeg tog ReactNative en tur.

Jeg besluttede mig for straks at oprette et fungerende arkiv til selve projektet. Klokken 12 om natten stødte jeg på, at geolocation i baggrunden ikke fungerer godt i ReactNative, hvis du ikke skriver native kode, var jeg lidt frustreret. Så slap jeg, da jeg indså, at jeg læste dokumentationen ikke af expo.io-rammerne, men af ​​ReactNative. Som følge heraf forstod jeg allerede i løbet af aftenen, hvordan man får den aktuelle position i expo.io og tegner separate skærme (til login, ordrevisning osv.).

Om morgenen ved hackathonet lokkede de Gleb ind i deres super-lovende projekt. De kom hurtigt med en plan for, hvad der skulle gøres.

Vi lavede en fejl, da vi i overensstemmelse med projektskabelonen forsøgte at kommunikere ikke via HTTP, men via GRPC, da ingen vidste, hvordan man byggede en GRPC-klient til JavaScript. Til sidst, efter at have brugt omkring halvanden time på dette, opgav vi denne idé. På grund af dette begyndte fyrene på back-end at lave den færdige server fra GRPC til WebApi. Efter en halv time var vi endelig i stand til at sætte kommunikationen op mellem applikationen og backend, lo og se. Men på samme tid var Gleb næsten ved at afslutte implementeringen til k8s og plus den automatiske implementering af en commit til masteren. 🙂

Vi valgte MySQL som opbevaring for ikke at tage risici i det mindste med databasen (vi havde tanker om CosmosDb).

Sammenfattende:

• Implementeret lagring af de aktuelle koordinater for kureren fra applikationen til databasen.
• Vi installerede RabbitMQ og abonnerede på beskeder om, at kureren hentede en ordre for straks at vise ordren fra kureren i applikationen.
• Vi begyndte at gemme ordreleveringstiden i vores database, efter at kureren trykkede på en knap i applikationen. Vi havde ikke tid til at tilføje at sende en begivenhed tilbage til rebbiten, hvor ordren blev leveret.
• Jeg lavede en kortvisning på den aktuelle bestillingsside på hjemmesiden med kurerens aktuelle position. Men denne funktionalitet forblev lidt ufærdig, da det ikke var muligt at konfigurere CORS i miljøet til at modtage koordinater fra vores nye service.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

Vi ønskede at implementere en OpenID Connect-udbyder, da vi i øjeblikket bruger en autentificeringsprotokol af vores eget design, og dette skaber en række vanskeligheder: tilpassede klientbiblioteker, ubelejligt arbejde fra eksterne partneres side, mulige sikkerhedsproblemer (trods alt , OAuth2.0 og OpenID Connect i referenceimplementeringen kan betragtes som sikre, men jeg er ikke sikker på vores løsning).

Vi lavede en separat tjeneste, der emulerede en tjeneste til lagring af personlige data for at skabe en lille lande-agnostisk model af en autentificeringsudbyder, der ville gå til en separat tjeneste for persondata (dette ville i fremtiden gøre det muligt at have én tjeneste med som man kunne logge ind med en kontoregistrering i ethvert land, og samtidig overholde GDPR og andre føderale love). Vi gjorde denne del, det samme gjorde udbyderen, og linkede dem med succes med hinanden. Dernæst var det nødvendigt at oprette en API, der ville være beskyttet af tokens udstedt af udbyderen, understøtte deres introspektion gennem udbyderen og returnere beskyttede data, hvis anmodningen opfyldte autorisationspolitikkerne (vi kontrollerer, at brugeren er autentificeret i henhold til Bearer-skemaet , hans token indeholder et vist omfang + y Brugeren har selv en tilladelse, der tillader opkaldet). Denne del blev også afsluttet. Den sidste komponent var en JavaScript-klient, som ville blive givet et token, ved hjælp af hvilket det ville kalde en beskyttet API. Vi havde ikke tid til at gøre denne del. Det vil sige, at hele den funktionelle del var klar, men front-end-delen var ikke klar til at demonstrere funktionaliteten af ​​hele systemet.

E-E-E (legetøj)

Dima Afonchenko, Sasha Konovalov

Vi lavede et mini-legetøj på yunka, hvor friske hænder smider pølse på pizza. Hvis du sætter pølsen forkert på, vises en trist "Afvist"-meddelelse på skærmen, og hvis al pølsen blev sat rigtigt på, dukker der et tilfældigt faktum op om pizza.

Vi ville lave et andet niveau med at kaste tomater, men vi havde ikke tid.

Kort fortsættelse: hvem vandt?

Før hackathonet talte vi med fyrene, og jeg spurgte, hvilken præmie de gerne ville modtage, hvis de vinder. Det viste sig, at den mest værdifulde præmie ville være "vejen til mad."

Forvent derfor, at vi snart annoncerer et spil med hænder, der sætter peberfrugter på pizza.

Som en opmærksom læser måske har bemærket, vandt holdet "E-E-E (legetøj)". Tillykke gutter!

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Hvilket projekt kunne du bedst lide?

• Oleg Learning (machine learning)

• GUI til NOOBS

• CourierGo

• M87

• E-E-E

5 brugere stemte. 3 brugere undlod at stemme.

Kilde: www.habr.com