php|tek in Chicago was fun as always. It is the best PHP conference I have ever been to, which makes sense, given that it is focused solely on PHP and surrounding technologies. The best thing about the conference is the community feeling in general. You get a real sense that everyone there really cares about PHP and is heavily invested in it, which is good for moving the whole language and ecosystem forward.

I myself gave two talks – one about Stackbox CMS, a new CMS project I have been working on, and one about Apppcelerator Titanium Mobile since I have been working with it a lot lately. The presentations are embedded below.

Cross-Platform Mobile Development with Titanium

Stackbox CMS: Next-Generation Content Management

Having a few well defined extension points force the developer to extend your library the right way instead of hacking your code.

The problem is that this kind of thinking is a slippery slope that kills the spirit of programming. It alienates the more pragmatic developers within communities. Telling other developers that you are going to force them to work with your code in some pre-determined “right way” is an incredibly arrogant statement to make. Instead of letting the codebase grow organically and be modified or extended at will, you handcuff developers and send them a different message. Allow me to re-phrase it using my own words:

I know the right way to use this code and I have thought of all the possible use cases. If you don’t agree, then you have to prove me wrong and wait until I either agree or figure out a better right way for you.

This is the real message developers hear when internal code is private scope or marked with the final keyword – a message that they have arbitrarily limited power and ability to make changes where they need to. But it doesn’t stop there.

When you take the position that all methods should be private unless proven otherwise, you plant a seed of fear in the developers that use your code. Fear that whenever they may have to veer off the beaten path to meet a project requirement they won’t be able to. Fear that they might miss deadlines waiting for the “right way”  to enable the functionality they need. Fear that they might have to modify or hack the actual file or class they need to change the behavior of to achieve the functionality they want within the project deadline because they are not able to extend it.

Using private scope removes the fun from programming and kills the hacking spirit by creating fear through the knowledge that you will not have the ability to make changes anywhere in the codebase you need to when you need to. You are no longer in control of your own code. You were forced to submit to a nanny state mentality by sacrificing your freedoms to modify the code for the promise of future stability and safety. That’s not a fun place to be when you’re on the receiving end, and it’s not a policy I would ever consider enforcing with my own code. I sincerely hope this line of thinking does not proliferate within the PHP community and infect other projects.

Templating

Templating is perhaps the most compelling and creative use of closures that I have found, yet I haven’t seen any people or projects using closures this way. Closures are an excellent way to allow custom formatting for re-useable template widgets, like forms, datagrids, and lists. Re-useable forms and datagrids are pretty common in frameworks, because no one likes the monotony of creating a bunch of HTML forms or tables. They all seem to work great, until you have to change a few things in how they output the input fields or format cell data – then they can get a bit hairy and ugly to work with, and often require inheritance or use some obscure template syntax of their own with tokens that get string replaced and weak-to-no support for basic control structures like loops and if statements. Fabien Potencier published a proof-of-concept for individual field templates in Symfony2. This approach, while much more flexible than string-replaced field tokens, adds quite a bit of overhead because you now have to render one template per input field to produce a complete form. The same end result can now be easily achieved with the use of closures:

1
2
3
4
5
6
7
8
9
10

<?php
$table = new \Alloy\View\Generic\Datagrid('datagrid');
$table->data($this->posts)
    ->column('Post', function($item, $view) { return $item->title; })
    ->column('Status', function($item, $view) { return $item->status; })
    ->column('Date Published', function($item, $view) {
        return ($item->date_published) ? $view->dateFormat($item->date_published) : '(Unpublished)'; 
    });
echo $table;
?>

In this example, our generic “Datagrid” view accepts “$this->posts” as its data source input, and loops over it with a foreach internally. It then implicitly passes two arguments to any closure given that defines column output – “$item” – the current item in the posts collection we provided, and “$view” – the view object itself so helpers and other typical functions can be accessed.

The added benefits for using closures in this context are enormous. There is no additional (and limiting) pseudo-syntax to parse, and no additional item templates to render. The custom content is overridden in-line right where you want it to be (instead of being one-step removed in a separate template), and you can still use the native PHP code you know and love. The provided example is from Cont-xt CMS built using my own Alloy HMVC Framework.

Imagine how powerful and simple something like Zend_Navigation and the resulting navigation view helpers would become with support for closure templates. You would no longer have to rely on a deep hierarchy of nested configuration arrays, custom partial templates, or complex object inter-dependencies to generate page links with your own custom code.

Dynamic Code Extension

Dynamically extending a class and modifying the behavior of a code block with the use of closures is the foundation of a new php 5.3 framework called Lithium. Lithium’s specific approach uses closure chains inside function bodies to allow end-users to modify core functionality without modifying the core files themselves or having to use inheritance.

