puts Blog.new(”nonsense”)

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.

• More evidence that 100% test coverage is just a good place to start.

• And here I thought perhaps it was finally time to drop BASIC from my resume. ^§

• Dave Klein takes on a gnarly Oracle schema using the Grails ORM DSL. If you’re dying to see some XML or annotations in use, then well, you need help, and this tutorial simply ain’t for you.

• Git repo containing the complete Rails source code and it’s entire revision history: 21.9 MB. SVN checkout of the current Rails source code with no history: 23.8 MB. Convinced yet? ^‡

• Safari 3.1 hits the street, now with more cowbell marginally better dev tools. Oh well, it’s still feels like the best fit for day-to-day browsing, but it’s got a long way to go if it’s ever gonna compete with Firebug for some real web developer love.

–

^§Link courtesy of Rob Sanheim.

^‡Link courtesy of Stu Halloway.

In the spirit of Andy Glover’s Weekly Bag and Bill Dupre’s frequent batches of Whatever, herein lies the first installment in a (sure-to-be-sporadic) series of Noteworthy Nonsense.

• iPhone web app authors rejoice! (Yes. You read that right. Web-app authors.) Test your web apps using the official iPhone simulator. (And, oh yeah, you can go native now too…but the lack of RubyCocoa support is a bit of a downer.)

• A plugin that lets you run Struts 1.x code inside a Grails app? Yeah, I cringed too, but this will surely be a welcome migration path for those folks trapped in the land of *.do.

• Are SVN users suffering from the Blub paradox? Linus pulls no punches in offering up his take on this matter.

• Dan Benjamin’s back with the Leopard edition of his definitive “how-to” guide for rolling your own installation of Ruby, Rails, and friends.

• The last time Glen Smith declared a month o’ Grails, he showed the community just how very much is possible with merely an hour a day. Now Glen’s at it again, but this time it’s MockFor(March). If history is any indicator, expect Glen to blaze new trails in the land of Grails unit testing. Glen: It takes GUTs, but I’m rootin’ for you!

• Speaking of good unit tests, Jay Fields announced a new version of the expectations gem, complete with a healthy dose of example code. One expectation per test? Saying “goodbye” to cumbersome test names? Jay’s onto something here.