Info

Ben is Vice President of Mobile Engineering at Walmart.com, where he works closely with his long-time friend Dion Almaer.

Posts from the Technology Category

I admire Steve Jobs. I’ve been aware of him for most of my life, having grown up near “The Valley” and played with computers from my youngest years. However, I wasn’t particularly interested in Jobs until about when most of society became interested in him. In recent years, I harbored a secret desire to work for him at some point in my career. Obviously, that will remain an unfulfilled wish.

So I came to this book with quite a bit of existing knowledge of Jobs. As many have observed, if you’ve already read a few books on Apple or Jobs, you will heard much of the material in the book. That, coupled with the fact that Isaacson seems to have designed the chapters to stand alone and thus repeated himself a large number of times, led to the general feeling that the book was less about learning about Jobs and more about celebrating his life by reviewing what I and any Jobs fan has heard time and time again.

Still, the new insights (and to be fair, there were many) are worth the price of admission. I also enjoyed the strong editorial voice of Mr. Isaacson, casting Objective-Voice-of-God judgment throughout the book. Maybe it’s because I studied history in college, but I’m comfortable with biographers taking a point of view, especially when they’ve cut their teeth so thoroughly as this one has.

The book ends with an essay by Jobs himself, recounting the lessons of his life. This was a sweet, intimate way to close out the narrative–and I think stands as a testament to the respect Isaacson developed for Jobs.

Ultimately, I think we’re left at the end of the book with ambiguity. Yes, Steve built an amazing company, and certainly if a life is judged by the things one creates and nothing else, Steve’s legacy is tough to beat. But his callous regard for others–including his own family–is heart-breaking. If this is the cost of building attractive widgets, I would hope most would not pay the price. And so it is left to all of us to work out whether we can achieve career greatness at a level of Jobs whilst also investing in and achieving greatness in the areas of life that matter most.

I think that’s how nearly all of us view Steve Jobs: as a stereotype–a template–of career success that is so comically exaggerated that it is not for any of us to attempt to emulate, but rather, for all of us to study and from which to extrapolate small lessons for our own lives, adapted to the contexts of our own situations. His life seems like a fairy tale of the modern age in classic three-act play format, with achievements of such heights as to defy man to best them with imaginary ones, these accompanied by extreme character traits at home alongside the strongest characterizations of great fiction. It’s as if life decide to write the Great American Novel–and succeeded.

For all that, I have enormous affection for Steve as a person. Rest in peace, thanks for the memories, and thanks for the Macs.

(I bought both the audiobook and the hardcover edition of this book. I mostly listened to the book, but I did read some portions. The fact I listened to this may have contributed to my view of the book. I appreciated the introduction from Isaacson, but the narrator–an actor whose name escapes me–would not have been my choice. I also wish they had been able to use Steve’s own recorded voice for the last chapter, but perhaps that was not possible.)

There’s no better way to start our careers at Palm than by getting reamed by open-source pioneer and legend Jamie Zawinski, one of the driving forces behind the release of the Mozilla source code and someone we’ve talked about in recent months in another context.

While a blog post isn’t the right avenue to talk about all of the issues that Jamie brought up, we’re following-up with him directly and will bring it to a conclusion. We obviously goofed in how we communicated with Jamie, and Dion and I take some of the blame here as our staff had been waiting for us to come on-board to get to some of these items.

We do want to take this opportunity to clarify a few things and share with you a bit about where we at Palm are with our developer program.

Our App Catalog is very much in beta right now, precisely because we want to take time to get it right prior to a full consumer launch. We have been collecting a bunch of feedback from developers and it is helping us prioritize and structure the program. In the brief three months since the launch of the Palm Pre, we have learned a great deal from the community!

We’ve seen some folks assert that Jamie’s case indicates a general pattern at Palm that we don’t really care about developers and aren’t operating in a developer-friendly manner. While we undoubtedly have some work to do here, we hope that people do notice how we treat the “homebrew” community (e.g. PreCentral) and how our current SDK agreement calls out the inspectability and reusability of our own Palm applications. (By the way, several applications from the homebrew community have already made it into our App Catalog.)

While we have yet to finalize and announce our developer program, we hope these points demonstrate our general attitude of embracing developers and empowering them. We’re trying to strike the right balance between locking down our device and making it a free-for-all. Like all great things, this will be an iterative process and we are eager and open to your participation and input to make it better for everyone.

We are sorry that Jamie feels the way he does, but we’ll fix what’s broken and are going to deliver a fantastic opportunity to developers as they in turn help create a fantastic experience to users.

We have a lot more to say on this topic, so watch this space. Dion and I are part of the developer community; we’re listening to what y’all say and we’ll speak up and participate in discussions.

