🥇Kodujemy–pizza

Cześć, Habr. Spontanicznie zorganizowaliśmy pierwszy wewnętrzny hackathon. Postanowiłam podzielić się z Wami moimi przemyśleniami i wnioskami o przygotowaniach do niego, które zajęły 2 tygodnie, a także projektami, które powstały.

Nudna część dla tych, którzy interesują się marketingiem

Zacznę od małej historii.

Początek kwietnia. W naszym biurze odbywa się pierwszy hackathon MskDotNet Community. Walka o Tatooine trwa, w naszej galaktyce tym razem. Sobota. 20 zespołów. Pizza. Wszystko bardzo przyjemnie (dowody). Napuchnięty R2-D2 krąży po sali. Zespoły piszą najlepsze algorytmy, aby pokonać najniebezpieczniejszy wyścig na mapie. Przesuwamy start pierwszych wyścigów. Ciasteczka i kawa pomagają. My z organizatorami spodziewaliśmy się, że w sobotę wielu odejdzie po obiedzie. Ale nie. 12 godzin kodowania za nami. Finał. Coś się psuje, coś nie działa. Ale wszyscy są szczęśliwi. Wygrywa nasz zespół. Cieszymy się podwójnie.

Dzielę się radością w Slacku i wpada mi do głowy pomysł: „Musimy zorganizować nasz hackathon”. Piszę do naszego CTO Saszy. Cisza.

Poranek. Piję kawę w biurze. Widzę podchodzącego od tyłu Saszę. „Liza, to świetnie! Mamy przecież 21 kwietnia ważną datę. Zróbmy to!” Co do cholery!? Tak szybko? Co? Muszę lecieć do Syktywkaru na staż w połowie kwietnia. Ale co tam! Zróbmy to.

Zostają 2 tygodnie. Nigdy nie byłam jedynym organizatorem hackathonu. Nawet wewnętrznego. Czytam artykuły na ten temat. Hardkor. Potrzebne kilka miesięcy. Potrzebne kilka osób. Trzeba przemyśleć merch, nagrody, warunki, harmonogram, zainteresować, zrozumieć cel, budżety. A może nawet zastanowić się nad sensem życia. Na pewno nie zdążę. A podczas gdy czytałeś i się przygotowywałeś, już minęły 2 tygodnie. To idealny moment, żeby przestać czytać artykuły i zacząć coś robić.

Oto nasza lista kontrolna przeprowadzenia wewnętrznego hackathonu w ciągu 1 tygodnia.

Plan: spokojnie siadasz i spisujesz listę rzeczy do zrobienia na hackathon. 30 minut.
Zadanie: uczestnicy sami proponują i wybierają projekty, które chcą stworzyć w Google Sheets. Zadanie tła, 2 godziny.
Harmonogram: na kolanie piszesz krótką rozpiskę czasową z uwzględnieniem 3 przerw i finału. 20 minut.
Polecenia: publikujesz wiadomość o hackathonie z harmonogramem od CTO w IT-kanałach w Slacku/poczcie/etc i tworzysz osobny kanał dla hackathonu. W nim wszyscy dzielą się na zespoły, a niezdecydowani robią to w pierwsze 5 minut hackathonu. Zadanie tła, 2 godziny.
Dodatki: wymyślasz merch z dwoma programistami, oddajesz go projektantowi do narysowania, otrzymujesz gotowy. Zadanie w tle, 3 dni.
Hackathon: przychodzisz do biura, koordynujesz wszystkich na początku, zajmujesz się swoimi sprawami, czytasz Reddit, z ważnym wyrazem twarzy informujesz o świeżej pizzy w każdym przerwie, fotografujesz zachód słońca, ogłaszasz finał, wszyscy wspólnie głosujecie i wybieracie zwycięzcę. 1 dzień.
Pod gwiazdką: oczywiście, ciągle myślisz o tym, żeby wszystko poszło dobrze. Oczywiście, nie wszyscy zobaczą twoją wiadomość i z niektórymi lepiej porozmawiać osobiście. Oczywiście, jeśli ktoś ci pomoże, wszystko będzie dwa razy łatwiejsze (pomagała mi wspaniała Alena).

Mniej nudna część o dacie hackathonu

