Development Notes on Nafies Luthfi

Minder: Aplikasi Mindmap untuk GNU/Linux

Wed, 30 Mar 2022 23:06:00 +0800

Bismillahirrahmaanirrahiim.

Minder: Aplikasi Mindmap untuk GNU/Linux:
https://github.com/phase1geo/Minder (free software)

Cocok untuk orang yang suka bikin konsep, bikin kerangka konten, bikin resume buku/tutorial, atau jadi bahan meeting. Saya sendiri pakai ini untuk bikin konsep fitur sistem, biar tidak lupa bagian-bagian yang harus dibuat (contoh screenshot).

Aplikasi alternatif terdahulu:

Freemind (sudah tidak bisa diisntall di ubuntu versi 18.04 ke atas).
Freeplan.
VYM (View Your Mind).

Selamat mencoba. Terima kasih.

Notifikasi Suara Saat Perintah Terminal Selesai

Wed, 09 Feb 2022 17:00:00 +0800

Bismillahirrahmaanirrahiim.

Saya ingin share sedikit, pernahkah teman-teman menunggu atau bolak-balik cek terminal untuk melihat apakah proses sudah selesai atau belum? Ternyata kita bisa meminta agar terminal “bersuara” saat proses selesai.

Contoh perintah:

ls; spd-say done

Jadi ketika perintah ls selesai dieksekusi, PC/laptop kita akan bersuara done.

Referensi:

Kenapa untuk saya ini sangat bermanfaat? Karena kadang ada pekerjaan proses import data, migrasi data, atau backup/restore database, biasanya menggunakan terminal dan setiap proses butuh waktu beberapa menit.

Daripada bolak-balik melihat ke terminal (untuk cek sudah selesai atau belum), dengan metode ini terminal akan memberi notifikasi jika prosesnya sudah selesai.

Demikian teman-teman selamat mencoba, mudah-mudahan bermanfaat. Terima kasih atas waktunya.

Cara Deploy VPS Always Free Oracle Cloud

Sun, 26 Dec 2021 23:30:00 +0800

Bismillahirrahmanirrahim.

Pada tulisan ini, kita akan membahas cara deploy satu VM (Virtual Machine) instance atau VPS yang always free pada Oracle Cloud. Berikut adalah spesifikasinya:

Server Shape: VM.Standard.E2.1.Micro
Network Bandwidth (Gbps): 0.48
CPU Count: 1
Memory: 1 GB
Local Disk: Block Storage Only (47GB)
Operating System: Ubuntu Server 20.04

Pastikan kita sudah memiliki akun Oracle Cloud aktif. Cek cara pendaftarannya di artikel ini: Cara Mendaftar Akun Oracle Cloud.

Buka halaman melalui browser: https://cloud.oracle.com
Isikan Cloud account name: nama_akun_anda -> Klik Next
Pada Identity Providers: pilih oracleidentitycloudservice -> Klik Continue
Isikan username: ***@mail.com (alamat email yang dipakai untuk mendaftar)
Isikan password: ***
Klik Sign In
Jika berhasil, kita akan redirect ke dashboard Oracle Cloud https://cloud.oracle.com/?region=xxxxx

Deploy VM Instance

Pada dashboard akun Oracle Cloud, scroll ke Launch Resources. Pada bagian Compute klik Create VM Instance (perhatikan bahwa label Always Free Eligible masih ada).
Pada formulir Create compute instance, silakan ubah name jika diperlukan.
Pada halaman ini, kita perlu mengubah bagian Image dari Oracle Linux menjadi Ubuntu Server. Klik Edit untuk mengubahnya.
Klik Change Image.
Cetang Canonical Ubuntu (Always Free Eligible), Pilih versi OS 20.04.
Click Select image.
Sekarang image sudah berubah menjadi Canonical Ubuntu 20.04.
Pada bagian Add SSH Keys kita bebas pilih opsinya, tapi saran saya gunakan yang di-generate oleh Oracle Cloud. Jadi pilih Generate a key pair for me.
Download SSH key: Klik Save Private Key dan Klik Save Public Key. Simpan di local disk PC kita. Untuk kasus saya, karena menggunakan Linux Mint, saya simpan di folder ~/.ssh/.
Setelah itu, klik tombol Create, maka pembuatan VM Instance akan diproses.

Pastikan VM baru kita ada label Always Free.
Ketika proses sudah selesai, akan tampil informasi status VM instance kita sedang RUNNING.
Sekarang kita bisa coba login ke VM dengan username ubuntu dan Public IP Address yang tampil di layar.

Akses SSH

Sebelum login ke VM instance melalui SSH, kita perlu modifikasi dulu file private key yang di-download tadi, yaitu mengubah file permissions menjadi 600.

Di sini saya menggunakan Linux Mint, maka dilakukan dengan perintah berikut:

$ chmod 600 ~/.ssh/ssh-key-2021-09-05.key

Kemudian akses SSH ke VM dengan perintah berikut:

$ ssh ubuntu@public-ip-address -i ~/.ssh/ssh-key-2021-09-05.key

Seharusnya akses SSH ke VM Oracle Cloud berhasil.

Disk Drive dan Memory (RAM)

Sekarang kita bisa cek kapasitas harddisk dan memory yang tersedia pada VM Instance Oracle Cloud yang baru.

$ free -m
$ df -h

Akan tampil informasi bahwa:

Total Memory: sekitar 1 GB
Disk size: 45 GB

Penutup

Baik teman-teman, seperti itu proses deploy satu VM instance atau VPS always free pada Oracle Cloud. Selamat mencoba dan terima kasih atas waktunya.

Melaporkan Problem Pendaftaran ke Customer Service Oracle Cloud

Sat, 30 Oct 2021 10:00:00 +0800

Bismillahirrahmanirrahim.

Di artikel Cara Mendaftar Akun Oracle Cloud, saya informasikan proses pendaftaran akun Oracle Cloud tidak langsung berhasil karena beberapa kali gagal saat input informasi kartu kredit.

Problem

Pada langkah ke 14, saya mendapat error proses transaksi seperti ini:

Kegagalan input kartu kredit ini tetap mengenakan charge sebesar SGD 1.38 sebanyak 3 kali karena saya mencobanya 3 kali juga.

Langkah yang dilakukan (mengirim email)

Jika teman-teman dapat problem yang sama, maka dapat melaporkan ke customer service oracle cloud dengan cara mengirim email seperti ini

To: oraclehelp_ww@oracle.com

Subject: My Card is being rejected for Free Trial Signup

Konten:

Hello Oracle Cloud,

I want to register for Oracle Cloud Free Tier, but it rejects
my credit card and says:

"We're unable to complete your sign up. Common sign up errors are due to:
(a) Using prepaid cards. Oracle only accepts credit card and debit cards
(b) Intentionally or unintentionally masking one's location or identity
(c) Entering incomplete or inaccurate account details."

I try to enter my credit card detail 3 times and get charged 3 times
(for verification), but the sign-up is kept failing.

I am using this email address xxxxxx@gmail.com and using MasterCard
for the credit card.

Could you please help me with this?

Thanks.

Kemudian sekitar 2 hari dapat balasan dari oracle cloud, bahwa mereka sudah melakukan penyesuaian dan mempersilakan untuk mendaftar dengan alamat email yang sama dalam 5 hari ke depan.

Setelah itu, proses registrasi saya ulang sekali lagi dan berhasil (sampai langkah ke 15 pada artikel sebelumnya).

Semoga bermanfaat, terima kasih atas waktunya.

Cara Mendaftar Akun Oracle Cloud

Sat, 30 Oct 2021 09:00:00 +0800

Bismillahirrahmanirrahim.

Di beberapa artikel sebelumnya, saya share tentang cara pendaftaran akun di Google Cloud Platform dan Microsoft Azure untuk dapat layanan VPS gratis. Kali ini kita bahas pendaftaran Oracle Cloud yang menawarkan layanan VPS gratis juga.

Sebagai informasi, Oracle Cloud menyediakan 2 VPS always free (AMD Compute VMs). Ini yang menarik, karena layanan lain tidak ada yang menawarkan VPS always free.

Sumber free trial info:

Proses Pendaftaran Akun Oracle Cloud

Kunjungi https://www.oracle.com/id/cloud/free
Klik “Start for Free”
Isi formulir dan klik “Verify my email”
Akan ada email masuk untuk verifikasi, lalu tekan tombol “Click here” pada email
Kita akan masuk ke form yang tadi tapi ada tambahan detail.
Pilih region terdekat dengan kita, saya pilih Japan East (Tokyo) karena latency nya paling kecil (https://cloudpingtest.com/oracle)
Klik “Continue”
Isi data alamat dan telp (isi yang wajib saja)
Klik “Continue”
Pada bagian payment verification klik “Add Payment Verification Method”.
Klik “Credit Card”. Di sini kita akan masukkan data kartu kredit
Pada Billing Information, isi data yang wajib-wajib saja.
Pada Payment Detail, isi data kartu kredit, lalu klik Finish.
Centang agreement dan klik “Start my free trial”

Catatan:
Pada langkah ini, ada kemungkinan gagal dengan pesan: We're unable to complete your sign up...
Jika mengalami problem ini, silakan baca: Melaporkan Problem Pendaftaran ke Customer Service Oracle Cloud.
Proses setup dilanjutkan hingga muncul tampilan Oracle Cloud Dashboard.

Bisa teman-teman perhatikan ada informasi di bagian atas dashboard:

You are in a free trial. When your trial is over, your account will be limited to Always Free resources. Upgrade at any time.

Baik, sampai Di sini proses pendaftaran Akun Oracle Cloud sudah selesai dan siap digunakan.

Problem yang saya alami

Sebagai informasi tambahan, proses pendaftaran ini tidak langsung berhasil. Saat submit kartu kredit ditolak, silakan baca: Melaporkan Problem Pendaftaran ke Customer Service Oracle Cloud.

Semoga bermanfaat, terima kasih atas waktunya.

Format Laporan Progress yang Disukai oleh Senior Dev/Project Manager

Mon, 20 Sep 2021 22:00:00 +0800

Bismillahirrahmanirrahim.

Pada artikel ini, Saya pingin share satu contoh laporan progress yang disukai oleh senior, atau lead, atau project manager ketika kita di-assign task/ditugasi mengerjakan sesuatu.

Disclaimer: Ini hanya preferensi saya, menurut pengalaman kerja untuk klien maupun kerja bareng sesama developer selama beberapa tahun terakhir.

Contoh Task dan Laporan Harian

Di contoh ini, saya pakai github issue sebagai task management. Deskripsi issue dipakai untuk menulis feature requirements, dan komentar-komentar issue dipakai untuk lapor progress harian.

Berikut beberapa screenshot dari salah satu task:

Issue dibuat oleh Senior Developer atau Project Manager.
Pada deskripsi issue ada:
- Goal (biar satu visi ini tasknya mau ngapain)
- Notes (catatan penting yang harus diperhatikan)
- Definition of Done (Task ini dianggap selesai kalau item-item ini terpenuhi)
Ketika ambil task ini, kita assign nama kita, biar mudah difilter per username/assignee
Ketika selesai mempelajari/mepahami requirement dari task ini, tuliskan “Apa yang saya pahami dari task ini”.
Tuliskan juga rencana kerja berdasarkan yang kita pahami di atas.
(optional) Kita buat perkiraan berapa lama waktu pengerjaan (bisa dalam jam atau hari).
Minta review dari orang yang membuat task, kira2 point 4, 5, 6 itu sudah OK atau belum. Kalau sudah sip, dia kasih jempol, kalau belum sip, dia kasih komentar/revisi.
Ketika sudah mulai progress, buat laporan harian. Komposisinya ada 2:
- Current progress: Apa saja yang sudah dikerjakan
- Next TODO: Progress selanjutnya kita mau ngapain
Ketika progress sudah selesai, kita beri komentar “dengan jelas” bahwa tugas sudah selesai, dan issue di-close.

Kenapa Harus Begitu?

Nah manfaatnya apa kita lapor seperti ini? Tujuannya adalah:

Menghemat waktu Senior Dev/Project Manager saat monitoring tugas-tugas yang sudah diassign. Cukup baca laporan progress terakhir, sudah tahu task ini sudah sampai mana.
Senior Dev/Project Manager tidak perlu bertanya: “progressnya sudah sampai mana?” karena sudah jelas dari point 8.
Menjadi dokumentasi dan referensi jika ada pekerjaan serupa.
Mudah onboarding developer yang baru join masuk tim.
Melatih disiplin developer karena terbiasa lapor progress secara rutin (lapor harian).
Melatih developer membuat estimasi (point 6). Suatu saat jadi Senior Dev atau Project Manager, jadi lebih mudah.
Senior Dev/Project Manager pasti senang dengan developer yang seperti ini.

Ini tidak hanya bisa diterapkan di github issue ya, bisa di Jira, Trello, Clickup, bitbucket issue. Kalau di tempat kerjanya belum ada format laporan progress harian, bisa coba diusulkan yang seperti ini.

Nah kebayang ‘kan kalau si Project Manager/Senior Dev suka dengan cara kerja kita? Kalau dia pindah kerja ke tempat lain yang lebih baik, mesti kita diboyong/diajak/direkomendasikan.

Semoga bermanfaat temen-temen. Selamat mencoba dan terima kasih.

Tips Pull Request Github untuk Memudahkan Reviwer

Sun, 29 Aug 2021 22:00:00 +0800

Bismillahirrahmanirrahim.

Pada artikel ini saya ingin sharing tentang tips pull request github yang disukai oleh reviewer.

Disclaimer: Ini hanya preferensi saya, menurut pengalaman kerja untuk klien maupun kerja bareng sesama developer selama beberapa tahun terakhir.

Saya pingin share tips cara memikat klien dengan menunjukkan cara kita bekerja. Cara ini cukup efektif jika klien kita adalah senior programmer/developer. Yaitu cara membuat deskripsi Pull Request yang mempermudah reviewer (orang yang me-review kerjaan kita).

Ini salah satu Pull Request yang saya bisa contohkan:

https://github.com/nafiesl/dompet/pull/64

Pada deskripsi pull request itu ada:

Description (rangkuman di Pull request ini kita mengerjakan apa)
Checklist (apa saja yang kita lakukan di Pull Request ini)
How to test on localhost (ini menghemat waktu reviewer buat me-review kerjaan kita)
Screenshot atau lebih bagus lagi kalau kita buatkan rekaman video (ini mempermudah reviewer juga).

Tujuannya adalah:

Menghemat waktu reviewer/senior developer untuk tahu di Pull Request ini kita ngapain (problemnya apa, solusinya apa)
Mereka bisa cepat menangkap: mana yang sudah dan mana yang belum dikerjakan.
Menghemat waktu mereka untuk cari tahu gimana cara me-review kerjaan kita (pasti mereka banyak kerjaan lain).

Saya yakin sih, reviewer pada seneng dengan pekerjaan yang seperti itu. Dengan model Pull Request seperti itu, saya dapat feedback yang bagus dari klien.

Cara kerja seperti ini pasti bisa diterapkan untuk developer yang kerja di kantor juga (tidak hanya kerja freelance). Tujuannya sama, menghemat waktu senior yang me-review kerjaan kita. Secara tidak langsung, ini jadi kontribusi positif bagi perusahaan. Proses review sebuah tugas bisa lebih efisien.

Jadi kalau di tempat kerjanya belum ada template Pull Request, bisa coba diusulkan. Mudah2an bermanfaat untuk temen-temen. Selamat mencoba.

Semoga bermanfaat, terima kasih.

Cara Bertanya dan Menjawab di Forum Komunitas

Sat, 31 Jul 2021 09:00:00 +0800

Bismillahirrahmanirrahim.

Kali ini saya ingin sharing tentang komunikasi di forum komunitas.

Disclaimer: Ini hanya preferensi saya, menurut pengalaman berkomunitas selama beberapa tahun terakhir. Bukan jadi aturan komunitas tertentu.

Kenapa dibahas?

Banyak yang japri ke saya, diarahkan ke grup, ternyata sudah tanya, tapi tidak ditanggapi. Ternyata karena pertanyaannya tidak lengkap, jadi orang malas merespons.
Cara bertanya menunjukkan seberapa baik kemampuan kita mengkomunikasikan problem.
Cara menjawab menunjukkan seberapa baik kita diajak kerjasama.

Cara bertanya

Sebelum tanya, coba cari tahu dulu di grup, siapa tahu ada yang sudah pernah tanya kasus yang sama sebelumnya.
Bertanya yang lengkap, usahakan tidak membuat orang lain bertanya balik.
Usahakan menghemat waktu orang yang membantu.
Tunjukkan sudah googling dengan keyword apa.
Hormati semua orang yang menjawab, jika ada jawaban yang kita anggap sepele, hargai dan tetap berterima kasih.
Jika ketemu solusi, usahakan memberi tanda “solved” dan merangkum solusi yang diterapkan.
Jangan lupa terima kasih, mention orang yang membantu sampai solved, ini jadi penghargaan bagi teman-teman yang membantu menjawab.
Jika ketemu solusi, jangan menghapus posting, karena dapat dimanfaatkan oleh member/teman-teman lain yang memiliki kasus serupa.

Cara Menjawab

Jangan takut salah kalau menjawab. Lebih baik tahu salah daripada mengira pikiran kita benar.
Lebih baik tidak menjawab daripada jawaban tidak bermanfaat. Saya pribadi, biasanya menjawab seperti seolah-olah ditanya saat interview kerja. Karena jawaban kita itu dilihat banyak orang, termasuk developer senior, business owner dan para leader.
Jangan takut bilang “saya tidak paham”
Lihat apakah sudah ada yang menjawab dengan jawaban kita? Jika sudah ada, tinggal kasih like atau lengkapi.
Jika ada yang bertanya lanjutan japri, dengan sopan, arahkan agar bertanya ke grup. Tujuan
- Agar member lain bisa ikut belajar
- Agar member lain bisa bantu jawab

Manfaat

Manfaat banyak membantu jawab pertanyaan di komunitas:

Jadi ilmu yang bermanfaat, amal jariyah.
Membuat kita dikenal orang (jawaban kita bisa menentukan reputasi kita di mata teman-teman member komunitas).
Bisa mempromosikan skill. Cara kita menjawab dengan baik dan jawaban yang menjadi solusi bisa jadi sarana promosi untuk skill kita.
Bisa tahu banyak error dan cara menanganinya (ada kemungkinan kita juga kena error serupa di kemudian hari).
Jadi mengerti banyak studi kasus/project yang kita belum pernah tahu sebelumnya.

Tips

Bagi penanya:

Jangan hapus posting pertanyaan jika sudah ketemu solusi, agar diskusi tersebut bisa menjadi manfaat untuk member lain juga.

Bagi penjawab/member komunitas:

Anggap anda di posisi penanya, kira-kira apa yang akan anda lakukan jika ketemu kasus yang sama?
Jika bertemu dengan pertanyaan yang dirasa kurang lengkap, ajari penanya bagaimana cara bertanya yang baik.

Baik teman-teman, itu saja tips cara komunkasi di forum komunitas. Jika ada yang belum dipahami, atau ada tambahan dari teman-teman, silakan tuliskan di kolom komentar. Semoga bermanfaat, terima kasih.

Perangkat Kerja Freelance Web Developer

Wed, 30 Jun 2021 10:00:00 +0800

Bismillahirrahmanirrahim.

Pada artikel ini, saya ingin bagi informasi perangkat-perangkat yang saat ini saya gunakan untuk bekerja sebagai freelance web developer:

Perangkat Keras

Laptop

Lenovo Thinkpad E480-48IA

Ini laptop kerja utama, baterainya awet, rata-rata 6-7 jam.
- Prosesor: Core i5-8250U
- Penyipanan: SSD M2 VGEN 512GB + HDD 1TB 5400RPM
- RAM: 2 x 4GB DDR4 2400
- Display: 14" FHD (1920 x 1080) Intel UHD 620
HP 14R017TX

Ini laptop cadangan, hanya untuk dirumah, baterainya hanya tahan 10 menit. Kadang dipakai main game, karena kartu grafisnya lebih bagus dari laptop utama.
- Prosesor: Core i3 4030U
- Penyipanan: SSD Sandisk 240GB + HDD 500TB 5400RPM
- RAM: 2 x 4GB DDR3L
- Display: 14" HD (1366 x 768) NVIDIA GeForce 820M

Monitor

LG 22" 22MK430H
Samsung 24" C24F390FHE

Meja

Saya pakai 2 Meja Kayu, dibuat di tukang kayu, masing-masing

Panjang: 120cm
Lebar: 60cm
Tinggi: 70cm

Kursi

Council Kursi Kantor Sandaran Tinggi beli di Informa

Audio

Headset Standar bawaan HP Samsung

Headset enak di-kuping, ringkas, suaranya dan mikrofonnya jernih. Tanpa noise cancel jadi dipakai meeting ngga enak.
Logitech Stereo Headset H151 Black

Ini hanya dipakai saat meeting, karena ada noise cancelnya. Kalau dipakai rekam video atau audio, masih bagusan yang headset Samsung.

Perangkat Lunak

Sistem Operasi dan Kelengkapan

Linux Mint 20 Ulyana XFCE

Ini dipakai di laptop Lenovo E480. Saya pakai yang versi XFCE karena ringan dan gesit.
Linux Mint 18.3 Sylvia XFCE

Ini dipakai di laptop HP 14R017TX.

Terminal Emulator

XFCE Terminal

Saya pakai ini karena bawaan XFCE, dan sangat cukup untuk kebutuhan saya. Ada sedikit custom di bashrc untuk menampilkan git branch.

Office Suite

Libre Office Writer 6.4 (bawaan linux Mint 20)

Launcher

Synapse

Ini launcher dengan shortut ctrl+space agar cepat membuka aplikasi.
Plank

Ini launcher berupa dock di desktop. Untuk beberapa aplikasi yang dipakai setiap hari serta aplikasi-aplikasi yang sedang aktif dibuka.

Monitor Internet

Ini alat bantu biar tahu apakah internet sedang lancar atau gangguan.

xfce4-netload-plugin

Ini internet speed indicator yang tampil di desktop panel XFCE, untuk Linux Mint 20 Ulyana.
Indicator Netspeed Unity

Ini internet speed indicator untuk Linux Mint 18.3 Sylvia. Sebenarnya ini lebih enak daripada xfce4-netload-plugin, tapi untuk ubuntu 18.04 ke atas, sudah tidak ada dukunganlagi (tidak bisa diinstall).

Web Development

Browser

Firefox

Ini browser utama, untuk web development dan browsing sehari-hari. Saya pindah dari chromium ke Firefox karena lebih yakin untuk penyimpanan password.
Chromium

Ini browser cadangan kalau butuh simulasi login beberapa user sekaligus untuk uji coba aplikasi web.

Teks Editor

Sublime Text

Saya pakai sublime text karena gesit. Fitur-fitur default plus beberapa package/pluginnya mempermudah saya lebih produktif menulis kode. Saya pernah menggunakan teks editor lain tapi belum ada ketemu uang settng.
Leafpad

Leafpad ini adalah teks editor bawaan lubuntu. Sangat ringan seperti aplika sinotepad pada windows. Saya biasanya pakai ini untuk bikin catatan cepat, seperti saat meeting, atau catatan sementara sebelum dimasukkan ke Joplin.

Web Server

Apache (localhost)

Saya pakai apache web server di localhost agar bisa mengakses project melalui browser sesuai urutan direktori, tanpa harus konfigurasi server block setiap project baru.
Nginx (live server)

Untuk staging dan production server, saya menggunakan nginx, karena konfigurasi server block tiap deploy aplikasi web cenderung mudah.
PHP 7

Karena saya banyak bekerja dengan bahasa program PHP sejak awal freelance, maka di localhost saya install PHP mulai versi 7.0 s/d 7.4. Mengikuti spesifikasi project-project lama. Biasaya di localhost saya pindah-pindah versi PHP apache dengan bantuan php switch script.

Baca juga: Cara Pindah-Pindah Versi PHP pada LAMP stack di Ubuntu.

Database

MariaDB 10

Sebagian besar project aplikasi web yang saya buat, menggunakan database MariaDB versi 10.2 dan 10.3.
Postgres 9.5

Beberapa project aplikasi web diminta oleh kliennya secara spesifik menggunakan postgres. Jadi di localhost saya install juga untuk kebutuhan development.

Produktifitas

Komunikasi

Telegram Desktop

Saya paling banyak aktif di telegram dengan username: @nafiesL.
Slack

Untuk komunikasi pekerjaan, baik bersama partner maupun klien, menggunakan slack. Slack juga saya gunakan untuk lapor error log di beberapa project yang lumayan penting dipantau.
Whatsapp Desktop

Saya pakai whatsapp desktop dari linux mint software center.

Mengelola Proyek

Free-PMO

Aplikasi web opensource yang saya buat untuk mengelola project freelance, item-item pekerjaan, penagihan, dan langganan customer (hosting dan domain).

Mengelola Aktifitas Kerja

Joplin

Ini aplikasi yang saya pakai untuk checklist item yang saya kerjakan setiap hari. Detailnya saya tulis di artikel ini: Produktifitas dengan Joplin.

Mengelola Password

Firefox Lockwise

Ini fitur bawaan firefox untuk simpan kredensial (username/email dan password) login. Aplikasi ini juga ada versi androidnya, jadi bisa dipakai untuk simpan password di handphone juga.

Git Client

GitG

Untuk penggunaan git dengan GUI, saya pilih aplikasi GitG karena ringan. Tapi versi GitG yang saya gunakan adalah versi 0.2.7. Yap, versi jadul, tapi in ringan sekali dan sangat cukup untuk kebutuhan saya di localhost.

Perangkat Online

Internet

Faznet (internet 15Mbps)

Karena tidak ada jalur internet kabel lain, saya pakai Faznet. Tapi lumayan stabil, jarang gangguan dan lumayan murah.
Tri (internet cadangan)

Agar tidak terkedala kalau ada gangguan internet, saya pakai Tri untuk internet cadangan. Di samping paketnya murah, jaringan Tri juga stabil di rumah saya. Jadi sangat cukup untuk kebutuhan backup saja.

Penyedia Server/Hosting

Vultr

Saya pakai vultr mulai tahun 2017 untuk project-project klien. Karena waktu itu paling murah untuk spesifikasi setara di provider lain. Sampai sekarang (tahun 2021) terhitung jarang gangguan sih. Jarang ada komplain dari klien juga. Ada juga klien juga saya buatkan akun vultr.com sendiri jadi tagihan langsung masuk ke kartu kredit beliau.
Digital Ocean

Waktu itu vultr membatasi hanya 5 VPS per akun pelanggannya, jadi mulai 2019, saya pakai digital ocean, karena waktu itu ada klien baru yang perlu VPS. (Tapi sekarang di vultr sudah bisa lebih dari 5 VPS karena bisa diminta tambah via support ticket).
IDCloudHost

Untuk klien-klien yang ingin hemat biaya hosting, saya pakai IDCloudHost.
Rumah Web

Untuk langganan beberapa domain, saya pakai Rumah Web, karena pilihan ekstensi domainnya banyak dan harga domain relatif lebih murah daripada provider domain lain.
Oracle Cloud

Saya pakai Oracle Cloud untuk server sendiri. Hosting blog ini dan kebutuhan trial aplikasi web klien. Oracle cloud ini menyediakan layanan VPS Always Free. Silakan baca-baca tentang Oracle Cloud di halaman Cloud Server.

Code Hosting

Github

Di github kebanyakan saya pasang project open source. Bisa cek di profil saya (https://github.com/nafiesl). Ada beberapa private repo punya klien juga, yang kerjanya kolaborasi dengan developer lain.
Bitbucket

Saya pakai Bitbuket untuk project-project freelance. Mulai sekitar tahun 2016. Karena waktu itu github belum gratis private repo.

Baik, rasanya itu yang bisa saya bagikan ke teman-teman, jika ada hal lain yang kira-kira belum terdaftar, bisa teman-teman sampaikan di komentar. Insya Allah saya tambahkan listnya jika memang ada.

Terima kasih atas waktunya. Semoga bermanfaat.

Solusi Problem: Akses Github jika Port 22 Diblok oleh Internet Provider

Sat, 08 May 2021 21:00:00 +0800

Bismillahirrahmanirrahim.

Buat yang punya problem akses ke port 22 diblok oleh internet provider, mungkin akan dapat kesulitan seperti berikut:

Akses VPS dengan SSH (port 22: Connection timed out)
Pull dan push ke Github (port 22: Connection timed out)
Pull dan push ke Bitbucket (port 22: Connection timed out)
Hal-hal lain yang berkaitan dengan SSH dan SCP (mungkin Gitlab juga)

Problem

Sebagai contoh, kalau port 22 diblok oleh internet provider, waktu kita mau pull changes di github, kita dapat pesan ini:

$ git pull origin master
# (loading lama...)
ssh: connect to host github.com port 22: Connection timed out
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Hal serupa ketika kita mau akses VPS via SSH (dengan default port 22):

$ ssh username@domain.co.id
# (loading lama...)
ssh: connect to host domain.co.id port 22: Connection timed out

Solusi

1. Untuk Github dan Bitbucket

Untuk source code hosting seperti github dan bitbucket, mereka menyediakan port yang berbeda untuk kebutuhan push dan pull. Berikut referensinya:

Di github: Enabling SSH connections over HTTPS.
Di bitbucket: Jira BCLOUD-9519 - port 22: Connection refused.

Dari referensi di atas, untuk sistem operasi Ubuntu dan turunannya kita bisa set SSH config dengan cara berikut:

$ vim ~/.ssh/config # boleh pakai nano

# Tambah config di bawah
Host bitbucket.org
  Hostname  altssh.bitbucket.org
  Port  443
  
Host github.com
  Hostname ssh.github.com
  Port 443
  User git

# Simpan dan exit

Kita coba push ke Github, akan muncul yang seperti ini:

$ git push origin main
The authenticity of host '[ssh.github.com]:443 ([18.138.xxx.xxx]:443)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTx.....
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[ssh.github.com]:443,[18.138.xxx.xxx]:443' (RSA) to the list of known hosts.
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 599 bytes | 299.00 KiB/s, done.
Total 6 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To github.com:username/nama-repo.git
   b21a15f..3b7510e  main -> main

Artinya sudah sukses. Untuk Bitbucket lebih kurang sama.

2. Untuk VPS

Di VPS-nya kita mesti ubah default port SSHnya, dari 22 menjadi (misal) 49152. Caranya coba cek artikel dari web om Musa Amin:

Link: Cara Mengubah Nomor Port SSH Server (musaamin.web.id)

Di artikel itu diajari juga cara akses SSH dengan beda port. Tapi kalau mau ringkas, kita bisa buat ssh config seperti di atas untuk VPS:

$ vim ~/.ssh/config # boleh pakai nano

# Tambah config di bawah
Host domain.co.id
  HostName 161.xxx.xxx.31 # IP address atau nama domain
  Port 49152 # Sesuai port baru di VPS
  IdentityFile /home/username/.ssh/id_rsa # Ini path private key localhost kita
  IdentitiesOnly yes 

# Simpan dan exit

Dari situ bisa kita coba ssh seperti biasa (tanpa mengisi custom port), mestinya sudah aman.

Baik teman-teman, itu saja tips untuk yang mengalami problem akses ke port 22 diblok oleh internet provider terkait dengan akses ke VPS atau Github dan Bitbucket. Terima kasih sudah berkenan membaca. Semoga bermanfaat.

Regular Auto Backup MySQL / MariaDB di Ubuntu

Mon, 26 Apr 2021 09:00:00 +0800

Bismillahirrahmanirrahim.

Untuk mengamankan data dari potensi kehilangan Saya butuh melakukan backup seluruh database MariaDB di laptop seminggu sekali, ini adalah hal kedua yang saya lakukan untuk menghindari kehilangan data mysql/mariaDB kalau ada apa-apa di OS linux mint laptop (hal pertama, baca Cara Mengubah Direktori Data MariaDB dengan Symlink).

Waktu googling sana sini, saya ketemu artikel yang berisi bash script untuk membuat backup seluruh database MySQL atau MariaDB menjadi 1 file per database.

https://skycube.net/2014/06/13/backup-all-mysql-databases-in-separate-files

Ini saya buat gist bash script-nya.

Cara menggunakan script

Cara pakainya di localhost/laptop:

Buat script dulu backupMySQLDBsinSingleFiles.sh bebas taruh di direktori mana saja, misal saya di /home/nafies/Documents/Nafies/backups.
Pastikan kedua variable di dalam file tersebut sesuai dengan credential MySQL di localhost

USER='root'
PASSWORD='root_password'

Pastikan MySQL/MariaDB kita sedang aktif.
Coba jalankan script (abaikan [Warning] Using a password...):

$ cd /home/nafies/Documents/Nafies/backups
$ chmod +x backupMySQLDBsinSingleFiles.sh
$ ./backupMySQLDBsinSingleFiles.sh
Starting MySQL Backup
Mon Apr 26 06:41:40 +08 2021
mysql: [Warning] Using a password on the command line interface can be insecure.
Dumping database: database_1
mysqldump: [Warning] Using a password on the command line interface can be insecure.
Dumping database: database_2
mysqldump: [Warning] Using a password on the command line interface can be insecure.
Dumping database: database_3
mysqldump: [Warning] Using a password on the command line interface can be insecure.
Dumping database: database_4
mysqldump: [Warning] Using a password on the command line interface can be insecure.
Finished MySQL Backup
Mon Apr 26 06:41:51 +08 2021

Sampai di sini kita akan mendapatkan direktori/folder baru berupa timestamp 20210426_064140, didalamnya ada file *.sql.gz sebagai file backup tiap database. Seperti gambar di bawah:

Setup CRON untuk auto backup regular

Sekarang kita lanjutkan membuat CRON sintax agar proses backup jalan otomatis seminggu sekali. Misal tiap hari Sabtu jam 10 pagi. Jalankan perintah di terminal berikut:

$ crontab -e
# Taruh paling bawah
0 10 * * 6 cd /home/nafies/Documents/Nafies/backups && ./backupMySQLDBsinSingleFiles.sh 2>&1 | /usr/bin/logger -t MYSQL_BACKUP

Persis seperti gambar di bawah, kemudian simpan.

Sampai di sini selesai prosesnya.

Nanti cron akan melakukan backup otomatis seluruh database setiap Sabtu jam 10 pagi dari setting ini:

0 10 * * 6

Referensi: https://crontab.guru

Baik teman-teman, itu saja tips cara membuat auto backup database MySQL atau MariaDB secara regular di Ubuntu dan distro turunannya. Jika ada yang belum dipahami, silakan tuliskan dikolom komentar. Semoga bermanfaat, terima kasih.

Dompet - Sistem Pencatatan Keuangan Personal

Sat, 24 Apr 2021 08:30:00 +0800

Bismillahirrahmanirrahim.

Saya ingin share project aplikasi web yang saya kembangkan untuk mencatat keuangan personal. Namanya Dompet. Aplikasi ini membantu saya dalam mencatat pengeluaran dan pemasukan harian, mengkategorikan/jenis transaksi, mencatat hutang piutang, dan melihat ringkasan transaksi per bulan dan per tahun. Project ini awalnya dibangun dengan Laravel 5.5, sekarang sudah upgrade ke Laravel 8.x (sampai artikel ini ditulis).

Ini link download source code: https://github.com/nafiesl/dompet

Secara umum fitur-fiturnya:

List Transaksi perbulan (dengan pencarian, filter bulan, kategori dan partner)
List transaksi per hari
Input pengeluaran dan pemasukan
Input hutang-piutang
Pengkategorian transaksi (misal: Iuran, Pulsa, Internet, Cicilan Motor)
Partner transaksi (misal: PLN, PDAM, FIF, atau nama orang)
Laporan/summary transaksi per tahun
Pindah bahasa (en untuk English, id untuk Bahasa Indonesia)

Project ini free and open-source berlisensi MIT, yang intinya :

Saya persilakan temen-teman untuk menggunakan/memodifikasi/mendistribusikan ulang untuk tujuan pribadi atau komersil, dengan catatan file LICENSE di dalam project tidak diubah/dihilangkan.

List fitur lengkap, cara installnya, dan detail lisensinya dijelaskan dalam playlist youtube berikut:

(Link ke youtube: Demo Project Dompet)

Aplikasi ini dibangun dengan metode Test-driven Development, yang sudah kita ulas di banyak artikel pada blog ini pada topik: TDD Laravel. Jadi sudah ada feature dan unit test setiap action usernya. Bagi yang ingin belajar automated testing Laravel, mungkin bisa jadi referensi. Silakan jika teman-teman yang ingin berkontribusi dalam mengembangkan project ini.

Semoga manfaat yang saya dapatkan dari project ini juga bermanfaat untuk orang banyak. Terima kasih teman-teman.

Cara Membuat Sponsor Button pada Github Repository

Wed, 07 Apr 2021 22:30:00 +0800

Bismillahirrahmanirrahim.

Github sponsor adalah satu fitur di github untuk memfasilitasi para inisator project open-source menggalang dukungan dana dari pengguna atau suporter project open-source-nya.

Cara membuatnya sebenarnya ada di dokumentasi github ini, tapi di sini saya buatkan panduan Bahasa Indonesianya.

Login ke github: https://github.com/login
Buka project repository yang ingin kita tambah tombol sponsor, misal di saya: https://github.com/nafiesl/dompet
Klik tab “Settings”
Centang checklist “Sponsorships”
Klik “Set up sponsor button”
Kita akan masuk halaman text editor untuk buat file baru .github/FUNDING.yml
Pada bagian custom: isi link ke layanan dukungan dana dalam bentuk array, contoh:
```
custom: ['https://trakteer.id/nafiesl', 'https://...']
```
(Baris lainnya boleh dihapus.)
Isikan pesan commit, misal “Add Sponsorship”
Klik tombol “Commit new file”.
Refresh halaman repository, mestinya sudah muncul tombol “Sponsor”, kalau di-klik muncul informasi link dukungannya.
Link dukungan juga akan muncul di sisi kanan halaman repository github.

Sip, semoga tips ini bermanfaat.

BTW saya aktif membuat beberapa project open-source juga (cek di sini). Kalau temen-temen ingin memberikan dukungan dana, bisa cek tombol Sponsor tiap repository githubnya, atau lihat halaman “donate” ini.

Terima kasih temen-temen untuk waktunya.

Cara Menghubungi Customer Support GCP (Google Cloud Platform)

Sat, 03 Apr 2021 21:30:00 +0800

Bismillahirrahmanirrahim.

Beberapa bulan terakhir, ada beberapa pembaca yang menghubungi saya melalui telegram dan email, berdiskusi tentang problem akun GCP mereka. Kebanyakan diskusi tentang saat masa trial GCP habis.

Beberapa topik diantaranya:

Ada yang tidak sengaja mendaftar GCP tapi tidak tahu fungsinya buat apa, bagaimana cara menghapus akunnya.
Ada yang sudah mendaftar, lalu bertanya bagaimana cara stop layanan GCP agar tidak kena charge.
Ada juga yang kena charge kartu kreditnya karena ada pemakaian layanan GCP tanpa dia tahu penyebabnya.
Ada juga yang masa free-trial habis, tetapi ingin melakukan migrasi data ke tempat (provider) lain.

Nah untuk kasus yang bermasalah teknis atau billing/tagihan, berikut cara menghubungi Customer Support Google Cloud Platform:

Sebelum mulai, pastikan kita sudah login dengan akun google yang dipakai untuk mendaftar GPC nya ya.

Kunjungi link ini: https://console.cloud.google.com/support/chat
Klik Get GCP billing Support
Klik Contact Billing Support
Pilih akun kartu kredit nya (walaupun sudah non aktif)
Klik continue.

Dari situ kita sampaikan problem yang kita hadapi di akun Google Cloud Platform, baik problem teknis ataupun tagihan/billing (pakai bahasa Inggris).

Ya tahu sih, ini channel customer support untuk billing/tagihan, tapi kalau kita tanya teknikal, minta bantu sambungkan ke tim yang berwenang, gitu aja.

Kemudian nanti ada 2 kemungkinan saluran response dari customer supportnya:

Dibalas dengan Chat (di situ juga).
Dibalas dengan email.

Kemungkinan mereka ngga balas segera, butuh waktu beberapa jam, karena perbedaan zona waktu antara kita dengan mereka. Tapi dari beberapa orang yang sudah menghubungi customer support, pemasalahannya selesai. Alhamdulillah.

Sip, semoga tips ini bermanfaat, terima kasih.

Produktifitas dengan Joplin untuk Aktifitas Harian

Sun, 07 Mar 2021 12:30:00 +0800

Bismillahirrahmaanirrahiim.

Diantara banyak note-taking dan to-do list app yang pernah saya gunakan:

Google Keep (sync desktop dan android)
Standard Notes (sync desktop dan android),
xfce4-notes-plugin (desktop XFCE),
Indicator sticy notes (desktop ubuntu),
Color Notes (android),
Trello (sync desktop dan android), dan
Joplin (sync desktop dan android)

Saat ini saya memilih Joplin karena sangat cukup untuk produktifitas kerja dan kehidupan personal. Saya pakai Joplin sejak sekitar Oktober 2019.

Pengenalan Joplin

Joplin adalah sebuah aplikasi open-source untuk note-taking dan to-do list yang bisa sinkronisasi antar Aplikasi Desktop, Android dan IOSnya.

Link Download: https://joplinapp.org

Privasi (penting)

Joplin tidak punya server untuk nyimpan data kita, dia menyediakan fitur sinkronisasi antar perangkat dengan media online dari pihak ketiga (one drive, dropbox, nextcloud).
Kita bisa aktifkan sinkrodinasi dengan end-to-end encription. Jadi data yang tersimpan di media online tidak bisa dibaca orang, selain perangkat-perangkat yang terhubung.

Pemanfaatan

Joplin saya gunakan tiap hari untuk produktifitas:

Menulis rencana dan aktual aktifitas harian
Notulen meeting dengan klien atau partner
Mencatat ide yang terlintas pikiran
Code snippet
Link-link penting.
Panduan singkat ketika ketemu solusi dari suatu masalah.

Fitur

Ini fitur diantara Joplin yang saya sering gunakan:

End to end sync via dropbox ke joplin Laptop dan joplin Ponsel (tanpa ada batasan jumlah perangkat)
Buat konten (todo list dan note) dengan markdown
Struktur notebook/folder dapat diatur sesuai kebutuhan
Dark mode (biar ngga silaw)
Pencarian konten
Tag konten

Tips Penggunaan untuk Aktiftas Harian

Berikut tips yang bisa saya share untuk teman-teman yang ingin memberdayakan Joplin untuk aktifitas harian:

Notebook/folder diatur sesuai kebutuhan.
Untuk aktifitas harian, note list dalam notebook/folder berjudul tanggal.
Dalam satu note (harian) dibuat struktur planning dan aktual aktifitas
- Plan hari ini (berupa checklist)
- Aktual aktifitas pagi, siang, sore dan malam (berupa bullet list)
Tiap mau stop kerja setiap hari, bikin plan aktifitas besok.
Besok harinya, sebelum mulai aktifitas, cek plan yang sudah ditulis hari sebelumnya.
Selama tidak ada distraksi, fokus menyelesaikan plan hari ini.

Sejak awal tahun 2021, saya berusaha selalu mengisi plan dan aktifitas aktual setiap hari, agar penggunaan waktu lebih efisien, sehingga waktu untuk keluarga bisa lebih banyak.

Demikian sharing kali ini tentang produktifitas dengan joplin, siapa tau ada yang cari-cari software todo list dan note-taking yang simple, privat dan open-source.

Mudah-mudahan bermanfaat buat teman-teman pembaca. Terima kasih.

Manfaat Project Open-Source dan Github bagi Programmer

Sat, 06 Mar 2021 23:00:00 +0800

Bismillahirrahmaanirrahiim.

Tentang Project Open-Source

Dari yang saya pahami, project open-source adalah sebuah project yang dibuat atas inisiatif sendiri kemudian dipublikasikan secara publik, sehingga menjadi manfaat juga untuk orang lain. Jika project tersebut menarik, maka banyak orang yang menggunakan dan berkontribusi untuk pengembangannya. Contohnya: Bahasa pemrograman, framework, library/package, atau software jadi yang bisa digunakan orang lain.

Secara umum, biasanya programmer yang membuat project open source untuk kebutuhan sendiri, kemudian dipublikasikan untuk mengenalkan dirinya/produknya/jasanya kepada komunitas, mendapatkan side project/penghasilan tambahan, dan menolong orang lain. Teman-teman bisa belajar tentang project open-source di website https://opensource.guide/id.

Tentang Github

Di dunia programming hampir semua orang tahu tentang github, sebuah media untuk menyimpan source code berupa repository, banyak digunakan oleh para programmer maupun perusahaan. Selain menyimpan kode, di github kita juga dapat berinteraksi dengan para pengguna dan kontributor, misal berdiskusi tentang improvement fitur dan bug melalui fitur issue. Di github sudah ada tool continuous integration melalui github actions.

Nah, untuk menyimpan source code, di github itu ada 2 pilihan privasi:

Public, source code kita dibuka untuk umum, semua orang bisa lihat.
Private, source code tidak dibuka untuk umum, hanya kita dan orang-orang yang kita ijinkan yang bisa melihat.

Pada artikel ini, kita hanya membahas privasi repository yang public (open-source) serta manfaatnya bagi programmer.

Yang Bisa Dilihat Orang Lain

Ketika kita mempublikasikan project open-source ke github, orang lain akan melihat:

Problem apa yang kita hadapi dan apa solusinya
Programming stack apa saja yang kita bisa, skill apa yang kita punya, seberapa ahli kita di situ.
Seberapa baik susunan kode yang kita buat, apakah mudah dipahami atau asal-asalan.
Bagaimana kita menyelesaikan sesuatu, implementasi fitur dan implementasi solusi dari suatu masalah.
Seberapa cepat kita mengerjakan sesuatu, dilihat dari history commit yang kita push.
Seberapa informatif pesan commit yang kita buat (ini penting untuk kerja kolaborasi).

Ketika kita menangani issue di github, orang lain akan melihat:

Seberapa komunikatif kita terhadap orang lain.
Seberapa sopan kita berpendapat.
Seberapa cepat kita respons terhadap suatu masalah.
Seberapa baik kita menanggapi usul/ide orang lain.
Seberapa cepat kita mendapatkan solusi atas permasalahan yang dilaporkan.

Yang Bisa Disimpulkan Orang Lain

Orang lain jadi mudah mengenal skill dan personalitas kita. Akan lebih mudah memutuskan apakah kita cocok diajak kerjasama atau tidak.

Kesimpulan

Ini beberapa manfaat yang bisa kita dapatkan jika memiliki project Open-Source di Github:

Mudah menolong orang lain yang memerlukan contoh project atau contoh potongan kode.
Menjadi sarana marketing gratis untuk menunjukkan skill.
Mempermudah orang lain utk mempertimbangkan jika ingin bekerjasama (atau meng-hire kita).
Mudah menjawab jika ada yang bertanya: “Anda punya skill apa saja?”
Menjadi nilai plus saat melamar pekerjaan.

Saran dari saya:

Untuk mendapatkan manfaat di atas, buatlah minimal 1 project open-source yang kira-kira jadi manfaat untuk orang banyak, buatlah dengan serius, lalu upload ke github dan publikasikan ke forum, komunitas, dan grup-grup facebook yang cocok.

Baik temen-teman itu sedikit share pengalaman saya tentang project open-source dan github. Mudah-mudahan bermanfaat. Terima kasih atas waktunya.

Cara Pindah-Pindah Versi PHP pada LAMP stack di Ubuntu

Sun, 14 Feb 2021 14:00:00 +0800

Bismillahirrahmaanirrahiim.

Latar Belakang

Untuk kebutuhan web development dengan PHP dan Laravel, di laptop saya menggunakan LAMP Stack, dan saya install beberapa versi PHP, mulai versi 7.0 s/d 8.0, karena saya masih maintain project untuk klien dari Laravel versi 5.2 s/d Laravel versi baru untuk kebutuhan project baru dan project riset. Dari situ saya butuh pindah-pindah versi PHP sesuai project yang sedang dihandle.

Script PHP Swither

Cari-cari di github, saya ketemu repository ini:

https://github.com/rapidwebltd/php-switch-scripts

Pada project tersebut tersedia :

File setup.sh untuk install beberapa versi PHP sekaligus dari ppa:ondrej/php
File switch-to-php-x.x.sh untuk pindah ke versi x.x.

Dan karena saya butuh beberapa modifikasi script untuk install extension PHP-nya, saya fork repository tersebut dan modifikasi sesuai kebutuhan:

https://github.com/nafiesl/apache-php-switcher

Cara Menggunakan Script

Sebelum Mulai

Pastikan di localhost kita sudah terinstall LAMP stack atau minimal apache2.

Sekarang kita clone project di atas, bebas saja mau pilih antara kedua repositori di atas. Misal mau pakai yang punya saya:

# Clone projectnya ke localhost
$ cd ~/projects/scripts
$ git clone https://github.com/nafiesl/apache-php-switcher.git

# Masuk direktorinya
$ cd apache-php-switcher

# (optional) Install semua versi PHP yang tersedia
$ ./setup.sh

# Gunakan script switch untuk pindah-pindah versi PHP
$ ./switch-to-php-7.2.sh
$ ./switch-to-php-7.3.sh
$ ./switch-to-php-7.0.sh

# Cek versi PHP aktif
$ php -v
PHP 7.0.33-40+ubuntu20.04.1+deb.sury.org+1 ......

Ok sampai di sini mestinya kita sudah bisa pindah-pindah versi PHP dengan cara:

$ cd ~/projects/scripts/apache-php-switcher
$ ./switch-to-php-7.3.sh
$ ./switch-to-php-7.2.sh

Permudah dengan Bash Alias

Kalau cara di atas terkesan repot (harus cd ke direktori lalu jalankan script), kita bisa permudah lagi dengan bash alias. Caranya seperti berikut:

$ vim ~/.bash_aliases # Bisa juga pakai nano

# Masukkan tambahkan script ini
alias setphp56='~/projects/scripts/apache-php-switcher/switch-to-php-5.6.sh'
alias setphp70='~/projects/scripts/apache-php-switcher/switch-to-php-7.0.sh'
alias setphp72='~/projects/scripts/apache-php-switcher/switch-to-php-7.2.sh'
alias setphp73='~/projects/scripts/apache-php-switcher/switch-to-php-7.3.sh'
alias setphp74='~/projects/scripts/apache-php-switcher/switch-to-php-7.4.sh'
alias setphp80='~/projects/scripts/apache-php-switcher/switch-to-php-8.0.sh'
# Simpan dan keluar

# Terapkan alias terbaru
$ source ~/.bash_aliases

# Pindah-pindah versi PHP
$ setphp73
$ setphp74
$ setphp72

Sip, dari sini satu urusan hidup kita terasa lebih mudah. Mudah-mudahan bermanfaat. Terima kasih teman-teman.

Cara Mengubah Direktori Data MariaDB dengan Symlink di Ubuntu

Sat, 13 Feb 2021 23:00:00 +0800

Bismillahirrahmaanirrahiim.

Latar Belakang

Sedikit cerita, saya pernah kehilangan data MySQL/MariaDB di localhost karena install ulang Sistem Operasi di laptop. Di localhost laptop, saya mengunakan aplikasi Free PMO untuk mengelola proyek freelance. Jadi data software tersebut hilang sekitar 3 bulan, akhirnya saya harus input ulang berdasarkan dokumen-dokumen kerja yang saya simpan. Tapi tidak bisa kembali semua. :(

Dari situ saya memikirkan gimana caranya agar setiap install ulang sistem operasi, data MySQL/MariaDB saya tetap aman. Akhirnya ketemu artikel di Digital Ocean untuk mengubah direktori data MySQL. Saya praktekkan dengan database MariaDB ke disk drive/partisi harddisk lain di laptop, alhamdulillah berhasil.

Mengubah Direktori Data MariaDB/MySQL

Sebelum Mulai

Di sini kita akan praktek memindahkan direktori data MariaDB ke partisi atau disk drive lain pada laptop/PC, pertama kita perlu konfigurasi auto-mount untuk disk drive yang akan digunakan, caranya bisa cek di artikel ini.

Pada contoh ini, saya punya absolute path untuk direktori di partisi lain seperti ini: /mnt/ND/DB/mysql

Lakukan backup database seluruh terlebih dahulu, untuk menghindari resiko data hilang. Saya biasa pakai script dari artikel ini.

Lanjut, buka terminal, berikut perintahnya:

# Stop MySQL (MariaDB) service
$ sudo systemctl stop mysql
$ sudo systemctl status mysql # Pastikan service mysql sudah stop

# Backup dulu direktori datanya
$ sudo cp -a /var/lib/mysql /var/lib/mysql_bak

# Pindahkan direktori data MySQL
$ sudo mv /var/lib/mysql /mnt/ND/DB/mysql

# Buat symlink
$ sudo ln -s /mnt/ND/DB/mysql /var/lib/mysql

# Update apparmor tunables alias
$ sudo vim /etc/apparmor.d/tunables/alias # Bisa pakai nano juga
alias /var/lib/mysql/ -> /mnt/ND/DB/mysql/, # Tambahkan paling bawah
$ sudo systemctl restart apparmor

# Start MySQL (MariaDB) service
$ sudo systemctl start mysql
$ sudo systemctl status mysql

OK sampai di situ pastikan MySQL (MariaDB) service aktif kembali, lalu coba akses datanya melalui MySQL client biasa yang kita gunakan (PHPMyAdmin / Adminer / MySQL Workbench). Mestinya isi database sama seperti sebelumnya.

Restore Database (Setelah Install Ulang Sistem Operasi)

Nah saat install ulang sistem operasi, kita coba restore database menggunakan direktori data yang sudah kita ubah di atas.

Sebelum Mulai

Lakukan konfigurasi auto-mount untuk disk drive yang akan digunakan, cek di artikel ini.

Pastikan MariaDB sudah terinstall di sistem operasi yang baru.

Baik kita lanjut, buka terminal, jalankan perintah berikut:

# Stop MySQL (MariaDB) service
$ sudo systemctl stop mysql
$ sudo systemctl status mysql # Pastikan service mysql sudah stop

# Backup direktori data default
$ sudo mv /var/lib/mysql /var/lib/mysql_bak

# Buat symlink
$ sudo ln -s /mnt/ND/DB/mysql /var/lib/mysql

# Update apparmor tunables alias
$ sudo vim /etc/apparmor.d/tunables/alias # Atau pakai nano
alias /var/lib/mysql/ -> /mnt/ND/DB/mysql/, # Tambahkan paling bawah
$ sudo systemctl restart apparmor

# Start MySQL (MariaDB) service
$ sudo systemctl start mysql
$ sudo systemctl status mysql

Sampai di sini, mestinya MySQL (MariaDB) service kembali normal, bisa kita cek melalui MySQL client, data lama mestinya sudah kembali.

Mengembalikan Data Direktori Default

OK sekarang gimana kalau kita mengalami kendala saat melakukan langkah di atas? Kita mesti revert atau mengembalikan pengaturan direktori data default seperti semula. Caranya seperti ini:

# Stop MySQL (MariaDB) service
$ sudo systemctl stop mysql
$ sudo systemctl status mysql

# Hapus direktori data hasil symlink
$ sudo rm /var/lib/mysql

# Kembalikan direktori hasil backup
$ sudo mv /var/lib/mysql_bak /var/lib/mysql

# Update apparmor tunables alias
$ sudo vim /etc/apparmor.d/tunables/alias
alias /var/lib/mysql/ -> /mnt/ND/DB/mysql/, # Hapus baris ini
$ sudo systemctl restart apparmor

# Start MySQL (MariaDB) service
$ sudo systemctl start mysql
$ sudo systemctl status mysql

Sip, seharusnya setelah dikembalikan, data MySQL (MariaDB) sudah kembali seperti data default saat baru install MariaDB.

Summary

Cara ini cukup cepat dan efektif untuk mengembalikan data jika kita sering install ulang sistem operasi. Sebelumnya saya melakukan backup dan restore database secara manual, tetapi prosesnya lama dan jadi masalah jika kelupaan.
Backup database juga tetap perlu dilakukan sebelum install ulang sistem operasi, untuk jaga-jaga jika proses pengembalian data dari disk drive lain gagal dilakukan. Saya biasa pakai script dari artikel ini.
Saya pernah gagal saat restore direktori data (MySQL service tidak bisa start), akhirnya membuat symlink lagi ke disk drive lain, kemudian restore hasil backup (summary nomor 2). Setelah dicek harddisknya, ternyata penyebabnya ada bad sector pada harddisk. Jadi perlu diwaspadai juga.

Baik, demikian teman-teman, mudah-mudahan bermanfaat. Terima kasih.

Cara Auto-Mount Disk Drive dengan Gnome Disk Utility di Ubuntu

Thu, 11 Feb 2021 08:48:00 +0800

Bismillahirrahmaanirrahiim.

Pada posting ini, Saya ingin share cara seting auto-mount disk drive di Ubuntu dan distro-distro turunannya. Pengaturan Auto-mount disk ini tujuannya agar harddisk atau partisi harddisk bisa langsung digunakan tanpa harus mount secara manual (meng-klik disk nya di file manager).

Manfaatnya:

Jika ada aplikasi/software yang kita pakai sehari-hari yang disimpan pada disk tersebut, bisa dijalankan langsung tanpa mount disknya.
Jika kita buat symlink suatu direktori pada disk tersebut di Home directory, symlink-nya langsung bisa digunakan.

Baik, untuk mengatur auto-mount disk drive, kita menggunakan software “gnome-disk-utility”. Biasanya sudah include di Ubuntu dan distro-distro turunannya, di sini Saya menggunakan Linux Mint 20).

Langkah pengaturannya:

Buka software “gnome-disk-utility” atau “Disks”.
Pilih harddisk yang berisi partisi atau drive yang ingin di auto-mount.
Klik pada partisi atau drive yang ingin di auto-mount.
Klik Partition Options.
Klik Edit Mount Options.
Ketika kotak dialog Mount Options terbuka, klik switch “User Session Defaults”.
Pastikan Mount at system startup tercentang.
Pada Identify As, pilih “LABEL=xxxx”, di mana xxxx adalah label disk drive ketika kita membuat partisinya.
Klik OK (isi password user jika diminta).
Ketika kembali ke tampilan utama, kita akan melihat partisi atau disk drive nya akan ditandai bintang.
Restart laptop/PC.
Setelah restart, kita buka terminal dan jalankan $ ll /mnt, maka disk drive yang auto-mount tadi akan muncul di sana.

Dari sini kita bisa mengunakan /mnt/xxxx sebagai absolute path untuk partisi atau disk drive tersebut.

Demikian teman-teman, semoga bermanfaat. Terima kasih.

Monitor Error Laravel: Sentry

Sat, 30 Jan 2021 23:10:00 +0800

Bismillahirrahmaanirrahiim.

Beberapa waktu yang lalu, saya pernah posting tentang cara membuat laravel log viewer untuk mengecek error log yang terjadi saat laravel sudah dideploy ke production server. Cara ini lumayan mempermudah sih, tapi ada yang lebih canggih lagi dari itu.

Kali ini kita membahas cara yang lebih modern untuk monitor error laravel di production. Yaitu menggunakan layanan Sentry.io. Yaitu sebuah layanan monitoring aplikasi online yang membantu developer untuk men-diagosis error, memperbaiki error dan optimasi performa sistem. Layanan paket gratisnya sangat cukup untuk kebutuhan freelancer, kita bisa cek di halaman pricingnya.

Berikut beberapa tampilan sentry.io ketika ada error yang ditangkapnya dari project laravel kita:

Daftar Event Error

Ini tampilan sentry ketika kita membuka list error yang terjadi pada sebuah project.

1. Daftar Project

Berisi pilihan project yang kita pasangi sentry.

Saya belum tahu apakah ada batasan jumlah project untuk tipe akun free. Saat ini baru saya coba untuk 6 project laravel.

2. Pilihan Environment

Di sini kita dapat memilih environment mana yang ingin kita lihat list errornya. Ini sangat berguna jika kita memiliki beberapa server deployment untuk aplikasi yang sama, misal:

Staging (deployment untuk pengujian)
Production (deployment untuk live sistem).

Jadi kita bisa tahu, error ini berasal dari environment yang mana.

Kalau untuk project temen-temen, mungkin ada env dev, qa, uat, prod. Sesuai dengan deployment setup masing-masing.

3. Umur Error

Informasi ini untuk mengetahui, sudah berapa lama/sejak kapan error ini pertama terjadi (tanda nomor 3 pada screenshot di atas).

4. Terakhir terjadi error

Informasi ini untuk mengetahui, kapan terakhir error terjadi (tanda nomor 4 pada screenshot di atas). Misal sebelumnya terjadi 3 jam yang lalu, setelah kita lakukan perbaikan (bugfix) seharusnya error tidak terjadi lagi setelahnya.

5. Berapa kali error terjadi

Informasi ini untuk mengetahui berapa kali error sudah terjadi sejak awal hingga saat ini (tanda nomor 5 pada screenshot di atas).

6. Assignee (penugasan, cocok untuk team)

Fitur ini dapat kita manfaatkan jika kita mendaftar dengan paket sentry “team” atau di atasnya. Fitur ini untuk menugasi developer siapa yang akan meng-handle error tersebut, agar lebih mudah mem-follow-up nya (tanda nomor 6 pada screenshot di atas).

Detail Event Error

Ini tampilan detail ketika kita klik salah satu error dari list error di atas.

1. Pesan error

Kita bisa lihat pesan error yang terjadi pada section EXCEPTION (tanda nomor 1 pada screenshot di atas). Ini yang biasa muncul di file log laravel.

2. Informasi Client (Browser dan Sistem Operasi)

Di halaman ini kita bisa melihat ketika terjadi error, client/user menggunakan sistem operasi apa dan browser apa (tanda nomor 2 pada screenshot di atas).

3. Grafik kejadian per hari

Pada grafik ini (tanda nomor 3 pada screenshot di atas), kita bisa lihat intensitas kejadian error (seberapa sering terjadi perharinya).

4. Waktu kejadian pertama dan terbaru/terakhir

Di bawah grafik kejadian error per hari, kita bisa melihat informasi, kapan error terjadi pertama kali, dan kapan terakhir atau kejadian terbaru untuk error tersebut (tanda nomor 4 pada screenshot di atas).

5. Stacktrace yang informatif

Biasanya ketika membaca error log di laravel log, ada stacktrace (file-file yang dilewati sebelum error/exception terjadi). Nah di sentry ini, kita dapat informasi stacktrace yang lumayan lengkap, sampai isi variabel yang masuk pada method/function juga bisa dilihat. Ini sangat mempermudah kita untuk proses debugging dan bugfix.

6. Query Database

Pada bagian BREADCRUMBS, kita bisa melihat query-query database yang dijalankan oleh laravel sebelum error terjadi. Ini juga akan mempermudah kita untuk proses debugging.

7. cURL Sample

Pada detail event error kita juga bisa dapat informasi cURL (request ke web) yang menjadi trigger/pemicu error pada project laravel.

Pada cURL sample ini, kita bisa mengetahui form data atau form input yang dikirimkan oleh user ke sistem. Informasi ini bisa kita gunakan untuk simulasi/reproduce error saat proses debugging.

Kesimpulan

Sentry adalah layanan yang sangat bermanfaat untuk melakukan monitoring error di project kita untuk mempermudah proses debugging dan bugfix developer.
Tidak hanya sebatas PHP/Laravel, Sentry ini support banyak bahasa pemrograman, kita bisa lihat di halaman ini https://sentry.io/platforms. Taglinenya: “Track errors in every language, framework, and library.”
Untuk setup sentry di project laravel cukup mudah, bisa ikuti tutorial dari webnya (https://sentry.io/for/laravel).
Sentry support laravel versi lama juga, ada 1 project saya yang laravel versi 5.2, masih bisa setup sentry untuk monitor errornya.
Akun sentry yang free sangat cukup untuk kebutuhan freelance project.

Demikian ulasan singkat tentang monitor error pada project laravel dengan sentry. Mudah-mudahan dengan informasi ini dapat mempermudah temen-temen developer/freelance dalam memberikan layanan yang lebih baik untuk user dan kliennya.

Terima kasih.

Internet Speed Indicator untuk Android

Mon, 04 Jan 2021 08:15:00 +0800

Bismillahirrahmaanirrahiim.

Mungkin ada teman-teman suka monitor kecepatan internet di hape, seperti saya. Untuk melihat seberapa cepat internet saat ini, atau ingin lihat apakah internet sedang lancar atau gangguan. Nah saya ketemu aplikasi Internet Speed Meter Lite yang rasanya cocok untuk kebutuhan di atas.

Di antara fiturnya:

Indicator kecepatan internet di status bar
Indicator kecepatan internet di notification
Pemakaian kuota harian dari internet SIM card vs Wifi

Ada juga fitur lainnya untuk versi berbayar, tapi untuk kebutuhan saya pribadi, yang versi lite ini sudah sangat cukup.

Demikian teman-teman mudah-mudahan bermanfaat. Terima kasih atas waktunya.

Testing Laravel: Menggunakan Fitur Data Provider PHPUnit

Fri, 07 Jun 2019 09:00:00 +0800

Bismillahirrahmaanirrahiim.

Dari artikel sebelumnya yang membahas tentang testing laravel, kita membuat beberapa test method untuk menguji validasi form register user. Ini kita lakukan karena ingin menguji apakah nilai yang kita berikan sudah sesuai dengan validasi form yang kita tentukan.

Nah, ternyata untuk melakukan hal seperti ini, kita bisa menggunakan fitur Data Provider dari PHPUnit. Saya bisa mencoba fitur Data Provider ini setelah membaca artikel ini: Tidying Up Your PHPUnit Tests with Data Providers.

Dengan menggunakan Data Provider, kita cukup membuat dua method, yaitu:

Satu test method,
Satu method untuk menyediakan data yang diujikan.

Kedua method ini membuat phpunit menjalankan satu method test beberapa kali dengan nilai yang berbeda.

Persiapan Praktek

Baik, seperti artikel-artikel testing laravel sebelumnya, kita sambung project yang sudah ada di repo ini : Laravel TDD, tepatnya di commit ini.

Bagi teman-teman yang ingin ikut praktek silakan clone repository tersebut, install dan jalankan vendor/bin/phpunit. Pastikan teman-teman dapat hijau dulu pada testingnya.

Hasilnya: OK (21 tests, 86 assertions).

Langsung Praktek

Baik, sekarang kita buka file tests/Feature/Auth/RegisterTest.php kita tambahkan dua method ini:

<?php
// Class RegisterTest.php

// ... getRegisterFields()

// ... user_can_register()

/**
 * @test
 * @dataProvider registrationDataProvider
 */
public function validate_user_register_form($errorField, $formFields)
{
    $this->post('/register', $this->getRegisterFields($formFields));

    $this->assertSessionHasErrors([$errorField]);
}

public function registrationDataProvider()
{
    return [
        // error pada field name, jika name kosong
        ['name', ['name' => '']],
        // error pada field name, jika name panjang 260 karakter
        ['name', ['name' => str_repeat('John Thor ', 26)]],

        // error pada field email, jika email kosong
        ['email', ['email' => '']],
        // error pada field email, jika mengisi email yang tidak valid
        ['email', ['email' => 'username.example.net']],
        // error pada field email, jika mengisi email yang terlalu panjang
        ['email', ['email' => str_repeat('username@example.net', 13)]],

        // error pada field password, jika password kosong
        ['password', ['password' => '']],
        // error pada field password, jika password kurang dari 6 karakter
        ['password', ['password' => 'ecret']],
        // error pada field password, jika konfirmasi password tidak sama
        ['password', ['password' => 'secret', 'password_confirmation' => 'escret']],
    ];
}

// ... user_email_must_be_unique_on_users_table()

Nah kedua method tersebut dapat menggantikan delapan test method lainnya:

1. user_name_is_required
2. user_name_maximum_is_255_characters
3. user_email_is_required
4. user_email_must_be_a_valid_email
5. user_email_maximum_is_255_characters
6. user_password_is_required
7. user_password_minimum_is_6_characters
8. user_password_must_be_same_with_password_confirmation_field

Sekarang kedelapan method di atas bisa dihapus. Lalu kita jalankan vendor/bin/phpunit lagi:

Seharusnya hasilnya tetap sama OK (21 tests, 86 assertions).

Penjelasan Penggunaan Data Provider

Data Provider adalah fitur PHPUnit yang memungkinkan kita menjalankan beberapa test dengan hanya menggunakan satu test method.

Pada method yang dijadikan Data Provider, seperti registrationDataProvider(), di sana kita me-return numeric array yang terdiri dari 8 value. Analoginya:

public function dataProviderMethod()
{
    return [
        [$var1, $var2], // value loop 1,
        [$var3, $var4], // value loop 2,
        [$var5, $var6], // value loop 3,
        ...
    ];
}

Ketika phpunit dijalankan pada test method yang memiliki @dataProvider dataProviderMethod, maka phpunit akan menjalankan test berulang-ulang (loop) sebanyak jumlah value yang berasal dari dataProviderMethod. Jika ada 3 value, maka test method tersebut diulang 3 kali.

Setiap perulangan test method, phpunit menggunakan value dari masing-masing loop tadi pada test method yang bersangkutan. Jadi :

$var1 dan $var2 digunakan pada loop pertama.
$var3 dan $var4 digunakan pada loop kedua.
$var5 dan $var6 digunakan pada loop ketiga.
Dan seterusnya …

Seperti yang sudah kita kerjakan di atas, satu test method yang mendapatkan bantuan dari data provider berisi 8 value, maka test method akan diulang 8 kali, sehingga dapat menggantikan 8 test method lainnya.

Kesimpulan

Fitur data provider dapat mempermudah kita dalam:

Menguji satu helper function dengan beberapa kondisi nilai (parameter dan nilai return nya).
Menguji fitur validasi form dalam framework laravel.

Baik, sampai di situ contoh penggunaan data provider pada phpunit. Penjelasan detailnya dapat teman-teman lihat di dokumentasi PHPUnit-nya.

Perubahan script yang dikerjakan pada artikel ini, dapat teman-teman lihat di commit ini. Terima kasih atas waktunya. Semoga bermanfaat.

Tips Saat Freelance Project Berjalan (Bagian 2)

Thu, 06 Jun 2019 09:00:00 +0800

Bismillahirrahmaanirrahiim.

Menyambung artikel sebelumnya, berikut 5 tips lagi pada saat project sedang dikerjakan.

6. Catat semua hasil diskusi dengan klien

Ketika pekerjaan kita sedang di review klien, biasanya ada berbagai masukan atau feedback terkait point-point yang mendetailkan item-item pekerjaan, atau ada bagian tertentu yang harus diperbaiki, ditambahkan, atau dikurangi.

Tips berikutnya, usahakan agar selalu mencatat jika ada feedback yang pointnya belum ada/tercatat pada dokumen konsep/item pekerjaan. Misal berupa dokumen.txt. Catatan ini sebagai bantuan untuk kita mengingat detail instruksi dari klien, dan akan menjadi eviden atau bukti feedback dari klien yang harus diperbaiki. Biasanya pada sebuah file catatan itu saya menambahkan informasi ini:

Tanggal dan jam, nama personel klien (tulis jika ada beberapa orang)
Item pekerjaan
- catatan 1
- catatan 2
- catatan 3

Keudian catatan disimpan dengan nama file, misal: Meeting 2019-04-04.13.30.21.txt (ada tanggal dan jamnya). Catatan-catatan ini akan menjadi acuan kita dalam melanjutkan pekerjaan dan minimalisir kata “lupa”.

7. Sampaikan kepada klien jika ada permintaan yang diluar kesepakatan awal

Setiap feedback dari klien, sangat dimungkinkan (bahkan selalu) muncul permintaan diluar dari item pekerjaan yang sudah disepakati. Karena secara wajar memang setelah beberapa waktu point tambahan tersebut baru terpikirkan, atau bisa jadi memang ada perubahan kebijakan.

Ada beberapa opsi dalam menanggapi item pekerjaan yang diluar kesepakatan awal:

Kerjakan sebagai layanan gratis (jika tidak dianggap berat)
Kerjakan dengan minta tambahan waktu
Kerjakan dengan usulan biaya tambahan
Pending ke fase project berikutnya
Sampaikan tidak sanggup.

Pilihan ini tergantung kebijakan kita sebagai freelancer, mau pilih opsi yang mana, karena ikatan kerja kita dengan klien sudah kita batasi sesuai dengan kesepakatan tertulis di awal. Kalau saya pribadi, kalau pekerjaan tambahan tidak terlalu rumit, saya pilih opsi 1.

8. Laporkan kesulitan

Jika kita menemui kesulitan saat mengerjakan project klien, terutama yang akan berdampak pada keterlambatan target waktu, sebaiknya disampaikan kepada klien. Tujuannya agar klien mengetahui dan bisa antisipasi bahwa akan ada keterlambatan dari target yang disepakati.

Dari pengalaman saya, biasanya klien mau memahami kondisi kesulitan yang kita sampaikan selama kita memberikan argumen yang masuk akal, walaupun dengan alasan pribadi. Terutama jika sejak awal kita sudah membangun komunikasi yang baik dengan klien.

Walaupun yang kita sampaikan merupakan hal negatif (keterlambatan progress), ini bisa menjadi kabar baik bagi klien. Artinya dengan kondisi itu, klien mengetahui bahwa project akan terlambat, sehingga dapat menyesuaikan agenda lauching atau menjalankan kebijakan lain.

9. Berikan opsi/pilihan yang jelas jika perlu keputusan klien

Tidak jarang kita menemui “persimpangan jalan” saat sedang mengerjakan project klien. Di situ kita memiliki beberapa opsi yang memerlukan keputusan dari klien. Apakah pekerjaan dilanjutkan dengan metode A, atau dengan metode B, atau dengan metode C.

Jika keputusan ini berhubungan dengan proses bisnis klien, maka konsultasikanlah dengan klien, agar beliau memutuskan metode mana yang dipilih. Sebisa mungkin kita tidak memutuskan sendiri, karena jika keputusan kita keliru, pekerjaan harus diulang lagi.

Ingat, ketika menemui “persimpangan” seperti ini, sebisa mungkin berikan dua pilihan terbaik, atau maksimal 3 pilihan untuk klien. Jika lebih dari 3 pilihan, klien membutuhkan waktu lama untuk memutuskan. Menunggu keputusan itu bisa memperlambat progress pekerjaan kita.

Untuk mempermudah klien mengambil keputusan, pastikan sebelum memberikan pilihan, kita sudah menyiapkan informasi kelebihan dan kekurangan atau plus minus dari masing-masing metode tadi, dari sisi:

Kerumitan mengerjakan

Kemudahan user saat menggunakan

Perkiraan waktu yang dibutuhkan

Perkiraan ada biaya tambahan

10. Konsisten (sekaligus kesimpulan)

Tips terakhir, KONSISTEN. Yap, kapital dan tebal. Ini sekaligus kesimpulannya.

Konsisten adalah tekad dan semangat mengerjakan sesuatu secara terus menerus. Agar 9 tips di atas yang dapat membantu mengamankan pekerjaan kita dan membuat hubungan dengan klien selalu baik, maka kita harus melakukannya secara konsisten (terus-menerus), tidak hanya di awal-awal saja.

Beberapa klien cerita kepada saya, mereka menemui freelancer yang hanya berkomunikasi dan kerja baik di awal-awal saja, tetapi setelah beberapa minggu, progress pekerjaan dan komunikasi dengan klien mulai berkurang dan sering konflik.

Ketika kita:

Konsisten datang “on-time” setiap meeting
Konsisten memulai pekerjaan segera
Konsisten “fast response” dan komunikasi dengan baik
Konsisten melaporkan progress
Konsisten mencatat hasil diskusi

Insya Allah hubungan dengan klien akan selalu baik dan menjadi lebih baik.

Penutup

Baik teman-teman itu 10 tips bagi freelancer saat project sedang berjalan, yang sudah kita bahas di artikel sebelumnya dan artikel ini. Hal-hal di atas adalah aturan yang saya terapkan selama bekerja sebagai freelancer selama 5 tahun terakhir (sampai artikel ini ditulis).

Semoga bermanfaat menjadi tips yang bermanfaat. Terima kasih atas waktunya.

Tips Saat Freelance Project Berjalan (Bagian 1)

Sun, 31 Mar 2019 16:50:00 +0800

Bismillahirrahmaanirrahiim.

Pada artikel sebelumnya, kita sudah membahas bagaimana cara:

Sekarang hal-hal apa yang harus diperhatikan ketika sebuah project berjalan? Misalkan setelah proses di atas terjadi kesepakatan, dan kita di-hire oleh klien untuk mengerjakan projectnya. Alhamdulillah artinya klien mempercayakan pekerjaan kepada kita.

Setiap freelancer memiliki cara, metode, strategi atau aturan tersendiri yang diterapkan dalam menjalankan project. Pada artikel ini saya akan share 5 dari 10 tips yang biasa saya terapkan ketika saya mengerjakan sebuah project web development.

1. Segera mulai

Yap, segera mulai. Penyakit yang sering menyerang freelancer adalah “entar dulu”. Karena merasa project ini baru disetujui, kita terkadang menganggap enteng waktu mulai project. Apakah karena masih ada project (sebelumnya) yang belum rampung, atau memang maunya entar dulu, yang jelas suka menunda mulai kerja.

Nah, biasanya ekspektasi klien, setelah DP (pembayaran tahap pertama), setidaknya seminggu kemudian kita sudah ada laporan progress. Kalau kita lambat mulainya, pasti lapor progress juga lambat. Ekspektasi (klien) ini akan meleset, satu poin minus untuk kita.

Jadi sekali lagi, segera mulai. Jangan sampai dapat point minus pertama.

2. Fast respons

Misal kita menghubungi seseorang, kemudian orang itu segera merespons. Kita pasti senang. Apa lagi kalau yang dihubungi itu adalah orang yang kita titipi uang untuk mengerjakan sesuatu.

Kalau kita tanya sesuatu, kita pasti berharap orang itu respons cepat, kan? Kalau orang itu tidak merespons, apalagi sampai berhari-hari? Bagaimana perasaan kita? Silakan jawab sendiri.

Nah klien seperti itu juga. Ketika sudah bayar uang DP kepada freelancer, klien berharap: kalau ditanya progress, kita bisa merespons dengan cepat. Terlepas apakah sudah ada progress atau belum, progress banyak atau sedikit, selama kita cepat respons, klien akan lebih tenang.

Sebaliknya, jika freelancer slow respons (atau bahkan tidak merespons) ketika dihubungi, akan jadi point minus dan kepercayaan klien bisa menurun.

Insya Allah dengan sikap fast respons, hubungan dengan klien akan selalu baik (dan menjadi lebih baik). Walaupun ada keterlambatan progress, kepercayaan klien terhadap kita tidak akan berkurang selama kita fast respons.

3. Konsisten melaporkan progress

Kalau dari contoh penawaran yang saya share di artikel menyusun budgeting project, di akhir bagian Tahap Pembangunan Website, ada saya sebutkan laporan progress per minggu.

Itu bentuk janji saya kepada klien, untuk melaporkan progress secara periodik per minggu.

Nah ekspektasi klien, saya berjanji akan rutin melakukan laporan progress per minggu. Bisa dibayangkan jika saya tidak ada kabar progress selama 2 atau 3 minggu, bagaimana perasaan klien?

Bisa jadi klien bertanya-tanya: “Kira-kira bener dikerjakan atau tidak ya?”.

Jika ingin jadi freelancer yang mendapat testimoni yang baik (reputasi bagus), kita harus selalu mengusahakan laporan progress sesuai dengan yang dijanjikan itu.

Selain itu, dengan konsisten melakukan laporan progress perminggu, kita menjadi dipaksa harus ada progress. Jadi seolah-olah seperti ada tekanan bahwa kita benar-benar harus mengerjakan project dan melaporkan seminggu sekali.

Jika kita bisa disiplin melaporkan per minggu, Insya Allah kita bisa menyelesaikan project sesuai target. Itu intinya: Disiplin = progress on target.

4. Segerakan meminta feedback dari klien

Pernah kah mengalami ketika sudah 50% project berjalan, klien baru melihat pekerjaan kita dan mengatakan: yang ini keliru, itu salah, harusnya begini, yang saya maksud begitu, lalu yang ini juga salah perhitungannya, atau sejenisnya.

Pernah kah? Sering kah?

Nah hal-hal seperti ini dulu sering saya alami. Ketika laporan minggu pertama, kedua dan ketiga tidak ada feedback dari klien, pada minggu ke 4 baru ketahuan ada yang salah, harus diperbaiki. Akhirnya membuat saya mengulang kerja beberapa bagian. Sudah 50% diulang lagi dari 30%.

Ini lumayan makan waktu, menguras pikiran, dan bisa jadi potensi konflik dengan klien. Untuk mengantisipasi kejadian ini, sesegera mungkin freelancer harus mendapatkan feedback dari klien. Agar pekerjaan yang keliru dapat diminimalisir.

Misalnya jika laporan progress 1 dan 2 tidak dapat feedback, pada progress 3 usahakan bertemu dengan klien. Tunjukkan progress yang sudah diselesaikan sampai tahap tersebut, dan minta feedback (apakah sampai disini sudah benar atau ada yang perlu diperbaiki).

Dengan pola seperti ini, jika ada kesalahan dalam proses yang kita kerjakan, maka kita dapat segera memperbaikinya. Mendapatkan feedback sesegera mungkin akan mendatangkan keuntungan bagi kedua pihak :

Bagi freelancer: minimalisir pekerjaan keliru dan kesalahpahaman konsep dengan klien.
Bagi klien: melihat progress nyata dalam pengerjaan projectnya.

5. Bertanya kepada klien

Walaupun kita sudah membuat konsep dan membuat list item pekerjaan sebelum mulai project, akan sangat mungkin kita menemukan hal-hal baru yang belum sempat dibahas dengan klien.

Jika hal itu terjadi, jangan sungkan untuk bertanya kepada klien.

Pak/ibu kalau kondisi begini bagaimana? Sepertinya belum sempat kita diskusikan. Bagaimana solusi yang diterapkan saat ini di perusahaan?
Pak/ibu kemarin sempat kita bahas proses bla..bla..bla.., tetapi ada kondisi yang seperti ini. Sebaiknya bagaimana?
Pak/ibu kemarin kita sepakat dibuat begini, tetapi sepertinya lebih efektif begini, jadi nanti bla..bla..bla… Bagaimana menurut bapak/ibu?

Kita (freelancer) adalah orang luar, bukan bagian dari perusahaan klien, sangat wajar jika kita tidak memahami seutuhnya seluk beluk dan aturan yang diberlakukan.

Jadi jika ada hal yang belum dimengerti terkait proses bisnis klien, sebaiknya kita (freelancer) tidak mengambil asumsi/solusi sendiri. Asumsi kita bisa salah dan solusi terbaik adalah bertanya.

Penutup

Baik teman-teman itu dulu 5 tips yang kita bahas. Insya Allah selanjutnya akan ada 5 tips lagi yang akan saya tulis pada artikel selanjutnya.

Semoga bermanfaat bagi teman-teman semua. Terima kasih atas waktunya.

Cara Membuat Budget untuk Project Klien

Fri, 15 Mar 2019 10:30:00 +0800

Bismillahirrahmanirrahim.

Seperti yang saya sampaikan pada artikel sebelumnya, bahwa saat ini saya bekerja sebagai freelance web developer. Artinya bekerja dari satu project ke project lainnya, baik dari klien yang sama maupun klien yang baru.

Beberapa teman menanyakan kepada saya, bagaimana cara menentukan budget sebuah project untuk dijadikan penawaran kepada klien. Jawabannya, tiap freelancer atau agensi berbeda-beda cara menentukan budget projectnya.

Pertimbangan Penentuan Budget

Menentukan budget/anggaran/nilai project memang memerlukan banyak pertimbangan agar nilainya menjadi cocok untuk kita (freelancer) dan cocok untuk klien. Berikut beberapa pertimbangan yang saya rangkum. Mempertimbangkan dari:

Perkiraan lama pengerjaan project.
Jumlah/banyaknya fitur yang dikerjakan.
Seberapa rumit fitur yang dikerjakan.
Seberapa banyak user yang akan menggunakannya.
Seberapa rumit tampilan user-interface sistem.
Seberapa besar nama perusahaan klien.
Seberapa besar usaha/omzet klien.
Bahkan ada yang menentukan dari seberapa besar penghematan klien jika sistem yang kita buat sudah berjalan. Misal setelah adanya sistem yang kita buat nanti:
- Klien akan menghemat budget pulsa dan rekening telepon.
- Klien akan hemat kertas.
- Klien akan hemat budget pembelian dan maintenance infrastruktur.

Nah, kira-kira 8 point di atas itu yang bisa dijadikan acuan untuk menghitung nilai project. Ini berdasarkan pengalaman saya selama freelance, dan cerita teman-teman yang pernah saya temui.

Kalau saya pribadi bagaimana? Apakah 8 point itu dipertimbangkan semua? Hmm…

Pertimbangan yang Saya Terapkan

Kalau yang saya terapkan selama ini (dan saya pikir cukup efektif), adalah mempertimbangkan point 1 s/d 3.

Pertimbangan lama pengerjaan
Misal dihitung perkiraan berapa minggu atau berapa bulan proses pengerjaanya. Kalau saya biasanya dihitung per minggu (berapa minggu target saya menyelesaikannya).
Pertimbangan Jumlah Fitur
Semakin banyak fitur, otomatis kan waktu dan pikiran kita juga semakin banyak terfokus disitu. Semakin banyak yang dikerjakan, semakin panjang waktu yang diperlukan, harusnya semakin banyak kita dapat bayaran. Jadi waktu dan pikiran kita itu yang nanti akan dibayar oleh klien.
Pertimbangan Kerumitan Fitur
Diantara sekian banyak fitur yang diminta oleh klien, pasti ada beberapa fitur yang pengerjaannya rumit, karena akan ada banyak rule/peraturan perusahaan yang diterapkan pada fitur-fitur itu. Biasanya ini fitur utama sistem. Fitur-fitur inilah yang akan menjadi solusi dari kesulitan klien saat ini (sesuai konsep yang sudah kita buat sebelumnya).

Pertimbangan Opsional

Pertimbangan nomor 4 s/d 8 adalah pertimbangan opsional bagi saya, bisa digunakan bisa juga tidak.

Pertimbangan point ke 4, yaitu potensi jumlah pengguna sistem/web, ini bisa menjadi pertimbangan jika sistem digunakan oleh user umum. Sistem yang digunakan untuk internal perusaahaan tentu berbeda penanganannya dengan sistem/web yang akan digunakan untuk khayalak ramai.

Berhubungan dengan point pertimbangan ke 4, biasanya disusul dengan pertimbangan ke 5, yaitu tampilan user interface. Jika sistem/web akan digunakan oleh khalayak ramai, tentu tampilan depan (front-end) tentunya klien ingin tampilan yang cantik dan menarik, karena tampilan depan itu akan menjadi citra dari perusahaan. Semakin bagus kan jadinya semakin keren, semakin rumit juga developer membuatnya.

Cara Menentukan Budget

Atas pertimbangan-pertimbangan di atas, saya menyusun beberapa tahap dalam menghitung budget project.

1. Membuat Daftar Fitur

Dari konsep yang sudah kita tulis, seharusnya kita sudah bisa perkirakan, apa saja fitur yang akan dikerjakan untuk sistem ini. Kita buat daftar fitur yang akan dikerjakan. Untuk memulai, bisa list fitur utama dulu.

Membuat Daftar Fitur Utama

Misal kita ambil contoh Konsep Sistem Sewa Barang pada artikel sebelumnya, pada sistem web tersebut harus ada:

Bagian depan (untuk pelanggan):

Katalog produk
Proses pemesanan
Proses Checkout

Bagian belakang (untuk admin/karyawan):

Pengelolaan order
Laporan

Menambah Daftar Fitur Pelengkap

Setelah fitur utama kita dapatkan, sekarang kita daftarkan fitur-fitur pelengkapnya.

Bagian depan (untuk pelanggan)

Registrasi member
Detail dan foto produk
Konfimasi pembayaran
Email transaksi untuk member
Halaman profil member
Header dan footer website

Bagian belakang (untuk admin/karyawan):

Pengelolaan produk
Pengelolaan member
Pengelolaan data pembayaran
Pengaturan sistem
Pengelolaan backup dan restore database

Sampai di sini, kita bisa melengkapi list fitur di atas dengan sub-sub fiturnya, sesuai kebutuhan. Nanti di paling bawah, saya share contoh list fitur lengkap dengan deskripsi masing-masing.

2. Memperkirakan Lama Pengerjaan

Nah setelah kita menentukan fitur-fitur yang akan dibuat, saatnya kita perkiraan waktu pengerjaannya. Dari sekian banyak fitur yang akan dibuat tadi:

Q: Apakah cukup waktu mengerjakan 1 bulan?
A: Tidak!
Q: Apakah cukup waktu mengerjakan 1,5 bulan?
A: Cukup, tapi mepet.
Q: Apakah cukup 2 bulan?
A: Cukup!

Oke sekarang kita mau dibayar berapa untuk mengerjakan itu selama 2 bulan?

Q: Dibayar Rp. 3 juta cukup?
A: Tidak!
Q: Dibayar Rp. 6 juta cukup?
A: Tidak!
Q: Dibayar Rp. 10 juta cukup?
A: Ya, cukup! (kalau belum cukup, bisa diteruskan lagi.)

Oke, kita perkirakan waktu pengerjaan 1,5 - 2 bulan, dengan budget Rp. 10 juta. Ini hanya permisalan, ya. Kita bisa mengira-ngira sendiri, nilai jasa kita kira-kira cocoknya berapa.

3. Menentukan Harga Setiap Fitur

Lanjut, sekarang kita tentukan harga per fitur dengan patokan total Rp. 10 juta yang kita tentukan tadi. Kita bisa membuatnya dengan format tabel seperti ini.

Bagian depan (untuk pelanggan) :

No.	Item Pekerjan	Biaya
1.	Katalog produk	Rp. ……….
2.	Proses pemesanan	Rp. ……….
3.	Proses Checkout	Rp. ……….
4.	Registrasi member	Rp. ……….
5.	Detail dan foto produk	Rp. ……….
6.	Konfimasi pembayaran	Rp. ……….
7.	Email transaksi untuk member	Rp. ……….
8.	Halaman profil member	Rp. ……….
9.	Header dan footer website	Rp. ……….
	Total	Rp. ……….

Bagian belakang (untuk admin/karyawan) :

No.	Item Pekerjan	Biaya
1.	Pengelolaan order	Rp. ……….
2.	Laporan	Rp. ……….
3.	Pengelolaan produk dan stok	Rp. ……….
4.	Pengelolaan member	Rp. ……….
5.	Pengelolaan data pembayaran	Rp. ……….
6.	Pengaturan sistem	Rp. ……….
7.	Pengelolaan backup dan restore database	Rp. ……….
	Total	Rp. ……….

Di sini kita menentukan harga per fitur ini, sesuai dengan tingkat kerumitan fitur yang bersangkutan. Misal dari rincian item pekerjaan di atas, kita bisa mengira pengerjaan fitur pengelolaan data order akan lebih rumit daripada pengelolaan data member. Berarti harga item pekerjaan pengelolaan order akan lebih tinggi dari pada harga item pekerjaan pengelolaan member.

Begitu.

4. Total Harga Fitur = Budget

Baik sampai di situ kita tinggal jumlahkan total harga di atas, sehingga mendapatkan atau mendekati nilai budget kita yang Rp. 10 juta tadi.

No.	Item Pekerjan	Biaya
1.	Pengerjaan bagian depan	Rp. ……….
2.	Pengerjaan bagian belakang	Rp. ……….
	Total	Rp. ……….

Baik, setelah penjelasan di atas, semoga teman-teman pembaca bisa memahami alur proses menghitung budget sebuah project. Setidaknya itu yang saya terapkan saat ini.

Informasi Ketentuan Kerjasama

Ini opsional, tetapi bagi saya ini penting sekali.

Setelah menulis rincian di atas, pada pengajuan budget (proposal) itu kita bisa informasikan ketentuan-ketentuan untuk menggunakan layanan kita, atau ketentuan-ketentuan untuk bekerjasama dengan kita. Misalnya:

Informasi bahwa biaya pada pengajuan ini disesuaikan dengan tingkat kesulitan pengerjaan fitur sistem.
Informasi bahwa jika ada perubahan kebijakan perusahaan yang berpengaruh ke fitur yang dikerjakan, maka biaya akan dikalkukasikan lagi menyesuaikan dengan kebijakan baru (biasanya ini terkait fitur baru yang belum didiskusikan di awal).
Rencana pengerjaan mulai kapan, dan target selesai berapa lama.
Cara/tahapan pembayaran.
Masa Garansi untuk bugfix dan maintenance.
Dan seterusnya sesuai kebutuhan …

Contoh Proposal Pengajuan Budget

Sekarang saya share satu contoh proposal pengajuan budget project untuk klien.

Download PDF : Contoh Pengajuan Budget Project.pdf.
Ini format ODT : Contoh Pengajuan Budget Project.odt.

Kesimpulan

Kalau kita lihat contoh pengajuan budget project di atas, apa manfaat yang kita dapatkan? Kalau dari pengalaman saya, dengan pengajuan yang rinci di atas:

Cara kita mempersiapkan project seperti ini akan menjadi point besar untuk pertimbangan klien. Di sini klien akan melihat keseriusan kita terhadap projectnya.
List item pekerjaan ini menjadi semacam perjanjian kerja, bahwa item-item pekerjaan itulah yang menjadi patokan kita dalam mengerjakan project.
Kita sebagai developer akan tahu tanggung jawab kita sampai dimana.
Klien akan tahu sampai di mana kewajiban developer yang menjadi haknya (fitur-fitur yang akan didapatkan).
Nilai project yang kita ajukan lengkap dengan rincian item pekerjaan akan mendapat penilaian yang berbeda (dari klien) dibandingkan nilai project yang diajukan tanpa rincian yang jelas.
Jika terjadi kesepakatan, maka item-item pekerjaan di atas akam menjadi pegangan masing-masing pihak untuk bahan evaluasi di akhir project.

Nah seperti itu teman-teman cara saya mempersiapkan sebuah project yang akan dikerjakan untuk klien. Lumayan panjang dan melelahkan kah? Di awal-awal mungkin iya, tapi kalau sudah terbiasa, sudah tidak melelahkan lagi.

Secara tidak langsung kita belajar menjadi system analyst, dan akan semakin terasah jika sering dikerjakan. Insyaallah usaha tidak akan mengkhianati hasil. Usaha maksimal hasilnya juga akan maksimal.

Semoga bermanfaat bagi teman-teman semua. Terima kasih atas waktunya.

Contoh Penulisan Konsep Project untuk Klien

Sun, 10 Mar 2019 12:00:00 +0800

Bismillahirrahmanirrahim.

Pada beberapa artikel sebelumnya, kita membahas tentang mempersiapkan calon project untuk develop sistem calon klien. Di situ saya cerita tentang konsep tertulis, terkait proses bisnis sesuai cerita dari klien. Pada artikel ini, saya share contoh konsep sebuah sistem web pemesanan dan pengelolaan sewa produk elektronik yang pernah saya buat.

Silakan download PDF : Contoh Rangkuman Diskusi (Interview Project).pdf.

Kerangka Konsep

Baik, sedikit kita bahas point-point utama dari konsep tersebut:

1. Tujuan Sistem

Di bagian awal ini biasanya saya menulis alasan-lasan kenapa sistem ini dibuat, apa manfaatnya untuk perusahaan klien (sbg sistem owner), manfaat untuk user (misal utk karyawan). Bagian ini ditulis untuk memastikan kita sudah satu visi dengan klien perihal tujuan dan manfaat sistem nantinya.

2. Kamus Istilah

Namanya kita feeelancer kan orang luar, dan istilah-istilah dan singkatan-singkatan tertentu dalam perusahaan ada yang tidak umum. Kadang ada istilah dari klien yang belum kita pahami, ada juga istilah-istilah dari kita yang belum dipahami oleh klien. Kamus istilah ini untuk minimalisir kesalahpahaman saat komunikasi dengan klien saat project berjalan.

Kenapa kamus istilah diletakkan di bagian awal konsep? Karena istilah-istilah tersebut akan kita gunakan pada konten dokumen konsep ini. Jika ada istilah yang salah, kemungkinan besar konsep akan salah.

3. Jenis Pengguna (Tipe User)

Bagian ini kita menuliskan daftar tipe-tipe pengguna yang akan berinteraksi dengan sistem. Ini penting sekali, jika tidak dibahas atau diketahui sejak awal, akan lumayan merepotkan kita sebagai developer. Karena modifikasi untuk penambahan jenis user baru biasanya tidak mudah, apalagi jika sistem lumayan kompleks, bisa memakan waktu yang panjang.

Saran saya, urusan jenis pengguna atau tipe user ini harus fixed dulu di awal.

4. Kondisi Saat Ini (optional)

Di contoh konsep itu tidak ada, tapi jika perlu, bagian ini bisa ditambahkan.

Di sini kita tulis seperti apa kondisi klien saat ini (sesuai dengan cerita dari klien). Bagian ini bisa berisi, misal:

Alat bantu/software apa yang digunakan klien saat ini.
Bagaimana proses bisnis atau alur kerja klien saat ini, terutama bagian yang akan dikomputerisasi menjadi sistem. (Misal proses dari A ke C, C ke F, F ke J dan seterusnya).
Kesulitan apa saja yang didapatkan dari kondisi itu, sehingga klien memutuskan untuk membuat sistem baru.

Ini tujuannya sama, agar kita satu visi dengan klien pada project ini, klien akan melihat bahwa kita mengerti kesulitannya, dan kita akan membantu memberi solusi atas kesulitan itu.

Ada contoh kasus yang baru saja saya temui, klien menggunakan file dan rumus-rumus excel untuk membantu mengelola pekerjaan di perusahaannya. Tetapi karena karyawan silih berganti, kebutuhan semakin kompleks, dan file excel tidak menjamin keakuratan data yang banyak. Beliau memutuskan untuk membuat sistem baru berbasis web.

Ini perlu kita catat juga sebagai referensi. Agar memastikan sistem yang kita buat nanti tidak akan mengulang kesalahan yang sama seperti kasus di atas.

5. Konsep Sistem atau Bisnis Proses Sistem

Di bagian ini kita membahas apa saja fitur atau proses bisnis yang diharapkan oleh klien, sebagai solusi dari kesulitan kondisi saat ini. Bagian ini bisa berupa:

Langkah kerja proses A ke C (dengan aturan-aturanya, harus ini, tidak boleh begini)
Langkah kerja C ke F (dengan aturan-aturannya juga)
Langkah kerja F ke J (dengan aturan-aturannya juga)
Jenis-jenis status yang disepakati (misal contoh file konsep di atas, ada status-status order, status barang sewa, dan status-status user)
Jika ada pertanyaan (misal ada hal yang belum dihahas waktu bertemu), bisa langsung kita tuliskan di setiap item yang kita jabarkan.

Biasanya di bagian ini saya menulis paling panjang. Sama seperti yang bagian sebelumnya, bagian ini memastikan bisnis proses yang diceritakan oleh klien pada saat interview sudah kita pahami dengan baik. Kalau ternyata ada pemahaman yang keliru, tinggal diperbaiki agar cocok dengan harapan klien.

6. Rencana Implementasi Sistem

Di contoh konsep itu tidak ada, tapi jika perlu, bagian ini bisa ditambahkan.

Jika kita mengembangkan sistem berbasis web, kita perlu menuliskan bahwa sistem yang dibuat akan berbentuk web (bukan aplikasi desktop). Tujuannya agar dapat diakses dengan PC/laptop, handphone, dan atau tablet melalui internet, sistem akan ditempatkan di server online.

Kadang ada klien yang belum bisa membedakan antara aplikasi web dengan desktop.

Kesimpulan

Nah, dengan adanya konsep tertulis seperti ini, bisa dibayangkan nanti pada saat kita mengerjakan projectnya, kita sebagai developer akan lebih terarah dalam bekerja.

Di sisi klien juga akan sangat terbantu karena isi pikirannya telah tertuang dalam bentuk tertulis. Ketika ada ide baru yang belum ada pada konsep tersebut, klien tahu bahwa ide itu belum didiskusikan dengan developer.

Bagi yang ingin mendapatkan sumber asli konsep itu, silakan download format ODT-nya. File dapat dibuka dengan software LibreOffice Writer.

Download ODT : Contoh Rangkuman Diskusi (Interview Project).odt.

Baik teman-teman, seperti itu kira-kira cara saya membuat konsep untuk mempersiapkan project klien. Semoga dapat menjadi referensi dan manfaat untuk teman-teman yang membutuhkan.

Mohon diingat bahwa ini adalah preferensi saya pribadi, bukan best practice dari sebuah siklus project software development. Ide ini saya dapatkan sesuai dengan pengalaman saya freelance sekitar hampir 5 tahun (sampai artikel ini ditulis).

Setidaknya ini adalah usaha saya untuk minimalisir konflik dan berusaha untuk menjadi freelancer yang profesional di mata klien. (ciyee, profesional… :D)

Terima kasih atas waktunya.

Project Existing Ditawar Miring? Coba Pertimbangkan 3 Hal Ini

Sun, 03 Feb 2019 14:30:00 +0800

Bismillahirrahmanirrahim.

Jika bekerja sebagai freelance progammer, biasanya kita memajang portfolio kita, baik di blog pribadi maupun website profil usaha kita (misal seperti porfolio saya ini). Akan sangat mungkin ada calon klien datang/menghubungi kita kemudian tertarik dengan project/sistem yang sudah kita buat (project untuk klien lama). Beliau ingin membeli sistem tersebut dimodifikasi dan disesuaikan dengan kebutuhan beliau.

Penawaran Harga dari Klien

Biasanya, pada tahap negosiasi harga, calon klien menawar harga dengan miring (baca: lebih murah) dari biaya development di awal, dengan pertimbangan:

Project/sistem lama tinggal diduplikat.
Hanya sedikit modifikasi sesuai kebutuhan perusahaan beliau.

Sehingga menurut beliau, developer (kita) tidak banyak yang dikerjakan lagi, jadi biaya development “bisa ditekan” seminim mungkin.

Kadang kita sebagai developer meng-amin-i pertimbangan tersebut (apalagi jika “sedang mendesak”) sehingga akhirnya terjadi kesepakatan dengan harga (miring) sesuai tawaran calon klien.

Pertimbangan Mempertahankan Harga

Kali ini saya ingin share beberapa pertimbangan agar kita (developer) dapat mempertahankan harga sesuai dengan harga yang lama, bahkan lebih tinggi dari harga yang lama.

1. Klien baru (jauh) lebih hemat waktu

Sistem sudah jadi, klien baru tidak perlu menunggu lama. Klien baru cukup menunggu kita untuk menduplikat dan modifikasi sistem yang sudah ada untuk beliau. Mungkin hanya perlu waktu 1-2 minggu, sistem sudah bisa diuji coba.

Bisa dibayangkan jika project lama belum ada, otomatis kita harus develop dulu sistemnya dari awal, berapa minggu/bulan waktu klien akan menunggu sampai sistem siap diuji coba? 1 bulan? 2 bulan? 3 bulan?

2. Sistem “minim Bug”

Jika sistem tersebut sudah digunakan oleh klien (lama), misal selama 6 bulan atau 1 tahun, pasti sudah ada tau banyak laporan kendala-kendala dan error-error yang terjadi pada sistem selama penggunaan. Otomatis sejak awal hingga sekarang, sistem tersebut sudah banyak dilakukan bugfix dan improvement di sana-sini, sehingga sistem tersebut semakin handal dan nyaman digunakan oleh user.

Pada kondisi ini klien baru tidak akan mendapatkan problem yang sama dengan klien lama. Tinggal menikmati sistem yang sudah handal dan “minim bug”.

Disclaimer: Tidak ada sistem yang bug-less, kalaupun ada, pasti akan sangat sedikit dibandingkan saat sistem baru selesai dibuat.

3. Yakin modifikasi hanya sedikit?

Nah ini yang kadang terabaikan oleh kita (sebagai developer). Pada awalnya, memang point-point/bagian-bagian yang akan dimodifikasi (untuk menyesuaikan kebutuhan) hanya sedikit. Tetapi (nanti) kita akan lihat beberapa waktu sistem tersebut jika digunakan oleh klien baru, (pasti) akan bermunculan permintaan-permintaan modifikasi diluar dari kesepakatan awal.

Hal ini memang lumrah sekali, karena setiap perusahaan memiliki bisnis proses dan strategi yang berbeda-beda, walaupun bidang usahanya sama. Misal sama-sama kampus, sama-sama perusahaan ekspedisi/kurir, atau sama-sama perusahaan dealer otomotif, pasti ada perbedaan peraturan dan kebijakan yang diadopsi ke dalam sistem. Ini yang harus kita antisipasi sebagai developer sistem.

Sekali lagi, awalnya memang “rencana modifikasi” sedikit, tetapi seiring berjalannya waktu biasanya akan banyak penyesuaian lagi diluar dugaaan kita. Dan sekali lagi ini sangat lumrah/wajar.

Keuntungan Para Pihak

Disclaimer: Ingat ini masih tahap negosiasi, belum tentu deal ya.

Baik kita coba simpulkan dari beberapa pertimbangan di atas.

Keuntungan yang akan didapatkan developer

Dengan mempertahankan harga, ini keuntungan yang akan didapatkan freelance programmer:

Bisa mempertahankan harga (jasa) agar tetap bagus.
Experience/pengalaman bertambah setelah diskusi calon klien baru (terutama di sisi bisnis proses perusahaan yang bidangnya sama).
Jika deal, tidak perlu (lelah) develop sistem dari awal.

Keuntungan yang akan didapatkan klien baru

Dengan harga yang disepakati (walaupun dianggap tinggi), ini keuntungan yang akan didapatkan oleh klien:

Hemat waktu, tanpa menunggu lama sistem bisa langsung diuji coba/digunakan.
Sistem sudah “minim bug”, karena sudah dilakukan bugfix dan improvement.
Jika perlu fitur tambahan, tinggal improve dari fitur yang sudah ada.

Kesimpulan

Jadi masing-masing pihak akan mendapatkan keuntungan yang sepadan (bahasa kerennya: “worth it”). Bagi teman-teman yang berprofesi freelance programmer, seperti saya, silakan gunakan pertimbangan-pertimbangan di atas untuk diskusi/negosiasi dengan calon klien baru. Insyaallah akan terjadi win-win solution antar kita dengan calon klien baru. Aamiin..

Ini adalah pendapat pribadi saya menurut pengalaman selama bekerja freelance.
Pertimbangan-pertimbangan di atas tidak mutlak cocok bagi semua freelance programmer, jadi boleh dipakai, boleh tidak.
Pertimbangan di atas berlaku untuk project/sistem yang khusus dibuat untuk klien dengan bidang usaha tertentu, mungkin kurang cocok untuk produk software yang dijual retail.

Semoga bermanfaat, terima kasih atas waktu teman-teman sudah membaca artikel ini.

Install plugin wordpress diminta login FTP?

Thu, 31 Jan 2019 08:00:00 +0800

Bismillahirrahmanirrahim.

Problem

Jika kita menginstall dan develop wordpress menggunakan ubuntu dan OS turunannya seperti linux mint, ketika ingin memasang plugin atau theme kita diminta login FTP.

Misal kita kunjungi URL /wp-admin/plugins.php, kita klik Install Now pada salah satu plugin, akan muncul dialog seperti gambar ini.

Siapa yang pernah mengalami? Saya sendiri (dan teman-teman yang bertanya) :D

Sebagai informasi, ini spesifikasi yang saya gunakan:

Linux Mint 18.3 (Ubuntu 16.04 LTS)
LAMP Stack (Apache 2.4, PHP 7.2)
Wordpress versi 4.* dan 5.*

Penyebab

Problem ini terjadi karena masalah permission pada direktori project wordpress. User ubuntu yang digunakan oleh web server adalah www-data, sedangkan owner dari direktori project wordpress adalah user yang sedang login (selanjutnya kita sebut username).

Cara Mengatasi

Untuk mengatasinya, kita ubah permission direktori project wordpress seperti ini.

Pertama kita cek dulu username ubuntu kita:

# Cek username yang sedang login
$ pwd
/home/username/www/wp-test

Di sini kita temukan, username kita adalah username. Kita lanjutkan dengan mengubah permissionnya.

# Ubah permission (sesuaikan dengan username teman-teman)
$ sudo chown www-data:username -R .
$ sudo chmod 775 -R .

Sekarang kita refresh halaman /wp-admin/plugins.php tadi, lalu klik Install Now. Seharusnya proses install langsung berjalan seperti gambar di bawah (tanpa ada permintaan login FTP lagi).

Penjelasan

Pada perintah chown www-data:username di atas, kita mengubah owner dari seluruh file dan direktori/folder dalam project ini (secara recursive) menjadi www-data (sesuai username web server) dan grup username sesuai dengan username ubuntu/linux mint kita.
Pada perintah chmod 775 di atas, kita mengubah permission seluruh file dan direktori di dalam project ini agar dapat dibaca dan ditulis oleh user www-data dan grup username.

Baik teman-teman, itu saja tips singkat cara mengatasi problem login FTP pada saat install plugin dan theme wordpress pada OS Ubuntu dan linux mint. Jika teman-teman ada solusi lain yang lebih ringkas/best practice, mohon teman-teman tuliskan di komentar, agar saya bisa coba riset juga. :D

Semoga bermanfaat, terima kasih atas waktu teman-teman.

Kontribusi ke Pull Request Github sebagai Pemilik Repo

Sun, 27 Jan 2019 20:30:00 +0800

Bismillahirrahmanirrahim.

Ketika ada pull request dari teman di github, mungkin ada beberapa bagian yang belum sesuai dengan convention atau best practice yang kita ikuti. Bagian tersebut harus/ingin kita perbaiki, bagaimana caranya?

Cara pertama: Merge dulu baru perbaiki.
Cara kedua: Perbaiki langsung di pull request, setelah fixed baru di merge.

Antara dua cara itu, sepertinya lebih nyaman menggunakan cara kedua, jadi history branchnya tetap jadi satu.

Cara kedua adalah seperti ini:

$ git checkout -b new-branch
$ git pull git@github.com:username/repo-name.git pr-branch

Commit beberapa perubahan di “new-branch”.

$ git remote add pr-repo git@github.com:username/repo-name.git
$ git push pr-repo new-branch:pr-branch

Kemudian lanjutkan merge pull request seperti biasa. Selesai.

Jadi nanti commit historynya jadi seperti ini:

Baik teman-teman, itu saja tips singkat agar project owner/maintainer dapat berkontribusi ke sebuah Pull Request dari kontributor dengan tetap menjaga timeline history commitnya. Semoga bermanfaat, terima kasih.

Search dan Replace String di Terminal Ubuntu

Mon, 31 Dec 2018 22:00:00 +0800

Bismillahirrahmanirrahim.

Misal kita memutuskan ingin mengganti sebuah (atau frase) kata yang ada di beberapa file di dalam satu folder secara bersamaan, biasanya kita menggunakan fitur search and replace di teks editor. Yap, fitur ini sangat membantu sekali untuk keperluan itu. Kalau di dunia programming biasanya fitur ini kita gunakan untuk mengganti nama-nama variabel, function, (atau apapun) secara bersamaan.

Nah saya pribadi menggunakan fitur Find in Files dari Sublime Text untuk melakukannya. Tetapi rasanya masih belum optimal (baca: kurang cepat), karena setelah replace, kita harus simpan satu-persatu file-filenya.

Karena perlu yang ringkas, saya googling dengan kata kunci “search replace string ubuntu terminal”, dan ketemu jawaban di halaman stackoverflow ini. Jadi di terminal di Ubuntu, kita bisa menggunakan perintah ini untuk melakukan search and replace dengan cepat:

# Perintah
$ find nama_folder -type f -exec sed -i -e 's/kata_diganti/kata_pengganti/g' -- {} +

Misal kita berikan perintah pada terminal:

# Contoh
$ find resources -type f -exec sed -i -e 's/formatDecimal/format_decimal/g' -- {} +

Maka semua kata formatDecimal pada file-file dalam folder resources akan berubah menjadi format_decimal. Perubahan yang terjadi bisa kita lihat di sample git commit ini.

Sangat disarankan agar teman-teman menggunakan version control (seperti git) sebelum menggunakan perintah ini. Just in case ada perubahan yang tidak diinginkan, maka kita tinggal melakukan git reset untuk mengembalikan semua perubahan.

Baik teman-teman, itu saja tips cara singkat dan cepat untuk mengubah kata di beberapa file text dalam folder melalui terminal Ubuntu. Semoga bermanfaat, terima kasih.

Solusi Problem: 413 Request Entity Too Large

Thu, 27 Dec 2018 17:30:00 +0800

Bismillahirrahmanirrahim.

Secara default, Nginx itu membatasi ukuran file upload maksimal 1 MB. Jika kita mengupload file ke server lebih dari itu, maka kita akan mendapat pesan error 413 Request Entity Too Large. PHP juga membatasi file upload maksimal 8 MB.

Misal kita ingin menaikkan batas maksimal file uploadnya pada web server LEMP stack. Caranya seperti ini, setelah kita ssh ke VPS, jalankan perintah ini:

# Edit file nginx.conf
$ sudo vim /etc/nginx/nginx.conf

Pada server block http, tambahkan:

http {
    server_tokens off;
    client_max_body_size 10M;
}

Simpan dan exit.

# Reload nginx
$ sudo nginx -s reload

# Edit file php.ini
$ sudo vim /etc/php/7.2/fpm/php.ini

Pada ubah nilai berikut:

upload_max_filesize = 10M
post_max_size = 10M

Simpan dan exit.

$ sudo service php7.2-fpm reload

Selesai. Sekarang kita sudah bisa upload file maksimal 10MB. Jika limit 10MB ini masih kurang, teman-teman bisa memasukkan nilai maksimal upload sesuai kebutuhan.

Semoga bermanfaat, terima kasih.

Membuat Database Baru dengan Perintah Terminal di Ubuntu

Mon, 24 Dec 2018 04:45:00 +0800

Bismillahirrahmanirrahim.

Misal kita menemukan satu project/aplikasi yang menarik di repository github, kemudian kita ingin mencobanya di PC/laptop kita. Saat kita ikuti langkah-langkah installasinya, lalu di satu langkah kita disuruh membuat database baru di MySQL. Dari situ kita buka Adminer, PHPMyAdmin, HeidiSQL, atau MySQL client apapun yang kita gunakan, lalu membuat database disitu.

Jika kita menggunakan Ubuntu/distro apapun turunannya, ada satu baris perintah terminal/bash yang membuat proses membuat database menjadi lebih cepat.

Berikut perintah satu baris perintah untuk membuat database MySQL:

$ mysqladmin -uroot -p create database_name
# Masukkan password untuk user root MySQL

Sedangkan untuk membuat database Postgres perintahnya:

$ sudo -u user_postgres createdb database_name
# Masukkan password untuk user ubuntu (karena pakai sudo)
# Masukkan password untuk user user_postgres Postgres

Dengan kemudahan perintah-perintah ini, kita tidak perlu lagi membuka aplikasi MySQL client hanya untuk keperluan membuat sebuah database di MySQL.

Semoga bermanfaat, terima kasih.

Membuat Shortcut Teks Timestamp di Ubuntu

Sat, 22 Dec 2018 08:00:00 +0800

Bismillahirrahmanirrahim.

Jika membuat sebuah file, saya itu suka menambahkan timestamp (tanggal dan waktu) pada nama filenya. Tujuannya agar saya mudah ingat, kapan saya membuat file/dokumen itu. Misalnya file Meeting 2018-11-05.14.59.txt untuk mencatat point-point diskusi dengan klien pada tanggal 5 November 2018 jam 15.00.

Kalau untuk menambahkan timestamp kita mesti mengetik satu persatu: tahun, bulan, tanggal, jam dan menit, lumayan makan waktu, belum lagi harus mengingat/melihat kalender dan jam tangan dulu. Hmm.. kurang produktif rasanya.

Bagaimana kalau untuk menggenerate timestamp text itu kita cukup menggunakan shortcut dari operating system? Jadi kita bisa menggenerate timestamp di mana saja. Nah untuk kali ini, kita akan membuat teks timestamp otomatis dengan shortcut di Ubuntu, kemudian untuk menuliskan timestamp itu kita tinggal paste saja.

Perintah Bash: date

Untuk menggenerate teks timestamp, kita bisa menulis perintah date di terminal ubuntu:

$ date
Sat Dec 22 06:56:21 +08 2018

Atau jika ingin format tertentu:

$ date +%Y-%m-%d.%H.%M
2018-12-22.06.58

Btw, format itu saya dapatkan dari hasil googling “bash date with format”, kemudian ketemu jawaban di stackoverflow ini. Kalau mau format lain, bisa lihat dengan perintah $ man date.

Masukkan teks ke clipboard

Nah selanjutnya bagaimana agar text dari perihtan date itu bisa kita gunakan? Idenya, bagaimana caranya agar teks timestamp itu bisa masuk clipboard, agar tinggal kita paste di mana-mana. Nah untuk itu kita akan menggunkan xclip.

Pertama kita install xclip:

$ sudo apt install xclip

Lalu kita coba perintah date kemudian disambung dengan perintah xclip, agar teksnya masuk clipboard.

$ date +%Y-%m-%d.%H.%M | xclip -selection clipboard

Ketika perintah di atas dijalakan, maka teks tanggal dan jam sesuai format itu bisa kita paste di manapun (di Libre Office, Text Editor, atau di nama file). Jadinya seperti ini :

2018-12-22.07.12

Membuat shortcut untuk perintah bash

Baik, sekarang bagian terpenting (untuk produktifitas), membuat shortcut agar perintah diatas tidak perlu kita jalankan di terminal. Di ubuntu kita membuatnya di pengaturan keyboard:

Buka Keyboard Settings, tab Application Shortcuts.
Klik Add.
Masukkan perintah:

bash -c 'date +%Y-%m-%d.%H.%M | xclip -selection clipboard'

Klik OK.
Masukkan shortcut sesuai keingingan, contoh kombinasi : Shift+Ctrl+Alt+T.
Selesai.

Sekarang silakan coba menggunakan shortcut itu dari keyboard, kemudian pada text editor apapun, silakan paste.

Penutup

Cara ini mungkin belum tentu bisa dilakukan di operating sistem lain. Cara ini saya dapatkan setelah beberapa lama mencari artikel untuk membuat teks tanggal dan waktu otomatis di ubuntu, tetapi tidak ketemu. Akhirnya cara diatas saya susun sendiri, untuk kebutuhan produktifitas sehari-hari.

Kalau teman-teman pembaca, menemukan cara yang lebih ringkas lagi, mohon dituliskan infonya atau link artikel di komentar.

Bagi teman-teman yang memerlukan fitur yang sama tetapi belum menemukan, selamat mencoba cara ini. Terima kasih atas waktunya. :)

Testing Laravel: Refactor Register Feature Test

Wed, 12 Dec 2018 08:50:00 +0800

Bismillahirrahmanirrahim.

Pada artikel sebelumnya kita membuat feature test untuk fitur register, tetapi pada artikel itu, kita lumayan mengulang banyak kode yang sama saat membuat testing validasi form. Sekarang kita akan coba membahas cara melakukan refactor, menerapkan DRY Code (Don’t Repeat Your Code) untuk mengefisienkan penulisan testing.

Pada praktek ini, kita menggunakan repository github Laravel-TDD, yaitu pada commit fd58467. Jika ingin mengikuti sama persis, silakan teman-teman clone repo itu ke localhost.

Baik kita mulai. Ini adalah source keseluruhan dari file tests\Feature\Auth\RegisterTest.php:

<?php

namespace Tests\Feature\Auth;

use App\User; // Tambahkan use model App\User
use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class RegisterTest extends TestCase
{
    // Trait refresh database agar migration dijalankan
    use RefreshDatabase;

    /** @test */
    public function user_can_register()
    {
        // Kunjungi halaman '/register'
        $this->visit('/register');

        // Submit form register dengan nama, email dan password 2 kali
        $this->submitForm('Register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Lihat halaman ter-redirect ke url '/home' (register sukses).
        $this->seePageIs('/home');

        // Kita melihat halaman tulisan "Dashboard" pada halaman itu.
        $this->seeText('Dashboard');

        // Lihat di database, tabel users, data user yang register sudah masuk
        $this->seeInDatabase('users', [
            'name'  => 'John Thor',
            'email' => 'username@example.net',
        ]);

        // Cek hash password yang tersimpan cocok dengan password yang diinput
        $this->assertTrue(app('hash')->check('secret', User::first()->password));
    }

/** @test */
    public function user_name_is_required()
    {
        // Submit form untuk register dengan field 'name' kosong.
        $this->post('/register', [
            'name'                  => '',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'name'.
        $this->assertSessionHasErrors(['name']);
    }

    /** @test */
    public function user_name_maximum_is_255_characters()
    {
        // Submit form untuk register dengan field 'name' 260 karakter.
        $this->post('/register', [
            'name'                  => str_repeat('John Thor ', 26),
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'name'.
        $this->assertSessionHasErrors(['name']);
    }

    /** @test */
    public function user_email_is_required()
    {
        // Submit form untuk register dengan field 'email' kosong.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => '',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_must_be_a_valid_email()
    {
        // Submit form untuk register dengan field 'email' tidak valid.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username.example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_maximum_is_255_characters()
    {
        // Submit form untuk register dengan field 'email' 260 karakter.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => str_repeat('username@example.net', 13),
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_must_be_unique_on_users_table()
    {
        // Buat satu user baru
        $user = factory(User::class)->create(['email' => 'emailsama@example.net']);

        // Submit form untuk register dengan field
        // 'email' yang sudah ada di tabel users.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'emailsama@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_password_is_required()
    {
        // Submit form untuk register dengan field 'password' kosong.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => '',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

    /** @test */
    public function user_password_minimum_is_6_characters()
    {
        // Submit form untuk register dengan field 'password' 5 karakter.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'ecret',
            'password_confirmation' => 'ecret',
        ]);

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

    /** @test */
    public function user_password_must_be_same_with_password_confirmation_field()
    {
        // Submit form untuk register dengan field 'password'
        // beda dengan 'password_confirmation'.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'escret',
        ]);

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }
}

Kalau kita lihat is file di atas, script yang paling banyak berulang adalah isian form register: name, email, password, dan password_confirmation. Berarti kita perlu membuat DRY Code untuk itu.

Jalankan Testing Sebelum Mulai

Seperti biasa, kita mulai kerja dengan menjalankan testing dulu.

# 1
$ vendor/bin/phpunit

OK (21 tests, 86 assertions)

Membuat Private Helper Method

Caranya adalah dengan membuat sebuah private helper method getRegisterFields yang berisi array attribute/isian yang lolos validasi form, seperti ini:

<?php
    // Class RegisterTest.php

    private function getRegisterFields()
    {
        return [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ];
    }
}

Menggunakan Helper Method

Sekarang kita gunakan helper method tersebut pada test method user_can_register:

<?php
    // Class RegisterTest.php

    /** @test */
    public function user_can_register()
    {        
        // Kunjungi halaman '/register'
        $this->visit('/register');

        // Submit form register dengan name, email dan password 2 kali
        $this->submitForm('Register', $this->getRegisterFields());

        // Lihat halaman ter-redirect ke url '/home' (register sukses).
        $this->seePageIs('/home');

        // Kita melihat halaman tulisan "Dashboard" pada halaman itu.
        $this->seeText('Dashboard');

        // Lihat di database, tabel users, data user yang register sudah masuk
        $this->seeInDatabase('users', [
            'name'  => 'John Thor',
            'email' => 'username@example.net',
        ]);

        // Cek hash password yang tersimpan cocok dengan password yang diinput
        $this->assertTrue(app('hash')->check('secret', User::first()->password));
    }
}

Jalankan PHPUnit:

# 2
$ vendor/bin/phpunit

Hasil: Passed

OK (21 tests, 86 assertions). Refactor pertama berhasil. Sekarang, untuk menggunakan helper method yang sama untuk test method yang lain, kita harus memodifikasinya sedikit.

Kalau kita lihat di test method yang lain, bagian attribute/isiannya juga array yang memiliki key yang sama, tetapi value nya yang berbeda-beda. Maka kita perlu menggunakan function array_merge() pada helper method kita.

<?php
    // Class RegisterTest.php

    private function getRegisterFields($overrides = [])
    {
        return array_merge([
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ], $overrides);
    }
}

Pada method ini, kita memberikan variable $overrides sebagai parameter yang akan mengganti isi dari array yang di-return oleh method.

Baik sekarang coba kita gunakan method getRegisterFields ke test method validasi untuk name dulu, untuk memastikan modifikasi kita sudah benar.

<?php
    // Class RegisterTest.php
    
    // ... getRegisterFields()
    
    // ... user_can_register()

    /** @test */
    public function user_name_is_required()
    {
        // Submit form untuk register dengan field 'name' kosong.
        $this->post('/register', $this->getRegisterFields(['name' => '']));

        // Cek pada session apakah ada error untuk field 'name'.
        $this->assertSessionHasErrors(['name']);
    }

    /** @test */
    public function user_name_maximum_is_255_characters()
    {
        // Submit form untuk register dengan field 'name' 260 karakter.
        $this->post('/register', $this->getRegisterFields([
            'name' => str_repeat('John Thor ', 26)
        ]));

        // Cek pada session apakah ada error untuk field 'name'.
        $this->assertSessionHasErrors(['name']);
    }

Oke, sekarang kita jalankan PHPUnit:

# 3
$ vendor/bin/phpunit

Hasil: Passed

OK (21 tests, 86 assertions). Sip seharusnya memang kita tetap dapat hijau. Jika sampai di sini teman-teman dapat test failure, silakan lihat kembali 2 potongan kode di atas.

Sudah? Sekarang kita gunakan method helper kita pada test method validasi form yang lain.

<?php
    // Class RegisterTest.php
    
    // ... getRegisterFields()
    
    // ... user_can_register()
    
    // ... user_name_is_required()
    
    // ... user_name_maximum_is_255_characters()

    /** @test */
    public function user_email_is_required()
    {
        // Submit form untuk register dengan field 'email' kosong.
        $this->post('/register', $this->getRegisterFields(['email' => '']));

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_must_be_a_valid_email()
    {
        // Submit form untuk register dengan field 'email' tidak valid.
        $this->post('/register', $this->getRegisterFields([
            'email' => 'username.example.net',
        ]));

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_maximum_is_255_characters()
    {
        // Submit form untuk register dengan field 'email' 260 karakter.
        $this->post('/register', $this->getRegisterFields([
            'email' => str_repeat('username@example.net', 13),
        ]));

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_must_be_unique_on_users_table()
    {
        // Buat satu user baru
        $user = factory(User::class)->create(['email' => 'emailsama@example.net']);

        // Submit form untuk register dengan field
        // 'email' yang sudah ada di tabel users.
        $this->post('/register', $this->getRegisterFields([
            'email' => 'emailsama@example.net',
        ]));

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_password_is_required()
    {
        // Submit form untuk register dengan field 'password' kosong.
        $this->post('/register', $this->getRegisterFields(['password' => '']));

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

    /** @test */
    public function user_password_minimum_is_6_characters()
    {
        // Submit form untuk register dengan field 'password' 5 karakter.
        $this->post('/register', $this->getRegisterFields(['password' => 'ecret']));

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

    /** @test */
    public function user_password_must_be_same_with_password_confirmation_field()
    {
        // Submit form untuk register dengan field 'password'
        // beda dengan 'password_confirmation'.
        $this->post('/register', $this->getRegisterFields([
            'password'              => 'secret',
            'password_confirmation' => 'escret',
        ]));

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

Nah seluruh test method sudah menggunakan private helper method kita, sekarang kita jalankan PHPUnit lagi:

# 4
$ vendor/bin/phpunit

Hasil: Passed

OK (21 tests, 86 assertions). Sip seharusnya kita tetap dapat hijau. Jika sampai di sini teman-teman dapat test failure, silakan lihat kembali script di atas, bandingkan dengan yang teman-teman punya.

Selesai proses refactoring kita sampai di sini.

Kesimpulan

Sekarang kalau kita lihat, proses yang ada di artikel ini agak panjang, tetapi aktualnya, yang dikerjakan tidak banyak. Teman-teman bisa membandingkan before dan after refactor-nya. Dari sebelumnya 183 baris, menjadi 154 baris (lumayan dipangkas 29 baris kode). Perbedaan baris yang ditambah (hijau) dan dihapus (merah) bisa teman-teman cek di commit ini.

Sekarang apa yang kita pelajari dari proses refactor ini? Kira-kira begini:

DRY code bertujuan kita tidak menulis kode yang sama berulang-ulang (seperti contoh atribute/isian form register ini).
Dengan DRY Code, ketika ada perubahan pada source code, kita hanya cukup mengubah kode satu kali. Misal kita diminta untuk menambah field phone_number pada form register, dengan testing seperti sebelumnya kita harus menambah field baru di setiap test method yang ada.
Tetapi dengan testing yang sudah direfactor barusan, kita cukup menambah field baru di method getRegisterFields saja, maka semua test otomatis menggunakan field baru tersebut.
Metode refactor ini dapat kita terapkan pada (hampir) semua feature test yang berurusan dengan CRUD.
Jika sudah mengetahui metode refactor ini, maka teman-teman bisa langsung menerapkan teknik ini, tanpa harus mengerjakan before dan after.
Jadi pada artikel sebelumnya dan artikel ini, saya ingin menunjukkan kepada teman-teman cara melakukan refactor saja. Aktualnya, silakan langsung terapkan DRY code jika kita memang sudah memahaminya :D

Saya mohon bantuan teman-teman untuk review proses dan hasil refactor ini, jika masih ada yang perlu di-refactor, mohon berikan komentar di bawah, agar kita diskusikan sama-sama. :)

Semoga belajar TDD di Laravel tetap menyenangkan. Demikian dan terima kasih atas waktu teman-teman, semoga bermanfaat.

Testing Laravel: Register Feature Test

Fri, 07 Dec 2018 19:43:00 +0800

Bismillahirrahmanirrahim.

Jika pada artikel sebelumnya kita membuat feature test untuk fitur login bawaan Laravel, kali ini kita membuat feature test untuk fitur registrasi usernya. Sedikit mengulang, fitur register ini dihasilkan melalui perintah:

$ php artisan make:auth

Pada praktek ini, kita menggunakan repository github Laravel-TDD, yaitu pada commit eb202bf. Jika ingin mengikuti sama persis, silakan teman-teman clone repo itu ke localhost.

Karena konten artikel ini agak panjang, sedikit saya sampaikan sub-sub judulnya:

Baik kita mulai.

Jalankan Testing Sebelum Mulai

Seperti biasa, kita mulai kerja dengan menjalankan testing dulu.

# 1
$ vendor/bin/phpunit

OK (11 tests, 60 assertions) Sudah hijau, kita lanjutkan.

Membuat Feature Test Register

$ php artisan make:test Auth/RegisterTest

Kita akan mendapatkan testcase class baru di : tests/Feature/Auth/RegisterTest.php. Sekarang edit filenya dan buat test method baru user_can_register.

<?php

namespace Tests\Feature\Auth;

use App\User; // Tambahkan use model App\User
use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class RegisterTest extends TestCase
{
    // Trait refresh database agar migration dijalankan
    use RefreshDatabase;

    /** @test */
    public function user_can_register()
    {        
        // Kunjungi halaman '/register'
        $this->visit('/register');

        // Submit form register dengan name, email dan password 2 kali
        $this->submitForm('Register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Lihat halaman ter-redirect ke url '/home' (register sukses).
        $this->seePageIs('/home');

        // Kita melihat halaman tulisan "Dashboard" pada halaman itu.
        $this->seeText('Dashboard');

        // Lihat di database, tabel users, data user yang register sudah masuk
        $this->seeInDatabase('users', [
            'name'  => 'John Thor',
            'email' => 'username@example.net',
        ]);

        // Cek hash password yang tersimpan cocok dengan password yang diinput
        $this->assertTrue(app('hash')->check('secret', User::first()->password));
    }
}

Sekarang kita jalankan PHPUnitnya:

# 2
$ vendor/bin/phpunit

Hasil: Passed

{:style=“width:100%”}

Okey, mantap. Sekali lagi, karena fiturnya sudah ada, ketika script testing dibuat sesuai fitur yang ada, maka hasilnya harus langsung hijau.

Testing Validasi Form Register

Karena kita sudah dapat hasil hijau untuk inputan yang valid, sekarang kita buat testing untuk validasi form register ini.

Lihat Validation Rules

Karena fiturnya sudah ada, maka kita perlu melihat apa saja validation rules yang digunakan pada formulir register ini. Bisa dilihat di controller: app\Http\Controllers\Auth\RegisterController.php, kemudian lihat method validator(). Script pada method itu isinya seperti ini:

<?php
    // Class RegisterController.php

    /**
     * Get a validator for an incoming registration request.
     *
     * @param  array  $data
     * @return \Illuminate\Contracts\Validation\Validator
     */
    protected function validator(array $data)
    {
        return Validator::make($data, [
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users',
            'password' => 'required|string|min:6|confirmed',
        ]);
    }

Di lihat dari validation rules-nya:

name: wajib diisi, berbentuk string, dan maksimal 255 karakter.
email: wajib diisi, berbentuk string, berupa format email, maksimal 255 karakter, dan email harus unik pada tabel users.
password: wajib diisi, berbentuk string, minimal 6 karakter, dan harus sama dengan field password_confirmation.

Sedikit refresher saja, validation rules adalah aturan-aturan yang diberlakukan terhadap data-data yang diinput ke sistem melalui submit form. Jika aturan-aturannya dilanggar (data yang diinput tidak valid), maka Laravel akan membatalkan proses data dan meminta agar formulir diisi kembali dengan benar.

Test Method untuk Validation Rules

Dari validation rules di atas, kita akan membuat beberapa test method :

user_name_is_required
user_name_maximum_is_255_characters
user_email_is_required
user_email_must_be_a_valid_email
user_email_maximum_is_255_characters
user_email_must_be_unique_on_users_table
user_password_is_required
user_password_minimum_is_6_characters
user_password_must_be_same_with_password_confirmation_field

Wah, kok banyak? Ga apa-apa sekalian latihan, biar terbiasa nulis test :D

Testing Script untuk Validation Rules

Nah untuk script testingnya, kita boleh mencontoh script testing yang pernah kita buat pada artikel ini: Testing Validasi Form.

Baik sekarang kita buat test method dan script sesuai dengan method-method di atas ya …

<?php
    // Class RegisterTest.php
    
    // ... user_can_register()

    /** @test */
    public function user_name_is_required()
    {
        // Submit form untuk register dengan field 'name' kosong.
        $this->post('/register', [
            'name'                  => '',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'name'.
        $this->assertSessionHasErrors(['name']);
    }

    /** @test */
    public function user_name_maximum_is_255_characters()
    {
        // Submit form untuk register dengan field 'name' 260 karakter.
        $this->post('/register', [
            'name'                  => str_repeat('John Thor ', 26),
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'name'.
        $this->assertSessionHasErrors(['name']);
    }

    /** @test */
    public function user_email_is_required()
    {
        // Submit form untuk register dengan field 'email' kosong.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => '',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_must_be_a_valid_email()
    {
        // Submit form untuk register dengan field 'email' tidak valid.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username.example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_maximum_is_255_characters()
    {
        // Submit form untuk register dengan field 'email' 260 karakter.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => str_repeat('username@example.net', 13),
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_email_must_be_unique_on_users_table()
    {
        // Buat satu user baru
        $user = factory(User::class)->create(['email' => 'emailsama@example.net']);

        // Submit form untuk register dengan field
        // 'email' yang sudah ada di tabel users.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'emailsama@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'email'.
        $this->assertSessionHasErrors(['email']);
    }

    /** @test */
    public function user_password_is_required()
    {
        // Submit form untuk register dengan field 'password' kosong.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => '',
            'password_confirmation' => 'secret',
        ]);

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

    /** @test */
    public function user_password_minimum_is_6_characters()
    {
        // Submit form untuk register dengan field 'password' 5 karakter.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'ecret',
            'password_confirmation' => 'ecret',
        ]);

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

    /** @test */
    public function user_password_must_be_same_with_password_confirmation_field()
    {
        // Submit form untuk register dengan field 'password'
        // beda dengan 'password_confirmation'.
        $this->post('/register', [
            'name'                  => 'John Thor',
            'email'                 => 'username@example.net',
            'password'              => 'secret',
            'password_confirmation' => 'escret',
        ]);

        // Cek pada session apakah ada error untuk field 'password'.
        $this->assertSessionHasErrors(['password']);
    }

Cukup panjang, tapi ga apa-apa, cuman copy-paste ini. Sekarang kita jalankan PHPUnitnya:

# 3
$ vendor/bin/phpunit

Hasil: Passed

{:style=“width:100%”}

Langsung hijau juga ya? Ya harus, kalau dapat merah, berarti copy-paste-nya ada salah.

Kesimpulan

Seperti manfaat dari feature test login kemarin, feature test register user ini akan sangat membantu jika ada perubahan kebijakan terhadap formulir yang harus diisi oleh user baru. Misalnya:

Formulir isian register ditambahkan nomor telepon, alamat, kota dan Kodepos.
Pada formulir register, user harus setuju dengan syarat dan ketentuan sistem dengan cara centang checkbox.
Dan berbagai kemungkinan perubahan fitur register di kemudian hari.

Semua kode yang telah kita kerjakan pada artikel ini, bisa teman-teman lihat di pada file RegisterTest.php ini.

Semoga belajar automated testing di Laravel semakin menyenangkan. Demikian dan terima kasih atas waktu teman-teman, semoga bermanfaat.

Testing Laravel: Login Feature Test

Wed, 28 Nov 2018 09:26:00 +0800

Bismillahirrahmanirrahim.

Sekian lama kita tidak membahas testing laravel di blog ini (terakhir tips TDD Laravel), sekarang kita coba bahas tentang testing fitur Login di laravel.

Login di framework laravel sudah disediakan “out of the box” melalui satu perintah artisan. Artinya sebenarnya sudah tidak perlu dibuatkan test lagi (karena sudah fitur resmi laravel), tetapi ada kalanya kita perlu memodifikasi fitur login ini, sesuai dengan kebutuhan sistem kita di masa datang. Jadi akan lebih baik jika kita memiliki feature test untuk ini.

Di artikel kita menggunakan repository github Laravel-TDD yang awal ya, yaitu pada commit c2feb56. Jika ingin mengikuti sama persis, silakan teman-teman clone repo itu ke localhost.

Pada project itu kita sudah memiliki fitur login, yang kita generate dengan perintah php artisan make:auth pada artikel ini. Jadi kita tinggal buat feature testnya saja.

Jalakan Testing Sebelum Mulai

Baik, seperti biasa, kita mulai kerja dengan menjalankan testing dulu.

# 1
$ vendor/bin/phpunit

OK (9 tests, 49 assertions)

$ php artisan make:test Auth/LoginTest

Kita akan mendapatkan testcase class baru di : tests/Feature/Auth/LoginTest.php. Sekarang edit untuk menyesuaikan fitur login kita. Buat test method baru registered_user_can_login, kemudian kita buat PHP comment line yang menjadi panduan kita.

<?php

namespace Tests\Feature\Auth;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class LoginTest extends TestCase
{
    /** @test */
    public function registered_user_can_login()
    {
        // Kita memiliki 1 user terdaftar

        // Kunjungi halaman '/login'

        // Submit form login dengan email dan password yang tepat

        // Lihat halaman ter-redirect ke url '/home' (login sukses).

        // Kita melihat halaman tulisan "Dashboard" pada halaman itu.
    }
}

Btw, langkah ini hanya sebagai panduan, jika teman-teman sudah fasih dengan testing, maka tidak perlu lagi membuat comment line seperti ini, boleh langsung testing scriptnya.

Baik, sekarang kita terjemahkan ke dalam bentuk script testing.

<?php

namespace Tests\Feature\Auth;

use App\User; // Tambahkan use model App\User
use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class LoginTest extends TestCase
{
    // Trait refresh database agar migration dijalankan
    use RefreshDatabase;

    /** @test */
    public function registered_user_can_login()
    {
        // Kita memiliki 1 user terdaftar
        $user = factory(User::class)->create([
            'email'    => 'username@example.net',
            'password' => bcrypt('secret'),
        ]);

        // Kunjungi halaman '/login'
        $this->visit('/login');

        // Submit form login dengan email dan password yang tepat
        $this->submitForm('Login', [
            'email'    => 'username@example.net',
            'password' => 'secret',
        ]);

        // Lihat halaman ter-redirect ke url '/home' (login sukses).
        $this->seePageIs('/home');

        // Kita melihat halaman tulisan "Dashboard" pada halaman itu.
        $this->seeText('Dashboard');
    }
}

Kita tambahkan penggunaan trait RefreshDatabase agar testing menjalankan artisan migrate, seperti yang pernah kita lakukan waktu mendapatan passed test pertama.

Sekarang kita jalankan PHPUnitnya:

# 2
$ vendor/bin/phpunit

Hasil: Passed

{:style=“width:100%”}

Langsung hijau? Betul, fitur loginnya sudah ada, kita hanya membuat testingnya saja.

Membuat Test Method Logout

Sekarang kita buat testing fitur logout. Kita edit lagi file tests/Feature/Auth/LoginTest.php tambahkan test method baru: logged_in_user_can_logout.

<?php

// ...

class LoginTest extends TestCase
{
    // ... registered_user_can_login()
    
    /** @test */
    public function logged_in_user_can_logout()
    {
        // Kita memiliki 1 user terdaftar

        // Login sebagai user tersebut

        // Kunjungi halaman '/home'

        // Buat post request ke url '/logout'

        // Kunjungi (lagi) halaman '/home'

        // User ter-redirect ke halaman '/login'
    }
}

Lanjut, kita buat testing scriptnya.

<?php

// ...

class LoginTest extends TestCase
{
    // ... registered_user_can_login()
    
    /** @test */
    public function logged_in_user_can_logout()
    {
        // Kita memiliki 1 user terdaftar
        $user = factory(User::class)->create([
            'email'    => 'username@example.net',
            'password' => bcrypt('secret'),
        ]);

        // Login sebagai user tersebut
        $this->actingAs($user);

        // Kunjungi halaman '/home'
        $this->visit('/home');

        // Buat post request ke url '/logout'
        $this->post('/logout');

        // Kunjungi (lagi) halaman '/home'
        $this->visit('/home');

        // User ter-redirect ke halaman '/login'
        $this->seePageIs('/login');
    }
}

Simpan, kemudian jalankan PHPUnit.

# 3
$ vendor/bin/phpunit

Hasil: Passed

{:style=“width:100%”}

Selesai sampai di sini misi kita.

Kesimpulan

Mungkin ada yang bertanya, mengapa testing untuk fitur login dan logout ini perlu dilakukan? Bukankah fitur login bawaan laravel ini sudah handal dan teruji? Well, testing ini lebih bertujuan sebagai backup kita (developer) jika ada kebijakan baru. Kita tidak tahu jika aplikasi web kita kedepannya mengalami perubahan kebijakan, misalnya:

User boleh login dengan username atau email, atau
User yang bisa login, akun harus diaktifkan melalui email dulu, atau
Ada fitur suspend user di dalam sistem, jika user berstatus suspend, maka dia tidak dapat login, atau
Login sebagai tipe user tertentu akan ter-redirect ke halaman yang berbeda dengan user tipe lain, atau
Setelah user login, ada flash message untuk user : “Selamat datang kembali, John Thor”.

Atau berbagai macam perubahan kebijakan lain terkait urusan login user. Dengan adanya automated testing pada fitur ini, kita dapat dengan mudah menyesuaikan aplikasi/sistem dengan kebijakan baru.

Semua kode yang telah kita kerjakan pada artikel ini, bisa teman-teman lihat di pada file LoginTest.php ini.

Demikian teman-teman terima kasih atas waktunya, semoga bermanfaat.

Cara Membeli Aplikasi Android di Playstore dengan Pulsa XL

Sun, 04 Nov 2018 10:00:00 +0800

Bismillahirrahmanirrahim.

Pagi ini saya membeli sebuah aplikasi android dari playstore dengan cara potong pulsa XL. Alhamdulillah berhasil. Saya membeli aplikasi Smart Keyboard Pro seharga Rp. 28.000,- dengan biaya tambahan sekitar 12%, pulsa terpotong total Rp. 31.360,-.

Baik, saya share tahapan cara belanjanya.

Pada Playstore, buka detail aplikasi yang ingin dibeli. Misal beli aplikasi Smart Keyboard Pro.
Klik tombol hijau “IDR 28,000” (ini harga aplikasinya).
Di bahwa judul aplikasi, ada metode pembayaran, klik (touch) agar muncul pilihan metode pembayaran lain.
Pilih “Payment Methods”.
Pilih “Use XL/Axis billing”.
Baca aturan pakai, jika ingin tahu. Yang jelas informasinya, ada charge/tarif yang dikenakan oleh operator pada proses pembayaran ini.
Tekan “Buy”, setelah ini mungkin kita akan diminta masukkan password akun google/gmail kita, sebagai konfirmasi bahwa kita ingin membayar.
Setelah Payment successful, tampil halaman konfirmasi “Require authentication for purcases?”. Pilih “YES, ALWAYS”. Agar kita selalu diminta masukkan password saat akan melakukan pembelian/ pembayaran di playstore. Ini untuk menghindari pembelian yang tidak disengaja.
Payment successful, installation in prgress, klik “Continue”. Proses install ke handset android kita.
Selesai. Kita akan menerima SMS dan email masuk sebagai resi pembayaran.

Baik, begitu cara mudah membeli aplikasi android di playstore dengan cara potong pulsa. Sampai artikel ini ditulis, ada 4 operator telekomunikasi di Indonesia yang menyediakan layanan bayar playstore dengan potong pulsa ini. Bisa dilihat detailnya di sini.

Demikian teman-teman, semoga bermanfaat. Terima kasih.

Ketika Masa GCP Free Trial Habis (12 Bulan)

Mon, 29 Oct 2018 07:30:00 +0800

Bismillahirrahmanirrahim.

Alhamdulillah saya 12 bulan menggunakan Google Cloud Platform (GCP) Free Trial adalah pengalaman yang mengasikkan dan rezeki yang besar untuk saya secara pribadi. Pada tulisan ini, saya akan berbagi pengalaman ketika masa Free Trial GCP akan dan telah habis.

Manfaat yang saya dapatkan

Apa saja manfaat dan pengalaman yang saya dapatkan dari layanan GCP Free Trial ini? Ini beberapa hal yang menurut saya penting:

Satu VM Instance (VPS) yang digunakan untuk website marketing saya dan juga blog ini.
Satu VM Instance yang digunakan untuk riset, demo project open-source, dan demo prototype aplikasi (project) untuk klien.
Beberapa kali deploy (dan destroy) Virtual Machine (VM) Instance untuk riset saat belajar install dan konfigurasi web server.
Semua didapatkan gratis sekitar 11 bulan (secara efektif).
Tidak ada charge ke kartu kredit.

Sekali lagi ini pengalaman yang sangat bermanfaat untuk saya pribadi.

Apa yang terjadi setelah 12 bulan?

Nah apa yang terjadi setelah 12 bulan Free Trial GCP ini habis? Secara umum teman-teman bisa membaca di Google Cloud Platform Free Tier FAQ ini. Tatapi saya akan saya ceritakan apa yang saya alami, sebagai gambaaran untuk tema-teman semua.

7 hari sebelum masa trial habis, kita akan mendapatkan email dari GCP sebagai reminder bahwa trial akan habis.
Ini kesempatan kita untuk melakukan backup dan download/migrasi semua website, database, demo project, konfigurasi DNS, dan file-file yang saya titipkan di VM Instance Google Cloud Engine (GCE).
Tepat tanggal Free Trial habis, kita akan mendapatkan email lagi dari GCP, bahwa masa trial habis.
Ketika free trial habis, kita sudah tidak bisa mengakses VM Instance kita lagi, termasuk yang “always free” (I’m sorry, good bye…).
Free Credit yang tersisa hangus, tidak dapat digunakan lagi.
Selama 12 bulan pemakaian GCP, sesuai dengan pernyataan GCP di FAQ-nya, mereka benar-benar konsisten, tidak melakukan charge ke kartu kredit, sampai kita upgrade billing ke akun berbayar.

Tips untuk pengguna GCE Free Trial yang masih aktif

Beberapa tips saya bisa berikan berdasarkan pengalaman saya menggunakan GCP ini.

Set reminder 1 bulan sebelum tanggal Free Trial expired, untuk antisipasi jika kita ingin pindah ke provider yang lain. Tanggal expired bisa dilihat di GCP Console, menu Billing.
Cari layanan VPS pengganti. Ada beberapa alternatif, akhirnya saya memilih Microsoft Azure.
Persiapkan checklist, apa saja yang perlu dibackup/dipindahkan dari GCE yang masih aktif. Untuk memastikan tidak ada yang tertinggal saat proses migrasi/proses backup. Untuk saya kemarin, checklistnya kurang lebih ini:
- Folder Project Web (tempat website dipasang).
- Folder konfigurasi sites-available nginx.
- Isi database MySQL dan PostgreSQL.
- Cloud DNS Entry tempat saya mengatur domain dan subdomain yang saya pasang di GCP.
- Folder repository git (bare) yang digunakan untuk git push langsung dari local PC langsung ke VM Instance.
- Semua folder di-zip dengan timestamp, misalnya: web_2018-08-29.064600.zip, config_site_nginx_2018-08-29.064600.zip, dan seterusnya.
Tutup/destroy VM-VM yang sudah tidak digunakan lagi, untuk minimalisir data tertinggal.
Jika layanan VPS pengganti sudah siap, lakukan migrasi paling lambat 7 hari sebelum free trial habis.
Pelajari cara transfer file antar server, untuk menghemat kuota internet (daripada kita download dulu dari GCE, lalu upload lagi ke VPS baru). Kalau saya kemarin menggunakan perintah scp untuk mengirim file ke server baru. Bisa lihat referensi di sini.

Note:
Tadinya saya berharap bahwa VM instance yang “Always Free” masih tetap dapat digunakan saat Free Trial habis, ternyata tidak bisa lagi. Semua layanan Always Free dapat diteruskan jika kita sudah upgrade billing. So, keep that in mind!

Penutup

Demikian teman-teman, semoga dengan artikel ini bermanfaat untuk teman-teman yang akan/sedang menggunakan Google Cloud Platform Free Account. Sebagai antisipasi ketika nanti masa trial akan habis. Jika teman-teman mengalami kendala baik teknikal atau billing/tagihan, bisa coba menghubungi Customer Support GCPnya, caranya bisa cek di artikel ini.

Bagi yang belum tahu bagaimana cara mendaftar dan mendapatkan Free Credit Google Cloud Platform ini, silakan baca-baca artikel ini.

Terima kasih atas waktunya.

MS Azure Free Account harus Upgrade Biling setelah 30 Hari

Sat, 27 Oct 2018 23:00:00 +0800

Bismillahirrahmanirrahim.

Perhatian!

Saya ingin menginformasikan kepada teman-teman yang sudah membaca tulisan saya tentang pindah layanan dari Google Cloud ke MS Azure. Bahwa 30 hari setelah mendaftar Microsoft Azure Free Account (masa free credit), saya mendapatkan email bahwa semua layanan free account dihentikan. Kebetulan saya membaca email ini setelah mendapat info dari pembaca blog ini, bahwa web tidak dapat diakses.

Layanan Stop setelah 30 Hari

Yap, diluar ekspektasi memang, setelah membaca aturan mainnya, ternyata layanan Free Account ini hanya berlaku 30 hari sejak pendaftaran (sesuai dengan masa berlaku Free Credit yang $200). Setelah itu harus upgrade billing ke layanan berbayar untuk terus menggunakan layanan MS Azure.

Virtual Machine atau VPS gratis selama 12 bulan (dan semua produk “always-free”) itu dihentikan, dan hanya dapat diteruskan setelah melakukan upgrade langganan ke “Bayar seperlunya” (Pay as you go).

Setelah membaca aturannya, langganan/billing “Pay as you go” ini artinya kartu kredit akan standby untuk dikenakan charge jika ada layanan berbayar yang digunakan. Wah, ngeri kan?

Dengan kondisi saya saat itu :

Semua sudah terlanjur pindah ke VPS di MS Azure.
Layanan 12 bulan VPS gratis (katanya) tetap dapat dinikmati.
Belum ada pilihan lain untuk mendapatkan VPS gratis.

Setelah membaca aturan main berulang-ulang dan mempertimbangkan resikonya, akhirnya saya putuskan untuk upgrade billing.

Upgrade ke Billing “Pay as you go”

Jika teman-teman ada yang mengalami hal yang sama, dan memutuskan untuk upgrade juga, begini caranya:

Buka email dari MS Azure perihal Upgrade Billing (gambar di atas), klik tombol/link “Upgrade Now”.
Login ke akun MS Azure (jika diperlukan). Kita akan masuk ke formulir Upgrade your subscription seperti di bawah ini.
Isikan field subscription friendly name, misal “Bayar seperlunya”.
Pada Add a support plan, pastikan kita memilih opsi terbawah “No technical support or I’m already covered Microsoft Premier Support”. (Agar tidak tidak terkena biaya layanan teknis perbulan).
Klik “Upgrade”.
Tunggu sampai muncul notifikasi Succcessfully upgraded subscription.

Sampai disini selesai proses upgrade billing ke “Pay as you go”. Selanjutnya kita aktifkan kembali Virtual Machine yang distop tadi:

Kembali ke dashboard
Buka halaman detail Virtual Machine yang disabled, melalui menu di samping, atau dari dashboard.
Klik tombol Start". tunggu sampai ada notifikasi: “Started virtual machine”.
Kunjungi lagi IP Address/domain dari VPS ini, seharusnya sudah aktif lagi.

Hal yang harus diperhatikan

Agar kartu kredit tidak dikenakan charge/biaya:

Monitor bandwidth (memastikan tidak ada kelebihan outbound data transfer dari jatah free account).
Memastikan tidak menggunakan layanan berbayar MS Azure.
Rajin mengunjungi halaman Cost Management + Billing untuk melihat dan memastikan Current Cost selalu nol.

Penutup

Ketika menulis artikel ini, terhitung sudah 1 bulan lebih saya upgrade ke billing “Pay as you go”. Alhamdulillah tidak ada charge pada kartu kredit dari Microsoft Azure, artinya pemakaian VPS masih di bawah batas layanan gratis 12 bulan. Semoga tetap terjaga agar tagihan selalu di angka nol.

Baik, demikian cerita saya menggunakan layanan Microsoft Azure Free Account (yang sudah tidak free lagi) ini. Terima kasih atas waktu teman-teman, semoga bermanfaat.

Cara Deploy Free Account Virtual Machine di MS Azure

Sun, 23 Sep 2018 21:12:00 +0800

Bismillahirrahmanirrahim.

Sebagaimana yang telah kita bahas di artikel sebelumnya, bahwa Free Account dari Microsoft Azure memberikan kita satu Virtual Machine atau VPS gratis selama 12 bulan. Kali ini saya ingin share ke teman-teman pembaca, tentang cara men-deploy sebuah Virtual Machine atau VPS tersebut. Tetapi sebelum mengikuti langkah-langkah di bawah, pastikan teman-teman sudah mendaftar di Microsoft Azure Free Account.

Untuk memulai kita harus login terlebih dahulu di Portal Microsoft Azure.

Kunjungi https://azure.microsoft.com
Klik Sign in.
Lanjutkan proses hingga masuk ke dashboard.

Langkah Deployment VM

Klik link Create a resource.
Pada kotak pencarian, cari “b1s”, lalu klik b1s pada hasil pencarian.
Muncul hasil pencariannya, kemudian klik link Free account virtual machine.
Pada kotak dialog Free account virtual machine, klik Create.
Pada subscription pilih Free Trial.
Resource group isikan nama grup secara bebas, contoh di saya : “grup-saya”
Tulis nama virtual machine/VPS yang diinginkan, misal: my-azure-vm, ini nama computer namenya.
Untuk region pilih yang terdekat dengan target audience website, saya di Indonesia, pilih Southeast Asia.
Pada Image, pilih operating sistem yang diinginkan, kalau saya pilih Ubuntu 16.04-LTS. Karena bisanya cuman ubuntu itu, xixi..
Size sudah pilihkan oleh webnya, 1 virtual CPU, RAM 1 GB.
Authentication type, jika mau langsung dengan SSH public key, silakan pilih, nanti kita diminta masukkan public key dari PC kita. Saya pilih dengan password dulu untuk mempermudah di awal.
Isikan username dan password yang digunakan untuk login ke VM/VPS nanti.
Pada Inbound Port Rules kita pilih 3 item:
- HTTP
- HTTPS
- SSH (22)
Inbound port source pilih Any IP Address, agar bisa login dari PC/laptop mana saja. Silakan pilih opsi lain kalau ingin disesuaikan dengan kebutuhan teman-teman.
Klik Review + create.
Selanjutnya kita diberi halaman verifikasi isian, kalau ada yang keliru silakan klik Previous. Tenang saja, tidak sakit kok, ini masih gratis.
Kalau sudah yakin dengan isiannya, klik Create untuk memulai proses deploy VM kita. (Prosesnya sekitar 3-5 menitan.)
Jika sudah dapat notifikasi Deployment succeeded, klik link Go to resource untuk melihat VM/VPS kita.

Pada detail VM ini, kita bisa melihat Public IP Address nya. Silakan teman-teman ping dari terminal untuk mengujinya.

Ping IP Address VM

Kalau Ping sukses, seharusnya kita sudah bisa login ke VM dengan SSH. Kita coba dengan username yang kita seting di point 12 tadi:

$ ssh username@ip-address
# masukkan password

Sip sudah. Jika berhasil login seperti di atas, berarti kita sudah berhasil deploy VM dari Free Account Microsoft Azure ini.

Cek Memory dan Disk Space

Masih dalam kondisi login SSH di VM, RAM/memory pada VM kita bisa cek dengan perintah:

$ free -m

Sedangkan Disk Space pada VM kita bisa cek dengan perintah:

$ df -h

Yap, kita dapat disk dengan space ~64GB.

Next Step

Setelah selesai deploy VM dengan langkah-langkah di atas, selanjutnya teman-teman bisa mengoperasikan/menggunakannya sesuai kebutuhan. Misalnya:

Install LEMP Stack dulu untuk web server.
Lalu Deploy Project Laravel, silakan coba project open-source Free-PMO ini untuk mempermudah mengelola project.
Mapping subdomain agar mengarah ke VM yang baru.

Alhamdulillah, cukup sampai di sini. Insyaallah kita akan bahas hal-hal lain lagi pada artikel berikutnya. Terima kasih atas waktu teman-teman.

Cara Mendaftar Microsoft Azure Free Account

Wed, 05 Sep 2018 13:15:00 +0800

Bismillahirrahmanirrahim.

Microsoft Azure adalah layanan cloud yang dimiliki oleh Microsoft. Mirip seperti Google Cloud Platform, Azure memiliki banyak layanan, salah satu di antaranya adalah Virtual Machines, atau biasa kita sebut Virtual Private Server (VPS).

Pada artikel sebelumnya, saya cerita tentang rencana pindah layanan VPS dari Google Cloud Platform karena masa trialnya sudah hampir habis. Alhamdulillah sekarang sudah mendaftar dan pindah ke Microsoft Azure ini. Nah, kali ini saya mau share ke teman-teman tentang bagaimana cara mendaftar Free Account di Microsoft Azure ini.

Perhatian!

Sebelum teman-teman mendaftar, saya informasikan bahwa Microsoft Azure Free Account hanya berlaku 30 hari sejak pendaftaran. Setelah itu kita harus upgrade ke layanan berbayar. Lihat detailnya pada artikel ini.

Syarat Mendaftar Microsoft Azure

Untuk mendaftar, syaratnya kita perlu :

Kartu Kredit yang masih berlaku.
Nomor Hape aktif.
Akun Microsoft/Live/Skype (bisa dibuat sekalian mendaftar Akun Azure).

Proses Mendaftar Microsoft Azure

Kunjungi link pendaftarannya: https://azure.microsoft.com/en-us/free, kemudian klik tombol Start free.
Kita akan menuju ke halaman login akun Microsoft. Silakan login ke akun Microsoft (atau buat akun jika belum ada).
Setelah login akun Microsoft, kita akan diarahkan ke halaman Azure free account sign up. Silakan isi Data Diri di sana.
Pada bagian Identity verification by phone, silakan isi nomor telepon/Hp., tekan Text me. Nanti akan dapat SMS berisi nomor verifikasi.
Isikan data kartu kredit yang akan digunakan pada bagian Identify verification by card.
Lanjutkan ke bagian Agreement sampai selesai.
Setelah berhasil mendaftar, kita mendapatkan halaman: You’re ready to start with Azure. Klik tombol Go to portal.
Tampil halaman Portal Microsoft Azure.

Sip, sampai di tahap ini kita sudah sukses mendaftar di Microsoft Azure Free Account.

Penutup

Sampai artikel ini ditulis, saya sudah mencoba men-deploy satu Virtual Machine (VPS), caranya agak berbeda dengan membuat VM Instance di Google Cloud Engine. Selanjutnya insyaallah kita akan bahas cara men-deploy Free Account Virtual Machine (VPS yang gratis).

Btw jika teman-teman ingin coba daftar ke Google Cloud Platform dan dapat Free Credit $300 selama 12 bulan, bisa cek artikel ini: Mendapatkan Free Credit USD 300 untuk Google Compute Engine. Lumayan bisa digunakan untuk kebutuhan riset selama 1 tahun.

Terima kasih atas waktu teman-teman, semoga bermanfaat.

Pindah dari Google Cloud Platform ke Microsoft Azure

Thu, 30 Aug 2018 21:15:00 +0800

Bismillahirrahmanirrahim.

Pada artikel terdahulu saya pernah cerita bahwa saya menggunakan layanan Google Cloud Engine sebagai server untuk blog ini, web JasaWebsiteBanjarmasin.com, beberapa project riset dan demo project untuk klien.

Waktu itu sudah 5 bulan saya menggunakan layanan Google Cloud Engine. Sekarang, layanan itu sudah hampir habis, sudah hampir 12 bulan saya menggunakannya. Jika diteruskan, biaya perbulan untuk 1 VM Instance cukup menguras kantong ($19.63 atau Rp. 295.000 per bulan), jadi saya putuskan untuk mencari layanan lain yang menyediakan VPS murah, atau gratis 12 bulan juga, hehe…

Btw, per hari ini, ketika artikel ini ditulis, saya punya waktu sekitar 1 minggu untuk melakukan migrasi ke layanan yang baru.

Alternatif Penyedia Server

Setelah googling, saya mendapatkan 2 provider yang memiliki layanan Free Trial 12 bulan:

Microsoft Azure Free Account (info dan FAQ).
Amazone Web Services Free Tier (info dan FAQ).

Teman-teman bisa lihat informasi dan FAQ di kedua penyedia server itu. Keduanya memiliki Data Center Singapore, dekat dari Indonesia dengan latency rata-rata 70 ms.

Pilihan Penyedia Server

Setelah mempelajari info dan FAQ dari kedua layanan tersebut, saya memilih untuk mencoba Microsoft Azure Free Account. Kenapa? Karena FAQnya lebih mudah saya pahami, dan ada lumayan banyak layanan always free yang mungkin bisa saya manfaatkan suatu hari nanti.

Spesifikasi Mesin Virtual (VPS)

Di screenshot FAQ MS Azure ini, ada 750 hours of Azure B1S General Purpose Virtual Machines for Linux yang free 12 bulan. Setelah saya cek, di free account ini kita akan dapat virtual server dengan spesifikasi :

CPU: 1 virtual CPU
RAM: 1 GB
DISK: SSD 64 GB
Bandwidth: outbound 15 GB per bulan, inbound unlimited.
Operating System: Ubuntu Server 16.04.5 LTS
(Sampai artikel ini ditulis, belum tersedia Ubuntu 18.04 LTS.)

Lumayan ya. Dengan spesifikasi itu, insyaallah cukup untuk kebutuhan saya saat ini. Sebagai perbandingan, di Google Cloud Platform saya menggunakan VM Instance jenis:
g1-small (1 vCPU, RAM 1.7 GB).

Baik, sampai disitu dulu cerita rencana saya untuk pindah layanan VPS. Pada artikel berikutnya, insya Allah saya lanjutkan dengan menulis cara mendaftar ke Microsoft Azure Free Account. Stay tuned…

Terima kasih.

Cara Install Wordpress dengan WP-CLI

Tue, 28 Aug 2018 10:00:00 +0800

Bismillahirrahmanirrahim.

Kali ini kita akan bermain dengan command-line tool untuk menginstall CMS Wordpress, yaitu WP-CLI (wordpress command-line interface). Bagi yang sudah terbiasa bekerja dengan terminal, WP-CLI ini sangat membantu untuk mempercepat proses installasi wordpress.

Install WP-CLI

Requirement

Untuk dapat menggunakan dan menginstall WP-CLI, ada beberapa requirement yang harus dipenuhi :

Lingkungan UNIX-like ( X, Linux, FreeBSD, Cygwin). Menurut websitenya, lingkungan windows masih kurang disupport. Di sini saya menggunakan Ubuntu 16.04.
Bisa perintah curl atau wget.
Versi PHP minimal 5.4.

Cara Install

Proses install WP-CLI, kita bisa jalankan perintah berikut :

# Download dengan curl (bebas di direktori mana saja)
$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

# Cek hasil install
$ php wp-cli.phar --info

# Berikan permission untuk eksekusi wp-cli
$ chmod +x wp-cli.phar

# Pindahkan file ke direktori `/usr/local/bin` dengan nama file `wp`
$ sudo mv wp-cli.phar /usr/local/bin/wp

# Cek hasil install lagi
$ wp --info
PHP binary: /usr/bin/php7.2
PHP version:    7.2.7-1+ubuntu16.04.1+deb.sury.org+1
php.ini used:   /etc/php/7.2/cli/php.ini
WP-CLI root dir:    phar://wp-cli.phar
WP-CLI vendor dir:  phar://wp-cli.phar/vendor
WP_CLI phar path:   /home/nafies
WP-CLI packages dir:    
WP-CLI global config:   
WP-CLI project config:  
WP-CLI version: 1.3.0

Jika sudah tampil seperti di atas, berarti proses install WP-CLI dan selesai berhasil.

Install Wordpress dengan WP-CLI

Untuk proses installasi wordpress dengan WP-CLI, kita lakukan langkah-langkah berikut

Membuat Database Baru di MySQL

Kita buat database baru dengan perintah mysqladmin

$ mysqladmin -urootuser -p create wp_2018_test
Enter password: # masukkan password user mysql

Buat Direktori Wordpress

Buat satu direktori/folder (misal wp-test) sesuai dengan document root web server kita, baik di XAMPP, LAMP atau LEMP. Untuk kasus saya, document root apache ada di ~/www.

$ mkdir wp-test
$ cd wp-test

Install Wordpress

Jalankan perintah WP-CLI untuk mulai menginstall wordress.

# Download wordpress file
$ wp core download

# Buat file `wp-config.php`
$ wp config create --dbname=wp_2018_test --dbuser=rootuser --prompt=dbpass --dbprefix=test_
# --dbname adalah nama database yang kita buat untuk wordpress di atas.
# --dbuser adalah username MySQL yang kita gunakan untuk wordpress ini.
# --prompt=dbpass adalah perintah untuk memasukkan password user MySQL (agar tidak masuk cli history).
# --dbprefix adalah prefix table-tabel wordpress di database.

# Install wordpress dan set admin user.
$ wp core install --url=http://localhost/wp-test --title="My Wordpress Website" --admin_user=web_manager --prompt=admin_password --admin_email=info@example.net --skip-email
# --url adalah domain atau URL untuk website wordpressnya, bisa juga langsung gunakan domain.
# --title adalah judul website wordpress.
# --admin_user adalah username untuk administrator website.
# --prompt=admin_password adalah perintah untuk memasukkan password user admin wordpress (agar tidak masuk cli history).
# --admin_email adalah alamat email user administrator website.
# --skip-email ditambahkan agar server tidak mengirimkan data akun dan profil user admin melalui email.

Disini kita menggunakan perintah wp core dan wp-config, teman-teman bisa melihat dokumentasi perintah ini di websitenya : wp core dan wp config.

Sampai di sini proses install wordpress sudah selesai. Sekarang kita bisa coba kunjugi URL wordpressnya melalui browser. Untuk kasus saya, saya akan mengunjungi URL:

http://localhost/wp-test

Untuk login admin area, dapat dikunjungi seperti biasa, dengan ditambahkan /wp-admin:

http://localhost/wp-test/wp-admin

Kesimpulan

Baik sampai di situ selesai tutorial cara install wordpress dengan wp-cli. Beberapa hal yang bisa saya simpulkan dari cara installasi ini.

Cara install ini hanya salah satu dari sekian banyak cara menginstall wordpress ke localhost.
Menurut saya pribadi, dengan cara ini proses installasi wordpress menjadi ringkas dan cepat.
Selain di localhost, cara install dengan CLI ini dapat juga diterapkan jika kita menggunakan server online (VPS). Tetapi tidak dapat digunakan di shared hosting.
Kita bisa menggunakan WP-CLI untuk mengelola theme, plugin, user, media, option, dan banyak lagi, hanya melalui perintah terminal.
List perintah WP-CLI dapat dilihat di dokumentasinya.

Alhamdulillah, semoga tulisan ini bermanfaat. Terima kasih atas waktu teman-teman sudah membaca.

Mengatur Environment Variable pada POSTMAN

Thu, 31 May 2018 11:20:00 +0800

Bismillahirrahmanirrahim.

Ketika kita mengembangkan API Endpoint untuk dikonsumsi berbagai platform sistem, salah satu alat bantunya adalah POSTMAN. POSTMAN adalah alat bantu untuk menguji hasil atau output dari API Endpoint dari sebuah server back-end. Baik Endpoint tersebut berasal dari localhost (saat development), maupun di server online.

Jika kita ingin menguji endpoint-endpoint API yang sudah dibuat, kita harus mengisi URL yang sesuai dengan lingkungan server yang diuji, yaitu di localhost dan di server online. Misalnya di localhost base URLnya: http://localhost/dompet/public, sedangkan di server online, pasti base URLnya berbeda, misalnya: http://dompet.nafies.id.

Ketika tahap development kita tes endpoint di localhost, dengan URL localhost, ketika tes endpoint di server online, kita ubah URL nya jadi domain di server online. Ketika lanjut development, URL domain server online diubah lagi menjadi localhost.

Kalau hanya 1 atau 5 endpoint saja tidak masalah kita gonta-ganti URL seperti itu. Tapi kalau endpointnya ada 20 bagaimana? Kalau ada 50 endpoint bagaimana? Apakah harus mengganti semua URL? Atau sebagai alternatif, kita buat endpoint duplikat, yang satu untuk locahost yang satu untuk online? Apakah begitu? Ternyata tidak perlu. Ada satu fitur di POSTMAN yang bernama Environment.

Fitur Environment

Fitur Environment ini dapat kita gunakan untuk membuat variabel dengan nilai yang berbeda sesuai dengan lingkungan (environment) yang ingin diuji coba. Manfaatnya, kita tidak repot lagi mengganti-ganti URL atau nilai-nilai apapun untuk menguji API endpoint yang ada di localhost dan server online.

Membuat Environment Variable

Langsung saja, misal kita perlu uji coba project Dompet pada dua lingkungan server, localhost dan server online. Maka kita membuat dua environment :

dompet-local, yaitu environment untuk mencoba API di localhost.
dompet-staging, yaitu environment untuk mencoba API di server staging (atau server demo).

Dari dua environment itu, kita akan membuat variabel dan nilai sesuai dengan pengaturan masing-masing server. Caranya :

Klik tombol elips disamping environment, lalu klik Add
Isi nama environment (misal: dompet-local)
Isi nama variabel dan nilainya (misal: base_url = http://localhost/lv/2018/dompet/public)
Tambah nama variable dan nilainya sesuai kebutuhan
Klik Add
Environment pertama (dompet-local) sudah jadi
Klik Add (jika masih berada pada tampilan Manage Environments)
Ulangi langkah dari nomor 2 sampai 5 untuk environment kedua
- nama environment = dompet-staging
- variabel base_url = http://dompet.nafies.id
Environment kedua (dompet-staging) sudah jadi

Mengunakan Environment Variable

Untuk menggunakan environment variable yang sudah kita atur tadi, masukkan nama variabel dengan kode {% raw" >}}{{nama_variabel}}{% endraw" >}}, contoh:

Untuk menggunakan variabel base_url pada endpoint URL, kita tambahkan variabel seperti ini
{% raw" >}}{{base_url}}/api/transactions{% endraw" >}}
Pilih Environment yang kita ingin gunakan.
Untuk menggunakan variabel pada Request Header dan Request Body, caranya juga sama.

Kesimpulan

Dengan bantuan fitur environment ini kita lebih mudah untuk menguji endpoint-endpoint yang ada pada aplikasi yang kita buat di beberapa lingkungan server yang berbeda.
Tidak ada batasan jumlah environment, sehingga kita bisa membuat sesuai kebutuhan, misalnya:
- dompet-local (untuk development di locahost)
- dompet-staging (untuk ujicoba pra-produksi)
- dompet-production (untuk server produksi)
- dompet-demo (untuk server demo)

Demikian cara mengatur environment variable pada aplikasi POSTMAN, terima kasih.

Referensi Bacaan

http://blog.getpostman.com/2014/02/20/using-variables-inside-postman-and-collection-runner

Mempersiapkan Calon Project untuk Calon Klien Baru

Sun, 27 May 2018 10:40:00 +0800

Bismillahirrahmanirrahim.

Ketika ada orang yang menghubungi untuk diskusi tentang rencana atau konsepnya sebuah project pembuatan web, tentu ini hal yang menyenangkan. Karena ada potensi ini menjadi pekerjaan, artinya potensi rejeki baru. Maklum, karena sebagai freelancer, saya bekerja dari satu project ke project yang lain, seperti yang sempat dibahas di artikel sebelumnya.

Nah, bagaimana cara yang saya terapkan untuk memperbesar kemungkinan agar calon klien ini mempercayakan pekerjaan kepada saya? Di artikel ini kita akan bahas beberapa tahap yang biasa saya lakukan untuk mem-follow up seorang calon klien :

Tahap Kontak Awal
Tahap sebelum Bertemu Calon Klien
Tahap Pertemuan dengan Calon klien
Tahap Setelah Pertemuan dengan Calon Klien
Proses Pengajuan Anggaran Project

Sebagai catatan, hal-hal yang kita bahas di sini adalah untuk jenis pekerjaan freelance web developer. Untuk pekerjaan freelance jenis lainnya mungkin sedikit berbeda.

Baik kita bahas satu persatu.

1. Tahap Kontak Awal

Ini adalah pada saat kita dihubungi oleh calon klien, baik melalui telepon atau chat, di mana beliau menyampaikan secara umum tentang project yang beliau rencakankan. Biasanya tahap ini hanya berupa diskusi singkat 10-15 menit. Pada saat ini, yang saya biasa lakukan adalah :

Mencatat point pembiacaraan

Buat catatan, baik ditulis tangan, atau notepad di PC/Laptop, terkait point-point pembicaraan saat diskusi singkat ini. Catat yang menurut kita penting untuk diketahui lebih lanjut ketika bertemu dengan beliau.

Ajak bertemu untuk diskusi lebih detail

Yap, tentu saja tidak cukup berbicara di telepon atau chat. Buat janji dengan calon klien bertemu untuk pembicaraan lebih detail. Agar kita memahami lebih dalam tentang konsep dan rencana projectnya.

2. Tahap sebelum Bertemu Calon Klien

Setelah selesai diskusi singkat tadi, kita lakukan beberapa hal berikut sebagai bekal atau persiapan bertemu dengan calon klien.

Cari informasi seputar topik project

Misalnya ada klien dari perusahaan rental kendaraan minta buatkan software transaksi sewa dan pengelolaan kendaraan. Nah kita bisa “googling” dulu seputar software manajemen rental kendaraan. Tidak usah banyak-banyak, setidaknya kita tahu sedikit seputar topik itu, jadi tidak “blank” ketika diskusi dengan klien.

Atau jika klien sudah punya website profil perusahaan, bisa lihat-lihat sekilas di sana.

Kenapa mesti mencari informasi ini? Karena beberapa project yang datang, umumnya berupa hal baru yang belum pernah kita kerjakan sebelumnya. Akan menjadi nilai plus di mata calon klien, jika kita mengetahui seputar topik project yang akan dikerjakan (setidaknya pengetahuan secara umum saja).

Buat list pertanyaan seputar project

Setelah kita punya catatan kecil dari hasil diskusi awal dan sudah mencari informasi seputar topik project tersebut, pasti akan muncul pertanyaan-pertanyaan untuk menggali informasi lebih detail. Kita buat list pertanyaan tertulis juga, beberapa misalnya :

Apa tujuan dan manfaat software ini untuk perusahaan?
Apa kendala-kendala yang dihadapi saat ini (sehingga membutuhkan bantuan software)?
Alat bantu apa saja yang digunakan saat ini? (Boleh jadi ada software yang sudah digunakan, tetapi dinilai belum maksimal).
Bagaimana proses bisnis yang berjalan di perusahaan ini (dari awal hingga selesai)?
Siapa saja (tipe user) yang akan menggunakan software nanti?
Apa saja hak akses masing-masing jenis user?

Itu list pertanyaan yang biasanya saya siapkan sebelum bertemu calon klien. Dari 6 pertanyaan tersebut akan berkembang ke pertanyaan lain agar kita mendapat info lebih detail.

3. Tahap Pertemuan dengan Calon klien

Oke dari persiapan di atas, saatnya kita bertemu dengan klien.

DATANG ONTIME

Nah, maaf ini hurufnya saya kapital semua, DATANG ONTIME. Misal janjian bertemu hari Senin jam 10.00. Maka kita harus datang tepat waktu, selambatnya 5 menit sebelum waktu yang dijanjikan. Kenapa penting? Karena ini adalah kesan pertama antara kita dan klien. Ada 2 hal yang penting di sini :

Klien melihat keseriusan kita dalam hal waktu.
Kita juga melihat keseriusan klien dalam hal waktu.

Jika kita yang terlambat, klien bisa menilai mungkin nanti progress kerja kita juga akan terlambat. Sebaliknya, jika klien yang terlambat, kita bisa menilai mungkin nanti pembayaran juga bisa terlambat.

Walaupun ini tidak selalu dan bukan penilaian yang obyektif (namanya juga “mungkin”), tetapi ada kecenderungan itu akan terjadi. Itu sih pengalaman saya, hehe…

Saat Diskusi dengan Calon Klien

Ketika bertemu dan mulai diskusi, biasanya saya lakukan hal-hal berikut :

Catat hal-hal yang menurut klien penting (manfaat yang diharapkan dan kesulitan yang terjadi saat ini).
Pastikan daftar pertanyaan yang sudah dibuat tadi terjawab semuanya.
Minta contoh formulir yang saat ini digunakan.
Minta contoh laporan yang saat ini digunakan dan bagaimana laporan yang diharapkan pada software nantinya.

Tips Saat Diskusi

Sedikit tips untuk agar diskusi berjalan lancar :

Silent handphone (agar tidak mengganggu ada yang berbicara).
Bicara dengan sopan.
Hindari istilah-istilah teknis yang sulit dihapami klien (tidak perlu terlihat intelek).
Perhatikan dengan serius ketika klien berbicara/bercerita (usahakan tidak memotong pembicaraan).
Ukur kemampuan kita terhadap permintaan klien.
Jangan malu menyampaikan “saya belum bisa” jika memang skill/ilmu kita belum cukup. Klien lebih senang dengan kejujuran daripada kepintaran kita.
Jangan menjanjikan hal-hal yang tidak bisa kita penuhi (tentang item pekerjaan dan waktu).

Selesai Diskusi

Biasanya selesai diskusi, calon klien itu bertanya kisaran biaya dan waktu pengerjaan project. Saran saya :

Sampaikan bahwa anggaran/biaya dan waktu diajukan setelah analisis kebutuhan sistem.
Jangan sebutkan anggaran/biaya pada pertemuan pertama (apalagi deal, jangan). Karena kita di pertemuan awal ini, kita belum tahu persis apa saja yang mesti dikerjakan nanti. Mungkin bagi freelancer profesional, atau sudah punya jam terbang tinggi memang langsung bisa estimasi biaya. Kalau saya pribadi belum bisa. Takut salah hitung. :)
Minta waktu untuk analisis requirement.
Yap, kita butuh waktu untuk menganalisis kebutuhan klien ini, terutama jika proses bisnis yang akan dibuat ini lumayan panjang. Kalau saya biasanya setidaknya perlu waktu 1 minggu, maksimal 2 minggu. Kalau lebih dari 2 minggu terlalu lama klien menunggu.

4. Tahap Setelah Pertemuan dengan Calon Klien

Oke, setelah diberi waktu untuk analisis kebutuhan project, kita manfaatkan untuk membuat konsep secara tertulis. Bagaimana bentuknya, ini agak panjang pembahasannya, insyaallah kita akan bahas pada artikel lain. Tetapi secara umum, ini yang biasa saya lakukan untuk menindak lanjuti hasil pertemuan tadi :

Buat rangkuman diskusi/konsep secara tertulis dari hasil pertemuan pertama.
Kirim rangkuman diskusi kepada klien untuk di-review.
Minta tanggapan atau koreksi dari klien jika rangkuman diskusi tersebut ada yang keliru.
Bisa saja kita salah memahami cerita dari klien, bisa juga ada yang ditambahkan oleh klien karena lupa disampaikan waktu pertemuan pertama.

Rangkuman diskusi/konsep itu, harus sesuai dengan rencana/harapan klien. Karena itu akan menjadi acuan kita dalam membuat list item pekerjaan dan pengajuan anggaran biaya project. Artinya konsep itu harus disepakati bersama (antara kita dan klien).

Untuk memastikan konsep ini benar, biasanya saya lakukan pertemuan kedua atau ketiga dengan klien, sampai konsep pas dengan keinginan klien dan disepakat bersama.

Perlu diingat, konsep disepakati, belum tentu pengajuan biaya juga disepakati.

5. Proses Pengajuan Anggaran Project

Setelah konsep jadi, selanjutnya bagaimana? Ini beberapa hal yang biasa saya lakukan:

Buat list fitur/item pekerjaan

List fitur atau item pekerjaan ini adalah item-item yang akan dikerjakan dalam pengembangan software sesuai dengan konsep tadi. List fitur ini yang akan dibuat pengajuan biaya.

Kok perlu buat list fitur lagi? Bukanya sudah buat konsep tertulis? Apakah konsep tertulis itu berbeda dengan fitur di softwarenya? Yap, tentu beda. Konsep tertulis yang disepakati tadi itu baru konsepnya, sedangkan list fitur itu adalah item-item yang akan kita kerjakan atau kita develop untuk software.

Pengajuan anggaran biaya dan waktu berdasarkan fitur/list pekerjaan

Dari list fitur atau item pekerjaan ini, kita membuat pengajuan biaya berdasarkan tingkat kesulitan fitur aplikasi yang dibuat. Jika pekerjaannya rumit biayanya tinggi, sebaliknya, jika pekerjaan ringan, biayanya juga ringan.

Ini misalnya, ada 6 fitur/item pekerjaan :

Fitur autentikasi Rp. 500.000
Fitur entry data Rp. 700.000
Fitur proses data dari A ke C Rp. 300.000
Fitur proses data dari C ke E Rp. 1.000.000
Fitur manajemen user Rp. 300.000
Fitur report/laporan Rp. 1.200.000

Total: Rp. 4.000.000.

Jadi nanti total biaya project itu berdasarkan jumlah fitur dan tingkat kerumitannya masing-masing. Dengan cara ini, ketika calon klien disodorkan pengajuan Rp. 4.000.000, beliau jadi tahu apa saja yang akan didapatkan dari nilai itu. Sehingga pengajuan anggaran biaya dari kita akan masuk akal bagi calon klien.

Dari list pengerjaan dan biaya itu kita dapat mengukur berapa lama project ini akan dikerjakan. Mungkin kita perlu bahas lebih detail tentang penyusunan anggaran dan waktu pada artikel tersendiri, karena agak panjang.

Diskon Harga Minim

Karena kita sudah membuat rincian item pekerjaan sesuai konsep yang disepakati sebelumnya, maka minim kemungkinan klien menawar/meminta diskon yang tinggi (misal sampai 50%). Kalaupun ada permintaan diskon, kita bisa pertahankan maksimal 10% dari biaya pengajuan.

Deal or Cancel

Baik, setelah proses yang panjang untuk diskusi, membuat konsep dan anggaran untuk project, kita akan sampai pada titik kesepakatan dengan calon klien ini.

Selama saya menerapkan cara ini dalam mempersiapkan project, kemungkinan yang besar hanya ada dua, yaitu : Sepakat atau Batal. Kalaupun ada diskon, alhamdulillah diskon yang disepakati tidak lebih dari 10% dari pengajuan.

Kesimpulan

Baiklah, kita simpulkan pembahasan kita tentang “Mempersiapkan Calon Project untuk Calon Klien Baru” ini.

Cara kita melayani saat mempersiapkan project akan menjadi point besar bagi klien untuk mempertimbangkan, apakah memberikan pekerjaan kepada kita atau tidak.
Klien menilai kita serius dalam bekerja jika kita tepat waktu dalam berjanji, dan membuat konsep tertulis untuk project beliau.
Kita juga bisa menilai keseriusan klien, selama proses persiapan project ini.
Sangat penting bagi programmer membuat list pekerjaan tertulis untuk disepakati bersama dengan klien. Ini untuk minimalisir perubahan kebijakan saat project berjalan dan minimalisir revisi (setelah project selesai) yang lumayan menyita waktu dan pikiran.
List pekerjaan tertulis akan mengamankan seorang programmer dalam batasan hak dan tanggung jawab yang harus dipenuhi, sehingga dapat bekerja fokus dan terencana.
Nilai project yang kita ajukan lengkap dengan rincian item pekerjaan akan mendapat penilaian yang berbeda dibandingkan nilai project yang diajukan tanpa rincian yang jelas.
Dengan ini kita belajar profesional dalam bekerja.
Urutan persiapan project :
Konsep –> List Item Pekerjaan –> Pengajuan Biaya –> Pengajuan Waktu –> Deal atau Batal.

Urutan persiapan project yang saya terapkan memang panjang, perlu waktu dan pikiran, tetapi manfaatnya juga besar untuk menghasil pelayanan lebih baik, insyaallah menjadikan testimoni yang baik dan menjadi sarana promosi yang efektif.

Tapi mungkin ada pertanyaan di benak teman-teman, kalau sudah mempersiapkan project sedemikan rupa, ternyata batal bagaimana? Nah ini menarik, insyaallah akan kita bahas di artikel lainnya. Semoga teman-teman tidak bosan membaca blog saya.

Terima kasih atas waktunya.

Kelebihan dan Konsekuensi Kerja Fulltime Freelance

Tue, 08 May 2018 00:00:00 +0800

Bismillahirrahmanirrahim.

Ketika ada orang yang bertanya kepada saya :

“Mas kerja di mana?”

Saya jawab “Saya kerja dirumah pak.”

Ditanya lagi “Wah kerja apa dirumah?”

Saya jawab lagi “Saya buat web dan program komputer pak. Saya programmer, freelance, pak.”

Terus kata bapaknya. “Wah freelance ya, kerja dirumah, enak bisa santai ngatur waktu sendiri, ga kena macet dan hujan panas di jalanan.”

Saya jawab “Iya pak, alhamdulillah. Bisa bantu isteri ke pasar dan ngangkat jemuran.”
Kemudian diskusi bisa berlanjut pendek atau panjang sesuai rasa penasaran Bapaknya.

Kebanyakan pada diskusi seperti itu, orang melihat seorang fulltime freelancer sebagai pekerjaan yang enak, pekerjaan yang diharapkan oleh semua orang.

Nah kali ini saya akan coba “nge-list” kelebihan dan konsekuensi jika kita bekerja freelance secara fulltime. Supaya teman-teman pembaca ada gambaran enaknya apa, dan konsekuensinya apa.

Di sini yang akan kita bahas adalah pekerjaan Freelance Web Developer yang saya jalani, mungkin ada beberapa perbedaan dengan jenis pekerjaan freelance lainnya. Mudah-mudahan perbedaannya tidak terlalu jauh.

Kelebihan Freelance Fulltime

1. Kebebasan mengelola waktu kerja

Ya, keuntungan utama nya adalah, kita “bebas” mengelola waktu kerja. Kapan mau kerja, kapan mau istirahat, kapan mau piknik, kita yang atur sendiri.

Tetapi perlu diingat, “bebas” disini bukan berarti jam kerja tidak teratur, suka-suka, kerja kapan mau dan kapan malas, bukan begitu. Waktu kerja itu harus dikelola, harus ada target progress, setidaknya kita ada perencanaan progress per minggu untuk setiap project yang dikerjakan, dan itu harus konsisten.

Pekerjaan seperti ini membuat dan mengharuskan kita mengelola waktu dengan baik, agar semua pekerjaan terlaksana sesuai rencana. Ada dua hal yang minimal kita terapkan dalam bekerja freelance :

Waktu kerja harian, setiap hari kita bekerja dari jam berapa sampai jam berapa.
Perencanaan/target progress per minggu, dalam mengerjakan project, kita harus punya target, setidaknya perminggu, pekerjaan bisa selesai on target atau bahkan lebih cepat dari target.

Insyaallah tentang pengelolaan waktu kerja, kita bisa bahas di artikel tersendiri nanti.

2. Dapat bekerja di mana saja

Pekerjaan seperti ini (fulltime freelancer) tidak mengharuskan kita bekerja di satu tempat yang tetap, bisa dirumah, di cafe (kata orang-orang), sewa tempat seperti co-working space, atau di mana saja selama bisa membuat kita fokus kerja dan terhubung internet.

Tetapi walaupun bebas kerja di mana saja, sebaiknya ada tempat kerja yang pasti. Misalnya di pojokan rumah kita punya meja kerja, atau ada kamar kerja sendiri. Jadi walaupun kita bisa kerja di mana saja, kita ada tempat kerja yang tetap.

Saran dari saya, buat tempat kerja senyaman mungkin. Atur tinggi meja yang pas. Jika ada rejeki yang cukup, beli kursi yang nyaman dan empuk, ada senderannya, seperti kursi direktur itu. Saya sendiri malah potong kaki meja agar tingginya pas dengan tempat duduk (istilah kerennya dibikin “ergonomis”). Intinya untuk membuat kita nyaman saat kerja, karena sebagian besar waktu kita seharian duduk di situ. :)

3. Membangun hubungan dengan klien

Pekerjaan Freelancer umumnya berhubungan langsung dengan klien (pemilik project). Ada banyak pengalaman positif yang kita dapatkan jika terhubung langsung dengan klien :

Mengetahui ide-ide baru, atau ide lama dengan konsep baru.
Mengetahui lebih jelas, tujuan dan manfaat project yang akan dikerjakan.
Melatih untuk komunikasi profesional, bekerja profesional, karena kita pasti dinilai langsung oleh klien.
Kemungkinan kerjasama jangka panjang.
Tahu karakter klien.

Jadi manfaat dari hubungan langsung dengan klien, kita tahu persis karakter orang yang memberi kita pekerjaan, dan klien juga tahu persis karakter orang yang membantu projectnya.

Perlu diingat, ini akan menjadi testimoni dari klien untuk kita, hubungan yang baik membuahkan hasil yang baik, hubungan kurang baik membuahkan hasil yang kurang baik.

Bagaimana cara membangun hubungan yang baik dengan klien? Insyaallah akan kita bahas pada artikel tersendiri.

4. Dapat memilih pekerjaan

Wah, “memilih pekerjaan?” Kedengarannya sedap ini. Yap, artinya kita misa memilih (menyanggupi) pekerjaan sesuai keinginan dan kemampuan kita. Ketika ada project yang telah kita diskusikan dengan klien, biasanya saya mempertimbangkan :

Apakah sesuai dengan kemampuan/skill yang saya miliki?
Apakah sesuai dengan kemampuan jadwal dan memenuhi target deadline klien?
Apakah sesuai dengan anggaran biaya klien?

Di sini kita berhak menentukan apakah kita lanjut atau tidak untuk mengerjakan project itu.

5. Melatih attitude sebagai “business owner”

Sama seperti pemilik usaha, sebagai freelancer kita berperan sebagai pemilik bisnis. Sehingga attitude atau prilaku kita harus sesuai selayaknya pemilik usaha. Siapapun yang berhubungan dengan kita, akan menilai kita.

Attitude kita dalam bekerja dan hubungan dengan klien akan kembali kepada kita.
Hal-hal yang positif dan negatif kembali kepada kita.
Attitude yang baik akan menghasilkan testimoni yang baik, juga sebaliknya.
Portfolio dan testimoni adalah hal yang penting untuk modal marketing.
Nasib dari bisnis dan pekerjaan kita akan ditentukan oleh attitude cara kita bekerja.

Pekerjaan ini juga melatih kita agar bertanggung jawab secara menyeluruh. Tanggung jawab memang konsekuensi dari semua jenis pekerjaan, tatapi sebagai freelancer, seluruh project menjadi tanggung jawab kita, diantaranya :

Administrasi Project (pengelolaan email, bukti pembayaran, bukti diskusi).
Mengerjakan progress pekerjaan.
Laporan Progress.
Penyelesaian pekerjaan.
Problem-problem dalam project.
Data-data penting/rahasia milik klien.

Semua jadi tanggung jawab kita. Ini menjadi latihan soft-skill yang sangat bagus untuk kita. Sekali lagi, nasib bisnis akan ditentukan oleh attitude cara kita bekerja. :)

6. Kesempatan, ruang dan waktu untuk berkembang terbuka lebar

Nah karena kita bekerja sendiri, tidak ada yang mengatur “kapan kita ngapain”. Mau berkembang atau tetap begitu-begitu saja, itu tergantung kemauan diri sendiri.

Kita bisa mengatur jadwal agar bisa mempelajari hal-hal yang baru. Saya biasa mengatur waktu untuk belajar hal baru, terutama hal-hal yang menurut saya penting untuk produktifitas kerja ke depan.

Tetapi perlu diingat, jangan jadikan klien sebagai “kelinci percobaan”. Misalnya kita baru belajar suatu bahasa pemrograman atau teknologi yang sedang “trend”, jangan langsung digunakan untuk project klien. Pastikan dulu teknologi itu efisien untuk project tersebut, baik dari sisi waktu pengerjaan, dan kemungkinan problem di kemudian hari. Jika sudah yakin, silakan diterapkan. Jika belum, gunakan yang sudah kita punya.

Konsekuensi Freelance Fulltime

1. Memulai dengan (relatif) sulit

Beberapa hal yang saya temui ketika memulai bekerja sebagai freelance web developer:

Semua solusi harus diupayakan sendiri, tidak bisa mengandalkan orang lain karena ini pekerjaan kita. Ketika ada problem, cari solusinya sendiri, ini tanggung jawab kita. Karena itu kita harus memastikan bahwa kita memilik skill yang cukup untuk target pekerjaan kita.
Setiap orang pasti pernah jadi “newbie”, karena kita belum ada pengalaman, belum tahu apa-apa tentang bekerja sendiri.
Tidak sedikit project dengan bayaran (relatif) rendah, lihat point kedua di atas. :)
Tidak setiap rencana akan berjalan sesuai target, terutama kali pertama. Lihat lagi point kedua, semua yang kita rencanakan bisa berantakan karena berbagai hal yang terjadi ketika project sedang dikerjakan.
Di awal kita harus fokus mengumpulkan portfolio dan testimoni.
Portfolio, bisa dibilang, pekerjaan yang bisa kita banggakan untuk ditunjukkan kepada calon klien.
Testimoni adalah bagaimana perasaan klien setelah kita mengerjakan projectnya. Apakah senang, biasa saja, atau suram?

Memang semua dimulai dengan relatif sulit, tetapi dari situ kita belajar :

Oh, Supaya tidak kejadian begini, caranya harus begini.
Oh, ternyata klien itu tidak suka kalau saya begini, berarti saya harus begitu.
Oh, sepertinya harus pakai cara ini biar efisien nih.

Cukup jelas ya? :D

2. Penghasilan tidak tetap

Pekerjaan fulltime frelancer adalah “based on demand”. Ketika ada order, maka ada pekerjaan, dan ada pemasukan. Ketika tidak ada order, maka tidak ada pekerjaan, dan tidak ada pemasukan. Jadi tidak ada tanggal tetap untuk gajian.

Jumlah penghasilan juga tidak tetap, nilai project itu kadang relatif besar, kadang relatif kecil, tergantung yang disepakati.

So, karena tidak ada slip gaji, jadinya sulit mengajukan kredit barang, hahaha..
Mau ajukan kredit laptop tidak bisa, ajukan kredit motor tidak bisa. Mesti pintar nabung agar bisa beli barang dengan tunai.

Yahh.. gitu lah.

3. Terkadang menghadapi klien yang sulit

Klien yang sulit itu kriterianya (menurut saya) :

Tidak mau paham kondisi sulit (bukan tidak paham ya, tapi tidak mau).
Suka menunda pembayaran.
“Rajin” tanya progress.

Tidak ada klien yang paket lengkap seperti itu, biasanya hanya salah satu saja per klien.

Kenapa “rajin” tanya progress itu (menurut saya) termasuk klien yang sulit, karena setiap awal kerja, saya biasanya buat kesepakatan frekuensi laporan progress, misalnya per minggu atau per 3 hari. Nah, kategori ini adalah klien yang suka tanya progress sebelum waktunya. :)

Bagaimanapun kondisinya, ketika sudah sepakat, kita harus konsekuen dengan kesepakatan. Sadari bahwa :

Tidak semua hal berjalan sesuai rencana.
Menjadi pelajaran dan modal kita pada project selanjutnya.
Kita tetap bertanggung jawab hingga project selesai.

Alhamdulillah sedikit sekali saya bekerja dengan klien yang sulit, karena sudah banyak dapat pelajaran sebelumnya. Sekali lagi kita sebagai freelancer berhak menentukan “lanjut” atau “tidak” untuk mengerjakan sebuah project. Silakan pertimbangkan sebelum menyanggupi pekerjaan. :)

4. Harus menolak pekerjaan ketika sedang padat

Kalau kita sudah dikenal orang, besar kemungkinan kita akan mendapat tawaran project, apalagi kalau dia (calon klien) dapat rekomendasi dari temannya yang sudah menggunakan jasa kita (ini pentingnya testimoni nih).

Jadi, ketika ada tawaran project datang, apa yang harus kita lakukan?

Diskusikan spesifikasi dan target waktu calon project baru.
Periksa jadwal dan target project yang berjalan.

Saran dari saya, jangan menerima pekerjaan diluar kemampuan kita, yaitu di sisi skill dan jadwal waktu. Jangan berani menumpuk pekerjaan jika kita belum disiplin waktu.

5. Kerja bergantung dengan Internet

Saya sering lihat orang-orang di media sosial mengeluhkan layanan penyedia internet. Sebagian besar pekerja freelance bergantung dengan internet. Termasuk saya, yang sangat mengandalkan internet untuk bekerja.

Apa saya lakukan untuk menanggulangi masalah internet?

Lakukan experimen beberapa layanan internet, terutama di tempat kerja kita yang tetap.
Pilih layanan internet yang tetap sesuai kemampuan. Jadi jangan mengandalkan yang harus gonta-ganti kartu, pilih satu yang tetap sesuai kemampuan.
Kategorikan item-item pekerjaan yang membutuhkan internet dan yang tidak memubutuhkan internet. Jadi ketika internet bermasalah, fokus kerjakan item yang tidak perlu internet.
Manfaatkan waktu luang dengan “piknik”. Kalau tidak ada yang bisa dikerjakan silakan piknik, dengan main game, atau nonton anime kesukaan. Yah, namanya ga bisa kerja, gimana dong? :)

6. Sering dikejar deadline

Nah ini yang sering dialami oleh freelancer, mepet deadline. :)

Cara meminimalisir kondisi “dikejar deadline” bagimana? Kuncinya disiplin, yaitu disiplin waktu dan laporan progress secara rutin sesuai kesepakatan. Jangan menyalahkan klien jika memberi deadline mepet (sejak awal), kalau memang kita tidak sanggup, jangan disepkati.

Apa saja hal yang sering menyebabkan kita dikejar deadline?

Bekerja tanpa jadwal yang jelas.
Keliru membuat jadwal.
Tidak disiplin melaporkan progress secara rutin.
Tidak disiplin dengan jadwal yang telah dibuat.
Project yang dikerjakan terlalu banyak (beberapa project dalam satu waktu).
Kondisi badan kurang fit/sakit.
Terlalu banyak “piknik”.

Tapi ada sisi positif yang kita ambil dari “dikejar deadline” ini, kita jadi tahu bahwa dikejar deadline itu tidak nyaman. Jadikan hal ini sebagai pelajaran untuk project selanjutnya. Artinya jangan diulangi lagi.

Kesimpulan

Oke, lumayan panjang lebar pembahasan kita, kesimpulannya :

Setiap pekerjaan ada plus minusnya, ada kenyamaman dan resikonya.
Apakah saya nyaman bekerja seperti sekarang? Alhamdulillah, seperti anggapan banyak orang, nyaman.
Kenapa di sini saya sebut kelebihan dan konsekuensi, bukan kelebihan dan kekurangan? Karena saya tidak melihat kekurangan dari pekerjaan saya sekarang.
Semua hal yang kurang baik yang saya dapatkan itu, sangat bermanfaat untuk saya pribadi agar bekerja lebih baik, lebih efisien, dan lebih aman. Jadi pelajaran.
Semua hal yang kita bahas diatas berdasarkan pengalaman yang saya temukan selama bekerja freelance.

Demikian teman-teman, semoga menjadi bahan bacaan yang bermanfaat, terima kasih atas waktunya.

Apakah Fulltime Freelancer itu?

Tue, 01 May 2018 14:20:00 +0800

Bismillahirrahmanirrahim.

Alhamdulillah hari ini tanggal 1 mei 2018, tepat 4 tahun saya bekerja sebagai fulltime freelancer, tepatnya freelance web developer.

Waktu yang lumayan lama dalam menjalani dunia freelancing, dan memang banyak sekali pelajaran yang saya dapatkan. Dari mulai menemui dan berbicara dengan klien, mengerjakan project dengan progress dan waktu yang efektif, mengelola project agar tidak dikejar deadline, belajar hal-hal yang baru untuk mendukung pekerjaan, dan mengatur keuangan agar kebutuhan keluarga tetap terpenuhi.

Pada artikel ini, dan insyaallah pada beberapa artikel kedepan, saya ingin berbagi cerita ke teman-teman seputar dunia freelance, setidaknya sejauh yang saya pahami dalam 4 tahun terakhir ini. Mungkin bisa menjadi salah satu rujukan bagi teman-teman yang ingin tahu tentang freelancing.

Nah pada tulisan ini, saya akan buat semacam tanya jawab, sesuai dengan pertanyaan-pertanyaan yang sering diajukan orang seputar pekerjaan freelance yang saya kerjakan.

1. Apa itu freelancing / freelance dan freelancer?

Freelance adalah sebuah pekerjaan yang dilakukan oleh seseorang dengan durasi waktu yang disepakati. Kalau kita lihat di kamus bahasa inggris, freelance artinya lepas atau bekerja lepas. Jadi biasanya orang bekerja freelance untuk mengisi waktu di sela sela kegiatan rutinnya.

Umumnya pekerjaan freelance itu, yaitu ketika kita diminta mengerjakan sesuatu dalam jangka waktu tertentu, kemudian dibayar, dan selesai pekerjaan sampai di situ. Di lain waktu, ada pekerjaan lagi, dibayar lagi, selesai lagi.

Jadi pekerjaan freelance ini memang pekerjaan yang tidak tentu/tidak tetap, tergantung permintaan orang lain (biasa disebut klien/client). Dan umumnya pekerjaan freelance membutuhkan skill/kebisaan tertentu sesuai pekerjaan yang ditawarkan.

2. Nah, apakah saat ini saya bekerja seperti itu?

Jawabnya: Ya. Saat ini saya bekerja sebagai freelance web developer. Saya membuat web untuk klien-klien sesuai kebutuhan mereka.

Web seperti apa? Macam2, ada yang web profil usaha, toko online, tetapi kebanyakan berupa web aplikasi untuk manajemen dalam perusahaan.

3. Apakah berarti pekerjaan saya mengerjakan web, lalu dibayar, lalu selesai, begitu?

Jawab: Ya, begitu.

Tetapi setiap project yang saya kerjakan tidak selalu untuk klien baru, malah yang saya kerjakan dalam 2 tahun terakhir berasal dari klien lama. Kebanyakan klien yang saya layani, mereka tidak cukup buat website atau aplikasi web sekali jadi. Biasanya mereka ada permintaan improvement/pengembangan dari web/sistem yang sudah dibuat di awal.

Tetapi model pekerjaannya ya seperti itu: diskusi, buat kesepakatan, kerjakan, dibayar, selesai. Lalu lanjutkan project berikutnya.

4. Sepertinya pekerjaan freelance ini hanya untuk programer ya?

Jawab: Tidak, banyak juga jenis pekerjaan yang lain, seperti :

Penulis (blogger, content writer, email marketing),
Designer (desainer web, desainer logo, desainer borsur),
Digital marketing (SEO website, Google Adwords, Facebook Ads),
Video animator dan editing,
Dan pekerjaan2 yang umumnya dapat dikerjakan per project.

Jadi di Indonesia cukup banyak orang yang bekerja freelance, bahkan ada situs-situs marketplace untuk pekerjaan freelance seperti projects.co.id, freelancer.co.id, dan yang di luar negeri juga ada upwork.com. Kebanyakan pekerjaan freelance itu adalah pekerjaan yang dibantu oleh komputer dan internet.

5. Itu Freelancer, lalu yang Fulltime Freelancer itu bagaimana?

Jawab: Nah biasanya, pekerjaan freelance ini dikerjakan oleh orang-orang yang sudah memiliki pekerjaan tetap. Kemudian untuk menambah penghasilan atau mengisi waktu senggang, mereka memanfaatkan skill yang mereka punya untuk bekerja freelance. Itu yang freelance, biasanya ada juga yang menyebutnya “Part-timer”.

Sedangkan Fulltime Freelancer itu, secara umum seperti ini :

Bekerja tanpa ikatan pada instansi/perusahaan, jadi bekerjanya sebagai personal, bukan sebagai karyawan/pegawai.
Bekerja sesuai project (atau kontak project), di mana ada kesepakatan target waktu, tahap pekerjaan, bagaimana pekerjaan dianggap selesai. Sehingga komitmen dan tanggung jawab pekerjaannya sesuai kesepakatan.
Mengelola waktu dan tempat kerja sendiri, di mana seorang fulltime freelancer mengatur jam kerja sendiri sesuai target waktu pengerjaan project, dan dapat bekerja di manapun.

Jadi saat ini saya tidak menjadi karyawan atau pegawai di sebuah perusahaan atau instansi, saya bekerja di rumah. Biasanya berkomunikasi dengan klien melalui chat, telepon, email, video call. Sesekali saya datang ke kantor klien untuk diskusi jika diperlukan.

Saya sering menganalogikan Freelancer ini seperti tukang bangunan. Di mana yang kita tahu, setiap tukang bangunan mereka memiliki skill sendiri-sendiri. Ada yang bisa bangun rumah, ada yang bisa bangun rumah kayu saja, ada yang bisa bangun rumah beton saja, ada yang spesialis bikin dapur, ada yang spesialis bikin kamar mandi, macam-macam kan ya?

Nah freelancer juga begitu, ada yang punya keahlian ini, keahlian itu, bisa bikin ini, spesialis bikin itu, masing-masing orang bisa memanfaatkan skill untuk mencari nafkah yang halal dan baik. :)

Penutup

Baik, 5 tanya jawab itu rasanya cukup untuk menjelaskan seperti apa itu freelancer dan fulltime freelancer. Insya Allah tulisan-tulisan berikutnya, saya bisa berbagi lagi seputar kelebihan dan konsekuensi bekerja freelance, bertemu dan komunikasi dengan calon klien, cara saya memulai, menjalankan dan melaporkan progress project, dan lain-lain.

Semoga bermanfaat, terima kasih atas waktu teman-teman.

Cara Deploy Project Laravel dari Github ke VPS Ubuntu Server

Mon, 23 Apr 2018 23:30:00 +0800

Bismillahirrahmanirrahim.

Kita lanjut seputar web server, yaitu cara men-deploy atau menginstall project Laravel dari Github ke VPS. Pada artikel ini, kita akan install project Free-PMO dan membatasi cakupan bahasan sebagai berikut:

Source Project di-clone langsung dari repository Free-PMO di github.
VPS dengan Ubuntu Server 16.04.
Menggunakan LEMP Stack (Nginx, MariaDB 10.2, dan PHP 7).
Database menggunakan MariaDB / MySQL.
Kita mengikuti petunjuk installasi yang ada pada readme project di github.

1. Install LEMP Stack

Baik kita mulai dengan ssh ke VPS.

$ ssh projectuser@35.198.238.82

Kemudian lakukan proses installasi LEMP Stack, yaitu Nginx, MariaDB/MySQL, dan PHP untuk Linux. Untuk menjaga agar posting ini fokus pada cara deploy project Laravel, cara install LEMP Stack bisa teman-teman cek di posting ini).

2. Clone Source Code dari Github

Baik, setelah LEMP Stack terinstall dengan benar, kita cd ke direktori tempat project akan kita deploy/install.

$ pwd
/home/projectuser
$ cd www

Kemudian kita clone source code dari Repository Free-PMO di github.

# Clone repo
$ git clone https://github.com/nafiesl/free-pmo.git

# Pindah ke direktori project
$ cd free-pmo

# Install dependensi
$ composer install

# Buat file .env
$ cp .env.example .env

# Generate APP_KEY
$ php artisan key:generate
Application key [base64:UPcKQ3i4arfBe5...] set successfully.

# Update permission untuk direktori storage
$ sudo chown www-data: -R storage

3. Buat Database dan Config di .env

Sekarang kita membuat database untuk melayani project Free-PMO.

$ mysqladmin -uusernamebaru -p create laravel_free_pmo

Catatan:
Pada potongan perintah -uusernamebaru, usernamebaru adalah username MySQL yang dgunakan untuk database laravel_free_pmo di project ini. Cek referensi.

Setelah itu kita buka file .env untuk input config database project ini. Misalnya kita menggunakan:

Nama Database: laravel_free_pmo
Username MySQL: homestead
Password user MySQL: supersecurepassword

$ vim .env # atau nano .env

# Ubah
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=supersecurepassword

# Menjadi
DB_DATABASE=laravel_free_pmo
DB_USERNAME=usernamebaru
DB_PASSWORD=secret

Simpan file .env kemudian jalankan artisan migrate untuk mengisi database:

$ php artisan migrate

Sip, proses installasi aplikasi web Free-PMO selesai sampai di sini.

4. Serverblock Nginx

Sekarang kita lakukan konfigurasi serverblock nginx agar melayani aplikasi web Free-PMO.

# Duplikat serverblock yang sudah ada
$ sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/free-pmo

# Edit serverblock baru
$ sudo vim /etc/nginx/sites-available/free-pmo

Silakan copy dan paste script serverblock berikut, kemudian sesuaikan dengan kondisi server teman-teman.

server {
        root /home/projectuser/www/free-pmo/public;
        index index.php index.html;
        server_name 35.198.238.82;
        location / {
                try_files $uri $uri/ /index.php?$query_string;
        }

        location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        }
        location ~ /\.ht {
                deny all;
        }
}

Hal yang harus teman-teman sesuaikan adalah :

root /home/projectuser/www/free-pmo/public;
Sesuaikan dengan absolute path direktori project di VPS.
server_name 35.198.238.82;
Disesuaikan dengan IP Address VPS atau domain dari VPS.
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
Disesuaikan dengan versi PHP di VPS.

Ok, jika sudah, silakan simpan, kemudian aktifkan serverblock.

# Symlink serverblock ke sites-enabled
$ sudo ln -s /etc/nginx/sites-available/free-pmo /etc/nginx/sites-enabled

# Test script serverblock
$ sudo nginx -t

# Reload nginx
$ sudo nginx -s reload

Sampai di sini selesai konfigurasi nginx.

Sekarang kita bisa coba kunjungi IP Address atau domain sesuai konfigurasi nginx teman-teman di atas. Misal: http://35.198.238.82.

Jika sudah tampil halaman login project Free-PMO, artinya proses deploy kita sudah berhasil.

6. (Optional) Formulir Install Free-PMO

Untuk dapat menggunakan Free-PMO, silakan teman-teman kunjungi route /app-install dari IP Address atau domain VPS kita: http://35.198.238.82/app-install

Isi formulir sesuai dengan data agency teman-teman, kemudian klik Install Free-PMO.

Done.

Kesimpulan

Dari proses deployment dan konfigurasi yang agak pajang di atas, kita tarik beberapa kesimpulan :

Proses di atas (langkah 1 s/d 5) berlaku untuk project Laravel secara umum.
Proses di atas berlaku untuk public repository, untuk private repository saya belum coba cara ini.
Jika ada commit baru di repo github Free-PMO (atau project manapun yang kita install), maka kita tinggal menjalankan perintah git pull origin master untuk mendapatkan update terbaru di VPS.
Proses yang sama (langkah 1 s/d 6) dapat dilakukan untuk menginstall aplikasi web Free-PMO di local PC/Laptop yang memiliki OS Ubuntu 16.04 dengan LEMP Stack web server.

Baik demikian pembahasan tentang Cara Deploy Project Laravel dari Github ke VPS Ubuntu Server 16.04. Terima kasih atas waktu teman-teman sudah membaca.

Jika teman-teman ingin mencoba aplikasi Free-PMO, silakan kunjungi demonya:

URL: http://free-pmo.nafies.id/login
Email: pmo_admin@mail.com
Password: secret

Akses Database MariaDB/MySQL VPS dengan Heidi SQL via SSH

Sun, 18 Mar 2018 08:30:00 +0800

Bismillahirrahmanirrahim.

Ketika kita deploy sebuah VPS, untuk mengoperasikan database dengan GUI, kita biasa menginstall PHPMyAdmin atau Adminer. Kalau kita terbiasa menggunakan MySQL Client di localhost, tentu rasanya jadi beda. Misal saya suka menggunakan Heidi SQL, kan enak kalau kita menggunakan Heidi SQL juga untuk mengelola database di VPS? Apakah bisa? Bisa. :D

Salah satu caranya menggunakan SSH Tunnel pada HeidiSQL dengan bantuann plink. Bisa dicek pada artikel How to connect to a MySQL database over a SSH tunnel with HeidiSQL ini.

Saya mendapatkan cara yang lebih mudah dari artikel ini: Connecting to MySQL via SSH. Setelah dicoba, ternyata lebih mudah.

SSH dengan Port Forward

Caranya, kita ssh ke server melalui terminal dengan menambahkan command option -L, seperti ini :

$ ssh projectuser@35.198.238.82 -L 3333:localhost:3306

Di mana :

projectuser adalah sudoer user pada VPS, bisa juga pakai root.
35.198.238.82 IP Address VPS, bisa juga menggunakan domain.
3333 adalah port localhost pada PC/Laptop kita, dan
3306 adalah port MySQL pada VPS.

Sekarang kita konfigurasi koneksinya di session manager HeidiSQL.

Konfigurasi Session HeidiSQL

Klik New untuk membuat session baru.
Isi nama session, misalnya my-vps
Isi Hostname / IP : 127.0.0.1
Isi User dan Password sesuai dengan username dan password MySQL pada VPS
(Optional) untuk mempermudah akses selanjutnya, simpan perintah SSH pada Comment
Simpan dengan tombol Save.
Klik Open untuk membuka koneksi database ke VPS.

Kalau kita sudah terhubung ke VPS melalui di terminal, dan konfigurasi session sudah benar, seharusnya kita berhasil terhubung ke database pada VPS kita. Tampil seperti ini.

Kesimpulan

Sip. Kita simpulkan pembahasan pada artikel ini. Cara koneksi MySQL via SSH dengan port forward :

(Saat ini saya rasa) adalah cara yang paling mudah.
Bergantung dari koneksi SSH di terminal, jika koneksi SSH terminal putus, maka koneksi di HeidiSQL juga akan putus.
Tidak hanya berlaku untuk HeidiSQL, tetapi bisa menggunakan MySQL Client yang lain juga.
Waktu respons saat kita bekerja dengan HeidiSQL di VPS tentu berbeda dengan pengoperasian database di localhost, tergantung dari latency dari PC/Laptop kita ke VPS.

Demikian teman-teman, terima kasih atas waktunya.

Sumber Bacaan

Install LEMP Stack pada Ubuntu Server 16.04

Fri, 16 Mar 2018 10:00:00 +0800

Bismillahirrahmanirrahim.

Sekarang kita akan menginstall LEMP Stack web server: Nginx, MariaDB, dan PHP 7.0 pada VPS (atau VM Instance) yang sudah kita punya. Sebenarnya artikel cara install web server pada Ubuntu Server sudah banyak bertebaran di internet, tetapi kali ini kita akan bahas installasi LEMP Stack dengan konfigurasi tambahan yang biasa saya terapkan :

Mengubah root directory project pada serverblock nginx.
Menambah user baru setara “root” pada MySQL.

Pada artikel ini, saya menggunakan Ubuntu Server 16.04 dari Google Cloud Engine, tetapi ini bisa diterapkan ke VPS dari provider lain, dengan catatan kita tidak menggunakan user “root”, tetapi menggunakan sudoer user.

Baik kita mulai.

Install Nginx 1.10.3

SSH ke VPS atau VM Instance, kemudian:

sudo apt update
sudo apt install nginx

Ketika selesai, bisa kita cek di browser dengan membuka IP Address VPS kita. Misal: http://35.198.238.82 (tampil Welcome to nginx!).

Mengubah directory root nginx

Secara default, nginx melayani project yang berada pada direktori /var/www/html. Tetapi untuk akses dan menjalankan perintah ke direktori itu, kita harus menggunakan sudo (karena kita tidak menggunakan user root).

Agar kita tidak repot menggunakan sudo, kita ubah direktori root nginx dari /var/www/html ke /home/username/www. Di mana username adalah sudoer user di server ini.

Caranya, edit serverblock default nginx.

$ sudo vim /etc/nginx/sites-available/default

Ubah 2 baris berikut ini :

# Ubah sesuai dengan direktori yang akan kita gunakan
root /home/username/www;

# ubah sesuai dengan IP Address Server atau domain
server_name 35.198.238.82;

Simpan, kemudian buat direktori sesuai dengan yang diatur pada serverblock, yaitu /home/username/www.

# Cek direktori saat ini.
$ pwd
/home/username

# Buat direktori sesuai dengan yang diatur pada serverblock.
$ mkdir www

# Test nginx (jika OK, maka serverblock sudah benar).
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

# Reload nginx.
$ sudo service nginx reload

Sekarang kita cek, apakah perubahan yang kita buat berhasil? Buat buat file index.html pada direktori www.

$ vim www/index.html

Isi file index.html, misal :

<h1>Dilayani dari direktori /home/username/www</h1>

Tes via browser http://35.198.238.82, jika tampil tulisan di file index.html tadi, berarti perubahan root directori nginx berhasil.

Sip, selesai install nginx dengan project root pada home directory kita.

Install PHP 7.0

Lanjutkan install PHP 7.0 beserta extensionnya (yang diperlukan oleh Laravel).

$ sudo apt install php-fpm php-mysql php-mbstring zip unzip php7.0-zip gzip php-xml php-gd php-curl

Setting nginx serverblock default agar melayani PHP.

$ sudo vim /etc/nginx/sites-available/default

        # Tambahkan index.php pada baris index
        index index.php index.html index.htm index.nginx-debian.html;

        # Uncomment pada location ~ \.php$ seperti di bawah
        location ~ \.php$ {
                include snippets/fastcgi-php.conf;

        #       # With php7.0-cgi alone:
        #       fastcgi_pass 127.0.0.1:9000;
                # With php7.0-fpm:
                fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        }

        # Uncomment untuk menolak akses .htaccess
        location ~ /\.ht {
                deny all;
        }

Serverblock lengkapnya bisa dilihat pada gist ini.

Simpan, kemudian reload nginx.

# Test nginx (jika OK, maka serverblock sudah benar).
$ sudo nginx -t

# Reload nginx.
$ sudo service nginx reload

Edit php.ini

$ sudo vim /etc/php/7.0/fpm/php.ini

Ubah baris ini cgi.fix_pathinfo menjadi 0, hilangkan # jika ada.

cgi.fix_pathinfo=0

Simpan, kemudian restart PHP-FPM.

$ sudo service php7.0-fpm restart

Setup PHP-FPM untuk nginx sudah beres, sekarang kita tes apakah konfigurasi berhasil.

Uji Coba PHP

Buat file info.php pada direktori www.

$ vim www/info.php

Isi file dengan script phpinfo().

<?php phpinfo();

Simpan, kemudian tes di browser: http://35.198.238.82/info.php. Seharusnya tampil info lengkap PHP pada server kita.

# Kalau sudah tampil seperti di atas,
# hapus file info.php demi keamanan.
$ rm www/info.php

Selesai install PHP 7.0, kita lanjutkan install MariaDB.

Install MariaDB 10.2

Secara default, pada ubuntu server 16.04 kita mendapatkan MariaDB 10.0. Tetapi kali ini kita akan menginstall MariaDB 10.2.

$ sudo apt-get install software-properties-common
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mirror.poliwangi.ac.id/mariadb/repo/10.2/ubuntu xenial main'
$ sudo apt update
$ sudo apt install mariadb-server

Cek versi MariaDB :

$ mysql -V
mysql  Ver 15.1 Distrib 10.2.13-MariaDB ...

Sekarang kita konfigurasi keamanannya :

$ sudo mysql_secure_installation

# Ikut langkahnya, dengan menjawab pertanyaan
# 
# Enter current password for root (enter for none): 
# Change the root password? [Y/n] Y
# New password: 
# Re-enter new password: 
# Password updated successfully!
# Remove anonymous users? [Y/n] Y
# Disallow root login remotely? [Y/n] Y
# Remove test database and access to it? [Y/n] Y
#  ... Success!
# 
# Cleaning up...
# 
# All done!  If you've completed all of the above steps, your MariaDB
# installation should now be secure.
# 
# Thanks for using MariaDB!

Sip, selesai install MariaDB 10.2.

Membuat User MySQL dengan root privileges

Setiap installasi MariaDB/MySQL, kita memiliki user root. Sama halnya dengan user root pada Ubuntu, sebaiknya kita tidak menggunakan user ini untuk bekerja. Kita buat user baru dengan hak akses yang sama dengan root.

# Masuk (login) ke MySQL dengan user root.
$ sudo mysql -uroot -p

# Buat user dengan nama 'usernamebaru' dan password 'supersecurepassword'
MariaDB [(none)]> CREATE USER 'usernamebaru'@'localhost' IDENTIFIED BY 'supersecurepassword';

# Grant privilleges untuk user baru
MariaDB [(none)]> GRANT ALL PRIVILEGES ON * . * TO 'usernamebaru'@'localhost';
MariaDB [(none)]> FLUSH PRIVILEGES;

# Untuk melihat semua user yang ada
MariaDB [(none)]> SELECT User,Host FROM mysql.user;

# Selesai, exit MariaDB/MySQL
MariaDB [(none)]> exit;

Sehingga nanti aplikasi PHP yang kita deploy pada server ini dapat menggunakan database dengan username usernamebaru dan password supersecurepassword, tidak perlu menggunakan user root.

Kesimpulan

Dengan installasi dan setup/konfigurasi di atas, maka kita akan memiliki :

Nginx versi 1.10.3 dengan root directory /home/username/www.
(Tidak perlu sudo untuk menjalankan composer).
PHP versi 7.0.
Database MariaDB versi 10.2.
Dengan username usernamebaru dan password supersecurepassword.
Database lebih aman karena :
- Memiliki user mysql baru yang hanya kita yang tahu.
- Kita blok akses database secara remote untuk user root.

Demikian teman-teman, seperti ini proses installasi LEMP Stack yang biasa saya lakukan untuk VPS Ubuntu Server 16.04. Cara dan proses di atas sebatas sepengetahuan saya yang sangat sedikit dalam hal keamanan server. Mudah-mudahan kedepannya kita bisa bahas tentang keamanan ubuntu server jika sudah ketemu ilmu baru. :D

Terima kasih sudah berkenan membaca.

Sumber Bacaan

Google Script dengan Trigger, Alternatif Laravel Schedule

Tue, 27 Feb 2018 13:45:00 +0800

Bismillahirrahmanirrahim.

Saya ingin share video tutorial yang saya jadikan referensi untuk menjalankan Google App Script dengan triggernya sebagai alternatif agar aplikasi kita “melakukan sesuatu” pada jadwal yang sudah ditetapkan.

How To Call External API Using Google App Script - by Amarindaz

Ini video tutorial cara membuat sebuah function pada Google App Script untuk memanggil external API endpoint UrlFetchApp.

Jika pada video di atas kita mendapatkan ilmu baru untuk membuat script pemanggilan API Endpoint, pada video berikut ini kita mengetahui cara membuat Trigger agar script tersebut dijalankan setiap waktu (jadwal) yang kita tentukan.

Setup Triggers Run script using Google Apps Script - by Break Period

Nah dengan berbekal ilmu baru dari tutorial tersebut maka kita dapat melakukan penyesuaian untuk scheduler pada project/aplikasi kita, kurang lebih logic nya seperti ini:

Buat sebuah endpoint pada project agar dapat diakses oleh Google App Script.
Buat sebuah kondisi bahwa hanya google atau ada syarat tertentu yang akan dilayani oleh endpoint ini.
Buat script aktifitas apapun yang diperlukan jika endpoint tersebut dikunjungi, seperti :
- Membersihkan notifikasi lama,
- Menghapus order yang tidak terbayar lebih dari 1 minggu,
- Atau aktifitas apapun yang ingin diotomatiskan.
Cek dan re-cek agar aktifitas tersebut berjalan sesuai dengan kebutuhan.
Buat Google Script function dengan triggernya.

Contoh Kasus

Di sebuah project CRM Sales Otomotif, saya diminta untuk membuat sebuah fitur di mana setiap hari ada pengecekan untuk customer yang tidak di follow-up lebih dari 1 minggu dari tanggal deadlinenya (overdue follow up).

Misalkan :

Deadline customer tanggal 01 Pebruari 2018,
Toleransi deadline 7 Hari,
Kalau tidak ada follow-up hingga 07 Pebruari 2018, jam 12 malam, sistem secara otomatis akan “membebaskan” customer tersebut dari PIC Sales nya,
Customer masuk ke daftar “Free Customers”,
PIC Sales lain dapat dapat diambil alih customer tersebut yang menginginkannya.

Karena akan dideploy ke shared hosting, maka saya tidak dapat membuat laravel schedule untuk keperluan ini. Solusinya saya coba dengan Google App Script plus Triggernya.

Untuk melakukan pengecekan itu saya membuat script seperti ini :

Di sini bisa kita lihat, jika tidak ada payload atau request body yang berisi 'action' => 'evaluate-free-customers' maka sistem akan abort(404) (diberi respons halaman tidak ditemukan).

Setelah memastikan Endpoint API tersebut sudah berjalan dengan baik melalui automated testing dan Postman, saya buatkan google script seperti gambar di bawah.

Kalau dijalankan dan tidak ada error, hasilnya cek di Logs seperti ini (Menu: View -> Logs atau Ctrl+Enter) :

Kemudian setting jadwalnya seperti ini.

Maka maka setiap jam 12 malam (tiap hari), google script akan “mengunjungi” endpoint tersebut, dan aplikasi melakukan pengecekan customer sebagaimana yang diinstruksikan. :D

Gimana cukup mudah ya menggunakan Google App Script ini? Sangat membantu meng-otomatiskan sesuatu di aplikasi yang dipasang di shared hosting. Ditambah adanya video tutorial di atas, setupnya tidak terlalu sulit.

Demikian share singkat dari saya seputar Google Script dengan Trigger, sebagai alternatif Laravel Schedule dan Server Cron untuk project laravel yang dipasang di shared hosting.

Terima kasih teman-teman atas waktunya.

Free PMO - Aplikasi Management Project

Sun, 25 Feb 2018 19:00:00 +0800

Bismillahirrahmanirrahim.

Saya ingin share tool/software yang saya kembangkan untuk mempermudah pengelolaan project-project yang saya kerjakan. Nama nya Free PMO. Software ini membantu saya dalam mengelola project, membuat proposal pengajuan anggaran project, update progress task (tugas) dan job per project, serta mencatat pemasukan dan pengeluaran uang dalam project.

Aplikasi ini dibuat dengan Laravel 5 ini awalnya hanya untuk tujuan mencatat seluruh pemasukan dan pengeluaran saja, agar saya tahu persis berapa profit/penghasilan yang saya terima dalam setahun (dalam bekerja sebagai Freelance Web Developer). Kemudian aplikasi ini terus saya kembangkan, sambil memanfaatkan waktu senggang, untuk mempermudah mencatat list item-item pekerjaan yang harus saya kerjakan, beserta detail checklist tugasnya.

Setelah mengembangkan dan menikmati sendiri sekitar 1 tahun, saya memutuskan untuk meng-opensource-kan aplikasi ini. Mungkin dapat bermanfaat bagi teman-teman developer/freelancer atau agensi yang masih belum ketemu tool yang pas untuk mengelola project-projectnya dalam satu aplikasi yang customizable sesuai kebutuhan.

Software ini juga dapat digunakan oleh perusahaan/lembaga/usaha yang memiliki layanan project based bagi pelanggannya. Misal seperti Developer Perumahan, Pengacara, Notaris, atau bisa juga digunakan oleh seorang Project Manager di sebuah perusahaan. Memang tidak semua fitur tersedia, tetapi setidaknya pengelolaan project secara umum dapat dilakukan dengan Free PMO. Dan sekali lagi, source code Free PMO tersedia gratis di github, siapa pun dapat mengembangkan sesuai kebutuhan.

Software ini free and open-sourced berlisensi MIT, yang intinya :

Pengembang (baca: saya) mengijinkan dan ridho jika aplikasi ini digunakan/dimodifikasi/distribusikan ulang untuk tujuan pribadi, instansi maupun komersil, dengan catatan file LICENSE di dalam project tidak diubah/dihilangkan.

Artinya saya mempersilakan teman-teman untuk menggunakan source code dan aplikasi Free PMO sesuai keperluan tanpa harus minta ijin atau membayar saya.

List fitur lengkap dan cara installnya dijelaskan dalam repo githubnya. Jika ada kendala dalam installasi, silakan diinformasikan.

Saya juga mempersilakan jika teman-teman ada yang ingin berkontribusi dalam mengembangkan project ini. Beberapa cara dan sarana kontribusi saya jelaskan pada file CONTRIBUTING di repository Project.

Btw, aplikasi ini dibangun dengan metode Test-driven Development, yang sudah kita ulas di banyak artikel pada blog ini. Mungkin bisa jadi salah satu referensi jika teman-teman ada yang mau menekuni metode TDD dalam pembangunan aplikasi dengan Framework Laravel.

Semoga manfaat yang saya dapatkan dari tool ini juga bermanfaat untuk orang banyak.

Terima kasih atas perkenan teman-teman.

Cara Membuat Sudoer User pada Ubuntu Server 16.04

Fri, 23 Feb 2018 22:00:00 +0800

Bismillahirrahmanirrahim.

Ketika kita menyewa sebuah VPS, umumnya kita mendapatkan login sebagai super user “root” ke server. Kata orang-orang yang berpengalaman, ini berresiko, karena perintah-perintah yang kita jalankan dengan super user “root” akan dieksekusi tanpa konfirmasi atau ditanya password. Ini lumayan bahaya jika kita “tidak terlalu paham” dengan perintah-perintah yang kita eksekusi (IMHO).

Nah, ketika mulai belajar menggunakan VPS, saya mencari referensi bagaimana cara membuat sebuah user baru di Ubuntu server. Tujuannya agar ketika ingin menjalankan perintah yang berhubungan dengan perubahan di sistem (misal install, hapus atau mengubah sesuatu), harus dilakukan dengan “sudo” dan ditanya password dulu. Sekedar memastikan bahwa saya yakin akan mengeksekusi perintah itu.

Yah, sedikit lebih aman lah..

Oke, kita simpulkan, karena lebih aman, maka setiap deploy VPS baru, kita perlu membuat sebuah user yang memiliki hak akses “root” dengan bantuan “sudo”. Inilah yang disebut sudoer user. Sudoer user adalah user masuk dalam grup super user, memiliki hak akses setara super user “root” dengan “mantra” bernama “sudo”.

sudo = super user do

Membuat User Baru

Di sini saya login dari terminal di laptop, ke VPS Ubuntu Server 16.04 yang baru di-deploy melalui SSH dengan user root.

$ ssh root@ip-address-vps

Misal kita membuat sebuah user baru bernama “projectuser”, kita berikan perintah :

adduser projectuser

Isikan New password dan Retype new password, isikan data yang diperlukan. Lebih kurang seperti ini prosesnya :

root@test-vps:~# adduser projectuser
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:

...

perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Adding user `projectuser` ...
Adding new group `projectuser` (1000) ...
Adding new user `projectuser` (1000) with group `projectuser` ...
Creating home directory `/home/projectuser` ...
Copying files from `/etc/skel` ...
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for projectuser
Enter the new value, or press ENTER for the default
    Full Name []: Project User
    Room Number []: 
    Work Phone []: 
    Home Phone []: 
    Other []: 
Is the information correct? [Y/n] y
root@test-vps:~#

Sampai sini kita sudah memiliki user “projectuser”. Baik kita lanjutkan.

Masukkan User ke grup SUDO

Agar dapat menjalankan perintah dengan “sudo”, kita masukkan user projectuser ke dalam grup “sudo”. Berikut perintahnya :

usermod -aG sudo projectuser

Nah salah satu contohnya ini, dengan “root”, ketika kita masukkan sebuah user ke grup sudo, perintah ini langsung dijalankan oleh sistem, tanpa konfirmasi dulu. Bisa dibayangkan kalau kita eksekusi sebuah perintah yang berbahaya (tanpa kita tahu resikonya)? Hmmm…

Uji coba perintah SUDO

Oke sekarang kita coba login sebagai projectuser.

su - projectuser

Maka kita akan ter-login sebagai “projectuser”. Sekarang kita coba sebuah perintah yang memerlukan hak akses root dengan “sudo”.

$ sudo ls -la /root

Akan tampil seperti ini.

Sip, jika isi direktori /root muncul, berarti user ini sudah menjadi seorang “sudoer user”.

Uji coba SSH dengan User Baru

Apakah kita bisa login dengan user ini langsung melalui SSH? Bisa dong..
Kita coba SSH dari PC/Laptop local kita.

$ ssh projectuser@ip-address-vps

Berhasil. Oke dengan demikian, kita sudah punya sebuah user “projectuser” yang akan digunakan untuk bekerja di VPS kita, tanpa harus menggunakan user “root”.

Kesimpulan

Jadi mengapa disarankan menggunakan non-root user dalam bekerja di sebuah VPS?
Berikut beberapa hal yang dapat saya simpulkan :

User “root” mengeksekusi perintah tanpa konfirmasi password terlebih dahulu, sehingga agak berresiko jika digunakan dalam bekerja di sebuah server.
Dengan adanya sudoer user dan bisa SSH dengan user tersebut, maka kita dapat disable “root” login.
Semua GNU/Linux server memiliki user “root” dengan hak akses super user. “Orang-orang usil” dapat mencoba akses via SSH ke server kita dengan user “root” secara brutal. Istilah kerennya Brute Force SSH attack. Ini dapat dihindari dengan men-disable “root” login seperti pada point 2 di atas.

Baik, demikian pembahasan kita tentang cara membuat sudoer user, agar kita tidak perlu menggunakan super user “root” dalam bekerja dengan VPS Ubuntu 16.04. Hanya sedikit share dari pengetahuan saya yang minim seputar pengelolaan server. :D

Terima kasih teman-teman sudah berkenan membaca.

Cara Akses VM Instance GCE dari Terminal Ubuntu 16.04

Tue, 13 Feb 2018 08:00:00 +0800

Bismillahirrahmanirrahim.

Beberapa artikel yang lalu kita bahas tentang Google Cloud Engine (GCE), yaitu VPS dari google. Pada artikel tentang deploy VM Instance kemarin, kita dapat mengakse VPS tersebut dengan SSH melalui pop-up window browser dari Google Cloud Platform (GCP). Kita tidak dapat mengakses vps tersebut langsung melalui terminal.

Misal kita punya VM Instance dengan External IP Address: 35.194.38.27.

$ ssh nafiesl@35.194.38.27 
Permission denied (publickey).

Kalau terus-terusan mengakses melalui pop-up window browser di GCP Console, sepertinya lumayan merepotkan. Karena harus buka GCP Console dulu baru bisa login ke VM Instance (VPS) nya. Kita kan inginnya serba cepat ya? Langsung SSH dari terminal Ubuntu kan enak? :D

Bagaimana caranya agar kita langsung bisa akses melalui terminal kita? Pada artikel ini kita bahas langkah-langkahnya.

Install Google Cloud SDK (gcloud).
Setup gcloud compute (ijin akses google cloud SDK).
SSH dengan gcloud.
Akses langsung dengan SSH terminal (tanpa gcloud).

Install Google Cloud SDK (gcloud)

Satu-satunya cara bisa akses melalui terminal Ubuntu adalah menggunakan aplikasi Google Cloud SDK. Silakan buka halaman dokumentasi Google Cloud SDK, pilih OS yang sesuai, saya menggunakan Ubuntu 16.04, maka pilih Install for Debian / Ubuntu.

Sesuai petunjuk di dokumentasi tersebut, kita jalankan perintah-perintah berikut untuk install Google Cloud SKD.

# Create an environment variable for the correct distribution
export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)"

# Add the Cloud SDK distribution URI as a package source
echo "deb http://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

# Import the Google Cloud Platform public key
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

# Update the package list
sudo apt-get update 

# Install the Cloud SDK
sudo apt-get install google-cloud-sdk

Selesai proses installasi, uji coba perintah gcloud -v.

$ gcloud -v
Google Cloud SDK 188.0.1
alpha 2018.02.08
beta 2018.02.08
bq 2.0.28
core 2018.02.08
gsutil 4.28

Sip, artinya aplikasi gcloud sudah terinstall di Ubuntu kita.

Set up gcloud compute

Untuk memulai akses ke VM Instance kita di Google Cloud Engine (GCE), kita lakukan setup gcloud compute. Jalan kan perintah gcloud init, kita akan mendapatkan tampilan berikut, ikuti langkahnya :

$ gcloud init

Welcome! This command will take you through the configuration of gcloud.
Your current configuration has been set to: [default]
To continue, you must login. Would you like to login (Y/n)?  y

Your browser has been opened to visit:

https://accounts.google.com/o/oauth2/auth?scope=https%3A%2F%2Fwww.googleapis.co%2
Fauth%2Fappengine.admin+https%3A%2F%2...

Browser akan terbuka, kemudian kita diminta untuk login dengan akun google sesuai yang kita gunakan untuk GCP, kemudian ijinkan akses untuk Google Cloud SDK.

Setelah berhasil login, kembali ke terminal dan akan muncul pilihan project pada GCP.

Created new window in existing browser session.
[28187:28222:0212/215654.452498:ERROR:browser_gpu_channel_......
You are logged in as: [........@gmail.com].

Pick cloud project to use: 
 [1] api-project-6587......
 [2] balm......
 [3] inspe......
 [4] jw......
 [5] nafi......
 [6] youtube-chann......
 [7] Create a new project
Please enter numeric choice or text value (must exactly match list 
item):  5

Masukkan nomor cloud project yang ingin kita gunakan, silakan isi dengan nomor project sesuai dengan nama project yang kita buat saat mendaftar pada GPC. Dalam hal ini, saya pilih nomor 5. Lanjutkan proses jika ada pertanyaan selanjutnya, sampai selesai.

Sampai di sini kita sudah berhasil set up gcloud compute. Artinya dengan perintah :

$ gcloud compute ssh username@my-vps

seharusnya kita sudah dapat akses SSH langsung dari terminal Ubuntu kita.

SSH dengan gcloud

Oke, sekarang kita coba ssh ke VM Instance kita melalui terminal dengan perintah :

$ gcloud compute ssh nafiesl@my-vps

Prosesnya lebih kurang seperti ini :

$ gcloud compute ssh nafiesl@my-vps
WARNING: The public SSH key file for gcloud does not exist.
WARNING: The private SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/....../.ssh/google_compute_engine.
Your public key has been saved in /home/....../.ssh/google_compute_engine.pub.
The key fingerprint is:
SHA256:+QLtoU95kCnibbK1ZSf3PU...... ......@kingpinn

Updating project ssh metadata...-Updated [https://www.googleapis.com.....].
Updating project ssh metadata...done.     
Waiting for SSH key to propagate.

...

Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.13.0-1008-gcp x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.


Last login: Mon Feb 12 23:26:47 2018 from 202.67.32.89
nafiesl@my-vps:~$

Catatan : Jika ada kegagalan dalam proses, coba ditambahkan command option yang sesuai, misal --zone, panduannya ada pada dokumentasi gcloud-compute bagian connecting.

Akses Langsung dengan SSH Terminal?

Sekarang, check this out :

$ ssh nafiesl@35.194.38.27
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.13.0-1008-gcp x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.


Last login: Mon Feb 12 14:46:07 2018 from 173.194.93.34
nafiesl@my-vps:~$

Yes! Karena (PC/laptop) kita sudah pernah terhubung kita melalui gcloud, sekarang kita bisa langsung ssh ke VM Instance dengan perintah ssh username@ip-address-vm-instance.

Mantap!

Catatan

Agar dapat ssh ke VM Instance melalui terminal, kita harus menginstall Google Cloud SKD (gcloud) dan memberikan ijin akses ke project di GPC.
Sepanjang yang saya tahu, secara default kita tidak mendapat akses root, kita mendapatkan user ubuntu dengan nama yang sama dengan username gmail kita.
Jika kita lakukan gcloud compute ssh my-vps (tanpa username google), maka gcloud akan membuat login/user sesuai dengan username PC/Laptop kita.
Jika ada kegagalan dalam koneksi ssh, pastikan teman-teman menambahkan command option yang sesuai, misal --zone, cek panduannya pada dokumentasi gcloud-compute bagian connecting.

Sip, selesai. Demikian pembahasan kita tentang cara akses VM Instance GCE dari terminal Ubuntu 16.04. Mudah-mudahan bermanfaat bagi teman-teman yang memerlukan. Jika ada yang ingin didiskusikan, silakan tuliskan pada kolom komentar.

Terima kasih atas waktunya. :D

MkDocs - Project Documentation with Markdown

Mon, 12 Feb 2018 07:00:00 +0800

Bismillahirrahmanirrahim.

Membuat user guide atau panduan user dari aplikasi yang kita bangun adalah pekerjaan yang lumayan menyita waktu. Apalagi bagi seorang freelancer, umumnya paduan user ini dibuat setelah project selesai, karena semua dikerjakan sendiri. Kita harus mencari cara agar mempermudah pekerjaan ini.

Salah satu tool yang bisa kita gunakan untuk membuat panduan sistem adalah MkDocs. MkDocs ini adalah sebuah static site generator yang ditujukan untuk membuat project documentation.

Beberapa klien yang meminta dibuatkan user guide, saya buatkan dengan tool MkDocs ini.

Kelebihan MkDocs

Kelebihannya yang saya ketahui antara lain :

Menulis dengan markdown (bagi yang terbiasa menulis readme di github, nyaman dengan ini).
Auto-reload on save changes (refresh otomatis saat file disimpan).
Top Navbar otomatis sesuai struktur folder dan file.
Table of content (daftar isi) otomatis mendeteksi setiap header dokumen (#, ##, ###, h1, h2, h3, h4, …).
Scroll spy pada table of content.
Fitur search dokumentasi.
Bisa custom CSS dan JS.
Mobile responsive (bootstrap 3).
Bisa dipublish ke github pages.

Keren ya.

Contoh Project MkDocs

Ini contoh yang dipublish dengan github pages :
https://nafiesl.github.io/panduan-penjualan.

Source codenya di github :
https://github.com/nafiesl/panduan-penjualan.

Silakan teman-teman yang mau coba :
http://www.mkdocs.org, ada panduan installasinya.

Manfaat MkDocs

Yang saya rasakan dari menggunakan MkDocs ini, dapat mempercepat pembangunan dokumentasi project, karena :

Bisa fokus ke konten, karena tampilan yang cantik sudah diberikan oleh MkDocs.
Tidak perlu tekan tombol refresh browser karena auto-reload.
Sudah dalam format HTML, tinggal upload ke production server/hosting.

Kendala pada MkDocs

Satu yang belum saya temukan di MkDocs adalah konversi ke file PDF, karena kadang klien juga minta versi PDF nya untuk dibaca secara offline, atau dibagi-bagi ke user yang menggunakan sistem. Jadi untuk kebutuhan ini, solusinya dengan menggunakan LibreOffice Writer.

Oke, demikian sharing singkat tentang MkDocs, mudah-mudahan bermanfaat bagi yang membutuhkannya.

Terima kasih atas waktu teman-teman sudah membaca.

Cara Deploy VPS (VM Instance) Google Cloud Engine

Fri, 02 Feb 2018 16:00:00 +0800

Bismillahirrahmanirrahim.

Google memiliki promo untuk Google Cloud Platform, yaitu Free Credit $300 untuk 12 bulan untuk pengguna baru. Jika kita sudah mendaftar dan mendapatkan Free Credit ini, kita dapat menggunakannya untuk membayar beberapa Cloud Platform dari Google, salah satunya Google Cloud Engine. Dengan membuat sebuah VM Instance dari Google Cloud Engine, kita akan memiliki sebuah VPS (Virtual Private Server) yang dapat kita gunakan sebagai web server.

Blog ini, web JasaWebsiteBanjarmasin.com, dan project riset yang saya kelola, saya hosting di satu VM Instance Google Cloud Engine. Lumayan hemat budget hosting untuk 1 tahun.

Deploy VM Instance Google Cloud Engine

Kali ini kita akan membahas bagaimana cara deploy satu VM Instance pada GCE (Google Cloud Engine). Persiapannya, pastikan kita sudah mendaftar dan mendapatkan Free Credit. Kemudian lakukan langkah berikut ini:

Dari Dashboard Google Cloud Platform, pilih menu:
Products & services (kiri atas) → Compute Engine → VM Instances.
Klik Create Instance.
Isi Name, misal: vps-saya
Pilih Zone terdekat dengan target visitor. Ini menentukan lokasi data center VPS kita, untuk Indonesia, pilih asia-shoutheast1-a.
Pilih Machine Type, paling murah micro (1 shared vCPU), tapi Machine Type ini bebas pilih sesuai kebutuhan.
Pada Boot Disk, klik Change, pilih OS Image Ubuntu 16.04 LTS, Boot disk type SSD Persistent Disk, Size minimal 10GB. Klik Select.
Pada Identity and API access, pilih Service account App Engine app default service account (sesuai nama project).
Pada Firewall, centang Allow HTTP dan HTTPS traffic.
Sebelum klik Create, kita perhatikan estimasi tagihan perbulan di sebelah kanan klik Details untuk melihat rinciannya. Jumlah itu yang akan dipotong dari Kredit nanti.
Jika sudah memahami, klik Create. Maka VM Instance (VPS) kita sudah selesai.
Kita coba login ke VPS melalui SSH, klik link SSH pada kolom Connect. Maka akan muncul terminal window berupa pop-up window browser. Seperti di bawah ini.
Sekarang kita coba ping IP Address nya (External IP).

Jika seperti terlihat pada gambar di atas, artinya VM Instance (VPS) kita sudah aktif dan siap digunakan, silakan install web server sesuai kebutuhan.

BTW untuk harga estimasi perbulan di atas $6.57 perbulan = $6.57 * 12 = $78,84 per tahun (Credit masih sisa banyak), jadi silakan teman-teman pilih spesifikasi di atas sesuai dengan kebutuhannya.

Sip, sampai di sini pembahasan kita tentang Cara deploy VPS (VM Instance) Google Compute Engine. Semoga bermanfaat, terima kasih.

Mendapatkan Free Credit USD 300 untuk Google Compute Engine

Fri, 02 Feb 2018 09:00:00 +0800

Bismillahirrahmanirrahim.

Sekitar September 2017 saya mendaftar di Google Cloud Platform, karena tergiur dengan gratis credit $300 untuk 12 bulan. Kebetulan shared hosting yang saya sewa untuk blog ini dan JasaWebsiteBanjarmasin.com sudah mau habis (oktober 2017), jadi saya putuskan untuk mencobanya.

Setelah berhasil mendaftar, mendeploy satu VM Instance (VPS), setup web servernya, deploy websitenya, kemudian update nameserver domain ke google cloud, akhirnya kedua web ini akan berjalan di VPS dari google itu. Alhadulillah “selamat” budget untuk hosting 12 bulan kedepan. :D

Nah, pada artikel ini saya akan share untuk teman-teman yang mungkin ingin mencobanya.

Mendaftar Google Cloud Platform

Langkah pertama yang kita lakukan adalah mendaftar ke Google Cloud Platform. Syaratnya kita harus memiliki Kartu Kredit yang masih berlaku.

Buka halaman web Google Cloud Platform.
Login dengan akun google/gmail.
Hingga mencapai halaman ini, klik TRY FOR FREE
Isi Formulirnya, klik Aggree and continue.
Isi Formulir Data Diri.
Isi Data Kartu Kredit.
Info dari google, kartu kredit tidak ada charge tanpa sepengetahuan user (kita), selama 12 bulan, kita tetap akan menggunakan kredit $300 gratis dari google.
Klik Start my free trial.
Pendaftaran selesai, dan seharusnya kita sudah bisa mengakses halaman ini: https://console.cloud.google.com/home

Membuat Project Baru

Untuk dapat memulai menggunakan VPS atau VM Instance Google Cloud Engine, kita harus membuat Project dulu.

Buka Menu Products & services (kiri atas) → Compute Engine → VM Instances.
Pada Project Name, input nama project yang diinginkan, misal Project VPS Saya.
Klik Create.
Selesai, mestinya sekarang kita sudah bisa membuat VM Instance baru.

Sisa Kredit Billing

Jika kita sudah mendaftar dan mulai menggunakan VM Instance Google Cloud Engine, kita bisa melihat Sisa Kredit Billing yang kita dapatkan dari google.

Menu : Products & services (kiri atas) → Billing.

Di sini kita bisa lihat, kredit akan berkurang selama kita men-deploy VM Instance.

Penutup

Selama 5 bulan pemakaian (sampai artikel ini ditulis), saya mendeploy 1 VM Instance secara tetap, dan beberapa kali bongkar pasang VM Instance untuk keperluan riset, alhamdulillah belum ada charge yang dikenakan google untuk pembayaran Google Cloud Engine ini.

Sip, sampai di sini kita sudah siap men-deploy dan menggunakan VM Instance Google Cloud Engine untuk web server. Insya Allah pada artikel berikutnya kita akan bahas tentang cara deploy VM Instance dan perhitungan estimasi biaya bulanannya.

Terima kasih atas waktu teman-teman sudah membaca. Mudah-mudahan artikel ini bermanfaat bagi yang membutuhkannya.

Mencatat Bug dan Small Improvement dengan Bitbucket Issue

Sat, 20 Jan 2018 21:00:00 +0800

Bismillahirrahmanirrahim.

Misal teman-teman programmer/software developer telah selesai mengerjakan sebuah software (misalkan project untuk user/klien) dan software tersebut dalam masa uji coba, kita cenderung mendapatkan laporan bug terkait software tersebut. Bagaimana cara mencatat laporan tersebut agar mudah diingat/dibuka kembali ketika ingin mengerjakan perbaikannya?

Atau ketika ada permintaan improvement kecil dari user/klien. Bagaimana apa sarana yang digunakan mencatat permintaan tersebut untuk memastikan tidak ada yang terlewat oleh kita (saat dikerjakan)?

Sarana Mencatat Bug Report/Improvement Request

Ada beberapa sarana (catatan) yang mungkin kita andalkan :

“Scroll back” diskusi melalui Chat
Mencari diskusi pada Email
Membuat catatan file .txt atau .odt yang kita buat saat meeting
Catatan tulis tangan saat kita meeting
Pada sebuah Board Trello yang sudah kita siapkan
Atau buat issue pada hosted repo di github/bitbucket/gitlab.

Saya sudah mencoba sarana point 1 s/d 5, dan akhirnya yang paling rutin saya lakukan adalah point 3 karena paling mudah dan cepat. Sedangkan point 6 (saya bayangkan) hanya bisa diterapkan pada sebuah project yang dikerjakan dengan kolaborasi, karena keterlibatan banyak orang dan pasti ada project leader dalam project tersebut. Dan sarana itu juga lengkap dengan fitur “penugasan”, maka akan sangat membantu dalam pembagian tanggung jawab pada project yang dikerjakan secara kolaborasi.

Yap, selama ini saya mengandalkan file-file .txt yang saya buat saat meeting/chat dengan klien, dan kembali membuka file-file tersebut untuk mengingat hal-hal yang harus saya kerjakan. Setiap item yang sudah dikerjakan, saya tambahkan tanda (done) disampingnya. Seperti ini.

Tradisionil ya? Hehe..

Setidaknya ini usaha saya agar tidak lalai terhadap pekerjaan yang harus saya kerjakan. Untuk minimalisir kata “saya lupa” (yang sering sekali menjadi perkara).

Menggunakan Bitbucket Issue

Baru-baru ini, saya menyadari, bahwa sarana point 6 di atas juga bisa digunakan untuk project yang dikerjakan sendiri (misal oleh seorang freelancer atau seorang single fighter dalam sebuah instansi). Coba teman-teman lihat ini.

Disitu kita bisa lihat, catatan txt saat meeting dengan klien (yang saya buat di atas), setiap item bisa kita input menjadi sebuah issue di repo bitbucket. Kalau sudah diinput seluruhnya (hasil meeting tadi), maka di bitbucket issue kita bisa lihat :

Mana item yang sudah dikerjakan,
Mana yang belum dikerjakan,
Mana yang prioritasnya tinggi,
Sifat issue (bug atau improvement atau lainnya)
Kapan issue dibuat
Kapan solved/update terakhir (ketahuan jika ada yang sudah lama tidak di-follow-up)
Siapa yang bertugas (kalau sendirian ya tentu nama kita di situ :D )

Mantap ya, banyak manfaat yang kita dapatkan. Kemudian jika kita lihat detail salah satu issue seperti di bawah ini.

Maka kita bisa melihat :

Siapa yang buat issue
Ada komentar (kalau perlu mencatat detailnya)
Kalau statusnya closed kelihatan siapa yang mengerjakan.
Commit-commit yang berkaitan dengan issue ini, jika direferensikan pada commit message.

Lebih keren, kan ya, dari pada mengandalkan catatan yang di file txt? Menurut saya, iya. :D

Input Issue di Bitbucket

Pada saat kita klik Create Issue pada Bitbucket, kita akan mendapatkan formulir seperti ini:

Berikut keterangannya :

Title adalah judul issue, deskripsi singkat tentang masalah/item pekerjaan
Description adalah penjelasan tentang masalah/item pekerjaan secara detail, agar mudah dipahami oleh orang yang akan ditugasi, deskripsi dapat ditulis dengan format Markdown dan dapat kita review terlebih dahulu.
Assignee adalah petugas yang bertanggung jawab terhadap issue ini, baik developer atau penanggung jawab (PIC).
Kind adalah jenis issue. Bisa berupa Bug, Enhancement, Proposal, atau Task
Priority adalah prioritas atau tingkat urgensi masalah yang dilaporkan.
Attachment adalah lampiran file pendukung untuk masalah tersebut, misalnya screenshot software atau lainnya.

Dengan pengisian yang lengkap dan jelas pada formulir ini, maka masalah yang dilaporkan akan mudah dipahami oleh penanggung jawab, atau bahkan oleh kita sendiri (untuk memastikan kita tidak lupa).

Manfaat History Issue Bitbucket

Ketika semua catatan hasil meeting dan laporan temuan bug dicatat pada fitur Issue private repo Bitbucket kita, otomatis semua catatan akan tersimpan kan ya? Ini sangat bermanfaat agar kita dapat :

“Trace back” apa saja yang telah dikerjakan
Mengetahui beberapa banyak bug yang kita tangani
Mengetahui berapa banyak improvement yang diminta oleh User/Klien
Review kapan kita menyelesaikan issue yang mana
Review siapa yang menyelesaikan issue yang mana
Evaluasi dari titik ketika project kita anggap selesai sampai project benar-benar selesai.

Kesimpulan

Baik, kita ambil kesimpulan dari artikel ini, yaitu jika kita menggunakan fitur bitbucket issue untuk mencatat item-item pekerjaan terkait bug dan small improvement dalam sebuah project, kita mendapatkan beberapa manfaat :

Catatan laporan problem terpusat di satu tempat
Catatan permintaan improvement (feature request) terpusat di satu tempat
Memilah mana item pekerjaan yang sudah dan belum dikerjakan
Memilah mana item pekerjaan yang harus dikerjakan duluan sesuai prioritasnya
Evaluasi seberapa banyak bug yang ditemukan oleh user/klien
Evaluasi seberapa banyak small improvement yang diminta oleh user/klien
Minimalisir hilang catatan dan kata “saya lupa”.

Satu catatan dari saya untuk pemanfaatan sarana ini (dari sudut pandang freelancer). Sarana ini hanya cocok untuk mencatat laporan bug dan improvement kecil untuk sebuah project, kurang cocok jika digunakan untuk mencatat fitur-fitur utama project atau pembagian tugas sejak awal project.

Karena jika digunakan sejak awal project, banyak waktu akan habis untuk menulis issue ini. Kecuali ada pertimbangan yang mungkin belum terpikir oleh saya.

Tentunya manfaat-manfaat tersebut di atas bersifat subyektif berdasarkan opini saya pribadi. Jika teman-teman memiliki opini lain, silakan disampaikan pada komentar, agar saya mendapatkan pencerahan baru dari teman-teman.

Terima kasih atas waktunya, semoga tulisan ini menjadi manfaat untuk kita semua. Aamiin..

Testing Laravel: Tips untuk Workflow TDD

Fri, 05 Jan 2018 22:00:00 +0800

Bismillahirrahmanirrahim.

Ketika mengerjakan project Laravel dengan metode TDD, bisa jadi ada kejenuhan. Misalnya kita “terpaksa” harus mengetik perintah vendor/bin/phpunit di terminal setiap kali kita ingin menjalankan PHPUnit. Well, jenuh juga mengetik perintah itu berulang-ulang, atau kita bolak-balik ke terminal untuk menekan tombol panah atas (history terminal), kemudian tekan tombol Enter untuk menjalankan PHPUnit.

Atau ketika kita menjalankan testing, kita menunggu testing berjalan hingga sampai titik yang sedang dikerjakan, padahal (sebenarnya) hanya perlu menjalankan testing untuk satu fitur yang sedang dikerjakan saja.

Atau saat testing berjalan, prosesnya ada yang lambat, tetapi kita tidak tahu proses yang lambat itu pada Test Case atau Test method yang mana?

Problem

Nah, problem seperti ini saya temukan di 1-6 bulan pertama saya belajar TDD :

Menjalankan perintah PHPUnit berulang-ulang (ini melanggar DRY, kan?).
Menunggu jalannya testing hingga sampai titik yang sedang dikerjakan (menunggu error muncul).
Semua testing passed, tetapi prosesnya lambat, dan tidak tahu di titik mana testing yang lambat itu terjadi (karena yang tampil di terminal hanya titik-titik saja).
Problem di database, di mana data yang di-generate oleh model factory (saat jalannya testing) dapat menjadikan hasil test yang berbeda.

Dari beberapa problem tersebut, saya mencari tips dari artikel-artikel di internet untuk menemukan solusinya.

Solusi dan Tips

Berikut ini beberapa tips dan solusi yang bisa saya bagi ke teman-teman, mungkin ada yang belum tahu dan bisa menjadi referensi.

Run Test on file change

Solusi untuk problem pertama kita adalah PHPUnit Watcher. Ketika kita menjalankan perintah phpunit-watcher watch pada project Laravel kita, maka dia akan menjalankan PHPUnit, kemudian menunggu perubahan file .php yang ada di dalam direktori app dan tests dalam project Laravel kita.

Yap, ketika phpunit-watcher ini “standby”, setiap ada file php yang di-save pada kedua direktori tersebut, PHPUnit langsung dijalankan, kemudian memberikan hasilnya (passed atau failed) dengan notifikasi desktop.

Dampak positifnya, kita tidak perlu repot bolak balik terminal untuk menjalankan vendor/bin/phpunit. Kita bisa fokus “ngoding” di text-editor atau IDE kita. Ini sangat efektif dalam memangkas waktu development kita dalam workflow TDD. Jika teman-teman ingin mencobanya, silakan langsung ikuti petunjuk instalasinya.

https://github.com/spatie/phpunit-watcher

Ini screenshot phpunit-watcher saat “standby” menunggu perubahan file.

Referensi:
Saya dapat tips tentang tool ini dari video Laracon EU Amo Chohan. Kalau teman-teman ada waktu, silakan lihat videonya dari awal sampai selesai, tips-tipsnya sangat bermanfaat.

Menggunakan trait DatabaseTransaction

Trait DatabaseTransaction pada Test Case class Laravel adalah alat bantu yang akan mengembalikan kondisi database kita setiap sebuah test method selesai dijalankan. Dengan bantuan trait ini, kita tinggal melakukan persiapan data pada database khusus untuk testing (pada project yang bersangkutan).

Script-script testing kita dapat menggunakan record-record pada database tersebut saat menjalankan test. Setiap satu testing method selesai, database dikembalikan seperti semula. Trait ini sangat berguna saat kita ingin mulai membuat testing untuk project Laravel existing yang belum ada testingnya.

Tips:
Jika ingin mulai membuat testing untuk project Laravel existing, jangan lupa memisahkan database yang digunakan untuk testing dengan database aplikasi.

Mendeteksi test method yang lambat

Seperti yang kita bahas pada paragraf pembuka di atas, ada kalanya testing berjalan lambat, tapi kita tidak mengetahui pada test method mana yang prosesnya lambat. Solusi yang bisa kita gunakan adalah sebuah paket bernama phpunit-speedtrap.

https://github.com/johnkary/phpunit-speedtrap

“SpeedTrap helps you identify slow tests but cannot tell you why those tests are slow.”

Jadi tool ini hanya memberi tahu kita jika ada testing yang berjalan lambat (satu test jalan lebih dari 500ms), tetapi dia tidak dapat memberitahu kenapa testingnya lambat. Tugas kita lah sebagai developer untuk menemukannya.

Beberapa hal yang saya temukan dapat membuat testing lambat :

Terlalu banyak meng-generate record yang “tidak perlu” melalui model factory. Karena itu kita perlu memperhatikan ini pada saat membuat model factory :
Using Factories -> Relationships -> Relations & Attribute Closures
Terdapat N+1 problem pada aplikasi controller/view yang sedang di-test. Apa itu N+1? Yaitu ada query ke database dalam sebuah loop. Referensinya lihat di sini atau di sini.
Ada batch insert record ke dalam database yang terlalu banyak dalam satu test.
Terdapat API Request ke pihak ketiga, di mana request tersebut bergantung kepada koneksi internet PC/laptop kita.

Jadi ketika sudah menggunakan phpunit-speedtrap ini, kita mendapat kesempatan untuk me-refactor testing kita agar lebih optimal. Contoh penggunaannya? Silakan coba install project Free PMO di localhost teman-teman, kemudian jalankan testingnya.

Menggunakan command option ‘–filter’

Ketika testing kita sudah mulai banyak, pastinya kita akan menunggu jalannya testing lebih lama. Bandingkan testing untuk dua project berikut :

dengan

Jika kita memiliki banyak test method (yang dilambangkan dengan satu tanda titik), maka semakin lama waktu yang diperlukan oleh PHPUnit untuk menyelesaikan seluruh test.

Jika kita ingin membatasi agar PHPUnit menjalankan test hanya pada bagian tertentu saja, maka kita bisa gunakan option command --filter. Contoh :

$ vendor/bin/phpunit --filter ReceiptCollectionTest

“ReceiptCollectionTest” adalah (semacam) kata kunci. Kata kunci ini dapat berupa (bagian dari) nama class TestCase atau (bagian dari) nama test method. Jadi hanya class test case atau test method itu saja yang akan dijalankan oleh PHPUnit (disesuaikan dengan fitur yang sedang kita kerjakan).

Menggunakan command option ‘–stop-on-failure’

Langsung pada contohnya :

$ vendor/bin/phpunit --filter ReceiptCollectionTest --stop-on-failure

Dari situ kita bisa lihat, command option --stop-on-failure adalah perintah kepada PHPUnit agar segera menghentikan jalannya test ketika menemukan test yang gagal (ada pesan error). Tujuannya agar kita tidak perlu menunggu sampai testing selesai dijalankan untuk melihat pesan error yang tampil pada terminal.

Btw, kita juga dapat memberikan command option ini pada saat menggunakan phpunit-watcher.

Menggunakan script ‘Hash::setRounds(5)’

Nah, script Hash::setRounds(5) ini benar-benar mengurangi durasi waktu test, utamanya jika script-script testing ada yang melibatkan function bcrypt(). Umumnya jika dalam testing kita menggunakan fitur autentikasi atau login user, kemungkinan besar menggunakan bcrypt() ini, yaitu pada factory untuk model User.

Kita bisa menempatkan script Hash::setRounds(5) ini pada class Base TestCase kita. Contoh penggunannya, kita bisa cek script ini digunakan pada trait CreatesApplication.php di project Free PMO.

Jika kita jalankan testnya:

Kemudian uncomment Hash::setRounds(5) trait CreatesApplication.php.

<?php
// tests/createApplication.php

public function createApplication()
{
    $app = require __DIR__.'/../bootstrap/app.php';

    $app->make(Kernel::class)->bootstrap();
    // \Hash::setRounds(5);

    return $app;
}

Jika kita jalankan testing lagi :

Nah kelihatan, kan? Lumayan selisih waktunya 2x lipat lebih cepat. Artinya script Hash::setRounds(5) ini sangat berpengaruh pada kecepatan jalannya testing kita.

Saya belum tahu persis apa makna/fungsi dari script ini. Silakan teman-teman cek artikel ini Two tips to speedup your Laravel tests.

Memanfaatkan (Bash) Aliases

Saya menggunakan OS Ubuntu 16.04 untuk bekerja. Saya mendaftarkan alias perintah-perintah yang sering digunakan untuk mempercepat mengetik perintah di terminal. Beberapa yan saya gunakan untuk mempercepat workflow TDD Laravel :

# phpunit
alias punit='vendor/bin/phpunit'
alias punitf='vendor/bin/phpunit --filter'
alias punits='vendor/bin/phpunit --stop-on-failure'
alias punitsf='vendor/bin/phpunit --stop-on-failure --filter'

# phpunit-watcher
alias wpunit='phpunit-watcher watch'
alias wpunitf='phpunit-watcher watch --filter'
alias wpunits='phpunit-watcher watch --stop-on-failure'
alias wpunitsf='phpunit-watcher watch --stop-on-failure --filter'

Kesimpulan

Nah demikian teman-teman, kita sudah membahas beberapa tips yang biasa saya gunakan dan manfaatkan untuk mempermudah, mempercepat, dan mengurangi kejenuhan dalam menerapkan workflow Test-Driven Development dalam project Laravel. Mudah-mudahan bermanfaat menjadi referensi bagi teman-teman yang membutuhkan.

Jika ada masukan terkait tips-tips ini, atau ada tips lain yang bisa teman-teman share, silakan disampaikan di komentar.

Terima kasih atas waktunya.

Testing Laravel: Apa Saja yang Perlu Dibuatkan Test?

Sat, 30 Dec 2017 15:20:00 +0800

Bismillahirrahmanirrahim.

Jika kita baru mulai menerapkan Test-Driven Development dalam mengerjakan project, mungkin awalnya kita bingung, bagian mana saja yang perlu dibuatkan testing? Oke lah, yang jelas fitur CRUD, lalu pada artikel yang lalu kita sudah tahu tentang Model Behaviour, kita juga perlu membuat unit testing untuk itu. Lalu apa lagi yang perlu kita buat test selain itu? Baik kita bahas sama-sama bagian mana saja (yang menurut saya) harus kita buatkan testing scriptnya.

Di sini juga akan kita bahas pembagian level class Test Case (class testing script) dari yang saya pahami dan terapkan secara umum. Apakah sebuah Test Case masuk ke level Feature Test atau ke level Unit Test.

Level Feature Test

Pada bagian ini, class Test Case ditempatkan pada direktori tests/Feature di project Laravel. Test Case yang masuk ke dalam Feature test adalah fitur-fitur utama dalam aplikasi, seperti entry data, edit data, hapus data dan API endpoint.

1. Fitur CRUD

Pertama yang utama adalah fitur-fitur yang berinteraksi dengan perubahan record pada database. Misalnya fitur entry artikel, edit artikel, hapus artikel, pengelolaan kategori artikel, dan fitur-fitur lain. Dalam Test Case ini kita definisikan fitur sesuai dengan spesifikasi kita.

Misalnya, saat “create” record, field-fieldnya apa saja, mana yang wajib diisi, mana yang nullable. Kemudian saat “update” record, mana yang wajib mana yang nullable, dan saat “delete” record, kondisi apa saya yang harus terpenuhi sehingga user boleh menghapus record tersebut dari database.

Contoh class Test Case Fitur CRUD (silakan klik link untuk melihat source-code nya) :

2. API Endpoints

Jika pada sistem kita terdapat web service atau API, sebaiknya seluruh Endpoint API-nya dibuatkan test, untuk memastikan parameter yang dikirimkan ke endpoint, serta respons yang dihasilkan dari endpoint sudah sesuai dengan spesifikasi yang diinginkan.

Mirip seperti Fitur CRUD pada point nomor 1 di atas, jika pada API Endpoint terdapat interaksi yang mengubah record pada database, sebaiknya pada Test Case untuk API Endpoint dibuatkan sesuai spesifikasi yang diinginkan.

Contoh class Test Case Fitur API Endpoint :

Level Unit Test

Pada bagian ini, class-class Test Case kita akan masuk dalam direktori tests/Unit pada project Laravel. Pertimbangannya adalah, karena kita menguji bagian-bagian kecil dari sistem/aplikasi kita. Misalnya pengujian terhadap method-method khusus pada class Model (Model Behaviour), hak akses/otorisasi user terhadap sebuah model (record), pengujian helper functions, dan pengujian untuk class-class PHP yang dibuat untuk membantu jalannya sistem.

1. Model Behaviour

Seperti yang sempat kita bahas pada artikel terdahulu, model behaviour adalah method-method khusus yang kita tambahkan pada class Model Laravel. Yang bertujuan untuk refactor method di controller, atau membuat source-code kita lebih “readable” karena mirip seperti pendelegasian tugas dan definisi “jobdeks” dari sebuah model.

Termasuk di dalamnya pendefinisian relasi antar model (antar tabel) dan attribute model yang didefinisikan melalui Eloquent Accessor.

Contoh class Test Case Model Behaviour :

Test Case ProjectTest, untuk relationship dan method class model Project.
Test Case SubscriptionTest, untuk relationship dan method class model Subscription (langganan).
Test Method a_job_has_progress_attribute, untuk menguji Eloquent Accessor atribute “progress” pada model Job. Di mana nilai atribute progress dihitung berdasarkan rata-rata progress task pada job tersebut.
Test Case ProductTest, untuk class model Product.
Test Case PersonRelationTest, untuk menguji hubungan antar (model) User para project Aplikasi Silsilah.

2. Model Policy

Sedikit pengantar tentang Model Policy Object pada Laravel, Model policy adalah salah satu fitur Laravel yang (menurut saya) sangat bermanfaat untuk kebutuhan pengendalian akses user dalam sistem. Fitur ini benar-benar menghemat penggunaan fungsi “if”, baik di view maupun di controller.

Contoh kasusnya dalam sistem, misal halaman detail sebuah “project” dapat diakses oleh seluruh user, tetapi “nilai project” hanya dapat dilihat oleh user dengan role Project Manager dan Admin. Atau misal detail sebuah “job” dalam “project” hanya dapat di-edit oleh project manager dan pekerja yang ditugaskan ke dalam project itu, petugas dengan job lain tidak boleh meng-edit. Nah, model policy sangat bermanfaat untuk keperluan seperti ini.

Contoh class Test Case Model Policy :

Test Case UserPolicyTest, untuk menguji class UserPolicy.
Test Case CustomerPolicyTest, untuk menguji class CustomerPolicy.

4. Service Class

Service class adalah class-class PHP yang kita buat pada project kita yang digunakan untuk membantu jalannya sistem. Misal aplikasi kita memiliki fitur Shopping Cart, kemudian kita membuat sebuah class PHP bernama “Cart” dengan berbagai method dan property didalamnya agar fitur Shopping Cart yang kita inginkan dapat berjalan sesuai spesifikasi.

Untuk memastikan class “Cart” (service class) tadi berjalan sesuai dengan target, maka kita membuatkan test case untuk class tersebut.

Contoh class Test Case Service Class :

Test Case CartCollectionTest, untuk menguji service class CartCollection. Service class ini digunakan pada fitur Shopping Cart atau Draft Transaksi untuk project Grosir Obat.
Test Case InvoiceDraftCollectionTest, untuk menguji service class InvoiceDraftCollection. Service class ini digunakan pada fitur Draft Invoice (Entry Invoice) untuk project Free PMO.

Contoh lain adalah ketika kita membuat sebuah service class untuk mengintegrasikan sistem kita dengan API dari luar, misal Twitter, Instagram, atau Raja Ongkir. Service class ini juga perlu kita buatkan Test Case untuk memastikan komunikasi dengan API dari pihak luar tersebut berjalan sesuai dengan spesifikasi kita. Tetapi kebetulan saya belum ada contoh source-code untuk yang ini.

6. Number Generators

Kalau kita pernah membuat sebuah fitur penomoran atau kode otomatis untuk sistem kita, misal saat input invoice kemudian secara otomatis sistem memberi nomor urut invoice tersebut dengan pola tertentu, maka semestinya penomoran otomatis tersebut kita buatkan testing juga.

Misal sistem membuat penomoran otomatis (number generator) berdasarkan pola berikut: INV-aabbxxx di mana :

aa adalah tahun 2 digit
bb adalah bulan 2 digit
xxx adalah nomor urut invoice pada bulan tersebut

Maka seharusnya kita membuat testing untuk memastikan aplikasi kita meng-generate nomor urut yang benar setiap invoice dibuat.

Contoh sederhana testing script untuk menguji penomoran otomatis invoice seperti ini : it_generates_its_own_number. Test method ini pada dasarnya digunakan untuk menguji model behaviour pada model Invoice, tetapi contoh penggunaanya ada pada model factory invoice-nya.

Hmm.. terlihat agak repot ya. Kebetulan perihal “testing number generator” ini saya baru dapat ilmunya sekitar 2 bulan yang lalu, bahwa fitur-fitur yang menggunakan number generator itu (seharusnya) dibuatkan testing scriptnya. Saat artikel ini ditulis, belum ada contoh lain yang bisa saya sampaikan. Asumsi saya pribadi, testing number generator ini harus dibuatkan class Test Case class sendiri. Untuk memastikan semua kemungkinan/kondisi dapat diakomodir oleh testing scriptnya.

Insyaallah bagian ini akan saya update jika sudah ada contoh untuk testing number generator.

Test Case Tambahan (Optional)

Item-item yang sudah kita bahas di atas (menurut saya) adalah item-item yang harus dibuatkan test (prioritas utama), karena posisinya sangat vital pada sistem/aplikasi. Ada beberapa item lagi yang biasanya saya buatkan test case, sebagai pendukung.

1. Helper Function

Ketika kita membuat beberapa function helper, entah untuk mempersingkat script, atau agar beberapa baris script dapat “reusable” dalam source-code kita (prinsip DRY), ada baiknya function-function helper tersebut kita buatkan testing script juga. Sekedar memastikan bahwa function tersebut bekerja dengan baik pada versi Laravel/versi PHP yang kita gunakan sekarang.

Salah satu contoh function helper yang dibuatkan test case :

Test Case AppLogoImageTest, untuk menguji function helper appLogoImage().

Sementara baru satu contoh itu, mudah-mudahan jika nanti ada contoh lain, bagian ini bisa saya update.

2. Model Factory

Item pendukung lainnya yang bisa dibuatkan Test Case adalah Model Factory. Biasanya testing diperlukan untuk model factory yang memiliki beberapa state atau defineAs (seperti contoh model factory ini).

Kita membuat testing untuk model factory untuk memastikan record yang di-generate oleh model factory sesuai dengan kebutuhan (umumnya untuk keperluan automated testing).

Kesimpulan

Baik, dengan pembahasan diatas, kita tarik beberapa kesimpulan tentang “Apa saja yang perlu dibuatkan test pada project Laravel?”.

Fitur utama yang harus dibuatkan test adalah fitur CRUD, yaitu saat fitur tersebut berinteraksi dengan perubahan record pada database.
**Feature Test Case class dibuat terlebih dahulu saat kita bekerja dengan metode TDD.
Unit Test Case class dibuat sebagai pendukung bagian-bagian kecil dari sebuah fitur (yang diuji dengan Feature Test).

Hal-hal yang kita bahas di atas merupakan pendapat saya pribadi, bisa jadi tidak sesuai dengan pendapat teman-teman sekalian, dan bisa jadi akan berubah menyesuaikan kebutuhan di masa datang.

Jika ada masukan pendapat dari teman-teman pembaca, saya akan sangat berterima kasih sekali. Setidaknya harapan saya, mudah-mudahan pembahasan kali ini dapat menjadi referensi ketika kita jika masih ada pertanyaan :

“Apa saja/bagiam mana yang harus dibuatkan test dalam project Laravel saya?”

Terima kasih atas waktu teman-teman sudah berkenan membaca. :)

Testing Laravel: Setup Codeship CI untuk Private Project

Thu, 28 Dec 2017 15:30:00 +0800

Bismillahirrahmanirrahim.

Kali ini kita menyambung pembahasan seputar Continuous Integration lagi. Sebelumnya kita sudah sempat membahas cara setup layanan Travis CI untuk project open-source. Nah, karena karena kebanyakan project kita berupa private repo, maka kali ini kita bahas tentang Setup Codeship CI untuk private project juga (dengan hosting source-code di BitBucket).

Sebagaimana yang kita bahas sebelumnya, layanan Codeship CI ini sangat cukup untuk kebutuhan freelance web developer (utamanya yang single fighter). Untuk akun gratisnya (Codeship Basic), kita mendapatkan 100 builds per bulan dengan jumlah project unlimited. Artinya, jika setiap hari kita melakukan push ke BitBucket 2 kali (misal siang dan sore). Maka sehari kita akan men-trigger 2 build, atau lebih kurang 60 build per bulan. Cukup kan? :)

Baik, pada artikel ini ada 4 langkah setup Codeship CI untuk private project Laravel di Bitbucket:

Push source-code ke BitBucket
Login ke Codeship.com dengan akun BitBucket
Buat project baru pada Codeship untuk project kita
Trigger “First Build” layanan Codeship CI

Kita mulai

Jika belum memiliki project untuk praktek, silakan teman-teman clone project Laravel-TDD ini ke localhost, kemudian buat project private baru di BitBucket, push source-code nya ke BitBucket.

1. Push source-code Project ke Private repo Bitbucket

Pertama, pastikan source-code project laravel kita sudah disetor ke BitBucket dengan Access level private repository. Seperti yang tampil pada gambar di bawah ini.

Seperti kita lihat, pada list commit ini, di paling kanan terdapat kolom Builds. Kolom itu yang nanti akan terisi ketika layanan Codeship mendapatkan hasil passed atau failed.

Kunjungi situs codeship.com.
Klik “SIGN UP FOR FREE”.
Login dengan akun BitBucket.
Ikuti langkah selanjutnya hingga kita mendapatkan tampilan seperti gambar di bawah (menu Projects).

3. Buat project baru pada Codeship

Klik tombol “New Project” pada halaman Projects.
Klik icon “Connect to Bitbucket”.
Masukkan url git repo BitBucket kita, contoh di saya: git@bitbucket.org:nafiesl/laravel-tdd.git.
Klik “Connect”.
Klik “Select Basic project”.
Kita lanjutkan dengan mengisi form Setup Commands dengan script berikut :

Silakan copy script nya :

phpenv local 7.0
echo "memory_limit = 512M" >> /home/rof/.phpenv/versions/$(phpenv version-name)/etc/php.ini
# install dependencies
COMPOSER_HOME=${HOME}/cache/composer
composer install --prefer-dist --no-interaction
# set up environment variables
touch .env
echo "APP_ENV=testing" >> .env
echo "APP_DEBUG=true" >> .env
echo "APP_KEY=base64:sQPFP80eWJQGo0SDPc+M2Tib+GLUocRYRw4RLsfM27I=" >> .env

Kemudian isikan Test Commands dengan perintah PHPUnit : vendor/bin/phpunit

Klik Save and go to dashboard.

Sip, sampai di sini selesai proses Setup project Codeship CI. Saat ini codeship standby menunggu commit baru yang dipush ke repo BitBucket kita.

4. Trigger “First Build”

Untuk membuat layanan Codeship CI mulai bekerja, kita coba membuat commit pada repo dengan cara meng-edit file README.md langsung di BitBucket. Pada repo project ini, sebelumnya kita menggunakan badge status Travis CI pada file README.md, kita coba hapus saja bagian badge tersebut. Kemudian langsung commit perubahannya.

Sekarang kita lihat layanan Codeship CI langsung bekerja untuk menjalankan build dan test hingga selesai.

Sip, proses Build dan Test selesai dan SUCCESS. Kemudian kita bisa lihat source-code kita di BitBucket menu list commit. Di kolom Builds paling kanan kita melihat 1 of 1 passed.

Selesai praktek kita setup Codeship CI untuk Private Project Laravel di BitBucket.

Kesimpulan

Kita coba simpulkan pembahasan kita pada artikel ini:

Layanan Codeship CI yang gratis (Codeship Basic) sangat cukup untuk kebutuhan freelance web developer yang ingin menggunakan Coontinuous Integration pada project-project privatenya.
Cara setup Codeship CI agak berbeda dengan setup layanan Travis CI.
Cara kerja layanan Codeship CI serupa dengan Travis CI, yaitu bekerja setiap menerima push dan pull-request di repo BitBucket.

Baik, demikian teman-teman, mudahan bermanfaat pembahasan kita tentang setup Codeship CI untuk Private Project. Jika ada yang ingin didiskusikan, silakan tuliskan di kolom komentar.

Terima kasih atas waktunya.

Testing Laravel: Refactor Controller dengan Model Behaviour

Wed, 27 Dec 2017 22:45:00 +0800

Bismillahirrahmanirrahim.

Pada artikel sebelumnya kita sudah membahas tentang toggle status task, kali ini kita melakukan refactor pada method TasksController@toggle untuk fitur tersebut. Sekarang coba teman-teman lihat potongan script berikut :

<?php

// TasksController

    // ... method destroy

    public function toggle(Task $task)
    {
        if ($task->is_done == 1) {
            $task->is_done = 0;
        } else {
            $task->is_done = 1;
        }

        $task->save();

        return back();
    }

Kemudian kita bandingkan dengan ini.

<?php

// TasksController

    // ... method destroy

    public function toggle(Task $task)
    {
        $task->toggleStatus();

        return back();
    }

Kira-kira lebih “readable” mana? Pasti potongan script yang kedua, kan ya? Dengan script yang kedua, ibarat :

TasksController adalah seorang manager.
Task model adalah staff (dari manager) untuk mengurus record-record tabel task.
Method toggleStatus() adalah jobdesk untuk staff agar mengubah nilai is_done.
Manager memberi perintah kepada staffnya dengan memanggil method toggleStatus().
Staff melakukan tugasnya sesuai perintah dan jobdesk yang sudah didefinisikan.
Setelah staff selesai bekerja, manager kembali melanjutkan tugasnya, yaitu return back();

Insyaallah mudah dipahami ya? Inilah yang saya pahami dari cara kerja Object Oriented Programming, di mana ada interaksi antar object (class), dan setiap object akan bekerja sesuai dengan tugas dan tujuannya.

Kita mulai

Baik, seperti biasa, sebelum mulai edit sana-sini, kita jalankan PHPUnit dulu, sekedar memastikan kita dapat hijau.

# 1
$ vendor/bin/phpunit

Seharusnya kita tetap dapat OK (8 tests, 47 assertions).

Baik, kita lanjutkan dengan membuka file TasksController, kemudian kita edit method toggle sesuai dengan keperluan kita.

<?php

// TasksController

    // ... method destroy

    public function toggle(Task $task)
    {
        // if ($task->is_done == 1) {
        //     $task->is_done = 0;
        // } else {
        //     $task->is_done = 1;
        // }

        // $task->save();

        $task->toggleStatus();

        return back();
    }

Simpan, dan jalankan PHPUnit.

# 2
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks/1/toggle] failed. Received status code [500]
...
Caused by
BadMethodCallException: Call to undefined method App\Task::toggleStatus() ...

Penyebab

Kita belum memiliki method toggleStatus() pada model App\Task.

Solusi

Kita buat method toggleStatus() pada model App\Task.

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Task extends Model
{
    protected $fillable = ['name', 'description'];

    public function toggleStatus()
    {
        //
    }
}

Simpan, jalankan PHPUnit

# 3
$ vendor/bin/phpunit

Hasil: Error

Unable to find row in database table [tasks] that matched attributes
[{"id":1,"is_done":0}].
Failed asserting that 0 is greater than 0.

Penyebab

Method toggleStatus() pada model App\Task belum melakukan apa-apa.

Solusi

Kita definisikan script untuk toggle status is_done pada method toggleStatus() di model App\Task. Di sini serupa dengan kita mendifinisikan “jobdesk” atau tugas agar model App\Task mengubah status is_done.

Membuat unit test untuk model ‘App\Task’

Untuk mendefinisikan tugas model ini, mari kita buat Unit Test untuk model App\Task, untuk memastikan method ini berjalan sesuai dengan keinginan kita (yaitu mengubah nilai is_done).

$ php artisan make:test --unit Models/TaskTest

Laravel akan membuat test class baru tests/Unit/Models/TaskTest.php. Sekarang kita edit file tersebut.

<?php

namespace Tests\Unit\Models;

use App\Task;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class TaskTest extends TestCase
{
    use RefreshDatabase;

    /** @test */
    public function task_model_has_toggle_status_method()
    {
        // Generate 1 record task pada table `tasks`.
        $task = factory(Task::class)->create();

        // Panggil method `toggleStatus()` pada model `App\Task`
        $task->toggleStatus();

        // Kolom is_done pada record task berubah menjadi 1
        $this->seeInDatabase('tasks', [
            'id'      => $task->id,
            'is_done' => 1,
        ]);

        // Panggil method `toggleStatus()` pada model `App\Task` (lagi)
        $task->toggleStatus();

        // Kolom is_done pada record task berubah menjadi 0
        $this->seeInDatabase('tasks', [
            'id'      => $task->id,
            'is_done' => 0,
        ]);
    }
}

Secara umum, struktur method test ini mirip seperti Feature Test untuk toggle status pada artikel sebelumnya, tetapi disini tidak ada submit form, kita hanya menguji method toggleStatus() dari model App\Task saja, maka dari itu testing ini kita golongkan sebagai Unit Test.

Baik, pastikan simpan file ini dan jalankan PHPUnit. Tetapi kali ini kita hanya menjalankan PHPUnit untuk satu class saja, yaitu TaskTest, sehingga kita tambahkan parameter --filter TaskTest pada perintah PHPUnit.

# 4
$ vendor/bin/phpunit --filter TaskTest

Hasil: Error

Unable to find row in database table [tasks] that matched attributes
[{"id":1,"is_done":0}].
Failed asserting that 0 is greater than 0.

Penyebab

Method toggleStatus() pada model App\Task belum melakukan apa-apa (ini mirip seperti hasil error sebelumnya ya).

Solusi

Kita definisikan script untuk toggle status is_done pada method toggleStatus() di model App\Task. Script nya bisa kita tiru dari script di method TasksController@toggle, tetapi variabel $task kita ganti dengan $this, karena saat ini kita sedang meng-edit class App\Task itu sendiri.

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Task extends Model
{
    protected $fillable = ['name', 'description'];

    public function toggleStatus()
    {
        if ($this->is_done == 1) {
            $this->is_done = 0;
        } else {
            $this->is_done = 1;
        }

        $this->save();

        return $this;
    }
}

Baik kita jalankan lagi PHPUnit dengan --filter TaskTest.

# 5
$ vendor/bin/phpunit --filter TaskTest

Hasilnya :

{:id=“toggleStatus-method-test-passed”}

Sip kita sudah dapat hijau untuk testing model TaskTest.

Sekarang kita jalankan PHPUnit untuk keseluruhan testingnya.

# 6
$ vendor/bin/phpunit

Hasilnya :

OK (9 tests, 49 assertions). Yap, secara otomatis semua testing script passed. Mengapa? Karena testing yang failed (error) pada tahap #3 ini, disebabkan oleh “perkara yang sama” dengan testing yang failed pada tahap #4, yaitu karena kita belum mendefinisikan tugas dari method toggleStatus().

Ketika method toggleStatus() sudah dibuat sesuai tugasnya (mengubah nilai is_done), dan testing tahap #5 passed, maka tahap #3 ini juga akan passed.

Dengan demikian refactor yang kita lakukan untuk method TasksController@toggle ini berjalan sukses.

Kesimpulan

Baik, sampai disini kita simpulkan manfaat dari refactor controller ke sebuah method pada model, karena kemungkinan diantara teman-teman ada yang bertanya :

“Mengapa repot-repot merefactor method TasksController@toggle ini? Kan method ini tidak terlalu sulit dipahami, ya? Lalu dibuatkan unit testing pula, kenapa?”.

Jawabannya kita buat kesimpulan :

Method dari controller menjadi lebih ramping.
Script pada controller menjadi “readable” (lebih mudah dipahami).
Controller (sebagai manager) tinggal memerintahkan model (sebagai staffnya) sesuai dengan “jobdesk”-nya.
Method toggleStatus() pada model App\Task adalah model behaviour atau perilaku model.
Unit testing untuk model memastikan bahwa model behaviour bekerja sesuai spesifikasi, atau bisa dikatakan, model berperilaku sebagaimana yang kita inginkan.

Bisa dibayangkan jika pada project-project aplikasi yang kita buat, kita dapat me-refactor method-method pada controller ke dalam method-method model, agar method-method pada controller kita tidak “gendut”.

Hal ini juga akan membuat source-code kita menjadi lebih “readable”, baik untuk orang lain yang melihat/me-review source-code yang kita kerjakan, maupun untuk diri kita sendiri (jika melihat source-code ini beberapa bulan setelah project selesai).

Baik teman-teman, demikian pembahasan kita tentang “refactor controller dengan model behaviour”. Mudah-mudahan pembahasan pada artikel ini dapat menjadi inspirasi bagi teman-teman dalam melakukan refactor controller.

Semua perubahan script project Testing-TDD pada artikel ini bisa dilihat pada commit ini (dengan sedikit clean-up).

Terima kasih teman-teman atas waktunya.

Testing Laravel: Toggle Status Task dengan Form Button

Tue, 26 Dec 2017 15:24:00 +0800

Bismillahirrahmanirrahim.

Kalau teman-teman ingat, pada artikel saat mendapatkan passed test, kita membuat file migration untuk tabel tasks dengan kolom is_done untuk menyatakan status task yang bersangkutan. Dari kemarin-kemarin kita belum melakukan apa-apa terhadap kolom tersebut karena secara default dia bernilai 0. Nah sekarang kita akan mencoba memanfaatkan kolom tersebut untuk mengubah status task.

Jika teman-teman sudah mengikuti artikel Testing Laravel ini dari awal, silakan menggunakan projectnya. Saya akan mulai dari commit ini pada repo Laravel-TDD ini.

Seperti biasa, sebelum mulai kita jalankan testing dulu untuk memastikan project kita dalam kondisi “sehat”.

# 1
$ vendor/bin/phpunit

Seharusnya kita tetap dapat hasil OK (7 tests, 36 assertions).

Membuat Failing Test

Baik, kita lanjutkan dengan membuat test method untuk fitur toggle status task ini. Pertama kita buka file tests/Feature/ManageTasksTest.php, kemudian kita tambahkan satu test method baru user_can_toggle_task_status.

<?php

// ...

class ManageTasksTest extends TestCase
{
    // ... user_can_create_a_task()

    // ... user_can_browse_tasks_index_page()

    // ... user_can_edit_an_existing_task()

    // ... user_can_delete_an_existing_task()

    /** @test */
    public function user_can_toggle_task_status()
    {
        //
    }
}

Sekarang kita buat PHP Comment line untuk membantu kita membuat testing script.

<?php

    /** @test */
    public function user_can_toggle_task_status()
    {
        // Generate 1 record task pada table `tasks`.

        // User membuka halaman Daftar Task.

        // User tekan tombol dengan id="toggle_task_1"

        // Lihat halaman web ter-redirect ke halaman daftar task

        // Kolom is_done pada record task berubah menjadi 1

        // User tekan tombol dengan id="toggle_task_1" (lagi)
        // untuk mengembalikan status task

        // Lihat halaman web ter-redirect ke halaman daftar task

        // Kolom is_done pada record task berubah menjadi 0
    }

Sekarang kita buat testing script-nya.

<?php

    /** @test */
    public function user_can_toggle_task_status()
    {
        // Generate 1 record task pada table `tasks`.
        $task = factory(Task::class)->create();

        // User membuka halaman Daftar Task.
        $this->visit('/tasks');

        // User tekan tombol dengan id="toggle_task_1"
        // Dimana angka 1 adalah id dari $task
        $this->press('toggle_task_'.$task->id);

        // Lihat halaman web ter-redirect ke halaman daftar task
        $this->seePageIs('/tasks');

        // Kolom is_done pada record task berubah menjadi 1
        $this->seeInDatabase('tasks', [
            'id'      => $task->id,
            'is_done' => 1,
        ]);

        // User tekan tombol dengan id="toggle_task_1" (lagi)
        // untuk mengembalikan status task
        $this->press('toggle_task_'.$task->id);

        // Lihat halaman web ter-redirect ke halaman daftar task
        $this->seePageIs('/tasks');

        // Kolom is_done pada record task berubah menjadi 0
        $this->seeInDatabase('tasks', [
            'id'      => $task->id,
            'is_done' => 0,
        ]);
    }

Cukup panjang ya, karena di sini kita menguji “toggle”, ketika tombol yang sama ditekan, maka statusnya akan kembali ke status sebelumnya.

Mendapatkan Passed Test

Baik, simpan file, kita mulai jalankan PHPUnit.

# 2
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Could not find a form that has
submit button [toggle_task_1].

Penyebab

Kita belum memiliki form yang memiliki tombol toggle_task_1. Di mana toggle_task_1 bisa berupa tulisan atau atribut value pada tombol submit, bisa juga berupa atribut id dari tombol submit tersebut.

Solusi (Membuat Form Button)

Pada view tasks.index bagian daftar Task (di bawah form delete task) kita buat form dengan tombol toggle_task_1.

<!-- resources/views/tasks/index.blade.php -->

<!-- @foreach ($tasks as $task) -->
<li class="list-group-item">
    <form action="{% raw" >}}{{ url('tasks/'.$task->id) }}{% endraw" >}}" method="post" class="pull-right"
        onsubmit="return confirm('Are U sure to delete this task?')">
        {% raw" >}}{{ csrf_field() }}{% endraw" >}}
        {% raw" >}}{{ method_field('delete') }}{% endraw" >}}
        <input type="submit" value="X" id="delete_task_{% raw" >}}{{ $task->id }}{% endraw" >}}" class="btn btn-link btn-xs">
        <a
            href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}?action=edit&id={% raw" >}}{{ $task->id }}{% endraw" >}}"
            id="edit_task_{% raw" >}}{{ $task->id }}{% endraw" >}}">
            edit
        </a>
    </form>
    <form action="{% raw" >}}{{ url('tasks/'.$task->id.'/toggle') }}{% endraw" >}}" method="post">
        {% raw" >}}{{ csrf_field() }}{% endraw" >}}
        {% raw" >}}{{ method_field('patch') }}{% endraw" >}}
        <input type="submit" value="Toggle" id="toggle_task_{% raw" >}}{{ $task->id }}{% endraw" >}}">
    </form>
    {% raw" >}}{{ $task->name }}{% endraw" >}} <br>
    {% raw" >}}{{ $task->description }}{% endraw" >}}
</li>
<!-- @endforeach -->

Di sini kita membuat sebuah form dengan action 'tasks/1/toggle' (angka 1 adalah id dari task yang bersangkutan), yang di dalamnya langsung kita berikan csrf_field() dan method_field('patch'), kemudian ada tombol submit dengan id="toggle_task_1".

Simpan, kemudian jalankan PHPUnit.

# 3
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks/1/toggle] failed. Received status code [404]
...
Caused by
Symfony\Component\HttpKernel\Exception\NotFoundHttpException

Penyebab

Request yang dikirimkan ke tasks/1/toggle, belum route yang melayaninya.

Solusi

Kita tambahkan route untuk melayani requestnya di file routes/web.php.

<?php
// routes/web.php

// ..

Route::get('/tasks', 'TasksController@index');
Route::post('/tasks', 'TasksController@store');
Route::patch('/tasks/{task}', 'TasksController@update');
Route::delete('/tasks/{task}', 'TasksController@destroy');
Route::patch('/tasks/{task}/toggle', 'TasksController@toggle');

// ..

Jalankan PHPUnit

# 4
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks/1/toggle] failed. Received status code [500]
...
Caused by
BadMethodCallException: Method [toggle] does not exist.

Penyebab

Yap, sudah diduga, belum ada method toggle di TasksController kita.

Solusi

Kita buat method TasksController@toggle untuk melayani request ini. Method tersebut langsung kita isi dengan script untuk mengupdate kolom is_done dan redirect kembali ke halaman sebelumnya.

<?php

// TasksController

    // ... method destroy

    public function toggle(Task $task)
    {
        $task->is_done = 1;
        $task->save();

        return back();
    }

Jalankan PHPUnit

# 5
$ vendor/bin/phpunit

Hasil: Error

Unable to find row in database table [tasks] that matched attributes
[{"id":1,"is_done":0}].
Failed asserting that 0 is greater than 0.

Penyebab

Pada method TasksController@toggle kita hanya mengeset $task->is_done = 1 padahal seharusnya (yang kita inginkan) : jika kolom is_done bernilai 0 maka jadikan 1. Sebaliknya, jika saat ini kolom is_done bernilai 1 maka jadikan 0.

Solusi

Kita buat method TasksController@toggle untuk melakukan toggle kolom is_done dengan nilai 1 dan 0.

<?php

// TasksController

    // ... method destroy

    public function toggle(Task $task)
    {
        if ($task->is_done == 1) {
            $task->is_done = 0;
        } else {
            $task->is_done = 1;
        }

        $task->save();

        return back();
    }

Jalankan PHPUnit

# 6
$ vendor/bin/phpunit

Alhamdulillah, sekarang kita sudah dapat hijau. Sekarang kita melihat tampilan melalui browser untuk melihat hasilnya.

Hmmm, kurang bagus ya. Sebenarnya fitur tombol “toggle”-nya sudah bekerja, hanya saya tidak ada perubahan tampilan yang bisa kita lihat di browser. Tidak apa-apa sekarang kita perbaiki tampilannya.

Mempercantik Tampilan

Kita buka view tasks.index, kemudian kita ubah menjadi seperti ini :

<!-- resources/views/tasks/index.blade.php -->

<!-- @foreach ($tasks as $task) -->
<li class="list-group-item {% raw" >}}{{ $task->is_done ? 'task-done' : '' }}{% endraw" >}}">
    <form action="{% raw" >}}{{ url('tasks/'.$task->id) }}{% endraw" >}}" method="post" class="pull-right"
        onsubmit="return confirm('Are U sure to delete this task?')">
        {% raw" >}}{{ csrf_field() }}{% endraw" >}}
        {% raw" >}}{{ method_field('delete') }}{% endraw" >}}
        <input type="submit" value="X" id="delete_task_{% raw" >}}{{ $task->id }}{% endraw" >}}" class="btn btn-link btn-xs">
        <a
            href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}?action=edit&id={% raw" >}}{{ $task->id }}{% endraw" >}}"
            id="edit_task_{% raw" >}}{{ $task->id }}{% endraw" >}}">
            edit
        </a>
    </form>
    <form action="{% raw" >}}{{ url('tasks/'.$task->id.'/toggle') }}{% endraw" >}}" method="post">
        {% raw" >}}{{ csrf_field() }}{% endraw" >}}
        {% raw" >}}{{ method_field('patch') }}{% endraw" >}}
        <input
            type="submit" value="{% raw" >}}{{ $task->name }}{% endraw" >}}"
            id="toggle_task_{% raw" >}}{{ $task->id }}{% endraw" >}}"
            class="btn btn-link no-padding">
    </form>
    {% raw" >}}{{ $task->description }}{% endraw" >}}
</li>
<!-- @endforeach -->

Kalau teman-teman perhatikan. bagian yang diubah adalah :

<li class="list-group-item {% raw" >}}{{ $task->is_done ? 'task-done' : '' }}{% endraw" >}}">. Jika is_done bernilai true atau 1, maka ditambahkan class “task-done” pada tag <li> tersebut.
tombol submit Toggle menjadi nama task masing-masing. Sehingga nama masing-masing task akan berperan sebagai toggle status task tersebut.
tombol submit Toggle ditambahkan class=“btn btn-link no-padding”.

Di sini ada 2 class css yang kita buat, yaitu “task-done” pada <li> dan “no-padding” pada tombol submit Toggle. Sekarang kita buat style untuk kedua class tambahan ini.

Buka view layouts.app, tambahkan tag <style> pada bagian <head>.

<!-- resources/views/layouts/app.blade.php -->

<head>
    <!-- ... -->

    <!-- Styles -->
    <link href="{% raw" >}}{{ asset('css/app.css') }}{% endraw" >}}" rel="stylesheet">
    <style>
        .task-done {
            background-color: #dff0d8;
            text-decoration: line-through;
            color: #3c763d;
        }
        .btn.no-padding {
            padding: 0;
        }
    </style>
</head>

Nah, sekarang simpan dan kita lagi di browser, hasilnya kurang lebih begini :

Oke, sudah lumayan bagus ya. Jadi ketika kita klik nama task, maka akan menjadi “toggle” status task. Background hijau dan tulisan ~~strikethrough~~ untuk task dengan is_done = 1.

Terakhir, kita jalankan PHPUnit untuk memastikan perubahan di view tidak merusak fitur toggle status task kita.

# 7
$ vendor/bin/phpunit

Seharusnya kita tetap dapat hasil OK (8 tests, 47 assertions).

Baik teman-teman sampai disini pembahasan kita tentang form button untuk toggle status task. Semua perubahan script pada artikel ini bisa teman-teman lihat pada commit ini.

Insyaallah pada artikel berikutnya kita akan bahas tentang refactor di controller dengan model behaviour (perilaku kelas model) khusus untuk method TasksController@toggle.

Terima kasih atas waktunya.

Testing Laravel: Setup CI dengan Travis CI

Thu, 21 Dec 2017 10:00:00 +0800

Bismillahirrahmanirrahim.

Pada artikel sebelumnya kita sudah membahas tentang manfaat layanan Continuous Integration untuk project kita, dan sudah mengetahui beberapa layanan yang gratis. Jika kita memiliki repositori project Laravel open-source yang dihosting di github, setup Continuous Integration yang paling mudah adalah Travis CI.

Secara umum, berikut langkah yang akan kita lakukan :

Membuat file .travis.yml untuk definisi konfigurasi dan script yang dijalankan oleh Travis CI.
Login pada Travis CI dengan akun Github.
Pilih dan aktifkan repositori yang akan menggunakan layanan Travis CI.
Buat commit baru untuk men-triger layanan Travis CI untuk pertama kali.

Selanjutnya kita bahas langkah detail setup Travis CI untuk project Laravel di github.

Membuat file “.travis.yml”

File .travis.yml adalah file yang berisi konfigurasi layanan CI dan script-script build dan test yang akan dijalankan Travis CI. Baik, kita buat file bernama .travis.yml pada project root, kemudian isikan file tersebut dengan script berikut ini :

language: php

php:
  - 7.0

before_script:
  - travis_retry composer self-update
  - travis_retry composer install --prefer-source --no-interaction
  - cp .env.example .env
  - php artisan key:generate

script:
  - vendor/bin/phpunit

Seperti ini.

Kemudian buka website Travis CI, klik “Sign in with GitHub”.

Ikuti langkahnya hingga kita mendapatkan tampilan seperti gambar di bawah ini. Klik tombol “Sync account” untuk menampilkan daftar repository yang ada pada akun github kita.

Aktifkan Repository Project

Klik “switch” disamping nama repository untuk mengaktifkan layanan Travis CI untuk project tersebut. Kemudian klik Nama Repository (dalam kasus saya: nafiesl/Laravel-TDD) untuk masuk ke halaman detail build repository tersebut.

Nah, sampai disini kita sudah selesai mengaktifkan layanan Travis CI untuk project kita. Travis akan “standby” untuk menunggu commit berikutnya agar dapat mulai build untuk pertama kalinya.

Buat commit untuk men-trigger build

Sekarang kita buat commit baru untuk men-trigger build dari Travis CI. Misalnya kita ingin menampilkan build badge seperti ini pada file README.md. Langkah kerjanya seperti ini:

Klik badge build status pada halaman Travis CI project.
Pilih branch master
Pilih Markdown
Copy script badge status build untuk kita paste ke file README.md
Edit (atau buat) file README.md pada repo project di github, tambahkan script badge status build dari Travis CI tadi. Misal seperti ini.

# Laravel TDD Project

[![Build Status](https://travis-ci.org/nafiesl/Laravel-TDD.svg?branch=master)](https://travis-ci.org/nafiesl/Laravel-TDD)

## About
Source code laravel testing pada blog https://blog.nafies.id/tags/#testing.

File README.md langsung dibuat/edit pada github.

Maka seketika itu juga, kita melihat pada list commit dari repo project ini, layanan Travis CI langsung bekerja.

Kita dapat melihat proses kerjanya pada halaman Travis CI project.

Silakan tunggu hingga prosesnya selesai.

Oke, proses build dan testing nya sudah selesai. Jika kita kembali ke list commit repo tersebut, kita akan melihat tanda Centang Hijau yang menandakan bahwa proses build dan testing oleh travis CI untuk commit tersebut berjalan dengan baik. Seperti gambar di bawah ini.

Selesai Setup

Sampai disini kita sudah berhasil melakukan setup layanan Travis CI untuk project opensource Testing Laravel kita. Sebagaimana kita bahas sebelumnya, Travis CI akan otomatis berjalan setiap kita melakukan commit baru dan pull-request dari contributor.

Travis CI untuk Paket Composer

Oh ya, proses build layanan Travis CI ini tidak hanya untuk sebuah project aplikasi, lho. Layanan ini juga kita bisa gunakan untuk build dan testing paket composer. Misal paket Simple CRUD Generator untuk Laravel. Paket ini dikembangkan untuk mempermudah dan mempercepat workflow TDD dalam membangun sebuah project dengan Laravel (untuk versi 5.3 s/d 5.5), karena selain menggenerate Controller, Model dan View-nya, paket ini juga menggenerate Feature Test dan beberapa Unit Test.

Travis CI dapat digunakan untuk menjalankan test yang digenerate oleh paket tadi. Temen-temen bisa lihat disini kita bisa mendefinisikan perintah php artisan juga pada file .travis.yml. Hasilnya:

Karena paket tersebut awalnya dibuat untuk Laravel 5.5, Travis CI juga digunakan untuk menguji paket tersebut di laravel versi sebelumnya dan beberapa versi PHP. Apakah testing yang digenerate oleh paket tersebut tersebut dapat berjalan dengan baik untuk Laravel 5.3 pada php 5.6? Dan juga berjalan pada Laravel 5.4 pada php 7.0? Travis CI sangat membantu untuk kebutuhan ini.

Sample projectnya bisa dilihat pada repo ini (lihat branch laravel5.3 dan branch laravel5.4).

Demikian teman-teman, mudah-mudahan bisa memberi inspirasi tentang cara Setup Travis CI untuk project open-source laravel di github. Terima kasih atas waktunya.

Testing Laravel: Tentang Continuous Integration

Tue, 12 Dec 2017 18:00:00 +0800

Bismillahirrahmanirrahim.

Baik, karena kita sudah memiliki sebuah mini-project Laravel yang dilengkapi dengan automated testing, kita bisa mencoba yang namanya Continuous Integration. Bagi teman-teman yang belum mengetahui apa itu Continuous Integration (atau kita singkat “CI”), kurang lebih yang saya pahami seperti ini:

Continuous Integration adalah layanan yang melakukan build dan pengujian otomatis, yang terintegrasi dengan hosting repository source code (seperti Github, Gitlab, atau Bitbucket). Di mana setiap kita melakukan push commit-commit baru, atau ada pull request ke dalam repository project, layanan ini langsung menjalankan build dan test, sehingga jika ada error atau kegagalan test akan segera ketahuan.

Catatan: untuk yang lebih lengkap, silakan teman-teman coba googling “continuous integration adalah”.

Sebelum kita melakukan setup Continuous Integration pada project Testing Laravel ini, sebaiknya kita pahami dulu apa manfaat Continuous Integration untuk project kita, serta beberapa layanan CI gratis yang bisa kita gunakan untuk project kita.

Kenapa perlu Continuous Integration?

Seperti biasa, sebelum kita mempelajari/menggunakan suatu alat bantu, kita harus tahu dulu manfaatnya untuk kita. Dari situ kita bisa memutuskan apakah kita memang perlu atau tidak.

Untuk Single Fighter

Jika kita mengerjakan project sendirian, tanpa kolaborasi dengan programmer lain, satu alasan mengapa kita perlu CI, yaitu untuk memastikan bahwa testing aplikasi tidak hanya passed di localhost saja.

“Testing hanya passed di localhost saja? kok begitu?”

Ya, kalau kita kerja sendirian, kita tahunya di tempat kita (localhost) semua berjalan lancar, tapi kita belum tahu nanti ketika kita build ke server produksi (apakah lancar atau tidak?), karena pasti ada perbedaan spesifikasi hardware dan software pendukung antara localhost dengan server produksi (nanti).

Nah, CI dapat membantu kita untuk memastikan, proses langkah yang dilakukan saat kita build aplikasi ke server sudah benar dan testingnya passed, sebagaimana di locahost kita. Disamping itu, jika suatu saat ada programmer lain meneruskan project ini tanpa keterlibatan kita, atau jika ada yang bergabung, project kita sudah siap untuk digarap secara kolaborasi.

Catatan: “build” yang dimaksud disini adalah proses deploy atau installasi aplikasi pada server.

Gambar dibawah adalah contoh commit push yang langsung dicek oleh Travis CI dan Style CI.

Untuk Kolaborasi

Untuk project yang dibangun dengan cara kolaborasi, ada PM (Project Manager/Maintainer) dan kolaborator yang terlibat, ada manfaat lain yang didapatkan (selain manfaat untuk single fighter di atas), yaitu :

Setiap kolaborator melakukan push commit atau pull request, CI langsung melakukan build dan test untuk memastikan semua fitur berjalan lancar.
Testing yang sudah passed di localhost seorang kolaborator, bisa jadi failed di CI dengan berbagai sebab (ini akan jadi bahan diskusi dan ilmu tambahan untuk kolaborator).
Menghindarkan problem jika: Testing passed di localhost kolaborator, tetapi failed di localhost PM.
Meringankan beban PM (Project Manager/Maintainer).
Kalau seorang PM harus : git pull kemudian build di localhostnya dulu, untuk memastikan semua testing passed, kemudian baru melakukan code review. Kan lumayan makan waktu, ya?

Dengan dibantu CI ini, PM tinggal bilang:
“Bro, silakan bikin testingnya passed dulu sebelum ane review kerjaan ente.”

Apakah ini meringankan pekerjaan PM? Tentu saja.

Gambar dibawah adalah contoh pull request yang langsung dicek oleh layanan CI.

Layanan CI Gratis

Ada beberapa layanan CI yang saya ketahui dan coba gunakan untuk project open-source maupun private. Umumnya layanan CI selalu gratis untuk project-project open-source. Sedangkan untuk project private, biasanya berbayar, tapi ada juga yang gratis.

1. Travis CI

Travis CI adalah layanan CI yang mendukung banyak bahasa pemrograman dan banyak digunakan untuk project-project open-source di Github. Saya juga menggunakan Travis CI untuk beberapa project open-source yang saya kembangkan. Layanan ini berbayar kita gunakan untuk project private.

Berikut contoh hasil build dan test di Travis CI, bisa coba klik link 15.1 untuk melihat detailnya.

2. Codeship

Codeship adalah layanan CI yang menyediakan akun gratis untuk project private dengan batasan tertentu. Batasannya (saya rasa) sangat cukup untuk kebutuhan freelance web developer. Saya sendiri menggunakan codeship ini untuk project-project private di Bitbucket. Kita bisa melihat perbandingan akun basic dengan akun pro pada halaman web ini.

3. Bitbucket Pipeline

Bitbucket Pipeline adalah layanan CI milik Bitbucket, paket akun usernya mengikuti paket akun Bitbucket yang kita miliki. Gratis dengan batasan jumlah user (5 orang). Jika kita menggunakan Bitbucket untuk hosting source code private, kita bisa langsung menggunakan layanan ini.

4. Gitlab CI

Gitlab CI serupa dengan pipeline milik Bitbucket, yang ini adalah layanan milik Gitlab. Kebetulan saya belum pernah mencoba layanan ini di Gitlab.

Layanan CI Standarisasi Sintax

Nah, layanan CI yang ini berbeda dengan keempat layanan di atas, ini diluar urusan testing. Yang ini adalah layanan untuk mengecek sintax/script yang kita tulis pada project. Misal kita menggunakan bahasa pemrograman PHP, maka dia akan mengecek apakah gaya “coding” (sintax) yang kita tulis sudah sesuai dengan standar atau tidak.

1. Style CI

Style CI ini salah satu layanan CI untuk pengecekan sintax itu. Jadi dengan Style CI ini, kita dibantu mengecek seluruh script di file-file PHP yang ada. Jika ditemukan sintax yang tidak sesuai standar, maka Style CI menyatakan “tidak lolos uji”, dan Style CI akan menawarkan Pull Request untuk memperbaikinya.

Contohnya seperti project Free PMO, sintaxnya ternyata banyak yang tidak standar, ada 151 file yang diperbaiki melalui Pull Request oleh Style CI.

Sayangnya layanan ini gratis hanya untuk project open-source, untuk private repo berbayar.

2. Nitpick CI

Layanan serupa Style CI adalah Nitpick CI, gratis untuk project open-source dan berbayar untuk project private. Nitpick CI khusus untuk bahasa PHP dan PSR-2.

Kesimpulan

Setelah pembahasan di atas, coba kita simpulkan manfaat dari layanan Continuous Integration.

CI membantu memastikan bahwa automated testing project kita passed diluar localhost (ini penting).
CI sangat membantu dalam project kolaborasi yang dikerjakan oleh banyak developer.
CI mempermudah kerja Project Maintainer, dalam membantu memastikan semua perubahan yang baru tidak “merusak” fitur-fitur yang telah ada.
CI yang berkaitan dengan sintax membantu kolaborator belajar standarisasi sintax dan membantu agar kita lebih fokus kepada proses bisnis dan logika bisnis dalam project, ~~ketimbang berdebat tentang gaya menulis kode~~.

Baik, lebih kurang itu manfaat yang kita dapatkan dari penggunaan layanan Continuous Integration dalam membangun sebuah project. Saya mohon koreksi dari teman-teman jika ada pemahaman saya yang keliru terkait Continuous Integration ini.

Satu lagi, Continuous Integration tidak hanya digunakan saat development saja, pada saat maintenance dan improvement pun Continuous Integration akan tetap kita gunakan. Karena manfaat yang didapatkan dengan adanya Continuous Integration ini bisa kita gunakan untuk jangka panjang. Mungkin itu salah satu sebab kenapa dinamakan “Integrasi secara terus menerus”.

Selanjutnya insyaallah kita mencoba setup Continuous Integration menggunakan Travis CI pada project Testing Laravel. Terima kasih teman-teman atas waktunya.

Testing Laravel: Menghapus dengan Form Button

Thu, 07 Dec 2017 16:00:00 +0800

Bismillahirrahmanirrahim.

Kali ini kita akan membuat fitur hapus task. Pada Route Resource Laravel, ada method request http khusus untuk melayani aktifitas penghapusan record, yaitu method “DELETE”. Method “DELETE” ini dapat dilayani oleh aplikasi laravel jika kita mengirimkan request dari submit form, padahal biasanya kita melakukan submit form kan untuk fungsi create dan update ya? Sedangkan fungsi delete atau hapus record ini hanya berupa aksi satu tombol, seperti halnya fungsi link atau anchor tag. Misal tombol “Hapus Item”. Ketika tombol diklik, maka record dihapus dari sistem dan user diberi respons redirect ke halaman tertentu.

Dari yang saya ketahui, ada 2 cara untuk mengirimkan request “delete” :

Membuat form dengan action menuju method delete, yang hanya berisi tombol “Hapus”.
Membuat tag anchor (<a href="#"></a>) yang dapat dikonversi dengan javascript agar berubah menjadi form (seperti ini).

Yang biasa saya terapkan adalah cara pertama, karena lebih familiar dan dapat dijangkau oleh paket browserkit-testing Laravel. Cara yang kedua saya dapatkan dari mempelajari source code sebuah package bernama Ngeblog, dan berdiskusi dengan authornya mas Antoni Putra.

Nah, pada artikel ini kita akan menggunakan cara pertama dengan form. Cara ini biasa saya sebut dengan “Form Button”, karena dia berupa sebuah form yang hanya berisi satu tombol.

Artikel ini adalah lanjutan dari artikel Testing Laravel: Form Edit Task. Jika teman-teman sudah mengikuti project TDD ini sampai artikel tersebut, silakan menggunakan projectnya. Saya mulai dari repo Laravel-TDD pada commit ini.

Baik, kita mulai dengan menjalankan PHPUnit untuk memastikan project kita tidak ada Failed test.

# 1
$ vendor/bin/phpunit

OK (7 tests, 31 assertions).

Membuat Method Test untuk Hapus Task

Kita kembali meng-edit file tests/Feature/ManageTasksTest.php dan mulai mengerjakan method user_can_delete_an_existing_task.

<?php

// ...

class ManageTasksTest extends TestCase
{
    // ... user_can_create_a_task()

    // ... user_can_browse_tasks_index_page()

    // ... user_can_edit_an_existing_task()

    /** @test */
    public function user_can_delete_an_existing_task()
    {
        $this->assertTrue(true);
    }
}

Buat PHP comment line dulu untuk mempermudah kita membuat testing script.

<?php

    /** @test */
    public function user_can_delete_an_existing_task()
    {
        // Generate 1 record task pada table `tasks`.

        // User membuka halaman Daftar Task.

        // User tekan tombol "Hapus Task"

        // Lihat halaman web ter-redirect ke halaman daftar task

        // Record task hilang dari database
    }

Sekarang kita buat testing script-nya.

<?php

    /** @test */
    public function user_can_delete_an_existing_task()
    {
        // Generate 1 record task pada table `tasks`.
        $task = factory(Task::class)->create();

        // User membuka halaman Daftar Task.
        $this->visit('/tasks');

        // User tekan tombol "Hapus Task" (tombol dengan id="edit_task_1")
        // Dimana angka 1 adalah id dari $task
        $this->press('delete_task_'.$task->id);

        // Lihat halaman web ter-redirect ke halaman daftar task
        $this->seePageIs('/tasks');

        // Record task hilang dari database
        $this->dontSeeInDatabase('tasks', [
            'id' => $task->id,
        ]);
    }

Simpan, kemudian jalankan PHPUnit.

# 2
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Could not find a form that has
submit button [delete_task_1].

Penyebab

Kita belum memiliki form yang memiliki tombol delete_task_1. Di mana delete_task_1 bisa berupa tulisan atau atribut value pada tombol submit, bisa juga berupa atribut id dari tombol submit tersebut.

Solusi (Membuat Form Button)

Pada view tasks.index bagian daftar Task kita buat form dengan tombol delete_task_1.

<!-- resources/views/tasks/index.blade.php -->

<!-- @foreach ($tasks as $task) -->
<li class="list-group-item">
    <form action="{% raw" >}}{{ url('tasks/'.$task->id) }}{% endraw" >}}" method="post">
        <input type="submit" value="X" id="delete_task_{% raw" >}}{{ $task->id }}{% endraw" >}}" class="btn btn-xs">
    </form>
    <a
        href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}?action=edit&id={% raw" >}}{{ $task->id }}{% endraw" >}}"
        id="edit_task_{% raw" >}}{{ $task->id }}{% endraw" >}}"
        class="pull-right">
        edit
    </a>
    {% raw" >}}{{ $task->name }}{% endraw" >}} <br>
    {% raw" >}}{{ $task->description }}{% endraw" >}}
</li>
<!-- @endforeach -->

Simpan, kemudian jalankan PHPUnit.

# 3
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks/1] failed. Received status code [405].
...
Caused by
Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException

Penyebab

Request yang dikirimkan berupa “POST” ke tasks/1, seharusnya kita mengirim request berupa “DELETE”.

Solusi

Pada form berisi tombol delete di view tasks.index kita tambahkan {% raw" >}}{{ csrf_field() }}{% endraw" >}} dan {% raw" >}}{{ method_field('delete') }}{% endraw" >}}.

<!-- resources/views/tasks/index.blade.php -->

<!-- @foreach ($tasks as $task) -->
<li class="list-group-item">
    <form action="{% raw" >}}{{ url('tasks/'.$task->id) }}{% endraw" >}}" method="post">
        {% raw" >}}{{ csrf_field() }}{% endraw" >}}
        {% raw" >}}{{ method_field('delete') }}{% endraw" >}}
        <input type="submit" value="X" id="delete_task_{% raw" >}}{{ $task->id }}{% endraw" >}}" class="btn btn-xs">
    </form>
    <a
        href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}?action=edit&id={% raw" >}}{{ $task->id }}{% endraw" >}}"
        id="edit_task_{% raw" >}}{{ $task->id }}{% endraw" >}}"
        class="pull-right">
        edit
    </a>
    {% raw" >}}{{ $task->name }}{% endraw" >}} <br>
    {% raw" >}}{{ $task->description }}{% endraw" >}}
</li>
<!-- @endforeach -->

Sebelum jalan PHPUnit, kita tambahkan dulu route untuk melayani requestnya di file routes/web.php.

<?php
// routes/web.php

// ..

Route::get('/tasks', 'TasksController@index');
Route::post('/tasks', 'TasksController@store');
Route::patch('/tasks/{task}', 'TasksController@update');
Route::delete('/tasks/{task}', 'TasksController@destroy');

// ..

Jalankan PHPUnit

# 4
$ vendor/bin/phpunit

Hasil: Error

BadMethodCallException: Method [destroy] does not exist.

Penyebab

Belum ada method destroy di TasksController.

Solusi

Kita buat method TasksController@destroy sekaligus dengan script action untuk menghapus recordnya.

<?php

// TasksController

    // ... method update

    public function destroy(Task $task)
    {
        $task->delete();

        return redirect('/tasks');
    }

Jalankan PHPUnit

# 5
$ vendor/bin/phpunit

Yayy.. hijau. Sekarang lebih cepet ya dapat hijau? Iya, begitulah TDD. Semakin sering metode ini digunakan, maka semakin cepat kita menyelesaikan pekerjaan.

Baik sekarang kita coba buka browser untuk melihat hasilnya.

Posisi tombol hapusnya kurang pas ya, kita perbaiki sedikit posisi tampilannya. Kira-kira begini.

<!-- resources/views/tasks/index.blade.php -->

<!-- @foreach ($tasks as $task) -->
<li class="list-group-item">
    <form action="{% raw" >}}{{ url('tasks/'.$task->id) }}{% endraw" >}}" method="post" class="pull-right"
        onsubmit="return confirm('Are U sure to delete this task?')">
        {% raw" >}}{{ csrf_field() }}{% endraw" >}}
        {% raw" >}}{{ method_field('delete') }}{% endraw" >}}
        <input type="submit" value="X" id="delete_task_{% raw" >}}{{ $task->id }}{% endraw" >}}" class="btn btn-link btn-xs">
        <a
            href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}?action=edit&id={% raw" >}}{{ $task->id }}{% endraw" >}}"
            id="edit_task_{% raw" >}}{{ $task->id }}{% endraw" >}}">
            edit
        </a>
    </form>
    {% raw" >}}{{ $task->name }}{% endraw" >}} <br>
    {% raw" >}}{{ $task->description }}{% endraw" >}}
</li>
<!-- @endforeach -->

Ada tambahan class bootstrap pada form dan tombol hapus, Link Edit kita masukkan ke dalam form, dan ada tambahan dialog konfirmasi javascript ketika akan menghapus task.

Baik, sekarang kita jalankan lagi PHPUnit untuk memastikan tidak ada masalah setelah perubahan view barusan.

# 6
$ vendor/bin/phpunit

Seharusnya kita tetap dapat hasil OK (7 tests, 36 assertions).

Tapi ada pertanyaan : Itu kan ada “dialog konfirmasi” di browser pada saat kita menghapus task, kenapa tidak ada perubahan di sisi testingnya untuk mengkonfirmasi dialog itu? Yap, bagian itu (afaik) memang tidak dapat “dijangkau” oleh Browserkit Testing Laravel. Sebagaimana yang sebelumnya pernah kita bahas, Browserkit dibantu oleh DOM Crawler Symfony, hanya dapat mendeteksi elemen html yang di-render pada browser, sehingga tidak bisa berinteraksi dengan javascript.

Jika ingin memiliki paket testing yang lengkap hingga interaksi dengan javascript, teman-teman bisa mencoba Browser Test - Laravel Dusk milik Laravel. Akan tetapi dalam waktu dekat kita tidak akan membahas Laravel Dusk di sini, karena saya sendiri belum familiar dengan paket browser test tersebut. :)

Baik, sampai disini artikel menghapus task dengan Form Button. Jika teman-teman ada yang mempraktekkan dan mengalami permasalahan, silakan disampaikan melalui komentar.

Selanjutnya kita akan membahas tentang Continuous Integration dan setup Continuous Integration dengan Travis CI pada project ini. Teman-teman juga boleh langsung lompat ke artikel toggle status task dengan form button jika tidak belum berminat dengan Continuous Integration.

Terima kasih atas waktunya.

Testing Laravel: Form Edit Task

Tue, 05 Dec 2017 10:00:00 +0800

Bismillahirrahmanirrahim.

Pada artikel sebelumnya kita sudah membuat link untuk melakukan edit task, tetapi link tersebut belum bekerja. Link tersebut akan kita gunakan untuk menampilkan form edit task pada halaman yang sama (view tasks.index).

Jika teman-teman sudah mengikuti artikel Testing Laravel ini sejak awal, silakan menggunakan projectnya. Jika tidak, silakan menggunakan commit pada repo ini (sampai update artikel sebelumnya).

Baik, seperti biasa, kita mulai kerja dengan menjalankan testing dulu.

# 1
$ vendor/bin/phpunit

OK (7 tests, 22 assertions)

Untuk membuat form edit task, kita lakukan dengan meng-edit file tests/Feature/ManageTasksTest.php. Pada file ini kita perhatikan method user_can_edit_an_existing_task. Kita akan bekerja dari sini.

<?php

// ...

class ManageTasksTest extends TestCase
{
    // ... user_can_create_a_task()
    
    // ... user_can_browse_tasks_index_page()

    /** @test */
    public function user_can_edit_an_existing_task()
    {
        $this->assertTrue(true);
    }
    
    // ... user_can_delete_an_existing_task()
}

Baik, kita buat PHP comment line yang menjadi panduan kita.

<?php

    /** @test */
    public function user_can_edit_an_existing_task()
    {
        // Generate 1 record task pada table `tasks`.
        
        // User membuka halaman Daftar Task.
        
        // Klik tombol edit task
        
        // Lihat URL yang dituju sesuai dengan target
        
        // Tampil form Edit Task

        // User submit form berisi nama dan deskripsi task yang baru

        // Lihat halaman web ter-redirect ke URL sesuai dengan target
        
        // Record pada database berubah sesuai dengan nama dan deskripsi baru
    }

Oke sekarang kita buat script testing sesuai dengan langkah kerja di atas.

<?php

    /** @test */
    public function user_can_edit_an_existing_task()
    {
        // Generate 1 record task pada table `tasks`.
        $task = factory(Task::class)->create();
        
        // User membuka halaman Daftar Task.
        $this->visit('/tasks');
        
        // Klik tombol edit task (link dengan id="edit_task_1")
        // Dimana angka 1 adalah id dari $task
        $this->click('edit_task_'.$task->id);
        
        // Lihat URL yang dituju sesuai dengan target
        $this->seePageIs('/tasks?action=edit&id='.$task->id);

        // Tampil form Edit Task, kita cek apakah ada form dengan
        // id="edit_task_1" dan action="tasks/1"
        $this->seeElement('form', [
            'id'     => 'edit_task_'.$task->id,
            'action' => url('tasks/'.$task->id),
        ]);

        // User submit form berisi nama dan deskripsi task yang baru
        $this->submitForm('Update Task', [
            'name' => 'Updated Task',
            'description' => 'Updated task description.',
        ]);

        // Lihat halaman web ter-redirect ke URL sesuai dengan target
        // yaitu '/tasks', kembali ke daftar task
        $this->seePageIs('/tasks');
        
        // Record pada database berubah sesuai nama dan deskripsi baru
        $this->seeInDatabase('tasks', [
            'id' => $task->id,
            'name' => 'Updated Task',
            'description' => 'Updated task description.',
        ]);
    }

Simpan, kemudian jalankan PHPUnit.

# 2
$ vendor/bin/phpunit

Hasil: Error

Failed asserting that the page contains the element [form] with the attributes
{"id":"edit_task_1","action":"http:\/\/localhost\/tasks\/1"}.
Please check the content above.

Penyebab

Kita belum memiliki <form id="edit_task_1" action="http://localhost/tasks/1" method="post"></form>.

Solusi

Pada view tasks.index kita buat <form id="edit_task_1" action="http://localhost/tasks/1" method="post"></form>.

<!-- resources/views/tasks/index.blade.php -->

    <div class="col-md-4">
        <form id="edit_task_1" action="{% raw" >}}{{ url('tasks/1') }}{% endraw" >}}" method="post"></form>

        <h2>New Task</h2>
        <!-- form create task -->
    </div>

# 3
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Could not find a form that has submit button
[Update Task].

Stop!!

Kalau kita perhatikan, di sini progress kita berlanjut, karena error yang kita dapatkan sudah berubah (artinya error sebelumnya sudah solved). Sebenarnya belum, karena pada script testing di bawah ini kita hanya menguji apakah form dengan kriteria :
id="edit_task_1" action="{% raw" >}}{{ url('tasks/1') }}{% endraw" >}}" tampil di halaman web.

<?php

    public function user_can_edit_an_existing_task()
    {
        // ..
        
        // Tampil form Edit Task, kita cek apakah ada form dengan
        // id="edit_task_1" dan action="tasks/1"
        $this->seeElement('form', [
            'id'     => 'edit_task_'.$task->id,
            'action' => url('tasks/'.$task->id),
        ]);
        
        // ..
    }

Padahal kita masih menggunakan sintaks html statis <form id="edit_task_1" action="{% raw" >}}{{ url('tasks/1') }}{% endraw" >}}" method="post"></form>. Artinya kita harus membuat angka 1 disini menjadi dinamis sesuai dengan id dari task yang akan kita edit.

Untuk membuat angka 1 tersebut menjadi dinamis, kita kerjakan mulai dari controllernya. Buka TasksController, kemudian buat blok if untuk mengecek apakah terdapat query string id dan action=edit pada request. Ini sesuai dengan link edit task yang kita buat pada view tasks.index pada artikel sebelumnya.

<?php

// TasksController
    
    public function index()
    {
        $tasks = Task::all();
        $editableTask = null;

        if (request('id') && request('action') == 'edit') {
            $editableTask = Task::find(request('id'));
        }

        return view('tasks.index', compact('tasks', 'editableTask'));
    }

    // ... method store

Penambahan script di atas dimaksudkan agar ketika ada query string id dan action=edit, kita buat variabel $editableTask berisi record model Task yang ingin kita edit.

Oke, selanjutnya kita edit view tasks.index dengan menambahkan blok if untuk mengecek apakah variabel $editabelTask tidak bernilai null dan terdapat action=edit pada request, serta menyesuaikan angka id form edit task.

<!-- resources/views/tasks/index.blade.php -->

    <div class="col-md-4">
        @if (! is_null($editableTask) && request('action') == 'edit')
        <form id="edit_task_{% raw" >}}{{ $editableTask->id }}{% endraw" >}}" action="{% raw" >}}{{ url('tasks/'.$editableTask->id) }}{% endraw" >}}" method="post"></form>
        @endif

        <h2>New Task</h2>
        <!-- form create task -->
    </div>

Baik sekarang jalankan PHPUnit.

# 4
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Could not find a form that has submit button
[Update Task].

Oke, hasil error ini tetap sama dengan hasil error pada tahap sebelumnya, sebelum kita membuat variabel $editableTask di controller dan view barusan.

Baik kita lanjutkan untuk memperbaiki error ini.

Penyebab

Kita belum memiliki tombol submit Update Task pada form edit task.

Solusi

Kita buat tombol submit Update Task pada form edit task.

<!-- resources/views/tasks/index.blade.php -->

    <div class="col-md-4">
        @if (! is_null($editableTask) && request('action') == 'edit')
        <form id="edit_task_{% raw" >}}{{ $editableTask->id }}{% endraw" >}}" action="{% raw" >}}{{ url('tasks/'.$editableTask->id) }}{% endraw" >}}" method="post">
            <input type="submit" value="Update Task" class="btn btn-primary">
        </form>
        @endif

        <h2>New Task</h2>
        <!-- form create task -->
    </div>

Jalankan PHPUnit

# 5
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Unreachable field "name"

Penyebab

Kita belum input text name.

Solusi

Kita buat input text name pada edit task. Error yang serupa juga akan muncul untuk input description, maka kita buat sekalian saja. Kita jua membuat {% raw" >}}{{ csrf_field() }}{% endraw" >}} dan {% raw" >}}{{ method_field('patch') }}{% endraw" >}} karena proses ini adalah proses update record.

<!-- resources/views/tasks/index.blade.php -->

    <div class="col-md-4">
        @if (! is_null($editableTask) && request('action') == 'edit')
        <form id="edit_task_{% raw" >}}{{ $editableTask->id }}{% endraw" >}}" action="{% raw" >}}{{ url('tasks/'.$editableTask->id) }}{% endraw" >}}" method="post">
            {% raw" >}}{{ csrf_field() }}{% endraw" >}}
            {% raw" >}}{{ method_field('patch') }}{% endraw" >}}
            <div class="form-group">
                <label for="name" class="control-label">Name</label>
                <input id="name" name="name" class="form-control" type="text">
            </div>
            <div class="form-group">
                <label for="description" class="control-label">Description</label>
                <textarea id="description" name="description" class="form-control"></textarea>
            </div>
            <input type="submit" value="Update Task" class="btn btn-primary">
        </form>
        @endif

        <h2>New Task</h2>
        <!-- form create task -->
    </div>

# 6
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks/1] failed. Received status code [404].

Penyebab

Kita belum membuat route untuk melayani action update record task.

Solusi

Tambahkan route Route::patch('tasks/{task}', 'TasksController@update') pada routes/web.php.

<?php
// routes/web.php

// ..

Route::get('/tasks', 'TasksController@index');
Route::post('/tasks', 'TasksController@store');
Route::patch('/tasks/{task}', 'TasksController@update');

// ..

Selanjutnya buat method TasksController@update langsung dengan script update record task dan redirect ke halaman /tasks.

<?php

// TasksController
    
    // ... method store
    
    public function update(Task $task)
    {
        // dd(request()->all());
        $task->update(request()->only('name', 'description'));

        return redirect('/tasks');
    }

# 7
$ vendor/bin/phpunit

Yeyy.. Hijauuuu!!.

Baik. sampai di sini karena sudah dapat Hijau, kita coba tambahkan validasi dan refactor sedikit controllernya.

<?php

// TasksController
    
    // ... method store
    
    public function update(Task $task)
    {
        $taskData = request()->validate([
            'name'        => 'required|max:255',
            'description' => 'required|max:255',
        ]);

        $task->update($taskData);

        return redirect('/tasks');
    }

# 8
$ vendor/bin/phpunit

Seharusnya kita tetap dapat hasil OK (7 tests, 31 assertions). Sekarang kita coba lihat melalui browser.

Hmmm.. sepertinya perlu sedikit kita perbaiki. Bagaimana kalau kita buat seperti ini?

<!-- resources/views/tasks/index.blade.php -->

    <div class="col-md-4">
        @if (count($errors) > 0)
            <div class="alert alert-danger">
                <ul class="list-unstyled">
                    @foreach ($errors->all() as $error)
                        <li>{% raw" >}}{{ $error }}{% endraw" >}}</li>
                    @endforeach
                </ul>
            </div>
        @endif
        @if (! is_null($editableTask) && request('action') == 'edit')
        <h2>Edit Task {% raw" >}}{{ $editableTask->name }}{% endraw" >}}</h2>
        <form id="edit_task_{% raw" >}}{{ $editableTask->id }}{% endraw" >}}" action="{% raw" >}}{{ url('tasks/'.$editableTask->id) }}{% endraw" >}}" method="post">
            {% raw" >}}{{ csrf_field() }}{% endraw" >}}
            {% raw" >}}{{ method_field('patch') }}{% endraw" >}}
            <div class="form-group">
                <label for="name" class="control-label">Name</label>
                <input id="name" name="name" class="form-control" type="text" value="{% raw" >}}{{ old('name', $editableTask->name) }}{% endraw" >}}">
            </div>
            <div class="form-group">
                <label for="description" class="control-label">Description</label>
                <textarea id="description" name="description" class="form-control">{% raw" >}}{{ old('description', $editableTask->description) }}{% endraw" >}}</textarea>
            </div>
            <input type="submit" value="Update Task" class="btn btn-primary">
            <a href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" class="btn btn-default">Cancel</a>
        </form>
        @else
        <h2>New Task</h2>
        <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
            {% raw" >}}{{ csrf_field() }}{% endraw" >}}
            <div class="form-group">
                <label for="name" class="control-label">Name</label>
                <input id="name" name="name" class="form-control" type="text" value="{% raw" >}}{{ old('name') }}{% endraw" >}}">
            </div>
            <div class="form-group">
                <label for="description" class="control-label">Description</label>
                <textarea id="description" name="description" class="form-control">{% raw" >}}{{ old('description') }}{% endraw" >}}</textarea>
            </div>
            <input type="submit" value="Create Task" class="btn btn-primary">
        </form>
        @endif
    </div>

Hasilnya seperti di bawah ini, dimana form Create Task tidak muncul saat edit task.

Terakhir, jalankan PHPUnit untuk memastikan tidak ada yang “rusak” setelah kita mengubah form view tadi.

# 9
$ vendor/bin/phpunit

Seharusnya kita tetap dapat hasil OK (7 tests, 31 assertions).

Baik sampai di sini kita membuat form edit task dengan bantuan Testing Laravel. Pada project ini kita menampilkan halaman edit form pada view tasks.index. Teman-teman bebas jika ingin membuat halaman sendiri untuk form create dan edit tasknya.

Jika ada yang kurang dipahami pada artikel kali ini, silakan teman-teman sampaikan dikomentar. Selanjutnya kita akan membahas tentang menghapus task dengan Form Button. Terima kasih atas waktunya.

Testing Laravel: Menggunakan Model Factory

Wed, 29 Nov 2017 22:00:00 +0800

Bismillahirrahmanirrahim

Di beberapa artikel sebelumnya kita masih bicara seputar satu fitur, yaitu Input Task. Sekarang kita akan membuat testing agar user dapat melihat daftar Task yang ada. Sebenarnya fitur ini secara tidak langsung sudah ada pada tahap pengerjaan fitur sebelumnya, kita sudah dapat melihat daftar task. Tetapi kali ini kita membuat task tanpa harus input task dari form. Kita akan memanfaatkan Model Factory Laravel untuk meng-generate beberapa task pada testing.

Model Factory adalah fitur yang berfungsi untuk membuat instance dari kelas model laravel dengan atribut-atribut yang sesuai dengan kolom-kolom tabel yang sesuai pada database. Setiap penggunaan model factory akan menghasilkan instance model atau collection (list) dari beberapa model yang sama.

Pada artikel Definisi Fitur, kita sudah membuat sebuah test method untuk artikel ini, yaitu user_can_browse_tasks_index_page. Isinya hanya $this->assertTrue(true);, sebuah assert sederhana agar test method ini passed (untuk sementara waktu). Kita akan bekerja pada method test ini.

<?php

// ...

class ManageTasksTest extends TestCase
{
    // ... user_can_create_a_task()

    /** @test */
    public function user_can_browse_tasks_index_page()
    {
        $this->assertTrue(true);
    }

    // ... user_can_edit_an_existing_task()
    
    // ... user_can_delete_an_existing_task()
}

Sebelum mulai kerja, kita jalankan dulu PHPUnit, untuk memastikan aplikasi tidak ada masalah.

# 1
$ vendor/bin/phpunit

OK (7 tests, 13 assertions)

Membuat Test Method

Sekarang kita lanjut mendefinisikan langkah dalam testing method tersebut (dalam bentuk PHP comment line) sesuai yang kita inginkan. Seperti ini :

<?php

    /** @test */
    public function user_can_browse_tasks_index_page()
    {
        // Generate 3 record task pada table `tasks`.
        
        // User membuka halaman Daftar Task.

        // User melihat ketiga task tampil pada halaman.

        // User melihat link untuk edit task pada masing-masing item task.
    }
}

Baik, itu misinya, sekarang kita buat script untuk memenuhi langkah tersebut.

<?php

// ...
use App\Task; // Tambahkan ini

class ManageTasksTest extends TestCase
{
    // ... user_can_create_a_task()
    
    /** @test */
    public function user_can_browse_tasks_index_page()
    {
        // Generate 3 record task pada table `tasks`.
        $tasks = factory(Task::class, 3)->create();

        // User membuka halaman Daftar Task.
        $this->visit('/tasks');

        // User melihat ketiga task tampil pada halaman.
        $this->see($tasks[0]->name);
        $this->see($tasks[1]->name);
        $this->see($tasks[2]->name);

        // User melihat link untuk edit task pada masing-masing item task.
        
        // <a href="/tasks?action=edit&id=1" id="edit_task_1">edit</a>
        $this->seeElement('a', [
            'id'   => 'edit_task_'.$tasks[0]->id,
            'href' => url('tasks?action=edit&id='.$tasks[0]->id)
        ]);

        // <a href="/tasks?action=edit&id=2" id="edit_task_2">edit</a>
        $this->seeElement('a', [
            'id'   => 'edit_task_'.$tasks[1]->id,
            'href' => url('tasks?action=edit&id='.$tasks[1]->id)
        ]);

        // <a href="/tasks?action=edit&id=3" id="edit_task_3">edit</a>
        $this->seeElement('a', [
            'id'   => 'edit_task_'.$tasks[2]->id,
            'href' => url('tasks?action=edit&id='.$tasks[2]->id)
        ]);
    }
}

Jangan lupa use App\Task; di atas kelas ManageTasksTest.

Oke, kita jalankan PHPUnit untuk mendapatkan error pertama.

# 2
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Unable to locate factory with name [default] [App\Task].

Penyebab

Kita belum memiliki model factory untuk model App\Task.

Solusi

Kita belum buat model factory untuk model App\Task.

Membuat Model Factory “App\Task”

$ php artisan make:factory TaskFactory --model=Task

Laravel akan membuat database/factories/TaskFactory.php. Kita edit file tersebut dan tambahkan atribut name dan description untuk model App\Task.

<?php

use Faker\Generator as Faker;

$factory->define(App\Task::class, function (Faker $faker) {
    return [
        'name' => $faker->word,
        'description' => $faker->sentence,
    ];
});

Jalankan PHPUnit.

# 3
$ vendor/bin/phpunit

Hasil: Error

Failed asserting that the page contains the element [a] with the attributes
{"id":"edit_task_1","href":"http:\/\/localhost\/tasks?action=edit&id=1"}.
Please check the content above.

Penyebab

Kita belum membuat link untuk edit masing-masing task.

Solusi

Buka view tasks.index atau file resources/views/tasks/index.blade.php, kita buat link untuk edit masing-masing task.

<!-- resources/views/tasks/index.blade.php -->

        <h2>Tasks</h2>
        <ul class="list-group">
            @foreach ($tasks as $task)
                <li class="list-group-item">
                    <a
                        href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}?action=edit&id={% raw" >}}{{ $task->id }}{% endraw" >}}"
                        id="edit_task_{% raw" >}}{{ $task->id }}{% endraw" >}}"
                        class="pull-right">
                        edit
                    </a>
                    {% raw" >}}{{ $task->name }}{% endraw" >}} <br>
                    {% raw" >}}{{ $task->description }}{% endraw" >}}
                </li>
            @endforeach
        </ul>

Jalankan PHPUnit.

# 4
$ vendor/bin/phpunit

OK (7 tests, 22 assertions)

Sip, sekarang sudah dapat Hijau. Artinya ketiga task yang kita generate dengan model factory tadi sudah muncul pada halaman web, beserta link edit nya masing-masing.

Sekarang coba kita buka aplikasi melalui browser, kita lihat tampilannya setelah ditambahkan link edit seperti ini.

Sampai di sini proses TDD kita untuk fitur melihat daftar Task.

Kita lanjut bahas sedikit tentang beberapa method assert yang kita gunakan di atas.

Method “$this->see()”

Method $this->see() adalah method assert browserkit untuk melihat teks pada halaman html. Method ini kita gunakan untuk melihat teks apapun yang kita ingin lihat pada halaman web, baik di dalam tag heading, paragraf, form, label, div, dan lain-lain.

Contoh

$this->see('123');

akan passed jika di dalam halaman terdapat :

<h1>Rp. 123.000</h1>
<p>Testing 123</p>
<span class="badge">Status 123</span>

Method “$this->seeElement()”

Method $this->seeElement() adalah method assert browserkit untuk melihat element pada halaman html. Method ini kita gunakan untuk melihat apakah terdapat elemen tersebut (beserta atributnya) dalam halaman html.

Contoh Passed

$this->seeElement('h1', ['class' => 'page-header', 'id' => 'judul-halaman']);

akan passed jika di dalam halaman terdapat :

<h1 class="page-header" id="judul-halaman">Rp. 123.000</h1>
<h1 class="page-header" id="judul-halaman">Judul Halaman</h1>

$this->seeElement('button', ['class' => 'btn btn-info']);

akan passed jika di dalam halaman terdapat :

<button class="btn btn-info">Submit</h1>
<button class="btn btn-info" id="judul-halaman">Simpan</h1>

Contoh Failed

$this->seeElement('h1', ['class' => 'page-header', 'id' => 'judul-halaman']);

akan failed jika di dalam halaman hanya terdapat :

<h1 class="page-header">Rp. 123.000</h1>
<h1 id="judul-halaman">Judul Halaman</h1>

Oke, mudah-mudahan teman-teman yang mencoba praktek artikel ini mendapatkan hasil yang sesuai dengan proses di atas. Jika menemui kendala atau ada keliru dalam proses di atas, silakan disampaikan melalui komentar.

Selanjutnya kita akan mengerjakan Form Edit Task dari link edit yang sudah dibuat di atas. Terima kasih atas waktunya.

Testing Laravel: Testing Validasi Form

Mon, 27 Nov 2017 07:00:00 +0800

Bismillahirrahmanirrahim

Kita lanjutkan membuat validasi form input task. Mungkin teman-teman sudah melihat, ketika membuka aplikasi pada url /tasks, kemudian langsung tekan tombol Create Task (submit form) tanpa mengisi field name dan description, kita dapatkan error seperti ini.

Error ini disebabkan karena kolom name tidak boleh bernilai null saat diinput ke database. Sebagaimana file migration untuk table tasks : xxxxx_create_tasks_table.php, name dan description tidak diset nullable. Error ini juga akan terjadi jika kolom description kosong.

Solusinya, kita harus buat validasi form input task ini, untuk memastikan user menginput data dengan benar. Karena misi kita menerapkan TDD, maka kita juga buat testing sebelum membuat validasi form.

Di sini starting point saya berasal dari commit repo ini pada artikel sebelumnya. Teman-teman silakan teruskan project sendiri jika sudah mengikuti artikel ini dari awal.

Membuat Testing untuk menguji validasi form

Seperti biasa sebelum mulai kerja, kita pastikan semua testing passed.

# 1
$ vendor/bin/phpunit

OK (6 tests, 13 assertions)

Sip, kita lanjutkan. Buka file tests/Feature/ManageTasksTest.php, tambahkan method test baru seperti berikut :

<?php
    // Kelas ManageTasksTest.php
    
    // ... user_can_create_a_task()

    /** @test */
    public function task_entry_must_pass_validation()
    {
        // Submit form untuk membuat task baru
        // dengan field name description kosong
        $this->post('/tasks', [
            'name'        => '',
            'description' => '',
        ]);

        // Cek pada session apakah ada error untuk field nama dan description
        $this->assertSessionHasErrors(['name', 'description']);
    }

Hasil: Error

Session missing key: errors
Failed asserting that false is true.

Penyebab

Belum muncul error (dari validasi) pada session, karena kita belum membuat validasi pada TasksController@store.

Solusi

Tambahkan script validasi Laravel untuk field name dan description.

<?php
// TasksController

    // ... method index
    
    public function store()
    {
        request()->validate([
            'name'        => 'required|max:255',
            'description' => 'required|max:255',
        ]);

        Task::create(request()->only('name', 'description'));

        return back();
    }

# 2
$ vendor/bin/phpunit

OK (7 tests, 16 assertions)

Sip. Kita sudah dapat hijau lagi. Sekarang kita coba buka aplikasi dari browser.

Menampilkan error validasi form

Kita coba klik tombol Create Task (submit form). Nah, error SQL sebelumnya sudah hilang. Kita sudah redirect ke halaman sebelumnya, tetapi belum ada tampilan pesan (error) validasi form. Oke, kita tambahkan script untuk menampilkan error validasinya pada view tasks.index.

    <!-- ... -->
    <div class="col-md-4">
        <h2>New Task</h2>

        @if (count($errors) > 0)
            <div class="alert alert-danger">
                <ul class="list-unstyled">
                    @foreach ($errors->all() as $error)
                        <li>{% raw" >}}{{ $error }}{% endraw" >}}</li>
                    @endforeach
                </ul>
            </div>
        @endif

        <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
            <!-- ... -->
        </form>
    </div>
    <!-- ... -->

Simpan, kita kembali ke browser dan coba klik Create Task lagi. Seharusnya kita dapatkan tampilan seperti ini, pesan dari validasi form sudah muncul.

Sekarang kita coba jalankan PHPUnit, untuk memastikan tidak ada yang error/kerusakan dari perubahan barusan.

# 3
$ vendor/bin/phpunit

Ok, sampai di sini selesai penambahan fitur validasi untuk form Input Task.

Mungkin sebagian teman-teman ada yang bertanya, kenapa kita menggunakan $this->post() saat menguji validasi form, bukan menggunakan $this->submitForm() seperti saat testing input task.

Perbedaan “$this->submitForm()” dengan “$this->post()”

Pada $this->submitForm()
Paket browserkit testing berinteraksi dengan halaman web, dia mendeteksi halaman web dengan bantuan DOM Crawler Symfony. Yaitu mencari komponen html berupa tag form yang didalamnya ada tombol submit dengan tulisan Create Task, mencari input field bernama name dan description, kemudian melakukan submit form seolah-olah menekan tombol submit Create Task tadi. Method $this->submitForm() ini juga dapat menerima respons saat aplikasi redirect ke halaman lain.

Kekurangan dari method $this->submitForm() ini, dia tidak mendeteksi isi session Laravel. Sehingga pesan validasi form yang ingin kita cek (di testing) pada session Laravel tidak terlihat. (Mohon koreksi jika saya keliru paham tentang ini).
Pada $this->post()
Paket browserkit testing berinteraksi dengan HTTP Request langsung ke URL yang dituju (misal /tasks) dengan method post.

Method $this->post() ini tidak ~~perduli~~ berinteraksi dengan halaman web, dia langsung mengirim request ke URL tujuan (dengan method yang sesuai). Method ini dapat berinteraksi dengan session Laravel, karenanya kita dapat melihat session yang berisi pesan (error) validasi form.

Kekurangan dari method $this->post() ini, dia mengabaikan form yang kita buat di view. Ketika kita melakukan perubahan field di view, misal nama field description diubah menjadi deskripsi_task (tetapi pada testing tidak disesuaikan), method ini tidak perduli dengan perubahan itu (testing tetap passed), karena dia langsung melakukan request ke URL yang dituju.

Sedangkan method $this->submitForm(), dia akan berpengaruh terhadap perubahan ini. Testing akan fail karena nama field di view berbeda dengan yang di script testing.

BTW, selain $this->post(), ada juga $this->get(), $this->patch(), $this->put(), dan $this->delete(). Masing-masing method ini akan berinteraksi dengan method yang sesuai saat kita mendifinisikan Route pada file routes/web.php, misal Route::get(), Route::post(), Route::patch(), Route::put(), dan Route::delete().

Jadi antara kedua metode submit form tersebut, saya pribadi lebih sering menggunakan $this->submitForm() dalam menguji sebuah fitur CRUD, karena dia beriteraksi dengan halaman web dan elemen-elemen form. Supaya ketika kita mengutak-atik form di view, tetapi lupa menyesuaikan testingnya, testing akan fail (segera ketahuan). Jadi hasilnya lebih pasti dan meyakinkan. :)

Baik teman-teman, semoga artikel ini mudah dimengerti. Jika ada yang belum dipahami atau kurang jelas. Silakan disampaikan di komentar. Perubahan script di atas dapat dilihat pada commit repo ini.

Terima kasih sudah berkenan membaca.

Testing Laravel: Mempercantik Tampilan Web

Sun, 26 Nov 2017 06:13:00 +0800

Bismillahirrahmanirrahim

Setelah mendapatkan passed test, kita mendapatkan tampilan plain html, karena tahap awal kita fokus ke fungsional/fitur yang berjalan sesuai keinginan. Kita lanjutkan untuk mengerjakan tampilan webnya. Pada Laravel sudah built-in file css dan js Bootstrap 3 dengan modifikasi sedikit warna. Kita akan menggunakannya untuk mempercantik tampilan aplikasi kita.

Edit View “tasks.index”

Untuk mendapatkan template tersebut, sebenarnya kita cukup menggunakan file public/css/app.css dan public/js/app.js ke view tasks.index. Tetapi best practice-nya, kita perlu membuat sebuah file layout sebagai master template halaman web, kemudian view tasks.index meng-extend master template/layout tersebut. Nah untuk mempercepat kerja, kita gunakan command make:auth untuk generate file-file view default autentikasi Laravel.

$ php artisan make:auth
Authentication scaffolding generated successfully.

Laravel membuatkan beberapa file untuk kita, termasuk view layouts.app atau file resources/views/layouts/app.blade.php.

Kita edit view tasks.index meng-extend view layouts.app tersebut. Ganti seluruh konten view tasks.index menjadi seperti di bawah ini.

@extends('layouts.app')

@section('content')
<h1 class="page-header text-center">Tasks Management</h1>
<div class="row">
    <div class="col-md-4 col-md-offset-2">
        <h2>Tasks</h2>
        <ul class="list-group">
            @foreach ($tasks as $task)
                <li class="list-group-item">
                    {% raw" >}}{{ $task->name }}{% endraw" >}} <br>
                    {% raw" >}}{{ $task->description }}{% endraw" >}}
                </li>
            @endforeach
        </ul>
    </div>
    <div class="col-md-4">
        <h2>New Task</h2>
        <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
            {% raw" >}}{{ csrf_field() }}{% endraw" >}}
            <div class="form-group">
                <label for="name" class="control-label">Name</label>
                <input id="name" name="name" class="form-control" type="text">
            </div>
            <div class="form-group">
                <label for="description" class="control-label">Description</label>
                <textarea id="description" name="description" class="form-control"></textarea>
            </div>
            <input type="submit" value="Create Task" class="btn btn-primary">
        </form>
    </div>
</div>
@endsection

Hasilnya kurang lebih seperti ini.

Edit View “layouts.app”

Kita lanjutkan untuk menyesuaikan navbar dengan aplikasi kita. Edit file view layouts.app atau file resources/views/layouts/app.blade.php, ubah beberapa baris seperti di bawah ini.

<!-- Baris ke 11, tag title-->
<title>Tasks Management</title>

<!-- Baris ke 30 - 33, Navbar Brand-->
<a class="navbar-brand" href="{% raw" >}}{{ url('/') }}{% endraw" >}}">
    Tasks Management
</a>

<!-- Baris ke 37 - 40, Navbar link kiri -->
<ul class="nav navbar-nav">
    <li><a href="{% raw" >}}{{ url('tasks') }}{% endraw" >}}">Tasks</a></li>
</ul>

<!-- Baris ke 74, bagian yield content -->
<div class="container">@yield('content')</div>

Hasilnya bisa kita lihat di bagian navbar.

Sekarang kita jalankan PHPUnit untuk mengecek apakah yang kita kerjakan membuat kerusakan?

$ vendor/bin/phpunit

Sip. Mestinya testing kita tetap “Hijau”. Jika teman-teman mendapatkan hasil testing “Merah”, silakan cek kembali view tasks.index dan layouts.app tadi, mungkin ada yang keliru di sana. Update kedua file ini dapat teman-teman lihat pada commit repo ini.

Baik sampai di sini kita sudah mengubah tampilan web menjadi lebih bagus tanpa meninggalkan failing test. Selanjutnya insyaallah kita bahas tentang Testing Validasi Form.

Terima kasih atas waktu teman-teman. Mudah-mudahan bermanfaat.

Testing Laravel: Mendapatkan Passed Test

Sat, 14 Oct 2017 13:00:00 +0800

Bismillahirrahmanirrahim

Pada artikel terdahulu, kita sudah membahas dan memahami konsep penerapan Test-Driven Development, 5 tahap yang kita kerjakan :

Buat Kode Pengujian (Add Test).
Jalankan test, hasilnya pasti fail (Watch Test Fail).
Tulis Kode Fitur Sistem (Write Code).
Jalankan test (Run Tests) hingga testing passed.
Refactor Kode Fitur Sistem (Refactor).

Empat Langkah Perulangan

Berdasarkan konsep itu, pada artikel sebelumnya kita mengerjakan tahap pertama, yaitu membuat Kode Pengujian (Failing Test). Kali ini kita akan mengerjakan tahap ke 2 dan ke 3, dengan melakukan 4 langkah berikut secara berulang-ulang :

Jalankan vendor/bin/phpunit
Error tampil
Temukan Penyebab
Tentukan Solusi

Keempat langkah ini dilakukan setiap kita menemukan error baru yang ditampilkan oleh PHPUnit. Setiap ekseksusi PHPUnit pada artikel ini kita berikan hashtag (#) angka. Saya menghitung ada 19 proses yang dilakukan dari awal sampai kita mendapatkan “Hijau”.

Oke, kita mulai

# 1
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks] failed. Received status code [404].
Pada artikel sebelumnya kita sampai di sini.

Penyebab

Belum ada route untuk melayani request ke URL /tasks.

Solusi

Buat route untuk melayani request ke /tasks pada file routes/web.php. Tambahkan route get ke url tasks dengan controller dan method yang melayani requestnya.

<?php
// routes/web.php

Route::get('/', function () {
    return view('welcome');
});

// Tambahkan route dan actionnya (controller dan method)
Route::get('tasks', 'TasksController@index');

# 2
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks] failed. Received status code [500].

Caused by
ReflectionException: Class App\Http\Controllers\TasksController does not exist

Penyebab

TasksController belum ada.

Solusi

$ php artisan make:controller TasksController

# 3
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks] failed. Received status code [500].

Caused by
BadMethodCallException: Method [index] does not exist.

Penyebab

Pada TasksController belum ada method index.

Solusi

Tambahkan method index pada app/Http/Controllers/TasksController.php.

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class TasksController extends Controller
{
    public function index()
    {

    }
}

# 4
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Could not find a form that has submit button [Create Task].

Penyebab

Ini karena pada TasksController method index, kita tidak return view, sehingga hanya tampil halaman web kosong.

Solusi

Kita return view pada method index.

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class TasksController extends Controller
{
    public function index()
    {
        return view('tasks.index');
    }
}

# 5
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: View [tasks.index] not found.

Penyebab

File index.blade.php tidak ditemukan pada direktori resources/views/tasks.

Solusi

Kita buat file index.blade.php pada direktori resources/views/tasks.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Tasks Management</title>
</head>
<body>
    
</body>
</html>

# 6
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Could not find a form that has submit button [Create Task].

Penyebab

Pada file resources/views/tasks/index.blade.php atau disebut juga view tasks.index tidak ditemukan Tombol Submit Create Task.

Solusi

Kita buat file form dengan tombol submit Create Task pada view tasks.index.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Tasks Management</title>
</head>
<body>
    <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
        <input type="submit" value="Create Task">
    </form>
</body>
</html>

# 7
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Unreachable field "name"

Penyebab

Pada view tasks.index tidak ditemukan input text field dengan nama name.

Solusi

Dalam form pada view tasks.index tambahkan input text dengan nama name.

<!-- body -->
    <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
        <input type="text" name="name">
        <input type="submit" value="Create Task">
    </form>
<!-- /body -->

# 8
$ vendor/bin/phpunit

Hasil: Error

InvalidArgumentException: Unreachable field "description"

Penyebab

Pada view tasks.index tidak ditemukan input textarea field dengan nama description.

Solusi

Pada view tasks.index kita buat input textarea dengan nama description.

<!-- body -->
    <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
        <input type="text" name="name">
        <textarea name="description"></textarea>
        <input type="submit" value="Create Task">
    </form>
<!-- /body -->

# 9
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks] failed. Received status code [405].

Caused by
Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException

Penyebab

Pada route sudah ada route tasks yang kita buat, tetapi ini untuk method get, sedangkan saat kita submit form, kita mengirimkan method POST artinnya kita perlu route juga untuk melayani method POST ini.

Solusi

Pada routes/web.php, buat route untuk melayani method POST.

<?php
// routes/web.php

Route::get('/', function () {
    return view('welcome');
});

// Tambahkan route dan actionnya (controller dan method)
Route::get('tasks', 'TasksController@index');
Route::post('tasks', 'TasksController@store');

# 10
$ vendor/bin/phpunit

Hasil: Error

A request to [http://localhost/tasks] failed. Received status code [500].

Caused by
BadMethodCallException: Method [store] does not exist.

Penyebab

Pada TasksController belum ada method store.

Solusi

Kita buat methodnya, buka app/Http/Controllers/TasksController.php. Tambahkan method store

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class TasksController extends Controller
{
    public function index()
    {
        return view('tasks.index');
    }

    public function store()
    {

    }
}

# 11
$ vendor/bin/phpunit

Hasil: Error

PDOException: SQLSTATE[HY000]: General error: 1 no such table: tasks

Penyebab

Belum ada tabel tasks di database.

Solusi

Nah sekarang kita berurusan dengan database, kita buat model Task dengan file migrations untuk tabel tasks.

# Membuat model `Task` beserta file database migrationnya
$ php artisan make:model Task -m

# 12
$ vendor/bin/phpunit

Hasil: Error

PDOException: SQLSTATE[HY000]: General error: 1 no such table: tasks

Penyebab

Kok Errornya masih sama? Yap, PHPUnit belum tahu file migration yang barusan dibuat bersama model Task itu harus diapakan.

Solusi

Solusinya kita gunakan Trait RefreshDatabase pada kelas tests\Feature\ManageTasksTest.php agar setiap PHPUnit jalan, dia melakukan database migration.

<?php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class ManageTasksTest extends TestCase
{
    use RefreshDatabase; // Tambahkan baris ini

    /** @test */
    public function user_can_create_a_task()
    {
        // ...
    }
}

# 13
$ vendor/bin/phpunit

Hasil: Error

Unable to find row in database table [tasks] that matched attributes [{"name":"My First Task", ...

Penyebab

Belum ada action yang dilakukan pada method store untuk mengisi database dengan data yang telah diinput melalui form.

Solusi

Kita kerjakan kode pembuatan record task yang diproses dari form pada method store.

<?php

namespace App\Http\Controllers;

use App\Task; // Tambahkan ini
use Illuminate\Http\Request;

class TasksController extends Controller
{
    // ... method index

    public function store()
    {
        Task::create(request()->only('name', 'description'));
    }
}

Jangan lupa use App\Task; di atas class.

# 14
$ vendor/bin/phpunit

Hasil: Error

Illuminate\Database\Eloquent\MassAssignmentException: name

Penyebab

MassAssignmentException

Solusi

Kita tambahkan protected property $fillable pada model Task untuk kolom name dan description.

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Task extends Model
{
    protected $fillable = ['name', 'description'];
}

# 15
$ vendor/bin/phpunit

Hasil: Error

PDOException: SQLSTATE[HY000]: General error: 1 table tasks has no column named name

Penyebab

Tidak ditemukan kolom name pada tabel task di database.

Solusi

Edit file xxxxx_create_tasks_table kemudian tambahkan attribute name, description, dan is_done;

<?php

class CreateTasksTable extends Migration
{
    // ...
    public function up()
    {
        Schema::create('tasks', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('description');
            $table->boolean('is_done')->default(0);
            $table->timestamps();
        });
    }

# 16
$ vendor/bin/phpunit

Hasil: Error

1) Tests\Feature\ManageTasksTest::user_can_create_a_task
InvalidArgumentException: The current node list is empty.

...
...
/home/nafies/www/lv/riset/laravel-tdd/tests/Feature/ManageTasksTest.php:35

ERRORS!
Tests: 2, Assertions: 7, Errors: 1.

Penyebab

The current node list is empty, artinya PHPUnit tidak menemukan apa-apa di halaman webnya, hanya berupa halaman kosong. Ini karena kita belum memberikan return apa-apa pada method store nya.

Solusi

Kita berikan kode return back(); pada method store, agar Laravel mengembalikan kita ke halaman sebelumnya (index tasks).

<?php
    // ... TasksController

    public function store()
    {
        Task::create(request()->only('name', 'description'));

        return back();
    }

# 17
$ vendor/bin/phpunit

Hasil: Error

Failed asserting that the page contains the HTML [My First Task].

Penyebab

Pada halaman view tasks.index kita belum menampilkan daftar Task yang ada di dalam tabel tasks di database.

Solusi

Kita edit TasksController agar mengambil record task dari database, kemudian kita tampilkan di view tasks.index.

<?php

namespace App\Http\Controllers;

use App\Task; // Tambahkan ini
use Illuminate\Http\Request;

class TasksController extends Controller
{
    public function index()
    {
        $tasks = Task::all();
        return view('tasks.index', compact('tasks'));
    }

    // ... method store
}

Jangan lupa use App\Task; di atas class.

Kemudian pada view tasks.index :

<!-- body -->
    <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
        <input type="text" name="name">
        <textarea name="description"></textarea>
        <input type="submit" value="Create Task">
    </form>
    <h1>Tasks Management</h1>
    <ul>
        @foreach ($tasks as $task)
            <li>
                {% raw" >}}{{ $task->name }}{% endraw" >}} <br>
                {% raw" >}}{{ $task->description }}{% endraw" >}}
            </li>
        @endforeach
    </ul>
<!-- /body -->

# 18
$ vendor/bin/phpunit

Hasil: Passed

{:style=“width:100%”}

Yeeyyy… akhirnya setelah perjalanan panjang, kita dapat “Hijau” :) Ini artinya testing kita pada ManageTasksTest method user_can_create_a_task() sudah berhasil.

Mencoba Fitur Input Task pada Browser

Asumsinya, kita belum mencoba untuk membuka aplikasi ini dengan browser. Sekarang kita coba aplikasinya melalui browser, kira-kira seperti apa bentuknya?

$ php artisan serve
Laravel development server started: <http://127.0.0.1:8000>

Buka URL di browser : http://127.0.0.1:8000/tasks.

Kok error, ya? Iya, karena kita belum melakukan konfigurasi database di sisi aplikasi, kita baru setting database di . Silakan teman-teman buat database pada MySQL atau SQLite, kemudian konfigurasikan databasenya pada file .env. Di PC saya konfigurasinya menggunakan SQLite :

...
APP_LOG_LEVEL=debug
APP_URL=http://localhost

DB_CONNECTION=sqlite

BROADCAST_DRIVER=log
CACHE_DRIVER=file
...

Matikan development server (artisan serve) tadi. Kemudian migrasikan database :

$ php artisan migrate
Migrating: 2017_10_14_051259_create_tasks_table
Migrated:  2017_10_14_051259_create_tasks_table

Kemudian

$ php artisan serve
Laravel development server started: <http://127.0.0.1:8000>

Hasil di browser :

Hehe.. masih jelek ya, tidak apa-apa sekarang silakan coba input data task nya. Tapi ternyata belum bisa …

Masalahnya adalah hidden field CSRF Token belum ada pada form. Sekarang kita tambahkan {% raw" >}}{{ csrf_field() }}{% endraw" >}} persis di bawah tag form:

<!-- body -->
    <form action="{% raw" >}}{{ url('tasks') }}{% endraw" >}}" method="post">
        {% raw" >}}{{ csrf_field() }}{% endraw" >}}
        <input type="text" name="name">
        <textarea name="description"></textarea>
        <input type="submit" value="Create Task">
    </form>
<!-- /body -->

Jalankan lagi phpunit.

# 19
$ vendor/bin/phpunit

{:style=“width:100%”}

Sip, no problem, kita masih dapat “Hijau”. Kita coba input Task dan Deskripsi lagi, seharusnya sudah bisa berhasil.

Oke berhasil input task. Sampai di sini proses TDD untuk pembangunan sub-fitur Input Task sudah selesai. Silakan teman-teman berkreasi untuk menambakan validasi form, atau mempercantik tampilan pada browser.

Kesimpulan

Dalam penerapan TDD, testing memandu kita membangun fitur (atau sub-fitur) dengan cara memperbaiki error yang tampil.
Empat langkah berulang dalam TDD Laravel :
1. Jalankan vendor/bin/phpunit
2. Error tampil
3. Temukan Penyebab
4. Tentukan Solusi
Jika setiap perubahan yang kita lakukan di kode aplikasi membuat error yang berbeda pada PHPUnit, berarti progress kita ada kemajuan.
Proses TDD hanya berfokus untuk pembangunan fitur sistem, tidak terpengaruh bagaimana tampilan yang muncul pada browser.
Selama perubahan yang dilakukan tidak “merusak” fitur pada kode aplikasi, testing akan tetap menghasilkan “Hijau”. Salah satunya telah kita buktikan saat kita menambahkan csrf_field() pada form tadi.

Pada artikel berikutnya insyaallah kita akan mempercantik tampilan view tasks.index, agar ketika melanjutkan proses TDD pada fitur berikutnya, kita sudah memiliki tampilan yang bagus.

Jika teman-teman ada yang mencoba praktek dan menemui kendala atau stuck di salah satu langkah, atau mendapatkan pesan error yang berbeda dengan proses di atas, silakan tuliskan di kolom komentar, kita bahas sama-sama.

Terima kasih atas waktunya.

Testing Laravel: Definisi Fitur dan First Failing Test

Wed, 11 Oct 2017 08:00:00 +0800

Bismillahirrahmanirrahim

Sebelumnya kita membahas setup project baru laravel dengan testing, sekarang kita lanjutkan membuat definisi dari fitur yang akan kita buat. Pada tutorial TDD ini, ceritanya kita akan membuat Fitur CRUD Task atau Create, Read, Update, and Delete Task.

Pada penerapan TDD, proses yang kita lakukan saat membuat sebuah fitur kurang lebih seperti ini (mulai perencanaan hingga implementasi) :

Mendefinisikan fitur.
Memprioritas sub-fitur.
Membuat kelas TestCase fitur.
Membuat method test untuk masing-masing sub-fitur.
Mulai membuat failing test untuk method test.
Mulai kerjakan (menulis kode) fitur pada aplikasi sampai failing test menjadi passed test.
Ulangi langkah 4 s/d 6 hingga fitur selesai dibuat.

1. Definisi Fitur

Mendefinisikan sama dengan menentukan/menyusun spesifikasi dari fitur yang kita ingin buat. Kali ini kita akan membuat fitur CRUD Task dengan spesifikasi sebagai berikut :

Record pada database disimpan dalam tabel tasks dengan atribut name, description, dan is_done
Atribut is_done : 0 belum dikerjakan, 1 sudah dikerjakan.
User dapat melihat daftar Task
User dapat menginput Task baru
User dapat meng-edit Task
User dapat menghapus Task

2. Menyusun Prioritas Sub-fitur

Berikutnya kita susun prioritas pengerjaan fitur/sub-fitur mana yang kita kerjakan duluan dari spesifikasi di atas, dilengkapi dengan rencana konsep pengoperasian oleh user.

Input Task
Untuk melakukan Input Task baru, user membuka halaman Daftar Task, kemudian mengisi form name dan description, klik tombol “Create Task”. Setelah berhasil, record Task tersimpan ke database, user redirect ke halaman Daftar Task, dan melihat Task yang telah diinput tampil pada halaman webnya.
Lihat Daftar Task
Jika ada record Task di dalam database, kemudian user membuka halaman Daftar Task. Muncul nama dan deskripsi Task yang ada.
Edit/Update Task
Jika ada record Task di dalam database, kemudian user membuka halaman Daftar Task, User meng-klik tombol “Edit Task”, mengubah name dan description kemudian tekan tombol “Update Task”. Setelah berhasil, record tersimpan di database, user redirect ke halaman Daftar Task, dan melihat Task yang telah diupdate pada halaman webnya.
Hapus Task
Jika ada record Task di dalam database, kemudian user membuka halaman Daftar Task, User melihat tombol “Delete Task”. User meng-klik tombol “Delete Task”. Setelah berhasil, user redirect ke halaman Daftar Task, record Task tidak tampil dan hilang dari database.

Penyusunan prioritas ini penting, agar kita tahu sub-fitur mana yang mesti dikerjakan terlebih dahulu dibandingkan dengan sub-fitur yang lain. Ini melatih kita (sebagai developer) untuk efisien waktu dan manajemen project. Lama-kelamaan kita bisa dengan mudah meng-estimasi lama pengerjaan dari sebuah fitur dengan spesifikasi tertentu.

3. Membuat Kelas TestCase

Kelas TestCase adalah kelas testing untuk sebuah fitur, yang dibuat untuk mengelompokkan pengujian sub-sub fiturnya. Misal kita ingin membuat sebuah kelas testing untuk fitur Kalkulator, maka kelas TestCase yang kita buat bernama KalkulatorTest. Di dalam kelas KalkulatorTest terdapat method-method test untuk masing-masing sub-fitur dari kalkulator tersebut.

Baik, kita lanjut. Pada terminal, kita cd ke direktori Project Laravel, kemudian jalankan testing untuk memastikan testing yang sudah ada berjalan dengan baik :

$ vendor/bin/phpunit

{:style=“width:100%”}

Hasilnya, 2 tests dan 2 assertions, sama seperti kondisi akhir artikel sebelumnya.

Untuk membuat TestCase baru, kita berikan perintah :

$ php artisan make:test ManageTasksTest

Laravel membuat TestCase pada direktori tests/Feature bernama ManageTasksTest.php.

<?php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class ManageTasksTest extends TestCase
{
    /**
     * A basic test example.
     *
     * @return void
     */
    public function testExample()
    {
        $this->assertTrue(true);
    }
}

Sekarang kita coba jalankan lagi testingnya :

$ vendor/bin/phpunit

{:style=“width:100%”}

Oke, sudah ada 3 tests dan 3 assertions artinya kelas ManageTasksTest sudah jalan. Sampai disini kita lanjutkan membuat method-method testingnya.

Akhiran (suffix) Test wajib untuk setiap nama kelas TestCase. Karena tanpa suffix Test, PHPUnit tidak mengenali kelas tersebut sebagai kelas testing yang harus dijalankan. Referensi.

4. Membuat Method Test

Method Test atau Test Method adalah method-method pada kelas TestCase yang akan dijalankan oleh PHPUnit. Untuk mempermudah pemahaman kita, satu Test Method itu sama dengan pengujian untuk satu sub-fitur. Jadi kita akan membuat :

Satu Test Method untuk Input Task
Satu Test Method untuk Lihat Daftar Task
Satu Test Method untuk Edit Task
Satu Test Method untuk Hapus Task

Baik kita edit file kelas tests/Feature/ManageTasksTest.php dan kita update seperti ini :

<?php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;

class ManageTasksTest extends TestCase
{
    /** @test */
    public function user_can_create_a_task()
    {
        $this->assertTrue(true);
    }

    /** @test */
    public function user_can_browser_tasks_index_page()
    {
        $this->assertTrue(true);
    }

    /** @test */
    public function user_can_edit_an_existing_task()
    {
        $this->assertTrue(true);
    }
    
    /** @test */
    public function user_can_delete_an_existing_task()
    {
        $this->assertTrue(true);
    }
}

Ingat, satu test method mewakili satu sub-fitur :

user_can_create_a_task untuk Input Task
user_can_browser_tasks_index_page untuk Lihat Daftar Task
user_can_edit_an_existing_task untuk Edit Task
user_can_delete_an_existing_task untuk Hapus Task

Sekarang kita jalankan lagi PHPUnit-nya, seharusnya kita mendapat hasil seperti berikut :

{:style=“width:100%”}

“Hijau” ya? Baik, sampai di sini kita punya 4 sub-fitur dengan Test Method masing-masing untuk fitur CRUD Task.

Syarat sebuah test method : harus berupa public method dan nama method harus diawali dengan test atau diberikan anotasi @test pada docblock method. Referensi.

5. Membuat “Failing Test”

Sekarang kita fokus ke method user_can_create_a_task() untuk membuat failing test, yaitu script testing yang kita buat ini untuk menguji fitur yang belum ada di sistem, jadi pasti gagal (fail).

Oke, untuk mempermudah membuat script testing, kita buat beberapa perumpamaan langkah/proses yang dilakukan oleh user ketika menggunakan sub-fitur tersebut dengan PHP comment line. Seperti ini :

<?php
// Kelas ManageTasksTest.php

    /** @test */
    public function user_can_create_a_task()
    {
        // User buka halaman Daftar Task

        // Isi form `name` dan `description` kemudian submit

        // Lihat Record tersimpan ke database

        // Redirect ke halaman Daftar Task

        // Tampil hasil task yang telah diinput
    }

Metode ini saya pelajari dari video youtube Laravel Daily.

Setelah membuat comment seperti di atas, kita coba buat testing script-nya untuk masing-masing langkah ini.

<?php
// Kelas ManageTasksTest.php

    /** @test */
    public function user_can_create_a_task()
    {
        // User memngunjungi halaman Daftar Task
        $this->visit('/tasks');
        
        // Isi form `name` dan `description` kemudian submit
        $this->submitForm('Create Task', [
            'name' => 'My First Task',
            'description' => 'This is my first task on my new job.',
        ]);
        
        // Lihat Record tersimpan ke database
        $this->seeInDatabase('tasks', [
            'name' => 'My First Task',
            'description' => 'This is my first task on my new job.',
            'is_done' => 0,
        ]);
        
        // Redirect ke halaman Daftar Task
        $this->seePageIs('/tasks');

        // Tampil hasil task yang telah diinput
        $this->see('My First Task');
        $this->see('This is my first task on my new job.');
    }

Kita bisa lihat, setiap langkah/proses yang seharusnya dilakukan oleh user (manusia) kita gantikan dengan testing script yang sesuai :

$this->visit('/tasks'); untuk mengunjungi halaman dengan URL tertentu.
$this->submitForm('Create Task', ... untuk mengisi form dan klik tombol “Create Task”.
$this->seePageIs('/tasks'); melihat URL yang kita dapatkan setelah action sebelumnya.
$this->seeInDatabase('tasks', ... melihat isi tabel tasks pada database.
$this->see('.....'); melihat isi tulisan yang tampil di halaman web.

Oke, jika kita jalankan kembali PHPUnitnya :

$ vendor/bin/phpunit

Hasilnya? {:style=“width:100%”}

{:style=“width:100%”}

Yap kita dapat “Merah”, “failing test” pertama berhasil dibuat :)

Pada error ini, yang kita perhatikan adalah tulisan-tulisan pada posisi saya garis bawahi pada gambar di atas :

Tulisan di bawah Kelas dan method test
Status Code yang didapatkan
Baris keberapa pada Kelas Test kita mendapatkan error ini
Disebabkan oleh apa error ini terjadi.

Dengan memperhatikan 4 hal di atas, kita bisa tahu, apa yang menyebabkan error ini terjadi, sehingga kita dapat memperbaiki kode di aplikasi yang kita buat. Untuk error yang pertama ini, kita mendapatkan NotFoundHttpException, artinya route untuk URL /tasks itu tidak ditemukan.

Untuk membuktikannya, sekarang coba kita buka halaman webnya :

$ php artisan serve
Laravel development server started: <http://127.0.0.1:8000>

Kita coba buka URL di browser : http://127.0.0.1:8000/tasks.

Setiap error yang tampil pada terminal saat kita menjalankan test, umumnya sama dengan tampilan error yang muncul di layar web. Pesan di atas sama dengan NotFoundHttpException dan status code = 404, hanya saja dihandle oleh Laravel dengan menampilkan halaman error 404.

Baik, sampai di sini cukup dulu. Insyaallah pada artikel berikutnya, kita akan menulis kode aplikasi untuk sub-fitur input Task, sampai testing method user_can_create_a_task() mendapatkan hasil “Hijau”.

Jika ada yang kurang jelas dengan penjelasan dan tutorial pada artikel ini, atau ada hal yang keliru, mohon disampaikan pada komentar.

Terima kasih untuk waktu teman-teman berkenan membaca.

Source untuk kelas ManageTasksTest dapat dilihat commit github ini.

Testing Laravel: Setup Project Baru dengan Testing

Fri, 06 Oct 2017 14:05:00 +0800

Bismillahirrahmanirrahim

Alhamdulillah akhirnya bisa mulai menulis lagi. Sekitar dua bulan sebelumnya (terakhir) kita membahas Testing Laravel, tentang Test-Driven Development (TDD), yaitu menulis script testing terlebih dahulu sebelum menulis kode untuk aplikasinya. Sekarang kita lanjutkan untuk melakukan setup/konfigurasi awal project Laravel untuk memulai alur kerja TDD.

Awalnya saya memang menunda untuk menulis artikel ini karena menunggu rilis Laravel 5.5. Niatnya biar sekalian belajar Laravel 5.5. Setelah rilis, ternyata banyak kegiatan yang membuat penulisan artikel ini semakin tertunda. Tapi sekali lagi, alhamdulillah akhirnya bisa mulai menulis lagi.

Setup Local Development

Sebelum memulai, saya ingin menginformasikan development environment yang saya gunakan saat menulis artikel ini :

Sistem Operasi: Ubuntu 16.04.3 LTS
Web server : Apache/2.4.18
Versi PHP : 7.0.22
Terminal : GNOME Terminal
Database : MariaDB 10.0.31 (Local) & SQLite3 (Testing)
Versi Laravel : 5.5.14
Direktori Project : ~/www/lv/riset/laravel-tdd

Baik, pada artikel kali ini asumsinya kita sudah menginstall sebuah project Laravel yang baru (fresh install). Kita mulai dengan membuka terminal dan cd ke direktori project Laravel tersebut.

$ cd ~/www/lv/riset/laravel-tdd

Pastikan project Laravel terinstall dengan benar jika kita berhasil melihat versinya.

$ php artisan -V
Laravel Framework 5.5.14

Karena setiap installasi Laravel sudah termasuk dengan paket software testing PHPUnit (sebagai dependensinya), maka kita dapat mencobanya dengan perintah :

$ vendor/bin/phpunit

Mestinya kita akan mendapatkan tampilan seperti ini :

Sip, kalau sudah dapat warna “Hijau”, artinya Laravel terinstall dengan benar dan PHPUnit berjalan dengan baik.

Perhatikan: jika teman-teman belum menghasilkan tampilan yang sama, kemungkinan Laravel belum terintsall dengan benar.

Baik, sampai di sini sebenarnya kita sudah bisa mulai ngoding testingnya, tetapi untuk menyesuaikan dengan testing setup yang biasa saya lakukan (setiap memulai project Laravel), perlu dilakukan beberapa pengaturan/konfigurasi lagi.

Install paket Laravel Browser Kit Testing

Pertama kita akan install sebuah paket tambahan, yaitu Laravel Browser Kit Testing. Dengan paket ini, kita dapat menulis script testing agar PHPUnit dapat interaksi dengan browser. Misal : untuk mengisi form, menekan tombol/submit form, mengecek keberadaan element html, mengunjungi halaman dengan klik link, dan beberapa fitur testing lainnya untuk mempermudah alur kerja TDD kita.

Silakan menginstall dengan cara :

$ composer require laravel/browser-kit-testing dev-master --dev

Sebenarnya paket Browser Kit Testing ini berisi fitur-fitur testing yang ada pada Laravel 5.2 dan 5.3, tetapi pada versi 5.4 dan seterusnya, fitur ini dihilangkan, diganti dengan Laravel Dusk untuk interaksi dengan browser (afaik).

Oke setelah selesai, kita lanjutkan dengan meng-edit file tests/TestCase.php untuk mendapatkan fitur dari paket laravel/browser-kit-testing yang barusan kita install tadi.

Mengubah file BaseTest.php

File tests/TestCase.php adalah kelas Base Test yaitu kelas abstract yang di-extends oleh seluruh kelas-kelas testing yang akan kita buat di project Laravel (ibarat sebagai induknya testing kita). Nah, kelas/file ini harus kita ubah/sesuaikan agar kita dapat menggunakan fitur-fitur dari paket Browser Kit Testing.

Buka file tests/TestCase.php dengan text editor, akan kita dapatkan seperti berikut :

<?php
// tests/TestCase.php

namespace Tests;

use Illuminate\Foundation\Testing\TestCase as BaseTestCase;

abstract class TestCase extends BaseTestCase
{
    use CreatesApplication;
}

Sekarang kita ubah isinya menjadi seperti di bawah:

<?php
// tests/TestCase.php

namespace Tests;

use Laravel\BrowserKitTesting\TestCase as BaseTestCase;

abstract class TestCase extends BaseTestCase
{
    use CreatesApplication;

    public $baseUrl = 'http://localhost';
}

Perhatikan kita mengubah 1 baris Laravel\BrowserKitTesting\TestCase, dan menambahkan baris public $baseUrl = 'http://localhost';. Simpan, kemudian kembali ke terminal dan jalankan perintah :

$ vendor/bin/phpunit

Ups, dapat “Merah” ya? Artinya ada yang mesti kita perbaiki dulu setelah perubahan yang kita lakukan tadi.

Oke kita buka file yang error, yaitu tests/Feature/ExampleTest.php, lihat pada baris ke 20 : $response->assertStatus(200). Script ini adalah method assertion bawaan Laravel sejak versi 5.4 (Illuminate\Foundation\Testing\TestCase), sedangkan kita sudah menentukan pada file tests/TestCase.php bahwa kita menggunakan paket Browser Kit Testing sebagai Base Test atau induk kelas-kelas testingnya. Maka script yang error itu harus diperbaik/diganti :

<?php
// tests/Feature/ExampleTest.php

public function testBasicTest()
{
    // $response = $this->get('/');

    // $response->assertStatus(200); // Tidak ada pada paket Browser Kit Test
    
    // Kedua baris kode di atas digantikan dengan yang ini
    $this->visit('/');
}

Kode $this->visit('/'); adalah salah satu method testing dari Browser Kit Testing.

Setelah itu kita jalankan kembali vendor/bin/phpunit, seharusnya kita akan mendapatkan hasil warna “Hijau” seperti sebelumnya, artinya sudah tidak ada masalah lagi dengan perubahan file tests/TestCase.php tadi.

Oke, karena sudah tidak ada masalah, kita rapikan file test tests/Feature/ExampleTest.php, seperti ini :

<?php
// tests/Feature/ExampleTest.php

public function testBasicTest()
{
    $this->visit('/');
}

Sip, setup untuk konfigurasi paket BrowserKitTesting selesai.

Mengubah file phpunit.xml

Sekarang kita lanjutkan untuk konfigurasi database yang digunakan untuk testing. Kita akan (dan harus) membuat database yang terpisah antara database local development (yang kita gunakan untuk uji coba manual) dengan database untuk Automated Testing. Mengapa? Agar database yang digunakan oleh Automated Testing tidak “mengganggu” database yang kita gunakan saat uji coba manual. Mengganggu? Oke, nanti temen-temen bisa lihat kenapa database ini mesti kita pisahkan, kita lanjutkan dulu.

Seperti yang saya informasikan di awal artikel ini, database untuk local development (pengujian manual) kita menggunakan MariaDB atau MySQL, sedangkan untuk Testing kita gunakan SQLite. Kenapa SQLite? Samakah SQLite dengan MySQL? Beda, tapi mirip. Karena yang akan kita buat adalah fitur CRUD biasa, SQLite sangat cukup dan sepadan dengan MySQL untuk tujuan ini. SQLite juga dapat diatur menggunakan in-memory database, ini menjadikan proses testing lebih cepat.

Untuk dapat menggunakan SQLite pada testing, kita mengkonfigurasinya dengan cara mengubah file phpunit.xml. Atur agar environment variable database testing menggunakan in-memory database SQLite.

Kita buka file phpunit.xml. Tambahkan dua baris kode berikut pada bagian env :

<phpunit>
    <!-- ..... -->
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="QUEUE_DRIVER" value="sync"/>
        <!-- Tambahkan dua baris di bawah ini untuk pengaturan database -->
        <env name="DB_CONNECTION" value="sqlite"/>
        <env name="DB_DATABASE" value=":memory:"/>
    </php>
</phpunit>

Untuk dapat menggunakan SQLite, kita pastikan pada PC kita sudah terinstall sqlite3 dan extension php7.0-sqlite3.

Oke sekarang kita jalankan lagi php unit untuk mengecek apakah perubahan pada file ini berdampak masalah/error.

Sip, selama testing dapat “Hijau”, artinya tidak ada masalah. Sampai di sini proses konfigurasi awal testing di Project Laravel kita selesai. Pada artikel selanjutnya insyaallah kita akan membuat script testing pertama kita. Tahapannya, mendefinisikan fitur yang akan dibuat kemudian menterjemahkan fitur-fitur tersebut menjadi method-method testing.

Jika ada pertanyaan tentang artikel ini, silakan teman-teman tulis di komentar. Terima kasih atas waktunya sudah berkenan membaca.

Cara Install Aplikasi Laravel dari Github ke XAMPP Windows

Sat, 19 Aug 2017 13:30:00 +0800

Kita sebagai pengguna XAMPP di Windows kadang agak kesulitan menginstall source code Laravel agar dapat digunakan dengan XAMPP, utamanya bagi yang belum pernah kenal dengan Laravel. Biasanya si pembuat aplikasi mengasumsikan orang-orang yang akan menggunakan source code tersebut sudah familiar dengan framework yang digunakan.

Misalkan kita ingin menginstall source code dari repo Github Silsilah agar dapat kita gunakan dan eksplorasi.

Asumsi

Pada panduan di bawah, saya mengasumsikan bahwa pembaca sudah terbiasa dengan PHP menggunakan XAMPP di Windows, tetapi belum berkenalan dengan Composer dan Laravel.

Yang harus Disiapkan

Memiliki CLI/Command Line Interface berupa Command Prompt (CMD) atau Power Shell atau Git Bash (selanjutnya kita sebut terminal).
Memiliki Web Server (misal XAMPP) dengan PHP minimal versi 5.6.
Composer telah ter-install, cek dengan perintah composer -V melalui terminal.
Dapat menggunakan perintah php -v dengan terminal (menampilkan versi php). Caranya bisa ikuti langkah pada artikel ini Cara Menjalankan PHP Melalui CMD sampai langkah 6.
Memiliki koneksi internet (untuk proses installasi).

Langkah pengerjaan

Download Source Code dari repo Github Silsilah dalam bentuk Zip.
Extract file zip (source code) ke dalam direktori htdocs pada XAMPP, misal htdocs/silsilahku.
Melalui terminal, cd ke direktori silsilahku.
(Sesuai petunjuk installasi) Pada terminal, berikan perintah composer install. Ini yang perlu koneksi internet.
Composer akan menginstall dependency paket dari source code tersebut hingga selesai.
Jalankan perintah php artisan, untuk menguji apakah perintah artisan Laravel bekerja.
Buat database baru (kosong) pada mysql (via phpmyadmin).
Duplikat file .env.example, lalu rename menjadi .env.
Kembali ke terminal, php artisan key:generate.
Setting koneksi database di file .env (DB_DATABASE, DB_USERNAME, DB_PASSWORD).
Jalan kan perintah php artisan migrate Jika di cek di phpmyadmin, seharusnya tabel sudah muncul.
Setelah selesai, buka aplikasi melalui browser, misal : http://localhost/silsilahku/public
Klik link Register untuk mendaftarkan user baru.
Login dan aplikasi siap digunakan.

Seperti itu lebih kurangnya cara menginstall aplikasi Laravel dari github ke XAMPP di Windows. Mudah-mudahan membantu teman-teman yang belum familiar dengan cara menggunakan source code di Github, Composer dan Laravel.

Terima kasih sudah berkenan membaca.

Testing Laravel: Tentang TDD (Test-Driven Development)

Wed, 02 Aug 2017 14:18:00 +0800

Sebagaimana sempat disinggung pada artikel sebelumnya , bahwa dengan menerapkan Automated Testing pada sistem/aplikasi yang kita buat, kita jadi kerja dua kali, yaitu :

Menulis kode untuk membangun aplikasi dan
Menulis kode untuk membuat kode pengujian setiap fitur yang ada pada sistem.

Jika testing script dibuat setelah sistem selesai, tentunya lumayan menyita waktu. Padahal biasanya User menginginkan sistem segera lauhcing dan mulai digunakan. Ditambah lagi developer biasanya sudah males ngutak-ngutik sistem yang sudah jadi (apalagi fiturnya banyak). Akhirnya batal bikin testing. :)

Metode paling efektif untuk menerapkan Testing Automation adalah Test-Driven Development (TDD). Menerjemahkan secara bebas pengertian dari Wikipedia :

Test-Driven Development adalah suatu metode pembangunan aplikasi dengan terlebih dahulu menulis “kode pengujian” sebelum menulis kode aplikasinya, sehingga testing memandu developer dalam proses development aplikasi tersebut.

Konsepnya seperti ini:

Sumber gambar : Test-Driven Development

Konsep Penerapan TDD

Misalkan kita ingin membuat sebuah fitur dengan TDD, metodenya seperti ini :

Buat Kode Pengujian (Add Test).
Jalankan test, hasilnya pasti fail (Watch Test Fail).
Tulis Kode Fitur Sistem (Write Code).
Jalankan test (Run Tests) hingga testing passed.
Refactor Kode Fitur Sistem (Refactor).

Penerapan dari metode di atas, langkah aktual yang dikerjakan kurang lebih begini :

Buat Kode Pengujian artinya kita membuat testing script (pada software testing) sesuai spesifikasi fitur yang diinginkan.
Jalankan Test artinya kita menjalankan software testing untuk melihat testing fail (gagal) dengan pesan error-nya.
Tulis Kode Fitur Sistem artinya kita mulai ngoding atau menulis script di aplikasi/sistem yang ingin dibuat. Script yang ditulis ini adalah script untuk memperbaiki error yang ditunjukkan oleh software testing.
Jalankan Test lagi, ketemu pesan error yang berbeda (masih fail).
Tulis script lagi untuk “memperbaiki” error-nya.
Jalankan Test lagi hingga mendapatkan pesan error yang berbeda lagi (masih fail).
Ulangi terus langkah “Tulis Kode”, “Jalankan Test”, “Tulis Kode”, “Jalankan Test” hingga mendapatkan testing passed (lulus).
Ketika testing sudah passed, kita bebas refactor (mengutak-utik) kode/script pada aplikasi. Selama hasil testing-nya tetap passed artinya fitur tersebut tetap bekerja sebagaimana mestinya (sesuai spesifikasi).

Selesai sampai di situ untuk penerapan TDD dalam pembangunan satu fitur. Bagaimana untuk fitur berikutnya? Ya, sama seperti langkah di atas, kita buat testing, jalankan testing, perbaiki error pada testing, jalankan testing lagi, perbaiki lagi, dan seterusnya…

Jadi dalam TDD, testing “memandu” kita dalam membangun fitur yang kita inginkan. Jika seluruh spesifikasi fitur itu sudah dituangkan dalam script testing, maka kita akan “dipaksa” untuk ngoding sampai target (spesifikasi) kita terpenuhi, yang ditandai dengan testing-nya passed atau lulus.

Merasa repot dengan metode ini? Ya, saat awal mencoba memang agak repot, karena kita belum terbiasa. Saya sendiri awalnya merasa testing ini menghabiskan banyak waktu, tapi karena “merasa perlu” ya jalan terus. Lama-kelamaan terbiasa dan lancar.

Jika kita menerapkan metode/langkah tersebut sejak awal development hingga selesai, maka hasil yang kita dapatkan adalah sebuah “aplikasi yang handal”. “Wow, pede banget? Ya donk..” kita menyelesaikan sebuah aplikasi/sistem yang berjalan sesuai keinginan (spesifikasi) dan itu dijamin dengan testing automation, teruji oleh komputer tanpa perlu pengujian manual oleh manusia.

TDD Mempercepat Pembangunan Aplikasi?

Pada artikel sebelumnya , saya menyebutkan bahwa metode TDD dapat mempercepat kerja kita dalam membangun sebuah aplikasi. Yap, ingin menegaskan kembali, pada penerapan TDD ini, dengan adanya testing yang “memandu”, kita tinggal ngoding untuk memperbaiki error yang tampil di software testing saja, sampai testing-nya passed. Selanjutnya kita bisa refactor script aplikasinya, atau langsung melanjutkan membangun fitur berikutnya dengan metode yang sama, begitu seterusnya.

Bahkan kadang kita “tidak mesti” membuka browser (aplikasi) untuk memastikan apakah coding yang kita kerjakan sudah “jalan” atau belum, karena sudah “yakin” dengan testing yang passed. Kita buka browser pada saat ingin memperbaiki tampilan atau tata letak nya saja.

Memangkas aktifitas yang “agak” menyita waktu

Jadi apa saja sih pekerjaan yang dipangkas dengan metode TDD ini? Kita memangkas aktifitas-aktifitas yang sedikit menyita waktu. Menurut pengalaman saya, yang agak ~~lumayan~~ menyita waktu adalah hal-hal berikut :

Setelah ngoding beberapa baris, kita buka browser untuk refresh halaman, atau submit form, lalu ngoding lagi, buka browser lagi, refresh, dan seterusnya.
Kita membuka browser untuk simulasi mengisi form lebih dari 5 item dan submit formulir.
Setelah selesai ngoding satu fitur, kita menguji “proses yang bertahap” di dalam sistem, misal :
- Setelah mengisi keranjang belanja kita, checkout mengisi data diri (sebagai Customer).
- Sebagai Reseller, setelah mengisi keranjang belanja kita, checkout mengisi data pengiriman.
Simulasi fitur-fitur lain yang berhubungan dengan fitur yang barusan selesai dibuat.

Jadi dengan adanya testing untuk masing-masing fitur itu, kita tidak perlu mengetes lagi secara manual. Yang penting testing sudah dibuat mengikuti spesifikasi yang diinginkan dan testing-nya passed.

Nah kesimpulannya, kenapa metode TDD dapat mempercepat kerja kita dalam membangun sebuah aplikasi? Karena simulasi-simulasi yang dilakukan secara manual dapat diminimalisir dengan adanya testing yang sudah passed. Sudah itu aja jawabannya. :)

Memudahkan modifikasi fitur

Bagaimana jika ditengah proses developement atau saat sistem sudah hampir selesai, kita diminta modifikasi sebuah fitur karena User “baru kepikiran”, nah lho, ini sering banget kejadian. Oke, dengan adanya automated testing, kita tinggal modifikasi testing script fitur sesuai yang diminta oleh User tadi, lalu jalankan testing (pasti ketemu error), perbaiki error-nya, testing lagi sampai ketemu testing passed untuk fitur itu, maka modifikasi fitur selesai.

Apakah setelah selesai modifikasi fitur tadi pekerjaan selesai? Belum! Kita mesti uji juga apakah fitur yang barusan diubah tadi tidak “merusak” atau menjadi bug fitur lainnya (biasanya karena kita modifikasi tabel di database). Jika memang fitur itu menjadi bug untuk fitur lain, maka testing akan segera memberitahu kita, sehingga dapat segera diperbaiki (menjadikan seluruh testing menjadi passed).

Kesimpulan TDD

Dengan menerapkan metode Test-Driven Development, beberapa manfaat yang didapatkan oleh developer:

Developer dipandu oleh testing dalam proses development.
Semua target spesifikasi harus dituangkan dalam script testing agar mendapatkan fitur yang sesuai keinginan.
TDD dapat mempercepat kerja karena meminimalisir simulasi manual oleh manusia.
Modifikasi sebuah fitur dapat dilakukan “dengan tenang” karena ada Automated Testing yang mem-backup kita.
Menambah percaya diri developer karena dapat membangun aplikasi yang handal teruji.

Semoga dengan membaca artikel ini teman-teman developer lebih mantap untuk memulai metode TDD dalam bekerja. Insyaallah pada artikel berikutnya kita mulai masuk ke praktek Testing Laravel, yaitu setup testing laravel yang biasa saya terapkan saat mulai project, dan memulai membuat testing script sebuah fitur.

Terima kasih atas waktunya.

Testing Laravel: Tentang Automated Testing

Wed, 26 Jul 2017 12:22:00 +0800

Melanjutkan dari artikel sebelumnya, kita sudah membahas bahwa Automated Testing itu penting untuk dipelajari dan diterapkan dalam pembangunan aplikasi. Kali ini kita akan membahas lebih lanjut tentang apa itu Automated Testing atau disebut juga Testing Automation.

Menerjemahkan pengertian dari Wikipedia, menurut pemahaman saya :

Automated Testing adalah sebuah metode pengujian software yang menggunakan suatu Software Testing (terpisah dari sistem/aplikasi yang sedang diuji), dengan tujuan untuk membandingkan antara “output yang diprediksikan” dengan “output yang dihasilkan” oleh sistem.

Jadi kita memanfaatkan sebuah software/framework testing sebagai pengganti manusia untuk menguji, apakah sistem/aplikasi yang kita buat sudah sesuai dengan spesifikasi yang ditentukan atau tidak.

Tahapan umum melakukan Automated Testing

Secara umum tahapan melakukan Automated Testing adalah sebagaimana berikut :

Memasang software testing pada sistem/aplikasi yang kita bangun.
Menulis “kode/script pengujian” pada software testing untuk menguji masing-masing fitur yang ada di sistem.
“Kode/script pengujian” yang ditulis pada software testing disesuaikan dengan kebutuhan/output yang diinginkan pada setiap fitur.
Menjalankan software testing untuk melihat apakah fitur yang ada pada sistem/aplikasi “lulus uji” oleh software testing atau tidak.
- Jika fitur yang diuji lulus, maka status hasil pengujian adalah passed atau “lulus”.
- Jika fitur yang diuji tidak lulus, maka si-software testing akan menampilkan pesan error yang didapatkannya dari sistem kita.

Catatan:
Untuk mempermudah penyebutannya, “Kode pengujian” ini kita sebut dengan testing script atau singkatnya testing saja.

Contoh kasus : Testing Fitur Ganti Password dengan PHPUnit dan Laravel

Misalkan di sistem kita, terdapat satu fitur untuk user mengganti password, di mana untuk menggunakan fitur tersebut user melakukannya dengan cara :

Meng-klik link Ganti Password
Mengisi Password yang lama
Mengisi Password yang baru
Mengisi Konfirmasi password
Klik Tombol Update Password
Password baru tersimpan dalam database
Tampil pesan “Password anda berhasil diubah.”

Nah, dengan Automated Testing kita melakukan simulasi proses/tahapan aktifitas tersebut dengan bantuan komputer (Software Testing). Dalam contoh kasus ini kita menggunakan sebuah software/framework testing bernama phpunit yang sudah tersedia dan terintegrasi dengan framework Laravel.

Dengan catatan bahwa fitur ganti password di dalam sudah bekerja sesuai cara di atas, berikut adalah contoh testing script-nya :

<?php

namespace Tests\Feature\Auth;

use App\User;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Tests\BrowserKitTestCase;

// Kelas penguji untuk tujuan pengelompokan
class UserChangePasswordTest extends BrowserKitTestCase
{
    use DatabaseMigrations;

    /** @test */
    public function user_can_change_password() // Kasus fitur yang diuji
    {
        // Kondisi/Permisalan
        // generate user
        $user = factory(User::class)->make(['username' => '123456']);
        $this->actingAs($user); // Login/Acting sebagai user

        // Action
        $this->visit(route('change-password')); // Kunjungi url /change-password
        $this->type('secret', 'old_password'); // Input form
        $this->type('member', 'password');
        $this->type('member', 'password_confirmation');
        $this->press(trans('auth.change_password')); // Tekan tombol

        // Asumsi hasil
        $this->see(trans('auth.old_password_success')); // Melihat pesan
        $this->seePageIs(route('change-password'));

        // Cek bahwa passsword sudah berubah (password sebelumnya : secret)
        $this->assertTrue(app('hash')->check('member', $user->password));
    }
}
?>

Sumber: “UserChangePasswordTest.php” pada repo di github dengan sedikit modifikasi.

Testing Lulus

Okey, untuk mecoba apaka testingnya berhasil, kita coba jalankan PHPUnit pada Laravel, dengan perintah berikut pada terminal :

$ vendor/bin/phpunit tests/Feature/Auth/UserChangePasswordTest.php

Dan hasilnya :

Sip, kita dapat hijau artinya “lulus tes”, berarti output yang diharapkan pada testing script yang kita buat ini sudah cocok dengan output yang dihasilkan oleh fitur Ganti Password pada sistem kita.

Testing Gagal

Bagaimana jika pengujian gagal? Misalkan setelah kita memodifikasi script yang terkait dengan fitur Ganti Password ini, maka PHPUnit akan menampilkan pesan error seperti contoh berikut :

Begitu menemukan seperti ini, kita langsung dapat mengetahui bahwa ada kesalahan di script aplikasi kita. Sehingga dapat segera memperbaiki tanpa harus diuji secara manual atau menunggu “laporan” dari User yang menggunakan sistem.

“Automated Testing” Menghemat Waktu

Jika kita lihat pada contoh di atas (Testing Lulus) pada bagian time: 193 ms, artinya satu pengujian/testing script tersebut hanya memakan waktu 193 mili detik. Jauh lebih cepat jika kita mengujinya dengan cara manual dengan cara : Buka Browser, lalu Login, lalu klik Ganti Password, dan seterusnya.. mungkin perlu waktu sekitar 5-10 detik.

Dalam hati mungkin kita bilang : “Ga masalah sih, waktu 5-10 detik itu ga lama kok”. Tapi perlu kita ingat, bahwa waktu 5-10 detik itu hanya untuk menguji satu fitur saja. Bayangkan kalau kita memiliki 20 fitur dengan formulir pengisian yang lebih banyak.

Jika kita hitung rata-rata 1 fitur kita perlu waktu 5 detik untuk menguji secara manual dan continue, maka untuk 20 fitur kita perlu waktu 100 detik (1 menit 40 detik). Dibandingkan dengan bantuan Automated Testing yang hanyar perlu waktu sekitar 4 detik (20 x ~200ms). Tentunya jauh lebih efektif, kan? Itu baru 20 Fitur, lho.. :)

Contoh Testing Keseluruhan

Ini adalah capture automated testing PHPUnit yang dijalankan pada aplikasi Grosir Obat di atas yang telah dibuat untuk semua fiturnya.

Bisa kita lihat, dalam waktu 2,7 detik, PHPUnit membantu men-simulasikan penggunaan fitur dengan hasil “Lulus”

Teman-teman bisa melihat dan mencoba testing script keseluruhan dari aplikasi tersebut di github pada direktori grosir-obat/tests/.

Konsep penulisan “Kode Pengujian”

Jika kita ingin membuat sebuah testing script untuk suatu fitur, bagaimana menulisnya? Konsep penulisan yang saya sering terapkan kurang lebih mengikut alur berikut :

Kita buat sebuah kasus yang ingin kita uji.
Tuliskan testing script untuk menentukan kondisi, action dan asumsi dengan urutan :
1. Kondisi atau permisalan
2. Action yang dilakukan
3. Asumsi hasil yang diinginkan
Pastikan testing script tadi sudah sesuai dengan tugas atau langkah kerja fitur yang kita ujikan.
Jalankan software testing / (PHPUnit) untuk melihat hasilnya.
Jika pada kasus pengujian ini lulus tes, maka fitur tersebut cocok dengan asumsi hasil yang diinginkan oleh “kode pengujiannya”
Jika pada kasus pengujian ini tidak lulus, berarti ada yang salah, baik di sisi kode pengujian atau dari sisi fiturnya

Untuk mempermudah pemahaman, kita coba analogikan konsep penulisannya mirip seperti konsep yang diajarkan oleh guru kita sejak SD, ketika kita menjawab soal tugas atau ujian (imho).

Masih ingat dengan kata kunci ini: Pertanyaan, Diketahui, Ditanya, dan Jawab?

Pasti sebagian besar sudah pernah menerapkan konsep ini untuk menjawab soal, kan?

Contoh :

Pertanyaan :
    Hitunglah luas persegi panjang dengan panjang 5 meter dan lebar 3 meter.

Diketahui : 
    p = 5 meter
    l = 3 meter

Ditanya : Luas persegi panjang (L)

Jawab : 
    L = p x l
      = 5 x 3
      = 15
    Maka luas persegi panjang = 15 meter persegi

Nah, pada konsep penulisan testing script kita juga memiliki 4 kata kunci:
Fitur yang ingin diuji, Kondisi/Permisalan, Action atau ketika script dieksekusi, dan Asumsi hasil yang diinginkan.

Jadi :

Fitur yang ingin diuji setara dengan Pertanyaan
Kondisi/Permisalan setara dengan Diketahui
Action setara dengan Ditanyakan
Asumsi Hasil setara dengan Jawab

Dengan mengingat konsep ini, harapannya kita akan lebih mudah dalam menulis testing script.

Pada beberapa artikel kedepan, kita akan menerapkan konsep tersebut untuk mulai membangun “kode pengujian” atau testing script kita.

Nah, bagaimana jika kita ingin menerapkan Test-Driven Development (TDD)? Yaitu membuat testing script terlebih dahulu sebelum mulai menulis kode untuk membangun sistem? Kita akan bahas pada artikel Tentang TDD.

Terima kasih teman-teman sudah berkenan membaca.

Testing Laravel: Latar Belakang

Thu, 20 Jul 2017 21:15:00 +0800

Pada artikel ini dan beberapa artikel kedepan, saya ingin berbagi cerita tentang pengalaman saya menggunakan metode Test-Driven Development (TDD), cara memulai, apa saja yang perlu di-test, dan studi kasus yang ringan. Mudah-mudahan dapat membantu teman-teman yang ingin menerapkan TDD dalam pekerjaannya.

Sebelum memulai membahas Testing Laravel, ijinkan saya menceritakan latar belakang mengapa “Testing itu Penting?”, menurut pengalaman saya selama beberapa tahun terakhir.

Problem yang dihadapi oleh Developer

Seorang developer (terutama freelancer) kadang mengalami perasaan “takut” saat diminta melakukan improvement pada aplikasi buatannya sendiri, terutama jika sudah berjalan di server production dan sedang digunakan oleh user. Misal kita diminta menambah fitur baru atau mengubah fitur yang sudah berjalan.

Kenapa kok takut, padahal aplikasi itu kan buatan kita sendiri? Satu alasan terlintas di pikiran adalah karena kita cenderung sudah lupa dengan “coding” kita sendiri. Apalagi jika bekerja sebagai freelancer, umumnya setelah selesai mengerjakan satu project, kita langsung mencari, mengambil pekerjaan/project lain, dan fokus pada project selanjutnya.

Bener nggak?

Contoh Kasus

Satu waktu kita menyelesaikan sebuah project aplikasi untuk sebuah perusahaan. Selanjutnya sistem itu digunakan sekaligus (tahap) pengujian oleh user/klien selama 1-2 bulan, untuk memastikan semua fitur berjalan sesuai dengan target dan tujuan. Setelah masa pengujian selesai dan semua fitur sudah Oke (mungkin setelah beberapa bugfix), aplikasi digunakan oleh perusahaan secara penuh. Selesai pekerjaan sampai di situ.

Enam bulan kemudian, perusahaan tersebut menghubungi kita lagi untuk meminta improvement di sistemnya. Setelah berdiskusi, ada beberapa fitur yang ingin ditambahkan ke sistem, dan ternyata ada beberapa fitur yang diubah karena adanya perubahan kebijakan perusahaan.

Apa yang harus kita lakukan untuk memenuhi permintaan tersebut, dengan catatan, sistem yang sudah ada sekarang tetap digunakan paralel dengan proses improvement?

Potensi “Bug setelah Improvement”

Menurut pengalaman, kondisi ini bisa membuat kita (terutama saya) takut untuk menambah/mengubah fitur pada aplikasi buatan sendiri, karena :

Harus mengubah stuktur tabel yang saat ini sudah berjalan dengan aman.
Ada potensi bug yang muncul akibat perubahan struktur database.
Ada potensi bug yang muncul akibat penambahan/perubahan script fitur yang dilakukan.
Kita sudah lupa dengan workflow yang diterapkan saat membuatnya, sementara project yang kita kerjakan setelahnya menggunakan workflow baru.
Proses migrasi data yang sudah ada (existing) ke sistem yang baru (setelah ditambah fitur).

Dengan beberapa alasan tersebut, bisa jadi kita akan ragu untuk mengerjakan improvement yang diminta, karena memikirkan impact/akibatnya, misalkan :

Komplain yang tidak terduga dari user beberapa minggu setelah improvement selesai.
Misal ada laporan: “Mas kemarin yang ini perhitungannya bener, kok sekarang salah?”.
Kadang waktu yang diperlukan untuk perbaikan impact bisa lebih banyak daripada waktu pengerjaan improvement.
Misal: kita sudah perbaiki bug yang dilaporkan, tetapi perbaikan tadi menjadi bug lagi pada fitur lain, yang sebelumnya baik-baik saja, seterusnya sampai tidak ada laporan bug lagi.
(Saat mengerjakan improvement) Fokus pekerjaan terbagi antara mengerjakan fitur baru dengan rasa takut komplain yang akan datang belakangan.

Bagi sebagian orang mungkin ini hal yang biasa, karena ini adalah “resiko” dari proses improvement sebuah sistem dan ini harus dipahami oleh user/klien (pengguna aplikasi). Tapi bagi saya pribadi, potensi impact ini lumayan mengganggu, karena kita harus tetap bertanggung jawab atas kelalaian kita sendiri pada saat pengerjaan improvement itu. Bayangkan waktu dan pikiran yang dihabiskan untuk perbaikannya, padahal di saat yang sama kita sedang mengerjakan project yang lain.

Apa lagi setelah bug diperbaiki, muncul bug lain lagi.

Mumet, kan? Mumet.

Tapi kan bagaimanapun kita mesti maju, tidak bisa bilang kepada klien bahwa kita takut memenuhi permintaan itu. Orang aplikasinya juga kita yang bikin. Ntar malu kita..

Nah? jadi curcol..

Oke, anggap saja improvement kita sanggupi dan sudah kita kerjakan.

SOLUSI tradisional untuk Potensi “Bug setelah Improvement”

Setelah pekerjaan improvement selesai, mestinya kita melakukan pengujian untuk memastikan aplikasi berjalan dengan baik tanpa ada bug, bukan?

Pengujian dilakukan oleh Developer

Bayangkan misal aplikasi ini memiliki 10 fitur utama, dan masing-masing fitur utama memiliki 4-5 sub-fitur, sehingga ditotal sekitar 50 fitur. Apakah setelah melakukan improvement tadi, kita menguji semua fitur secara manual?

Misal dengan cara :

Buka browser dan Login
Input form satu-satu
Input form dengan kondisi input yang salah
Cek hasil input form di aplikasi atau di database

Satu persatu fitur sampai dirasa cukup.

Jika aplikasi tidak terlalu besar, proses pengujian manual ini tidak masalah. Tapi untuk kasus ini, proses di atas kita lakukan setidaknya untuk 10 fitur utamanya. Atau hanya fitur-fitur lama yang berkaitan dengan fitur baru (yang dibuat setelah improvement).

Idealnya memang semua fitur harus diuji, tapi apakah seorang programmer akan “se-rajin” itu? Silakan jawab sendiri :D

Bayangkan, berapa banyak waktu yang kita habiskan untuk memastikan semua fitur berjalan lancar setelah improvement selesai? Kalau aplikasi tidak terlalu kompleks, mungkin 1 hari selesai pengujian. Tetapi jika aplikasi lumayan kompleks dengan fitur-fitur yang saling berhubungan satu sama lain? Mungkin perlu 2 hari, seminggu, atau “kalau rajin” bisa 2 minggu. Padahal pengerjaan improvement nya hanya 1 atau 2 hari saja sudah beres.

Membiarkan user komplain?

Alternatifnya jika kita tidak mau repot, kita biarkan user yang mencoba sendiri, ketika ada masalah biarkan melapor, kemudian bug diperbaiki. Begitu seterusnya sampai tidak ada laporan lagi.

Cara ini resikonya cukup besar, bisa membuat hubungan kita dengan klien menjadi renggang gara-gara keseringan adu argumen soal bug. Bisa membuat image kita ~~jelek~~ kurang bagus di mata klien. Dan menurut saya, cara kerja ini sangat tidak efektif dan menghabiskan waktu.

Ditambah lagi (jika) setelah improvement ini kita langsung ke project berikutnya, kondisi seperti ini berpotensi membuat kita dikejar deadline. Karena bisa jadi kita tidak fokus mana yang mau diprioritaskan di antara :

Bugfix,
Pikiran kekhawatiran bug berikutnya, dan
Project yang sedang berjalan.

Jika Aplikasi punya “Automated Testing”?

Dengan contoh kasus di atas, saya pertimbangan untuk memulai belajar Automated Testing. Kenapa? Karena saya pikir, dengan aplikasi yang memiliki Automated Testing, kita (sebagai developernya) memiliki backup yang dapat membantu kita memastikan bahwa aplikasi ini sudah teruji secara otomatis dengan bantuan komputer.

Dibandingkan jika kita harus menguji sistem secara manual, dengan adanya Automated Testing (selanjutnya kita sebut testing) yang dipasang pada aplikasi buatan kita, ke 50 fitur tadi diuji oleh komputer dengan waktu yang cepat. Bayangkan betapa hematnya waktu kita ketika pengujian (misal) 50 Fitur cukup perlu waktu 30 detik.

Jadi jika ada bug yang disebabkan oleh improvement tadi? Testing segera memberitahu kita dengan cara menampilkan error yang terjadi. Baik karena script yang salah, atau struktur database yang ada tidak sesuai dengan script yang baru.

Yap, dalam waktu sekian detik, bug yang disebabkan oleh improvement tadi segera ketahuan. Walhasil, saat itu juga kita dapat segera memperbaikinya, tanpa menunggu laporan dari user yang bikin kita mumet kita di kemudian hari.

Kita akan membahas tentang Automated Testing pada artikel berikutnya.

Kesimpulan Latar Belakang “Kenapa Testing itu Penting?”

Oke, kita simpulkan materi latar belakang pentingnya testing dalam pengembangan sebuah sistem/aplikasi :

Sebagai backup kita jika ada improvement sistem di kemudian hari
Sebagai jaminan bahwa aplikasi yang berjalan sudah sesuai dengan spesifikasi yang diinginkan
Membantu mempercepat informasi bug akibat perubahan yang dilakukan
Membuat kerja, pikiran, dan hidup lebih tenang :D

Demikian ulasan tentang latar belakang mengapa saya mempertimbangkan untuk belajar Automated Testing. Saya berharap teman-teman merasa :
“Oh, iya, setuju, ternyata automated testing itu besar sekali manfaatnya.”

Mudah-mudahan artikel ini dapat menjadi referensi untuk memantapkan niat teman-teman yang ingin belajar dan membuat testing dalam membangun aplikasi. Pada artikel selanjutnya, kita akan membahas lebih lanjut tentang Automated Testing.

Terima kasih teman-teman sudah berkanan membaca.

Membuat Log Viewer Laravel

Tue, 18 Jul 2017 18:11:00 +0800

Kita sering mengalami kesulitan untuk melihat error log aplikasi Laravel ketika aplikasi sudah di deploy ke production server, baik di VPS ataupun di Shared Hosting. Terutama pada saat ada laporan dari user misalkan :
“Mas, ada error ketika membuka halaman ini.” atau “Ada bug nih waktu submit form ini tetapi ininya ga diisi.”

Biasanya hal-hal seperti ini baru kita temukan pada saat aplikasi sudah digunakan oleh usernya (waktu kita bikin sih rasanya baik-baik aja, hehe).

Nah pada saat dapat laporan itu, biasanya saya login ke VPS atau cPanel Shared Hosting, lalu mengecek error log web server dan log di laravel yang ada di direktori storage/logs. Dan menelusuri file log untuk menemukan problem yang dimaksud.

Sebenarnya bagi sebagian orang ini ga terlalu merepotkan sih, tetapi bagi saya ini lumayan repot karena harus melihat catatan akun login VPS atau cPanel nya.

Lalu untuk meminimalisir ini, di aplikasi laravel, kita akan coba buat sebuah halaman untuk :

Menampilkan daftar file log Laravel perhari
Melihat isi file log
Men-download file log (Save As)

Nanti tampilannya lebih kurang seperti ini:

Tahap Pengerjaan

Membuat Route dan Controller untuk menampilkan daftar Log
Membuat View list File Log
Membuat Route dan controller untuk menampilkan Isi File Log
Membuat Route dan controller untuk download File Log
Mengatur Config untuk Log Harian

Oke, kita langsung buat sama-sama.

1. Route dan Controller untuk List File Log

Kita buat Route log-files pada file routes/web.php

<?php
// routes/web.php

Route::get('log-files', [
    'as' => 'log-files.index',
    'uses' => 'LogFilesController@index'
]);

Kemudian buat Controller dengan nama LogFilesController dan method index untuk membaca isi direktori storage/logs.

<?php
// app/Http/Controllers/LogFilesController.php

namespace App\Http\Controllers;

class LogFilesController extends Controller
{
    public function index()
    {
        if (!file_exists(storage_path('logs'))) {
            return [];
        }

        $logFiles = \File::allFiles(storage_path('logs'));

        // Sort files by modified time DESC
        usort($logFiles, function ($a, $b) {
            return -1 * strcmp($a->getMTime(), $b->getMTime());
        });

        return view('log-files', compact('logFiles'));
    }
}

2. View untuk List File Log

Sesuai dengan Controller diatas, kita buat view dengan nama log-files.blade.php pada direktori resources/views

3. Route dan controller Method untuk Melihat Isi File

Kita buat Route log-files/{filename} pada file routes/web.php

<?php
// routes/web.php

// Route List File
Route::get('log-files', [
    'as' => 'log-files.index', 
    'uses' => 'LogFilesController@index'
]);

// Route melihat isi File
Route::get('log-files/{filename}', [
    'as' => 'log-files.show', 
    'uses' => 'LogFilesController@show'
]);

Kita lanjutkan LogFilesController dengan script berikut :

<?php
// app/Http/Controllers/LogFilesController.php

namespace App\Http\Controllers;

class LogFilesController extends Controller
{
    // index method..

    public function show($fileName)
    {
        if (file_exists(storage_path('logs/'.$fileName))) {
            $path = storage_path('logs/'.$fileName);

            return response()->file($path, ['content-type' => 'text/plain']);
        }

        return 'Invalid file name.';
    }
}

4. Route dan controller Method untuk Download File

Untuk download filenya sebenarnya tidak terlalu penting, yang penting kita bisa lihat filenya langsung dari aplikasi.

Tapi siapa tau diperlukan, kita buat saja. Route log-files/{filename}/download pada file routes/web.php

<?php
// routes/web.php

// Route List File
Route::get('log-files', [
    'as' => 'log-files.index', 
    'uses' => 'LogFilesController@index'
]);

// Route melihat isi File
Route::get('log-files/{filename}', [
    'as' => 'log-files.show', 
    'uses' => 'LogFilesController@show'
]);

// Route Download File
Route::get('log-files/{filename}/download', [
    'as' => 'log-files.download', 
    'uses' => 'LogFilesController@download'
]);

Oke kita buatkan method untuk actionnya di LogFilesController :

<?php
// app/Http/Controllers/LogFilesController.php

namespace App\Http\Controllers;

class LogFilesController extends Controller
{
    // index method..
    
    // show method..

    public function download($fileName)
    {
        if (file_exists(storage_path('logs/'.$fileName))) {
            $path = storage_path('logs/'.$fileName);
            $downloadFileName = env('APP_ENV').'.'.$fileName;

            return response()->download($path, $downloadFileName);
        }

        return 'Invalid file name.';
    }
}

5. Mengatur Config untuk Log Harian

Oke setelah langkah di atas, seharusnya jika kita mengakses route /log-files kita akan mendapatkan tampilan seperti berikut:

Dengan kondisi ini, kita akan repot melihat log karena log digabung dalam 1 file default bernama storage/logs/laravel.log

Untuk mempermudah troubleshoot kita atur konfigurasi log agar file log dibuat per hari. Caranya seperti ini:

Buka file config/app.php, kemudian pada bagian log ganti dengan config seperti ini :

<?php
// config/app.php

    // sekitar baris ke 123
    // 'log' => env('APP_LOG', 'single'),

    // Ganti log menjadi per hari
    'log' => 'daily',

    // Agar jumlah maksimum log untuk 30 hari
    'log_max_files' => 30,

    'log_level' => env('APP_LOG_LEVEL', 'debug'),

Setelah langkah di atas, seharusnya jika kita mengakses route /log-files kita akan mendapatkan tampilan seperti berikut :

Oke, sampai di sini tutorial pembuatan Laravel Log Viewer, mudah-mudahan dapat membantu teman-teman yang punya kesulitan yang serupa dengan saya.

Contoh implementasi untuk Log Viewer ini sudah diterapkan pada aplikasi Grosir Obat yang saya buat. Bisa teman-teman lihat di commit ini

Terima kasih untuk waktunya.

Struktur Direktori Composer

Sat, 15 Apr 2017 17:22:00 +0800

Setelah minggu lalu kita membahas tentang perintah-perintah umum yang digunakan dalam Composer, kali ini kita akan bahas tentang struktur direktori project yang menggunakan Composer sebagai alat bantunya.

Dalam sebuah project yang menggunakan Composer, akan ada direktori dan file-file berikut :

Baik, kita bahas satu persatu sesuai yang saya pahami.

1. Direktori “vendor”

Sebagaimana yang telah kita singgung sebelumnya, direktori ini adalah tempat Composer meletakkan paket-paket yang telah diinstall/di-download-nya untuk project/aplikasi kita. Didalamnya terdapat:

File autoload.php (ini akan kita bahas berikutnya)
Direktori composer Saya tidak tahu persis isi dan fungsi dari direktori ini, tetapi sepertinya dari sini lah Composer mengatur agar kelas-kelas yang ada pada setiap paket dapat di akses sesuai dengan ”namespace”-nya. Karena secara umum paket-paket yang ada di Composer/packagist dibuat dalam basis object (OOP).
Direktori-direktori lainnya yang merupakan direktori paket dependensi yang telah diinstall oleh Composer.

Nah, pada direktori-direktori ini, Composer mengatur susunan paket berdasarkan nama vendornya. Kita ambil contoh saat kita memberikan perintah

$ composer require nesbot/carbon 1.20.0

maka struktur direktori kita akan seperti gambar ini :

Kita fokus ke direktori "nesbot" dan "symfony" :

Direktori "nesbot" berisi direktori "carbon" yang berisi source code dari paket carbon sesuai yang ada di githubnya.
Kemudian direktori "symfony" berisi direktori "polyfill-mbstring" dan direktori "translation" di mana masing-masing berisi source code paket nya.

Ini sesuai dengan nama paketnya masing-masing yang telah terinstall pada contoh perintah composer require kita sebelumnya.

Kalau kita menggunakan perintah create-project kan paket yang di-download juga banyak ya, otomatis isi direktori vendor juga akan banyak.

Nah, jadi pada direktori “vendor” ini lah depedency kita “menginap”. Semakin banyak dependency di-download oleh Composer, maka semakin besar juga ukuran direktori ini. Direktori “vendor” ini wajib kita ikutkan kemana-mana pada saat aplikasi kita gunakan. Karena sesuai dengan yang kita bahas di sesi pertama “judulnya : perlu atau harus ada”.

Ada pertanyaan : “berarti kalau pakai Composer dan direktori vendor harus dibawa, aplikasi jadi besar dan berat donk?”
Jawabnya : “jadi besar? Iya. Jadi berat? Tidak”
“Kok tidak berat? Kan file yang dibawa banyak?”

“Karena Composer cukup pintar meng-efisien kan penggunaan autoload-nya agar kelas-kelas paket yang di-load oleh aplikasi, hanya kelas-kelas yang dibutuhkan saja.”

Saya belum tau persis cara kerjanya, tapi inilah jawaban yang saya simpulkan dari membaca beberapa referensi.

Composer membuat semacam classmap (peta kelas) untuk meng-efisien-kan penggunaan autoload-nya. Jadi file dan kelas paket hanya di-load ketika kelasnya dipanggil saja.

Contoh kasus : kita menggunakan paket shopping cart dan paket terbilang:

Kelas-kelas paket shopping cart akan diakses pada saat fitur shopping cart digunakan (misal halaman katalog dan halaman produk) dan tidak digunakan pada saat kita berada di halaman pengelolaan order.
kelas terbilang hanya akan digunakan pada saat fungsi/fitur terbilang digunakan/dipanggil, misal pada halaman Invoice Order. pada halaman lain kelas terbilang tidak akan di-load.

Mohon koreksi bila saya keliru paham tentang autoload ini.

Nah, bicara tentang autoload kelas, bagaimana caranya agar aplikasi yang kita buat dapat membaca dan mengenali kelas-kelas yang ada di masing-masing paket yang di download via Composer tadi? Kita langsung bahas file autoload.php di dalam direktori “vendor”

2. File “vendor/autoload.php”

File ini adalah file yang menghubungkan antara aplikasi kita dengan kelas-kelas yang di-download oleh Composer. File ini yang kita “require” ke dalam aplikasi php kita. Contohnya seperti gambar ini:

Jadi setelah file autoload.php ini kita require ke dalam aplikasi kita, maka kelas-kelas yang ada di direktori “vendor” dapat kita panggil berdasarkan “namespace”-nya.

Dari tadi saya sebut-sebut soal “namespace”, namespace itu apa sih? Hmm penjelasannya panjang teman-teman, saya juga belum benar-benar paham.

Intinya namespace itu untuk :

Kita memanggil nama kelas yang sesuai fungsi paket yang kita panggil.
Memastikan tidak konflik (dan pesan error) di aplikasi php kita akibat ada nama kelas (class) yang sama.

Artikel ini menjelaskan tentang namespace dengan “renyah”, mudah dicerna :)
http://id-laravel.com/post/mengenal-namespace-menjelajah-milyaran-galaksi, silakan kunjungi kalau ingin tahu tentang “namespace”.

Oke, kita simpulkan bahwa:

direktori “vendor” tempat Composer meletakkan paket-paket depedency di aplikasi kita.
file autoload.php di direktori “vendor” adalah “pintu gerbang” komunikasi antara aplikasi kita dengan paket-paket yang ada di dalam direktori “vendor”.

3. File “composer.json”

Baik kita lanjukan ke file composer.json File composer.json, adalah file yang dibuat oleh kita, atau oleh Composer untuk mencatat daftar paket yang “kita perlukan” untuk membuat project/aplikasi ini. Jadi pada file ini kita mencatat/menulis untuk menambahkan atau mengurangi paket yang menjadi dependency aplikasi kita. File composer.json yang terbentuk dari perintah composer require dengan composer create-project berbeda.

Sebagai contoh kita gunakan paket nesbot/carbon:

$ composer require nesbot/carbon 1.20.0

akan menghasilkan file composer.json seperti berikut ini :

Sedangkan pada perintah :

$ composer create-project nesbot/carbon project-saya 1.20.0

akan menghasilkan file composer.json persis seperti source codenya di github (sesuai versi yang kita pilih) :
https://github.com/briannesbitt/Carbon/blob/1.20.0/composer.json

4. File “composer.lock”

File composer.lock, adalah file yang dibuat oleh Composer untuk menyimpan detail paket-paket yang “telah” di-download ke dalam project/aplikasi kita. Untuk perintah :

$ composer require nesbot/carbon 1.20.0

kita akan dapatkan file composer.lock seperti berikut ini

https://gist.github.com/nafiesl/fc2ea0aa3acbcb0f41b2da3cfa01f20e

Kita lihat isi filenya, kita lihat pada :

baris ke 10 merupakan nama dan versi paket “nesbot/carbon”,
baris ke 57 merupakan nama dan versi paket “symfony/polyfill-mbsring”, dan
baris ke 116 merupakan nama dan versi paket “symfony/translation”. Nah, dari isi file composer.lock inilah perintah composer install tanpa ba.. bi.. bu.. lagi akan langsung menginstall paket yang dibutuhkan.

Perintah-perintah Composer: update

Tue, 04 Apr 2017 16:57:00 +0800

Kali ini kita akan bahas tentang perintah “composer update”.

composer update

Perintah ini kita gunakan untuk salahs salah satu antara dua fungsi:

meng-”update” versi seluruh paket dependency di sebuah project/aplikasi mengacu pada file composer.json
meng-install seluruh paket dependency jika belum ada folder “vendor” mengacu pada file composer.json

Perintah :
composer update

Makna perintah :
“Composer, tolong update semua (versi) paket dependency untuk project ini sesuai dengan file composer.json saya.”

Secara umum perintah composer update dan composer install melakukan hal yang sama, tetapi ada sedikit perbedaan diantara keduanya. Apa perbedaan?

Berikut perbedaan yang saya ketahui :

Composer update

Tidak mengacu pada/memperdulikan composer.lock, hanya ke composer.json
Proses cenderung lebih lambat karena akan mengecek update versi paket ke packagist terlebih dahulu
Dapat bekerja (meng-”update) walaupun folder “vendor” sudah ada dengan berisi paket lengkap
jika Composer melihat di packagist ada versi terbaru dari paket yang sudah terinstall, maka Composer akan meng-update paket ke versi terbarunya.

Composer install

Mengacu pada composer.lock atau ke composer.json
Proses cenderung lebih cepat karena mengdownload paket sesuai file composer.lock
Dapat bekerja (meng-install) dengan kondisi folder “vendor” tidak ada, atau paket didalamnya tidak lengkap
Jika sudah ada file composer.lock, Composer tidak mengecek versi baru, tetapi langsung menginstall sesuai versi paket yang ada pada file composer.lock

Baik itu tadi perbedaan antara perintah install dengan perintah update

Perintah-perintah Composer: install

Mon, 03 Apr 2017 14:13:00 +0800

Pada materi-materi sebelumnya perihal perintah Composer, kita sudah membahas : require dan create-project, kali ini kita akan bahas tentang perintah “composer install”.

composer install

Perintah ini digunakan untuk menginstall seluruh paket dependency dari sebuah project/aplikasi mengacu pada file composer.lock atau composer.json.

Sedikit gambaran :
File composer.lock, adalah file yang dibuat oleh Composer untuk menyimpan detail paket-paket yang “telah” didownload oleh Composer di project/aplikasi ini.

File composer.json, adalah file yang dibuat oleh kita, atau oleh Composer untuk mencatat daftar paket yang “kita perlukan” untuk membuat project/aplikasi ini.

Kita akan bahas lebih lanjut tentang kedua file ini kemudian.

Perintahnya adalah :
composer install

Makna perintah :
“Composer, tolong install semua dependency yang saya butuhkan untuk project ini berdasarkan file composer.lock atau composer.json.”

Proses yang dilakukan oleh perintah ini adalah :

Composer mengecek apakah ada file composer.lock
Jika ada file composer.lock, Composer akan segera menginstall seluruh paket yang terdaftar pada file tersebut.
Jika tidak ada file composer.lock, maka Composer akan melihat daftar paket pada file composer.json
Composer mengecek kembali seluruh dependency dari paket yang ada pada file composer.json.
Jika tidak ada masalah dengan spesifikasi PHP kita, maka Composer akan menginstall seluruh paket dengan dependency-nya.
Seluruh paket yang terinstall akan menghuni direktori “vendor”.

Nah kapan kita menggunakan perintah composer install?

Ada beberapa syarat atau kondisi dimana perintah composer install dapat bekerja:

Tidak ada direktori “vendor” (pada direktori yang sedang digunakan)
Salah satu (direktori) paket di dalam direktori “vendor” terhapus/hilang/belum ada
terdapat file composer.lock (opsional)
terdapat file composer.json (wajib ada)

Salah satu keuntungan menggunakan Composer dengan perintah composer install adalah yang nomor 2, Composer dengan “pintar” memeriksa keberadaan paket yang “seharusnya ada” di dalam project kita.

Karena sekali lagi, pekerjaannya Composer adalah me-manage dependency paket-paket dari packagist yang digunakan dalam project kita.

Nah jadi seperti itu penggunaan perintah composer install. Kesimpulannya, perintah composer install akan bekerja jika :

Ada file composer.json dan dependency kita daftarkan dengan benar
Ada file composer.lock
Folder “vendor” belum ada
Atau direktori “vendor” ada, tetapi direktori paket di dalamnya tidak lengkap/hilang/terhapus.

Perintah-perintah Composer: create-project

Sun, 02 Apr 2017 11:57:00 +0800

Pada materi sebelumnya kita sudah bahas perintah Composer, yaitu : require, kali ini kita akan bahas tentang perintah “composer create-project”.

composer create-project

Perintah ini digunakan untuk membuat sebuah project baru dengan menggunakan source code paket yang kita panggil.

Jadi struktur perintahnya:
composer create-project “nama-paket” “nama-folder” “versi-paket”

Contoh perintah :
composer create-project nesbot/carbon project-saya 1.20.0

Makna perintah :
“Composer, tolong buatkan saya project baru dalam folder project-saya dengan menggunakan source code dari paket nesbot/carbon versi 1.20.0”

Pada dasarnya pada perintah ini, Composer melakukan clone source code dari repository paket yang bersangkutan (dari github), dan meng-install seluruh dependensi dari paket tersebut. Sebagai contoh kita ingin membuat project menggunakan source code dari paket nesbot/carbon.

Jika perintah tersebut dieksekusi, maka akan tampil proses seperti gambar ini:

Nah dari gambar tersebut kita lihat perbedaan yang signifikan antara perintah require dengan create-project. Ternyata dependency paket yang di-download oleh Composer lebih banyak.

Pada perintah ini:

Composer membuat sebuah folder project-saya
Composer meng-install/men-download source code paket nesbot/carbon ke dalam folder project-saya
Composer men-download seluruh dependency dari paket
Composer juga men-download seluruh dependency dari paket yang digunakan saat source code ini dibuat, dalam kasus ini adalah paket “phpunit/phpunit”.

Jika kita tengok di halaman packagist, bisa di lihat pada bagian require-dev di sana kelihatan paket phpunit/phpunit yang menjadi dependency untuk kebutuhan development paket nesbot/carbon

hmm… oke, Jadi dari sini kita bisa melihat bahwa perintah create-project berguna jika kita ingin menggunakan source code paket sebagai starting point dari project yang akan kita garap. Umumnya perintah create-project ini kita gunakan untuk membuat project dari sebuah framework. Misalkan : symfony, codeigniter, laravel, dan slim.

Perintah-perintah Composer: require

Sat, 01 Apr 2017 11:57:00 +0800

Pada materi ini (dan beberapa materi berikutnya) kita akan bahas perintah-perintah umum yang sering digunakan pada composer, yaitu :

require
create-project
install, dan
update

Perintah-perintah pada Composer dapat kita lakukan melalui terminal (pada linux dan mac) atau command prompt atau powershell (pada windows).

composer create-project

Perintah ini kita gunakan untuk menambahkan sebuah paket ke dalam project kita, dan menjadikan paket tersebut sebagai dependensi dari project kita.

Struktur perintahnya :
composer require nama-paket versi

Contoh perintahnya :

$ composer require nesbot/carbon 1.20.0

Makna perintah :
“Composer, saya memerlukan paket nesbot/carbon versi 1.20.0 dalam project saya.”

Di sini kita ambil contoh sebuah paket bernama “nesbot/carbon”. Sebagai info, paket ini adalah paket ekstensi atau turunan dari kelas DateTime pada PHP. Paket ini dapat membantu kita dalam mengoperasikan tanggal dan waktu untuk dalam aplikasi PHP.

Teman-teman dapat melihat manfaat dan dokumentasi paket ini:
Dokumentasi http://carbon.nesbot.com/docs
Source code https://github.com/briannesbitt/Carbon
Packagist https://packagist.org/packages/nesbot/carbon

Sebelum kembali bahas composer require, sedikit gambaran tentang sebuah paket atau library pada Composer/Packagist.
Setiap nama paket memiliki format nama-vendor/nama-paket, kalau diibaratkan sebuah buku, formatnya serupa pengarang/nama-buku

Nah, jadi pada paket yang barusan kita gunakan nesbot/carbon, nesbot adalah nama atau alias si pembuat atau vendornya, sedangkan carbon adalah nama paketnya.

Ok kembali bahas perintah composer require. Jadi kalau kita jalankan, maka tampilannya akan seperti ini:

Tahap prosesnya kira-kira seperti ini:

Ketika kita mengetikkan composer require nesbot/carbon 1.20.0 dan tekan enter,
- Composer membuat file composer.json
- Composer membaca detail paket yang bersangkutan pada packagist dan melihat dependecy paket tersebut
- pada tahap ini, Composer juga membaca spesifikasi PHP pada PC kita
Composer menginstall/men-download paket-paket dependency
- paket-paket dependecy akan di-download terlebih dahulu
- paket yang kita “require” akan di-download setelah dependecynya selesai di-download
Composer membuat file composer.lock dan file-file autoload.php yang akan me-load kelas-kelas yang ada di seluruh paket.

Bisa kita lihat pada gambar tersebut, untuk menginstall paket nesbot/carbon ternyata ada dua paket lain yang di-download oleh Composer.

Mengapa ada dua paket tambahan? Dari mana asalnya kedua paket tersebut?

Kalau kita lihat di https://packagist.org/packages/nesbot/carbon, ternyata dia memiliki 1 dependensi paket, yaitu symfony/translation

Lalu satu paket lagi dari mana? oke kita lihat di packagist symfony/translation, paket ini memiliki satu dependency paket lain, yaitu symfony/polyfill-mbstring

Oke, kita coba lihat lagi apakah paket symfony/polyfill-mbstring punya dependency lagi? kita lihat di packagist symfony/translation

Pada gambar di atas symfony/polyfill-mbstring tidak memiliki dependency ke paket lain.

Nah, ini rupanya cocok dengan pembahasan kita pada artikel perkenalan Composer, di mana sebuah paket bisa memiliki dependency, dan dependency-nya juga punya dependency. Begitu seterusnya.

Oke sampai disini kita mengerti dua hal:

Perintah composer require, kita meminta Composer untuk menginstall/men-download sebuah paket agar menjadi dependency project/aplikasi kita.
Sesuai dengan analogi yang kita pahami bersama pada materi pada perkenalan dengan Composer, bahwa Composer terbukti memang benar “Dependency Manager” sehingga untuk dapat menggunakan satu paket/library, kita tidak perlu repot-repot men-download paket dan depedencynya secara manual.

Dan sedikit kita mengingat materi pada cara kerja Composer, bahwa :

Seluruh paket yang diinstall oleh Composer akan “menghuni” folder bernama “vendor”

Ya, semua paket yang di-download oleh Composer akan diletakkan dalam folder “vendor”, kita akan bahas tentang folder vendor pada artikel lainnya.

Selanjutnya kita akan membahas tentang perintah berikutnya, yaitu composer create-project.

Mapping Subdomain ke VPS

Tue, 21 Mar 2017 14:10:00 +0800

Pada artikel ini kita akan melakukan mapping agar subdomain dari sebuah website (dengan shared hosting) dapat digunakan pada server terpisah (dalam hal ini VPS).

Kondisi

Nameserver Domain utama (misal: nafies.id) sudah diset ke hosting utama (shared hosting dengan cpanel).
Domain utama telah online (optional).
VPS telah dibuat dengan sebuah IP Address (misal: 45.32.113.217)
Web server pada VPS telah aktif (jika diakses melalui http://45.32.113.217)

Langkah yang dilakukan

Login ke cpanel dari domain utama (shared hosting)
Buat subdomain baru (vultr.nafies.id)
Kemudian cari dan klik menu Advanced Zone Editor
Pilih domain utama (contoh.com)
Pada tabel Zone File Records, cari nama subdomain yang telah dibuat tadi (vultr.nafies.id)
Klik Edit pada vultr.nafies.id, muncul kotak dialog untuk Edit Record
Ubah Address menjadi IP Address VPS yang dituju 45.32.113.217
Klik Edit Record
Lakukan Edit Record juga untuk subdomain www.vultr.nafies.id
Selesai pengaturan sampai disini.
Coba akses VPS melalui alamat baru (http://subdomain.contoh.com) melalui browser.

Seharusnya akan tampil halaman yang sama dengan VPS yang diakses dengan IP Addressnya (http://45.32.113.217).

Jika halaman yang sama belum muncul, mungkin proses propagasi (pemindahan) belum selesai, umumnya memakan waktu maksimal 1x24 jam. Pada kasus saya, proses propagasi kurang dari 1 menit, alamat subdomain sudah menampilkan halaman web pada VPS.

Cara Install Composer

Thu, 16 Mar 2017 14:10:00 +0800

Minggu lalu kita membahas tentang Cara Kerja Composer, mudah-mudahan teman-teman sudah memahami fungsi dan manfaatnya. Nah, kali ini kita akan membahas tentang Cara Install Composer.

Di sini kita akan membahas Cara install Composer menggunakan Ubuntu 14.04 atau Linux Mint 17.3 Rosa (yang saat ini saya gunakan pada Laptop saya).

Menginstall Composer secara Local

Buka Terminal, kemudian buat direktori dan cd ke direktori tempat composer akan didownload, misal :

$ cd ~/Downloads
$ mkdir composer && cd composer

Kemudian jalankan perintah berikut untuk mendownload script installer Composer :

$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

Akan terdownload installer composer dalam bentuk file php : composer-setup.php

Selanjutnya pada direktori yang sama, jalankan perintah berikut untuk memverifikasi hash file yang telah di-download :

$ php -r "if (hash_file('SHA384', 'composer-setup.php') === '669656bab3166a7aff8a7506b8cb2d1c292f042046c5a994c43155c0be6190fa0355160742ab2e1c88d40d5be660b410') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

Jika muncul pesan “Installer verified”, maka file tersebut valid/aman.

Jalankan perintah berikutnya untuk menginstall Composer :

$ php composer-setup.php

Tunggu hingga proses selesai.

Setelah berhasil, kita dapat mengecek versi composer dengan perintah :

$ php composer.phar -V
Composer version 1.4.1 2017-03-10 09:29:45

Baik setelah berhasil menginstall Composer, kita hapus file installer (composer-setup.php) dengan perintah ini :

$ php -r "unlink('composer-setup.php');"

Sampai disini proses instalasi composer selesai.

Catatan :
Langkah ini sesuai dengan petunjung pada website Composer :
Kunjungi https://getcomposer.org/download{:target:="_blank"}.

Menginstall Composer secara global

Composer yang diinstall secara global memungkinkan kita mengoperasikan composer cukup dengan: composer nama-perintah

# contoh :
$ composer install
# sebelumnya menggunakan 'php composer.phar nama-perintah' pada yang local

Untuk menginstall Composer secara global, proses awalnya sama persis dengan langkah di atas. Kemudian teman-teman bisa lihat dokumentasi di :
https://getcomposer.org/doc/00-intro.md#globally{:target:="_blank"}.

Sesuai dengan petunjuk pada web tersebut, kita pindahkan file composer.phar tadi ke direktori /usr/local/bin dengan perintah :

$ sudo mv composer.phar /usr/local/bin/composer

Baik sekarang kita jalankan composer, atau cek versi composer dengan perintah :

$ composer -V
Composer version 1.4.1 2017-03-10 09:29:45

Selesai, sampai disini kita sudah berhasil menginstall composer secara global dan dapat digunakan untuk project kita.

Perbedaan Composer local dengan global

Memangnya apa sih perbedaan composer yang diinstall secara local dengan yang global?

Composer local

Composer hanya dapat digunakan dalam direktori yang sama.
Jika ingin digunakan untuk direktori atau project lain, maka file composer.phar harus di-copy ke project yang membutuhkan.
Jadi setiap project harus ada file/aplikasi composer atau composer.phar-nya.
Jika extensi .phar dihapus, maka composer dapat digunakan tanpa perintah php, seperti sebelumnya “php composer.phar” menjadi “composer” saja.
Untuk update composer harus dilakukan satu persatu setiap direktori/project.

Composer global

Cukup satu file/aplikasi composer untuk digunakan pada semua project/direktori.
Untuk mengupdate composer, cukup satu perintah: composer self-update.

Bagaimana untuk teman-teman yang menggunakan windows?

Teman-teman bisa gunakan installer composer yang dapat didownload melalui halaman ini: https://getcomposer.org/doc/00-intro.md#installation-windows{:target:="_blank"}.

Demikian cara menginstall composer secara local dan global, mudah-mudahan bermanfaat.

Cara Install Laravel

Tue, 07 Mar 2017 14:10:00 +0800

Bagi seorang developer yang terbiasa dengan “tinggal download” saat menginstall sebuah framework, menginstall Laravel mungkin menjadi agak merepotkan, karena:

Harus terhubung Internet. Secara default, Laravel tidak menyediakan file ZIP yang “tinggal download” dan “tinggal extract” untuk memulai sebuah project baru.
Menggunakan Composer. Setiap kali menginstall Laravel baru, kita harus memiliki Composer untuk menginstall Laravel dan dependensinya.

Baik, ada beberapa cara mengintall framework Laravel untuk project baru:

Menggunakan ‘composer create-project’
Menggunakan Laravel Installer
Mendownload Source Rilis Terbaru Laravel
Mendownload Source dari Github Release Laravel

Pada ke-empat cara tersebut, semuanya tetap memerlukan Composer dan internet untuk menginstall framework Laravel hingga dapat memulai project.

Ingat untuk menjalankan langkah-langkah install framework Laravel, composer sudah harus terinstall pada PC teman-teman, jika belum ada composer, silakan install dulu. Jika teman-teman belum tau apa itu Composer, silakan baca pengenalan composer dan cara kerja composer.

Baik, Kita bahas satu persatu.

Catatan sebelum memulai:

Pastikan semua perintah terminal yang kita lakukan berada pada direktori web localhost kita (misal: C:\xampp\htdocs, atau /var/www/html).
Pada tutorial ini saya menggunakan Ubuntu.

1. Menggunakan ‘composer create-project’

Untuk menginstall Framework Laravel menggunakan composer create-project, lakukan langkah-langkah berikut:

Berikan perintah berikut pada terminal : $ composer create-project Laravel/Laravel nama-direktori-project
Tunggu hingga proses installasi selesai. Durasi proses ini bergantung pada kecepatan koneksi internet yang kita gunakan.
Setelah proses selesai, kita masuk ke direktori nama-direktori-project $ cd nama-direktori-project
Untuk memeriksa apakah Laravel terinstall dengan benar, coba perintah berikut: $ php artisan -V
Aaka akan muncul informasi Laravel Framework 5.4.15 (Versi terbaru saat artikel ini ditulis).

Oke dengan cara install yang pertama ini, saya menyimpulkan kelebihan dan kekurangannya :

Kelebihan

Cukup satu perintah terminal
Dapat menentukan versi laravel mana yang ingin digunakan/di-download

Kekurangan

Terkadang proses cukup lama, memakan waktu beberapa menit.

2. Menggunakan Laravel Installer

Laravel installer adalah aplikasi yang dibuat oleh pengarang laravel agar kita dapat menginstall laravel dengan perintah : $ laravel new nama_direktori. Ok, kita akan bahas sama-sama.

Untuk dapat menggunakan cara ini, kita akan menginstall sebuah paket dari composer yang bernama Laravel/installer pada PC atau laptop kita. Tahapannya sebagai berikut :

Dengan menggunakan terminal, berikan perintah berikut : $ composer global require "Laravel/installer"
Dengan perintah ini, composer akan mendownload paket Laravel/installer secara global dalam PC kita, karena paket ini akan kita gunakan dengan terminal.
Baik setelah selesai, kita menambahkan sebuah script export PATH pada file ~/.bashrc. Tambahkan script berikut pada akhir isi file: export PATH="$PATH:$HOME/.composer/vendor/bin"
Simpan dan exit.
Pada terminal, berikan perintah berikut : $ source ~/.bashrc
Jika tahap ini dijalankan dengan benar, seharusnya ketika kita berikan perintah berikut ke terminal : $ laravel -V Akan menghasilkan informasi versi Laravel Installer : Laravel Installer version 1.3.3 (versi terbaru saat artikel ini dibuat).

Oke dengan adanya Laravel Installer, untuk menginstall project Laravel baru.

Kita bisa berikan perintah: $ laravel new nama-direktori-project (proses installasi laravel akan berjalan)
Ketika proses instalasi selesai, maka kita dapat cd ke nama-direktori-project, dan memberikan perintah : $ php artisan -V
Jika proses installasi berjalan dengan baik, perintah tersebut akan menghasilkan : Laravel Framework 5.4.15

Artinya cara install Laravel yang kedua sudah selesai. Dengan menggunakan Laravel Installer, saya menyimpulkan kelebihan dan kekurangannya :

Kelebihan

Cukup satu perintah terminal
Selalu men-download Laravel versi rilis terbaru
Proses composer cenderung lebih cepat dari cara pertama

Kekurangan

Perlu pengaturan awal sebelum mulai digunakan

3. Mendownload Source Rilis Terbaru Laravel

Cara menginstall Laravel yang ketiga adalah dengan mendownload source code rilis terbaru framework Laravel.

Download source framework Laravel dari url berikut: http://cabinet.Laravel.com/latest.zip atau klik disini. Kita akan mendapatkan file latest.zip.
Pindahkan file tersebut ke dalam direktori project kita, kemudian extract ke direktori nama-direktori-project.
Pada terminal, cd ke nama-direktori-project, kemudian berikan perintah pada terminal : $ composer install

Tunggu proses installasi hingga selesai. Pada langkah ini, proses installasi oleh composer cenderung lebih cepat, karena pada direktori project kita sudah ada file composer.lock. Sehingga composer tinggal menginstall seluruh paket yang ada pada file tersebut.
Oke, proses instalasi oleh composer selesai, maka kita dapat langsung mencoba perintah : php artisan -V Dan menghasilkan : Laravel Framework 5.4.15

Yah, walaupun awalnya kita “mengambil source” framework ini dengan cara men-download, kita tetap harus menggunakan composer juga untuk menginstall paket-paket dependensinya.

Kelebihan

Proses composer cenderung lebih cepat dari cara pertama (karena sudah ada file composer.lock)

Kekurangan

Agak repot mendownload, dan extract ke direktori project

Okay, selanjutnya kita bahas cara keempat

4. Mendownload Source dari Github Laravel

Untuk cara install yang ini, berikut tahap instalasinya :

Kunjungi halaman github dari Laravel https://github.com/Laravel/Laravel
Klik link releases atau https://github.com/Laravel/Laravel/releases
Klik icon/link zip pada rilis versi terbaru Laravel untuk mendownload source code dengan format ZIP
Extract file zip tersebut pada direktori web project kita, misal ke direktori nama-direktori-project.
Buka terminal, kemudian cd nama-direktori-project
Kemudian berikan perintah pada terminal : composer install Tunggu hingga proses installasi selesai
Setelah proses instalasi oleh composer selesai, kita coba perintah : php artisan -V
Seharusnya muncul informasi : Laravel Framework 5.4.15

Kelebihan

Tidak ada

Kekurangan

Agak repot mendownload, dan extract ke direktori project

Info Tambahan

Sebenarnya untuk menginstall laravel pada project baru, kita dapat menduplikat direktori dari project yang lama, selama paket-paket dependensi yang digunakan sudah sesuai (sama dengan project sebelumnya), maka ini bisa menjadi salah satu solusi.

Cara Kerja Composer

Mon, 06 Mar 2017 14:10:00 +0800

Dengan analogi kita sudah pahami mengenai “Dependency”, lalu apa yang dilakukan oleh Composer berkaitan dengan tagline-nya “Dependency Manager for PHP”?

Dari yang sudah kita ketahui sebelumnya, Composer adalah aplikasi yang berfungsi untuk men-download paket-paket atau library-library yang kita perlukan sebagai dependensi aplikasi kita. Bagaimana cara kerja Composer untuk membantu kita?

Cara Kerja Composer

Sebelum men-download library-library yang kita perlukan, Composer akan:

Mengecek apakah library-library ini memerlukan library lain sebagai dependensinya?
Mengecek versi PHP dan module-module PHP yang diperlukan oleh library-library tersebut.

Setelah kedua proses di atas, Composer mendownload library-library tersebut ke dalam aplikasi/project kita pada direktori “vendor”.

Misalkan versi PHP yang terinstall di PC kita tidak cocok dengan versi minimum yang dibutuhkan oleh salah satu library, maka Composer akan memberitahukan bahwa “spesifikasi minimum tidak terpenuhi”. Atau ketika ada module PHP yang diperlukan oleh salah satu library belum terinstall atau enabled, Composer juga akan memberitahukan dan menyarankan kita untuk menginstall/enable module terlebih dahulu.

Jadi selain mengecek dependensi library, Composer juga membantu mengecek spesifikasi PHP kita apakah cocok atau tidak dengan kebutuhan library tersebut.

Contoh Kasus

Contoh kasus saat kita membuat sebuah aplikasi, kita memerlukan paket/*library* dari Composer : - **Paket A**, - **Paket B**, dan - **Paket C**

Maka tahap yang dilakukan oleh Composer adalah :

Composer akan mengecek dependency dari paket A, B dan C tersebut beserta spesifikasi PHP-nya.
Kemudian Composer mendapatkan :
- Paket A: memiliki dependecy paket D, paket E, dan paket F
- Paket B: memiliki dependency paket D dan paket G
- Paket C: memiliki dependecy paket E dan paket H
Composer** akan** men-download :
- Paket A: ini paket yang kita butuhkan
- Paket B: paket yang kita butuhkan
- Paket C: paket yang kita butuhkan
- Paket D: dibutuhkan oleh paket A dan paket B
- Paket E: dibutuhkan oleh paket A dan paket C
- Paket F: dibutuhkan oleh paket A
- Paket G: dibutuhkan oleh paket B
- Paket H: dibutuhkan oleh paket C
Sebelum mulai men-download library di atas, Composer akan mengecek lagi apakah ada dependensi untuk paket D, E, F H, dan H.
Jika Composer menemukan bahwa Paket G memiliki dependensi berupa Paket I, maka Composer juga akan mendownload paket I tersebut (karena diperlukan oleh paket G).
Jadi total ada 9 buah paket/library yang akan di-download oleh Composer, sesuai dengan ketergantungan dari satu paket dengan paket lainnya.
- Paket A: ini paket yang kita butuhkan
- Paket B: paket yang kita butuhkan
- Paket C: paket yang kita butuhkan
- Paket D: dibutuhkan oleh paket A dan paket B
- Paket E: dibutuhkan oleh paket A dan paket C
- Paket F: dibutuhkan oleh paket A
- Paket G: dibutuhkan oleh paket B
- Paket H: dibutuhkan oleh paket C
- Paket I: dibutuhkan oleh paket G

Nah kira-kira begitu cara kerja Composer menurut yang saya pahami :)

Mungkin pertanyaan berikutnya, dari mana ya Composer bisa tahu tentang dependensi library-library yang kita butuhkan itu? Nah, untuk menjawab pertanyaan tersebut, kita ulas tentang “lumbung” library dari Composer.

Packagist.org

Misal kita ingin membuat sebuah paket atau* library* agar dapat digunakan oleh orang lain (melalui Composer), apa yang kita harus lakukan?

Jadi kita (atau seorang developer) yang membuat sebuah library, harus memberitahukan terlebih dulu tentang library yang dibuatnya tersebut kepada Composer. Memberitahukan ke mana? Yaitu ke repository tempat yang menjadi rujukan Composer, yaitu packagist.org.

Kalau teman-teman belum tau apa itu* repository*, analoginya repository itu semacam “lumbung”, tempat di mana seluruh library, serta informasi terkait library yang ada pada Composer dapat kita temukan. Jadi Composer akan mencari paket-paket yang kita butuhkan itu dari “lumbung” yang bernama packagist.org tadi.

Lalu apa saja yang diberitahukan oleh seorang developer sebuah library kepada packagist.org agar dapat digunakan oleh orang lain?

Syarat “publish” Paket

Syarat sebuah library yang didaftarkan pada packagist.org :

Nama dan deskripsi library
Source code dari paket atau library yang dibuat (biasanya dari github)
Versi (minimal) PHP dan atau module yang digunakan (opsional)
Daftar *library *lain yang menjadi dependensinya (opsional).

Teman-teman bisa melihat referensi ini di https://packagist.org.

Nah kalau kita lihat syarat yang ke empat, di sini sang developer memberitahukan kepada packagist, bahwa “jika seseorang ingin menggunakan library saya ini, maka library-library yang saya list di syarat ke empat tadi juga harus di-download.” Btw, “pemberitahuan” yang dilakukan oleh sang developer library ke Packagist.org ini disebut dengan “Publishing Package” atau mempublish paket.

Nah, setelah library ter-publish atau diberitahukan ke packagist.org, Composer merujuk kepada list depedensi *library *yang telah di-publish tadi.

Jadi Composer membuat semacam “daftar isi” depedensi paket-paket/library-library yang ada di dalam repository packagist.org tadi.

Simpulan Materi

Oke, sedikit kita simpulkan untuk tulisan tentang composer ini.

Apa manfaat Composer?

Berbagi library open-source kepada orang lain
Mempermudah kita mendapatkan paket/library open-source tanpa perlu mengetahui dependensi paket yang kita perlukan (karena dependensi di-download otomatis oleh Composer)
Mempermudah update paket library yang menjadi dependensi (tanpa dilakukan secara manual)

Nah jadi kira-kira begitu lah cara kerja Composer sebagai “Dependency Manager for PHP”, sebuah aplikasi yang membantu mempermudah kita dalam membuat sebuah aplikasi.

Sekarang pertanyaannya, apakah dengan membaca artikel tersebut teman-teman sudah memahami tentang Analogi Dependensi dan Cara Kerja Composer?

Jika belum paham, jangan sungkan untuk bertanya di komentar :)

Selanjutnya kita bahas tentang Cara Install Composer.

Berkenalan dengan Composer

Sat, 25 Feb 2017 14:10:00 +0800

Bicara tentang Laravel, kita akan banyak menggunakan tehnik dan teknologi baru di dunia pemrograman PHP. Bagi kita yang baru memulai mengenal Laravel, kita harus berkenalan terlebih dahulu dengan satu tool (alat bantu) untuk menginstall Laravel, yang bernama Composer.

Oke, sebagian kita mungkin sudah mengenal Composer sebelum kenal Laravel, tapi sebagian lagi mungkin baru tahu tentang Composer setelah belajar install Laravel (seperti saya). Nah, timbul beberapa pertanyaan seputar Composer :

Sebenarnya apa sih Composer itu?
Apa manfaatnya untuk kita jika menggunakan composer?
Kenapa laravel membutuhkan composer?

Ini adalah pertanyaan saya saat pertama tahu tentang Laravel dan Composer. Oke, kita akan membahas pertanyaan-pertanyaan tersebut di artikel ini.

Apa itu Composer?

Menurut websitenya, tagline Composer adalah “Dependency Manager for PHP”. Hmm… oke lah, kita simpan dulu tagline ini di memory.

Menurut bahasa saya, Composer adalah sebuah aplikasi yang diinstall ke dalam PC atau Laptop, yang memfasilitasi kita untuk dapat menggunakan script/library opensource milik orang lain ke dalam project yang sedang kita bangun. Lalu apa kaitannya pengertian itu dengan tagline “Dependency Manager”? Oke, kita bahas dulu tentang maksud dari “Dependency Manager”.

Dependency Manager di sini maksudnya, Composer akan mengelola “ketergantungan” antara library-library PHP (yang disebut package), yang dibuat oleh seseorang untuk digunakan oleh orang lain. Dan yang dikelola oleh Composer ini bukanlah script atau *library-*nya, tetapi ketergantungan (dependency) nya, antara satu library dengan library yang lain. Lalu ketergantugan atau dependency yang dimaksud itu bagaimana? oke, kita bahas tentang dependency.

Analogi Dependency

Begini, misalkan kita membuat sebuah project e-commerce yang memerlukan fitur:

Fitur Keranjang Belanja
Fitur Penomoran Romawi untuk Invoice
Fitur Terbilang angka Rupiah untuk Invoice/Tanda Terima

Di atas kita bisa tangkap kata “memerlukan”. Artinya ketiga fitur itu wajib ada pada aplikasi e-commerce kita. Jika tidak ada? Maka bisa dipastikan aplikasi kita tidak akan berjalan sempurna (atau bahkan tidak bisa jalan). Oke, karena ketiga fitur itu “wajib ada”, maka kita harus membuatnya, kan? Bagaimana kalau ada teman kita yang sudah pernah membuat fitur Keranjang Belanja untuk web e-commerce nya. Kemudian ada teman yang lain pernah membuat fitur Konversi Penomoran Romawi. Lalu ada lagi teman sudah membuat fitur Terbilang Rupiah. Hhmm.. sepertinya temen-temen kita ini baik hati dan mau berbagi dengan kita. Dan ternyata ketiganya dengan senang hati memberikan script buatannya (diajarkan pula cara menggunakannya).

Apa yang terjadi? Akhirnya project e-commerce kita dapat selesai dikerjakan lebih cepat dari yang kita rencanakan. Tentu dengan cara ini, proses pembangunan aplikasi akan cenderung lebih cepat, karena untuk mendapatkan fitur tadi, kita tidak perlu bikin dari awal.

Jadi seperti itu contoh “ketergantugan” atau “dependency” ini. Sudah terbayang ya? Inti dari “dependency” adalah, project yang kita bangun “memerlukan” script atau library-library lain agar dapat berjalan dengan benar.

Betapa mudahnya hidup kita saat itu. Bisa kita bayangkan, jika banyak teman yang baik yang berbuat seperti itu, dapat berbagi script/library agar mempermudah pekerjaan orang lain. Hehe..

Dan ternyata … hal itu sudah berlangsung saat ini. Yap! Saat ini ada banyak developer/programmer di berbagai belahan dunia saling berbagi library buatan mereka.

Pertanyaannya, bagaimana caranya agar kita bisa menggunakan library-library dari para programmer di belahan dunia lain? Sepertinya kita tidak bisa meminta mereka dengan mudah, kenal aja nggak!?

Nah, di sinilah peran kerja Composer ~~(masih ingat kan ya? kita ini lagi bahas composer)~~. Composer yang membantu kita dalam mendapatkan library-library PHP milik orang lain agar dapat digukanan dalam project kita.

Kira-kira sampai disini sudah terjawab ya pertanyaan nomor 2 di atas (Apa manfaatnya untuk kita jika menggunakan composer?)

Terakhir, kenapa laravel membutuhkan composer?

Ya, karena Framework Laravel terdiri dari gabungan dari banyak library PHP yang diikat menjadi satu untuk menyempurnakan fitur-fitur yang ada pada Framework Laravel. Sepertinya sejak awal sudah didesain seperti itu. Keuntungkan untuk kita pengguna Laravel apa? Ya, ketika kita membutuhkan library lain, kita tinggal “memanggil” library tersebut melalui composer, dan library tersebut siap digunakan dalam project kita.

Sampai di sini akan muncul pertanyaan lagi, bagaimana cara kerja composer sehingga bisa se-“hebat” itu? Bisa mengumpulkan library milik orang lain dan membantu kita dalam penggunaannya dalam project kita?

Kita akan bahas pada artikel berikutnya, yaitu Cara Kerja Composer dan Lumbung Library Packagist.org.

Terima kasih untuk waktunya membaca artikel ini.

Development Notes on Nafies Luthfi

Minder: Aplikasi Mindmap untuk GNU/Linux

Notifikasi Suara Saat Perintah Terminal Selesai

Cara Deploy VPS Always Free Oracle Cloud

Login ke Akun Oracle Cloud

Deploy VM Instance

Akses SSH

Disk Drive dan Memory (RAM)

Penutup

Melaporkan Problem Pendaftaran ke Customer Service Oracle Cloud

Problem

Langkah yang dilakukan (mengirim email)

Cara Mendaftar Akun Oracle Cloud

Proses Pendaftaran Akun Oracle Cloud

Problem yang saya alami

Format Laporan Progress yang Disukai oleh Senior Dev/Project Manager

Contoh Task dan Laporan Harian

Kenapa Harus Begitu?

Tips Pull Request Github untuk Memudahkan Reviwer

Cara Bertanya dan Menjawab di Forum Komunitas

Kenapa dibahas?

Cara bertanya

Cara Menjawab

Manfaat

Tips

Perangkat Kerja Freelance Web Developer

Perangkat Keras

Laptop

Monitor

Meja

Kursi

Audio

Perangkat Lunak

Sistem Operasi dan Kelengkapan

Terminal Emulator

Office Suite

Launcher

Monitor Internet

Web Development

Browser

Teks Editor

Web Server

Database

Produktifitas

Komunikasi

Mengelola Proyek

Mengelola Aktifitas Kerja

Mengelola Password

Git Client

Perangkat Online

Internet

Penyedia Server/Hosting

Code Hosting

Solusi Problem: Akses Github jika Port 22 Diblok oleh Internet Provider

Problem

Solusi

1. Untuk Github dan Bitbucket

2. Untuk VPS

Regular Auto Backup MySQL / MariaDB di Ubuntu

Cara menggunakan script

Setup CRON untuk auto backup regular

Dompet - Sistem Pencatatan Keuangan Personal

Cara Membuat Sponsor Button pada Github Repository

Cara Menghubungi Customer Support GCP (Google Cloud Platform)

Produktifitas dengan Joplin untuk Aktifitas Harian

Pengenalan Joplin

Privasi (penting)

Pemanfaatan

Fitur

Tips Penggunaan untuk Aktiftas Harian

Manfaat Project Open-Source dan Github bagi Programmer

Tentang Project Open-Source

Tentang Github

Yang Bisa Dilihat Orang Lain

Yang Bisa Disimpulkan Orang Lain

Kesimpulan

Saran dari saya:

Cara Pindah-Pindah Versi PHP pada LAMP stack di Ubuntu

Latar Belakang

Script PHP Swither