Emri im është Dmitry. Dhe unë dua të flas se si ekipi ynë arriti në finalet e hakatonit Urban Tech Challenge në pistën Big Data. Do të them menjëherë se ky nuk është hackathoni i parë në të cilin kam marrë pjesë, dhe jo i pari në të cilin kam marrë çmime. Në lidhje me këtë, në tregimin tim dua të shpreh disa vëzhgime dhe përfundime të përgjithshme në lidhje me industrinë e hackathon-it në tërësi dhe të jap këndvështrimin tim në krahasim me vlerësimet negative që u shfaqën në internet menjëherë pas përfundimit të Sfidës Urban Tech (për shembull ).
Pra, së pari disa vëzhgime të përgjithshme.
1. Është për t'u habitur që shumë njerëz mendojnë me naivitet se një hackathon është një lloj gare sportive ku fitojnë koduesit më të mirë. Kjo eshte e gabuar. Unë nuk i konsideroj rastet kur vetë organizatorët e hackathon nuk e dinë se çfarë duan (e kam parë edhe këtë). Por, si rregull, kompania që organizon një hackathon ndjek qëllimet e veta. Lista e tyre mund të jetë e ndryshme: mund të jetë një zgjidhje teknike për disa probleme, një kërkim për ide dhe njerëz të rinj, etj. Këto qëllime shpesh përcaktojnë formatin e ngjarjes, kohën e tij, online/offline, si do të formulohen detyrat (dhe nëse do të formulohen fare), nëse do të ketë një rishikim të kodit në hackathon, etj. Nga ky këndvështrim vlerësohen edhe skuadrat edhe ajo që bënë. Dhe fitojnë ato skuadra që arritën më së miri pikën që i duhet kompanisë, dhe shumë prej tyre arrijnë në këtë pikë krejtësisht pa vetëdije dhe rastësisht, duke menduar se po marrin pjesë vërtet në një garë sportive. Vëzhgimet e mia tregojnë se për të motivuar pjesëmarrësit, organizatorët duhet të krijojnë të paktën pamjen e një ambienti sportiv dhe kushte të barabarta, përndryshe do të marrin një valë negativiteti, si në rishikimin e mësipërm. Por ne largohemi.
2. Prandaj përfundimi i mëposhtëm. Organizatorët janë të interesuar që pjesëmarrësit të vijnë në hackathon me punën e tyre, ndonjëherë ata madje organizojnë posaçërisht një fazë korrespondence në internet për këtë qëllim. Kjo lejon zgjidhje më të forta të prodhimit. Koncepti i "punës së vet" është shumë relativ; çdo zhvillues me përvojë mund të grumbullojë mijëra rreshta kodi nga projektet e tij të vjetra në kryerjen e tij të parë. Dhe a do të jetë ky një zhvillim i parapërgatitur? Por në çdo rast vlen rregulli, të cilin e shpreha në formën e një meme të famshme:
Për të fituar, duhet të keni diçka, një lloj avantazhi konkurrues: një projekt të ngjashëm që keni bërë në të kaluarën, njohuri dhe përvojë në një temë specifike, ose një punë të gatshme të bërë para fillimit të hackathon. Po, nuk është sportive. Po, kjo mund të mos ia vlen përpjekja e shpenzuar (këtu, të gjithë vendosin vetë nëse ia vlen të kodoni për 3 javë gjatë natës për një çmim prej 100 mijë, të ndarë në të gjithë ekipin, madje edhe me rrezikun e mosmarrjes së tij). Por, shpesh, kjo është mundësia e vetme për të ecur përpara.
3. Zgjedhja e ekipit. Siç e vura re në bisedat hackathon, shumë e trajtojnë këtë çështje mjaft joserioze (edhe pse ky është vendimi më i rëndësishëm që do të përcaktojë rezultatin tuaj në hackathon). Në shumë fusha të aktivitetit (si në sport ashtu edhe në hackathon) kam parë që njerëzit e fortë priren të bashkohen me të fortët, të dobëtit me të dobëtit, të zgjuarit me të zgjuarit, mirë, në përgjithësi, ju e kuptoni... Kjo është përafërsisht ajo që ndodh në biseda: programues më pak të fortë ata këputen menjëherë, njerëz që nuk kanë ndonjë aftësi të vlefshme për një hackathon qëndrojnë në chat për një kohë të gjatë dhe zgjedhin një ekip me parimin që nëse dikush do ta merrte atë. . Në disa hackathone, praktikohet caktimi i rastësishëm në ekipe dhe organizatorët pretendojnë se ekipet e rastësishme nuk performojnë më keq se ato ekzistuese. Por sipas vëzhgimeve të mia, njerëzit e motivuar, si rregull, gjejnë një ekip më vete; nëse dikush duhet të caktohet, atëherë, shpesh, shumë prej tyre nuk vijnë në hackathon.
Sa i përket përbërjes së ekipit, kjo është shumë individuale dhe varet shumë nga detyra. Mund të them se përbërja minimale e mundshme e ekipit është një projektues - front-end ose front-end - back-end. Por di edhe raste kur fituan skuadra të përbëra vetëm nga front-ender, të cilët shtuan një back-end të thjeshtë në node.js, ose bënë një aplikacion celular në React Native; ose vetëm nga backenders që kanë bërë layout të thjeshtë. Në përgjithësi, gjithçka është shumë individuale dhe varet nga detyra. Plani im për zgjedhjen e një ekipi për hackathon ishte si vijon: Kam planifikuar të mbledh një ekip ose të bashkohem me një ekip si front-end - back-end - designer (unë jam vetë një front-end). Dhe shumë shpejt fillova të bisedoj me një mbështetës python dhe një stilist që pranoi ftesën për t'u bashkuar me ne. Pak më vonë, një vajzë, një analiste biznesi, e cila tashmë kishte përvojë në fitimin e një hackathon, na u bashkua dhe kjo vendosi çështjen e bashkimit të saj me ne. Pas një takimi të shkurtër, vendosëm ta quanim veten U4 (URBAN 4, urban katër) në analogji me katër fantastike. Dhe ata madje vendosën një fotografi përkatëse në avatarin e kanalit tonë telegram.
4. Përzgjedhja e një detyre. Siç thashë tashmë, ju duhet të keni një avantazh konkurrues, detyra për hackathon zgjidhet në bazë të kësaj. Bazuar në këtë, duke parë dhe duke vlerësuar kompleksitetin e tyre, ne u vendosëm në dy detyra: një katalog të ndërmarrjeve inovative nga DPiIR dhe një chatbot nga EFKO. Detyrën nga DPIiR e zgjodhi backenderi, detyrën nga EFKO e zgjodha unë, sepse kishte përvojë në shkrimin e chatbots në node.js dhe DialogFlow. Detyra e EFKO-s përfshinte edhe ML; unë kam një përvojë, jo shumë të gjerë, në ML. Dhe sipas kushteve të problemit, më dukej se nuk kishte gjasa të zgjidhej duke përdorur mjetet ML. Kjo ndjenjë u forcua kur shkova në takimin Urban Tech Challenge, ku organizatorët më treguan një grup të dhënash në EFKO, ku kishte rreth 100 foto të paraqitjeve të produkteve (të marra nga këndvështrime të ndryshme) dhe rreth 20 klasa gabimesh në paraqitje. Dhe, në të njëjtën kohë, ata që urdhëruan detyrën donin të arrinin një shkallë suksesi të klasifikimit prej 90%. Si rezultat, përgatita një prezantim të zgjidhjes pa ML, backender përgatiti një prezantim të bazuar në katalog dhe së bashku, pas finalizimit të prezantimeve, i dërguam ato në Urban Tech Challenge. Tashmë në këtë fazë u zbulua niveli i motivimit dhe kontributit të secilit pjesëmarrës. Projektuesi ynë nuk mori pjesë në diskutime, u përgjigj me vonesë dhe madje plotësoi informacione për veten e tij në prezantim në momentin e fundit, në përgjithësi, lindën dyshime.
Si rezultat, ne e kaluam detyrën nga DPiIR dhe nuk u mërzitëm aspak që nuk e kaluam EFKO-në, pasi detyra na dukej e çuditshme, për ta thënë më butë.
5. Përgatitja për hackathon. Kur më në fund u bë e ditur se ishim kualifikuar për hackathon, filluam të përgatisim përgatitjen. Dhe këtu nuk jam duke mbrojtur fillimin e shkrimit të kodit një javë para fillimit të hackathon. Së paku, duhet të keni gati një pllakë kazan, me të cilën mund të filloni menjëherë të punoni, pa pasur nevojë të konfiguroni mjetet dhe pa u përplasur me defektet e disa libeve që keni vendosur të provoni për herë të parë në një hackathon. Unë di një histori për inxhinierët këndorë që erdhën në një hackathon dhe kaluan 2 ditë duke vendosur ndërtimin e projektit, kështu që gjithçka duhet të përgatitet paraprakisht. Ne synuam të shpërndajmë përgjegjësitë si më poshtë: backender shkruan crawlers që pastrojnë internetin dhe vendosin të gjithë informacionin e mbledhur në bazën e të dhënave, ndërsa unë shkruaj një API në node.js që kërkon këtë bazë të dhënash dhe i dërgon të dhënat në pjesën e përparme. Në këtë drejtim, përgatita një server paraprakisht duke përdorur express.js dhe përgatita një front-end në react. Unë nuk përdor CRA, personalizoj gjithmonë paketën e uebit për veten time dhe e di shumë mirë se çfarë rreziqesh mund të sjellë kjo (mbani mend historinë për zhvilluesit këndorë). Në këtë pikë, kërkova shabllone ndërfaqeje ose të paktën modele nga projektuesi ynë në mënyrë që të kisha një ide se çfarë do të shtroja. Teorikisht edhe ai duhet të bëjë përgatitjet e veta dhe t'i koordinojë me ne, por nuk kam marrë kurrë përgjigje. Si rezultat, huazova dizajnin nga një nga projektet e mia të vjetra. Dhe filloi të funksionojë edhe më shpejt, pasi të gjitha stilet për këtë projekt ishin shkruar tashmë. Prandaj përfundimi: një projektues nuk është gjithmonë i nevojshëm në një ekip))). Ne erdhëm në hackathon me këto zhvillime.
6. Punoni në hackathon. Hera e parë që pashë ekipin tim live ishte vetëm në hapjen e hackathon-it në Qendrën Qendrore të Shpërndarjes. U takuam, diskutuam zgjidhjen dhe fazat e punës për problemin. Dhe megjithëse pas hapjes duhej të shkonim me autobus për në Tetorin e Kuq, shkuam në shtëpi për të fjetur, duke rënë dakord të mbërrinim në vend deri në orën 9.00. Pse? Organizatorët me sa duket donin të përfitonin sa më shumë nga pjesëmarrësit, ndaj organizuan një orar të tillë. Por, në përvojën time, ju mund të kodoni normalisht pa fjetur për një natë. Sa i përket të dytës, nuk jam më i sigurt. Një hackathon është një maratonë; ju duhet të llogaritni dhe planifikoni në mënyrë adekuate forcën tuaj. Për më tepër, ne kishim përgatitje.
Prandaj, pasi fjetëm, në orën 9.00 ishim ulur në katin e gjashtë të Dewocracy. Më pas dizenjatori ynë lajmëroi papritur se nuk kishte laptop dhe se do të punonte nga shtëpia dhe ne do të komunikonim me telefon. Kjo ishte pika e fundit. Dhe kështu u kthyem nga katër në tre, megjithëse nuk e ndryshuam emrin e ekipit. Përsëri, kjo nuk ishte një goditje e madhe për ne; unë kisha tashmë dizajnin nga projekti i vjetër. Në përgjithësi, në fillim gjithçka shkoi mjaft mirë dhe sipas planit. Ne ngarkuam në bazën e të dhënave (vendosëm të përdorim neo4j) një grup të dhënash kompanish inovative nga organizatorët. Fillova të shtypja, më pas mora node.js, dhe më pas gjërat filluan të mos funksiononin. Unë kurrë nuk kisha punuar me neo4j më parë, dhe në fillim po kërkoja një drejtues pune për këtë bazë të dhënash, më pas kuptova se si të shkruaj një pyetje dhe më pas u befasova kur zbulova se kjo bazë të dhënash, kur pyetet, kthen entitete në forma e një grupi objektesh nyjesh dhe skajet e tyre. Ato. kur kërkova një organizatë dhe të gjitha të dhënat mbi të nga TIN, në vend të një objekti organizate, m'u kthye një grup i gjatë objektesh që përmbanin të dhëna për këtë organizatë dhe marrëdhëniet midis tyre. Shkrova një hartë që kaloi nëpër të gjithë grupin dhe ngjiti të gjitha objektet sipas organizimit të tyre në një objekt. Por në betejë, kur kërkohej një bazë të dhënash prej 8 mijë organizatash, ajo u ekzekutua jashtëzakonisht ngadalë, rreth 20 - 30 sekonda. Fillova të mendoj për optimizimin... Dhe më pas u ndalëm në kohë dhe kaluam në MongoDB, dhe na u deshën rreth 30 minuta. Në total, rreth 4 orë humbën në neo5j.
Mos harroni, kurrë mos e çoni teknologjinë në një hackathon me të cilin nuk jeni njohur, mund të ketë surpriza. Por, në përgjithësi, përveç këtij dështimi, gjithçka shkoi sipas planit. Dhe tashmë në mëngjesin e 9 dhjetorit, ne patëm një aplikim plotësisht funksional. Për pjesën tjetër të ditës kemi planifikuar t'i shtojmë veçori shtesë. Në të ardhmen, gjithçka shkoi relativisht mirë për mua, por backender kishte një mori problemesh me ndalimin e zvarritësve të tij në motorët e kërkimit, në spam-in e grumbulluesve të personave juridikë, të cilët vinin në vendet e para të rezultateve të kërkimit kur kërkonin për çdo kompani specifike. Por është më mirë që ai të tregojë për këtë vetë. Tipari i parë shtesë që shtova ishte kërkimi me emrin e plotë. Drejtori i Përgjithshëm i VKontakte. U deshën disa orë.
Pra, në faqen e kompanisë në aplikacionin tonë, u shfaq një avatar i drejtorit të përgjithshëm, një lidhje në faqen e tij VKontakte dhe disa të dhëna të tjera. Ishte një qershi e bukur mbi tortë, megjithëse mund të mos na kishte dhënë fitoren. Pastaj, doja të drejtoja disa analitikë. Por pas një kërkimi të gjatë opsionesh (kishte shumë nuanca me UI), u vendosa në grumbullimin më të thjeshtë të organizatave sipas kodit të aktivitetit ekonomik. Tashmë në mbrëmje, në orët e fundit, po shtroja një shabllon për shfaqjen e produkteve inovative (në aplikacionin tonë supozohet të ketë një seksion Produkte dhe Shërbime), megjithëse backend nuk ishte gati për këtë. Në të njëjtën kohë, baza e të dhënave po fryhej me hapa të mëdhenj, zvarritësit vazhduan të punojnë, mbështetësi eksperimentoi me NLP për të dalluar tekstet novatore nga ato jo-inovative))). Por koha e prezantimit përfundimtar tashmë po afrohej.
7. Prezantimi. Nga përvoja ime, mund të them se duhet të kaloni në përgatitjen e një prezantimi rreth 3 deri në 4 orë përpara se të mbarojë. Sidomos nëse përfshin video, xhirimi dhe redaktimi i tij kërkon mjaft kohë. Ne duhej të kishim një video. Dhe ne kishim një person të veçantë që merrej me këtë, dhe gjithashtu zgjidhte një sërë çështjesh të tjera organizative. Në këtë drejtim, ne nuk e shpërqendruam veten nga kodimi deri në momentin e fundit.
8. Katrani. Nuk më pëlqeu që prezantimet dhe finalet u mbajtën në një ditë të veçantë jave (e hënë). Këtu, ka shumë të ngjarë, politika e organizatorëve për të shtrydhur maksimumin nga pjesëmarrësit vazhdoi. Nuk kisha në plan të merrja pushim nga puna, doja vetëm të vija në finale, megjithëse pjesa tjetër e ekipit tim e mori ditën e pushimit. Sidoqoftë, zhytja emocionale në hackathon ishte tashmë aq e lartë sa në orën 8 të mëngjesit shkrova në bisedën e ekipit tim (ekipit të punës, jo ekipit të hackathon) se po e merrja ditën me shpenzimet e mia dhe shkova në qendrën zyre per terrene. Problemi ynë doli të kishte shumë shkencëtarë të të dhënave të pastra, dhe kjo ndikoi shumë në qasjen për zgjidhjen e problemit. Shumë kishin një DS të mirë, por askush nuk kishte një prototip funksional, shumë nuk mund të kapërcenin ndalimet e zvarritësve të tyre në motorët e kërkimit. Ne ishim ekipi i vetëm me një prototip pune. Dhe ne dinim si ta zgjidhnim problemin. Në fund fituam pistën, megjithëse patëm shumë fat që zgjodhëm detyrën më pak konkurruese. Duke parë fushat në pista të tjera, kuptuam se nuk do të kishim asnjë shans atje. Dua të them gjithashtu se ishim shumë me fat me jurinë, ata kontrolluan me përpikëri kodin. Dhe, duke gjykuar nga vlerësimet, kjo nuk ndodhi në të gjitha pistat.
9. Final. Pasi u thirrëm disa herë në juri për një rishikim të kodit, ne, duke menduar se më në fund i kishim zgjidhur të gjitha çështjet, shkuam për të ngrënë drekë në Burger King. Aty na thirrën përsëri organizatorët, duhej të paketonim shpejt porositë dhe të ktheheshim.
Organizatori na tregoi se në cilën dhomë duhej të futeshim, dhe me të hyrë, u gjendëm në një seancë stërvitore të fjalimit publik për ekipet fituese. Djemtë që duhej të performonin në skenë ishin të ngarkuar mirë, të gjithë dolën si showmen të vërtetë.
Dhe duhet të pranoj, në finale, në sfondin e skuadrave më të forta nga pistat e tjera, ne dukeshim të zbehtë; fitorja në nominimin e klientëve të qeverisë i shkoi me mjaft meritë ekipit nga pista e teknologjisë së pasurive të paluajtshme. Unë mendoj se faktorët kryesorë që kontribuan në fitoren tonë në pistë ishin: disponueshmëria e një boshe të gatshme, për shkak të së cilës ne ishim në gjendje të bënim shpejt një prototip, prania e "pikëve kryesore" në prototip (kërkimi për CEO në rrjetet sociale) dhe aftësitë NLP të mbështetësit tonë, të cilat gjithashtu i interesuan shumë jurisë.
Dhe në përfundim, falënderim tradicional për të gjithë ata që na mbështetën, jurinë e pistës sonë, Evgeniy Evgrafiev (autori i problemit që zgjidhëm në hackathon) dhe sigurisht organizatorët e hackathon. Ky ishte ndoshta hackathoni më i madh dhe më i lezetshëm në të cilin kam marrë pjesë, vetëm mund t'u uroj djemve që të mbajnë një standard kaq të lartë në të ardhmen!
Burimi: www.habr.com