Recently ten people from Launchpad and other parts of Canonical came together in Berlin to hack on Launchpad’s new YUI 3 JavaScript interface. The sprint was tremendously successful, producing four fully functioning YUI 3 Widgets, complete with test suites and live demo pages. This post offers a look inside the event, and some thoughts about what made it so successful.
The sprint brought together one member from each of Launchpad’s teams, as well as Martin Albisetti, for his design insight, Francis Lacoste, for his Zope3 and Launchpad architecture knowledge, and Stuart Langridge, who, to our surprise and fortune, had much jQuery, DOM, and CSS experience. This wasn’t the team’s first encounter with the YUI 3 JavaScript library (we had spent two weeks in the fall reviewing JavaScript, YUI 3, and client-side development), but this would be our first time taking YUI 3, and Launchpad’s JavaScript support, up to full speed.
Martin kicked off the morning of day one with a walk through some video proof-of-concepts that we would bring to life. After some wide-ranging discussion and dealing over implementation details, we spent the afternoon looking at the technical side of YUI 3 Widgets. At the end of the day eight of the sprinters split into pairs, each pair picking a widget to work on.
Day two saw the four teams plan their attack, then dive into the code. The sprint took on the shape of a massive parallel experiment, with each team choosing a different development approach: one wrote tests first, diving into Test Driven Development; another executed a two-pronged assault, with one person writing the widget while the other worked on Lauchpad integration. A third team went for functionality first, aiming for a working wireframe before styling the page, or writing tests. In the end none of the approaches was a clear winner, but it’s worth noting that quickly getting a working prototype up on the projector gave everyone a huge moral boost, and looks to be worth the cost of that team writing their tests last.
One thing that helped every team get up and running quickly with the YUI 3 Widget framework was having an already-running, fully integrated widget in Launchpad: the inline-text editor for Bug and Project titles. Building the inline editor had cleared paths for coding styles, directory structure, test harnesses, and all of the Zope3 integration code. A month or two of work had already gone into supporting JavaScript and JavaScript testing in Launchpad — now that work paid off, giving all eight people a very fast ramp-up to code that could land in mainline. Along with the very well-written YUI 3 docs, everyone was writing code by noon.
Day three saw more code, tests, and our first working widget. We just needed the fancy frame to have a pixel-perfect movie match. The teams kept the momentum high all day while Martin, Francis and I criss-crossed the room, lending design decisions, on the spot integration plans, and YUI advice and council. Stuart Langridge also lent his scripting and CSS experience to the effort. For any sprint, when the team is blocked on an implementation question, it helps to have someone with the authority to make final, on the spot decisions. We discovered that, when doing top-to-bottom JavaScript widget implementation, it helps to have a whole team of them.
By noon of day four most of the remaining widgets were functional, if not fully styled. For me, much of the day was spent pair programming, tackling a subclass of the YUI Overlay widget. We had trouble getting it to accept the stylish drop-shadowed frame given to us by our designer, and we used YUI 3’s JavaScript unit testing library, yuitest, to work around it. Our test suite allowed us to spot the Firefox DOM bugs our layout triggered, and assured us that our hackish workarounds unbroke the DOM tree.
Most of the sprinters were qualified code reviewers, so day four’s afternoon was spent in a team review of the fully functional fancy Overlay widget: two authors presenting with Emacs, one scribe, and seven people contributing questions and comments. The meeting helped immensely in building a culture around JavaScript code in Launchpad, and left us with a draft JavaScript style guide, and a coding standard we could take to the wider team. I highly recommend such a review, along with the surrounding discussion, to anyone bringing a new language into a programming group.
Everyone had great momentum going into day five. All four widgets were fully functional, with only a few rough spots remaining. One nasty Friday surprise was that the original inline editor didn’t work in Konqueror 4.1 — in fact, it made editing Launchpad Bug titles impossible. This is where our adoption of YUI’s Graded Browser Support and Graceful Degredation really shone. We quickly made the decision to give KHTML browsers a C-Grade experience: for them, the site behaves as if it were not enhanced with JavaScript: you can still edit a bug title, but you are taken to a new page to do so. The decision was fast and simple, and with a clear C-Grade verdict of “No JavaScript”, no unnecessary time was spent searching for other fun issues the browser may have presented.
Day five’s afternoon was spent with everyone in a Review Jam. We mixed up the programming pairs, with one person from each team reviewing someone else’s code, using the guidelines we had drafted the previous day. Martin did some final user interface design reviews, and everyone left that Friday with a list of changes before final submission to mainline.
The sprint was very successful, one of our best yet, producing four YUI 3 widgets in only three and-a-half days of coding, and we plan to have another sprint like this in the future. Here’s some of what made this week-long coding sprint work for us:
- You need to have a good mix of skills at the sprint, including experienced people from each discipline. And that experience needs to be available to unblock sprinters as quickly as possible. At this sprint, two of the ten people were dedicated to roaming the room, and at least two more had deep experience with the problems we were tackling.
- Someone at the sprint needs to be a project stakeholder, with desicion-making authority. They’ll be called upon as the sprint progresses. Martin filled this role for us, having final authority on what the Launchpad user interface would look like.
- If sprinters are building something new, but understood, come prepared with a template, plan, or example that everyone can follow. Use that template to spend less time at the sprint understanding known problems, and more time tackling new ones. The completely integrated and running inline editor widget had already covered all aspects of widget development for us.
- Sprinters do very well with self-selected goals and self-made plans. We didn’t hold any of the teams to any particular approach (aside from some good-hearted chiding about unwritten tests), which let everyone adapt their style to their own problem. Two of the teams even picked goals that were more ambitious than the original scope.
A final word on YUI 3: the library performed very well, especially given its pre-release status. Experienced scripters may find working with YUI 3 a little odd at first, because you are not working with the raw DOM: you have to get used to using YUI Node instances, getters, and setters, instead of DOM object properties (most of the DOM methods are passed right through). However, once past the initial bump, you can quickly see the advantages of having features like object property getters and setters, a robust and advanced object construction system, and cross-browser APIs. Stuart also pointed out one big, open question about YUI itself: the only major libraries to tackle JavaScript widget development “in the large” are YUI and Dojo. We’ll see if YUI’s large approach, jQuery’s small tools approach, or YUI 3’s mix of both is best.
