[A Juju adventure] Linking up with Android

In my previous entry, I argued that Ubuntu is possibly the best development environment to write connected android apps, thanks to Juju. Although using WordPress was possibly not a great example 🙂 I still think that this idea has legs! Hence, I have decided to build an example project.

The example will mainly be a simple and plan ToDo list app for Android, that gets its items from a back-end MySQL server.

So here is my list of things to get done for this example project:

Proof that you can access a Juju local environment from the Android Emulator
Develop a TODO list android app
Using a few charms from the charm store plus a custom one, set up a MySQL database that can be exposed through a web service with simple commands/steps
Connect the android app and the webservice, so they talk to each other.

And as there is no time like the present, here is the first bullet point!

Accessing a Juju Local Environment from the Android Emulator

As I was working on my wordpress charm, the easiest thing for me to do was to access the local webserver set-up for the blog. I first installed the Android SDK, which turned out to be pretty easy to do by just following the instructions posted at http://developer.android.com/sdk/index.html . Apart of the sdk tools that download you the emulator, build tools and so on.. you can also choose to use Eclipse as your IDE. If you do this, you can then install an Android plug-in that is *very very* complete. Having had previous experience with Eclipse, I choose this root and unless you feel very strongly against it, I recommend that you do the same.

Once I had the SDK installed, I run the 2.2 emulator (because that happens to be the version in the spare Android phone that I plan to use later on) and open the local IP address of the WordPress service. That just worked fine.

Then I decided to create a sample android project and tried some code to do the same. I found that the following method within the main activity of the project was able to ping and then open in a browser window the wordpress app:

private String hostip = "192.168.122.137";

...

public void pingme(View view) {
 TextView info = (TextView) findViewById(R.id.mytext);
 WebView mweb = (WebView) findViewById(R.id.webView1);
 InetAddress in = null;

 Log.w("PING","trying to reach" + hostip);
 info.setText("trying to reach" + hostip);
 in = InetAddress.getByName(hostip);

 if (in.isReachable(5000)) {
   info.append("\nHost found");
   Log.w("FOUND",in.getCanonicalHostName());
 } else {
   info.append("\nHost found");
 }
 mweb.getSettings().setJavaScriptEnabled(true);
 mweb.loadUrl("http://"+hostip);
}

So in a nutshell, the first bullet point (and the easiest) of my list is completed!

[A JuJu Adventure] Splitting my charm out

In my previous post, Jorge Castro commented that a new super wordpress charm is in the works, and I want to keep working on my blog site configuration (theme and plug-ins) without missing out on any updates. This means that I needed to stop forking the wordpress plugin and find a way to just use the one in the charm store and then ,onto the same instance, roll-out my configuration.

I mentioned that I might try splitting my configuration out into a Subordinate service, and that is what I done 🙂 It was actually pretty easy.

I created a new charm called wordpress-conf. I set the metadata.yaml file to contain:

name: wordpress-conf
summary: "WordPress configuration"
subordinate: true
description: |
Provides configuration for wordpress blogs
- Plugin:
- WordPress importers
- super cache plug-in
requires:
logging:
 interface: logging-directory
 scope: container
juju-info:
 interface: juju-info
 scope: container

As you can see it has a line calling out that this charm is a subordinate, and has two requirement. The two requirements are for testing purposes really. The “logging” requirement is an explicit requirement that the charm that you are “subordinating” to must have defined, while “juju-info” is an implicit requirement that is define for all charms. What this mean is that using “juju-info”, I can deploy my charm against any service. The key is to define the scope as container.

The magic happens not when you deploy a subordinate charm, but when you add a relationship to another service. For example the following commands result on a wordpress instance setup following the WP charm in the charm store, but with my plugin and theme set up:

juju bootstrap
juju deploy wordpress
juju deploy mysql
juju add-relation wordpress mysql
juju expose wordpress
juju deploy --repository=~/mycharm local:precise/wordpress-conf
juju add-relation wordpress-conf wordpress

Pretty cool, eh!? I should be able to upgrade the two charms now independently

