The Community Team

So, given Jono’s departure a few weeks back, I bet a lot of folks have been wondering about the Canonical Community Team. For a little background, the community team reports into the Ubuntu Engineering division of Canonical, which means that they all report into me. We have not been idle, and this post is to discuss a bit about the Community Team going forward.

What has Stayed the Same?

First, we have made some changes to the structure of the community team itself. However, one thing did not change. I kept the community team reporting directly into me, VP of Engineering, Ubuntu. I decided to do this so that there is a direct line to me for any community concerns that have been raised to anyone on the community team.

I had a call with the Community Council a couple of weeks ago to discuss the community team and get feedback about how it is functioning and how things could be improved going forward. I laid out the following for the team.

First, there were three key things that I think that I wanted the Community Team to continue to focus on:

• Continue to create and run innovative programs to facilitate ever more community contributions and growing the community.
• Continue to provide good advice to me and the rest of Canonical regarding how to be the best community members we can be, given our privileged positions of being paid to work within that community.
• Continue to assist with outward communication from Canonical to the community regarding plans, project status, and changes to those.

The Community Council was very engaged in discussing how this all works and should work in the future, as well as other goals and responsibilities for the community team.

What Has Changed?

In setting up the team, I had some realizations. First, there was no longer just one “Community Manager”. When the project was young and Canonical was small, we had only one, and the team slowly grew. However, the Team is now four people dedicated to just the Community Team, and there are others who spend almost all of their time working on Community Team projects.

Secondly, while individuals on the team had been hired to have specific roles in the community, every one of them had branched out to tackle new challenges as needed.

Thirdly, there is no longer just one “Community Spokesperson”. Everyone in Ubuntu Engineering can and should speak to/for Canonical and to/for the Ubuntu Community in the right contexts.

So, we made some small, but I think important changes to the Community Team.

First, we created the role Community Team Manager. Notice the important inclusion of the word “Team”. This person’s job is not to “manage the community”, but rather to organize and lead the rest of the community team members. This includes things like project planning, HR responsibilities, strategic planning and everything else entailed in being a good line manager. After a rather competitive interview process, with some strong candidates, one person clearly rose to the top as the best candidate. So, I would like formally introduce David Planella (lp, g+) as the Community Team Manager!

Second, I change the other job titles from their rather specific titles to just “Community Manager” in order to reflect the reality that everyone on the community team is responsible for the whole community. So that means, Michael Hall (lp, g+), Daniel Holbach (lp, g+), and Nicholas Skaggs (lp, g+), are all now “Community Manager”.

What's Next?

This is a very strong team, and a really good group of people. I know them each personally, and have a lot of confidence in each of them personally. Combined as a team, they are amazing. I am excited to see what comes next.

In light of these changes, the most common question I get is, “Who do I talk to if I have a question or concern?” The answer to that is “anyone.” It’s understandable if you feel the most comfortable talking to someone on the community team, so please feel free to find David, Michael, Daniel, or Nicholas online and ask their question. There are, of course, other stalwarts like Alan Pope (lp, g+) and Oliver Grawert (lp, g+) who seem to be always online :) By which, I mean to say that while the Community Managers are here to serve the Ubuntu Community, I hope that anyone in Ubuntu Engineering considers their role in the Ubuntu Community to include working with anyone else in the Ubuntu Community :)

Want talk directly to the community team today? Easy, join their Ubuntu on Air Q&A Session at 15 UTC :)

Finally, please note that I love to be "interrupted" by questions from community members :) The best way to get in touch with me is on freenode, where I go by rickspencer3. Otherwise, I am also on g+, and of course there is this blog :)

Delaying Queries to a Server from Map Move Events

Last week I added BikeShare info to my map. But I also take the bus a lot. I would like the information I need to choose between taking a bus and grabbing a bike. So I need to show buses on the map. In my first iteration of showing bus data, I downloaded the XML for every bus stop in the metro system and loaded that. Unfortunately, this did not work. 

There are over 11,000 bus stops in the DC Metro System and using that may POI in a MapItemView made the map unusably slow. Even if it wasn't slow, when zoomed out on the map, the POI covered the map so it was just a huge blob of POI. Oh well, looks like I need to do something slightly more elegant. 

