When we started Faces 1.0 it was very important for us to work with tools, that’s where a lot of our focus was. But now, we really want to focus on ease of development without tools.

– Roger Kitain

– Staff Engineer, Sun Microsystems

– Talk at Javapolis on Dynamic Applications With Faces and AJAX

A more enlightened approach focuses on ease of development. Our developers spend next to no time in the drag and drop tooling of JSF plugins, but various JSF pains like dealing with spotty error reporting from the 6 phase life cycle have consumed hundreds of hours of valuable time.

Apparently they’re going to focus on AJAX in the 2.0 spec as well. We’ve gone ahead and used AJAX Anywhere over the past year.

The really unfortunate part is JSF 2.0 is still in just getting started and since Websphere doesn’t have J2EE 1.5 support yet we can’t move up to even JSF 1.2.

The value of having continuous integration of your code is everyone knows when someone broke the build. The two most common errors are forgetting to check in all the changed code from someone’s desktop or forgetting to run the whole test suite before checking in.

There’s a tiny bit of guilt associated with breaking the build under normal conditions. Then there’s the times that make you scratch your head.

Like, the developer who checked in a single java class with the compelling CVS comment:

This doesn’t compile.

Then there was the retort long ago from another developer who had broken the build by forgetting to check in a class. It turned out the class he hadn’t bothered to check in that was being referenced in other classes didn’t actually compile. He sent a cryptic email explaining this:

I can check in the class if having an unused non-compilable class in CVS is a problem for you guys.

Only problem was the ‘unused’ class had several references to it in the code. Strange understanding of unused.

They do make for good war stories.

Tomorrow we’ll demonstrate Fitnesse tests for a complete 30 days of work to the whole team. We’ve piloted Fitnesse tests before for portions of a Sprint’s code, but never for an entire Sprint’s worth of work.

Our experience so far:

• Some of the team is still having trouble understanding what Fitnesse is for. Responses have ranged from “OK, I think I get it,” to “We didn’t sign up for this.”
• The developers have understood it best, but we’re championing automated acceptance tests.
• QA has been easier to involve with writing tests, and they have helped add extra scenarios.
• Business analysts are still taking a wait and see approach. They’re writing use cases for the first time. Fitnesse with its’ wiki type approach is still an additional input they may not be quite ready for.

I’m hopeful we’ll turn some heads tomorrow at the review.

Well we’re seeing a lot more MySQL customers these days.

— from a manager at a DBA outsourcing company

Purely anecdotal evidence, but I assume as databases like MySQL have proved themselves capable of doing a comparable job to Oracle, DB2 or SQL Server the cost issue has begun to make a difference. And if you’re a new business then a commercial database isn’t compelling. When more of the enterprise software vendors start supporting products with an option beyond Oracle, SQL Server, and DB2 adoption will increase. That took a while for Linux, but eventually everyone started to support at least RedHat for their enterprise software installs.

Could also be that companies hacking together a site in PHP who don’t know much about databases have to go looking for help as soon as they get large numbers of users.