Aplikasi Desktop Menggunakan Arsitektur Three Tier

February 24th, 2010

Beberapa waktu terakhir ini saya cukup banyak memposting topik tentang bagaimana membuat aplikasi desktop menggunakan arsitektur Three Tier. Selama ini aplikasi desktop sebagian besar menggunakan arsitektur Client Server, dimana client akan langsung melakukan koneksi ke database. Konsep ini dipopulerkan oleh Microsoft bersama dengan platform VB. Konsep utamanya adalah meletakkan bisnis proses dan logic aplikasi di dalam server database lewat Stored Procedure dan Trigger.

Belakangan konsep client-server mulai mendapat tantangan dengan berkembangnya jaringan internet. Perusahaan ingin membuat aplikasi desktop namun kantor-kantor cabang tersebar di beberapa tempat, jika masih ingin menggunakan arsitektur client-server lewat jaringan internet, maka banyak sekali pertimbangan keamanan yang perlu diperhatikan, karena membuka port database di jalur internet bukanlah ide yang baik dari sisi security. Masalah lain adalah lisensi, banyak database vendor yang memberlakukan lisensi per user untuk menentukan harga lisensi. Dengan arsitektur client server, setiap client harus menggunakan user yang berbeda sehingga secara drastis menaikkan harga lisensi mana kala ada ratusan client terhubung ke server. Masalah lain yang muncul adalah jika client menggunakan koneksi dialup miskin bandwith, komunikasi client ke server akan sedikit terganggu (corupt).

Selain alasan diatas, alasan performance tuning juga menjadi perhatian kalau menggunakan arsitektur client server. Misalnya clientnya sudah membengkak menjadi ratusan, maka server (database) harus melayani semua client tersebut, kalau database sudah tidak sanggup lagi maka harus beli hardware lebih besar dan migrasi dari hardware lama. Arsitektur Three tier dapat mengatasi hal ini dengan membebankan sebagian pekerjaan ke Server Aplikasi, sehingga database server tidak bekerja sendirian.

Teknologi-teknologi baru semacam cache, hibernate search dapat meningkatkan kinerja aplikasi secara keseluruhan dengan meminimalisasi hit ke database. Dimana database connection sering kali menjadi bottleneck dalam aplikasi dengan ukuran data yang sangat besar. Ukuran data yang besar memunculkan masalah serius, yaitu slow query. Hal ini terjadi karena proses select-join dilakukan dalam table yang berukuran naudzubillah besarnya.

Model Three Tier ini meletakkan server application antara client (swing) dan database, sehingga client tidak langsung konek ke database. Alesanya bernacam-macam, terutama kalau database ada di server yang harus konek lewat internet, nah kalau port database dibuka lewat public IP, bisa dihack server databasenya, makanya client koneknya gak ke database tapi ke application server. Seperti yang saya jelaskan sebelumnya.

Koneksi antara  client ke application server menggunakan protokol yang disebut remoting. Alternatif remoting di java sangat banyak, pilih salah satu alternatif yang sesuai dengan infrastruktur dan kebutuhan. Saya coba bikin matriks perbandingan antara berbagai macam remoting ini deh :

remoting Jenis Remoting Protokol Iteroperability dengan platform lain Implementasi Keamanan Kebutuhan bandwith
RMI Binary TCP socket Hanya aplikasi java EJB, RMI murni Sangat aman, bisa menggunakan JAAS kalau menggunakan EJB Sangat besar, cocok di intranet
RMI Binary TCP socket Java, C++, Python dll Implementasi sudah jarang, nyaris absolete aman Sangat besar, cocok di intranet
Spring HTTPinvoker Binary HTTP Java dan harus pake spring Spring remoting aman Cukup besar, cocok untuk intranet
Hessian Binary HTTP Java dan library hessian Hessian aman Cukup besar, cocok untuk intranet
Hessian Text / XML HTTP Java dan library hessian Hessian aman Cocok untuk internet, karena berbasis text
Webservice Text / XML HTTP Semua platform bisa JAX-WS, Spring WS, Axis2 aman Cocok untuk internet, karena berbasis text
HTTP call with json/XML Text / json / XML HTTP Semua platform bisa. Apache HTTPClient Jakson, JSON lib, tidak aman, harus ada mekanisme security, https misalnya Cocok untuk internet, karena berbasis tex

Pilihan favorit :
1. Aplikasi intranet : Spring Remoting Http Invoker
2. Aplikasi internet : HTTP call with json/XML + Https + Application client certicifate signing kalau aplikasinya critical. Kalau seperti twitter atau facebook sih ga perlu sampe application client certicifate signing.

Implementasi Three Tier

Untuk mengerti implementasi Three Tier, baca blog saya terdahulu mengenai arsitektur three tier dan  perlu dipelajari dulu apa itu remoting, sebaiknya baca blog endy tentang spring remoting dan http invoker.

Kalau anda sudah pernah membuat aplikasi desktop dengan Hibernate dan Spring, sebaiknya langsung saja lihat contoh kodenya.

Persiapan pertama adalah membuat aplikasi desktop dengan menggunakan Spring framework. Proses development tidak ada yang istimewa, lakukan seperti biasa. Dalam proses development ini masih menggunakan arsitektur client server, sehingga tidak perlu repot menjalankan web server seperti tomcat atau glassfish. Development sangat nyaman, cepat dan tidak ribet.

Setelah developement selesai, berikutnya adalah fase deployment. Dalam fase ini barulah kita deploy aplikasi yang sudah dibuat dalam arsitektur three tier. Brilian bukan? develop dengan arsitektur client-server yang ringkas, deploy dengan arsitektur three tier yang robust.

Proses perubahan arsitektur client server ke three tier hanya melibatkan 3 file konfigurasi saja, tanpa ada perubahan sama sekali di kode java-nya.

1. konfigurasi spring untuk expose service menjadi http invoker : server-httpinvoker-ctx.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

<bean id="transaksiServiceHttpInvoker"
class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"
p:service-ref="transaksiService"
p:serviceInterface="org.javadesktop.pos.service.TransaksiService"
/>

<bean id="masterServiceHttpInvoker"
class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"
p:service-ref="masterService"
p:serviceInterface="org.javadesktop.pos.service.MasterService"
/>

</beans>

Dalam konfigurasi diatas kita membuat bean dengan nama  transaksiServiceHttpInvoker dan masterServiceHttpInvoker, kedua bean ini digunakan untuk mengekspose TransaksiService dan MasterService agar bisa diakses dari client yang berada di jaringan berbeda menggunakan remote protokol http invoker.

2. konfigurasi spring untuk client invoke http invoker dr server : client-contex-httpinvoker.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

<bean id="transaksiService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"
p:serviceUrl="http://localhost:8080/javadesktop-server/TransaksiService"
p:serviceInterface="org.javadesktop.pos.service.TransaksiService"
/>

<bean id="masterService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"
p:serviceUrl="http://localhost:8080/javadesktop-server/MasterService"
p:serviceInterface="org.javadesktop.pos.service.MasterService"
/>

</beans>

Konfigurasi di atas diletakkan di client, bean transaksiService dan masterService digunakan untuk mengakses service Spring yang berada di server localhost port 8080.  Kalau servernya berada di tempat lain, ganti localhost dengan alamat IP server.

3. Buat satu Project web, kemudian tambahkan konfigurasi berikut ini di dalam web.xml-nya

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:applicationContext.xml
classpath:server-httpinvoker-ctx.xml
</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<servlet>
<servlet-name>masterServiceHttpInvoker</servlet-name>
<servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>transaksiServiceHttpInvoker</servlet-name>
<servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>masterServiceHttpInvoker</servlet-name>
<url-pattern>/MasterService</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>transaksiServiceHttpInvoker</servlet-name>
<url-pattern>/TransaksiService</url-pattern>
</servlet-mapping>

</web-app>

Konfigurasi web.xml ini digunakan untuk membuat servlet mapping yang memberikan alamat ke bean transaksiServiceHttpInvoker dan masterServiceHttpInvoker agar bisa diakses lewat protokol http dari client.

Penutup

Tulisan ini bertujuan untuk membuka wawasan tentang implementasi arsitektur Three Tier dalam aplikasi desktop. Masih banyak teknik lain dalam implementasi arsiktektur Three Tier. Kalau anda familiar dengan arsitektur aplikasi Java ME yang terhubung dengan Server, anda pasti tidak asing lagi dengan konsep Three Tier.

Tidak semua aplikasi desktop harus menggunakan konsep Three Tier, silahkan disesuaikan dengan kebutuhan masing-masing dan pastikan anda mengerti manfaat Three Tier dibanding Client-Server, beserta kelemahanya. Tidak ada teknologi yang sempurnya.

Semoga bermanfaat.

Optimasi Database dan Performance dengan Hibernate

February 23rd, 2010

Di milis Netbeans-indonesia ada yang bertanya bagaimana caranya mentuning performance aplikasi, terutama database kalau menggunakan Hibernate sebagai backend.

Q : Bagaimana Caranya Menambahkan Index Pada Hibernate sehingga secara otomatis akan ditambahkan ke tabel saya juga?

A : Emang bisa dari Hibernate create index ? Koq saya baca di FAQ-nya[1] koq
ga bisa yah??
[1] https://www.hibernate.org/119.html#A11

A : Tuning itu gampang. Yang sulit dan lama itu profiling, yaitu menemukan bottleneck. Sekali bottleneck ditemukan, google 5 menit juga ketemu cara tuningnya.

Berikut metodologi saya dalam melakukan profiling :

1. Jalankan aplikasi dengan stress test tool, misalnya Apache JMeter.
2. Selama stress test sedang jalan, login ke mysql dan jalankan show processlist berkali-kali. Nanti akan keliatan query mana yang makan waktu lama.|
3. Pilih query yang waktunya paling besar.
4. Jalankan explain select untuk query tersebut untuk melihat bagaimana MySQL menjalankan query tersebut.
http://dev.mysql.com/doc/refman/5.0/en/explain.html

5. Lakukan tuning yang sesuai, misalnya:
- tambahkan index di kolom2 yang sering dipakai di where dan order by
- samakan tipe data dan length untuk kolom2 yang sering dijoin
- ubah urutan join
- perbaiki query-nya di source code aplikasi

6. Kembali ke #1 dan lakukan terus sampe performance-nya acceptable. Gak perlu kenceng, yang penting acceptable.

A : Cuma mau nambahin, langkah-langkah diatas bisa kita  otomatis-kan dengan menggunakan tool namanya *MySQL Monitor*[1] tapi  sayangnya ini berbayar, tapi ga masalah kan klo sekedar utk 7an
profilling diatas, kita bisa register utk dpt trial 30 hari :)

Jadi gunakan waktu 30 hari dengan sebaik-2xnya :D
[1] http://mysql.com/products/enterprise/monitor.html

A : Ups..ketinggalan, ini ada tool juga yg fitur-nya hampir sama ama MySQL Monitor, namanya MySQL Proxy[1] dan ini fitur yg dibawa :
MySQL Proxy is a simple program that sits between your client and MySQL server(s) that can monitor, analyze or transform their communication. Its flexibility allows for a wide variety of uses, including load balancing; failover; query analysis; query filtering and modification; and many more.

Hm… mangstab gan :) :D
[1] http://dev.mysql.com/downloads/mysql-proxy/

Q : btw, boleh tanya kenapa harus bikin bean dulu baru generate ke table, knp ga bikin table dulu di database baru tarik jadiin bean, bukankah dengan begitu, index dan sejenisnya bisa di set tanpa harus tergantung dgn Hibernate??
A : Hanya gaya development saja, dari dua arah bisa dilakukan. Jadi tidak ada alasan khusus, cuma alasan kenyamanan saja ;).

Saya pribadi lebih memilih jalan tengah, untuk proses generate DDL lebih bagus hasil buatan Hibernate daripada buatan saya manual, soalnya Hibernate sangat teliti dalam membuat foreign key, unique constraint dan seterusnya.

