Raible Designs

The Flight to Amsterdam

Tomorrow morning, my dad, Bruce and I will be getting on a Continental flight headed for Amsterdam. We stop in Houston for a couple hours, then it's a 10-hour flight from there. Bruce found a diagram of our plane and it appears to have power outlets. Inspired by this news, I went out and bought an adapter for my MacBook Pro.

Now the question is - where there be enough room for my 17" laptop?

The last flight I was on (to Boston a few weeks ago), there was no room for a laptop. When the guy leaned back in front of me, I ended up with barely enough room to scratch my nose. A 15" laptop wouldn't have solved that problem. Has anyone out there flown internationally in a Boeing 767? We're in economy, so it might be tight, but I would like to get some work done on the flight. I'm willing to take both my MacBooks, but it would suck if I couldn't use either one. On the other hand, it'd be nice if I knew my 17" would work fine and I only had to take one. Thanks for any advice.

Update: The adventure/drama has already begun! My dad forgot his passport in Oregon and we've been on the phone with Fedex and UPS trying to get it here before our flight takes off at 11:20. Fedex was $384 for a "it should get there" delivery. UPS gave us a "guaranteed delivery" for $75 and told us it would get here by 9. Once they gave us the tracking number, they switched it to 10. Those bastards! Oh well, at least I'm on the flight - who knows about my dad.

Saturday @ 7 AM: UPS Tracking shows his passport is in Ontario, Canada (an arrival scan, no departure shown). WTF - the two hour flight from Portland to Denver wasn't short enough?!

Saturday @ 9 AM: Julie has the passport in her hands and is driving out to the airport to give it to my dad. He came with me an hour ago to check in and explain his situation. Looks like he's going to make it!

Ant vs. Maven

I found a good post from Steve Loughran on what's wrong with Maven's repositories. I agree with most of his points, but would like to point out mvnrepository.com. This site seems to provide good XML Feeds for what's been uploaded to Maven's Central Repository. If you're using Maven, you should probably subscribe to its Atom Feed.

In related news, Timothy M. O'Brien has an entry about Steve's upcoming book: Ant in Action. This book is the 2nd edition of Java Development with Ant. I have a hard time believing Erik Hatcher is helping Steve write Ant in Action - AFAIK, he's off in Rails-land enjoying himself. Regardless, I'm sure Ant in Action will be an excellent book. Java Development with Ant is one of my favorite technical books of all time and is largely responsible for inspiring me to write AppFuse. I read JDwA way back in October 2002 and used a lot of its code to develop AppFuse 1.x's Ant-based build system.

Like Tim, I still like Ant. However, AppFuse 2.x uses Maven 2 and most of the projects I work on these days use Maven 2. It may surprise some folks, but I actually like Maven 2 (not Maven 1). Sure it has issues, but after a year of using it in anger, I know how to solve most of its quirks. AppFuse 2.x users will benefit from this greatly and I'm thinking of changing its tagline to "We make Maven work."

One of the most interesting things about moving to Maven is we were easily able to make AppFuse more like a framework than a project starter kit. We thought this is what most folks wanted - especially the ability to upgrade a project to the latest version of AppFuse. While some folks wanted this, it seems like most folks liked the full-source version that was a pain-in-the-ass to upgrade. I don't blame them. On the project I'm on, I'll likely be converting to a full-source version before the project is over. That's why APF-675 exists. I doubt we'll make it happen for the 2.0 final release, but it is on our radar of things to do shortly after. With any luck, we'll create a way to migrate projects using embedded AppFuse to full-source AppFuse.

I'd also like to point out something ironic. With AppFuse 1.x, there were a lot of folks that advocated we move to Maven. Their primary reasoning - the Ant build scripts were too long and complicated. How about a good ol' lines of XML comparison for those folks:

• Lines of Ant-related XML in AppFuse 1.x: 1655
• Lines of Maven-related XML in AppFuse 2.x: 2847

Oh wait, that's not a fair comparison. The above number is for AppFuse in SVN, which end users won't deal with. A new project created with AppFuse 2.x will likely have a pom.xml with 634 lines. That's about 1/3 of the amount needed for Ant in AppFuse 1.x. Maven hasn't exactly gotten us away from XML hell though. How about a LOC count for archetypes vs. installers:

• Lines of Ant-related XML for AppFuse 1.x framework installers: 2786
• Lines of Maven-related XML for AppFuse 2.x archetypes (including archetype's pom.xml files): Too much to count. Creating archetypes is waayyyy too complicated IMO. Basic archetypes seem to be around 740 lines (pom.xml for archetype project, archetype.xml and archetype's pom.xml), modular archetypes are around 870. 740 x 4 + 870 x 4 = 6440. I'm guessing the full-source archetypes will add another 5000 lines of XML. Ugh.

This XML-for-archetypes comparison might be unfair as well. With 1.x, you could only create a webapp, with 2.x, you can create a modular application and chop off the web-portion if you so choose.

Of course, the real benefits of moving to Maven are elsewhere. We've seen quite an uptick on the mailing list in the last few months. There's tools cropping up and I've gotten quite a few inquiries about training (yes, I do have a 3-day course on Spring, Hibernate, Ajax, Maven and AppFuse). To me, AppFuse 2.x seems more complicated than 1.x, but it seems the community thinks otherwise. Judging from the increased amount of developer activity on the project, developers seem more interested in a Maven-based system too. Then again, we are making Maven work!

Bandwidth Speed Issues

In the last few days, I started to notice a huge slowdown on my MacBook Pro when surfing the net. At first, it seemed to be a Firefox-hogging-a-shitload-of-memory issue. So I started using Safari instead. After a few hours of using Safari, the problem came back and pages were taking 5-6 seconds to load. I have a Cable (Comcast) modem, so I didn't suspect any bandwidth issues.

Last night, I got tired of waiting and decided to do some further investigation. I started off by running several bandwidth speed tests. All of them reported similar statistics: download speeds of under 300K/sec. I called Comcast, they ran some tests and determined that there were no package loss issues between my modem and their facilities.

