Kodim-pizza

Dobrý den, Habr. Spontánně jsme uspořádali náš první interní hackathon. Rozhodl jsem se s vámi podělit o své bolístky a závěry ohledně přípravy za 2 týdny a také o projekty, které se ukázaly být.

Nudná část pro zájemce 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 tentokrát v naší galaxii v plném proudu. Sobota. 20 týmů. Pizza. Všechno je velmi upřímné (důkazy). Po hale pluje nafukovací R2-D2. Týmy píší nejsprávnější algoritmy, aby zvládly nejnebezpečnější závod na mapě. Posouváme spuštění prvních závodů. Sušenky a káva jsou zachránce života. Pořadatelé i já jsme očekávali, že v sobotu po obědě hodně lidí odejde. Ale ne. 12 hodin kódování pozadu. Finále. Něco spadne, něco nezačne. Ale všichni jsou šťastní. Náš tým vyhrává. Máme dvojnásobnou radost.

Sdílím svou radost ve Slacku a napadá mě myšlenka: „Musíme udělat svůj vlastní hackathon.“ Píši na naši čerpací stanici Sasha. Umlčet.

Ráno. Piju kávu v kanceláři. Vidím, jak se zezadu blíží Saša. „Liso, to je skvělé! Máme důležité datum 21. dubna. Pojďme na to!" WTF!? Tak rychle? A? Co? Potřebuji v půlce dubna letět do Syktyvkaru na stáž. A k čertu s tím! Pojďme.

zbývají 2 týdny. Nikdy jsem nebyl jediným organizátorem hackathonu. Ať je to vnitřní. Četl jsem články na toto téma. Tvrdý. Trvá to několik měsíců. Je potřeba několik lidí. Musíte myslet na zboží, ceny, podmínky, harmonogram, zájem, pochopit cíl, rozpočty. Nebo možná i přijít na smysl života. Časově to určitě nestihnu. A zatímco jste četli a připravovali, uběhl už týden. Je čas zapomenout na články a začít něco dělat.

Podívejte se na náš kontrolní seznam pro uspořádání interního hackathonu za 1 týden

• Plán: V klidu si sednete a napíšete seznam toho, co je potřeba pro hackathon udělat. 30 minut.
• Úkol: Účastníci navrhují a vybírají projekty, které chtějí vytvořit v Tabulkách Google. Úkol na pozadí, 2 hodiny.
• Jízdní řád: na koleni napíšete krátký rozpis času s přihlédnutím ke 3 přestávkám a finále. 20 minut.
• Týmy: zveřejnit zprávu o hackathonu s harmonogramem od čerpací stanice v IT kanálech ve Slack/mail/atd a vytvořit samostatný kanál pro hackathon. V něm jsou všichni rozděleni do týmů a ti nerozhodnutí to dělají v prvních 5 minutách hackathonu. Úkol na pozadí, 2 hodiny.
• Buchty: vymyslíte zboží se dvěma vývojáři, předáte ho návrháři k vykreslení a dostanete ho připravený. Úkol na pozadí, 3 dny.
• Hackathon: přijdete do kanceláře, na začátku všechny zkoordinujete, jdete si za svým, čtete Reddit, důležité je oznamte každou přestávku o čerstvé pizze, vyfotíte západ slunce, vyhlásíte finále, společně hlasujete a vyberete vítěze. 1 den.
• Pod hvězdičkou: Samozřejmě neustále myslíš na to, aby všechno dobře dopadlo. Samozřejmě ne každý vaši zprávu uvidí a je lepší si s některými promluvit osobně. Samozřejmě, že pokud vám někdo pomůže, vše bude 2x jednodušší (mně pomohla úžasná Alena).

Ta méně nudná část o hackathonu

Proč 21. dubna? Tento den je pro nás významný. Přesně před rokem, 21. dubna, jsme během prvního víkendu po zahájení Federální reklamní kampaně propadli zátěži. Druhý den, v neděli, byl náš tým v práci od 8 hodin. Pak jsme vytvořili sundayhackathon board v Trello a začal týden práce na směny, 12 hodin denně. Situace byla tak kritická, že jsme ani neměli čas jíst a krmili nás kluci z jiných týmů.

