Planet Launchpad

The title may sound like a contradiction, but I assure you that it is not. You can now use private teams in social contexts in Launchpad. Private teams can collaborate with public projects and other teams if they choose to reveal the existence of the private team.

1. Private teams can me members of other teams.
2. Other teams can be members of private teams.
3. Private teams can subscribe to bugs, blueprints, branches, and merge proposals
4. Private teams  can be in public project roles,  such as maintainers, drivers, and bug supervisors.
5. You can change the branch owner to be a private team.
6. Private team personal branches (+junk) are always private.

When a member places the private team in a social situation, a the member is asked to confirm that it is okay to reveal the team’s identifying information. This information is the team’s Launchpad Id used in URLs, the displayname, icon, and logo. A user can visit the private team’s Launchpad page and will only see that information. The rest of the page is not shared. Anonymous users cannot see a private team’s page because that user is not being social; logged in users can see the private team’s page

Private team page seen by a non-member

Launchpad did not permit these interactions previously because it was not clear who should know about the team. Someone has to know. If Launchpad permitted private teams to subscribe to bugs or be members of teams without anyone knowing of them, they would be unaccountable. Private teams could spy on organisation, or learn about security vulnerabilities to exploit. Launchpad will not ever permit such asocial behaviour. The resolution for social interactions was to permit other parties to know enough of the private team to make an informed decision. For example, when I choose to make a bug private, I want to know who was already seen the bug through a subscription. I may choose to unsubscribe the private team if I do not trust them.

Private teams may invite exclusive teams to be members. Exclusive teams (moderated or restricted teams) review all members so they are accountable. If a team admin trusts the admins of another team, and that team is accountable, Launchpad permits the other team to be a member. This is actually a rule that applied to all exclusive teams. private teams are always exclusive (restricted membership policy). The only nuance with private teams is when it is a member of another team; the super team may know the members of the private sub team because the super team has the right to audit all its members so that it too can be accountable.

Here's a thing that happens a lot to me: I'm doing some work, and as part of that work I need to run a command in my terminal that takes a little while. I run the command, look at it for about a second and then switch to doing something else – checking email, perhaps. I get deeply involved in my email checking, and then about twenty minutes later I switch back to the terminal and see the command has finished. For all I know, it finished nineteen minutes ago, and I was just too engrossed to notice it.

This is a big productivity sink for me, especially if the command happened to fail and need retrying. I'm not disciplined enough to just sit and watch the command, and I'm not prescient enough to add something to each invocation telling me when a command is done. What I want is something that alerts me whenever long running commands finish.

Well, that thing now exists, thanks to glyph's script that provides precmd and postcmd support to bash and a lot of help from Chris Jones of Terminator.

To use it right now:
 $ bzr co lp:~jml/+junk/shell-tools
 $ . shell-tools/long-running.bash
 $ notify_when_long_running_commands_finish_install


You'll see that if you run a command that takes over 30 seconds to complete, it will pop up a notification, which should hopefully take you away from whatever it was you are doing and back to the task at hand.

If you look at the code, you'll see that it installs two hooks: precmd and preexec. preexec runs just before the shell launches a command, and precmd runs just before it prompts for the next command. Our preexec stores when the command was launched and the precmd checks to see if it finished within a certain time frame. If not, it sends out a notification.

Currently, you'll get a notification when you finish reading a long document, since the command finishes a long time after the command starts. Obviously this isn't ideal. I think the fix is to only send notifications when the shell doesn't have focus. Unfortunately, that's a little tricky and I think is going to be highly terminal specific.

Anyway, I'm a total shell newbie, so I'd love to know if there's any way this could be done better.  Also let me know if you find this useful, or you know of someone who has already done this.

Custom Bug Listings

Over the past few months the Launchpad Orange Squad has been working to make it easier to get the information that matters to you from bug listings.

A lot of you have said in the past that you’d like to be able to filter bugs in a way that works best for you. Hopefully this new feature, with its customisable functionality should help with this goal, filling your screen with more of what you want to see.

Features

You can now sort bugs by criteria such as name, importance, status and age. You can switch on the criteria that you use most and turn off criteria that you don’t use. So if you always like to see bug age, but aren’t interested in heat, you can switch on age and switch off heat, and so on.

Display

We’ve also redesigned how bug listings are displayed – fitting more information into each bug listing, and adding sort options such as bug age, assignee, reporter, and tags.

