Hati-hati dengan lisensi software

Gerakan open source adalah hal yang bagus dan telah membuat perkembangan software di negara berkembang, seperti Indonesia ini, cukup cepat. Dunia Java banyak juga diwarnai dengan proyek-proyek free dan open source dan di Indonesia, saya percaya telah banyak juga proyek-proyek komersial yang menggunakan free/open source software yang terdapat di Internet.

Tapi sayangnya karena hukum, terutama yang menyangkut IT, kurang berlaku disini (implementasinya tidak bagus) maka banyak orang menggunakan free/open source software tanpa memperhatikan lisensinya. Ini berbahaya dan budaya yang tidak bagus. Sebagai contoh, banyak orang menggunakan software berlisensi GPL (GNU Public License) untuk keperluan komersial tapi mereka --karena menggunakan untuk software komersial-- merasa produknya benar-benar miliknya, hasil jerihpayahnya sehingga tidak mau memberikan source code-nya ke konsumen/klien. Hal seperti itu tentu saja salah karena GPL mengharuskan baru yang menggunakan software berlisensi GPL juga harus menyertakan source codenya baik itu tertulis atau dalam bentuk soft-copy.

Jadi sudah seharusnya kita membaca lisensi produk open source yang akan kita gunakan. Jika ingin memakai software free/open source, carilah yang memang sesuai dengan lisensi produk yang akan dibuat.

Macam-macam lisensi open source dapat dilihat di website OSI

IT dan birokrasi?

Ada yang salah dengan birokrasi IT?

Ini sekedar share pengalaman, saat birokrasi IT pada suatu perusahaan kadang membuat orang teknis menjadi pusing dan terjepit. Terjepit antara birokrasi dengan masalah yang perlu diselesaikan dengan cepat.

Ekspresi logika

Baru saja saya dapat masalah gara-gara desain user interface (UI) yang kurang fleksibel. Masalahnya bermula dari kebutuhan client akan pembuatan aturan logika untuk keperluan strategi bisnisnya. Aturan tersebut dibentuk dari variabel-varibel yang sudah ditentukan (ada) dan mudah untuk diubah-ubah. Sistem harus membaca aturan logika yang dibuat dan mengeksekusinya. Masalah timbul karena desain UI yang dibuat tidak dapat membuat prioritas pada deretan aturan logic. Contoh yang dimaksud adalah seperti ini:

(a OR b) AND c

Logika "a OR b" akan dieksekusi dahulu, kemudian hasilnya akan di-AND dengan variabel c. Jika aturan tersebut kita tuliskan

a OR b AND c

hasilnya akan berlainan, karena tingkat eksekusi AND (precedence) adalah lebih dulu dibanding OR. Aturan tersebut akan dieksekusi seperti

a OR (b AND c)

Dengan prioritas (tangan kurung) kita akan lebih mudah untuk membuat aturan logika, tapi akan sulit jika tanpa prioritas, apalagi aturannya sudah semakin kompleks atau rumit. Tidak mudah untuk mengubah UI sehingga mendukung prioritas, jadi untuk saat ini client harus membuat aturan logika tanpa prioritas. Jadi tantangannya adalah bagaimana membuat sebuah sebuah ekspresi atau aturan logika tanpa tanda kurung yang ekivalen dengan aturan logika aslinya. Atau dalam kata lain bagaimana kita menghilangkan tanda kurung dalam sebuah ekspresi logika?

Sepertinya belum ada software tool untuk keperluan seperti ini. Sebagai bahan acuan, hukum logika berikut ini (ingat kembali pelajaran SMP) kadang membantu, tapi tidak dijamin..

1. Hukum Komutatif
   a AND b <=> b AND a,
   A OR B <=> B OR A
2. Hukum Asosiatif
   (a AND b) AND c <=> a AND (b AND c),
   (a OR b) OR c <=> a OR (b OR c)
3. Teorema DeMorgan's
   NOT (a OR b) <=> NOT A AND NOT B,
   NOT (a AND b) <=> NOT a OR NOT b
4. Hukum distributif
   a OR (b AND c) <=> (a AND b) OR (a AND c),
   a AND (b OR c) <=> (a OR b) AND (a OR c)

Java Expression Parser (JEP) cukup bagus untuk melakukan parsing pada ekpresi logika boolean. JEP inilah yang saya gunakan sebagai mekanik untuk mengeksekusi ekspresi logika. JEP mendukung prioritas eksekusi dengan tanga kurung, jadi masalah tanda kurung pada masalah saya adalah bagaimana UI dapat dengan mudah membuatnya, artinya perombakan UI. Ini yang saya sesalkan...

AJAX: Web based rich client application

Yang belum tau AJAX artikel "Ajax: A New Approach to Web Applications" merupakan artikel utama yang mempopulerkan teknik ini.

AJAX = Asynchronous JavaScript + CSS + DOM + XMLHttpRequest.

AJAX merupakan sebutan untuk teknik pada aplikasi web yang menggunakan :