Kemudian kalau index dipasang manual karena hibenarnate gak support. Mungkin hibernate tidak bisa menebak mana table yang akan berkembang besar mana yang tidak. Sehingga proses tuning diserahkan ke system engineer / programmer yang tahu mana data besar yang perlu tuning.

A : Kalo di MySQL, beberapa hal yang harus dilakukan setelah hbm2ddl :
1. Tambah index
2. Refine maxlength, misalnya varchar(255) dijadikan varchar(10)
3. Kolom untuk data enum yang tadinya varchar diganti jadi enum.
Q : ada cara lain untuk tuning performance tanpa menggunakan index?
A : Ada juga proses Tuning dengan hibernate tanpa melibatkan tuning
Database, caranya dengan :

1. Hibernate Second level cache

Hibernate mempunyai level 1 cache yang aktif secara otomatis dan gak bisa dinonaktifkan, level cachenya adalah transaction. Jadi cache akan dihapus setelah 1 transaction selesai.

Misalnya dalam satu transaksi kita bikin query yang melibatkan select user berkali2 atau select systemparameter berkali2, maka select ke 2 akan diambilkan dari cache, tidak hit database sama sekali. Tapi ketika transaction selesai maka cache ini akan dibuang.

Second level cache secara default tidak diaktifkan, harus ada konfigurasi tambahan di hibernate.conf agar level2 cache aktif. Library untuk cachenya pun bisa bermacam2, defaultnya sih ehcache.

Contoh penggunaanya misalkan ada data produk yang tidak sering berubah tapi sering banget dibaca. Bikin konfigurasi untuk mengkaktifkan cache level2 dan daftarkan entity produk ke dalam konfigurasi. Settingan
level2 cache pun bervariasi, kita bisa load semua data dalam table produk ke memory (cache) atau hanya sebagian saja menggunakan algoritma LRU atau FIFO.

Perlu diwaspadai bahwa cache ini harus ada proses invalidate-nya, semua proses update insert atau delete harus lewat Hibernate, kalau ada proses lain yang menginsert data dari belakang, maka hasil insert ini kemungkinan tidak masuk cache kalau kita gunakan metode load semua table ke memory (cache). Kalau ada proses lain yang insert data, maka gunakan algoritma LRU atau FIFO agar kalau data produk tidak ketemu, cache harus lihat ke database baru bilang datanya gak ketemu.

Hal lain yang perlu diwaspadai adalah kalau aplikasi jalan menggunakan Client server, dimana setiap client punya sessionfactory sendiri2, nah arsitektur ini gak memungkinkan adanya proses caching yang efisien,
karena setiap client punya cache sendiri-sendiri. Jalankan aplikasinya dalam arsitektur 3-thier baru deh kerasa cache-nya.

2. Hibernate Search

Proses penampilan data transaksi biasanya dilakukan dengan mengambil data langsung ke database (select), dengan adanya hibernate Search, data transaksi diletakkan di tempat lain dalam bentuk hashset,
sehingga setiap kali aplikasi akan menampilkan data dalam bentuk table, datanya diambil dari hibernate search, tidak ambil data ke table.

Proses pencarian data menggunakan fulltext search, bukan lagi select-from-where. Indexing fulltext search menggunakan apache lucene yang sudah integrate dengan hibernate seach. Ketika user mengklik
salah satu barus dalam table, barulah hit database untuk mendapatkan data full-nya. Kelemahanya adalah data dalam table tidak langsung up-to-date, ada jeda beberapa detik sebelum data yang ada di database
(table) diindex ke hibernate search.

Di aplikasi yang sedang saya kerjakan sih metodenya begitu, agar hit databasenya berkurang ketika menampilkan table (inbox). Masalah terbesar di database adalah ketidak mampuanya untuk scalable secara
horizontal. Kalau database dah pusing dihit sama aplikasi ya harus beli lebih besar lagi. Sedangkan Hibernate Search bisa diletakkan dalam lingkungan cluster dengan menggunakan SAN atau dengan
Distributed file system seperti HDFS dan GFS. Dan sekali lagi, tidak bisa jalan di arsitektur Client server, harus pake 3 thier setidaknya.

Q : Saya tertarik dengan Hibernate Search,  apakah bisa dijelaskan lebih detail lagi mengenai Hal ini?
A : Hmm, biar dijelaskan lebih lanjut sama yang bikin Hibernate Search : Emmanuel Bernard
http://www.manning.com/bernard/
;)
Salam

SOP dan pembagian kerja di software house

February 23rd, 2010

Beberapa hari ini ada diskusi seru di milis JUG-indonesia, ada salah satu member JUG yang bertanya bagaimana membuat software house dan melakukan pembagian kerja. Dari satu posting berkembang menjadi panjang lebar sampai puluhan email dalam thread ini. Saya tergelitik untuk merangkup thread tersebut menjadi satu sesi QA agar lebih terurut informasinya.

Nah silahkan menyimak serunya thread ini :

Q : Ada yang bisa share gak gimana SOP dari software house tempat teman-teman? Gimana workflow-nya, dan pembagian tugasnya. Kapan sih orang management dan akuntansi dilibatkan dalam project?

A : Kalo di kantor, qta ada 1 orang head developer, dia yang me-manage proyek dari awal sampe akhir. Ada 1 orang analis + desainer aplikasi (database + modul2), trus ada programmer, trus ada tester/qc

Kalo dulu kerja bareng sama temen, kita bagi2 tugas siapa yang analisis + desain DB, sapa yang bikin SP, Trigger, View, sapa yang bikin front end.

A : Life Cycle project itu kira-kira gini :

1. Cari kabar dimana ada yang perlu aplikasi
2. Kalau ada, janjian untuk mendengarkan requirement
3. Menunjukkan bahwa anda bisa mengerjakan aplikasi sesuai
requirement. Caranya :
- paling gampang tunjukkan portofolio aplikasi yang pernah dibikin
- Paling efektif tunjukkan produk yang sesuai dengan requirement (ini agak sedikit mustahil)
- Presentasikan kembali requirement dalam bahasa yang sedikit lebih teknis
- Presentasikan SDLC dan proses pengembangan aplikasi di perusahaan anda. Gimana requirement gathering, prototyping, demo sampai ke user acceptance test (UAT). Trus garansi, change request management.
4. Biasanya point 2 dan 3 bisa dalam satu sesi meeting, tapi lebih sering sesi 3 dilaksanakan beberapa hari setelah sesi 2
5. Setelah point 3 disetujui biasanya sih ada proses nego harga dan termin pembayaran. Usahakan di termin pembayaran ada DP dan ada step2 pembayaran yang berdurasi pendek, misalnya setiap satu modul selesai dibayar sekian persenya.
6. kalau deal baru mulai developmet.
7. Requirement gathering dengan mewawancara client dan user yang akan menggunakan aplikasinya. Kemudian minta segala macem form, data, dokumen yang di print beserta semua dokumen bisnis.
8. Mulai develop
9. Demo setiap modul, jangan sampai demo di akhir saja untuk semua modul, kalau ada perubahan bisa berdarah2. Release often release fast.
10. Sign off modul yang udah disetujui, minta dibayar :D
11. Implementasi, biasanya ada proses migrasi data dari sistem lama atau dari excell kalau masih manual.
12. Bug fix dan maintenance
13. closing
14. makan2, jangan lupa saya ditraktir :D

Kalau saran saya sih ya, daripada memulai usaha menjadi software consultant mending mulai usaha untuk bikin web 2.0 service, kalau belum bisa secanggih facebook ya bikin seperti kaskus aja tuh, simple aja, install vbuletin :D. Atau bikin produk seperti accurate, zahir dan software untuk pendidikan ;)

Software consultant yang 100% bergantung kepada project base itu sangat rentan, model bisnisnya nggak survive, karena semua usaha kita ujung-ujungnya hanya menghasilkan upah, artinya kita jadi kuli aja. Berbeda halnya kalau km bikin produk, nanti kalau produknya sudah mapan, income tidak lagi bergantung pada berapa baris kode yang kita buat tapi berapa banyak lisensi yang kita buat. Nah kelihatan kan bedanya? kalau konsultant kita dibayar karena keringat yang kita keluarkan, tapi kalau bikin produk ya yang “nyari duit” produk kita. Jadi jerih payah kita terakumulasi ke produk tersebut, nggak bayar lepas seperti project ;). Saya lihat bisnis model seperti ini cukup terbuka dengan adanya apple app store, bikin aplikasi kecil2 dijual

$1, sebulan kejual 600 buah aja udah cukup lah ya ;) Model bisnis lain yang cukup bagus adalah membuat “service” yang banyak digunakan orang dan bisa kita jual ke pengiklan, seperti detik.com, kaskus.us, indowebster.com dll. Kelemahanya ya butuh investor sih, harus ada yang bayarin bandwith, infrastruktur dll. Di US sana ada ycombinator.com/faq.html yang mau nalangin, di indonesia masih blom ada sepertinya :(.

Bisa juga model bisnis “komisi per transaksi” seperti ATM bersama, atau bikin software loket pembayaran PLN, atau bikin marketplace yang transaksinya dikenakan fee. ;)

Bisnis model yang bagus tapi agak susah diimplementasikan adalah software as service (SAS) dengan model subscription, untuk mendapatkan layanan dari aplikasi tersebut, customer perlu membayar sekian rupiah
per satuan waktu (bulan, tahun). Di indonesia yang sudah jalan sepertinya http://www.asianbrain.com, cuman lebih ke jualan konten dibanding jualan layanan software. Di luar sana yang terkenal ya
salesforce.com, google application, http://www.fogcreek.com/FogBUGZ/. Bayarnya per user ;)

A : Pembagian perand dalam tim pengembangan perangkat lunak :
1. Tukang nanyain user apa yang mau dibikin
2. Tukang coding level jago, supaya bikinnya gak sembarangan
3. Tukang coding level pemula, supaya ada yang disuruh2 bagian coding yang boring seperti validasi, geser2 tombol, pasang icon, dsb
4. Tukang ngetes
5. Tukang ngurusin hal2 lain supaya tukang no. 1 sampe 4 bisa kerja dengan nyaman Misalnya: reimburse taksi, janjian meeting sama client, laporan progress ke client dan ke bos, cari pengganti kalo ada yang sakit/resign/cuti/dipecat, mengucapkan, “You’re fired” kalo ada yang gak bener
6. Tukang tagih invoice kalau sudah tiba masanya

Versi keren :
1. Business Analyst
2. Software Architect
3. Programmer
4. Tester
5. Project Manager
6. Biasanya sih dikerjain sama no. 5 juga

A : Kalo pengalamannya nol semua rada ribet ya… kalo mau n niat, bisa bikin pake tipe prototipe.
1. Tentuin mo bikin apa, scopenya sampe mana.
2. Kumpulin requirementsnya
3. Desain aplikasi + bikin prototipe
4. Menta komentar dari user, biasanya di sini user bikin ribet, ada requirements yang sebelomnya diomongin tau2 ada. Hal2 gaib terjadi di sini, makanya siapin dokumentasi requirements.
5. balik ke nomer 3, kalo user setuju, aplikasi di deliver.

Kalo ada waktu n produknya umum, aplikasi bisa dikembangin sendiri n disempurnakan.
Yang mesti diinget :
1. Siap2 cape n makan ati, maklum soalnya starter…
2. Jangan mikirin duitnya dulu, tapi pengalaman, produk, sama relasi dulu.
3. Komitmen tiap2 individu agar “perusahaan” jalan.
4. Profesionalitas, bedakan urusan teman sama pekerjaan.

Q : Nah, apa di software house itu ada semacam SOP tertulis, tentang pembagian kerja atau sebagainya? Bagaimana struktur businessnya? Kapan bagian management atau akuntansi ikut gabung?

A : Tergantung software housenya.

Kalau balicamp/sigma setahuku sudah menerapkan CMMi yang mendefinisikan berbagai macam dokumen yang harus dibuat dalam satu project. SOP dan resource management dijelaskan dengan tegas. Tapi kalau software house semacam yang kecil-kecil sih biasanya masih cowboy belum ada process yang jelas, SOP dan dokumen. Paling sih ada template bikin proposal, form untuk requirement, form untuk change request, berita acara UAT / testing, Invoice untuk nagih. Kayaknya udah cukup segitu.

