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.

Pentingnya Performance dalam Software

Abis nonton video disini: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-046j-introduction-to-algorithms-sma-5503-fall-2005/video-lectures/lecture-1-administrivia-introduction-analysis-of-algorithms-insertion-sort-mergesort/

Baru 25 menit nonton, sudah mendapatkan pencerahan yang outstanding. Ada alasannya memang, kenapa MIT terkenal sebagai salah satu universitas Top di Dunia, kuliah undergraduate-nya saja masih bisa memberikan pencerahan kepada salah satu lulusan S2 ITB. 

25 menit awal tersebut membicara performance. Professor tersebut menanyakan hal apa yang lebih penting dari performance? beberapa mahasiswa menjawab:

• Correctness. Benar atau tidaknya program
• Stability/ Robustness. Robust atau tidaknya program
• Programmer Time. Waktu yang dihabiskan untuk membuat program
• Scalability. apakah program bisa di scale-up-kan atau tidak
• User-Friendliness. Apakah program mudah digunakan atau tidak
• Security. Keamanan dari program

Kemudian professor tersebut menambahkan lagi:

• Modularity. Modularitas program, agar bug/perubahan di satu tempat tidak mempengaruhi tempat lain
• Functionality. Apakah program memiliki fitur-fitur yang lengkap atau tidak

Ternyata banyak parameter yang lebih penting dari performance. Lantas mengapa justru performance yang dipelajari?

Melihat parameter-parameter lain diatas yang lebih penting dari performa, apabila ditelusuri lebih dalam, sebenarnya membutuhkan performa. Sebagai contoh:

• User-Friendliness. Program jadi not so user friendly kalo ada lag ato musti nunggu lama
• Correctness. Bila ada kebutuhan 'real-time', performance kurang baik yang mengakibatkan ada delay 1 menit akan membuat program tersebut not so realtime

Oleh karena itu, performa adalah mata uang dalam program. Dengan performa, security bisa diaplikasikan. Dengan performa, user-friendliness bisa dicapai, dengan performa, correctness bisa dipenuhi. Parameter-parameter lain dipenuhi oleh performa. Parameter-parameter lain di-'beli' oleh performa. Perfoma by itself tidak penting, namun menjadi salah satu paling penting jika digunakan untuk mengadakan parameter-parameter lain. Mirip dengan uang, by itself uang tidak bisa dimakan, dikenakan, ditinggali, namun uang bisa digunakan untuk mengadakan makanan, baju, tempat tinggal dan lain-lain.

Semoga bermanfaat, dan please do visit link diatas jika ada waktu senggang.

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?

Parameter Pada Fungsi Utama

Java dan C++ (mungkin bahasa lain juga) memulai programnya dari fungsi utama, yang biasanya memiliki signature int main(int argc, char** argv) di C/C++ atau public static void main(String[] args) di Java. Fungsi utama ini memberikan saya inspirasi pertanyaan untuk recruitment, pertanyaannya adalah kapan parameter tersebut memiliki nilai dan apa nilainya jika ada.

Mungkin pertanyaannya cukup mendasar, namun Saya cukup kaget bahwa lebih banyak yang tidak tahu daripada yang tahu. Saya pikir pertanyaannya yang kurang jelas atau ambigu, tapi ada juga 1-2 orang yang langsung bisa menjawab begitu pertanyaannya selesai Saya ucapkan. Artinya memang ada lulusan informatika yang tidak tahu kapan parameter tersebut diisi.

katakan terdapat kode pada file main.cpp sebagai berikut:

int main(int argc, char** argv){
 for(int i=0;i < argc; i++) cout << argv[i] << endl;
 return 0;
}
note: kode diatas kurang iostream dan std


kemudian di compile dengan perintah c++ -o testargv.exe main.cpp
lalu testargv.exe dieksekusi dengan perintah: testargv.exe coba parameter
maka outputnya akan sebagai berikut:
testargv.exe
coba
parameter


Disini, C++ dan Java memiliki sedikit perbedaan, namun pada prinsipnya tetap sama. C++ berisi perintah eksekusi programmnya, sedangkan Java tidak. Dengan begini, jelas kapan parameter tersebut bernilai dan apa nilainya.

Berbekal pengetahuan ini, sebenarnya program-program umum adakalanya memanfaatkan ini untuk melakukan sesuatu, sebagai contoh Firefox. Jika kita berikan alamat website pada shortcut di desktop seperti pada gambar berikut:

