Over the years, there have been many simple polls about PHP frameworks, libraries, and other PHP periphery.

I've created a more comprehensive survey about PHP frameworks, libraries, databases, evaluation techniques and other assorted tidbits in an attempt to better understand how people pick the libraries they do. My hope is that if enough people complete the survey, a picture will form that illustrates some itches that so many projects have been created to try to scratch.

I intend to share some (perhaps MOST) of the information gathered -- so don't worry that all this is going into a black hole somewhere.

The first version of the Killersoft PHP Frameworks & Libraries Survey is available here: http://j.mp/phpsurvey

Take a few moments to fill it out if you can! It should only take 10 minutes (or less!).

When it comes to technology, everyone thinks they want interoperability. Using SQL, JavaScript or map APIs? There's an abstraction layer for that (SQL, JavaScript, map APIs). Writing mobile applications? There's an abstraction layer for that too (PhoneGap, Appcelerator, among others).

Developing "cloud-native" applications? Soon there'll be an abstraction layer for that too. Yesterday Zend announced the Simple Cloud API, a set of PHP classes for "writing scalable and highly available applications that are still portable."

Sounds great, right? Not so much. As Chief Architect of a PHP-based "cloud-native" application that's handling hundreds of millions of requests per month, there's no way I'd consider using Simple Cloud. Here are five reasons why you shouldn't either:

1. Abstractions leak. It's never as easy as it seems, which becomes painfully obvious at the least opportune moment. Let's have a show of hands of how many people have launched a SQL-abstraction based web application, only to find later that the crazy-ass SQL your toolset generated was 100x slower than one you'd have cooked up on your own. Okay then. The Law of Leaky Abstractions drags us down when it's time to figure out what's broken.

2. The Lowest common denominator rules. Abstraction layers often talk about unifying access to technologies where the differences are insignificant. Which is funny, since the providers of those technologies introduce differences to be competitive. Do you really want your web applications to be built around the elements of cloud services that are all the same? Your competition will likely be focusing on leveraging cloud advantages to the max, which will inevitably mean taking advantage of features that a lowest common denominator API ignores.

3. The true leaders don't participate. Simple Cloud lists contributors including Microsoft, IBM, Rackspace, Nirvanix and Go Grid, and dubs these companies as "leading the cloud revolution." Note how the three published APIs all include support for an Amazon Web Services solution. Who's really leading here? Amazon is leading the cloud revolution, and has been all along. Everyone else is just playing catch-up.

We've seen a similar situation recently. Remember OpenSocial? Google, MySpace, Yahoo and a few others banded together when Facebook handed their asses to them a couple of years ago. Facebook has never participated, and continues to lead the pack in social platform application development.

Of course all the companies that are not leading want to band together for the sake of interoperability, since interoperability means a greater chance of survival. But as a developer, be careful of getting roped into these company-serving agendas--it will cost you more than it costs them, with little return on your investment.

4. Native adoption isn't hard. Have you looked at the Amazon Web Services APIs, and noticed how many of them actually use the term "Simple" in their full descriptions? SDB is short for SimpleDB, S3 is short for Simple Storage Service. Is an API simplifying these already-simple APIs really necessary? If you're looking for a reduced feature set and inability to leverage each service to the maximum, sure! Otherwise, bite the very tiny bullet and learn about each service that you need. They're not hard. Trust me.

5. Face it: You'll probably never move. Despite portability claims, you'll likely never move from one service to another willy nilly. Consider the last significant web application you built around the database of your choice. Even if you used an abstraction layer, do you really think you could just pick it up tomorrow and move to a competing database engine? Whenever this scenario is truly considered, it's a much more complicated problem than just swapping out the underlying RDBMS. An audit must be done of all code to make sure no one snuck in a workaround query that included vendor-specific features, a new backup system needs to be evaluated (odd that no one has cooked up an SQL backup abstraction layer!), performance testing needs to be done ... all for what? Try doing this in a real company and see how quickly your plan gets shot down. Real companies have real business problems to be solving, and rarely have spare engineering cycles to waste on switching technologies that lie behind abstraction layers. So, just because you could doesn't mean you ever will.

With all that said, don't get me wrong: I love it that there are multiple providers getting into the cloud computing game in a meaningful way. I am actively evaluating each service and looking at ways to spread my cloud dependancies around to reduce my exposure to single-company cloud fail.

However, with each set of services I evaluate, I look for exactly the kinds of differentiating details that abstraction layers strive to hide, and will build out my application to leverage each environment to the max. My company and the services my customers consume deserve the very best utilization of upstream resources possible. Don't yours?

With all the TechCrunch50 chatter earlier this week, it's easy to see how entrepreneurs feel that if they're not putting on a great showing at an event like TC50, they're missing a golden opportunity. That notion was craftily compounded by the announcement of the sale of the first TechCrunch40 winner's (Mint.com) to Intuit for $170M. Well played PR, folks.

All the buzz was then followed by Sarah Lacy's parade-drenching "Memo to Start-ups: You're Supposed to Be Changing the World, Remember?", which gripes about this year's TC50 crop playing it safe.

