What are stream wrappers?

PHP 4.3.0 introduced the idea of streams. The PHP manual has a perfect explanation:

Streams were introduced with PHP 4.3.0 as a way of generalizing file, network, data compression, and other operations which share a common set of functions and uses. In its simplest definition, a stream is a resource object which exhibits streamable behavior. That is, it can be read from or written to in a linear fashion, and may be able to fseek() to an arbitrary locations within the stream.

Streams are identified by a particular scheme in the URI. For example, with http://someurl the scheme is 'http' and when no scheme is provided like in /file.php, the scheme is defaulted to 'file' and is expected to be a file in the filesystem (thus file:///file.php would mean the same thing).

Stream wrappers are bits of code that tell PHP how to handle certain schemes. The interesting thing is that you can create your own custom stream wrappers written in PHP with little effort.

For example, you may have done file_get_contents('file.txt'); before. But say you wanted to have the same ease of use but with data from a different source. You could create a custom stream wrapper to get data from wherever you want and use all of the normal PHP functions as usual: file_get_contents('mystream://whatever');.

Almost any function that works on files will work with custom stream wrappers. That includes fopen, fwrite, fseek, is_readable, is_writable, stat, unlink and more. In essence you can create a virtual filesystem in your applications.

Why create custom stream wrappers?

So why in the world would you want to create custom stream wrappers? Basically it comes down to decoupling filesystem-coupled interfaces from the filesystem (or any stream, for that matter). That is, make software think it's talking to files when it's talking to your custom PHP class. It's all about abstraction!

You could also use stream wrappers to simplify an interface, though this is less common. If you are using stream wrappers to simplify an interface, you can just as easily create a normal facade to simplify the interface and leave streams out of it.

For example

I wanted to use a newish PHP templating engine called Dwoo for an upcoming project. The problem was it expects files everywhere. Template files were read from the filesystem and compiled to the filesystem, and caches were written to the filesystem. There was no easy way to change this.

For this particular project I need to read templates from a string (loaded from an arbitrary source decided at runtime), and I can't use the filesystem for caches, I need to use memcached. The reason being that the application will be run in a cluster. Using shared disks is not practical with this many machines, and disk IO would eventually become a bottleneck. True, we could use RAM disks, but it's a lot easier and portable to manage the data layer from our application instead of pushing it to the OS.

Using custom stream wrappers I created two new schemes for 'tpl://' (for reading) and 'tplc://' (for writing compiled templates). I was able to fill the requirements for the project while still using the awesome templating engine with little modification. The library still thinks it's reading and writing to files but behind the scenes it's reading from a cache of template sources and writing to memcached. Perfect!

Creating custom stream wrappers

To create your own custom stream wrappers you need to write a class that implements a set of methods. After you write the class, you can register it with stream_wrapper_register. Refer to that manual page for details on the methods you need.

The only problem I encountered was how to get my custom stream working with is_readable() and is_writable(). The trick is to implement the 'url_stat' method and set the 'mode' correctly. The mode is a number that represents what type of file the file is (file or directory etc) and the file permissions -- the usual chmod values. Here's a code snippet that accurately defines how the number should add up:

$dir = 040000;
$file = 0100000;

// Now you can add any permissions you want using the usual chmod octal notation:
$file += 0777; // A file that is readable
$dir += 0222; // A directory that is writable

The Zend PHP Certification is basically a badge that says "I know my stuff". Zend's site actually has a pretty good summary of the benefits of becoming certified.

I became certified for a couple of reasons (other than me being an egotistical bastard). I wanted to test myself and make sure I was actually up to date with everything. I came into the world of PHP around version 4.1. Since then a lot has changed, especially with the advent of PHP5. Taking the practice exams I discovered that there were a few areas I definitely needed to improve upon. For example, primarily working on products that needed to run under a PHP4, I never had much experience with the new XML features.

The other reason was that the exam was really cheap for the possible benefit. Noted, the Zend PHP Certification is hardly mentioned at all by employers. It is relatively new as far as certifications go. But by sticking that badge on your resume, you automatically have a one-up over your adversaries. PHP programmers are a dime a dozen these days, and most of them only know enough to slap together something that barely works. If a possible client knows you've passed the official PHP Certification exam, it gives you some credibility. $125 is a small price to pay. You can make that back in just a single job.

Preparation

