ActsAsFlinn

Some of you might have seen the O’Reilly article by former Rails trumpeter Derek Sivers entitled 7 reasons I switched back to PHP. Or the Slashdot article, even more ominously named Thinking about Rails? Think Again. In typical fashion, Slashdot ran the link with a suggestive name which I’m sure will effect the credibility of Rails in the eyes of the uninitiated masses of PHP developers trolling the website.

I happened to read the article earlier in the morning before it made it to Slashdot and didn’t think too much of the arguments behind the article. I can honestly say from my own experiences that mismanagement of a project, not limitations of a framework or language are usually to blame for missed deadlines, and project failures. I can say that from experience after developing the same project in both PHP and Rails with about 1/3 of the tables (and probably logic).

Anyone with a lick of common sense can tell you that if you’ve got a legacy application with 90 tables, migrating that data and accompanying application to an MVC framework is going to be a big project. With a 2 person team, 1 of which is the owner of the company (who should be focusing on more important things), the project is going to take a long time, cost a lot of money and the likelihood of failure is high.

I think Derek’s logic and motivations for pursuing the project should be at question, not his choice of programming language or framework. Why do companies go into business? To make money of course. What possible reason does a company then have to rebuild it’s entire infrastructure from the ground up? To either make more money, or save money ie. make more money. The 7 reasons he switched back should have coincided with business considerations before he started the project not after the project failed. I think it’s shameful to place the blame of the project’s failure on the language and framework choice.

I’d love to hear what bitsweat honestly has to say about the project but we can be sure either an NDA or professional courtesy will keep that from coming out.

The comments at the end of the article do this opinionated scapegoat of an article justice.

Useless post without a concrete illustration.

Show us an example of:
1) What you tried to accomplish.
2) How you tried to implement it in rails.
3) The rails code that "didn't work." 
4) The "beautiful" PHP code you created instead.
Richard Hertz | September 22, 2007 08:03 PM

I especially like this one:

I'm a little reluctant to add to the wasteland that is this post and these comments, but here goes.

I'm familiar with the situation here. The deal was this: Derek was not a programmer; he was a musician. He learned some PHP and cobbled together the old CDBaby site by himself. It was good.

Then, he heard about Rails, and became infatuated with it. He proceeded to attempt a rolling rewrite of CDBaby's frontend and backend both (the backend is large, because of inter-label and digital distribution stuff) in Rails.

At this time, Derek had no experience with the following things:

* any language other than PHP
* systems integration and interoperability
* Rails
* object-orientation
* the MVC pattern
* managing a development team

Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often.

As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely.

His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet.

No framework saves you from your own inexperience.

Out.
wellwisher | September 23, 2007 01:47 AM 

Yesterday I finished my first week at my new job. Going back to the PHP world is somewhat shocking to see a complete lack standardized coding methods. I spent some time this week getting to know the project I’ll be helping out on for the next several weeks. The code originates from an overseas outsourcing company with absolutely no standards or knowledge of design patterns, or concept of writing DRY code.

I find it difficult sometimes to get the concepts I’ve picked up during Ruby development across to PHP programmers. Since most people self-learn PHP there is a tendency to do a lot of brute force coding, copying and pasting and doing stupid stuff like using template languages when there is know need to use a templates. Because they self learn, modern software engineering philosophies and management techniques that are progressing the state of the art are virtually unheard of by many PHP developers. Let’s explore some of the things PHP developers could be doing to make their lives better, save their employers money and maybe get a raise.

Views Instead of Templates

In the PHP world there is this mysterious draw toward templating using engines like Smarty, Flexy (which I have been guilty of), Blitz or any of the other engines available. I think this draw is the experience of the developer wanting to abstract and separate the presentation layer. It’s a natural progression that comes from experience – the kind of experience you get from PHP’s free style – so free that you often see SQL statements, and HTML markup embedded within the same PHP script.

So why use a template engine in the first place? PHP is a template engine. The only valid reason I have ever found is for applications that allow either designers or end users change the front end presentation layer – and even then I’m skeptical what with the whole existence of CSS…but I can understand the level of flexibility templates allow a designer. A good example that I have used is Shopify use of the Liquid Markup Language which was created for Shopify. Anyway, back to the subject.

If there is no reason for a third party designer to change the presentation layer there is almost no need for a template language, but you see templating in PHP frequently used as a way to force code separation.

So PHP coders pay attention… Forget the template engines unless you really need them they only indirectly force you to do code separation, slow down your application, learn a bunch of additional syntax and limit your ability to present what you want to in PHP. Just chose to do code separation from the design phase of your application. Keep the power of PHP available in your presentation layer views and skip learning a pointless template language.

