Zach Holman

You Won't Regret Positive Feedback

2013-04-29T00:00:00-07:00

Every product that has ever existed has had to deal with feedback.

The most interesting feedback happens before the product ever ships, in comments and discussion amongst your teammates. Should we leave this as-is? Does it look right? How can we improve this part of it?

It's governed by taste and design. They're subjective measurements, which means there's inevitably going to be conflict.

I can't think of a time I've ever regretted giving someone positive feedback on their work. But I still cringe years later when I think of the times I've been overly critical in past feedback.

"The products suck! There's no sex in them anymore!"

While not the originator, Steve Jobs is the personification of this culture of cruelty-as-management-tactic. There are stories all over the Valley about directors berating their staff in an effort to motivate them to push harder. My friend worked at a startup that typified this: her boss would stand over her desk, tell her how the work she just did was shit and how she needed to redo it. I told her that her boss was an asshole; she said he was a genius.

Maybe that really is a motivator in the short term. It seemed to work for Apple. But it also led to a lot of burnt-out, unhappy employees, and a really hostile work environment.

Regret

There was this thing a few years ago.

It was something our company was going to launch, and it seemed like there were parts of it slipping through the cracks. I wanted to see this succeed, so I devised a sarcastic approach in an effort to drum up more attention to the launch's deficiencies. I figured this would be an edgy way to help get more people involved in turning the ship around, so to speak.

It was the wrong way to handle it. It shed more negative light internally on the people involved in the launch, who in the end had great reasons as to why they made the choices they did. Sometimes circumstances are just shitty. Sometimes you don't know the whole story. Or sometimes the shit you're stressing out about just doesn't matter that much.

Drive-by design

I think our industry does feedback really poorly. I sure as hell do. My first impulse whenever I see a comp is to shit on it. Honestly. Even if it looks great. Especially if it looks great. We instinctively want to pick apart any deficiencies as soon as possible because that's how product is created. We build things incrementally, chipping away the rough edges until we have a clean polished surface underneath it all.

I think that leads to a feeling that being emotional or cruel is actually helpful during design or code reviews. That the approach cuts away the fat even quicker, which is a great thing since we can get to that finished product quicker, right? Because that's really all that matters anyway, after everything is said and done: if The Product is unimpeachable, everything was worth it. Sleeping under your desk. Yelling at your coworkers. Pushing to make that final iteration. It's all for The Sake Of The Product.

It's really all bullshit though. Maybe it does produce good product, but I don't really care about that directly anymore. I want to make good companies. Good, healthy, positive companies produce good products. And if things still go south, and your good company produces a product that just wasn't good enough, well, at least you're all still happy. Companies with hostile environments can fail just as easily, but the difference is that they leave depressed and angry people in their wake.

It doesn't matter that much

It really doesn't.

I'm still bad at giving feedback. I want to slam my mouse on that big submit button in the comment form as soon as I can. But I've found that's almost always a reaction.

If I see a monumentally bad idea come across my inbox, I've been trying to first let it simmer for a few hours or days. It's surprisingly made me a much happier human. You don't get suckered into as many passionate debates because you're able to come into the discussion with a much cooler head. Many times I end up seeing why the decision was made in the first place. There are always a myriad of tiny invisible decisions that go into building a product, and you can't understand all of them three minutes into glancing at someone's work.

In turn, you also avoid shitting on the work of people you care about: friends, colleagues, humans. You should still say what's on your mind — disagreements will always happen, after all — but coming at it with a cooler head makes for less sarcasm and fewer lines drawn in the sand. And you can be proud about that.

The Conference Circuit

2013-04-22T00:00:00-07:00

You're at a new conference, but the faces look the same.

The speakers all are familiar. The names? Few surprises. You're seeing the conference circuit at work.

Hedging Their Bet

This isn't some conspiracy. What you're seeing is simple: it's a hedge. Conference organizers like people who have given talks before.

The quality gulf between your first talk and your second talk is unnervingly large. You learn how to talk to a group of people. You discover how to stand on a stage. You micromanage an internal monologue while delivering an external monologue. During your first talk, the dumbest things — plugging your laptop in, drinking water, even breathing — are things to worry about, things that could cause a stumble.

They dissipate some by your second talk. By reaching your second talk, you're suddenly Accomplished: you have made it through at least one talk without dying or collapsing into a small ball of tears and embarrassment.

People who do this process over and over again are Very Accomplished. They're a known quantity. Someone who can Get Things Done, at least on stage.

Watching a bad talk at a conference can waste thirty minutes of your time. That's irritating. On a conference level, though, you're wasting thirty minutes of two hundred people's time. That's intimidating.

So they hedge. Organizers ask people who have done this before, and they hope to avoid disaster.

The Circuit

The Conference Circuit is a weird thing to be on. I flew around 200,000 miles last year to primarily give talks at conferences. It's exhausting, and it's a lot of fun. It's also really surreal sometimes.

People look up to you. Often, literally: you're on a stage, towering over tidy rows of folding chairs. Typically, metaphorically: you're the expert, you're flown in, you go to special speakers dinners. It's hard to not feel some feeling of superiority.

This isn't necessarily bad when it comes to your talk. It's helpful to feel like you have some special power over these people because holy fuck they're all looking at me why did I think I ever deserved to be up here in the first place holy bajeezus I should just duck behind this podium and maybe I can disappear in poof of nervousness. Anything that makes you feel confident in the face of this insecurity is a good thing.

The real trick is dropping the schtick after the talk. More often than not, the attendees know more than you do, and the speakers just happen to have some additional experiences in the small realm of their talk. Many times, people on The Conference Circuit can't drop the schtick: I've heard of plenty who only show for their talk session and ditch the rest of the conference like some conference prima donna. If that was a thing that existed, I mean.

Most speakers aren't magical; they're just prepared (and some not even that). It's not cause for some special elevated status.

Small and focused

So how do we address this problem of stale speakers? It's a problem that won't ever go away, but good conferences can help combat the tide.

Stories. Focus on stories rather than ideas. For one, ideas are harder to capture for first-time speakers: they're typically abstract concepts that are difficult to communicate unless you've thought about it a lot. But if you're just telling a story of a problem you've solved in your career, you're just regurgitating experiences. It's easier to deliver, and reduces the risk of a new speaker bombing on-stage.

Hidden bonus: stories are typically far more captivating to listen to for an audience.
Discussions. For smaller conferences, breaking into groups of less than 50, ideally seated informally, can really change an experience. Have someone talk about their experiences for twenty minutes, and then have an informal discussion around the room for the next forty. In this format, the discussions are usually more fascinating than the talk, as each person contributing to the discussion can share their own experiences in that domain.

Good moderation, of course, is crucial here.
Shorter talks. Speaking for twenty minutes is a wildly different experience than trying to fill an entire hour. Almost no technically-minded talk can keep a room full of people engaged for a full hour. Shorter, targeted talks get people focused on very specific problems, and they're simply more exciting.

These suggestions won't work for every conference, though. Larger conferences can't break up into small, intimate sessions. Abstract talks — which are just as important — don't lend themselves to stories as easily. Still, facilitating these types of interactions can really make your conference stand out.

There are a lot of great speakers out there. A lot of them haven't discovered it yet, though. There's nothing wrong with wanting to seeing our favorite speakers at conferences, but I'd love to discover even more new faces, too.

Keeping People

2013-04-11T00:00:00-07:00

Tech companies do a generally poor job at keeping employees from leaving.

There are plenty of reasons for this: competing offers, unhappiness, and just generally itchy feet. Because of this, sometimes it's difficult to focus on building a strong culture of company solidarity, particularly when you're trying to juggle the hundreds of other needs of a growing business.

This is a talk about keeping people.

Slides

If Only I Knew This Shit in College

2013-03-28T00:00:00-07:00

I knew I wanted to work in tech.

Looking back, that's really all I knew prior to graduating from university and joining the working world. I was invited back to give a talk at my alma mater recently and I wanted to give a talk to my less-than-knowledgeable former self and explain to him what he'll learn in the subsequent years after school.

This is that talk.

Slides

GitHub: Behind the Feature

2013-03-28T00:00:00-07:00

In the beginning of 2013, we shipped a new version of Search to GitHub.com. This talk takes a peek behind the scenes to illustrate how we build features at GitHub. It's a good beginner-level look at how startups work in teams together and deploy a product to the general public (initially this talk was given at a university).

Slides

Retina or Death

2013-01-07T00:00:00-08:00

It's been six months since the Retina MacBook Pro shipped and web developers everywhere are still clutching their keyboards to their chest, ignoring Progress, and rocking themselves into a dark, pixel-fearing delusion.

Pixels are the future, be it on an iPad or MacBook or Android phone. Photos jump out at you. Icons pierce your soul. Letterforms curve through your screen like a polka dancer dropping acid.

The Retina MacBook Pro is still very much a luxury item, but we've had a Retina iPad for almost a year and the iPhone 4 for two and half years. High definition displays in widespread usage are five times older than Gangam Style.

And yet, the internet is still having a hard time adopting. Startups slave for months meticulously designing their new marketing site and are completely oblivious that, to people on a Retina display, it looks like a jumbled pixelated mess.

Here's an actual, unretouched screenshot I took of a new startup that launched this week:

See? Pixels everywhere. I don't even see the sites anymore: all I see is yellow pixel, brown pixel, red pixel…

The Fix is In

The fix is easy, but few implement the fix: serve higher-resolution assets.

There are a few ways to do this. Apple.com is one of the approximately two sites on the internet that have mostly switched-over to high resolution assets, but they use some janky JavaScript to first download the image at 1x (normal resolution), shoot another request to test the existence of the image at 2x (twice the size), download the image at 2x, and swap the 1x image out of the DOM with the 2x image. It gives your eyes the distinct impression that they have cataracts as they adjust to the blurry image for a split-second before it bumps up to something pleasant to look at. On top of that, Retina devices incur the additional overhead of loading two images and an additional request in order to render the image at 2x.

The easier way is to just load the 2x asset for all clients:

<img src="/images/header-500px.png" width="250" />

Modern browsers are pretty decent now at scaling down assets in-page. That's typically fine for photos, and for things like logos — where you want pixel- perfect scaling at smaller sizes — you can send a designer to go off and calculate different scale ratios to figure out what fits best in the grid for that asset.

You incur additional bandwidth overhead for low-fi screens, but that can be remedied with CSS media selectors by conditionally displaying assets depending on pixel density. You can even automate a lot of this with SCSS or other frontend frameworks.

Beyond that, explore vector technologies like SVG and webfonts. Creating your own icon set or using other sets can play a huge role in making buttons and navigation controls really pop on a high DPI screen.

1x1.gif

Doing this shit takes longer. It's easier, I know, to just take your same favorite 16x16 icon from 1992 and blow it up to 128x128 because that's just what you've done for the last few decades. But deal with it. High resolutions displays aren't quite in widespread usage yet, but by the end of 2013 that's certainly going to start to change. Get ahead of the curve now.

Remember back in the days before ajax, before DHTML, and before CSS? We had five years of gloriously designing sites using <table> tags and the inimitable 1x1.gif transparent GIF to move elements around on-page. It was badass, and served us well. But then things like Zen Garden exploded on the scene and fundamentally changed how the internet collectively looks.

That's where we're at now. There's a post 1x1.gif world happening now, and you better serve up some Retina images soon or else your company is going to crumble and no one will use your product and your children will drop out of school and do drugs but not the fun drugs the really scary drugs that even you don't like and you're positive they're doing them because they'll be uploading high-resolution photos of themselves doing lines off of the new Retina iPad you bought them last Christmas.

So cover your assets, and go update your CSS.

Chat Trumps Meetings

2012-12-12T00:00:00-08:00

I do a lot of public speaking about our asynchronous workflow at GitHub. Our office is filled with chat rooms, email, and pull requests rather than development meetings and in-person code review.

I think people understand why this may be a better way to work, overall. We can avoid distractions, work from anywhere, and recruit globally.

But I think it goes further than most realize: chat is a better way to communicate.

The Explicit

Text is explicit. By forcing communication through a textual medium, you're forcing people to better formulate their ideas.

Real-time oral communication has drawbacks. In normal, conversational dialog, most of us know the direction we want to take our argument, but it's difficult to think about what you're going to say until a few moments before you say it. This leads to filler words (like um and uh), excess rambling, and lack of clarity in speech.

If you've ever wanted to scream at someone get to the damn point already, you know this pain.

Text is the opposite. It takes only a moment to go back and rephrase a sentence before hitting return. The bit of freedom from being a purely synchronous, real-time medium means you can editorialize and clean up your words to better clarify your point.

Focused text is skimmable, quicker to mentally process, and leaves less room for ambiguity of thought.

The Record

Text is also on-record. You should be logging everything that's said through your company chat so that people working remotely don't miss out on what was happening in the office. This makes communication in your company searchable and accessible.

We drop into our transcripts every day to gain more context about previous decisions. You don't get that level of granularity even from meeting minutes: what you think is worth writing down after the meeting may not be what was important from that meeting. The discussion is sometimes more important than the decision.

The High-Level

Brainstorming is the one area of work where this falls flat.

During brainstorming, you don't want that editorializing step during the moment before you tap return. That split-second hesitance can mean the difference between a multi-million dollar idea and a flop, a clean object model and a mess, a new policy or the same broken policy.

At GitHub, we get together a few times a year in the same physical room with everyone in the company and talk high-level brainstorming. We take notes for posterity, but talking is the best way to stimulate geniusly-dumb ideas.

It's important to not use this excuse for all work, though: most problems would benefit from a paper and pencil and a room to yourself rather than a large disruptive meeting. Big ideas require big brainstorming, and small ideas just take some self-reflection.

Next time, use your words.

Left: A Jekyll Theme

2012-12-11T00:00:00-08:00

I murdered my blog today, and when I plunged my knife into its soft underside, it bled open source.

A New Look, an Old Look

After redesigning zachholman.com, I realized I still wanted a nice foundation on which others could build their own Jekyll blogs. Jekyll's a lot of fun to use, but it can be a bit of a pain to set up. Today I'm open sourcing holman/left.

Left is the previous theme I had for zachholman.com: left-aligned, white-and- black, and simple. It features the font I helped popularize: Yanone Kaffeesatz.

Left is what I half-assed previously: it has clear directions for setting it up yourself, it removes lovely paid-for icon fonts from Symbolset that I felt funny putting in a public repo since that company is so cool, and it's fully MIT licensed without any silly attribution caveats.

Enjoy Left, and go forth and blog like a hacker.

Open Source Misfeasance

2012-11-20T00:00:00-08:00

DID YOU KNOW OPEN SOURCE IS A SWIMMING POOL FILLED WITH MILK SHAKES AND A WALRUS. Seriously it's amazing. I don't think people realize how amazing open source can be for your life, for your salary, and your company.

Life shouldn't be all about Linux device drivers and suicidal key value stores; build silly things. With a little spit-shining and a lot of dumb ideas, we can all grow to become the Notorious B.I.G. of open source. (Minus the guns, drugs, and eventual murder. Unless that's what you're into, I mean.)

Slides

Video

The Product is the Byproduct

2012-10-12T00:00:00-07:00

People in Silicon Valley perpetuate this idea that if you're smart enough, have an amazing vision, and keep pushing at it, then you'll end up with a great product. Take a look at startup success stories, though: a ton of them succeeded in spite of their original vision. A great product is closer to an accident. It's the byproduct of the environment you build at your company. This environment may actually be harder to build than the product itself, but you'll be left with a better everything by the end of it.

Slides

Video

Abusing Emoji in iOS and Your Mac 👑💩

2012-09-20T00:00:00-07:00

Like most fourteen-year-old Japanese schoolchildren, my social circle in Silicon Valley has embraced the usage of emoji, a subset of Unicode that uses pretty pictures as letters.

You can easily tell a story with emoji:

🎅 🚀 👬 🐟 🍕 🏩 🎥 🎧 🍉 🚲 🐓 🙈

For example, this string of emoji means "Let's go meet at Chipotle and build a nuclear fallout shelter out of pinto beans and discarded burritos". See? Emoji is efficient.

Apple's support for emoji in the last few years has been admirable. You can add an emoji keyboard to your iPhone or iPad by tapping through Settings ➡ About ➡ General ➡ International ➡ Keyboards ➡ Add New Keyboard....

On OS X Lion or Mountain Lion, just hit option + command + T in most text boxes and text areas and you'll be able to drag and drop from the character viewer.

Naturally the next step is to see how far we can take this.

Your computer's name and hostname

I don't know about you, but my computer is a dick. It keeps not doing all of my work for me. What a piece of shit.

So what better way to show our affection to your hunk of metal than to rename it as a literal steamy pile of shit? 💩

In the "Sharing" preference pane, you can set the computer name of your machine. Let's set it to a piece of poo:

If you have File Sharing turned on, your machine will proudly display its emoji in the Finder's sidebar on other OS X machines on your network:

But this is where we run into our first problem. OS X is smart enough not to set emoji as your actual hostname; it keeps a separate internal plaintext hostname alongside the emoji name. Unfortunately it sets that plaintext to Macintosh.local. I don't know about you, but I have a hard time attracting potential mates once they discover I have such a boring hostname. After setting your emoji computer name, be sure to click Edit and change it to something sure to entice potential partners, like i-smell-like-cheetos.local.

AirPort Extreme

They say the two hardest problems in computer science are cache invalidation and naming things, but they must not have had emoji.

I have an AirPort Extreme at home, along with an AirPort Express attached to some speakers. I decided to emoji those, too.

In AirPort Utility, you can rename your router as you see fit:

You can also name your actual wifi network as emoji, too:

There's some serious problems here, though:

Other clients: You can use emoji names for your wifi network and it works great if you connect to your base station with OS X Lion (and above), iPhone, or iPad. But if you run a more diverse network you're going to run into problems. Snow Leopard and earlier, for example, renders emoji as square boxes since the OS just didn't understand emoji until Lion. Your Xbox 360 also won't render emoji, but it seems to connect just fine. It appears that Windows clients will refuse to connect to any emoji network name at all. Might be a feature instead of a bug, though.

Time Machine: If you have a hard drive attached to your AirPort Extreme for use with Time Machine, you shouldn't name that drive with emoji characters. Your Mac will mount it correctly, but it'll spin indefinitely at the "preparing backup" phase. You'll likely run into the same problem if you instead use a Time Capsule, too.

iPhone, iPad, and iOS

In a few keystrokes you can turn your shiny, expensive Apple device into a shiny, expensive Apple device with an emoji name. Just go into Settings ➡ About ➡ Name and adjust it there:

This'll show up neatly on your iTunes sidebar:

While you're there, use emoji to name your iTunes playlists. For example, I use 🆕 for the last 100 songs added to my library, and 🔝 for my top 100 most-played songs.

Don't be stingy, now. You can use emoji as iOS folder names, too. Here I use a big ol' warning sign as a reminder to myself to avoid showing a couple of our internal GitHub apps publicly:

Wait, ignore that last bit.

Passwords

Turns out, you can use emoji as your OS X user password. It's probably not a good idea, but then entire civilizations have been built on bad ideas before. Oddly enough, if you drag emoji into the password box, a single emoji shows up as two characters:

You can't bring up the character palette at the password prompt, though, and you can't paste from the clipboard, so you'd never be able to log into the account. In other words, it's perfect security.

OS X Home Directory

Sure, this can't go wrong.

Let's create a new user:

By this point, OS X has figured out what you're up to and probably thinks you're a moron, so it stops you. You can't drag or copy and paste emoji into the "Account Name" box, so there's no way to create a home directory with non-legal characters.

Time to force the issue. After you create a user with a vanilla account name, you can right click it on the sidebar and select "Advanced Options". From here, OS X is apparently cool with emoji:

I chose a dress shirt with a nice necktie (👔). No one suspects the mild-mannered office worker.

Surprisingly enough, OS X takes one look at that respectable necktie and says "YEAH SURE LOOKS GOOD TO ME! IS THAT A FULL WINDSOR???"

Click OK, because this is certainly something that can't go wrong.

At this point OS X chugs along and creates the user. Log out, switch users, and behold, the most beautiful sight these eyes have ever seen: emoji in your menu bar.

ls has some issues with emoji files, but bash seems to handle things okay-ish (and note that Terminal.app supports emoji, which is new in Mountain Lion):

Finder, in contrast, seems not to care one bit:

After playing around with it for a bit, it looks like OS X handled it like a champ. Nothing overtly crashed, no processes were amuck in Activity Monitor. I recommend all serious technologists move their home directory at their earliest convenience.

🎊🎈 HOORAY 🎁🎉

I really hope with this newfound knowledge that you now feel confident enough to go venture out into the world and accomplish nothing of value.

Unsucking Your Team's Development Environment

2012-09-14T00:00:00-07:00

Success can bring many glamorous changes to your company: hiring more employees, getting free coffee, and giving everyone a private jet filled with cash and endangered African predatory cats.

Success can lead to less-glamorous problems, though. As you grow, your team's development environment becomes really important. How long does it take to clone, set up, and boot your apps? Can your employees still be productive on an aging codebase? How can you automate CI, hooks, and other setup for new projects? Is any of this fun anymore?

GitHub ran into these problems as we expanded our team tremendously over the last two years. Let's look at some of the ways we've improved our employees' development environments.

Slides

Video

How to Build a GitHub

2012-08-06T00:00:00-07:00

GitHub's been through a lot of growth the past five years. Expanding to two million users and almost seven million repositories can push the limits of how we interact with a tool like Git (which wasn't at all designed to work at scale like this).

This talk is about the systems we've built to handle that growth. Starting from a local Git architecture, migrating to a networked backend setup, then optimizing our disk usage with net-shard, and finally I talk about our newest addition, GitRPC, which we haven't talked publicly about until now.

This talk also covers the human side of things. We've gained 100+ employees in two years and we've never had anyone quit. That won't last forever, but I think it's a good indication of the type of company we've built. There are certain things you can do to retain employees, and by worrying about employee happiness you'll ultimately create a much better product.

Slides

Slides with Audio

Video

Coming soon.

How to Screencast Your Talk

2012-06-21T00:00:00-07:00

So you're nervously up on stage in front of hundreds of strangers about to give a talk, sweating profusely, petrified that you might get your own name wrong.

SOUNDS LIKE A GOOD TIME TO RECORD YOUR WEAKNESS AND UNCERTAINTY!

After my What They Don't Tell You About Public Speaking post made the rounds this week, I got a number of questions asking about how I record the audio and slide transitions of my talks.

QuickTime on OS X

There's a million ways to do this. Keynote, for example, has a recording function built directly into presenter mode, although it's difficult to tweak and to export. Beyond that, there's a million different apps you can use to do this, too. I try to stay as simple as possible: on my Mac, I just use QuickTime's Screen Recording feature.

Either before a talk on-stage or at home practicing my slides, running a quick screen recording session is pretty simple. Start a new Screen Recording:

...then hit record:

If you're on stage and on a projector, the trick is to get QuickTime to record your projected slides rather than your presenter display. Luckily, QuickTime makes it really easy. Before you start your slideshow, hit record, then mouse over to the other screen (in other words, the projector). It'll dim the screen and inform you:

Click it, then you're off to the races. It'll record your voice on your internal microphone (surprisingly well, too), and as you flip through your slides it'll retain all the transitions and little details you can't get from viewing slides online.

It's for you

The best thing about recording your talks is that it's a great learning tool. It's cliché, but force yourself to listen to yourself. It will utterly change your perspective. You'll hear all of the uhhhhhs and ummmmms you didn't notice at the time. That's good; listening to yourself talk is designed to make you angry enough to change those habits.

It's for them

As I mentioned previously, your mileage may vary when it comes to conference videos of your talks. Half of conferences won't film you, and the other half may take months to publish all their talks while organizers take a well-deserved breather post-conference.

So think about recording your own talk so you can post it on your site immediately after your talk. If you've wowed someone in the room, they'll be able to share the experience of your talk to their friends as soon as possible.

I use Vimeo for my screencasts and talks because they're a swell company.

It's mostly for me

Slides are great, but audio and video is better. Record your talks, because I want to see and learn from them. I'm totally selfish like that.

What They Don't Tell You About Public Speaking

2012-06-19T00:00:00-07:00

Looking back on a year of speaking at conferences, I'm rather flabbergasted that I managed to make it without my pants falling off mid-sentence or my laptop exploding in a fireball of self-doubt and international power cords.

I'd read all the blog posts and heard all of the advice: slow down, speak loudly, tell a story. But goddamn, no one told me I'd have to put my laptop down on the ground twenty feet away behind a couch because that's the only place the projector's VGA cable would reach.

Turns out there's all this other stuff to worry about, too!

The room isn't your audience

When you're on stage in front of a few hundred people, your brain is screaming at you DON'T SCREW UP IN FRONT OF ALL THESE PEOPLE. But these people aren't your main audience.

Run the numbers: most technology talks are in front of 50-300 people. That's your most important audience; after all, they came to listen to you. But if you post your talk online afterwards, you could reach thousands more. It's a different audience. You can choose to ignore this audience completely, or you can choose to embrace them.

Most conferences are a crap shoot when it comes to video. Half the time they won't record your talk, and the other half of the time it may take months before your talk is published.

Something I've been doing recently is making a screen recording of my talks using QuickTime on my Mac. It'll record both my voice and my slides as I flip through them. It's a much better experience than just posting contextless slides.

Last-minute prep

There are a number of things you'll want to take care of before jumping into your talk:

Silence your phone. That means airplane mode or non-vibrate mode. You'll (hopefully) be getting tweets or emails mentioning you during your talk; trust me, feeling your pants vibrate will wreck your concentration.
Crank up your screen brightness. You don't want to be fighting to read your notes. You should be plugged in, anyway, so don't worry about draining your battery.
Rearrange your presenter display. Rather than just mirror your slides, you should be using a separate presenter display that shows your slide, your next slide, a timer, your notes, and anything else you'd like to have up on-screen. If you use Keynote, you can customize this screen.

Ground your talk in reality

I've done one or two talks that I thought were great ideas initially: projects that weren't finished yet, things that I thought would be interesting to talk about, and so on. They're talks I regret. Talks should always be reactionary rather than anticipatory: they're going to come off as more natural, more interesting, and above all, more valuable.

Think about writing a detailed blog post before you speak on any subject. That way you'll know your comfort level with the information, and, more importantly, you can gauge the reaction of everyone else. Is it interesting? Are you wrong? Does anyone care?

Your talk gets interesting when it's over

My favorite part about talks are the questions afterwards (if your conference allows it). Don't shy away from them. They're a great barometer of how well you know your material, and, most importantly, whether your audience "got it". If you plan on giving your talk again, take special note of what happens in the question-and-answer section. It's a goldmine for improving and changing your talk for the next time through.

Be excited

There's one mistake I consistently see made by speakers both novice and experienced: they're not excited about their talk. Changing this one thing will completely, utterly change the perception of your talk for the better.

You're on stage, ostensibly talking about something that interests you or makes your life better or saves you time. Be fucking excited about that. Let your enthusiasm bleed through. People absolutely react to emotion. The opposite is just as true: a passive voice on-stage will lead to a passive response by your audience.

These are some of the many things I've picked up on while giving talks, but it's certainly not a comprehensive list. Public speaking's all about thinking on your feet, of reading people. Like everything else, it all gets better with practice.

Git and GitHub Secrets

2012-05-22T00:00:00-07:00

We tuck a lot of features away on github.com.

Sometimes the UI just hasn't been fleshed out. Or we have bigger plans in mind for the feature in the future. Or it just hasn't been finished yet. But we still want to give you the flexibility of using that feature today.

The same can be said about Git. If you've ever looked at the manpages, there's feature after feature and option after option in its binaries. Part of the strength of Git and GitHub is having access to those features when you need them, and getting them out of your way when you don't.

This talk covers both Git and GitHub: different tricks I've picked up after two years at GitHub, helpful advice on common gripes I've seen in support tickets and tweets, and just general nifty things that make you a faster, more capable technologist.

Photo credit: Sheila Menezes.

Video

Slides

How to Survive Tech Conferences

2012-04-27T00:00:00-07:00

For a large part of the last year of my life I've had the good fortune of being able to speak and attend a number of technology conferences. Big, small, corporate, indie, local, international... conferences come in so many delightful forms.

Conferences can be a lot of fun, but they can also be mentally and physically exhausting. Here's what I've learned.

Connect with a local

Some people you meet are going to be special.

