SID/Service name/TNS name untuk Oracle XE

Sudah coba Oracle XE (Express Edition)?

Setelah instalasi saya bingung: SID/Service name/TNS name apa yang digunakan Oracle XE karena saya perlu tau untuk melakukan koneksi dari client menggunakan JDBC driver.

Ternyata Oracle XE menggunakan 'XE' sebagai SID. Ini bisa dilihat di file tnsnames.ora
Jadi kalau kamu pakai Oracle XE dan menggunakan JDBC untuk mengaksesnya, gunakan URL berikut:

jdbc:oracle:thin:@localhost:1521:XE

Jangan terkecoh dengan framework yang menjajikan mengurangi komplesitas koding dan meningkatkan produktifitas.

Sering kali kita dengar janji-janji suatu dari produk atau framework seperti ini: "Reduce Coding Complexity and Increased Productivity".

Ada harga yang harus dibayar untuk itu:

• Jika produk itu tidak gratis kita harus mengeluarkan uang untuk membelinya.
• Jika produk itu gratis kita perlu waktu untuk mempelajarinya.

Kadang-kadang suatu produk/framework hanya akan mempercepat pekerjaan atau meningkatkan produktifitas jika menggunakan tool yang tepat. Misalnya saja Struts atau Spring, dengan banyaknya konfigurasi yang dibutuhkan dalam bentuk file XML, akan menyulitkan developer untuk men-debug atau melakukan tracing jika tidak menggunakan tool/IDE yang memiliki kemampuan untuk memvalidasi file konfigurasi tersebut.

Tulisan ini berkaitan dengan proyek saya sekarang. Proyek yang saya hadapi sekarang akan menggunakan BEA Weblogic. Saya pikir Weblogic hanya sekedar Application Server dan Weblogic Workshop hanya sekedar IDE seperti halnya Eclipse, Netbeans. Tetapi ternyata banyak hal yang saya tidak tau. Weblogic Workshop memiliki framework sendiri, mereka menyebutnya Page Flow dan Control atau Apache Beehive. Dengan menggunakan framework ini pada Weblogic Workshop kita akan berhubungan dengan file-file berekstensi aneh (tidak saya temukan sebelumnya seperti jpf, jcs, jcx), Javadoc annotation, coding menggunakan gambar dan banyak melibatkan mouse untuk klak-klik memilih sesuatu.

Bukan hal mudah untuk bisa menbangun aplikasi menggunakan sesuatu yang baru, apalagi untuk mendesain. Untuk mendesain dengan menggunakan framework baru (yang belum pernah digunakan sebelumnya) akan memiliki resiko yang lebih besar dibandingkan menggunakan framework yang sudah pernah kita gunakan. Jika sudah menggunakan suatu framework kita akan memiliki list of best practice sehingga design akan dilakukan dengan menekankan best practices tersebut dipikiran kita.

Dengan menggunakan framework baru pada suatu proyek maka akan ada proses refractoring yang harus dilakukan pada perjalanan proyek tersebut. Jadi hati-hati lah menggunakan framework yang belum pernah anda gunakan sebelumnya jika tidak ada orang yang berpengalaman yang terlibat pada proyek anda.

Rencanakan dokumentasi anda!

Saat ini aya berada di sebuah proyek software (integrasi sistem) dengan beberapa technical lead, senior architect dan lain-lain. Pada awal proyek telah dijelaskan bahwa akan ada dokumen: requirement specification, functional specification dan design specification. Itu saja.

Setelah requirement spec selesai, saya rasa mereka semua bingung dengan struktur dari dokumen functional spec. Kenapa? saya pikir ini karena tidak direncanakannya dokumentasi yang akan dibuat. Buat saya requirement spec yang telah dibuat lebih menyerupai functional spec. Requirement spec yang kita buat berisi section yang dibagi berdasarkan fungsionalitasnya. Dalam tiap section terdiri dari beberapa sub-section yaitu

• Description yang menjelaskan sedikit mengenai fungsi yang ditulis dalam judul section
  
• Assumptions
  
• Use case diagram yang berisi sequence diagram (dalam terminologi UML), yang memperlihatkan interaksi antar system yang akan dibangun
• Requirements, yang mejelaskan dengan kata-kata diagram yang ada di sub-section sebelumnya atau menjelaskan kebutuhan dengan sedikit mendetail.
  
• Impacts

Bahkan di requirement spec dituliskan :

It also contains a detailed analysis of business, process, functional and operational model in order to provide context and background to the approach.

Bisa dilihat bahwa requirement spec sebenarnya adalah functional spec. Sehingga ketika kita dituntut untuk membuat functional spec yang terjadi adalah kebingung.

Kebingunan bertambah setelah seorang senior architecht yang 'dituakan' mengirimkan contoh functional spec dari project lain yang jelas-jelas di judul dokumen tersebut tertera ".... architectural documentation." Buat saya functional spec sangat berbeda dengan architectural spec.

Itulah sebabnya saya rasa perencanaan terhadap dokumen yang akan dibuat penting. Perencanaan dokumen tidak hanya merencanakan dokumen apa saya yang akan dibuat atau diberikan ke klien tapi lebih dari itu kita perlu merencakan struktur dan isinya.

Perencanaan menjadi penting juga karena biasanya tiap orang yang terlibat dalam proyek memiliki persepsi yang berbeda-beda tentang suatu dokumen. Kita tahu juga banyak sekali bentuk-bentuk dokumen standar yang digunakan dalam software development, misalnya standar IEEE, ISO, atau bahkan standar dari perusahaan. Kita bisa saja menggunakan standar dokumen yang ada tetapi sebaiknya selalu disesuaikan dengan proyek yang dijalankan.

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.