Kodim-pizza

Hallo, Habr. We hielden spontaan onze eerste interne hackathon. Ik besloot mijn pijn en conclusies over de voorbereiding ervan in 2 weken met jullie te delen, evenals de projecten die dat bleken te zijn.

Het saaie gedeelte voor degenen die geïnteresseerd zijn in marketing

Ik begin met een klein verhaal.

Begin april. De eerste MskDotNet Community-hackathon vindt plaats op ons kantoor. De Slag om Tatooine is deze keer in volle gang in onze Melkweg. Zaterdag. 20 ploegen. Pizza. Alles is heel oprecht (bewijzen). Een opblaasbare R2-D2 zweeft door de hal. Teams schrijven de meest correcte algoritmen om de gevaarlijkste race op de kaart te passeren. We verplaatsen de lancering van de eerste races. Koekjes en koffie zijn levensreddend. De organisatoren en ik verwachtten dat veel mensen zaterdag na de lunch zouden vertrekken. Maar nee. 12 uur coderen achter de rug. De laatste. Er valt iets af, iets start niet. Maar iedereen is blij. Ons team wint. Wij zijn dubbel blij.

Ik deel mijn vreugde in Slack en het idee komt in me op: “We moeten onze eigen hackathon doen.” Ik schrijf naar ons tankstation Sasha. Stilte.

Ochtend. Ik drink koffie op kantoor. Ik zie Sasha van achteren naderen. “Lisa, dit is geweldig! We hebben een belangrijke datum op 21 april. Laten we het doen!" WTF!? Zo snel? A? Wat? Half april moet ik naar Syktyvkar vliegen voor een stage. En naar de hel ermee! Laten we.

Nog 2 weken. Ik ben nooit de enige organisator van een hackathon geweest. Laat het intern zijn. Ik lees artikelen over dit onderwerp. Moeilijk. Het duurt enkele maanden. Er zijn meerdere mensen nodig. Je moet nadenken over merchandise, prijzen, voorwaarden, planning, interesse, het doel begrijpen, budgetten. Of misschien zelfs de zin van het leven ontdekken. Ik ga het zeker niet op tijd halen. En terwijl jij aan het lezen en voorbereiden was, was er al een week voorbij. Het is tijd om de artikelen te vergeten en iets te gaan doen.

Bekijk onze checklist voor het houden van een interne hackathon in 1 week

• plan: Je gaat rustig zitten en schrijft een lijstje met wat er moet gebeuren voor de hackathon. 30 minuten.
• Taak: deelnemers stellen de projecten voor die ze willen maken en kiezen deze in Google Spreadsheets. Achtergrondtaak, 2 uur.
• Dienstregeling: op je knie schrijf je een korte tijdsindeling, rekening houdend met 3 pauzes en de finale. 20 minuten.
• Команды: publiceer een bericht over de hackathon met een schema van het servicestation in IT-kanalen in Slack/mail/etc en maak een apart kanaal aan voor de hackathon. Daarin is iedereen verdeeld in teams, en degenen die onbeslist zijn, doen dit in de eerste 5 minuten van de hackathon. Achtergrondtaak, 2 uur.
• Broodjes: je bedenkt met twee ontwikkelaars merchandise, geeft deze ter rendering aan de ontwerper en ontvangt deze gereed. Achtergrondtaak, 3 dagen.
• Hackaton: je komt naar kantoor, coördineert iedereen in het begin, gaat door met je zaken, leest Reddit, kondigt, belangrijker nog, elke pauze aan over verse pizza, maakt foto's van de zonsondergang, kondigt de finale aan, stemt samen en kiest de winnaar. 1 dag.
• Onder het sterretje: Natuurlijk denk je er voortdurend aan dat alles goed gaat. Natuurlijk zal niet iedereen uw bericht zien en is het beter om met sommigen persoonlijk te praten. Als iemand je helpt, wordt alles natuurlijk 2 keer gemakkelijker (de geweldige Alena heeft me geholpen).

Het minder saaie deel over de hackathon-date

Waarom 21 april? Deze dag is belangrijk voor ons. Precies een jaar geleden, op 21 april, kwamen we tijdens het eerste weekend na de start van de Federale Reclamecampagne onder druk te staan. De volgende dag, zondag, was ons team vanaf 8 uur aan het werk. Vervolgens creëerden we een zondaghackathonbord in Trello en begon een week van ploegendienst, 12 uur per dag. De situatie was zo kritiek dat we niet eens tijd hadden om te eten en we werden gevoed door jongens van andere teams.

