Pengembangan on kenji.blog

Kisah Pengembangan LogicPad

Wed, 30 Jul 2025 23:51:35 +0900

Alat untuk Mereka yang “Tidak Bisa Menulis Kode, tetapi Memiliki Logika”. Mengapa Saya Membuat LogicPad

Halo, saya kenji. Saya adalah pembuat alat low-code “LogicPad”. Kali ini, daripada memperkenalkan produk, saya ingin menulis dari sudut pandang yang sedikit lebih personal tentang kisah di balik layar pengembangannya, “mengapa saya ingin membuat ini?” dan perasaan saya sendiri.

Sejujurnya, ini bukan sekadar pengembangan alat. Masa lalu saya, rasa frustrasi di tempat kerja, keterampilan saya, dan keinginan yang selalu membara, “suatu hari nanti saya ingin membuat produk saya sendiri” ―― Hasil dari persilangan semua hal itulah yang melahirkan LogicPad.

Dengan kata lain, ini juga merupakan “proyek puncak kehidupan” bagi saya. Saya akan menulis tentang latar belakang ini dengan sejujur dan seantusias mungkin.

Sejujurnya, Saya Menginginkan Produk yang Bisa Saya Banggakan dan Katakan, “Saya yang Membuat Ini”

Sejujurnya, ini adalah motif pertama saya.

Sejak lama, saya suka menulis kode baik untuk pekerjaan maupun hobi. Saya telah terlibat dalam berbagai pengembangan. Tapi suatu hari, saya tiba-tiba menyadari. “Saya tidak memiliki produk yang saya rilis ke dunia atas nama saya sendiri dan di bawah tanggung jawab saya sendiri.”

Tentu saja, hal-hal yang kami buat sebagai tim memiliki nilai, dan ada banyak pekerjaan yang saya banggakan. Tapi di suatu tempat, ada juga perasaan hampa: “Apakah saya akan mengakhiri karier saya seperti ini, di bawah nama orang lain?”

Sekali saja. Saya ingin meninggalkan sesuatu yang bisa saya banggakan dan katakan, “Saya yang membuat ini”. Dengan pemikiran itu, saya mulai merumuskan konsep LogicPad. Itu sekitar 6 tahun yang lalu (sekitar tahun 2019). (Ide awalnya sendiri adalah sekitar tahun 2015 ketika saya mengetahui tentang Blueprints, bahasa pemrograman visual di Unreal Engine.)

Anda Tidak Bisa Ikut Campur Karena Tidak Bisa Menulis Kode. Bukankah Itu Sayang Sekali?

Ada banyak orang berbakat di tempat kerja saya.

Mereka bisa membangun logika. Mereka menggunakan fungsi Excel dengan bebas, dan mereka bisa melihat inti dari sebuah masalah. Tapi ―― tangan mereka berhenti pada tahap “menulis kode”.

“Saya melakukan pekerjaan ini dengan melihat manual setiap kali, tidak bisakah kita mengotomatiskannya?” “Ya, bisa. Tapi… Anda harus menulis kode untuk melakukannya…”

Percakapan seperti itu terjadi berkali-kali.

Saya berpikir setiap kali. “Meskipun mereka memahami logikanya, sungguh disayangkan mereka terhenti oleh dinding kode.”

Pilihan Editor Low-Code

Sebenarnya, di pekerjaan saya sebelumnya, saya sedang mengembangkan perangkat lunak CAD 2D yang dioperasikan melalui GUI. Di CAD, Anda merakit bentuk menggunakan mouse, bukan? Dengan kata lain, ini adalah dunia “membangun logika melalui operasi” .

Saya pikir, “Ini sangat cocok dengan low-code.”

Melihat lebih jauh ke belakang, sejak saya masih mahasiswa, saya selalu melakukan pemrosesan gambar, pemrosesan numerik, alat Windows, alat posting otomatis SNS, dll. Setiap kali saya mendapat ide, saya akan langsung menulis kode dan memproduksi massal program kecil. Saya rasa ada lebih dari 600 buah. Semuanya masih ada di GitHub hingga hari ini.

