From An Egg

Over the holidays I've been working on a small project playing with some of the new Javascript libraries that came out over the past year. After a while I noticed that the size of the Javascript I was sending to the client was growing and starting to approach 100 KB for a basic isomorphic website. I figured now was a good time to look into minification and compression.

The site starts out by loading in the following raw code:

Riot.js 64KB Page.js 14KB client code  14KB Total 92KB

After Browserify was done rolling all of the code up into a single file it was ~92KB which was getting a little large for a website which basically did nothing. First step was to add minification to the Makefile using UglifyJs2.

$(CLIENT_MIN_ROLLUP): $(CLIENT_ROLLUP) $(UGLIFYJS) --screw-ie8 $^ -o $@

This step brought it down from 92KB to 44KB shaving off over 50% of the original size. This is still quite a lot of code for such a simple site so the next step is to add gzip compression for everything being sent. I am using expressjs 4.0 as the webserver so to add gzip it's as easy as:

import compression from 'compression'; app.use(compression());

When writing code which needs to be built before it can be used, whether that's a transpile step like ES7 JavaScript to ES5, or a compile step like with Go, you're likely going to want to do this when a file in your application tree is modified. There are a large number of project and language specific tools which were developed to tackle this problem but did you know that there are system level packages available that you can use across all your projects?

Introducing inotifywait, which is an efficient and easy to use cli tool which uses Linux's inotify interface to watch for changes to the file system. And fswatch for those on OSX. Most of the language and project specific tools are built using wrappers around these two tools.

If you're like me and don't like to add more build tools and layers of abstraction than necessary then you're probably already using Make to build and develop your application, and you'll be happy to know that using these tools with it is trivial. Make has no way to know when a file has changed until the next time you run make so because of this many have tried something like the following which will run the build target every 2s.

watch -n 2 make build

Or they will build the loop into the makefile.

.PHONY watch watch: while true; do \ make build --silent; \ sleep 1; \ done

This works, but it's performing a lot of unneccesary work being run in a loop especially since the file system is able to tell us when a file or directory has been modified using inotify. Instead of automatically looping we wait for a file system event that we're interested in and then run our build target. In the following code we're able to create a make target in our makefile which will watch for file changes under our specified directory recursively.

.PHONY watch watch: while true; do \ inotifywait -qr -e modify -e create -e delete -e move app/src; \ make build; \ done

