Technical Pickles

Today marked the concussion of No Fluff, Just Stuff for the Boston Fall 2007 event. To put it simply: it was a truly amazing experience.

If you aren't familiar with NFJS, it was started just over six years ago by Jay Zimmerman out in Denver, Colorado. After many discussions with members of the Boulder Java User's Group, it was decided that there weren't any local conferences that focused on Java and agility, and that were strictly technical. Shortly thereafter, NFJS was born with a three-day symposium format. It was decided to cap the attendance at 250 in order to keep a high level of interaction between speakers and attendees. Each day has five concurrent tracks with a total of eleven 90 minute sessions with top-notch speakers from around the country.

I had the opportunity to speak briefly with Jay, and one thing I had asked was if much had changed over the past years. Apparently it had not. The particular format of the symposium works amazing well, with the small number of attendees, great speakers, and a high level of interactivity. Changing any of these would detract from what makes it so good, and would violate the original intent in which the event was started. Sure venues change, more schwagg is introduced, and technology continues to plow ahead, but at the heart, it's really the same as it has ever been, and that's a good thing.

The Sessions

There were a lot of great talks this year. Here is a list of sessions I had the opportunity to hit up:

• Friday
  • JavaServer Faces: A Whirlwind Tour by David Geary
  • OSGi: A Well Kept Secret by Venkat Subramaniam
  • 10 Ways to Improve Your Code by Neal Ford
  • Keynote: No, I Won't Tell You Which Web Framework to Use, or The Truth (with Jokes)
• Saturday
  • Productive Programmer: Acceleration, Focus, and Indirection by Neal Ford
  • Productive Programmer: Automation and Canonicality by Neal Ford
  • The Busy Java Developer's Guide to ClassLoaders by Ted Neward
  • Leveraging Annotations with AOP by Ramnivas Laddad
  • Birds of a Feather: Dynamic Languages with Neal Ford
• Sunday
  • Software Development Risk Analysis Techniques by Mark Johnson
  • Adding Behavior to Java Annotations by John Heintz
  • Experts Panel with all speakers present
  • REST: The Basics and Not So Basic... by John Heintz
  • Refactoring Ant Builds with Ivy, Groovy, and Good Old Fashion Common Sense by Andrew Glover

If I can find public copies of any of these presentations, I'll update this list with links.

Some future posts...

I found a few of the talks to be particularly fascinating, so I hope to follow up with several posts:

• Productive Programmer
• ClassLoaders
• Annotations + AOP + Behavior
• A summary of tips, resources, etc from everything

If you don't see something about these in the next week or so, feel free to hassle me a little :)

Pseudo random thoughts, observations, and feelings

• Things were pretty swagtastic this year
  • A pleather binder that zips close, came in extremely useful
  • A nice backpack, but I won't likely use it...
  • A CD with all the presentations
• The venue was the Framingham Sheraton
  • Great food
  • Great service and staff
  • Maybe a little overzealous on the AC in a few rooms
• Being around smart and passionate people definitely rubs off
• Definitely feeling
• Each day felt much longer than it was, in a good way
  • Amazing amount of new material
  • Constantly experiencing paradigm shifts
• All the speakers I spoke with were very approachable
• A lot of people didn't seem quite as engaged, as much as I was at least
  • Sitting leaning back during talks
  • Not taking notes
  • Not asking questions, or talking to the speaker afterwards
  • Not engaging in conversation with other attendees between sessions or at meals
• Survey says...
  • Most people are on Java 1.5 now
  • Most of the people still on Java 1.4 are there because of WebSphere
  • WebSphere sucks
  • A majority of people are doing automated testing
  • More people are doing continuous integration
  • More people are using not struts, including JSF, Tapestry, and Spring MVC
  • Most people are pretty psyched about Groovy, JRuby, and Grails
  • Overwhelming majority of people are using Eclipse
  • Most of the speakers are now Mac users
  • Most of the speakers are using IntelliJ IDEA

Advice for potential attendees

The most significant piece of advice I can give is this: be engaged. You have an amazing opportunity to interact with experts in the fields. You are surrounded by feels geeks and hackers who take time off to go to these kinds of things. Talk to them! Take notes! Absorb!