You can put your results into ascending or descending order without having to reload the page, and you’ll be able to save your preferred layout, so your settings will be saved for the next time you need to look over your bugs.

User research

This was my first main project since joining the Launchpad team back in November as the new Usability & Communications Specialist. User research has played an important part in how we’ve defined the feature and the decisions the team has made to improve the display, wording and functionality.

A number of you took part in one to one interviews, at group sessions at UDS-P and by taking part in an online survey. Thanks to everyone involved – what you told us has really helped to make this feature a more user-friendly experience. Some of our user research results (link) are already available online, with more being added soon. We’ll be carrying out some further tests in the weeks ahead, so please get in touch if you’d like to get involved.

Bugs

Every new feature has teething problems, and custom bug listings is no different. We still have a number of bugs that need tweaking, so please bear with us, and file any bugs if you spot anything that’s still out there.

This is a tiny PSA prompted by my digging into a deadlock condition in the Launchpad application servers.

We were observing a small number of servers stopping cold when we did log rotation, with no particularly rhyme or reason.

tl;dr: do not call any non-reentrant code from a Python signal handler. This includes the signal handler itself, queueing tools, multiprocessing, anything with locks (including RLock).

Tracking this down I found we were using an RLock from within the signal handler (via a library…) – so I filed a bug upstream: http://bugs.python.org/issue13697

Some quick background: when a signal is received by Python, the VM sets a status flag saying that signal X has been received and returns. The next chance that thread 0 gets to run bytecode, (and its always thread 0) the signal handler in Python itself runs. For builtin handlers this is pretty safe – e.g. for SIGINT a KeyboardInterrupt is raised. For custom signal handlers, the current frame is pushed and a new stack frame created, which is used to execute the signal handler.

Now this means that the previous frame has been interrupted without regard for your code: it might be part way through evaluating a multi-condition if statement, or between receiving the result of a function and storing it in a variable. Its just suspended.

If the code you call somehow ends up calling that suspended function (or other methods on the same object, or variations on this theme), there is no guarantee about the state of the object; it becomes very hard to reason about.

Consider, for instance, a writelines() call, which you might think is safe. If the internal implementation is ‘for line in lines: foo.write(line)’, then a signal handler which also calls writelines, could have what it outputs appear between any two of the lines in writelines.

True reentrancy is a step up from multithreading in terms of nastiness, primarily because guarding against it is very hard: a non-reentrant lock around the area needing guarding will force either a deadlock, or an exception from your reentered code; a reentrant lock around it will provide no protection. Both of these things apply because the reentering occurs within the same thread – kindof like a generator but without any control or influence on what happens.

Safe things to do are:

• Calling code which is threadsafe and only other threads will be concurrently calling.
• Performing ‘atomic’ (any C function is atomic as far as signal handling in Python is concerned) operations such as list.append, or ‘foo = 1′. (Note the use of a constant: anything obtained by reading is able to be subject to reentrancy races [unless you take care ])

In Launchpad’s case, we will be setting a flag variable unconditionally from the signal handler, and the next log write that occurs will lock out other writers, consult the flag, and if needed do a rotation, resetting the flag. Writes after the rotation signal, which don’t see the new flag, would be ok. This is the only possible race, if a write to the variable isn’t seen by an in-progress or other-thread log write.

That is all.

Launchpad doesn't really have any good mechanism for letting you review a list of "your" projects.

That's partly because there are a lot of different ways that it could do it. You could be the maintainer of a project, or its driver, or its bug supervisor, or you might have commit access to its trunk branch. All of this could be direct, or through membership of a team. It's tough.


Since it's that time of year when I review my projects, responsibilities, goals and the like and start to figure out what I want to do next year, I want to figure out what are my projects on Launchpad.

Luckily, Launchpad has an API. I can't use it to figure out what projects I'm the maintainer of, but I can use it to figure out what trunk branches I have commit access to.  The link has the Python code for the script.

Really, Launchpad should allow me to curate my own list of projects, with input to that list coming from all of the sources mentioned above, as well as arbitrarily selecting projects.

The new bug listings listings were the first time my squad, the Orange Squad, had a chance to work on some really nice in-depth client-side UI since our squad was formed. Not only were we implementing the feature, we wanted to lay groundwork for future features.  Here are some of the new things we’ve done.

Synchronized client-side and server-side rendering

