Jenengku Dmitry. Lan aku pengin ngomong babagan carane tim kita tekan final hackathon Urban Tech Challenge ing trek Big Data. Aku bakal langsung ngomong yen iki dudu hackathon pisanan sing aku melu, lan dudu sing pertama aku entuk hadiah. Ing babagan iki, ing critaku, aku pengin nyritakake sawetara pengamatan lan kesimpulan umum babagan industri hackathon sacara sakabehe, lan menehi sudut pandangku minangka lawan saka review negatif sing muncul online sanalika sawise rampung Tantangan Urban Tech (kanggo contone ).
Dadi pisanan sawetara pengamatan umum.
1. Iku ngageti sing cukup sawetara wong naively mikir hackathon sawetara jenis kompetisi olahraga ngendi coders paling menang. Iki salah. Aku ora nganggep kasus nalika penyelenggara hackathon dhewe ora ngerti apa sing dikarepake (aku uga wis weruh). Nanging, minangka aturan, perusahaan sing ngatur hackathon ngupayakake tujuane dhewe. Dhaptar kasebut bisa uga beda: bisa dadi solusi teknis kanggo sawetara masalah, golek ide lan wong anyar, lsp. Tujuan kasebut asring nemtokake format acara, wektune, online / offline, carane tugas bakal dirumusake (lan apa bakal dirumusake kabeh), apa bakal ana review kode ing hackathon, lsp. Loro-lorone tim lan apa sing ditindakake ditaksir saka sudut pandang iki. Lan tim sing paling cocog karo titik sing dibutuhake perusahaan menang, lan akeh sing tekan kanthi ora sadar lan ora sengaja, mikir yen dheweke pancen melu kompetisi olahraga. Pengamatanku nuduhake yen kanggo motivasi peserta, panitia kudu nggawe paling ora katon lingkungan olahraga lan kondisi sing padha, yen ora, dheweke bakal nampa gelombang negatif, kaya ing review ing ndhuwur. Nanging kita digress.
2. Mula dudutan ing ngisor iki. Penyelenggara kasengsem ing peserta sing teka ing hackathon kanthi karyane dhewe-dhewe, kadhangkala uga ngatur panggung korespondensi online kanggo tujuan kasebut. Iki ngidini kanggo solusi output kuwat. Konsep "karya dhewe" relatif banget; pangembang sing berpengalaman bisa nglumpukake ewu baris kode saka proyek lawas ing komitmen pisanane. Lan iki bakal dadi pembangunan sing wis disiapake? Nanging ing kasus apa wae, aturan kasebut ditrapake, sing dakkandhakake ing bentuk meme sing misuwur:
Kanggo menang, sampeyan kudu duwe sawetara kauntungan kompetitif: proyek sing padha karo sadurunge, kawruh lan pengalaman ing topik tartamtu, utawa karya sing wis rampung sadurunge hackathon diwiwiti. Ya ora olahraga. Ya, iki bisa uga ora worth gaweyan expended (ing kene, saben wong mutusaké kanggo awake dhewe apa iku worth coding kanggo 3 minggu ing wayah wengi kanggo hadiah 100 ewu, dipérang antarane kabeh tim, lan malah karo resiko ora nampa). Nanging, asring, iki mung kesempatan kanggo maju.
3. Pamilihan tim. Nalika aku weruh ing obrolan hackathon, akeh sing nyedhaki masalah iki kanthi sembrono (sanajan iki minangka keputusan sing paling penting sing bakal nemtokake asil sampeyan ing hackathon). Ing pirang-pirang bidang kegiatan (loro olahraga lan hackathon) aku weruh manawa wong sing kuwat cenderung nyawiji karo sing kuwat, sing ringkih karo sing ringkih, sing pinter karo sing pinter, umume, sampeyan entuk ide ... Iki kira-kira apa sing kedadeyan ing obrolan: programer sing kurang kuwat langsung dicekel, wong sing ora duwe katrampilan sing larang regane hackathon ing obrolan suwene suwe lan milih tim kanthi prinsip yen mung ana sing bakal njupuk. . Ing sawetara hackathon, tugas acak kanggo tim dipraktikake, lan panitia ngaku yen tim acak ora luwih elek tinimbang sing wis ana. Nanging miturut pengamatanku, wong sing duwe motivasi, biasane, golek tim dhewe, yen ana wong sing kudu ditugasake, mula, asring, akeh sing ora teka ing hackathon.
Minangka kanggo komposisi tim, iki banget individu lan gumantung banget ing tugas. Aku bisa ngomong yen komposisi tim minimal sing bisa ditindakake yaiku desainer - front-end utawa front-end - back-end. Nanging aku uga ngerti kasus nalika tim mung dumadi saka front-enders menang, sing nambah back-end prasaja ing node.js, utawa nggawe aplikasi seluler ing React Native; utawa mung saka backenders sing nindakake tata letak prasaja. Umumé, kabeh iku individu banget lan gumantung ing tugas. Rencanaku kanggo milih tim kanggo hackathon kaya ing ngisor iki: Aku ngrencanakake ngumpulake tim utawa gabung karo tim kaya front-end - back-end - designer (aku dhewe sing ngarep-arep). Lan cukup cepet aku miwiti ngobrol karo backender python lan desainer sing nampa undhangan kanggo gabung kita. Ora suwe, ana bocah wadon, analis bisnis, sing wis duwe pengalaman menang hackathon, gabung karo kita, lan iki mutusake masalah dheweke gabung karo kita. Sawise rapat singkat, kita mutusake kanggo nyebut awake dhewe U4 (URBAN 4, kutha papat) kanthi analogi karo papat sing fantastis. Lan malah sijine gambar sing cocog ing avatar saluran telegram kita.
4. Milih tugas. Kaya sing wis dakkandhakake, sampeyan kudu duwe keunggulan kompetitif, tugas kanggo hackathon dipilih adhedhasar iki. Adhedhasar iki, wis katon lan netepake kerumitan, kita ngrampungake rong tugas: katalog perusahaan inovatif saka DPiIR lan chatbot saka EFKO. Tugas saka DPIiR dipilih dening backender, tugas saka EFKO dipilih dening kula, amarga wis pengalaman nulis chatbots ing node.js lan DialogFlow. Tugas EFKO uga melu ML; Aku duwe sawetara, ora akeh banget, pengalaman ing ML. Lan miturut kahanan masalah kasebut, aku rumangsa ora bisa ditanggulangi kanthi nggunakake alat ML. Perasaan iki dikuwatake nalika aku lunga menyang Urban Tech Challenge meetup, ngendi panitia nuduhake kula dataset ing EFKO, ngendi ana bab 100 foto tata produk (dijupuk saka sudhut sing beda) lan bab 20 kelas saka kesalahan tata letak. Lan, ing wektu sing padha, sing mrentahake tugas kasebut pengin entuk tingkat sukses klasifikasi 90%. Akibaté, aku nyiapake presentation saka solusi tanpa ML, backender nyiapake presentation adhedhasar katalog, lan bebarengan, sawise finalizing presentations, kita dikirim menyang Urban Tech Challenge. Wis ing tahap iki, tingkat motivasi lan kontribusi saben peserta dicethakaké. Desainer kita ora melu diskusi, nanggapi pungkasan, lan malah ngisi informasi babagan awake dhewe ing presentasi ing wayahe pungkasan, umume, keraguan muncul.
Akibaté, kita liwati tugas saka DPiIR, lan padha ora ing kabeh upset sing ora pass EFKO, wiwit tugas ketoke aneh kanggo kita, kanggo sijine iku mildly.
5. Nyiapake kanggo hackathon. Nalika pungkasane dikenal yen kita wis mumpuni kanggo hackathon, kita wiwit nyiapake persiapan kasebut. Lan ing kene aku ora nyengkuyung miwiti nulis kode seminggu sadurunge wiwitan hackathon. Paling ora, sampeyan kudu nyiapake boilerplate, sing bisa langsung digunakake, tanpa kudu ngatur alat, lan tanpa nabrak bug saka sawetara lib sing sampeyan mutusake kanggo nyoba pisanan ing hackathon. Aku ngerti crita babagan insinyur sudut sing teka ing hackathon lan ngentekake 2 dina nyiyapake proyek kasebut, mula kabeh kudu disiapake sadurunge. We intended kanggo disebaraké tanggung jawab minangka nderek: backender nyerat crawler sing scour Internet lan sijine kabeh informasi sing diklumpukake ing database, nalika aku nulis API ing node.js sing takon database iki lan ngirim data menyang ngarep. Ing babagan iki, aku nyiapake server sadurunge nggunakake express.js lan nyiapake front-end ing reaksi. Aku ora nggunakake CRA, Aku tansah ngatur webpack kanggo aku lan aku ngerti banget apa risiko iki bisa nuduhke (elinga crita bab pangembang sudut). Ing wektu iki, aku njaluk template antarmuka utawa paling ora mockup saka desainer kita supaya bisa duwe ide babagan apa sing bakal dakwenehake. Ing teori, dheweke uga kudu nggawe persiapan dhewe lan koordinasi karo kita, nanging aku ora nate nampa jawaban. Akibaté, aku nyilih desain saka salah siji proyek lawas. Lan wiwit bisa luwih cepet, amarga kabeh gaya kanggo proyek iki wis ditulis. Dadi kesimpulan: desainer ora mesthi dibutuhake ing tim))). Kita teka ing hackathon kanthi perkembangan kasebut.
6. Kerja ing hackathon. Sepisanan aku ndeleng timku langsung mung nalika mbukak hackathon ing Pusat Distribusi Pusat. Kita ketemu, ngrembug solusi lan tahapan nggarap masalah kasebut. Lan senajan sawise bukaan kita kudu pindhah bis menyang Red Oktober, kita mulih kanggo turu, setuju kanggo teka ing panggonan ing 9.00. Kenging punapa? Penyelenggara ketoke pengin entuk manfaat sing maksimal saka peserta, mula dheweke ngatur jadwal sing kaya ngono. Nanging, ing pengalamanku, sampeyan bisa kode normal tanpa turu sewengi. Kanggo sing nomer loro, aku ora yakin maneh. Hackathon minangka maraton; sampeyan kudu ngetung lan ngrancang kekuatan sampeyan kanthi cukup. Kajaba iku, kita duwe persiapan.
Mula, sawise turu, jam 9.00 awake dhewe lungguh ing lantai enem Dewokrasi. Banjur desainer kita ora sengaja ngumumake yen dheweke ora duwe laptop lan dheweke bakal kerja saka omah, lan kita bakal komunikasi liwat telpon. Iki minangka jerami pungkasan. Dadi, kita nguripake saka papat dadi telu, sanajan kita ora ngganti jeneng tim. Maneh, iki ora dadi pukulan gedhe kanggo kita; Aku wis duwe desain saka proyek lawas. Umumé, pisanan kabeh lumaku kanthi lancar lan miturut rencana. Kita dimuat menyang database (kita mutusake nggunakake neo4j) dataset perusahaan inovatif saka panitia. Aku miwiti ngetik, banjur njupuk munggah node.js, lan banjur iku wiwit misfire. Aku ora tau nggarap neo4j sadurunge, lan ing wiwitan aku nggoleki driver sing bisa digunakake kanggo database iki, banjur aku ngerti carane nulis pitakon, banjur aku kaget nemokake yen database iki, nalika ditakoni, ngasilake entitas ing wangun array saka obyek simpul lan pinggiran. Sing. nalika aku njaluk organisasi lan kabeh data ing iku dening TIN, tinimbang siji obyek organisasi, aku bali Uploaded dawa saka obyek ngemot data ing organisasi iki lan hubungan antarane wong-wong mau. Aku nulis mapper sing ngliwati kabeh array lan nempelake kabeh obyek miturut organisasi dadi siji obyek. Nanging ing paprangan, nalika njaluk database 8 ewu organisasi, dieksekusi alon-alon, kira-kira 20 - 30 detik. Aku wiwit mikir babagan optimasi ... Banjur kita mandheg ing wektu lan ngalih menyang MongoDB, lan butuh udakara 30 menit. Total, kira-kira 4 jam ilang ing neo5j.
Elinga, aja njupuk teknologi menyang hackathon sing ora sampeyan kenal, bisa uga ana kejutan. Nanging, ing umum, saliyane saka kegagalan iki, kabeh mlaku miturut rencana. Lan wis esuk tanggal 9 Desember, kita duwe aplikasi sing bisa digunakake. Kanggo liyane dina kita ngrancang kanggo nambah fitur tambahan kanggo. Ing mangsa ngarep, kabeh dadi lancar kanggo aku, nanging backender duwe akeh masalah karo larangan crawler ing mesin telusuran, ing spam aggregator entitas hukum, sing teka ing papan pertama asil panelusuran nalika njaluk. kanggo saben perusahaan tartamtu. Nanging luwih becik dheweke nyritakake dhewe. Fitur tambahan pisanan sing ditambahake yaiku telusuran kanthi jeneng lengkap. Direktur Umum VKontakte. Butuh sawetara jam.
Dadi, ing kaca perusahaan ing aplikasi kita, ana avatar direktur umum, link menyang kaca VKontakte lan sawetara data liyane. Iku Cherry becik ing jajan, senajan bisa uga ora menehi kita menang. Banjur, aku pengin mbukak sawetara analytics. Nanging sawise nggoleki pilihan sing dawa (ana akeh nuansa karo UI), aku mapan ing agregasi organisasi sing paling gampang kanthi kode kegiatan ekonomi. Wis ing wayah sore, ing jam pungkasan, aku nggawe template kanggo nampilake produk inovatif (ing aplikasi kita mesthine ana bagean Produk lan Layanan), sanajan backend durung siap. Ing wektu sing padha, database dadi gedhe kanthi kabisat, crawler terus kerja, backender eksperimen karo NLP kanggo mbedakake teks inovatif saka teks non-inovatif))). Nanging wektu kanggo presentasi pungkasan wis nyedhak.
7. Presentasi. Saka pengalamanku dhewe, aku bisa ujar manawa sampeyan kudu nyiapake presentasi udakara 3 nganti 4 jam sadurunge wis rampung. Utamane yen kalebu video, njupuk lan nyunting mbutuhake wektu sing cukup suwe. Kita mesthine duwe video. Lan kita duwe wong khusus sing ngatasi iki, lan uga ngrampungake sawetara masalah organisasi liyane. Ing babagan iki, kita ora ngganggu awake dhewe saka coding nganti pungkasan.
8. Pitik. Aku ora seneng yen presentasi lan final dianakake ing dina minggu sing kapisah (Senin). Ing kene, paling kamungkinan, kabijakan penyelenggara kanggo nyepetake maksimal peserta terus. Aku ora rencana kanggo njupuk wektu saka karya, Aku mung arep teka menyang final, sanajan liyane saka tim njupuk dina. Nanging, kecemplung emosional ing hackathon wis dhuwur banget, nganti jam 8 esuk aku nulis ing obrolan timku (tim kerja, dudu tim hackathon) yen aku njupuk dina kanthi biaya dhewe, lan menyang pusat. kantor kanggo pitches. Masalah kita dadi akeh ilmuwan data murni, lan iki mengaruhi pendekatan kanggo ngrampungake masalah kasebut. Akeh sing duwe DS sing apik, nanging ora ana sing duwe prototipe sing bisa digunakake, akeh sing ora bisa ngubengi larangan crawler ing mesin telusur. Kita mung tim sing duwe prototipe kerja. Lan kita ngerti carane ngatasi masalah kasebut. Pungkasane, kita menangake trek kasebut, sanajan kita seneng banget amarga milih tugas sing paling kompetitif. Ndeleng pitches ing trek liyane, kita nyadari yen kita ora bakal duwe kesempatan ing kana. Aku uga pengin ujar manawa kita seneng banget karo juri; dheweke mriksa kode kasebut kanthi teliti. Lan, miturut review, iki ora kedadeyan ing kabeh trek.
9. Pamungkas. Sawise kita padha disebut juri kaping pirang-pirang kanggo review kode, kita, mikir sing pungkasanipun mantun kabeh masalah, banjur nedha awan ing Burger King. Ing kana, panitia nelpon maneh, kudu cepet-cepet ngemas pesenan lan bali.
Penyelenggara nuduhake kamar sing kudu dituju, lan nalika mlebu, kita ketemu ing sesi latihan pidato umum kanggo tim sing menang. Wong-wong sing kudune tampil ing panggung wis diisi kanthi apik, kabeh metu kaya pemain pertunjukan.
Lan aku kudu ngakoni, ing final, nglawan latar mburi tim paling kuat saka trek liyane, kita katon pucet; kamenangan ing nominasi pelanggan pemerintah cukup pantes kanggo tim saka trek teknologi real estate. Aku mikir yen faktor kunci sing nyumbang kanggo kamenangan kita ing trek yaiku: kasedhiyan kosong sing wis siap, amarga kita bisa nggawe prototipe kanthi cepet, anané "highlights" ing prototipe (search for CEOs ing jaringan sosial) lan katrampilan NLP saka backender kita, sing uga narik kawigaten para juri.
Lan ing kesimpulan, thanks tradisional kanggo kabeh wong sing ndhukung kita, juri trek kita, Evgeniy Evgrafiev (penulis masalah sing kita ditanggulangi ing hackathon) lan mesthi penyelenggara hackathon. Iki mbok menawa hackathon paling gedhe lan paling keren sing aku nate melu, aku mung bisa pengin wong lanang supaya standar dhuwur ing mangsa ngarep!
Source: www.habr.com