Ahoj, Habr. Náhodou jsme uspořádali první interní hackathon. Rozhodla jsem se podělit o své bolesti a závěry z přípravy na něj během dvou týdnů, stejně jako o projektech, které vznikly.

Nudná část pro ty, kdo se zajímají o marketing.
Začnu malým příběhem.
Začátek dubna. V naší kanceláři probíhá první hackathon MskDotNet Community. Bitva o Tatooine je v plném proudu, tentokrát v naší galaxii. Sobota. 20 týmů. Pizza. Všechno je velmi příjemné (). Nafukovací R2-D2 se motá po sále. Týmy píší ty nejlepší algoritmy, aby zvládly nejnebezpečnější závod na mapě. Posunujeme start prvních závodů. Sušenky a káva nám pomáhají. S organizátory jsme očekávali, že v sobotu mnozí odejdou po obědě. Ale ne. 12 hodin kódování za námi. Finále. Něco se odpojuje, něco nenastartuje. Ale všichni jsou šťastní. Vyhrává náš tým. Jsme šťastní dvojnásobně.
Sdílím radost na Slacku a do hlavy se mi dostane myšlenka: „Musíme uspořádat svůj hackathon.” Píšu našemu CTO Sašovi. Ticho.
Ráno. Piji kávu v kanceláři. Vidím Sašu přicházet zezadu. „Lizo, to je skvělé! Máme přesně 21. dubna důležitý termín. Pojďme to udělat!” Cože!? Tak rychle? A? Co? Musím letět do Syktyvkaru na stáž v polovině dubna. Ale kašlu na to! Pojďme.
Zbývá 2 týdny. Nikdy jsem nebyla jediným organizátorem hackathonu. I když je to interní. Čtu články na toto téma. Šílené. Potřebuje to několik měsíců. Potřebuje to několik lidí. Je třeba promyslet merch, ceny, podmínky, harmonogram, zaujmout, pochopit cíl, rozpočty. A možná se dokonce zamyslet nad smyslem života. Určitě to nezvládnu. A zatímco jsi četl a připravoval se, už uplynul týden. Nejvyšší čas zahodit články a začít něco dělat.
Zde je náš checklist pro uspořádání interního hackathonu za 1 týden.
- Plán: v klidu si sedni a napiš seznam toho, co je třeba udělat pro hackathon. 30 minut.
- Úkol: účastníci sami navrhují a vybírají projekty, které chtějí vytvořit v Google Sheets. Pozadí úkolu, 2 hodiny..
- Harmonogram: na koleno napíš krátké rozvržení času s ohledem na 3 přestávky a finále. 20 minut.
- Příkazy: zveřejni zprávu o hackathonu s harmonogramem od CTO v IT kanálech na Slacku/e-mailu/etc. a vytvoř zvláštní kanál pro hackathon. V něm se všichni rozdělí do týmů, a ti, kdo se nerozhodli, to udělají během prvních 5 minut hackathonu. Pozadí úkolu, 2 hodiny..
- Bonusy: Přemýšlíš o merchandise se dvěma vývojáři, předáváš to designerovi na návrh, dostáváš hotové. Pozadí úkol, 3 dny.
- Hackathon: Příjdeš do kanceláře, v začátku koordinuješ všechny, zabýváš se svými věcmi, čteš Reddit, vážným tónem oznamuješ každou pauzu o čerstvé pizze, fotíš západ slunce, vyhlašuješ finále, společně hlasujete a vybíráte vítěze. 1 den.
- Pod hvězdičkou: Samozřejmě neustále přemýšlíš o tom, aby vše probíhalo dobře. Určitě ne každý uvidí tvou zprávu a s některými je lepší mluvit osobně. Samozřejmě, pokud ti někdo bude pomáhat, všechno bude dvakrát jednodušší (pomáhala mi úžasná Alena).
Méně nudná část o datu hackathonu
Proč 21. dubna? Tento den je pro nás významný. Přesně před rokem, 21. dubna, jsme padli pod zátěží během prvního víkendu po startu Federální reklamní kampaně. Následující den, v neděli, byla naše tým v práci od 8 ráno. Tenkrát jsme vytvořili na Trellu desku sundayhackathon a začal týden směnné práce po 12 hodin každý den. Situace byla tak kritická, že jsme ani neměli čas jíst a kluci z jiných týmů nás krmili.

