Cloud computing is reaching a level of maturity in the technology market as a whole, finally finding its place and purpose and dropping the “silver bullet” tag. This seems to reflect on the language as well and many sessions revolved around using the cloud to complement projects and on how to take advantage of cloud aspects in a PHP architecture, as well as the many cloud offerings available.

Another topic that kept us all busy was Mobile development, which following the incredible rise of the smartphones and the various systems like iOS, Android and WP7 was also present in multiple tags teaching how to architect your app and create solutions that would work for all smartphone users out there.

I was very surprised this year to see a the clear presence of Applications in the event. WordPress, Drupal and sites like joind.in made their presence in various aspects, ranging from talks, to coding sessions and especially to representatives who took their time to talk to the speakers and attendees.

APIs and integration with external tools was also a hot topic. Many sessions described the many tools that can be used to improve your application, like queues, protocols, services and so many more, also how to develop api into your code so that your application can also be used as an external tool in another project.

One topic that i would love to see more and more was also present: Soft skills. This is a very important area to be explored by the community in general, some conferences like DayCamp 4 Developers already do a great job of covering them but they also grow in various others. These skills or just plain recommendations are fundamental to new and old developers so they can find new paths and grow in their own careers as they do it.

I must also reserve space for the Hack-a-thon which was a complete surprise and success this year, seeing somewhere around 90 developers hacking into the night or just plain learning from each other was quite a pleasing experience. I myself had a great time explaining the importance and the first steps needed to develop PHPT tests to cover PHP’s source code, its not about how much work is done in these events, but its about planting that very important seed that will keep growing after the event, and I was very glad to see so many reach that stage during the event.

Congratulations to the organizers and to all the speakers for delivering incredible content and for taking all developers under their wing to teach and interact. I had a great time also speaking to everyone about Windows Azure and architecting for the cloud, and I hope everyone at the session had a great time learning, even tough my voice decided to play a hoax on me and make me sound like a game of “fill in the blanks”. If you were at the session I would love to hear your feedback, please do it over at joind.in, also you may want to see the slides, so please go ahead and see them here.

This is probably the most common argument against template engines. People often say “but PHP IS a template engine”. Proponents of template engines will then counter argue that the syntax is simpler, but in some cases this is just not true…

We use Smarty in one of our products and in retrospect, we would most likely not have chosen to use it if we had to do it all again. However, based on our requirements and design decisions at the time, it was probably the right choice for then. When we started out, we opted for a MVC architecture where controllers pull data from models and push the data as arrays to the view. The advantage of this approach is that it keeps the templates simple because you’re only ever printing the contents of variables and occasionally looping over a dataset.

As our product evolved and became more complicated, this process became tedious and inefficient. Objects had to be converted to arrays and passed to the view. Sometimes this included a hierarchy of child objects. Then we started implementing lazy loading and iterators, the benefit of which quickly evaporated when we converted all of our objects to arrays.

We decided to instead pass either the model objects to the view or to use view helpers. The view then calls methods on the model or loops over the iterator, preserving the original objects and any lazy loading. All was well again, but of course the views started getting more and more complicated. To refer back to the argument, our templates have now become as complicated as embedded PHP code in HTML would have been. Add of course the additional overhead of the template engine and the cost of learning yet another language and suddenly a template engine doesn’t make an awful lot of sense anymore.

The problem is that requirements, design decisions and technologies all shift and evolve over time. It is not possible to predict where your product will be in 2 years, 5 years or even a few months from now. As software engineers, we try to accommodate change as much as possible by building safeguards into our code. However, at the end of the day, we cannot predict the future so we have to make peace with the fact that continuous re-factoring is as much a fact of life as change itself.

The sessions catered for all levels of developers, from basic introductions to advanced and incredibly engaging workshops. Sessions that stood out for me included anti-gaming techniques, in depth looks at the PHP Core, scaling, new technologies like git and xmpp, amongst others.

php|tek also provided a great opportunity for networking. From my personal experience (being a veteran PHP developer of over 10 years) this aspect of a conference can often be more important then the actual sessions. For a seasoned developer many sessions do not dwell deeply enough on advanced topics, serving more as a point of study initiation then as a full injection of knowledge. However the opportunity to meet developers of the very technologies you employ on a day to day basis enables far greater learnings. Simply because during these opportunities you can address your problems – be it by talking to the creator of the tool, or by talking to the developers of renown websites – during lunch, in the hallway or even during after-event drinks.

Let’s take for example the opportunity of chatting with Sebastian Bergmann, creator of PHPUnit. Being able to discuss and resolve issues you have while implementing tests in your application, learning from him how you can automate your environment and implement more QA processes. Or engaging with Matthew Weier O’Phinney, lead of the Zend Framework project to learn how to participate in bug hunting – solving a bug you have found right there on the spot.

Imagine how much you can learn from talking with someone like Eli White, former developer of Digg, getting scaling tips tailored to your scenario directly from someone who has had the opportunity to deal with high traffic and site availability. Or chatting to people like Lorna Jane Mitchell and Michelangelo van Dam – people who have built their careers on contributing to the community. Leaders like these have helped developers to better qualifications and consequently projected their own names into the halls of fame of the ecosystem, opening doors to new opportunities and places. Career advice from such people would prove to be a turning point in any developers life.

