Canonical Voices

Posts tagged with 'article'

David Planella

Get your apps ready for the Showdown!

phone-apps-grid-extended

So the time to get your apps ready for the Ubuntu App Showdown deadline is drawing to a close. It’s been a fun ride and it’s been truly inspiring to see the r/UbuntuAppShowdown reddit and the Ubuntu App Developers G+ page boiling with activity with participants showcasing the progress of their apps and developers helping each other with questions and answers. We are very much excited to see and use the cool applications you’ve all created.

This is a reminder for everyone to start submitting their applications to the Software Store and fill in the participation form. You can already send your apps and upload new updates, but only until Sunday, 15th Sept at 23:59 UTC.

Register your participation

To make sure your application is registered for the contest and judges review it, you’ll need to fill in the participation form. You can start filling it in already and until the submission deadline, it should only take you 2 minutes to complete.

Fill in the Showdown participation form ?

Submit your app

The final and most important step will be to submit your app to the store, so that judges and users can start reviewing them. Essentially, you’ll need to package up your application using the click format with Qt Creator and submit it online
as instructed on the developer site.

Those of you with apps using C++ extensions will need to include the compiled extensions manually into a click package until the infrastructure pieces are in place in the platform.

Submit your app to the Store

Design questions?

For those of you who have design questions for your apps, we’re starting a weekly design clinic where you can talk directly to Ubuntu Touch designers. The first Ubuntu Touch Design Clinic starts today, 11 Sept at 13:00 UTC at Ubuntu on Air.

Looking forward to seeing your apps on the phone and let the Showdown countdown start!

Read more
Michael Hall

After many months of hard work, I’m very proud to be announcing a beta launch of the click packages software store, as part of the 2013 Ubuntu App Showdown Contest.

This beta is exclusively aimed at Ubuntu Touch apps that have been built using the Ubuntu SDK.

Once you upload your apps, they will go through a brief review and will be available on the latest image of Ubuntu Touch for download. Please take into account the current beta does not support selling apps yet, so you will only be able to upload free (as in speech) apps.

Keep in mind the store is currently under heavy development, so you might encounter bugs and workflow changes as we work through different issues.

If you have any questions about uploading click packages or bugs, please pop into our IRC channel, #ubuntu-app-devel.

Find out how to submit your Ubuntu Touch app here: http://developer.ubuntu.com/publish/

If you are interested in the development of the software store or the click format, all discussions are currently being held in a mailing list you are welcome to join, and the process so far has been pretty thoroughly documented in the wiki.

Read more
Michael Hall

Today we are announcing our second Ubuntu App Showdown! Contestants will have six weeks to build and publish their apps using the new Ubuntu SDK and Ubuntu Touch platform. Both original apps and ported apps, native and HTML 5, will qualify for this competition.

phone-naturally-neat

The winners of this contest will each receive an LG Nexus 4 phone running Ubuntu Touch with their application pre-installed. Furthermore, each of the winners will have an opportunity to have their app included in the default Ubuntu install images for phones and tablets.

All valid entries will also become available for install on Ubuntu Touch devices from the Apps lens in the Dash, using the new Click packages and MyApps submission process.

Judges

The jury will be composed by a team of five judges:

  • Jono Bacon, Ubuntu Community Manager
  • Joey-Elijah Sneddon, writer and editor-in-chief of OMG!Ubuntu
  • Lisette Slegers, User Experience Designer at Canonical
  • Nekhelesh Ramananthan, Ubuntu Touch Core App developer
  • Bill Filler, Engineering Manager for the Phone & Tablet App Team

Review criteria

The jury will judge applications according to the following criteria:

  • General Interest – apps that are of more interest to general phone users will be scored higher. We recommend identifying what most phone users want to see, and identifying gaps that your app could fill.
  • Features – a wide range of useful and interesting features.
  • Quality – a high quality, stable, and bug-free application experience.
  • Design – your app should harness the Ubuntu Design Guidelines so it looks, feels, and operates like an Ubuntu app.
  • Awareness / Promotion – we will award extra points to those of you who blog, tweet, facebook, Google+, and otherwise share updates and information about your app as it progress.

If you are not a programmer and want to share some ideas for cool apps, be sure to add and vote apps on our reddit page.

How To Enter

The contest is free to enter and open to everyone.

The six week period starts on the Wed 7th August 2013!

Enter the Ubuntu App Showdown

Read more
Anthony Lenton

Top 10 Ubuntu App Downloads for July

The productivity app, Spindl, debuts in the top 10 paid apps for July. While MC-Launcher was popular in July, it has been removed from the Software Center recently for unknown reasons. In the free apps category, three new apps make their debut. The game, Wakfu, comes in at number four in the list with two YouTube downloading tools, Minitube and All Video Downloader, coming in at #2 and #4.

Want to develop for the new Phone and Tablet OS, Ubuntu Touch? Be sure to check out the “Go Mobile” site for details.

Top 10 paid apps

  1. Filebot
  2. MC-Launcher
  3. Quick ‘n Easy Web Builder
  4. Fluendo DVD Player
  5. Spindl [NEW]
  6. UberWriter
  7. Bastion
  8. Drawers
  9. Braid
  10. Linux Format Magazine – Issue 173 [NEW]

Top 10 free apps

  1. Steam
  2. Minitube [NEW]
  3. Wakfu [NEW]
  4. All Video Downloader [NEW]
  5. Master PDF Editor
  6. Youtube to MP3
  7. CrossOver (Trial)
  8. Plex Media Server
  9. IntelliJ IDEA 12 Community Edition
  10. Motorbike

