<$BlogRSDUrl$>

Tuesday, December 30, 2003

Alhamdulillah, setelah kena belasah dgn AspectJ selama 2 jam sampai tergolek2 semalam, akhirnya berjaya gak tambah paparan utk HTTPRequest kat semua subclass struts Action. Bengang betul krn, RnD yg dibuat macam a ok je.

Apa yg saya nak buat ialah amat mudah iaitu paparkan segala isi kandungan HTTPRequest. Itu je. Boleh guna cara biasa, tapi nak mencuba cara aop. Masalahnya, code utk aspect tersebut tak dijalankan langsung! Saya nak paparan ni run sebelum mana2 code dlm method perform tu dijalankan. Tapi, gagal. Paparan langsung tak kelihatan.

Sebabnya ialah krn saya guna pointcut "call". Setelah tukar ke pointcut "execution", ia berjalan dgn cun nya. Baru saya faham, call ni adalah pointcut kat code pemanggil dan execution adalah pointcut kat code dipanggil. Padan la tak jln masa guna call krn code pemanggil adalah code dlm framework struts itu sendiri yg memang tak diubah, iaitu dlm struts.jar

hmmm..., ok la gak. 2 jam punya pelajaran semalam.

(0) comments

Monday, December 29, 2003

OK, saya buh je RnD yg saya dah buat tentang AspectJ. Pandai2 la baca, faham dan tafsir sendiri :)

download aspectj, dan unzip katakan di C.

env.bat:
set ASPECT_HOME=C:\aspectj1.1
set JAVA_HOME=C:\j2sdk1.4.2_03
set PATH=%PATH%;%JAVA_HOME%\bin;%ASPECT_HOME%\bin
set CLASSPATH=%CLASSPATH%;%ASPECT_HOME%\lib\aspectjrt.jar

file utama / mula2: Test.java
public class Test
{
public static void say(String msg)
{
System.out.println(msg);
}

public static void sayToPerson(String name, String msg)
{
System.out.println(name + ", " + msg);
}

public static void main(String[] args)
{
Test.say("To be or not to be.");
System.out.println();
Test.sayToPerson("ahmad", "To be or not to be the 2nd.");
}
}

compile pakai aspectj compiler:
ajc Test.java

outputnya apabila run java Test:
To be or not to be.

ahmad, To be or not to be the 2nd.



file aspect pertama: TestAspect.java
public aspect TestAspect
{
pointcut callSayMessage() : call(public static void Test.say*(..));

before() : callSayMessage()
{
sayPekaba();
}

after() : callSayMessage()
{
sayBabai();
}

public void sayPekaba()
{
System.out.println("Pekaba!");
}

public void sayBabai()
{
System.out.println("Babai!");
}
}

compile:
ajc *.java

outputnya:
Pekaba!
To be or not to be.
Babai!

Pekaba!
ahmad, To be or not to be the 2nd.
Babai!



file aspect kpd aspect:
public aspect TestTestAspect
{
pointcut callMulaJumpa() : call(public void TestAspect.sayPekaba());
pointcut callBerpisah() : call(public void TestAspect.sayBabai());

before() : callMulaJumpa()
{
sayAkum();
}

after() : callBerpisah()
{
sayAkum();
}

public void sayAkum()
{
System.out.println("Akum!");
}

}

compile dan run, outputnya:
Akum!
Pekaba!
To be or not to be.
Babai!
Akum!

Akum!
Pekaba!
ahmad, To be or not to be the 2nd.
Babai!
Akum!



amacam, senang je kan, kan :)

(0) comments

Sunday, December 28, 2003

Waduh, waduh! Hello world aop ni memang senang, tapi nak masuk real world programming, tak semudah tu, spt yg dijangka :D

Sibuk betul dgn paper work sejak 1 ke 2 minggu ni. Tak sempat nak buat proper example utk tontonan umum. Prototype development pun teramat la lambatnya. Huh! Bila boleh masuk developer saya ni yek?! ;) Masih lampu kuning ni, sheeh!

(0) comments

