Yesterday, Mike and I presented our session "Best Practices of PHP Development" at this year's Zend Conference. It was a marathon three hour tutorial first thing in the morning, and we had an incredible turnout, with some fairly enthusiastic people in the audience.

Download the slides slides for PHP Best Practices.

As Mike already noted, he and I are presenting a session on "Best Practices of PHP Development" at this year's Zend Conference and Expo. It has been my fortunate experience to work with Mike in the past, and, as he noted, we had so much fun presenting during last year's conference, we thought we'd do it again.

The session is a pre-conference tutorial session, running for 3 hours on Monday morning, 30 October 2006. Currently, we're shaping up the session into the following subject areas:

• Programming Practices

  • Coding Standards
  • Test Driven Development and Unit Testing
  • Project Documentation

• Tools and Processes

  • Software Configuration Management (SCM)
  • Collaboration tips and tools
  • Deployment

Emphasis is going to be on working in teams, particularly those operating in geographically diverse areas. With roughly 30 minute blocks per topic, we've certainly got plenty to cover!

If you're coming to the conference, we look forward to seeing you in our session!

As noted previously by myself and Davey, I've been working on Zend_XmlRpc_Server for some months now. In the past couple weeks, I've refactored it to push the class/function reflection into Zend_Server_Reflection, and, in doing so, noted that there were further areas for refactoring into additional helper classes. Currently, it now has classes for the Request, Response, and Faults, and all actual XML wrangling is done in those, making the server basically XML-agnostic.

As Davey Shafik noted recently, he and I have been working together on some web services for the Zend Framework. In doing so, I've become very familiar with PHP 5's Reflection API, and am coming to love it.

When I first read about the Reflection API in a pre-PHP 5 changelog, my initial reaction was, "who cares?" I simply failed to see how it was a useful addition to the language. Having done some projects recently that needed to know something about the classes they are using, I now understand when and how it can be used. It shines when you need to work with classes that may not be defined when you write your code — any code that dispatches to other classes, basically.

I may work at Zend, but I've never been a fan of IDEs. They simply don't suit my programming style. I can usually keep track of file locations in my head pretty easily, and what I really need is a blank slate on which I can write, and one that doesn't consume resource that can better be used running web servers and other programs. Syntax highlighting, good indentation — these are important, but you can get these from good, minimal text editors very easily. Vim is my editor of choice.

I will admit, though, that one area where I have had IDE-envy is the area of code completion. I often find myself doing quick lookups to php.net or perldoc to determine the order of arguments to a function or method call, or checking for the expected return value. Most of the time, this doesn't take much time, however, so I just live with it.

Today, however, cruising through the blogosphere, I came across an article showcasing some new features of Vim 7.0, and discovered Vim 7's code completion.

Basically, while in insert mode, you can type <C-x> <C-o> to have vim attempt to autocomplete the current keyword. If more than one possibility exists, it shows a dropdown, and you can use your arrow keys to highlight the keyword that you wish to use.

But it gets better! Not only does it do this kind of autocompletion, but it also opens a small 'scratch preview' pane showing the function/method signature — i.e., the expected arguments and return value!

I thought I had little need for IDEs before… now I have even less! Bram and the rest of the Vim team, my hat's off to you for more fine work!

In response to Scott Johnson's request for advice on variable functions, I decided to run some benchmarks.

<rant>Writing benchmarks is easy. Yet I see a lot of blog entries and mailing list postings asking, "Which is faster?" My first thought is always, "Why didn't they test and find out?" If I ever have a question about how something will work, I open up a temporary file, start coding, and run the code. It's the easiest way to learn. Also, it teaches you to break things into manageable, testable chunks, and this code often forms the basis for a unit test later.</rant>

Back to benchmarking. Scott asks, "Is there a real difference between call_user_func versus call_user_func_array and the variable function syntax i.e. $function_name()?"

The short answer: absolutely. The long answer? Read on.

I upgraded Serendipity today, due to the recent announcement of the 1.0 release, as well as to combat some rampant issues with trackback spam.

I've been very happy with Serendipity so far; it just runs, and the default install gives just what you need to get a blog up and running, and nothing more; any extra functionality comes via plugins which you, the blogger, get to decide upon.

Additionally, it's incredibly easy to upgrade. Unpack the tarball, rsync it over your existing install (I rsync it, because I don't use 'serendipity' as my directory name), visit the admin, boom, you're done. I've upgraded several times, and never lost data, nor configuration settings.

My primary reason for the upgrade was, as noted earlier, to combat trackback spam. As of this morning, I had 15,000 pending trackbacks, none of which appeared to be valid (if any of them were, and you're not seeing yours, I'm very sorry; I deleted them en masse). These had accumulated in less than a month — that's an average of about one every 3 minutes.

Since upgrading, and using the Akismet service, I've received not a single spam trackback. Needless to say, I'm happy I performed the upgrade!

If you're a Serendipity user, and haven't upgraded to 1.0.0 yet (or one of it's reportedly very stable release candidates), do it today — you have nothing to lose, and a lot of lost time to gain!

This is the second in a series of Cgiapp2 Tutorials. In this tutorial, I cover creating what I call 'Pluggable Applications', applications that can be distributed and customized to work with other sites.

I ran across a blog post entitled "Why the Light Has Gone Out on LAMP" earlier today, and felt compelled to respond.

First, a rant: somehow, this article got posted on Slashdot. I've never heard of the guy who posted it, and some quick googling shows that he's a pythoner. He's simply fueling the language wars, and the slashdot post opened up a huge debate that need not have occurred. I think it was irresponsible of the Slashdot editors to post it.

In the post, the author makes an analogy of using PHP + MySQL as the equivalent of using BASIC, and then uses a quote that claims BASIC "has become the leading cause of brain-damage in proto-hackers."

I'm sorry, but using a language doesn't cause brain damage. And there are many levels to programming. And using Python, Ruby, C, C++, Java, etc., does not automatically make you a better programmer than those using one of "those other languages". You can write crap code in any language. You can also write great code in just about any language.

Programming takes practice; programming well takes a lot of practice. You get better at it by learning more about programming practices, and applying them to your language. Part of programming is also learning when a particular language is suited to a task, and when it isn't. Python works for the web, but it's not particularly suited to it; similarly, you can write web servers in PHP, but that doesn't mean you should.

Stop the language wars already! Stop writing incendiary pieces about a language you don't use regularly or never gained particular proficiency in, and code already!