bermain-main dengan java reflection

dalam posting ini saya hanya ingin mencoba java.lang.reflect dalam men-set property dari sebuah object. ada 2 cara yang saya coba yaitu dengan langsung men-set field-nya dan satu lagi yaitu dengan meng-invoke method setternya.

apa bedanya? silakan menuju ke http://blog.nostratech.com/2015/09/bermain-main-dengan-java-reflection.html untuk pembahasannya.

baca selengkapnya..

menguji atomisitas redis - INCR command

post ini ditujukan untuk menguji sifat atomisitas command INCR redis. 

kebutuhannya adalah, misalnya di aplikasi saya membutuhkan sebuah generator unique code. cara termudah untuk membuat unique code adalah dengan melakukan increment yang dimulai dari suatu angka, dan seterusnya. nantinya ini bisa dikombinasikan dengan character lain.

jika kita melihat dari 1 jvm, hal ini mudah saja, misalnya kita bisa buat sebuah variable static yang menampung angka tertentu dan menyiapkan sebuah method synchronized bagi thread yang hendak mengambil value tersebut (dan meng-increment-nya).

tapi bagaimana jika kita memiliki lebih dari 1 jvm? silakan menuju ke http://blog.nostratech.com/2015/09/menguji-atomisitas-redis-incr-command.html untuk pembahasannya.

baca selengkapnya..

Cucumber for Java Behaviour Driven Development

Let's say the client or partner has a new requirement. We're dealing with what is exactly he wants. Then the requirements will be implemented by the developers. Is there any tool that can be use to ease this process, so we can get the exact cases what the client wants, and easy to be implemented by developers in their unit tests?

here it is: http://blog.nostratech.com/2014/05/behaviour-driven-development-using.html

baca selengkapnya..

javaFX redirect page and passing object to controller

how to redirect page and passing object between controller class in javaFX?
read more at http://blog.nostratech.com/2013/12/javafx-redirect-page-and-passing-object.html

baca selengkapnya..

ADF table multiple selection tanpa business component

Ada kalanya saat menggunakan ADF, kita mem-bind suatu table tidak melalui business component, misalnya data tersebut tidak berasal dari database, bisa jadi hasil dari suatu kalkulasi di engine tertentu dan resultnya berupa list, atau bisa juga data didapat dari invokasi service (soap/rest).

bagaimana cara melakukan multiple selection untuk kasus seperti di atas? baca selengkapnya di http://blog.nostratech.com/2013/12/adf-table-multiple-selection-tanpa.html

baca selengkapnya..

Sentralisasi Hibernate Cache dengan Terracotta/Ehcache

ORM cache diperlukan untuk mengurangi akses ke database, yaitu untuk pengaksesan data yang sama berulang kali. Defaultnya, hibernate telah menerapkan caching pada level Session (L1). artinya, cache tersebut hanya digunakan oleh 1 user, dalam 1 proses transaksi. Bagaimana untuk menerapkan caching untuk multi-user (multi-session)?

baca selengkapnya di http://blog.nostratech.com/2013/12/sentralisasi-hibernate-cache-dengan.html.

baca selengkapnya..

some of these days thoughts

beberapa pikiran beberapa hari (atau beberapa minggu) ini. ada beberapa pikiran yang ga berkaitan dengan yang lain, mungkin sbnrnya postingan ini bisa dibagi2 jadi beberapa posting pendek (subpost), tapi males ah ngepost banyak2. gabungin aja lah ya.

chat server application
dimulai dari ngulik2 oracle communications instant messaging server - kita singkat aja namanya jadi ocims. dia salah satu produknya oracle yang nanganin real-time communication, 'saingannya' oracle beehive (mungkin beehive udah tenar duluan). standar dan teknologi protocol yang diusung: xmpp, singkatnya si ocims ini adalah server buat chatting.

kalo kita chatting di ym misalnya, kita ngetik di aplikasi (desktop/web) nya ym, ngeliat presence (siapa aja yg online/offline), dll. semua aktivitas yg kita lakukan di aplikasi tersebut akan dikirim ke server chatnya yahoo. utk diterusin lagi ke setiap pemilik akun ym yg lagi online, secara realtime. misalnya kita ngechat temen kita, yg kita ketik dikirim ke server, trus server akan nerusin informasi tadi ke aplikasinya temen kita (baca: client). trus nongol deh message kita di sana.

*technically, bukan server yang akan nerusin info tadi ke client. tapi tiap client naro listener di server, utk nerima message yang ditujukan ke dirinya, dan dibawa ke aplikasi kliennya.

itu artinya, server ga akan berguna kalo ga ada kliennya. aplikasi apa yang bisa jadi clientnya?

itu lah asiknya xmpp (atau jabber). selain teknologi, dia juga adalah sebuah standar. dengan adanya sebuah standar, beberapa provider (server) bisa menerima client dari berbagai aplikasi. sekarang google, facebook, yahoo pada pake xmpp utk instant messagingnya, dan utk bisa mengakses mereka (bahkan pada saat bersamaan) kita bisa menggunakan aplikasi seperti pidgin/adium dan kalo ga salah ym versi baru juga support utk login ke im-nya facebook..

kalo demikian, logikanya, setelah gw setup ocims, gw bisa konek pake pidgin dan adium. dan bener aja, memang bisa konek, login, ngliat presence, kirim2an message, juga kirim2an file. sukses.

chat client application
oke, kita bisa konek pake adium. tapi main goalnya apa sih sebenernya? ternyata si klien itu lagi pengen integrasiin fitur chat ke aplikasi portalnya. portalnya dia pake oracle juga. jadi yang harus dilakukan berikutnya adalah masang chat client di sebuah aplikasi web. si aplikasi web ini nantinya akan di-embed ke halaman portal.

pidgin bisa di-embed ke aplikasi web ngga? gw ngga tau. gimana caranya?
coba googling2, nemu beberapa web chat app pake javascript, misalnya yg ini: http://opkode.com/media/blog/converse.js-xmpp-instant-messaging-with-javascript. wah bagus nih, coba ah. ternyata eh ternyata, browser punya kebijakan same origin policy, silakan baca juga HTTP access control. jadinya koneksi xmpp harus 'dialihkan' melalui http, memanfaatkan BOSH.

so, terkait dengan aplikasi client ini, ada 2 opsi: 1) pake javascript yg udah ada, trus setup bosh di ocims, atau 2) ga perlu setup bosh, tapi bikin aplikasi xmpp client pake java, utk di-embed ke web app. opsi (1) keliatannya butuh effort yang lebih banyak utk ngertiin dulu apa itu bosh, dan gimana cara kerja bosh sbnrnya, dan gimana hubungan teknis bosh dan xmpp server. jadi karena dikejar waktu, opsi (2) lah yg dipake.

harusnya kalo pake javascript aplikasinya bisa jauh lebih ringan daripada aplikasi webapp java. terkait dengan masalah server processing. kalo pake java framework, misalnya jsf atau adf atau yg lain, komponen2 direndernya oleh server, dengan kata lain, server harus melakukan juga fungsi tambahan selain processing data, kalo concurrent usernya banyak mungkin akan kerasa beratnya.

tapi apa mau dikata, waktu lah yang akhirnya mengerucutkan pilihan. webapp pun dibuat pake framework oracle adf (mempermudah integrasi dengan oracle webcenter portal, udah ada pluginnya di IDE jdeveloper) dan xmpp client diimplementasi menggunakan smack api.

kondisi saat ini, xmpp client sudah berhasil dijalankan (terpisah dengan framework adf). tetapi saat diintegrasikan dengan framework adf, masih tersangkut masalah terkait dengan mekanisme page rendering dan data control yang dimiliki sama adf. curhatan soal ini dibahas dikit di subpost life barrier di bawah.

