Как и защо спечелихме пистата Big Data на хакатона Urban Tech Challenge

Казвам се Дмитрий. И искам да говоря за това как нашият екип стигна до финала на хакатона Urban Tech Challenge на пистата Big Data. Веднага ще кажа, че това не е първият хакатон, в който участвах, и не първият, в който взех награди. В тази връзка, в моята история искам да изразя някои общи наблюдения и заключения по отношение на хакатон индустрията като цяло и да дам моята гледна точка в противовес на негативните отзиви, които се появиха онлайн веднага след края на Urban Tech Challenge (за пример това).

И така, първо някои общи наблюдения.

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

2. Оттук следва следният извод. Организаторите се интересуват от участниците, които идват на хакатона със собствена работа, понякога дори специално организират етап за онлайн кореспонденция за тази цел. Това позволява по-силни изходни решения. Понятието „собствена работа“ е много относително; всеки опитен разработчик може да натрупа хиляди редове код от старите си проекти в първия си комит. И това предварително подготвена разработка ли ще е? Но във всеки случай важи правилото, което изразих под формата на известен мем:

За да спечелите, трябва да имате нещо, някакво конкурентно предимство: подобен проект, който сте правили в миналото, знания и опит по конкретна тема или готова работа, направена преди началото на хакатона. Да, не е спортно. Да, това може да не си струва изразходваните усилия (тук всеки решава за себе си дали си струва да кодира 3 седмици през нощта за награда от 100 хиляди, разделена на целия екип и дори с риск да не я получи). Но често това е единственият шанс да напреднете.

3. Избор на екип. Както забелязах в чатовете на хакатона, мнозина подхождат към този въпрос доста несериозно (въпреки че това е най-важното решение, което ще определи резултата ви в хакатона). В много области на дейност (както в спорта, така и в хакатоните) съм виждал, че силните хора са склонни да се обединяват със силните, слабите със слабите, умните с умните, е, общо взето, схванахте идеята... Приблизително това се случва в чатовете: по-малко силни програмисти веднага биват грабнати, хора, които нямат ценни за хакатон умения, висят дълго време в чата и си избират екип на принципа, ако може някой да го вземе . На някои хакатони се практикува произволно разпределяне на отбори и организаторите твърдят, че произволните отбори се представят не по-зле от съществуващите. Но според моите наблюдения мотивираните хора по правило намират екип сами; ако някой трябва да бъде назначен, тогава много от тях често не идват на хакатона.

Що се отнася до състава на екипа, той е много индивидуален и силно зависи от задачата. Бих могъл да кажа, че минималният жизнеспособен състав на екипа е дизайнер - front-end или front-end - back-end. Но също така знам за случаи, когато екипи, състоящи се само от front-enders, печелят, които добавят прост back-end в node.js или правят мобилно приложение в React Native; или само от backenders, които са направили просто оформление. Като цяло всичко е много индивидуално и зависи от задачата. Моят план за избор на екип за хакатона беше следният: планирах да събера екип или да се присъединя към екип като front-end - back-end - дизайнер (аз самият съм front-end). И доста бързо започнах да разговарям с python backender и дизайнер, които приеха поканата да се присъединят към нас. Малко по-късно към нас се присъедини момиче, бизнес анализатор, което вече има опит в спечелването на хакатон и това реши въпроса тя да се присъедини към нас. След кратка среща решихме да се наречем U4 (URBAN 4, градска четворка) по аналогия с фантастичната четворка. И дори поставиха съответната снимка на аватара на нашия телеграм канал.

4. Избор на задача. Както вече казах, трябва да имате конкурентно предимство, въз основа на това се избира задачата за хакатона. Въз основа на това, като погледна списък със задачи и оценявайки тяхната сложност, се спряхме на две задачи: каталог на иновативни предприятия от ДПиИР и чатбот от ЕФКО. Задачата от ДПИиР е избрана от бекендера, задачата от ЕФКО е избрана от мен, т.к имаше опит в писането на chatbots в node.js и DialogFlow. Задачата на EFKO също включваше ML; имам известен, не много богат опит в ML. И според условията на проблема ми се стори, че е малко вероятно да се реши с помощта на ML инструменти. Това усещане се засили, когато отидох на срещата Urban Tech Challenge, където организаторите ми показаха набор от данни на EFKO, където имаше около 100 снимки на продуктови оформления (заснети от различни ъгли) и около 20 класа грешки в оформлението. И в същото време тези, които поръчаха задачата, искаха да постигнат успеваемост на класификацията от 90%. В резултат подготвих презентация на решението без ML, backender-ът подготви презентация на базата на каталога и заедно, след като финализирахме презентациите, ги изпратихме на Urban Tech Challenge. Още на този етап беше разкрито нивото на мотивация и принос на всеки участник. Нашият дизайнер не участва в дискусиите, отговори късно и дори попълни информация за себе си в презентацията в последния момент, като цяло възникнаха съмнения.