What I need to do is query the server every time the user moves the map, through a pan or a zoom and ask the web service for the XML for the bus stops centered on the center of the map, and within a certain radius that is slightly bigger than the map. However, if I do that for each and eveyr pan and zoom, I end up hammering the server when ever the user swipes. The web service doesn't like to be called so much so fast, and it's just a waste of resources and bandwidth. So I decided to add a little logic to only load the data after the map is "at rest" for some period of time. I chose to start with a two second rest, but it could be whatever. I did this by first creating a timer.

       Timer
       {
         id: mapRestTimer  
         running: false  
         interval: 2000  
       
       }  

Then I wrote add some event handlers to the Map, for zoom and pan events.

       onZoomLevelChanged:  
       {  
         if(zoomLevel >= minimumBusDataZoomLevel)  
         {  
           timeMapRest()  
         }  
       }  
       onCenterChanged:  
       {  
         if(zoomLevel >= minimumBusDataZoomLevel)  
         {  
           timeMapRest()  
         }  
       }  

Note that I set it up so that bus stops aren't displayed if the user is panned out too far due to the problems I mentioned above. The timeMapRest function just decides whether it needs to restart the timer, or to start it. If the timer is already running, then the user has moved the map before the rest period was up, so we'll reset the timer. Otherwise, we'll go ahead and start the timer.

   function timeMapRest()  
       {  
         if(mapRestTimer.running)  
         {  
           mapRestTimer.restart()  
         }  
         else  
         {  
           mapRestTimer.start()  
         }  
       }  

To finish up, I just had to write an onTriggered handler and set properties on my subclassed XmlListModel, which then goes ahead an updates itself based on the new latlong or zoom level.

         id: mapRestTimer  
         running: false  
         interval: 2000  
         onTriggered:  
         {  
           //stop the timer and set the new latlong  
           running: false  

           //get the info necessary to calculate the correct radius
           busStopListModel.latlong = [getThereMap.center.latitude,getThereMap.center.longitude]  
           var tr = getThereMap.toCoordinate(Qt.point(0,0))  
           var bl = getThereMap.toCoordinate(Qt.point(getThereMap.width,getThereMap.height))  
           var latdiff = bl.latitude - tr.latitude  
           var londiff = bl.longitude - tr.longitude  
           //TODO: fix this silly calculation for the radius  
           var rad = (latdiff > londiff) ? latdiff * (34.67 * 5280 / 3) : londiff * (34.67 * 5280 / 3 )  
           busStopListModel.mapRadius = rad  
         }  
       }  

The code for the whole project is here.

Adding Interactivity to a Map with Popovers

On Friday I started my app "GetThereDC". I started by adding the locations of all of the Bikeshare stations in DC to a map. Knowing where the stations are is great, but it's a bummer when you go to a station and there are no bikes, or there are no empty parking spots. Fortunately, that exact information is in the XML feed, so I just need a way to display it.  
The way I decided to do it is to make the POI (the little icons for each station on the map) clickable, and when the user clicks the POI to use the Popover feature in the Ubuntu Components toolkit to display the data.

Make the POI Clickable

When you want to make anyting "clickable" in QML, you just use a MouseArea component. Remember that each POI is constructed as a delegate in the MapItemView as an Image component. So all I have to do is add a MouseArea inside the Image and respond to the Click event. So, not my image looks like this:

           sourceItem: Image  
           {  
             id: poiImage  
             width: units.gu(2)  
             height: units.gu(2)  
             source: "images/bike_poi.png"  
             MouseArea  
             {  
               anchors.fill: parent  
               onClicked:  
               {  
                 print("The POI was clicked! ")  
               }  
             }  
           }  

This can be used anywhere in QML to make an image respond to a click. MouseArea, of course, has other useful events as well, for things like onPressed, onPressAndHold, etc...

Add the Roles to the XmlListModel

I already know that I'll want something to use for a title for each station, the address, as well as the number of bikes and the number of parking slots. Looking at the XML I can see that the "name" property is the address, so that's a bonus. Additionally, I can see the other properties I want are called "nbBikes" and "nbEmptyDocks". So, all I do is add those three new roles to the XmlListModel that I constructed before:

   XmlListModel  
   {  
     id: bikeStationModel  
     source: "https://www.capitalbikeshare.com/data/stations/bikeStations.xml"  
     query: "/stations/station"  
     XmlRole { name: "lat"; query: "lat/string()"; isKey: true }  
     XmlRole { name: "lng"; query: "long/string()"; isKey: true }  
     XmlRole {name: "name"; query: "name/string()"; isKey: true}  
     XmlRole {name: "available"; query: "nbBikes/string()"; isKey: true}  
     XmlRole {name: "freeSlots"; query: "nbEmptyDocks/string()"; isKey: true}  
   }  