Ketika Icon diclick, maka firefox akan langsung membuka halaman yang kita tuliskan. Tentunya apa parameter tambahan bagi setiap program berbeda tergantung programnya, cuma rata-rata memang mereka take account of added parameter ketika di run. Semoga bermanfaat.

Optimasi Peng-eksekusi-an Branch (IF/SWITCH)

Baru mengaplikasikan teknik yang menurut gw pribadi cukup unik, yaitu optimasi eksekusi kode branch/conditional pada aplikasi yang punya main loop.

Misalkan gw punya aplikasi dengan potongan kode demikian:

Katakan method someMethod() dipanggil di dalam main loop. Method diatas tampak simpel, namun dari hal yang simpel tersebut mengandung potensial problem, khususnya ketika programmer melakukan salah ketik (katakanlah ia menulisnya "Login", bukan "login"). Sebenarnya dengan ketelitian yang tinggi, salah ketik bisa dihindari, namun manusia tetap manusia, sehingga kasus seperti ini, sebaiknya diserahkan ke komputer, seperti pada gambar berikut:

Pada gambar diatas, string di parse dengan parseEnum(String pInput) menjadi Enum Action. Dengan penggunaan enum, jadi dapat menggunakan switch, dan kesalahan typo akan mengakibatkan compile error. Compile error ini yang dimaksud menyerahkan ketelitian ke komputer.
Btw, anggap aja isinya parseEnum(String pInput) sudah benar ya, meski diatas hanya mengembalikan Unknown terus, hehe.

Pada realnya, someMethod1() isinya bisa sangat panjang, dan semakin panjang method, akan semakin sulit untuk dibaca oleh orang lain. Oleh karena itu, dapat dioptimasi lagi menjadi berikut:

Pada gambar diatas, diciptakan kelas abstract ActionWorker, yang nantinya akan memiliki kelas turunan yang bersesuaian dengan action yang ada. Pada optimasi ini, bahkan branching sudah tidak ada lagi di badan someMethod2(), sudah terenkapsulasi pada ActionWorker.ActionWorkerFactory(Action pInputEnum). someMethod2() menjadi sangat pendek jika dibandingkan dengan someMethod1().

Namun meski terenkapsulasi, branching SWITCH yang ada tetap terpanggil setiap kali loop. Apabila 1 detik terdapat 100 loop, akan terpanggil 100 kali. Optimasi selanjutnya adalah untuk mengurangi pemanggilan loop menjadi hanya 1 kali. Ya, terdapat cara untuk mengurangi menjadi hanya 1 kali, meski sebenarnya perlu dipanggil setiap loop.

Contohnya dapat dilihat pada gambar berikut:

Pada gambar diatas disertakan lagi enum Action, karena telah diubah sedikit, yaitu dengan menambahkan member mIntValue, konstruktor yang menerima parameter integer, dan method getIntValue()
selain itu, ditambahkan member ActionWorker[] mWorkers yang diinisiasi pada method init(). Method init() itu perlu di-invoke sekali sebelum main loop. Hasilnya, jadilah someMethod3()

sekilas someMethod3() mirip dengan someMethod2(). Bedanya terletak pada pen-assign-an tAppropriateWorker. Method someMethod3() hanya melakukan pengaksesan element pada suatu array, sedangkan method someMethod2() melakukan branching. Dengan begini, tidak ada lagi pemanggilan SWITCH pada main loop, yang digantikan dengan mengakses element array.

Sempet lakuin percobaan kecil-kecilan. Di java, branch dengan 1 kondisi lebih cepat daripada pengaksesan element array. Tapi mulai dari 2 kondisi dan seterusnya, pengaksesan element array lebih cepat. Selain itu, pengaksesan element array memiliki waktu konstan berapapun jumlah array yang ada, antara berisi 1 element dengan 1000 element, apabila diberikan index-nya, waktu aksesnya akan tetap.

Kalo ada yang kurang dimengerti, atau ada kesalahan, please kindly inform me by email, and thanks before. Semoga bermanfaat

2 Cara Membuat Aplikasi Jadi Scalable

Gw bukan orang yang jago bikin aplikasi, meski bukan seorang pemula juga, adalah pengalaman sedikit. Jika ada kesalahan, mohon dibantu untuk memperbaikinya.

