Thursday, April 30, 2009

90% Application adalah CRUD process

Percaya tak bahawa 90% application/system adalah berkaitan simple CRUD (Create,Read,Update and Delete).

Simple Design

Aku masih tak dapat lari dari bila design memasukkan element mistik dalam design aku? Apa design ada element mistik dan seram?..(Terpengaruh dengan cerita seram yang kerap ditayangkan di TV). Tak lah sebenarnya apa yang aku nak cakapkan ialah bila design result akhirnya akan menjadi komplex kerana menjadi kebiasaan aku macam tu.

Ntah kali keberapa aku pasang niat untuk cuba design menggunakan konsep KISS dan YAGNI, walau aku faham kedua-dua konsep nie, tapi bila masa aku design atau menulis code sering aku terlupa akan guideline ini. Design kalau terlalu syok sendiri akan menyusahkan orang lain aku cukup setuju pendapat ini. Salah seorang teammate aku pernah tegur, kenapa aku bila design fikirkan benda yang complex?.. Jawapannya ialah kerana aku adalah student graduated in Electrical Engineering yang dah terbiasa dengan complex formula hehehe boleh ke bagi reason macam tu?? Kaukan dah grade 11 thn lepas maner ingat lagi formula tu semua..tipu je tu..hehehe ....habis tu Mr H tu pun sama grade dalam EE kenapa dia design ok je?Sebab dia grade zaman tu IC memory baru berapa je/conductor/Circuit board layer baru ada selapis je zaman tu, zaman aku dah berlapis-lapis macam kuih lapis so nak kira current masuk dan current keluar sampai air liur yang terkeluar tau, tu belum nak kira voltage, yang tak betul pun ramai sebab salah calculate voltage.. pergh , so tu lah reason kuat yang aku boleh bagi untuk mempertahankan diri :)

Teguran yang membina dan aku akui kebenaran tersebut...sebab itu bagus jika ada orang lain yang review code dan design kita, kita jangan mengharapkan orang akan setuju dengan design kita kerana kita tidak akan banyak belajar jika tiada kritikan kecuali memang Allah dah bagi ilmu laduni (ilmu yang dapat tanpa belajar dari mana-mana sumber, ilmu nie untuk semua bidang atau bidang agama sahaja?) kena tanya member-member yang expert bidang kerohanian.

Jadi majulah simple domain design untuk kesihatan anda, rakan-rakan anda dan alam sekitar..

Wednesday, April 29, 2009

Muhammad 'Umar Hafiy



Yaya hero sudah datang sekali dia tarik dua-dua kakak dia tumbang daaa...... :)Tak boleh tengok kakak dia minum air yougurt sure nak... sampai habis dia minum manalah si kakak tu tak menangis..

Deeni Husna

Posing bila depan kamera


Masa baru-baru pandai nak berjalan



Anak kedua aku Deeni Husna, independent, berani dan suka kacau kakak dan adik dia... dia lak suka nak pergi sekolah..:)


Damia Bisyri


Masa pagi raya



Dalam walker



Bergaya di sofa baru


Anak sulong aku, berumur hampir 4 tahun. Banyak celoteh dan banyak sangat pertanyaan,suruh aku beli kereta baru yang ada gelungsor dan peti ais dan dalam peti ais tu ada air yogurt and vitagen anggur... Selalu tanya hari nie pergi sekolah ke tidak..kalau aku atau wife aku kata tak gi sekolah perasaan dia "Bahagianya Hidup".

Friday, April 24, 2009

Peraturan TDD yang kedua

Peraturan pertama ada di sini
Setiap perbuatan akan dipertanggungjawabkan. Apabila object tersebut melakukan sesuatu tugas mesti ada kesan samaada perbuatan itu merupakan arahan(command) atau juga permintaan(query). Kejayaannya bila anda ada kawalan penuh dan anda memang sudah menjangkakan kesan yang terjadi dari perbuatan tersebut.

Maka peraturannya ialah check semua kesan gegaran berapa skala richter.

Kalau aku tolak kau dari bangunan nie ke bawah: Kesannya dengan izan Allah.

1. Kau mati
2. Aku suka hati (kejam betul..)
3. Harta kau aku yang punya
4. Aku kena dakwa (bersalah atau tidak tengok cable aku macam mana..:)


Ini ialah kesan dan memang tu jangkaan pada keadaan normal atau dipanggil Assert.

Single Responsibility Principle berguna dalam design Interface

Ada satu lagi pattern/principal yang insyAllah dilain masa aku akan cerita iaitu Interface Segregation Principle. Cuma apa yang aku nak cerita ada sedikit kena mengena dengan Interface Segregation Principle tapi dari sudut Single Responsility Principle.

Sebelum nie aku ada menulis Transformasi kepada Single Responsibility Principle dimana pada pendapat aku untuk mencapai konsep pattern tersebut groupkan tugas-tugas yang related/berkaitan kepada satu class. Cara yang sama boleh digunakan juga pada class yang baru kita asingkan.

Konsep mengroupkan tugas yang berkaitan kedalam class yang lain diguna pakai juga kepada Interface.

Istiqamah dalam memboikot