Early on, we decided to try out the Mustache template language, because it has client and server implementations. Although we wanted to make a really responsive client-side UI, we also wanted to have server-side rendering, so that we’re not broken for web crawlers and those with JavaScript disabled. Being able to use the same template on the server and the client seemed ideal, since it would ensure identical rendering, regardless what environment the rendering was done in.

It’s been a mixed bag. We did accomplish the goal of using a single template across client and server, but there are significant bugs on both sides.

The JavaScript implementation, mustache.js, is slow on Firefox. Rendering 75 rows of data takes a noticeable length of time. If you’re a member of our beta team, you can see what I mean. Go to the bugs page for Launchpad itself in Firefox. Click Next. Now click Previous. This will load the data from cache, but it still takes a visible length of time before the listings are updated (and the Previous link goes grey).

mustache.js also has bugs that cause it to eat newlines and whitespace, but those can be worked around by using the appropriate entity references, e.g. replacing “\n” with “
”

The Python implementation, Pystache, does not implement scoping correctly. It is supposed to be possible to access outer variables from within a loop. On the client, we use this to control the visibility of fields while looping over rows. On the server, we have to inject these control variables into every row in order for them to be in scope.

We needed a way to load new batches of data. Mustache can use JSON data as its input. Launchpad’s web pages have long had the ability to provide JSON data to JavaScript, but Brad Crittenden and I recently added support for retrieving the same data without the page, via a special ++model++ URL. This seemed like the perfect fit to me, and it’s turned out pretty well. Using the ++model++ URL rather than a the Launchpad web service means the server-side rendering can tightly parallel the client-side rendering.  Each uses the same data to render the same template.  It also means we don’t have to develop a new API, which would probably be too page-specific.

Client-side Feature Flags

While in development, the feature was hidden behind a Feature Flag. But at one point, we found we wanted access to feature flags on the client side, so we’ve now implemented that.

History as Model

We wanted users to be able to use their browser’s Next and Back buttons in a sensible way, especially if they wanted to return to previous settings. We also wanted all our widgets to have a consistent understanding of the page state.

We were able to address both of these desires by using YUI’s History object as a common model object for all widgets.  History provides a key/value mapping, so it can be used as a model.  That mapping gets updated when the user clicks their browser next and back buttons.  And when we update History programmatically, we can update the URL to reflect the page state, so that the user can bookmark the page (or reload it) and get the same results.  Any update to History, whether from the user or from code, causes an event to be fired.

We’re able to boil the page state down to a batch identifier and a list of which fields are currently visible. The actual batches are stored elsewhere, because History isn’t a great place to store large amounts of data.  For one thing, there are limits on the amount of data that can be stored.  For another, the implementation that works with old browsers, HistoryHash, can’t store anything more complex than a string as a value.

All our widgets then listen for events indicating History has changed, and update themselves according to the new values in the model.

Summing up

It’s been an interesting feature to work on, both because of the new techniques we’ve been able to try out, and because we’ve been closely involved with the Product team, trying to bring their designs to life.  We haven’t quite finalized it yet, but I’m going on leave today, so I wanted to let you know what we’ve all been up to.  Happy holidays!

I'd like to announce the general availability of a YUI 3 Nightly combo server. Each night, it will check out and create a new build of the YUI 3 source code, and serve it via a combo handler. In order to use it, just point your YUI_config to the new combo loader. Information about it can be found at the main page at YUI Nightly Doc Page.

Why did I do this? There are a few reasons. First, Ubuntu One can't use the Yahoo! CDN because we're using SSL. This means we have to run our own combo loader. The problem with this is that it's a pain to go out and get new YUI and plug it into my dev environment just to get surprised by something that broke or something that changed, etc. With the nightlies, I can regularly just point YUI to this combo loader and let it run.

I'm using this in "production" for a small personal site, but I wouldn't recommend it be used it any production site that actually has uptime requirements.

Comments, questions, and pull requests welcome.

Update: The URL has now been changed to http://yuinightly.com/.

The Launchpad maintenance teams have been working since the beginning of the year at reducing our Critical bugs count to 0. Without much success this far. The long term trend keeps the backlog at around 300.  And it’s not because we haven’t been fixing these. Since the beginning of the year, more than 800 Critical bugs were fixed, but more than 900 were reported

So I investigated what was the source of all these new critical bugs we were finding. A random sample of 50 critical bugs filed were analyzed to see where and why they were introduced. The full analysis is available as a published Google document.

