Canonical Voices

Posts tagged with 'work'

Michael Hall

Well, we did it.  The six members of the Canonical Community Team stayed awake and (mostly) online for 24 straight hours, all for your entertainment and generous donations.  A lot of people gave a lot over the last week, both in terms of money and time, and every one of you deserves a big round of applause.

Team Insanity

First off, I wanted to thank (blame) our fearless leader, Jono Bacon, for bringing up this crazy idea in the first place.  He is the one who thought we should do something to give back to other organizations, outside of our FLOSS eco-system.  It’s good to remind us all that, as important as our work is, there are still things so much more important.  So thanks, Jono, for giving us a chance to focus some of our energy on the things that really matter.

I also need to thank the rest of my team, David Planella, Jorge Castro, Nick Skaggs and Daniel Holbach, for keeping me entertained and awake during that long, long 24 hours.  There aren’t many people I could put up with for that long, I’m glad I work in a team full of people like you.  And most importantly, thanks to all of our families for putting up with this stunt without killing us on-air.

Upstream Awesomeness

Before we started this 24-hour marathon, I sent a challenge to the Debian community.  I said that if I got 5 donations from their community, I would wear my Debian t-shirt during the entire broadcast.  Well, I should have asked for more, because it didn’t take long before I had more than that, so I was happily sporting the Debian logo for 24 hours (that poor shirt won’t ever be the same).

I wasn’t the only one who put a challenge to the Debian community.  Nick made a similar offer, in exchange for donations he would write missing man pages, and Daniel did the same by sending patches upstream.  As a result, the Debian community made an awesome showing in support of our charities.

All of our donors

The biggest thanks, of course, go out to all of those who donated to our charities.  Because of your generosity we raised well over £5000, with the contributions continuing to come in even after we had all finally gone to bed.  As of right now, our total stands at £ 5295.70 ($8486).  In particular, I would like to thank those who helped me raise £739.13 ($1184) for the Autism Research Trust:

And a very big thank you to my brother, Brian Hall, who’s donation put us over £5000 when we only had about an hour left in the marathon.  And, in a particularly touching gesture of brotherly-love, his donation came with this personal challenge to me:

So here it is.  The things I do for charity.

Read more
Michael Hall

The Canonical Community Team is running a week long charity fundraising drive, capped by a 24-hour live work hangout.  We all chose a different charity, and will be promoting it and encouraging donations during the week.  I chose to support the Autism Research Trust, and wanted to share a little bit about why.

Those in the open source community, or who are computer scientists, engineers or programmers, will be no strangers to Autism. Autism, and it’s associated spectrum, affect 1 out of every 88 children according to a recent study. In our geek community, the number is likely even higher than that.

Many of you may notice my blog’s banner, or read the post from when I put it up. When my first child was 2 years old, he was diagnosed with something called PDD-NOS (Pervasive Developmental Disorder, not otherwise specified), which is basically the catch-all “we don’t really know what’s wrong” category in the Autism spectrum. We were told this by a neurologist who then left the room without explaining what it was, what it would mean for our son, or what we were supposed to do about it. It was scary as hell.

What made things worse is that there is very little that anybody actually knows about Autism. Nobody knows what it actually is, or what causes it. There is no known cure or medicine to treat it. Our son needed our help, and we literally didn’t know how to give it. When he turned 3 years old he could speak only a handful of words. He was smart though, he seemed to understand everything, but we couldn’t communicate with him, or him with us. It was extremely frustrating for everyone.

The only thing that’s been proven to help children with Autism is early intervention. We were lucky, he was diagnosed at a much younger age than most kids. We found local speech and occupational therapy centers, and for over a year he went to these 3-4 times a week. Local organizations like Autism Speaks and the Central Florida Autism Institute helped us find what worked for him, because every child is different.

Early intervention has given our son his future back.  He still struggles with the effects of Autism, it doesn’t ever go away, but he’s learned how to work around it, and we’ve learned how to work around it.  That is why I have chosen Autism research as my charity for the Community Team 24-hour marathon, because there are still millions of children who need this intervention, and millions of parents struggling to understand how to help them.  And every dollar, pound or euro you give is likely to change somebody’s life.

Read more
Michael Hall

Back in San Francisco, during UDS-Q, we had a discussion about the need for better online documentation for the various APIs that application developers use to write apps for Ubuntu.  The Ubuntu App Showdown and subsequent AppDevUploadProcess spec work has consumed most of my time since then, but I was able to start putting together a spec for such a site.  The App Showdown feedback we got from our developers survey highlighted the need, as lack of good Gtk documentation for Python was one of the most common problems people experienced, giving it a little more urgency.

Fortunately, Alberto Ruiz was at UDS, and told me about a project he had started for Gnome called Gnome Developer Network (GDN for short).  Alberto had already done quite a bit of work on the database models and GObject Instropection parsing needed to populate it.  The plan is to use GDN as the database and import process, and build a user-friendly web interface on top of that, linking in external resources like tutorials and AskUbuntu questions, as well as user submitted comments and code snippets.

Now that the spec is (mostly) done, we need to get together some developers who can implement it.  There will be a lot of front-end work (mostly HTML, CSS and Javascript), but also enough backend work (Python and Django) to keep anybody occupied.  I’ve created a Launchpad project for the site, and a team you can join if you’re interested in helping out.

