1. Before the replacement

Image 1.1: Before view of the fender

Being rear-ended on a scooter, even at low speed, is pretty jarring. We were stopped and he just rolled into me but it felt like when a clutch slips on an manual scooter and you jump forward. There weren’t any injuries and as you can see above it only cracked one part. What you can’t see above is the seam behind the chrome crash bar. The back fender is made of plastic and holds the license plate, license plate light and a reflector.

2. Removing the crash bars

The crash bars have saved the body of my scooter more than once. Taking these things off is a pain in the butt because they hug the body very closely. Taking off the front part of the bars requires a socket (13mm) as well as something to hold the nut on the back (pliers in this case). I loosened these on both sides but didn’t remove them immediately because I needed the bars to stay in position for the nest step. I couldn’t take a picture with both the wrench and the pliers on at the same time since one hand needed to hold the camera. However, this should give you the idea:

With the front bolts loose I was able to move to the rear bolts. Once again I needed to use a wrench on the outside (11mm) and pliers on the inside (plier picture omitted, you get the idea):

The crash bars are supported in the back by a bracket that passes over the tire and rests on the inside of the fender (image one). That bracket is held on at the sides by the rear bolts mentioned above so once they are removed you can slide the bracket out and then remove the loosened front bolts and remove the bars completely (image two):

3. Remove the fender

Removing the fender itself after the crash bars in quite simple. I have photographed the steps on the left side of the scooter below but the right side is just a mirror image. I started by removing the license plate light, which is held in place by a rubber grommet and nothing more. It’s a bit hard to see in the two images below but these are pictures taken from the ground, under the inside of the fender. The circle of light in image two is the sun coming in the license plate light hole. If you compare the two photos you should be able to see the rubber grommet around the base of the bulb. That’s all that held it in so a light tug dislodged it:

Now on to the real body panels. If you pull up the back corner of the floor mat you’ll see a large screw which needs to be removed:

Once the screw is removed the lower panel of the cowl can be pulled off. Start by pulling on the side closest to the front of the scooter because the back edge is hooked into the fender (see image one). Once the lower panel is removed you have a clear view of the fender mounting screw (image two):

When the mounting screws have been remove from both sides the fender just needs a light tug to come off. You can see below the old   part with all of the accessories on it next to the new part:

New and old, side by side

4. Transfer the accessories

The license plate it held on by four slot-headed screws that require pliers to hold the square nuts on the far side. Once the plate is remove you can clearly see the license plate bracket (image one, shown upside down, sorry.), which is held on by three screws that have nuts (7mm) on the back side. The license plate light housing (which is fronted by a reflector) is held on by two screws from the inside (image two, also upside down, sorry):

And once all of that is removed you have a mess on the sidewalk and someone with a dog is bound to come upon you and give you the stink eye. Remind yourself that they have likely helped add to the feces content of SF streets and feel smug that your shit will be cleaned up in the next 15 minutes and won’t leave a smear that some poor fool steps in. My mess looked something like this, but your mess may vary:

A mess.

5. Conclusion

The steps were easy to repeat in reverse so I don’t see any use in detailing that here. The finished product looks good, though the paint is not a perfect match due to aging:

Ta-da!

This is an off-topic blog post about a scooter repair meant for one (or maybe two) people to read. If you’re not one of those people and you’re reading this then hopefully you found this through some very obscure search and you’re saying “Thank god somebody wrote this down”. I leave you with this moment of zen:

Non-ASCII URL Hashes

The first bug I ran into has to do with assigning a new value to window.location.hash in Javascript. Our site uses the hash (or anchor) portion of the URL quite extensively in something generally called “hashbang URLs”. Two of my colleagues at Twitter have discussed the pros and cons of this approach publicly but what’s important here is that we use it today and therefore do more work with the hash portion of the URL than most people. This matters for hashtags because we catch the click on hashtag links and navigate by assigning the search to the window.location.hash.

Safari 5.0.5, and possibly earlier versions, are buggy in the implementation of assignment to window.location.hash. This isn’t a quirk, or a feature-I-do-not-appreciate, this is a bug. It’s fixed in 5.1 which makes me very happy. Our site was attempting to assign #томск to the window.location.hash but the page kept switching to #B><A:. After a bit of reflection on the issue I noticed that the two are the exact same number of characters. What a curious coincidence. Well, it turns out it’s much worse than I thought:

Safari 5.0.5 hash alteration

Look at that! Safari 5.0.5 seems to have turned all of our well formed Unicode into ASCII by stripping out all of the high bits. I thought this must be a problem with our page but our pages are UTF-8 encoded so those are not even the bytes on our page (and it also works in all other browsers, which is always suspicious). The fix for this was quite simple. If you re-build the complete URL and assign it to window.location.href the encoding is left intact. As a bonus, Safari correctly recognizes that the only change was the hash and does not trigger a full page reload. If you’re using hashbang URLs in languages other than English this might bite you. Beware of changing to window.location.href because IE does a full page reload, thus disabling your carefully crafted hasbang plans.

Regular Expression Size Limit

After testing our new hashtag regular expression in a myriad of browsers we thought we were covered. It turns out that Safari 4.0 and below have a limit on the maximum size of a regular expression that is lower than the browsers we tested. I had tested in Safari 5.1, because it is what I have, as well as several versions of Firefox and IE. Running multiple versions of Safari on a Mac is somewhere between impossible and difficult as far as I can tell, so beware of this one because it’s hard to test.

The regular expression in question contained a character class that had every Chinese character, which was admittedly excessive. We were able to refactor into character ranges and verify that it works in all of our supported browsers, so this was more of a coding inconvenience that a serious bug. The inability to run two versions of Safari feels like it’s setting me up for more failures like this in the future. If versions don’t act the same (and they shouldn’t, otherwise what’s the point?) then developers will need a way to run multiple versions to test. Without that this is a losing battle.

The code itself is shockingly simple but effective. Dustin already has an example built into his website. Here is the normal page (emphasis added to the demo link):

When you click the demo link (pointed to with the Click Me. label) there is a small amount of Javascript that alters the link tag to point the the CSS file that R2 has processed. The resulting page shows the CSS direction change with zero customization:

While this is obviously not everything one needs to do for right-to-left support (of note above are the Twitter follow buttons) it’s a good starting point. If you have a large CSS file to start with the alterations can be daunting. I recommend using R2 and then troubleshooting the remaining bugs. I created a Ruby port of R2 in part to improve my understanding of R2 and in part in the hopes of using it in some future Rails project.

As I mentioned above I’ve been working on Twitter’s community translation tools from the beginning. I originally called it “crowdsourced translation” but over time I’ve come to call it “community translation” and appreciate the subtle difference between the two terms, or at least started using them to mean two slightly different, but similar, things. The explanation of that difference explains is a little interesting but it’s most interesting because it highlights the biggest benefits Twitter has seen from translating this way.

I see “crowdsourcing” as an activity that requires very little or no prior knowledge of the problem space at hand and which can benefit solely from a wealth of different opinions/views/activities. A great example of this is search engine relevance evaluations. At their most basic these evaluations ask a group of people to search for a term and mark different links on the results as on- or off-topic. In more complicated scenarios they ask the participants to re-order the links into the “best” order, or to compare two result pages side-by-side and pick which is best. In all of these scenarios the activity does not require that the person have any idea how search engines work. You’re not asking an expert in the field to evaluate something, you’re asking the largest, most diverse group possible to evaluate it so you can understand the problem.

In the case of Twitter’s Translation Center we rely heavily on our user’s prior knowledge of Twitter itself. While that might seem like a minor difference it matches exactly what Nicholas Muldoon said above about Atlassian in the original Quora topic, “translations provided by our Language Service Provider were not translated by people who used the product“. Twitter has also experimented with Language Service Providers (LSPs) and they do a great job at some types of tasks, while at others they don’t. The reason I now call it “community translation” is that we have taken an existing community of users and asked them to help based on prior knowledge. We did not take a group of people at random, but an existing community (bi-lingual Twitter users). We also didn’t take a collection of professional translators because while our task is translation our actual problem space is actually Twitter, and how it uses language.