All of this is possible and very welcome during the week that everyone is gathered at php|tek. In fact, even before the conference  started I was already  taking advantage of the great minds around me! Having arrived a couple days before the event and still having work to catch up on (for the official release of my latest project Share My Map), I decided to head down to the lobby to code. To my surprise many of the speakers were there doing the same thing! So I had the opportunity of coding, surrounded by many of the creators of the tools I was using. Needless to say this was amazing – I was able to instantly get opinions on what I was working on – from world-leading experts all very eager to show me alternatives to the code I was writing and provide explanations to the up or downsides of the code in question.

The networking aspect of a coder’s career are often overlooked but  in my opinion this is a vital part of a successful professional life. Your network can make a difference in many different stages of you career and industry events like php|tek are important opportunities to meet and engage with industry leaders. I certainly made the most of my time at php|tek – let me know what your best moments were…

Let me give you a glimpse of what the event tries to accomplish and tell you what came out of it in 2009. MSWDS is all about communication. It is a yearly event that allows Microsoft to get in touch with key players in the PHP community and interact with them on various levels. This means they get to ask us questions, and we rant and ask them questions. It is a an effective way of getting Microsoft and PHP to do better business together, which in turn means getting better tools and better performing PHP applications on Microsoft platforms. Both sides get to know more about how the other operates.

Over 3 days Microsoft and the PHP community shared notes, discussed various products and opinions and shared quite a few beers and dinners at the Redmond Commons Campus.

Microsoft has been very active in the PHP area and even though this is often received with skepticism by the overall community their actions are generating a lot of benefits for the PHP community specifically and Windows users in general. You cannot be right all the time, so Microsoft is still making some mistakes, but it is worth looking at some of what they shared with us. The final day of the conference was held under a non-disclosure agreement and is therefore not included here.

One of the highlights of the event was a project led by Garrett Serrack describing the process and plans for making PHP and associated libraries easier to compile from source on Windows – a project that could give Windows a push as a viable platform for PHP, since custom PHP compilations are a big part of PHP sites. Also very interesting were the news of WebPI and IIS. IIS is working on being a centralized dashboard for system developers and administrators and new tools like the SEO toolkit are laying down a new track for innovation. The road ahead for this is still long, but Microsoft got a lot of feedback on the kind of deploy and maintenance oriented services we developers would like to see such as imporvements to WinCache to offer more features and make it share the spotlight with APC.

The WebPI project made life for PHP application users a breeze – its simplicity and the application gallery makes it very simple to install a complete web platform and get a site up and running. The same is not true for developers. Solutions were gathered to address developer needs – amongst these are multiple side-by-side versions of PHP and other applications, automated testing and closed cycle solutions that can contribute back to our applications as well as make our life deploying and testing before releases much easier on this platform.

During our airing of grievances many topics came up which Microsoft really needs to address. The long lead time to new projects and solutions and all the bureaucratic red tape that needs to be cut was the starting point and showed Microsoft they are the ones slowing themselves down. We also highlighted the areas of the world that need more attention from Microsoft evangelists. Recurring topics such as drivers for SQL Server and better developer tools for IE7 and IE8 came up as well.

One matter that generated heated arguments was the Codeplex Foundation. The discussion was triggered by ill-timed and not unplanned comments of an “info-mercial like” nature. Unfortunately Microsoft is still a huge corporation and parts of it still does not understand that the developer community does not want marketing pitches. The message hit home and some sessions reverted from that format, but the Codeplex idea was still not palatable tomost of the people present. The topic was later brought up in a round-table discussion and disagreements were addressed, showing that Microsoft is willing to correct some mistakes.

Some sessions had .NET solutions at their heart and were not very effective in communication, some were interesting enough to generate in us the desire to copy them, but in my opinion these were not really in their right place for the objective of this event. New technologies such as PowerShell, Azure and Silverlight got lots of attention and showed some in the room that these could be much more useful than they thought it could be.

Silverlight triggered further discussion with its use in Bing Maps – the latter is now live with very striking visual effects. Microsoft’s skill for naming projects was criticised many times especially after we figured out that the “ASP.NET Ajax Toolkit” was an ajax library that had nothing to do with ASP.NET. This was dully noted by MS for future naming.

Microsoft also had an opportunity to listen to the main players in the PHP community about the community itself, Ramsey went over some concepts of user groups and I talked about the new organization of user groups in Brazil (simple slides). We also had sessions by Marco and Keith on uncons and community participation, as well as a few sessions on tools and frameworks/closed apps.

One of the sessions explained how we can get in touch with Microsoft and gave us some insight on the internal structure and roles of all Microsoft related posts. This session was great and also opened the floor to questions from both sides.

The end result of the summit was very positive, even though we may only start seeing concrete results in a few months or even a year. The important message i got out of the conference is that Microsoft is working hard on matching Linux as a viable deploy platform and development platform, but more than that they are looking to go one better and innovate. Investing in professionals that develop PHP and its related libraries is also a way that Microsoft can help PHP to be even more viable on Windows. I guess it is becoming more viable and you should give it a try.

I look forward to some of the new tools and features of current products that were showcased in open and closed sessions – I believe Microsoft has a chance of doing great things for the PHP community.

For the team that organised MSWDS all I can say is that you did more then an awesome job: the hotel was great, social events were a great opportunity to get into more detailed talks about the day’s topics. The whole event went down without a glitch – thank you very much for all the hard work.

