Wesabe, as of this month, has gone out of business. Reportedly, they lost their venture backing and after years, still had no revenue. They planned to sell subscriptions, but later changed to trying to sell directly to banks. I’m not sure why they thought they could sell web apps to large, conservative businesses, but hey. Wesabe was also expensive to run. Between running secure servers and paying for the service that connects to all those banks, they had to fold.

On the other hand, Mint was by most accounts a success. They made some revenue by upselling financial services to users, and grew extremely fast. They only supported US banks, but that seemed to help more than it hurt. They built a significant threat to the establishment (Intuit’s Quicken) and then were acquired by Intuit for 170 million.

So where are we now? Four years later, if you want personal finance tools, you go to Intuit. Jason Fried lamented this, but now that their #1 competitor has died, it’s even more dramatic.

Yet with hindsight, I’m still happy having retired Budgetable. Both competitors had to get big venture capital investment to do what they did, and neither got to profitability. They had to give their services away for free since that’s what consumers expect, and now neither of them exist as separate entities. That’s just not my game.

Now that I am no longer held back by big-company legal restrictions, I am going to be much more involved with the platform. Very soon I will post some new example code. Some others are working on new documentation and build tools to ease that pain as well. Starting this fall, my new company will also start to offer online and in person training and mentoring courses to your team get up to speed quickly. We can also finally get started on that book.

This is exactly what SproutCore needed. It’s great that Apple is using it and putting resources into it, but being restricted from promoting your open source product is painful. There’ll still be teams at Apple using it, and now there’ll be a group that’s willing and able to spread it.

Working there has been the experience of a lifetime. The people, the products, and the coffee are all wonderful. I’m going to miss laughing at rumour sites, hiding prototypes, and not needing to explain where I work.

At Steve Jobs’ commencent address at Stanford, he said:

You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle.

“Don’t settle” sounds obvious, but it took me a long time to realize how working at a company like Apple could possibly be settling. It turns out that while I like programming, it’s not my true love. The work I truly love is ensuring that a product is great. Sometimes that’s programming, sometimes it’s design, sometimes it’s talking to customers. It seems then that I belong at a small company where a role like that exists.

A great thing about small companies is that you can build your own. And so, tomorrow is my first day at Steam Clock Software. We’re going to take inspiration from great companies like Panic and 37signals, but with our own twist. We founded Steam Clock to make awesome software products and to be the best place to work in Vancouver. Getting there should be a fun ride.

Onward!

All links shared on Twitter.com or third-party apps will be wrapped with a t.co URL. A really long link such as http://www.amazon.com/Delivering-Happiness-Profits-Passion-Purpose/dp/0446563048 might be wrapped as http://t.co/DRo0trj for display on SMS, but it could be displayed to web or application users as amazon.com/Delivering- or as the whole URL or page title.

My guess is that Twitter clients will just use the domain as the link text, but either way it’s a big win for usability and readability. Any suggestions on what domains I should punish on Unladen Follow?

Luckily, it’s possible to implement high-performance touch scrolling with fixed elements using the hardware-accelerated animations available on the iPhone and iPad. Even more luckily, people are working on this problem so you don’t have to, and have released their work under MIT-style licenses.

iScroll

Website: Announcement blog post.
Demo: iPhone only.
Minified Size: 7.6KB.

The most commonly used scrolling library for Mobile Safari has been Matteo Spinelli’s iScroll library. iScroll is now at version 3, and supports most of what you’d want from an iPhone scrolling library. The look and feel are pretty close, but are not an exact reproduction of native scrolling. For example, version 3 removed the effect where scrollbars shrink when you scroll past the end of the region. Further, support for non-Apple devices is intermittent, which causes concerns for people using PhoneGap to make cross-platform apps. For these reasons, a lot of developers I’ve talked to aren’t satisfied with it.

In terms of perception, iScroll suffers most from a weak web presence. It’s hard to find on Google because “iScroll” is actually the name of an unrelated eBook app. The library is distributed through blog entries rather than a dedicated website, so make sure you’re looking at the latest iScroll-related entry. The creator has now switched gears to a more general purpose JavaScript library called GhostTouch, which is still at an early stage. As a result, a community hasn’t really formed around this library.

TouchScroll

Website: Announcement blog post and GitHub page.
Demo: iPhone and iPad.
Minified Size: 17.4KB.

This week David Aurelio released TouchScroll, a competing library. It’s more code than iScroll, but seeks to be more featureful and high-fidelity. It automatically updates to compensate for its content changing, and is also scrollable on desktop browsers simply by setting overflow:scroll. It’s written with PhoneGap developers in mind, including first-class Android support. It’s currently buggier than iScroll, but given its current buzz, its fork-friendly GitHub page, and the PhoneGap focus I can see TouchScroll becoming the dominant library in the medium term.

Frameworks

In the meantime, various frameworks have been implementing their own touch scrolling. Earlier this month at JSConf, the SproutCore guys announced and demoed their own touch scrolling support. While they don’t have native-style scrollbars yet, their performance is very good. For large apps, the performance benefits of their incremental rendering technology is a big win: only elements that are visible are rendered in the DOM. Other frameworks are working on solutions, for example the jqTouch plugin for jQuery has a plugin of its own based on iScroll. In the long term I see most frameworks including touch scrolling as part of the package.

