Code Naked - PHP

PHP: Irrelevant Again

nospam@example.com (Matthew Purdon) — Tue, 09 Feb 2010 07:24:28 -0800

So I was pointed to the Google AI Challenge being put on by the University of Waterloo Computer Science Club by a friend of mine. It's so funny to see the paradox of PHP so starkly portrayed. Take a look at the starter packages that are provided for the challenge, you will notice a couple of things:

1) PHP is not to be found on there at all, even though its chief rivals Ruby and Python are. In fact, Python was one of the first ones available.
2) The page itself is written using PHP to drive the content, presumably by some one-off page action rather than a framework implementation (the HTML is too packed hehe)

This sums up the general feeling the world has towards PHP: it's fine for throwing together a quick web page, but who would use it to actually do any programming with? I am not complaining mind you; even though I have been in the PHP game a long time, I love Python and wish I could get more work doing it!

Apparently I suck

nospam@example.com (Matthew Purdon) — Thu, 28 Jan 2010 09:15:54 -0800

I was reading an article today on outspokenmedia.com that was written back in April of 2009 and I was pretty impressed with it. I too feel that not only are people using the recession as an excuse for not trying, but also that employers are using it as an excuse to get rid of employees without having anyone put up a fight. "I'm sorry Bob, in this economy we have all had to make cutbacks, as a result we are going to give you 10 minutes to get your stuff together and say goodbye to the job you have had for 5 years." To which Bob replies "I can totally understand, at least you are going to give me my Christmas Bonus before I leave right?" hahaha. Poor little developer, you'd be cute if we weren't embarrassed to look you in the eye.

Lisa Barone goes through a few points that employees and especially contractors should be doing in order to not only stay afloat, but to excel during these crazy times. I feel that I am performing the majority of items that Lisa suggests we do: Learn something new, Work harder than everyone else, Do the leg work, Take risks, and Shut up. I am always learning and I love it so this is not a problem for me. Even now that I am not on a full-time gig I still sit in front of my computer for a minimum of 8 hours a day. Not 8 hours a day watching YouTube, but spent coding. I have written a framework from the ground up using PHP5.3 features such as namespaces, closures/lambdas, __callStatic, and late static binding. I use these features to build next level framework components such as Dependency Injection, Annotations and a Unit of Work maintained ORM layer. A little over 7,000 lines of code in a couple of weeks. I have also tried out what the development work cycle is like with Zend Studio 7.1 and Zend Server CE. I also used those tools to build a brand new Zend Framework application using a modular layout and integrating Doctrine as the ORM layer. Finally I have started to work with GWT and have discovered that it can actually be really fun to work with. There are a few other items that I have been researching and playing with, but long story short, I have used my free time to the max increasing my skill set.

The one thing that I am still sucking at is surrounding myself with fighters. It's hard to surround yourself with anyone when you work from home. I feel that I need to start being more involved in the PHP community and so I have been trying to find a PHP user group in Toronto that I could attend and perhaps speak at. So far, no luck. If any of you know of a group in the GTA please feel free to tell me about it in the comments!

Interfaces: You are doing them wrong.

nospam@example.com (Matthew Purdon) — Sat, 16 Jan 2010 05:35:18 -0800

Normally I don't do any sort of Introduction to Object Oriented Programming posts because to be honest, it's been a long time since I read chapter one and thinking in objects comes naturally to me. Today I happened across the Interfaces section of the PHP manual; the examples and comments on that page were so brutal I thought maybe I should do a public service and write something about how to create a clear object model using a couple of rules of thumb.

In my opinion, one of the most misunderstood OOP mechanisms in the PHP world is the Interface. Unfortunately, the manual seems to support my opinion. In the first example we have the class Template implementing the interface iTemplate. What is an iTemplate? The rest of the examples are even worse: class a implements b. No wonder developers struggle with interfaces when the people that literally wrote the book for them don't seem to get it. Even worse are the comments though, class Rain extends Weather and implements Water? What? Maybe if they mean water as in the sense of watering your lawn. Even so, there has got to be a better name for it than that. The way that interfaces are done in the Zend Framework offers a real-world example of bad interface design. Take a look at the following sentence and let's see if you can make sense of what the involved components are:

