Topik ini menentukan lingkup proyek puncak jalur: memilih antara sistem obrolan dan layanan presence multi-node, membatasi fitur pertama yang layak dibangun, dan menyusun urutan pengerjaan yang menuntaskan kemampuan inti Erlang. Hasil topik ini adalah lingkup tertulis yang menjadi masukan perancangan pada topik perancangan pohon supervisi.
Dua kandidat dan sifatnya#
Dua kandidat terbaik untuk proyek ini menuntut bagian berbeda dari platform. Sistem obrolan menyatukan pemeliharaan koneksi, pengiriman pesan antar pengguna, dan riwayat yang tersimpan, sehingga menyentuh proses per pengguna, registry nama, persistensi DETS atau Mnesia, dan supervisi yang rapi. Layanan presence menyatakan siapa yang sedang daring dan pada node mana ia berada, sehingga menuntut penguasaan distribusi: pendaftaran lintas node, pembaruan state saat node berganti, dan pemulihan saat koneksi terputus. Keduanya sama-sama menuntut pohon supervisi yang dirancang dengan pertimbangan, dan perbedaannya ada pada bobot: obrolan berat di penyimpanan dan protokol pesan, presence berat di distribusi dan konsistensi state.
Kriteria pemilihannya sederhana dan jujur. Jika tujuan utamanya memperdalam OTP dan penyimpanan, obrolan memberi latihan yang lebih panjang karena setiap fitur menyentuh state. Jika tujuan utamanya memperdalam distribusi dan pemulihan, presence memberi pelajaran yang lebih tajam karena kesalahan state langsung terlihat pengguna. Keduanya harus mampu berjalan sebagai satu release, diuji dengan PropEr pada protokol pesannya, dan teramati lewat logger serta trace, karena ketiganya adalah kemampuan yang sudah dibangun pada modul-modul sebelumnya.
Lingkup pertama yang layak#
Kesalahan terbesar proyek puncak adalah lingkup terlalu luas. Lingkup pertama yang layak untuk obrolan terdiri atas tiga kemampuan: pengguna dapat menyambung dan disupervisi, pesan pribadi antar dua pengguna yang daring sampai, dan riwayat percakapan bertahan saat VM dimulai ulang. Fitur grup, indikator luring, lampiran, dan enkripsi bukan bagian lingkup pertama, karena masing-masing menggandakan permukaan desain tanpa menambah pelajaran baru. Untuk presence, lingkup pertamanya: pengguna daring terdaftar pada node tempat ia berada, pertanyaan siapa yang daring dijawab dari state yang konsisten, dan hilangnya node memindahkan status daring secara benar. Enam belas hingga dua puluh jam kerja adalah batas sehat untuk lingkup pertama, dan melebihi itu biasanya tanda fitur kedua menyelinap masuk.
Urutan pengerjaan dan syarat terima#
Urutan yang terbukti bekerja dimulai dari protokol: definisi pesan dan tipe datanya ditulis lebih dulu sebagai modul typespec yang lolos dialyzer, karena protokol adalah kontrak yang menyatukan semua bagian. Lanjut ke pohon supervisi terkecil yang hidup, lalu gen_server per unit kerja dengan uji EUnit dan PropEr pada protokolnya, kemudian lapisan penyimpanan, dan terakhir kemampuan distribusi bila kandidatnya presence. Syarat terima lingkup pertama dinyatakan sebagai tiga skenario yang bisa dijalankan:
- satu skrip uji Common Test yang menyambung dua pengguna, mengirim pesan, memulai ulang VM, dan memverifikasi riwayat
- satu properti PropEr yang menuntut setiap pesan terbalas atau tercatat
- satu sesi observer yang menunjukkan pohon supervisi sesuai rancangan
Dengan syarat seperti ini, selesai tidak lagi menjadi selera, dan setiap penambahan lingkup berikutnya berdiri di atas fondasi yang sudah teruji.
Menulis lingkup sebagai kontrak#
Lingkup yang tidak tertulis akan bergeser diam-diam. Kontrak lingkup pertama yang layak menampung empat bagian pendek: tiga kemampuan yang dijanjikan, dua kemampuan yang sengaja ditunda beserta alasannya, syarat terima yang bisa dieksekusi, dan batas waktu. Contoh yang telah dirinci pada topik ini cukup dipindahkan apa adanya: tiga kemampuan obrolan, penundaan fitur grup dan lampiran, tiga syarat terima yang masing-masing dieksekusi, dan batas enam belas jam. Kontrak serupa untuk presence menukar bagian penyimpanan dengan bagian distribusinya, dan membandingkan dua kontrak itu berdampingan biasanya menjawab pemilihan kandidat lebih cepat daripada diskusi, karena bobot pekerjaan yang sesungguhnya baru terlihat saat ditulis.
Ringkasan#
- Obrolan memperdalam OTP dan penyimpanan, presence memperdalam distribusi dan konsistensi, dan keduanya menuntut pohon supervisi yang rapi.
- Lingkup pertama dibatasi tiga kemampuan yang menuntaskan materi inti, dan fitur lain ditunda secara tertulis.
- Urutan pengerjaan dimulai dari protokol bertipe, lalu pohon supervisi, behaviour, penyimpanan, dan distribusi.
- Syarat terima dinyatakan sebagai skenario yang bisa dieksekusi: uji Common Test, properti PropEr, dan inspeksi observer.
Referensi#
- Erlang Design Principles — Ericsson — Kerangka desain aplikasi yang dipakai kandidat proyek.
- Distributed Erlang User Guide — Ericsson — Panduan distribusi yang menjadi bobot kandidat presence.
- Learn You Some Erlang for Great Good! — Fred Hebert — Bab yang membingkai penyusunan aplikasi OTP utuh.