Witaj, Habr. Spontanicznie zorganizowaliśmy nasz pierwszy wewnętrzny hackaton. Postanowiłam podzielić się z Wami moimi bolączkami i wnioskami z przygotowań do niego w 2 tygodnie, a także projektami, które okazały się być.
Nudna część dla osób zainteresowanych marketingiem
Zacznę od małej historii.
Początek kwietnia. W naszym biurze odbywa się pierwszy hackaton społeczności MskDotNet. Tym razem bitwa o Tatooine w naszej galaktyce toczy się pełną parą. Sobota. 20 drużyn. Pizza. Wszystko jest bardzo szczere (). Po sali unosi się nadmuchiwany R2-D2. Zespoły piszą najpoprawniejsze algorytmy, aby przejść najniebezpieczniejszy wyścig na mapie. Przesuwamy start pierwszych wyścigów. Ciasteczka i kawa ratują życie. Organizatorzy i ja spodziewaliśmy się, że wiele osób wyjdzie w sobotę po obiedzie. Ale nie. 12 godzin kodowania za mną. Finał. Coś odpada, coś się nie zaczyna. Ale wszyscy są szczęśliwi. Nasz zespół wygrywa. Jesteśmy podwójnie szczęśliwi.
Dzielę się swoją radością na Slacku i przychodzi mi do głowy pomysł: „Musimy zrobić własny hackaton”. Piszę do naszej stacji obsługi Sasha. Cisza.
Poranek. Piję kawę w biurze. Widzę Saszę zbliżającą się od tyłu. „Lisa, to jest świetne! 21 kwietnia mamy ważną datę. Zróbmy to!" WTF!? Tak szybko? A? Co? Muszę lecieć do Syktywkaru na staż w połowie kwietnia. I do cholery z tym! Chodźmy.
zostały 2 tygodnie. Nigdy nie byłem jedynym organizatorem hackatonu. Niech to będzie wewnętrzne. Czytałem artykuły na ten temat. Trudny. Zajmuje to kilka miesięcy. Potrzebnych jest kilka osób. Musisz pomyśleć o towarach, nagrodach, warunkach, harmonogramie, zainteresowaniach, zrozumieć cel i budżety. A może nawet odkryje sens życia. Na pewno nie zdążę. A kiedy czytałeś i przygotowywałeś się, minął już tydzień. Czas zapomnieć o artykułach i zacząć coś robić.
Zapoznaj się z naszą listą kontrolną dotyczącą zorganizowania wewnętrznego hackathonu za tydzień
- plan: Siadasz spokojnie i piszesz listę rzeczy do zrobienia w ramach hackatonu. 30 minutowych opcjach.
- Zadanie: uczestnicy proponują i wybierają projekty, które chcą utworzyć w Arkuszach Google. Zadanie w tle, 2 godziny.
- Harmonogram: na kolanie zapisujesz krótki podział czasu, biorąc pod uwagę 3 przerwy i finał. 20 minutowych opcjach.
- Polecenia: opublikuj wiadomość o hackatonie wraz z harmonogramem ze stacji serwisowej w kanałach IT w Slack/mail/etc i utwórz osobny kanał dla hackathonu. W nim wszyscy podzieleni są na zespoły, a niezdecydowani robią to w ciągu pierwszych 5 minut hackatonu. Zadanie w tle, 2 godziny.
- Bułeczki: wymyślasz gadżet z dwoma programistami, przekazujesz go projektantowi do renderowania i otrzymujesz gotowy. Zadanie w tle, 3 dni.
- Hackathon: przychodzisz do biura, koordynujesz wszystkich na początku, zajmujesz się swoimi sprawami, czytasz Reddita, co ważne ogłaszasz każdą przerwę na świeżą pizzę, robisz zdjęcia zachodu słońca, ogłaszasz finał, wspólnie głosujecie i wybieracie zwycięzcę. 1 dni.
- Pod gwiazdką: Oczywiście ciągle myślisz o tym, żeby wszystko poszło dobrze. Oczywiście nie każdy zobaczy Twoją wiadomość i lepiej z kimś porozmawiać osobiście. Oczywiście, jeśli ktoś ci pomoże, wszystko stanie się 2 razy łatwiejsze (pomogła mi cudowna Alena).
Mniej nudna część dotycząca daty hackatonu
Dlaczego 21 kwietnia? Ten dzień jest dla nas znaczący. Dokładnie rok temu, 21 kwietnia, w pierwszy weekend po rozpoczęciu Federalnej Kampanii Reklamowej wpadliśmy pod obciążeniem. Następnego dnia, w niedzielę, nasza ekipa była w pracy od godz. 8 rano. Następnie stworzyliśmy tablicę niedzielnego hackatonu w Trello i rozpoczął się tydzień pracy zmianowej, po 12 godzin dziennie. Sytuacja była tak krytyczna, że nie mieliśmy nawet czasu na jedzenie i karmili nas chłopaki z innych drużyn.
Bardziej szczegółową historię można przeczytać na stronie (nasz dyrektor generalny). Od tego czasu bardzo się zmieniliśmy, ale teraz na pewno nie zapomnimy tej daty.
W tym roku uznaliśmy, że warto utrwalić to wydarzenie w pamięci potomnych i zgodnie z najlepszą tradycją zorganizowaliśmy pierwszy w historii Dodo wewnętrzny hackaton, który trwał 10 godzin.
Najnudniejsza część projektów hackathonowych
Zastrzeżenie: wszystkie opisy zostały napisane przez samych chłopaków, więc autorstwo tekstu nie jest moje.
Oleg Learning (uczenie maszynowe)
Dima Kochnev, Sasha Andronov (@alexandronov)
Chcieli stworzyć sieć neuronową, która bez żadnej wiedzy określałaby, jaki rodzaj pizzy znajduje się na zdjęciu. W rezultacie zrobiliśmy bardzo prosty i zabawkowy - rozpoznaje 10 pizz, z grubsza zorientowaliśmy się, jak wszystko działa, w miarę możliwości w ciągu jednego dnia (~10 godzin).
W szczególności zdaliśmy sobie sprawę, że branża osiągnęła poziom, w którym zwykły programista może wziąć gotowe biblioteki, przeczytać dokumentację i wytrenować swoją sieć neuronową bez głębokiej wiedzy na ten temat. I będzie działać wystarczająco dobrze, aby rozwiązać rzeczywiste problemy.
Narzędzia użyte:
- — wygodna i prosta biblioteka do pracy z uczeniem maszynowym i wizją komputerową.
- Wypróbowaliśmy dwa modele - ResNet50, Yolo.
- Kod został napisany oczywiście w Pythonie.
Mieliśmy 11000 3 zdjęć, ale prawie 4/500 z nich okazało się śmieciami, a reszta miała inne, nieodpowiednie kąty. W rezultacie wzięliśmy gotowy model (który po prostu wie, jak znaleźć pizzę) i za jego pomocą segregowaliśmy śmieci. Następnie w tytule zdjęcia znalazła się nazwa pizzy - więc posortowaliśmy ją w foldery, ale okazało się, że nazwy nie pokrywały się z rzeczywistością i trzeba było to sprzątać rękami. Ostatecznie zostało około 600-10 zdjęć, wiadomo, że to niewielka ilość, ale mimo to wystarczyła, aby oddzielić od siebie XNUMX pizz.
Do trenowania sieci wykorzystaliśmy najtańszą maszynę wirtualną na platformie Azure na platformie NVIDIA Tesla K80. Trenowali na nim przez 100 epok, jednak było jasne, że po 50 epokach sieć uległa przesyceniu, ze względu na mały zbiór danych.
Właściwie cały problem polega na braku dobrych danych.
Być może trochę pomyliliśmy pojęcia, ale musimy wziąć pod uwagę, że nie mamy żadnego doświadczenia w pracy z tymi wszystkimi sprawami.
GUI dla NOOBS (konsola do zamawiania pizzy)
Misza Kumaczow (), Żenia Bikkinin, Żenia Wasiliew
Stworzyliśmy prototyp aplikacji konsolowej dla maniaków, dzięki której możesz zamówić pizzę przez terminal lub linię poleceń, a nawet zintegrować ją z potokiem wdrożenia i po pomyślnym wydaniu dostarczyć pizzę do biura.
Pracę podzieliliśmy na kilka części: zorientowaliśmy się, jak działa nasze API dla aplikacji mobilnych, zbudowaliśmy przy jego pomocy własne CLI i skonfigurowałem publikację zebranej przez nas paczki. Ostatnie zadanie wiązało się z kilkoma nieprzyjemnymi minutami pod koniec hackathonu. Wszystko działało dla nas lokalnie i nawet stare opublikowane wersje pakietu działały, ale nowe (które dodały więcej fajnych funkcji i emotikonów) nie działały. Spędziliśmy około 40 minut, próbując dowiedzieć się, co poszło nie tak, ale ostatecznie wszystko w magiczny sposób zadziałało samo).
Naszym maksymalnym programem na hackaton było realne zamówienie pizzy do biura poprzez nasze CLI. Uruchomiliśmy wszystko kilkanaście razy na stanowisku testowym, ale ręce wciąż mi się trzęsły, gdy wprowadzałem polecenia w produkcji.
Dzięki temu w końcu nam się to udało!
KurierGo
Anton Bruzhmelev (autor), Wania Zverev, Gleb Lesnikov (), Andriej Sarafanow
Wpadliśmy na pomysł „Aplikacji dla Kuriera”.
Tło dotyczące przygotowań.Początkowo zastanawiałem się, jakie funkcje może znaleźć się w aplikacji? Pojawiła się następująca lista funkcjonalności:
- Aplikacja loguje się do kasy dostawczej za pomocą kodu.
- Aplikacja od razu pokazuje dostępne zamówienia oraz zamówienia, które należy zrealizować.
- Kurier notuje zamówienie i zabiera je w podróż.
- Pokazuje mu szacowany czas i to, czy jest na czas, czy nie.
- Pokazuje klientowi, że kurier odjechał.
- Klientowi zaczyna wyświetlać się punkt kuriera na mapie i szacowany czas.
- Kurier może napisać do klienta na czacie z poziomu aplikacji.
- Klient może napisać do kuriera za pośrednictwem czatu z poziomu aplikacji.
- Na pięć minut przed przyjazdem klient otrzymuje wiadomość, że kurier już blisko, bądź przygotowany.
- Kurier zaznacza we wniosku, że przyjechał i czeka.
- Kurier jednym kliknięciem dzwoni z aplikacji i melduje, że (wstaje, przyjechał itp.)
- Klient akceptuje zamówienie i w celu potwierdzenia dostawy wprowadza kod PIN z aplikacji lub SMS-a (w formie podpisu), aby kurier w przypadku spóźnienia nie mógł zrealizować dostawy wcześniej.
- Zamówienie zostaje oznaczone w systemie jako dostarczone.
Plus kilka alternatywnych scenariuszy:
- Kurier może oznaczyć zamówienie jako niedostarczone i wybrać przyczynę.
- W przypadku spóźnienia kurier jednym przyciskiem może wystawić certyfikat elektroniczny za pomocą wiadomości SMS. Lub certyfikat dotrze automatycznie, jeśli termin dostawy nie zostanie dotrzymany.
Poczucie obietnicy i konieczności tego projektu było oczywiście energetyzujące.
Następnego dnia poszliśmy z zespołem na lunch i omówiliśmy, jak będzie wyglądać minimalna funkcjonalność aplikacji.
W rezultacie powstała następująca lista rzeczy do zrobienia na hackatonie:
- Zaloguj się do kasy dostawczej.
- Wyświetl aktualną pozycję.
- Wyślij dane do zewnętrznego API (współrzędne, otrzymałeś zamówienie, dostarczyłeś zamówienie).
- Otrzymuj dane z zewnętrznego API (bieżące zamówienia kurierskie).
- Wyślij zdarzenie wskazujące, że przyjąłeś zamówienie na dostawę/dostarczono.
- Wyświetl aktualną pozycję kuriera na mapie w serwisie.
Główna praca, jak się wydawało, polegała na stworzeniu backendu, samej aplikacji (po dyskusjach wybraliśmy ReactNative do opracowania aplikacji, a raczej frameworku dla niej - , co pozwala w ogóle nie pisać kodu natywnego). Jeśli chodzi o backend, początkowo pokładano nadzieję w Vanyi Zverevie, ponieważ miał on doświadczenie w pracy z naszym szablonem usługi i k8s (którego zadania się podjął). Andrey Sarafanov i ja wzięliśmy udział w ReactNative.
Postanowiłem spróbować od razu stworzyć działające repozytorium dla samego projektu. O 12 w nocy natknąłem się na fakt, że geolokalizacja w tle nie działa dobrze w ReactNative, jeśli nie piszesz kodu natywnego, byłem trochę sfrustrowany. Potem odpuściłem, gdy zdałem sobie sprawę, że czytam dokumentację nie frameworka expo.io, ale ReactNative. W rezultacie przez cały wieczór zrozumiałem już, jak uzyskać aktualną pozycję w expo.io i narysować osobne ekrany (do logowania, wyświetlania zamówień itp.).
Rano na hackatonie zwabili Gleba do swojego super obiecującego projektu. Szybko obmyślili plan, co należy zrobić.
Popełniliśmy błąd, gdy zgodnie z szablonem projektu próbowaliśmy komunikować się nie poprzez HTTP, a poprzez GRPC, ponieważ nikt nie wiedział, jak zbudować klienta GRPC dla JavaScript. Ostatecznie, po spędzeniu nad tym około półtorej godziny, porzuciliśmy ten pomysł. Z tego powodu ludzie z backendu zaczęli przerabiać gotowy serwer z GRPC na WebApi. Po pół godzinie w końcu udało nam się nawiązać komunikację pomiędzy aplikacją a backendem i oto proszę. Ale w tym samym czasie Gleb prawie kończył wdrażanie na k8s i dodatkowo automatyczne wdrażanie zatwierdzenia na serwerze głównym. 🙂
Jako magazyn wybraliśmy MySQL, aby przynajmniej nie ryzykować z bazą danych (myśleliśmy o CosmosDb).
W skrócie:
- Wprowadzono zapisywanie aktualnych współrzędnych kuriera z aplikacji do bazy danych.
- Zainstalowaliśmy RabbitMQ i zasubskrybowaliśmy komunikaty o odbiorze zamówienia przez kuriera, aby od razu wyświetlić w aplikacji zamówienie od kuriera.
- Zaczęliśmy zapisywać czas realizacji zamówienia w naszej bazie danych po naciśnięciu przez kuriera przycisku w aplikacji. Nie mieliśmy czasu dodać odesłania zdarzenia do rebbita, że zamówienie zostało dostarczone.
- Zrobiłem mapę wyświetlającą się na stronie bieżącego zamówienia w serwisie z aktualną pozycją kuriera. Ale ta funkcjonalność pozostała trochę niedokończona, ponieważ nie było możliwości skonfigurowania CORS w środowisku do otrzymywania współrzędnych z naszej nowej usługi.
M87
Roma Bukin, Gosha Polevoy (), Artem Trofimuszkin
Chcieliśmy wdrożyć dostawcę OpenID Connect, ponieważ w tej chwili używamy protokołu uwierzytelniania własnej konstrukcji, a to stwarza szereg trudności: niestandardowe biblioteki klienckie, niewygodna praca ze strony partnerów zewnętrznych, możliwe problemy z bezpieczeństwem (w końcu , OAuth2.0 i OpenID Connect w implementacji referencyjnej można uznać za bezpieczne, jednak nie jestem pewien co do naszego rozwiązania).
Stworzyliśmy osobną usługę emulującą usługę przechowywania danych osobowych, aby stworzyć mały, niezależny od kraju model dostawcy uwierzytelniania, który przechodziłby do osobnej usługi dla danych osobowych (dzięki temu w przyszłości możliwe byłoby posiadanie jednej usługi z do których można się zalogować rejestrując konto w dowolnym kraju, a jednocześnie przestrzegać RODO i innych przepisów federalnych). Zrobiliśmy tę część, podobnie jak dostawca, i pomyślnie połączyliśmy je ze sobą. Następnie należało stworzyć API, które byłoby chronione tokenami wydawanymi przez dostawcę, wspierać ich introspekcję za pośrednictwem dostawcy i zwracać chronione dane, jeśli żądanie spełniało zasady autoryzacji (sprawdzamy, czy użytkownik jest uwierzytelniony zgodnie ze schematem Bearer , jego token ma określony zakres + y Użytkownik sam ma uprawnienia umożliwiające wykonanie połączenia). Ta część również została ukończona. Ostatnim komponentem był klient JavaScript, który otrzymywał token, za pomocą którego wywoływał chronione API. Nie mieliśmy czasu na zrobienie tej części. Oznacza to, że cała część funkcjonalna była gotowa, ale część front-end nie była gotowa do zademonstrowania funkcjonalności całego systemu.
E-E-E (zabawka)
Dima Afonczenko, Sasza Konowałow
Zrobiliśmy mini-zabawkę na yunkę, w której rozbrykane ręce rzucają kiełbasę na pizzę. Jeśli źle ułożysz kiełbasę, na ekranie pojawi się smutny komunikat „Odrzucono”, a jeśli wszystkie kiełbasy zostaną prawidłowo ułożone, pojawi się losowy fakt dotyczący pizzy.
Chcieliśmy zrobić drugi poziom z rzucaniem pomidorów, ale nie mieliśmy czasu.
Krótka kontynuacja: kto wygrał?
Przed hackatonem rozmawialiśmy z chłopakami i zapytałem, jaką nagrodę chcieliby otrzymać, jeśli wygrają. Okazało się, że najcenniejszą nagrodą będzie „droga do jedzenia”.
Dlatego spodziewajcie się, że wkrótce ogłosimy grę z rękami, które układają pepperony na pizzę.
Jak uważny czytelnik mógł zauważyć, zwyciężyła drużyna „E-E-E (zabawka)”. Gratulacje Panowie!
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Który projekt podobał Ci się najbardziej?
-
Oleg Learning (uczenie maszynowe)
-
GUI dla NOOBSów
-
KurierGo
-
M87
-
E-E-E
Głosowało 5 użytkowników. 3 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com