Jina langu ni Dmitry. Na ninataka kuzungumzia jinsi timu yetu ilifika fainali ya Urban Tech Challenge hackathon kwenye wimbo wa Big Data. Nitasema mara moja kuwa hii sio hackathon ya kwanza ambayo nilishiriki, na sio ya kwanza ambayo nilichukua tuzo. Kuhusiana na hili, katika hadithi yangu ninataka kutoa maoni na hitimisho la jumla kuhusu tasnia ya hackathon kwa ujumla, na kutoa maoni yangu tofauti na hakiki hasi zilizoonekana mtandaoni mara tu baada ya kumalizika kwa Urban Tech Challenge (kwa mfano ).
Hivyo kwanza baadhi ya uchunguzi wa jumla.
1. Inashangaza kwamba watu wachache kabisa wanafikiri kwamba hackathon ni aina fulani ya mashindano ya michezo ambapo coders bora hushinda. Hii si sahihi. Sizingatii kesi wakati waandaaji wa hackathon wenyewe hawajui wanachotaka (nimeona pia). Lakini, kama sheria, kampuni inayopanga hackathon hufuata malengo yake mwenyewe. Orodha yao inaweza kuwa tofauti: inaweza kuwa suluhisho la kiufundi kwa matatizo fulani, utafutaji wa mawazo mapya na watu, nk. Malengo haya mara nyingi huamua muundo wa tukio, muda wake, mtandaoni/nje ya mtandao, jinsi kazi zitakavyoundwa (na iwapo zitaundwa hata kidogo), iwapo kutakuwa na ukaguzi wa msimbo kwenye hackathon, n.k. Timu zote mbili na kile walichokifanya kinatathminiwa kwa mtazamo huu. Na timu hizo ambazo zimefikia hatua ambayo kampuni inahitaji kushinda, na nyingi hufikia hatua hii bila kujua na kwa bahati mbaya, wakifikiri kwamba wanashiriki katika mashindano ya michezo. Uchunguzi wangu unaonyesha kuwa ili kuwahamasisha washiriki, waandaaji wanapaswa kuunda angalau mwonekano wa mazingira ya michezo na hali sawa, vinginevyo watapata wimbi la uzembe, kama ilivyo kwenye hakiki hapo juu. Lakini tunaacha.
2. Hivyo hitimisho lifuatalo. Waandaaji wanavutiwa na washiriki wanaokuja kwenye hackathon na kazi zao wenyewe, wakati mwingine hata hupanga haswa hatua ya mawasiliano mkondoni kwa kusudi hili. Hii inaruhusu ufumbuzi wa pato wenye nguvu zaidi. Wazo la "kazi yako mwenyewe" ni jamaa sana; msanidi programu yeyote mwenye uzoefu anaweza kukusanya maelfu ya mistari ya msimbo kutoka kwa miradi yake ya zamani katika ahadi yake ya kwanza. Na hii itakuwa maendeleo yaliyotayarishwa kabla? Lakini kwa hali yoyote, sheria inatumika, ambayo nilionyesha kwa njia ya meme maarufu:
Ili kushinda, lazima uwe na kitu, aina fulani ya faida ya ushindani: mradi sawa ambao ulifanya zamani, ujuzi na uzoefu katika mada maalum, au kazi iliyofanywa tayari kabla ya kuanza kwa hackathon. Ndio, sio mchezo. Ndiyo, hii inaweza kuwa haifai jitihada zilizotumiwa (hapa, kila mtu anaamua mwenyewe ikiwa ni thamani ya kuweka coding kwa wiki 3 usiku kwa tuzo ya elfu 100, iliyogawanywa kati ya timu nzima, na hata kwa hatari ya kutoipata). Lakini, mara nyingi, hii ndiyo nafasi pekee ya kwenda mbele.
3. Uchaguzi wa timu. Kama nilivyoona kwenye gumzo za hackathon, wengi huchukulia suala hili kwa ujinga (ingawa huu ndio uamuzi muhimu zaidi ambao utaamua matokeo yako kwenye hackathon). Katika maeneo mengi ya shughuli (katika michezo na hackathons) nimeona kuwa watu wenye nguvu huwa na kuungana na wenye nguvu, dhaifu na dhaifu, wenye akili na wenye akili, vizuri, kwa ujumla, unapata wazo ... Hii ndio takribani kile kinachotokea kwenye gumzo: waandaaji wa programu wenye nguvu kidogo wananaswa mara moja, watu ambao hawana ujuzi wowote muhimu kwa hackathon hukaa kwenye gumzo kwa muda mrefu na kuchagua timu kwa kanuni kwamba ikiwa tu mtu angeikubali. . Katika baadhi ya hackathons, mgawo wa nasibu kwa timu hufanywa, na waandaaji wanadai kwamba timu za nasibu hazifanyi vibaya zaidi kuliko zilizopo. Lakini kulingana na uchunguzi wangu, watu waliohamasishwa, kama sheria, hupata timu peke yao; ikiwa mtu lazima apewe, basi, mara nyingi, wengi wao hawaji kwenye hackathon.
Kuhusu muundo wa timu, hii ni ya mtu binafsi na inategemea sana kazi hiyo. Ningeweza kusema kwamba utungaji wa chini kabisa wa timu ni mbunifu - mbele-mwisho au mbele-mwisho - nyuma-mwisho. Lakini pia najua kesi wakati timu zinazojumuisha washindi wa mbele pekee zilishinda, ambao waliongeza sehemu rahisi ya nyuma katika node.js, au walituma programu ya simu katika React Native; au tu kutoka kwa waungaji mkono ambao walifanya mpangilio rahisi. Kwa ujumla, kila kitu ni mtu binafsi na inategemea kazi. Mpango wangu wa kuchagua timu kwa ajili ya hackathon ulikuwa kama ifuatavyo: Nilipanga kukusanya timu au kujiunga na timu kama vile mbunifu-mwisho-mwisho-mwisho (mimi ni mtu wa mbele-mwenyewe). Na kwa haraka sana nilianza kuzungumza na chatu na mbunifu ambaye alikubali mwaliko wa kujiunga nasi. Baadaye kidogo, msichana, mchambuzi wa biashara, ambaye tayari alikuwa na uzoefu wa kushinda hackathon, alijiunga nasi, na hii iliamua suala la yeye kujiunga nasi. Baada ya mkutano mfupi, tuliamua kujiita U4 (MJINI 4, miji minne) kwa mlinganisho na nne bora. Na hata waliweka picha inayolingana kwenye avatar ya chaneli yetu ya telegraph.
4. Kuchagua kazi. Kama nilivyosema tayari, lazima uwe na faida ya ushindani, kazi ya hackathon imechaguliwa kulingana na hii. Kulingana na hili, baada ya kuangalia na kutathmini ugumu wao, tulitatua kazi mbili: katalogi ya biashara bunifu kutoka DPiIR na chatbot kutoka EFKO. Kazi kutoka kwa DPIiR ilichaguliwa na backender, kazi kutoka kwa EFKO ilichaguliwa na mimi, kwa sababu alikuwa na uzoefu wa kuandika chatbots katika node.js na DialogFlow. Kazi ya EFKO pia ilihusisha ML; Nina uzoefu, sio wa kina sana katika ML. Na kulingana na hali ya shida, ilionekana kwangu kuwa haikuwezekana kutatuliwa kwa kutumia zana za ML. Hisia hii iliimarishwa nilipoenda kwenye mkutano wa Urban Tech Challenge, ambapo waandaaji walinionyesha seti ya data kwenye EFKO, ambapo kulikuwa na takriban picha 100 za mipangilio ya bidhaa (zilizochukuliwa kutoka pembe tofauti) na takriban madarasa 20 ya makosa ya mpangilio. Na, wakati huo huo, wale walioamuru kazi hiyo walitaka kufikia kiwango cha mafanikio ya uainishaji wa 90%. Kama matokeo, nilitayarisha uwasilishaji wa suluhisho bila ML, msaidizi alitayarisha uwasilishaji kulingana na katalogi, na kwa pamoja, baada ya kukamilisha mawasilisho, tuliwapeleka kwenye Urban Tech Challenge. Tayari katika hatua hii, kiwango cha motisha na mchango wa kila mshiriki kilifunuliwa. Mbuni wetu hakushiriki katika majadiliano, alijibu marehemu, na hata akajaza habari juu yake katika uwasilishaji wakati wa mwisho kabisa, kwa ujumla, mashaka yalitokea.
Kama matokeo, tulipitisha kazi hiyo kutoka kwa DPiIR, na hatukukasirika kabisa kwamba hatukupitisha EFKO, kwani kazi hiyo ilionekana kuwa ya kushangaza kwetu, kuiweka kwa upole.
5. Kuandaa kwa hackathon. Hatimaye ilipojulikana kwamba tumehitimu kwa hackathon, tulianza kutayarisha maandalizi. Na hapa sipendekezi kuanza kuandika msimbo wiki moja kabla ya kuanza kwa hackathon. Kwa kiwango cha chini, unapaswa kuwa na boilerplate tayari, ambayo unaweza kuanza kufanya kazi mara moja, bila kuhitaji kusanidi zana, na bila kugongana na mende wa lib fulani ambayo uliamua kujaribu kwa mara ya kwanza kwenye hackathon. Ninajua hadithi kuhusu wahandisi wa angular ambao walikuja kwenye hackathon na kutumia siku 2 kuanzisha mradi wa kujenga, hivyo kila kitu kinapaswa kutayarishwa mapema. Tulinuia kusambaza majukumu kama ifuatavyo: mtoa huduma nyuma huandika vitambazaji ambavyo hukagua Mtandao na kuweka taarifa zote zilizokusanywa kwenye hifadhidata, huku nikiandika API katika node.js ambayo huuliza hifadhidata hii na kutuma data mbele. Katika suala hili, nilitayarisha seva mapema kwa kutumia Express.js na kuandaa mwisho wa mbele kwa kuguswa. Situmii CRA, mimi hubinafsisha kifurushi cha wavuti kila wakati na ninajua vizuri ni hatari gani hii inaweza kusababisha (kumbuka hadithi kuhusu wasanidi wa angular). Kwa wakati huu, niliomba violezo vya kiolesura au angalau nakala kutoka kwa mbunifu wetu ili kuwa na wazo la kile ningekuwa nikiweka. Kwa nadharia, anapaswa pia kufanya maandalizi yake mwenyewe na kuyaratibu na sisi, lakini sikupata jibu. Kama matokeo, nilikopa muundo kutoka kwa moja ya miradi yangu ya zamani. Na ilianza kufanya kazi haraka zaidi, kwani mitindo yote ya mradi huu ilikuwa tayari imeandikwa. Kwa hivyo hitimisho: mbuni haihitajiki kila wakati kwenye timu))). Tulikuja kwenye hackathon na maendeleo haya.
6. Fanya kazi kwenye hackathon. Mara ya kwanza nilipoona timu yangu moja kwa moja ilikuwa tu kwenye ufunguzi wa hackathon kwenye Kituo Kikuu cha Usambazaji. Tulikutana, tukajadili suluhisho na hatua za kushughulikia shida. Na ingawa baada ya ufunguzi tulilazimika kwenda kwa basi hadi Red Oktoba, tulienda nyumbani kulala, tukakubali kufika mahali hapo saa 9.00. Kwa nini? Inaonekana waandaaji walitaka kufaidika zaidi na washiriki, kwa hiyo walipanga ratiba kama hiyo. Lakini, kwa uzoefu wangu, unaweza kuweka nambari kawaida bila kulala kwa usiku mmoja. Kuhusu ya pili, sina uhakika tena. Hackathon ni marathon; unahitaji kuhesabu vya kutosha na kupanga nguvu zako. Zaidi ya hayo, tulikuwa na maandalizi.
Kwa hiyo, baada ya kulala mbali, saa 9.00 tulikuwa tumeketi kwenye ghorofa ya sita ya Dewocracy. Kisha mbuni wetu alitangaza bila kutarajia kwamba hakuwa na kompyuta ya mkononi na kwamba angefanya kazi kutoka nyumbani, na tungewasiliana kwa simu. Hili lilikuwa tangazo la mwisho. Na kwa hivyo tuligeuka kutoka nne hadi tatu, ingawa hatukubadilisha jina la timu. Tena, hili halikuwa pigo kubwa kwetu; tayari nilikuwa na muundo kutoka kwa mradi wa zamani. Kwa ujumla, mwanzoni kila kitu kilikwenda vizuri na kulingana na mpango. Tulipakia kwenye hifadhidata (tuliamua kutumia neo4j) mkusanyiko wa data wa kampuni bunifu kutoka kwa waandaaji. Nilianza kuandika, kisha nikachukua node.js, na kisha mambo yakaanza kwenda vibaya. Sikuwahi kufanya kazi na neo4j hapo awali, na mwanzoni nilikuwa nikitafuta dereva anayefanya kazi kwa hifadhidata hii, kisha nikafikiria jinsi ya kuandika swali, na kisha nikashangaa kugundua kuwa hifadhidata hii, inapoulizwa, inarudisha vyombo kwenye aina ya safu ya vitu vya nodi na kingo zao. Wale. nilipoomba shirika na data yote iliyo juu yake na TIN, badala ya kitu kimoja cha shirika, nilirejeshewa safu ndefu ya vitu vilivyo na data ya shirika hili na uhusiano kati yao. Niliandika ramani ambayo ilipitia safu nzima na kubandika vitu vyote kulingana na shirika lao kuwa kitu kimoja. Lakini katika vita, wakati wa kuomba hifadhidata ya mashirika elfu 8, ilitekelezwa polepole sana, kama sekunde 20 - 30. Nilianza kufikiria juu ya uboreshaji ... Na kisha tukasimama kwa wakati na kubadili MongoDB, na ilituchukua kama dakika 30. Kwa jumla, takriban saa 4 zilipotea kwenye neo5j.
Kumbuka, kamwe usipeleke teknolojia kwa hackathon ambayo huifahamu, kunaweza kuwa na mshangao. Lakini, kwa ujumla, mbali na kushindwa huku, kila kitu kilikwenda kulingana na mpango. Na tayari asubuhi ya Desemba 9, tulikuwa na maombi ya kufanya kazi kikamilifu. Kwa siku nzima tulipanga kuongeza vipengele vya ziada kwake. Katika siku zijazo, kila kitu kilienda sawa kwangu, lakini msaidizi alikuwa na rundo zima la shida na marufuku ya watambazaji wake kwenye injini za utaftaji, kwenye barua taka za wakusanyaji wa vyombo vya kisheria, ambao walikuja katika sehemu za kwanza za matokeo ya utaftaji wakati wa kuomba. kwa kila kampuni maalum. Lakini ni bora kwake kusema juu yake mwenyewe. Kipengele cha kwanza cha ziada nilichoongeza kilikuwa tafuta kwa jina kamili. Mkurugenzi Mkuu wa VKontakte. Ilichukua masaa kadhaa.
Kwa hivyo, kwenye ukurasa wa kampuni katika maombi yetu, avatar ya mkurugenzi mkuu ilionekana, kiungo kwenye ukurasa wake wa VKontakte na data nyingine. Ilikuwa cherry nzuri kwenye keki, ingawa inaweza kuwa haijatupa ushindi. Kisha, nilitaka kuendesha uchanganuzi fulani. Lakini baada ya utaftaji mrefu wa chaguzi (kulikuwa na nuances nyingi na UI), nilitulia kwenye mkusanyiko rahisi wa mashirika kwa nambari ya shughuli za kiuchumi. Tayari jioni, katika masaa ya mwisho, nilikuwa nikiweka kiolezo cha kuonyesha bidhaa za ubunifu (katika programu yetu inapaswa kuwa na sehemu ya Bidhaa na Huduma), ingawa sehemu ya nyuma haikuwa tayari kwa hili. Wakati huo huo, hifadhidata ilikuwa ikivimba kwa kiwango kikubwa na mipaka, watambazaji waliendelea kufanya kazi, msaidizi wa nyuma alijaribu NLP kutofautisha maandishi ya ubunifu kutoka kwa yale yasiyo ya ubunifu))). Lakini wakati wa uwasilishaji wa mwisho ulikuwa tayari unakaribia.
7. Uwasilishaji. Kutokana na uzoefu wangu mwenyewe, naweza kusema kwamba unapaswa kubadili utayarishaji wa wasilisho takribani saa 3 hadi 4 kabla ya kukamilika. Hasa ikiwa inahusisha video, upigaji picha na uhariri wake huchukua muda mwingi sana. Tulitakiwa kuwa na video. Na tulikuwa na mtu maalum ambaye alishughulikia hili, na pia alitatua maswala mengine kadhaa ya shirika. Katika suala hili, hatukujisumbua kutoka kwa kuweka msimbo hadi dakika ya mwisho kabisa.
8. Lami. Sikupenda kwamba maonyesho na fainali zilifanyika siku tofauti ya juma (Jumatatu). Hapa, uwezekano mkubwa, sera ya waandaaji ya kufinya kiwango cha juu kutoka kwa washiriki iliendelea. Sikupanga kuchukua likizo kazini, nilitaka kufika fainali tu, ingawa timu yangu yote ilichukua mapumziko ya siku. Walakini, kuzamishwa kwa kihemko kwenye hackathon tayari kulikuwa juu sana hivi kwamba saa 8 asubuhi niliandika kwenye gumzo la timu yangu (timu ya kazi, sio timu ya hackathon) ambayo nilikuwa nikichukua siku kwa gharama yangu mwenyewe, na nikaenda katikati. ofisi kwa viwanja. Tatizo letu liligeuka kuwa na wanasayansi wengi wa data safi, na hii iliathiri sana mbinu ya kutatua tatizo. Wengi walikuwa na DS nzuri, lakini hakuna mtu aliyekuwa na mfano wa kufanya kazi, wengi hawakuweza kuzunguka marufuku ya watambazaji wao katika injini za utafutaji. Tulikuwa timu pekee iliyo na mfano wa kufanya kazi. Na tulijua jinsi ya kutatua shida. Mwishowe, tulishinda wimbo huo, ingawa tulikuwa na bahati sana kwamba tulichagua kazi yenye ushindani mdogo. Kuangalia viwanja katika nyimbo zingine, tuligundua kuwa hatutakuwa na nafasi huko. Pia nataka kusema kwamba tulikuwa na bahati sana na jury; walikagua msimbo kwa uangalifu. Na, kwa kuzingatia hakiki, hii haikutokea katika nyimbo zote.
9. Mwisho. Baada ya kuitwa kwa jury mara kadhaa kwa ajili ya ukaguzi wa kanuni, sisi, tukifikiri kwamba hatimaye tumesuluhisha masuala yote, tulienda kula chakula cha mchana huko Burger King. Huko waandaaji walituita tena, ilibidi tupakie maagizo yetu haraka na kurudi.
Mratibu alituonyesha ni chumba gani tulichohitaji kuingia, na tulipoingia, tulijikuta kwenye kipindi cha mazoezi ya kuzungumza hadharani kwa timu zilizoshinda. Wavulana ambao walipaswa kutumbuiza kwenye jukwaa walishtakiwa vizuri, kila mtu alitoka kama washiriki wa kweli.
Na lazima nikiri, katika fainali, dhidi ya timu zenye nguvu zaidi kutoka kwa vikundi vingine, tulionekana tulivu; ushindi katika uteuzi wa wateja wa serikali ulistahili kabisa kwa timu kutoka kwa wimbo wa teknolojia ya mali isiyohamishika. Nadhani mambo muhimu yaliyochangia ushindi wetu kwenye wimbo huo ni: kupatikana kwa tupu iliyotengenezwa tayari, kwa sababu ambayo tuliweza kutengeneza mfano wa haraka, uwepo wa "muhimu" kwenye mfano (tafuta Wakurugenzi Wakuu). kwenye mitandao ya kijamii) na ujuzi wa NLP wa msaidizi wetu , ambayo pia ilivutia sana jury.
Na kwa kumalizia, shukrani za jadi kwa wale wote waliotuunga mkono, jury la wimbo wetu, Evgeniy Evgrafiev (mwandishi wa shida ambayo tulitatua kwenye hackathon) na bila shaka waandaaji wa hackathon. Labda hii ilikuwa hackathon kubwa na ya baridi zaidi ambayo nimewahi kushiriki, ninaweza tu kuwatakia watu hao kudumisha kiwango cha juu kama hicho katika siku zijazo!
Chanzo: mapenzi.com