Click here to show or hide the menubar.
  • When people asked me what I was going to grow in my new garden, my response was, "Anything but tomatoes."

    Blame it on my Italian relatives for excessive use of marinara, or on American restaurants for the pale, mealy wedges atop salads, but I just don't like tomatoes. I was excited about growing peaches, blueberries, broccoli, and just about anything else.

    I'm fortunate to live near Love Apple Farms in Santa Cruz, CA. Their main gig is growing produce for a Michelin-starred restaurant, but they also teach an array of gardening classes. After having a great time in their spring vegetable class, I returned excitedly to the class roster to find another. Given the name of the farm -- "love apple" is an antiquated French name for tomatoes -- you can probably guess which plant most of the classes were about. I signed up for one nonetheless, convinced that only a selfish gardener would refuse to grow things they don't enjoy eating.

    Seed party

    The farm's owner, Cynthia Sandberg, opened class with a refrain I'd heard before: Homegrown heirloom tomatoes are infinitely superior to the supermarket variety. I wanted to believe her, but I wasn't optimistic.

    And then she began passing around hundreds of jars of seeds for us to choose from -- Black Zebra! Green Giant! Amazon Chocolate! -- and my collector's instinct kicked in as I imagined the menagerie of fruit that would burst from Cynthia's catalog into my garden.

    Selecting which seeds to plant was kind of stressful. The jars swapped hands so fast, I barely had time to pinch out seeds, much less discern orange striped this from sweet red that. I ended up shooting for a mix of colors and shapes and hoping for the best.

    My tomato pets

    Once I got home, I learned that tomatoes are more like pets than houseplants. The fun of watching them sprout soon gave way to despair as many seedlings wilted and died when I forgot to check them even for a day or two.

    Despite having all the recommended equipment -- a heating mat, grow lights, a fan, timers, and temperature sensors -- they mostly just needed personal attention (and water). As they grew, the seedlings had to be carried into the sun during the day and brought back in at night. Once they outgrew their trays, I had to transplant them to larger pots, and soon after, still larger 1-gallon pots.

    From seed trays to 4-inch pots to 1-gallon pots.

    I hadn't considered what I was going to do with 100 seedlings until I was at the nursery buying 100 plastic pots. My garden is big, but not that big. Neglect thinned the numbers quite a bit, but I still wound up with more than 60 plants in 1-gallon pots. A dozen or so found their way to friends' gardens, and somehow I found room for 25 plants in the ground.

    Fish heads, aspirin, rusty cages

    Twenty-five plants may not seem like a lot until you try to lift a coil of 25 steel tomato cages -- each 7 feet tall -- from the bed of a pickup. Cynthia insisted on this height and even predicted the vines might grow taller and spill over (indeed, they would). Before I could set up the cages, I needed to get the tomatoes in the ground. Of course, my needy pets insisted I first round up a witch's brew of soil amendments.

    Only thing missing was frog's legs.

    According to Cynthia's prescription, each young plant should be buried with the following: one fish head, a handful of egg shells, bone meal, worm castings, tomato fertilizer, mycorrhizal fungi, and two aspirin. (Yes, aspirin. Apparently it combats disease.)

    After three months of babying the seedlings, I wasn't about to slack off now. It took a few phone calls to track down the fish heads, but Whole Foods came through for me with beautiful 1-pound salmon heads. Into the ground they went, up went the cages, down went the irrigation tubes, and then the wait began.

    Nothing seemed to happen for weeks at a time, and I kind of forgot about them for the summer. When the fruit began to ripen in August, there was suddenly a lot happenening, and not all of it good. I learned a few things the hard way.

    Lesson #1 Cages are there for a reason

    Tomatoes are vines, and when vines spill out of their cages, they need to be pushed back in. Otherwise, tomatoes will soon be growing in hard-to-reach places, or worse, rotting on the ground. Young and limber vines are easily snaked back into the cage, but mature woody vines will only snap if you try this.

    Lesson #2 Treat blossom-end rot

    About half the plants had fruit with "blossom-end rot," a condition caused by poor calcium absorption. The egg shells were supposed to help with this, but I guess I didn't use enough. There's tons of literature on the web on blossom-end rot prevention -- this year I'll be on top of it.

    Lesson #3 Fear the rain

    Coastal California summers are bone-dry, which is great for tomatoes. But in late August, we had an unexpected downpour. My vines were covered in almost-ripe fruit that I was waiting to get super-ripe, but in the days after the rain many of them began to split and rot. Lesson learned: When it rains, immediately harvest everything that is remotely edible.

    Lesson #4 Know your diseases

    In early September, many of the plants began to look parched, with droopy and desiccated leaves. I thought they just needed more water, but I was mistaken. The dead leaves were from "late blight," a dreaded tomato disease. Guess what "late blight" loves? Water! Oops.

    Before I realized my error and stopped the irrigation, a couple plants were killed to the ground. Others stopped fruiting, and what fruit was left didn't ripen. Fortunately, only about 1/3 of the plants were affected. This year I'll definitely back off on water later in the season.

    Lesson #5 Be ready for an avalanche

    Growing the plants was hard work, I thought, but that was nothing compared to the work of harvest. My four cherry tomato plants started ripening in early August, and I expected the rest to steadily follow for the next couple of months, giving me plenty of time to deal with them. Instead, my other 21 non-cherry plants ripened all at once in early September, and I had about three weeks to deal with the bulk of them.

    A typical day in September.

    September was a tomato-chopping, crushing, canning, freezing, and dehydrating frenzy. I ate tomatoes with nearly every meal and delivered heaping baskets to friends and neighbors. With my freezer and pantry overflowing, the tomatoes still kept coming. I was greeted with the smell of mold each morning as I walked past the growing backlog in my kitchen. The first time I had to compost a moldy tomato was sad, but by mid-September, every lost tomato was kind of a relief. The lesson here is that 25 plants is too many for me. I'll probably have eight this year.

    But how do they taste?

    You might be wondering at this point if I changed my mind about the merits of eating "love apples." I'll say this much: A tomato, picked when warm from the sun, so ripe it's on the verge of going bad, and eaten while standing in the garden, is better than ice cream. On the other hand, some of the varieties I grew, despite being fancy heirlooms, tasted no better than a winter greenhouse tomato from Safeway.

    I conducted a taste test with my parents with each of the 25 varieties. One clear winner emerged, and that is Orange Russian 117, which is not only the most beautiful tomato I've ever seen, but tastes more like a peach than a tomato. Other favorites included Coyote and Sungold cherries; the hefty Casey's Pure Yellow and German Red Strawberry; the striped Tigerella; and George O'Brien for making sauce. Some, like Black Plum, tasted just OK when raw, but were spectacular when dehydrated.

    Until next year

    As it turns out, I was right all along. Tomatoes aren't that great -- unless you grow the right varieties, eat them at the right time, and process them the right way. As I ripped out the last of the tomatoes in October, it was clear I was ending a cycle that would begin again every year for as long as I'm fit to garden.

  • I've been reading a lot of speculation recently about what a future Apple TV might look like. Not nearly enough of these analyses have talked about AirPlay. It's clear to me that AirPlay would be so important to the Apple TV, you might as well call it AirPlay TV.

    There's so much compelling video content and games available on the App Store, it's not really that big of a deal if you can't watch cable TV, DVDs, or play Xbox on the Apple TV. This trend is only accelerating. When Steve Jobs said "I finally cracked it", I'd bet he was thinking of how AirPlay and the App Store had eliminated the need to support old set-top boxes.

    The new AirPlay Mirroring feature in iOS 5 doesn't get talked about much, but it's the key to making this work. Watch this demo of AirPlay Mirroring if you need to be convinced. AirPlay Mirroring with the current Apple TV is underwhelming because of the hassle of making it work. You need to find the TV remote, switch to the Apple TV input, find the Apple TV remote, wake up the Apple TV, then go back to your iOS device and turn on AirPlay. Ugh! Apple has to make AirPlay work effortlessly, and to do that, they need more than a set-top box. They need to control the whole TV.

    The one big technical hurdle for Apple to overcome is the unreliable WiFi connection between your iOS device and the TV. There are a number of ways they could overcome this. They could put a WiFi router or extender in the TV to ensure a fast connection. They might try another high-bandwidth wireless networking standard that doesn't rely on flaky home WiFi routers. They might come up with a new split architecture in which apps run partially on the TV and partially on the iOS device. I don't know exactly how they'll solve this, but I am sure they will solve it.

    Once the networking is reliable, the user experience can get really good. There would be no on/off switch on the TV. You'd just sit down on the couch, pick up your iPad (or iPhone or iPod touch), start using an app, and the TV would turn itself on and start displaying the AirPlay stream. No fumbling with remotes. No numeric keypads and up/down/left/right buttons. Just touch, swipe, and speak to find what you want to watch. You'll never plug a set-top box into this thing, and you'll never want to.

    It's possible Apple could choose to just license AirPlay to TV manufacturers, but something tells me they won't be able to resist making a showcase TV that screams "Apple!" to everyone who walks into your living room. Once Apple announces this, iOS developers will be scrambling to support AirPlay. I'm sure Apple will give enough advance notice to ensure that a ton of amazing content is available on launch day. It will take a while for Apple to get all of the big TV/movie studios, sports leagues, and news networks on board, but they will eventually. Most them already have dipped their toe into the App Store waters (see HBO Go,, and CNN, for example).

    If I were an iOS developer, I'd start investing in AirPlay right now.

  • I've been thinking about ways to save the Web from being buried in the avalanche of native apps we've been seeing. As I recently wrote, hyperlinks are the defining characteristic of the Web, but most native platforms break the hypertext model. iOS and Android support URLs for navigating between apps, but the URLs they support are not portable to other platforms. For example, you can link to my Facebook profile on iOS using fb://profile/joehewitt, but this URL is useless on Android or in a desktop browser.

    Many of the URLs that iOS and Android apps support have an equivalent URL for the Web. For instance, fb://profile/joehewitt translates to on the Web. It would be ideal if the OS could automatically perform this translation for any third-party app, just as iOS redirects Google Maps and YouTube URLs to their native app equivalents.

    We don't have to wait and hope that Apple or Google solve this problem for us. Here's a solution we could build now: a Web service that translates between Web URLs and native URLs using a community-maintained database. Domain owners could claim the mappings for their domain using an authentication process. There could be accompanying libraries that developers could link into their native apps which help to find the best way to display a URL. If you happen to have the Facebook app installed, and you tap a URL, the service would redirect you to the native app. If it's not installed, it would open the URL in the default Web browser.

    This service would make URLs more future friendly and really underscore their "universal" nature. It would allow hypertext to transition beautifully into this new world in which browsers are not the only way to consume Web content.

  • While building Scrollability I've learned a few tricks about how to make animations that start fast and run fast on iOS WebKit. The challenge of getting the scrolling physics right was nothing compared to the chore of making the animations as smooth and stutter-free as they are in native iOS apps. It took several iterations to get results that are acceptable.

    First problem: cubic bezier curves

    My motivation in starting Scrollability was that I was disappointed with iScroll, the most popular touch scrolling library out there. iScroll uses CSS transitions with the cubic-bezier timing function, and the results don't feel anything close to iOS native scrolling. Cubic bezier curves are simply unable to match the deceleration curve that Apple uses, so I knew right off the bat that CSS transitions could not be part of my solution.

    Play with the iScroll demo and tell me if it doesn't immediately feel wrong to you, especially the way it bounces back at the edges.

    Solution: animate with JavaScript, not CSS

    My first iteration used JavaScript and setInterval to animate the -webkit-transform CSS property using translate3d. This achieved hardware acceleration, and it looked amazingly good on an iPad, but not nearly as good on an iPhone 4. While the physics were improved over iScroll, the animation was not nearly as smooth as the results iScroll got using CSS transitions.

    Second problem: pixel doubling

    Pixel doubling means that even though the iPhone 4 screen is 640 pixels wide, WebKit reports it as 320 pixels wide. The smallest increment you can animate something with JavaScript is two physical pixels, since WebKit always rounds coordinates up to the nearest integer before doubling them. That's right, writing translate3d(0, 0.5, 0) is the same as writing translate3d(0, 1, 0), and both will be multiplied to translate3d(0, 2, 0) in real coordinates. While you might be able to use the meta viewport tag to avoid pixel doubling, that causes a host of other headaches that I didn't want to burden Scrollability users with.

    Play with this early Scrollability demo on an iPhone 4 (with iOS 4) and you will see how jerky the animations feels.

    Updatetest by @amadeus shows, floating point values are not rounded as I thought. I'll have to do more research into why my first Scrollability animation was so poor on retina displays.

    Solution: CSS keyframe animations

    CSS keyframe animations, like CSS transitions, have the ability to animate in physical pixel increments on retina displays, but give you much more control over timing than cubic-bezier functions. Rather than simulating the physics progressively at each setInterval callback, I would simulate them all up front when the user released their finger, and use the resulting positions and times to create a fine-grained CSS keyframe animation like this:

    @-webkit-keyframes scrollability {
        0% {
            -webkit-transform: translate3d(0, 10px, 0);
        1% {
            -webkit-transform: translate3d(0, 11px, 0);
        ... a bunch more keyframes ...
        99% {
            -webkit-transform: translate3d(0, 290px, 0);
        100% {
            -webkit-transform: translate3d(0, 292px, 0);

    Turns out you can generate this CSS, insert it into a stylesheet, and start it playing faster than the wink of an eye. The results were just as good as I had hoped they would be.

    Third problem: image animations stutter

    While keyframe animations made my vertical scrolling demo fly, they caused a severe slowdown in my photo gallery demo. I knew the slowdown wasn't JavaScript-related, since my table demo was so fast. It had to be deep in the guts of WebKit. After much experimentation I noticed that galleries with only three photos did not stutter. Turns out the problem occurred only when the width of the animated element was greater than 1024 pixels.

    Third solution: avoid repaints

    WebKit does all of its painting on the CPU and then uploads the results to the GPU in the form of an OpenGL texture. This process is slow, but once you have that texture, it can be drawn to the screen incredibly fast. This is the key to native scrolling speed.

    Turns out that on iPhones, WebKit creates textures that are no larger than 1024 by 1024, and if your element is larger than that, it has to create multiple textures. It really doesn't want to do that, due to limited GPU memory, so it creates these textures only when it needs to, and then throws them away immediately after. In our case, the textures are created at the start of a CSS animation and then discarded when it ends. Therefore, the stutter in my photo gallery is caused by those large images being painted on the CPU and pushed to new textures on the GPU at the start of the animation.

    However, if your scrollable element only requires one texture, there is no stuttering, since that texture is probably already on the GPU when the animation begins. The solution was as simple as setting a max-width of 1024px on my photo gallery demo. Ok, it isn't that simple, since I have to do some other tricks to continually reposition the gallery images within that 1024px container, but the results are really excellent.

    Fourth problem: iOS 4 WebKit sucks

    Since this is the Web, where good things are always too good to be true, the 1024px texture trick works great on iOS 5, but has no benefit whatsoever on iOS 4.

    Play with the photo gallery demo on iOS 5, but grab a box of tissues to dry your tears before you try it again on iOS 4. Kudos to Apple for optimizing iOS 5, but what do we do in the mean time?

    Solution: wait for iOS 4 to die

    No, seriously. If you want to use Scrollability, you need to have a fallback for legacy browsers anyway, and so I'm going to recommend that you limit Scrollability to iOS 5 WebKit. It's the future, right?

  • I flipped the switch on my new blog last night. If you've been here before, you might not notice anything different. The design hasn't changed, but behind the scenes everything is new. I've written a CMS for the blog in Node.js and Express. It's hosted on EC2, S3, and Cloudfront. All the content is written in Markdown and pushed to my server using Dropbox. All the code is pulled from repositories on Github and NPM. I use responsive design to adapt nicely to all screen sizes, and use feature testing with has.js and hascan to adapt nicely to all browsers.

    Like many nerd-minded bloggers, I prefer writing in Markdown in my programming text editor instead of writing in a browser. Many such systems like Jekyll are growing in popularity, but these usually require you to use Git to push your Markdown files to the server. Call me lazy, but I don't want to have to go down to the command-line. I just want to save the file to publish it. This is where Dropbox comes in.

    All of my blog posts are now in Markdown files, and those files are synchronized to my Linux EC2 servers with Dropbox. My previous blog used Markdown also, but I had to FTP the files to my former Dreamhost server. I used ExpanDrive, which made the FTP process relatively painless, but FTP is still flaky, and ExpanDrive doesn't deal well with flaky connections. With Dropbox, the synchronization is effortless. A second or two after I save the Markdown file, the post is up on the blog, and I never have to think about it.

    Setting up Dropbox

    I run Dropbox on my EC2 server using the default Linux AMI, but this should work on most Linux distros.

    Start by installing the Dropbox Linux command line client. At the end of the install script, it will ask you to link your Dropbox account by copying and pasting a URL into your browser. Do not do this yet. If you do, it will link your personal Dropbox account to the server, downloading the hundreds of megabytes of files you may have on Dropbox, and exposing potentially sensitive files to any intrepid hacker who breaks into your server.

    You only want to synchronize the files needed by your CMS, so you need to create a new Dropbox account that is dedicated to this purpose. Of course, the Dropbox client only works with one account at a time, and your personal computer is going to be logged into your personal account. Luckily, Dropbox folder sharing solves this problem nicely. Once you have your new account, go to your personal account and share the folder containing your CMS files with the new account. Then you can link the new account to your server. Be sure you are logged into the new account in your browser, and then load that URL the installer gave you. Done.

    About that CMS

    Dropbox alone does not a blog make. My new CMS, called Nerve, processes those magically synchronized files and spits out a website. It's Apache-licensed and hosted on Github, but I'm not recommending that anyone other than me use it at this time.

    Nerve takes advantage of Node.js's built-in file watching abilities to monitor changes made by Dropbox and then regenerate pages on the fly. It asks you for a path to your Markdown file, but this can include asterisk wildcards so you can use as many files as the pattern matches. My entire blog is two Markdown files. One contains all posts from 2002 to 2010 and the other contains all posts from this year. The files look something like this:

    This is a new post
    Blah blah blah.
    This is another post [9/30/2011]
    Blah blah blah.

    Nerve uses Markdown's level-one header to demarcate the posts. It then looks for a bracketed timestamp in the header to distinguish posts that are public from ones that are still drafts. A password-protected drafts page allows me to preview drafts before publishing. Once they are done, I add the timestamp, save the file, and it's published.

    A previous version of Nerve required creating a separate file for each post and giving it a name that contained the timestamp. I tested this system out on Laura's blog and found that the chore of creating new files was just enough friction to discourage her from starting new posts. One day I was talking to my friend, Dave Winer, and he told me that his entire blog is contained in a single OPML outline file. This was a big aha-moment for me, and I rewrote Nerve so that all posts could be within the same file. This was a big hit with Laura, and I've found her posting volume has gone up significantly ever since.


    The Dropbox Linux client works pretty well, but on a couple occasions I've found it has stopped syncing for no apparent reason. It's not the end of the world. The web server keeps running, but new posts won't get published until I SSH into my EC2 instance and restart the Dropbox daemon.

  • My post the other day generated a lot of responses. I suspect that most of the positive responses were from people who, like me, have a depth of experience on other client platforms, and are able to judge the Web in comparison. It's hard not to be disappointed by HTML if you've developed for iOS, Windows, or other mature platforms as I have.

    Then there are the people who reacted negatively to my post. A common theme throughout these responses is complacency. The Web is good enough and it's been getting much better lately, so we should be grateful, they say. The shortcomings are not so important as to risk that a centralization of ownership would lead to more IE6-style stagnation. The Web will catch up eventually.

    This argument is futile, because nothing I yearned for in my post is possible. HTML and company are going to continue going through the same standards bodies, there will continue to be an array of subtly different implementations, and the Web "operating system" will continue to evolve at a far slower pace than centrally-controlled operating systems. That train left the station a long time ago.

    Thinking about this in public helps me work out why I care so much about the Web. I'm beginning to see that some parts of the Web we take for granted are not what actually defines it. The Web is not HTML, CSS, and JavaScript. It's not DOM, SVG, WebGL, PNG, or Flash. The Web is really just HTTP over TCP/IP. What gets transported over HTTP does not define the Web.

    There is, however, one other characteristic that does define the Web, and that is the humble hyperlink. Links are a feature of HTML, but they are not limited to HTML. Links are the connections that give the Web its name, and links are the biggest thing missing from native platforms. Some have pointed out to me that iOS and Android allow you to construct URLs that let users navigate between apps, but what they are navigating is not a network, but the tiny subset of the App Store they have installed on their devices. That is a far less powerful idea than the Web, where a single click is guaranteed (network willing) to take you to a self-contained application that begins running immediately.

    So, my definition of the Web then is resources loaded over the Internet using HTTP and then displayed in a hyperlink-capable client. This definition is liberating. It helps me see a future beyond HTML which is still the Web. I can say now that when I exclaim my love for the Web, it's the freedom of driving the open Internet in a browser that I love, not the rendering technology. Hyperlink traversal matters. The Internet being global and decentralized matters. HTML does not matter.

    The biggest thing HTML has going for it is that every computer in the world can render it. Not a small benefit, to be sure, but not a reason to limit ourselves to HTML forever. People can and will download new browsers with new rendering engines, given the proper motivation. It just so happens that we're currently in a major transition period, from desktops to mobile touch screen devices, where there is an incentive for people to try new browsers. I wonder, will someone capitalize on that?

  • Many people seem to assume that the Web will one day become the one and only client computing platform on Earth, therefore it must not be controlled by anyone. This is a dangerous assumption. The HTML, CSS, and JavaScript triumvirate are just another platform, like Windows and Android and iOS, except that unlike those platforms, they do not have an owner to take responsibility for them.

    The Web has no one who can ensure that the platform acquires cutting edge capabilities in a timely manner (camera access, anyone?). The Web has no one who can ensure that the platform makes real developers happy and productive. The Web has no one to ensure that it is competitive with other platforms, and so increasingly we are seeing developers investing their time in other platforms that serve their needs better.

    The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven't they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.

    My prediction is that, unless the leadership vacuum is filled, the Web is going to retreat back to its origins as a network of hyperlinked documents. The Web will be just another app that you use when you want to find some information, like Wikipedia, but it will no longer be your primary window. The Web will no longer be the place for social networks, games, forums, photo sharing, music players, video players, word processors, calendaring, or anything interactive. Newspapers and blogs will be replaced by Facebook and Twitter and you will access them only through native apps. HTTP will live on as the data backbone used by native applications, but it will no longer serve those applications through HTML. Freedom of information may be restricted to whatever our information overlords see fit to feature on their App Market Stores.

    Let's face facts: the Web will never be the dominant platform. There will forever be other important platforms competing for users' time. To thrive, HTML and company need what those other platforms have: a single source repository and a good owner to drive it. A standards body is not suited to perform this role. Browser vendors are innovating in some areas, but they are stalled by the standards process in so many areas that is impossible to create a platform with a coherent, unified vision the way Apple has with Cocoa or the way Python has with Guido.

    I wish I could offer solutions, but I have none. I know where we need to go, but not how to get there. It would help if all the rendering engines but one were to die, but even that would not be enough. Even if WebKit was the only game in town, it would still be crucial for it to have competent, sympathetic, benevolent leaders. The closest thing we have to that today is Chromium, but they have no foothold in mobile and are likely years away from having one. And so I end on a sad note.

  • Today my girlfriend and I are launching a new photo blog that we've made together called Up on a Hill. The photos and text are mostly by Laura, and the code and design are by me. The blog combines large photos with overlapping blog posts, and uses Scrollability to scroll vertically through the posts and horizontally through each post's photo gallery.

    The design of Up on a Hill has been optimized for desktops, phones, and iPads, and Scrollability is leveraged in different ways on each. On phones and desktops, native scrolling is still used to scroll vertically, but Scrollability handles flipping horizontally through photo galleries. On iPads, however, Scrollability handles both vertical and horizontal scrolling. I think the site feels fantastic to use on all three kinds of device, but is especially a treat on the iPad.

    Some might see Scrollability as a tool for replicating native-looking iOS user interfaces on the web, but I think that Up on a Hill shows that Scrollability's greatest value is in leveraging inertial scrolling for even non-standard interfaces. Inertial scrolling is a fundamental part of touch screen devices, regardless of their visual design, and should be used more often on the web.

    Most mobile websites still rely on clicking (actually, tapping) buttons to navigate through sections that should really be using inertial scrolling, like photo galleries. That's unfortunate, because flicking through pages is a far more comfortable than tapping on small "next" and "previous" buttons. My hope is that Scrollability will encourage mobile web developers to be more like native app developers, and use inertial scrolling when it makes sense, rather than falling back on desktop conventions.

  • Today was my last day at Facebook. Normally when I leave a job I go out cursing the management and wishing I had left much sooner. In the case of Facebook, I sent heartfelt emails to all of my managers thanking them for the privilege of letting me work there, and I genuinely meant it. Facebook was the longest I ever worked at one company, and the best employer I've ever had.

    Working at Facebook was like having my own startup, but with a paycheck instead of ramen. Management gave me the freedom to work on my own ideas, and just like with real startups, some of my projects never made it out of the lab, while others shipped and were huge successes. The brilliance of Facebook management is encouraging everyone to take initiative, take risks, and wear as many hats as you can. I wish more tech companies operated like this.

    It's been more than five years since I made Firebug, and though I stopped working on it long ago, I've continued thinking about it nearly every day since. It was probably the most gratifying project I've ever worked on. Knowing that I was helping developers solve hard problems, work more efficiently, and create awesome things gave me an energy and happiness that was unmatched.

    My mind is still full of ideas for tools of all kinds: tools for writers, designers, programmers, whatever. Wherever people are using computers to turn their ideas into reality, I want to help. I've spent the last four years of my career working on a very different kind of software. At Facebook, I've gotten to build communications tools that reach hundreds of millions of people. I've had the honor of seeing people, even my own parents, using my apps while walking down the street, in restaurants, on trains, in planes and everywhere I go. Still, I haven't been able to stop thinking about Firebug.

    Technologies have a way of growing faster than the ecosystem of tools needed to support them. Over the last four years, we've seen the rise of mobile apps, the cloud, and now HTML5. Most developers building on these new platforms are using the previous generations of tools along with a mix of ad-hoc scripts and web apps to get things done. It works, but it is far from ideal. In fact, it reminds me a lot of the Ajax climate back in 2006 when I decided to make Firebug.

    And so, I'm independent now, and I'm going to pour myself into understanding the needs of modern developers and designers, and creating software to fill those needs. There are so many opportunities that I can't even predict what I will end up building, but I am pretty sure I know where I am going to start. I can't wait.

  • I often play videos of conference talks while I work, though I have no intention of actually listening to them. The background noise helps me focus, like those recordings of crashing waves, chirping birds or a rambling brook. I remember the first time I made the mistake of trying to work over a video of Gary Vaynerchuk speaking at a conference. If you've ever seen Gary speak, you'll already know why I didn't write a line of coding during the 30-minutes of his talk.

    Gary is a special guy with an unusual trait for a businessman: He genuinely cares about people. It comes through when he's on stage motivating developers, taking a sniffy-sniff on Wine Library TV, err, The Daily Grape, and in the books he's written. I've just finished the latest of those books, The Thank You Economy, and I'm feeling the same inspiration I feel after watching one of Gary's high-adrenaline YouTube videos.

    On the surface, The Thank You Economy is a book about how businesses can use "social media" to have meaningful relationships with their customers, but to me it was just a guide to being a genuinely good person.

    If you're going to apply Gary's advice, you can't just think about how to treat your customers better. You should learn to treat all the people in your life with respect, warmth, and patience - and hire people into your business who exhibit the same kind of character.

    I am your typical introverted software developer. I show my love for the people who use my software by trying to craft the most enjoyable user experience possible. Dealing with my users directly is something I'm not as naturally good at, but that doesn't mean I don't enjoy it. The most fun period in the lifecycle of a software product is when it first hits the wire and you start getting user feedback, both positive and negative. The problem is, software scales like no other product; the work of a single engineer can easily reach millions of people, and it's just not feasible for that engineer to directly interact with every one of those customers. That's where a book like The Thank You Economy becomes useful, because it covers a lot of different ways to engage with your customers as efficiently as possible. I'd definitely recommend it to anyone running a small software business.

Stats & Atts.

It's even worse than it appears.