Thursday, December 18, 2003

YES! Berjaya! Berjaya! Berjaya buat hello world equivalent dgn aspectj! hehehe :D

Sonang je rupanya. Ant support utk aspectj pun a ok.

Bila sempat nanti, saya post kan code2 RnD.

(0) comments

Wednesday, December 17, 2003

Groovy. Huh? Apa kebendanya groovy ni? Dah dengar beberapa kali, tapi, tak amik kesah pun. Sampai la terbaca thread

http://www.theserverside.com/home/thread.jsp?thread_id=22902

dan salah satu dpd posting dlm thread tu, iaitu graham glass, pakar java yg berjaya buat sistem2 dasat spt Voyager, ElectricXml, Glue dan Gaia, PUN recommend Groovy

http://groovy.codehaus.org/index.html

ni kes mesti check it out ni. sheeh. lagi kena rnd...

(0) comments

Tuesday, December 16, 2003

OK, baru balik dpd kursus "fundamendal logistics management" selama 2 hari. Menarik la juga.

Beberapa berita menarik:
1. AspectWerkz 0.9 RC1 dah release! Macam mamat tu dengor je komen saya tentang projek dia dah tak aktif, hehehe! http://www.theserverside.com/home/thread.jsp?thread_id=22901
2. Refactoring guna AOP, artikel kedua kat http://www.theserverside.com/home/thread.jsp?thread_id=22904. Hmmm, artikel pertama tak habis baca lagi....
3. JVM power, JRockit ver 1.4.2 dah release, http://www.theserverside.com/home/thread.jsp?thread_id=22895. Ia kononnya teramat la powernya berbanding JVM yg Sun buat. Nak kena download ni.

(0) comments

Thursday, December 11, 2003

Hoorey! Hibernate, salah satu tool dlm kategori OR (Object Relational) Mapper yg dasat dah release version baru iaitu 2.1. Links:
http://www.theserverside.com/home/thread.jsp?thread_id=22841
http://www.hibernate.org/

Hmm... bila nak belaja ye? Selit2 baca la nampaknya, masa dlm train. Hmm... bila nak upgrade code generator saya tu kpd hibernate, serta memaksimumkan object model mengikut keupayaan hibernate? Sekarang ni, ia dimaksimumkan mengikut castor, yg kurang sikit efisiennya. Hmm...

Tambahan tentang AOP. Saya baru perabis revise balik baca tentang AOP melalui artikel2:
http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect_p.html - part 1
http://www.javaworld.com/javaworld/jw-03-2002/jw-0301-aspect2_p.html - part 2
http://www.javaworld.com/javaworld/jw-04-2002/jw-0412-aspect3_p.html - part 3

Sekarang, saya dah semakin faham tentang AOP, dpd 30% sebelum ni kpd 50%! OK la. AOP ni bukannya mudah nak faham, at least bukan mudah utk saya. Kena try it out. Harapnya notebook saya cepat2 la balik dpd service center dia.

(0) comments

Wednesday, December 10, 2003

Wokey, sedikit update shj. Syarikat The Mind Electric, pembuat beberapa tools software yang dasat, iaitu gaia, glue dan electricxml, telah pun dibeli oleh syarikat WebMethods beberapa bulan yg lepas. Kat web site mereka (www.themindelectric.com) pun dah nampak gabungan produk2 masing2.

Yang saya tak nampak ialah electric xml. Terkejut dan risau akan nasibnya. Adakah ia di.... nyahkan? Pastinya tidak. Paling tidak pun, ia tidak kelihatan sebagai produk, tapi built in dlm glue krn glue memang menggunakannya.

Setelah dpt emai dpd rizan, bhw dia baru je download electric xml, saya pi mencari lagi, dan setelah login ke page downloadnya... ITU DIA! Sihat rupanya :-) Bahkan dah semakin membesar dah. Dah version 8 beta 2 dah! Wah, wah, wah. Makin besau dia. Dulu kecik aje. Nak download? Naaahh. Biarlah dia sempurna bersalin kulit dia dulu.