This works by creating an infinite loop which is started when you run the watch target. Before the first loop can finish it hits inotifywait which sets up listeners on all of the files and directories in your app/src directory. These listeners are waiting for any files to be modified, created, deleted, or moved in or out of app/src/.... When a file or directory changes inotifywait lets the loop continue triggering the call to your build target. That target executes in its entirety building only the file(s) which changed (assuming you've properly set up your makefile) and then the loop starts again with inotifywait waiting for those files to change again.

Over my career I've written in a number of different programming languages, most of them dynamic. It's been about 10 years since I last wrote a project from start to finish in a typed language, C++, but recently I've been working with Go. It's safe to say I had become blissfully ignorant of the benefits and challenges of a typed language and in working with Go I found myself really enjoying the explicit declaration of types with regards to stability and code legibility.

In many JavaScript projects you’ll see something like this:

function dataFiller() { var myObject = {}; // 5 lines later myObject.Foo = 'bar'; // 10 lines later myObject.Baz = 'bax'; // 5 lines later return myObject; }

This essentially means that you must read through an entire functions execution, and sometimes an entire modules execution to see what the structure of that object will become.

Now lets compare that to Go:

type myObject struct{ Foo string Baz string } func dataFiller() *myObject { var data = &myObject{} // 5 lines later data.Foo = "bar" // 10 lines later data.Baz = "bax" // 5 lines later return data }

Here you don’t even have to read further than the function declaration to know what the function will return and then you simply have to reference that type in the file to know ahead of time what it’s structure will be.

Throughout my time as a developer I’ve noticed that it’s quite rare that you cannot predict with 100% certainty what the data structure of your variables will be but, in dynamic languages, we don’t ever seem to outline that structure for people reading and writing the code. So this got me thinking about how this workflow can be adopted in JavaScript to give us the benefits of types using the native language constructs without having to use a compile target like Typescript. In practice it turns out to be quite simple:

// Method to convert defined object literal 'type' // into a 'locked down' data store. function createObject(obj) { var stub = Object.create(null); var keys = Object.keys(obj).forEach(function(key) { Object.defineProperty(stub, key, { configurable: true, enumerable: true, writable: true, value: obj[key] }); }); Object.seal(stub); return stub; } // Your 'type' which will be used to create // usable data store instances. var myObject = { Foo: '', Baz: '' }; // Fills the object with data. // @method dataFiller // @return {myObject} function dataFiller() { var data = createObject(myObject); // Set values like normal. data.Foo = 'bar'; data.Baz = 'bax'; return data; } var fullData = dataFiller(); fullData.Foo = "can Update"; // Updated fullData.Qux = "Can't add new properties"; // Not added

Juju works great for software development involving simple environments and is amazing for complex environments. A recent question on Ask Ubuntu “Is Juju a suitable tool for development as well as deployment?” made me realize that we use Juju for development every day but there really isn’t much documentation on the subject.

For the rest of this post I’m going to assume that you are already familiar with the concept of Juju and what problems it solves on the deployment side of things. If you aren’t, I recommend reading an earlier post of mine “Juju - Explain it to me like I’m 5”.

One of the biggest problems when developing any kind of software is getting the dependencies up and running in a way which matches the production environment close enough to be sure that you aren’t going to run into “this environment only” bugs. Sure you can install mysql onto your local machine and run the database dump on that install, but you also have to make sure that you apply all of the same configuration, indexes, build flags, etc. as the production environment.

Even once you get it up and running you then need the ability to update it after modifications were made by someone else on the project all with high production parity, and without extraneous downtime.

To illustrate the benefits of using Juju for development I’m going to use a fictitious photo and video sharing website. A website like this would require multiple services, load balancer, web server, database, blob store, user authentication, photo processor, video processor.

Keeping in mind that a Juju Charm can be written using any programming language or DSL that can be executed on the host machine. This means it can use Puppet, Chef, Python, JavaScript, Docker, and pretty much anything else you would like to use. Juju provides distinct advantages for project development depending on the lifecycle of the project. For our photo video site let's first assume that we’re just starting the project and then later on we’ll assume that the project is mature, released, and still under active development.

Just starting out

Typically when a project starts you’re only going to need a couple services, the database and your webserver. Let’s start our environment and install the database and webserver on our local machine.

juju bootstrap local juju deploy apache2 juju deploy mongodb

Great, It’s 5 minutes in and we now have apache2 and mongodb running on our machine in separate LXC’s, we can now start developing our website and pointing it to these services.

Parallel to this, your teammate is working on the user authentication service, it’s going well and they want someone to help them test it in the application environment. So lets get that service that they have been working on.

mkdir -p ~/charms/trusty && cd ~/charms/trusty git clone --depth 1 [email protected]:photovideo/authenticator juju deploy --repository=. local:trusty/authenticator

*For more information on deploying local charms see This Post on Ask Ubuntu.*

A few minutes later and you have an identical copy to their user authenticator service, you can point your website to it and give it a try. A little later the authenticator service has been updated and you’d like to run it again.

cd ~/charms/trusty/authenticator git pull juju upgrade-charm --repository=.

This process repeats itself throughout each service and across each member of your team. Allowing each one to update their dependencies within minutes to identical representations of how it’ll be run in production.

Released project

Now that your project has been released, deployed using Juju, running in production, you’ve had a chance to take advantage of Juju’s deployment and scaling features but how does Juju help you develop now?

In some ways it’s even easier to deploy. In this case, I’m going to assume that your services are private and not stored in the Juju Charm Store. If they were in there you wouldn’t have to first clone the repositories.

mkdir -p ~/charms/trusty && cd ~/charms/trusty git clone --depth 1 [email protected]:photovideo/mongodb git clone --depth 1 [email protected]:photovideo/authenticator … juju-quickstart -e local photovideo.yaml

Taking advantage of Juju Quickstart and the Juju bundles functionality you can deploy your entire environment with identical services, configuration, and machine placements. This will open up the GUI which will allow you to modify the machine placement of any of those services and change configuration values before deploying to your machine. Once you hit commit, sit back and wait for it to deploy an identical environment to your production environment on your local machine.

Now you can work on the specific service you’re interested in within an identical environment to everyone on your team. And when a service gets updated by another member on your team it’s trivial to update.

cd ~/charms/trusty/authenticator git pull juju upgrade-charm --repository=.

I hope this gets you excited to use Juju for development as well as deployment. My team uses Juju for development this way and has for over a year. It allows us to be more productive because we don’t have to waste time installing and updating services the hard way.

When using 'use strict;' in your scripts you'll find that you are no longer allowed to overwrite native methods like FileReader() so how do you test that these methods are being called with the appropriate parameters? Lets start with a typical function call involving FileReader() and then modify it to make it easier to test.

function importFile(file) { var reader = new FileReader(); reader.onload = function(e) { processData(e.target.result); }; reader.readAsText(file); }

Pre 'use strict'; days you could simply stub out the global FileReader() but since that's no longer an option we need to get a little creative with our code structure. First thing we're going to do is create a FileReader instance generator function.

function importFile(file) { var reader = generateFileReader(); reader.onload = function(e) { processData(e.target.result); }; reader.readAsText(file); } function generateFileReader() { return new FileReader(); }

Then we'll move the onload callback to a named function.

function importFile(file) { var reader = generateFileReader(); reader.onload = _readerOnloadHandler; reader.readAsText(file); } function generateFileReader() { return new FileReader(); } function _readerOnloadHandler(e) { processData(e.target.result); }

Now you can test the importFile function and its parts by stubbing out the generateFileReader function to return a basic reader stub and not have to worry about the native method. In the following example I'm using two simple stubbing methods to generate stub functions and methods.

it('parses files', function() { // Set up the stubs. var processStub = stubMethod('processData'); // The second parameter of the stubMethod is what generateFileReader // will return when it's called. var reader = stubMethod('generateFileReader', { onload: null, readAsText: stubFunction(); }); // Call the public method. importFile('/path/to/file'); // Make assertions assert.equal(reader.calledOnce(), true); assert.equal(reader.readAsText.calledOnce(), true); assert.equal(reader.readAsText.lastArguments()[0], '/path/to/file'); // Call the callback. reader.onload({ target: { result: 'file data' }}); // Make assertions assert.equal(processStub.calledOnce(), true); assert.equal(processStub.lastArguments()[0], 'file data'); });

It's common when moving from one version of your application to another that you will want to maintain all of the SEO cred you have built up while simultaneously moving to a new url syntax. To do this people usually reach for mod_rewrite with apache or nginx for which there is quite a bit of documentation on this topic. Unfortunately the same can't be said for rewriting and 301 redirecting when using HAProxy.

I have a rather common use case. I plan on moving this blog from Tumblr to Ghost using the Ghost Juju charm and the HAProxy charm to handle load balancing, reverse proxy and rewriting and redirecting the old Tumblr style urls to the Ghost url format.

Using mod_rewrite you would likely write something similar to the following to handle rewriting the url to the new syntax and redirecting with a 301 response code:

RewriteEngine On RewriteRule ^/post/\d+/(.+)/? http://example.com/$1 [R=301,L]

HAProxy however doesn't have a single rule for rewrite and redirect instead we have to combine reqrep, to rewrite the url, and redirect, to handle the actual redirection.

Assume the following front and backend configurations:

frontend haproxy-0-80 bind 0.0.0.0:80 default_backend haproxy_service backend haproxy_service balance leastconn cookie SRVNAME insert server ghost-0-2368 10.0.3.220:2368 maxconn 100 cookie S0 check

In order to rewrite the url we first need to add the rewrite into the frontend:

frontend haproxy-0-80 bind 0.0.0.0:80 default_backend haproxy_service reqrep ^([^\ :]*)\ /post/\d+/(.+)/? \1\ /\2

This will rewrite the old Tumblr style url format to the new Ghost style url format and pass that url off to the Ghost webserver. If you're ok with the user still seeing and using the old url style then you can stop here. Both the real Ghost url format and the old Tumblr style url format will work. If however you want to tell the users and any search engines that the old url is no longer valid and to use a new one instead we need to add the redirect rule:

frontend haproxy-0-80 bind 0.0.0.0:80 default_backend haproxy_service reqrep ^([^\ :]*)\ /post/\d+/(.+)/? \1\ /\2 redirect prefix / code 301

The HAProxy redirect syntax requires us to specify what kind of redirect we want to occur. The options are 'location', 'prefix', and 'scheme' none of these truly fit redirecting an old to new url. Fortunately we can trick HAProxy into doing just what we want by telling it we want to redirect to change the prefix of the url and passing / as the url to prefix along with the code we want to send, 301.

We aren't quite done. If we leave this as is it will redirect every rule, including the Ghost url formatted ones which will put it into a redirect loop. In order to fix this we need to create an access control list to only redirect the old urls:

frontend haproxy-0-80 bind 0.0.0.0:80 default_backend haproxy_service acl old_url path_beg /post reqrep ^([^\ :]*)\ /post/\d+/(.+)/? \1\ /\2 redirect prefix / code 301 if old_url

To the frontend we added a new acl rule called "old_url" which returns true if the path begins with /post. We then add the conditional 'if old_url" to the redirect rule and we're done. After restarting the HAProxy service you'll be able to use the old url structure and be 301 redirected to the new Ghost syntax urls which also remain functional.

Juju is brilliant. Ok I am a little biased being that I work at Canonical on the Juju project, but every week I'm more and more impressed with how awesome Juju is and how easy it makes developing software and working in the cloud. I tweet and post a bunch about Juju but today I was asked to explain what Juju is to someone like they are 5.

@FromAnEgg ELI5 Juju..

— Mark Poppen (@MarkPoppen) September 8, 2014

Juju is often described as apt-get for the cloud, but what does someone who isn't familiar with the Ubuntu ecosystem know about apt-get? I think I'll need to go even more abstract...

Let's say that you had built the most awesome Lego race car body (kids still play with Lego right?) but you didn't know how to make the wheels or make it move with one of those Mindstorm engines. So now you have to go and play around for a long time to learn how to make a wheel and how to hook up engines. But this is going to take a long time and your mom is going to call you for supper soon, there has to be someone who is an expert wheel maker and Mindstorm engine builder right? Wouldn't it be awesome if they could build wheels and engines you could use in your race car so you can finish it before supper?

Well that is what Juju does. It allows people who have expertise in a specific field to build packages that you can connect to your own projects without needing to be an expert in that field. So how does this help you write software faster in the cloud? Well I think that's best explained with another, more grown up, example.

Recently, I wrote a Juju Charm for the Ghost blogging platform so that I can move this blog off of Tumblr and onto something a little more customize-able. The problem? I needed a front end server which was capable of load balancing the webservers when the load picks up and I don't have the time to learn all about the various options and the best way to install and configure them. So I went to what's known as the Juju Charm Browser and picked the haproxy Charm and added it into my environment. With multiple web servers I could no longer rely on Ghost's built in SQLite implementation so I needed to hook up to an external MySQL database. Back to the Charm Browser I went and grabbed the MySQL Charm.

So now I have a load-balanced horizontally scale-able Ghost blog (coming soon). You can have one too, it's incredibly easy too. For you to get your very own horizontally scale-able load-balanced Ghost blog all you have to do is execute these commands:

juju deploy ghost juju deploy haproxy juju deploy mysql juju add-relation ghost haproxy juju add-relation ghost mysql

Lets pretend for a moment that haproxy isn't cutting it any longer and you instead want to use apache2:

juju destroy-service haproxy juju deploy apache2 juju add-relation ghost apache2

Maybe your blog is super popular and you need another 5 webservers:

juju add-unit ghost -n 5

That's it. You have now taken advantage of many peoples domain expertise to develop a cloud environment for your own blog.

So what if you wanted to use MySQL or any of these other Charms for a different application? That's the best part these charms are written using the best practices for the particular charm but have easy to interface with hooks. To enable the Ghost charm to communicate with the haproxy charm all I had to write was:

#!/usr/bin/node var exec = require('child_process').exec; var port, address; function storePort(err, returnedPort) { port = returnedPort; exec('unit-get --format=json private-address', storeAddress); } function storeAddress(err, returnedAddress) { address = returnedAddress exec('relation-set port=' + port + ' hostname=' + address); } exec('config-get --format=json port', storePort);

Juju charms can be written in anything that can be executed. The Ghost charm was written in JavaScript, the MySQL one in bash. Others use Python, Puppet, Chef, Ansible, even Docker containers can be orchestrated using a Juju Charm.

Want to run your own wiki:

juju deploy mediawiki juju deploy mysql juju deploy haproxy juju add-relation mediawiki mysql juju add-relation mediawiki haproxy

How about a MongoDB cluster, Hadoop cluster, Django app, a video transcoding cluster, and more including your own applications. All easily deployable and scalable across public clouds like EC2, HP Cloud, Joyent, Your private OpenStack cloud, and even your very own local machine. That's right, the above commands all work to deploy identical set ups to all of these targets and more.

Last week we released a new version of the Juju GUI which brings with it one major UI change plus a huge refactoring of the application state system.

We moved the inspectors default rendering position to the left over top of the charm browser to give you more room to work with your active environment.

A new uni-directional data flow system was implemented which dramatically simplified the GUI's data flow and execution.

Charm searching has been improved in the charm browser and will continue to be improved over time.

Work for the new machine view continues under the 'mv' flag. To check out this work load up the GUI with '<hostname>:flags:/mv'.

Plus many many fixes. See the repository for more information.

Since Facebook released Flux there has been a lot of chatter about the unidirectional data flow architecture and how it helps large scale applications be easier to reason about and develop. With the Juju GUI nearing 70,000 lines of code in the core application we were running into an issue where it was becoming difficult to maintain the correct state throughout the many rendered UI components which are being consistently changed from the user interactions and changes coming in over the websocket from the users Juju environment.

In an effort to remedy this we determined that the only way to solve our current issues and prevent new ones going forward is to develop a unidirectional data flow architecture vs our MVC event style system which was currently in place. The execution flow we decided on was as follows:

When a user visits a url or a delta comes in over the websocket it is parsed and split into disparate sections of state for each component that's involved.

That state is then saved into the state system.

When the state system changes it diffs from it's previous state and passes the diff off to the dispatcher.

The dispatcher scans through the diff and passes off the various state components to their registered handlers.

Those handlers then pass the updated data into the UI components.

The UI components are then responsible for updating their DOM representation.

If the user makes a change to the UI, that UI component requests a change from the state system and the cycle repeats.

You'll notice that this is strikingly similar to the Flux architecture:

It's great to see cases of the multiple discovery hypothesis in action. It's a sign that you're on the right track for solving the bigger picture problems. It's also nice to see someone formalizing this architecture for client side applications in the hopes that others will be able to skip these scalability problems. While our implementation differs from Flux, the architecture is nearly identical. I highly recommend this architecture to anyone writing a large complex application of any kind, client or server side, as it dramatically reduces the complexity of the applications execution.

Anyone who is familiar with package versioning has used, or at the very least heard of, Semantic Versioning. For the uninitiated, semver is a three part version number in the format MAJOR.MINOR.PATCH ex) 1.13.2, and you can find very in-depth details on the semver website.

The semver website outlines the rules for incrementing version numbers as:

MAJOR: When you make incompatible API changes.

MINOR: When you add functionality in a backwards-compatible manner.

PATCH: When you make backwards compatible bug fixes.

At gophercon I had a discussion with another engineer about what these mean. When does a change make the API incompatible with a previous release? Take the following contrived example:

Your API typically returns a key/value pair for a requested field:

{ foo: ‘bar’ }

But now you decide to change the value returned by capitalizing the first character in the returned strings:

{ foo: ‘Bar’ }

What portion of the version should be updated with this change?

MAJOR: It could break someones code who is relying on the case of the returned value.

MINOR: This is adding functionality because the value being returned is actually a title for a story.

PATCH: Stories should always have been capitalized so this is actually a bug fix.

This shows that the rules are up for a lot of interpretation and will depend heavily on your situation. This unfortunately doesn’t make it easier to explain to someone who is new to, or skeptical of, semver. As a solution I came up with a slightly more specific set of rules which I think make the decision much easier for everyone.

Jeff’s semver incrementing version number rules:

I inverted the rule set so it can be read that any later rule overwrites the previous rule so the version section moves up a level.

If this is fixing a reported bug in your system: PATCH

If this is adding a feature to your public or private api: MINOR

If this is a change to your private methods or data structures: MINOR

If it broke your public api call tests: MAJOR

Because your tests should test exactly what you expect your public API to return it should be very trivial to know when a change is breaking what others could be relying on.

The official release date of Ubuntu 14.04 LTS Trusty Tahr is coming up in just over a week from the time of writing. With that, many of you are going to want to install the next version of the best Linux operating system on your computers, and if you want to install on metal along side OSX and have a Apple Mac or Macbook this is the guide for you!

You're going to need a few things before we get started:

Download Ubuntu 14.04 LTS Trusty Tahr. (If you're here before it's released you can download the daily image here. Be sure you download the iso which does NOT have '+mac' in the filename. This is for older Apple computers.

Download the rEFInd Boot Manager. You want the Binary source file zip which you need to extract.

A 2GB or bigger USB stick which has nothing on it that you don't care to lose. This will be our boot stick...(remember when they were boot disks?)

A thunderbolt to ethernet adapter or if your machine has an ethernet port, plug it in. After installing Ubuntu it is unlikely you will have wifi until the final step.

Your computers hard drive should have a big chunk of free space...you're going to use this as your primary operating system afterall!

An hour or so of free time. This took me about 30 minutes from start to finish but I had done it a number of times by the time I created this post.

Obligatory Warning

All of this information is provided without warranty of any kind. Always make and keep proper backups of your data.

Step 1

Backup your computer

While it's unlikely that an issue will occur which wipes the data on your disk it's always highly advisable to have a couple quality backups just in case.

Go make another backup...I'll wait.

Did you back up your data yet?

Step 2

Now that you have a quality backup safely tucked away you will need to install rEFInd. Open the terminal and navigate to the location that you extracted the zip file and then follow the installation instructions for OSX. Once completed, restart your computer to confirm that rEFInd was installed correctly. On rebooting, the rEFInd boot loader should load up and you should select the Apple logo to get back into OSX. (sorry for the sub par photos)

Step 3

Now that you're back in OSX we need to take that iso of Ubuntu 14.04 that you downloaded and make a bootable USB stick. Follow the 10 steps outlined here to create the bootable stick. You'll know when it's ready because OSX will pop open a dialogue saying that it cannot read the device.

Step 4

You need a place to put Ubuntu on your computer, so you'll need to create a partition on your hard drive. The size of this partition will depend on the size of your disk and what you plan to do in Ubuntu, but it should be at least 10GB to give you some wiggle room (mine is 100GB). To do so you will use the OSX tool 'Disk Utility'. There are some dated, but still accurate instructions on creating this partition here.

Step 5

With the partition made it's now time to stick the USB stick into your computer and reboot. After rebooting you should land on the rEFInd boot loader again with a few more options than before. If you do not see these options then reboot again holding the "option" key.

Your options may look a little different but you want to pick one of the options which are provided from the USB stick (There are three provided in this image). For the Haswell equipped machines you want to pick the option which reads something along the lines of "Boot EFI\boot\grubx64.efi ..." and hit enter. This will start another boot loader with the first option "Install Ubuntu", hit enter to select this option. After a little while you should be in the Ubuntu installer, follow through the steps until the installer asks you where you would like to install Ubuntu.

Note: If after progressing through the install process and you find that it boots into a black screen start again from Step 5 but choose an installer without "EFI" in the path name.

Step 6

Note: partitioning will be a little different for everyone so if you get confused hop onto IRC in #ubuntu on freenode.net or create a question on http://askubuntu.com for some help.

When you step through the installer you will get to a pane which asks you where you want to install Ubuntu to. The options should be pretty self explanatory. But if there isn't an option to install Ubuntu into your new partition you will need to take the manual route. Select the manual partition option and you should be shown a screen which looks like:

As you can see form this list, I created a 100GB partition originally and then created a 3GB swap partition. To take the partition you created in OSX and create a swap from it you will need to select it then hit the "Change" button and downsize it 3GB. This will leave you with "free space" of 3GB. Click the "+" button and create a new partition of the type "swap". You'll want to make sure your primary partition is of type "ext4" and that the mount point is "/".

Continue on from here installing Ubuntu to your new partition.

Step 7

After the installation has completed remove the USB stick from your computer and reboot. Now when rEFInd shows up you should have an extra option with the Ubuntu logo. Click it and boot into Ubuntu.

Step 8

Once you have logged into Ubuntu, click the 'System Settings' icon in the launcher bar on the left. Select 'Software and Updates' and then select the 'Additional Drivers' tab. After this tab loads you should see a proprietary driver for the Broadcom wireless, select it and click 'Apply'. Reboot the computer and you should now be able to click the network icon in the top right of the desktop to connect to a wireless connection.

Congratulations you now have Ubuntu installed along side OSX!

Our industry moves so fast that just to stay on the curve, let alone ahead of it, you need to spend a considerable amount of time reading other peoples code. Whether that be in code reviews, gists, or open source projects, you can glean a lot of invaluable information about new technologies, protocols, and techniques.

As an industry as a whole we need to understand this and write all code, even that which at first is not meant for public consumption, as self-documenting code with comments which detail, to anyone reading it, the why the code is doing what it's doing.

Self-documenting code is code which follows commonly accepted style conventions, and uses descriptive variable, and function names. As an example, self-documenting code turns this:

function gd(p1, p2) { return [p1.x - p2.x, p1.y - p2.y]; }

Into:

function getDifference(point1, point2) { var x = point1.x - point2.x; var y = point2.y - point2.y; return [x, y]; }

It's much easier to understand what the second function is doing at a glance vs the first.

This function is so trivial many will stop here and continue on. But trivial scripts have a way of becoming more, whether they grow into a project of their own or are copy/pasted into much larger projects where their use may not be as clear.

Lets assume for a moment that this function was copy & pasted into a larger projects utility class. Wouldn't it be nice if it would automatically be added to the API docs?

/** Calculate the difference between the x and y coords of two points. @method getDifference @param {Object} point1 The first point to compare. @param {Object} point2 The second point to compare. @return {Array} The difference between the two points in the format [x, y] */ function getDifference(point1, point2) { var x = point1.x - point2.x; var y = point2.y - point2.y; return [x, y]; }

This function can now be copy and pasted into any project without any ambiguity about it's functionality and will automatically be included in the API documentation.

To illustrate the importance of inline comments even with self documenting code. Take the following method from the Juju GUI source.

The Juju GUI has just over 65,000 lines of javascript excluding dependencies and growing fast every day. With so many developers writing code this fast it would be very difficult to understand why things were done the way they were done without the additional 17,000 lines of api comment blocks and inline documentation.

exportYAML: function() { var result = this.db.exportDeployer(); var exportData = jsyaml.dump(result); var exportBlob = new Blob([exportData], {type: 'text/plain;charset=utf-8'}); saveAs(exportBlob, 'export.yaml'); },

Using only self-documenting code you would probably be able to figure out that this function extracts some data from a database, converts it into yaml, then saves the blob to disk. Unfortunately this would have taken you at least 4x longer to parse because it doesn't have any comments. You would also be missing some very important information from a previous bug fix. Now here it is with it's comments:

/** Export the YAML for this environment. @method exportYAML */ exportYAML: function() { var result = this.db.exportDeployer(); var exportData = jsyaml.dump(result); // In order to support Safari 7 the type of this blob needs // to be text/plain instead of it's actual type of application/yaml. var exportBlob = new Blob([exportData], {type: 'text/plain;charset=utf-8'}); saveAs(exportBlob, 'export.yaml'); },

Without even reading the code you now know what the purpose of this method is which will dramatically reduce time when debugging or adding more features. More importantly however, the why of some of the code is outlined for future-you or another developer who may end up here. Without the comment regarding Safari 7 they very likely could have changed the mime type to application/yaml and introduced a difficult to find bug.

Last week the latest version of the Juju GUI was released. With the holidays and our move from Bazaar and Launchpad to Git and Github there was unfortunately over a month from our last release. Have no fear however because this one brings with it some big changes.

We made a large number of bug fixes most of which were reported by you, like incorrect unit counts in bundle details and fixing the inspector height calculations so that it doesn't hide some of the lower buttons for environments with a lot of units.

90% speed improvement in the inspector for environments with thousands of units.

Inspector relations tab now shows the relation statuses and any units that are in error

The biggest change that we made in this release was entirely removing the full screen browser. This allowed us to remove over 4000 lines of code from our code base speeding up the application start up time and lowering the size of the application sent over the wire.

One thing that anyone who has used the internet for more than a day can attest to, is that we have a lot of credentials to remember. Every new product we purchase, every new website we log into, every system in corporate networks need a unique username and password to access. To help combat the huge number of credentials we need to remember many administrators have started to implement what is known as single sign on.

Single sign on, or SSO, is the practice of having the user to log into a central system which then grants them access to multiple systems. If you have ever logged into a third party website using your Facebook, Google, or Twitter account you have used SSO. From the user perspective this is incredibly convenient because now they only have to remember a single set of credentials for multiple systems. Unfortunately SSO does little to combat users from using simple insecure passwords which, when compromised, will now give the attackers full access to a number of systems instead of just a single one.

As an additional layer of security many administrators are implementing another layer of security called two factor authentication. 2FA simply means that there are multiple techniques used to identify you when you attempt to gain access to a system. This can be in the form of a text message being sent to your phone, or a random key generated by a third party key generator which is required to be entered along side your typical username and password.

This all sounds excellent, but unfortunately it is very complicated and time consuming to implement both systems correctly and securely. To solve this issue the great people in Juju Labs at Canonical have started a project to bring instant SSO & 2FA to Juju users everywhere.

How are they going to do it? Because every system from Apache, to MongoDB requires a different technique to implement SSO & 2FA, a third party repository will be created which will house a large collection of expertly written components which will interface with the SSO & 2FA Juju Charm.

As with everything in Juju Labs this will require buy-in and support from the community to push forward. There are already three contributors out of the required five to move it to the next stage and a number of people who are very interested in seeing this become a reality. If you are interested in being able to add SSO and 2FA into your systems with a few clicks or want to lend a hand as a contributor you can flip through the slide deck below, spread the word around, or sign up as a contributor.

Earlier today I talked with some of the YUI team about the Juju GUI and how we use YUI for the first 'YUI in the wild'.

The links I mentioned in the video:

Juju GUI Demo Site

Juju GUi Bazaar repository

It's been a few weeks since our last Juju GUI release which means here comes another! This GUI release brings with it the latest beta version of the Juju quickstart plugin...

Juju GUI

Our latest work focuses on making the Juju GUI a more effective day-to-day tool:

The service inspectors now categorize errors and pending units by their types instead of grouped as 'error' and 'pending' so that it's easier to see your services status at a glance.

Services that are in the process of being destroyed no longer disappear immediately from the canvas so you can follow along and make sure that there aren’t any problems in the teardown.

Service level relation status is now shown on the inspector relation tab.

You can now drag and drop from a bundle file or the Charm browser.

Bundle deployments now give you better feedback during deployment so you have some insight into what’s going on.

The remaining notes can be found in the changelog

More exciting work in this direction is coming, including long-requested features like per-unit debug logs and local charm deployments!

Juju Quickstart

The quickstart plugin is nearing feature completion and has a lot of great improvements.

For new users, if you don’t have Juju installed, after it adds the stable PPA to your system and installs Juju, it will create an environments.yaml file that you need to edit.

For everyone, when you run quickstart, it will automatically log into the GUI for you as long as you accept the security certificate in your browser within two minutes of it appearing.

We also fixed a bug triggered when your default series was not precise.

The next release will guide new users through creating environments.yaml interactively.

To try out our new releases, existing users can upgrade their GUI charm to cs:precise/juju-gui-81; or run:

juju deploy juju-gui && juju expose juju-gui

...or update the juju-quickstart plugin via apt and run:

juju quickstart

New users on Ubuntu can do the following to get everything installed and start an environment with the GUI running and ready:

sudo add-apt-repository ppa:juju/stable sudo apt-get update && sudo apt-get install juju-quickstart juju-quickstart ## ...edit ~/.juju/environments.yaml file... juju-quickstart

Next quickstart release will hopefully remove those last two steps.

New users on other operating systems can’t use Quickstart right now, but the Juju installation instructions can get you started, and..

juju deploy juju-gui && juju expose juju-gui

..can add the GUI to your bootstrapped environment.

While writing code for the next features in the Juju GUI I needed to test instances when charms would fail in various stages of their setup or execution. After a lot of messing around it became apparent that most charms are just too stable for this kind of testing so, I wrote a Juju Charm which is designed to fail in a large number of hooks depending on the configuration set on deploy (or later), and can relate to itself to test relation failures.

The charm, innovatively named 'failtester', can be found on launchpad or on jujuCharms.com. In depth details on proper use can be found in its README but it's really simple to use:

Note: This charm should only be used for Juju or Juju GUI development. It has no other functionality than to fail predictably.

// bootstrap your juju environment juju bootstrap // deploy the failtester charm juju deploy cs:~hatch/precise/failtester // set the failure type you want to occur // the failtester charm will now fail in its install hook juju set failtester install=true

Known Issue