🥇Кодим–пицца

Здравей, Хабр. Спонтанно проведохме първия вътрешен хакатон. Реших да споделя с вас моите притеснения и изводи относно подготовката за него за 2 седмици, а също така и проектите, които се получиха.

Скучната част за тези, които се интересуват от маркетинг

Ще започна с кратка история.

Началото на април. В нашия офис се провежда първият хакатон на MskDotNet Community. Битката за Татуин е в разгара си, този път в нашата галактика. Събота. 20 отбора. Пица. Всичко е много приятно (доказателства). Надуваемият R2-D2 се появява в залата. Отборите пишат най-правилните алгоритми, за да преминат през най-опасното състезание на картата. Преместваме старта на първите надбягвания. Бисквитите и кафето спасяват. Ние с организаторите очаквахме, че в събота много хора ще си тръгнат следобед. Но не. 12 часа кодиране зад гърба. Финал. Нещо се разпада, нещо не стартира. Но всички са доволни. Нашият отбор печели. Ние сме двойно щастливи.

Споделям радостта в Slack и в главата ми идва идея: "Трябва да направим свой хакатон". Пиша на нашия CTO Саша. Тишина.

Сутрин. Пия кафе в офиса. Виждам, че Саша идва отзад. "Лиза, това е страхотно! На 21 април имаме важна дата. Нека го направим!" WTF!? Толкова бързо? А? Какво? Трябва да отлетя за Сыктывкар на стажировка в средата на април. Но да е дяволът! Хайде.

Остават 2 седмици. Никога не съм била единствен организатор на хакатон. Нека е и вътрешен. Чета статии по темата. Ужас. Нужни са месеци. Нужни са няколко души. Трябва да се помисли за мерч, награди, условия, график, да се заинтересуват, да се разбере целта, бюджетите. Може би трябва дори да се позанимавам с смисъла на живота. Определено не мога да се справя навреме. И докато четеше и се подготвяше, вече е минала една седмица. Най-доброто време е да се откажа от статиите и да започна да правя нещо.

Ето нашия чеклист за провеждане на вътрешен хакатон за 1 седмица

План: спокойно сядате и пишете списък с нещата, които трябва да направите за хакатона. 30 минути.
Задача: участниците сами предлагат и избират проектите, които искат да създадат в Google Sheets. Фоново занимание, 2 часа.
График: на коленете пишете кратка разбивка по време с 3 паузи и финал. 20 минути.
Екипи: публикувате съобщение за хакатона с графика от CTO в IT-каналите в Slack/имейл/и др. и създавате отделен канал за хакатона. В него всички се разделят на отбори, а нерешилите се организират в първите 5 минути на хакатона. Фоново занимание, 2 часа.
Бонуси.: измисляш мърч с двама разработчици, предаваш на дизайнера за оформление, получаваш готовото. Фоново задание, 3 дни.
Хакатон: идваш в офиса, координираш всички в началото, занимаваш се със своите дела, четеш Reddit, с важен вид съобщаваш всеки休ение за свежа пица, снимаш залеза, обявяваш финала, заедно гласувате и избирате победител. 1 ден.
Под звездичката: разбира се, постоянно мислиш за това, как всичко да мине добре. Разбира се, не всеки ще види съобщението ти и с някои е по-добре да говориш лично. Разбира се, ако някой ти помага, всичко става два пъти по-лесно (ми помагаше чудесната Алена).

По-малко скучната част за датата на хакатона

Защо 21 април? Тази дата е важна за нас. Точно година назад, на 21 април, се провалихме под натоварването по време на първите уикенди след старта на Федералната Рекламна Кампания. На следващия ден, в неделя, нашият екип беше на работа от 8 сутринта. Тогава създадохме в Trello дъската sundayhackathon и започна седмица на сменна работа по 12 часа на ден. Ситуацията беше толкова критична, че нямаше време дори да ядем и ни хранеха момчетата от другите екипи.

По-подробен разказ можете да прочетете на страницата на Фьодор Овчинников (нашия СЕО). Оттогава много се е променило, но датата вече не можем да забравим.

Тази година решихме, че събитието заслужава да бъде увековечено в паметта на поколенията и в най-добрите традиции организирахме първия в историята на Додо вътрешен хакатон, който продължи 10 часа.

Най-нескучната част за проектите на хакатона

Отказ: всички описания написаха самите момчета, така че авторството на текста не е мое.

Олег Лърнинг (машинно обучение)

Дима Кочнев, Саша Андронов (@alexandronov)

Искахме да създадем невронна мрежа, която да определя каква е пицата на снимката без каквито и да било знания. В крайна сметка направихме много проста и играчка – тя разпознава 10 пици, почти разбрахме как всичко е устроено, колкото е възможно за ден (~10 часа).

