ProHoster > Blogs > interneta ziņas > Kā un kāpēc mēs uzvarējām Big Data trasē Urban Tech Challenge hakatonā

Kā un kāpēc mēs uzvarējām Big Data trasē Urban Tech Challenge hakatonā

Mani sauc Dmitrijs. Un es vēlos runāt par to, kā mÅ«su komanda Big Data trasē sasniedza Urban Tech Challenge hakatona finālu. Uzreiz teikÅ”u, ka Å”is nav pirmais hakatons, kurā piedalÄ«jos, un ne pirmais, kurā ieguvu balvas. Å ajā sakarā savā stāstā es vēlos izteikt dažus vispārÄ«gus novērojumus un secinājumus par hakatonu nozari kopumā un izteikt savu viedokli pretstatā negatÄ«vajām atsauksmēm, kas parādÄ«jās tieÅ”saistē tÅ«lÄ«t pēc Urban Tech Challenge beigām (par piemērs Å”is).

Tātad vispirms daži vispārīgi novērojumi.

1. PārsteidzoÅ”i, ka diezgan daudzi cilvēki naivi domā, ka hakatons ir kaut kādas sporta sacensÄ«bas, kurās uzvar labākie kodētāji. Tas ir nepareizi. Neuzskatu gadÄ«jumus, kad hakatona rÄ«kotāji paÅ”i nezina, ko grib (es arÄ« to esmu redzējis). Bet, kā likums, uzņēmums, kas organizē hakatonu, tiecas pēc saviem mērÄ·iem. Viņu saraksts var bÅ«t atŔķirÄ«gs: tas varētu bÅ«t tehnisks dažu problēmu risinājums, jaunu ideju un cilvēku meklÄ“Å”ana utt. Å ie mērÄ·i nereti nosaka pasākuma formātu, laiku, online/offline, kā tiks formulēti uzdevumi (un vai tie vispār tiks formulēti), vai hakatonā bÅ«s koda apskats utt. No Ŕī viedokļa tiek vērtētas gan komandas, gan to paveiktais. Un uzvar tās komandas, kas vislabāk trāpa uzņēmumam nepiecieÅ”amo, un daudzi lÄ«dz Å”im nokļūst pilnÄ«gi neapzināti un nejauÅ”i, domājot, ka viņi patieŔām piedalās sporta sacensÄ«bās. Mani novērojumi liecina, ka, lai motivētu dalÄ«bniekus, organizatoriem vajadzētu radÄ«t vismaz sportiskas vides izskatu un vienādus apstākļus, pretējā gadÄ«jumā viņi saņems negatÄ«visma vilni, kā iepriekÅ” minētajā apskatā. Bet mēs novirzāmies.

2. LÄ«dz ar to Ŕāds secinājums. Organizatori ir ieinteresēti, lai dalÄ«bnieki uz hakatonu ierastos ar savu darbu, dažkārt pat speciāli Å”im nolÅ«kam organizē tieÅ”saistes sarakstes posmu. Tas nodroÅ”ina spēcÄ«gākus izvades risinājumus. Jēdziens ā€œpaÅ”u darbsā€ ir ļoti relatÄ«vs; jebkurÅ” pieredzējis izstrādātājs savā pirmajā apņemÅ”anās reizē var uzkrāt tÅ«kstoÅ”iem koda rindu no saviem vecajiem projektiem. Un vai tā bÅ«s iepriekÅ” sagatavota attÄ«stÄ«ba? Bet jebkurā gadÄ«jumā ir spēkā noteikums, ko es izteicu slavenā mēma formā:

Kā un kāpēc mēs uzvarējām Big Data trasē Urban Tech Challenge hakatonā

Lai uzvarētu, ir jābÅ«t kaut kam, kaut kādai konkurences priekÅ”rocÄ«bai: lÄ«dzÄ«gam projektam, ko darÄ«jāt agrāk, zināŔanām un pieredzei konkrētā tēmā vai jau gatavam darbam, kas paveikts pirms hakatona sākuma. Jā, tas nav sports. Jā, tas var nebÅ«t ieguldÄ«to pūļu vērts (Å”eit katrs pats izlemj, vai ir vērts kodēt 3 nedēļas naktÄ«, lai saņemtu balvu 100 tÅ«kstoÅ”u apmērā, kas sadalÄ«ta starp visu komandu, un pat ar risku to nesaņemt). Taču bieži vien Ŕī ir vienÄ«gā iespēja tikt uz priekÅ”u.