Ubuntu ARM Server AMI on Amazon EC2

Reposting here the blog entry that I uploaded to blog.canonical.com

Have you been wondering if your Web application will work with the new generation of Hyperdense ARM Servers? Now you can easily find out by using Ubuntu and Amazon Web Services. Canonical has made available in Amazon Web Services an AMI image for developers wishing to experiment with Ubuntu ARM Server. Dann Frazier is the engineer behind this initiative. I took some of his time today to asking a few questions:

How did this came about?
We were wanting to do some internal functional testing of the 12.04 release across our global team without shipping hardware around. We had a QEMU model with us and using cloud systems to host it seemed like an excellent way to grow our (emulated) machine count.

Can you give me some examples of what could I do with it?
Basically, anything you can do with Ubuntu Server. You can install packages, deploy Juju charms, test your web applications, etc. However, I would strongly suggest not using it for any production work or performance testing – being an emulated environment, you will notice some overhead.

Who do you expect will use this new AMI?
Developers looking to test their applications on ARM, people wanting to test Juju charm deployments in a multi-architecture environment, and anyone just looking to kick the tires.

This is all great, How do I get my hands on it?
Canonical has published an AMI on Amazon EC2. You will need an Amazon Web Services account, then just go into your Management Console for EC2 and launch a new instance. Select “Community AMIs” and look for AMI ID ‘ami-aef328c7’. (We’ll keep the latest AMI ID posted at http://wiki.ubuntu.com/ARM/Server). Or click here.

Are there any limations compared to a real hardware box?
The AMI provides an Ubuntu 12.04 (‘armhf’) system running on an emulated hardware system. Performance is limited due to the emulation overhead. This AMI requires the use of an m1.large instance type due to memory requirements.

Once again, thanks to Dann and the Canonical team for sharing this neat tool with the community. It sounds great and easy to set up. So, What are you waiting for?

[A JuJu Adventure] Baby Steps into WordPress Charm

For a while now, I have being toying with the idea to move away from a WordPress.com hosted site for this blog. The main reason: I am not really happy to have to pay for every single simple stuff.. add an additional URL to the site, take aways advertising, edit a CSS… it really stops me from playing 🙂

What had prevented me from doing this in the past was that I haven’t really got much experience setting up WordPress or MySQL. What I really needed was a save (and free) sandbox to try changes to my site, until I was happy with it, and then easily deploy it live… Can you say Juju?

With Juju you can do all your playing locally using LXC, save all the changes into a Charm and then just deploy them into a public cloud. Perfect!

The first thing I did was to set-up an Amazon AWS account and configure my juju environment to deploy to the public cloud. My rationale here was: if I can’t get vanilla WordPress in a live public site, then there is little point continuing with the experiment.

This was actually pretty easy, I just followed the Getting Started guide. The only stumbling block was that I was using my travel laptop at the time that didn’t have my launchpad ssh keys. You need to create ssh keys to use Juju, but apparently you also need to publish them into your launchpad account. Once this was done, I had a public WordPress instance in just 5 commands.

Next step: destroy the environment and stop paying 🙂 Now I needed to bring up my cheap sandbox.

Again this is pretty easy to setup, just follow the Getting Started guide. I hit another road block once my deployment instances seemed not be doing much, “juju status -e local” showed them in pending state and the logs did not display any activity…A bit of Googling later , I found that Jorge Castro had hit the same problem and found the solution in Ask Ubuntu.

With my WordPress local instance now fully up and running, now I needed to upload my own content. To do this, I just needed to upload the wordpress importer plugin. Fairly trivial to get gone by hand, thanks to the very useful “juju scp” and “juju ssh” commands, but how to do it via a Charm. I wanted to make sure that the next time a deploy wordpress, it would have already this plugin install. Crudly this is what I did:

Using the charm-tools I got the wordpress charm loc ally (charm get wordpress)
I then edited the install file under hooks/ to include:
apt-get -y install wordpress pwgen wget unzip
wget http://downloads.wordpress.org/plugin/wordpress-importer.0.6.zip
sudo unzip wordpress-importer.0.6 -d /usr/share/wordpress/wp-content/plugins/
redeploy using locally stored charm. juju deploy –repository=~/charms local:precise/wordpress -e local

Guess what, it worked. I did get some warnings (WARNING Charm ‘.mrconfig’ has an error) that I am yet to iron out, but when the wordpress instance came up the new plugin was there:

That is all for today, and before I go, one last useful hint courtesy of James Page: Add “default: {name of your env}” if you have multiple environments but you normally always use one. Save me having to type “-e local” all the time.

Chrome OS Gets A New “Retro” Look

I had a CR-48 Chromebook for a while, which has recently fallen in disuse. While I have never being totally convinced about Chrome OS being a polished, well designed, interface that simplifies the “always connected” user journey that Google was envisioning, I liked the concept.

Now I am reading in ArsTechnica that Chrome OS is getting a brand new look, that is … basically.. well, not new. While I am sure there are many technical advantages of a fully hardware accelerated windows managers, my issue is with the [lack of] concept.

Continue reading “Chrome OS Gets A New “Retro” Look” →

Going Agile: Scrum or Kanban?

I have been using Scrum for a while. Back at my previous role, we tried using Scrum within the integration team that was creating the nightly builds and our bi-weekly releases. It brought good results, the team specially liked the visibility of the task board and the daily stand-ups.

We did found a bit artificial to have a cadence. We were suppose to put out a release every two weeks but we end up doing it as often as we could (or made sense), as we were not in control of when the new software was landing in our plate.

Since then, I’ve this nagging thought that Scrum might not be appropriated to service teams or teams with a large portion of maintenance/customer support work. I have found iterations shorter than 2 weeks, can be over burden by the demo, planning and sizing overheads. In the other hand, two weeks is too much time for teams with Service Level Agreements of days or hours. It also seems a bit cumbersome for short project (~1 month), were you end up with 2 or 1 iterations… What to do!?

In Canonical several teams have used Kanban in order to improve their development processes, so I started reading up on it when I stumbled on this excellent article on Kanban vs Scrum.

The author won me over straight away by not trying to decide which of the two practices is best but instead doing a great job at remaining impartial.

Looking back at the Symbian Foundation’s integration team it seems that Kanban would have been better suited. It retains the focus on making information visible while concentrating on reducing WIP. It seems better suited to a “specialist” team, where most members share the same skills and work on similar tasks. Scrum seems to work better for cross-discipline project teams.

Also, the emphasis on managing constant flow of work is one that resonates with teams that have a work “currency” measured in days of effort (bugs?) rather in large projects lasting months at the time.

While Scrum has been very successfully adopted by the Certification team at Canonical, My previous experience with the Integration team had stopped me from cheering on Scrum in teams that have a constant flow of work. Now, we are thinking on going Kanban! Don’t get me wrong, we are going to continue using Scrum. It is just a case of using the right tool for each job. I will keep you posted on how it goes.

If you have any advice, tips or gotchas that you could share with us, I would be most grateful if you could drop your comments here!

by the only anla — Time to try something new (by theonlyanla)

Ubuntu Certification – Website Improvements

The Ubuntu Certification Website has just got better. We have roll-out improvements to how we list systems and provided a powerful search feature. We want to ensure that you get as quick as possible to the information that you need.

As part of the Certification website, we provide a feedback mechanism through Launchpad Answers. Over the last year, we have seen a trend of questions around:

Most models are sold with different graphics cards , processors… so which one is the one listed as certified?
Does the system listed as certified works with a version of Ubuntu that I can download from Ubuntu.com? Or only with the one that the manufacturer sales?
What release is this model certified for?

To address these questions, we have introduced some changes to the website. We now display what components are included on the certified system in the search results. We’ve also added a icon to indicate if the system is only certified with a vendor image or with the standard Ubuntu image.

The new and simpler search interface eliminates confusion on what data is presented. A small filter box has been added to the website allowing users to select the device type, Ubuntu release and image type that they are interested in.

If you have any comments on the new website design, I would really like to hear from you!