The GDN code and some very basic template are already available. You can get the code from bzr with bzr branch lp:ubuntu-api-website and following the instructions in the DEVELOPMENT file.  I’ll also be running a live App Developer Q&A Session at 1700 UTC today (September 19th), and would be happy to help anybody get the code up and running during that time.

Read more
Michael Hall

More than a few, actually. As part of our ongoing focus on App Developers, and helping them get their apps into the Ubuntu Software Center, we need to keep the Application Review Board (ARB) staffed and vibrant. Now that the App Showdown contest is over, we need people to step up and fill the positions of those members who’s terms are ending. We also want to grow the community of app reviewers that work with the ARB to process all of the submissions that are coming in to the MyApps portal.

ARB Membership

Two of the existing members, Bhavani Shankar and Andrew Mitchell, will be continuing to serve on the board, and Alessio Treglia will be joining them. But we still need four more members in order to fill the full 7 seats on the board.  ARB applicants must be Ubuntu Members, Ubuntu Developers, and should create a wiki page for their application.

ARB members help application developers get their apps into Software Center by reviewing their package, providing support and feedback where needed, and finally voting to approve the app’s publication.  You should be able to dedicate a few hours each week to reviewing apps in the queue, and discussing them on IRC and the ARB’s mailing list.

If you would like to apply, you can contact the current ARB members on #ubuntu-arb on Freenode IRC, or the team mailing list (app-review-board at lists.ubuntu.com).  The current term will expire at the end of the month, so be sure to get your applications in as soon as you can.

ARB Helpers

In addition to the 7 members of the ARB itself, we are building a community of volunteers to help review submitted packages, and work with the author to make the necessary changes.  There are no limits or restrictions on members of this community, though a rough knowledge of packaging will surely help.  This group doesn’t vote on applications, but they are essential to helping get those applications ready for a vote.

The ARB helpers community was launched in response to the overwhelming number of submissions that came in during the App Showdown competition.  Daniel Holbach put together a guide for new contributors to help them get started reviewing apps, and you can still follow those same steps if you would like to help out.

Again, if you would like to get involved with this community, you should join #ubuntu-arb on Freenode IRC, or contact the mailing list (app-review-board at lists.ubuntu.com).

Read more
Michael Hall

For the past several week, David Planella, Jono Bacon and I have been drafting a spec that proposes a radically different approach to getting desktop applications into the Ubuntu Software Center.  Now, there’s nothing that annoys me more than somebody proposing radical changes for no reason, and without giving much thought as to how it would actually be done.  So I wanted to write down, here, both the justification for this proposal, and the process that we went through in drafting it.

The current process splits submissions between closed-source and commercial apps, which get reviewed by a paid team of Canonical employees, and non-commercial open source apps which are reviewed by the Application Review Board (ARB).  The ARB consists of 7 volunteers from the Ubuntu community, who will review the source code and packaging of each submission.  Members of the ARB are very smart, very dedicated members of the community, but they also have paying jobs, or are pursuing higher education (or both), so their time is a limited resource.  The ARB process was meant to provide an easier route for app developers than the more rigorous process that distro packages must follow to get into the Universe repository or Debian’s archives, and in that respect it has been a success.  But even with eased requirements, there was a limit to how many apps they could manually review.

The recent App Developer Showdown competition, which resulted in more than 140 new apps being submitted through our MyApps portal, showed us the limits of our current process.  We even drafted a number of new volunteers to help review the incoming apps, and Daniel Holbach provided both instructions and programs to help speed things up.  It took us weeks to give an initial review to all of the apps.  Almost two months later and we still haven’t been able to publish more than a quarter of them.  Android has seen over 9,000 new apps in a month, and I can only assume that iOS has seen similar numbers.  If we can’t even scale to handle 140, something has to change.

The spec didn’t get written down all at once from some grand design. It grew organically, from a short list of general goals to the massive text it is today.  In fact, the spec we ended up with is quite a bit different than the one we initially set out to write.  We took our list of goals and started asking the obvious questions: what work is involved, who will it impact, and what could (will) go wrong?  We could have just throw these questions out to other people, but those people are busy and have their own things they are trying to do.  Before we could ask anybody else to spend time on this, we had to put in some effort ourselves.

So we answered as many of these as we could between the three of us, and those answers changed our spec accordingly.  That raised more questions, and we repeated the process, updating the spec and finding more questions that needed to be answered.  In the process we gained both a clearer idea of what we wanted, and a better understanding of how to get there.  By the time we had answered as many as we could on our own, our list of goals had transformed into a longer list of implementation items and who would most likely be doing them.

At that point, we had a more specific direction and a pretty good idea of how much work it would take.  Having done as much of the leg-work as we could, we took the implementation items, and any unanswered questions we still had, and started talking to the people who would have to implement it.  Unsurprisingly, these conversations had an even bigger impact on the spec, and it underwent some pretty drastic changes as we tried to nail down the details of the implementation.  Just like the previous stage, we iterated over this one multiple times until we had as many details as we could collect, and answered all of the questions that we could.  At the end, we had the massive spec we announced today.

But this is just the next stage, the spec isn’t final.  The three of us have answered as much as we could, the teams who will implement it have answered as much as they could, now we’re introducing it the community to gather even more details and answer even more questions.  The feedback we get in this stage will go back into the spec, and very likely generate new questions and feedback, and we’ll iterate through this stage too.