Dlaczego 21 kwietnia? Ten dzień jest dla nas znaczący. Równo rok temu, 21 kwietnia załamał się pod obciążeniem podczas pierwszego weekendu po rozpoczęciu Federalnej Kampanii Reklamowej. Następnego dnia, w niedzielę, nasz zespół był w pracy od 8 rano. Wtedy stworzyliśmy w Trello tablicę sundayhackathon i zaczęła się tydzień pracy zmianowej po 12 godzin dziennie. Sytuacja była na tyle krytyczna, że nie mieliśmy nawet czasu na jedzenie, a chłopaki z innych zespołów nas dokarmiali.

Bardziej szczegółową opowieść można przeczytać na stronie Fiodora Owczinnikowa (naszego CEO). Od tego czasu wiele się zmieniło, ale tę datę na pewno zapamiętamy.

W tym roku postanowiliśmy, że to wydarzenie warto uwiecznić dla potomnych i w najlepszej tradycji zorganizowaliśmy pierwszy w historii Dodo wewnętrzny hackathon, który trwał 10 godzin.

Najbardziej interesująca część o projektach hackathonu

Disclaimer: wszelkie opisy napisali sami chłopcy, więc autorstwo tekstu nie jest moje.

Oleg Learning (machine learning)

Dima Kočniew, Sasha Andronow (@alexandronov)

Chcieli stworzyć sieć neuronową, która rozpoznałaby, jaka pizza znajduje się na zdjęciu bez żadnej wiedzy. Ostatecznie zrobiliśmy bardzo prostą i zabawkową – rozpoznaje 10 pizz, mniej więcej ogarnęliśmy, jak to wszystko działa, tak jak było to możliwe w ciągu dnia (~10 godzin).

W szczególności zrozumieliśmy, że przemysł osiągnął poziom, na którym zwykły programista może wziąć gotowe biblioteki, przeczytać dokumentację i nauczyć swoją sieć neuronową bez głębokiej wiedzy na temat. I będzie ona działać wystarczająco dobrze w rozwiązywaniu rzeczywistych problemów.

Narzędzia, które użyliśmy:

imageai — wygodna i prosta biblioteka do pracy z uczeniem maszynowym i widzeniem komputerowym.
Wypróbowaliśmy dwa modele – ResNet50, Yolo.
Kod pisaliśmy, jak można się domyślić, w Pythonie.

Mieliśmy 11000 zdjęć, ale praktycznie 3/4 z nich okazały się być nieprzydatne, a w pozostałych były różne, nieodpowiednie kąty. W końcu wzięliśmy gotowy model (który potrafi tylko znajdować pizzę) i dzięki niemu oddzieliliśmy najgorsze zdjęcia. Dalej, w nazwach zdjęć było imię pizzy — tak rozdzieliliśmy je do folderów, ale okazało się, że nazwy nie zgadzają się z rzeczywistością i trzeba było ręcznie poprawić. Ostatecznie zostało około 500-600 zdjęć, co oczywiście jest niewielką liczbą, ale mimo to wystarczyło, aby oddzielić 10 pizz od siebie.

Do treningu sieci wzięliśmy najtańszą wirtualną maszynę w Azure z NVIDIA Tesla K80. Na niej uczyliśmy przez 100 epok, ale było widać, że sieć była przesycona już po 50 epokach, ponieważ mieliśmy mały zbiór danych.

Właściwie – cały problem leży w braku dobrych danych.

Możliwe, że trochę pomyliliśmy terminy, ale trzeba pamiętać, że nie mamy doświadczenia w pracy z tymi wszystkimi rzeczami.

GUI dla NOOBS (terminal do zamawiania pizzy)

Misha Kumachyov (Ceridan), Zhenya Bikyinin, Zhenya Vasiliev

Zbudowaliśmy prototyp aplikacji konsolowej dla geeków, dzięki której można zamówić pizzę przez terminal lub wiersz poleceń, a nawet zintegrować ją w pipeline deploy i dostarczać pizzę do biura przy udanym wydaniu.

Praca została podzielona na kilka części: analizowaliśmy, jak działa nasze API dla aplikacji mobilnych, budowaliśmy własne CLI przy użyciu oclif i konfigurowaliśmy publikację stworzonego przez nas pakietu. Ostatnie zadanie wiązało się z kilkoma nieprzyjemnymi chwilami pod koniec hackathonu. Wszystko działało lokalnie, a nawet działały stare opublikowane wersje pakietu, ale nowe (w których dodano więcej fajnych funkcji i emotikonów) odmawiały współpracy. Spędziliśmy około 40 minut, aby zrozumieć, co poszło nie tak, ale ostatecznie wszystko magicznie zaczęło działać).