Podrobnější příběh si můžete přečíst na (našeho CEO). Od té doby jsme hodně změnili, ale tuto datum určitě nezapomeneme.
Letos jsme se rozhodli, že tuto akci stojí za to uchovat v paměti budoucích generací a v nejlepších tradicích jsme uspořádali první v historii Dodo interní hackathon, který trval 10 hodin.
Nejnudnější část o projektech hackathonu
Upozornění: všechny popisy psali kluci sami, takže autorství textu není moje.
Oleg Lërning (strojové učení)
Dima Kočnev, Saša Andronov (@alexandronov)
Chtěli jsme vytvořit neuronovou síť, která by určovala, co je za pizza na fotografii bez jakýchkoli znalostí. Nakonec jsme udělali velmi jednoduchou a hrací – rozpoznává 10 pizz, přibližně jsme pochopili, jak to všechno funguje, jak je to možné za den (~10 hodin).

Konkrétně jsme pochopili, že průmysl dosáhl úrovně, kdy běžný vývojář může vzít hotové knihovny, přečíst dokumentaci a vyškolit svou neuronovou síť bez hlubokých znalostí předmětu. A bude fungovat dost dobře pro řešení reálných úloh.
Nástroje, které jsme používali:
- — pohodlná a jednoduchá knihovna pro práci s strojovým učením a počítačovým viděním.
- Vyzkoušeli jsme dva modely – ResNet50, Yolo.
- Kód jsme psali, jak jinak, v Pythonu.
Měli jsme 11000 fotek, ale téměř 3/4 z nich se ukázaly jako odpad, a ve zbývajících byly různé, nevhodné úhly. Nakonec jsme vzali hotový model (který jen umí najít pizzu) a s jeho pomocí jsme oddělili ten nejhorší obsah. Dále, v názvu fotky bylo jméno pizzy — tak jsme to roztřídili do složek, ale ukázalo se, že názvy neodpovídají skutečnosti a museli jsme to ručně upravit. Nakonec zbylo asi 500-600 fotek, což je očividně zanedbatelné množství, ale přesto to bylo dost, abychom odlišili 10 pizz od sebe.
Pro trénink sítě jsme vzali nejlevnější virtuální stroj v Azure s NVIDIA Tesla K80. Na něm jsme trénovali po 100 epoch, ale bylo vidět, že síť se již po 50 epochách přetížila, protože dataset byl malý.
A vlastně — celým problémem je nedostatek kvalitních dat.

My jsme možná trochu zamotali termíny, ale je třeba vzít v úvahu, že nemáme žádné zkušenosti s prací na všech těchto věcech.
GUI for NOOBS (konzole pro objednání pizzy)
Misha Kumachev (), Zhenya Bikkinin, Zhenya Vasiliev
Sestavili jsme prototyp konzolové aplikace pro geeky, díky kterému lze objednat pizzu přes terminál nebo příkazový řádek, nebo dokonce integrovat do deployment pipeline a při úspěšném vydání doručit pizzu do kanceláře.

Práce se rozdělila na několik částí: zkoumali jsme, jak funguje naše API pro mobilní aplikace, vytvářeli jsme vlastní CLI s pomocí a nastavovali publikaci námi vytvořeného balíčku. S posledním úkolem jsme měli pár nepříjemných chvil blízko konce hackathonu. Mělo nám to všechno fungovat lokálně a dokonce i staré publikované verze balíčku fungovaly, ale nové (do kterých bylo přidáno více skvělých funkcí a emotikonů) nechtěly fungovat. Strávili jsme asi 40 minut tím, abychom pochopili, co se stalo, ale nakonec to nějak magicky začalo fungovat samo).
Naším maximálním cílem na hackathonu byl skutečný objednávka pizzy do kanceláře přes naše CLI. Desetkrát jsme všechno testovali na zkušebním místě, ale stejně jsem měl nervy, když jsem zadával příkazy na produkci.

Nakonec — přece jsme to dokázali!