Would you like to see your app featured in this list and on millions of user’s computers? It’s a lot easier than you think:

Notes:

  • The lists of top 10 app downloads includes only those applications submitted through My Apps on the Ubuntu App Developer Site. For more information about of usage of other applications in the Ubuntu archive, check out the Ubuntu Popularity Contest statistics.
  • The top 10 free apps list contains gratis applications that are distributed under different types of licenses, some of which may not be open source. For detailed license information, please check each application’s description in the Ubuntu Software Center.

Follow Ubuntu App Development on:

Social Media Icons by Paul Robert Lloyd

Read more
Steve George

Today we are pleased to announce the beta release of the Ubuntu SDK! The SDK is the toolkit that will power Ubuntu’s convergence revolution, giving you one platform and one API for all Ubuntu form factors. This lets you write your app one time, in one way, and it will work everywhere.  You can read the full Ubuntu SDK Beta announcement here.

For the developers who are already writing apps using the Ubuntu SDK most of the beta’s features will already be known, as they have been landing in the daily releases as they become finished. Here’s a list of the features that have been added since the alpha:

  • Cordova Ubuntu HTML5 app template – leverage the Apache Cordova APIs to write Ubuntu apps with web technologies: HTML, JavaScript and CSS. Write your first HTML5 with the Cordova Ubuntu tutorial.
  • Ubuntu SDK HTML5 theme – a companion to all HTML5 apps: stylesheets and JavaScript code to provide the same look and feel as native apps
  • Responsive layout – applications can now adopt a more natural layout depending on form factor (phone, tablet, desktop) and orientation
  • Scope template – Scopes enable operators to prioritise their content, to achieve differentiation without fragmentation. Now easier to create with a code template
  • Click packaging preview – initial implementation of the Click technology to distribute applications. Package your apps with Click at the press of a button
  • Theme engine improvements – a reworked theme engine to make it easier and more flexible to customise the look and feel of your app
  • Unified Actions API – define actions to be used across different Ubuntu technologies: the HUD, App Indicators, the Launcher, the Messaging Menu
  • U1DB integration – the SDK now provides a database API to easily synchronise documents between devices, using the Ubuntu One cloud

Some of the biggest news here is the Cordova support and HTML5 theme, which brings together our goal of making first class HTML5 app that look and feel like native apps.  Cordova support means that apps written using the PhoneGap framework can be easily ported to Ubuntu Touch, and the HTML5 themes, written largely by community developer Adnane Belmadiaf, will allow those apps to match the native SDK components in both the way they look as well as the way the user interacts with them.

The Responsive Layouts, which landed in the daily SDK packages weeks go, gives developers the ability to adjust their application’s GUI dynamically at runtime, depending on the amount of screen space available or any number of other variables.  This is one key to making convergent apps that can adapt to be useful on both small touch screens and large monitors with a keyboard and mouse.

We’ve also put out the first set of Click packaging tools, which will provide an easier way for developers to package and distribute their applications both on their own and through the Ubuntu Software Center.  There is still a lot more work to do before all of the Click infrastructure is in place, but for now developers can start trying getting a feel for it.

All of that and more is now available, so grab the latest SDK packages, read the QML and HTML5 app development tutorials, and get a head start building your convergent Ubuntu application today!

Read more
Steve George

Ubuntu Edge

Today we took the wraps off a campaign to build the world’s first truly convergent Superphone: the Ubuntu Edge.  With top of the line hardware running Ubuntu software, the Ubuntu Edge will dual boot Ubuntu Touch as well as Ubuntu for Android, and will run the full Ubuntu desktop when docked to an external keyboard, monitor and mouse.

We have started a community funding campaign to raise the cost of building these phones.  Reserve your Ubuntu Edge today as the discounted price of only $600 USD (£394) today!  After 4pm BST on Tuesday July 23rd the price for the device will go up to $830, so don’t wait.

Community Funded

Like Ubuntu itself, the creation of the Ubuntu Edge phone is a community endeavor, which is why we’re using an Indie GoGo campaign to raise the cost of building these devices.  All of the money raised will go towards manufacturing and delivering the phone to the people who contribute.  That means you get the phone basically at the cost of manufacturing it (or less if you contribute $600 in the first 24 hours of the campaign).

Crowd funding plays two important roles for Ubuntu Edge.  First and most obviously it will cover the expense of this manufacturing run.  But more importantly it will also show other manufacturers and carriers that there is a great demand not just for Ubuntu phones, but fully convergent Superphones.  Even if you are unable to contribute enough to get a phone, your smaller donation to the campaign will still advance that second goal of spreading awareness.

The money collected in this campaign will not be used to fund Canonical’s normal business activity, it will all go towards manufacturing a limited number these high-end Ubuntu Edge devices.  Nor will Canonical be turning into a hardware company, we are still actively engaged with OEMs who are interested in building their own Ubuntu powered phones, and this campaign does not change those relationships at all.  This campaign is solely for the purpose of developing a limited number of ultra-high-end convergent devices to kick off a new generation of mobile phones based on Ubuntu’s convergent technologies.

Technical Details