Saat itu, saya tidak memikirkan maknanya. Itu hanya “Saya membuatnya karena saya ingin”. Itu saja.

Tapi sekarang, saat membuat LogicPad…

Saya benar-benar merasa titik-titiknya telah terhubung menjadi sebuah garis.

Mudah Digunakan, tapi Kuat. Kesulitan Menjaga Keseimbangan

Saat saya melanjutkan pengembangan, hal yang selalu saya pikirkan adalah “menjadikannya alat yang intuitif untuk digunakan dan juga benar-benar kuat” .

Jika Anda menambahkan fitur, Anda menambah apa yang bisa dilakukan. Tapi itu akan menjadi sulit digunakan. Jika Anda membuatnya sederhana, siapa pun bisa menyentuhnya. Tapi kemudian, akan ada orang-orang yang merasa kurang puas.

Agar orang tidak berkata, “Alat low-code itu cuma mainan, kan?” Tapi juga agar mereka tidak berkata, “Pada akhirnya, Anda tetap harus menulis kode, kan?”

Saya selalu berjuang di garis tipis antara intuisi dan ekspresi tersebut.

Saya membangun ulang UI berkali-kali, membuangnya berkali-kali, dan ketika saya akhirnya mendekati bentuk yang membuat saya berpikir, “Ini bisa berhasil,” saya benar-benar bahagia.

Saya Terselamatkan oleh Kata-Kata Pertama dari “Pengguna”

Orang pertama yang saya beri LogicPad adalah mantan rekan kerja. Dia tidak pandai IT, dan takut pada kode. Tapi dia ahli dalam logika.

Saya menjelaskan sedikit dan membiarkannya mencoba… Kata-kata yang dia ucapkan beberapa menit kemudian, saya tidak bisa melupakannya sampai sekarang.

“Kalau begini, sepertinya saya juga bisa melakukannya!”

Saya hampir menangis. Itulah yang ingin saya berikan padanya.

Bukan sekadar alat yang berfungsi, melainkan perasaan “Saya bisa membuatnya sendiri!” . Saya yakin bahwa itulah nilai sebenarnya dari LogicPad.

Jika Lebih Banyak Orang Bisa Membuat, Masyarakat Akan Menjadi Lebih Menarik

Saya benar-benar berpikir bahwa “demokratisasi teknologi” sangatlah penting.

Teknologi memiliki kekuatan untuk mengubah dunia. Namun orang-orang yang bisa menanganinya terbatas.

Bagaimana jika Anda bisa membuat aplikasi hanya dengan “memahami logika”?

Lebih banyak orang akan bisa beralih ke sisi “pembuat”. And saya percaya bahwa apa yang akan lahir dari sana akan melampaui imajinasi kita saat ini.

Jika LogicPad bisa menjadi pintu masuk itu. Saya ingin ini menjadi alat yang mengubah “Saya ingin membuat” menjadi “Saya bisa membuat”.

Itulah harapan saya.

Penutup

LogicPad masih dalam versi beta dan belum selesai. Masih ada segunung hal yang perlu diperbaiki dan hal yang ingin saya lakukan.

Namun, saya telah menuangkan seluruh “titik-titik” kehidupan saya ke dalam alat ini . Sekarang saya bisa mengatakannya dengan bangga.

“Ini adalah produk yang saya buat” .

👇 Bonus: Apa yang Bisa Anda Lakukan dengan LogicPad

Membangun proses dengan drag & drop
Menangani percabangan kondisional dan variabel melalui GUI
Menyediakan berbagai node integrasi AI
Ekstensibilitas untuk pengguna tingkat lanjut dengan memasukkan skrip
Fungsi matematika dan pemrosesan data presisi tinggi (seperti perhitungan numerik dengan presisi tak terbatas)
Pintasan keyboard yang ekstensif untuk pengguna tingkat lanjut
Mendukung lebih dari 90 bahasa

