Mon, 01 Apr 2013 08:00:00 GMTWhen 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 partyThe 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 petsOnce 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 cagesTwenty-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 reasonTomatoes are vines, and when vines spill out of their[...]
Tue, 25 Oct 2011 08:00:00 GMT
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, MLB.tv, and CNN, for example).
If I were an iOS developer, I'd start investing in AirPlay right now.
Thu, 06 Oct 2011 08:00:00 GMT
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
http://facebook.com/joehewitt 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 facebook.com 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.
Mon, 03 Oct 2011 08:00:00 GMTI 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 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 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 DropboxI 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 CMSDropbox 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'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[...]
Mon, 26 Sep 2011 08:00:00 GMT
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.
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?
Thu, 22 Sep 2011 08:00:00 GMT
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.
Mon, 20 Jun 2011 08:00:00 GMT
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.
Fri, 06 May 2011 08:00:00 GMT
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.
Tue, 15 Mar 2011 08:00:00 GMT
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.