Aku dan family aku dah lama tak makan-makan di McDonalds atau KFC, dah hampir 5 bulan kami sekeluarga pertahankan diri dari membeli makananan di kedua-dua company ini. Aku percaya pada konsep boikot walau satu product impactnya tetap ada kalau semua umat Islam ada matlamat yang sama. Cuma ntah macam mana semalam masa bawa anak-anak aku jalan, kami lalu di depan kedai KFC, agaknya baunya manarik kot, so anak aku kata kat aku.. "Abah nak makan KFC", aku bagi tahu dia untuk cari makan dikedai lain je.. anak aku baru berusia hampir 4 tahun, dia merengek nak makan ayam KFC gak. Aku tak sampai hatilak tengok dia dah menangis.. so wife aku kata jom cari yang drive thru je. Pada aku ada juga kejayaan dalam memboikot selama hampir 5 bulan, aku kena realistik dan cuba didik anak aku sedikit-sedikit, cuma yang pasti McDonalds anak-anak aku memang dah tak nak, sebab aku pernah bagi tahu tu orang jahat punya company:), KFC aku tak cakap cam tu pulak :).. salah ke aku cakap macam tu?

Barang-barang keperluan lain yang boleh diganti dgn product Malaysia atau Muslim, kami cuba sikit-sikit, contohnya ubat gigi aku replace dengan ubat gigi mukmin junior dan yang kayu sugi, Nescafe aku dah stop terus beli, sebab tak berapa minat dan sebelum-sebelum nie kalau beli Nescafe memang boleh tahan lebih dari 3 bulan.

Ada yang boleh direplace dengan product yang lebih kurang sama quality dan ada juga product yang orang Muslim belum keluarkan lagi, dan keperluan tu penting yang tidak dapat tidak kena terus membeli.

Cuma satu kalau boleh teruskanlah memboikot apa-apa yang boleh. Satu product pun cukup memadai sebenarnya atleast ada juga sumbangan kearah kekuatan permintaan umat Islam dalam jual beli.

Thursday, April 23, 2009

Aku mula menyukai AAA

AAA (Arrange-Act-Assert), baru je menceburkan diri dan membiasakan diri dengan cara AAA, tak pasti sejauh mana kebagusan dan resultnya nanti, masih awal untuk mengatakan cara ini yang terbaik, cuma lebih clear sedikit dari cara yang lama.

AAA masih tergolong dalam golongan pemikiran BDD. Sebelum ini aku guna BDD cuma dengan different cara, dimana setiap method (When,Because,Act) akan diberi class sendiri dan apabila penggunaan terhadap sesuatu function berlaku akan adalah beberapa Assert yang terjadi.

Iman & Hidayah

Baca entry dari 1kHz berkaitan Hidayah , terasa mereka yang convert ke Islam kerana Allah nie iman dia orang lagi tinggi dari kita, ujian yang mereka hadapi memang berat yang kalau kita Islam sejak lahir mungkin tak mampu hendak hadapi.

Perbezaan ketara antara orang yang diberi dengan orang yang mencari.

Wednesday, April 22, 2009

Transaformasi kepada Single Responsibility Principal

Post aku sebelum nie ada menyentuh tentang kepentingan pattern SRP dan OCP dalam mencorakkan design domain dan sewaktu coding. Tapi bila aku bercerita tentang kepentingan pattern jika tidak diterjemahkan kedalam code dan real implemantation agak payah hendak mendapat gambaran yang jelas dan kebaikan pattern tersebut. Aku ada berbincang dengan kawan seangkatan berkaitan kedua-dua pattern dan apa yang pasti SRP merupakan pattern yang agak tricky. Jadi aku cuba terangkan dengan layman word dan code.

Aku tiada banyak idea nak bagi contoh dan aku pun tak pasti contoh yang aku bawa ini bagus atau tidak, ini juga menjadi kayu pengukur untuk aku mengetahui kefahaman aku dalam pattern2 ini.

Apa dia SRP?..

Single Responsibility Principle

Mengikut tuan empunya diri yang memperkenalkan pattern ini, SRP ialah
Sesuatu class/object hanya ada satu sebab sahaja untuk diubah..

Aku bawah contoh code dibawah :


    public class Report
{
public void Print()
{
//
}

public IList GetData()
{
return null;
}

public void FormatReport()
{
//
}
}


Kenapa code ini melanggar principle SRP. Kalau dilihat code tersebut ada berapa kerja code Report itu boleh buat? Ada 3, iaitu dia boleh melakukan tugas Print(), tugas untuk Formatting FormatReport() dan tugas untuk mendapatkan data GetData(). Oleh kerana itu code tersebut ada 3 sebab utama jika kita hendak buat perubahan.

Jadi adakah setiap class/object hanya boleh melakukan satu tugas sahaja bagi memenuhi SRP? Jawapannya sudah tentulah tidak. Kena faham maksud responsibility (tanggungjawab). Ok seorang bapa mempunyai banyak tanggungjawab, salah satu ialah menyara anak-anak. Jika beliau mempunyai 3 orang anak adakah perlu diwujudkan 3 class berkaitan saraan? Jawapan ialah tidak. Object saraan hanyalah satu tapi tugasnya boleh ada banyak selagi mana ianya berada dalam lingkungan makna saraan.

Caranya ialah dengan groupkan mana-mana tugas yang related dengan responsibility class tersebut dan refactorkan.

Contoh:

public class Bapa
{
public void Bekerja()
{
}

public void SaraanAnak1()
{
}

public void SaraanAnak2()
{
}

public void SaraanAnak3()
{
}

public void SaraanIbuBapa()
{
}

}


Jadi berdasarkan code diatas ini class bapa coupling direct dengan tugas-tugas tersebut, aku boleh bahagikan kepada 3 responsiblity disini seperti berikut.
1. Bekerja
2. Saraan Anak
3. Saraan IbuBapa (Bapa/Ibu kepada bapa tersebut)

Jadi bila refactor dia akan menjadi:

public class Bapa
{

public void Tugas()
{
new SaraanIbuBapa();
new SaraanAnak();
new Kerja();
}
}

public class Kerja
{
public Kerja()
{
Bekerja();
}

public void Bekerja()
{
}
}

