Rails has a history of co-opting names, as happened when the ActiveRecord library used the active record pattern name. A similar co-opting has happened with the MVC pattern wherein many believe Rails is an example of the MVC design pattern. In truth, it’s probably closer to MVC Model 2… but I digress.

Model View What’s-that-now?

MVC stands for Model, View, Controller. In Rails-land we know what the Controllers are. And while we don’t have Views in the way that MVC meant, we do have view-templates, and we call those our views. The Model is meant to be all the things it takes to model our problem domain. As applied to Rails, the Model seems the most misunderstood/misused of the MVC triumvirate.

Rails gave us the app/models/ directory, a natural home for our model. Yet, that was also where Rails dumped all our ActiveRecord::Base-derived objects. Combined with the “Skinny Controller, Fat Model” mantra of 2006-ish Rails-land, that directory had grown full of bloated, tightly coupled, low cohesion ActiveRecored::Base-derived objects. Our model!

Models Too Fat?

Eventually we realized that shoving all those disparate concerns into a single class was a Bad Idea™. There was a movement afoot to thin down our now overly-fat models. So, we re-learned some forgotten lessons and the use of POROs became a Good Thing™. We needed to break our domain models down into smaller, more cohesive objects, but we had a new problem. Where to put these new files?

As Rails had reserved app/models/ directory for ActiveRecord::Base-derived objects, we had to find a new home for those POROs. As luck would have it, Rails had given us a lib/ directory, and that thing was basically deserted. We began breaking up our model and littering it amongst the app/models/ and lib/ directories.

Our model had become more loosely coupled, with more cohesive parts, but it wasn’t living together. Why are we forcibly segregating the ActiveRecord::Base portions from the rest of our model? If it’s a single domain model, why doesn’t it live together?

These days I put all the domain-specific objects into the app/models/ directory. I reserve the lib/ directory for things which could ostensibly be gemified.

So. Many. Files. So Many Boundaries.

I’ve heard grumblings that having all the domain model living together results in a lot of files in the app/models/ directory, making it hard to organize and navigate. To this I say, YES, it does.

However, I suspect that is a sign of another problem. To wit, do you actually have multiple domains emerging, which could perhaps be broken out into discrete apps? If that is the case, make that boundary explicit and break out a new application!

So long as those other domains are small or emerging it seems excessive to split them out into their own apps. So, what do we do? Why we segregate them with internal domain boundaries, of course!

An Example Boundary.

A lot of apps have a search feature (or set of search features). Search is a whole domain on its own, and often not germane to the primary domain. Pull all search concerns into a namespace, Search::. To help with organization, put all files to do with search in a directory of their own. For example, app/models/search/, app/controllers/search/, app/views/search/, etc…

With just a few changes we’ve reclaimed the app/models/ directory, better organized our files, and defined some new boundaries within our code base. Ah, much better.

Deep Greens image courtesy of Brett Jordan.

Rails-era web apps have some great tooling and deliver a pretty nice development experience. The shift toward rich client-side web experiences has lead to some great tooling that makes for a 1st-class web development experience.

A no man’s land

Between these two approaches lies a no man’s land. The tooling and techniques are focused largely on either end of the continuum despite the large population of apps living in the middle.

For too long we’ve resorted to sprinkling JavaScript onto our Rails-era web apps in an attempt to inch toward the rich and dynamic experiences we see at the other end of the spectrum. However, not every application needs a full rich-client experience. Often a Rails-era web app is mostly enough, except we require some dynamism in portions of the application. But sprinkling on more JavaScript only leads to larger tangles of costly and inflexible code. What we really desire is that rich-client 1st-class web development experience paired with our 1st-class Rails-era web app development experience.

For example

Rails is a tool I use regularly, and it’s often the first tool I reach for when building those Rails-era web apps. My friends at Test Double have made great contributions to creating a great web development experience for fat-client JavaScript applications with Lineman, especially when paired with frameworks like AngularJS or Ember. What I long for, and believe is both needed and achievable, is a happy union of these two approaches with tooling that supports them working together.

