May 14, 2012

Documentation is essential for software development. I’m always interested when someone presents a new way to navigate documentation. I remember when Fileability came out with Ingredients. Sadly, Ingredients doesn’t seem to work on Lion.

Nate told me about this new documentation viewer called Dash, from the Mac App Store. It works fast, can be accessible with a hotkey, and has support for “snippets” (kind of like TextExpander) which can sync over DropBox.

It also includes support for custom documentation sets, and has a growing library of one-click-install docsets.

It’s free at the time of this writing, and I recommend it.

Noise in the Ceiling

Apr 17, 2012

I’m currently attending a university, about to graduate this May. I live off campus in an apartment with 4 other roommates. Several weeks ago, I had an idea to play a prank on my neighboring roommate. I had heard about the ThinkGeek Annoy-a-Tron and thought it was an excellent idea for something like this. I wanted to one-up it, though. Using an Arduino and some other components my other roommates had lying around, I built a similar device that can be controlled over HTTP.

The noise device:

The noise device, wrapped in a plastic bag

Pretty menacing, right? I wrapped it in a grocery bag, for dust shielding, but this seemed dangerous for static.

Here’s the Mk II, which I switched to shortly thereafter:

The noise device, Mk II

I installed it 3 weeks ago, in the drop ceiling between our rooms. I thought he’d notice within several days.

The device listened over port 1337, and parsed the HTTP request to generate a particular tone. For example, device:1337/1000 would sound at 1000Hz, device:1337/2000 is 2000Hz, and so on.

I wrote a script to send it HTTP requests at a random interval, between 2 and 8 minutes (just like the Annoy-a-Tron). I ran this script all day, and all night, for at least a week.

At some time, I stopped running the script for whatever reason, but would casually check in and make the device beep manually every now and then.

My roommate never said anything. I assumed he couldn’t hear it, despite the noise being definitely audible from my room.

Tonight, he noticed a power supply running into the drop ceiling of my room, on the wall adjacent to his room. He didn’t know that this was for an Arduino in his ceiling, but suspected something. I turned up the intensity, and the rest of my roommates joined me in a hunt for the source of the noise. They, of course, had all known since I first installed it.

Finally my roommate realized the prank. He confessed that he heard the noise, every single time it sounded, and that he was convinced it was coming from his computer or television. He was afraid of saying something because he was afraid of sounding crazy.

Needless to say, this went on for a little longer than I intended. Worth it.

Emotive Text

Apr 09, 2012

I’m currently taking a course in Typography. For a class project, we were asked to investigate the relationship between typography and language. While individual letterforms are interesting from a design standpoint, they are traditionally used to convey language and emotion.

Because we could choose any medium for the project, I decided to write software. I recently have become very familiar with Core Text, and I wanted to try my hand at various natural language processing toolkits.

I had this idea, early on in the semester, of animating type in a fullscreen application. I have a strange passion for large text fields and unusually colored text carets. I ran with these ideas for the project.

I wanted to make something to visualize the emotion given in a particular sentence or phrase. I thought natural language processing sounded perfect for determining the emotion of a sentence, and then I could use Core Text to typeset it, and Core Animation to animate it.

First, though, how do we determine the emotion present in a given set of words?

I searched around, and found a very interesting component of a project called NodeBox. This en Python library is capable of evaluating the emotion of a given noun, verb, adverb or noun. It includes a lite version of nltk, and has no external dependencies. Awesome.

Now that I had emotions for given words, I could begin to write some Objective-C to do the typesetting and animation. I bugged Gaynor for help with using Python.framework to glue Python into an app.

I wrote a text attributer, which would utilize the emotion mapping given by en to assign a custom “emotion” attribute to each word in a provided phrase of text. Then, a font assignment object would parse these emotions, and set the typeface accordingly. Finally, using some (very hacky disgusting) Core Animation, I put each glyph into its own CALayer, and animated them all.

For setting fonts, an easy choice would have been to find typefaces that match the emotions expressed in that sentence. This seemed too obvious. Alex pointed out that it would be cool to assign fonts representing the opposite emotion. This sounded very interesting. Once I implemented all the fonts, reading sad messages in “happy” typefaces and vice-versa felt unusual and uncomfortable. This emotional connection was surprising to me, and exactly what I wanted for the project.

