Како и зошто победивме на патеката Big Data на хакатонот Urban Tech Challenge

Јас се викам Дмитриј. И сакам да зборувам за тоа како нашиот тим стигна до финалето на хакатонот Urban Tech Challenge на патеката Big Data. Веднаш ќе кажам дека ова не е прв хакатон на кој учествував, ниту прв на кој земав награди. Во овој поглед, во мојата приказна сакам да изразам некои општи опсервации и заклучоци во врска со индустријата за хакатон како целина, и да дадам моја гледна точка наспроти негативните критики што се појавија на интернет веднаш по завршувањето на Urban Tech Challenge (за пример овој).

Значи, прво некои општи забелешки.

1. Изненадувачки е што многу луѓе наивно мислат дека хакатонот е некој вид спортски натпревар каде победуваат најдобрите кодери. Ова е погрешно. Не ги разгледувам случаите кога самите организатори на хакатонот не знаат што сакаат (и јас го видов тоа). Но, по правило, компанијата што организира хакатон си ги следи сопствените цели. Нивниот список може да биде различен: тоа може да биде техничко решение за некои проблеми, потрага по нови идеи и луѓе итн. Овие цели често го одредуваат форматот на настанот, неговиот тајминг, онлајн/офлајн, како ќе се формулираат задачите (и дали воопшто ќе се формулираат), дали ќе има преглед на кодот на хакатонот итн. Од оваа гледна точка се оценуваат и тимовите и она што го направија. И победуваат оние тимови кои најдобро ја погодиле точката што и е потребна на компанијата, а многумина до овој момент стигнуваат сосема несвесно и случајно, мислејќи дека навистина учествуваат во спортски натпревар. Моите согледувања покажуваат дека за да ги мотивираат учесниците, организаторите треба да создадат барем изглед на спортско опкружување и еднакви услови, во спротивно ќе добијат бран на негативност, како во горниот преглед. Но, ние се оддалечуваме.

2. Оттука и следниот заклучок. Организаторите се заинтересирани учесниците да дојдат на хакатонот со своја работа, понекогаш дури и специјално организираат сцена за допишување преку Интернет за оваа намена. Ова овозможува посилни излезни решенија. Концептот на „сопствена работа“ е многу релативен; секој искусен развивач може да акумулира илјадници линии код од неговите стари проекти во своето прво извршување. И дали ова ќе биде однапред подготвен развој? Но, во секој случај важи правилото, кое го изразив во форма на познато мем:

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

3. Избор на тим. Како што забележав во хакатонските разговори, многумина пристапуваат на ова прашање прилично несериозно (иако ова е најважната одлука што ќе го одреди вашиот резултат на хакатонот). Во многу области на активност (и во спортот и во хакатоните) видов дека силните луѓе имаат тенденција да се обединуваат со силните, слабите со слабите, паметните со паметните, добро, генерално, сфаќате... Ова е приближно она што се случува во разговорите: помалку силни програмери веднаш се откинуваат, луѓе кои немаат никакви вештини вредни за хакатон долго време висат во разговорот и избираат тим на принципот дека само некој би го прифатил . На некои хакатони се практикува случајно доделување на тимови, а организаторите тврдат дека случајните тимови не работат полошо од постоечките. Но, според моите согледувања, мотивираните луѓе, по правило, сами наоѓаат тим; ако некој треба да биде назначен, тогаш, често, многу од нив не доаѓаат на хакатонот.

Што се однесува до составот на тимот, ова е многу индивидуално и многу зависи од задачата. Би можел да кажам дека минималниот остварлив тимски состав е дизајнер - фронт-енд или преден крај - бек-енд. Но, исто така знам за случаи кога победиле тимови кои се состојат само од фронт-ендери, кои додале едноставен back-end во node.js или направиле мобилна апликација во React Native; или само од backenders кои направиле едноставен распоред. Во принцип, сè е многу индивидуално и зависи од задачата. Мојот план за избор на тим за хакатонот беше следен: Планирав да составам тим или да се приклучам на тим како front-end - back-end - дизајнер (и самиот сум front-end). И прилично брзо почнав да разговарам со помошник на питон и дизајнер кој ја прифати поканата да ни се придружи. Малку подоцна ни се придружи една девојка, бизнис аналитичар, која веќе имаше искуство да победи на хакатон, и тоа го реши прашањето за нејзино придружување. По кратка средба, решивме да се викаме U4 (URBAN 4, urban four) по аналогија со фантастичната четворка. И тие дури ставија соодветна слика на аватарот на нашиот телеграмски канал.