Taking the organizational reigns this time around, Eli White takes over from Cal Evans who recently moved from Zend to iBuildings. Organization was mostly smooth, with a few minor hiccups – day 1 had a serious lack of power supply, leaving most attendees with dying laptops before lunch. Compounding the problem, no notepads or pens were provided on registration. Attendees who had registered early and received free netbooks reported that the netbooks came with European plugs instead of US ones. However, most of these issues were sorted out by day 2.

The speakers at this year’s ZendCon included some familiar stalwarts – Sebastian Bergmann was back and presented on topics including testing, quality assurance and continuous integration. Accompanying him, was Stefan Priebsch and Arne Blankerts, who together with Sebastian Bergmann makes up the newly formed PHP consulting company, thePHP.cc. Cal Evans was present in the capacity as a speaker and delivered a good presentation on design patterns. Of course,  Elizabeth Marie Smith was back and presented on PHP for the desktop using php GTk as well as a talk on SPL

Of all the speakers, two that stood out was Ilia Alshanetsky and Stefan Priebsch. I attended two of Ilia sessions, the first about premature optimization and the second on popular caching tools, APC and Memcache. His rapid delivery style and excellent knowledge crammed an almost overwhelming amount of content into a single one hour slot. Stefan Priebsch joined in on a code review tutorial session with Sebastian Bergmann and Arne Blankerts, but it was only when he presented on OOP best practices when he came into his own. Stefan is an engaging speaker and his OOP knowledge demands a lot of respect.

As usual, Twitter and the ZendCon IRC channel was abuzz with attendees tweeting during the conference and was a great way to keep a finger on the conference’s pulse.

The conference, however, wasn’t without negatives – drinks (soft drinks and coffee) were only served after every 2 talks and physically removed after the break, even though these weren’t refrigerated to begin with. In some instances, I had to leave the conference venue to purchase my own drinks.

This year there was no party or any afterhours activities arranged by the conference or sponsors other than the usual reception – this year sponsored by Adobe.

Regarding the format of the conference, I do feel that there are too many talks and the talks are too short – it is simply not possible (unless your name is Ilia Alshanetsky) to fit any meaningful amount of information into a one hour slot , especially the more advanced topics (which are of course the more interesting ones).

ZendCon 09 ended with a framework shootout – a representative of each of the more popular PHP frameworks were invited to appear in a panel discussion and the audience grilled them with questions. Of course, to liven things up, each panel member was provided with a toy gun. Although not particularly useful, it was highly entertaining and a great way to end the conference with.

For a list of conference speakers, talks, ratings and slides of this year’s ZendCon, check out the ZendCon Joind.in page.

Wouldn’t it be nice if you could live life just by applying a foreach to each year and live day by day? Ok, that was an awful joke, but using iterators does make life a lot easier and it makes for cleaner code. SPL’s iterator classes are really awesome and helpful – they replace multiple lines of code and a handful functions with a simple new. This and a foreach can really help cleaning up code. Admittedly there is an argument that this might make the code less legible to “beginner”programmers or programmers that are not familiar with iterators and such, but hey, if you can’t understand it, read this post and learn it.

In this article i want to go over some of SPL’s Directory Iteration options, following up with more details on the code i posted in the original SPL article. Let’s dive into the infinity of iterators and iterate over them, showing how they “go together”and where to get them to solve things for you.

Native in SPL

Native SPL classes have been converted to C, so they perform much faster and are available in any PHP installation, especially since in PHP 5.3 you cannot disable SPL anymore.

DirectoryIterator (doc)

This is a simple iterator because it is not recursive (so you don’t end up as dizzy as we did after the “Iteratah drinking game” at Tek’09). It basically replaces the functionality of the scandir function, but gives you a few more advantages along the way. You can pass it the directory you wish to iterate and it will return an object that you can foreach over as if it were an array. This is a simple task that can be done using scandir as well, so let’s compare advantages, starting with some code:

<php

echo '- Iterate diretory using scandir' . PHP_EOL;
echo '- Avoid DOT directories' . PHP_EOL;
echo '- Show full path' . PHP_EOL;
$dir = 'samples' . DIRECTORY_SEPARATOR . 'sampledirtree';
$files = scandir( $dir );
foreach($files as $file){
    if ($file != '.' || $file != '..'){
        echo $dir . DIRECTORY_SEPARATOR . $file . PHP_EOL;
    }
}
?>

And same thing with DirectoryIterator

<php

echo '- Iterate directory using DirectoryIterator' . PHP_EOL;
echo '- Avoid DOT directories' . PHP_EOL;
echo '- Show full path' . PHP_EOL;
$files = new DirectoryIterator('samples' . DIRECTORY_SEPARATOR . 'sampledirtree');
foreach($files as $file){
    if (!$file->isDot()){
        echo $file->getRealPath() . PHP_EOL;
    }
}

?>

Output for both:

- Iterate directory using (scandir|DirectoryIterator)
- Avoid DOT directories
- Show full path
samples/sampledirtree/file1.txt
samples/sampledirtree/folder1
samples/sampledirtree/folder2