The final spec, whatever it ends up being, isn’t going to be perfect, and it’s not going to make everybody happy.  But we can be confident that is will be a very well thought out spec, it will be a very detailed spec, and it will allow us to accomplish the goals we set out to accomplish at the beginning of it all.  It will help make Ubuntu a much more attractive platform for application developers, it will make Software Center more useful to developers and users alike, and it will make Ubuntu a better OS for all of our users.

If you have any questions or comments on the spec itself, please send them to the ubuntu-devel mailing list, not the comments section here.

Read more
Michael Hall

You can watch the App Developer Q&A live stream starting at 1700 UTC (or watch the recording of it afterwards):

Questions should be asked in the #ubuntu-on-air IRC channel on freenode.

You can ask me anything about app development on Ubuntu, getting things into the Software Center, or the recent Ubuntu App Showdown competition.

Read more
Michael Hall

Due to the popularity of the Ubuntu App Showdown Workshops, I plan to start holding a weekly Q&A session for all Ubuntu app developers using the same format: A live Google+ Hangout with IRC chat.

The first of these will be Wednesday of this week, at 1700 UTC (6pm London, 1pm US Eastern, 10am US Pacific).  Because it will be an On-Air hangout, I won’t have a link until I start the session, but I will post it here on my blog before it starts.  For IRC, I plan on using the #ubuntu-on-air channel on Freenode, though again the exact details will be posted the day of the session.

So bring your questions about developing apps for Ubuntu, packaging an submitting them to the Software Center.  If I can’t answer your question myself, I’ll help you find someone who can.

Read more
Michael Hall

As part of the Ubuntu App Showdown I started on a small project to provide a nice GUI frontend to Quickly.  While I was able to get it working and submitted before the contest deadline, I unfortunately didn’t have the time to make it do everything I wanted.  Since the end of the contest, however, I was able to spend a little more time adding some nice features to it.

Project Management

The majority of the work has gone into Quickly-Gtk’s project management.  Some of this was implemented already, such as the ability to switch the “current” project. But internally it was all kind of a mess of code to track that.  So I replaced all of that with a ProjectManager class that will store both the list of projects Quickly-Gtk knows about, but also keeps track of which project is “current”.  This class also implements Observer design pattern to let other parts of the code know about changes to both the list of projects and the current project.  This made it easy to, for example, display a notification on the screen whenever the current project was changed, regardless of whether it was changed in the window, the indicator, or from a Zeitgeist event.

Zeitgeist event monitoring

The other big development was integrating Quickly-Gtk with Zeitgeist.  For those that aren’t familiar with it, Zeitgeist is an event log that tracks all kinds of user activities and system events.  Applications can read past events or monitor them as they happen.  I wanted Quickly-Gtk to be smart enough to switch to a project as soon as the user started working on it, without requiring the user to make the switch themselves.  To do that, I set a Zeitgeist monitor to listen for file system events in any of the saved project directories.  I also set it to watch for the user viewing the project’s Launchpad page.  If any of those events happen, Quickly-Gtk will automatically make that the current project.

The future of Quickly-Gtk

While I was able to get a lot done with Quickly-Gtk, the underlying Quickly API and command line really weren’t designed to support this kind of use.  However, as a result of what we learned during the App Showdown, Didier Roche has begun planning a reboot of Quickly, which will improve both it’s command-line functionality, and it’s ability to be used as a callable library for apps like Quickly-Gtk.  If you are interested in the direction of Quickly’s development, I urge you to join in those planning meetings.

 

Launchpad Project: https://launchpad.net/quickly-gtk

 

Read more
Michael Hall

Following yesterday’s announcement of the Ubuntu Webapps project, I really wanted to find a way to try it out on a website.  I chose my personal blog (this one) as my guinea pig.

Since this site is powered by WordPress, it seemed that the best way to add Ubuntu Webapps integration was to make a plugin.  Now I’m not a big fan of writing WordPress backend code, not only is it PHP but I’ve found the API documentation lacking and the actual API implementation a bit of a mess.

However, after only a few hours of work (90% of which was spent trying to get the WP API to work), I had a very basic plugin that would export all my published pages to the Unity HUD.  If you have already installed the Ubuntu Webapps preview, you should have been asked if you want to integrate this site already.  If you did, you will get this in your HUD:

The code is licensed under the AGPLv2, and can be branched from my bazaar branch.

To install it, just copy the ubuntuwebapps.php file into your wp-content/plugins/ directory, then activate the plugin from the WP admin.  And remember this is 0.1 code that is mere hours old.  You have been warned.

Read more
Michael Hall

As you’ve probably heard already, Ubuntu is running an App Developer Showdown competition where contestants have three weeks to build an Ubuntu app from scratch.  The rules are simple: It has to be new code, it has to run on Ubuntu, and it has to be submitted to the Software Center.  The more you use Ubuntu’s tools, the better your chances of winning will be.  This week we ran a series of workshops introducing these tools and how they can be used.  It all seemed like so much fun, that I’ve decided to participate with my own submission!

