Todd Huss

Thanks to Jeremy’s blog I discovered the MC Hawking CD. I’ve been listening to it for a few days and if you’re a rap loving nerd, this CD is for you! Don’t miss the flash movie.

Mike Clark made this short quicktime video on continuous integration with Cruise Control. I love these kinds of videos (similar to the Ruby on Rails video) and would like to see more of them.

At my company we have 50+ MySQL databases on one server that have the same schema for the purpose of partitioning data (due to the size of each database). The decision goes back before my time and of course there is a tremendous amount of spaghetti infrastructure (web, batch processing, cron scripts, reporting, etc…) relying upon this arrangement. The data is state specific so for the purpose of this discussion we'll say all schemas are identical. If I need California data I can connect to that database and look it up the same way I would look it up in say the Maine database. One handy feature in MySQL is that I can get a connection to any database on the server and then access data in another database via that connection. For example I can connect to the Ohio database and then select * from florida.sometable;. You'll see why this is possibly handy in my discussion about iBatis below.

In moving our company from Perl to Java one of the main challenges for me has been sorting out our approach to the ORM layer. I'm using Hibernate on the unique databases that have unique tables. However, I'm struggling to find an elegant way to work with Hibernate to have one class map to tables in 50+ different databases and have come up with the following possibilities (that I still need to test) listed in order of my perceived level of simplicity:

1. Use iBatis for these multi-database tables and have Spring maintain 1 database connection and use variable substitution as part of the SQL map statements: select * from #databasename#.table. This approach seems simple and promising on the surface. Downside is programmers will need to know two ORM packages and it takes a little longer to write a DAO/POJO combo in iBatis than Hibernate (at least for me).
2. Use Hibernate and have Spring maintain the 50+ hibernate session factories and the 50+ datasources. I would then have Spring dependency inject a class that allows the DAO to fetch the appropriate hibernate session factory.
3. Use JDBC and have Spring maintain 1 database connection. Then I would use select * from databasename.tablename and then manually do the ResultSet to POJO mapping.
4. Put the company on hold and have engineering focus for a few months on refactoring the 50 databases down to one that support partitioning and refactor the legacy web, batch processing, and reporting systems. This one I feel is a little too costly and risky since I can't think of a way to take an iterative approach due to the number of systems involved.

If you have ideas please chime in!

I’ve had the same @iname email address for about 8 years now. I’ve been using Mail.com’s Iname forwarding service to forward to wherever I’m keeping my mail (usually on a Linux box I host) so that whenever I want to move my actual email account somewhere else I can. However, every year the iname forwarding service seems to get a little worse with numerous outages. Considering Go Daddy offers domains for around 8 bucks a year which includes mail forwarding I decided to make the switch.

Here’s my new completely convoluted setup which I’m trying out instead of iname coupled with SpamAssassin on my linux box (which just hasn’t been cutting it for me as a spam filter, perhaps I don’t have it configured correctly):

I have my new Go Daddy registered domain forward email to my GMail account. My GMail account spam filters and then forwards to my linux box (an address I don’t give out so I can change it when I need to). On the Linux box I use Pine, IMP, or IMAP to read my mail, respond, and compose messages with the From header set to my GoDaddy registered domain.

The main reason I did all of this is so my email address will never need to change again. I thought that was going to be the case when I went with iname but alas vendor lock-in is often problematic over the long haul. With complete control over my mail setup and how I forward it, spam filter it, etc… I’m optimistic that I can happily go about using my new email address for the foreseeable future.

I've finally completed a project that I've been thinking/scheming over for a couple of years. The java based Marine Wireless NMEA Navigation Server. Right up there with software engineering, my other really big passion is boats. I love sailing and Susan and I own a 38 foot cutter named Sugata. Most boats transfer navigation data (wind speed/direction, boat speed/course, GPS, autopilot, etc…) about via serial cable using the NMEA protocol. Typically this limits you to having one laptop connected to all of your instruments in one place. I started thinking it would be cool to make the data available wirelessly so that any number of handhelds or laptops could access the data on a boat. This becomes more important as you get into larger and larger boats.

I needed a small 12 volt driven wireless access point with a serial connector (to connect to the NMEA devices). After a lot of searching I finally decided to use a Soekris board with 32MB ram and Pebble Linux running on a 256MB CF card (read-only) with a 200mW 802.11 transmitter with an external antenna. With 32MB ram I originally wrote the NMEA multiplexing/server software in J2ME but finally decided to try J2SE with a very low (16MB) max memory setting and sure enough it worked fine even under full NMEA data loads (which are admitedly pretty low). Then I needed a web interface to allow users to configure the wireless navigation server so they could easily change the administrator password, SID, encryption, download the system log to send me for debugging, and so on. For that I opted for Perl using FastTemplate (mainly because I was lazy and it could easily run in the remaining 12MB or so) running inside the tiny busy box http server. After I had the web interface mostly complete I also needed a way for users to upgrade the firmware/CF card (when I released new versions or fixed bugs). This is where you just have to love all of the Unix tools available. I was able to write the firmware upgrade portion in a couple of hours using familiar tools like md5, tar, bzip2, and mount (to remount the CF card read-write).

After I had the device built, working, and tested I put out the word for some beta boats to try it out on. The response was excellent with far more boats interested than I could afford hardware for. I got interested responses from commercial fisherman, racing sailboats, and many many trawlers. Having something work in the lab (my living room) is always completely different from reality as I soon discovered. There were a lot of bugs to fix and usability issues to address to get it working. I'm sure there's still a lot of work needed since it's only been tested out in a handful of configurations.

One company starting around the same time I started this project was Rose Point Nav. They make commercial navigation software and they added direct network support to their software to make it really easy to interface their software with my wireless navigation server which was pretty cool of them.