The code looks pretty much the same and we are basically performing a simple task, but one of the powerful built-in things about the DirectoryIterator is that instead of returning a string as scandir does, it returns a SplFileInfo Object, packed with a lot of information goodness. It allows us to skip the “dot” files ( . and .. ) without testing for both, and it allows us to get a file’s full real path without having to concatenate the actual directory. It does even more, check out the main methods list: (whole list)

• getFilename ()
• getOwner ()
• getPath ()
• getPathname ()
• getPerms ()
• getRealPath ()
• getSize ()
• getType ()
• isDir ()
• isExecutable ()
• isFile ()
• isLink ()
• isReadable ()
• isWritable ()
• openFile ($mode= ‘r’, $use_include_path=false, $context=NULL)

Arguably one can also get this information by calling a function, but hey – this is OO. It is cleaner and not procedural. So it makes for much cleaner code and ease of use because you have a fully qualified object to handle a file right there, just a method call away. Its important to note that this does come at a performance cost, but at less then 40% and measured in much less then microseconds, this is not a major thing to worry about.

RecursiveDirectoryIterator (doc)

This is where the fun begins, recursive goodness. You probably noticed above that the script did not follow up on the folders it found, it stayed within the first level of the directory we chose. Recursion solves this problem. Basically this iterator will go into directories, executing DirectoryIterator on anything that is a directory. This is done by implementing the getChildren function which allows you to get a DirectoryIterator instance of the child directory.

Using the regular scandir approach we would have had to use a recursive function to obtain this behavior, but using this we only need to.. “wait, even with the getChildren function we still would need a recursive function to go through it, hey! someone lied to me!” .. This is where SPL composite magic comes in, we simply need to use a RecursiveIteratorIterator (see how the drinking game begins to be fun?).

The RecursiveIteratorIterator is basically an object that implements the recursive function, but without the complications. Just pass a Recursive<whatever>Iterator to its construct and foreach away. The iterator will automatically call the getChildren functions and manage that, and you can even tell it how to behave.

<php

function recursiveScanDir($dir){
    $files = scandir($dir);
    foreach($files as $file){
        if ($file != '.' && $file != '..'){
            if (is_dir($dir . DIRECTORY_SEPARATOR . $file)){
                recursiveScanDir($dir . DIRECTORY_SEPARATOR . $file);
            }else{
                echo $dir . DIRECTORY_SEPARATOR . $file . PHP_EOL;
            }
        }
    }
}

$dir = 'samples' . DIRECTORY_SEPARATOR . 'sampledirtree';
recursiveScanDir($dir);

?>

Now using SPL stuff with 3.5 less lines of code:

<php

$files = new RecursiveIteratorIterator( new RecursiveDirectoryIterator('samples' . DIRECTORY_SEPARATOR . 'sampledirtree') );
foreach($files as $file){
    echo $file->getPathname() . PHP_EOL;
}

?>

Output:

samples/sampledirtree/file1.txt
samples/sampledirtree/folder1/file1.txt
samples/sampledirtree/folder1/file2.html
samples/sampledirtree/folder2/file1.html
samples/sampledirtree/folder2/file2.txt

We used default settings here, but by manipulating the $mode property of the contract (2nd parameter), we can for example show children first, or “leaves” only. If you are not seeing it yet, imagine that you want to remove a directory structure – you can’t just use rmdir because it will fail due to files existing inside the folder. So you will need to delete all the files one by one, following the folder hierarchy. If you use this iterator combination and ask it to show children first, you can then delete all children and afterward remove the parents, like in this code:

<php
//Recursively delete tree structure
$files = new RecursiveIteratorIterator(new RecursiveDirectoryIterator('samples' . DIRECTORY_SEPARATOR . 'sampledirtree'), RecursiveIteratorIterator::CHILD_FIRST);
foreach($files as $file){
    if ($file->isDir()){
        rmdir($file->getRealPath());
    }else{
        unlink($file->getRealPath());
    }
}
?>

You might not see the advantage of SPL over scandir in the basic stuff, but once you start adding operations to your iteration and start to need specific behavior, you begin to realize it let’s you have much simpler and easily readable code, plus its OO! (i’m a big OO fan BTW)

Non-native in SPL

Non-native SPL clases are available currently as examples and some will be converted to C and integrated in the native part of SPL. Some contain useful as examples and you can implement them locally for your own use, or you can load these examples into your code by one of two methods:

• Add ext/spl/examples/autoload.inc to you php.ini in auto_prepend_file (or add it to the file already set in auto_prepend_file)
• Include ext/spl/examples/autoload.inc in your application

The autoload.inc file is available in the folder above, which should be in your PHP install or in the source code you can download from PHP.net. I would recommend downloading this and adding it into your application tree if you wish to use it.

Personal Recommendation: Use everything in the examples folder as inspiration to what you can do with SPL and implement it locally

DirectoryTreeIterator (doc)

The DirectoryTreeIterator is more interesting as an example of what you can do with the iterators as to actually be something you might use on a daily basis. It does what the RecursiveDirectoryIterator does but diplays the result as a ASCII directory tree, so using this code:

<php
set_include_path( get_include_path() . PATH_SEPARATOR . 'spl' . DIRECTORY_SEPARATOR . 'examples' );
include('spl' . DIRECTORY_SEPARATOR . 'examples' . DIRECTORY_SEPARATOR . 'autoload.inc');

$files = new DirectoryTreeIterator('samples' . DIRECTORY_SEPARATOR . 'sampledirtree');

