The effect of a No Fluff, Just Stuff conference is not unlike that of a conversation with a beautiful woman: afterward, you feel simultaneously like you can do anything, and also like you’re the biggest moron ever to walk the face of the earth. The analogy runs out of gas pretty quickly after that, but still: you can’t help but feel pumped when you’re done with the weekend.

The networking was, as always, first-rate. I got to reconnect with Denver-area peers I already knew and make new acquaintances as well. The speakers themselves are also very accessible at No Fluff, and I enjoyed getting to get to know several of them a bit. Most of these guys are pretty big guns, but you never get the idea that they believe their own press, as the saying goes. If you want a chance to talk to or even share a meal with published authors and industry thought leaders, this is the conference for you.

Here’s a brief summary of some of my favorite sessions:

JVM Memory and Garbage Collection, by Ken Sipe. Ken led us through the structure of the Java heap and the life cycle of that Java objects that live in it. He showed us the heap monitoring tools we should be using. My ignorance of the JVM’s memory management was nearly complete before this session, so it was quite an eye-opener for me. I now see how a poorly configured heap can hobble the performance of a program that should otherwise run well on a given hardware configuration, and I know how to begin diagnosing such a problem. This was one of those sessions that leaves you wondering, “How could I not have known that?” But now, next time I run out of memory, -Xmx is the last thing I’ll be doing.

It occurred to me while listening to Ken speak that some exposure to embedded systems would be good preparation for this material. Only during Ken’s keynote that night did I discover that he (like another outstanding software engineer I know fairly well) began his career in firmware. So there you have it.

Security Code Review, by Ken Sipe. My notes on this session were not great, due to the combination of flaky WiFi and my strange and unexamined unwillingness to take notes in anything but Google Docs. (And yes, Docs supports offline editing with Gears now, but you can’t create a new document without an Internet connection.) However, I had two takeaways: first, that security considerations ought to pervade the development process, rather than be tacked on the end in an external review, or worse, in response to damaging exploits and bad press. The second was Ken’s proposed threat model, which struck me as a handy and reality-conforming way to think about the bad things that people can do to your software.

JSF: Whirlwind Tour, by David Geary. I am not a JSF user, nor am I a likely JSF adopter in the near future. I understand that JSF enjoys very good uptake in the enterprise, but most of my work is done outside of a classical enterprise context, so it’s probably just not something I’m going to do much. Going for the throat, one might even say JSF is the buttoned-down nerd of the technologies covered at NFJS, relying heavily on tooling, enjoying the embrace of the likes of Oracle, and being all JSR-y as it tends to be. I mean, compare this to the shorts-and-Birkenstocks free love of Grails! No contest among the self-proclaimed cool kids.

Nevertheless, if there’s anybody who can make JSF fun, it’s Dave Geary. This is a technology that is in no way near and dear to my heart, but I really enjoyed learning the basics in this talk. You can’t go wrong listening to this guy. (And for the record, you can go wrong thinking you’re too cool for JSF. It may, in fact, be a bit more buttoned down than other options in the space, but there are more developer jobs open right now for it than for Grails, hot shot.)

Git Control of Your Source, by Stu Halloway. This was one of four very good Stu talks I attended, and easily the most impactful. The cool kids have been refusing to allow me at their lunch table since springtime for my continued use of Subversion, and now I have some idea why. I have heard Git sold as a decentralized version control system, which synchronizes many noncanonical repositories across a project rather than rely on one centralized server—sort of a postmodern VCS, in terms Brian Sletten might appreciate. Stu actually didn’t cover that aspect of Git all that much, but instead focused on its more sophisticated concept of what constitutes a controlled file, a “commit,” a branch, a merge, and so forth. VCS scatology was discussed. He  made the point strongly that SVN discourages branches by imposing too much cognitive cost on the practice (largely through the anticipated difficulty of resolving merges or changing plans with a branch-in-progress), which is precisely the kind of thinking about tools we should be doing more of. It’s not the mechanics of what is technically possible with a tool that are important, but rather the woodgrain of that tool or the intellectual sensibilities it engenders that matter over the long term. Git doesn’t want you to worry about what will happen to the repository when your workstream is interrupted, and it makes it cheap to accommodate those interruptions when they occur. I predict this more than anything else will turn out to be a compelling reason for its adoption. We shall see.