Sebelum bahas lebih lanjut, perlu dijelaskan maksud dari scalable disini. Aplikasi yang Scalable adalah aplikasi yang apabila pengguna-nya banyak, yang perlu dilakukan untuk memfasilitasinya adalah dengan menambah jumlah mesin, bukan upgrade spek mesin (ex: nambah memori mesin, nambah CPU mesin).

Sengetahuan gw yang masih belajar ini, scalable umumnya bisa dicapai apabila:

• Sebisa mungkin aplikasi bersifat transaksional

Sifat transaksional disini maksudnya aplikasi tersebut apabila dijalankan oleh mesin yang berbeda, outputnya akan tetap sama. Misalkan ada web service yang menerima integer dan mengembalikan kuadrat-nya. Web service tersebut, jika dijalankan di beberapa server sekalipun, hasilnya akan konsisten untuk semuanya.

• Usahakan kompleksitas semua algoritma dan memori O (log(n)), maksimal O(n), dan idealnya O(1)

Ya, kompeksitas algoritma dan memori berpengaruh terhadap scalability aplikasi. Kompleksitas O(n) adalah kompleksitas yang paling berat yang bisa di toleransi untuk scalability. Diatas O(n), semakin banyak user akan semakin cepat memperlambat sistem


Gw yakin sih masih banyak lagi, tapi sementara yang pernah bener-bener dirasain itu 2 diatas. Semoga bermanfaat.

Apa itu Pointer: Perspektif Lain

Pointer itu biasanya sulit dimengerti orang yang baru belajar C atau C++. Pernah ditanya juga ama sodara apa itu pointer. Jadi tertarik untuk menjelaskan definisi pointer yang gw anut.

Prerequisite: Paham variable scope, Paham array, paham shortcut icon desktop

Apa sih pointer itu?
Jujur tak sanggup menjelaskan pointer langsung, jadi pake analogi sederhana aja. Lets take a little detour. Nilai dari variabel pada program itu disimpan pada memori komputer. Memori laptop saat ini umumnya 1-4 Gigabyte, artinya terdapat lebih dari 1 milyar tempat penyimpanan. Ini bisa dianalogikan dengan satu jalanan yang panjang dimana terdapat 1 milyar rumah sepanjang jalan. Jika nilai variabel diibaratkan dengan isi rumah, maka pointer adalah alamat rumah tersebut. Hal ini kadang membingungkan orang, namun seharusnya tidak, karena biasanya orang tidak sampai salah menulis surat yang ditujukan kepada "Tuan Jl Dipati Ukur No. 135" yang tinggal  di "Riza Ramadan" misalnya.

Contoh lain lagi, jika memory adalah array yang elementnya adalah bytes, maka pointer adalah index-nya. Misalnya ada:
int* j = (int) malloc(4); /*asumsi 1 integer ukurannya 4 bytes*/

kode diatas bisa dianalogikan dengan:
memory_as_array[j] = (int) malloc(4);

ketika kita printf('%d',j); maka yang kita print adalah index-nya, sedangkan jika printf('%d',*j); maka yang kita print adalah isi dari memory_array[j].

Dasarnya kira-kira begitu, tapi karena memory itu beda dengan array biasa, things got complicated. bedanya antara lain:

• Jika array of sesuatu isinya bertype sama sehingga setiap elemen ukurannya tetap, memory tidak

masing-masing element memori bisa memiliki ukuran yang berbeda-beda. bisa jadi memory_as_array[0] panjangnya 1 byte, memory_as_array[1] panjangnya 5 bytes, memory_as_array[6] panjangnya 3 bytes.

• Meskipun bisa berbeda ukuran elementnya, Memory itu array 1 dimensi

Perhatikan bahwa contoh diatas setelah index 0 adalah 1, sedangkan setelah index 1 adalah 6, bukan 2,3 dst, ini ada maksudnya, yaitu karena ukuran element di memory_as_array[1] adalah 5, sehingga element ke 2,3 sampai 5 adalah milik element 1. Jadi element selanjutnya yang bisa diisi adalah 6. Ada Warnings disini, meskipun element di index 2 itu bagian dari element di index 1, kita tetep bisa akses element ke 2. Disini bahayanya, karena bisa dikira element tersebut adalah element yang di 6, padahal masih bagian dari element 1.

• Suatu element dari memory bisa dibuat mengacu element lain, analoginya seperti shortcut icon 

