Opening an Office in Portland

We’re pleased to announce that we are opening an office in Portland.

8 Things Github’s Atom Editor is not going to solve for you

February 26, 2014

We’re all excited about the prospect of a new code editor (Atom Editor). We all love what Github has produced so far and our expectations for anything new are going to be quite high.

Do we know exactly what it’ll be yet? Not quite. We have some hints… but until it’s released… we’ll continue to speculate.

While I am not one to make predictions—I do have a few theories about what Atom will not do for us. (if you’re looking for a new business idea… feel free to snag any of these)

1. Atom Editor will not make it easier to code while in the shower. While I would love to take advantage of putting my thoughts to code while letting my conditioner do it’s thing… I don’t believe they’re trying to solve this problem (yet).

2. Atom Editor is not going to make it difficult for me to produce shitty code. To date, nearly every code editor on the market is focused on making it easier to produce code…. good AND/OR bad. Where is the editor that tells us to quit while we’re head. “Are you serious, Robby? Have you seen what you’ve been writing today? Just stop. Go outside. Take a break and try again tomorrow.”

3. Atom Editor will not bring synergy to developers.

4. Atom Editor will not change the music playing to compliment the coding problem that I’m faced with. If my tests aren’t passing… I wish my music would keep me calm and focused. This is not a time to start playing WHAM! (…or maybe it is)

5. Atom Editor will not bring about peace in the Emacs vs Vim wars. We are going to have to let them sort a peace deal on their own.

6. Atom Editor will not have integrated CVS or Subversion support when it is released.

7. Atom Editor will not promise the world to you like Visual Studio.NET did back in 2002. I remember their demo videos and it seemed like the development world was about to change! I never would have guessed that come 2005, I’d be in love with something as simple and fancy-feature-less as TextMate.

8. Atom Editor will not just be a clone of Sublime Editor. Github has too clever a team for that objective.

What are you confident that Atom Editor will not be?

Update

8 for 8!

[…]

Clojure: Expectations Ignore A Variable Number Of Args In An Interaction Test

March 20, 2013

Over the past year I've written the same test a few times.

This test accomplishes what I'm looking for when I write it - verification that my-fn isn't called. However, it doesn't prevent me from future regressions where my-fn is called with 0, 2, or 2+ arguments. After being bitten by this issue a few times I decided to add an argument matching function that will accept any value for the argument at it's index, and any value for all of the arguments at a greater index. This argument matching function is anything&

The following example is similar to what's above, except any call to my-fn will result in a failure

My original intent was to protect against the scenario I described above*; however, what I ended up with is actually flexible enough to allow me to test other situations as well. For example, I've often found myself testing that a log message was written at a certain level, but not being interested in testing the actual message. The logging I'm working with allows a variable number of arguments, so anything& is perfect for verifying that no matter what args are passed in, the tests passes as long as the level is set correctly.

The anything& matching function gives me an extra bit of flexibility that can come in handy at times.

*which is similar to verifyZeroInteractions in mockito

[…]

The Ruby Rails Aggregator