Kategori: Catatan Coding

Minggu ketiga Agustus 2026 menjadi minggu yang cukup sibuk bagi dunia developer, terutama di ekosistem PHP, Go, dan AI open source. Berbagai rilis penting datang bertubi-tubi — mulai dari Laravel yang terus memperluas fitur framework-nya, PHP yang mendekati rilis stabil, sampai tools AI inference yang makin efisien untuk dijalankan secara lokal. Bagi siapa pun yang bekerja di web development maupun cloud infrastructure, minggu ini layak diperhatikan karena beberapa perubahan ini bisa berdampak langsung pada workflow dan arsitektur proyek yang sedang dikerjakan.

Berikut kumpulan berita coding, web dev & AI paling menarik minggu ini. Mulai dari rilis Laravel terbaru, PHP 8.6 Beta, sampai update di dunia AI open source.

1. Laravel 13.26: Read-Through Disks & Debounced Listeners

Laravel merilis versi 13.26 dengan dua fitur menarik. Pertama, Read-Through Disks yang memungkinkan filesystem disk melakukan lazy loading dan caching otomatis — cocok untuk migrasi storage gradual. Kedua, debounced event listeners yang memungkinkan event listener hanya dijalankan setelah jeda waktu tertentu, berguna untuk event yang sering trigger tapi cukup diproses sekali.

Dari sudut pandang pribadi, fitur Read-Through Disks sangat relevan untuk proyek yang sedang migrasi dari storage lokal ke cloud (misalnya S3 atau R2). Seringkali kita butuh waktu untuk transisi penuh, dan fitur ini mempermudah proses tersebut tanpa harus refactor besar-besaran. Sementara debounced listeners adalah solusi elegan untuk masalah klasik di event-driven architecture — terutama untuk event yang berulang dalam waktu singkat.

Baca selengkapnya di Laravel News →

2. Lerd: Alternatif Open Source Herd untuk Linux & macOS

Lerd adalah tool baru gratis dan open source yang menawarkan pengalaman serupa Herd (environment PHP dari Laravel) tapi bisa jalan di Linux maupun macOS. Bagi developer PHP yang belum mau pakai Herd atau butuh alternatif cross-platform, Lerd layak dicoba.

Ketersediaan Lerd di Linux ini menjawab keluhan yang cukup lama di komunitas PHP, karena Herd sebelumnya hanya tersedia di macOS. Developer yang bekerja di lingkungan Linux atau WSL kini punya opsi yang serupa tanpa harus mengandalkan Docker untuk setup environment PHP mereka. Ini contoh bagaimana komunitas open source bisa mengisi gap yang ditinggalkan oleh tools komersial.

Baca selengkapnya di Laravel News →

3. PHP 8.6.0 Beta 1 Sudah Tersedia untuk Dites

PHP.net mengumumkan rilis PHP 8.6.0 Beta 1. Ini menandakan PHP 8.6 sudah masuk fase stabilisasi dan siap untuk diuji oleh komunitas. Developer yang ingin mencoba fitur-fitur baru di PHP versi mendatang bisa mulai install sekarang untuk kompatibilitas codebase.

Fase beta adalah waktu yang tepat untuk mulai testing di environment staging, terutama jika proyek kamu sudah memakai fitur-fitur terbaru PHP yang berpotensi berubah. Jangan sampai harus rush ketika PHP 8.6 rilis stabil dan menemukan breaking changes yang belum terantisipasi. Mulai tes sekarang, hemat waktu nanti.

Lihat pengumuman resmi di php.net →

4. Go 1.27 Resmi Dirilis

Go 1.27 dirilis dengan berbagai peningkatan performa dan fitur baru. Rilis Go terbaru ini selalu membawa perubahan yang berdampak pada ekosistem backend dan cloud-native development. Worth dicek kalau kamu pakai Go untuk service atau CLI tools.

Go terus menjadi pilihan utama untuk microservices dan infrastruktur cloud, dan setiap rilis major biasanya membawa perbaikan performa yang cukup signifikan. Kalau kamu sedang maintain service Go di production, sekarang waktu yang tepat untuk mulai merencanakan upgrade dan testing di environment non-produksi.

Baca announcement di go.dev →

5. Unsloth Dynamic 3.0: GGUF Lebih Cepat untuk Inference AI