Once I glued all these components together, something still felt off about the project. Due to the inherent nature of Python (and the en library), processing the emotion of text was slow. 2 or so seconds, but still, not instant and visceral like I wanted.

How could I get instant emotion for a phrase, as the user types it? No natural language toolkit (that runs on commodity hardware) is that fast. But, if you can’t do something fast enough at runtime, maybe you can precompute it!

It took very little time to write a program to test the emotional status of every word in /usr/share/dict/words. 50 hours of Mac Pro time later, I pickle‘d these to a Python dict. Then, I used PyObjC (in the interpreter!) to translate this dict into an NSDictionary property list I could load into my app.

I was initially worried about having enough disk space to hold this emotional mapping file. After discovering it was less than 50K, I jumped at the opportunity to have it in memory.

Combing through the emotional mapping, I noticed that there were many emotional synonyms. “sadness” and “depression”, “joy” and “elation”, and so on. I wrote a quick “synonymizer” object to resolve these synonyms, thereby increasing the word scope of the app.

Emotive Text Screenshot

And now it’s instant, and pretty much done. You can clone it and play with it at the GitHub Repo. It requires OS X 10.7 “Lion” or later.

(Please excuse the dirty, disgusting CA hacks and unoptimized NSDictionary code. This was written quickly, and for one purpose, and is not something that I will need to maintain).

Instapaper 4.1 looks fantastic

Mar 22, 2012

I recently updated to Instapaper 4.1 on my new 3rd generation iPad.

The text looks incredible. Arment has licenses from various foundries, and the new included typefaces are best-in-breed for screen reading. I prefer Elena on iPad, and am tending towards Lyon on iPhone, although I’m still a bit undecided.

A great update to one of my all-time favorite iOS apps.

Don't Cut Slack

Mar 02, 2012

Let’s say you needed a can opener (and for whatever reason, you didn’t own one yet). You go to a store, and purchase one.

That night, extremely excited (as many people are about new can opener purchases), you hurry into your kitchen. Tonight, you’re going to prepare a meal! And some of the ingredients will come from a can, yum! You bust out a can of sweet corn, hook your brand new department-store can opener onto it, squeeze, and turn the crank. After a few seconds of turning the hand crank, the top comes off, and you can enjoy your sweet corn. Yum!

Later that same week, you’d like to again cook yourself a delicious meal whose ingredients also come in an aluminum enclosure. Just as you did before, you hook the can opener up, and begin to turn the crank. Only this time, you hear a terrible grinding noise. Before you can stop turning, the can opener has cut up metal shavings of the can, and put them in the food. Furthermore, due to the destruction of the can, a lot your food has leaked out onto the kitchen counter and floor. Your dinner is ruined.

Maybe the owner’s manual for this can opener had a specific angle you were supposed to hold it at. Perhaps it had a suggested service plan - after so many turns, you need to get it serviced to have it work the same as before.

You now have a lemon can opener (without service or new parts), and a wrecked meal for the evening. Besides doing nothing, there are two courses of action you could take.

You could take the active approach. Maybe you’d write the company. You could contact consumer advocacy campaigns, you could return the can opener. You were sold a defective can opener, and you’re going to get your money’s worth!

Or you could be passive. If this freak can opener incident happened to you, you’d probably never buy a can opener of this style or from this manufacturer ever again. You might even tell your friends, and recommend that they too stay away from this particular kind of can opener.

You wouldn’t be cutting this faulty can opener any slack. You certainly would not assume “Oh, this is just how can openers work”, and conclude that you’re stupid or wrong for not following the bizarre requirements. You weren’t wrong. The tool was wrong. You’re not cutting it any slack.

Maybe you don’t cut a can opener any slack because it’s not very complicated. You can understand the basic principle behind how it works.

Would you cut a more complicated thing more slack?

