Just like every other Bob Dylan fan in the world, I have been endeavoring to
determine exactly how many roads a man must walk down. To this end, I’ve been
using passive location tracking for a few years now and have generated a fairly
significant amount of data on my movements and travel. Mostly I’ve used
Google Latitude, and enabled its optional history
feature.

Many people shudder at the privacy implications of this. Personally, I assume
my cell phone providers have very similar data on hand already, if not with
quite as much accuracy and precision.

I’ve now started looking through the data to see how my movements have changed
over time. One really stark difference between living in Seattle and living in
Stockholm is my average furthest distance — on any given day how many miles away
from home do I make it?

Check it out. This a map of my movements in Seattle on Thursday, September 29, 2011:

That was a fairly normal Thursday on which I went downtown for work, went back
home, and then went out for drinks on Capitol Hill. One cool thing about having
this data is that it helps spark your memory — I now remember that exact
evening, who I was with, and some of the conversations that we were having.
Location is an excellent trigger for that sort of thing.

Anyway, you can see that the furthest I made it from home is 4.3 miles. Most
of my days in Seattle seem to have a furthest distance figure of 4 to 6 miles.

Now, here’s a map of my movements in Stockholm on this Wednesday, September 26, 2012:

Again, a fairly normal Wednesday. I walked to the office, went to a show after
work, and then walked home. The difference, though, is that the furthest I made
it from home is only 0.997 miles.

One mile instead of five miles. That’s a pretty significant difference. What
makes it especially interesting for me is that I lived pretty centrally in Seattle
and had a very enviable commute (15 minutes on the bus followed by 5 minutes
on a bike).

The same holds in Stockholm. I live fairly centrally and have a similarly short
commute. But the difference is that in Stockholm a short commute is a 15-minute walk,
rather than a 15-minute bus ride. This is the kind of thing you can enable when
you build for density, and it’s the kind of thing I hope to see become more
possible in Seattle as well.

Some caveats here:

Neither of these days were climbing days for me, so I didn’t make it to the
climbing gym. If I look at climbing days, my distance from home in Seattle is
about 6 miles. In Stockholm it’s either 2 or 4 miles depending on which gym.
That’s definitely a less pronounced difference, but I think the theme still
holds.

Some neighborhoods in Seattle are fairly dense. On my stereotypical lazy Sundays
spent in and around Wallingford,
I often didn’t make it even 2 miles from home. I could walk to restaurants,
the coffee shop, the beer shop and the pub without going even half a mile.
But unlike in Stockholm, that half a mile isn’t dense enough to have many
offices where a software engineer might be able to find employment. Rather,
I had to go downtown for work.

While I have a bunch of data points about myself and my movements, this whole
thing is — at its heart — quite anecdotal. I’m sure there are people
in Seattle who don’t usually have to go more than a mile from home. And I know
there are people in Stockholm who live further out and have to commute a few
miles.

public void onClick(View v) {
new DownloadImageTask().execute("http://example.com/image.png");
}
private class DownloadImageTask extends AsyncTask<String, Void, Bitmap> {
/** The system calls this to perform work in a worker thread and
* delivers it the parameters given to AsyncTask.execute() */
protected Bitmap doInBackground(String... urls) {
return loadImageFromNetwork(urls[0]);
}
/** The system calls this to perform work in the UI thread and delivers
* the result from doInBackground() */
protected void onPostExecute(Bitmap result) {
mImageView.setImageBitmap(result);
}
}

I prefer AsyncTask, which has better semantics, but implementing one
AsyncTask after another quickly becomes tedious. Same with writing line after
line of Runnable boilerplate.

The first step is to create an implicit conversion from a function to a Runnable,
which can then be passed to View.post or runOnUiThread. Once we’ve done
that, it’s simple to use spawn from scala.concurrent.ops
to do background work.

This is so much nicer than the Java alternative. Instead of up to ten lines of boilerplate
for each background task, we end up with just the spawn and runOnUiThread.

If you’re waiting for that final push to switch over to Scala for your Android development,
I highly recommend the sbt plugin for Android. Take
a look at its brilliant Getting Started guide,
which will have you up and running in just a few minutes.

A few weeks ago, I had to make one of the toughest choices I’ve had in a while: a 30” Dell display,
or a 27” Apple Thunderbolt display. I went with the Thunderbolt display, partly because the colors
are better, but mostly for the convenience of having USB and ethernet integrated into the display.