Zend_Validate_Date is a Zend_Validate_Abstract and can Zend_Validate_Interface

Now to be completely fair, these class names do get ugly as a result of having to bear the weight of pseudo-namespacing, but if your interface is actually called "Interface" you know you have a problem. Let's look at it again but this time we will be using PHP 5.3+ (which you should be using because it's awesome) and Zend Framework 2.0 - which may have namespace support:

Date is an Abstract and can Interface

This does not describe what type of an object the Date is. Is it a calendar date? Is it a fruit that can be dried and old people drink to help them go #2 more regularly? Or maybe it is a meeting involving two or more people in order to determine if their physical proximity elicits a chemical response. Who knows? And don't even get me started on "can Interface"! Maybe that's what happens if there is chemistry between the people on the Date? Now if you are an experienced OOP developer, you will know that Abstract is the home of some common functionality that all child classes share and that the Interface defines the contract that any objects implementing it must fulfill. But it doesn't tell you anything about what type of functionality is common to the children of the abstract or what types of behavior must be implemented by objects implementing the interface.

Designing objects can be fairly easy for the most part if you take the stance that your objects are nouns and your interfaces are adjectives. Until you get better at it, try to add the suffix "able" to indicate that objects implementing it are capable of doing something. Try this version of the Zend Framework validation action:

Date is a Validator and is Validatable

You won't always be able to use the "able" rule of thumb, but going through the process of trying to think of one will help you arrive at a better object model. Take a look at a few more examples:

A Circle is a Shape and is Drawable
A TeddyBear is a Toy and is Huggable
A CardDeck is an ArrayObject and is both Countable and Sortable

So hopefully these examples help give you an idea how easy it is to create good code. As always when it comes to designing objects, your best tool is simply reading the objects out loud. The better your design, the less like Yoda you will sound. Of course I couldn't leave this post without throwing down some code, and since I was most appalled by the Weather examples in the manual comments I thought I would do my own weather example. The real key here is to note that not only do weather conditions such as the amount of clouds and the UV index rating affect what the actual temperature feels like, so can what you wear. In other words, weather can use objects of completely different types to do work because it knows that those objects are capable of doing a particular thing.
Continue reading "Interfaces: You are doing them wrong."

I thought Zend_Soap was going to be easy

nospam@example.com (Matthew Purdon) — Wed, 13 Jan 2010 15:56:20 -0800

But then I tried to use it. I had a project that I needed to respond to SOAP requests and considering the issues I had last time I played with SOAP, I thought I'd try it a different way this time. The Zend framework is always described as being a collection of components that you can wire together in order to get work done. Most of the time, you use it to build a full MVC stack application, but I only needed one component (I thought) in order to get my work done.

Turns out you need a whole bunch of junk in order to be able to use the Zend_Soap component without a full copy of the Zend Framework:

Zend_Exception - I always thought this was a dumb thing in the first place. I use the SPL exceptions for my stuff.
Zend_Loader - What? Why? I required my class and most of the ZF uses requires as well so I am not sure why it wanted the loader
Zend_Registry - I thought maybe to cache the wsdl? But that's cached in /tmp by the underlying PHP soap action
Zend_Uri - Makes sense, the service is a web service after all
Zend_Validate - Have to make sure the Uri is valid I guess
Zend_Soap - duh

In the end, I needed 106 source files in 20 folders to get things done. This is especially crazy when you think that you can get a boiler plate client working by doing this:So you may be asking yourself if the Zend_Soap really needs all of those files. I thought so as well, but to be honest, I am trying to use the component to get a quick start on the service, not to spend an annoyingly long time going through each component only pulling out the exact source files I needed and placing them in their proper place in my library folder. You may also be asking yourself why I would bother in the first place. I'll tell you why, dear reader, it's because I wanted automatic WSDL generation! And it's because of this small desire that my troubles began.
Continue reading "I thought Zend_Soap was going to be easy"

Naked PHP Framework on Git Hub

nospam@example.com (Matthew Purdon) — Fri, 08 Jan 2010 07:59:24 -0800

