Here’s some of my favorite things that I’ve read lately:

• The days are long but the decades are short. A great writeup from Sam Altman with a good smattering of advice on a whole bunch of topics.

• Ready for Rain: Why Seattleites Crave the End of Summer. I actually read this over the winter, but it’s a beautiful article that really made me miss the PNW.

• How to Downsize a Transport Network. Never in my life did I think that I’d use the phrase “gripping, exciting article about wheelbarrows”, but that’s exactly what this is.

• “Why is software so expensive?”. Something that I thought I already knew the answer to, but which I’d never thought about like this.

Discussion welcome.

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:

1. 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.

2. 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.

3. 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.

Anyway, just some data that I thought was interesting.

When it comes to building responsive Android apps, there are two commandments:

1. Don’t block the UI thread, ever.
2. Only access and modify the UI from the UI thread itself.

The Android Dev Guide goes into some detail about this. The usual solutions in Java are to:

• Spawn a thread that does work and then invoke View.post with a Runnable that manipulates the UI.
• Implement and run an AsyncTask that does work in doInBackground, and then manipulates the UI in onPostExecute.

As you can see, both these solutions — though they are the bread and butter of Android development — are pretty verbose and unwieldy:

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.

Enter Scala, using either the sbt Android plugin or my Maven-based solution.

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.

Here’s a fully functional example:

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:

1. 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.

2. 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.

3. sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

4. Restart your MacBook Pro and log back in. Once you’ve logged in, connect your Thunderbolt display again.

5. 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.

After all that, everything seems to be working smoothly for me.

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.

Here’s a photo of the place by Helena Wahlman at the Swedish photo blog:

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.

What little tape there is just marks the start and end of a problem. The color of the tape is what specifies the problem’s approximate grade:

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.

All that said, I’m still not sure about this system. In a way, I’m sure it encourages creativity, as limits and constraints tend to do.

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.

Looks like I have some serious optimization to do for the new stuff that I’ve been building:

At least the latency seems pretty good?

Today someone on Hacker News posted a link to the Wikipedia article on the inner-platform effect, which is “the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using.”

One of my favorite parts of the article (emphasis mine):

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.

Before I begin, here are a few great, relevant xkcd’s: #719 #430 #203

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 code fairly 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:

1. 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?

2. 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.

3. 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?