Mia nomo estas Dmitry. Kaj mi volas paroli pri kiel nia teamo atingis la finalon de la Urban Tech Challenge hackathon sur la Big Data-trako. Mi tuj diros, ke ĉi tio ne estas la unua hakatono, en kiu mi partoprenis, kaj ne la unua, en kiu mi ricevis premiojn. Ĉi-rilate, en mia rakonto mi volas esprimi kelkajn ĝeneralajn observojn kaj konkludojn pri la hakatonindustrio entute, kaj doni mian vidpunkton kontraste al la negativaj recenzoj kiuj aperis interrete tuj post la fino de la Urban Tech Challenge (por ekzemplo ).
Do unue iuj ĝeneralaj observoj.
1. Estas surprize, ke sufiĉe multaj homoj naive pensas, ke hakatono estas ia sporta konkurso, kie venkas la plej bonaj kodistoj. Ĉi tio estas malĝusta. Mi ne konsideras kazojn, kiam hakatonorganizantoj mem ne scias, kion ili volas (tion ankaŭ mi vidis). Sed, kiel regulo, la kompanio, kiu organizas hakatonon, persekutas siajn proprajn celojn. Ilia listo povas esti malsama: ĝi povus esti teknika solvo de iuj problemoj, serĉo de novaj ideoj kaj homoj, ktp. Ĉi tiuj celoj ofte determinas la formaton de la evento, ĝian tempon, interrete/senrete, kiel la taskoj estos formulitaj (kaj ĉu ili entute estos formulitaj), ĉu estos koda revizio ĉe la hakatono, ktp. Kaj la teamoj kaj tio, kion ili faris, estas taksataj el ĉi tiu vidpunkto. Kaj tiuj teamoj, kiuj plej bone trafas la punkton, kiun la kompanio bezonas, venkas, kaj multaj atingas ĉi tiun punkton tute senkonscie kaj hazarde, pensante, ke ili vere partoprenas sportan konkurson. Miaj observoj montras, ke por instigi partoprenantojn, organizantoj devus krei almenaŭ aspekton de sporta medio kaj egalaj kondiĉoj, alie ili ricevos ondon de negativeco, kiel en la supra recenzo. Sed ni digresas.
2. Tial la sekva konkludo. La organizantoj interesiĝas, ke partoprenantoj venos al la hakatono kun sia propra laboro, foje ili eĉ speciale organizas retan korespondan stadion tiucele. Ĉi tio permesas pli fortajn produktaĵsolvojn. La koncepto de "propra laboro" estas tre relativa; ĉiu sperta programisto povas amasigi milojn da linioj de kodo de siaj malnovaj projektoj en sia unua kompromiso. Kaj ĉu ĉi tio estos antaŭpreparita evoluo? Sed ĉiukaze validas la regulo, kiun mi esprimis en formo de fama memeo:
Por gajni, vi devas havi ion, ian konkurencivan avantaĝon: similan projekton, kiun vi faris en la pasinteco, scion kaj sperton pri specifa temo, aŭ pretan laboron faritan antaŭ la komenco de la hakatono. Jes, ĝi ne estas sporta. Jes, ĉi tio eble ne valoras la penon elspezitan (ĉi tie, ĉiuj mem decidas ĉu indas kodi 3 semajnojn nokte por premio de 100 mil, dividita inter la tuta teamo, kaj eĉ kun la risko ne ricevi ĝin). Sed, ofte, ĉi tiu estas la sola ŝanco por antaŭeniri.
3. Teama elekto. Kiel mi rimarkis en hakatonaj babilejoj, multaj traktas ĉi tiun aferon sufiĉe frivole (kvankam ĉi tio estas la plej grava decido, kiu determinos vian rezulton ĉe la hakatono). En multaj agadkampoj (kaj en sporto kaj en hakatonoj) mi vidis, ke fortaj homoj emas kuniĝi kun la forta, la malforta kun la malforta, la inteligenta kun la inteligenta, nu, ĝenerale, oni komprenas la ideon... Ĉi tio estas proksimume kio okazas en babilejoj: malpli fortaj programistoj ili estas tuj kaptitaj, homoj kiuj ne havas ajnajn valorajn kapablojn por hakatono longe pendas en la babilejo kaj elektas teamon laŭ la principo, ke se nur iu prenus ĝin. . Ĉe kelkaj hakatonoj, hazarda tasko al teamoj estas praktikata, kaj la organizantoj asertas ke hazardaj teamoj rezultas ne pli malbonaj ol ekzistantaj. Sed laŭ miaj observoj, motivitaj homoj, kutime, trovas teamon memstare; se iu devas esti asignita, tiam, ofte, multaj el ili ne venas al la hakatono.
Koncerne la konsiston de la teamo, ĉi tio estas tre individua kaj tre dependa de la tasko. Mi povus diri, ke la minimuma realigebla teamkonsisto estas dezajnisto - front-end aŭ front-end - back-end. Sed mi ankaŭ konas kazojn, kiam venkis teamoj konsistantaj nur el front-endistoj, kiuj aldonis simplan back-end en node.js, aŭ faris poŝtelefonan aplikaĵon en React Native; aŭ nur de backenders kiuj faris simplan aranĝon. Ĝenerale ĉio estas tre individua kaj dependas de la tasko. Mia plano por elekti teamon por la hakatono estis jena: Mi planis kunveni teamon aŭ aliĝi al teamo kiel front-end - back-end - designer (mi estas front-end mi mem). Kaj sufiĉe rapide mi komencis babili kun python-backender kaj dezajnisto, kiuj akceptis la inviton aliĝi al ni. Iom poste, knabino, komerca analizisto, kiu jam havis sperton gajni hakatonon, aliĝis al ni, kaj ĉi tio decidis la aferon, ke ŝi aliĝu al ni. Post mallonga renkontiĝo, ni decidis nomi nin U4 (URBAN 4, urban four) analoge kun la fantazia kvar. Kaj ili eĉ metis respondan bildon sur la avataro de nia telegrama kanalo.
4. Elektante taskon. Kiel mi jam diris, vi devas havi konkurencivan avantaĝon, la tasko por la hakatono estas elektita surbaze de ĉi tio. Surbaze de tio, rigardinte kaj taksante ilian kompleksecon, ni decidiĝis je du taskoj: katalogo de novigaj entreprenoj de DPiIR kaj babilboto de EFKO. La taskon de DPIiR elektis la subendoninto, la taskon de EFKO elektis mi, ĉar havis sperton skribi babilbots en node.js kaj DialogFlow. La EFKO-tasko ankaŭ implikis ML; mi havas iom, ne tre vastan, sperton pri ML. Kaj laŭ la kondiĉoj de la problemo, ŝajnis al mi, ke ĝi ne verŝajne estos solvita per ML-iloj. Ĉi tiu sento plifortiĝis kiam mi iris al la renkontiĝo de Urban Tech Challenge, kie la organizantoj montris al mi datumaron pri EFKO, kie estis ĉirkaŭ 100 fotoj de produktaranĝoj (prenitaj el malsamaj anguloj) kaj ĉirkaŭ 20 klasoj de aranĝoeraroj. Kaj, samtempe, tiuj, kiuj ordonis la taskon, volis atingi sukcesprocenton de klasifiko de 90%. Rezulte, mi preparis prezenton de la solvo sen ML, la backender preparis prezenton bazitan sur la katalogo, kaj kune, post finpretigo de la prezentoj, ni sendis ilin al la Urban Tech Challenge. Jam en ĉi tiu etapo, la nivelo de instigo kaj kontribuo de ĉiu partoprenanto estis malkaŝita. Nia desegnisto ne partoprenis en la diskutoj, respondis malfrue, kaj eĉ plenigis informojn pri si en la prezento en la lasta momento, ĝenerale, duboj aperis.
Rezulte, ni pasis la taskon de DPiIR, kaj tute ne ĉagreniĝis, ke ni ne preterpasis la EFKO, ĉar la tasko ŝajnis al ni stranga, por milde diri.
5. Preparante por la hakatono. Kiam finfine oni sciis, ke ni kvalifikiĝis por la hakatono, ni komencis prepari la preparadon. Kaj ĉi tie mi ne rekomendas komenci skribi kodon semajnon antaŭ la komenco de la hakatono. Minimume, vi devus havi pretan kaldronon, per kiu vi povas tuj eklabori, sen devi agordi ilojn, kaj sen renkonti cimojn de iu lib, kiujn vi decidis provi la unuan fojon ĉe hakatono. Mi konas rakonton pri angulaj inĝenieroj, kiuj venis al hakatono kaj pasigis 2 tagojn por starigi la projekton, do ĉio estu preta anticipe. Ni intencis distribui respondecojn jene: la backender skribas crawlers kiuj traserĉas la Interreton kaj metas ĉiujn kolektitajn informojn en la datumbazon, dum mi skribas API en node.js kiu demandas ĉi tiun datumbazon kaj sendas la datumojn al la fronto. Ĉi-rilate, mi preparis servilon anticipe uzante express.js kaj preparis front-end en react. Mi ne uzas CRA, mi ĉiam agordas retpakon por mi kaj mi tre bone scias kiajn riskojn ĉi tio povas prezenti (memoru la rakonton pri angulaj programistoj). Je ĉi tiu punkto, mi petis interfacŝablonojn aŭ almenaŭ maketojn de nia dezajnisto por havi ideon pri tio, kion mi prezentus. En teorio, li ankaŭ devus fari siajn proprajn preparojn kaj kunordigi ilin kun ni, sed mi neniam ricevis respondon. Kiel rezulto, mi pruntis la dezajnon de unu el miaj malnovaj projektoj. Kaj ĝi komencis funkcii eĉ pli rapide, ĉar ĉiuj stiloj por ĉi tiu projekto jam estis skribitaj. Tial la konkludo: ne ĉiam necesas dezajnisto en teamo))). Ni venis al la hakatono kun ĉi tiuj evoluoj.
6. Laboru ĉe la hakatono. La unua fojo, kiam mi vidis mian teamon viva, estis nur ĉe la malfermo de la hakatono ĉe la Centra Distribua Centro. Ni renkontis, diskutis la solvon kaj etapojn de laboro pri la problemo. Kaj kvankam post la malfermo ni devis iri per buso al Ruĝa Oktobro, ni iris hejmen por dormi, konsentante alveni al la loko antaŭ la 9.00. Kial? La organizantoj ŝajne volis pleje profiti de la partoprenantoj, do ili aranĝis ĝuste tian horaron. Sed, laŭ mia sperto, vi povas kodi normale sen dormi dum unu nokto. Pri la dua, mi ne plu certas. Hakatono estas maratono; vi devas taŭge kalkuli kaj plani vian forton. Krome, ni havis preparojn.
Tial, post dormado, je la 9.00 ni sidis sur la sesa etaĝo de Dewocracy. Tiam nia dezajnisto neatendite anoncis, ke li ne havas tekkomputilon kaj ke li laboros hejme, kaj ni komunikiĝus per telefono. Ĉi tio estis la lasta pajlo. Kaj tiel ni pasis de kvar al trio, kvankam ni ne ŝanĝis la teamnomon. Denove, ĉi tio ne estis granda bato por ni; mi jam havis la dezajnon de la malnova projekto. Ĝenerale, komence ĉio iris sufiĉe glate kaj laŭplane. Ni ŝargis en la datumbazon (ni decidis uzi neo4j) datumaron de novigaj kompanioj de la organizantoj. Mi komencis kompostadon, poste prenis node.js, kaj tiam aferoj komencis misfardi. Mi neniam laboris kun neo4j antaŭe, kaj komence mi serĉis funkciantan pelilon por ĉi tiu datumbazo, poste mi eltrovis kiel skribi demandon, kaj tiam mi surpriziĝis malkovri, ke ĉi tiu datumbazo, pridemandite, resendas entojn en la formo de tabelo de nodaj objektoj kaj iliaj randoj. Tiuj. kiam mi petis organizon kaj ĉiujn datumojn pri ĝi per TIN, anstataŭ unu organiza objekto, mi estis resendita longan aron da objektoj enhavantaj datumojn pri ĉi tiu organizo kaj la rilatoj inter ili. Mi skribis mapiston, kiu trairis la tutan tabelon kaj gluis ĉiujn objektojn laŭ ilia organizo en unu objekton. Sed en batalo, petinte datumbazon de 8 mil organizoj, ĝi estis ekzekutita ege malrapide, ĉirkaŭ 20 - 30 sekundoj. Mi ekpensis pri optimumigo... Kaj tiam ni ĉesis ĝustatempe kaj ŝanĝis al MongoDB, kaj ni daŭris ĉirkaŭ 30 minutojn. Entute perdiĝis ĉirkaŭ 4 horoj ĉe neo5j.
Memoru, neniam prenu teknologion al hakatono, kun kiu vi ne konas, povas esti surprizoj. Sed, ĝenerale, krom ĉi tiu fiasko, ĉio iris laŭplane. Kaj jam matene de la 9-a de decembro ni havis plene funkciantan aplikaĵon. Dum la resto de la tago ni planis aldoni pliajn funkciojn al ĝi. Estonte, ĉio iris relative glate por mi, sed la backender havis multajn problemojn kun la malpermeso de siaj crawlers en serĉiloj, en la spamo de agregantoj de juraj entoj, kiuj venis en la unuaj lokoj de serĉrezultoj kiam petis. por ĉiu specifa firmao. Sed estas pli bone por li mem rakonti pri tio. La unua kroma funkcio, kiun mi aldonis, estis serĉo per plena nomo. Ĝenerala Direktoro de VKontakte. Ĝi daŭris plurajn horojn.
Do, sur la paĝo de la kompanio en nia aplikaĵo, aperis avataro de la ĝenerala direktoro, ligilo al lia paĝo VKontakte kaj iuj aliaj datumoj. Ĝi estis bela ĉerizo sur la kuko, kvankam ĝi eble ne donis al ni la venkon. Tiam mi volis fari iujn analizojn. Sed post longa serĉado de opcioj (estis multaj nuancoj kun la UI), mi decidiĝis pri la plej simpla agregado de organizaĵoj laŭ kodo de ekonomia agado. Jam vespere, en la lastaj horoj, mi elmetis ŝablonon por montri novigajn produktojn (en nia aplikaĵo supozeble estas sekcio de Produktoj kaj Servoj), kvankam la backend ne estis preta por tio. Samtempe, la datumbazo ŝveliĝis per saltoj, la rampiloj daŭre funkciis, la backender eksperimentis kun NLP por distingi novigajn tekstojn de nenovigataj))). Sed jam alproksimiĝis la tempo por la fina prezentado.
7. Prezento. Laŭ mia propra sperto, mi povas diri, ke vi devus ŝanĝi al preparado de prezento ĉirkaŭ 3 ĝis 4 horojn antaŭ ol ĝi venĝos. Precipe se ĝi implikas videon, ĝia filmado kaj redaktado prenas sufiĉe da tempo. Ni devis havi videon. Kaj ni havis specialan personon, kiu traktis ĉi tion, kaj ankaŭ solvis kelkajn aliajn organizajn problemojn. Ĉi-rilate, ni ne distris nin de kodado ĝis la lasta momento.
8. Tonalto. Mi ne ŝatis, ke la prezentoj kaj finaloj okazis en aparta labortago (lundo). Ĉi tie, plej verŝajne, daŭris la politiko de la organizantoj elpremi la maksimumon el la partoprenantoj. Mi ne planis preni libertempon de laboro, mi nur volis veni al la finalo, kvankam la resto de mia teamo prenis la liberan tagon. Tamen, la emocia mergo en la hakatonon jam estis tiom alta, ke je la 8-a horo mi skribis en la babilejo de mia teamo (la laborteamo, ne la hakatona teamo), ke mi prenis la tagon je mia propra elspezo, kaj iris al la centra. oficejo por tonaltoj. Nia problemo montriĝis havi multajn purajn datumajn sciencistojn, kaj tio multe influis la aliron al solvi la problemon. Multaj havis bonan DS, sed neniu havis funkciantan prototipon, multaj ne povis eviti la malpermesojn de siaj crawlers en serĉiloj. Ni estis la sola teamo kun funkcianta prototipo. Kaj ni sciis kiel solvi la problemon. En la fino, ni gajnis la trakon, kvankam ni estis tre bonŝancaj ke ni elektis la malplej konkurencivan taskon. Rigardante la tonaltojn en aliaj trakoj, ni ekkomprenis ke ni havus neniun ŝancon tie. Mi ankaŭ volas diri, ke ni estis tre bonŝancaj kun la ĵurio; ili zorge kontrolis la kodon. Kaj, se juĝi laŭ la recenzoj, ĉi tio ne okazis en ĉiuj aŭtoveturejoj.
9. Fino. Post kiam ni estis vokita al la ĵurio plurfoje por koda revizio, ni, opiniante ke ni finfine solvis ĉiujn problemojn, iris tagmanĝi ĉe Burger King. Tie la organizantoj denove vokis nin, ni devis rapide paki niajn mendojn kaj reiri.
La organizanto montris al ni kiun ĉambron ni bezonas iri, kaj enirinte, ni trovis nin ĉe publika parolanta trejna sesio por la venkantaj teamoj. La uloj kiuj devis rezulti sur la scenejo estis bone ŝargitaj, ĉiuj eliris kiel veraj spektakloj.
Kaj mi devas konfesi, en la finalo, sur la fono de la plej fortaj teamoj de aliaj aŭtoveturejoj, ni aspektis palaj; la venko en la registara kliento nomumo tute merite iris al la teamo de la nemoveblaĵo-teknika vojo. Mi pensas, ke la ŝlosilaj faktoroj, kiuj kontribuis al nia venko sur la trako, estis: la havebleco de preta blankaĵo, pro kiu ni povis rapide fari prototipon, la ĉeesto de "elstaraĵoj" en la prototipo (serĉo de ĉefoficistoj en sociaj retoj) kaj la NLP-kapabloj de nia subtenanto , kiuj ankaŭ multe interesis la ĵurion.
Kaj konklude, tradician dankon al ĉiuj, kiuj subtenis nin, al la ĵurio de nia trako, Evgeniy Evgrafiev (la aŭtoro de la problemo, kiun ni solvis ĉe la hakatono) kaj kompreneble la organizantoj de la hakatono. Ĉi tio eble estis la plej granda kaj plej mojosa hakatono, kiun mi iam partoprenis, mi povas nur deziri, ke la infanoj konservu tian altan normon en la estonteco!
fonto: www.habr.com