The Ubuntu Edge will not be just another phone, it will be the first in a new breed of convergent superphones.  Being able to run a full productive desktop environment from a device that fits into your pocket is no small feat, and to do that we will use the very best hardware available, making Ubuntu Edge a top-of-the-line device not only now and when it will ship in May 2014, but for quite some time after as well.

  • Dual-boot Ubuntu Edge into either Ubuntu or Android
  • Becomes a fully integrated Ubuntu desktop PC when docked
  • Fast and powerful device with multi-core CPU and at least 4GB RAM
  • 128GB of storage for photos, music, content
  • 4.5in 1,280 x 720 HD display with pure sapphire crystal screen, the hardest natural substance after diamond
  • Cameras made for low-light, fast response and close up pictures: 8mp rear camera, 2mp front
  • Faster connection all over the world with dual-LTE, dual-band 802.11n Wi-Fi, Bluetooth 4, NFC
  • Connect to HDMI TVs and monitors easily with MHL connector, 3.5mm jack
  • GPS, accelerometer, gyro, proximity sensor, compass, barometer
  • Stereo speakers with HD audio, dual-mic recording, Active Noise Cancellation
  • Silicon-anode Li-Ion battery
  • 64 x 9 x 124mm.

With a quad-core processor, 4GB of RAM and 128GB of storage, this little device will be capable of satisfying most desktop computing needs.  It’s sapphire crystal glass is virtually unscratchable, so you’ll have a perfect, clear display for the lifetime of the phone.  Even the battery will be using the revolutionary silicon-anode technology that will provide higher energy density and faster charging.

For App Developers

When designing the Ubuntu Edge, we didn’t just pick the biggest and best technologies, we also thought about how to make it better for Ubuntu Touch and apps written with the Ubuntu SDK.  Using that as a guide, the size and physical design of Ubuntu Edge are built to complement the edge-swipe gestures that are unique to Ubuntu Touch.  You can easily access all 4 edges of the screen while holding the phone in one hand, giving users an unobstructed view of your entire app while still putting controls in easy reach.  Ubuntu Edge will give your app the best user experience of any device currently on the market.

Get yours now!

There will only be a limited number of Ubuntu Edge devices made, once this campaign ends so does your chance to get one for yourself!  Since we announced our plans to enter the mobile phone market with Ubuntu we have been asked where people can buy one, so now you have your chance.  And if you contribute within the first 24 hours you can get your Ubuntu Edge phone at a huge discount! Go to our campaign page and make your donation today!

Read more
Anthony Lenton

Top 10 Ubuntu App Downloads for June

Top 10 Ubuntu Apps

Filebot takes over the top spot for June as the North American summer heats up while Quick ‘n Easy Web Builder moves into the #2 spot. Not much change in the Free Top 10. Steam continues it’s reign at the top.

Want to develop for the new Phone and Tablet OS, Ubuntu Touch? Be sure to check out the “Go Mobile” site for details.

Top 10 paid apps

  1. Filebot
  2. Quick ‘n Easy Web Builder
  3. Fluendo DVD Player
  4. Mini Minecraft Launcher
  5. MC-Launcher
  6. Braid
  7. UberWriter
  8. Drawers
  9. HDD Ranger
  10. Robotux

Top 10 free apps

  1. Steam
  2. Motorbike
  3. Master PDF Editor
  4. Youtube to MP3
  5. Plex Media Server
  6. Screencloud
  7. CrossOver (Trial)
  8. IntelliJ IDEA 12 Community Edition
  9. Nitro
  10. Splashtop Streamer for Ubuntu Linux

Would you like to see your app featured in this list and on millions of user’s computers? It’s a lot easier than you think:

Notes:

  • The lists of top 10 app downloads includes only those applications submitted through My Apps on the Ubuntu App Developer Site. For more information about of usage of other applications in the Ubuntu archive, check out the Ubuntu Popularity Contest statistics.
  • The top 10 free apps list contains gratis applications that are distributed under different types of licenses, some of which may not be open source. For detailed license information, please check each application’s description in the Ubuntu Software Center.

Follow Ubuntu App Development on:

Social Media Icons by Paul Robert Lloyd

Read more
David Planella

Participate in the Ubuntu Core Apps Hack Days and get involved in developing the essential apps of Ubuntu on phones.

Starting this Wednesday, and during the next three weeks, we’re organizing a set of Hack Days inviting all interested contributors to bring Ubuntu Touch up another step closer to a production release and to ensure all core apps have reached a state of functionality to be used every day.

With the Core Apps Hack Days we’re targeting several objectives:

  • Get all core apps into a ‘dogfoodable’ state
  • Find and fix critical bugs in core apps and their dependencies
  • Identify, record and fix gaps in functionality
  • Get new developers involved in Core Apps and Ubuntu Touch development in general
  • Have fun with Ubuntu App Development!

How the Hack Days will work

  • The Ubuntu Core Apps Hack Days will be run as virtual hackfests on the #ubuntu-app-devel IRC channel on Freenode
  • Everyone is free to join the channel and encouraged to pick a task related to the set of goals to get core apps to a dogfoodable state
  • The development and testing tasks will be posted on the Hack Days wiki before each day’s hackfest starts
  • Ask Michael Hall (mhall119), David Planella (dpm) or Alan Pope (popey) on the channel for any help when you join (or just say hi!)

When

  • Starting on Wednesday 10th of July until Thursday 25th of July
  • From 9:00 UTC to 21:00 UTC
  • We’ll be following this schedule:
10 July Calendar
11 July Music
12 July Clock
15 July Calculator
16 July Weather
17 July Sudoku Touch
18 July RSS Reader
19 July File Manager
22 July Document Viewer
23 July Terminal
24 July Dropping Letters
25 July Stock Ticker

Join us!

Participating in the Hack Days is extremely easy: you just need a working Internet connection and access to IRC. We simply recommend some preparation beforehand:

  1. Learn how to get started developing core apps
  2. Join the #ubuntu-app-devel IRC channel on Freenode

Looking forward to seeing you next Wednesday at the Calendar hackfest!

Read more
Chris Jones

Help shaping up Ubuntu Touch by joining the core apps development teams

Community-driven apps that will power the next million phones