Satu lagi, baru mula baca balik tentang AOP. Nampaknya saya kena download AspectJ jugak. AspectWerkz dah macam tak aktif sejak main developer dia join Bea. More to come on aop.

(0) comments

Monday, December 08, 2003

> .net multi language(java satu je)

multi language Java ni sebenarnya kurang popular, tapi wujud, antaranya support utk Ruby dan Python (jython). Saya pernah baca terdapat lebih 10 programming lang. yg digunakan di atas java byte code.

(0) comments

>kalu banding java ngan .net application... mane lagi ok in term of hasil and application

saya tak pernah guna .net tapi saya yakini kedua2nya ada kelebihan dan kelemahan masing2. satu faktor yg elok diambil kira ialah keselesaan, style dan citarasa diri sendiri terhadap kedua2nya, mahupun dgn programming lang. dan teknologi yg lain.

utk saya, saya jauh lebih selesa dgn Java berbanding C, assembly lang. mahupun VB. tapi, satu kelemahan atau boleh dianggap sebagai kelebihan ialah, keselesaan dgn Java ni bukan datang bergolek. saya kena sediakan environment supaya ia lebih selesa, dari masa ke semasa.

maksud saya, walaupun teknologi java dah baik, tapi as is, ia masih tak cukup bagus dan saya tak puas hati. saya berusaha utk jadikan ia lebih bagus utk buat sistem dlm beberapa kategori:
1. 3rd party tools
2. development environment
3. custom tools
4. complementary development techniques


3rd party tools spt :
1. OR mapper spt castor, hibernate, etc
2. Xml Parser spt electric xml
3. Web service spt glue
4. Application Server spt tomcat, jetty, jboss
5. Unit Test spt JUnit
Semua tools ini dan banyak lagi, adalah complement kpd teknologi sedia ada dlm Java, dan menambahkan nilai dan keselesaannya.


Development environment spt:
1. ant utk customise build sw kita, mengikut cara yg kita nak.
2. IDE spt eclipse

One size does not fit all. Oleh itu, menggunakan ant dll, kita customise environment sw dev kita mengikut selera kita. Dari masa ke semasa, bila nak ubah cara build sw, adalah amat senang krn kita ada hampir kawalan penuh terhadapnya. Cth nak build sw adalah spt step2 berikut:
a. compile semua files dlm dir src ke target dir
b. runkan semua unit test terhadap code yg telah berjaya dicompile
c. create file utk deployment spt war, jar, ear
d. copy file deployment ke application server
e. arahkan application server utk reload application yg baru di deploy.

Semua steps diatas diautomatekan dlm build process dgn hanya 1 arahan.


Custom tools
Buat la customs tools sendiri utk memperkemaskan lagi development kita. Cthnya, hasilkan code generator yg menghasilkan pelbagai code, configuration files, html/javascript, dll. Gabungkan kalau boleh, dgn ant build kita. Ini mampu meningkatkan productivity kita beberapa kali ganda.


Complementary development techniques
Masa guna VB dulu, saya kantul dlm mempelajari OOAD selama lebih 1 tahun. Setelah berpindah ke Java dan dapat bimbingan dlm OOAD, saya dapati antara faktor penghalang kpd saya belajar OOAD ialah cara development dlm VB yg 'unik'. Perlunya 'unlearn' cara ini utk lebih mudah menerima OOAD. Dan, setelah belajar OOAD, saya merasakan ianya amat sesuai dgn Java. Meningkatkan keselesaan saya.

Ni pendapat dan pengalaman saya je. Lain orang, lain pendapat dan pengalaman. Take it for what it's worth.

(0) comments

> ...pemahaman dalam business process lagi penting...kebanyakkan orang buleh jadi power dalam programming...it's just a matter of time je...tapi business process tak ramai yang terror...

utk saya, pemahaman dlm business process tu comes with the project. kalau kita kena buat sistem inventory, kena la faham domain inventory tu dpd pakar inventory. apabila siap sistem tu kelak, kita masih bukan pakar, tapi tahu la jugak tentang inventory tu sendiri, business flow dan process dia.