По-специално, разбрахме, че индустрията е достигнала ниво, при което обикновеният разработчик може да вземе готови библиотеки, да прочете документацията и да обучи своята невронна мрежа без дълбоки знания по темата. И тя ще работи достатъчно добре за решаване на реални задачи.

Инструментите, които използвахме:

imageai — удобна и проста библиотека за работа с машинно обучение и компютърно зрение.
Изпробвахме два модела – ResNet50, Yolo.
Кодът беше написан, разбира се, на Python.

Имахме 11000 снимки, но почти 3/4 от тях се оказаха безполезни, а останалите бяха с различни, неподходящи ъгли. В крайна сметка взехме готова модель (която просто може да открива пица) и с нейната помощ отделихме най-неподходящите снимки. След това, в имената на снимките имаше имената на пиците — така ги разпределихме по папки, но се оказа, че имената не съвпадат с действителността и тук вече трябваше да почистим на ръка. В крайна сметка останаха около 500-600 снимки, разбира се, че това е малко количество, но все пак, това се оказа достатъчно, за да разделим 10 пици една от друга.

За обучението на мрежата използвахме най-евтината виртуална машина в Azure на NVIDIA Tesla K80. На нея обучавахме в 100 епохи, но беше видно, че мрежата е пренаситена още след 50 епохи, тъй като имаше малък набор от данни.

Същината на проблема е в отсъствието на добри данни.

Може би малко объркваме термините, но трябва да се има предвид, че нямаме никакъв опит с всичко това.

GUI за ЗАЧЕВАЩИ (конзола за поръчка на пица)

Миша Кумачёв (Ceridan), Женя Биккинин, Женя Васильев

Събрахме прототип на конзолно приложение за гикове, благодарение на което може да се поръча пица през терминала или командната редица, или дори да се вгради в pipeline за деплой и при успешен релиз да се доставя пица в офиса.

Работата беше разделена на няколко части: разбирахме как работи нашият API за мобилни приложения, събирахме собствен CLI с помощта на oclif и конфигурирахме публикуването на събрания от нас пакет. С последната задача имаше няколко неприятни минути близо до края на хакатона. Всичко работеше локално и дори работеха старите публикувани версии на пакета, но новите (в които бяха добавени още готини функции и емоджита) отказаха да работят. Прекарахме около 40 минути, за да разберем какво е сбъркано, но в крайна сметка всичко магически заработи само по себе си).

Нашата програма максимум за хакатона беше реална поръчка на пица в офиса чрез нашия CLI. Десетина пъти всичко преминахме на тестов стенд, но моите ръце все още трепереха, когато въвеждах командите на продукцията.

В крайна сметка — все пак го направихме!

CourierGo

Антон Бружмелёв (автор), Ваня Зверев, Глеб Лесников (entropy), Андрей Сарафанов

Взехме идеята "Приложение за куриер".

Предистория за подготовката.Първоначално си помислих, какви функции могат да бъдат в приложението? Появи се следният списък с функционалности:

Приложението влиза в касата на доставчика с код.
В приложението веднага се виждат наличните поръчки и поръчките, които трябва да се вземат.
Куриерът отбелязва поръчката и я взема за пътуване.
На него се показва изчисленото време и дали успява или не.
На клиента се показва, че куриерът е тръгнал.
На клиента започва да се показва местоположението на куриера на картата и изчислено време.
Куриерът може да пише на клиента в чата от приложението.
Клиентът може да пише на куриера в чата от приложението.
Пет минути преди пристигането клиентът получава съобщение, че куриерът е близо, бъдете готови.
Куриерът отбелязва в приложението, че е пристигнал и чака.
Куриерът може да се обади от приложението с едно кликване и да съобщи, че (идва, е дошъл и т.н.)
Клиентът приема поръчката и въвежда пин кода от приложението или СМС за потвърждение на доставката. (като подпис) За да не може куриерът да завърши доставката предварително, ако закъснява.
Поръчката се отбелязва в системата като доставена.

Плюс няколко алтернативни сценария:

Куриерът може да отбележи поръчката като недоставена и да избере причина.
Куриерът, при закъснение, може с едно натискане да изпрати електронен сертификат чрез СМС. Или сертификатът идва автоматично при неспазване на срока за доставка.

Чувството за перспектива и необходимостта от този проект, разбира се, зареждаше.

На следващия ден отидохме с екипа на обяд и обсъдихме как ще изглежда минималната функционалност на приложението.

В крайна сметка изникна следният списък с нещата, които предстои да бъдат направени на хакатона:

Логин в касата на доставчика.
Да се покаже текущото местоположение.
Да се изпратят данни към външно API (координати, взех поръчката, доставих поръчката).
Да се получат данни от външно API (текущите поръчки на куриера).
Да се изпрати събитие за това, че е взета поръчката за доставка/доставена.
Да се покаже текущото местоположение на куриера на картата в сайта.