Naszym maksymalnym celem na hackathonie było prawdziwe zamówienie pizzy do biura przez nasze CLI. Dziesiątki razy testowaliśmy to na testowym stanowisku, ale wciąż miałem drżące ręce, gdy wpisywałem komendy w wersji produkcyjnej.

W rezultacie – udało nam się to zrobić!

CourierGo

Anton Bruzmelёv (author), Vanja Zverev, Gleb Lesnikov (entropia), Andrey Sarafanov

Wzięliśmy pomysł na „Aplikację dla kuriera”.

Historia przygotowania.Na początku zastanawiałem się, jakie funkcje mogą być w aplikacji? Powstała mniej więcej taka lista funkcjonalności:

Aplikacja loguje się do kasy dostawy po kodzie.
W aplikacji od razu widać dostępne zamówienia oraz zamówienia do podjęcia.
Kurier zaznacza zamówienie i zabiera je w trasę.
Pokazywane jest mu przewidywane czas przybycia oraz czy zdąży czy nie.
Klient widzi, że kurier wyruszył.
Klient zaczyna widzieć lokalizację kuriera na mapie oraz przewidywany czas.
Kurier może napisać do klienta na czacie z aplikacji.
Klient może napisać do kuriera na czacie z aplikacji.
Na pięć minut przed przyjazdem klient otrzymuje wiadomość, że kurier jest blisko, bądź gotowy.
Kurier zaznacza w aplikacji, że dotarł i czeka.
Kurier dzwoni z aplikacji jednym kliknięciem i informuje, że (przybywa, podszedł itp.)
Klient akceptuje zamówienie i wprowadza pin z aplikacji lub SMS dla potwierdzenia dostawy (jak podpis). Aby kurier nie mógł zakończyć dostawy wcześniej, jeśli się spóźnia.
Zamówienie oznaczane jest w systemie jako dostarczone.

Plus kilka alternatywnych scenariuszy:

Kurier może zaznaczyć zamówienie jako niedostarczone i wybrać powód.
Kurier, w przypadku spóźnienia, może jednym kliknięciem wysłać elektroniczny certyfikat przez SMS. Lub certyfikat przychodzi automatycznie w przypadku nieprzestrzegania terminu dostawy.

Odczuwałem perspektywiczność i potrzebę tego projektu, to oczywiście motywowało.

Następnego dnia poszliśmy z zespołem na lunch i omówiliśmy, jak będzie wyglądać minimalna funkcjonalność aplikacji.

W efekcie powstała następująca lista tego, co trzeba było zrobić na hackathonie:

Logowanie do kasy dostawy.
Wyświetlenie aktualnej pozycji.
Wysłanie danych do zewnętrznego API (koordynaty, wzięte zamówienie, dostarczone zamówienie).
Otrzymanie danych z zewnętrznego API (aktualne zamówienia kuriera).
Wysłanie zdarzenia, że wzięto zamówienie na dostawę/dostarczono.
Wyświetlenie aktualnej pozycji kuriera na mapie na stronie.

Główna praca, jak to widziałem, miała polegać na stworzeniu backendu, samej aplikacji (po dyskusjach wybraliśmy ReactNative do rozwoju aplikacji, dokładniej obudowę nad nim — expo.io, co pozwala w ogóle nie pisać natywnego kodu). W planie backendu początkowo była nadzieja na Wanię Zwierewa, jako doświadczonego w pracy z naszym szablonem usług i k8s (jaką pracę na siebie wziął). ReactNative wziąłem pod uwagę razem z Andriejem Sarafanowem.

Postanowiłem spróbować od razu stworzyć działające repozytorium dla samego projektu. O 12 w nocy natknąłem się na to, że w ReactNative geolokalizacja słabo działa w tle, jeśli nie piszesz natywnego kodu, co mnie trochę sfrustrowało. Później to mnie opuściło, gdy zrozumiałem, że czytam dokumentację nie frameworka expo.io, a ReactNative. Ostatecznie wieczorem już wiedziałem, jak uzyskać bieżącą lokalizację w expo.io i rysować oddzielne ekrany (dla logowania, wyświetlania zamówienia itd.).

Rano na hackathonie wciągnęliśmy Glebę do naszego superperspektywicznego projektu. Szybko naszkicowaliśmy plan tego, co trzeba zrobić.