Every now and then I attend an event that transitions from interesting to memorable. It tends to be locals who show you the way. Embrace the unplanned. Instead of going to bed early, think about taking someone up on their offer to go a town over to a hidden absinthe bar where everyone wears goofy hats. Or take a day trip to pet some cheetahs in the surrounding wine country. Or go back to someone's home and play Rock Band with twenty new friends. These are the memories that stick with me, and I experienced them only because locals took it upon themselves to show off their area.

Look for open, friendly people. They're everywhere. They know the best tips, and they are likely eager to tell you and show you their city.

The reverse holds true, too. If you're playing host in your city, pay it forward. It's your city. Show it off. Attendees are traveling for a reason, and more often than not, showing them your favorite place in the city would thrill them, too.

Take photos

I don't typically check into Foursquare or anything like that, but I do try to take a lot of photos. They tell a story and help me relive specifics of the trip.

I try to geotag every photo. When you're traveling somewhere different — particularly in a foreign country — it becomes really difficult to relate all of different locations you visited to each other, particularly if you're taking cabs or public transportation. Geotagging photos gives you a very visual way of piecing together your journey when you load them into iPhoto or Aperture later.

If you're overseas, usually you don't have a full data plan on your phone 24/7, but if you switch off of airplane mode it'll still pick up the GPS coordinates and geotag any photos you take.

If you're like me and like taking your DSLR out for some shots, it's a pain to go back and geotag those manually. There's a few solutions, but the best one I've found is gps4cam. Before you start shooting, press the button on your phone to start, and then it'll record your GPS positioning every minute or so. When you're done, click finish, and then take a picture of the QR code on your phone. That syncs up the clock on your camera to the clock on your phone so it knows where you were when you took those photos. Then, load your photos on your Mac, run the simple gps4cam sister app, and it'll go through all of your photos, geotag them and timesync them to the correct time from your phone. It's kind of like magic.

Get connected

Traveling is sometimes just one long quest to find good wifi, especially if you're not on your home mobile network. And, let me give you a hint: conference wifi almost always sucks.

You can buy a SIM card for most phones, but I've found that to be a bit of a pain, for a lot of reasons (the need to swap out SIM cards, and weird edge cases like iMessage getting confused as to which number it's on). If you're going to be traveling a lot, I'd suggest looking into getting an unlocked mifi. It's basically internet-in-a-box: buy a quick 1GB or 2GB data plan SIM card when you arrive in the city, toss it in, and you have wifi for up to five devices. It also means you can make four new friends if they desperately need connectivity, too.

I picked my mifi up from Amazon unlocked for a hundred bucks and change.

See the talks

The common rally cry is that conferences are worthless and that you really go only to network and socialize. I think that's shortsighted. I've been surprised by talks in the past. Try to find talks about libraries or languages you haven't been exposed to. Even if you don't understand all of the material, you likely will come up with some interesting comparisons to your own world view.

If you're planning on giving your first talk in the future, pay attention to the flip side of talks: what do you like about the speaker? Are you bored? Why are you bored? What would you change? It's pretty easy to drift into passive mode, where you'll miss these important questions, so take some time to consciously think about these things.

Monitor

Another not-so-secret secret is the conference backchannel. Every conference I go to I'll add the conference hashtag as a saved search in Summizer so that I can always see the new tweets about what's going on. It lets you keep track of the conference pulse, which is helpful for conversation topics later on: "Were you at her talk? It was hilarious!", "What do you think about the drama about the sponsor's booth?", and so on.

You'll also be able to see what people are doing after the conference- don't be afraid to ping new people and see if they wouldn't mind another joining in. If they're tweeting about it, they're probably happy to meet you, too.

Reconnect

The most lasting part of a conference is reconnecting with new friends after the conference is over. Our industry is not that large, particularly if you're in a smaller community centered around a language or framework. The people you meet today will have a tendency to show up at the conference later this year halfway across the world. It will be a welcome sight to see familiar faces, and they'll be able to introduce you to new people, too.

Don't be afraid to follow people on Twitter or GitHub during a conference and keep the lines of communication open. Sometimes it doesn't take much to maintain lasting friendships in situations like these... just a quick "hi" now and then.

Carry on

Conferences can be professionally enlightening, and, more importantly, fun. Go and make the most of them. And if you see me, say hi. We'll talk about the conference wifi together.

Aggressively Probing Ruby Projects

2012-04-19T00:00:00-07:00

A Ruby Code Analysis Project

I just gave a talk in Kraków at Railsberry where I announced Hopper, an open source Ruby code analysis project.

Hopper

Hopper is a Sinatra app designed to pull down tens of thousands of Ruby projects from GitHub, snapshot each repository into ten equidistant revisions, run them through a battery of tests (which we call Probes), and hopefully come up with some deeply moving insights about how we write Ruby.

Codestat

Codestat is the live version of Hopper. It's available at codestat.us.

The Future

Codestat is a bit of a work-in-progress. It's running on an underpowered instance, and I'm pretty sure I might be blowing out the database from time to time as we settle on what makes sense to model all the data.

Hopper is one big experiment. I think where it is today is a long throw away from where it could be tomorrow. I welcome your thoughts, issues, and Pull Requests as we build something nifty together.

Slides

Video

Ruby Patterns from GitHub's Codebase

2012-02-29T00:00:00-08:00

There are a few specific things we've done at GitHub to help our maintainability and reliability of our Ruby apps. Focusing on improving documentation, optimizing the first-run experience, splitting out our API as Sinatra apps, and being careful about how we ship impacting infrastructure changes has helped us out dramatically.

Slides

Word of Mouth

2012-02-25T00:00:00-08:00

Word of mouth is not just about adding a Facebook "Like" button to your site. How people talk about your product is entirely defined by how you build that product.

Slides

Video

The Apple Voice

2012-02-02T00:00:00-08:00

Most startups don't have the luxury of meeting every one of their customers. They can't explain the case for their product in-person.

Instead, we market our product with words. We craft those words with our voice.

The Apple Voice

Apple commands their words exceedingly well. They aren't the originator — or even the owner — of their particular voice, but they are the most visible.

Mechanically, The Apple Voice is characterized by short, declarative sentences that are informally and personally delivered to you with a hint of smugness.

Our most amazing iPhone yet. 10,000 songs in your pocket. We think you'll like it.

For Apple, this voicing evokes two feelings:

Accessibility. Formal tones feel heavier and more complex. The informal tone emits a feeling of simplicity, of fewer barriers to entry. Apple wants their products to be simple.
Quality. Smugness is always a gamble — and you can lose that gamble — but when executed well it can set your product's quality apart from the rest. Apple wants their products to be high quality.

As a consumer company, those feelings are appropriate for Apple. The Apple Voice is a far cry from Oracle's voice or Kaiser Permanente's voice, which both target very different markets.

The Apple Voice, however, has a lot of crossover to most startups.

The Apple Voice in startups

This voice is all over. Each put their own spin on it, but companies like 37signals, Square, and Simple use similar voicing in their copy. Square and Simple both use their words to mitigate often heavy-handed financial terminology. 37signals aims to assure us that our company's data is safe in their high-quality, simple product.

The feelings Apple targets dovetail with the feelings many startups target. It's a good, complimentary voice to select for your startup.

And you should select a voice

This stuff is important. You should really think through what voicing is appropriate for your company's copy, for your announcements, and for your tweets. It impacts you in subtle ways. A well-written post is more likely to be tweeted and linked to. Good copy could encourage more people to buy. Comforting your customers' fears encourages them to remain customers.

Maintaining a standard voicing is hard for even one person. As your company grows, though, it becomes exponentially more difficult to maintain a consistent voice as each person contributing to your copy dilutes your initial vision.

Pick gold standards

The best way to combat this is to select gold standards of work: the pieces written by your founders or executives that can stand as examples of how each employee can target their writing.

Steve Jobs was — to put it lightly — a fairly controlling personality. He certainly had a lot of control over marketing copy, with the classic "Here's to the Crazy Ones" ad spot edited and written in part by Jobs himself. This crossed over to product announcements, too. Take a look at the recent Apple launch of iBooks 2. As a new employee to the Keynote stage, Roger Rosner almost certainly watched a number of Jobs introductions as he fairly successfully emulated Steve's way of demoing a new product.

Tim Cook hasn't yet issued any informal press releases, but when he does it wouldn't be surprising to see him emulate the writing style Jobs created in the original Thoughts on Music anti-DRM post. It's an expanded form of their ad copy: informal, persuasive, and data-heavy.

GitHub's gold standards

On GitHub's blog, the main posts are either technical or announcement-related. There are two specific gold standard GitHub pieces that have directly influenced most other GitHub blog posts.

Tom Preston-Werner's 2009 post on How We Made GitHub Fast characterized GitHub's technical posts. Extremely detailed and formally written, it conveys an appropriate sheen of consummate professionalism. This directly impacted how later technical posts were written, particularly in regard towards downtime. When the site goes down, it's important to plainly state the case, explain what happened, and detail what is changing to prevent this in the future.

Chris Wanstrath writes great launch posts. (His CodeConf announcement post, for example, is just impressively ballsy.) He collaborated with Kyle Neath on the post for the launch of Organizations in 2010, and that style of post led directly to the Issues 2.0 launch post and the Enterprise launch post. Most GitHub feature launches now employ this point-by-point, graphical, partially technical writing style.

GitHub encourages employees to write their feature and announcement posts themselves. As more employees are hired, these posts can be pointed towards as gold standards in order to help get everyone on the same page.

It's important to identify your company's voice. It's important to decide who is in charge of different aspects of your voice, and how you can keep that voicing consistent even as you grow larger and larger.

Apple does a great job, and if their perspective is relevant to your own, take a look at emulating them and putting your own spin on their voice. Consistent, clear copy helps craft your experience.

So go craft one.

Scaling GitHub

2012-01-26T00:00:00-08:00

A month after launching, GitHub hosted one thousand repositories. Three years later, we host over three million. In the same time we've gone from one thousand users to over a million.

This type of scaling presents some interesting technical challenges. I'll dig into our development workflow and how we address concepts like scaling, deployment, code review, and testing.

It also presents some interesting business challenges, too. How you grow your company from three employees, how you work in teams, and how you split your app up into services all help ensure that you'll be able to react to your product's growth.

Slides

References

Women Should Do Startups

2011-12-12T00:00:00-08:00

Yesterday Penelope Trunk wrote a guest post on TechCrunch that told us all to "Stop Telling Women To Do Startups".

Pardon me while I do just the opposite.

Startups don't need to suck

Trunk's article has a lot of arguments that just aren't relevant to the problem of getting more women in startups. Most of them are an indictment against startups in general, and startups simply don't have to work that way.

[Women] are complaining about the lack of jobs with flexible hours. And I don’t see anyone on TechCrunch addressing that when they address women.

I don't mean to sound like a broken record, but hours are bullshit. You don't need to enforce 9-5 hours at a company. You don't even need a full 40 hour work week. Companies like GitHub, Heroku, Square, Simple… we're still in the minority, but I think it's safe to say that it's okay to be successful without working 90 hour weeks and forcing everyone to come in at arbitrary hours.

But I can tell that all three times I’ve done it, raising money for a startup has been hell, so I think we should really be asking why anyone would want to try to convince someone to do it.

Yes! Definitely! That's why I argue "women should join startups" and not "women should join startups and then try to raise a lot of VC money". Raising VC is important for some companies, but the number of companies that need VC is plummeting each day. For web startups, we have open source frameworks, technologies, and methodologies with decades of investment thrown into them. It's easier than ever to bootstrap a business. VC doesn't need to be a limiting factor anymore.

Straw men

There's some crazy statements in Trunk's article. Indulge me.

Whoever started the TED Women’s conference is pathetic. Which would you rather say you spoke at? TED? Or the TED Ghetto?

I'd be thrilled to speak at (and attend!) TEDWomen, and I think it's horseshit to call it a ghetto. TED decided that the topic of women in tech is so important that they devoted a conference to the topic to try to help solve issues of diversity, exposure, and to perhaps help counter close-minded guest posts on sites like TechCrunch.

The people trying to give solutions are as lame as the people pointing to a problem.

Pro tip: if you ever see an argument disparaging both raising awareness and presenting solutions, then something is wrong with the argument.

Try that for a few years, and then tell all the other women you know, who are out-earning the men they know, or taking care of kids, to trade their life for startup life.

That's an appropriate argument if everyone were money-driven. Startups do offer decent money compared to non-tech industries, but the vast majority of people I know in the industry do it out of love and passion for technology rather than money. We do it to build products, to change the world, and to have fun. If money were our motivator we would have studied asbestos case law.

Everyone should do startups

I want more everyone — including women — to be exposed to the idea of working at a startup or founding a startup. I think it's one of the best careers on earth. More than any other industry, we're able to work on interesting problems, create new things, maintain flexible hours, and impact lives across the entire world minutes after we launch a product.

I worry about girls and boys in middle school and high school who are turned off from our industry entirely because they've been influenced early on that programming is only for white, middle-to-upper-class, geeky boys. It's important to raise visibility to everyone — especially young women — that our industry can be both fulfilling and accessible to everyone.

Women should really do startups

I think, for certain women just as much as it is for certain men, that working in a startup can be a wholly positive experience in their lives. That's why we should encourage more women to join startups. But as much as that's a nice, benevolent gesture, I also want this for entirely selfish reasons: I think having more women in tech will improve our products, improve our work environments, and improve our industry. Today, startups mostly have a singular (and male!) perspective. On top of that, it's hard enough to find good talent lately. Hiring for tomorrow means we need to snatch up all of the killer talent that both genders can provide.

Gina Trapani gave a wonderful talk at CodeConf last year about the importance of community in open source software. One aspect was diversity. If you only surround yourself with like-minded individuals, you're going to end up with solutions that suit that minority. It's hard to change the world that way. By adding different perspectives to your project or company, you're able to position yourself to better address the needs of a broader public.

I think it's harmful for such a visible publication like TechCrunch to suggest we shouldn't encourage women to join the startup world.

I think we should all be telling women to do more startups.

From "Hack" to "Popular Project"

2011-11-23T00:00:00-08:00

Last Monday, I sat down to hack.

After a few hours, I open sourced the code. By the end of the week, it had 1,000 watchers and 70 forks on GitHub, and 500 upvotes on Hacker News.

It's my favorite example of open source recently. Here's why it worked.

The project

The project was spark. It's a shell script that lets you graph tiny sparkline graphs from your command line. A quick example:

$ spark 0 30 55 80 33 150
▁▂▃▅▂▇

Common ground

I wrote spark in bash shell. From the start, this gave me a huge audience. Shell is a glue language; it cuts across disparate communities as a common foundation that we can all use. If spark were just another Ruby script I wrote, I'm fairly certain it would have been largely ignored. Requiring a nonstandard runtime already cuts out a big chunk of the market that might not have it installed or aren't interested in digging into another environment.

It's fun to bring different communities together. You get exposed to very different perspectives.

Simplicity

As a shell script, all you have to do is copy that single script into your $PATH. Done.

Don't underestimate simplicity as marketing. If your project is easy to try out, you reduce the time from the initial "oh wow!" statement to the final "I'm going to tweet/upvote/fork this" statement. Every minute that passes between the two reduces the chance that someone will end up sharing your project.

Code can be fun

spark is a silly little project that took a couple hours to come up with the idea, code, and to ship. The concept isn't very difficult to wrap your head around, and it's really easy to reimplement in a higher-level language. What's more, sparklines aren't complicated, scientific graphs; spark is designed to be a fun project.

I exploited this. From the start, my README had some interesting examples: commits by author, number of characters per line of a file, and the magnitude of earthquakes over the last 24 hours. I added a wiki page to keep track of other cool usage of spark (which includes zany things like a sparkline of Beijing's air quality).

Soon after launch, I added a wiki page for alternative implementations, too. Very quickly a small community arose, with some awesome results: implementations in Ruby, Python, Haskell, Java, Lisp, and many others. An implementation in obfuscated C whose code actually looks like a sparkline. An npm package for adding spark to Hubot. The creator of Redis, Salvatore Sanfilippo, said it best while creating his own implementation:

Sometimes coding something useless, funny, from scratch, is the best way to relax before the next burst of work.

Try to support people's playful moods. Everyone gets in a rut sometimes, and they're just waiting for you to inspire them out of it.

Okay, your turn

spark is somewhat unusual. It's a generic, simple, interesting library that appeals to a broad segment of the developer population. But different aspects of spark's appeal can stand alone and be useful in your own projects.

Don't be afraid to experiment. Experimenting with sparklines drove a lot of interest to my project, which was great. That was the least important part, though. Seeing everyone excited to reimplement my project? Seeing developers rush into applying spark to crazy datasets? Getting message after message of helpful pointers on where my code could be improved? All of these were what made this project so much fun.

It all stemmed from a brief moment of, "hey, this afternoon I'm going to sit down and hack on something fun".

Swearing

2011-11-09T00:00:00-08:00

Swearing is a strong tool. It can be a particularly strong tool during presentations.

Emotion

When it comes to your talk, I want you to avoid bullet points. I want you to avoid recitation. I want to learn and to experience what pains and problems you faced, and then discover interesting solutions that grew from them.

I want a story.

Humans are storytellers. The best stories convey a sense of emotion. Emotion helps us identify with the speaker. Without fail, if I can plainly identify with what the speaker is going through, I'm going to remember that talk. Did your servers burn down? Is your app twice as fast? How did you handle all of those new hires? Connect with me emotionally, and I'm going to better apply what you say to my own life.

As storytellers, our tools are words. Some of our most evocative tools are swear words. The emotions they raise can't be reached as succinctly with other tools. They're powerful. When chosen with deliberate consideration, they aren't a cop-out; they're the strongest way to connect with a particular audience.

I want a story. I want emotion. I want the entire toolbox at my disposal, not a subset.

Persona

I understand the argument that you shouldn't swear at all; I really do. If that's your considered perspective, I'm happy for you. That's not me, though.

I maintain separate voices in long-form essays, over Twitter, and in talks. Together, it's a crafted persona. That persona includes edge, informality, and passion for what I do. Sometimes I'll swear to invoke that persona. Usually it's no more than 1-3 times on my slide deck, and I seldom swear much outside of my slides. My deck takes 2-3 weeks to design and practice, so I can assure you my words are not thrown in haphazardly. It's all designed to support my persona.

This persona has served me well, judging from how people react to my talks, tweets, and posts.

Audience

The common objection raised to swearing in talks is that it is bound to offend someone, so why risk it? Why automatically reduce your potential audience?

I don't view it this way. I'm less concerned about my overall reach than I am with connecting with my audience. Put another way: I'm content with losing a handful of people if that means I connect much stronger with everyone else.

Your reputation is your brand. Just like a company, your brand can be deeply impacted by a small group of passionate followers. I've been seeing this for years- the same avatars retweet me, the same names show up in discussions about me, the same sites help promote my projects. I'm fortunate and humbled to have these people at my back.

I wouldn't have nearly as many of them if I played it safe. I enjoy keeping an edge, and they respect that. Someone else could construct a beige persona and cultivate a following, but that would be less effective for me because I'm not nearly as good at fitting that personality.

For me

At the end of the day, the talks I give are intended for me. I don't know any other way to do it. I want to give talks that would interest me as a member of the audience. The voice I choose, what words I project on a screen, and how I present myself are all part of the talk.

I'm just telling my story.

Stories From a Music-Fueled Distributed Streaming Bender

2011-11-07T00:00:00-08:00

I gave the closing keynote at BACON in London about Play, GitHub's internal music server. I also merged the next branch into master, which was a months-long effort to make Play possibly the greatest thing in a million milliseconds.

Play can be found on GitHub, and you can browse the Play organization on GitHub to check out our clients for iOS, Mac, Windows, Android, and other projects we've open sourced.

Slides

Video

The video for this talk can be found on Vimeo.

Hubot Play

2011-11-07T00:00:00-08:00

Guy walks into a bar.

Bartender glances at his shirt, which proudly proclaimed "INTRAMURAL FIELD HOCKEY CHAMPIONS 2002". Bartender comments: "You know, that shirt reminds me of a story I once heard.

"A team of researchers ended up shipwrecking their oceanliner on a beach. Fearing death, they built shelters and huddled together for warmth. One researcher, fed up with another's statement that increased wine production in Detroit led to the rise of Marxist sympathizers in Maryland, stormed off, left the beach, and hailed a nearby taxicab."

Introducing play: your company's DJ.

Edit: in April 2012 I announced a new version of Play.

play

We use play to play music on the speakers at work. It tallies up votes and plays what people want. And all of it's available through the web or through Hubot.

Suddenly, a screencast.

Don't Give Your Users Shit Work

2011-11-02T00:00:00-07:00

The problem with shit work is that no one likes doing it, but an awful lot of people say they do.

Shit work

Take a look at Twitter Lists. The idea behind Twitter Lists was that users would carefully cultivate lists on Twitter of different accounts they're following (or not following). These could be divided into lists like Family, Friends, Coworkers, People I Find Mildly Attractive, People To Murder, People I Find Mildly Attractive And Want To Murder, and so on.

The problem is that, anecdotally, no one seems to use Lists. Twitter is filled with users who have carefully made a few lists, and then promptly forgot about them after they realized their clients don't make it as easy to read List tweets as it is to read tweets from people you follow.

This is why I was never fascinated by Google+ and its concept of Circles. You have to go through entire sub-communities of your friends and drop them into arbitrary groupings. That sounds like shit work to me. What happens if I get really hammered with a Business Acquaintance and he becomes a Close Drinking Partner? Do I move his circles around? What happens if we hire him? Is he a Coworker and a Close Drinking Partner? The last thing I want to have to worry about is continually micromanaging another facet of life. This is important, since Google+ Circles is allegedly about privacy, and if you don't continually cultivate your circles, you could inadvertently send out the wrong update to the wrong subset of contacts.

Smart work

Facebook used to have this problem. They went through a couple, multi-year iterations of Groups. Initially — say, around 2005 or so — groups were outlets for inside jokes. Not a lot of meaningful communication happened. Then Facebook rightfully realized that they could have a real impact. They added Friend Lists, with heavy-headed suggestions to create lists for family, friends, coworkers, and so on, much akin to Google+'s circles.

Recently they revamped Groups and their whole privacy permission structure. Today, Facebook can anticipate most of what you want to do:

I get to decide whether to send this status out to close friends, my work network, my school, whoever I want. And I don't need to set those groups up. They already know who's in my work network, who went to school with me, and who lives where I live. Your product handles the smart work, and I won't have to do the shit work.

This doesn't work for all features in all products, of course. A stranger could join my college network, friend me, get me to accept the friend request, and then see statuses directed at my classmates. That seems unlikely, though. More often than not, letting your app handle the shit work is going to be better than letting your users handle it.

Don't embrace the shit work

Some people still like shit work. They can spend an hour moving Twitter accounts to special Lists, and then at the end of it look back and say "Boy, I spent an hour doing this. I really accomplished a lot today!" You didn't. You did shit work.

One of my favorite posts is Merlin Mann's Mud Rooms, Red Letters, and Real Priorities. His main point is that adding an assortment of labels, tags, and priorities to your email inbox only serves to give you the illusion of getting work done. Either something is important, or it isn't. You don't need five levels of priorities to decide that, and spending time categorizing isn't real work.

The same is true in any product. We need to get out of this idea that the act of spending time on a project means that you spent your time wisely. Sometimes you're just wasting your time.

Don't give your users the shit work

I used to carefully craft a bunch of buddy lists in my instant messenger. Friends From Home, College Friends, Bay Area Friends, Work, Previous Work, Current Work… it kept growing and growing until I suddenly realized how fruitless it was for me. Then I merged everyone into one big group called "Humans".

Simplify. Don't give your users the shit work.

Slide Design for Developers

2011-10-24T00:00:00-07:00

So I gave this talk called How GitHub Uses GitHub to Build GitHub. Someone submitted my slides to Hacker News, where it stayed at #1 for most of the day.

This was pretty strange to me at first.

My slides are not designed for people who didn't see the talk in person. They're designed to support my words, not some online audience. What's more, many commented that they found the design of the slides to be noteworthy. I'm expressly not a designer.

Working on your slide design pays off for the audience in front of you and for the audience online reading your slides later. I learned a lot designing this talk, and I think it can be helpful for you, too.

Colors

Color is the very first thing people will notice. It should also be the very first thing you think about.

Head to a color site like Colour Lovers and find a palette you like. Pick colors with a lot of contrast- it gives you a lot of flexibility with text, backgrounds, and objects. In my GitHub talk, I have around four colors I use frequently, and 8-10 total (lighter green to augment a darker green, lighter blue for my dark blue, and so on).

Size

Make your text huge. And then get rid of half of the words and make it huger. Almost all of the presentations I've ever seen at every conference screws this up.

Most of my text in my entire deck is at least 90pt. Usually I like to sit around 150pt, with spikes up to 300pt or more. You cannot get large enough.

For the curious, I use Yanone Kaffeesatz as the typeface for both my slide deck and the headings on my blog.

One of my favorite tweets from my New Orleans talk said "Great slide design- I was way in the back and could read every single word!" Forget the people in front of you: design for people three rooms away from you.

Words as Shapes

I took one design class in college. One of the most fascinating assignments they gave us was a study of shape: you get one letter, in one typeface… do something with it. The idea was that the severe limitation forced you to be creative with duplication, rotation, scale, alignment, and whitespace. It opened my mind to a lot of possibilities I hadn't thought before. Letters themselves can be part of the design.

Slides give you the same opportunity. The easiest way to make your slides visually interesting is to play around with the physical shape of the letters that constitute the word. Line things up. Don't line things up. Shift things around. Worry about pixels. Almost every single slide in my talk is a different font size, since I want things to work off of previous words, lines, and so on. Text sizes of 94.5 points are not uncommon in my deck. They create a much more interesting visual than throwing a random bullet point on-screen.

Repetition

Humans love repetition. It's one of the tricks used in lots of disciplines. The best jazz soloists are capable of starting a melody, repeating it, and then playing with it after the audience has identified with the repetition. The best storytellers will repeat the same line throughout a story to build a sense of familiarity, of excitement. Slides are no different.

Steve Jobs did this often. Before moving onto the next product announcement, he'd spend thirty seconds and go over the same information he just presented. It's a very simple way of keeping things memorable for your audience. I make this explicit by giving recap sections big green stamps in the upper corner saying "RECAP". I also giving the start of each section of my talk bright orange backgrounds with colorful, bold text. Simple reiteration is important.

Simple reiteration is important.

Worry about it

A good set of slides won't magically make your talk great. But a great talk is really hurt by terrible slides. Spend some time thinking about your slides. Put yourself in your audience's shoes: is this readable? Is this interesting? Should I pay attention, or should I get my laptop out and hack until lunch?

I'm certainly not a designer, but it's really remarkable how little design you need to put yourself far ahead of most talks. Huge text. Consistent colors. Less words. Worry about those, and it will already put you far ahead of the pack.

Scaling GitHub's Employees

2011-09-28T00:00:00-07:00

GitHub has been pretty public about how we work. We love to write about it, tweet about it, and give talks about it. But there's usually a lingering question of whether this type of workflow scales.

It does.

It scales.

We do things differently at GitHub: we work out of chat rooms, we don't enforce hours, and we have zero managers. People work on what they want to work on. Product development is driven by whoever wants to drive product.

I'm GitHub employee number nine, and although I wasn't there at the beginning, I've been hearing and reading the same things since even before I was hired a year and a half ago: GitHub really has a great work environment, but it's not going to scale as they grow. The common sentiment was once GitHub grew past five employees, they'll have to start changing their strategy.

Once we made it to five employees, we heard the same thing about ten employees. Once we made it to ten employees, then they talked about twenty. Then thirty. Today we're at forty employees, and, if anything, we're even happier with our way of working than ever before.

Code gets shipped fast

Central to scaling GitHub's humans is a streamlined way to deliver code. With each additional employee added, you're exponentially growing potential pain points as communication paths inside the company get more complex. Building more barriers to product development is not the answer.

Pull Requests are our major breakthrough. Scott Chacon went into great detail about how we use Pull Requests at GitHub. I gave a talk on it, too. Pull Requests mean we can do away with code review meetings. Pull Requests mean we can quickly and safely deploy features. Pull Requests mean our designers and developers work together in one place.

Pull Requests are the way we're able to continually improve our product quickly without sacrificing code quality.

Break apart the company

Companies like Instagram, Quora, and Reddit get a lot of press and buzz, but GitHub's bigger than all of them. Combined. We're still a small company, but at 42 employees and counting, we're no longer a tiny company.

We have very little hierarchy in GitHub — on some days our CEO ships more code than the rest of us do — but as we've grown larger we've let natural breaks in overall development happen. Embracing these as they happen is critical. We're far past the point where any single person can monitor every changed line of code.

We have natural groupings: a dozen or two work on the main Rails app, a small team works on GitHub Firewall Install, a couple are in charge of GitHub Jobs, one works exclusively on the Git core team, and we break out into a number of platform-specific teams like the iPhone app, the Mac app, and open source projects like Eclipse, libgit2, and others. There aren't a lot of barriers between teams, so we encourage you to move between teams as your interest allows.

These natural groupings let specific people focus on and own those areas. Those teams are in charge when things break. Those teams are in charge of improving the product. Our ability to trust individual teams to work independently allows us to tackle more and more projects.

Automate, automate, automate

Another thing GitHub does well is automate tedious — and important — tasks. There's a very strong culture of building mini-apps and Hubot scripts if it helps with automation.

There's two reasons for why we push hard on this. The first is most obvious: you're letting a scripted process save you time so you can focus on doing real work. The second is more subtle: automation reduces institutional knowledge. Institutional knowledge leads to a minority group inside of the company retaining answers. That forces new employees to bother those few in order to make impactful changes. It becomes a very verbal, synchronous process, which we try to avoid.

By automating deploys, a brand-new GitHubber can type hubot deploy github to production and deploy changes on their first day without needing to read up on how our deploy script delivers code updates to 60+ servers. By running tests automatically for each pushed Git branch, each developer doesn't have to find out how to get CI to run their tests. By scripting commonly-used Graphite queries into Hubot, each employee can generate graphs of application exceptions, deploys, and Twitter mentions to @github to visually determine if there's a problem with a recent deploy without having to learn the specific Graphite syntax.

The Uphill Battle

This stuff doesn't come easily, but it unfortunately leaves easily. Figuring out ways to streamline, to improve your process, to grow your company as you grow your employees is a constant struggle. It's something that should be continually re-evaluated.

Is this workflow going to work for us when we're 500 employees? Likely not. But core values and ideas last. Figure out what your core values are, and adapt and refine them as you grow.

How GitHub Uses GitHub to Build GitHub

2011-09-21T00:00:00-07:00

Build features fast. Ship them. That's what we try to do at GitHub. Our process is the anti-process: what's the minimum overhead we can put up with to keep our code quality high, all while building features as quickly as possible? It's not just features, either: faster development means happier developers.

Slides

Video

References

Customer Support Doesn't Have to Suck

2011-09-07T00:00:00-07:00

We all have this feeling that fielding support requests is a monotonous job we ought to dread.

We shouldn't. It doesn't have to suck.

I was at a dinner in Boulder for the 2011 Rocky Mountain Ruby conference, and Hoyt (@jonmagic) asked a simple question about software support to a table-mate:

When was the last time you did something particularly nice for a customer?

I don't think Hoyt intended this to be a particularly interesting or deep question, but I think it's much more important that it looks on the surface.

Support can substantially impact people

If you're in a position of supporting a product — answering emails, fixing bugs, responding to people over Twitter — you are in a position to improve lives. It sounds overly dramatic, but consider a support request:

I want something that I currently can't attain in your product: a specific end result, a feature, a bug fixed, or sufficient in-product help so I can do it myself.
This desire impacts me emotionally: if I'm helped, I will be happy, or I'll avoid feeling frustrated, or I'll be impressed.

The second aspect is most important. Support requests are almost always tied to emotion, even if the asker doesn't herself believe it. A lot of the time, addressing someone's concerns is as much about protecting against future frustrations rather than improving today's complacency. Fixing someone's bug may only lead to a three-second "oh good, they fixed that" response, but that short-lived relief is relief. Do that enough times, and you turn customers into happy customers. Do it consistently and frequently, and your happy customers turn into devoted customers.

Going over the top

Hoyt's question was more about what happens if you go "over the top". Are you just going to give your customer a paste of steps they can take to fix their problem? Can you spend some time and give them an executable script? Can you manually go into the database to do it yourself so they don't have to lift a finger?

Do they have a completely, irrationally-involved support request you usually blow off? Can you fully address it at least one time this month?

Can you read between the lines and recognize someone's actual desires before they do? If they're asking for x, give them 5x. Go over the top. Lose money on it. Waste time on it. Don't do it for the marketing exposure: do it because you can make someone happy. If they tweet or blog about it, great, but if that's the primary reason you're doing it, they'll know. Do it for the right reasons.

We're limited by time. We're limited by money. "Over the top" support responses may only be feasible in your company every few weeks. Or months. Or even more. But there will be times where it is possible. When that happens, consider whether you can help. In most cases, the other party won't even notice the lengths you've went to. That's okay. Over time, people will notice.

All too often we forget that many companies aren't built primarily to make money: they're built to solve problems. Money is the intended side-effect of that. Connect with customers emotionally and you'll start seeing happier humans.

Glue Languages Make You a Better Coder

2011-09-06T00:00:00-07:00

Glue languages are used everywhere. While you may identify as a Pythonista, or a Lua fiend, or a C++ developer, we all end up congregating in some common spaces. On the web, this means JavaScript. On the server, this means shell. These are our glue languages: languages that bring our disparate programming communities together.

JavaScript, shell scripting, SQL, and glue languages like them are ubiquitous. Grab any UNIX box and you can dive right in with a shell script. JavaScript is pushing the envelope on the client as well as the server. No matter what language you primarily develop in, improving your chops in these common-ground languages is one of the best things you can do for your career.

Specialization is for insects

It's difficult to find a "shell scripting expert" or, to some extent, a "JavaScript expert". Both JavaScript and shell tend to expose other technologies rather than form the primary focus of your program: your shell script exposes UNIX internals, your JavaScript binds HTML and CSS together. Because of that, you're much more likely to find generic "sysadmins" or "front-end experts".

That's your opportunity. You don't need to become the "expert" in a particular glue language, but the more you can improve your glue language skill set, the more valuable you are to a wide variety of developers.

Futuristic Glue

This is why I find projects like Node.js so interesting. JavaScript isn't subservient to HTML and CSS anymore; it becomes a first-class language. Node is just more accessible in JavaScript than if it were written in Ruby. This is even apparent in shell: rvm, a platform-agnostic Ruby installer, is substantially written in shell rather than Ruby. You don't need to be a Rubyist to improve the project.

It's hard to consolidate in our industry. Technologies are forked, turned into new projects, and forked again just as quickly. But we may start to see more consolidation in the future. With more JavaScript developers, attention will continue to be focused on improving the runtime efficiency of various JavaScript engines, which will in turn continue to drive JavaScript adoption.

Back to Basics

Shell scripting syntax is fairly basic. JavaScript has a paltry standard library. But those simplicities are strengths, not weaknesses.

If your JavaScript skills consist mostly of running alert() for input validation, try stretching your legs with Node.js. If you still don't know what a pipe is, dive into shell scripting a bit further. These languages have been around for ages, and will continue to be around for years to come.

Look into other common areas, too: they needn't even be languages. Make sure you understand JSON and XML. Look into how you can expose your web frameworks over REST. Consider real-time streaming protocols in your API. These are concepts that transcend arbitrary language choice.

The usage of cross-discipline, cross-culture glue languages is only going to grow. Embrace it. Get out of your language comfort zone and work at becoming a better programming citizen. The more our communities can work in glue languages, the better we can work together.

A Documentation Talk

2011-09-02T00:00:00-07:00

"A Documentation Talk" sounds pretty boring, right? Wouldn't it be scandalously titillating if this talk's title included detailed analysis of the expectations and results of the talk itself? Jeez it's like someone's making an overt metaphor for how Rubyists document their code.

At GitHub, we add docs to every single method we write, and we couldn't be more excited about it. It means faster and simpler code. It means stronger tests. It means your developers can pay attention to new commits without stressing about them. Documentation will make your project so very happy.

Slides

Video

References

How GitHub Works: Creativity is Important

2011-08-18T00:00:00-07:00

We want to foster a creative environment. We love it when employees hack on side projects. It gets people excited. Excitement is contagious, and spreads easily from one project to another. Even if we'll never make money on that side project, the excitement generated from it can bleed into things that will make us money.

Alcohol

It's no secret that there's more than a few people at GitHub who like to drink. I mean, we have four beers on-tap at the office in our kegerator. But alcohol is more important than just intoxication.

We meet people. Through our sponsored drinkups, we meet a ton of people in San Francisco and all over the world. This gets people excited about our product, and gets people excited about working for GitHub. (It's a lot safer to hire someone after you've had a few beers with them in a non-threatening environment rather than create a large, stressful interview process.)

We meet each other. We all work together, but we're not just coworkers; we're friends. We bleed friendship and work together, so it's hard to tell when we're discussing work and when we're chatting over beers. This is not just for a fuzzy feel-good feeling. When you're close to someone, you can be much more honest with them. If they have an idea, tell them about it straight, help them improve it, and move on. Going out socially is part of that. Alcohol's called a social lubricant for a reason.

We brainstorm. Bars are a great environment to ask "what if". Don't stay concrete- talk about industry direction, how it can apply to your product, what we might be building three years from now. So many of our existing features stem from vague sessions at San Francisco bars.

Encourage different

GitHub's primarily a Ruby shop: most of the developers use Ruby full-time and most of our projects use Ruby. But you shouldn't be limited by your existing workflow.

We're setting up an Arduino shop in the office for those of us who have never done meatspace programming projects. GitHub sponsors monthly gym memberships. We have intense philosophical debates on who can gain the most followers on Twitter. We encourage employees to give internal talks on everything from arcane programming languages to mountain climbing.

The point is to get people interested in a lot of different areas of life. Get people excited. Get people exposed to completely different ways of thinking. Improve the person, and it improves the company.

Creativity means self-direction

One of the initial questions Chris asked that led to this blog post was I'm sure anyone can't just write whatever they want. That's actually the case.

There are certain things that are more pressing — overhauling our events table before it crashed the site is a bit more important than a new footer, for example — but for the most part GitHub is self-directed. If you're interested in working on something, then work on it. The best work is done by those who are genuinely interested in finishing that project.

We're able to do this because we talk a lot about our product, so everyone's on the same page. Things like Pull Requests give us playgrounds to try out new ideas before shipping them publicly. We thrive on experimentation and shun grandstanding. If you're interested in something, just do it. We can iterate on top of your prototype from that point forward. It's a great way to build a product. Kyle has written extensively on this process at GitHub from a design standpoint.

We're hiring

Okay, I didn't mean for this to be one huge plug for GitHub; I just think this is a great way to build products. That said, we're always looking for new talent; follow @holman and @github on Twitter and we'll let you know when we have openings.

If not, I hope this interests you. A large company like IBM may need to enforce a lot of overhead, but in the startup world we can avoid all of that. You don't need to mandate hours. You don't need to mandate meetings. Your code review can be ad-hoc. You can build fun companies that get shit done. It's not mutually exclusive.

Don't let your company get in the way of building your product.

How GitHub Works: Be Asynchronous

2011-08-17T00:00:00-07:00

This is — by far — my favorite aspect of working at GitHub. Everything is asynchronous.

Chat

GitHub didn't have an office for the first two years. Chat rooms (in our case, Campfire) is where things got done. Today we've moved into our second office, and Campfire is still where we get things done. There's a reason for that: chat is asynchronous.

Asynchronous communication means I can take a step out for lunch and catch up on transcripts when I get back. Asynchronous communication means I can ask my coworker a question in-chat and not worry about bothering her since she'll get back to me when she's available. Asynchronous communication means I can go to rural Minnesota and feel like I'm working from the office like normal.

Pull Requests

The majority of our development workflow involves Pull Requests. I'm going to be going into a lot more detail about this in future blog posts and talks but in the meantime let me say this: living in a pull request world is sublime. Gone are days at companies with complicated branching strategies, with in-person code-on-a-screen code review.

If I want to add a new feature or impact the codebase, I'll push a new branch, create a Pull Request for it, and my coworkers will review it 1) if they're impacted by those changes, 2) interested in the subject, or 3) when they have ample time to check out my changes. At that point, we can run a partial deploy of that branch on different subsets of machines and try things out in production, and if everything looks good, merge into master.