3. Komandas atlase. Kā pamanÄ«ju hakatona čatos, daudzi Å”im jautājumam pieiet diezgan vieglprātÄ«gi (lai gan tas ir svarÄ«gākais lēmums, kas noteiks tavu rezultātu hakatonā). Daudzās darbÄ«bas jomās (gan sportā, gan hakatonos) esmu redzējis, ka stipri cilvēki mēdz apvienoties ar stiprajiem, vājie ar vājajiem, gudrie ar gudrajiem, nu, vispār jau saproti... Apmēram tā arÄ« notiek čatos: mazāk spēcÄ«gi programmētāji uzreiz tiek noÄ·erti, cilvēki, kuriem nav nekādu hakatonam vērtÄ«gu prasmju, ilgi turas čatā un izvēlas komandu pēc principa, ja nu kāds paņemtu. . Dažos hakatonos tiek praktizēta izlases veida iedalÄ«Å”ana komandām, un organizatori apgalvo, ka izlases komandas sniegums nav sliktāks par esoÅ”ajām. Bet, pēc maniem novērojumiem, motivēti cilvēki, kā likums, paÅ”i atrod komandu, ja kāds jānorÄ«ko, tad bieži vien daudzi uz hakatonu neierodas.

Kas attiecas uz komandas sastāvu, tas ir ļoti individuāls un ļoti atkarÄ«gs no uzdevuma. Es varētu teikt, ka minimālais dzÄ«votspējÄ«gais komandas sastāvs ir dizainers - front-end vai front-end - back-end. Taču zinu arÄ« gadÄ«jumus, kad uzvarēja komandas, kas sastāv tikai no priekÅ”gala spēlētājiem, kuras pievienoja vienkārÅ”u back-end node.js vai izveidoja mobilo aplikāciju React Native; vai tikai no backenderiem, kuri veica vienkārÅ”u izkārtojumu. Kopumā viss ir ļoti individuāls un atkarÄ«gs no uzdevuma. Mans plāns, izvēloties komandu hakatonam, bija Ŕāds: es plānoju komplektēt komandu vai pievienoties komandai, piemēram, front-end - back-end - dizainers (es pats esmu front-end). Un diezgan ātri es sāku tērzēt ar python backender un dizaineru, kurÅ” pieņēma uzaicinājumu pievienoties mums. Nedaudz vēlāk mums pievienojās meitene, biznesa analÄ«tiÄ·e, kurai jau bija pieredze uzvarēt hakatonā, un tas izŔķīra jautājumu par viņas pievienoÅ”anos mums. Pēc Ä«sas tikÅ”anās mēs nolēmām sevi saukt par U4 (URBAN 4, urban four) pēc analoÄ£ijas ar fantastisko četrinieku. Un viņi pat ievietoja atbilstoÅ”u attēlu mÅ«su telegrammas kanāla iemiesojumā.

4. Uzdevuma izvēle. Kā jau teicu, jums ir jābÅ«t konkurences priekÅ”rocÄ«bām, pamatojoties uz to, tiek izvēlēts uzdevums hakatonam. Pamatojoties uz to, paskatÄ«jies uzdevumu saraksts un novērtējot to sarežģītÄ«bu, mēs nolēmām divus uzdevumus: novatorisku uzņēmumu katalogu no DPiIR un tērzÄ“Å”anas robotu no EFKO. Uzdevumu no DPIiR izvēlējās backender, uzdevumu no EFKO izvēlējos es, jo bija pieredze tērzÄ“Å”anas robotu rakstÄ«Å”anā node.js un DialogFlow. EFKO uzdevums ietvēra arÄ« ML; man ir neliela, ne pārāk liela pieredze ML. Un pēc problēmas apstākļiem man Ŕķita, ka to diez vai varēs atrisināt, izmantojot ML rÄ«kus. Å Ä« sajÅ«ta nostiprinājās, kad devos uz Urban Tech Challenge tikÅ”anos, kur organizatori man parādÄ«ja EFKO datu kopu, kurā bija aptuveni 100 produktu izkārtojumu fotogrāfijas (uzņemtas no dažādiem leņķiem) un aptuveni 20 izkārtojuma kļūdu klases. Un tajā paŔā laikā tie, kas pasÅ«tÄ«ja uzdevumu, vēlējās sasniegt klasifikācijas panākumu lÄ«meni 90%. Rezultātā es sagatavoju risinājuma prezentāciju bez ML, backender sagatavoja prezentāciju pēc kataloga un kopā pēc prezentāciju pabeigÅ”anas nosÅ«tÄ«jām tās uz Urban Tech Challenge. Jau Å”ajā posmā atklājās katra dalÄ«bnieka motivācijas lÄ«menis un ieguldÄ«jums. MÅ«su dizainers diskusijās nepiedalÄ«jās, atbildēja novēloti un pat prezentācijā aizpildÄ«ja informāciju par sevi paŔā pēdējā brÄ«dÄ«, kopumā radās Å”aubas.

