Code Naked When the going gets tough, the tough get naked

4Sep/100

Finally, a note is added to PHP.net

So I have tried many times over the years to add a note to one of the reference pages on PHP but for some reason it never worked ... Well I tried again on Thursday and it finally worked! Check it out and let me know if you have any questions: http://www.php.net/manual/en/function.array-walk.php#99748
Filed under: Uncategorized No Comments
3Sep/100

Finally, prioritized inbox has arrived

So Google announced recently the ability to have mail in your inbox prioritized based on your usage patterns and a bunch of other junk. I have been asking for this for YEARS! I mean, if we have filtering for spam why not have filtering for email that you need to keep but isn't the most important? I personally hate email, I find it scary that there are literally thousands of middle managers employed who's sole role in a company is to filter email and forward it around to the people that need it to get their job done. I hate having to stop what I am doing every 15 minutes or so (okay more like 30 minutes if I remember) to see if there is anything important that I need to read. Now, gmail will help me out by putting those import emails right at the top so I can take care of them straight away. Sweet! You can read more about the GMail Priority Inbox here.
Filed under: Uncategorized No Comments
23May/100

Zend_Form element decoration

So recently I was asked to work with the Zend Framework on an application and I ran into a common issue that developers have when dealing with Zend_Form. That issue is the fact that basically no client side developer I have ever worked with wraps their form elements in <dl> <dt> and <dd> tags. Not saying that Zend was incorrect in using those tags for the forms, after all I have yet to see two client side developers use the same code to create a form! The current project I was working on used <p> tags to wrap them, it was a bit weird to be honest, I am used to divs with variations as the main technique used to lay out the form. Trying to solve this issue led me to embark on a fun trek through Google search results that were mostly incoherent and generally useless. Then I decided to look at the code. To keep it simple, here are a few quick and dirty examples of forms that require different element wrappings and the corresponding form class that makes it happen.

This form wraps the elements in <p> tags and has classes applied to both the container <p> and the input elements themselves. Here's the Zend_Form code that makes it happen:

Now you might have some questions about some of the things I did. Here are some bullet points to help clear things up:

  1. Yes, the setElementDecorators method in the constructor wraps every label and input in a <p> tag.
  2. Yes, I know that adding the ViewHelper decorator to the new_category element in init is basically doing the exact same thing. BUT it is also adding a class "one_half" to the <p> tag. This is how the developer was floating the elements for a two column layout.
  3. The new_category input element itself also has a class applied to it of "input-test", you can ignore that part of you aren't styling them yourself.
  4. The label of the submit element was purposely set to nothing, for some reason Zend_Form was adding the label element to the submit button if I didn't null it.

Not so bad right? Let take a look at another example that uses <li> tags around the form elements. This one is special because it also requires a <ul> tag wrap all of the form element <li> tags. Check out what that form should look like:

Nothing too fancy, I have seen forms done with li tags many times. Here's the Zend_Form code that makes the magic happen:

This one is basically the exact same as the last one with the exception that it adds the HtmlTag decorator back to the default decorators and sets its tag value to ul. It's all pretty simple really once you go digging and figure out what is going on with all of the decorators.

Tagged as: No Comments
1Apr/100

Hello wordpress!

So I decided to move my blog from the somewhat archaic feeling Serendipity to Wordpress. There are some migration tools but I'll prolly just end up recreating the blog posts by hand in the db. No biggie, it's not like I am that prolific of a blogger.
Filed under: Uncategorized No Comments
12Sep/080

Using Mappers to Persist Data

One of the things that is most annoying to deal with when developing software is converting your objects into records to be inserted into your database and then getting them back out. One of the key Patterns for doing this is known as the Data Mapper. I have followed the examples from PoEAA fairly closely when implementing this pattern, but I have diverted in places where the typing mechanisms in PHP make things easier than in Java. My mapping consists of four primary classes:
  • Naked_Mapper_Abstract - The Abstract parent of all Data Mappers
  • Naked_Mapper_DataMap - Contains the actual property to field mapping definition
  • Naked_Mapper_ObjectData - A helper class that accepts an object and a datamap and returns a hash of property=>value or fields=>value pairs.
  • Naked_Mapper_Registry - A helper class that knows how to find Mappers for domain objects and caches them for subsequent calls
In the examples below I have stripped out all of the extra junk such as logging and caching so that the basic concept can be clear. The central class that all of the other classes build on is the concept of the Data Map. Here is an example of a concrete Album mapper that builds its DataMap on construction: A data map takes the class name and the table name as constructor parameters. You add the identity property and then the rest of the property to field mappings. Pretty simple.
Filed under: PHP No Comments
12Sep/080

Debugging with FirePHP

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: It's actually pretty easy to get this working, I did have to make one change to the Wildfire library though when I first started using it in order to get it behaving as I expected. I opened a bug which was resolved before 1.6 rolled out the door. In setting this up, I wanted the debugging to be as transparent as possible, one of the great things about Zend_Log is the ability to add filters to the individual writers so that the main log writer that writes things out to a file can ignore log messages with a priority of debug or info quite easily. This means that on production we can just not include the Firebug writer and we can rest assured that no sensitive information is being sent to the browser.

