By now you should have heard that Canonical is branching out from the desktop and has begun work on getting Ubuntu on TVs.   Lost in all the discussion of OEM partnerships and content distribution agreements is a more exciting (from my perspective) topic: Ubuntu TV shows why Unity was the right choice for Canonical to make.

The Unity Platform

Ubuntu TV doesn’t just look like Unity, it is Unity.  A somewhat different configuration, visually, from the desktop version, but fundamentally the same.  Unity isn’t just a top panel and side launcher, it is a set of technologies and APIs: Indicators, Lenses, Quick Lists, DBus menus, etc.  All of those components will be the same in Ubuntu TV as they are on the desktop, even if their presentation to the user is slightly different.  When you see Unity on tablets and phones it will be the same story.

The Developer Story

Having the same platform means that Ubuntu offers developers a single development target, whether they are writing an application for the desktop, TVs, tablets or phones.  There is only one notifications API, only one search API, only one cloud syncing API.  Nobody currently offers that kind of unified development platform across all form factors, not Microsoft, not Google, not Apple.

If you are writing the next Angry Birds or TweetDeck, would you want to target a platform that only exists on one or two form factors, or one that will allow your application to run on all of them without having to be ported or rewritten?

The Consumer Story

Anybody with multiple devices has found an application for one that isn’t available for another.  How many times have we wanted the functionality offered by one of our desktop apps available to us when we’re on the go?  How many games do you have on your phone that you’d like to have on your laptop too?  With Ubuntu powered devices you will have what you want where you want it.  Combine that with Ubuntu One and your data will flow seamlessly between them as well.

A farewell to Gnome 2

None of this would have been possible with Gnome 2.  It was a great platform for it’s time, when there was a clear distinction between computers and other devices.  Computers had medium-sized screens, a keyboard and a mouse.  They didn’t have touchscreens, they didn’t change aspect ratio when turned sideways.  Devices lacked the ability to install third party applications, the mostly lacked network connectivity, and they had very limited storage and processing capabilities.

But now laptops and desktops have touch screens, phones have multi-core, multi-GHz processors.  TVs and automobiles are both getting smarter and gaining more and more of the features of both computers and devices.  And everything is connected to the Internet.  We need a platform for this post-2010 computing landscape, something that can be equally at home with a touch screen as it is with a mouse, with a 4 inch and a 42 inch display.

Unity is that platform.

Back when I first started writing Unity lenses, I lamented the complexity required to get even the most basic Lens written and running.  I wrote in that post about wanting to hide all of that unnecessary complexity.  Well now I am happy to announce the first step towards that end: Singlet.

In optics, a “singlet” is a very simple lens.  Likewise, the Singlet project aims to produce simple Unity lenses.  Singlet targets opportunistic programmers who want to get search results into Unity with the least amount of work.  By providing a handful of Python meta classes and base classes, Singlet lets you write a basic lens with a minimal amount of fuss. It hides all of the boilerplate code necessary to interface with GObject and DBus, leaving the developer free to focus solely on the purpose of their lens.  With Singlet, the only thing a Lens author really needs to provide is a single search function.

Writing a Singlet

So what does a Singlet Lens look like?  Here is a sample of the most basic lens, which produced the screenshot above:

#! /usr/bin/python

from singlet.lens import SingleScopeLens, IconViewCategory, ListViewCategory
from singlet.utils import run_lens

class TestLens(SingleScopeLens):

    class Meta:
        name = 'test'

    cat1 = IconViewCategory("Cat One", "stock_yet")

    cat2 = ListViewCategory("Cat Two", "hint")

    def search(self, phrase, results):
        results.append('http://google.com/search?q=%s' % phrase,
                             'file',
                             self.cat1,
                             "text/html",
                             phrase, phrase, '')

        results.append('http://google.com/search?q=%s' % phrase,
                             'file',
                             self.cat2,
                             "text/html",
                             phrase, phrase, '')

if __name__ == "__main__":
    import sys
    run_lens(TestLens, sys.argv)

As you can see, there isn’t much to it.  SingleScopeLens is the first base class provided by Singlet.  It creates an inner-scope for you, and connects it to the DBus events for handling a user’s search events.  The three things you need to do, as a Lens author, is give it a name in the Meta  class, define at least one Category, and most importantly implement your custom search(self, phrase, results) method.

Going Meta

Django developers will notice a similarity between Singlet Lenses and Django Models in their use of an inner Meta class.  In fact, they work exactly the same way, though with different properties.  At a minimum, you will need to provide a name for your lens.  Everything else can either use default values, or will be extrapolated from the name.  Everything in your Meta class, plus defaults and generated values, will be accessible in <your_class>._meta later on.

Categorically easy

Again borrowing from Django Models, you add categories to your Singlet Lens by defining it in the Class’s scope itself, rather than in the  __init__ method.  One thing that I didn’t like about Categories when writing my previous lenses was that I couldn’t reference them when adding search results to the result model.  Instead you have to give the numeric index of the category.  In Singlet, the variable name you used when defining the category is converted to the numeric index for that category, so you easily reference it again when building your search results.  But don’t worry, you category objects are still available to you in <your_class>._meta.categories if you want them.

The search is on

The core functionality of a Lens is the search.  So it makes sense that the majority of your work should happen here.  Singlet will call your search method, passing in the current search phrase and an empty results model.  From there, it’s up to you to collect data from whatever source you are targeting, and start populating that results model.

You can handle the URI

Unity knows how to handle common URIs in your results, such as file:// and http:// uris.  But often times your lens isn’t going to be dealing with results that map directly to a file or website.  For those cases, you need to hook into DBus again to handle the URI of a selected result item, and return a specifically constructed GObject response.  With Singlet, all you need to do is define a handle_uri method on your Lens, and it will take care of hooking it into DBus for you.  Singlet also provides a couple of helper methods for your return value, either hide_dash_response to hide the dash after you’ve handled the URI, or update_dash_response if you want to leave it open.

Make it go

Once you’ve defined your lens, you need to be able to initialize it and run it, again using a combination of DBus and GObject.  Singlet hides all of this behind the run_lens function in singlet.utils, which you should call at the bottom of your lens file as shown in the above snippet.

Lord of the files

There’s more to getting your Lens working that just the code, you also need to specify a .lens file describing your lens to Unity, and a .service file telling dbus about it.  Singlet helps you out here too, by providing command line helpers for generating and installing these files.  Suppose the code snippet above was in a file called testlens.py, once it’s written you can run “python testlens.py make” and it will write test.lens and unity-test-lens.service into your current directory.  The data in these files comes from <your_lens>._meta, including the name, dbus information, description and icon.  After running make you can run “sudo python testlens.py install”, this will copy your code and config files to where they need to be for Unity to pick them up and run them.

More to come

You can get the current Singlet code by branching lp:singlet.  I will be working on getting it built and available via PyPi and a PPA in the near future, but for now just having it on your PYTHONPATH is enough to get started using it.  Just be aware that if you make/install a Singlet lens, you need to make the Singlet package available on Unity’s PYTHONPATH as well or it won’t be able to run.  I’ve already converted my Dictionary Lens to use Singlet, and will work on others while I grow the collection of Singlet base classes.  If anybody has a common yet simple use case they would like me to target, please leave a description in the comments.

Unity certainly has been getting a lot of attention in the past year.  Love it or hate it, everybody seems to have something to say, whether it’s about the Launcher, application indicators, or the window control buttons being on the left.  But with all the talk about Unity, good and bad, one very unique aspect that hasn’t been getting nearly enough attention are Lenses.