foreach($files as $file){
    echo $file . PHP_EOL;
}

?>

We get this result:

|-samples/sampledirtree/file1.txt
|-samples/sampledirtree/folder1
| |-samples/sampledirtree/folder1/file1.txt
| \-samples/sampledirtree/folder1/file2.html
\-samples/sampledirtree/folder2
  |-samples/sampledirtree/folder2/file1.html
  \-samples/sampledirtree/folder2/file2.txt

Since i said its more interesting as an example, let’s look at the actual source code of the class that does the printing:

	function current()
{
$tree = '';
for ($l=0; $l < $this->getDepth(); $l++) {
$tree .= $this->getSubIterator($l)->hasNext() ? '| ' : '  ';
}
return $tree . ($this->getSubIterator($l)->hasNext() ? '|-' : '\-')
. $this->getSubIterator($l)->__toString();
}

As you can see, it is just a matter of working the ASCII to images and css and you can very easily have a directory tree anywhere on your site, by taking advantage of the RecursiveDirectoryIterator.

End of Part I…

This is a brief overview of what you can do with all the Directory Iterators available in SPL. Combining these directory iterators with other navigation iterators lets you do a lot more. This will be the topic of another post in which I will talk about all the different iterators you can use to iterate over iterators (say that 3x fast!) all the way from the FilterIterator to the InfinityIterator. I hope this helps you to get an idea of how to make your code better with SPL code.

Whatever the reason for neglecting security may be, such neglect can compromise much more than just the “non-sensitive” application data. Consider for example a recent incident at one of the biggest Brazilian mobile companies. An issue was found in a file called popup.php. The code in the file had the apparently simple objective of appending the company logo and loading a given file’s content into a popup window. So the excuse of “non-sensitive” data seemed to apply in this case.

We can easily imagine that the need for this page probably originated in the <insert non-tech department> and got escalated to the tech department with high priority (late on a Friday afternoon). In the rush the priority was to “Just get it done”, and ignore the worries about security. “No problem” you say, “leave it like that during the weekend and redo it on Monday following the proper protocols”. What happens of course is that code is never looked at again….until the day THE EPIC FAIL happens.

In retrospect we can easily see how the popup.php file led to THE EPIC FAIL. The final URL used by the popup.php file had a “url” GET var attached to it, the value of which usually pointed to another html or PHP file. This is an open invitation to try and point the GET to any file that would be “unexpected”, like so:

The result of this request immediately made obvious that at least 2 security issues were overlooked by the developer. Can you see which ones?

The first mistake here was leaving display_errors on – and this shows us the second mistake(s). The obvious one was neglecting to stick to the rule: “Filter input, escape output”. The developer obviously actually executed an include on the file specified in the URL. We can see that he did not check in any way the value provided in the “url” parameter, but he should at least have checked whehther the file was still in the site’s file tree.

To turn this exploit into something dangerous you simply need to start passing it sensitive files, like /etc/passwd or try to load the apache httpd.conf file (which actually worked in this case).

Analyzing these files showed that the problem was severe. The actual site had little valuable information, but it did show that the server had much more on it than just this site – this qualifies as an EPIC FAIL because it compromised all systems on that server. Another factor that contributed to the severity of the problem was Twitter. This flaw was only fixed 2 days after it was first reported and in the interval the detail of the exploit was widely circulated on Twitter, giving everyone the chance to look at configuration and other files. Only the victim knows if any sensitive data was compromised, but given the creativity of hackers nowadays, something was compromised for sure.

This demonstrates that security is not a simple “injection” or “pill” you can give your application after it is live – security needs to come from the ground up, leave the quick fixes for the occasional software bug. Your development cycle must include security concerns in the form of tests, validations or anything else you can think of. OWASP is a great source of points to think about. No feature should roll out the door if it did not take security into consideration. One approach is to incorporate security into your “Definition of Done”, so that a task can only be complete after security steps are taken to validate it. Peer review can further contribute to enhanced security – two heads are better than one. Managers should be as worried about this as the programmers should be. An example of such a Definition of Done is:

• Developed
• Tested (Unit Tests written and executed)
• Documentation (proper doc file or PHPDoc blocks for code segments)
• Peer review
• Security check (for known flaws, like input filtering)
• Load Testing

Every task should include the above. Even though it may cost some project development time, it will save you even more time and effort if someone attempts to hack your site. Including security in the set of tasks gives the developer time to plan each feature and reduces the risk of exploits being released. Taking security into account is part of becoming a professional developer and leaving behind the code-hacker ethic which means just coding and not considering the environment in which the application exists.

Needless to say the security-conscious approach has to be embraced by management because it is usually up to them to fight the battle for more development time and proper development cycles, and not to simply give in to external pressures – which leads to the risk of distributing dangerous code.

1. Preparing the Environment
2. Choosing what to test
3. Writing a test
4. Executing a test
5. Submitting a test to PHP

1. Preparing the Environment

Your test environment needs the correct version of PHP and the ability to run tests, I’m going to focus on *nix/MacOS systems here as I have not had experience with tests on Windows. The first step is to compile PHP from source. During the testfest we focused on PHP 5.3, but you should head over to the PHP QA Page (qa.php.net) to see what version is being targeted, or else take you pick from the PHP SVN. In any case – you need to download the source code that is appropriate for your system. The basic compilation process means you need to execute ./configure with your correct settings, and then run make. After running make you are already ready to run tests using the make test command. The latter will run all the current tests (9000+) and prompt you to send a report to the QA Team. But before you begin writing your own tests I recommend that you also run make install so you can have a proper PHP executable for the version you are testing. Later on we will see how to use make test to target only the tests you wish to execute.