Viewports

Mobile Safari presents desktop-sized sites on small screens by rendering to a virtual browser screen that is 980px¹ wide, and letting you pan and zoom that page. Viewport tags let you tell Mobile Safari that your site displays properly narrower than 980px, and set other preferences for scaling your page.

Craig Hockenberry famously determined the ideal viewport tag for content sites in the iPhone era. That technique is no longer sufficient for the iPad because it can blow up your content larger than 1:1, blurring your images.

TN2262

The Apple tech note “Preparing Your Web Content for iPad” has a good suggestion: avoid hard-coding a width for your viewport. On the iPad, a viewport width smaller than 1024 can cause your content to be blown up and blurred. Their suggestion is

<meta name="viewport" content="width=device-width" />

This is an improvement, but your content will still be blown up if your device is in landscape mode. This is because device-width is the width of the physical device (320px or 768px), not the width of the screen in the current orientation. As a consequence, you can get content rendered at 768px and blown up to 1024px.

Avoiding Blowup

To make sure your content is not blown up, set the maximum-scale to 1.0:

<meta name="viewport" content="width=device-width,
                               maximum-scale=1.0" />

Sites with the above tag will get a 1:1 viewport for all devices and orientations. This is impractical if your site does not render properly at 320px wide. In this case, hardcode a width and also set a maximum scale so your site isn’t blown up on the iPad:

<meta name="viewport" content="width=720,
                               maximum-scale=1.0" />

This viewport will give you 1:1 rendering on the iPad, and a 720px viewport on the iPhone and iPod touch. Any desktop site that looks good narrower than 980px should set a viewport like this, especially any site that fits in 768px, since you can opt portrait-oriented iPad users into 1:1 unblurred versions of your content.

The initial-scale Hack

In Craig’s aforelinked viewport post from 2007, he suggested adding an initial-scale and minimum-scale of around 0.5 to your viewport for long pages. Back then, this simply limited how zoomed out the page would be on initial load. That’s unnecessary now, since Mobile Safari instead sets the initial zoom to whatever is required to fit the width of the screen.

Setting a small initial-scale nowadays has an interesting effect: if your chosen initial-scale is less than would be required to fit the width of the screen, your viewport is expanded. For example, if you set a viewport of 640px wide, and an initial-scale of 0.5, it will display normally on the iPhone (scaled 0.5x to fit 640px into 320px.) On the iPad, however, it will expand your viewport to 1280px, which was probably not your intention.

Overall, the initial-scale hack doesn’t seem to have utility anymore, and has odd side effects, so I imagine sites that have adopted the initial-scale hack, such as Daring Fireball, will drop it as iPad usage increases.

1. Of course, when the iPad is in landscape orientation of 1024px wide, it will use 1024px.

I think we can all remember this experience from other games we have enjoyed, and we were keen to make sure we delivered the same frantic experience for ModNation Racers.

I say it gives Mario Kart a run for its money.

I never used to understand why people would have side projects each with their own domains and branding instead of tying everything into one monolithic site. Now I realize it’s much better for the same reason you modularize anything else: it lets you upgrade, rewrite, shut down, reassign, or otherwise evolve with minimal mess. Plus, it’s fun.

Having one less project on my mind, not to mention no longer having 20,000 lines of unmaintained PHP running on my server, will help me sleep at night. More importantly, it frees up that mental bandwidth for the next big thing. Onward!

We were originally trying to use the BinaryMemtable interface, but we actually found it to be too fast — it would saturate the backplane of our network. We’ve switched back to using the Thrift interface for bulk loading (and we still have to throttle it).

Awesome.

There are many JavaScript linting programs out there. As a counterpart to his book The Good Parts, Douglas Crockford maintains a tool called JSLint. Matthias Miller was inspired by this, and maintains a similar but less picky tool he confusingly calls JavaScript Lint. If you want to go even further, there is the Google Closure Compiler.

Take this WTFJS caused by implied semicolons:

function laugh()
{
  return
  {
    haha: "ha!"
  };
}
laugh();
// returns undefined

The lint programs will warn you (in different ways) that your return gets an implicit semicolon, and the object with “haha” in it never gets executed.

Or this one:

parseInt('06'); // 6
parseInt('08'); // 0

Lint will tell you that you can’t use parseInt safely without specifying that you want base-10, or wrapping it in something that assumes base-10.

They’ll also catch things like this:

{
  "ping": "pong",
  "foo": "bar",
} // IE says parse error on the last line of your file.
// (It doesn't understand trailing commas, yay!)

and this:

if (foo == bar) {
{
  // You doubled a bracket.
  // Now need to round-trip to your browser to find out.
}

You can save yourself from these wtfs and parse errors. All you need to do is have your text editor run a lint program instantly when you save your JavaScript. The excellent JavaScript Tools Textmate bundle does this for you using JavaScript Lint¹, and is easy to set up. If Textmate isn’t your favourite or you prefer the more aggressive JSLint, you can set up your own save macro on any editor worth its salt.

1. Even though JavaScript Tools says it’s using JSLint, it’s actually using the more lax JavaScript Lint.