public class SaraanAnak
{
public SaraanAnak()
{
SaraanAnak1();
SaraanAnak2();
SaraanAnak3();
}

public void SaraanAnak1()
{
}

public void SaraanAnak2()
{
}

public void SaraanAnak3()
{
}
}

public class SaraanIbuBapa
{
public SaraanIbuBapa()
{
SaraanIbuBapaSendiri();
SaraanIbuBapaMertua();
}

public void SaraanIbuBapaSendiri()
{
}

public void SaraanIbuBapaMertua()
{
}
}


So dari class Bapa yang sarat dgn tugas kita dah menjadikan class Bapa untuk follow SRP. Ini adalah secara basic, class SaraanAnak sendiri adalah grouping tugas secara highlevel kemungkinan juga akan ada refactor di class tersebut tetap ada. Aku cuba buat sesimple yang boleh

Cuba-cubalah memahami, ada yang nak bagi comment dipersilakan.

Tuesday, April 21, 2009

2 pattern yang penting bila start design and coding

Ada dua pattern yang insyAllah boleh membantu mempertingkatkan kualiti code pada tahap dimana code tersebut mudah untuk di refactor kemudian hari.

1. Single Responsibility Principal
2. Open Closed Principal

Jika pemahaman yang mendalam untuk 2 pattern ini diberi perhatian insyAllah sudah cukup untuk refactor dan apabila perlu boleh ditambah dengan pattern-patern yang lain.

Monday, April 20, 2009

Design API, kebebasan atau guideline

Soalan ini timbul selepas aku dalam process buat Repository API. Menjadi kebiasaan sekarang ini dalam repository aku ada support nhibernate linq, jadi ada method yang return IQueryable.

Bila aku expose method ini yang return IQueryable, bermakna developer yang mengguna API ini mempunyai full control bagaimana ingin query ke database. Dari satu segi dia beri kebebasan pada developer untuk query dan tanpa menunggu developer yang terlibat dengan repository API untuk bagi specific query. Manakala dari sudut yang lain kebebasan tanpa control juga menyebabkan haru biru pada system.

Ada apa-apa pendapat?.

Friday, April 17, 2009

Peraturan sekolah TDD yang pertama - check not null

Ini ialah sekolah TDD, peraturan pertama apabila buat test sematkan dalam otak, bahawa apabila menulis test yang pertama perkara penting ialah test not null value pada mana-mana object yang memangg tidak sepatutnya ada null value apabila berfungsi. Antara main bugs dalam software yang pertama sekali bila dapat message yang ini.

"Object reference not set to an instance of reference".

Jadi rajin-rajin lah test ShouldNotNull()

Thursday, April 16, 2009

Aku ada banyak masa?

Aku pun tak pasti cuma akhir-akhir nie aku macam bersemangat sahaja nak menulis, ialah dulu aku tak de kesempatan nak luahkan, nak share apa yang aku tahu dan tak ade juga kesempatan nak mengutarakan kemusykilan.

Sibuk tetap sibuk, cuma aku rasa kalau aku tak menulis aku sibuk juga, cuma aku cuba ambil masa dalam 15 min untuk menulis apa-apa yang aku rasa baik dan bagus untuk aku (mungkin tidak untuk orang lain) Wallahu'alam..

Tanda-tanda rosak akhlak

Tanda-tanda rosak akhlak, maaf bukan nak cerita pasal rosak akhlak, kalau nak tahu pasal akhlak seorang geek refer kat sini "Akhlak seorang Geek" .

Aku nak cerita tanda-tanda rosak design

1. salah satunya ialah susah nak refactor.
2. keakraban dengan database design.

Wednesday, April 15, 2009

Pedih tapi ok sahaja

Aku walaupun dikritik sebagai bos yang tak boleh nak bawa perubahan kepada team dan cara pembawakan software development yang jumud dimana tidak ada perkembangan yang positif. Kesanya banyak yang merasa demotivated dan berhenti, insyAllah aku boleh terima kerana aku juga dalam prosess belajar walaupun aku dah involve dalam dunia IT hampir 12 tahun, tapi aku akui part management aku agak kurang memberangsangkan.Aku boleh terima sebab aku juga kritik orang dan tidak setuju dengan cara seseorang yang aku fikirkan tidak bijaksana. Aku ambil segala kritikan terbuka dan kritikan body language sebagai panduan untuk bina team yang lebih bagus insyAllah. Penolakan orang untuk berubah hanyalah persepsi kita kerana cara approach kita yang orang lain tidak boleh hendak terima. Kita tidak boleh ambil bulat-bulat apa yang dibaca dan cuba apply sebiji, kena perhati tahap mana knowledge seseorang.

Aku pernah tulis dahulu lama sebelum aku jadi lead dalam company ini, keberkesanan dan berjaya sesuatu team bukan kerana expertnya seseorang dalam team tersebut tapi bagaimana dia boleh bekerja dengan orang yang tidak sama level dengan dia.

Tuesday, April 14, 2009

Mana satu idaman kalbu

Ini ialah basic design tapi kadang-kadang susah juga nak dapat yang betul. Aku bawa contoh seorang bapa mempunyai ramai anak. Bila bapa itu sudah sampai masa mengadap Allah , anak-anak didunia ini hanya boleh membantu dengan berdoa, anak masih hidup bapa dah pergi ke alam fana. Ok yang itu ialah cerita je..yang sebenar-benarnya aku nak design konsep parent child dalam domain model. Macam mana nak design macam inikah?

A


atau

B



macam inikah?

C



D
atau ketiga-tiga betul???

Sunday, April 12, 2009

Kerja kosong