Make a Popover Component

The Ubuntu SDK offers some options for displaying additional information. In old school applications these might be dialog boxes, or message boxes. For the purposes of this app, Popover looks like the best bet. I suspect that over time the popover code might get a little complex, so I don't want it to be too deeply nested inside the MapItemView, as the code will become unwieldy. So, instead I decided to add a file called BikeShareStationPopover.qml to the components sub-directory. Then I copy and pasted the sample code in the documentation to get started. 

To make a popover, you start with a Component tag, and then add a popover tag inside that. Then, you can put pretty much whatever you want into that Popover. I am going to go with a Column and use ListItem components because I think it will look nice, and it's the easiest way to get started. Since I already added the XmlRoles I'll just use those roles in the construction of each popover. 

Since I know that I will be adding other kinds of POI, I decided to add a Capital Bike Share logo to the top of the list so users will know what kind of POI they clicked. I also added a close button just to be certain that users don't get confused about how to go back to the map. So, at the end of they day, I just have a column with ListItems:

 import QtQuick 2.0  
 import Ubuntu.Components 0.1  
 import Ubuntu.Components.ListItems 0.1 as ListItem  
 import Ubuntu.Components.Popups 0.1  
 Component  
 {  
   id: popoverComponent  
   Popover  
   {  
     id: popover  
     Column  
     {  
       id: containerLayout  
       anchors  
       {  
         left: parent.left  
         top: parent.top  
         right: parent.right  
       }  
       ListItem.SingleControl  
       {  
         control: Image  
         {  
           source: "../images/CapitalBikeshare_Logo.jpg"  
           height: units.gu(5)  
           width: units.gu(5)  
         }  
       }  
       ListItem.Header { text: name}  
       ListItem.Standard { text: available + " bikes available" }  
       ListItem.Standard { text: freeSlots + " parking spots available"}  
       ListItem.SingleControl  
       {  
         highlightWhenPressed: false  
         control: Button  
         {  
           text: "Close"  
           onClicked: PopupUtils.close(popover)  
         }  
     }  
   }  
 }  

Make the Popover Component Appear on Click

So, now that I made the component code, I just need to add it to the MapItemView and make it appear on click. So, I add the tag and give it an id to the MapQuickItem Delegate, and change the onClicked handler for the MouseArea to open the popover:

 delegate: MapQuickItem  
         {  
           id: poiItem  
           coordinate: QtPositioning.coordinate(lat,lng)  
           anchorPoint.x: poiImage.width * 0.5  
           anchorPoint.y: poiImage.height  
           z: 9  
           sourceItem: Image  
           {  
             id: poiImage  
             width: units.gu(2)  
             height: units.gu(2)  
             source: "images/bike_poi.png"  
             MouseArea  
             {  
               anchors.fill: parent  
               onClicked:  
               {  
                 PopupUtils.open(bikeSharePopover)  
               }  
             }  
           }  
           BikeShareStationPopover  
           {  
             id: bikeSharePopover  
           }  
         }  

And when I run the app, I can click on any POI and see the info I want! Easy!

Code is here

It's Easy and Fun to Write Map Based Apps

Yesterday I started work on an app that I personally want to use. I don't have a car, so I use services like Metro Bus, Metro Rail, Car2Go, and BikeShare around DC all the time. It's annoying to go to each different web page or app to get the information that I want, so I decided to write an app that combines it all for me in one place.

After asking around, I settled on a best practice for Ubuntu map apps, and I was pointed to this excellent code as a basis:
http://bazaar.launchpad.net/~yohanboniface/osmtouch/trunk/view/head:/OSMTouch.qml

It was so easy and fun once I got started, that I decided to show the world. So, here we go.

I started with a "Simple UI" project. Then I deleted the default column that it started with, and I set the title of the Page to an empty string. While I was at it, I changed the height and width to be more like a phone's dimensions to make testing a little easier. So my starter code for an emply Window looks like this:

 import QtQuick 2.0  
 import Ubuntu.Components 0.1  
 import "components"  
 MainView {  
   objectName: "mainView"  
   applicationName: "com.ubuntu.developer.rick-rickspencer3.MapExample"  
   width: units.gu(40)  
   height: units.gu(60)  
   Page  
   {  
     title: i18n.tr("")  
   }  
 }  

So what's missing now is a map. First I need to import the parts of Qt where I get location and map information, so I add these imports:

 import QtPositioning 5.2  
 import QtLocation 5.0  

Then I can use the Map tag to add a Map to the MainView. I do four things in the Map to make it show up. First, I tell it to fill it's parent (normal for any component). Then I set it's center property. I choose to do this using a coordinate. Note that you can't make a coordinate in a declarative way, you have to construct it like below. The center property tells the map the latitude and longitude to be centered on. Then I choose the zoom level, which determines the scale of the map. Finally, I need to specify the plug in. For various reasons, I choose to use the Open Street Maps plugin, though feel free to experiment with others. So, a basic funcitonal map looks like this:

   Page  
   {  
     title: i18n.tr("")  
     Map  
     {  
       anchors.fill: parent  
       center: QtPositioning.coordinate(38.87, -77.045)  
       zoomLevel: 13  
       plugin: Plugin { name: "osm"}  
     }  
    }  

When I run it, I get a lot of functionality for free. On the desktop I can drag the map, and when I run the app on my phone or tablet, I can pinch to zoom in or out. All that functionality comes for free. Of course, you are free to add mapping controls as desired, but I find that map works well out of the box, at least on a device that supports pinch and zoom.

Typically, a map displays little pinpoints. These are often referred to as Points of Interest, or more typically "POI". It's delightfully easy to populate your map with POI using our old friend XmlListModel. First, you will need some XML that has location information. For this exmaple, I am going to use the Bike Share feed for Washington, DC. It's easy to get and to parse, so it makes a nice example. You can see the feed here:
https://www.capitalbikeshare.com/data/stations/bikeStations.xml

So let's use it to set up our XmlListModel. First, of course, we need to import the XmlListModel functionality.

 import QtQuick.XmlListModel 2.0  

Next, we'll make the list model, and use the query and Roles functionality to set up the model with the latitude and longitude of each POI inside the model. This is *exactly* like using the XmlListModel for a typical list view. Very cool.

   XmlListModel  
   {  
     id: bikeStationModel  
     source: "https://www.capitalbikeshare.com/data/stations/bikeStations.xml"  
     query: "/stations/station"  
     XmlRole { name: "lat"; query: "lat/string()"; isKey: true }  
     XmlRole { name: "lng"; query: "long/string()"; isKey: true }  
   }  

Now that I have my list model set up, it's time to display them on the Map. We don't do that with a ListView, but rather wtih a MapItemView. This works exactly the same as a ListView, except it displays items on a map instead of in a list. Just like a ListView I need a delegate that will translate use data from the each item in the XmlListModel to create a UI element. In this case, it's a MapQuickItem instead of a ListItem (or similar). A MapQuickItem needs to know 4 things.

1. The model where it will get the data. In this case, it's my XmlListModel, but it could be a javascript list or other model as well.
2. A latitude and longitude for the POI, which I set up as roles in the XmlListModel.
3. An offset for whatever I am using for POI so that it is positioned properly. In this case I have made a little pushpin image out of the bikeshare logo (I know it's bad I'll make a better one later :) ). The offset is set by anchorPoint, so I make the anchorPoint the bottom and center of of the pushpin. 
4. Something to use for the POI. In this case, I choose to use an image. Note that it is important to use grid units, or the POI may appear too small on some devices, and too large on others. Grid Units make them "just right" on all devices, and ensure that users can click them on any device. 

