Pada akhir Maret di Novosibirsk, peringatan 10 tahun
CodeFest meninggal . Seperti, mungkin, konferensi apa pun, CodeFestX meninggalkan banyak kesan berbeda untuk para peserta dari "kakiku tidak akan lagi di sini" hingga "bagaimana cara membeli langganan seumur hidup?". Saya tidak akan menjelaskan bagaimana itu,
sudah ada ulasan dan, saya pikir, masih akan muncul. Saya ingin berbagi cerita tentang bagaimana kami meluncurkan
versi alternatif untuk jadwal Codefest (
menonton lebih baik dari ponsel ): dari ide hingga hasilnya.
Ide
Saya telah menghadiri Codefest sejak 2010, dan tahun ini adalah konferensi ke-9 saya. Bagi saya, Codefest adalah sebuah tradisi, dan kali ini saya ingin melakukan sesuatu yang bermanfaat. Sebelum acara, membaca obrolan konferensi, saya menyadari bahwa jadwal adalah sesuatu yang pasti dapat ditingkatkan. Codefest adalah acara penting yang semua orang ingin manfaatkan, jadi saya memutuskan untuk membantu membangun jadwal kustom alternatif.
Tujuannya adalah sebagai berikut:
- Bagi pengunjung - untuk memberikan kesempatan untuk mendapatkan informasi yang lebih relevan tentang acara terkini dan membentuk umpan minat mereka sendiri. Plus, semua pengunjung konferensi memiliki kesempatan untuk datang ke stan kami dan mencatat semua fitur yang hilang atau memperbaiki bug;
- Untuk Codefest , ini adalah saluran tambahan untuk mendistribusikan program "populer";
- Bagi kami, sebagai perusahaan , ini tentu saja merupakan nilai tambah tambahan dalam merek Majikan.
Konsep jadwal "dipompa" datang ke penyelenggara Codefest. Saya berbagi ide di Wrike dan dengan cepat menemukan orang-orang yang berpikiran sama yang mau terhubung. Kami mulai dengan penelitian, melihat situs konferensi dan aplikasi seluler. Secara umum, kami meluncurkan
proses belanjaan yang biasa di Wrike.
Sebagai hasil dari pengerjaan backlog, kami menentukan bahwa fungsionalitas yang diperlukan diperlukan seperti ini:
- Jadwal konferensi utama dengan kemampuan untuk memfilter laporan dan pencarian;
- Favorit dan pemberitahuan tentang pendekatan acara yang dipilih;
- Program populer dengan fungsi yang sama dengan yang utama, serta peluang bagi mitra dan aktivis untuk menambahkan acara ke program ini.
Ada tugas dengan prioritas lebih rendah:
- Diskusi pada laporan sehingga pengguna yang berwenang dapat bertukar pendapat dan berdiskusi;
- Suka dan laporan peringkat populer;
- Peta, sebagai CodeFest hebat dan navigasi sangat penting.
Masih ada tugas dengan prioritas ketiga, di mana kami masih memiliki banyak pesawat ruang angkasa yang terkubur, tetapi saya percaya bahwa waktunya akan tiba.
Implementasi
Kami memutuskan untuk mengambil apa yang kami gunakan dalam pengembangan produk kami sebagai tumpukan untuk proyek, untuk memberikan kesempatan untuk melihat bagaimana frontend dibangun di Wrike. Kami menulis di
Dart (
dan sudah memberi tahu alasannya: di sini dan di sini ) dan untuk saat ini untuk proyek web besar seperti milik kami, hanya ada Angular (di
sini adalah 5 menit inspirasi dari bunopus ). Repositori proyek kami dapat ditemukan di sini
github.com/wrike/codefestx .
Di aplikasi Angular kami, kami menambahkan
Redux . Ada beberapa implementasi untuk Dart: kami menggunakan
Redux.dart dan
Redux Epics untuk efek. Dalam proyek kami, kode yang terkait dengan Redux terdapat di sini
github.com/wrike/codefestx/tree/master/lib/src/redux .
Untuk bekerja dengan
keadaan tidak berubah, kami mengambil paket
built_value dan
built_collection , yang menyederhanakan pekerjaan dengan baik. Sebagai contoh, kita membuat kelas untuk keadaan aplikasi kita -
CodefestState , dan paket menghasilkan
pembangun .
Trik sederhana digunakan untuk berkomunikasi Angular dan Redux (
dalam komponen utama - github.com/wrike/codefestx/blob/master/lib/app_component.dart ):
Dan kami mengikat mereka bersama melalui
Stream gart standar:
_dispatcher.onAction.listen((action) => _store.dispatch(action)),
_store.onChange.listen((_) => _zone.run(_cdr.markForCheck)),
Yaitu, ketika Anda membuat tindakan di manajer (
mereka semua ada di sini ), itu masuk ke repositori Redux. Sedang diproses dan negara berubah, yang menyebabkan siklus Deteksi Perubahan Sudut.
Kami membuat 2 mekanisme untuk mengirim notifikasi: karena notifikasi terjadinya peristiwa, karena ini penting, terintegrasi dengan
PushWoosh dan menerima dorongan sistem (
sayangnya tanpa dukungan untuk browser di iOS ). Untuk acara yang kurang kritis, misalnya, rilis versi baru, soket dinaikkan, dan
socket_io_client digunakan pada klien.
Secara umum, struktur aplikasi sederhana dan, menurut saya, dapat dimengerti. Jika Anda memiliki pertanyaan, kami dapat mendiskusikan solusi spesifik di komentar atau di github.
Infrastruktur
Di dunia modern, untuk mengunggah file JS untuk penggunaan umum,
k8s sangat diperlukan. Tapi serius, salah satu fitur dari layanan kami adalah revisi tepat di konferensi itu sendiri (
yang mengambil keuntungan beberapa pengunjung di antara pengunjung dan tidak, mereka bukan dari Wrike :) ).
Karena itu, kami memutuskan untuk membuat CI yang jujur. Kami melihat peluang integrasi yang
dimiliki GitHub dan menemukan
Google Cloud Build di sana : karena kami menggunakan produk Google, maka kami tidak boleh meninggalkan trek ini. Integrasi berfungsi seperti ini: komit apa pun ke repositori akan memanggil perakitan
cloudbuild.yaml . Kami menyusuri jalur yang kami rakit wadah Docker dengan aplikasi yang sudah jadi (
ada templat hub untuk panah - hub.docker.com/r/google/dart ), dan kemudian kami meluncurkannya dalam k8s sehingga kami dapat memutar kembali rilis, skala dan menyediakan untuk yang hipotetis lainnya situasi. Dari apa yang tidak cukup di luar kotak, itu adalah kemampuan untuk melakukan perilaku yang berbeda tergantung pada cabang di mana kita melakukan, yaitu, untuk master untuk membangun dan menyebar ke pertempuran, dan untuk cabang yang tersisa, langkah minimal harus dilakukan tanpa k8. Ada diskusi aktif tentang topik ini di
sini , dan kami mengambil keuntungan dari solusi dari diskusi ini. CI bekerja dengan sempurna dan tidak pernah gagal.
Terbang di salep
Selain kesuksesan kami, tentu saja, ada sesuatu yang bisa dilakukan secara berbeda. Misalnya, jangan memaksa orang untuk masuk ketika memberikan suara untuk laporan - beberapa tidak suka ini (
terutama dalam layanan jangka pendek ). Sebagai hasilnya, kami tidak mendapatkan banyak "suka" untuk laporan, tetapi, bagaimanapun, memberi selamat kepada juara pembicara.
Kami juga dalam keberanian pengembangan web lupa tentang batasan ketat iOS, dan bahwa tidak
ada cara untuk melakukan push untuk web . Ternyata hampir separuh dari pengguna layanan kami menggunakan iPhone. Sayangnya, kami tidak dapat mengirimi mereka pemberitahuan.
Dan apa lagi yang mengganggu tim, seperti yang telah saya sebutkan, - kami tidak berhasil melakukan semua rencana kami. Beberapa fungsionalitas diluncurkan tepat di konferensi, dan beberapa masih hidup dalam jaminan.
Hasil
Terima kasih kepada panitia bahwa tautan ke jadwal telah ditambahkan ke memo peserta konferensi. Selama konferensi, lebih dari 1100 pengguna menggunakan layanan ini. Pada program utama ~ 120 acara, kami menambahkan ~ 50 "folk" lainnya. Sekitar 75% dari sesi berada di perangkat seluler, kami mengirim lebih dari 500 pemberitahuan push, mengeluarkan 3 rilis selama konferensi itu sendiri, dan menerima banyak kesenangan dari proses dan hasilnya.
Itu adalah pengalaman hebat, dan kami akan terus mengembangkan proyek, setidaknya untuk acara internal dan konferensi Wrike. Jika Anda pernah ke Codefest dan menggunakan jadwal kami, kami menyambut umpan balik Anda di komentar.