So I have been using git for a while now, and I really like it. I really appreciate being able to check in code without having to have a server available and for some reason it just feels a lot more solid than Subversion. Case in point, today I was merging a big branch back into trunk and it was throwing a ton of conflicts on tabbed versus spaced lines... Easy enough to fix but still annoying in the first place. I don't seem to get those kinds of issues with git. *shrug*

So I am just doing a quick post to say that I have put my toy framework up on GitHub so that I can keep track of it, share it with some other people and because I want to be like all of the other cool kids and have some open source junk on GitHub. I feel cooler already!

The framework itself has some interesting features, but as I said, it's mostly just there to experiment on. Check out what's working now:

* MVC stack - Duh, isn't every framework now?
* Highly modular - Everything for a module lives in the module. Configuration, Routes, etc can all be dropped in place as one folder.
* Uses namespaces - The initial reason I started writing this framework was to get namespace experience. Love them.
* Annotations - Allows you to specify stuff in a method/property doc block. @Inject for example.
* Dependency Injection - Uses type hinting and annotations to inject using constructor and/or setter injection. Can use lambdas/closures as object factories. It's sick, trust me.
* ORM - Has a very Django-like object manager. Want to get all BMWs with a model of 750i newer than 2007? It's easy: $cars = Bmw::objects()->filter('model_eq=750i')->filter('year_gt=2007'); Working on implementing single table inheritance right now where all classes for a hierarchy map onto on database table. Uses lots of late static binding.
* Unit of Work - Basically handles persisting Domain Models transparently using the ORM. If you load an object, change it and then delete it. Only the delete is persisted and the changes are ignored. You can read more about it on Martin Fowler's site. It's pretty awesome too.
* Templating - Another port from django. Basically allows for non-php template syntax. I like it, you might not.

Here's what is on the road map to completion:

* Forms - You guessed it. Django port again. Basically each property in a model is a field with validation and all of that junk built in. The forms handle wrangling them to and from the browser.
* Signals - Very similar to how plugins work in the Zend Framework. Instead of being rigidly contained however, you can emit any old signal to the signal bus and it can be ignored or handled by various listeners
* Automatic auditing - The unit of work knows what changes have happened, by adding an @auditable annotation to a class the Unit of Work will track the changes to the object in an auditing table.
* Automatic Sphynx updating - Again the unit of work knows when an object has been updated so if it has the @searchable annotation it will automatically update the sphynx indexes.
* Creation tools. The point is that this framework pretty much wires up everything for you so you just get down to business. Need something similar to Zend_Tool to help peeps out.
* Who knows. After all of that junk is in place... Well, I'll probably have started all over again ... *sigh* A great way to learn a lot about the new PHP 5.3+ features though!

Dependency Injection: Me likey

nospam@example.com (Matthew Purdon) — Tue, 29 Dec 2009 08:48:04 -0800

So I spent some time over the holidays working on my proof of concept framework. One of the key features I added was something I have always been curious about but never really got around to playing with, Dependency Injection. I thought the idea seemed to be powerful but I never really grokked it until I sat down and started to implement my own DI container. The first thing I did was hit google and search for "PHP Dependency Injection". It turns out there are a lot of frameworks out there now that support some form of injection but I wanted to make sure I was taking the best ideas from all of them and rolling them into my own. I decided to start with Constructor Injection as it is the easiest to implement, but I also wanted to introduce the concept of a context. One of the things we have to contend with frequently in software development is the transition of our code from development environments to production environments, I wanted my framework to knit itself together automatically for whatever environment it was being deployed in. For example, when I am in development I want my logger to use the FirePHP extension and have it log at the debug level. In production I want my logger to be completely silent for all but critical errors which are logged to a remote monitoring server. Most of the time I see this implemented in some form of Environment via an init call