A more extreme example uses closures to enable dynamic run-time object creation. The idea is in an article titled PHP Object Oriented Programming Reinvented. The entire object and all its functionality is created with closures. The article is a good demonstration of the power of closures, but has little practical use.

One of the more practical (and perhaps controversial) uses I came up with is replacing string configuration values with closures if the return values needs to be dynamic. Here’s an example:

1
2
3
4
5
6
7

<?php
// Set in base config file
$cfg['path_uploads'] = function($cfg) { return "/uploads/" . $cfg['user_id'] . "/"; };
 
// Set dynamically by database value from logged-in user later in your application
$cfg['user_id'] = 74;
?>

This way, the ‘path_uploads’ config value will not have to be changed when the ‘user_id’ config value is. The closure will cause the config value to always be evaluated when called, and will always use the current ‘user_id’ value, so it will never be “out of date”. This, of course, requires you to have a standard way to retrieve config values from named keys, because closures can’t just be automatically converted to a string by themselves, and do have to be called a different way (like functions).

This is the only use that comes with a warning: beware how far down this road you travel. Dynamic code extension provides a lot of flexibility, but comes with the downside of code obfuscation and performance penalties. You are essentially adding class methods and modifying code behavior in places other than the code itself, which can lead to confusion when trying to trace code execution. Stack traces and development toolbars can help here, and using an opcode cache like APC can minimize the performance penalty.

Delayed Execution

Closures are a great tool to use anywhere you need to delay PHP code execution until a later time. A great example of this use is for a job queue system with multiple workers. Using closures, you can execute any arbitrary PHP code you need to without conforming to a specific structure — there is no need to create new classes or functions with set names determined by naming conventions, and no need to put “worker classes” in any specific place in the filesystem. Your worker task can be passed around and executed in parallel at will by the job queue.

Example: PHP Native Job Queue.

Caching

Using closures for caching is a bit of an extension of the delayed execution idea. Consider a cached block of code inside a view template using a closure:

1
2
3
4
5
6
7
8
9

<?php echo $this->cache(function($view) { ?>
    <?php
    // Expensive external HTTP request
    $blogRss = $view->helper('feedReader')->fetch('http://github.com/zendframework/zf2/commits/master.atom');
    $widget = new \MyApp\View\Generic\FeedList('feedlist');
    $widget->feedContent($blogRss, 'atom');
    return $widget;
    ?>
  <?php }, 'github_zf2_commits', 3600); ?>

Using a closure here offers two advantages over the typical ‘beginCache’, ‘…’, ‘endCache’ type calls that are more prevalent in pre-5.3 code. The first benefit is that through the use of a closure, our code block is contained in a variable before it is even executed. This allows us to use a cache backend like Memcache without having to use output buffering at all, saving us a tiny bit of overhead. The second big benefit is that executing our code chunk is entirely optional, without manually checking the cache first. This second benefit could also allow you to disable rendering of certain cached content completely if you need it, without any code changes in your view templates. Heavy-load or traffic spike scenarios come to mind as possible candidates for this functionality. Imagine being able to make a small configuration change to skip certain code blocks like $cache->disable(‘github_zf2_commits’) to serve a “lite” version of your site when you need all the server resources you can get.

Convenience

This may sound like a bit of a cop-out reason, but using closures in some cases really does make things a lot easier, and truly better. Consider the case where you have to use a one-off function to apply some sort of custom filtering logic to an array or collection of objects. With closures, you can just specify the logic in-place right where you need it instead of having to create a new function for the job in a separate location and having to figure out where to put it in your application, and then how to call it. It produces the same result in fewer lines of code with no side-effects (like having to make a global function).

1
2
3
4
5
6
7
8
9
10
11
12

// Collection of entities
$objCollection = array(
    new Entity(),
    new Entity(),
    new EntityRelation(),
    new OtherRandomJunk()
);
 
// Get only Entity objects
$entitiesOnly = array_filter($objCollection, function($val) {
    return ($val instanceof Entity);
});

In the above example, it may not make sense to create a separate named or global function for this collection filtering, because it may only ever be used in one place. If this is the case, it makes sense to use a closure, and makes the code more concise and readable because everything is all in one place.

Summary

Closures are a game-changer for PHP all by themselves. Throw namespaces and late static binding in the mix as well, and PHP 5.3 reaches a level of power and dynamic flexibility that PHP has never been able to reach before. If you have been sitting on the sidelines, stuck in PHP 5.2 land – you desperately need to upgrade. This is the future of PHP.

1
2
3
4
5
6
7
8
9
10
11
12

class BobUser
{
	public $name = 'bob';
	public $publicFlag = true;
	protected $internalFlag = true;
 
