Framework dan Tumpukan Masalah yang Menyertainya

Saya sudah agak lama tidak terlibat dalam sebuah project yang sangat intens dengan coding dan saya merasa rindu karenanya. Saya sudah cukup banyak tahu dan mencoba bermacam framework seperti Spring, Hibernate, Webwork, Struts, Seam, IceFaces (Java sudah jenuh dengan framework ya?). Saya bukan programmer yang tahu terlalu dalam dengan tumpukan framework tersebut dan tidak terlalu tahu bagaimana memanfaatkan mereka dengan benar. Izinkan saya meletakkan ego saya dengan berkata bahwa saya tidak terlalu paham dengan konsep MVC (Model View Controller).

Saya pernah gagal dalam merancang sebuah software dengan tumpukan framework MVC, dimana di sisi model menggunakan Hibernate sebagai ORM (Object Relational Model), di sisi view menggunakan Struts/Webwork, sedangkan Spring menangani sisi controller-nya. Singkatnya, dengan begitu tumpukan framework yang besar, permasalahan datang karena batasan-batasan framework, bukan karena proses bisnisnya. Akhirnya, banyak energi yang harus dihabiskan untuk memenuhi syarat-syarat cukup yang diwajibkan framework.

Seharusnya dengan perancangan, desain, dan perencanaan yang baik hal itu tidak terjadi. Janji-janji framework dimana proses skalabilitas dan perawatan akan lebih mudah menjadi janji palsu belaka. Nyatanya proses tambal sulam menjadi sedemikian besar. Apakah dengan framework tersebut proses pengerjaan akan menjadi lebih cepat? Mungkin jika project-nya begitu besar iya, tapi dengan skala kecil, akan ada waktu yang dihabiskan untuk membuat sistem dasar dimana semua framework berjalan dan saling bekerja sama dengan baik sebelum menyentuh ke proses bisnis intinya.

Akhirnya saya begitu merindukan PHP. PHP from scratch. PHP tanpa framework. PHP yang dengan begitu buruknya menangani variabel dan nilai null karena pemesanan blok memory tanpa deklarasi. Dan itulah yang saya lakukan. Semua saya gabung jadi satu. Query ke database, validasi, HTML, Javascript, semua dalam satu file PHP yang besar. Saya hanya memakai library kecil-kecil saja tanpa framework besar yang bertumpuk-tumpuk. Cukup merepotkan, tapi saya fokus dan hanya dihadapkan pada permasalahan inti, bukan masalah-masalah yang ditimbulkan karena penggunaan framework yang tidak benar.

Pelajaran moral yang saya dapatkan: tidak semua permasalahan harus menggunakan solusi framework yang besar. Kadang-kadang, sebuah permasalahan lebih efektif jika dikerjakan dengan cara “gila” tanpa aturan seperti ini. Permasalahan selesai, dan ada banyak orang yang lebih mengerti dengan cara dasar (karena mudah) dan sulit mengerti cara framework karena learning curve-nya jauh-jauh lebih panjang. Lebih mudah mendelegasikan pekerjaan.

Anda boleh menyebut saya programmer yang buruk karena tidak patuh terhadap kaidah suci MVC. Toh, saya mungkin tidak akan kembali lagi ke dunia ini, ha ha ha ha…

PS: Saya jadi ingat tulisan-tulisan beberapa tahun yang lalu waktu masih memuja MVC hehe.

Service Oriented Architecture (SOA)

From IBM’s presentation about SOA from Board Room a few hours ago. I loved to attend this meeting, ’cause from there I’d got a new perspective about how the system is designed based on Service. Thanks for IBM, and Mrs. Hana Parker for her interesting and interactive presentation. Below is my summarization about service oriented architecture as I got the big picture from the presentation. If there was any wrong concept, please correct me and let me know.

SOA’s Point of View

Suppose that we have existing functionality in our organization, but the functionality resides in separate system, such as: (1) the data is in a database, (2) the bussiness logic is in a legacy mainframe application, and (3) the bussiness logic is also in a J2EE application. We would like to extend the current system without affecting running system, and of course there will be no problem if we want to create new functionality. In SOA’s point of view, things that exposed to be “an services” is bussiness functionality, not applications minded. Take a look at the figure below:

If there are Purchasing application which have Request functionality and Financial application which have Check Budget functionality, on contrary with Object Oriented Architecture which will expose Purchasing and Financial as Objects/Application and Request and Check Budget as Methods, SOA will expose Request and Check Budget as service. So, an application may have one or more services.

Architecture

As you’ve seen at figure above, this simple diagram showing an distributed architecture. We have two database, one J2EE application. So, talking about database connectivity, we have 2 connections. If we add one more application which connects this two databases, there’ll be 4 connections. And as the system grows, the diagram will be much more complex and just like Mrs. Hanna said, a spaghetti diagram.