With Pull Requests, I don't have to drag anyone into a meeting that's inconvenient for them and for me. There's a good reason for that, too:

Meetings are fucking toxic

37signals originated "meetings are toxic" in Getting Real. I tend to loathe meetings even more than 37signals. I despise them.

Meetings are usually called when you need to hash something out. They tend to invite more people than necessary, and even if you're pretty interested in the meeting topic, you're still going to be frustrated because meetings pull you from doing actual work in order to talk about doing work. It's easier to push a branch up, check out the diff, and then iterate on that diff rather than assuming you're going to perfectly whiteboard system design ahead of time.

Beyond that, meetings are utterly forgettable. Even if you take meeting notes, you can't capture them all. You make a judgement at that point in time as to what to write down for later. Then three weeks later you try to remember what wasn't written down when it becomes apparent that that discussion was more important. You don't have this problem with chat transcripts. Forcing people to reduce their otherwise rambling thoughts into concrete sentences helps focus discussion, too.

We'll have meetings at GitHub, but I can count the number of full "meetings" we've had in the last year and a half on one hand.

The Zone

This all goes back to what I was writing about yesterday: you want your employees to be in "the zone". Putting people in an atmosphere where they can only work for an hour before a team meeting pulls them out of that flow.

We've found that if you let responsible people handle their own priorities on their own timeline, they'll end up getting the important stuff finished and still be able to work productively on other work.

How GitHub Works: Hours are Bullshit

2011-08-16T00:00:00-07:00

Frederick Winslow Taylor wrote the seminal analysis of management and efficiency in 1911 with The Principles of Scientific Management. He took the first scientific approach towards maximizing efficiency in manufacturing jobs. Time is money. Faster is better. More hours are better.

Hours are bullshit

Hours are great ways to determine productivity in many industries, but not ours. Working in a startup is a much different experience than working in a factory. You can't throw more time at a problem and expect it to get solved. Code is a creative endeavor. You need to be in the right mindset to create high-quality code.

Think back to the last time you were depressed or angry. How productive were you? Now think back to the last time you were truly productive. Code flying from your fingertips. Not just the sheer quantity- the sheer quality of that code. When you're in the right mindset, your best day of coding can trump weeks of frustrated keyboard-tapping.

We want employees to be in the zone as often as possible. Mandating specific times they need to be in the office hurts the chances of that. Forcing me in the office at 9am will never, ever get me in the zone, but half of GitHub may very well work best in the morning.

By allowing for a more flexible work schedule, you create an atmosphere where employees can be excited about their work. Ultimately it should lead to more hours of work, with those hours being even more productive. Working weekends blur into working nights into working weekdays, since none of the work feels like work.

A day

Everyone at GitHub is different. I don't really have an "average" day, but this is a close approximation:

Wake up around 10am, check Campfire logs, clear overnight support tickets
Bus into work and grab lunch around noon or 1
Work from 1pm to somewhere around 6-9pm at the office
Go home and work/relax from my couch until 2am, or:
Go out and drink with coworkers (more on this later)

We have a contingent of (insane) people who come into work around 7am, we have some who come in at 3pm. We have some who are more productive at home. You don't have to come into the office every day if you don't feel like it (although most of the time everyone comes in).

Why is our day so "loose"? Because 1) working in chat rooms lets us work when and where we want, and 2) we want to create an environment where people are most productive. There's no one work day that fits everyone's productive hours, so we don't enforce one.

Enforcement

We're currently at 35 employees and growing, and this approach still works great. But managers love to assign hours for a reason: it gives them the illusion that hours can measure performance.

If you don't go hard on hours, you do have to look at different metrics. How good is their code? Are they fixing bugs? Are they involved in work, or is the greater flexibility not motivating them?

It's difficult to make these qualitative judgements, but they're still going to be more valuable than "did this guy put in his ten hours of work today". Because as soon as you make it about hours, their job becomes less about code and more about hours.

How GitHub Works

2011-08-15T00:00:00-07:00

In 2011, I wrote a three-part series called How GitHub Works. I wanted to detail how we planned ideas, built them, and shipped them.

Posts

The three posts are:

Talk

I've always wanted to expand this into a proper talk, though. While I've done a few GitHub-related talks since then, I didn't get to do a true "How GitHub Works" talk until 2012.

Video

Slides

This is an updated deck; you may be interested in the first version of my How GitHub Works talk.

Steve Jobs Sometimes Lies to You

2011-07-27T00:00:00-07:00

I love Apple. I love Apple so much that if someone gave me a bulletproof vest made out of MacBook Airs, I'd strap it to my back and take a bullet to my chest to protect my precious aluminum friends.

But Steve's lying to us when it comes to FaceTime.

"And we're going to take it all the way. We're going to the standards bodies, starting tomorrow, and we're going to make FaceTime an open industry standard." Steve Jobs, 2010 WWDC Keynote

Steve went on stage and announced this to the world. Rumor is he also simultaneously announced it to the majority of the FaceTime team, who until that moment hadn't yet been informed that their work was going to be standardized.

There's certainly a possibility that FaceTime may still be ratified as an open standard. Maybe Steve just misspoke when he gave concrete dates and steps to open up the FaceTime protocol. Maybe it happens the day after I publish this blog post. But regardless of the reason, we are stuck here more than a year later, with FaceTime siloed strictly to Apple devices and (to my knowledge) zero standards bodies reviewing a proposed FaceTime protocol spec.

OpenFaceTime™

If FaceTime were open, we'd certainly see people working on integrating it. Within a day of Jobs' announcement, Skype had said that they were interested in the technology available through FaceTime. I'd wager good money that some of the Android-based phones would add FaceTime as an option. And the indie market would have a blast... depending on how "open" FaceTime would be, I'm sure we'd be building FaceTime into Hubot, our chat room robot at GitHub.

Increasing the number of FaceTime-equipped devices means that FaceTime moves from a novelty that you use when you stumble into a bar and find out it has free Wi-Fi, to a serious communication medium that can start to supplant telephone calls themselves.

"Open" isn't just a buzz word

"Open" isn't just a buzz word. People like the word "open". Marketers love it. It sounds inviting. It sounds safe. But it's fundamentally an important concept in computer science. Open source, open guidelines, transparent motivations. These concepts actually mean something to us.

If a company goes on record and says they're going to open up, we need to hold their feet to the fire. We need to make it clear that you can't garner goodwill by embracing openness while at the same time not delivering on that promise.

The stakes are just too high not to pursue this admirable goal. To be truly happy, I need to be able to FaceTime in ASCII from my scientific calculator. Or mount a FaceTime camera to my dog. Or run it through a Visual Basic GUI and give my recipient a really huge nose. The point is: open is open, and FaceTime is not. Apple needs to fix that or fess up.

Blog Marketing for Ego-Centric Assholes

2011-07-21T00:00:00-07:00

My official job title at GitHub is "Ego Surfer", a tongue-in-cheek reaction to my stars project, a command line interface I wrote to tell me who have starred my tweets. GitHub job titles are given to employees in a comical fashion, but in my case I like to think it's fairly accurate: I really like to discover and manage people's reactions to my blog posts, tweets, and product launches.

I use "assholes" in the title somewhat loosely; I hate spam like the rest of you and being an asshole who pushes their work with wanton disregard for how disrespectful they're being is never a good idea. That said, if you're writing good content that could stimulate an appreciative audience, I see nothing wrong with putting your best foot forward.

This isn't some old-school post about getting indexed in Technorati. Getting buzz about the posts you write today is a bit different. How you initially react to someone's own reaction to your work can turn your small buzz into a lot of fucking eyeballs.

Writing your launch tweet

Twitter is the most important technology to leverage. As I wrote in Fame, tweets and their subsequent retweets can really snowball a mediocre post into one that's discussed all over the internet.

Not all tweets are created equally. Here's how to win:

When you write a post, simultaneously tweet a link to it.
Make the tweet body interesting. Either overtly make it vague, or catchy. I tend to swear a lot, which can jump out at you. (Or backfire, of course.)
It's helpful to get others to tweet you at around the same time. I'll usually pop into Campfire and pre-announce a post. If my coworkers decide to tweet it at the same time, you end up generating a lot of talk on the same link. If you have overlapping circles of followers, you can build a feeling of urgency and freshness that is appealing to click on — and retweet.
Reply to criticism and to compliments over Twitter. It's sometimes surprising how many outsiders read public @replies. Not only does replying to someone directly generate goodwill (regardless of whether or not they ultimately agree with your position), but you can sometimes generate interest in third parties that would have otherwise missed your post entirely.

Monitoring tweets

On a good post, you'll see a lot of activity in the first hours and day. The best ways to monitor that are using Favstar and Summizer.

Favstar was created by Tim Haines as a way to track who retweets and stars your tweets on Twitter. I use it as a quick benchmark of how quickly a post is taking off. It's helpful to track who exactly is checking your post out; sometimes you'll catch some larger players, sometimes you'll be able to click through and read some discussion on your article. Sometimes it's just fun to have an ego boost.

Summizer is an iPhone app by Fantzer that is effectively an interface for saved Twitter searches. While there are plenty of Twitter search apps out there, Summizer does a great job of keep track of read state (which, surprisingly enough to me, I end up using frequently), and the interface itself is very quick. I initially assumed that I wouldn't use Summizer more than once or twice, but find myself using it often: second only to my main Twitter client on my phone.

Twitter saved search bonus round

Another hint for Summizer and Twitter saved searches in general: you can do some fairly powerful stuff in your search. I track the term "zachholman.com", which returns tweets that link to this site (which even works through link shorteners).

You can also use it as a form of filter. If we just searched Twitter for "github", we'd pull in a lot of extra noise: post receive Twitter hooks, blog posts on pages.github.com domains, etc. We want to see the discussion, not the noise. A lot of us at GitHub have a search saved similar to github -merge -commit, which will strip tweets with "merge" and "commit" in the URL (which are usually just notification tweets).

Footer hacks

Right now I have a few things in my footer after my posts. One of which is the tweet button, a brain-dead easy way to let visitors tweet your URL.

Secondly, I have Boastful, a tiny jQuery plugin I wrote that displays the smiling faces of everyone who tweets a link to your post. Humans are ego-centric. They like seeing their faces in public places. I don't do comments on my blog posts, but I do like offering this small bit of community.

Thirdly, on more substantial posts I'll add a link to the Hacker News story submission (either submitted by me or whoever else gets to it first). This serves as a way to facilitate the discussion that I don't allow on the post itself, and it provides a easier connection for Hacker News visitors to my site to upvote the actual Hacker News submission. I really like this setup: Hacker News tends to give you some honest, respectful feedback, and exposes you to movers and shakers in the industry.

You don't need to go crazy with these sort of "footer pieces of flair", but having a few smart integration points goes a long way.

Analytics

I hate Google Analytics. I really care about 1) trends, 2) referrals. Anything more than that is interesting, but a distraction from those first two expectations. Google Analytics is a pain to use.

Gauges is not.

Gauges is a newcomer this year to the stats game, but it's beautifully-designed and gets me the information I need quickly (and in real-time, with maps!). The reason I love Apple is the reason I love Gauges. If you're feeling that Google Analytics is too heavy for you, check out Gauges. Seriously.

Always Be Closing

Look. I loathe that there are jobs in "Marketing". I hate that very word. But you can be smart about a few things and get the word spread about your project or post faster.

More importantly: everything I've said in this post is completely bullshit if your content is bullshit. I play the social card heavily on the assumption that people will want to share my content. If I write a crappy post, people won't share it and I leave it at that. Get that house in order first, and then from there you just take steps to make sure more people have the opportunity to talk about your work.

Improving Yourself is Easy

2011-07-20T00:00:00-07:00

For the last four years I've set informal goals to become a better Ruby developer. They looked something like this:

2008: Contribute to an open source project
2009: Make it to a Ruby conference
2010: Maintain some sort of popular open source project
2011: Speak at a conference

All of these seemed daunting at first. And then I did them. Now I wonder why I didn't do all of them earlier. I want you to experience that same progression, regardless of what goal you might have. It's easy to improve yourself.

2008

2008 was before GitHub really started picking up momentum, and as someone feeling somewhat new to Ruby and to open source in general, figuring out which project to contribute to and how to do it was fairly challenging. Eventually I made a few different contributions (one of which was for restful_authentication to my future coworker, Rick Olson, who unceremoniously shot down my patch and made me whimper in a corner for a few weeks). But I got my other contributions in.

2009

Being young, dealing with scheduling, and the lack of a company sponsoring my travels meant heading to a technical conference felt a little out of reach. But I made it to RailsConf 2009.

2010

In 2010 I found myself with a couple different open source projects taking off: both in developer activity (forks of my dotfiles) and in end-user activity (usage of boom). I learned more about what versioning a project meant. And releases. And encouraging contributions. It was initially intimidating, but now it feels so second-nature.

2011

In 2011, I sent a talk submission to RailsConf. I felt silly: I hadn't given a talk before, and choosing the largest Ruby conference seemed an intimidating first step. It was accepted, and I gave my talk in May. Now I have four other talks scheduled for the rest of 2011 so far, including some international conferences.

Being better

I felt a little embarrassed putting my timeline at the top of this post. Everything on that list seems so trivial now that I've done it. Of course it's easy to contribute to a project. To attend a conference. To prepare a talk.

But they all felt daunting before I did them.

A big part of my job involves talking to a lot of software developers, from Ruby to Cocoa to young to old to stern to playful. And I usually find myself encouraging people to give a talk. To write blog posts. To publish more open source.

I'll look at them and see the same feeling I felt. It's not a feeling of incompetence. It's a feeling of a lack of belonging. That they're not ready to be indoctrinated into the special Club of People Who Are Ready.

Being Ready is only accomplished after you've done something. Before you've done something, it's daunting. After you've done something, it's easy.

So do something.

Double-Shipping Software for Profit

2011-07-19T00:00:00-07:00

Selling a product once is fun, but selling that product twice is wildly excellent. GitHub does that with Firewall Install, our installable enterprise GitHub. This talk aims to discuss how you can repackage your existing product too, by covering code strategies for parallel codebases, supporting remote server infrastructures, and talking about the impressively stupid decisions we've made.

Slides

References

Parallaxing Parallax on iOS

2011-07-01T00:00:00-07:00

GitHub has a bit of a friendly competition complex. When Corey Johnson released URL Hunter, there was a lot of talk about how that minigame could be topped. Cameron McEfee, the famed designer behind all of the parallax effects on GitHub's site (the 404 page, the 500 page, the about page, and so on) took Corey's URL bar game and parallaxed it. In doing all of this parallax work, Cameron open sourced his parallax plugin for jQuery itself: plax.

Parallax is a perspective-based animation technique: move your mouse and you simulate moving your frame of reference around. Cameron's plax only worked based on mouse movement, though:

...which means all of these gorgeous animations of this handsome fellow didn't work on your favorite iOS device. What a bummer. So I parallaxed his parallax and added support for the accelerometer and gyroscope present in iPhones and iPads, which Apple generously gave us access to in the iOS 4.3 release last year.

So now we can do cool things to GitHub's Cloud:

Safari's Accelerometer Support

It's really pretty easy to add this to your own apps and libraries. Apple exposes the accelerometer to us through DeviceMotionEvent, a class that handles "signification change in motion". (You might also want to take a look at DeviceOrientationEvent, too.) The change to plax is pretty straightforward, but it's really just a matter of handling the ondevicemotion event and grabbing the values from that motion:

window.ondevicemotion = function(e) {
  x = e.rotationRate.beta
  y = e.rotationRate.alpha
}

In this case, rotationRate is the rate of rotation, which is a bit more relevant for parallax. You can also grab rotationRate.gamma, which is the rotation positive out of the screen on the z axis. Unfortunately rotationRate is for those devices with gyroscopes: in other words, iPhone 4 and above. Once we have the rotation rate pulled from the phone we can pipe that information into plax and plax handles the coordination of layers based on that.

Depending on your use case, you also might want to take a look at accelerationIncludingGravity, which gives you a measurement of the acceleration of the movement happening on the device.

Todo

This at least gives us some real-world parallax support on iOS, which is great. There's some improvements that could be made to retaining rotation position in parallax (which would give it more of a realistic feel), and there's oodles of accelerometers in Android phones and in laptops, too. If you're looking for a fun hack day, you might want to build in support for those devices (or create a library abstraction for movement in JavaScript!) and send us a pull request.

VAGRANCEPTION

2011-06-08T00:00:00-07:00

