NFJS Conference Day 3 and Wrap Up

What a whirlwind weekend. I wasn’t sure how I was going to fit any more information in today, but somehow I managed to. I decided to get some more Java in today, and play with some more tools I hadn’t played with yet. I can’t stress enough how great this conference was, and they are on a national tour, so try to get in when they come by you.

Without further ado, day 3…

The State of AOP

Aspect-Oriented programming is one of those things that I’ve heard lots about, read lots about, and just haven’t played with. Ramnivas Laddad, the author of AspectJ in Action, was giving the talk, so I jumped in. And it was a good session. Ramnivas gave some good examples, outside of even logging, and showed how to use AspectJ with 1.4, and then using annotations with 1.5.

However, I couldn’t help but feel that Aspects in Java are some nasty hack put in to work around limitations of the language. Well, a well done nasty hack anyway. It was actually good to see the use of annotations both here and from the Tapestry session one of my coworkers attended.

Table-Driven Acceptance Testing

I had met Mario Aquino on Saturday, and was interested to hear their viewpoint on FIT, which is what this talk was really about. We use Fitnesse almost exclusively, and other than Excel, I’m still not sure why people would create HTML tables manually. However, Mario had done some interesting things around DoFixtures, and it was an interesting demo. Especially the part where he used Jemmy to talk to his Swing App and drive it. We also talked about maybe driving Selenium in the driven mode using Fitnesse to test web apps.

While that may seem like overkill, it really is nice to be able to have your JUnit tests, and then all of your others controlled with Fitnesse. I’m glad Ward doesn’t read this – he’d probably throw a monitor at me or something. ;)

Pragmatic Tracer Bullets

In my opinion, Jared Richardson’s Pragmatic Tracer Bullet talks was one of the best of the day, and one of the most controversial in our organization. Jared (the author of Ship It!) proposes a “tracer-bullet” process for starting a new project.

What is the tracer-bullet? First, you take the requirements and define your System Objects, which should be coarse enough to be able to be deployed seperately on different machines. Next, you propose the interfaces between the objects, connect them using stubs and canned data, add functionality, and then refactor, refine, and repeat.

The problem? Well, it seems like a lot of people think of this process as Big Design Up Front – the antithesis of XP. However, I don’t think that is what Jared was trying to get across at all. I actually felt he was proposing to do the simplest thing possible, except with a little planning ahead of the game. And, unless I have been duped by multiple spoof emails from Mr. Jeffries on the XP list, XP allows this. In fact, it encourages it. It just doesn’t encourage:

• Item 218.4.c.ii.1: The first character of the password may be of the set [a-zA-Z1-9]
• Item 218.4.c.ii.2: The second character of the password may be of the set [a-zA-Z1-9]
• Item 218.4.c.ii.3: The third character of the password may be of the set [a-zA-Z1-9]

Ugh.

Anyway, now that I’ve talked to some people, I think the issue is the terminology of all things. When someone says, “To build a system, first come up with the system objects, then build the interfaces between them, then start building them”, well, I guess they could be confused.

But even when I explained the full concepts (System Objects are tiers like Client/Server/Data Access/Database, interfaces are how we anticipate the layers talking to one another), it was still a stumbling point.

But I think Jared got it right. When we get a requirement in for an app, the first shot at the tiers are usually obvious. For example, if I get a request for an app where a user can go to a web page, enter some information, get a response back (which records the request for billing), I know I have the following tiers:

Client -> Server -> Data Layer -> Database

And I know the interfaces might look like:

• Client -> Server
• Login(username, password);
• GetDataForRequest(request);
• Server -> Data Layer
• RetrieveDataForRequest(request);
• RecordRequestAttempt(req, user)

And so on. But, in a small shop where these layers might be the responsibility of a handful of people for all, breaking out from the beginning, because there is no way to work in parallel on the layers – you’re small and serialized. But in a large shop, it very well might make sense.

Ruby Tools

Ok, enough about that. The last session was Mark Volkmann giving a rapid fire tour of various Ruby tools for editing, building and interacting with objects in Ruby. Perhaps the most interesting part was when he wrote a C++ file, compiled it, used SWIG to generate a wrapper, built an .so, and then called it from Ruby as if it were a normal Ruby object. As easy as he made it look, I was quite impressed.

All in all, I had a wonderful time, and thanks to Jay Zimmerman and the whole NFJS crew for their hard work in bringing this to the area (and many others). We have a lot of people who learned a heck of a lot in such a short time, and who are excited about the various tools available to them in Ruby and Java.