Since I moved my modem downstairs last year, I tried moving it upstairs. Same result. I tried plugging it directly into my desktop and voila! - 3MB/sec. I have 2 NetGear routers setup (one for each laptop since my MacBook Pro's wireless abilities suck) and it seems like they are the source of the problem. Do routers go bad like this?

I'm considering buying an Airport Extreme to solve all my Mac-related wireless issues. Unfortunately, it only has 3 ethernet ports and I'd prefer a lot more.

[TSE] Spring-OSGI with Adrian Colyer

One of the first questions people ask about OSGi is "what the heck is it?"

Most people don't even know what it is. OSGi stands for Open Services Gateway initiative. From the very beginning, it was designed to be lightweight and dynamic. This is the major difference between it and other containers. It's always been designed to have things added and removed. Now it's tagline is: "The Dynamic Module System for Java".

It's designed to allow you to partition a system into a number of modules (a.k.a. bundles). There's strict visibility rules (similar to protected and private). There's a resolution process (dependencies are satisfied) and it understands versioning.

It's dynamic! Modules can be installed, started, stopped, uninstalled and updated - all at runtime.[Read More]

RE: Five things I hate about AppFuse

Karsten Voges has written a nice critique of AppFuse titled Five things I hate about AppFuse. I started a new JSF+Hibernate project with AppFuse yesterday, so I definitely feel some of his pain. Let's examine his points one-by-one:

1. It's nice to choose between the usage of JSP 2.0 or before, but making the changes (to all jsps and the web.xml) every time I build my app sucks.

I absolutely agree. I spent a good hour modifying build.xml, web.xml, etc. to switch my app from JSP 1.2 to JSP 2.0 yesterday. You can modify your build.xml to permanently switch to JSP 2.0, but it doesn't get everything. I'll create a separate script for 1.9.3 and the upcoming 1.9.4 to make this cleaner.

2. Seperating the classes in web, services and dao is good, but I hate the building of jar-Files for the different layers. Just take the classes under dao and service and copy them into the war or move them over to the webapps folder as it is done with the web classes!

Yeah, I've proposed doing this a couple of times on the user mailing list. It always gets shot down by existing users. I'm sure it'd be possible to write a script to do this, but it'd be no fun to write.

3. Eclipse crashed with OutOfMemory errors. Always when trying to open the build file. The build file is really, really long, with lots of stuff in there. IMO 50% of it could be deleted.

Hmmm, I rarely have OOM errors with Eclipse, but I also used Bruce's tip for increasing Eclipse's available memory. If you're using Windows, here's how to bump up Eclipse's memory.

4. Generation of Hibernate-Mapping files. I really hate it to look within a jarfile how the Hibernate mapping file looks like. It is nice to get it generated, but I prefer to be able make adjustments to it by hand to try out things quickly. And it is quite hard to enter special SQL statements in an Hibernate file, if it gets overwritten all the time.

You can create/modify the Hibernate mapping files by hand if you prefer. From the FAQ:

If you have an @hibernate.class tag on a POJO - hibernatedoclet will generate the mapping file into build/dao/gen. If you have a mapping file (*.hbm.xml) file for your POJO in the src/dao/**/model/* directory, it will overwrite the generated version. If you don't want to worry about the two conflicting - just remove the @ sign from @hibernate.class in your POJO and put your hbm.xml file in the model directory.

No build.xml modification are need for this to work. The "package-dao" target will include these mapping files. If you want to get rid of the hibernatedoclet process, you can do that- but make sure and run it first - and then copy all of the generated hbm.xml files into your model directory.

5. I don't like to get my struts.xml merged from many sources. I like to have one struts-config file holding all my struts configuration.

I agree this is kinda painful, but so is developing with Struts. You should be able to move the generated struts-config.xml into web/WEB-INF and remove the <strutsconfigxml> from build.xml to get the behavior you're looking for.

As far as throwing out the build.xml, I'm actually planning on doing that with my current project. I will keep it in place for the development phase, but I hope to move the application into a large build system once I'm done. Since it's all Java code and XML in the end, this shouldn't be hard to do. I did it when migrating to Maven 2, so I know it's possible. As far as Karsten's opinion of Maven 2, he may be right - but I hope to make a strong effort to make it very useable when using AppFuse. In fact, I hope to make it possible for users to use their IDE their entire time, with no need to run any Maven commands. Of course, that could be a pipe dream - only time will tell.

As far as sounding like the BileBlog, the more you rag on AppFuse, the better. Remember, screaming users are a good thing.

A device-free weekend

This weekend, I did something I haven't done in a while (if ever). I left my laptop at work, and I promised myself to not touch a keyboard all weekend. When my phone's battery died on Saturday morning, and I realized I'd left my charger at work, I decided to go no-devices all the way. Of course, I still watched TV and enjoyed my car stereo, but being computer-free felt liberating. It was an awesome weekend, and I'm thinking about doing it from now on.

Saturday, Julie and I had a great time watching Superman, IMAX, in 3D. It was killer. The whole movie wasn't 3D, but the 4 scenes in 3D were incredible. I highly recommend it. On Sunday, we had kickass seats to The International thanks to Virtuas. We sat on the 18th hole and watched golf while getting free cocktails served to us for several hours. It didn't suck by any means.

Driving to OSCON: Day 2

This morning, Jim and I slept in a bit and hit the road around 11. The time zone changed on us after an hour and all of a sudden, we were destined for Portland in good time. It was an enjoyable drive through the Columbia Gorge with some beautiful scenery.

We arrived in Portland around 4:15 p.m. and checked into our hotel across the street from the Oregon Convention Center. It didn't take us long to realize the wireless sucked (b/c it's trying to suck off the free wireless next door).

We hopped on "the Max" and headed into downtown Portland. We found the local Rock Bottom Brewery, found out they didn't have wireless, and ended up at Jax Bar. They have free wireless and cold Guinness. You couldn't ask for much more.

DC Tech Meetup

Anyone out there still interested in a DC-Area tech meetup tomorrow night? If so, are there any good places near Tyson's Corner? We'd love to return to Brickskeller, but it'd be nice to avoid the 1.5 hour commute to get there. It's not that far, but traffic is something else around here.

Update: Vienna Inn (map) is the location - we'll be there around 8:00.

Buildix - CruiseControl, Trac and Subversion for VMWare

From the CruiseControl mailing list a few minutes ago:

Just passing on the info... this is one of those projects I also wanted/intended to do. I'm glad someone beat me to it!

http://buildix.thoughtworks.com

It includes CruiseControl, Trac, Subversion all on a single live cd or vm ware image. Very nice!

After installing Ubuntu on VMWare server last weekend, I was getting ready to create something similar to this. I'm glad I saw this as it seems to be a much more complete package than the one I was going to create. I'd prefer Ubuntu over Debian/KNOPPIX, but since Ubuntu is based on Debian, it probably doesn't matter.

A couple additions I'd like to see are Maven 1, 2 and Continuum pre-installed. I doubt that'll happen though since CruiseControl is a Thoughtworks-sponsored project. Regardless, if I had a Buildix with those options, I'd likely use (and recommend) it for every future project. A lot of clients already have bug tracking and source control installed, so the build server is the main thing that interests me.

RE: What Web Application framework should you use?

Tim O'Brien has an interesting post titled What Web Application framework should you use?. The first thing I noticed about this post is the permalink. It looks like he started with "Isn't Rails supposed to change...", which makes me wonder what the rest of the title was. In this post, he rags on Java Web Frameworks and the lack of a clear path for choosing one. He ends up predicting that many will stick with Struts 1.x (poor bastards) and those that aren't tied to Java should move to Rails. I don't have a problem with folks moving to Rails, but I would like to comment on the Java Web Framework space and Tim's comments.

He says:

Prediction: The confusion over what is happening over at Struts is going to discourage people from continuing to use it. The Struts team did the right thing in recognizing that Struts 1.x was a dead-end, but that project needs a single public message. Is it Struts Action or is it Struts Faces? Or is it two frameworks capitalizing on the Struts brand name?

I think what is going on in the Struts project is definitely two frameworks capitalizing on a brand name. That was a concious choice on the project's part when they chose to start creating sub-projects. The interesting thing about Struts Shale is it's largely a prototype for JSF 2.0. Furthermore, it was rejected by many Struts developers as becoming Struts 2.0. Why? Because JSF sucks. Especially when used with JSP - which is what most folks are doing.

JSF continues to be the most over-hyped under-used framework in Javaland. If you read the blogs of first-time users, you'll find many complaints and issues on how things work. Granted, most of these problems are with JSP and the implementation, but still. If I were in charge of JSF, I'd dump JSP altogether, bundle Facelets with it and allow more flexible page navigation (including controller-to-page). Don't get me wrong, I like the ideas behind JSF, I just don't like the implementation (or the fact I have to wait years for things to be fixed in the spec).

That being said, I've yet to meet an unhappy WebWork fan. If you find someone that still likes Struts, ask them if they've used WebWork. Chances are they'll say no. As far as Tapestry is concerned, the learning curve is too high. It's been rejected time and time again by my clients because of the learning curve. Are they going to fix this? Yep, they're going to re-write the whole damn thing - again! Every major point release of Tapestry throws backwards-compatibility out the window. Furthermore, I've heard once you get over the learning curve, it's a joy to work with. I've also met people at conferences that've used it over a year and say they're still struggling with its concepts.

Spring MVC - I wish I had bad things to say about it, but I don't. It (obviously) has the best Spring integration, but I've found WebWork much more pleasurable to work with. Sure, Spring has a ThrowawayController, but with a name like that, you can tell it's a second-class citizen.

Inspired by Tim's post, here's my prediction:

Struts Action 2 will be the best choice for developing Java-based web frameworks. Not only does it support JSF, but it's easy to learn, test and use. Furthermore, it seems to be the most often used framework in major software products and web sites.

How's that for a clear message? Struts Action 2 is the shiznit, now let's get back to developing applications.

Disclaimer: This is my opinion with a lot of stuff thrown in to get folks riled up. I've never put a JSF, Tapestry or Spring MVC application into production (except for AppFuse of course), so most of my opinions are likely without foundation. In wonder how many applications Mr. O'Brien has put into production with these frameworks?