Catatan – Catatan

Saat ini saya menggunakan m2eclipse untuk urusan per-maven-an pada eclipse saya. Sayangnya, setiap saya menggunakan fasilas yang terkait dengan maven, selalu keluar tulisan “Eclipse is running in a JRE, but a JDK is required“.
Untuk mengatasi hal ini, ketika saya menjalankan eclipse, saya menambahkan perintah -vm, sehingga menjadi eclipse -vm "C:\Program Files\Java\jdk1.6.0_18\bin\javaw
Pada perintah di atas, “C:\Program Files\Java\jdk1.6.0_18\bin\javaw” adalah lokasi JDK saya.

• JSR 303 – Bean Validation
• JSR 299 – Context and Dependency Injection (aka: Web beans)
• JSR 330 – Dependency Injection
• JSR 286 – Portlet 2
• JSR 186 – Portlet 1
• JSR 318 – EJB 3.1
• JSR 220 – EJB 3.0
• JSR 137 – JPA 2.0
• JSR 314 – JSF 2.0
• JSR 252 – JSF 1.2
• JSR 127 – JSF 1.0
• JSR 250 – Common Annotations

Dalam beberapa tahun ini, stack framework utama saya dalam develop project adalah Spring+Hibernate. Saya mulai merasakan kebosanan dalam penggunaan stack ini. Apalagi saya masih menggunakan old style configuration (baca : XML configuration ) . Paling tidak, berikut ini adalah yang harus saya buat untuk develop  :

1. Hibernate Entity
2. HBM file
3.Interface Dao
4. Dao Implement (Hibernate)
5. Konfigurasi XML untuk Dao
6. Interface Service
7. Service Implement (POJO)
8. Konfigurasi XML untuk Service
9. Class  Controller (Spring-MVC)
10. Command class controller
11. Validator controller
12. Konfigurasi XML untuk controller
13. JSP
14. Validasi level view (javascript / JQuery)

14 hal yang harus saya buat too much. Mungkin sudah saatnya untuk menggunakan new style configuration Spring (baca: spring annotation ataupun JSR 330) + JSR 303-Bean validation. Bila menggunakan annotation based + JSR 303, akan ada 6 hal yang hilang dari daftar di atas, menjadi :

1. Entity (JSR 137 + 303)
2. Interface Dao
3. Implementasi Dao (JSR 330)
4. Interface Service
5. Implementasi Service (JSR 330)
6. Controller (dengan annotation)
7. Command class controller + mekanisme JSR 303
8. JSP

Sekarang hanya 8 hal yang perlu saya kerjakan. Lebih sedikit dan lebih cepat. Eits, atau mungkin saya harus sekalian berpindah framework ke JBoss Seam??? hanya perlu :

1. Entity
2. Interface Action
3. Implementasi action
4. xhtml

Wow!!! hanya 4!!! mmmm……

Sebagai developer java, saya hampir setiap hari menggunakan eclipse sebagai IDE saya. Satu yang saya pelajari ketika menggunakan eclipse adalah kita jauh lebih produktif bila kita mulai mengurangi penggunaan mouse dan menggantinya dengan tombol-tombol shortcut.

Berikut adalah beberapa shortcut yang sering saya gunakan :

1. ctrl-shift-f : Format source code
2. ctrl-shift-o : Organize import
3. alt-shift-m : Extract method (refactor)
4. ctrl-1 : Quick fix
5. alt-up / alt-down : Memindah suatu line ke baris atas/bawah
6. alt-shift-w : show in
7. ctrl-pgup / ctrl-pgdn : Pindah window
8. ctrl-f4 : menutup window
9. ctrl-shift-r : Open resource
10. ctrl-t : Membuka type hierarchy
11. ctrl-d : Menghapus sebuah baris
12. ctrl-m : Maximize window aktif
13. ctrl-space : Code completion
14. ctrl-f4 : Tutup window aktif
15. ctrl-up / ctrl-down : Menggeser layar satu baris ke atas/bawah

Ketika kita mendevelop portlet pada liferay, session akan hilang ketika kita login ke dalam liferay.
Session yang hilang karena memang diinvalidate oleh liferay untuk alasan keamanan.
Agar session tidak hilang, kita harus memberikan konfigurasi berikut pada portal-ext.properties :

session.enable.phishing.protection=false

GET :
	formBackingObject
	initBinder
	showForm
	referenceData

POST (wrong POST) :
	formBackingObject
	initBinder
	onBind
	onBindAndValidate
	processFormSubmission
	showForm
	referenceData

POST (right POST) :
	formBackingObject
	initBinder
	onBind
	onBindAndValidate
	processFormSubmission
	onSubmit

Orang berilmu dan beradab tidak akan diam di kampung halaman
Tinggalkan negerimu dan merantaulah ke negeri orang
Merantaulah, kau akan dapatkan pengganti dari kerabat dan kawan
Berlelah-lelahlah, manisnya hidup terasa setelah lelah berjuang

Aku melihat air menjadi rusak karena diam tertahan
Jika mengalir menjadi jernih, jika tidak kan keruh menggenang

Singa jika tak tinggalkan sarang tak akan dapat mangsa
Anak panah jika tidak tinggalkan busur tak akan kena sasaran