Основната работа, както изглеждаше, ще бъде в създаването на бекенда, самото приложение (след обсъждания избрахме ReactNative за разработка на приложението, по-точно обвивката над него — expo.io, позволяваща изобщо да не се пише нативен код). По отношение на бекенда първоначално имаше надежда на Ваня Зверев, като опитен в работата с нашия шаблон на услугата и k8s (каква работа пое той). ReactNative взехме да тестваме аз и Андрей Сарафанов.

Реших веднага да създам работен репозиторий за самия проект. В 12 през нощта се натъкнах, че в ReactNative геолокацията не работи добре във фона, ако не се пише нативен код, което ме фрустрира малко. После ме отпусна, когато разбрах, че чета документацията не на expo.io фреймворка, а на ReactNative. В крайна сметка за вечерта вече ми беше ясно как да получа текущото местоположение в expo.io и как да рисувам отделни екрани (за вход, показване на поръчка и т.н.).

Сутринта на хакатона привлечеха Глеб в своя свръхперспективен проект. Бързо накиснахме план на това, което трябва да се направи.

Направихме грешка, когато в съответствие с шаблона на проекта се опитахме да направим комуникация не през HTTP, а през GRPC, тъй като никой не знаеше как да събере GRPC-клиента за JavaScript. В крайна сметка, изразходвайки за това около един час и половина, се отказахме от тази идея. Поради това, момчетата започнаха да преработват готовия сървър от GRPC на WebApi. След половин час, най-накрая, успяхме да настроим комуникацията на приложението с бекенда, о, чудо. Но в същото време Глеб почти завърши деплоя в k8s и плюс автодеплой при комитване в мастер. 🙂

Като хранилище избрахме MySQL, за да не рискуваме поне с базата (имахме мисли за CosmosDb).

Резултат:

Реализирахме запазването на текущите координати на куриера от приложението в базата.
Свързахме RabbitMQ и се абонирахме за съобщения за вземане на поръчката от куриера, за да покажем веднага поръчката в приложението на куриера.
Започнахме да запазваме времето за доставка на поръчката в базата, след като куриерът натисне бутона в приложението. Не успяхме да добавим изпращането на събитието обратно в RabbitMQ, че поръчката е доставена.
Създадох показ на картата на страницата currentorder на сайта с текущото местоположение на куриера. Но този функционал остана малко недовършен, тъй като на средата не успяхме да настроим CORS за получаване на координатите от нашата нова услуга.

M87

Рома Букин, Гоша Полевой (georgepolevoy), Артём Трофимушкин

Искахме да реализираме OpenID Connect доставчик, тъй като в момента ползваме протокол за удостоверяване, разработен от нас, което създава редица трудности: персонализирани клиентски библиотеки, неудобна работа от страна на външни партньори, възможни проблеми със сигурността (все пак OAuth2.0 и OpenID Connect в своеобразната им реализация могат да се считат за безопасни, докато относно нашето решение — не съм сигурен).

Създадохме отделен сервис, емулиращ сервис за съхранение на лични данни, за да разработим малка модел на Country-Agnostic доставчик на удостоверяване, който да извиква лични данни от отделен сервис (в дългосрочен план това би позволило да имаме един сервис, чрез който да можем да се логнем с акаунт от всяка страна и същевременно да отговаряме на GDPR и другите закони). Тази част я реализирахме, както и доставчика, и успешно ги свързахме помежду си. След това трябваше да създадем API, който да бъде защитен с токени, издавани от доставчика, да поддържа тяхната интроспекция чрез доставчика и да предава защитени данни, ако заявката отговаря на политиките за авторизация (проверяваме, че потребителят е удостоверен по схемата Bearer, в неговия токен съдържа определен обхват + самият потребител има разрешение, което позволява извикването). Тази част също беше изпълнена. Последният компонент беше JavaScript клиент, който би получил токен, с помощта на който да извиква защитения API. Тази част не успяхме да завършим. Тоест, готова беше цялата функционалност, но не беше готова фронтенд част за демонстриране на работоспособността на цялата система.

Е-Е-Е (игра)

Дима Афонченко, Саша Коновалов

Създадохме мини-игра на юньке, където бързите ръце хвърлят колбас върху пица. В случай, че колбасът бъде неправилно хвърлен, на екрана се появява тъжно съобщение "Отхвърлено", а ако колбасът е хвърлен правилно, се появява произволен факт за пицата.

Искахме да направим второ ниво с хвърляне на домати, но не успяхме.

Кратко продължение: кой спечели?

Преди хакатона разговаряхме с момчетата и попитах каква награда биха искали да получат, ако спечелят. Оказа се, че най-ценната награда ще бъде "път към прод".

Затова, в скоро време очаквайте от нас анонс на играта с ръчички, която добавя пеперонки върху пицата.