Blog

  • Sistem Antrian Klinik: Cara Kerja dan Kapan Membutuhkannya

    Sistem Antrian Klinik: Cara Kerja dan Kapan Membutuhkannya

    Sistem antrian klinik bekerja dengan cara sederhana: pasien mengambil nomor antrian, baik dari rumah lewat HP maupun langsung di klinik, lalu sistem mengurutkan dan memanggil nomor itu secara otomatis. Pasien bisa memantau posisi antriannya secara real time, jadi tahu kira-kira kapan gilirannya tiba. Tidak perlu duduk berjam-jam di ruang tunggu sambil menebak-nebak. Di sisi klinik, petugas pendaftaran tinggal menekan tombol panggil, dan nomor berikutnya muncul di layar display plus terdengar lewat pengeras suara.

    Di balik layar, setiap nomor antrian tersambung dengan data pasien. Saat nomor dipanggil dan pasien masuk ke ruang periksa, kunjungan itu tercatat. Klinik jadi punya riwayat: siapa datang hari ini, jam berapa, ke dokter siapa, berapa lama menunggu. Data inilah yang membedakan sistem antrian digital dengan mesin nomor urut biasa. Bukan sekadar memanggil nomor, tapi merekam seluruh alur kunjungan pasien dari daftar sampai selesai diperiksa.

    Masalah klasik antrian manual di klinik

    Hampir semua klinik yang masih pakai antrian manual mengalami pola masalah yang sama. Ruang tunggu penuh sejak pagi karena pasien datang lebih awal demi dapat nomor kecil. Padahal dokternya baru praktik jam sepuluh. Akhirnya orang menumpuk, kursi habis, dan yang datang belakangan berdiri di teras.

    Lalu ada pertanyaan yang diulang terus ke petugas: masih lama tidak ya. Petugas pendaftaran yang seharusnya fokus melayani administrasi jadi merangkap petugas informasi. Jawabannya pun sering hanya perkiraan, karena tidak ada yang benar-benar tahu antrian nomor berapa yang sedang diperiksa di dalam.

    Masalah lain yang kelihatannya sepele tapi sering bikin ribut: nomor kertas hilang. Pasien keluar sebentar cari makan, kertasnya terselip, lalu terjadi perdebatan soal siapa duluan. Dan yang paling sering memicu kekecewaan, jam praktik dokter molor tanpa ada informasi. Pasien sudah menunggu dua jam, tidak ada pengumuman apa pun, dan pilihan mereka cuma dua: terus menunggu atau pulang dengan kesal. Pengalaman seperti ini yang pelan-pelan membuat pasien pindah ke klinik sebelah.

    Komponen sistem antrian klinik dan fungsinya

    Sistem antrian klinik umumnya terdiri dari beberapa komponen yang saling terhubung. Tidak semua klinik butuh semuanya sekaligus, tapi memahami tiap bagian membantu Anda menilai mana yang relevan.

    Pengambilan nomor

    Ini pintu masuknya. Pasien bisa ambil nomor lewat beberapa jalur: datang langsung dan mengambil dari kios atau meja pendaftaran, lewat halaman web klinik, atau lewat aplikasi. Untuk klinik yang pasiennya rutin dan berlangganan, aplikasi mobile khusus pasien bisa jadi nilai tambah karena nomor antrian, riwayat kunjungan, dan pengingat jadwal kontrol ada dalam satu tempat. Kalau Anda penasaran seperti apa bentuknya, layanan pembuatan aplikasi mobile biasanya mencakup skenario seperti ini.

    Display antrian

    Layar di ruang tunggu yang menampilkan nomor yang sedang dilayani, nomor berikutnya, dan poli atau dokter tujuan. Display ini mengurangi drastis pertanyaan ke petugas, karena semua orang bisa melihat sendiri posisinya. Beberapa klinik menambahkan estimasi waktu tunggu, meski angka ini sebaiknya ditampilkan sebagai perkiraan, bukan janji.

    Notifikasi WhatsApp

    Ini komponen yang paling terasa manfaatnya bagi pasien. Setelah ambil nomor, pasien menerima pesan WA berisi nomor antrian dan tautan untuk memantau posisi. Saat antriannya tinggal beberapa nomor lagi, sistem mengirim pengingat supaya pasien segera merapat. Efeknya, pasien tidak harus menunggu di klinik. Mereka bisa menunggu di rumah atau sambil beraktivitas, dan ruang tunggu jadi jauh lebih lega.

    Dashboard admin

    Bagian yang dilihat petugas dan pemilik klinik. Dari sini petugas memanggil nomor, memindahkan pasien antar poli, atau menandai pasien yang tidak hadir. Pemilik klinik bisa melihat laporan: jumlah kunjungan per hari, jam-jam paling ramai, rata-rata waktu tunggu, sampai dokter mana yang antriannya paling panjang. Laporan seperti ini berguna saat mengambil keputusan, misalnya menambah jadwal dokter di jam sibuk.

    Sistem antrian saja atau sekalian booking jadwal dokter

    Dua istilah ini sering tertukar, padahal fungsinya berbeda. Sistem antrian mengurus urutan pasien pada hari itu. Siapa pun yang ambil nomor hari ini, dialah yang masuk daftar. Cocok untuk klinik dengan pola kedatangan langsung, seperti klinik umum atau praktik dokter yang pasiennya datang tanpa janji.

    Booking jadwal dokter melangkah lebih jauh. Pasien memilih dokter, tanggal, dan slot jam dari beberapa hari sebelumnya. Sistem seperti ini cocok untuk layanan yang butuh alokasi waktu jelas, misalnya dokter gigi, klinik kecantikan, atau fisioterapi, karena satu pasien bisa memakan waktu 30 sampai 60 menit.

    Banyak klinik akhirnya memakai kombinasi keduanya: pasien booking mendapat slot jam, pasien datang langsung masuk antrian reguler, dan sistem menggabungkan keduanya dalam satu urutan yang adil. Yang penting dipahami, kebutuhan Anda menentukan bentuk sistemnya. Klinik umum ramai mungkin cukup sistem antrian. Klinik gigi dengan dua dokter spesialis hampir pasti lebih butuh booking.

    Kapan klinik belum butuh, dan kapan sudah waktunya

    Jujur saja, tidak semua klinik butuh sistem antrian digital. Kalau praktik Anda melayani lima sampai sepuluh pasien sehari dengan satu dokter, antrian manual masih sangat bisa jalan. Pasien datang, duduk, dipanggil sesuai urutan kedatangan. Menambah sistem digital di kondisi ini hanya menambah biaya dan hal baru yang harus dipelajari petugas, tanpa manfaat yang sepadan.

    Tanda-tanda klinik mulai butuh sistem antrian biasanya muncul sendiri:

    • Ruang tunggu rutin penuh dan pasien mengeluh soal lama menunggu, baik langsung maupun lewat ulasan Google.
    • Petugas pendaftaran kewalahan menjawab pertanyaan posisi antrian sampai pekerjaan administrasinya keteteran.
    • Klinik punya lebih dari satu poli atau lebih dari satu dokter yang praktik bersamaan, sehingga urutan manual mulai kacau.
    • Jumlah pasien harian sudah di atas 30 sampai 50 orang dan terus bertambah.
    • Pasien sering pulang sebelum dipanggil karena tidak sanggup menunggu tanpa kepastian.

    Kalau dua atau tiga poin di atas sudah terjadi di klinik Anda, itu sinyal yang cukup jelas. Menunda justru membuat masalahnya menumpuk, karena keluhan pasien soal antrian termasuk yang paling cepat menyebar dari mulut ke mulut.

    Bikin custom atau pakai aplikasi jadi

    Begitu memutuskan butuh sistem antrian, pilihannya ada dua: berlangganan aplikasi jadi atau membangun sistem sendiri. Dua-duanya punya sisi kuat dan lemah, dan tidak ada jawaban yang benar untuk semua klinik.

    Aplikasi jadi unggul di kecepatan dan biaya awal. Daftar hari ini, besok sudah bisa dipakai. Biayanya berbentuk langganan bulanan, biasanya ratusan ribu sampai beberapa juta rupiah tergantung fitur. Kekurangannya, Anda mengikuti alur kerja yang sudah ditentukan vendor. Kalau klinik punya alur khusus, misalnya pasien BPJS dan umum dipisah jalurnya, atau ingin antrian tersambung ke sistem internal yang sudah ada, sering kali aplikasi jadi tidak bisa mengakomodasi. Data pasien juga tersimpan di server vendor, jadi pastikan Anda membaca ketentuan kepemilikan datanya.

    Sistem custom kebalikannya. Biaya awal lebih besar dan butuh waktu pengembangan beberapa minggu sampai beberapa bulan. Tapi alurnya mengikuti cara kerja klinik Anda, bukan sebaliknya. Fitur bisa bertahap: mulai dari antrian dan notifikasi WA dulu, lalu berkembang ke booking, rekam kunjungan, sampai laporan keuangan. Sistemnya milik Anda sepenuhnya, tanpa biaya langganan per bulan yang berjalan terus. Dari pengalaman kami membangun sistem aplikasi custom untuk berbagai jenis usaha, pola yang paling sering berhasil adalah mulai dari modul yang paling sakit dulu, dalam kasus klinik biasanya antrian, lalu menambah modul lain setelah tim terbiasa.

    Aturan praktisnya begini. Kalau kebutuhan Anda standar dan anggaran terbatas, mulai dari aplikasi jadi. Kalau alur klinik Anda punya kekhususan, pasiennya sudah ramai, atau Anda ingin sistem yang tumbuh mengikuti klinik dalam jangka panjang, custom lebih masuk akal secara hitungan beberapa tahun ke depan.

    Pertanyaan yang sering muncul

    Bagaimana dengan pasien lansia yang tidak pakai HP?

    Sistem antrian yang baik tidak pernah menutup jalur offline. Pasien lansia tetap bisa datang langsung dan mengambil nomor di meja pendaftaran, dibantu petugas. Sistem menggabungkan nomor online dan offline dalam satu urutan, jadi tidak ada yang dirugikan. Notifikasi juga bisa dikirim ke nomor WA anggota keluarga yang mengantar.

    Apakah semua pasien harus daftar online?

    Tidak. Jalur online sifatnya pilihan, bukan kewajiban. Praktiknya, klinik biasanya membagi kuota, misalnya sebagian nomor untuk pendaftaran online dan sisanya untuk pasien datang langsung. Porsi ini bisa diatur sesuai karakter pasien klinik Anda. Kalau mayoritas pasien terbiasa datang langsung, sistem tetap berjalan normal, hanya saja manfaat pantau antrian dari rumah baru terasa bagi yang memakai jalur online.

    Bisakah sistem antrian terintegrasi dengan rekam medis?

    Bisa, dan justru di sinilah nilai jangka panjangnya. Saat nomor antrian tersambung ke data pasien, kunjungan hari itu otomatis masuk ke riwayat. Dokter bisa membuka catatan pemeriksaan sebelumnya begitu pasien masuk ruang periksa. Untuk sistem custom, integrasi ini dirancang sejak awal. Untuk aplikasi jadi, tergantung apakah vendor menyediakan fitur rekam medis atau API untuk disambungkan ke sistem lain, jadi tanyakan hal ini sebelum berlangganan.

    Mulai dari mana

    Langkah pertama tidak harus langsung beli atau bangun sistem. Mulailah dengan memetakan alur pasien di klinik Anda sekarang: dari datang, daftar, menunggu, diperiksa, sampai pulang. Catat di titik mana penumpukan paling sering terjadi. Peta sederhana ini akan membuat diskusi dengan vendor mana pun jadi jauh lebih terarah, dan mencegah Anda membayar fitur yang tidak dibutuhkan.

    Kalau Anda ingin mendiskusikan alur klinik Anda dan menimbang apakah lebih cocok aplikasi jadi atau sistem custom, tim Arrazy Inovasi terbuka untuk ngobrol tanpa komitmen. Silakan hubungi kami lewat halaman kontak, ceritakan kondisi klinik Anda, dan kami bantu petakan opsinya.

  • Aplikasi Manajemen Proyek Konstruksi: Biar Anggaran Tidak Kabur

    Aplikasi Manajemen Proyek Konstruksi: Biar Anggaran Tidak Kabur

    Aplikasi manajemen proyek konstruksi mengerjakan empat hal inti. Membandingkan RAB dengan realisasi biaya, mencatat progres tiap item pekerjaan, memantau material yang masuk dan keluar gudang, serta merekap upah dan kasbon tukang. Semua tercatat di satu sistem, bukan tersebar di buku tulis, tumpukan nota, dan chat WhatsApp. Anda buka aplikasi, posisi proyek hari ini langsung kelihatan.

    Buat kontraktor yang pegang dua atau tiga proyek sekaligus, bedanya terasa besar. Anda tidak perlu menunggu rekap akhir bulan untuk tahu proyek A sudah menghabiskan biaya berapa. Owner tanya progres, Anda jawab dengan angka, bukan perkiraan. Artikel ini membahas modul apa saja yang penting, siapa yang harus input data di lapangan, kapan spreadsheet masih cukup, dan seperti apa proses membangunnya kalau Anda memutuskan butuh.

    Masalah klasik proyek yang dicatat manual

    Ceritanya hampir selalu mirip. Ada proyek renovasi rumah dua lantai. Mandor belanja material pakai uang kas, bonnya diselipkan di dashboard mobil. Sebagian sampai ke admin, sebagian hilang entah ke mana. Dua minggu kemudian tidak ada yang ingat semen kemarin itu 30 sak atau 40 sak.

    Lalu ada kasbon. Tukang minta kasbon 500 ribu hari Rabu, dicatat di kertas. Hari Sabtu gajian, kertasnya tidak ketemu. Mau motong gaji tidak enak karena tidak ada bukti, tidak dipotong berarti perusahaan yang nombok. Kejadian sekali dua kali mungkin kecil. Kalau tukangnya dua puluh orang dan proyeknya jalan paralel, bocornya lumayan.

    Yang paling sering bikin canggung justru pertanyaan sederhana dari owner: “Progresnya sudah berapa persen?” Jawaban andalannya “sekitar 70 persen”. Angka itu dari perasaan, bukan dari data bobot pekerjaan. Owner percaya saja di awal. Tapi begitu minggu depan jawabannya masih “sekitar 70 persen”, kepercayaan mulai turun.

    Skala lebih besar, masalahnya ikut membesar. Kontraktor perumahan kecil yang membangun sepuluh unit sekaligus harus tahu biaya per unit, bukan cuma total. Pengembang ruko dua pintu perlu memisahkan mana pengeluaran pintu A dan mana pintu B. Dicatat manual, semua campur jadi satu tumpukan nota. Akhirnya hitung untung rugi per unit cuma bisa dikira-kira.

    Puncaknya di akhir proyek. RAB bilang 400 juta, realisasi ternyata 460 juta. Selisih 60 juta itu baru ketahuan saat semua nota dikumpulkan dan dihitung. Sudah tidak bisa diapa-apakan. Padahal kalau selisihnya kelihatan sejak minggu ketiga, masih ada waktu untuk menekan biaya di pekerjaan berikutnya atau negosiasi ulang dengan owner.

    Modul yang benar-benar dipakai di lapangan

    Aplikasi manajemen proyek tidak perlu punya seratus fitur. Dari kebutuhan yang paling sering muncul, modul intinya ada lima.

    RAB vs realisasi

    Ini jantungnya. RAB diinput per item pekerjaan di awal proyek. Setiap pengeluaran dicatat dan menempel ke item yang sesuai. Sistem menghitung selisihnya secara berjalan. Anda bisa lihat item galian tanah masih aman, tapi pekerjaan besi sudah lewat anggaran 8 persen. Ketahuan dini, bisa dikoreksi dini.

    Progres pekerjaan

    Tiap item pekerjaan punya bobot. Pasang keramik lantai satu selesai, mandor update statusnya, progres keseluruhan terhitung otomatis dari bobot. Jadi angka “72 persen” itu hasil hitungan, bukan tebakan. Kalau ditambah foto lapangan, owner bahkan tidak perlu datang ke lokasi untuk yakin.

    Material masuk dan keluar

    Material datang dari supplier, dicatat masuk. Dipakai untuk pekerjaan tertentu, dicatat keluar. Sisa stok kelihatan. Modul ini yang paling cepat terasa manfaatnya karena material biasanya porsi terbesar dari biaya proyek, dan paling gampang bocor. Beda antara catatan dan fisik langsung memicu pertanyaan, bukan didiamkan sampai proyek selesai.

    Upah dan kasbon tukang

    Absensi atau opname kerja tukang dicatat, kasbon dicatat di hari yang sama. Saat gajian, sistem sudah menghitung upah bersih setelah potong kasbon. Tidak ada lagi debat soal kasbon yang katanya sudah dibayar atau belum.

    Laporan untuk owner

    Rekap progres, biaya, dan dokumentasi foto yang bisa dikirim berkala. Kelihatannya sepele, tapi laporan rapi itu alasan owner memakai jasa Anda lagi di proyek berikutnya. Kontraktor yang transparan soal angka jauh lebih gampang dipercaya.

    Siapa yang input data? Ini tantangan sebenarnya

    Di sinilah banyak sistem gagal, dan kami tidak mau menutupi itu. Aplikasi sebagus apa pun tidak berguna kalau tidak ada yang mengisi datanya. Mandor di lapangan sibuk. Tangannya kotor, sinyal kadang jelek, dan tidak semua terbiasa dengan aplikasi.

    Cara yang realistis biasanya kombinasi. Pertama, input di lapangan dibuat sesederhana mungkin. Mandor cukup foto bon dan update status pekerjaan, selesai dalam satu menit dari HP. Kedua, pekerjaan input yang detail seperti mencocokkan bon ke item RAB dikerjakan admin di kantor. Mandor jadi sumber data mentah, admin yang merapikan.

    Ketiga, dan ini paling penting, pemilik usaha harus konsisten memakai datanya. Kalau bos tiap minggu mengecek laporan dari sistem dan bertanya berdasarkan data itu, mandor akan rajin mengisi. Kalau bos sendiri masih tanya lewat telepon dan mengabaikan sistemnya, dalam dua bulan aplikasi itu jadi pajangan. Adopsi itu soal kebiasaan tim, bukan cuma soal software.

    Kapan spreadsheet masih cukup

    Jujur saja, tidak semua kontraktor perlu aplikasi custom. Kalau Anda mengerjakan satu proyek dalam satu waktu, tukangnya di bawah sepuluh orang, dan yang pegang uang cuma Anda sendiri, spreadsheet yang rapi sudah cukup. Templat RAB di Excel plus disiplin mencatat bisa jalan bertahun-tahun.

    Masalah spreadsheet bukan di alatnya, tapi di jumlah tangan yang menyentuhnya. Satu orang, satu file, aman. Begitu mandor, admin, dan bos sama-sama mengedit, mulai muncul file “RAB final revisi 3 fix” dan tidak ada yang tahu mana versi yang benar. Rumus kehapus tanpa sengaja juga sering kejadian dan baru ketahuan berminggu-minggu kemudian.

    Tanda-tanda Anda mulai butuh sistem biasanya muncul bersamaan. Proyek mulai jalan paralel di lokasi berbeda. Ada admin atau keuangan yang ikut pegang data, lalu muncul dua versi angka yang tidak cocok. Owner proyek mulai minta laporan rutin. Atau Anda sadar tiap akhir proyek selalu ada selisih anggaran yang tidak bisa dijelaskan asalnya dari mana. Kalau dua atau tiga tanda ini sudah kejadian, biaya membangun sistem biasanya jauh lebih kecil daripada kebocoran yang dibiarkan.

    Pengalaman kami dengan bisnis konstruksi

    Di Arrazy Inovasi, kami pernah menggarap kebutuhan digital untuk bisnis konstruksi, salah satunya Mandor Bangun. Untuk mereka, kami membangun website company profile dengan galeri proyek dan jalur kontak WhatsApp, karena masalah utama mereka waktu itu ada di sisi kepercayaan calon klien dan leads. Dari proyek seperti ini kami belajar satu hal: setiap bisnis konstruksi punya titik sakit yang berbeda, dan solusinya harus mengikuti masalah, bukan sebaliknya.

    Untuk kebutuhan internal seperti pantau anggaran, progres, material, dan upah, jalurnya adalah pengembangan sistem aplikasi custom. Prosesnya dimulai dari duduk bareng membedah alur kerja Anda. Bagaimana uang keluar, siapa yang belanja, bagaimana opname tukang dihitung. Baru dari situ modul dirancang mengikuti kebiasaan tim Anda, bukan memaksa tim menyesuaikan diri dengan software jadi yang setengah fiturnya tidak terpakai.

    Pertanyaan yang sering muncul

    Bisa dipakai di HP di lapangan?

    Bisa, dan memang harus. Sistem seperti ini biasanya dibangun berbasis web yang responsif atau dilengkapi aplikasi mobile, jadi mandor cukup pakai HP Android biasa. Input di lapangan dibuat ringkas: update progres, foto bon, catat material. Urusan yang butuh layar besar seperti menyusun RAB dikerjakan admin di komputer kantor.

    Proyek kecil perlu aplikasi seperti ini?

    Kalau proyeknya satu-satu dan tim masih kecil, belum tentu perlu. Spreadsheet yang disiplin sering kali cukup. Aplikasi mulai masuk akal saat proyek jalan paralel, tim membesar, atau selisih anggaran mulai sering muncul tanpa penjelasan. Ukur dari nilai kebocorannya, bukan dari gengsi punya aplikasi.

    Berapa lama pembuatannya?

    Tergantung cakupan modul. Versi awal yang fokus di pencatatan biaya, progres, dan material umumnya bisa dipakai dalam hitungan minggu sampai beberapa bulan, lalu dikembangkan bertahap. Kami biasanya menyarankan mulai dari modul yang paling menyumbat operasional, bukan langsung membangun semuanya sekaligus. Estimasi pastinya baru bisa dihitung setelah alur kerja Anda dibedah bersama.

    Tidak perlu langsung mikir soal fitur. Mulailah dari pertanyaan sederhana: di proyek terakhir, berapa selisih RAB dengan realisasi, dan tahu tidak larinya ke mana? Kalau jawabannya menggantung, itu sinyal paling jujur bahwa pencatatan Anda perlu dibenahi, entah lewat spreadsheet yang lebih disiplin atau sistem yang dibangun khusus.

    Kalau mau ngobrol dulu soal alur kerja proyek Anda dan kira-kira sistem seperti apa yang masuk akal, hubungi tim Arrazy Inovasi. Ceritakan saja cara kerja tim Anda sekarang, nanti kita bedah bareng bagian mana yang paling layak dirapikan lebih dulu. Diskusi awal tidak dipungut biaya dan tidak ada kewajiban lanjut.

  • Belajar Golang dari Nol #3: Function, Multiple Return, dan Error

    Belajar Golang dari Nol #3: Function, Multiple Return, dan Error

    Di Belajar Golang dari Nol #2 kamu sudah pegang variabel, tipe data, zero value, dan konversi tipe. Di sana kamu juga sempat ketemu sekilas dengan if err != nil waktu memakai strconv.Atoi. Waktu itu saya minta kamu terima dulu polanya tanpa banyak tanya. Sekarang saatnya membongkar asal-usulnya. Di bagian ini kita belajar function, multiple return, dan cara Go memperlakukan error.

    Function: bungkus logika biar bisa dipakai ulang

    Bayangkan function seperti mesin jus. Kamu masukkan buah, mesin bekerja, keluar jus. Kamu tidak perlu tahu isi mesinnya setiap kali mau bikin jus. Cukup tahu apa yang dimasukkan dan apa yang keluar.

    Di Go, bentuk dasarnya seperti ini.

    func sapa(nama string) string {
        return "Halo, " + nama
    }

    Baca pelan-pelan dari kiri ke kanan. func adalah kata kunci untuk membuat function. sapa adalah namanya. nama string artinya function ini menerima satu parameter bernama nama yang bertipe string. string di paling kanan adalah tipe nilai balikannya. Lalu return mengirim nilai itu keluar ke pemanggil.

    Kalau kamu pernah lihat Java atau C, urutannya terasa terbalik, karena Go memang sengaja menaruh tipe setelah nama supaya deklarasi tetap enak dibaca saat mulai kompleks.

    Begini cara memanggilnya dalam program utuh.

    package main
    
    import "fmt"
    
    func sapa(nama string) string {
        return "Halo, " + nama
    }
    
    func main() {
        pesan := sapa("Sari")
        fmt.Println(pesan)
    }

    Jalankan dengan go run main.go, hasilnya:

    Halo, Sari

    Parameter dan return value

    Function boleh menerima lebih dari satu parameter. Kita coba function hitung sederhana.

    func luasPersegiPanjang(panjang int, lebar int) int {
        return panjang * lebar
    }

    Ada satu trik kecil yang sering kamu temui di kode Go orang lain. Kalau beberapa parameter bertipe sama, tipenya cukup ditulis sekali di belakang.

    func luasPersegiPanjang(panjang, lebar int) int {
        return panjang * lebar
    }

    Keduanya sama persis artinya. Memanggilnya juga biasa saja: luas := luasPersegiPanjang(8, 5) akan mengisi luas dengan 40. Sampai sini belum ada yang aneh. Bagian menariknya baru mulai sekarang.

    Multiple return: ciri khas Go

    Di kebanyakan bahasa, function hanya bisa mengembalikan satu nilai. Go berbeda. Satu function boleh mengembalikan dua nilai atau lebih sekaligus. Ini bukan sekadar fitur gaya-gayaan. Ini fondasi dari cara Go menangani error.

    Contoh paling klasik adalah pembagian. Membagi angka dengan nol itu operasi yang tidak sah. Jadi function pembagi kita sebaiknya menjawab dua hal: berapa hasilnya, dan apakah operasinya berhasil.

    package main
    
    import (
        "errors"
        "fmt"
    )
    
    func bagi(a, b float64) (float64, error) {
        if b == 0 {
            return 0, errors.New("tidak bisa membagi dengan nol")
        }
        return a / b, nil
    }
    
    func main() {
        hasil, err := bagi(10, 2)
        if err != nil {
            fmt.Println("terjadi error:", err)
            return
        }
        fmt.Println("hasil:", hasil)
    }

    Perhatikan bagian (float64, error). Itu artinya function ini mengembalikan dua nilai: hasil pembagian bertipe float64, dan sebuah error. Kalau semuanya lancar, error yang dikembalikan adalah nil, yang artinya kosong, tidak ada masalah. Kalau ada masalah, kita kembalikan nilai error yang berisi pesan.

    Di sisi pemanggil, dua nilai itu ditangkap sekaligus: hasil, err := bagi(10, 2). Ini pola yang akan kamu tulis ratusan kali selama menulis Go, jadi biasakan dari sekarang.

    Konvensi error di Go

    Di Go, error bukan sesuatu yang spesial. Error adalah nilai biasa, sama seperti angka atau string, hanya saja tipenya error. Karena dia nilai biasa, dia bisa dikembalikan dari function, disimpan di variabel, atau dibandingkan.

    Ada beberapa konvensi tidak tertulis yang dipegang hampir semua programmer Go:

    • Kalau function bisa gagal, nilai balikan terakhirnya bertipe error. Bukan yang pertama, bukan di tengah. Selalu yang terakhir.
    • Untuk membuat error dengan pesan tetap, pakai errors.New("pesan errornya") dari package errors.
    • Untuk pesan yang butuh format, pakai fmt.Errorf. Misalnya fmt.Errorf("stok tinggal %d", sisa).

    Satu hal lagi yang cukup kamu tahu namanya dulu. fmt.Errorf punya kata kerja format khusus, yaitu %w, yang dipakai untuk membungkus error lain di dalam error baru. Teknik ini namanya error wrapping, dan detailnya kita bahas di bagian lanjutan seri ini. Sekarang cukup ingat bahwa %w itu ada.

    Pola if err != nil, dijelaskan tuntas

    Sekarang kita jawab pertanyaan yang tertunda dari bagian 2: kenapa kode Go penuh dengan if err != nil?

    Bahasa seperti Java, Python, atau JavaScript memakai try-catch. Kamu tulis kode di blok try, dan kalau ada yang meledak di mana pun di dalamnya, eksekusi melompat ke blok catch. Go mengambil jalan lain. Tidak ada try-catch. Function yang bisa gagal mengembalikan error sebagai nilai, dan kamu memeriksanya langsung setelah pemanggilan.

    Alasannya soal kejujuran kode. Dengan try-catch, kamu bisa memanggil sepuluh function tanpa tahu mana yang bisa gagal. Di Go, kemungkinan gagal tertulis jelas di tanda tangan function. Pembaca kode langsung tahu titik mana saja yang bisa bermasalah, dan compiler akan protes kalau kamu menangkap err lalu tidak menyentuhnya sama sekali.

    Supaya adil, pendekatan ini ada harganya. Kode Go jadi lebih panjang, dan mengetik if err != nil berulang-ulang memang terasa repetitif. Ini kritik paling umum terhadap Go, dan kritik itu valid. Sebagian orang menganggapnya bertele-tele, sebagian lagi justru menyukainya karena alur kegagalan terlihat gamblang tanpa lompatan tersembunyi. Setelah beberapa minggu menulis Go, kebanyakan orang berhenti menganggapnya masalah.

    Pola pendampingnya bernama early return: begitu ketemu error, langsung return dan hentikan function. Kode sukses tidak perlu dibungkus blok else, jadi alur utamanya tetap lurus dari atas ke bawah. Contohnya sudah kamu lihat di function main tadi. Kalau err tidak nil, cetak pesannya lalu return. Baris di bawahnya hanya berjalan saat semuanya aman.

    Named return: singkat saja

    Go mengizinkan nilai balikan diberi nama di tanda tangan function.

    func bagi(a, b float64) (hasil float64, err error) {
        if b == 0 {
            err = errors.New("tidak bisa membagi dengan nol")
            return
        }
        hasil = a / b
        return
    }

    hasil dan err otomatis menjadi variabel di dalam function, dan return polos akan mengembalikan nilai keduanya saat itu. Kelihatan praktis, tapi pada function yang panjang, pembaca harus menebak apa isi return polos itu. Saran saya untuk sekarang: tulis return secara eksplisit seperti contoh-contoh sebelumnya. Named return baru berguna di kasus khusus yang akan kamu temui jauh di depan.

    Variadic function: parameter yang jumlahnya bebas

    Kadang kamu tidak tahu berapa banyak nilai yang akan dikirim ke function. Menjumlahkan isi keranjang belanja, misalnya. Bisa dua barang, bisa sepuluh. Untuk itu Go punya variadic function, ditandai tiga titik sebelum tipe.

    func totalBelanja(harga ...int) int {
        total := 0
        for _, h := range harga {
            total += h
        }
        return total
    }

    harga ...int artinya function ini menerima nol, satu, atau banyak nilai int. Di dalam function, harga berperilaku seperti kumpulan nilai yang bisa kita jelajahi dengan for range. Perulangan sendiri akan kita kupas dalam di bagian lain, untuk sekarang cukup pahami bahwa baris itu mengunjungi tiap harga satu per satu dan menambahkannya ke total.

    Memanggilnya luwes sekali: totalBelanja(15000, 20000) sah, totalBelanja(5000, 7500, 12000, 3000) juga sah. fmt.Println yang kamu pakai sejak bagian 1 juga variadic. Itu sebabnya dia mau menerima berapa pun argumen.

    Latihan: kalkulator diskon

    Sekarang kita rangkai semuanya jadi satu program utuh. Skenarionya sederhana: kasir menjumlahkan keranjang belanja, lalu menerapkan diskon. Diskon di bawah 0 persen atau di atas 100 persen jelas tidak masuk akal, jadi harus ditolak lewat error.

    package main
    
    import "fmt"
    
    func totalKeranjang(harga ...float64) float64 {
        total := 0.0
        for _, h := range harga {
            total += h
        }
        return total
    }
    
    func hitungDiskon(total, persen float64) (float64, error) {
        if persen < 0 {
            return 0, fmt.Errorf("persen diskon tidak boleh negatif, dapat %v", persen)
        }
        if persen > 100 {
            return 0, fmt.Errorf("persen diskon tidak boleh lebih dari 100, dapat %v", persen)
        }
        potongan := total * persen / 100
        return total - potongan, nil
    }
    
    func main() {
        total := totalKeranjang(15000, 42500, 8000)
        fmt.Println("Total keranjang:", total)
    
        bayar, err := hitungDiskon(total, 20)
        if err != nil {
            fmt.Println("Gagal menghitung diskon:", err)
            return
        }
        fmt.Println("Bayar setelah diskon 20 persen:", bayar)
    
        bayar, err = hitungDiskon(total, 150)
        if err != nil {
            fmt.Println("Gagal menghitung diskon:", err)
            return
        }
        fmt.Println("Bayar setelah diskon 150 persen:", bayar)
    }

    Jalankan, dan outputnya seperti ini.

    Total keranjang: 65500
    Bayar setelah diskon 20 persen: 52400
    Gagal menghitung diskon: persen diskon tidak boleh lebih dari 100, dapat 150

    Mari bedah sebentar apa yang terjadi:

    • totalKeranjang adalah variadic function. Dia menerima tiga harga dan menjumlahkannya jadi 65500.
    • hitungDiskon memakai multiple return: hasil bertipe float64 plus error di posisi terakhir, sesuai konvensi.
    • Validasi dilakukan di awal function dengan early return. Persen 20 lolos, jadi errornya nil dan program mencetak 52400.
    • Panggilan kedua mengirim persen 150. Validasi menolaknya, err terisi, dan blok if err != nil mencetak pesan lalu menghentikan main. Baris cetak “Bayar setelah diskon 150 persen” tidak pernah dijalankan.

    Coba ubah sendiri: ganti persen jadi -5, tambah barang di keranjang, atau buat function baru hitungPajak dengan pola yang sama. Semakin sering tanganmu menulis pola ini, semakin cepat dia jadi refleks.

    Rangkuman dan lanjut ke mana

    Hari ini kamu sudah belajar cukup banyak:

    • Function dideklarasikan dengan func, dan tipe ditulis setelah nama.
    • Function di Go bisa mengembalikan lebih dari satu nilai.
    • Konvensi error: nilai balikan terakhir bertipe error, dibuat dengan errors.New atau fmt.Errorf.
    • Go memilih pengecekan error eksplisit lewat if err != nil plus early return, bukan try-catch.
    • Named return ada, tapi untuk sekarang lebih baik return eksplisit.
    • Variadic function menerima jumlah argumen yang bebas.

    Dengan bekal ini, kamu sudah bisa memecah program jadi potongan-potongan kecil yang rapi dan tahan gagal. Di bagian berikutnya kita naik satu tingkat: “Belajar Golang dari Nol #4: Struct dan Method: Cara Go Menyusun Data”. Di sana function yang baru kamu kuasai akan menempel langsung ke data.

    Pola function dan error yang kamu latih hari ini persis pola yang kami pakai sehari-hari saat membangun backend produksi dengan Go untuk klien Arrazy.

  • Belajar Linux dari Nol #1: Cara Install Ubuntu 24.04

    Belajar Linux dari Nol #1: Cara Install Ubuntu 24.04

    Cara install Ubuntu 24.04 yang paling aman untuk pemula adalah lewat VirtualBox. Kamu download ISO Ubuntu 24.04 LTS dari ubuntu.com, buat virtual machine dengan RAM minimal 4 GB dan disk 25 GB, lalu ikuti installer sampai login desktop. Seluruh prosesnya sekitar 30 sampai 60 menit, dan kalau ada yang rusak, tinggal hapus VM lalu ulang dari nol tanpa menyentuh Windows atau data kamu.

    Artikel ini bagian pertama dari seri Belajar Linux dari Nol, seri tutorial 26 bagian yang membawa kamu dari belum pernah pegang terminal sampai bisa mengelola server sendiri. Di bagian ini kita siapkan fondasinya dulu: kenalan singkat dengan Linux, memilih jalur setup yang cocok, lalu praktik install sampai selesai.

    Apa Itu Linux dan Kenapa Seri Ini Pakai Ubuntu 24.04 LTS

    Linux adalah sistem operasi open source, sama seperti Windows atau macOS tapi gratis dan kodenya terbuka. Kamu mungkin belum sadar, tapi Linux sudah ada di mana-mana: Android jalan di atas kernel Linux, dan mayoritas server di internet memakai Linux. Kalau kamu mau kerja sebagai backend developer, DevOps, atau sysadmin, Linux bukan pilihan, tapi keharusan.

    Linux dirilis dalam bentuk distro (distribusi), yaitu paket kernel Linux plus kumpulan software siap pakai. Ada banyak distro: Ubuntu, Debian, Fedora, Arch, dan lainnya. Seri ini memakai Ubuntu 24.04 LTS dengan tiga alasan praktis:

    • LTS berarti Long Term Support. Ubuntu 24.04 (nama kodenya Noble Numbat) didukung update keamanan sampai tahun 2029. Kamu tidak perlu upgrade besar tiap enam bulan.
    • Paling banyak dipakai di server. Skill yang kamu pelajari di laptop langsung terpakai saat pegang server sungguhan. Tim Arrazy sendiri menjalankan hampir semua deployment klien, dari backend Go sampai aplikasi Laravel, di server Ubuntu.
    • Komunitasnya besar. Hampir semua error yang kamu temui sudah pernah ditanyakan orang lain. Solusinya gampang dicari.

    Tiga Jalur Setup: VirtualBox, WSL2, atau Dual Boot

    Ada tiga cara umum menjalankan Ubuntu di laptop yang sudah terpasang Windows. Masing-masing punya kelebihan dan risikonya sendiri.

    Jalur Cocok untuk Risiko
    VirtualBox Pemula yang mau eksperimen bebas, dapat desktop Ubuntu penuh Hampir nol, VM terisolasi dari Windows
    WSL2 Yang cuma butuh terminal Linux di dalam Windows Rendah, tapi tanpa pengalaman desktop Linux
    Dual boot Yang sudah yakin mau pakai Linux harian dengan performa penuh Salah partisi bisa menghapus data Windows

    Rekomendasi saya untuk seri ini: pakai VirtualBox. Kamu dapat pengalaman Ubuntu lengkap termasuk proses install, desktop, dan manajemen sistem, tanpa risiko apa pun ke laptop utama. Salah ketik perintah paling parah cuma merusak VM, tinggal buat lagi.

    Kalau Mau Jalur WSL2 di Windows

    WSL2 (Windows Subsystem for Linux) menjalankan Ubuntu langsung di dalam Windows 10/11 tanpa VM manual. Cukup satu perintah di PowerShell yang dijalankan sebagai Administrator:

    wsl --install -d Ubuntu-24.04

    Setelah restart, buka aplikasi Ubuntu dari Start Menu, buat username dan password, selesai. WSL2 sah-sah saja dipakai mengikuti seri ini karena 90 persen materi kita berbasis terminal. Yang tidak kamu dapat: pengalaman install OS dan desktop Linux.

    Kalau Mau Dual Boot

    Dual boot memasang Ubuntu berdampingan dengan Windows di disk yang sama. Performanya paling kencang karena tidak ada lapisan virtualisasi. Tapi jalur ini melibatkan pemotongan partisi disk, dan salah langkah bisa membuat Windows tidak bisa boot atau data hilang. Kalau kamu baru pertama kali, tunda dulu. Selesaikan seri ini di VirtualBox, nanti kalau sudah nyaman baru pindah ke dual boot dengan backup data lengkap.

    Praktik: Cara Install Ubuntu 24.04 di VirtualBox

    Yang kamu butuhkan: laptop dengan RAM minimal 8 GB (4 GB untuk VM, sisanya untuk Windows), ruang disk kosong 30 GB, dan koneksi internet untuk download sekitar 6 GB.

    Langkah 1: Download ISO Ubuntu 24.04

    Buka https://ubuntu.com/download/desktop lalu klik tombol download untuk Ubuntu 24.04 LTS. File yang kamu dapat bernama seperti ubuntu-24.04.2-desktop-amd64.iso dengan ukuran sekitar 5,8 GB. Angka di belakang 24.04 adalah point release, isinya tetap Ubuntu 24.04 plus update terbaru, jadi ambil saja versi yang ditawarkan.

    Langkah 2: Install VirtualBox dan Buat VM

    Download VirtualBox versi 7.1 dari https://www.virtualbox.org/wiki/Downloads, pilih “Windows hosts”, lalu install dengan pengaturan default. Setelah terbuka, buat VM baru:

    1. Klik New. Isi nama ubuntu-belajar, pilih ISO yang tadi didownload di kolom ISO Image. VirtualBox otomatis mendeteksi tipe Linux dan versi Ubuntu 24.04.
    2. Centang Skip Unattended Installation. Ini penting supaya kamu mengalami proses install manual, bukan diotomatiskan VirtualBox.
    3. Di bagian Hardware: set Base Memory 4096 MB dan Processors 2. Kalau laptop kamu punya RAM 16 GB, boleh naikkan ke 8192 MB supaya lebih lega.
    4. Di bagian Hard Disk: buat disk baru ukuran 25 GB. Ini ukuran maksimal, file di Windows hanya membesar sesuai pemakaian nyata.
    5. Klik Finish, lalu klik Start untuk menyalakan VM.

    Langkah 3: Jalankan Installer Ubuntu Sampai Selesai

    VM akan boot dari ISO dan masuk ke installer Ubuntu. Ikuti urutan ini:

    1. Pilih bahasa English. Bukan karena bahasa Indonesia jelek, tapi supaya pesan error kamu gampang dicari di Google, hampir semua dokumentasi memakai istilah Inggris.
    2. Pilih Install Ubuntu, lalu keyboard layout English (US) yang cocok dengan keyboard laptop Indonesia pada umumnya.
    3. Sambungkan ke internet kalau ditawarkan, lalu pilih Interactive installation dan Default selection untuk aplikasi bawaan.
    4. Di bagian tipe instalasi, pilih Erase disk and install Ubuntu. Tenang, “disk” di sini adalah disk virtual 25 GB milik VM, bukan disk Windows kamu.
    5. Isi nama, nama komputer, username, dan password. Catat password ini baik-baik, kamu akan memakainya terus untuk perintah sudo.
    6. Pilih zona waktu Jakarta, klik Install, lalu tunggu 10 sampai 20 menit.
    7. Setelah muncul “Installation Complete”, klik Restart Now. Kalau layar meminta “remove the installation medium”, cukup tekan Enter.

    Kalau semua lancar, VM akan boot ulang dan menampilkan layar login Ubuntu. Masukkan password, dan kamu resmi punya desktop Linux pertama.

    Update Pertama Kali Setelah Install Ubuntu

    Hal pertama yang wajib dilakukan setelah install adalah update sistem. ISO yang kamu pakai dibuat beberapa bulan lalu, jadi ada tumpukan update keamanan yang menunggu. Buka terminal dengan shortcut Ctrl+Alt+T, lalu jalankan:

    sudo apt update && sudo apt upgrade -y

    Kamu akan diminta password. Saat mengetik password di terminal, tidak ada tanda apa pun yang muncul di layar, itu normal, ketik saja lalu Enter. Output awalnya kira-kira seperti ini:

    Hit:1 http://id.archive.ubuntu.com/ubuntu noble InRelease
    Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
    Get:3 http://id.archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
    ...
    Reading package lists... Done
    Building dependency tree... Done
    XX packages can be upgraded. Run 'apt list --upgradable' to see them.

    Perintah apt update menyegarkan daftar paket, apt upgrade memasang versi terbarunya. Detail lengkap soal APT kita bahas di bagian 11 seri ini, untuk sekarang cukup paham bahwa dua perintah ini adalah ritual rutin pengguna Ubuntu. Di pekerjaan kami sehari-hari mengelola server klien yang menjalankan sistem aplikasi mereka, update rutin seperti ini adalah lapisan keamanan paling dasar yang tidak boleh dilewatkan.

    Terakhir, matikan VM dengan benar: klik menu power di pojok kanan atas desktop lalu pilih Power Off, atau dari terminal:

    sudo poweroff

    Troubleshooting: Error Umum Saat Install Ubuntu 24.04

    VT-x/AMD-V Tidak Aktif di BIOS

    Gejalanya VM menolak start dengan pesan seperti VT-x is not available (VERR_VMX_NO_VMX) atau AMD-V is disabled in the BIOS. Penyebabnya fitur virtualisasi di prosesor belum dinyalakan. Solusinya: restart laptop, masuk BIOS/UEFI (biasanya tekan F2, F10, atau Del saat logo vendor muncul), cari opsi bernama Intel Virtualization Technology, VT-x, atau SVM Mode untuk AMD, ubah ke Enabled, simpan, lalu boot ulang. Di Windows 11, cek juga Task Manager tab Performance, baris “Virtualization” harus tertulis Enabled.

    Installer Lambat atau Crash karena RAM VM Kurang

    Kalau RAM VM diset di bawah 4 GB, installer Ubuntu 24.04 desktop sering macet, sangat lambat, atau muncul pesan “the installer encountered an unrecoverable error”. Solusinya: matikan VM, buka Settings, System, Motherboard, naikkan Base Memory ke minimal 4096 MB. Kalau laptop kamu total RAM-nya hanya 8 GB, tutup aplikasi berat seperti browser dengan banyak tab sebelum menjalankan VM.

    Stuck di Layar Hitam Setelah Install

    VM boot tapi hanya menampilkan layar hitam atau kursor kedip. Ada dua penyebab paling umum. Pertama, VM masih boot dari ISO installer: buka Settings, Storage, klik ikon CD, lalu pilih Remove Disk from Virtual Drive. Kedua, masalah grafis: buka Settings, Display, naikkan Video Memory ke 128 MB, pastikan Graphics Controller diset VMSVGA, dan matikan centang Enable 3D Acceleration kalau sebelumnya aktif. Salah satu dari dua langkah ini menyelesaikan hampir semua kasus layar hitam yang kami temui.

    Lanjut ke Bagian Berikutnya

    Sampai sini kamu sudah punya Ubuntu 24.04 yang hidup, ter-update, dan aman untuk dieksperimeni. Itu modal utama untuk seluruh seri ini. Sering-seringlah masuk ke VM ini, karena satu-satunya cara jago Linux adalah memakainya tiap hari.

    Bagian berikutnya, “Belajar Linux dari Nol #2: Cara Menggunakan Terminal Linux”, akan mulai masuk ke jantung Linux yang sebenarnya: terminal, shell, dan cara membaca struktur perintah. Artikelnya terbit menyusul dan bisa kamu pantau di halaman hub Belajar Linux.

    Referensi

  • Checklist Serah Terima Proyek Aplikasi: Hakmu dari Vendor

    Checklist Serah Terima Proyek Aplikasi: Hakmu dari Vendor

    Saat proyek aplikasi selesai, ada lima kelompok hal yang wajib kamu terima dari vendor: akses dan kepemilikan penuh (source code, hosting, domain, database, akun pihak ketiga), dokumentasi teknis, kejelasan legal dan lisensi, kesepakatan garansi serta penanganan bug, dan yang terakhir, kepastian bahwa tidak ada satu pun aset yang “disandera” vendor. Kalau salah satu dari lima ini tidak kamu pegang, proyekmu belum benar-benar selesai, berapa pun invoice yang sudah lunas.

    Kami menulis ini dari posisi yang mungkin terdengar aneh: kami sendiri software house. Artinya kami tahu persis celah mana yang sering dimanfaatkan vendor untuk membuat klien bergantung selamanya. Sebagian besar klien baru sadar ada masalah justru saat mau pindah vendor, lalu menemukan bahwa domain bukan atas nama mereka atau source code tidak pernah diserahkan. Artikel ini membocorkan daftar lengkapnya, item per item, supaya kamu bisa menagih hakmu sebelum terlambat.

    1. Akses dan Kepemilikan: Ini yang Paling Sering Ditahan

    Ini kelompok paling penting sekaligus paling sering bermasalah. Prinsipnya sederhana. Kamu yang bayar, kamu yang punya. Semua akses harus atas nama kamu atau perusahaanmu, bukan atas nama vendor.

    • Source code dalam bentuk repository Git, bukan file zip. Ini penting. File zip hanya potret satu momen. Repository Git menyimpan seluruh riwayat perubahan kode, siapa mengubah apa dan kapan. Developer baru yang meneruskan proyekmu akan sangat terbantu oleh riwayat ini. Minta kamu dijadikan owner di GitHub, GitLab, atau Bitbucket, atau minta repository dipindahkan ke akun organisasimu.
    • Akun hosting dan domain atas nama kamu. Domain adalah identitas bisnismu. Kalau terdaftar atas nama vendor, secara administratif itu milik mereka. Cek di registrar siapa pemiliknya. Hosting juga sama. Idealnya kamu yang bikin akun, vendor hanya diberi akses kerja yang bisa dicabut kapan saja.
    • Akses database. Data pelanggan, transaksi, dan konten adalah asetmu yang paling berharga. Minta kredensial database plus cara melakukan backup. Tanpa ini, datamu ada di tangan orang lain.
    • Akun layanan pihak ketiga. Payment gateway, API pengiriman, layanan email, push notification, Google Maps, dan sejenisnya. Semua akun ini harus dibuat dengan email perusahaanmu. Khusus payment gateway ini krusial karena menyangkut uang yang mengalir ke rekening. Kalau akunnya milik vendor, uangmu lewat jalur mereka.
    • Password admin aplikasi. Terdengar sepele, tapi banyak klien tidak pernah pegang akses admin tertinggi di sistemnya sendiri. Minta akun super admin, lalu ganti password-nya setelah serah terima.

    Satu tips praktis. Jangan tunggu hari serah terima untuk mengecek semua ini. Cicil dari awal proyek. Akun-akun dibuat atas nama kamu sejak hari pertama, jauh lebih mudah daripada proses migrasi di akhir.

    2. Dokumentasi: Bekal untuk Developer Setelahnya

    Aplikasi tanpa dokumentasi itu seperti mesin tanpa buku manual. Masih jalan, tapi begitu ada masalah, tidak ada yang tahu harus mulai dari mana. Dokumentasi yang layak kamu minta minimal mencakup tiga hal.

    • Cara deploy. Langkah-langkah memasang aplikasi dari nol sampai jalan di server. Termasuk kebutuhan server, versi bahasa pemrograman, dan perintah yang harus dijalankan. Tanpa ini, pindah server bisa jadi proyek tersendiri yang mahal.
    • Daftar environment variable. Ini konfigurasi rahasia seperti kunci API, kredensial database, dan setting per server. Biasanya tidak ikut tersimpan di repository demi keamanan. Justru karena itu harus diserahkan terpisah dan tercatat. Aplikasi yang kodenya lengkap tapi environment variable-nya hilang tetap tidak bisa jalan.
    • Dokumentasi API, kalau ada. Kalau aplikasimu punya backend yang diakses aplikasi mobile atau sistem lain, minta dokumentasi endpoint-nya. Cukup format sederhana seperti Postman collection atau Swagger. Ini menghemat berminggu-minggu kerja developer berikutnya.

    Dokumentasi tidak perlu setebal skripsi. Satu file README yang jujur dan up to date jauh lebih berharga daripada dokumen 50 halaman yang tidak pernah diperbarui.

    3. Legal dan Lisensi: Hitam di Atas Putih

    Bagian ini sering dilewati karena dianggap formalitas. Padahal di sinilah sengketa biasanya bermula.

    • Kepemilikan kode harus tertulis di kontrak. Di banyak yurisdiksi, tanpa klausul penyerahan hak, hak cipta kode secara default bisa tetap di tangan pembuatnya. Jadi jangan berasumsi. Pastikan kontrak menyebut jelas bahwa hasil kerja, termasuk source code, menjadi milik klien setelah pelunasan.
    • Lisensi library dan komponen berbayar. Hampir semua aplikasi modern dibangun di atas library pihak ketiga. Sebagian gratis, sebagian berbayar per proyek atau per tahun. Minta daftar komponen berbayar yang dipakai, atas nama siapa lisensinya, dan berapa biaya perpanjangannya. Kamu tidak mau kaget aplikasi berhenti berfungsi karena lisensi template atau plugin kedaluwarsa.
    • Perjanjian maintenance yang terpisah dan jelas. Setelah garansi habis, siapa yang merawat sistem? Berapa biayanya, apa saja cakupannya, dan bagaimana cara mengakhirinya? Perjanjian maintenance yang bagus juga menyebut apa yang terjadi kalau kontrak berakhir. Yang penting, maintenance harus jadi pilihan, bukan keterpaksaan karena hanya vendor itu yang pegang akses.

    4. Serah Terima Teknis: Garansi, Bug, dan Batas Revisi

    Aplikasi yang baru rilis hampir pasti masih punya bug. Itu normal. Yang tidak normal adalah kalau tidak ada kesepakatan soal siapa yang memperbaikinya dan sampai kapan. Sebelum tanda tangan berita acara serah terima, pastikan hal-hal berikut sudah disepakati.

    • Masa garansi bug. Di industri ini umumnya 1 sampai 3 bulan setelah go live. Dalam periode ini, error yang berasal dari kode vendor diperbaiki tanpa biaya. Pastikan definisinya jelas: garansi mencakup bug, bukan fitur baru.
    • Format pelaporan bug. Sepakati lewat mana bug dilaporkan, entah grup chat, email, atau tools tiket. Sepakati juga informasi apa yang perlu kamu sertakan, misalnya screenshot dan langkah untuk mereproduksi masalah, plus estimasi waktu respons. Tanpa jalur yang jelas, laporan bug gampang hilang dan dua pihak saling menunggu.
    • Batas revisi. Bedakan tiga hal ini sejak awal: bug (masuk garansi), revisi minor (biasanya ada jatahnya di kontrak), dan fitur baru (kerjaan baru dengan biaya baru). Perselisihan klien dan vendor paling sering terjadi karena tiga hal ini dicampur aduk. Vendor merasa dimintai kerja gratis, klien merasa ditagih untuk hal yang seharusnya beres.

    Minta juga sesi serah terima teknis, semacam walkthrough. Vendor menjelaskan arsitektur sistem ke kamu atau ke tim IT-mu, direkam kalau perlu. Satu jam sesi ini bisa menyelamatkanmu dari kebingungan bertahun-tahun.

    5. Tanda Bahaya: Pola Vendor yang Perlu Kamu Waspadai

    Sekarang bagian yang jarang dibahas terbuka. Ada beberapa pola yang berulang kali kami dengar dari klien yang datang setelah kecewa dengan vendor sebelumnya. Polanya mirip di mana-mana.

    • Source code disandera. Vendor menolak menyerahkan kode dengan alasan “itu aset kami” atau “nanti disalahgunakan”. Padahal kontrak tidak menyebut demikian, atau bahkan tidak ada kontrak sama sekali. Akibatnya klien tidak bisa pindah ke developer lain tanpa membangun ulang dari nol.
    • Domain dan hosting atas nama vendor. Saat hubungan baik, ini tidak terasa. Saat hubungan memburuk atau vendor menghilang, domainmu ikut hilang. Ada bisnis yang terpaksa ganti alamat website, ganti email perusahaan, dan kehilangan reputasi yang sudah dibangun bertahun-tahun hanya karena domain tidak pernah atas nama mereka.
    • Biaya tebusan di akhir. Modusnya, biaya proyek di awal terlihat murah. Begitu kamu mau memutus hubungan, muncul tagihan “biaya migrasi”, “biaya rilis source code”, atau angka perpanjangan maintenance yang tiba-tiba melonjak. Murah di depan, mahal saat mau keluar.
    • Semua serba lisan. Vendor yang menghindari kontrak tertulis dan berita acara serah terima biasanya sedang menjaga ruang abu-abu. Ruang abu-abu itu hampir selalu menguntungkan pihak yang pegang akses, dan itu bukan kamu.

    Perlu adil juga. Tidak semua vendor yang menahan sesuatu berarti nakal. Kadang pembayaran memang belum lunas, dan menahan serah terima sampai pelunasan itu wajar. Yang jadi masalah adalah ketika kewajibanmu sudah beres tapi hakmu tidak kunjung diserahkan.

    Pertanyaan yang Sebaiknya Kamu Ajukan Sebelum Kontrak

    Semua masalah di atas jauh lebih murah dicegah daripada diperbaiki. Sebelum tanda tangan kontrak pembuatan sistem atau aplikasi, ajukan pertanyaan-pertanyaan ini ke calon vendormu.

    • Setelah lunas, apakah source code jadi milik saya sepenuhnya, dan diserahkan dalam bentuk repository Git?
    • Domain, hosting, dan semua akun layanan pihak ketiga akan didaftarkan atas nama siapa?
    • Kalau suatu saat saya pindah vendor, apa saja yang saya bawa dan adakah biaya tambahan untuk itu?
    • Berapa lama masa garansi bug, dan apa saja cakupannya?
    • Apa saja dokumentasi yang saya terima di akhir proyek?
    • Adakah komponen berbayar di dalam sistem, dan atas nama siapa lisensinya?

    Perhatikan bukan hanya jawabannya, tapi cara menjawabnya. Vendor yang sehat akan menjawab lugas karena pertanyaan ini memang standar. Vendor yang berbelit atau tersinggung saat ditanya soal kepemilikan, itu sinyal yang layak kamu catat.

    Posisi Kami Soal Ini

    Di Arrazy Inovasi, prinsipnya sederhana. Kode yang kamu bayar adalah milikmu. Repository, akses hosting, database, dan dokumentasi kami serahkan saat serah terima, dan klien bebas melanjutkan dengan tim mana pun. Kami lebih memilih klien bertahan karena puas dengan hasil kerja, bukan karena tidak punya pilihan untuk pergi.

    Kalau kamu sedang menghadapi serah terima proyek dan ragu apa saja yang berhak kamu minta, atau sedang menimbang pindah vendor, hubungi kami. Ceritakan situasimu, dan kami bantu petakan langkahnya. Konsultasi awal tidak dipungut biaya, dan tidak ada kewajiban lanjut.

  • Tagihan SPP Santri Masih Dicatat Manual? Begini Cara Kerjanya

    Tagihan SPP Santri Masih Dicatat Manual? Begini Cara Kerjanya

    Cara kerja penagihan SPP digital sebenarnya sederhana. Setiap awal bulan, sistem membuat tagihan syahriah untuk seluruh santri secara otomatis. Wali santri menerima pemberitahuan tagihan, lalu membayar lewat transfer atau virtual account atas nama anaknya. Begitu uang masuk, status tagihan berubah menjadi lunas dengan sendirinya. Tidak ada yang perlu mencocokkan mutasi rekening satu per satu, tidak ada yang perlu menyalin ulang ke buku besar.

    Bendahara cukup membuka dasbor untuk melihat siapa yang sudah bayar, siapa yang belum, dan berapa total pemasukan bulan berjalan. Itu jawaban singkatnya. Sisanya, artikel ini membahas alur kerjanya langkah demi langkah, apa yang berubah untuk wali santri dan bendahara, serta satu pertanyaan yang jarang dijawab jujur: kapan pencatatan manual sebenarnya masih cukup.

    Rekap SPP manual, pekerjaan yang tidak pernah selesai

    Kalau Anda bendahara pesantren, alur ini mungkin terasa akrab. Data pembayaran tersebar di tiga tempat sekaligus: buku besar di meja, chat WhatsApp dari wali yang mengirim bukti transfer, dan mutasi rekening yang harus dicek satu per satu. Ketiganya harus dicocokkan tiap akhir bulan, biasanya sambil berharap tidak ada yang terlewat.

    Lalu ada transferan tanpa berita. Masuk uang 350 ribu, tapi tidak jelas dari wali santri yang mana, untuk bulan apa. Bendahara terpaksa bertanya di grup atau menghubungi beberapa wali satu per satu. Pertanyaan “mohon maaf, ini transferan dari siapa ya” jadi rutinitas bulanan yang melelahkan dua belah pihak.

    Yang paling berat sebenarnya bukan pencatatannya, tapi tunggakan yang ketahuan telat. Karena rekap baru rapi di akhir bulan, santri yang menunggak tiga bulan sering baru terlihat saat sudah jauh tertinggal. Menagihnya jadi tidak enak, jumlahnya sudah besar, dan wali kadang kaget karena merasa sudah membayar. Bukan salah siapa-siapa. Sistemnya saja yang tidak memberi kabar lebih awal.

    Cara kerja sistem penagihan SPP digital, langkah demi langkah

    Sistem billing pesantren pada dasarnya menjalankan lima langkah yang sama setiap bulan. Bedanya, hampir semuanya berjalan tanpa disentuh bendahara.

    • Data santri dan tarif diatur sekali di awal. Nama santri, kelas atau kamar, nominal syahriah, plus pengecualian seperti keringanan atau beasiswa per santri. Ini pekerjaan satu kali, bukan tiap bulan.
    • Tagihan digenerate otomatis tiap awal bulan. Tanggal 1, sistem membuat tagihan untuk semua santri sesuai tarif masing-masing. Untuk 300 santri, prosesnya hitungan detik, bukan hitungan hari lembur.
    • Wali santri menerima pemberitahuan. Isinya jelas: nama santri, bulan tagihan, nominal, dan cara bayar. Wali tidak perlu menebak atau bertanya dulu ke pengurus.
    • Wali membayar lewat virtual account atau transfer. Setiap santri punya nomor virtual account sendiri, jadi uang yang masuk otomatis dikenali milik siapa dan untuk tagihan yang mana. Tidak ada lagi transferan misterius tanpa berita.
    • Status lunas tercatat sendiri. Begitu pembayaran terverifikasi, tagihan berubah jadi lunas, riwayat tersimpan, dan angka di dasbor terbarui. Tunggakan pun langsung kelihatan sejak bulan pertama, bukan setelah menumpuk tiga bulan.

    Pembayaran tunai tetap punya tempat. Kalau ada wali yang datang langsung membawa uang, bendahara tinggal mencatatnya di sistem sebagai pembayaran tunai. Satu kali input, dan datanya menyatu dengan pembayaran transfer di laporan yang sama.

    Perhatikan satu hal dari alur di atas. Peran bendahara tidak hilang, tapi bergeser. Dari orang yang menyalin dan mencocokkan angka, menjadi orang yang mengawasi dan mengambil keputusan. Sistem yang mengerjakan bagian berulangnya, bendahara yang menangani pengecualian, misalnya wali yang minta penjadwalan ulang atau santri yang berganti kategori tarif di tengah tahun.

    Apa yang berubah setelah penagihan jalan otomatis

    Untuk wali santri

    Wali tidak perlu lagi menyimpan nominal SPP di ingatan atau bertanya dulu sebelum transfer. Tagihan datang sendiri, jelas untuk bulan apa dan berapa. Pembayaran bisa dilakukan dari rumah, kapan saja, tanpa menunggu jam kerja kantor pesantren. Dan karena setiap pembayaran tercatat atas nama santri, wali tidak akan dikira menunggak padahal sudah membayar. Riwayat pembayaran bisa dibuka kembali kalau suatu saat perlu bukti.

    Untuk bendahara

    Perubahan paling terasa ada di sini. Rekap akhir bulan yang biasanya makan waktu berhari-hari berubah jadi membuka satu halaman laporan. Pertanyaan “santri A sudah bayar belum” dijawab sistem, bukan dijawab dengan membongkar buku dan scroll chat. Daftar tunggakan tersedia setiap saat, sehingga mengingatkan wali bisa dilakukan lebih awal, saat nominalnya masih satu bulan dan pembicaraannya masih ringan.

    Ada satu efek lain yang jarang disebut: laporan ke pimpinan pesantren dan yayasan jadi lebih mudah dipertanggungjawabkan. Semua angka punya jejak, siapa membayar, kapan, lewat jalur apa. Kepercayaan wali pada pengelolaan keuangan pesantren ikut terjaga.

    Kapan pencatatan manual sebenarnya masih cukup

    Jawaban jujurnya, tidak semua pesantren perlu buru-buru. Kalau santri masih puluhan, hampir semua pembayaran tunai langsung ke kantor, dan satu bendahara masih hafal kondisi tiap santri, buku besar yang rapi ditambah disiplin rekap mingguan sebenarnya masih bisa jalan. Memaksakan sistem di kondisi ini hanya menambah pekerjaan baru.

    Ukuran gampangnya begini. Hitung berapa jam per bulan yang habis untuk rekap, mencocokkan mutasi, dan menjawab pertanyaan soal pembayaran. Kalau totalnya masih beberapa jam dan jarang ada selisih, sistem manual Anda sehat. Kalau sudah memakan hitungan hari dan tiap bulan selalu ada angka yang tidak ketemu, itu sinyal yang layak didengar.

    Tanda-tanda bahwa manual mulai tidak cukup biasanya muncul bertahap. Jumlah santri melewati seratus. Wali makin banyak yang membayar lewat transfer. Rekap bulanan mulai molor ke tanggal 10. Atau pergantian bendahara membuat catatan lama sulit dibaca pengurus baru. Kalau dua atau tiga tanda ini sudah terasa, masalahnya bukan lagi kurang teliti, tapi volume yang memang sudah melebihi kapasitas pencatatan tangan.

    Soal biaya juga wajar jadi pertimbangan pertama. Sistem billing bukan pengeluaran kecil untuk sebagian pesantren, dan keputusannya sebaiknya dihitung, bukan diambil karena ikut-ikutan. Kami pernah menulis panduan lengkapnya di artikel berapa biaya sistem pesantren beserta hitungan ROI-nya, termasuk cara menilai apakah investasinya sepadan untuk ukuran pesantren Anda.

    Belajar dari Al-Muttaqin, pembayaran yang tercatat sendiri

    Pondok Pesantren Al-Muttaqin dulunya berada di posisi yang sama dengan banyak pesantren lain. Ratusan santri, aktivitas harian padat, dan hampir semua proses bergantung pada catatan manual serta koordinasi lewat pesan singkat. Ketika laporan dibutuhkan, pengurus harus mengumpulkan data dari berbagai sumber dulu.

    Bersama Arrazy, Al-Muttaqin membangun sistem manajemen pesantren terpadu. Salah satu bagian yang paling relevan dengan urusan keuangan adalah mekanisme pembayaran berbasis virtual account. Wali melakukan top-up saldo untuk anaknya, santri bertransaksi tanpa uang tunai, dan setiap mutasi keuangan tercatat otomatis lengkap dengan referensi transaksinya. Pengurus bisa melihat ringkasan arus kas langsung di dasbor, tanpa menunggu rekap akhir bulan. Akses sistem juga diatur per peran, jadi hanya orang yang berwenang yang bisa menyentuh data keuangan.

    Mekanisme itulah yang menjadi fondasi penagihan SPP digital: uang masuk dikenali otomatis milik santri yang mana, tercatat sendiri, dan bisa diaudit kapan saja. Detail lengkap sistemnya, dari modul tahfidz sampai perizinan gerbang, bisa dibaca di studi kasus SIM-Pesantren Al-Muttaqin.

    Pertanyaan yang sering diajukan

    Apakah wali santri harus install aplikasi?

    Tidak harus. Sistem billing pesantren umumnya berbasis web, jadi wali cukup membuka tautan lewat browser HP. Pemberitahuan tagihan pun bisa dikirim lewat kanal yang sudah biasa dipakai wali, seperti WhatsApp. Prinsipnya, makin sedikit langkah baru yang harus dipelajari wali, makin lancar sistemnya diadopsi.

    Bagaimana kalau ada wali yang tetap bayar tunai?

    Tetap bisa. Wali datang ke kantor pesantren seperti biasa, bendahara menerima uangnya, lalu mencatat pembayaran itu di sistem. Status tagihan santri langsung berubah lunas dan datanya menyatu dengan pembayaran transfer. Sistem digital tidak menutup jalur tunai, hanya memastikan semua jalur berakhir di satu catatan yang sama.

    Berapa lama setup sampai sistem bisa dipakai?

    Bagian teknisnya biasanya bukan yang paling lama. Yang paling menyita waktu justru merapikan data awal: daftar santri, nominal syahriah per jenjang, dan daftar keringanan atau beasiswa. Kalau data ini sudah rapi, proses setup sampai tagihan pertama terkirim umumnya selesai dalam hitungan minggu. Banyak pesantren memulai dari satu angkatan dulu sebagai uji coba sebelum diberlakukan ke semua santri.

    Kalau rekap SPP sudah mulai terasa seperti pekerjaan yang tidak ada habisnya, mungkin ini waktu yang pas untuk melihat opsinya. Tim kami di Arrazy biasa membantu pesantren memetakan kebutuhan dulu sebelum bicara sistem, termasuk menilai apakah kondisi pesantren Anda memang sudah butuh billing digital atau belum. Ceritakan saja dulu alur pembayaran yang sekarang berjalan, nanti kita lihat sama-sama bagian mana yang paling layak dibenahi lebih dulu.

  • Belajar Golang dari Nol #2: Variabel, Tipe Data, dan Zero Value

    Belajar Golang dari Nol #2: Variabel, Tipe Data, dan Zero Value

    Di Belajar Golang dari Nol #1 kamu sudah install Go dan menjalankan program pertama lewat go run. Sekarang kita masuk ke bahan bangunan paling dasar dari semua program: variabel, tipe data, dan satu konsep khas Go yang namanya zero value.

    Anggap variabel itu seperti kotak berlabel. Labelnya nama variabel, isinya nilai. Bedanya dengan bahasa lain, di Go setiap kotak juga punya aturan ketat soal barang apa yang boleh masuk. Kotak untuk angka tidak bisa diisi teks. Aturan ini yang bikin program Go jarang error aneh saat sudah jalan.

    Tiga Cara Deklarasi Variabel di Go

    Go punya tiga gaya untuk membuat variabel. Semuanya sering dipakai, jadi kenali satu per satu.

    1. var tanpa nilai awal

    var nama string
    var umur int
    
    fmt.Println(nama) // (string kosong)
    fmt.Println(umur) // 0

    Di sini kamu hanya menyiapkan kotaknya. Isinya belum ada, tapi Go otomatis memberi nilai default. Soal nilai default ini kita bahas lebih dalam di bagian zero value nanti.

    2. var dengan nilai awal

    var nama string = "Rizky"
    var umur = 25 // tipe int ditebak otomatis oleh Go

    Kalau nilai awal sudah ada, kamu boleh menulis tipenya atau membiarkan Go menebak sendiri. Menebak tipe dari nilai ini disebut type inference. Nilai 25 otomatis dianggap int, nilai "Rizky" otomatis dianggap string.

    3. Short declaration dengan :=

    nama := "Rizky"
    umur := 25

    Ini cara paling ringkas dan paling sering kamu lihat di kode Go sehari-hari. Tanda := artinya “buat variabel baru sekaligus isi nilainya”. Tanpa kata var, tanpa menulis tipe.

    Ada satu aturan penting: := hanya boleh dipakai di dalam function. Di luar function, misalnya di level package, kamu wajib pakai var. Kode di bawah ini menunjukkan bedanya.

    package main
    
    import "fmt"
    
    var appName = "Kasir Sederhana" // level package, wajib var
    
    func main() {
    	versi := "1.0" // di dalam function, boleh :=
    	fmt.Println(appName, versi)
    }

    Lalu kapan pakai yang mana? Panduan sederhananya begini:

    • Pakai := untuk variabel biasa di dalam function. Ini pilihan default kamu.
    • Pakai var kalau kamu butuh variabel di level package, atau kalau kamu sengaja ingin variabel kosong dulu dan diisi belakangan.
    • Pakai var dengan tipe eksplisit kalau tipe tebakan Go bukan yang kamu mau. Misalnya var saldo float64 = 10000, karena saldo := 10000 akan jadi int.

    Tipe Data Dasar yang Wajib Kamu Kenal

    Go punya banyak tipe data. Untuk sekarang, empat tipe ini cukup untuk hampir semua latihan awal.

    string

    Teks. Selalu ditulis dengan tanda kutip dua, bukan kutip satu.

    namaToko := "Kopi Senja"
    alamat := "Jl. Merdeka No. 10, Purwokerto"

    int

    Bilangan bulat. Cocok untuk hal yang dihitung satuan: jumlah barang, umur, jumlah user.

    stok := 120
    jumlahKaryawan := 8

    Go juga punya varian seperti int8, int32, dan int64. Angka di belakangnya menunjukkan berapa bit memori yang dipakai, yang menentukan seberapa besar angka yang bisa ditampung. int64 misalnya sering dipakai untuk ID di database yang nilainya bisa sangat besar. Untuk belajar, pakai int biasa saja dulu. Sisanya akan terasa gunanya saat kamu mulai kerja dengan database atau API.

    float64

    Bilangan desimal. Cocok untuk harga, berat, rating, dan apa pun yang punya koma.

    hargaKopi := 25000.0
    beratBiji := 0.25 // kg

    Perhatikan 25000.0. Titik nol di belakang itu penting. Tanpa itu, Go menganggapnya int. Dengan titik desimal, Go tahu kamu mau float64.

    bool

    Nilai benar atau salah. Isinya cuma dua kemungkinan: true atau false.

    sudahBayar := true
    tokoTutup := false

    Tipe ini kelihatan sepele, tapi hampir semua logika program dibangun di atasnya. Setiap if yang kamu tulis nanti ujungnya selalu sebuah bool.

    Zero Value: Nilai Default yang Bikin Tenang

    Sekarang konsep khas Go yang tadi sempat disinggung. Di Go, variabel yang dideklarasikan tanpa nilai awal tidak pernah kosong tanpa arti. Go selalu mengisinya dengan nilai default sesuai tipenya. Nilai default ini disebut zero value.

    • string menjadi "" (string kosong)
    • int dan float64 menjadi 0
    • bool menjadi false
    • tipe seperti pointer, slice, dan map menjadi nil

    Coba jalankan program kecil ini dan lihat hasilnya.

    package main
    
    import "fmt"
    
    func main() {
    	var nama string
    	var stok int
    	var harga float64
    	var aktif bool
    
    	fmt.Printf("nama: %q\n", nama)
    	fmt.Printf("stok: %d\n", stok)
    	fmt.Printf("harga: %f\n", harga)
    	fmt.Printf("aktif: %t\n", aktif)
    }

    Outputnya:

    nama: ""
    stok: 0
    harga: 0.000000
    aktif: false

    Kenapa ini desain yang enak? Karena kamu tidak pernah perlu bertanya “variabel ini sudah diisi atau belum, isinya sampah memori atau bukan”. Setiap variabel selalu punya nilai yang jelas dan bisa diprediksi sejak lahir. Kalau kamu pernah pegang JavaScript, ini beda jauh dengan undefined yang sering muncul tiba-tiba di tempat yang tidak kamu duga.

    Zero value juga sering dimanfaatkan langsung. Counter mulai dari 0, flag mulai dari false, teks mulai dari kosong. Banyak kode Go sengaja didesain agar zero value-nya langsung berguna tanpa perlu setup tambahan.

    Konstanta: Nilai yang Dikunci

    Kadang ada nilai yang tidak boleh berubah selama program berjalan. Rate diskon, nama aplikasi, batas maksimal upload. Untuk itu Go punya const.

    const appName = "Kasir Senja"
    const diskonMember = 0.1
    const maksimalQty = 100

    Bedanya dengan var ada dua. Pertama, nilai const harus sudah diketahui saat program di-compile, jadi kamu tidak bisa mengisinya dari input user atau hasil pemanggilan function biasa. Kedua, nilainya terkunci. Kalau kamu coba mengubahnya, program tidak akan bisa di-compile.

    const diskonMember = 0.1
    diskonMember = 0.2 // error: cannot assign to diskonMember

    Ini bagus. Lebih baik error muncul saat compile daripada diam-diam ada kode yang mengubah rate diskon di tengah jalan. Aturan praktisnya: kalau sebuah nilai memang tidak akan pernah berubah, jadikan const. Sisanya baru var atau :=.

    Konversi Tipe: Go Itu Ketat, dan Itu Bagus

    Go tidak mau menebak-nebak saat dua tipe berbeda bertemu. Operasi int dicampur float64 langsung ditolak compiler. Kamu harus konversi dulu secara eksplisit.

    qty := 3          // int
    harga := 12500.0  // float64
    
    // total := qty * harga        // error: mismatched types
    total := float64(qty) * harga  // benar: 37500

    Polanya sederhana: tulis nama tipe tujuan, lalu bungkus nilainya dengan tanda kurung. float64(qty) artinya “ubah qty menjadi float64”. Berlaku juga sebaliknya, int(harga), dengan catatan angka di belakang koma akan dibuang.

    Angka ke string dan sebaliknya dengan strconv

    Untuk konversi antara angka dan string, tipe castingnya berbeda urusan. string(65) tidak menghasilkan teks “65”, tapi karakter dengan kode 65. Yang benar, pakai package strconv dari standard library.

    package main
    
    import (
    	"fmt"
    	"strconv"
    )
    
    func main() {
    	// int ke string: Itoa (Integer to ASCII)
    	umur := 25
    	teksUmur := strconv.Itoa(umur)
    	fmt.Println("Umur saya " + teksUmur + " tahun")
    
    	// string ke int: Atoi (ASCII to Integer)
    	angka, err := strconv.Atoi("123")
    	if err != nil {
    		fmt.Println("Gagal konversi:", err)
    		return
    	}
    	fmt.Println("Hasil tambah satu:", angka+1)
    }

    Perhatikan baris angka, err := strconv.Atoi("123"). Kenapa hasilnya dua? Karena konversi string ke angka bisa gagal. String "123" jelas bisa jadi angka, tapi bagaimana dengan "abc"? Go menjawab kemungkinan gagal itu dengan mengembalikan dua nilai: hasilnya dan errornya. Kalau konversi sukses, err bernilai nil. Kalau gagal, err berisi keterangan kegagalannya dan kamu wajib menanganinya.

    Pola if err != nil ini akan kamu tulis ratusan kali sepanjang karier Go kamu. Ini cara Go memaksa programmer memikirkan kegagalan sejak awal, bukan menundanya sampai program crash di production. Detail cara kerja multiple return dan error akan kita kupas tuntas di bagian 3. Untuk sekarang, cukup hafalkan bentuknya.

    Kenalan dengan fmt.Printf

    Sebelum masuk latihan, kenalan dulu dengan fmt.Printf. Kalau fmt.Println mencetak apa adanya, Printf mencetak dengan format yang kamu atur lewat kode persen. Yang paling sering dipakai:

    • %s untuk string
    • %d untuk bilangan bulat
    • %f untuk desimal, dan %.2f untuk membatasi dua angka di belakang koma
    • %t untuk bool
    • %v untuk nilai apa pun, berguna saat malas mikir tipenya
    nama := "Rizky"
    qty := 3
    harga := 12500.0
    member := true
    
    fmt.Printf("%s beli %d barang seharga %.2f, member: %t\n", nama, qty, harga, member)
    // Rizky beli 3 barang seharga 12500.00, member: true

    Jangan lupa \n di akhir untuk pindah baris. Printf tidak menambahkannya otomatis seperti Println.

    Latihan: Program Hitung Total Belanja

    Sekarang gabungkan semua materi jadi satu program utuh. Kasusnya sederhana: hitung total belanja satu barang, lalu beri diskon 10 persen kalau pembelinya member. Buat file main.go baru, ketik ulang kodenya sendiri, jangan copy paste. Mengetik ulang itu cara belajar paling cepat.

    package main
    
    import "fmt"
    
    const diskonMember = 0.1 // 10 persen, dikunci dengan const
    
    func main() {
    	// data belanja
    	namaBarang := "Kopi Arabika 200g" // string
    	qty := 3                          // int
    	harga := 45000.0                  // float64
    	isMember := true                  // bool
    
    	// qty harus dikonversi dulu agar bisa dikali float64
    	subtotal := float64(qty) * harga
    
    	// zero value float64 adalah 0, jadi non-member otomatis diskonnya 0
    	var diskon float64
    	if isMember {
    		diskon = subtotal * diskonMember
    	}
    
    	total := subtotal - diskon
    
    	// cetak struk
    	fmt.Println("===== Struk Belanja =====")
    	fmt.Printf("Barang   : %s\n", namaBarang)
    	fmt.Printf("Qty      : %d\n", qty)
    	fmt.Printf("Harga    : Rp%.0f\n", harga)
    	fmt.Printf("Subtotal : Rp%.0f\n", subtotal)
    	fmt.Printf("Member   : %t\n", isMember)
    	fmt.Printf("Diskon   : Rp%.0f\n", diskon)
    	fmt.Printf("Total    : Rp%.0f\n", total)
    }

    Jalankan dengan go run main.go. Outputnya:

    ===== Struk Belanja =====
    Barang   : Kopi Arabika 200g
    Qty      : 3
    Harga    : Rp45000
    Subtotal : Rp135000
    Member   : true
    Diskon   : Rp13500
    Total    : Rp121500

    Lihat bagaimana semua materi hari ini terpakai. Ada const untuk rate diskon, := untuk variabel di dalam function, empat tipe data dasar, konversi float64(qty), zero value yang dimanfaatkan di variabel diskon, dan Printf untuk merapikan output.

    Sebagai latihan tambahan, coba ubah isMember jadi false dan jalankan lagi. Perhatikan diskon otomatis jadi 0 tanpa kamu menulis kode tambahan. Itu zero value yang bekerja untukmu. Lalu coba ganti qty := 3 menjadi qty := 3.0 dan lihat error apa yang muncul. Membaca pesan error compiler sejak dini akan sangat membantu di bagian-bagian berikutnya.

    Lanjut ke Bagian 3

    Hari ini kamu sudah pegang fondasi terpenting: tiga cara deklarasi variabel, empat tipe data dasar, zero value, konstanta, konversi tipe, dan kenalan pertama dengan pola if err != nil. Semua program Go, sesederhana atau serumit apa pun, dibangun dari bahan-bahan ini.

    Di bagian berikutnya kita masuk ke topik yang membuat kode kamu mulai terstruktur: “Belajar Golang dari Nol #3: Function, Multiple Return, dan Error Pertamamu”. Di sana misteri kenapa Atoi mengembalikan dua nilai akan terjawab tuntas.

    Seri ini kami tulis dari pengalaman sehari-hari, karena tim Arrazy memang membangun backend produksi dengan Go untuk berbagai sistem aplikasi klien kami.

  • Contoh Percakapan Chatbot Toko Online: Template Siap Pakai

    Contoh Percakapan Chatbot Toko Online: Template Siap Pakai

    Artikel ini berisi 5 template percakapan chatbot toko online yang bisa langsung Anda salin dan sesuaikan. Bukan teori, bukan penjelasan apa itu chatbot. Langsung contoh dialognya. Lima skenario yang dicover: tanya stok dan varian produk, tanya ongkir dan estimasi sampai, cek status pesanan, komplain barang rusak atau salah kirim, dan follow-up keranjang yang ditinggal pembeli.

    Tiap template ditulis dalam bahasa chat yang memang dipakai orang Indonesia sehari-hari. Ada juga catatan singkat kenapa alurnya dibuat begitu, termasuk kapan bot harus berhenti dan oper ke admin. Bagian itu sering dilupakan, padahal justru paling menentukan pelanggan betah atau kesal.

    Template 1: Tanya Stok dan Varian Produk

    Ini pertanyaan paling sering masuk di toko online mana pun. Pola umumnya: pelanggan tanya satu produk, lalu lanjut tanya warna, ukuran, atau varian lain. Bot harus bisa jawab spesifik, bukan lempar link katalog lalu selesai.

    Pelanggan: Kak gamis seri Naura yang navy masih ada?

    Bot: Halo kak, makasih sudah mampir. Gamis Naura warna navy masih ready ya kak. Tersedia ukuran S, M, L, dan XL. Kakak biasanya pakai ukuran apa?

    Pelanggan: Yang L kak. Itu bahannya apa ya?

    Bot: Ukuran L ready kak. Bahannya crepe premium, adem dan nggak nerawang. Kalau mau, aku kirimkan foto detail bahannya ya kak?

    Pelanggan: Boleh kak

    Bot: [mengirim foto] Ini detail bahannya kak. Kalau cocok, langsung aku bantu proses ya. Cukup balas “order” nanti aku pandu langkahnya.

    Catatan alur: bot selalu menutup jawaban dengan satu pertanyaan atau satu ajakan kecil. Jawab lalu diam itu kebiasaan bot yang bikin chat mati. Perhatikan juga bot menanyakan ukuran duluan sebelum ditanya. Itu memangkas satu langkah menuju order. Kalau produk yang ditanya ternyata kosong, bot jangan cuma bilang habis. Tawarkan varian terdekat atau minta izin menghubungi lagi saat restock.

    Template 2: Tanya Ongkir dan Estimasi Sampai

    Pertanyaan ongkir kelihatan sepele tapi sering jadi penentu jadi beli atau tidak. Kuncinya bot harus minta data yang dibutuhkan sekali saja, jangan bolak-balik nanya.

    Pelanggan: Min ongkir ke Purwokerto berapa ya?

    Bot: Halo kak. Biar akurat, boleh info kecamatannya kak? Sama rencana ordernya berapa pcs, soalnya ongkir ngikut berat paket.

    Pelanggan: Purwokerto Utara, mau ambil 2 gamis

    Bot: Siap kak. Untuk 2 gamis (sekitar 1 kg) ke Purwokerto Utara: JNE REG Rp18.000 estimasi 2-3 hari, J&T Rp18.000 estimasi 2-3 hari, SiCepat HALU Rp15.000 estimasi 3-4 hari. Order sebelum jam 3 sore dikirim hari ini juga ya kak.

    Pelanggan: Kalau order sekarang sampai Jumat nggak kak? Buat kado soalnya

    Bot: Hari ini Selasa, kalau pakai JNE REG estimasinya Kamis atau Jumat kak. Kalau mau lebih aman untuk kado, ada opsi YES Rp29.000 yang biasanya sampai besok. Mau aku buatkan orderannya sekarang kak?

    Catatan alur: bot minta kecamatan dan jumlah barang dalam satu pesan, bukan dua pertanyaan terpisah. Lalu jawaban ongkir langsung lengkap dengan estimasi hari, jadi pelanggan tidak perlu tanya lagi. Kalimat “order sebelum jam 3 dikirim hari ini” itu bukan hiasan. Info batas jam kirim terbukti sering jadi pendorong orang memutuskan saat itu juga.

    Template 3: Cek Status Pesanan

    Orang yang tanya “pesanan saya sudah sampai mana” biasanya sudah agak cemas. Jangan disuruh menunggu lama, dan jangan dijawab template kosong seperti “mohon ditunggu ya kak”.

    Pelanggan: Kak mau tanya, pesanan saya sudah dikirim belum ya? Atas nama Rina

    Bot: Halo kak Rina. Aku bantu cek ya. Boleh info nomor ordernya kak? Formatnya ada di chat konfirmasi, contohnya INV-20260721-XXX.

    Pelanggan: INV-20260721-088

    Bot: Ketemu kak. Pesanan INV-20260721-088 (gamis Naura navy, ukuran L) sudah dikirim kemarin sore via JNE, resi 1234567890. Posisi terakhir: transit di gudang sortir Semarang, estimasi sampai besok atau lusa. Mau aku kirimkan link lacak resinya kak?

    Pelanggan: Boleh kak makasih

    Bot: Ini ya kak [link]. Kalau sampai Jumat belum ada pergerakan, kabari aku lagi, nanti langsung aku teruskan ke tim untuk dicek ke ekspedisi.

    Catatan alur: bot menyebut ulang isi pesanan, bukan cuma status. Itu cara halus menunjukkan datanya benar-benar dicek, bukan jawaban asal. Kalimat penutup juga penting: bot memberi batas waktu jelas kapan pelanggan boleh komplain lagi, sekaligus janji eskalasi. Ini mencegah pelanggan spam chat tiap beberapa jam. Syaratnya satu: chatbot Anda memang tersambung ke data order. Kalau bot cuma bisa jawab “silakan cek resi di website”, lebih baik pertanyaan ini langsung dioper ke admin saja.

    Template 4: Komplain Barang Rusak atau Salah Kirim

    Ini skenario paling sensitif. Aturan utamanya: bot boleh menerima komplain dan mengumpulkan data, tapi keputusan solusi harus di tangan manusia. Pelanggan yang sedang kecewa lalu merasa dipingpong robot akan berubah dari kecewa jadi marah.

    Pelanggan: Kak ini gimana ya, saya pesan warna navy yang dateng malah hitam. Padahal buat acara Sabtu ini

    Bot: Mohon maaf banget ya kak atas kesalahannya. Ini murni kelalaian kami dan pasti kami bantu selesaikan. Biar cepat diproses, boleh kirimkan foto produk yang diterima beserta label pengirimannya kak?

    Pelanggan: [mengirim foto] Ini kak

    Bot: Terima kasih kak, fotonya sudah aku terima dan komplain sudah aku catat dengan nomor tiket CP-1142. Karena ini kesalahan kirim dari kami, kakak tidak perlu keluar biaya apa pun. Aku sambungkan sekarang ke kak Dina dari tim kami untuk atur penggantiannya ya, maksimal 15 menit lagi kak Dina yang balas chat ini.

    Admin (manusia): Halo kak Rina, aku Dina. Sekali lagi mohon maaf ya kak. Barang pengganti warna navy aku kirim hari ini pakai ekspedisi tercepat biar sampai sebelum Sabtu. Yang hitam nggak usah dikirim balik dulu, nanti kurir kami yang jemput. Aman ya kak?

    Catatan alur: perhatikan bot cuma melakukan tiga hal. Minta maaf tanpa membela diri, kumpulkan bukti foto, dan buat nomor tiket. Setelah itu langsung eskalasi ke manusia dengan menyebut nama admin dan batas waktu respon yang konkret. “Maksimal 15 menit lagi” jauh lebih menenangkan daripada “akan segera kami proses”. Jangan pernah biarkan bot menjanjikan solusi spesifik seperti refund atau kirim ulang, karena tiap kasus komplain bisa beda kondisinya dan janji bot yang meleset akan jadi masalah baru.

    Template 5: Follow-up Keranjang yang Ditinggal

    Banyak calon pembeli tanya panjang lebar, bilang mau order, lalu hilang. Bukan berarti batal. Kadang cuma ketiduran atau kepotong kerjaan. Follow-up satu kali dengan nada santai sering cukup untuk menghidupkan lagi chat yang mati.

    Bot (H+1 setelah chat terakhir): Halo kak Sari, kemarin sempat tanya gamis Naura navy ukuran M ya kak. Kebetulan stok ukuran M tinggal 3 pcs, jadi aku kabari dulu sebelum keburu habis. Kalau masih mau, aku bisa bantu prosesnya sekarang, atau kalau masih mikir-mikir juga nggak apa-apa kak.

    Pelanggan: Eh iya kak kemarin kelupaan hehe. Itu bisa COD nggak ya?

    Bot: Bisa kak, kami support COD untuk area kakak. Nanti bayar ke kurir pas barang sampai. Aku buatkan orderannya ya kak? Tinggal konfirmasi alamat lengkapnya aja.

    Pelanggan: Gas kak

    Catatan alur: follow-up dikirim sekali di H+1, bukan tiga kali sehari. Isinya menyebut produk spesifik yang kemarin ditanyakan, jadi terasa personal, bukan broadcast massal. Alasan follow-up juga harus jujur. Kalau stok memang menipis, sebutkan. Kalau tidak, cukup tanya kabar ordernya tanpa drama stok palsu. Sekali pelanggan sadar Anda pakai jurus stok tinggal sedikit padahal bohong, kepercayaan hilang dan susah balik. Kalau setelah satu follow-up tetap tidak dibalas, berhenti. Kirim lagi hanya saat ada momen baru seperti promo atau restock.

    Logic follow-up seperti ini yang kami pasang di Aliqa AI Assistant, chatbot custom untuk Aliqa Muslim Indonesia. Masalah mereka waktu itu volume chat tinggi, lead sering terlewat, dan respon antar admin tidak konsisten. Solusinya bukan cuma bot penjawab, tapi alur follow-up otomatis supaya lead panas tidak hilang begitu saja, plus dashboard untuk memantau performa percakapan dan order.

    Prinsip yang Bikin Percakapan Bot Enak Dibaca

    Lima template di atas beda skenario tapi mengikuti prinsip yang sama. Ini beberapa hal yang kami pegang setiap merancang alur percakapan, hasil dari mengerjakan chatbot untuk bisnis yang chat masuknya ratusan per hari.

    • Satu pesan, satu tujuan. Jangan gabungkan salam, promosi, tiga pertanyaan, dan link katalog dalam satu balasan panjang. Orang membaca chat sambil lalu. Pesan pendek yang jelas selalu menang.
    • Selalu tutup dengan langkah berikutnya. Setiap balasan bot diakhiri pertanyaan atau ajakan kecil. Chat yang berakhir dengan “oke kak” tanpa arah itu penjualan yang menguap.
    • Bot harus tahu kapan menyerah. Komplain, negosiasi harga, permintaan aneh di luar alur, semua itu jatah manusia. Bot yang memaksa menjawab semuanya justru merusak pengalaman. Aturan praktisnya: kalau pelanggan mengulang pertanyaan yang sama dua kali atau mulai menunjukkan emosi, langsung oper ke admin.
    • Tulis seperti admin terbaik Anda mengetik. Cara paling cepat merancang bahasa bot: buka riwayat chat admin yang paling sering closing, lalu tiru gaya bahasanya. Bot yang kaku dan formal terasa seperti mesin penjawab kantor pajak, bukan toko yang ramah.

    Template Sudah Ada, Tinggal Dijalankan

    Kelima template di atas bebas Anda pakai dan modifikasi. Ganti nama produk, sesuaikan gaya bahasa dengan karakter toko Anda, lalu uji ke beberapa pelanggan dulu sebelum dipasang penuh.

    Yang perlu diingat, template hanyalah naskah. Supaya benar-benar jalan otomatis, naskah ini butuh sistem di belakangnya: koneksi ke data stok, data order, logic eskalasi ke admin, dan follow-up terjadwal. Kalau mayoritas pelanggan Anda chat lewat WhatsApp, ada catatan khusus soal itu di halaman chatbot AI untuk WhatsApp.

    Dan kalau Anda ingin alur percakapan yang dirancang khusus mengikuti SOP dan produk toko Anda sendiri, bukan template generik bawaan platform, tim kami bisa bantu lewat jasa pembuatan chatbot. Ceritakan saja dulu skenario chat yang paling sering bikin tim Anda kewalahan, nanti kita diskusikan alurnya bareng.

  • Aplikasi Simpan Pinjam Koperasi: Fitur yang Dipakai Pengurus

    Aplikasi Simpan Pinjam Koperasi: Fitur yang Dipakai Pengurus

    Fitur inti aplikasi simpan pinjam koperasi sebenarnya cuma lima kelompok: data anggota, pencatatan simpanan (pokok, wajib, sukarela), pengelolaan pinjaman berikut angsuran dan jasanya, laporan keuangan plus perhitungan SHU, dan akses untuk anggota mengecek saldonya sendiri. Kalau lima kelompok ini beres, sebagian besar pekerjaan administrasi harian koperasi sudah tertangani.

    Sisanya di artikel ini pendalaman. Kenapa lima kelompok itu yang penting, apa yang perlu Anda cek di tiap fiturnya sebelum memutuskan pakai sistem, dan fitur mana yang kedengarannya keren di brosur tapi jarang disentuh setelah sistem berjalan. Semuanya ditulis dari sudut pandang pengurus, bukan dari daftar fitur vendor.

    Masalah pembukuan manual itu bukan capeknya, tapi selisihnya

    Hampir semua koperasi yang mulai cari aplikasi punya cerita yang mirip. Simpanan dicatat di buku besar. Angsuran dicatat di buku lain. Kas dicatat di buku lain lagi. Tiap akhir bulan, bendahara duduk berhari-hari merekap semuanya ke Excel. Dan hampir selalu ada angka yang tidak ketemu.

    Selisih seribu dua ribu rupiah kedengarannya sepele. Tapi di koperasi, selisih kecil itu harus dicari sampai ketemu. Tidak bisa dibulatkan begitu saja, karena ini uang anggota. Satu selisih bisa menghabiskan waktu setengah hari, menelusuri catatan mundur berminggu-minggu.

    Masalah kedua muncul di akhir tahun. Perhitungan SHU butuh data simpanan dan transaksi pinjaman tiap anggota selama setahun penuh. Kalau datanya tersebar di beberapa buku dan beberapa file Excel, penyusunan laporan RAT bisa makan waktu berminggu-minggu. Salah hitung sedikit, anggota protes di rapat.

    Masalah ketiga yang paling sering bikin pengurus tidak enak hati: anggota tanya saldo. Di koperasi guru misalnya, guru yang mau mengajukan pinjaman baru biasanya tanya dulu, simpanan saya sudah berapa, sisa pinjaman saya tinggal berapa. Kalau jawabannya harus menunggu bendahara buka buku dulu, kepercayaan pelan-pelan terkikis. Bukan karena ada yang salah, tapi karena tidak ada yang bisa dilihat.

    Lima kelompok fitur yang benar-benar dipakai tiap hari

    Saat membandingkan aplikasi simpan pinjam, daftar fiturnya bisa panjang sekali. Supaya tidak pusing, fokus dulu ke lima kelompok ini. Ini yang akan dibuka pengurus setiap hari, bukan sebulan sekali.

    Data anggota yang jadi satu sumber kebenaran

    Kedengarannya sepele, padahal ini fondasi. Semua simpanan, pinjaman, dan perhitungan SHU menggantung ke data anggota. Yang perlu dicek: apakah data anggota cukup lengkap untuk kebutuhan koperasi Anda (nomor anggota, tanggal masuk, unit kerja untuk koperasi karyawan), apakah ada status keanggotaan (aktif, keluar, meninggal), dan apakah anggota baru otomatis dibuatkan akun untuk mengakses sistem. Kalau anggota keluar, sistem juga harus bisa menghitung pengembalian simpanannya dengan rapi.

    Simpanan: pokok, wajib, sukarela

    Tiga jenis simpanan ini perilakunya beda. Simpanan pokok dibayar sekali di awal. Simpanan wajib rutin tiap bulan, dan di koperasi karyawan biasanya dipotong dari gaji. Simpanan sukarela bebas setor dan bebas tarik. Aplikasi yang baik memperlakukan ketiganya sebagai produk terpisah dengan aturan masing-masing, bukan satu kolom saldo yang dicampur.

    Satu hal yang sering terlewat saat demo aplikasi: coba tanyakan bagaimana input simpanan wajib untuk banyak anggota sekaligus. Kalau bendahara harus input satu per satu untuk 200 anggota tiap bulan, itu bukan penghematan waktu, itu cuma memindahkan capek dari buku ke layar.

    Pinjaman, angsuran, dan hitungan jasa

    Ini jantungnya. Alur lengkapnya: anggota mengajukan pinjaman, pengurus menilai kelayakan, pinjaman disetujui atau ditolak, lalu sistem membuat jadwal angsuran otomatis. Tiap pembayaran angsuran tercatat dan langsung mengurangi sisa pinjaman.

    Yang wajib dicek di bagian ini: metode perhitungan jasa. Ada koperasi yang pakai bunga flat, ada yang menurun (efektif), ada yang punya aturan sendiri hasil kesepakatan RAT. Pastikan aplikasi mendukung metode yang koperasi Anda pakai, jangan koperasi yang dipaksa menyesuaikan aplikasi. Tanyakan juga soal pelunasan dipercepat dan denda keterlambatan, dua kasus yang pasti terjadi di dunia nyata.

    Untuk koperasi yang lebih besar, alur persetujuan berjenjang jadi penting. Pinjaman kecil cukup disetujui manajer, pinjaman besar harus naik ke pengurus. Kalau semua orang bisa menyetujui semua pinjaman, kontrol internalnya bolong.

    Laporan keuangan dan SHU

    Di sinilah perbedaan paling terasa antara aplikasi pencatatan biasa dan sistem yang serius. Aplikasi pencatatan hanya menyimpan transaksi. Sistem yang serius meneruskan tiap transaksi ke jurnal akuntansi secara otomatis, sehingga neraca dan laporan sisa hasil usaha bisa ditarik kapan saja tanpa rekap ulang.

    Efeknya besar saat RAT. Data simpanan dan partisipasi pinjaman tiap anggota sudah tersedia sepanjang tahun, jadi perhitungan SHU tinggal dijalankan sesuai persentase yang disepakati. Pekerjaan yang tadinya berminggu-minggu jadi hitungan hari, dan angkanya bisa ditelusuri kalau ada yang bertanya.

    Akses anggota untuk cek saldo sendiri

    Fitur ini sering dianggap pelengkap, padahal justru yang paling terasa buat anggota. Anggota bisa login, lihat saldo simpanan, lihat sisa pinjaman dan jadwal angsuran, tanpa harus bertanya ke bendahara. Pertanyaan berulang berkurang, dan yang lebih penting, anggota merasa koperasinya transparan. Untuk KSP di desa yang anggotanya belum semua akrab dengan aplikasi, minimal pengurus bisa membuka data itu di depan anggota dalam hitungan detik.

    Fitur yang kedengarannya keren tapi jarang dipakai

    Supaya adil, ini sisi yang jarang diceritakan vendor. Beberapa fitur terlihat menarik di demo tapi dalam praktik jarang disentuh.

    • Grafik dashboard yang berlebihan. Satu dua angka kunci itu berguna. Lima belas grafik warna-warni biasanya cuma dilihat di minggu pertama.
    • Fitur marketplace atau PPOB di dalam aplikasi koperasi. Terdengar seperti sumber pendapatan baru, tapi kalau simpan pinjamnya sendiri belum rapi, fitur tambahan ini hampir pasti terbengkalai.
    • Notifikasi untuk segala hal. Pengingat jatuh tempo angsuran itu berguna. Notifikasi tiap ada transaksi apa pun, orang berhenti membacanya setelah seminggu.
    • Chat internal antar pengurus. Semua orang sudah pakai WhatsApp. Fitur chat di aplikasi koperasi hampir selalu kosong.

    Bukan berarti fitur di atas selalu buruk. Tapi kalau anggarannya terbatas, lebih baik uangnya dipakai memastikan lima kelompok fitur inti tadi berjalan mulus daripada membayar fitur yang akhirnya jadi menu mati.

    Belajar dari Koperasi Dwija Usaha

    Contoh nyata bisa dilihat di studi kasus Koperasi Dwija Usaha yang kami kerjakan. Koperasi ini menjalankan tiga unit usaha sekaligus: perdagangan barang, pembelian TBS kelapa sawit dari petani, dan simpan pinjam untuk anggota. Sebelumnya ketiga unit berjalan dengan pencatatan terpisah-pisah, sehingga pengurus sulit melihat kondisi keuangan koperasi secara utuh. Rekap simpanan dan angsuran manual rawan selisih, dan penyusunan laporan SHU tahunan lama karena data harus dikumpulkan dari banyak sumber.

    Untuk unit simpan pinjamnya, sistem yang kami bangun mencakup jenis dan produk simpanan, setoran, penarikan, pengajuan pinjaman, survey kelayakan, persetujuan berjenjang sesuai limit wewenang, jadwal angsuran, sampai pembayaran angsuran anggota. Setiap anggota baru otomatis dibuatkan akun akses. Semua transaksi dari tiga unit usaha bermuara ke modul akuntansi dengan jurnal otomatis yang selalu balance, jadi neraca saldo bisa ditarik tanpa rekap manual.

    Satu hal yang menurut kami penting dari proyek ini: sistemnya mengikuti struktur organisasi asli koperasi. Ketua, pengawas, manajer unit, kasir, teller, sampai surveyor punya akses sesuai wewenang masing-masing, dan setiap perubahan data penting tercatat di audit trail sehingga Dewan Pengawas bisa menelusurinya. Aplikasi yang baik menyesuaikan diri dengan cara koperasi bekerja, bukan sebaliknya.

    Mulai dari mana kalau koperasi Anda masih manual

    Tidak perlu langsung membeli sistem paling lengkap. Urutannya kira-kira begini. Pertama, rapikan dulu data anggota dan saldo terakhir, karena data inilah yang akan dimigrasikan. Kedua, tentukan aturan main yang selama ini berjalan: metode perhitungan jasa, besaran simpanan wajib, persentase pembagian SHU. Ketiga, baru bandingkan aplikasi, dan ukur setiap fiturnya dengan pertanyaan sederhana, apakah ini akan dipakai tiap hari atau cuma bagus di demo.

    Kalau proses di koperasi Anda punya kekhasan yang tidak tertampung aplikasi jadi, misalnya aturan SHU hasil kesepakatan RAT yang unik atau alur persetujuan yang berlapis, sistem aplikasi custom bisa jadi jalan tengahnya. Sistem dibangun mengikuti proses yang sudah berjalan, bukan memaksa pengurus mengubah kebiasaan yang sudah disepakati anggota.

    Kalau mau ngobrol dulu soal kondisi koperasi Anda, silakan hubungi kami. Ceritakan saja prosesnya sekarang seperti apa, nanti kita diskusikan bagian mana yang paling layak dibenahi lebih dulu.

    Pertanyaan yang sering muncul

    Data simpanan dan pinjaman lama kami masih di buku dan Excel. Bisa dipindah?

    Bisa, dan ini justru tahap yang paling menentukan. Praktik yang umum: saldo akhir tiap anggota (simpanan per jenis dan sisa pinjaman) dijadikan saldo awal di sistem, lalu transaksi berjalan dicatat di sistem sejak tanggal cut-off. Riwayat lama tidak harus diinput ulang semuanya. Yang penting saldo awalnya diverifikasi dulu bersama pengurus supaya tidak ada selisih yang terbawa.

    Koperasi kami kecil, anggotanya belum sampai seratus. Perlu aplikasi?

    Tergantung beban pengurusnya. Kalau rekap bulanan masih selesai dalam satu dua jam dan tidak pernah ada selisih, sistem manual Anda mungkin masih cukup. Tapi kalau bendahara mulai kewalahan, sering ada selisih, atau anggota mulai sering menanyakan transparansi saldo, itu tanda sudah waktunya. Justru migrasi paling enak dilakukan saat anggota masih sedikit, karena datanya belum terlalu banyak.

    Berapa biaya membuat aplikasi simpan pinjam?

    Jujur saja, tidak ada satu angka yang berlaku untuk semua. Biayanya bergantung pada cakupan: apakah cukup simpan pinjam saja atau ada unit usaha lain, seberapa rumit aturan jasa dan SHU-nya, dan apakah perlu akses khusus untuk anggota. Aplikasi jadi berbasis langganan biasanya lebih murah di awal, sedangkan sistem custom lebih masuk akal kalau proses koperasi Anda punya banyak kekhasan. Cara paling cepat tahu angkanya ya diceritakan dulu kebutuhannya, baru dihitung.

  • Belajar Golang dari Nol #1: Kenalan dengan Go dan Cara Installnya

    Belajar Golang dari Nol #1: Kenalan dengan Go dan Cara Installnya

    Go (sering disebut Golang) adalah bahasa pemrograman open source yang dibuat di Google oleh Robert Griesemer, Rob Pike, dan Ken Thompson, lalu dirilis ke publik tahun 2009. Bahasa ini dirancang untuk satu hal: membuat software yang cepat dan mudah dirawat, tanpa ritual yang ribet. Di dunia nyata, Go paling sering dipakai untuk backend API, tool CLI, dan service yang butuh performa tinggi. Google jelas memakainya. Uber memakainya untuk banyak microservice mereka. Di Indonesia, Gojek dan Tokopedia sudah lama menjadikan Go tulang punggung backend mereka.

    Jadi kalau kamu ingin serius di dunia backend, Go adalah salah satu pilihan paling masuk akal saat ini. Seri “Belajar Golang dari Nol” ini akan menemani kamu dari titik paling awal: belum pernah menyentuh Go sama sekali. Mungkin kamu baru bisa sedikit PHP atau JavaScript. Tidak masalah. Kita mulai pelan.

    Kenapa Go Enak untuk Pemula Backend

    Ada beberapa alasan kenapa saya suka merekomendasikan Go sebagai bahasa backend pertama atau kedua.

    • Kompilasinya cepat. Kamu edit kode, jalankan, hasilnya muncul dalam hitungan detik. Siklus coba-salah-perbaiki jadi singkat, dan itu penting banget saat belajar.
    • Hasilnya satu binary. Saat kamu build program Go, hasilnya satu file executable yang bisa langsung dijalankan di server. Tidak perlu install runtime, interpreter, atau setumpuk dependency di server tujuan. Kalau kamu terbiasa dengan PHP yang butuh web server plus interpreter di sisi produksi, ini rasanya seperti pindah dari koper besar ke satu tas selempang.
    • Sintaksnya kecil. Go hanya punya 25 keyword. Bandingkan dengan bahasa lain yang bisa dua kali lipatnya. Artinya, hal yang perlu kamu hafal sedikit. Kode Go milik orang lain juga gampang dibaca karena semua orang menulis dengan gaya yang kurang lebih sama.
    • Ada garbage collector. Kamu tidak perlu mengatur memori secara manual seperti di C. Go yang membereskan memori yang sudah tidak terpakai. Kamu fokus ke logika program saja.

    Biar adil, Go juga punya sisi yang kurang enak. Pertama, kodenya cenderung verbose. Hal yang di JavaScript bisa satu baris, di Go kadang butuh lima baris. Kedua, error handling-nya berulang. Kamu akan sering sekali menulis pola if err != nil sampai hafal di luar kepala. Sebagian orang menganggap ini membosankan. Tapi ada hikmahnya: kamu dipaksa memikirkan setiap kemungkinan error, dan itu kebiasaan bagus untuk programmer backend.

    Cara Install Go

    Semua file instalasi resmi ada di satu tempat: go.dev/dl. Jangan unduh dari tempat lain. Pilih bagian sesuai sistem operasi kamu di bawah ini.

    Install Go di Linux

    Di Linux, cara paling bersih adalah memakai tarball resmi. Hindari install dari apt bawaan distro karena versinya sering tertinggal jauh.

    Pertama, unduh tarball dari go.dev/dl. Cek dulu nomor versi terbaru di halaman itu, lalu sesuaikan nama filenya. Contoh di bawah memakai versi 1.25.1 untuk arsitektur amd64:

    wget https://go.dev/dl/go1.25.1.linux-amd64.tar.gz

    Kedua, hapus instalasi Go lama (kalau ada) dan ekstrak ke /usr/local:

    sudo rm -rf /usr/local/go
    sudo tar -C /usr/local -xzf go1.25.1.linux-amd64.tar.gz

    Perintah tar -C /usr/local artinya ekstrak isi arsip ke folder /usr/local. Hasilnya, Go terpasang di /usr/local/go.

    Ketiga, tambahkan Go ke PATH. PATH itu daftar folder tempat terminal mencari program saat kamu mengetik sebuah perintah. Kalau folder bin milik Go tidak ada di PATH, terminal tidak akan kenal perintah go. Buka file ~/.bashrc (atau ~/.zshrc kalau kamu pakai zsh), lalu tambahkan baris ini di paling bawah:

    export PATH=$PATH:/usr/local/go/bin

    Simpan, lalu muat ulang konfigurasi shell:

    source ~/.bashrc

    Kalau pakai zsh, ganti dengan source ~/.zshrc.

    Install Go di Windows

    Di Windows jauh lebih sederhana:

    • Buka go.dev/dl lalu unduh file installer berakhiran .msi untuk Windows.
    • Jalankan file itu dengan klik dua kali, lalu ikuti wizard-nya. Klik Next terus sampai selesai. Secara default Go terpasang di C:\Program Files\Go.
    • Installer ini otomatis mengatur PATH untukmu, jadi tidak ada langkah manual tambahan.

    Satu catatan penting: setelah instalasi selesai, tutup semua jendela Command Prompt atau PowerShell yang sedang terbuka, lalu buka yang baru. Terminal yang sudah terbuka sebelum instalasi belum membaca PATH yang baru.

    Install Go di macOS

    Kalau kamu sudah pakai Homebrew, satu perintah ini cukup:

    brew install go

    Homebrew akan mengurus PATH secara otomatis. Kalau belum pakai Homebrew, alternatifnya unduh installer .pkg dari go.dev/dl, klik dua kali, lalu ikuti wizard-nya seperti install aplikasi Mac pada umumnya.

    Verifikasi Instalasi

    Apa pun sistem operasinya, cara mengeceknya sama. Buka terminal baru, lalu ketik:

    go version

    Kalau instalasi berhasil, kamu akan melihat output kurang lebih seperti ini:

    go version go1.25.1 linux/amd64

    Nomor versi dan nama platformnya bisa berbeda sesuai apa yang kamu install. Yang penting perintah itu mengeluarkan versi, bukan pesan “command not found”. Kalau muncul “command not found” di Linux atau macOS, kemungkinan besar masalahnya di langkah PATH tadi. Cek lagi apakah baris export sudah tersimpan dan kamu sudah menjalankan source atau membuka terminal baru.

    Oh ya, kalau kamu sempat baca tutorial Go yang lama, mungkin kamu menemukan pembahasan panjang soal GOPATH dan struktur folder yang wajib diikuti. Abaikan saja. Sejak Go versi modern memakai sistem module, kamu bisa menaruh proyek di folder mana pun yang kamu suka. Tidak perlu setting tambahan apa-apa lagi setelah langkah instalasi di atas.

    Program Go Pertama: Hello World

    Sekarang bagian paling menyenangkan. Buat folder baru untuk latihan, misalnya halo-go, lalu masuk ke dalamnya:

    mkdir halo-go
    cd halo-go

    Buat file bernama main.go dengan teks editor favoritmu (VS Code juga boleh), lalu isi dengan kode ini:

    package main
    
    import "fmt"
    
    func main() {
    	fmt.Println("Halo, Go!")
    }

    Enam baris saja, tapi setiap barisnya punya makna. Mari kita bedah satu per satu.

    package main

    Setiap file Go wajib diawali deklarasi package. Package itu semacam label yang mengelompokkan file-file kode yang saling berhubungan. Nah, package main punya arti khusus: ini penanda bahwa program kamu adalah program yang bisa dijalankan langsung, bukan sekadar pustaka yang dipakai program lain. Anggap saja seperti label “pintu masuk utama” pada sebuah gedung.

    import “fmt”

    Baris ini mengambil package fmt dari pustaka standar Go. Nama fmt singkatan dari format, isinya fungsi-fungsi untuk mencetak dan memformat teks. Tanpa baris import ini, kamu tidak bisa memakai fmt.Println. Go bahkan menolak kompilasi kalau kamu meng-import package yang tidak dipakai. Ketat memang, tapi hasilnya kode kamu selalu bersih dari import sampah.

    func main()

    func adalah kata kunci untuk mendefinisikan fungsi. Fungsi bernama main di dalam package main adalah titik awal eksekusi program. Saat program dijalankan, Go langsung mencari fungsi ini dan mengeksekusi isinya baris per baris. Satu program hanya boleh punya satu func main.

    fmt.Println(“Halo, Go!”)

    Ini isi programnya: memanggil fungsi Println milik package fmt untuk mencetak teks ke layar, lalu pindah ke baris baru. Pola namaPackage.NamaFungsi ini akan sangat sering kamu temui di Go.

    Menjalankan Program: go run vs go build

    Ada dua cara menjalankan program Go, dan keduanya penting kamu pahami. Cara pertama, go run:

    go run main.go

    Outputnya:

    Halo, Go!

    Perintah go run mengompilasi kode ke file sementara, menjalankannya, lalu membuang hasil kompilasinya. Cocok untuk fase belajar dan development karena praktis: satu perintah, langsung lihat hasil.

    Cara kedua, go build:

    go build -o halo main.go

    Perintah ini mengompilasi kode dan menyimpan hasilnya sebagai file executable bernama halo (flag -o menentukan nama outputnya). Di Windows hasilnya halo.exe. Sekarang jalankan binary itu:

    ./halo

    Di Windows cukup ketik halo. Hasilnya sama: teks “Halo, Go!” muncul di layar.

    Bedanya apa? go run itu seperti masak lalu langsung makan di dapur. go build seperti masak lalu mengemas makanannya rapi dalam kotak, siap dibawa dan dimakan di mana saja. File hasil go build bisa kamu salin ke server atau komputer lain yang bahkan tidak punya Go terinstall, dan program tetap jalan. Inilah keunggulan “satu binary” yang saya sebut di awal, dan alasan kenapa deployment aplikasi Go terkenal simpel.

    Persiapan Bagian 2: go mod init

    Satu hal lagi sebelum kita tutup. Proyek Go modern selalu diawali dengan membuat module. Module itu semacam identitas proyek plus catatan dependency-nya, mirip peran package.json di dunia Node.js. Di dalam folder proyekmu, jalankan:

    go mod init halo-go

    Perintah ini membuat file go.mod yang berisi nama module dan versi Go yang dipakai. Untuk latihan lokal, nama module bebas. Nanti kalau proyekmu dipublikasikan, biasanya nama module memakai alamat repositori seperti github.com/username/nama-proyek. Untuk sekarang, cukup tahu bahwa setiap proyek Go yang serius dimulai dengan go mod init. Kita akan memakainya terus di sepanjang seri ini.

    Sampai Ketemu di Bagian 2

    Sampai di sini kamu sudah punya Go yang terpasang rapi, paham struktur dasar sebuah program Go, dan tahu bedanya go run dengan go build. Itu fondasi yang cukup kuat untuk melangkah.

    Di bagian berikutnya, “Belajar Golang dari Nol #2: Variabel, Tipe Data, dan Zero Value di Go”, kita mulai menulis kode yang sesungguhnya: menyimpan data, mengenal tipe-tipe bawaan Go, dan memahami konsep zero value yang membuat Go beda dari kebanyakan bahasa lain. Sambil menunggu, coba ubah-ubah program hello world tadi. Ganti teksnya, tambah baris Println lain, lalu build ulang. Membiasakan jari itu bagian dari belajar.

    Seri ini kami tulis dari pengalaman langsung, karena tim Arrazy memakai Go untuk membangun backend produksi milik klien lewat layanan pengembangan sistem aplikasi.