Sadly I don’t have an answer for you. At least not today. But I know that folks are working to enrich the middle ground, to reduce the frustration and friction felt when using tools like Rails while also striving to build sensible and coherent fat-client JavaScript apps with tools like AngularJS and Lineman.

If you’re working to improve the middle ground, or you find yourself living there, please share your thoughts, experiences, and advice so that we all might learn and improve, together.

To delete local branches which have alread been merged into master:

$ git branch --merged master | grep -v "\* master" | xargs -n 1 git branch -d

You can omit the master branch argument to remove local branches which have already been merged into the current HEAD:

$ git branch --merged | grep -v "\*" | xargs -n 1 git branch -d

Breaking it down

We start by getting a list of local branches which have already been merged into the current branch (i.e. HEAD)

$ git branch --merged

  add_new_user_gravatar_links
  assign_unique_key_to_uploads
* master
  remember_the_last_activity_per_user
  update_kaminari_to_thread_safe_version

We then pipe that to grep to match on the "\*" character, inverting that match via -v to get all merged branches sans the current one.

$ git branch --merged | grep -v "\*"

  add_new_user_gravatar_links
  assign_unique_key_to_uploads
  remember_the_last_activity_per_user
  update_kaminari_to_thread_safe_version

Finally we pipe that list in to xargs so we can strip apart the input and pass it on to a new command. We use -n 1 to ensure at most one argument is taken from the input to be passed to the invocation of the new command. The resulting commands that xargs will invoke are effectively

$ git branch -d add_new_user_gravatar_links
$ git branch -d assign_unique_key_to_uploads
$ git branch -d remember_the_last_activity_per_user
$ git branch -d update_kaminari_to_thread_safe_version

Pulling it all back together, we have

$ git branch --merged | grep -v "\*" | xargs -n 1 git branch -d

Deleted branch add_new_user_gravatar_links
Deleted branch assign_unique_key_to_uploads
Deleted branch remember_the_last_activity_per_user
Deleted branch update_kaminari_to_thread_safe_version

And there you have it. Go forth and clean up!

BOMM |bäm| (abbreviation)

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.

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.

An example

I realize that it’s unfair to pick on sample code used in talks, but “Problem 2: Stubbing instead of mocking” provides a great illustration. Here the author claims that we too often stub where we should be mocking. He gives the following snippet:

Firstly I had to get over the use of the old RSpec 1.0-style #stub! and the overly verbose #and_return syntax. After resetting my brain I quickly realized the test was awkward. I re-read it a few times and then asked, “why stub, or mock for that matter, methods on the object under test?”

A design issue emerges

This is a design issue! The BalanceCalculator is doing too much work. This is the “S” in SOLID - the Single Responsibility Principle. The friction of this test suggests that we need to adjust the design.

For example, we could wrap the account info and account type into a cohesive object to be passed into the calculator.

To stub or to mock?

Forgiving that design issue for now, let’s get back to the author’s point - should we mock or stub those methods?

The methods in question are queries. The BalanceCalculator presumably uses the results of those queries to do its work. So why do we need to set an expectation that we should call those methods? After all, if we don’t call them we’ll not have their resulting values. Therefore we won’t be able to do the work. Therefore the test should fail. Right?

And if we don’t call those methods and the test passes, then they neither need to be mocked nor stubbed; they are unnecessary.

So, to stub or mock… how do we know when to use which?

My heuristic is that stubs are for queries and mocks are for commands. In a very generic sense I’m talking about Command-query separation applied to testing.

It’s all design

In the end nearly everything we do is design in some sense. Testing is no exception, and is in my opinion a much larger part of the design of software systems than it is given credit for. Or at least, I believe we should be striving to make it so.

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

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 other fast test fanatics.

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 both happy and proud to say that I’m still learning. I hope by putting my experience out there, yours can be better, faster, MOAR!

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!

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.

A better approach