review soap vs rest webservices
sebenernya ini dimulai dari case umum: gw pengen aplikasi gw dijadiin soa-based, utk integrasinya pake webservice. pertanyaannya: mendingan mana, webservice RESTful atau SOAP?

untuk bagian ini, bisa langsung menuju http://blog.nostratech.com/2013/07/membandingkan-soap-dan-rest-webservice.html.

di situ ada overview sekilas, dilanjutin dengan komparasinya. disertakan juga link2 referensi kalo mau baca2 lebih lanjut. silakan.

life barrier
ini tentang sudut pandang.

semua hal yang dilakukan tiap orang, berasal dari sudut pandang orang tersebut terhadap objek yang dikenai pekerjaannya. hal-hal kecil yang dilakukan berulang-ulang dan akhirnya membentuk kebiasaan. karena telah terbiasa, akhirnya orang tersebut menjadi yakin dalam menjalaninya. entah salah atau benar, tapi keyakinan pada apa yang dilakukan (atau apa yang dituju) itulah yang memunculkan keberanian (menghadapi konsekuensinya) dan makin memperkuat karakter tiap orang, yang tentunya berbeda satu sama lain. sudut pandangnya berbeda.

misalnya seorang programmer. anggaplah dia programmer java. terbiasa menggunakan library2 opensource dalam proses developmentnya. karena yang digunakan adalah library, maka logika programming yang dia terapkan pun berdasarkan logikanya. logika dan arsitekturnya adalah rancangan logika sang programmer.

tiba-tiba pada suatu hari, programmer tersebut diminta untuk melakukan development softwarenya menggunakan framework (bukan library) milik vendor tertentu. library mengacu pada reusable functions, framework mengacu pada reusable behaviors. behaviors berarti tingkah laku, dan tingkah laku terkait dengan logika si pembuatnya, terkait lagi dengan sudut pandang pembuatnya.

adalah sebuah kesalahan fatal bagi seorang programmer untuk ngotot membawakan logikanya di tengah framework yang dia gunakan. karena dalam banyak kasus, logika sang programmer tidak sejalan dengan logika pembuat framework. dan pemanfaatan framework itu pun jadinya bukan best practice nya framework itu. dan bug2 yang tidak perlu pun bermunculan, dan usaha2 fixingnya pun bisa jadi malah memperparah keadaan. dan mungkin solusi terakhir yang bisa dilakukan adalah rework. mengikuti logika pembuatnya.

konteks yang sama bisa juga diterapkan dalam logika beragama. ketika seseorang telah menjalani hari2nya dengan keyakinan yang berasal dari logikanya sendiri, selama bertahun-tahun. dan kemudian berusaha mengenal suatu agama dan/atau kepercayaan (mendekati keyakinan melalui sudut pandang tertentu) tetapi dengan membawa logikanya dalam (berusaha) memahami kepercayaan itu.

agama, artinya aturan, untuk membuat jadi teratur. mengatur behavior tertentu, bisa dianalogikan sebagai framework tiap orang sebagai programmer yang memprogram kehidupannya, untuk mengenal framework, harus dilepaskan dulu logika pribadinya. ikuti alur dan mekanisme frameworknya.

dan, yah… ga mudah untuk melepas logika bawaan. karena artinya sudut pandangnya harus diubah. tetapi untuk mengenal sebuah framework/agama, sudut pandang harus diubah mengikuti framework/agama-nya. walaupun ga mudah.

baca selengkapnya..

membandingkan SOAP dan REST webservice

silakan langsung menuju halaman ini
http://blog.nostratech.com/2013/07/membandingkan-soap-dan-rest-webservice.html

baca selengkapnya..

Membuat Custom WebLogic Certificate

membuat custom weblogic certificate, dengan symantec (free trial).
http://blog.nostratech.com/2013/06/membuat-custom-weblogic-certificate.html

baca selengkapnya..

Parsing ISO 8583 dengan jPOS Library

sekilas tentang iso 8583 dan parsingnya dengan jPOS.

http://blog.nostratech.com/2013/06/parsing-iso-8587-dengan-jpos-library.html

baca selengkapnya..

Oracle SOA Outbound SocketAdapter with custom Java translation

http://blog.nostratech.com/2013/05/oracle-soa-outbound-socketadapter-with.html

creating soa composite using socket adapter with custom java implement as reference. can be used to parse an iso8583 message, or fixed-length string message.

baca selengkapnya..

jalur pengiriman

bayangin sebuah kondisi dimana manusia ga bisa bicara langsung dengan tuhannya. mungkin karena jauhnya jarak antara keduanya, atau mungkin karena ada frekuensi yang tertutup antara keduanya sehingga suara yang satu tidak dapat diterima dan diolah oleh yang lainnya. atau mungkin karena perbedaan bahasa sehingga komunikasi tidak dapat diterima dengan baik oleh salah satu pihak, yang ada adalah kesalahpahaman..

ah, apa pun penyebabnya, semua kemungkinan itu akhirnya menghasilkan satu akibat yang sama: yaitu sang manusia ga bisa bicara langsung dengan tuhannya.

manusia mengucap doa. bisa dalam hati, bisa teriak, bisa berupa tulisan, bisa berupa gambar, bisa berbahasa indonesia, bisa berbahasa inggris, bisa berbahasa zimbabwe, bisa berupa apa pun.

seandainya tuhan punya satu bahasa tertentu, yang ga bisa dibayangkan apalagi didefinisikan oleh manusia, mungkin manusia cuman bisa me-label-i bahasa itu sebagai 'bahasa ilahi'. atau seandainya tuhan memiliki frekuensi tertentu untuk menerima segala bentuk komunikasi, dan frekuensi tersebut bahkan belum diketahui eksistensinya oleh manusia. dan seperti biasa, manusia lalu cuma bisa melabelinya sebagai 'frekuensi ilahi' dan seandainya-seandainya yang lain.

manusia ngucap doa, menyatakan kepasrahan, meminta ampun, meminta petunjuk. manusia meminta. manusia mengharapkan 'jawaban' dari tuhannya. kadang kala jawaban itu dirasa tak kunjung datang.

padahal mungkin aja jawaban itu sudah datang beberapa waktu sebelumnya. cuman manusianya aja yang ga bisa nerima atau ngolah jawaban itu. ketidakterhubungan bahasa manusia dengan bahasa ilahi, atau frekuensi manusia dengan frekuensi ilahi.ketersampaian informasi yang tidak kesampaian (halah, ruwet!)..

---

bayangin tuhannya manusia tadi memiliki singgasana di sebuah negri di balik sebuah gunung yang sangat tinggi, yang ga bisa dipanjat oleh manusia, ga bisa dilewatin oleh manusia.

dan malaikat lah yang bisa menjadi perantara antara bahasa manusia dengan bahasa ilahi.

mungkin salah satu solusinya adalah manusia tadi menitipkan doanya ke awan, tepat di atas puncak gunung tinggi yang memisahkannya dengan tuhannya. dan salah satu malaikat di singgasana ilahi akan mengambil doa tersebut dari awan, menerjemahkannya ke bahasa ilahi, dan menyampaikannya ke sang tuhan.

dan mungkin dengan demikian tuhan pun akan dengan leluasa mengolah doa tadi, dan memberikan jawaban, sebuah petunjuk yang diharapkan oleh si manusia. malaikat tadi kemudian akan meletakkan jawaban tuhan tadi ke awan.

