Noting that this week I delivered three hour long sessions of interest to those interested in writing HTML5 apps for Ubuntu:
Ubuntu’s Display Server Mir is gaining more and more traction and the team is making good progress on the platforms that are at the core of Ubuntu. Mir is proving itself everyday to be the exact technology that Ubuntu needs to power mobile devices. Mir’s features are on par with the requirements that we put […]Read more
Starting at 1400 UTC today, and continuing all week long, we will be hosting a series of online classes covering many aspects of Ubuntu application development. We have experts both from Canonical and our always amazing community who will be discussing the Ubuntu SDK, QML and HTML5 development, as well as the new Click packaging and app store.
You can find the full schedule here: http://summit.ubuntu.com/appdevweek-1403/
We’re using a new format for this year’s app developer week. As you can tell from the link above, we’re using the Summit website. It will work much like the virtual UDS, where each session will have a page containing an embedded YouTube video that will stream the presenter’s hangout, an embedded IRC chat window that will log you into the correct channel, and an Etherpad document where the presenter can post code examples, notes, or any other text.
Use the chatroom like you would an Ubuntu On Air session, start your questions with “QUESTION:” and wait for the presenter to get to it. After the session is over, the recorded video will be available on that page for you to replay later. If you register yourself as attending on the website (requires a Launchpad profile), you can mark yourself as attending those sessions you are interested in, and Summit can then give you a personalize schedule as well as an ical feed you can subscribe to in your calendar.
If you want to use the embedded Etherpad, make sure you’re a member of https://launchpad.net/~ubuntu-etherpad
That’s it! Enjoy the session, ask good questions, help others when you can, and happy hacking.Read more
Today we announced the start of the next Ubuntu App Showdown, and I have very high hopes for the kinds of apps we’ll see this time around. Our SDK has grown by leaps and bounds since the last one, and so much more is possible now. So go get yourself started now: http://developer.ubuntu.com/apps/
Earlier today Jono posted his Top 5 Dream Ubuntu Apps, and they all sound great. I don’t have any specific apps I’d like to see, but I would love to get some multi-player games. Nothing fancy, nothing 3D or FPS. Think more like Draw Something or Words With Friends, something casual, turn-based, that lets me connect with other Ubuntu device users. A clone of one of those would be fun, but let’s try and come up with something original, something unique to Ubuntu.Read more
I wrote earlierthat I was having a new roof put on my house. Well that all starter unceremoniously at 7:30am on Monday, and the hammering over my head has been going on non-stop for two full working days. Everybody who joined me on a Google+ Hangout has been regaled with the sounds of my torment. It looks nice though, so there’s that.
Well, new-ish. We heavily revamped the Apps section to include more walk-through content to help new Ubuntu app developers learn the tools, the process and the platform. If you haven’t been there yet, you really should give it a read and get yourself started: http://developer.ubuntu.com/apps/
In addition to the developer portal itself, I was able to publish new HTML5 API docs for the 14.04 release of Ubuntu. Not only does this include the UbuntuUI library from the previous release, it also introduced new platform APIs for Content Hub, Online Accounts and Alarms, with more platform APIs coming soon. The Cordova 3.4 API docs are proving harder to parse and upload than I anticipated, but I will hopefully have them published soon. If you’re an HTML5 app developer, you’ll be interested in these: http://developer.ubuntu.com/api/html5/sdk-14.04/
While not exactly a secret, we did start to make some noise about the new Scopes framework and Unity Dash that bring in a lot of improvements. As much as I liked the Home lens searching everything and aggregating results, it just wasn’t reaching the potential we had hoped for it. The new setup will allow scopes to add more information that is specific to their result types, control how those results are displayed, and more clearly brand themselves to let the user know what’s being searched. You can read more about the enhancements at http://developer.ubuntu.com/2014/02/introducing-our-new-scopes-technology/ Like I said, it’s been a crazy busy week. And we’re not done yet!Read more
There’s been a lot of talk about Ubuntu’s phone and tablet development over the last year, and it’s great that it’s getting so much attention, but people have been getting the name of it all wrong. Now, to be fair, this is a problem entirely of our own making, we started off talking about the phone (and later tablet) developments as “Ubuntu Touch”, and put most of the information about on our wiki under a page named Touch. But there is no Ubuntu Touch! It’s not a separate OS or platform, there is only one OS and it’s simply called Ubuntu.
What people are referring to when they say Touch or Ubuntu Touch, is really just Ubuntu with Unity 8. Other than the shell (and display server that powers it), it’s the same OS as you get on your desktop.
Everything under the hood is the same: same tools, same filesystem, even the same version of them, because it’s all built from the same source. Calendar data is stored in the same place, audio and video is played through the same system, even the Unity APIs are shared between desktop and phone.
So why is the name important? Not only is it more accurate to call them both Ubuntu, it’s also one of the (in my opinion) most exciting things about having an Ubuntu phone. You’re not getting a stripped down embedded Linux OS, or something so customized for phones that it’s useless on your desktop. You’re getting a fully featured, universal operating system, one that can do everything you need from a phone and everything you need from a desktop.
This is the key to Ubuntu’s convergence strategy, something that nobody else has right now. Android makes a terrible desktop OS. So does iOS. Chrome OS won’t work for a phone either, nor OSX. Even Microsoft has built two different platforms for mobile and desktop, even if they’ve slapped the same interface on both.
But with Ubuntu, once Unity 8 comes to the desktop, you will have the same OS, the same platform, on all of your devices. And while you will run the same version of Unity on both, Unity 8 is smart enough to change how it looks and how it works to meet the needs and capabilities of what you’re running it on. Better still, Unity will be able to make these changes at run time, so if you dock your convertible tablet to a keyboard, it will automatically switch from giving you a tablet interface to a desktop interface. All of your running apps keep running, but thanks to the Ubuntu SDK those too will automatically adjust to work as desktop apps.
So while “Ubuntu Touch” may have been a useful distinction in the beginning, it isn’t anymore. Instead, if you need to differentiate between desktop and mobile versions of Ubuntu, you should refer to “Unity 8″ if talking about the interface, or “Ubuntu for phones” (or tablet) if you’re talking about device images or hardware enablement. And if you’re a developer and you are talking about the platform APIs or capabilities, you’re talking about the “Ubuntu SDK”, which is already available on both desktop and mobile installs of Ubuntu.Read more
This last weekend I was in LA at SCALE12x and gave a presentation providing a detailed update of much of the work going on as we build a convergent Ubuntu. As I have mentioned before, there is lots of other foundational pieces being built as part of this work (app insulation, SDK, click packages, developer.ubuntu.com, platform services etc), and this presentation covered where we stand today in this work.
Obviously a lot more of you couldn’t be at SCALE than couldn’t, so I have recorded the presentation to share online. You can see it below or click here to watch it. Enjoy!Read more
For much of the past year I’ve been working on the Ubuntu API Website, a Django project for hosting all of the API documentation for the Ubuntu SDK, covering a variety of languages, toolkits and libraries. It’s been a lot of work for just one person, to make it really awesome I’m going to need help from you guys and gals in the community.
To help smooth the onramp to getting started, here is a breakdown of the different components in the site and how they all fit together. You should grab a copy of the branch from Launchpad so you can follow along by running: bzr branch lp:ubuntu-api-website
First off, let’s talk about the framework. The API website uses Django, a very popular Python webapp framework that’s also used by other community-run Ubuntu websites, such as Summit and the LoCo Team Portal, which makes it a good fit. A Django project consists of one or more Django “apps”, which I will cover below. Each app consists of “models”, which use the Django ORM (Object-Relational Mapping) to handle all of the database interactions for us, so we can stick to just Python and not worry about SQL. Apps also have “views”, which are classes or functions that are called when a URL is requested. Finally, Django provides a default templating engine that views can use to produce HTML.
If you’re not familiar with Django already, you should take the online Tutorial. It only takes about an hour to go through it all, and by the end you’ll have learned all of the fundamental things about building a Django site.
When you first get the branch you’ll see one folder and a handful of files. The folder, developer_network, is the Django project root, inside there is all of the source code for the website. Most of your time is going to be spent in there.
Also in the branch root you’ll find some files that are used for managing the project itself. Most important of these is the README file, which gives step by step instructions for getting it running on your machine. You will want to follow these instructions before you start changing code. Among the instructions is using the requirements.txt file, also in the branch root, to setup a virtualenv environment. Virtualenv lets you create a Python runtime specifically for this project, without it conflicting with your system-wide Python installation.
The other files you can ignore for now, they’re used for packaging and deploying the site, you won’t need them during development.
As I mentioned above, this folder is the Django project root. It has sub-folders for each of the Django apps used by this project. I will go into more detail on each of these apps below.
This folder also contains three important files for Django: manage.py, urls.py and settings.py
settings.py contains all of the Django configuration for the project. There’s too much to go into detail on here, and you’ll rarely need to touch it anyway.
urls.py is the file that maps URLs to an application’s views, it’s basically a list of regular-expressions that try to match the requested URL, and a python function or class to call for that match. If you took the Django project tutorial I recommended above, you should have a pretty good understanding of what it does. If you ever add a new view, you’ll need to add a corresponding line to this file in order for Django to know about it. If you want to know what view handles a given URL, you can just look it up here.
If you followed the README in the branch root, the first thing it has you do is grab another bzr branch and put it in ./developer_network/ubuntu_website. This is a Django app that does nothing more than provide a base template for all of your project’s pages. It’s generic enough to be used by other Django-powered websites, so it’s kept in a separate branch that each one can pull from. It’s rare that you’ll need to make changes in here, but if you do just remember that you need to push you changes branch to the ubuntu-community-webthemes project on Launchpad.
This is a 3rd party Django app that provides the RESTful JSON API for the site. You should not make changes to this app, since that would put us out of sync with the upstream code, and would make it difficult to pull in updates from them in the future. All of the code specific to the Ubuntu API Website’s services are in the developer_network/service/ app.
This app isn’t being used yet, but it is intended for giving better search functionality to the site. There are some models here already, but nothing that is being used. So if searching is your thing, this is the app you’ll want to work in.
This is another app that isn’t being used yet, but is intended to allow users to link additional content to the API documentation. This is one of the major goals of the site, and a relatively easy area to get started contributing. There are already models defined for code snippets, Images and links. Snippets and Links should be relatively straightforward to implement. Images will be a little harder, because the site runs on multiple instances in the cloud, and each instance will need access to the image, so we can’t just use the Django default of saving them to local files. This is the best place for you to make an impact on the site.
The common app provides views for logging in and out of the app, as well as views for handling 404 and 500 errors when the arise. It also provides some base models the site’s page hierarchy. This starts with a Topic at the top, which would be qml or html5 in our site, followed by a Version which lets us host different sets of docs for the different supported releases of Ubuntu. Finally each set of docs is placed within a Section, such as Graphical Interface or Platform Service to help the user browse them based on use.
This app provides models that correspond directly to pieces of documentation that are being imported. Documentation can be imported either as an Element that represents a specific part of the API, such as a class or function, or as a Page that represents long-form text on how to use the Elements themselves. Each one of these may also have a given Namespace attached to it, if the imported language supports it, to further categorize them.
Finally we get into the app that is actually generates the pages. This app has no models, but uses the ones defined in the common and apidocs apps. This app defines all of the views and templates used by the website’s pages, so no matter what you are working on there’s a good chance you’ll need to make changes in here too. The templates defined here use the ones in ubuntu_website as a base, and then add site and page specific markup for each.
If you’re still reading this far down, congratulations! You have all the information you need to dive in and start turning a boring but functional website into a dynamic, collaborative information hub for Ubuntu app developers. But you don’t need to go it alone, I’m on IRC all the time, so come find me (mhall119) in #ubuntu-website or #ubuntu-app-devel on Freenode and let me know where you want to start. If you don’t do IRC, leave a comment below and I’ll respond to it. And of course you can find the project, file bugs (or pick bugs to fix) and get the code all from the Launchpad project.Read more
It may surprise some of you (not really) to learn that in addition to being a software geek, I’m also a sci-fi nerd. One of my current guilty pleasures is the British Sci-Fi hit Doctor Who. I’m not alone in this, I know many of you reading this are fans of the show too. Many of my friends from outside the floss-o-sphere are, and some of them record a weekly podcast on the subject.
Tonight one of them was over at my house for dinner, and I was reminded of Stuart Langridge’s post about making a Bad Voltage app and how he had a GenericPodcastApp component that provided common functionality with a clean separation from the rest of his app. So I decided to see how easy it would be to make a DWO Whocast app with it. Turns out, it was incredibly easy.
Here are the steps I took:
That’s it! All told it took my less than 10 minutes to put the app together, test it, show it off, and submit my Click package to the store. And the app doesn’t look half bad either. Think about that, 10 minutes to get from an idea to the store. It would have been available to download too if automatic reviews were working in the store (coming soon).
That’s the power of the Ubuntu SDK. What can you do with it in 10 minutes?
Update: Before this was even published this morning the app was reviewed, approved, and available in the store. You can download it now on your Ubuntu phone or tablet.Read more
Yesterday, in a conference call with the press followed immediately by a public Town Hall with the community, Canonical announced the first two hardware manufacturers who are going to ship Ubuntu on smartphones!
Now many have speculated on why we think we can succeed where so many giants have failed. It’s a question we see quite a bit, actually. If Microsoft, RIM/Blackberry and HP all failed, what makes us think we can succeed? It’s simple math, really. We’re small. Yeah, that’s it, we’re just small.
Unlike those giants who tried and failed, we don’t need to dominate the market to be successful. Even just 1% of the market would be enough to sustain and continue the development of Ubuntu for phones, and probably help cover the cost of developing it for desktops too. The server side is already paying for itself. Because we’re small and diversified, we don’t need to win big in order to win at all. And 1%, that’s a very reachable target.
I am sure that you have all seen the exciting news about the first partners to ship Ubuntu smart-phones. For those who haven’t seen it:
19th February 2014, London: Canonical today announces it has signed agreements with mobile device manufacturers bq (www.bqreaders.com) (Spain) and Meizu (China) to bring Ubuntu smartphones to consumers globally. Canonical is working with these partners to ship the first Ubuntu devices on the latest hardware in 2014. Ubuntu has also received significant support from the world’s biggest carriers, some of which intend to work with OEM partners to bring phones to market this year.
Development programmes have begun with the partners to provide smartphones with a superior user experience on mid to high end hardware for consumers around the world. Devices will be available to buy online through bq, Meizu and at Ubuntu.com.
Today was a hectic day, starting with our Ubuntu town hall hangout and spent in a wealth of meetings. As such I haven’t had a chance to write a blog post about this announcement yet, but I wanted to throw something out on my blog before I go to bed.
Naturally this is tremendously exciting news. As I posted about before, 2013 was an intense year as we not only started building our convergent platform, but also the many inter-connecting pieces too such as our SDK, image based updates, Mir, app developer platform, platform services, app insulation, developer portal, and more. As a result of this work, since May 2013 I have been running Ubuntu full-time on my phone and we are in great shape.
In the last year my team has been heavily focused on building a new community; our Ubuntu app developer community. I have directed many resources in my team here for a number of reasons that I believe are of strategic importance to the future health, growth, and opportunity of Ubuntu and our community.
Firstly, we want Ubuntu to instill a level of simplicity, elegance, and power that is not just present in the default platform, dash, scopes, and services, but also emphasized across the apps that users want to use. This means kickstarting a new generation of apps inspired by the design and development principles that are driving our convergence vision and using a simple and powerful app developer platform so devs can go from idea to app store as quickly and easily as possible.
Secondly, I personally believe that apps are key to our success. I suspect that OEMs and carriers will be even more motivated by a platform with great apps and a powerful developer platform, I believe that users will be attracted to a platform with great apps, and I believe that developers will want to build apps for a platform that is both fun to use and develop for.
Thirdly, I believe there is a huge opportunity to refine and innovate in so many areas of our app developer platform and community. Everything from the tooling to knowledge and support to publishing can be optimized and refined to build the very best developer platform.
As such, in my peanut-sized brain the apps are where much of my team’s strategy should be focused.
I am delighted by the progress we are making here. As I wrote about a few days ago, there is lots of wonderful work going on and fresh features and improvements landing soon. Our Ubuntu app developer platform is growing in leaps and bounds and I am really proud of the efforts of so many people.
Now, while I am proud of where we are today, I am not going to compromise until we have the best developer platform in the world.
So, how does this all relate to the bq and Meizu news?
Well, this news starts the ball rolling on the first set of devices that are going to be hitting the market. This in-turn will result in a general consumer audience starting to use Ubuntu on smart-phones. While today we have thousands of developers flashing their phones with Ubuntu and eagerly writing apps and using other people’s apps, the injection of general consumers will build even more motivation and momentum for our app developers to create apps they are truly proud of and that will be of interest to a new generaton of Ubuntu smart-phone users. As a musician I can tell you that having an audience makes everything that much more worthwhile, and I think it is the same our developers who are about to get a new audience growing around them.
These are tremendously exciting times. Our vision is ambitious but every day the momentum grows and I delighted you are all joining the journey with us. Let’s do this, friends!Read more
Today I reached another milestone in my open source journey: I got my first package uploaded into Debian’s archives. I’ve managed to get packages uploaded into Ubuntu before, and I’ve attempted to get one into Debian, but this is the first time I’ve actually gotten a contribution in that would benefit Debian users.
I couldn’t have done with without the the help and mentorship of Paul Tagliamonte, but I was also helped by a number of others in the Debian community, so a big thank you to everybody who answered my questions and walked me through getting setup with things like Alioth and re-learning how to use SVN.
One last bit of fun, I was invited to join the Linux Unplugged podcast today to talk about yesterday’s post, you can listen it it (and watch IRC comments scroll by) here: http://www.jupiterbroadcasting.com/51842/neckbeard-entitlement-factor-lup-28/Read more
With UDS just around the corner (11-13 March 2014, 2pm-8pm UTC) we wanted to give you a quick update where things stand in the 14.04 cycle. The teams have been busy working towards the goals for the 14.04 cycle, with a focus on the Ubuntu 14.04 LTS release, the App Developer Program and of course Ubuntu for Phones. […]Read more
Last week I was in Orlando sprinting with my team as well as the platform, SDK, and security teams and some desktop and design folks. As usual after a sprint, I have been slammed catching up with email, but I wanted to provide a summary of some work going that you can expect to see soon in the Ubuntu app developer platform.
In the last few months we have been working to refine our HTML5 support in the Ubuntu SDK.
Today we have full HTML5 support in the SDK but we are working to make HTML5 apps more integrated than ever. This work will land in the next week and will include the following improvements:
With these refinements you will be able use the Ubuntu SDK to create a new HTML5 app from a single template, follow a tutorial to make a truly native look and feel HTML5 app utilizing the Cordova and Platform APIs, then click one button to generate a click package and fill in a simple form and get your app in the store.
I want to offer many thanks to David Barth’s team for being so responsive when I asked them to refine our HTML5 support ready for MWC. They have worked tirelessly, and thanks also to Daniel Holbach for coordinating the many moving pieces here.
Our SDK is the jewel in the crown of our app development story. Our goal is that the SDK gets you on your Ubuntu app development adventure and provides all the tools you need to be creative and productive.
Fortunately there are a number of improvements coming here too. This includes:
As ever, you can download the latest Ubuntu SDK by following the instructions on developer.ubuntu.com. Thanks to Zoltan and his team for his efforts
An awesome SDK and a fantastic platform is only as good as the people who know how to use it. With this in mind we are continuing to expand and improve developer.ubuntu.com to be a world-class developer portal.
With this we have many pieces coming:
Thanks to David, Michael, and Kyle on my team for all of their wonderful efforts here.
In the Ubuntu 14.04 cycle we are also making some enhancements to how Ubuntu SDK apps can run on the desktop.
As many of you will know we are planning on shipping a preview session of Unity8 running on Mir. This means that you can open Unity8 from the normal Ubuntu login screen so you can play with it and test it. This will not look like the desktop; that work is on-going to converge Unity 8 into the desktop form-factor and will come later. It will however provide a base in which developers can try the new codebase and hack on it to converge it to the desktop more quickly. We are refreshing our Unity8 developer docs to make this on-ramp easier.
We are also going to make some changes to make running Ubuntu SDK apps on Unity 7 more comfortable. This will include things such as displaying scrollbars, right-click menus etc. More on this will be confirmed as we get closer to release.
All in all, lots of exciting work going on. We are at the beginning of a new revolution in Ubuntu where beautifully designed, integrated, and powerful apps can drive a new generation of Ubuntu, all build on the principles of Open Source, collaboration, and community.Read more
Today was a distracting day for me. My homeowner’s insurance is requiring that I get my house re-roofed, so I’ve had contractors coming and going all day to give me estimates. Beyond just the cost, we’ve been checking on state licensing, insurance, etc. I’ve been most shocked at the differences in the level of professionalism from them, you can really tell the ones for whom it is a business, and not just a job.
But I still managed to get some work done today. After a call with Francis Ginther about the API website importers, we should soon be getting regular updates to the current API docs as soon as their source branch is updated. I will of course make a big announcement when that happens
I didn’t have much time to work on my Debian contributions today, though I did join the DPMT (Debian Python Modules Team) so that I could upload my new python-model-mommy package with the DPMT as the Maintainer, rather than trying to maintain this package on my own. Big thanks to Paul Tagliamonte for walking me through all of these steps while I learn.
I’m now into my second week of UbBloPoMo posts, with 8 posts so far. This is the point where the obligation of posting every day starts to overtake the excitement of it, but I’m going to persevere and try to make it to the end of the month. I would love to hear what you readers, especially those coming from Planet Ubuntu, think of this effort.
 Re-roofing, for those who don’t know, involves removing and replacing the shingles and water-proofing paper, but leaving the plywood itself. In my case, they’re also going to have to re-nail all of the plywood to the rafters and some other things to bring it up to date with new building codes. Can’t be too safe in hurricane-prone Florida.