Orang accounting sama management gak dilibatkan dalam project. Paling cuma nanya2 doank tentang konsep accounting, malah kadang2 kita diajarin sama usernya. Kalau buku besar ini begini tablenya, jurnal AR dan AP begini begitu dst.

Kalau di operasional perusahaan biasanya ada bagian administrasi perusahaan yang ngurusi accounting, awal2 cukup pekerjakan lulusan SMK saja untuk membuat dokumen2 di atas.

Q : Trus gimana menentukan lamanya waktu pengerjaan sebuah software misalkan membuat software accounting atau CBI?

A : Ada beberapa cara untuk menentukan project estimation
1. Cara kasar : tentukan deadline berdasarkan kebutuhan bisnis, misalnya: PT A akan memulai usahanya pada juli bulan ini, maka aplikasi harus selesau bulan juni. Pokoknya aplikasi harus selesai, :D
2. Cara Marketing : Ikut tender, terus dengarkan tim lain presentasi, hitung waktu penyelesaianya kirakira 40% lebih cepat dibanding pesaing. Kalau pesaing bilang 5 bulan, ya kita bilang 3 bulan :)).
3. Cara logis : Tentukan kapan deadlinenya, kemudian tentukan feature apa yang diperlukan agar aplikasi Accounting bisa berjalan. Kemudian bentuk tim, training tim, setup teknologinya. Lalu bersama-sama dengan tim estimasi setiap feature berapa lama bisa dikerjakan. Kalau timnya berisi programmer berpengalaman dan pernah terlibat project development aplikasi serupa, peluang estimasi akurat bisa cukup
tinggi, kalau semuanya belum pernah membuat aplikasi tersebut ya coba tanya sama yang pernah bikin, kalau ada yang nggak tanya ya pura2 jadi mama laurent trus cari hari baik untuk deadline :D

Kalkulasi estimasi project bisa ditentukan dengan berbagai teknik ada yang dihitung berdasarkan table, banyak kolom, banyaknya screen, export-import modul, banyaknya report. Bisa menggunakan semacam poin untuk setiap item yang dihitung. Kemudian dibandingkan dengan history pengerjaan aplikasi, misalnya setelah dirata2 kecepatan pembuatan aplikasi ternyata 3 feature point per orang per hari, trus dari perhitungan feature point dari aplikasi dihasilkan 3000 feature point. Mandaysnya : 3000/3 = 1000 mandays, dikerjakan 5 orang jadinya 200 hari ;)

A : Estimasi pada intinya dibagi menjadi beberapa tahap :
1. Estimasi dulu seberapa besar aplikasi yang akan dibuat. Ada beberapa satuan yang umum digunakan untuk mengukur besarnya aplikasi, diantaranya Function Point dan Line of Code (LOC) LOC lebih akurat, tapi sulit diestimasi di awal project. FP lebih mudah, karena berkaitan langsung dengan requirement.

2. Setelah didapat besarnya aplikasi, estimasi effortnya. Berapa manday yang dibutuhkan untuk menyelesaikan. Perusahaan berpengalaman dan rajin ngumpulin data seperti Balicamp biasanya sudah punya data historis tentang kemampuan pasukannya. Satu FP bisa diselesaikan berapa manday. Nah dengan data ini, tinggal dibagi aja, berapa FP jadinya berapa manday.

3. Setelah manday didapat, estimasi durasi. Durasi adalah jumlah hari kalender untuk membuat aplikasi, satuannya hari kerja. Apa bedanya effort dan durasi? Misalnya satu fitur effortnya 8 manday. Ini belum tentu selesai dalam 1 hari. Mungkin saja durasinya bisa 4 hari, sbb :
2 jam meeting dengan client 2 jam coding.
2 hari clientnya lagi sibuk, sehingga gak bisa ngetes
2 jam UAT, dapat 10 bug
1 hari programmer mules-mules, gak bisa coding.
2 jam fixing
Total effort 8 jam, tapi durasi jadi 5 hari karena ada 2 hari nungguin user dan 1 hari programmer murus.

4. Setelah durasi dapat, baru bisa hitung cost. Misalnya durasi 4 bulan, berarti 4 kali gajian programmer, PM, tester, dsb. Kalo nyebrang lebaran, hitung juga THR, sehingga cost nambah.

Itu sederhananya. Mau yang rumit dan penuh jargon? Coba google function point calculation, wideband delphi, cocomo, planning game. Kalo saya sih yang gampang2 aja dan minim hype. Estimasi itu sederhana, tapi tidak mudah, karena butuh experience.

A : Klo ginian, enaknya dilihat dulu kapasitas team internal-nya spt apa. Maksud saya sih gini, coba lihat 1 orang itu sanggup bikin 1 screen CRUD standart + UI n DB validation brp jam. Nah dr situ dilihat kira2x brp form yg dibutuhin, trs hitung dengan cara yg udah dipaparin ama diatas . Nah masalah dr ngitung berdasarkan kompleksitas screen ini timbul klo misalkan client ga ada aplikasi sebelum-nya (manual abis, masih pakai excel) :D Nah klo udah masuk masalah ini, tergantung PM-nya gmn. Soalnya kadang-2x dr UI yg udah dibuat, ketika deliver iterasi 1 eh user-nya ngomong wah nih UI koq susah banget yah, klo diganti gmn ?? (gubrak ~_~’) Gmn cara ngitung-nya klo spt ini :D ^_^

A : Kalo soal screen design mah harusnya udah di waktu UReq dong, Khan dari requirement kita kasi mock up screen nya kayak apa, Lalu kalo di setujui, ntar kita estimate, bikin screen gituh bisa berapa lama, Nah kadang… consultant company is banking on the user to change their mind :p
Hahahaha
Believe me…
Jadi gitu user minta ganti UI… that’s it!
Time frame nya udah bisa di nego ulang… asal project nya udah di tangan toh?

Satu hal lagi, Buat management, 3000 feature point dengan 30 programmer jadi dalam 100 hari. Tapi apakah 3000 feature point dengan 60 programmer bisa jadi dalan 50 hari? Hal ini yang selalu bikin susah nih…

Q : Seberapa pentingnya kah orang yang benar-benar background marketing di software house?
Lebih menghasilkan mana, marketing online atau offline??

A : Kalau belum bisa gaji orang marketing, mending dikerjakan sendiri.

Kalau di perusahaan2 kecil marketing ini ibarat jantungnya software consulting, ngebul apa nggak dapur tergantung project yang diperoleh marketing.

Kalau masih pure tukang jait dan belum punya keunggulan kompetitif selain harga yang murah, sepertinya offline dengan pendekatan person to person lebih gampang. Kalau online lebih enak punya keunggulan kompetitif, misalnya punya nama yang dah dikenal banyak orang.

Offline dan online juga tergantung bussiness yang mau digarap. Kalau client besar seperti banking, telco, oil & gas dan pertambangan sepertinya lebih pendekatan ke personal. Masalahnya di industri ini cuma cukup untuk pemain-pemain besar saja, perusahaan masih baru mulai sih mana dipercaya.

Kalau mau mulai paling gampang nih, jadi sub kontraktor pengadaan software pemerintah :D. Ini project paling gampang, tapi paling berdarah2. Requirement tidak jelas, termin pembayaran tidak jelas, belum tentu aplikasi digunakan, dst dst.

Pikir-pikir dulu kalau mau bikin software consulting. Lebih enak kalau kerja dulu dan melihat industri apa yang bisa digarap. Kecuali km gak jadi consulting tapi bikin produk/service/framework dll

A : ArtiVisi udah jalan 3 tahun, tanpa ada orang ber-background marketing maupun orang yang dedicated untuk marketing. Nyatanya kita survive, project sih ada aja. Nah, kalo gitu penting gak marketing?

Menurut saya, reputasi lebih penting.

Q : Screen design dilakukan pada waktu UReq dan menghasilkan mock up screen, kalo di setujui, ntar kita estimate, bikin screen gituh bisa berapa lama. Proses ini biasanya software udah deal apa belum ya? sign kontrak dst?

A : Belom dong…
Khan biasa nya step nya tuh die undang buat presentation, Lalu di jelasin scope dasar nya, Ini masi blur nih tapi karna udah ada gambaran nya khan at least kita udah bisa sketch gambar screen, Nothing fancy nothing written on stone Cuma kayak kalo mo load data pasti ada search screen dulu, search screen nya di kasi criteria Cuma yang wildcard searchable di taro di tengah. Ntar ada border warna biru  Gitu2 ajah.

Kalo udah ada patokan ini khan udah ada screen mock up, Semua search screen akan kliatan seperti ini Tapi kalo tiba2 user nya mau ganti, Gak gini deh mau nya pake pop-up search, Lah ya bongkar toh? Ini lho maksud gue. Kalo udah beres screen mock up nya Tar kita kasi proposal, Tampilan nya gimana, Feature2 yang bisa kita throw in apa ajah, Time line nya berapa lama,  Harga nya berapa, Assumptions nya apa ajah, Report nya bisa apa ajah, Mesin nya musti apa ajah, Lalu baru di seleksi lagi, terakhir baru harga.

Nah ideal nya khan semua udah ada waktu nya Kayak tiba2 udah mau deliver user nya minta, wah report ginian gak ada nih, minta dong!, Lah ya kalo Cuma 1-2 ya gpp (mungkin) tapi kalo minta 30-40 report?

Q : Pernah coba terapkan agile methodology? user bisa mengerti methodology ini gak sih?

A : Sayang nya selama ini client2 gue kagak mau ngerti segala methodology ginian. U give the timeline, and I expect a stable product by that date, That’s it!  Hahahaha, Ya gue mah,  lu neken gue teken balik. Gak bole meleset ya lu gak bole banyak minta :p hahahaha

Q : Kalau semuanya masih mahasiswa dan belum pernah sama sekali masuk software house, ada saran ?

A : Disclaimer : Tidak bermaksud meruntuhkan semangat ataupun psywar bagi calon kompetitor ;p

Untuk bisa mendeliver sebuah aplikasi berkualitas production, sangat sulit. Apalagi kalo timnya semua fresh graduate, gak ada yang experienced.

Sebagai gambaran, Martinus bikin aplikasi kasir, Point of Sale, itu cuma 2 hari sudah komplit fiturnya, lengkap dengan print ke dot matrix. Tapi dari situ sampe aplikasi implement dan go live, butuh 3 minggu.

Pesan moralnya, deliver software jauh lebih banyak dari sekedar coding. Ada tarik-tarikan fitur/change, implementasi, training user, nagih invoice, dan urusan non teknis lainnya.

Coding itu sangat gampang, apalagi aplikasi bisnis. Paling cuma insert update delete database, nothing new.
Yang sulit itu :
- estimasi nilai project : butuh pengalaman
- menggali requirement di awal dengan lengkap supaya di belakang gak banyak hidden feature : butuh pengalaman
- mendesain aplikasi supaya adaptif terhadap perubahan : butuh jam terbang
- menerapkan change procedure supaya project tidak melebar : butuh skill negosiasi yang didapat dari pengalaman

Satu lagi, kalo core businessnya project, siap2 puasa berbulan-bulan. Cashflow perusahaan berbasis project sangat unpredictable. Bisa-bisa 4 bulan baru turun 1 termin. Nah selama itu biaya operasional dari mana?

Jadi, apa rekomendasi saya?
Kerja dulu di software house yang sudah mapan dengan tujuan sbb :
- belajar siklus mulai dari sales sampe project closing
- memperluas wawasan business process, misalnya akunting, procurement, dsb
- memperdalam kebijaksanaan dalam mendesain software
- menabung uang untuk modal bikin perusahaan
- menabung relasi untuk modal bikin perusahaan
- menabung reputasi biar gampang dapet orderan

Nanti setelah 2 - 3 tahun kerja, udah tau project dari kepala sampe buntut, baru deh bikin sendiri.