CourierGo
Anton Bruzhmelov (autor), Vanya Zverev, Gleb Lesnikov (), Andrey Sarafanov
Vzali jsme myšlenku „Aplikace pro kurýra“.
Pozadí přípravy.Nejprve jsem uvažoval, jaké vlastně funkce by mohly být v aplikaci? Vznikl zhruba takový seznam funkcionality:
- Aplikace se přihlásí do pokladny dopravy pomocí kódu.
- V aplikaci jsou ihned vidět dostupné objednávky a objednávky, které je třeba vzít.
- Kurýr označí objednávku a vezme ji na cestu.
- Jsou mu zobrazeny odhadované časy a zda stihne objednávku nebo ne.
- Zákazníkovi se zobrazuje, že kurýr vyjel.
- Zákazníkovi se začne zobrazovat poloha kurýra na mapě a odhadovaný čas.
- Kurýr může napsat zákazníkovi do chatu z aplikace.
- Zákazník může napsat kurýrovi do chatu z aplikace.
- Pět minut před příjezdem zákazník dostane zprávu, že kurýr je blízko, buďte připraveni.
- Kurýr v aplikaci označuje, že přijel a čeká.
- Kurýr může z aplikace jedním kliknutím zavolat a oznámit, že (přichází, je poblíž apod.)
- Zákazník přijímá objednávku a zadává PIN kód z aplikace nebo SMS pro potvrzení dodání (jako podpis). Aby kurýr nemohl dodání dokončit předčasně, pokud má zpoždění.
- Objednávka je v systému oznámena jako dodaná.
Plus pár alternativních scénářů:
- Kurýr může označit objednávku jako nedodanou a vybrat důvod.
- Kurýr může při zpoždění jedním kliknutím vydat elektronický certifikát prostřednictvím SMS. Nebo certifikát přijde automaticky při nedodržení doby dodání.
Pocit perspektivity a potřebnosti tohoto projektu samozřejmě nabíjel.
Druhý den jsme šli s týmem na oběd a probrali, jak bude vypadat minimální funkcionalita aplikace.
Nakonec se utvořil následující seznam toho, co bylo třeba stihnout na hackathonu:
- Přihlášení do pokladny dopravy.
- Zobrazit aktuální polohu.
- Odeslat data do externího API (souřadnice, vzal objednávku, doručil objednávku).
- Získat data z externího API (aktuální objednávky kurýra).
- Odeslat událost o tom, že vzal objednávku k dodání/doručil.
- Zobrazit aktuální polohu kurýra na mapě na webových stránkách.
Hlavní práce, jak se jevilo, byla v tvorbě backendu, samotné aplikace (po diskusích jsme zvolili ReactNative pro vývoj aplikace, přesněji obal nad ním — , což umožňuje vůbec nepsat nativní kód). Co se týče backendu, původně jsme měli naději na Vanyu Zvereva, který měl zkušenosti s naším šablonovým servisem a k8s (což vzal na sebe). ReactNative jsme vzali na zkoušku já a Andrej Sarafanov.
Rozhodl jsem se hned vytvořit pracovní repozitář pro samotný projekt. Ve 12 hodin v noci jsem narazil na problém, že v ReactNative špatně funguje geolokace na pozadí, pokud se nenapíše nativní kód, a byl jsem trochu frustrovaný. Poté se to uvolnilo, když jsem si uvědomil, že čtu dokumentaci pro framework expo.io, nikoli ReactNative. Nakonec jsem za večer už pochopil, jak v expo.io získat aktuální polohu a vykreslit samostatné obrazovky (pro přihlášení, zobrazení objednávky atd.).

Ráno na hackatonu jsme nalákali Gleb na náš velmi perspektivní projekt. Rychle jsme sestavili plán toho, co je třeba udělat.

Udělali jsme chybu, když jsme se podle šablony projektu pokusili navázat komunikaci nikoli přes HTTP, ale přes GRPC, protože nikdo nevěděl, jak sestavit GRPC klienta pro JavaScript. Nakonec, po zhruba hodině a půl, jsme tuto myšlenku opustili. Kvůli tomu začali kluci na backendu předělávat hotový server z GRPC na WebApi. Po půl hodině se nám konečně podařilo nastavit komunikaci aplikace s backendem, co je zázrak. Ale v téže době Gleb téměř dokončil nasazení do k8s a plus automatické nasazení po commitu do masteru. 🙂
Jako úložiště jsme zvolili MySQL, abychom neriskovali alespoň s databází (byly myšlenky na CosmosDb).