/**
     * Initializes the main logger
     *
     */
    protected function _initLogger()
    {
        // logging handler
        $logger = new Zend_Log();

// general logger, in charge of writing important info to PHP_ERROR
        $stdWriter = new App_Log_Writer_Error();
        $stdWriter->addFilter(Zend_Log::DEBUG);
        $stdWriter->addFilter(Zend_Log::INFO);

// If we are not in production and not running from command line,
        // send logging info to FirePHP
        if (!$this->isProduction()) {
            // queries
            if ((bool) $this->getConfig()->log->writers->query->enabled) {
                $queries = new App_Log_Writer_Query(
                    $this->getConfig()->log->writers->query->uri);
                $logger->addWriter($queries);
                $stdWriter->addFilter(9);
            }

// firePHP
            if ((bool) $this->getConfig()->log->writers->firePHP->enabled) {
                $firePhp = new Zend_Log_Writer_Firebug();
                $firePhp->addFilter(new Zend_Log_Filter_Priority(9, '!='));
                $firePhp->setPriorityStyle(8, 'TABLE');
                $logger->addWriter($firePhp);
                $stdWriter->addFilter(8);
            }

// debug
            if ((bool) $this->getConfig()->log->writers->debug->enabled) {
                $queries = new App_Log_Writer_Debug(
                    $this->getConfig()->log->writers->debug->uri);
                $logger->addWriter($queries);
            }
        }

$logger->addWriter($stdWriter);
        Zend_Registry::set('logger', $logger);
        $this->_logger = $logger;
    }

As you can see, there are a lot of implementation details that the environment needs to know about in order to get logging together. Even worse is the fact that if you need to get at the logger in code other than in the Environment class itself you need to get it from a registry every time $logger = Zend_Registry::get('logger');
Continue reading "Dependency Injection: Me likey"

SOAP Kills

nospam@example.com (Matthew Purdon) — Fri, 20 Feb 2009 06:06:18 -0800

So I am working on a new assignment at work yesterday, should be a pretty simple task I think. I am consuming a SOAP service to get some simple data. Little did I know that it was such a pain to work with .Net when you are using the PHP SOAP extension. I started out with the following WSDL (just a portion that I wanted to work with is listed).

<wsdl:binding name="WSHttpBinding_IFeedService" type="i0:IFeedService">
    <wsp:PolicyReference URI="#WSHttpBinding_IFeedService_policy"/>
    <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>
    
    <wsdl:operation name="List">
        <soap12:operation soapAction="http://schemas.example.com/IFeedService/List" style="document"/>
        <wsdl:input name="ListRequestMessage">
            <soap12:header message="i0:ListRequestMessage_Headers" part="MetaRequest" use="literal"/>
            <soap12:body use="literal"/>
        </wsdl:input>
        <wsdl:output name="ListResponseMessage">
            <soap12:header message="i0:ListResponseMessage_Headers" part="MetaResponse" use="literal"/>
            <soap12:body use="literal"/>
        </wsdl:output>
    </wsdl:operation>
    
    <wsdl:operation name="ListByCode">
        <soap12:operation soapAction="http://schemas.example.com/IFeedService/ListByCode" style="document"/>
        <wsdl:input name="ListByCodeRequestMessage">
            <soap12:header message="i0:ListByCodeRequestMessage_Headers" part="MetaRequest" use="literal"/>
            <soap12:body use="literal"/>
        </wsdl:input>
        <wsdl:output name="ListByCodeResponseMessage">
            <soap12:header message="i0:ListByCodeResponseMessage_Headers" part="MetaResponse" use="literal"/>
            <soap12:body use="literal"/>
        </wsdl:output>
    </wsdl:operation>
</wsdl:binding>

<wsdl:binding name="BasicHttpBinding_IFeedService" type="i0:IFeedService">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="List">
        <soap:operation soapAction="http://schemas.example.com/IFeedService/List" style="document"/>
        <wsdl:input name="ListRequestMessage">
            <soap:header message="i0:ListRequestMessage_Headers" part="MetaRequest" use="literal"/>
            <soap:body use="literal"/>
        </wsdl:input>
        <wsdl:output name="ListResponseMessage">
            <soap:header message="i0:ListResponseMessage_Headers" part="MetaResponse" use="literal"/>
            <soap:body use="literal"/>
        </wsdl:output>
    </wsdl:operation>
    <wsdl:operation name="ListByCode">
        <soap:operation soapAction="http://schemas.example.com/IFeedService/ListByCode" style="document"/>
        <wsdl:input name="ListByCodeRequestMessage">
            <soap:header message="i0:ListByCodeRequestMessage_Headers" part="MetaRequest" use="literal"/>
            <soap:body use="literal"/>
        </wsdl:input>
        <wsdl:output name="ListByCodeResponseMessage">
            <soap:header message="i0:ListByCodeResponseMessage_Headers" part="MetaResponse" use="literal"/>
            <soap:body use="literal"/>
        </wsdl:output>
    </wsdl:operation>
