Tony Bibbs on PHP

Webinar on Propel sponsored by php|architect

Tue, 24 Mar 2009 08:33:35 -0500

This is just a friendly reminder that this Friday, March 27th from 12pm-1pm CST I will be giving a webinar on using Propel, an object relational mapper (ORM). This webinar is just one of a series being sponsored by php|architect. The webinar will focus on the basics of installing and using Propel as well as one or two more advanced topics. If you are interested why not register now!

MVCnPHP

Fri, 13 Mar 2009 07:19:51 -0500

I will start this blog entry by saying I like Zend Framework. I really do. However, the part of ZF I don't use is the MVC implementation. No, it's not bad. Actually it's a good implementation that is the product of a lot of hard work by Zenders and non-Zenders alike. I use bits and pieces of ZF in my PHP projects and, admittedly, Zend's MVC implementation never made the cut. Why?

I started using my first MVC implementation, Phrame, back around 2002 long before ZF. I was quickly turned off by Phrame's Stuts-ish familiarity (no, I don't hate on Struts either). The crux of my problem was the need to edit a bunch of files just to implement one page in my web application. So started MVCnPHP. That need to itch a scratch produced an MVC implementation that made it's way into my 9-to-5. Over the next 7 years or so I did attempt to release MVCnPHP into the wild but never really polished it off. Today I'm happy to announce that has changed.

Before I get into MVCnPHP let me circle back around to ZF. Why didn't I adopt it's MVC implementation when it was released? I considered it but the issue simply came down to my biased view of the design differences. In fact, I was motivated to release MVCnPHP because of a project I recently inherited that uses the Zend MVC implementation. The biggest difference between the ZF MVC implementation and MVCnPHP is MVCnPHP is meant to allow you to isolate views and commands into their own files and simply drop them into a directory then having your controller immediately aware of them. I admit this quality of MVCnPHP isn't unique in the world of MVC implementations but this whole experience motivated me to really start working on polishing the code and documenting how to use it. Today I'm happy to announce my first release of those efforts.

So to cut the fluff, here's a few things to get you started on MVCnPHP:

I know learning a new MVC implementation may appear time so to help you evaluate it you can see it in action with this sample application that not only excersizes most the features of MVCnPHP, it gives you quick access to the code behind the scenes.
After that why not download MVCnPHP. We have versions that support PHP 5.2.x and well as a release that support PHP 5.3 namespaces.
Once installed all you need to do use read the MVCnPHP User Guide. The guide is still a work in progress but it does cover most of what you need to get started.

I can barely contain my personal excitement for getting this out. MVCnPHP represents a library that brings the benefits of a model-view-controller implementation in a package that is small, yet packed full of features with no limits for being extended. I hope you all agree.

PHP 5.2, Mac OS X Leopard and Oracle

Fri, 16 Jan 2009 10:30:58 -0600

I wanted to give a heads-up to all the PHP, Mac and Oracle fans that I just had an article published on the Oracle Technology Network (OTN). It's been in the works for months but has only just recently been published. I have to give Christopher Jones a lot of credit for being patient wtih me. The end result was an article that was fairly easy to write but was a bit of a pain. What you see in the final version is how to setup PHP, Apache and the Oracle Instant Client on a Macbook running Leopard. The most unfortunate part of all this is I was unable to get all the moving parts working on stock version of Apache. Instead I had to roll with a version of Apache I compiled from source. For those of you interested in using Oracle the article walks you through the installation process pretty well. It should also be noted I did confirm the same instructions worked flawlessly using the last PHP 5.3 alpha release. To the skilled people in the PHP Community, if someone does figure out how to get this working with the stock version of Apache I would love to hear how you did it because that'd be ideal for most of us Mac users. Comments aren't possible on the OTN version so feel free to add comments here.

Web Security Demo

Fri, 10 Oct 2008 15:58:58 -0500