One quick example to highlight the difference in community translation quality versus professional translators: Twitter uses the word “unfollow” to label the button that stops following another account. If you ask an LSP to translate this they will likely return a phrase such as “Nicht mehr folgen” in German. If you ask a translator (or linguist) directly they will probably point out that “unfollow” isn’t a word. Twitter’s language is very informal in English and community translation has helped us keep that playful tone in every language (even the ungrammatical “Entfolgen” in German). This might seem like a small thing but the consistency of product language with the product itself is really the key to translation quality. The localization industry has known this for ages and has made great strides in “source document quality” to that end (limited grammars, style guides, etc.).

As Alex Lane said in the original Quora topic nobody is crowdsourcing advertising, accounting or legal translation work (he might have meant the functions and not translations, but I took it to mean translation). Even Twitter does not do that because the language of those domains is formal. Our community of translators are an asset because they know our domain so well. They don’t know those more formal domains so they would do as poorly at those as an LSP does with things like “unfollow“.

In the beginning, there was Geocities

When I first heard of mainstream internet usage there was a general feeling of excitement about every person being able to share their views and knowledge with anyone interested. Internet savvy people practically stood on soap boxes in town squares telling people they should  have a presence on the internet. After all, the greatness of the internet is the fact that any one of us can have a site all our own – our own internet-identity. Enter Geocities, a free way to host a site of your own (I know there were others, but Geocities captured the imagination) for the modest price of learning HTML. Or, as luck would have it, there were some templates to get you started.

Some people were drawn to the internet by this and stayed. Most, however, put together a hasty page with a few words and an “Under Construction” icon and moved on to other things. Even those who spent the time learning HTML, or finding a good template, soon felt like they just didn’t have enough to say to fill a site. Posting was technically difficult, graphic design was harder than anticipated but what killed the Geocities utopia more than anything was that most people realized they just didn’t have enough to say to make it worth all of that effort. If this self-expression on the internet thing was going to work out something had to give.

And then came Blogger

The homepage craze died down among the majority but it was clear that the internet-identity and self-expression dream still lived on. While I don’t know if that was the direct inspiration for blogs I would argue it led directly to it. It was clear to the creators of early blog platforms (Blogger as an early and popular example) that people had things to say and there was a business in making that easier. Blog platforms removed most, if not all, of the technical and design challenges that the home page era had suffered from. All you needed to blog was an idea and the time to write about it.

Blog platforms made (and still make) publishing easy but they didn’t do anything to ease what I see as the crux of the problem. You see, most blogs stop after a month or two (cached) and the main reasons are a lack of things to say and the time it takes to create a long-form blog post. That lack of things to say might be true or it might just be in the eyes of the author. Hell, my own update rate is erratic for just that reason. If I have a spare few hours I don’t run to post what’s on my mind for nobody to read. I only write when I feel I have both the time and the personal desire to get something off my chest – reader be damned (sorry).

And here we are at Twitter

I talked about Twitter in the intro and here is where it all ties back. I see Twitter as the next logical step in the process and that’s part of how I use it. There is no longer a technical or design learning curve and the amount of effort required at any one time is small. Twitter does not replace all blogs, just like blogs did not replace all home pages. This has all been an evolution from having a whole site that was infused with you in both design and content; to a place that expressed your views in traditional long-form content; and now to the sum of your small thoughts and observations. It turns out those small bits add up to your self-expression and your identity on the internet. You are what you say , what you do, and even what you repeat, on the internet just like everywhere else.

Could it get simpler to publish? Sure. Could you distill human communication down any more? Perhaps. Maybe that’s the vision for gruntr.com … maybe the next big thing will be a system where you can only poke and grunt. Physical-gesture-over-IP? I’m in. Watch out AT&T Wireless customer service, I foresee some angry gestures from SF residents.

The root cause and how the problems surface

If you work on internationalization issues and use MySQL you’ve probably run into this. If not then it’s only a matter of time until you run into it. This is the dirty little secret of MySQL before 5.5 … it only supports characters within the BMP (more on what that means in a moment). With Unicode 6.0 over 50% of all characters are outside of the BMP so that’s a big deal. To me it was a big deal before, but with Unicode 6.0 it’s bigger and now people are starting to take notice. Supporting half of a character set is almost worse than not supporting it since it’s difficult to figure out what’s going to happen when you send data to the server.

Most of the bugs caused by this poor UTF-8 support don’t surface in English, and that’s why many developers remain blissfully unaware of the problem. Having said that, this is not something that’s only found when user’s write in Deseret or Egyptian Hieroglyphs (PDF), it also comes into play with Japanese names and some new Unicode characters like Emoji.