Lenses are a central part of the Unity desktop, and anybody who’s used it will be familiar with the default Application and File lenses, maybe even the Music lens.  But there’s so much more to this technology than you might think.  In fact, David Callé has recently been spearheading an effort to build out a large number of small but incredibly useful lenses.  I first took notice of David’s work when he released his Book lens which, being a huge ebook fan, really brought home the usefulness of Unity Lenses for me.

More recently, David has been writing Scopes for the One Hundred Scopes project.  A Scope is the program that feeds results into a Lens.  While the Lens defines the categories and filters, it’s the Scopes that do the heavy lifting of finding and organizing the data that will ultimately be displayed on your Dash.  If you follow David on Google+, chances are you’ve seen him posting screenshots of one scope after another as he writes them, often multiple of them per day.

Seeing how quickly he was able to write these, I decided to dive in and try it out myself.  You can write Lenses in a variety of languages, including Python, my language of choice.  I decided to start of with something relatively easy, and something that I’ve personally been missing for a while.  I used to use a Gnome2 applet called Deskbar, which let you type in a short search word or phrase, and it presented you with search results and various other options.  Included among those was the option to lookup the word in the gnome-dictionary, and I used this option on a startlingly frequent basis.  Unfortunately Deskbar fell out of favor and development even before the switch to Gnome 3, and I’d been lacking a quick way to lookup words ever since.  So I decided that the Lens I wanted was one that would replace this missing functionality, a Dictionary lens.

My first task was to find out how to write a lens.  I checked the Ubuntu Wiki and the Unity portal, both of which offered a lot of technical information about writing lenses, but unfortunately not very much that I found helpful for someone just starting off.  In fact, I had to get a rather large amount of one-on-one help from David Callé before I could even get the most basic functionality working.

Lenses and Scopes all communicate with each other and with the Unity Dash via DBus, and for anybody not familiar with DBus this makes for a very steep learning curve.  On top of that, writing it in Python means you’ll be relying on GObject Introspection (GI), which is a very nice way of making APIs written in one language automatically available to another, but it also means you’re going to be using the lowest common denominator when it comes to language features.  I found that learning to work with these two technologies accounted for 90% or more of the time it took me to write my Dictionary lens.  Before I write another Lens or Scope, I plan on wrapping much of the DBus and GI boilerplate and wiring behind a simple, reusable set of Python classes.  I hope this will help developers, both newbies and seasoned Unity hackers, in writing simple Scopes by allowing them to focus 90% of their time on writing the code that does the actual searching.

But by the end of the day I had a working Dictionary lens.  It uses your local spellcheck dictionary, via python-enchant, to both confirm whether or not the word you typed in is spelled correctly, as well as offer a list of suggested alternatives.  I also dug through the gnome-dictionary code and found that it was pulling its definitions from the dict.org online database using an open protocol.  Using the python-dictclient I was able to query the same database, and include the start of a word’s definition in the Lens itself.

This lens turned out to be more complex than I had originally envisioned, not just for the features listed above, but also because I needed to override what happened when you clicked on an item.  When you build up your results, you have to give each item a unique URI, which is often in the form or an http:// or file:// URL that Gnome knows how to handle.  But for results that were just words, I needed to do the handling myself, which meant more DBus wiring to have the mouse click event call a local function.  From there I was able to copy the word to the Gnome clipboard or launch gnome-dictionary for viewing the full definition.

After seeing that first Lens running in my Dash, I felt an urge to try another.  Since I already had all of the DBus and GI code, I wouldn’t have to mess with all of that and I could focus just on the functionality I wanted.  Jorge Castro has been trying to get me to write a lens for the LoCo Teams Portal (formerly LoCo Directory) since the concept was first introduced to Unity under the name “Places”.  Since LTP already offers a REST/JSON api, this turned out to be remarkably simple to do.  Between the existing DBus/GI code copied from my previous lens, and an existing python client library for the LTP, I was able to get a working lens in only a couple of hours.

For item icons, you can use either a local icon, or a URL to a remote image.  For this lens, I used the team’s mugshot URL that LTP pulls from the team’s Launchpad information.  When you search, it’ll show matching Teams, as well as Events and Meetings for those teams, and any Event or Meeting that also matches your search criteria.  I’ve also added the ability for this lens to lookup your Launchpad username (by checking for it in your bazaar.conf) and defaulting it to display the LoCo Teams you are a member of, as well as their upcoming Events and Meetings.

Both the Dictionary Lens and the LTP Lens lump the Lens and Scope code in the same Python class, but it doesn’t have to be this way.  You can write a Scope for someone else’s Lens, and vice versa.  In fact, plan on separating the LTP lens into a general purpose Community Lens, with an LTP Scope feeding it results about LoCo Teams.  From there, others can write scopes pulling in other community information to be made available on the Dash.  This will also be my prototype for a Python-friendly wrapper around all of the DBus and GI work that scope writers probably don’t need to know about anyway.

As promised in my previous post about my Unity Phone Mockups, here’s a look at the TV mockups I’ve been playing with over the last week, along with the reasons behind some of the designs.  Links to the source files for these mockups, as well as the mockups by other community contributors, can be found on this wiki page.

These aren’t as innovative as my phone mockups, partly because I didn’t have much of a reference to start from like I did with IOS and Android for phones.  I have a DVR from my cable company, but no HTPC or other media center software.

The TV frame and choice of movie (Big Buck Bunny) came from Alan Bell’s template.  I added a remote control to that, and added buttons as I found a need for them.  In the mockups, I’ve highlighted the buttons you would use to interact with the given screen.

The basic concept was to overlay the Unity components when the user presses the Circle-of-Friends button on the remote, but to otherwise leave whatever they are watching full screen.  On this mockup I used applications in the Launcher, and pressing the CoF would put the focus on them the same way Alt-F1 does on the desktop.  You could then navigate through them using the arrow buttons on the remote, pressing OK to make your selection.

In this alternate mockup, I replaced the applications with Unity lenses, which I think makes more sense for a TV, since you will more often than not be interested in finding content, not selecting which application to run.  Luckily Unity already supports both, so this is just a matter of what the default initial configuration should be, after that the user can put whatever they want in the Launcher.

For opening the dash I envision being able to double-tap the CoF button (or selecting a Lens).  In fact, I would like to have this on desktop Unity, since I want quick access to the Launcher more often than I want the Dash.  Once the Dash is open, you would use the remote’s arrow buttons to navigate through the items listed, again pressing OK to make your selection.

For accessing the Dash’s filters, I added the “context menu” button to the remote which, when pressed while on the Dash screen, will open the filter sidebar, letting you navigate through the filtering options using the remote’s arrows.  Pressing the context menu button again would collapse the filter sidebar and return arrow navigation to the results table.

Likewise I added a Search button to the remote to send focus to the Dash’s search field and activate the on-screen keyboard.  Text input from a remote like this will be cumbersome (unless we come up with a monstrosity of a remote like this), so we’ll want to avoid the need for this as much as possible.  But since the Dash is highly search-focused, I felt that there needed to be a mockup for this aspect.

This is a screenshot of Shotwell taken from my laptop and scaled to fit a resolution it might be at on a TV screen.  I did this to demonstrate how an existing desktop app might look and work without modification on a 10 foot interface.  Here again I added a new button to the remote, which is a kind of next/last panel or, more accurately, the tab key on a desktop keyboard.  This lets you navigate through widgets and panels on a traditional application like you can using the tab key on a desktop.

I think with some small enhancements to GTK and QT, we can allow application developers to make navigating apps this way easier.  Alternately, a new library similar to uTouch could act as an interface between remote control input and applications.