Podrobnější příběh si můžete přečíst na Stránka Fjodora Ovčinnikova (náš generální ředitel). Od té doby jsme se hodně změnili, ale teď už na datum určitě nezapomeneme.

Letos jsme se rozhodli, že tuto akci stojí za to zachovat v paměti potomků a podle nejlepších tradic jsme uspořádali první interní hackathon v historii Dodo, který trval 10 hodin.

Nejnudnější část o projektech hackathonu

Upozornění: všechny popisy napsali kluci sami, takže autorství textu není moje.

Oleg Learning (strojové učení)

Dima Kochnev, Sasha Andronov (@alexandronov)

Chtěli vyrobit neuronovou síť, která by bez jakýchkoli znalostí určovala, jaká pizza je na fotce. Ve výsledku jsme vyrobili velmi jednoduchou a hračku - rozpozná 10 pizz, zhruba jsme přišli na to, jak vše funguje, maximálně za den (~10 hodin).

Zejména jsme si uvědomili, že průmysl dosáhl úrovně, kdy si běžný vývojář může vzít hotové knihovny, číst dokumentaci a trénovat svou neuronovou síť bez hlubokých znalostí tématu. A bude to fungovat dost dobře na vyřešení skutečných problémů.

Použité nástroje:

• imageai — pohodlná a jednoduchá knihovna pro práci se strojovým učením a počítačovým viděním.
• Vyzkoušeli jsme dva modely - ResNet50, Yolo.
• Kód byl napsán samozřejmě v Pythonu.

Měli jsme 11000 3 fotek, ale skoro 4/500 z nich se ukázaly jako smetí a zbytek měl jiné, nevhodné úhly. Ve výsledku jsme vzali hotový model (který prostě ví, jak najít pizzu) a s jeho pomocí jsme oddělili odpadky. Dále byl v názvu fotky název pizzy - roztřídili jsme ji tedy do složek, ale ukázalo se, že názvy se neshodují s realitou a museli jsme ji uklízet rukama. Nakonec zbylo asi 600-10 fotek, je jasné, že je to zanedbatelné množství, ale přesto to stačilo na oddělení XNUMX pizz od sebe.

Abychom trénovali grid, vzali jsme nejlevnější virtuální stroj v Azure na NVIDIA Tesla K80. Trénovali na tom 100 epoch, ale bylo jasné, že síť je po 50 epochách přesycená, kvůli tomu, že tam byl malý datový soubor.

Ve skutečnosti je celý problém v nedostatku dobrých dat.

Možná jsme si trochu spletli pojmy, ale musíme vzít v úvahu, že s prací se všemi těmito záležitostmi nemáme vůbec žádné zkušenosti.

GUI pro NOOBS (konzole pro objednávání pizzy)

Misha Kumachev (Ceridan), Zhenya Bikkinin, Zhenya Vasiliev

Dali jsme dohromady prototyp konzolové aplikace pro geeky, díky které si můžete objednat pizzu přes terminál nebo příkazový řádek, nebo ji dokonce integrovat do pipeline nasazení a po úspěšném vydání doručit pizzu do kanceláře.

Práce byla rozdělena do několika částí: přišli jsme na to, jak funguje naše API pro mobilní aplikace, sestavili jsme vlastní CLI pomocí oclif a nakonfigurovali publikování balíčku, který jsme shromáždili. Poslední úkol zahrnoval několik nepříjemných minut ke konci hackathonu. Vše nám fungovalo lokálně a dokonce i staré publikované verze balíčku fungovaly, ale nové (které přidaly další skvělé funkce a emotikony) odmítaly fungovat. Asi 40 minut jsme se snažili přijít na to, co se pokazilo, ale nakonec vše magicky fungovalo samo).

Naším maximálním programem pro hackathon byla skutečná objednávka pizzy do kanceláře přes naše CLI. Vše jsme spustili tucetkrát na zkušební stolici, ale stále se mi třásly ruce, když jsem ve výrobě zadával příkazy.

