Raible Designs

Bye Bye Dream Machine

This evening, I'm shipping back one of my favorite machines of all time. I received a fully-loaded Mac Pro as part of my employment with LinkedIn last June. It was necessary to run the LinkedIn application locally and I thoroughly enjoyed using it for the last 6 months. With 12GB of RAM and two 23" monitors, it was a great employee perk.

When I became a contractor again, they let me take my dream machine home. I promptly plugged in my 30" monitor and I've been loving my home work environment ever since. I could have bought the machine from LinkedIn, but I discovered I can buy a brand new machine with similar specs for less than their asking price.

The good news is I'm now able to answer the question I asked a couple years ago: One 30" monitor or two 23" monitors? IMO, one 30" monitor is definitely better and two 30" monitors would be awesome.

In addition to the Mac Pro, I'll also be shipping back the 15" MacBook Pro they gave me. This leaves me with my 17" MacBook Pro and an old HP Pavilion with Windows XP. I was hoping to plug my 30" into the HP, but I discovered I don't have a DVI card that will handle it. Over the next few months, I do plan on buying a new MacBook Pro (for work) and a Mac Pro (for home). With my running commute, I need to leave one machine downtown and I like to have one at home for the kids + late night hacking.

I'm currently having a hard time deciding if I should buy a MacBook Pro now or make do with what I have and just buy a new DVI card for my Windows box. I'm leaning towards a new 15" MacBook Pro (17" is too big to travel with). If I could get one with a 256GB SSD, I'd definitely be sold.

What would you do?

Moving from Spring's XML to Annotations in AppFuse

Last night, I did a spike on AppFuse to change XML to Spring annotations (@Repository, @Service and @Autowired) in its service and data modules. While I was able to accomplish everything in a few hours (including converting tests), I did run into a couple issues.

AbstractTransactionalJUnit4..Tests vs. AbstractTransactionalDataSource..Tests
I've switched from my favorite Spring class to the annotation-happy AbstractTransactionalJUnit4SpringContextTests. However, this has presented an issue: when using ATDSSCT, I was able to call endTransaction() and startNewTransaction(). With ATJ4SCT, this doesn't seem possible. Below is a screenshot of the diff on a test method in the JPA implementation of UserDaoTest:

On the right, you'll notice that I had to comment out @ExpectedException to get the test to pass. This concerns me since this exception should be thrown. Is there a way to call endTransaction() and startNewTransaction() when subclassing AbstractTransactionalJUnit4SpringContextTests?

Instantiating GenericDao Implementations Programmatically
The second feature I tried to add is the ability to instantiate a GenericDao programatically rather than requiring a XML bean definition. In current versions of AppFuse, you can use the following bean definition to create a GenericDao for a model object.

<bean id="personDao" class="org.appfuse.dao.hibernate.GenericDaoHibernate">
    <constructor-arg value="org.appfuse.tutorial.model.Person"/> 
    <property name="sessionFactory" ref="sessionFactory"/>
</bean> 

When moving to a no-XML required architecture, it'd be nice to allow users to create GenericDao's programmatically. Below is the easiest way I've found to do this in a test:

GenericDao<User, Long> genericDao;
@Autowired
SessionFactory sessionFactory;

@Before
public void setUp() {
    genericDao = new GenericDaoHibernate<User, Long>(User.class);
    genericDao.setSessionFactory(sessionFactory);
}

However, there's a couple problems with this. First of all, mixing constructor injection and setter injection probably isn't a good idea. Changing the constructor to take a SessionFactory solves this problem, but now all subclasses need to have a more verbose constructor:

@Autowired
public UserDaoHibernate(SessionFactory sessionFactory) {
    super(User.class, sessionFactory);
}

Whereas before they had:

public UserDaoHibernate() {
    super(User.class);
}

In an ideal world, I could call new GenericDaoHibernate<User, Long>(User.class) and the SessionFactory would be wired in auto-magically. Is this possible with Spring 2.5?

The 2nd problem this presents is your client code will now be dependent on an implementation rather than the interface. I don't know how to solve that one, but I'd love to figure out a way to create GenericDaos with no XML and no implementation details in the client. Any ideas are most welcome.

If you'd like to see all the changes I made in converting from XML to Annotations, please see this patch.

RESTful Web Applications with Subbu Allamaraju