Apa yang Ingin Saya Lakukan ke Depannya

Integrasi AI untuk menghasilkan logika dari bahasa alami
Mekanisme yang memungkinkan pengguna membuat node kustom
Membangun platform di mana node dan logika yang dibuat dapat dibagikan

✍️ Catatan Akhir

Terima kasih banyak telah membaca sejauh ini. Ini bukan sekadar pengembangan alat, melainkan sebuah tantangan di mana saya mencurahkan pengalaman, hasrat, dan bagian dari hidup saya.

“Tidak bisa menulis kode, tetapi memiliki logika” Masa depan di mana orang-orang seperti itu bisa “membuat” dengan kekuatan mereka sendiri. Saya ingin terus mengupayakan hal tersebut melalui LogicPad.

Jika hal ini membuat Anda sedikit saja berpikir, “Saya ingin menggunakannya,” saya akan sangat senang. Jika Anda tertarik, silakan coba LogicPad.

Dan jika Anda memiliki pemikiran atau hal yang Anda sadari setelah menggunakannya, tidak peduli sekecil apa pun itu. Suara Anda akan menjadi kekuatan pendorong yang besar untuk langkah selanjutnya dari produk ini.

Terima kasih atas dukungan Anda yang berkelanjutan.

Tembok Pengembangan AI

Sun, 20 Jul 2025 21:52:42 +0900

Tembok Pengembangan AI

〜 Sampai di pos 8, tapi setelah itu seperti neraka 〜

Halo, saya kenji.

Belakangan ini, saya sering sekali mendengar, “Saya minta AI, dan aplikasi pun jadi!” Kita telah melewati era no-code dan low-code, dan memasuki fase “vibe-coding” (menulis kode berdasarkan suasana hati).

Misalnya, jika Anda berkata, “Buatkan aplikasi yang bisa mengedit gambar dan mempostingnya ke media sosial,” AI akan mengeluarkan kode dan bahkan antarmuka pengguna (UI). Anda mungkin berpikir, “Wow, kita tidak butuh manusia lagi, kan?”

Tapi tahukah Anda, itu seperti turun di pos 8 Gunung Fuji dengan memakai sandal.

Sampai pos 8 terlihat “sangat mudah”

Pengembangan dengan AI pada awalnya memang sangat mudah. File I/O? Untuk saat ini berfungsi. Jaringan? Yah, terhubung. Database? JSON saja cukup. UI? ChatGPT sudah memberikan kode React. Pembayaran? API Stripe cukup copy-paste.

Di sini, Anda mulai berkhayal, “Apakah saya sudah menjadi seorang engineer?” Namun, neraka yang sesungguhnya baru saja dimulai.

Mengapa kita terjebak?

Alasannya sederhana, “AI membuat sesuatu yang tampak jadi, tetapi penyesuaian akhir sepenuhnya diserahkan kepada manusia.”

Data hilang saat file I/O
Normalisasi DB yang buruk membuat pencarian menjadi lambat
UI tidak intuitif
Tidak ada pengujian beban, sehingga crash saat ada lonjakan akses
Ditolak saat review oleh Apple/Google
Menimbulkan masalah hukum (dan hampir viral)

Dengan kata lain, AI ahli dalam membuat “prototipe yang terlihat seperti sudah selesai”, tetapi mengubahnya menjadi “produk yang siap dirilis ke dunia nyata” masih merupakan pekerjaan manusia.

Tapi, ada sebuah paradoks

Di sini kita menyadari sebuah paradoks.

Bagaimana jika di masa depan AI benar-benar bisa melakukan segalanya? Artinya, bagaimana jika “keamanan, penagihan, dan desain semuanya ditangani dengan sempurna oleh AI”?

Pada saat itu, kebutuhan manusia untuk membuat aplikasi mungkin akan hilang sepenuhnya.