dan kemudian mungkin saja ada sesosok malaikat lain, yang bertempat di sisi luar gunung, berada di sisi yang sama dengan si manusia, menyamar sebagai manusia, mengambil jawaban tadi di awan dan menyampaikan ke si manusia dengan bahasa yang dimengerti oleh si manusia.

yah, malaikat ini bisa aja menjelma sebagai seorang bapak, ibu, kakak, adik, teman, guru, atau siapa pun yang bisa menyampaikan pesan tadi dengan baik kepada si manusia. dan akhirnya si manusia itu pun menerima response dari tuhan atas doanya tadi.

dan kehidupannya terus mengalir sebagaimana adanya.
sebuah jalur pengiriman antar dunia. dunia manusia dan dunia ilahi. melalui perantara para malaikat dan standar bahasa yang dimiliki oleh para malaikat itu (yang memang diciptakan demikian oleh sang tuhan tadi).

jalur pengiriman.

---

si subjek meletakkan langsung sebuah pesan di awan. dan dengan seenaknya (bener2 seenaknya) gw istilahkan sebagai 'pelayanan awan', cloud service, atau mungkin dalam konteks informasi, lebih banyak dikenal orang sebagai web service.

pesan yang diletakkan itu adalah sebuah representasi dari apa yang disampaikan oleh subjek. Representational State Transfer, enaknya sih kita singkat aja sebagai REST.

bisa aja pesan itu berupa sekumpulan data request, dalam format tertentu. langsung dikirimkan oleh user melalui protokol HTTP ke alamat (url) tertentu yang terhubung dengan internet. kenapa HTTP? karena hampir semua komputer sekarang memiliki webbrowser, dan semua webbrowser bisa mengolah informasi yang dikirim melalui protokol HTTP.

sesuatu bertugas mengubah data-data yang terkirim tadi ke dalam format xml. kenapa xml? karena xml itu udah jadi sebuah standar bersama mengenai bentuk kemasan data, tujuannya untuk mempermudah pengiriman data antar device.

lalu ada sebuah object yang kita buat untuk mengambil data dari cloud tadi, asiknya sih kita sebut sebagai 'requestClient'. nah si requestClient ini ngambil data berformat xml tadi dan memasukkan nilai2nya ke dalam atribut objek tertentu. object ini kemudian dikirim ke sebuah class lain untuk diproses, dan mengembalikan data-data ke dalam object lain sebagai response.

object requestClient mengambil lagi object response tadi dan mengirimkannya ke webservice untuk response. di sini bisa kita sebut bahwa object requestClient bertindak sebagai 'malaikat dari singgasana ilahi'..

kemudian kita buat sebuah object, misalnya namanya 'responseClient' yang tugasnya adalah ngambil data dari url response tadi dan mengirimkannya kembali ke user. karena kita ga tau pasti si user nge-request dan minta responsenya dalam device apa, asiknya sih kita buat dulu sebuah class 'Adapter' yang tugasnya utk nyesuaiin bahasa/format yang diinginkan oleh user. dan di sini bisa kita anggep Adapter adalah 'jelmaan malaikat yang menerjemahkan bahasa ilahi kepada kita'..

hmm
apaan tuh?

---

jadi ada framework, namanya RESTLet. dia bisa dipake untuk bikin web service tanpa menggunakan SOAP (simple object access protocol). kalo pake SOAP,  ruginya: interoperabilitasnya lebih rendah.

dengan pake sistem REST, interoperabilitas lebih tinggi karena bisa diakses dengan apa aja, selama pengirimannya lewat protocol HTTP. tapi kayanya sih bakal lebih rumit utk ngurusin securitynya (ga tau juga sih, gw belom nyobain securitynya).

dalam RESTLet, web service dinyatakan sebagai sebuah 'resource' dari objek yang mau disimpen di alamat (url) tertentu. dan resource ini diarahkan oleh sebuah terminal/router. dan karena ini adalah aplikasi server, maka pastinja mesti didaptarin tuh terminalnya di web.xml.

---

seandainya bayangan tentang komunikasi antara manusia-malaikat-tuhan emang gitu adanya,
dan seandainya komunikasi make internet sebagai toolnya,
mungkin RESTLet adalah salah satu framework yang bisa digunakan untuk jalur pengiriman informasi(doa/jawaban)nya..

baca selengkapnya..

ga jelas

sebuah siklus umum, berawal dari teori kertas kosong (tabula rasa) -john locke. ketika lahir, manusia digambarkan seperti kertas kosong, dan secara naluri untuk 'mengisi' kertas kosong itu dengan berbagai pengetahuan.

ketika kita datang ke sebuah tempat baru, anggeplah di sebuah tempat yang jauh dari tempat asal kita, apa yang pertama kali harus dilakukan?

menurut gw:
1. mengenal bahasa.
2. mengolah logika kita terhadap bahasa itu
3. mengenal lingkungan (budaya, sosial, dll)
4. baru kemudian mengimplementasikan logika kita ke dalam bahasa yang dikenal, disesuaikan dengan lingkungannya.

kenapa gw anggep ini siklus umum? karena ternyata yang gw liat, belajar programming pun siklusnya sama kaya gitu juga. misalnya belajar bahasa pemrograman java:

1. mengenal bahasa -> dimulai dengan mengetahui (dan membiasakan diri) dengan variabel, keyword, operator, dll

2. mengolah logika -> menggunakan variabel, operator dan lainnya tadi untuk membuat sesuatu, dimulai dari yang sederhana hingga makin lama makin kompleks

3. mengenal lingkungan -> makin kompleksnya kebutuhan logika tadi, 'menuntut' programmer untuk menggunakan IDE (integrated development environment) atau library/framework tambahan.
IDE ada banyak, misalnya eclipse, jdeveloper, netbeans, intellijIdea dan lainnya. masing2 punya keunggulan dan kelemahannya sendiri2.
framework pun ada banyak: misalnya framework untuk membuat tampilan ada tapestry, jsf, zk, dll. framework untuk koneksi database atau untuk controller pun ada banyak variannya.
itu semua baru yang berhubungan langsung dengan pemrogramannya. banyak kondisi yang mengharuskan programmer membuat konfigurasi tertentu dan ini berhubungan dengan operating system yang digunakan, berarti ada baiknya programmer juga menguasai berbagai operating system.
kesemuanya ini adalah bagian dari environment yang harus dikuasai untuk developing.

4. mengimplementasikan -> setelah mengenal lingkungan 'teknis' seperti di poin 3, berikutnya baru lah penerapan sebenarnya dari pemrograman. mendevelop sesuatu, bisa jadi untuk keperluan proyek (pekerjaan) atau pun untuk keperluan studi, atau yang lainnya.

dalam keberjalanannya, poin 3 dan 4 sering kali berjalan beriringan. saat implementasi, ada kalanya kita baru sadar kalo ternyata kita butuh wawasan tentang environment tertentu, dan sambil jalan kita  juga sambil mempelajari environment itu. contoh: kita biasa develop di komputer sendiri dengan operating system windows. tapi dalam keberjalanan proyek, digunakan server yang menggunakan operating system linux. ya mau ga mau dikit2 mesti ngerti linux juga. kalo ga ngerti? mau ga mau mesti belajar juga deh :D (apess..)

life is not only about logics. its also the environment.

jadi inget jenjang kaderisasi di himpunan dulu, ada 4:
1. doktrinasi
2. sosialiasi
3. aktualisasi
4. kontemplasi

kalo dicocok2in, siklus umum yang tadi dijabarin di atas sesuai dengan penjenjangan ini dari poin 1 sampai 3.
-doktrinasi kira2 bisa disejajarkan dengan pengenalan bahasa
-sosialiasi kira2 sejajar dengan mengolah logika dan mengenal lingkungan
-aktualisasi kita2 sejajar dengan implementasi logika (dan bahasa) dalam lingkungan

