MacBook Pro Gaming PC

This is kind of amazing: using the Thunderbolt connector on a MacBook Pro to connect 2 desktop gaming GPUs! An upgradable gaming PC at home and a portable MacBook Pro on the move, it’s the best of both worlds. Right now it’s very much a DIY not-ready-for-consumers thing but external GPUs are the future.

What a time to be alive.

My Life With SmartThings (so far)

I’ve been using SmartThings for home automation for about 6 months now and figured it’s worth getting some of my thoughts down.

I’ll start in this post with what I’ve got set up:

5 GE Link LED bulbs in my family room. I actually needed to get an updated firmware for these to work, so I put in a support ticket on a Saturday after noon and got a response saying the firmware was updated in less than 10 minutes. I was impressed enough with their support to remember all that.

When I started going down the home automation path I was thinking about what I had done with X-10 many years ago and expected outlet switches to be the way to go. It turns out that a $15 LED bulb is cheaper than a $40 outlet switch.

I originally had them set to come on at sunset, but that became kind of annoying because it was still light out, so now we just turn them on with the app. Still easier than turning on 5 lights individually, and I can turn them off from my bed.

My bedroom lamps on some Z-Wave outlet switches. It’s been extremely nice to come upstairs to a lit room; the placement of outlets and switches in our bedroom made it annoying to turn on lights when we got into the bedroom. But I also have to open the app to turn off the lights, which can be annoying. (I’m hoping the iOS 8 widget will smooth this process)

A water sensor in my basement. I’m paranoid about water down there and this gives me peace of mind. I also moved it to my bathroom after doing some plumbing so that I knew I wouldn’t walk into a flood zone some morning.

A smoke/carbon monoxide sensor, also for peace of mind and if my family is out and there were an emergency I could get the fire department over ASAP (assuming that the internet didn’t go out first).

A window sensor in my daughter’s room so that my wife and I can figure out if we left it open without having to wake her.

2 super cheap IP cameras – again, great for checking on a toddler without waking her. The second one is deployed to watch the front door, mostly so I can see what the dogs are barking at while I’m in the basement. When baby #2 comes in October that one will get moved to childcare duties as well

Finally, SmartThings can host applications, so I’ve installed SmartTiles (née ActiON Desktop) as a simple way for house guests like my mother-in-law to turn stuff off and on:

The thing I like about this hobby (and it’s totally a hobby) is that it can be iterative and cumulative. When I want to play around with it, I can start adding new things and integrating them. Then, when I don’t have the energy to mess around with it, I can let it coast in its current configuration for a while until I’m game to playing with it again.

What I want to focus on next is providing more physical access (switches and buttons) so that I don’t have to use the app (and so that house guests don’t need a web interface).

The Speak Test for Remote Working

This is a pretty good test for how well a company supports remote workers:

  1. Does your team have a shared, public method for asynchronous communication?
  2. Does your team have easy access to high-quality video and audio conferencing tools?
  3. Does everyone on your team have access to all the tools they need to do their job?
  4. Do you have time set aside at regular intervals purely for communication?
  5. Does your team have 4 or more hours of work day overlap?
  6. Are priorities clearly defined and communicated in advance?
  7. Can your team make most decisions on their own without waiting on others?
  8. Is every task in the organization tracked in a shared project management tool?
  9. Does your team meet up in person at least a couple of times a year?
  10. In case of emergency, is there a way for team members to call for help immediately?
  11. Do team members use cloud based collaborative tools wherever possible?
  12. Is your team made up of self-motivated, self-managing individuals?

It’s not perfect – some of these have a lot more wiggle room than the questions from The Joel Test – but if you’re looking to work at a company as a remote worker these are good topics to discuss.

About that new stadium in Detroit…

Two years ago Detroit got approval to spend over $283 million of taxpayer money on a new arena for the Red Wings just six days after the city filed for bankruptcy even though the Red Wings’ owner is Mike Illitch the founder of the Little Caesar’s pizza chain who’s worth an estimated $5.1 billion.

And if you think that it’s OK because it will put the money back in the economy…

A major review of almost 20 years of studies showed economists could find “no substantial evidence of increased jobs, incomes or tax revenues”

Yahoo! Pipes 😭

I just deleted a draft I wrote about Yahoo! Pipes closing because Reflections on the Closure of Yahoo Pipes says it all.

looking back, it seems to me now that the whole mashup thing arose from the idea of the web as a creative medium, and one which the core developers (the coders) were keen to make accessible to a wider community. Folk wanted to share, and folk wanted other folk to build on their services in interoperation with other services. It was an optimistic time for the tinkerers among us.

The web companies produced APIs that did useful things, used simple, standard representations (RSS, and then Atom, as simple protocols for communicating lists of content items, for example, then, later, JSON as a friendlier, more lightweight alternative to scary XML, which also reduced the need for casual web tinkerers to try to make sense of XMLHttpRequests), and seemed happy enough to support interoperability.

The death of Pipes doesn’t sting because it was a tool I need to get through my day. It’s just a sign that the times have changed and API openness isn’t valued like it was a decade ago. “End of an era” kind of sting.

A world that used Pipes as often as Excel is a world I want to live in. Where every company I do business with says “of course we have an API!” Imagine what Siri or Google Now or Amazon Echo look like in that world. That’s the world that Pipes represented, the world I’m mourning.

Passing configuration to Angular

This is something that we got wrong on our project initially, then had a guy named Mark come on board and nail a very clean solution.

What we were trying to accomplish: we wanted to give our Angular Singe Page App some configuration data for initialization. Things like a CSRF token and API URL, so not necessarily things we could load from a web service.

The wrong way to do it:

We started off using an ng-init on our element. If you RTFM on ng-init they make it very clear that you should not be using it for that purpose. In our defense, the name “init” is right there in the name and the warning wasn’t as bright red in earlier versions of the documentation.

A better way to do it:

What we are doing now is putting this in our server-side template:

angular.module('ns-config', [])
    .constant('config', {{config|js}});

and then inject the ns-config module into our project. By using Angular’s constant() instead of value() the config object is available in our application’s .config() block.

Sprint length… do you think it is ever a good idea to go to 1 week sprints?

A friend sent me the above question about sprint lengths over Twitter but I think some other people might want to know my answer too. A question like that doesn’t have a clear cut answer, it’s more of an open-ended question that can’t be answered with a simple “yes” or “no.” But the answer is no.


I don’t think it’s valuable to perform all of the Scrum ceremonies in a single week; the planning:production ratio is way off with one 1 week. In an effort to seem like the kind of person to which you would ask this kind of question, I responded with a question of my own: “What are you trying to accomplish by shortening the sprint length?” and that was the real answer: “I am leaning towards 1 week sprints to help developers understand how long something really takes.”

A developer that is over-optimistic with their estimates? Now I have heard everything!

Shortening the sprint isn’t the first tool I would use to accomplish that. Instead I would be focusing on velocity. I’m not a huge fan of velocity (or pure Scrum for that matter) but it definitely can provide some perspective in sprint and long-term planning. I don’t care if you’re using an average or Yesterday’s Weather or what, as long as you are keeping good track of how much you are getting done.

First I would make sure that we are not half-assing Planning Poker. The goal is to come up with a size that everyone can agree on, and step 1 means using real cards or an app. Get some reference stories. I might be projecting a bit (why else would I have a blog?) but if you commit to a size and don’t have an easy out it forces a much better conversation about size. If I’m using my fingers it’s pretty easy for me to fudge that 5 to a 2 when I see what other people are saying. Everyone has a smartphone, use it.

The next piece is to have a good definition of “done.” The traditional goal of Scrum is to have a potentially shippable product at the end of every sprint, which lends itself to a decent definition of “done” but your team knows what’s right for them. Once you have that definition in place you do not count a single point until a story has reached that state. No “This 8 pointer is 75% done, so we’ll count 6 points this sprint and re-label it as 2.” No points until it is done.

Once you have that in place you should have a pretty clear picture of velocity emerging. At that point you can have the sprint planning session that you were waiting for all this time:

“Well we’ve committed to 50 points but we’ve never finished more than 20 points. Why is it a realistic amount for us to commit to this sprint?”

There will probably be some excuses and you can either push to reduce the sprint or let the team commit to it and bring the velocity up in the retro as a reason why the team couldn’t complete the sprint with a sustainable pace. (Aside: how did Scrum ever figure that you should “sprint” at a “sustainable pace”?) I would lean towards pushing the team to reduce the sprint size because I suspect the team is aware they are not finishing sprints on time, and another missed sprint would demoralize folks more. You can always offer the carrot “let’s commit to 20 and pull in more stories if we have time.”

Like I said, I don’t love velocity but I think that it’s the right tool for solving this problem. It isn’t about having a high score to beat, it’s about having a yard stick for understanding if a sprint is realistic.

Angular’s $http.error()

Earlier I promised (ha! PROMISE!) to explain why I don’t like Angular’s $http.success() and .error() but this guy beat me to the punch:

Don’t use $http’s .success()

First, I hate anything that creates inconsistency in my code. If we use success() we’ll still have to use then() in every other place that has a promise, which makes this syntax sugar more of a cognitive leak in my opinion than anything useful.

Second, it couples your code in a subtle way – you’re telling everyone you’re actually reaching to the network to get something.

These are big issues but I think it misses the biggest one: you lose most of the Power of Promises™ by using .success().

Promises are amazing. You can use them to make async code reasonable. You can use them to compose small async bits into a functioning whole. And $http.success() throws it all away. Take a look at this code:

app.controller('MainCtrl', MainCtrl);
function MainCtrl($scope, $http) {
  $scope.started = 'Started';
    .success(function(resp) {
      $scope.time = resp.time;
      return $http.get('');
    .success(function(resp) {
      $scope.ip = resp.ip;
    .finally(function() {
      $scope.finished = 'All done';

See the issue? Here it is on Plunker – the IP address isn’t getting filled in. Why? Because you can’t chain HttpPromises together like you can real Promises. What’s actually happening on the second .success() is that it’s calling the Date service a second time! If you were reading that code would you expect 2 calls to the Date service? Here’s the same code using .then():

app.controller('MainCtrl', MainCtrl);

function MainCtrl($scope, $http) {
  $scope.started = 'Started';
    .then(function(resp) {
      $scope.time =;
      return $http.get('');
    .then(function(resp) {
      $scope.ip =;
    .finally(function() {
      $scope.finished = 'All done';

That actually works like you would want it to. It works how Promises are supposed to work: if your .then() returns a Promise it will pass the resolved value to the next .then(). I’m not even getting into error testing. And if you were to pass that to some other system they could add to the chain however they wanted and it would Just Work™.

Then (ha! THEN!) there’s the issue of interoperability. Promises are in ES6 and anything that supports the Promises/A+ API should work together. That means Angular can create a Promise that Bluebird can wrap it in a timeout. Want to split 1 $http call into 5 $http micro-service calls because that’s the Hot New Architecture? If you were using .then() you could just wrap your calls in $q.all(), but $q.all() doesn’t have a .success() method. You lose all that power if you’re calling .success() and .error() all over the place.

So please please please stop using .success() and .error() in your Angular projects and stick to POPO: Plain ‘Ol Promise Objects.