The Ubuntu Core Apps project started as an initiative born out of the initial Ubuntu Touch announcement, with a call to our community to participate in building the core set of applications which will be considered for shipping on Ubuntu phones.

With this, we started an exciting project that provides a unique opportunity for community members to create Free Software that could run on millions of handsets.

If you’re running Ubuntu Touch on a device, you can already see the results of the work our amazing volunteer developers have been doing: Calculator, Clock, Calendar, Weather, Terminal, File Manager… these apps and more are part of this project. Together with the Canonical designers and other community designers, we’ve also got a solid UX and design story for our applications.

In essence, each core app development team organizes their work and time in the way that works best for them, where the Canonical Community, Design and Engineering teams participate in several different areas:

  • Development infrastructure
  • Engineering management
  • Community mentorship and support
  • Design guidance

With this post I’d like to share how any developer can contribute to core apps and join the core dev teams. It’s not only an opportunity to shape up Ubuntu Touch, but also to work in a truly open development environment, with the best Open Source developers and designers out there!

Participating in the core apps project

Getting started to contributing to core apps is just a few minutes away. Here are some really easy steps for developers to get all set up.

Step 1: install all core apps

While some of the apps are already installed on the Ubuntu Touch image, you’ll be doing your development on the desktop. As part of the convergency story, core apps run equally well on phones, tablets or desktops, so the first step will be to get familiar with them and do some dogfooding.

  1. Open a terminal by pressing Ctrl+t and type the commands below, followed by Enter.
  2. Install the Ubuntu SDK: sudo add-apt-repository ppa:canonical-qt5-edgers/qt5-proper && sudo add-apt-repository ppa:ubuntu-sdk-team/ppa && sudo apt-get update && sudo apt-get install ubuntu-sdk
  3. Install the core apps: sudo add-apt-repository ppa:ubuntu-touch-coreapps-drivers/daily && sudo apt-get update && sudo apt-get install touch-coreapps

If you get stuck here, check out the SDK’s getting started page or ask on Ask Ubuntu

At this point you’ll be able to launch any of the core apps from the Dash.

  • Try opening the Dash clicking on the Ubuntu button in the Launcher, and type the first letters of each one of the apps to launch them. You should now be able to install:
    1. Calculator
    2. Calendar
    3. Clock
    4. Document viewer
    5. Dropping Letters
    6. Email
    7. File Manager
    8. Music
    9. RSS Reader
    10. Stock Ticker
    11. Sudoku
    12. Terminal
    13. Weather

Step 2: pick an app and find something to work on

Once you’ve road-tested all of the apps, you’ll have a good overview of their functionality, and where you think you can help. At this point, the best thing to do is to pick an app you’re interested in contributing to and find more about it:

  1. Go to the core apps overview page
  2. Click on the app you’re interested in. This will show you:
    • The public project where the app is being developed and where the code is hosted
    • The development team who is writing the app
    • The IRC channel where to discuss about the app’s development in real time
    • The blueprint we use to track the items to work on to implement the functional requirements
    • The burn-down chart we use to provide an overview of the status of the work

The best way to get started is to look at the existing code for the app. Here’s how:

  1. If you haven’t already, open a terminal with Ctrl+t and type this command to install the Bazaar revision control system: sudo apt-get install bzr
  2. Get a local copy of the code. Run this command, replacing ubuntu-clock-app by the app you’ve chosen. You’ll find the exact name to replace on the project section of the app’s detail page you opened earlier on: bzr branch lp:ubuntu-clock-app
  3. Start Qt Creator, the Ubuntu’s SDK IDE by clicking the Ubuntu button on the Launcher and typing “ubuntu sdk”
  4. In Qt Creator, press Ctrl+o to navigate to the location where you’ve just downloaded the code to and choose the .qmlproject file to open the app’s project in the IDE
  5. You can now study the code and launch it with either the Ctrl+r key combination or by pressing the big green “Run” button in Qt Creator

Before you start doing any changes in the code, you might want to get in touch with us to ensure no one is already working on what you’re intending to start on. Two good places to look at are:

Step 3: send a merge proposal with your contribution

In our distributed collaborative environment, where thousands of volunteers participate in Ubuntu from all over the world, we use a distributed version control system, Bazaar to manage the code’s revisions.  The code for all core apps is hosted in public projects in Launchpad, the online tool where we do all development.

You can easily do your changes to the code locally, publish them in a public branch and then send a request for the core app development teams to review and merge your code.

Check out the core apps development guide for the full details ›

Many ways to contribute

Although development is where you can make most of an impact at this point, there are many other ways to participate. You can:

Get in touch

We’d like to hear from you!. If you’ve got QML programming skills and would be interested in joining one of the core apps teams, get in touch with Michael Hall, David Planella or Alan Pope and we’ll gladly guide you in the first steps to becoming a core app dev.

You can also join any of the public IRC core app development meetings.

Looking forward to welcoming you in the core apps project!

Read more
niemeyer

Note: This is a candidate version of the specification. This note will be removed once v1 is closed, and any changes will be described at the end. Please get in touch if you’re implementing it.

Contents


Introduction

This specification defines strepr, a stable representation that enables computing hashes and cryptographic signatures out of a defined set of composite values that is commonly found across a number of languages and applications.

Although the defined representation is a serialization format, it isn’t meant to be used as a traditional one. It may not be seen entirely in memory at once, or written to disk, or sent across the network. Its role is specifically in aiding the generation of hashes and signatures for values that are serialized via other means (JSON, BSON, YAML, HTTP headers or query parameters, configuration files, etc).

The format is designed with the following principles in mind:

Understandable — The representation must be easy to understand to increase the chances of it being implemented correctly.

Portable — The defined logic works properly when the data is being transferred across different platforms and implementations, independently from the choice of protocol and serialization implementation.

Unambiguous — As a natural requirement for producing stable hashes, there is a single way to process any supported value being held in the native form of the host language.

Meaning-oriented — The stable representation holds the meaning of the data being transferred, not its type. For example, the number 7 must be represented in the same way whether it’s being held in a float64 or in an uint16.


Supported values

The following values are supported:

  • nil: the nil/null/none singleton
  • bool: the true and false singletons
  • string: raw sequence of bytes
  • integers: positive, zero, and negative integer numbers
  • floats: IEEE754 binary floating point numbers
  • list: sequence of values
  • map: associative value→value pairs


Representation

nil = 'z'

The nil/null/none singleton is represented by the single byte 'z' (0x7a).

bool = 't' / 'f'

The true and false singletons are represented by the bytes 't' (0x74) and 'f' (0x66), respectively.

unsigned integer = 'p' <value>

Positive and zero integers are represented by the byte 'p' (0x70) followed by the variable-length encoding of the number.

For example, the number 131 is always represented as {0x70, 0x81, 0x03}, independently from the type that holds it in the host language.

negative integer = 'n' <absolute value>

Negative integers are represented by the byte 'n' (0x6e) followed by the variable-length encoding of the absolute value of the number.

For example, the number -131 is always represented as {0x6e, 0x81, 0x03}, independently from the type that holds it in the host language.

string = 's' <num bytes> <bytes>

Strings are represented by the byte 's' (0x73) followed by the variable-length encoding of the number of bytes in the string, followed by the specified number of raw bytes. If the string holds a list of Unicode code points, the raw bytes must contain their UTF-8 encoding.

For example, the string hi is represented as {0x73, 0x02, 'h', 'i'}

Due to the complexity involved in Unicode normalization, it is not required for the implementation of this specification. Consequently, Unicode strings that if normalized would be equal may have different stable representations.

binary float = 'd' <binary64>

32-bit or 64-bit IEEE754 binary floating point numbers that are not holding integers are represented by the byte 'd' (0x64) followed by the big-endian 64-bit IEEE754 binary floating point encoding of the number.

There are two exceptions to that rule:

1. If the floating point value is holding a NaN, it must necessarily be encoded by the following sequence of bytes: {0x64, 0x7f, 0xf8, 0x00 0x00, 0x00, 0x00, 0x00, 0x00}. This ensures all NaN values have a single representation.

2. If the floating point value is holding an integer number it must instead be encoded as an unsigned or negative integer, as appropriate. Floating point values that hold integer numbers are defined as those where floor(v) == v && abs(v) != ∞.

For example, the value 1.1 is represented as {0x64, 0x3f, 0xf1, 0x99, 0x99, 0x99, 0x99, 0x99, 0x9a}, but the value 1.0 is represented as {0x70, 0x01}, and -0.0 is represented as {0x70, 0x00}.

This distinction means all supported numbers have a single representation, independently from the data type used by the host language and serialization format.

list = 'l' <num items> [<item> ...]

Lists of values are represented by the byte 'l' (0x6c), followed by the variable-length encoding of the number of pairs in the list, followed by the stable representation of each item in the list in the original order.

For example, the value [131, -131] is represented as {0x6c, 0x70, 0x81, 0x03, 0x6e, 0x81, 0x03, 0x65}

map = 'm' <num pairs> [<item key> <item value>  ...]

Associative maps of values are represented by the byte 'm' (0x6d) followed by the variable-length encoding of the number of pairs in the map, followed by an ordered sequence of the stable representation of each key and value in the map. The pairs must be sorted so that the stable representation of the keys is in ascending lexicographical order. A map must not have multiple keys with the same representation.

For example, the map {"a": 4, 5: "b"} is always represented as {0x6d, 0x02, 0x70, 0x05, 0x73, 0x01, 'b', 0x73, 0x01, 'a', 0x70, 0x04}.


Variable-length encoding

Integers are variable-length encoded so that they can be represented in short space and with unbounded size. In an encoded number, the last byte holds the 7 least significant bits of the unsigned value, and zero as the eight bit. If there are remaining non-zero bits, the previous byte holds the next 7 bits, and the eight bit is set on to flag the continuation to the next byte. The process continues until there are non-zero bits remaining. The most significant bits end up in the first byte of the encoded value, which must necessarily not be 0x80.

For example, the number 128 is variable-length encoded as {0x81, 0x00}.


Reference implementation

A reference implementation is available, including a test suite which should be considered when implementing the specification.


Changes

draft1 → draft2

  • Enforce the use of UTF-8 for Unicode strings and explain why normalization is being left out.
  • Enforce a single NaN representation for floats.
  • Explain that map key uniqueness refers to the representation.
  • Don’t claim the specification is easy to implement; floats require attention.
  • Mention reference implementation.

Read more
Chris Jones

One of the key aspects in developing the Ubuntu Touch core apps has been Quality Assurance. With that goal in mind, we’ve been adding functional tests to each and every one of the applications, using Autopilot.

We want to ensure our core apps are rock-solid, and we’d like to invite each of you who want to help make it happen to participate in the Autopilot Hackfest today. Here’s how:

  1. Join the #ubuntu-quality IRC channel ›
  2. Read the Autopilot tutorial ›
  3. Read Nick Skagg’s blog post for more details ›

Looking forward to the new autopilot tests for core apps. See you there!

Image: Autopilot Engaged CC-BY-SA by Mike Miley

Read more
David Planella