After the staggering mediocrity of my last screencast, I immediately made elaborate plans to create my next screencast. And here it is, five months of 110-hour weeks later. Well, maybe I mostly spent those five months putting it off. But you can imagine what it'd look like if I spent 110-hour weeks on it! It would have been magical!

Instead, I bring you this one.

V A G R A N C E P T I O N

This stems from my love for Vagrant, a command-line interface to VirtualBox, which is Oracle's open source virtualization software. If you ever need to build up and tear down virtual machines, do check it out.

The Process

So it gets a little complicated at the end. Watch the screencast first — I don't want to SPOILER ALERT you all over the place! — but then you can check out the project README to see how all the individual parts are put together.

This also gave me a chance to shoot on my new Nikon D5100, for you camera nerds out there. You guys are so nerdy.

Resources

The Most Important Code Isn't Code

2011-06-07T00:00:00-07:00

Documentation is the single most important change I've made to my coding style in the last year.

Documentation is Personal

I'm not talking about injecting a few comments in front of confusing lines here and there. I'm talking about taking a firm, consistent view at how you document your methods, your classes, and your projects, and then sticking to that mentality. Documentation is mostly described as a way to communicate your thoughts to other developers, but honestly, other developers can eat it. Documentation is the best way to communicate your thoughts to yourself.

Documentation is Clarity

If you don't have an absolute clarity in the code you're pushing, it rears its head by way of bugs, confused coworkers, and slow code. Straightforward documentation has given me that clarity.

I typically hate process. From TDD to BDD to Agile to everything else, it usually feels too cumbersome for me to stick with it. But two mentalities have really impacted me: TomDoc and Readme Driven Development. Both were designed by Tom Preston-Werner. Both have documentation at their core. Though they're both obviously helpful for other developers who look at your code, I've found them to be extremely helpful to me as I code.

Writing the README first means you think about the end-product first. That seems somewhat silly — I mean, I'm writing this library, don't I already know what's coming next? But that's usually not the case. More often than not I would jump straight into the challenging part of the project since I thought that's where the substantive part is. It's not. The end result is always the substantive part of your project. Forcing myself first to consider the API, the interface, and the end result led to a clarity that inspired less code and a more impactful project.

I feel similarly about TomDoc. TomDoc is a mentality that places emphasis on clear, straightforward, explicit documentation. Here's a simple example taken from the TomDoc spec:

# Duplicate some text an abitrary number of times.
#
# text  - The String to be duplicated.
# count - The Integer number of times to duplicate the text.
#
# Examples
#
#   multiplex('Tom', 4)
#   # => 'TomTomTomTom'
#
# Returns the duplicated String.
def multiplex(text, count)
  text * count
end

You describe your method arguments, and you detail your response. Every time. It can sometimes feel repetitive, but that repetitive feeling is one of those I strongly welcome. It improves the clarity of my code. I get more done in less lines. The documentation style itself is clear, too. I write this blog in John Gruber's Markdown because Markdown looks and feels like plaintext. I use Tom Preston-Werner's TomDoc because TomDoc looks and feels like plaintext. There's very little interface to learn between writing it down and rendering it in your head.

Documentation is Testable

Documenting code in TomDoc has lead me to two big testing personal "breakthroughs", if you will. Since you're required to detail every method argument, you're forced from the beginning to consider how those inputs end up impacting that method. You think about the edge cases explicitly. Conveniently enough, those edge cases almost always translate into real test cases. I don't consistently TomDoc first or write my test first, but they almost always happen simultaneously, since they effectively work in tandem. One helps you write the other.

My second "breakthrough" is realizing that if some method is hard to document, it's too big. Ruby in particular has been harping for years that you want short, focused methods. I know that. Everyone's known that since their third week using Ruby. But even if you've been writing Ruby for years, you can pretty quickly fall into the classic "oh I'll just handle this here too" mentality. Once I do that, I end up trying to document more method arguments, more possible method outputs, and it's just more work. Once that happens, it's an obvious reminder that I messed up this method and should break it into two or three other methods. That means smaller, more resilient and easier-to-test methods, which directly translate into less brittle code.

Documentation is Diffable

Over the last year or so, we've been adding more and more TomDoc to code that we push here at GitHub. It's not high priority or anything, but if you refactor or touch old code, it's nice to add documentation for it.

We're now at 30-plus employees, and there's a lot of code flying around. When someone pushes to a GitHub repository, Hubot, our trusty Campfire bot, jumps in and posts a Compare View of the changes:

This hook is important. It's how everyone at GitHub can see how GitHub is changing incrementally. The commit messages in Git are helpful to see what's happening, but sometimes the commit message and (particularly!) the code doesn't really give you a good idea of what or why something is changing.

Seeing the changes in a huge block of documentation in the Compare View on GitHub ends up being much easier to parse. You can see which arguments got removed, which new edge case is defended against, what changes are made in the public API. It's another tool in your belt to help communicate code changes to everyone else.

Documentation is Marketing

I love the idea of documentation as marketing. A good README gets people to jump into your project much, much quicker. Heavily-documented code means others can read your project much, much quicker. Heavily-documented code means others will tend to break your tests less.

This extends to project websites and documentation as well. In fact, I love this documentation-as-marketing concept so much that I wrote about it. Even though I get a lot out of my documentation, that doesn't mean that it can't serve as a promotional vehicle for my project, either.

Documentation helps you in the bedroom

Well, I'm still trying to test the validity of that. But documenting your code is cool as hell. More importantly, it makes me feel more confident about my own code. You don't need to go full-bore Readme Driven Development, you don't need to use TomDoc, you don't need to follow any particular process. But improving your documentation skills will make you a better developer.

Fame

2011-05-13T00:00:00-07:00

A patrician in ancient Rome might be able to make a name for himself around his neighborhood over the course of his lifetime.

By the time the printing press gained widespread usage, an educated citizen might be able to write to her newspaper and reach thousands over a few days.

Today, a tenth grader who perhaps may not be our finest societal achievement judging from a cursory glance at her neck tattoo that proudly proclaims "To hot 4 you", drunkenly sits on her keyboard and mistakenly sends out a tweet that six hundred thousand people read within the hour.

Does this blow your mind? Does it? Because it should fucking blow your mind.

Power

A thousand years ago, kings and emperors would kill to have this power. At no other time in human history have even the richest, most famous humans been able to wield the power your average teenager has access to on their iPhone today.

We've never been so closely networked before. Your tweet on Twitter isn't just for your direct followers anymore... each of your followers is a click away from broadcasting it to their followers. It's a simple concept, but let that sink in. Every time someone retweets my blog post or my tweet or something I've done, I'm being exposed to their followers, who in turn can perpetuate the cycle.

Classic network effect. But that doesn't make it any less amazing.

Fast Starts

It's remarkable how quickly this can happen. When I wrote Facelette, I had a good idea that it was going to go viral as soon as I released it. I didn't even get that far, actually; my coworkers tweeted it as soon as I pasted in the URL to our company chat, and within a couple minutes it was clear I couldn't put it back in the bag. There were more than 2,500 tweets in the first 24 hours, and that all stemmed from those initial few tweets.

I saw the same phenomena happen for my coworker Corey Johnson when he released URL Hunter, a simple game in your browser's URL bar. Because of how easy word-of-mouth is today, he was getting thousands of tweets about this little hack, which led to interviews in tech magazines and lol-worthy acquisition inquiries. All from a simple idea and a human compulsion to share cool shit.

Think about this stuff the next time you launch your product. Or tweet. Or post a photo. It's good for you to stop being so goddamn jaded and realize that we've built a fucking awesome society.

Open Source Doesn't Just Market Itself

2011-04-18T00:00:00-07:00

Hip trendy startup software folk hate "Marketing Guys". Usually for good reason, since they tend to swoop in and steal the best donuts at the conference breakfasts by distracting you with buzzwords like "SEO" or "global goal-oriented output funnels" or "Rebecca Black".

This mentality drifts over to open source software, too. We like to think that open source is pure, that it's unadulterated. That marketing an open source project is silly.

That's just silly.

GitHub

Prior to GitHub, word about open source projects travelled primarily through word-of-mouth and messenger bicyclists. The largest open source project had three users and two developers. I think it involved a lot of twine and glitter.

Anyway, I digress. When GitHub launched, you could log into your dashboard and see the News Feed front and center, giving you a glimpse into what developers you're following are working on, what they're watching, and so on.

This was insidiously subtle, but ended up being one of the strongest advantages of moving your projects to GitHub. Your followers watch your projects, which in turn gives you more exposure to their followers and so on.

I think the problem is that a lot of developers stop there. They see a modicum of support from their GitHub followers and call it a day.

You should do more!

Why?

Marketing your projects is important. Open source is fantastic, and noble, and awesome, yes. But if you believe your project has value — which you probably do, since you spent time on it — you should try to get it in the hands of as many people as possible.

Get your project's name out there. I can't tell you the number of times I stumble on this tiny, underfollowed project and it completely blows me away. This isn't an ego thing; I want you to whore yourself out. Did you spend two days hacking out a way to convert my data between two services I use? I would absolutely love to discover that. If it's worthwhile to you, it's probably worthwhile to someone else. They won't use it unless they learn about it.

The easiest thing to do is to tweet about your project. Retweets can be extremely beneficial to a new project, and people honestly love to tweet 1) links, and 2) cool things. It makes them look hip. That's great; help them look hip by tweeting your new projects and code snippets.

Documentation as marketing

My favorite marketing of all time is documentation. We all loathe sleazy marketing, and by definition I like to think documentation can't be sleazy because it solves a real purpose: teaching everyone about the project.

The best part, though, is that documentation is linkable. It's indexable. It's tweetable. Particularly if you have a nice, coherent one-page overview of your project that lets people jump in and immediately "get" it. Check out Bundler's docs. Or the Rails Guides. Or the interactive Try Redis app. They're very inviting, very welcoming glimpses into the project. As much as I absolutely adore a nice README on GitHub, they still can't be as impactful as a thoughtfully-designed page.

Your success is our success

This matters to me because the more everyone markets their projects, the better off we all are. It's not a zero-sum game. Better documentation, better relevance in search engine results, more project activity, more contributions, happier users. I like it.

Why GitHub Hacks on Side Projects

2011-04-04T00:00:00-07:00

GitHub employees have gotten very good at writing irrelevant code.

In my Automating Inefficiencies screencast, I showed some goofy ways we use animated gifs, inside jokes, and hacks to make our Campfire chat room more fun. Some days we'll spend a decent chunk of work time on these projects. They don't directly contribute to our bottom line, most of these projects won't be released publicly, and the code quality itself is questionable.

I couldn't be happier about that.

To take one example: Hubot, our valiant Campfire bot, has continued to grow in complexity. A tiny list of his (current) capabilities:

unlock the door to our office
print out a list of the people currently in the office based on their wifi presence
find an apartment in the area to rent
deploy GitHub
say an arbitrary string over the office speakers
play an audio sample of deadmau5 to everyone through hacked Propane HTML5 <audio> tags
give you a quote from any movie or TV show
tell you the build status of any git branch
track and map packages
SMS any GitHubber from Campfire
embed a seven day weather forecast

We're building more and more into Hubot every day. (Before you ask, no, he's not open source yet, and yes, a few people are working on that.) Update, October 25, 2011: Hubot is open source.

Embrace your newbies

The importance, in my mind, is not that Hubot can do all of these really cool things. That's fun. But what's really important is Hubot is a shared side project within GitHub. He's a node.js bot, so most developers with a working knowledge of JavaScript can easily contribute to him. I get a kick out of seeing our latest hire add something funny or interesting to Hubot in their first week of employment; doing so offers a real sense of ownership and belonging when everything else is new around you.

Joining any sizeable organization is daunting. Having an open, shared space to explore together is important.

Make your mouth do that smile thing

It's also a pleasant distraction. I love what I work on and most days are a blast, but even fun jobs can be a grind from time to time. It's nice to take a break mentally and get jacked up on something exciting. More than once I've found myself hitting a wall, switching gears to Hubot or a few other GitHub projects, working heads-down for an hour or three, and then discovering I'm ready to slaughter the original problem I had.

Programmer productivity is not impacted by number of hours; it's impacted by the quality of those hours.

Culture

You should build out a side project culture. A Campfire bot is natural for us, since we spend so much time in Campfire, but there's plenty of other areas. Hack on your continuous integration server. An app that picks where you're having lunch that day. A miniapp that collects and stores employee-created animated gifs. A continuous integration animated lunch machine. It doesn't matter what it is; if it improves the lives of your coworkers or makes them laugh, it helps build a stronger company culture. And that's cool.

Your Talk Looks Like Crap

2011-03-21T00:00:00-07:00

Chances are, your slides look like crap.

It shouldn't be that way. The presentation you give is undermined by your decision to use that cutesy 10-point serif. Luckily, you don't need a lot of design chops to improve the way you present yourself.

Slides

From the conferences I've gone to, certainly a number of people "get" it. Great slides, very readable, pleasant to stare at for 50 minutes. But those presenters are in the distinct minority.

We want to live in an idealized world where the content of your talk is what people pay attention to. But that's far from reality. People base their opinion of your talk, in part, on your slides. Maybe it's unpleasant to think about, but pleasantries don't dictate realities.

It's hard for me to remember a terrible presentation with a great set of slides. It's hard for me to remember a great presentation with a terrible set of slides. Good speakers pay attention to everything: how their slides look, how they speak, how their content comes across.

It may sound like you need a fabulous slide deck to make an impact. You don't. I've been in plenty of presentations where I suspected the speaker was uncomfortable with their design talents, so they instead opted for simple, huge text on white or black backgrounds for every slide. That's great. Those very basic concepts — huge, readable, minimal text — will immediately push you ahead of 90% of everyone else. No joke.

On-screen code is incredibly important, too. There's something about putting code samples on-screen that leads decent presenters to just say Oh fuck it! That's fine! Code samples are a fragile move in the first place, since they require a more intensive cognitive process on the audience's part to understand what's going on. On top of that, syntax highlighting makes it hard to read. A speaker at the last conference I went to had 20 lines of code on one slide, with black-on-grey text (except for the line he was talking about, which was white-on-grey). It's insane.

Put yourself in your audience's shoes. Think about how the design of your slides augments your talk, rather than detracts from it.

Developer Design

Developers aren't "supposed" to design, I know. And it's a very personal thing: some people are more artistically inclined than others, and I'm not expecting every developer to be able to pass some university art school program. What I am saying is that design is important, and you should care about how you present yourself. Designers can get by with fancy, intricate designs, but you'd be surprised at how easy and powerful a simple, no-frills approach can be.

OS X Isn't for Developers

2011-03-10T00:00:00-08:00

Apple had about 2.06 percent of the US desktop market in 2003. By 2010, OS X had about 10.9% of the market.¹ There's a slew of reasons for this growth, but I think a large part of it is the migration of software developers from Windows to OS X starting in the early 2000's. Attracted by the reasonable UNIX toolchain and the straightforward usability approach, more and more geeks adopted OS X as their primary machines, saw it also doubled as a decent computer for non-techies, and its popularity grew from their recommendations.

This wasn't just about Objective-C developers. Java, Ruby, Python, Perl, and PHP communities all found a home for themselves in OS X. That Apple provided first-class, installed-by-default support for all of those languages dramatically lowered the barriers for the technically-inclined to dabble.

gcc

A blight on this installed-by-default support is the lack of compilers on OS X. The recommended course of action is to pull out your OS X installation CD, install Xcode, and you'll get the specialized gcc builds from Apple customized for Darwin. This, again, is not about Objective-C developers, since they will need to install Xcode regardless. This is about the rest of the language ecosystem that grew on OS X. For example, Ruby's predominant package manager, RubyGems, can allow developers to drop down to languages like C for additional speed or functionality.

For years this blight was a pain, but bearable. If you wanted to install a gem that needed to build C extensions, you just needed to remember to find your install DVD, install Xcode, and go for it. With the growth of the internet, pretty quickly the process switched to downloading the installer from apple.com instead. That was somewhat bearable when Xcode 2.1 was less than 800MB.

Xcode 4

This week, Apple released Xcode 4. It clocks in at a 4.5GB download, and is $4.99 in the AppStore. This is the first time Apple's charged for Xcode. It's possible that this will change before OS X Lion ships, but it's still a troubling prospect today.

If I want to release a great new Ruby gem that uses a C extension or library, I need to ask prospective users of that gem to:

Spend $4.99 in the App Store
Download a large 4.5GB file
Spend a decent amount of time installing XCode
Sacrifice 15GB of disk space to an app they likely won't use
Install my gem

It's not about the money

Though I don't think Apple should charge for Xcode, $5.00 isn't a lot of money to Cocoa developers... I suspect most would pay a lot more. It is a lot of money to someone who just wants to try a gem, to someone who has to justify a business expense, to someone who isn't old enough for a credit card. It's the act of throwing up such a huge barrier to a casual, interested user that is offensive.

It's not about the language

I bring up Ruby because I'm a Rubyist, but it doesn't just affect Ruby developers. It affects all developers. One only needs look at Homebrew's Formula directory to see all of the software this impacts.

The thing that kills me about this is language transfer. I like building general-purpose libraries. boom and stars, for example, can be used without any knowledge of Ruby. If someone goes outside of their comfort zone into a language they're unfamiliar with, it's important to make that process as smooth as possible. On OS X, it's getting worse and worse.

It's not about the platform

Okay, it is. It's Apple's fault for not including gcc by default in OS X. But what I mean by this is that this issue impacts all other platforms. As an industry, we want more people building libraries of all sorts in all languages. It doesn't matter if you're sitting comfortably in your self-compiled BSD world using your favorite free build chains... we want every facet of our industry to be pushing the envelope. Projects in the language you don't use may inspire you down the road to build something you would use.

By making it more difficult to ship compilable code, we miss out on faster interpreted-language libraries. We miss out on easy abstractions to rock-solid, battle-tested C libraries. We make it harder for people to dabble.

Fixes

There's three scenarios here:

Apple releases their gcc package, installs it in Lion by default, or otherwise makes it available. This would be excellent. The holy grail would be if Homebrew could use this and we could just run brew install gcc. It would be a huge, huge impact to our community.
Someone else releases gcc for a Mac. Again, this would lead to a brew install gcc. This would be great, and possibly more likely than waiting on Apple to do the right thing. I'm just an interpreted language asshole though, so I really don't have much of a clue as to how in-depth a challenge it would be to compile gcc for Apple's system frameworks. My guess is it's daunting, otherwise we'd have it three years ago.
Nothing happens and things get shittier. This is probably the most likely. It's also the most depressing.

It's a frustrating position to be in. We are, of course, subject to Apple's whims on this. Free software advocates will point out that they've been saying the same thing for years, and that's true- we all give up some flexibility by being on OS X. It's a tradeoff. What is dismaying is that, all things considered, OS X has been a wonderful boon to software development in general in the last decade. They've done a lot of things right. You still won't see PHP installed on Windows any time soon.

I just hope Apple has an interest in making this decade as fruitful for software developers as the last decade. Seeing OS X dwindle as a developer platform would be such a waste.

I Liked It When Quick Bars Got Me Drunk

2011-03-04T00:00:00-08:00

Twitter pushed an update for Twitter for iPhone yesterday that mostly centered around the new "Quick Bar". The Quick Bar is a new technological innovation that brings the power of a business plan to Twitter, Inc.

With this new update, I can finally forfeit that additional one-tenth of my screen real estate I've been meaning to shed. A beautiful five-tweet vertically-stacked display can miraculously, at just the click of an AppStore update button, turn into four tweets. Or three! I can also gain an ever-present UI element constantly informing me about mysterious subjects like "Friday" or "blackpeoplemovies" or "Donald Trump". Sometimes, if I'm really lucky, it will inform me about a really neat product from a company that is so neat that the company needs to pay Twitter money to help promote it.

How does Twitter gain such technological insights into this market? Is it the one developer they hire to work on the Mac, iPhone, and iPad apps? Is it because that one developer only tweets every twenty days? Is it because, even though that one developer is strapped for time, he usually makes good UI decisions and this is very clearly a top-down example where Twitter executives wanted to insert their Monetary Acquisition Strategy into their popular product regardless of how horrendously misguided the implementation was? I'll let you decide! They're all just so exciting!

Winning San Francisco's Startup Scene

2011-02-28T00:00:00-08:00

I moved to the Bay Area right after I finished school a few years ago. Luckily, as a recent college graduate, I knew everything there was to know about life. Easy as pie! Give me my VC check, dammit, I'm ready!

I've since come to understand that maybe there was a lot I've learned about San Francisco since then.

You

This post is me trying to lay some knowledge on naïve Zach Holman circa 2008. It's a collection of things I've fretted about and heard others stress about. If you're about to move to San Francisco, if you're in school and thinking about moving out here, or if you're already here and want to make the most of it, this may be relevant to your interests.

Usual disclaimer applies: this is my outlook on startup life in San Francisco, and you may disagree. That's cool, I don't mind. Let me buy you a beer.

San Francisco vs. the Bay Area

There's a lot of debate on where to live: in The City (which always means San Francisco), or somewhere more suburban like Palo Alto or Mountain View. I've lived in Palo Alto before moving to San Francisco, and it really depends on what you're looking for. If you want to be out barhopping more often, you'll want to head to the City. If a less stressful, more laid-back atmosphere is more important, try to pick somewhere on the Peninsula.

If you do choose San Francisco, the next thing you'll ask is where to live. San Francisco is the most neighborhood-y city I've ever heard of: within a three block walk you could hit four neighborhoods, all with a completely different feel and population. Some of them have more drugs than residents. Your best bet is to just spend a few weeks here with a friend or in a hotel, scope out which neighborhood initially interests you, and pull the trigger. You'll probably end up moving in a year anyway once you figure out what you really want.

Get drunk a lot

If you don't drink much yet, you should. Part of what makes San Francisco great is the technical meetups in the area: lots of conferences, lots of presentations, lots of small tutorials. Those are all well and fun, of course — it's great to be exposed to the new hotness — but I've found them to be pretty lame to meet new people. Every time you meet someone you get the feeling that you're walking through the professional steps: 1) name, 2) company, 3) technologies used 4) uh, okay, have a good one. These are the single-serving friends that Fight Club warned you about. It's fine if you want to pass the time, but if you want to have meaningful conversations, debates, general fisticuffs about scalability of languages, you'll need to go drink some alcohol. Preferably: lots.

San Francisco is a great bar town. It's tiny geographically, so there's a good chance you can get a drunk cab home for $15 bucks or less from anywhere in the city. Perhaps it's because of that, perhaps it's because everyone's stressed out, but startup workers love to get their drink on. And it's great. You can be talking about some software project and a random stranger will overhear you and jump into it (because they, inevitably, are also in the tech industry). These are the meaningful relationships you'll build as you live and work here. Make sure you follow them on Twitter while you're at it, too- it's surprising how much of a bond you can make over tweets after you've initially had a few beers.

It's important to cultivate these deeper relationships, because:

San Francisco is fuckin' small

I mentioned it's small geographically, but the actual tech community is really startlingly small. You'll be surprised at how many of your groups of friends know each other. And everyone is hiring. San Francisco must not give five fucks about the national economy, because it's some bizarro world where no one can ever find anyone to hire. If you're looking for a job, virtually everyone is either hiring at their own company or can immediately name five friends at other companies that are hiring. The importance of knowing people is, well, important.

It's not just for hiring, either: it's marketing, it's funding, it's technology resources. These are the people that will tweet and blog about you when you launch. They'll forward your name on to their VC friends. They'll help you out and suggest projects and technologies to look at. For as much cutthroat competition there is in the Valley, it's an incredibly networked and positive-thinking community. Everyone tends to lend a helping hand.

San Francisco rockstars

One last thing I've noticed: the "rockstar" programmer. There's a lot of hero worship in the Bay Area, for good reason: the meetup you'll go to will probably have the authors of your favorite language, framework, or company there.

It's amazing, when you think about it. Imagine you're an actor: you're not going to be able to pound tequila shots with Will Smith or Natalie Portman very easily. Imagine you're a dentist: you're not going to be able to do a keg stand with the inventor of that new bicuspid treatment, because no one knows who the fuck did that.

That said, I love a good stereotype, and the stereotype for nerds is that they're typically pretty nice people. I've found that to be completely accurate for these "rockstar" developers. Ask them questions, buy them a beer, get them to buy you a beer. It's cliché, but they're not any different than you or me. Most of them are shy anyway. I just always cringe when I see someone completely flipping out after seeing this person across the room that they know only through their online reputation. And it does happen frequently. Don't be that jive turkey.

Startup cultures

I'm not saying that there aren't legitimately great startup cultures rising up around the globe; there are. And there are great companies and great products being built everywhere. But I am saying that the Bay Area is the major league and will be for quite some time. You should drop by.

It's a good place to be. Hopefully this'll help out if you ever find yourself in San Francisco, and if it doesn't, let's throw down into fisticuffs at the bar while we talk about that new bicuspid treatment. I hear it's pretty rad.

New Apple Patent Shows iPhone 6 Dispensing Ice Cream

2011-02-21T00:00:00-08:00

No, fuck that. This has got to stop.

Over the weekend there was another story about an Apple patent: Apple 'Safe Deposit Box' Patent Revealed Ahead of Mac OS X Lion. It's some patent about distributed file access encryption mumbo jumbo. A story about a new Apple patent comes out every day or two. Rumor sites love writing about it because it's concrete information coming from Apple, and they usually detail some far-flung product idea that everyone wants.

Who cares.

Companies patent stuff. In fact, companies patent a lot of stuff. Some patents are half-baked, some patents are very real product ideas. But this religious devotion to Apple's patents has got to stop. Everything gets written about. There's entire sites devoted just to Apple patents. Endless discussion.

For a company whose devotees so proudly proclaim that Apple always ships real product rather than peddle vaporware, the amount of significance placed on patents is baffling. These are possible ideas, possible approaches. Nothing is concrete, and even if the general idea is interesting, Apple will certainly change the UI, physical design, or ultimate approach to the solution.

A lot of what Apple does isn't rocket science. Apple is past the point of bringing something truly novel to market: they're not adding data streams piped directly into your nervous system, for example. They're at a scale where they can't really bet the company on super-futuristic technology. Even iPhone and iPad were relative straightfoward extensions of OS X and the Mac lines.

What makes Apple novel is their approach to the mundane: how their UI is simplified, how their engineering processes are refined, how their operations and business deals are arranged. And that makes patents fairly valueless. Everyone knows they'll have a cloud-based streaming solution at some point; come up with the most boring, straightforward approach and you're probably pretty close to what they'll ultimately ship in the future. What will distinguish Apple will not come from anything detailed in a patent; it will come from the approach they take to those ideas.

In 2004 or so, there was a patent for Apple to embed hundreds of iSight camera lenses in-between pixels in a Cinema Display, so you could look directly at the screen and your face would be better oriented for conversation. That shit ain't here. The "Safe Deposit Box" patent from the weekend was appearing in patents at least from 2005 and possibly earlier; that shit ain't here. For the last decade Apple has apparently been on the precipice of delivering a flat-screen internet TV. That shit ain't here.

All of these things may be coming, but at some point we need to realize that applying straightforward logic to Apple may derive better predictions than speculating on patents.

Graduated with a Major in Startups

2011-02-07T00:00:00-08:00

A few years ago, I graduated from Carnegie Mellon. Boasting some of the top technology programs in the world, CMU graduates are specifically recruited by Google, Apple, Amazon, Microsoft... the who's who of the tech industry.

I work for GitHub. Around half of the company either dropped out of college or just didn't go.

Virtually none of the technical skills I studied at CMU are used in my job. Everyone at GitHub is self-taught. I'm pretty sure no one at GitHub even realized I went to CMU until a few months after I was hired.

Why is there such a disparity in the startup world? Is this something we can change? Can we better prepare university students for life as a startup worker? Can we teach startup culture?

The Startup Life for Me

This deserves some context. I absolutely adore Carnegie Mellon, had a great time there, and it was certainly a formative four years for my character, work ethic, and broader academic enrichment. This is not about "should I go to school", either; that discussion depends entirely on the person and situation. This is about one specific question: how do we, as a culture and industry, produce first-class startup workers from our university system?

In the few short years since I've graduated, I've been completely convinced that I require a startup culture. I'd crumble in a big business corporate hierarchy. There are thousands just like me; I'm nothing special. There's a substantial community of entrepreneurs that love building things, that loathe bureaucracy, that crave the risks and seek the rewards.

It's not for everybody. It's not even for the majority. Most of our industry will be more than happy — and thrive — by taking their courses during school, joining a stable and profitable company, picking up their paycheck and rising through the ranks. That's great, and all things considered I think the university system is starting to figure out how to evolve their curriculum to accommodate those professions.

