Baru-baru ini, kami
berbicara tentang program master perusahaan JetBrains dan “Rekayasa Perangkat Lunak / Rekayasa Perangkat Lunak” Universitas ITMO. Kami mengundang semua orang yang tertarik pada Hari Terbuka pada hari Senin, 29 April. Kami akan berbicara tentang keunggulan sekolah pascasarjana kami, tentang bonus apa yang kami tawarkan kepada siswa dan apa yang kami minta sebagai imbalannya. Selain itu, kami pasti akan menjawab pertanyaan para tamu.
Hari terbuka akan diadakan di kantor JetBrains di Times Business Center, tempat mahasiswa pascasarjana kami belajar. Mulai pukul 17:00. Anda dapat mengetahui semua detail dan mendaftar untuk acara tersebut di
mse.itmo.ru. Datang dan jangan menyesalinya!
Salah satu komponen utama pelatihan pada program ini adalah praktik. Siswa memiliki banyak hal: pekerjaan rumah mingguan, proyek semester dan hackathon. Berkat perendaman lengkap dalam metodologi dan teknologi pengembangan modern sambil belajar, lulusan dengan cepat bergabung dengan proses kerja perusahaan IT besar.
Dalam posting ini kami ingin berbicara lebih banyak tentang hackathons DevDays, yang berlangsung setiap enam bulan. Peraturannya sederhana: tim yang terdiri dari 3-4 orang berkumpul dan dalam waktu tiga hari, para siswa menghidupkan ide mereka sendiri. Apa yang bisa terjadi dengan ini? Baca bagian pertama dari cerita tentang proyek hackathon semester ini dari para siswa sendiri :)
Rekomendasi Film Diary
Penulis ideIvan Ilchuk
Komposisi TimIvan Ilchuk - parsing plot film, server
Vladislav Korablinov - pengembangan model untuk membandingkan kedekatan buku harian dan plot film
Dmitry Valchuk - UI
Nikita Vinokurov - UI, desain
Tujuan dari proyek kami adalah untuk menulis aplikasi desktop - buku harian yang akan merekomendasikan film kepada pengguna sesuai dengan entri di dalamnya.
Ide ini muncul di benak saya ketika saya pergi ke universitas dan memikirkan masalah saya. "Apa pun masalah yang dihadapi seseorang, beberapa klasik sudah menulis tentang ini," pikirku. "Dan sejak seseorang menulis, itu berarti seseorang telah membuat film." Jadi keinginan untuk menonton film tentang seorang pria dengan siksaan mental yang sama muncul dengan sendirinya.
Jelas, ada berbagai macam buku harian terpisah dan layanan rekomendasi terpisah (tetapi biasanya rekomendasi didasarkan pada apa yang sebelumnya disukai seseorang). Pada prinsipnya, proyek ini memiliki kesamaan dengan pencarian film berdasarkan poin-poin utama, tetapi tetap saja, pertama-tama, aplikasi kita menyediakan fungsionalitas buku harian.
Bagaimana kami menerapkan ini? Ketika tombol ajaib ditekan, buku harian mengirim entri ke server, tempat film dipilih berdasarkan deskripsi yang diambil dari Wikipedia. Frontend kami dibuat pada Elektron (kami menggunakannya, bukan situs, karena pada awalnya kami memutuskan untuk menyimpan data pengguna bukan pada server, tetapi secara lokal di komputer), dan server dan sistem rekomendasi itu sendiri menggunakan Python: TF diperoleh dari deskripsi -IDF vektor yang dibandingkan dengan kedekatan dengan vektor entri buku harian.
Satu anggota tim hanya terlibat dalam model, yang lain di seluruh frontend (awalnya dipasangkan dengan anggota ketiga, yang kemudian beralih ke pengujian). Saya terlibat dalam parsing plot film dari Wikipedia dan server.
Langkah demi langkah, kami mendekati hasilnya, mengatasi sejumlah masalah, dimulai dengan fakta bahwa awalnya model tersebut membutuhkan banyak RAM, berakhir dengan kesulitan mentransfer data ke server.
Sekarang, untuk menemukan film untuk malam itu, Anda tidak perlu banyak usaha: hasil dari kerja tiga hari kami adalah aplikasi desktop dan server yang diakses pengguna melalui https, menerima sebagai tanggapan atas 5 pilihan film dengan deskripsi dan poster singkat.
Saya memiliki kesan yang sangat positif terhadap proyek ini: pekerjaan itu menyenangkan dari pagi hingga larut malam, dan aplikasi yang dihasilkan secara berkala memberikan hasil yang sangat lucu dalam gaya "Sleepless Night" ke entri buku harian tentang pekerjaan rumah di universitas atau film tentang hari sekolah pertama pada kisah hari pertama di departemen.
Tautan yang relevan, penginstal, dan lainnya dapat ditemukan di
sini .
Pembuat rute
Penulis ideArtemyeva Irina
Komposisi TimArtemyeva Irina - pemimpin tim, loop utama
Gordeeva Lyudmila - musik
Platonov Vladislav - rute
Saya sangat suka berjalan di sekitar kota: melihat bangunan, orang-orang, berpikir tentang sejarah. Tetapi, bahkan mengubah tempat tinggal saya, cepat atau lambat saya dihadapkan dengan masalah memilih rute: segala sesuatu yang saya dapat hasilkan telah berlalu. Jadi muncul ide untuk mengotomatiskan pembuatan rute: Anda menentukan titik awal dan panjang rute, dan program memberikan opsi. Berjalan bisa lama, jadi pengembangan logis dari ide itu tampaknya menambah kemampuan untuk menunjukkan titik-titik perantara untuk "berhenti", di mana Anda bisa menggigit dan bersantai. Cabang pengembangan lainnya adalah musik. Pergi ke musik selalu lebih menyenangkan, jadi alangkah baiknya menambahkan kemampuan untuk memilih daftar putar untuk rute yang dihasilkan.
Di antara aplikasi yang ada, solusi tersebut tidak dapat ditemukan. Analog terdekat adalah perencana rute: Google Maps, 2GIS, dll.
Aplikasi semacam ini paling nyaman untuk digunakan di telepon, sehingga penggunaan Telegram telah menjadi pilihan yang baik. Ini memungkinkan Anda untuk menampilkan peta dan memutar musik, dan Anda dapat mengatur semua ini dengan menulis bot. Pekerjaan utama dengan peta dilakukan dengan menggunakan Google Map API. Python membuatnya mudah untuk berteman dengan kedua teknologi.
Ada tiga orang di tim, jadi tugas itu dibagi menjadi dua subtugas terpisah (bekerja dengan kartu dan bekerja dengan musik) sehingga orang-orang dapat bekerja secara mandiri, dan saya mengurus hasilnya.
Tidak satu pun dari kami yang pernah bekerja dengan Google Map API dan menulis Telegram bot, jadi masalah utamanya adalah jumlah waktu yang diberikan untuk proyek: untuk mengetahui sesuatu selalu membutuhkan lebih banyak waktu daripada melakukan apa yang Anda ketahui dengan baik. Itu juga sulit untuk memilih API bot Telegram: karena memblokir, tidak semua orang bekerja dan harus menderita untuk mengkonfigurasi semuanya.
Perlu disebutkan secara terpisah bagaimana tugas menghasilkan rute diselesaikan. Mudah untuk membangun rute antara dua lokasi, tetapi apa yang akan ditawarkan kepada pengguna jika hanya panjang rute yang diketahui? Biarkan pengguna ingin berjalan 10 kilometer. Dalam arah yang sewenang-wenang, sebuah titik dipilih yang jaraknya dalam garis lurus adalah 10 kilometer, setelah itu sebuah rute dibangun ke titik nyata di sepanjang jalan nyata. Kemungkinan besar itu tidak akan langsung, jadi kami akan mempersingkatnya menjadi 10 kilometer yang ditentukan. Ada banyak opsi untuk rute seperti itu - kami mendapatkan generator rute nyata!
Awalnya, saya ingin membagi peta menjadi beberapa bagian yang sesuai dengan area hijau: tanggul, halaman, jalan-jalan, untuk mendapatkan rute yang paling menyenangkan untuk berjalan-jalan, dan juga untuk menghasilkan musik sesuai dengan bagian-bagian ini. Tetapi ternyata sulit melakukan ini menggunakan Google Map API (mereka tidak berhasil menyelesaikan masalah ini). Namun, ternyata mewujudkan pembangunan rute melalui jenis lokasi tertentu (toko, taman, perpustakaan): jika rute telah melewati semua tempat yang ditentukan, tetapi jarak yang diinginkan belum ditempuh, itu meluas ke jarak yang ditentukan pengguna dalam arah acak. Juga, Google Map API memungkinkan Anda menghitung perkiraan waktu perjalanan, yang membantu untuk memilih daftar putar untuk durasi perjalanan yang tepat.
Akibatnya,
ternyata membuat generasi rute dengan titik awal, jarak dan titik menengah; Semuanya disiapkan untuk mengklasifikasikan musik sesuai dengan bagian rute, tetapi karena kurangnya waktu, diputuskan untuk meninggalkan kemungkinan memilih daftar putar hanya sebagai cabang UI tambahan. Dengan demikian, pengguna dapat secara mandiri memilih musik untuk didengarkan.
Masalah utama dengan bekerja dengan musik adalah kurangnya pengetahuan di mana mendapatkan file mp3 sehingga tidak mengharuskan pengguna untuk memiliki akun di layanan apa pun. Diputuskan untuk meminta musik dari pengguna (mode UserMusic). Ini menimbulkan masalah baru: tidak semua orang memiliki kemampuan untuk mengunduh lagu. Salah satu solusinya adalah membuat repositori dengan musik dari pengguna (mode BotMusic) - Anda dapat menghasilkan musik dari sana terlepas dari layanan.
Meski tidak sempurna, tetapi kami mengatasi tugas itu: ternyata aplikasi yang ingin saya gunakan. Secara umum, ini sangat keren: tiga hari yang lalu Anda hanya punya ide dan tidak ada satu pun yang berpikir bagaimana menerapkannya, dan sekarang ada solusi yang berfungsi. Bagi saya itu adalah tiga hari yang sangat penting. Saya tidak lagi takut untuk menghasilkan sesuatu yang kurang pengetahuan, menjadi pemimpin tim sangat menarik, dan saya lebih baik mengenali orang-orang hebat yang pergi ke tim saya!
Demokrasi cair
Penulis ideStanislav Sychev
Komposisi TimStanislav Sychev - pemimpin tim, basis data
Nikolay Izyumov - antarmuka bot
Anton Ryabushev - backend
Dalam kelompok yang berbeda, seringkali perlu untuk membuat keputusan atau memilih. Biasanya dalam kasus seperti itu mereka menggunakan
demokrasi langsung , namun, ketika kelompok menjadi besar, masalah dapat muncul. Misalnya, seseorang dari suatu kelompok mungkin tidak memiliki keinginan untuk sering menjawab pertanyaan atau menjawab pertanyaan tentang topik tertentu. Dalam kelompok besar, untuk menghindari masalah, mereka menggunakan
demokrasi perwakilan , ketika mereka memilih kelompok "wakil" yang terpisah dari semua orang yang membebaskan sisanya dari beban pilihan. Tetapi sistem ini memiliki kekurangan.
Untuk memecahkan masalah kedua sistem, Brian Ford mengusulkan konsep
demokrasi cair . Dalam sistem seperti itu, setiap orang bebas untuk memilih peran pengguna biasa atau delegasi, hanya dengan mengekspresikan keinginan. Siapa pun dapat memberikan suara secara independen atau memberikan suara mereka pada delegasi pada satu atau lebih masalah. Seorang delegasi juga dapat memberikan suara. Terlebih lagi, jika delegasi telah berhenti untuk mengatur seorang pemilih, pemungutan suara dapat ditarik kapan saja.
Contoh penggunaan demokrasi cair ditemukan dalam politik, dan kami ingin menerapkan ide serupa untuk penggunaan sehari-hari dalam berbagai kelompok orang. Pada hackathon DevDays berikutnya, kami memutuskan untuk menulis bot Telegram untuk memberikan suara pada prinsip-prinsip demokrasi cair. Pada saat yang sama, saya ingin menghindari masalah yang sering terjadi pada bot seperti itu - menyumbat obrolan umum dengan pesan dari bot. Solusinya adalah menempatkan sebanyak mungkin fungsionalitas ke dalam percakapan pribadi.
Untuk membuat bot ini, kami menggunakan
API Telegram . Untuk menyimpan riwayat pemilihan dan delegasi, database PostgreSQL dipilih. Untuk berkomunikasi dengan basis data, bot dinaikkan ke Flask-server. Kami memilih teknologi ini karena kami sudah memiliki pengalaman berinteraksi dengan mereka saat belajar di magistracy. Bekerja pada tiga bagian pokok proyek - database, server dan bot - berhasil didistribusikan di antara anggota tim.
Tentu saja, tiga hari adalah waktu yang singkat, jadi selama hackathon kami merealisasikan ide ke tingkat prototipe. Akibatnya, kami membuat bot yang menulis di obrolan umum hanya informasi tentang pembukaan suara dan hasil anonimnya. Peluang untuk memilih dan membuat suara diwujudkan melalui korespondensi pribadi dengan bot. Untuk memilih, sebuah tim diperkenalkan yang menampilkan daftar masalah yang membutuhkan perhatian langsung. Dalam korespondensi pribadi, Anda dapat melihat daftar delegasi dan suara mereka sebelumnya, serta memberi mereka suara Anda pada salah satu topik.
Video dengan contoh pekerjaan .
Sangat menarik untuk mengerjakan proyek ini, kami tinggal di universitas sampai tengah malam. Tampaknya bagi kita bahwa ini adalah cara yang bagus untuk mengalihkan perhatian dari studi, meskipun sangat melelahkan. Ada pengalaman yang menyenangkan di tim yang akrab.
PS: Penerimaan ke magistrasi untuk tahun akademik berikutnya sudah
terbuka . Bergabunglah sekarang!