Author: Ben Nash

Obtaining a Thorough CS Background Online

I’d like to show you a way to obtain a computer science background that doesn’t involve enrolling in a university program. Maybe you’ve completed an introductory Java course, and now you’d like to pursue a software development position. Or maybe you already have some formal CS training, and you’d like to fill in a couple of knowledge gaps. By utilizing online learning resources, you can obtain that background without incurring the costs of the traditional university approach.

Read more on Obtaining a Thorough CS Background Online…

Your 1st Impression as a Development Candidate Is Your Writing

Atomic Object Detroit recently assessed dozens of candidates to find a summer development intern, and we’re continually receiving applications for full-time developers.

As I reflect on the candidates that I’ve assessed both here and at previous companies, I’m struck by how revealing each candidate’s first email correspondence is. Those who’ve left strong, positive first impressions on me and my team have almost always made it far in the interview process, while everyone else has almost never worked out well, even if we advanced them to a later stage initially.

Read more on Your 1st Impression as a Development Candidate Is Your Writing…

Sharpen Your Git Saw – Aliases, Selective Staging, & Interactive Rebasing

Git is a powerful tool that we love as developers. It’s also complicated. I consider the bare essentials of Git, the minimum set of features to be familiar with before we can be productive, to be all of this:

  • local interaction: status, add, remove, commit, reset, checkout
  • branch management: checkout, merge
  • remote interaction: clone, fetch, push, pull

Once we’ve learned these basics well, we move onto advanced features and tricks. Read more on Sharpen Your Git Saw – Aliases, Selective Staging, & Interactive Rebasing…

Backbone Event Best Practices

When our Backbone.js apps become complicated, we need to utilize Backbone’s EventAggregator. From the Marionette docs: “An event aggregator is an application level pub/sub mechanism that allows various pieces of an otherwise segmented and disconnected system to communicate with each other.”


// Three ways of creating an event bus in backbone
var marionetteVent = new Marionette.EventAggregator();
var backboneVent   = new Backbone.Wreqr.EventAggregator();
var vent           = _.extend({object}, Backbone.Events);

1. Make sure you need it.

It’s harder to follow the execution of an event-based program than of regular synchronous method calls, so make sure you understand why you need an event in the first place. It’s worthwhile to ask: if events weren’t available, what would I have to do to solve this problem? Read more on Backbone Event Best Practices…

Develop Smoothly with the Right MacBook CPU

If you’re a developer shopping for a new MacBook, choosing a CPU can be confusing. Apple always gives you a handful of different CPUs options, all with different specs and prices, but it’s very difficult to understand how your development experience will be affected by this choice.

You can put thought into the other options that Apple lets you customize. For hard drive capacity, it’s easy to check the amount of space you’re using on your current machine and decide on a hard drive size for your new machine. If you’re comparing two different screen sizes, you can decide if you’d rather have a cheaper and lighter machine or a larger screen.

You can’t do that with CPUs. For instance, the latest round of 15″ Pro Retinas (released in late 2013) gives you three CPU options: Read more on Develop Smoothly with the Right MacBook CPU…

The Cost of Unit Testing

How far should we take unit testing? Should every line of code be covered by a unit test? What about code that’s hard to test? Let’s look at the cost and value of unit testing in a couple of different situations.

Tests We Can All Agree On

It’s easy to see the value of unit tests when we’re writing actual functions. Let’s say we’re writing a helper function called next_valentines_day for our greeting card application. Here are some tests that we might write:

describe next_valentines_day do
  it "returns next year's valentine's day when after Feb 14" do
    expect(next_valentines_day('2014-02-15')).to eq('2015-02-14')
  end
  it "returns same year's valentine's day when on Feb 14" do
    expect(next_valentines_day('2014-02-14')).to eq('2014-02-14')
  end
end

Even from just these two tests, we we’ve significantly reduced the risk of calculating the wrong Valentine’s day in our software. And that means we’re less likely to lose valuable time fixing bugs in the code or dealing with other fallout from the code being wrong (like decreased greeting card sales). Read more on The Cost of Unit Testing…