Hmm … jadi ingat thread sebelah tentang lulusan IT ;p
Coba baca ini dulu : http://endy.artivisi.com/blog/life/pengetahuan-wajib-buat-programmer/

Kalo mau buka software house, harus bisa solve problem, bukan cuma bisa coding.

Q : Nah, muncul satu lagi pertanyaan. Ntar yang bagian hubungan sama user, seberapa jauh harus mengerti teknis program yang kita buat?

A: Yang jelas harus ngerti bisnis process, dan ngerti behavior aplikasi yang dibuat. Jadi kalo user punya skenario, misalnya, gimana caranya kalo saya ada diskon dari supplier? Implementor bisa menjelaskan cara aplikasi mengakomodasinya. Bagian mana yang harus dikonfigurasi.

Q : Oia, untuk project management, tanya nih. Software apa saja yang bagus n gratisan yang untuk:
- project manager (misal: MS Project untuk yang punya mikocok)
- uml designer (power designer kan bayar)
- dll yang perlu lagi untuk software house
?

A : Uml jarang dperlukan. Ms project dipake tim yg ada Pm-nya, nggak ada manfaat praktis ke developer.
Yg penting tools itu versioning sistem spt subversion trus issue tracker spt trac atau redmine. Kl 2 itu dipake bnyak bantu developer.

klo emang ingin kerja tim, siapkan build tool yg bisa  ngurusin smua secara otomatis + nanganin masalah dependencies library :)  Nah enaknya lagi, di java ada 2 tool yg keren yaitu :
- Apache Ant (Automatic build tool, didlm ini jg bisa ditambahin custom  task utk kepentingan smua team)
- Apache Ant + Ivy ( Jika digabung ama ivy, bisa automatic dependencies  resolution :) )
- Apache Maven (Udah nge-cover smua yg disebutin diatas :D)

Nah pilih salah 1 aja :) Btw meskipun hal diatas ini kelihatan-nya sepele, tapi pengetahuan tool2x diatas diperlukan biar lebih nyaman klo mau beruusan ama subversion, release dan yg terkait dng versi aplikasi :)

A : Hmm… biasanya sih kita gak pake aplikasi Gantt chart model ginian. Berdasarkan pengalaman, aplikasi Gantt chart seperti ini kurang praktis. Soalnya kita jadi banyak berkutat mikirin dependensi antar task.
Padahal task di software development itu sangat dinamis.

Planning dan tracking di ArtiVisi tidak kompleks. Kita ngikutin fitur yang disediakan trac. Cuma ada milestone dan task. Milestone bisa dikasi tanggal deadline Satu milestone terdiri dari banyak task. Yang manapun task yang dikerjakan duluan tidak masalah.

UML juga tools yang kita gak pake. Mau presentasi class diagram ke siapa? Di ArtiVisi, karena client kita kebanyakan adalah end-user, kita tidak mendiskusikan hal2 teknis dengan client. Kita mau pakai surrogate atau natural key, client tidak perlu mikir. Kita mau pakai 1 tabel atau 10 tabel, bukan urusan client. Kita dibayar karena kita experienced dan bisa mengambil keputusan sendiri berkaitan dengan internal teknologi yang kita gunakan. So, ngapain lagi ngerecoki user dengan urusan jeroan?

Kita diskusi aplikasi dengan client menggunakan prototype UI. Kalo desktop, bikin pakai Swing, kalo web, ya langsung HTMLnya. Client memutuskan what to be built, kita memikirkan how to build.

Tools yang perlu lagi untuk software house :
- version control (kita pakai Subversion)
- Issue/task tracker, lebih sipp kalo ada version control browsernya (kita pakai Trac)
- IDE (kita pakai Netbeans)
- Skype, kita pake fitur share screennya, sangat berguna untuk remote discussion
- Aplikasi Email (Gmail sudah cukup, personally saya pakai TB)
- YM client

Intinya: stay simple, supaya bisa fokus ke kerjaan, bukan tools.

A : UML itu sepengalaman saya cocok digunakan untuk dokumentasi teknik yang dimengerti oleh developer, sedangkan user sebenarnya tidak mengerti UML, kecuali usernya mengerti IT. Kasus user yang mengerti IT
biasanya terjadi di project2 besar, sedangkan project web application, POS atau apliksi transaksi kecil hingga sedang tidak perlu UML. Malah lebih berguna Entity Relation Diagram (ERD).

User yang mengerti IT pun kalau berasal dari lingkungan nonOOP juga tidak familiar dengan UML.

Q : kalau mau manage project bareng-bareng, enak jelasin ke programmernya pake uml. Tentunya pake narasi di diagramnya. begitu ?

Ini adalah sesuatu yang mudah diucapkan tapi sulit dilakukan. Yang namanya programmer, akan lebih memilih coding daripada bikin UML. Soalnya dia akan mikir, daripada bikin UML lama, akan lebih cepat

kalau langsung dicoding. Dan jangan lupa, sesuatu yang dibuat harus dimaintain. Class diagram sih bisa direverse engineer biar tetap up to date, tapi narasinya?

ERD juga sesuatu yang kita gak pake. Gimana cara kita bikin diagram skema database? Bikin dulu aplikasinya, setelah selesai reverse engineer pakai Netbeans.

Kalau sesuatu terdengar indah di kuliah, belum tentu applicable di real project.

ERD, UML, kedengarannya keren dan mudah, kalau class/tabelnya < 10 Di aplikasi nyata, class biasanya > 100 dan tabel biasanya > 20. User management aja sudah 7 tabel sendiri : user, group, user_group,
permission, group_permission, user_session, user_preference.

UML tidak hanya class diagram. Yang lainnya adalah :
- Use Case Diagram : kayaknya terlalu simplistik untuk menjelaskan business process.
- Activity Diagram : ok lah ini mungkin bermanfaat untuk menjelaskanflow, sama aja kayak flowchart
- State Diagram : jarang dipakai kecuali untuk sesuatu yang state berubah misalnya status Order.
- Sequence Diagram : definetely for programmer, melihat invocation stack.

Saya gak bilang UML bad, crap, useless atau apa. Cuma gini aja, UML itu kan cara berkomunikasi. Jadi mau dipakai atau tidak ya tergantung pihak-pihak yang terlibat. Selama ini komunikasi kita lebih efektif dengan prototype screen, ya itu yang kita gunakan.

A : Gua juga pernah mau pakai UML sampai capai-capai baca beberapa buku. Terus latihan. Tapi ujung-ujungnya nggak kepakai. User lebih mengerti narasi dalam bentuk tulisan atau screen mock-up. Kalau menurut gua UML itu berguna sih tapi untuk skala proyek tertentu yang amat besar kalau menurut skala Indonesia. Untuk skala proyek normal di Indonesia UML adalah “overkill”/terlalu berlebihan.

Q : Gimana cara kita bikin diagram skema database?

A : Diagram ERD di kantor saya juga ga dipake, bukan ga mau ngikutin standar, tapi gmana cara bikin ERD untuk 35-40 database, tiap database > 100 tabel & > 50 view, tiap tabel/view kebanyakan > 20 field? Kita bikin desain tabel pake fasilitas diagram punya SQL Server 2000/2005.

Kalo saya dari sisi programmer keluarga DFD, ngeliat aplikasi itu berdasarkan fitur dan data. Fitur yang user mau apa? Data yang mo ditampilin apa? Data yang diinput apa? Nah dari situ baru bikin desain fitur, desain database, dll dsb sampe terakhir coding. Kalo coding dulu baru desain database terakhir ngikutin maunya program bakal lebih ribet pengembangan kedepannya.

A : Klo di tempat saya, urusan database pake ERWIN Data Modeller, support cukup banyak RDBMS.
Disana bisa dipecah-pecah berdasarkan subject area, cuma ya ada kemudahan, ya ada harga.

Jadi biar ada 1000 tabel pun, bisa dikelompokkan berdasarkan subject area. Manfaatnya dapat semua:
- Dokumentasi database
- Reverse / Forward Engineering
- dan mendukung semua fitur database yang disupport.

Ini yang paling basic dulu sih, semua kembali pada kedisplinan dan toleransi yang mengerjakan proyek. Klo gak disiplin jg bakal susah implementasi semua SOP Kerja yang ada, dan kembali ke dunia primitif.

Q : Yang namanya programmer, akan lebih memilih coding daripada bikin UML. Soalnya dia akan mikir, daripada bikin UML lama, akan lebih cepat kalau langsung dicoding. begitu?

A : Maaf kalo saya bilang ini programmer belom pengalaman megang aplikasi besar. Programmer yang pengalaman, dia bakal desain dulu aplikasinya ntar kaya gmana, butuh apa aja (fitur2nya), ada modul apa aja, hubungan antar modul gmana, data yang dibutuhin apa aja, nampilin data apa aja, desain databasenya gmana, kemungkinan evolusi aplikasi ke depannya gmana, permasalahan umum lainnya apa, dsb. Setelah desain udah jadi, baru coding. Kalo programmer yang langsung maen coding aja tanpa bikin desain, jamin deh dimasa depan pas pengembangan aplikasi (tambah fitur, tambah modul, integrasi modul lain) pasti lebih
kelimpungan daripada yang desainnya udah bagus.

A : Hmm.. saya tidak sepenuhnya setuju dengan yang diatas. Di company tempat saya sekarang aplikasi yang dibangun rata2 semuanya kompleks. Tapi di sini gak terpaku pada design formal (ada diagram pun paling oret oret di kertas ato gambar pake power point saja). System yang rumit2 aja docsnya gak perlu sebanyak yang diminta dosen saya waktu jaman mata kuliah Software Engineering.

Menurut saya kalo design yang sampai mendetail itu cocoknya kalau polanya system architect mendesign untuk “dijahit” oleh programmer, maka perlu design yang detail. Di tempat kami programmer semuanya tipe2 yang engineer, jadi design sendiri, coding sendiri, kadang2 konsultasi dengan rekan2, jadi design yang diperlukan cuma garis besarnya saja kira2 programnya mau dibuat bagaimana, sisanya improvisasi dipikir sambil dicoding.

Maintenance hell? Nggak juga, menurut saya malah lebih “agile” dari yang pakai SDLC tradisional - asalkan codingannya bagus dan kebaca, gak perlu design doc yang njelimet koq.

Design database? Kalau buat saya sih baca ERD sama baca schema (dengan asumsi schemanya rapi buatnya), gak banyak bedanya. Jadi perlu ERD kalau mau dikomunikasikan dengan client, dokumentasi, etc. saja. Jangan malah jadi “beban” karena merasa “wajib” buat diagram ini itu.

Jadi menurut saya, design kadang2 perlu, tapi nggak perlu yang extreme2 amat kecuali kalau mau dideliver ke pihak luar.

A : Perhatikan perbedaan antara *tidak melakukan desain* dan *tidak membuat dokumen desain* Yang saya bilang di atas, saya tidak bikin UML, DFD, ERD, and whatever dokumen desain yang orang lain biasa bikin. Lalu apa saya tidak melakukan desain? Tidak juga. Saat ini di ArtiVisi, yang biasanya mendesain aplikasi saya dan Martinus. Gini cara kerjanya.

1. Analisa UI prototype (kami tidak membuat SRS, URS, atau whatever *RS)
2. Tentukan tabel dan relasi (biasanya pada tahap ini cuma nama tabel, PK, dan FK) Ini tidak pakai tools apa2, cukup kertas dan pulpen.
3. Jalankan test scenario untuk berbagai variasi use case menggunakan sampel data sederhana, lihat apakah semua use case, baik untuk saat ini ataupun ke depan, sudah bisa terakomodasi oleh tabel dan relasi.
4. Revisi desain sesuai feedback dari step #3.
5. Repeat until done.
6. Setelah dirasa memuaskan, langsung coding domain class berikut relasinya (@Entity, @ManyToOne, @OneToMany, dsb)
7. Commit, kemudian buang kertasnya, pulpennya jangan.

