Мене звуть Дмитро. І я хочу розповісти про те, як наша команда вийшла у фінал хакатону Urban Tech Challenge з треку Big Data. Відразу скажу, що це не перший хакатон, у якому я брав участь, і не перший, де займаю призові місця. У зв'язку з цим, у своєму оповіданні я хочу озвучити деякі загальні спостереження та висновки, що стосуються індустрії хакатонів загалом, і дати свою точку зору на противагу негативним відгукам, які з'явилися в мережі одразу після закінчення Urban Tech Challenge (наприклад ).
Отже, спочатку деякі загальні спостереження.
1. Дивує, що чимало людей наївно думають, що хакатон — це щось подібне до спортивного змагання, де перемагають найкращі кодери. Це не так. Я не розглядаю випадки, коли організатори хакатону самі не знають чого вони хочуть (бачив і таке). Але, як правило, компанія, яка влаштовує хакатон, має свої цілі. Їх список може бути різним: це може бути технічне вирішення якихось проблем, пошук нових ідей та людей тощо. Ці цілі часто визначають формат заходу, його терміни, онлайн/оффлайн, те, як будуть сформульовані завдання (і вони взагалі сформульовані), чи буде на хакатоні code review і т.д. І команди, і те, що вони зробили оцінюються саме з цього погляду. І перемагають ті команди, які найкраще потрапляють у точку, потрібну компанії, причому багато хто потрапляє в цю точку абсолютно неусвідомлено та випадково, думаючи, що вони дійсно беруть участь у спортивному змаганні. Мої спостереження показують, що для мотивації учасників організаторам слід створювати хоча б видимість спортивної обстановки та рівних умов, інакше вони отримують хвилю негативу, як у зазначеному вище відгукі. Але ми відхилилися.
2. Звідси такий висновок. Організатори зацікавлені в тому, щоб учасники приходили на хакатон зі своїми напрацюваннями, іноді навіть спеціально влаштовується заочний онлайн етап. Це дозволяє отримати сильніші рішення на виході. Поняття «свої напрацювання» — дуже відносне, будь-який досвідчений проґер може в перший же коміт нагромадити тисячі рядків коду зі своїх старих проектів. І чи буде це заздалегідь підготовленим доробком? Але в будь-якому випадку діє правило, яке я висловив у вигляді відомого мема:
Для перемоги у вас має щось бути, якась конкурентна перевага: схожий проект, який Ви робили в минулому, знання та досвід у якійсь специфічній темі або вже готовий доробок, зроблений до початку хакатону. Так, це не спортивно. Так, це може не окупити витрачених зусиль (тут уже кожен сам вирішує, чи варто кодувати 3 тижні ночами за приз у 100 тисяч, поділений на всю команду, та ще й із ризиком його не отримати). Але найчастіше це єдиний шанс вирватися вперед.
3. Підбір команди. Як я помітив по чатах хакатонів, багато хто підходить до цього питання досить легковажно (хоча, це найважливіше рішення, яке визначить Ваш результат на хакатоні). За багатьма сферами діяльності (і зі спорту, і за хакатонами) бачив, що сильні люди схильні поєднуватися з сильними, слабкі зі слабкими, розумні з розумними, ну, загалом, Ви зрозуміли… Приблизно це і відбувається в чатах: сильні програмісти одразу розхоплюються, люди, що не володіють будь-якими цінними для хакатона навичками, висять у чаті подовгу і вибирають команду за принципом аби хтось узяв. На деяких хакатонах практикується випадковий розподіл за командами, причому організатори стверджують, що рандомні команди показують результат не гірше, ніж ті, що вже склалися. Але за моїми спостереженнями, мотивовані люди, як правило, знаходять команду самі, якщо вже когось і доводиться розподіляти, то найчастіше багато хто з них і не приходить на хакатон.
Щодо складу команди — це дуже індивідуально і сильно залежить від завдання. Я міг би сказати, що мінімальний життєздатний склад команди – це дизайнер – фронтендер чи фронтендер – бекендер. Але мені відомі також випадки, коли перемагали команди, що складаються тільки з фронтедерів, які прилаштовували простий бек на node.js, або робили мобільний додаток на React Native; або лише з бекендерів, які робили просту верстку. Загалом все дуже індивідуально і залежить від завдання. Мій план щодо підбору команди на хакатон був наступним: я планував зібрати команду або приєднатися до команди типу фронтендер-бекендер-дизайнер (я сам фронт). І досить швидко почав спілкуватися в чаті з бекендером на python та дизайнером, який прийняв запрошення до нас приєднається. Трохи згодом до нас приєдналася дівчина бізнес-аналітик, яка вже мала досвід перемоги на хакатоні, і це вирішило питання її приєднання до нас. Після короткої наради ми вирішили назватись U4 (URBAN 4, урбаністична четвірка) за аналогією з фантастичною четвіркою. І навіть поставили на аву нашого телеграм-каналу відповідну картинку.
4. Вибір завдання. Як я вже казав, у Вас має бути конкурентна перевага, завдання на хакатон вибирається, виходячи з цього. Виходячи з цього, подивившись та оцінивши їхню складність, ми зупинилися на двох завданнях: каталог інноваційних підприємств від ДПіІР та чат-бот від ЕФКО. Завдання від ДПІіР обрав бекендер, завдання від ЕФКО вибрав я, т.к. мав досвід написання чат-ботів на node.js та DialogFlow. Завдання ЕФКО також передбачало ML, я маю деякий, не дуже великий, досвід у ML. І за умовами завдання мені здалося, що вона навряд чи вирішується засобами ML. Це відчуття зміцнилося, коли я сходив на мітап Urban Tech Challenge, де організатори показали мені датасет по ЕФКО, де було близько 100 фотографій розкладок продуктів (зроблених із різних ракурсів) та близько 20 класів помилок розкладки. І при цьому замовники завдання хотіли отримати успішність класифікації в 90%. У результаті я підготував презентацію рішення без ML, бекендер підготував презентацію за каталогом, і спільними зусиллями, доопрацювавши презентації, ми відправили їх на Urban Tech Challenge. Вже цьому етапі виявився рівень мотивації і внеску кожного учасника. Наш дизайнер не брав участі в обговореннях, відповідав із запізненням і навіть інформацію про себе у презентації заповнив у останній момент, загалом з'явилися сумніви.
У результаті, ми пройшли за завданням від ДПіІР, і анітрохи не засмутилися, що не пройшли по ЕФКО, оскільки завдання видалося нам, м'яко кажучи, дивним.
5. Підготовка до хакатон. Коли стало відомо, що ми пройшли на хакатон, почали готувати заготівлю. І тут я не закликаю розпочати писати код за тиждень до початку хакатону. Як мінімум, у Вас повинен бути готовий boilerplate, з яким Ви можете відразу ж розпочати роботу, не займаючись налаштуванням інструментів, і не натикаючись на баги якоїсь ліби, яку Ви вирішили вперше спробувати на хакатоні. Мені відома історія про ангулярників, які прийшли на хакатон і всі 2 дні займалися налаштуванням складання проекту, тому все має бути підготовлене заздалегідь. Ми припускали розподілити обов'язки в такий спосіб: бекендер пише краулери, які обшаривают інтернет і кладуть всю зібрану інформацію в БД, я ж пишу API на node.js, який запитує цю БД і віддає дані на фронт. У зв'язку з цим я заздалегідь зробив заготівлю сервера на express.js, зробив заготівлю фронтенда на react. Я не використовую CRA, завжди налаштовую вебпак під себе і чудово знаю, які це може таїти в собі ризики (пам'ятаємо історію про ангулярників). У цей момент я запросив заготівлі інтерфейсу або хоча б мокапи від нашого дизайнера, щоб мати уявлення про те, що я верстати. За ідеєю він теж повинен робити свої заготівлі і погоджувати їх з нами, але я так і не отримав відповіді. У результаті я запозичив дизайн з одного свого старого проекту. І так стало виходити швидше, оскільки всі стилі для цього проекту вже були написані. Звідси висновок: далеко не завжди в команді потрібний дизайнер))). З цими доробками ми й прийшли на хакатон.
6. Робота на хакатоні. Свою команду наживо я вперше побачив лише на відкритті хакатону в ЦДП. Ми познайомилися, обговорили рішення та етапи роботи над завданням. І хоча після відкриття ми мали їхати автобусами до Червоного жовтня, поїхали додому відсипатися, домовившись прийти на місце до 9.00. Чому? Організатори, мабуть, хотіли вичавити максимум із учасників, тому влаштували саме такий розклад. Але, на мій досвід, можна нормально кодити, не спавши одну ніч. А щодо другої — я вже не впевнений. Хакатон – це марафон, треба адекватно розраховувати та планувати свої сили. Тим більше, що ми мали заготовки.
Тому, оспівшись, о 9.00 ми сиділи на шостому поверсі Dewocracy. Тут наш дизайнер несподівано повідомив, що він не має ноутбука, і що він попрацює з дому, а спілкуватися ми будемо по телефону. Це стало останньою краплею. І так ми з четвірки перетворилися на трійку, хоч назву команди не змінили. Знову ж таки це не стало для нас сильним ударом, дизайн зі старого проекту у мене вже був. Загалом спочатку все йшло досить гладко і за планом. Ми завантажили базу даних (ми вирішили використовувати neo4j) датасет інноваційних компаній від організаторів. Я почав верстати, потім взявся за node.js, і тут пішли осічки. Я ніколи раніше не працював з neo4j, і спочатку я шукав для цієї БД робочий драйвер, потім знався, як пишеться запит, а потім з подивом виявив, що ця БД при запиті повертає сутності у вигляді масиву об'єктів нод та їх ребер. Тобто. коли я запитував по ІПН організацію і всі дані щодо неї, замість одного об'єкта організації мені повертався довгий масив об'єктів, що містить дані щодо цієї організації та відносин між ними. Я написав маппер, який проходив весь масив, і склеював усі об'єкти організації в один об'єкт. Але на бою при запиті до бази на 8 тисяч організацій він виконувався вкрай повільно близько 20-30 секунд. Я задумався про оптимізацію... І тут ми вчасно зупинилися і пересіли на MongoDB, і це зайняло близько 30 хвилин. Загалом на neo4j було втрачено близько 5 годин.
Пам'ятайте, ніколи не беріть на хакатон технологію, з якою Ви не знайомі, можуть бути сюрпризи. Але, загалом, крім цієї невдачі, все йшло за планом. І вже вранці 9 грудня у нас був повністю робочий додаток. Весь день ми планували накручувати на нього додаткові фічі. Надалі, у мене все йшло відносно гладко, а ось у бекендера була ціла купа проблем з баном його краулерів у пошукових системах, у спамі агрегаторів юрособ, який приходив у перших місцях пошукової видачі при запиті на кожну конкретну фірму. Але про це краще розповість він сам. Перша додаткова фіча, яку я прикрутив, - пошук за П.І.Б. генерального директора ВКонтакте. Це зайняло кілька годин.
Так, на сторінці фірми в нашому додатку з'явилася ава ген. директора, посилання на його сторінку ВКонтакте та деякі інші дані. Це була гарна вишенька на торті, хоч можливо і не вона забезпечила нам перемогу. Потім я хотів накрутити якусь аналітику. Але після тривалого перебору варіантів (виникало багато нюансів з UI) зупинився на найпростішій агрегації організацій за кодом економічної діяльності. Вже ввечері, останнім часом, я верстав заготівлю для відображення інноваційних продуктів (у нашому додатку передбачається розділ Продукти та послуги), хоча бекенд під це був не готовий. База при цьому пухла як на дріжджах, краулери продовжували роботу, бекендер експериментував з NLP, щоб відрізняти інноваційні тексти від інноваційних))). Але вже настав час здачі підсумкової презентації.
7. Презентація. За своїм досвідом можу сказати, що перемикатися на підготовку презентації слід десь за 3-4 години до її здачі. Особливо, якщо в ній передбачається відео, його зйомка та монтування забирає чимало часу. У нас передбачалося відео. І в нас була спеціальна людина, яка цим займалася, а також вирішувала цілу низку інших організаційних питань. У зв'язку з цим ми до останнього моменту не відволікалися від кодингу.
8. Пітч. Мені не сподобалося, що презентації та фінал було винесено в окремий будній день (понеділок). Тут, швидше за все, продовжилася політика організаторів щодо вичавлювання з учасників максимуму. Я не планував відпрошуватися з роботи, хотів прийти лише на фінал, хоча решта членів моєї команди взяла вихідні. Однак емоційна зануреність у хакатон була вже настільки висока, що о 8-й ранку я написав у чат своєї команди (робочої, а не команди хакатона), що беру день за свій рахунок, і поїхав до ЦДП на пітчі. У нашій задачі виявилося дуже багато чистих дата саєнтистів і це дуже позначилося на підході до вирішення завдання. У багатьох був хороший DS, але ні в кого не було робочого прототипу, багато хто не зміг обійти бани їхніх кроулерів у пошукових системах. Ми виявились єдиною командою з робочим прототипом. І ми знали, як вирішувати поставлене завдання. У підсумку ми перемогли в треку, хоча нам дуже пощастило, що ми вибрали найменш конкурентне завдання. Дивлячись на пітчі в інших треках, ми усвідомлювали, що в нас не було б жодних шансів. Також хочу сказати, що нам дуже пощастило з журі, вони ретельно перевіряли код. І, судячи з відгуків, так відбувалося далеко не у всіх треках.
9. Фінал. Після того, як нас кілька разів викликали до журі на code review, ми, подумавши, що остаточно вирішили всі питання, пішли пообідати у Бургер Кінг. Там організатори зателефонували нам знову, довелося спішно пакувати замовлення та повертатися назад.
Організатор показав, у яку кімнату треба пройти, і, зайшовши туди, ми опинилися на тренінгу з ораторської майстерності для команд, що перемогли. Хлопців, які мали виступати на сцені, добре зарядили, всі виходили як справжні шоумени.
І мушу визнати, що у фіналі, на тлі найсильніших команд з інших треків, ми виглядали блідо, перемога за номінацією держзамовника цілком заслужено пішла команді з треку real estate tech. Думаю, що ключовими факторами, що зробили свій внесок у нашу перемогу на треку, стали: наявність готової заготівлі, за рахунок якої і вдалося швидко зробити прототип, наявність у прототипі «родзинок» (пошук ген. директорів у соцмережах) та навички з NLP нашого бекендера , які теж дуже зацікавили журі
І насамкінець традиційні подяки всім тим, хто за нас вболівав, журі нашого треку, Євгену Євграф'єву (автору завдання, яке ми вирішували на хакатоні) і звичайно ж організаторам хакатону. Це був мабуть найбільший і найкрутіший хакатон, з усіх у яких я брав участь, залишається тільки побажати хлопцям тримати таку високу марку й надалі!
Джерело: habr.com