Embarrassment Driven Development

Googling “embarrassment driven development” (EDD) does not return as many hits as it should. I think it’s a very powerful development technique. I first heard the expression from the Plone guys at PyCon 2006, and Google did turn up this match:

[ArchipelagoSprint] Time to get cracking on Plone 3.0!

Wrt. timelines, I was hoping that we could try to have a “Tech preview” release before the Plone Conference 2006 in Seattle (October 25-27) – I’m going to be on-stage there talking about the exciting new features of Plone 3.0 – and I’d like to not be booed off stage. Yes, this is embarrassment-driven development – as usual. 😉

That’s Alexander Limi illustrating the prime motivator for EDD.

The idea behind EDD is simple: if you have to demo something in front of an audience, and that something sucks, you will move hell or high water to make sure you don’t look like an idiot.

Every product has rough edges and warts, but no one wants a demo to be all warty and to have to say “yeah, I know you shouldn’t have to click to the left of the button, but we just haven’t gotten to that yet”. EDD ensures that, at least for the parts you have to get up and show, the rough edges will be smoothed in time for the show.

I’m going to be practicing EDD leading up to JSConf. I want to be able to show some useful, non-trivial bits of ServerJS work by then.

Bespin: code in the cloud

Despite working for an open source company, I have been pretty quiet here about what I’ve been doing in the Mozilla Labs web developer tools group. No more. We’ve gone public!

Mozilla Labs » Blog Archive » Introducing Bespin

Bespin proposes an open extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards.

I started working on Bespin as soon as I joined Mozilla, hitting the ground running with a new Python server. Ben and Dion had already done a lot of work and experimentation on Bespin prior to joining Mozilla in December, so I must confess that I am still fairly ignorant about the Canvas-based magic that they’re doing in the UI. But, Bespin has an architecture that lends itself well to selective ignorance: the server provides a RESTful API, and the client is responsible for all of the presentation. For their part, Ben and Dion have been able to be blissfully ignorant about the inner workings of the Python server.

Of course, I’m not a JavaScript noob and have done some work in the client, but my focus has been the server. Now that we’re out in the open, you can definitely expect that we’ll be talking more about how things work and how you can bend Bespin to your will. Bespin is honest to goodness open source (MPL-licensed), so it becomes an open and collaborative effort starting right away.

The initial reaction has been fantastic. There are tons of people hanging out in #bespin on irc.mozilla.org, and the mailing list has grown to a couple hundred members already. Thanks to everyone for jumping in with your thoughts and patches!

Here’s some of the coverage:

Dion’s post at Ajaxian:

From Dion’s personal blog:

Foolish chaps and companies have come to me in the past thinking that open source will be a silver bullet for “getting other people to do our work.” Those that have been involved in open source know that it isn’t the case. It is often more work. But, it is worth it.

From Ars Technica:

The project is still at an early stage of development and there is clearly a lot of work to be done before it will be able to deliver the same practical value as existing desktop editors. Despite the limitations, it shows an enormous amount of promise and has the potential to eventually deliver a user experience that rivals even the best text editors.

From Five Questions with Dion Almaer:

Now the browsers are moving fast again and building a first class platform for us to develop, the Open Web Platform. Instead of getting bogged down thinking about what IE 6 gives you, take some time to think about what you could build with the latest technology. I realise that you have to be pragmatic and get things working with your audience, but browsers are changing, and so are expectations.

From What Mozilla’s Bespin Bespeaks (ComputerworldUK):

You can see that Bespin is ticking all the Mozilla boxes, but what’s also striking is that this is a Web-based project: Mozilla is entering the cloud. It’s a further shift to viewing the Web as a platform for doing, well, just about anything. Clearly, against that background, open standards are even more important. And not only for the code: another issue that Mozilla will need to start addressing publicly is that of open data. As more stuff moves into the cloud, it become imperative to establish minimum standards for access to the data that is held there. I look forward to hearing Mozilla’s views on the subject.