Someone pointed me to YouTube’s LeanBack interface, an HTML5 webapp designed for 10 foot displays.  This is a very promising way to deliver applications and contents to internet connected TVs, especially if we ship with a fully functional, HTML5 supporting web browser optimized for control with a remote.

Finally I wanted to show off Media Explorer, a media center application built on the same Gnome technologies as the rest of the Ubuntu desktop.

Feedback

Just like I did in my last post, I’d like to solicit discussion and feedback on these mockups, and also ask what other scenarios/mockups you would like to see.  You can either leave comments here, or join the live conversation in #ubuntu-tv on Freenode.

I’ve been expanding on my earlier Unity TV mockups lately, which I will post more about later, but I’ve also been working on some Unity Phone mockups, and I wanted to put a couple of ideas out for wider discussion and feedback.

Launcher Position

OMG!Ubuntu! highlighted some other mockups for Unity on a Phone where the designer kept the launcher on the left hand side, as it is on the desktop.  While this is keeping with the look of desktop Unity, I didn’t think it was in line with the reasons for it.  The primary reason for the launcher’s position is to use up screen width (which is abundant on desktops) and free up screen height (which is scarce on desktops).

Keeping that in mind, I came up with a design that keeps the launcher on the narrowest screen edge, regardless of orientation.  When holding the phone in portrait mode, the launcher sits along the bottom, the way is traditionally does on Android interfaces.  When rotated to landscape, the launcher sits along the left edge, the way it does in Unity on the desktop.  This was the launcher is only ever taking up space in the dimension you have the most to spare, while providing a familiar interface in both modes.

The top panel, however, always stays up along the top edge of the screen.  This matches Android in portrait mode, and desktop Unity on landscape.  This is because it contains the time, which would either have to be rotated or left at 90 degrees in landscape, but also because having the panel at the top gives consistency in the next feature I looked at.

Accessing Indicators

There is a video on YouTube showing a new Acer Iconia W500 running Ubuntu 11.10, and watching the user try and land a touch event on an indicator icon was particularly painful, even on a tablet the indicator icons are far to small to be easy touch targets.  How much worse would it be when they’re on a screen a quarter of the size?

Instead I thought about the way Android lets you drag-down the top bar to access your list of notifications, and how easy of a gesture that is.  Applying that to Unity, I came up with the idea of a drag-down gesture activating the indicator menus, much like you can by pressing F10 on desktop unity.  Only instead of popup menus, these would use a full-screen overlay, again like Android does for notifications.

Unlike Android, however, you would be able to access all of your indicators from here, not just notifications.  Swiping left or right will move you to adjacent indicators (just like left and right keyboard buttons do on desktop Unity).  So you would have quick, easy, always available access to your networking, sound (including playback controls) and calendar.

Feedback

Like my earlier TV mockups, these are all done using the Pencil mockup tool.  You can see the full exported version here, and download the source files here.  If you are interested in the discussions going on, join the #ubuntu-phone channel on Freenode.  Please let me know what you think of these mockups, and what other areas of Unity on a phone you would like to see designs for.  And remember, none of these are official designs, they’re just what I’ve been doing for fun in the evenings.

Inspired my Mark Shuttleworth’s recent post about Alan Bell’s Unity TV mockups, I’ve decided to try my hand at some.  Alan did his using Pencil, which is an awesome tool for UI mockups that I wrote about previously, so it was easy enough for me to get started.  Here is my first one, a mockup where just the Launcher and Unity panel are showing (no Dash):

You can see other people’s mockups, and add your own on the Ubuntu Wiki.  Instructions for getting setup with Pencil can be found in the mailing list archive.

(Update 1: There seems to be some confusion about what I’m saying in this post, so let me be absolutely clear from the start: I am not questioning or criticizing Distrowatch’s data.  Their data is, as far as I know, 100% accurate.  What I’m questioning is whether or not this data is a measure of the “popularity” of any given distro, as so many news stories are claiming it is.)

(Update 2: If anybody else wants to run a story about this post, please contact me before making it sound like my blog article is somehow an official Canonical response.  I’m more than happy to have a conversation with you for the sake of accuracy.)

It seems that the tech blogs both inside and outside the Linux sphere have picked up on a graph supposedly showing a decline in the popularity of Ubuntu based on statistics from Distrowatch.  I’m not going to point out all of the flaws in these reports, or the basis of the graph in general, that has been done already here and here (especially in their comment threads).

Instead I want to take a step back for a moment and examine what the statistics are actually counting, and what that actually means for both Ubuntu and LinuxMint.

Hits per day

The numbers themselves come from the number of page views per day on Distrowatch’s page for each distro.  So if you go to http://distrowatch.com/arch you’ve added to the count for Arch.  Now the first thing this tells us is that the statistic is in no way tied to the actual number of users a distro has, just the number of people looking at that distro’s page on Distrowatch.  Now there are three possible reasons why a user might visit one of these pages:

1. Curiosity about a distro
2. Following a link from somewhere else
3. Attempting to boost the hits-per-day count for a distro

I’m going to disregard #3, because I don’t believe that anybody involved with Mint is doing anything underhanded to boost these numbers.  But an examination of the other two will shed some light on what exactly is happening.

Follow that link

Even though a Distrowatch ranking isn’t connected to number of users, it’s still exciting to see your distro rise in the list, and it’s natural to want to tell people about it.  Mint does it, Ubuntu does it, lots of distros do it.  There’s nothing wrong with this, and if enough people are reading your announcement to impact the ranking, then it most likely deserves to be impacted.

But something all together different happens when 3rd party sources start sending people to your distrowatch page because of your rank.  When the Register and PC World run articles about you being on top, their readers will naturally visit your Distrowatch page, further increasing your rank, which will in turn prompt more stories about it, sending more people to your page, etc.

While I have no doubt that Mint deserves the top spot (more on that below), I think the amount of its increase has been affected by this positive feedback loop.  This cyclic reaction will likely continue for a few weeks until people finally get bored with the story, at which point I expect Mint’s numbers to fall back down into the 2500-3000 range, comfortably at #1, but well below the 7728 it’s at as I’m writing this.

The Buzz

