Canonical Voices

Posts tagged with 'developers'

Canonical

Have you submitted your app for the App Showdown contest? With just under one week to go, there’s still time to enter and have the opportunity to win a Nexus/Meizu device with your app running on the handset. Deadline for submissions is Wednesday 9th April, 2014.

Here are the details once again:

The contest is open to everyone. The four dedicated categories that you can enter:

  1. QML: original apps written in QML or those with a combination of QML and JavaScript/C++

  2. HTML5: original apps written using web technologies, be it pure HTML (and CSS/JavaScript) or with platform access using Apache Cordova

  3. Ported: apps ported from another platform, regardless of the technology used

  4. Chinese apps: apps in this category will have to be original and specific to China and the Chinese culture. They will be judged by three native experts in our jury.

To enter the competition and get further information click here.

Winning entries will be announced by Canonical once the judging process has been completed – anticipated to be end of April 2014.  Good luck!

Read more
Daniel Holbach

I talked many times about getting involved with developing Ubuntu and how it can seem daunting and that there’s much to learn. When I talked to contributors who had reached the critical point where they understood what they can do, who they can talk to and how the processes roughly work, most of them said that three things helped them to get to the point:

Code review

Today I want to talk about code reviews. It’s probably the most straight-forward way to learn by osmosis: you easily pick up conventions, distinctions which are made and which processes to follow.

Everybody has to go through code reviews, no matter which team they are in, which company they work for or when they joined the project. Up until a point they get their developer application approved and get upload rights.

This is the reason why code reviews in Ubuntu are so important and why we should constantly strive for timely replies and decisions on review requests.

Sponsoring Queue

The sponsoring queue is reviewed by developers with upload rights. Sometimes it’s very easy to approve a request and upload the package, sometimes it takes a bit longer, especially when you have a comment ping-pong between the reviewer and the patch author.

We came up with a number of points in our documentation which should help keeping the queue manageable:

For Bugs fixing small details, you could do the following:

  1. Ask the contributor to forward the patch upstream.
  2. Open an empty upstream bug task.
  3. Mark the Ubuntu task as ‘Fix Committed’.
  4. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as “Work in Progress”. (Be sure to tell the contributor to reverse the process.)

This will get the review item off the list for the time being and once we can import the code from upstream, it will get fully closed.

We also get requests which are not suitable for the current release period. In this case you could:

  1. Let the contributor know that the patch is not suitable for the current release period.
  2. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as “Work in Progress”. (Be sure to tell the contributor to reverse the process.)
  3. Subscribe yourself to the bug report.
  4. Milestone the bug to ‘later’.
  5. Visit https://bugs.launchpad.net/people/+me/+bugs/?field.milestone%3Alist=196 once the new release opens and upload the fix.

This are just some points which help to keep things on the queue relevant.

Patch Pilots

From the Bazaar team we borrowed the scheme of “patch pilots”. Here’s how they explain how it works: “The word pilot is in the sense of a maritime pilot: we help patches come through congested waters safely in to harbour. The main thing to watch is the bzr active reviews page in Launchpad. When you’re piloting, put some concentrated effort into helping people have a good and satisfying experience contributing to Bazaar. Just how you do that is up to you.

Instead of trying to review each and every bit in the queue – sometimes there are packages you know less about and where you can’t make a decision for example – you try to help nudge the patch along. You help to talk to upstream about it, try to find somebody who can make a decision, etc.

Canonical engineers with upload rights who work on Ubuntu are expected to spend an hour per week on the Ubuntu sponsoring queue, so everybody’s on the hook for having a piloting shift 4h every four weeks. This usually works much better, as you have an extended period of time where you do nothing else. Current patch pilots can be seen in the #ubuntu-devel channel topic.

Up until now I mostly noticed Canonical engineers who did piloted. If you have upload rights and are interested, let me know and I can add you to a preliminary schedule, so you get a reminder mail and you can try it out and see if you like it.

Please all help making this work even better. :-)

Read more
Laura czajkowski

Martin Packman

Laura:  What do you do on the Launchpad team?
Martin:  I’m on the newly created Blue squad, and we’re on the nebulous task of maintenance at present. I’m also on loan doing some juju development work.