Sebab, jika pengguna langsung memberi tahu AI, “Saya ingin melakukan ini,” tugas tersebut akan langsung dieksekusi tanpa memerlukan aplikasi.

🌀 Sebagai contoh

Dulu kita “membuka aplikasi kalkulator untuk berhitung”, sekarang kita hanya perlu berkata, “Hey Siri, berapa 12×32?”, dan selesai.

Sama halnya, jika kita berkata, “AI, edit foto ini dan bagikan,” proses tersebut mungkin selesai tanpa melalui UI atau API aplikasi.

Dengan kata lain, ketika tujuan “membuat aplikasi dengan AI” terwujud, mungkin akan datang dunia di mana aplikasi itu sendiri tidak lagi dibutuhkan.

Pada akhirnya, apa yang bisa kita lakukan sekarang

Lalu, apa yang harus kita lakukan?

Saat ini “di atas pos 8” masih menjadi ranah manusia, jadi mari kita asah kemampuan di sana
Fokus pada pemahaman mendalam tentang pengguna dan desain layanan
Memikirkan “apa yang bernilai” daripada “apa yang bisa dibuat”
Sebaliknya, mencari cara untuk memberikan nilai yang “tidak terbatas pada format aplikasi”

AI adalah alat, lift, dan kadang-kadang pesaing. Namun, pertanyaan “apa yang akan dibuat” dan “mengapa membuatnya” masih merupakan pertanyaan untuk kita, manusia.

Kesimpulan:

Tembok pengembangan AI bukanlah teknologi, melainkan paradoks struktural

Kita berada di era di mana siapa pun bisa mencapai pos 8 Gunung Fuji. Tapi dari situlah ujian sebenarnya dimulai.

Dan mungkin, saat kita mencapai puncak, akan ada masa depan yang menunggu di mana kita bertanya, “Apakah kita benar-benar perlu mendaki gunung ini?”

Market-in dan Product-out

Tue, 15 Jul 2025 20:18:22 +0900

Market-in dan Product-out

Halo, ini kenji.

Terkadang di buku bisnis atau proposal proyek, saya melihat hal-hal seperti:

“Kami menggunakan strategi market-in.” “Ini adalah tipe product-out.”

Mereka mengatakan hal-hal seperti itu tapi…

Tidak, market-in? Product-out? Mana yang lebih hebat???

Tidakkah kamu merasa begitu?

Jadi kali ini, saya akan mencoba mengurai “market-in” dan “product-out” ini sesederhana mungkin, dan melihatnya sedikit secara kritis.

Singkatnya…

Market-in : Mendengarkan suara pasar (market) dan membuat produk sesuai dengan itu.
Product-out : Membuat sesuatu (product) yang kita anggap bagus dan merilisnya ke dunia.

Hanya itu. Sederhana.

Contohnya di kedai ramen…

Kedai ramen bergaya market-in adalah, “Akhir-akhir ini ramen Iekei sedang populer. Oke, mari kita beri banyak lemak dan bawang putih!” seperti itu.

Kedai ramen bergaya product-out adalah, “Ramen garam basil susu kedelai yang saya buat ini benar-benar yang terbaik, jadi makanlah,” seperti itu.

Mana yang benar… Keduanya benar

Market-in mendekati kebutuhan pelanggan, jadi “probabilitas terjualnya tinggi”, tetapi ide terobosan atau inovasi sulit lahir.

Product-out adalah “mewujudkan keadilan yang kita yakini,” jadi itu tajam dan menarik, tetapi jika meleset, itu tidak akan beresonansi dengan siapa pun.

iPhone sepertinya product-out

Di era ketika orang berkata “kita tidak butuh smartphone”, Apple merilis iPhone.

Ini sudah sepenuhnya contoh sukses product-out .

Jika mereka mendengarkan pengguna, mereka akan diberitahu, “Ponsel tanpa keyboard? Tidak mungkin,” dan itu akan berakhir.