I know you're thinking it. Everyone whose asked me about the exam always asks "was it hard?". For me, it was simple. I found it really easy. But I've been working with PHP for a long long time, so obviously your milage may vary (it's all relative, after all).

What you really need to do is a little research. I ended up buying the bundle which included the study guide, 10 practice exams, and the actual exam voucher. It's a pretty good deal, I encourage anyone interested in taking the exam to do the same.

The study guide was not bad. It's basically a quick walkthrough over the entire language. But the practice exams were really useful. The practice exams tell you if you're really ready to take the real thing. I can tell you, they are very very close to the real exam; they are actually a bit harder. If you pass the practice exams, you will surely pass the real exam.

After you finish a practice exam, you get a scorecard telling you which areas you passed, which you failed, and which you did excellent in. For me, this scorecard revealed I needed to brush up with SimpleXML.

I should mention that the exam is a pass or fail thing. There are no grades. My PHP Certification can not be better than yours. So just because you get "pass" instead of "excellent" doesn't really matter unless your ego requires it (like mine!).

What you should know

The Zend website has an overview of the topics covered by the exam. Of course you need to know every inch of PHP, but I will point-out/stress:

• Regular expressions: You should know some basic regex.
• SQL: You will need to know some basic SQL, and how it works (i.e., fetching rows with PDO). Some topics you might need to brush up on include indexes, table joins and transactions. You don't need to be a DBA to pass the exam, but you should know how to work with a database.
• How numbers are represented in hex or octal notation. I mention this here because a lot of us don't need to worry about hex or octal notation in PHP.
• How the bitwise operators work.
• Differences between PHP4 and PHP5. There are a bunch of little nuances here that you may be asked about.
• Security: You should know things like how to avoid XSS, session fixation, filtering input, validation etc.
• XML: There may be a number of questions about XML, XPath, SimpleXML etc. If you've been working with PHP4 a lot, then it's time to get in tune with the improvements PHP5 introduced.
• PDO: If you've been working with a database abstraction layer (which is probably just about everyone reading this), then you probably will need to read up on how PDO works.
• There may be a few questions regarding software architecture such as design patterns (MVC for example), OOP principals etc.
• Streams and network programming is something you will probably need to look into a bit.

Who should take the exam

You should only take the exam if you actually know PHP well. It does an excellent job at weeding out the half-assed PHP programmers, so don't even attempt it unless you know your stuff already. If you are just starting out, or are of average skill, your money would be best spent buying some other material like Advanced PHP Programming.

You should take the exam if you are a freelancer, or looking for work. I think it definitely does give you a heads up over your competition. Even if you have other credentials. Case in point: recently I was looking for a new programmer to help develop a product I work on. One applicant was a CS major, but was an absolutely horrible programmer. You might have passed a few college classes, but that doesn't mean much to me. I need to know that you can deliver.

You should take the exam if you want to test yourself, like I did. It is certainly a good way to discover your weaknesses and your strengths. You might find multiple areas where you had no experience.

So with all that said, good luck!

The solution that I came up with was to use Flash. Seeing as how over 98% of all users have Flash installed, it was the perfect solution.

I ended up finding an open source project called Sound Manager. You just embed the Flash movie on your page somewhere, and talk to it with plain old Javascript. You don't need Flash installed, you don't need to create your own movie -- all you do is use the API provided by Sound Manager.

For the curious ones amongst you, the API is really simple (taken directly from the linked page above):

soundManager.createSound('myNewSound','/path/to/some.mp3');

soundManager.play('myNewSound');
soundManager.setVolume('myNewSound',50);
soundManager.setPan('myNewSound',-100);

The only problem I had with using Sound Manager is that it requires MP3's, and all of our sounds were WAV's. No biggie. Converting the files to MP3's was simple, and the resulting filesize a bit smaller anyway.

Even more accessible?

98% of internet users have Flash. That's a pretty good percentage. But I still wanted to make sure those rare 2% of users didn't get some "install this plugin" popup.

Basically what I ended up doing was using a Flash sniffer (some JS to determine if Flash is installed, and which version) to see if the user can use the Sound Manager. If they could use it, then great -- we're all set to go. If they couldn't, then the app reverts back to using good ol'd <embed>'s (except for IE7; no sound is better then an annoying security popup!).

Yesterday's time was spent both learning the framework and creating the upcoming Outershift website. In 6 hours I learned much and completed a good chunk of the back-end. Considering I started from scratch, I am very pleased with how quickly the project has progressed. So, check out the symfony framework for yourself!