puts Blog.new(”nonsense”)

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!

• 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.

Navigating through man pages in a terminal window doesn’t exactly rank as a highlight of this developer’s day. The experience feels like 1971 for a reason, and that means of interaction just leaves something to be desired. Perhaps you could make the argument that A) people that read man pages don’t rank humane interfaces as a top priority, or that B) I could spend more time mastering the ways to navigate via less (the default man page browser in OS X). But, believe it or not, apparently I’m not alone in my crazy desire to consult man pages outside of the terminal. So with web-based solutions, PDF generators, and full-blown apps dedicated solely to “manning up,” where should we turn? Queue The Pragmatic Programmer for some welcome words of wisdom:

Use a Single Editor Well

The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

For me, that editor is undoubtedly TextMate. I already spend most of my day in TextMate, be it for coding, blogging, editing wiki pages (and other Safari-based content), or sometimes even writing e-mail. So, if I can use TextMate to find my way around a man page, that’s an all-around win.

Goal

While working in the terminal, be able to quickly open a man page in TextMate.

Making it happen

First, install the mate shell command. (Even if you have no interest in viewing man pages in TextMate, this command is simply indispensable for anyone that even occasionally ventures into the land of the terminal.)

Now that we have access to TextMate from the command line, we can assemble a quick script to get us the rest of the way toward achieving our goal. I keep all of my custom scripts in a .scripts directory that I include in my path, so I’ll define this handy scriptbaby in a file named mman (for “mate man”) in that directory.

And once we drop a bit of Unix-fu into that file, we’ll be good to go.

To see it in action, just use mman anywhere you would have previously used the vanilla man command.

Kicking it up a notch?

That approach has served me well for several months now, but in the course of writing this post, I came across an associated TextMate bundle that some folks may find helpful as well. The TextMate Man Pages bundle offers some (minor) syntax highlighting, the ability to open a man page from within TextMate, and the ability to use Command + Shift + T (i.e., “Go To Symbol”) to quickly find and access key sections of the man page by name.

Now go forth and devour some man pages already.

Want to know more about just how easy it is to contribute to the many open source projects that you use day in and day out? The Refactotum series is dedicated to showing you how. Coming up at RailsConf in May, Stu, Justin, Rob, and I will be offering up another round of Refactotum open sorcery.

What are people saying about Refactotum? The 2GX crowd was pretty psyched…

Showed how you can contribute to open source even if you don’t have a lot of time.

Cool. Time? What’s that?

Very helpful. I’ll definitely follow up by contributing to open source projects.

Right on.

Explaining how to contribute to open source is something that is not usually covered and needs to be taught and evangelized.

And even when the network didn’t cooperate…

It turned out to be a giant “pair” programming exercise instead of individual programming and this turned out to be MUCH better. Some of the ideas discussed were really intriguing.

Grab your seat now before they’re all gone. Hope to see you there!

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.