lalu dimana posisi kontemplasi?

penjabaran tadi kan menggambarkan proses belajar (dan beraktualisasi) secara pribadi. dialami tiap individu. tapi dari sudut pandang organisasi, sebutlah keluarga, temen bergaul, sekolah, kampus atau perusahaan, semuanya memiliki proses regenerasi.

dalam konteks regenerasi inilah kontemplasi dimasukkan. dari bahasa yang 'cuma gitu2 aja' bisa melahirkan logika yang sangat luas, tergantung karakter dan sudut pandang tiap pribadi yang menggunakannya. dan dalam konteks organisasi, perlu ada standar, berarti perlu ada penjaga standar.

life is not only about logics and/or environment. its also the regeneration.

baca selengkapnya..

masalah untuk mengurangi masalah

bayangin kita duduk di sebuah teras, di posisi yang agak lebih tinggi dari aktivitas keseharian, di tengah kota. kita liat kemacetan, kita liat pelanggaran-pelanggaran "kecil" seputar lalu lintas, kita liat trotoar berubah fungsi jadi tempat jualan atau tempat melintasnya motor yang mau ngehindarin macet, bukan lagi tempat yang nyaman bagi pejalan kaki.

dalam hati mungkin kita akan berkata "untunglah gw ga ada di jalan raya yang semrawut itu..", lalu mulai membayangkan asiknya duduk mengamati kesibukan (atau kesemrawutan?) sambil minum segelas kopi panas sambil ngerokok.

lalu kita alihkan pandangan ke lingkungan yang lebih dekat dengan posisi duduk kita. bayangin ada biji kopi yang baru aja disangrai, belom digiling jadi bubuk. bayangin juga seandainya ada sebuah alat, bentuknya kotak, kalo kita masukin biji kopi tadi, ga lama kemudian segelas kopi panas dengan aroma yang menggugah selera telah tiba secara otomatis di samping kita.

trus kita mulai mbayangin lagi, seandainya alat seperti itu emang ada, gimana cara kerjanya?

pasti ada sistem penghancur biji kopi, pasti ada sistem pemanas air, pasti ada sistem penuang bubuk kopi, pasti ada sensor untuk menentukan volume bubuk kopi yang harus dituang (berdasarkan volume gelas dan perbandingan takaran), pasti ada sistem penuang air dan penentu volume air yang mesti dituang (berdasarkan volume gelas dan perbandingan takaran), pasti ada sistem pengaduk, dan terakhir pasti ada sistem 'pengantar' gelas dari alat tersebut sampai lokasi tertentu di samping kita. dan masih banyak lagi masalah yang bisa diajukan terkait dengan alat itu, mengembangkan lagi dari masalah-masalah yang disebutin sedikit di atas.

ada sangat banyak masalah yang harus dipecahkan sebelum hidup kita sedikit lebih nyaman, menyempurnakan hidup.

apa yang menyempurnakan hidup? kenyamanan yang sempurna atau kegiatan yang kita lakukan untuk menyempurnakan kenyamanan itu sendiri? entah, terserah gimana masing-masing orang mempersepsikannya. bisa jadi salah satunya, bisa jadi keduanya.

kenyamanan yang sempurna. kalo kita artikan 'nyaman' sebagai kondisi dimana tidak ada (atau ada tapi sedikit) masalah, berarti untuk mendekati kenyamanan itu kita mesti mengurangi jumlah masalah.

kita balik lagi ke hal-hal yang tadi kita bayangin, ada kondisi lalu lintas, ada alat pembuat kopi, dan mungkin ada yang mbayangin hal-hal lain, ada banyak sekali masalah di sekitar kita. mulai dari masalah aktual (seperti contoh lalu lintas) sampai masalah ideal (berawal dan/atau berada di tataran ide).

dan dengan asumsi bahwa semua hal yang menjadi perhatian kita bermula dari persepsi tertentu kita akan sesuatu itu (semua hal punya potensi untuk jadi masalah, semua hal punya potensi untuk jadi peluang, semua hal punya potensi untuk membuat senang, semua hal punya potensi untuk membuat sedih, dan seterusnya), maka untuk mengurangi jumlah masalah yang mesti kita lakukan adalah berfokus pada satu hal/masalah/bidang/apapun.

dalam contoh kasus alat pembuat kopi otomatis tadi, keseluruhan sistem kerja terbagi jadi 7 subsistem. tiap subsistem memiliki masalah-masalahnya masing-masing. bayangin kalo 1 orang mau ngerjain semua itu sendiri. kebanyakan masalah tuh orang ntar, ksian..

pembagian sistem ke dalam subsistem itu sendiri udah merupakan upaya pengurangan masalah. berikutnya, mending dibagi-bagi aja masalah itu ke beberapa orang. misalnya 1 subsistem dibebanin ke 1 orang. bukan ga mungkin nantinya tiap subsistem ini akan terbagi jadi beberapa subsistem lagi. tergantung tingkat kesulitannya.

untuk ngehemat waktu, enaknya sih tiap subsistem itu dikerjain paralel. berarti yang perlu dilakukan berikutnya adalah bikin interface untuk komunikasi antar subsistem itu. misalnya interface antara sistem penghancur biji dengan sistem penuang bubuk kopi.

di sini orang yang ngerjain sistem penuang mesti ngasih tau kebutuhannya untuk memulai sistemnya. misalnya: dia butuh tau kopi udah jadi bubuk atau belum dan berapa volumenya. sepakatin dulu, kalo kopi udah jadi bubuk, sistem penghancur akan ngelempar variabel String bernilai "OK", dan akan ngelempar variabel double bernilai volume bubuk kopi.

baru deh sekarang orang yang ngerjain bubuk kopi bisa kerja, acuannya: dia mesti ngehasilin output String "OK" dan double volume bubuk kopi. dan orang yang ngerjain sistem penuang mengacu sama begitu ada variabel String "OK" nyampe ke sistemnya, dia akan ngecek berapa jumlah volume bubuk kopi, ngecek berapa volume gelas, dan ngaktifin sistem penuangnya.

jika kita adalah orang yang ngerjain sistem penghancur, kita ga usah mikirin sistem2 lainnya. yang penting kan udah jelas apa outputnya yang perlu kita hasilin. selanjutnya mungkin kita bisa mulai dengan 1. sensor (atau 'listener') utk ngecek apa ada biji tertuang, 2. proses penggilingan, 3. pengukuran volume, 4. media untuk melempar pesan ke interface.

gitu tuh, ternyata di dalam (sub)sistem penghancur, masih beranak lagi jadi 4 (sub)subsistem. mau bagi2 tugas lagi? atau mau dikerjain sendiri? terserah. yang pasti, utk mulai ngerjain kita perlu nyiapin interface lagi antar (sub)subsistem. 4 subsistem berarti 4 masalah. mau ngurangin masalah? kita pilih aja satu subsistem, sisanya dibagi-bagi ke orang lain.

misalnya kita pilih proses penggilingan. berarti kita mesti nunggu pesen yang masuk dari sistem listener, sepakatin dulu apa kode yang akan dilempar sama sistem listener, misalnya String "lanjut!". nah sekarang proses penggilingan akan digenerate sama sistem yang nerima kode String "lanjut!". program akan mengatur tegangan mana yang diaktifkan untuk njalanin mesin penggiling. kemudian bubuk kopi yang udah tergiling akan 'dijatuhkan' di sebuah wadah di bawah mesinnya.

