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.

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.

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.

Once upon a time I knew a vi mantra for removing carriage returns from a DOS-formatted text file, thus transforming it into a UNIX file.It was something like :%s/^V^M//g. It has become such an ingrained habit that I can still type it without even thinking about it. Muscle memory.

But VIM knows more about a file than that old clunky version of vi did, and there's an easier and more consistent way of converting between DOS and UNIX in VIM.

To convert from DOS to UNIX:

:e ++ff=dos
:setlocal ff=unix
:w

This basically forces the document into DOS mode, and then tells VIM to switch it to a UNIX file. (That closing :w just writes the change to disk.)

ff is VIM's abbreviation for fileformat. If you want to type that all out, you can. And ++? It tells VIM to effectively reopen the current file. So make sure you save your work before running these commands.

To convert from UNIX to DOS is even easier:

:e ++ff=dos
:w

That forces the file into DOS mode and then saves the change to disk.

Since both of these hook into a deeper level of VIM, they're not as prone to bugs and inconsistencies as relying upon a regular expression.

But wait... I need to do something more complicated...

The above is a great way to do simple conversions, but if your needs are more complex, you might want to take a look at the VIM wiki page in this topic.

A few years ago, I tested SPLObjectStorage and Arrays to see which performed better. My conclusion at the time was that SPLObjectStorage is the better performer.

One thing I did not examine there was the implications of size. I ran tests with a fixed size of 10,000 elements. The test was also run on PHP 5.2.

A recent email from Frederik Krautwald caused me to re-evaluate these benchmarks. Using PHP 5.4.10 on Windows 7, Frederik generated this set of benchmarks:

Forbes covered HP Cloud's announcement of the new Platform as a Service (PaaS) project.

This is my favorite quote from the article:

With this announcement HP’s Cloud grabs a potentially big technological advantage. Expect other cloud providers to do the same by quickly following HP’s lead of an integrated PaaS technology as key a differentiator. It’s also interesting to see that HP has selected ActiveState to form the core of its new PaaS offering. ActiveState’s Stackato is built atop VMware’s Cloudfoundry project, and is described as an application platform for creating your own private, secure, and flexible enterprise Platform-as-a-Service (PaaS) using any language on any stack on any cloud.

The same story was picked up by other outlets. My favorite "negative" take on it was posted on Diversity, Ltd . The author uses some loaded language (a poisoned chalice? Really?) to describe HP's partnership with ActiveState (Why? No idea). And he makes much of the fact that Stackato is a fork of Cloud Foundry. But I think his conclusion is right:

It’s not all negative for HP however. PaaS is, I believe, the future of the cloud and, more importantly, provides an opportunity for large traditional IT vendors like HP to bridge to offerings that will be compelling in the future world. Of course the fact that they can sell some cloud servers to run the new private PaaS offering doesn’t hurt either and I’m looking forward to seeing how seriously the company articulates the value of this product.

(As usual, I speak for myself, not my employer.)