Lalu apa kami sama sekali tidak pernah bikin gambar skema pakai tools? Pernah juga kadang2. Biasanya teman saya suka minta pendapat saya, atau saya pengen review skema yang dibikin Martinus. Gimana caranya? Generate dulu database pakai hbm2ddl, kemudian reverse engineer jadi diagram pakai whatever tools yang tersedia. Kalo gak ada tools, pakai ini aja
http://teethgrinder.co.uk/database-diagram/
Martinus kirim png ke saya. Saya komentar, kalo ada revisi langsung edit domain model. Regenerate png.

So, skema database itu dibuat secara reverse engineer, untuk keperluan komunikasi.
Begitu selesai, ya dibuang aja itu gambarnya, toh kalo perlu bisa dibikin lagi dengan mudah. Kalo perlu, generate pakai Ant aja dan masukkan ke build process.

Inilah interpretasi kami terhadap prinsip “the source code is the documentation” yang dianut Agile.

Kita tidak menganut pendekatan arsitek bikin gambar, programmer coding. Soalnya software itu dinamis, kalau desainnya pakai dokumen rigid semacam MS Word,nanti capek maintainnya. Kalo tiap nambah field, refactor nama tabel, add/remove relasi harus edit *doc, jaminan gak bakal dikerjain. Sudah jadi human nature males ngerjain gitu2an.

Jadi gini, dokumen itu ada untuk 2 purpose : komunikasi dan dokumentasi. Komunikasi itu untuk ngobrol sama orang lain. Dokumentasi itu untuk meringkas informasi biar gak harus ngetrace source code.

Yang untuk komunikasi, kita generate on demand. Abis komunikasi selesai ya dibuang, gak dimaintain.

Yang untuk dokumentasi, dibikin belakangan, setelah semua coding selesai. Kalo dibikin di depan, repot maintainnya, karena source code belum stabil. Masih banyak refactoring. Idealnya, setelah go live baru bikin dokumentasi. Jadi gak banyak rework. Tapi karena berhubungan dengan invoice, bisa juga dibuat pas UAT dimana perubahan sudah tidak signifikan lagi.

Sekali lagi, gak bikin dokumen desain bukan berarti tidak melakukan desain.

Nah sekarang, yang pada bikin ERD, DFD, UML, saya mau tanya? Kenapa Anda bikin diagram itu? Why? Asal ada manfaatnya no problem. Tapi kalo karena disuruh bos, di kuliah gitu, di buku dianjurkan demikian, think again. Apa gak sebaiknya masa remaja digunakan untuk hal2 yang lebih bermanfaat? :D

Akhirnya saya penasaran sendiri apa bisa diautomate, jadi saya google dan dapat ini :
http://schemaspy.sourceforge.net/

Bisa tuh dari Ant/Maven :
ant generate-skema-db

A : Yg ini bener banget neh.. kebanyakan kerjaan gw cuciin piring orang laen, jadi mana ada dokumentasi UML,ERD atau apapun juga.. Kalo gw milih dokumentasiin itu semua, bisa ga kelar-kelar kerjaan dan kehilangan pekerjaan gw.

Kalo menurut gw seh daripada pusing ngurusin UML dan segala macemnya itu lebih bagus belajar design pattern dulu dah. Buat make library dan mempelajari framework yang baru itu gampang, yg susah itu nerapin design pattern yang bagus buat applikasi kita. Kalo udah capek-capek bikin UML tapi design pattern nya ga diterapin juga pasti di jamin dalam pengembangan applikasinya nanti itu kelimpungan juga. yah kayanya emang UML lebih cocok untuk menjadi alat komunikasi antar programmer aja deh.. :D Gw bayangin presentasiin itu uml ke client gw :D  Bisa di ketawain + di goblok-goblokin + di keluarin Undang-undang garuda tuh..  Mana mo tau mereka urusan begituan.. Client butuh solusi bukan gambar-gambar gituan..
Kesimpulan
K : baru baca thread ini, sop di software house. tp jadinya menarik bahan diskusinya

ada beberapa hal menarik disini, seperti sharing dari Bung Ifma, dan Endy bagaimana mereka menerapkan development process di artivisi, menurut saya itu bagus banget dimana kita harus melihat skala perusahaan dan success level untuk menjadi sebuah result oriented company. tapi memang akan kurang cantik kelihatannya dari sisi documentation, inget technical team hate documentation, jadi rule of the gamenya sah2 aja.

Cerita Adelwin, ureq di indo jika bisa seindah itu…. gw demen banget deh. sayang sepanjang experience di project, belum pernah seindah itu, walaupun bisa sih di manage supaya ontime, tapi balik lagi, kemampuan business analyst, and project manager penting banget dalam hal ini.

about UML and development ini menarik banget untuk saya… karena saya sendiri berangkat dari dunia developer dan analyst dalam bekerja saat ini.

Dalam dunia development banyak yang menggunakan UML sebagai design and documentation. pake use case, class diagram, sequence dan activity diagram. di tempat saya sendiri bekerja saat ini, saya menggunakan UML terutama class diagram sebagai acuan dasar, karena saya menggunakan Model Driven Architecture. dimana class diagram sebagai design dasar untuk pengembangan application. klo ditanya kenapa sih butuh class diagram, kebetulan project kami menggunakan sekitar 200-400 domain model bahkan ada class yang memiliki attribute hingga 200, jadi tools cukup membantu dalam hal ini.

Tapi ada hal yang menarik mengenai diagram lain, seperti usecase dan sequence diagram. dimana diagram2 lain ini dapat dengan mudah digantikan oleh oret2 pencil, powerpoint, prototype maupun user stories. kebetulan sempat menggunakan 2 cara yang agak berbeda dalam menyampaikan apa yang harus dikerjakan developer :

satu team, selalu menggunakan use case scenario lengkap, prototype, hasilnya… programmer kesannya jadi jauh lebih manja, bahkan kemampuan analisa dan logika programmer kurang terasa. di team yang lain, kita mencoba menggunakan oret2 pencil, prototype atau simple scenario dapat juga verbal aja. hasilnya perkembangan developer yang ada, di team ini jauh lebih significant, kemampuan terhadap analisa dan logika lebih baik bahkan mereka tahu apa yang sebenarnya diminta oleh customer. Selain isu sense yang dimiliki oleh programmer bahwa mereka lebih berkembang dan tidak bosan dengan aktivitas mereka jauh lebih bagus dibandingkan dengan team yang lain.

Jadi ini lebih kelihat sebagai dinamika team dalam software development :)

K : Wowowow.. ternyata topik ini jadi panjang juga yah. sebagai TS, saya harus berterima kasih nih, banyak ilmu dan pendapat yang saya bisa ambil dari sini.

Saya memang newbie sih, belum pernah bikin aplikasi besar. Mungkin bagi yang sudah berpengalaman kayak om Endy, UML itu sudah nggak ada apa-apanya karena proses desain udah manteb di otak, tanpa perlu divisualisasikan. Itu juga dipengaruhi tingkat kerjasama tim dan pengalaman tim itu sendiri.

Tapi bagi saya yang jadi pemimpin tim programmer saya, saya masih perlu UML untuk menyampaikan desain aplikasi saya ke teman-teman. sebenarnya agak susah juga, karena semua harus dipikir di awal, agar nggak banyak perubahan seperti yang om Endy bilang. Tapi memang, efeknya ada bagusnya juga. Pengerjaan jadi lebih cepat karena si programmer nggak perlu susah-susah mikir desain-nya. Tapi ya kayak katanya om Tjiputra, akhirnya jadi males deh si programmer.

Dari sisi dokumentasi, rasanya UML patut diperhitungkan. Sayangnya saya belum ngerti gimana proses reverse engineer itu. Jadinya sekarang ini masih manual bikin UML, terus di share ke anggota, baru kalo ada perubahan ya tambal sulam diagramnya.

Oia, saya nemu tool gratisan yang cukup bagus. Saya pakai Visual Paradigm UML for Community. Itu gratisan juga, meski ada yang versi enterprise. Fiturnya cukup bagus, sayangnya agak lambat di Windows karena dia jalan pake Java.

Salam

Proses Pembuatan Passport

February 23rd, 2010

Saya beberapa waktu lalu berniat membuat passport, dan bertanya di milis smatn, ada satu posting dari kakak kelas saya, Prissy Waworuntu, yang menerangkan prosesnya dengan sangat mendetail. Rasanya ada dorongan kuat untuk mempublish postingan tersebut agar lebih banyak orang yang mendapaf manfaat ;).

ifnu : Dear all, bisa share pengalamanya membuat passport?

kak Prissi : Coba deh browsing di website-nya imigrasi, kayanya aplikasi paspor udh bisa online deh, tp aku blm nyoba yg online sih, terakhir bikin paspor bayi buat putra saya sblm lebaran kmrn di Kanim Jaksel.

Kalo menurut flyer/brosur yg gw baca di Kanim Jaksel, lama proses pembuatan paspor (resmi, ngurus sendiri, tanpa calo, tanpa kenalan org dalam) adalah 7 hari kerja dgn deskripsi sbb:

1. Hari pertama ambil nomor antrian, Senin-Kamis sampai pkl. 11, Jumat sampai pkl.10:30 –> penting utk diperhatikan krn kalo kelewatan mesin antriannya di-turned off. Beli formulir (harga Rp 5rb) di tempat fotokopi di dlm kantor dkt loket2, di situ jg ada keterangan dokumen2 yg perlu di-submit apa aja, baik dewasa maupun bayi/anak2.

Trus diisi selengkapnya, jgn lupa lampirkan fotokopi seluruh dokumen yg diperlukan (KTP, KK, Akte Lahir/Ijazah, Akte/Buku Nikah jika sdh menikah, Surat Referensi Kerja, Paspor lama; utk anak ditambah Paspor ortu, KTP ortu, Akte/Ijazah ortu, anak tsb sudah masuk dlm KK ortunya, surat persetujuan ortu yg formulirnya ada di tempat fotokopi td) Dokumen asli perlu dibawa hanya utk diperlihatkan, nantinya tdk ikutan di-submit.

2. Duduk manis, tunggu nomornya dipanggil ke Loket I, II atw III (it’ll take upto 2 hours, tergantung dtgnya jam brp. Lbh pagi lbh cepat beres sih) Setelah semua persyaratan dinyatakan lengkap, kita akan menerima selembar kertas kecil yg menyatakan harus kembali tgl brp utk foto/wawancara/dsb, biasanya paling cepat 2 hari lagi dtg kembali.

3. Hari ketiga ga perlu ngambil nomor antrian lgs ke loket IV. Nanti kita akan dicek apakah sudah bisa lanjut ke tahap berikutnya, trus tanda tangan lagi di formulir yg awal. Kemudian disuruh bayar ke Kasir di lantai 2, total Rp 270rb plus PMI (suka2 kasir mo minta brp lembar, mknya mending kasih uang pas deh kalo ngga ya ga dpt kembalian krn dipaksa membeli tiket PMI tsb)