Now 2 our of the 6 judges for this competition are my immediate co-workers, so let me just start off by saying that I will not be eligible for any of the prizes.  But it’s still a fun and interesting challenge, so I’m going to participate anyway.  But what is my entry going to be?  Well in my typical fashion of building tools for tools, I’ve decided to write a GUI wrapper on to of Quickly, using Quickly.

Before I started on any code, I first wanted to brainstorm some ideas about the interface itself.  For that I went back to my favorite mockup tool: Pencil.  I knew I wanted to cover all of Quickly’s functions, both for creating projects and working on them afterwards.  I also wanted something that would keep track of my projects, so I wouldn’t have to find where they are on my disk whenever I wanted to hack on them.

Now, I’ve never been a fan of GUI builders.  Even back when I was writing Java/Swing apps, and GUI builders were all the rage, I never used them.  I didn’t use one for Hello Unity, and I wasn’t planning on using Glade for this project either.  But after Jono’s fantastic workshop session about Glade, I decided to give it another chance.  I found that I was able to get a basic UI built and running in very little time.  I’m still struggling with some, and there’s a point where you need to switch from Glade to code, but all in all it has saved me a significant amount of time.

Quickly also saved me a large amount of time, both in creating the project and adding things too it.  Being able to add an Application Indicator to your app by just running “quickly add indicator” is amazing.  From there is was a simple matter to build a menu based on available Quickly commands and tie them in with callback functions.

But the part I like the best about this app so far, is that it’s useful even when you’re not using it.  Most of the time you spend developing a Quickly app is going to be in some other application, such as your code editor of choice, Glade or something.  Thanks to Unity’s HUD, and the fact that it’s smart enough to check Indicator menus in addition to the focused application’s menus, you can call your Quickly commands any time, simply by tapping ‘Alt’ and the command you want to run.  It’s like having Quickly integrated into all of your other tools.

And thanks to the developer tools available in Ubuntu, I was able to accomplish all of this in only a few hours of work.

Now it’s very, very far from being complete.  For instance, the “active” project is hard-coded to my quickly-gtk working directory, it can’t start a project yet, or support commands that take optional arguments or user input.  But in a short amount of time I was able to go from a mockup to a working layout and even some functional code.  It even packages successfully, something I found out quite by accident when I selected “Share” from the indicator menu and ended up with a package in my PPA.

Building an app in 4 hours then accidentally building a proper package and uploading it to a PPA, who’d have thought we’d ever make it that easy?  I hope you all are having as much fun and success in your showdown applications as I am.

Read more
Michael Hall

Last week we introduced a new ‘Download for Ubuntu’ campaign for upstreams to use on their websites, letting their users know that the app is available in Ubuntu already.  We event generated a list of targeted upstreams we wanted to reach out to in order to spur the adoption of these buttons.  What we didn’t go into much detail about why upstreams should use them.  I hope to remedy that here.

It’s easy

Let’s just get that out of the way, this won’t take a significant amount of work on the part of an upstream.  It’s just a one time change to a website.  You don’t even need to change it every cycle, since the buttons point to the App Directory entry for the application itself, not any specific version of it.

It makes installing your app more appealing

The button isn’t just another way of getting your app, it also tells the user that it will install correctly, all of it’s dependencies are available and will be installed, everything is configured to work with their system, and they will get be getting updates and security fixes to it through a mechanism they already use and trust.  In short, it’s a promise of a good user experience (which I’ll admit we don’t always live up to, more on that below).  Telling 20 million users (and growing) that your app is safe and easy to install is surely worth a few pixels on your website.

It’s good social exposure for your app

By sending users to the App Directory, instead of just immediately installing, new users get to see what others are saying about your app through the ratings and reviews (which will be mostly positive, because your app is awesome right?)  of other Ubuntu users.  Not only does this tell your users that other people like your app, but it’s also telling them that they can add their own ratings and reviews, which will in turn boost your app’s standing.  More reviews leads to more users, which leads to more reviews, it’s a great positive feedback loop.

Users will be looking for it

Not right now, obviously, since we just started this campaign.  But as more upstreams adopt the new button, it’s going to be one of the first things Ubuntu users will be looking for on your website (for all the reasons mentioned above).  With a majority of website visitors leaving in less than a minute (according to a lazy Google search), the promise of a quick and easy install might just be the difference between a new user and a lost opportunity.

This campaign benefits everybody: end users, upstream developers and, yes, Ubuntu too.  So let’s improve these ties, together.  If you’re an upstream, you can copy/paste the following HTML snippet directly into your website (replacing {{pkgname}} with the name of your application’s package in Ubuntu).  If you want to reach out to an upstream developer, please add them to our list so we know who’s contacting them, and what the status is.

<a href="https://apps.ubuntu.com/cat/applications/{{pkgname}}/">
 <img src="http://developer.ubuntu.com/wp-content/uploads/2012/06/downloadonubuntubutton.png"  title="Download for Ubuntu" alt="Download for Ubuntu button" width="122" height="49" />
</a>

Now I know we can’t always give the best user experience possible (see, I told you I’d get to that).  Sometimes our packagin isn’t quite right, or the default configuration of your app is sub-optimal.  Our six month release cadence and package freezes mean that rapidly developing applications will often be out of date in our main repositories.  We’ve taken on a lot of work by distributing apps the way we do, and even though we’re a very large community, it’s still hard to get every package right.  Luckily, you’re not powerless here, if you spot problems with the way we distribute your app, or you need to get a newer version out to Ubuntu users, you can do something about that.

