Numele meu este Dmitry. Și vreau să vorbesc despre modul în care echipa noastră a ajuns în finala hackatonului Urban Tech Challenge pe pista Big Data. Vă spun imediat că acesta nu este primul hackathon la care am participat și nici primul la care am luat premii. În acest sens, în povestea mea vreau să exprim câteva observații și concluzii generale cu privire la industria hackatonului în ansamblu și să-mi dau punctul de vedere spre deosebire de recenziile negative care au apărut online imediat după încheierea Urban Tech Challenge (pentru exemplu ).
Deci mai întâi câteva observații generale.
1. Este surprinzător că mulți oameni cred naiv că un hackathon este un fel de competiție sportivă în care câștigă cei mai buni programatori. Este gresit. Nu iau în considerare cazurile în care organizatorii de hackathon înșiși nu știu ce vor (am văzut și asta). Dar, de regulă, compania care organizează un hackathon își urmărește propriile obiective. Lista lor poate fi diferită: ar putea fi o soluție tehnică la unele probleme, o căutare de idei și oameni noi etc. Aceste obiective determină adesea formatul evenimentului, calendarul acestuia, online/offline, modul în care vor fi formulate sarcinile (și dacă vor fi formulate deloc), dacă va exista o revizuire a codului la hackathon etc. Atât echipele, cât și ceea ce au făcut sunt evaluate din acest punct de vedere. Și acele echipe care au ajuns cel mai bine în punctul de care compania are nevoie câștigă, iar multe ajung în acest punct complet inconștient și întâmplător, crezând că participă cu adevărat la o competiție sportivă. Observațiile mele arată că, pentru a motiva participanții, organizatorii ar trebui să creeze cel puțin aspectul unui mediu sportiv și condiții egale, altfel vor primi un val de negativitate, ca în recenzia de mai sus. Dar divagam.
2. De aici concluzia următoare. Organizatorii sunt interesați ca participanții să vină la hackathon cu munca lor, uneori chiar organizează special o etapă de corespondență online în acest scop. Acest lucru permite soluții de producție mai puternice. Conceptul de „lucrare proprie” este unul foarte relativ; orice dezvoltator cu experiență poate acumula mii de linii de cod din vechile sale proiecte în prima sa comisie. Și va fi aceasta o dezvoltare pregătită dinainte? Dar, în orice caz, se aplică regula, pe care am exprimat-o sub forma unui meme celebru:
Pentru a câștiga, trebuie să ai ceva, un fel de avantaj competitiv: un proiect similar pe care l-ai făcut în trecut, cunoștințe și experiență într-un anumit subiect sau o muncă gata făcută înainte de începerea hackatonului. Da, nu este sportiv. Da, s-ar putea să nu merite efortul depus (aici, fiecare decide singur dacă merită să codifice timp de 3 săptămâni noaptea pentru un premiu de 100 de mii, împărțit între întreaga echipă și chiar cu riscul de a nu-l obține). Dar, de multe ori, aceasta este singura șansă de a merge înainte.
3. Selectarea echipei. După cum am observat în chat-urile de hackathon, mulți abordează această problemă destul de frivol (deși aceasta este cea mai importantă decizie care vă va determina rezultatul la hackathon). În multe domenii de activitate (atât în sport, cât și în hackathon-uri) am văzut că oamenii puternici tind să se unească cu cei puternici, cei slabi cu cei slabi, cei deștepți cu cei deștepți, ei bine, în general, înțelegi ideea... Cam așa se întâmplă în chat-uri: programatori mai puțin puternici sunt imediat atrași, oameni care nu au abilități valoroase pentru un hackathon stau mult timp în chat și aleg o echipă pe principiul că dacă ar accepta cineva. . La unele hackathon-uri se practică repartizarea aleatorie pe echipe, iar organizatorii susțin că echipele aleatoare nu au rezultate mai proaste decât cele existente. Dar, conform observațiilor mele, oamenii motivați, de regulă, își găsesc o echipă pe cont propriu; dacă cineva trebuie să fie desemnat, atunci, de multe ori, mulți dintre ei nu vin la hackathon.
În ceea ce privește componența echipei, aceasta este foarte individuală și foarte dependentă de sarcină. Aș putea spune că componența minimă viabilă a echipei este un designer - front-end sau front-end - back-end. Dar știu și cazuri în care au câștigat echipe formate doar din front-end, care au adăugat un simplu back-end în node.js sau au făcut o aplicație mobilă în React Native; sau numai de la backenders care au făcut layout simplu. În general, totul este foarte individual și depinde de sarcină. Planul meu pentru selectarea unei echipe pentru hackathon a fost următorul: am plănuit să adun o echipă sau să mă alătur unei echipe precum front-end - back-end - designer (eu sunt front-end). Și destul de repede am început să vorbesc cu un backender python și un designer care a acceptat invitația de a ni se alătura. Puțin mai târziu, ni s-a alăturat o fată, un analist de afaceri, care avea deja experiență în câștigarea unui hackathon, iar asta a hotărât problema ca ea să ni se alăture. După o scurtă întâlnire, am decis să ne numim U4 (URBAN 4, urban four) prin analogie cu cei patru fantastici. Și chiar au pus o poză corespunzătoare pe avatarul canalului nostru telegram.
4. Selectarea unei sarcini. După cum am spus deja, trebuie să aveți un avantaj competitiv, sarcina pentru hackathon este selectată pe baza acestui lucru. Pe baza acestui lucru, după ce m-am uitat și evaluând complexitatea acestora, ne-am stabilit pe două sarcini: un catalog de întreprinderi inovatoare de la DPiIR și un chatbot de la EFKO. Sarcina de la DPIiR a fost aleasă de backender, sarcina de la EFKO a fost aleasă de mine, deoarece a avut experiență în scrierea de chatbot-uri în node.js și DialogFlow. Sarcina EFKO a implicat și ML; am ceva, nu foarte vastă, experiență în ML. Și în funcție de condițiile problemei, mi s-a părut că este puțin probabil să fie rezolvată folosind instrumente ML. Acest sentiment s-a întărit când am fost la întâlnirea Urban Tech Challenge, unde organizatorii mi-au arătat un set de date pe EFKO, unde erau aproximativ 100 de fotografii cu machete de produse (luate din diferite unghiuri) și aproximativ 20 de clase de erori de layout. Și, în același timp, cei care au comandat sarcina și-au dorit să obțină o rată de succes în clasificare de 90%. Drept urmare, am pregătit o prezentare a soluției fără ML, backender-ul a pregătit o prezentare pe baza catalogului, iar împreună, după finalizarea prezentărilor, le-am trimis la Urban Tech Challenge. Deja în această etapă a fost dezvăluit nivelul de motivație și contribuția fiecărui participant. Designerul nostru nu a luat parte la discuții, a răspuns târziu și chiar a completat informații despre el în prezentare în ultimul moment, în general, au apărut îndoieli.
Drept urmare, am trecut sarcina de la DPiIR și nu am fost deloc supărați că nu am trecut de EFKO, deoarece sarcina ni s-a părut ciudată, ca să spunem ușor.
5. Pregătirea pentru hackathon. Când în sfârșit s-a știut că ne-am calificat pentru hackathon, am început să pregătim pregătirea. Și aici nu susțin începerea scrierii codului cu o săptămână înainte de începerea hackatonului. Cel puțin, ar trebui să aveți un boilerplate gata, cu care puteți începe imediat să lucrați, fără a fi nevoie să configurați instrumente și fără să dați peste bug-uri ale unor lib pe care ați decis să le încercați pentru prima dată la un hackathon. Știu o poveste despre inginerii angular care au venit la un hackathon și au petrecut 2 zile punând la punct construcția proiectului, așa că totul ar trebui să fie pregătit în avans. Am intenționat să distribuim responsabilitățile după cum urmează: backender-ul scrie crawler-uri care parcurg internetul și pun toate informațiile colectate în baza de date, în timp ce eu scriu un API în node.js care interogează această bază de date și trimite datele în față. În acest sens, am pregătit un server în avans folosind express.js și am pregătit un front-end în react. Nu folosesc CRA, personalizez întotdeauna webpack pentru mine și știu foarte bine ce riscuri poate prezenta (amintiți-vă povestea despre dezvoltatorii angular). În acest moment, am cerut modele de interfață sau cel puțin machete de la designerul nostru pentru a avea o idee despre ceea ce aș fi așezat. În teorie, ar trebui să-și facă și el singur pregătirile și să le coordoneze cu noi, dar nu am primit niciodată un răspuns. Drept urmare, am împrumutat designul de la unul dintre vechile mele proiecte. Și a început să funcționeze și mai repede, deoarece toate stilurile pentru acest proiect fuseseră deja scrise. De aici concluzia: un designer nu este întotdeauna necesar într-o echipă))). Am venit la hackathon cu aceste evoluții.
6. Lucrează la hackathon. Prima dată când mi-am văzut echipa live a fost abia la deschiderea hackatonului de la Centrul Central de Distribuție. Ne-am întâlnit, am discutat soluția și etapele de lucru asupra problemei. Și deși după deschidere a trebuit să mergem cu autobuzul până în Octombrie Roșu, am plecat acasă să dormim, acceptând să ajungem la locul până la ora 9.00. De ce? Se pare că organizatorii au vrut să profite la maximum de participanți, așa că au aranjat tocmai un astfel de program. Dar, din experiența mea, puteți codifica în mod normal fără a dormi o noapte. Cât despre al doilea, nu mai sunt sigur. Un hackathon este un maraton; trebuie să vă calculați și să vă planificați în mod adecvat puterea. Mai mult, am avut pregătiri.
Prin urmare, după ce ne-am culcat, la ora 9.00 stăteam la etajul șase al Dewocracy. Atunci designerul nostru a anunțat pe neașteptate că nu are laptop și că va lucra de acasă, iar noi vom comunica telefonic. Acesta a fost ultimul pahar. Și așa am trecut de la patru la trei, deși nu am schimbat numele echipei. Din nou, aceasta nu a fost o lovitură mare pentru noi; aveam deja designul din vechiul proiect. În general, la început totul a decurs destul de bine și conform planului. Am încărcat în baza de date (am decis să folosim neo4j) un set de date de companii inovatoare de la organizatori. Am început să compoziționez, apoi am preluat node.js, iar apoi lucrurile au început să nu se aprindă. Nu lucrasem niciodată cu neo4j înainte și la început am căutat un driver funcțional pentru această bază de date, apoi mi-am dat seama cum să scriu o interogare și apoi am fost surprins să descopăr că această bază de date, atunci când este interogată, returnează entități în forma unui tablou de obiecte nod și marginile acestora. Acestea. când am solicitat o organizație și toate datele de pe aceasta prin TIN, în loc de un obiect organizație, mi s-a returnat o gamă lungă de obiecte care conțineau date despre această organizație și relațiile dintre ele. Am scris un mapper care a trecut prin întreaga matrice și a lipit toate obiectele în funcție de organizarea lor într-un singur obiect. Dar în luptă, la solicitarea unei baze de date de 8 mii de organizații, s-a executat extrem de lent, aproximativ 20 - 30 de secunde. Am început să mă gândesc la optimizare... Și apoi ne-am oprit la timp și am trecut la MongoDB și ne-a luat cam 30 de minute. În total, pe neo4j s-au pierdut aproximativ 5 ore.
Amintiți-vă, nu duceți niciodată tehnologia la un hackathon cu care nu sunteți familiarizat, pot exista surprize. Dar, în general, în afară de acest eșec, totul a mers conform planului. Și deja în dimineața zilei de 9 decembrie, aveam o aplicație complet funcțională. Pentru restul zilei am plănuit să îi adăugăm funcții suplimentare. În viitor, totul a decurs relativ bine pentru mine, dar backender-ul a avut o grămadă de probleme cu interzicerea crawlerelor sale în motoarele de căutare, în spam-ul agregatorilor de persoane juridice, care a ajuns pe primele locuri în rezultatele căutării atunci când a solicitat. pentru fiecare companie anume. Dar este mai bine ca el să spună el însuși despre asta. Prima caracteristică suplimentară pe care am adăugat-o a fost căutarea după nume complet. Director general al VKontakte. A durat câteva ore.
Deci, pe pagina companiei din aplicația noastră, a apărut un avatar al directorului general, un link către pagina sa VKontakte și alte câteva date. A fost o cireșă drăguță pe tort, deși poate nu ne-a oferit câștigul. Apoi, am vrut să fac niște analize. Dar după o lungă căutare de opțiuni (au fost multe nuanțe cu UI), m-am hotărât pe cea mai simplă agregare a organizațiilor după codul de activitate economică. Deja seara, în ultimele ore, așezam un șablon pentru afișarea produselor inovatoare (în aplicația noastră ar trebui să existe o secțiune Produse și Servicii), deși backend-ul nu era pregătit pentru asta. În același timp, baza de date se umfla cu un pas, crawler-urile au continuat să lucreze, backender-ul a experimentat cu NLP pentru a distinge textele inovatoare de cele neinovatoare))). Dar timpul pentru prezentarea finală se apropia deja.
7. Prezentare. Din propria mea experiență, pot spune că ar trebui să treci la pregătirea unei prezentări cu aproximativ 3 până la 4 ore înainte de scadență. Mai ales dacă implică video, filmarea și editarea acestuia durează destul de mult. Trebuia să avem un videoclip. Și am avut o persoană specială care s-a ocupat de asta și a rezolvat și o serie de alte probleme organizaționale. În acest sens, nu ne-am distras de la codificare până în ultimul moment.
8. Pitch. Nu mi-a plăcut că prezentările și finalele au avut loc într-o zi a săptămânii separată (luni). Aici, cel mai probabil, a continuat politica organizatorilor de a strânge maximum de participanți. Nu aveam de gând să-mi iau concediu de la serviciu, voiam doar să vin în finală, deși restul echipei mele și-a luat ziua liberă. Cu toate acestea, imersiunea emoțională în hackathon era deja atât de mare încât la ora 8 am scris în chat-ul echipei mele (echipa de lucru, nu echipa de hackathon) că îmi iau ziua pe cheltuiala mea și am mers la centrală. birou pentru terenuri. Problema noastră s-a dovedit a avea o mulțime de oameni de știință de date pure, iar acest lucru a afectat foarte mult abordarea rezolvării problemei. Mulți aveau un DS bun, dar nimeni nu avea un prototip funcțional, mulți nu puteau ocoli interdicțiile crawlerelor lor în motoarele de căutare. Eram singura echipă cu un prototip funcțional. Și am știut să rezolvăm problema. Până la urmă, am câștigat pista, deși am fost foarte norocoși că am ales sarcina cea mai puțin competitivă. Privind terenurile din alte piste, ne-am dat seama că nu vom avea nicio șansă acolo. De asemenea, vreau să spun că am fost foarte norocoși cu juriul, ei au verificat meticulos codul. Și, judecând după recenzii, acest lucru nu s-a întâmplat în toate piesele.
9. Finală. După ce am fost chemați de mai multe ori în juriu pentru o revizuire a codului, noi, crezând că în sfârșit am rezolvat toate problemele, am mers să luăm prânzul la Burger King. Acolo organizatorii ne-au sunat din nou, a trebuit să ne împachetăm rapid comenzile și să ne întoarcem.
Organizatorul ne-a arătat în ce sală trebuie să intrăm și, la intrare, ne-am trezit la un antrenament de vorbire în public pentru echipele câștigătoare. Băieții care trebuiau să cânte pe scenă erau bine încărcați, toată lumea a ieșit ca adevărații showmen.
Și trebuie să recunosc, în finală, pe fundalul celor mai puternice echipe de pe alte piste, am părut palid; victoria în nominalizarea clienților guvernamentali i-a revenit destul de meritat echipei de la pista de tehnologie imobiliară. Cred că factorii cheie care au contribuit la victoria noastră pe pistă au fost: disponibilitatea unui semifabricat gata făcut, datorită căruia am putut realiza rapid un prototip, prezența „repere” în prototip (căutare directori executivi). pe rețelele de socializare) și abilitățile NLP ale backender-ului nostru, care au interesat foarte mult și juriul.
Și în încheiere, mulțumiri tradiționale tuturor celor care ne-au susținut, juriului piesei noastre, Evgeniy Evgrafiev (autorul problemei pe care am rezolvat-o la hackathon) și bineînțeles organizatorilor hackatonului. Acesta a fost poate cel mai mare și mai tare hackathon la care am participat vreodată, nu pot decât să le doresc băieților să păstreze un standard atât de înalt în viitor!
Sursa: www.habr.com