Eagle eyed readers may have noticed I have been talking a lot about [Ubuntu Accomplishments](https://wiki.ubuntu.com/Accomplishments) in the last few weeks…more so than usual… Well, to put it bluntly, my wife has been out of town for a few weeks and as such my evenings have had my husband time replaced with sitting in a darkened room, surrounded by empty Lean Cuisine trays, sipping on coffee, hacking to the sound-track of [Gov’t Mule](https://www.mule.net/home.php). If I had more hair, I really would feel like was 18 again. 🙂

Anyway, enough of the goings on at Castle Bacon, so what is the latest in the *Ubuntu Accomplishments* camp? Well, I have some fun things to share…

## 0.2. Like 0.1 But Twice As Awesome

We are now officially on the road to 0.2. We have decided to codename our releases after notable accomplishments in history, so the next release will be codenamed *lightbulb* and has a release date set for **Tues 12th June 2012**. You can see our targeted bugs lists ([daemon](https://launchpad.net/ubuntu-accomplishments-daemon/+milestone/0.2) : [viewer](https://launchpad.net/ubuntu-accomplishments-viewer/+milestone/0.2)) to get a feel for what we have yet to do.

While on the covers 0.2 might seem a small and incremental release, there has been a lot going on as we work to bring quality and precision to the code and the user experience.

## A New API

The 0.1 release was an important milestone for us. With over **230** people testing it and over **900** trophies issued, we were shocked pleased to see a surprisingly low number of bug reports coming in.

0.1 also helped us to identify the deficiencies in our current API, so we planned on maturing it significantly for 0.2. *Rafal Cieslak* did a stunning job implementing this work and the API is not only more mature and more consistant, but faster and better testable.

## Categories and Sub-Categories

As our accomplishments collection has started grow, it has been clear that we needed two features that were not in 0.1:

* Accomplishments should be able to appear in multiple categories (e.g *Set Up Your SSH key* should appear in both *Development* and *Launchpad* categories).
* Some (but not all) categories are too big and general and could benefit from sub-categories (e.g. *Games* could be divided into different genres or specific games).

To focus on this work I put together a mock-up and explored some different ideas of exposing this cleanly. This was the final design:

Over the weekend Rafal and I tag-teamed this one; *Rafal* built the support into the API and I built the front-end support for this in the client. It now looks like this:

In this screenshot none of the sub-categories are selected, so all Launchpad accomplishments are displayed. If you click one of the sub-categories it only shows those opportunities. This still needs some visual tweaks and polish, but it works quite nicely.

## Multiple Dependencies

Another lesson from 0.1 was that while most accomplishments only need one other opportunity completing first before it can be unlocked, some need more than one. As an example, *On Planet Ubuntu* requires you to have a SSH key and be an Ubuntu Member. As such, we built in support for multiple dependencies.

Now the client show which dependencies you have yet to accomplish before the opportunity is unlocked:

## Credit Where Credit Is Due

Ubuntu Accomplishments is a fairly big vision with lots of moving parts that will involve lots of contibutors. While a few of us hack on the core system, the real value in the system are the hundreds of accomplishments that could be exposed via it. These different accomplishments are available in grouped *Collections* and we expect many different people to contribute to different collections (e.g. the *Ubuntu Community Accomplishments* collection).

As such, we wanted to be able to expose these contributions to our clients. To do this we built support into the API for an `author` field in each accomplisment, and clients can now display this in their help dialog box. Here is the official client showing off the credits:

The default behavior is that it will show the contributors for each collection you have installed as well as the core system.

## New Accomplishments

One of the most pleasant outcomes of 0.1 was getting many different accomplishment contributions from the community. In total we have added the following to the *Ubuntu Community Accomplishments* collection:

* Accomplishments Contributor
* Attend LoCo Team Event
* Bug Squad Member
* Ubuntu Forums Council Member
* Ubuntu Forums Staff Member
* Imported an SSH Key
* Ubuntu Beginners Team Council Member
* Ubuntu Beginners Team Member
* Bug Control Member
* Ubuntu Forums Ubuntu Member
* Blog on Planet Ubuntu
* Ubuntu Cloak
* Signed Canonical Contributor Agreement
* Uploaded First Branch To Launchpad

Thanks to *Silver Fox, Michael Hall, Matt Fischer, Rafal Cieslek, Angelo Compagnucci*, and *José Antonio Rey* for these contributions!

**Would you like to contribute an accomplishment? See the [list of ideas](https://wiki.ubuntu.com/Accomplishments/AccomplishmentIdeas) and [get started](https://wiki.ubuntu.com/Accomplishments/Creating)!**

## Ubuntu Desktop Accomplishments

Do you know what is exciting about the following screenshot?

We fixed local accomplishments support in 0.2 (these are accomplishments on your computer such as sending your first email or installing your first application). We will be building out our own desktop collection and the above screenshot shows the very first accomplishment that is in the new [Ubuntu Desktop Accomplishments](https://launchpad.net/ubuntu-desktop-accomplishments) collection. This is still very much early days, but I am particularly looking forward to building this collection out: I want it to become one of the best ways of learning the many different things you can do on your computer in Ubuntu.

**UPDATE:** After I posted this I added support for local accomplishments to the *Accomplishment Information* app itself. See a short video demo below:

*Can’t see the video? [Click here](https://youtu.be/GDxpqX4Szl0)!*
## Spring Cleaning

In addition to this more visible work, there has been lots of other things going on as we clean up our code base and bring maturity and predictability to the project. This has included:

* Many improvement to the validation server: more resiliance, better logging of failures, and some performance improvements.
* As I wrote about the other day, we are now doing [automated daily testing of accomplishments](https://archivedblog.jonobacon.com/2012/05/14/precision-and-reliability-in-ubuntu-accomplishments/) as well as graphing growth.
* Improving our documentation and support for how people can contribute to the project as well as contributing accomplishments.

# Moving Forward

I just want to say a huge thank-you to everyone who has been participating in the project! I am looking forward to 0.2 as another important milesone. I will be following up in the next week about areas in which we are looking for help in the project that you might be able to contribute to.

If you are interested in joining us, be sure to [install it](https://wiki.ubuntu.com/Accomplishments/Installing), join `#ubuntu-accomplishments` on Freenode IRC, and join the [mailing list](https://launchpad.net/~ubuntu-accomplishments-contributors).

Recently I have been talking a little about [building quality and precision into Ubuntu Accomplishments](https://archivedblog.jonobacon.com/2012/05/14/precision-and-reliability-in-ubuntu-accomplishments/). Tonight I put one of the final missing pieces in place and I thought I would share in a little more detail about some of this work. Some of you might find this useful in your own projects.

Before I get started though, I just wanted to [encourage you to start playing our software](https://wiki.ubuntu.com/Accomplishments/Installing) and for those of you that had a crash when using certain languages with the *Accomplishments Information* viewer, I released a `0.1.2` update earlier that fixes this.

## Automated Testing

As we continue to grow the [Ubuntu Community Accomplishments](https://launchpad.net/ubuntu-community-accomplishments) collection it is going to be more and more complex to ensure all of the accomplishments are working effectively every day; we are already at 28 accomplishments and growing! What’s more, the community accomplishments scripts work by checking third-party services for data (e.g. Launchpad) to assess if you have accomplished something. These external services may change their APIs, adjust how they work, add/reduce services etc, so we need to know right away when one of our accomplishments no longer works and needs updating.

To do this I wrote a tool called *battery*. It works by reading in a test that is available for each accomplishment that feeds the accomplishment validation data that should succeed and also data that should not validate. As an example, for the *Ubuntu Member* accomplishment the data that succeeds is an existing member’s email address (such as my own) and the test for failure is an email address on Launchpad that is not a member. The original script requires the user’s email address to assess this accomplishment, so *battery* tests simply require the same types of information, with data that can trigger success and failure.

This approach allows us to test for three outcomes:

* That the valid email address returns exit code `0` (the script ran successfully and the user is verified as being an Ubuntu Member).
* That the invalid email address returns exit code `1` (the script ran successfully but the user is not an Ubuntu Member).
* If the script has an internal issues and returns exit code `2`.

The way this works is that battery includes a customized version of the general `accomplishments.daemon` module that we use for the backend service. In the code I override the back-end module and load a custom module. This way the original accomplishment script does not need to be modified; instead of `get_extra_information()` calling the back-end daemon and gathering the user’s details, the custom module that comes with *battery* instead has it’s own `get_extra_information()` that gets returns the test data so *battery* can run the tests.

Originally *battery* only output textual results, but this would require us manually running it. As such, last night I added HTML output support. I then enabled *battery* to run once a day and automatically update the HTML results. You can see the output [here](https://213.138.100.229/battery/).

There are a few important features in this report other than a list of all the accomplishment test results:

* It shows the failures: this provides a simple way for us to dive into the accomplishments and fix issues where they occur.
* It shows which tests, if any, are missing. This gives us a TODO lists for tests that we need to write.

While this was useful, it still required that we would remember to visit the web page to see the results. This could result in days passing without us noticing a failure.

Tonight I fixed this by adding email output support to *battery*. With it I can pass an email address as a command-line switch and *battery* will generate an email report of the test run. I also added *battery*’s default behavior to only generate an email when there are failures or tests are missing. This prevents it generating results that don’t need action.

With this feature I have set *battery* to send a daily “Weather Report” to the [Ubuntu Accomplishments mailing list](https://launchpad.net/~ubuntu-accomplishments-contributors); this means that whenever we see a weather report, something needs fixing. 🙂

One final, rather nice feature, that I also added was the ability to run *battery* on one specific accomplishment. This is useful for when we are reviewing contributions of new accomplishments; we ask every contributor to add one of these simple tests, and using *battery* we can test that the script works for validation success, validation failure, and script failure with a single command. This makes reviewing contributions much easier and faster and improves our test coverage.

## Graphing

Something Mark Shuttleworth discussed at UDS was the idea of us building instrumentation into projects to help us identify ways in which we can make better decisions around how we build software. This is something I have also been thinking of for a while, and to kick the tyres on this I wanted to first track popularity and usage of Ubuntu Accomplishments before exploring other ways of learning how people contribute to communities to help us build a better community.

Just before we [released version 0.1](https://archivedblog.jonobacon.com/2012/05/01/first-ubuntu-accomplishments-release/) of Ubuntu Accomplishments, I created a little script that does a scan of the validation server to generate some statistics about the number of daily new users, the daily number of new trophies issued, and the totals. Importantly, I only count users and trophies, and I am only interest in publishing anonymized data, not exposing someone’s own activity.

To do this my script scans the data and generates a CSV file with the information I am interested in. I then used the rather awesome [Google Charts](https://developers.google.com/chart/) API to take my CSV and generate the Javascript need to display the graph. Here are some examples:

While this is not exactly instrumentation, it got me thinking about the kind of data that could be interesting to explore. As an example, we could arguably explore which types of contributions in our community are of most interest in our users, how effective our documentation and resources are, which processes are working better than others, and also some client side instrumentation that explores how people use Ubuntu Accomplishments and how they find it rewarding and empowering.

Importantly, none of this instrumentation will happen without anyone’s consent; privacy always has to be key, but I think the idea of exploring patterns and interesting views of data could be a fantastic means of building better software and communities.

At the Ubuntu Developer Summit last week I delivered a plenary on the Tuesday called *Accomplishing An Awesome App Developer Platform* that tells the story of how the Ubuntu app developer platform enabled me to build the [Ubuntu Accomplishments](https://wiki.ubuntu.com/Accomplishments) system that I designed with Aq. The presentation walks through the story of how we designed the system, and how everything was available in Ubuntu to create the client, back-end daemon, validation server, and desktop integration. I think it is a good example of how Ubuntu can help app devs to create interesting ideas and apps.

I thought this might be handy to have on YouTube, so I re-recorded it today, and you can see the video below:

*Can’t see it? [Watch it here](https://youtu.be/dDXlh5rE1Eg)!*

If you want to create your own application for Ubuntu, be sure to visit [developer.ubuntu.com](https://developer.ubuntu.com).