Package fixes

Even though our process locks applications to the version in the archives for that particular release of Ubuntu, we will still allow changes to the packaging itself.  So if we’ve done something wrong on our end that is giving your app a hard time, we’ll fix it and make that available to all of your Ubuntu users as a Stable Release Update.

Backport newer versions

A six-month release cycle means that every Ubuntu release has relatively up to date versions of applications, at least compared to distros that have a longer cadence.  But for rapidly developed applications, where new versions come out more frequently than that, this means their packages can become outdated quickly.  And with the five year lifetime of our LTS releases, most packages will get to be stale by the end.  That’s why we have a special repository just for backporting new versions of packages to stable releases of Ubuntu. And starting with 11.10, this repository is enabled by default.

In order to have your application backported to a stable release, it first has to be accepted into the current development release.  If your new version was in Debian’s unstable repository at the beginning of the development cycle, chances are it’s already there.  If it’s not in Debian you’ll need to submit your package to be included in the development release.  Once it’s there, you can request that it be backported to one more more stable Ubuntu releases.  You can use the requestbackport command line tool (from ubuntu-dev-tools package) to automate much of the process, or if you’re not running Ubuntu simply file a bug to start the request.

Read more
Michael Hall

It’s no secret anymore, we want apps in Ubuntu.  Big app, small apps, shiny apps, cute apps,  apps that play a catchy tune while avian avengers explode porcine poachers.  You name it, we want it in Ubuntu.  And we need your help getting them.

It doesn’t matter if you’re not a programmer, there are plenty of programmers in the world, and they’re making all kinds of really cool apps that you want, that I want, that we all want.  But they’re not putting them in Ubuntu, and that’s why I need your help.

You see I’m just one person, and with David Planella we’ve got, well, two people.  Now, two people can find an awful lot of apps on the internet, that’s true.  Especially when that’s part of your job.  But even still that would hardly amount to a drop in the bucket of apps that have been made.  And we’re not happy with just a drop in the bucket, are you?

No, of course you’re not.  So right about now you’re probably thinking of a bunch of cool apps you’ve used or seen or read about recently (and if you weren’t before, you certainly are now, aren’t you).  And you may be wondering how you can help us get them into the Ubuntu Software Center.   Well wonder no more my friend, because we have a Trello board.

Not terribly impressive, I’ll admit, but it is terribly useful.  You see, David and I will be contacting each and every one of these app developers about submitting their apps to the Software Center, and moving the card from column to column as that conversation progresses.  And while we have a nice long “To Contact” list right now, it’s not going to stay that way without your help.

We’re opening up this board to anybody who wants to add new upstream apps for us to contact.  All you need to do is follow David’s instructions on this wiki page to get started.  It’s quick, mostly painless, and best of all you get to start telling us what to do (at least a little bit).

But wait! There’s more!  Didn’t I say we were just two people?  There’s no way we could contact all these upstreams on our own.  And hey, you’ve just signed up to join the Trello board (you did do that, right?), which means you can start contacting them too, and moving their cards, and make Ubuntu even better.  We’ve even created a reusable email template that you can use for that initial contact.

If you contact one of the app developers, make sure you move their card to the “Conversation Started” column, assign it to yourself, and add comments about who you contacted and any other relevant information.  This of course requires that you joined the board, which you definitely should do if you are going to be working on this.  And please note that is says “Started”, not “Finished”.  Once you contact the developer, keep that line of communication open and help them through the process of submitting their app.  If you get to a point where you can’t help them, let David or I know and we’ll be happy to pick it up.

Read more
Michael Hall

With the Ubuntu TV port to Unity 3d currently underway, the project team is looking towards future feature development and they want the community’s input on what the product should do.  Specifically they are gathering a list of use cases that consumers might want in a Smart TV in five key areas:

  • Local/networked media
    • How should Ubuntu TV interface with media on the local device or local network?
  • Online media
    • How should Ubuntu TV find and play online media?
  • Control from another device (smartphone, tablet etc.)
    • How can you use your existing phone or table to interface with your TV?
  • Broadcast (LiveTV, PVR)
    • How should Ubuntu TV list, store and playback live TV?
  • Applications
    • What types of applications would be useful on a TV?

So here’s your chance to get involved and be heard, go to this wiki page and start adding your use cases to the list.

 

 

Read more
Michael Hall

Expanding on my previous post calling for pkgme backend contributors, here’s a list of the backends we would like to see added, and who in the community you can contact for help in making them. If you can act as a mentor for one of these backends, please say so in the comments and I will add your name to the list.    For any questions about pkgme itself, and what options are available to backends, your best bet is to ask James Westby (james_w) in the #pkgme channel on freenode.

Qt/qmake

QMake is a Makefile-generator. It uses information that the application author puts into a project file to build the Makefile for a project. A qmake backend would need to either use qmake to extract the information requested by pkgme, or parse the same project file that qmake uses in order to provide that information.

Information about qmake: http://qt-project.org/doc/qt-4.8/qmake-manual.html

Help Contact: Angelo Compagnucci

Flash

Flash applications can be packaged for Ubuntu by wrapping them in a GTK window that contains a Webkit browser widget, and an index.html file for it to load that embeds the given flash file.