And hey, look for an announcement soon that goes into more details on our developer program.

Do you remember how much the Web used to suck?

Not so long ago, we Web developers would have to constantly educate product managers and other business stakeholders about the limitations of HTML; we would often contrast it with so-called “rich client” technologies.

Over the past few years, we’ve all watched with wonder as these boundaries have disappeared and the Ajax revolution brought us a never-ending supply of rich web applications.

And while Ajax started out as web developers leveraging little-used so-called “latent” browser technologies, browser makers haven’t been sitting idle. Modern browsers are acquiring new abilities at a pace not seen since the early years of the Web–most of which are largely unused by today’s web applications.

Dion and I started Ajaxian.com a few years back when we like many others felt that a revolution was about to take place, and we’ve been fortunate to be able to chronicle a bit of it as it happened. We feel like the Web is similarly positioned today, ready for another expansion as developers discover and leverage the next generation of browsers.

Bespin Logo

We’ve been fortunate to do a bit of that expansion ourselves at Mozilla with the Bespin project. What Dion and I started as an experiment to see if we could create a code editor on the Web as responsive as the desktop has turned into a full-fledged project team aiming to revolutionize the way the world writes code.

At the same time the Web has been expanding, we’ve all been blown away as desktop computers have somehow shrunk down to pocket size. Clearly a revolution in hardware is taking place and it doesn’t take a prophet to work out that the future of computing lies along this new trajectory.

However, my enthusiasm for this amazing new world is tempered by some unfortunate decisions made by some of the players in this space. It seems that some view this revolution as a chance to seize power in downright Orwellian ways by constraining what we as developers can say, dictating what kinds of apps we can create, controlling how we distribute our apps, and placing all kinds of limits on what can do to our computing devices.

palm

And so as my good friend and long-time collaborator Dion so eloquently explains over at his blog, he and I have taken an opportunity to work at Palm–at the very intersection of these two exciting technology arcs–and we have the opportunity to run Palm’s developer program and to do things quite a bit differently than some others in the industry have done.

Dion and I believe in the Web platform–an open platform that no single vendor controls–and we believe in empowering and enabling developers. We have been honored to work with so many who feel the same way at Mozilla, we will continue to advocate those values as members of the Mozilla community, and we can’t wait to put these ideals into practice in our work at Palm.

Chuck Finley

As prognosticated earlier, the next release of Bespin (named “Chuck Finley”) schlepped out the door this week. One half maintenance release and the other half feature release, Chuck Finley adds a “deploy” command and support for SVN commands while fixing various glitches with the once-shiny-now-lusterless “H. E. Pennypacker” release we put out in late August. The deploy command takes Bespin one step closer to the vision of developing entirely in the cloud and we’re absolutely thrilled to move in that direction.

Kevin Dangoor goes into Chuck Finley’s new features over on his blog, including a look at an enhancement to collaboration that shows you the current location of your collaborators’ cursors (a fancier version of this is coming soon).

Named Cursors

Next up is 0.4.5 “Bubba Ho-Tep”, a planned maintenance release for next week that may gain a few features as well.

Today we shipped the next release of Bespin: the 0.4.2 “H. E. Pennypacker” release. As discussed in my recent “Bespin Roadmap” blog post, H. E. Pennypacker is primarily a bug fix release focused specifically on issues related to the new collaboration engine. The key fixes in this release include:

  • Work towards ensuring that we never lose your data (bugs 511289, 511217, and 511291)
  • You can now export projects from Bespin (bug 511828)
  • Various other stability enhancements (bugs 511125, 512044, 511539, 509496, among others)

We’re now focused on shipping Bespin 0.4.3 “Chuck Finley” which will deliver deployment and SVN/HG commands (right now we have our own VCS commands that map into SVN and HG; we are working on implementing the actual SVN/HG commands you’re used to).

Command-line Only?

In the bespin mailing list, I saw a message or two lamenting that we are too focused on the command-line at the expense of the UI. Take heart, gentle fans. We have plans to implement GUI equivalents for nearly every major command we can think of; it’ll take us a while to get there.

We hope you enjoy H. E. Pennypacker, and I look forward to telling you more about Chuck Finley in a week and a half or so.

Bespin Roadmap

With the recent release of Bespin 0.4 “Stratospheric Stratus” last week and 0.4.1 “Fletch F. Fletch”* on Monday, it’s a good time to post an update on the Bespin roadmap.

0.4.2 “H. E. Pennypacker” – August 26th

Minor release that aims to whack any major bugs reported in the collaboration engine; if we have resources left over, we’ll add support for a subset of native SVN and HG commands to Bespin’s command-line.

0.4.3 “Chuck Finley” – September 7th

Includes a new feature: a “deployment” command. We plan to support SCP (and therefore SFTP and FTP) to start and build up from there.

