Thursday, November 30, 2006

Daily log menggunakan Log4J

Jika anda menggunakan Log4J andan menginginkan log file selalu berganti setiap hari, maka ada beberapa solusi yang bisa digunakan.

Pertama, menggunakan class org.apache.log4j.DailyRollingFileAppender sebagai appender. Class tersebut telah ada dalam library Log4J, jadi kita bisa langsung menggunakannya.

Atau menggunakan solusi dari http://minaret.biz/tips/datedFileAppender.html

Kedua solusi tersebut berbeda, jadi anda harus memilih mana yang paling sesuai dengan kebutuhan.

Wednesday, November 29, 2006

Kirim SMS menggunakan MMAP.


Bisnis content untuk telepon selular di Indonesia saat ini sangat besar. Hal ini
membuat perusahaan content provider semakin banyak tumbuh. Perusahaan content
provider bekerja sama dengan operator selular untuk dapat menjakau konsumennya. Di
Indonesia protokol yang digunakan oleh content provider untuk menerima atau
mengirimkan SMS kebanyakan dibuat sendiri oleh operator dan tidak standar.


Operator-operator biasanya menggunakan protokol sendiri dengan alasan kesederhanaan
dan kemudahan. Operator yang menggunakan protokol standar untuk menerima dan mengirim
SMS biasanya menggunakan protokol SMPP. Artikel ini membahas secara singkat tentang
protokol MMAP/SMAP yang merupakan alternatif protokol untuk menerima atau mengirim
SMS antar operator dan content provider.

-= Definisi =-

MMAP (Mobile Messaging Access Protocol) mendefinisikan seatu cara untuk melakukan
pertukaran pesan bergerak (mobile message) menggunakan SOAP. MMAP hanya
mendefinisikan bagain bagaimana koneksi antara dua entitas dan suatu mobile message
dipertukarkan, oleh karenanya MMAP disebut SOAP access framework. MMAP dapat
digunakan untuk melakukan pertukan data XML yang anda buat sendiri, tetapi biasanya
MMAP digunakan sebagai pembungkus protokol SMAP. Format MMAP mengikuti standar SOAP
1.2 dan biasanya menggunakan HTTP sebagai transport protokolnya. MMAP menggunakan
tidak menggunakan model SOAP RPC tetapi menggunakan SOAP messaging model (document
model).


-= SMAP =-

SMAP adalah suatu set XML elemen untuk mengirimkan, menerimana dam me-manage suatu
pesan singkat (SMS). SMAP hanya mendefinikan suatu set XML dokumen (elemen) tapi
tidak mendefinisikan bagaimana XML dokumen tersebut dipertukarkan. SMAP dapat
dimasukan (embed) dalam MMAP sehingga menjadi protokol yang lengkap untuk pertukaran
data SMS.

-= Menggapa menggunakan MMAP/SMAP? =-

Dibandingkan dengan protokol yang dibuat sendiri (proprietary protocol), MMAP
merupakan standar terbuka sehingga memudahkan untuk dikuti semua operator dan content
provider.

Dibandingkan SMPP yang merupakan binary protokol, MMAP lebih mudah dipelajari dan
dibuat implementasinya karena MMAP berbasiskan SOAP (teks). Hal ini juga membuat MMAP
mudah di-debug.

-= Alasan untuk belum menggunakan MMAP? =-

Dibanding proprietary protocol, tentu saja MMAP/SMAP lebih lengkap dan lebih rumit
untuk diimplementasikan. Selain itu, library untuk MMAP/SMAP yang gratis sejauh ini
belum ada. Hal ini berbeda dengan SMPP, library untuk SMPP yang gratis banyak
terdapat di internet sehingga akan memudahkan developer untuk menggunakan protokol
SMPP.


-= Penggunaan MMAP/SMAP =-

Ilustrasi penggunakan MMAP dan SMAP dapat dilihat pada gambar dibawah ini.