• Presentasi web berbasis standar XHTML dan CSS;
• Tampilan dan interaksi dinamis menggunakan Document Object Model (DOM);
• Perukaran dan manipulasi data menggunakan XML dan XSLT;
• Penggambilan data secara asynchronous menggunakan XMLHttpRequest;
• Menggunakan JavaScript sebagai teknologi yang menggabungkan komponen2 tersebut.
  

Keuntungan menggunakan AJAX:

• Lebih efektif, karena beberapa hal :
• Transfer data hanya untuk bagian tertentu yang akan diupdate pada sebuah halaman web sehingga transfer data lebih kecil.
• Beberapa proses cenderung dilakukan di client
• Halaman web lebih interaktif atau responsif
  

Kerugiannya:

• Sangat tergantung pada kompabilitas browser karena menggunakan client side scripting.
  
• Point accessibility bisa menurun karena tergantung pada konfigurasi/kemampuan browser.
• Lebih rumit dari aplikasi web biasa karena banyak menggunakan client side scripting, hal ini bisa diminimalisasi dengan adanya tools, library atau framework. Misalnya menggunakan DWR, JavaScript O Lait
• Effort testing/debugging lebih besar
  

Saat ini pun kelihatannya Sun mulai mengadopsi AJAX sebagai blueprint solusi untuk aplikasi J2EE. Coba baca artikel: Asynchronous JavaScript and XML (AJAX) with Java 2 Enterprise Edition

Website portal tentang AJAX, www.ajaxmatters.com bagus untuk referensi, karena berisi link-link tentang artikel, tutorial, sample code dan lain-lain.

Links lainnya:
JavaScript/ECMAScript Language Specification
ECMAScript for XML (E4X) Specification
Document Object Model (DOM) Level 3 Load and Save Specification

Hati-hati menggunakan Singleton pada aplikasi Java.

Kita biasanya menggunakan singleton class (pattern) untuk keperluan caching, dimana setiap object yang mengakses instance dari singleton class akan mendapatkan nilai yang sama.
Instance dari class singleton hanya akan ada satu dalam JVM, karena pattern ini menghindari pembuatan instance baru jika sudah ada sebuah instance.
Dengan singleton pattern kita terhindar dari meng-create object berulang-ulang.

Tapi kita perlu hati-hati menggunakan Singelton di aplikasi J2EE. Karena ada scalability issue yang harus diperhatikan jika kita menggunakan singleton.

Perhatikan, ada beberapa hal yang membuat Singleton tidak singleton.

Jika aplikasi kita multithreding, ada masalah synchronization yang membuat class singleton menjadi beberapa instances. Yaitu jika pada method yang meng-create instance dari class singleton diakses oleh lebih dari satu thread pada waktu yang --hampir-- bersamaan.

Jika aplikasi kita menggunakan lebih dari satu JVM misalnya pada aplikasi terdistribusi/cluster, bagaimana kita menduplikasi singleton antar JVM?

Singleton biasanya menggunakan "static" keyword, dan ini bisa menimbulkan masalah pada aplikasi J2EE yang menggunakan banyak (lebih dari satu) class loader.

Pada JDK 1.2 virtual machine, singleton dapat di-garbage collection. Karena pada dasarnya instance akan dihapus oleh GC jika tidak ada object lain yang menyimpan reference ke class atau instance tersebut.

Software design: Harus pakai MDA dan UML?

Ini cerita cepat...

Dulu pertama kali belajar UML (Unified Modeling Language) tidak begitu mudah apalagi saya belajar programming bersamaan dengan belajar mendesain software (tentu saja dengan menggunakan UML). Yang saya rasa pertama kali dengan UML adalah bingung, karena terlalu banyak dan saya tidak tahu kalau kita tidak perlu menggunakan semua digram untuk mendesign software atau sistem. Dan yang membuat saya bingung juga adalah kata "Languange" sehingga saya pikir UML seperti bahasa pemrograman. Saya heran kenapa mereka tidak membuat nama dengan "Diagram". Dengan banyaknya jenis diagram dalam UML membuat belajar lebih lama, berbeda ketika mendesain software hanya dengan flowchart atau DFD (data flow diagram) saja.

UML sepertinya berusaha meng-cover semua kebutuhan untuk desain software, bahkan saya pikir malah tidak hanya software, sehingga begitu banyak model yang digunakan.

Kemudian ketika mendesain dengan metode MDA (Model Driven Architecture), ternyata hambatannya adalah sinkronisasi antara kode riil dengan model awal yang kita buat. Kadang-kadang kita bekerja cepat dan efektif dengan menggubah langsung kode program dengan desain yang masih ada di kepala. Saat kita sedang coding kemudian ingin membuat sebuah class, kita kembali ke diagram, membuat kotak, bla bla bla, kemudian kembali ke kode. Proses yang tidak efektif kan? Adalagi dengan masalah code yang di-generate oleh tool MDA yang pernuh komentar atau template-nay tidak sesuai dengan yang kita inginkan. Kita harus belajar lebih banyak dari tool untuk bisa mulai memprogram. Belum lagi masalah harga tool yang mahal.