lalu mungkin kita bisa nari sebuah timbangan digital di bawah wadah itu dan menyambungkannya dengan interface pengukuran volume. jika berat wadah > 0 maka sebuah kode akan terkirim ke interface dan interface itu akan ngelanjutin ke sistem pengukuran volumenya. tapi tenang, ini bukan masalah kita. ini masalahnya orang yang ngerjain pengukuran volume. dan seterusnya..

setelah semua orang selesai dengan kerjaannya masing-masing. tinggal dites deh hasilnya. masukin biji kopi ke alat dan lihat apa yang terjadi selanjutnya, pasti bisa dilacak di sistem mana terletak kesalahannya (kalau ada). dan biarkan orang itu bertanggung jawab sama kerjaannya (kalo orangnya udah ga ada, sepakatin aja siapa yg mesti beresin itu)..

jadi sejauh ini apa yang bisa disimpulin?
menurut gw,
1. secara manusiawi tiap orang akan bergerak menuju kenyamanannya masing-masing dengan membatasi lingkup perhatian dan pekerjaan sesuai minatnya (mengurangi scope masalah yang dihadapi). dan pada akhirnya kegiatan ini akan menghasilkan spesifikasi (atau keahlian spesifik) dari orang itu.

2. dengan simpulan 1, kita mesti siap dengan pertanyaan: "lu orang atau bukan? kalo lu orang, apa spesifikasi lu?". dan mungkin hal ini udah jadi trend di masa sekarang, dimana tiap orang akan menangani masalah tertentu yang spesifik di dalam sebuah keseluruhan sistem besar. istilah kerennya: outsourcing.

3. dari simpulan 2, ngeliat maraknya outsourcing sekarang ini, interfacing bisa dilihat sebagai satu titik vital dari semua sistem. bermain di zona interface berarti menggunakan sudut pandang bahwa keseluruhan sistem terbagi jadi beberapa subsistem yang saling berkomunikasi satu sama lain.

baca selengkapnya..

apalah aku

begitu tombol 'OK' ditekan, aku pun meluncur. entah tenaga apa yang mendorongku, tapi aku bersama kawananku terlontar bersamaan menyusuri lekuk liku jalur yang tidak kuketahui liukan dan kemana tujuannya. baiklah, aku ikut saja. dorongan itu terlalu kuat untuk kulawan, toh setidaknya kawananku masih berada di sekitarku.

kami berdiri berurutan, dalam satu barisan panjang, di atas sebuah gerbong panjang dan sempit yang meluncur dengan kecepatan tinggi. tapi aneh juga, kami stabil di atasnya.

dalam waktu singkat kami sampai di sebuah ruangan besar. ruangan ini penuh kesibukan. riuh sekali. satu persatu kami di dalam barisan diminta untuk maju, dan saat tiba giliranku suatu sosok di depanku (entah apa dia, aku ga pernah mengenal sosoknya) melihatku sesaat dan mengucapkan sesuatu pada kawannya.

kawan dari sosok itu mencatat apa yang dikatakannya, kemudian pergi. tidak lama kemudian dia kembali, membawakan sebuah papan bertali untuk ku kalungkan di leherku. aku tidak tau apa yang tertulis di papan itu, karena tidak lama kemudian sebuah sel kecil (kandang berterali) tiba di depanku dan aku didorong masuk ke sana.

begitu aku masuk, pintunya langsung ditutup. dan sel ini mulai meluncur, ke sebuah ruangan besar, dan kulihat kawan-kawanku tadi juga berada di dalam selnya masing2. kami masing-masing dipisahkan satu sama lain, tapi dijajarkan bersama-sama. apa maksudnya ini??

belum sempat pertanyaanku terjawab, sel-sel kawananku berikutnya mulai menyusul dijajarkan bersama kami. dan segera saja sel-sel kami mulai meluncur kembali dalam sebuah lorong gelap. posisi kami masih sama seperti waktu luncuran pertama tadi, berurutan satu per satu dalam sebuah barisan panjang, hanya bedanya kini kami berada di dalam sel kami masing2.

rasanya cepat sekali waktu berlalu, kami tiba di sebuah ruangan besar lagi, yang juga penuh kericuhan. tepat di tengah ruangan besar ini terdapat semacam court luas, yang terbagi-bagi berdasarkan kode-kode tertentu, dan kode itu menempel di sebuah kursi.

selku langsung mengarah ke salah satu kursi dan berhenti tepat di sampingnya. secara otomatis pintu itu terbuka dan sekali lagi aku merasakan dorongan sehingga aku pun terlempar keluar dari sel dan jatuh terduduk di kursi itu. dengan cepat sebuah seat belt membelit tubuhku dan kini aku sudah terikat erat di kursi itu. selku tiba2 berputar dan meluncur kembali ke arah datangnya tadi. baru aku sadari ada sebuah kode di atas tiap sel, entah kode apa itu dan apa artinya.

dalam sekejap kursi yang kududuki bergerak melaju dengan kencang. kulihat kawananku pun mengalami hal yang sama dengan kursinya. kembali melewati lorong panjang, dan tiba di sebuah ruangan besar lagi. dan sekali lagi kami semua dilemparkan ke sebuah wadah berkode tertentu. tiap satu dari kami mendapat satu wadah sendiri.

tak berselang lama, suatu sosok kembali mendatangiku dan memperhatikanku cukup lama, kemudian dia mengatakan sesuatu kepada kawannya yang segera mencatat dan pergi. kulihat kawananku pun mengalami hal yang sama. si sosok tadi akhirnya kembali bersama sosok lain yang kukira mirip dengan diriku dan kawananku.

kulihat nametag di dadanya, sempat terbaca sekilas "responseCode". dia didorong untuk duduk di wadah yang sama dengan kami, dan dengan segera, kursi yang tadi membawaku ke ruangan ini kembali lagi di sampingku.

wadahku meninggi dan mulai memutar seakan hendak "menuang" diriku ke atas kursi tadi. aku pun lagi2 jatuh ke kursi itu yang langsung mengikatku dengan seatbeltnya. setelah semua kawananku mengalami hal yang sama, kursi ini kembali melaju cepat melewati lorong yang tadi.

dan proses seperti awal tadi kembali berulang, tapi kebalikannya. sampai kusadari aku telah berada di ruangan pertamaku sebelum tombol "OK" ditekan. semua yang kupakai dipreteli, nametag-ku dilepas dan sesuatu menarikku ke sebuah sandaran, aku tertempel di sana. dan tidak lama aku meluncur keluar dari ruangan gelap itu.

aku muncul ke dunia, melalui sebuah kertas tipis. dan kulihat ada manusia di atas sana menarik sandaranku yang berupa kertas tipis. kurasakan kertas sandaranku pun berpindah tangan ke manusia lainnya yang melihat diriku dengan seksama sebelum akhirnya meremukkan sandaranku dan melemparkannya ke sebuah tempat yang sempat kulihat bertuliskan 'recycle'..

belakangan kuketahui bahwa ternyata aku tidak satu. aku berada di semua wadah yang kududuki, sebelum luncuran lain menghapus diriku dari semua wadah itu.

apalah aku ini. pasif, terduplikasi, terlempar kesana kemari. jika aku dapat memilih ketika dilahirkan, aku akan memilih jadi seorang manusia yang dapat beraktivitas di dunia nyata, bukan sebagai data 'amountTransaction' yang pasif di dunia digital..

baca selengkapnya..

request-respons

respons.
pengen dapet respons? kirim request lah.

anggeplah kita punya beberapa parameter untuk dijadiin request. kita lempar lah request ini ke sebuah sistem.