The MySQL defaults also have an effect on Unicode processing that affects the majority of European languages you’re likely the try and target. This unsafe default  has a different root cause but I want to cover it here so the two issues are not confused with each other. Here are how some of the most common issue surface:

• Attempting to update a record where a varchar column changed only by a single accent will return success but not save the change
  • This makes spelling corrections in record seem to “not save”.
• A row can be inserted successfully but when it is re-read the varchar column is empty or missing characters.
  • This is the case with the Ruby driver at least, probably others.
• Unique constraints on varchar columns will fail despite different text if the differences are all outside of the BMP.
• You can’t store the new Emoji characters, or they seem to disappear.

The supplementary character issue

The crux of the UTF-8 issue is rooted in the fact that UTF-8 is a variable-width encoding. The MySQL 5.1 implementation (like many others) was built on the assumption that a UTF-8 encoded character would use between 1 and 3 bytes. The beauty of UTF-8 is that it is compatible with ASCII (and by proxy the beginning of ISO-8859-1, which is also ASCII compatible) for the most common characters in English, using only 1 byte, but that the variable-width encoding scheme lets it also support the rest of Unicode. Here’s the rub: “the rest of Unicode” is an expanding set and when it passed a certain boundary UTF-8 needed 4 bytes to handle it. Let’s have an example:


1 byte  (0000-007F): "A"  ➔ 0x41
2 bytes (0080-07FF): "Ж" ➔ 0xD0 0x96
3 bytes (0800-FFFF): "龍" ➔ 0xE9 0xBE 0x8D
4 bytes (> FFFF)   : "𐐒" ➔ 0xF0 0x90 0x90 0x92

As you can see above, that last character takes 4 bytes in UTF-8 while MySQL only expects 1-3 bytes per character. Without getting into too many Unicode details it’s important for our discussion to know that the Unicode characters are logically divided into “planes“. The first plane is the Basic Multilingual Plane (BMP) and what you probably think of as “Unicode”. This is all of the characters between U+0000 and U+FFFF and covers most of the characters for the major languages of the world. When Unicode starting using the additional planes it started addressing characters beyond U+FFFF and UTF-8 expanded to handle that.

The MySQL 5.1 CHARSET “utf8” and the utf8_* collations were only able to handle 1-3 bytes so they had to do something. That something was mentioned depends on your client driver. In Ruby the insert succeeds but the data is discarded. In Java an exception is thrown, which at least alerts you to the problem. With the addition of Emoji in Unicode 6.0 this problem has a very high profile failure case when the text is Emoji-only. For Japanese mobile phone users this not an uncommon use case, and you can expect it to get more common in the US very soon.

The problem with accents

The problem I mentioned above with accent changes not taking effect is actually a configuration problem rather than a MySQL bug. This has to do with the common misunderstandings around MySQL collation and specifically the utf_general_ci/utf_uncode_ci collation sequences. This is probably best illustrated with an example:


mysql> select "bar" = "bär" COLLATE utf8_unicode_ci\G
*************************** 1. row ***************************
"bar" = "bär" COLLATE utf8_unicode_ci: 1
mysql> select "bar" = "bär" COLLATE utf8_general_ci\G
*************************** 1. row ***************************
"bar" = "bär" COLLATE utf8_general_ci: 1
mysql> select "bar" = "bär" COLLATE utf8_bin\G
*************************** 1. row ***************************
"bar" = "bär" COLLATE utf8_bin: 0


If your default collation is utf_general_ci or utf_uncode_ci then your database thinks “bar” and “bär” are the same word. If you have unique constraints on a column this is clearly problematic but this can also cause problems without that. This is the root cause of the “accent changes won’t save” problem. When updating a record it appears MySQL (or at least InnoDB) checks for equality before updating a record. Since and accent-only change is considered equal by the collation MySQL skips the write (which saves I/O overhead) and returns success since it thinks it optimized a write rather than failing.

English speaking developers very often assume that MySQL is mature and will “just work” in every language. The default character set for MySQL is latin1 (rather than utf8) and many developers have learned to dutifully change that to utf8 and utf8_general_ci when they install MySQL. This change fixes a large swath of issues but leaves behind these much more subtle bugs.