The way this works, you can just plug your USB peripherals and your network cord into the
Thunderbolt display. Then, whenever you dock your MacBook Pro, you just connect the single
Thunderbolt cable and the display, USB devices, and network all work magically.

It’s much more convenient than doing the daily morning dance of plugging four or five things into
your MacBook, and it’s the closest thing we have to a good MacBook Pro dock.

Well, that’s the theory anyway. In reality, while the USB works fairly decently, the ethernet
connection dropped out on day one, and I haven’t been able to get it back since. Until today.

Here are the final steps that worked for me. Hopefully somebody else can save a bit of time with
this:

With the Thunderbolt display connected, visit the Network tab in System Preferences. If you see
Display Ethernet and/or Display FireWire in the list of network interfaces, select each
one and use the minus (-) button at the bottom of the list to remove it.

For me, Display FireWire was listed, but Display Ethernet was not. I’ve heard of others
having strange symptoms with neither or both listed.

Unplug the Thunderbolt display. This will not work if you keep the display plugged in while doing
the next few steps. Trust me, I tried it.

Visit the Network tab in System Preferences again. If you see Display Ethernet and Display
FireWire listed, you’re all good. Otherwise, click the plus (+) button at the bottom of
the list of network interfaces.

From the Interface dropdown, select the interface you have missing and click Create. If
you have both interfaces missing like I did, you will have to repeat this step for the other
interface.

If you haven’t heard about ACTA,
it’s a damaging piece of legislation very similar to SOPA
— the difference being that ACTA is international in scope and much closer to
becoming reality than SOPA ever was. Here is a video explaining ACTA
which I found to be quite educational.

Anyway, Stockholm decided to take to the streets to protest ACTA today.
Here are a few photos of the fairly well-attended event that I managed to snap
on my phone:

Earlier this week I moved from Seattle to Stockholm, where I’ll be working at
Spotify. I arrived and started settling in on Friday.
On Saturday, I decided to check out out the local bouldering scene.

There’s quite a few gyms in the area, and the closest ones to downtown are run
by Klättercentret and Klätterverket.
The Klättercentret in Solna is the place I was really looking forward to
visiting. But since it’s closed for renovation until next week, I instead found
myself at the Klättercentret in Telefonplan.

What I found there was a style of setting I had never seen before on such a
scale — instead of being marked by tape, problems are based on holds that
are of the same color and style.

Look closely and you’ll see that there’s pretty much no tape on the wall. For
example, neither of the holds the guy in the photo is using are marked. Instead,
he knows to use them because they are yellow.

At the moment I’m not sure if this is a regional thing or just a Klättercentret
thing.

One thing I can tell you is that, at first, I was very, very confused! I’d
expected a different grading system, but when I first walked up to the wall in
Telefonplan, I seriously had no idea what was going on. Of course, I tried to
figure out what other people were doing, but I’m not used to looking at the
color of holds.

Until I realized what was up, I just figured everyone was improvising their
own problems. Also, at the time I hadn’t realized that the vast majority of the
bouldering area at Telefonplan was on a different floor. Those things combined to
make me wonder if I was in some special kind of hell where bouldering was just a
joke.

What finally made it click for me is when I found a long overhanging problem
comprised entirely of bright orange holds. Once I saw that, everything clicked
into place and I could suddenly see all the problems everywhere! There were
quite a few excellent problems, and overall it was a great session.

Thoughts on this style of setting:

Grading. The approximate grading is something I can appreciate. It lets
you walk up to a problem and have a general idea of what it’s going to be
like, but without forming preconceptions of whether or not you can handle it.
Moreover, it reflects the reality of a gym problem where grading is inexact
and approximate, based on the perception of a single setter.

Visibility. Once you get used to the idea, identifying holds based on hold
color isn’t that different from tape color. You do have the same problem as
with tape where similar adjacent colors can be difficult to pick apart. In
some cases, you have an additional problem where heavily-chalked holds become
difficult to identify.

Style. Each problem definitely takes on a certain style based on the type
of hold used. I imagine this could be really handy when you want to train a
specific skill. If you pick a problem that starts with a sloper, it’s going to
be full of slopers that came from the same set. Same with crimps, or jugs or
pockets or what-have-you. As an example, I’ve set something similar before
using a single set of bright pink crimps, and it was great for training crimps.

