Inside the Launchpad AJAX Sprint: A Week with Widgets and YUI 3
Published by Maris Fogels March 13, 2009 in General
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.
Shutter
Published by Matthew Revell March 11, 2009 in Projects
Screenshots are screenshots, right? If whacking the “Print Screen” button doesn’t offer enough refinement, then surely firing up The Gimp, gnome-screenshot or knsapshot would give you what you need, wouldn’t it?
The team behind Shutter would disagree. I was interested to know what would motivate someone to develop a new screenshot app, so I asked Mario Kemper why he began work on Shutter.
Mario: Well, I am a computer science student working as QA person in my freetime. When i started to do the QA work I was looking for a neat screenshot application because we are doing a lot of documentation for the developers as well.
There were some apps like ksnapshot, gnome-screenshot etc. but they all focus on a single screenshot; no editing features, no session, no nice effects etc. So i started to develop Shutter (formerly gscrot) with these features and goals in mind.
There is another big point, though: we all spend much of our time in forums, wikis, chats etc. From time to time we need to do some screenshots and upload them so we can share them with other people so i wanted to have a built-in function to upload your screenshot with nice link-formatting so you can post the generated link directly in the forum, wiki etc.
Shutter uses Launchpad for bugs, code, translations, answers and blueprints. You can get hold of Shutter from the Shutter team’s Personal Package Archive.
Why PyRoom chose Launchpad
Published by Matthew Revell March 4, 2009 in Projects
Perhaps shutting out the distractions of the physical world is no longer enough.
PyRoom is a simple text editor that shuts out all the distractions you might find in a more complex editor or word processor, giving you nothing but a black screen that you can type into.
Bruno Bord has driven the project and chose Launchpad to host it. I asked him what led him to choose Launchpad.
Short answer: Because I was lazy, and I didn’t want to hack on a project management system myself. Launchpad hosts everything I wanted: code, bugs, translations.
Long answer: It’s not just the bug tracker. It’s the whole thing. Bug trackers are very interesting to track down tasks, reorder them, assign them priorities, etc. But it’s like playing all alone on a video game while you could have much more fun playing it online, with other people
involved.I discovered Code Versioning System and then moved to Subversion, which was a massive improvement. When I had to download a source code from CVS, I used to copy-paste command lines I didn’t understand into a bash script, and run it from time to time to update my working copy. I’ve never used CVS as a committer, and I’m glad.
I was working in a small web agency where the “revision” system was just renaming the old version of a file/directory “_old”, make a copy of it, and go on with the developement. Of course, when there was another “revision” to “commit”, you had to rename it “_old2”. Hem. Pretty amazing how things can become hellish using that kind of system.
I heard about Subversion, and reading the docs, I instantly fell in love with the syntax. At last, I could version my work with commands I could grok!
I made a quick svn+trac install on our local server, and that was ready. One of the major drawbacks of Trac at the time was the impossibility to track several projects at once.
So I had to build up a trac instance for every new project. Which was fine, as soon as I could make a tiny bash script that did everything from the ground up (svn repository and trac setup).
Anyway. I started using SVN for my personal projects. A friend of mine accepted to host my trac+svn instance for pet projects on his personal web server, and everything was fine.
One day, I moved. And I went off the internet at home for 149 days. Yes. It’s a huge number of days for a geek. At work, it was ok, but it was impossible for me to commit changes about my pet projects.
After months of despair, I finally found out about Distributed Version Control. And bzr changed my life. I could work on my projects offline, commit code, branch, merge, etc, and push it back again in the main repository when internet connection came back — this is true for any DCVS, not only bzr…
But bzr isn’t very well integrated into Trac (yet). And it’s fully integrated with Launchpad.
What’s absolutely brilliant in Launchpad is the fact that any item may interact with another. You can register a branch in a project, or in your “+junk” repository, or you can link a bug to a branch or link a branch to a bug. Once the bug is fixed, you propose the branch for merging. You can build up teams, working on specific tasks on your project: bugsquad to sort out bugs, developers to commit in the main branches, translators, or a just more general team where people interested by the project can get notifcations at any time.
Hence, using LP as a project manager makes sense.
Using LP for PyRoom was an instant choice. When I retrieved the initial python script from ubuntuforums, I commited it into a bzr branch, hacked on it a bit to clean up the code, and pushed it on the fresh new project hosted on LP.
I learned a lot during the first weeks of the project: one of the best practises is to create teams. You are on your own at the beginning, but create a team anyway, and give this team read/write access to the trunk of the project. When people start to get involved, they join the team, and are granted instant access on the main branches of the project.
But the good thing with LP is that you don’t actually NEED to be part of the dev team to send code. For Gwibber, for example, I just hacked on a bug I found with my French locale the main developers couldn’t guess. I just registered a bug, created a branch, pushed my code to this branch, and proposed it for merging. It was merged without me being member of the Gwibber team or whatever. Now the bug may be closed. WIN!
My first contributions in LP were translations, IIRC (into French, what a surprise!). Again, I was not member of any team to translate small strings in my mother tongue.
You see… it’s not just the bug tracker. Any text editor can work as a bug tracker, as long as you keep your tasks up to date in a single file. It’s the whole shebang that rocks.
Translations team in Buenos Aires
Published by Matthew Revell in Translations
I’m in Buenos Aires this week with the Launchpad Translations team — Danilo, Jeroen and Henning — along with Launchpad UI guy Martin Albisetti.
We’re working on making Launchpad cleverer at giving people the information they need where they need it. Each day we’ve been sitting with a white board, a list of existing pages that we want to improve and one simple question: what do translators want from that page?
And that’s a question that we can answer through the feedback that we’ve had on how translation can work better and also the translations that we’ve made ourselves.
We’re half way through the week and have some great plans that you can expect to see in place before our 3.0 release in July.
Inside the Launchpad Foundations sprint
Published by Leonard Richardson March 3, 2009 in API
I’m in Montreal this week, with the rest of the Launchpad Foundations team and a few other Canonical engineers. We’re preparing for the open sourcing of Launchpad by doing a lot of refactoring, so that when the code is released in July it will be more comprehensible, and reusable in projects other than Launchpad.
In addition to our main body of Launchpad code we’ll be releasing a framework project called LAZR. Code that’s not Launchpad-related will go into LAZR or one of its subprojects: lazr.config, lazr.uri, lazr.batchnavigator, and so on. These will be little libraries that can be reused in other projects.
For instance: underneath the Launchpad web service is a generic library that lets you create a web service from your existing data objects by annotating the Zope interfaces. All this code lives in LAZR: the only web service code in Launchpad has to do with Launchpad’s web service specifically. We’d like you to reuse the LAZR webservice code in any project that uses Zope interfaces to describe its data objects.
Unfortunately, there’s a lot of code in Launchpad that really should be in LAZR. If that wasn’t bad enough, the web service code in LAZR is full of dependencies on that Launchpad code. At the moment, you can’t run the LAZR web service code without bringing in all of Launchpad.
The object of this sprint is to refactor this code and move it all into LAZR packages. Our medium-term goal is a working example web service (code name “Sharks”) that uses no Launchpad code, but it won’t stop there. The more utilities we can move out of Launchpad’s monolithic code base, the more likely it is you’ll be able to find a bit of code you want to reuse.
Meet Jeroen Vermeulen
Published by Matthew Revell February 27, 2009 in Meet the devs
Jeroen Vermeulen gives us our first Asian stop-off in the Meet the devs series.
Matthew: What do you do on the Launchpad team?
Jeroen: I work on the Translations application. That’s where we translate software (including all of Ubuntu’s “main” section!) from English into just about any language I’ve ever heard of. Many people still know it by its original name, Rosetta.
Matthew: Can we see something in Launchpad that you’ve worked on?
Jeroen: It’s a funny thing: that question makes me realize how little really “visible” stuff I’ve written. I’ve been working with the database a lot and of course fixed bugs. You could say there’s mostly things that you can’t see in Launchpad that I worked on.
Recently though I’ve been working on something you should see show up in more places soon: the inline text editor. If you have javascript enabled in your browser, you can already use the existing version when you edit a bug title. No need to click through to an editing form: you just click the “edit” icon and the title becomes editable in-place.
The version I’ve been working on together with Danilo Šegan (I found out how to type that weird letter by accident:
It’s been both fun and a nuisance, since JavaScript lets you do very powerful stuff very quickly… and then it lets you spend days debugging the silliest little things. It’s a far cry from the C++ work I’ve been doing in my spare time. There, all your weak typing happens at compile time. At run time it’s all strong typing with a tiny bit of polymorphism. So it’s usually the compiler that spots the bugs, not your tests per se. As the language matured we grew habits and practices to reinforce this. Nowadays I barely even use polymorphism anymore in C++: only in a handful of isolated patterns, and more often than not purely at compile time. As my friend Kirit Sælensminde puts it, it’s great to have a compiler as a theorem prover for your code’s correctness!
Matthew: Where do you work?
Jeroen: Mostly in Bangkok, Thailand. I like to poke fun at my colleagues in places that are 40°C colder.
Matthew: What can you see from your office window?
Jeroen: One of the reasons why I picked the place: some green, unused land! It’s got grass, trees, birds, and not a whole lot of noise. That’s pretty rare in this city. What there is is usually hidden behind walls.
Right under my window there’s a dirt road with a volleyball net strung across it. Sometimes the children have to stop playing and lift the net to let a car pass underneath.
Matthew: What did you do before working at Canonical?
Jeroen: I worked for a Thai government department set up to promote open-source software in the country. It was a good chance to learn, both about technology and about cultures.
Nothing shows how the two can interact as well as the questions I got at trade shows. For instance, many people believed that software you give away cannot possibly have any value. To those people I had to explain how the software made money for the companies behind them, or they just wouldn’t consider using it. This in a country where pirated proprietary software is the norm, and price-competitive with free downloads.
Other people thought that “open source” and “linux” were the same thing, and were very sceptical when you showed them free software running on Windows. Those who do work on free software, and we have some very enthusiastic people doing that, tend to be a bit too shy for the process. They are often reluctant to badger authors about accepting patches or translations. Translating Ubuntu in Launchpad is a great way for them to get around that.
Matthew: How did you get into free software?
Jeroen: Mainly by not staying out of it. When I started programming for fun in the early 1980s, the only reasons my friends and I ever saw not to share our code were embarrassment (if the code was ugly) or fear of someone passing it off as their own (if the code was pretty). But most of the credit goes to some great people I met in and after university, and a company called Cistron that got me working with 100% free software professionally.
I did work a few jobs involving proprietary software, and some of those left a very bad taste in my mouth. At Cistron we sometimes had to patch the software we used, because it wasn’t always mature. But at least we could, and we’d be helping the software mature in the process. We didn’t need to ask for permission, or wait for someone who already had our money to decide whether our problem was a priority. In the proprietary world you always had to beg or wait for permission to solve some problem or other.
Surprisingly often, it’s easier and cheaper to deal with a problem yourself than to go through the process of getting proprietary software licenses for it. That’s even before you start handing over money. If you do make it past that, you come to the stage where you start seeing the little gaps between what you bought and what you needed. And then you end up coding your own in-house glue anyway.
There was a lot of the code as well, under the glitzy surface. Oh, the code! Some examples I’ve seen:
- A button in a user interface switches the application between two modes. The button changes its label and its colour between modes. The business logic decides which mode it’s in by looking up the button’s current colour. Yes, you read that right. This is in a large-scale financial application. The code was then given to cheaper foreign engineers for maintenance, despite all the comments, identifiers etc. being in the local language and unreadable to the engineers. The maintenance was necessary because the application relied on some proprietary commercial infrastructure that was being end-of-lifed by its vendor.
- A database table has three consecutive rows for every logical item it describes. A loop searches them linearly instead of using SQL’s WHERE clause. Instead of using a meaningful marker, the loop computes what row #i represents by taking i % 3. The switch statement has cases for 0, 1, 2, and “default.” It’s been a while but I seem to remember there was a case for 3 as well.
- A database object cache looks if the object you requested is already in memory. It does so by taking the numeric id for the object you want and comparing it to each of the cached objects’ addresses. It never finds a match because in-memory addresses simply have nothing to do with identifiers in the database. The problem goes unnoticed for years (causing memory leaks and data loss) because the compiler, also proprietary, takes until version 5.0 to start noticing that this is a very basic type error.
It’s not like we don’t make those mistakes in free software. But we let people catch us at it, and it’s better for everyone. In fact I’m convinced that projects like Linux and MySQL became so popular in part because there were enough things for beginning contributors to fix.
Matthew: What’s more important? Principle or pragmatism?
Jeroen: You’re eating soup. The bowl breaks. (Not likely, but work with me here). Now tell me which was more important: the bowl or the soup?
I know a lot of people get very worked up about this. But principle and pragmatism are on a two-way street. Going one way, principle is where you look when deciding what you should do. Or, and this is usually what gets people worked up, what everyone should do. But going the other way, you look at pragmatic reality and discern all sorts of principles. That, I think, is the real attractor to the whole debate &mash; free software has basically revived classical philosophy. What you learn there, what catches your imagination, what patterns you see and choose to explore, is all very personal.
There are people like Eric Raymond who will say that everyone just does what’s in their best interest, and nothing else will decide the course of events. The big epiphany they take from the free/open-source development is game theory and how it applies to markets. Then there are people like Richard Stallman who see how the given incentives in the market pit us against each other, and decide that it’s a bad thing. They derive a field-specific model of morality. Personally I’m fascinated by both.
But enough weaseling: I’m more on the “principle” side, because I don’t think principles are inherently non-practical. One of the smartest people I’ve known once said that morality evolves. It grows and adapts to help us survive as a group, just like perspective vision or opposable thumbs. Software licensing is at a point where different people try different things and we’re seeing what works. If I “sell” you software, it has to be like a piece of property, except copying is free and unlimited. So should we pretend that the program is still “my property” after the sale, only I’m also letting you use it? Or is it now yours, except I can sell it to others as well? It’s a lot like the old particle-or-wave debate about the nature of light.
Matthew: Do you/have you contribute(d) to any free software projects?
Jeroen: In all sorts of ways, usually to scratch an itch: a patch here, some documentation there. My main project is libpqxx, the C++ client API to PostgreSQL. I worked with the old API back in 2000, and it was as if the right approach just jumped at me, shouting “code me, code me!” I get a lot of positive feedback about how it blends in with the language and its standard library.
Sometimes you can do more good by documenting than by coding. We engineers are all the same: once you understand something, it’s “obvious” and suddenly you’re unable to explain it. I thought D-Bus was a great development when I first saw it, but the documentation was thin on concepts and too detailed. Since I had to figure out the concepts anyway, I made a list and pretty soon I had a decent introduction written up. It even sparked some debate between developers about unresolved design questions. Funny how a contribution like that is easier to make when you’re new to the project. Much the same happened with fcgi, a nice “persistent CGI handler” similar to FastCGI but much simpler.
Matthew: Tell us something really cool about Launchpad that not enough people know about.
Jeroen: My personal favourite is a very basic one that we’ve had for ages: because Launchpad mirrors subversion and CVS repositories, you can play with the code of some project and still have full revision control.
When I wanted to mess around with a piece of code I got from the internet, I used to download a tarball, unpack, work on the code, then diff against a freshly-unpacked copy. Or I’d check out the repository and never commit. But now I can just branch off Launchpad’s copy of the source tree, and commit changes locally to my own branch.
Matthew: What’s your favourite TLA?
Jeroen: Hard one, since I have over 23,000 to choose from! I keep them here.
It started out as a joke about TLA-space pollution, but some people actually use it as a reference. I do, too.
What’s my favourite TLA? I like the name of the list itself, which is a meta-TLA. GTF stands for GPL’ed TLA FAQ. If you send me a new entry you become part of the GTF Contributor Program or GCP, and you get a little logo you can show on your home page.
Matthew: Okay, Kiko‘s special question! You’re at your computer, you reach for your wallet: what are you most likely to be doing?
Jeroen:Probably checking for a 10-Baht coin so I can get a motorcycle ride back to the main road. The dogs get a little frisky sometimes, so the wild ride may be marginally safer. The coin looks just like a worn 2-euro coin at about 1/10th the price. They’re similar enough that many coin slot machines had to be recalibrated.
Matthew: Thanks Jeroen!
Launchpad 2.2.2: easier upstream bug linking
Published by Matthew Revell February 26, 2009 in Releases
The Launchpad team is proud to announce the release of Launchpad 2.2.2! Let’s look at what’s new this month.
Now easier to add upstream links to bug reports
If you’re using Launchpad to track a bug that you think may also be reported elsewhere — such as in a project’s Bugzilla — it’s now easier to find that bug report.
Launchpad developer Graham Binns explains:
Launchpad will now give you direct links to the bug search and filing forms in a project’s external tracker, so long as Launchpad knows the tracker’s location.
To find the links, all you have to do is click “Also affects project” on the bug report and select the project you want to link to.
There’s more in Graham’s blog post.
Also in Launchpad 2.2.2
February saw the Launchpad team dedicate a week to tackling slower-loading pages. Read our write-up of what happened in Launchpad Performance Week.
You can find full details of Launchpad 2.2.2 on its milestone page.
If you come across a bug, please report it!
See you next month!
We’ll be releasing Launchpad 2.2.3 at the start of April. In the mean time, stay up to date with Launchpad news and views right here on our blog.
And as always, you can join us in #launchpad on Freenode and on the launchpad-users mailing list.
Links to external bug trackers right where you need them
Published by Graham Binns in Bug Tracking, Cool new stuff
Linking Launchpad bugs to upstream bugs can be hard work. You don’t necessarily know whether the bug is reported on the upstream tracker, and if you don’t know where the upstream project tracks its bugs you have to go and find out before you can file the bug and link the Launchpad bug to it.
We understand that this process can be a bit of a pain, so we’re introducing a feature that should make linking to upstream bugs a bit easier: Launchpad will now give you direct links to the bug search and filing forms in a project’s external tracker, so long as Launchpad knows the location of the project’s tracker and, if the tracker tracks more than one project, which project on the external tracker the Launchpad project refers to (so, for example, Launchpad needs to know that the Launchpad project ‘evolution’ links to the ‘Evolution’ product in the Gnome Bugzilla).
And because we know that a project maintainer shouldn’t have to go back to Launchpad and add the link to the remote project when Launchpad should be able to work it out for itself we’ve fixed that problem, too: Launchpad will check all the projects that are linked to a remote bug tracker and will try to deduce which remote project they’re linked to by looking at the bug watches that are registered against that bug tracker. Of course, this isn’t an exact science, and we’ll have to correct some of these auto-generated links manually, but hopefully it won’t take more than a few days for us to straighten out the kinks.
In order to get to remote bug tracker links, all you have to do is click Also affects project on the bug report and select the project that you want to link to. Launchpad will then offer you the links.
We’re going to be working to improve this further in the coming Launchpad development cycle, so keep your eyes on this blog for further information.
Roundup of the first Launchpad Performance Week
Published by Matthew Revell in Launchpad Performance Week
Back at the beginning of February, we ran our first Launchpad Performance Week.
Our aim was to find pages that, although they weren’t slow enough to trigger our internal warning, were nonetheless taking too long load. The first thing we did was to get our internal warning system to generate a report when a page takes 25 seconds to load, rather than 30 seconds.
So, armed with a list of sloth-like pages, each part of the Launchpad team went away with one aim: to fix whatever was preventing those pages from loading in a reasonable time.
Those fixed pages have been around on Launchpad’s edge environment for some time now and hit production with our 2.2.2 release.
So, let’s see what the team have been working on.
Faster bug pages
As a bug in Launchpad gets more attention — whether you measure that by the number of comments or subscribers — it takes more work to display it. That has led to particularly popular bugs, including the oft-linked-to bug #1, taking too long to load.
Two of the big pain points, on bug pages, were comments and the box listing the bug’s subscribers. For most bugs, they present no problem. However, bugs with many comments/subscribers were nudging Launchpad’s hard timeout limit.
Gavin tackled the slow loading of multiple comments by changing the bug page to display only 80 comments. Where the 81st comment would be there’s now a link to view the rest of the comments or post a new comment.
Tom‘s approach to the subscriber list was to load it asynchronously, preventing it from acting as a bottle-neck to loading the rest of the page. So far, there’s very little wait between the rest of the page loading and the subscriber list appearing.
Personal Package Archive overview pages
The Soyuz team worked on PPA overview pages. Take a look at the Exaile development team’s PPA as an example.
Two hold-ups were caused on this page, particularly for PPAs with many packages: the disk usage information and the detail for each package. Both are now loaded asynchronously, the package detail only being loaded when you click its header.
There’s more detail from Julian in his blog post.
Translation pages
The translations pages are some of the most data-intesnive in all of Launchpad. Danilo talks about the tranlsations team’s Launchpad Performance Week work in his blog post.
Code project cloud
Launchpad Code developer, Jonathan, wrote on his own blog about his work on the project cloud page:
The Launchpad Code home page is now a little bit nicer and a little bit faster.
For a while now, the page has had a tag cloud showing some projects that host branches on Launchpad. The tag cloud is drawn based on these two rules:
- the more branches, the bigger the tag
- the more recent the last commit, the less faded the tag.
Up until recently, the home page only showed some projects starting with ‘A’ — which is a bit silly. My recent patch changed the query to show the most branch-y projects on Launchpad. It looks a lot nicer, IMO.
We also got rid of the green / blue distinction. No one knew what it meant and it made the page more visually muddled. There are still some tweaks we can make, but I think this is definitely an improvement.
And elsewhere
We made a number of smaller changes right across Launchpad, as part of the Performance Week. We’re also working on introducing much more AJAX into Launchpad’s web interface, which should make the experience of using Launchpad feel much quicker.
We’ll be holding another Launchpad Performance Week in April, this time cutting our definition of slow page by a further five seconds. Again, we’ll be posting details of what we did right here.
New privacy features for commercial subscribers
Published by Matthew Revell February 25, 2009 in General
Launchpad is set up to make it easy for groups to come together spontaneously around tasks big or small. Take this bug as an example: it affects three projects that share the same code. Launchpad brings them together to find a fix.
But there are times when collaboration needs to be done privately. It could be because of security concerns, or confidentiality obligations to a client, or to coordinate the timing of events for marketing purposes, etc.
Launchpad already enables individual bugs to be marked as private but, until now, that’s been all. However, we’re running an interesting beta program at the moment that allows projects to default to both private bugs and private branches. As this will be of most interest to projects who aren’t ready to share their code, we’ll offer it by commercial subscription.
We’ve already been offering basic commercial subscriptions for a few months now. While Launchpad is always free of charge for free software projects, it also hosts some projects with non-free licenses, and charges them a fee to offset the costs of running the site. Until now, these commercial subscriptions have just meant access to Launchpad with no extra features. But following our beta of private branches and private bugs, we hope to offer a wider range of features to commercial subscribers, as they are likely to have different privacy needs from free software projects. If you’re a commercial subscriber and want to take part in the beta, or if you’re considering a commercial subscription, please contact us.
Of course, commercial subscriptions don’t take anything away from the free software projects that use Launchpad. They remain the focus of our development work, particularly as we move to open sourcing Launchpad itself.