All of which brings us back to the first reason for visiting a distrowatch page: Curiosity.  Distrowatch is a great resource for finding out about a distro, and it’s how a lot of young distros get attention.  When Qimo got a mention there, we saw a huge traffic increase, and we also rose pretty sharply in the ranking (nowhere near #1, but still something I was proud of).

But there comes a point, when a distro has become established, where the vast majority of those curious people will be going directly to the distro’s own website, rather than Distrowatch.  Nobody would deny that Red Hat is one of the most used Linux distros, but it currently ranks at #42 on Distowatch.  Suse ranks at #64.  Even the free-as-in-beer CentOS, which we all know is widely used, is only at #9.  As a general rule then, we can assume that as a distro becomes more established and gains more market and mind-share, fewer people will be going to Distrowatch to learn about it.

So what does that leave us?  I like to call it “Young Buzz”, a large amount of excitement about a relatively new (in terms of mindshare) distro.  This is something that absolutely describes LinuxMint.  As the seemingly anti-Unity distro of choice, it has been getting a lot of talk and attention and, while I disagree with the anti-Unity sentiment, Mint is certainly deserving of attention.  Its user base is growing rapidly and I hope its community is too.  They are doing some interesting work with both Gnome-Shell and the Mate, the Gnome 2 fork.  Every other distro will be keeping an eye on them, seeing what gains traction and what doesn’t, and I expect some of that to make its way upstream and into other distros as well.

What does it all mean?

Is LinutMint more popular that Ubuntu?  No, not by any measure I have seen.  Will it become more popular than Ubuntu?  I don’t know, but my gut says not anytime soon.  But Mint certainly has the most momentum, at least for the moment, and will continue to grow at a faster rate for at least the near future.

But they aren’t the first to be in the position, PCLinuxOS had much the same buzz a few years ago, but wasn’t able to maintain it.  The challenge for Mint is to keep this momentum going, and to do that they’re going to need a strong, open, supporting community that gives new users somewhere to belong in the way the Ubuntu community does.

It’s late, I’m tired, so this is going to be brief.  But if I didn’t put something up now, chances are I’d procrastinate to the point where it didn’t matter anymore, so something is better than nothing.

JuJu

So the buzz all week was about Juju and Charms.  It’s a very cool technology that I think is really going to highlight the potential of cloud computing.  Until now I always had people comparing the cloud to virtual machines, telling me they already automate deploying VMs, but with Juju you don’t think about machines anymore, virtual of otherwise.  It’s all about services, which is really what you want, a service that is doing something for you.  You don’t need to care where, or on what, or in combination with some other thing, Juju handles all that automatically.  It’s really neat, and I’m looking forward to using it more.

Summit

Summit worked this week.  In fact, this is the first time in my memory where there wasn’t a problem with the code during UDS.  And that’s not because we left it alone either.  IS actually moved the entire site to a new server the day before UDS started.  We landed several fixes during the week to fix minor inconveniences experienced by IS or the admins.  And that’s not even taking into consideration all the last-minute features that were added by our Linaro developers the week prior.  But through it all, Summit kept working.  That, more than anything else, is testament to the work the Summit developers put in over the last cycle to improve the code quality and development processes, and I am very, very proud that.  But we’re not taking a break this cycle.  In fact, we had two separate sessions this week about ways to improve the user experience, and will be joined by some professional designers to help us towards that goal.

Ubuntu One eBook syncing

So what started off as an casual question to Stuart Langridge turned into a full blown session about how to sync ebook data using Ubuntu One.  We brainstormed several options of what we can sync, including reading position, bookmarks, highlights and notes, as well as ways to sync them in an application agnostic manner.  I missed the session on the upcoming Ubuntu One Database (U1DB), but we settled on that being the ideal way of handling this project, and that this project was an ideal test case for the U1DB.  For reasons I still can’t explain, I volunteered to develop this functionality, at some point during the next cycle.  It’s certainly going to be a learning experience.

Friends

Friends!  It sure was good to catch up with all of you.  Both friends from far-away lands, and those closer to home.  Even though we chat on IRC almost constantly, there’s still nothing quite like being face to face.  I greatly enjoyed working in the same room with the Canonical ISD team, which has some of the smartest people I’ve ever had the pleasure of working with.  It was also wonderful to catch up with all my friends from the community.  I don’t know of any other product or project that brings people together the way Ubuntu does, and I’m amazed and overjoyed that I get to be a part of it.

If you’ve been doing anything with Ubuntu lately, chances are you’ve been hearing a lot of buzz about Juju.  If you’re attending UDS, then there’s also a good chance that you’ve been to one or more sessions about Juju.  But do you know it?

The building blocks for Juju are it’s “charms”, which detail exactly how to deploy and configure services in the Cloud.  Writing charms is how you harness the awesome power of Juju.  Tomorrow (Friday) there will be a 2 hour session all about writing charms, everything from what they do and how they work, to helping you get started writing your own.  Questions will be answers, minds will be inspired, things will be made, so don’t miss out.

http://summit.ubuntu.com/uds-p/meeting/19875/juju-charm-school/

(Photo courtesy of http://www.flickr.com/photos/slightlynorth/3977607387/)

Are you both an Ubuntu user and a bibliophile?  Want to keep your ebooks synced between all your connected devices, including bookmarks and reading position?   If so, join us for this UDS session Thursday, Nov 3rd, where we’ll be talking about how to add that functionality to Ubuntu One.

http://summit.ubuntu.com/uds-p/meeting/19820/other-p-u1-book-sync/

In a previous post a commentator was explaining his typical web-stack deployment, and boasting about how he “can roll this out on Debian in less than 4 hours”.  Now he’s talking about provisioning, installing the OS, installing the services, and configuring everything.  That’s easily a day’s work for a capable sysadmin in a corporate environment. At least, it is in my experience.  So 4 hours sounds pretty good, doesn’t it?  I tell you what, go find your nearest admin and ask them how long it would take for them to get a new WordPress site up and ready for you to start posting to.  No really, I mean it, go ask.  I’ll wait.

Back?  Good.  I’m betting that, for many of you, the answer was a day or less, depending on their backlog of work.  A lucky few would be able to get their new site in an hour or two.  Not bad. But if you were using Ubuntu and cloud technology, you would have had your new site ready in the time that it took you to get that answer.

You think I’m exaggerating?  You can get a new world-accessible WordPress site up and running in less than 10 minutes.  That’s not marketing hype, Canonical is quite literally putting it’s money where it’s mouth is, by paying for an hour of Ubuntu Server on Amazon’s cloud service.  Go to http://try.cloud.ubuntu.com and follow along, and you’ll have a WordPress site up and running in less time than it’ll take you to finish reading this article.

Welcome to the Try Ubuntu project.  Yes, we really are footing the bill for this, it won’t cost you a dime.  Click that large inviting “Let’s go to the cloud” button to start your adventure in cloud computing.

You will need to sign into Ubuntu SSO, because while we’re perfectly happy to pay for one hour, we do need to prevent abuse.  Requiring a login lets us limit this to once per user.  If you don’t have an SSO account you can create one now, and really if you’re going to spend any time at all with Ubuntu or the community, you’re going to want one soon or later anyway.

Ubuntu SSO lets you decide what detailed information to send back to any requesting web service.  You don’t have to send any of these details back to use this service, but if you have a Launchpad profile and uploaded SSH keys, you’ll get a better experience if you send at least your username.

Next you’ll get to choose what you want running on your trial instance.  You’ll also have to agree not to be abusive with your instance, do anything illegal, or generally cause other people problems as a result of our generosity.  Seriously, just don’t do it.

Currently we offer a base Ubuntu Server, running just the default installation, as well as the base server plus WordPress, Drupal or MoinMoin.  These aren’t pre-made images, they’ll be installed after the new server is provisioned, just like you would do manually, only thanks to cloud-init, we have it all automated.  You will use the same Ubuntu Server AMI regardless of which service you choose.

That’s all you need to do!  Now click the “Launch” button and the website will ask for a new m1.small instance through Amazon’s EC2 API.  This API is available to anyone, by the way, so you can script your own cloud deployments in exactly the same way.  We are using the boto python library to access the API from within Django.

After we get an instance reserved, we have to wait for Amazon to start it.  It only takes about a minute for Amazon to start up your new instance. In the mean time, this page will periodically refresh itself, and will let you know once your instance has started.  Did you notice that “View Cloud-Config” link?

This is what will be run on your new instance as soon as it’s ready.  You can copy this script, and use it later to start up your own permanent Ubuntu Server instances on AWS or any other EC2 compatible cloud host.  It is this script that will install Apache, MySQL and WordPress, configure them all properly, and get them all running.

Now your instance has started, and so has your countdown clock. At this point Ubuntu is fully booted, and your cloud-init script is busy installing all the packages and dependencies needed to run WordPress, all you have to do is sit back and wait.  Deploying is hard work huh?.  Don’t worry, I won’t tell your boss.

Hope you didn’t get too comfy, because 3 minutes later and we’re done!  Here you’ve given the command to SSH into your new instance.  If you’re running this from Windows, you’ll need to get something like PuTTY, because last time I checked Redmond still thinks that unencrypted Telnet is a good idea.  Trust me, you want SSH.

So fire up a terminal (yes, a terminal, you’re in server-land now buddy) and copy/paste the ssh command to get connected to your new instance.

Next you will be prompted for your password, it’s back on the web page, just copy/paste it into the terminal.  Remember how I said earlier that having a Launchpad profile with uploaded SSH keys would give a better experience?  Well if you’ve got all that, then you won’t see this step.  You see, part of the initialization that happened when your new instance started was to download your public SSH keys from Launchpad, allowing you to use your private SSH keys for authentication.  Nice huh?

So now you’re connected to your new instance.  But what’s all that stuff at the bottom of your terminal now?  That my friend, is Byobu, Ubuntu’s highly customized profile for GNU Screen.   Describing all of it’s wonderful goodness would take another full blog post, so I’ll just point out the highlights.  F2 creates a new “tab”, and you can switch between them with F3/F4.  Down at the bottom are some system monitoring widgets for things like load and memory usage.  In green characters is a special widget for Amazon EC2 that gives you an estimate of how much your instance is costing you (a whopping $0.09 USD at this point), and in blue characters is a clock showing how long your trial has been running (so you’ll know how much of your 55 minutes you have used).

Alright, your instance is running and configured, now what?  Well, did you  see that link on the web page?

That one, next to “Try going to”.  Click on it.

Well look at that, it’s your new WordPress site, just waiting for you to give it a name (and also username and password).  No unzipping, copying, apache configs, database setup, nothing.  We literally can’t make it any easier.

So pick a name, give it a password and email, and you’re all set!  Yes, I know my password was weak.  Actually my password was ‘password’.  Hey, it was only up for 55 minutes, I’m not going to spend extra time thinking of a secure password.  Come on, we’ve got a WordPress site to play with!

There you are, your new WordPress site is deployed.  And how are we doing on time?  Well if you hadn’t spent so much time reading along with this article, you’d have at least 45 minutes left out of the original 55.  Heck, I wasted a bunch of time taking screenshots along the way, and I still had more than 40 remaining.  How far do you think your sysadmin would have gotten in this same amount of time?  He probably just got back form refilling his coffee (which, to his credit, really is necessary before attempting a deployment the old fashioned way).

After a while, as you get close to the end of your trial period, you’ll get these helpful messages in your terminal session, letting you know how much longer you have.  And before you start thinking that you can use your mighty sudo powers to stop your instance’s termination, sorry pal, but we keep track of them on our end too, and your instance will be killed through the same EC2 API that launched it.  But I sure hope you had fun.

So now you’ve seen how fast and easy it is to deploy not just Ubuntu Server in the cloud, but actual, useful services running on top of it.  We offer you three popular software packages for websites, but those are only the tip of the iceberg.  You can write cloud-init scripts for anything you want to deploy on Ubuntu, even your own in-house build applications.  Then you too can deploy into the cloud with the click of a button.

What’s that you say?  You don’t have a handy dandy webapp for one-click deployments into the cloud?  Oh but you do!  You see, everything you just saw is open source, you can download it from lp:awstrial on Launchpad.  Use it to run your own trials, or just to learn how we did it so you can write your own internal provisioning service.  It defaults to using Amazon’s EC2 cloud, but you can point it to any EC2 compatible cloud.  We ran it internally against an OpenStack EC2 cloud during development and testing.

Did you enjoy your trial?  Leave us some feedback on what you liked, what you didn’t, and what you want us to offer in the future.

At the LibreOffice Conference, they announced that they will be releasing versions for Android and iOS.

They also plan to release an online version which you could host on your own as well to offer web based office suite. This would a boon to companies wanting to offer Google Docs but want it hosted in their own private cloud.  They could now host LibreOffice Online.

Expect this to take 12-18 months to release something for end-users. Target date is End 2012 or beginning 2013.

Meanwhile  for Android Users, there are three applications to open ODF files on Android.

OpenOffice Document Reader

ODF Viewer

Mobile Document Viewer

Related posts:

1. LibreOffice 3.3 offers more than OpenOffice After Oracle’s acquisition of Sun, OpenOffice was forked to create LibreOffice....
2. 10 reasons why I like Android more than Apple iOS I have been using an Android phone for more than...
3. 11 features Apple copied from Android Congratulations Apple users, you are soon going to have 11...

Related posts brought to you by Yet Another Related Posts Plugin.

We’re less than a month away from the start of UDS-P, which means we’re winding down the development pace on the Summit project. It’s been a very, very busy 6 months for us, we’ve done more work on Summit this cycle than I think it has ever seen before.  As I mentioned in previous posts, our main focus this cycle has been on stabilizing both the code, and the development process, and I think we’ve done an excellent job of meeting those goals.

During this cycle we have developed an easy to reproduce development environment that allows new contributors to get started hacking on Summit much faster than the could previously.  At the same time we’ve implemented stricter code reviews, requiring accompanying test cases in most instances, and have configured Tarmac to help us keep approved branches landing without delay.  We have also handed the task of maintaining our production environment and production deployments to Canonical’s IS team so that Summit will be managed by the same professional team as any other Ubuntu website.  We have also added 3 new contributors during this cycle, and hope to add more even more in the next.

From the end of UDS-O to the time of this writing, the Summit developers have closed 37 bugs, landed 89 merge proposals, and added 118 test cases (which is 118 more than we had before).  I can’t even begin to say how proud I am of the team of developers that have contributed to this project, and the amazing results that we have achieved in so short a time.  It is even more incredible because this is truly a community project, we all contribute to it in our spare time.  So thank you to everybody who has contributed to the success of the Summit project this cycle.

Below is the full list of bugs, branch merges and test cases from this cycle.

Bugs

Branch Merges

193: Michael Hall 2011-10-02 [merge] [r=james-w] Optimizations to reduce the number of database queries on the summit and schedule pages.
192: James Westby 2011-09-22 [merge] [r=mhall119] Apply the same transform as etherpad to meeting names when generating pad urls.
191: Michael Hall 2011-09-22 [merge] [r=mhall119] Allow linaro tracks to be scheduled in adjacent slots in the same room.
190: James Westby 2011-09-21 [merge] [r=mhall119] Don’t escape URLs before putting them in the HTML.
189: Michael Hall 2011-09-21 [merge] [r=james-w] Change user_private_ical to use Schedule.from_request, add test case for private ical.
188: James Westby 2011-09-21 [merge] [r=mhall119] Allow + in track, room and attendee names without causing url lookup errors.
187: James Westby 2011-09-21 [merge] [r=mhall119] Fix the 500 error pages to not crash when displayed.
186: Michael Hall 2011-09-19 [merge] [r=james-w] Exclude attendee secret key from the API
185: James Westby 2011-09-19 [merge] [r=mhall119] Allow “+” in a meeting name without crashing on the url lookup.
184: James Westby 2011-09-17 [merge] Make it a single query, rather than doing a few queries per meeting.
183: Michael Hall 2011-09-18 [merge] [r=nigelbabu] Fixes problem with old cache on track view schedule
182: James Westby 2011-09-18 [merge] [r=mhall119] Add some tests for constructing a Schedule object.
181: Nigel Babu 2011-09-17 [merge] [r=james-w] Initial run at pep8 and pyflakes complaints fixing.
180: Michael Hall 2011-09-17 [merge] [r=james-w] Adds read-only REST/JSON API to the schedule data
179: Michael Hall 2011-09-17 [merge] [r=james-w] Adds the ability to download or subscribe to an ical containing your public *and* private meetings
178: Michael Hall 2011-09-17 [merge] [r=james-w,nigelbabu] Fix tests that were looking for a hard-coded SITE_ROOT in urls
177: Jamal Fanaian 2011-09-16 [merge] [r=mhall119] Updating the description of a meeting from the LP blueprint.
176: James Westby 2011-09-16 [merge] The autoscheduler will now reliably not require someone to be in two places at once.
175: Michael Hall 2011-09-16 [merge] [r=nigelbabu] In unit tests, specify that all Meeting instances are requires_dial_in=False unless explicitly testing that functionality.
174: James Westby 2011-09-16 [merge] [r=mhall119] Add fields on rooms and meetings for dial-in.
173: James Westby 2011-09-16 [merge] [r=mhall119] Remove the code to display the track in the room title if there is only one.
172: James Westby 2011-09-16 [merge] [r=mhall119] Add tests for the reschedule command, and make it do something again.
171: James Westby 2011-09-16 [merge] [r=mhall119] Fix a javascript error when a meeting has no participants.
170: James Westby 2011-09-16 [merge] [r=mhall119] Revert r50 which was a band-aid to fix a bug that can no longer be reproduced.
169: James Westby 2011-09-15 [merge] Fix percent sign escaping in render.py
168: James Westby 2011-09-15 [merge] Add support for using multiple Launchpad sprints to populate a single Summit, which will allow separate UDS and Linaro Connect sprints
167: Michael Hall 2011-09-14 [merge] [r=james-w] Adds test cases to make sure % signs are being properly escaped in render.py
166: James Westby 2011-09-14 [merge] [r=mhall119] Update the location of the linaro theme branch.
165: James Westby 2011-09-13 [merge] Add headers to avoid caches on the +temp-meeting-export fetch.
164: Michael Hall 2011-09-14 [merge] [r=james-w] Fix to allow periods in records names
163: James Westby 2011-09-13 [merge] Stops the auto-scheduler from acting on private meetings.
162: Chris Johnston 2011-09-13 [merge] [r=james-w] Updates linaro link to match uds.u.c
161: Michael Hall 2011-09-13 [merge] [r=nigelbabu] Fixes 2 typos in the get_edit_link_to_pad method
160: Michael Hall 2011-09-13 [merge] [r=james-w] Fix for the PrivateSchedulingTestCase
159: Michael Hall 2011-09-12 [merge] [r=nigelbabu] Adds a new TestCase for building tests of the schedule conflict resolution.
158: Michael Hall 2011-09-11 [merge] [r=chrisjohnston] Adds a new ‘color’ field to the Track record, this contains a 6-char hex color code that will be used as the background for meeting blocks on the schedule.
157: Michael Hall 2011-09-02 [merge] [r=chrisjohnston] Check that at least one plenary room exists before trying to use 156: Michael Hall 2011-09-02 Add back in what was lost on rebase
155: Michael Hall 2011-09-02 Add back in what was lost on rebase
154: Chris Johnston 2011-09-02 Adds ability for schedulers to schedule private rooms.
153: Chris Johnston 2011-09-02 Adds private rooms to edit page
152: Chris Johnston 2011-09-02 Adds display of private rooms on UDS page for staff
151: Chris Johnston 2011-09-02 Adds def private_rooms
150: Jamal Fanaian 2011-09-02 [merge] [r=mhall119] Created a method to get an attendee’s full name. Showing crew
149: Chris Johnston 2011-09-02 [merge] [r=mhall119] Removes stray }
148: Michael Hall 2011-08-27 [merge] More XSS fixes
147: Michael Hall 2011-08-27 [merge] Fix XSS vulnerability
147: Michael Hall 2011-08-22 [merge] Check with launchpad to see if an entered username is valid on sponsorship suggestion form
147: Michael Hall 2011-08-22 [merge] Fix errors when converting sponsorship scores to unicode strings
146: Chris Johnston 2011-08-22 [merge] [r=nigelbabu,mhall119] Updates the version of light-django-theme and fixes bzr apps after an update.
145: Chris Johnston 2011-08-22 [merge] [r=nigelbabu] Moves admin link to masthead due to wrapping in main-nav
144: Chris Johnston 2011-08-19 [merge] [r=nigelbabu] Changes Linaro link to match uds.u.c
143: Chris Johnston 2011-08-14 [merge] [r=nigelbabu] This will set debug to true when running locally.
142: Chris Johnston 2011-08-12 [merge] [r=nigelbabu] Switches summit to using bzr_apps by running init-summit.
141: Chris Johnston 2011-08-12 [merge] [r=nigelbabu] Adds a link to the page for editing an etherpad
140: Chris Johnston 2011-08-01 [merge] Adds today link to main-nav
140: Michael Hall 2011-07-22 [merge] Adds the meeting id to the meeting_page_url, and uses only that as the lookup parameter
parameter
139: Nigel Babu 2011-07-30 [merge] [r=mhall119] Reset the theme of the documentation to default.
138: Chris Johnston 2011-07-30 [merge] [r=nigelbabu][] Remove translation tags, summit is not translated.
137: Nigel Babu 2011-07-30 [merge] [r=][] Create a docs so that it shows up in rtfd.org
136: Chris Johnston 2011-07-25 [merge] [r=mhall119][] Removes old migrations and adds new initial migration
137: Michael Hall 2011-07-20 [merge] Adds 960px style to all pages except the wide schedule
134: Chris Johnston 2011-07-20 [merge] Fixes lpupdate. Props mhall119
134: Michael Hall 2011-07-20 Make sure we don’t have periods in meeting names when trying to form the meeting page url
133: Michael Hall 2011-07-20 [merge] point logo link to http://uds.ubuntu.com
133: Michael Hall 2011-07-20 If meeting has no name, we can’t form a proper URL for it, fallback to returning no URL
132: Chris Johnston 2011-07-19 [merge] [r=mhall119][] Adds update-openids script to summit to fix usernames.
131: Chris Johnston 2011-07-19 [merge] [r=mhall119][765031] Adds private room as an option for a room status.
130: Chris Johnston 2011-07-19 [merge] [r=mhall119][793020] Modifies links to match uds.ubuntu.com
129: Michael Hall 2011-07-19 [merge] [r=mhall119][781117] Changes /today url to /summit_name/today
128: Chris Johnston 2011-07-18 [merge] [r=chrisjohnston][] Fixes a minor spelling issue in fields.py
127: Chris Johnston 2011-07-18 [merge] [r=][] Updates required version of south
126: Chris Johnston 2011-07-11 [merge] [r=][] Fixes minor spelling error
125: Chris Johnston 2011-06-26 [merge] [r=nigelbabu][chrisjohnston][798822] Adds a print statement to provide feedback
124: Chris Johnston 2011-06-17 [merge] [r=mhall119][chrisjohnston][798826] Displays information in the name field error message more clearly.
123: Maris Fogels 2011-06-17 [merge] [r=nigelbabu][mars][] Added a tests.py module and an in-memory sqlite database for running the test suite.
122: Nigel Babu 2011-06-12 [merge] [r=james-w][nigelbabu][782062] Remove the ‘.’ from the name of the meeting and replace it with ‘-’
121: Nigel Babu 2011-06-10 [merge] [r=james-w][nigelbabu][790675] Stop the screen scape and use the json API instead.
120: Nigel Babu 2011-06-11 [merge] [r=chrisjohnston,james-w][nigelbabu][783291] Removed the brainstorm code out of
119: Penelope Stowe 2011-06-11 [merge] [r=james-w,nigelbabu][Penelope Stowe] try-catching the launchpad requests with 5
118: Nigel Babu 2011-06-09 [merge] Removes Attendees list from the meeting page if the session is a plenary. Props Nigel Babu
117: Nigel Babu 2011-06-09 [merge] Adds spacing around the QR code to avoid overlap. Props Nigel Babu
116: Nigel Babu 2011-05-22 [merge] Fix authschedule to not modify anything in the past
115: Chris Johnston 2011-05-22 [merge] Add prev/next day links to schedule view
114: Michael Hall 2011-05-22 [merge] Add full path to meeting page in the ical feed
113: Michael Hall 2011-05-22 Fix errors in template, add settings option to have django serve media files even when DEBUG=False
112: Chris Johnston 2011-05-22 [merge] Disable debug mode and give better error messages
111: Nigel Babu 2011-05-22 [merge] Fixes to reschedule command
110: Michael Hall 2011-05-22 [merge] Updated setup.py and requirements.txt to match current production environment

Tests

test_sponsorship_display
test_nonlaunchpad_display
test_suggest_valid_username
test_suggest_invalid_username
test_sponsorship_review_display
test_sponsorship_about_paras_filtering
test_sponsorship_about_urlize_filtering
test_sponsorship_xss_escaping
test_sponsorshipsuggestion_review_display
test_sponsorshipsuggestion_xss_escaping
test_passing_nonexistant_summit_raises_error
test_meetings_can_not_be_scheduled_in_closed_slots
test_participants_are_in_another_meeting
test_check_schedule_errors_on_no_dial_in
test_check_schedule_errors_on_same_track_in_previous_slot
test_check_schedule_errors_on_same_track_in_next_slot
test_check_schedule_no_error_on_different_track
test_check_schedule_no_error_on_same_track_for_plenaries
test_check_schedule_no_error_on_same_track_for_ajdacent_sessions_allowed
test_try_schedule_into_refuses_room_without_dial_in
test_try_schedule_into_allows_room_with_dial_in
test_link_to_pad_with_pad_url_set
test_link_to_pad_with_pad_url_unset
test_link_to_pad_with_plus_in_meeting_name
test_edit_link_to_pad_with_pad_url_set
test_edit_link_to_pad_with_pad_url_unset
test_edit_link_to_pad_with_plus_in_meeting_name
test_ical_meeting_without_name
test_ical_meeting_name_with_period
test_private_ical
test_meeting_page_url
test_meeting_name_with_period
test_room_name_with_period
test_track_name_with_period
test_participant_name_with_period
test_meeting_name_with_percent
test_meeting_name_with_plus_sign
test_room_name_with_percent
test_room_name_with_plus_sign
test_track_name_with_percent
test_track_name_with_plus_sign
test_participant_name_with_percent
test_participant_name_with_plus_sign
test_etherpad_edit_url
test_meeting_check_schedule_no_conflict
test_meeting_check_room_conflict
test_meeting_check_schedule_participant_conflict
test_private_meeting_schedule
test_no_available_public_room
test_no_available_private_room
test_required_participant_in_private_meeting
test_percent_in_meeting_name
test_percent_in_meeting_title
test_percent_in_meeting_description
test_percent_in_spec_url
test_percent_in_wiki_url
test_percent_in_room_title
test_percent_in_meeting_track_title
test_percent_in_meeting_track_slug
test_percent_in_attendee_username
test_cache_cleared_on_meeting_change
test_cache_cleared_on_agenda_change
test_track_cache_cleared_on_meeting_change
test_track_cache_cleared_on_agenda_change
test_default_read_only
test_editable
test_read_only_for_public_summit
test_read_only_for_non_edit_request
test_read_only_for_unauthenticated_user
test_read_only_for_user_without_permission
test_default_not_personal
test_personal_if_specified_in_get
test_date_set_from_date
test_date_parsed_from_string
test_dates_set_from_summit_if_not_passed
test_room_set_from_room
test_room_set_from_summit_if_not_passed
test_rooms_include_private_if_user_is_staff
test_rooms_include_private_if_show_private
test_track_is_none_by_default
test_track_set_from_track
test_nextonly_false_by_default
test_nextonly_set_from_get_parameters
test_fakenow_none_by_default
test_fakenow_set_from_get_parameters
test_fakenow_set_to_none_if_invalid
test_calculate_unscheduled_does_nothing_when_read_only
test_calculate_unscheduled_includes_unscheduled
test_calculate_unscheduled_ignores_scheduled_meetings
test_calculate_unscheduled_ignores_meetings_in_tracks_not_in_this_room
test_calculate_unscheduled_includes_meetings_without_a_track
test_calculate_unscheduled_includes_all_meetings_in_room_without_a_track
test_calculate_unscheduled_includes_meetings_of_the_right_track
test_calculate_unscheduled_includes_meetings_with_one_right_track
test_calculate_unscheduled_ignores_plenaries_in_the_room_view
test_calculate_unscheduled_ignores_talks_in_the_room_view
test_calculate_unscheduled_ignores_specials_in_the_room_view
test_calculate_unscheduled_shows_plenaries_in_the_plenary_room_view
test_calculate_unscheduled_ignores_non_plenaries_in_the_plenary_room_view
test_update_meeting_skips_no_name
test_update_meeting_trims_name
test_update_meeting_accepts_existing_meeting
test_update_from_launchpad_response_empty
test_update_from_launchpad_response_handles_no_name
test_launchpad_sprint_import_urls_uses_default
test_launchpad_sprint_import_url_uses_one_summit_sprint
test_launchpad_sprint_import_url_uses_two_summit_sprint
test_update_from_launchpad_gets_info_for_all_import_urls
test_update_from_launchpad_does_the_update
test_update_from_launchpad_deletes_unseen_meetings
test_update_from_launchpad_doesnt_delete_meetings_with_no_spec_url
test_update_from_launchpad_updates_last_update
test_reschedule_does_nothing_on_empty_schedule
test_reschedule_removes_missing_participants
test_reschedule_removes_unavailable_participants
test_reschedule_removes_insufficient_slots
test_reschedule_leaves_old_slots
test_reschedule_leaves_manually_scheduled

Summit is the code that runs the session scheduler for the Ubuntu Developer Summit (UDS) and, as of last cycle, the Linaro Summit as well.  Summit has had a rather troubled past, being passed from one maintainer to another, evolving organically as it went.  But during UDS-N, it started gaining a team of community contributors, specifically Chris Johnston and I.  This expanded further for UDS-O, when Nigel Babu took the helm as the project manager.  We were also joined by Linaro developers who wanted to make Summit support two simultaneous events, using the same schedule, the same rooms and the same attendees.

Many changes were made in the run-up to UDS-O, and by “run-up” I mean all the way up to the first day of sessions.  Unfortunately, nowhere along Summit’s organic growth did it gain the proper test suite and deployment processes that are a necessity for a project of this size.  In fact, one of the bugs that was discovered during UDS-O was a script running on the server that wasn’t even part of Summit’s revision control tree!

Well this part of Summit’s history is coming to an end.  After UDS-O, the community developers started to plan out how to stabilize Summit, both it’s code base by adding testing, and also the deployment process by strictly managing how new code gets into production.

Bug Fixes

The bug fixing started early this cycle.  Nigel was submitting merge proposals by the end of the week of UDS-O, and Chris and I were pair-programming on the flight from JFK back to Orlando.  So far there have been 30 branch merges into the summit tree and fixes for 20 bug reports.  Nigel gives the full list over at his blog.

Setup and Development

Summit can now be easily setup for development using Virtualenv, which makes getting started with development significantly easier.  LoCo Directory recently gained a script that fully automated the setup of a development environment, and this will soon be coming to the Summit code.  At the time I’m writing this post, Jorge Castro has even begun work on an Ensemble formula, that will make deploying a fully configured instance of Summit on Amazon’s EC2 platform a matter of a few simple commands.

Making development setup easier lowers the barrier to new contributors, and we hope this will encourage more community members to get involved in such a fun and important project.  Making sure we’re all using the same development environment, and having it easily replicated for others to develop and test, will help improve the accessibility and stability of our code.

Testing

During UDS-O we got some help setting up and writing the very first testing code for Summit.  From now on, writing test cases for new features or bug fixes will become a normal part of our development process.  We recently held an online classroom session about how to write test code for Summit (and LoCo Directory too).  There is still a lot of Summit code that needs tests written for it, but we’re going to cover as much of that as we can while continuing to move forward with development.  More than any other change this cycle, I’m excited about the huge improvements to stability that we can gain through aggressively testing our code.

Branch based deployments

Summit has always used branch-based deployments, that is our production server has a copy of our bzr tree that it runs from, instead of a package that gets installed.  Unfortunately, up until last week the only branch we really had was trunk, which made it harder to properly track emergency fixes when we already had revisions committed to trunk that weren’t ready to be deployed.  To fix this we’ve split off a production branch, which is the only branch we will deploy from, and will always have a copy of the exact code that is running in production.

We will also, for the short term, have two branches for development.  The 1.x branch is our “stable” tree, that’s where we will make any changes that will be ready to deploy in the coming days or weeks.  This means that we can use our trunk branch for long-term development, where we can perform some much-needed refactoring and code cleanup, without worrying about blocking deployments while these changes settle into place.  There are some major and necessary changes coming to parts of the Summit code, and this development setup will let us start landing those quickly so that we can test them and build off them, without destabilizing the currently used code tree or blocking minor fixes from being deployed.

Ubuntu Website integration

If you visit the Summit website today, you’ll already see some of our recent changes.  To better integrate with the WordPress instance running uds.ubuntu.com, we have changed our main navigation and 960px width to match. Once the WordPress theme updates are rolled out, both sites will have the new community top navigation bar too.  No longer will it feel like you’re being thrown from one site to another without a means of getting back.  This should lead to a less confusing user experience for both sites, and much happier UDS attendees all around.

I’ve been slacking a bit when it comes to DJing land picked it up this year again. Some of my mixtapes are on a part of my blog that’s not syndicated, but I set up a page with all the posts. I just posted a new one today.

If you have no plans tonight and you’re in Berlin, come to the GNOME3 Launch Lounge (Facebook event page) in c-base tonight. I’ll be playing there as well.

This past weekend was Ubuntu Global Jam, where Ubuntu users and contributors all over the world get together to work on improving the project.  Jams come in many forms, code hacking, bug triaging, translating, documenting, or even just promoting Ubuntu in their community.  In my own corner of the Ubuntu community, a few of us got to together to work on improving the Summit project

This is the code behind http://summit.ubuntu.com, which provides the UDS scheduler and sponsorship application forms.  Summit is a Django application, released under the AGPLv3 license, and is primarily developed by community members.  Joining me were Chris Johnston,  a frequent community contributor who I’ve also worked with in LoCo Directory and other projects, and Elliot Murphy, my 3rd-level boss as Canonical (no pressure there!).

Here’s a list of what we managed to accomplish:

Switch to the new ubuntu-community-webthemes, which will give us the “mothership” top-navigation links as seen on planet.ubuntu.com and wiki.ubuntu.com

Started work on integrating Summit with Django testing framework.

Bug #643012: Register Interest should only show currently available tracks

Currently when you register your interest in a track, the form shows tracks for previous summits.  This will restrict it to just the tracks for the summit you’re registering for.

Bug #668532: /today page to display current day’s schedule

A new, permanent URL which will show the current day’s schedule, so you can bookmark it once and re-use it for each day of the summit, and even future summits!

Bug #745378: Empty sub-nav exists on sponsorship page

Removes the gray sub-navigation bar from pages where there aren’t any linkes in it.

Bug #462793: Add slots for videographers

Up to two videographers can not be assigned to a UDS session and their names will appear on the schedule.

Bug #747296: Add plenary flag to iCal feed for conventionist.com

We have been working with the makers of Conventionist, a convention management application, which will allow you to track your session schedule on your Android or iPhone, even getting directions to the correct room.  This fix was necessary for them to distinguish plenary sessions from regular ones.

Bug #747301: Add daily Crew list

Allows Summit to schedule which UDS attendees are willing to act as event crew, with the current day’s crew assignments listed on the daily schedule which is displayed on the large monitors during the event.

Bug #747303: Auto-add slots to schedule

This solved an administrative headache for those organizing the summit.  For past events, every available time slot had to be entered manually, which was a very time consuming task.  This provides them a quick way to pre-populate the time slots, with the ability to fine-tune just the ones that need it.

Bug #747419: Fix login redirect

Several features of Summit require that you log in using your SSO/Launchpad account.  However, after login you are currently redirected back to the main Summit page instead of the page you left.  This sends your current page URL as the path to redirect to after a successful login, so you no longer have to go find that page again.

I know that the Mailman 3 project is not alone in procrastinating getting out a release of its major rewrite. It's hard work to finish a rewrite on your own copious spare time. I was just chatting with Thomas Waldmann of the Moin project on IRC, and he lamented a similar story about the Moin 2 release. Then he said something that really made me sit up straight:

<ThomasWaldmann> 11.11.11 would be a great date for something :)