Umumnya di desktop ada shortcut program bukan? yang kalo kita click akan ngejalanin program tersebut?. Pertanyaannya, apakah shortcut icon itu programnya? jawabannya bukan, programnya letaknya bukan di desktop, tapi entah dimana. Shortcut itu mempercepat akses terhadap program sehingga user tidak perlu repot-repot buka explorer untuk masuk ke folder tempat program.exe berada.
Demikian juga dengan pointer, element B bisa diisi dengan element A, sehingga element B seolah olah merupakan 'shortcut' terhadap A. Bedanya antara pointer dengan analogi diatas, pointer berlaku dua arah, jika kita mengubah 'isi' dari element A, maka 'isi' B akan ikut berubah dan sebaliknya.

• Element di memory bisa invalid

This is the reason why pointer can be nasty. Ambil contoh memory_as_array diatas yang index-nya terisi di 0,1 dan 5. Katakan memory_as_array[1] kita hapus, dengan free kalo c, atau delete kalo c++. element di 0 dan dan 5 akan tetap baik-baik saja, namun ketika kita pengen akses 'isi' element 1, bam, error.

• Element di memory kebal akan scope, tapi index ke element tersebut tidak

beda dengan suatu variable yang hilang kalo scope-nya abis, element di memory akan tetep ada meski udah keluar scope. Sayangnya index untuk akses element tersebut tidak. Inilah kenapa ada istilah memory leak, karena index yang bisa dipake untuk ngacu elementnya udah ga ada. #:'kan bisa tinggal delete memory_as_array[1] aja bukan?' #:teorinya begitu, kalo tau emang di element ke 1. Sayangnya jarang kita tau nilai index-nya, hampir ga pernah kita bisa tau kalo yang perlu didelete itu element ke 1. #'kenapa?' #:penjelasan selanjutnya.

• Umumnya kita tidak menentukan index memory-nya dari element yang kita buat

ambil contoh: int* j = (int) malloc(4); printf('%d',j); Outputnya tidak akan selalu sama, bisa kadang sama, kadang berbeda. Intinya bisa kita pastikan bahwa j tidak konsisten di suatu nilai.

Nah, kira-kira demikian definisi pointer menurut gw. Merasa definisi diatas salah atau kurang tepat? mohon masukkannya ya, terima kasih.

Semoga bermanfaat.

Bahaya Overidable Method di Konstruktor

Lagi coding Java, nemu error Overridable method call in constructor. Jadi keinget dulu di c++ pernah ngalamin hal yang sama, semua OOP kyknya begitu deh, jadi pengen jelasin lebih detil.

Apa itu Overridable Method di Konstruktor?
Overridable Method adalah method pada suatu kelas yang dapat di override pada kelas turunannya. Umumnya hampir method public dapat di override.

Kenapa Overridable Method di Konstruktor berbahaya?
Katakan ada kelas A, yang pada konstruktornya memanggil method EchoClass(), isinya ngeprint A.
Kemudian ada kelas B, turunan kelas A, yang meng-override EchoClass(), yang isinya ngeprint B.
Katakan konstruktor B isinya kosong, dengan kondisi demikian, ketika kita meng-instansiasi kelas B, EchoClass yang ngeprint B tidak akan pernah muncul, yang muncul hanyalah ngeprint A.

err, berbahayanya dimana ya?
sebenernya ga bahaya sih kalo contoh diatas. Tapi pada umumnya, kenapa sampai EchoClass di override, itu pasti terdapat suatu maksud. Jika seorang perancang memang bermaksud menggunakan EchoClass dari Kelas Bapaknya, tentunya tidak akan repot-repot meng-override EchoClass. Ketika yang diharapkan dari menginstansiasi kelas B adalah memanggil EchoClass() yang ngeprint B, disinilah bahayanya muncul.
Coba kita ganti nama kelasnya, A menjadi OSHandler, B menjadi LinuxHandler, dan EchoClass menjadi InitializeClass(). Bisa saja seorang beranggapan ketika menginstansiasi LinuxHandler, berharap LinuxHandler.InitializeClass() yang dipanggil, padahal kenyataannya tidak demikian.

Wajar bahaya, orang ribet gitu kelas-kelasnya, coba bikin simpel pasti ga bahaya deh
yah, kalo bisa mengindari situasi kayak diatas, tentu bagus sekali.

Anggep emang kayak diatas deh kasusnya, solusinya gimana?
sederhananya, membuat Overridable Method menjadi Un-Overridable Method. Ini jalan pintasnya, meski terkadang tidak bisa semudah itu. Caranya paling mudah adalah dengan mem-private-kan method tersebut.