Here are the most interesting findings from the report:

• Most of the new bugs (68%) are actually legacy issues lurking in our code base.
• Performance and spotty test coverage represents together more than 50% of the cause of our new bugs. We should refocus maintenance on tackling performance problems, that’s what is going to bring us the most bang for the bucks (even though it’s not cheap).
• As a team, we should increase our awareness of testing techniques and testing coverage. Always do TDD, maybe investigate ATDD to increase the coverage and documentation our the business rules we should be supporting.
• We also need to pay more attention to how code is deployed, it’s now very usual for scripts to be interrupted, and for the new and ancient version of the code to operate in parallel.

Another way of looking at this is that Launchpad represents a very deep mine of technical debt. We don’t know how exactly deep the mine is, but we are going to find existing Critical issues until we hit the bottom of the mine. (Or until we finish refactoring enough of Launchpad for better testing and performance. That’s what the SOA project is all about.)

In the mean time, we should pay attention to regressions and fallouts, (those are really the new criticals) to  make sure that we aren’t extending the mine!

Photo by Brian W. Tobin. Licence: CC BY-NC-ND 2.0.

...K-I-S-S-I-N-G

The Web and Mobile Ubuntu One team is in Buenos Aires, Argentina (along with most of the rest of the Ubuntu One teams) exploring the boundaries we may experience merging the Web and Native App experiences. I realized very quickly in this exploration project that I needed an end goal. Since we are already using YUI on the web part of Ubuntu One, I figured that I needed to figure out where the limitations of YUI would be there.

Enter PhoneGap.

It became very clear that it'd be much better to use one of these "glue" frameworks than to roll our own (the important reason being that we'd rather do more fun things). One of the first things I noticed is that the default PhoneGap doesn't really "compile" out of the box, which annoys me. Once I linked in the www folder properly, I had a good stub.

Using the YUI Loader in PhoneGap is not impossible, but it's relatively impractical. It stores a whitelist of URLs that you can get to, and even then, javascript is so required on the site that we can't afford to not have javascript. At this point, I realized that all the front-end tweaking/ricing I've been doing for the last year or so gets thrown out the window. I broke down and made giant rollup files for yui.js and yui.css.

As a sidenote, I also took the time to actually explore the YUI App Framework by coding rather than reading about it (which I've done a lot). There is an example Todo app (thus, the reason why I made a todo app). So I essentially cargo-culted that code.

Sometime during this cargo-culting, I realized one very important thing: Debugging PhoneGap apps is a pain in the ass. It really is. It resulted in this late night tweet (which I was at least half serious about). Unless you're a human jslint machine (and if your name is not Doug Crockford, I assert that you are not a human jslint machine), you're bound to make typos and syntax errors and such. You don't really get a decent access to the console1. I tried running the app in a normal desktop browser but I found that events I was expecting either weren't firing or weren't being handled (without a console, I don't know). I eventually went digging into the PhoneGap js that comes with the default template, and realized that I needed to just kill the PhoneGap js when testing in my browser. The browser only takes you so far, but it at least helped me to get the YUI toolchain sorted out.

I then took a bit of time sorting through the touch-specific interface and adapting the App example to that interface. For instance, hover events are useless on mobile. I also found that the "keypress" event for the Enter key in an input wasn't firing with the keyboard "return". Apparently, the iPhone wants the form input wrapped in a form itself, and then it'll show the "Done" button in the on-screen keyboard, which will send the right event (make sure that the form doesn't actually submit).

The end result is MoarTodo2. It's a really ugly app, but it's academic and I just wanted to learn about the toolchain. I can't imagine not using something like PhoneGap (it doesn't have to actually be PhoneGap) to build a mobile web app to be distributed through the various app stores. I expect there will be more to the debugging story, but it's still a learning curve.

I still feel pretty strongly that the Native vs. Web argument will continue, and that they'll still have their various places. I look forward to a day when that argument is settled, but I also look forward to the Year of the Linux Desktop, the rapture, and Santa Claus.

1 I didn't try Weinre because I had switched to using iWebInspector a few weeks ago (when I wasn't using a PhoneGap container), and so didn't have it immediately on my system. I'll probably have to go back and try it out in a PhoneGap context.

2 Xcode creates new projects with Git. I'm not making a political statement here. I just pushed it where it was easiest. Don't hate.

