Как мы судили на чемпионате России по спортивному программированию
В начале ноября так сложились обстоятельства, что мне с коллегой довелось поучаствовать в качестве судей на мероприятии под строгим названием «Отборочный этап чемпионата России по спортивному программированию» в дисциплине «Продуктовое программирование». Или, говоря более простым языком — студенческий трехдневный онлайн-хакатон, победители которого поедут на финал чемпионата страны в Москву.
Вот об этом мероприятии, что на нём было интересного и каких-то выводах из увиденного сегодня и поговорим.
Дано
Для начала расскажем о самом мероприятии. Главным организатором здесь выступает не какое-то частное лицо, а Федерация спортивного программирования. Я в первый момент закатил глаза, подумав что-то типа: «Ну что там за очередную чухню со странным названием придумали», но оказалось, что это вполне себе находящаяся в ведении Министерства спорта так называемая Общероссийская физкультурно-спортивная общественная организация (оставим чиновничий канцелярит на совести тех, кому он нужен), со временем повышенная до звания Общероссийской спортивной федерации по виду спорта «Спортивное программирование». Или, переводя на человеческий язык — спортивное программирование — это признанный государством вид спорта (о чём есть запись в соответствующем реестре), со всеми полагающимися вещами: федерацией, турнирами и прочими чемпионатами.
Вот вам скриншотик с пруфами из Всероссийского реестра видов спорта
И вот под крылом этой прекрасной организации и устраивается тот самый чемпионат России по спортивному программированию. Наша компания, Postgres Professional, поддерживает этот чемпионат, поэтому нам предложили придумать задание для этапа, посвящённого продуктовой разработке, и принять участие в оценке работ в составе судейской бригады.
Немного об организации процесса. Не знаю как для команд-участниц, но с судейской колокольни всё выглядело суперорганизованным и чётким. В самом начале мы сформулировали задание, которое было отправлено на согласование в федерацию. Получив вышестоящий Ок, был проведён установочный звонок, где мы познакомились с организаторами, и нам рассказали, что и когда будет происходить, что там от нас ожидается и прочие организационные штуки. В целом, основная задача — это посетить два чека для отсеивания слабых команд и итоговый питч, где выставить оценки для определения прошедших в следующий тур. Словом, от процесса получали только удовольствие.
Несмотря на то, что этап проходил онлайн, для всех значимых событий проводилась трансляция из студии, что, несомненно, приносит плюсик в карму организаторам. Вот, например, открытие соревнований.
Задание
Итак, мы, Михаил Жилин и Александр Фатин, оба трудимся в компании Postgres Professional. Миша руководит группой, отвечающей за производительность наших решений, а я скромный DevRel. И раз этап называется Продуктовое программирование, мы попилили роли: Миша был больше за программирование, я был больше за продукт.
Соответственно, мы постарались сформулировать задание таким образом, чтобы оно не выглядело как теория, высосанная из пальца, а решало реальную проблему, и в дальнейшем, при наличии желания, ребята могли бы довести свой проект до ума, прикрутить монетизацию, вывести проект на рынок или чего они там сами захотят с ним делать.
Наше задание называлось так: Smart-мониторинг базы данных PostgreSQL через бот в Telegram. После оглашения случился шквал вопросов, которые, в принципе, были вполне ожидаемы, так что давайте разберём происходящее немного подробней.
Почему такой узкий кейс? Что вообще за постгрес такой?
Тут всё просто, конечно. Традиционно (не спрашивайте почему), в вузах курс по базам ведётся на MySQL, так что у большинства студентов выработалась чёткая нейронная связь: Вижу БД, читаю MySQL. Но так уж получилось, что в реальном мире Postgres распространён не меньше и зачастую используется охотней. Да и мы работаем в компании, которая занимается его разработкой, так что экспертиза наша именно в нём.
С каких пор написать бота стало равно написать продукт?
Типичное искажение начинающих специалистов. Все привыкли что бот в телеге — это некая однозадачная сущность, состоящая из одного файлика, с максимально простым функционалом. Но об этом будет правильнее поговорить в следующем пункте.
Зачем писать какого-то бота, если в этом мире уже придуманы Zabbix, Prometheus и далее по списку? И что вообще за smart-мониторинг такой?
Вот тут ребят ждало главное открытие. Мониторинг это не про собрать циферки со счётчиков, а про их интерпретацию и принятие решений. А сделать продукт — это не просто написать код бота, а подумать над моделью его использования, какие боли он может снять с админа БД и чем будет полезен.
В качестве затравки в какую сторону копать, мы предложили подумать над различными ситуациями, в которых бот сможет очень сильно выручить админа. Например, он ушёл из офиса домой, по пути зашёл в магазин, у него с собой только телефон, а базе стало плохо. Как бот должен проводить аутентификацию и авторизацию админа? О каких проблемах его надо уведомлять? Каким образом? Какие варианты действий надо предлагать?
Это подводит ко второй части вопроса — что значит smart? А у нас ответа и нет, причём это принципиальная позиция. Это как раз задача конкурсантов продумать, чем их бот может быть полезен, кроме как выдавать алерт что база упала. Но чтоб совсем уж их в море не бросать, был составлен список неких минимальных требований, что должно происходить. Опрос базы каждые 15 секунд, определение корректности работы базы, вычленение самых долгих транзакций, отслеживание активных сессий, умение перезапускать базу после команды checkpoint, отслеживание загруженности хостовой машины, ссылочки на документацию и прочие полезные мелкие штуки.
Что было на чекпоинтах
По правилам соревнования, на каждом промежуточном чекпоинте у команд было по пять минут, чтобы показать свои наработки и минимальный список того, что должно работать. Например, к первому чекпоинту должна быть работающая база и бот способный к ней подключаться.
Лично у меня никаких особых ожиданий не было, благо опыта судейства ноль, но уже с первых выступлений становится очевидно, кто куда копает и способен прийти к успеху. Некоторые ребята пишут всё в одном файле, другие городят структуру из сотни микросервисов. Третьи начинают писать мобильное приложение ещё до того, как написали ядро бота, просто потому что в команде есть мобильщик, и пусть он тоже пользу принесет. Но ребята явно стремятся к какой-то своей цели, поэтому молодцы однозначно. (Хотя местами очень хотелось развернуть их в сторону правильной цели, вместо ложной, но тут у нас соревнования, а не бюро добрых услуг).
Словом, обнажается общая проблема 99% команд — за технологиями не видно сути решаемой проблемы. Некоторые так и спрашивали на чекпоинтах: мы вот реализовали всё что в примерах написано, а что ещё сделать? Так и хотелось сказать: «Так это к тебе вопрос. Это ты должен поставить себя на место админа и понять, что ему для счастливой жизни надо». Но тут главное не навредить своими советами. В какой-то момент была озвучена подсказка с нашей стороны, что необязательно добавлять базу через UI телеги. Может стоит подумать в сторону добавления через списки или забирать из заранее известной базы, или ещё что-то. В итоге мы наблюдали фестиваль проектов, где база добавлялась через JSON-файл, где в три строчки написаны параметры подключения. Включая пароли в открытом виде. Вот и советуй им после такого.
Поэтому на всех промежуточных чекпоинтах мы налегали на то, что участникам надо подумать, чем их решение будет лучше конкурентов. Какая у них будет изюминка и killer-фича. Это не обязательно должны быть сверхнавороты, это может быть простая, но очень полезная штука. Спойлер — как минимум одна команда именно так и сделала.
На чём сыпались на итоговой презентации
Здесь мы не берём самоотводы, когда команда резко теряла интерес к происходящему, а рассмотрим объективные фиаско. Самая частая причина: нагородили огород всего, забыв про основной функционал. Тут прям хочется дать золотую тройку советов, на случай если это будут читать участники следующих соревнований:
Делайте MVP сразу. Буквально в первые часы. Минимальное выполнение требований ТЗ практически гарантированно ведет к прохождению чекпоинта. Не надо никаких допфичей, упаковки в контейнеры, прорисовку красивого интерфейса и так далее. Это всё не важно, пока основное не работает.
Концентрация и дисциплина. Вы знаете, что у вас пять минут на всё про всё. Договоритесь заранее, кто что говорит. Кто может подстраховать на случай проблем со связью у основного говоруна. Где что лежит, как называется и так далее. Из отведённых пяти минут некоторые команды только подключались минуты по три, теряя драгоценное время.
План, план и ещё раз план. На каждом чеке точно спросят, что вы уже сделали и что планируете. Если по обоим пунктам вы можете только неуверенно мычать под нос что-то о прекрасном мире будущего, это никому не интересно. Банально, но напишите себе заранее пару фраз и проговорите их на чеке. Вы уже будете выглядеть намного лучше, сами же успокоитесь и получите больше очков в карму.
Что запомнилось
Здесь безотносительно хорошо/плохо, а просто отложившиеся в памяти случаи, которые кому-то могут оказаться полезными для будущих соревнований.
Та самая простая, но очень крутая фича. Ребята добавили в бот опцию звонка. Админу пришло уведомление о критической проблеме, он не прочитал его, бот начинает звонить, чтобы он всё же вытащил телефон из штанов и увидел ахтунг. Элементарно? Абсолютно. Полезно? Однозначно!
Нет никакой аутентификации или авторизации. Даже если не обращать внимания на работы с захардкоженными кредами к базам, буквально три команды подумали над реализацией механизма проверки, что к базе подключается валидный пользователь. И только одна команда реализовала эту проверку с внесением пользователя в список доверенных третьим лицом.
Мы тут мобильное приложение собрали под андроид. Ну это вы молодцы конечно, а что делать яблоководам? А почему ваш бот по сути, кнопка открывающая сайт?
Одна команда всё же прикрутила мониторинг через Zabbix с мотивацией: «Zabbix умеет всё!». На вопрос что делать тем, у кого мониторинг инфраструктуры построен на другом решении, стушевались и не нашли что ответить.
Была очень классная работа, где бот управлялся консольными командами, за счёт чего имел около неограниченный функционал. Правда, что делать если на улице -25 градусов и как не отморозить палец в данном случае, ответа не нашлось. Да, продукт должен быть не только технологичным, но и удобным в использовании.
PHP жив!
Несколько команд прикрутили к боту AI, ML инструменты и прочие модности. Но никто не смог внятно объяснить в чем вероятная польза, кроме как предсказание аномалий на основе усреднённой статистики (для чего никакой ML и AI никому и не нужен, собственно).
Явный перекос в сторону Python. Всё же это минус, если мы говорим о продукте, который планируем расширять с сохранением производительности.
ChatGPT прикрученный как советчик. Вроде и хорошая идея, но кто проверит валидность его ответов? И что будет с ботом, если завтра OpenAI просто закроют свой API?
За ботами со встроенными веб-приложениями будущее. Запомните этот твит.
Студенты читерят и думают, что никто не догадается =)
Непрошенные советы организаторам
Странная система отбора. Суть в том, что учёт баллов ведётся в рамках регионов. То есть команды соревнуются не в общем зачёте, а в рамках своего региона. С одной стороны, это объясняется защитой от досрочного захвата всех мест традиционно сильными командами, что вроде даже и хорошо. С другой стороны, это порождает коллизии, когда в одном регионе сразу несколько очень сильных команд и между ними происходит серьёзное рубилово. А в соседнем заявилась только одна, и она автоматически проходит.
Явный провал с привлечением участников. На участие заявилась 41 команда. На мой взгляд, весьма достойный результат, если смотреть в целом. Но, например, из Москвы заявилась только одна команда. Это как вообще? То есть, очень хорошо, что не столицей единой, но это выглядит как явный провал в рекламе мероприятия.
Итого
Нам действительно понравилось. И что подобные соревнования есть, и что проводятся они на достойном уровне, и что признаны на государственном уровне.
Есть действительно сильные ребята с интересными идеями. Если говорить в терминах найма, это не тот уровень, когда ты готов прям сразу взять их на работу, но пообщаться в рамках стажировки однозначно можно.
Поэтому призываем всех участвовать в подобных вещах, поднимая общий уровень специалистов.