The MySQL 5.1 guidelines and work arounds

If you need to stay on MySQL 5.1 there are a few things worth keeping in mind.

• Using utf8_bin for collation will solve the accent issues, which is probably what you thought the other utf8_* collations where doing. The downside to this is that utf8_bin and ORDER BY will not be in language-specific order. You’ll have to make the choice for yourself depending on your needs but my advice would be that if you don’t know you should go with utf8_bin.
• If you want to fully support non-BMP characters your only recourse is to convert your char/varchar column in question to a binary/varbinary and make sure you handle the character encoding correctly on the way in and out. If you use UTF-8 be sure to allow 4 bytes per character (as discussed above). If you use UTF-16, make sure you allow 4-bytes to handle surrogate pairs. The downside to this is the subtle differences in how binary and varbinary columns are stored and you should fully understand that and the performance implications before making any changes.

The MySQL 5.5 fix

MySQL 5.5 was just released with new character sets for utf8mb4, utf16 and utf32. While utf16 and utf32 support is certainly welcomed I want to focus on utf8mb4 since my assumption is that you want ASCII compatibility. The newly added utf8mb4 character set is a superset of the utf8 character set that can store up to 4 bytes per character. With 4 bytes per character utf8mb4 should be able to store all 16 planes, including planes 4-13 which are currently empty and given the known writing systems in the world are not expected to be filled.

The addition of utf8mb4 makes me breath a little easier. You still have to know your collations to not reproduce the accent problem but I trust you can remember that small piece of Unicode/MySQL knowledge. If not, maybe you’ll google again in the future an find this handy command:

ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

The Twitter HQ Visit

In May of 2009 I had been working for Twitter for long enough that the then-common celebrity visits to HQ didn’t seem out of the ordinary. Having said that, I worked remotely so these visits always seemed like an exotic treat when they coincided with my trips to SF. It was only the second time only of these visits was scheduled during one of my SF trips and it was going to be MC Hammer. To be honest I wasn’t an MC Hammer fan even when he was huge and I thought it seemed like it was going to be a bit dull. I could not have been more wrong.

MC Hammer started by talking about his own use of Twitter. He was one of our earliest high-profile users and we all knew he was an avid user. He is an amazing speaker and kept a group who were probably not fans glued to the talk. Hearing people tell the stories about how they use Twitter is always interesting. Most people stop at how they use it but Hammer talked about how he saw it changing the very business he was in. To explain that, let me follow the line of thought he had at the time.

Hammer’s Tale (my recollection, anyhow)

If you’re making a music video you can spend quite a bit of money, and that is money spent by you and/or your label (if your label spends it you can bet they are going to want that back before you get paid). Now, you’ve spent this money and made a video which you then give to MTV. What does MTV do? They run your video surrounded by ads, for which they get paid. On cable networks who pay to carry the channel. The only way that money makes it back to the person who paid for and created the video is through exposure. Well, money that comes in that way passes through a great many hands.

• Albums? Promotion, packaging and distribution take a chunk of that. Check out how that all works.
• Tours? It turns out carting all of that stuff around is expensive. Venues are expensive. And TicketMaster™, just like MTV, are making money on both sides.

Hammer has often rocked the boat in which the music industry sits, like providing advice to the Napster founder, and his feelings about TicketMaster™ were clearly of the same bent. Hammer, mobile phone in hand said (and I paraphrase),

“There will come a time when I can go to a stadium owner and say I want to put on a concert – ok, maybe not me, I’m not going to be playing stadiums, but Bruce Springsteen. Anyway: Bruce will say he can sell all of the tickets in the whole place with one Tweet [hold up his phone]. We don’t need any TicketMaster™. No booking agent. Just you, me and my followers buying tickets. Now, what kind of a deal will you give me on the concessions?”

During the Q&A someone pointed out that the Bruce Springsteen story expected every artist to also be business savvy, which is unrealistic. Hammer’s response, which will stick with me, was that there will always be agents and managers, “There is always someone willing to do work like that for 20% of your take”. In May of 2009 I thought this sounded really far fetched. I believed in our product but I never thought there would be a time where we could do anything like this.

Enter the Future