If you're interested in working at a startup, I think you're much more ill-prepared.

Learn Me Some Tech

The problem with technology that we've battled for decades is how to teach it. It's just too damn fast. You can't teach the same Java course you taught in 2001; APIs have changed, frameworks have evolved, entire methodologies have died, risen, and then been replaced again. But you can teach Java itself more broadly. And that's been the saving grace for many programs: if you teach the foundations of a language, the student can then build upon them, learn the incremental changes, and take those language-specific foundations and apply them to a different language.

The startup world takes this to the extreme. The concept of a startup is, at its very core, creating entirely new solutions to new and existing problems. (If you're not, you're probably doing it wrong.) This typically means completely reinventing existing technology. Or reinventing new approaches to busted-ass processes. Or combining a multitude of different moving parts in a package that's never been done before. It takes a little bit of crazy that is, quite frankly, difficult to learn in a classroom.

So, don't learn it in a classroom.

Just Build Shit

It's not all dreary in my school experiences. By far, my favorite class in my major that I took wasn't a class at all: it was an independent study with Jeff Baxendale, one of my friends and classmates in the program. We paired up with one of our favorite professors who acted as our advisor for the semester. No classes, no tests. Our instruction consisted mostly of "go build something cool", and we met every week or two and talked about the process, what worked, what didn't, potential business implications, that sort of thing. What we built — a killer distributed comment tracker, and a self-referential inline annotation app — was never shipped to the general public (your loss). But we gained a new perspective on managing a tiny team, working fantastically diverse hours and workloads, and building something we cared about. That, in many ways, was worth the weight of all my other classes put together.

I wish there were more emphasis on this. There was certainly more of this in my program at CMU than others (we had two semester-long projects in groups of 5-6 for real-world nonprofits, for example), but I think there's more to be done. The reason I pick on CMU is not because there's a problem with CMU; it's because, as a "top tier" school, if it's not leading the way, how can we expect the rest of the university system to fare much better?

At the expense of being a complete shill for GitHub, I think what would be great is a GitHub class. A semester-long, no-rules class designed specifically to contribute to open source on GitHub (or any other site). See who can get the project with the most watchers or forks. Or who had the project with the biggest impact. Whose code is now in use at the largest organization. Or don't even make it a competition; let everyone work the whole semester and take breaks to just talk about everyone else's experiences. I'd have a blast sitting down and hearing what sort of impact my peers were making in their free time. Or have endless discussions about different NoSQL solutions (at the very least, that will prepare them for posting to Hacker News). With no real expectations, everyone picks projects they're interested in and can gain a deeper experience through that.

You can also stretch the envelope in different fashions, too. Take an uptime class, where everyone gets a VPS at the beginning of the semester and has to keep their box up. Grade based on uptime. Have the professor DDOS them. Simulate a power outage at 3am. Simulate a huge traffic influx. Offline specific components. The point is things start to feel less like a class and more like an actual project, with real consequences.

This is, of course, why internships and co-ops are so great. Once you graduate and join your first job, no matter how prepared you are you're going to have that oh shit moment your first day when you realize you're finally deep into it. Those work programs help mitigate the oh shit moments. But I think we can mitigate that in academia, too.

Better Industries

Don't get me wrong; I'm not advocating doing away with abstract studies. Teaching fundamentals and the theory of programming is what college is for; it creates the foundation for learning future languages and patterns. And I'm not advocating replacing entire CS curriculums with startup-oriented classes, either... again, the majority of students might not be as interested in such a curriculum.

That said, I think there are students that would eat it up. And fostering that is good for all of us. Better students create better startups create better industries.

OAuth Will Murder Your Children

2011-01-25T00:00:00-08:00

Say there's a hot new startup that just launched today that you've just gotta sign up for and use immediately. It's that hot. I bet they even have a whiz-bang HTML5 website. Paul Graham is rumored to be in talks about funding it. John Gruber has already made a snide-but-poignant remark while linking to it. All things considered, it's probably a neato service that runs word frequency algorithms on all of your tweets and tells you whether, statistically, you are Kanye West.

Luckily you already have a Twitter account. And KanyeAnalysis™ uses OAuth, which lets you use your Twitter credentials to sign in! Yipee! As you start to create an account, you flip open another tab to Amazon.com and add a new 808 to your cart in preparation. Switching back to KanyeAnalysis™, you see Twitter's OAuth screen:

In your dark fantasy of determining whether you're truly Kanye West (which, let's admit, would be a hell of a life), you turn into a monster and slam down the mouse button on ALLOW, dooming all of the children to death, leading the cops to question you in their murders and laying the blame game on you until you're forced to runaway to some non-extradition country but not before you get your 808 in the mail from Amazon Prime.

Taking an inch, taking a mile

OAuth has matured under Twitter, Flickr, Facebook, and a multitude of other sites, but almost every third-party app that plugs into OAuth abuses it.

Right now 41 of the 43 apps connected to my Twitter account request "read and write access". There's probably seven of them that legitimately need write access (mobile and desktop Twitter clients, for example), but, from my perspective, all of the others only need read-only access. I hate spamming my followers, so none of the rest of those apps will ever need write access. So why do they have it?

They have it because Twitter has created a culture where the developer can request whatever they want. The user typically will just click ALLOW because, let's face it, they want to use the app, and convenience tends to trump privacy.

But what would happen if the screen were different?

Professionally and personally, I try to avoid checkboxes and user preferences as much as possible. Opt for simplicity. But in terms of privacy, I think you need to allow some flexibility. This isn't some inane color theme preference; this is your user's personal information we're dealing with. Giving them the option to hand it out or keep it private is fundamentally important.

How can I possibly code for that?

When I brought this up briefly over a few tweets a week ago, I got mostly reasonable agreement in response, mixed in with a few "but then it will be harder to develop applications".

Tough shit. That's why we have if statements.

This stuff is a big deal. If a user doesn't want some superficial Kanye West app to read and download all of her private direct messages, she should be able to expressly restrict that. The same goes for apps tweeting from her account. It's not just Twitter, either; I've seen the same thing with Facebook and others. While Facebook thankfully has more privacy levels than Twitter's two-level approach, you still can't pick-and-choose what you like; it's either accept the app's request or you're out of luck.

Some apps may legitimately need a particular level of permission, of course, and I'm fine with that. Native Twitter clients, for example, usually require the ability to tweet for you. But with more and more apps using Twitter and others strictly as a form of identification ("sign in with Twitter!" and the like), you open yourself up for attack more and more often.

If you're creating an app, you should only request the absolute bare minimum of what's necessary. If Twitter wised up and started adding access selection, you should code around the prospect that your app may not receive everything under the sun. It may not be as convenient for you, but it's just another programming problem to deal with.

Automating Inefficiencies

2011-01-03T00:00:00-08:00

My friend Steve Chanin just launched How I Work, a pretty nifty new site that collects a bunch of screencasts about developer tools, workflows, that sort of thing. He suggested I do a quick little screencast, so I did, and everyone ran for their lives.

I decided to do one on some of the tools I use most in my day-to-day interactions with the rest of GitHub: Campfire, my dotfiles, and boom. By combining all of these together, we can successfully make your company's chat room super inefficient. Apply some programming and boom, you're suddenly automating inefficiencies.

Check it out on How I Work (along with the bunch of other screencasts going up there!), or check out the conveniently-embedded video here:

A couple specific links to things mentioned in the screencast:

Reputation: kind of a big deal

2010-12-14T00:00:00-08:00

Reputation is an undervalued commodity.

It's not a numbers game.

It really isn't. Social Media Experts continually harp on numbers: how many hits, how many followers, how many retweets. Numbers transform to metrics because they are easily measured. But numbers are only important insomuch as they are a stepping stone to the true reach of your actions.

Reach is important. If you take an action — write a blog post, publish a photo, launch a website — you want your action to spread to as many people as possible. It's human nature. It's a slightly different concept than simple exposure; if reach is giving a presentation on stage, exposure is yelling in a noisy auditorium without a microphone. There's a difference in engagement.

You want to be on that stage with everyone yearning to hear what you're going to say next.

People respect reputation.

Public figures captivate the public. Powerful, smart, funny, crafty, evil, menacing, malicious. It doesn't matter where on the spectrum they lie; the point is that they're on the stage and everyone has some sort of conceptual idea of who they are. Their reputation dictates their legitimacy and how people continue the dialogue.

Our industry is filled with these individuals. The stronger your reputation, the stronger the reaction you'll get from your community. In the Ruby community, we elevate why the lucky stiff to such pseudo-religious heights because we strongly identify with his playful, positive mentality. Apple has a tremendously high-quality, product-driven culture, and it's no wonder Steve Jobs is heralded there.

Reputation isn't always such a Puritan concept, either. Zed Shaw is an abrasive jerkstore, but his contributions, writings, and output is a frequent boon to our entire industry. Nothing stirs the pot more than Zed's blog posts. The same thing happens when NoSQL nukes a startup, or a tech rag's database gets compromised to pieces. Antagonist bloggers will craft attack pieces, sympathizers defend, and each player carves their reputation into the community a bit deeper.

It's too simplistic to believe in some fairytale where the most impact belongs to the nicest guy on stage. Sometimes the greatest impact goes to the one with the most insightful commentary, no matter how it gets delivered. Generally, people can disagree and still respect you as long as you're consistently genuine.

Numbers still don't matter.

The internet spreads fastest by individuals working on a micro-level, pushing and linking their favorite content to their own networks. You want that to be your content. Give them a reason to push it. Form a narrative around yourself, around your company. There's a reason why Paul Graham's essays shoot to the top of Hacker News within minutes of being published, and it's not because he's gaming his own site. It's because he's created a culture of dedicated individuals who are deeply interested in what he has to say.

At GitHub, we call these people superfans. We owe much of our early, current, and future success to them. It's not a case of simple fanboyism, either; quite honestly our most vocal supporters are often also our most vocal detractors. They feel passionate enough about GitHub to talk about us, to stimulate dialogue with others, and to call us out when we fuck up. We wouldn't be here without them.

This is prime time. The internet happens fast. You can type 140 characters, and within a few minutes have the entire world reading your words through retweets, remakes, and reblogs. The entire process is only going to speed up, too. Start building superfans.

Text Snippets. Boom.

2010-11-25T00:00:00-08:00

Yesterday I released boom, an open source library that manages text snippets on your command line.

"WHAT DOES THAT MEAN?!?!?!‽‽‽‽" you say, your caps lock bleeding into my soul.

It means you now have a quick way to stash and retreive pieces of text. Like URLs. Or email snippets. Or a list of insults ready at a moment's notice for internet flamewars. I spend so much time with a billion shell sessions open that having this accessible on the command line was a no-brainer for me.

Check boom's README for the complete usage low-down, but basically it goes down like this:

    $ boom gifs kyle-wink "http://cl.ly/326M/content#.gif"
    Boom! "kyle-wink" in "gifs" is "http://cl.ly/326M/content#.gif". Got it.

    $ boom all
      gifs
        kyle-wink: http://cl.ly/326M/content#.gif

And then maybe Kyle says something snarky in Campfire tomorrow and I think to myself, hey! I have a hilarious animated gif of him winking at me. Where did I put that again?

    $ boom kyle-wink
    Boom! Just copied http://cl.ly/326M/content#.gif to your clipboard.

And then it's ready to be pasted, earning me lots of stars in our Campfire transcript as everyone has a jolly laugh.

The code's on GitHub, of course, and I'd love to hear how you're using boom, if you're doing something particularly cool with it, or if you've got a bugfix or pull request for me to add.

Steal the Code

2010-10-28T00:00:00-07:00

Learning anything is easy. Internalizing it is difficult.

Something I've found myself doing in my last few projects is to steal ideas from other projects. Not actually "stealing", of course, but browsing your favorite projects and developers and stealing concepts from them. Design patterns. Refactoring methodologies. How does Chris deal with command-line arguments in hub? How does Wayne transition between shell scripting and Ruby in rvm? Anything that conceptually requires you to come out of auto-pilot programming mode and think, "hey, how do I actually do this?" is a great place to start.

Once you reach that point, sure, you could google a blog post to get the answer. But by "stealing" it from someone else, you achieve two things:

You form a mental connection between your concept and that specific project.
You acquire "ownership" in that concept.

"Acquiring ownership" in something you "steal" is counter-intuitive, but think about it: you spend the necessary time to understand the concept, and then you apply it to your own problem domain. The mental act of doing that can be an intensely satisfying process. Once that bell clicks, you'll start understanding why the author may have refactored that method, or why they needed a separate helper class.

Don't get me wrong; hammering things out on your own is great. That's almost an entirely different class of learning, and it works well in the majority of cases. But sometimes learning others' best practices is the quickest way to enlightenment- not in terms of fixing your problem at hand, but of substantially understanding the forces involved.

By seeing how others have tackled your problem, reaching the point of your own personal understanding, and then reshaping it to fit within your viewpoint, the concept then becomes "your" concept and you then have it in your pocket for your next project. It may be just another word for "learning", but as soon as I thought of it in this concrete, compartmentalized fashion — Oh, this is just like that inheritance strategy I stole from Homebrew in my other project a few months back — my ability to retain knowledge has gone way up.

Once you've reached that level of internalization, that difficult concept becomes just another concept you can auto-pilot.

Facelette: On TechCrunch in Three Hours and $0

2010-10-21T00:00:00-07:00

Yesterday, Apple announced FaceTime for Mac. A couple hours later, I launched Facelette, which is basically like Chat Roulette for FaceTime. Post your FaceTime ID, we'll hook you up with a stranger, and you eagerly FaceTime with them.

Response has been great. I'm writing this about half a day after launch, and my original tweet has been retweeted 125 times, I made TechCrunch in three hours post-launch, and there's been about a tweet a minute about Facelette this morning. All of this for about an hour of work, and $0 invested.

Basically, I lucked out. This is the dumbest experiment I've done, and I happened to come upon a novel idea that I figured people would really want to talk about as soon as they heard it. It's probably not easily repeatable, but I'd thought I'd share some of my thoughts on the journey itself.

Technical

I'm not sure things could get more basic on a technical level. There's a time and a place to experiment with new technology and new platforms... this was not one of them. I just wanted to get something out the door as fast as possible. (In my mind, literally hundreds of developers were all working on the same idea! What if I weren't first? It would ruin everything!)

The app itself is 34 lines of application logic in Rails 3.0. Add a stylesheet, add some HTML, about an hour of time, and you have Facelette.

I'm currently spending zero dollars on the project. It's all hosted on a free Heroku instance. I host the code through GitHub. The domain itself, facelette.com, was somewhere around $20, but my domain registrar refunded the money. I use iWantMyName, which is the cleanest, craftiest registrar I've seen- they have one-click installs for things like Heroku, GitHub Pages, and Google Apps. Totally awesome, and it's a credit to them that they're supporting customers who recently dip into some good buzz.

Usage

The best part of this all was that the damn thing worked. I mean, that's to be expected since there's not much there in the first place, but this project was special to me just because I could talk to my users in real-time. That was the entire point of the site. It was a total blast. Within a few hours, I had talked with Oklahoma, Florida, Brazil, Russia, Spain, and even my arch-nemesis from BitBucket, Jesper, in Greece. The entire thing is such a trip, I love it.

Last night, concurrent FaceTime users were hovering around 3-6; this morning has been more towards 10-12.

Monetization

I've seen the post-mortems on Hacker News. I know what I'm supposed to do. I'm supposed to show you graphs of traffic received from Hacker News vs. TechCrunch vs. Twitter vs. Whatever else. I've had people ask to run ads on Facelette, I've had recruiters tell me I'm a great fit for their Stealth Startup that's written in PHP and other languages I no longer remember, and everyone is convinced their service would make Facelette a real smash hit.

The Startup World is great because of this. So many people with so much ambition, trying to squeeze out The Next Big Thing at every turn. Someone puts together a weekend project and Hacker News descends on them, suggesting Facebook integration! And real-time chat! And SEO! And node.js! And tips on their first hire!

I've also come to loathe this mentality, at times. It's the same mentality where someone whips up a two-page website and asks people to "review their startup!" I think startup is a phrase that's been abused. You've made a project, or a mashup, or a hack, not a startup.

And that's cool! Embrace that. More people need to do stupid shit. I mean that from the bottom of my heart. Don't do it to make money. Don't even do it to learn hip new technology X. Do it for the sake of doing something stupid. We're in the most ridiculous industry on earth. You can whip something up in a few hours and before you know it, people around the world will be using it. That is insane. An architect or a fireman or a lawyer or anyone else can't say that for their profession or their hobby.

when you don't create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

_why the lucky stiff

Don't be afraid to build things for the sake of building them. Since Facelette launched, you know what's put the biggest smile on my face? It definitely wasn't being TechCrunch'd; it was two tweets and a comment that said Facelette put a smile on their faces.

My Favorites From Rails Rumble 2010

2010-10-17T00:00:00-07:00

This year's Rails Rumble just finished. It's a 48-hour sprint for small teams to whip up a Ruby on Rails app. As expected, the apps this year were even more gorgeous, more polished, and more amazing-er than last year. I didn't get to participate this year, but you better believe I can armchair quarterback my favorites to you.

There's about five million apps this year that I was impressed with, but here's a couple that I was really impressed with, in no particular order. I definitely encourage you to browse the whole list of teams; there's a lot of interesting apps tackling some unique problems in there.

Remember... all of these were done in 48 hours or less, which is kind of insane.

Boarrd

Boarrd is an app that I've wanted to do for some time; it's basically a status board that lets you set up self-contained widgets on a page. Great design, and they have 18 widgets to start out with (ranging from Flickr streams, to Twitter searches, to GitHub project snapshots). Super easy to use, and something that doesn't seem all too hard for them to ferociously build out new widgets into the future.

Splendid Bacon

Splendid Bacon's pretty splendid. Simple project tracker somewhat akin to Cultured Code's status board. It works with GitHub post-receive hooks, too, which makes it probably the hottest thing since sliced butter.

Owe Me Cash

Keep track of who owes you what. Simple. Basically I fancy myself a mobster sometimes, and sometimes you need to break a few kneecaps.

Playbill

Playbill's a quick way to find out what's going down in your city of residence tonight. Cool design, one text field, embedded maps, what's not to like? Nothing, that's what. Nothing's not to like.

And a bunch more.

The Rails Rumble (and other blitzkrieg app events like it- nearly every language and framework has one now) is just fun to watch. It's fun to be excited about web development sometimes. These cats built some cool apps in two days, some of which will go on to become full-fledged apps or businesses. That's awesome.

Sure, a button may not work, or the design may not be up to snuff, or there may not be the feature you want in a particular app. None of that matters in competitions like these. It's the journey we should applaud.

And if you're still some sort of bitter internet commenter after all this, well, shut the fuck up, lace up your boots, and step in the ring next year. :)

Cheers! And don't forget support your favorites on October 21, when the round of public voting starts.

Hey Twitter: Give us our Tweets

2010-09-24T00:00:00-07:00

Welcoming baby Maren, who was born this Tuesday morning in the front seat of our car.August 31, 2010 via Twitter for iPhoneseaofclouds
seaofclouds

Todd's family just increased by one a few weeks ago. I found it to be quite a surprising tweet to read that morning, to say the least. I imagine the family may have some stronger feelings about that tweet than I do, too. To them, it's something that years from now will still signify such an important moment of their lives. Unfortunately, Twitter's not making it easy to retain that nostalgia.

Now and then

Twitter is about now now now. What's happening now, what just happened now, what will happen in approximately now. What you have to say about "now" is interesting to people. What you said about "now" is mostly interesting only to you.

Twitter's a snapshot into your life. How you feel a given day dictates your tone of your tweets. Writing a detailed personal journal is one way to capture your thoughts, but Twitter is another type of journal. The tweets you made after being hired at that company, or while at that great conference last year, or after breaking up with a loved one, or simply being drunk on the beach in a beautiful place with friends... all of those experiences are your experiences. They're important.

Twitter retains

As it stands, Twitter doesn't make it easy to relive these experiences.

You're API-limited:

Clients may access a theoretical maximum of 3,200 statuses via the page and count parameters for the user_timeline REST API methods.

You're also web-limited. I can hit page 159 on my user timeline, but anything after that is a blank page. 160 pages sounds like a lot of tweets, but that only covers me to early 2009; a far cry from my first tweets made in 2007.

What's worse is that this affects your Direct Messages, too. I can only pull back my DMs from four months prior to now; all of the ones before that period are inaccessible to me. DMs are even more intimate than regular tweets, and to lose all of that personal, one-to-one correspondence is a bummer.

Tweet mining

So Twitter's restricting access to our tweets. That's a bummer. But even if they flipped the switch tomorrow on full browse access, that's still not quite very useful. Tweet mining is the real goldmine. Just imagine the treasure trove of things you could re-learn and re-experience about yourself if you had the tools to do so:

What were my first tweets? Did I even "get" Twitter? How do those early tweets differ from my tweets today?
What have all my conversations been with @insert-user-here? Were they all serious? Were they all hilarious? Were they somber? Maybe you've fallen out of touch. Maybe they've passed away. These quick back-and-forth conversations may grow to become impossibly important to you, further down the line.
How can we explore my tweets graphically? Can you chart my tweets out by month? By year? Maybe there's a novel way to graphically point out "Hey, this cluster of tweets around May 2008 must be really important to you since you tweeted nonstop over three days".
Can you show me when others thought my tweets were important? If they favorite my tweets, can you show me which segments of my Twitter life might be the most important to me, judged from the perspective of my followers?
Can you break out my geolocated tweets on a map, over time? Maybe an animated heatmap that I can interact with. I would absolutely love to revisit old trips and vacations through the lens of tweets, twitpics, and maps.

Meaning

There's so many possibilities that are exciting to think about. That are comical. That are dumber than hell. That are deeply meaningful.

Twitter is a terse communication medium, and yes, most tweets have very little value because of that. But it's clear that some tweets are the exact opposite. It's a low-barrier of entry to exploring your past self. Twitter has matured to where we can't ignore the significance it can bring to people, to relationships, and to society. The Library of Congress shouldn't be the only one who gets to explore the archives of Twitter; it's something to which everyone should have a right.

A Nike+ Importer for Garmin

2010-09-13T00:00:00-07:00

My little weekend project this weekend was Fatigue, a tiny bit of rubygem that imports your Nike+ run history into Garmin Connect.

Like many others, I presume, I had a few lovely years on Nike+ but recently switched over to a Garmin Forerunner 405CX. It's like leveling up your running: the GPS mapping with Garmin Connect is a really compelling way to visualize your runs. I didn't want to leave my hundreds of logged miles behind, though.

Run fatigue and it'll import your old runs from Nike+. More installation and usage information can be found on GitHub.

On a technical sidenote: I had a fun time using Readme Driven Development and TomDoc on it. I've found I really dig using both of those development mentalities; give 'em a shot and see if they work for you, too.

How to Discover Your Music

2010-09-07T00:00:00-07:00

We finally figured out how to sell music online. Everyone knew that DRM was insane, everyone sort of figured that the general public would buy music more often than steal it, and iTunes came by and demonstrated both. Now people are buying a lot of music online. Cool. Problem solved.

There is a war going on for your music discovery. For years we've had the iTunes model: first, figure out what the hell you're interested in, and then you can go to the iTunes Store, click on an album, and then hear a thirty second sample. Maybe click around for another thirty second sample, and then click! You buy those songs. Or maybe the whole album. And then you own those digital bits. Cool. Problem solved. I mean, it's solved for a few days until we all figured out that the process sucks. But we had to live with it.

Music discovery is the last thing to conquer. How can we show you, the user, which songs you'd love to listen to? How can we involve your friends in those recommendations? How about the general public? How can we get independent artists in the mix?

There have been a lot of companies — big and small — attacking this process over the last decade. Amazon, Last.fm, Spotify, Rdio, Like.fm, Lala, Rhapsody, Grooveshark, Pandora, iLike, eMusic, The Hype Machine, Slacker... it's really a stupendous amount. Some crashed and burned, some enjoyed tepid mainstream success, some retained a small but passionate userbase.

And then Apple decides to launch Ping.

Ping

Apple's Ping has gotten people talking. It's a pretty large effort: in the realm of tiny, gradual growth music startups, Apple had to scale up their service to support one million full-fledged user accounts in two days, with the potential of Ping to be eventually used by the 160 million overall iTunes users. It's a technical feat, to be sure.

That said, the buzz on the street appears to be lukewarm. It may just be the nerdy crew I follow on Twitter and Hacker News are too jaded in life that they scoff at Ping out of mainstream spite. But I think it's safe to say that the initial reaction was less than stellar.

Making a Better Ping

It gets you thinking: how should Ping have been launched? Why do people dislike it? More importantly, what cool shit did Apple ignore that should have been in there from the start?

I used to be a steadfast believer in Jobs' usual comment: people may want to rent movies, but people want to own their music. I still think that's true, except in the case of music discovery. When I'm trying out new music, when I want to browse what my friends have been listening to, when I just want to listen to someone's random playlist... in all of those scenarios I'm fine with paying a monthly fee in order to get full access to streaming every song I want, on demand.

I've come to think Ping should have been more like Rdio and less like iTunes. In fact, that's what I've decided my music setup will be for the foreseeable future: all of my "main" music is in iTunes, all of my music discovery is handled by Rdio.

Rdio does a few things really well: on login I get a snapshot of what my friends have been listening to (above). I can also browse their playlists and make my own. More importantly, I pay a small monthly fee and I can stream everything on the site, without incessant 30-second limitations, without locked-in walled gardens. I've already found a number of new artists in the last few months that I would never have otherwise heard of. I have a somewhat less favorable outlook on Ping's ability to deliver that.

Apples and Labels

So why isn't Ping more like Rdio, or Spotify, or the multitude of other social music networks with good ideas? Two reasons: Apple, and Labels.

Apple

Apple doesn't understand the Internet. This could be made no clearer than when Ping launched on iTunes and on iPhone (and presumably soon enough, on iPad) only. If you're trying to make a social network for music, you're cutting the legs out from under you if you take away the one sharing option people understand: URLs. Taking it out of the browser means it's a walled garden. Yes, there are ways to link to individual Ping pages through really gnarly-looking URLs, but most people won't understand how to do that in the first place (not to mention scores of bookmarklets, browser plugins, and other sharing niceties aren't present in iTunes). Apple has a funny idea of what a social network is.

Labels

I think the other elephant in the room is music labels. Apple's at a disadvantage: they're big enough to freak out the old guys in boardrooms across Hollywood. Startups get more lenient terms because of smaller marketshare and less potential for disaster. This is why Apple's struggling to even get one minute previews of songs on iTunes. Any big changes Apple wants to make to the industry is going to be fought viciously from these guys. Startups though? Do what you want. It puts Apple in a rather stagnant position.

Discovery

Ping doesn't cut it in its current form. Inviting people to share their musical tastes and building a social platform on 30 second sound bites is just an extension of the iTunes Store, not a novel way to explore your own potential musical tastes. And it's a bit of a bummer... a network with as much pull and draw as iTunes could have been really killer.

I think we'll get there eventually. Until then, explore some of the other smaller players... they're the ones that will bring you the goods until Apple and the labels wrap their heads around the internet.

Dotfiles Are Meant to Be Forked

2010-08-20T00:00:00-07:00

I'm a big fan of customizing your dotfiles. "Dotfiles" are the funky little files in your *nix-based home directory that allow you to customize your nerdery: change how your prompt looks, set up your $PATH, adjust settings for Ruby's IRB, completely change everything about Vim, and about a billion and a half other things. They're fun.

In many ways, this loose framework is one of the most important tools you'll use as a developer. It dictates how you use every other tool in your software arsenal. And everyone has different tastes, which I find fascinating: sit down at a crafty programmer's shell for a minute and you'll find that out pretty quick.

So many lines

But I think it's a tool that few use, and amongst those, even fewer use well. Beginner-level developers tend not to dive into a lot of shell customization aside from a few aliases for Git, perhaps. And of those who do take the time to sit down and really personalize their shell, it's kind of a mixed bag. Look at dotfiles.org, a nifty little site that's designed to help share your own dotfiles:

Face it: you're proud of that 204-line .bashrc, and you should be! You've fine-tuned your prompt, carefully planned your aliases, and written some pretty time-saving functions over the years.

I've seen this a lot, and it drives me crazy. The same people who have very core ideas about how code should be refactored, minimized, and organized end up having these outlandish .bashrc files. They've probably started out with a tiny file a few years ago and just kept adding... and adding... and adding to it.

