Re: [JUG-Indonesia] [ask] Codesmith di java
http://www.artima.com/intv/dry2.html 2008/12/23 Jecki jecki...@gmail.com: yup.. codegen sebaiknya dipakai dengan prinsip 'Generate Once Run Anywhere' hehe.. (kayanya pernah denger :P). painfull kalo musti di-maintain lagi. cocok untuk simple CRUD yg pattern-nya mirip pleg. -- syaiful.mukhlis gtalk:syaiful.mukh...@gmail.com
Re: [JUG-Indonesia] [ask] Codesmith di java
kenapa di java code generation/templating itu kurang laku, mungkin karena prinsipnya templating itu kan konsep interfacing+inherintance dan java dan orang java cukup jago disini jadinya udah nggak perlu pake templating yang lain cukup pake yang naturenya java punya. gitu kali yach...:pis...:(lol) 2008/12/17 sm96 syaiful.mukh...@gmail.com yah, soal ejb2 dah pada tahu lah... tapi xdoclet tidak identik dengan ejb2 kan... pake xdoclet bukan berarti pasti pake ejb2 kan. dan codegen gak cuma xdoclet aja kan. kalo cuma ngomong xdoclet, dah pada tau kan nasibnya kayak gimana skrg. (kecuali yg belum tau). karena codegen itu penting utk banyak hal, dimana utk solusi2 tertentu ternyata tidak harus coding by hand. 2008/12/15 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: Ato simply put.. API yg requires codegen baru bisa dipake dengan nyaman biasanya berarti APInya terlalu noisy dan ribet. Mau insert 1 row ajah mesti nulis dulu 3 classes dan 10 methods... dan baca 10 chapter textbook. Framework yg DRY dan gak leaky-abstraction, gak butuh codegen at first place... Dan personally banyak orang yg prefer ini. Tapi kadang2 codegen dibutuhin gara2 limitation dari static language, terlalu limited buat produce fluent interface (e.g. NHQG). Disini codegen cuma buat shut the compiler up. 2008/12/15 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com Maksud gw bukan itu... Bukan code gen bikin repetition... Tapi design EJB2 itu butuh banyak noise n repetition, makanya butuh codegen kayak xdocklet buat ease the pain. Padahal disini xdocklet sebenernya gak lebih dari quick hack buat get around the underlying problem... yaitu design API EJB2 yg ridiculously verbose, unreadable, n repetitive. Disini yg gw maksud manfaat codegen yg illusive. Emang codegen ngebantu banget daripada mesti nulis pake tangan, tapi tetep lebih baik API designnya yg dibenerin supaya gak noisy dan human friendly.. dimana lo gak butuh lagi codegen. Kayak yg dah dibenerin di ejb3. Tapi codegen juga sebenernya banyak dipake buat tujuan bener. Gw gak tau napa banyak comment yg undermining codegen di java. Padahal NHQG (NHibernate Query Generator) itu contoh codegen yg bener2 ngebantu banget di .net. Contohnya, ini query Many-To-Many di nhibernate: User usr = User.FindOne( Where.User.Name == Hendry Where.User.Roles.With().Name == Administrator ); Strong type... far better daripada HQL. Dan (di c# 2) ini cuma possible dengan code-generator buat autogenerate class Where beserta setiap subclassnya buat tiap entity (e,g, Where.User.Roles). nb: di c# 3 ini udah deprecated direplace linq 2008/12/15 sm96 syaiful.mukh...@gmail.comsyaiful.mukhlis%40gmail.com ini juga satu factor kelemahan yg terlalu dibesar-besarkan. padahal sebenarnya bisa-bisa saja DRY diterapkan di code generator manapun. hanya karena, developer pemakai code generator pengen cepetnya aja, sehingga gak terlalu mikirin masalah DRY. jika penggunaan code generator sudah optimal, duplikasi apa lagi yg masih harus dipermasalahkan? berarti masalah duplikasi itu yang harus diresolve di sisi code generatornya. ekstrimnya, apakah kita gak mau mengulang2 ngetik statement macam 'public class .. extends implements ' ini masuk DRY apa bukan? jelas bukan dong? tapi code generator bisa dibikin dengan menerapkan DRY didalamnya. Kalau masih ada yg menganggap code generator 'jatuh' karena 'melanggar' prinsip DRY, apa itu berarti developer2 ini gak mahir pake code generator. 2008/12/11 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: Masalahnya bukan code generator vs tanpa code generator. Tapi code generator vs code yg DRY dan low noise yg gak butuh generator at first place. Alasan xdocklet di ejb2 kan gara2 banyak butuh duplication n code noise dimana2 :( 2008/12/9 sm96 syaiful.mukh...@gmail.comsyaiful.mukhlis%40gmail.com kesalahan terbesar pada penggunaan code generator adalah, setelah code digenerate, trus dimodifikasi code hasil generate tsb. padahal jika konsisten dalam penerapan cara ini, mesti code generatornya yang disempurnakan, disertai dengan konfigurasi yang disempurnakan juga. bukan berarti code generator adalah sekali generate masalah langsung beres. kalo ada masalah, code generator yg disempurnakan sedemikian rupa, sehingga pada saat generate code yg diperlukan, tidak memakan waktu yg lama. dipikirkan juga, bahwa code yg sudah digenerate juga tidak perlu digenerate ulang. pada menyadari atau tidak, proses compiler, interpreter, codeweaver, bytecode enhancer, bytecode engineering, sebenarnya ini termasuk juga dalam kategori code generator. hanya saja untuk kasus ini, code yang dihasilkan, tidak pernah diubah-ubah lagi, dan tinggal dieksekusi. netbeans, sudah bertahun menerapkan cara seperti ini, form design aslinya
Re: [JUG-Indonesia] [ask] Codesmith di java
Bagian ejb2/xdocklet nya gak penting. Cuma mo make point bahwa... emang codegen gak selalu painful dibanding handcode... dan emang codegen bisa disempurnain dan gak require manual modification... Tapi bukan itu alesan codegen dijauhin. *Codegen* itu gak bad*. Needing a codegen* itu yang bad... karna indicates codenya painful.. yang mesti dibius pake codegen... tanpa ngobatin source of the pain.. Cuma mindahin pain nya dari tangan ke mesin... Regardless of sesempurna apa codegennya. 2008/12/17 sm96 syaiful.mukh...@gmail.com yah, soal ejb2 dah pada tahu lah... tapi xdoclet tidak identik dengan ejb2 kan... pake xdoclet bukan berarti pasti pake ejb2 kan. dan codegen gak cuma xdoclet aja kan. kalo cuma ngomong xdoclet, dah pada tau kan nasibnya kayak gimana skrg. (kecuali yg belum tau). karena codegen itu penting utk banyak hal, dimana utk solusi2 tertentu ternyata tidak harus coding by hand. 2008/12/15 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: Ato simply put.. API yg requires codegen baru bisa dipake dengan nyaman biasanya berarti APInya terlalu noisy dan ribet. Mau insert 1 row ajah mesti nulis dulu 3 classes dan 10 methods... dan baca 10 chapter textbook. Framework yg DRY dan gak leaky-abstraction, gak butuh codegen at first place... Dan personally banyak orang yg prefer ini. Tapi kadang2 codegen dibutuhin gara2 limitation dari static language, terlalu limited buat produce fluent interface (e.g. NHQG). Disini codegen cuma buat shut the compiler up. 2008/12/15 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com Maksud gw bukan itu... Bukan code gen bikin repetition... Tapi design EJB2 itu butuh banyak noise n repetition, makanya butuh codegen kayak xdocklet buat ease the pain. Padahal disini xdocklet sebenernya gak lebih dari quick hack buat get around the underlying problem... yaitu design API EJB2 yg ridiculously verbose, unreadable, n repetitive. Disini yg gw maksud manfaat codegen yg illusive. Emang codegen ngebantu banget daripada mesti nulis pake tangan, tapi tetep lebih baik API designnya yg dibenerin supaya gak noisy dan human friendly.. dimana lo gak butuh lagi codegen. Kayak yg dah dibenerin di ejb3. Tapi codegen juga sebenernya banyak dipake buat tujuan bener. Gw gak tau napa banyak comment yg undermining codegen di java. Padahal NHQG (NHibernate Query Generator) itu contoh codegen yg bener2 ngebantu banget di .net. Contohnya, ini query Many-To-Many di nhibernate: User usr = User.FindOne( Where.User.Name == Hendry Where.User.Roles.With().Name == Administrator ); Strong type... far better daripada HQL. Dan (di c# 2) ini cuma possible dengan code-generator buat autogenerate class Where beserta setiap subclassnya buat tiap entity (e,g, Where.User.Roles). nb: di c# 3 ini udah deprecated direplace linq 2008/12/15 sm96 syaiful.mukh...@gmail.comsyaiful.mukhlis%40gmail.com ini juga satu factor kelemahan yg terlalu dibesar-besarkan. padahal sebenarnya bisa-bisa saja DRY diterapkan di code generator manapun. hanya karena, developer pemakai code generator pengen cepetnya aja, sehingga gak terlalu mikirin masalah DRY. jika penggunaan code generator sudah optimal, duplikasi apa lagi yg masih harus dipermasalahkan? berarti masalah duplikasi itu yang harus diresolve di sisi code generatornya. ekstrimnya, apakah kita gak mau mengulang2 ngetik statement macam 'public class .. extends implements ' ini masuk DRY apa bukan? jelas bukan dong? tapi code generator bisa dibikin dengan menerapkan DRY didalamnya. Kalau masih ada yg menganggap code generator 'jatuh' karena 'melanggar' prinsip DRY, apa itu berarti developer2 ini gak mahir pake code generator. 2008/12/11 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: Masalahnya bukan code generator vs tanpa code generator. Tapi code generator vs code yg DRY dan low noise yg gak butuh generator at first place. Alasan xdocklet di ejb2 kan gara2 banyak butuh duplication n code noise dimana2 :( 2008/12/9 sm96 syaiful.mukh...@gmail.comsyaiful.mukhlis%40gmail.com kesalahan terbesar pada penggunaan code generator adalah, setelah code digenerate, trus dimodifikasi code hasil generate tsb. padahal jika konsisten dalam penerapan cara ini, mesti code generatornya yang disempurnakan, disertai dengan konfigurasi yang disempurnakan juga. bukan berarti code generator adalah sekali generate masalah langsung beres. kalo ada masalah, code generator yg disempurnakan sedemikian rupa, sehingga pada saat generate code yg diperlukan, tidak memakan waktu yg lama. dipikirkan juga, bahwa code yg sudah digenerate juga tidak perlu digenerate ulang. pada menyadari atau tidak, proses compiler, interpreter, codeweaver, bytecode enhancer, bytecode engineering, sebenarnya ini termasuk juga dalam kategori code generator. hanya
Re: [JUG-Indonesia] [ask] Codesmith di java
2008/12/18 Hira Sirojudin hirasiroju...@gmail.com: kenapa di java code generation/templating itu kurang laku, mungkin karena prinsipnya templating itu kan konsep interfacing+inherintance dan java dan orang java cukup jago disini jadinya udah nggak perlu pake templating yang lain cukup pake yang naturenya java punya. gitu kali yach...:pis...:(lol) pandangan yang optimis :D. kemungkinan lain adalah code generation ditinggalin karena uda ga relevan (specific ke tiap issue). misal hibernate doclet ud ditinggal karena ada annotation, ejb doclet ditinggal karena ada ejb3 yang less painfull. CMIIW setau gw appfuse ada codegen juga kan? jadi codegen masih relevan dong, cuma ya pakenya dengan bijak.
Re: [JUG-Indonesia] [ask] Codesmith di java
Codegen banyak ditinggalkan karena menurut pengalaman saya, effort (codegen+modification) = effort buat sendiri. Modification di sini termasuk penyesuaian untuk specific case, code convention. Codegen lebih baik digunakan untuk prototyping saja, untuk production lebih baik buat manual saja. Para rubynius saja jarang kok yang menggunakan scaffoldingnya RoR untuk production. 2008/12/23 Jecki jecki...@gmail.com: pandangan yang optimis :D. kemungkinan lain adalah code generation ditinggalin karena uda ga relevan (specific ke tiap issue). misal hibernate doclet ud ditinggal karena ada annotation, ejb doclet ditinggal karena ada ejb3 yang less painfull. CMIIW setau gw appfuse ada codegen juga kan? jadi codegen masih relevan dong, cuma ya pakenya dengan bijak. -- Bustanil Arifin Keep moving forward!
Re: [JUG-Indonesia] [ask] Codesmith di java
codegen memang painful, crud mulus ok laaah.. trus ada ganti component, regenerate.. celakanya yang diatasnya uda kita costumize... bisa siy diakalin pake extends code generatednya sebelum dipakai, jadi yang kita pakai yang uda turunannya code yang digenerate, cuma klu uda beda banget sama sebelumnya tetep aja recode yang uda kita costumize... dan yang jelas code ga bersih.. DRYnya codegen beda banget sama DRYnya framework. untuk scaffolding gw ini pendekatan framework bukan codegen, cmiiw 2008/12/23 Bustanil Arifin street.program...@gmail.com: Codegen banyak ditinggalkan karena menurut pengalaman saya, effort (codegen+modification) = effort buat sendiri. Modification di sini termasuk penyesuaian untuk specific case, code convention. Codegen lebih baik digunakan untuk prototyping saja, untuk production lebih baik buat manual saja. Para rubynius saja jarang kok yang menggunakan scaffoldingnya RoR untuk production. 2008/12/23 Jecki jecki...@gmail.com: pandangan yang optimis :D. kemungkinan lain adalah code generation ditinggalin karena uda ga relevan (specific ke tiap issue). misal hibernate doclet ud ditinggal karena ada annotation, ejb doclet ditinggal karena ada ejb3 yang less painfull. CMIIW setau gw appfuse ada codegen juga kan? jadi codegen masih relevan dong, cuma ya pakenya dengan bijak. -- Bustanil Arifin Keep moving forward! -- __ rEEk 'o hEEk Xinix Technology Geek Email / GTalk / Jabber: reekoh...@gmail.com YM!: reeko_fing...@yahoo.com Website: http://reekoheek.wordpress.com/ http://reekodezz.wordpress.com/
Re: [JUG-Indonesia] [ask] Codesmith di java
yup.. codegen sebaiknya dipakai dengan prinsip 'Generate Once Run Anywhere' hehe.. (kayanya pernah denger :P). painfull kalo musti di-maintain lagi. cocok untuk simple CRUD yg pattern-nya mirip pleg. 2008/12/23 rEEk 'o hEEk reekoh...@gmail.com: codegen memang painful, crud mulus ok laaah.. trus ada ganti component, regenerate.. celakanya yang diatasnya uda kita costumize... bisa siy diakalin pake extends code generatednya sebelum dipakai, jadi yang kita pakai yang uda turunannya code yang digenerate, cuma klu uda beda banget sama sebelumnya tetep aja recode yang uda kita costumize... dan yang jelas code ga bersih.. DRYnya codegen beda banget sama DRYnya framework. untuk scaffolding gw ini pendekatan framework bukan codegen, cmiiw 2008/12/23 Bustanil Arifin street.program...@gmail.com: Codegen banyak ditinggalkan karena menurut pengalaman saya, effort (codegen+modification) = effort buat sendiri. Modification di sini termasuk penyesuaian untuk specific case, code convention. Codegen lebih baik digunakan untuk prototyping saja, untuk production lebih baik buat manual saja. Para rubynius saja jarang kok yang menggunakan scaffoldingnya RoR untuk production. 2008/12/23 Jecki jecki...@gmail.com: pandangan yang optimis :D. kemungkinan lain adalah code generation ditinggalin karena uda ga relevan (specific ke tiap issue). misal hibernate doclet ud ditinggal karena ada annotation, ejb doclet ditinggal karena ada ejb3 yang less painfull. CMIIW setau gw appfuse ada codegen juga kan? jadi codegen masih relevan dong, cuma ya pakenya dengan bijak.
Re: [JUG-Indonesia] [ask] Codesmith di java
di weblogic kan banyak banget code generator nya... ejb aja pake EJBGen... gua personally pake integration suite nya... in the background ini sama seperti java class yang transactionally controlled by EJB... semua code nya generated... tinggal drag drop... (bukan web component) code generated nya oke juga koq... meskipun bener point nya sm96... kita generate lalu kita modify lagi, percuma... gua personally suka code yang bersih banget... so dengan banyak nya documentation dan comment, gua pasti bakal apus satu2... however ridiculously painful... lalu kalo ada bug, toh gua bakal pertama cari dari generated code nya... jadi all those time going thru the generated code to clean the code is worth it... at least you know what was generated... although it partially defeats the purpose of having a generator... Regards, Jonathan Handoyo 2008/12/15 Hendry Luk hendrym...@gmail.com Ato simply put.. API yg requires codegen baru bisa dipake dengan nyaman biasanya berarti APInya terlalu noisy dan ribet. Mau insert 1 row ajah mesti nulis dulu 3 classes dan 10 methods... dan baca 10 chapter textbook. Framework yg DRY dan gak leaky-abstraction, gak butuh codegen at first place... Dan personally banyak orang yg prefer ini. Tapi kadang2 codegen dibutuhin gara2 limitation dari static language, terlalu limited buat produce fluent interface (e.g. NHQG). Disini codegen cuma buat shut the compiler up. 2008/12/15 Hendry Luk hendrym...@gmail.com Maksud gw bukan itu... Bukan code gen bikin repetition... Tapi design EJB2 itu butuh banyak noise n repetition, makanya butuh codegen kayak xdocklet buat ease the pain. Padahal disini xdocklet sebenernya gak lebih dari quick hack buat get around the underlying problem... yaitu design API EJB2 yg ridiculously verbose, unreadable, n repetitive. Disini yg gw maksud manfaat codegen yg illusive. Emang codegen ngebantu banget daripada mesti nulis pake tangan, tapi tetep lebih baik API designnya yg dibenerin supaya gak noisy dan human friendly.. dimana lo gak butuh lagi codegen. Kayak yg dah dibenerin di ejb3. Tapi codegen juga sebenernya banyak dipake buat tujuan bener. Gw gak tau napa banyak comment yg undermining codegen di java. Padahal NHQG (NHibernate Query Generator) itu contoh codegen yg bener2 ngebantu banget di .net. Contohnya, ini query Many-To-Many di nhibernate: User usr = User.FindOne( Where.User.Name == Hendry Where.User.Roles.With().Name == Administrator ); Strong type... far better daripada HQL. Dan (di c# 2) ini cuma possible dengan code-generator buat autogenerate class Where beserta setiap subclassnya buat tiap entity (e,g, Where.User.Roles). nb: di c# 3 ini udah deprecated direplace linq 2008/12/15 sm96 syaiful.mukh...@gmail.com ini juga satu factor kelemahan yg terlalu dibesar-besarkan. padahal sebenarnya bisa-bisa saja DRY diterapkan di code generator manapun. hanya karena, developer pemakai code generator pengen cepetnya aja, sehingga gak terlalu mikirin masalah DRY. jika penggunaan code generator sudah optimal, duplikasi apa lagi yg masih harus dipermasalahkan? berarti masalah duplikasi itu yang harus diresolve di sisi code generatornya. ekstrimnya, apakah kita gak mau mengulang2 ngetik statement macam 'public class .. extends implements ' ini masuk DRY apa bukan? jelas bukan dong? tapi code generator bisa dibikin dengan menerapkan DRY didalamnya. Kalau masih ada yg menganggap code generator 'jatuh' karena 'melanggar' prinsip DRY, apa itu berarti developer2 ini gak mahir pake code generator. 2008/12/11 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: Masalahnya bukan code generator vs tanpa code generator. Tapi code generator vs code yg DRY dan low noise yg gak butuh generator at first place. Alasan xdocklet di ejb2 kan gara2 banyak butuh duplication n code noise dimana2 :( 2008/12/9 sm96 syaiful.mukh...@gmail.comsyaiful.mukhlis%40gmail.com kesalahan terbesar pada penggunaan code generator adalah, setelah code digenerate, trus dimodifikasi code hasil generate tsb. padahal jika konsisten dalam penerapan cara ini, mesti code generatornya yang disempurnakan, disertai dengan konfigurasi yang disempurnakan juga. bukan berarti code generator adalah sekali generate masalah langsung beres. kalo ada masalah, code generator yg disempurnakan sedemikian rupa, sehingga pada saat generate code yg diperlukan, tidak memakan waktu yg lama. dipikirkan juga, bahwa code yg sudah digenerate juga tidak perlu digenerate ulang. pada menyadari atau tidak, proses compiler, interpreter, codeweaver, bytecode enhancer, bytecode engineering, sebenarnya ini termasuk juga dalam kategori code generator. hanya saja untuk kasus ini, code yang dihasilkan, tidak pernah diubah-ubah lagi, dan tinggal dieksekusi. netbeans, sudah bertahun menerapkan cara seperti ini, form design aslinya selalu disimpan dalam file formatnya khusus, untuk kemudian
Re: [JUG-Indonesia] [ask] Codesmith di java
Maksud gw bukan itu... Bukan code gen bikin repetition... Tapi design EJB2 itu butuh banyak noise n repetition, makanya butuh codegen kayak xdocklet buat ease the pain. Padahal disini xdocklet sebenernya gak lebih dari quick hack buat get around the underlying problem... yaitu design API EJB2 yg ridiculously verbose, unreadable, n repetitive. Disini yg gw maksud manfaat codegen yg illusive. Emang codegen ngebantu banget daripada mesti nulis pake tangan, tapi tetep lebih baik API designnya yg dibenerin supaya gak noisy dan human friendly.. dimana lo gak butuh lagi codegen. Kayak yg dah dibenerin di ejb3. Tapi codegen juga sebenernya banyak dipake buat tujuan bener. Gw gak tau napa banyak comment yg undermining codegen di java. Padahal NHQG (NHibernate Query Generator) itu contoh codegen yg bener2 ngebantu banget di .net. Contohnya, ini query Many-To-Many di nhibernate: User usr = User.FindOne( Where.User.Name == Hendry Where.User.Roles.With().Name == Administrator ); Strong type... far better daripada HQL. Dan (di c# 2) ini cuma possible dengan code-generator buat autogenerate class Where beserta setiap subclassnya buat tiap entity (e,g, Where.User.Roles). nb: di c# 3 ini udah deprecated direplace linq 2008/12/15 sm96 syaiful.mukh...@gmail.com ini juga satu factor kelemahan yg terlalu dibesar-besarkan. padahal sebenarnya bisa-bisa saja DRY diterapkan di code generator manapun. hanya karena, developer pemakai code generator pengen cepetnya aja, sehingga gak terlalu mikirin masalah DRY. jika penggunaan code generator sudah optimal, duplikasi apa lagi yg masih harus dipermasalahkan? berarti masalah duplikasi itu yang harus diresolve di sisi code generatornya. ekstrimnya, apakah kita gak mau mengulang2 ngetik statement macam 'public class .. extends implements ' ini masuk DRY apa bukan? jelas bukan dong? tapi code generator bisa dibikin dengan menerapkan DRY didalamnya. Kalau masih ada yg menganggap code generator 'jatuh' karena 'melanggar' prinsip DRY, apa itu berarti developer2 ini gak mahir pake code generator. 2008/12/11 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: Masalahnya bukan code generator vs tanpa code generator. Tapi code generator vs code yg DRY dan low noise yg gak butuh generator at first place. Alasan xdocklet di ejb2 kan gara2 banyak butuh duplication n code noise dimana2 :( 2008/12/9 sm96 syaiful.mukh...@gmail.com syaiful.mukhlis%40gmail.com kesalahan terbesar pada penggunaan code generator adalah, setelah code digenerate, trus dimodifikasi code hasil generate tsb. padahal jika konsisten dalam penerapan cara ini, mesti code generatornya yang disempurnakan, disertai dengan konfigurasi yang disempurnakan juga. bukan berarti code generator adalah sekali generate masalah langsung beres. kalo ada masalah, code generator yg disempurnakan sedemikian rupa, sehingga pada saat generate code yg diperlukan, tidak memakan waktu yg lama. dipikirkan juga, bahwa code yg sudah digenerate juga tidak perlu digenerate ulang. pada menyadari atau tidak, proses compiler, interpreter, codeweaver, bytecode enhancer, bytecode engineering, sebenarnya ini termasuk juga dalam kategori code generator. hanya saja untuk kasus ini, code yang dihasilkan, tidak pernah diubah-ubah lagi, dan tinggal dieksekusi. netbeans, sudah bertahun menerapkan cara seperti ini, form design aslinya selalu disimpan dalam file formatnya khusus, untuk kemudian digenerate menjadi code java, dimana didalam source code tsb selalu ada pesan 'Generated Code' ditambah lagi pesan WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. 2008/12/8 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: xdocklet sempet jadi mainstream di EJB2 totally agree, ridiculously painful. 2008/12/5 Ifnu ifnub...@gmail.com ifnubima%40gmail.com Software semacam codesmith ini sepertinya tidak populer di dunia Java, kalaupun ada sepertinya juga tidak laku. Di netbeans ada Visual Web Pack, ga banyak juga yang pake, ;). Ada juga mobility pack, disana ada visual midlet, ga banyak juga yang pake. Cuma Matisse aja yang desain halaman yang banyak dipake, trus di matisse ada databinding dengan beans binding, eh banyak yang ga pake juga ;) Ini adalah nature dari aplikasi java yang kebanyakan aplikasi enterprise, dan sekaligus egoistis programmer java yang alergi dengan full code generation. Banyak yang bilang code generation itu cuma awalnya yang enak, ketika kita mau costumize, banyak juga work around yang harus dicari. Pada akhirnya sama saja, ;). -- syaiful.mukhlis gtalk:syaiful.mukh...@gmail.com syaiful.mukhlis%40gmail.com -- syaiful.mukhlis gtalk:syaiful.mukh...@gmail.com syaiful.mukhlis%40gmail.com
Re: [JUG-Indonesia] [ask] Codesmith di java
Masalahnya bukan code generator vs tanpa code generator. Tapi code generator vs code yg DRY dan low noise yg gak butuh generator at first place. Alasan xdocklet di ejb2 kan gara2 banyak butuh duplication n code noise dimana2 :( 2008/12/9 sm96 syaiful.mukh...@gmail.com kesalahan terbesar pada penggunaan code generator adalah, setelah code digenerate, trus dimodifikasi code hasil generate tsb. padahal jika konsisten dalam penerapan cara ini, mesti code generatornya yang disempurnakan, disertai dengan konfigurasi yang disempurnakan juga. bukan berarti code generator adalah sekali generate masalah langsung beres. kalo ada masalah, code generator yg disempurnakan sedemikian rupa, sehingga pada saat generate code yg diperlukan, tidak memakan waktu yg lama. dipikirkan juga, bahwa code yg sudah digenerate juga tidak perlu digenerate ulang. pada menyadari atau tidak, proses compiler, interpreter, codeweaver, bytecode enhancer, bytecode engineering, sebenarnya ini termasuk juga dalam kategori code generator. hanya saja untuk kasus ini, code yang dihasilkan, tidak pernah diubah-ubah lagi, dan tinggal dieksekusi. netbeans, sudah bertahun menerapkan cara seperti ini, form design aslinya selalu disimpan dalam file formatnya khusus, untuk kemudian digenerate menjadi code java, dimana didalam source code tsb selalu ada pesan 'Generated Code' ditambah lagi pesan WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. 2008/12/8 Hendry Luk hendrym...@gmail.com hendrymail%40gmail.com: xdocklet sempet jadi mainstream di EJB2 totally agree, ridiculously painful. 2008/12/5 Ifnu ifnub...@gmail.com ifnubima%40gmail.com Software semacam codesmith ini sepertinya tidak populer di dunia Java, kalaupun ada sepertinya juga tidak laku. Di netbeans ada Visual Web Pack, ga banyak juga yang pake, ;). Ada juga mobility pack, disana ada visual midlet, ga banyak juga yang pake. Cuma Matisse aja yang desain halaman yang banyak dipake, trus di matisse ada databinding dengan beans binding, eh banyak yang ga pake juga ;) Ini adalah nature dari aplikasi java yang kebanyakan aplikasi enterprise, dan sekaligus egoistis programmer java yang alergi dengan full code generation. Banyak yang bilang code generation itu cuma awalnya yang enak, ketika kita mau costumize, banyak juga work around yang harus dicari. Pada akhirnya sama saja, ;). -- syaiful.mukhlis gtalk:syaiful.mukh...@gmail.com syaiful.mukhlis%40gmail.com
Re: [JUG-Indonesia] [ask] Codesmith di java
kesalahan terbesar pada penggunaan code generator adalah, setelah code digenerate, trus dimodifikasi code hasil generate tsb. padahal jika konsisten dalam penerapan cara ini, mesti code generatornya yang disempurnakan, disertai dengan konfigurasi yang disempurnakan juga. bukan berarti code generator adalah sekali generate masalah langsung beres. kalo ada masalah, code generator yg disempurnakan sedemikian rupa, sehingga pada saat generate code yg diperlukan, tidak memakan waktu yg lama. dipikirkan juga, bahwa code yg sudah digenerate juga tidak perlu digenerate ulang. pada menyadari atau tidak, proses compiler, interpreter, codeweaver, bytecode enhancer, bytecode engineering, sebenarnya ini termasuk juga dalam kategori code generator. hanya saja untuk kasus ini, code yang dihasilkan, tidak pernah diubah-ubah lagi, dan tinggal dieksekusi. netbeans, sudah bertahun menerapkan cara seperti ini, form design aslinya selalu disimpan dalam file formatnya khusus, untuk kemudian digenerate menjadi code java, dimana didalam source code tsb selalu ada pesan 'Generated Code' ditambah lagi pesan WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. 2008/12/8 Hendry Luk [EMAIL PROTECTED]: xdocklet sempet jadi mainstream di EJB2 totally agree, ridiculously painful. 2008/12/5 Ifnu [EMAIL PROTECTED] Software semacam codesmith ini sepertinya tidak populer di dunia Java, kalaupun ada sepertinya juga tidak laku. Di netbeans ada Visual Web Pack, ga banyak juga yang pake, ;). Ada juga mobility pack, disana ada visual midlet, ga banyak juga yang pake. Cuma Matisse aja yang desain halaman yang banyak dipake, trus di matisse ada databinding dengan beans binding, eh banyak yang ga pake juga ;) Ini adalah nature dari aplikasi java yang kebanyakan aplikasi enterprise, dan sekaligus egoistis programmer java yang alergi dengan full code generation. Banyak yang bilang code generation itu cuma awalnya yang enak, ketika kita mau costumize, banyak juga work around yang harus dicari. Pada akhirnya sama saja, ;). -- syaiful.mukhlis gtalk:[EMAIL PROTECTED]
Re: [JUG-Indonesia] [ask] Codesmith di java
Code generation ga laku di java :D. Code generation itu cemen B-) 2008/12/9 sm96 [EMAIL PROTECTED]: kesalahan terbesar pada penggunaan code generator adalah, setelah code digenerate, trus dimodifikasi code hasil generate tsb. padahal jika konsisten dalam penerapan cara ini, mesti code generatornya yang disempurnakan, disertai dengan konfigurasi yang disempurnakan juga. bukan berarti code generator adalah sekali generate masalah langsung beres. kalo ada masalah, code generator yg disempurnakan sedemikian rupa, sehingga pada saat generate code yg diperlukan, tidak memakan waktu yg lama. dipikirkan juga, bahwa code yg sudah digenerate juga tidak perlu digenerate ulang. pada menyadari atau tidak, proses compiler, interpreter, codeweaver, bytecode enhancer, bytecode engineering, sebenarnya ini termasuk juga dalam kategori code generator. hanya saja untuk kasus ini, code yang dihasilkan, tidak pernah diubah-ubah lagi, dan tinggal dieksekusi. netbeans, sudah bertahun menerapkan cara seperti ini, form design aslinya selalu disimpan dalam file formatnya khusus, untuk kemudian digenerate menjadi code java, dimana didalam source code tsb selalu ada pesan 'Generated Code' ditambah lagi pesan WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. 2008/12/8 Hendry Luk [EMAIL PROTECTED]: xdocklet sempet jadi mainstream di EJB2 totally agree, ridiculously painful. 2008/12/5 Ifnu [EMAIL PROTECTED] Software semacam codesmith ini sepertinya tidak populer di dunia Java, kalaupun ada sepertinya juga tidak laku. Di netbeans ada Visual Web Pack, ga banyak juga yang pake, ;). Ada juga mobility pack, disana ada visual midlet, ga banyak juga yang pake. Cuma Matisse aja yang desain halaman yang banyak dipake, trus di matisse ada databinding dengan beans binding, eh banyak yang ga pake juga ;) Ini adalah nature dari aplikasi java yang kebanyakan aplikasi enterprise, dan sekaligus egoistis programmer java yang alergi dengan full code generation. Banyak yang bilang code generation itu cuma awalnya yang enak, ketika kita mau costumize, banyak juga work around yang harus dicari. Pada akhirnya sama saja, ;). -- syaiful.mukhlis gtalk:[EMAIL PROTECTED]
Re: [JUG-Indonesia] [ask] Codesmith di java
xdocklet sempet jadi mainstream di EJB2 totally agree, ridiculously painful. 2008/12/5 Ifnu [EMAIL PROTECTED] Software semacam codesmith ini sepertinya tidak populer di dunia Java, kalaupun ada sepertinya juga tidak laku. Di netbeans ada Visual Web Pack, ga banyak juga yang pake, ;). Ada juga mobility pack, disana ada visual midlet, ga banyak juga yang pake. Cuma Matisse aja yang desain halaman yang banyak dipake, trus di matisse ada databinding dengan beans binding, eh banyak yang ga pake juga ;) Ini adalah nature dari aplikasi java yang kebanyakan aplikasi enterprise, dan sekaligus egoistis programmer java yang alergi dengan full code generation. Banyak yang bilang code generation itu cuma awalnya yang enak, ketika kita mau costumize, banyak juga work around yang harus dicari. Pada akhirnya sama saja, ;).
[JUG-Indonesia] [ask] Codesmith di java
Dear All, Kalo di .net ada codesmith. Kalo di java, ada apa yah? Ampe bisa bikin form lengkap master-detail. Tx b4 -- Sent from Gmail for mobile | mobile.google.com
Re: [JUG-Indonesia] [ask] Codesmith di java
Software semacam codesmith ini sepertinya tidak populer di dunia Java, kalaupun ada sepertinya juga tidak laku. Di netbeans ada Visual Web Pack, ga banyak juga yang pake, ;). Ada juga mobility pack, disana ada visual midlet, ga banyak juga yang pake. Cuma Matisse aja yang desain halaman yang banyak dipake, trus di matisse ada databinding dengan beans binding, eh banyak yang ga pake juga ;) Ini adalah nature dari aplikasi java yang kebanyakan aplikasi enterprise, dan sekaligus egoistis programmer java yang alergi dengan full code generation. Banyak yang bilang code generation itu cuma awalnya yang enak, ketika kita mau costumize, banyak juga work around yang harus dicari. Pada akhirnya sama saja, ;).
