Recently I have been doing all kinds of DevOps/Orchestration work setting up in-cloud servers and services. Most of the time, what I want to be able to do is quickly and repeatably create several servers all working together. But I don't need a full orchestration system. I've found three promising solutions (in alphabetical order):

• Ansible
• Fabric
• Stack-Kicker

Here's a very basic overview of each of those.

Awesome is a window manager that you can use to replace or augment other desktop environments like Gnome Desktop and KDE. I find Awesome appealing because of the different perspective it brings to window management. Instead of windows floating free on the desktop, Awesome provides various tiled views of windows. This maximizes screen usage, and also adds some workflow. Keyboard shortcuts are plentiful and convenient (and make use of that otherwise untouched Windows key).

Installing Awesome on Ubuntu 13.04 was a piece of cake:

$ sudo apt-get install awesome awesome-extra


But from there, it got tricky. I expected to log out of my current desktop and be able to switch desktops into Awesome. But Awesome wasn't on the list of desktops. After lots of poking around, I found out why. While Awesome is configured by default, it is also disabled by default. To enable it, you ned to edit /usr/share/xsessions/awesome.desktop and set NoDisplay to false:

[Desktop Entry]
Encoding=UTF-8
Name=awesome
Comment=Highly configurable framework window manager
NoDisplay=false
TryExec=awesome
Exec=awesome
Type=Application

Once that is done, Awesome will show up on the list of desktops in LightDM when you log in. After you're logged in, you can begin to get a feel for Awesome and start tweaking it to your needs.

Thanks to Jekyll and some similar technologies, static site generators have recently made a comeback. Static sites have distinct advantages when it comes to cloud computing: They have simple requirements (static web server), consume small amounts of resources, and can be hosted out of object storage at extremely low cost.

MiddleMan is a generic static site generator. Rather than focusing only on blogs, as Jekyll does, it provides the basic facilities for building any type of site. Extensions extend MiddleMan by providing specific features. The architecture is elegant and easy to use.

In this article, I show how to create a simple blog using MiddleMan (and it's blog extension).

The task was simple: I wanted to run xhprof (the Facebook-developed PHP profiler) to get some quick-and-dirty metrics on a PHP script. While xhprof is actually really easy to install and use, I had to read a surprising amount of material in order to run a simple install and write three lines of code.

To spare others the agony of cruising old Facebook docs in the Internet Archive, here's a 30 second guide to installing and using xhprof.

I recently began working on some PHP code for resolving HTML5 entities into their Unicode codepoints. According to the code, it had been optimized for performance. The code was moderately complex, and the authors appeared to have gone through great pains to build a specialized lookup algorithm. But when I took a closer look, I doubted. I decided to compare the "optimized" version with what I would call a naive version -- the simplest solution to the problem.

Here I show the two solutions, and then benchmark them for both memory and speed.

Cloud compute instances are like disposable servers. They make a great platform for application development as well as deployment. But frankly it's no fun to spend time setting them up time and time again. Lately, I've been amassing a collection of tools and strategies for working with compute instances in the cloud. One thank I think is outstanding for its combination of simplicity and power is Ubuntu's Cloud Init.

To expedite setting up a LAMP (Linux/Apache/MySQL/PHP) server, I've created a very simple Cloud-Config YAML file that I can attach to a build request when I build a compute instance. In this post, I'll show how I do it.

We Americans hold fast to the myth of the self-made man, and when we give autobiography, we often steadfastly refuse to acknowledge how in so many cases we didn't pull ourselves up by the bootstraps. We were lifted up and pushed forward by others.

I am guilty of failing to acknowledge how indebted I am to my mentors. So I want to start setting the record straight while also sharing some of the lessons I've learned.

Dr. Wes Munsil studied at Caltech, Cambridge University, and University of Colorado. He was on the standards committee for the Pascal programming language, wrote code for the NASA's Voyager project, and has worked on a wide variety of projects, large and small. When I look at my current career trajectory, and even my life's trajectory, his influence is easy to see.

Here are a few of the lessons I've learned from him -- some taught with words, but most by example.

A programming language is a language designed to be read by both humans and machines. It is an intermediary that saves us (the programmers) from manually reducing all of our high-level designs to straight boolean logic. But it's also structured in such a way that current machine resources can unambiguously interpret it.

When you write a program, your code has two audiences. Humans and machines.

When we alienate one audience, the machines, the result is that the machine either does something wrong or cannot do anything at all. When a programmer makes this kind of error, we call it a bug. Bugs are bad.

But a mistake all too often made is for programmers to intentionally or unwittingly alienate the other audience. I recently inherited a codebase that had a single function whose body was 2, 996 lines long. It had high cyclomatic complexity (lots of control structures), hundreds of variables, and crazy indenting. For the most part, it worked fine. The computer understood it. But trying to add features and find and fix bugs has been a tremendous chore. This program was not written for two audiences. It was only written for one.

If I rewind the clock, I can remember numerous occasions where I wrote cryptic code, failed to document, and committed other such sins. And I can think of many times when I've returned to my own code weeks, months, or years later and have had to re-invest substantial time in figuring out what I wrote. My code was not written for two audiences.

Perhaps what we need is a new term. A counterpart to "bug" that describes the code's failure to remain semantically transparent to humans, and not just to computers. Because like computers, when programmers pick up a piece of code and find it indecipherable, they give up.

Unlike computers, they may just go build an alternative.

Today the HP Cloud Node.js JavaScript library was made publically available at GitHub. The new library provides Identity Service (aka Keystone) and Object Storage (Swift) libraries.

Along with writing the actual library, I've worked with it on projects, and it is stable and usable. The APIs are similar to the PHP library that we released last year.

To install:

    $ npm install hpcloud-js

And usage instructions can be found on the official site. We also have complete API documentation, thanks to Matt Farina.