Radyology

Poor Man's Location-based services with arp-scan and cron

Have you ever wanted to have your computer do something when you came home, or when you left? Here's a cheap and easy way to do it.

The arp-scan utility (available in most decent package managers) can scan your local network for active network clients. Just use the --localnet option. If get a response from your mobile phone (identified by mac address) on your local network, then you're (probably) home! Here's an example:

#!/bin/bash

if arp-scan --retry=3 --localnet | grep 'a4:a4:a6:a7:aa:ad'; then 
  echo "Daddy's home!"
else
  echo "Daddy's gone."
fi

Something like this could be easily run from cron (as root). A more sophisticated version would probably need to track the current state, possibly by touching and deleting a file, as to only act when it changes.

Something else to note: My phone, it seems to ignore too many arp requests in a row. Of course YMMV. Once a minute seems to work though. So the --retry option is in there just in case one of the arp packets gets lost.

Arduino Controlled RC Car

The problem with RC cars and little kids is that RC cars are actually rather hard to control. And really, rather than standing there controlling the car, most kids would rather be chasing it around (at least, most of my kids would).

So I decided to see if I could build an RC car that drove itself, using an Arduino nano rather than a remote control.

Hardware

Here's the parts list (aside from wires, solder, etc...)

• Arduino Nano
• PING))) Ultrasonic Distance Sensor ($30 from Paralax.com)
• 4 pin multicolor LED (Can't find a link now but this is close)
• Maisto Tech R/C Radio Control Rock Crawler Jr.($40 from Amazon.com)

The first step was figuring out where the RC chip leads were connected.

The answer turned out to be:

• R17 -- Backward
• R18 -- Forward
• R23 -- Right
• R24 -- Left

After that, I just needed to wire those leads into the arduino. I started out testing with an Arduino Uno, and once everything was working, I wired it up to the Nano I bought to actually use in the car.

After I confirmed that was working, I put the car back together, drilled a hole in the top for the LED, and hot-glued the PING))) sensor to the front at about a 10 degree angle upwards.

Software

Arduino's libraries are so easy to work with, you almost forget you're writing C++. So I wrote a simple program to control the car. Since there's only one ultrasonic sensor, I needed a simple approach to avoiding obstacles (Summary: turn left).

Final Result

Here's the car driving around my toy-littered basement.

There are still some improvements to be made here. Finding a car that ran on 9 volt power would have greatly simplified the design...although most of those cars are much more expensive than the one that I bought. And I need to add a switch to control the arduino.

Of course, this begs the question, is it still an "RC" car if it's not controlled remotely?

The Simplest Continuous Testing

Here's a simple bash script I use to do things to files whenever they change. It takes a command as an argument and runs that command with the name of a changed file. Many times, it's all I need to do continuous testing.

#!/bin/bash
# Requires that the inotify-tools package be installed.
wait_cmd="inotifywait -m -r --format %w%f -e modify ."
filter=$1
shift
cmd="$@"
$wait_cmd | grep --line-buffered $filter | while read file; do 
  clear
  $cmd $file
  date
done

There's No Such Thing As Software Productivity

Bill Caputo, through repeated conversations we've had, has convinced me of something very surprising. It was something that changed the way I think about the world, and how I do my job.

There is no such thing as software productivity.

As Martin Fowler observed almost a decade ago, productivity in software cannot be usefully measured. The reason why is it just doesn't exist in The Realm of Relevant Things. Put another way, productivity has no applicability as a metric in software. "How much did we create today?" is not a relevant question to ask. Even if it could be measured, productivity in software does not approximate business value in any meaningful way.

This is because software development is not an activity that necessarily produces anything. Here's a thought experiment: Let's say that you have a couple of developers working on the same project, and by accident, both of them pick up the same task on the same day. The first one, Frank, hauls off and writes a 1000 line framework that solves the problem beautifully. The code is well written, well tested, and the deployment and operation of it is well documented. The second developer, Peter, heads off to to the park for the day, where he thinks about the problem while he feeds the pigeons. Around 4:45, Peter wanders back to the office, deletes 100 lines of code, deploys the change...and the problem is fixed.

Which of these two developers was more "productive" today? The answer is: It doesn't matter. What matters the that Peter solved the problem, while simultaneously reducing long term maintenance costs for the team. Frank also solved the problem, but he increased maintenance costs by producing code, and so (all other things being equal) his solution is inferior. To call Peter more "productive" is to torture the metaphor beyond any possible point of utility.

I would argue that what good software developers do is remove problems. The opposite, in fact, of production. The creation of technological artifacts such as code, documentation, data, etc...are all necessary evils to achieve the goal of removing problems. That's why, sometimes, the most effective solution to a problem is a 5 minute conversation.

The strongest evidence for this model is that when you look at software development this way, a large number of thorny, observable-but-unquantifiable problems suddenly become easy to understand. For example, why do developers (usually) seem to be less effective when you isolate them from stakeholders and/or users. Wouldn't keeping them from getting distracted make them more productive? The answer is yes, it does often make them more productive...but it also makes them less effective. Since what they're doing is solving problems for stakeholders, isolating them from those stakeholders makes it harder for them to identify and solve problems. Having access to the people whose problem is being solved is more effective than the alternative, even if it means not having hands-on-keyboards for 8 full hours a day.