kalo sistemnya adalah engine transaksi keuangan bisa jadi responsnya cuma berupa kode '00' jika berhasil atau '06' jika gagal.

kalo sistemnya adalah halaman website, responsnya adalah tampilnya halaman yang dipanggil.

kalo sistemnya adalah orang, bisa jadi responsnya adalah kalimat 'ga tau..' atau mungkin malah '......' (alias dicuekin).

yah, bisa macem2 bentuk respons. tergantung kaya gimana requestnya dan kaya gimana kelakuan sistem yang diharapkan utk ngerespons.

dengan adanya respons, kita jadi kenal sama sistemnya, dan kita tau gimana harus bertindak (utk ngerawat sistemnya, atau utk manfaatin sistemnya, atau untuk mbenerin sistemnya, atau apa pun lah).

dulu dosen gw bilang: "kalo mau kenal sama suatu sistem, kasih lah gangguan ke sistem itu dan liat responsnya". kira2 mirip lah, anggep aja tiap request adalah gangguan bagi internal sistem itu. maksudnya, misalnya si sistem lagi bengong, atau lagi diem (lembam lah pokoknya), trus kita kasih pertanyaan atau perintah, itu kan gangguan untuk ke-diem-annya, dia jadi mesti njawab atau mesti nyuekin, atau mesti ngerjain perintahnya.. gangguan lah.

apapun responsnya, kalo ga sesuai keinginan, yaudah itu lah dia. (cukup tau aja lah..), kalo sesuai keinginan yaudah alhamdulillah.

tapi yang pasti, tiap sistem butuh gangguan (atau request) biar dinamis.
dan eksternal butuh mengganggu untuk bisa ngenal sistem itu (dari responsnya).

tapi jangan lupa juga, request-response kan bentuk komunikasi. yang namanya komunikasi pasti nyediain tempat untuk adanya kesalahpahaman. sistem salah nangkep maksud request (jadi responsnya ga sesuai harapan). atau justru requestnya yang salah sehingga respons yang diinginkan pun ga tercapai. atau bisa jadi requestnya bener, responsnya bener, tapi si pemberi request yang salah nangkep arti responsnya (salah nerjemahin).

semua itu bisa terjadi, siap2 aja.

di luar dari segala tetek bengek dan suka duka dalam merequest dan merespons, jelas request ga bisa gitu aja dilakukan.

misalnya, kita ga bisa langsung nge-request ke servernya fesbuk untuk nampilin foto orang tertentu yang kita pengen (dengan langsung ngeklik alamat url-nya foto itu). minimal kita mesti login dulu. setelah login, profil kita juga mesti 'diijinin' untuk ngeliat foto2 itu dari si empunya foto.

atau yang lebih simpelnya lagi, bahkan untuk bisa login di fesbuk kita mesti buka dulu koneksi internetnya. kegiatan 'login' juga adalah merupakan request ke sistem aplikasi web.

perlu ada session yang dibuka sebelom kita ngerequest. dan perlu ada request yang dilempar sebelom kita dapet respons.

tenang aja, kita ga perlu berasal dari halaman http untuk bisa ngelempar request dan nerima respons dari halaman http. yang penting kita nyiapin akses untuk komunikasinya aja. kita buka aja koneksinya, trus alirin datanya.

kita ga perlu jadi pangeran utk bisa ngegodain (ngerequest) seorang puteri cantik. dan kita juga ga perlu jadi pangeran untuk bisa dibentak2 (respons) sama si puteri cantik tadi. kita cuma perlu berada di tempat yang dia lewatin, atau tau nomer telponnya (atau bahkan ym/fbnya :D).

kita bisa berasal dari mana aja. kita bisa jadi siapa pun diri kita sebenernya.

kalo kita adalah class java, sebagai client, yang penting kita open HttpUrlConnectionnya, kita printStream parameter2nya, dan post ke url-nya server yang kita inginkan, dan siapin HttpUrlConnection utk nerima respons dari server itu. kalo koneksi berhasil terbuat, kita akan dapet respons pertama kode '201', kalo dicuekin (mungkin karena salah alamat) kita akan dapet respons kode '404'. dan kalo kita berhasil konek tapi ga dibolehin ngakses dia, kita akan tetep dapet respons, yaitu kode '401' atau '403'.

kita bisa cegat si puteri di tempat dia beraktivitas, setelah dia lewat di tempat kita, kita bisa buka sessionnya dengan bilang 'eh..', kalo dia nengok berarti connection/session is created (bisa dilanjutkan dengan mengirim request). kalo ga nengok, tendang aja kakinya dan bilang 'sori..' kalo dia senyum trus ngajak kita kenalan berarti responsnya = transaction success. kalo dia cemberut jangan kecil hati, paling ga dia udah ngerespons request kita (minimal itu artinya koneksi/sessionnya udah kebuka).

kalo dirasa responsnya masih kurang untuk kita ngecek apakah sessionnya udah kebuka, angkat aja roknya. dan session (plus rok!) pasti terbuka, dengan request pertama adalah ngangkat rok, dan respons pertamanya adalah tamparan.

berhasil! session terbuka, kita uda ngerequest dan udah dapet respons. dengan demikian urusan selanjutnya bisa jadi lebih mudah, tinggal disesuaikan aja requestnya untuk dapetin respons yang diinginkan.

hal yang menyenangkan dalam pihak Client: kita bisa agresif dan kreatif dalam memberi request dan bisa leluasa menerjemahkan responsnya.

dengan mengingat kesenangan itu,
dengan mengingat bahwa interaksi tidak lebih dari sekedar request dan respons,
lets just make a move for a session.

baca selengkapnya..

petualangan bersama ADF dan JSF

BUTUT (BUkan TUTorial).
entah bener entah salah, yang penting review dulu sebelom lupa :D

baru kenalan sama IDE Oracle JDev dan framework ADF.
jadi apa rupanya ADF itu? Application Development Framework. sebuah framework untuk mengembangkan aplikasi. aplikasi apa? yang lagi gw pelajarin sih pembuatan aplikasi enterprise, pake java ee. dimulai dari tampilan yang akan dilihat melalui web browser, dan berujung pada pengaksesan data di database.

ini adalah sebuah cerita melalui sudut pandang gw tentang sudut pandang ADF dalam mengembangkan sebuah aplikasi web.

di sebuah sisi yang gelap dan berbatu tersebut lah sebuah data di database, dia dikemas dalam sebuah model, boleh lah model ini kita sebut aja ApplicationModul (tidak mesti nama sebenarnya, tapi boleh aja. btw tadi 'model', sekarang 'modul'. bentar lagi 'modol' nih!). baiklah jika demikian, kita gunakan kesimpulan bahwa dia bernama 'ApplicationModol'.

sementara di sisi lain yang meriah dan menarik, yaitu sisi tampilan web browser ada sebuah halaman yang akan menampilkan tabel, atau form atau apa pun lah yang diharapkan dapat terhubung dengan data yang gelap di database. oke lah kita sepakatin aja, ada form untuk menginput data ke database.

yang jadi pertanyaan misterius, apa yang terjadi di antara mereka? siapa yang tega memisahkan (atau justru menyatukan??) mereka? sejauh yang gw perhatiin, gw curiga sebenernya ada pihak ketiga di antara mereka. boleh lah kita sebut dia DataBinding. memang luar biasa si DataBinding ini. gw curiga, sebenarnya dia lah otak dari kerangka kerja ADF.

---