Popełniliśmy błąd, gdy zgodnie z szablonem projektu próbowaliśmy zrealizować komunikację nie przez HTTP, a przez GRPC, ponieważ nikt nie potrafił zbudować klienta GRPC dla JavaScript. W rezultacie, poświęcając na to około półtorej godziny, porzuciliśmy ten pomysł. Z tego powodu chłopcy zaczęli przebudowywać gotowy serwer z GRPC na WebApi. Po pół godzinie w końcu udało nam się ustawić komunikację aplikacji z backendem, cud. Ale w tym samym czasie Gleb prawie kończył wdrożenie w k8s i dodatkowo autowdrożenie po commicie do mastera. 🙂

Jako magazyn wybraliśmy MySQL, aby nie ryzykować przynajmniej z bazą danych (były myśli o CosmosDb).

W rezultacie:

Zrealizowaliśmy zapisywanie bieżących współrzędnych kuriera z aplikacji w bazie.
Podłączyliśmy RabbitMQ i zapisaliśmy się na wiadomości o odebraniu zamówienia przez kuriera, aby natychmiast wyświetlać zamówienie kuriera w aplikacji.
Zaczęliśmy zapisywać w naszej bazie czas dostawy zamówienia, po tym jak kurier naciskał przycisk w aplikacji. Nie zdążyliśmy dodać wysyłania zdarzenia z powrotem do RabbitMQ o tym, że zamówienie zostało dostarczone.
Zrobiłem wyświetlanie mapy na stronie currentorder na stronie z bieżącą lokalizacją kuriera. Ale ta funkcjonalność pozostała lekko niedokończona, ponieważ na środowisku nie udało się skonfigurować CORS do uzyskania współrzędnych z naszej nowej usługi.

M87

Roma Bukin, Gosza Polewoj (georgepolevoy), Artiom Trofimuszkin

Chcieliśmy stworzyć dostawcę OpenID Connect, ponieważ obecnie używamy protokołu uwierzytelniania opracowanego wewnętrznie, co wiąże się z szeregiem trudności: niestandardowe biblioteki klienckie, niewygodna współpraca z partnerami zewnętrznymi, a także potencjalne problemy z bezpieczeństwem (w końcu OAuth2.0 i OpenID Connect w swoich standardowych implementacjach można uznać za bezpieczne, a co do naszego rozwiązania — nie jestem pewny).

Stworzyliśmy osobny serwis, emulujący serwis przechowywania danych osobowych, aby stworzyć mały model dostawcy uwierzytelniania niezależnego od kraju, który pozyskiwałby dane osobowe z osobnego serwisu (w przyszłości dawałoby to możliwość posiadania jednego serwisu, z którego można się logować przy użyciu konta w dowolnym kraju, a jednocześnie spełniać wymagania RODO i innych ustaw). Tę część zrealizowaliśmy, podobnie jak dostawcę, i udało nam się je ze sobą powiązać. Następnie należało stworzyć API, które byłoby zabezpieczone tokenami wydawanymi przez dostawcę, obsługiwać ich introspekcję przez dostawcę i przekazywać zabezpieczone dane, jeśli żądanie spełniałoby polityki autoryzacji (sprawdzamy, czy użytkownik jest uwierzytelniony w schemacie Bearer, czy w jego tokenie zawarty jest określony zakres + czy sam użytkownik ma uprawnienie zezwalające na wykonanie wywołania). Ta część również została zrealizowana. Ostatnim komponentem był klient JavaScript, któremu wydawany byłby token, za pomocą którego mógłby wołać zabezpieczone API. Tę część niestety nie zdążyliśmy wykonać. To znaczy, cała funkcjonalność była gotowa, ale część front-endowa nie została przygotowana do zaprezentowania działania całego systemu.

E-E-E (gra)

Dima Afonczenko, Sasza Konowalow

Stworzyliśmy mini-grę w Unity, w której zręczne ręce wrzucają kiełbaskę na pizzę. W przypadku niepoprawnego wrzucenia kiełbaski na ekranie pojawia się smutny napis „Odrzucone”, a jeśli cała kiełbaska zostanie wrzucona poprawnie, pojawia się losowy fakt o pizzy.

Chcieliśmy zrobić drugi poziom z wrzucaniem pomidorów, ale nie zdążyliśmy.

Krótki ciąg dalszy: kto zwyciężył?

Przed hackathonem rozmawialiśmy z chłopakami, a ja pytałem, jaką nagrodę chcieliby otrzymać, jeśli wygrają. Okazało się, że najcenniejszą nagrodą byłaby „droga do produkcji”.

Dlatego wkrótce oczekujcie od nas zapowiedzi gry z rękami, które rzucają pepperoni na pizzę.