Tips Mempercepat Development Web App

Overview

Web-App sudah menjadi mainstream, atau bahkan mulai bisa dikatakan old-school sekarang-sekarang ini, namun bukan berarti membangun Web-App lantas menjadi mudah dan cepat. Memang saat ini banyak sekali teknologi yang dapat digunakan untuk mempercepat proses development Web-App, bahkan mungkin terlalu banyak sehingga mungkin agak membingungkan untuk sebagian orang.

Berikut merupakan beberapa teknologi/konsep yang bisa dimanfaatkan untuk mempercepat development Web-App, antara lain:

1. Develop dengan Arsitektur Front-End dan Back-End
2. Manfaatkan Javascript Widget Libraries
3. Gunakan PostgreSQL
4. Manfaatkan Scaffolding / Source Code Generator
5. Gunakan Bootstrap Admin Template

Arsitektur Front-End Back-End

Dewasa ini berkembang istilah Front-End dan Back-End, bahkan terdapat 1 halaman Wikipedia yang menjelaskan hal tersebut. Untuk mendevelop Web-App dengan tim tiga orang atau lebih, arsitektur ini sangat bermanfaat untuk mengelola kompleksitas, karena arsitektur ini memisahkan dengan jelas UI/UX dengan inner engine dibaliknya, sehingga comply dengan prinsip Separation of Concern, dimana prinsip tersebut merupakan best practice dalam Software Development.

Javascript Widget Libraries

Widget Javascript Libraries dapat mempercepat development karena menyediakan widget-widget yang langsung bisa dipergunakan dengan sedikit kode, bahkan umumnya tidak ada logic pada kode, hanya setting-setting dan konfigurasi saja. Selain itu, Widget umumnya bersifat komponen based sehingga dapat mengunakan berbagai macam libraries sekaligus atau dipadukan dengan Javascript Framework seperti AngularJS, EmberJS dll. Dengan kerugian hanya bentuknya yang standard dan mungkin loading time pertama kali lebih lama, trade-off-nya masih lebih condong ke positif daripada negatif.

PostgreSQL

Jika Oracle merupakan pilihan solid untuk database enterprise, maka PostgreSQL merupakan ekuivalent Oracle pada dunia open source. PostgreSQL memiliki fitur-fitur hebat yang umumnya tidak ada di database lain. Googling PostgreSQL vs Database lain akan memberikan perspektif kapan sebaiknya postgreSQL digunakan dibanding database lain, yang tampaknya lebih sering daripada tidak.

Source Code Generator

Dengan hanya sedikit menulis kode, generate, and BAM! jadilah simple version dengan fully functional features. Sayangnya, menggunakan source code generator ibarat pedang bermata dua, namun jika dipergunakan dengan pas, akan lebih banyak manfaatnya daripada kerugiannya. Salah satu prinsip untuk menggunakannya dengan baik adalah: Hindari men-Generate 2 kali untuk hal yang sama.

Bootstrap Admin Template

CSS Framework tidak hanya bootstrap, banyak pilihan lain yang sebenarnya tidak kalah bagus. Namun khusus untuk Admin Template yang based on Bootstrap, pilihannya sangatlah baaanyaaakk. Dari yang gratis sampai yang berbayar. Untuk menghemat waktu dalam melakukan design, akan jauh lebih efektif jika melakukan modifikasi dari Template yang sudah dipilih, tidak perlu memulai dari nol.

---

Bagaimana dengan anda, adakah teknologi/prinsip yang anda pergunakan untuk mempercepat proses development web-app?

Software Documentation Hierarchy

Disclaimer: kontent posting ini adalah opini dari penulis dan merupakan konten yang experimental, oleh karena itu sangat boleh untuk didebat dan penulis tidak diwajibkan untuk mempertahankannya.

Sewaktu melihat artikel wikipedia tentang software documentation, menurut Saya diperlukan konsep yang berbeda untuk kategorisasi dokumentasi software sebagai komplemen dari kategorisasi yang sudah dikemukakan di artikel tersebut. 

Konsep kategori pada artikel tersebut dibuat dari perspektif pengembangan, sehingga untuk situasi dan kondisi tertentu justu akan kontra-produktif. Misalnya, ada seorang programmer yang ingin mencari tau bagaimana cara install open source software X, kemudian dia mengambil dokumentasi mengenai arsitektur. Dia hanya akan dibombardir oleh informasi-informasi yang belum dia butuhkan, yang mungkin sekali akan membuatnya bingung.

Oleh karena itu, perlu dibuatkan lagi kategorisasi software documentation yang dirancang berdasarkan kebutuhan, situasi dan kondisi user, kategori tersebut yakni:

