The real problem that autoloaders solve is to load dependencies. [...] The normal logic that's used to justify autoloading over manual dependency loading in production is that it only loads the classes you need. Therefore you save the parsing costs of classes that you don't need. But surely that additional run-time loading has costs. So I decided to setup a test to see how expensive that additional run-time loading costs us, and to prove whether or not autoloading is worth it in production.

He gives an example of the two methods - using the spl_autoload_register method to define a loader and loading them with a defined file path instead. He found the autoloading version slower than the hard-coded (by quite a bit) but how, when the number of files is reduced, the performance gets much closer. He also briefly looks at two other pieces of file-related functionality: file_exists and require_once.

These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.

Earlier when playing around with the Security component and SecurityBundle i found that for all paths you can specify a route name and the component will match it when check for the request paths.

Setting this up in your configuration gives you more control over the paths that are matched as well as more flexibility in defining them. He includes a note about a change you might have to make to the SecurityBundle's code to get the "check_path" part working correctly. You can find out more about the SecurityBundle's integration in this blog post from Pablo Bandin.

The thing that makes graphing databases useful is the ability to find relationship paths from one node to another. There are many algorithms for finding paths efficiently, depending on the use case.

He includes some code showing the REST request (made via this client) to fetch these street-based relationships. He then creates a little sample script that provides driving directions from one intersection to another with a "findPathsTo" call. He modifies it a bit later on to use the Dijkstra algorithm.

Since the thing went public before new PHP version has been released, I present full details of the latest PHP vulnerability I reported - together with some sweet demo exploit. The issue was found with fuzzing being part of my recent file upload research. And I still have some more to show in the future :)

The issue, described in more detail here on bugs.php.net (as of the time of this post, unfortunately unavailable) and his code to reproduce the issue is here. Due to a bug in the code that should strip down the upload to just the filename, certain kinds of file paths can make it through. The real problem comes in when an application blindly uses this filename to write to, possibly overwriting important files. You can see a screenshot of it in action here.

Lately, I've been playing around with the graph database Neo4j and its application to certain classes of problems. Graph databases are meant to solve problems in domains where data relationships can be multiple levels deep. [...] As you continue to add degrees, the query becomes increasingly unwieldy, harder to maintain, and less performant.

Graph databases, like Neo4j, handle these sorts of needs perfectly. There wasn't an official PHP interface for it, so he decided to create his own that worked with the REST interface the database provides. He includes a few code snippets showing how to connect and make a few requests - setting properties on objects, relating objects to one another and making queries that follow the paths from user to user and return them as a simple array.

When drawing a path on a map (for instance, the directions from point A to point B) it is important to consider the limitations of the device you're drawing the path on. In this article, I will show you how to reduce the number of points in a path so the path can be displayed with minimal loss of quality on devices such as iPhone or Android-powered devices that may struggle with an extremely large set of points.

Using the GTFS service's data, he's been creating maps for an iPhone application. Naturally, a path with 700 points would take a lot of resources to render. Using the Douglas-Peucker algorithm he can reduce it down to a much more manageable 70 points. He explains the algorithm briefly and hows how to implement it in PHP with three classes - ShapePoint, Shape and ShapeReducer. The resulting reduced dataset is then passed directly over to a Google Maps for plotting.

Quite a while ago I looked at using the filter_var() function to validate URL's using the FILTER_VALIDATE_URL flag and someone pointed out recently that this function has not only changed since the initial release, but that a number of flags can be added to change the way that this function works.

He lists some of the other flags that are now available that can be used in conjunction with FILTER_VALIDATE_URL to get more fine-grained in your filtering - checks on things like a required scheme, hostname and query string. He includes some code with a set of URLs to run through some tests and output as a table with the pass/fail rank of each URL value. You can see the resulting output here.

There's a popular turn of phrase "pave the cow paths", which was introduced to me by my friend Chris Shiflett in one of his talks. The essence (as I understand it) of paving the cow paths is that it's easier to positively encourage users to act they way they already want to, than to have them change their behaviour.

[...] You can't hope to guess all the ways users will want to interact with your products. [...] You can however release your core feature with some flexibility and mind, then watch.

He suggests four ways that you can try to figure out these paths in your applications: by logging routes not just hits, give them somewhere to talk about their experiences with the app, open it up to outside interface (like APIs) and try to open it up for multiple kinds of use, not just what trends in statistical results.

Recently I've been working on some new functionality to visualise all the code paths that make up each function. These new routines sit on top of the routines that do dead code analysis. These new routines sit on top of the routines that do dead code analysis. Every branch instruction (such as if, but also for and foreach) is analysed and a list of branches is created. [...] Once all the branches and their links are found, another algorithm runs to figure out which paths can be created out of all the branches.

He illustrates with a few examples, showing both the command that was executed and the resulting output with the new path information of a simple test file using a "for" loop and an "if/else" conditional.