Rezultātā mēs izturējām uzdevumu no DPiIR un nemaz nebijām sarÅ«gtināti, ka neizturējām EFKO, jo uzdevums mums, maigi izsakoties, Ŕķita dÄ«vains.

5. GatavoÅ”anās hakatonam. Kad beidzot kļuva zināms, ka esam kvalificējuÅ”ies hakatonam, sākām gatavoties. Un Å”eit es neaicinu sākt rakstÄ«t kodu nedēļu pirms hakatona sākuma. Vismaz jums ir jābÅ«t gatavai sistēmai, ar kuru jÅ«s varat nekavējoties sākt darbu, nekonfigurējot rÄ«kus un nesaskaroties ar kādu lib kļūdu, ko nolēmāt izmēģināt pirmo reizi hakatonā. Es zinu stāstu par leņķiskajiem inženieriem, kuri ieradās hakatonā un pavadÄ«ja 2 dienas, lai izveidotu projekta bÅ«vi, tāpēc visam vajadzētu sagatavoties iepriekÅ”. Mēs plānojām pienākumus sadalÄ«t Ŕādi: aizmugure raksta rāpuļprogrammas, kas izpēta internetu un ievieto visu savākto informāciju datu bāzē, savukārt es node.js ierakstu API, kas vaicā Å”o datu bāzi un nosÅ«ta datus uz priekÅ”u. Å ajā sakarā es iepriekÅ” sagatavoju serveri, izmantojot express.js, un sagatavoju priekÅ”galu react. Es neizmantoju CRA, vienmēr pielāgoju tÄ«mekļa pakotni sev un ļoti labi zinu, kādus riskus tas var radÄ«t (atcerieties stāstu par leņķiskajiem izstrādātājiem). Å ajā brÄ«dÄ« es pieprasÄ«ju mÅ«su dizainera saskarnes veidnes vai vismaz maketus, lai bÅ«tu priekÅ”stats par to, ko es izkārtoÅ”u. Teorētiski viņam vajadzētu arÄ« paÅ”am sagatavoties un saskaņot ar mums, bet es tā arÄ« nesaņēmu atbildi. Rezultātā es aizņēmos dizainu no viena no saviem vecajiem projektiem. Un tas sāka darboties vēl ātrāk, jo visi Ŕī projekta stili jau bija uzrakstÄ«ti. No tā izriet secinājums: dizainers ne vienmēr ir vajadzÄ«gs komandā))). Mēs ieradāmies hakatonā ar Å”iem notikumiem.

6. Darbs hakatonā. Pirmo reizi savu komandu tieÅ”raidē redzēju tikai hakatona atklāŔanā Centrālajā sadales centrā. Tikāmies, pārrunājām problēmas risinājumu un darba posmus. Un, lai gan pēc atklāŔanas mums bija jādodas ar autobusu uz Sarkano oktobri, devāmies mājās gulēt, vienojoties ierasties vietā lÄ«dz 9.00. Kāpēc? Organizatori acÄ«mredzot vēlējās no dalÄ«bniekiem gÅ«t maksimālu labumu, tāpēc sakārtoja tieÅ”i Ŕādu grafiku. Bet, pēc manas pieredzes, jÅ«s varat normāli kodēt, neguļot vienu nakti. Kas attiecas uz otro, es vairs neesmu pārliecināts. Hakatons ir maratons, jums ir adekvāti jāaprēķina un jāplāno savi spēki. Turklāt mums bija sagatavoÅ”anās darbi.

Kā un kāpēc mēs uzvarējām Big Data trasē Urban Tech Challenge hakatonā