Aku cuma nak sampaikan ada kekosongan kerja sebagai "Analyst Programmer" untuk .Net dan PHP dekat company tempat aku pagi-pagi pergi kerja selepas hantar anak aku pergi tadika :) nak jadi guru tadika pun ada kalau tak silap aku, ada memo tampal depan pintu gate tadika sekolah anak aku tu, sila nyatakan hendak berkerja dengan sekolah tadika tersebut atau sebaliknya.

Ok company yang sekarang nie bayar gaji bulanan pada aku selalunya 26 haribulan dan ada dalam bank, cuma company nie tak berapa glamour tapi Alhamdulillah aircond sejuk, kedai makan pun senang. Kerja dia sama je macam kerja kat tempat lain juga tak de apa-apa special, kena tulis code, kena masuk discussion, kelayakan kalau dah pernah bekerja kat mana-mana company IT dalam dunia nie dan terlibat dalam salah satu language seperti C# atau PHP atau Java maka secara automatik level satu nyer filtering lepas. Kelayakan yang lain ialah anda lepas kelayakan yang pertama. Untuk hantar resume anda sila hantar ke email budak nie irwan.azam@mediu.edu.my.

Soalan interview dia senang je, antaranya: Kenapa agaknya anda berminat hendak join company nie??.. Contoh jawapan yang mungkin diberi
- kawan saya kerja kat sini, nampak macam best,
- saja hantar resume, ada orang call ntah saper tah, lagi pun hari yang disetkan interview nie saya free so saya datang jelah
- mencari pengalaman dari tempat kerja lama (orang yang bagi jawapan nie selalunya menerima nasib ngeri, otak akan menjadi separa sedar dan akan mengalami penyesalan)
- nak bekerja berdedikasi, nak berjaya macam encik, jadi bos nampak macam senang je..ada orang cakap encik rileks je kat ofiss ek :) ..kalau jawapan dia nak berjaya macam encik, aku rase belum habis interview confirm dah dapat tapi sambungan ayat selepas tu sure kena baling keluar.
- nak gantikan tempat encik, encik nampak macam terror, teknology yang encik cerita tu pun saya tak pernah dengar, ada unsur mistik, penipuan dan kelakar saya memang cari kalau dapat bos yang macam tu ..emmmmmmmmm kalau jawapan nie susah sikit tu kecualilah yang tukang interview tu memang dah ada kerje lain sebagai cleaner ke..
- saya dipaksa untuk datang interview .........dusshhhhhhhhhhhh!!!!!

Friday, April 10, 2009

Make Role Explicit

Aku baru je habis habis tengok presentation Udi Dahan berkaitan Make Role Explicit . Macam menarik untuk dicuba dalam design. Setiap object perlulah clear apa yang boleh dibuat dan apa yang patut dibuat.

Open Source Business Process Management

Yang aku jumpa ada 3 salah satunya dihantar oleh CTO aku

Intalio
ProcessMaker
CuteFlow

Aku tak biasa dengan BPM, budak baru belajar

Wednesday, April 08, 2009

Kepentingan Sequence Diagram yang diabaikan

Aku memang sering mengabaikan sequence diagram pada kebanyakkan project sebelum ini, bila dah terduduk dengan domain yang agak complex baru nak buat sequence diagram.

Kenapa sequence diagram terabai ialah kerana aku tak berapa mahir nak design. Sedangkan kepentingan sequence diagram dalam masa pertapaan aku dengan master H di tekankan, tapi bila aku keluar dari pertapaan aku sembah derhaka (Ala macam DS Nizar buat lahhh ).

Aku buka balik buku lama aku tentang sequence diagram didalam Applying UML and Patterns. Kegunaan sequence diagram ialah untuk verify domain design yang dibuat itu montap atau tidak itu antara perbualan aku dan Mr 1kHz ketika kami sedang menjamu selera :) Selera makin bertambah bila dicampurkan dengan term-term ini kedalam lauk makanan tengah hari anda.Kalau tak percaya cubalah :)

Kami juga bersedia untuk dipanggil makan tengahari pada sesiapa yang hendak nak merasa term-term ini dalam makanan...

Tuesday, April 07, 2009

Apalah nasib BIJAN

Aku dan wife aku sambil tengok Astro Awani, sempat lagi menjengah ke beberapa blog bloggernetworks yang pro PR dan sesekali tersesat kedalam blogger BPN yang pro KERAjaan. Ada dua team masing-masing hebat update bahan dan mainkan psikologi menarik, menarik..cuma sesetengah team BPN bahasa agak lucah dan melampau. Dia orang nie tak sekolah agaknya kot. Memperbodohkan intelek seseorang dengan hujah yang jelik. Dalam era internet masing-masing ada hak nak berkata dan kena juga study effectnya jika gaya bahasa yang tidak beradap, kalau yang baca tu memang penyokong tegar, rasanya tak adelah ambil port sangat, cuma yang baca nie mereka-meraka yang berada atas pagar yang masih belum buat keputusan nak memilih siapa, but bila dah terbaca dalam blog tu dimana sumpah seranah penuh dalam artikel jadi pembaca boleh buat kesimpulan pemilik blog tersebut memang tiada sahsiah diri dan secara direct merke akan melihat parti mana yang disokong juga terkena tempiasnya.

Pukul 8:00 malam aku dah dapat msg mengatakan PR menang 2 - 1, cuma bukan keputusan rasmi. Aku sesekali minat juga nak cerita pasal politik, cuma yang aku perasan bila Mahathir turut sama berkempen aku nampak ada tanda negatif dari kem pak lah. Kau bayangkanlah teruk paklah kena hina ngan Mahathir, penyokong-penyokong pak lah tak kan nak diam aja, mungkin dia orang akan buat silent protest..

