Oracle database link

Oracle database link sederhanya adalah untuk melakukan proses (query) dari saru koneksi database ke database lain. Hari ini karena keperluan tidak sengaja saya membutuhkan database link dan mendapatkan caranya.

Dokumentasinya bisa dilihat disini.

Sebenarnya saya hanya ingin membandingkan dua data dari tabel yang berada pada database yang berbeda. Kasusnya kedua tabel bernama REFERENCES pada schema bernama DATA, yang satu berada di mesin production dengan service name "production" dan satu lagi di mesin yang lain dengan service name "development".

Query yang diperlukan adalah seperti ini:

SELECT description FROM data.REFERENCES@production
MINUS
SELECT description FROM data.REFERENCES@development;

Pertama lakukan koneksi ke mesin development kemudian:

CREATE DATABASE LINK prod_link CONNECT TO data IDENTIFIED BY datapasswd USING 'production';

Setelah selesai matikan session:

ALTER SESSION CLOSE DATABASE LINK prod_link;

Dan hapus database link:

DROP DATABASE LINK prod_link;

Selesai.

Jangan refactor kode orang lain tanpa memberitahukannya.

Refactor adalah pekerjaan yang baik, tetapi jangan lakukan jika refactor menyangkut kode orang lain tanpa memberitahukan detil apa yang telah di-refactor kepada orang yang telah menuliskan kode tersebut.

Refactor yang dilakukan tanpa diketahui orang yang menulis kode tersebut akan menyebabkan produktifitas menurun. Ini karena orang yang menuliskan kode pertama harus mempelajari kembali dan melakukan pelacakan perubahan. Lebih baik lagi jika perubahan selalu diinformasikan kepada semua anggota tim.

Hati-hati dengan progress report dari programmer

Pemimpin proyek atau leader biasanya menggap penting suatu progress report untuk mengetahui seberapa jauh proyek telah selesai, untuk mengetahui apakah proyek on-schedule atau tidak.

Yang salah biasanya progress report dari suatu pekerjaan (task) adalah suatu hal yang imajinatif. Karena penilaian progress akan bersifat individual dan tidak terkuantisasi. Oleh sebab itu nilai progres beruapa prosentasi biasanya tidak mencerminkan keadaaan yang sebenarnya.

Pekerjaan yang akan diketahui progressnya juga kadang-kadang tidak detail sehingga membuat penentuan pekerjaan yang sudah selesai atau belum semakin sulit. Dengan membuat item pekerjaan lebih detail maka penilaian progress bisa dikuantifikasi dengan kata-kata "sudah selesai" dan "belum selesai" atau 0% dan 100%. Angka 50% sepertinya masih baik untuk digunakan tetapi angka-angka lain seperti 35% yang lebih detail sebaiknya dihindari karena rancu.

Kadang-kadang angka progress tidak bisa memcerimankan seberapa lama lagi suatu pekerjaan akan selesai. Misalkan seorang programmer mengerjakan suatu pekerjaan yang dijadwalkan akan selesai selama 5 hari mengatakan progress-nya sudah mencapai 90% ketika hari kedua. Berapa lagi programmer tersebut akan menyelesaikan sisa pekerjaannya yang 10%? Dari angka yang ia bilang kita tidak dapat mengambil kesimpulan. Bisa saja sisa pekerjaan 10%-nya tersebut akan selesai dalam waktu 1 hari, 2 hari atau bahakan lebih dari 5 hari.

Pernah dengar kata-kata bahwa "All marketers are liar"? Mungkin kita perlu mempertimbangkan kalimat itu untuk programmer yang mengatakan progres pekerjaannya. "Programmer selalu berbohong tentang progres pekerjaannya." Itulah kalimat yang perlu kita pertimbangkan, mengapa? Karena hal tersebut terbukti, apalagi jika orang yang menanyakan progres tersebut adalah yang secara organisasi merupakan atasan dan programmer tersebut dinilai dari progres atau pekerjaannya.

Kadang-kadang leader hanya menanyakan progress tanpa detail apa yang sudah dikerjakan dan yang belum dan tanpa pertanyaan soal kendala ayng dihadapi. Sebaiknya progress,detil pekerjaan yang sudah dikerjakan dan yang belum serta kendala dalam pekerjaan dapat diketahui oleh semua tim. Hal tersebut tidak cukup dicapai dengan dengan sebuah shared document atau wiki yang bisa diakses seluruh anggota tim. Hal tesebut bisa dicapai dengan meeting.

JAX-RPC berubah menjadi JAX-WS

JAX-RPC (Java API for XML Based RPC) yang dispesifikasikan pada JSR-101 berubah nama menjadi JAX-WS (Java API for XML Web Services) dengan spesifikasi JSR-224.

Perubahan ini terjadi pada versi JAX-RPC 2.0, setelah JAX-RPC 1.1

Hal ini karena kesalahaan penamaan awal sebab JAX-RPC memberi kesan spesifikasi/library hanya untuk RPC padahal sebenarnya termasuk juga untuk Web Services.

Perubahan mendasar pada versi ini adalah digunakannya JAXB sebagai library untuk databinding.

