and the difference between Apps and Websites

For my first six months of working at Mozilla on our Apps ecosystem, I would tell everyone that HTML5 developers should have an easy time getting their stuff into our Marketplace, because “it’s just the web”. And there are lots of advantages to being an experienced web developer when it comes to making a successful HTML5 App.

And then I tried it myself.

Here’s LucidChart, a fully-featured diagramming tool, running in a web browser. It’s got a menu bar, it lets you open, edit, save, and close documents, it’s got drag-and-drop. Awesome! So why does this look so weird?

LucidChart App in a Browser

Once you start looking at it, doesn’t all that browser UI look weird up there? What would I expect the back button to do? Likely, it’ll take me away from LucidChart right in the middle of trying to delete some text. And why shouldn’t LucidChart’s menubar be up at the top of the screen where my OS really puts menubars? hint: these are all things we can fix by establishing a standards-based Web Runtime for Apps.

Conversely, look at my own website,, as an App: as an App as an App

It looks rather App-like — the App name is in the title bar, an edit menu, and no browser back button. I was very proud of it at first. But then I started to ask — do my other Apps have hyperlinked content? Shouldn’t those tab-like things at the top remain visible as I scroll through the content? No, and yes. I’ve got some work to do!

Posted in HTML5 | Leave a comment

getting lost in Cambridge

While on spring break years ago, in a time before GPS and smartphones, my friend and I were trying to get to a movie theater while visiting Cambridge, MA. We stopped a stranger on the street and asked for directions. He thought for a moment, pointed down the street and said, “walk two blocks that direction and ask again.” We did, and found ourselves two blocks closer to our destination.

Now think about an engineering leader asking a product manager for directions, or vice versa. When we take on those roles, we aren’t satisfied with “walk two blocks that way and ask again.” Most traditional engineering cultures expect us to provide (and to follow) directions chock full of “go four blocks south, take your first right, then your first left…” with such detail and clarity that the listener will follow our comprehensive directions and get to their movie on time.

I  think that when we tend to hold ourselves and each other to unrealistic standards of direction giving, we let the best become the enemy of the good. What strikes me about the stranger we met in Cambridge is his choice to share useful but incomplete information rather than shrugging sheepishly and claiming ignorance, afraid of giving bad advice or of being unable to articulate how to get there.

Posted in Process | Leave a comment

Martin Fowler on doing painful things more often

In this post entitled “FrequencyReducesDifficulty”, Martin Fowler explains why doing painful things more often reduces the pain. Think pushups, cleaning the catbox, refactoring ugly code, and integrating multiple subsystems.

Posted in Other Blogs | Leave a comment

Legacy code is like unwanted inventory?

In this May 2011 post, Michael Feathers asks us to consider the cost of carrying around all that legacy code, making an analogy with how lean manufacturing folks become more efficient by reducing the amount of stuff they have lying around.

Posted in Other Blogs | Leave a comment

Michael Feather’s next book

Ever since I first discovered Michael Feather’s “Working Effectively with Legacy Code” I’ve been a huge fan. I find it both inspiring and a great book to teach from. While catching up on his blog this morning, I read that instead of a second edition of that book, he’s planning a sequel called Brutal Refactoring. I can’t wait!

Posted in Other Blogs | Leave a comment


I heard about this from @ralekseenkov. TDGotchi is an Eclipse plug-in that creates a virtual pet, like the old Tamagotchi, except that this one doesn’t thrive on simulated feedings. It thrives on watching you fix failing unit tests and do refactoring. Conversely, if you let your tests continue to fail, TDGotchi gets sicker and sicker. Don’t let this happen!

Posted in Other Blogs | Tagged | Leave a comment

RubyOnAles wrap-up

RubyOnAles2011 was a blast! In addition to getting in some serious hacking with JQuery, Rails, and the eBird API, I got to meet some cool ruby people, hang out in the cozy environs of the Old St. Francis School, and hang out with my friend and mentor @ggoodale. Here are a few of the highlights:

Jim Weirich and Matt Yoho, “Securing your Rails App”

I had some familiarity with most of this material, but I really appreciated their concise summary and clear demonstrations of the various security problems facing web applications today. I especially appreciated their demonstration of a cross-site scripting (XSS) attack. Happily, Rails offers some pretty simple fixes for most of these attacks (some of which I will be implementing shortly for

Avdi Grimm on exception handling

Avdi started by exploring the details of Ruby’s exception handling mechanisms, best practices, and mechanisms for extensibility and customization.  He then segued into a broader discussion of the dangers of using exceptions to address non-exceptional behavior. His design advice that will stick with is, “Detect errors at a low level; Handle them at a high level”. By detecting errors at a low level, we have the most knowledge of the root cause of the problem, and can bundle the most information into the exception object. By handling them at a high level, we have the most context for knowing whether we can continue executing and how to explain to the user.

Rein Henrichs, Recent intrusion at PHPFog

Rein works at PHPFog which recently got hacked in a major way. I admire how open he and his company have been in disclosing how the intrusion was done, and he seemed genuinely passionate that we all learn from his mistakes. Their blog post is definitely worth reading.

Kyle Neath, Design Hacks for the Pragmatic-minded

Kyle describes himself as an engineer who has ended up doing a lot of design work. He urged us to refrain from gratuitous use of weird fonts, to add more padding around text, and to use color with restraint — all of which suits my own design aesthetics just fine. He recommend an exercise in which you describe all the objects on your page in a hierarchical text outline, and from there to consider visual containment can match the hierarchical outline. He concluded with some stern words about making presentation materials. I especially liked “Do your slides look SLEEK? Then add more contrast — this is not web design!” Having tried more than once to make sleek slides, this really hit home.

Jesse Proudman, “Demystifying Auto Scaling”

Jesse described how his firm, Blue Box Group, is building their scheme to automatically scale application servers as demand rises and falls for their clients. The implementation seems to combine their existing internal API for instantiating app servers with a Rails application monitoring service called New Relic. He showed some very straightforward code examples that, as advertised, really demystified what they’re doing.

Other notes:

Heroku is a Rails hosting service that integrates so thoroughly with the standard Rails makefile that you can deploy your app to their cloud in two simple command-lines. Very slick.

Test-driven development and Pair programming are very common among this crowd, but they’re both still topics worthy of conversation.

Gemstone, a former Smalltalk vendor, has reappeared as the basis for a new Ruby implementation called MagLev.

Anyway, those are my big takeaways, along with a bunch of other tidbits crammed into my Notational Velocity notes. Now for some more hacking before the flight to SJC.

from Portland airport, -Bill

Posted in Trip Reports | Leave a comment

Mark Pilgrim on “Why Specs Matter”

In this timeless essay about how developers typically approach implementing a standard or specification, Mark Pilgrim mercilessly divides us developers into Morons and Assholes. I imagine you don’t want to chose one or the other, but after reading what he means, you’ll realize how very right he is. An absolutely brilliant piece of writing.

Posted in Other Blogs | 1 Comment

Michael Feathers on “Data-Rich Development”

In his recent post “Data-Rich Development”, Michael Feathers talks about supplementing the recent emphasis on incremental design through TDD with a longer-term perspective gained through analyzing changes to the codebase over time. As a budding source code miner myself, I was heartened to learn that he’s thinking similar thoughts.

Posted in Other Blogs | Tagged , | Leave a comment

RubyOnAles 2011, here I come!

ROA logoNext up for me is a quick jaunt up to Bend, Oregon for Ruby On Ales 2011. I’m a Rails enthusiast but haven’t really connected with the Rails community until now. Really looking forward to it!

Posted in Trip Reports | Leave a comment