Een uitgebreider verhaal kunt u lezen op Fjodor Ovchinnikov's pagina (onze CEO). Sindsdien hebben we veel veranderd, maar nu zullen we de datum zeker niet vergeten.

Dit jaar hebben we besloten dat dit evenement de moeite waard was om te bestendigen in de herinnering van het nageslacht en, in de beste tradities, organiseerden we de eerste interne hackathon in de geschiedenis van de Dodo, die 10 uur duurde.

Het saaiste deel van hackathonprojecten

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

Oleg Leren (machine learning)

Dima Kochnev, Sasha Andronov (@alexandronov)

Ze wilden een neuraal netwerk maken dat zonder enige kennis zou bepalen wat voor soort pizza er op een foto staat. Als resultaat hebben we een heel eenvoudige en speelgoedversie gemaakt - hij herkent 10 pizza's, we hebben ongeveer uitgezocht hoe alles werkt, voor zover mogelijk per dag (~ 10 uur).

We realiseerden ons vooral dat de industrie een niveau heeft bereikt waarop een gewone ontwikkelaar kant-en-klare bibliotheken kan gebruiken, de documentatie kan lezen en zijn neurale netwerk kan trainen zonder diepgaande kennis van het onderwerp. En het zal goed genoeg werken om echte problemen op te lossen.

Gebruikt gereedschap:

• afbeelding — een handige en eenvoudige bibliotheek voor het werken met machine learning en computer vision.
• We hebben twee modellen geprobeerd: ResNet50, Yolo.
• De code is uiteraard in Python geschreven.

We hadden 11000 foto's, maar bijna driekwart daarvan bleek onzin, en de rest had een andere, ongepaste invalshoek. Als resultaat hebben we een kant-en-klaar model genomen (dat eenvoudig pizza weet te vinden) en met zijn hulp hebben we het afval gescheiden. Vervolgens bevatte de titel van de foto de naam van de pizza - dus hebben we deze in mappen gesorteerd, maar het bleek dat de namen niet overeenkwamen met de werkelijkheid en dat we hem met onze handen moesten opruimen. Uiteindelijk bleven er ongeveer 3-4 foto's over, het is duidelijk dat dit een onbeduidend aantal is, maar toch was dit genoeg om 500 pizza's van elkaar te scheiden.

Om het grid te trainen, hebben we de goedkoopste virtuele machine in Azure op een NVIDIA Tesla K80 genomen. Ze trainden er gedurende 100 tijdperken op, maar het was duidelijk dat het netwerk na 50 tijdperken oververzadigd was, vanwege het feit dat er een kleine dataset was.

Eigenlijk is het hele probleem het gebrek aan goede gegevens.

We hebben de termen misschien een beetje verward, maar we moeten er rekening mee houden dat we helemaal geen ervaring hebben met het werken met al deze zaken.

GUI voor NOOBS (console voor het bestellen van pizza)

Misha Kumachev (Ceridan), Zjenja Bikkinin, Zjenja Vasiliev

We hebben een prototype samengesteld van een consoleapplicatie voor nerds, waarmee je pizza kunt bestellen via de terminal of opdrachtregel, of deze zelfs kunt integreren in de implementatiepijplijn en, bij succesvolle release, pizza kunt bezorgen op kantoor.

Het werk was in verschillende delen verdeeld: we ontdekten hoe onze API voor mobiele applicaties werkt en stelden onze eigen CLI samen met behulp van oklif en configureerde de publicatie van het pakket dat we hadden verzameld. De laatste taak omvatte een paar onaangename minuten tegen het einde van de hackathon. Alles werkte lokaal voor ons, en zelfs de oude gepubliceerde versies van het pakket werkten, maar de nieuwe (die meer coole functies en emoticons toevoegden) weigerden te werken. We hebben ongeveer 40 minuten besteed aan het uitzoeken wat er mis ging, maar uiteindelijk werkte alles op magische wijze vanzelf).

Ons maximale programma voor de hackathon was een echte pizzabestelling op kantoor via onze CLI. We hebben alles een tiental keer laten draaien op de testbank, maar mijn handen trilden nog steeds toen ik commando's invoerde in de productie.

Het resultaat is dat we het eindelijk hebben gedaan!

KoerierGo

Anton Bruzhmelev (auteur), Vanya Zverev, Gleb Lesnikov (entropie), Andrej Sarafanov

