Yesterday I gave a talk at the php|tek 2009 Conference about the ORM in the PHP World. In the first part of the presentation, I’m focusing on what an ORM is, what would make a great ORM, design patters for ORM and tying ORM systems to the PHP world in terms of philosophy, uses and approaches. The second part of the presentation talks about a list of ORMs that I have seen and their pros and cons.

The ORMs I mention:

• Propel
• Doctrine
• dOrm
• Zend Framework – specifically the proposed Zend_Db_Mapper
• Xyster Framework
• CodeIgniter
• ez components’s Persistent Object and Persistent Mapping
• symfony
• PHPLinq
• Solar’s Solar_Sql_Model
• Outlet PHP ORM
• CoughPHP
• ORMer

I plan on talking about each of these ORMs in detail in separate blog posts, so stay tuned!

I think by now everyone’s familiar with the phrase:

“Premature optimization is the root of all evil.”

In my day-to-day job, I worry a lot about writing high-performance applications, especially in the way applications manage and retrieve data. There is a huge difference between designing your application to be optimized for a specific purpose and premature optimization. It’s one thing to worry whether echo or print is faster (who cares, really?) – but it’s another to design an application to tolerate some slowness in low-traffic parts but gaining ultra fast response time on the first access to the application. For example, viewing your photo album may take a while but seeing the homepage is pretty freakin’ fast!

In a recent post, Sebastian Bergmann points out that you should not micro-optimize (in reference to a PHP micro-optimization tricks post by Alex Netkachov). I agree wholeheartedly. It’s a nice list and definitely something to keep in mind, but it should be just a small component of your developer bag of tricks! Before you can optimize, you have to design well first. Proper design leads to potential for great optimization. And to design well, you have to really understand the problem you’re trying to solve. Sebastian links to slides by Ilia Alshanetky from PHP Quebec 2009 on Common Optimization Mistakes. Ilia also points out that it’s important to understand before you start fixing:

Solve the business case before optimizing the solution.

For PHP Advent, I wrote an article Optimize This!, which talks about how to optimize an existing application. The most important part to focus on is understand what the application is doing and then figuring out where you’ll have most impact. Sure, you can use echo over print (or print over echo, once again, who cares?) to get that 0.0001% performance boost, but if you’re doing 140 live SQL queries on your homepage, your application will still have 3 minute response time and with more users, the performance will continue to degrade until the application becomes unusable.

Modularizing code (aka “Object-Oriented Programming”) makes it easy to focus on problem areas in an existing application. Designing well doesn’t always mean designing for high performance. Instead, it means designing for flexibility and atomicity – you want to be able to easily change things without huge impact on the overall system. So before you go an optimize, take a step back and think about what your application is doing and what it’s supposed to do. Go write on the white board – diagrams prove very useful in figuring out flows and functionality! Go chat in #phpc channel on irc.freenode.net – the PHP community will help (with a little bit of playful making fun of, but we’ll help). Just don’t go changing all your methods to static methods unless you’re really sure it’s the right thing to do!

The error log is a standard development support tool. It will help you find problems with your application. When developing, I take extra care to make sure that the error log is clean – this includes warnings and notices as well. When your application gets deployed, you can then depend on the error logs to accurately report any issues.
You’d be surprised how many systems I encountered with warnings and notices wildly scrolling by as developers say “oh, just ignore those”. What? I’m kind of a jerk, so I’ll yell at people about it. Actually, I’m a jerk enough to go way out of my way to have ways to yell at people about their poor code practices. Things like “it works on my machine!” are super annoying, srsly. But going along with the logging of your application, I really love to be able to see how the underlying database access performs in the application. This is where we can have a philosophical discussion about the difference between an error and a bug, but long story short, a query that performs poorly because you forgot something obvious like an index is almost an error.
On a recent project, my coworker Matt Purdon wrote a pretty awesome debug console that leverages FirePHP support in Zend Framework to log a lot of information about what the application is doing directly to the Firebug console. Take a look at his implementation here (this is the most important link you’ll click on in this blog post).
The project we used it was structured in a way that separates server-side developers (any PHP and database stuff) and client-side developers (any JavaScript magic and HTML). We’ve used the console to help track which ZF controller actions are called (and hence, which views are rendered), which drastically smoothed out the process of working together between the two teams. In addition, this console also tracks:

• all variables stored in session
• memcached usage information
• all queries that are executed on the request – including their explain plans!

The beauty about the session, memcached and query tracking together is that we can easily say whether we’re correctly caching results that could/should be cached and whether the results are or need to be stored in session. For the queries that are not cached, we can see the entire explain plan and how long it took for the query to run. This is great because you don’t have to extract the queries outside of your code and run them outside of the application, never being really sure whether that’s how the application will use them.
As a result, we’ve got a lot more accountability across the development team. In addition to still paying attention to basic things like clean error logs, all developers now have a tool that does not allow them to make simple mistakes (like queries in loops! good God!) It’s really easy to conduct code reviews as well. And if you’re the type of person who always runs “svn blame” instead of “svn praise” (both aliases for “svn annotate”), you will now have a lot of material for, erghm, discussion among your fellow developers.

Slides for Keeping Your Database and PHP in Sync from php|tek 2008.
For those of you interested whether I’m writing this tool to release, check out dbMorph on SourceForge.