1. Dokumentasi yang membuat pembaca bisa menggunakan software
2. Dokumentasi yang membuat pembaca bisa meng-install software
3. Dokumentasi yang membuat pembaca bisa mengkonfigurasi software
4. Dokumentasi yang membuat pembaca bisa meng-compile/build software
5. Dokumentasi yang membuat pembaca bisa mengembangkan software

Dengan kategorisasi diatas, dapat dilihat bahwa kategori tersebut merupakan konsep hirarki dokumentasi. Hirarki yang dibangun berdasarkan dependencies dari pengetahuan mengenai perangkat lunak tersebut dan kebutuhan user. Dengan begini, pembaca dokumentasi bisa mendapatkan gambaran mengenai informasi-informasi apa saja yang akan didapat sesuai dengan hirarkinya.

Terkait dengan kebutuhan project, perlu dianlisis terlebih dahulu sampai mana kebutuhan dokumentasi yang diperlukan, karena semakin dalam kebutuhan yang ada, akan semakin mahal membuatnya. Analisis ini dapat mempertimbangkan juga profil user project tersebut, apabila tidak ada programmer atau developer didalam jajaran user, maka hirarki Level 3 (Konfigurasi Software) adalah level terdalam yang masih efektif untuk dibuat.

Hikmah Dari Upaya Contribute Ke Open Source

Sudah menjadi knowledge umum di internet kalau cara termudah untuk bekerja sama dengan orang-orang brilian di seluruh dunia adalah dengan bergabung ke open-source project mereka. Project-project open-source tertentu memang ada yang sarat dengan ilmu, dan Bombermaaan salah satunya.

Awalnya ngeliat bombermaaan dari game di liberkey, karena dulu waktu kecil suka bermain game itu, maka di download-lah dan dimainkan. Begitu ditekahui bombermaaan itu open source, iseng-iseng checkout source-code-nya, ngeliat to-do list-nya, mau mencoba implement team-mode.

And that turns out to be a good decision, ngeliat code-based-nya project bombermaaan, akhirnya sadar betapa bergunanya komentar kode yang konsisten dan extensive. Author-author sebelumnya seperti memulai coding dengan pseudocode, setelah rampung baru dicoding ke bahasa spesifik (C++). Pseudocode tersebut akhirnya menjadi komentar-komentar yang sangat membantu dalam pembacaan kode, penelusuran kode, dan tentunya dalam memahami apa yang terjadi pada kode.

Selama ini Saya berpikir bahwa naming variabel, method dan class yang baik cukup untuk membuat suatu kode nyaman dibaca. Namun setelah melihat kode bombermaan, hal tersebut saya sadari salah karena meskipun kode tersebut memiliki naming yang baik, komentar-komentar yang berupa pseudocode-nya lah yang paling membantu saya dalam memahami kode.

Saat ini sedang menunggu balasan author-nya untuk request agar mereka melihat hasilnya dan meminta feedback. Semoga lancar dan akhirnya kode dicommit, sehingga bisa dihitung telah benar-benar contribute kode ke open source project.
-------
Update: Author sudah me-reply, dia menyarankan untuk melakukan fork-ing terhadap project ini karena memang tidak ada aktivitas lagi di project ini dari original author-author-nya. Sayang sekali saya belum berpikir untuk memaintain suatu open source project. Berarti saatnya hunting open source project lain untuk berkontribusi. Ada ide?

Manajemen Proyek Pragmatis dan Agile

Bulan lalu beres baca buku ini, dan mau berbagi pemahaman yang didapat dari buku tersebut. Karena pemahaman yang akan di-share, maka isinya sebenarnya jauh sekali dari kualitas dan detail level-nya antara buku tersebut dengan artikel berikut. Jika tertarik, saran Saya, bacalah bukunya.

Disini pembahasan dibagi menjadi dua section, yaitu Starting Project dan Doing Project

Starting Project
Pada suatu project akan terdapat ekspektasi dari customer & sponsor, serta batasan yang harus dipenuhi. Contoh daftar ekspektasi dan batasan adalah sebagai berikut:

• Harus selesai dibulan Januari
• Memiliki fitur A, B, C, D
• Biaya tidak lebih dari 10 juta
• Mudah digunakan
• Bug-free
• High performance
• Dan lain-lain

Masing-masing item pada daftar yang dibuat untuk suatu project, diprioritaskan berdasarkan kepentingannya, dan dibagi menjadi 3 kategory. Driver, Constraint, dan Float.

Driver
Driver adalah item utama yang memberi nilai pada project. Kegagalan memenuhi Driver dapat menghilangkan seluruh nilai dari Project. Hanya ada 1 item pada daftar yang boleh dikategorikan sebagai Driver. Lebih dari 1 Driver, maka project akan kacau.

