Как И Почему Мы Выиграли Трек Big Data На Хакатоне Urban Tech Challenge

Меня зовут Дмитрий.

И я хочу рассказать о том, как наша команда вышла в финал хакатона Urban Tech Challenge по треку Big Data. Скажу сразу, это не первый хакатон, в котором я участвую, и не первый, на котором я занимаю призовые места.

В связи с этим в своем рассказе я хочу озвучить некоторые общие наблюдения и выводы относительно индустрии хакатонов в целом, а также изложить свою точку зрения в противовес негативным отзывам, появившимся в сети сразу после окончания Urban Tech Challenge (для пример этот ).

Итак, сначала несколько общих замечаний.

1. Удивительно, что немало людей наивно полагают, что хакатон — это своего рода спортивное соревнование, в котором побеждают лучшие программисты.

Это не верно.

Я не рассматриваю случаи, когда организаторы хакатонов сами не знают, чего хотят (я тоже такое видел).

Но, как правило, компания, организующая хакатон, преследует свои цели.

Их список может быть разным: это может быть техническое решение каких-то проблем, поиск новых идей и людей и т. д. Эти цели часто определяют формат мероприятия, его сроки, онлайн/оффлайн, то, как будут формулироваться задачи ( и будут ли они вообще сформулированы), будет ли code review на хакатоне и т. д. С этой точки зрения оцениваются и команды, и то, что они сделали.

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

Мои наблюдения показывают, что для мотивации участников организаторам следует создать хотя бы видимость спортивной среды и равных условий, иначе они получат волну негатива, как в приведенном выше обзоре.

Но мы отвлеклись.

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

Это позволяет использовать более сильные выходные решения.

Понятие «своя работа» весьма относительное; любой опытный разработчик может накопить в своем первом коммите тысячи строк кода из своих старых проектов.

И будет ли это заранее подготовленная разработка? Но в любом случае действует правило, которое я выразил в виде известного мема:

Как и почему мы выиграли трек Big Data на хакатоне Urban Tech Challenge

Для победы у вас должно быть что-то, какое-то конкурентное преимущество: аналогичный проект, который вы делали в прошлом, знания и опыт по конкретной теме или готовая работа, сделанная до начала хакатона.

Да, это не спортивно.

Да, возможно, это не стоит затраченных усилий (тут каждый решает сам, стоит ли кодить 3 недели по ночам ради приза в 100 тысяч, разделенного на всю команду, да еще с риском его не получить).

Но, зачастую, это единственный шанс вырваться вперед. 3. Выбор команды.

Как я заметил в чатах хакатона, многие подходят к этому вопросу довольно легкомысленно (хотя это самое важное решение, от которого будет зависеть ваш результат на хакатоне).

Во многих сферах деятельности (и в спорте, и на хакатонах) я видел, что сильные люди склонны объединяться с сильными, слабые со слабыми, умные с умными, ну в общем, вы поняли.

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

.

На некоторых хакатонах практикуется случайное распределение команд, и организаторы утверждают, что случайные команды работают не хуже уже существующих.

Но по моим наблюдениям, мотивированные люди, как правило, находят команду самостоятельно; если кого-то надо назначить, то зачастую многие на хакатон не приходят. Что касается состава команды, то он очень индивидуален и сильно зависит от поставленной задачи.

Я бы мог сказать, что минимально жизнеспособный состав команды — дизайнер — фронтенд или фронтенд — бэкенд. Но я также знаю случаи, когда побеждали команды, состоящие только из фронтендеров, которые добавили простой бэкенд на node.js или сделали мобильное приложение на React Native; или только от бэкендеров, которые делали простую верстку.

В целом все очень индивидуально и зависит от поставленной задачи.

Мой план подбора команды на хакатон был следующий: я планировал собрать команду или присоединиться к команде по типу фронтенд-бэкенд-дизайнер (я сам фронтендер).

И довольно быстро я начал общаться с бэкендером Python и дизайнером, который принял приглашение присоединиться к нам.

Чуть позже к нам присоединилась девушка, бизнес-аналитик, уже имевшая опыт победы на хакатоне, и это решило вопрос о ее присоединении к нам.

После недолгого общения мы решили назвать себя U4 (URBAN 4, городская четверка) по аналогии с фантастической четверкой.

И даже поставили соответствующую картинку на аватарку нашего телеграм-канала.

4. Выбор задачи.

Как я уже говорил, у вас должно быть конкурентное преимущество, исходя из этого подбирается задача на хакатон.

Исходя из этого, посмотрев список заданий и оценив их сложность, мы остановились на двух задачах: каталог инновационных предприятий от ДПиИР и чат-бот от ЭФКО.