The Quickly Flash template currently does much the same thing. To do the same in pkgme, you will need to pass the necessary wrapper files to the extra_files request. extra_files should return a JSON object where the key is the file path relative to the root of the target application, and the value is the contents of that file.

Help Contacts: Michael Terry and Stuart Langridge

HTML5

A backend for an HTML5 application would also require wrapping the target application in a GTK window with embedded Webkit widget. Only instead of creating an index.html, you would just point the Webkit widget to the target application’s HTML files.

Help Contact: Didier Roche

Java

The Java backend would need to parse ant’s build.xml files to extract information about the target application or an already built jar file’s manifest.

Help Contact: James Page

Read more
Michael Hall

pkgme is a small utility created by James Westby, its purpose is to create a Debian package for any unpackaged applications.  It’s currently used when applications are submitted through the Ubuntu Developer Portal as tarballs, inspecting the contents of the application to determine how to build a package from it.  In order to support many different types and configurations of application, James built pkgme to support any number of different backends.

Currently there is support for apps using Python and Distutils, apps compiled by cmake, and apps written in Vala.  But there are still many, many applications out there that aren’t covered by these backends, including Qt apps, HTML5 apps, Flash apps and more.  That’s where you, dear contributor, come in.

UPDATE: Here is a list of desired backends and mentors to help you with them.

But I don’t know how to create packages!

That’s okay, you don’t need to know how to make packages to create a pkgme backend.  It already knows how to make packages, what it doesn’t know is where to find the information it needs to do that.  This is what backends are, just one or more small scripts that extract enough information about a project to let pkgme do its thing.

Ok, I’m interested, how do I start?

First of all, get a copy of the latest pkgme code from its bazaar branch in Launchpad:

bzr branch lp:pkgme ./pkgme

Then, create a VirtualEnv environment to install it into:

virtualenv ./env

Then, install it into the Virtualenv:

source ./env/bin/activate
cd ./pkgme
python setup.py develop

Now you’ve got a working pkgme installed and running in your virtualenv. You can leave your virtualenv by running ‘deactivate’.  Time to get started on your backend!

Where do I put my new backend code?

Since we’re going to submit your new backend to the pkgme branch, we can just create it there:

cd ..
mkdir ./pkgme/pkgme/backends/<your backend name>

Great, now I have an empty Backend, what do I put here?

The first thing your backend needs is a ‘want’ file.  You see, in order for pkgme to know which backend it should use on any particular application, it needs to ask every backend how much they want it.  It does this by executing a script named ‘want’ in each backend.

Your want file is executed from the target application’s directory, so in your script ./ will be the root of the target application’s directory.  This lets you script easily browse through the files in the application to determine how well it can provide packaging information for it.

In order to tell pkgme how much your backend wants to handle the target application, your ‘want’ file simply needs to print a number to STDOUT.  The backend with the highest number is the one pkgme will use.  These are the suggested ranges for your ‘want’ value:

  • 0 – no information can be provided about the project (e.g. a Ruby backend with a Python project).
  • 10 – some information can be provided, but the backend is generic (e.g. Ruby backend).
  • 20 – some information can be provided, and the backend is more generic than just language (e.g. Ruby on Rails backend).
  • 30 – some information can be provided, and the backend is highly specialized.

Now I have what I want, what do I do with it?

Once pkgme has chosen your backend to use against an application, it will call one or more scripts from your backend to get information about the application.  As the backend author, you can choose to provide separate scripts for each piece of information, or you can provide just a single script called ‘all_info’ that will provide everything.

Lots of scripts

For separate scripts, you will need to provide an executable in your backend directory for each of the pieces of information that pkgme might request.  Each script should print that information to STDOUT, or exit with an error if it can not provide it.

Just one script

However, if looking up bits of information one at a time is a time-consuming task for your backend, you can do it all in one shot.  If you want to do that, then the only script you need is one called ‘all_info’.  When this script is called, it is also given a JSON list on STDIN.  This list contains the keys for all the pieces of information that pkgme needs from your backend.  As output, this scripts needs to print a JSON dictionary to STDOUT.  This dictionary should contain a key for each of the fields sent as input, along with its corresponding value.  If your backend can’t provide a value for one of those fields, it should be left out of the dictionary.

You can test your new backend by switching to the directory of a project your backend is made to support, and running:

pkgme

Make sure your virtualenv is still activated, or pkgme won’t be found. If everything works, you should have a ./debian/ directory in the application’s root folder.

Hurray, my backend works.  Do you want it?

Of course we want it!  What a silly question.  And it’s already in your local branch of pkgme too!  Well, it’s in the directory anyway, you still need to add it to the workingset:

cd ./pkgme/pkgme/backends/
bzr add <your backend name>

Then commit your changes and push them back to Launchpad:

bzr commit -m "Added backend for <your backend name>"
bzr push lp:~<your lp username>/pkgme/add-backend-<your backend name>

Then head on over to https://code.launchpad.net/pkgme, click on your new branch name, and then click the “propose for merging” link.  Fill out the description of what your backend adds, and submit it.  From there it will get reviewed by one of pkgme’s maintainers, and either get merged into the main branch, or sent back to you for fixes.

Read more
Michael Hall

Sweet Chorus