Tapi product-out mudah menjadi “kepuasan diri”

Kadang-kadang ada perusahaan atau orang yang berkata, “Kami bertipe product-out,” tetapi

Tidak, bukankah itu hanya mengabaikan pengguna?

Saya kadang berpikir begitu.

“Membuatnya karena ingin membuatnya. Tapi tidak terjual” itu, bukan product-out tetapi “egois-out”, bukan?

Market-in juga punya jebakan

Di sisi lain, market-in juga tidak sempurna.

Jika Anda berkata “Kami akan melakukan semua yang diinginkan pengguna!”, inti dari produk akan goyah, dan pada akhirnya mungkin tidak menarik bagi siapa pun.

Anda terus menambahkan fitur, dan tiba-tiba Anda menyadari itu adalah alat yang kacau, seperti itu.

Yang benar-benar luar biasa adalah “mereka yang melakukan keduanya”

Produk yang luar biasa adalah produk yang dengan jelas menyajikan, “apa yang benar-benar diinginkan pengguna, tetapi tidak dapat diungkapkan dengan kata-kata”.

Dengan kata lain, “mendapatkan simpati bergaya market-in, dengan menggunakan ide product-out”.

Ini mudah dikatakan tetapi sangat sulit dilakukan. Namun, jika Anda bisa melakukannya, itu akan langsung menjadi “produk dewa”.

Kesimpulan: Reaksi pengguna adalah segalanya, bukan kata-kata

Market-in atau product-out. Mana yang benar adalah pertanyaan yang tidak terlalu berarti.

“Apakah itu benar-benar mencapai hati pengguna?” adalah segalanya , menurut saya.

“Kami menggunakan strategi seperti ini,” saya pikir sudah cukup jika kita bisa menuliskannya di materi pemasaran nanti.

Jadi, itu adalah cerita tentang market-in dan product-out!

Tanpa terpengaruh oleh kata-kata asing yang aneh, berpikir “pada akhirnya, bagaimana saya bisa membuat orang senang?” adalah yang paling masuk akal, menurut saya.

Sampai jumpa~.

Kelebihan dan Kekurangan Membuat Program dengan Win32API + C++

Sat, 12 Jul 2025 12:30:35 +0900

Daya Tarik dan Tantangan Pengembangan dengan Win32API + C++

Bagi mereka yang ingin mendalami pengembangan aplikasi Windows, Win32API + C++ masih menjadi pilihan yang kuat. Kombinasi ini, yang memungkinkan Anda berinteraksi dengan OS pada jarak terdekat, menggabungkan kecepatan tinggi dan fleksibilitas.

Di sisi lain, karena sangat berbeda dari gaya pengembangan modern, menguasainya juga membutuhkan tekad.

Di halaman ini, dari sudut pandang pengembang aplikasi Windows yang aktif , kami akan menjelaskan kelebihan dan kekurangannya dengan cara yang mudah dipahami.

Kelebihan

Eksekusi Asli yang Sangat Cepat

Karena C++ dan Win32API beroperasi pada lapisan yang paling dekat dengan OS, hampir tidak ada overhead tambahan. Efisiensi penggunaan CPU dan memori sangat tinggi, dan membanggakan kecepatan eksekusi yang luar biasa .

Fleksibilitas dan Kebebasan Tinggi

Anda dapat mengontrol sendiri secara detail setiap perilaku aplikasi, seperti kontrol jendela, pemrosesan asinkron, integrasi COM, dan manajemen proses. Dimungkinkan juga untuk membangun alat yang disesuaikan untuk tujuan tertentu, atau kerangka kerja khusus Anda sendiri.

Mudah Didistribusikan Tanpa Perlu Runtime

Karena tidak diperlukan runtime eksternal seperti .NET atau Java, aplikasi dapat didistribusikan hanya dengan satu file yang dapat dieksekusi . Masalah saat redistribusi jarang terjadi, dan daya tariknya adalah mudah dijalankan bahkan tanpa penginstal.

