🥇Coderen–pizza

Hallo, Habr. We hebben spontaan onze eerste interne hackathon gehouden. Ik wil mijn pijnpunten en conclusies over de voorbereiding in de twee weken ervoor delen, evenals de projecten die zijn ontstaan.

De saaie kant voor degenen die geïnteresseerd zijn in marketing.

Ik begin met een klein verhaal.

Begin april. In ons kantoor vindt de eerste hackathon van de MskDotNet Community plaats. De strijd om Tatooine is in volle gang, deze keer in onze galaxie. Zaterdag. 20 teams. Pizza. Alles is zeer gezellig (bewijzen). Een opblaasbare R2-D2 staat in de zaal. Teams schrijven de juiste algoritmes om de gevaarlijkste race op de kaart te voltooien. We schuiven de start van de eerste races op. Koekjes en koffie zijn een redding. We verwachte dat veel mensen zaterdag na de lunch zouden vertrekken. Maar nee. 12 uur coderen zijn voorbij. De finale. Iets valt uit, iets start niet. Maar iedereen is blij. Ons team wint. We zijn dubbel gelukkig.

Ik deel mijn vreugde in Slack en het idee komt in me op: "Laten we onze eigen hackathon organiseren." Ik schrijf naar onze CTO Sasha. Stilte.

Ochtend. Ik drink koffie op kantoor. Ik zie Sasha van achteren naderen. "Lisa, dat is geweldig! We hebben precies op 21 april een belangrijke datum. Laten we het doen!" WTF!? Zo snel? Huh? Ik moet halverwege april naar Syktyvkar voor een stage. Maar laat maar! Laten we doorgaan.

Er blijven 2 weken over. Ik ben nog nooit de enige organisator van een hackathon geweest. Laat staan een interne. Ik lees artikelen over dit onderwerp. Wat een uitdaging. Je hebt enkele maanden nodig. Je hebt een paar mensen nodig. Je moet merchandise, prijzen, voorwaarden, een schema plannen, interesse wekken, het doel begrijpen, budgetten. Misschien zelfs de zin van het leven doorgronden. Ik haal het zeker niet op tijd. En terwijl jij aan het lezen en voorbereiden bent, is er al een week voorbij. Het is tijd om te stoppen met lezen en te beginnen met doen.

Hier is onze checklist voor het organiseren van een interne hackathon in 1 week.

Plan: ga rustig zitten en schrijf een lijst van wat er gedaan moet worden voor de hackathon. 30 minuten.
Task: deelnemers stellen zelf de projecten voor en kiezen wat ze willen maken in Google Sheets. Achtergrondtaak, 2 uur..
Schema: schrijf snel een korte tijdsplanning op met rekening houdend met 3 pauzes en de finale. 20 minuten.
Teams: publiceer een bericht over de hackathon met het schema van de CTO in IT-kanalen op Slack/e-mail/etc. en maak een apart kanaal voor de hackathon. Daarin verdeelt iedereen zich in teams, en degenen die nog geen team hebben vormen dit in de eerste 5 minuten van de hackathon. Achtergrondtaak, 2 uur..
Leuke extraatjes: je bedenkt merchandise met twee ontwikkelaars, geeft het aan de ontwerper voor weergave, en ontvangt het resultaat. Achtergrondtaak, 3 dagen.
Hackathon: je komt op kantoor, coördineert iedereen in het begin, houdt je met je eigen zaken bezig, leest Reddit, geeft met een serieuze blik elk pauzemoment het nieuws over verse pizza door, fotografeert de zonsondergang, kondigt de finale aan, en stemt samen om de winnaar te kiezen. 1 dag.
Onder de sterren: natuurlijk denk je voortdurend na over hoe alles goed zal gaan. Natuurlijk zullen niet alle mensen je bericht zien en is het met sommigen beter om persoonlijk te spreken. Natuurlijk, als iemand je helpt, wordt alles twee keer zo makkelijk (ik kreeg geweldige hulp van Alena).