jadi, utk saya, yg paling penting bagi seseorang sw dev ialah pengetahuan utk membina sw dlm spectrum yg luas dpd projeck management, methodology, team leadership, user requirements capturing spt use case, analysis & design spt OOAD dan object model, code, pelbagai algo yg dasat2 spt genetic algo, pelbagai teknik2 yg dasat spt AOP, pelbagai communication protocol/medium spt web services, xml-rpc, EDI, etc. tumpukan la fokus utk menguasai kepakaran2 dlm spektrum ini.

tang domain knowledge tu, usah la risau, kerana, when the time comes, kita perlu belajar domain khusus utk projek tersebut. dan dlm dunia ni terdpt begitu banyak domain2 yg tak termampu utk dipelajari kesemuanya. dan kita tak perlu pun tahu jika belum tiba masanya. ya, kalau dah tahu tu bagus la, tapi tak perlu kalau tiada keperluan. ni kerana, memang dah terdapat domain expert dlm bidang masing2.

cth domain expert ialah pakar dlm supply chain, logistics, warehouse management, fleet management, fleet optimization, tracking and security, building automation, prison management, payphone management, accounting, payrol, e-learning, energy saving, dll. yg disenaraikan ni hanyalah segelintir dpd pelbagai domain yg wujud dlm dunia, dgn business process masing2.

bahkan, dlm logistics pun, ada yg pakar dlm inbound (barang2 luar di bawa masuk ke dlm negeri - import) dan ada yg pakar dlm outbound (export), tak semestinya pakar dlm kedua2nya. ada pulak yg pakar dlm logistics tempatan dan bukan import/export. ada plak yg pakar dlm sea freight dan bukan dlm air freight. ada yg pakar utk logistics dlm negara tertentu spt singapore dan bukan utk negara malaysia yg lain sikit spt perlu berinteraksi dgn DagangNet. dlm satu domain pun terdpt pelbagai kepakaran tertentu.

sebagaimana terdapat kepakaran2 tertentu dlm setiap domain ini, begitu juga la terdpt kepakaran2 tertentu dlm sw dev. saya berpendapat, lamanya kita dlm bidang sw dev ni, belum menjamin kita jadi terror dlmnya. terdpt begitu banyak sudut dan ceruk dlm sw dev ni yg perlu dipelajari dan belum tentu dpt dikuasai walaupun seumur hidup sekali pun.

utk saya sendiri, dan saya dah pun ceritakan begitu banyak kali, bhw usaha saya belajar OOAD adalah melalui susah payah. lebih 1 tahun dan beribu2 ringgit company saya perabiskan melalui kursus, training CDs, buku dll adalah sia2 shj. hanya dgn izin Allah, company saya dipertemukan dgn OO mentor ni dan dlm masa 2 minggu pertama, saya dah dpt 'on'kan lampu dlm kepala saya. perubahan paradigma telah berlaku. kalau tak diizinkan, saya agak, sampai la ni pun saya masih kantul dlm OOAD.

semua ni adalah pendapat saya je dpd apa yg saya alami. lain orang lain pengalaman dan pendapat. YMMV.

(0) comments

Saya dan team saya dulu pernah kena buat projek yg guna visual c++ utk hasilkan fax engine utk cirrus chip set, sekitar 97/98. Hancus! complexity nye melampaui tahap saya. Akhirnya projek tu kantul, bukan krn tak siap, tapi krn dipermain2kan oleh satu syarikat dpd US yg menjanjikan seribu satu janji (senang je, kami boleh ajar dan bimbing, jgn risau, siap punya, etc).

Kami bernasib baik krn masa tu, saya dpt seorang Object Oriented consultant tempatan, DZ. Dia grade dpt PhD kat Australia dan jadi VP RnD salah sebuah syarikat terkemuka tempatan masa tu sebelum go on his own. Utk bantu projek ni, dia bawak masuk seorang mamat tempatan juga, S, yg rupa2nya, walaupun berdarah jawa, tapi tak mahir Java, tapi mahir giler C, sejak zaman U kat us lagi khabarnya. Memang terror si S tu.