Testing, Testing, 1. 2. 1. 2.

How do we test in PHP? Write a script, hit the browser and look all over the place to see if what you wrote worked). WRONG Well not really – most PHP developers do just that. No automated unit testing or integration testing, and most have never heard of it. I’ll be the first to admit that when I made the leap from PHP to Ruby I had never heard of unit testing and didn’t incorporate testing until after at least a year of Rails development. I’m also the biggest advocate for automated testing.

People often resist writing automated tests because they can be time intensive at the onset of a project. It’s often a matter of “we don’t have enough time or funds to spend writing tests.” The proponents of this argument are usually the ones in favor of brute force eye ball tests. “Let’s make a change and cross our fingers hoping it doesn’t break anything we’ve already eyeballed.”

Well that just doesn’t make any sense! It’s a business decision that budget managers should understand. Why spend more time eyeballing and crossing your fingers when PHP has unit tests, continuous integration tests and a other great methods. Managers should be asking their developers why they aren’t using PHP’s automated testing facilities!

Data Modeling and Class Design

I do my little turn on the cat walk, yeah on the cat walk… Modeling seems to be an esoteric subject for some PHP developers. In a lot of database schemas I repeatedly see weird table layouts, aggregate data storage and lots of abbreviations. In Ruby on Rails the convention is to model tables based on object usage. We use the Active Record design pattern. PHP developers often think ActiveRecord and Active Record are one and the same – they’re not.

Active Record the design pattern is a description for creating classes that relate to a row in a database, provide static finder methods and implement an object that both provides an interface to data and the methods to store, destroy and modify the data. The pattern is impossible to simply implement in PHP. But that doesn’t mean it can’t be used to the fullest of PHP’s ability or that you can’t implement the next best data design pattern.

Why use abbreviations in database tables? Is it really that convenient to abreviate the hell out of every variable or attribute name? One of the best things you get in Rails is string inflection (huh?). That means we can take a string like “phone_number” and call a method like humanize resulting in a human readable field label, “Phone Number” – using this is a no brainer. It also makes it a lot less tempting to use variable names like “phonum”...but that’s really a no brainer too.

What looks better to the human eye? “phonum” or “phone_number” – you can see where this is going… ”$phonum”, ”$cli_phonum”, ”$client_phonum”, ”$client_phone_number”, ”$client->phone_number”. So if you were working in a team what convention works best, esoteric abbreviations or human readble variable names that any programmer can jump into without a secret decoder ring.

If you’ve got a form full of aggregate information keep it separate. This is an easy one – when you’re on the receiving end of a post why reassemble your information?

HTML

<input type="text" name="client_name" id="client_name" value="Joe Smalltime &amp; Son" />
<input type="text" name="client_email" id="client_email" value="" />
<input type="text" name="client_login" id="client_login" value="" />
...

PHP

$client = array();
$client['name'] = $_POST['client_name'];
$client['email'] = $_POST['client_email'];
$client['login'] = $_POST['client_login'];
...

Or do nothing..

HTML

<input type="text" name="client[name]" id="client_name" value="Fortune 500 Corp." />
<input type="text" name="client[email]" id="client_email" value="" />
<input type="text" name="client[login]" id="client_login" value="" />
...

PHP

$client = $_POST['client'];

Do what you mean, and only that.

Why make things more complex than they need to be? If you mean to take information from the web and save it, do just that. Where should we validate information, every script that needs to accept and save information or in the one place it actually matters? Why validate manually in every script when we can set our validation conditions at the class level then do what we mean? What am I talking about?

if (valid_client_info($_POST['client_info']) {
  save_client_info($_POST['client_info']);
} else {
  throw new Exception("Your client info sucks");
}

Or we could do this…

  $client = new Client($_POST['client']);
  if ($client->save()) {
    $this->render_string("Hazaa!");
  } else {
    throw new Exception("argh!");
  }

Conclusion

PHP developers can learn a lot from Ruby on Rails. You really don’t have to use Ruby to take advantage of modern design techniques but what a lot of people fail to realize about Rails is the fact that most of the conventions weren’t designed just for ruby – Rails is a laundry list of best practices for web development. Some of the best developers in the world are using Rails because of it’s best practices that enable rapid development and get you focused on the business logic not the repetative tasks you face every project.

Again I’m investigating interesting things for the new job I start next week. I just came across Quercus which appears to be a complete implementation of PHP5 in Java. It even includes the ability to import Java classes into PHP. It also provides bytecode caching ala APC for a nice 3-5x speed improvement over plain old mod_php. This is akin to Ruby’s jRuby which provides just about the same feature set. The code looks like it already offers good compatibility but needs more attention…any Sun executives reading? ;-)