This weekend was the first opportunity I’ve had to hear Stu talk, and I’m very glad I did. He’s a great speaker and a quotable guy, plus his laptop has a name nearly as clever as mine.

FP on JVM, by Venkat Subramaniam. I have in the past described Venkat (accurately) as a live-coding ninja. His Livecode-Fu was in evidence in this talk, in which he covered the basic concepts of functional programming with examples mostly in Erlang, Haskell, and Scala (with some Groovy for illustration purposes). Having been a Computer Engineering major, I can still do some elementary op-amp circuit design, but I am complete functional programming n00b, never having seen so much as a line of Lisp or Scheme in my undergraduate program. This left me at a bit of a deficit at the start of the talk, but Venkat did a good job introducing the requisite concepts and illustrating them in code. This truly was a good introduction to functional programming concepts in emerging languages of the JVM (plus Erlang, which does not run on the JVM) in Venkat’s inimitable and highly dynamic style.

Sometimes Venkat’s live coding feature becomes a bug when you try to take notes on one of his talks. There’s no way I can type as quickly as he can bang out code in his highly Bundled copy of TextMate, but happily the slides contained complete listings of everything he did. It will be easy to refer to them for review going forward.

Groovy Metaprogramming, by Jeff Scott Brown. Mere minutes before I left the home office for the start of the conference, I was coding an ugly hack to work around a “bug” in a Groovy MarkupBuilder I was using to render some XML in a Grails action. The darn thing wouldn’t emit XML for an element called “phoneNumber,” and I couldn’t immediatley figure out why. I hacked it into submission in a most shameful fashion, realizing there had to be a better way, but not knowing what it was. When Jeff covered closure delegates, I smelled something promising, but when he went over Builders, I knew I had my fix. I actually changed the code right there in the session and committed it to the SVN repository (not yet having sufficiently internalized Stu Halloway’s Git talk). Thanks, Jeff!

I already knew a fair amount of the Groovy metaprogramming material besides that, but this fix was definitely worth the price of admission.

Well, with the Dow making its biggest single-day point gain ever today, maybe things aren’t going to be so bad after all. However, the economy is still on everyone’s mind these days, especially us independent consultants. Will shrinking demand for development services cause our business to decline, or will hiring freezes and tight budgets cause IT managers to look to variable-cost options like consultants and small development firms to keep key projects alive? Time will tell.

In case it’s the former, I’ve put together my predicted top ten growth industries for 2009, so we can all focus our limited resources wisely:

1. Brisk trade in gold, guns
2. Generating electricity for
3. Foraging for nuts and berries
4. Being a Democrat in elected office/Not being a Republican (tie)
5. Repurposing credit default swaps into lightweight, waterproof shelters
6. Issuing public guarantees of underperforming bank assets/nationalizing the banks (tie)
7. Innovative financing methods to enable less-creditworthy borrowers to participate in the dream of home ownership, only in this case the dream is a blood-chilling national nightmare
8. Law practice specializing the the raft of rushed and poorly thought-out regulations about to be imposed on the financial industry
9. Fix and flip!
10. Providing Agile training and coaching at recession-sensitive prices to give businesses the tools they need to remain competitive in the face of shrinking budgets and to position themselves for success in the recovery, following Tim Bray’s recent suggestion

With so many options to choose from, 2009 could still really be an exciting year. As for me, though, I think I’m going to go with #10. Who’s with me?

At the DOSUG meeting last night, Matt Quinlan talked to us about his company’s product, Appcelerator. Appcelerator seems at first blush to be another JavaScript framework wanting to make AJAX and UI widgets easier, but actually does have a pretty neat spin on the problem that makes it something more than just another dōjō or jQuery. Appcelerator brings delcarative, remotable messaging to HTML. Put another way: the Observer pattern is back in your web UIs, and it misses you.

Early in his talk, Matt laid out the competing philosophies in the RIA space: to wit, plug-ins vs. the open web. These terms themselves are a bit tendentious (whatever is the opposite of “open” can’t possibly be good), and some of his arguments in favor of the open web were a bit thin, but at the end of the day I am with him here. Despite the power of the Flash plugin to deliver pixel-perfect UIs, cross-domain networking, and snappy user interaction with impunity, I still think HTML, CSS, and JavaScript are the best way to go most of the time. Call me a masochist.