	public function getFields()
	{
		$getFields = create_function('$obj', 'return get_object_vars($obj);');
		return $getFields($this); // Returns only 'name' and 'publicFlag'
	}
}

We can also do this the PHP 5.3 way with a much nicer-looking closure:

1
2
3
4
5
6
7
8
9

class BobUser
{
	// ...
	public function getFields()
	{
		$getFields = function($obj) { return get_object_vars($obj); };
		return $getFields($this);
	}
}

“… So a blogging platform won the content management system award? How sad is that?”

My knee-jerk “how sad is that?” reaction comes not because I don’t think WordPress is worthy, but because of what it implies about the state of other open source CMS projects. The reaction comes from the fact that a blogging platform is kicking your CMS’s ass in its own category.

WordPress bridges both the blogging and CMS categories due to the ‘Pages’ feature, and is extremely useful for managing a blog-focused website. Mostly. That is, until you want to do something that a CMS should be good at, like have an event calendar, custom form, photo gallery, etc. – which is why WordPress is not focused on being a CMS in the first place. Yet it does such a better job at the basic things like creating new pages, tagging, categorizing, comments, and having custom SEO-friendly URLs out of the box that it edged out other software projects like Drupal MODx and Joomla! SilverStripe whose sole focus is content management. Sad indeed.

The fact that I can go through literally hundreds of open source content management systems and still end up settling on WordPress because I know it’s the only one that won’t totally confuse my client is what’s sad. Usability and ease of use matter. They are the number one feature to the end user. If you’re involved in a CMS project, you need to do better. A lot better. Right now.

UPDATE: Some commenters have pointed out that the awards website has a specific rule:

Previous winners of the Overall category are not eligible for the Overall category in 2009. Previous winners compete amongst one another in a separate Hall of Fame category designed specifically for them.

Since both Drupal and Joomla! have won the award previously and thus were automatically excluded, I replaced their names with the CMS projects that were 2nd and 3rd behind WordPress (MODx and SilverStripe) instead. The premise of the post still holds true.

Object Oriented Apologetics

In defense of object-oriented programming – How and why you should use object oriented programming for your next project.This talk is for PHP programmers who are just learning about object oriented code, who cling to old excuses(“object oriented code is slower”), or who are otherwise unconvinced of its usefulness. Concrete real-world examples of commonscenarios and challenges that programmers face will be presented, and how taking an object oriented approach is better than a proceduralone in most cases. Copious code examples in both object oriented and procedural approaches will be provided throughout, and thedifferences and benefits of the object oriented approach will be explained.

Download Object Oriented Apologetics on SlideShare

If you were in the talk, please rate it on Joind.in

The CodeWorks Experience

All in all, the CodeWorks roadshow Dallas stop was much smaller than I expected. There were about 20 people in the talk I gave. I suppose it was both a good a bad thing. On one hand, I had a lot of fun connecting with the other speakers and attendees on a more personal level than I would have had the opportunity to do otherwise. I met a lot of new people in the PHP community that I will probably stay connected with on some level, even if it is just Twitter and IRC. We had a lot of fun the night before the presentation day eating together and hanging out.

On the other hand, I know that as a business, the relatively low attendance levels coupled with the high travel expenses could mean that something like this can’t happen again, which is a shame. This was one of the best efforts I have seen in a while to really lower the price of the conference for attendees by bringing the speakers directly to their cities or at least ones that are close by. Going to ZendCon, for instance, could easily cost up to $2,500 for the whole trip with airfare, hotel stays, and food, if not more.

The bottom line here is that CodeWorks was a good conference that offered a great value for your money. I had a great time meeting and connecting with new people and finally meeting people in real life that I had been communicating with for years. I learned some new things and finally got the kick in the pants I needed to jump into Test Driven Development, thanks to Jason Sweat’s TDD tutorial and hand-holding.

Now I’m just looking forward to php|tek in May 2010.

I was able to arrive at this solution by combining the one-line comment with the comment block in a way that takes advantage of the rules the different types of comments have to follow.

The One-Line Comment

One-line comment rules dictate that everything after the comment characters must be ignored for the rest of that line. They look like this:

1
2
3
4
5

// My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";

The Block Comment

Block comment rules dictate that once the beginning characters are started, everything up until the ending characters is ignored. They look like this:

1
2
3
4
5
6

/* My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";
*/

Combining The Two: The Best of Both Worlds

Using both those comment style rules, we can combine the two comment styles in a way that will allow us to comment and un-comment a block of code with by adding or deleting a single character. The trick is to make both the beginning and ending lines both single-line AND block style comments, like so:

1
2
3
4
5
6

//* My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";
// */