Tapi ya, ga pernah tuh gw ngalamin kasus gitu
Good for you then. unfortunately for me, gw malah udah 2 kali ngalamin.

Ada yang kurang jelas atau ingin tanya lebih dalam? tulis aja di comment ya, akan Saya jawab sebelum nambah post pastinya, thkyu.

Dark Theme Netbeans Java

Selera Personal aja sih, tapi gw lebih seneng dark theme untuk coding. Lebih enak buat mata apalagi kalo menghabiskan waktu berjam-jam.

Dibawah ini gambar salah satu editor yang dipake, Netbeans, dengan profile Norway Today yang di enhance lagi. Tentu saja enhancement-nya khusus untuk bahasa Java.



Enchancementnya antara lain:

• Variabel dengan scope yang berbeda, yaitu variabel lokal, variabel member, dan variable parameter, memiliki warna yang berbeda, sehingga mudah dibedakan
• unused variabel, scope apapun, apabila tidak digunakan akan berwarna merah
• Method declaration dan Method usage memiliki warna sendiri
• Class Declaration dan Class usage juga memiliki warna sendiri
  

Pengen tampilan netbeans java-nya jadi kayak diatas tapi males ngedit satu-satu? PM aja, ntar dikirimin export-annya, hehe

Untuk Apa Bikin Method?

Saya pernah ditanya "Untuk apa bikin method?" baru-baru ini. Setelah lama berpikir, akhirnya menemukan jawaban yang keren (setidaknya untuk level Saya).

Jawabannya adalah untuk me-manage complexity.

Bagi yang baca buku Code Complete, pasti kenal istilah manage complexity. Bagi yang tidak, read on, but beware, this is a quite long post.

Misalnya, Saya diminta oleh dosen untuk bikin program baca file X, tulis isinya ke layar, dan save isinya ke file Y. katakan Saya masih pemula, belum tau cara baca file X, belum tau tulis ke layar, belum tau cara tulis ke file Y.
Tapi Saya diminta untuk menulis programnnya, saat itu juga. Dengan kondisi seperti ini, kira-kira jawaban Saya akan begini:

int main(int argc, char** argv) {
bacaFileX();
tampilkanIsiFileX();
tulisIsiFileXkeY();
}

Tugas dari dosen tadi jelas, Saya punya tiga concern/urusan/isu yang sebenarnya berbeda satu sama lain. 1 baca file, 1 tampilin ke layar, 1 tulis file. Kalo semua-nya digabungin, kode function main pasti akan panjang, selain itu, 3 concern tersebut menjadi satu. Sayangnya, Saya sedikit kesulitan memfokuskan pekerjaan jika dalam 1 method, terdapat lebih dari 1 concern.

di jawaban atas, terdapat total 4 method, masing-masing dengan concern yang berbeda:

• 1 untuk mengurusi bagaimana cara program Saya memenuhi tugas dari dosen
• 1 bagaimana cara baca file
• 1 bagaimana cara tulis ke layar
• 1 bagaimana cara tulis ke file

jadi ketika Saya melihat function main, concern Saya adalah apakah program dapat memenuhi tugas dosen. Ketika Saya liat bacaFileX(), concern-nya adalah bagaimana membaca file, dan HANYA BACA FILE. disini tidak memikirkan bagaimana cara tulis ke layar, gimana cara tulis ke file. Itu lain persoalan, sehingga tidak perlu. Dengan googling, akhirnya didapatkan cara baca file dengan C++. Di-implementasikanlah method tersebut.

Namun jika algoritma main tetap seperti diatas, isi File X hanya didapat didalam bacaFileX(), sedangkanyang dibutuhkan adalah isinya untuk ditampilin ke layar dan tulis ke file lain. Oleh karena itu, program utama perlu diubah menjadi demikian:

int main(int argc, char** argv) {

char* isiFileX = bacaFileX();

tampilkanIsiFileX();

tulisIsiFileXkeY();

}

dengan begitu, didapatlah isi file X.

kemudian berpindah ke tampilkanIsiFileX(). nah, disini dilakukan googling, akhirnya ditemukan cara menulis ke layar. Namun pas diimplementasi, didalam tampilkanIsiFileX(), perlu dilakukan pembacaan isi file. Dan ini jadinya menyalahi untuk concern tidak bisa lebih dari satu, oleh karena itu perlu diubah menjadi seperti ini:

