Мяне клічуць Зміцер. І я хачу расказаць пра тое, як наша каманда выйшла ў фінал хакатона 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