SOA comes with solution. We add an interface, let say, a pipe, or whatever. Every resources such as database back-end, or existing applications connect to this pipe. IBM introduces their terminology: Enterprise Service Bus. Any services is defined here. Applications exposes their functionality as a service and its service will reside here. By then, application which has connectivity with user (user interface) will access this ESB and access what they need. Of course, it can be defined, what services can be accessed by an application. SOA claimed that this approach will be much more simpler than spaghetti architecture when the system grows bigger and more complex. It doesn’t matter which database should be accessed by an application, but the point is, which services should be accessed by an application. Its services is provided by an service provider which has direct connectivity with its needed resources such as database, file server, and so on.

Well, it’s a very big subjects to learn, and unfortunately, I don’t have much time just like when I’m still in college. Technology is always running fast and we should keep our eyes on it.
Hihihi… ) sengojo ditulis neng boso enggres, sopo ngerti si bule iku moco :”>

Visi Masa Depan

Barusan aku menentukan apa yang menjadi visiku untuk sekitar lima tahun ke depan. Aku memang belum menentukan visiku sejak aku menyelesaikan S1-ku. Tapi paling tidak, apa yang menjadi road map-ku mulai terbentuk. Pertimbangan paling utama adalah, bahwa ibuku tercinta tidak menghendaki aku untuk menikah muda (toh sekarang juga ngga ada calon yang doyan ama orang aneh ini , risiko programmer: you have to be freak and geek if you want to be a master in programming world), sehingga aku masih punya waktu yang lama untuk sendiri.

Aku juga sudah menghubungi Ibu, apakah beliau merestui aku dengan rencanaku ini. Ternyata tidak ada masalah. Ah, ibuku memang orang paling baik sedunia!! Dua atau tiga tahun lagi, aku akan bergerak, meskipun masih melihat apa yang terjadi pada diriku pada saat itu. Tapi, persiapan untuk menuju ke sana harus dimulai hari ini. Yang jelas, untuk dua atau tiga tahun ke depan, aku akan habis-habisan di sini dulu, do my job as best as I can do.

Selamat Tinggal, Praktikum

Agak basi sih, tapi ngga pa pa, saya baru bisa menuliskannya sekarang.

Beberapa hari yang lalu, akhirnya praktikum jaringan komputer yang saya bertanggung jawab menjadi salah satu asisten pembimbing praktikum di situ berakhirlah sudah. Alhamdulillah, lima modul lewat sudah. Soal praktikan, Banyak yang pandai dan rajin, tapi tak kurang juga yang sangat malas. Bukan bodoh, tapi malas. Dan karena ini adalah (semoga) praktikum terakhir yang saya asisteni sejak praktikum Struktur Data, Sistem Operasi, dan Jaringan Komputer, saya ingin meninggalkan sesuatu di sini.

Sejak awal saya menjadi asisten, saya paling getol dengan permasalahan “mbacem” atau kebiasaan praktikan yang melakukan copy-and-paste tugas tanpa mengerti tugas yang diberikan kepadanya. Saya paling murka jika membaca laporan praktikum praktikan yang melakukan perbuatan terkutuk itu. Kenapa saya begitu intens pada masalah ini? Karena kebudayaan ini saya anggap awal dari bencana. Kita tidak akan pernah mengerti materi tanpa kita melalui tahap bersakit-sakit dan mengetahui kesulitan-kesulitannya. Dengan memiliki pengalaman menyelesaikan suatu masalah, konsep yang telah kita taklukkan akan membekas karena diingatkan oleh pengalaman heroik mengalahkan masalah itu. Percayalah pada saya, ketika kita berhasil menyelesaikan suatu masalah dengan tangan sendiri, rasanya ada kepuasan yang tak bisa dilukiskan, bagaimana menjadi seorang pemenang atas masalah tersebut, dan merasakan kesombongan kita naik karenanya — paling tidak itu yang saya rasakan.

Kebiasaan copy-and-paste juga membunuh rasa penghargaan atas hasil karya orang lain. Tidak akan ada penghargaan atas copyright. Bagaimana kita bisa berteriak-teriak soal HAKI jika di dalam kehidupan sehari-hari kita tidak belajar menghargai hasil karya orang lain, meskipun telah diizinkan oleh teman kita untuk di-copy-paste, tapi kenapa tidak dirujuk di daftar pustaka?

