Bingungnya Puasa di Indonesia

Bukan hari rayanya yang bikin bingung, tapi pemerintahnya yang bikin bingung. Karena defaultnya Ramadhan tuh 29 hari, kalo gak terlihat bulan baru dibulatkan 30 hari. Nah di Indonesia ini udah bertahun-tahun Ramadhan selalu 30 hari (setidaknya yang masih ada dalam ingatan, 4 tahun berturut-turut). Apa yang salah di Indonesia? Kenapa di wilayah timur tengah selalu 29 hari dan 30 hari adalah kasus? Bahkan, tetangga kita Malaysia saja selalu 29 hari dan 30 hari adalah kasus. Untuk itu, dengan berserah diri kepada Allah SWT dan dengan alasan bahwa berpuasa pada hari raya adalah haram, serta keyakinanku bahwa beragama tidak dipengaruhi oleh posisi geografis kita dan harus terbebas dari kepentingan politik manapun, dengan tetap berserah diri kepada Allah, hari ini aku batalkan puasaku dan apabila memang perlu, Insya Allah aku akan berpuasa di lain hari.

http://www.detiknews.com/read/2011/08/29/234309/1713375/10/arab-saudi-juga-rayakan-idul-fitri-selasa-30-agustus?n991102605

http://www.detiknews.com/read/2011/08/29/230814/1713372/10/kbri-tokyo-gelar-salat-id-30-agustus?nd992203605

http://www.detiknews.com/read/2011/08/29/221722/1713368/10/malaysia-rayakan-idul-fitri-besok?nd992203605

http://nasional.kompas.com/read/2011/08/29/21220098/Lebaran.di.Malaysia.pada.Hari.Selasa.30.Agustus

Migrasi PowerBuilder Application Server ke Enterprise Application Server

Latar Belakang

PowerBuilder Application Server adalah feature yang disediakan oleh Sybase PowerBuilder untuk mengembangkan aplikasi  n-tier.  Dengan menggunakan fitur ini, seorang developer bisa mengembangkan server application dan client application dengan hanya menggunakan PowerBuilder.  Lebih jauh lagi, server yang dikembangkan dengan menggunakan fitur ini mempunyai reliabilitas yang cukup baik. Namun, ada masalah pada skalabilitasnya dimana selain bergantung kepada kapasitas windows operating systemnya juga bergantung pada kemampuan powerbuilder application server yang tidak bisa menghandle lebih dari 255.

Permasalahan berikutnya yang tidak kalah pentingnya adalah kenyataan bahwa fitur PowerBuilder  application server sudah tidak bisa lagi ditemui pada PowerBuilder versi terakhir.  PowerBuilder versi 7.0.3 adalah versi terakhir yang masih membawa fitur powerbuilder application server.  Sementara, PowerBuilder 7.0.3 adalah versi yang dioptimized untuk windows 9x . Windows XP masih bisa digunakan namun potensi kejadian error lebih banyak bila dibandingkan dengan Windows 9x.

Saat ini, sistem operasi windows yang umum dipakai adalah windows 7.  Sistem operasi ini, bila dilihat dari tampilannya akan membuat orang berfikir bahwa Microsoft telah membuat suatu lompatan lagi seperti  yang pernah dia lakukan dari Windows 3.1.1 ke Windows 9.5.  Apalagi bila mau memperhatikan perkembangan sampai munculnya windows 7 yang didului dengan Windows Vista yang kemudian dikenal sebagai produk gagal.  Artinya Windows 7 seakan dibuat untuk memperbaiki kegagalan windows vista.  Artinya lagi, Windows 7 berbeda dengan Windows Vista dan sangat berbeda dengan Windows XP apalagi windows 9x.

Dalam hal lain, memang Windows Emulator atau disingkat sebagai wine bisa menjalankan beberapa aplikasi windows dengan baik pada environment, apalagi Microsoft dengan Windows nya pada environment windows; tentunya Microsoft  akan tetap mempertahankan kompatibilitasnya terhadap aplikasi-aplikasi windows versi sebelum windows 7.  Namun dalam satu kesempatan pernah ketika membuka library yang berasal dari direktori yang berbeda dengan menggunakan PowerBuilder 7.0.3 pada Windows 7, yang muncul pada box library list hanya file-file library dari direktory terakhir. List File-file yang telah terbuka  yang berasal dari direktory lain sebelumnya hilang.  Suatu behaviour menyimpang yang dihasilkan oleh suatu fungsi yang sama.  Dalam hal ini, yang pasti adalah bahwa PowerBuilder menggunakan Windows API yang sama baik untuk windows 7 maupun XP.  Namun pada Window 7 ternyata memberikan respon yang berbeda.  Bagi saya, satu contoh kegagalan sudah sangat mencukupi  untuk mencurigai bahwa masih banyak kegagalan yang mungkin timbul.