So, here is my MapItemView that goes *inside* the Map tag. It's a MapItemView for the map, after all.

       MapItemView  
       {  
         model: bikeStationModel  
         delegate: MapQuickItem  
         {  
          id: poiItem  
          coordinate: QtPositioning.coordinate(lat,lng)  
          anchorPoint.x: poiImage.width * 0.5  
          anchorPoint.y: poiImage.height  
          sourceItem: Image  
          {  
            id: poiImage  
            width: units.gu(2)  
            height: units.gu(2)  
            source: "bike_poi.png"  
          }  
         }  
       }  

Now when I run the app, the POI are displayed. As you would expect, when the user moves the Map, the MapItemView automatically displays the correct POI. It's really that easy.

If you want to add interactivity, that's easy, you can simply add a MouseArea to the Image and then use things like Ubuntu.Components.Popups to popup additional information about the POI. 


This sample code is here: http://bazaar.launchpad.net/~rick-rickspencer3/+junk/MapExample/view/head:/MapExample.qml

Rick's Ubuntu for Phones FAQ

Why is the Ubuntu Team So Excited about Ubuntu for Phones?

13.10 represents a major step forward for the Ubuntu project, because the Ubuntu phone images feature a set of new technologies that solve many of the longstanding difficulties with Ubuntu distros. Specifically:

1. Image based updates
2. A complete SDK
3. Application Isolation
4. Click packages and click installer with app store
5. Mir Display Server and Window Manager
6. Unity 8

Image based updates

Image based updates are a new of getting updates on Ubuntu. In the past, all versions of Ubuntu (and on Ubuntu Server and Desktop for 13.10 and beyond) updates were done with apt. Apt is the tool for debian package management. It was capable of calculating which packages needed to be updated or upgraded, and then ran those updates. Apt works well on servers and desktops because it supports complicated dependencies. However, it also takes a lot of computing horsepower to compute the updates or upgrades, and due to it being complicated, could occasionally get into situations that needed to be fixed with some command line options.

Ubuntu needed to take much less energy and time to perform updates, and needed to be much more reliable. This is where image-based updates come in. The Ubuntu images for phones have a read only file system by default, and a specific partitioning scheme for the drives. User data and applications are kept on a separate partition from the underlying system. As a result, if our update servers know which build you are running, they have an exact copy of the system on the servers. So rather than calculating package upgrade paths on your computer, the server can simply calculate a binary diff and the phone downloads only the diff for the system. Ubuntu then applies the diff and reboots into the update image. This has the added benefit that the downloads of the updates are much smaller, since users only have to download what has changed.

This all happens over the air. You can access this function from the Updates panel of the system settings application. Note that the phone can still be put into “system builder mode” which allows a user full access to all of the power of Apt, if they want to hack on their phones.

A Complete SDK

Ubuntu for phones provides three ways of developing applications for end users:

1. Web apps
2. Phone gap
3. Ubuntu SDK

Web apps and phone gap support is tried and true technology for delivering HTML 5 applications to end users and we are proud to offer these options to developers. But what if you want to write a native app that looks like the core Ubuntu applications? Ubuntu now offers an SDK which includes the QtCreator development environment, the Qt library, the Ubuntu UI Toolkit, and many Ubuntu services, such as the Friends API for writing socially connected apps.

Application Isolation

Ubuntu on the phone runs applications under App Armour. App Armour is a kernel feature which ensures that processes are simply not able to access any resources to which they are not entitled. In this way, application are kept from interfering with each other or the underlying system in any way. This keeps the user safe from both malicious applications that may try to snoop on other applications, use services to which they are not entitled, or other naughtiness. Developers can write applications that interact with other applications, but only through strictly defined and secure APIs.

One result of this much higher level of isolation, is that applications do not need to go through the same degree scrutiny to ensure that they are safe. As such, we can publish new applications to stable releases orders of magnitude faster than ever before. It often takes less than 30 minutes for an application to be submitted, reviewed, and appear in the application store.

Click Packages

Ubuntu for phones offers a brand new and much simpler means of packaging and installing applications. For other Ubuntu images, apps needed to be packaged as debian files (.deb files). This required the developer to have significant skill in packaging in order to manage the dependencies.

Click packages are much simpler because applications can depend only upon the “base sdk” which is installed on all phones, or on libraries bundled directly with the application. Since click packages are uploaded to the store and run under application isolation, it is very easy and fast for an application developer to get their applications to users.

Mir Display Server and Window Manager

The Ubuntu Desktop has always depended on implementations of the X11 protocol (xorg). This technology is more than 20 years old and designed for very different systems than are available today. Between the complexity of the protocol and the drivers, it is a significant effort to deliver a stable and fast system to end users. Even with this effort, their systems sometime regress or break, especially if the users are using drivers from their GPU chip vendor. Writing a window manager on top of this protocol also turned out to be very complex, often due to differences in the implementations of APIs in the GPU drivers, and also due to complexities in the X11 protocol.

The Mir display server solves these problems by offering a simpler and more direct library to both GPU driver developers and Window Manager authors. Mir is also designed to work easily with existing Android drivers.

The Mir display server on Ubuntu for phones is carefully designed by the Ubuntu design team, and takes advantage of the simpler more direct Mir API to deliver faster development and a better user experience.

