Kodim-pizza

Hej, Habr. Vi höll spontant vårt första interna hackathon. Jag bestämde mig för att dela med mig av mina smärtor och slutsatser om att förbereda mig för det om 2 veckor, såväl som de projekt som visade sig vara.

Den tråkiga delen för den som är intresserad av marknadsföring

Jag börjar med en liten historia.

Början av april. Det första MskDotNet Community-hackathonet äger rum på vårt kontor. Slaget vid Tatooine är i full gång i vår galax den här gången. lördag. 20 lag. Pizza. Allt är väldigt uppriktigt (bevis). En uppblåsbar R2-D2 flyter runt i hallen. Lag skriver de mest korrekta algoritmerna för att klara det farligaste loppet på kartan. Vi flyttar lanseringen av de första loppen. Kakor och kaffe är livräddare. Arrangörerna och jag räknade med att många skulle gå efter lunch på lördagen. Men nej. 12 timmars kodning bakom. Den slutliga. Något faller av, något startar inte. Men alla är glada. Vårt lag vinner. Vi är dubbelt glada.

Jag delar min glädje i Slack och tanken kommer att tänka på: "Vi måste göra vårt eget hackathon." Jag skriver till vår bensinstation Sasha. Tystnad.

Morgon. Jag dricker kaffe på kontoret. Jag ser Sasha närma sig bakifrån. "Lisa, det här är bra! Vi har ett viktigt datum den 21 april. Vi gör det!" WTF!? Så fort? A? Vad? Jag behöver flyga till Syktyvkar för praktik i mitten av april. Och åt helvete med det! Låt oss.

2 veckor kvar. Jag har aldrig varit ensam arrangör av ett hackathon. Låt det vara internt. Jag läste artiklar om detta ämne. Tuff. Det tar flera månader. Det behövs flera personer. Du måste tänka på varor, priser, villkor, schema, intresse, förstå målet, budgetar. Eller kanske till och med ta reda på meningen med livet. Jag kommer definitivt inte att hinna i tid. Och medan du läste och förberedde dig hade det redan gått en vecka. Det är dags att glömma artiklarna och börja göra något.

Se vår checklista för att hålla ett internt hackathon om 1 vecka

• planen: Du sätter dig lugnt och skriver en lista på vad som behöver göras inför hackathonet. 30 minuter.
• Uppgift: Deltagarna föreslår och väljer de projekt de vill skapa i Google Kalkylark. Bakgrundsuppgift, 2 timmar.
• Tidtabell: på ditt knä skriver du en kort tidsuppdelning, med hänsyn till 3 pauser och finalen. 20 minuter.
• kommandon: publicera meddelande om hackathon med schema från bensinstationen i IT-kanaler i Slack/mail/etc och skapa en separat kanal för hackathon. I den är alla indelade i lag, och de som är osäkra gör detta under de första 5 minuterna av hackathon. Bakgrundsuppgift, 2 timmar.
• Bullar: du kommer med merch med två utvecklare, ger den till designern för rendering och får den klar. Bakgrundsuppgift, 3 dagar.
• Hackathon: du kommer till kontoret, koordinerar alla i början, gör ditt jobb, läser Reddit, framför allt tillkännager varje paus om färsk pizza, tar bilder av solnedgången, tillkännager finalen, röstar tillsammans och utser vinnaren. 1 dag.
• Under asterisken: Visst, man tänker hela tiden på att allt ska gå bra. Naturligtvis kommer inte alla att se ditt meddelande och det är bättre att prata med några personligen. Naturligtvis, om någon hjälper dig, kommer allt att bli 2 gånger lättare (den underbara Alena hjälpte mig).

Den mindre tråkiga delen om hackathon-dejten