</wsdl:binding>

So I write up a quick test script to grab that WSDL and try to run a method on it. It looked something like this:
Easy-peasy, I have working with PHP driven SOAP services a bunch of times before so I could pretty much write that off the top of my head. So I run the code and I get a SoapFault saying that the Content-type is text/xml when it was expecting application/soap+xml. So I Google around and find that I have to specify the soap version 1.2 in order to get the correct Content-type. So I make the following change to $clientOptions:
Nice, that error is fixed. But Now I have another SoapFault: "The SOAP action specified on the message, '', does not match the HTTP SOAP Action. Google again. This time it looks like the PHP soap client is not able to deal with WSHTTP binding and must use the basicHTTP binding. I am not authenticating for this SOAP service, so I am not sure why it even matters. Luckily, the WSDL tells me that I have basicHTTP bindings available. When I try to use the basic data source though, I get another SoapFault "Action /basic is not defined". So then I email the provider of the feed to make sure their basic binding is configured correctly and working. They make some changes and end up dropping the WSHTTP binding completely from the WSDL. Sweet, that error is fixed.

Except that I am getting another SoapFault, fortunately for me I have run across it aready in my little adventure. It is now complaining that the Content-type application/soap+xml is incorrect as it was expecting text/xml. Seriously! So I go and remove the soap_version element from the $clientOptions array. Awesome, that was an easy one to fix!

But now I have another SoapFault: "Object reference not set to an instance of an object.". Google again. This is where things get really annoying. First of all, the SoapFault error message is ridiculously cryptic. I find all kinds of forum posts and comments in the PHP manual about how you are supposed to pass parameters into the action method on your client. Here are some of the different versions that I tried:
No good.
No good.
No good.
No good. Then I tried adding 'classmap' => array('ListByCode', 'ListByCodeRequest') to the $clientOptions array. That didn't work either. Please bear in mind that these changes may appear to be the flapping around of a dying fish, but I assure you that they each involved several minutes of Google research. I will admit though that by this point I was feeling fairly desperate. I decided to go get a copy of soapUI to see if maybe the feed itself wasn't working. I import the WSDL click on LIST and hit run. Bam! Results are returned immediately. I calmly stand up and leave my office before I bring violence upon my computer.

15 minutes pass

Okay, so I return to me desk and decide to look ONLY at the requests I was making and try to get them to match the ones created by soapUI. Here's what soapUI was doing:
And here is what I was producing:
So obviously my parameters where not being passed in. I tried making the following change:
Which results in this request:
Snap! I am getting a different SoapFault saying that param1 is basically an unknown parameter. I proceed to try several versions of nested arrays and finally give up after this one:
You see I am back to the whole "Object reference not set to an instance of an object." SoapFault. It is then that lightening comes down and strikes my brain. This is the final (and working) version of the script:
So, hopefully this little saga will help others that are in danger of having a very long day as I had escape their fate. On a side note, whenever I am doing this kind of research on Google I always wish that there was an option to specify how old the results should be. I have the option Search: [ ] the web [ ] page from Canada, but I'd really like to see [ ] from this month [ ] from this year [ ] any time as options as well. A blog post mentioning PHP and SOAP from 2003 is probably not going to be helpful. Although sometimes I can see the date it was written before I click, not seeing the entry at all would be great.

Enterprisey PHP

nospam@example.com (Matthew Purdon) — Thu, 29 Jan 2009 06:58:59 -0800

I hear a lot of talk about the use of PHP in the Enterprise, recently there was even a white paper circulated extolling the virtues of PHP and attempting to make the case that PHP should be the language of choice for Enterprise development. Although the paper does bring up some interesting points such as the large number of extensions and the fact that there are a number of bridges for PHP to load native code written in Java and other languages, taking away from these strengths was that there is way too much emphasis placed on how many websites run PHP. Although it is hard to argue with the fact that PHP is greatly suited to web development, that in no way translates into suitability for Enterprise development. No offense to the language, but I find it perfectly understandable that PHP is not often considered a language suitable for Enterprise development.

