Bag of Methods Module and Grep-driven Development

Always looking for more concise ways to express ideas, I’d like to present two terms for your consideration.

BOMM |bäm| (acronym)
Bag of Methods Module
An anti-pattern for "sharing behavior" or "separating concerns" of an object. In practice such modules often contain code that is related in name or function, but lacking a cohesive purpose. See also: GDD.
GDD (initialism)
Grep-driven Development
A software development process that relies on searching full source code to find usages of methods and deduce intended behavior of a piece of code. Often caused by lack of coherent and cohesive design. See also: BOMM.

Thanks to fellow Highgroover, Andy Lindeman, for helping me to finally define these terms. Or at least, refine them.

Sensible Testing is About Sensible Design

If you’ve not yet seen Justin Leitgeb’s GoGaRuCo talk, Sensible Testing, go check out the slides. I hope the actual talk is posted soon; I’m sure it’s more rich and full of context.

Overall I agree with most of Justin’s points. However, I get the feeling that he, like many folks, approaches testing as a method for verifying the correctness of code. As I understand the thesis, CUPID is to testing what SOLID is to design.

While I’m not opposed to laying down some names and concepts to improve the state of testing, I don’t believe testing should be the goal. It’s not about testing. I believe testing is a tool to be used in guiding your design.

Read on →

The accepts_nested_attributes_for Un-Solution

Merry-Go-Round Why does Rails’ accepts_nested_attributes_for approach always feel so darned wrong?

My suspicion is that it feels wrong because it likely is wrong - or at least it is likely the wrong tool for the job.

An example

An accounting of a recent ride I took into the accepts_nested_attributes_for merry go round.

In order to create a Message, I have to first create the Conversation it’s a part of.

This sounds like an explicit workflow, so I’ll model it that way.

… hours later …

FFFUUU, this is too complicated! There must be an easier, more Rails-y way.

I know, Conversations can accepts_nested_attributes_for :messages. Brilliant!

… hours later …

FFFUUU, this is too complicated! There must be a simpler way.

I know, rather than shoehorning this into an overly-coupled mess I’ll model it as an explicit workflow!

FML.

Remember, easy is not the same thing as simple.

image via: lolitanie.com

From Testing to Test-First to Test-Driven

When I started writing tests, around 2005, I was stoked just to have the tests.

When I started writing tests first, around 2006, I was excited because I was Doing The TDD.

A couple of years later I found that writing tests was getting really painful. Painful because they were so damn hard to set up, and painful because I had to wait too damn long (on the order of 10-15 minutes) for the test suite to run. I reacted to the pain by changing how I write my tests; I discovered mock objects. My tests got faster, but they were still painful.

A realization

In 2008 I was talking with Corey Haines about test pain, object-oriented design, and “listening” to the former to influence the latter. Scott Bellware also contributed much insight, forcing me to really think about what I hoped to gain from writing tests.

Those conversations help to crystallize it for me: the root cause of the pain was not the tests, but the design of the code under test. I had been doing test-first development, not test-driven design.

In the years since I’ve honed my technique for driving design by listening to tests and I continue to seek out the ideas and experiences of others.

The Ruby and Rails communities have accelerated this path for many. I would say it’s not uncommon for new folks to get started where I was in 2005 or 2006. What’s more exciting is the growing numbers who are starting to feel some pain in how they test. The next step is to become more aware of that pain; lower your pain threshold, and then make it stop hurting.

It’s a journey

It was by no means an overnight endeavour. It literally took years of work for me to figure this out, and I’m I’m still learning. I hope by putting my experience out there, yours can be better, faster, MOAR!

Another Git Repository Visualization, Just for Fun.

I’ve created visualizations for Git repositories before – the one tracked a product from its first commit through launch. And while I still think there is some information and insight to be gleaned from such visualizations, the real reason I like to make them is… I think they’re neat.

To celebrate launching the latest incarnation of VersionOne, I made another visualization! This one tracks all changes made in our Git repository that occurred between our last major release (in late February) right through the very last commit that made it into the Spring 2011 release.

Wow… that really sounded like a sales pitch, didn’t it? I hate sales pitches!

Enough of that. Enjoy!

Git Pull with Automatic Rebase

To rebase, or not to rebase - for me its not really a question. I generally prefer a clean, linear commit history. Why? Because merge bubbles make history confusing, noisy, and can break git bisect.

Y U NO REBASE!?! Don’t believe me? Check out the pretty log to the right. See all those merge bubbles in there? Eww!

The Why?

The workflow that caused those merges was as follows:

  1. git pull (to bring local up to date)
  2. hackity-hack
  3. git commit
  4. git pull
  5. git push

By default git pull will fetch any new commits from the remote, and then merge any local changes in, resulting in the merge bubbles.

Read on →

An Io Language Vim Plugin

Who here doesn’t enjoy a little color in their life? I know I do, especially when used to highlight the syntax of a language - as anyone who’s been around me while downing a few pints can attest! Io Syntax Highlighting in Vim

Learning, Io, and Vim

In an attempt to feed our insatiable desire to learn, a few of us at VersionOne are doing a book club on Seven Languages in Seven Weeks. We’re currently working on chapter 2: Io. My current favorite editor is Vim. I wanted syntax highlighting for Io, in Vim.

I found a decent Vim script to get Io syntax highlighting, and then wrote a quick ftdetect script to set Io-related files to use the Io syntax. The resulting vim-io plugin is currently embedded in my dotfiles on the GitHubs, but if there’s interest I can pull them out into a standalone plugin.

Grab it, enjoy it, fork and improve it!

Caps Lock is Dumb; Make it Useful

I’ve long thought that Caps Lock was quite dumb. Yes, I’m sure there is some archaic reason it exists, but the truth is I don’t care. I don’t find it useful and am annoyed that it’s taking up valuable room on my Home Row. The more I use Vim the more angry I get at the Caps Lock key.

Making Caps Lock Useful, on The Mac

I long ago remapped Caps Lock to Esc on my Mac - which worked great for TextMate. However, these days I spend the majority of my time in Vim or Zsh (in Vim mode) where I’d much prefer to have Ctrl on my Home Row. Remapping Caps Lock to Ctrl is trivial on OS X; it’s baked in via System Preferences > Keyboard Preferences > Modifier Keys.

Read on →

A First Step to Better User Experience: Thinking Like a Human

As we strive to build more humane user experiences it is important to not only consider what data to, or not to, show, but also how we present that data.

An example from our recent Conversations feature is the date and time at which portions of a conversation take place.

Human-friendly date and time via jquery.timeago

Notice the two highlighted areas. The tooltip shows fully-formatted, and much more precise information, with the “less than a minute ago” text being a more fuzzy, human-friendly presentation of the same data.

There is no question that the precise data is valuable, but when it comes to human users of a system, it may not be the most consumable form. The full-fidelity information is still available to the user who cares to engage the application, when he cares to engage it.

Whether its fuzzy dates and time, or using avatars instead of user names, or any number of other examples, the point is to think about the human experience when designing for, well, humans.

A Handful of Git Workflows for the Agilist

A few months back I gave little talk on the darling SCM tool of the Open Source world, Git. After the conference, the organizers asked for a copy of the presentation materials I’d used - something I usually find little value in as the content of a discussion is far more than just the collateral used.

At any rate, I obliged, sent off a PDF, and have opened the talk up for others to use and improve. You can find the source (Keynote presentation, images, etc.) on GitHub. Fork and modify the talk to your heart’s content. ♡

Oh, and the PDF is there too.

Enjoy!