0.4.4 “Bubba Ho-Tep” – September 14th

Minor release to fix bugs and introduce small enhancements and feature polish.

0.4.5 “Ash Williams” – September 21st

Adds “colorization” to the collaboration engine: the ability to track who has changed what in a file and visualize that in a configurable fashion, probably with foreground or background text color. While this may sound like a minor feature, it actually represents a significant enhancement to our existing functionality.

Also includes “cursor tracking” to show you where collaborators are currently hanging out in the document.

0.5 “Brisco County Jr.” – September 28th

Follows-up with additional social development features, such as:

  • “Live file history”: the ability to scrub back and forth along a timeline that corresponds to the history of the file to see what it looked like at any point since its inception. This is vital for collaboration because undo/redo doesn’t undo changes to the document made by your collaborations; using this feature, you can essentially do this by going back in time to revert a change made by someone else.
  • “What are my friends doing right now?”
  • “What is everyone else in this project doing right now?”

Feedback

Follow along with us on the Bespin mailing list as we update the community if (when?) we deviate from these plans, and please do give us feedback here on this blog or on the mailing list.

* We neglected to update the UI’s codename label in 0.4.1 to Fletch F. Fletch from 0.4′s Stratospheric Stratus.

Roadmap image adapted from Jemimus’ IMG_2699

Michael Mahemoff recently wondered about whether Bespin will ever have more than one back-end. That’s a good question! We’ve waffled a bit ourselves on the back-end bit. The initial back-end was Java, but we migrated to Python. Michael pointed out that we’d need to solidify and publish the API for alternate back-ends to be viable.

At our launch, we documented the server API, but we’ve changed it a touch here and there since. We need to keep the Wiki up-to-date. But in addition to our back-end, there is MobWrite, which powers the collaboration engine. MobWrite’s protocol is documented, but we’ve altered it a touch and published our alterations as well.

If you’ve an interest in implementing a back-end server, please do let us know and we’ll put more effort into updating the published documentation.

Bespin Collaboration Screenshot

We just launched collaboration in Bespin today; it’s come a long way since the initial prototype we had working earlier this year. That progress is due primarily to the hard work of our own Joe Walker and Google’s Neil Fraser, the latter of which created Mobwrite, an editor-neutral diff-and-paste collaboration engine that Joe integrated into Bespin underneath the beginnings of a set of social collaboration features that Joe’s designed and implemented over the past few months. As Joe mentioned in his blog today, this is but the first step in a journey towards a very social coding experience on-line with Bespin.

With today’s (beta) launch of collaboration, you can now use bespin.mozilla.com to check out an SVN or HG project from any public repository, hack on the code with a whole bunch of friends in the same session, and commit the code back to the repository. We’ve tested around twenty sessions collaborating on 10,000 line files and things seem stable, fast, and fun–but before you get too carried away, collaboration is to be considered beta, and you may lose some data while using it until we have a chance to examine bugs filed by the community and fix ‘em.

We definitely need to implement some sugar to track cursor positions of collaborators, colorize text according to author, and so forth. Watch for some of this soon.

Here’s to more social, collaborative coding experiences in the browser!

Open Web Tools Directory

Several weeks ago, I blogged about the Open Web Tools Directory, another Mozilla Labs experiment we launched to explore making some sense of the huge and diverse web tools ecosystem. Thanks for taking a look at the site, for telling us about your favorite tools and your own projects, and for all the feedback!

We’ve just pushed out another minor update to the directory, including the more updates to the tools database and some tweaks and bug fixes to the user interface. (We’ve still got more tools to add and will do another update next week.)

So what’s next for this project?

At Mozilla, we try hard to do things out in the open and engage the community in the development process very early. We’re a mission-driven organization and that mission is to maximize the Internet’s benefit to the public, so we like to get the public involved as much as we can in telling us what we should be doing.

Can you help us decide what the next steps should be?

The Open Web Platform

To get the conversation going, let me share our vision for this project. I’ll start with the big picture, and work back towards the Tools Directory.

At some point over the last few years, the web browser evolved from being a way to render hypertext documents and has become an application run-time platform. This new emerging web-based platform has been called the “Open Web Platform” with increasing frequency; I like the name and have used it for the past few years and will use it throughout this post to describe the technologies available to web applications (provided to them by the browser and occasionally plug-ins).

Liberation

I’m extremely enthusiastic about the Open Web Platform and its potential to liberate: to liberate applications from the shackles of operating systems (e.g., you must own [Operating System X] to run this application), to liberate developers from the tyranny of learning multiple SDKs (e.g., you must learn n entirely different technology stacks to get your app onto n different platforms), and to free users to customize their applications easily and to share those customizations freely (e.g., the Greasemonkey / “user script” vision). As the web platform gains in capabilities, it frees us from traditional unnecessary barriers that sap our productivity and block our progress. I’d like to expound on each of these “liberations”, but it’s a bit orthogonal to today’s theme, so I’ll move on for now and circle back another day.