Mir display server and window manager are currently optimized for phones and to some degree tablets, but will grow over the next few releases to provide a full desktop experience as well.

Unity 8

Finally, Ubuntu phone images feature the latest version of the Ubuntu shell, called “Unity 8”. It features enhancements to the launcher and to indicators that make them very user friendly even when operated with just a thumb while holding a phone, as well as the latest iteration of the dash that includes scopes optimized for mobility, providing touch optimized access to music, video, and applications.

What is “Ubuntu Touch”?

“Ubuntu Touch” is the development codename for the special images of Ubuntu that were created to run on phones and tablets. There are some technical differences in terms of how the phones are updated, which apps can run and how they are installed, and the display server. However, these differences are small compared to the similarities. Officially, these images are simply named “Ubuntu”.

How Do I Get and Use Ubuntu on a Phone?

Ubuntu 13.10 will have images that work for the Galaxy Nexus and the Nexus 4. They are available in the normal places. However, phones require special steps for installing a new OS. Aside from the officially supported images, the community has created a set of ports for their own devices, you can find that list here: https://wiki.ubuntu.com/Touch/Devices

Will Ubuntu Work on My Tablet?

We are making Ubuntu images for the first version of the Nexus 7 and the Nexus 10. These images are available alongside images for phones, and the installation experience is similar. However, please note that we in Ubuntu prioritized making Ubuntu working for phones for 13.10, so the tablet images are still in “early preivew stages” There are bugs and missing functionality. We plan to focus on tablets more fully for 14.04.

Is Ubuntu Finished for Phones?

Yes and no. We are proud that Ubuntu 13.10 is a complete 1.0 solution for powering your phone. Many of us have been using Ubuntu as our on our only phone for months. However, it does have one or two features that you may miss and that will be added very soon. For example, Ubuntu 13.10 does not have a lock screen when running on a phone. There are some settings, such as a convenient airplane mode that have not been implemented yet, but will be shortly.

Of course, we also have a list of enhancements and new features for the 14.04 as well!

If I Install Ubuntu on my Phone, How Will it be Supported?

The images for phones feature a new way to update that we call “image based updates”. For about a month after we release 13.10, expect to get updates for only the most critical bugs. However, after about a month, all users will be upgraded to the current development version. This will allow users to get the latest features and bug fixes without having to wait six months.

Can I Run my Favorite Application on My Phone?

This depends on the application. If your favorite app is a web app, then you are in luck. Ubuntu ships many web applications in a manner that is well integrated into the overall phone experience. Also, there is a good chance that your favorite application has a version made especially to run on phones running Ubuntu. However, applications that require a keyboard and mouse, or that require a toolkit that is not supported on Ubuntu will not run on the phone until it is ported.

Can I Run a Desktop from My Phone Like I’ve Seen in Demos?

This represents our ultimate goal for what what we call “convergence”, one device with all the functionality you need from various devices converged together. In 13.10 we have made great strides towards convergence. Most of the software running on Ubuntu for desktop images and Ubuntu for phone images is the same. However, Ubuntu does not yet have the capability for a phone to dock into a desktop, yet. We continue to work very hard toward this goal, and all of our development is geared towards reaching it.

The Big Rocks of August

Have you ever heard the phrase "If you don't put the big rocks in first, you'll never get them in at all"? It's from an oft repeated parable about life and also project management.

Last week I met with Canonical's Ubuntu Engineering leadership team (me, the Directors, Engineering Managers, Tech Leads, and Architects). We took a close look at the progress of Ubuntu Touch from many points of view. All in all, I left last week feeling quite satisfied that Ubuntu Touch for phones was on track for a very good 1.0 release in October. However, we identified that there were some "big rocks" that we didn't get in the jar yet, and that we needed to get them in asap if we were going to finish with the kind of systematic development process that will be necessary to make 13.10 rock.

So, we set the goal for August to get all the big rocks in. The 5 big rocks ...

Image Based Upgrades

Blueprint is here

The first big rock is Image Based Upgrades. Today, when we "bless" a new image, one must use a tool on your desktop called "phablet-flash" to update to that new image. After August, the phone will download updates over wireless and install them without requiring a connection to the desktop. As you can see in the blueprint, this requires some deep changes to the way Ubuntu works (as well as to our automated testing) in order to do it as robustly as is necessary for this market (a.k.a. no "dpkg --configure -a"). The disks must be partitioned so that the system is total separate from user data. The server must calculate the binary diff of an update for that partition, and the diff must be applied safely and reliably.

