Entries Categorized as 'Design Pattern'

Framework dan Tumpukan Masalah yang Menyertainya

Date February 15, 2010

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)

Date May 24, 2007

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 :D :P :”>

Visi Masa Depan

Date March 25, 2007

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

Date July 5, 2006

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

Date May 2, 2006

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?