Canonical Voices

What Something driven development talks about

Posts tagged with 'launchpad'


Learning a new language is fun…finding new ways of thinking about old problems and simple ways of expressing new ideas.

As a small learning project for Golang, I set out the other day to experiment writing a simple form field validation library in my spare time – as it seems there is not yet anything along the lines of Django’s form API (email thread on go-nuts).

The purpose was to provide an API for creating forms that can validate http.Request.Form data, cleaning the data when it is valid, and collecting errors when it is not.

The initial version provides just CharField, IntegerField and RegexField, allowing form creation like:

    egForm := forms.NewForm(

    if egForm.IsValid() {
        // process the now populated egForm.CleanedData() and 
        // redirect.
    } else {
        // Use the now populated egForm.Errors map to report
        // the validation errors.

The GoForms package is installable with `goinstall` or you can browse the goforms code on Launchpad (forms_test.go and fields_test.go have examples of the cleaned data and error). Let me know if you see flaws in the direction, or better ways of doing this in Go.

As a learning project it has been great – I’ve been able to use GoCheck for the tests, use embedded types (for sharing BaseField functionality – similar to composition+delegation without the bookkeeping) and start getting a feel for some of the subtleties of working with interfaces and other types in Go (this felt like all the benefits of z3c interfaces, without any of the overhead). Next I hope to include a small widget library for rendering basic forms/fields.

Filed under: golang, launchpad, testing

Read more

Thanks to the excellent work from the Launchpad Code team and others (James and William, to name just two), here’s a preview of how easy it will soon be to build a branch into published binaries in your PPA:

(I’ll update with the inline flash version once it’s been converted).

Filed under: launchpad

Read more

Having just been through the process of trying to involve people in open source design and development, Maris Fogels (another Launchpad engineer) and I took some time to document/reflect on the process. The strongest point that came out of the Q&A for me is the importance of voice conversations for iterating a design like this.

In this Q&A Michael shares his experience helping design the ‘Build Branch to Archive’ user interface:

Ubuntu is beginning to manage its source packages as Bazaar branches, as part of the DistributedDevelopment project.

One incredibly important activity for source packages is building them into binary packages that can be downloaded and installed. This spec explains how Launchpad can make this a wonderful experience.

Mars: Have you done any work designing user interfaces before this?

Michael: A little – we went through a similar process for the PPA redesign as
part of Launchpad 3.0. Prior to that, no, only your typical “Oh this
needs a UI – let’s just start creating the UI that *we* think the
target users will want.”

We had tried (in the Launchpad Soyuz team) doing something similar to
this design process previously (particularly, defining stories for an
interaction before coding, and getting feedback from the people
representing the target users), but no matter how hard we tried, we
weren’t able to get the time with them or any feedback, and so we
ended up implementing the design and landing it without their
feedback, which was a mistake – and a lesson learned which influenced
the process I used here.

Mars: What tools and resources did you use as you went through the project?

Michael: Balsamiq, wikis, email discussions and phone calls. Balsamiq was great
as a way to create UI’s quickly, modify them easily as we learned
more, share them for others to modify (I just pushed a bzr branch that
I kept up to date).

Mars: Was there a particular process that you followed?

Michael: Basically I tried to:

  1. Identify and describe the use-cases,
  2. Create mockups for each use-case,
  3. Get feedback from as many people as possible,

and then constantly update or add new use-cases and mockups as more
info came in. Looking back, it seems we went through three definite

Mars: How long did it take to design the page?

Michael: We just designed the main interactions to build a branch into a PPA,
which is 2 pages/overlays (they’ll be overlays if js is enabled). I
think the process (3 iterations above of gathering feedback,
phone-calls etc.) spanned 3 weeks, on and off.

Mars: Do you think the problem was well-understood before you started working on the user interface?

Michael: I think different people understood their own domains of the
build-from-branch interaction, and everyone had ideas about how the
other parts should work, but no, I don’t think any of us understood
the use-cases properly – particularly the issues around re-using
recipes in the UI – until all the ideas and feeback was collected and
put together.

Mars: Did the design of the interface change much as work progressed?

Old vs. New

Michael: Yes, quite a bit. Initially I had initially (mis)understood that we
needed to work with the current implementation of bzr-builder, but
after the first iteration, James Westby pointed out that bzr-builder
can be updated to support the requirements of the UI. This freed us to
consider sharing recipes in the UI in a way that would not have been
possible otherwise.

Collecting and expanding the use-cases naturally required updates to
the design. Also feedback and questions from various people helped to
keep refocusing on what people want to be able to do (for example,
“This recipe supports building to Ubuntu Lucid, Ubuntu 9.10 and Ubuntu
9.04″, while still allowing the person using the recipe to select just
the distroseries they want).

Mars: How did you get feedback on your designs? Was there a good response?

Michael: (Just an aside, there’s no ‘y’ there – they are really our designs, I
was just filtering and focusing the collected thoughts and ideas into
something visible).

So as above, email to the dev list, then irc chats, but the biggest
throughput of communication and feedback came via actual calls. It’s
just so much easier to clear misunderstandings on the spot if you walk
through the process together. I had multiple calls with 6 different
people, all which were invaluable.

Mars: Looking back, what was the most difficult part of the process?

Michael: (1) Getting real user input and feedback and (2) getting feedback from
professional designers.

With (1) the best I could do with the time I had was to communicate
with representatives of target users, which I think worked quite well.
And (2) was difficult mostly due to the nature of the problem for
build-from-branch. IMO it requires someone to sit physically in the
office and walk through the process with a designer, something I
couldn’t do, and hasn’t been done yet as far as I know.

Mars: What did you most enjoy about the work?

Michael: Bringing lots of ideas together from lots of people, clarifying the
different needs to different people to build a common understanding of
the issues involved.

But, to be honest, I am also enjoying getting back to soyuz coding. I
enjoy doing this kind of thing for a week or two, but after that I’m
always keen to get back to doing some coding.

I think I (and James?) also enjoyed the fact that we could work on
defining the interaction *before* anything had been coded. Too often
we get in there and just start coding something without thinking
through the use-cases properly (or even defining them), and it ends up
causing a lot of pain. Like everything, it’s a learning process.

Mars: Any final words for developers looking to try this themselves?

Michael: Sure, if you’d like a change of rhythm and enjoy facilitating
conversations and ideas, give it a go – it’s a great chance to
interact with other people in different areas and build your
understanding of what people actually want to do with your product.

Filed under: design, launchpad

Read more

Every time that I upgrade my operating system, I feel like I’m receiving a whole bunch of gifts from people I don’t know – which actually is what’s happening! As I learn more about the Debian and Ubuntu communities, and Launchpad (which I’ve been working on for the past year), I never stop feeling awed at the amount of effort that is being filtered through Launchpad (in both directions) in terms of bug-fixes, new packages, translations etc., into end-products that rock!

Having upgraded my netbook a few weeks ago, over the weekend I decided to upgrade my work machine to test the latest development release, Ubuntu Lucid, and the only difficult part of the process was having to install Windows XP to update my bios (because Samsung, the manufacturer of my work laptop, only provide bios updates as win-32 applications). Other than that, it’s been a joy seeing all the improvements (like the open-source nvidia support – a few clicks and my dual monitors worked perfectly, something I could only do previously with the proprietary drivers).

So, whether it is heard or not, I want to say a big thanks to the millions involved for the gift – my Lucid experience has been wonderful.

Read more

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