One year ago I listened to Allen Wirfs-Brock of the Mozilla Foundation deliver the closing keynote for StrangeLoop 2011. Wirfs-Brock's central claim was jarring. Keep in mind, this is a conference whose attendee list is dominated by language designers, database architects, PhDs, and people whose credentials make the term "senior" seem like a gaping understatement. Yet in front of this crowd, Wirfs-Brock unabashedly coronated JavaScript the new king of programming languages.

I did not buy it. But a year later, I'm changing my mind.

Packt now has 1,000 titles! Packt's royalties sharing model contributes a percentage of book royalties back to open source projects, and they've now exceeded £300,000 in contributions. (Packt is a UK-based company.) To celebrate their 1,000th title they are offering one free ebook to anyone who already has or creates a new account at PacktPub.com. This offer, as I understand it, lasts until the end of September, 2012.

Over the years, I've published seven books and a number of articles with Packt. In fact, my author ID on their website is '4'. It's been great to see a startup thrive in an industry long dominated by a select few giants. Packt has also been a huge force in publishing Drupal books. While big companies like O'Reilly have a few Drupal titles, Packt has around 40.

EDIT: Originally I said three free ebooks. This was incorrect. It's only one.

TL;DR: There's an experimental version of QueryPath 3 for you to try and let me know what you think: https://github.com/technosophos/querypath/zipball/3.0.0-experimental-fin...

Either respond at support-querypath@googlegroups.com or to @querypath on Twitter.

Read on for the onger explanation.

Reverse proxies and web servers sometimes forward HTTPS traffic to their backends using HTTP. (In other words, they handle the SSL with the client, and the backend only has to handle HTTP). This can provide a speed boost, and is generally a good thing. But smart backend code may need to ensure that the remote client is only making HTTPS requests. (See this Drupal issue, which suggests that the problem impacts Drupal, and that it will not be solved in core).

Some such reverse proxies (I know of Zeus, Stackato, and Nginx) will set a special HTTP header, typically X-Forwarded-Proto or X-Forwarded_Proto. This will have the value https if the client request was over HTTPS, and http if the client used HTTP.

Here's a simple way that a backend Apache server can rewrite a client request to instruct it to only connect via HTTPS:

  RewriteEngine on
 
  # Rewrite to SSL for anything coming off of a proxy.
  RewriteCond %{HTTP:X-Forwarded_Proto} ^http$
  RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [L,R=301]

Of course, the value may also be accessed in PHP using $_SERVER['HTTP_X_FORWARDED_PROTO'].

The first two articles in a series about the HP Cloud PHP bindings is available on the Cloud Matters, the official HP Cloud blog. Matt Farina is writing this series.

• Part 1: Integration PHP Apps with the HP Cloud
• Part 2: Including and Bootstrapping the library
• More will come this week and next.

The HP Cloud library, which is developed on Github, is a project Matt and I started. It wasn't intended to be part of HP's offerings. Instead, we started the project because we wanted to build our own tools to work with our cloud services. We have a number of specialized internal tools that we use for things like debugging the Identity Service catalog or taking snapshots of DBaaS instances.

We also wanted to be able to store Drupal assets inside of Object Storage, and building a PHP library was the first step. (The second, of course, was to build an HP Cloud Drupal module).

The high point so far has been launching our new blog entirely inside of our own cloud architecture, powered in a large part by this PHP code. We'd been dipping our toes in the water, but this was a head-first plunge.

It's been rewarding to see this library go from "scratching our own itch" to being generally useful for others. The library still has a way to go, and we've just about pushed it to 1.0, but I'm encouraged to see how far it has gone already.

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.

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.

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.