Yesterday, on an invitation from our Information Security Office (ISO), I had the pleasure of giving a talk on about injection flaws, Cross Site Scripting (CSS) and Cross Site Request Forgeries (CSRF). That talk had a surprisingly large turnout and crowd participation was good. Anyway, I took my old talk on CSRF and expanded it to include a very simple PHP script (roughly 60 lines of code) that had 2 SQL injection flaws, 2 XSS flaws and a CSRF flaw to boot. I demo'd the flaws (sample input included) and I provided another script that shows some of the fixes you can make to sure it. I've made the slides you see below along with my sample code and the MySQL database available in this ZIP file. For anybody with a working PHP/MySQL setup it would take seconds to stand up and you have something you can play with to see how you can take my simple hacks and turn them into something more serious. Please add a comment below if you find any problems or have any questions.

Web Security Overview and Demo

View SlideShare presentation or Upload your own. (tags: xss sql)

PHP 5.3 on Mac OS X 10.5

Thu, 31 Jul 2008 11:45:28 -0500

Being the recent (and appreciative) recipient of a MacBook I've been getting all the usual development tools installed. Everything went pretty much as expected until I got to where I wanted to compile PHP5. Not just any flavor of PHP5 but a snapshot of PHP 5.3. While this focuses on 5.3 you'd have to do the same song and dance for the PHP 5.2 source. Why?

If there is anything you should gleam from this article for future reference, Leopard comes with a 64bit Apache installation. Thus if I go into the PHP 5.3 source and tried, say:

#>./configure --with-png --with-tiff --with-jpeg \--with-gd --enable-soap --with-apxs2

It my configure, may even compile but when you install and restart Apache you'd get errors about the PHP module being of the wrong architecture. I confirmed this using the "file" command. After that I started down the path of "well, let's just compile to 64 bit". I did find references that suggest trying to add CFLAGS="-arch x86_64" to your configure statement but that didn't work either. You might be able to get this working if you dink with it enough, however, I was in "get it working" mode. I did find this blog post by Marc Liyanage which gives more details into what is going on. Turns out this 64-bit problem is much bigger than just PHP because I was unable to get the fink libraries for stuff like libpng, etc to compile to 64bit. Now maybe you can do this by downloading the individual packages and compiling them one-by-one but I'm far too lazy for that.

The fix? Run Apache in 32-bit mode. Not knowing anything about Mac and that some binaries are compiled to support multiple architectures I was hanging out in #apache on irc.freenode.net trying to figure out the best way to compile Apache under OS X. At the same time I posted to macosxhints.com and got a very simple, elegant answer that didn't require me to download and recompile Apache:

sudo cp /usr/sbin/httpd /usr/sbin/httpd-fatsudo lipo /usr/sbin/httpd -thin i386 -output /usr/sbin/httpd

After that using my standard ./configure worked just fine and I now have PHP 5.3a1 working beautifully. That said, I'd love to hear from anybody that has managed to get PHP 5.3 (and required libraries) compiled using the 64-bit Apache.

Book Review: Pro PHP

Tue, 10 Jun 2008 09:02:00 -0500

On my flight to the DC PHP Conference in Washington D.C. I had a chance to read a copy of Pro PHP: Patterns, Frameworks, Testing and More written by Kevin McArthur. I've never written a book, I clearly don't have a first hand appreciation for the amount of work that undoubtedly goes on under the hood. Given that I will try to be as constructive with this review as possible. First I think it's important to cover the valuable aspects of the book as that will really drive your decision whether the book is worth a read. If you are new to object oriented programming and basic design patterns you will get a fairly good introduction of how to do both in PHP. Part 1, OOP and Patterns, covers things like abstract classes, interfaces, exception handling and a couple of design patterns. The list of valuable design patterns in this section of the books is far from exhaustive so I'd strongly encourage you to supplement what is in this book with a book dedicated to patterns (as well as anti-patterns). One of the best chapters in Part 1 is on Exceptions and I was specifically glad to see Kevin articulate when *not* to use exceptions as it is my experience they are often over used and used improperly. Sort of the square peg in a round hole in Part 1 was a section on what's new in PHP6 which, in my opinion, is a bit premature and it should be noted that some of the features listed in PHP6, specifically the support of namespaces, may actually show up sooner than advertised (PHP rumor mill suggests namespaces may make it into version 5.3 which is further rumored to be out around the first of next year). Because this Part of the book is five chapters yet only 52 pages don't expect a ton of detail on object oriented programming and design patterns, though, you will get a decent introduction.

