On DZone.com Giorgio Sironi shares what he describes as his "standard PHP setup" - the tools and standards he commonly uses when developing his projects.

Last week I passed a day speeding up a Java and Ruby oriented team which started developing a PHP application: not only a standard project structure was required, but also some hints on the default tools and process to work with it. Here's what I thought was crucial during the setup, based on the question of my Rubyist colleague. Of course one of the most visible differences is the language itself, but there is a lot more tacit knowledge to share.

Things mentioned in the post include: development tools (like IDEs), the language itself and similarities to other languages, a standardized project setup, a good testing methodology and a bit of discussion about using external libraries.

Dave Gardner has put together a guide to deploying PHP applications with the help of Capistrano, a Ruby-based deployment tool (including some example "recipes").

Capistrano is written in Ruby and offers up a basic DSL from which you can craft quite flexible deployment scripts. [...] That said, it's very flexible. In my current setup I have it deploying to multiple environments (dev, staging, production), building code (think Phing), running tests on the servers before finalising the deploy and then restarting worker processes on completion.

He starts by introducing some of the commands that you can perform with the "cap" command line client and links to an example PHP project structure you cn base your deployment off of. He also includes a bit about multi-stage deployments, tag (version) selection and the full source of his build script.

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.