2. Choosing what to test

Before you begin writing a test you must decide on what you are writing a test for. You will usually be either writing a test for a specific bug or to cover areas of PHP without “code coverage”. To figure out the bugs that have/need tests you should get on the QA mailing list or check out the correct path (for example for GD go to ext/gd/tests) for a filename with the bug-id. To write tests to cover untouched areas of the source code your best bet is to head over to http://gcov.php.net where you should pick you branch/version and look for the areas with less code coverage. In this year’s testfest the PHPSP group focused on the GD extension, so we where basically looking at the coverage for the gd.c file, which i will use for examples in this article. To decide what to test took a little bit of bit-scrubbing, so this is why I remarked earlier that knowing the inner working of PHP helps. However – after a few examples you will easily pick up what needs to be done.

Let’s start by analysing these lines of code from gd.c:

What we are looking for here are the red lines, which means that these lines were not executed. The main objective is to get all lines to either blue (executed) or white (non-executable code) as you can see above. The first thing you should notice here is that this is the code for the imageclorallocatealpha function as displayed online 1848 by the PHP_FUNCTION construct. Now you should look at the red lines where we can easily see that line 1856 is never executed, and judging by the IF construct before it we can state that this line is never executed because the zend_parse_parameters function (nevermind what it does for now) never returns the FAILURE state. As it happens, the zend_parse_parameters is responsible for parsing and validating the parameters passed to the function, so we can guess that this means that the current tests never pass an invalid parameter to the function, thus never testing if it actually returns a proper error message. This seems like good place to begin learning about tests.

3. Writing a test

Writing the actual test is usually really simple, as it should be since tests need to be atomic. You should limit the scope of your test to testing only the function at hand and the particular situation you want to test – this will also help you name the test properly, as we will see next.

3.1 Naming test files

Naming test files is simple if you defined you scope correctly:

• Bug test: bug<bugid>.phpt
• Basic function usage: <função>_basic.phpt
• Function error behaviours: <função>_error.phpt
• Variations of function usage: <função>_variation.phpt
• Extensions: <extensão>_<#>.phpt

3.2 Structure of a .phpt file

The simple structure of PHPT tests follows this basic pattern:

--TEST--
strtr() function - basic test for strstr()
--FILE--
/* Do not change this test it is a README.TESTING example. */
$trans = array("hello"=>"hi", "hi"=>"hello", "a"=>"A", "world"=>"planet");
var_dump(strtr("# hi all, I said hello world! #", $trans));
?>
--EXPECT--
string(32) "# hello All, I sAid hi planet! #"

As we can see the –TEST– section holds a one-line title for the test and should make it pretty clear as to what is being tested. The –FILE– section is the actual test code which will be internally converted into a .php file and executed. And finally the –EXPECT– section will be compared to the .php output to see if they are the same, var_dump is recommended for the tests. These are just the most standard sections – the full documentation can be checked on the QA site under phpt format,. You will come across situations where these blocks are not sufficient, but generally you will be checking if function X is returning value Y when passed parameter Z, so the above is usually all you need. One block is very important namely the –CREDIT– block. Putting your name here is very important so you can be reached in case of problems, and also to ensure that you get credit for writing tests for PHP. We used this format in our testfest:

--CREDIT--
Rafael Dohms <myemail@gmail.com>
#PHPSPTestFest 2009-04-DD

Getting back to the code above, let’s try to write a test to cover the untested line we selected above. Let’s look closely at the parse function and figure out what we need to test:

zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rllll", &IM, &red, &green, &blue, &alpha)

The important part to look at is the “rllll” as it defines the type needed for each of the parameters. The first parameter for example requires a Resource as stated by the “r”, whereas the rest of them need Long value. If we look at the PHP manual for this function we will get:

int imagecolorallocatealpha ( resource $image , int $red , int $green , int $blue , int $alpha )

It confirms what we saw in the code, but it might also show wrong information, so this would be another point where you can help PHP updating and fixing the documentation. Let’s write a test to make sure that the function sends an error message if we pass something that is not a Resource as its first parameter. Looking inside the ext/gd/tests folder we do not find any imagecolorallocatealpha files, so according to the naming conventions above we should use the name imagecolorallocatealpha_error1.phpt for our test file, since we are checking error conditions and it is the first error test for this function. (in sequence we can user error2, error3… for the other parameters)

--TEST--
Testing imagecolorallocatealpha(): Wrong types for parameter 1
--CREDITS--
Rafael Dohms <rdohms [at] gmail [dot] com>

The first step is to get the test title right and tag it with our credit so we can be found in case of future changes or problems. Make sure your title describes the objective without being an essay.

--SKIPIF--
<?php
    if (!extension_loaded("gd")) die("skip GD not present");
?>