Yes, it would! We have the 2011 Google Summer of Code happening soon (students, you have until April 8th to submit your applications) so many free and open source software projects will get some great code coming soon. And November is far enough out that we can plan exactly what a "release" means. Here's what I propose:

Let's make November 11, 2011 the "Great FLOSS Release Day". If you're working on an open source project undergoing a major new version rewrite, plan on doing your release on 11.11.11. It can be a beta or final release, but get off your butts and make it happen! There's nothing like a good deadline to motivate me, so Mailman 3 will be there. Add a comment here if you want your project to be part of the event!

Debian just released Debian 6.0. Good work everyone!

One of my favourite applications in the Ubuntu and general Open Source world is xwax. It allows me to hook up my turntables using a Native Instruments Audio4DJ device. This way I can use music I bought on the Ubuntu One Music store using my turntables (as a controller). It’s absolutely fantastic.

Because I love xwax so much, I just set up an automatic daily build in Launchpad. The process is pretty straight-forward:

• set up a Launchpad code import of upstream trunk
• write a very short build recipe (mine basically just says: branch upstream trunk from LP and nest a branch with the packaging into the ./debian directory)
• test the build recipe
• and request build for the Ubuntu releases you’re interested in
• done.

This is seriously good work by the Launchpad and Bazaar people. I hope this will help us figure out problems in specific pieces of upstream software much earlier in the future.

SWEET!

As I mentioned earlier, today I’m working with Ara, Matthias, Michael and Yaiza at Büro 2.0 and we just finished a very funny video cast together.

Matthias ‘doko’ Klose made sure to arrive AFTER the video cast was done, but rest assured he can not evade. In recompensation he brought Father Christmas hats, so to you here’s from the Canonical Berlin team:

Merry Christmas and Happy New Year