di dalam DataBinding.cpx ada 'pageMap', yang tugasnya nge-list semua page yang akan dipake di dalem aplikasi, trus menyuruh sebuah 'usageId' untuk menyertai tiap halaman tersebut melalui salah satu divisinya, yaitu 'PageDefinitionUsage'. ada sebuah 'halamanPageDef' yang menumpang sama 'usageId' tadi.

berikut contoh kode yang ada di DataBinding.cpx:

kita (mungkin) bisa menganggap bahwa BC4JDataControl (atau kita singkat aja 'DataControl') adalah sebuah perwakilan dari ApplicationModol. dimana ApplicationModol (objek yang ada di dalam package ini.bukan.tutorial.applicationmodol.am) adalah integrasi dari objek entity dan objek view. objek entity adalah perwakilan dari objek (mungkin merujuk ke tabel) di database yang bisa digunakan dalam pengaksesan. sedangkan objek view adalah perwakilan dari field-field di tabel data.

---

sekarang dimana persisnya ada hubungan antara Halaman.jspx dengan class java? di atas tadi kita udah liat hubungan antara Halaman.jspx dengan HalamanPageDef.xml. nah ternyata class java (kita kasih nama aja Halaman.java) bisa berhubungannya sama HalamanPageDef.xml. hubungan ini diaturnya sama face-config.xml. apaan tuh face-config? ternyata itu adalah bantuan dari framework JSF (JavaServer Faces).

ada bagian 'managed-bean' yang fungsinya adalah ngehubungin HalamanPageDef.xml dengan Halaman.java, bagian ini bisa kita liat dari cuplikan kode di face-config.xml ini:

nah sampe sini, kita bisa bayangin tiap data dari input di Halaman.jsx akan dilarikan ke HalamanPageDef.xml oleh DataBinding.cpx. kemudian data itu diterusin sama si HalamanPageDef.xml ke Halaman.java untuk diproses lebih lanjut.

kemudian data dioper lagi ke DataControl di DataBinding.cpx (gw masih belom nemu gimana persisnya proses pelemparan data ini (gw curiganya ada koordinasi yang baik sekali antara JSF dengan ADF di bagian ini, tebakan gw melalui class ValueBinding dan/atau FacesContext (dari JSF) dengan class DCDataControl dan/atau BindingContainer (dari ADF)).

Kalau..
sekali lagi, kalau.. kerjasama antara JSF dan ADF tadi memang begitu adanya, maka kemungkinan besar DCDataControl lah yang akan meneruskan data ke objek entity ApplicationModol.

sampai di sini, data input dari Halaman.jspx di webbrowser udah sampe di ApplicationModol, dan siap diteruskan untuk meng-update database. sebelum transaksi dilakukan, terlebih dulu DataControl akan mengecek kesesuaian data yang masuk dengan data di database. misalnya, mungkin, apakah input sesuai dengan field yang ada di database, apakah semua field di database yang harus terisi sudah memiliki nilai inputnya masing2, dan seterusnya.

kalau udah oke, maka ApplicationModol yang akan melanjutkan amanah dari pengguna web browser itu untuk meng-update database.

---

sampe sini mungkin baik untuk kita inget lagi bahwa ApplicationModol terdiri dari object entity DAN object view. tadi object entity udah berperan, sekarang dimana peran object view? jangan2 makan gaji buta doang tuh mahluk??

tergantung. tergantung apakah si pengguna minta data di database untuk ditampilin di web browser atau ngga. biar ga magabut (makan gaji buta) akhirnya si pengguna minta data di database untuk ditampilin di webbrowser melalui HalamanLain.jspx.

di sini face-config berfungsi lagi. selain managed-bean, dia juga punya bagian navigation-rule yang tugasnya adalah membaca apa keinginan pengguna melalui sebuah variabel String dan kemudian menyiapkan HalamanLain.jspx untuk menampilkan sesuatu jika variabel String itu terpanggil.

ini cuplikannya dari face-config.xml:

ini artinya tiap ada nilai 'tambahData' disebut dari Halaman.jspx maka HalamanLain.jspx akan  ditampilkan setelahnya.

---

biasanya sih setelah nginput data, pengguna pengen liat keseluruhan data yang ada. maka tugasnya HalamanLain.jspx adalah untuk nampilin data dari database. tadi Halaman.jspx memiliki hubungan dengan DataBinding dan HalamanPageDef, dan begitu juga lah si HalamanLain.jspx. dia punya hubungan dengan HalamanLainPageDef.xml dan juga DataBinding.

tapi hubungan HalamanLainPageDef dengan DataControl di DataBinding.cpx adalah pada bagian view objectnya si ApplicationModol (HalamanPageDef berhubungannya sama object entity) karena tugasnya adalah menampilkan data.

skemanya kurang lebih sama dengan proses di awal tadi (input data), bedanya adalah jika pada saat input data, komponen yang ada di form pada Halaman.jspx menyampaikan data ke HalamanPageDef.xml, sedangkan pada penampilan data, komponen yang ada di tabel pada HalamanLain.jspx memanggil data dari HalamanLainPageDef yang akan memaksa HalamanLain.java untuk memanggil data dari DataBinding yang akan memerintahkan ApplicationModol untuk mengaktifkan object viewnya yang berisi query untuk memanggil data-data di database.

---

proses di atas kurang lebih disesuaikan dengan life cycle umum dari ADF:
1. initialiation
2. restore view
3. apply input request
4. update model value
5. validate model value
6. invoke application
7. render response

---

yang masih jadi pertanyaan adalah:
1. gimana persisnya hubungan class ValueBinding dan/atau FacesContext (dari JSF) dengan class DCDataControl dan/atau BindingContainer (dari ADF)?
2. bener ga sih semua yang gw tulis di atas? :D

baca selengkapnya..

antusiasme dan manajemen data

waktu yang tepat untuk rehat sebentar. orang-orang udah pada tidur. enak, sepi.

jadi di sini lah gw berada sekarang, di sebuah rumah kontrakan dengan 1 rumah utama dan 10 kamar. ngumpul bareng beberapa temen dengan ide dan cita-cita yang sama, nyoba ngembangin diri dalam sebuah grup, masih nyoba menghidupi diri dengan proyek lepas. dengan fasilitas seadanya, dengan kemampuan semampunya, dengan cita-cita dan kemauan belajar sebesar-besarnya. tercatat 12 orang udah bergabung, 2 kamar dan 1 rumah utama (kebagi jadi 4 bagian) udah terkontrak.

jadi di sini gw belajar jalan ke suatu tujuan tertentu, pada jarak tertentu dari tempat awal, nyoba membaginya dalam beberapa tahapan, yang kemudian dibagi lagi dalam satuan-satuan langkah kecil. tiap kesalahan atau keambiguan di suatu langkah bisa mengakibatkan kesalahan atau keambiguan pada langkah berikutnya. di sini juga gw belajar tentang memberi perintah, menjalankan perintah dan menampilkan hasil perintah. bahwa ternyata memberi, menjalankan dan menampilkan hasil perintah masing-masing punya tingkat kesulitannya sendiri-sendiri.

berulang-ulang terlintas di pikiran, bahwa dunia ini diciptakan bagi orang-orang yang memiliki antusiasme terhadap hal tertentu. antusiasme berawal dari minat. minat bisa berawal dari tuntutan atau dari keingintahuan. minat menghasilkan kemauan untuk belajar. kemauan untuk belajar menghasilkan kegiatan. kegiatan menghasilkan keahlian. dan dengan keahlian kita bisa mengambil peran.

ngomong-ngomong soal peran: ada peran, ada fasilitas, dan tentunya ada tipe akses yang dimiliki tiap peran itu terhadap fasilitas yang ada. tidak semua fasilitas bisa diakses dengan cara yang sama oleh semua peran. terima aja, emang gitu adanya. sama seperti admin yang memiliki akses tak terbatas atas data-data di sebuah instansi, melebihi akses yang dimiliki sama pimpinan proyek, pemilik proyek, dan pekerja proyek.

---
jadi sejauh ini gw tuh mau nulis apa? entah, blom kepikiran.. yang penting kejar setoran dulu untuk ngisi archive bulan desember.
---

gara-gara barusan nulis data, baru inget lagi bahwa beberapa minggu terakhir ini pikiran gw dipenuhin sama gimana caranya ngatur data-data sedemikian rupa biar gampang diaturnya. mulai dari masukin data, ngehapus data, ngerevisi data dan ngatur keterkaitan antar data. orang-orang bilang semua kegiatan tadi bisa dimasukin jadi 1 variabel namanya database. keterkaitan antar data, perubahan satu data bisa ngakibatin perubahan dari banyak data lainnya.

misalnya sebuah perusahaan: punya data keuangan, data karyawan, data proyek. dalam data keuangan ada data tiap karyawan (dan gaji2nya), data tiap proyek (pengeluaran dan pemasukannya, waktu pelaksanaannya). dalam data karyawan ada data nama, alamat, gaji dan ada juga data proyek (tiap karyawan terlibat di proyek apa aja, peran masing2 di proyek itu apa aja, dll). semua saling terkait, gimana cara ngerumusin keterkaitannya? gimana cara ngebagi perumusan itu jadi langkah-langkah kecil? gimana cara nyampein langkah-langkah kecil itu dalam barisan perintah? gimana cara ngecek/ngukur ketepatan hasil tiap perintah? gitu deh.

---
jadi ngelantur kemana-mana deh, lanjut aja lah.
---

jadi inget sama keteraturan singapur. dengan sebuah kartu, kita bisa ngakses kereta MRT, bis dan minimarket 711. cara nggunainnya kira-kira mirip sama pulsa hp. si kartu itu dibeli dengan harga tertentu dan berisi nilai tertentu (sama kaya beli pulsa), penggunaannya:

pas masuk stasiun MRT kartu itu kita tempelin di sebuah mesin (yang nyatet lokasi stasiun dan nyatet jumlah pulsa di kartu) trus tinggal naik aja ke keretanya, pas turun dan keluar stasiun kita nempelin lagi kartunya (yang nyatet dan mbandingin lokasi stasiun berangkat dan lokasi stasiun pas turun - kalo ga keluar stasiun berarti dianggepnya ga ada perpindahan, pulsa ga berkurang).

penggunaan lain pas naik bis, begitu naik bis kita nempelin kartu itu di sebuah mesin yang nyatet lokasi kita naik, dan pas turun kita nempelin lagi ke mesin lain yang nyatet lokasi kita turun, pengurangan pulsa bergantung jarak antara naik dan turun). contoh di 711 gw ga sempet nyobain, ke minimarket gituan paling utk beli rokok, tapi rokoknya mahal banget (pulsa di kartu gw selalu ga pernah cukup utk beli rokok).