Laura: Can we see something that you’ve worked on?
Martin:  You can see everything I’ve worked on. Well, all the things where I’ve had the convenience of using launchpad rather than having to send patches by email.

Laura: Where do you work?
Martin:  From home like most of the other developers in Canonical. I’m only a few hours away from the London office, but haven’t been there since the relocation.

Laura: What can you see from your office window?
Martin:  A weeping birch, and whatever feathered things perch atop. Sky, often blue, generally grey. Houses on the other side of the road. This time of year, swift acrobatics.

Laura:  What did you do before working on the Launchpad team?
Martin:   Bazaar! Which is still a pretty key part of how Launchpad works. In between I worked on a cloud api proxy, which has sensibly been dropped in favour of just using the native openstack api.

Laura:  What did you do before working at Canonical?
Martin:  Whatever came up, computer support and some development work.

Laura: How did you get into free software?
Martin:  Mostly from using it, having it break horribly, and getting the urge to make the code actually work.

Laura:  What’s more important? Principle or pragmatism?
Martin:  Principle is more important, otherwise you compromise all the way to  the other side. But you need some pragmatism to get anything done at all.

Laura: Do you/have you contribute(d) to any free software projects?
Martin:  I’ve tended to submit changes for anything I use heavily at the time, and to various bzr related projects. I’d use this space to hector some maintainer who’d been sitting on a patch for ages, but everyone’s been organised of late.

Laura:  Tell us something really cool about Launchpad that not enough people know about.
Martin:  It actually works pretty well in lynx!

Laura:  Is there anything in particular that you want to change in Launchpad?
Martin:  You mean apart from making it work better in lynx? I’d like bug search to suck less.

Read more
Daniel Holbach

Jono blogged about the importance of application developers to Ubuntu earlier and I wanted to echo some thoughts and add some of my own.

I have been in the Ubuntu Developer camp for most of Ubuntu’s life as a project, so the mindset of “App developers? Why don’t they just set up an open source project and get it packaged?” or “Apps? We have packages.” is what I have heard a couple of times already and is what I would probably have answered some years ago myself.

The power of the Open Source community and having open projects is immense. We all have seen it many times: a thought, a great idea, some dedicated contributors, good communication and a friendly community can achieve amazing things. This happens every single day.

We are well aware of how things work in the Open Source world and we have recently seen the success of our great work: millions of users, who have never dabbled in Open Source before, today enjoy Ubuntu (or other pieces of Free Software) and rely on it. We have managed to reach out to an entirely new demographic and continue to grow our user base.

With new demographics there are new expectations and new responsibilities. Consider my father for example. He follows what’s going on in the Ubuntu world, but will occasionally point out to me that an app he’s interested in buying does not exist for Ubuntu. The last I remember him talking about was a good language learning course.

With new form factors and devices running Ubuntu (you know, TVs, tablets, phones, watches, cars, coffee machines, hoverboards and the like), there are going to be thousands of useful helper tools out there which might not be available for Ubuntu yet. Add to that the growing number of content providers (magazines, books, maps, music, etc.) which users yet can’t easily get “for Ubuntu”.

This is the world we are looking at today and it becomes obvious that apps should be a first-class citizen in Ubuntu. Don’t get me wrong. I’m all for making everyone who shows the slightest interest in working on Ubuntu itself an Ubuntu developer and member of our community, also because I feel that everyone who is part of this has a lot to gain, personally and for their particular project. It just shouldn’t be a strict requirement because it won’t scale.

A number of teams have been working very hard on making seamless apps in Ubuntu a reality and that’s just great to see. It’s a hard problem to solve because it involves so many different important pieces. Keep up the good work everyone!

At UDS I’m definitely going to (among other sessions, I’ll blog about later on) attend these sessions to see what we can do about making apps in Ubuntu more exciting and something that just works:

Hope to see you there!

Read more
Stuart Langridge

Merry Christmas from the Ubuntu One team! As announced at UDS in Orlando in November, the Ubuntu One team have been working on a project to allow application developers to sync data to Ubuntu One, and we’ve now reached the tech preview stage. Here’s the details.