Ve výsledku jsme to nakonec udělali!

CourierGo

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

Vzali jsme myšlenku „aplikace pro kurýra“.

Pozadí o přípravě.Zpočátku jsem přemýšlel, jaké funkce by aplikace mohla obsahovat? Objevil se následující seznam funkcí:

• Aplikace se pomocí kódu přihlásí do doručovací pokladny.
• Aplikace okamžitě zobrazuje dostupné objednávky a objednávky, které je potřeba vyřídit.
• Kurýr zaznamená objednávku a vezme ji na cestu.
• Ukazuje se mu odhadovaný čas a zda jde včas nebo ne.
• Ukazuje klientovi, že kurýr odešel.
• Klientovi se začne na mapě zobrazovat bod kurýra a předpokládaný čas.
• Kurýr může napsat klientovi do chatu z aplikace.
• Klient může napsat kurýrovi přes chat z aplikace.
• Pět minut před příjezdem klient obdrží zprávu, že kurýr je blízko, buďte připraveni.
• Kurýr do přihlášky poznamená, že dorazil a čeká.
• Kurýr zavolá z aplikace jedním kliknutím a hlásí, že (roste, dorazil atd.)
• Klient přijme objednávku a zadá PIN kód z aplikace nebo SMS pro potvrzení doručení.(jako podpis) Aby kurýr nemohl dokončit doručení předem, pokud se opozdí.
• Objednávka je v systému označena jako doručená.

Plus pár alternativních scénářů:

• Kurýr může označit objednávku jako nedoručenou a vybrat důvod.
• Pokud se opozdíte, kurýr vám jedním tlačítkem vystaví elektronický certifikát prostřednictvím SMS. Nebo certifikát dorazí automaticky, pokud není dodržen termín dodání.

Pocit příslibu a nutnosti tohoto projektu byl samozřejmě energizující.

Druhý den jsme šli s týmem na oběd a probrali, jak bude vypadat minimální funkčnost aplikace.

V důsledku toho vznikl následující seznam toho, co bylo třeba na hackathonu udělat:

• Přihlášení do doručovací pokladny.
• Zobrazení aktuální polohy.
• Odeslání dat na externí API (koordinuje, přijal objednávku, doručil objednávku).
• Přijímat data z externího API (aktuální objednávky kurýrů).
• Odešlete událost oznamující, že jste objednávku převzali k doručení/doručení.
• Zobrazte aktuální pozici kurýra na mapě na webu.

Hlavní práce, jak se zdálo, spočívala ve vytvoření backendu, samotné aplikace (po diskuzích jsme pro vývoj aplikace, respektive frameworku pro ni, zvolili ReactNative - expo.io, což vám umožňuje vůbec nepsat nativní kód). Pokud jde o backend, zpočátku byla naděje ve Vanya Zverev, protože měl zkušenosti s prací s naší servisní šablonou a k8s (kterou práci převzal). Andrey Sarafanov a já jsme si vzali ReactNative na otočku.

Rozhodl jsem se zkusit okamžitě vytvořit funkční úložiště pro samotný projekt. Ve 12 v noci jsem narazil na to, že v ReactNative nefunguje dobře geolokace na pozadí, pokud nepíšete nativní kód, trochu mě to zamrzelo. Pak jsem to pustil, když jsem si uvědomil, že nečtu dokumentaci frameworku expo.io, ale ReactNative. Díky tomu jsem v průběhu večera již pochopil, jak získat aktuální pozici v expo.io a kreslit samostatné obrazovky (pro přihlášení, zobrazení objednávky atd.).

Ráno na hackathonu nalákali Gleba do svého superslibného projektu. Rychle přišli s plánem, co je potřeba udělat.

Udělali jsme chybu, když jsme se v souladu se šablonou projektu pokusili komunikovat nikoli přes HTTP, ale přes GRPC, protože nikdo nevěděl, jak postavit GRPC klienta pro JavaScript. Nakonec, poté, co jsme nad tím strávili asi hodinu a půl, jsme tento nápad opustili. Kvůli tomu začali kluci na back-endu předělávat hotový server z GRPC na WebApi. Po půl hodině jsme konečně mohli nastavit komunikaci mezi aplikací a backendem, ejhle. Ale ve stejnou dobu Gleb téměř dokončoval nasazení na k8s a plus automatické nasazení commitu na master. 🙂