Kegagalan-kegagalan yang mungkin muncul adalah kegagalan service di sisi server atau kegagalan operasional di sisi client.  Kegagalan-kegagalan ini akan muncul dari response yang mungkin berbeda pada Windows 7 dibanding pada Windows XP / 9x.

Dari paparan di atas sangat bisa dimengerti bahwa pencarian alternatif powerbuilder application server menjadi sangat mandatory.  Pada tulisan kali ini saya akan mencoba untuk mengambil alternatif dengan menggunakan Sybase EAServer.

Persiapan Migrasi

Dalam migrasi ini saya akan menggunakan PowerBuilder 10.5.2 dan Sybase EAServer 6.0.2 karena license produk yang ada adalah PowerBuilder 10.5 yang telah di patch menjadi 10.5.2.  Sedangkan EAServer 6.0.2 dipilih karena supportnya untuk PowerBuilder 10.5.2. Sebenarnya PowerBuilder 10.5.2 pun belum dioptimized  ke Windows 7, namun sampai saat ini saya belum menemukan perbedaan behaviour untuk PowerBuilder 10.5.2 di Windows 7 maupun di Windows XP.

EAServer dijalankan di atas Linux 2.6.  Hal ini dilakukan untuk mendapatkan value added dari migrasi aplikasi.

Proses Migrasi

Kenali  Object Yang akan Kita Migrasi

PowerBuilder adalah IDE yang telah mendukung OOP, dengan memperhatikan desain utama dari aplikasi yang akan kita migrasi maka kita bisa menentukan strategi migrasi dengan lebih baik.

Menghilangkan semua Visual Object.

Semua visual object yang umum digunakan pada PowerBuilder Application Server harus dihilangkan dan semua method yang mempergunakan visual object harus segera disesuaikan agar tidak lagi menggunakan visual object dimaksu.  Visual object tidak disupport oleh EAServer.

Hindari Penggunaan Global Variable

Global Variable dihilangkan atau dipersempit scope nya hanya menjadi instance variable dengan akses protected.  Karena scooping untuk Global dan Instance variable sangat berbeda, maka perlakukan terhadap instance variable yang mewakili Global variable dan benar-benar variable dengan akses global harus mendapatkan perhatian khusus.

Tipe Data Any tidak disupport oleh EAServer

Ganti semua ANY data type assignment menjadi STRING data type dan sesuaiakan perlakuan dari terhadap ANY menjadi  perlakuan terhadap STRING.

Hindari Pembentukan Method yang terlalu besar

Buang semua method yang tidak terpakai lagi karena EAServer mempunyai  keterbatasan terhadap pengelolaan script.  Apabila masih dianggap script terlalu besar saat di-deploy ke dalam sistem, maka berarti komponen harus dipecah.  Dalam hal ini penurunan method harus mendapatkan perhatian khusus agar satu siklus proses hanya terjadi pada satu komponen.

Sebenarnya method yang terlalu besar juga tidak efektif dan dalam tuning aplikasi juga tidak disarankan karena ini akan menimbulkan terbentuknya suatu blok dalam suatu routine yang sangat jarang dipanggil tetapi harus dibuka.

Perhatikan Masalah Encoding.

PowerBuilder untuk versi 8.0 dan sebelumnya menggunakan DBCS (Double Byte Character Sets) dalam menyimpan source code ke dalam file.  Namun mulai versi  9 penyimpanan source code dilakukan dengan menggunakan unicode, dan dalam hal ini adalah UTF16LE.

Hasil Percobaan Migrasi.

Dari hasil pengamatan awal terhadap komponen yang ada pada aplication server dapat disimpulkan bahwa beberapa komponen aktif hanya digunakan 1 komponen yang merupakan turunan terakhir, sehingga bisa disimpulkan bahwa pola penurunannya hanya 1 ke 1. Dan sebenarnya secara riil ini masih belum menggambarkan OOP karena tidak ada generalisasi maupun sebaliknya.  Dari turunan pertama sampai turunan terakhir tidak ada yang dikembangkan hanya menambahkan method.