4. Tanda bukti pembayaran yg diterima dari kasir dibawa ke ruang foto/wawancara. Ngantri lagi dehh,, :( Lama ngantri tergantung peak hours ngga, biasanya paling rame deket2 istirahat siang dimana orang2 yg kerja dtg utk langsung foto (kuat2an calo nih) Yg ngantri normal suka diselak gitu aja, suka2 petugasnya. Bisa ampe 2 jam juga tuh!

5. Ketika foto akan sambil diwawancara, bentuknya hanya sebatas rekonfirmasi data2 kita (tanggal lahir, alamat dll) sudah benar atw blm, baik ejaannya maupun datanya sendiri. Trus tanda tangan lagi, udah deh beres tinggal nunggu paspornya jadi. Biasanya dikasitau kpn kira2 jd, bisa tepat waktu, bisa lbh telat, yg pasti jarang bgt lbh cepet.

6. Hari ketujuh ga perlu ngambil antrian, langsung kasih aja tanda bukti pembayaran utk dituker paspor. Syukur2 udh jadi, biasanya yg lama di tanda tangan kepala Kanim-nya. Oya, kalo lupa bawa kwitansinya, bisa dgn  nunjukin KTP.

7. Kalo pengen centil dikit, beli cover paspor di koperasi karyawan. Harganya cuma Rp 3rb aja koq! Tauk deh knp skrg gitu, prasaan th 2006 beli formulir 5rb udh termasuk cover.

Fun facts:
1. Perpanjangan dihitung sama saja seperti bikin baru. Jika sudah pernah memiliki paspor maka paspor lama wajib dilampirkan. Kalo hilang maka prosesnya bakalan jauh lebih ribet lagi.

2. Referensi kerja is a must, apabila di KTP-nya tertulis karyawan dsj. Kalo di KTP-nya mahasiswa/pelajar maka lampirkan surat keterangan dari sekolah/kampus. Tapi ini tergantung reseh2nya petugas aja sih.

3. Setiap Kanim punya kebijakan masing2 –> dlm artian kalo kita punya kenalan org imigrasi di kantor lain, blm tentu dpt mempercepat proses. Meskipun miris tp pd kenyataannya kalo kita pake calo atw ngurusnya via org dlm, sangat bermanfaat dlm mempercepat proses. Hal ini kemudian akan berdampak pada biaya keseluruhan proses. Mau sehari jadi? Bisa bangett,, but there’s a certain price to pay :P

4. Bawa aja semua dokumen yg related. Mending kelebihan drpd kurang kan? Kalo dokumen ga lengkap ga akan diproses soalnya, ga bisa disusulin, harus balik lagi dan ngulang proses dari awal lg (ngambil
nomor antrian lg)

Semua ini berdasarkan pengalaman pribadi, sengaja ngurus normal dan prosedural dari jauh2 hari spy ga buru2. Males aja memperkaya calo dan petugas imigrasi ketika perlu cepat2.

Aku bikin paspor di Kanim Makassar (prosedural) ga seribet dan selama di Kanim Jaksel tuh! Tapi itu udh bbrp tahun yl, trus ada ngelampirin paspor lama. Ga perlu ngambil pula, dianterin ke depan pintu rumah donk sama petugasnya.. Katanya sih rumahnya deket.. :D *no extra charges*

Semoga bermanfaat.

Deploy jBPM-3.2.3 di JBoss-4.2.2.GA

November 10th, 2009

Pendahuluan

Dua minggu ini saya dapet tugas untuk explore XForm dan jBPM. XForm sudah saya bahas sedikit-sedikit di postingan saya terdahulu, tapi belum ada tutorialnya, hehehe, nunggu benar-benar sudah bikin sesuatu baru deh nanti saya buatkan tutorialnya.

jBPM adalah framework dari JBoss untuk memanage Bussiness Process Management. BPM sendiri merupakan alat untuk mendokumentasikan flow aliran data dalam aplikasi. Tipikal aplikasi yang mempunyai BPM kompleks adalah proses Purchase Order dan settlement. Misalnya di sistem supply chain management perusahaan retail seperti Giant atau Hypermart, proses PO sangat panjang. Dimulai dari ERP perusahaan akan membuat PO, kemudian PO “somehow” harus sampe ke inbox supplier, kemudian supplier akan mengirim barang bersamaan dengan despatch advice, kemudian dilanjutkan dengan settlement jumlah barang yang dikirim dan harganya hingga disepakati invoice oleh kedua belah pihak. Kenapa perlu settlement? karena ternyata nggak semua barang yang dikirim supplier diterima, mungkin karena rusak atau nggak sesuai standard, harga juga masih perlu ada settlement mungkin karena ada perubahan atau karena ada kondisi tertentu di kontrak yang menyebabkan harga yang sudah disepakati berubah.

BPM digunakan dalam proses seperti diatas untuk mengatur aliran flow data (dokumen) dan action apa yang bisa dikenakan terhadap data yang sedang aktif. Misalnya di data (dokumen) despatch advice bisa ditolak atau diterima, sedangkan dokumen invoice tidak bisa diapa2kan karena sudah final. Nah semua action dan flow data ini diatur dalam BPM engine.

Agar tidak penasaran, saya kasih sedikit screenshoot dari jBPM console :

Gambar diatas memperlihatkan flow diagram dari sebuah Process didalam jBPM. Lebih jauh tentang konseptual jBPM bisa baca buku dari packt jBPM practical guide

Persiapan

Sebelum bisa menjalankan jBPM console, ada beberapa file yang harus didownload, antara lain:
1. JBoss 4.2.2.GA.zip
2. Jbpm-jpdl-3.2.3.zip
3. Mysql
4. MySQL connector (JDBC Driver)
5. Java JDK
Link mysql download silahkan dicari di mysql.com atau cukup install mysql untuk OS yang digunakan. Java yang digunakan adalah JDK versi 1.4 keatas, saya sendiri menggunakan versi 1.6.0_12 dan berjalan dengan lancar.

Setelah proses download selesai, install mysql dan Java JDK. Kemudian extract jboss 4.2.2.GA dan jbpm-jpdl-3.2.3 ke folder yang diinginkan.

Konfigurasi

1. Instalasi dan persiapan mysql.
Setelah mysql berhasil diinstall, buat sebuah database baru untuk menyimpan data jbpm. Setelah itu buat user yang diberi akses ke database baru tersebut. Jangan dibiasakan menggunakan user root dalam konfigurasi aplikasi. Gunakan satu user khusus yang diberi akses hanya ke database yang digunakan aplikasi.

Login ke mysql dan jalankan perintah ini :

mysql> create database jbpmdb;
mysql> grant all on jbpmdb.* to jbpm@localhost identified by 'jbpm';

2. Create table jBPM
jBPM memerlukan table-table dalam database untuk menyimpan semua data yang diperlukanya. Setelah extract file jbpm-jpdl-3.2.3.zip, buka folder db dan cari file jbpm.jpdl.mysql.sql. Di dalam file tersebut terdapat DDL untuk membuat schema, nah anehnya ternyata DDL tersebut tidak benar secara sintaks, harus dilakukan manipulasi agar DDLnya bisa dijalankan di mysql. Pertama hapus semua statement alter table dan drop table di bagian atas kira-kira ada 122 baris. Kemudian untuk sisanya, tambahkan ; di bagian belakang setiap barisnya. Yang terakhir adalah ganti statement type=InnoDB menjadi engine=InnoDB. hfff, sepertinya pada waktu dibuat versi 3.2.3 ini mysql masih versi < 5, jadi sintaksnya banyak yang error kalau digunakan di mysql-5.
Setelah selesai diedit, simpan file jbpm.jpdl.mysql.sql dan flush ke mysql. Caranya, pertama buka console (command prompt) dan cd ke folder di mana file jbpm.jpdl.mysql.sql berada, lalu jalankan perintah di bawah ini dari console:

$ mysql -u root -p jbpmdb < jbpm.jpdl.mysql.sql

Pastikan proses flush berhasil tanpa ada pesan error. Setelah proses flush table ke database selesai, coba test hasilnya dengan login ke mysql dan periksa jumlah tablenya :

$ mysql -u jbpm -p jbpmdb
mysql> show tables;

Gunakan password jbpm dan pastikan ada 33 table di dalam database jbpmdb.

3. Menyiapkan Mysql Data Souce dan Drivernya
Sebelum bisa mendeploy jbpm di jboss, persiapan berikutnya adalah membuat Data Source agar jbpm bisa akses database dan table yang sudah dipersiapkan tadi.
Periksa folder hasil extract file jbpm-jpdl-3.2.3.zip dan cari file jbpm-console.war, nah file war inilah yang nantinya akan dideploy di dalam jboss. File war sebenarnya adalah file zip biasa, coba gunakan winzip atau zip tools lain untuk mengextract file war tersebut.
Setelah berhasil mengextract file war, coba cari file jboss-web.xml, disana terdapat konfigurasi nama datasource yang digunakan jbpm, kira-kira seperti ini konfigurasinya:

<resource-ref>
  <res-ref-name>jdbc/JbpmDataSource</res-ref-name>
  <jndi-name>java:JbpmDS</jndi-name>
</resource-ref>

Terlihat dalam konfigurasi diatas, jbpm memerlukan JbpmDS yang dibind ke JNDI name. Nah di JBoss 4.2.2 harus disiapkan datasource yang dimaksud. Caranya tidak susah, karena jboss sudah menyediakan contoh bagaimana membuat mysql-ds, file contohnya ada di ${jboss_home}/docs/examples/jca/mysql-ds.xml
Buka file mysql-ds.xml kemudian edit isinya menjadi :

    <jndi-name>JbpmDS</jndi-name>
    <connection-url>jdbc:mysql://mysql-hostname:3306/jbpmdb</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>jbpm</user-name>
    <password>jbpm</password>

Copy mysql-ds.xml yang sudah diedit ke folder ${JBOSS_HOME}/server/default. Konfigurasi diatas memerlukan driver mysql, oleh karena itu copy mysql jdbc driver yang sudah didownload dalam langkah persiapan ke folder ${JBOSS_HOME}/server/default/lib

4. Menyiapkan Security untuk login
jbpm-console menggunakan JAAS sebagai security mechanismnya. Form-based authentication merupakan teknik autentikasinya. Tutorial kali ini hanya membahas konfigurasi JAAS yang digunakan oleh jbpm-console, mungkin penjelasan saya malah bikin bingung, ya mohon maklum, ini cuma tutorial howto saja, kalau mau lebih jelas lagi tentang mekanisme security JAAS di JBoss silahkan membaca buku JBoss in Action.
Konfigurasi security JAAS untuk jboss tersebar di beberapa file :
- jboss-web.xml
Letaknya di dalam WEB-INF dari jbpm-console.war, konfigurasinya :

<security-domain>java:/jaas/jbpm</security-domain>

Di dalam konfigurasi ini disebutkan bahwa jbpm-console menggunakan mekanisme security JAASdengan domain jbpm. Nah untuk sekarang cukup ingat-ingat bahwa nama domain securitynya adalah jbpm, nama ini nanti digunakan di file konfigurasi login-config.xml.

- web.xml
Letaknya di WEB-INF dalam file jbpm-console.war dan kita tidak perlu melakukan modifikasi apa-apa.

    <security-role>
        <role-name>admin</role-name>
    </security-role>
    <security-role>
        <role-name>user</role-name>
    </security-role>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Secure Area</web-resource-name>
            <url-pattern>/sa/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>user</role-name>
        </auth-constraint>
    </security-constraint>
    <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/ua/login-example.jsf</form-login-page>
            <form-error-page>/ua/login-example.jsf?error=true</form-error-page>
        </form-login-config>
    </login-config>

Konfigurasi dalam Web.xml ini menandakan url apa saja yang diamankan, dalam hal ini adalah /sa/*, kemudian role user bisa masuk ke dalam url /sa/*, sedangkan user dengan role lain bisa masuk juga, konfigurasinya ada di server.xml, nanti kita bahas di bagian selanjutnya.

- server.xml
Letaknya ada di ${JBOSS_HOME}/server/default/deploy/jboss-web.deployer. Konfugurasi yang ada dalam file ini ada konfigurasi yang mengijinkan user lain dalam role selain user role bisa mengakses /sa/*

<Realm className="org.jboss.web.tomcat.security.JBossSecurityMgrRealm"
            certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping"
            allRolesMode="authOnly"
            />

Lihat atribute allRolesMode, disana isinya “authOnly”, konfigurasi ini mengjinkan user lain dengan role selain role user bisa login, sedangkan user lain yang tidak masuk ke role apapun tidak bisa login. Selain mode authOnly, JBoss menyediakan 2 mode lainya: strict dan strictAuthOnly. Penjelasan lebih lanjut silahkan cari di buku JBoss In Action tentang 2 mode lainya ini.
Selain itu di dalam server.xml terdapat konfigurasi agar JAAS menggunakan https (SSL/TSL) dalam aplikasi, silahkan lihat bagian <Connecto port=”8443″ yang di-remark secara default. Connector inilah yang digunakan sebagai provider Https di JBoss.

- login-config.xml
Letaknya di ${JBOSS_HOME}/server/default/conf. Di bagian web.xml ada konfigurasi untuk mendefinisikan security domain, dalam hal ini namanya jbpm. Security domain jbpm harus didefinisikan dalam login-config.xml. Konfigurasi security domain ini hanya digunakan kalau data user dan rolenya disimpan di dalam file properties. Sedangkan kalau menggunakan user dan role yang ada dalam database, tidak perlu mendefinisikan security domain di login-config.xml. Pertama saya akan menjelaskan konfigurasi kalau menggunakan file properties dan nanti saya akan menjelaskan konfigurasi untuk menggunakan data user dan role yang ada di dalam database.
Tambahkan konfigurasi ini ke dalam login-config.xml :

<application-policy name="jbpm">
      <authentication>
        <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
          flag="required">
          <module-option name="usersProperties">props/jbpm-users.properties</module-option>
          <module-option name="rolesProperties">props/jbpm-roles.properties</module-option>
        </login-module>
      </authentication>
    </application-policy>

Konfigurasi ini menyaratkan adanya file jbpm-users.properties dan jbpm-roles.properties di dalam folder props yang sejajar dengan file login-config.xml. Isi dari file jbpm-users.properties adalah :

user=user
manager=manager
admin=admin
shipper=shipper

Konfigurasi diatas adalah pasangan antara username dan passwordnya.
File jbpm-roles.properties :

manager = user,manager,admin
user = user
shipper = user
admin = user,admin

Konfigurasi diatas adalah pasangan antara username di sebelah kiri dan role yang dipunyai user tersebut.

Kalau ingin user dan role mengambil entry dari database, konfigurasi di login-config.xml diubah. Entrinya menjadi :

    <application-policy name = "jbpm">
       <authentication>
         <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule"
                       flag="required">
           <module-option name="dsJndiName">java:/JbpmDS</module-option>
           <module-option name="principalsQuery">
             SELECT PASSWORD_ FROM JBPM_ID_USER WHERE NAME_=?
           </module-option>
           <module-option name="rolesQuery">
             SELECT g.NAME_ ,'Roles'
             FROM JBPM_ID_USER u,
                  JBPM_ID_MEMBERSHIP m,
                  JBPM_ID_GROUP g
             WHERE g.TYPE_='security-role'
               AND m.GROUP_ = g.ID_
               AND m.USER_ = u.ID_
               AND u.NAME_=?
           </module-option>
         </login-module>
       </authentication>
    </application-policy>

Kemudian perlu insert user, role dan membership di dalam table, nah berikut ini statement untuk insertnya, masukkan ke database jbpmdb yang sudah dibuat di proses sebelumnya:

insert  into `JBPM_ID_GROUP`(`ID_`,`CLASS_`,`NAME_`,`TYPE_`,`PARENT_`) values
(1,'G','sales','organisation',NULL),
(2,'G','manager','security-role',NULL),
(3,'G','hr','organisation',NULL),
(4,'G','admin','security-role',NULL),
(5,'G','user','security-role',NULL);
insert  into `JBPM_ID_USER`(`ID_`,`CLASS_`,`NAME_`,`EMAIL_`,`PASSWORD_`) values
(1,'U','user','user@sample.domain','user'),
(2,'U','manager','manager@sample.domain','manager'),
(3,'U','admin','admin@sample.domain','admin'),
(4,'U','shipper','shipper@sample.domain','shipper');
insert  into `JBPM_ID_MEMBERSHIP`(`ID_`,`CLASS_`,`NAME_`,`ROLE_`,`USER_`,`GROUP_`) values
(1,'M',NULL,NULL,2,2),
(2,'M',NULL,NULL,2,4),
(3,'M',NULL,NULL,3,4),
(4,'M',NULL,NULL,2,5),
(5,'M',NULL,NULL,1,5),
(6,'M',NULL,NULL,4,3),
(7,'M',NULL,NULL,4,5),
(8,'M',NULL,NULL,3,5),
(9,'M',NULL,NULL,3,3),
(10,'M',NULL,NULL,2,3),
(11,'M',NULL,'boss',2,1),
(12,'M',NULL,NULL,1,1);

5. Deploy
Setelah selesai konfigurasi yang sangat melelahkan, langkah berikutnya adalah mendeploy jbpm-console.war di JBoss. Cukup copy file jbpm-console.war dan letakkan di folder ${JBOSS_HOME}/server/default/deploy
Jalankan file ${JBOSS_HOME}/bin/run untuk linux atau ${JBOSS_HOME}/bin/run.bat untuk windows.
Buka browser dan akses url http://localhost:8080/jbpm-console/ kemudian masukkan user dan password yang ada di jbpm-users.properties atau yang ada di table JBPM_ID_USER (tergantung mana datastore yang digunakan, properties atau table di database).

hff, lanjut lagi kapan2 dengan topik development JBPM dengan JBoss tools di Eclipse, what the, eclipse? yak yak, untuk sementara babay dulu netbeans :(

XForm

November 4th, 2009

Hari ini saya mendapatkan sesuatu yang tak terduga dan membuat saya syok: XForm

Ternyata ada teknologi untuk meggantikan HTML Form yang dianggap sudah kuno dan uzur. Salah satu implementasi dari XForm yang cukup sukses adalah Orbeon Form. Saya masih teringat bagaimana sulitnya mengimplementasikan Validation Framework di Struts jaman dulu. Atau membuat form dengan JSF atau dengan ExtJS. Nah ternyata ada framework yang khusus menangani masalah Form ini.

Karena masih sedikit syok, tutorialnya dilanjutkan nanti saja ;)

Membaca XML Bagian 3 : Xanot

October 3rd, 2009

Artikel ini adalah bagian ketiga dari seri membaca XML.

Kali ini kita akan menggunakan Xanot untuk membaca XML, jika 2 metode sebelumnya masih melakukan parsing manual, metode xanot sedikit berbeda. Xanot adalah singkatan dari XML Annotation, dibuat oleh salah satu member jug Ferdinan Neman.

Xanot menggunakan metode yang sering disebut dengan XML binding. Untuk menggunakan Xanot, Class-class yang diperlukan disiapkan terlebih dahulu kemudian diberi anotasi untuk memnentukan bagaimana cara melakukan binding antara XML tag dengan properti class-class tersebut.

Kelemahan xanot, dan semua XML binding, adalah semua tag XML harus ada representasi class-nya. Misalkan untuk melakukan mapping XML yang sama dengan 2 artikel sebelumnya :

<?xml version="1.0" encoding="UTF-8"?>
<Users>
	<User>
		<Name>badu</Name>
		<TglLahir>09-09-2009</TglLahir>
	</User>
	<User>
		<Name><![CDATA[fulan]]></Name>
		<TglLahir>13-01-1976</TglLahir>
	</User>
</Users>

Harus dibuat 2 class, yaitu class Users dan class User. Berikut ini kedua class tersebut beserta mapping Annotationya :

@TagInstance(path="Users")
public class Users {
    private List users = new ArrayList();
    private Users usersParent;
    @XmlCollectionProperty(xmltag=”User”,element=User.class,methodName=”addUser”)
    public List getUsers() {
        return users;
    }
    public void setUsers(List users) {
        this.users = users;
    }
    public void addUser(User user){
        users.add(user);
    }
    @ParentReference
    public Users getUsersParent() {
        return usersParent;
    }
    public void setUsersParent(Users usersParent) {
        this.usersParent = usersParent;
    }
}

Class User menjadi seperti ini :

@TagInstance(path="User")
public class User {
    private String name;
    private Date tglLahir;
    @XmlSingleProperty(name="Name")
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    @XmlSingleProperty(name="TglLahir",dateFormat="dd-MM-yyyy")
    public Date getTglLahir() {
        return tglLahir;
    }
    public void setTglLahir(Date tglLahir) {
        this.tglLahir = tglLahir;
    }
}

Terlihat ada 4 buah Annotation yaitu :

@TagInstance
Digunakan untuk menandai classs tersebut dibanding dengan Tag XML tertentu. @TagInstance ini diperlukan agar class Users bisa digunakan sebagai root.

@XmlSingleProperty
Digunakan untuk mapping single value atau single class. Contoh diatas digunakan untuk memapping tag Name dengan property name dari class User. Property tglLahir juga dimap dengan tag TglLahir, karena tglLahir adalah Date maka value dari dateFormat harus diisi.

@XmlCollectionProperty
Digunakan untuk memapping Collection value, ada beberapa setting harus diisi:

  • xmltag diisi dengan XML tag yang akan dimapping dengan class User. Tetapi nilai dari xmltag ini dioverride dengan nilai yang ada di @TagInstance yang ada di atas deklarasi class User. nilai xmltag akan digunakan jika misalnya class User tidak mempunyai @TagInstance
  • element diisi dengan User.class
  • method name diisi dengan method yang disiapkan untuk menambahkan satu nilai User ke dalam Users, dalam hal ini saya kasih nama addUser

@ParentReference
Digunakan untuk menandai bahwa properti usersParent adalah parent dari class User

Setelah menyiapkan class dan mappingnya, sekarang waktunya Xanot in action. Lihat kodenya, dan anda akan terkejut dengan begitu sederhananya Xanot in Action.


import java.io.File;
import java.io.IOException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.xml.parsers.ParserConfigurationException;
import org.xanot.Xanot;
import org.xanot.XanotException;
import org.xml.sax.SAXException;

/**
 *
 * @author ifnu
 */
public class XmlReaderXanot {

    public static void main(String[] args) {
        try {

            Xanot xanot = new Xanot();
            xanot.setRoot(Users.class);
            Users users = (Users) xanot.parse(new File("users.xml"));
            for(User user : users.getUsers()){
                System.out.println(user.getName());
            }
        } catch (SAXException ex) {
            Logger.getLogger(XmlReaderXanot.class.getName()).log(Level.SEVERE, null, ex);
        } catch (IOException ex) {
            Logger.getLogger(XmlReaderXanot.class.getName()).log(Level.SEVERE, null, ex);
        } catch (ParserConfigurationException ex) {
            Logger.getLogger(XmlReaderXanot.class.getName()).log(Level.SEVERE, null, ex);
        } catch (XanotException ex) {
            Logger.getLogger(XmlReaderXanot.class.getName()).log(Level.SEVERE, null, ex);
        }

    }

}

Satu hal yang belum dicapai xanot adalah bagaimana memvalidasi document xml menggunakan XML schema. Ferdinand bilang akan diimplementasikan di versi 2, tetapi sepertinya belum sempat terealisasi beliaunya sudah terlanjur meninggalkan dunia perkodingan java ;)