Juju is revolutionizing the way web services are deployed in the cloud, taking what was either a labor-intensive manual task, or a very labor-intensive re-invention of the wheel  (or deployment automation in this case), and distilling it into a collection of reusable components called “Charms” that let anybody deploy multiple inter-connected services in the cloud with ease.

There are currently 84 Juju charms written for everything from game backends to WordPress sites, with databases and cache servers that work with them.  Charms are great when you can deploy the same service the same way, regardless of it’s intended use.  Wordpress is a good use case, since the process of deploying WordPress is going to be the same from one blog to the next.

Django’s Blues

But when you go a little lower in the stack, to web frameworks, it’s not quite so simple.  Take Django, for instance.  While much of the process of deploying a Django service will be the same, there is going to be a lot that is specific to the project.  A Django site can have any number of dependencies, both common additions like South and Celery, as well as many custom modules.  It might use MySQL, or PostgreSQL, or Oracle (even SQLite for development and testing).  Still more things will depend on the development process, while WordPress is available in a DEB package, or a tarball from the upstream site, a Django project may be anywhere, and most frequently in a source control branch specific to that project.  All of this makes writing a single Django charm nearly impossible.

There have been some attempts at making a generic, reusable Django charm.  Michael Nelson made one that uses Puppet and a custom config.yaml for each project.  While this works, it has two drawbacks: 1) It requires Puppet, which isn’t natural for a Python project, and 2) It required so many options in the config.yaml that you still had to do a lot by hand to make it work.  The first of these was done because ISD (where Michael was at the time) was using Puppet to deploy and configure their Django services, and could easily have been done another way.  The second, however, is the necessary consequence of trying to make a reusable Django charm.

Just for Fun

Given the problems detailed above, and not liking the idea of making config options for every possible variation of a Django project, I recently took a different approach.  Instead of making one Django Charm to rule them all, I wrote a small Django App that would generate a customized Charm for any given project.  My goal is to gather enough information from the project and it’s environment to produce a charm that is very nearly complete for that project.  I named this charming code “Naguine” after Django Reinhardt’s second wife, Sophie “Naguine” Ziegler.  It seemed fitting, since this project would be charming Django webapps.

Naguine is very much a JFDI project, so it’s not highly architected or even internally consistent at this point, but with a little bit of hacking I was able to get a significant return. For starters, using Naguine is about as simple as can be, you simply install it on your PYTHONPATH and run:

python manage.py charm --settings naguine

The –settings naguine will inject the naguine django app into your INSTALLED_APPS, which makes the charm command available.

This Kind of Friend

The charm command makes use of your Django settings to learn about your other INSTALLED_APPS as well as your database settings.  It will also look for a requirements.txt and setup.py, inspecting each to learn more about your project’s dependencies.  From there it will try to locate system packages that will provide those dependencies and add them to the install hook in the Juju  charm.

The charm command also looks to see if your project is currently in a bzr branch, and if it is it will use the remote branch to pull down your  project’s code during the install.  In  the future I hope to also support git and hg deployments.

Finally the command will write hooks for linking to a database instance on another server, including running syncdb to create the tables for your models, adding a superuser account with a randomly generated password and, if you are using South, running any migration scripts as well. It also writes some metadata about your charm and a short README explaining how to use it.

All that is left for you to do is review the generated charm, manually add any dependencies Naguine couldn’t find a matching package for, and manually add any install or database initialization that is specific to your project.  The amount of custom work needed to get a charm working is extremely minor, even for moderately complex projects.

Are you in the Mood

To try Naguine with your Django project, use the following steps:

  1. cd to your django project root (where your manage.py is)
  2. bzr branch lp:naguine
  3. python manage.py charm –settings naguine

That’s all you need.  If your django project lives in a bzr branch, and if it normally uses settings.py, you should have a directory called ./charms/precise/ that contains an almost working Juju charm for your project.