Unsloth merilis Dynamic 3.0 GGUFs — format kuantisasi model AI yang lebih cepat dan efisien untuk inference lokal. Ini penting untuk developer yang menjalankan model LLM di perangkat sendiri atau di server dengan sumber daya terbatas. Optimasi di level GGUF bisa bikin perbedaan besar di kecepatan inference.

Dengan tren self-hosted AI yang makin populer, optimasi seperti ini sangat berharga. Bukan cuma soal kecepatan, tapi juga biaya — model yang lebih efisien berarti server yang lebih murah atau bahkan bisa dijalankan di hardware kelas menengah. Untuk developer yang sudah eksperimen dengan local LLM, update ini wajib dicoba.

Pelajari lebih lanjut di Unsloth →

6. OpenRouter Bergabung dengan Stripe

OpenRouter, platform populer untuk akses berbagai model AI dari berbagai provider, diakuisisi oleh Stripe. Ini menarik karena menggabungkan infrastruktur pembayaran global Stripe dengan ekosistem model AI yang luas. Bisa jadi sinyal integrasi AI dan payment makin erat di masa depan.

Akuisisi ini menjadi sinyal kuat bahwa industri AI dan fintech sedang bergerak ke arah konvergensi. Stripe yang sudah dominant di payment infrastructure kini punya foothold di ekosistem AI. Bagi developer yang membangun produk AI-powered dengan monetisasi berbasis usage, integrasi ini bisa mempermudah pipeline pembayaran di masa depan.

Baca pengumumann di OpenRouter Blog →

7. Real-Time Data di React: Ring Buffers & OffscreenCanvas

Artikel dari freeCodeCamp membahas teknik untuk menangani data real-time berfrekuensi tinggi di React, menggunakan Ring Buffers untuk manajemen memori efisien dan OffscreenCanvas untuk rendering di luar main thread. Penting untuk dashboard monitoring, visualisasi data, atau aplikasi yang butuh render cepat.

Teknik ini sangat relevan untuk developer front-end yang sering menghadapi masalah performance saat mem-render data streaming. Banyak yang masih pakai approach naive dan berakhir dengan UI yang lag. Artikel ini menjelaskan pendekatan yang lebih matang dan layak dijadikan referensi untuk proyek-proyek yang membutuhkan real-time rendering.

Baca tutorial lengkapnya di freeCodeCamp →

Secara keseluruhan, tren minggu ini menunjukkan beberapa pola menarik. Pertama, ekosistem PHP dan Laravel terus matang dengan fitur yang makin spesifik dan praktis — bukan lagi sekadar “catch up” dengan framework lain. Kedua, tools AI inference makin efisien dan terbuka, memungkinkan lebih banyak developer untuk bereksperimen dengan model lokal tanpa hardware mahal. Ketiga, integrasi antara AI dan infrastruktur bisnis (seperti payments) mulai menjadi realita, bukan lagi konsep masa depan.

Secara pribadi, berita yang paling menarik perhatian saya minggu ini adalah rilis Unsloth Dynamic 3.0. Alasannya sederhana: kemampuan menjalankan model AI dengan lebih efisien di hardware terbatas membuka peluang besar untuk developer indie dan tim kecil. Tidak semua orang punya budget untuk GPU cluster, tapi dengan optimasi seperti ini, menjalankan LLM di laptop atau VPS sudah jadi hal yang realistis. Ini langkah kecil tapi signifikan untuk demokratisasi AI.

Minggu yang produktif untuk dunia developer. Laravel makin solid dengan 13.26, PHP 8.6 sudah di beta, Go 1.27 resmi, dan tools AI open source terus berkembang pesat. Tetap semangat belajar dan jangan ragu untuk mencoba tools baru — siapa tahu ada yang bisa bikin workflow kamu lebih efisien. Selamat coding!

Hari ini saya belajar tentang perbedaan mendasar antara USB-C dan USB4 — dua istilah yang sering dipakai bergantian tapi sebenarnya merujuk pada hal yang sangat berbeda. USB-C adalah nama konektor fisik, sedangkan USB4 adalah protokol yang menentukan seberapa cepat data bergerak, seberapa besar daya yang bisa dialirkan, dan apakah video bisa dikirim lewat kabel yang sama. Artikel ini dibuat berdasarkan liputan dari Gadgets Now (Agustus 2026).

Apa Itu USB-C?

