Author: Mohammad Sani Suprayogi

  • Menikmati Libur Hari Senin

    Hari ini Senin ini saya masih dapat libur perusahaan dalam rangka hari raya Idulfitri. Rasanya agak aneh, hari Senin pagi tidak perlu segera bergegas bangun dan melakukan rutinitas pagi sebelum berangkat ke kantor. Hari ini cukup selaw.

    Kami menghabiskan waktu hari Senin ini dengan mengunjungi beberapa tempat di mal, salah satunya adalah Starbucks di lantai 5 Plaza Senayan.

    Lokasinya cukup unik, jika dari lantai dasar itu tangga eskalatornya tidak akan terlihat. Awalnya kami juga kebingungan untuk menuju kesana, berdasarkan informasi dari pak sekuriti, ternyata sampai di lantai 3 harus berjalan ke arah Sogo (?) kemudian barulah disitu akan ada tangga eskalator.

    Naik eskalator itu sebanyak 2 lantai nanti akan bertemu dengan toko buku, nah lokasi Starbucks ada di sekitar situ.

    Bagaimana Starbucks? standar saja, normal seperti Starbucks pada umumnya. Tapi rasanya menyenangkan saja bisa main kesitu di hari Senin siang hahaha.

  • Kembali ke Jakarta

    Hari ini saya sudah kembali ke Jakarta, perjalanan menggunakan kereta api Taksaka pagi yang saya pikir bakalan sepi, rupanya tetap ramai dengan pemudik yang sudah mulai kembali ke kota asal.

    Perjalanan lancar dan tepat waktu, suasana kereta juga riuh dengan anak-anak yang ikut serta di perjalanan ini. Sepanjang jalan cuaca juga cerah, paling sempat hujan deras ketika melewati Bekas, tapi sesampai di Gambir sudah cerah.

    Awalnya kami mau menggunakan MRT untuk menuju ke kosan, tapi melihat banyaknya bawaan dari Jogja, akhirnya memutuskan untuk menggunakan taksi Green SM yang sudah biasanya standby di pintu pejalan kaki Stasiun Gambir.

    Tips untuk naik Green SM dari situ adalah, pastikan gunakan aplikasi dengan mode Green Now, kemudian sebelum masuk pastikan sebutkan bahwa mau pakai Green Now. Karena kalau tidak maka sopir akan berusaha menggunakan argo. Jadi pastikan selalu bilang di awal ya. Oh iya, siapkan 5 ribu rupiah untuk parkir.

    Jakarta sore ini cukup lengang, titik kemacetan yang biasanya ada di Bundaran HI, Sudirman, Senayan, dan Blok M tidak terlalu terlihat. Perjalanan cukup lancar hingga sampai ke kosan.

    Akhirnya usai sudah ritual mudik kami yang sengaja diakhiri lebih awal, selain karena hari Selasa mendatang saya sudah mulai ngantor, juga untuk mengurangi keterlibatan acara halalbihalal yang bisa berlangsung sangat panjang dan lama. Bukan kenapa-napa, selain sudah nggak kenal dengan yang ditemui, juga harus mempersiapkan jawaban dari pertanyaan yang selalu kami hindari selama ini wkwkwk.

    Hello Jakarta!

  • Siapa yang Paling Jago Bohong Pakai AI

    Semenjak saya hiatus dari media sosial, ada beberapa informasi yang terlewatkan dan tidak termonitor, salah satunya adalah berita perang antara AS + Israel melawan Iran. Saya tidak tertarik dengan isi perangnya, tapi lebih ke senjata lain yang diluncurkan, yaitu berita palsu.

    Mulai dari video rudal yang menghujani kota, hingga berita mengejutkan soal kematian pemimpin negara. Masalahnya satu: sebagian besar dari berita itu adalah palsu (hoaks) yang dibuat menggunakan AI.

    Di medan perang modern, AI bukan cuma soal robot tempur, tapi soal Deepfake dan Generative Image. Tujuannya bukan lagi sekadar menghancurkan gedung, tapi menghancurkan logika dan ketenangan kita.

    Ada tiga fungsi utama AI sebagai senjata informasi saat ini:

    1. Mengaburkan Fakta (Clouding the Truth): Saat berita asli dan buatan AI bercampur aduk, orang jadi tidak tahu mana yang benar. Akhirnya, kita jadi skeptis pada semuanya—bahkan pada kebenaran sekalipun.
    2. Menciptakan Kebingungan Massal: Bayangkan melihat video pemimpin negara mengumumkan menyerah atau meninggal, padahal beliau sedang minum teh di kantornya. Dalam hitungan detik, pasar saham bisa anjlok dan warga panik hanya karena video buatan mesin.
    3. Memancing Emosi dan Kebencian: AI bisa membuat foto korban perang yang sangat dramatis (meskipun fiktif) untuk memancing amarah netizen. Tujuannya? Agar kita saling hujat dan terpecah belah di kolom komentar.

    Bagaimana Kita Melawan?

    Kita tidak butuh senjata canggih untuk melawan ini. Kita hanya butuh Skeptisisme Sehat:

    • Jangan langsung “Share”: Berita bombastis biasanya sengaja dibuat agar kita kaget dan langsung membagikannya.
    • Cek Media Arus Utama: Jika berita sebesar “Kematian Pemimpin Negara” tidak ada di TV nasional atau kantor berita resmi (seperti Antara, BBC, atau Reuters), fiks itu hoaks.
    • Cari Kejanggalan Visual: Perhatikan detail kecil seperti bayangan yang aneh, jumlah jari, atau suara yang terdengar “datar” tanpa emosi manusia.

    Perang informasi ini menyerang pikiran kita. Jangan biarkan jempol kita menjadi “tentara” bagi mereka yang ingin menyebarkan kekacauan.

    Saring sebelum sharing, karena sekarang melihat belum tentu berarti percaya.

  • Selamat Lebaran 1447 H

    Mohon maaf lahir dan batin, hari ini kami sudah berlebaran, berbeda dengan tanggal yang ditetapkan oleh Pemerintah. Tidak mengapa karena ini juga bukan pertama kalinya terjadi.

    Semoga kita semua diberi kesehatan sehingga bisa berjumpa dengan Ramadhan tahun depan dan menjadi orang yang lebih baik daripada sebelumnya.

    Tidak perlu membahas mengenai perbedaan hari, karena yang penting yakin dengan apa yang sudah diyakini.

    Selamat Lebaran 1447 H
  • Mengambil Hak Orang Lain Tanpa Sadar

    Pagi tadi, saat menyetir ke perjalan mudik, awalnya perjalanan lancar karena kami berangkat dari Jogja tepat sehabis Subuh. Setiba di Pasar Ambarawa kami tertahan hampir 15 menit lamanya karena kemacetan yang menurut saya tidak perlu terjadi.

    Setelah 15 menit berlalu dan kami berhasil melewati kemacetan itu, saya membayangkan terkadang kita itu sering mengambil hak orang lain tanpa sadar.

    Apa saja contohnya?

    1. Menahan traffic. Misalnya ketika berjalan pelan di lajur yang tidak semestinya, memotong kendaraan lain dengan agresif, menyeberang jalan sesuka hati, memutar balik pada area terlarang.
    2. Tidak lurus saf saat shalat berjamaah. Tumit tidak berada di dalam area namun malah lebih mundur ke belakang, akibatnya mengambil area sujud jamaah di belakangnya.
    3. Parkir mobil di jalan depan rumah, mengakibatkan kendaraan tetangga kesulitan untuk lewat atau parkir di garasinya. Punya dua mobil padahal garasi cuma satu, atau malah punya mobil tapi nggak punya garasi.
    4. Tidak mengembalikan uang atau barang yang dipinjam.

    Masih banyak banget contoh korupsi dan pencurian kecil-kecilan ini. Biasanya semua dilakukan tanpa sadar karena selama ini tidak ada yang menegur, sehingga merasa yang dilakukan itu wajar dan tidak salah.

    Padahal, ketika kita melakukan itu dan ada doa dari orang lain yang terambil haknya, maka semua dosa akan berpindah, rezeki akan ditukar, dan kita menjadi merugi.

    Tulisan ini saya buat sebagai pengingat ke diri sendiri supaya selalu menjaga lisan dan perilaku. Mudah-mudahan di hari terakhir Ramadhan ini kami dan kita semua bisa menjadi manusia yang lebih baik daripada sebelumnya.

    Aamiin.

  • Tips Berobat ke Rumah Sakit

    Hari ini rencananya kami sudah harus berpindah kota untuk merayakan lebaran, namun tidak disangka istri sakit hingga perlu dibawa ke rumah sakit. Alhamdulillah RS AMC Muhammadiyah berlokasi dekat dengan tempat tinggal dan memberikan pelayanan yang prima.

    Saat perjalanan pulang, saya membayangkan bahwa tidak semua orang mengerti cara berobat ke rumah sakit, terutama untuk yang tidak menggunakan BPJS Kesehatan melainkan menggunakan asuransi dari perusahaan.

    Sebagai informasi, asuransi dari perusahaan itu biasanya akan terbagi menjadi dua, yaitu asuransi rawat jalan dan rawat inap.

    Rawat jalan digunakan untuk berobat jalan dan langsung pulang, sedangkan rawat inap digunakan untuk berobat dengan menginap di rumah sakit dulu/mondok.

    Sebelum Anda atau anggota keluarga mengalami sakit, ada baiknya untuk memahami detil asuransi Anda dan bagaimana cara menggunakannya di rumah sakit.

    Perhatikan benefit dan limit asuransinya, apa saja yang dicover dan tidak, apa saja syaratnya jika ada. Ini hal penting yang harus dihapal supaya ketika saatnya tiba, tidak panik dan bisa membuat keputusan dengan bijak.

    Setiap rumah sakit biasanya akan memiliki sistem antrian. Jika sakitnya tidak darurat, Anda bisa langsung berobat ke poli sesuai dengan kebutuhannya. Misalnya sakit gerd, bisa langsung menuju ke poli spesialis penyakit dalam. Pengen scaling gigi, bisa mendaftar ke poli gigi.

    Jika darurat gimana? Langsung menuju ke IGD saja.

    Jika asuransi Anda bersifat cashless, maka ini akan sangat mempermudah prosesnya. Cukup berikan kartu fisik atau digital ke petugas jaga, selanjutnya silakan fokus pada perawatan. Asuransi kesehatan cashless adalah pilihan terbaik, jika ada opsi itu maka gunakan!

    Jika asuransi Anda bersifat reimburse, maka pastikan Anda memiliki dana darurat atau kartu kredit yang bisa digunakan untuk membayar biaya perawatan terlebih dulu. Nanti di rumah sakit bilang akan menggunakan jalur Umum, bukan asuransi.

    Setelah perawatan selesai, pada saat di kasir pastikan Anda bilang untuk dibantu dibuatkan kwitansi pendukung guna reimbursement asuransi. Tenang saja, 99,9999% petugas kasir di rumah sakit sudah sangat paham prosesnya dan biasanya mereka akan dengan senang hati membantu.

    Pastikan semua dokumen disimpan dan didokumentasikan supaya proses klaim reimburse ke asuransi berjalan lancar. Memamg terasa ribet tapi itu adalah usaha yang tidak akan mengkhianati hasil.

    Saya cukup terbiasa berurusan dengan bagian administrasi rumah sakit. Saya setuju denga joke bahwa area paling menakutkan di rumah sakit itu bukanlah kamar mayat, melainkan kasir. Setidaknya yang berada di kamar mayat tidak akan menagih pembayaran wkwkwk.

    Maka dari itu, dengan memiliki asuransi dan memahami, ingat kuncinya memahami benefit dan limitnya, setidaknya akan membantu Anda untuk melewati area terseram itu, sehingga Anda cukup fokus pada pengobatan dan recovery.

    Oh iya, jika Anda melakukan tindakan operasi itu biasanya perlu melakukan kontrol. Jika menggunakan asuransi, maka pada saat kontrol itu biayanya masih ditanggung oleh asuransi yang sama, syaratnya adalah jangan melewatkan janji temu dan pastikan membawa surat pengantarnya.

    Semoga kita semua selalu sehat-sehat.

  • Memadukan DuckDB dan Python untuk Pivot Table

    Saya dapat saran dari beberapa kawan (thanks kang Zam dan mas Bernard) pada artikel memproses 600 ribu baris data kemarin untuk menggunakan library Pandas dan DuckDB supaya pemrosesan datanya lebih cepat dan efisien.

    Setelah melakukan riset beberapa saat, saya memutuskan untuk mencobanya meskipun baru dilakukan di branch untuk melihat hasilnya terlebih dulu sebelum merge ke master.

    Apa yang saya dapatkan?

    Hasilnya, DuckDB (dengan dikombinasikan dengan Pandas) ini membuat aplikasi saya bisa berjalan dengan lebih cepat. Saya memang tidak melakukan benchmark dengan detil ya, saya cuma membandingkan waktu pemrosesan saja, dimana untuk 600 ribu data ini sekarang bisa diproses 30 detik lebih cepat.

    Ini sangat bagus, karena 600 ribu data ini baru permulaan, nantinya akan bisa bertambah dan saya prediksi di akhir tahun nanti bisa tembus 4 juta baris. Tentunya kalau masih diproses dengan metode streaming aggregation akan membuat OOM lagi.

    Pertanyaan muncul: Haruskah semua logika dilakukan di dalam SQL (DuckDB), ataukah lebih baik menyerahkannya ke Python? Kasusnya sederhana: Saya harus memproses data transaksi (CSV), melakukan filter, agregasi, dan menyajikannya dalam bentuk Pivot Table (per bulan).

    Inilah alasan mengapa strategi “DuckDB untuk Heavy Lifting, Python untuk Reshaping” adalah pemenangnya.

    Saya membagi proses menjadi dua tahap kritis:

    1. Tahap Otot (DuckDB)

    Saya menyerahkan tugas berat ke DuckDB. Mengapa? Karena DuckDB adalah database columnar yang menggunakan eksekusi vektor (C++). Ia sangat cepat dalam memindai ribuan baris.

    • Tugas: Filter data (buang beberapa data yang tidak diperlukan) dan lakukan SUM(total_bill) dengan GROUP BY.
    • Hasil: Data mentah sebanyak 600 ribu baris dipangkas menjadi hanya ~100-500 baris data agregat.

    Sebelum data masuk ke DuckDB, ada satu optimasi lagi yang saya terapkan di level CSV parsing. Alih-alih menggunakan csv.reader bawaan Python lalu menyisipkan baris per baris dengan executemany(), saya menggunakan kombinasi Pandas + Apache Arrow protocol.

    Baca CSV dengan pandas, hanya kolom yang diperlukan

    df = pd.read_csv(
    buffer,
    usecols=[0, 5, 9, 10, 13, 16], # invoice_month, sku, total_bill, source, service_group, bill_org
    dtype=str,
    )

    Bulk insert via Arrow fast-path (zero-copy)

    conn.register("_temp_csv", df)
    conn.execute("INSERT INTO billing SELECT * FROM _temp_csv")

    Apa keuntungannya?

    1. Column Pruning — Dari 17 kolom di CSV, saya hanya membaca 6 kolom yang diperlukan. Kolom lain di-skip sejak awal, menghemat memori dan waktu parsing.
    2. Zero-Copy Transfer — DuckDB menerima DataFrame dari Pandas via Apache Arrow protocol tanpa menyalin data (zero-copy). Ini jauh lebih cepat dibanding executemany() yang melakukan iterasi Python-level untuk setiap baris.
    3. Vectorized Parsing — Parser CSV-nya Pandas ditulis dalam C/Cython, sehingga jauh lebih cepat dari csv.reader murni Python.

    Dengan kombinasi ini, pipeline dari “file CSV di Google Drive” hingga “siap di-query di DuckDB” menjadi sepenuhnya vektorisasi, tidak ada lagi Python-level loop di tahap loading.

    2. Tahap Otak/Fleksibilitas (Python)

    Setelah data menjadi kecil, saya menggunakan Python (defaultdict) untuk melakukan pivoting (mengubah baris menjadi kolom bulan).

    • Tugas: Mengatur ulang data dari bentuk (key, month, total) menjadi struktur {key: {month: total}}.

    Mungkin Anda bertanya, “DuckDB kan punya fungsi PIVOT, kenapa tidak dipakai saja?” Jawabannya adalah Dynamic Columns.

    1. Masalah Compile-Time: SQL PIVOT biasanya perlu tahu nama kolomnya dari awal (misal: Januari, Februari, dst). Jika bulan bertambah, kueri SQL harus diubah secara dinamis. Ini menambah kompleksitas kode (Dynamic SQL generation).
    2. Efisiensi Manusia vs Mesin: Menulis generator SQL yang kompleks hanya untuk menghemat beberapa milidetik pada data yang sudah kecil (~500 baris) tidaklah sebanding. Python jauh lebih fleksibel dalam menangani kunci (bulan) baru secara otomatis.
    3. Maintainability: Menggunakan defaultdict di Python jauh lebih mudah dibaca dan di-debug oleh rekan tim lain dibandingkan kueri SQL yang panjang dan penuh dengan fungsi EXECUTE.

    Kesimpulan: Menemukan “Sweet Spot“

    Analisis saya menyimpulkan bahwa pendekatan ini sudah optimal.

    • Kecepatan: Didapat dari DuckDB yang menghancurkan data besar.
    • Fleksibilitas: Didapat dari Python yang menyusun tampilan akhir tanpa peduli berapa banyak kolom bulan yang muncul.

    Pelajaran bagi kita: Jangan memaksakan satu alat untuk melakukan segalanya. Gunakan database untuk agregasi, dan gunakan bahasa pemrograman untuk formatting.

  • Sementara WFH Sampai Lebaran

    Hari Senin ini saya sedang WFH di Jogja sampai Lebaran, jadi ketika beberapa orang sudah mulai menikmati cuti dan jalan-jalan di Jogja, saya masih standby di depan laptop dulu sampai tanggal 18 Maret mendatang.

    Rasanya aneh haha. Sebab nggak terasa sudah hampir setahun ini WFO, sudah mulai punya ritme dan rutinitas, sekarang kembali lagi ke WFH yang sudah saya lakukan selama bertahun-tahun sebelumnya.

    Apa yang beda?

    WFH memang memiliki banyak keuntungan, salah satunya adalah efektivitas waktu. Sebab dengan beberapa langkah saja dari kamar, saya sudah siap untuk bekerja selama koneksi Internet dan listrik sedang bersahabat.

    Tapi, efek WFO selama hampir setahun ini memunculkan kebiasaan baru untuk membantu pekerjaan saya, salah satunya adalah kecepatan koordinasi.

    Memang tidak dipungkiri, ketika kita WFH itu meskipun sudah memiliki koneksi Internet level dewa, tidak akan bisa menandingi kecepatan colek dan/atau nyamperin ke meja.

    Jadi, tadi itu rasanya ada agak terasa lambat dalam membuat keputusan atau strategi. Keputusan yang bisa didapatkan dalam hitungan menit, harus menunggu beberapa jam sampai bisa terhubung dan berkoordinasi.

    Memang ini tidak terjadi setiap hari, tapi ternyata ketika kita berada di kebiasaan baru dan kembali ke kebiasaan lama, maka situasi menjadi sedikit berbeda.

  • Mengolah 600 Ribu Baris Data di Python Tanpa Beban

    Pernah nggak Anda terjebak dengan file CSV raksasa yang membuat komputer tiba-tiba “hang” dan memunculkan pesan error OOM (Out of Memory)?

    Saya baru saja mengalaminya saat mencoba mengolah sekitar 600 ribu baris data. Rencana awal saya sederhana: unduh, muat semua ke Python, lalu olah. Tapi kenyataannya, RAM server langsung menyerah karena beban data yang terlalu masif untuk dimuat sekaligus.

    Menariknya, saya bukan seorang ahli Python. Solusi yang saya temukan bukan dari hasil begadang belajar dokumentasi, melainkan hasil dari “Vibe Coding” bersama GLM-5.

    Dulu, kode saya bekerja seperti orang yang mencoba menelan satu loyang pizza sekaligus (Metode Load-All). Tentu saja keseleg!

    Dengan Streaming Aggregation, logikanya diubah total:

    1. Makan Sesuap demi Sesuap: Data dibaca baris demi baris. Begitu satu baris selesai diproses dan poin pentingnya dicatat, baris itu langsung “dibuang” dari memori.
    2. Memory-Friendly: Karena hanya satu baris yang ada di RAM pada satu waktu, beban kerja menjadi sangat ringan. Memproses 600 ribu baris terasa seperti memproses 6 baris saja.
    3. Logika Kondisional yang Cerdas: Saya juga menyisipkan filter di tengah jalan. Data yang tidak relevan langsung dilewati sebelum sempat membebani hasil akhir.

    Alih-alih menyarankan library besar dan berat yang populer di Google, GLM-5 memberikan kode Python yang sangat sederhana (basic). Ternyata, kode standar Python justru memiliki performa terbaik untuk kasus ini karena tidak memiliki “overhead” atau beban tambahan yang sering ada pada library pihak ketiga.

    Inilah yang disebut dengan cara “Pythonic”: Sederhana, bersih, dan sangat efisien.

    Pengalaman ini membuktikan bahwa di era AI, kita tidak harus menjadi kamus berjalan untuk bahasa pemrograman. Yang paling penting adalah insting arsitektur, tahu kapan harus berhenti memuat semua data dan mulai menggunakan aliran (stream).