4. Избор на задача. Како што веќе реков, мора да имате конкурентна предност, задачата за хакатонот е избрана врз основа на ова. Врз основа на ова, откако погледна список со задачи и проценувајќи ја нивната сложеност, се решивме на две задачи: каталог на иновативни претпријатија од DPiIR и chatbot од EFKO. Задачата од DPIiR ја избра бекендерот, задачата од ЕФКО ја избрав јас, затоа што имаше искуство со пишување чет-ботови во node.js и DialogFlow. Задачата на ЕФКО вклучуваше и МЛ; имам одредено, не многу големо, искуство во МЛ. И според условите на проблемот, ми се чинеше дека е малку веројатно да се реши со помош на алатки за ML. Ова чувство се засили кога отидов на состанокот на Urban Tech Challenge, каде што организаторите ми покажаа база на податоци за EFKO, каде што имаше околу 100 фотографии од распоред на производи (снимени од различни агли) и околу 20 класи на грешки во распоредот. И, во исто време, оние што ја нарачаа задачата сакаа да постигнат стапка на успех во класификацијата од 90%. Како резултат на тоа, подготвив презентација на решението без ML, бекендерот подготви презентација врз основа на каталогот и заедно, по финализирањето на презентациите, ги испративме на Urban Tech Challenge. Веќе во оваа фаза беше откриено нивото на мотивација и придонесот на секој учесник. Нашиот дизајнер не учествуваше во дискусиите, одговори доцна, па дури и пополни информации за себе во презентацијата во последниот момент, генерално, се појавија сомнежи.

Како резултат на тоа, ја поминавме задачата од DPiIR и воопшто не бевме вознемирени што не го поминавме EFKO, бидејќи задачата ни изгледаше, благо кажано, чудна.

5. Подготовка за хакатонот. Кога конечно се дозна дека сме се квалификувале за хакатонот, почнавме да ја подготвуваме подготовката. И тука не се залагам да почнам да пишувам код една недела пред почетокот на хакатонот. Во најмала рака, треба да имате подготвена плоча за готвење, со која можете веднаш да започнете со работа, без да мора да конфигурирате алатки и без да налетате на грешки од некои lib што сте решиле да ги пробате за прв пат на хакатон. Знам приказна за аголни инженери кои дојдоа на хакатон и поминаа 2 дена поставувајќи ја изградбата на проектот, така што сè треба да се подготви однапред. Имавме намера да ги дистрибуираме одговорностите на следниов начин: бекендерот пишува роботи кои го пребаруваат Интернетот и ги ставаат сите собрани информации во базата на податоци, додека јас пишувам API во node.js што ја бара оваа база на податоци и ги испраќа податоците напред. Во врска со ова, однапред подготвив сервер користејќи express.js и подготвив front-end во react. Јас не користам CRA, секогаш го приспособувам веб-пакетот за себе и многу добро знам какви ризици може да носи ова (сетете се на приказната за аголните програмери). Во овој момент, побарав шаблони за интерфејс или барем макети од нашиот дизајнер за да имам идеја за тоа што ќе изложам. Теоретски и тој треба сам да направи подготовки и да ги координира со нас, но никогаш не добив одговор. Како резултат на тоа, го позајмив дизајнот од еден од моите стари проекти. И почна да функционира уште побрзо, бидејќи сите стилови за овој проект беа веќе напишани. Оттука и заклучокот: дизајнер не е секогаш потребен во тимот))). Дојдовме на хакатонот со овие случувања.

6. Работете на хакатонот. Првиот пат кога го видов мојот тим во живо беше само на отворањето на хакатонот во Централниот дистрибутивен центар. Се сретнавме, разговаравме за решението и фазите на работа на проблемот. И иако по отварањето требаше да одиме со автобус до Црвен Октомври, отидовме дома да спиеме, договорејќи се да пристигнеме на местото до 9.00 часот. Зошто? Организаторите очигледно сакале да го извлечат максимумот од учесниците, па затоа договориле токму таков распоред. Но, според моето искуство, можете нормално да кодирате без да спиете една ноќ. Што се однесува до второто, веќе не сум сигурен. Хакатонот е маратон, адекватно треба да ја пресметате и планирате својата сила. Згора на тоа, имавме подготовки.