Obviously, messy dotfiles make mental organization difficult for yourself, but you end up missing out on some of the absolute best part of dotfiles: sharing the shit out of them.

Sharing the shit out of them

Think about it: these are the files, aliases, and executables that programmers make for themselves to make their lives more productive. If you have a way to easily share your dotfiles amongst other developers, you're only going to make it easier for yourself to pull in someone else's super-awesome-executable that will make your own workflow amazing.

A 200-line jumbled .bashrc becomes a lot harder to share with people. Putting that on GitHub lets others pick and choose from it, but a flat file with the kitchen sink makes it harder to merge in other work from other dotfiles in your network, particularly as both you and your forks grow and personalize your dotfiles. You want to make it easier for people to share code, not harder.

So, organize it

So, organize it. Do what programmers have been doing for years: make a smart system, follow it, and let others use it too.

There's a lot of great projects doing this:

Ryan Bates (@rbates) fame has his own network of 175 forks. His project centers around bash and zsh, TextMate, Vim, and Rails.
Robby Russell (@robbyrussell) started up oh-my-zsh, a community of some 250 forks surrounding zsh.
Ryan Tomayko (@rtomayko) open sourced his dotfiles with a great set of documentation and some 150 developers watching the repository.

My dotfiles

Personally, I forked Ryan's Bates' dotfiles a few years back and loved it. It's great to be a part of a larger community- you can sit in GitHub's Fork Queue, browse what others have added, and within a click or two, add it to your own project.

After awhile, though, I started wanting a clean slate with a much better handle on organization. So, I started from my fork and pushed a new project.

What sets mine apart that I'm kind of in love with is that everything is broken into very specific and distinct areas:

  bin/
  cas/
  ec2/
  git/
  jruby/
  ruby/
  system/
  vim/
  zsh/

This makes sense, at least to me: too many times I'd be in the Git mindset, trying to add a new alias but never remembering where to find it in the long aliases.zsh file I had. Now if I'm adding a new alias for Git I can go straight into git/, edit aliases.zsh and know that all the aliases I'd need for Git is contained within that file. Any new directories created get automatically added to your shell, too. It's really helpful, and lets you scale your dotfiles a lot easier. More importantly, if I'm browsing a fork's directories — which are likely to be very different than mine — I can immediately determine the areas of their code I might be interested in.

So, fork it. Or, if not mine, then fork some of the awesome other projects I mentioned. Or come up with your own way of organizing your stuff and share it. Everyone's got their own way of streamlining their system, and sharing dotfiles helps everyone.

Apple OnLine 4.0

2010-08-10T00:00:00-07:00

Apple doesn't understand the internet.

This is something that every Apple fanboy knows and tries not to think about. It's embarrassing, really. Apple's industrial design is unmatched, their software UI is copied, emulated, and copied again, and their business focus is the envy of the town. But their internet properties are hosted on Tripod wrapped in a <marquee> built in FrontPage '97.

Just look at what they're been doing within MobileMe: iDisk doesn't come close to matching up with Dropbox, the online Mail.app is a far cry from Gmail, and their Photos app is so wildly far off from being a competitor to Facebook or Flickr that it's a stretch to even make that comparison.

It's not a matter of talent. Apple has the money and draw to attract anyone they want to hire. I suspect it's a management problem. It's that senior management really understands software, that senior management really understands hardware, and that senior management really doesn't understand the web. Even the little bit that grew out of MobileMe feels like some weird oddity: they're the only Apple division that has their own development blog of sorts. Nowhere else in Apple are they really allowed to just continually roll out features and announce them in that fashion. In cases like that, it feels like they're trying to act like a "normal" web startup, but the climate of Apple prevents them from really running free like one and building product people want.

Apple is particularly bad at social software. Flickr made it big because they made exploring photos super easy. Facebook Photos made it big because they made photo discovery super easy. Apple's "Gallery" product offers zero exploration and zero discovery possibilities. What's the point of a large-scale product like that?

I'm being a little disingenuous, though. It's rare for any large company to have the imagination to build out new ideas. There are very few "established" companies that have interesting consumer web properties. You could argue Facebook and Google, but they're both startups in terms of age. They were built by people that knew their respective craft inside and out, and that culture grew with their company. That's why Apple's so good at hardware and software- it's grown within that sector for decades.

But we like to hold Apple to higher standards. We like to think that greatness can transcend fields. We'd like to hope that Apple can get a handle on social media, on the internet. But is that even a feasible desire? Can you switch core competencies that easily?

It makes me wonder if the obvious route is the only route for Apple: buy up the dreamers who can dream those new worlds, and then spackle some of it on your existing product lineup. Case in point: Lala. And maybe it's a good thing. It perpetuates the Silicon Valley myth of huge liquidation events, it provides some innovation to companies who couldn't otherwise dredge out of their own culture, all the while broadening the amount of consumers who gain access to that innovation.

On the same hand, though, you still wish that the company you start next Tuesday will be able to confidently handle new markets when they open up in 2021. The pace of technology is unforgiving.

Enslaving Branches: How GitHub Does Enterprise

2010-07-28T00:00:00-07:00

I work on GitHub Firewall Install, GitHub's enterprise-level product. FI is aimed at larger companies that want to host their own version of GitHub on their own hardware. We ship them a full, self-contained stack, and once installed they have their own private github.com on their network. Pretty cool.

It's an interesting product to work on, and it also comes with its fair share of challenges. One of these challenges is figuring out what type of development workflow works best for us. It's a type of challenge you might find yourself facing sometime, too.

Merges

The big question for FI is merges. Most new development is done on master, and we'd like to pull that into our separate branch for FI. The fi branch in particular is somewhat different from a normal branch in that it's long-running. It needs one-way merges in from master, but it also has its own active codebase to maintain as we simplify FI deployment, add enterprise-y features like LDAP and CAS support, and remove some github.com features that aren't relevant in the enterprise.

Needless to say, a good test suite is a godsend. Merging itself may be difficult, but the ability to have your tests immediately point out to you what may be a trouble area is fantastic and, in my view, a prerequisite for this type of work.

If I had to submit a technical schematic of how our merging process looks like from a developer standpoint, I'd probably whiteboard something like this:

This is primarily because the merge ends up looking like this:

By default, I probably want everything in master. That's where the new stuff is, and that's what we're looking to pull down.
Except if the change in question is in conflict with an FI-specific change we've made, in which case we want to keep the FI change around.
Except if THAT change in question is a new version of something we've since changed on FI, which means we need to take what's in master, overwrite what we've done on fi, and then rewrite everything on fi using the new master changes so it's tailored for FI.
And all the while keep a look out for entirely new stuff in master that's going to blow up fi.

That's a little specific to our domain, but there's plenty of other areas where a similar workflow happens: concurrently developing version 2.0 with your deployed 1.0 version, splitting your product into multiple products, or spinning off smaller parts from an existing product that subsequently share the same core library. It doesn't become just a simple merge; you unfortunately have to be a little smart about it. But there are some crafty ways to tackle it.

Conditional Statements

Conditional statements are one way of doing it. It can be a simple as this:

  if Rails.fi?
    destroy_planets_with_lasers
  else
    destroy_planets_with_love
  end

In other words, it's somewhat similar to how Flickr does feature flipping: explicitly branch which code you want to run. Deep in my core, I know I'm not super happy with this. It's unclean, adds verbosity, and you can end up repeating yourself a lot. But remember: merging is what's difficult, and adding verbosity ends up really improving your ability to merge. If instead in the above code we just changed destroy_planets_with_love to destroy_planets_with_lasers inline without the conditionals, you end up losing the context of why that change was made. By glancing at the conditional I can easily grok 1) the change, and 2) what we changed from. All of this can be found in version control, of course — I could git log through and find the original context we branched from — but it's a huge pain in the ass during merges to do that. In this case, verbosity is great.

It's not even just about the merges, either; the branch itself has a lot of specific FI code. Filesystems are simplified, enterprise features are maintained. It's sometimes hard to mentally jump from one codebase to the other, and by explicitly delineating what happens in FI versus what happens on github.com, it offers us a way to easily understand code by showing us the differences. Once we remember how github.com does it, things usually fit into place mentally quite quickly.

Conditional Inherited Modules

One of the things Rick Olson did while refactoring some repo creation code on github.com was to set up what I'd call something like conditional inherited modules. This works great for repository creation: we do a lot of things on github.com when you create a repo, and we do a lot of things on FI when you create a repo. They both follow a similar workflow, but those workflows are different. So set up one module that you can conditionally inherit from:

  module GitHub
    RepoCreator = Rails.fi? ? Fi::RepoCreator : Web::RepoCreator
  end

  module GitHub
    module Web
      class RepoCreator
        def create_directories
          # write to a networked disk
        end

        def set_permissions
          # set permissions
        end
      end
    end
  end

  module GitHub
    module Fi
      class RepoCreator < GitHub::Web::RepoCreator
        def create_directories
          # write to a simple file system
        end
      end
    end
  end

It's straightforward Ruby inheritance, but for those who don't use Ruby, the simple version is that on any branch we can just access GitHub::RepoCreator and create a repo appropriately for that branch. In this simplified example, we write to disk differently so we override create_directories, but FI still inherits set_permissions because that part of the process is the same on both branches.

This is also really flexible: after we did this there was a new option we wanted to add to FI that lets sysadmins create repos a little differently on their network. This makes it really easy to do that- we could just override set_permissions and not have to worry about much else.

The other benefit is that all of our FI-specific code is tucked neatly away in one file, and there's only one main conditional to deal with. This type of inheritance works great for instances where you have similar workflows but divergent implementations. But there are times where everything's just totally different, too.

Overriding Functionality

Sometimes FI itself is completely different. GitHub uses Smoke and Chimney to route your request to a myriad of networked file stores. That's great for github.com but a bit overkill for FI. For things like that we can swap that functionality out wholesale. If we have something like CHIMNEY = Chimney.new, we can instead instantiate our own FI Chimney mock that responds to Chimney's methods but doesn't actually perform operations (or performs them in a simplified manner). You end up avoiding a lot of lower-level code changes all over your project and get to centralize your changes in one tidy place.

Now, Ship Amongst Yourselves

Some code will lend itself to needing only a few tweaks to keep things current with master, some might be too divergent to the point where you can only fork it and split the two forever. Most will fall in-between the two. You'll end up developing your own strategies to tackle your own idiosyncrasies. And who knows, maybe in the next few years there'll be a git merge-for-reals-like-figure-things-out-real-good that'll take care of even more of this for us (at least git's merging skills are quite good- I shudder to think of doing this workflow in Subversion).

Anyway, merge on. And for the love of god, merge frequently.

Is that the new iPhone with the antenna thing?

2010-07-18T00:00:00-07:00

I'm in Fargo, North Dakota this weekend for a buddy's wedding. Fargo is, in my view, primarily known for three things: the movie, the cold, and that it's the only market nearing a quarter of a million people that has absolutely zero AT&T coverage. Forget San Francisco reception woes- Fargo has no AT&T presence at all. It's a struggle for me to even see a two-bar EDGE connection while I'm here.

I'm no stranger to stoking my ego a little every now and then, and on this trip that means pulling out my shiny new iPhone 4 and showing it off to people that are interested. I'd wager I showed it to around ten people in the last 24 hours, and these two things always happened:

"Is that the new iPhone? Can I see it?"
"But don't you have problems with the antenna?"

It kind of blew my mind. Here's a community where no one is technically permitted to own any iPhone in the last four years, and they all seemed to immediately be able to decipher that this iPhone was the newest version. That in and of itself is testament to the incredible buzz Apple has been able to generate. Then they followed up with the antenna problem. That's testament to how much people are captivated by a story.

Say what you will about bumpers, about the Apple press conference, and let RIM and Motorola go on the counter-offensive about their own antennas. The only thing I'm concerned about is that it's still the best hardware I've owned. It's got the best build quality out of any object I've seen. FaceTime is a different, meaningful experience that I'm unexpectedly still using — and deeply enjoying — weeks past that first launch day. The camera is finally to the point where I don't have to lug around my SLR, my point and shoot, or my mini HD camcorder to most places.

I don't experience antenna problems. I was able to reproduce it a couple of times earlier on out of curiosity if I tried hard enough, but the novelty of trying melted away once I started actually using it. My calls don't get dropped. My texts all reach me fine. And the rest of the OS is great, as usual. It could be that maybe I've subconsciously repositioned my hand while using the phone, it could be that I'm usually in good enough coverage where it's not a problem, but my workflow is never interrupted during my iPhone 4 usage. And that's the most important part: if I had to consciously change my usage or how I operate that phone, that'd be a problem. But I'm not.

This isn't a terribly interesting post. I'm not calling anyone out, I'm not link baiting people for those precious precious page views, I'm not posting a sarcastic YouTube video. Society loves a scandal, but good design on a good product doesn't illicit the same response. Human nature, I suppose. Luckily for Apple, it also appears to be human nature to buy a shitgaggle of Apple products. They'll probably be okay.

Web Apps Aren't Apps

2010-06-17T00:00:00-07:00

I really appreciate all the lengths Apple has gone to give web apps a true native feel. HTML5 hooks into geolocation, animation, local storage. Direct iOS hooks into the Springboard ("Add to Homescreen"), and the ability to remove browser window chrome. These are all great things. It lowers the bar and allows a far greater number of developers to run their own code on their iPhone. Really great stuff. But we're missing out on a few core pieces.

Even though you can send your web app to the home screen, move it around like an app, and make it look like an app, it's still not a true app. That's fine; native apps are always going to have a leg up. But by not being a "true" app, web apps face some unfortunate problems.

Web apps miss out on multitasking. I've been using iOS 4.0 for a week or so, and while multitasking works well for web apps, they're relegated to second-class citizens: you have to switch to Safari to access your last page loaded. When I'm in Gmail's mobile client, my context is mail. It's distinctly not web browser that I read my mail in. I launch the app by tapping the Gmail icon, but I lose that context when I'm stuck looking for the Safari icon when switching apps.

Web apps miss out on making that money. I have to believe there's a ton of developers out there that would like to sell their HTML5-based app, but don't want to deal with the billing side of things. That's one of the biggest selling points of AppStore: a lot of people will gladly give Apple a cut in exchange for such a braindead-simple method of distribution.

Web apps miss out on backups. I recently did a clean restore. As advertised, my apps got transferred over, my data got transferred over, but my homescreened web apps didn't. I manually went back and re-added what apps I remembered to my homescreen, but it's really a pain in the ass to do. It's not a matter of the data inside of the apps (they usually sync to a central server anyway), it's a simply matter of not being able to restore the Gmail logo to my home screen.

Broadly, I view this as two problems: how do we make web apps behave more like native apps, and how do we leverage AppStore? Two problems, and I think they have one simple answer: make the damn things native. Toss each web app in a native Cocoa wrapper.

This can happen transparently without any changes for web developers and, more importantly, without any changes for the end user. Still allow users to press "+" on a website to add it to the homescreen, but instead of just saving the URL, iOS can slip it into a special wrapper. It'll show up in multitasking, it'll sync to your Mac, it'll just act more like a real app. It needn't be tied to AppStore whatsoever, so you can still use HTML to bypass any of Apple's rules you disagree with.

But the really killer stuff is if you do want to play by Apple's rules and tap into AppStore. People are already doing this, I'm told; write a thin Cocoa wrapper around a WebKit view and do the rest over offline HTML or on your external server somewhere. And that's great. But there's a huge market of developers that find XCode a little daunting and don't want to have to deal with that.

Think of how game-changing it would be if you could sign up as a developer and upload a zip of your app's code to Apple directly. In the background, Apple wraps that directory in a loving Cocoa embrace. Your compiled binary is then shipped to AppStore reviewers, where you play by the same rules as every other existing developer, and then you're given your all-important "yay" or "nay". There's no complex changes for Apple to compensate for, and developers play in a realm that they're comfortable with. Both make more money.

You can already do this, so there shouldn't be a Section 3.3.1 problem here. You can make some pretty immersive stuff in HTML nowadays, so quality shouldn't be an issue. Besides, we're still playing by AppStore rules, so if the app does suck, please just reject it and we'll move on.

The line has been blending between web apps and desktop apps for quite some time. Let's just nuke the fucking line already.

Androidvertising

2010-05-26T00:00:00-07:00

The last couple of days I've seen a number of different television ads for Android. I think most of them were Verizon-made, but a few others might have slipped in. The focus of these ads seemed to center around a few things: the openness of the platform, multitasking, and various spec-related aspects like processor speeds. It's clear these ads are shots across iPhone's bow, but the attacks themselves are perplexing.

The iPhone's success stemmed from its ease of use. This is the modus operandi for most of Apple's products: never compete on specs or arbitrary measurements because the vast majority of consumers really don't care. And this is why these Android attacks are perplexing: Apple's forced Android devices into positions that just aren't as relevant.

I don't consider this a master stroke of Apple strategic brilliance. I don't even consider this is a boneheaded move by the Android camp. I think it's simply someone's answer to equation: (Android - iPhone = shit we should market). And that makes sense in a lot of realms: our flights have more legroom than they do, our detergent comes in larger bottles, our store is open on weekends. But doing that in the tech world ignores much about what made the iPhone (and similar competing products) so alluring in the first place: it's fun to use, it's simple to use, and it helps you get stuff done.

Beyond that, their strategy is a much harder sell. Apple's recent ads for iPhone and iPad have centered around usage: oh, I just press that and I can get movie times or oh, cool, I can use the internet on that. That's easy to comprehend. It's much harder to simultaneously describe the closed policies of the AppStore and the benefit of an open marketplace in a 30 second spot. Or that you can run an application in the background all the time and call it forward as you need it. It's hard to expect the layperson to understand these concepts when all they really want to know is how to access ESPN.com or watch a movie.

Don't get me wrong: a chunk of consumers want to know this stuff. They understand how speed impacts the user experience and why a faster processor might interest them. They get why arbitrary app installation can rock. And maybe that's really the type of audience they're trying to target. But we're no longer in an era where the general public gives a shit. We can argue all we want whether the general populace is full of morons, but it's not going to sell more product.

In the meantime, Apple continues to push ads that sell the experience, and the Android camp appears to be pushing ads that sell the device. I can't help but feel that Android would be better off if they focused more on what makes their platform enjoyable rather than what simply makes them different.

The Clean Slate

2010-05-23T00:00:00-07:00

There's a certain allure to iPad and iPhone development right now. It's the idea of the clean slate: there's no legacy support, no underlying codebase, no real concepts of former implementations. For every app that is tied to an existing website or business, there's an app that is forging out on its own, with no ties to anything to come before it.

This doesn't happen too often. The iPhone was the first real platform change in decades. You could always do the Big Rewrite every time OS X bumps a version or Windows moves from 95 to 98, of course, but existing concepts and methodologies subtly squeezed innovation, to say nothing of the temptation of leveraging existing codebases and libraries in an effort to just "get that prototype out fast". We're in the middle of a time more free than we've seen in ages. It's full of frustrations, creativity, opportunity, and failure. But it's exciting.

Shipping entirely new platforms is a lost art. It just doesn't happen much anymore. Everything in the Windows, OS X, and Linux worlds have been incremental for the last decade or two. Sure, there's always framework changes, new features born, old features thrown away, but it's rare to sit back and say "Yeah, this is an entirely different way of thinking". It doesn't just take innovation; new platforms require scale. Your new library that you pushed last weekend to your six collaborators, no matter how killer, doesn't count. A platform needs scale to become significant.

It just doesn't happen often. But when it does, it's exciting. The iPhone platform is the latest and greatest example. Whether the ideology espoused by that platform will ultimately win out is irrelevant; that there's suddenly such a big push for a different way of computing is what's important. Like it or not, it's one of the biggest changes since the 1980's.

But that's not the only example. I remember my jaw dropping during the shift from Super Nintendo to Nintendo 64: the games enabled by the new platform itself were completely different. Far more immersive, far more potential. Sony eventually took the crown, but at that point everyone could see the game itself was changing. It was incremental from there, until the Wii broadened the industry's horizons further.

Similar things happened in the web front: frameworks were largely heavy-Java-Spring-ish or interesting-but-closed-source until Ruby on Rails came along and floored everyone. It wasn't just its innovations that were important: Rails brought things to scale, and that's what made it a game changer. One of the early complaints about Rails was that it was all marketing, insinuating it was just fluff, just a toy. But the marketing — whether you like it or not — was a huge part of Rails. The buzz surrounding the project scaled the reach of Rails, spreading its ideas far and wide. Once this new platform — an ideology, really — came around, it changed the landscape and dozens of frameworks all over the language globe grew and blossomed, based in large part to the validation of certain ideas Rails adopted.

I think we're starting to see this now. The iPhone's brought with it a lot of cool new ideas, new lines of thinking about how a phone should be made, how a computer should be made. Android's picked up on this and forked themselves in a slightly different (but very analogous) direction. It's hard to imagine living today with the phones planned by Motorola of 2003. The phone market just wasn't evolving from their stubborn mindset back then. But today, everyone, regardless of carrier, has benefited.

This stuff doesn't happen often. Pretty exciting to be in the thick of it right now.

Rebuild Facebook

2010-05-08T00:00:00-07:00

It seems like every day this past week there's been some new story about privacy issues and security holes at Facebook. People are starting to get really pissed at the company. I'm not; I find the whole thing fascinating. Here we have a massive company who has grown far beyond what anyone had anticipated, and it's experiencing some growing pains as it transitions from the site people signed up for yesterday to the site people will use tomorrow.

This is classic opportunity, guys.

Hacker News is all aflutter about building peer-to-peer proxied distributed neutral neural private interconnected nodes having sex with each other to replace Facebook. I know, right? The whole point of Facebook was that I connect to non-nerds. The moment anything gets even the slightest bit complicated, you start losing them. That can be surmounted in a lot of sites, but for social networking you need to retain as many users as possible in order to exploit the network effect.

The easiest and quickest way to build a Facebook-level of replacement is to just blatantly copy Facebook. Not the Facebook of 2010, of course — today's Facebook can hardly be called Facebook — but the Facebook of yesteryear. Tap into the primal urges that got people really excited about the site in the first place. My university was in the first half-dozen of schools added to Facebook, and I remember this new site out of nowhere hitting roughly 90-95% student penetration within a couple of weeks. That's absurd... but not completely unexpected.

When Facebook first came out, people were excited about person-to-person communication. It was especially enticing for those graduating in my class of '08; we were in our first two weeks of our first year of college when Facebook debuted, and it was the perfect service to connect ourselves with both our newfound college friends and our old high school friends from back home. It had some features like class scheduling and planning, but it was most exciting as a simple, straightforward way to keep in touch with your new and old friends.

Eventually Facebook broadened into what many of us would classify as "true" Facebook: friend connections, photos, status updates, possibly events. And it was good. And then they added their API, and it slowly sank into what it is today.

The ironic part of this is that there's a huge opportunity for a new player in the exact space that Facebook just vacated. Facebook used to be about connections: how are my friends doing? What are they doing? And what are they planning on doing? Today, Facebook's more meta-personal. It broadcasts information that I never wanted to see or know: here's how I scored on a game. You should play this game. You should see this link.

It all serves to dilute the information that really matters in life. Oh? You had a baby? I didn't notice because it was sandwiched between fifty Farmville notices. You visited San Francisco last week? I read my newsfeed much less nowadays, so I missed it and missed your visit. Even stupid shit like you threw a monster kegger last weekend. Awesome! I want to know about that, because you're significant in my life, and I want to stay in touch with you. This is how you're living your life, which is far more interesting than your 7th top score on Scrabble.

Facebook's proven there's a huge, huge market for superficial interactions. I'm not knocking that; it's gotten a lot of people into casual gaming, and millions of people enjoy mini-games and the social atmosphere surrounding the Facebook app ecosystem. It's just not for me anymore, and judging from the backlash lately, lots of other people, too. The beauty of it is that I think these are two separate markets now. Facebook's moved onto some weird amalgamation of games and APIs and graphs and crazy. A smaller, simpler experience can coexist with that.

Make it simple; follow Twitter's lead. Make it focused; follow 37signals' lead. Make it social; follow Facebook's lead. Make it private; follow, well, that might be where you have to blaze a trail, but it shouldn't be hard... just don't be a dick with other people's data. If you can resist the temptation to toss the kitchen sink in it, there's a good chance you can develop a following. From that following, build it up into something meaningful. I'd love to see a killer new startup tackle these issues.

There's a lot of excitement in personal, direct relationships that no one's tapping right now. Twitter's too open, Facebook's too broad. Let people rediscover through text and photos the real, physical connections that have been pushed aside in the last few years. A big, lumbering giant with privacy concerns is too big of an opportunity to pass up.

Here: a poke for good luck.

Apple is Petrified

2010-04-27T00:00:00-07:00

Apple is petrified.

This thought occurred to me after watching a video of Spotify's new features: social sharing, tight mobile device integration, local library syncing, streaming, the likes. I don't use Spotify, and I don't know whether that'll change in the future, but I became far more interested in just the concept of Apple trying to do any of these.

Apple's the company everyone pins as being BOLD and BALLSY and other colorful adjectives describing "fuck you" attitudes towards ingrained ideas. And now this is the point where it's custom for me to mention dropping the floppy drive. And supporting USB instead of serial ports. And Wi-Fi. And the continued lack of Blu-ray (does anyone actually feel like they need that anymore anyway?). And so on and so on. Apple's certainly been in the midst of controversy for these types of decisions, and they've all turned out to be great decisions. Cool.

But can they really do it for themselves?

Apple has a problem: iTunes. I've written about iTunes before, specifically with regard towards how Apple transitions it into the future. Cloud-based streaming, wireless syncing, cutting features, simplifying the bloated iPod syncing. They're all relatively safe bets for the vague short-or-long-term future. But there's a difference between Apple founded in 1976 versus a startup founded last year. Apple is heavily, heavily invested in iTunes as a platform. I don't think they can just trash that.

I'm sure they want to. They're the company who, after years of iMovie development and versions released, allegedly threw it all out the window after one engineer decided to rewrite it as he saw fit. Apple saw the demo, threw resources behind it, and shipped a better app, in my opinion. I wouldn't be surprised if there's a hard drive full of iTunes replacement demos and sketches and prototypes and possibly even finished projects at this point- iTunes is so old that's a near guarantee. But today we're still stuck with a huge, all-encompassing app that handles everything.

This isn't a technical challenge. If Spotify can build these features as a smaller startup, Apple surely can several times over. And I'm sure they can continue to toss them into iTunes. But at some point, I think it's going to be clear that they're going to need a fresh start. There's just way too much stuff in iTunes for comfort. And some of these new ideas — cloud-based streaming, for one — might be different enough to where it just doesn't work to shoehorn it into the iTunes GUI anymore.

What do they do? Rewrite everything like a startup would and make the perfect media manager and player? I'm sure they could and want to do that. But iTunes is comfort. iTunes is your interface to some of your most prized possessions on your computer: your media. iTunes is what hundreds of millions of people have gotten used to over the years. iTunes has a huge ecosystem on top of it: from software integration like Last.fm or Growl helpers, to homebrewed AppleScript, to people's mental models of how music "should work". The former technical issues Apple doesn't shy away from: they'll pull the rugs out from under developers without too much of a sweat. But the latter, how this software has grown deep roots on a human level, is something I don't think Apple has had to face before.

Microsoft has, of course. They've been battling all this for years. And the funny part is that much of their issues stem from what Apple cares less about: the technical side of things. They worry more about backward compatibility, about breaking third party software, about breaking device drivers. And they still are fighting that battle. On top of all that, there's still people on Windows XP who adamantly won't upgrade not because of the technical worries but because it's different. It's outside of their comfort level. It's so utterly ingrained into them that moving scares the shit out of them. Sure, maybe I'll upgrade applications, but my OS? That's my anchor point! How do I work without my anchor?

iTunes is like that to many people. Not nearly as ingrained as their OS, but outside of the geek circles we inhabit there are an awful lot of people whose primary application is iTunes. They might use Word here and there, some web browsing, some emailing, but iTunes is likely open all the time and in use all the time. It's how they sync their data. It's how they watch movies. It's how they buy music. It is a big deal to these people.