---

nah lho, kira-kira gimana tuh sistem manajemen data transportasinya? gw kebayangnya gini:

tiap kartu punya data jumlah_pulsa. tiap stasiun MRT punya data nomer_ID_stasiun, data jarak antar stasiun dan method pengurangan_jumlah_pulsa . tiap bis 'terhubung' sama halte. tiap halte punya data nomer_ID_halte dan tiap ada bis dia 'ngirim' data ID itu ke mesin yang ada di bis. tiap bis punya method pengurangan_jumlah_pulsa. bentuk keterhubungannya bisa jadi ada sistem komunikasi bis-halte, bisa juga ada tombol di dalem bis yang meng-generate nomer_ID_halte berdasarkan urutan di databasenya.

tiap kartu juga punya tabel_sementara yang isinya nomer_ID_naik dan nomer_ID_turun. masing-masing nomer ID itu sifatnya sementara (cuma bertahan dalam tiap pasang naik-turun) selebihnya data di 2 tabel itu dihapus lagi. tiap bis juga punya tabel_sementara yang gunanya untuk penyimpanan sementara nomer_ID_halte. selama bis berenti di halte, data itu kesimpen dan 'dioper' ke tabel_sementara di tiap kartu yang ditempelin.

karena ada 2 mesin di bis, berarti 1 mesin tugasnya masukin nomer_ID_halte ke tabel nomer_ID_naik di kartu, dan 1 mesin lagi tugasnya masukin nomer_ID_halte ke tabel nomer_ID_turun dan langsung masukin parameter jumlah_pulsa,  nomer_ID_naik dan nomer_ID_turun itu ke sebuah method pengurangan_jumlah_pulsa yang memproses (mengkalikan jarak dengan satuan pengurangan) dan me-return nilai pengurangan jumlah pulsa untuk nggantiin data jumlah_pulsa di kartu. berikutnya mesin ini juga ngehapus data nomer_ID_naik dan nomer_ID_turun di kartu.

kalo di MRT, prosesnya mirip2 gitu juga, mungkin bedanya: tiap ada kartu yang ditempelin, mesin akan ngoper nomer_ID_stasiun dengan syarat: 'kalo tabel nomer_ID_naik kosong maka nomer_ID_stasiun dimasukin ke tabel nomer_ID_naik, jika tabel nomer_ID_naik berisi nilai tertentu maka nomer_ID_stasiun dimasukin ke tabel nomer_ID_turun' dan langsung masukin 2 nilai itu dan nilai jumlah_pulsa sebagai parameter di method pengurangan_jumlah_pulsa yang me-return nilai ke kartu untuk menggantikan data jumlah_pulsa. berikutnya mesin ini juga ngehapus data nomer_ID_naik dan nomer_ID_turun di kartu.

untuk yang 711, mungkin mesin di kasirnya masukin nilai jumlah_harga_barang dan data jumlah_pulsa ke method pengurangan_jumlah_pulsa dan kemudian me-return nilai hasilnya untuk nggantiin nilai jumlah_pulsa sebelumnya.

kalo mau dipilah-pilah properti dan aktivitas di tiap objek:

objek: kartu.
atribut: jumlah_pulsa, nilai temporary nomer_ID_naik dan nilai temporary nomer_ID_turun.

objek: mesin di stasiun MRT.
atribut: nomer_ID_stasiun.
method: pengurangan_jumlah_pulsa(jumlah_pulsa, nomer_ID_naik, nomer_ID_turun),  penghapusan_nilai_temporary(nomer_ID_naik, nomer_ID_turun).

objek: mesin di bis. 

atribut: nilai temporary nomer_ID_halte. 

method: pengurangan_jumlah_pulsa(jumlah_pulsa, nomer_ID_naik, nomer_ID_turun),  penghapusan_nilai_temporary(nomer_ID_naik, nomer_ID_turun).

objek: mesin kasir 711. 

atribut: nilai temporary jumlah_harga_barang.

method: pengurangan_jumlah_pulsa(jumlah_pulsa, jumlah_harga_barang),  penghapusan_nilai_temporary(nomer_ID_naik, nomer_ID_turun).

objek: mesin pengisi pulsa

atribut: nilai temporary jumlah_pengisian_pulsa.

method: pengisian_pulsa(jumlah_pulsa, jumlah_pengisian_pulsa),  penghapusan_nilai_temporary(jumlah_pengisian_pulsa).

---

kapan ya indonesia (khususnya bandung) bisa make skema se-sistematis itu (atau lebih baik lagi) untuk sistem transportasinya, gw mau lah jadi bagian yang ngerjain sistem manajemen datanya.

baca selengkapnya..