I love the fact that it's all just self-contained. That the language includes so many helpful functions in the box. [...] PHP scales down like no other package for the web and it deserves more credit for tackling that scope.

and to that, Matthew comments:

It's nice to see leaders of projects like Rails having this same attitude. It's a breath of fresh air in the competitive market of web development frameworks.

There's three new tutorials posted:

• Ruby Block Scope - the basics of Ruby block scope, a common point of confusion for PHP developers new to Ruby.
• Variable Arguments - an article that shows two common API patterns found in Rails, variable arguments and option hashes, and how to implement them both in PHP.
• Regular Expressions in Ruby - a useful reference that maps all of the common PHP regular expression functions to the equivalents in Ruby.

Check out the rest of the site for even more great content.

Rails for PHP Developers is a new site for PHP developers who are also interested in Rails and Ruby. PHP and Ruby are great complementary tools that are sometimes seen as adversarial, which is really unfortunate. We use both and we'll be writing regular articles to help cross-pollinate ideas and promote collaboration between the communities.

There's already some good content there - useful perlisms in ruby, a look at PHP object attributes and some information about the release of the site itself.

Back in January 2005, I announced on the O'Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby (cdbaby.com) website, and rewrite the entire thing in Rails, from scratch. [...] The first few months showed good progress, and Jeremy could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do.

But at every step, it seemed our needs clashed with Rails' preferences. (Like trying to turn a train into a boat. It's do-able with a lot of glue. But it's damn hard. And certainly makes you ask why you're really doing this.)

Recounting the rest of the story, Derek mentions the turning point ("Is there anything Rails can do that PHP CAN'T do?") and the speed at which they were able to make up for the two years of lost development time. To helps others make a decision for their project, he also includes seven reasons why he made the decision to switch back, including:

• Our entire company's stuff was in php: don't underestimate integration
• Don't want what i don't need
• I love SQL
• Programming languages are like girlfriends: the new one is better because *you* are better

There's also been several bloggers in the PHP community that have responded to the article:

• Elizabeth Naramore - "Derek Sivers' Article on RoR vs PHP"
• Paul Jones - "Is there anything Rails can do that PHP cannot do? *No.*"
• Terry Chay - "Why PHP triumphs over Ruby"
• Jeff Moore - "Ruby versus PHP or There and Back Again"

Compared to the current problems Rails is facing PHP is proving itself within a very wide range of sectors including the commercial sector. And although PHP in its raw state is slower to develop for and more prone to having BAD code written for it. The guys at Zend (and the open source community) are doing a great job at building a framework that is making developed quicker and enforces better code practices.

He talks about the advantage of using a framework and how, because PHP is such a flexible, open language, it's easy to go "under the hood" and mess with things a bit. This is all in the scope of the issues that Rails is having and how it's a bit more difficult to make things custom to what you need.

This post is geared towards folks who haven't done the "A" part of "AJAX" before (And I mean the first "A", as in "Asychronous"); are new to Yahoo's implementation of the XMLHttpRequest object (The Yahoo! Connection Manager) and would like added information on how that works; or both.

Sarah starts off slow with an example of making a connection to a backend PHP script as called by a HTML form. The simple example is fleshed out with a database backend (via PEAR::DB) and the Javascript to handle the response and the errors that might arise. Finally, a request can be made and the result eval-ed to give the client a nice, simple Javascript object to work with.

I know the title is harsh but it's so true. At least it is according to nowadays php's implementation of classes and objects, which do not permit to "reopen" and add or redefine new methods to an existing class definition, which is the basis upon Rails (and I presume lots more of applications and frameworks) is built.

The post goes on to talk about they "why" behind the statement - basically that this kind of functionality makes it easier to "Extend. Morph. Adapt. Improve. Refine." your applications. She talks some about other frameworks that have tried to offer the same kinds of functionality Rails does (CakePHP and Symfony) but notes that they still have their limitations (in specific, mentioning CakePHP's AppModel functionality).

In my previous post on this topic I described the method we used to convert a legacy MySQL PHP database to a Rails conformant PostgreSQL hosted version. In this article I will tell a bit about how we converted the HTML of the application to Rails layout templates and partials.

It's a quickpost this time showing how to extract the rendered HTML from the page's output, writing out some of the business logic, and a mention of test driven development versus write test after developing methods.

The idea behind it is pretty simple: Often you have two Models that are associated with each other where setting the associations themself via hasAndBelongsToMany isn't quite enough for what you try to to.

He gives an example of the code, a method to get around the typical CRUD pattern without breaking it. His example involves users and groups and storing information surrounding them. Storing the data about the groups and which users belong to which groups is easy - it's when you start including some meta-data into the mix that things get a little complex.

He provides the sample code to make it all work - three models and three controllers - and the database structure to work behind the scenes.

So far they've indexed over 3,000 projects and their conclusion seems to be that among Web scripting languages, PHP is the undisputed champion (as measured by the LOC count).

He also notes that they've discovered something interesting - despite the lowering numbers of developers/projects being done with PHP, the code and applications seem to be growing still. Andrei interprets this as a positive move for developers away from the "reinvent the wheel" school of thought to a more "find something that works already and go from there".

Check out the original article for more information on the stats and some charts to show the trends.