I know PHP. I mean, I really know PHP. Not just the syntax, or the idioms and idiosyncrasies, but why. I can tell you why something works the way it does, under the hood; and I was probably around when the decision was made to do it that way. Thirteen years with any language is a long time. [...] Ultimately, it comes down to: Is it the right tool for the task? Because of this, ultimately when I come to write a web site, PHP is my tool of choice. Know thy tool well, and it shall treat you well. Then along came Engine Yard, and I was exposed to just a ton of fantastic engineers who happen to choose Ruby as their tool of choice.

His project was the site for the Distill conference Engine Yard is putting on in August. He lists a few "WTF" moments he came across when learning and creating the site with Ruby including issues with parentheses on metod calls, method naming rules, implicit returns and variations on control structures. He also talks about some of the other technologies used to power the site like OAuth and S3 for image uploads (via paperclip). He finishes out the post by wrapping up the experience and talking some about the benefits of getting outside your comfort zone and learning something wildly new (language or other technology) to give you perspective.

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail's case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of "buried" code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby's dark magic, e.g. eval(), include(), require_once(), system() and, let's not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise… Pay attention to competing applications or frameworks - their problems may also be your problems. If you're worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters' might originate from.

In my previous post Modern framework comparison I presented performance tests, which compared Ruby On Rails, Django and Symfony2. After recieving a feedback in comments I decided to run this benchmark one more time on my own laptop (instead of on my hosting). The reason was simple: enviroment was outdated.

There were some overall performance increases were seen, but some statistics were higher - the "time per request" for all of them grew, some by quite a bit. He presents these benchmarks with a caveat, though:

You should never choose framework based on benchmarks. Those shows them from one point of view, but there are plenty of other aspects, such as support, community, maturity, number of ready to use components.

There is occasionally people asking about things such as "Is there an integration for X in framework Y?" Then they are disappointed when it isn't, acting as if it's a really bad thing. But why do things need to be integrated to begin with?

He points out that other frameworks (ex. Ruby on Rails) have a lot of things integrated, but he doesn't agree that this should be the standard. He suggests that, by not having tools that are tightly coupled with the framework you're using, you open yourself up to a wider, possibly better range of external tools.

One could argue that integrated libraries give you a productivity boost. While it may be so, I think the main boost you get is the very first steps: It's easier to get started, but after that the benefit fades. In the long run, it may even turn into a poor investment in general, as you could have learned a general purpose tool instead.

If you ask me, which one is the best - I can't point one, all of them are very good. But let's try to measure frameworks. For purpose of this article, I created three applications in Symfony2, Django and Ruby On Rails. All those apps do the same - show two tables, one shows top USA cities (by population), second shows US states with highest number of big cities (above 100k citizens). I don't want to measure frameworks by echoing "Hello world", because it's pointless.

Each of his applications use the same data set and use a default ORM with optimized queries, HTML rendered by an internal template engine and rounded floats. His performance requests (using Apache's ab) for this sample application show Symfony2 being able to handle the most requests/second followed by Ruby then Django. Symfony2 comes in at a larger file size than both the others combined, though. As far as the community is concerned, Ruby on Rails outpaces the others with about three times as many "watchers" on Github.

Be sure to read the comments for some opinions, both for and against his results.

The reason I know PHP has to die is because I've seen this before. Roughly a decade ago, PHP killed Perl. [...] As a language for newcomers, and especially for web developers, it was already dying in 1999 and was mostly dead by sometime around 2005. [...] There was no reason you couldn't write a perfect web app in Perl, but in PHP you'd do it faster and easier, despite the flaws in PHP itself which were, even then, already obvious.

He talks about moving on from PHP, why almost requiring a framework to do anything these days is a bad thing and how, despite the flaws the language has, he feels "trapped in a language that's losing its suitability for the task." He suggests that one successor might be Ruby on Rails but also points out some of the flaws it has including performance, Active Record and possible issues with code generation. He notes, though, that this isn't quite the replacement he had in mind and that there's just not something there to fill that gap.

Be sure to read the comments for lots of great opinions from both sides of the PHP opinion fence.

It has been said ad nauseam that comparing PHP and Ruby on Rails is unfair as one is a programming language and the other is a full-stack framework. In spite of this, we can compare PHP frameworks (which have learned a lot from their first releases) and Ruby on Rails, again not by piling up a list of features, which would be also cluttered by different extensions and plugins. I'm talking about the different approaches taken by PHP and Ruby framework developers.

He talks about the options (or lack there of) that each side of the same web development coin provide and how "magic" and configuration come in to play when developers are making their selections for the most relevant technologies.

In 2006 I created killerphp.com because I wanted to make it easy for web designers to learn PHP. I thought PHP was THE predominate web programming language and I felt every web designer should include PHP as one of their core coding skills [...] Then Ruby came along...for a short while.

He looks back at the time when Rails was "the best thing since sliced bread" and was taking the web world by storm. Other Ruby frameworks have come along and are taking the lead (like a merge of Merb and Rails). So, what does Stefan think the problem was with RoR's climb to fame and popularity? The crucial pieces that were missing (libraries, functionality, etc) and its poor resource handling that could lead to some big problems with certain kinds of applications.

There's lots of great comments from both PHP and RoR-ers alike, so be sure to gives those a look too!

Gregg Pollack and Jason Seifer from RailsEnvy.com do some Ruby on Rails commercials in the same style of the Mac vs PC ads. Videos produced by Jason Hawkins of MakeFilmWork.com.

Other videos include Ruby on Rails vs .NET, Ruby on Rails vs Django and, of course, Ruby on Rails vs ColdFusion.

Oracle is running a free workshop at its Headquarters on August 25th. This is a call for developers interested in developing applications in PHP, Ruby/Rails, Java, .Net or even wanting to use Oracle's free SQL Developer tool or learn web development with Oracle's APEX product.

They'll be providing lunch and the information, you just show up and soak it all in. You can find more information about the event here (and register to reserve your spot).