Minder saaie deel over de datum van de hackathon

Waarom 21 april? Deze dag is belangrijk voor ons. Precies een jaar geleden, op 21 april, bezweken we onder de druk tijdens het eerste weekend na de start van de Federale Reclamecampagne. De volgende dag, op zondag, was ons team vanaf 8 uur 's ochtends aan het werk. Toen hebben we in Trello een bord aangemaakt voor sundayhackathon en begon een week met ploegendiensten van 12 uur per dag. De situatie was zo kritiek dat we zelfs geen tijd hadden om te eten en werden gevoed door collega's uit andere teams.

Een meer gedetailleerd verhaal kun je lezen op de pagina van Fyodor Ovchinnikov (onze CEO). Sindsdien hebben we veel veranderd, maar die datum zullen we zeker niet vergeten.

Dit jaar hebben we besloten dat dit evenement herinnerd moet worden in de toekomst en in de beste tradities organiseerden we de eerste interne hackathon in de geschiedenis van Dodo, die 10 uur duurde.

Het meest interessante deel over de hackathonprojecten

Disclaimer: alle beschrijvingen zijn door de jongens zelf geschreven, dus de auteurschap van de tekst is niet van mij.

Oleg Learning (machine learning)

Dima Kochnev, Sasha Andronov (@alexandronov)

We wilden een neurale netwerk maken die kan bepalen welke pizza er op de foto staat zonder enige voorkennis. Uiteindelijk hebben we een zeer eenvoudige en speelse gemaakt – het herkent 10 pizza's, we hebben ongeveer begrepen hoe alles in elkaar zit, zover dat mogelijk is in een dag (~10 uur).

Specifiek hebben we begrepen dat de industrie het niveau heeft bereikt waarbij een gemiddelde ontwikkelaar kant-en-klare bibliotheken kan gebruiken, de documentatie kan doorlezen en zijn neurale netwerk kan trainen zonder diepgaande kennis van het onderwerp. En het zal goed genoeg werken voor het oplossen van echte taken.

Tools die we hebben gebruikt:

imageai — een handige en eenvoudige bibliotheek voor machine learning en computer vision.
We hebben twee modellen geprobeerd: ResNet50, Yolo.
De code is natuurlijk geschreven in Python.

