No Fluff, Just Stuff: A Just In Time Conference
An interview with Jay Zimmerman and Ted Neward
Last year I was introduced to the No Fluff, Just Stuff (NFJS) Software symposium (www.nofluffjuststuff.com) in Atlanta. It was a high-quality experience in every aspect. The speakers delivered more than technical information, they delivered an insight into what was happening in our industry. The Dallas edition of NFJS (Lone Star Software Symposium) maintained (if not exceeded) this high standard and it too delivered on the promise of a small and very personal experience where participants and presenters mix throughout the three-day event.
NFJS was organized by Jay Zimmerman in 2001 after a number of conversations he had with members of the Boulder/Denver Java Users Groups. I was able to catch up with Jay between sessions. During our conversation, you could see that his meticulous attention to detail was driven by his passion to create a forum that has garnered a lot of respect in the industry. You can see that passion in his words.
JDJ: Jay, what motivated you to start NFJS?
Jay: I am heavily involved in the Boulder Java User Group
and was talking to a number of people there. We thought it would be great if we could have a technically focused event right here in Denver. We looked at the national conference model and said: what if we could localize it, focus on technical content, and find a way to attract teams of developers. We wanted to focus on development teams because we've found that the trickle-down effect that everyone was looking for from national conferences wasn't really happening. National conferences elevated the individual who got to attend. We wanted to elevate the entire team.
We contacted a number of companies and from conversations with them, we decided that a Friday to Sunday model would work the best. That way, companies were willing to allow entire teams to attend, as it didn't hurt their immediate schedules. As it turns out, it also offered a number of side benefits. First, most of the good speakers are independents who are heavily engaged. This schedule gave us access to those people. The other benefit was that we could also attract contractors and consultants as this group has long been ignored. These people take a double hit when they take time out to attend a conference.
There was a little resistance in the beginning, but then things really took off when we demonstrated that we were able to reliably provide a high-level event that is always worthwhile and something to count on. To be a better Java developer is worth one weekend a year of your time.
JDJ: How were you able to attract these high-caliber speakers?
Jay: We connected the dots with James Duncan Davidson and other top-flight speakers, then things just took off from there. The speakers like the highly interactive nature that is encouraged. Many of the speakers not only speak, they attend the other seminars; they dine with the participants. The whole structure is set up to be very personal and highly interactive. We currently get about three to four speaker requests per month. What we are looking for are speakers with fresh material with a view of where the industry is going.
JDJ: Why the lack of vendor presence?
Jay: We do have a limited number of sponsorship opportunities for passive marketing. We will distribute software and pamphlets, but what we are striving for is an environment that is friendly, not disruptive. I am proud that we get comments like "no one was selling me something." This get kudos from the developers and it does create a lot of goodwill with vendors.
JDJ: Is there a message that you'd like to send?
Jay: Yes. What we are trying to offer is something of extraordinary value that allows companies to reward their employees equally. Too often it is only the technical architect who gets to go to a national conference. We, as developers, get closed in our four walls. Once a year it's good to peek out and get a fresh view. And now we're making this easier by expanding to include 24 different stops in the U.S. and Canada.
. . .
The first lecture that I attended was a spirited talk on decoupling patterns presented by Dave Thomas (The Pragmatic Programmer). Dave's apparent meanderings were actually a very highly structured, methodical, and entertaining presentation on couplings and how to avoid them. During the presentation, Dave proclaimed, "I hate design patterns." His defense to such heresy was that "patterns should not lead your designs." He went on to say that patterns should be used as a standard language that describes elements of your design.
In addition to the coverage of development techniques, a number of the seminars focused on Tiger (J2SE 1.5). Glen Vanderburg talked about the concurrent programming features specified in JSR 166 and Ted Neward lectured on custom metadata specified in JSR 175. Ted is an independent software consultant and author who "just loves to talk a lot." I had the opportunity to listen to Ted between sessions. Here's what he had to say.
JDJ: How long have you been involved with NFJS?
Ted: I'm still in my first year doing these; IIRC, my first show was in Denver back in May. That said, almost from the very first show, I've felt like I've found a group to which I really "belong" - my very first speaker panel with Jason, James, Bruce, Dave, and Stu, among others, was an absolute blast and definitely one of my favorite memories as a speaker. The speaker panel at these shows is definitely not something to be missed. It's two parts stand-up comedy, two parts pithy wisdom, one part absolute enlightenment, and that's for someone sitting on the panel - I can't imagine what it must be like to sit out there in the audience. I'm absolutely honored by the company I'm with up there; I just provide the comic relief.
JDJ: Is there a message that you wish to impart or leave the audience with?
Ted: Honestly - a sense of "questioning"; so many times developers simply take the marketing material spoon-fed to them and accept it as doctrine and gospel without ever really stopping to think about what's going on under the hood. (Frankly, who has time to do anything but take them at face value?) But this is a correctable state of affairs simply by forcing Java developers to slow down for a moment and think the situation through. Ever stop to think how an RMI call actually works? Going through the mental exercise tends to yield some interesting insights that, lo and behold, yield some great suggestions about how to make a distributed object system not suck. If I can get the attendees to start thinking about these things, particularly with respect to upcoming technologies (When are Web services just like EJBs? When you use them like EJBs. When are they better than EJBs? When you stop using them like EJBs), then I've done a good day's work. Teach a man to fish...
JDJ: What do you draw from this symposium?
Ted: More than I'm able to put into it, that's for sure. I get to rub shoulders (both during the show and at the traditional Saturday night dinner-and-a-movie gathering we do at every show) with guys like Dave Thomas, Jason Hunter, James Duncan Davidson, Erik Hatcher, and, of course, some of my DevelopMentor buddies like Stu Halloway. I learn something new every time. On top of which I get to meet folks I've never met in person before: guys like Mike Clark, Bob Lee, Glenn Vandenburg, all of whom teach me even more, and even meet in person the folks I've met before but only over e-mail, like Bruce Tate, who's got a great story about how we came to know each other through Manning. :-) More than that, though, the small-scale nature of the show gives me the opportunity to poll the audience and actually give them a chance to offer insights on the material I'm presenting - it seems like almost every show I have somebody telling me some interesting little tidbit about software that I didn't know before. It forces me to rethink my positions on software, and that's probably the best benefit I can possibly imagine from a show.
JDJ: What prompted you to talk about the metadata features
Ted: Officially, the stuff I'm discussing in the JSR 175 talk is still under wraps, but considering that our Expert Group lead, Josh Bloch, and a few others have been engaging in Webcasts and other discussions to promote the new features of Tiger, it seems the cat has already been let out of the bag. That said, though, I have to prefix any talk I give on the metadata attributes stuff with a standard disclaimer (and the attendees are required to swear an oath to this effect) that if you build a production system based on what's presented here, you're liable to be pounded repeatedly with a whiffle bat until you agree it's a bad idea to do so.
By the time you read this, we should have released a Public Draft, but until that actually makes the streets, everything's up for grabs. There's also, I believe, a large misperception among the Java community at large about what metadata is and is for, mostly driven by systems claiming to be "aspect-oriented" that use attributes to convey the sort of interception that should take place against those methods; the perception is that JSR 175 is going to somehow codify that and make it a standard part of the language. Nothing could be further from the truth, and given the venue that I'm able to command through the NFJS shows, I've got a responsibility, I believe, to make sure the right message goes out to the world.
JDJ: Just what is metadata and how do you see it being used?
Ted: Officially, it's "data about data." In an RDBMS, it's the tables that describe the tables in your database instance. In Java, metadata is the Reflection model, the classes, fields, and methods that you build. Among other uses, it's what allows technologies like Java's Object Serialization and Hibernate to be able to reach into a Java object, discover its contents, and scoop out (or shove in) the values stored in those fields. It's powerful stuff.
JDJ: You mention in your talk that this will fundamentally change the Java landscape. Can you describe some of the changes that you expect to see?
Ted: A lot of mechanisms currently exist to try and provide extensions to Java's standard metadata through various means: J2EE uses deployment descriptors to offer custom metadata about transactional affinity (EJB) and servlet mappings (servlets), while JDO uses an XML "persistence descriptor" to describe how a JDO enhancer should modify your compiled classes to provide transparent persistence capabilities. Both of these things, along with many others, can and should be codified into your compiled binary, such that you can obtain that data without having to resort to mechanisms stored outside of the source code. Storing it externally to your source forces another point of maintenance and introduces the possibility that a mismatch can occur; this chance is greatly reduced, although not entirely eliminated, when the "descriptive" data is stored inside the source file it references. Although it's out of scope for our JSR to define some annotations outside of those needed for the core functionality, I can easily imagine several annotations that would have an immediate and powerful impact on the community:
(*) JavaBeans "Bean", "Property", "Method", and "Event" annotations, rather than naming patterns
(*) XML Serialization enhancements (a la .NET's XmlSerializer attributes)
(*) Outright replacement of such "marker interfaces" as Remote and Serializable
(*) Declarative security constraints enforced by the JVM, rather than explicit Permission checks at the start of each method
and so on. More and more "stuff" will be described using annotations rather than external "descriptor" files, and having this functionality built into the language and compiler will release tools like XDoclet from trying to act like metadata attribute systems and go back to their core focus, which is code generation.
Again, so long as your readers understand that reading this code example implies they're taking the whiffle-bat oath, using an annotation would look something like this:
public class Person
private String firstName;
private String lastName;
// . . .
JDJ: What is the "Arms Length API" and do you feel that
it is important?
Ted: The "At-Arms-Length API" is our current working term for some kind of API that would allow a tool (preprocessor or postprocessor) to examine metadata without having to load the actual class or its annotations into
the JVM. This actually has some powerful ramifications - it means that you'd be able to load into a postcompilation utility (like a JDO enhancer) a class whose annotation types you don't have on your CLASSPATH; the missing annotations would be described, but would not be able to be loaded until you put those annotation type binaries into a ClassLoader that can find them. Unfortunately, it looks like the Expert Group will have to defer defining this particular API for the Tiger release; we're just not sure we can get it done in time to make the JDK 1.5 release date. This is still a "hot" issue for the group though, so I strongly encourage feedback through the e-mail address listed on the 175 page at the JCP site, if readers are strongly in favor (or opposed) to that API. As a matter of fact, I strongly encourage everybody to have a look and see if it makes sense to you - the more data points we as an expert group have, the better we can make decisions that everybody
will have to live with.
. . .
The only disappointment I felt was when I looked at the schedule and realized that I would not be able to attend as many of the lectures as I would have liked. This is a clear testament that this symposium is time well spent.