В резултат на това преминахме задачата от DPiIR и изобщо не се разстроихме, че не преминахме EFKO, тъй като задачата ни изглеждаше странна, меко казано.

5. Подготовка за хакатона. Когато най-накрая стана известно, че сме се класирали за хакатона, започнахме да подготвяме подготовката. И тук не препоръчвам да започнете да пишете код седмица преди началото на хакатона. Най-малко трябва да имате готов шаблон, с който можете веднага да започнете работа, без да се налага да конфигурирате инструменти и без да се сблъсквате с грешки на някоя библиотека, която сте решили да опитате за първи път на хакатон. Знам една история за ъглови инженери, които дойдоха на хакатон и прекараха 2 дни в настройка на изграждането на проекта, така че всичко трябва да бъде подготвено предварително. Възнамерявахме да разпределим отговорностите по следния начин: backender пише роботи, които претърсват Интернет и поставят цялата събрана информация в базата данни, докато аз пиша API в node.js, който прави запитвания към тази база данни и изпраща данните напред. В тази връзка подготвих сървър предварително, използвайки express.js и подготвих front-end в react. Не използвам CRA, винаги персонализирам webpack за себе си и знам много добре какви рискове може да представлява това (помнете историята за ъгловите разработчици). В този момент поисках шаблони за интерфейс или поне макети от нашия дизайнер, за да имам представа какво ще очертая. На теория той също би трябвало сам да си направи подготовката и да я съгласува с нас, но така и не получих отговор. В резултат на това заимствах дизайна от един от старите ми проекти. И започна да се получава още по-бързо, тъй като всички стилове за този проект вече бяха написани. Оттук и заключението: не винаги е необходим дизайнер в екип))). Стигнахме до хакатона с тези разработки.

6. Работа в хакатона. За първи път видях екипа си на живо едва на откриването на хакатона в ЦРБ. Срещнахме се, обсъдихме решението и етапите на работа по проблема. И въпреки че след откриването трябваше да отидем с автобус до Червения октомври, се прибрахме да спим, като се съгласихме да пристигнем на мястото до 9.00. Защо? Организаторите явно са искали да извлекат максимума от участниците, затова са направили точно такъв график. Но според моя опит можете да кодирате нормално, без да спите една нощ. За второто вече не съм сигурен. Хакатонът е маратон, трябва адекватно да изчислите и планирате силата си. Освен това имахме подготовка.

Затова, след като се наспахме, в 9.00 седяхме на шестия етаж на Dewocracy. Тогава нашият дизайнер неочаквано обяви, че няма лаптоп и ще работи от вкъщи, а ние ще комуникираме по телефона. Това беше последната капка. И така от четворка станахме тройка, въпреки че не сменихме името на отбора. Отново това не беше голям удар за нас, вече имах дизайна от стария проект. Като цяло в началото всичко вървеше съвсем гладко и по план. Заредихме в базата данни (решихме да използваме neo4j) набор от данни на иновативни компании от организаторите. Започнах да набирам текст, след това се захванах с node.js и тогава нещата започнаха да се провалят. Никога преди не бях работил с neo4j и отначало търсих работещ драйвер за тази база данни, след това разбрах как да напиша заявка и след това бях изненадан да открия, че тази база данни, когато бъде заявена, връща обекти в под формата на масив от възлови обекти и техните ръбове. Тези. когато поисках организация и всички данни за нея по TIN, вместо един обект на организация, ми беше върнат дълъг масив от обекти, съдържащи данни за тази организация и връзките между тях. Написах картограф, който премина през целия масив и залепи всички обекти според тяхната организация в един обект. Но в битка, когато се иска база данни от 8 хиляди организации, тя се изпълнява изключително бавно, около 20 - 30 секунди. Започнах да мисля за оптимизация... И тогава спряхме навреме и преминахме към MongoDB и ни отне около 30 минути. Общо около 4 часа бяха загубени на neo5j.

