Canonical Voices


A few weeks ago at our Launchpad BuildFromBranch sprint, I gave a brief overview of the process I use when doing a significant design change – whether it’s a code architecture or UI design (hint: don’t try to do a presentation after flying for 26 hours with two kids).

The main point that I was keen to communicate is how important it is to involve people and get early feedback. Launchpad bugs provide a great way to invite this involvement too, as you’ve already got many of the interested people already subscribed, and if you add information early other people – such as the person who created the bug – have an opportunity to clarify and contribute to the design or solution.

As a result of our sprint, we’re now focusing on how we can provide the best user experience for automating the process of building code into installable packages that will be updated on peoples machines the next day. In particular, we want to enable easy setup of daily builds for projects, allowing people who like to live on the edge and contribute QA time to their favourite open-source projects (building on the excellent work of bzr-builder).

To encourage involvement in this process, I’m trying a combination of relevant email lists for discussion, phone calls where helpful, and a wiki page that I try to keep up-to-date with the current status of those discussions. The aim being that anyone can read the wiki page and, in addition to seeing the current UI mockups, can see all the significant questions that have been brought up already. We’ll see how it goes…

Read more

When hacking on Launchpad’s soyuz application – and creating tests to verify that your new functionality works, you’ll often need sources or binaries published in very specific scenarios.

This demo of using Launchpad’s SoyuzTestPublisher for testing shows you how you can setup those scenarios using the Soyuz Test Publisher which – as the name suggests – was created for this exact reason (by Celso).

To save you typing (or squinting if you can’t view the hi-res version of the demo), the python script for the demo is available also.

Read more

After reading lots of reviews, I went out and bought an EeePC 1008HA (‘Seashell’) netbook last weekend and installed the alpha Ubuntu 9.10 Netbook Remix… and everything just worked. Very impressed.

I haven’t decided whether I’ll stick with the Netbook Remix launcher interface, or just go for a cut-down desktop with Gnome-do launcher, but eitherway it’s lovely to use.

Read more

During the Ubuntu Developer Summit there were a number of discussions around how debian operating systems, such as Ubuntu, can best enable people to add trusted software archives to their computer (see the blueprint AptURL-policy for Ubuntu Karmic).

As far as I understood, there are three competing issues:

  1. There is currently no easy way for a person to evaluate whether a software archive might be trustworthy – other than trusting a centralized white-list,
  2. Installing software directly from a web-browser click should be minimized and discouraged,
  3. There should be an easy way for people to share (and maintain) software that they develop

I’m only going to discuss the first point here. DoctorMo has some great mockups demonstrating gpg-keys being used for identity and software trustworthiness, but a few people have commented on the problem of confusing the “web-of-(identity)-trust” that gpg keys currently provide with some sort of general trust that the identified person will be responsible with my computer.

Reading all the comments there leaves me wondering whether we should stop using the phrase “web-of-trust” and instead use the more verbose “web-of-identity-trust” to avoid confusion – even though it doesn’t roll off the tounge so easily. I love Martin’s idea – the concern is real – but am wondering how it could be implemented in a decentralised way.

Of course, it would be possible to add this as an api feature of Launchpad – my feeling is that Launchpad should be a source of the social value of an archive (ie. user ratings etc.), but not necessarily a source of this fundamental trust-relationship.

So here is an idea: what if the repository contained this infrastructure itself, such as a directory of meta-information, ‘identities-who-trust-this-archive’, which contained signed trust files ‘trust-of-canonical.txt’ or ‘trust-of-joe-bloggs.txt’. The text could just be a standard paragraph, or be modified by the signer if needed. The installer on the operating system would allow the user to check the trust text etc. Could this work? Can anyone see any issues? (hmm… revoking trust would not be possible without revoking the key used to sign the document?)

Read more

For over 6 months now I’ve been working on – collaborative development for open source software – using Python (Zope). It’s been an unreal experience seeing various testing strategies on such a large code-base, but the two things I miss the most while developing on launchpad are:

  1. The ability to do outside-in development properly – as is possible with ruby’s Cucumber project (although, this could be used, but it’d be adding yet-another-technology to the stack – I haven’t tried pyCucumber, but it doesn’t look too active), and
  2. Something similar to rspactor – allowing tests to be run automatically as I edit files, and reporting them via the OS’s notification system.

But trying to communicate exactly what I mean by that to people who haven’t used rspactor or Cucumber is kind-of tricky, so here’s a video demo’ing how I’d love to do inside-out development on Ubuntu…

Read more

Voidspace just released Mock 0.4.0 – an update to the excellent Mock library which brings a few conveniences and easier patching of module and class-level attributes.

This makes tests using mocks easier to read, for example inside a test case:

self.assertEquals(my_mock.my_method.call_args,     (('goodbye',),{'hello': False}))

Can now be written as:

my_mock.my_method.assert_called_with('goodbye', hello=False)

Check it out!

Read more

Since working with RSpec over the past 6 months – a Behaviour-Driven Development framework for ruby – I’ve been wondering if there’s anything comparable in Python (my preferred tool for development!). One of the things I love about RSpec is the ease with which Mock objects can be used to keep tests focused.

While there are a number of mock libraries around for Python most don’t result in particularly readable test code. But I was pleasantly suprised to discover Michael Foord’s Mocking and Testing utilities.

A simple example: I’ve got a Django application hosted on Google AppEngine and say I want to write a simple test to verify that my view does require the user to be logged in with their Google account and if not, redirects appropriately – but I don’t want to have to manually log a user in, or even use the Google api as part of my test. Here’s a snippet showing how easy this is with Mock:

from mock import Mockfrom google.appengine.api import users

class MySpecialView(TestCase):

    def setUp():        """ Create the required mocks for the view tests """        # Mock the get_current_user method of the google users api        users.get_current_user = Mock()

        # Create a mock user that we'll pretend is logged in        mock_user = Mock()

        # Just for readability, save the special app-engine login url as         # an instance variable        self.url = reverse('my-special-view-name')        self.login_url = "http://testserver/_ah/login?continue=http%%3A//testserver%s" % self.url

    def test_logged_in_user_can_access_page(self):        """A logged in user should not be redirected to the login page"""        # Set the return value for the mocked         # get_current_user method:        users.get_current_user.return_value = mock_user

        response = do_request()

        # Make sure the mock method was called        self.assertTrue(users.get_current_user.called)

        # And the redirect did not take place, but the         # normal template was rendered...        self.assertTemplateUsed(response, 'myapp/overview.html')

    def test_anonymous_user_is_redirected_to_login(self):        """ An anonymous user should be redirected to the login page"""        # Set the google api's get_current_user method to return None        users.get_current_user.return_value = None

        response = self.do_request()

        # Make sure the mock method was called        self.assertTrue(users.get_current_user.called)

        # And that the redirect took place... note we can't use        # the normal assertRedirects due to the app-engine specific        # login url.        self.assertEquals(response.status_code, 302)        self.assertEquals(            response['location'],            "http://testserver/_ah/login?continue=http%%3A//testserver%s" % self.url        )

Easy! Thanks Michael. The Mock object has lots of other goodies of course (such as auto-setting all the mock-methods from the real object, testing for call parameters etc.).

Read more