Quick overview post today, because it’s late and I don’t have anything particular to talk about today.
First of all, the next vUDS was announced today, we’re a bit late in starting it off but we wanted to have another one early enough to still be useful to the Trusty release cycle. Read the linked mailinglist post for details about where to find the schedule and how to propose sessions.
I pushed another update to the API website today that does a better job balancing the 2-column view of namespaces and fixes the sub-nav text to match the WordPress side of things. This was the first deployment in a while to go off without a problem, thanks to having a new staging environment created last time. I’m hoping my deployment problems on this are now far behind me.
I took a task during my weekly Core Apps update call to look more into the Terminal app’s problem with enter and backspace keys, so I may be pinging some of you in the coming week about it to get some help. You have been warned.
Finally, I decided a few weeks ago to spread out my after-hours community a activity beyond Ubuntu, and I’ve settled on the Debian new maintainers Django website as somewhere I can easily start. I’ve got a git repo where I’m starting writing the first unit tests for that website, and as part of that I’m also working on Debian packaging for the Python model-mommy library which we use extensively in Ubuntu’s Django website. I’m having to learn (or learn more) Debian packaging, Git workflows and Debian’s processes and community, all of which are going to be good for me, and I’m looking forward to the challenge.Read more
In both git and bzr, each branch you clone is a full copy of project’s history. Once you have downloaded the source control objects from the remote location (e.g. github or launchpad), you can then use your local copy of the repo to quickly create more local branches.
What if another user has code in their branch that you want to inspect or use?
In git, since it’s common to have many logical git branches in the same physical filesystem directory, the operation is conceptually a simple extension of the default workflow, where you use “git checkout” to switch between logical branches.
The conceptually simple extension of the workflow is to add the location of the remote repo to your local repo and download any potentially new objects you don’t already have.
Now you have access to the new branches, and can switch between them with “git checkout”.
In command sequences:
git remote add alice https://github.com/alice/project.git git remote update git checkout alice/new_branch
This workflow is great if project.git is very large, and you have a slow network. The remote update will only download Alice’s objects that you don’t already have, which should be minimal, comparatively speaking.
In bzr, the default workflow is to have a separate physical filesystem directory for each logical branch. It is possible to make different branches share the same physical directory with the ‘colo’ plugin, but my impression is most people don’t use it and opt for the default.
Since different bzr branches will have different directories by default, getting them to share source control objects can be trickier especially when a remote repo is involved.
Again, the use case here is to avoid having to re-download a gigantic remote branch especially when perhaps 98% of the objects are the same.
I read and re-read the `bzr branch` man page multiple times, wondering if some combination of –stacked, –use-existing-dir, –hardlink, or –bind could do this, but I ended up baffled. After some good clues from the friendly folks in the #bzr irc channel, I found this answer:
I used a variation of the second (non-accepted) answer:
bzr init-repo ../ bzr reconfigure --use-shared
I was then able to:
cd .. bzr branch lp:~alice/project/new_branch cd new_branch
The operation was very fast, as bzr downloaded only the new objects from Alice that I was missing, and that was exactly what I wanted. \o/
We wrapped up the last day of our sprint with a new team photo. I can honestly say I couldn’t think of a better group of people to be working with. Even the funny looking guy in the middle.
I mentioned that earlier in the week we decided on naming SDK releases after distro releases, and with that information in hand I spent my last day getting the latest API docs uploaded, so if you’re writing apps for the latest device images, you’ll want to use these: http://developer.ubuntu.com/api/qml/sdk-14.04/
In the coming week I’ll be working to get the documentation publishing scripts added to the automated build and testing process, so those docs will be continuously updated until the release of Ubuntu 14.04, at which point we’ll freeze those doc pages and start publishing daily updates for 14.10. Being able to publish all of those docs in a matter of minutes was a particularly thrill for me, after working for so long to get that feature into production. It certainly proves that it was the right approach.Read more
We are growing a world-class community and app developer eco-system, fuelled by Open Source and open collaboration. We are putting the core pieces in place and I am delighted to be working with such a wonderful team:
(L-R) Daniel Holbach, Kyle Nitzsche, Michael Hall, This Guy, Nicholas Skaggs, Alan Pope, David PlanellaRead more
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.