Ntahlah cuma bagi aku tunggu dan lihat je lah corak pemerintahan BIJAN nie sama ada dia kena queen control dengan wife dia atau ada lagi satu king control MAHATHIR akan remote control BIJAN.

Bagi negeri aku MELAKA masih kurang sinar untuk PR bertapak WallahuA'lam, pekat sungguh darah dacing dia orang sampai ada yang cakap kalau letak tunggul mati pun kat kertas undi dacing sure dia orang akan pilih tunggul dari pilih manusia hehehe alahaiii orang Melaka.

Pengalaman buat presentation untuk Gov agensi

2 minggu lepas aku dikehendaki buat satu presentation tentang architecture dan cara software development yang aku dan remote team aku akan buat. Mereka yang hadir kebanyakkan ialah level penolong pengarah dan mempunyai pengalaman teknikal dalam beberapa project Goverment sebelum ini. Terdapat juga Pegawai Teknologi Maklumat lebih kurang 4 orang dalam bilik tu.

Aku tiada pengalaman deal dengan agensi kerajaan sebelum ini dan aku tak tahu sangat protokol dan cara bekerja dia orang. 2 hari sebelum presentation tu adalah beberapa slide diagram yang aku sediakan dalam membantu aku unutk memberi penerangan dan untuk aku buat demo. Aku agak gemuruh juga ialah aku nie orang biasa-biasa je, nak beri presentation kat beberapa orang yang ada title Dr.

Selepas Project Manager buka majlis dan perkenalkan diri aku sebagai Solution Architect untuk project, aku pun bagi salam dan start lah presentation aku.. 5 minit awal rasa macam tak de darah je..aku pun tak banyak cerita direct to technical part.

Selepas dan masuk dalam 15 minit, aku tengok dia orang macam focus je (ada yg tertidur tu aku tak tahu lee hehehe), aku start confidence semula, macam-macam technical word yang latest dan terkini keluar dari mulut aku, ada yang aku tak plan nak cerita, bila dah syok dan banyak pulak pertanyaan dia orang aku pun rasa perghh...bestnyaa... term-term SOA, interconnected component, n-tier layering project solution, Test Driven Design, User Story, Automated Test, Dependency Injection, Object Relational Mapper semuanya aku cerita yang tak de dalam slide pun aku cerita, nie open source mulut :). Part yang aku rasa best dan mencabar ialah bila aku kena demo :) Ialah aku dah puas cerita ..kita orang tak guna stored procedure lah, view...bla bla bla, nak tukar database dari oracle ke mssql ke mysql ke firebird ke sqlite umpama menekan remote control untuk tukar channel je..

First yang aku demo ialah we can run our application tanpa database..yehaaaaaaaaa!!!, lepas tu aku run kalau ada apa-apa perubahan aku tak sentuh pun database management console, ubah sahaja di domain dan tadaaaaaaaaaaaa!!!!!!! field baru bertambah, relation bertambah semunya dengan tekan enter sahaja. Kalau aku tak suka database tu aku boleh je tukar database lain tanpa tukar code.

Aku demo sikit tentang BDD, aku bawa contoh BDD style Dan North narrator/story approach. Alih-alih aku dah present 2 jam lebih...masa yang diperuntukan ialah 1 jam je..:)

Alhamdulillah, lepas nie aku jadi presenter je...:)

Monday, April 06, 2009

Kenapa Active Record ku pandang sepi

Ntah kenapa bila aku tengok Active Record nyer pattern aku tak begitu tertarik walaupun ianya bagus, mudah,senang dan simple. Element-element sebegitulah yang diperlukan KISS cuma ntah perasaan ini tidak dapat nak ambil Active Record sebagai pemain utama dalam DataAccess layer. Siapa ada hujah menyakinkan aku untuk aku memberi tempat Active Record dalam DataAccess Layer?...

Command Query Separation, Distributed Domain Drven Design

CQS, DDDD .................. best seronok bila baca tentang SOA (Service Oriented Architecture), kena faham betul-betul konsep event dan messaging.

Kenapa ERD tidak boleh express real world problem

Sebelum ini, lama dahulu semasa zaman muda-muda, sebagai programmer yang bersemangat waja apabila mendapat sahaja tugas untuk develop software/aplikasi tidak kisahlah yang besar atau yang kecil atau mewarisi aplikasi itu untuk dijaga dari senior programmer, maka perkara pertama bermain di benakku ialah bagaimana rupanya database design, berapa banyak table dan lain-lain yang sewaktu dengannya.

Aku cukup suka bila semua relation dalam database lengkap dengan primary key, foreign key, constrains dan aku rasa bila database dah complete baru aku ready untuk buat coding. Dulu memang aku tak dapat nak bayangkan macam nak memulakan coding applikasi yang berkaitan dengan penyimpanan maklumat tanpa perlu memikirkan database design. Bila bercerita dengan customer aku akan bayangkan database design bila bercerita dengan team se unit pun bercakap pasal database design.

Berbalik semula 7 tahun lepas aku kenal mamat H nie, olahan cerita beliau tentang software development approah mengusik akal fikiran ku. Aku terasa ajaran beliau berlainan tidak seperti yang biasa aku dan kawan-kawan aku buat dan fikirkan. Tentang konsep design pattern, pertama kali dengar :) ialah aku budak electrical yang banyak aku dengar semua berkaitan dengan electrical term. Jadi aku terus tumpukan perhatian pada setiap posting beliau dan aku juga kerap kali bertanya soalan. Oleh kerana begitu berminat dangan cara beliau aku pernah ambil beliau naik motor kapchai aku bawak datang ofis minta dan tunjukkan pada beliau apa yang aku buat, dia tegur aku jagan fikirkan pasal database design aku masih lagi tidak boleh lari dari terus terbayang akan si database design nie, penagangan database design aku rasa cukup kuat, dan aku pasti ramai yang ada perasaan tersebut walaupun dah capai umur baligh dalam programming :)