Sebagai contoh, terdapat suatu project yang diharuskan selesai pada bulan desember, fitur/harga/kualitas seperti apapun tidak ada artinya jika belum selesai desember. Maka project Driver-nya adalah waktu.

Constraint
Beberapa item dengan prioritas tinggi namun dibawah Driver dapat dikategorikan Constraint. Kategori constraint boleh diberikan ke lebih dari 1 item.

Constraint perlu dipenuhi agar customer/sponsor. Apabila Constraint dengan Driver saling konflik, Constraint bisa tidak dipenuhi, namun akan menbuat customer/sponsor tidak senang. Apabila seluruh Constraint tidak terpenuhi, nilai project akan hilang seluruhnya, seperti halnya jika Driver tidak terpenuhi.

Constraint idealnya dua, lebih dari itu project menjadi un-managable. Kurang dari itu, project akan kacau karena seakan terdapat dua Driver.

Float
Float kategori item yang penting untuk dipenuhi, namun memiliki fleksibilitas dalam pencapaiannya dan dapat dinegosiasi dengan customer/sponsor mengenai targetnya.

Sama seperti Constraint, kategori Float dapat diberikan kepada lebih dari 1 item, idealnya 3. Tidak memenuhi seluruh Float akan mengakibatkan costumer/sponsor tidak senang, memenuhi seluruh Float akan membangun reputasi yang baik.



Release Criteria
Berbekal daftar Driver, Constraint, dan Float, tuliskan kondisi done untuk project, yang disebut dengan Release Criteria. Release Criteria harus Specific, Measurable, Achievable, Relevant dan Trackable ke daftar Driver, Constraint dan Float. Baik customer, sponsor, management dan pelaksana perlu mengetahui dan menyetujui Release Criteria.

Contoh Release Criteria:

• Software Release tanggal 1 januari
• Normal Skenario untuk fitur A, B, C tanpa bug-free
• Halaman D, E, F dapat diakses hanya dengan 2 kali click.

Product Backlog
Last but not least, tuliskan dokumen Product Backlog. Product Backlog adalah dokumen yang berisikan daftar fitur sistem yang diberi angka prioritas. Prioritas diberikan oleh pemiliki sistem, dengan pertimbangan ROI bisnis. Perhatikan bahwa 1 angka hanya untuk 1 fitur, tidak boleh terdapat dua fitur yang memiliki angka prioritas yang sama.


Doing Project
Project dilaksanakan dengan life cycle iterative incremental. Berbekal Product Backlog yang dimiliki sebelumnya, project dilakukan dengan:

1. Melaksanakan Iteration Planning Meeting di awal iterasi, yang melakukan
1. Memilih fitur-fitur dengan angka prioritas tertinggi yang belum selesai
2. Merencanakan waktu  1 iterasi dengan maksimal waktu 2 minggu
3. Lakukan requirement gathering untuk fitur-fitur yang dipilih bila perlu
4. Mem-breakdown fitur tersebut dengan task-task kecil yang dapat diselesaikan maksimal 8 jam.
5. Mengestimasi man-hour untuk setiap task
6. Membuat perencanaan dan target selesai untuk seluruh task tersebut
2. Melaksanakan pertemuan harian untuk memantau pencapain rencana sepanjang iterasi
3. Melaksanakan Iteration Review Meeting di akhir iterasi, yang:
1. Apabila target tercapai, demokan fitur-fitur tersebut
2. Apabila target tidak tercapai, lakukan evaluasi, targetkan demo untuk iterasi berikutnya

Lakukan kegiatan diatas berulang sampai Release Criteria terpenuhi


Change Request
Perubahan prioritas Product Backlog ataupun perubahan fitur-fitur yang ada pada Product Backlog dapat dilakukan kapan saja selama fitur tersebut bukan merupakan fitur yang sedang dalam pengerjaan iterasi.

Perubahan pada fitur yang telah diselesaikan iterasi sebelumnya menjadi prioritas utama untuk dikerjakan pada iterasi berikutnya.

----------

Sebenarnya buku tersebut membahas jauh lebih detail dan memberikan banyak sekali contoh kasus. Buku yang menurut Saya must-read untuk developer yang ingin mengetahui konsep agile project management, yang dilakukan dengan Pragmatic Way. Semoga bermanfaat.

Isu Scalability Gammu dan Solusinya

Sebenernya tidak ada isu scalability di gammu, hanya karena terdapat situasi dan kondisi di proyek yang Saya ikuti, baru isu scalability muncul.