We namen het idee van een “App voor Koerier”.

Achtergrondinformatie over de voorbereiding.Aanvankelijk vroeg ik me af wat voor functies er in de applicatie zouden kunnen zitten? De volgende lijst met functionaliteit is ontstaan:

• Met de code logt de applicatie in op de bezorgkassa.
• De applicatie toont direct beschikbare bestellingen en bestellingen die moeten worden opgenomen.
• De koerier noteert de bestelling en neemt deze mee op reis.
• Hij krijgt de geschatte tijd te zien en of hij op tijd is of niet.
• Laat de klant zien dat de koerier is vertrokken.
• De klant krijgt het punt van de koerier op de kaart en de geschatte tijd te zien.
• De koerier kan vanuit de applicatie in de chat met de klant schrijven.
• De klant kan vanuit de applicatie via chat naar de koerier schrijven.
• Vijf minuten voor aankomst krijgt de klant een bericht dat de koerier dichtbij is, wees voorbereid.
• De koerier noteert in de aanvraag dat hij is gearriveerd en wacht.
• De koerier belt vanuit de applicatie met één klik en meldt dat (stijgend is, gearriveerd etc.)
• De klant accepteert de bestelling en voert een pincode uit de applicatie of sms in om de bezorging te bevestigen (als handtekening) Zodat de koerier de bezorging niet vooraf kan voltooien als hij te laat is.
• De bestelling wordt in het systeem als afgeleverd gemarkeerd.

Plus een paar alternatieve scenario's:

• De koerier kan de bestelling als niet bezorgd markeren en de reden selecteren.
• Bent u te laat, dan kan de koerier met één druk op de knop een elektronisch certificaat per sms afgeven. Of het certificaat komt automatisch binnen als de levertermijn niet wordt gehaald.

Het gevoel van belofte en noodzaak van dit project was uiteraard stimulerend.

De volgende dag zijn we met het team gaan lunchen en hebben we besproken hoe de minimale functionaliteit van de applicatie eruit zou zien.

Als gevolg hiervan ontstond de volgende lijst met wat er tijdens de hackathon moest gebeuren:

• Log in op de bezorgkassa.
• Geef huidige positie weer.
• Gegevens verzenden naar een externe API (coördineert, bestelling ontvangen, bestelling afgeleverd).
• Ontvang gegevens van externe API (huidige koeriersbestellingen).
• Stuur een gebeurtenis waarin u aangeeft dat u de bestelling voor bezorging heeft aangenomen/bezorgd.
• Toon de huidige positie van de koerier op de kaart op de website.

Het belangrijkste werk lag, zo leek het, in het creëren van de backend, de applicatie zelf (na discussies kozen we voor ReactNative om de applicatie te ontwikkelen, of beter gezegd het raamwerk ervoor - expo.io, waardoor u helemaal geen native code kunt schrijven). Wat de backend betreft, was er aanvankelijk hoop in Vanya Zverev, omdat hij ervaring had met het werken met onze servicesjabloon en k8s (welke taak hij op zich nam). Andrey Sarafanov en ik hebben ReactNative eens geprobeerd.

Ik besloot te proberen onmiddellijk een werkende repository voor het project zelf te maken. Om 12 uur 's nachts kwam ik tegen dat geolocatie op de achtergrond niet goed werkt in ReactNative, als je geen native code schrijft, was ik een beetje gefrustreerd. Toen liet ik het los toen ik me realiseerde dat ik de documentatie niet van het expo.io-framework aan het lezen was, maar van ReactNative. Hierdoor begreep ik in de loop van de avond al hoe ik de huidige positie in expo.io kon krijgen en aparte schermen kon tekenen (voor inloggen, orderweergave, etc.).

'S Morgens tijdens de hackathon lokten ze Gleb naar hun veelbelovende project. Ze kwamen snel met een plan van wat er moest gebeuren.

We hebben een fout gemaakt toen we, in overeenstemming met de projectsjabloon, probeerden niet via HTTP, maar via GRPC te communiceren, omdat niemand wist hoe je een GRPC-client voor JavaScript moest bouwen. Uiteindelijk, nadat we er ongeveer anderhalf uur aan hadden besteed, hebben we dit idee laten varen. Daarom begonnen de jongens aan de back-end de voltooide server opnieuw te maken van GRPC naar WebApi. Na een half uur konden we eindelijk de communicatie tussen de applicatie en de backend opzetten, ziedaar. Maar tegelijkertijd was Gleb bijna bezig met het afronden van de implementatie naar k8s en de automatische implementatie van een commit naar de master. 🙂

