Недавно мы рассказывали об интенсивном курсе по СУБД в высоконагруженных проектах. Напомним, это был один из трех интенсивов, которые мы провели этим летом для студентов образовательных проектов и стажеров Mail.Ru. В этом посте делимся впечатлениями о том, как прошел хакатон - второй интенсив летней серии.



Базой для участия в хакатоне было знание С++, умение пользоваться git и понимание того, как работает интернет. Чтобы присоединиться к команде, нужно было выполнить тестовое задание. Нам прислали более сорока тестовых заданий, мы отобрали 34 лучшие работы, и в итоге интенсив завершили 19 ребят - все они получили отличный опыт. О том, что еще можно было почерпнуть из хакатона, читай в рассказах самих участников и преподавателя Максима Тремпольцева.

Максим Тремпольцев, преподаватель

Решение провести хакатон я принял сразу, как только получил предложение. Во-первых, любое образовательное мероприятие всегда означает личностный и профессиональный рост, а расти я люблю, так как это всегда коррелирует с финансовым положением. Во-вторых, было интересно удастся ли за небольшое количество времени с командой из незнакомых людей, имеющих разный опыт, написать что-то работающее. И в-третьих, это просто шанс классно провести время.

Начало
У меня был опыт написания мессенджера, ноутбук, сервер для деплоя, печенье на кухне, фрукты во фрешбаре, море газировки и три дюжины желающих писать код. Не то чтобы это много, но раз начал, то иди в своем увлечении до конца. Единственное, что меня беспокоило, - время. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек, пытающийся успеть в последние два дня сделать 80% работы. И я знал, что довольно скоро мы в это окунемся.

Итак, чтобы отобрать лучших, я предложил кандидатам написать простой асинхронный файловый сервер, используя Boost.Asio или асинхронный же загрузчик с libcurl (все это потом должно было пригодится). Проснувшись утром и обнаружив в своей почте более 40 выполненных тестовых заданий, я немедленно написал коллеге: “Закрывай регистрацию!!”. Было отобрано 35 человек. Я стал ждать начала.

Архитектура
Транспортом для мессенджера я выбрал https. Это упростило задачу, так как мы бы получили в первом эшелоне шифрование из коробки, Кроме того, для поддержки этого есть хорошие инструменты. Таким образом, клиент, используя libcurl, инициировал общение с сервером через https. На стороне сервера все запросы принимал nginx, который перенаправлял расшифрованный трафик уже нашему серверу. Также по задумке nginx должен был отдавать клиенту расшаренные файлы. Сам сервер представлял собой однопоточный асинхронный сервер на Boost.Asio. Асинхронность обеспечила бы нам достаточный уровень быстродействия, а однопоточность избавила бы от багов и проседания производительности из-за неправильных блокировок. Текст на клиенте шифровался RSA, между двумя участниками чата происходил обмен открытыми ключами, таким образом они могли шифровать передаваемый текст от чужих глаз, в том числе и от сервера. Серверов в нашей архитектуре могло быть несколько, клиент мог выбрать свой сервер и обслуживаться там. Для поиска сервера, на котором обслуживается конкретный клиент, мы планировали использовать распределенную хеш-таблицу (DHT). На клиенте архитектурно было разделение на ядро и графический интерфейс, которые взаимодействовали между собой через диспетчер.

Запланированный функционал
1. Роутинг (поиск сервера на котором обслуживается клиент по id клиента)
2. Список контактов.
3. Шаринг файлов.
4. Синхронизируемая история на сервере.
5. Парадоксально, но, собственно, чат.

