Ang pangalan ko ay Dmitry. At gusto kong pag-usapan kung paano naabot ng aming team ang finals ng Urban Tech Challenge hackathon sa Big Data track. Sasabihin ko kaagad na hindi ito ang unang hackathon kung saan ako lumahok, at hindi ang una kung saan ako nakakuha ng mga premyo. Kaugnay nito, sa aking kwento, nais kong ipahayag ang ilang pangkalahatang obserbasyon at konklusyon patungkol sa industriya ng hackathon sa kabuuan, at ibigay ang aking pananaw kumpara sa mga negatibong pagsusuri na lumabas kaagad online pagkatapos ng Urban Tech Challenge (para sa halimbawa ).
Kaya una ang ilang mga pangkalahatang obserbasyon.
1. Nakakagulat na ilang tao ang walang muwang na nag-iisip na ang hackathon ay isang uri ng kumpetisyon sa palakasan kung saan nanalo ang pinakamahuhusay na coder. Mali ito. Hindi ko isinasaalang-alang ang mga kaso kapag ang mga hackathon organizer mismo ay hindi alam kung ano ang gusto nila (nakita ko na rin). Ngunit, bilang isang patakaran, ang kumpanya na nag-aayos ng isang hackathon ay hinahabol ang sarili nitong mga layunin. Maaaring iba ang kanilang listahan: maaaring ito ay isang teknikal na solusyon sa ilang problema, paghahanap ng mga bagong ideya at tao, atbp. Kadalasang tinutukoy ng mga layuning ito ang format ng kaganapan, ang tiyempo nito, online/offline, kung paano bubuuin ang mga gawain (at kung mabubuo ba ang mga ito), kung magkakaroon ng pagsusuri sa code sa hackathon, atbp. Parehong ang mga koponan at kung ano ang kanilang ginawa ay tinasa mula sa puntong ito ng view. At ang mga koponan na pinakamahusay na naabot ang punto na kailangan ng kumpanya ay manalo, at marami ang nakarating sa puntong ito na ganap na hindi sinasadya at hindi sinasadya, iniisip na sila ay talagang kalahok sa isang kumpetisyon sa palakasan. Ang aking mga obserbasyon ay nagpapakita na upang ma-motivate ang mga kalahok, ang mga tagapag-ayos ay dapat lumikha ng hindi bababa sa hitsura ng isang kapaligiran sa palakasan at pantay na mga kondisyon, kung hindi man ay makakatanggap sila ng isang alon ng negatibiti, tulad ng sa pagsusuri sa itaas. Ngunit lumihis tayo.
2. Kaya ang sumusunod na konklusyon. Ang mga tagapag-ayos ay interesado sa mga kalahok na dumarating sa hackathon na may sariling gawain, kung minsan ay espesyal na nag-aayos sila ng isang online na yugto ng pagsusulatan para sa layuning ito. Nagbibigay-daan ito para sa mas malakas na mga solusyon sa output. Ang konsepto ng "sariling gawain" ay isang napaka-kamag-anak; sinumang may karanasang developer ay maaaring makaipon ng libu-libong linya ng code mula sa kanyang mga lumang proyekto sa kanyang unang commit. At ito ba ay isang pre-prepared development? Ngunit sa anumang kaso, nalalapat ang panuntunan, na ipinahayag ko sa anyo ng isang sikat na meme:
Upang manalo, dapat mayroon kang isang bagay, isang uri ng mapagkumpitensyang kalamangan: isang katulad na proyekto na ginawa mo sa nakaraan, kaalaman at karanasan sa isang partikular na paksa, o isang handa na gawaing ginawa bago magsimula ang hackathon. Oo, hindi ito palakasan. Oo, maaaring hindi ito katumbas ng pagsisikap na ginugol (dito, ang bawat isa ay nagpapasya para sa kanilang sarili kung ito ay nagkakahalaga ng coding para sa 3 linggo sa gabi para sa isang premyo na 100, na hinati sa buong koponan, at kahit na may panganib na hindi ito matanggap). Ngunit, madalas, ito lamang ang pagkakataong mauna.
3. Pagpili ng pangkat. Tulad ng napansin ko sa mga chat sa hackathon, marami ang lumalapit sa isyung ito nang walang kabuluhan (bagaman ito ang pinakamahalagang desisyon na tutukuyin ang iyong resulta sa hackathon). Sa maraming lugar ng aktibidad (kapwa sa sports at sa hackathon) nakita ko na ang malalakas na tao ay may posibilidad na makiisa sa malakas, mahina sa mahina, matalino sa matalino, well, sa pangkalahatan, nakuha mo ang ideya... Ito ay halos kung ano ang nangyayari sa mga chat: hindi gaanong malakas na mga programmer ay agad silang nahuli, ang mga taong walang anumang mga kasanayan na mahalaga para sa isang hackathon ay nananatili sa chat nang mahabang panahon at pumili ng isang koponan sa prinsipyo na kung may kukuha lang nito . Sa ilang hackathon, ginagawa ang random na pagtatalaga sa mga koponan, at sinasabi ng mga organizer na ang mga random na koponan ay gumaganap nang hindi mas masama kaysa sa mga umiiral na. Ngunit ayon sa aking mga obserbasyon, ang mga motivated na tao, bilang panuntunan, ay naghahanap ng isang koponan sa kanilang sarili; kung ang isang tao ay kailangang italaga, kung gayon, madalas, marami sa kanila ang hindi pumupunta sa hackathon.
Tulad ng para sa komposisyon ng koponan, ito ay napaka-indibidwal at lubos na nakadepende sa gawain. Masasabi kong ang pinakamababang mabubuhay na komposisyon ng koponan ay isang taga-disenyo - front-end o front-end - back-end. Ngunit may alam din akong mga kaso kung kailan nanalo ang mga team na binubuo lang ng mga front-end, na nagdagdag ng simpleng back-end sa node.js, o gumawa ng mobile application sa React Native; o mula lamang sa mga backender na gumawa ng simpleng layout. Sa pangkalahatan, ang lahat ay napaka-indibidwal at nakasalalay sa gawain. Ang aking plano para sa pagpili ng isang team para sa hackathon ay ang mga sumusunod: Nagplano akong mag-assemble ng isang team o sumali sa isang team tulad ng front-end - back-end - designer (ako mismo ay front-end). At medyo mabilis na nagsimula akong makipag-chat sa isang backender ng sawa at isang taga-disenyo na tinanggap ang imbitasyon na sumali sa amin. Maya-maya, sumali sa amin ang isang babae, isang business analyst, na may karanasan nang manalo sa hackathon, at ito ang nagpasya sa isyu ng pagsali niya sa amin. Pagkatapos ng maikling pagpupulong, nagpasya kaming tawagin ang aming sarili na U4 (URBAN 4, urban four) sa pamamagitan ng pagkakatulad sa fantastic four. At naglagay pa sila ng kaukulang larawan sa avatar ng aming telegram channel.
4. Pagpili ng isang gawain. Tulad ng nasabi ko na, dapat ay mayroon kang competitive advantage, ang gawain para sa hackathon ay pinili batay dito. Batay dito, nang tumingin at tinatasa ang pagiging kumplikado ng mga ito, nakipagkasundo kami sa dalawang gawain: isang catalog ng mga makabagong negosyo mula sa DPiIR at isang chatbot mula sa EFKO. Ang gawain mula sa DPIiR ay pinili ng backender, ang gawain mula sa EFKO ay pinili ko, dahil nagkaroon ng karanasan sa pagsusulat ng mga chatbot sa node.js at DialogFlow. Kasama rin sa gawain ng EFKO ang ML; Mayroon akong ilang, hindi masyadong malawak, karanasan sa ML. At ayon sa mga kondisyon ng problema, tila sa akin ay malamang na hindi ito malutas gamit ang mga tool ng ML. Lumakas ang pakiramdam na ito nang pumunta ako sa Urban Tech Challenge meetup, kung saan ipinakita sa akin ng mga organizer ang isang dataset sa EFKO, kung saan mayroong humigit-kumulang 100 larawan ng mga layout ng produkto (kinuha mula sa iba't ibang anggulo) at humigit-kumulang 20 klase ng mga error sa layout. At, sa parehong oras, ang mga nag-utos ng gawain ay nais na makamit ang isang rate ng tagumpay ng pag-uuri na 90%. Bilang isang resulta, naghanda ako ng isang pagtatanghal ng solusyon nang walang ML, ang backender ay naghanda ng isang pagtatanghal batay sa katalogo, at magkakasama, pagkatapos na tapusin ang mga pagtatanghal, ipinadala namin ang mga ito sa Urban Tech Challenge. Nasa yugto na ito, nahayag ang antas ng motibasyon at kontribusyon ng bawat kalahok. Ang aming taga-disenyo ay hindi nakibahagi sa mga talakayan, huli na tumugon, at kahit na pinunan ang impormasyon tungkol sa kanyang sarili sa pagtatanghal sa pinakahuling sandali, sa pangkalahatan, ang mga pagdududa ay lumitaw.
Bilang resulta, naipasa namin ang gawain mula sa DPiIR, at hindi kami nagalit na hindi namin naipasa ang EFKO, dahil ang gawain ay tila kakaiba sa amin, upang ilagay ito nang mahinahon.
5. Paghahanda para sa hackathon. Nang sa wakas ay malaman na kami ay kwalipikado para sa hackathon, sinimulan naming ihanda ang paghahanda. At dito hindi ako nagsusulong na magsimulang magsulat ng code isang linggo bago magsimula ang hackathon. Hindi bababa sa, dapat kang magkaroon ng isang boilerplate na handa, kung saan maaari kang agad na magsimulang magtrabaho, nang hindi kinakailangang i-configure ang mga tool, at nang hindi nabangga ang mga bug ng ilang lib na napagpasyahan mong subukan sa unang pagkakataon sa isang hackathon. May alam akong kuwento tungkol sa mga angular na inhinyero na pumunta sa isang hackathon at gumugol ng 2 araw sa pag-set up ng project build, kaya dapat ihanda nang maaga ang lahat. Nilalayon naming ipamahagi ang mga responsibilidad tulad ng sumusunod: nagsusulat ang backender ng mga crawler na nagsusuri sa Internet at naglalagay ng lahat ng nakolektang impormasyon sa database, habang nagsusulat ako ng API sa node.js na nagtatanong sa database na ito at nagpapadala ng data sa harapan. Kaugnay nito, naghanda ako ng server nang maaga gamit ang express.js at naghanda ng front-end bilang reaksyon. Hindi ako gumagamit ng CRA, palagi kong kino-customize ang webpack para sa sarili ko at alam kong mabuti kung ano ang mga panganib na maaaring idulot nito (tandaan ang kuwento tungkol sa mga angular na developer). Sa puntong ito, humiling ako ng mga template ng interface o hindi bababa sa mga mockup mula sa aming taga-disenyo upang magkaroon ng ideya kung ano ang aking ilalatag. Sa teorya, dapat din siyang gumawa ng kanyang sariling mga paghahanda at i-coordinate ang mga ito sa amin, ngunit hindi ako nakatanggap ng sagot. Bilang resulta, hiniram ko ang disenyo mula sa isa sa aking mga lumang proyekto. At nagsimula itong gumana nang mas mabilis, dahil naisulat na ang lahat ng mga istilo para sa proyektong ito. Kaya ang konklusyon: ang isang taga-disenyo ay hindi palaging kinakailangan sa isang koponan))). Dumating kami sa hackathon kasama ang mga pag-unlad na ito.
6. Magtrabaho sa hackathon. Ang unang pagkakataon na nakita ko ang aking koponan nang live ay sa pagbubukas lamang ng hackathon sa Central Distribution Center. Nagkita kami, napag-usapan ang solusyon at mga yugto ng pagtatrabaho sa problema. At bagaman pagkatapos ng pagbubukas ay kailangan naming sumakay ng bus papuntang Red October, umuwi kami upang matulog, na pumayag na makarating sa lugar ng 9.00. Bakit? Tila gusto ng mga organizer na sulitin ang mga kalahok, kaya inayos nila ang ganoong iskedyul. Ngunit, sa aking karanasan, maaari kang mag-code nang normal nang hindi natutulog sa isang gabi. Tungkol naman sa pangalawa, hindi na ako sigurado. Ang hackathon ay isang marathon; kailangan mong sapat na kalkulahin at planuhin ang iyong lakas. Bukod dito, mayroon kaming mga paghahanda.
Samakatuwid, pagkatapos matulog, sa 9.00 ay nakaupo kami sa ikaanim na palapag ng Dewocracy. Pagkatapos ay hindi inaasahang inihayag ng aming taga-disenyo na wala siyang laptop at nagtatrabaho siya mula sa bahay, at nakikipag-usap kami sa pamamagitan ng telepono. Ito ang huling straw. At kaya naging tatlo kami mula sa apat, bagaman hindi namin binago ang pangalan ng koponan. Muli, hindi ito isang malaking dagok para sa amin; Mayroon na akong disenyo mula sa lumang proyekto. Sa pangkalahatan, sa una ang lahat ay naging maayos at ayon sa plano. Nag-load kami sa database (napagpasyahan naming gumamit ng neo4j) isang dataset ng mga makabagong kumpanya mula sa mga organizer. Nagsimula akong mag-typeset, pagkatapos ay kumuha ng node.js, at pagkatapos ay nagsimulang magkamali. Hindi pa ako nakatrabaho dati sa neo4j, at sa una ay naghahanap ako ng gumaganang driver para sa database na ito, pagkatapos ay naisip ko kung paano magsulat ng query, at pagkatapos ay nagulat ako nang matuklasan na ang database na ito, kapag na-query, ay nagbabalik ng mga entity sa anyo ng isang hanay ng mga bagay sa node at ang kanilang mga gilid. Yung. nang humiling ako ng isang organisasyon at lahat ng data dito sa pamamagitan ng TIN, sa halip na isang object ng organisasyon, ibinalik sa akin ang isang mahabang hanay ng mga bagay na naglalaman ng data sa organisasyong ito at ang mga relasyon sa pagitan nila. Sumulat ako ng isang mapper na dumaan sa buong array at idinikit ang lahat ng mga bagay ayon sa kanilang organisasyon sa isang bagay. Ngunit sa labanan, kapag humiling ng isang database ng 8 libong mga organisasyon, ito ay naisakatuparan nang napakabagal, mga 20 - 30 segundo. Nagsimula akong mag-isip tungkol sa pag-optimize... At pagkatapos ay huminto kami sa oras at lumipat sa MongoDB, at tumagal kami ng halos 30 minuto. Sa kabuuan, humigit-kumulang 4 oras ang nawala sa neo5j.
Tandaan, huwag kailanman dalhin ang teknolohiya sa isang hackathon na hindi ka pamilyar, maaaring may mga sorpresa. Ngunit, sa pangkalahatan, bukod sa kabiguan na ito, ang lahat ay naaayon sa plano. At sa umaga ng Disyembre 9, mayroon kaming ganap na gumaganang aplikasyon. Para sa natitirang bahagi ng araw ay binalak naming magdagdag ng mga karagdagang feature dito. Sa hinaharap, ang lahat ay medyo maayos para sa akin, ngunit ang backender ay nagkaroon ng isang buong bungkos ng mga problema sa pagbabawal ng kanyang mga crawler sa mga search engine, sa spam ng mga aggregator ng mga legal na entity, na dumating sa mga unang lugar ng mga resulta ng paghahanap kapag humihiling para sa bawat partikular na kumpanya. Pero mas mabuting siya na mismo ang magkuwento nito. Ang unang karagdagang feature na idinagdag ko ay ang paghahanap ayon sa buong pangalan. Pangkalahatang Direktor ng VKontakte. Tumagal ng ilang oras.
Kaya, sa pahina ng kumpanya sa aming aplikasyon, lumitaw ang isang avatar ng pangkalahatang direktor, isang link sa kanyang pahina ng VKontakte at ilang iba pang data. Ito ay isang magandang cherry sa cake, bagaman maaaring hindi ito nagbigay sa amin ng panalo. Pagkatapos, gusto kong magpatakbo ng ilang analytics. Ngunit pagkatapos ng mahabang paghahanap ng mga pagpipilian (mayroong maraming mga nuances sa UI), nanirahan ako sa pinakasimpleng pagsasama-sama ng mga organisasyon sa pamamagitan ng pang-ekonomiyang aktibidad code. Sa gabi na, sa mga huling oras, naglalagay ako ng isang template para sa pagpapakita ng mga makabagong produkto (sa aming aplikasyon ay dapat na isang seksyon ng Mga Produkto at Serbisyo), kahit na ang backend ay hindi handa para dito. Kasabay nito, ang database ay namumulaklak nang mabilis, ang mga crawler ay patuloy na gumagana, ang backender ay nag-eksperimento sa NLP upang makilala ang mga makabagong teksto mula sa mga hindi makabagong))). Ngunit ang oras para sa huling pagtatanghal ay nalalapit na.
7. Paglalahad. Mula sa sarili kong karanasan, masasabi kong dapat kang lumipat sa paghahanda ng isang presentasyon mga 3 hanggang 4 na oras bago ito matapos. Lalo na kung ito ay nagsasangkot ng video, ang pagbaril at pag-edit nito ay tumatagal ng maraming oras. May video daw kami. At mayroon kaming isang espesyal na tao na humarap dito, at nalutas din ang ilang iba pang mga isyu sa organisasyon. Sa bagay na ito, hindi namin ginulo ang aming sarili mula sa coding hanggang sa huling sandali.
8. Pitch. Hindi ko nagustuhan na ang mga presentasyon at finals ay gaganapin sa isang hiwalay na araw ng linggo (Lunes). Dito, malamang, nagpatuloy ang patakaran ng mga organizers na i-squeeze ang maximum out sa mga kalahok. Hindi ko binalak na magpahinga mula sa trabaho, gusto ko lamang na makarating sa finals, bagaman ang iba sa aking koponan ay nag-day off. Gayunpaman, ang emosyonal na paglulubog sa hackathon ay napakataas na kaya noong 8 am ay isinulat ko sa chat ng aking koponan (ang pangkat ng trabaho, hindi ang pangkat ng hackathon) na ako ay tumatagal ng araw sa sarili kong gastos, at pumunta sa gitnang opisina para sa mga pitch. Ang aming problema ay lumabas na may maraming purong data scientist, at ito ay lubos na nakaapekto sa diskarte sa paglutas ng problema. Marami ang may magandang DS, ngunit walang may gumaganang prototype, marami ang hindi makalusot sa mga pagbabawal ng kanilang mga crawler sa mga search engine. Kami lang ang team na may gumaganang prototype. At alam namin kung paano lutasin ang problema. Sa huli, nanalo kami sa track, bagama't napakaswerte namin na pinili namin ang hindi gaanong mapagkumpitensyang gawain. Sa pagtingin sa mga pitch sa ibang mga track, napagtanto namin na wala kaming pagkakataon doon. Gusto ko ring sabihin na napakaswerte namin sa hurado; maingat nilang sinuri ang code. At, sa paghusga sa pamamagitan ng mga pagsusuri, hindi ito nangyari sa lahat ng mga track.
9. Pangwakas. Matapos kaming tawagin sa hurado ng ilang beses para sa pagsusuri ng code, kami, sa pag-aakalang nalutas na namin sa wakas ang lahat ng mga isyu, ay nagpunta upang kumain ng tanghalian sa Burger King. Doon kami tinawagan muli ng mga organizer, kailangan naming mabilis na mag-impake ng aming mga order at bumalik.
Ipinakita sa amin ng organizer kung aling silid ang kailangan naming puntahan, at pagpasok namin, natagpuan namin ang aming mga sarili sa isang sesyon ng pagsasanay sa pagsasalita sa publiko para sa mga nanalong koponan. Yung mga lalaki na dapat magpe-perform sa stage, well charged, lahat lumabas na parang totoong showmen.
At dapat kong aminin, sa pangwakas, laban sa backdrop ng pinakamalakas na mga koponan mula sa iba pang mga track, nagmukha kaming maputla; ang tagumpay sa nominasyon ng customer ng gobyerno ay karapat-dapat na napunta sa koponan mula sa real estate tech track. Sa tingin ko ang mga pangunahing salik na nag-ambag sa aming tagumpay sa track ay: ang pagkakaroon ng isang handa na blangko, dahil sa kung saan kami ay mabilis na nakagawa ng isang prototype, ang pagkakaroon ng "mga highlight" sa prototype (paghahanap para sa mga CEO sa mga social network) at ang mga kasanayan sa NLP ng aming backender , na lubos ding interesado sa hurado.
At sa konklusyon, tradisyonal na salamat sa lahat ng sumuporta sa amin, ang hurado ng aming track, si Evgeniy Evgrafiev (ang may-akda ng problema na nalutas namin sa hackathon) at siyempre ang mga organizer ng hackathon. Ito na marahil ang pinakamalaki at pinakaastig na hackathon na nilahukan ko, hiling ko lang na panatilihin ng mga lalaki ang ganoong mataas na pamantayan sa hinaharap!
Pinagmulan: www.habr.com