I’ve only tested this on a few Django project, all of which followed the same general conventions when it came to development, so don’t be surprised if you run into problems.  This is still a very early-stage project after all.  But you already have the code (if you followed step #2 above), so you can poke around and try to get it working or working better for your project.  Then submit your changes back to me on Launchpad, and I’ll merge them in.  You can also find me on IRC (mhall119 on freenode) if you get stuck and I will help you get it working.

(For those who are interested, each of the headers in this post is the name of a Django Reinhardt song)

Read more
Michael Hall

My big focus during the week of UDS will be on improving our Application Developer story, tools and services.  Ubuntu 12.04 is already an excellent platform for app developers, now we need to work on spreading awareness of what we offer and polishing any rough edges we find.  Below are the list of sessions I’ll be leading or participating in that focus on these tasks.

And if you’re curious about what else I’ll be up to, my full schedule for the week can be found here: http://summit.ubuntu.com/uds-q/participant/mhall119/

Read more
Michael Hall

Ubuntu 12.04, the Precise Pangolin, is scheduled to be released in a little over a week.  This is a very exciting release for us, not only is it an LTS release with 5 years of support, but it also brings some major improvements to Unity and other areas of the desktop.  It’s also going to see a very big focus on independent application developers.

Developers, Developers, Developers!

During the last six months we’ve spent a lot of time building tools and documentation for app developers.  In September of 2011 we launched the Ubuntu Developer Portal, a site dedicated to helping application developers target the Ubuntu platform, and for getting their applications distributed through Ubuntu.

The developer portal provides all the information an app developer needs to write apps for Ubuntu.  It will get you started with tools like Quickly, tell you what languages, toolkits and IDEs are available, and introduce you to the tools and workflows that make developing for Ubuntu a joy.

Once your app is ready, the Developer Portal will walk you through packaging it and submitting it to be published in the Ubuntu Software Center.  The MyApps section lets you upload and manage all your applications, provide branding and screenshots, and set your purchase price.

Going Native

In the past couple of months we’ve added extensive documentation on Unity integration, which allows your application to become part of the desktop experience.  The Unity APIs give your application a presence in multiple areas of the desktop, letting you to add extra information to the Launcher, indicators in the panel, search results in the Dash and more.

All about the Apps

Everybody knows that “Apps” are the big thing now.  No longer relegated to tablets and smartphones, “App Stores” are coming to both major proprietary desktop operating systems as well.  The Ubuntu Software Center already supports independent free and paid app downloads, and with 12.04 we want to grow that segment exponentially.

Not only do we provide a rich platform for app developers to target, we also have the means of delivering those apps directly to over 12 million users worldwide.  With Unity, your app isn’t just visible in the Ubuntu Software Center, but we put it right in the Dash!  Your app will show up whenever the user searches their system for something similar, giving it a level of visibility that no other platform offers.

Join the conversation

Developing applications for Ubuntu doesn’t have to be something you do in isolation.  Having a strong community is an important aspect in today’s software market, and Ubuntu provides you with the tools for collaborating with the existing Ubuntu user community and for growing a strong user community around your own application.    These users can help grow your app by add translations, identify bugs, and even submitting patches.

We’re also building a vibrant community of app developers, and we want you to be a part of that.  Learn tips and tricks from other app developers, share your own expertise and build professional connections.  Here you will also find a number of Ubuntu and Canonical developers who will take your suggestions and feedback for making app development on Ubuntu even better.

Read more
Michael Hall

Hello Unity is now open for translations!

Please help me make this technology showcase is available to application developers in your native language.  Translations are done through Launchpad, and will be built into the Hello Unity package.

Read more
Michael Hall

When the topic of contributions to FOSS come up, it usually happens that people focus entirely on the aspect of creation, specifically code creation, to the exclusion of all others.  In the context of software, this makes a certain amount of sense, since the primary product is the code itself, either in source or binary form.  Even the more broadly-focused, who make a point to expand their definition to include things like documentation and artwork, will still focus exclusively on the creation of those works.  And yet perhaps the single biggest factor towards increased creation of code is in the distribution of what is being created.

There are a number of reasons for people to write new code.  We often talk about a developer “scratching their own itch”, but other times it can be a matter of personal improvement, monetary gain, or even just plain fun.  While there are many reasons to write code, there are not so many reasons for releasing it under a Free or Open Source license.  By choosing such a license, the author explicitly wants his or her creation to be used by others, as many others as possible in fact.  The use of their creation is what motivates them, and it stands to reason that the more it is used, the more motivating it becomes to create.  The underlying reason why this is motivating can vary, but the fact is that creators of FOSS are motivated by the use of FOSS, and the more users there are, the more motivation there will be for creating it.

The number and variety of potential consumers of FOSS is larger than any single developer can hope to reach.  Even a group of developers, even a large group of them, will find it impossible to make their creations available to the widest possible audiences.  And the more effort they put into making their creation available, the less time and resources they have to put back into creating new things.  Likewise the smaller the pool of potential consumers, the less reason developers have to improve on or create something in the first place.  But by choosing an open source license, developers separate the work of distribution from that of creation.  The desire for their creation, then, will naturally lead to a much larger number of individuals and groups bringing these creations to the people who want them.  More importantly, by focusing exclusively on the task of distributing, these new groups are able to afford not just one project, but a multitude of projects, with an increase in the consumption of their creation.  And with an increase in consumption, it is reasonable to expect an increase in contributions.

The default application selection for each Ubuntu release is often the subject of much discussion and advocacy.  People called for the inclusion of Banshee long before Ubuntu made the switch.  It’s unimaginable that people who like a project and appreciate it’s developers would actively seek to have it used by an organization that contributed nothing back.  Likewise when it was announced that Ubuntu would switch back to Rhythmbox, those same advocates genuinely believed that they had lost something, again something unimaginable if they weren’t gaining something valuable from the distribution.  When PiTiVi was selected as a default application, advocates for Openshot made a very strong case for why their preferred application should be included, again because they knew that the project would gain something of value from the increased distribution.  The same happened with F-Spot and Shotwell, with the removal of the Gimp, the various boot splash systems, and more.  I can only assume that the same happens in other distributions.  The only reason why this would happen is if, whether consciously or not, people see a real value, as real as the value of code contributions, in being distributed as widely as possible.

By relieving the developers of the need to put resources into distribution, distributors allow them to create more using the same commitment of time and resources.  Likewise, by increasing the number of people who will be using it, the distributors multiply the motivating value, whatever it may be, that the developer gets in return.  And as the motivation for creating increases, the number of people who participate in creating also increases.  In this way, every distributor of Free and Open Source software contributes towards increasing the total number of creators and creations (including lines of code written), and they do so in direct proportion to the expansiveness of their distribution.

Read more