Tāpēc pēc izgulÄ“Å”anās 9.00 sēdējām Dewocracy sestajā stāvā. Tad mÅ«su dizainers negaidÄ«ti paziņoja, ka viņam nav portatÄ«vā datora un viņŔ strādās no mājām, un mēs sazināsimies pa telefonu. Å is bija pēdējais piliens. Un tā mēs pagriezāmies no četrinieka uz trÄ«s, lai gan komandas nosaukumu nemainÄ«jām. Atkal, tas mums nebija liels trieciens; man jau bija dizains no vecā projekta. Kopumā sākumā viss noritēja diezgan gludi un pēc plāna. Mēs ielādējām datubāzē (nolēmām izmantot neo4j) inovatÄ«vu uzņēmumu datu kopu no organizatoriem. Es sāku drukāt, tad paņēmu node.js, un tad viss sāka aizdegties. Es nekad iepriekÅ” nebiju strādājis ar neo4j, un sākumā meklēju Å”ai datubāzei strādājoÅ”u draiveri, pēc tam izdomāju, kā uzrakstÄ«t vaicājumu, un tad ar pārsteigumu atklāju, ka Ŕī datu bāze pēc vaicājuma atgriež entÄ«tijas mezglu objektu un to malu masÄ«va forma. Tie. Kad es pieprasÄ«ju organizāciju un visus datus par to, izmantojot TIN, viena organizācijas objekta vietā man tika atgriezts liels objektu klāsts, kurā bija dati par Å”o organizāciju un to savstarpējām attiecÄ«bām. Es uzrakstÄ«ju kartētāju, kas izgāja cauri visam masÄ«vam un salÄ«mēja visus objektus atbilstoÅ”i to organizācijai vienā objektā. Bet kaujā, pieprasot 8 tÅ«kstoÅ”u organizāciju datubāzi, tas tika izpildÄ«ts ārkārtÄ«gi lēni, apmēram 20 - 30 sekundes. Sāku domāt par optimizāciju... Un tad mēs laikus apstājāmies un pārgājām uz MongoDB, un tas aizņēma kādas 30 minÅ«tes. Kopumā uz neo4j tika zaudētas apmēram 5 stundas.

Atcerieties, nekad neņemiet tehnoloÄ£iju uz hakatonu, kas jums nav pazÄ«stams, jo var bÅ«t pārsteigumi. Bet kopumā, ja neskaita Å”o neveiksmi, viss noritēja pēc plāna. Un jau 9. decembra rÄ«tā mums bija pilnÄ«bā strādājoÅ”a aplikācija. AtlikuÅ”ajā dienas daļā mēs plānojām tam pievienot papildu funkcijas. Turpmāk man viss gāja samērā gludi, bet aizmugure sagādāja vesela kaudze problēmu ar viņa rāpuļprogrammu aizliegÅ”anu meklētājprogrammās, juridisko personu agregatoru surogātpastā, kas pieprasot nonāca meklÄ“Å”anas rezultātu pirmajās vietās. katram konkrētam uzņēmumam. Bet labāk viņam paÅ”am par to pastāstÄ«t. Pirmā papildu funkcija, ko pievienoju, bija meklÄ“Å”ana pēc pilna vārda. VKontakte Ä£enerāldirektors. Pagāja vairākas stundas.

Tātad uzņēmuma lapā mÅ«su lietojumprogrammā parādÄ«jās Ä£enerāldirektora iemiesojums, saite uz viņa VKontakte lapu un daži citi dati. Tas bija jauks Ä·irsis uz kÅ«kas, lai gan tas varbÅ«t nedeva mums uzvaru. Pēc tam es gribēju palaist kādu analÄ«zi. Bet pēc ilgas iespēju meklÄ“Å”anas (ar UI bija daudz nianÅ”u) es nokārtojos uz vienkārŔāko organizāciju apkopoÅ”anu pēc saimnieciskās darbÄ«bas koda. Jau vakarā, pēdējās stundās, klāju veidni inovatÄ«vu produktu attēloÅ”anai (mÅ«su aplikācijā it kā ir sadaļa Produkti un pakalpojumi), lai gan aizmugure tam nebija gatava. Tajā paŔā laikā datubāze strauji pieauga, rāpuļprogrammas turpināja strādāt, aizmugure eksperimentēja ar NLP, lai atŔķirtu novatoriskus tekstus no nenovatoriem))). Taču noslēguma prezentācijas laiks jau tuvojās.