Aku cuba lagi, dan aku diperkenalkan pula dengan Peter Coad teknik - Colour Modeling, selepas mengodek-godek cara tersebut barulah ada sinar FM sikit pada cara aku berfikir. Aku sudah boleh melupakan sedikit si database design. Aku join group color modelling dan banyak soalan bodoh aku tanya dalam group tu.. arghh buat apa aku nak malu, dia orang bukannya nampak muka aku masa aku tanya, dah lah english aku cukup makan nak tanya pasal design level enterprise lak tu.. hahahaha. Yang bagusnya ramai jugak lah response pada pertanyaan aku, aku oleh kerana excited sangat selepas siap je buat design class terus pergi Cyber Cafe dah malam dah masa tu tapi dia orang kan siang so dapatlah jawapan segera bila dia orang review example tersebut.. pergh seronok betul, betul, betul

Selepas tu nie aku tak ingat macam mana aku boleh beli buku Domain Driven Design, sama ada mamat M bagi tahu aku atau pun aku terbaca dalam forum tersebut. Buku nie aku baca lebih dari sekali dan ambil masa untuk aku faham.

Ok aku dan lari jauh dari tajuk yang aku nak cerita. Aku nak bagitahu pada mereka yang masih lagi berfikir tentang database design, cubalah ambil masa fikirkan cara alternatif sikit.

Aku nak bawa contoh yang biasa-biasa aje, Customer membuat Order untuk membeli beberapa barang keperluan. Ok untuk simple case kita akan ada object Customer, Order dan OrderLine

Kalau kita buat database design dia akan jadi macam nie kan



Relation antara Customer kepada Order adalah sama dengan relation antara Order dan OrderLine. Tapi kalau mengikut design sebenar mengikut comman senario ianya bukan begitu.

Customer dan Order ialah unidirectional association, bermakna Customer tidak perlu tahu tentang Order, sebaliknya Order tahu akan Customer.

Manakala untuk Order dan OrderLine relationnya pula bidirectional, bermakna Order mempunyai maklumat tentang OrderLine dan begitu juga sebaliknya OrderLine mempunyai maklumat tentang Order.

Tapi relationnya tiada beza, bagaimana? satu unidirectional dan satu lagi bidirectional, jadi bagaimana. Perkara tersebut hanya boleh di terangkan dengan design domain model menggunakan UML. Berdasarkan design ini kita boleh terangkan OrderLine lifecycle dia dependecy kepada Order, kalau kita listkan semua maklumat OrderLine pun tiada guna kerana maklumat tersebut hanya berguna bila disekalikan dengan maklumat Order. Untuk Customer bukan tugas Customer untuk tahu semua maklumat Order, apa yang Customer perlu tahu jika diberi maklumat Customer sistem perlu bagi maklumat Order kesemua Order yang di lakukan oleh Customer tersebut.




Selamat mencuba dan Vote No to BIJAN

Saturday, April 04, 2009

Behaviour Driven Design

Aku sudah lama apabila menulis code test guna cara TDD, cuma baru-baru nie adalah dalam setahun yang lepas aku nampak TDD banyak sangat repeated test code, code smell etc. Dan lagi satu bila buat test tu tak berapa sangat nak clear apa yang code itu test dan akhir sekali banyak sekali test code aku yang terbengkalai kerana masa nak deliver semakin dekat jadi terus tumpukan kepada real code. Akhir-akhir ini aku tumpukan masa lebih sedikit tentang BDD dan aku tertarik untuk menjadi sebahagian dari community BDD.

Bila dah involve dengan BDD, sudah tentu code test yang ditulis berlainan dari apa yang tedapat dalam TDD. Kenapa aku beria-ia sangat nak tukar ialah kerana bila aku buat BDD, test code aku boleh menajdi sebahagian dari "Executable Documentation". Aku kesian kat team aku dahulu, oleh kerana ketidakmahiran aku dalam menulis documentation maka berlari-lari keluar mereka mencari rumah baru sedang aku masih dalam lamunan dengan memberi janji-janji manis bahawa aku mempunya standard yang tinggi dalam software development hehehehe.............

Aku insaf seketika, memikirkan bagaimana bisa aku hendak cari penganti mereka-mereka yang hebat-hebat ini? Aku kalau diberi peluang..arghh jangan dikenang perkara yang lalu...

Apa yang aku bernostalgia nie, anak-anak aku semua dah tidur, mata aku tidak mengantuk lagi. Aku sambung semula tentang BDD.

Untuk aku code guna BDD aku boleh memilih 2 jalan alternatif, alternatif pertama dari kumpulan parti Dan North dan alternatif yang lagi satu ialah parti David Astel, kedua-dua mereka ini tak bertanding dimana-mana bukit dan batang seperti pilihanraya di Malaysia.

Pada mulanya aku cuba undi cara Dan North, sebab dia menjanjikan bahawa rakyat yang buat business prosess dan rakyat marhaen seperti programmer akan dapat menikmati kenikmatan cara Narrator/Story. Tapi selepas diberi peluang memang benar kenikmatan bagi pihak business prosess tapi rakyat marhaen kurang mendapat pembelaan, sebagai ada satu perasaan memberontak kerana untuk mendapat gaji mereka, mereka dikehendaki menulis karangan seperti ini:

Story: Deposit

Narrative:
As a User
I want The bank account balance to increase by the amount deposited
So that I can deposit money

Scenario 1: Money deposit
Given My bank account is empty
When I deposit 100 units
Then The account balance should be 100

Scenario 2: Negative amount deposit
Given My bank account is empty
When I try to deposit a negative amount
Then I get an exception - FAILED
Then the user can not log in


Selepas tu aku cuba pulak memilih parti baru menggunakan cara Context/Specification atau AAA (Arrange/Act/Assert). Buat masa nie aku rasa macam parti nie best sedikit dari parti Dan North dan sudah tentu parti BIJAN tidak menarik minat aku langsung. Aku tunjukkan dulu cara bagaimana aku write BDD guna AAA style.

Mula-mula aku create dahulu SpecificationContext.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace Icms.Tests
{
public abstract class SpecificationContext
{
[TestFixtureSetUp]
public void ContextSetup()
{
Context();
Act();
}

[TestFixtureTearDown]
public void ContextTearDown()
{
Tear_Down();
}

public virtual void Context()
{

}

public virtual void Act()
{
}

public virtual void Tear_Down()
{
}
}
}

Lepas tu aku create pulak SpecificationExtension.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;
using System.Collections;
using System.Xml;

namespace Icms.Tests
{
public static class SpecificationExtension
{
public delegate void MethodThatThrows();

public static void ShouldBeFalse(this bool condition)
{
Assert.IsFalse(condition);
}

public static void ShouldBeTrue(this bool condition)
{
Assert.IsTrue(condition);
}

public static object ShouldEqual(this object actual, object expected)
{
Assert.AreEqual(expected, actual);
return expected;
}

public static object ShouldNotEqual(this object actual, object expected)
{
Assert.AreNotEqual(expected, actual);
return expected;
}

public static void ShouldBeNull(this object anObject)
{
Assert.IsNull(anObject);
}

public static void ShouldNotBeNull(this object anObject)
{
Assert.IsNotNull(anObject);
}

public static object ShouldBeTheSameAs(this object actual, object expected)
{
Assert.AreSame(expected, actual);
return expected;
}

public static object ShouldNotBeTheSameAs(this object actual, object expected)
{
Assert.AreNotSame(expected, actual);
return expected;
}

public static void ShouldBeOfType(this object actual, Type expected)
{
Assert.IsInstanceOfType(expected, actual);
}

public static void ShouldNotBeOfType(this object actual, Type expected)
{
Assert.IsNotInstanceOfType(expected, actual);
}

public static void ShouldContain(this IList actual, object expected)
{
Assert.Contains(expected, actual);
}

public static void ShouldContain(this IEnumerable actual, T expected)
{
ShouldContain(actual, x => x.Equals(expected));
}

public static void ShouldContain(this IEnumerable actual, Func expected)
{
actual.Single(expected).ShouldNotEqual(default(T));
}

public static void ShouldBeEmpty(this IEnumerable actual)
{
actual.Count().ShouldEqual(0);
}

public static void ShouldHaveCount(this IEnumerable actual, int expected)
{
actual.Count().ShouldEqual(expected);
}

public static IComparable ShouldBeGreaterThan(this IComparable arg1, IComparable arg2)
{
Assert.Greater(arg1, arg2);
return arg2;
}

public static IComparable ShouldBeLessThan(this IComparable arg1, IComparable arg2)
{
Assert.Less(arg1, arg2);
return arg2;
}

public static void ShouldBeEmpty(this ICollection collection)
{
Assert.IsEmpty(collection);
}

public static void ShouldBeEmpty(this string aString)
{
Assert.IsEmpty(aString);
}

public static void ShouldNotBeEmpty(this ICollection collection)
{
Assert.IsNotEmpty(collection);
}

public static void ShouldNotBeEmpty(this string aString)
{
Assert.IsNotEmpty(aString);
}

public static void ShouldContain(this string actual, string expected)
{
StringAssert.Contains(expected, actual);
}

public static string ShouldBeEqualIgnoringCase(this string actual, string expected)
{
StringAssert.AreEqualIgnoringCase(expected, actual);
return expected;
}

public static void ShouldEndWith(this string actual, string expected)
{
StringAssert.EndsWith(expected, actual);
}

public static void ShouldStartWith(this string actual, string expected)
{
StringAssert.StartsWith(expected, actual);
}

public static void ShouldContainErrorMessage(this Exception exception, string expected)
{
StringAssert.Contains(expected, exception.Message);
}

public static Exception ShouldBeThrownBy(this Type exceptionType, MethodThatThrows method)
{
Exception exception = null;

try
{
method();
}
catch (Exception e)
{
Assert.AreEqual(exceptionType, e.GetType());
exception = e;
}

if (exception == null)
{
Assert.Fail(String.Format("Expected {0} to be thrown.", exceptionType.FullName));
}

return exception;
}

public static void ShouldEqualSqlDate(this DateTime actual, DateTime expected)
{
TimeSpan timeSpan = actual - expected;
Assert.Less(Math.Abs(timeSpan.TotalMilliseconds), 3);
}

public static object AttributeShouldEqual(this XmlElement element, string attributeName, object expected)
{
Assert.IsNotNull(element, "The Element is null");

string actual = element.GetAttribute(attributeName);
Assert.AreEqual(expected, actual);
return expected;
}

public static XmlElement ShouldHaveChild(this XmlElement element, string xpath)
{
XmlElement child = element.SelectSingleNode(xpath) as XmlElement;
Assert.IsNotNull(child, "Should have a child element matching " + xpath);

return child;
}

public static XmlElement DoesNotHaveAttribute(this XmlElement element, string attributeName)
{
Assert.IsNotNull(element, "The Element is null");
Assert.IsFalse(element.HasAttribute(attributeName), "Element should not have an attribute named " + attributeName);

return element;
}

}
}