Setelah dilakukan perubahan untuk meniadakan visual object, meniadakan global variable, type data ANY; saya coba untuk deploy.  Namun sayang masih memberikan pesan kegagalan deployment oleh karena kode terlalu besar.  Akhirnya, dengan memperhatikan pola penurunan yang ada dan karena saya tidak berani untuk mengurangi method yang ada, saya putuskan untuk memecah menjadi 3 buah komponen yang saling bebas dengan mengelompokkan dengan hanya berpatokan pada kemiripan nama methodnya. Kemudian saya coba deploy. Alhamdulillah semua lancar.

Sebagaimana pada PowerBuilder Application Server, eksekusi remote object oleh client ditrigger melalui proxy object yang merupakan skeleton dari server object.  Oleh karena itu, sebagai langkah selanjutnya saya harus menggenerate proxy object di sisi client dengan terlebih dahulu membuang seluruh proxy object yang telah ada.

Telah disebutkan tadi bahwa dalam project ini, saya memecah komponen menjadi 3 komponen saling bebas.  Oleh karena di sini ada 3 komponen yang saling bebas, untuk tetap menjaga behaviour client dari yang sebelumnya terkoneksi secara state-full dengan PowerBuilder Application Server, maka koneksi dengan EAServer juga tetap saya gunakan secara state-full.  Implikasi dari penggunaan state-full ini adalah jumlah koneksi database akan mengikuti jumlah instant yang diaktifkan, dan dalam hal ini ada 3 instan sesuai dengan jumlah komponen yang dideploy.  Oleh karena sebelumnya hanya ada satu komponen, sementara setelah migrasi ada tiga komponen, maka kode pada sisi client harus disesuiakan untuk menggunakan ketiga komponen tersebut dengan mengganti instan dari remote object itu disesuiakan dengan method yang ditrigger.

Setelah semua penyesuaian di sisi client dilakukan, saya mulai mencoba untuk melakukan koneksi client ke server. Koneksi berhasil, namun sayang menu gagal dibentuk karena adanya kegagalan eksekusi komponen di sisi server. Hal ini dilakukan adalah untuk memberikan fleksibilitas object (c.q. Datawindow) assignment sehingga ketika ada perubahan terhadap object dimaksud, tidak perlu melakukan kompilasi untuk dideploy ke server.  Kesalahan yang disampaikan adalah ‘bad UTF-8 data’ pada salah satu object yang melakukan proses ekstraksi source code memasuki environment server sebelum kemudian diassign ke object lain.  Permasalahan ini tidak muncul untuk server yang dideploy ke environment windows.

Lama permasalahan ini mendapatkan penyelesaiannya.  Bahkan ketika mencari ke forum pun hasilnya nihil. Akhirnya dengan melakukan coba-coba sendiri dengan tetap menjaga fleksibilitas sebagaimana dimakasud pada awal paragraf akhirnya tekniknya dirubah dari sebelumnya:

String ls_syntax,errorteks_e

Datastore ds

Integer error_e

Ds = create datastore

Ls_syntax = LibraryExport(“path_to\libfile.pbl”,dwObjectNameArg,ExportDataWindow!)

Error_e = ds.create(ls_syntax,errorteks_e)

If error_e  > 0 then

Ds.settransobject(sqlca)

End if

Dst...

Menjadi:

String ls_Liblist

Datastore ds

Ds = create datastore

lsLibList = GetLibraryList()

AddToLibraryList(“path_to\libfile.pbd”) àperhatikan PBD file bukan PBL file

Ds.dataobject = lower(dwObjectNameArg)

Dst,,,

--pada baris akhir kembalikan library list ke nilai semula

SetLibraryList(lsLibList)

Setlah semua yang perubahan semagaimana dimaksud di atas dilakukan, komponen dideploy ulang ke server.  Oleh karena secara skeleton tidak ada perubahan, proxy object tidak perlu digenerate ulang.

Client langsung dijalankan, dan koneksi berhasil. Menu bisa ditampilkan dengan baik yang berarti perubahan yang dilakukan telah memberikan hasil sesuai yang diharapkan. Namun, sampai  di sini belum semua tujuan terwujudkan.  Pada saat ini hanya ada satu client yang bisa konek.  Bahkan client dengan username lain sekalipun masih gagal melakukan koneksi.  Bahkan dalam beberapa kondisi  menyebabkan crash.  Namun setelah semua komponen propertiesnya diset untuk thread-safe dan support-transaction koneksi bisa dilakukan untuk lebih dari 1 client.

Kesimpulan

