Mengapa saya tidak suka BEA weblogic workshop 8

Beberapa bulan ini saya berkutat dengan proyek portal yang menggunakan BEA weblogic workshop. Setelah mendapatkan training, saya baru tau kelebihan-kelebihan dari weblogic workshop. IDE ini mengedepankan kemudahan untuk membuat aplikasi J2EE dengan cara memberikan komponen-komponen yang sudah dibuat. Ini memudahkan kita untuk memakainya dengan hanya click atau click-and-drag. Behind the sceen, IDE ini menggunakan xdoclet, framework Java Page Flow (Struts), Java controls.

Tetapi sebagai development evirontment, saya tetap tidak suka dengan BEA weblogic workshop 8. Beberapa alasan diantaranya yaitu:

• Tidak memiliki fasilitas refactor code. Menurut saya ini fasilitas basic yang perlu dimiliki untuk Java IDE modern.
• Tidak memiliki akses ke kode library yang telah kita buat walaupun library tersebut masih dalam satu Project. Ini membuat kita tidak dapat dengan mudah menuju suatu kode class dari kode class lain yang menggunakannya. Hal ini karena ... baca point berikut ini
  
• Library dalam suatu folder perlu dikompilasi menjadi jar file terlebih dahulu agar library atau applikasi lain dalam satu project dapat menggunakannya.
• Tidak memiliki fasilitas pemformat kode (code beautifier).
• Tidak dapat menjalankan applikasi java sederhana yang memiliki main method. Kita harus deploy di application server untuk dapat menjalankan suatu class sederhana. Ini merepotkan saat kita ingin melakukan test.
• Workshop + application server membutuhkan resource besar dan sering berjalan sangat lambat.
• 
  

Kelihatan simpel tapi menurut saya itu sudah cukup mengurangi produktifitas.

Segalanya berubah, standar pun berubah

Kebutuhan berubah, sehingga standar pun berubah. Sebuah standar pun akhirnya memiliki versi sehingga kadang kita tidak cukup hanya dengan mengatakan kita mengikuti standar A, tapi harus mengatakan bahwa kita mengikuti standar A versi 1.2

Dalam suatu dokumen spesifikasi standar pun biasanya tidak semua harus diikuti. Ada bagian yang dinyatakan _harus_ diikuti atau diimplementasikan tapi kadang ada bagian lain juga yang _boleh_ tidak diimplementasikan. Berhati-hatilah dengan hal tersebut.

Perlukah dokumen desain teknis menjadi deliverables untuk klien?

Terlepas dari klien menginginkan dokumen desain teknis menjadi deliverables (artifak yang diberikan sebagai bagian dari solusi proyek) atau tidak, pelaksana proyek perlu menganalisis penting tidaknya suatu desain teknis di-review oleh client.

Hal pertama yang perlu dipertimbangkan adalah detail tidaknya requirement specification yang dibuat.

Kedua, pertimbangkan apakah klien memahamai benar apa yang mereka inginkan (kebutuhan) atau tidak.

Perhatikan juga apakah klien memiliki kemampuan teknis yang memadai untuk memahami solusi teknis yang diberikan.

Dari analisis ketiga pertimabangan terbut barulah sebaiknya diputuskan apakah desain teknis akan menjadi deliverables atau tidak. Tapi terlepas dari itu untuk keperluan internal desain teknis adalah keharusan, dan sebaiknya terdokumentasi dengan baik.

Pentingnya job description (pada proyek besar)

Proyek disebut besar bisa karena nilai harga proyek atau jumlah orang yang terlibat dalam proyek. Mengerjakan proyek besar memang tidaklah mudah terutama jika proyek tersebut melibatkan banyak orang. Kendala yang dihadapi bisa sangat banyak, mulai dari yang bersifat teknis maupun yang nonteknis seperti mental manusia ataupun hubungan antar manusia.

Masalah teknis bisa mengakibatkan masalah nonteknis karena kecenderungan manusia yang bersifat egois. Untuk itu orang yang bertindak sebagai manager ataupun leader perlu mencermati adanya kecenderungan tersebut. Masalah nonteknis bisa berakibat fatal jika tidak dimenej dengan baik. Awalnya masalah hubungan antar manusia ini cuma akan menghambat jalannya proyek tapi jika membesar konflik yang terjadi akan mengakibatkan gagalnya proyek.

Proyek besar memiliki kemungkinan masalah nonteknis atau konflik antar manusia yang besar pula. Karena itu perlu diantisipasi dari awal. Salah satu antisipasi yang baik adalah dengan memberikan job description yang jelas terhadap setiap orang yang telibat. Tapi perlu diingat, jangan sampai job description menjadi batasan terhadap seseorang untuk mengerjakan hal-hal yang lain yang tidak tercakup dalam job description-nya. Dengan kata lain, jangan sampai sesorang tidak mau mengerjakan sesuatu dengan berkelit hal tersebut tidak termasuk dalam job descriptionnya. Dan sebaiknya manager atau leader memberikan nilai lebih terhadap orang yang telah melakukan tugas diluar dari apa yang tersebut dalam job description-nya.

Dengan adanya job description yang jelas dan disiapkan dari awal maka kita dapat dengan cepat mengevaluasi pekerjaan-pekerjaan apa saja yang belum tercakup dalam job description kemudian dengan segera memberikan tugas tersebut (assign) pada salah satu orang dalam tim.

Update atau insert di ORACLE

Kasus sinkronisasi data pada database sering kali kita hadapi. Kita perlu memasukan data baru atau mengubah/memperbarui data yang sudah ada.

Dalam kasus ini jika kita menggunakan ORACLE, kita dapat menggunakan perintah SQL 'MERGE'. Dengan perintah MERGE kita tidak perlu mengecek data yang ada apakah akan di-insert atau di-update karena data sudah ada.

Dibawah ini contoh query untuk update atau insert ke database yang diimplementasikan pada class PreparedStatement:

MERGE INTO app_user dest
USING (SELECT ? AS userid, ? AS first_name FROM dual) src
  ON (dest.userid = src.userid)
WHEN MATCHED THEN
     UPDATE SET dest.first_name = src.first_name
WHEN NOT MATCHED THEN
     INSERT (dest.userid, dest.first_name)
     VALUES (src.userid, src.first_name) 

Pada query diatas akan dilihat apakah dalam tabel app_user sudah ada userid yang dimasukan dalam variabel pertama (tanda tanya pertama), jika ada maka field first_name akan di-update dengan variabel kedua (tanda tanya kedua) tapi jika tidak ada maka varibel pertama dan varibel kedua akan di-insert pada tabel.