PHP developers have a love-hate relationship with Java. Many PHP'ers are quick to point out that "PHP is not Java" and yet when one considers some of the most recent waves in PHP interest, they are frequently things that have been around in the Java world for years and are just now being introduced into PHP. A couple of recent examples are the sudden surge in PHPUnit and phpUnderControl. The latter isn't even a fully native PHP solution but en extension of the venerable Cruise Control continuous integration suite. That being said, I use both of those extensively and they form a crucial part of my software development process. Unfortunately, I feel that the adoption of these technologies has started to plateau as the initial wave of blog posts and general buzz have died down. Many PHPers feel that it's just too much effort for what it's worth. This is the key to the whole debate in my opinion. PHP developers put everything behind speed when it comes to development, in fact I often see bad code decisions being made for the benefits of a few CPU cycles. Perhaps it's because the speed of PHP is the primary strength that developers point to when comparing it to other languages that they focus on that feature. Honestly, PHP should be the fastest language on the web, after all it's all it's done for the last decade.

Here's what you should take away from this post:
1) Using PHP does not make you cooler. It should mean that you have chosen the right tool for the job. There is a reason why Zend Studio (from Zend, The PHP Company) is written in Java and not PHP-GTK. Why be just a PHP developer when you can be a programmer with many tools at your disposal.
2) If you want to improve the way PHP is considered in terms of The Enterprise, make your code look like it was written for the Enterprise. Stop considering your software to be something that you will write and throw away. Write it like it's something you will have to maintain for a decade and some day you just might get to.

Debugging with FirePHP

nospam@example.com (Matthew Purdon) — Fri, 12 Sep 2008 06:40:00 -0700

One of the nicest features to have when you are developing an application is a decent debug console so that you can see what your application is doing without having to look through ten log files and put var_dumps that you have to comment out all through your code. In the Zend Framework v1.6 we get a new feature based on FirePHP which will allow us to log directly to the Firebug console with a simple API call from PHP. Here is an example of how this looks in my application:

Continue reading "Debugging with FirePHP"

Better Alternatives to using Zend_Registry

nospam@example.com (Matthew Purdon) — Wed, 10 Sep 2008 14:21:32 -0700

Don't get me wrong, I think the Zend_Registry component is great. There are a couple of problems that I see when using the Zend_Registry as a container for junk like database connection objects and session namespaces and pretty much every other resource that you need to be globally accessible. The first, is that there is no information about what kinds of resources are available to you when you are using the registry. In other words, there is no way to know what Zend_Registry::get('db'); is actually going to give you. Is it a Database connection resource or is it a Data Buffer? Actually, it almost makes more sense for "db" to be an acronym for data buffer ... At any rate, there is no way to enforce what you are getting. This means that your editor can't code hint for you and your API docs don't really show an object that has the responsibility of wrangling application resources. I guess that is a good summary for the first issue with Zend_Registry - it's too generic to be really useful.

The second problem with the Zend_Registry is that it is essentially a global array. At any given time an innocent developer can unwittingly blow away your database connection with his data buffer and there is nothing to stop him. We all know (or should know) that global variables are bad. They inject uncertainty into our applications and can be the cause of some of the most irritating to debug problems. So, to sum up the second issue with Zend_Registry - it suffers from the same issues that all global variables suffer.

So, how do we fix it. Simple really, we create an object that is responsible for maintaining these application services. In fact, I use two different objects to manage two different types of application resource. I use Naked_App_Environment to manage configuration and environment information and I use Naked_App_Workspace to manage my application resources such as Naked_Db connections and Zend_Logger instances. Let's take a look at these two components and see how your life as a developer can be made better...
Continue reading "Better Alternatives to using Zend_Registry"

Adding a profiler to a Db class.

nospam@example.com (Matthew Purdon) — Mon, 18 Aug 2008 06:09:54 -0700