Yet, the fact remains — with a given set of holds, you can
express more problems and permutations if you can mix holds of different colors.
Then again, the point of setting is to create challenging, climbable problems,
not just to mathematically optimize your theoretical problem space.

Every now and then I have a discussion or lecture with my roommate Chris, on some aspect of software
engineer, architecture, process management, or programming in general. His specialization is
psychology, so while this exercise can be cathartic, it’s largely pointless. I’ve decided that it
might be more effective to write these things down and post them.

Today, prompted by a discussion on what I should name some new object, Chris asked:

Isn’t all coding about being too clever?

I think that is a conception that many laypeople and beginning programmers have — that we should try
to be clever. Seasoned engineers will know that being clever can be one of the worst sins.

Here was my response, paraphrased:

The goal is to write the minimal code that (a) gets the job done, (b) doesn’t break, and (c) is
understandable and maintainable by other people.

“Clever” often meets the first requirement, can sometimes meet the second, and always fails
miserably at the third — which is actually the most important one. All things equal, I’d often
rather have a broken system that I can understand than a rat’s nest of code that happens to work.

That said, sometimes you do come across clever code that meets all of those requirements. These are
small masterpieces and works of art and should be regarded as such.

In the database world, developers are sometimes tempted to bypass the RDBMS, for
example by storing everything in one big table with two columns labelled key and
value. While this entity-attribute-value model allows the developer to break out
from the structure imposed by an SQL database, it loses out on all the benefits,
since all of the work that could be done efficiently by the RDBMS is forced onto
the application instead. Queries become much more convoluted, the indexes and
query optimizer can no longer work effectively, and data validity constraints
are not enforced. Such designs rarely make their way into real world production
systems, however, because performance tends to be little better than abysmal,
due to all the extra joins required.

Oh man, if only. I can think of at least one example of a
a platform with this very problem — and with the associated horrible performance profile — that is
very widely deployed and used in production environments around the world. I’m sure you can think of
others.

Anyhow, say what you will about Scott Rosenberg’s book, Dreaming in Code
— but the fact is, it makes Googling for experiences of actually dreaming in codefairly impossible.

Personally though, I find dreaming in code to be very real.
My dreams have always quite vividly blended reality and the imaginary, often
leaving me confused as to which is which, and leaving me with a somewhat tenuous
connection to the former. Code dreams are no different, and I’ve found that mine
fit into three major types:

The Text Editor. This is your fairly standard code dream. In my case,
white background, plain text and some code appearing or being written.
Sometimes, it might make sense and actually relate to a project I’ve been
working on or code I’ve being writing, but quite often this code doesn’t make
any sense whatsoever.

Often, there is no background or text, but just the lines and constructs of
code floating in a place where there is no physical reality. I wonder if
mathematicians have dreams similar to these, but with mathematical constructs?

The Inspiration. These dreams are comparatively rare, and don’t actually
seem to involve any coding whatsoever. However, they very specifically relate
to something I am working on, and when I wake up I know how to structure some
code that I have been struggling with.

This seems to be a pretty straightforward case of the brain working on a
waking-world concern while asleep. Too bad the hours aren’t billable.

Code Blends With Reality. This is the strangest type of dream and the
most difficult to relate, but in many ways my favorite. In these dreams,
physical reality seems to blend and mix with the reality of code. While there
is a normal dream of the physical world underlying everything here, in these
dreams I interact with that world with code instead of in the normal physical
manner.

For example, I might find myself writing a script to light a campfire.
Or instead of traveling from place to place by walking or in a car, I might
just fiddle with the parameters that define my location. People may speak in code
or in concepts rather than words.

Overall, I find #3 to be the most common type of code dream I have, as well as
the most interesting. It lets the world become a playground that is strangely
close to the real world. It is almost as if, in these dreams, magic is real, and
code is magic.

While it’s probably not the most important thing in the world, I’m really
curious to hear whether lots of other people out there dream in code, and how
everyone else’s code dreams differ from mine.

After all, we spend an amazing amount of time asleep throughout the course of
our lives. Who knows, maybe if talk about dreaming code enough, clients will
agree that those hours asleep should be billable after all, eh?