Don’t Make API Calls in Tests

I recently had a great conversation about application testing strategy and remote API calls. The question we were trying to answer was this:

In an application which makes external API call, when should you mock those calls in your test suite, and when should you make live calls in your tests?

My take on this issue: always always always mock external1 API calls. Here’s why:

Continue reading Don’t Make API Calls in Tests

  1. This gets more tricky when you own both systems, but I still stand by this as a best practice for that situation as well, for slightly different reasons. 

Please Save Me From Myself

Today, I very nearly let a domain lapse that I fully intended to continue to have registered in my name. In all fairness: I own a huge portion of the blame for that near miss. But that’s the trick with UX: you’re trying to let someone do what they already know they want to do. I wanted to give Namecheap1 money for a domain. I almost didn’t get to. I’m going to tell you why.

Continue reading Please Save Me From Myself

  1. I want to be clear about this, though: this is mostly nitpicking. I’m very happy with Namecheap and recommend them despite these little issues 

Compiling the Best Possible Code Sample

Aspiring software engineers are often asked for code samples to demonstrate that they’ve got some clue what they’re doing. This is pretty terrifying and it’s incredibly difficult. When they’re not done well, they don’t provide much in the way of useful information.

I’m a lead engineer at a pretty cool software company. I’ve been in a lot of interviews and I’ve read a lot of crappy code samples. I decided to write about what would get me excited about a candidate’s code sample (and, by extension, them). Other people might feel differently. That’s cool; this isn’t a math test. (But I would love to hear those counter-points in the comments below!)

Continue reading Compiling the Best Possible Code Sample

Elixir Getting Started: First Impressions

I’ve worked through the Elixir getting started guide as the first step in my goal to build something in Elixir. So far, there are lots of things I like and a lot of things I find kind of strange.

The Good

The fact that Elixir is up front about the performance profiles of lists and tuples is encouraging. Understanding when certain operations will be slow helps us make good decisions about design.

The string support seems amazingly robust. The guide claims that Elixir passes every test contained in The String Type is Broken. Being able to avoid dealing with terrible string implementations is a huge benefit and, in the long run, probably worth putting up with a lot of other issues.

Parallelism is a primary concern, which is just as appealing here as it is in Go. Combined with immutability of Elixir variables, it provides an environment where you can reduce garbage collection based issues more easily.

I really like the pipe operator. Here’s a normal line of code:

Here’s that same line of code using the pipe operator instead:

The Bad

With some exceptions (like the pipe operator), the syntax is not very friendly when compared to languages like Ruby or Python. I get that some of this is probably the result of most of my experience being in imperative languages, but I just don’t find Elixir intuitive or easy to read.

This might seem like a little thing, but for most applications it is the most important thing. An employee’s time is often far more expensive than another server or ten, so languages that are harder to read have a higher “total cost of ownership” than ones where the intent is easily understood.


In terms of being “better” than Ruby or Rails, it still seems better in ways that Rails doesn’t concern itself with. There is a lot of interesting stuff in Elixir, though, and I’m looking forward to taking a swing at a practical project as soon as I make it through the Mix and OTP tutorials.

The Ultimate Password Solution

Few things are more annoying than passwords. In theory, they’re fantastic. You keep a secret locked away in your super-computer-brain, and nobody else knows what it is, then you use that secret to prove that you’re who you say you are. Brilliant.

Except that, in reality, passwords are beset by several tough problems. First and foremost, you don’t have any control over what the website you plug your password into does with it, so using the same password for everything is foolish. That means that instead of having to remember one password, you have to remember a bunch of them and what services and websites they match up with. Don’t write them down, either, or someone with physical access to your space could steal them!

Those are all problems with passwords before individual sites get into the mix with their own restrictions. Some of these make sense; it’s almost pointless to have a two-character password, after all. Others of them are just silly: why should there be a limit on how long the password can be? Or what characters I can put into it? Then we have the myriad restrictions on how complex the password can be and how often you can repeat them.

The first group of problems are all going to be around for as long as we have passwords, but when it comes to the problem of users having too simple a password, there’s a painfully simple solution: base the expiration date of a password on how strong it is.

Continue reading The Ultimate Password Solution

Giving Up Push Email

When I made the move to smart phones god-knows how many years ago, it was amazing to me that emails would come straight to my phone. It was basically magic; I was fascinated and infatuated. I was living in the future. For years, I had no idea how anyone could live without having access to their email any moment they wanted it.

Moreover, I couldn’t understand why anyone wouldn’t want to be notified the second they had a new message.

Not terribly long ago I met someone who, more than not needing to know every time she received an email, actively did not want that. I’m not sure there’s a logical or practical reason1,  it’s just a personal preference. It took me months to really wrap my head around it, which probably says something about how attached I am to technology.

Then, a few weeks ago, I noticed two things. First, I noticed that unless I was actively ignoring my phone (like at dinner or out with friends), getting a new email meant that I immediately wanted to see what it was, regardless of what else was going on. Second, I noticed that this was almost always a disappointment. Rarely are my emails even vaguely interesting. Something on the order of two or three dozen times a day I would hear the new mail beep, I would get excited over the possibilities contained in a new and unknown message, and then I’d be disappointed by the outcome. It would also serve as a distraction.

I decided to tell my phone that when I wanted to know if I had new messages, I’d ask for them. At first, this seemed almost prehistoric. Now, however, I find that I really don’t miss it. The email is all there waiting when I decide to check it. I don’t have trains of thought interrupted or random distractions.

If you’re a push-email addict (except, maybe, for work email), you should try it for a week or two. I think you’ll find you hate it far less than you think you do.

  1. Which is not to say that the desire is illogical or impractical, only that I don’t think those are the motivations