The biggest challenge in the whole process for me has been motivation (since I have a full-time job) and writing the manual. It's difficult to make installing/configuring a device like this easy for the novice. Heck, companies like LinkSys have whole teams developing their products and manuals and many people still run into problems. I received help from friends and a business partner on the manual but writing the software was basically a solo effort. I'm going to start out by selling my wireless NMEA navigation server directly on the web (using the open-source osCommerce platform). If it doesn't really take off I plan to open-source the software so other people can build their own wireless navigation servers. Either way, it's been an interesting and exciting experience!

In learning Maven over the weekend I set about the process of creating a Maven Data Access Kickstart project (with Spring, Hibernate, JUnit, DBUnit, and XDoclet). Here's my Mavenized data access kickstart project if you're interested: maven-dao-kickstart-0.1.tgz

One of the main projects I'm working on now will involve a data access/business logic project and a separate web interface project which will depend on the data acess/business logic project. With that in mind I used Maven to implement the above kickstart project. I borrowed some code from AppFuse as well as some of the hibernate/dbunit configuration from Rick Hightower's fine blog.

Matt Raible really pioneered the concept of a java kickstart project (AFAIK) with the introduction of AppFuse which is the most comprehensive java web kickstart project I know of. I would love to see a repository of java kickstart projects!

Update: I've started working with maven multiproject and I'm totally sold! I'm already excited about the time savings with the plugins and managing dependencies.

I set aside some time this weekend to learn Maven which I continue to hear a lot about and until this weekend knew very little about. I was definitely impressed, I'll be hard pressed to go back to using Ant after seeing the power of Maven. I got started with this article from the TheServerSide.com: Maven Magic.

After working with it a bit, the main areas I hope Maven will improve over time are:

• Documentation, primarily better docs for the plugins.
• A downloadable version with binaries and docs. Since I learned it where I only had a dialup connection I found it frustrating to have to dialup everytime I wanted to look for some basic information.
• Some packages on ibiblio are out of date so I had to use my local repository.

The things I really like about it are:

• Dependency management, amazing!
• Plugins plugins plugins plugins!
• Sensible build defaults for most types of projects.
• Great Ant integration and support if I need more control over the build process.
• Nice reporting system for continuous integration build processes.

Here was my one road block while learning Maven. I was missing a jar that one of unit tests required at runtime and here's the output I got when running maven -X test:

BUILD FAILED
File...... C:\Documents and Settings\thuss\.maven\cache
\maven-test-plugin-1.6.2\
plugin.jelly
Element... junit
Line...... 133
Column.... 41
java.lang.NoClassDefFoundError
com.werken.werkz.UnattainableGoalException: Unable to
obtain goal [test:test] -- C:\Documents and Settings
\thuss\.maven\cache\maven-test-plugin-1.6.2\
plugin.jelly:133:41:  java.lang.NoClassDefFoundError
        at com.werken.werkz.Goal.fire(Goal.java:646)
 	...

Any idea what class is missing based on the above? Me neither! I spent almost an hour searching forums and tearing my hair out until I finally tried setting the property maven.junit.fork=true in my project.properties file. Then JUnits log messages started to show on STDOUT so I could see that I had forgotten the hibernate jar in my dependencies (which was only a runtime dependency since I'm using the spring-orm support). Anyhow, there's probably a maven parameter I could set to show logging messages while running the test goal but I couldn't find it and maven -X was no help. One of the main goals of TDD is that the build process and unit tests will tell you what's broken so you can refactor with confidence. Kind of ironic that one of my unit tests was simply missing a runtime dependency and maven couldn't give me a better error message.

That minor frustration aside, Maven is a great tool!

On a very long flight to Germany and back I started digging into Howard Lewis Ship's book Tapestry in Action. I am very impressed with Tapestry so far. It does have a fairly steep learning curve compared to your more typical request/response frameworks such as Struts and Spring MVC. I attribute this to two main points:

1. 1. Tapestry uses more of an event driven programming style rather than the more familiar web style request response which makes the overall programming model closer to regular GUI programming. The tough part for me as a web programmer is that I tend to think more in terms of request response so this required a bit of a shift in the way I think when develping with Tapestry. I'm told JSF is similar in this regard.
2. 2. Tapestry uses its own templating language (which reminds me a bit of Enhydra's XMLC). I really like it because it's non-invasive unlike JSP. Once you've worked with one templating language for a while though (in my case JSP) switching to a new one takes time.

People tend to evaluate MVC frameworks (and software in general) based on what is easiest to get up and running with the fastest. I'm not convinced this is a sound approach though. It may be fine when your developing a simple page for a personal website. However, once you throw in a lot of complex requirements such as internationalization, complex client and server side validation, cobranding, etc… the framework that solves the complex requirements in the simplest and most elegant manner is going to be more cost effective in the long run, even if the up-front learning curve is steeper.

Things I'd like to see in Tapestry are resources that can be shared among pages and cleaner search engine friendly URL's (although that's a general gripe I have with the servlet spec as well). I don't think URL's are a showstopper though since on a real project I would probably just use Apache to transform a search engine friendly url like http://x.com/product/id/1234 to http://x.com/product?id=1234 for the servlet container.

With regards to the book I think Howard does a good job overall. The hangman sample application was interesting and illustrates Tapestry's elegance and power, however, I breezed through it to get to form handling since that's more relevant to the type of work I do. In summary, with very clean non-invasive templating, a nice per page XML file, graceful form handling and validation, internationalization, etc… Tapestry is definitely in the running for me as my MVC framework of choice. I now just need to get more real-world implementation experience with it.