The order of where things showed up in this book was a problem for me. Part 2 is on Testing and Documentation while Part 4 is dedicated to the Model-View-Controller (MVC) design pattern. At the very least Part 4 should follow Part 1's discussion on design patterns and, better yet, all of Part 4 should have been merged with Part 1. That said, I was pretty happy with the talk on testing and documentation. Kevin does a good job talking through the use of PHPDoc and PHPUnit both of which should be in any PHP developer's toolbox. Part 2 also has a good discussion on Reflection which, back to the organization of the book, could have probably been a better fit in the discussion of object oriented programming, though, he did have a lengthy section on parsing reflection-based documentation data. Kevin did a great job covering the topic of reflection but I was a bit surprised to see no mention of how using reflection can negatively impact performance of your PHP application. Which brings me to my biggest criticism of the book.

With a title like "Pro PHP" I'd expect a few chapters dedicated to performance, scalability and security. While I'm a huge fan of object oriented programming and know a bit about the value software frameworks they often work counter to scalability and performance. This book had no mention of opcode caching, no discussion on application caching, database caching and the use of shared memory (RAM). Maybe that is intended to be another book in and of itself? Nonetheless, having a chapter or two on security is something that is needed if we want to fix the internet. Indeed application security is the subject of many books so I wouldn't expect a book on "Pro PHP" to be exhaustive but today's hackers are trending toward looking for applications holes instead of networking holes because a) they are usually easier to exploit and b) there are a lot of applications looking to be exploited. XSS, CSRF, SQL Injection, etc are all things developers need to be conscious of when writing code (regardless of language) and ignoring security is this book seems to be a bit irresponsible. I know, I know...tough words and, again, you can only effectively cover so much in one book but security definitely should have made the cut.

Part 3 covered the The Standard PHP Library (SPL). This quite possibly was one of the strongest points of the book. SPL's top features are iterators of all sorts, file and directory handling and advanced array handling. Kevin covers all this and more in great detail. I was surprised to learn how many different types of iterators supported by SPL and I would recommend this entire book based on how well SPL was covered.

Part 4 of Pro PHP does a good job covering the most essential parts of the Zend Framework particularly they MVC implementation, logging and access control. In the world of PHP frameworks Zend is becoming more of a household name but I'd simply add that there are a lot of PHP frameworks out there. While the author is clearly a fan of the Zend Framework and does a good job showcasing some of it's strengths please leave knowing they aren't they only game in town.

AJAX/JSON and Web Services via SOAP are covered by Part 5 of the book. AJAX and JSON in PHP can also be it's own book given all the AJAX libraries out there. Kevin does a great job giving a quick overview of AJAX and talks a bit on how to use it with the Zend Framework. This will only wet your appetite on the subject but I felt it was a pretty good start. The following chapters focused exclusively on Web Services and SOAP. PHP5 has solid support for SOAP minus some interoperability issues and Kevin covers this well. As a shameless plug I'd also point anybody doing SOAP-based web services in PHP to check out the PHP SOAP Toolket (PST) which works around some of the interop issues. Additionally I'd also point you to this utility that gives you all the features of PST without having to install a thing. I digress...back to the book. One thing I feel that PHP is really good at is support for REST-based services which is largely ignored by this book. I think in a book like this you can only effectively cover one of either SOAP and REST, however, I would have liked to see REST at least mentioned and a quick comparison of when you might use one versus the other.

This book has also been reviewed by a number of other talented people so please feel free to factor their opinions in with mine to see if this is a book for you. I honestly do feel this book has a place on your bookshelf particularly for those just diving in more advanced PHP development.

