#dusk $DUSK @Dusk .....Saya tidak sedang mencari pembaruan Dusk tentang Mac.
Saya sedang menyusuri Piecrust, dan satu perubahan kecil pada CI membuat saya berhenti.
@dusk memindahkan validasi macOS ARM keluar dari workflow utama dan ke dalam jalur terpisah yang dipagari....
Awalnya, itu terdengar seperti pekerjaan rumah rekayasa yang membosankan.
Lalu saya ingat apa sebenarnya Piecrust.
Itu adalah mesin virtual WASM yang berada di bawah smart contract Dusk. Jadi pertanyaan menariknya menjadi: bagaimana cara menguji lapisan eksekusi yang kritis tanpa membiarkan setiap kasus tepi spesifik platform memperlambat seluruh pipeline pengembangan?
Anggap saja seperti memeriksa sebuah pesawat...
Pemeriksaan standar dilakukan setiap kali.
Konfigurasi khusus mendapatkan prosedur uji sendiri saat perangkat keras memintanya...
Itulah kira-kira yang dilakukan perubahan ini.
Pipeline reguler tetap fokus pada validasi inti, sementara pengujian macOS ARM bisa berjalan terpisah pada pemicu tertentu, bukan menjadi jalur wajib untuk semuanya..
Dan pembedaan itu semakin penting saat protokol berkembang.
Pekerjaan Rusk versi 1.7.x sudah menyentuh perilaku VM di sekitar hardfork Boreas, termasuk perubahan yang melibatkan event yang dibatalkan dan perilaku replay historis. Piecrust jelas masih bagian dari tumpukan eksekusi yang terus berubah.
Yang saya anggap menarik bukanlah “Dusk mendukung mesin lain.”
Yang menarik adalah trade-off rekayasa...
Anda bisa membuat setiap pengujian berjalan di mana-mana, setiap saat.
Atau Anda bisa menjaga jalur kritis tetap ketat dan mengisolasi validasi spesifik platform di tempat yang benar-benar menambah sinyal..
Kedua pendekatan tidak otomatis lebih baik.
Tapi untuk VM smart-contract, saya lebih suka pengujian diorganisasi berdasarkan di mana risiko eksekusi berada, bukan berdasarkan satu daftar periksa raksasa.
Bagian yang tak terlihat dari infrastruktur inilah yang jarang diperhatikan orang.
Kualitas sebuah blockchain tidak hanya ditentukan oleh apa yang mencapai mainnet.
Itu juga ditentukan oleh seberapa teliti perangkat lunak di bawahnya diuji tantangannya sebelum sampai ke sana.
Jadi, apa yang akan Anda optimalkan pertama?
Lebih banyak pengujian untuk setiap perubahan, atau lebih banyak pengujian yang ditargetkan untuk jalur eksekusi yang paling mungkin gagal?
$ACE $TRUMP
Saya sedang menyusuri Piecrust, dan satu perubahan kecil pada CI membuat saya berhenti.
@dusk memindahkan validasi macOS ARM keluar dari workflow utama dan ke dalam jalur terpisah yang dipagari....
Awalnya, itu terdengar seperti pekerjaan rumah rekayasa yang membosankan.
Lalu saya ingat apa sebenarnya Piecrust.
Itu adalah mesin virtual WASM yang berada di bawah smart contract Dusk. Jadi pertanyaan menariknya menjadi: bagaimana cara menguji lapisan eksekusi yang kritis tanpa membiarkan setiap kasus tepi spesifik platform memperlambat seluruh pipeline pengembangan?
Anggap saja seperti memeriksa sebuah pesawat...
Pemeriksaan standar dilakukan setiap kali.
Konfigurasi khusus mendapatkan prosedur uji sendiri saat perangkat keras memintanya...
Itulah kira-kira yang dilakukan perubahan ini.
Pipeline reguler tetap fokus pada validasi inti, sementara pengujian macOS ARM bisa berjalan terpisah pada pemicu tertentu, bukan menjadi jalur wajib untuk semuanya..
Dan pembedaan itu semakin penting saat protokol berkembang.
Pekerjaan Rusk versi 1.7.x sudah menyentuh perilaku VM di sekitar hardfork Boreas, termasuk perubahan yang melibatkan event yang dibatalkan dan perilaku replay historis. Piecrust jelas masih bagian dari tumpukan eksekusi yang terus berubah.
Yang saya anggap menarik bukanlah “Dusk mendukung mesin lain.”
Yang menarik adalah trade-off rekayasa...
Anda bisa membuat setiap pengujian berjalan di mana-mana, setiap saat.
Atau Anda bisa menjaga jalur kritis tetap ketat dan mengisolasi validasi spesifik platform di tempat yang benar-benar menambah sinyal..
Kedua pendekatan tidak otomatis lebih baik.
Tapi untuk VM smart-contract, saya lebih suka pengujian diorganisasi berdasarkan di mana risiko eksekusi berada, bukan berdasarkan satu daftar periksa raksasa.
Bagian yang tak terlihat dari infrastruktur inilah yang jarang diperhatikan orang.
Kualitas sebuah blockchain tidak hanya ditentukan oleh apa yang mencapai mainnet.
Itu juga ditentukan oleh seberapa teliti perangkat lunak di bawahnya diuji tantangannya sebelum sampai ke sana.
Jadi, apa yang akan Anda optimalkan pertama?
Lebih banyak pengujian untuk setiap perubahan, atau lebih banyak pengujian yang ditargetkan untuk jalur eksekusi yang paling mungkin gagal?
$ACE $TRUMP