TimShadel.com

Random tidbit. I’ve followed Merlin’s dangerous precedent, and nuked nearly everything I have in my RSS reader. Unlike Merlin, I didn’t delete everything. I’ve left only those places I know I enjoy reading at least once a week. Everything else is gone. I did, however, backup my subscriptions as an OPML file. I’ll drop that into my personal Subversion repo, svn rm and then forget about it. If I really, really need it I can dig and the clutter’s gone from view. But I’m sure I won’t need to. If you care at all, you can see my subscriptions on my public Bloglines profile. In addition to what you see I have one Trial folder, and one folder to ensure my own feeds come out right.

Selenium is an excellent open source tool to test your website automatically, right from your browser. The test scripts are written as plain HTML files, which makes them easy to read, edit, and understand. BUT, it’s even easier than that. There’s an IDE for developing these tests.

We used to use a different tool, but we found one that’s MUCH better. It’s called Selenium IDE. It’s a plugin to Mozilla Firefox. You can watch this video about how easy it is to record Selenium tests with Selenium IDE.

Install Selenium IDE

Once you’re ready to start, you can download Selenium IDE. (When you click, you’ll see a yellow bar near the top of the page that says Firefox requires you to allow Extensions to be installed from openqa.org. Click the Edit Options... button to allow the installation.)

Glimpse the Future

These automated tests are great, but sometimes we have trouble because they rely on specific data. This video shows an example of what is possible. The example is done in Ruby, so try to ignore that part if you’re not comfortable with Ruby. Watch, though, as it moves into automated acceptance tests that setup the database, click through the application, and do it in both Firefox and Internet Explorer. This is the vision that we have for automated acceptance testing. Enjoy.

I’ve had lots of feedback from listeners of my JSF podcasts. Many of them have asked what I’d recommend instead of JSF. I think the best answer is no answer here. Matt Raible’s latest post is a great example of the process I’d actually recommend to make your own decision.

Look at your project, your people, and your skills. Look at the industry directions, and contrast the approaches each framework takes. Look at your existing tools, your budget, tool documentation, forum support, and a growing collective knowledge of how to solve hard problems with a framework. From there, take your best guess and try it out on something small, then add a bit of complexity in difficult areas like using complex objects to drive your UI or reusing chunks of UI and controller logic. See how well your framework front-runner does.

Have a junior developer try to complete a maintenance task on your prototype. Evaluate the options enough to get a feel for it, but take the plunge at some point. Recognize that you can change it later, and that will cost something, but you need a longer term experience to know the bumps, bruises and bright spots. Blog about your experiences on the way to clarify and catalog the evolution of your thinking.

Finally, don’t choose simply one framework and always use that. Matt’s a great example in this area as well. If you look back, he’s done several comparisons of various web frameworks; often the same frameworks are in all of the comparisons. He’s made different recommendations over time depending on the goals of his comparison. He’s also looked at fringe frameworks and disected them to understand what they offered, even if he decided not to use them. These are the kinds of things you want to do or see others do when making a choice about most technical recommendations.

Michael Slattery makes a good observation in a comment on my last JSF podcast.

I generally enjoy your podcasts. [...] I have some feedback. It seems like you are complaining mostly about an implementation of JSF rather than the spec itself.

Much of my chatter has centered around examples involving the actual implementation. Let me step back and summarize my podcast main points from the standpoint of the spec:

1. The JSF spec indicates exclusive use of POST. That breaks all kinds of RESTful idioms and paradigms that good websites are based on. Strike one.

2. The JSF spec itself attempts to create a component model with a lifecycle that obscures the underlying HTTP request-response cycle. It’s a Leaky Abstraction, and it does more harm than good. Strike two.

3. The JSF spec defines the concept of a RenderKit; a concept that places HTML far away from page content and creates an abstraction that most people won’t need but everyone must deal with. Oh, and it turns the page definition into an XML config file, forcing my view logic back into the controller area. Strike three.

Many of the annoyances I listed are stated in an implementation specific way, but my philosophical differences truly lie with the spec. Perhaps it’s a forest vs trees thing. In any case, it evidently wasn’t clear that the spec was to blame for the issues discussed in my podcasts.

Oh. I almost forgot. One more:

4. The JSF spec is a spec for a web framework(!?). So the rest of the problems I have with substandard implementations are indirectly caused because there’s a spec in the first place. If there was just a single, high-quality framework it would eliminate the chatter of choosing among several implementations and focus disucssion on the underlying merits of it’s approach to web development. Will the next web framework please step up to bat?

Merlin Mann has an interesting take on podcasting here:

Flash: “Podfading” ravages the landscape of logorrheic bloggers

Me? I like the idea that a podcast is simply another way to post. Nothing more. Same way that Flickr and del.icio.us — to name just a couple — let me share something in a way that isn’t a traditional blog post, recording audio lets me (try to) make a certain point in my own way and with tone (and, one hopes, personality) that are a contrast with typically dry blog writing. But maybe that’s just me.

Agreed. 100%. I view the Zdot podcast as an extension of my blog. It lets me speak about things I’d rather speak about, and write about things I’d rather write about. My frequency isn’t tied to a radio show paradigm, but to my interests. It seems this works well for most of my listeners, too.

This is the final part of my three-part series on why JSF isn’t my personal choice for future development work. I focus on the woes of the doing HTML interfaces in JSF.

Download JSF Part 3.

The major problems I speak to:

• The HTML put out by today’s JSF components is neither standards compliant or semantically meaningful. Take a look around the web, and you’ll see all sorts of movements that require good, semantic, standards compliant HTML. JSF’s rederings are stuck in 1999.
• The HTML for the components is very far away from the page layout (it’s in the RenderKit). To fix HTML problems, programmers will likely find workarounds instead of fixing the problem. That’s a set of Broken Windows waiting to happen (see The Pragmatic Programmer) . It doesn’t encourage the kind of clean programming that I think it ought to.
• RenderKits are an artifact of the Architecture Astronauts. They are so unlikely to be used for the purpose for which they were designed that they create more pain than solution. (Will all seven of you using your JSF for HTML and WML please stand up?)
• Finally, JSF turns JSP almost, if not entirely, into a data language (or declarative language) instead of an imperative language. The page layout is used to configure the component tree, and has no direct representation of executable statements like “if” and “for”. Some view this as a triumph; I think it’s a tragedy.

Again, I’d rather be solving the business problems than finding workarounds to these restrictions and annoyances of JSF. If you’re interested in reading and hearing more, please see my previous posts here, here and here.

UPDATE: The mp3 file should now be in the right spot. Serves me right for posting in a rush. Sorry. While I’m at it, I might as well claim my Odeo channel (odeo/0f55e88149deb27e). Enjoy.