Varför 21 april? Den här dagen är betydelsefull för oss. För exakt ett år sedan, den 21 april, hamnade vi under belastning under den första helgen efter starten av den federala reklamkampanjen. Dagen efter, söndagen, var vårt team på jobbet från kl. Sedan skapade vi en sundayhackathon-tavla i Trello och en veckas skiftarbete började, 8 timmar om dagen. Situationen var så kritisk att vi inte ens hann äta och vi fick mat av killar från andra lag.

Du kan läsa en mer detaljerad berättelse på Fjodor Ovchinnikovs sida (vår vd). Sedan dess har vi förändrats mycket, men nu glömmer vi definitivt inte datumet.

I år bestämde vi oss för att detta evenemang var värt att föreviga i eftervärldens minne och i bästa tradition anordnade vi det första interna hackathonet i Dodos historia, som varade i 10 timmar.

Det tråkigaste med hackathonprojekt

Disclaimer: alla beskrivningar skrevs av killarna själva, så författarskapet till texten är inte mitt.

Oleg Learning (maskininlärning)

Dima Kochnev, Sasha Andronov (@alexandronov)

De ville skapa ett neuralt nätverk som skulle avgöra vilken typ av pizza som finns på ett foto utan någon som helst kunskap. Som ett resultat gjorde vi en mycket enkel och leksak - den känner igen 10 pizzor, vi räknade ungefär ut hur allt fungerar, så långt som möjligt på en dag (~10 timmar).

Speciellt insåg vi att branschen har nått en nivå där en vanlig utvecklare kan ta färdiga bibliotek, läsa dokumentationen och träna sitt neurala nätverk utan djup kunskap om ämnet. Och det kommer att fungera tillräckligt bra för att lösa verkliga problem.

Använda verktyg:

• bildai — ett bekvämt och enkelt bibliotek för att arbeta med maskininlärning och datorseende.
• Vi provade två modeller - ResNet50, Yolo.
• Koden skrevs naturligtvis i Python.

Vi hade 11000 3 bilder, men nästan 4/500 av dem visade sig vara skräp, och resten hade olika, olämpliga vinklar. Som ett resultat tog vi en färdig modell (som helt enkelt vet hur man hittar pizza) och med dess hjälp separerade vi soporna. Därefter inkluderade titeln på bilden namnet på pizzan - så vi sorterade den i mappar, men det visade sig att namnen inte överensstämde med verkligheten och vi var tvungna att rensa upp den med händerna. Till slut fanns det cirka 600-10 bilder kvar, det är klart att det är en obetydlig mängd, men ändå räckte detta för att skilja XNUMX pizzor från varandra.

För att träna nätet tog vi den billigaste virtuella maskinen i Azure på en NVIDIA Tesla K80. De tränade på det i 100 epoker, men det var tydligt att nätverket blev övermättat efter 50 epoker, på grund av att det fanns en liten dataset.

Egentligen är hela problemet bristen på bra data.

Vi kan ha blandat ihop begreppen lite, men vi måste ta hänsyn till att vi inte har någon som helst erfarenhet av att arbeta med alla dessa frågor.

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

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Vi har satt ihop en prototyp av en konsolapplikation för nördar, tack vare vilken du kan beställa pizza via terminalen eller kommandoraden, eller till och med integrera den i distributionspipelinen och, efter framgångsrik release, leverera pizza till kontoret.

Arbetet var uppdelat i flera delar: vi kom på hur vårt API för mobilapplikationer fungerar, satte ihop vårt eget CLI med hjälp av oclif och konfigurerade publiceringen av paketet vi samlade in. Den sista uppgiften innebar några obehagliga minuter mot slutet av hackathon. Allt fungerade lokalt för oss, och även de gamla publicerade versionerna av paketet fungerade, men de nya (som lade till fler coola funktioner och uttryckssymboler) vägrade att fungera. Vi tillbringade cirka 40 minuter med att försöka lista ut vad som gick fel, men till slut fungerade allt magiskt av sig självt).