Jika ada pertanyaan, lalu darimana kita belajar jika kita tidak boleh “mbacem”? Bukankah kita juga belajar dari sumber lain? Yap! Anda boleh belajar dari mana saja, Mbah Google, PakDhe Yahoo!, internet, buku, perpustakaan, teman sendiri… tapi tentu saja hasilnya akan jauh lebih baik jika kita membacanya dan memahami maksudnya terlebih dahulu. Lalu apa yang telah kita pahami kita tuliskan dengan bahasa kita sendiri. Hasilnya pasti akan jauh lebih luwes dan lebih orisinil. Jika belajar sendiri tetap buntu, tanya asisten Anda. Asisten bukanlah algojo pembantai saat Anda demo program, tetapi rekan yang membimbing Anda melalui praktikum dengan cantik. Jika Anda tak percaya pada kemampuan asisten, tanyalah siapa pun yang Anda percaya bisa menyelesaikan masalah Anda. Jika Anda bertanya dengan baik-baik, saya yakin, Anda akan mendapatkan solusi.

Jadi, ada 1000 banyak cara menyelesaikan masalah. Perbuatan copy-and-paste hanyalah perbuatan orang yang malas saja. Menyelesaikan masalah tidak dibutuhkan kepandaian otak. Sama sekali tidak. Yang diperlukan hanyalah kerja keras dan kerja keras. Kerja keras untuk menyelesaikan masalah, dan kerja keras untuk mencari jalan keluar. Kepandaian otak hanya berperan pada kecepatan waktu menyelesaikan masalah saja. Tidak lebih.

Hanya itu yang saya harapkan di praktikum-praktikum selanjutnya di IF. Yaitu kesadaran bahwa perbuatan copy-and-paste adalah perbuatan menjerumuskan diri. Sudah lebih dari 1,5 tahun saya berjuang sebisa saya dan semoga saya telah menjalankan amanah dengan baik. Semester depan, semoga Anda tidak akan bertemu dengan saya lagi, asisten yang paling gila dan paling perfeksionis ini. ^_^

Alasan Kenapa Aku Jatuh Cinta dengan Java

Menanggapi pertanyaan Adam di buku tamu homepage-ku, izinkanlah aku untuk menuliskan kenapa aku begitu jatuh cinta dengan bahasa pemrograman yang satu ini. Buat mbak rena, sori yah hot-potatonya belom dibales V(^_^)V

Sejak diperkenalkan dengan bahasa pemrograman ketika aku memasuki bangku kuliah di IF, bahasa C telah dipaksa menjadi bahasa ibuku. Hingga kuliah Algoritma dan Struktur Data adalah saksi jatuh bangunku bersama C. Aku adalah orang yang memulai dunia pemrograman mulai dari 0, karena semasa di SMA aku sama sekali tidak mengenal dunia Informatika, kecuali sedikit mengenai sistem operasi DOS dan sedikit ilmu mengenai HTML.

Manajemen Memory adalah mimpi buruk yang selalu kualami ketika bekerja di C. Hal ini berulang-ulang selalu bikin frustasi, debugging yang tidak selesai-selesai. Maklum, aku sebenarnya adalah orang yang sangat tidak teliti, padahal C/C++ memerlukan seorang programmer ala Dennis Ritchie: teliti, kalem, dan bertangan dingin.

Sampai akhirnya aku diperkenalkan dengan Java dengan bapak FX Arunanto di kuliah Bahasa Pemrograman Lanjut. Fitur yang paling menarik bagiku adalah: garbage collector Java yang membebaskan dari segala hal tentang manajemen memory. Ringkasannya adalah ini:

1. Java adalah bahasa yang sederhana, baik strukturnya maupun cara penulisannya.
2. Object Oriented Java sangat kental — membantu cara berpikir dalam menghadapi masalah.
3. Transparan — kita bisa mambuat program Java hanya dengan notepad atau VIM. Bandingkan dengan visual studio .net, mungkinkah kita membangun from scratch dengan notepad?
4. Tutorial dan buku yang banyak serta gratis tersebar di internet
5. Library standarnya sudah sangat banyak
6. Memiliki banyak library yang gratis
7. Dukungan dari banyak vendor besar (Oracle, IBM, BEA..)
8. Dukungan komunitas yang juga besar (Apache, JBoss, Java.net)
9. Terkenal kokoh dan belum terkalahkan di tingkat enterprise
10. IDE (Integrated Development Environment) yang tersedia banyak dan gratis (JDev, Netbeans, Sun Java Creator, Eclipse)
11. Ada kepuasan tersendiri ketika aku mrogram Java
12. dan yang terakhir dan tak kalah penting tentu saja pasar Java yang masih luas

Bagaimana pengalamanku dengan C# (Visual Studio .net)? Sangat tertarik pada pandangan pertama melihat user interface yang luar biasa. Kemiripan C# dengan Java yang membuat cepat beradaptasi juga membuat semangat untuk pindah ke lain hati (baca: C#). Tapi sayang, waktu yang diberikan untuk mempelajari C# tidak sebanyak waktu untuk mempelajari Java, sehingga kurang bisa beradaptasi dengan cara berpikir C# menyelesaikan masalah.

