In the last 24 hours, I have had three glimpses into emergency plans. First, my local coffee shop -- the true source of my productivity -- experienced a water main break. Second, a site I manage experienced a server failure. Third, I came across Netflix's recently open sourced Chaos Monkey tool.

HP Cloud has migrated its blog site into Drupal. This makes the fourth Drupal migration for HP Cloud. But it is the first one to be running entirely inside of our own cloud.

We're using HP Cloud Compute instances, our Relational Database in-cloud MySQL server, Object Storage for all static files, and CDN to seamlessly serve public files out of a content distribution network. What is more, we now have a Stackato-based architecture for rapidly deploying Drupal sites into the cloud.

Over on the HP Cloud blog, I've got an article explaining the architecture.

If there is one single problem I would identify with the now nearly ubiquitous JSON format, it's the absence of comments.

Why is this a big deal?

1. Comments can be used to document. Since JSON has gained currency as a configuration file format, this is a big deal. Take a look at the default Apache configuration file. Take a look at /etc/hosts. Comments play an important role as unstructured inline documentation.
2. Sometimes things need to temporarily go away. Sometimes during testing, it can be necessary to change large sections of a data file. Being able to toggle a couple of comment sections is the easiest way of doing this. But as JSON stands now, this sort of thing requires keeping multiple copies of a file around (and synchronized).

I'm hardly the first person to criticize JSON for this, and Douglas Crockford, the author of the JSON spec, has responded to this criticism. But his response is, I suggest, unsatisfactory. Here's why.

For a few years I have fostered the development of Fortissimo. Fortissimo is a different kind of PHP framework. Instead of the MVC pattern, it combines the Front Controller pattern with the Chain-of-Command pattern. Like Software Factories, it is based on the idea that developers should focus on strongly interchangeable and re-usable components and provide a DSL that can be used to combine components.

Today I have transferred ownership of Fortissimo from my GitHub account to Masterminds, and organization of which I am a member.

In many ways, I am not the average PHP developer. PHP was not my first language. I came to it after learning C, Perl, Java, JavaScript and others. And my initial reaction to PHP was, "What a funny little template language!" But through a long and convoluted career trajectory, I ended up as a professional PHP developer.

Why did I end up depending on PHP for my daily bread? There is one simple reason: It's everywhere. Project after project, client after client, I kept running into PHP. There were home grown utilities to fix. There were webmail clients to tune. There were blogs to write plugins for. And there were CMS systems to build out.

It's been three or four years since I transitioned from developer-who-happens-to-know-PHP to a PHP developer. Day in and day out I hack on PHP code. I wouldn't say that I've grown to love PHP, but I've certainly grown comfortable with PHP.

I know there is a constant stream of PHP cynicism. Like Perl before it it, PHP has no shortage of detractors. But I think PHP might be getting better.

The funny thing, though, is that it's not the language that's getting better, it's the community. I think there are four clear ways in which this is true:

• A Move Toward OOP
• Loaders
• Libraries
• Professionalization

I briefly explain each of these below.

tl;dr: FIG is a welcomed force in PHP standardization. But I believe their recent two standards have undercut their credibility. By choosing contentious grounds, issuing an arbitrary standard that competes with existing conventions, and doing this in an area that does not actually improve the interoperability of code, they have weakened their position as a standards body. I suggest that they remedy by downgrading PSR-1/2 from "standard" to "recommendation."

In mid-June, the relatively young Framework Interoperability Group (FIG) proposed a pair of new standards called PSR-1 and PSR-2. FIG's ostensible mission is to provide PHP-related standards to bring some level of interoperability between the plethora of PHP frameworks and applications.

But these two standards, and PSR-2 in particular, have in my mind undercut the larger goal of the standards body. That is, releasing these two documents as formal standards harms the credibility of what had looked like a very promising standards body. Here I explain why I think this, and suggest a remedy.

I hate typing long shell commands, so I often create for myself short shell scripts that perform common tasks for me. I can hard-code all those options and arguments. Sometimes, though, there are a few bits that I want to change on a run or I don't want to hard code into a shell script.

Here's an excellent example: I don't want my password stored in a shell script. Ideally, what I want is to be prompted for my password.

There is a very simple shell built-in that you can use to do this: read. Here's how it's used.

Have you ever accidentally suspended or stopped a process in your shell? In UNIX, Linux, and Mac OSX it is easy enough to do. An accidental hit to CTRL-z will suspend a program, returning a message like this:

    [1]+  Stopped                 top

The message above says that the process that was stopped is named "top". What it means is that the process still exists, but is in an suspended state where it is not actively doing anything. If you try to exit your shell session, you will get a message saying something like zsh: you have suspended jobs. and you will not be able to log out.

The easiest way to restart after this is to type the command fg:

    $ fg

That will start the last stopped program. You can optionally supply a name to fg. We stopped "top" above. We can restart it like this:

    $ fg top

That will restart "top" even if it wasn't the last process stopped.

I was thrilled to read the story at Mobile Drupal about how ConsumerSearch is using Pronto.js to expose their huge Drupal content to their mobile application.

Pronto.js is designed to be a high performance asynchronous application framework that makes it simple to chain together components to build sophisticated application logic. It's the JS equivalent of the PHP Fortissimo framework.