Katanya dengan JAX-WS dibanding JAX-RPC maka generated code dari WSDL akan lebih sedikit (dalam hal line of code dan tentu saja size/byte) dan coding menjadi lebih mudah.

Tetapi target platform JAX-WS adalah Java SE 5, jadi jangan harap yang masih menggunakan JDK/JRE 1.4 bisa menggunakannya. Pada library ini code yang kita buat dimudahkan dengan adanya annotation yang mulai ada pada JDK/JRE versi 1.5

Seperti versi sebelumnya JAX-WS ini memenuhi standar:

• WS-I Basic Profile 1.1
• WS-I Attachments Profile 1.0
• WS-I Simple SOAP Binding Profile 1.0
  

Yang saya tidak suka adalah, JAX-WS ini akan dimasukan dalam standar library JRE/JDK yaitu pada versi Mustang (Java SE 6). Buat saya seharusnya library ini cukup dimasukan ke spesifikasi Java Enterprise (JEE) sehingga JRE tidak semakin besar dan dipenuhi dengan framework-framework yang bukan inti (core libray).

Component/dependecy analyst

Setelah selesai membuat suatu program/software, ada baiknya Anda lakukan analisis komponen yaitu analisis ketergantungan antar modul atau komponen yang ada pada program/software Anda untuk kemudian anda dapat me-refactor kode program sehingga hubungan antar komponen menjadi lebih teratur (nggak jelimet).

Beberapa aplikasi untuk component/dependecy analyst untuk program Java diantaranya:

http://clarkware.com/software/JDepend.html
http://www.kirkk.com/Main/JarAnalyzer

Kenapa gaji manager lebih besar dari programmer?

Alamat artikel blog ini dikirim teman saya:

Why managers get paid more than programmers??

Buat saya kenapa manager digaji lebih besar dari programmer sudah jelas:

• Budaya: orang yang bekerja membawahi (beberapa) orang akan dinilai lebih tinggi posisinya.
• Tanggung jawab: seharusnya manager memiliki tanggung jawab yang lebih besar dari individu yang berada dibawahnya.
• Tugas manager bukan hanya mengatur orang, tapi dia harus memonitor proses, menganalisis hasil (software yang dibuat) dan memastikan proyek selesai dengan tepat waktu dan biaya yang rendah.
• Me-manage orang bukan berarti mengatur tiap programmer (individu) tetapi juga mengatur kerjasama, komunikasi, hasil dari pekerjaan (artifacts).
• Kadang-kadang manager adalah pemilik saham (owner) yang mengaji programmer-nya. Mana ada owner mau gajinya lebih kecil dari bawahannya.
• Kadang-kadang manager harus berpendidikan lebih tinggi dari bawahannya, walaupun kemampuannya mungkin masih dibawah programmer dan orang yang berpendidikan tinggi cenderung ingin dibayar lebih tinggi karena mereka telah mengeluarkan biaya (modal) yang lebih besar untuk pendidikannya.

Tidak ada masalah jika manager memiliki gaji lebih besar dari programmer, yang jadi masalah adalah kualitas si manager itu sendiri. Kadang-kadang kualitas manager jelek dan yang menjadi kambing hitam tetap saja programmer.

Permasalah requirement.

Dari hasil pengalaman, saya tuliskan dibawah ini beberapa kendala yang terjadi pada saat proses menspesifikasikan requirement:

• Requirement melibatkan beberapa orang dari client yang memiliki pendapat yang berbeda mengenai suatu masalah. Kadang-kadang malah VISI yang mereka punya berbeda-beda.
• Proses requirement tidak melibatkan end user yang benar-benar akan menggunakan software/system yang dibuat.
• Client terlalu sibuk, dikerjar dengan pekerjaan rutinnya shingga meeting untuk requirement terganggu.
• Business analyst menjdi frustasi karena suatu requirement yang telah dibahas panajang lebar di-drop oleh menajer client.
• Business analyst terpatok pada satu cara/teknik requirement gathering yaitu meeting/interview (berdikusi secara langsung dengan user).
• Meeting tidak efektif karena tidak mempertimbangkan siapa saja yang seharusnya hadir dan siapa saja yang seharusnya tidak ikut dalam meeting.
• Manajer yang memiliki kemampuan untuk memutuskan melakukan pengambilan keputusan yang sebenarnya tidak dapat dijalankan secara teknis oleh bawahannya. hal ini bisa terjadi karena sebenarnya manajer tidak mengetahui secara detail bagaimana proses bekerja di tingkat bawah.
• Client yang merupakan narasumber requirement, tidak mengetahui susahnya proses requirement gathering dan tidak mengetahui masalah-masalah yang akan timbul selama proses. Sehingga client mengalami frustasi sebelum proyek selesai.
• Adanya requirement yang tertinggal, biasanya adalah non-functional requirement misalnya adanya SLA (Service Level Agreement) seberapa cepat suatu proses harus selesai. Kadang-kadang business analyst memberikan solusi yang canggih tetapi tidak memikirkan waktu yang dibutuhkan untuk proses tersebut.
• Istilah yang digunakan tiap orang (client) berbeda-beda (lack of communication).
• Client tidak benar-benar mau melakukan review terhadap requirement yang didokumentasikan. Client malas untuk membaca SRS.