Time passed, I worked hard, and then Conan O’Brien came along. Conan sent a tweet with a link to buy tickets to his upcoming live comedy tour. Within hours the tickets were sold out. This didn’t buy-pass traditional ticket agents, but there is no reason it couldn’t have. This was only half way to the future Hammer talked about but it was the half I was (and still am) working on so it speaks to me. I am certainly convinced that Hammer was on to something. So this has left me feeling that Twitter will do more in the future than I can foresee today. But my main lesson is this:

TicketMaster™, watch your back … Justin Bieber doesn’t need you.

I know that Twitter had to limit who they display content from for a myriad of reasons. I’m not privy to the reasons but I know from the public discussion around previous blog posts that Twitter is sensitive about injuring 3rd party developers. When it comes to mash-ups, which is essentially what this is, most developers I know would argue that any site with an open API is fair game. With that moral relativism out of the way I’ll get down to the business at hand.

Adding a new media type

Maybe your you and your friends use an unsupported photo posting site. Maybe it’s video. Maybe it’s something I haven’t yet thought of. Whatever it is, here is an example of adding a new media hosting site. This specific technique works with any site providing content from a URL based on the short-url component. For my example I’m using images from the image hosting site img.ly. I’ll start with a code listing and then break it down:

// ==UserScript==
// @name          Twitter Details Pane - Media Type support example
// @namespace     http://mzsanford.com/
// @description   Example script to display a spcific media type
// @include       http://twitter.com/*
// @include       https://twitter.com/*
// ==/UserScript==

(function(){

    window.addEventListener('load', function() {
      unsafeWindow.twttr.mediaType('twttr.media.types.Imgly')

      .url('http://img.ly')
      .matcher(/\b(?:https?\:\/\/)?img\.ly\/(\S+)/g)

      .icon('photo')

      .process(function(slug, cb) {
        slug = slug.replace(/\/$/, '');
        this.data["id"] = slug;
        cb();
      })

      .methods({
        html: function(cb) {
          var t = '<img src="http://img.ly/show/medium/{id}" />'
          cb(unsafeWindow.twttr.supplant(t, this.data));
        }
      });
    }, true);
})();

I’m going to skip the Grease Monkey boiler plate and get right to line 11. You can’t call into the #NewTwitter Javascript environment until it’s loaded (duh) so I setup a window load handler to run my code. Now the magic begins. Using some information @hoverbird posted on GitHub and Grease Monkey’s unsafeWindow I was able to execute my own Javascript code in the #NewTwitter environment. This code uses Twitter’s twttr.MediaType system to register a new URL pattern and how it is displayed.

The  url() and matcher() functions seem pretty straight forward with the additional note that parentheses in the matcher pattern can be accessed by the process function. The icon() function takes one of three values: ‘photo’ (the little picutre), ‘video’ (which looks like film) and ‘generic’ (a little generic page icon) and is displayed on the timeline. The process function is run for the timeline entries and where you can stash away infomation found in the URL match for later on. And lastly the html method (defined using this odd methods({}) syntax) is where the actual data is rendered in the Details Pane.

If you had a JSONP API to work with you would want to make your call in the html method since it called when the Detail Pane is rendered. Calling in the process method would create a bunch of load on the other API for Tweets that the user never clicks on. That’s not how friendly neighbors work.

Hopefully that was at least a little helpful for developing Grease Monkey scripts that work with #NewTwitter. I am also working on Details Pane interaction without a timeline icon but that will have to wait for a future post. If you have a suggested API to use for my next example (JSONP is easiest) drop a comment at the bottom.

Start up life is complicated so no one analogy really explains it all. Instead I’ve opted to break it into three phases, all alike in dignity. It’s not like there is a day where you switch from one phase to the next … and I’m not even sure I could spot these again if I were in the middle of them. This is a hindsight look at the last two years. The craziest and possibly best years I’ve known.

It All Starts with Prometheus

When Prometheus stole fire from the gods he didn’t sell it to his neighbor. He didn’t barter with it or tell the person next to him about “the exciting investment opportunities in state-of-the-art home heating and illumination“. No, he gave it to humanity. I joined a start-up when it was still very small and making no money at all. At the same time we were becoming quite popular and busily working to stay online. I’m not saying we brought something as critical as fire to man, but what I am saying is that we didn’t show up looking like P.T. Barnum and trying to bilk the suckers. We showed up with what we could muster and gave it up for people to use as they like. And boy did they use it … and in ways we never imagined. Looking back on it the Prometheus myth would be more fitting if he was burned badly while delivering fire to man, but that’s another story.