Berbekalkan buku tentang fax protocol dll yg saya beli tapi tak faham / tak reti, beserta bimbingan DZ tu, dia berjaya siapkan fax engine guna C. Antara kepayahan fax engine ni ialah:
1. memerlukan real time programming krn fax protocol ni ada berbagai peringkat dan setiap peringkat ada beberapa ms shj utk siapkannya.
2. memahami setiap peringkat ni bukan la mudah.

Walaupun S ni tahap sederhana dlm C++ dan kurang mahir dlm OOAD, tapi ke terror an dia dlm C memang cukup hebat.

Kesimpulannya, utk setiap projek yg hendak dibuat, analisa risiko2 yg ada dan cuba atasinya. Dlm kes saya, kami dah cuba, tapi tahap C/C++ yg lemah beserta kelemahan dlm real time & time critical programming, memerlukan pakar utk masuk, join the team dan bagi dia ruang utk manuver. Hanya bila dia dah selesa, barulah dia mula ajar kpd selected team members utk technology transfer. Yg penting, system tu siap.

Tapi, sama penting atau lebih penting ialah, jgn la percaya sangat dgn syarikat2 yg promote product dan keupayaan mereka seolah2 tahap dewa. Mereka banyak yg tipu. Akibatnya, syarikat yg saya keje tu mengalami kerugian yg besau dan terpaksa downsize.

(0) comments

Saya sebenarnya agak hancus dgn user requirements capturing. Saya memang tak pandai & kurang sabar dgn pengguna yg malas utk buat keje dia spt seorang HR manager yg tak mau hasilkan company polisi & procedure dan menjadikan user requirements capturing excerice tu sebagai tempat dia throw ideas, kemudian ubah, throw lagi ideas, ubah lagi.

Shoot!! Dia sepatutnya hasilkan doc yg mengandungi polici + procedure tu dulu, dipersetujui semua pihak yg terbabit, baru handover kpd team yg kena buat sw HR tu. Tapi, dia malas dan hanya salahkan orang lain.

Malangnya, client sedemikian agak ramai. Saya belum mampu handle user sedemikian lagi. Tapi, saya kenal beberapa orang yg memang terror dlm bab ni. Mereka pandai handle orang dan mahir dlm project management on the client handling side. Utk projek yg besar dan punya client sedemikian, saya kena bergabung dgn mereka ni. Kalau tak, hancus nanti.

Kebanyakan projek memang perlu dibuat dlm satu team. Saya bernasib baik dpt rasa kedua2 situasi, sendirian dan dlm team. Saya bermula dgn jadi solo programmer buat 2 jenis payphone management system, satu bercakap dgn Tamura coin payphone guna dtmf dan satu lagi dgn payphone yg guna modem. Buat sorang2 selama lebih 2 tahun.

Kemudian bermula fasa handle team lebih 10 org 2 kali dan hanya 2 orang sekali. Memang berbeza handle team ni. Kesimpulan yg saya buat utk diri saya sendiri ialah, apabila join satu team baru utk satu projek baru, berusaha la utk memahami projek yg hendak dibuat tu, takat mana kompleknya dari segi domain nye mahupun teknologi yg nak diguna, serta time frame utk siapkan.

Berusaha la utk ketahui kekuatan dan kelemahan team members kita. Map kan kekuatan dan kelemahan mereka ni dgn projek yg hendak dibuat. Mana2 kelemahan yg ada, tampung dgn team members yg kuat dlm bhgn yg orang lain lemah. Kalau dah tak ada, kita aje la yg tampung kelemahan tersebut jika mampu.