Задачу от DPIiR выбрал бэкендер, задачу от ЭFKO выбрал я, т.к.

имел опыт написания чат-ботов на node.js и DialogFlow. Задача ЭFKO также включала ML, у меня есть некоторый, не очень большой опыт в ML. И по условиям задачи мне казалось, что ее вряд ли удастся решить средствами ML. Это чувство укрепилось, когда я пошел на митап Urban Tech Challenge, где организаторы показали мне датасет на ЭFKO, где было около 100 фотографий макетов продуктов (снятых с разных ракурсов) и около 20 классов ошибок макетов.

И в то же время заказчики хотели добиться успеха классификации в 90%.

В итоге я подготовил презентацию решения без ML, бэкендер подготовил презентацию на основе каталога, и вместе, после доработки презентаций, мы отправили их на Urban Tech Challenge. Уже на этом этапе выявился уровень мотивации и вклада каждого участника.

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

В итоге мы сдали задание от ДПиИР, и нисколько не расстроились, что не сдали ЭФКО, так как задание показалось нам, мягко говоря, странным.

5. Подготовка к хакатону.

Когда наконец стало известно, что мы прошли квалификацию на хакатон, мы начали готовиться.

И здесь я не призываю начинать писать код за неделю до начала хакатона.

Как минимум, у вас должен быть готовый шаблон, с которым вы сможете сразу приступить к работе, без необходимости настройки инструментов и не натыкаясь на баги какой-то библиотеки, которую вы решили впервые попробовать на хакатоне.

Я знаю историю об инженерах Angular, которые приехали на хакатон и потратили 2 дня на настройку сборки проекта, поэтому все должно быть подготовлено заранее.

Мы намеревались распределить обязанности следующим образом: бэкендер пишет сканеры, которые прочесывают интернет и помещают всю собранную информацию в базу данных, а я пишу API на node.js, который запрашивает эту базу данных и отправляет данные на фронт. В связи с этим я заранее подготовил сервер с помощью express.js и подготовил фронтенд в реакции.

Я не использую CRA, всегда настраиваю вебпак под себя и прекрасно знаю, какие риски это может нести (вспомните историю про угловых разработчиков).

На этом этапе я запросил у нашего дизайнера шаблоны интерфейса или хотя бы макеты, чтобы иметь представление о том, что буду выкладывать.

По идее, он тоже должен был сделать свои приготовления и согласовать их с нами, но ответа я так и не получил.

В результате я позаимствовал дизайн из одного из своих старых проектов.

И всё стало получаться ещё быстрее, так как все стили для этого проекта уже были написаны.

Отсюда вывод: дизайнер не всегда нужен в команде))).

Мы пришли на хакатон с этими разработками.

6. Работа на хакатоне.

Впервые я увидел свою команду вживую только на открытии хакатона в ЦРП.

Мы встретились, обсудили решение и этапы работы над проблемой.

И хотя после открытия нам пришлось ехать на автобусе до «Красного Октября», мы пошли домой спать, договорившись приехать на место к 9.00. Почему? Организаторы, видимо, хотели получить от участников максимум, поэтому устроили именно такой график.

Но, по моему опыту, вы можете нормально программировать, не спив ни одной ночи.

Насчет второго я уже не уверен.

Хакатон — это марафон; необходимо адекватно рассчитывать и планировать свои силы.

Более того, у нас была подготовка.



Как и почему мы выиграли трек Big Data на хакатоне Urban Tech Challenge

Поэтому, отоспавшись, в 9.00 мы сидели на шестом этаже Девократии.

Потом наш дизайнер неожиданно заявил, что у него нет ноутбука и что он будет работать из дома, а общаться мы будем по телефону.

Это было последней каплей.

И вот мы превратились из четверки в тройку, хотя название команды не меняли.

Опять же, для нас это не было большим ударом; У меня уже был дизайн из старого проекта.

В общем, поначалу все шло вполне гладко и по плану.

Мы загрузили в базу данных (решили использовать neo4j) датасет инновационных компаний от организаторов.

Я начал верстать, потом взялся за node.js, а потом что-то пошло не так.

Я никогда раньше не работал с neo4j и сначала искал рабочий драйвер для этой базы данных, потом разобрался как написать запрос, а потом с удивлением обнаружил, что эта база данных при запросе возвращает сущности в форма массива узловых объектов и их ребер.

Те.

когда я запросил организацию и все данные о ней по ИНН, то вместо одного объекта организации мне был возвращен длинный массив объектов, содержащих данные об этой организации и связях между ними.

Я написал маппер, который перебирал весь массив и склеивал все объекты по их организации в один объект. Но в бою при запросе базы данных 8 тысяч организаций он выполнялся крайне медленно, примерно 20 – 30 секунд. Я начал думать об оптимизации.

