Last week I had the pleasure of speaking at the Scandinavian Developers Conference in Goteborg, Sweden. I flew out on Sunday afternoon with my friends Matthew McCullough and Paul Rayner, who were also speakers at the conference. We arrived in Göteborg on Monday afternoon and checked into the Hotel Gothia Towers, finding comfortable rooms with all of the free, fast broadband a geek could want. This is the stuff of Norse epics.

The conference’s organizers treated the speakers to an exclusive dinner on Monday night at a nearby restaurant whose name was sadly lost to jet lag. Conversation flowed freely for hours among world-class talents whose company I was honored to keep.

The show opened on Tuesday with a keynote by Michael Feathers. Michael observed that the software community has thought less about design and more about process in the past decade. He suggested that web-scale computing heralds a return to constraint-based engineering, which will cause some strain in previous approaches to design and will likely overthrow the recent emphasis on process, restoring engineering to a prominent place in the work of the software developer.

On Tuesday, Matthew and I led a fishbowl discussion on “the dire need for encryption in web apps.” Technology topics often provoke emotional disagreements and highly affective conflict, but encryption is rare in that it also to touches concepts and passions that are as much social and political as technical. We spoke very little of key lengths and rainbow tables and much more of the economics of encryption, the nature of private property, and the relationship between the State and the individual. Our community needs more panels like this one.

The show’s seven tracks covered many topics, but overall evinced a heavy emphasis on Agile and Lean methods. Diana Larsen’s keynote on Wednesday morning riffed on the role of the manager is the agile organization, describing leaders more as curators of human flourishing than directors of mechanical activity. The more I interact with agile thinkers, the more I’m persuaded that this is a philosophical program I can get behind.

I spoke Wednesday afternoon in the Emerging Technologies and Cloud Computing track on how to use Grails and JMX together. My talk gave a lightning overview of Grails for the uninitiated (which turned out to be nearly everyone in attendance), a quick refresher on JMX, a video tutorial on how to manage Tomcat from VisualVM securely and over a public connection, a description of the Grails plugin architecture, and a quick tour of the kinds of the things the Grails JMX Plugin will let you do. It ended with a live demo of controller action statistics exposed by the plugin as MBeans. We even ended five minutes early!

I ended the conference with Kent Beck’s talk on Wednesday afternoon about the organizational changes necessary to release often. He discussed the kinds of organizational structures implied by a discipline annual, quarterly, monthly, weekly, daily, and continuous releases—fascinating process thinking from a true thought leader. I had the unexpected pleasure of sitting with Ken, his partner Cindee, and two of their daughters at Dinner 22 after the show. Our discussion of value-based consulting and integrating family life into a heavy travel schedule was more helpful to me than two hours of TDD mentoring would have been—and it’s not like I couldn’t use expert help with the latter.

Which is to say nothing of the reindeer steak, which may end up being the best food I eat this year. Time will tell.

Matthew, Paul, and I spent Thursday exploring Göteborg. Despite the cloudy and cold day, we found that the city had much charm to offer. It is safe, clean, and offered plentiful cafes filled with earnest, multilingual conversation, coffee, and all the baked goods you could metabolize. (Wifi was less than plentiful, but we managed to survive.)

The conference itself was superbly organized and run—and I don’t say that only because they had the foresight to accept a talk on Grails. The organizers took good care of their speakers, selected world-class headliners, incorporated sponsors in an appropriate way, and encouraged some nontraditional forms like the fishbowl talks and the open-space-style “conversation corners.” A huge thanks to Lennart Olsen of Iptor Konsult AB for his outstanding work, and especially for his coaching of my Swedish—which, as he pointed out, is not nearly as good as my surname might suggest!

It was truly a world-class conference which I’d be happy to attend again next year. Thanks to all who made it possible.

Here’s a partial list of my speaking engagements over the next few months. Another event or two may pop up, but this is it for now. If you’re near one of these, I’d love to meet you!

