Nama saya Dmitry. Dan saya ingin berbicara tentang bagaimana tim kami mencapai final Urban Tech Challenge hackathon di jalur Big Data. Saya harus segera mengatakan bahwa ini bukan hackathon pertama di mana saya berpartisipasi, dan bukan yang pertama di mana saya memenangkan hadiah. Dalam hal ini, dalam cerita saya, saya ingin menyuarakan beberapa pengamatan umum dan kesimpulan mengenai industri hackathon secara keseluruhan, dan memberikan sudut pandang saya yang bertentangan dengan ulasan negatif yang muncul di jaringan segera setelah akhir Urban Tech Challenge (misalnya yang
ini ).
Jadi, pertama, beberapa pengamatan umum.
1. Mengejutkan bahwa beberapa orang secara naif berpikir bahwa hackathon adalah sejenis kompetisi olahraga di mana coders terbaik menang. Ini tidak benar. Saya tidak mempertimbangkan kasus ketika penyelenggara hackathon sendiri tidak tahu apa yang mereka inginkan (saya melihat ini juga). Tetapi, sebagai suatu peraturan, sebuah perusahaan yang mengatur hackathon mengejar tujuannya. Daftar mereka bisa berbeda: itu bisa menjadi solusi teknis untuk beberapa masalah, mencari ide dan orang baru, dll. Sasaran ini sering menentukan format acara, waktunya, online / offline, bagaimana tugas akan dirumuskan (dan apakah akan dirumuskan sama sekali), apakah akan ada tinjauan kode pada hackathon, dll. Baik tim dan apa yang mereka lakukan dievaluasi dengan tepat dari sudut pandang ini. Dan tim-tim yang paling baik sampai pada titik yang dibutuhkan oleh perusahaan menang, dan banyak yang sampai pada titik ini sepenuhnya secara tidak sadar dan tidak sengaja, berpikir bahwa mereka benar-benar berpartisipasi dalam kompetisi olahraga. Pengamatan saya menunjukkan bahwa untuk memotivasi peserta, penyelenggara harus membuat setidaknya penampilan lingkungan olahraga dan kondisi yang sama, jika tidak mereka akan menerima gelombang negatif, seperti dalam ulasan di atas. Tapi kami tersesat.
2. Oleh karena itu kesimpulan berikut. Panitia tertarik pada peserta yang datang ke hackathon dengan ide-ide mereka sendiri, kadang-kadang bahkan tahap korespondensi online secara khusus diatur untuk ini. Ini memungkinkan solusi keluaran yang lebih kuat. Konsep "pekerjaan mereka sendiri" sangat relatif, setiap programmer yang berpengalaman dapat mengumpulkan ribuan baris kode dari proyek-proyek lamanya di komit pertama. Dan apakah ini akan menjadi waktu operasi yang sudah disiapkan sebelumnya? Tetapi bagaimanapun juga, aturannya berlaku, yang saya ungkapkan dalam bentuk meme terkenal:
Untuk menang, Anda harus memiliki sesuatu, semacam keunggulan kompetitif: proyek serupa yang pernah Anda lakukan di masa lalu, pengetahuan dan pengalaman dalam topik tertentu, atau pekerjaan yang sudah selesai dilakukan sebelum dimulainya hackathon. Ya, itu bukan olahraga. Ya, ini mungkin tidak membayar upaya (di sini semua orang memutuskan apakah kode 3 minggu di malam hari untuk hadiah 100 ribu, dibagi oleh seluruh tim, dan bahkan dengan risiko tidak mendapatkannya). Tetapi, seringkali, ini adalah satu-satunya kesempatan untuk maju.
3. Pemilihan tim. Seperti yang saya perhatikan dari obrolan hackathon, banyak orang mengambil masalah ini dengan agak ringan (walaupun, ini adalah keputusan paling penting yang akan menentukan hasil Anda di hackathon). Dalam banyak bidang kegiatan (baik dalam olahraga dan hackathon) saya melihat bahwa orang yang kuat cenderung bersatu dengan yang kuat, yang lemah dengan yang lemah, yang pintar dengan yang pintar, yah, secara umum, Anda mengerti ... Inilah yang terjadi di ruang obrolan: programmer yang kurang lebih kuat segera, orang-orang yang tidak memiliki keterampilan hackathon yang berharga bertahan dalam obrolan untuk waktu yang lama dan memilih tim sesuai dengan prinsip jika hanya seseorang yang mengambilnya. Di beberapa hackathon, distribusi acak di antara tim dipraktikkan, dan panitia mengklaim bahwa tim acak menunjukkan hasilnya tidak lebih buruk daripada yang sudah ada. Tetapi menurut pengamatan saya, orang-orang yang termotivasi, sebagai aturan, menemukan tim itu sendiri, jika seseorang harus dibagikan, maka sering kali banyak dari mereka tidak datang ke hackathon.
Adapun komposisi tim, sangat individual dan sangat tergantung pada tugas. Saya bisa mengatakan bahwa tim yang layak minimum adalah desainer - front-end atau front-end - back-end. Tapi saya juga tahu kasus ketika tim yang hanya terdiri dari front-endors menang, yang melampirkan back-end sederhana ke node.js, atau membuat aplikasi mobile di React Native; atau hanya dari beckender yang membuat tata letak sederhana. Secara umum, semuanya sangat individual dan tergantung pada tugas. Rencana saya untuk memilih tim untuk hackathon adalah sebagai berikut: Saya berencana untuk membentuk tim atau bergabung dengan tim seperti desainer front-end-back-end (saya sendiri di depan). Dan dengan cepat dia mulai mengobrol dengan python back-end dan seorang desainer yang menerima undangan untuk bergabung dengan kami. Beberapa saat kemudian, seorang gadis analis bisnis bergabung dengan kami, yang sudah memiliki pengalaman memenangkan hackathon, dan ini memutuskan masalah dia bergabung dengan kami. Setelah pertemuan singkat, kami memutuskan untuk menyebut diri kami U4 (URBAN 4, urban four) mirip dengan empat yang fantastis. Dan mereka bahkan memasang gambar yang sesuai di saluran telegram kami.
4. Pilihan tugas. Seperti yang saya katakan, Anda harus memiliki keunggulan kompetitif, tugas hackathon dipilih berdasarkan ini. Melanjutkan hal ini, setelah melihat
daftar tugas dan menilai kerumitannya, kami menyelesaikan dua tugas: katalog perusahaan inovatif dari DPiIR dan bot obrolan dari EFKO. Tugas dari Institut Pengembangan Industri dan Industri dipilih oleh backender, tugas dari EFKO dipilih oleh saya, karena punya pengalaman menulis chatbots di node.js dan DialogFlow. Tugas EFKO juga melibatkan ML, saya punya beberapa, tidak terlalu besar, pengalaman dalam ML. Dan sesuai dengan kondisi masalah, menurut saya itu hampir tidak diselesaikan melalui ML. Perasaan ini menguat ketika saya pergi ke pertemuan Urban Tech Challenge, di mana panitia menunjukkan saya set data EFCO, di mana ada sekitar 100 foto tata letak produk (diambil dari sudut yang berbeda) dan sekitar 20 kelas kesalahan tata letak. Dan pada saat yang sama, pelanggan tugas menginginkan tingkat keberhasilan klasifikasi 90%. Sebagai hasilnya, saya menyiapkan presentasi solusi tanpa ML, backender menyiapkan presentasi sesuai dengan katalog, dan bersama-sama, setelah menyelesaikan presentasi, kami mengirimnya ke Urban Tech Challenge. Sudah pada tahap ini, tingkat motivasi dan kontribusi masing-masing peserta terungkap. Perancang kami tidak ambil bagian dalam diskusi, menjawab terlambat dan bahkan mengisi informasi tentang dirinya dalam presentasi pada saat terakhir, pada umumnya timbul keraguan.
Sebagai hasilnya, kami mengerjakan tugas dari Departemen Konstruksi dan Desain, dan sama sekali tidak kesal karena kami tidak pergi melalui EFKO, karena tugas itu bagi kami, untuk membuatnya agak, aneh.
5. Persiapan untuk hackathon. Ketika akhirnya diketahui bahwa kami pergi ke hackathon, kami mulai menyiapkan benda kerja. Dan di sini saya tidak mendesak Anda untuk mulai menulis kode seminggu sebelum dimulainya hackathon. Minimal, Anda harus menyiapkan pelat ketel, yang dengannya Anda dapat segera mulai bekerja tanpa harus menyetel alat, dan tanpa menabrak bug apa pun yang Anda putuskan untuk coba pertama kali menggunakan hackathon. Saya tahu cerita tentang pemancing yang datang ke hackathon dan menghabiskan 2 hari menyiapkan perakitan proyek, jadi semuanya harus disiapkan terlebih dahulu. Kami seharusnya mendistribusikan tugas sebagai berikut: bekender menulis perayap yang memindai Internet dan menaruh semua informasi yang dikumpulkan dalam basis data, saya menulis API pada node.js, yang meminta basis data ini dan mengirimkan data ke depan. Dalam hal ini, saya menyiapkan server terlebih dahulu di express.js, dan menyiapkan frontend untuk bereaksi. Saya tidak menggunakan CRA, saya selalu menyesuaikan webpack untuk diri saya dan saya tahu betul risiko apa yang mungkin terjadi (kita ingat cerita tentang pemancing). Saat ini, saya meminta antarmuka kosong, atau setidaknya mockup dari desainer kami, untuk memiliki gagasan tentang apa yang akan saya terapkan. Secara teori, dia juga harus membuat persiapan dan mengoordinasikannya dengan kita, tetapi saya tidak pernah menerima jawaban. Akibatnya, saya meminjam desain dari salah satu proyek lama saya. Dan jadi mulai menjadi lebih cepat, karena semua gaya untuk proyek ini sudah ditulis. Oleh karena itu kesimpulannya: desainer tidak selalu diperlukan dalam tim))). Dengan perkembangan ini, kami sampai di hackathon.
6. Kerjakan hackathon. Saya pertama kali melihat tim saya hidup hanya pada pembukaan hackathon di CDP. Kami bertemu, membahas solusi dan tahapan pekerjaan pada tugas. Dan meskipun setelah pembukaan kami harus naik bus ke Red October, kami pulang untuk tidur, setelah setuju untuk datang ke tempat kami pada jam 9.00. Mengapa Panitia, tampaknya, ingin memeras para peserta, sehingga mereka mengatur jadwal seperti itu. Tapi, dalam pengalaman saya, Anda biasanya dapat kode tanpa tidur satu malam. Sedangkan untuk yang kedua, saya tidak yakin lagi. Hackathon adalah maraton, Anda perlu menghitung dan merencanakan kekuatan Anda secara memadai. Apalagi kami punya yang kosong.
Karena itu, setelah tidur, jam 9.00 kami duduk di lantai enam Dewocracy. Kemudian desainer kami tiba-tiba mengumumkan bahwa ia tidak memiliki laptop, dan bahwa ia akan bekerja dari rumah, dan kami akan berkomunikasi melalui telepon. Ini sedotan terakhir. Jadi kami beralih dari empat menjadi tiga, meskipun kami tidak mengubah nama tim. Sekali lagi, ini tidak menjadi pukulan kuat bagi kami, saya sudah memiliki desain dari proyek lama. Secara umum, pada awalnya semuanya berjalan dengan lancar dan sesuai rencana. Kami telah mengunggah setumpuk perusahaan inovatif dari penyelenggara ke dalam basis data (kami memutuskan untuk menggunakan neo4j). Saya mulai mengeset, kemudian mengambil node.js, dan kemudian gagal. Saya belum pernah bekerja dengan neo4j sebelumnya, dan pertama saya mencari driver yang berfungsi untuk database ini, kemudian saya mencari tahu bagaimana query ditulis, dan kemudian saya terkejut menemukan bahwa database ini mengembalikan entitas ketika diminta, sebagai array dari objek node dan tepi mereka. Yaitu ketika saya meminta organisasi dengan TIN dan semua data di dalamnya, alih-alih objek organisasi tunggal, saya mengembalikan array panjang objek yang berisi data pada organisasi ini dan hubungan di antara mereka. Saya menulis mapper yang melintasi seluruh array dan menempelkan semua objek dalam organisasi menjadi satu objek. Tetapi dalam pertempuran, ketika menanyakan database 8.000 organisasi, itu sangat lambat selama sekitar 20-30 detik. Saya memikirkan pengoptimalan ... Lalu kami berhenti tepat waktu dan pindah ke MongoDB, dan kami butuh sekitar 30 menit. Total sekitar 5 jam hilang pada neo4j.
Ingat, jangan pernah menggunakan teknologi hackathon yang tidak Anda kenal, mungkin ada kejutan. Tetapi, secara umum, terlepas dari kegagalan ini, semuanya berjalan sesuai rencana. Dan sudah pada pagi hari tanggal 9 Desember kami memiliki aplikasi yang berfungsi penuh. Untuk sisa hari itu, kami berencana untuk memutar fitur tambahan di atasnya. Di masa depan, semuanya berjalan relatif lancar, tetapi bekender memiliki banyak masalah dengan larangan perayapnya di mesin pencari, dalam spam agregator badan hukum, yang muncul di tempat pertama hasil pencarian ketika meminta setiap perusahaan tertentu. Tetapi tentang ini dia akan memberi tahu yang lebih baik. Fitur tambahan pertama yang saya mengacaukan adalah pencarian dengan nama lengkap CEO VKontakte. Butuh beberapa jam.
Jadi, pada halaman perusahaan di aplikasi kami muncul ava direktur umum, tautan ke halaman VK-nya dan beberapa data lainnya. Itu adalah ceri yang enak pada kue, meskipun itu mungkin tidak memberi kita kemenangan. Kemudian, saya ingin membuat beberapa analitik. Tetapi setelah pencarian opsi yang panjang (ada banyak nuansa dengan UI), ia menentukan agregasi organisasi yang paling sederhana berdasarkan kode aktivitas ekonomi. Sudah di malam hari, pada jam-jam terakhir, saya mengosongkan untuk menampilkan produk-produk inovatif (bagian Produk dan Layanan seharusnya dalam aplikasi kami), meskipun backend untuk ini belum siap. Basis pada saat yang sama bengkak oleh lompatan, perayap terus bekerja, back-end bereksperimen dengan NLP untuk membedakan teks inovatif dari yang tidak inovatif))). Tapi sudah waktunya untuk presentasi terakhir.
7. Presentasi. Dari pengalaman saya sendiri, saya dapat mengatakan bahwa Anda harus beralih ke menyiapkan presentasi di suatu tempat 3-4 jam sebelum pengirimannya. Apalagi jika video itu seharusnya ada di dalamnya, memotret dan mengeditnya membutuhkan banyak waktu. Kami seharusnya memiliki video. Dan kami memiliki orang khusus yang terlibat dalam hal ini, dan juga memecahkan sejumlah masalah organisasi lainnya. Dalam hal ini, sampai saat-saat terakhir, kami tidak terganggu dari pengkodean.
8. Pitch. Saya tidak suka bahwa presentasi dan final dibuat pada hari kerja yang terpisah (Senin). Di sini, kemungkinan besar, penyelenggara melanjutkan kebijakan memeras maksimal dari peserta. Saya tidak berencana untuk mengambil cuti dari pekerjaan, saya hanya ingin datang ke final, meskipun tim saya yang lain menghabiskan akhir pekan. Namun, perendaman emosional dalam hackathon sudah sangat tinggi sehingga pada jam 8 pagi saya menulis ke obrolan tim saya (bekerja, bukan tim hackathon) sehingga saya mengambil hari itu dengan biaya sendiri dan pergi ke CDC untuk pitches. Masalah kami ternyata banyak data ilmuwan murni dan ini sangat mempengaruhi pendekatan untuk memecahkan masalah. Banyak yang memiliki DS yang bagus, tetapi tidak ada yang memiliki prototipe yang berfungsi, banyak yang tidak bisa menghindari larangan perayap mereka di mesin pencari. Kami adalah satu-satunya tim dengan prototipe yang berfungsi. Dan kami tahu bagaimana menyelesaikan tugas itu. Pada akhirnya, kami memenangkan perlombaan, meskipun kami sangat beruntung bahwa kami memilih tugas yang paling tidak kompetitif. Melihat lapangan di trek lain, kami menyadari bahwa kami tidak akan memiliki kesempatan di sana. Saya juga ingin mengatakan bahwa kami sangat beruntung dengan juri, mereka dengan cermat memeriksa kodenya. Dan, dilihat dari ulasan, ini jauh dari terjadi di semua trek.
9. Final. Setelah kami dipanggil ke juri beberapa kali untuk tinjauan kode, kami berpikir bahwa kami akhirnya menyelesaikan semua masalah dan pergi makan malam di Burger King. Di sana, panitia memanggil kami lagi, kami harus buru-buru mengepak pesanan dan kembali.
Penyelenggara menunjukkan ruang mana yang harus dituju, dan, pergi ke sana, kami menemukan diri kami dalam pelatihan berbicara di depan umum untuk tim yang menang. Orang-orang yang seharusnya tampil di atas panggung diisi dengan baik, semua orang keluar sebagai pemain sandiwara nyata.
Dan harus saya akui, di final, dengan latar belakang tim terkuat dari trek lain, kami tampak pucat, kemenangan dalam nominasi pelanggan negara sepatutnya meninggalkan tim dari trek teknologi real estate. Saya berpikir bahwa faktor-faktor kunci yang berkontribusi pada kemenangan kami di trek adalah: ketersediaan blanko yang sudah jadi, karena kami dapat dengan cepat membuat prototipe, kehadiran "semangat" dalam prototipe (mencari direktur umum di jejaring sosial) dan keterampilan NLP dari pendukung kami yang juga sangat tertarik dengan juri.
Dan sebagai kesimpulan, terima kasih tradisional kepada semua yang mendukung kami, juri dari lagu kami, Evgeny Evgrafiev (penulis tugas yang kami selesaikan di hackathon) dan, tentu saja, kepada para penyelenggara hackathon. Ini mungkin hackathon terbesar dan paling keren yang pernah saya ikuti, tetap saja berharap para lelaki untuk mempertahankan merek setinggi itu dan banyak lagi!