USB-C adalah spesifikasi konektor 24-pin yang didefinisikan oleh USB Implementers Forum (USB-IF). Bentuknya oval dan reversible — bisa dicolok dari arah mana saja. Satu konektor ini membawa daya, data, dan sinyal video sekaligus.

Penting untuk dipahami: konektor USB-C sendiri tidak menentukan kecepatan. Sebuah port USB-C di hp budget mungkin hanya mendukung USB 2.0 (480 Mbps), sementara port USB-C di laptop profesional bisa mendukung USB4 (40 Gbps) atau Thunderbolt 4 (40 Gbps). Bentuk fisiknya sama persis — kemampuannya ditentukan oleh protokol yang di-wiring oleh pabrikan di belakang port.

Untuk pengiriman daya, USB Power Delivery (USB PD) 3.1 berjalan melalui USB-C dengan standar terpisah yang bisa mengatur level daya antar perangkat. Profil Extended Power Range pada USB PD 3.1 bisa mengantarkan daya hingga 240W (48V, 5A) — cukup untuk mengisi daya laptop gaming dan monitor besar. Kabel USB-C yang dirating 60W punya konstruksi internal yang berbeda dari yang dirating 240W, meski konektornya identik.

Sebelumnya saya sudah belajar tentang single index dan composite index di MySQL. Tapi pertanyaan selanjutnya: bagaimana cara memastikan index yang sudah dibuat benar-benar dipakai oleh MySQL? Jawabannya ada di perintah EXPLAIN. Hari ini saya mencatat bagaimana membaca hasil EXPLAIN dan menghubungkannya dengan pemahaman tentang index.

EXPLAIN: Jendela ke Otak MySQL

EXPLAIN adalah perintah di MySQL yang menampilkan execution plan — rencana eksekusi yang akan dilakukan MySQL untuk menjalankan sebuah query. Dengan EXPLAIN, kita bisa melihat apakah index sudah terpakai, berapa banyak baris yang harus diperiksa, dan apakah ada bottleneck tersembunyi.

Cara pakainya sangat sederhana — tinggal tambahkan EXPLAIN di depan query:

-- Tambah EXPLAIN di depan SELECT
EXPLAIN SELECT * FROM users WHERE email = 'rudy@example.com';

-- Bisa juga untuk query kompleks
EXPLAIN SELECT u.nama, COUNT(o.id) AS total_order
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.status = 'active'
GROUP BY u.id;

Setiap Kolom di EXPLAIN: Apa Artinya?

Hasil EXPLAIN berupa tabel dengan beberapa kolom. Berikut penjelasan masing-masing kolom yang paling penting untuk dipahami:

1. id — Nomor Urut Query

Setiap SELECT dalam query diberi nomor id. Jika dua baris punya id yang sama, mereka dieksekusi bersama (misalnya saat JOIN). Jika id berbeda, mereka dieksekusi secara terpisah — misalnya subquery yang dijalankan untuk setiap baris dari outer query.

2. select_type — Jenis SELECT

Yang paling perlu diwaspadai adalah DEPENDENT SUBQUERY — ini artinya subquery dijalankan ulang untuk setiap baris dari tabel induk. Semakin banyak data, semakin lambat.

3. table — Tabel yang Diakses

Nama tabel atau alias yang sedang diakses. Jika tertulis <subqueryN>, berarti itu hasil materialized dari subquery nomor N.

4. type — Cara MySQL Mengambil Baris ⭐

Ini adalah kolom paling penting di EXPLAIN. Kolom type menunjukkan cara MySQL mengambil data dari tabel. Semuanya diurutkan dari yang paling cepat ke yang paling lambat:

Rumus cepat: kalau type adalah ALL atau index di tabel yang besar (ribuan baris ke atas), itu tanda ada masalah yang perlu diperbaiki.

5. possible_keys vs key — Index Kandidat vs Index Terpakai

possible_keys menunjukkan index yang bisa dipakai MySQL, sedangkan key menunjukkan index yang benar-benar dipakai. Jika key bernilai NULL, berarti MySQL memilih full table scan karena dianggap lebih cepat.

Ini kembali ke pembahasan single index vs composite index — tidak semua index yang tersedia akan dipakai. MySQL memilih index yang paling efisien berdasarkan selectivitas (seberapa banyak baris yang bisa di-filter).

6. key_len — Panjang Byte Index yang Dipakai