First of all, in case you don't know me that well, you need to know that I am a big fan of unit testing. Although I like the idea of using a database abstraction layer, I have come to dislike PDO for several reasons. First of all it's behavior is not the same for every database driver that you use. This is not a fault of PDO itself so much as the authors of the database specific drivers that are not able to implement the entire feature set. Secondly, I am not sure I buy into this "You can just switch databases and all you have to do is change the config" argument. Any application that either has a DBA on the team or cares at all about performance will have tailored SQL to get the most out of the database - which as you know tends to be the main bottleneck in an application. The main reason that I dislike PDO is that it is such a pain to mock it while unit testing. For some reason it was deemed necessary to have PDO connect on construct rather than either having an explicit connect() method or a lazy connect when one is needed. Even though you can specify that you don't run the constructor when you mock PDO, you then run into internal trouble as some settings are not set up properly and you get errors. At work, I tend to just wrap PDO with my own Db class that proxies calls to the internal PDO instance so that I can mock my Db class and everything plays nicely.

For my own junk, I tend to always go with MySQL as my database so I don't really like the idea of adding a wrapper to a wrapper to a wrapper in order to talk to it. I use MySQLi as my db class, but I still wrap it so that I can do lazy connects. The reason for this is so that once my cache is warmed up, and the user has logged in, I don't even connect to the database during a normal session. This helps tremendously as the connection to the database is the most expensive part of database interaction. If I do need to perform any write operations, they are performed by the Unit of Work, which doesn't kick in until the dipatchLoopShutdown. (I still have a few tweaks in regards to caching with my Unit of Work implementation before I show you how that works.) This also helps to ensure that if I do need to open a connection, it's for the shortest amount of time possible.
Continue reading "Adding a profiler to a Db class."

Wrap PDO and be happy.

nospam@example.com (Matthew Purdon) — Wed, 30 Jul 2008 09:31:06 -0700

So I normally don't bother using PDO as most of my projects are MySQL based, for a project at work though it was decided to use it. One thing that I get really annoyed with is the fact that PDO attempts to connect on instantiation. I have no idea why you would want that to be the default behavior as it makes so many things a pain. Where it really bites you is in unit testing because it's very difficult to mock PDO.

So, instead of using PDO directly I wrap it with my own class that defers instantiating PDO until absolutely necessary. In this way, I can mock my database class quite easily so that I can test without touching the database. So let's take a look at some code...
Continue reading "Wrap PDO and be happy."

Zend Framework Exception Handling

nospam@example.com (Matthew Purdon) — Fri, 20 Jun 2008 18:32:16 -0700

Handling exceptions is extremely import if you want to have an application that is stable and end-user friendly. The Zend Framework comes with some great features for handling things like missing controllers and actions right out of the box. Like many things with the Zend Framework, you have to dig a little before you find the answers that you need. There are three steps needed to take advantage of the build in exception handling features:

1) You have to register the Zend_Controller_Plugin_ErrorHandler plugin.
2) You have to create an error controller
3) You have to create the templates for the specific error types

Read on to see what my versions of the above look like...
Continue reading "Zend Framework Exception Handling"

Simple array syntax

nospam@example.com (Matthew Purdon) — Wed, 18 Jun 2008 18:38:46 -0700

So I was reading Brian Moon's blog today. I had bookmarked it to come back to it later but then I had to go to NY and everything... Turns out the change was voted down. The vote by email thing is lame as well.

So here's my opinion. Anything that makes PHP feel more like a modern programming language is better. What is the percentage of programmers that still code in C? Just because PHP is built on top of C doesn't mean that it has to look and feel like C. I totally agreed with Brian that it should be committed. In fact, I think the syntax should be expanded to include ranges:

$foo = [1,2,3,4,5];

could be written as:

$foo = [1..5];

Sweet. Oh and for the love of God can you make functions as first class citizens so we can start to do some functional programming?

*sigh* PHP is held back again.

Object Property Visibility and Magic Methods

nospam@example.com (Matthew Purdon) — Sun, 08 Jun 2008 10:12:31 -0700

I often thought that one of the great features of OOP in PHP 5 was the addition of the public, protected and private keywords. Now, I find that they are total pain in the ass when used incorrectly. I was just reading the article on DevShed about protecting class data with member visibility and I was reminded of an email that I had sent out to the PHP developers that I work with. As usual, there was not one response to the idea of using magic methods rather than fifty eleven accessors and mutators. I personally use the magic __get and __set methods all of the time but I'll get to that in a minute.
Continue reading "Object Property Visibility and Magic Methods"