While I certainly don’t speak for Mozilla, I would be extremely surprised if there’s anyone at Mozilla that believes that users should have anything less than full access and ability to take their data with them. There can be technical issues involved in providing the data, but the data should be available in some reasonable form. Bespin, for its part, makes it easy to export a project in a tarball or zipfile.

I was surprised to see Bespin covered even on Lifehacker:

Primarily, Bespin is a text editor—the kind you’d use for editing code or managing text-based todos. Using Bespin, developers could collaborate on projects through a unified interface (that still supports plugins!) no matter where they are—so long as they’ve got a browser.

cnet has the story, too:

For example, what about integration with open-source software repositories? If it’s flexible enough, Bespin could essentially act as a source code viewer that repositories such as SourceForge or Google Code could employ.

A nice writeup on the ReadWriteWeb as well:

It’s clear that a great deal of thought and attention went into this early version – and it’s a safe bet that it will only get more impressive as time goes on.

RWW last month surprised me with their coverage of me joining Mozilla.

I’m having a great time at Mozilla so far, and it’s great to be out in the open working with so many people now on Bespin and ServerJS.

Making web development suck less

We make shitty software… with bugs!
old Living Videotext slogan, as reported by Dave Winer

I love that quote. On the surface, it sounds disparaging about the software you have today, but it’s actually more of a statement of hopes for the future. The status quo, in fact every status quo, is less than ideal. It’s great to be proud of your products and where you are, but it’s even more important to keep in mind how much more there is to do.

Early in my career, I worked at the ANS Network Operations Center. ANS ran the original NSFNet and provided internet and dial-up connectivity for America Online, as well as a number of large companies and research labs. We had the internal slogan “we suck less”, and it was the same idea as the “we make shitty software” quote. At ANS, we did suck less than our competitors. But, every time a customer’s connection was down we knew we had work to do to make things even better.

I’ve been doing web-based software development for a long time, and the tools for creating web-based software have improved tremendously. Server side frameworks like Rails, TurboGears and Django have made writing typical server side code far easier. Client side toolkits like Dojo, jQuery and Prototype/Scriptaculous have made creating better client experiences even easier. And tools like Firebug have made it much easier to debug an application and tweak its appearance on the fly.

But, developing compelling web-based applications still sucks. Its still more work than it should be in the ideal case. I’m sure that the people working on all of those tools, and all of the competing tools, all have ideas on how to make things better and will all be pushing the state of the art forward and removing a bit of suckyness with each release.

I’m delighted to say that starting today I am working with Ben Galbraith and Dion Almaer at Mozilla Labs on web development tools. I’ve been a reader of Ben and Dion’s Ajaxian site for years and I know how much thought they’ve put in to making webdev better, so I’m really excited to be joining their group. And Mozilla looks like a fantastic organization to be a part of.

It’s still a very new group, but you can bet that every day I’m going to be thinking about how I can help make web development easier, faster and better.

Reinhardt: a client-side web framework

At PyCon in March, I spoke about how applications can be browser-driven. For the past few months, I’ve been involved with a browser-driven app. Remarkably, some of the same kinds of problems crop up when making a browser-driven app as when you’re making a traditional server-driven webapp. So, today I introduced something called Reinhardt, a client-side web framework. Using Dojo’s Django Template Engine implementation (dojox.dtl), Dojo’s data model (dojo.data) and Reinhardt’s new Django-inspired URL dispatcher you get something that approximates a server-side web framework all on the client side.

The Tech of SitePen Support

I’ve just posted an article with some details on how SitePen’s Support system is built. We use Python on the server and Dojo-driven JavaScript on the browser to create a responsive system. The model we use is similar to what I described in my PyCon 2008 talk where the client is driving the interaction rather than the server.

SitePen’s Support service is built using a variety of interesting techniques and technologies. Read on to see how we built a system that treats the web browser as a real client tier and bridges the worlds of JavaScript, Python and PHP seamlessly to provide a great experience for our customers.