Di artikel berikutnya, saya akan membahas tentang bagaimana menggunakan XMLBeans untuk membaca dokumen berdasarkan XML Schema. Selain itu XML Bean dapat mengenerate class mapping (Users dan User) tanpa harus kita membuat sendiri, cool eh?

Membaca XML Bagian 2 : Apache Commons Configuration

October 3rd, 2009

Artikel saya sebelumnya menerangkan bagaimana membaca XML menggunakan SAX. Metode tersebut adalah yang paling sederhana dan paling manual. Kode yang diperlukan cukup banyak, kalau XML dokumenya cukup panjang dan rumit maka kode-nya juga makin rumit pula.

Cara kedua ini sangat sederhana, namun Apache Commons Configuration ini performancenya masih kalah jauh dibanding SAX. Jadi sebaiknya, sesuai namanya, apache commons configuration digunakan untuk membaca file konfigurasi XML saja. Atau bisa juga digunakan untuk membaca XML data tetapi load-nya kecil. Kalau anda membutuhkan parser XML yang performance critical sebaiknya jangan menggunakan Apache Commons Configuration.
Commons Configuration sebenarnya bisa membaca file :

  • Properties files
  • XML documents
  • Windows INI files
  • Property list files (plist)
  • JNDI
  • JDBC Datasource
  • System properties
  • Applet parameters
  • Servlet parameters

Nah artikel kali ini sedikit membahas trik menggunakan commnons configuration untuk membaca file XML. Seperti sudah saya tekankan dari awal, commons configuration hanya tepat digunakan untuk membaca konfigurasi xml atau data XML yang kecil-kecil saja. Performa apache configuration bukanlah issue penting karena bukan merupakan tujuan utama.