Nakonec:
- Realizovali jsme ukládání aktuálních souřadnic kurýra z aplikace do databáze.
- Připojili jsme RabbitMQ a přihlásili se k zprávám o převzetí objednávky kurýrem, abychom mohli okamžitě zobrazit objednávku u kurýra v aplikaci.
- Začali jsme si do databáze ukládat čas doručení objednávky, poté co kurýr stiskl tlačítko v aplikaci. Nestihli jsme přidat odeslání události zpět do RabbitMQ, že objednávka byla doručena.
- Udělal jsem zobrazení mapy na stránce currentorder na webu s aktuální polohou kurýra. Ale tato funkčnost zůstala trošku nedokončená, protože na prostředí se nepodařilo nastavit CORS pro získání souřadnic z našeho nového servisu.
M87
Roma Boukin, Gosha Polevoy (), Artyom Trofimushkin
Chtěli jsme implementovat poskytovatele OpenID Connect, protože v současnosti používáme vlastní autentizační protokol, což přináší řadu obtíží: vlastní klientské knihovny, nepohodlná spolupráce s externími partnery, možné problémy s bezpečností (protože OAuth 2.0 a OpenID Connect v referenční implementaci lze považovat za bezpečné, zatímco u našeho řešení si tím nejsem tak jistý).

Vytvořili jsme samostatnou službu emulující úložiště osobních údajů, abychom vytvořili malý model Country-Agnostic poskytovatele autentizace, který by mohl získávat osobní údaje z této samostatné služby (to by v budoucnu umožnilo mít jednu službu, pomocí které by bylo možné přihlásit se pomocí účtu v jakékoli zemi a zároveň splnit požadavky GDPR a dalších předpisů). Tuto část jsme provedli, stejně jako poskytovatele, a úspěšně je propojili. Dále bylo potřeba vytvořit API, které by bylo chráněno tokeny, které vydává poskytovatel, podporovat jejich introspekci přes poskytovatele a vracet chráněná data, pokud by žádost splňovala politiky autorizace (ověřujeme, že uživatel je autentizován podle schématu Bearer, v jeho tokenu je určitý rozsah + sám uživatel má povolení, které umožňuje provedení výzvy). Tato část byla také dokončena. Poslední komponentou byl JavaScript klient, kterému by byl vydán token, pomocí kterého by volal chráněné API. Tuto část se nám nepodařilo dokončit. To znamená, že byla připravena celá funkční část, ale frontendová část pro demonstraci funkčnosti celého systému nebyla hotová.
E-E-E (hračka)
Dima Afončenko, Saša Konovalov
Vytvořili jsme mini-hračku na Unity, kde rychlé ruce hází klobásu na pizzu. V případě, že klobásu hodíš špatně, na obrazovce se objeví smutný nápis „Zamítnuto“, a pokud je celá klobása házena správně, objeví se náhodný fakt o pizze.

Chtěli jsme udělat druhou úroveň s házením rajčat, ale nestihli jsme to.

Krátké pokračování: kdo se stal vítězem?
Před hackathonem jsme se bavili s kluky a ptala jsem se jich, jakou cenu by chtěli získat, pokud vyhrají. Ukázalo se, že nejcennější cenou by byla „cesta do produkce“.

Brzy se od nás dočkáte oznámení o hře se skleničkami, které na pizzu posypávají pepperoni.
Jak si mohl všimnout pozorný čtenář, vyhrál tým „E-E-E (hra)“. Gratulujeme klukům!
Pouze registrovaní uživatelé se mohou účastnit ankety. , prosím.
Který projekt se vám líbil nejvíc?
Oleg Lërning (strojové učení)
GUI pro NOOBS
CourierGo
M87
E-E-E
Hlasovalo 5 uživatelů. Zdrželi se 3 uživatelé.
Zdroj: habr.com