-------------------------------
| ,---------. ,---------. |
| | Message | | | | ,----------.
| | center |<---->| SMS | | MMAP/SMAP | |
| | (SMSC) | | Gateway | |<---------->| Aplikasi |
| `---------' | Function| | | |
| | | | `----------'
| `---------' |
| Mobile message service |
-------------------------------

- Mobile center adalah elemen yang bertanggung jawab untuk meneruskan pesan ke tujuan
misalnya nomor telepon selular seseorang.

- SMS gateway function adalah elemen yang memberikan layanan koneksi terhadap
aplikasi atau elemen lain yang akan menggirimkan pesan. SMS gateway function tersebut
bisa jadi telah ada dalam message center (SMSC) sehingga bukan merupakan elemen
terpisah dari message center.

- Aplikasi merupakan elemen yang membutuhkan layanan untuk dapat mengirim atau
menerima pesan. Aplikasi pada diagram diatas biasanya adalah aplikasi eksternal yang
dibuat oleh rekanan dari operator misalnya content provider. Karena MMAP/SMAP
merupakan standar terbuka dan gratis, content provider dapat dengan mudah
menggunakannya untuk mengirimkan atau menerima pesan (content) kepada pelanggannya.

-= Struktur MMAP =-

MMAP memiliki 2 bagian yaitu:

1. MMAP header
MMAP header berisi informasi application context misalnya, session, kontrol akses
(username dan password), billing, dan parameter-parameter lain yang bisa ditambahan.
MMAP header berada pada SOAP header. Contoh MMAP header:

<MMAP:MMAPHeader soap:mustUnderstand="1"
xmlns:MMAP="http://www.smsforum.net/schemas/mmap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/mmap/v1.0
http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd">
<MMAP:ApplicationContext bodyType="Request" sourceOperationReference="123"/>
<MMAP:AccessControl>
<MMAP:ApplicationIdentity>testApp</mmap:ApplicationIdentity>
<MMAP:Authentication>
<MMAP:Password>secret</mmap:Password>
</MMAP:Authentication>
</MMAP:AccessControl>
<MMAP:ServiceContext serviceName="test"/>
</MMAP:MMAPHeader>

2. Request/response MMAP data.
MMAP data berada pada SOAP body yang membawa informasi standar untuk operasi request
dan response.

Fungsi MMAP sebagai access framework yang hanya menspesifikasikan operasi untuk
me-maintain koneksi atau session saja, tergambar dari semua XML data elemen yang
dimilikinya berikut ini:

BindRequest,
BindResponse/BindBackResponse,
BindBack request,
UnbindRequest,
UnbindResponse,
BatchRequest,
BatchResponse,
BatchResult request,
EnquireLink request,
EnquireLinkResponse,
SuccessResponse,
ErrorResponse

Dibawah ini adalah contoh suatu SOAP message yang menunjukan tempat bagian MMAP
berada:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
<!-- MMAP header disini -->
</soap:Header>
<soap:Body>
<!- MMAP data element disini -->
</soap:Body>
</soap:Envelope>

-= Mode Operasional MMAP =-

Ada 4 mode operasional hubungan antar aplikasi dengan message service pada MMAP,
yaitu:

1. Mode Immediate.
Pada mode ini aplikasi tidak menyimpan session untuk koneksifitas dengan mobile
message service. Mobile message service hanya mengirimkan respon hanya jika diminta.
Mode ini dapat digunakan untuk mengirimkan pesan saja. Pesan berada di SOAP body
element dan operasi MMAP tidak diperlukan pada mode ini.

2. Mode client-session.
Pada mode ini aplikasi menyimpan (maintain) session dengan message service dengan
cara mengirimkan bind request. Setiap SOAP message yang kirim berisi sebuah
application context yang mengidentidikasikan session yang dimiliki client.

Proses ini diawali dengan client menggirimkan BindRequest ke message service. Pada
element BindRequest, sessionType parameter pada elemen SessionControl berisi
"client". Message service meresponse dengan membawa informasi session ID pada MMAP
header dan elemen BindResponse pada SOAP body.

Setelah melakukan proses bind, maka client dapat melakukan pengiriman pesan. Mode ini
diakhiri client dengan mengirimkan UnbindRequest ke message service dan message
service akan mengirimkan UnbindResponse pada client.

3. Mode Peer-to-peer
Pada mode ini, aplikasi dan message service melakkan session dua arah (bi-directional
session) sehingga komunikasi dapat dilakukan secara asynchronous. Message service
akan memberikan respon segera setelah menerima pesan dari client. Respon tersebut
hanya mengindikasikan bahwa message service telah menerima pesan. Setelah pesan
diproses makan message service akan mengirimkan respon lagi kepada client.

Proses ini diawali dengan client menggirimkan BindRequest ke message service. Berbeda
dengan mode client-session, pada mode ini sessionType parameter berisi "peer".
Kemudian message service akan meresponse dengan BindResponse dan informasi session IF
pada MMAP header. Selain merespon BindRequest, message service dengan segera juga
akan mengirimkan BindBackRequest ke client. Client atau aplikasi akan merespon
BindBackRequest dengan BindBackResponse dan menginformasikan session ID pada MMAP
header.

Mode ini diakhiri dengan pengiriman UnbindRequest dari client ke message service dan
sebaliknya.

4. Mode batch
Pada mode ini, message service menerimana satu set MMAP request untuk diproses.

Aplikasi mengirimkan BatchRequest ke message service dan direspon dengan BatchReponse
yang menunjukkan request telah diterima. Kemudian message service akan memproses
setiap operasi yang ada dalam batch request. Setelah selesai semua operasi, message
service akan mengirimkan BatchResult request yang berisi status hasil tiap-tiap
proses. Client menerima BatchResult result dan meresnponse dengan SuccessResponse.

-= Contoh =-

Berikut ini adalah contoh pesan MMAP/SMAP lengkap untuk mengirimkan SMS menggunakan
mode immediate:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope
http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
<MMAP:MMAPHeader soap:mustUnderstand="1"
xmlns:MMAP="http://www.smsforum.net/schemas/mmap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/mmap/v1.0
http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd">
<MMAP:ApplicationContext bodyType="Request" sourceOperationReference="123"/>
<MMAP:ServiceContext serviceName="test"/>
</MMAP:MMAPHeader>
</soap:Header>
<soap:Body>
<smap:SubmitRequest xmlns:smap="http://www.smsforum.net/schemas/smap/v1.0"
xsi:schemaLocation="http://www.smsforum.net/schemas/smap/v1.0
http://www.smsforum.net/schemas/smap/v1.0/smap.xsd">
<smap:ShortMessage>
<smap:Header>
<smap:Destination>
<smap:Number>+12345679</smap:Number>
</smap:Destination>
</smap:Header>
<smap:Body>
<smap:Text>Hello world</smap:Text>
</smap:Body>
</smap:ShortMessage>
</smap:SubmitRequest>
</soap:Body>
</soap:Envelope>

-= Penutup =-

Penjelasan yang lebih detail tentang MMAP dapat dibaca pada dokumen spesifikasinya
yang dapat di download dari:

http://smsforum.net/doc/download.php?id=smppv34 (versi 3.4)
http://smsforum.net/doc/download.php?id=smppv50 (versi 5.0)

Untuk implementasi MMAP/SMAP, situs tersebut juga menyediakan file XML schema untuk
MMAP maupun SMAP yang dapat didownload secara terpisah.

Thursday, November 16, 2006

Format file presentasi pada MMS

Beberapa handphone saat ini sudah memiliki fitus pembuatan presentasi sederhana. Presentasi tersebut dapat berisi teks, gambar maupun suara dan kemudian dapat dikirimkan ke handphone lain menggunakan MMS (Multimedia Messaging Service).

Teknologi presentasi pada MMS merupakan standard yang dibuat oleh OMA (Open Mobile Alliance). Teknologi ini menggunakan SIML (dibaca seperti kata smile) yaitu sepesifikasi (rekomendasi) dari W3C.

SMIL adalah singkatan Synchronized Multimedia Integration Language, dari namanya kita tahu teknologi ini menyatukan beberapa atau banyak multimedia resource.Format SMIL seperti HTML, merupakan suatu file teks dengan link yang merujuk ke suatu sumber (resource) tertentu. Resource tersebut bisa teks file, audio, gambar maupun video. Tentu saja untuk mepresentasikan suatu file SMIL dibutuhkan program (client) yang dapat membaca dan memproses file tersebut. Pada komputer destop, program seperti RealPlayer merupakan salah satu contoh SMIL client.

SIML yang digunakan pada MMS adalah subset dari versi asli SMIL karena terbatasnya kapabilitas dari suatu handphone atau mobile device. Oleh karena itu kita hanya bisa membuat presentasi yang sederhana pada handphone.

Contoh suatu file SIML:

<smil>
<body>
<par dur="10000ms">
<text src="deskripsi.txt"></text>
<audio src="deskripsi.rm"></audio>
<img src="deskripsi.jpg"></img>
</par>
</body>
</smil>
</code>

Wednesday, November 15, 2006

Akses CVS dengan SSH tunneling

Dalam tulisan ini saya akan menjelaskan bagaimana menggunakan koneksi SSH untuk mengakses repository CVS dengan menggunakan CVS client. Tulisan ini berdasarkan pengalaman yang telah saya lakukan. Mesin untuk CVS server yang saya gunakan adalah Linux dan mesin yang saya gunakan sebagai client adalah Windows.

Pertama saya install CVS server di mesin Linux kemudian membuat repository. Kemudian setup cvs pserver yaitu membuat configurasi xinetd untuk membuka service untuk cvspserver.

Dengan menggunakan PuTTYgen saya membuat public key dan private key. Dari program tersebut saya dapatkan text untuk dimasukan ke file authorized_key di server, seperti ini:


ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBMFXliQrC16kZwFH1YOl/n3leI5aK13gFYiPFKFSBCFikNzJL5Su9PrJB0fJ7ZgSHKc/2
s+tWaXvfS6yWsGTQ81T49YidfQu/M14QgHTvpe23h8NaBRr+HuxDil0euUnolOcFchXraS5APe+yrqNIKSotGAxpfyPDpXTAZsAgdhQ==
rsa-key-20061115


dan sebuah file yang disave bernama cvsadmin_private_key.ppk

Di server Linux saya dimana CVS diinstall, saya buat user cvsadmin kemudian pada home direktori user cvsadmin saya buat direktori .ssh/ kemdian di direktory tersebut saya but file authorized_key dengan isi seperti contoh diatas.

Kemudian saya buat kofigurasi untuk SSH daemon (sshd) di /etc/ssh dengan cara mengkopi konfigurasi yang sudah ada kemudian memodifikasinya. File konfigurasi yang baru ini saya beri nama sshd_config_ext.

Bagian penting dari isi file configurasi tersebut (tidak semua dicantumkan disini) adalah:


Port 4321
Protocol 2
PasswordAuthentication no
AllowTcpForwarding yes
AllowUsers cvsadmin


Saya menggunakan port 4321 yang tidak biasa dipakai untuk service ssh. Authentication menggunakan password saya set 'no' untuk meningkatkan keamanan karena authentication yang saya buat akan menggunakan key pair yang telah dibuat menggunakan PuTTYgen.

Setelah itu saya jalankan sshd dengan menggunakan file configurasi tesebut:


/usr/sbin/sshd -f /etc/ssh/sshd_config_ext


Di sisi client untuk koneksi ke server CVS menggunakan tunneling, saya menggunakan program PuTTY. Saya buat session baru untuk koneksi ke server CVS. Saya lakukan setting SSH connection pada bagian 'Auth' dengan menspesifikasikan file private key yaitu file cvsadmin_private_key.ppk yang telah saya buat sebelumnya.

Saya juga set SSH connection pada bagian 'Tunnels' dengan menambahkan port forwarding rule. Saya isi source port dengan 2401 yaitu port yang digunakan untuk CVS pserver di server Linux dan saya isi destination dengan '127.0.0.1:2401' yaitu mesin destop saya yang akan saya gunakan untuk development. 2401 adalah standar port untuk CVS pserver.

Hasil yang saya dapatkan setelah menambahkan seting port forwarding tersebut adalah:

L2401 127.0.0.1:2401

Dengan membuat session tersebut di PuTTY, setiap saya melakukan koneksi menggunakan session tersebut maka di lokal mesin saya akan dibukan port 2401. Port tersebut seolah-olah adalah port 2401 di mesin CVS. Koneksi ke mesin CVS sebenarnya tidak menggunakan port 2401 tetapi port 5000 dengan protokol SSH. Inilah tunneling.

Akhirnya setelah saya berhasil melakukan login (koneksi) menggunakan session pada PuTTY, saya dapat menggunakan CVS saya. Yang saya lakukan pada CVS client, dalam hal ini saya menggunakan Eclipse development tool, saya buat koneksi CVS pserver ke localhost port 2401.

Dengan cara seperti ini transaksi dengan CVS server menjadi aman. Server CVS juga dapat dipindah-pindah tanpa perubahan apapun di CVS client.

Thursday, November 09, 2006

Menangani Client: Jangan debat lewat email.

Menangani client memang tidak mudah. Kita perlu memperlakukannya seperti raja karena client adalah sumber pendapatan bagi vendor. Jika client senang terhadap vendor maka loyalitas mereka terhadap vendor pun akan semakin besar sehingga dapat memberikan keuntungan bagi vendor.

Ada pengalaman penting yang saya dapatkan untuk menangani client beberapa hari lalu yaitu jangan debat dengan client lewat email. Komunikasi lewat email memang cukup efektif karena bersifat self-documented dan tidak memerlukan respon yang cepat dibanding komunikasi langsung lewat telepon misalnya. Tapi email kurang bisa mencerminkan nada bicara dan perasaan kita. Emoticon tidak banyak membantu dan dalam hal email resmi, penggunaan emoticon dirasakan kurang etis.

Menanggapi email dari client yang mengarah ke debat apalagi dengan 'nada' yang tidak enak dibaca, sebaiknya tidak dengan emosi dan tidak ditanggapi lagi dengan email. Kontak langsung dengan telepon untuk menjelaskan duduk persoalan dengan nada yang ramah akan lebih baik. Perlakukan client seperti raja, dan jika anda vendor anggaplah anda sebagai patih yang memohon petunjuk pada raja. Setidaknya beberapa hari ini cara tersebut berhasil buat saya.

Wednesday, November 01, 2006

Over-the-air Provisioning Aplikasi MIDP

Provisioning dapat diartikan sebagai membuat sesuatu tesedia. Over-the-air (OTA) provisioning memberikan pengertian proses tersedianya aplikasi MIDP (MIDlet) pada device hingga siap digunakan yang ditransfer lewat sebuah jaringan nirkabel (wireless network). Proses OTA provisioning untuk MIDlet mencakup proses mendapatkan aplikasi (discovery), download, install/update maupun penghapusan (removal).

Pada sisi pengguna, OTA provisioning mempermudah pengguna untuk melakukan verifikasi dan installasi MIDlet. Pada sisi penyedia layanan OTA provisioning memberikan kemampuan untuk memberikan informasi content, melakukan proses pembiayaan (charging) dan lain-lain.

OTA provisioning untuk aplikasi MIDP awalnya merupakan rekomendasi praktis bukan suatu spesifikasi. Rekomendasi tersebut dibuat setelah spesifikasi MIDP 1.0 namun kemudian rekomendasi ini masuk dalam spesifikasi MIDP 2.0 dengan beberapa pembaruan atau tambahan.

Arsitektur sebuah OTA provisioning aplikasi MIDlet terdiri dari:

- Provisioning server

Provisioning server adalah HTTP/Web server yang menyimpan file dan pemroses status hasil provisioning. File yang disimpan adalah file metadata atau java application descriptor (JAD) dan aplikasi MIDP (content) yang berupa file JAR. Content dapat juga disimpan di tempat lain misalnya pada suatu repository server atau content management system (CMS). Provisioning server berinteraksi dengan network elemen misalnya WAP gateway yang menghubungkannya dengan device pengguna. Server ini juga dapat berinteraksi dengan sistem lain misalnya charging/billing server, Authentication Authorization server dan lain-lain.

- Client atau AMS

Application Management Software (AMS) biasa digunakan sebagai istilah untuk software pada sebuah device yang bertanggung jawab untuk mengatur suatu aplikasi misalnya mendownload, menyimpan (install), menjalankan (execution) atau bahkan membuang aplikasi. AMS biasa juga disebut Java Application Manager (JAM) untuk menunjukan software yang bertanggung jawab mengatur aplikasi MIDP pada device.


Proses OTA provisioning dimulai dengan content discovery yaitu proses mendapatkan content dari web server. Pengguna biasanya mendapatkan content dari suatu website atau halaman WAP yang menggandung link ke file descriptor (JAD). Contoh link pada halaman WML:

<a href="http://www.javanensis.net/sample.jad">MIDlet sample</a>


Jika pengguna mengklik link tersebut, AMS (browser) akan mendownload file JAD menggunakan HTTP GET request ke web server.

Web server akan meresponse request dengan memberikan file JAD. File tersebut harus diberikan dengan MIME type "text/vnd.sun.j2me.app-descriptor" pada HTTP response header.

Dibawah ini contoh suatu file JAD yang didapat dari web server:

Manifest-Version: 1.0
Created-By: 1.3.1 (Sun Microsystems Inc.)
MIDlet-Version: 1.0.3
MIDlet-Name: Sample MIDlet
MIDlet-Vendor: Javanensis
MIDlet-1: System Viewer, /icons/system.gif, net.javanensis.sample,SystemViewer
MIDlet-2: Bluethoot Test, , net.javanensis.sample.BluethootTest
MIDlet-Description: Contoh aplikasi MIDP
MIDlet-Jar-Size: 86445
MIDlet-Jar-URL: http://www.javanensis.net/contents/sample.jar
MIDlet-Install-Notify: http://www.javanensis.net/MidpOtaProvisioing.do?file=sample.jar
MIDlet-Delete-Notify: http://www.javanensis.net/MidpOtaProvisioing.do?file=sample.jar
MIDlet-Delete-Confirm: Anda yakin akan menghapus aplikasi 'Sample MIDlet'?


Setelah mendapatkan file descriptor, AMS biasanya melakukan verifikasi dan konfirmasi. Dari informasi yang ada pada file descriptot AMS bisa melakukan verifikasi apakah aplikasi yang akan diinstall sesuai dengan device, atau apakah ukuran file mencukupi untuk diinstall. Sebelum proses dilanjutkan, AMS dapat pula memberikan informasi yang tertera pada file descriptor kepada user dan meberikan konfirmasi kepada user untuk melanjutkan proses download dan install atau menghapus aplikasi jika aplikasi telah ada.

Jika user memilih untuk melanjutkan proses download maka AMS akan mendownload MIDlet (file JAR) dari alamat URL yang tertera pada file descriptor bagian "MIDlet-Jar-URL". Proses download file JAR adalah proses HTTP download. AMS akan melakukan HTTP request ke web server, dan web server akan mengirimkan response yang berisi file dengan MIME type pada HTTP header adalah "application/java-archive"

Setelah proses pengambilan file selesai, AMS akan melakukan installasi di tempat (directory) yang telah ditentukan.

Bila proses installasi selesai, AMS akan memberitahukan ke provisioning server apakah proses tersebut berhasil atau tidak. Pemberitahuan hasil proses provisioning dilakukan AMS dengan mengirimkan HTTP POST request yang bersisi kode status dan pesan ke URL yang tertera pada "MIDlet-Install-Notify" dalam file descriptor.
Contoh pengiriman status:

POST /MidpOtaProvisioing.do?file=sample.jar HTTP/1.1
Host: www.javanensis.net
Content-Length: 13

900 Success


Bila user memilih hapus aplikasi karena aplikasi telah ada. Status proses penghapusan dapat juga dikirimkan oleh AMS ke URL yang tertera pada "MIDlet-Delete-Notify"

Code Description (Status Message)
------ ---------------------------------------------------------
900 Success
901 Insufficient Memory
902 User Cancelled
903 Loss of Service
904 JAR size mismatch
905 Attribute Mismatch
906 Invalid Descriptor
907 Invalid JAR (MIDP 2.0)
908 Incompatible Configuration or Profile (MIDP 2.0)
909 Application authentication failure (MIDP 2.0)
910 Application authorization failure (MIDP 2.0)
911 Push registration failure (MIDP 2.0)
912 Deletion Notification (MIDP 2.0)
913 Required package not supported by the device (MIDP 2.0)

Contoh proses diatas adalah proses yang biasa. Dibelakang layar sebuah provisioning server, penyedia layanan dapat menambahakan proses-proses yang diperlukan misalnya:

- Klasifikasi berdasarkan device pada saat user melakukan discovery
- Autentikasi user menggunakan Basic HTTP Authentication atau menggunakan cookies
- Charging (pembiayaan) pada user
- Tracking

Proses OTA provisioning MIDP ini diadopsi pada cakupan yang lebih luas yaitu Spesifikasi provisioning untuk aplikasi klien J2EE (JSR 124) dan OMA download.

== Spesifikasi provisioning untuk aplikasi klien J2EE

JSR 124 didesain tidak hanya untuk aplikasi MIDP, tapi masih mirip dengan OTA provisioning aplikasi MIDP. JSR 124 lebih kompleks karena menspesifikasikan cara untuk mengirimkan content termasuk packaging, publishing, authentication, policies, adapter, plug-in, konfigurasi device serta API untuk mengakses content repository.
Descriptor yang digunakan pada JSR 124 berupa XML.

== OMA Download OTA

Proses OMA download juga mirip dengan OTA provisioning aplikasi MIDP. OMA download tidak dikhususkan untuk men-download MIDlet atau tipe media spesifik lainnya, tetapi merupakan framework untuk mendownload media object apapun. OMA download juga menambahakan kemampuan untuk menghindari dari pengkopian ilegal suatu content dengan menambahkan spesidikasi Digital Rigth Management (DRM). Content descriptor yang digunakan OMA download berupa XML kecuali untuk aplikasi MIDP descriptor tetap menggunakan file JAD.

Contoh descriptor pada OMA download OTA:

<media xmlns="http://www.openmobilealliance.org/xmlns/dd">
<type>image/gif</type>
<objecturi>http:/foo.bar.com/pic-dir/picture.gif
</objecturi>
<size>1234</size>
<installnotify-uri>http:/foo.bar.com/status</installnotify-uri>
</media>


== Links

MIDP 1.0 OTA recommendation http://java.sun.com/products/midp/OTAProvisioning-1.0.pdf
MIDP 2.0 specification http://www.jcp.org/jsr/detail/118.jsp
J2EE Client Provisioning http://www.jcp.org/jsr/detail/124.jsp, http://java.sun.com/j2ee/provisioning
Deploying Wireless Java Applications http://wireless.java.sun.com/midp/articles/deploy
OMA Download OTA v.1.0 http://www.openmobilealliance.org/release_program/download_v10.html

20061031

Wednesday, October 18, 2006

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.

Monday, September 25, 2006

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.

Friday, July 14, 2006

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.

Thursday, July 13, 2006

SAX Tutorial

-== Pengenalan SAX ==-

SAX (Simple API for XML) adalah API (common interface) untuk memparsing XML dokumen secara event-based.
SAX bukanlah sebuah XML parser. SAX didesain untuk dapat digunakan dengan berbagai macam event-based parser.

SAX tidak sulit dipelajari, karena sifatnya yang simpel.
SAX API cukup kecil, hanya terdiri 35 class/interface yang terdapat dalam 3 package:

org.xml.sax
org.xml.sax.ext
org.xml.sax.helpers

-== Event-based API ==-

Pada event-based API,suatu even akan dilemparkan lewat callback jika parser membaca karakter data atau awal/akhir
dari dokumen maupun element/tag.Kita harus membuat (mengimplementasikan) handler yang akan menangani event. Dengan
event-based API, akses ke XML dokumen menjadi lebih cepat dan sederhana. Juga dimungkinakan untuk memparsing
dokumen yang besar dari memori sistem yang tersedia karena struktur dokumen tidak disimpan dalam memori.

Catatan
Untuk yang belum tahu, selain parser yang event based ada juga parser XML yang DOM based dan pull streaming based.
Ketiga macam parser tersebut dibedakan dengan caranya memproses dokumen XML dan masing masing memiliki kelebihan dan
kekurangan.


-== Beberapa Java SAX2 parser ==-

Xerces http://xml.apache.org/xerces-j/index.html
Sun's JAXP http://java.sun.com/xml/
SAXON XSLT processor http://users.iclway.co.uk/mhkay/saxon/
Oracle XML Developer's Kit for Java http://technet.oracle.com/tech/xml/xdk_java.html
ParserAdapter http://www.megginson.com/SAX/Java/index.html

-== Menggunakan SAX ==-

Untuk dapat melakukan parsing pada XML dokumen kita membutuhkan class yang mengimplentasikan interface XMLReader.
XMLReader bertanggung jawab untuk mem-parsing dokumen XML.
Implemantasi interface org.xml.sax.XMLReader dapat di-instantiate dengan cara:

XMLReader xr = (XMLReader) Class.forName("org.apache.xerces.parsers.SAXParser").newInstance();

atau

XMLReader xr = new org.apache.xerces.parsers.SAXParser();

atau

XMLReader xr = org.xml.sax.helpers.XMLReaderFactory.createXMLReader();

Dianjurkan kita menggunakan cara yang terakhir, karena tidak tergantung pada suatu implementasi parser tertentu.
Dengan cara yang terakhir, XMLReader didapatkan dari class pada saat runtime dengan membaca setting pada:

- System property "org.xml.sax.driver" yang dispesifikasikan pada command line seperti

java -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser JavaProgram

atau pada kode program seperti

System.setProperty("org.xml.sax.driver", "org.apache.xerces.parsers.SAXParser");

- Atau pada file META-INF/services/org.xml.sax.driver didalam JAR file


XMLReader membutuhkan class handler yang harus mengimplementasikan interface berikut:

- ContentHandler yang akan meng-handle jika terjadi event pada saat proses parsing
- ErrorHandler yang akan meng-handle jika terjadi warning/error
- DTDHandler yang akan meng-handle event pada dkumen DTD
- EntityResolver yang akan men jika ada external entities pada dokument XML (misalnya external DTD atau external
parameter entity)


Untuk mengimplementasikan handler diatas sebaiknya gunakan DefaultHandler sebagai base class.
DefaultHandler telah mengimplementasikan keempat interface diatas.
Method signature dari ContentHandler (atau Defaulthandler) yang penting untuk memproses dokumen XML diantaranya:

* void characters(char[] ch, int start, int length)
* void endDocument()
* void endElement(String uri, String localName, String rawName)
* void startDocument()
* void startElement(String uri, String localName, String rawName, Attributes attributes)

Dibawah ini contoh code penggunaan DefaultHandler sebagai base class yang hanya mengimplementasikan method-method
ContentHandler:

public class MyDefaultHandler extends DefaultHandler {
public void startElement(java.lang.String uri, String localName, String qName, Attributes attributes)
throws SAXException {
System.out.print("Start element: URI = " + uri +
", localname = " + localName +
", qname = " + qName +
", attributes = {" );
for (int i = 0; i < attributes.getLength(); i++) {
System.out.print( attributes.getQName(i) + "(" + attributes.getType(i) + ") = " +
attributes.getValue(i) + ", ");
}
System.out.println("}");
}


public void characters(char[] ch, int start, int length) throws SAXException {
System.out.println("characters: " + ch);
}

public void endElement(String uri, String localName, String qName) throws SAXException {
System.out.println("End element: URI = " + uri + ", localname = " + localName + ", qname = " + qName);
}

}


XML memerlukan class InputSource sebagai input dalam melakukan parsing.
InputSource adalah representasi dari XML dokumen yang kemudian di-parsing oleh XMLReader.
XML dokumen dapat berada di lokal maupun remote dan URI digunakan sebagai parameter constructor dari class InputSource.

FileInputStream is = new FileInputStream("C:/Users.xml");
xmlReader.setContentHandler(myDefaultHandler);
xmlReader.parse(new InputSource(is));

-== Perubahan class pada SAX1 ke SAX2 ==-

Saat ini SAX terbaru adalah versi 2, biasa ditulis SAX2 dan SAX versi sebelumnya biasa ditulis SAX1.
Ada beberapa perbedaan antara SAX1 dan SAX2 walaupun demikian parser yang mengimplementasikan SAX1 yaitu class Parser
masih dapat digunakan oleh SAX2, demikian juga sebaliknya.
Dibawah ini adalah table class yang berubah pada SAX1 ke SAX2

-------------------------------------
Class pada SAX1 Class pada SAX2
================= ===================
ParserFactory XMLReaderFactory
Parser XMLReader
DocumentHandler ContentHandler
HandlerBase DefaultHandler
AttibuteList Attributes
-------------------------------------

Parser dari SAX1 dapat digunakan pada sebagai SAX2 XMLReader dengan menggunakan class ParserAdapter

SAX2 XMLReader juga dapat digunakan sebagai XA1 Parser dengan menggunakan class XMLReaderAdapter

-== Contoh kode yang lengkap ==-

public class MyDefaultHandler extends DefaultHandler {

public static void main(String[] args) {
try
FileInputStream is = new FileInputStream("C:/Users.xml");
XMLReaderFactory fact = XMLReaderFactory.newInstance();
XMLReader xmlReader = parser.createXMLReader();
xmlReader.setContentHandler(this);
xmlReaderreader.setErrorHandler(this);
xmlReader.setFeature("http://xml.org/sax/features/validation" ,true);
xmlReader.setEntityResolver(this);
xmlReader.parse(new InputSource(is));
} catch (Exception e) {
e.printStackTrace();
}
}


public void startElement(java.lang.String uri, String localName, String qName, Attributes attributes)
throws SAXException {
System.out.print("Start element: URI = " + uri +
", localname = " + localName +
", qname = " + qName +
", attributes = {" );
for (int i = 0; i < attributes.getLength(); i++) {
System.out.print( attributes.getQName(i) + "(" + attributes.getType(i) + ") = " +
attributes.getValue(i) + ", ");
}
System.out.println("}");
}


public void characters(char[] ch, int start, int length) throws SAXException {
System.out.println("characters: " + ch);
}

public void endElement(String uri, String localName, String qName) throws SAXException {
System.out.println("End element: URI = " + uri + ", localname = " + localName + ", qname = " + qName);
}



}



-== Menggunakan JAXP (versi 1.1) ==-

Pada JAXP, XMLReader dibungkus (wrap) oleh class lain yaitu javax.xml.parsers.SAXParser yang dapat diperoleh dari
factory class yaitu javax.xml.parsers.SAXParserFactory. Dibawah ini contoh kode untuk mendapatkan instance dari class
SAXParser:

SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();

Class SAXParser sudah cukup untuk dapat melakukan parsing pada XML dokumen, yaitu dengan menggunakan method
parse(InputSource, DefaultHandler). Jika menginginkan mendapatkan class XMLReader, kita dapat memanggil method
getXMLReader() pada class SAXParser.

SAXParserFactory adalah class abstract, implementasinya didapatkan dari metode lookup yaitu:

- Menggunakan system property "javax.xml.parsers.SAXParserFactory"
- Menggunakan standar java properties file yang ada di "lib/jaxp.properties" pada direktori JRE
- Menggunakan service API yaitu pada file META-INF/services/javax.xml.parsers.SAXParserFactory di dalam file JAR
- Default instance yang ada pada platform

Friday, July 07, 2006

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

Thursday, June 29, 2006

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.

Tuesday, June 20, 2006

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.

Tuesday, May 23, 2006

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.

Friday, May 12, 2006

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.

Thursday, May 11, 2006

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).

Wednesday, May 10, 2006

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

Tuesday, May 09, 2006

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.

Friday, May 05, 2006

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.

Monday, April 24, 2006

Prinsip Pareto atau prinsip 80/20

Satu nilai lagi yang saya dapat dari Dynamic Systems Development Method (DSDM) adalah Pareto Principle.

Tanpa sengaja minggu ini saya jalan-jalan ke toko buku dan menemukan buku, "Living the 80/20 Way" yang ditulis Richard Koch. Hal ini berarti tepat ketika pada hari yang sama saya baca sebelumnya di Internet tentang prinsip yang sama yaitu prinsip pareto yang digunakan sebagai nilai pada DSDM. Awalnya saya ragu apa yang dimaksud buku tersebut adalah pareto principle yang saya baca di Internet karena di buku tersebut tidak ada penjelasan sejarah tentang prinsip tersebut. Setelah beberapa bagian penting buku dibaca, ternyata itu buku kedua Koch tentang prinsip 80/20. Tidak lama saya menemukan buku pertamanya yaitu "The 80/20 Principle", dan dibuku tersebut dijelaskan mengenai prinsip 80/20 mulai dari awal. Barulah jelas bahwa prinsip yang dimaksud adalah memang prinsip pareto.

DSDM percaya pada filosofi prinsip Pareto ini, seperti yang dinyatakan dalam pernyataan berikut:

"A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that 80% of the solution can be produced in 20% of the time it would take to produce the total solution."

Friday, April 21, 2006

Prioritaskan dengan MoSCoW

Saya belum pernah mempelajari Dynamic Systems Development Method (DSDM), sebuah Agile methology yang banyak dipakai di Eropa (karena memang metodologi ini lahir disana). Tapi proses belajar saya pada Agile methodology, mengantarkan kepada cara memprioritaskan dengan metode metode MoSCoW yang ada pada DSDM.

Methode MoSCoW merupakan cara pembagian prioritas dengan level yang ditentukan untuk suatu kebutuhan (requirement/customer need), fungsi dari produk ataupun bagian dari proyek yang akan dibuat. MoSCoW sebenarnya adalah singkatan dari Must, Should, Can, Won't yang merupakan tingkatan pada suatu item yang diprioritaskan.
  • MUST berarti sesuatu yang harus dimiliki (MUST have this)
  • SHOULD berarti harus dimiliki jika memungkinkan (SHOULD have this if at all possible)
  • CAN berarti dapat dimiliki jika tidak berefek pada yang lain (CAN have this if it does not effect anything else)
  • WON'T berarti tidak perlu dimiliki, tapi mungkin nanti (WON'T have this time but would like in the future)
Pemriositasan sebaiknya dilakukan pada fungsi ditingkat yang tinggi (high level fungtionality) yaitu kebutuhan/fungsi yang belum didetailkan (masih general) misalnya waktu menentukan kebutuhan modul-modul utama pada aplikasi, dan juga pada tingkatyang lebih rendah yaitu kebutuhan/fungsi yang lebih spesifik.

Melakukan prioritas, baik dilakukan untuk menentukan bagian mana yang akan dikerjakan atau tidak, juga untuk menentukan mana akan dikerjakan lebih dulu.Prioritas fungsi atau kebutuhan pada high-level juga membantu kita untuk menentukan yang bagian mana yang merupakan out-of-scope dari project.

Komponen penting yang menjadi pertimbangan prioritas adalah project scope, kualitas, waktu, resources, dan resiko [referensi]. Komponen tersebut bisa saling berbenturan sehingga melakukan prioritas bukan hal yang mudah.

Kadang-kadang project scope tidak didefinisikan dengan detail atau jelas pada saat proyek mulai berjalan. Klien atau customer juga cenderung ingin semuanya kebutuhannya dipenuhi. Hal ini semua menyulitkan kita dalam memprioritaskan kebutuhan.

Dalam perjalanannya, prioritas suatu kebutuhan/fungsi sangat mungkin sering berubah sehingga meprioritaskan kembali (reprioritisation) jangan menjadi hal tabu. Yang perlu diwaspadai adalah banyaknya perubahan prioritas yang drastis misalnya dari level WON'T ke level MUST. Jika hal itu terjadi maka ada sesuatu yang salah dengan awal proses prioritisasi atau tujuan awal (goal) dari proyek.

Gratis: IBM DB2 Express-C Database

Seperti Oracle, IBM juga memberikan versi gratis dari produk databasenya yaitu DB2 Express.
Database DB2 Express-C (community edition) adalah versi gratis dari DB2 Express, bedanya DB2 Express-C hanya boleh digunakan pada mesin sampai dengan 2 CPU dan memory 4 GB saja, dan tentu tidak mendapatkan support komersial dari IBM. DB2 Express-C juga memiliki beberapa batasan fitur dibanding versi yang tidak gratis.

DB2 Express-C is completely "free" to download, develop, deploy, test, run, embed, and redistribute. For more information click here

Dengan adanya versi gratis seperti ini, ISV tidak perlu beli untuk menggunakan dan mempaketkannya bersama software yang dibuatnya. Dan jika konsumen yang membeli software membutuhkan database yang lebih powerfull, maka ISV tinggal memberikan opsi untuk updgrade databasenya ke versi yang lebih besar, dalam hal ini untuk DB2 bisa menggunakan DB2 Enterprise Server Edition (ESE).

Thursday, April 20, 2006

Gratis: Oracle Database 10g Express Edition

Oracle Database 10g XE benar-benar gratis, dan dapat didistribusikan secara bebas. Jadi kita bisa buat aplikasi dan menjualnya dalam satu paket dengan Oracle Database 10g XE.

Hanya saja Oracle edisi ini memiliki batasan seperti yang tertera di situsnya:

"Oracle Database XE can be installed on any size host machine with any number of CPUs, but this free version of the world's leading database will store up to 4GB of user data, use up to 1GB of memory, and use one CPU on the host machine."

Wednesday, April 12, 2006

Feature-Driven Development (FDD)

FDD diinisialisasi oleh Jeff De Luca dan diperkenalkan ke publik lewat buku "Java Modeling In Color With UML" pada chapter 6, "Feature-Driven Development"

** Proses

FDD terdiri dari 5 proses atau aktifitas yaitu:

1. Pembuatan model keseluruhan (Develop an Overall Model)
2. Buat daftar fitur (Build a Feature List)
3. Rencanakan dengan fitur (Plan By Feature)
4. Desain dengan fitur (Design By Feature)
5. Membangun dengan fitur (Build By Feature)


Dan proses tambahan yang tidak kalah penting adalah (Track by Feature)

Domain Walkthough | Design | Design Inspection | Code | Code Inspection | Promote to build

** Best practises

# Domain Object Modeling
# Developing by Feature
# Individual Class (Code) Ownership
# Feature Teams
# Inspections
Inspeksi/review merupakan suatu hal yang penting dalam FDD. [http://www.featuredrivendevelopment.com/node/566]
# Regular Builds
# Configuration Management.
# Reporting / Visibility of Results

UI screen design is not a prototype.

Di perusahaan tempat saya bekerja sekarang, hampir dalam setiap proyeknya selalu membuat prototipe. Prototipe biasanya berupa screen yang dibuat dengan HTML dan javascript. Seiring dengan berjalannya proses requirement gathering dan pembuatan dokumentasi requirement, prototipe tersebut diubah-ubah mengikuti kebutuhan. Prototipe tersebut kemudian di capture dan dimasukan dalam dokumen desain software.

Apa yang client lihat adalah screen capture dari prototipe dalam sebuah dokumen. Client tidak benar-benar bisa menyentuh atau menggunakan prototipe tersebut. Biasanya client tidak jeli (malas) untuk me-review dokumen. Apalagi membayangkan 'flow of process' dari fungsionalitas software dengan hanya melihat screen-capture dan penjelasan teks. Hal ini membuat client setuju untuk mendatangani dokumen tanpa pernah merasakan bagaimana nantinya dia akan menggunakan software tersebut.

Hasilnya setelah software selesai dibuat, bisa terjadi banyak kekurangan-kekurangan yang dirasakan oleh client pada software yang diberikan (deliver). Kita bisa saja berargumen bahwa memang seperti itulah software yang diberikan, telah tertera dalam dokumentasi dan telah ditandatangani. Tapi akibatnya adalah ketidakpuasan client terhadap software yang kita berikan, karena bisa jadi kekurangan yang ada pada software adalah common functionality seperti misalnya fungsi menghapus (delete) pada suatu item.

Hal tersebut bisa terjadi sebenarnya karena prototyping sebenarnya tidak dilakukan.
Kesalahnya adalah:
  • User tidak dibiarkan menggunakan sendiri 'prototype software'
  • Prototipe berubah wujud menjadi UI screen design, karena hanya menjadi screen-capture yang ada dalam dokumentasi.
  • Menggap tanda tangan adalah segalanya (sign-off is everything). Yaitu aggapan selama sudah dokumen sudah ditandatangani maka semuanya yang ada didokumentasi menjadi 'argueable' dan perubahan/tambahan terhadap feature akan menjadi change request.
Oleh karen aitu kita bisa meminimalisasi kesalah tersebut dengan membuat prototipe dan membiarkan user (client) menggunakan prototipe tersebut. Kita sebagai vendor sebaiknya hanya memberikan asistensi saat user mencoba protipe. Kesalahan atau kekurangan pada prototipe akan lebih mudah diterima oleh client dibanding, bugs yang ada pada software yang sudah diberikan atau dirilis.

Tuesday, April 11, 2006

Earned Value Management

Earned value management (EVM) atau earned value analysis adalah metodologi untuk mengukur dan mengkomunikasikan progress dari kinerja suatu project. Varibel penting dalam metodologi ini adalah: waktu (schedule), biaya (cost), pekerjaan (work).

Tujuan yang ingin dicapai dari metodologi ini adalah proyek yang efisien, yang berarti menyelesaikan pekerjaan dengan waktu yang ditelah ditentukan dengan meminimalisasi biaya atau materi yang dikeluarkan untuk proyek. Tujuan tersebut diharapkan dapat dicapai dengan cara mengevaluasi dan mengontrol resiko proyek dengan cara mengukur progres secara berkala.

EVM merupakan hal sudah biasa pada manajemen proyek software. Project Management Body Of Knowledge (PMBOK) memasukan EVM sebagai salah satu alat untuk memonitor proyek. Pada metodologi 'agile' juga sering digunakan earned value analysis dengan menggunakan S-curve atau burn chart sebagai alat monitoring pekerjaan atau biaya yang sudah atau belum diselesaikan.

EVM sebenarnya lebih memberikan petunjuk (guidance) pada cara mengkalkulasi biaya dari suatu project. Dengan perangkat pengontrol yang diberikan EVM diharapkan meningkatkan performance proyek dan mengurangi resiko (risk) yang terjadi.

Earned value analysis menggunakan beberapa variabel untuk memonitor performansi dari proyek yang sedang berjalan. Beberapa variable tersebut adalah:

  • Planned Value (PV) atau budgeted cost of work scheduled (BCWS)
  • Earned Value (EV) atau budgeted cost of work produced (BCWP)
  • Actual Cost (AC) atau actual cost (AC) of work produced (ACWP)

Dari nilai-nilai tersebut dapat dihitung:

Schedule Variance (SV) = EV - PV
Cost Variance (CV) = EV - AC

Cost Performance Index (CPI) = EV/AC
Schedule Performance Index (SPI) = EV/AC


Nilai-nilai tersebut dimonitor selama proyek berjalan dan digambarkan dengan menggunakan grafik seperti ini.


Hasil UAT

Saya baru saja menyelesaikan UAT, dan dibawah ini beberapa kendala yang dihadapi:

  • Software yang masih memiliki banyak bug karena kurang intensifnya internal test.
  • Tim UAT dari client hanya terdiri dari 4 orang dan yang benar-benar terlibat hanya sastu orang.
  • Tester hanya satu orang dan merupakan orang baru (orang yang tidak mengerti betul requirement)
  • Tidak ada kontrol yang ketat dari project owner terhadap tester.
  • Tim UAT dari vendor juga hanya satu orang, yang pekerjaannya adalah mengenalkan software, membantu testing secara teknis dan bug fixing.
  • Tidak ada test scenario, yang ada adalah list modul yang akan ditest.
  • Tidak menggunakan tools untuk test, sehingga retesting memakan waktu yang tidak sedikit.
  • Test dilakukan di tempat client dengan keterbatasan evirontment seperti, tidak tersambungnya komputer development dengan test server.
  • Repository berada di tempat saya bekerja (vendor) sementara development fase kedua yang masih berlangsung ketika UAT fase pertama dapat mengakibatkan perubahan dari code yang dihasilkan dari fase pertama.
  • Birokrasi yang lama di tempat client seperti saat meminta account email untuk test.

Hasil keseluruan: UAT selesai dengan sukses.
Bagaimana bisa? Bisa, kuncinya adalah:
  • Close relationship dengan client. Beri impresi bahwa kita selalu working on improvement.
  • Selalu cepat untuk fixing bug atau solve issues.
  • Jangan tekan client karena keterbatasan-keterbatasan atau problem internal yang mereka hadapi, selama mereka tidak menekan kita.
  • Berikan pengertian, bahwa kendala/masalah tidak hanya datang dari vendor tapi juga dari client. Sehingga mereka tidak selalu menyalahkan kita. (Intinya sih cari alasan yang tepat deh)
  • Jangan memberikan ide-ide baru untuk testing, biarkan apa yang mereka mau test tapi jangan tambah degan item yang seharusnya mereka test.
  • Fokus pada fungsi utama, jika ada bug dan tidak menghalangi test berikutnya, lanjutkan test berikutnya.
  • Restest semua fungsi (secara cepat) saat akhir UAT.

Catatan, sukses disini berarti client happy (paling tidak, mereka tidak kecewa) dan kita sebagai vendor juga akhirnya happy :-)

Saturday, April 08, 2006

Sekilas tentang metodologi pembuatan software, SCRUM

Scrum adalah suatu metodologi yang mengatur (manage) proses pembuatan software.
Scrum yang dikategorikan pada agile software development methodology.
Lihat agile manifesto, untuk mengerti filosofi dibalik kata agile pada konteks software development methodology atau project management.

** Kenapa Scrum?

Scrum menarik karena scrum lebih condong pada cara me-manage proyek secara praktikal (practical process model). Lebih menuntun tim untuk melakukan hal-hal yang perlu dan menyarankan hal-hal yang tidak perlu dalam menginspeksi proses dan melakukan adaptasi terus meneus untuk menyetir arah dari proses. Tidak seperti metodologi manajemen proyek lain yang cenderung deskriptif dan heavyweight.

** Scrum Role
Orang yang terlibat dalam proses scrum dibagi menjadi 3 jenis peran (role), yaitu:
  • Product Owner yaitu orang yang menentukan spesifikasi atau feature dari software yang akan di-deliver.
  • ScrumMaster yang bertanggung jawab untuk mengatur scrum process selama proyek berjalan. Oleh karena itu ScrumMaster harus menguasai Scrum process. ScrumMaster adalah fasilitator, yang mempersiapkan dan memimpin pertemuan (meeting)
  • Project Team (tim 7 plus minus 2) yang merupakan self-organizing team yang menjalankan project, seperti business analyst, software architect, developer, tester dan lain-lain.
** Teminologi ayam dan babi (chickens and pigs)

Terminologi ini dapat dijelaskan dengan lelucon dibawah ini:

A chicken and a pig decide to start a restaurant.
The pig says, "What should we call it?"
The chicken says, "How about 'Ham & Eggs'?"
The pig says, "No thanks. I'd be committed, but you'd just be involved."

Terminologi ayam (chicken) berarti orang yang berkepentingan terhadap proyek (involved) tapi tidak sepenuhnya terlibat dalam proyek.
Terminologi babi (pig) adalah orang yang terlibat sepenuhnya dalam proyek. Yang termasuk dalam kategori pig adalah anggota project team.


** Proses

Proses eksekusi proyek dengan menggunakan scrum, dapat dilihat pada gambar ini

  • First meeting
    • Proses scrum diawli dengan pebuatan tujuan yang akan dicapai dan product backlog.
      Product backlog dikuantisasi waktu dengan satuan hari (antara 1-20 hari)
      Product backlog merupakan ombinasi antara story-based work (pekerjaan yang berbasis use case/product feature) dan task-based work misalnya "Tambahkan validasi pada semua form"
      Product backlog diprioritaskan oleh product owner.
    • Product backlog yang berisi list yang diprioritaskan dari fitur-fitur atau perubahan yang akan ada pada produk.
  • Sprint planning meeting
    • Meeting untuk product owner, scrum team dan orang-orang yg berkepentingan.
    • Menentukan sprint goal yaitu tujuan yang ingin dicapai pada scrum sprint berikutnya (30 hari kedepan).
      Sprint goal biasa adalah minimum fungsinalitas yang harus dicapai.
      Jika sprint goal tidak dicapai maka dilakukan abnormal termination
    • Membuat sprint backlog yaitu list dari pekerjaan yang akan dilakukan selama sprint.
      Sprint backlog merupakan bagian produck backlog yang didetailkan.
      Sprint backlog dikuantisasi waktu berdasarkan jam (bukan hari yaitu antara 1-16).
      Sprint backlog harus tranparan untuk semua orang dalam tim
    • Meeting yang tidak lebih dari 8 jam saja.
      Dengan 4 jam pertama adalah waktu yang digunakan untuk Product Owner menjelaskan atau presentasi tentang prioritas dari product backlog.
      Kemudian tanya jawab dari tim tetang isi, maksud, tujuan dari item yang ada di product backlog.
    • Empat jam berikutnya adalah sesi untuk tim merencanakan Sprint.
    • Fokus pada melakukan pekerjaan bukan berfikir mengenai bagaimana mengerjakannya.
  • Daily Scrum meeting (Inspect and adapt cycle)
    • Meeting harian selama tidak lebih dari 15 menit
    • Yang boleh bicara dalam tim ini adalah scrum master dan anggota tim (pigs)
    • Orang lain yang bekepentingan (chickens) dapat ikut dalam tim tetapi tidak boleh berkomunikasi (berbicara)
    • Scrum master menanyakan 3 pertanyaan dari kepada anggota tim:
      • Apa yang sudah kamu lakukan kemarin (selama 24 jam kebelakang)?
      • Apa yang akan dikerjakan pada esok hari (24 jam mendatang)?
      • Hal apa yang bisa menghentikan pekerjaan besok hari (kendala)?
  • Sprint review meeting
    • Meeting setelah aktivitas selama 2 minggu atau 1 bulanan (Sprint) berakhir, yang kemudian diikuti oleh sprint planning meeting untuk Sprint berikutnya.
    • Meeting sebagai review atas Sprint yang sudah dilaksanakan.
    • Memperbarui (update) sprint backlog yang merefleksikan berapa lama waktu yg dibutuhkan untuk menyelesaikan pekerjaan (task)
  • Sprint retrospective meeting
    • Meeting setelah sprint review meeting dan sprint planning meeting ScrumMaster dengan tim untuk merevisi proses dan cara kerja Scrum, proses development agar Sprint berikutnya lebih efektif dan enjoyable.
    • Meeting ini sebaiknya tidak lebih dari 3 jam.

** Burndown charts

Burndown charts adalah grafik yang menunjukan seberapa banyak waktu yang dibutuhkan untuk menyelesaikan proyek. Grafik ini merefleksikan progress dari proyek.

Y-axis: Sisa waktu yang diperlukan untuk menyelesaikan pekerjaan (dalam jam)
atau jumlah item pekerjaan yang masih harus diselesaikan
X-Axis: Tanggal

Referensi tentang burndown chart yang cukup detail bisa dibaca di artikel "Earned-Value and Burn Charts"

** Artikel lain
Adaptive Project Management Using Scrum.
File presentasi yang bagus tentang SCRUM

Saturday, March 18, 2006

Service provider dalam file JAR

Sejak Java 1.3, suatu file JAR dapat berisi file metadata yang menspesifikasikan service provider class. File tersebut berada di direktori META-INF/services dan disebut sebagai file konfigurasi-profider (provider-configuration file)

Service disini adalah suatu set dari beberapa interface atau beberapa class, dan provider (service provider) adalah implementasi spesifik dari suatu service.

Sebuah provider biasanya sebuah class berfungsi sebagai proxy dari semua operasi yang ada pada sebuah service. Provider haruslah tidak memiliki argumen pada constructor-nya, sehingga dapat diinisialisasi saat pencarian (lookup).

Sebuah provider-configuration file harus memiliki nama sesuai dengan nama (fully-qualified name) dari abstract service class. File tersebut berisi list dari provider-class konkrit yang ada dalam file JAR. Komentar dapat ditambahakan pada file dengan karakter '#'

Sebagai contoh, mari kita membuat sebuah class service pada suatu aplikasi dengan nama com.ejlp.spi.EncryptorProvider yang

memiliki method abstract sebagai berikut:

public abstract Encryptor getEncryptor(String s);


Kita dapat membuat suatu provider dalam file JAR yang terpisah dengan aplikasi dan mengimplementasikan abstract class com.ejlp.spi.EncryptorProvider. Misalnya kita membuat class com.ic.DESEncryptor sebagi provider:

public class DESEncryptor extends com.ejlp.spi.EncryptorProvider {

   public DESEncryptor() {}

   public abstract Encryptor getEncryptor(String s) {
      //...
   }

}


Kemudian pada JAR file kita buat teks file META-INF/services/com.ejlp.spi.EncryptorProvider yang berisi line berikut

#Provider for DES encryptor
com.ic.DESEncryptor


Pada aplikasi yang akan menggunakan provider, kita bisa membuat mekanisme seperti ini:

 static {
     for (Iterator i = Service.providers(EncryptorProvider.class); i.hasNext(); ) {
         EncryptorProvider ep = (EncryptorProvider) i.next();
         registerProvider(ep.class.getName, ep);
     }
 }


 registerProvider(String name, EncryptorProvider ep) {
   //... Add provider to a Map
 }


 Encryptor getEncryptor(String providerName) {
   //... get provider by its name, otherwise get default provider
 }



Links:
JAR File Specification
Bacaan bagus tentang service framework: Introduction to Services Framework

Wednesday, March 15, 2006

JSR 160 (JMX Remoting)

JSR-160 (JMX Remoting)

JMX (JSR-3) mendefinisikan API untuk management aplikasi Java yang bersifat local.
Jika dibutuhkan client yang terkoneksi ke aplikasi Java yang mendukung JMX, maka koneksi dilakukan dengan cara yang tidak standar, biasanaya menggunakan RMI atau HTTP.
JMX remote API merupakan ekstensi dari spesifikasi JMX versi 1.2

Untuk itu dibuatlah JSR-160 yang memperluas JSR-3 yaitu memberikan sebuah standar API untuk koneksi ke suatu aplikasi JMX secara remote.
JMX remoting API terdiri dari package yang harus (mandatory) diimplementasikan dan ada bagian yang tidak mandatory.

Package yang ada pada JSR-160 adalah:

javax.management.remote
javax.management.remote.generic (optional package)
javax.management.remote.jmxmp (optional package)
javax.management.remote.message (digunakan untuk wrapping object yang dikirim dari client ke server)
javax.management.remote.rmi (mandatory package)

*** Connector
Connector (JMX API connector) adalah bagian yang bertanggung jawab untuk mentransmisikan permintaan (request) client ke sebuah remote MBean server.
Connector yang mandatory pada JSR-160 adalah yang berbasis RMI (RMI/JRMP atau RMI/IIOP)
Connector yang tidak mandatory adalah yang berbasis pada:
  • Java serialization (JMX Messaging Protocol/JMXMP) yang disebut Generic JMX API Connector
  • TCP socket protokol lainnya (disebut User-Defined Protocols Connector)
Connector merupakan class yang mengimplementasikan interface javax.management.remote.JMXConnector


*** Connector server
Connector server (JMX API connector server) disisipkan (attach) pada MBean Server (JMX agent) agar connector dapat berinteraksi dengannya.
Direpresentasikan dengan suatu super class: javax.management.remote.JMXConnectorServer
Connector server berasosiasi dengan MBean server dengan cara meregisterkannya pada MBean server atau memberikan MBean server pada constructornya.
Connector server perlu di-start() untuk mulai mendengarkan (listening) koneksi dari client.
Connector server berhenti ketika di-stop() atau akan di-unregister dari MBean Server

*** Pengalamatan
Alamat JMXConnectorServer menggunakan format URL.
URL tersebut digunakan JMXConnector untuk melakukan koneksi ke JMXConnectorServer
Bentuk pengalamannya seperti ini:

service:jmx:://[host[:port]][url-path]

protocol adalah jenis protokol yang digunakan misalnya rmi", "iiop", "jmxmp" atau yang lainnya
Representasi alamat connector adalah class javax.management.remote.JMXServiceURL

*** Contoh

Membuat connector server:

MBeanServer mbs = MBeanServerFactory.createMBeanServer();
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:9999/server");
Map environment = null;

JMXConnectorServer cs = JMXConnectorServerFactory.newJMXConnectorServer(url, environment, mbs);
cs.start();

Membuat connector client:

JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:9999/server");
Map environment = null;
JMXConnector connector = JMXConnectorFactory.newJMXConnector(url, environment);
connector.connect(connectionEnvironment);

// Obtain a "stub" for the remote MBeanServer
MBeanServerConnection mbsc = connector.getMBeanServerConnection();

// Call the remote MBeanServer
String domain = mbsc.getDefaultDomain()

*** Discovery dan Lookup Service

Digunakan untuk 'mengiklankan' (advertise) dan mencari JMX agent
Infrasuktur untuk discovery dan lookup Service ini bisa menggunakan yang sudah ada seperti:
  • Service Location Protocol (SLP)
  • Java Naming and Directory Interface (JNDI)
  • Jini Network Technology


*** Referensi JMX Remote API
JavaTM Management Extensions (JMX) Remote API Overview
JavaTM Management Extensions (JMX) Remote API Tutorial
API Documentation

Semuanya bisa didownload dari pake reference implementation (RI)

Friday, March 10, 2006

Jawaban yang aneh: Maksudnya me-manage apa?

Perusahaan tempat saya bekerja memang tidak besar, maksimum jumlah pegawai yang pernah ada saja tidak pernah sampai 30 orang. Salah satu perusahaan IBM business partner. Bosnya pun mantan pegawai IBM yang mungkin termauk top level employee.

Dalam proposal-proposal yang dibuat perusahaan seringkali mengedepankan RUP (Rational Unified Process) sebagai metode project management. Entah kenapa, mungkin karena Rational sudah merupakan bagian dari IBM sekarang, atau karena mungkin hanya itu metode yang 'mereka' tahu. Yang jelas, dalam setiap proposal yang perlu menjelaskan deskripsi manajemen proyek yang akan dilakukan pasti gambar yang sangat populer ini selalu muncul.

Tapi lucunya, RUP itu hanya ada dalam proposal. Sebenarnya kita sama sekali tidak melakukan manajemen proyek. Hmm.. mungkin kata ini tidak tepat. Proyek tetap di-manage tapi tidak menggunakan framework atau metode tertentu. Kita disini hanya me-manage proyek dengan cara mmm.. susah mencari kata yang tepat. Ciri-ciri manajemen proyek disini jika saya tulis:
  • Semau gue dan semaunya tim. Tim yang berbeda akan memiliki behaviour yang sangat berbeda.
  • Tidak ada tester atau QA at all (yang menjadi tester akan didefinisikan nanti)
  • Tidak ada best practise. Best practise hanya akan ada dalam masing-masing employee. Artinya pengalaman dalam satu proyek bukan menjadi pengalaman untuk proyek yang lain, karena timnya pun sudah berbeda.
  • Kadang-kadang technology minded. Kata-kata "Kita pakai framework X?" hampir sering muncul diawal proyek.
  • Get things done. Yang penting jalan dulu, urusan lambat atau error akan dipikir belakangan.
  • Disini 1 + 1 akan selalu sama dengan 2. Seharusnya jika tim berkolaborasi 1 + 1 bisa sama dengan 4 atau 5 (Kata-kata bijak dari seseorang).
  • Buat schedule bersama-sama, tentukan mandays bersama-sama, coding sendiri-sendiri, bug fixing sendiri-sendiri, maintenance..?? "Kamu yang maintain ya" artinya "Kamu akan bertemu user/client, tau bagaimana jelek atau kurangnya software yang dibuat, tau masalah-masalah yang timbul di production, kamu harus siap diomelin client dan kamu solve semua itu, kalau ada apa-apa kita bicarakan nanti". Berutunglah orang-orang yang tidak ikut maintenance :)
  • Perlu satu atau dua orang yang akan selalu meng-upgrade skill-nya, learn emerging technologies and new product, melakukan prove of concept (POC), mendesain arsitektur software dan menjalan proyek pada saat awal. Orang ini adalah orang tipe pertama, yang setelah pekerjaan orang ini selesai akan dilempar ke orang-orang tipe kedua.
  • Perlu beberapa orang yang siap dicemplungin ditengah-tengah proyek, fixing other people codes, dan (disuruh) jadi maintainer. Orang ini orang tipe kedua yang sayangnya saya termasuk didalamnya :(
Sebagai penutup, jawaban aneh ini mungkin bisa menggambarkan bagaimana manajemen proyek software disini dilakukan: "Maksudnya me-manage apa?"

Jawaban itu terlontar ketika saya bertanya: "Siapa yang akan me-manage fase 2?" Ketika fase - akan berjalan. (Fase atau phase 2 biasanya adalah fase development setelah software dianggap selesai dan bisa dipakai user, fase ini biasanya dilakukan setelah UAT fase-1, fase-2 mempunyai ciri-ciri: kurang dokumentasi, dianggap bukan bagian penting dan tidak didesain dari awal).

Saya harus kembali bekerja. Mungkin topik berikutnya adalah "Bagaimana RUP bisa digunakan untuk proyek kecil" ini akan menarik jika RUP untuk proyek kecil ini dibadingkan dengan agile project management (agile method).

Wednesday, March 08, 2006

Membuat scheduler atau proses periodik

Kita bisa menggunakan Timer seperti ini:


int initialDelay = 30000; // start after 30 seconds
int period = 5000; // repeat every 5 seconds
Timer timer = new Timer();
TimerTask task = new TimerTask() {
public void run() {
// job code here
}
};
timer.scheduleAtFixedRate(task, initialDelay, period);


Atau menggunakan EDU.oswego.cs.dl.util.concurrent.ClockDaemon seperti ini:


static protected ClockDaemon clockDaemon = new ClockDaemon();

static
{
log.debug("Setting the clockDaemon's thread factory");
clockDaemon.setThreadFactory(new ThreadFactory()
{
public Thread newThread(Runnable r)
{
Thread t = new Thread(getThreadGroup(), r, "ThreadDaemon");
t.setDaemon(true);
return t;
}
});
}

public static ThreadGroup getThreadGroup()
{
if (threadGroup.isDestroyed())
threadGroup = new ThreadGroup("Our Threads");
return threadGroup;
}


public static void main(String[] args)
{
int period = 500; //millis
clockDaemon.executePeriodically(
period,
new Runnable() {
public void run() {
System.out.println("Running...");
}
},
true);

}


Atau menggunakan Quartz, job scheduling system.

Tuesday, March 07, 2006

Alternatif untuk Logging framework

Untuk keperluan logging kita bisa menggunakan bermacam-macam framework seperti

Jakarta Commons Logging (JCL)
Log4J
simple-log, A logging anti-framework


Untuk logging yang sederhana, kita bisa gunakan Simple Logging Facade for Java (SLF4J)
yang dibuat oleh pendiri project Log4J, Ceki Gülcü.

Sesuai namanya SLF4J merupakan facade API yang sederhana, inti dari API-nya adalah service provider interface (SPI). Dengan SLF4J, kita bisa berpindah-pindah dari logging framework satu ke logging framework yang lain hanya dengan mengganti file JAR saja.

SLF4J mirip dengan JCL atau juga LogBridge yang dapat diintegrasikan dengan logging framework lainny. Tapi yang saya suka dari SLF4J adalah caranya mengkonstruksi pesan (message) log, yaitu dengan mengubah tanda {}. Seperti kode contoh dibawah ini:

logger.debug("The new entry is {}. It replaces {}.", object, oldObject);
logger.debug("Value {} was inserted between {} and {}.",
new Object[] {newVal, below, above});

Alternatif framework lain untuk logging bisa dilihat di sini

Tuesday, February 21, 2006

Pengalaman pertama menggunakan web testing framework

Beberapa hari ini saya sibuk dengan testing web application. Functional testing tidak rumit karena kebanyakan adalah operasi CRUD (Create Read Update Detele).

Untuk mempermudah testing saya mencoba menggunakan aplikasi/framework yaitu MaxQ dan Solex.

Dibawah ini beberapa fitur yang penting pada kedua aplikasi tersebut.

  • Instalasi yang mudah. [Keduanya]
  • Proxy based recording. [Keduanya]
  • Recording dapat dimatikan dan proxy tetap hidup (runs). [MaxQ]
  • Menggunakan dokumen teks sebagai test case untuk mempermudah perubahan. [Keduanya, Solex menggunakan format dokumen XML]
  • Menggunakan script sebagai test case untuk memudahkan penambahan fungsi otomatisasi misalnya looping, operasi aritmatika, dll. [MaxQ]
  • Script yang mudah/familiar. [Tidak keduanya, mengapa MaxQ menggunakan Python?]
  • Test case dapat disimpan. [Keduanya]
  • Editor yang baik untuk mengubah script. [Solex]
  • Integrasi dengan IDE. [Solex]
  • Maturity (Stabil). [Solex]
  • Hasil HTTP request & response dapat dilihat. [Solex]
  • Fungsi XQuery/Xpath/Regular Expression untuk pencarian string pada response. [Solex]
Saya kira Solex sangat bagus, tapi saya kesulitan mengulang-ulang test case berkali-kali (misalnya pada saat stress test atau input data banyak). Hal ini karena saya harus mengklik tombol untuk menjalankan test case dan tidak bisa menambahakan operasi looping pada test case.

Bagaimana dengan Selenium atau Sahi yang merupakan web testing tool yang terintegrasi pada browser?

Thursday, February 16, 2006

Modeling Maturity Levels: Dilevel mana saat ini disain software anda terdokumentasi?

Dalam buku MDA Explained, Anneke Kleppe dan Jos Warmer, memperkenalkan beberapa level pemodelan software yang mereka sebut Modeling Maturity Levels (MML).

MML ini memiliki enam level pemodelan. Tiap level disa dibilang menunjukan maturity dari tipe-tipe model yang ada. Suatu model dalam hal ini merupakan spesifikasi dari software yang (akan) dibuat dapat berupa dokumentasi abstrak (masih dalam pikiran) ataupun dalam bentuk tulisan ataupun dambar/diagram.

Level-level tersebut yaitu:

  1. MML 0: No Specification
    Tanpa spesifikasi (tidak didokumentasikan)
  2. MML 1: Textual Specification
    Dispesifikasikan dengan bahasa natural (bahasa Indonesia misalnya)
  3. MML 2: Text with Models
    Spesifikasi tekstual dengan ditambah model (diagram) secara garis besar (tidak detail)
  4. MML 3: Models with Text
    Spesifikasi software dengan banyak model yang lebih berperan dengan penambahan deskripsi untuk model tersebut
  5. MML 4: Precise Models
    Spesifikasi dijelaskan dengan model dan bahasa natural. Dengan model lebih dekat dengan source code, perubahan model dapat menyentuh langsung ke perubahan source code. MDA (Model Driven Architecture) mengarah pada level pemodelan ini.
  6. MML 5: Models Only
    Model sangat komplit sehingga bisa membuat source code yang lengkap. Saat ini tidak ada pemodelan yang berdara pada level ini.
Detailnya bisa dibaca di sini

Dokumentasi kode sumber (source code)

Suatu aplikasi atau program harus memiliki dokumentasi yang baik. Membuat dokumentasi tidaklah mudah, apalagi dokumentasi pada API yang mungkin akan digunakan oleh orang lain.

Kita tidak hanya dituntut untuk mengerti bagaimana menuliskan suatu komentar didalam source code, tapi lebih dari itu kita perlu mengerti bagaimana cara mendesripsikan suatu package, class, atau method. Mendeskirpsikan yang baik berarti memberi penjelasan kepada pembaca sehingga pembaca mudah mengerti. Mendeskripsikan suatu bagian dari source code berarti memberikan penjelasan tentang karakteristik dasi suatu bagian source code tersebut. Karakteristik suatu bagian source code dapat berarti menjelaskan:
  • Tujuan atau fungsi
  • Algoritma spesifik yang digunakan
  • Dependencies (Ketergantungan terhadap hal lain misalnya sistem operasi, library, dll)
  • Karakteristik input atau output
  • Informasi exception, security, deployment
  • Penjelasan implementasi (misalnya pada dokumentasi Interface)
  • Referensi ke dokumen lain
Dokumen Requirements for Writing Java API Specifications dianjurkan untuk dibaca karena memberikan penjelasan yang baik dan memberikan contoh-contoh dalam menuliskan dokumentasi.

Dalam perograman Java tentu kita dituntut untuk mengetahui bagaimana menggunakan tool javadoc, dan menuliskan dokumentasi pada source code yang 'javadoc friendly'. Untuk itu kita perlu baca How to Write Doc Comments for the Javadoc Tool

Followers