(Don’t get me wrong: I fully support empowering application developers to chose the platform that allows them to best express their vision and meet the needs of their customers, and I want people to be able to profit from selling software. But I’m working as hard as I can with thousands of other people to make the Open Web Platform be the platform of choice for as many developers as I can. Because when that choice makes sense, we all win. Big time.)

Fragmentation

One of the reasons folks call the web platform “open” is that it’s beyond that control of any one person, entity, vendor, government, etc. As a consequence, knowledge about the platform is fragmented. There’s not one resource you can leverage quite like the developer networks of other platforms. There have been some attempts by the market to meet the obvious demand created by this void, but it’s pretty difficult to make money selling developer tools or developer-related services. A few companies succeed at this, mostly at a small scale, but much larger numbers of companies fail.

We’d like to do something about this.

Open Web Developer Center?

We think the web could really use something like an “Open Web Developer Center”, a site where you can go to find integrated documentation for the various browsers and specifications that compromise the platform and learn more about its capabilities, where you can find the tools that can increase your productivity and augment your capabilities, and where you can socialize with other developers.

Perhaps most important of all, we want a place where that helps more people get engaged in influencing the future of the platform in direct, tangible, and meaningful ways–to help realize the vision of the Open Web Platform as the People’s Platform, of the people and for the people.

The Tools Directory

So the tools directory is a first step towards realizing this vision. We’ve got a lot of work to do, but we think the next immediate steps are:

  • Provide great ways to navigate and filter the data. Seeing a centralized mass of tools is useful, but it’s much better to sift through the noise to find just what you want. Crowd-sourced tagging (i.e., folksonomies) are one step in this direction; we’d also like to add features that show you the tools that your friends use, the most popular and highest rated tools, and tools that industry luminaries use. What are useful filters / discovery techniques should we employ?
  • Crowd-source the data. What’s the right mix of data stewardship? Submit revisions and have them reviewed by “trusted editors”? Allow each tool to have an “owner” that modifies the data? Wikipedia-style free-for-all?
  • Efficient and accessible interface. The current UI is certainly… graphical but has a bunch of usability and accessibility problems. We think the right move here is to focus on a more traditional data-centric UI for the main view, but provide one or more graphical “explorers” for a different perspectives onto the data set and a bit of fun and whimsy. We’re making the data open to anyone to consume (we have a JSON-producing MySQL-backed web service we’ll make available soon, once we nail down the API a bit more) so we’d love to see folks create their own explorer interfaces on top of the data in addition to the one we’ll provide.

What Do You Think?

Are these the right immediate next steps for the tools directory? What do you think of the overall vision of the Open Web Developer Center?

I really wish all of us interested in this sort of thing could get together and brainstorm about all this. In fact, we should do just that. Look for another post on this topic shortly.

In the meantime, please do send in feedback, either via our mailing list or comments right here. Thanks!

Open Web Tools Directory

Just published a couple of blog posts earlier this week announcing the release of another project we’ve been kicking around here in Mozilla’s Developer Tools lab: a directory of the universe of tools to help web developers. The Ajaxian post goes into some detail on the technology behind it. Like Bespin, the directory uses HTML 5′s canvas element extensively. Unlike Bespin, there’s no compelling technological reason for this decision; we’re exploring different ways to visualize the data and we wanted to achieve a dynamic floating universe of tools.

We’ll be spending a great deal of energy in building up the directory and turning it into a vibrant, living resource for web developers, and we’d sure love to get your feedback on what you think we should to do it. Because the data is all available via a simple JSON format, we’re also keen to see other folks create their own custom front-ends for it. Who knows, perhaps a few other alternative interfaces will land in the coming weeks or months (we’re releasing a fully accessible version for the vision-impaired soon, btw).

I also want to give a special thanks to Mike “Morgamic” Morgan and Laura Thomson, two members of our incredible web development team at Mozilla, for tons of help getting this project going.

It’s been nothing short of a blast to work on this project. I’ve spent a good deal of time developing software on desktop platforms and here the web platform delivered the best of both worlds: easy-to-use graphic rendering API coupled with trivial network access built-in. And the performance! While a GPU-powered version would blow away the performance of the current version of the directory, I’m fairly certain that the web’s software rendering performance is comparable with the major desktop platforms software equivalents (e.g., Java2D, GDI, etc)–and I can’t wait to do a canvas 3D version to compare GPU-backed performance.

Go Web.

Follow

Get every new post delivered to your Inbox.