• 3/11: Memphis JUG. I’ll be speaking on Practical Agile Database Development (featuring Liquibase). This talk is sponsored by the Mid-South Software Symposium.
• 3/12-3/13: Twin Cities Software Symposium in Minneapolis, MN. I’ll be giving all four of my No Fluff talks: Agile DB Development, Slaying the Legacy Dragon, Open Source Business Intelligence, and Decision Making in Software Teams.
• 3/16-3/17: Scandinavian Developers’ Conference in Göteborg, Sweden. I’ll be speaking on Managing Grails with JMX.
• 3/30-3/31: Orbitz Tech Talks in Chicago, IL. This is a private event, but an exciting one for me. I’ll be speaking on my favorite language, Groovy, to a group of developers at at this very tech-savvy organization.
• 4/9-4/10: the Greater Illinois Software Symposium in Bloomington, IL.
• 4/23-4/25: the Mid-South Software Sympsium in Memphis, TN.
• 4/30-5/2: the Northern Virginia Software Symposium in Reston, VA.
• 5/21-5/23: the Gateway Software Symposium in St. Loius, MO.
• 6/14-6/17: Überconf in Westminster, CO. This will feature my four No Fluff talks plus talks on Gaelyk, a deep dive on Talend Open Studio, and a big-idea talk on complexity and software development. I’m really excited about this conference! Register here.

I’m very pleased to announce my partnership with ThirstyHead.com. ThirstyHead is a training and consulting company that specializes in Groovy and Grails solutions. I’m still going to continue every bit of my work at the August Group as a writer, speaker, and software developer, but I’ll be joining forces with Scott and Andy for classroom training. ThirstyHead is a strong brand in the Groovy and Grails training space, and I couldn’t be more pleased to be a part of their team. Look for continued G2 Goodness from ThirstyHead, as well as new offerings in the near future. Stay tuned for more!

Like a terminally ill dictator in exile, IE 6 has been hanging on for far too long, forcing legions of web developers to to relive the pain of its tyranny every day. Happily, it’s starting to look like the old bugger might finally pass away.

It’s no longer news that Google is phasing out support for the browser, and more anecdotally, a very tech-savvy client of mine has eliminated support for it in its next-generation web app—an app which is responsible for the entire business and is exposed to external customers as well as internal users. When smaller technology companies who lack the power to move the market are making decisions like this, it means the end is near.

A Denver area design consultancy has now gone so far as to schedule a wake for the dying browser. What a fun way to celebrate a laudable technology development and generate some positive buzz at the same time! My hat is off to you, Aten Group.

Everybody who makes software makes bad software sometimes, so I’m always hesitant to blast bad code when I see it. That said, IE 6 was for years a gratuitous drain on the flourishing of the web and the cause of more misallocated capital than a hundred failed dotcoms. It will be a relief to see it go. May the future of the web be more competitive and less autocratic.

Broken IE icon courtesy of Zakar.

I first bought my 100WH HyperMac battery on the recommendation of Scott Davis. It’s a great way to survive a long flight with a layover or spend some time in a cafe without worrying about being near a plug. Scott had warned me about the hiss it caused in the headphones (which didn’t stop me from temporarily convincing myself my headphones, then my MacBook audio output, were broken, before I remembered his advice), so I theoretically knew what I was getting into.

The hiss is actually pretty bad. On my machine, it quickly got to the point where I couldn’t enjoy listening to music while using the battery. Since the my two primary use cases both recommend headphone usage, this was a major bummer.

I have a theory of what caused the hiss. I haven’t been able to test this with my spectrum analzyer yet—yet!—but I think the problem has to do with the power converter in the HyperMac. The unit isn’t just a dumb lithium ion batter and a charger; it’s actually got a DC/DC converter onboard, presumably because the specified voltage on the MagSafe connector was not easy to achieve with lithium ion cells. And switching power converters mean noise.

I’ll skip some tedious details, but you can read more about switching power supplies on your own if you’d like. Basically, despite the best efforts of the power supply designer, a switcher will couple noise into its output at the switching frequency of the converter (plus its harmonics). Linear power supplies, distant cousins to switchers, avoid this, but at the expense of size, weight, and efficiency. This is why your stereo receiver is big, heavy, and hot—but sounds great.

So the HyperMac battery contains a switching power converter, and this switcher is busily coupling its noise into your MacBook when you’re plugged into it. My theory is that some of that noise is getting coupled through the power input and into the audio output circuitry, causing the hiss. Pretty straightforward, and suggestive of a simple fix.

But wait! Before I “fix” this problem, you’re dying to point out a flaw in my argument: Apple’s plug-in power adaptor (what power supply designers call an “off-line” supply, because it draws power off the line voltage) is a switcher too! Why doesn’t it hiss? Well, this is what I’d have to take some measurements to confirm, but I’m guessing the switching frequency of the Apple product is matched to noise rejection circuits in the power input or our audio output circuitry of a MacBook. The switcher in the HyperMac battery either switches at a different frequency that bypasses the MacBook’s filtering, or its noise is just louder. I could be wrong about this, and I don’t mean to cast aspersions on a great product. However, the headphone hiss is certainly real, and this is a decent hypothesis, easily strengthened with some simple measurements.