7. Prezentācija. No savas pieredzes varu teikt, ka jums vajadzētu pāriet uz prezentācijas sagatavoÅ”anu apmēram 3 lÄ«dz 4 stundas pirms tās termiņa. It Ä«paÅ”i, ja tas ir saistÄ«ts ar video, tā uzņemÅ”ana un rediģēŔana aizņem diezgan daudz laika. Mums bija paredzēts video. Un mums bija Ä«paÅ”s cilvēks, kas ar to nodarbojās, kā arÄ« risināja vairākus citus organizatoriskus jautājumus. Å ajā sakarā mēs lÄ«dz pēdējam brÄ«dim nenovērsām uzmanÄ«bu no kodÄ“Å”anas.

8. PiÄ·is. Man nepatika, ka prezentācijas un fināli notika atseviŔķā darba dienā (pirmdien). Å eit, visticamāk, turpinājās organizatoru politika izspiest no dalÄ«bniekiem maksimumu. Es neplānoju atvaļinājumu no darba, gribēju tikai tikt uz finālu, lai gan pārējā komanda paņēma brÄ«vu dienu. Taču emocionālā iedziļināŔanās hakatonā jau bija tik liela, ka pulksten 8 savas komandas (darba, nevis hakatona komandas) čatā ierakstÄ«ju, ka dienu pavadu par saviem lÄ«dzekļiem, un devos uz centrālo. birojs laukumiem. IzrādÄ«jās, ka mÅ«su problēmai ir daudz tÄ«ru datu zinātnieku, un tas lielā mērā ietekmēja pieeju problēmas risināŔanai. Daudziem bija labs DS, bet nevienam nebija strādājoÅ”a prototipa, daudzi nevarēja apiet savu rāpuļprogrammu aizliegumus meklētājprogrammās. Mēs bijām vienÄ«gā komanda ar funkcionējoÅ”u prototipu. Un mēs zinājām, kā atrisināt problēmu. Beigās uzvarējām trasi, lai gan ļoti paveicās, ka izvēlējāmies vismazāk konkurētspējÄ«go uzdevumu. Apskatot laukumus citās trasēs, sapratām, ka tur mums nebÅ«s nekādu izredžu. Es arÄ« gribu teikt, ka mums ļoti paveicās ar žūriju, viņi rÅ«pÄ«gi pārbaudÄ«ja kodu. Un, spriežot pēc atsauksmēm, tas nenotika visās trasēs.

9. Fināls. Pēc tam, kad vairākas reizes tikām izsaukti pie žūrijas uz koda pārskatÄ«Å”anu, mēs, domājot, ka beidzot esam atrisinājuÅ”i visus jautājumus, devāmies pusdienot uz Burger King. Tur mums atkal zvanÄ«ja organizatori, nācās ātri iesaiņot pasÅ«tÄ«jumus un doties atpakaļ.

Organizators mums parādÄ«ja, kurā telpā jāiet, un, ieejot, mēs nokļuvām uzvarētāju komandu publiskās runas apmācÄ«bā. PuiÅ”i, kuriem vajadzēja uzstāties uz skatuves, bija labi uzlādēti, visi iznāca kā Ä«sti Å”ovmeņi.

Un jāatzÄ«st, ka finālā uz citu traÅ”u spēcÄ«gāko komandu fona izskatÄ«jāmies bāli, valdÄ«bas klientu nominācijā uzvara gluži pelnÄ«ti tika nekustamo Ä«paÅ”umu tehnoloÄ£iju trases komandai. Es domāju, ka galvenie faktori, kas veicināja mÅ«su uzvaru trasē, bija: gatavās sagataves pieejamÄ«ba, kuras dēļ mēs varējām ātri izgatavot prototipu, prototipa "izcelto punktu" klātbÅ«tne (meklējiet izpilddirektorus sociālajos tÄ«klos) un mÅ«su backender NLP prasmes, kas arÄ« ļoti ieinteresēja žūriju.

Kā un kāpēc mēs uzvarējām Big Data trasē Urban Tech Challenge hakatonā

Un noslēgumā tradicionāls paldies visiem, kas mÅ«s atbalstÄ«ja, mÅ«su trases žūrijai Jevgeņijam Jevgrafijevam (problēmas autoram, kuru atrisinājām hakatonā) un, protams, hakatona organizatoriem. Å is, iespējams, bija lielākais un forŔākais hakatons, kurā esmu piedalÄ«jies, varu tikai novēlēt puiÅ”iem arÄ« turpmāk saglabāt tik augstu lÄ«meni!

Avots: www.habr.com

Pievieno komentāru