Vårt maximala program för hackathonet var en riktig pizzabeställning till kontoret genom vår CLI. Vi körde allt ett dussin gånger på testbänken, men mina händer skakade fortfarande när jag skrev in kommandon i produktionen.

Som ett resultat gjorde vi det äntligen!

CourierGo

Anton Bruzhmelev (författare), Vanya Zverev, Gleb Lesnikov (entropi), Andrey Sarafanov

Vi tog idén om en "App för kurir".

Bakgrund om förberedelser.Inledningsvis undrade jag vilken typ av funktioner som kan finnas i applikationen? Följande lista över funktioner dök upp:

• Applikationen loggar in i leveranskassan med koden.
• Applikationen visar omedelbart tillgängliga beställningar och beställningar som måste tas.
• Kuriren noterar beställningen och tar med den på resan.
• Han visas den beräknade tiden och om han är i tid eller inte.
• Visar kunden att kuriren har lämnat.
• Kunden börjar visas kurirens punkt på kartan och den beräknade tiden.
• Kuriren kan skriva till klienten i chatten från applikationen.
• Kunden kan skriva till kuriren via chatt från applikationen.
• Fem minuter före ankomst får kunden ett meddelande om att kuriren är nära, var beredd.
• Kuriren noterar i ansökan att han har kommit och väntar.
• Kuriren ringer från applikationen med ett klick och rapporterar att (stiger, har anlänt, etc.)
• Kunden accepterar beställningen och anger PIN-kod från applikationen eller SMS för att bekräfta leverans.(som signatur) Så att kuriren inte kan slutföra leveransen i förväg om han är sen.
• Beställningen är markerad som levererad i systemet.

Plus ett par alternativa scenarier:

• Kuriren kan markera beställningen som ej levererad och välja orsak.
• Om du är sen kan kuriren utfärda ett elektroniskt certifikat via SMS med en knapp. Eller så kommer intyget automatiskt om leveranstiden inte hålls.

Känslan av löfte och nödvändighet av detta projekt var naturligtvis energigivande.

Dagen efter gick vi på lunch med teamet och diskuterade hur applikationens minimifunktionalitet skulle se ut.

Som ett resultat bildades följande lista över vad som måste göras på hackathonet:

• Logga in i leveranskassan.
• Visa aktuell position.
• Skicka data till ett externt API (koordinater, tagit emot beställningen, levererat beställningen).
• Ta emot data från extern API (aktuella budorder).
• Skicka ett event som indikerar att du har tagit beställningen för leverans/levererad.
• Visa kurirens aktuella position på kartan på webbplatsen.

Huvudarbetet, som det verkade, låg i att skapa backend, själva applikationen (efter diskussioner valde vi ReactNative för att utveckla applikationen, eller snarare ramverket för det - expo.io, vilket gör att du inte kan skriva inbyggd kod alls). När det gäller backend fanns det till en början hopp i Vanya Zverev, eftersom han hade erfarenhet av att arbeta med vår servicemall och k8s (vilket jobb han tog på sig). Andrey Sarafanov och jag tog ReactNative en sväng.

Jag bestämde mig för att omedelbart försöka skapa ett fungerande arkiv för själva projektet. Klockan 12 på natten stötte jag på att geolokalisering i bakgrunden inte fungerar bra i ReactNative, om man inte skriver native-kod så blev jag lite frustrerad. Sedan släppte jag taget när jag insåg att jag läste dokumentationen inte för expo.io-ramverket, utan av ReactNative. Som ett resultat förstod jag redan under kvällens gång hur man får den aktuella positionen i expo.io och ritar separata skärmar (för inloggning, ordervisning, etc.).

På morgonen på hackathonet lockade de Gleb in i sitt superlovande projekt. De kom snabbt fram till en plan för vad som behövde göras.