We did not mention the –SKIPIF– section before, but it is a key section in this case. This is very important because we are testing a function of the GD extension, so this means that depending on the local environment it might actually not be available, for example if GD is not enabled. In this case we do not want to execute these tests since they would all fail, leading to false negatives. This section can also be used for other skip criteria, like 32 bit Vs. 64 bit tests, or any other condition that you feel might affect your test. The section itself is very simple – just do a check and in case the conditions for skipping are met, call a die command and the test will be marked as SKIP not FAIL in the final execution.

--FILE--

<?php $resource = tmpfile();

imagecolorallocatealpha($resource, 255, 255, 255, 50);
imagecolorallocatealpha('string', 255, 255, 255, 50);
imagecolorallocatealpha(array(), 255, 255, 255, 50);
imagecolorallocatealpha(null, 255, 255, 255, 50);
?>

This is the body of the actual test – it is really simple and atomic. What we did is to call the function various times with different types of parameters. In the first call we are actually testing line 1859, because tmpfile returns a valid Resource, however not an Image Resource and line 1859 should catch that. The rest of the parameters receive valid values, in this case integers. Testing various types is interesting because you might find a specific type that causes non-expected behavior. Since we are hoping for error messages, we do not even need the return value of the function.

--EXPECTF--
Warning: imagecolorallocatealpha(): supplied resource is not a valid Image resource in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, %s given in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, array given in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, null given in %s on line %d

Finally we now have a –EXPECTF– block which is the same as a –EXPECT– block but uses a printf-like structure to skip out on dynamic parts of the test. As we can see strings such as file name or line are replaced by %s or %d meaning it will fit any value. This is important because different environments might return different file paths. You can also use blocks with regular expressions, but this format is much more simple and easy to read. As we can see we are expecting an error message for each of the calls we made.

Tip: To get these error messages, execute the phpt file using a php executable, like: php imagecolorallocatealpha_error1.phpt. The file will be executed and everything outside <? tags will be output, and the actual output for the –FILE– block will be output as well, just copy-paste and replace dynamic bits.

Tip 2: the error message usually states the given type, as in: string given; If you are expecting the string type in the error message, replace it with %s to make your test compatible with PHP 5.3- and PHP6, since in this case it would print “unicode string” instead of “string”

4. Executing a test

Your test is ready for the drill, now we need the drillmaster to pick it up and make it jump through the hoops. We have seen that make test executes the PHP tests, but with 9000+ tests this is too time consuming to test one new test. So we should get it to execute only our test and the related tests we need. To do this we can use the TESTS parameter which will define which tests should be executed:

make test TESTS=ext/gd/tests/imagecolorallocatealpha_*.phpt

You can either pass it the full path to your test or use a wildcard (*) to execute all tests that match the pattern – this is useful if we decided to write tests for all parameters and want to run them all at once. This is the resulting output:

The test passes as we can see by the PASS text present before the test title (–TEST– block). Note that if this test had failed, the test framework would have created a few additional files to help you debug the problem. These files have the same name as the original .phpt but different extensions:

• .out – the output for the php code
• .php – source code generated for the test (–FILE–)
• .diff – a diff between –EXPECT– and the actual output
• .exp – the isolated text in the –EXPECT– section
• .log – a log of all information related (output, expected…)

These files are extremely useful in debugging. They are auto-removed once you get the test to PASS.

5. Submitting you test to PHP

There are a few ways to get your test into the PHP SVN. The easiest one is to participate in a TestFest event. All tests written at these events are submitted to a separate repository and then migrated to the official repository. The second way is to send your test file to the QA mailing list (use pastebin) and get someone to review it. The final way is a mix of the previous ones, participate in a TestFest event.. get a taste for tests, write a whole bunch of them, and at the end, apply for a SVN account. If you play your cards right and keep on writing tests you will easily get Karma and will become an official test committer in PHP. Hey it happened to me, true story, so it just depends on you and your willingness to write tests.

Conclusion

Now htat you have all the tools you need, what are you waiting for? Go help out the PHP Community. But don’t stop there, get the taste for tests and bring them to your application as well using PHPUnit and TDD – which I hope to write more about soon.

The book covers a lot of ground, even though it looks rather thin. Derick does a wonderful job of introducing date/time matter in the opening chapter, covering all the calendar switches (Julian to Gregorian) and its complexities (did you know Feb 30th has already happened once?) as well as timezones, solar times and details of daylight-saving time. This is all invaluable information for anyone working with dates.

The remaining chapters delve into the various operations we use with and around date and time, like parsing, representing and manipulating date and time values. It directs attention to various features of the PHP functions that handles timezones and daylight savings. Its also very interesting that the book fully covers and makes crystal clear the new features in PHP 5.3 that pertains to this topic.

The book explores PHP internals and describes how to use timezones and to update the internal timezone database, as well as how to deal with database engines and still get back correctly timezoned dates.

Guide to Date and Time Programming is a really pleasant read. In a very orderly fashion Derick covers all the steps before introducing new issues, instead of just raising issues without fully explaining what they are about. The book functions very well as reference book, since documentation on this topic is not all it should be in the PHP Manual. This is a must-read book for anyone that has ever had to deal with handling date or time in a PHP system, or anyone who plans on launching systems that are aware of timezone differences.

php/architect’s Guide to Date and Time Programming

by Derick Rethans

Paperback: 152 pages

Publisher: Marco Tabini & Associates, Inc. (April 20, 2009)

Language: English

ISBN-10: 0981034500

ISBN-13: 978-0981034508