Commons configuration untuk XML mempunyai cara yang sangat mudah untuk mendapatkan nilai dari XML. Misalnya untuk mendapatnkan String “badu” kita gunakan kode :

  configuration.getString("User(0).Name"));

Perhatikan bahwa Tag Users yang merupakan Root dari XML dokumen diatas tidak disertakan dalam String path diatas.
Sebelum mulai coding, sebaiknya download dulu library Apache Commons Configuration dari websitenya : http://commons.apache.org/configuration/

Jar yang diperlukan adalah

Misalnya XML yang akan diparsing sama seperti di artikel sebelumnya :

<?xml version="1.0" encoding="UTF-8"?>
<Users>
	<User>
		<Name>badu</Name>
		<TglLahir>09-09-2009</TglLahir>
	</User>
	<User>
		<Name><![CDATA[fulan]]></Name>
		<TglLahir>13-01-1976</TglLahir>
	</User>
</Users>

Kode untuk mendapatkan List of user adalah seperti berikut ini :

import java.io.File;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.XMLConfiguration;

/**
 *
 * @author ifnu
 */
public class XmlReaderApacheCommonsConfig {
    public static void main(String[] args) {
        try {
            XMLConfiguration configuration = new XMLConfiguration(new File("users.xml"));
            List users = new ArrayList();
            //mendapatkan banyaknya tag User di dalam tag Users
            int userLength = ((Collection)configuration.configurationsAt(”User”)).size();
            for(int i = 0;i<userLength;i++){
                User user = new User();
                users.add(user);
                user.setName(configuration.getString(”User(” + i +”).Name”));
                System.out.println(user.getName());
                String tglLahir = configuration.getString(”User(” + i +”).TglLahir”);
                try {
                    user.setTglLahir(new SimpleDateFormat(”dd-MM-yyyy”).parse(tglLahir));
                } catch (ParseException ex) {
                    Logger.getLogger(XmlReaderApacheCommonsConfig.class.getName()).log(Level.SEVERE, null, ex);
                }
            }
        } catch (ConfigurationException ex) {
            Logger.getLogger(XmlReaderApacheCommonsConfig.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

Membaca XML bagian 1: SAX

October 3rd, 2009

Hari ini dapet pertanyaan dari Yoga gimana caranya baca XML dan mapping ke dalam Object.

Nah beberapa waktu yang lalu saya sudah menyampaikan training tentang IO di java, kebetulan salah satu materinya adalah membaca XML. Jadi sekalian saja saya share kodenya di sini.

XML yang akan kita baca adalah seperti ini :

<?xml version="1.0" encoding="UTF-8"?>
<Users>
	<User>
		<Name>badu</Name>
		<TglLahir>09-09-2009</TglLahir>
	</User>
	<User>
		<Name><![CDATA[fulan]]></Name>
		<TglLahir>13-01-1976</TglLahir>
	</User>
</Users>

Salah satu metode untuk membaca XML diatas adalah dengan SAX (Simple API for XML). Metode ini adalah yang paling cepat dan sederhana. Untuk membaca XML yang sedikit rumit sebaiknya hindari menggunakan SAX karena proses parsingnya masih sangat manual dan akan menyebabkan kodenya cukup rumit untuk dipahami.

Ada library lain yang bisa digunakan untuk membaca XML dengan lebih mudah, misalnya menggunakan XML-binding library seperti XMLBean. Dimana kita cukup menyediakan XML Schema dari dokumenya, maka Object mappingnya akan digenerate sekaligus parsernya.

Selain itu ada juga XML library yang dapat digunakan untuk memapping dari XML ke object, antara lain Xanot (yand didevelop oleh Ferdinand) dan Apache Commons Configuration. Lain kali saya akan coba bikin tutorial mengenai ginama menggunakan libary Xanot dan Apache Commond Configuration.

Langkah pertama dalam menggunakan SAX adalah dengan membuat class yang extends DefaultHandler. Untuk membaca XML diatas, begini classnya :

public class UserXmlHandler extends DefaultHandler{

        private User currentUser;
        private Set users = new HashSet();
        private String currentString;

        public Set getUsers() {
            return users;
        }

        @Override
        public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
            if(qName.equals(”User”)){
                currentUser = new User();
            }
        }

        @Override
        public void characters(char[] ch, int start, int length) throws SAXException {
            currentString = new String(ch,start,length);
        }

        @Override
        public void endElement(String uri, String localName, String qName) throws SAXException {
            if(qName.equals(”User”)){
                users.add(currentUser);
            } else if(qName.equals(”Name”)){
                currentUser.setName(currentString);
            } else if(qName.equals(”TglLahir”)){
                try {
                    currentUser.setTglLahir(new SimpleDateFormat(”dd-MM-yyy”).parse(currentString));
                } catch (ParseException ex) {
                    Logger.getLogger(XmlReader.class.getName()).log(Level.SEVERE, null, ex);
                }
            }
        }
    }

Ada 3 method penting yang harus dioverride dari class DefaultHandler, yaitu startTag, endTag dan characters.

Method startTag akan dipanggil oleh SAX parser ketika ada start tag dari xml ditemukan. Dalam class UserXmlHandler diatas, kodenya sangat sederhana, yaitu kalau ketemu start tag User ( if(qName.equals(”User”)) ) maka buat user baru ( currentUser = new User());

Method character digunakan untuk menyimpan isi dari tag. Misalnya dalam tag <Name>badu</Name> isi dari character adalah “badu”.

Method endTag dipanggil SAX parser ketika end tag dari xml ditemukan. Di end tag ini biasanya ada kode-kode untuk memasukkan string yang diperoleh dari method character ke tag yang bersesuaian.

Setelah siap kodenya, kita coba untuk membaca Xml, nah kode untuk membaca XML kira-kira seperti ini :

import java.io.File;
import java.io.IOException;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.HashSet;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;

/**
 *
 * @author ifnu ifnubima@gmail.com;ifnu@artivisi.com
 * blog : ifnu.artivisi.com
 * company : artivisi intermedia
 * site : artivisi.com
 */
public class XmlReader {

    public static void main(String[] args) {

        UserXmlHandler handler = new UserXmlHandler();

        SAXParser parser;
        try {
            parser = SAXParserFactory.newInstance().newSAXParser();
            parser.parse(new File("users.xml"), handler);

            Set users = handler.getUsers();
            for(User u : users){
                System.out.println(u.getName());
            }

        } catch (IOException ex) {
            Logger.getLogger(XmlReader.class.getName()).log(Level.SEVERE, null, ex);
        } catch (ParserConfigurationException ex) {
            Logger.getLogger(XmlReader.class.getName()).log(Level.SEVERE, null, ex);
        } catch (SAXException ex) {
            Logger.getLogger(XmlReader.class.getName()).log(Level.SEVERE, null, ex);
        }

    }
}

file users.xml berada di dalam user.dir yaitu folder yang sama dimana aplikasi java-nya dijalankan. kalau di NetBeans project ya di dalam folder projectnya, sejajar dengan file build.xml

Selamat mencoba

Deploy Aplikasi Desktop sebagai Java Webstart/JNLP

August 31st, 2009

Aplikasi yang sedang saya develop adalah aplikasi desktop menggunakan java, arsitekturnya menggunakan 3 thier dimana ada satu bagian aplikasi yang menjadi server-side. Untuk memudahkan development, kita putuskan untuk mengadopsi teknologi Spring.

Aplikasi didevelop seperti biasa mengguanakan stack Spring-Hibernate-Swing, kemudian bagian service-dao-Entity hibernate dideploy di sisi server, kemudian interface service diexpose sebagai Servlet menggunakan protokol HTTP Invoker dari Spring. Lebih lanjut mengenai arsitektur ini bisa baca di sini dan di sana

Client hanya membutuhkan interface service, Entity (diabuse jadi DTO) dan UI code (Swing). Sampai di sini saya sudah cukup puas, karena aplikasi jadi cukup fleksible untuk ditambah-tambahkan feature, misalnya scheduler di sisi server.

Kemudian ada masalah cukup pelik di sisi deployment. Aplikasi client harus di install di setiap workstation, kemudian kalau ada update, ya diupdatelah semua workstation, bete abis!!

Pemecahanya ternyata gampang kok, gunakan JNLP/Webstart. Aplikasi client diletakkan di sisi server, kemudian install web server agar bisa dibrowse file jnlp dan jar dari client. Kemudian akses file jnlp dari browser client, misalnya :

http://192.168.0.1/app/pos.jnlp

Nah sekarang, aplikasi cleint tidak perlu diinstall lagi, cukup akses file jnlp maka semua jar yang diperlukan akan didownload. Jika ada update di sisi server, maka jar yang baru akan didownload ke client, praktis bukan?.

Selain dari browser, file jnlp bisa dieksekusi langsung dari console, perintahnya seperti ini :

javaws http://192.168.0.1/app/pos.jnlp

Isi file JNLP tidak terlalu rumit, yang perlu didefinisikan adalah url dimana file jnlp dan jar diletakkan. Kemudian daftar dari semua jar yang dibutuhkan dan main class aplikasi. Contoh file JNLP kira-kira seperti ini :

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://192.168.0.1/app/" href="pos.jnlp">
    <information>
        <title>Termos Application</title>
        <vendor>Artivisi Intermedia</vendor>
        <homepage href="http://www.artivisi.com"/>
        <description>Aplikasi POS</description>
        <description kind="short">Aplikasi POS</description>
        <offline-allowed/>
    </information>
    <resources>
        <j2se version="1.6+"/>
        <jar eager="true" href="pos.jar" main="true"/>
        <jar href="jasypt-1.5.jar"/>
        <jar href="jcalendar-1.3.2.jar"/>
        <jar href="joda-time-1.5.2.jar"/><
        <jar href="log4j-1.2.12.jar"/>
        <jar href="commons-collections-3.1.jar"/>
        <jar href="commons-codec-1.3.jar"/>
        <jar href="commons-lang-2.1.jar"/
        <jar href="commons-beanutils-1.7.jar"/>
        <jar href="commons-digester-1.7.jar"/>
        <jar href="commons-logging-1.0.2.jar"/>
        <jar href="itext-1.3.1.jar"/>
        <jar href="jasperreports-3.1.4.jar"/>
        <jar href="poi-3.0.1-FINAL-20070705.jar"/>
        <jar href="ejb3-persistence.jar"/>
        <jar href="AbsoluteLayout.jar"/>
        <jar href="termos-config.jar"/>
        <jar href="spring.jar"/>
        <jar href="MartinSwingUtil.jar"/>
        <jar href="hibernate3.jar"/>
    </resources>
    <application-desc main-class="com.artivisi.pos.client.Main">
    </application-desc>
</jnlp>

Cara paling mudah mengekspose file jar dan jnlp agar bisa diakses dari client lewat protokol http adalah dengan menginstall apache webserver. Di ubuntu caranya sangat gampang tinggal jalankan perintah :

sudo apt-get install apache2

Kalau di windows bisa menggunakan package instalasi AMP seperti XAMPP. Setelah instalasi apache2 selesai, kemudian buat folder /var/www/app dan letakkan file jar dan jnlp yang dibutuhkan di folder tersebut. Nah sekarang siap sudah jnlp diakses dari client.

Kadang kala kita gagal dalam proses deployment jnlp, ada sintaks yang salah atau daftar jar yang tidak lengkap, sehingga perlu proses download ulang jnlp dari client. Nah, rumitnya, javaws melakukan penyimpanan semua jnlp di cachenya, jadi kadang-kadang saya nggak mengerti kenapa kok jnlp udah diupdate di server tapi dari cleint kok masih tetep yang lama?

Ada langkah tambahan untuk menghapus cache ini, jalankan perintah ini di workstation client :

javaws -viewer

Akan tampil dialog java console seperti ini :

kemudian pilih tab network dan tekan tombol “view cache files…”, akan tampil daftar aplikasi java webstart yang pernah dieksekusi, kemudian pilih aplikasi yang akan dihapus cachenya :

Selamat mencoba