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.

Pandoc is an Open Source tool (and a library) for converting documents from one format to another. Specifically, it can take a document written as Markdown, reStructured Text, Textile, HTML, DocBook, or LaTeX and convert it to any of a plethora of other formats, including:

• Word DOCX
• Open Document Text (ODT)
• HTML, XHTML, or HTML 5
• PDF
• LaTeX
• EPUB ebooks
• Many others

The Pandoc project provides installers for Windows and Mac. Pandoc already has packages in most (if not all) of the popular Linux distributions.

In addition to its general conversion functionality, Pandoc augments the input formats with support for citations, mathematical notation, and many Markdown extensions.

Aaron Winborn is a prolific contributor to Drupal, not just code-wise but as a community member as well. He's been diagnosed with Amyotrophic Lateral Sclerosis (ALS), a degenerative nervous disease that will shorten his lifespan considerably. He has posted about his condition and its impact on his family on his blog.

Along with the the other co-authors of Drupal 7 Module Development, I am donating my portion of the 3rd and 4th quarter royalties of this book to a special needs trust for the Winborn family.

Drupal 7 Module Development is a great book for those interested in getting started with Drupal development. If your looking for a good Drupal book, please consider buying this one. 100% of the royalties will go to the Winborns.

Even better, contribute directly to the trust. Our royalties work out to only a few dollars per book. A direct contribution will go a lot farther.

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.

Dear Social Media Users,

I'd like to ask you to perform a courtesy.

Recall your six-year-old self on the elementary school playground. You're likely to have overheard (or perhaps made) statements like this:

• "She's stupid."
• "You're a fatso."
• "He's such a retard."

We all give a hearty frown of disapproval. These things are not said as constructive criticism, or to open a dialog or solve a problem. They're said out of malice. They're said to hurt. When we hear children say such things, we intercede. We try to explain to them that this is not appropriate behavior.

Now I'd ask you to consider a few recent one-liners derived from various social media:

• "Romney's a two-faced Mormon liar."
• "The Supreme Court are all smoking crack."
• "Obama is a fascist hell-bent on undercutting your freedom."

Of what constructive value are these? How do they help mature US citizens engage in meaningful political discourse? Who is better off after reading these statements?

I know it's an election year in the US. I know feelings are running high when it comes to politics. But ostensibly, if you're old enough to vote, you're old enough to discern a legitimate political point from a playground insult.

So to turn a phrase, act your age.

I'm not pointing fingers. I'm not naming names. Nobody's on the stocks for this. But from here forward, can we agree to operate at a higher plane of discourse?

If not, if you insist on using your God-given right to freely express yourself any ol' way you want, I will simply employ my Zuckerberg-given right to unfriend you.

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.