Our custom bug listings beta has been up and running for just over a week now – thanks to everyone in the Launchpad beta testers group that have tried it out, and thank you for all your valuable feedback and comments. If you haven’t tried it yet, you can get access by joining our beta team here:  https://launchpad.net/~launchpad-beta-testers

We want to improve how the default information is displayed to make this tool work better, so we’ve put together a super-quick survey to find out:

- What information about a bug you most want to see in bug listings

- What the default ‘order by’ options should be

- If you’d like to see any other ‘order by’ options.

These three questions should only take a few minutes to complete, but they’ll add real value to our work redesigning how bug listings appear and function. Here’s the link if you’d like to take part

Last night, I came home from a meeting, kissed my wife, and was walking back upstairs when my coat started vibrating. I pulled my phone out to see that I was too late, and wasn't able to answer a phone call from my dad. I called him back, and here's a summary of the beginning of that conversation.

Me: "Hi dad."

Dad: "Hi"

Me: "Did you call? What did you need?"

Dad: "I did. I installed Ubuntu and now I'm trying to figure out how to install the driver for my video card."

Me: "Waaaaaaaaaaitaminute. There's a backstory here that I have to know before we go any further."

My dad is "technical". I remember as a little kid realizing how excited my dad was when he was installing Windows 95 the day it came out. I spent summers and school holidays making money at the company he worked for by being the floppy swapper when installing software. He was also the person who introduced me to the term "freetard". He's always been pretty resistant to free software, and sometimes for good reason (ever tried sending a document back and forth between on OpenOffice environment and a MS Office environment multiple times?). Last year for Christmas, my little brother Matt received a netbook that got infected before Christmas Day was over. I offered to put Ubuntu on it (something he wanted) but my dad was so resistant that he went out and bought a USB CD-ROM drive just so he could make sure Windows stayed on the machine.

For me, Ubuntu has never been about "So easy my mom can use it", but "So simple my dad doesn't have a reason not to use it".1

As the story unfolded, my dad had been exploring the idea of virtual machines for a client, and had installed Ubuntu in a Virtual PC environment on Windows 7 host. Unfortunately, his video would only give him 800x600, when his Windows XP guest would fill his dual-monitor setup easily. He expected this to be a driver issue (Virtual PC apparently doesn't have a driver pack for guests like VirtualBox and VMWare do). I found this article, but as I looked at the instructions, I thought "Holy crap. I wouldn't even do this." It became pretty clear that Microsoft Virtual PC was a pretty hostile environment to anything non-Windows.

At this point, my dad starts asking about the Windows installer he saw for Ubuntu (Wubi). Most of his concern centered around whether or not it was going to screw up his Windows partition (it doesn't). After a bit of talk about Wubi, we ended the phone call.

This morning, I get an email from him that says:

Installed 32-bit Ubuntu on my system last night (Wubi). Booted this morning and found that my USB keyboard/mouse combo is not recognized at Ubuntu login screen. No time to troubleshoot this morning before work and probably won’t spend a great deal of time on it, but wondered if you had any ideas of things I could try this evening.

Sounds like he's got a bluetooth keyboard/mouse combo that is having problems. It's not a happy ending just yet, but it's a giant step in the right direction.

The Chasm. Ubuntu is crossing it.

1 I gave my mom my old laptop, running Ubuntu, and connected to Landscape so I can manage it for her. She's not technical, and Ubuntu satisfies most of her computer needs (the only one that it doesn't satisfy is that she has no genealogy software that's compatible with the other software she uses).

Launchpad translations will be unavailable for around one hour, starting 10.00 UTC, on Tuesday 2011-11-29, to allow us to open the translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS).

We tried this last week but hit some problems. Rather than prolong the disruption, we decided to bring translations back online and delay the opening of Precise’s translations until after we’d fixed the issue.

While we’re opening Precise’s translations, Launchpad will not be importing translation files and the web interface for making and reviewing translations will be unavailable. This includes imports for translation uploads, but also imports from Bazaar branches.

Once this is done, imports will resume normally and any backlog should be processed quickly after that.

The information displayed with bug listings is often not what you want to see – you might not be interested in bug heat and want to see bug age, but it’s not there.  Looking at this problem, we’ve come up with a new beta feature: custom bug listings.  A lot of you have said that you’d like to be able to filter bugs in a way that works best for you. Hopefully this new functionality should help with this goal:

• You’ll be able to sort bugs by criteria such as name, importance and status.
• You can put them into ascending or descending order without having to reload the page.
• You’ll be able to save your preferred layout.

We’ve also redesigned how bug listings are displayed – fitting more information into each bug listing, and adding sort options such as bug age, assignee, reporter, and tags.

We’ve done some successful rounds of user testing and would love to hear your options on this great new feature. We’ve just released it into beta. To see it, you need to be part of Launchpad Beta Testers. To try it out, take a look at any bugs listing, like this one for Openstack.

Let us know how you get on with it: either report a bug (using the bug tag bug-columns) or join us on launchpad-users.

2011/11/28 update: we have temporarily suspended the beta, but we’ll have it back in the next day or so

Photo by Stephen Fulljames. Licence: CC-BY-SA.

Launchpad is ending support for multi-tenancy for branches and bugs to ensure that projects can manage the disclosure of private information. This is a fundamental change to how launchpad permits communities to share projects. Very few users will be affected by this change, but several communities will need to change how they work with private bugs and branches.

Launchpad currently permits users to create private bugs or branches that cannot be seen by the project maintainers, or the project’s other communities. This feature permits communities and companies to develop features in secret until they are ready to share their work with the other communities. This exclusivity feature is difficult to use, difficult to maintain, and makes Launchpad slow. This feature also contradicts the project maintainer’s need to be informed and to manage the disclosure of confidential information. When multiple parties can control privacy on a project, important information is lost.

While discussing the proposed changes with Launchpad stakeholders, I was surprised that most believed that the project maintainers could see the private bugs they were reporting — they wanted to collaborate, but the subscription-as-access mechanism is faulty. There are thousands of private bugs reported in Launchpad that cannot be fixed because the person who can fix the issue is not subscribed.

A contributing reason to drop support for private branches on project you do not maintain is that the feature is fundamentally broken. Privacy is inherited from the base branch. If you cannot access the base branch your branch is stacked on, you are locked out. Project owners can, and accidentally do, lock out contributors. You cannot subscribe someone to review the security concerns in your branch if that user does not have access to the base branch. Project contributors must subscribe each other to their respective branches to collaborate on a fix or feature.

This change is a part of a super-feature called Disclosure. To ensure that confidential data is not accidentally disclosed, project maintainers will be able to view and change who has access to confidential project information. Maintainers can add users to security or proprietary policies to grant access to all the information in the respective policy. You will not need to subscribe users to individual bugs or branches, unless you want to grant an exception to a user to access one confidential piece of information.

Launchpad translations was due to be unavailable from 10.00 UTC for around one hour this morning to allow us to set up translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS).

