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!

This is the first in a short series of tutorials showcasing some of the new features of Cgiapp2. In this tutorial, you will see how easy it is to switch template engines in Cgiapp2-based applications.

A darcs repository browser is now online for the Phly channel.

If you're not familiar with darcs, it's a revision control system, similar to GNU Arch and git; changes are kept as patch sets, and repositories are branched simply by checking them out. This makes darcs repositories very flexible, and incredibly easy to implement. Static binaries are available for most systems, which makes it easy to install on systems to which you have no administrator rights.

A perl CGI script is shipped with darcs, and provides a web-based repository viewer. It utilizes darcs' --xml-output switch to create XML, which is then transformed using XSLT. However, there are some issues with the script; it is somewhat difficult to customize, and makes many assumptions about your system (location of configuration files, repositories, etc.). To make it more flexible, I ported it to PHP, using Cgiapp2 and its XSLT template plugin and Phly_Config.

I have released this PHP darcs repository browser as Phly_Darcs, which contains both a Model and Controller, as well as example XSLT view templates. It is currently in beta as I'm still developing PHPUnit2 tests for some of the model functionality, as well as debating the ability to add write capabilities (to authenticated users only, of course).

Update: fixed links to internal pages to use absolute urls.

After several months of testing and some additional work, I've finally released the first stable version of Cgiapp2.

It is available at both the Cgiapp site as well as via my Phly PEAR channel.

There were a ton of changes while creating the Cgiapp2 branch. From the release notes:

The 2.x series of Cgiapp completes a PHP5 port of Cgiapp2. PHP5 compatibility changes include visibility operators for all properties and methods, declaration of many methods as static and/or final, and the use of exceptions for catching run mode errors. Most notably, though, is the fact that Cgiapp2 is now an abstract class, with one abstract method, setup(); this enforces the fact that you must subclass Cgiapp2 in order to create your application.

New features include:

• Callback hook system. Cgiapp2 is now an observer subject, and has hooks at several locations within the application. Additionally, it provides a method for registering new hooks in your applications. The callback hook system replaces the plugin system introduced in Cgiapp 1.7.0.

• Template engines are now relegated to plugin classes, and should implement the Cgiapp2_Plugin_Template_Interface. Shipped template engines include Smarty, Savant2, Savant3, and XSLT.

• Improved and more extensive error handling, which has been expanded to exceptions as well. Cgiapp2_Exception and Cgiapp2_Error are both observable subjects, with interface classes for implementing observers. This allows the developer to tie into exceptions and errors and perform actions when triggered (Log and Mail observers are implemented for each).

• Cgiapp2_FrontController class. This is a simple front controller that dispatches to public static methods in registered classes. Included is a 'page' controller for handling static pages.

I have included migration notes, for those migrating from the 1.x series of Cgiapp; there is very little that you need to do, but some PHP5 changes necessitate some compatability breakages, and the new callback hook architecture and the ability to separate the template engines into plugins introduced some slight changes as well.

In testing the release, I have been writing some apps that take advantage of some of the new features, and I will be writing some tutorials in the coming weeks.

Last week, I had someone bring to my attention that the SPL's Countable interface was actually first released in PHP 5.1.0… which means I needed to update the PHP dependency on Phly_Hash. I also needed to do so on Phly_Config as it depends on Phly_Hash. I released 1.1.1 versions of each yesterday; the only change in each is the PHP version dependency.

After some discussion with Paul and Mike, I was convinced that 'Struct' was a bad name for Phly_Struct; structs are rarely if ever iterable, and one key feature of Phly_Struct is its iterable nature.

The question is: what to name it? Associative arrays go by a variety of names in different languages. In Perl, they're 'hashes'; Ruby and Javascript, 'collections'; Python, 'dictionaries'. I ruled out Phly_Dictionary immediately, as (a) I don't want it to be confused with online dictionaries, and (b), it's too long. The term 'Collection' also feels too long (although I write things like Cgiapp2_ErrorException_Observer_Interface, so I don't know why length should be such an issue), as well as unfamiliar to many PHP developers. Hash can imply cryptographic algorithms, but, overall, is short and used often enough in PHP circles that it makes sense to me.

So, I've renamed Phly_Struct to Phly_Hash, and updated Phly_Config to use the new package as its dependency. In addition, I've had it implement Countable, so you can do things like:

$idxCount = count($struct);

Go to the channel page for instructions on adding Phly to your PEAR channels list, and grab the new package with pear install -a phly/Phly_Hash, or pear upgrade -a phly/Phly_Config.