Which leads us to another example: Why do maintenance costs usually (but not always) dwarf other costs in building software? Why can't we ever seem to get it "right" the first time? One explanation is that software is a fixed solution to a potentially changing problem. When the problem changes (or when our understanding of it changes), it creates a gap between the problem and the solution. It gets expensive to constantly fill these gaps over time as the problems shift, even though the software doesn't change unless we change it. This also explains why video games traditionally have low maintenance costs compared to other software projects. It could be that the problem being solved (getting people to buy and play the game) is mostly dependent on human psychology, and less likely to change.

What about the mythical 10x "productivity" difference between good and bad developers? Everyone claims to have seen it, and yet nobody seems to be able to measure it directly. This theory explains that too. Problem solving is a much easier thing to "lever" (in the financial sense) than productivity, which makes order-of-magnitude differences easier to achieve. Problem solving requires only information and insight. Either you have it or you don't. There are no raw materials, no throughput limits. It's not that the bad developers are typing slowly. It's not that they would do better if they just "tried harder". They just don't have the insight or the information to solve the problem as effectively. Perhaps the reason you can't measure the difference in productivity between the good and bad developer is because there's nothing to measure.

There may be other phenomena that this theory explains. You can probably figure them out if you try, anyway. Here's what I've been doing lately...try this and see if it works for you. Every time you catch yourself talking about being "productive", ask if you're approaching the problem in the right way. Remember that if we could solve the problem without making anything at all, anything that we actually produce is wasteful.

How to Run Across a Lake

To run across a lake, you only have to do one thing: Run fast. The same is true in software development.

An Apology of Sorts: Functional Languages Are (Still) Overrated

Two years ago, I stood on my soapbox and yelled. I told the FP community that their languages were bad, and that they should feel bad. It was a post full of vitriol and frustration, but also a little bit of truth. I believed then (and still do) that functional languages are a poor solution if what you're looking for is a way to get B grade programmers to build scalable, concurrent systems. After trying to learn Erlang, Haskell, and then Scala, I couldn't see how using those languages was easier that just using separate processes, stitched together with message passing infrastructure, to build systems at scale. And with these thoughts running through my head, I vomited on the Internet. Then Hacker News picked it up.

The Case for Privacy (in Clojure)

A lot of people I've met don't use the private function definition in Clojure -- which is defn- if you've never seen it. They don't see the point, or they think that private functions in Clojure are dynfunctional (pun!). Based on my use of it so far this year, this confuses me, because I think private functions in Clojure are awesome. The reason I think they're awesome is because I write tests for my code, so that I can refactor. Having a clear deliniation between code the that's tested directly and indirectly means I can refactor much more quickly.

When you're looking for ways to refactor code, you can use your fingers, or you can use your eyes. Refactoring with your fingers is nice. When you have a continuous test runner, running a suite of tests on each change, you can refactor pretty quickly. But refactoring with your eyes is much, much faster. Being able to see possible refactorings and think through them in your head is a much faster way to reason about how to clean up code.

If most of your functions are private, you can refactor with your eyes before you refactor with your hands. Unless you've been doing something dumb like subverting access controls to invoke private functions, you know that all of your private functions can be changed, inlined, extracted, and generally recombobulated without fear of breaking a test or messing with another module. This frees up your mind to think about the code that's right in front of you, rather than worrying about the other code that might be calling it.

The public functions, on the other hand, are expensive to change. You will probably break some clients. You probably break tests. All of this will require a lot of work that, essentially, adds no value on it's own. That's not to say that you shouldn't refactor public functions, of course. It's just that the costs are potentially higher. And I find that too many public functions in a module create a slight reluctance to refactor. A pause in thinking, if you will, that I'd rather do without.

So I love private Clojure functions. They're just new a way to implement an old-fashioned idea: Encapsulation. Clearly dividing my clojure modules into public (more expensive to change) and private (less expensive to change) has worked out very well for me. If you haven't tried it, I suggest that you do.

Unless, of course, you're not writing tests...in which case I have nothing for you!

Better Continuous Testing in JavaScript

Things have come a long way since I wrote Continuous Testing in Ruby, Rails, and JavaScript. Lately, for JavaScript, I've been using John Bintz's jasmine-headless-webkit and his complementary guard plugin.

This tool has some really awesome features, not the least of which is that the environment your tests run in is really webkit. That means that you don't have to mock out major parts of the browser environment like window.location, localStorage and sessionStorage, and XMLHttpRequest if you don't want to.

Another great feature is the ability to generate an html file that will run all your tests in a real browser, whenever guard runs tests. Combined with the Live Page plugin for chrome, I get instant feedback about whether or not my Jasmine tests actually pass in the browser.

However, there is one downside compared the node.js technique I outlined in my book. jasmine-headless-webkit doesn't give you real stack traces in the guard output when tests fail. Usually this means you resort to looking at the test failure in the browser (using that generated html file). In practice, it's not a big deal, but it also means you need to make sure your tests pass in both environments, otherwise you might be stuck with a failing test that you can't diagnose.

Released Jezebel 0.4

I released version 0.4 of Jezebel last week. It now works with Node.js 0.6.2.

Continous Testing: with Ruby, Rails, and JavaScript -- Now in Print!

It's done! It's out. And I couldn't be happier.

As part of writing writing Continous Testing: with Ruby, Rails, and JavaScript, I had the opportunity to talk to a lot of people about what Rod and I were doing, and what they thought of it. Most of the people, once introduced to the idea, thought it was so obviously good that there just wasn't any reason not to follow this practice. By running your tests on every change, you create a tight feedback loop that makes it so much easier to find bugs and get a better understanding of what your code is doing. I'm really proud of what we've done with this book because I think the techniques we discuss in it will really open this practice up to a wide range of developers and projects.