We hadden 11.000 foto's, maar bijna 3/4 daarvan bleek rommel te zijn, en van de overgebleven foto's waren er verschillende, ongepaste hoeken. Uiteindelijk hebben we een kant-en-klaar model genomen (dat gewoon pizza's kan herkennen) en daarmee het meeste afval gescheiden. Daarna hebben we de foto's op naam van de pizza's ingedeeld — zo hebben we ze in mappen verdeeld, maar het bleek dat de namen niet overeenkwamen met de werkelijkheid, dus moesten we handmatig opschonen. Uiteindelijk bleven er ongeveer 500-600 foto's over; dat is natuurlijk een verwaarloosbaar aantal, maar toch was het genoeg om 10 pizza's van elkaar te scheiden.

Voor het trainen van het netwerk hebben we de goedkoopste virtuele machine in Azure met een NVIDIA Tesla K80 genomen. We hebben 100 epochs getraind, maar het was al na 50 epochs duidelijk dat het netwerk oververzadigd was, omdat we een kleine dataset hadden.

Eigenlijk ligt het probleem in het ontbreken van goede data.

Misschien hebben we wat termen door elkaar gehaald, maar we moeten in gedachten houden dat we helemaal geen ervaring hebben met al deze zaken.

GUI voor NOOBS (console voor het bestellen van pizza's)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

We hebben een prototype van een console-applicatie voor geeks ontwikkeld, waarmee je pizza kunt bestellen via de terminal of command line, of zelfs kunt integreren in de deploy pipeline om bij een succesvolle release pizza op kantoor te laten bezorgen.

Het werk werd opgedeeld in verschillende delen: we onderzochten hoe onze API voor mobiele apps in elkaar zat, en bouwden onze eigen CLI met behulp van oclif , en configureerden de publicatie van het door ons gebouwde pakket. Met de laatste taak waren er een paar vervelende minuten dichter bij het einde van de hackathon. Alles werkte lokaal en zelfs de oude gepubliceerde versies van het pakket functioneerden, maar de nieuwe (waarin meer coole functies en emoji's waren toegevoegd) weigerden te werken. We hebben ongeveer 40 minuten besteed om te begrijpen wat er fout ging, maar uiteindelijk werkte alles op magische wijze zelf weer.)

Onze ambitie voor de hackathon was een echte bestelling van pizza op kantoor via onze CLI. We hebben het tien keer op de testomgeving doorlopen, maar toch beefden mijn handen toen ik de commando's op de productie invoerde.

Uiteindelijk hebben we het toch gedaan!

CourierGo

Anton Bruzhmelёv (auteur), Vanya Zverev, Gleb Lesnikov (entropie), Andrey Sarafанов

We hebben het idee «App voor koerier» overgenomen.

Achtergrondinformatie over de voorbereiding.Ik heb aanvankelijk overwogen welke functies er in de app kunnen zitten. Dit resulteerde in een lijst met functionaliteiten:

De app logt in op de bezorgkassa met een code.
In de app zijn onmiddellijk de beschikbare opdrachten zichtbaar, evenals de opdrachten die moeten worden opgepakt.
De koerier markeert de opdracht en neemt deze mee.
Hij ziet de berekende tijd en of hij op tijd kan zijn of niet.
De klant ziet dat de koerier is vertrokken.
De klant kan de locatie van de koerier op de kaart en de geschatte tijd volgen.
De koerier kan in de chat met de klant communiceren vanuit de app.
De klant kan in de chat met de koerier communiceren vanuit de app.
Vijf minuten voor aankomst ontvangt de klant een bericht dat de koerier in de buurt is, wees voorbereid.
De koerier markeert in de app dat hij is aangekomen en wacht.
De koerier kan met één klik vanuit de app bellen en melden dat hij (aan het arriveren is, of iets dergelijks).
De klant accepteert de bestelling en voert de pincode in die uit de app of SMS is ontvangen ter bevestiging van de levering (als een handtekening) zodat de koerier de levering niet voortijdig kan afronden als hij laat is.
De bestelling wordt in het systeem gemarkeerd als geleverd.

Daarnaast zijn er een paar alternatieve scenario's:

De koerier kan de bestelling als niet geleverd markeren en de reden kiezen.
Bij vertraging kan de koerier met één klik een elektronische bon via SMS verstrekken. Of de bon komt automatisch als de levertijd niet wordt gehaald.

Het gevoel van de perspectieven en de noodzaak van dit project gaf zeker een boost.

De volgende dag gingen we met het team lunchen en bespraken we hoe de minimale functionaliteit van de app eruit zou zien.

Uiteindelijk ontstond de volgende lijst van wat we moesten doen tijdens de hackathon:

Inloggen op de bezorgkassa.
De huidige locatie weergeven.
Gegevens naar een externe API sturen (coördinaten, opdracht opgenomen, bestelling afgeleverd).
Gegevens uit een externe API ophalen (huidige opdrachten van de koerier).
Een evenement versturen dat aangeeft dat de opdracht is opgepakt voor levering/afgeleverd.
De huidige locatie van de koerier op de kaart op de site weergeven.

Het grootste werk, zoals we zagen, zou bestaan uit het creëren van de backend, de app zelf (na besprekingen kozen we ReactNative voor de ontwikkeling van de app, meer bepaald de binding eromheen — expo.io, waardoor je helemaal geen native code hoeft te schrijven). Voor de backend was er aanvankelijk hoop op Vanya Zverev, als ervaren persoon in de omgang met onze sjabloonservice en k8s (de werkzaamheden die hij op zich heeft genomen). ReactNative hebben Andrey Sarafanov en ik even bekeken.

Ik besloot meteen een werkrepository voor het project aan te maken. Om 12 uur 's nachts stuitte ik op het probleem dat geolocatie in de achtergrond slecht werkt in ReactNative, tenzij je native code schrijft, wat me een beetje frustreerde. Het voelde beter toen ik ontdekte dat ik de documentatie van het framerwerk expo.io las in plaats van ReactNative. Uiteindelijk begreep ik tegen de avond al hoe ik in expo.io de huidige locatie kon verkrijgen en afzonderlijke schermen kon tekenen (voor inloggen, het weergeven van bestellingen, enz.).

In de ochtend op de hackathon trok ik Gleb in ons superveelbelovende project. We hebben snel een plan opgesteld van wat er gedaan moest worden.

We maakten een fout door, volgens de projecttemplate, te proberen communicatie niet via HTTP, maar via GRPC te doen, omdat niemand wist hoe je een GRPC-client voor JavaScript moest opzetten. Uiteindelijk, na ongeveer anderhalf uur, hebben we dit idee opgegeven. Hierdoor begonnen de jongens aan de backend de bestaande server van GRPC naar WebApi om te bouwen. Na een half uur kregen we eindelijk de communicatie tussen de app en de backend aan de praat, wat een wonder. Maar op datzelfde moment was Gleb bijna klaar met de deployment in k8s en de automatische deployment bij een commit naar master. 🙂

We hebben MySQL gekozen als opslag om niet te riskeren met de database (er waren gedachten over CosmosDb).

Uiteindelijk:

We hebben de huidige coördinaten van de koerier vanuit de app in de database opgeslagen.
We hebben RabbitMQ geïntegreerd en ons aangemeld voor berichten over het aannemen van bestellingen door de koerier, zodat we de bestelling direct in de app van de koerier kunnen weergeven.
We begonnen de levertijd van de bestelling in onze database op te slaan, nadat de koerier op de knop in de app had gedrukt. We hebben niet de tijd gehad om het evenement terug naar RabbitMQ te sturen dat de bestelling was geleverd.
Ik heb een kaart weergegeven op de pagina currentorder op de website met de huidige positie van de koerier. Maar deze functionaliteit bleef een beetje onafgemaakt, omdat het niet lukte om CORS in de omgeving in te stellen voor het verkrijgen van coördinaten uit onze nieuwe service.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Artyom Trofimushkin

We wanted to implement an OpenID Connect provider since we currently use a custom-developed authentication protocol, which creates several difficulties: custom client libraries, inconvenient interactions with external partners, and potential security issues (after all, OAuth2.0 and OpenID Connect in their standard implementations can be considered secure, while I'm not sure about our solution).

We created a separate service emulating a personal data storage service to develop a small model of a Country-Agnostic authentication provider that would fetch personal data from a separate service (this would eventually allow having a single service through which one could log in with an account from any country while complying with GDPR and other laws). We completed this part, as well as the provider, and successfully linked them. Next, we needed to create an API that would be secured by tokens issued by the provider, support token introspection through the provider, and return protected data if the request met the authorization policies (checking that the user is authenticated according to the Bearer scheme, that their token contains a specific scope, and that the user has the permission to make the call). This part was also completed. The last component was a JavaScript client that would be issued a token to call the protected API. We didn't manage to complete this part. In other words, the entire functional part was ready, but the frontend part for demonstrating the system's operability was not finished.

E-E-E (game)

Dima Afonchenko, Sasha Konovalov

We created a mini-game on Unity where nimble hands toss slices of sausage onto a pizza. If you place the sausage slice incorrectly, a sad message appears on the screen saying 'Rejected', but if all the sausage slices are placed correctly, a random fact about pizza appears.

We wanted to create a second level with tossing tomatoes, but we ran out of time.

A short continuation: who won?

Before the hackathon, we talked to the guys, and I asked them what prize they would like to receive if they won. It turned out that the most valuable prize would be 'a ticket to production'.

Dus, verwacht binnenkort een aankondiging van ons voor een spel met handvatten die pepperoni op pizza gooien.