[From SitePen Blog » The Tech of SitePen Support]

What I’ve been up to: The Dojo Toolbox

Today, we unveiled a project that I’ve been quite busy with the past few weeks: The Dojo Toolbox. Check out my First Look article to learn more about it or watch my 5 minute screencast:

The short story is that it’s an Adobe AIR-based app, built with Dojo itself, that gives you a zippy offline API documentation viewer and a graphical user interface for running Dojo builds.

This was my first interaction with the development side of AIR and my overall impression is quite good. The APIs are nicely done, and only having to target WebKit is quite a blessing.

Of course, I’m better known for my Python projects than JavaScript-related projects. In this case, we are using Paver to manage our builds and we also have Python code that processes the API documentation and generates the search index.

My colleagues and I had a great time putting this together. Thanks to SitePen and Adobe for sponsoring this project!

“Why Do I need To Sign This?” : Alex Russell on contributor agreements

Anyone who runs a significant open source project should read this, especially if you don’t currently require your contributors to send in any kind of agreement:


So why have it? Why create the barrier to entry for newcomers who just want to pitch in? I have great sympathy for the impatient potential contributor huffing “why do I need to sign this, anyway?”, so this blog post is an effort to boil it down.
[From “Why Do I need To Sign This?”]

I’ve spoken with Alex a couple of times about open source intellectual property, and he’s definitely given this a lot of thought. For a project the size of Dojo, involving many very large contributors, having something like Dojo’s CLA seems critical for keeping the IP clean.

With TurboGears, from the beginning, I’ve required people to send in a simple contributor agreement and this sums up why: “One of the best aspects of the CLA process is that it gets people who are contributing to think about what it means to contribute.”. Significant open source projects that people depend on need to have contributors that are serious about maintaining the project’s quality and the project’s IP. Making people aware of this responsibility from the get-go is a big positive.

I’m posting this in hopes that more of my friends in open source software will keep these things in mind as their projects grow and the outside code contributions increase.

Programming language warts: Newspeak

There’s a new language that is soon to be open sourced called Newspeak. Gilad Bracha and team are creating a new language to address what they see as the future of programming (online/offline operation, lots of service oriented design, more concurrency). They’re angling for a Smalltalk-like environment and, indeed, their current implementation is in Squeak.

Ignoring that there’s at least one other language called Newspeak, it seems like Gilad Bracha’s Newspeak is built on reasonable premises. You can read a bit about what Newspeak is like. Newspeak is definitely not done yet, but things like this give me some doubt:

note that the caret (ˆ) is used to indicate that an expression should be returned from the method, just like the return keyword in conventional languages

If I were creating a programming language, writing a sentence like that would give me pause. I would ask myself “why am I doing this differently?” If everyone in the world is using return, why choose ^? To save a few characters of typing? Really? The Newspeak document does not explain why it’s like that, it just states matter-of-factly that ^ means return.

Though they reference Self as an influence for Newspeak, they chose to go with classes rather than prototypes. That’s a good decision for adoption, because people are familiar with and like classes.

Anyhow, I think Newspeak looks interesting and it will be interesting to see how it matures. But too many arbitrary changes from “conventional” syntax are likely to hinder adoption.

Why Java remains the most popular language on the JVM

My latest blog post is up on the SitePen blog:

Mark Ramm-Christensen posed some questions about using the JVM as a platform for dynamic languages. Many people do, in fact, use dynamic languages on the JVM (Groovy, Beanshell, Rhino, Jython, JRuby are some big ones… and don’t forget Scala, Nice and other “non-dynamic” languages that target the JVM). But Java the platform has not gotten widespread or serious attention until recently (witness the recent resurgence of Jython, the rise of JRuby and the coming of the Da Vinci Machine).
[From Why Java remains the most popular language on the JVM]

Answering the question “Why Java remains the most popular language on the JVM” gives clues as to what might be the next most popular language on that platform.