Subbu works at Yahoo! developing standards, patterns and practices for HTTP web languages. In the past, he was a web service and Java developer. He was also a standards contributor at BEA and an author of books on Java EE. His current passion is HTTP and REST. Subbu confesses that he's not a web developer, has no interest in the internals of programming models used for web frameworks and he's only interested in the visible aspects of the architecture.

"The Web is Mostly Restful"

Being RESTful in an abstract sense means:

• Resources are named by URIs
• Resources have representations (Atom, HTML, JSON, XML)
• Resources contain contextual links to allow navigation of state
• There's a Uniform Interface

In the web today, some resources and URIs are personalized, but most are not. Some depend on sessions, but most do not. The consequence of a personalized UI with a non-unique URI is you cannot rely on browser caching.

The web is full of different representations (HTML, XML, JS, PDF, CSS, Flash). The problem with HTML is you can't tell links that you want a particular representation based of a link. The links are hard-coded to be a particular content-type. However, some media types on responses are ignored. This is often a problem with browsers and whether the user has plugins installed.

The Uniform Interface for the web is HTML and primarily links and forms (GET and POST). There's still some misconceptions (e.g. POST is secure). However, it's not about security, it's about idempotency and safety. You need to make sure you only use POST when you're changing data. POSTs are not repeatable. GET URIs are not always refreshable, which is quite unfortunate. Users shouldn't have to fight the back button.

Caching is a fundamental aspect of the web. Even in a personalized site, most of the content can be cached. The web is read-only for the most part. However, many enterprise web applications don't take advantage of caching. This is fine when there's not that many users, but it's bad when you want to scale to thousands of users. There's several frameworks that use cache-busting and prefer backend caching over HTTP caching. These frameworks are not using the web like they should.

Backend caching (e.g. Memcached) uses a non-uniform interface and you need to explicitly program to it. Frontend/HTTP caching has a uniform interface that's pluggable. Backend caching is generally more expensive to develop and deploy. There are cases where data should be cached on the backend, but you shouldn't focus all on backend caching w/o doing some frontend caching.

With Ajax, you get more opportunities to be RESTful. XMLHttpRequest is another HTTP client that can be programmed to. It has full support for the uniform interface, which allows content negotiation, optimistic concurrency and caching. Cross-domain hacks can be done with <script> and <iframe> to tunnel requests over GET. The W3C has been working for the last two years on how to do cross-domain Ajax w/o using hacks. The problem with current cross-domain implementations is they often use GET for everything, which isn't very RESTful. Subbu recommends using a proxy on the same domain if you do need to talk to other domains. This will allow your Ajax code to remain RESTful.

Web Frameworks
Web development is hard because of all the moving pieces that exist. Because of this, many web frameworks have been created to solve the various problems. In 1997, there were servlets. They provided basic plumbing and closely reflected HTTP/1.1. Servlets provided a poor programming model, but it allowed a lot of frameworks to be built on top of it. We don't use servlets to write applications, only to write application frameworks. The second era came about in 2001 when Action-oriented frameworks became popular. In 2004, JSF and friends came to play. JSF is a component-based framework with known limitations (complex, slow, uses POST for almost everything, Ajax is difficult). These limitations have resulted in a number of third-party patches being developed to solve these issues.

JSF was designed to use the request to create a component tree that maintains state. Unfortunately, the state is not something the developer has control over. It's not the state of the application, it's the state of the components. The client's knowledge of the state is mentioned with a cookie and the server keeps the state in the session. The problem with JSF is you don't have a choice of state in your application - you can't write stateless applications like you can with servlets.

JSF uses overloaded URIs for its resources. When you have one URI with multiple representations, there's no way to tell how a representation was chosen. JSF's compromise is to allow client-side state saving. However, they do this by putting hidden field in the form and requiring POST for navigation.

JSF vs. REST
Basically, these two are at opposite extremes. JSF is focused heavily on a UI component model. The people that developed it misinterpreted how the web works and made some fundamental questionable choices. You can patch it, but you can not fix it.