I typically use the same workflow as above with one tweak. Rather than git pull I use git pull --rebase. The --rebase option will fetch the remote commits and rebase your commits on top of the new commits from the remote. This is the “re-writing” of history folks often talk about.

Make it better, automatically!

You can tell git to use rebase, rather than merge, in one of two ways, depending on your situation.

1

$ git config branch.autosetuprebase always # Force all new branches to automatically use rebase

You can add the --global switch to have all future branches, in all repositories on this machine, behave this way.

1

$ git config branch.*branch-name*.rebase true # Force existing branches to use rebase.

Get more info

Be sure to check out the git man pages for more info on what those options mean and when you may or may not want to use them.

You might also want to check out my Git Workflows repository on The GitHubs where you can find a Keynote presentation (or PDF in the Downloads) explaining git rebase vs. git merge Complete with pictures!

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!

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.

Making Caps Lock Useful, on The Windows

To my knowledge, there is nothing baked into the OS that makes this easy, but there are a handful of utilities that will let you remap most keys. I opted for the Lo-Fi route - hacking the registry to remap Caps Lock to Ctrl.

To use it, just download/save the raw .reg file to your Windows box, and the run (double-click, whatever) it.

And there you have it. Good bye, annoying Caps Lock. Hello, useful stuff!

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

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.

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!

Why do merchants insist on making it so damned difficult for their customers to get the goods?

A few frustrating examples

Ever been to a sporting event where the beer vendor only accept cash, has no cash-register, and yet insists on charging a partial dollar amount per unit of booze? $6.65 for a beer. Really? Just call it $7 and make the math easy for everyone. Or have a cash register at each kiosk. Or, here’s a novel idea, start accepting plastic!

Need to renew your vehicle registration? Just do it online! But be prepared to spend an extra $5 for the convenience of, you know… actually giving them the money now rather than sending a check and them having to pay someone to physically handle the thing.

Two simple rules for making money

1. If you’re selling something someone wants: make it easy for them to give you their money!
2. If you’re selling something someone does not want: make them want it!

Unfortunately, the desire for visual representation is at odds with the high bandwidth flood of information we’re subjected to these days. Even if we manage to trim the overwhelming flood of information down to a laser-focused stream, it takes an immense amount of effort to make sense of it.

For example

For years the primary way we’ve looked at the activity or interaction within various source control management systems is via log files. Yep… plain, text-laden, indecipherable logs chock full of entries each a similitude of it’s predecessors.

However, thanks to projects like Processing there may be a change on the horizon. Using tools of their ilk we can build exciting new ways to see and consume the vast seas of data we’re drowning in. By visualizing the data we are able to discover new and interesting patterns, behaviors, and insights.

An example

The above video is an example of one such visualization I produced using Gource to analyze the Git repository of one of the product’s we’ve build at VersionOne.

For reference, each branch (line) is a different directory containing files. Each leaf (dot) is a file, with different file types (Ruby, JavaScript, C#, etc.) having different colors. Each contributor is represented by their name and Gravatar.  The colored lines that occasionally connect a contributor to a file are color coded to represent adds (green), changes (orange) and deletes (red).

A few interesting things this visualization leads me to think about are

• how much churn happens in various parts of the code base?
• where are we spending time?
• is new-feature work well isolated? (perhaps an indicator of composition)
• are there specialists within the team?

Do any interesting things pop to mind when you watch the video? Let me know by leaving a comment.

Now contrast that with how often we stop to think about the Whys?

Why are we being asked to solve fizz-buzz-thing; do we understand the motivation and context behind the problem, or are we fixated on how we’ll build the solution? Are we asking why a problem occurred, or are we merely focused on how we fixed it, this time?

Why don’t we ask “Why?”

Frankly, because we’d rather spend our time in the comfortable arena of how than venture into the sometimes uneasy realm of why.

She didn't want to know how a thing was done, but why. That can be
embarrassing. You ask *Why* to a lot of things and you wind up
very unhappy indeed, if you keep at it.
- Captain Beatty

Asking why often forces us to face the truth, and that truth can be uncomfortable. We need to have the courage to face those truths and coninue to ask why; we must have the courage to pop the why stack.

It’s only by asking why that we’ll gain the understanding, insight, and context necessary to effectively solve the problems we’re faced with, to grow, and to improve.

So, why are you reading this post? :)