U1DB is a database API for synchronised databases of JSON documents. It’s simple to use in applications, and allows apps to store documents and synchronise them between machines and devices. U1DB itself is not a database: instead, it’s an API and data model which can be backed by any database for storage. This means that you can use U1DB on different platforms, from different languages, and backed on to different databases, and sync between all of them.

Data sync is an essential part of what we want to offer with Ubuntu One. We already offer file sync, and that’s also part of our developer story (the APIs for file sync and music streaming are documented at https://one.ubuntu.com/developer/); U1DB is designed to offer data sync. Some information in your personal cloud is best done as files: your music, your photos, letters written in Word, things you want to back up. However, applications work with data: contacts, metadata about your files, todo lists, preferences and settings, and most stuff an application works with. We’re building U1DB to allow app developers to work with the same data on every platform and in every language; to save data and sync it between devices without having to manage that themselves.

We’ve been working on U1DB enough to have a working implementation, and now we want to get it out to all of you. We’re calling this a tech preview — it’s a working version of U1DB, with the intention that developers look at it and play with it and start working with it. We’re very interested in hearing your thoughts on the current implementation, the API, and its use in applications. Give us your thoughts in comments here or on the U1DB mailing list at https://launchpad.net/~u1db-discuss or just join us at #u1db on freenode for a chat. The tech preview is of the reference implementation — this is written in (and to be used from) Python on Windows or Ubuntu or anywhere Python runs, and it’s where we work on the algorithms and API used across all U1DB implementations. This tech preview contains the library to work with U1DBs from Python, and an example server and client implementation — U1DB is peer-to-peer syncing, so it’s perfectly possible to run your own server and sync to that, and this tech preview has an example server to play with.

You can see (early) documentation of U1DB, the API, and example usage at http://people.canonical.com/~aquarius/u1db-docs/. We are also working on Vala and JavaScript implementations of U1DB: you can find the Vala implementation at http://launchpad.net/shardbridge, and we plan to build implementations of U1DB for iOS (Obj-C on SQLite) and Android (Java on SQLite) in the future.

The tech preview is mostly about getting input into the product so we can make sure we build something that is useful for people. We also have listed a number of open questions on detailed technical subjects which we’d like to hear opinions on from people who would be interested in using U1DB or writing a new implementation for another platform or language or database backend. Give us your thoughts on these too!

Open Questions

  1. In general, creating an API that is conceptually portable across many languages has some difficulties. For example, currently, the reference implementation provides a Document object, where doc_obj.content is a JSON string of the document content. This means that app developers using the Python API need to json.loads(doc_obj.content) to edit the content of a Document. Should a Document be addressable as a dictionary? This is an obvious thing to do in Python, but it does not necessarily make sense across many platforms; how would you envisage a Document object looking in C? In Java? In Objective C? In your choice of language?
  2. Revision IDs for a U1DB Document are currently quite verbose, but this makes them easy to read (and makes it easier to debug issues). Should we use a less readable but more compact format for these version vectors?
  3. Ubuntu One’s U1DB server will have a direct HTTP API, so that apps can retrieve and store data directly in the cloud without syncing. The HTTP API is also used for syncing U1DBs to Ubuntu One. What form of authorization should be used for this HTTP API, both for syncing and for direct access? Other Ubuntu One services use OAuth 1.1; should we examine OAuth 2, or other alternatives, or is it more important to be able to use the same tokens and auth libraries as other Ubuntu One services?
  4. Indexing is a tricky issue. Letting users provide code to do the indexing is tricky and creating a reasonably thorough DSL is a lot of work. We’re currently taking the DSL route; index expressions are basically a domain-specific language for querying a u1db. Is there a middle ground?
  5. Index expressions can not only name fields but also apply transformation functions to them. For example, lower(fieldname) stores the lowercased contents of a field as an index key, and splitwords(fieldname) splits the contents of the field on whitespace and stores each item as an index key. What are the basic transformation functions we should support? What are the use cases for your proposals? What do apps need?
  6. Each peer in replication has a replica uid, a name for that device. Should those ids be just uuids (as they are currently)? Can we use hostnames? Can we detect a db copied across machines? How about a db copied locally? Is identifying these important?

These questions are the stuff we are discussing currently. Any comments on these or other issues not covered here will be most welcome.

So, to get started, see the quickstart guide at http://people.canonical.com/~aquarius/u1db-docs/, and let us know about your ideas for applications using U1DB and your thoughts on the API!

Read more
Joshua Hoover

Stuart LangridgeLast week we told you that we launched our App Developer Program. Today we’re pleased to announce our first Ubuntu One App Developer event. Our App Developer Program is open to everybody and on Thursday 1st of September we’re inviting any interested developers to an evening of talking Ubuntu One apps and a drink or two with our futures architect, Stuart Langridge, at Manchester Metropolitan University in the UK from 7pm. If you’re interested in building apps for mobile, web or the desktop to work with or use Ubuntu One’s features, or you want to bring Ubuntu One to a new platform, or you just want to hear about what’s going on, come along!

It’s a chance to bounce around some ideas, ask questions and chat with like-minded folks so come and join us. Please let us know you’re coming at http://www.eventbrite.com/event/1981804631

We’re really looking forward to seeing you there on the 1st and hearing what imaginative Ubuntu One app ideas are out there…and helping you make them! To find out more about the Ubuntu One APIs we’ve already published, for file syncing and music streaming and data storage, take a look at  https://one.ubuntu.com/developer/.

Read more
Steve George

To go with the Software Business Development role we also opened up an Ubuntu Developer Relations Advocate job as the two areas are closely related. Business Development is focused on working with developers at a business level, fundamentally creating a revenue-generating relationship.  Developer relations is focused on working with developers at a technical level, providing resources, assistance and community.  Both roles could be speaking to the same people in a small developer shop, but the focus of the conversation is different and we need both to help developers be successful.

Fundamentally, the objective of developer relations is to provide a focus for evangelising the platform and assisting developers as they develop software for Ubuntu. One thing to clarify is that the type of development we mean here is ‘developing applications that run on Ubuntu‘, with the desired outcome being that we increase the range of applications available to Ubuntu users. So this is different to a lot of our other community relations work which is aimed at contributors to Ubuntu. Another point is that our focus is on commercial software developers since we believe that it’s important to create a sustainable ecosystem around the platform: that doesn’t exclude FOSS since Open Source can be commercial – although being realistic I expect that most of the commercial software will be proprietary.

Developer relations is a mixed role, it’s partially to evangelise the platform and attract developers, and partially assisting developers by giving them resources and a community. I group the responsibilities into three areas – attracting, enabling and enthusing. By attracting we mean communicating and showing how great the Ubuntu platform is for developers. This covers the Ubuntu distribution but also developer enabled technologies such as Unity, UbuntuOne and distribution through the Software Center. To enable developers we need to provide resources they can use to develop on Ubuntu explaining the tools and technologies that are part of the platform and how to use them.  A key difference between Ubuntu and other platforms is that we aim to be participatory and transparent. So the most important element of ‘enabling’ is that we want to create a Developer Community: we’re focusing our attentions on developer.ubuntu.com which you can think of as the equivalent to IBM’s Developer Works or Apple’s Developer Center. This is a real connector role so a key part will be working with the wider world, and coordinating internal Canonical teams and exciting everyone so that we’re all working together to the common goal.

Finally, there’s lots of discussion whether Developer Relations should sit within an engineering department or within a marketing organisation, which depends on your objectives. In our case the focus is increasing the range of software that is available on Ubuntu which is a long-range business development strategy aimed at strengthening the platform, so we’ve chosen to put Developer Relations within that team so we can have the best connections. Either way at heart it’s a technical role that is all about communications by helping developers get the most from the platform – being their advocate.

We know the objective and the strategy, how to drive it forward is open territory that will need leadership, energy and tenacity. If you have experience in Developer Relations and some of the thoughts above chime with your own ideas then hop across to the Ubuntu site where you can read the job description and apply!


Tagged: Canonical, developers, Linux, Ubuntu

Read more