Menunjukkan berapa byte dari index yang benar-benar digunakan. Ini berguna untuk memahami apakah composite index terpakai penuh atau hanya sebagian. Contoh:

-- Composite index: (survei_id, deleted_at, responden_type, responden_id)
-- key_len: 8  → Hanya survei_id yang terpakai (BIGINT = 8 byte)
-- key_len: 13 → survei_id + deleted_at terpakai (8 + 5)
-- key_len: 18 → survei_id + deleted_at + responden_type terpakai

Jika key_len kecil padahal composite index-nya punya banyak kolom, berarti hanya sebagian kolom index yang aktif — bisa jadi karena ada gap di leftmost prefix (kembali lagi ke aturan composite index sebelumnya).

7. ref — Apa yang Dibandingkan dengan Index

8. rows — Estimasi Jumlah Baris yang Diperiksa ⭐

Kolom kedua paling penting setelah type. Menunjukkan berapa baris yang estimasi harus diperiksa MySQL. Semakin kecil, semakin cepat. Jika angkanya mendekati total baris di tabel, berarti filter tidak selektif atau index tidak efektif.

Catatan: angka ini adalah estimasi optimizer, bukan jumlah aktual. Untuk memastikan statistik akurat, jalankan:

ANALYZE TABLE nama_tabel;

9. Extra — Info Tambahan

Yang perlu diwaspadai: Using temporary + Using filesort bersamaan — ini menunjukkan query yang cukup mahal karena MySQL harus membuat tabel sementara DAN mengurutkannya tanpa bantuan index.

Red Flags: Tanda-tanda Query Bermasalah

Setelah memahami setiap kolom, berikut ringkasan tanda-tanda yang harus diwaspadai saat membaca hasil EXPLAIN:

• type: ALL di tabel lebih dari 1.000 baris → full table scan, index tidak terpakai
• select_type: DEPENDENT SUBQUERY → subquery dijalankan ulang N× per baris outer query
• key: NULL padahal possible_keys ada → MySQL menolak index karena dianggap tidak efisien
• rows mendekati total baris tabel → filter tidak selektif
• Extra: Using intersect() → MySQL harus menggabungkan 2 index (index merge), lebih baik pakai composite index tunggal

Studi Kasus: Dari EXPLAIN ke Perbaikan

Mari kita lihat contoh nyata. Misalnya ada query survei yang hasil EXPLAIN-nya menunjukkan masalah:

EXPLAIN SELECT
  s.nama,
  (SELECT COUNT(*)
   FROM v2_survei_pertanyaan p
   WHERE p.survei_id = s.id
     AND p.deleted_at IS NULL
     AND p.is_required = 1) AS pertanyaan_wajib,
  (SELECT COUNT(*)
   FROM v2_survei_respon r
   WHERE r.survei_id = s.id
     AND r.deleted_at IS NULL
     AND r.responden_type = 'tendik'
     AND r.responden_id = 1536) AS pertanyaan_dijawab
FROM v2_survei s
WHERE s.deleted_at IS NULL;

Hasil EXPLAIN-nya:

Ada tiga masalah yang bisa diidentifikasi:

Masalah 1: Row 3 — 26.585 baris diperiksa per subquery. Dengan 48 survei, total baris yang harus diperiksa: 48 × 26.585 = ~1,27 juta baris. Penyebabnya: index (deleted_at, responden_type, survei_id, responden_id) tidak efisien untuk query yang filter by survei_id dulu — karena survei_id bukan kolom paling kiri di index.

Masalah 2: DEPENDENT SUBQUERY di row 2 dan 3. Kedua subquery di SELECT dijalankan ulang untuk setiap baris dari v2_survei. Ini pola yang harus dihindari.

Masalah 3: Kolom key_len hanya 8. Artinya dari composite index yang tersedia, hanya satu kolom yang terpakai. Sisa kolom index sia-sia.

Perbaikan: Tambah Index yang Benar

Karena query filter by survei_id duluan, survei_id harus jadi kolom pertama di composite index:

-- Urutan kolom mengikuti urutan filter di query:
-- WHERE survei_id = ? AND deleted_at IS NULL
--   AND responden_type = ? AND responden_id = ?
ALTER TABLE v2_survei_respon
  ADD INDEX idx_respon_fix (survei_id, deleted_at, responden_type, responden_id);

