There is a bunch I could say to introduce this chapter. However, I think that by reading the first few paragraphs you will know what I’m talking about. For those who are experienced developers some of these items might seem a little basic, but there are reams and reams of PHP developers who do not follow several of these rules.
In other news, “You want to do WHAT with PHP?” is now available for purchase in the Amazon store.
PHP is a langauge generally not suited for running daemons. That said, PHP can do it, and in certain circumstances does it sufficiently for the job. In this chapter we look at some of the things you need to know about to build a PHP-based daemon. This excerpt doesn’t feature any code, but it does set the foundation for why I think PHP is fine for daemons in some circumstances. Later in the chapter we get into the code.
Most PHP developers are used to dealing with files. Files that are uploaded, downloaded, etc. If we work with data files it is usually in the form of XML or CSV or something like that. But what if the files that users were uploaded and downloading had information in them that you wanted to get. Say that you were hosting MP3 files on your website that people could upload. You might want to get the ID3 information that states who has the copyright. Or if people were uploading Word documents and you wanted to get author information. There are often libraries available to read certain file formats in PHP, but more often than not, there isn’t. The purpose of this chapter is to get you started in being able to read and understand binary files. Even if you aren’t using them directly in your application, knowing how to read them is a good exercise since there is a good chance that at some point you will need to be able to work with them. Even if it’s something that you would be writing a one-off script for to do some basic data transormation, knowing how to access binary files is a good thing and, as I said earlier, a lot of PHP developers don’t do this.
I was getting ready to post the Powerpoint presentations from my last two user group meetings when I fat-fingered my “My Documents” folder and accidentally opened up a Word doc that had an old article that I had written for a Zend newsletter a while ago. So for this case of serendipity I decided that I would repost this article, which I had written long before I had a blog. The basic premise is that once you get past a few minor differences, an organization can move from Java development to PHP development in a very short amount of time, saving time, money and headaches.
One of the things that I think PHP developers do not do well is asynchronous processing. PHP developers have written reams of applications that do all their calculations up front and over-and-over again for multiple requests. Or they will just write their code to work linearly, regardless of the scalability implications. In this chapter I wrote a simple example showing how you can do some asynchronous processing. It is a basic example that I use and there is a LOT more I could have talked about, and perhaps I should have. But this example will get you started thinking about how to architect your application so that you can greatly increase the scalability of your application.
So I was sitting here thinking to myself “This is Friday and I’m not getting much of anything done. Maybe I should write another Friday Framework Highlight.” I figured that it was a good idea so I pondered what I should write. I came up blank and so I asked Matthew Weier O’Phinney. “Multiple writers for Zend_Log,” he said. I agreed.
Let’s take a quick look at something that’s kind of neat in Zend Framework. I’ve been doing some work with Adobe on some articles and one of them was on working with mobile clients with Flash. Well, me being the masochist I did more. What I did was write an example that worked as a full website, an Ajax website, a Flash service and an XML-RPC service.
Setting the Stage
First I started with a Zend_Db row instance and it’s corresponding table instance.
Quick! Raise your hand if you know the most underutilized feature in PHP? If you’re thinking type-juggling you’re wrong (that’s probably the most over-utilized feature). It is, in my mind, SPL. If you are doing any data processing whatsoever you are using arrays. And most likely you are doing database queries, iterating over the results and doing your algorithm-ing. But what if you have additional functionality that you need to have integrated with your data. You could go the traditional route and copy and paste half your application around or you could build, what we like to call structured applications. SPL allows you to do that. How? Well, that’s one of the reasons why I wrote the book “You want to do WHAT with PHP?”. Here’s your excerpt…
So, you just received instructions to download and try out Zend Server. Or, you heard that Zend Server is a “PHP Application Server”, but you have no idea what that means and you want to find out. What do you do?
What I have often seen is that people will download and install Zend Server, try a PHP application on it and see if it works. They see that it does work. Then they ask “ok, it works but it’s not worth the price so I’ll just go back to what I was using before.” The problem here is that more often than not, and I’m sure it’s a MUCH more often than not, “worth” is not defined.
Communication is key to building applications now and for the future. While it is not something that I think that everyone should do, I have not seem many applications that make good use of streams in PHP. Streams can be immensely useful in the right situations, but a lot of developers are not really aware of how streams can be used. In this excerpt from chapter 4 of my book “You want to do WHAT with PHP?” I talk about how you can use streams for fun, and maybe for profit. While I don’t think you will end up basing your application around streams it is a really good idea to know how streams work. With that in mind, here is an excerpt from the book.