Cthnya, utk salah satu team yg saya join beberapa tahun lepas. Mereka kena buat satu projek guna J2EE. Ramai team members yg agak lemah dlm Java, apatah lagi J2EE. Hanya seorang je programmer dari india yg agak mahir dlm Java dan J2EE (team ni ada 2 programmer india muslim dan yg selebihnya orang tempatan). Peringkat awal saya join adalah peringkat fire fighting. Saya dan programmer india ni terpaksa banyak tampung kelemahan team members, dlm mendebug code mereka dan dlm cara2 utk mereka buat module mereka.

Cut off point dlm projek ni ialah bila programmer india tu pun hadapi beberapa bugs yg dia sendiri tak boleh nak debug. Selepas saya debugkan utk dia, saya ambil keputusan utk hasilkan satu framework yg sepatutnya lebih mudah dpd J2EE tu sendiri, yet ia menggunakan J2EE secara transparent. Setelah terhasilnya framework ini dan apabila setiap team members berjaya menyiapkan module pertama mereka menggunakan framework, baru la produktiviti team secara keseluruhan meningkat akibat berkurangan dgn mendadaknya bugs2 yg J2EE related.

Satu point penting ialah continuous improvement. Bawa la masuk teknologi/tools/libs yg berbaloi utk diperkenalkan kpd team members, cthnya:
1. perkenalkan ant kpd team tersebut dan bila cairo join team ni, dia berjaya enhance kan lagi supaya boleh seamless build dan auto deploy kat tomcat utk development, dan ke iplanet utk production. framework yg ada tu membolehkan application kami run kat atas web container shj mahupun web + ejb container secara transparent.
2. perkenalkan OR mapper castor. Productivity utk buat code2 db terus meningkat beberapa kali ganda krn senang dan cepatnya nak code db access ni beserta hilang la bugs spt max cursor exceeded, etc.
3. perkenalkan electric xml yg jauh lebih senang dan power berbanding dgn parser xerces yg guna sax/dom.

Tapi, ada juga yg saya perkenalkan tu tak mendapat sambutan walaupun berbuih mulut spt junit utk buat unit test. Hancus. Hanya sekerat je yg buat sikit2. Berat betul mereka nak buat unit test.

Ni pengalaman saya je.

(0) comments

Saya nak post beberapa tulisan saya yg ditulis dlm beberapa forum tempatan. Sebabnya, kadang kala, soalan yg sama berulang kembali. So, malas nak tulis lagi dan lagi. Tulis kat sini je la.

Bermula dgn:

Saya mulakan kerjaya sebagai programmer, lebih 8 tahun yg lepas (ish, terasa tua plak ). masa tu, hanya fikir programming je. hanya lepas beberapa tahun melakukan programming, baru saya sedar wujudnya dunia yg lebih luas dlm sw dev ni. aktiviti programming dan programming language hanyalah sebahagian dpd dunia sw dev ni.

antaranya ialah sw methodology, sw project and team management dan teknik2 OOAD dan architecture spt Design Patterns, Analysis Patterns, Object Model, Use case, etc.

setelah menggabungkan kemahiran utama (core competency) programming dgn OOAD yg juga dijadikan kemahiran utama, dan yg lain2 kemahiran kedua (secondary/supporting competencies), saya dapati terdpt permintaan yg agak tinggi utk skill set sedemikian. err, gajinya pun agak lumayan jawatan ni biasanya diberi nama sw architect.

dulu, saya tak dpt jumpa company kat m'sia yg wujudkan jawatan ni. tapi, Alhamdulillah, setelah join satu company tu, selepas tamat contract pertama selama 6 bulan saya (jawatan System Analyst), depa wujudkan jawatan sw architect tu utk contract kedua selama 2 tahun.

bulan lepas saya pi interview, ketiga2 company yg saya apply, semuanya ada offer jawatan sw architect. saya rasa ini satu perkembangan yg memberangsangkan utk industri IT negara kita. dlm masa beberapa tahun je, dah semakin banyak kesedaran tentang tahap2 teknikal dlm sw dev ni. semoga semakin banyak kesedaran ni timbul, utk manfaat semua, kecuali consultant2 luar yg membolot jawatan2 ini sebelum wujudnya kesedaran.

(0) comments

This page is powered by Blogger. Isn't yours?