Spring Web Flow mengembangkan kemampuan Spring MVC dengan framework yang dapat memanajemen alur interaksi sebuah website.
Silakan download.
Monday, February 8, 2010
Spring Web Flow -- ada cheat sheetnya
Spring Web Flow mengembangkan kemampuan Spring MVC dengan framework yang dapat memanajemen alur interaksi sebuah website.
Silakan download.
Saturday, January 16, 2010
Tomcat Out of Memory Error : PermGen space
Apabila aplikasi web Java EE mengalami Out of Memory Error : PermGen space saat dijalankan di Apache Tomcat, ada solusinya.
Workaroundnya adalah memperbesar MaxPermSize. Tambahkan line berikut di launcher tomcat atau environment JAVA_OPTS
-XX:MaxPermSize=256m
Sumber: http://raibledesigns.com/rd/entry/how_do_you_determine_a
Selain itu juga perhatikan beberapa guidelines utk web app tsb, untuk referensi bias lihat http://wiki.apache.org/tomcat/OutOfMemory
Workaroundnya adalah memperbesar MaxPermSize. Tambahkan line berikut di launcher tomcat atau environment JAVA_OPTS
-XX:MaxPermSize=256m
Sumber: http://raibledesigns.com/rd/entry/how_do_you_determine_a
Selain itu juga perhatikan beberapa guidelines utk web app tsb, untuk referensi bias lihat http://wiki.apache.org/tomcat/OutOfMemory
Tuesday, January 12, 2010
Alasan Tidak Menggunakan Stored Procedures
Maintenance DB
Utk maintenance DB... Memang betul, itulah gunanya DBA...
Sebaliknya, dengan membatasi penggunaan fitur2 DBMS, peran DBA bisa diminimalkan bahkan mungkin dihilangkan.
Performa
SP menawarkan performa lebih baik.. Memang benar. Jika pilihannya adalah tanpa SP = lambat dan pakai SP = cepat, saya SP adalah solusi yang baik.
Namun jika pilihannya adalah tanpa SP = cepat dan pakai SP = sedikit lebih cepat, maka bila tetap memakai SP saya menyebutnya premature optimization. Use the rule "Performance is not a problem before performance is a problem" sama Keep It Simple.. No SP is simpler. Rule saya sendiri: gunakan SP hanya jika terpaksa, bukan menggunakan SP sebagai business logic API (setiap fungsi di-wrap dalam SP).
Stored Procedures as Best Practice?
Sebenarnya bisa dimengerti apabila SP dimasukkan sebagai best practice untuk sebuah DBMS (I think it's more marketing than technical).
Tentang prepared statements, yang tidak berhubungan dengan SP, meski fungsinya sedikit mirip. Prepared statement menyiapkan sebuah query untuk dieksekusi berulang2 dengan parameter yang berbeda-beda.
Perbedaannya sangat mendasar: source code SP disimpan dalam database, sedangkan prepared statement code-nya tetap berasal dari aplikasi. App tetap memegang kendali penuh atas code, dan karena it's app code, bisa masuk ke SCM.
Kalau prepared statement... ini memang benar-benar best practices, dan bisa (wajib) diterapkan di app Java terlepas apakah menggunakan SP maupun tidak. Saya jadi curiga, apa semua parameterized query di Java (dari level JDBC) sudah di-prepared statement?
Correctness vs. Unit Testing
Logic yang benar "saat ini" tidak berarti bahwa logic tersebut akan tetap benar saat ada perubahan berikutnya. Ini gunanya unit testing, yang cukup mudah diaplikasikan di Java. Dan ada lagi functional testing dan integration testing.
Develop app Java akan lebih mudah dan tidak terlalu mengkhawatirkan dengan adanya test suites yang baik. Kalau ada perubahan yang memunculkan kesalahan, seharusnya tests jadi FAIL.
Hal ini jadi lebih sulit kalau SP ada di dalam database, karena unit testing lebih sulit. Bukan berarti tidak mungkin... tapi kecenderungannya developer mau menulis test code apabila semakin mudah melakukan unit test. Utk membuat unit test dengan SP, maka harus dilakukan testing dengan real DBMS.. ada banyak issue di sini, misalnya performance dan lifecycle (startup/teardown) serta mungkin workaround. Bila tanpa SP dan implementasi berbasis POJO, unit testing dapat menggunakan mocks.
Sejujurnya, saya sendiri suka malas bikin tests, padahal (relatif) gampang banget, sudah ada Maven, JUnit, Spring test integration, dan didukung IDE. apalagi kalo ribet yah.. gitu sih..
Conclusion
Kesimpulan saya, SP vs no-SP adalah tradeoff, tdk ada salah satu pendekatan yang paling superior. Ada compromise yang harus dipilih. Secara pribadi saya memang bias ke no-SP, dalam artian SP hanya digunakan apabila terpaksa, "default" mode-nya adalah no-SP.
Mirip dengan rasionalisasi ttg memcached. memcached tidak digunakan secara "hantam kromo", check this out: http://www.slideshare.net/err/kickin-ass-with-cachefu
Kutipan:
Utk maintenance DB... Memang betul, itulah gunanya DBA...
Sebaliknya, dengan membatasi penggunaan fitur2 DBMS, peran DBA bisa diminimalkan bahkan mungkin dihilangkan.
Performa
SP menawarkan performa lebih baik.. Memang benar. Jika pilihannya adalah tanpa SP = lambat dan pakai SP = cepat, saya SP adalah solusi yang baik.
Namun jika pilihannya adalah tanpa SP = cepat dan pakai SP = sedikit lebih cepat, maka bila tetap memakai SP saya menyebutnya premature optimization. Use the rule "Performance is not a problem before performance is a problem" sama Keep It Simple.. No SP is simpler. Rule saya sendiri: gunakan SP hanya jika terpaksa, bukan menggunakan SP sebagai business logic API (setiap fungsi di-wrap dalam SP).
Stored Procedures as Best Practice?
Sebenarnya bisa dimengerti apabila SP dimasukkan sebagai best practice untuk sebuah DBMS (I think it's more marketing than technical).
Tentang prepared statements, yang tidak berhubungan dengan SP, meski fungsinya sedikit mirip. Prepared statement menyiapkan sebuah query untuk dieksekusi berulang2 dengan parameter yang berbeda-beda.
Perbedaannya sangat mendasar: source code SP disimpan dalam database, sedangkan prepared statement code-nya tetap berasal dari aplikasi. App tetap memegang kendali penuh atas code, dan karena it's app code, bisa masuk ke SCM.
Kalau prepared statement... ini memang benar-benar best practices, dan bisa (wajib) diterapkan di app Java terlepas apakah menggunakan SP maupun tidak. Saya jadi curiga, apa semua parameterized query di Java (dari level JDBC) sudah di-prepared statement?
Correctness vs. Unit Testing
Logic yang benar "saat ini" tidak berarti bahwa logic tersebut akan tetap benar saat ada perubahan berikutnya. Ini gunanya unit testing, yang cukup mudah diaplikasikan di Java. Dan ada lagi functional testing dan integration testing.
Develop app Java akan lebih mudah dan tidak terlalu mengkhawatirkan dengan adanya test suites yang baik. Kalau ada perubahan yang memunculkan kesalahan, seharusnya tests jadi FAIL.
Hal ini jadi lebih sulit kalau SP ada di dalam database, karena unit testing lebih sulit. Bukan berarti tidak mungkin... tapi kecenderungannya developer mau menulis test code apabila semakin mudah melakukan unit test. Utk membuat unit test dengan SP, maka harus dilakukan testing dengan real DBMS.. ada banyak issue di sini, misalnya performance dan lifecycle (startup/teardown) serta mungkin workaround. Bila tanpa SP dan implementasi berbasis POJO, unit testing dapat menggunakan mocks.
Sejujurnya, saya sendiri suka malas bikin tests, padahal (relatif) gampang banget, sudah ada Maven, JUnit, Spring test integration, dan didukung IDE. apalagi kalo ribet yah.. gitu sih..
Conclusion
Kesimpulan saya, SP vs no-SP adalah tradeoff, tdk ada salah satu pendekatan yang paling superior. Ada compromise yang harus dipilih. Secara pribadi saya memang bias ke no-SP, dalam artian SP hanya digunakan apabila terpaksa, "default" mode-nya adalah no-SP.
Mirip dengan rasionalisasi ttg memcached. memcached tidak digunakan secara "hantam kromo", check this out: http://www.slideshare.net/err/kickin-ass-with-cachefu
Kutipan:
- YAGNI ya ain't gonna need it none of the big guys built memcache into their infrastructure (just ask twitter) build it in later focus on your app first in small apps it is slower than sql hardware is the real special sauce memcached wont help if you cant keep up with the IO requests you probably don't need memcache...
- UYRDNI er-den-ee...
- UYRDNI (unless you really do need it) this would be: - millions of hits - millions of rows - millions of both if you're getting these, you can use memcached to help with the heavy lifting...
Query Database langsung dari Java vs SQL Stored Procedure & Trigger?
Dari Iskandar Saleh:
Helo friends,
Mau tanya nich , Ane pengen buat aplikasi desktop yang menggunakan procedure & triger mysql.
apakah aplikasi yang ane buat ini bisa berjalan cepat jika dibandingkan dengan melakukan query langsung ( Onplay ) di source codenya.
Thaks Responsnya .
Rata-rata kalau pakai procedure & trigger bakal lebih cepat daripada kalau langsung query dari Java app.
Saran saya sich, pakai query langsung dulu..... sampai terbukti bahwa ada query2 yang sangat lambat sampai perlu mempertimbangkan menggunakan procedure/trigger. Itu pun coba gunakan cara lain tlebih dahulu, misalnya querynya diliat dulu, coba index-nya dioptimasi, struktur DBnya diubah agar sesuai utk query tsb, dll.
Why? Krn code Java lebih mudah diubah, dan bisa masuk SVN. Kcuali jika ada DBA khusus, saya berusaha menghindari mengubah skema database hanya sekedar ngedit2 SP dan trigger2nya. Apalagi kalo deployment DB tsb sudah ada beberapa (tidak hanya satu instansi). Sedangkan lumrah bagi aplikasi utk terus didevelop dan diupgrade.
Satu studi kasus adalah Facebook. Mereka punya scalability problem, tp approach mereka tdk hanya sekedar hajar DB atau hajar code.. penyelesaian utama mereka adalah menggunakan memcached.
Check this out:
http://www.slideshare.net/guoqing75/4069180-caching-performance-lessons-from-facebook
Saya lebih gak setuju lagi kalo ada banyak perintah apalagi logic di query tersebut.
Artinya DB logic menjadi kompleks, dan ini sumber dari runtime errors.
Karena mempersulit:
Maintenance software, meski gak gampang, masih lebih ringan daripada maintenance DB.
Satu kelebihan Java code adalah mudah dilakukan unit testing, termasuk untuk mengetes logic dalam sebuah transaction. Theoretically, asal testnya bagus, apabila unit tests pass berarti program berjalan baik. Prakteknya tetep ada issue, sih, but that's better daripada nggak ada support unit testing sama sekali (untuk MySQL procedures, kalo Oracle dll sepertinya dukungan lebih baik).
Saya bukan anti-procedures, tp memang bias ke no-procedures. Menurut saya, stored procedures adalah pilihan terakhir dan hanya digunakan untuk masalah performance yg akut.. yg tdk bisa dipecahkan dengan alternatif solusi yg lain.
Saran saya sich, pakai query langsung dulu..... sampai terbukti bahwa ada query2 yang sangat lambat sampai perlu mempertimbangkan menggunakan procedure/trigger. Itu pun coba gunakan cara lain tlebih dahulu, misalnya querynya diliat dulu, coba index-nya dioptimasi, struktur DBnya diubah agar sesuai utk query tsb, dll.
Why? Krn code Java lebih mudah diubah, dan bisa masuk SVN. Kcuali jika ada DBA khusus, saya berusaha menghindari mengubah skema database hanya sekedar ngedit2 SP dan trigger2nya. Apalagi kalo deployment DB tsb sudah ada beberapa (tidak hanya satu instansi). Sedangkan lumrah bagi aplikasi utk terus didevelop dan diupgrade.
Satu studi kasus adalah Facebook. Mereka punya scalability problem, tp approach mereka tdk hanya sekedar hajar DB atau hajar code.. penyelesaian utama mereka adalah menggunakan memcached.
Check this out:
http://www.slideshare.net/guoqing75/4069180-caching-performance-lessons-from-facebook
Saya lebih gak setuju lagi kalo ada banyak perintah apalagi logic di query tersebut.
Artinya DB logic menjadi kompleks, dan ini sumber dari runtime errors.
Karena mempersulit:
- unit testing
- debugging kalo ada masalah
- maintenance DB jadi lebih berat
- nggak bisa lihat history (via SCM)
Maintenance software, meski gak gampang, masih lebih ringan daripada maintenance DB.
Satu kelebihan Java code adalah mudah dilakukan unit testing, termasuk untuk mengetes logic dalam sebuah transaction. Theoretically, asal testnya bagus, apabila unit tests pass berarti program berjalan baik. Prakteknya tetep ada issue, sih, but that's better daripada nggak ada support unit testing sama sekali (untuk MySQL procedures, kalo Oracle dll sepertinya dukungan lebih baik).
Saya bukan anti-procedures, tp memang bias ke no-procedures. Menurut saya, stored procedures adalah pilihan terakhir dan hanya digunakan untuk masalah performance yg akut.. yg tdk bisa dipecahkan dengan alternatif solusi yg lain.
Mengapa Spring untuk Web Development?
Alasan awal saya sendiri pake Spring karena de facto & propaganda saja, banyak yg pake Spring.
Terus, library2 yang dipakai, nyaris semua punya Spring integration. Lebih jarang yang bilang "Jboss integration", "Guice integration", "EJB integration", apalagi "CDI integration". Contoh: Apache Camel, Apache CXF, ...
"Keunggulan" lainnya adalah aplikasi Spring bisa jalan di container standard Tomcat, jadi kalo misalnya mau nyoba di hosting, murah bahkan mungkin free. nggak perlu dedicated atau VPS. Belakangan saya tau kalo JBoss Seam juga bisa jalan di Tomcat, tapi harus modify instalasi Tomcatnya, kalo shared hosting kan tetep nggak bisa?
Soal JBoss Seam, jujur saya tertarik, karena lebih full-stack dan convention-nya jelas. Di Spring lebih cenderung mix-and-match. Bisa pake Spring MVC atau pake yg lain. Bisa pake Spring Web Flow kalau mau ala JSF. Framework yang didukung SpringSource sendiri ada beberapa: Spring MVC, Spring MVC + Web Flow, Spring Roo, dan Grails. Enaknya, banyak framework Java pakai Spring Framework sebagai core, jadi menurut saya skill Spring cukup dibutuhkan bagi programmer Java.
Google Apps Engine developmen juga menarik, dan meski lebih cepat kalo plain servlet, tapi masih reasonable kalo pake Spring core maupun Spring MVC. Kalo pake JBoss Seam, saya sangat yakin... bahkan jalan saja kayanya enggak.
Murni JavaEE? Buat saya Java EE = EJB dkk. Kalo yg dimaksud plain servlet, saya bukan tipe orang se-lowlevel itu hehe. Cuma memang saya mulai berusaha agar thin server-side dan fat client-side, seperti saya tulis di AdaRuby - Quest for Fluid Web Framework : http://www.adaruby.com/2010/01/08/quest-for-the-fluid-web-framework/
(Intermezzo: Sayangnya setelah beberapa eksperimen, ternyata "thin server-side" ini agak sulit direalisasikan secara pure. Ada beberapa kepentingan, misalnya authentication, security, ORM, dan inpage SEO.. yang membuat thin server-side kurang practical.)
Bagaimana dengan Anda, punya preferensi web framework Java ?
Subscribe to:
Posts (Atom)