This isn't a matter of "wtf morons, get your shit into gear and upgrade" if iTunes 14.0 is rewritten, simple, fast, and awesome. If there's one little thing in there that Apple deems too unimportant to make the cut, someone will inevitably complain and all the sudden there will be eight hundred Facebook groups titled "ONE MILLION STRONG AGAINST ITUNES 14 WHERES OUR LIBRARY SKIP COUNT TRACKING". Facebook is a stellar example of this whole shit-bricks effect: every time Facebook changes their design or some other major component, everyone shits bricks. Not because the change itself is necessarily bad, per se; it's just different. People are scared of change, and that goes for triple in the nascent technical world.

Don't get me wrong: Apple's going to change iTunes in the future. The rumors of their massive, massive data center nearing completion gives hope towards some cool cloud-based changes, potentially. But iTunes presents a problem that Apple very rarely experiences: a product so ingrained that changing it could pose serious adoption challenges at best, and serious product abandonment at worst.

Personally, I hope they do it anyway. Squirrel away an elite team inside Apple, tell them to solve the iTunes problem, and whatever they come up with do everything but name it iTunes. This is how the iPod will die. Rather than continue to build on an aging system, they created the Touch from scratch, made it awesome, and no one notices it doesn't have... well, I can't think of what it doesn't have, but that's kind of the point.

I don't think they will. I suspect it will be more of the same for the foreseeable future: incremental updates, more feature additions, more bloat, cautious plays. And that's what companies like Spotify are betting on. And that's why all this stuff is so great to watch: if a lumbering giant moves too slowly, someone smaller and quicker will beat them on their own turf.

Unless, of course, the lumbering giant is pretty nimble on its toes, too.

Gizmodo

2010-04-17T00:00:00-07:00

I apologize. Starting out a blog post with the names and photos of some guys as a result of how those guys did their jobs is really dirtbag journalism. Slimy, awful, dirtbag journalism. But don't worry, it's on the internet. I guess. Besides, it wasn't just Jason Chen and Jesus Diaz who were douchebags; there's probably a few other douchebags involved at Gizmodo, too.

Here's the thing. As a media outlet, I get it: getting the scoop is fun. It's also profitable. But there's a certain line that, as journalists, you should be loathe to cross. I get it: reporting on new hardware is exciting. Getting the exclusive is great. Getting the actual device in your possession is astounding. I'll grant you all of that. I'll even grant that you can buy that information off the street. I think that last particular point is wildly dubious — and I suspect Apple Legal might take note of that — but I'll give it to you. What's not news is posting the name, personal details, and photo of some guy who experienced a careless mistake and passing it off as news.

Does reporting the story sans-identifiable information have any bearing on the story itself? At all? As a reader I would have been content with "a software developer working at Apple". I would have been happy if Gizmodo posted that they knew the identity but were refraining from releasing it. All of that makes sense. They strengthen evidence of the story's authenticity by posting all of that information. But posting the details of some low-level employee is tabloid journalism. I suspect even tabloids have standards that would prevent them from reporting on non-newsworthy private citizens.

If it were Schiller or Ive or any other public figure at Apple, sure, it may have been appropriate to release the name. I just feel bad for this random Apple guy. He's probably going to lose his job over what likely amounts to a careless mistake. We don't know if he was drunk or anything close to it; we've all made mistakes even while sober. It will follow him past his term of employment at Apple: the front page of Google for his name already is splashed with articles, posts, and tweets about his actions.

Gizmodo has never really cared about ethical responsibility in the past, so it's par the course, apparently. The New York Times, at least, is reporting on the story without the drivel... old media still leads the way in some facets of journalism.

It's a cool story that would have stood on its own fine, but then Gizmodo had to be dicks. I'm pretty curious as to what Apple Legal's next move will be.

Cloudy With a Chance of Clients

2010-04-06T00:00:00-07:00

When I get a new email I potentially hear the ding of Mail.app up to four times, depending on where I am in relation to my various devices.

We've been through a number of different visualizations of the future: from everything is mainframes, to everything on mainframes connecting over thin clients, to commodity clients networked together, then back to thin clients, and now I think we're moving towards a slight modification of the thin client idea.

The iPad threw me for a loop. My iMac at home — center of my computing setup — appears to be falling off the cliff of relevancy. At least judging from these first few days post-launch, if I'm at home and not coding, there's very little reason for me to get up and hop on the iMac if my iPad's nearby. Not only is it just easier to deal with, but it's the iPad's singular focus that makes it simpler and more enjoyable to use. I use a MacBook Pro as my "work" machine, but the significance of a pure "work" machine is dwindling with the addition of new devices.

The foundation for distributed computing has been built: all my code is on the cloud, my documents/contacts/iCal are effectively on the cloud, and my most-used apps all tend to interface or be built around the web anyway. In short, I can get access to my data from most places as long as I have an internet connection. That's really cool, and it's a luxury we didn't have a few short years ago.

Syncing data itself isn't necessarily the problem anymore. It's the where of syncing, the when of syncing. If I'm on my iMac, it'd be great to get all my notifications pushed to me there. If I'm on my MacBook in a cafe, instant messages should get sent directly to my MacBook and not be duplicated if I happen to be signed-in at home. Same if I'm on my iPad. If all else fails, shoot it to my iPhone. The idea is that everything just seamlessly works, that I don't have to worry to sign out of my iMac before I head out the door, that I don't need to scroll up on Tweetie in four separate devices just to catch up on my tweets, that I don't get the same IM in three separate places at once.

It's not just notifications, either. My iPad was able to sync with my iMac or the AppStore to get my existing iPhone apps, but they were all a blank slate. I had to re-enter all my Google Reader auth details again. Local preferences I saved in one app didn't transfer over to another device. Part of this can be solved by dumping more functionality onto the cloud, but it also means some deeper integration from Apple for developers to sync their data cross-platform, for Apple to know which device to send notifications to. There needs to be an idea of your physical presence in relation to your computing.

It's weird it's gotten to this point. It's a completely strange concept, when you think about it; everything I mentioned can be solved today, with existing technology and some smart developers. The data problem is already solved; it's the data awareness that isn't. But that we've made it this far is pretty astounding. I swap between multiple machines a day, with my email, documents, and communication following me as I do, with relative ease. All things considered, cloud computing has had relatively few widespread, cataclysmic data loss incidents. And the devices themselves are far more futuristic than what we could have imagined a decade or two ago. Sometimes the future's fucking awesome to live in.

But other than that, fix that other stuff.

The Soloist

2010-04-03T00:00:00-07:00

I could go on for awhile about first-party iPad apps (Maps and Photos are fantastic, and YouTube finally transforms YouTube into, well, not YouTube), and about third-party apps (ABC, Netflix, New York Times, and growing competition in Twitter app land are all keen launch-day examples), but I think that time is going to show that these apps aren't isolated cases. These apps are a part of a platform that specializes in really great, best-on-the-planet type of quality.

I think this is a consequence of a lot of things- strong design leadership from Apple, strong leadership from the "Delicious Generation" of Mac developers moving to the iPhone, and indeed, the AppStore itself for proving it's economically viable. But I think the biggest motivator is singular focus, that you're not dealing with multiple apps at a time. No window chrome to deal with, no menu bar menus, no playing second fiddle to one or two or twelve other apps open at the same time. Even if (or when) Apple introduces 3rd party multitasking, I suspect it won't impact the main one-app-at-a-time viewpoint we've had the last few years.

You play differently when you're on stage by yourself than when you're in a 300-piece marching band. Each breath you take — and each you don't take — will be scrutinized by an audience with its attention solely on you and you alone. You make sure your instrument's in good shape, your fly isn't down, your hair isn't out of place. You want them concentrating on your music rather than some inane detail that doesn't even impact your music in the first place.

The app is a soloist. There's too much competition to fuck it up. Whether or not you agree with the amount of mindshare the iPhone platform has garnered, it still is a massive player in the market today. And all of these reasons are why people are throwing their best at the platform, from huge corporate giants to small, cutting edge startups. Either way, there's some really cool shit out there now, and we're going to look back in six months and wonder how we got by without those cool apps that haven't even yet been sketched.

Your Ad Blocker Probably Blocked This Post

2010-03-06T00:00:00-08:00

Ars Technica penned an interesting article this weekend on ad blocking and how it impacts an outfit like theirs. This spawned discussions of varying quality ranging from thoughtful discourse on the problems of client-side ad implementations, all the way to "WTF FUCK ADVERTISING".

I've been in the advertising game in some capacity for nearly a decade now, so I have a bit of a small- to medium-size publisher perspective in all this. Ad blocking has been around for the majority of that time, and that we're still in a battle about it is interesting to me.

It turns out monetizing entire new mediums is difficult.

Fuck Ads

Hey, let's start with users. A large — and vocal — chunk of users block ads. There's three reasons:

The ads, on a technical level, suck.

This covers a slew of ads ranging from poorly-designed ads (audio, graphically substandard, attention-grabbing, invasive) to resource-intensive ads (otherwise known as the "Flash is garbage" movement). In other words, people block ads because they fear ads may otherwise impact their productivity.

The ads, on a targeting level, suck.

This covers everything from low-brow ads ("LOSE WEIGHT FAST!") to adult ads to ads that just don't interest people on a broad level. Personally, I don't even mind ads that aren't targeted to me if the ad themselves are well-done; even though I might not be in the market for a BMW, it's nice to see a well-designed, full-page ad for one of their cars.

Some are freeloaders.

A small group of ad blockers literally won't care and will block regardless.

Fix Ads

As advertising-funded site owners, I'm going to argue the first and last are irrelevant for us. The freeloaders you can't deal with regardless (see: file sharing), and those that block from a technical standpoint are going to be extremely difficult to please, for the simple reason that we've hammered it into their subconscious for years that advertising consists of invasive content. Even if Ars, for example, promises no popups, no Flash, no audio, and no interstitials, users just don't think that way. Ads change over time. This page view may be different than the next. It's easy to block, so might as well block than risk having something jump out at you down the line.

Instead, targeting is a far better option. This includes typical content relevancy (a la AdSense), but it also includes better, high-brow ads. It's the same reason people watch the Super Bowl commercials instead of flipping away: ads are just better then. Far easier to watch. The problem, of course, is that these two areas are extremely hard to make work.

Flux Ads

If you're a small- to medium-sized publisher (even, say, up to Ars-sized), finding advertising is both difficult to do and a pain in the ass to do so. Handling billing, making schedules, monetizing every page view, setting up default chains... just the baseline concepts are a grind to deal with, and every hour you spend reworking ads you take away from doing the stuff you really enjoy doing: namely, working on your site and creating something new.

The path of least friction is to outsource to 3rd party networks. Google, Tribal Fusion, Amazon, whomever. It's far easier than doing direct sales, and they ensure that you can monetize your entire traffic stack from top to bottom. But that's exactly the reason people block: the ads you get are usually shitty, irrelevant, and a pain to deal with. That's the core of the problem: the path of least resistance is the path of most suck.

There's ways to get around this. Google AdSense, for example, is far less invasive, but you're still gambling on the quality of text results to be contextual and not low-brow, and that's a risky gamble. Ideally, networks like The Deck and BuySellAds start taking over as the easiest thing to implement. I run BuySellAds on Good-Tutorials and, though it doesn't offer me enough of a breadth of advertisers to run them exclusively, it does consistently run ads that are topical, neatly-designed, and more clickable than anything else currently.

Farewell, Ads?

I don't think this is going to happen. If the last decade was instructive (which it should have been), it's taught us that site owners are scum or otherwise don't care enough to make advertising an effective long-term revenue model. I doubt advertising is going to completely collapse, of course, but between ad blocking, the user's natural avoidance inclination, and the general decreasing effectiveness of advertising, things aren't going to get better. And the problem with ad blockers is that the online advertising industry has been so messed-up for so long that honest publishers like Ars get slotted into the same grouping as your Viagra vendor and they feel the squeeze financially because of it.

The Human is a RESTful Client

2010-03-01T00:00:00-08:00

There's plenty of great technical writeups and non-technical writeups on REST. In short, REST is one way to model and present your data to your users in a consistent, logical fashion that lends itself to being accessible humans, machines, and your own developers. (I don't know if I just called developers neither human nor machine, but let's go with it.)

There's a number of great technical reasons to move to an architecture like REST. In fact, there's a number of great reasons to implement SOAP, XML-RPC, or similar architecture on your app, the distinctions being less relevant for this post. But REST isn't just for API clients or web browsers: REST is for people, too.

Part of what REST does really well is help you to define the resources for your app. User, Post, Tag, Comment... all of these form the concept of a blog. By defining your structure this way, not only can you craft a machine-readable and machine-writeable interface for your site, but you can end up centering your UI around this, too. It's easy enough to scaffold your usual CRUD of an app: a barebones form to create a new Post, a page to show that Post, an index page to list Posts.

Humans understand this. I'd wager even your stereotypical I-don't-understand-computers Farmville player has a basic grasp on the basics of REST, even though they haven't the foggiest of what a "resource" is. They might not know how to do something upon first visit, but they know what resource they want to interact with. Posting a comment on a blog post? Look for the form labeled "New comment". Signing up for an account? Look for the "New account" button. As long as the resources are basic and intuitive — "create a new TransientSubscriberSubscriptionNode" might be slightly too complex, for example — humans are going to have a good chance at figuring out how to work with your objects.

This is all pretty straightforward, of course. A comment on a blog is simple enough that it's hard for anyone to get that wrong. The problem is when you bleed between objects or devise complex on-page ajax interactions. I have nothing but reckless intuition to back this up, but I'd bet that the majority of the most-confusing forms and interactions online stem from a failure to separate resources sufficiently, or a failure to properly define resources for your app (one resource doing the job instead of splitting things up into smaller pieces, for example).

Admin screens are a magnet for this. The noble idea is to have a few screens to manage as much data as possible, since we really care about efficiency and flexibility and productivity and other words ending in -y. This is where the minefield of checkboxes and radio buttons and dropdown filters come from when you're trying to graft one screen onto multiple interactions with resources that are sort of related but not exactly related. Yes, it can certainly work, but the more you drift from that simplistic, single-resource mindset, the harder it is to intuitively grasp what the hell's going on here. And sure, you can add help text and documentation and mouseovers and plenty more to explain how all these doohickeys interact with the data, but that just means you have a more complex screen that's harder to use and harder to get others to use. This doesn't even take into account the harder technical hurdles you face with complex screens, either.

It's not just admin screens, of course. Complex, multi-page signup forms may expand beyond just the User object and into other areas (Profile, Social Networks, Preferences, Billing, and so on). There may be a tendency to have a listing page that offers inline editing, state changes, and child creation for each object on the page. The listing page may, in fact, list a mixture of four separate resources rather than having four discrete lists. By bypassing the simple and straightforward, the user has to sit and think about how they might go ahead and accomplish their goal. I don't know about you, but users aren't the brightest tool in the shed, so leaving them to their own devices to think for themselves probably will sink your company and likely will cause California to sink into the ocean.

I'm not saying any of these are wrong, of course. REST is meant to be broken, really. It's not entirely all-encompassing; we've all skimped on a show action when the data is small enough to put on the index action, or we've added a few actions to help separate out complex state changes. But every time you cram more interactions into your controller than those magic seven actions or try to consolidate multiple resources into one page, you're not just going against the REST implementation grain; you're going against what might be the most intuitive route for the user.

Boastful, a new tweetback library for your blog

2010-02-13T00:00:00-08:00

I alluded to this yesterday, but finally have been able to release Boastful, a jQuery plugin that grabs "tweetbacks" for your blog. Tweetbacks are like trackbacks- every time someone mentions your blog on Twitter, you can pull in those mentions and print them out on your blog. This has gained in prevalence lately with 3rd party services like Disqus, which grabs all those tweets and integrates them with your normal blog comments. That's a really crappy solution.

Every year or so, the blogosphere circles the wagons and self-germinates on the topic of blog comments. Most of the elitist bastards of the internet — myself included — go sans-comments for ease of living without spam and for added focus on your writing. So I'm not terribly interested in pulling in tweets themselves and tossing them on my blog, particularly since I don't have traditional blog comments in the first place. But I like the idea of at least offering some aspect of dialogue, some aspect of community to the site. The Disqus way of doing things — regurgitating tweets on-page like a comment — never made any sense to me for the simple fact that tweets aren't comments. It's not just Disqus, either; almost every implementation I've seen works this way. This is why if you see this functionality on a site it's almost always tweets that take the form of "RT @someone RT @someoneelse RT @originator Hey! A link! http://example.com". 140 characters (minus your short URL) is not a lot of space to add your personal flavor. But it's kind of cool to see who's linking to you, what the general sentiment is, that sort of thing.

So I tackled this a bit differently. You can see it in my blog footer now (once this post gets mentioned online, that is). It looks like this:

Just the avatars, with a tooltip that lets you look at the tweet if you really are interested. Simple, not obtrusive, and hopefully something where the average reader might say "Hey, I can get some exposure just by tweeting this? Nifty!" (Actually, it might be nice to pull in follower numbers or Twitter bios here, too, as a way for existing readers to find more interesting people to follow. But that'll have to wait for a future version.)

The other difference with this is that it uses Topsy's API, which handles all the yucky details of old data that Twitter normally wouldn't return results on, and breaks through URL shorteners to get to the actual page in question (usually a search for zachholman.com/some-page won't match a shortened url like is.gd/some-string). So no matter how they link to your blog post, it should still be picked up by boastful.

The code's on GitHub, and you can browse the readme there for some additional background on the technical side of things. Hope you dig it, fork it, contribute back, and be merry. Or tweet a link to this page over Twitter. Your mug will look good down there.

The Future of iTunes

2010-02-05T00:00:00-08:00

iTunes is old. It was first released in 2001, with the majority of its code then based on SoundJam MP, which can trace its origins way back to 1999. After QuickTime's recent Snow Leopard rebuild, iTunes is left as one of Apple's oldest apps. That leaves it on a relatively ancient Carbon foundation, which carries some implications John Gruber detailed.

If we accept that iTunes will eventually go through The Big Rewrite — and that assumption might warrant some discussion, but let's go with it for now — what form does iTunes take? Does the existence of iPad fundamentally change iTunes' future? What can Apple's direction as of late tell us about "iTunes X"?

There are three main concepts that form iTunes: Your Syncing, Your Library, iTunes Store.

Your Syncing

This is the eight billion pound gorilla in the app. There's no huge mysteries behind playing a song. You don't need to innovate very hard on that. But syncing in iTunes has gone from very humble and very music-only iPod beginnings to full-fledged broad media iPhone syncing to hybrid iPod+iPhone+iPad syncing. In The Big Rewrite of iTunes, this is absolutely the area that will receive the most attention.

When I first talked about the iPad, part of the problem I had was the concept of where your data lived. In the current scheme, everything surrounded your main machine. You hooked up your devices — iPod, iPhone, and now iPad — and they become slaves to the content hosted on your machine. And it is machine. Not machines. This has been a common gripe for years: how can you keep your music and library metadata in sync between your iMac and your MacBook? It's a huge pain in the ass, and even if you do that your devices are still basically tethered to one specific machine. It's not just a "hardcore techie problem", either; I've heard this gripe from a variety of sources, including my dad. With a more digital lifestyle, more people want to use and sync their stuff in more places.

So where does that put us? The natural direction, of course, is the cloud. It's the holy grail, really: over-the-air syncing of all of your data. You become effectively free from having to worry about where your data is housed, which device is up to date and which is doing the updating, and hell, you don't even have to worry about files (which is one of the things Apple seems poised to dismantle, and for good reason: the file system is still a confusing concept to many). This solves a lot of my initial worries about the iPad, too; if you're not tied to a certain machine, the iPad itself becomes far more capable as a standalone machine.

This is a technical nightmare. Part of it is sheer bandwidth, part of it is reliability, part of it is it's just too damn new of a concept. The bandwidth issue can be solved by, you know, building a massive, massive data center. But the rest is typical cloud computing criticisms, and for good measure. There's been quite a few high-profile mishaps and unreliability. Pushing everyone's media and data to the cloud would be, in a lot of instances, just frightening.

But still achievable. I'm an avid supporter of MobileMe. Between three Macs and an iPhone, it's managed all of my data beautifully, to the point where I no longer care or worry about where my contacts or email settings are. But Apple did have its fair share of hiccups when MobileMe launched, and one has to take into account that the underlying technology, .Mac, has been around for nearly a decade, slowly being built upon and improved the whole time. Expanding that same tech would be a substantial feat, to say the least. But the payoffs are fantastic.

I'd imagine direct, over-the-line syncing would be here for quite some time, and it likely would be the only option for the large initial sync and any large video or music additions, mostly for the sake of speed (even wireless N is painfully slow compared to USB 2.0 and 3.0). But after that initial sync, one could imagine the incremental downloads and uploads of your library metadata — play counts, skip counts, titles, album art, and so on — could be done entirely over-the-air, likely when you're not even using your device. Download an album on your MacBook and, like MobileMe contacts, it gets pushed simultaneously to your iMacs at work and home and your iPhone in your pocket.

One big question mark is how much data gets pushed to Apple's servers. Can you only send Music Store-purchased songs to the cloud, or can you send your songs pirated from Napster in 1999, too? How much will the EFF piss themselves when they realize how much information Apple would have on you? Does the central server even make sense in this scenario, or will you instead deem one of your own machines as the "host" and push all the updates out directly over your own private pipes? A lot of questions, a lot of problems, but still one tantalizing prospect.

Your Library

This is, and always will be, the bedrock of iTunes. It's a way to access your media: music, video, podcasts, and soon-to-be likely e-books. It may seem fairly straightforward at first; list your media, play your media. But I wouldn't be surprised if it's some of the gnarliest code Apple's got. The problem is that, over a decade of use, feature additions, and rewrites, there's a lot of stuff in there. Between playlist subtleties, library sorting, album art display, multiple views (including Cover Flow, List, and Grid), iTunes Store hooks, library metadata, audio file conversion, iTunes DJ, iTunes Genius, ringtones, album art downloading, ratings, and a slew of underlying code tying it all together... it's a feat it works as well as it does in its current form. And the major problem with changing any of this is that iTunes is arguably the most entrenched software out there. Regardless of technical skill level, iTunes is the place most users call "home". It's their media. And everyone has very specific, custom ways of accessing their media. Removing, say, Skip Counts may utterly ruin some subset of users that tend to shuffle their library based on songs they've never skipped, for example.

But in The Big Rewrite, this is an area I suspect would get reworked. There's just so much stuff to handle, and the feature bloat of iTunes has grown substantially. I can't think of one feature release where Apple has ever removed anything from iTunes. That's pretty significant, given Apple is the type of company willing to completely throw away iMovie and replace it with a new version entirely. If they were to start stripping out smaller, lesser-used features for the sake of streamlining and simplicity, this will be the area that will get the most amount of griping and criticism. I suspect they'll keep the majority of the UI and look and feel around as they swap out the underlying engine, but those inconsistencies will creep through the cracks.

iTunes Store

The Store, interestingly enough, has gone through The Big Rewrite. And no one's really noticed. While the Store had previously used some type of web-oriented technologies, as of iTunes 9 it's basically bleeding-edge HTML in a thin WebKit wrapper. This is a big deal. It means for one, they can leverage their existing investment in WebKit for cross-platform compatibility, and two, they can draw from the comparably bigger well of web designers and developers for a more flexible storefront. As a byproduct, this has let them shift more of their content onto the "proper" web; you can browse most of the music store without iTunes already, and just this week they've flipped on the ability to view apps from AppStore on the web.

In terms of the next version of iTunes, the Store is effectively independent of any new development work. It's not nearly as big of a factor as it once was.

For reals?

This just feels like the way to do it. But I wouldn't even wager on a timeline. Apple's been very cautious with iTunes for quite some time, and if they push something this substantial to market and they experience widespread failures, it'll take some time to turn it around. But given iTunes' lag behind other 64bit apps in Snow Leopard, Apple's move to Cocoa, the sheer "oldness" of the codebase, and the much larger focus as of late on satellite devices with iPhone and iPad leading the way, it seems like now's the best time to really make a dent in how iTunes is positioned and built.

Impress the Ladies with Legacy Migrations

2010-01-30T00:00:00-08:00

If there's one thing I've learned from my experiences with women, it's that they secretly can't control themselves if a man is there to sweep them off their feet with tales of legacy data migration suavity. (If you're wondering why I didn't title this in the reverse, it's simply because I didn't feel that it was any particular secret that every man is most attracted to legacy data conversions.)

So, you're a few weeks away from launch day and you have a fair amount of data in an older database structure and you want it accessible to your new app. The possibilities here are really quite endless, and it depends entirely on a multitude of questions: do you need access to the old data in the old app? Is speed an issue? Can you fill records after the fact, or do you need them all immediately in the new format pre-launch? Is this a one-off or a regular thing? Will anyone notice if you instead just add a couple hundred thousand rows of quotes from Dr. Quinn, Medicine Woman instead of bothering with a possibly delicate transfer? These are all equally important questions. I recently did one such transfer, and here's my process.

I actually chose a few different routes. A lot of the data was going to be in a similar structure in the new system and the quicker the better, please. For those cases, you're best off to do everything via database dumps and raw SQL commands. By far, that's going to be the fastest way of doing things. Dropping out into Ruby land is going to be painfully slow. But in some cases, that's a tradeoff worth making. In this post, I'm going to detail the latter process. The benefit of pushing data through Rails is that you have access to model-specific validations, callbacks, and relationships. If you're dealing with complex data structures spread over multiple models and relationships (both in the old and new apps), sometimes the longer processing time is a decent tradeoff, particularly if you can kick off the process and slowly migrate post-deploy.

The first thing to do is make the data accessible to your new app. I've found it's easiest to create a temporary table that you can nuke when you're done. If we're migrating Users between totally different codebases, I'd use mysqldump to dump your old users table and import it with a prefix: old_and_busted_users, for example.

To actually use this data I've seen a few different approaches. The full-blown route is to script/generate model OldAndBustedUser, which gives you access to an ActiveRecord instance of the old_and_busted_users table. That's fine, and it offers you some additional freedom in terms of testing and relationships, but I've found that in a number of cases you don't really need to scaffold yourself out a full-fledged model. For the most part, you just need access to the table and to some relationships. Besides which, generating an entirely new model for your app means you're more likely to keep this old code polluting your new code, which really kind of sucks if you're only going to be doing this once.

The trick I've used is to define all of your models inline. For example, if you're running this as a rake task:

  namespace :import do
    desc "Import our old and busted users into the new hotness."
    task :users => :environment do
      class OldAndBustedUser < ActiveRecord::Base ; end
      class OldAndBustedProfile < ActiveRecord::Base ; end
    end
  end

It's a little funky defining classes like that, but for most scenarios you just don't need much scaffolding. If your task balloons to hundreds of complex, intricate lines, definitely think about refactoring quite a bit more. The model names should coincide to your temporary tables. If they don't, you can do so with set_table_name.

Once you have your temporary models set up, you can use them as you'd expect:

  task :users => :environment do
    class OldAndBustedUser < ActiveRecord::Base ; end
    class OldAndBustedProfile < ActiveRecord::Base ; end
    
    OldAndBustedUser.find_each(:batch_size => 2000) do |old_and_busted_user|
      User.create(:name => old_and_busted_user.name, :email => old_and_busted_user.email)
    end
  end

...the find_each being important since we're in Ruby Land, where instantiating huge object arrays willy-nilly will deplete your available memory faster than the alcohol you experienced on your 21st birthday. You also can set up relationships as needed, too:

  task :users => :environment do
    class OldAndBustedUser < ActiveRecord::Base
      has_one :profile, :class_name => 'OldAndBustedProfile', :foreign_key => 'profile_id'
    end
    class OldAndBustedProfile < ActiveRecord::Base
      belongs_to :user, :class_name => 'OldAndBustedUser'
    end

    OldAndBustedUser.find_each(:batch_size => 2000) do |old_and_busted_user|
      User.create(:name => old_and_busted_user.name,
                  :email => old_and_busted_user.email,
                  :twitter_handle => old_and_busted_user.profile.twitter)
    end
  end

Now for the Pro Tips: if you're doing a lot of data importing, you're bound to have to wipe your database and repopulate a gaggle of times. I found a lot of the manual steps in dumping data to be a pain, particularly in terms of importing into the temporary table. So I'd suggest making use of sed for some fun file replacement (which sure beats having to pick through vi multi-hundred-megabyte-db-dump every time). Assuming you're using regular mysqldump output:

  sed -i '' -e 's/`users`/`old_and_busted_users`/g' multi-hundred-megabyte-db-dump.sql

Your mileage may vary on that particular sed command, though. OS X uses BSD sed, Linux uses GNU sed. I've found the difference to be the spacing after the -i and before the single quotes (denoting an in-place substitution, which is usually safe enough considering you can always re-dump from MySQL if the file gets corrupted).

Since we're dealing with Rails, we get all the fun magic methods, but they're not all fun and games: they'll overwrite your created_at and updated_at fields. Have no fear; record_timestamps is here:

  ActiveRecord::Base.record_timestamps = false
  method_that_does_crazy_zany_stuff
  ActiveRecord::Base.record_timestamps = true

You'll also want to think about turning validations on or off (with a user.save or user.save(false))- validations are good for ensuring the validity of your data, but it's another point of slowness, and if you're importing legacy data there's a good chance your data might break validations anyway.

If all else fails, IMDB maintains a startlingly large repository of Dr. Quinn quotes.

iPad Ambiguity

2010-01-27T00:00:00-08:00

So The Tablet is now iPad. That was a fun little announcement.

There's been plenty of discussion and arguing about the name, the form factor, and its apparent iPhone-inspired lockdown. That's to be expected, in my mind. Apple takes away the number one complaint — price — and people'll find something else to talk about.

What I've been brewing on today is somewhat different. I'm having a hard time classifying this device. Jobs positioned it as something between an iPhone and a Mac, which is true, but what it really is is a bigger iPhone. I don't mean that in the typical ranting way found on the Engadget comment section ("It's just a bigger iPhone wtf"); I mean it in terms of content.

The way the iPhone works is that it's an extension of your data. The vast, vast majority of consumers sync from a laptop or desktop to their phones. Very few get by with buying only iTunes-supplied music and video and retain all of their contacts and email settings exclusively on their iPhone. Given the way the iPad is set up, it also is an extension of your data.

This is weird.

By setting it up this way, Apple's effectively saying that you have to have another computer for the iPad. This is fine, since we've progressed to the point as a society that most people have, you know, a computer. But what type of computer? Apple as a product company has traditionally been much stronger in the laptop market. I have a harder time seeing someone with a laptop picking this up; that makes you mobile twice over. If the iPad is so good as a mobile device, why do you still have a MacBook? If the MacBook offers so much more power and is mobile, why have an iPad?

This points towards people in my situation: those with desktops at home who traditionally might pick up a MacBook to split the difference. This makes total sense to me; my iMac can be my hub, and my iPad is an extension of that Mac. Logical.

But where does this place Apple? Instead of a MacBook I'll be picking up a product at half the price. I may be wrong, but most of those with laptops won't splurge on two similar mobile devices. And the way the iPad is set up, not many will go exclusively iPad.

Does this mean Apple's direction for the future is an iMac + iPad combo? That certainly takes some time to shift buying habits in that fashion, and I'm not sure desktops are what people really are looking for anymore. It's trending smaller than the laptop market. Does it mean that Apple will be forced to open up the iPad for use as an exclusive, syncless machine? By doing that I could install what I want on it — developer tools, for example — and use it in lieu of a laptop. But again, if they go that route they enable their customers to bypass pricier machines for the cheaper tablet.

That's the weird part. It potentially puts them either in the tiny-marketshare business or the less-profitable business. The aggressive pricing is nice, of course, but I'm trying to figure out who they're trying to aggressively attract, given these options.

I think it's a great product that will appeal to many, but that few people — in its current iteration — will be able to look at their existing computing setup and say, "Yeah, this makes sense for me to pick up."

Immeasurably Improve Your Life by 34 Percent

2010-01-24T00:00:00-08:00

So there were a few things that came out of 2009 that improved my computing lifestyle so dramatically that I question your morals if you aren't using them, too.

Homebrew

Max Howell first started work in May 2009 on homebrew, a friendly beer-themed package management system for OS X. The accepted practice before Homebrew caught steam was to install Fink or MacPorts, both of which I always had frustrating experiences with. There'd be some random dependency for a Ruby library I wanted to leverage, for example, and you'd have to pull it down from MacPorts. Between slow servers, slow compilation, and installs that just flat-out didn't work for months at a time, that solution was a source of disgust.

Homebrew does things differently. It's opinionated in that it optimizes for 64bit fast Snow Leopard compilation that leverages your Mac's existing installs of Ruby, Python, and other underlying languages and libraries. Most installs are now as easy as brew install postgres or brew install imagemagick. You can pull down any new installation or configuration changes with a simple brew update. As an added bonus, you can modify your Ruby gems to install to /usr/local, too, which lets you un-sudo your gem installs and just keeps all your third-party library and code in one neat, tidy location. What's even better is that since it's on GitHub, it's laughably easy to fork the project, add your own Formulas (instructions on how to install your given software), and contribute back to the main branch. This means that the Formulas in Homebrew top out in the hundreds, and any broken Formulas get fixed really, really quickly. Loves it. I just wish I could install everything with Homebrew.

Versioning your .dotfiles

2009 was home to the meteoric rise of GitHub, and I think it's the first clear example of developers as a community starting to version control their .dotfiles- their shell scripts, shell aliases, helper scripts, formatting, irb configurations, the whole shebang.

That's all well and good; you get what's traditionally a somewhat private, personal process and get it out in the open, letting everyone else dip into years (sometimes decades!) of carefully tuning and pruning to construct what they think is the perfect shell setup. But what's even cooler is that small networks began to emerge. Ryan Bates of Railscasts fame published his .dotfiles on GitHub and since then he's gotten 300-some forks of his code. (His was the main repo I forked from for my own .dotfiles). The best part isn't his particular dotfiles, though; it's that he's effectively created a framework that everyone else can leverage. My fork is wildly different after a year's worth of heavy usage, but the majority of the commits from the 300 other forks will still apply cleanly to my fork. That means I can browse GitHub's network view, see if there's anything interesting out there that someone else has added to their dotfiles, cherry pick it, and pull locally. A few seconds doing the process and boom, I suddenly have a smart archive extractor. Or autocompletion for Homebrew. Or autocompletion from my .ssh/config.

That I can pull great time-savers from so many different people so trivially is awesome and a half. You develop good habits, too; Ryan's dotfiles and associated forks pushed me from ditching bash in favor of zsh. (And along those lines, if you're looking for a good "community" of zsh .dotfiles, check out oh-my-zsh, which also has a huge following.)

Byline

I'm starting to feel like the weird kid on the playground that plays tetherball by themselves. How is it so many of you have ditched or simply don't use RSS? I love Twitter to pieces, and I follow some insanely smart people that drop great information in their streams, but really, that's only half the glory. RSS, in all its fulltext, dense information glory is the absolute primary source of knowledge for me. I'm always — always — reading my 228 subscribed-to feeds as I bus to work. It's a deeper communication that I'm a little worried people are starting to shun from in this gimme-gimme-gimme crazy world. Also, get off my porch.

Anyway, for those that do leverage RSS heavily, you probably already know about the great NetNewsWire on the Mac, which has been the best RSS reader on any platform for roughly 43 years now. My new love in 2009 was Byline, a nicely-designed iPhone app that, now that NNW syncs with Google Reader instead of their closed backend, will sync up with your Macs, too. And I've looked at a lot of iPhone readers. Even NNW for iPhone leaves me greatly wanting. Its design is so straightforward that it's not really worth diving into here; it just works exactly how I intuitively thought a reader should work. Nifty.

Plancast

My infatuation with Plancast has been a rather recent development, but I dig it nonetheless. Ostensibly, it's a site to manage what you're going to be doing: plans, conferences, meetups, and so on. Really, I just enjoy their execution. Adding an event is really easy- they have natural language parsing so you can say "next Thursday at four" and it'll do a good job of parsing and displaying that. It's a fun way to see what's going on in your city, particularly if you happen to live in the Valley where there's a bunch of tech-themed events planned every day. Add yourself as "attending" to any event, subscribe to it in iCal and it'll show up on your calendar.

Plus, you can look at Scoble, see how many subscriptions he has and events he's attending, and marvel at how crazy that dude is.

Simplifying Rails Controllers with named_scopes

2010-01-20T00:00:00-08:00

So named_scope is great. It's a quick and clear way to share common SQL fragments within your app by defining them in your models. It saves you a lot of repetition: instead of calling Article.find(:all, :order => 'views desc') all over your app, you can define named_scope :popular, :order => 'views desc' in Article, and then call it with Article.popular. There's a lot of good stuff in it; I encourage you to check the initial edge Rails post from Ryan Daigle for more examples.

One strong benefit of named_scope (or, scope, as it's been renamed in Rails 3) that wasn't immediately apparent to me was how much logic you can strip from your controllers this way. Not just logic about which scoped SQL fragment to leverage, but a lot of the logic surrounding how you initially might set up your action before it even gets to your Model queries. This originally stemmed from a discussion with David Kelso over Twitter, where he tweeted about simplifying some common controller code that's familiar to all of us- something similar to this generalized example:

  conditions = ['']
  
  if params[:city].present?
    conditions[0] += "city_name = ?"
    conditions << params[:city]
  end

  if params[:state].present?
    conditions[0] += ' AND ' unless conditions.first.blank?
    conditions[0] += 'state_name > ?'
    conditions.push params[:state]
  end

  @users = User.find(:all, :conditions => conditions)

In other words, you make a variable to hold your conditions (and maybe other variables for any group_bys or joins) and then conditionally build them up- but only if the user submitted values for those particular fields. There's certainly some refactoring we can do already (or avoid everything by using the ever-excellent Searchlogic or a more capable Sphinx or Solr backend), but it's not just a search-specific problem, of course.

Our solution has evolved over time to use a named_scope to handle the conditionals in the model... something which didn't seem entirely obvious to me in these cases at first. It reduces the controller logic dramatically:

  @users = User.with_city(params[:city]).with_state(params[:state])

...with named_scopes defined as:

  named_scope :with_city, lambda {|city| city.present? ? {:conditions => {:city_name => city} : {}}
  named_scope :with_state, lambda {|state| state.present? ? {:conditions => {:state_name => state} : {}}

This results in a far more readable controller, and, more importantly, you can reuse this all over the place now. The conditionals have been tucked away in lambdas in the model. If the passed-in argument isn't blank, the argument is forwarded as a condition; otherwise a blank hash is forwarded on. (Note: if you're using lambdas in named_scopes, you must ensure you're returning a hash, otherwise you'll explode a bit on some funky curly brace errors).

In other words, User.with_city(nil) or User.with_city('') will generate User.find(:all, :conditions => {}), returning all records. It might seem a little counter-intuitive at first, but we tend to look at it as asking, "Hey, give me all of the users with this particular city that I'm not going to tell you about", in which case it makes a bit more sense when it replies "Well, if you're not going to be specific, here's all of them". The other hidden benefit is that this is all much easier to test; the less controller tests the better, in my humble and lazy opinion.

WiiFailure™

2010-01-18T00:00:00-08:00

The Wii is a terribly interesting device. Unimpressive hardware, non-breakthrough game design, overtly simplistic. Yet the Wii has sold roughly the same as the 360 and PS3 combined. From the onset, Nintendo nailed the prediction that they would be seriously outgunned in an arms race. Pushing more bits faster would doom them, so they more or less invented — or at least revolutionized — casual gaming. That clears them from becoming fodder for Microsoft and Sony's battle and gives them a huge space to stretch out in their new sphere. It also opens them up to new competition from new faces.

Change You Could Believe In

I picked up my Wii near launch date (after a few months of battling starved supply). It was a lot of fun; Zelda was one of the finest games on any platform, Resident Evil 4 — a port — still was fun using motion technology, and casual gaming like WarioWare, MarioKart, and WiiSports rounded out the lineup. What I quickly discovered, however, was that my serious gaming shifted to my newly-purchased 360, and my casual gaming dried up. There's only so many frames you can virtually bowl before you decide that maybe real bowling could be fun, too. In effect, there wasn't enough movement in the casual gaming sphere, at least for me and my immediate and extended families, to pour as many hours into the Wii as we did in the initial few years post-launch. I have not touched my Wii in a year.

This wasn't always the feeling. When it first launched and I booted up the start screen, you saw all those smooth, white blank application icon squares on the home screen. As a developer, I immediately thought of two things: that, tied with an open API, developers could supply a consistently-fresh experience straight to your TV; and that the Apple-reminescent UI eagerly awaited some kind of Apple-Nintendo integration.

They haven't happened.

WiiAppStore

With Nintendo taking a fresh new approach to gaming, I had hoped that part of that approach would be to open up the Wii home screen to developers, to let them user your TV in a way we've never had before. Streaming video, mounting and viewing content from your home computer, mini games, mini apps, internet apps, maybe even full-blown TV over time. In hindsight, one could imagine the Wii having its own AppStore. They already have a concept of downloading classic games, with a billing infrastructure already in place. But as far as I can tell, the system remains closed, enslaving the consumer mainly to physical disks and Nintendo-ordained solutions.

WiiTV

Along those lines, I was hoping for more integration with existing systems, like iTunes or Windows Media Center streaming. In effect, this changes your strictly-casual gaming experience into a true convergence box, one the likes of which Bill Gates was clamoring for fifteen years ago. Stream your music, movies, documents, whatever you'd like, straight to your TV. On top of that, you have a familiar device to control it all: the Wii Remote. Similarly, its intuitive motion control puts Nintendo in a position that other gaming companies would be harder-pressed to emulate (try having your grandma play a movie with a PS3 controller compared to Nintendo's offering, for example). You end up with a small, simple system that can play your digital content on your TV in addition to allowing people of all ages to play fun, social, casual games with an intuitive controller.

This all seems very familiar to me.

Apple

The Apple TV is a flop. (I measure "flop" strictly in terms of fanboy-strokes-per-second, which, judging from the Apple rumor boards and blogs, is comparatively at an all-time low.) The recent Apple TV 3.0 update is cool and all, but doesn't solve any real core problems with the device. It solves the streaming content problem, but there just isn't anything more. It lacks in two specific areas: television, and casual gaming.

Casual gaming is within reach. Without any insider knowledge, it wouldn't be outlandish for an objective outsider to surmise that, between the AppStore's past success, vague Tablet/AppStore tie-in rumors in the future, and today's Apple TV, Apple's got some notion of how they might pull everything together for your fat home media setup, too. If they do have some sort of Apple TV AppStore in the works, it's going to place an awful amount of stress directly on Nintendo's shoulders. Once that happens, you end up with a small, simple system that can play your digital content on your TV in addition to allowing people of all ages to play fun, social, casual games with an intuitive controller (in this case, the iPhone itself). Having a DVR baked-in would be a "nice to have", but at this point we already have a compelling system that at least offers very real competition to Nintendo's core market.

This has already happened once before. Case in point: the iPhone has already done this to the Nintendo DS. Whereas a few short years ago I was seriously considering buying a DS for its innovative, not-totally-serious gameplay (Scribblenauts is still one of the most intriguing games I've ever seen), today I would almost find that notion offensive if only for the idea that I'd have to carry around another physical device. I've already consolidated my camera, my iPod, and my laptop into my iPhone; why would I ever want to reverse that trend? I don't think it's shocking to suggest that the days of the dedicated gaming device are numbered. Market reality backs this up, too: Nintendo's recently been facing 50% drops in net profit due to lagging Wii and DS sales.

Casual Mobile Immersive Graphical Hotness

In many ways, this shows the volatility of the fickle gaming market. From Atari's start to Nintendo's dominance, from Sony's reign to Microsoft's successful entry, from Nintendo's huge comeback to the next newcomer, perhaps. A lot has happened in the last few decades. The funny part of it is that we all know what's going to happen: things are going to get more integrated, more mobile, more cutting edge, more casual. But everyone's coming at it differently: Apple and Nintendo are going casual-mobile, Sony's throwing high tech at the problem, and Microsoft's gunning for some kooky full-body immersion. You could probably make an argument that everyone is headed in the right direction, but who's going to get there first is another question entirely.c

Getting Real. Real Tasty.

2010-01-17T00:00:00-08:00

I amused myself today when I realized 37signals does my groceries.

I grew up in the Midwest, where you did your groceries by driving 5-10 minutes to your local supermarket, grabbing a cart, and selecting your food as you wander the endlessly winding aisles. The process, depending on how many you're buying for and how far away the supermarket is, can take 20-40 minutes.

Since recently moving to San Francisco, I've been frequenting my local grocer more and more. It's less than a block away, I don't need to drive, and it's physically small, so the entire process can be slimmed to four or five minutes for travel, selection, and purchasing.

The more I thought about why I appreciated the small market so much, the more I saw that paralleled what 37signals espoused in Getting Real, and, more broadly, to shipping product. It's all about limitations.

The reason I've been going to my local grocery instead of the nearest supermarket is convenience, of course. The time and hassle I save is obvious. But there's a massive limitation: will they have what I want? They're obviously much, much smaller; how will I get by without my precious Dulce de Leche ice cream? The answer, of course, is it doesn't matter.

Would these things be nice to have? Sure. But are they essential? Do they really matter? Nope.

It just doesn't matter, 37signals

Pretty quickly, I found it just doesn't matter. If I'm not throwing a party or feeling like making a special meal that week, the vast majority of the time I'm simply looking to not be hungry; type of food is fairly irrelevant. The things I missed from my local grocer I just stopped getting and substituted them with something different than my "usual" items. The same can be said for web apps. You could try to please your user with every feature under the sun, but users are resilient- they can usually make due with an alternative existing process or feature. In most cases, the difference between the two isn't going to be significant.

Furthermore, you could look at the grocer's stock choices as their idea of what makes a good kitchen. They're a small company. They can't come close to delivering the breadth that a large company can. So they have to make choices. And for the most part, their choices are going to be good enough for me. If they aren't, I can always use them for the majority of my needs, and hit a supermarket every two months when the need arises. In the long term, I could let the owner know what I need, and if enough customers feel similarly I'm sure he'd be fine with implementing my request.

Limitations are a good thing, particularly the smaller you are. If you're building a new site, or if your company is forging ahead against the behemoth, there's no reason to shy away from them. The opposite is true, really: limitations make you who are. A huge company doesn't care about limitations because they're big enough to offer everything under the sun. They miss out on limitations because they don't even need to comprehend them. A small company does, and that shapes how they offer their product, how quickly they can adapt to changes in their product and in changes in their customers. If you're building a data-driven backend there's no reason you both need a list view and a browse view to access the same data. Take a stand, grow a pair and decide which singular view makes sense. It keeps you flexible for the future and lets you ship yesterday rather than tomorrow. The big company doesn't care; they'll build two, three, or five views, because they have the resources. And that's why they'll tend to build a very lukewarm user experience.

I don't mean to harp on 37signals as the end-all, be-all for simplicity in design, of course. But I found it amusing to compare my local grocery situation to Getting Real's table of contents and seeing how similar they line up in places. Simplicity is a little more universal than that. That's pretty cool.

So anyway, what I'm trying to say is I'll have a sandwich, @dhh.

Because 11Mbps is better than 10Mbps

2009-11-30T00:00:00-08:00

Why do cable companies bother advertise their connection speeds so heavily? Internet connectivity has lagged behind hardware specs by about 5-10 years, but they've followed the same path. In the 1990's, a 486 blew away a 386. 512MB of RAM offered enormous advantages over 256MB. But today it just doesn't matter. Apple, in particular, buries technical specs away, because the vast majority of people just don't care if their Core 2 Duo is running at 3.06GHz or at 2.1GHz. Software and hardware have progressed to a point where incremental improvements are effectively negligible. It's the experience that matters. It's the design. It's the freedom. It's the productivity.

Today, connectivity is the same. The vast majority of people are fine with a basic cable internet package. Most YouTube videos — the fattest bandwidth hit for the average consumer — will buffer and start playing within seconds. The connection speed shouldn't be a selling point. The selling point is how your experience is: are your customer service reps assholes? Or the design. Is billing and package management a complete nightmare? Or the freedom. Are you filtering and prioritizing your customer's bandwidth? Or simple economics. Are you dicking everyone with fee after fee, even when someone upgrades their equipment to pay more money to you?

Yes, you techies out there streaming bittorrent over a tunneled Tor node to a DC++ server do want more bandwidth. But you're also not going to buy a random, vanilla metal box from Dell. You're in the minority. It just doesn't matter anymore.

More Logical File System Organization with iTunes 9

2009-11-10T00:00:00-08:00

The iTunes organizational hierarchy has been slowly getting more and more disorganized with each feature Apple adds. When you let iTunes manage your files, traditionally they toss everything in ~/Music/iTunes/iTunes Music. That works great when everything in "iTunes Music" is, you know, music. Once they've tossed movies, podcasts, and a slew of other features in the mix, your directory hierarchy gets really nonsensical with everything in one big ol' pile.

iTunes 9 finally moves away from this mentality, though the feature is hidden by default. iTunes now lets you organize everything into an upper level "iTunes Media" folder structure, which then breaks out neatly into logical groupings: movies, apps, shows, and so on. You can find this in File => Library => Organize Library. You're welcome.

Positioning Apple

2009-10-19T00:00:00-07:00

It's easy to say that Apple has a great marketing department. It's also boring. The interesting question is: why is Apple so good at marketing their products?

Managing Expectations

To put it plainly: Apple is great at managing expectations. I don't really mean this in the traditional sense, that Apple first tries to scope down expectations and then releases an incrementally better version, blowing away expectations and having immediate success. Apple is more clever than this. What Apple does differently is that they mold expectations.

It's not about under-promising and over-delivering. It's about adjusting how consumers use your product in order to reach what is ultimately a great experience. This adjustment can be extremely non-intuitive. I'd argue that historically Apple has made moves in the very opposite direction than you'd expect in order to set up an easy layup months or years down the line.

This is all illustrated better with concrete examples.

iPod Nano's new "camera"

The Apple rumor community had the new iPod Nano pegged for a camera for weeks. Toss in a tiny lens, hook up a small chip, and we're done. It's an interesting rumor, but contains no shockers. It's straightforward enough that everyone thought they had it all figured out.

Steve comes out, mentions the Nano has a camera in it. Cool. The weird part is that it's a camera that takes no pictures; only video. This is strange. The cynical amongst the internet (surprise! there's a bunch of them) immediately jump on two related points: 1. The video quality sucks, and 2. You can't take photos! Seriously! A Linux-based 200GB media center deluxe from 2007 with a massive zoom lens is half the price of the Nano! Apple's screwing you, you suckers!

This is the interesting bit for me. The one fundamental constraint for any Apple-produced device is physical size and shape. More than anyone else, Apple will compromise on almost anything — Firewire 800, battery life, expandable batteries, PCI Express cards, the entire video card itself — with the exception of physical design. It's worked for them. I think it's clear that a number of consumers will pay extra for more durable aluminum casing, a slimmer profile, a more inviting grasp to it. Immediately, this fundamental constraint limits the camera. At a certain physical size, the physics don't work for high quality pictures while retaining small dimensions.

Once the decision has been made to include a camera, the driving design of the product has limited your choices in how to implement it: not well. By constraining design, they just can't implement a fantastic camera. Luckily, "not well" is relative. I'd wager that the chip Apple selected fits into the category of "takes mobile video decently, but the photos kind of blow a bit".

Once that decision has been made, most companies would just toss the bucket at the consumer. It takes decent video, and, hey, you can take some kind of quality of photo, too. This is what makes Apple different. By removing photos from the equation completely, yes, Apple avoids shouts of "This picture looks like garbage!", but more importantly it explicitly shapes the experience into one revolving around video.

It's no longer another smartphone. Or a point and shoot. Or an SLR. Its purpose is strictly for fun, off-the-cuff video for those times you might have your Nano with you. By ripping stills out, it's no longer just another de facto "Photographic Device". It becomes less of an option to bring with you on your family vacation; it's rather a subtle prod that maybe you should bring that SLR or point-and-shoot with you instead. Does this ruin the Nano as a broad, multi-purpose device? Yes. Absolutely. But again, it's not a primary market for the Nano (yet). Having the ability to take stupid, silly little videos is a bit of an untapped market, really. I have a Kodak Zi6, which is nifty and is similar to the Flip, but I have to consciously bring that with me. People carry their iPods around every day; having a low quality video camera on the Nano is going to be extremely popular in high schools and universities across the country. By shifting — not undervaluing — how you're expecting to use the Nano's camera, Apple's able to gently redirect it into another, more successful experience.

iPhone's MMS (or lack thereof)

Pardon my French, but fuck AT&T. Unfortunately, I'm a developer by profession, so I can grasp how messed up AT&T made viewmymessage.com, which was the website you previously were redirected to if you received a multimedia message on your iPhone.

Upon receipt of the MMS, you're directed to either viewmymessage.com/1, or viewmymessage.com/2. One of those appears to be a legacy site that's still in use, and it matters which one you go to- the logins are not federated. Once there, you have to laboriously type (or copy and paste one chunk at a time) a username and a password (the password being memorable, whereas the username being randomly generated, of all things). Inside, you see a maliciously-cropped photo or clip or whatever your insensitive friend texted you.

It's a terrible process.

From common sentiment, this is all AT&T's fault. Their network can't handle full-fledged iPhone MMS rollout, and they apparently can't build web apps for shit. But that's beyond the point; no one expected real competency from AT&T anyway. Again, what's interesting is how Apple managed this.

From the very beginning, even before launch day, you had Steve up on stage going out of his way to say how cool it was to take a picture on your phone, drop it into the mail app and your recipient would then get pretty decent-quality photos. This was the case for two years. It wasn't a matter of saying, "well, sending multimedia is tough right now, so don't expect much, but hey, a few years down the line we'll surprise you with KILLER MMS!" It's a route they could have taken. From the get-go, Apple could have said, "hey, we've got a bunch of stuff on our plate; we'll get to MMS eventually. In the meantime, I guess email could work." Or even, "well, MMS is a little hard to figure out and/or not high on our own lists, so here's a mediocre solution now that we might clean up in the future". Instead, Apple tossed all of its weight behind email. Everyone has email, everyone is used to email. (I'm continually surprised by friends who both 1) don't know what MMS is, and 2) don't receive traditional MMS. A number of my friends who don't receive traditional MMS get it forwarded to their email inboxes automatically anyway.)

viewmymessage.com, for better or worse, has adjusted my expectations of MMS. I hated that solution; I embraced email for sending multimedia. Even though I'm now happily situated with MMS finally, I still will tend to use email for multimedia. I suspect that's good for a number of people: I have a stable, cross-device avenue to share media, and AT&T doesn't have to carry another few kilobytes on their load-laden network.

Like the Nano, for some reason their development cycle was constrained or set up such that a particular feature would turn out subpar or limited in some fashion. By molding expectations, however, Apple is able to change the rules as they see fit. Again, this isn't a surefire way to win support. Plenty of people (myself included) hated MMS, and I'm sure plenty of people don't like that they can't take Nano stills. But they're taking things in a different direction in hopes of repositioning customer expectations.

The subtle prodding

At the expense of over-analyzing every decision, you can start seeing these progressions, these shifts over the course of many products at Apple. iTunes has had smart playlists for years. At first, I found them foreign. If you go way back to the Napster-era WinAmp days, you find everything riddled with static, manual playlists. It's really a carry-over from CD mixes, where you want control in picking each and every song, because heaven forbid you're stuck with a crappy song on your 16 song mix and you're driving in the middle of nowhere and you have to listen to that song.

Smart playlists started making sense the more I grew my library. Top 100 songs listened to. Songs rated 4 stars or higher. Last 100 songs purchased. Things like that. I had started to adjust to letting my computer figure out my habits. I suspect this was something Apple must have noticed years back, but they didn't have the technology to do much with it until recently. Then iTunes DJ and Genius Playlists came into the mix, which let you listen more on a global recommendation level. Most recently, Genius Mixes, which give you pretty targeted genre-based playlists. More and more I don't use shuffle and I don't use playlists; I just let Genius take over.

You can also see this with the evolution of geolocation. The iPhone first got broad wifi-based geopositioning. Then iPhone got quite accurate GPS. Then iPhoto got Places to organize your months of newly-geopositioned photos. Then Snow Leopard got OS-level CoreLocation. I rather doubt this is the last of the progression, either. It's a logical hierarchy, but one that might have been a little confusing with the advent of iPhone wifi-detection, since outside of Flickr there just wasn't many avenues to do anything with that data.

From a consumer standpoint, it's comforting to suspect that there's some grand plan behind everything, that each step Apple takes is a step towards a more integrated, neatly designed end game that will make my life terribly more organized and worthwhile a year down the line. I hold no illusions that this is always the case. I'm sure some brilliant Apple decisions have been complete seat-of-the-pants bullshitting that just happened to hit paydirt. But I also think that what sets Apple uniquely apart is that ability to take high level, end-to-end past-to-future views across entire product lines.