Rails Lessons Applied to Java
With both Ruby on Rails and Java having reached the Koolaid Point a long time ago detractors on both sides are taking pop shots at each other. Comments from both side can get pretty childish at times which I'm sure doesn't help the average IT professional when they are trying to decide on the best way to approach a project.
Anyway, Bill Venners and Bruce Tate are both trying and peel back the layers and help us understand these things better. I suggest Java developers read the two articles they have written recently (links above) to get a better understanding. Whether it is code generation or how Rails deals with the persistence layer the framework has hit on something of value. I for one am trying to take a deeper dive to figure it out so I can become better at what it is I do as an IT professional. Name-calling doesn't pay the bills.
March 26th, 2006 at 11:14 am
With Apache Torque http://db.apache.org/torque/ and code generation using XDoclet it is easy to achieve RoR like easiness in persistence layer.
March 26th, 2006 at 7:02 pm
Thanks Nano.
Apache’s Torque project is not something I’ve used before. I’ll check it out soon.
I’ve have been using XDoclet with Hibernate a lot latley. After setting up my annotations in my JavaBeans it takes care of all the Hibernate mappings and generating the database schema. I haven’t had to touch any SQl in the past six weeks and that is fine with me. It is not as easy as RoR but it beats the hell out of using JDBC.
March 27th, 2006 at 8:17 am
“Koolaid Point” was well used… Kathy Sierra’s basic premise of “Creating Passionate Users” (http://headrush.typepad.com/) has a wide degree of applicability for an entrepreneur ;)
April 27th, 2007 at 6:30 am
I think programmers often don’t like code generators that come from the outside, because like any framework they will often only take you 90% of the way you need to go. After that you start fighting the framework, which in a code generator often means you want to tweak the generated code. But that usually defeats the purpose of the code generator, which is to give you huge leverage. An exception are things like the scaffold generation in Rails, which is intended to just be a quick start that you edit and carry forward. Our in-house code generators are the kind where we aren’t supposed to touch the generated code, and we solve the 90% problem because when we need to change the generated code, we change the code generator (since we wrote it, we can change it). Read more about the subject : http://www.thesanfrancisconewsblog.com
April 27th, 2007 at 4:23 pm
It seems that Rails has highlighted a very real problem with Java frameworks in general – and I’m speaking from bitter experience – that when a choice between ease of use and flexibility is presented, Java framework developers have tended to choose flexibility. With Rails the developers have done the opposite, to a relatively extreme degree, and it’s working. Good to see that some in the Java world are responding positively!