Nama saya Dmitry. Dan saya ingin berbicara tentang bagaimana tim kami mencapai final hackathon Urban Tech Challenge di jalur Big Data. Saya harus segera mengatakan bahwa ini bukan hackathon pertama yang saya ikuti, dan bukan hackathon pertama yang saya ambil hadiahnya. Dalam hal ini, dalam cerita saya, saya ingin menyuarakan beberapa pengamatan umum dan kesimpulan mengenai industri hackathon secara keseluruhan, dan memberikan sudut pandang saya dibandingkan dengan ulasan negatif yang muncul online segera setelah berakhirnya Urban Tech Challenge (untuk contoh ).
Jadi pertama-tama beberapa pengamatan umum.
1. Mengejutkan bahwa banyak orang yang secara naif berpikir bahwa hackathon adalah sejenis kompetisi olahraga yang dimenangkan oleh pembuat kode terbaik. Ini salah. Saya tidak mempertimbangkan kasus ketika penyelenggara hackathon sendiri tidak tahu apa yang mereka inginkan (saya juga pernah melihatnya). Namun, sebagai aturan, perusahaan yang menyelenggarakan hackathon memiliki tujuan sendiri. Daftarnya mungkin berbeda: bisa berupa solusi teknis untuk beberapa masalah, pencarian ide dan orang baru, dll. Sasaran ini sering kali menentukan format acara, waktunya, online/offline, bagaimana tugas akan dirumuskan (dan apakah akan dirumuskan), apakah akan ada tinjauan kode di hackathon, dll. Baik tim maupun apa yang mereka lakukan dinilai dari sudut pandang ini. Dan tim-tim yang paling mencapai titik yang dibutuhkan perusahaan akan menang, dan banyak yang mencapai titik ini secara tidak sadar dan tidak sengaja, mengira bahwa mereka benar-benar berpartisipasi dalam kompetisi olahraga. Pengamatan saya menunjukkan bahwa untuk memotivasi peserta, penyelenggara setidaknya harus menciptakan tampilan lingkungan olahraga dan kondisi yang setara, jika tidak maka mereka akan mendapat gelombang negatif, seperti ulasan di atas. Tapi kami ngelantur.
2. Oleh karena itu kesimpulan berikut. Pihak penyelenggara tertarik dengan peserta yang datang ke hackathon dengan membawa karyanya sendiri, bahkan terkadang mereka secara khusus menyelenggarakan tahap korespondensi online untuk keperluan tersebut. Hal ini memungkinkan solusi keluaran yang lebih kuat. Konsep "pekerjaan sendiri" adalah konsep yang sangat relatif; setiap pengembang berpengalaman dapat mengumpulkan ribuan baris kode dari proyek lamanya pada komitmen pertamanya. Dan apakah ini akan menjadi perkembangan yang telah dipersiapkan sebelumnya? Namun bagaimanapun juga, aturan tersebut berlaku, yang saya ungkapkan dalam bentuk meme terkenal:
Untuk menang, Anda harus memiliki sesuatu, semacam keunggulan kompetitif: proyek serupa yang Anda lakukan di masa lalu, pengetahuan dan pengalaman dalam topik tertentu, atau pekerjaan siap pakai yang diselesaikan sebelum dimulainya hackathon. Ya, itu bukan olahraga. Ya, ini mungkin tidak sebanding dengan usaha yang dikeluarkan (di sini, setiap orang memutuskan sendiri apakah layak melakukan coding selama 3 minggu di malam hari untuk mendapatkan hadiah 100 ribu, dibagi di antara seluruh tim, dan bahkan dengan risiko tidak mendapatkannya). Namun seringkali, ini adalah satu-satunya kesempatan untuk maju.
3. Pemilihan tim. Seperti yang saya perhatikan dalam obrolan hackathon, banyak orang yang menangani masalah ini dengan sembrono (walaupun ini adalah keputusan paling penting yang akan menentukan hasil Anda di hackathon). Di banyak bidang kegiatan (baik dalam olah raga maupun hackathon) Saya telah melihat bahwa orang yang kuat cenderung bersatu dengan yang kuat, yang lemah dengan yang lemah, yang pintar dengan yang pintar, nah, secara umum, Anda mengerti... Ini kira-kira apa yang terjadi dalam obrolan: pemrogram yang kurang kuat segera diambil, orang-orang yang tidak memiliki keterampilan apa pun yang berharga untuk hackathon bertahan lama dalam obrolan dan memilih tim dengan prinsip bahwa jika saja seseorang mau mengambilnya . Di beberapa hackathon, penugasan acak ke tim dipraktikkan, dan penyelenggara mengklaim bahwa kinerja tim acak tidak lebih buruk daripada tim yang sudah ada. Namun menurut pengamatan saya, orang-orang yang termotivasi biasanya mencari tim sendiri, jika harus ada yang ditugaskan, seringkali banyak dari mereka yang tidak datang ke hackathon.
Adapun komposisi tim sangat individual dan sangat bergantung pada tugas. Saya dapat mengatakan bahwa komposisi tim minimum yang layak adalah seorang desainer - front-end atau front-end - back-end. Namun saya juga mengetahui kasus ketika tim yang hanya terdiri dari front-end menang, yang menambahkan back-end sederhana di node.js, atau membuat aplikasi seluler di React Native; atau hanya dari backender yang melakukan layout sederhana. Secara umum, semuanya sangat individual dan bergantung pada tugasnya. Rencana saya dalam memilih tim untuk hackathon adalah sebagai berikut: Saya berencana untuk membentuk tim atau bergabung dengan tim seperti front-end - back-end - designer (saya sendiri adalah front-end). Dan dengan cepat saya mulai mengobrol dengan backender python dan seorang desainer yang menerima undangan untuk bergabung dengan kami. Beberapa saat kemudian, seorang gadis, seorang analis bisnis, yang sudah memiliki pengalaman memenangkan hackathon, bergabung dengan kami, dan ini memutuskan masalah dia untuk bergabung dengan kami. Setelah pertemuan singkat, kami memutuskan untuk menamakan diri kami U4 (URBAN 4, urban four) dengan analogi dengan Fantastic Four. Dan mereka bahkan memasang gambar yang sesuai di avatar saluran telegram kami.
4. Memilih tugas. Seperti yang sudah saya katakan, Anda harus memiliki keunggulan kompetitif, tugas hackathon dipilih berdasarkan ini. Berdasarkan ini, setelah melihat dan menilai kompleksitasnya, kami menyelesaikan dua tugas: katalog perusahaan inovatif dari DPiIR dan chatbot dari EFKO. Tugas dari DPIiR dipilih oleh backender, tugas dari EFKO dipilih oleh saya, karena memiliki pengalaman menulis chatbots di node.js dan DialogFlow. Tugas EFKO juga melibatkan ML; Saya memiliki beberapa pengalaman, meskipun tidak terlalu luas, dalam ML. Dan berdasarkan kondisi masalahnya, menurut saya masalah tersebut tidak mungkin diselesaikan menggunakan alat ML. Perasaan ini diperkuat ketika saya menghadiri pertemuan Urban Tech Challenge, di mana penyelenggara menunjukkan kepada saya kumpulan data tentang EFKO, yang berisi sekitar 100 foto tata letak produk (diambil dari berbagai sudut) dan sekitar 20 kelas kesalahan tata letak. Dan, pada saat yang sama, mereka yang memerintahkan tugas tersebut ingin mencapai tingkat keberhasilan klasifikasi sebesar 90%. Hasilnya, saya menyiapkan presentasi solusi tanpa ML, backender menyiapkan presentasi berdasarkan katalog, dan bersama-sama, setelah menyelesaikan presentasi, kami mengirimkannya ke Urban Tech Challenge. Pada tahap ini sudah terungkap tingkat motivasi dan kontribusi masing-masing peserta. Desainer kami tidak ikut berdiskusi, terlambat merespon, bahkan mengisi informasi tentang dirinya dalam presentasi di saat-saat terakhir, secara umum timbul keraguan.
Hasilnya, kami lulus tugas dari DPiIR, dan sama sekali tidak kecewa karena kami tidak lulus EFKO, karena tugas itu terasa aneh bagi kami, secara halus.
5. Mempersiapkan hackathon. Ketika akhirnya diketahui bahwa kami lolos ke hackathon, kami mulai mempersiapkan persiapannya. Dan di sini saya tidak menganjurkan untuk mulai menulis kode seminggu sebelum dimulainya hackathon. Minimal, Anda harus memiliki boilerplate yang siap, yang dengannya Anda dapat segera mulai bekerja, tanpa harus mengonfigurasi alat, dan tanpa menemui bug dari beberapa lib yang Anda putuskan untuk dicoba pertama kali di hackathon. Saya tahu cerita tentang insinyur sudut yang datang ke hackathon dan menghabiskan 2 hari menyiapkan pembangunan proyek, jadi semuanya harus dipersiapkan sebelumnya. Kami bermaksud untuk mendistribusikan tanggung jawab sebagai berikut: backender menulis crawler yang menjelajahi Internet dan memasukkan semua informasi yang dikumpulkan ke dalam database, sementara saya menulis API di node.js yang menanyakan database ini dan mengirimkan data ke depan. Dalam hal ini, saya menyiapkan server terlebih dahulu menggunakan express.js dan menyiapkan front-end sebagai reaksi. Saya tidak menggunakan CRA, saya selalu menyesuaikan webpack untuk diri saya sendiri dan saya tahu betul risiko apa yang bisa ditimbulkannya (ingat cerita tentang pengembang sudut). Pada titik ini, saya meminta templat antarmuka atau setidaknya maket dari desainer kami untuk mendapatkan gambaran tentang apa yang akan saya tata. Secara teori, dia juga harus membuat persiapan sendiri dan mengoordinasikannya dengan kami, tapi saya tidak pernah mendapat jawaban. Hasilnya, saya meminjam desain dari salah satu proyek lama saya. Dan itu mulai berjalan lebih cepat, karena semua gaya untuk proyek ini telah ditulis. Oleh karena itu kesimpulannya: seorang desainer tidak selalu dibutuhkan dalam sebuah tim))). Kami datang ke hackathon dengan perkembangan ini.
6. Bekerja di hackathon. Pertama kali saya melihat tim saya secara live hanya pada pembukaan hackathon di Central Distribution Center. Kami bertemu, berdiskusi tentang solusi dan tahapan pengerjaan masalah tersebut. Dan walaupun setelah pembukaan kami harus naik bus ke Red October, kami pulang tidur, setuju untuk tiba di tempat itu pada jam 9.00. Mengapa? Pihak penyelenggara rupanya ingin memaksimalkan peserta sehingga mengatur jadwal seperti itu saja. Tapi, menurut pengalaman saya, Anda bisa membuat kode secara normal tanpa tidur selama satu malam. Sedangkan untuk yang kedua, saya tidak yakin lagi. Hackathon adalah maraton, Anda perlu menghitung dan merencanakan kekuatan Anda secara memadai. Apalagi kami sudah melakukan persiapan.
Oleh karena itu, setelah tidur, pada jam 9.00 kami sudah duduk di lantai enam Dewokrasi. Kemudian desainer kami tiba-tiba mengumumkan bahwa dia tidak memiliki laptop dan dia akan bekerja dari rumah, dan kami akan berkomunikasi melalui telepon. Ini adalah pukulan terakhir. Jadi kami berubah dari empat menjadi tiga, meski kami tidak mengubah nama tim. Sekali lagi, ini bukan pukulan besar bagi kami; saya sudah memiliki desain dari proyek lama. Secara umum, pada awalnya semuanya berjalan cukup lancar dan sesuai rencana. Kami memuat ke dalam database (kami memutuskan untuk menggunakan neo4j) kumpulan data perusahaan inovatif dari penyelenggara. Saya mulai mengetik, lalu menggunakan node.js, dan kemudian segalanya mulai macet. Saya belum pernah bekerja dengan neo4j sebelumnya, dan pada awalnya saya mencari driver yang berfungsi untuk database ini, kemudian saya menemukan cara menulis kueri, dan kemudian saya terkejut menemukan bahwa database ini, ketika ditanya, mengembalikan entitas di bentuk array objek node dan tepinya. Itu. ketika saya meminta sebuah organisasi dan semua data di dalamnya dengan TIN, alih-alih satu objek organisasi, saya dikembalikan serangkaian objek panjang yang berisi data tentang organisasi ini dan hubungan di antara mereka. Saya menulis mapper yang menelusuri seluruh array dan menempelkan semua objek sesuai dengan organisasinya ke dalam satu objek. Namun dalam pertempuran, ketika meminta database 8 ribu organisasi, itu dieksekusi dengan sangat lambat, sekitar 20 - 30 detik. Saya mulai berpikir tentang pengoptimalan... Lalu kami berhenti tepat waktu dan beralih ke MongoDB, dan kami membutuhkan waktu sekitar 30 menit. Secara total, sekitar 4 jam hilang di neo5j.
Ingat, jangan pernah membawa teknologi ke hackathon yang tidak Anda kenal, mungkin ada kejutan. Namun secara umum, terlepas dari kegagalan ini, semuanya berjalan sesuai rencana. Dan pada pagi hari tanggal 9 Desember, kami memiliki aplikasi yang berfungsi penuh. Untuk sisa hari itu kami berencana menambahkan fitur tambahan ke dalamnya. Di masa depan, semuanya berjalan relatif lancar bagi saya, tetapi backender memiliki banyak masalah dengan larangan perayapnya di mesin pencari, dalam spam agregator badan hukum, yang berada di urutan pertama hasil pencarian saat meminta untuk setiap perusahaan tertentu. Tapi lebih baik dia menceritakannya sendiri. Fitur tambahan pertama yang saya tambahkan adalah pencarian berdasarkan nama lengkap. Direktur Jenderal VKontakte. Butuh beberapa jam.
Jadi, di halaman perusahaan di aplikasi kita, avatar direktur umum muncul, tautan ke halaman VKontakte-nya, dan beberapa data lainnya. Itu adalah hasil yang bagus, meskipun itu mungkin tidak memberi kami kemenangan. Lalu, saya ingin menjalankan beberapa analisis. Namun setelah lama mencari opsi (ada banyak perbedaan pada UI), saya memilih agregasi organisasi yang paling sederhana berdasarkan kode aktivitas ekonomi. Sore harinya, di jam-jam terakhir, saya sedang membuat template untuk menampilkan produk-produk inovatif (di aplikasi kita seharusnya ada bagian Produk dan Layanan), meskipun backend belum siap untuk ini. Pada saat yang sama, database membengkak dengan pesat, crawler terus bekerja, backender bereksperimen dengan NLP untuk membedakan teks inovatif dari teks non-inovatif))). Namun waktu presentasi akhir sudah semakin dekat.
7. Presentasi. Dari pengalaman saya sendiri, saya dapat mengatakan bahwa Anda sebaiknya beralih ke mempersiapkan presentasi sekitar 3 hingga 4 jam sebelum waktunya. Apalagi jika menyangkut video, pengambilan gambar dan pengeditannya memakan waktu yang cukup lama. Kami seharusnya punya video. Dan kami memiliki orang khusus yang menangani hal ini, dan juga menyelesaikan sejumlah masalah organisasi lainnya. Dalam hal ini, kami tidak mengalihkan perhatian kami dari coding hingga saat-saat terakhir.
8. Lapangan. Saya kurang suka presentasi dan final diadakan pada hari kerja terpisah (Senin). Di sini, kemungkinan besar, kebijakan penyelenggara untuk memaksimalkan peserta terus berlanjut. Saya tidak berencana mengambil cuti kerja, saya hanya ingin mencapai final, meskipun anggota tim saya yang lain mengambil cuti. Namun, pencelupan emosional dalam hackathon sudah begitu tinggi sehingga pada jam 8 pagi saya menulis di chat tim saya (tim kerja, bukan tim hackathon) bahwa saya menghabiskan hari itu dengan biaya sendiri, dan pergi ke pusat kantor untuk pitching. Masalah kita ternyata memiliki banyak ilmuwan data murni, dan ini sangat mempengaruhi pendekatan pemecahan masalah. Banyak yang memiliki DS yang bagus, tetapi tidak ada yang memiliki prototipe yang berfungsi, banyak yang tidak dapat mengatasi larangan crawler mereka di mesin pencari. Kami adalah satu-satunya tim dengan prototipe yang berfungsi. Dan kami tahu bagaimana memecahkan masalah tersebut. Pada akhirnya, kami memenangkan lintasan tersebut, meskipun kami sangat beruntung karena kami memilih tugas yang paling tidak kompetitif. Melihat lapangan di trek lain, kami menyadari bahwa kami tidak memiliki peluang di sana. Saya juga ingin mengatakan bahwa kami sangat beruntung dengan juri, mereka dengan cermat memeriksa kodenya. Dan, dilihat dari ulasannya, hal ini tidak terjadi di semua trek.
9. Terakhir. Setelah kami dipanggil ke juri beberapa kali untuk tinjauan kode, kami berpikir bahwa kami akhirnya telah menyelesaikan semua masalah, pergi makan siang di Burger King. Disana panitia memanggil kami lagi, kami harus segera mengemas pesanan kami dan kembali.
Penyelenggara menunjukkan kepada kami ruangan mana yang harus kami masuki, dan setelah masuk, kami mendapati diri kami berada di sesi pelatihan berbicara di depan umum untuk tim pemenang. Orang-orang yang seharusnya tampil di atas panggung mendapat bayaran yang bagus, semua orang tampil seperti pemain sandiwara sungguhan.
Dan harus saya akui, di final, dengan latar belakang tim-tim terkuat dari jalur lain, kami tampak pucat; kemenangan dalam nominasi pelanggan pemerintah sepatutnya jatuh ke tangan tim dari jalur teknologi real estate. Menurut saya faktor kunci yang berkontribusi terhadap kemenangan kami di lintasan adalah: ketersediaan blanko yang sudah jadi, sehingga kami dapat dengan cepat membuat prototipe, adanya βsorotanβ dalam prototipe (mencari CEO di jejaring sosial) dan keterampilan NLP backender kami, yang juga sangat menarik minat juri.
Dan sebagai penutup, terima kasih yang sebesar-besarnya kepada semua pihak yang mendukung kami, juri lintasan kami, Evgeniy Evgrafiev (penulis masalah yang kami selesaikan di hackathon) dan tentu saja penyelenggara hackathon. Ini mungkin hackathon terbesar dan terkeren yang pernah saya ikuti, saya hanya bisa berharap mereka dapat mempertahankan standar tinggi di masa depan!
Sumber: www.habr.com