Blue Sky On Mars

I’ve always thought that it should be possible to design a language that is both usable and performant. JavaScript performance has improved tremendously, but it is still quite a distance behind C and even Java. Of course, programmer productivity is certainly more important than raw performance for most applications. It’s only as you try to scale up services that you really wish you could squeeze out more performance. In fact, being able to squeeze out more performance is one way to avoid the complexity shift of moving from one box to two/many. Of course, there’s always an upperbound to this, but that upperbound can be remarkably high.

I always thought that D looked like the language that could unify high level programming and performance. But D has failed to catch on and seems to be in a state that would make anyone seriously question using the language for real work.

Now, along comes Go, a new language sponsored by Google. More interesting than the Google part, is that Go was created by people with a long history dating back to the origins of Unix (Rob Pike, Ken Thomson, apparently even Brian Kernighan are involved). The language is designed to support super fast compilation (yay for programmer ergonomics!) and C-like performance. Importantly, the language also has built in features to help support scalable and safe concurrent programming, via “channels” for passing data back and forth, rather than something like transactional memory.

Go has a simplified object model that looks cool, but I’d be curious to see how it feels to use in practice. Go doesn’t have exceptions, which seems like a real drag to me. Apparently, exceptions are still considered an open issue and they present thorny issues when you’re dealing with concurrent processes.

Go’s standard library looks to have a decent collection of features, and you can call C code pretty easily. More care needs to be taken if you want C code to call into Go. If Go can get its packaging story together more quickly than Python has, it may indeed start having appeal as a high-level, fast, concurrent programming language.

It’s still very early for Go. It’s not used in production in Google yet. It doesn’t run on Windows. But it has arrived on the scene hitting many points at the “good enough” level (fast compiler, decent library, ok interface to C, decent docs). Google has full-time staff assigned to it, and they’re even hiring a program manager. With speculation that Google doesn’t want to use Python for their high volume services, I wouldn’t be surprised to hear that Google really wants to use Go internally. With an “anchor tenant” like Google, Go has a lot more potential than D ever had.

Now they just need to deal with the pesky issue of the name.

I’ve been interested in doing cool stuff with web technology for a long time. I still think that web development is harder than it should be, but new tools, processes and ideas come along all the time to make it easier and more fun.

Many people probably view me as a “Python guy”. Sure, I’ve done a good deal of work with Python over the past few years. But, there are many, many good ideas on the server side that come from places other than Python.

And, the browser as a platform is an entirely different thing than it was a few years ago, particularly when you restrict yourself to “modern browsers”, as we do on Bespin. The performance difference between today’s browsers and those from a couple years back is huge, and that new performance opens the door for all kinds of new applications and toolkits to help us build those apps.

I want to learn firsthand from people using modern tools to make development faster and more fun. I haven’t seen a group here in Ann Arbor that is devoted to the broad range of web development topics, so I decided to get one going. It turns out that Majd Taby sent a message to the a2geeks mailing list in April about starting a web dev group, but I somehow missed that. Majd and I exchanged some email this week and worked out the details of the new group.

The new group is called a2 <div> (or just a2div) because it has the same topic focus as cu <div> and I liked the idea of joining forces in some sense with a similarly minded group. cu <div> has a bit of a student focus that a2 <div> does not (it’s been a long time since I was a student). Thanks to Cameron from cu <div> for giving us the go-ahead to start an Ann Arbor offshoot. Thanks also to Dug Song for passing along the link to cu <div> and connecting me with Majd.

a2 <div> will be a loosely organized group as MichiPUG is… bringing the right people together for good discussion is far more important than creating a formal organization. Meetings are free. Our meeting format will likely be something along the lines of 1 hour presentation/demo followed by lightning talks and discussion.

An important aspect of a2 <div> is that’s non-denominational. Are you doing client and server in Java (for example, with GWT)? Neat. How about in Python (with Pyjamas)? Groovy. Doing the server in Lift and the client side with Cappuccino? How about PHP+Dojo? SproutCore+WebObjects? Using ASP.NET MVC with jQuery? Do you use Cucumber to test your apps? All are welcome, all are interesting.

Our meetings will be at the SRT Solutions office in downtown Ann Arbor. This is a great space to meet at (projector, whiteboards, flexible table arrangement), and the location is nice because it’s easy to walk out for drinks and food afterwards. Thanks to Dianne Marsh for letting us use their office!

Meetings will be on the 3rd Wednesday 4th Thursday of each month at 7pm. That means our first meeting will be on September 16th 24th (less than two weeks away). You can subscribe to our calendar in XML or ical formats.

The first meeting topic is not fully decided yet. Please join the a2div googlegroup and let us know what you might want to hear about or talk about!

If you’re near Ann Arbor on September 16th, join us at SRT Solutions for engaging discussion on all webdev-related topics! See you there!

I work in Mozilla’s Developer Tools Lab, where we’re working to make things easier for web developers and to explore what is possible using open web tools. It turns out there’s quite a bit that’s possible, and we’ve just scratched the surface with what we’ve done with Bespin so far.

I’m really happy with the team that I’m working with, both within Mozilla Labs and in the Bespin community. I’m also really happy to report that we’ve got an opening on our team! We’re looking for fantastic software engineer that will own the Canvas-based editor component that is at the heart of Bespin.

If being at the forefront of JavaScript technology (Canvas, local storage, web workers) sounds fun and exciting to you, drop us a line! We’d love to talk to you!

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.

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.

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.

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.

My latest article is up on the SitePen Blog: Inside the Dojo Toolbox. I walk through some of what we encountered while building the Dojo Toolbox AIR application. If you’re thinking of building an AIR application, particularly using JavaScript, check out this look at the technology.

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]

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!