Jika matahari di orbitnya tidak bergerak dan terus diam
Tentu manusia bosan padanya dan enggan memandang

bijih emas bagaikan tanah biasa sebelum digali dari tambang
Kayu gaharu tak ubahnya seperti kayu biasa jika di dalam hutan

*Karya Imam Syafii, disalin dari Novel “Negeri 5 Menara” karya A.Fuadi

Perhatikan gambar di atas. Terdapat dua buah lemari, lemari untuk peralatan makan dan lemari untuk peralatan kendaraan. Anda diminta untuk mengambil piring. Secara intuisi, anda akan langsung membuka lemari peralatan makan. Tapi apa yang terjadi ketika anda membuka lemari yang anda buka ternyata isinya sangat berantakan. Piring, mangkok, garpu, sendok, pisau dan lain sebagainya tercampur baur. Yang pasti, anda akan kesulitan dalam mengambil piring-piring itu.

Sekarang, perhatikan gambar berikut

Lagi-lagi anda diminta untuk mengambil piring. Apa yang anda lakukan? anda akan langsung membuka lemari dengan tulisan piring, dan langsung mengambil isinya.

Bila anda ditanya, mana yang lebih mudah? apakah dengan susunan lemari gambar pertama atau dengan susunan lemari gambar kedua? Anda pasti menjawab : susunan lemari gambar kedua.

Mengapa susunan lemari gambar kedua lebih memudahkan kita untuk mengambil isinya? hal itu pasti karena isi dari tiap lemari tidak tercampur baur antara satu hal dengan hal lainnya. Mungkin itu adalah analogi yang mirip dalam pembuatan class.

Beberapa tahun saya sebagai developer dengan beberapa team pernah mengalami kebiasaan team yang berbeda-beda. Tapi yang paling sering saya alami adalah team yang relatif malas untuk memecah class yang besar. Biasanya class-class besar itu paling sering terjadi di layer manager / service. Semua bisnis logic masuk pada layer ini. Parahnya adalah sebuah class manager / service bisa memiliki ratusan (bahkan mungkin ribuan) baris code. Ini sudah pasti menyalahi aturan SRP (Single Responsibility Principle). Sekarang banyangkan bila ada kebutuhan untuk merubah bisnis proses di salah satu class manager. susah. susah. Ini sama seperti kita harus mengambil piring pada gambar pertama. Banyak kesemrawutan dalam class.

Saya mulai berpikir mengapa developer sering malas untuk memecah sebuah class agar mengikuti SRP. Salah satu jawaban yang saya miliki adalah mungkin developer takut dengan jumlah class kecil yang banyak daripada class besar yang sedikit. Mereka mungkin beranggapan bahwa untuk mengetahui bagaimana sesuatu bekerja harus melihat pada banyak class. Mereka lebih memilih untuk membuka sebuah lemari yang semrawut untuk mengambil piring, sendok dan garpu daripada harus membuka tiga buah lemari untuk mengambil piring, sendok, dan garpu.

Mungkin bila kita makan di warteg, kita akan terbiasa untuk melihat mereka mencapur tempat untuk piring, sendok dan piring. Tapi bila kita makan di restoran besar, kita akan melihat mereka selalu memisah-misahkan tempat antara piring, sendok ataupun piring. Lebih rapi. Lebih terorganisir. Dan Lebih cepat untuk mengaksesnya.

Sekarang pilihannya, kita akan memilih metode yang sering dilakukan oleh warteg, ataukah memilih metode yang sering dilakukan restoran?????

Membuat suatu kode program berjalan dengan membuat suatu kode program yang bersih (clean code) adalah dua buah hal yang berbeda. Pada saat develop suatu program, sering kali kita hanya memfokuskan pada suatu titik agar kode program kita dapat berjalan. Kita sering kali lupa (atau pura-pura lupa) bahwa kode program yang kita buat juga harus bersih.

Padahal, kode program yang bersih sangat berpengaruh dalam kecepatan pengembangan program. Berikut ini adalah grafik yang relatif memberikan gambaran clean code vs dirty code

Pada grafik di atas, terlihat bahwa pada awal pengembangan, penggunaan dirty code akan menghasilkan jumlah fitur yang sangat tinggi, sayangnya seiring dengan berjalannya waktu, kecepatan penambahan jumlah fitur mulai berkurang.

Pada clean code, awal pengembangan tidak menghasilkan jumlah fitur setinggi dirty code. Akan tetapi, dan pada suatu titik waktu, jumlah jumlah fitur yang dihasilkan oleh clean code melampaui dirty code.

Dalam pengerjaan suatu project, sering saya dihadapkan dengan 3 hal berikut :
1. Cost
2. Time
3. Feature
Dari ketiga hal itu, kita hanya dapat memilih maksimal 2 dari 3.
Bila kita memilih cost yang rendah dan waktu yang cepat, maka kita pasti mengorbankan jumlah fitur.
Bila kita memilih cost yang rendah dan jumlah fitur yang banyak, pasti kita akan membutuhkan waktu pengerjaan yang lama.
Bila kita memilih waktu pengerjaan yang cepat dengan jumlah fitur yang banyak, pasti membutuhkan cost yang besar.