Available from Amazon

SPL, or Standard PHP Library, is a set of classes and interfaces that have been built in to PHP since version 5.0, and as of PHP 5.3 it cannot even be disabled, so it is here for good. Its actually hard to disable it when compiling, so 9.9 out of 10 times you can be sure that you have it. But why have you not used it? The answer begins with “poor documentation” and ends in “didn’t even know it existed”. SPL has not had the promotion that it deserves – but this article hopes to remedy that! So what is in SPL?

SPL makes available a few hooks for overloading the PHP Engine, such as ArrayAccess, Countable and SeekableIterator interfaces, to make your objects work like arrays. You can also manipulate other stuff using RecursiveIterator, ArrayObejcts and various other iterators. It even has classes for specific points such as Exceptions, SplObserver, Spltorage and helper functions to overload other aspects, like spl_autoload_register, spl_classes and iterator_apply. Overall its a swiss army knife of code that can be implemented in PHP but that because of its hooks will probably perform much faster in SPL. So, what can I actually do with it then?

Overloading autoloader

You are a by the book programmer, and after __autoload came around you rewrote all your sites and removed the endless stream os includes and requires in your code to make way for lazy loading, right? So once in a while you found yourself in a jam, your product’s classes use a specific naming/directory structure and the Zend Framework classes you use have a “_” to path approach, how do you solve this? Giant __autoload that includes all logic, trial and error style? Alter you directory structure to Zend’s? No! Overload it!

The process is simple, just create your own autoload function and overload it, that way the autoload procedure will run the class through Zend’s loader, if it does not find a class, it will then run yours, and keep on going down the line until one of them finds it.

    1 <?php
    2
    3 class MyLoader{
    4     public static function doAutoload($class){
    5         //autoload process
    6         //use file_exists please
    7     }
    8 }
    9
   10 spl_autoload_register( array('MyLoader', 'doAutoload') );
   11
   12 ?>

Iterators

Iterator is a design pattern, a generic solution to iterate over data in a consistent manner, a way to access elements of an object in a sequential way without exposing underlying representations. SPL has all the Iterators you ever need, and i’m not exaggerating at all. This includes iteratorfilters and many others. You can use this for example in you database results, making the DbResult object implement the Iterator interface, thus making functions such as next(), prev() and other available so you can iterate results in a foreach. Another good example for Iterators is traversing a directory. In the usual manner you can iterate over scandir, then use if and else to skip over “.”,  “..” and any other files, say for example you want just the pictures from a directory. You can do all this using iterators and iterator filters, like in this example:

    1 <?php
    2
    3 class RecursiveFileFilterIterator extends FilterIterator
    4 {
    5     protected $ext = array('jpg','gif');
    6
    7     /**
    8     * Takes $path and creates a recursive iterator with a directory iterator
    9     * @param $path diretory to iterate
   10     */
   11     public function __construct($path)
   12     {
   13         parent::__construct(new RecursiveIteratorIterator(new RecursiveDirectoryIterator($path)));
   14     }
   15
   16     /**
   17      * Checks extension names for files only.
   18      */
   19     public function accept()
   20     {
   21         $item = $this->getInnerIterator();
   22         if ($item->isFile() && in_array(pathinfo($item->getFilename(), PATHINFO_EXTENSION), $this->ext)) {
   23             return TRUE;
   24         }
   25     }
   26 }
   27
   28 // Using it
   29 foreach (new RecursiveFileFilterIterator('/path/to/something') as $item) {
   30     echo $item . PHP_EOL;
   31 }
   32
   33 ?>

You may argue that now you have much more code, I’ll reply: yes, but you have reusable and testable code!

Here are some more iterators:

• RecursiveIterator
• RecursiveIteratorIterator
• OuterIterator
• IteratorIterator
• FilterIterator
• RecursiveFilterIterator
• ParentIterator
• SeekableIterator
• LimitIterator
• GlobIterator
• CachingIterator
• RecursiveCachingIterator
• NoRewindIterator
• AppendIterator
• RecursiveIteratorIterator
• InfiniteIterator
• RegexIterator
• RecursiveRegexIterator
• EmptyIterator
• RecursiveTreeIterator
• ArrayIterator

As of PHP 5.3 we have some other interesting tools, like SPLInt and other types you can use for type-casting. One class worth mencioning however is:

SplFixedArray

Why? Its faster! Why? aha! that’s the million dollar question. See to understand that we must delve into the PHP internals for a regular array. In a regular array you can use different types of keys, i.e. numeric, strings and so forth. What PHP does is that it does not use that value as a key in  the underlying C array, rather it hashes whatever it gets and uses that as a key, so hashing has a performance cost. SplFixedArray only accepts numeric keys, so no hashing happens! For those of you that caught up, yes, it is a C array! Which explains why this is faster than regular arrays. (only php5.3!!)

These are just some examples of what you can do with SPL, unfortunately there is no single place to go and get a complete view of SPL. You can hit the regular manual, but you should always trust in this documentation, done by the creators themselves, or you can hit Elizabeth’s Blog, most examples on this article belong to her.

Invitation

There is no better way to get better at SPL than contributing to it! We need documentators! So if you want to be part of PHP and help out, check out the php.doc mailing list, or IRC your way to EFNet and join #php.doc and say “I want to help”, you will be given a task very fast!