All of this work is in place now on the client and server and being tested. Wet need to bring it together and start using it. We will do so in August.

Indicators

Ubuntu touch is designed to support user settings in 2 ways. The most common and dynamic settings are available from the indicators, others from the settings application.

The settings application has a long tail of settings, some more important than others. The indicators, have limited, but critical functionality. By the end of August, all of the indicators will be functional. As a result, most of the back-end work will be in place to finish settings in September and October as well.

Click

Martin Albeseti is working on a new video, but there is as starter one here if you want to see an end to end demo.

How developers write applications, how users install applications, and how those applications run ... what a huge topic. By the end of August, Ubuntu Touch will be doing this in a different and new way.

Of course, we all know that developers will use the sweet Ubuntu SDK to get write their sweet apps ;) However, did you know that developers will not need to package those apps into deb files? Rather they will make a simple click package that includes their code and all of their dependencies (in the case that they have dependencies that are not part of the SDK). Click packages are easy to create with Click, and support for this is even built into Qt Creator. So writing and packaging an app is now, finally, fun and easy for Ubuntu Touch.

But how will users find applications to install in Ubuntu Touch? Developers will be able to upload their applications and after a very quick review to ascertain that the requested permissions (more on that below) are reasonable, users will be able to find their apps in the apps lens! What could be easier. With a simple button click in the dash, the application will be downloaded and installed by Click.

The reason we can do such a light review is due to the something called "application confinement" which has already landed and is running on Ubuntu Touch today. Application confinement causes an application to run under apparmour, which means that the kernel controls what it has access to. As such, it is very very difficult for an application to do anything naughty.

Now, an application that is totally confined may be useful, but it may be desirable for an app to interact with data from other apps. For example, what if you wanted to import a picture from the phone? To support that, there will be a series of trusted helpers and services which can securely provide an application the data that it needs with a few simple SDK calls.

After August, when Click is working end to end on the phone, we can spend September and October adding the rest of the important features, like updating applications.

Application Lifecycle

Speaking of SDK calls, how do applications behave on the phone? On the desktop, an application can just run and run, because they have big batteries and are normally plugged in. So, a traditional Linux desktop does nothing to manage an application's use of resources.

This can't work on a phone. The reason this can't work is that phones have small batteries and are rarely plugged in. So a typical phone OS does not allow applications to just do what they want.

For Ubuntu Touch, when an application is put into the background today, it is stopped. Not killed, just stopped. The app can't use any resources and is essentially "frozen in time" until it comes to the front again. This ensures that a crazy application is only consuming resources when it is in the front, where the user is using.

But we have some work to do in August to finish the application lifestyle. First, what happens when you have so many applications open that there is no more memory? The OS has to do something to make room. In Ubuntu Touch, the OS will kill any stopped applications that haven't been used in a while in the case of low memory. But wait! you say. Won't that mean my apps get killed and I have to relaunch them and lose all my work and everything?

The answer to this problem is simple, when an application goes into the background, it will get a signal and a little time. The application can use the time to save whatever info it needs to rebuild itself in the case it gets killed while it is in the background. When the app gets called to the foreground, it can then use a little time to read whatever info it saved and rebuild itself. The result for the user will be that the app appears to just keep on running. Nice!

But Wait! What about apps that should work in the background? For example, the Music Player should keep playing while it is in the background, right? The answer to this is "sort of". An app shouldn't do anything that it would want to do in the background, but it should rather use services that work outside the scope of any one app. So the Music Player shouldn't make function calls to play music, but should rather call a system service and tell the system service what music to play.

There are several services like this that we will need in place by end of August, these include:

1. Music
2. Download
3. Telephony
4. Alarms (time)
5. Friends
6. Content
7. URI Handler
8. NITZ
9. Contacts

These services are "complete" when one can use them from the Ubuntu SDK.

Unity 8/Mir

Finally, Unity 8 (for phone only right now) is in the archive. Mir is almost in the archive. It's time to get these into the phone images so that we can spend September and October doing some nice refinements!

Conclusion

Of course not everyone in the Ubuntu community is working solely on these big rocks. So lots of other exciting stuff will happen as well. However, It's important that we get these 5 big rocks done in August. That will leave us September and part of October for us to work on the remaining list of features and requirements in priority order. After August, Ubuntu Touch will have made a dramatic step forward, really becoming the architecture that it is meant to be. I can't wait!