Aplikasi Ringan Dapat Dibuat

Karena hanya membutuhkan konfigurasi minimum, fiturnya adalah jejak memorinya sangat kecil . Ini beroperasi dengan nyaman bahkan pada PC dengan spesifikasi rendah dan lingkungan mesin virtual.

Kontrol Lanjutan Tingkat OS Dimungkinkan

Kontrol yang sulit dengan bahasa dan pustaka biasa juga dapat diwujudkan, seperti hook global mouse dan keyboard, penyesuaian gaya jendela secara detail, dan operasi menu sistem.

Kekurangan

Efisiensi Pengembangan Rendah

Pembuatan GUI juga harus dilakukan sepenuhnya dengan kode, dan membuat satu tombol bisa membutuhkan puluhan baris kode . Modifikasi saat mengubah desain juga rumit, dan produktivitasnya rendah dibandingkan dengan pengembangan menggunakan kerangka kerja UI.

Pemeliharaan Cenderung Menurun

Ini berisi banyak kode dengan struktur khusus , seperti perulangan pesan dan prosedur jendela, yang membuatnya sulit dibaca dan digunakan kembali. Ada juga aspek yang membuatnya tidak cocok untuk pengembangan tim atau pemeliharaan jangka panjang.

Beradaptasi dengan UI Modern Merepotkan

Sulit untuk beradaptasi dengan UX yang dituntut dalam beberapa tahun terakhir , seperti dukungan DPI tinggi, antarmuka sentuh, aksesibilitas, dan mode gelap. Masing-masing harus ditangani secara manual, yang membutuhkan banyak usaha.

Tidak Mendukung Lintas Platform

Karena ini sepenuhnya merupakan API khusus Windows, aplikasi tidak dapat di-porting ke macOS atau Linux . Jika Anda mengharapkan penerapan lintas platform, Anda harus memilih teknologi lain.

Biaya Pembelajaran Sangat Tinggi

Anda harus memahami konsep dan mekanisme yang jarang digunakan saat ini , seperti handle, GDI, COM, dan OLE. Banyak dokumen juga sudah usang, dan pembelajaran membutuhkan waktu dan kesabaran.

Penggunaan yang Cocok

Alat ringan seperti peluncur file dan bantuan hotkey
Utilitas sistem seperti manipulasi clipboard dan kontrol IME
Aplikasi kontrol asli seperti hook global dan penangkapan jendela
Alat bantu driver yang terkait erat dengan perangkat keras

Penggunaan yang Tidak Cocok

Aplikasi untuk konsumen umum di mana UI / UX modern ditekankan
Pembuatan prototipe dan pengembangan MVP di mana kecepatan diprioritaskan
Proyek skala besar yang berpusat pada operasi jangka panjang dan pengembangan tim
Produk lintas platform yang perlu mendukung banyak OS

Ringkasan Evaluasi

Kriteria	Evaluasi
Kecepatan Eksekusi	◎ Sangat cepat
Efisiensi Memori	◎ Sangat baik
Kecepatan Pengembangan	× Lambat
Pemeliharaan	× Rendah
Dukungan Lintas Platform	× Tidak didukung
Dukungan UI Modern	× Lemah
Kebebasan Kontrol OS	◎ Sangat tinggi

Kesimpulan

Win32API + C++ adalah alat yang cocok untuk pengembang yang “ingin menangani semuanya di OS sendiri”. Meskipun kekuatannya sangat besar, pembelajaran dan pengoperasian membutuhkan tekad yang sesuai.

Apakah “pilihan yang disengaja” ini sepadan tergantung pada sifat aplikasi yang Anda tuju.

Melompat ke dunia #include <windows.h> tanpa mengandalkan kerangka kerja GUI atau bahasa modern ―― Pilihan itu masih memiliki arti yang sama seperti sebelumnya.