Запомнете, никога не вземайте технологии на хакатон, с които не сте запознати, може да има изненади. Но като цяло, освен този провал, всичко вървеше по план. И още сутринта на 9 декември имахме напълно работещо приложение. За останалата част от деня планирахме да добавим допълнителни функции към него. В бъдеще всичко мина сравнително гладко за мен, но бекендерът имаше цял куп проблеми със забраната на неговите роботи в търсачките, в спама на агрегаторите на юридически лица, които идваха на първите места в резултатите от търсенето при заявка за всяка конкретна фирма. Но е по-добре той сам да разкаже за това. Първата допълнителна функция, която добавих, беше търсене по пълно име. Генерален директор на VKontakte. Отне няколко часа.

И така, на страницата на компанията в нашето приложение се появи аватар на генералния директор, връзка към неговата страница VKontakte и някои други данни. Беше хубава черешка на тортата, въпреки че може би не ни донесе победата. Тогава исках да направя някои анализи. Но след дълго търсене на опции (имаше много нюанси с потребителския интерфейс), се спрях на най-простото агрегиране на организации по код на икономическа дейност. Още вечерта, в последните часове, излагах шаблон за показване на иновативни продукти (в нашето приложение трябваше да има раздел Продукти и услуги), въпреки че бекендът не беше готов за това. В същото време базата данни набъбваше главоломно, роботите продължаваха да работят, бекендерът експериментира с NLP, за да разграничи иновативните текстове от неиновативните))). Но времето за финалната презентация вече наближаваше.

7. Презентация. От собствен опит мога да кажа, че трябва да преминете към подготовка на презентация около 3 до 4 часа преди датата. Особено ако става въпрос за видео, заснемането и монтажът му отнема доста време. Трябваше да имаме видео. И имахме специален човек, който се занимаваше с това, а също така реши редица други организационни въпроси. В тази връзка не се отклонихме от кодирането до последния момент.

8. Стъпка. Не ми хареса, че презентациите и финалите бяха в отделен делничен ден (понеделник). Тук най-вероятно политиката на организаторите за изстискване на максимума от участниците продължи. Не планирах да си взема отпуск от работа, исках само да дойда на финала, въпреки че останалата част от екипа ми взе почивен ден. Емоционалното потапяне в хакатона обаче вече беше толкова голямо, че в 8 часа сутринта написах в чата на моя екип (работния екип, а не екипа на хакатона), че взимам деня за моя сметка и отидох в центъра офис за терени. Нашият проблем се оказа, че има много учени за чисти данни и това силно повлия на подхода към решаването на проблема. Мнозина имаха добър DS, но никой нямаше работещ прототип, много не можаха да заобиколят забраните на своите роботи в търсачките. Ние бяхме единственият екип с работещ прототип. И знаехме как да решим проблема. В крайна сметка спечелихме пистата, въпреки че имахме голям късмет, че избрахме най-малко конкурентната задача. Гледайки терените в други писти, разбрахме, че няма да имаме шанс там. Искам също да кажа, че имахме голям късмет с журито, те щателно провериха кода. И, съдейки по рецензиите, това не се случи във всички песни.

9. Окончателно. След като няколко пъти ни викаха в журито за преглед на кода, ние, мислейки, че най-накрая сме решили всички проблеми, отидохме да обядваме в Burger King. Там отново ни извикаха организаторите, трябваше набързо да опаковаме поръчките и да се прибираме.

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

И да си призная на финала, на фона на най-силните отбори от другите направления, изглеждахме бледи, победата в номинацията за правителствени клиенти напълно заслужено отиде при отбора от пистата Real Estate Tech. Мисля, че ключовите фактори, допринесли за нашата победа на пистата, бяха: наличието на готова заготовка, благодарение на която успяхме бързо да направим прототип, наличието на „акценти“ в прототипа (търсене на изпълнителни директори в социалните мрежи) и НЛП уменията на нашия backender, които също силно заинтересуваха журито.

И в заключение, традиционни благодарности на всички, които ни подкрепиха, журито на нашата писта, Евгений Евграфиев (авторът на задачата, която решихме на хакатона) и разбира се организаторите на хакатона. Това беше може би най-големият и готин хакатон, в който съм участвал, мога само да пожелая на момчетата да поддържат такъв висок стандарт и занапред!

Източник: www.habr.com