We have very exciting and challenging plans for the future of the new web+mobile Ubuntu One team (more on this soon), and we’re looking for an exceptional web engineer to join us.

The summary for this position is:

We are looking for an exceptional engineer to work on Ubuntu One’s web infrastructure with a proven track record for exceptional problem solving and integration into third-party systems. This person should help the team design, build, and deploy web and mobile applications with a high degree of quality and passion. If you’re the type of person who gets excited about delivering cutting-edge technology to hundreds of thousands of users, in a lean and friendly environment, we are looking for you!

If this sounds like you, check out the full job description and send us your CV!

While we slowly ramp up to release mobile phone contact sync, using my own contacts as test data I realized that once I had merged my phone’s address book and Thunderbird’s address book, I had quite a few contacts duplicated due to them having different names with different information in them. So I had one of those “you know what would be cool…?” kind of moments, and started working on a feature that would let me merge contacts on the web, saving me hours of copy-n-paste.
A few weeks later, an initial pass at that feature has rolled out!  Yay agile software development!

There are a few tweaks to the contacts interface, and you will see a new option:

So, for example, let’s pretend you have 2 contacts that are the same person but have an extra name in one of them, one of them has his phone number, the other, his email:

and

We go to our new merge feature and select both of them:

Finally, we get a preview of what this will look like:

Done!

Plans for the future are:

- Allow conflict resolution when the contact has 2 fields that are the same but have different values
- Allow editing the contact in the merge preview
- Allow merging from the contacts page instead of a separate page
- Use this same mechanism when conflicts arise in couchdb merging contacts
Also, contact syncing from thousands of mobile phones will be opened up for a public alpha very very very soon. Stay tuned!

All projects in Canonical have a strong focus on testing. From all of them, I think Bazaar ranks the highest on obsesiveness on testing. As a drive-by contributor, it always felt like a very high entry barrier, and deterred me from getting into complicated changes. It was only after I bit the bullet and got into more complicated changes (in Launchpad, actually) that I understood that tests where my best friends ever. It’s a safety net against myself, and actually lowers the barrier, because I don’t need to know about the rest of the code base to make a change, tests will tell me if I break something (seemingly) unrelated.

On the more extreme side, there is test driven development (TDD). You write the tests first, watch them fail, and then start producing the code that will get them to pass. Having co-authored bzr-upload with the TDD-obsessed bzr developer, Vincent Ladeuil, I thought that if I was going to add a new feature, I may just as well try it (again).

It rocked.

I set up the test, my carrot, and the task went from “start poking around code” to “fix this problem”. With the test written, it became very clear what parts of the code I needed to change, and how the feature had to work.

The results?  in one hour, I implemented a feature that lets you ignore specific files on upload. With tests.

During UDS Vincent and I made sure we shared a room so we could talk a bit about what we wanted for the future of bzr-upload.

To ensure we didn’t loose any of the conversation, he took notes and sent them to me, so now I’m passing them on for those of you interested in contributing or just knowing what features are in the pipeline.
* Create a .bzr-upload-ignore file that ignore any action for which one the paths matches an ignore regexp. Use the working tree version by default, fallback to the versioned one otherwise

* New command: “bzr upload-files FILES” to allow uploading individual files. Upload the specified files if no uncommitted
changes exist, –force overrides the uncommitted changes check.

* New command: “bzr upload-check”. Walk the remote site ensuring that every file still has the same content that the local version –restore optionally restore the remote content to the local value. Optionally for remote sites implementing ssh and providing an md5 binary, the check can be implemented by comparing the local and remote md5 avoiding the full downloads.

Following up on my last post about user testing icons, it has been incredibly successful!  We’ve had over 100 responses, and are now going through the data to put together a summary. I will post information on our findings as soon as we finish the work.

In the mean time, Charline Poirier, who is in charge of user testing in our team, has created another survey with 5 more icons to help us get more data. If everyone could give this survey another spin, and create some networking effects to help spread the survey to non-Launchpad users, it would be tremendously helpful to us. Here’s the link: http://www.surveymonkey.com/s.aspx?sm=6iwthaIT4FwPCsMPa1EDEA_3d_3d

We’re trying to improve the icons we have in Launchpad so they’re more usable across different cultures and types of users, and our first step is to do some user testing on our current icons.

The Canonical User Experience team has set up a survey to gather information on how users see our icons, so if you have a few spare minutes (it’s very quick!), please take the survey and pass it on to other people, especially if they don’t use Launchpad, as they will be less biased.

Survey is available at: http://www.surveymonkey.com/s.aspx?sm=8hXmjrmFS7TmQCjh7jJB_2bQ_3d_3d

As promised, Launchpad has been fully open sourced (as opposed to the initial idea, nothing has been held back). Get it now, fix your favorite pet bug, and improve tens thousands of people’s experience.

Mark Shuttleworth really deserves a lot of praise for this bold and brave move, open sourcing not only the code, but all  it’s history. It’s a fantastic day today.

Update: yes, fully means including soyuz and codehosting, Mark has decided to release everything. The whole history is there.

See the loggerhead page:

A few days ago, the project ohloh announced they where starting to support bazaar imports.

It’s a pretty cool website, so I’m very happy they now support projects I actually work on

I kicked off an import of Loggerhead’s history, and in less than a day, it was up and working.

Kudos to the ohloh team!

A week ago I started going through my blog’s logs, and realized that I’d had a jump in visits from Google. Digging a little bit deeper into it, I realized that a lot of people seem to be searching for “working at canonical” phrased in different ways. From what I can gather, it’s split up into two groups: people who want to find a job in Canonical, and people who are considering a specific role and want to know what it’s like.

So, I thought it would be useful to provide information for the dozen of people who land here every day 

If you want to work for Canonical, check out the employment page, it always has the latest job offers: http://webapps.ubuntu.com/employment/
Among many other things, my team is currently looking for awesome people to join the User Experience Team, the coolest place to be today 

As for what it’s like to work at Canonical, here’s my take on it:
At this point, it’s been a little over five months since I started working full time, although I was doing some contracting work before that, and I’ve been around the Ubuntu and bzr community for ages, so I already knew a lot of the people before joining.
One of the coolest things for me is that the way most of the company works, is basically the same as your typical open source project: mailing lists, irc, distributed, and filled with passionate people. If you have an open source background, the transition should be pretty seamless. Coming from other companies may take a little bit of getting used, but you know how it is, “your mileage may vary“.
The Ubuntu-like atmosphere where everybody is extremely nice and respectful seems to span across the whole company as well. This was especially surprising to me considering that everyone is astonishingly smart, and have done amazing things I had read (and still do!) on news sites for years. My experience is that when too many smart people are together, it’s a much more cut-throat competitive environment. Here, it is not. You could sit down and have a fantastic and interesting dinner with anyone in the company (I’ve shared meals with dozens of different people, and it’s held up true every single time).
On the technical side, all the teams are constantly revising and improving work flows and tools, pushing towards the cutting edge by adopting all kinds of lean and agile development strategies, while still being very much test-driven. What can be more appealing to a developer than that?
Finally, there are so many interesting projects being worked on at the same time, it’s often very hard to keep up with what’s happening. Personally, I believe that the balance between open source development and projects developed in-house as services or for third parties, plays a very big part in making everything happen so fast a two-hundred-and-something people size the company. It’s amazing how so many people are payed to work full time on directly on free software, directly interleaved with the community.

So, as you can guess, my recommendation is that if you ever get the chance to work for Canonical, take it, it will almost certainly be a fulfilling experience.