Appcelerator includes some nice UI widgets and a framework-agnostic means of wrapping others’ JavaScript- or Flash-based UI widgets with a consistent API, but the talk was not about the widgets. The real value of Appcelerator comes in its in-browser message bus. Using nonstandard HTML attributes in your markup (something like

), any of a large set of DOM events, key presses, mouse events, drags, drops, etc., can be published to a message bus running in the page in JavaScript. Likewise, any scriptable element can be delaratively advised to subscribe to messages in the bus. Thus HTML elements become Observers of an impressively generalized stream of events in the browser, and you are free to think about your UI at a level of abstraction bordering on the appropriate.

But wait, there’s more! The message bus isn’t constrained to the browser alone. You can publish messages to remote endpoints, which in the case of Java are consumed by annotated POJOs on the server (presumably through the agency of a canned servlet-cum-Controller you’ve mapped in your WAR). Back-end services are responsible only for returning JSON data, which is more or less automatically consumed by the Appcelerator front end according to some friendly-seeming naming conventions and the message subscription declarations already described. This is cool in the extreme.

This architecture has several positive implications. Chief among them is that your HTML pages become an entirely static resource, able to be served from a vanilla Apache instance disconnected from Tomcat, JBoss, WebLogic, the Black App Server of Mordor, or whatever. Your code does not render HTML anymore. Further, it becomes easy to mock back-end services in pure JavaScript. This allows front-end developers to write a complete and functional front end user interface—an artifact which is not a mock in any sense of the term—while easily mocking the back-end services by including a single JavaScript file. This JavaScript mock (really just a bunch of functions returning some JSON) then becomes the ultimate Agile spec document to be consumed by the back-end team one iteration at a time. It’s like the product practically builds itself.

And hey, as an aisde: some Appcelerator ninja should suggest a convention for this mock file, perhaps using JavaDoc-like comments that could easily be processed at build time into a publishable HTML spec document for quick reference. The code itself shouldn’t be too hard to read, but this extra step would be a nice touch.

Matt also talked about tooling a little bit, but with Appcelerator’s embrace of the open web, the tooling question becomes less important as a part of their value proposition. They can assume that we all have tooling we like for building HTML, CSS, and JavaScript—or perhaps more to the point, tooling we hate, but tooling we at least can call our own.

Appcelerator  was founded and is advised by veterans of the open-source world, including Matt himself, who was Employee 31 at JBoss and an early hire at Appcelerator. The company’s site puts forth the image of an open-source startup, but there is no mention of any way to give money to them, and Matt was coy on this question when I asked him. Given the recent tremors in the Enterprise Java community caused by Spring Source’s changes to their support policy, I feel a new sense of caution on this front. The product is licensed under Apache 2.0, so there’s no questioning its open-source-ness, but I’d still feel a little more relaxed about trying to adopt it for a future project if I knew how the company planned to make money some day. Now, don’t get me wrong; I love philanthropy, but the knowledge that somebody, somewhere is trying to make money from a product I use still gives me a certain sense of comfort, as if I need not speculate about future motives or present sources of funding. It makes sense that Appcelerator would be giving things away with abandon now, while trying to grab market share, but I’d recommend that they modify their messaging to include something about their future business plans. It would just give us a warm fuzzy, is all.

Notwithstanding that minor note of caution, this is a really impressive product that I’d like to try to take for a test drive as soon as I can. I’m very glad to have seen Matt’s talk.

Well, it pays to consult the thought leaders on this one. I’m told Ken Sipe does one-weak sprints, when he’s not busy piloting his single-engine plane deep into the bush on an obscure errand somehow related to an enterprise SOA deployment. Jared Richardson prefers a more moderate two weeks—life just has a slower pace in the South—and of course there’s a whole slew of lesser Agilists who claim you need a lavish three or four weeks to really find your stroke and make a productive team.

Of course, it all depends on what kind of project you’re talking about. Because for software, sure, two weeks is great, but if you’re taking advantage of amazing late summer weather and a few pleasant weeks on the bench to do some regrading of a troublesome patch of back yard, about two hours seems to work well.

Just saying, is all.