Time does fly, and we’re alread on the last day of the Ubuntu Developer Summit. Lots of content covered and still lots of interesting discussions to be had. We’re thrilled to bring you the summary on what’s on today on the App Development track.

Here’s the list of app development sessions for today at UDS:

Hope to see you there!

Read more
David Planella

After a very productive kick off, we’re back with the second day of the Ubuntu Developer Summit on the App Development track and the summary of sessions for today. Thank you everyone who participated in the sessions yesterday, either in hangouts or in IRC.

Here’s the list of app development sessions for today:

See you there!

Read more
David Planella

UDS, the Ubuntu Developer Summit, is here again, starting in just a few hours. A week packed with content that will define the plans for the new Ubuntu development cycle, and as usual, a with a full track dedicated to application development.

So for all of you interested in helping and being part of the effort of making Ubuntu a platform of choice for application developers, here’s a quick list with an overview of the sessions we’ve got in store for today.

The links in the list below will take you to the each session, ready to participate on the live hangout or on IRC. You can also check out the full UDS schedule.

So, without further ado, here’s the list of app development sessions for today:

Looking forward to seeing you there!

Read more
John Pugh

That time has once again arrived…the Top 10 for April. Stormcloud continues to reign the top with Fluendo DVD moving into the second spot in paid applications. The Top 10 Free apps has not changed much from last month with Steam continuing to dominate the Free Top 10.

Want to develop for the new Phone and Tablet OS, Ubuntu Touch? Be sure to check out the “Go Mobile” site for details.

Top 10 paid apps

  1. Stormcloud
  2. Fluendo DVD Player
  3. War in a Box – Paper Tanks
  4. Splice [NEW]
  5. Filebot
  6. UberWriter [NEW]
  7. Quick ‘n Easy Web Builder
  8. Braid
  9. Drawers
  10. Bastion

Top 10 free apps

  1. Steam
  2. Master PDF Editor
  3. Youtube to MP3
  4. Nitro
  5. Plex Media Server
  6. CrossOver (Trial)
  7. Motorbike
  8. IntelliJ IDEA 12 Community Edition
  9. flareGet
  10. Splashtop Streamer

Would you like to see your app featured in this list and on millions of user’s computers? It’s a lot easier than you think:

Notes:

  • The lists of top 10 app downloads includes only those applications submitted through My Apps on the Ubuntu App Developer Site. For more information about of usage of other applications in the Ubuntu archive, check out the Ubuntu Popularity Contest statistics.
  • The top 10 free apps list contains gratis applications that are distributed under different types of licenses, some of which may not be open source. For detailed license information, please check each application’s description in the Ubuntu Software Center.

Follow Ubuntu App Development on:

Social Media Icons by Paul Robert Lloyd

Read more
niemeyer

A few years ago, when I started pondering about the possibility of porting juju to the Go language, one of the first pieces of the puzzle that were put in place was goyaml: a Go package to parse and serialize a yaml document. This was just an experiment and, as a sane route to get started, a Go layer that does all the language-specific handling was written on top of the libyaml C scanner, parser, and serializer library.

This was a good initial plan, but for a number of reasons the end goal was always to have a pure Go implementation. Having a C layer in a Go program slows down builds significantly due to the time taken to build the C code, makes compiling in other platforms and cross-compiling harder, has certain runtime penalties, and also forces the application to drop the memory safety guarantees offered by Go.

For these reasons, over the last couple of weeks I took a few hours a day to port the C backend to Go. The total time, considering full time work days, would be equivalent to about a week worth of work.

The work started on the scanner and parser side of the library. This took most of the time, not only because it encompassed more than half of the code base, but also because the shared logic had to be ported too, and there was a need to understand which patterns were used in the old code and how they would be converted across in a reasonable way.

The whole scanner and parser plus header files, or around 5000 code lines of C, were ported over in a single shot without intermediate runs. To steer the process in a sane direction, gofmt was called often to reformat the converted code, and then the project was compiled every once in a while to make sure that the pieces were hanging together properly enough.

It’s worth highlighting how useful gofmt was in that process. The C code was converted in the most convenient way to type it, and then gofmt would quickly put it all together in a familiar form for analysis. Not rarely, it would also point out trivial syntactic issues. A double win.

After the scanner and parser were finally converted completely, the pre-existing Go unmarshaling logic was shifted to the new pure implementation, and the reading side of the test suite could run as-is. Naturally, though, it didn’t work out of the box.

To quickly pick up the errors in the new implementation, the C logic and the Go port were put side-by-side to run the same tests, and tracing was introduced in strategic points of the scanner and parser. With that, it was easy to spot where they diverged and pinpoint the human errors.

It took about two hours to get the full suite to run successfully, with a handful of bugs uncovered. Out of curiosity, the issues were:

  • An improperly dropped parenthesis affected the precedence of an expression
  • A slice was being iterated with copying semantics where a reference was necessary
  • A pointer arithmetic conversion missed the base where there was base+offset addressing
  • An inner scoped variable improperly shadowed the outer scope

The same process of porting and test-fixing was then repeated on the the serializing side of the project, in a much shorter time frame for the reasons cited.

The resulting code isn’t yet idiomatic Go. There are several signs in it that it was ported over from C: the name conventions, the use of custom solutions for buffering and reader/writer abstractions, the excessive copying of data due to the need of tracking data ownership so the simple deallocating destructors don’t double-free, etc. It’s also been deoptimized, due to changes such as the removal of macros and in many cases its inlining, and the direct expansion of large unions which causes some core objects to grow significantly.

At this point, though, it’s easy to gradually move the code base towards the common idiom in small increments and as time permits, and cleaning up those artifacts that were left behind.