Web 2.0 Frameworks
GWT is a cross-compilation based framework. You write Java to generate JavaScript (b/c everyone hates writing JavaScript). It mashes client and server code into a single source. These layers communicate using GWT-RPC. Typical RPC concerns do not apply since code generation handles coupling and the client is downloaded from the same application. GWT-PRC does POSTs to the server and uses HTTP like a transport layer. To be fair, GWT does allow you to use a RequestBuilder to use the web like it should be used. This class allows more control over HTTP requests, it supports GET and POST and it allows so-called RESTful layers (GWT-REST and GET-Restlet). GWT is focused heavily on ease-of-use, which is good. It's modeled after RPC and breaks the uniform interface and focuses on backend caching. Unlike JSF, GWT is fixable, but the community tends to use RPC instead of RequestBuilder.

SOFEA has a central promise of SOA. Business logic is a reusable service that changes less often. The presentation application calls those services and changes more often. The nice thing about this type of architecture is it allows a separation of concerns and loose coupling. However, it doesn't embrace REST like it should. Appcelerator is an implementation of SOFEA that has a Ruby on Rails-like usability. However, it uses a SOAP/HTTP style with messaging and POSTs to a single URI. Appcelerator is interesting, but it introduces a different style of coupling. It breaks URI opacity and client deals with POX instead of links.

Conclusion
Don't fight the architecture of the web. Innovate and enhance instead of breaking. If nothing else, break judiciously. As developers, we should demand more from our frameworks and make sure they use the web and HTTP like it should be used.

Ajaxified Body

I've often wondered if it was possible to use Ajax to reload the main content of a web application without reloading the header, menu and footer. SiteMesh allows you to move these common elements to a decorator that gets wrapped around each page. Below is a diagram of how SiteMesh works.

You can read the Introduction to SiteMesh article if you're interested in learning more about SiteMesh's basic features. By default, SiteMesh decorates text/html responses and ignores any other content type (e.g. image/gif). It also contains an <excludes> configuration element that allows you to turn off decoration when a URL matches a certain pattern. For example, the following allows you to disable decoration when "ajax=true" is passed in the URL.

<excludes>
    <pattern>**ajax=true</pattern>
</excludes>

To optimize the loading of an application so the common elements aren't loaded for each page, it should be possible to create an Ajaxified Body where the primary content area (PCA) of the site is loaded via Ajax rather than refreshing the whole page. The header, footer and navigation bar often stays the same from page-to-page, so it doesn't seem to make a whole lot of sense to load them each time the page loads. The image below shows the PCA (of an AppFuse Light application) as a grey square with a red border.

Implementing an Ajaxified Body consists of the following steps:

1. Adding SiteMesh and moving common elements to a decorator.
2. Remove common elements from each individual page (if you're using includes).
3. Configure SiteMesh so decoration is disabled when the requested URL contains "ajax=true".
4. Write JavaScript that modifies all <a href=""> links (and buttons with onclick='location.href') in the PCA to have an onclick handler.
5. The onclick handler should call a JavaScript function that loads the link's URL + ajax=true using XMLHttpRequest (XHR).
6. Add XHR success handling to replace the PCA with the loaded content.
7. Add XHR error handling to go to the URL normally when response.status != 200.
8. Inspect the response HTML for <title> element and replace document.title if exists.
9. Inspect the response HTML for <head> element and append to current if exists.
10. Inspect the response HTML for <script> and <link> elements (JavaScript and CSS) and evaluate them if they exist.

As a proof of concept, I created a prototype using AppFuse Light (Prototype/Scriptaculous for Ajax). You can see a demo at the following URL. You can also download a patch or the source for this project.

http://demo.raibledesigns.com/ajaxifiedbody

Below are a number of things I discovered while writing this prototype:

• The hardest part of implementing this seems to be coding the exceptions. It's possible you'll have some links with existing onclick handlers and you may have to disable "ajaxifying links" for those links.
• A progress indicator is important or the page might load so fast that the user doesn't visually detect it changed. This can lead to a worse user experience because they don't see the flash of the blank page they're used to when a page load occurs.
• While forms can be submitted via Ajax, there's no harm in leaving existing form behavior in place where the full site is reloaded after submitting a form.
• If a particular page needs to change the common elements (header, menu, footer), it should be possible to do that with JavaScript after the PCA content loads.
• If the success/error indicator is outside the PCA, it may need to be populated and displayed/hidden with JavaScript after the PCA loads.

I'm sure my implementation can be improved, but I'm also curious to see what you think of this idea. I know it's not revolutionary, but it's something I'm considering adding by default to AppFuse and AppFuse Light. Do any Ajax frameworks do something like this out-of-the-box?

Update: Thanks to everyone for the great feedback - keep it coming. I agree that adding history support is a must. I'll try to do that in the next day or two. This post has also been featured on Javalobby and Ajaxian.

Update 2: Added history support.

Raible Road Trip #12 Vacation Report

I'm happy to report that the kids and I made it home safely last night after a heckuva Road Trip. We were gone for a total of 8 days and we drove for 4 of those. Here's some stats from Snow White:

• 43 Hours
• 2248.3 Miles
• 150.9 Gallons of Gas
• 14.9 AVG MPG
• 52 AVG MPH

Of course, these stats include day-to-day driving while in Montana.

Driving to Montana
We left early on Saturday morning, waking up at 4:30 and were on the road around 5. This was brutal considering I went to bed 4 hours earlier the night before. My Dad and I took turns driving and tried to listen to an audiobook (Spook Country) along the way. However, whenever one person wasn't driving, they fell asleep so the whole idea somewhat failed.

We arrived in Yellowstone around 5PM and checked into our campground. The ranger told me there were 5 grizzlies in the campsite and that we should pack up our food and put small pets in cars for the night. Of course, I couldn't wait to tell this to Abbie, who is always scared that bears will attack us when camping. I finally calmed her fears by telling her I wrestled a bear once when I was a kid and won pretty easily. After setting up camp, Abbie took a swim in the "freezing cold" Yellowstone Lake and we ate dinner and climbed into our tent shortly after.

On Sunday, we woke up and made it out of our campsite by 7:30. We drove to Old Faithful, enjoyed an eruption and proceeded to have a nice breakfast at The Old Faithful Inn. After checking out some more geysers, we made it out of the park around 11. We stopped briefly in Bozeman to see an old friend, hit Clearwater Junction and Lucky's (for huckleberry milkshakes) around 6, and made it to The Cabin just before dark.

At The Cabin
The few days we spent at The Cabin and in the Swan Valley were a lot of fun. I got to drive the family Excavator with both kids on my lap. Jack was operating the bucket while Abbie was operating the swivel of the cab. I took my mountain bike, so I got to ride some old trails I used to ride all the time as a kid. Not only were there beautiful views on the trails, but I also got to experience quite a wreck that sent me head-first into some rocks and bushes. It was the first time I've wrecked in a while where I thought to myself "that was fast and hard enough to break some bones". Luckily, all I received were a number of scratches and bruises.

On Thursday, we took my sister to the train station in Whitefish. We left early enough for my dad and I to get in some golfing at Meadow Lake Golf Course and the kids to hit Big Sky Waterslides. Apparently, they didn't have a height requirement because they were able to go on all the slides.

On the 4th, we finished Abbie's Princess float in the early morning, took a quick sauna and headed down to the Swan Valley Parade. We'd been talking about the parade and Abbie's float for several weeks, so I was kinda nervous that I might mess it up. Not only did everything go great, but there were several hundred folks that clapped when we drove by and commented on what a beautiful princess Abbie was.

After the parade and drinking some good ol' Busch Light from the "Beer Garden", we headed to Holland Lake for a swim and canoeing. We drove back home in time to play a game of horseshoes and get the fireworks setup for the evening. We had a good fireworks show (with yours truly in charge) and enjoyed lots of laughs with old friends.

The Drive Home
As usual, the drive home was the longest portion of the trip. The first day, we left the cabin around 11 and pulled into Billings around 5. The kids (and dog) did pretty good as we only needed to stop once. The shorter first day turned out to be a good idea since the kids like hotels so much. Yesterday, we left Billings around 9:30 and cruised along mightily until we hit the Colorado border. There, traffic came to a standstill and we suffered through stop-and-go the rest of the way home. After 9 hours, we pulled into my driveway, exhausted.

I don't believe we'll be driving next year. The Road Trip to The Cabin is something that should only be done every couple years. Snow White continues to be an awesome car. We towed a sawmill (on a trailer) to The Cabin and didn't even feel the load. With DVD screens in the back of both front-seats, it was an excellent road-trip vehicle for the kids. Also, it's smooth suspension made for an enjoyable experience for everyone (we drove Julie's Honda Odyssey one year and Abbie kept getting sick from the DVD screen bouncing). The more I drive it (esp. skiing, camping and on road trips), the happier I am with the purchase.

For more photos from the trip, please see Raible Road Trip #12 on Flickr.

Good times with kids in Colorado

A friend recently sent me an e-mail asking the following question:

May be coming to Colorado in early August for a good break. Can you share ideas on having good times with kids?

His kids are 3 and 5 years old, the same as Abbie and Jack. Here's my response:

[Read More]

What's a good RIA to develop in 20 hours?

In less than two months, I'm making my annual trek to Portland, Oregon to speak at OSCON. To prepare for my talk, I'd like to develop the same application with two different combinations: Flex + Rails and GWT + Grails.

As luck would have it, I'm having a hard time coming up with a good application to write. I'd like to time-box it so I only spend 10 hours on the backend (for each) and 10 hours on the front-end, for a total of 40 hours for both applications.

Can you think of any good applications that would warrant a rich front-end and wouldn't take too long to create? I'd like to put both applications in production and generate enough traffic to be faced with scalability issues.

Over the next several weeks, I hope to start creating the applications and blog about what I've learned along the way. At some point, I hope to post an outline and a rough draft. With your help, I believe this can be an excellent presentation. If the presentation and applications are as good as I hope they'll be, it's likely I'll open source them for everyone to use.

Thanks in advance for any advice.

Update: Thanks for all the great feedback. I've posted a survey to narrow the choices.

2008: The Year of Beer

In a few weeks, I'm heading to the American Craft Beer Festival in Boston. In July, I'll be attending the Oregon Brewers Festival in Portland (followed by a night at McMenamins Kennedy School). A friend and I just booked flights for Oktoberfest in Munich. A couple weeks after Oktoberfest, I'll be attending the Great American Beer Festival in Denver.

Homer would be proud.

The Web Framework Smackdown Questions

I'm doing my Web Frameworks Smackdown this morning at TheServerSide Conference. A few weeks ago, I asked What Would You Ask the Web Framework Experts? on Javalobby and LinkedIn. Here's a summary of those questions:

• What is the overall performance of your framework as it compares to others?
• How does your web framework position themselves in relation to Web Beans?
• How easy is it to create a re-useable component in your framework? Is it as easy as sub-classing an existing component?
• What is the key differentiating characteristic of your framework that makes it better than the rest?
• What do you think about the various scopes introduced by Seam, e.g. conversation vs request or session? If you support these additional scopes, do you also provide some sort of concurrency control?
• Why can't we, the Java Community, come together and adopt the best application framework and settle the web development subject?
• What are you doing to help with developer productivity?
• 2008 is a huge year for the mobile web. How do you help developers build great mobile web applications?
• If you couldn't use your framework, what would you use and why?
• How do you enable rich Ajax applications?
• Can a developer make a change to source, and hit RELOAD in the browser to see the change? If not, why not?
• What do you think about the whole Flex revolution, and do you think you are competitors to this technology?
• How easy is it to create a module and plug it into a bigger application, complete with configuration, code, and view?

Of course, there's many more questions on the aforementioned pages, these are just some that I hope to ask during the panel. Sitting on the panel: Don Brown (Struts 2), Keith Donald (Spring MVC), Ed Burns (JSF), David Geary (GWT), Geert Bevin (RIFE/OpenLaszlo) and Justin Gehtland (Rails). I tried to get Flex and Grails folks, but they'd either left the conference already or are speaking at the same time.

Update: InfoWorld has some modest coverage of this event in Web frameworks debated at TheServerSide Java Symposium.

Audi A6 Quattro

A few weeks ago, a friend recommended I join Hertz #1 Club Gold. His reason was simple - you can walk out of the airport, read your name on a board, jump in the car and go. No talking to anyone, just get your rental car and you're on your way. It sounded like a good idea, so I signed up.

Last week, I went online to reserve a car for this week's trip to Mountain View. I chose the cheapest car, and was subsequently prompted to choose an Audi A6 from their "Prestige Collection" for less money. I went for it.

This morning I hopped in the car at SFO and was immediately impressed. It's probably one of the nicest cars I've ever driven. It's not as fast as the Cayenne Turbo I drove for a week in Florida a couple years ago, but it's certainly a slick car. You can even talk to it to get it to change radio stations and such.

It's too bad I only have the car for one more day. I'm heading to TSSJS tomorrow night in Vegas. I wish there was a way to cancel my flight and drive instead.