Muness blogged a photographic introduction to the Relevance mothership, and Glenn Vanderburg went all meta on us and asked what we could learn from comparing the books in active use on the desks to the less fortunate books relegated to use as monitor stands.^§

Wired? Erlang.
Expired? RMI.

Read the rest of this entry »

With all the recent fuss about the game-changing advantages of Git and distributed version control in general, it would be easy to overlook what Git does for deciding whether (and when) to use version control for a given task. Sure, Git makes non-linear development a breeze, it manages large projects with uncanny efficiency, and we probably can’t even fathom yet just how transforming github is going to be for open source. But, if you look closely, there’s something worth noting way before you create your first branch, before your project is even thirty minutes old, and well before you’re ready to share it with the community: git init is so pleasantly simple, you’ll never again think twice about “whether it’s worth it” to throw something into version control.

As someone who had the, um, “joy,” of working with CVS, SourceSafe, ClearCase, and other SCM “solutions” that made you wish you were instead just using NTFS, I definitely appreciate what SVN did for the state of version control systems. Nevertheless, there were countless prototypes, drafts, experiments, etc. that I talked myself out of storing in SVN. The conversation typically went something like so: “Do I really want to create a new repository just for this experiment? Should it go in my local repo, or does it belong up on the shared repo? Should I bother setting up the standard dirs for trunk, tags, and branches? Maybe I should just add it to a grab-bag repo for now? Nah. Forget it. It’s not worth the trouble yet.”

Git removes many of those decisions altogether, and (in true agile fashion) it allows me to defer the others until they actually matter. I can “execute, build momentum, and move on.” Let’s say I’m halfway through a blog post, and I decide that I want to try taking it in a different direction. No problem. Drop it in Git, and experiment away…

So while you’ll continue to hear people (myself included) champion Git’s importance as a solution for team-based or community-based development, its ability to give you instant, no-questions-asked version control is enough to earn a place for Git on your system, even if you’re the only one who will ever see your work.

And Git’s agility doesn’t stop there. From branching on a dime, to the oh-so-beautiful stash, to the ability to rework past commits, Git reminds me that decisions are temporary. Or, to quote Ryan Tomayko, “Git means never having to say, ‘you should have.’”

–

Be sure to check out Rob’s post for a whole host of Git-infused goodness.

Rob dared me to fire up my favorite shell and jump into the game. Imagine my disappointment when I was greeted with this bummer of an error message.

Hmm. No dice. OK, on to my second choice.

The result? A few well-known friends and some that likely deserve a bit of elaboration.

• m is an alias for the mate shell command for TextMate
• mman is that handy TextMate man page viewer we talked about recently
• The one that’s bleeped out (i.e., **) is an alias that takes me straight to the source dir for my current client project
• cap1 is, um, a reminder that deprec2 is gonna be a nice upgrade

• Geertjan Wielenga suggests the first (and only) Java closure solution that makes any sense.

• Wait for it. Wait for it. Are you serious?! Damn, that’s cool!

• As always, Alan Hoffler offers some welcome advice “and stuff like that” on using words that add nothing to your message.

• Rails goes Git. Sweet! Who’s next?

• Multi-touch is so 1984.

• “Working for oneself, or at least for a small group, is the natural way for programmers to live.” Well said. And if you disagree with Paul Graham, watch out; you’re being graded.

Andres Almiray interviewed me this week for the Groovy Zone. We cover a breadth of topics, including:

• Just how far Grails has come in the past two years
• Why the GORM DSL likely obviates previous mapping techniques
• Groovy as a gateway drug to more and better developer testing
• Why Grails testing infrastructure improvements deserve top billing in Grails 1.1
• Something called Rails
• New testing-related developments in the Groovy ecosystem

For all that and more, check out the interview at Groovy Zone, a new(ish) and hoppin’ community for Groovy and Grails news.

(Did I mention that we discuss testing?)

Many thanks to Andres and DZone for the interview.

Marcos Fábio Pereira has just published a step-by-step guide for using the slick JasperGrails plugin in the Racetrack application (originally developed in Getting Started with Grails). The tutorial includes examples of generating a PDF of all the races in the app, exporting an Excel spreadsheet listing all the registrations for a race, and the impressively concise bits of code necessary to get this new tastiness up and running.

Nicely done, Marcos!