Ketika mencoba mencari bantuan, yang ada adalah MSDN. Aku yakin, seperti halnya Javadoc, MSDN adalah dokumen yang sangat berguna. Tapi bagi pemula, keduanya tidak berguna banyak. Seperti biasanya, tempat mengadu berikutnya adalah Mbah Google. Dan inilah yang membuatku kecewa, banyak tutorial yang harus bebayar. Library-library C# hampir dapat dipastikan tidak gratis, semuanya harus membayar. Jika aku bisa belajar dengan cepat dengan Java, kenapa aku harus menghabiskan waktu dengan C# jika kebanyakan C# harus mbayar?

Ada yang bisa membuatku jatuh cinta lagi dengan Microsoft Visual Studio?

Webservice Bukanlah XML!

Saya tertarik menulis ini setelah melihat beberapa kawan yang sedikit agak latah menerapkan webservice tanpa melihat kebutuhan yang ada. Banyak yang mengira bahwa webservice haruslah XML (lebih spesifik lagi: SOAP). Teknologi webservice proxy dengan standar SOAP dan WSDL memang sedang booming akhir-akhir ini dengan jargon-nya: Service Oriented Application (SOA).

Arti sebenarnya dari webservice sangatlah sederhana, yaitu menyediakan data dalam format yang terstandarisasi dan dimengerti oleh aplikasi lain untuk diolah kembali oleh aplikasi lain dimana antar aplikasi memiliki platform yang berbeda. Aplikasi-aplikasi tersebut tidak mungkin diintegrasikan menjadi satu aplikasi terdistribusi. Atau jika masih mungkin, cost-nya jauh lebih tinggi.

Sebenarnya, SOA dengan XML hanyalah salah satu jenis model webservice. Kenapa memakai XML? Karena XML merupakan standar representasi data yang digunakan secara luas di dunia. Dengan XML, kita tidak perlu repot-repot membuat aplikasi pembaca (parser) XML karena pustakanya telah tersedia sangat banyak di dunia ini. Konsorsium yang menangani masalah webservice (Microsoft, IBM, dan beberapa raksasa lainnya — aku lupa) telah merilis standar webservice ini dengan XML dan protokol SOAP (Service Oeriented Application Protokol).

Tapi ingat, bekerja dengan XML tidak semudah merebut permen dari anak kecil. Anda harus membuat struktur XML yang baik, lengkap dengan Doctype dan DTD-nya dan umpankan ke parser Anda. Jika tidak ingin mengalami mimpi buruk, gunakan arsitektur Object Oriented untuk menangani XML entah parser Anda bertipe SAX ataupun DOM. Pengalaman pribadi saya bekerja dengan XML dengan PHP 4 cukup membuat saya menangis darah *berlebihaan*.

Bolehkah kita membuat standar webservice sendiri? Kenapa tidak?!? Jika tanpa XML masalah akan teratasi kenapa tidak? Contoh sederhana: Misalnya kita memiliki sebuah database user tersentralisasi yang hanya bisa diakses user tertentu dan sangat terbatas. User (say A) yang tidak memiliki akses ke database tersebut dapat meminta apa yang dibutuhkannya kepada user yang memiliki akses ke database tersebut (say B). Misalnya, A mengirim user dan password kepada B. B mengolah data tersebut dengan mencari di database. Kemudian hasilnya disediakan kepada A melalui satu file teks berisi true (jika ok) atau false (jika gagal). A Akan membacanya dan mengolahnya kembali. Selesai! Webservice telah berjalan.

Kebutuhan versus Teknologi

Namun demikian, kita harus selalu melihat kebutuhan kita. Webservice digunakan jika dan hanya jika antar aplikasi tidak mungkin melakukan komunikasi secara langsung. Ambil kasus di atas. Jika A bisa mengakses database, tentunya kita tidak usah memerlukan sebuah webservice di situ. A dapat melakukan query SQL langsung ke database. Kasus di atas terjadi jika misalnya peraturan non-teknis membuat A tidak dapat mengakses database. Ada overhead yang signifikan di saat proses pertukaran informasi antar aplikasi, yaitu: menyediakan data untuk diolah di sisi aplikasi server dan mengolah data tersebut di sisi aplikasi client. Sayangnya, saat ini banyak yang latah dengan mengedepankan teknologi tanpa melihat kebutuhan yang sering menyebabkan sebuah teknologi terlalu tinggi untuk diterapkan di suatu kasus. Kenapa demikian? Jawabannya sederhana: gengsi!