However, by about 10.15 UTC we encountered problems with data already in Precise’s translations. We weren’t sure how long it’d take to fix this issue, so decided it was better to reschedule the translations downtime for another day.

Sorry for the brief interruption to service. We’ll give you at least 24 hours notice before attempting this work again.

Tonight I decided to hack on a quick little webapp and use the opportunity to explore some tech that I've only gotten to tinker with so far. I wanted to build a small webapp with express, but I hate jade templating (I realize this may make me a javascript heretic). Since I'd rather just write HTML, I decided to use Mustache (plus, I have previous experience with Mustache).

The biggest problem with Node.js in general is that development is too fast. Blog posts get out of date really quick. I found a few blogs that show how to do it, but they're more than a year old, and at that point, it's almost worthless. Then I found stache. The docs there helped out to get me most of the way there. Here's what I did to get a basic express app using mustache.

First, install express and stache, and then create a new express app named myApp:

sudo npm install -g express stache
express myApp

Now change into the myApp directory. Edit app.js.

var stache = require('stache');

...import stache and then configure the app to use stache (you'll replace the existing jade config)...

app.set('view engine', 'mustache');
app.register('.mustache', stache);

In this case, I'm using a .mustache extension for my templates, and then passing stache to it as the handler for mustache templates.

In your views/ folder, you should see two files that the express command created by default: layout.jade and index.jade. We want to replace these with mustache stubs similar to these files. Let's start with layout.mustache.

<html>
    <head>
        <title>{{title}}</title>
    </head>
    <body>
        {{{yield}}}
    </body>
</html>

In stache, {{{yield}}} seems to be a special keyword for using the subtemplate. Make sure you remember all three suspenders around it, or you'll spend 20 minutes scratching your head and wondering why the HTML is being escaped (a behavior I hadn't ever used in mustache).

Now in index.mustache, we add the following:

