Raphael Stolt has done a review of a book that's helping bridge the gap between Rails and PHP for those already using the PHP language. The book "Rails for PHP Developers" (part of the Pragmatic Programmers series of books, authored by Derek DeVries and Mike Naberezny) is a guide to learning Ruby on Rails from a PHP developer's perspective.

The e-book version of the Pragmatic Programmers release Rails for PHP Developers written by Derek DeVries and Mike Naberezny occupies now some of my scarce hard drive space for several months, and today I managed to hit the last page of it. In case you're interested in knowing if it's worthy to sacrifice some rare hard drive or bookshelf space for this book read on.

He goes through the three parts of the book - a look at the MVC pattern, teaching some of the details of Ruby and comparing the structure of the two languages to help PHP developers relate a bit more. Raphael gives it good marks for being a great guide to not only Ruby and Rails but to also making it accessible for PHP developers to make a smoother transition from one to the other if they're interested.

In a recent entry to his blog Andy Jeffries gives an overview of his site's transition over from one framework to another - away from Symfony and over to Rails.

I decided as I was learning/using Symfony at my contract at the time that it would be a good experiment to write it in Symfony. [...] The site did fairly well when I posted but I still posted in frequently.

After redefining the site's purpose a bit, he reconsidered the language (and framework) choice and decided to do a rewrite in Rails. He gives a comparison of the process on things like lines of code, time to build, performance differences, deployment and automated testing.

As Matthew Weir O'Phinney points out, David Hansson (of Rails fame) has posted a few comments on what he calls the "immediacy of PHP".

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.

Mike Naberezny has posted a few more articles to the "Rails for PHP Developers" website (based on this book) covering some more of the basics.

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.

Mike Naberezny has start up a new resource to try to bridge some of the gap between PHP and Ruby and to help developers of either to get a bit more insight into the others' side - Rails for PHP Developers (based on the book published by the Pragmatic Programmers).

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.

The PHP Community is buzzing about a new article, posted on the O'Reilly Ruby blog, about how the author (Derek Silvers of cdbaby.com) made the decision that Ruby on Rails just wasn't right for the project he was working on.

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"

On his "What I accidently learnt about programming" blog today, Nick Halstead shares some of his thoughts on Open Source scaling functionality in languages, specifically comparing Ruby and PHP.

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.

From the DevChix website, there's this new post that helps introduce developers (both in PHP and Rails environments) to hos to use the Yahoo! UI connection manager in their applications.

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.

Well, according to Soledad Pendaes, PHP will never have a (real) Rails-like framework because of some of the limitations with objects inherent to the language.

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).

The LoLoCoJr site has published part two of the series (part one is here) about converting a PHP application over to Rails.

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.