What about a car? Maybe you own a car (perhaps from the same company that brought you that fantastic can opener1), and it works alright. Every 10 or so times you start it, though, the engine fails to turn over and needs to be jumped. This isn’t because of a faulty component in the car, this is just how the car works. Everybody who owns this car has this same problem. Driving around, you frequently see people jumping each other to start these cars. This is commonplace. Also, every six months or so, these cars require major service to keep working. You need to have the engine rebuilt, or else the car won’t run nearly as well as it used to. Your speed will be limited, you’ll use more fuel, and the car will emit a terrible odor.

  1. I wouldn’t recommend buying a car from a company that makes can openers. Or a can opener from a company that makes cars.

Cars are significantly more complex than can openers. Lots of parts make up a car, and they work together in complicated ways. Unlike a can opener, most people do not understand how a car works (beyond basic principles of internal combustion, maybe).

But I bet most people would not cut this car any slack. They’d return the car. There would be class action lawsuits against this kitchen-tool-and-automobile company. This company would be scolded publicly - why can’t they make cars that work the way they should work? If you owned one of these cars, you wouldn’t accuse yourself of being stupid or wrong for not following the unusual service requirements. You would blame the car company. You wouldn’t cut them or the car any slack.

So, if complexity isn’t a factor, then what about something that’s similarly as complex to a car?

What about software?

People cut software a lot of slack. Way too much, if you ask me.

I see people all the time who deal with issues with software similar to the ones I’ve described for can openers and cars. If the computer does something bad, like loses a document because you forgot to save like you “should”2, the computer gets cut a lot of slack. People feel bad, they feel stupid, they feel like they did something wrong.

  1. Save early and save often” is an unfortunately common mantra.

For a lot of people, every 10 or so times they turn on a computer, they’re presented with a strange dialog or screen they don’t understand before it’ll start. Maybe it didn’t shut down cleanly, maybe it needs to rebuild some internal cache, maybe it needs to do a filesystem check. Most people don’t understand what this means (they should not have to understand what this means), and they may bring it in for service. Not because the machine’s doing something weird or cryptic, but because they feel too dumb to understand their computer.

I go to a fairly technical school, and it’s common practice for many students here to “re-image” their computers two or three times a year. They view it as good hygiene for their software - this is something computers need to function well. They think nothing of the fact that several times a year, they need to drop everything, and spend a day “cleaning” their computer.

Or, worse, they blame themselves for needing to do this.

If only they hadn’t installed all that software to bog it down, if only they had defragmented their disk more often, if only they remembered to check for spyware and malware. If only they had used the computer the “right” way, they wouldn’t have to do this.

Maybe people cut software so much slack because it often costs less than a car. Cars cost tens of thousands of dollars, while software is frequently much cheaper (or free). I believe, however, that upfront cost is not the whole story behind how much slack we should cut things.

Let’s take a free example, to make things easier. Let’s talk about gcc. gcc is free software, both in terms of speech and beer. I didn’t pay anything for it.

How much is gcc worth to me?

Certainly more than $0. I’d argue that gcc and similar free tools like it are worth a lot to me. They’re critical to my craft. They’re how I make stuff. How important is a pair of shoes to a runner? Or a paintbrush to an artist? Or a guitar to a musician? Much more than their retail price, that’s for sure.

It’s hard to put a financial value on these things, but it wouldn’t be difficult for them to be competitively priced to a car. For many people, they’re how they make a living.

Software is extremely important to many people’s lives, more than just software developers. Think of how many jobs require email clients, word processors, spreadsheeting applications and internet browsers.

If this stuff is so important to us, why do we cut it so much slack? Why do we blame ourselves when it doesn’t work right or how we expect? Why do we assume that frequent maintenance is acceptable for something so important?

Maybe we cut software slack because we have to. Because there’s rarely any other option. Sometimes you can’t just switch or stop using a piece of software.

It’s a problem with the software industry. Companies are used to people cutting their software slack, and as a result, they don’t try as hard. They start to make users custodians of the system, and user-centric design takes a back seat to cheaper operating costs. Who’s going to call them on it?

Intentionally or not, an attitude of guilt has been instilled in consumers regarding software. Companies aren’t likely to change if this attitude stays the same, if we keep cutting software slack.

We shouldn’t cut software slack. It’s a tool, and it should work like one.