To me the point is that it starts with an idea, yearning to spread, and making that idea available for free is a good start. Selfishly: you are more free to experiment when money isn’t your biggest worry. Pragmatically: Building a product people love will result in more people spending time with your product and becoming the people to whom you market your money-making idea. Bring the fire for free now and when you see they use it to see in the dark start making oil lamps to sell (or stoves to cook).

On to the Industrial Revolution

It’s hard to think of the Industrial Revolution without thinking of profit and loss, especially after the “free fire” talk above but that’s what I need to ask you to do. Trust me, we’re still in the free period of the start up product but the Industrial Revolution has a good lesson. This phase of the arc is about the accumulation of “technical debt“.

During the Industrial Revolution the skies were filled with black smoke from coal fires. Those coal fires were powering some of the greatest inventions of the 18th and 19th centuries and altered the lives of the people living in those times, and the history of the world in some cases. The focus of all manufacturers was getting their product out to the people, often ignoring any consequences. Start ups are less reckless and unlike Industrial Revolution factories they don’t endanger workers’ lives or the environment, but they leave a wake of refuse all the same. That refuse is called “technical debt” and is sometimes the code left over by late-night, under-fire fixes but more often than not it is the design work done when the product was being use differently that it would end up being used in the end.

This filling of your office sky with coal smoke is a good thing, actually. While there will be a time when you look back on it and realize you were rash, I would argue you could never have made it to that vantage point without a little rash action.

Renewable Energy: The Promised Land

I’ll tie the second and third phases of this arc together, since they’re very related. In the real worlds there came a point where we started to talk about “peak oil” and “climate change” and ever since then we’ve looked back on the Industrial Revolution like a youthful indiscretion. Something we would do better if we had it to do again. We’ve more or less painted ourselves into a corner when it comes to energy and environmental issues and now we’re trying to fix it. Start ups are no different in my experience.

During the “Industrial Revolution” phase of the start up there was furious design and implementation work. We didn’t completely know where we were headed but we knew we wanted to get there and find out. Now that we’ve reached a point where we can see what the product is we can look back over the scorched earth behind us and wonder what we were thinking. Well, if we were busy wondering back then we wouldn’t be able to think about how to fix it, we would have failed, so I’m glad we did what we need to survive.

So we’re in search of the promised land of renewable energy, but unlike the real world we can cleanup all of the mess we’ve made. We want something that does not pollute our experience (or code base) but can sustain itself. This means fixing the things we’ve created in haste, turning a good product into a sustainable business, and continuing to do what made us a success: focusing on users. We have a group of great people evaluating a bevy of great options and I believe we’ll manage a balance we can be proud of. Maybe in the future I’ll add a fourth phase about utopia … or the after life. My bet is on utopia but life can be unpredictable.

I am an omnivore and I’m not ashamed. I’m also not squeamish about where my food comes from. I know that pork used to be a pig, beef a cow. I can’t say I love the feel of raw chicken in my hands. What I can say is that I like the taste of chicken more than I dislike dealing with it in the raw … and because of that I’m unashamed to be an omnivore.

Burgers Shaped Like Cows

Anybody who has talked about food with me has heard my rant about burgers shaped like cows. Well, that pretty much the gist of this post and it sums up my feelings. If you order a hamburger you need to be comfortable with the fact you’re eating what was formerly a cow (or, depending on where you order it, several different cows). If you ordered and someone told you the cow’s name was “Bessy”, would you order something else? If so, perhaps vegetarianism is for you. Vegetarian food is just as tasty, sustaining and filling as the omnivore diet.

As time has progressed we’ve become farther and farther removed from the source of our food. Where our parent or grandparents might have raised live stock, today the vast majority of us don’t have that sort of connection to our food source. There has been a local food movement brewing, mostly focused on fruits and vegetables. This movement has been about distance in the traditional land area sense … I want less distance in the mental sense. I want to think about the previous form of my food. Be it vegetable:

or animal:

But let’s be honest – nobody is squeamish about what a vegetable looked like in the field.