In the above example, you notice that the code will still run – it’s not commented out because the first line is following the rules of the single-line comment – ignoring the block comment declaration on the same line. By removing the first backslash at the beginning of the block, we can comment out the entire code block by enabling the block comment style instead of the single-line style. The last single-comment line is ignored because the block comment rules ignore everything up until the end block comment declaration at the end of the line:

1
2
3
4
5
6

/* My code below
$someVar = array("foo", "bar", "blah");
echo "<code>";
print_r($someVar);
echo "</code>";
// */

So a single character – a backslash at the very beginning of the block declaration can now comment or un-comment the entire block by switching the comment rules back and forth between single-line and block style. The code examples provided are in PHP, but this trick will work with any language that supports both single-line and block style comments.

I will be presenting my talk on Building a Data Mapper with PHP5 and the Standard PHP Library, followed by a discussion on ORMs and whatever else comes up. The presentation will cover all the thought processes, goals, theories, and actual code that goes into building an ORM (or really any other larger project that requires more advance planning). The project that was the basis of this presentation is phpDataMapper – an open-source PHP5 data mapper ORM layer that I started in the fall of 2008. It now powers the model layer of InvoiceMore, a live web application I launched in March 2009.

This is a presentation I have given before at Tulsa TechFest.

Watch the video of this presentation online

The project itself hasn’t changed too much recently, but I decided to finally formally introduce this project because I finally got some time to write some decent documentation on how to use PHP DataMapper in in your own application.  Head on over to the PHP DataMapper page to check it out, or just get right into the good stuff with the Getting Started tutorial or the Usage – Finders example.

More updates and documentation will be coming soon.  If you’re interested in learning more about the project or contributing, please join the Google Group.

UPDATE: Links have been updated to the new home for the project – phpdatamapper.com

Any PHP developer who’s been in the community for a while has heard preposterous claims like “use single quotes (‘) for strings instead of double quotes (“), because it’s faster”.  That is, faster over the 100,000 or so iterations it took the tester to generate a number sufficiently large enough to justify the claim, with a particular version of PHP, in a particular development environment in which it was tested.

These articles are then followed up with other posts that only serve to perpetuate and solidify the original and invalid performance claims.  Articles like these are like a plague to the PHP community, spreading around and steering novice developers in the wrong direction, concerning them with the wrong things.  Chris Vincent recently released PHPBench.com – a website that benchmarks chunks of related PHP code against each other to compare the speeds.  His goal was just a simple discovery of what code is actually fastest, and although it does yield a few interesting results, I have to wonder if it even matters.  If the tests prove anything at all, it’s that the specific syntax you choose doesn’t matter.  Why? Because it shows that newer PHP versions (he runs it on PHP 5.2+ where most of the previous articles were based on PHP 4.x) have been corrected and optimized to fix any performance discrepencies that there may have been in the past.  In the “double (“) vs. single (‘) quotes” test, Chris concludes:

“In today’s versions of PHP it looks like this argument has been satisfied on both sides of the line. Lets all join together in harmony in this one!”

Similarly, the differences in the “echo vs. print” and “for vs. while” tests are so close in speed (and again remember, this is over 1,000 iterations) that you’re just better off using which ever one is a better fit the for job you’re doing.

Optimize for Performance AFTER You Code

The true way to optimize your code to run faster is to worry about optimization after you code.  This is, of course, because the real bottlenecks in your code can only be identified after the code is already written.  When put into simplified steps, the development and optimization process would then look something like this:

1. Write code
2. Run it for a while until you (or your users) start to experience noticeable slowdowns or you begin to reach the capacity of the hardware you’re running on
3. Profile your code to identify where the real bottlenecks are
4. Re-factor and make adjustments to your code to fix those bottlenecks
5. Go back to step 2

Now that’s not to say that performance concerns should be completely discarded when writing your code – experienced developers will automatically make code and design decisions based on their experience that will have a beneficial impact on performance while they’re writing the code.  This just means that it should never be your primary focus when developing your application, and that you should never be overly concerned about it until it’s actually a problem.

The Impact on Your Code

So the real difference here is that when you listen to benchmarks and have performance as a high priority immediately, you end up making bad design decisions and waste time worrying and doing things that may not even affect performance at all in the end.  So instead, focus on your users, and do what you can to make their lives easier, no matter what you think ahead of time the performance impact may be.  If it becomes a problem in the future, you can turn your focus to the specific problem and fix your code where the problems actually are.

Conclusion

Put aside your worries about performance and just build it.  Would you rather have 10,000 users using a website with performance problems that you have to fix or 100 users using a website that is half as useful but runs 10% faster because you spent all your time focusing on performance “tips” when they may not even have an impact on performance at all?