Поехали
Первую встречу я посвятил обсуждению архитектуры, разделению на команды и утверждению функционала на первую итерацию. Я понимал, что физически не смогу за имеющееся у меня время контролировать over 30 человек, поэтому надеялся, что в этом мне помогут тимлиды. Как среди незнакомых людей выбрать тимлида? Я решил смотреть на поведение людей на первой встрече и раздать должности наиболее активным (надо сказать, что там, где я угадал, все было хорошо. Но в одной команде никто не хотел быть тимлидом, и там пришлось назначать руководителя, используя административный ресурс - это был провал, и позже это аукнулось). Тимлиды должны были распределить задачи внутри своей команды, проконтролировать их выполнение, отревьюить код и сделать в мой репозиторий пул-реквест. Команды были следующие: роутинг, сервер, ядро, гуй. В каждой - плюс-минус шесть человек. На себя я взял инфраструктуру и библиотеку для взаимодействия с сервером со стороны клиента.

На притирку и раскачку требуется время, так что началось все ожидаемо вяло. Код начали писать только к концу первой недели (а их у нас было всего две!). До этого все время заняло обсуждение, что и как делать. Часть народа “отвалилась”, но те 20 человек, что остались, - мое почтение. Столько мотивации и азарта, очень круто! Естественно, появилось общее понимание: всего, что мы запланировали, не успеть, поэтому надо резать фичи. И мы стали резать. Окончательный план фич:
1. Роутинг (сделаем, но не заинтегрируем);
2. Чат.
Шифрование осталось.
Да, гораздо скромней.

Выводы
Кадры решают все - если все на своих местах, то любая задача решаема. Не надо бояться отсеять лишних людей, они и так “отвалятся”. На роль тимлидов в подобных мероприятиях нужно приглашать опытных разработчиков, одного разработчика на 30 человек катастрофически мало. В целом мы отлично провели время, я получил организационный опыт, ребята тоже освоили что-то новое и получили опыт работы в команде. Судя по отзывам и неформальному общению после мероприятия, всем понравилось. Лично я с удовольствием повторю подобное. С учетом полученного опыта все будет еще круче!

Впечатления от мероприятия крайне положительные. В команде мне довелось поработать впервые, обычно я разрабатываю всю программу в одиночку. Из-за этого первое время было не совсем понятно, как работать с людьми. Я пытался сделать общую часть нахрапом и самостоятельно, но через несколько дней вошел в ритм и ощутил плюсы командной работы. Я участвовал в разработке ядра клиента. Вместе с Александром Мельниковым мы написали менеджер авторизации (часть ядра, которая отвечает за регистрацию и авторизацию на сервере) и часть диспетчера ядра, обеспечивающую взаимодействие с менеджером авторизации. В менеджере был использован был чистый C++14. Также мной была написана функция, определяющая домашнюю папку в зависимости от платформы, на которой запускается клиент. В ней использовался Boost::Filesystem. Вначале было не слишком тяжело, но когда началась неразбериха в команде и нас осталось четверо, стало гораздо сложнее. Пару ночей спать не пришлось. Во время хакатона я выяснил свои слабые места, которые необходимо подтянуть, отчасти освоил стандарты C++11 и C++14, начал работать с libcurl и OpenSSL и чуть глубже освоил Boost. Было любопытно поработать в команде и посмотреть, что такое хакатон. Ожидания более чем оправдались. Мой совет участникам будущих хакатонов таков: если человек видит, что команда начинает распадаться или пропал тимлид, следует сразу донести это до преподавателя.

В целом было весело. Мне кажется, моя команда была самой классной (хотя, наверное, так кажется всем). Мы занимались роутингом, но, к сожалению, не успели, доделать свою часть. Несмотря на окончание хакатона, мы планируем завершить начатое. Всю первую неделю мы потратили на то, чтобы просто обсудить и утвердить алгоритм. Самым клевым было знакомство с интересными людьми, которые что-то делают и хотят развиваться, а не просто тухнут на работе. Такие знакомства вдохновляют. Бессонных ночей у нас не было, но на неделе мы встречались 3-4 раза и уходили из офиса только к полуночи. Не думаю, что когда-то еще буду заниматься схожей задачей, но алгоритмы - это круто, они развивают мозги. Я пошла на хакатон, чтобы вспомнить чистые плюсы. В принципе, мы не так много кодили, больше занимались самим алгоритмом, но все равно было полезно. Я за любые подобные активности, времени бы только побольше выделяли на это.