Okay, lets break down what I have done:

  1. I changed the Error Controller so that it logs exceptions
  2. I added a profiler to my Db class
  3. I added a custom Memcached class so that I could ask it for stats
  4. I modified my application environment so that it could know if was in production or development
  5. I have the Workspace logging init add the Firebug logger if we are in dev
  6. I added the Debug Front Controller plugin so that I could log stuff like action exec times etc
  7. I installed the FirePHP extension for Firefox
  8. I enabled console and net for my site in Firebug
  9. I saw glorious debug info and went to get a beer to celebrate.

Although it's great for developers to have this look into your applications inner workings, in the wrong hands this kind of information can lead to your site getting seriously p0wned. In order to prevent this, I don't even add the FirePHP writer to Zend_Log if I am not in a development environment. Here's how I accomplish this in my Workspace logger init method:

Here's what my controller plugin looks like: The items that are logged are as follows:
  1. The full paths to all view scripts that have been rendered - including layouts
  2. The Module::controller::actions performed as well as how long it took to perform each action
  3. An expandable table with the contents of the current user session
  4. An expandable table of the current memcached stats. If memached has been disabled, it will indicate such. Numbers in parenthesis indicates the number of each operation that occured during the current request. This is a great way to ensure that the cache is actually working properly.
  5. A timing of the requests entire processing time. This is basically measured as the difference between the dispatchLoopStartup and dispatchLoopShutdown events.
  6. Any exceptions that were encountered are sent to the debug console with an expandable tree for the traceback.
  7. The last and perhaps most import part of the debug console is the SQL query profiling. For each query that is run, the debug console dumps the query itself as well as the execution time for that SQL query. it also includes an explain plan of that query in an expandable table format so that you can see what decisions the MySQL optimizer made when it processed your query. This can be a quick way to look for "using key: none" or "temporary table" inefficiencies in your queries.

The added visibility into your application's inner workings in such a non-intrusive way are indispensable to me when developing. Once you use it in your own applications I am sure you will feel the same way.

Filed under: PHP No Comments
18Aug/081

Adding a Profiler to a Db Class

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.

First, let's take a look at the MySQLi wrapper.

Pretty simple really as it essentially just wraps the MySQLi class. There are a couple of things to note however. First of all, if you are wondering what Naked_App::getWorkspace() is ... I'll explain that in my next post. Basically think of it like a registry that houses all of the tools I need to get work done in an application such as a database connection, a logger, and access control list etc. Another thing to note is that I am calling $this->connect() at the start of each method that requires that I am connected to the database. This is how I implement the lazy connect functionality. To make sure that I am not connecting needlessly I also log the fact that I connected and which methods forced me to connect. This can help me track down caching issues among other things. You can see what a typical log message looks like in FirePHP here:

I also wrap two other MySQLi classes for convenience. The first is the mysqli_result object:

I basically just use it to be able to fetch one or more data objects from the result set. I like to use objects as much as I can. The other class that I wrap is the mysqli_stmt class, which is basically a prepared statement. I have a really simple one at the moment, you can see it here:

As a convention I only use prepared statements for write operations so I don't need to support results from a statement execute() call. The last piece of the puzzle and the point of the entire article is the profiler. Here it is:

Basically all it does it record the start and end times of a query as well as providing a means for getting the explain plans for queries that have already run. It doesn't actually perform the explain queries until you explicitly ask for them, that way i can keep the profiler overhead lower for the default usage. Speaking of usage, here's how I display database debug information:

Now of course you know I don't just vomit this information all over my page, I log it to FirePHP. But that's a topic for another time!

Filed under: PHP 1 Comment
30Jul/080

Wrap PDO and be Happy

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...Here is the main class that wraps PDO:

Pretty simple really, just basically proxies calls to PDO. As you can see, before any operation that requires a database connection we call connectPdo() which will instantiate the PDO property of the database class if it hasn't been already. One other thing to note is that we also wrap the PDOStatement class as well so that it too can be mocked. Here's what that class looks like:

As you can see it's pretty much just a simple proxy as well, although I added a few methods to help with fetching records in different formats such as fetchAllAssoc(). The last thing I am going to show you is how I leverage these classes to mock out the database altogether and perform database tied tests without actually touching the database. As an example, here is a simple DAO (Data Access Object) that works with Widgets:

Here is my PHPUnit TestCase with a test method that covers the My_Widget_Dao::getById() method:

That's all there is to it, I hope that clears up how to unit test when using PDO as your database abstraction layer.

Filed under: PHP No Comments
20Jun/080

Zend Framework Exception Handling

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 First is registering the plugin. That's super easy. For production, you probably want to turn off the front controller's abililty to throw exceptions. Next is my error controller. By default, the Zend_Controller_Plugin_ErrorHandler looks for the error controller in your default controllers directory. Mine is located at /modules/default/controllers/ErrorController.php and looks like this: So the plugin will forward to the error action of your ErrorController. In there you can do anything you want, I choose to handle the 404 missing controller or action using a template and any other uncaught exceptions with a 500 server error which is also rendered out as a template. Here are those two templates: not-found.phtml server-error.phtml That's it. In case you are wondering where all of the HTML is in those templates, I use Zend_Layout so my action-based view scripts are quite minimal. Now you have a top level catch-all that can handle routing errors without having to write a "No Route" plugin and you get a top level exception handler in case you let one slip by you. Which would never happen of course ;)
Filed under: PHP No Comments
18Jun/080

Simple Array Syntax

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.

Filed under: PHP No Comments