I didn't attend TC50, but I have attended these start-up launch binges before. It's never clear who benefits the most from these events, but my gut tells me it's most often the event organizers, and not the start-ups themselves. Sometimes the commentary is good, but there are other ways to get that kind of honest feedback. In some cases, the launch binge meat markets don't even offer commentary or criticism -- they just give you a five minute slot.

To me, these kinds of events aren't necessary for entrepreneurial success. By the end of the event, no one remembers who's launching what, and instead of gaining momentum naturally, all an entrepreneur's efforts are bet on the hope that everything will go off without a hitch with the presentation, the people watching won't be bored or distracted, etc. Despite what start-up bloggers and event organizers want you to think, you just don't need the meat market for a successful launch.

Look at the esteemed judges of TechCrunch 50:

• Reid Hoffman of LinkedIn
• Marc Andreessen of Netscape
• Tim O'Reilly of O'Reilly Media
• Kevin Rose of Digg
• Tony Hsieh of Zappos

Also, consider the other world-changing companies that Lacy mentions, such as Google, Facebook and Twitter.

Now ask yourself: How many of these world-changing companies launched their start-up selves at a meat market?

I'm not questioning the value of "normal" TechCrunch publicity, nor am I even saying that I'll never launch a start-up at one of these events someday (as hard as it is to imagine, never say never). I'm merely suggesting that many of the real game-changers of the next wave may have decided their companies are worth more than 15 minutes of pseudo-fame at a launch binge.

We'll know them when we see them.

Many of Amazon's official PHP5 libraries for Amazon Web Services are now available (unofficially) for use as Subversion svn:externals.

To add to your SVN-managed project, just do something like this:

svn propedit svn:externals library

And add:

Amazon http://killersoft.googlecode.com/svn/AWS/tags/update-2009-05-15/Amazon

This assumes, of course, that you're keeping your external libraries in a directory called "library" (many Zend Framework-based projects are laid out like this). Adjust to suit your own needs if necessary.

I'm not wild about the code layout of Amazon's official libraries. They're more verbose and cumbersome than a many other wrappers that have been created around Amazon services. However, in the end I choose to use them despite that, for one reason: they're the official libraries.

They're updated more often than any other set of PHP libraries for AWS. In fact, they're often updated on the same day that API changes are released for the underlying services. And, they're comprehensive; many AWS libraries wrap "the easy stuff" or "the commonly used" stuff, but leave you on your own if you actually need to do something non-easy or uncommon.

So, my suggestion is to use these. Hopefully having them in all in a single, easy-to-include place will make life easier for you. It has for me!

My plan for keeping these current is to create a new "update-[date]" tag whenever any of the libraries are updated, with the date of the most recently updated library as part of the directory name. Details about what's actually changed within the update tag will be documented in a README.txt file in the top level.

You can find the "ground zero" update for the AWS libraries in update-2009-05-15, browseable here.

PHP 5.3 is now yum-installable.

Ever been frustrated that the latest this-or-that package for PHP is bogged down in Big Distro Packaging politics? I have been. That's why I've put together a deliberately-current-as-possible repository for PHP RPMs.

The repository is currently i386-only, though I'll be adding x86_64 packages within the next week or so. Also, "regular" and "debug" builds are available for all packages, so that users may be more helpful in troubleshooting what issues they find.

The current list of packages, as well as all the RPM spec files for building them and information on how to set up the repository for use on your CentOS5/RHEL5 servers is available at the killersoft-yum Google Code site.

Have fun!

Update: I forgot to mention one of the things I think is interesting about the way I've packaged the PHP modules in the repository. Each supported SAPI -- apache2handler (mod_php), fastcgi and cli -- each have their own configuration paths and php.ini files.

/etc/php.mod.d/php.ini

/etc/php.cgi.d/php.ini

/etc/php.cli.d/php.ini

Within each directory, a subdirectory for per-extension config is present.

If you don't like this setup, no problem: just symlink them all together and you won't know the difference. However, I think it's convenient to be able to easily specify extensions that you want to use in mod_php that you don't want to use in the PHP CLI, and vice versa. If you need an ultralight PHP CLI for some reason, you can have it without having to hobble mod_php that's running on your website.

To offset the length of the article, I'll be brief: my deep dive into Amazon's PHP libraries for AWS is now available. Enjoy!

It's not blatently obvious, or mentioned in detail, or even shown in any of the examples or introductions to the service.

But it's true: Amazon's new Elastic MapReduce service supports mapper and reducer scripts written in PHP. PHP 5.2.6 is installed in the environment created by the MapReduce job flows.

Make sure to include this in your reading today. Read it slowly, perhaps a few times. It’s interesting stuff to keep in mind if you’re concerned about achieving maximum performance in your PHP applications.

Thanks Gopal Vijayaraghavan, link via Greg Beaver.

AKA: Mashery Recruiting at php|works

The company I had pleasure of co-founding last summer is once again on the prowl for top-notch, Zend Certified PHP developers.