Which I hope to do soon. In the mean time, it’s easy to knock this noise down below audible levels. Enter the HyperMac user’s best friend, the ferrite toroid:

Ferrite toroids are a beloved hack of noise-hating hardware designers everywhere. They don’t deal with the noise problem at its source, but they do stop it from spreading. With a 19mm internal diameter toroid from DigiKey, I was able to wrap the HyperMac’s power cord through it several times.

With this in place, I am no longer able to hear a hiss in the headphones. Your mileage may vary, but this hack has no choice at least to help a little bit, plus it looks kind of cool. With this hack in place, you have no excuse not to have a HyperMac battery. Let me know how it works for you!

UPDATE: a reader asked offline if the toroid was a concern near non-solid-state hard disks. The answer is no, since it’s not a permanent magnet by itself. It’s a ferromagnetic material with high magnetic permeability, but on its own can’t harm your hard disk or any of those 8½” floppies you’ve got lying around.

Back when I wrote firmware for a living, every project had an exciting phase in the middle which we called “bringing up the board.” Bringing up the board consisted of getting a fresh, chemical-smelling new circuit board from a short-run manufacturer, applying power to it, and attempting to take control of it with software. It sat neatly in between a very waterfall-ish design and coding phase at the beginning and a very deathmarch-y integration and test phase at the end.

Bringing up a board requires intensive, cross-disciplinary debugging in which very few abstractions are of any use to the engineer. Rarely do enterprise software developers think about things like reset vectors and fetch-and-execute cycles (much less voltages and currents), but these are the stock in trade of the firmware developer working with a brand new hardware design. The phase is full of the seemingly intractable problems and contradictions that normally attend test-last debugging. Inevitably, at least once on each project, some impossible condition will arise in which the engineer knows he is flipping a bit in a control register somewhere, and he knows the corresponding digital output pin is driving a high impedance, but somehow under such-and-such conditions the trace on the oscilloscope barely wiggles when it should be banging back and forth between five volts and zero. He’s sure of everything else in the system, he knows he’s got the address of the control register right, he’s certain he understands the circuit the output is driving. There’s just no other option: Ohm’s Law must be wrong in this case.

Of course it never is. And while widely used, production-ready web frameworks like Grails are less reliable than fundamental laws of physics, they can probably handle trivial form submissions with aplomb. Of course, that still didn’t stop me from thinking Grails had a bug last week.

I had generated some scaffolding for a fairly simple domain class, and had begun elaborating on it in the way that any Grails developer does for a real-life application. The GSP code looked something like this:

<g:form controller="assessment" action="save">
  <g:each var="q" in="${questions}">
    <p><g:render template="question" model="[question:q]"/></p>
  </g:each>
  <div class="buttons">
    <span class="button"><g:actionSubmit class="submit" value="Submit"/></span>
  </div>
</g:form>

When I clicked on the submit button, I got a 404 error. I verified that AssessmentController had a save action, which it did. I bounced Grails, which I was running in dev mode. Still no love. I banged my head against this for a while, unable to believe that I couldn’t get a form submission to work. Was it some strangle UrlMapping oddity? Was it a problem with allowed HTTP methods? Nothing made sense.

So I decided to bypass the Grails GSP tags and code up a form myself. It looked like this:

<form action="/app/assessment/save" method="post">
  Question 1: <input type="text" name="question-1"/>
  Question 2: <input type="text" name="question-2"/>
  Question 3: <input type="text" name="question-3"/>
  Question 4: <input type="text" name="question-4"/>
  <input type="submit" name="Submit" />
</form>

That worked perfectly! My next task was to figure out what was different between the two requests. Ever a fan of the big hammer (my favorite debugging tool in my firmware days was the oscilloscope), I broke out HttpFox to see what was happening on the wire.

I saw, as you might expect, two apparently identical requests that looked something like this:

No differences in headers, request URL, or anything that might affect how the request would be routed to an action. Everything was the same until I looked at the POST Data tab. The version of the form that was built by the Grails tags looked like this:

while my custom form generated these parameters:

The _action_Submit vs submit difference should have tipped me off right away, but it didn’t. I had simply forgotten that Grails is capable of doing request mapping through the submit button, so I continued plugging away at the code for longer than I’d care to admit. I knew at this point that there was some kind of internal processing of this form parameter going on, and was ready to resign myself to spelunking in the source to figure out what it was. Since this was such a basic operation going on here, surely this had to be a bug in the framework excited by an as-yet-undetected subtlety in my form markup. Surely. Then it hit me: the form code I was debugging used <g:actionSubmit>. Shouldn’t that be <g:submitButton>?