А потом мы вовремя остановились и перешли на MongoDB, и это заняло у нас около 30 минут. В общей сложности на neo4j было потеряно около 5 часов.

Помните, никогда не привозите на хакатон технологии, с которыми вы не знакомы, могут быть сюрпризы.

Но в целом, если не считать этой неудачи, все пошло по плану.

И уже утром 9 декабря у нас было полностью рабочее приложение.

На оставшуюся часть дня мы планировали добавить в него дополнительные возможности.

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

Но лучше ему рассказать об этом самому.

Первой дополнительной функцией, которую я добавил, был поиск по полному имени.

Генеральный директор ВКонтакте.

Это заняло несколько часов.

Так, на странице компании в нашем приложении появилась аватарка генерального директора, ссылка на его страницу ВКонтакте и некоторые другие данные.

Это была приятная вишенка на торте, хотя, возможно, она и не принесла нам победы.

Затем я хотел провести некоторую аналитику.

Но после долгих поисков вариантов (с интерфейсом было много нюансов) остановился на самой простой агрегации организаций по коду вида экономической деятельности.

Уже вечером, в последние часы, я выкладывал шаблон для отображения инновационных продуктов (в нашем приложении должен быть раздел «Товары и услуги»), хотя бэкенд к этому был не готов.

При этом база данных разрасталась как на дрожжах, краулеры продолжали работать, бэкендер экспериментировал с НЛП, чтобы отличать инновационные тексты от неинновационных))).

Но время финальной презентации уже приближалось.

7. Презентация.

По своему опыту могу сказать, что переходить к подготовке презентации следует примерно за 3-4 часа до назначенного срока.

Особенно, если речь идет о видео, его съемка и монтаж занимают довольно много времени.

У нас должно было быть видео.

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

В связи с этим мы не отвлекались от кодирования до самого последнего момента.

8. Подача.

Не понравилось, что презентации и финалы проводились в отдельный будний день (понедельник).

Здесь, скорее всего, продолжилась политика организаторов по выжиманию из участников максимума.

Я не планировал отпрашиваться с работы, хотел приехать только на финал, хотя остальная часть моей команды взяла выходной.

Однако эмоциональное погружение в хакатон было уже настолько велико, что в 8 утра я написал в чате своей команды (рабочего коллектива, а не команды хакатона), что беру день за свой счет, и пошёл в центральный офис для смол.

В нашей проблеме оказалось много чистых специалистов по данным, и это сильно повлияло на подход к решению проблемы.

У многих был хороший ДС, но ни у кого не было рабочего прототипа, многие не могли обойти запреты своих краулеров в поисковых системах.

Мы были единственной командой, у которой был работающий прототип.

И мы знали, как решить проблему.

В итоге мы выиграли трассу, хотя нам очень повезло, что мы выбрали наименее конкурентное задание.

Посмотрев поля на других трассах, мы поняли, что там у нас шансов нет. Еще хочу сказать, что нам очень повезло с жюри; они тщательно проверяли код. И, судя по отзывам, это произошло не во всех треках.

9. Финал.

После того, как нас несколько раз вызывали в жюри на код-ревью, мы, думая, что наконец-то решили все вопросы, пошли обедать в Burger King. Там нас снова позвали организаторы, нам пришлось быстро собирать заказы и отправляться обратно.

Организатор показал нам, в какой зал нам нужно пройти, и войдя, мы оказались на тренинге по публичным выступлениям для команд-победителей.

Ребята, которые должны были выступать на сцене, были хорошо заряжены, все вышли настоящими шоуменами.

И надо признать, в финале на фоне сильнейших команд других трасс мы выглядели бледно; Победа в номинации «Госзаказчик» вполне заслуженно досталась команде технологического трека недвижимости.

Думаю, что ключевыми факторами, которые способствовали нашей победе на трассе, были: наличие готовой заготовки, благодаря которой мы смогли быстро изготовить прототип, наличие «изюминок» в прототипе (поиск генеральных директоров в социальных сетях) и навыки НЛП нашего бэкендера, что также очень заинтересовало жюри.



Как и почему мы выиграли трек Big Data на хакатоне Urban Tech Challenge

И в заключение традиционное спасибо всем, кто нас поддержал, жюри нашего трека, Евгению Евграфьеву (автору задачи, которую мы решили на хакатоне) и конечно же организаторам хакатона.

Это был, пожалуй, самый масштабный и крутой хакатон, в котором я когда-либо участвовал, могу только пожелать ребятам и впредь держать такую высокую планку! Теги: #хакатон #Хакатоны #urban tech Challenge

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.