int main(int argc, char** argv) {

char* isiFileX = bacaFileX();

tampilkanKeLayar(isiFileX);

tulisIsiFileXkeY();

}

kemudian berpindah ke tulisIsiFileXkeY(). concern ini mirip dengan tampilkan ke layar, diperlukan pembacaan isi file x dulu, sehingga menyalahi aturan 1 concern. Oleh karena itu, perlu diubah menjadi seperti ini:

int main(int argc, char** argv) {

char* isiFileX = bacaFileX();

tampilkanKeLayar(isiFileX);

tulisKeFileY(isiFileX);

}

akhirnya programnya selesai.

Keuntungannya managing complexity yang baik dengan maksimal 1 concern/method itu antara lain:

• kode lebih mudah dimengerti. Dengan cuma 1 concern, biasanya Saya akan lebih mudah mengerti kode yang sudah lama tidak Saya lihat.
• Biasanya Kode per function/procedure jadi lebih pendek. Kalo Saya pribadi, kode 1 method sebaiknya ga lebih dari 30 baris. Selain keliatan dari atas sampai bawah, lebih gampang dibaca juga karena tidak panjang.
• Yang paling penting, jika ada perubahan, lebih mudah untuk diadopsi dan diberlakukan. Pada contoh diatas, jika dosen meminta file tersebut bukan di lokal namun di internet, maka hanya 1 method yang perlu berubah.

Ada yang bilang juga yang demikian disebut juga dengan abstraksi. Mungkin teknik diatas adalah teknik abstraksi, namun Saya ingin lebih menekankan pada tujuan diberlakukannya abstraksi, yaitu tetap untuk me-manage complexity.

Nah, bagaimana dengan anda, Untuk apa anda bikin method?

Sang Generalist

Pada satu titik dalam karir software developer, mungkin akan timbul pertanyaan, Spesialist atau Generalist.

Spesialist adalah seseorang yang menguasai teknologi dengan sangat mendalam. Let say Java. Seorang specialist java mengetahui bagaimana cara men-down-kan JVM-nya dengan sengaja, atau bahkan, jika diminta dan diberikan resource cukup, mampu mengimplemtasikan JDK. Visi spesialist, 'tidak ada permasalahan yang tidak bisa dipecahkan dengan teknologi ini.'

Seorang Generalist adalah orang yang memiliki pengetahuan yang meluas mengenai teknologi. Dari C sampai C#, dari J2ME sampai j2EE, dari CGI sampai Ruby, Seorang Generalist memiliki 'just enough knowledge' untuk memulai, dan dari sana ia dapat dengan mudah 'memperdalam' sesuai dengan kebutuhan. Visi Generalist, 'tidak ada permasalahan yang tidak memiliki teknologi yang fit dengan sempurna untuk menyelesaikannya.'

Saya tidak berani mengatakan siapa lebih baik dari siapa. Mana yang lebih baik, tergantung dari individu masing-masing. Terkesan mengelak ya? hehe, but seriously, it depends.

Analisis Saya yang dangkal, hehe, saat ini di Indonesia mungkin lebih cocok Generalist. Karena:

• Penguasaan IT masyarakat Indonesia belum merata, masih banyak yang gaptek. Sehingga teknologi yang 'tepat guna' mungkin akan lebih diminati daripada yang 'cutting edge'
• Pola pikir yang serba instant, yang berdampak pada demand time to market yang kecil. Sehingga untuk memenuhi hal tersebut, perlu teknologi yang paling sesuai.

Saya sendiri lebih senang jalur Generalist, karena lebih banyak bahan yang dipelajari.

Improving a Transactional Server Architecture

In my professional experience, so far I’ve made two medium to big-sized Server applications. The first one was for an online payment server, written in Java; the second was for an MMORPG online game, written in C++. Right now, I’ve been assigned to design and implement a server similar to my first Server application, which is also in Java. This time, I took a lot of time researching in order to make better software than before.

My first server architecture was a quite plain one. Picture below maybe will give a brief explanation.

A thread listens for connection, and put the socket of a connection into a queue. Then one of the may worker thread which are already waiting for an element of a queue take it, process it, and send the reply directly using the very socket it took from queue.

This architecture server quite well before, and I don’t see a reason it wouldn’t this time. Still I googled the web to improve it. In my search, I found two of the most significant improvement, that is:

• Use SocketChannel instead of plain java Socket

• Ensuring 1 thread/client will give better throughput

But then, I found an interesting word from somewhere here, that discourage using a queue, because it enforcing one more context switching, where it should be minimize.

It tickles my brain for a while, until someday I had a 'click'. The idea is to take remove the connection listener thread and of the queue. But how does the port listening being done if no thread to do it? The answer is, the worker do it.

Yes, all the worker thread should listen to the specified port. In detail, inside the worker code, exist something like:

While(!Stop){

Socket tSocket = mBindedSocket.accept();

…….. // the work goes here

}

First I thought it was weird, but then I try to implement this concept. Quite amazed by it, that concept is actually works! Now the architecture looks like this:

As a result, it’s a much simpler architecture, and logically faster because of the excluding of queue filling and taking, thus reducing the number of context switching occurred.

I had run some test, and the result pretty much expected. The new architecture require less time than the original architecture.

Test number original new

1 26 sec 24 sec

2 25 sec 23 sec

3 25 sec 23 sec

4 25 sec 23 sec

5 26 sec 23 sec

The test scenario was a simple one, the server returned ‘hello world’ every time a client connects to it, without read the message from client.

Maybe this finding isn’t impressive at all, but at least this was useful for me, as it feels good because I could improve what I made years ago, so that I know my skill is improving even if just a little, :)

Release Transaction Server Stub

Dulu waktu kerja di VSI, sempet buat multithreading transaction server make java2SE. Makin kesini, kyknya kerasa manfaatnya kalo misalnya punya transaction server yang generik.

Jadi akhirnya gw memutuskan untuk menulis ulang dari nol, konsep server transaksi tersebut. Ditulis dalam bahasa java juga. Dan karena ingin tetap menggunakan konsep generik, akhirnya project ini hanya berupa stub/skeleton saja, namun sudah runs well. Mengenai lisensi kode, LGPL aja mungkin, hehe.

bagi yang ingin melihat, memakai, mengkritik, memberikan bugfix, hehe, bisa dilihat di sini:

http://github.com/rizaramadan/Transaction-Server

Query-Helper, Kelas Java Simpel Untuk Membuat Query

Tampaknya sudah lama tidak posting di blog ini, hehe. Sebenarnya bukan gw males posting, tapi posting di blog lain, dengan identitas bukan asli tentunya, hihihi.

Anyway, ditimbang-timbang tadinya mo posting di mana, tapi akhirnya diputuskan disini saja. Bersama posting ini saya mau, eng ing eng, release Repo di github, hehe.

Namanya Query-Helper, kelas simpel untuk bikin query. Terinspirasi dari framework PHP, sedang iseng ingin reinvent the wheel, serta saran dari Breck Yunits untuk bikin project sampingan yang simple, akhirnya dibuat juga ini.

Feel free to give me comments, critics, bugfix, or contribute, hehe. Sementara sih sourcenya ga berlicense, hua ha ha ha, tapi kalopun nanti dikasih, paling BSD atau LGPL, hehe.

Talk Less Do More ->Big NO for Code

Sekarang lagi banyak iklan di TV, poling SMS Band Indonesia yang Talk Less Do More Alias ga banyak omong tapi prestasi mencorong, ha ha. Sangat baik sih memang, terkadang, tapi tidak Kode.

The Talk
Pernah baca dimana gitu, bahwa katanya komentar itu kayak makan nasi goreng, kalo enak rasanya bikin makan jadi menyenangkan, kalo biasa aja, lumayan ada yang dimakan. Samanya, kalo ada komentar bagus jadi gampang ngerti kode, tapi kalo biasa aja, mending daripada ga ada, hehe. Bisa diistilahkan Komentar adalah Talk-nya di dunia Kode, karena dia hanya menuh2in aja tanpa ngelakuin apa-apa.

The Do
Terinspirasi dari blog Assert True, disana dinyatakan bahwa untuk melakukan optimasi kode, kuncinya adalah dengan Do Less. Disana dikatakan bahwa Instruction per Second CPU sudah fix, sehingga untuk mempercepat suatu algoritma, satu-satunya cara tersisa adalah membuatnya do less.

Kalo dipikir-pikir, optimasi kompleksitas dari, katakanlah O(n), menjadi O(log n) sebenarnya memang membuat algoritma tersebut Do Less. Triknya dapat bermacam-macam, namun segala trik yang diaplikasikan, memang untuk membuat suatu algoritma melakukan instruksi yang lebih sedikit dari sebelumnya.