PHP SOAP Toolkit

Tue, 03 Jun 2008 14:40:19 -0500

Michael Tutty, a friend and co-worker, gave the below talk at the DC PHP Conference . PHP SOAP Toolkit is a handy way to fill-in some of the "missing" pieces of SOAP support in PHP that make implementing both SOAP services and clients in a way that is inter-operable with other languages like .NET and Java. If you are interested in getting your feet wet with PHP and SOAP particularly with contract-first type of development you can take your WSDL on over here where you can quickly turn it into a downloadable PHP SOAP client that supports code completion.

View Full Size

DCPHP Slides

Mon, 02 Jun 2008 14:42:00 -0500

Thanks for all who showed up to my talk at the DC PHP Conference on "Fed Up of Framework Hype?". The slides are below and I'm sure some will ask about MVCnPHP which can be downloaded here. I know MVCnPHP isn't quite documented as much as I'd like...please ask questions OR wait as I will likely have a blog post about how to get started with it.

View Fullsize

Cutting Use of Zend_Log in Half

Fri, 30 May 2008 10:03:00 -0500

As part of the framework we use at work, we borrow what we feel are the best components out there and logging is a key part of that. Logging should be simple to setup, easy to use and should minimize work on the developer. After all, you are going to do a lot of logging, right? We use Zend_Log exclusively and while I like it when coupled with Zend_Registry you've always got the following two lines of code:

    // at the beginning of our application (in a singleton or in     // index.php at the very least)    $logger = new Zend_Log($writer);    $registry->set(?logger? , $logger);    // Every time you log you have these two lines.    $logger = Zend_Registry::get(?logger?);    $logger->log($errorMessage,1);

Not bad, not bad at all. In fact Zend_Registry is a handy little class. But why call Zend_Registry::get() explicitly over and over if you don't have to? I mean wouldn't it be nice if you could simply do:

MyLog::log('SomeMessage', Zend_Log::DEBUG);

That's right, let's log things statically and let all the magic happen behind the scenes. We'll do just that with a small bit of code and best of all you won't even need Zend_Registry (again, great class but why use it if you don't need it). How? Well you need to use something that acts like Zend_Registry but allows us to log messages statically. To do that we'll create a new class called MyLog and the first thing is the allow the application (or any plugins) to register their loggers (click read more):

public static function registerLogger($loggerName, $zendWriter = '',     $isDefault = false){    if (!isset(self::$instances[$loggerName])) {        self::$instances[$loggerName] = new Zend_Log($zendWriter);			    }		    // If we weren't told this is the default logger yet none exists then force it    if (!self::getDefaultLoggerName() AND !$isDefault) $isDefault = true;        if ($isDefault) {            if (isset(self::$defaultLogger)) {                throw new Exception('Default logger is already defined');            }            self::$defaultLogger = $loggerName;        }    }

The $loggerName is a logical name given to the logger you are registering. This must be unique. $zendWriter is one of the many Zend_Writer children you can use. Finally $isDefault indicates if the logger given will serve as the default logger. This will allow us to use shorter notation in our application. Ok, once you have this you can register all your loggers:

// You only ever do these onceMyLog::registerLogger('kernel', new Zend_Log_Writer_Stream(getOption('logFile')), true);MyLog::registerLogger('somePlugin', new Zend_Log_Writer_Stream(getOption('path_logs') .     'SomePlugin.log'));MyLog::registerLogger('propel', new Zend_Log_Writer_Stream(getOption('path_logs') .     'Propel.log'));

This then allow us to log a message with a single line with any of the following

// Log to the default 'kernel' logger with only an informational message. // Default log level is Zend_Log::INFOMyLog::log('Kernel starting up');// Log to plugin's logMyLog::log('Plugin failed to initialize', Zend_Log::ERR, 'somePlugin');

While the above is nice we can improve by providing simple pass through functions for each Zend_Log log level:

// Same log to the kernel from above but shorterMyLog::info('Kernel starting up');// Log to plugin log like above but shorterMyLog::err('Plugin failed to initialize', 'somePlugin');

If you like all this logging goodness you simply need to grab this file along with Zend_Log and you are on your way. Please note the requires at the beginning of the class I'm providing. It is using a method called getOption() which you will either need to implement or replace it with relative pathing. We do it this way because we've optimized our application to use APC which likes a) require instead of require_once and b) absolute paths over relative paths.