Is that the whole story?

In short, I don’t think so.

I’ve long believed there was more to YAGNI than what had been canonically defined and was commonly understood. However, until recently I was never able to put my finger on what was missing.

While listening to an episode of Industry Misinterpretations I heard Kent Beck make a subtle point about the need to make progress being more important than the completeness of the thing you’re building at the point you’re building it. Lending from Kent’s insight and mixing in much of my own experience, I realized YAGNI is not about delaying building things until you need them; it’s that gaining real experience in the problem domain, while making concrete progress, is more important than trying to achieve a complete solution right now.

Do you think it’s too early to update the Wikipedia article?

Luckily our buddy Derick Bailey decided it was time to bite the bullet and start building some real Rake tasks that were special suited for building .net code. The result is Albacore.

Using Rake for .net IRL

I’ve been using Rake to be lazy for a while. And we, the VersionOne dudes & dudettes, have been using it to help automate our CI builds for over a year now. And just last week we started ditching much of our hacky-Rake-script inventory in favor of more concise, tested, and readable Rake tasks via Albacore.

During the migration I’ve run into a few small hitches here and there, but nothing that I couldn’t track down, write a test for, and fix within a couple of tomatoes. In one case I discovered an issue, called Derick to confirm, suggested a fix, and had a new Albacore Gem published within a couple of hours. Hawt!

Albacore already has a decent number of tasks baked in, and the list is growing all the time!

• AssemblyInfoTask - Generate an AssemblyInfo.cs file. Currently only supports C#
• ExpandTemplatesTask - expand template files with #{setting} markers, using YAML configuration files as the data
• NCoverConsoleTask - Run code coverage analysis through NCover’s NCover.Console
• NCoverReportTask - Check code coverage and get detailed reports through NCover’s NCover.Reporting
• NUnitTask - run NUnit test suites
• MSBuildTask - Build a Visual Studio solution (.sln) or MSBuild file
• Rename Task - Rename a file
• SftpTask - Upload a file to a remote server via secure FTP connection
• SQLCmdTask - Run scripts and other commands through SQL Server’s sqlcmd.exe
• SshTask - Run a command on a remote system via a secure shell connection
• ZipTask - Package your build artifacts into a .zip for easier distribution source data

Contribute!

As we move more and more of our custom stuff over I’ll continue to add features to Albacore, enhancing the great work the core team is doing. In fact, I’m already planning a NAnt task to help those folks in the process of migrating from an existing NAnt-based build script to Rake. Look for it soon!

Resources

• Albacore on GitHub
• Albacore Wiki
• OMG Rake! - The original post which first inspired many to use Rake with .net

The problem is the work we do isn’t structured. It is not deterministic. There is no grand blue print, process, nor methodology that we can follow to pay dirt.

We live in a chaotic and complex world that is itself continuously changing and adapting.

Software product development is a creative activity taking place in the midst of that complex and adaptive world. So doesn’t it make sense that we, as software developers, might benefit from admitting that we are indeed doing creative, unstructured, adaptive work? I sure think so!

Looking outward for inspiration

I’ve recently been looking outward to other creative professions and trades for inspiration and insights into how they work. One thing I’ve realized is that those folks spend an immense amount of time studying and seeking inspiration from the work of others both within and outside their own field.

For example, a musician doesn’t just sit in his garage all day, banging out albums. He listens to and is influenced by the music of many other musicians. An author doesn’t simply site down and write manuscript after manuscript. She spends countless hours reading the classics, studying the words, flow, and style of other authors. The same thing goes for painters, actors, architects, etc. And all of these people are constantly immersing them selves in works outside their area; musicians reading Hemingway, singer/song writers studying Salvador Dali, painters listening to Mozart, cats and dogs living together…

