Nama saya Dmitry. Dan saya ingin bercakap tentang cara pasukan kami mencapai peringkat akhir hackathon Urban Tech Challenge di landasan Big Data. Saya akan katakan dengan segera bahawa ini bukan hackathon pertama yang saya sertai, dan bukan yang pertama saya mengambil hadiah. Dalam hal ini, dalam cerita saya, saya ingin menyuarakan beberapa pemerhatian dan kesimpulan umum mengenai industri hackathon secara keseluruhan, dan memberikan pandangan saya berbanding ulasan negatif yang muncul dalam talian sebaik sahaja tamat Cabaran Teknologi Bandar (untuk contoh ).
Jadi pertama beberapa pemerhatian umum.
1. Sungguh menghairankan bahawa segelintir orang secara naif beranggapan bahawa hackathon ialah sejenis pertandingan sukan di mana pengkode terbaik menang. Ini adalah salah. Saya tidak menganggap kes apabila penganjur hackathon sendiri tidak tahu apa yang mereka mahu (saya juga pernah melihatnya). Tetapi, sebagai peraturan, syarikat yang menganjurkan hackathon mengejar matlamatnya sendiri. Senarai mereka mungkin berbeza: ia boleh menjadi penyelesaian teknikal kepada beberapa masalah, pencarian idea dan orang baharu, dsb. Matlamat ini selalunya menentukan format acara, masanya, dalam talian/luar talian, cara tugasan akan dirumuskan (dan sama ada ia akan dirumus sama sekali), sama ada akan ada semakan kod di hackathon, dsb. Kedua-dua pasukan dan apa yang mereka lakukan dinilai dari sudut pandangan ini. Dan pasukan-pasukan yang paling tepat mencapai titik yang syarikat perlukan untuk menang, dan ramai yang sampai ke tahap ini secara tidak sedar dan tidak sengaja, memikirkan bahawa mereka benar-benar menyertai pertandingan sukan. Pemerhatian saya menunjukkan bahawa untuk memotivasikan peserta, penganjur harus mewujudkan sekurang-kurangnya penampilan persekitaran sukan dan keadaan yang sama, jika tidak, mereka akan menerima gelombang negatif, seperti dalam ulasan di atas. Tetapi kita menyimpang.
2. Oleh itu kesimpulan berikut. Penganjur berminat untuk peserta datang ke hackathon dengan kerja mereka sendiri, kadang-kadang mereka juga menganjurkan peringkat surat-menyurat dalam talian untuk tujuan ini. Ini membolehkan penyelesaian keluaran yang lebih kukuh. Konsep "kerja sendiri" adalah sangat relatif; mana-mana pembangun berpengalaman boleh mengumpul beribu-ribu baris kod daripada projek lamanya dalam komitmen pertamanya. Dan adakah ini akan menjadi pembangunan yang telah disediakan terlebih dahulu? Tetapi dalam apa jua keadaan, peraturan itu terpakai, yang saya nyatakan dalam bentuk meme terkenal:
Untuk menang, anda mesti mempunyai sesuatu, sejenis kelebihan daya saing: projek serupa yang anda lakukan pada masa lalu, pengetahuan dan pengalaman dalam topik tertentu, atau kerja siap dibuat sebelum permulaan hackathon. Ya, ia tidak sukan. Ya, ini mungkin tidak berbaloi dengan usaha yang dibelanjakan (di sini, semua orang memutuskan sendiri sama ada ia bernilai pengekodan selama 3 minggu pada waktu malam untuk hadiah 100 ribu, dibahagikan kepada seluruh pasukan, dan walaupun dengan risiko tidak mendapatnya). Tetapi, selalunya, ini adalah satu-satunya peluang untuk maju.
3. Pemilihan pasukan. Seperti yang saya perhatikan dalam sembang hackathon, ramai yang mendekati isu ini dengan agak remeh (walaupun ini adalah keputusan paling penting yang akan menentukan keputusan anda di hackathon). Dalam banyak bidang aktiviti (sama ada dalam sukan dan dalam hackathon) saya telah melihat bahawa orang yang kuat cenderung untuk bersatu dengan yang kuat, yang lemah dengan yang lemah, yang pintar dengan yang pintar, secara umum, anda mendapat idea... Ini kira-kira apa yang berlaku dalam sembang: pengaturcara yang kurang kuat mereka segera ditangkap, orang yang tidak mempunyai apa-apa kemahiran yang berharga untuk hackathon menggantung dalam sembang untuk masa yang lama dan memilih pasukan berdasarkan prinsip bahawa jika seseorang akan mengambilnya . Di sesetengah hackathon, tugasan rawak kepada pasukan diamalkan, dan penganjur mendakwa bahawa pasukan rawak berprestasi tidak lebih buruk daripada yang sedia ada. Tetapi menurut pemerhatian saya, orang yang bermotivasi, sebagai peraturan, mencari pasukan sendiri jika seseorang perlu ditugaskan, maka, selalunya, ramai daripada mereka tidak datang ke hackathon.
Bagi komposisi pasukan, ini sangat individu dan sangat bergantung kepada tugas. Saya boleh katakan bahawa komposisi pasukan minimum yang berdaya maju ialah pereka - bahagian hadapan atau bahagian depan - bahagian belakang. Tetapi saya juga mengetahui tentang kes apabila pasukan yang hanya terdiri daripada front-end menang, yang menambah back-end mudah dalam node.js, atau membuat aplikasi mudah alih dalam React Native; atau hanya daripada backender yang melakukan susun atur mudah. Secara umum, semuanya sangat individu dan bergantung pada tugas. Rancangan saya untuk memilih pasukan untuk hackathon adalah seperti berikut: Saya merancang untuk memasang pasukan atau menyertai pasukan seperti front-end - back-end - designer (saya sendiri adalah front-end). Dan dengan pantas, saya mula berbual dengan ular sawa backender dan pereka yang menerima jemputan untuk menyertai kami. Tidak lama kemudian, seorang gadis, seorang penganalisis perniagaan, yang sudah berpengalaman memenangi hackathon, menyertai kami, dan ini memutuskan isu dia menyertai kami. Selepas pertemuan singkat, kami memutuskan untuk memanggil diri kami U4 (URBAN 4, empat bandar) dengan analogi dengan empat hebat. Dan mereka juga meletakkan gambar yang sepadan pada avatar saluran telegram kami.
4. Memilih tugas. Seperti yang telah saya katakan, anda mesti mempunyai kelebihan daya saing, tugas untuk hackathon dipilih berdasarkan ini. Berdasarkan ini, setelah melihat dan menilai kerumitannya, kami menyelesaikan dua tugas: katalog perusahaan inovatif daripada DPiIR dan bot sembang daripada EFKO. Tugas dari DPIiR dipilih oleh backender, tugas dari EFKO dipilih oleh saya, kerana mempunyai pengalaman menulis chatbots dalam node.js dan DialogFlow. Tugas EFKO juga melibatkan ML. Saya mempunyai beberapa, tidak begitu luas, pengalaman dalam ML. Dan mengikut keadaan masalah, nampaknya saya tidak mungkin menyelesaikannya menggunakan alat ML. Perasaan ini diperkuatkan apabila saya pergi ke pertemuan Cabaran Teknologi Bandar, di mana penganjur menunjukkan kepada saya set data pada EFKO, di mana terdapat kira-kira 100 foto susun atur produk (diambil dari sudut berbeza) dan kira-kira 20 kelas ralat susun atur. Dan, pada masa yang sama, mereka yang mengarahkan tugas itu ingin mencapai kadar kejayaan klasifikasi sebanyak 90%. Hasilnya, saya menyediakan pembentangan penyelesaian tanpa ML, backender menyediakan pembentangan berdasarkan katalog, dan bersama-sama, selepas memuktamadkan pembentangan, kami menghantarnya ke Cabaran Teknologi Bandar. Sudah pada peringkat ini, tahap motivasi dan sumbangan setiap peserta telah didedahkan. Pereka kami tidak mengambil bahagian dalam perbincangan, menjawab lewat, dan juga mengisi maklumat tentang dirinya dalam pembentangan pada saat terakhir, secara umum, keraguan timbul.
Akibatnya, kami lulus tugasan daripada DPiIR, dan sama sekali tidak kecewa kerana kami tidak lulus EFKO, kerana tugas itu kelihatan pelik kepada kami, secara ringkasnya.
5. Bersedia untuk hackathon. Apabila akhirnya diketahui bahawa kami telah layak untuk hackathon, kami mula menyediakan persiapan. Dan di sini saya tidak menganjurkan mula menulis kod seminggu sebelum permulaan hackathon. Sekurang-kurangnya, anda harus mempunyai boilerplate sedia, yang dengannya anda boleh mula bekerja dengan serta-merta, tanpa perlu mengkonfigurasi alat, dan tanpa terserempak dengan pepijat beberapa lib yang anda memutuskan untuk mencuba buat kali pertama di hackathon. Saya tahu cerita tentang jurutera sudut yang datang ke hackathon dan menghabiskan 2 hari menyediakan binaan projek, jadi segala-galanya harus disediakan lebih awal. Kami berhasrat untuk mengagihkan tanggungjawab seperti berikut: backender menulis perangkak yang menjelajah Internet dan meletakkan semua maklumat yang dikumpul dalam pangkalan data, sementara saya menulis API dalam node.js yang menanyakan pangkalan data ini dan menghantar data ke hadapan. Dalam hal ini, saya menyediakan pelayan terlebih dahulu menggunakan express.js dan menyediakan bahagian hadapan dalam tindak balas. Saya tidak menggunakan CRA, saya sentiasa menyesuaikan pek web untuk diri saya sendiri dan saya tahu betul apa risiko yang boleh ditimbulkan (ingat cerita tentang pembangun sudut). Pada ketika ini, saya meminta templat antara muka atau sekurang-kurangnya mockup daripada pereka bentuk kami untuk mendapatkan idea tentang apa yang akan saya susun. Secara teorinya, dia juga harus membuat persiapan sendiri dan menyelaraskannya dengan kami, tetapi saya tidak pernah mendapat jawapan. Akibatnya, saya meminjam reka bentuk daripada salah satu projek lama saya. Dan ia mula berfungsi dengan lebih pantas, kerana semua gaya untuk projek ini telah pun ditulis. Oleh itu kesimpulannya: pereka tidak selalu diperlukan dalam pasukan))). Kami datang ke hackathon dengan perkembangan ini.
6. Bekerja di hackathon. Kali pertama saya melihat pasukan saya secara langsung hanya pada pembukaan hackathon di Pusat Pengedaran Pusat. Kami bertemu, membincangkan penyelesaian dan peringkat menyelesaikan masalah. Dan walaupun selepas pembukaan kami terpaksa pergi dengan bas ke Red October, kami pulang ke rumah untuk tidur, bersetuju untuk tiba di tempat itu pada pukul 9.00. kenapa? Penganjur nampaknya ingin memanfaatkan sepenuhnya peserta, jadi mereka mengatur jadual sedemikian. Tetapi, dalam pengalaman saya, anda boleh mengekod secara normal tanpa tidur selama satu malam. Untuk yang kedua, saya tidak pasti lagi. Hackathon ialah maraton; anda perlu mengira dan merancang kekuatan anda dengan secukupnya. Lebih-lebih lagi, kami mempunyai persiapan.
Oleh itu, selepas tidur, pada pukul 9.00 kami duduk di tingkat enam Dewocracy. Kemudian pereka kami secara tidak dijangka mengumumkan bahawa dia tidak mempunyai komputer riba dan bahawa dia akan bekerja dari rumah, dan kami akan berkomunikasi melalui telefon. Ini adalah yang terakhir. Jadi kami bertukar daripada empat kepada tiga, walaupun kami tidak menukar nama pasukan. Sekali lagi, ini bukan tamparan besar bagi kami; Saya sudah mempunyai reka bentuk dari projek lama. Secara umumnya, pada mulanya semuanya berjalan dengan lancar dan mengikut perancangan. Kami memuatkan ke dalam pangkalan data (kami memutuskan untuk menggunakan neo4j) set data syarikat inovatif daripada penganjur. Saya mula menyusun taip, kemudian mengambil node.js, dan kemudian perkara mula tidak berfungsi. Saya tidak pernah bekerja dengan neo4j sebelum ini, dan pada mulanya saya sedang mencari pemacu yang berfungsi untuk pangkalan data ini, kemudian saya memikirkan cara menulis pertanyaan, dan kemudian saya terkejut apabila mendapati bahawa pangkalan data ini, apabila ditanya, mengembalikan entiti dalam bentuk susunan objek nod dan tepinya. Itu. apabila saya meminta organisasi dan semua data mengenainya oleh TIN, bukannya satu objek organisasi, saya telah dikembalikan pelbagai objek yang mengandungi data tentang organisasi ini dan hubungan antara mereka. Saya menulis pemeta yang melalui keseluruhan tatasusunan dan melekatkan semua objek mengikut organisasi mereka ke dalam satu objek. Tetapi dalam pertempuran, apabila meminta pangkalan data 8 ribu organisasi, ia dilaksanakan dengan sangat perlahan, kira-kira 20 - 30 saat. Saya mula memikirkan tentang pengoptimuman... Dan kemudian kami berhenti tepat pada masanya dan beralih kepada MongoDB, dan kami mengambil masa kira-kira 30 minit. Secara keseluruhan, kira-kira 4 jam telah hilang pada neo5j.
Ingat, jangan sekali-kali membawa teknologi ke hackathon yang anda tidak biasa, mungkin ada kejutan. Tetapi, secara umum, selain daripada kegagalan ini, semuanya berjalan mengikut rancangan. Dan sudah pada pagi 9 Disember, kami mempunyai permohonan yang berfungsi sepenuhnya. Untuk sepanjang hari kami merancang untuk menambah ciri tambahan padanya. Pada masa hadapan, semuanya berjalan dengan lancar untuk saya, tetapi backender mempunyai banyak masalah dengan larangan perangkaknya dalam enjin carian, dalam spam pengagregat entiti undang-undang, yang datang di tempat pertama hasil carian apabila meminta bagi setiap syarikat tertentu. Tetapi lebih baik dia menceritakannya sendiri. Ciri tambahan pertama yang saya tambah ialah carian mengikut nama penuh. Ketua Pengarah VKontakte. Ia mengambil masa beberapa jam.
Jadi, pada halaman syarikat dalam aplikasi kami, avatar pengarah besar muncul, pautan ke halaman VKontaktenya dan beberapa data lain. Ia adalah ceri yang bagus pada kek, walaupun ia mungkin tidak memberikan kami kemenangan. Kemudian, saya ingin menjalankan beberapa analisis. Tetapi selepas mencari pilihan yang panjang (terdapat banyak nuansa dengan UI), saya menetap pada pengagregatan organisasi yang paling mudah mengikut kod aktiviti ekonomi. Sudah pada waktu petang, dalam beberapa jam terakhir, saya telah meletakkan templat untuk memaparkan produk inovatif (dalam aplikasi kami sepatutnya terdapat bahagian Produk dan Perkhidmatan), walaupun bahagian belakang tidak bersedia untuk ini. Pada masa yang sama, pangkalan data membengkak dengan pesat, crawler terus berfungsi, backender bereksperimen dengan NLP untuk membezakan teks inovatif daripada yang tidak inovatif))). Tetapi masa untuk pembentangan akhir sudah menghampiri.
7. Pembentangan. Daripada pengalaman saya sendiri, saya boleh katakan bahawa anda harus beralih kepada menyediakan pembentangan kira-kira 3 hingga 4 jam sebelum tarikh tamat tempoh. Lebih-lebih lagi jika ia melibatkan video, penggambaran dan penyuntingannya mengambil masa yang agak lama. Kami sepatutnya mempunyai video. Dan kami mempunyai orang istimewa yang menangani perkara ini, dan juga menyelesaikan beberapa isu organisasi lain. Dalam hal ini, kami tidak mengalihkan perhatian kami daripada pengekodan sehingga saat terakhir.
8. Padang. Saya tidak suka pembentangan dan perlawanan akhir diadakan pada hari minggu yang berasingan (Isnin). Di sini, kemungkinan besar, dasar penganjur untuk memerah maksimum peserta diteruskan. Saya tidak bercadang untuk mengambil cuti dari kerja, saya hanya mahu datang ke peringkat akhir, walaupun seluruh pasukan saya mengambil cuti hujung minggu. Walau bagaimanapun, keterlibatan emosi dalam hackathon sudah begitu tinggi sehingga pada pukul 8 pagi saya menulis dalam sembang pasukan saya (pasukan kerja, bukan pasukan hackathon) bahawa saya mengambil hari itu dengan perbelanjaan saya sendiri, dan pergi ke pusat pejabat untuk padang. Masalah kami ternyata mempunyai ramai saintis data tulen, dan ini sangat mempengaruhi pendekatan untuk menyelesaikan masalah. Ramai yang mempunyai DS yang baik, tetapi tiada siapa yang mempunyai prototaip yang berfungsi, ramai yang tidak dapat mengatasi larangan perangkak mereka dalam enjin carian. Kami adalah satu-satunya pasukan yang mempunyai prototaip yang berfungsi. Dan kami tahu bagaimana untuk menyelesaikan masalah itu. Akhirnya, kami memenangi trek, walaupun kami sangat bertuah kerana kami memilih tugas yang paling tidak kompetitif. Melihat padang di trek lain, kami menyedari bahawa kami tidak akan mempunyai peluang di sana. Saya juga ingin mengatakan bahawa kami sangat bertuah dengan juri; mereka teliti memeriksa kod. Dan, berdasarkan ulasan, ini tidak berlaku dalam semua trek.
9. Akhir. Selepas beberapa kali kami dipanggil ke juri untuk semakan kod, kami, memikirkan bahawa kami akhirnya menyelesaikan semua isu, pergi makan tengah hari di Burger King. Di sana penganjur memanggil kami semula, kami perlu cepat mengemas pesanan kami dan balik.
Penganjur menunjukkan bilik mana yang perlu kami masuk, dan apabila masuk, kami mendapati diri kami berada di sesi latihan pengucapan awam untuk pasukan yang menang. Lelaki yang sepatutnya membuat persembahan di atas pentas sangat baik, semua orang keluar seperti pemain pertunjukan sebenar.
Dan saya harus mengakui, dalam perlawanan akhir, dengan berlatar belakangkan pasukan terkuat dari trek lain, kami kelihatan pucat kemenangan dalam pencalonan pelanggan kerajaan agak wajar diberikan kepada pasukan dari trek teknologi hartanah. Saya berpendapat bahawa faktor utama yang menyumbang kepada kemenangan kami di trek adalah: ketersediaan kosong siap, yang mana kami dapat membuat prototaip dengan cepat, kehadiran "sorotan" dalam prototaip (cari CEO di rangkaian sosial) dan kemahiran NLP backender kami, yang juga sangat menarik minat juri.
Dan sebagai kesimpulan, terima kasih tradisional kepada semua yang menyokong kami, juri trek kami, Evgeniy Evgrafiev (pengarang masalah yang kami selesaikan di hackathon) dan sudah tentu penganjur hackathon. Ini mungkin hackathon terbesar dan paling hebat yang pernah saya sertai, saya hanya boleh berharap mereka mengekalkan standard yang tinggi pada masa hadapan!
Sumber: www.habr.com