Perbaikan Lebih Baik: Rewrite ke JOIN

Selain menambah index, rewrite query dari DEPENDENT SUBQUERY ke JOIN bisa menghilangkan masalah secara total:

SELECT
  s.nama,
  COUNT(DISTINCT IF(
    p.is_required = 1 AND p.deleted_at IS NULL,
    p.id, NULL
  )) AS pertanyaan_wajib,
  COUNT(DISTINCT IF(
    r.responden_type = 'tendik' AND r.responden_id = 1536
    AND r.deleted_at IS NULL,
    r.id, NULL
  )) AS pertanyaan_dijawab
FROM v2_survei s
  INNER JOIN v2_survei_pertanyaan p
    ON p.survei_id = s.id
    AND p.deleted_at IS NULL
    AND p.jenis = 'pertanyaan'
    AND p.is_required = 1
  LEFT JOIN v2_survei_respon r
    ON r.survei_id = s.id
    AND r.deleted_at IS NULL
    AND r.responden_type = 'tendik'
    AND r.responden_id = 1536
    AND r.pertanyaan_id = p.id
WHERE s.deleted_at IS NULL
GROUP BY s.id, s.nama;

Query ini menjalankan scan sekali saja tanpa subquery berulang. Tapi ingat, keuntungan JOIN baru terasa jika jumlah baris di tabel cukup besar — untuk tabel kecil (48 baris), perbedaan waktunya mungkin tidak signifikan.

Hubungan EXPLAIN dengan Composite Index

Setelah memahami EXPLAIN, kita bisa memverifikasi apakah composite index yang dibuat sudah optimal. Beberapa poin kunci:

Pertama, perhatikan key_len. Jika composite index punya 4 kolom tapi key_len hanya menunjukkan 1 kolom, berarti ada kolom tengah yang di-skip. Ini kembali ke aturan leftmost prefix rule — MySQL tidak bisa melompati kolom di tengah composite index.

Kedua, jika Extra menunjukkan Using intersect(), artinya MySQL harus menggabungkan dua index secara terpisah (index merge). Ini kurang efisien dibandingkan satu composite index yang menampung semua kolom filter.

Ketiga, pastikan urutan kolom di composite index sesuai dengan urutan filter di query. Jika query selalu filter survei_id dulu, survei_id harus jadi kolom pertama di index. Kalau ada query lain yang filter tanpa survei_id, buat index terpisah untuk query tersebut — satu composite index tidak bisa melayani semua pola filter.

Cheat Sheet: Membaca EXPLAIN dengan Cepat

Berikut panduan cepat untuk memeriksa hasil EXPLAIN:

1. Cek kolom type — pastikan bukan ALL di tabel besar
2. Cek kolom key — jika NULL padahal seharusnya ada index, investigasi lebih lanjut
3. Cek kolom rows — pastikan angka tidak mendekati total baris di tabel
4. Cek kolom Extra — waspadai Using temporary, Using filesort, atau Using intersect()
5. Cek kolom key_len — pastikan composite index terpakai penuh (bukan hanya kolom pertama)
6. Jika ada DEPENDENT SUBQUERY, pertimbangkan rewrite ke JOIN

Kesimpulan

EXPLAIN adalah alat wajib sebelum mengoptimasi query. Tanpa EXPLAIN, kita hanya menebak-nebak. Dengan EXPLAIN, kita bisa melihat secara persis bagaimana MySQL merencanakan eksekusi query kita — index mana yang dipakai, berapa baris yang diperiksa, dan bottleneck di mana.

Tambahan index tanpa EXPLAIN ibarat obat tanpa diagnosis — mungkin cocok, mungkin tidak. Tapi dengan EXPLAIN, kita tahu persis masalahnya dan bisa memilih solusi yang tepat: menambah index baru, memperbaiki urutan kolom composite index, atau merewrite query dari subquery ke JOIN.

Seri belajar MySQL ini terus berlanjut. Setelah memahami perbedaan single dan composite index, sekarang kita punya cara untuk memverifikasi apakah index yang dibuat benar-benar bekerja.

Sumber

• MySQL 8.0 Reference Manual — EXPLAIN Output Format
• MySQL 8.0 — Multi-Column Indexes
• Use The Index, Luke — SQL Index Anatomy
• Catatan Rudy — Single Index vs Composite Index di MySQL