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.
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.
Cool, but Why Mashery?
Aside from the beer and a chance at a kick-ass iPod, why would you care about Mashery?
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 email@example.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 firstname.lastname@example.org 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.
All that’s missing now is news that Mike Wallner’s totally fabulous, essential-in-today’s-world freakin’ awesome HTTP extension is getting rolled into PHP 6.
Well, here’s hoping. They say that Things happen in threes. There couldn’t be a much better trio of announcements than that.
JSON Decoding in PHP 5.2.1 is Broken
As of PHP 5.2.1,
json_decode() no longer follows the published standards for JSON-encoded texts.
Why not? For no reason other than the convenience of those ignorant of JSON standards.
Prior to PHP 5.2.1, this:
As of PHP 5.2.1, it results in:
Nice and handy, perhaps … but a blatant violation of JSON specifications, since
'true' is not a valid JSON encoded text.
A little history
Rather than roll some new JSON interpreter, I chose to leverage the Services_JSON package along with ext/json to build a package that was compatible with ext/json, but usable for those who did not have that extension installed. With compatibility built in, developers could move application code back and forth between systems without having to worry about whether or not the extension was installed — if it was, the application would benefit from the added performance of a native extension. If it wasn’t, everything should work exactly the same way.
In the course of my research for the Solar_Json package, I learned a lot about JSON and how it is supposed to behave. JSON.org is a spartan but complete resource about the format, and includes the JSON Checker and a comprehensive JSON test suite. There’s also a link to RFC 4627, which details JSON’s structure in a proposal for the formal application/json media type.
While digging through all this JSON goodness, I came to appreciate ext/json’s strict adherence to JSON’s format. The version of ext/json bundled with PHP 5.2.0 (version 1.2.1) was right on the money in its parsing, and by the time I was done, Solar_Json matched it every step of the way. To ensure ext/json compatibility, I wrote a series of unit tests (26 in all) to ensure that Solar_Json’s “pure PHP” implementation matched ext/json’s output exactly.
It was challenging, but it worked out well. The result was Solar_Json.
JSON Bundled with PHP, Confusion Ensues
All was good, for awhile.
(Yesterday, Paul M. Jones re-ran the JSON unit tests I’d written for Solar_Json using PHP 5.2.1 in preparation for a new release of Solar. He mentioned that some of the tests started failing, which sparked this discussion. Thanks, Paul!)
Sure, a couple people (myself included) didn’t fully understand JSON for awhile. I even opened (and quickly closed) a bug in the way I thought certain strings should be decoded by the
json_decode() function. Others had the same confusion.
What’s so confusing?
Well, the common thing that people want to do is something like this:
The confusing part about these two snippets is that they both return
NULL instead of
true. Based on the two bug reports (#38440 and #38680), it’s common for people to expect the output to be a boolean
true in these examples.
However, if you understand JSON at all, you’ll know that
NULL is a perfectly reasonable result, because
'true' are not valid JSON texts.
Note that I said “if you understand JSON at all”, you’ll realize that
NULL is a perfectly reasonable result when attempting to decode an invalid JSON text.
I should amend that: If you understand JSON at all and actually care about standards and compatibility, you’ll realize that
NULL is a perfectly reasonable result of parsing an invalid JSON text.
Section 2 of the standard states very plainly:
A JSON text is a serialized object or array.
JSON-text = object / array
Translated, that means that a valid JSON-text is either an object or an array. It’s not a string literal, an integer, a boolean. The list of what a valid JSON-text can be is short. It can be an object. It can be an array. It can be … whoops, that’s it. An object, an array, or it just isn’t JSON.
DAMN, that’s inconvenient, you may be thinking. Yep, it is. But, it is what it is. If you don’t like it, submit an RFC to have it changed. That’s the way this crazy thing called the internet works.
Put another way: if you don’t like it, you do not just start making things up. Apparently, enough people unclear on the concept of JSON complained about their lack of understanding that PHP now just does whatever it wants with JSON. Check this out for the details. (And to reiterate, I’m not knocking the people who aren’t clear about JSON. I was one of them too, up until I actually researched how JSON is supposed to behave.)
Imagine if the core team behind every language did that. Hey, if you don’t like the standards, just ignore them! We can explain it away with documentation, right?
The cavalier attitude taken by the PHP internals team on this issue is inexcusable. Yep, cavalier — a colleague who spoke to a member of the PHP internals team about this change confirmed that the break from the JSON spec is deliberate and intentional.
To make matters worse, the version number of ext/json did not change between PHP 5.2.0 and PHP 5.2.1. In both releases, ext/json claims to be at version 1.2.1, despite this significant change.
While some are lobbying to compile the definitive business case for PHP (and I even piped in and agreed that it was necessary), some PHP internals folks are effectively shooting that effort in the foot by disregarding published standards.
I’ve spent the better part of the last two years defending my choice of PHP 5 as my preferred language, first at Feedster, now at Mashery. With all the buzz about other languages these days, the case for PHP is getting harder to make. Incidents like this will not make the case for PHP any easier.
Is this a big flap over a little thing? That’s certainly one way of looking at it. I see this flagrant disregard for published specs as one more cut toward a death by a thousand cuts.
Talented and notable developers are dropping PHP, or seriously considering other languages. If PHP’s next 10 years are to be as poignant as its first, a significant attitude adjustment is required.
My post yesterday struck a chord that many others were also hearing, as Andrei’s post and the comments that followed it indicate.
Potential developers of new frameworks, take note: Your announcement will be followed by wholesale eyeball-rolling.
Stephan and the Stubbles folks feel that my reaction and Andrei’s are somehow knee-jerk, and that if we really looked at their framework, we’d feel differently. Perhaps this is true, perhaps it’s not. I can say that if I spent time browsing code for every new framework that came out, I’d never have time for anything else (what with three n00bs in the last couple of days).
What I always wonder when these things come out is: why are people pouring their talents and energies into frameworks that will probably never have a critical mass instead of building something cool with existing frameworks?
Yes, it’s hard to build applications. There’s all that unpleasant user interface work and design considerations to think about, and you actually need a relatively complete package before you can announce/release something. But, given the landscape of PHP frameworks, there is no less work to building the next “everybody uses it because it’s so damn handy” application than there is to building the framework that everyone will eventually use.
Build a cool app. Forget about your own personal stamp on the framework world; you missed the boat on that one. But, if you want to make a mark, the world is wide open for new and cool applications. Pick an existing framework, start building your app, and contribute fixes back to that framework’s community as you find shortcomings in your needs for your app.
OR, if you’re not an application guy, and only feel comfortable with the plumbing, then pick a framework that has a shortcoming and fix that shortcoming. If you’re afraid that your work will not be accepted, or that there will be too many contribution political hurdles, then pick another framework (there are plenty to choose from, after all).
We need better tools, and better applications. We DO NOT need more clean slate starts.
…. yeah. PHP will definitely never have anything unifying like Rails.
Meanwhile, I encourage you to join up with the Solar community (as I have done instead of launching my own framework) … you’ll be glad you did.
For those of you who missed it, PHP 5 was released almost THREE YEARS AGO. That’s right … in a couple months, we’ll celebrate the 3 year anniversary of PHP 5.0.0 stable’s release.
I am fully aware that there are a handful of compatibility issues between PHP 4 and PHP 5 (outlined here). I was bitten by a few of those myself when I first started porting code over to PHP 5, but none of them were major issues.
So, PHP 4-using majority: what’s keeping you?
Is it your ISP that is behind the times? Your company’s system administrator? Your dependency on slow-to-upgrade libraries or applications? Or something else?
Please post the reason you haven’t upgraded yet in the comments below. I’d very much like to know what the resistance is to PHP 5.
Like many of my fellow geeks, I’ve found a few moments to play around with Yahoo Pipes over the last couple of days.
The first pipe I’ve created and published is the PHP Extension Monitor. It’s an aggregated feed that pulls in release information on several cool extensions that aren’t announced in the PECL feed, such as Suhosin, XCache and DBXML.
Since I use all of these extensions at Mashery, I thought it would be nice to have an aggregated feed to keep track of those releases along with the PECL releases feed.
So, please check it out. Hope it’s helpful to someone else out there. Please make a note in the comments if you’d like to see additional cool extensions added to the feed.
My thoughts on the creation process: Pipes is a cool tool, and a very impressive bit of UI scripting. As Aaron noted, the actual generation of the feed is quite slow. I hope they have some kind of caching in place.
If the PHP Extension Monitor feed is a popular idea, but Pipes proves to be too slow to handle it, let me know and I’ll create a more traditional back-end aggregator for it.