Ok dalam AAA style nie cara susun kedudukan file akan membina "Executable Documentation" yang boleh dimanfaatkan oleh banyak pihak. Contoh structure project dan apabila di run menggunakan NUnit




NUnit Result

Natural Spec

Masa tengah coding guna BDD style cara Context/Specification aku terbaca tentang NaturalSpec
Aku plan akan cuba bila ada masa, so tak dapat nak komen.

Friday, April 03, 2009

Single Responsibility Principle

Aku terbaca satu artikel Would Your Objects Praise You?
cuma aku kurang setuju dengan apa yang mamat nie cakap. Ada benarnya tapi tak semuanya betul konsep tu. Apa yang cuba disampaikan ialah konsep Single Responsibility Principal.

The single responsibility principle states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility. [Wikipedia].

Ok, cara dan formula yang di gunakan cukup menarik dan bagus dan aku pun rasa sesuatu yang reasonable unutk digunakan apabila buat domain model anlysis. Formula yang cuba diketengahkan ialah

Can a [type] [action in the infinitive] itself?

So dalam artikel tersebut , mamat nie ambil contoh sebuah kereta


Jadi berdasarkan method yang ada pada kereta tersebut kalau dilihat memang menyalahi SRP. Sebab class Car coupling dengan telalu banyak kerja yang perlu dilakukan. Cuba fikirkan sejenak apa tugas sebuah kereta. Jawapan dia abstract dan berlainan bagi setiap orang, sebab itu SRP nie kalau mengikut pencetus principle yang dekenali sebagai Pakcik Bob pattern yang simple tapi susah untuk dapat yang betul betul ngam.

"The SRP is one of the simplest of the principle, and one of the hardest to get right. Conjoining responsibilities is something that we do naturally. Finding and separating those responsibilities from one another is much of what software design is really about".

Berbalik semula kepada persoalan kereta tadi. Mamat Brian nie cadangkan untuk dapatkan cara yang betul penggunaan SRP ialah dengan melakukan pertanyaan seperti berikut:

  • Can a car change gears by itself?
  • Can a car change a radio station by itself?
  • Can a car drive itself?
  • Can a car idle by itself?
  • Can a car park itself?
  • Can a car start itself?
Dan ini jawapan bagi soalan-soalan tersebut

Unless you’re the lucky owner of the Knight Rider, you probably answered ‘NO’ to a few of these questions. For every question or observation you have answered ‘NO’, you should more than likely refactor the class and move some of its responsibilities elsewhere. But where exactly can you move these responsibilities? Well, before we dive to some of these answers, let’s see if we can directly some of the original questions pertaining to our Car class:
  • Can a car change gears by itself? ANSWER: Sure, if it has an automatic transmission. Otherwise, only the driver can shift gears.
  • Can a car change a radio station by itself? ANSWER: Nope, only the driver (or the passenger) can change the radio station.
  • Can a car drive itself? ANSWER: Not unless it’s KITT! Only a driver can drive a car.
  • Can a car idle by itself? ANSWER: Sure it can.
  • Can a car park itself? ANSWER: Nope! Only a driver can know how to park a car.
  • Can a car start itself? ANSWER: Uh, no. Once again, only the driver can start the car.
Nie pula jawapan aku. Ya memang betul kereta tak boleh change gear sendiri tapi kereta simpan maklumat tentang gear, jadi jika kereta tak boleh nak buat tugas change gear tapi kereta ada maklumat tentang gear jadi nak buat macam mana nie?.. Kalau tanya BIJAN dia jawab kita perlukan kereta yang ada ciri GLOKAL .. hahahah (iklan sebentar). So mamat Brian nie kata keluarkan tugas tersebut kepada seorang Driver (role). Aku tak setuju sangat. Nie contoh yang dia beri dan apa yang diberi sebenarnya valid dan boleh digunakan cuma jika diteliti dengan lebih detail pasti jawapan lain sedikit.


Disini kena faham konsep message to object. Persoalan Driver perlu ada atau tidak masih lagi abstract kepada Domain Expert dan juga untuk apa application ini dihasilkan. Kalau application nie dihasilkan untuk stimulate Video Game dimana dari screen hanya nampak kereta yang boleh dipandu maka class Driver tidak diperlukan sebaliknya class Driver itu digantikan dengan Application Service - CarService.

Ini pula pada pendapat aku, yang dikategorikan sebagai programmer kampung. Untuk mengikut konsep SRP kita perlu pecahkan tugas-tugas tersebut kepada yang berhak, jangan tamak nak ambil tugas orang lain, nasib baik BIJAN tak tamak dia ambik sikit je. Dari class Car kita akan pecahkan kepada class Gear, class Radio, class Engine.


//Car.cs

public class Car

{

public Gear Gear { set; get; }

public Engine Engine { set; get; }

public Radio Radio { set; get; }

public void Drive()

{

}

}


//Engine.cs

public class Engine

{

public void Start()

{

}

}

//Gear.cs

public class Gear

{

public void ChangeGear()

{

}

}

//Radio.cs

public class Radio

{

public void ChangeRadioStation()

{

}

}


//CarService.cs


public class CarService
{
public Car Car { set; get; }

public void ChangeGear()
{
Car.Gear.ChangeGear();
}

public void ChangeRadioStation()
{
Car.Radio.ChangeRadioStation();
}

public void StartEngine()
{
Car.Engine.Start();
}

public void Drive()
{
Car.Drive();
}
}