Wrap it up, B

I really can enumerate enough how awesome of an experience it was. I'm feeling pretty pumped up to get back to development to put this new knowledge to use. If NFJS is coming to a city near you, take the plunge; you won't regret it.

Like the good little code monkeys we are, it is time for us to adopt some form of web testing. There is only so much unit and integration testing can help you, before you need a fuller solution.

Given its maturity, Selenium seemed like the obvious choice. Here's what I found:

The Good

Here's some things we liked:

• An IDE, as a Firefox Extension, for building unit tests
• Support for testing in a many languages, such as Java, Ruby, their own Selenese (basically glorified HTML)
• The IDE generates Selenese, which can easily be converted to one of the above mentioned languages
• Support for running in multiple browsers across multiple platforms
• Support for running selenese tests using ant

All in all, pretty cool stuff.

The Bad

However, when we went down to our particulars for our project, things fell a little short. As a brief background, we use ant for building, junit for testing, and bamboo for continuous testing.

You can convert from Selenese to your language choice, but once you do, you can't go back. This is kind of expected, as you can do all sorts of trickery to the code after converting it from Selenese. The API for interacting with Selenium closely follows the Selenese. Here's an example of Selenese, and then converted Java.

<tr>
   <td>open</td>
   <td>/</td>
   <td></td>
</tr>
<tr>
   <td>clickAndWait</td>
   <td>link=diabetic nephropathy, schizophrenia, and bipolar disorder</td>
   <td></td>
</tr>
<tr>
   <td>clickAndWait</td>
   <td>link=Steering Committee</td>
   <td></td>
</tr> 

public class NewTest extends SeleneseTestCase {
   public void testNew() throws Exception {
       selenium.open("/");
       selenium.click("link=diabetic nephropathy, schizophrenia, and bipolar disorder");
       selenium.waitForPageToLoad("30000");
       selenium.click("link=Steering Committee");
       selenium.waitForPageToLoad("30000");
   }
}

The code here produced isn't the cleanest, because the API is closely following Selenium conventions, rather than using the language's conventions. For example, Maps should be used, instead of something like "link=Steering Committee", and Integers should be used instead of number in a String.

Because you can't go back to Selenese from code, we decided we should always work with Selenese, so we can maintain tests easily using the IDE. This means we need to use the 'selenese' ant tasks for running our tests.

This is how our invokation looks:

<selenese suite="${dir.webtest}/selenium_test_suite.html" 
  results="${dir.selenium}/selenium_test_results.html"
  browser="*firefox"
  timeoutInSeconds="90"
  startURL="${webapp.url}/" />

The first issue is that you have to specify a test suite. You can't just give it a directory, or fileset, that includes all your tests. This is one extra thing to maintain, and it becomes easy to forget to add new tests to it.

The other issue is the output. It's just an HTML. We want to be able to generate junit-like XML, so a report can be generated along with all our other tests.

Coming to terms

Since this is open source, the obvious solution is to get hacking, and so I started delving into the source tree.

I had two primary impressions of the codebase. The first is that there aren't suitable layers of abstraction. For example, instead of having a class representing a suite of tests, and a class for representing tests, java.io.File instances get passed around and grokked as their needed. Second was that it isn't sufficiently extensible for. There weren't any places we could hook in, or classes to extend, to change the results ouput, or even get at it.

On-the-fly suites

The issue here is that the code is expecting a File to be passed in, which contains all the tests. I had hoped it had some abstraction which would parse through the suite, so if you wanted, you could programattically build up a suite.

So here, we can get around this by building up a temporary File, which contains the appropriate HTML for Selenium to understand it as a suite.

JUnit reports

When looking at the code, I had hoped to see like a TestResult class, that you could get the results out of, and then have a way for outputting the results as you see fit.

Since we can't do that, the next best thing would be to parse through the results' HTML, and spit out XML laid out in a way that JUnit's reporting mechanism would be able to understand.

Success!

After a day or two of hacking around, I was able to implement the workarounds I mentioned here.

Unfortunately, the implementations turned out to be a bit too closely tied our environment, so I can't readily turn it out to the rest of the world.

Hopefully, I will have the time to do the necessary refactorings to be able to do so.