<h1>{{title}}</h1>
<p>Welcome to {{title}}</p>

At this point, we've got a similar layout and template to the jade templates. The last thing left to do is change the data structure of the context we pass (since mustache wants the template context in a different format). Crack open routes/index.js and change the res.render call to look like this:

res.render('index', {
    locals: {
        title: 'Express'
    }
});

Now fire up the app with node app.js and hit /. Does everything work? Hooray! If not, uh, sorry. I'd be interested to know what didn't work, so I can fix the post.

In fact, since Node.js posts tend to get out of date, if this one does, please let me know and I'll update it accordingly.

Thanks to radix, exarkun & dash, my branch to pyflakes to warn about duplicate definitions of classes finally landed. I did the work a year ago as an outrage-powered, opportunistic fix after I saw a co-worker struggle with tests weirdly not failing (Turned out it was a huge test module and there was another class at the bottom with the same name). I'm very happy to see it landed.

For those who haven't been paying attention, official pyflakes development is now taking place on Launchpad as part of the divmod.org project. The trunk of that project now has the best version of pyflakes known to man.

pyflakes is the best static Python checker. It's fast, and has very few false positives.

Update: A couple of people have asked me about lp:pyflakes. It's dead. It died when the divmorg.org trac instance died ages ago. Don't use it. To get pyflakes or any other divmod project, use lp:divmod.org.

Launchpad translations will be unavailable for around one hour, starting 10.00 UTC, on Tuesday 2011-11-22.

During this time Launchpad will not be importing translation files and the web interface for making and reviewing translations will be unavailable. This includes imports for translation uploads, but also imports from Bazaar branches.

We are suspending the service temporarily to allow us to set up translations for the next Ubuntu release, Precise Pangolin (to be 12.04 LTS). Once this is done, imports will resume normally and any backlog should be processed quickly after that.

I not only hack on Launchpad, I use it everyday for my personal projects and for the 1100+ projects I maintain as a registry administrator. I see hundreds of pages each week where my first question is “what has this user or project done recently”? Launchpad cannot easily tell me that, and what it does say requires interpretation. I am very disappointed. I think the most important information I need to see on Launchpad pages is an activity log.  I want to see something like a wall or stream presentation to understand how a person contributes to projects, what kinds of contributions are made, and is a project vital or dormant? My disappointment is compounded by Launchpad’s karma mechanism. I happen to know that “karma” is a Sanskrit word meaning “action”, which is not how Launchpad users or engineers interpret it.

I not writing an argument to fix Launchpad’s karma. It is fundamentally corrupt. Discussions about it become bike shed arguments. I like the name “karma” because I know it’s essential meaning, and that is all that I want to preserve.

For your edification, the value attributed to your action in Launchpad was arbitrarily set by an engineer, then a mechanism “balanced” the number against values in rarely used features.  These rules were created to in an effort to bring fairness to actions. We know that some actions help more people than other actions, but what is happening is that someone was awarded a tremendous number of points for some action that will never help someone else. For example, You can work for a year to build and release an app to earn 10 points, then Launchpad slaps you in the face when I register a blueprint that will never be implemented…awarding me with 300 points. Launchpad is misinforming you and everyone else about the value of your contributions. The numbers will always be subjective. Stop reading those karma numbers, stop trying to raise them; you will not win anything for having a high score.

• I want to stop recording values for action, at the very least, never show them.
• I want to stop expending valuable CPU time balancing karma.
• I want to stop expiring karma.

Once we stop talking about value and fairness, we are free to add new kinds of actions that we want Launchpad to record. I hope to know that someone has registered a project, set the branch used as development focus, added a recipe to build it, and made an official release.

• I want to see a listing of all the things I register or change in Launchpad.
• I want to see a list of actions that someone has done today, this week, this month, this year, and maybe even last year.
• I want to filter the actions by to specific categories that pertain to bugs, code, or planning.
• I want see a link to the thing the action was about.

Ubuntu’s single sign-on service will be read-only for around 15 minutes starting at 10.30 UTC on the 17th November. At the same time, Launchpad will be offline.

This means that you should be able to log into websites that depend on the Ubuntu single sign-on service, but not make changes to your login or register a new account. It also means that anything involving Launchpad will be unavailable during that time.

Starts: 10.30 UTC 17th November 2011
Expected back by: 10.45 UTC 17th November 2011

We’re sorry for this service disruption. During this time we’ll be making a database upgrade.