Затоа, по спиењето, во 9.00 седевме на шестиот кат на Девократија. Тогаш нашиот дизајнер неочекувано објави дека нема лаптоп и дека ќе работи од дома, а ќе комуницираме телефонски. Ова беше последната капка. И така од четворка се претворивме во тројка, иако не го сменивме името на тимот. Повторно, ова не беше голем удар за нас, јас веќе го имав дизајнот од стариот проект. Во принцип, на почетокот сè одеше сосема глатко и според планот. Вчитавме во базата на податоци (решивме да користиме neo4j) база на податоци од иновативни компании од организаторите. Почнав да пишувам, потоа го фатив node.js, а потоа работите почнаа да се погрешно. Никогаш порано не сум работел со neo4j, и на почетокот барав работен двигател за оваа база на податоци, потоа сфатив како да напишам барање, а потоа бев изненаден кога открив дека оваа база на податоци, кога се прашува, враќа ентитети во форма на низа од јазли објекти и нивните рабови. Оние. кога побарав организација и сите податоци за неа по TIN, наместо еден објект на организацијата, ми беа вратени долга низа објекти што содржат податоци за оваа организација и односите меѓу нив. Напишав мапер кој помина низ целата низа и ги залепи сите објекти според нивната организација во еден објект. Но, во битка, кога се бараше база на податоци од 8 илјади организации, таа беше извршена исклучително бавно, околу 20 - 30 секунди. Почнав да размислувам за оптимизација... И тогаш застанавме на време и се префрливме на MongoDB и ни требаа околу 30 минути. Вкупно на neo4j се изгубени околу 5 часа.

Запомнете, никогаш не ја земајте технологијата на хакатон со кој не сте запознаени, може да има изненадувања. Но, генерално, освен овој неуспех, се се одвиваше според планот. И веќе утрото на 9 декември имавме целосно работна апликација. За остатокот од денот планиравме да додадеме дополнителни функции на него. Во иднина, сè ми одеше релативно лесно, но бекендерот имаше цел куп проблеми со забраната на неговите роботи во пребарувачите, во спамовите на агрегатори на правни лица, кои беа на првите места на резултатите од пребарувањето при барањето за секоја конкретна компанија. Но, подобро е тој самиот да каже за тоа. Првата дополнителна функција што ја додадов беше пребарување по полно име. Генерален директор на ВКонтакте. Беа потребни неколку часа.

Така, на страницата на компанијата во нашата апликација се појави аватар на генералниот директор, врска до неговата страница VKontakte и некои други податоци. Беше убава цреша на тортата, иако можеби не ни ја донесе победата. Потоа, сакав да водам аналитика. Но, по долго пребарување на опции (имаше многу нијанси со корисничкиот интерфејс), се решив на наједноставната агрегација на организации по код за економска активност. Веќе навечер, во последните часови, поставував шаблон за прикажување иновативни производи (во нашата апликација треба да има дел Производи и услуги), иако заднината не беше подготвен за ова. Во исто време, базата на податоци отекуваше со скокови и граници, роботите продолжија да работат, бекендерот експериментираше со NLP за да ги разликува иновативните текстови од неиновативните))). Но, времето за финалната презентација веќе се приближуваше.

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

8. Терен. Не ми се допадна што презентациите и финалето се одржуваа во посебен работен ден (понеделник). Овде, најверојатно, продолжи политиката на организаторите да го истиснат максимумот од учесниците. Не планирав да земам одмор од работа, сакав само да дојдам во финалето, иако остатокот од мојот тим го зеде слободен ден. Сепак, емоционалното потопување во хакатонот веќе беше толку високо што во 8 часот наутро напишав во разговорот на мојот тим (работниот тим, а не тимот на хакатонот) дека го земам денот на моја сметка и отидов во централното. канцеларија за терени. Нашиот проблем се покажа дека има многу научници за чисти податоци, и тоа во голема мера влијаеше на пристапот кон решавање на проблемот. Многумина имаа добар DS, но никој немаше работен прототип, многумина не можеа да ги заобиколат забраните на нивните роботи во пребарувачите. Бевме единствениот тим со работен прототип. И знаевме како да го решиме проблемот. На крајот победивме на патеката, иако имавме голема среќа што избравме најмалку натпреварувачка задача. Гледајќи ги терените на другите патеки, сфативме дека нема да имаме шанси таму. Сакам да кажам и дека имавме многу среќа со жирито, тие прецизно го проверија кодот. И, судејќи според прегледите, тоа не се случи во сите патеки.

9. Конечно. Откако неколку пати бевме повикани во жирито на преглед на кодот, ние, мислејќи дека конечно ги решивме сите прашања, отидовме да ручаме во Бургер Кинг. Таму повторно не повикаа организаторите, моравме брзо да ги спакуваме нарачките и да се вратиме назад.

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

И морам да признаам, во финалето, наспроти позадината на најсилните тимови од другите патеки, изгледавме бледо; победата во номинацијата за владини клиенти сосема заслужено му припадна на тимот од технолошката патека за недвижнини. Мислам дека клучните фактори кои придонесоа за нашата победа на патеката беа: достапноста на готов празен простор, поради што можевме брзо да направиме прототип, присуството на „нагласи“ во прототипот (пребарување извршни директори на социјалните мрежи) и НЛП вештините на нашиот бекендер, што исто така многу го интересираше жирито.

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

Извор: www.habr.com