breddy.net

I finally got a little time last night to check out Ruby on Rails. I have been hearing the hype now for over a year and I was pretty certain it would live up, and I’m here to tell you that it does. As a J2EE developer I respect OO design and and well thought-out conventions. Ruby embraces both and delivers a slick little setup that lets you get a data-connected webapp running in minutes.

The nice part is that with one install, you get the Ruby language along with Gems, the package manager. Gems works a lot like Yum does for linux, and with one gem command, you get the complete rails package, including a little webserver called WEBrick. RoR passes the 10-minute test with flying colors.

I followed along with one of the recommended tutorials before I hit the sack, and I found myself lying in bed running through use cases for my new score. Damn I’m a geek.

Most seasoned Struts developers I know (myself included) are masters of the html:* tags, using and extending them liberally in just about every web application they design. Spring MVC has been on the forefront of challengers to Struts, and with its sensible design, endless flexibility and excellent documentation, it isn’t difficult to see why. But Spring’s MVC left the building of HTML form controls up to the developer and his own devices. This was a big issue for me and the one that has kept me from rapidly adopting the system for use in my own apps.

In their 2.0 release the Spring team has given the community its wish, and provided a JSP form tag library. It’s been added to the manual, but here’s a key term that might pique your interest: convention over configuration.

The Spring crew has taken lessons learned from the wildfire of support for Ruby on Rails and employed them in their J2EE kit. Bravo. Time (and other ‘me-too’ projects) will tell if this is really what J2EE needs to stay on return to the cutting edge.

As a Struts user since 1.x, I finally decided to come out of my Jarkarta shell and test the Spring waters. I’ve been using Spring in the middle tier for a year or so now and could not be happier. I’ve had only a small taste so far, but here are my initial thoughts:

Good

• Designed from the ground up using good OO principles - Rod & crew really have this part mastered
• Amazingly flexible - many concrete classes are provided for each bit of functionality so that you never get more than you need
• Transparently woven-in with Spring - less glue code

Bad

• Lack of rich HTML component library - just doesn’t cut it when you’re used to having forms and select boxes built for you. Apparently this is addressed in 2.0M3 which makes a new Form tag library available, but I didn’t see any reference to this in the docs.

More to come as I work with it.

I just spent a day or two wrestling with text resources sent to us by a Korean affiliate. They are bits of data that must be displayed via the browser in Korean. The process I use is outlined in the remainder of this post.
(more…)

While I was putting together my best of the web page, I realized that a lot of the sites that came to mind were purely technical, and of very little use to the motley assortment of folks who might peruse my site. Those links needed to go somewhere, so I’ve added a first draft of my Technical Favorites. Enjoy!

Tomcat’s Deployer can be a blessing and/or a curse. The documtation is lacking and some configurations don’t play nice with WAR files that are installed or deployed with the deployer tasks.

The particular issue I’m addressing here is the use of JNDI resources. If you expect to have environment-agnositc JNDI resources in a context fragment and still use the deployer, you are out of luck. But there is a solution.
(more…)

If you’ve ever asked, “do you know where there’s a list of all the Java Virtual Machine startup parameters”, this is your lucky day. Sun’s Joseph D. Mocker has bequeathed this list upon us.