Pada suatu proyek, terdapat kebutuhan dari client untuk membuatkan sistem yang melakukan pengiriman data dari lapangan ke website pusat, dengan teknologi pengiriman data yang diminta adalah SMS. Digunakanlah GSM modem yang menerima SMS yang disandingkan dengan Gammu. No prob.

Kemudian ada permintaan untuk dibuatkan semacam aplikasi sederhana untuk melakukan pengiriman data ini, agar memudahkan orang yang akan mengirimkan data, karena selain datanya memiliki format yang sulit dihafal manusia biasa, data yang dikirim juga panjang, bisa sampai 4-5 x 160 karakter untuk sekali pengiriman data. Dibuatlah aplikasi sederhana dengan menggunakan J2ME yang menampilkan semacam form pengisian data dan mengirimkan SMS isi datanya ke pusat. No prob.

The problem is, ketika banyak orang yang melakukan pengiriman data sekaligus, dimana setiap pengiriman data terdiri dari 4-5 x 160 karakter, terjadilah deadlock.

Detailnya begini. Karena GSM modem yang dipakai tidak punya fitur inbox, maka seluruh SMS yang diterima tersimpan di simcard. Katakan 20 orang melakukan pengiriman data sekaligus, masing-masing data terdiri dari 4*160 karakter, yang berarti GSM modem akan menerima 4 SMS, dimana masing-masing merepresentasikan bagiannya. Setelah beberapa saat, bagian pertama dan bagian kedua sampai ke simcard, sehingga isi inbox simcard sudah sampai 40 SMS. Ini merupakan jumlah maksimal SMS yang bisa disimpan di simcard yang kami digunakan. Karena penuh, maka bagian ketiga dan keempat dari SMS tidak bisa masuk. Sayangnya, Gammu baru akan menghapus inbox simcard ketika seluruh bagian sudah ada di inbox. Disatu sisi bagian ketiga dan keempat tidak bisa masuk karena inbox penuh, disisi lain isi inbox tidak dihapus karena menunggu semua bagian tersedia. Deadlock.

Memang Gammu memiliki setting timeout, yaitu untuk menghapus SMS yang tidak lengkap setelah beberapa saat. Namun jalan ini tidak diambil karena tidak ada jaminan SMS yang sudah dihapus akan dikirim lagi baik oleh operator maupun orang yang mengirimkan data.

Untungnya, pengirim data tidak menuliskan datanya dengan cara menuliskan SMS biasa, namun dengan mengisi form pada aplikasi J2ME. Inilah yang menjadi titik solusi dari permasalahan.

Kami mengubah cara aplikasi tersebut mengirimkan SMS. Alih-alih mengirimkan 1 kali SMS panjang yang akhirnya dipecah menjadi 5 SMS oleh entah siapa, aplikasi memecah-mecah sendiri 1 SMS panjang menjadi 5 SMS dan mengirimkannya satu per satu. Pada setiap SMS disiapkan ID unik untuk menyatakan bahwa 5 SMS yang dikirim ini merupakan satu kesatuan.

Dengan begini, ketika satu SMS diterima GSM modem, SMS langsung dihapus dari inbox simcard oleh Gammu dan diletakkan ke tabel database. Dari tabel itulah, diambil SMS-SMS tersebut dan dirangkai lagi menjadi satu kesatuan data sesuai dengan ID-nya. Akibatnya inbox simcard akan selalu kosong dan tidak ada lagi SMS yang ditolak karena inbox penuh.

Tentu saja solusi ini tidak cocok untuk semua keadaan, solusi ini hanya cocok jika:

• SMS yang dikirim sangat panjang, lebih dari 160 karakter
• pengiriman SMS melalui aplikasi buatan, bukan bawaan HP
• GSM modem yang digunakan tidak memiliki fitur inbox didalamnya
• GSM modem yang digunakan hanya satu untuk seluruh tujuan pengiriman data
• Mengambil asumsi bahwa pengirim data hanya akan mengirimkan suatu data sekali untuk selamanya

Dengan constraint bahwa data yang dikirim harus diproses dalam waktu 24 jam, solusi ini sampai sekarang masih cukup untuk 100 pengirim data sekaligus pada waktu yang bersamaan, dimana masing-masing data terdiri dari 4-5 SMS. Mungkin akan tahan sampai 1000 pengirim data sekaligus. Lebih dari itu, mungkin perlu ditambah GSM modem baru. 

Jika anda mengalami situasi dan kondisi yang mirip dengan ini namun menggunakan solusi yang berbeda, I would love to hear it. Atau jika ingin mengaplikasikan solusi ini, feel free to contact me at my email. Semoga bermanfaat.