Vi gjorde ett misstag när vi i enlighet med projektmallen försökte kommunicera inte via HTTP, utan via GRPC, eftersom ingen visste hur man bygger en GRPC-klient för JavaScript. Till slut, efter att ha spenderat ungefär en och en halv timme på detta, övergav vi den här idén. På grund av detta började killarna på back-end göra om den färdiga servern från GRPC till WebApi. Efter en halvtimme kunde vi äntligen sätta upp kommunikationen mellan applikationen och backend, och se. Men samtidigt avslutade Gleb nästan utplaceringen till k8s och plus den automatiska utplaceringen av en commit till mastern. 🙂

Vi valde MySQL som lagring för att inte ta risker åtminstone med databasen (vi hade funderingar kring CosmosDb).

Sammanfattningsvis:

• Genomfört att spara aktuella koordinater för kuriren från applikationen till databasen.
• Vi installerade RabbitMQ och prenumererade på meddelanden om att kuriren hämtade en beställning för att omedelbart visa beställningen från kuriren i applikationen.
• Vi började spara orderns leveranstid i vår databas efter att kuriren tryckte på en knapp i applikationen. Vi hade inte tid att lägga till att skicka en händelse tillbaka till rebbit att beställningen levererades.
• Jag gjorde en kartvisning på den aktuella beställningssidan på hemsidan med kurirens aktuella position. Men denna funktionalitet förblev lite oavslutad, eftersom det inte gick att konfigurera CORS i miljön för att ta emot 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 vår egen design, och detta skapar ett antal svårigheter: anpassade klientbibliotek, obekvämt arbete från externa partners, möjliga säkerhetsproblem (trots allt) , OAuth2.0 och OpenID Connect i referensimplementeringen kan anses vara säkra, men jag är inte säker på vår lösning).

Vi gjorde en separat tjänst som emulerade en tjänst för lagring av personuppgifter för att skapa en liten landsagnostisk modell av en autentiseringsleverantör som skulle gå till en separat tjänst för personuppgifter (detta skulle i framtiden göra det möjligt att ha en tjänst med som man kan logga in med en kontoregistrering i vilket land som helst, och samtidigt följa GDPR och andra federala lagar). Vi gjorde den här delen, liksom leverantören, och länkade dem framgångsrikt till varandra. Därefter var det nödvändigt att skapa ett API som skulle skyddas av tokens utfärdade av leverantören, stödja deras introspektion genom leverantören och returnera skyddad data om begäran uppfyllde auktoriseringspolicyerna (vi kontrollerar att användaren är autentiserad enligt Bearer-schemat , hans token innehåller ett visst omfång + y Användaren själv har en behörighet som gör att samtalet kan ringas). Även denna del blev klar. Den sista komponenten var en JavaScript-klient, som skulle få en token, med hjälp av vilken den skulle anropa ett skyddat API. Vi hade inte tid att göra den här delen. Det vill säga, hela den funktionella delen var klar, men front-end-delen var inte redo att demonstrera funktionaliteten i hela systemet.

E-E-E (leksak)

Dima Afonchenko, Sasha Konovalov

Vi gjorde en minileksak på yunka där fräscha händer kastar korv på pizza. Om du sätter på korven felaktigt visas ett tråkigt "Rejected"-meddelande på skärmen, och om all korv har lagts på korrekt visas ett slumpmässigt faktum om pizza.

Vi ville göra en andra nivå med att kasta tomater, men vi hade inte tid.

Kort fortsättning: vem vann?

Innan hackathonet pratade vi med killarna och jag frågade vilket pris de skulle vilja få om de vinner. Det visade sig att det mest värdefulla priset skulle vara "vägen till mat".

Räkna därför med att vi snart annonserar ett spel med händer som lägger pepperons på pizza.

Som en uppmärksam läsare kanske har märkt vann laget "E-E-E (leksak)". Grattis grabbar!

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Vilket projekt gillade du bäst?

• Oleg Learning (maskininlärning)

• GUI för NOOBS

• CourierGo

• M87

• E-E-E

5 användare röstade. 3 användare avstod från att rösta.

Källa: will.com