In response to some criticism about his previous post with some framework benchmarks, Wojciech Sznapka has posted updated results using the latest versions of each framework.

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.

On the Udemy blog there's a new post with a large infographic showing "who reigns supreme" comparing Ruby, Python and PHP (don't worry, this isn't flamebait...it's actual good stats comparing the state of these three languages).

Just as the Japanese, Spanish and French languages are uniquely different, programming languages also have their variations, some more popular and easier to use than others. With the recent introduction of some new ones, there is a 'war' of modern day languages. What's easier and faster to use is not always the best option.

The graphic includes stats like:

• Usability ratings
• Popularity in the TIOBE index
• How much it's discussed (from the IEEE Spectrum, IRC)
• The number of open job postings
• Average run time/lines of code

Check out the full post for more interesting data.

On NetTuts.com today there's a new tutorial showing off a package management system for the CodeIgniter framework, Sparks, that makes installing and using packages similar to Ruby's gems.

Sparks is a new package-management system for CodeIgniter that extends the core with support for gem-like sparks. This tutorial interweaves an entry-level overview of the architecture and usage of the sparks system with the creation of dovecote-a simple spark for managing RSS data.

The tutorial introduces you to the Sparks system and helps you get it installed and configured to work with a first basic package - a dovecote example. He helps organize and write the first spark as well as set up any dependencies and autoloading it might need. He follows this by adding some functionality to the package to make pushing output to the view simpler.

You can download the source for the complete tutorial's code.

On DZone.com there's a new post from Giorgio Sironi looking at how to automate a build of a virtual server with Vagrant, setting up a LAMP-based development instance.

Vagrant ia a tool for building virtual machines (in VirtualBox's format) that conforms to a specification. It's written in Ruby, but it makes really no assumptions over the environments that you're gonna build; in this article, we will setup a virtual server for PHP applications running inside Apache.

The end result is a virtual machine based on VirtualBox images and can be built in a few easy steps:

• install the vagrant gems on the build system
• add a new virtual box instance pointed to a .box file
• create the Vagrant config (including the commands to run post-create)
• set up a little port forawrding
• creating a phpinfo file and starting up Apache

One suggested place for grabbing images (some with pre-defined software) is Bitnami's "Stacks" repository.

Lars Tesmer is currently in the process of learning Ruby. He' been working through the tutorials and some sample scripts and has come across some pitfalls along the way. In his latest post he shares four of them that've stood out in his development so far.

I'm currently learning Ruby. In this post I'll list some pitfalls for programmers coming from PHP that would probably cause some confusion if you aren't aware of them. This list is by no means complete, while I learn Ruby I'll very probably encounter more gotchas, which I will blog about, too.

For each of his four examples, he gives the code PHP developers are used to seeing and the Ruby code that may or may not do what you'd expect:

• Arrays are continuous
• Zero is not falsy
• The keywords private and protected
• There's no static keyword

In his latest article comparing some of the functionality of PHP to Ruby, Dave Kennedy looks at modules, mixins and ducks and how they compare to PHP's interfaces and abstract classes.

If you have been writing PHP for a few years you will no doubt have come across Interfaces and Abstract classes. They were introduced in PHP5 object model and since have had medium usage in the PHP world. If you Google "PHP Interfaces" you will get some results on the official documentation and the rest saying how pointless they are. Why the divide? I believe it is mainly down to lack of understanding to what interfaces give you. They imply what your classes should do, but that's it. Yep, we are talking programming contracts.

He starts with some code examples of an interface and a class that implements it (to work with PDFs). He makes an abstract class to extend the functionality even further and allow for different kinds of reporting PDFs to be generated. From there he moves into the Ruby world, showing examples of duck typing and modules to avoid duplication (mixins).

RubySource.com has posted another in their "confessions of a converted PHP developer" series (more here) with a new article comparing namespacing between the two languages.

The moment you start writing code that grows beyond a few classes, you start to realise that you need a way to group files and logic. While this is easy to do, it can become quite difficult to ensure that you have class names that are unique and don't end up accidentally clashing with other classes in your own code, or classes in other people's code that you are using.

He talks about PHP's namespacing, a relatively recent addition, and how pre-5.3 "pseudo-namespacing" was done through class and directory names with autoloading. He compares this to Ruby's module support that provides a sort of built in namespacing support. He includes a multiple namespace Ruby example and shows how to nest modules for even more fine-grained separation.

Bastien Labelle has posted a new (tongue-in-cheek) post to his blog today about a presentation he and a friend of his recently gave at a conference - Why PHP is so Much Better than Ruby.

Of course, saying that PHP is so much better than Ruby is pure bullshit, and this talk is, as I hope you guessed, a big big sarcasm. Trolling apart, I think this talk is also quite interesting, since somehow it shows some of the weaknesses of Ruby and its ecosystem.

Included in the post are their slides and a brief transcript of the main points they mentioned. Also interesting are some of the comments mentioning the typing issues the talk discussed and the fact that popularity isn't the same as quality.

In another entry in his "Confessions of a Converted PHP Developer" series Mal Curtis about a typical class development path PHP developers take and how it can be a limiting, linear progression from one step to another.

In converting to Ruby I realized how strict PHP is in its class hierarchy. This surprised me as I'd always viewed PHP as a very loose language, mainly due to its loose typing and lack of formal code structure guidelines. [...] I find most PHP developers learn starting by using inline PHP as a low learning curve entry point into dynamic web languages and then move on to fuller, more complex, applications.

He includes a few code samples comparing how Ruby, while still allowing the same kind of structure, also lets you redefine classes on the fly. His example shows redefining a method in a Ruby class using a method commonly called "monkey patching". It's good that he points out a downfall of the approach too:

I must note that Monkey Patching is often a quick fix solution that can create headaches for future developers (or for yourself, if your memory is like mine) for several reasons. [...] Use at your own risk!

There's several different articles all over the web talking about the "monkey patching" approach and if it's possible/useful in PHP.

On the Knp Labs site there's a recent post showing you how to use Capifony (a tool designed for use with Symfony projects) to deploy your Symfony-based applications in a few easy steps.

Deploying should be an active part of your development process, but not something that gives you a headache. If deploying your entire application takes more than one command or doesn't put a smile on your face, you should keep reading. NOTE: This post will specifically cover how to deploy your Symfony2 application, but the library used here - capifony - is just as useful for deploying a symfony 1.x application.

He walks you through the simple five step process of installing and configuring the capifony tool to pull from a remote git repository, set up some shared directories and update the vendor libraries on deployment. A few more changes for the initial deployment and you'll be ready to call "cap deploy" any time you'd like to push the latest version of your application. He also points out that with version 2.0.9 and above of capifony, Doctrine database migrations are also supported. For more information on capifony, see the project's website.