Passing and Being Passed

Buckley. A dog I get to pet, but do not have to walk!

Co-Working Change My Life
I got some feedback from my wife and kids last week that I seem generally happier and more "tuned in" when I am at home than I have in the past few years. Additionally  I have been feeling much more productive at work. I chalk these changes up almost totally to adopting a co-working lifestyle.

I'm sure you are all away that Canonical is mostly a distributed company. We work from all over the world in online spaces. This is great. It has meant that I have gotten to know people from all the world. I've learned a little French. I make my own schedule. Working for a distributed company has been so enriching in so many ways, I don't see how I could ever go back to a real office environment.

Working for a distributed company has also meant that I have been working at home the last 4+ years. In many ways, this has been great. I've spent zero hours commuting, as one small example. 
Office Nomads

The friendly and helpful proprietors of Office Nomads

For various reasons, I decided to give co-working a try, and I am surprised how well I have taken to it. Co-working means that I "go to work" in a large shared office space. Practically, it means that I share resources such as networking, printers, desks, dogs, etc... 

Some nomads doing their thing

The area where I work. I usually take the standing desk to the left.

On the impractical side, it means that I share in the positivity of other people also doing what they love. Hearing people work, chatting with folks when I get in, having lunch with other people, etc... This has all been great for me, personally. I think there is a certain element of just getting out of the house and not being isolated. But the atmosphere at Office Nomads is high productivity, and I can't help but to feed off the buzz. I think the community building aspects of their mission is harmonious with my values, as well.

If you work in a distributed environment, I highly recommend giving co-working a try. If you are working independently in Seattle, I strongly recommend you join Office Nomads. 

Getting There

It's been a very unreal sprint in Seattle. Reliably nice weather most days. So, since I am traveling to Office Nomads, I take my bicycle almost every day. This builds  in free exercise for me, and is slightly faster than the bus. As a result, I have been biking more and more.

I flatter myself to think that I am relatively fit these days. None the less, I get passed by other bicyclists most days. When I get passed, I notice. I noticed that I have about three responses when this happens.

• Nice Bike! Often I am passed by much more serious bicyclists, and I notice their bikes costs many times what mine costs. However, this thought is really a small cop out. The fact is, they are all probably more fit and better at bicycling than I am, and generally invest more effort it in, that's why they are passing me. If we switched bikes, they'd still be faster than me.
• Good for you! This is more typical. I can admire that the passer is more engaged, fitter, and just generally cares more about going fast at this point in time than I do. Someone going faster than me takes absolutely nothing away from my experience, and it's cool that they an do it.
• Oops. Sometimes when I get passed I realize that my mind has wandered. I forgot to keep going fast. This is helpful. Realizing that I am daydreaming instead of focused on going fast, I can decide, to go fast, or maybe I decide I am happy day dreaming. In this way, someone passing me not only doesn't take anything from me, but it grants me something positive.

I pass more people than pass me, by a wide margin. Sometimes on longer, lonelier, rides, I observer other bicyclists as I pass them. The overwhelming majority of people I pass show essentially no response. They couldn't care less that I am passing them. Some folks even take advantage of the situation and draft behind me. They can go a little faster "for free" by letting my cut through the air for them.

However, sometimes, I sense a certain amount of rage from people I pass. I can see it in their faces and body language. The fact that I am fitter and working harder takes nothing from these people, but it seems to bother them that someone can go faster than them. For this set of people, a common response is for them to work really hard to pass my back. This means that my presence was helpful for them if they want to go faster, but often, it's not sustainable for them, and I end up soon passing them again, and leaving them far behind. These folks end up with a self-inflicted net loss. They have a loss of pleasure, and they end up being driven by being passed, rather than being driven by what they want to do. A shame, really.

As an aside, one time I was coming back from a very long ride, and took a break, going slowly for a few miles before my final push home. During this time, I heard someone pumping behind me. Finally, I was passed by someone clearly working to get back in shape. I was going the perfect speed for them, just fast enough that it was a challenge to pass me. As he passed, and I saw the look of pride mixed with exhaustion on his face, my heart went out to him. When it was time for me to go fast again, I quickly caught up with him, but then I fell behind. I just didn't have the heart to show him what going really fast looks like.