Nire izena Dmitry da. Eta gure taldea Big Data pistako Urban Tech Challenge hackatonaren finalera nola iritsi den hitz egin nahi dut. Berehala esango dut hau ez dela parte hartu dudan lehen hackatona, eta ez sariak hartu ditudan lehenengoa. Zentzu honetan, nire istorioan hackaton industria osoari buruzko behaketa eta ondorio orokor batzuk adierazi nahi ditut eta Urban Tech Challenge-a amaitu eta berehala sarean agertu ziren kritika negatiboen aurrean nire ikuspuntua eman adibidea ).
Beraz, lehenengo behaketa orokor batzuk.
1. Harritzekoa da jende askok inozoki pentsatzea hackaton bat kirol-lehiaketa bat dela, non kodetzaile onenek irabazten duten. Hau gaizki dago. Ez ditut kontuan hartzen hackaton antolatzaileek beraiek zer nahi duten ez dakiten kasuak (hori ere ikusi dut). Baina, oro har, hackaton bat antolatzen duen enpresak bere helburuak jarraitzen ditu. Haien zerrenda ezberdina izan daiteke: arazo batzuen irtenbide teknikoa izan daiteke, ideia eta pertsona berrien bilaketa, etab. Helburu horiek sarritan zehazten dute ekitaldiaren formatua, denbora, linean/offlinean, zereginak nola formulatuko diren (eta formulatuko diren ala ez), hackatoian kode berrikuspena egingo den, etab. Ikuspegi horretatik baloratzen dira bai taldeak, bai egindakoa. Eta konpainiak behar duen puntua ondoen lortzen duten talde horiek irabazten dute, eta askok erabat inkontzienteki eta ustekabean iristen dira horretara, benetan kirol lehiaketa batean parte hartzen ari direla pentsatuz. Nire behaketek erakusten dute parte hartzaileak motibatzeko, antolatzaileek gutxienez kirol-ingurunearen itxura eta baldintza berdinak sortu beharko lituzketela, bestela negatibotasun olatua jasoko dute, goiko berrikuspenean bezala. Baina alde egiten dugu.
2. Hortik hurrengo ondorioa. Antolatzaileek interesa dute parte hartzaileak hackatonera euren lanekin etortzea, batzuetan sareko korrespondentzia etapa bat ere antolatzen dute horretarako. Horrek irteera irtenbide sendoagoak ahalbidetzen ditu. "Bere lana" kontzeptua oso erlatiboa da; esperientziadun edozein garatzailek bere proiektu zaharretako milaka kode lerro pila ditzake bere lehen konpromisoan. Eta hori aldez aurretik prestatutako garapena izango al da? Baina, nolanahi ere, araua aplikatzen da, meme ospetsu baten moduan adierazi nuena:
Irabazteko, zerbait izan behar da, nolabaiteko abantaila lehiakorra: iraganean egin zenuen antzeko proiektu bat, gai zehatz batean ezagutza eta esperientzia, edo hackatona hasi aurretik egindako lan bat. Bai, ez da kirola. Bai, baliteke horrek ez du mereziko egindako esfortzuak (hemen bakoitzak bere kabuz erabakitzen du gauez 3 astez kodetzea merezi duen 100 milako saria, talde osoaren artean banatuta, eta ez lortzeko arriskuarekin ere). Baina, askotan, hau da aurrera ateratzeko aukera bakarra.
3. Taldeen hautaketa. Hackathoneko txatetan ohartu naizen bezala, askok gai honi nahiko arinki heltzen diote (nahiz eta hau den hackathoneko emaitza zehaztuko duen erabakirik garrantzitsuena). Jarduera-arlo askotan (kiroletan zein hackathonetan) ikusi dut pertsona indartsuak indartsuekin bat egiteko joera duela, ahulak ahulekin, adimentsuak smartekin, ba, orokorrean, ideia ulertzen duzu... Hau da, gutxi gorabehera, txatetan gertatzen dena: programatzaile ez hain indartsuak berehala lotzen dira, hackaton baterako balio handiko gaitasunik ez duten pertsonak denbora luzez txatean zintzilikatzen dira eta talde bat aukeratzen dute norbaitek hartuko balu. . Hackathon batzuetan, taldeen ausazko esleipena praktikatzen da, eta antolatzaileek diote ausazko taldeek ez dutela funtzionatzen lehendik daudenek baino okerrago. Baina nire behaketen arabera, pertsona motibatuak, oro har, talde bat aurkitzen du bere kabuz; norbait esleitu behar bada, askotan, horietako asko ez dira hackatonera etortzen.
Taldearen osaerari dagokionez, hau oso indibiduala da eta zereginaren oso menpekoa da. Esan nezake gutxieneko talde-osaketa bideragarria diseinatzailea dela - front-end edo front-end - back-end. Baina fronte-endarrek soilik osatutako taldeek irabazi zuten kasuak ere ezagutzen ditut, node.js-en back-end soil bat gehitu zutenek edo React Native-n mugikorretarako aplikazio bat egin zutenak; edo diseinu sinplea egin zuten backenders bakarrik. Oro har, dena oso indibiduala da eta zereginaren araberakoa da. Hackatonerako talde bat hautatzeko nire plana honakoa zen: Frontend - back-end - designer bezalako talde bat muntatzea edo talde batean sartzeko asmoa nuen (ni neu frontend bat naiz). Eta nahiko azkar hasi nintzen python backender batekin eta gurekin sartzeko gonbidapena onartu zuen diseinatzaile batekin berriketan. Pixka bat geroago, neska bat, negozio-analista, hackaton bat irabazteko esperientzia zuena, batu zitzaigun, eta honek erabaki zuen gurekin bat egitearen gaia. Bilera labur baten ostean, gure buruari U4 (URBAN 4, urban four) deitzea erabaki genuen lau fantastikoen analogia eginez. Eta dagokion argazkia ere jarri dute gure telegram kanalaren avatarean.
4. Zeregin bat hautatzea. Esan dudan bezala, abantaila lehiakorra izan behar duzu, hackatonaren zeregina hautatzen da. Horretan oinarrituta, begiratuta eta haien konplexutasuna ebaluatuz, bi zereginetan finkatu ginen: DPiIRren enpresa berritzaileen katalogoa eta EFKOren chatbot bat. DPIiR-eko zeregina backender-ak aukeratu zuen, EFKOko zeregina nik aukeratu nuen, izan ere esperientzia izan zuen node.js eta DialogFlow-en chatbot-ak idazten. EFKO zereginak ML ere hartzen zuen parte; esperientzia pixka bat, ez oso zabala, ML-n dut. Eta arazoaren baldintzen arabera, ML tresnak erabiliz nekez konponduko zela iruditzen zitzaidan. Sentsazio hori indartu egin zen Urban Tech Challenge topagunera joan nintzenean, non antolatzaileek EFKOri buruzko datu-multzo bat erakutsi zidaten, non produktuen diseinuen 100 argazki inguru zeuden (angelu ezberdinetatik hartutakoak) eta diseinu-akatsen 20 klase inguru zeuden. Eta, aldi berean, zeregina agindu zutenek %90eko sailkapeneko arrakasta-tasa lortu nahi zuten. Ondorioz, MLrik gabeko soluzioaren aurkezpena prestatu nuen, backender-ak aurkezpen bat prestatu zuen katalogoan oinarrituta, eta elkarrekin, aurkezpenak amaitu ondoren, Urban Tech Challengera bidali genituen. Jada fase honetan, parte hartzaile bakoitzaren motibazio eta ekarpen maila agerian geratu zen. Gure diseinatzaileak ez zuen eztabaidetan parte hartu, berandu erantzun zuen eta azken momentuan bere buruari buruzko informazioa ere bete zuen aurkezpenean, oro har, zalantzak sortu ziren.
Ondorioz, DPiIR-tik pasatu genuen zeregina, eta ez ginen batere atsekabetu EFKO gainditu ez izanak, zeregina arraroa iruditu zitzaigun eta, arin esateko.
5. Hackatona prestatzen. Azkenean hackatoirako sailkatu ginela jakin zenean, prestaketa prestatzen hasi ginen. Eta hemen ez dut hackatona hasi baino astebete lehenago kodea idazten hastea defendatzen. Gutxienez, boilerplate bat prest izan beharko zenuke, eta horrekin berehala lanean has zaitezke, tresnak konfiguratu beharrik gabe eta hackaton batean lehen aldiz probatzea erabaki zenuen lib baten akatsekin topo egin gabe. Badakit hackaton batera etorri eta 2 egun eman zituzten ingeniari angelutsuei buruzko istorio bat, proiektua eraikitzen, beraz, dena aldez aurretik prestatu behar da. Erantzukizunak honela banatzeko asmoa genuen: backendetzaileak Internet arakatzen duten arakatzaileak idazten ditu eta bildutako informazio guztia datu-basean jartzen du, nik, berriz, node.js-en API bat idazten du datu-base hau kontsultatzen eta datuak aurrealdera bidaltzen dituena. Zentzu honetan, aldez aurretik zerbitzari bat prestatu nuen express.js erabiliz eta front-end bat prestatu nuen react-en. Ez dut CRA erabiltzen, beti pertsonalizatzen dut webpack niretzat eta oso ondo dakit horrek zer arrisku ekar ditzakeen (gogoratu angeluar garatzaileei buruzko istorioa). Une honetan, interfaze-txantiloiak edo gutxienez maketak eskatu nizkion gure diseinatzaileari, ezarriko nuenaren ideia bat izateko. Teorian, berak ere bere prestaketak egin beharko lituzke eta gurekin koordinatu, baina ez nuen inoiz erantzunik jaso. Ondorioz, nire proiektu zahar batetik diseinua maileguan hartu nuen. Eta are azkarrago hasi zen lantzen, proiektu honetarako estilo guztiak idatzita zeudelako. Hortik ondorioa: diseinatzaile bat ez da beti behar talde batean))). Garapen hauekin etorri gara hackatonera.
6. Hackathonean lan egin. Nire taldea zuzenean ikusi nuen lehen aldia Banaketa Zentro Zentroko hackatonaren irekieran izan zen. Elkartu ginen, arazoa lantzeko irtenbidea eta faseak eztabaidatu genituen. Eta inaugurazioaren ostean Urri Gorrira autobusez joan behar izan genuen arren, etxera joan ginen lo egitera, 9.00etarako tokira iristea adostuz. Zergatik? Antolatzaileek antza denez, parte-hartzaileei etekinik handiena atera nahi izan diete, beraz, ordutegi hori antolatu dute. Baina, nire esperientziaren arabera, normalean kodetu dezakezu gau batez lo egin gabe. Bigarrenari dagokionez, jada ez nago ziur. Hackathon bat maratoia da; behar bezala kalkulatu eta planifikatu behar duzu zure indarra. Gainera, prestaketak egin genituen.
Hori dela eta, lo egin ondoren, 9.00etan Dewocracyko seigarren solairuan eserita geunden. Orduan gure diseinatzaileak ustekabean iragarri zuen ez zuela ordenagailu eramangarririk eta etxetik lan egingo zuela, eta telefonoz komunikatuko ginela. Hau izan zen azken lastoa. Eta horrela, lautik hirura pasatu ginen, taldearen izena aldatu ez genuen arren. Berriz ere, hau ez zen kolpe handia izan guretzat; lehendik nuen proiektu zaharreko diseinua. Oro har, hasieran dena nahiko ondo joan zen eta planaren arabera. Datu-basean kargatu genuen (neo4j erabiltzea erabaki genuen) antolatzaileen enpresa berritzaileen datu multzoa. Konposatzen hasi nintzen, gero node.js hartu nuen, eta gero gauzak gaizki hasi ziren. Ez nuen inoiz neo4j-rekin lan egin, eta hasieran datu-base honetarako funtzionatzen duen kontrolatzaile baten bila nenbilen, gero kontsulta bat nola idatzi asmatu nuen, eta orduan harritu egin nintzen datu-base honek, kontsultatzean, entitateak itzultzen dituela. Nodo-objektuen eta haien ertzen multzo baten forma. Horiek. Erakunde bat eta haren datu guztiak TIN-k eskatu nituenean, erakundearen objektu baten ordez, erakunde honi eta haien arteko erlazioei buruzko datuak dituzten objektu sorta luze bat itzuli zidaten. Mapper bat idatzi nuen, array osoa zeharkatu eta objektu guztiak objektu bakarrean itsatsi zituen bere antolaketaren arabera. Baina guduan, 8 erakundeko datu-basea eskatzean, oso poliki exekutatu zen, 20-30 segundo inguru. Optimizazioan pentsatzen hasi nintzen... Eta orduan gelditu ginen eta MongoDBra aldatu ginen, eta 30 bat minutu behar izan genituen. Guztira, 4 ordu inguru galdu ziren neo5j-en.
Gogoratu, inoiz ez eraman teknologia ezagutzen ez duzun hackaton batera, sorpresak egon daitezkeela. Baina, oro har, porrot honetaz gain, dena aurreikusitakoaren arabera joan zen. Eta jada abenduaren 9ko goizean, guztiz funtzionatzen duen aplikazioa genuen. Gainontzeko egunean eginbide gehigarriak gehitzea aurreikusi genuen. Etorkizunean, dena nahiko ondo joan zitzaidan, baina backender-ak arazo mordoa izan zituen bilatzaileetan bere arakatzaileak debekatzearekin, pertsona juridikoen agregatzaileen spamarekin, bilaketa-emaitzen lehen lekuetan zetorren eskaera egiterakoan. enpresa zehatz bakoitzarentzat. Baina hobe da berak kontatzea. Gehitu dudan lehen funtzio gehigarria izen osoaren arabera bilaketa izan da. VKontakteko zuzendari nagusia. Hainbat ordu behar izan zituen.
Beraz, gure aplikazioko konpainiaren orrian, zuzendari nagusiaren avatar bat agertu zen, bere VKontakte orrialderako esteka eta beste datu batzuk. Opilaren gerezi polita izan zen, nahiz eta agian ez zigun garaipenik eman. Orduan, analitika batzuk egin nahi nituen. Baina aukeren bilaketa luze baten ondoren (interfazearekin Γ±abardura asko zeuden), jarduera ekonomikoaren kodearen arabera erakundeen agregaziorik errazenean finkatu nintzen. Dagoeneko arratsaldean, azken orduetan, produktu berritzaileak erakusteko txantiloi bat jartzen ari nintzen (gure aplikazioan Produktu eta Zerbitzuen atala egon behar da), nahiz eta backend-a horretarako prest ez zegoen. Aldi berean, datu-basea jauzika hazten ari zen, arakatzaileek lanean jarraitu zuten, backender-ek NLPrekin esperimentatu zuen testu berritzaileak ez-berritzaileetatik bereizteko))). Baina azken aurkezpenaren ordua hurbiltzen ari zen jada.
7. Aurkezpena. Nire esperientziaren arabera, esan dezaket aurkezpen bat prestatzera pasatu behar duzula 3-4 ordu lehenago. Batez ere bideoa badakar, bere grabaketak eta edizioak denbora asko behar du. Bideo bat eduki behar genuen. Eta horretaz arduratu zen pertsona berezi bat genuen, eta antolakuntzako beste hainbat arazo ere konpondu zituen. Ildo horretatik, ez genuen kodetzetik azken unera arte desbideratu.
8. Zelaia. Ez zitzaidan gustatu aurkezpenak eta finalak astegun batean (astelehena) egitea. Hemen, ziurrenik, antolatzaileen parte-hartzaileei ahalik eta gehien estutzeko politikak jarraitu zuen. Ez nuen lanetik atsedenaldirik hartzeko asmorik, finalerdietara bakarrik etorri nahi nuen, nahiz eta nire gainerako taldeek atseden hartu zuten. Hala ere, hackaton-en murgiltze emozionala hain handia zen jada ezen goizeko 8etan nire taldeko txatean idatzi nuen (lan-taldea, ez hackaton-taldea) eguna nire kontura hartzen ari nintzela, eta zentralera joan nintzen. zelaietarako bulegoa. Gure arazoa datu-zientzialari huts asko izan zen, eta horrek asko eragin zuen arazoa konpontzeko ikuspegian. Askok DS ona zeukaten, baina inork ez zuen prototiporik funtzionatzen zuen, askok ezin zituzten beren arakatzaileen debekuei aurre egin bilatzaileetan. Prototipo funtzionatzen zuen talde bakarra ginen. Eta arazoa konpontzen jakin genuen. Azkenean, pista irabazi genuen, nahiz eta suerte handia izan genuen lehia gutxien zuen zeregina aukeratzeko. Beste pista batzuetako zelaiak ikusita, hor aukerarik ez genuela izango konturatu ginen. Esan nahi dut, halaber, zorte handia izan dugula epaimahaiarekin;zehazki egiaztatu zuten kodea. Eta, iritziak ikusita, hori ez zen bide guztietan gertatu.
9. Finala. Kode berrikusteko epaimahaiari hainbat aldiz deitu gintuzten ondoren, azkenean arazo guztiak konponduta genituela pentsatuta, Burger King-era bazkaltzera joan ginen. Bertan antolatzaileek berriro deitu ziguten, azkar egin behar izan genituen eskaerak eta bueltatu.
Antolatzaileak zein aretotara sartu behar ginen erakutsi zigun, eta sartzean, talde irabazleen jendaurrean hitz egiteko entrenamendu batean topatu ginen. Oholtza gainean aritu behar ziren mutilak ondo kargatuta zeuden, denak benetako showmen bezala atera ziren.
Eta aitortu behar dut, finalean, beste pista batzuetako talde indartsuenen atzealdean, zurbil ikusten ginela; gobernuko bezeroen izendapenaren garaipena merezimendu osoz lortu zuen higiezinen pistako taldearentzat. Uste dut pistan gure garaipenari lagundu dioten faktore nagusiak hauek izan direla: prest egindako hutsune baten erabilgarritasuna, horren ondorioz prototipo bat azkar egin ahal izan dugu, prototipoan "aipagarrien" presentzia (zuzendari nagusiak bilatu sare sozialetan) eta gure backender-en NLP gaitasunak, epaimahaiari ere asko interesatzen zitzaizkionak.
Eta amaitzeko, eskerrak tradizionalak lagundu gaituzten guztiei, gure ibilbidearen epaimahaiari, Evgeniy Evgrafiev (hackaton konpondu genuen arazoaren egilea) eta, jakina, hackaton-aren antolatzaileei. Inoiz parte hartu dudan hackathonik handiena eta politena izan zen, agian, mutilei etorkizunean maila altua mantentzea soilik opa diet!
Iturria: www.habr.com