Fiuhh... apa sih MDA itu? Saya bingung pertama kali saya dengar MDA karena saya pikir MDA itu adalah sebuah high level architecture system, ternyata bukan. Ternyata dengan definisi mudahnya MDA itu adalah metode membuat software dengan menggunakan berfokus pada modeling dahulu kemudian coding. Dengan fokus pada modeling berarti banyak pekerjaan kita adalah modeling, kemudian dengan modeling tersebut kita bisa generate code (menggunakan tools) sehingga model yang kita buat lebih bersifat powerful. Agar model yang kita buat lebih powerful lagi, maka dibuatlah metadata (yang open) sehingga tidak tool spesific. Agar lebih powerful lagi, maka disyaratkan model tersebut harus language-independent atau platform-independent. Dan saya sadar, ternyata saya sudah melakukan MDA tanpa tau kalau metode yang saya pakai itu adalah MDA.

Oke, jangan bingung-bingung dengan cara bagaimana kita membuat software. Begitu banyak metodologi yang kadang-kadang tidak terlalu jauh beda. Dan jangan bingung dengan begitu banyaknya jargon-jargon yang aneh-aneh dan telalu berlebihan. Kita gak sendirian kalau kita tidak mengimplementasikan MDA atau menggunakan UML.

Change request

Ceritanya...

Setelah kita selesai dengan dokumen-dokumen (business requirement, software design & spefication dan lain-lain) yang disetujui oleh client, kita mulai dengan membangun (develop) apa yang tertulis. Tapi kadang apa yang kita desain salah atau kurang tepat sehingga kita harus mengubah software yang telah kita buat. Perubahan juga bisa terjadi karena kesalahan pengertian terhadap bisnis proses atau memang karena proses bisnis yang berubah.

Perubahan bisnis proses akan membuat kita pusing kepala karena harus merubah aplikasi (software) yang kita buat, karena itu diperlukan "change request document" yang berguna untuk mengontrol perubahan selama project yang dapat mengakibatkan perubahan biaya, waktu, resource dan kualitas. Tanpa perjanjian yang jelas pada scope of project dan manajemen dokumen yang baik, perubahan bisnis akan lebih membuat kita pusing kepala. Oleh karena itu dokumen dan pengesahan (approval) terhadap dokumen menjadi penting.

Isi dokumen change request harus menjelaskan secara lengkap tentang perubahan yang terjadi. Komponen-komponen yang penting untuk ditulis dalam dokumen tersebut adalah:

• Requestor, orang yang menginisialisasi perubahan
• Waktu permintaan perubahan
  
• List dokumen yang terkait, dokumen lain yang berubah (document affected) akibat dokumen change request atau dokumen tambahan yang memperjelas
• Detail / deskripsi perubahan
  
• Penyebab perubahan
• Detail analisis
• Hasil evaluasi, keuntungan dan kerugian yang ditimbulkan dari change request
  
• Pengaruh adanya perubahan (impact)
• Pengaruh jika perubahan tidak dilakukan
• Pengaruh terhadap system/modul lain
  
• Solusi yang digunakan
• Perubahan biaya
• Perubahan resource (jumlah orang yang terlibat dalam proyek)
  
• Perubahan waktu pengerjaan (plan)
  
• List reviewer dan approver
• Status dokument, misalnya: Open, Approved for analysis, Approved for implementation, Rejected, Deffered, Closed
• Waktu selesai implementasi
  

Baik juga jika kita menambahakan atribut pengkategorian dari perubahan yang diminta, misalnya pengkategorian impact yang menunjukan seberapa besar pengaruh yang diakibatkan karena perubaha tersebut , scope of change yang menunjukan jenis perubahan, apakah perubahan bisnis, perubahan desain atau perubahan yang lain.

Pengalaman pribadi saya yang membuat "bete" adalah kejadian ketika client meminta untuk adanya perubahan kemudian kita mulai merespon perimtaan tersebut dengan membuka diskusi. Diskusi mulai panas dan memajang dengan pengaruh yang besar disana sini. Saat diskusi kita selalu memikirkan solusi detail yang akan dilakukan, karena client cukup educated maka kadang diskusi sampai pada desain interface secara umum. Kemudian kita mulai membuat dokumen change request berlembar-lembar, untuk memperjelas dibuat juga gambar-gambar dari mock-up screen yang akan dibuat.Cukup melelahkan. Kemudian setelah dokumen selesai kita mulai men-submit ke orang yang berhak melalukan approval. Karena impact-nya cukup besar, cost-nya pun besar, nah dengan mudahnya sang approver me-reject dokumen atau meminta diskusi ulang untuk solusi yang sederhana (solusi yang diambil dengan toleransi proses bisnis disana-sini). Bagaimana dengan kerjaan, waktu yang telah terbuang sebelumnya?? Inilah yang membuat saya "bete". Karenanya step "approved for analysis" sebelum kita mulai panjang lebar mediskusikan perubahan. Tapi ini terjadi pada proyek saya dimana tim bertindak sebagai kosultan tapi juga implementor.