MySQL jsme zvolili jako úložiště, abychom neriskovali alespoň s databází (přemýšleli jsme o CosmosDb).

V souhrnu:

• Implementováno ukládání aktuálních souřadnic kurýra z aplikace do databáze.
• Nainstalovali jsme RabbitMQ a přihlásili se k odběru zpráv o vyzvednutí objednávky kurýrem, abychom objednávku od kurýra okamžitě zobrazili v aplikaci.
• Čas doručení objednávky jsme začali ukládat do naší databáze poté, co kurýr zmáčkl tlačítko v aplikaci. Nestihli jsme přidat odeslání události zpět na rebbit, že objednávka byla doručena.
• Udělal jsem zobrazení mapy na stránce aktuální objednávky na webu s aktuální pozicí kurýra. Tato funkcionalita však zůstala trochu nedokončená, protože nebylo možné nakonfigurovat CORS v prostředí pro příjem souřadnic z naší nové služby.

M87

Roma Bukin, Gosha Polevoy (georgepolevoy), Arťom Trofimushkin

Chtěli jsme implementovat poskytovatele OpenID Connect, protože v současné době používáme autentizační protokol vlastní konstrukce, což přináší řadu potíží: vlastní klientské knihovny, nepohodlná práce ze strany externích partnerů, možné bezpečnostní problémy (koneckonců , OAuth2.0 a OpenID Connect v referenční implementaci lze považovat za bezpečné, ale nejsem si jistý naším řešením).

Vytvořili jsme samostatnou službu emulující službu pro ukládání osobních údajů, abychom vytvořili malý Country-Agnostic model poskytovatele autentizace, který by přešel na samostatnou službu pro osobní údaje (to by v budoucnu umožnilo mít jednu službu s ke kterému se lze přihlásit pomocí registrace účtu v jakékoli zemi a zároveň dodržovat GDPR a další federální zákony). Udělali jsme tuto část, stejně jako poskytovatel, a úspěšně jsme je propojili. Dále bylo nutné vytvořit API, které by bylo chráněno tokeny vydanými poskytovatelem, podporovalo jejich introspekci prostřednictvím poskytovatele a vracelo chráněná data, pokud by požadavek vyhovoval autorizačním zásadám (kontrolujeme, zda je uživatel autentizován podle schématu nositele , jeho token obsahuje určitý rozsah + y Sám uživatel má oprávnění, které umožňuje volání). I tato část byla dokončena. Poslední komponentou byl JavaScript klient, který by dostal token, s jehož pomocí by zavolal chráněné API. Na tuto část jsme neměli čas. To znamená, že celá funkční část byla připravena, ale front-endová část nebyla připravena demonstrovat funkčnost celého systému.

E-E-E (hračka)

Dima Afonchenko, Sasha Konovalov

Vyrobili jsme si minihračku na yunce, kde hravé ruce házejí klobásu na pizzu. Pokud klobásu nasadíte nesprávně, na obrazovce se objeví smutná zpráva „Odmítnuto“ a pokud byla klobása nasazena správně, objeví se náhodný fakt o pizze.

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

Krátké pokračování: kdo vyhrál?

Před hackathonem jsme se s klukama bavili a zeptal jsem se, jakou cenu by chtěli dostat, kdyby vyhráli. Ukázalo se, že nejcennější cenou bude „cesta k jídlu“.

Očekávejte proto, že brzy oznámíme hru s rukama, které dávají feferonky na pizzu.

Jak si pozorný čtenář mohl všimnout, vyhrál tým „E-E-E (hračka)“. Gratuluji kluci!

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.

Který projekt se vám nejvíce líbil?

• Oleg Learning (strojové učení)

• GUI pro NOOBS

• CourierGo

• M87

• E-E-E

Hlasovalo 5 uživatelů. 3 uživatelů se zdrželo hlasování.

Zdroj: www.habr.com