This code will be made public over the next few days via a new goyaml release. Meanwhile, some quick facts about the process and outcome follows.

Lines of code

According to cloc, there was a total of 7070 lines of C code in .c and .h files. Of those, 6727 were ported, and 342 were 12 functions that were left unconverted as being unnecessary right now. Those 6727 lines of C became 5039 lines of Go code in a mostly one-to-one dumb translation.

That difference comes mainly from garbage collection, lack of forward declarations, standard helpers such as append, range-based for loops, first class slice type with length and capacity, internal OOM handling, and so on.

Future work code can easily increase the difference further by replacing some of the logic ported with more sensible options available in Go, such as standard abstractions for readers and writers, buffered writing support as availalbe in the standard library, etc.

Code clarity and safety

In the specific context of the work done, which is of a scanner, parser and serializer, the slice abstraction is responsible for noticeable clarity gains in the code, when compared to the equivalent logic based on pointer arithmetic. It also gives a much more comforting guarantee of correctness of the written code due to bound-checking.

Performance

While curious, this shouldn’t be taken as a performance comparison between the two languages, as it is comparing a fine tuned C implementation with something that is worse than a direct one-to-one port: not only it hasn’t seen any time at all on preventing waste, but the original logic was deoptimized due to changes such as the removal of inlining macros and the expansion of large unions. There are many obvious changes to be done for improving performance.

With that out of the way, in a simple decoding benchmark the C-backed decoder runs on about 37% of the time taken by the out-of-the-box deoptimized Go port.

Output size

The previous goyaml.a Go package file had 1463kb. The new one has 1016kb. This difference includes glue code generated for the integration.

Considering only the .c and .h files involved in the port, the C object code generated with the standard flags used by the go build tool (-g -O2) sums up to 789kb. The equivalent Go code with the standard settings compiles to 664kb. The 12 functions not ported are also part of that difference, so the difference is pretty much negligible.

Build time

Building the 8 .c files alone takes 3.6 seconds with the standard flags used by the go build tool (-g -O2). After the port, building the entire Go project with the standard settings takes 0.3 seconds.

Mechanical changes

Many of the mechanical changes were done using regular expressions. Excluding the trivial ones, about a dozen regular expressions were used to swap variable and type names, drop parenthesis, place brackets in the right locations, convert function declarations, and so on.

Read more
niemeyer

Last week I was part of a rant with a couple of coworkers around the fact Go handles errors for expected scenarios by returning an error value instead of using exceptions or a similar mechanism. This is a rather controversial topic because people have grown used to having errors out of their way via exceptions, and Go brings back an improved version of a well known pattern previously adopted by a number of languages — including C — where errors are communicated via return values. This means that errors are in the programmer’s face and have to be dealt with all the time. In addition, the controversy extends towards the fact that, in languages with exceptions, every unadorned error comes with a full traceback of what happened and where, which in some cases is convenient.

All this convenience has a cost, though, which is rather simple to summarize:

Exceptions teach developers to not care about errors.

A sad corollary is that this is relevant even if you are a brilliant developer, as you’ll be affected by the world around you being lenient towards error handling. The problem will show up in the libraries that you import, in the applications that are sitting in your desktop, and in the servers that back your data as well.

Raymond Chen described the issue back in 2004 as:

Writing correct code in the exception-throwing model is in a sense harder than in an error-code model, since anything can fail, and you have to be ready for it. In an error-code model, it’s obvious when you have to check for errors: When you get an error code. In an exception model, you just have to know that errors can occur anywhere.

In other words, in an error-code model, it is obvious when somebody failed to handle an error: They didn’t check the error code. But in an exception-throwing model, it is not obvious from looking at the code whether somebody handled the error, since the error is not explicit.
(…)
When you’re writing code, do you think about what the consequences of an exception would be if it were raised by each line of code? You have to do this if you intend to write correct code.

That’s exactly right. Every line that may raise an exception holds a hidden “else” branch for the error scenario that is very easy to forget about. Even if it sounds like a pointless repetitive task to be entering that error handling code, the exercise of writing it down forces developers to keep the alternative scenario in mind, and pretty often it doesn’t end up empty.

It isn’t the first time I write about that, and given the controversy that surrounds these claims, I generally try to find one or two examples that bring the issue home. So here is the best example I could find today, within the pty module of Python’s 3.3 standard library:

def spawn(argv, master_read=_read, stdin_read=_read):
    """Create a spawned process."""
    if type(argv) == type(''):
        argv = (argv,)
    pid, master_fd = fork()
    if pid == CHILD:
        os.execlp(argv[0], *argv)
    (...)

Every time someone calls this logic with an improper executable in argv there will be a new Python process lying around, uncollected, and unknown to the application, because execlp will fail, and the process just forked will be disregarded. It doesn’t matter if a client of that module catches that exception or not. It’s too late. The local duty wasn’t done. Of course, the bug is trivial to fix by adding a try/except within the spawn function itself. The problem, though, is that this logic looked fine for everybody that ever looked at that function since 1994 when Guido van Rossum first committed it!

Here is another interesting one:

$ make clean
Sorry, command-not-found has crashed! Please file a bug report at:

https://bugs.launchpad.net/command-not-found/+filebug

Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.2.3 final 0
Distributor ID: Ubuntu
Description:    Ubuntu 13.04
Release:        13.04
Codename:       raring
Exception information:

unsupported locale setting
Traceback (most recent call last):
  File "/.../CommandNotFound/util.py", line 24, in crash_guard
    callback()
  File "/usr/lib/command-not-found", line 69, in main
    enable_i18n()
  File "/usr/lib/command-not-found", line 40, in enable_i18n
    locale.setlocale(locale.LC_ALL, '')
  File "/usr/lib/python3.2/locale.py", line 541, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