Sehingga kesimpulannya, untuk suatu kode, Talk Less Do More adalah sesuatu yang justru tidak baik, karena selain kode sulit dimengerti, kode cenderung memiliki performa yang relatif kurang baik. Makanya slogan itu Big NO for Code. Yang baik adalah, Talk More Do Less, hehe

Pertanyaan Untuk Software Developer Team

Sempet baca-baca beberapa buku, menyimpulkan beberapa pertanyaan antara lain:

• If the hard drive on your workstation crashed right now, how much work would you lose?
• would it a take as small amount of time for you to get a new machine up and running for development?
• can you build your entire product With one command?
• can you build your entire product From your Source Code Management system?
• can you build your entire product On any team member’s workstation?
• can you build your entire product With no external environmental requirements?
• Do you have tests in the system?
• Is anyone paying attention to the test system? Are the notifications turned on?
• Does your build get fixed quickly or stay broken for days?
• Does your build finish in a reasonable time?
• Can you generate a list of the top-priority, unaddressed issues?
• How about the second-tier issues?
• Can you generate a list of last week’s fixes?
• Can your system reference the code that fixed the issue?
• Do your tech leads use this system to generate to-do lists for development teams?
• Does your technical support team know how to get information out of the system?
• can you generate the last product version’s “new feature” list by running a report from this system?
• Is your test suite effective? Are your tests catching bugs?
• Is the product you’re testing stable?
• Are the tests being run automatically?
• Do your tests tell you whether they pass or fail?
• Does everyone in your team have the ability to add tests?

Jika jawaban pertanyaan pertama itu "none", kedua dan seterusnya adalah "yes", that team is truely a world-class developer team. Kasih tau gw ya kalo ada perusahaan yang begitu :D

Aniwei, meski Sangkuriang Studio belum seperti itu, tapi akan menjadi seperti itu dalam waktu dekat, Amin Amin

About Component Based Software Engineering

Di bidang elektronik, biasanya terdapat papan untuk ditaruh komponen-komponen seperti resistor, IC, transistor dan lain-lain. Dan dengan rangkaian tertentu, bisa menghasilkan alat yang memiliki fungsionalitas macam-macam.

Senada dengan konsep diatas, pada dunia Software Engineering juga terdapat Component-Based Software. Component itu sendiri dapat diartikan sebagai suatu unit yang executable yang berdiri sendiri dalam hal produksi, akuisisi, dan deployment yang dapat disusun menjadi suatu fungsionalitas.

Hal ini sebenarnya sudah dilakukan. Contoh paling jelas adalah OS. Misalnya Linux. Berikan component tertentu (install suatu program), maka ia akan dapat memainkan lagu dengan format mp3, yang mana pada awalnya tidak bisa. Atau contoh lainnnya Netbeans. Berikan plugin tertentu, dan tiba-tiba ia dapat menjadi tools untuk keperluan UML.

Membangun suatu perangkat lunak dengan memakai konsep component ini memiliki keuntungan yang sangat baik untuk menghasilkan perangkat lunak yang berkualitas. Programming pada dasarnya adalah suatu Art yang terkemas dalam bentuk logis. Sebagai art, memiliki kemungkinan wujud yang tidak berbatas, sedangkan bentuk logisnya mengharuskan ia dapat berjalan dengan sempurna (hei, salah titik ato koma saja, compile error kan? :p). Ketika dua aspek itu bertemu, maka muncullah ketidaksempurnaan yang biasa disebut dengan Bug. Lalu apa hubungannya dengan komponen? extensive testing diperlukan untuk menghilangkan Bug, dan dengan pembangunan komponen, sebelum akhirnya dilepaskan ke pasaran, komponen tersebut sudah di test keabsahannya.

Meski banyak penggunaannya, kenyataannya perkembangan Component-Based Software kurang begitu bagus. Hal ini dikarenakan tidak adanya suatu ketentuan yang menyeluruh akan bagaimana prosedur pembangunan, pembuatan, dan pen-deploy-an suatu komponen, masing-masing vendor memiliki aturannya sendiri. Contohnya Microsoft dengan .Net-nya, Sun dengan Java-nya, Adobe dengan AIR-nya, dan lain-lain, Sehingga menyebabkan bidang Software Engineering tidak memiliki standar baku seperti halnya bidang elektronik.