Saturday, October 31, 2026

Kisah Aku Membangunkan Aplikasi Tempahan Dewan dan Bilik Mesyuarat

 

Bermula dengan urusan harian di sekolah

Aku nak kongsikan cerita di sebalik aplikasi tempahan dewan dan bilik mesyuarat SMK Bandar Putra. Idea untuk membangunkannya datang daripada keperluan mengurus kemudahan sekolah dengan lebih tersusun. Aku mahu urusan tempahan lebih mudah dirujuk dan sesuai dengan cara kerja warga sekolah.

Dewan dan bilik mesyuarat digunakan untuk pelbagai aktiviti. Ada mesyuarat, taklimat, program murid dan urusan sekolah yang lain. Apabila kemudahan dikongsi ramai, maklumat penggunaannya perlu jelas supaya perancangan program dapat dibuat dengan lebih baik.

Daripada keperluan itu, aku mula merancang sebuah aplikasi yang memberi tumpuan kepada tempahan dua kemudahan ini. Aku fikirkan tujuan pengguna membukanya, maklumat yang perlu mereka faham dan bagaimana urusan itu patut disusun. Aku mahu hasilnya dekat dengan keperluan sebenar di sekolah.

Aku tentukan apa yang aplikasi ini perlu buat

Bagi aku, perkara pertama ialah menentukan masalah yang hendak diselesaikan. Sebelum memikirkan kod, aku perlu jelas tentang tujuan aplikasi dan bagaimana ia boleh membantu pengguna. Keperluan itulah yang menjadi panduan sepanjang pembangunan projek ini.

Aku menentukan hala tuju aplikasi, memberi arahan tentang hasil yang diperlukan dan menyemak sama ada hasilnya menepati kehendak aku. Apabila ada bahagian yang kurang sesuai, aku beri maklum balas dan tentukan perubahan yang perlu dibuat.

Dalam urusan penulisan kod, aku menggunakan bantuan ChatGPT. Aku terangkan keperluan yang telah aku fikirkan, kemudian mendapatkan bantuan untuk menterjemahkannya kepada kod. Dengan cara itu, aku boleh meneruskan pembangunan sambil memberi perhatian kepada susunan aplikasi dan kegunaannya di sekolah.


Bantuan koding dalam proses pembangunan

Peranan ChatGPT dalam projek ini tertumpu pada bantuan koding. Berdasarkan arahan dan keperluan yang aku berikan, ia membantu menyediakan serta mengubah kod. Aku kemudian menyemak hasil perubahan itu dari sudut penggunaan dan kesesuaiannya dengan aplikasi yang aku rancang.

Prosesnya melibatkan beberapa pusingan semakan. Aku melihat hasil yang dibina, mengenal pasti bahagian yang perlu diperbaiki dan memberi arahan seterusnya. Ada perkara yang lebih mudah dinilai apabila sudah muncul pada skrin berbanding ketika masih dalam bentuk idea.

Bantuan ini memudahkan aku melaksanakan bahagian teknikal. Namun, keputusan tentang apa yang perlu dipaparkan, perkara yang patut diutamakan dan perubahan yang sesuai tetap berpandukan keperluan yang aku tetapkan untuk sekolah.

Semak dari sudut orang yang akan menggunakannya

Apabila menilai aplikasi, aku cuba melihatnya dari sudut guru yang hendak membuat urusan tempahan. Mereka perlu memahami maklumat dan tindakan yang perlu dibuat dengan mudah. Sebab itu, aku memberi perhatian kepada kejelasan susunan dan arahan pada paparan.

Bagi aku, banyak fungsi belum tentu menjadikan aplikasi lebih membantu. Aku lebih berminat pada fungsi yang ada tujuan jelas. Kalau sesuatu bahagian menyukarkan pengguna memahami urusan tempahan, bahagian itu perlu dinilai dan dikemaskan.

Dalam proses ini, aku belajar memberikan arahan perubahan yang lebih khusus. Aku perlu jelaskan bahagian yang kurang sesuai, hasil yang aku mahu dan sebab perubahan itu diperlukan. Arahan yang jelas membantu kerja pembaikan kod berjalan dengan lebih terarah.

Mengenali bahagian teknikal aplikasi

Projek ini turut memberi aku peluang mengenali peranan Vercel dan Supabase. Dalam aplikasi ini, Vercel digunakan untuk pengehosan, manakala Supabase digunakan bagi pangkalan data. Kedua-duanya menjadi sebahagian daripada susunan teknikal yang menyokong aplikasi.