We kozen voor MySQL als opslag om in ieder geval geen risico's te nemen met de database (we hadden gedachten over CosmosDb).

In het kort:

• Geïmplementeerd door het opslaan van de huidige coördinaten van de koerier vanuit de applicatie naar de database.
• We hebben RabbitMQ geïnstalleerd en geabonneerd op berichten over de koerier die een bestelling ophaalt, zodat de bestelling van de koerier meteen in de applicatie wordt weergegeven.
• We zijn begonnen met het opslaan van de levertijd van de bestelling in onze database nadat de koerier in de applicatie op een knop had gedrukt. We hadden geen tijd om het terugsturen van een gebeurtenis toe te voegen aan de rebbit waarop de bestelling was afgeleverd.
• Ik heb op de huidige bestelpagina op de website een kaartweergave gemaakt met de huidige positie van de koerier. Maar deze functionaliteit bleef een beetje onvoltooid, omdat het niet mogelijk was om CORS in de omgeving te configureren om coördinaten van onze nieuwe dienst te ontvangen.

M87

Roma Bukin, Gosha Polevoy (Georgepolevoy), Artjom Trofimusjkin

We wilden een OpenID Connect-provider implementeren, omdat we momenteel een authenticatieprotocol van ons eigen ontwerp gebruiken, en dit levert een aantal problemen op: klantbibliotheken op maat, lastig werk van de kant van externe partners, mogelijke beveiligingsproblemen (tenslotte , OAuth2.0 en OpenID Connect in de referentie-implementatie kunnen als veilig worden beschouwd, maar ik ben niet zeker van onze oplossing).

We hebben een aparte dienst gemaakt die een dienst emuleert voor het opslaan van persoonlijke gegevens om een ​​klein land-agnostisch model te creëren van een authenticatieprovider die naar een aparte dienst voor persoonlijke gegevens zou gaan (dit zou het in de toekomst mogelijk maken om één dienst te hebben met waarmee men in elk land kon inloggen met een accountregistratie en tegelijkertijd kon voldoen aan de AVG en andere federale wetten). Wij hebben dit onderdeel, net als de provider, gedaan en succesvol aan elkaar gekoppeld. Vervolgens was het nodig om een ​​API te creëren die zou worden beschermd door tokens uitgegeven door de provider, hun introspectie via de provider zou ondersteunen en beschermde gegevens zou retourneren als het verzoek voldeed aan het autorisatiebeleid (we controleren of de gebruiker is geverifieerd volgens het Bearer-schema , zijn token bevat een bepaalde reikwijdte + y De gebruiker heeft zelf een machtiging waarmee de oproep kan worden gedaan). Ook dit onderdeel is afgerond. Het laatste onderdeel was een JavaScript-client, die een token zou krijgen, met behulp waarvan hij een beschermde API zou aanroepen. We hadden geen tijd om dit deel te doen. Dat wil zeggen: het gehele functionele deel was gereed, maar het front-end gedeelte was nog niet gereed om de functionaliteit van het gehele systeem te demonstreren.

E-E-E (speelgoed)

Dima Afonchenko, Sasja Konovalov

We hebben een minispeeltje op Yunka gemaakt waarbij speelse handen worst op pizza gooien. Als je de worst verkeerd hebt aangebracht, verschijnt er een triest bericht "Afgewezen" op het scherm, en als alle worst correct is aangebracht, verschijnt er een willekeurig feit over pizza.

We wilden een tweede niveau maken met het gooien van tomaten, maar we hadden geen tijd.

Kort vervolg: wie heeft gewonnen?

Voorafgaand aan de hackathon spraken we met de jongens en ik vroeg welke prijs ze zouden willen ontvangen als ze winnen. Het bleek dat de meest waardevolle prijs ‘de weg naar voedsel’ zou zijn.

Verwacht daarom dat we binnenkort een spel aankondigen met handen die pepernoten op pizza leggen.

Zoals een oplettende lezer misschien heeft opgemerkt, heeft het team “E-E-E (speelgoed)” gewonnen. Gefeliciteerd jongens!

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Welk project vond jij het leukst?

• Oleg Leren (machine learning)

• GUI voor NOOBS

• KoerierGo

• M87

• Uh-uh

5 gebruikers hebben gestemd. 3 gebruikers onthielden zich van stemming.

Bron: www.habr.com