Sure it should, if g:submitButton is all you ever use. I’ve never been a big fan of scaffolding—a conceit I have long suspected is to my detriment, and one I am currently in the process of reforming—and I had never had occasion to become familiar with g:actionSubmit. What that magical tag does is allow you to include multiple submit buttons inside a single form, each of which targets its own action within a given controller. Great idea, and great tag. And an epic failure if you’re trying to accomplish mapping through the tag and ignore the submit button tag’s parameters altogether.

I’m tempted to conclude that the moral to the story is to know how your web framework accomplishes simple tasks like form submissions, even if it throws a few nice features your way to spice them up a bit. And there is nothing wrong with knowing this; in fact, it’s a good trick if you can do it.

The real lesson, however, is about debugging. Ohm’s Law is never, ever, ever wrong, and when you sit down with ohmmeter and oscilloscope and proceed to prove that it is, all you’re doing is establishing that your mental model of the problem is badly off-base. Grails, like any web framework or well-used public API, sometimes is wrong—it is not a fundamental physical law—but public releases probably aren’t wrong about trivial things like form submissions. If you think you’ve got a bug so obvious that someone had to have caught it in the past, then somebody probably did. The bug is probably with you, either trivially in your code or even in your debugging process itself. In the heat of the chase, it can be difficult to remember this, but how often is the resolution to the story actually some complex subtlety that takes hours to explain? Sometimes it is, but most of the time you’re just using the wrong tag. Looking for the obvious is probably going to pay off well in advance of a deep dive into the code. Or, for that matter, a reconsideration of classical physics.

I’m building some simple .NET web services in a VMWare Fusion VM running Windows XP. I’d like to consume those web services from Grails code I’m developing on the host OS, which is a Mac. The easiest way to hit IIS in the VM is to switch the network connection to bridged mode, as shown here:

I had been doing this happily for a week or so, when suddenly yesterday afternoon it quit working. I tried to put a new VM into bridged mode, and I got this unhappy dialog box:

The guest OS (Windows XP) was insisting that the network cable was unplugged on my virtual LAN adaptor, and I had no way to hit my .NET services from the glorious host OS. Googling around a bit suggested that this was a problem when the Mac had more than one network adaptor configured, but that made no sense: I always have two network adaptors (wireless and wired), and have done bridging successfully while using one or the other, and sometimes while both are recognized by the OS as live options for network traffic.

Skipping to the end for your convenience, it turns out the problem was with the VPN. I can use bridged networking as much as I like, just as long as the Mac is not connected to the VPN. Even if I try to establish bridged mode while disconnected from the VPN, then connect to the VPN afterwards, it still disabled by bridged network adaptor in the guest OS. Host VPN and bridged guest simply will not coexist.

Which is great and all, but the .NET services I’m running in XP need to connect to a database server available on the client’s private network, so without a VPN, I’m sunk. The happy ending is that I can establish a VPN connection in the guest OS—in Windows—while the Mac is happily VPN-free. This still disables some of the tooling I rely on for efficient development, but it’s as good as it’s going to get, and ultimately, it’s workable.

Two weeks ago I finally succumbed to the temptation to order a Kindle. Availing myself of my Amazon Prime subscription—a service which may now find itself obsolescent—I had the device in my hands last Wednesday. My goal wasn’t just to have a new and more convenient way to read, but to figure out whether the Kindle actually delivers on that promise.

It came out of its elegant, Apple-like packaging with an image on its screen—not something you expect from a powered-off device. Having seen a Sony ebook reader before, I expected the Kindle’s screen to look fake, and it did. It was as if someone had cut out a piece of printed paper and glued it on the front of the unit. Its somewhat odd power switch worked fine, and it turned on after a few seconds. It was easy to connect it with my Amazon account (I don’t even remember the process, in fact) and wirelessly browse the Amazon store through the 3G “Whisperlink” connection. My first book purchase, which I made from the web site on my laptop, appeared on the Kindle quickly.

My first impulse, and the first impulse of several other new users who got their hands on it, was to tap the screen. I expected to swipe to turn pages, and I presumptuously expected a multi-touch gesture to bring up a coverflow-like view of the pages through which I could scroll by swiping. Somehow I doubt my reaction is unique, at least among iPhone users. At first blush, it seems imperative that future generation devices support a touchscreen.