We’re taking the hunt for these folks to php|works in Atlanta. Whenever possible, Mashery will be luring the quality developers with free beer.

That’s right: free beer that is free, as in beer.

We’re also sponsoring a lunch on BOTH Sept 13 and 14, as a good coder knows she cannot code on beer alone.

Show anyone from Mashery some proof that you recently took a PHP 5 Zend Certification Exam or are already PHP 5-Zend Certified, and we’ll enter your name in a drawing for a free 8GB Apple iPod Touch.

Cool, but Why Mashery?

Aside from the beer and a chance at a kick-ass iPod, why would you care about Mashery?

Well …

• Mashery is doing demanding PHP work at the bleeding edge of today’s most exciting technologies, such as mobile applications, AJAX and of course, web services.

• We work with cool tools like Amazon EC2 and S3. And we work them hard.

• Mashery’s clients represent a growing stable of very high volume web services. We tune our services to shave milliseconds off their runtime, and pound on PHP until it (occasionally) weeps.

… among other things.

After more than a year since co-founding Mashery, I can honestly say that in my ten years of working with PHP, I have never had more fun. The work is very hard, but very rewarding. And, it’s always interesting; as a “smart proxy” operator, Mashery’s engineers are constantly facing new challenges and solving them in creative ways.

Never a dull moment, as they say. That’s Mashery.

Up for it?

If you’re interested in learning more about Mashery and our unique opportunities, drop us an email at jobs@mashery.com. The job posting is here.

If you’re going to be attending php|works in Atlanta, be sure to look me up. I’ll be there with fellow co-founder Kirsten Spoljaric from Wednesday thru Friday evening. Email phpworks@mashery.com to set up a time to meet with us, or to find out about what our beer and food distribution schedule will be.

Facebook experienced a technical glitch over the weekend. The nature of the glitch was that the source code for the Facebook homepage was displayed instead of the result of the execution of that source code. Widespread news of the glitch first broke in this TechCrunch article by TechCrunch writer and OmniDrive founder Nik Cubrilovic.

I agree with Cubrilovic that the inadvertent delivery of source code instead of the result of that source code is certainly a horrific situation, with potentially serious ramifications for any company that experiences such a problem on a large scale basis.

That a company like Facebook, currently a hot ticket for searches, articles and blog posts, would experience this kind of problem is noteworthy.

Unfortunately, the updates appended to the article imply that PHP is somehow responsible for this leakage. In the first article update, Cubrilovic states:

It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconfiguration or high load (this is a known issue).

On the first of Cubrilovic’s suggested causes, server misconfiguration: well, duh.

Of course servers will behave strangely if they are misconfigured. The world of a system administrator is one of details, and when it comes to managing load balanced web servers for an extremely high-traffic destination like Facebook, it’s a world of a large number of details. Miss one of them and things will predictably start breaking in unpredictable ways.

On Cubrilovic’s second allegation: It’s “a known issue” that PHP barfs out source code under high load? I’ve been writing PHP code for some very, very high traffic websites for over 10 years, and this is the first I’ve heard of this.

Surely we in the PHP community would have heard from someone like Rasmus if PHP were prone to puking source at a high load. As an infrastructure architect at Yahoo!, Rasmus has likely seen how PHP behaves under load levels most of us only fantasize about. If PHP coders were building their applications on a platform pre-destined for Twitter-like failures, no doubt we’d have heard about it by now.

Can anyone provide links to articles or posts indicating that PHP will eject application source under a heavy load?

It’s infinitely more likely that Facebook’s problems were caused by a system administrator breaking some web server configuration (possibly not even PHP-specific configuration), or a new installation of a mod_php build that hadn’t been tested properly in a non-production environment.

Cubrilovic’s second amendment to his article links to an article on his own blog, Learning from Facebook: Preventing PHP Leakage.

Given the likelihood of this issue’s cause being server misconfiguration, it is disturbing that Cubrilovic’s first tip for avoiding this kind of problem is to install and correctly configure the powerful and complex Apache module mod_security. After all, if the a sysadmin can’t get Apache and PHP configured properly, how likely is it that they’ll be able to get two modules configured properly?

The rest of Cubrilovic’s tips also relate largely to web server configuration, such as making certain files inaccessible from direct requests.

The disappointing part of the FUD that Cubriolovic is spreading is that anything more than decent release practices are necessary to address and avoid the problem Facebook experienced.

I can only imagine why Cubrilovic has invested this weekend in undermining people’s faith in PHP’s reliability under heavy load. What I can tell you, though, is this:

PHP doesn’t cause website problems and inadvertent code leaks. People making mistakes while using PHP and other powerful tools do.

However, that fact isn’t worthy of two articles, so perhaps that’s why Cubrilovic went with the PHP-as-boogeyman-that-must-be-defended-against approach instead.

What’s the take-away from all this? Servers are powerful, and can be complicated. Tread carefully. Don’t roll untested configurations of web servers and related modules out on production without testing them in an identical staging environment.

Know what you’re doing, and do it carefully.