Aku memahami perkara ini sedikit demi sedikit sepanjang mengurus projek. Apabila ada makluman perubahan perkhidmatan, aku mula menilai kesannya kepada aplikasi, termasuk urusan penambahbaikan dan kemungkinan kos. Pengetahuan itu penting untuk aku merancang penjagaannya selepas siap.


Aplikasi perlu terus dijaga

Bila aplikasi sudah boleh digunakan, masih ada perkara yang perlu diberi perhatian. Aku perlu memikirkan pengurusan data, akses kepada projek dan kemampuan untuk membuat perubahan apabila diperlukan. Semua ini ada kaitan dengan kesinambungan penggunaan aplikasi di sekolah.

Untuk projek seperti ini, aku mahu pendekatan yang mampu diurus. Jika ada cadangan fungsi baharu, aku perlu menilai manfaatnya terlebih dahulu. Aku juga perlu memahami sama ada perubahan itu melibatkan susunan data atau bahagian lain dalam aplikasi.

Antara perkara yang boleh dipertimbangkan pada masa hadapan ialah penambahbaikan paparan jadual, makluman kepada pengguna dan ringkasan penggunaan kemudahan. Ini ialah cadangan yang masih perlu dinilai mengikut keperluan serta kemampuan pengurusan.

Apa yang aku belajar daripada projek ini

Pengalaman ini mengajar aku bahawa memahami keperluan pengguna ialah bahagian penting dalam membangunkan aplikasi. Sebagai orang yang berada di sekolah, aku membawa pengetahuan tentang konteks penggunaan dewan dan bilik mesyuarat. Pengetahuan itu membantu aku merancang dan menilai hasil projek.

Aku juga semakin faham bahawa pembangunan aplikasi memerlukan keputusan yang dibuat secara berterusan. Kita perlu menentukan keutamaan, menyemak hasil dan memilih perubahan yang benar-benar berguna. Kerja ini memerlukan perhatian walaupun bantuan penulisan kod tersedia.

Dalam projek ini, ChatGPT menjadi pembantu aku untuk koding. Aku pula mengurus idea, keperluan, hala tuju dan semakan hasil aplikasi. Pembahagian peranan ini membolehkan aku mengusahakan penyelesaian yang aku mahu untuk kegunaan sekolah.

Bagi aku, kepuasan projek ini datang apabila idea yang dirancang dapat diterjemahkan menjadi sebuah aplikasi yang boleh dirujuk dan diperbaiki. Masih ada ruang untuk belajar, tetapi pengalaman membangunkan aplikasi tempahan dewan dan bilik mesyuarat ini sudah memberi aku asas untuk meneruskan usaha yang seterusnya.

Friday, October 30, 2026

Auto RX Hidup Tapi KA9Q bermasalah

 


Cerita troubleshoot radiosonde pada 30 Oktober 2026 | 9M2ZAK

Malam ini sistem radiosonde saya buat hal sikit. Buka paparan Auto-RX, penuh log merah. Scanner asyik cuba berjalan, kemudian gagal, kemudian cuba lagi.

Antara mesej yang berulang:

KA9Q (sonde.local) - tune call failed ... with a timeout.
Task Manager - Ongoing issue with KA9Q server connection.

Web boleh buka macam biasa, tetapi bahagian penerimaan tak berjalan seperti sepatutnya. Jadi saya mula periksa satu demi satu.

Servis hidup tapi kenapa timeout

Mula-mula saya semak servis KA9Q:

systemctl list-units --all 'radiod*'

Hasilnya, radiod@airspymini-autorx.service ditunjukkan sebagai active running. Nampak elok. Tapi status itu cuma beritahu proses masih hidup. Sama ada Auto-RX boleh berkomunikasi dengannya, itu kena semak lagi.

Saya ambil log menggunakan arahan ini. Pilihan --no-pager memaparkan output terus tanpa masuk ke paparan less:

sudo journalctl -u radiod@airspymini-autorx -n 60 --no-pager

Airspy Mini berjaya dikesan. Frekuensi tuner ditetapkan pada 405.6 MHz, dan fail FFTW wisdom utama pun berjaya dibaca. Ada mesej fail wisdom tambahan tidak dijumpai, tetapi KA9Q terus berjalan selepas itu. Jadi saya tak terus usik bahagian tersebut.

Saya cuba pula:

timeout 15s control sonde.local