Actual reading is quite pleasant. Text is almost suspiciously crisp and passive-looking, just like a printed page. The digital paper display is famously slow to update, reminding me of laptop screens from twenty years ago. This makes interactive functions like scrolling through menus, navigating tables of contents, or shopping in the store somewhat frustrating (and it would render my expected touchscreen functionality all but useless), but is easy to overcome in actual reading. I soon learned to anticipate the page refresh delay by pressing the next page button while my eyes were somewhere near the beginning of the last line of text on each page.

Later, I pushed a few of my book purchases to the Kindle app on my iPhone. There is an immediately obvious difference in the feel of reading on the iPhone and on the Kindle. On the iPhone, the expected touch gestures work. There’s still still no multi-touch coverflow interface, but there is a draggable slider that quickly scrolls to any location in the book. The book seems more interactive, and has a massless quality to it. Compared to the Kindle, the iPhone screen itself looks alive. You can quickly be anywhere in a text almost as easily as flipping the pages of a bound paper book. The same text on a Kindle has some random access capability through the table of contents and the search function, but otherwise the slow speed of the display rewards sequential, page-after-page reading.

In other words, reading the Kindle is more like a reading scroll than a bound book—a scroll with a search box.

So my first reaction is positive, and I’m going to continue favoring it for the delivery of new books when possible. I’d like to use it for several different kinds of material (i.e., fiction, technology, theology, article-sized works, etc.) to get a sense for how the different reading habits associated with different texts work on the device. My larger question, which can only be answered over the course of months, is how the new form will alter my reading habits and my perception of the texts themselves. Even if, pace McLuhan, the medium isn’t identical the message in a strict sense, the message is clearly shaped and constrained by the medium in important ways. It seems clear that ebook readers will be a big part of the future of text, so understanding the new form might be a good plan.

I had a great time speaking at DOSUG last night on Talend Open Studio, the eponymous open-source ETL product by the French start-up. I realize ETL doesn’t exactly capture most developers’ imaginations the way cool dynamic languages or cutting-edge web frameworks might, but I think we had fun. The attendees were engaged and had many good comments and questions. I suspect at least a couple of them know the ETL landscape a lot better than I do, but they seemed happy to know there’s a credible open-source product in the marketplace.

I had two main examples to show. The first was a simple (and contrived) transformation of an OPML file into an Excel spreadsheet and a text file. The Excel file contained a list of the names and URLs of all my feeds in a human-readable format. The text file was supposed to contain a list of the unique link types (hint: they were all “rss”), but that part of the demo actually didn’t work properly due to some fault of mine. This being an occupational hazard in live coding not to be dwelt upon when your audience is patiently waiting, I dropped it and moved on.

After the first demo, I talked about basic data warehousing principles a little bit as outlined in The Data Warehouse ETL Toolkit by Kimball and Caserta. This kind of thing is tricky with a diverse audience, because the speaker runs the dual risks of insulting the informed and not informing those new to the subject. Brevity is usually the best policy.

The second demo showed a real-life transactional schema from a start-up I had been involved with a few years back. (The present custodians of the data were kind enough to share a sanitized copy of it with me for this demo.) I showed a few transformations of transactional data of varying levels of complexity into the relevant fact and dimension tables, including some look-ups from external text files and one or two interesting joins on the transactional inputs. Mind you, I didn’t proceed to show any neat analytical tools running on the newly minted warehouse, but the OLAP world is your oyster once the ETL job runs to completion. Relatively speaking.

A Talend job showing the creation of an order line item dimension.

I was frank about Talend’s weaknesses. There are a few tutorial screencasts on the web site, but other than that I don’t consider the getting-started documentation to be particularly smooth. The Business Modeler is a confusing addition to the product—a third-rate drawing program that distracts the newcomer and adds no discernable value to the suite. The lack of credible Mac support is as disappointing as it is surprising, given that the tool is entierly Eclipse-based. However, I still see the tool as an option very much worth evaluating if you have needs in the space.

All in all, I’m happy with how the talk went, and I’d like to put the tool to use in a production environment at some point soon. I hope to be able to make a few upgrades to the talk and give it at some other local groups as the opportunity arises. I’ll update with a link to Slideshare as soon as I get the deck upgraded.

Another thing: as threatened on Twitter, I did wear all black to the talk. And yes, Matthew McCullough did play a Johnny Cash song just before the meeting got started. See his post on the event for another account of how it went.

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.