1. Migrasi aplikasi yang telah dibangun dengan menggunakan PowerBuilder Application Sever adalah pilihan yang logis.
2. Migrasi PowerBuilder Application Server ke EAServer memerlukan beberapa penyesuaian.
3. Untuk migrasi ke server dengan environment Linux atau Unix harus dihindari pengolahan source code langsung di environment server oleh karena keterbatasan pengenalan encoding.
4. Untuk environment windows permasalah encoding relatif tidak ada.
5. Untuk aplikasi dengan session bean state-full maka harus ditentukan bahwa komponen yang melayani aplikasi harus thread-safe.

Catatan:

Pada bebarapa test demgan menggunakan sambungan 3G yang dibatasi sampai 19 kbps, aplikasi masih bisa menjalankan fungsinya.

Applikasi masih memerlukan perbaikan karena saat ini satu aplikasi berjalan membutuhkan 3 koneksi database.

Membatasi Akses System dari Server Lain atau Jaringan

Dalam suatu jaringan yang telah terinstall firewall, mungkin pembatasan akses telah diterapkan melalui implementasi suatu rule firewall. Namun, seringkali suatu server memerlukan pembatasan terhadap akses dari server lain maupun jaringan yang lebih ketat.
Xinetd super server yang biasanya telah ada pada installasi linux telah dilengkapi dengan TCP Wrapper.  Nah..., fasilitas TCP wrapper inilah yang bisa kita berdayakan untuk melindungi server dari akses-akses yang gak kita kehendaki, karena dengan tcp wrapper kita bisa hanya membuka akses dari beberapa server tertentu dan hanya pada port / service tertentu saja.  Kuncinya ada pada dua file /etc/hosts.deny dan /etc/hosts.allow.
Umumnya dalam mendefinisikan suatu pembatasan akses terkait pengamanan orang akan berpatokan pada 'semua tidak boleh kecuali yang kemudian ditentukan menjadi boleh'.
Dan, berangkat dari patokan ini pula, untuk /etc/hosts.deny boleh kita isi dengan:

                   ALL: ALL

yang berarti semuanya tidak boleh.
Sedangkan untuk membuka akses koneksi SSH dari server dengan nama SERVERKU1 dan DBServer, maka kita harus edit /etc/hosts.allow dan menambahkan baris-baris berikut.

         sshd: SERVERKU1 DBServer

Bila ingin memberikan akses kepada suatu jaringan dengan domain *.domain.ku juga maka /etc/hosts.allow akan berisi sebagai berikut.

         sshd: SERVERKU1 DBServer .domain.ku

Tetapi bila dari jaringan *.domain.ku ada pengecualian untuk host nganu, maka /etc/hosts.allow akan berisi sebagai berikut

         sshd: SERVERKU1 DBServer .domain.ku EXCEPT nganu.domain.ku

Sedangkan kalau pengin membuka semua akses dari komputer dengan nama DewaComp maka /etc/hosts.allow akan berisi

        ALL: DewaComp

Dan sebagai penutup, he he he...., semua bisa dilihat di hosts_options manual dengan menjalankan

myuser@mtmachine:~$man hosts_options

Silahkeun.....

Mars, Tetangga yang Cantik

Image Credit: NASA/JPL-Caltech/Cornell/ASU

Kalau saya katakan bahwa gambar di sebelah adalah gambar yang diambil dari planet Mars apakah sampeyan semua bakal percaya? Hmmm.... mungkin sebagian akan percaya sebagian yang lain tidak percaya, dan kalau ada sisanya paling juga akan ketawa. Ya, pemandangan gurun yang tenang di sebelah ini memang gambar planet Mars. Gambar ini diambil saat Mars Exploration Rover milik Nasa memasuki wilayah baru. Crater Endeavour. Saya tidak akan  membahas mengenai warna temaram yang melingkupi planet ini seperti pada gambar sebelah, karena sudah terlalu banyak yang melakukan itu. Saya gak mau ikut-ikutan tebak-tebak buah manggis; apa langit Mars itu biru atau temaram. Paling cuma jadi bahan ketawaan orang Nasa. Karena pasti mereka lebih tahu dari kita untuk saat ini.
Pada tulisan ini saya cuma pengin menuliskan sedikit hayalan tentang Mars sebuah planet yang bertetangga dengan kita dengan sehari semalam nya hampir sama dengan kita namun memiliki masa satu tahun 2 kali kita. Wajar.