How arrogant of we programmers then to think that we won’t, or don’t, benefit from reading code written by - gasp - someone else!

Read, learn, and be inspired

In my experience we spend a great deal more time reading code than actually writing it. Whether it be the code you wrote just a few minutes ago or something you’ve inherited and are now maintaining, you’re reading it. Of course, that’s only considering the motive of reading code because you’re currently working with.

The greatest motivator for reading code is the opportunity it provides for learning and serving as a source of inspiration. Reading code exposes you to techniques, view points, styles, idioms, and algorithms that you may not have otherwise come across.

In my own career it was by reading code written in Ruby that I first started to develop an appreciation for beauty and aesthetics in code. It also opened me to new ways of thinking about problems and exposed many pains and frictions with the techniques I had been using to that point.

Where to start?

I realize it’s probably obvious, but I’m going to say it anyhow - a great way to start reading other’s code is to pull down an Open Source project and dive in. Of course, that’s not to say that all Open Source code bases are necessarily examples of great code' so you might also want to leverage your network to find examples. Or, use your Google-fu to see what others are reading. Or maybe check out:

• Katacasts by Corey Haines and Chris Parsons
• The Weekly Source Code series by Scott Hanselman

At any rate, I have a few points I wanted to throw out there; most of them basic and mere reiterations of the words of others, but I’m gong to do it anyhow!

The question at hand

I would encourage you to go read the full thread (it’s a quick read… 4 minutes, tops!), but knowing many of you are lazy like me, I’ll reprint Jon’s original question here.

Again, please go read the full thread so you have the full context.

Whenever I tell people about StructureMap (or using DI in general), I mention that two of the benefits are that (a) StructureMap will create objects and all their dependencies for you and (b) it enables you to fake out the dependencies in a test.

Why do we need constructor injection to do this? I can call `ObjectFactory.GetInstance()` anytime I want and it will work. And I could leave SM configured for my tests and call `ObjectFactory.Inject()` to stub things out.

So theoretically, I wouldn't even need constructor injection, right?

Let’s get the jargon down

To be clear, Jon proposing using Service Location rather than Dependency Injection.

While Service location is better than poor-man’s DI, using it as suggested above is still introducing a high degree of coupling as all of these classes now have an opaque and highly concrete dependency on the container. This is effectively creating a new form of Global. Eww!

The key to using Service Location within new code is to keep it tucked away in the deepest, darkest corners of your infrastructure. For example, if you’re building something on the asp.net mvc stack, you might use Service Location within a custom IControllerFactory to create each of your controllers.

If you’re dealing with legacy code, full of concrete dependencies, you might use Service Location as technique for teasing things apart with a goal of decreased hard coupling. In the end this may result in wholesale replacement of some modules.

When it comes to Dependency Injection and dependencies in general, I agree with Scott Bellware’s point of view; make your dependencies explicit & transparent by requiring them in the constructor. My gut reaction is also to avoid translucent (setter-injected) dependencies as they make it harder to tell what dependencies an object will need to do its job - the shape of the object isn’t as clear as with explicit constructor dependencies.

Feeling the friction

I tend to be lazy and prefer to feel friction of poor design early so I can change direction quickly. For example, when a constructor gets too large it’s a signal to stop and consider Single Responsibility Principle, Separation of Concerns, etc. In a similar vein, I don’t usually advocate use of an auto-mocking container. Or at least not for folks who’ve not yet acquired a strong nose for design and simplicity; the friction helps keep you on the rails.

Later in the tread Jon mentions some friction he’s been feeling when setting up the context of his tests (or specs). Namely he’s having to set up and inject a lot of concrete objects for interaction within his unit tests. To me this is an indication that those tests may actually be integration tests. After all, they are flexing the integration of a several modules in concert, right?

I say, call them what they are, fire up the fully configured container, and move on.

I prefer to make the implicit explicit, to be able easily see the shape of an object, and in getting forced feedback when my design starts to slip off the rails.