Government in the Web 2.0 World

Wed, 28 May 2008 16:35:00 -0500

In a rare moment when Twitter was up Ivo Jansch put me on to one of his recaps of php|tek and I was particularly interested in a presentation by Terry Chay. If you haven't heard Terry talk there are two things you will leave with:

Your quota for the f-bomb. I know it may sound unprofessional but he does manage to use it to draw attention to the things that really deserve it. Truth told, though, he does simply enjoy cussing.
A bunch of web programming goodness particularly around web development and PHP

In Ivo's recap one thing that stood out for me was his declaration that when developing an application it is important to consider Stability, Scalability, Speed and Security and handling them in that order. Those four S's aren't anything new to me but the assertion that they had to be in a specific order was and it is one I couldn't disagree with more (for the right reason's I promise). So why do I disagree?

In truth I only partially disagree. If your job is more one with an eye toward engineering the next great, viral application then he's absolutely right. Twitter is learning this the hard way, whereas Digg, Facebook, Yahoo! and others successfully figured this out. Then there is me, the government IT worker not focused on any one site, rather, building a large number of smaller sites. Now you could argue that states like California, Florida, Texas, etc have enough of a population base to justify the same Chay philosophy here but generally my experience is that for government the order really ought to be Stability, Security, Speed and Scalability. Why?

Stability - Let's face it, if the application isn't stable the other three S's don't matter. Using my own original Chayism a secure, fast and scalable piece of sh*t is nothing more than that. An over-engineered piece of sh*t. Terry and I seem to agree here.
Security - In government, securing the data of citizens and businesses is paramount. That's not to suggest it isn't for the more Web 2.0, virual, social networking type sites but nearly every government system I've touched has had a strong focus on security. It's not just the usual stuff like SQL injections, XSS and CSRF but also the notion of feature-based security. By that I mean we apply our MVC model to only expose certain features to the public internet. A common example of this is to limit administrative features for use on our Intranet. Other considerations that move the security issue up the priority chain in government include watchdog groups and media outlets that thrive on good government scandals and mishaps. In Terry's defense (not that he needs it) one of the arguments I could see him giving is that it's pretty trivial to secure a stable, scalable and fast application.
Speed - After stability and security Speed is next in line. Not to further stereotype a state with plenty already out there, Iowa's sheer population suggests that the need to massively scale an application is going to be a rare issue. Serving as many requests per second, however, does come in to play. A great example why this is so is the Iowa Sex Offender Registry. From time-to-time some high profile sex offender cases have been covered on various media outlets across the state and this can cause short periods of high volume traffic. Making the code run as fast as possible allows us to meet these rare spikes. If we were unable to do this reliably we'd then have to turn to our last S...Scalability
Scalability - Again, don't get me wrong, I can see where scalability has it's place and I have heard talks on both trivial and more complicated ways to achieve this whether it be database replication, sharding a database, implementing memcached, etc. In fact we even use a few of these techniques in our Java environment which is the only platform we current support to scale horizontally. To PHP's credit, for Iowa's needs it performs well enough out of the box we often avoid having to put much thought into scalability. The big gain here is we spend less time on engineering concerns and more time focusing on customer requirements and trying to commoditize software delivery.

All that said, there is a lot to learn from people like Terry as I don't doubt that some day an application will come across my IDE that will require me to rethink the order of Stability, Security, Speed and Scalability. One thing that can be learned is that no matter what application you are working on, the analysis process and resulting requirements had better make it clear what that order should be.