Mars, planet yang pada penemuan awal ketika manusia cuma bisa mengintip dari celah teropongnya, dianggap merupakan planet yang sangat maju dengan kanal-kanal yang dibangun oleh manusia-manusia Mars. Sosok manusia yang digambarkan berwarna hijau mungil. Sampai kemudian manusia bumi membuktikan bahwa hal itu tidak bisa dibuktikan. Manusia bumi kemudian mendapati kenyataan bahwa Mars ternyata hanya sebuah planet gersang dengan atmosfer tipis (yang saking tipisnya bahkan bila kita bisa hidup disana, untuk berbicara dengan kawan pada jarak 1 meter pun belum tentu bisa dilakukan dengan berteriak). Kesimpulan manusia berubah-ubah mengenai planet ini sesuai dengan fakta yang ditemukan.  Dari kesimpulan tipisnya oksigen sampai kemungkinan adanya oksigen yang lebih kaya dari yang pernah diduga. Dan bahkan terakhir ditengarai di Mars masih ada air yang mengalir sampai dengan hari ini.  Terlepas dari apakah itu air asin (bergaram) atau bukan, yang pasti manusia pernah berkesimpulan bahwa permukaan Mars saat ini dibentuk oleh air yang mengalir pada masa lalu atau bahkan air mancur karbondioksid yang oleh sebagian orang diyakini sebagai vegetasi Mars seperti gambar berikut.

Gambar seperti terlihat di samping memang sangat menggugah orang untuk berspekulasi bahwa di Mars memang terdapat tetumbuhan dan kemudian akan menuduh NASA berbohong.  Sedangkan saya sendiri dengan mengandalkan sedikit logika lebih percaya bahwa penampakan yang mirip tanaman itu sebenarnya adalah semburan carbon sebagaimana pada gambar di bawah.

Hmmm.... tetangga kita yang satu ini memang penuh mistery. Dan saya yakin, Allah telah membuatnya begitu, agar kita sebagai manusia mau belajar. Tapi, memang sebaiknya mempelajari Mars itu jangan sampai melupakan Bumi. Rumah kita.

Pembelian Motorola oleh Google seperti Pisau Bermata Banyak

Sebagai sistem operasi baru, Android bagi saya merupakan suatu fenomena IT yang tidak bisa diabaikan. Sama seperti mbah-nya, Google, Android datang bukan dengan pelan-pelan. Dia datang dengan kekuatan penuh merangsek bagaikan air bah mengisi setiap ruang yang mungkin untuk dia isi. Apalagi didukung dengan berkembangkan gaya hidup IT saat ini, kedigjayaan Google dan Android-nya semakin memperlihatkan ujudnya.  Dan, bagi kita di Indonesia, setelah mengalami gegap gempita Blackberry, saat ini pada Android pun tak mau kalah dengan pestanya. Meskipun berbeda dengan Blackberry yang datang bukan sekedar sebagai operating system, namun juga mesin (gadget) nya; pesta Android tak kalah meriah karena justeru melibatkan banyak vendor. Sebut saja HTC, Samsung, LG, Sony Ericsson dan lain-lainnya. Bahkan vendor-vendor 'lokal' pun banyak yang ikut terlibat dalam pesta ini.
Gegap gempita Android ini sempat pula membuat pihak Google merasa risau, dan sempat muncul rumor bahwa Google akan membatasi lisensi Android nya untuk tidak menjadi open source lagi. Namun hal ini ditampik oleh pihak Google dan menyatakan bahwa mereka hanya memperketat pengawasan terhadap Android saja.  Dan sepertinya niatan untuk memperketat pengawasan terhadap android benar-benar diwujudkan dengan pembelian Motorola oleh Google. Dalam satu sisi benar, Google akan bisa mengontrol lebih ketat penggunaan Android karena dengan Motorola (orang banyak kemudian menyebut Gogorola) yang telah menjadi milik Google, Android akan tampil lebih baik lagi sesuai dengan persyaratan yang ditentukan oleh Google. Dan disisi lain, tentunya Google harus juga mempertajam pemasaran Gogorola, karena ternyata pemenang Android saat ini justeru adalah Samsung, dan bukan Motorola. Dan yang paling mengancam Google dengan Android dan Motorolla nya adalah munculnya pernyataan bahwa alasan untuk tidak memilih Android adalah sangat benar dari Nokia.
Sangat wajar Nokia menyatakan hal ini, karena apabila Nokia memilih Android, sementara Google sebagai pemilik Android telah memiliki Motorola, maka mau tidak mau Android yang dibenamkan ke dalam gadget Nokia harus melawan Android Motorola yang sangat mungkin bisa berbeda. Jadi, marilah kita lihat, apakah kemudian Samsung justeru akan menumbangkan Motorola atau kembali ke Bada? Apakah gadget 'lokal' akan kembali ke MTK (Mediatek)? Kita lihat saja nanti......