Yang keluar cuma “0 channels”. Belum ada jawapan yang meyakinkan. Paparan itu sahaja belum membuktikan pelayan memberi respons, jadi pemeriksaan diteruskan ke bahagian rangkaian.

Petunjuk muncul pada interface

Dalam fail /etc/radio/radiod@airspymini-autorx.conf, tetapan saya ialah:

[global]
hardware = airspy
mode = fm
status = sonde.local
iface = lo
ttl = 0
data = sonde-pcm.local

KA9Q menggunakan interface loopback, iaitu lo. Kemudian saya semak alamat sonde.local:

getent hosts sonde.local

Pada sistem saya ketika itu, alamatnya ialah 239.189.26.13. Ini alamat multicast. Bila saya semak laluan ke alamat tersebut:

ip route get 239.189.26.13

Output menunjukkan dev wlan0. Haa, sini ada petunjuk. KA9Q dikonfigurasi menggunakan lo, tetapi laluan multicast yang dipilih sistem menuju wlan0.

Saya semak juga Docker:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Networks}}'

Container radiosonde_auto_rx memang menggunakan rangkaian host. Maknanya Auto-RX berkongsi rangkaian komputer yang sama.

Cuba betulkan laluan dahulu

Saya tambah satu laluan sementara, khusus untuk alamat kawalan KA9Q tadi:

sudo ip route add 239.189.26.13/32 dev lo

Kemudian semak semula:

ip route get 239.189.26.13

Kali ini sudah menunjukkan dev lo. Saya restart Auto-RX, tetapi percubaan awal masih menghasilkan timeout:

tune call (closing channel) failed with return code 124.
Could not contact KA9Q Server sonde.local:5006.

Jadi pembetulan laluan sahaja belum terus memulihkan sistem pada ketika itu. Langkah seterusnya, saya restart KA9Q dahulu:

sudo systemctl restart radiod@airspymini-autorx

Beri masa sekitar 15 saat untuk ia bermula, kemudian restart Auto-RX:

docker restart radiosonde_auto_rx

Selepas menunggu sekitar 30 saat, saya semak log:

docker logs --since 1m --tail 80 radiosonde_auto_rx

Akhirnya keluar mesej yang ditunggu:

Detected peaks on 12 frequencies
Async scan starting: 12 frequencies with max_concurrent=4
Async scan completed: 0 detections from 12 frequencies in 19.9s
Running frequency scan.

Lega. Scanner sudah kembali bekerja, dan selepas dipantau, sistem kembali normal.

“0 detections” dalam satu pusingan itu bermaksud belum ada radiosonde dikenal pasti. Ia bukan mesej kegagalan sambungan. Puncak isyarat yang dikesan boleh datang daripada pelbagai sumber.

Apa yang saya belajar kali ini

Bila nampak timeout, jangan terus anggap Airspy rosak atau perlu pasang semula semuanya. Dalam kes ini, ada ketidakpadanan antara interface dalam konfigurasi KA9Q dengan laluan multicast sistem. Selepas laluan dibetulkan dan kedua-dua servis dimulakan semula mengikut urutan, penerimaan kembali normal.

Saya tak boleh asingkan sepenuhnya kesan pembetulan laluan daripada kesan restart berdasarkan ujian ini sahaja. Tetapi gabungan langkah tersebut berjaya memulihkan setup saya malam ini.

Satu catatan penting untuk rujukan sendiri: laluan yang ditambah menggunakan ip route add tadi masih sementara dan belum dibuat kekal. Ia tidak kekal selepas reboot.

Alamat multicast juga perlu disemak pada sistem masing-masing. Jangan terus salin 239.189.26.13 tanpa menjalankan getent hosts sonde.local terlebih dahulu. Langkah ini merujuk setup KA9Q dan Auto-RX saya yang berjalan pada komputer sama dengan Docker dalam mod host.

Kalau mahu membuang laluan ujian tadi:

sudo ip route del 239.189.26.13/32 dev lo

Begitulah cerita malam ini. Ingatkan kena buka cerita panjang pasal driver dan USB, rupanya pemeriksaan laluan rangkaian yang membawa kita kepada jalan penyelesaian.

Sekarang scanner dah jalan semula. Bolehlah sambung tunggu belon lalu kawasan Johor.

73 de 9M2ZAK

Kisah Aku Membangunkan Aplikasi Tempahan Dewan dan Bilik Mesyuarat

  Bermula dengan urusan harian di sekolah Aku nak kongsikan cerita di sebalik aplikasi tempahan dewan dan bilik mesyuarat SMK Bandar Putra. ...