That’s a pretty harsh crash for the lack of locale data in a system-level application that is, ironically, supposed to tell users what packages to install when commands are missing. Note that at the top of the stack there’s a reference to crash_guard. This function has the intent of catching all exceptions right at the edge of the call stack, and displaying a detailed system specification and traceback to aid in fixing the problem.

Such “parachute catching” is a fairly common pattern in exception-oriented programming and tends to give developers the false sense of having good error handling within the application. Rather than actually guarding the application, though, it’s just a useful way to crash. The proper thing to have done in the case above would be to print a warning, if at all, and then let the program run as usual. This would have been achieved by simply wrapping that one line as in:

try:
    locale.setlocale(locale.LC_ALL, '')
except Exception as e:
    print("Cannot change locale:", e)

Clearly, it was easy to handle that one. The problem, again, is that it was very natural to not do it in the first place. In fact, it’s more than natural: it actually feels good to not be looking at the error path. It’s less code, more linear, and what’s left is the most desired outcome.

The consequence, unfortunately, is that we’re immersing ourselves in a world of brittle software and pretty whales. Although more verbose, the error result style builds the correct mindset: does that function or method have a possible error outcome? How is it being handled? Is that system-interacting function not returning an error? What is being done with the problem that, of course, can happen?

A surprising number of crashes and plain misbehavior is a result of such unconscious negligence.

Read more
John Pugh


Hot on the heels of the Game Developer’s Conference in San Francisco we bring you the Top 10 Ubuntu App downloads for March 2013.
Stormcloud continues its rule at the top of the charts and the “far out” puzzle game, Machinarium is right behind it at #2. No surprise that Steam continues to dominate the top Free chart.
We saw some really cool technology at the Game Developer’s Conference, met some super nice people, and demonstrated the Ubuntu Phone and Tablet to a ton of people at the show.

Top 10 paid apps

  1. Stormcloud
  2. Machinarium
  3. Fluendo DVD Player
  4. War in a Box – Paper Tanks [NEW]
  5. Filebot
  6. Quick ‘n Easy Web Builder
  7. Braid
  8. Legend of Grimrock
  9. Mini Minecraft Launcher
  10. Linux Tycoon [NEW]

Top 10 free apps

  1. Steam
  2. Master PDF Editor
  3. Youtube to MP3
  4. Splashtop Streamer
  5. Plex Media Server
  6. Motorbike
  7. CrossOver (Trial)
  8. Nitro
  9. flareGet
  10. IntelliJ IDEA 12 Community Edition

Would you like to see your app featured in this list and on millions of user’s computers? It’s a lot easier than you think:

Notes:

  • The lists of top 10 app downloads includes only those applications submitted through My Apps on the Ubuntu App Developer Site. For more information about of usage of other applications in the Ubuntu archive, check out the Ubuntu Popularity Contest statistics.
  • The top 10 free apps list contains gratis applications that are distributed under different types of licenses, some of which may not be open source. For detailed license information, please check each application’s description in the Ubuntu Software Center.

Follow Ubuntu App Development on:

Social Media Icons by Paul Robert Lloyd

Read more
John Pugh

Canonical is again attending the Game Developer Conference in San Francisco. This year we will be in the ever popular Unity Partner Pavilion located in the South Hall #1002. The show floor is open from Wednesday to Friday March 27 – 29.

Stop by our kiosk for a demonstration of the Unity3d export for Ubuntu and see how easy it is to submit games to the Ubuntu Software Center via our App Developer Program.  Let us show you the benefits of Ubuntu, the painless submission process, and how we can help you access millions of Ubuntu users. We will have Ubuntu running on phones and tablets so you can touch the future of Ubuntu on mobile.

You will not want to miss a talk about monetising games and how to go mobile on the Ubuntu platform to be presented Wednesday, 27 March at 1:55 p.m. in the Unity Booth Theater on the exhibit floor in the South Hall.

Follow us on Twitter, Facebook or on G+ for updates while we are there.

See you at the Game Developer’s Conference!

Read more
Daniel Holbach

Hot on the heels of the announcements of the Ubuntu SDK and the Touch Developer Preview, we bring you the first ever Ubuntu SDK Days.

Make apps happen on all of these devices

On Thursday, 14th March and Friday, 15th March a number of app developers and Ubuntu SDK creators will get you started writing apps for Ubuntu on multiple devices. It’s surprisingly simple, and since the announcement we’ve seen many early adopters try out the SDK and the first apps up and running. We will  answer your questions, talk about best practises and show you the power of the SDK.

Here a quick overview over the sessions we’ll run:

  • Installing and Configuring the SDK
  • Writing your first app with the SDK
  • Writing games with QML and Javascript
  • Live update from the development progress of the Touch Core Apps
  • Several Q&A sessions
  • Making the best of the Ubuntu App Design guidelines
  • More about the SDK skunkworks projects
  • Introducing Friends and Gwibber QML
  • Writing a new generation of Scopes
  • Lightning talks and Project demos

How to join

Participating is easy: just head to http://ubuntuonair.com to watch the sessions on the schedule. Videos will be available after the event, to ensure you can watch the content even if you couldn’t make it to the session you wanted.

You can ask your questions on the chat widget on http://ubuntuonair.com or join the #ubuntu-app-devel IRC channel on Freenode directly.

Check out https://wiki.ubuntu.com/UbuntuSDKDays/ to see the timetable of the event, be there for lots of fun and bring your friends – and your questions too!

Read more