Thursday, April 27, 2006
Macam2
Code quality for software architects.
Build and Implement A Single Sign-On Solution.
Using a Java based Kerberos module to securely authenticate users against
Active Directory.
LdapTemplate: LDAP Programming in Java Made Simple.
Bringing Swing to the Web.
Writing Cool Games for Cellular Devices.
ehcache-1.2 released - distributed caching, listeners and more.
Obix Configuration Framework 1.0 Released. Web site Obix.
JAG 6.0 released: Tapestry 4, XFire SOAP & Acegi Security. Web site Jag.
Build your own scripting language for Java. An introduction to JSR 223.
The Mustang Meets the Rhino: Scripting in Java 6.
Advanced MySQL Replication Techniques.
Ajax Programming in BEA WebLogic Portal 8.1, Part 2.
Understanding Service Oriented Architecture.
Database Connection Pooling with Tomcat.
Using Solaris SMF.
An Introduction to the Enterprise JavaBeans 3.0 Specification.
Agile Object to Relational Database Replication with db4o.
Prototype: Easing AJAX's Pain.
(2) comments
Code quality for software architects.
Build and Implement A Single Sign-On Solution.
Using a Java based Kerberos module to securely authenticate users against
Active Directory.
LdapTemplate: LDAP Programming in Java Made Simple.
Bringing Swing to the Web.
Writing Cool Games for Cellular Devices.
ehcache-1.2 released - distributed caching, listeners and more.
Obix Configuration Framework 1.0 Released. Web site Obix.
JAG 6.0 released: Tapestry 4, XFire SOAP & Acegi Security. Web site Jag.
Build your own scripting language for Java. An introduction to JSR 223.
The Mustang Meets the Rhino: Scripting in Java 6.
Advanced MySQL Replication Techniques.
Ajax Programming in BEA WebLogic Portal 8.1, Part 2.
Understanding Service Oriented Architecture.
Database Connection Pooling with Tomcat.
Using Solaris SMF.
An Introduction to the Enterprise JavaBeans 3.0 Specification.
Agile Object to Relational Database Replication with db4o.
Prototype: Easing AJAX's Pain.
Tuesday, April 18, 2006
Macam2 Lagi
Currency Calculator.
HTTP-Tunnel Client Software. Free. Server dia pun free hanya slow. Yg berbayar punya laju. Jadi la...
Installation guide dia kat sini.
Not bad. Saya cuba dgn Firefox, menjadi. Hanya slow. Sesuai utk tempat2 yg block, katakan ym ke, email ke, etc. Check it out!
Macam2
Using the Java Persistence API with Spring 2.0.
Vocal Java.
Exception-Handling Antipatterns.
Introducing JAXX: A New Way to Swing.
Understanding Service Oriented Architecture.
MultiSplitPane: Splitting Without Nesting.
Time Again.
FMJ: open-source JMF alternative.
EJB3 Persistence Jumpstart.
Introduction to the Java Speech API.
Scripting Support in Mustang.
Simplified Wrapper and Interface Generator (SWIG).
The Framework for Integrated Tests (Fit).
(0) comments
Currency Calculator.
HTTP-Tunnel Client Software. Free. Server dia pun free hanya slow. Yg berbayar punya laju. Jadi la...
Installation guide dia kat sini.
Not bad. Saya cuba dgn Firefox, menjadi. Hanya slow. Sesuai utk tempat2 yg block, katakan ym ke, email ke, etc. Check it out!
Macam2
Using the Java Persistence API with Spring 2.0.
Vocal Java.
Exception-Handling Antipatterns.
Introducing JAXX: A New Way to Swing.
Understanding Service Oriented Architecture.
MultiSplitPane: Splitting Without Nesting.
Time Again.
FMJ: open-source JMF alternative.
EJB3 Persistence Jumpstart.
Introduction to the Java Speech API.
Scripting Support in Mustang.
Simplified Wrapper and Interface Generator (SWIG).
The Framework for Integrated Tests (Fit).
Sunday, April 09, 2006
Unit Test dan TDD
Soalan 1
========
> Adakah menggunakan unit test ni _menjimatkan
> masa_? Maksudnya, maybe masa yg dijimatkan utk membetulkan bug tu lebih
> berbaloi dari masa yg diambil utk menulis unit tests..
Jika keadaannya ialah, develop seorang diri, dgn tempoh masa menghasilkan sistem lebih kurang 6 bulan lamanya, dimana, sistem tu bersifat one-off, takde enhancement maka, unit test mungkin tidak menjimatkan masa.
Jika, keadaannya lebih dpd diatas iaitu:
1. lebih dpd 6 bulan utk hasilkan satu2 version,
2. mempunyai fasa enhancement seterusnya,
3. lebih dpd 1 orang dlm team,
maka, saya yakin, unit test mampu menjimatkan masa.
Cth 1
-----
Seorang developer yg boleh tahan bagus, develop sistem yg lebih dpd ½ tahun lamanya, katakan 1 tahun. Setiap bulan, dia hasilkan sejumlah feature utk sistem dia, mengunakan Incremental & Iterative (I&I). Design dan code keseluruhan sistem dlm genggaman kepala otak dia. Dibulan ke 4, ke 5 dan ke 6, apa2 penambahan yg menyentuh code2 3 bulan pertama tu, dia ingat lagi dan boleh analisa kesannya kpd deliverables 3 bulan pertama tu. Setakat ini, apa2 perubahan yg dibuat, menimbulkan bugs yg minima. So, kesan dan faedah unit test, teramat la kurangnya.
Berdasarkan pengalaman, seorang develop tak mampu nak teruskan tahap ini utk fasa2 berikutnya bermula dgn bulan ke 7. Dia mula lupa dan terlepas design dan code2 yg dilakukan berbulan2 sebelumnya. Mula la timbul bugs spt cendawan selepas hari hujan selepas peringkat ini berlaku. Akibatnya, 6 bulan terakhir ni, developer tu mula menumpu masa utk fix bugs dgn ketaranya. Productivity dia drop.
Utk developer yg mengunakan unit test dari bulan pertama lagi, mampu mengejar developer di atas ni di peringkat kedua dan menyamai dia digarisan penamat, iaitu apabila tamat tempoh setahun tu.
Satu lagi variable. Adakah sistem yg telah dibina selama 1 tahun ni is a one-off? Jika ya, maka, seri la kedua2 developer ni. Jika tidak, dan diyakini bhw begitu banyak sistem zaman kini yg memberi faedah kpd pengguna2nya, akan melalui fasa enhancement, maka, developer yg pertama atau kedua yg menang?
Kalau saya la, saya nak jadi developer yg kedua tu.
Cth 2
-----
Satu team kecil, tak sampai 5 developer, kena buat sistem yg lebih dpd ½ tahun. Seorang sw architect menghasilkan core object model utk sistem dan setiap team members diberikan features/use case2 yg perlu disiapkan berdasarkan core object model tersebut.
Setiap developer akan hasilkan code2 yg baru dan juga menggunakan code2 kongsi. Code2 kongsi ini adalah code2 core object model tu yg semua orang guna dan kongsi. Sekali sekala, bila keadaan memerlukan, code2 kongsi ini akan diupdate utk support keperluan dlm feature/use case. Selalunya, software architect / team lead akan melakukan ini. Dan code kongsi ini selalunya antara 30% hingga 70% dpd code yg diperlukan utk siapkan bhgn masing2 utk release bulan tu.
Besar peranan code kongsi ni kan? Ini tak termasuk code2 yg bukan core kpd object model, tapi masih dikongsi bersama antara beberapa developer, walaupun tak semua.
Tanpa unit test, tak perlu lama utk huru hara / chaos bermaharaja lela, kalau tiada pengawasan dan kawalan yg ketat. Pengawasan dan kawalan ini pula perlu masa dan tenaga seseorang, dgn banyaknya, terutamanya di 2nd half of the project period.
Dgn unit test, saya yakin, team kedua ini mampu menyamai team pertama yg tak guna unit test di bulan ke 7/8. Diperingkat akhir, team kedua ini mampu mengalahkan team pertama, dan jimat 1 developer lagi krn tak payah buat pengawasan full time krn unit test yg setiap developer hasilkan, bertindak mengawasi dan mengawal kesihatan keseluruhan code2 dlm projek. Utk team kedua, kurangnya berlaku fire fighting, kurangnya stress, kurangnya balik lewat diakhir projek dan lebih syok hasilkan sistem. Susah2 dahulu, senang2 kemudian.
Kedua2 cth diatas adalah cth penjimatan masa semasa fasa development, utk developer2 sendiri. Mungkin applicable kpd anda, mungkin tidak.
Satu lagi penjimatan masa yg kurang nyata faedahnya, tapi sebenarnya lebih hebat dpd penjimatan masa development ialah masa maintenance/enhancement.
Long after the original GREAT TEAM dah berjaya hasilkan pelbagai sistem2 hebat sampai version 10 la, 20 la, etc, di mana ahli2 GREAT TEAM ini dah pun berhijrah ke company2 lain cthnya, atau pencen, atau turun 6 kaki, etc, maka, team baru yg kena handle sejumlah sistem2 ini nak buat macammana?
Baca beberapa tan document yg telah dihasilkan setiap kali nak tambah seciput feature ke dlm sistem dan berdoa agar tidak ada bugs yg timbul dlm sistem?
Kesian. Kesian sekali team baru ini. Kalau la mereka bernasib baik spt satu lagi team yg seperti mereka tapi GREAT TEAM kedua ini dah mewariskan penunggu kpd team baru kedua ini yg bernama Jin Unit Test.
Team baru kedua ni, setiap kali nak tambah apa2 ke dlm sistem kedua, selepas merujuk kpd beberapa kilo documentation, terus melakukannya dan terus juga meminta bapak Jin Unit Test utk run, akan terus mendapat jawapan sama ada lampu hijau atau merah. Kalau lampu hijau, developer2 team2 ke2 ini happy. Kalau lampu merah pun developer2 team kedua ni happy krn bug yg dihasilkan secara tak sengaja semasa nak tambah feature baru tu, berjaya dikesan sebelum dimasukkan ke production lagi...
Unit test yg dihasilkan, adalah ibarat developer2 asal yg sentiasa menjaga code2 yg telah dihasilkan dari tahun ke tahun, dekad ke dekat, abad ke abad...
Unit test menjimatkan masa? Ya, dulu, kini dan selamanya...
Soalan 2
========
> TDD boleh digunakan tanpa ada domain/model driven
> design secara KHUSUS
> "Sebenarnya, yg saya kurang faham, mcm mana boleh dikatakan test driven
> design bila first and foremost kita kena ada satu "object" utk di test?"
Yg saya faham, TDD pun menggunakan object model sebagai asas dia, TAPI, object model dia is TEST DRIVEN! Sebagai seorang yg biasa dgn object model, saya tak terlalu fokus sangat utk memastikan object model yg dihasilkan tu, boleh ditest dgn senangnya masa mula2 hasilkan object model. Tapi, utk TDD, object model yg dihasilkan sentiasa dipastikan boleh ditest, awal2 lagi.
Perbezaannya disini ialah kepentingan memasukkan design yg sesuai utk dilakukan tests. Utk object model biasa, itu dilakukan kemudian sedikit dan kalau tak boleh dilakukan dgn senang, refactor. Utk TDD, ia adalah first and foremost dan mesti dimasukkan ke dlm design.
Saya ok aje dgn TDD, tapi sebab2 kenapa saya tak menggunakan TDD ialah:
1. Saya meletak kepentingan utk capture the problem domain sebagai no 1. Apa2 pun, sistem yg dihasilkan hendaklah memenuhi requirement client/pengguna. So, utk saya, no 1 ialah utk hasilkan object model that correctly models the problem domain. Saya tak mahu apa2 yg lain utk ganggu fokus ini termasuk testing.
2. Memasukkan design yg senang utk dilakukan testing kpd object model, bukan la susah sangat. Selalunya, design yg baik mampu menyokong keperluan utk tests. Hanya sejumlah tests shj yg memerlukan refactoring kpd object model utk menyokong senang test.
Pendapat saya aje.
Sudoku dan sewaktu dgnnya
3000 free Sudoku's in Excel.
Sudoku Works 4 Kids 1.
365 Free Sudoku Puzzles to print 2.3.
Killer Sudoku or Sum Sudoku.
Sudoku Midlet.
Sudoku Puzzles for Kids.
Brave Kid Sudoku.
Free Kid Sudoku Puzzles.
Daily kid SuDoku.
Daily Sudoku Puzzle.
More Free Kids Sudoku.
DC Proof 1.0.
(1) comments
Soalan 1
========
> Adakah menggunakan unit test ni _menjimatkan
> masa_? Maksudnya, maybe masa yg dijimatkan utk membetulkan bug tu lebih
> berbaloi dari masa yg diambil utk menulis unit tests..
Jika keadaannya ialah, develop seorang diri, dgn tempoh masa menghasilkan sistem lebih kurang 6 bulan lamanya, dimana, sistem tu bersifat one-off, takde enhancement maka, unit test mungkin tidak menjimatkan masa.
Jika, keadaannya lebih dpd diatas iaitu:
1. lebih dpd 6 bulan utk hasilkan satu2 version,
2. mempunyai fasa enhancement seterusnya,
3. lebih dpd 1 orang dlm team,
maka, saya yakin, unit test mampu menjimatkan masa.
Cth 1
-----
Seorang developer yg boleh tahan bagus, develop sistem yg lebih dpd ½ tahun lamanya, katakan 1 tahun. Setiap bulan, dia hasilkan sejumlah feature utk sistem dia, mengunakan Incremental & Iterative (I&I). Design dan code keseluruhan sistem dlm genggaman kepala otak dia. Dibulan ke 4, ke 5 dan ke 6, apa2 penambahan yg menyentuh code2 3 bulan pertama tu, dia ingat lagi dan boleh analisa kesannya kpd deliverables 3 bulan pertama tu. Setakat ini, apa2 perubahan yg dibuat, menimbulkan bugs yg minima. So, kesan dan faedah unit test, teramat la kurangnya.
Berdasarkan pengalaman, seorang develop tak mampu nak teruskan tahap ini utk fasa2 berikutnya bermula dgn bulan ke 7. Dia mula lupa dan terlepas design dan code2 yg dilakukan berbulan2 sebelumnya. Mula la timbul bugs spt cendawan selepas hari hujan selepas peringkat ini berlaku. Akibatnya, 6 bulan terakhir ni, developer tu mula menumpu masa utk fix bugs dgn ketaranya. Productivity dia drop.
Utk developer yg mengunakan unit test dari bulan pertama lagi, mampu mengejar developer di atas ni di peringkat kedua dan menyamai dia digarisan penamat, iaitu apabila tamat tempoh setahun tu.
Satu lagi variable. Adakah sistem yg telah dibina selama 1 tahun ni is a one-off? Jika ya, maka, seri la kedua2 developer ni. Jika tidak, dan diyakini bhw begitu banyak sistem zaman kini yg memberi faedah kpd pengguna2nya, akan melalui fasa enhancement, maka, developer yg pertama atau kedua yg menang?
Kalau saya la, saya nak jadi developer yg kedua tu.
Cth 2
-----
Satu team kecil, tak sampai 5 developer, kena buat sistem yg lebih dpd ½ tahun. Seorang sw architect menghasilkan core object model utk sistem dan setiap team members diberikan features/use case2 yg perlu disiapkan berdasarkan core object model tersebut.
Setiap developer akan hasilkan code2 yg baru dan juga menggunakan code2 kongsi. Code2 kongsi ini adalah code2 core object model tu yg semua orang guna dan kongsi. Sekali sekala, bila keadaan memerlukan, code2 kongsi ini akan diupdate utk support keperluan dlm feature/use case. Selalunya, software architect / team lead akan melakukan ini. Dan code kongsi ini selalunya antara 30% hingga 70% dpd code yg diperlukan utk siapkan bhgn masing2 utk release bulan tu.
Besar peranan code kongsi ni kan? Ini tak termasuk code2 yg bukan core kpd object model, tapi masih dikongsi bersama antara beberapa developer, walaupun tak semua.
Tanpa unit test, tak perlu lama utk huru hara / chaos bermaharaja lela, kalau tiada pengawasan dan kawalan yg ketat. Pengawasan dan kawalan ini pula perlu masa dan tenaga seseorang, dgn banyaknya, terutamanya di 2nd half of the project period.
Dgn unit test, saya yakin, team kedua ini mampu menyamai team pertama yg tak guna unit test di bulan ke 7/8. Diperingkat akhir, team kedua ini mampu mengalahkan team pertama, dan jimat 1 developer lagi krn tak payah buat pengawasan full time krn unit test yg setiap developer hasilkan, bertindak mengawasi dan mengawal kesihatan keseluruhan code2 dlm projek. Utk team kedua, kurangnya berlaku fire fighting, kurangnya stress, kurangnya balik lewat diakhir projek dan lebih syok hasilkan sistem. Susah2 dahulu, senang2 kemudian.
Kedua2 cth diatas adalah cth penjimatan masa semasa fasa development, utk developer2 sendiri. Mungkin applicable kpd anda, mungkin tidak.
Satu lagi penjimatan masa yg kurang nyata faedahnya, tapi sebenarnya lebih hebat dpd penjimatan masa development ialah masa maintenance/enhancement.
Long after the original GREAT TEAM dah berjaya hasilkan pelbagai sistem2 hebat sampai version 10 la, 20 la, etc, di mana ahli2 GREAT TEAM ini dah pun berhijrah ke company2 lain cthnya, atau pencen, atau turun 6 kaki, etc, maka, team baru yg kena handle sejumlah sistem2 ini nak buat macammana?
Baca beberapa tan document yg telah dihasilkan setiap kali nak tambah seciput feature ke dlm sistem dan berdoa agar tidak ada bugs yg timbul dlm sistem?
Kesian. Kesian sekali team baru ini. Kalau la mereka bernasib baik spt satu lagi team yg seperti mereka tapi GREAT TEAM kedua ini dah mewariskan penunggu kpd team baru kedua ini yg bernama Jin Unit Test.
Team baru kedua ni, setiap kali nak tambah apa2 ke dlm sistem kedua, selepas merujuk kpd beberapa kilo documentation, terus melakukannya dan terus juga meminta bapak Jin Unit Test utk run, akan terus mendapat jawapan sama ada lampu hijau atau merah. Kalau lampu hijau, developer2 team2 ke2 ini happy. Kalau lampu merah pun developer2 team kedua ni happy krn bug yg dihasilkan secara tak sengaja semasa nak tambah feature baru tu, berjaya dikesan sebelum dimasukkan ke production lagi...
Unit test yg dihasilkan, adalah ibarat developer2 asal yg sentiasa menjaga code2 yg telah dihasilkan dari tahun ke tahun, dekad ke dekat, abad ke abad...
Unit test menjimatkan masa? Ya, dulu, kini dan selamanya...
Soalan 2
========
> TDD boleh digunakan tanpa ada domain/model driven
> design secara KHUSUS
> "Sebenarnya, yg saya kurang faham, mcm mana boleh dikatakan test driven
> design bila first and foremost kita kena ada satu "object" utk di test?"
Yg saya faham, TDD pun menggunakan object model sebagai asas dia, TAPI, object model dia is TEST DRIVEN! Sebagai seorang yg biasa dgn object model, saya tak terlalu fokus sangat utk memastikan object model yg dihasilkan tu, boleh ditest dgn senangnya masa mula2 hasilkan object model. Tapi, utk TDD, object model yg dihasilkan sentiasa dipastikan boleh ditest, awal2 lagi.
Perbezaannya disini ialah kepentingan memasukkan design yg sesuai utk dilakukan tests. Utk object model biasa, itu dilakukan kemudian sedikit dan kalau tak boleh dilakukan dgn senang, refactor. Utk TDD, ia adalah first and foremost dan mesti dimasukkan ke dlm design.
Saya ok aje dgn TDD, tapi sebab2 kenapa saya tak menggunakan TDD ialah:
1. Saya meletak kepentingan utk capture the problem domain sebagai no 1. Apa2 pun, sistem yg dihasilkan hendaklah memenuhi requirement client/pengguna. So, utk saya, no 1 ialah utk hasilkan object model that correctly models the problem domain. Saya tak mahu apa2 yg lain utk ganggu fokus ini termasuk testing.
2. Memasukkan design yg senang utk dilakukan testing kpd object model, bukan la susah sangat. Selalunya, design yg baik mampu menyokong keperluan utk tests. Hanya sejumlah tests shj yg memerlukan refactoring kpd object model utk menyokong senang test.
Pendapat saya aje.
Sudoku dan sewaktu dgnnya
3000 free Sudoku's in Excel.
Sudoku Works 4 Kids 1.
365 Free Sudoku Puzzles to print 2.3.
Killer Sudoku or Sum Sudoku.
Sudoku Midlet.
Sudoku Puzzles for Kids.
Brave Kid Sudoku.
Free Kid Sudoku Puzzles.
Daily kid SuDoku.
Daily Sudoku Puzzle.
More Free Kids Sudoku.
DC Proof 1.0.
Monday, April 03, 2006
Status Interview
Dah finalize list utk diberi kpd CEO. Aim nak bagi hari ini gak. Nak minta tolong rakan sekerja utk bind dan submit kpd CEO's office dan bagi satu salinan kpd HR.
Lepas tu, kena tunggu queue CEO la. Khabarnya, ada yg dah tunggu lebih sebulan utk dipanggil interview. Aduuhh! Harapnya, bos saya dpt ingat2kan CEO. Ialahkan, CEO sendiri yg nak team ini ditubuhkan. Harapnya dpt la dia meluangkan masa utk calon2 ini. Kalau kena potong queue pun, potong la... Sori ye...
Kursus SAP EM
Ha! Kursus SAP lagi, kali ini, SAP Event Management plak. Semalam belajar nak hasilkan event handler dan update expected events yg dihasilkan semasa event handler tu dibuat, berdasarkan event handler type.
Ceh! Bunyi macam bagus, walhal tin kosong aje :b :)
Kursus tamat esok, hari rabu. 3 hari punya course.
Unit Test
Adakah menggunakan unit test lebih menjimatkan masa atau melambatkan? Itu la persoalan yg ditanya kat group mmyooad.
Komen saya, tunggu... Nak pi kursus ni. Bila sempat, saya update kat mmyooad dan blog ini gak. Penat gak cerita pasal unit test kat beberapa orang semasa interview tempoh hari. Nanti, saya print aje la dan bagi semua orang yg nak diinterview utk baca. Tak payah terang berkali2. :D
(2) comments
Dah finalize list utk diberi kpd CEO. Aim nak bagi hari ini gak. Nak minta tolong rakan sekerja utk bind dan submit kpd CEO's office dan bagi satu salinan kpd HR.
Lepas tu, kena tunggu queue CEO la. Khabarnya, ada yg dah tunggu lebih sebulan utk dipanggil interview. Aduuhh! Harapnya, bos saya dpt ingat2kan CEO. Ialahkan, CEO sendiri yg nak team ini ditubuhkan. Harapnya dpt la dia meluangkan masa utk calon2 ini. Kalau kena potong queue pun, potong la... Sori ye...
Kursus SAP EM
Ha! Kursus SAP lagi, kali ini, SAP Event Management plak. Semalam belajar nak hasilkan event handler dan update expected events yg dihasilkan semasa event handler tu dibuat, berdasarkan event handler type.
Ceh! Bunyi macam bagus, walhal tin kosong aje :b :)
Kursus tamat esok, hari rabu. 3 hari punya course.
Unit Test
Adakah menggunakan unit test lebih menjimatkan masa atau melambatkan? Itu la persoalan yg ditanya kat group mmyooad.
Komen saya, tunggu... Nak pi kursus ni. Bila sempat, saya update kat mmyooad dan blog ini gak. Penat gak cerita pasal unit test kat beberapa orang semasa interview tempoh hari. Nanti, saya print aje la dan bagi semua orang yg nak diinterview utk baca. Tak payah terang berkali2. :D
