I’ll be Reviewing “Zend Framework 1.8 Web Application Development” by Keith Pope
A Marketing Research Executive from Packt Publishing contacted me several days ago about reviewing a recently (September 2009) released book by Keith Pope entitled Zend Framework 1.8 Web Application Development. I am honored to be considered a developer with enough knowledge of the Zend Framework to offer my thoughts and opinions on such a book. Since I already read Mr. Pope's blog I've followed along during the writing process and cannot wait to read the actual book.
Keith posted a sample chapter of the book on his blog if you are interested. Otherwise, stay tuned for my review!
The Modern PHP Workflow
Over time we have all seen projects that become great success stories and our fair share of projects that become epic failures. Some of this can be blamed on the idea behind the project but I challenge you to consider that part of failure can be attributed to a lack of constant supervision of the project. This is not to say that any one person is in charge of ensuring a project is on target with the original goals, or even that a project manager is responsible for testing the project throughout development. Rather, I'd like you to consider the work flow used on those failed projects and compare it with a more modern approach to development. While this won't guarantee the success of every project, using proven tools and methods such as unit testing with PHPUnit, an automated build system such as Phing, and a continuous integration server such as Xinc will greatly improve the quality and timeliness of your future projects.
Preparations
In order to follow along with this article you will need to equip yourself with the proper tools. Luckily between pear and the pecl obtaining these tools is the matter of a few characters typed into the command line. Note that thorough installation instructions can be found on the websites for each of the tools which are http://www.phpunit.de for PHPUnit, http://xinc.googlecode.com for Xinc, and http://phing.info for Phing.
The Foundation: PHPUnit
Personally before I began my journey into the world of “Agile” development practices, specifically unit testing, I was already familiar with the basic concepts behind why it is a good idea but I was a little intimidated by the seemingly steep learning curve. If you're anything like me you have thought about the amount of additional time your projects will take because of the added burden of writing tests, you think that testing is something reserved for the extra weeks you tacked on to the schedule for this project and comes in the flavor of “Try out this application and see if you can break it.” or worse yet you think that your code is so impressively impeccable that you could not possibly benefit from writing these silly little tests. I am here to tell you that I was wrong in all of those assumptions. It took a while for me to realize the benefit and I will not try to convince you that it took no time at all to adapt my thought process to testing, but I can tell you that as a result I am more confident in my code, my projects are easier to maintain, and my clients and employers are much more satisfied with my work.
The toughest part of getting started with unit testing is deciding where to being your journey of learning how to test your applications. To help you along we are going to work together to develop an application to track the whereabouts of various items needed for school as a collegiate student. For this purpose we are going to assume that our student needs to track his notebooks, his textbooks, his planner, and his laptop which can be in his desk or in his backpack. Over the course of this example I may introduce a few bugs--some purposely, some otherwise--if there is any doubt in your mind about the code, assume it is for example sake.
Coupled with unit testing the technique of test-driven development is thrown into the mix and we're going drive the development of our application with testing. The principle behind test-driven development (TDD) is that we first write tests that describe how our code functions, more specifically how it is used, and then we write the code that allows the tests to pass. This might seem counter-intuitive at first, but we write failing tests first then make the code conform to our tests thus making our tests the contract to which we design our code. Coding the opposite direction generally leads to bending test code to fit the workings of your code base which in turn will lead to massive refactoring and potential code hernias in the future. If you aren't familiar with the term “code hernia” it is essentially a fragment of code that is in place that may be difficult to understand, most likely causes awkward use of the code base or API, and is only explained by lengthy comment blocks. The maintenance nightmare associated with such awkward code is exactly the type of problem we hope to solve by unit testing our code.
Object Oriented Power, err, Programming
I started working on integration between three libraries that were not meant to work together. Well, I should say they were not developed with this type of integration in mind. Naturally there were some roadblocks, but eventually I was able to overcome them and create what should be a decently elegant solution. But that's a post for another day. This post is targeted at developers searching for the purpose of Object Oriented Programming.
I suppose it's not a secret that I make liberal use of the Zend Framework. (It's nothing personal Symfony, CodeIgnitor, Django, etc., Zend Framework just fits my style!) Part of my integration experiment led me to ZF-7367 because I too needed to tell the front controller to return the response rather than output it. The first instinct is to hack up the copy of the Zend Framework to make this work. The patch suggested in the issue gets us part of the way there, but we also have to hack on the Zend_Application component including the Bootstrap implementation. This would make future upgrades a pain if this feature request is rejected, so it's obviously not the best solution.
Thinking about the problem a little deeper I immediately realized that I already extend the Zend_Application_Bootstrap_Bootstrap (yes, the naming scheme is quite verbose and suffers from a bit of redundant redundancy…) so it should not be too difficult to override the run() method to do what I want. Let's look at the original run() method inside Zend_Application_Bootstrap_Bootstrap.
/**
* Run the application
*
* Checks to see that we have a default controller directory. If not, an
* exception is thrown.
*
* If so, it registers the bootstrap with the 'bootstrap' parameter of
* the front controller, and dispatches the front controller.
*
* @return void
* @throws Zend_Application_Bootstrap_Exception
*/
public function run()
{
$front = $this->getResource('FrontController');
$default = $front->getDefaultModule();
if (null === $front->getControllerDirectory($default)) {
throw new Zend_Application_Bootstrap_Exception(
'No default controller directory registered with front controller'
);
}
$front->setParam('bootstrap', $this);
$front->dispatch();
}
All we really need to do here is configure the front controller instance to return the response object which is accomplished using the Zend_Controller_Front::returnResponse(bool) method. Inside the application bootstrap class we simply use this implementation:
public function run()
{
$front = $this->getResource('FrontController');
$front->returnResponse(true);
parent::run();
return $front->getResponse();
}
Now I have the response I need returned from the bootstrap file, but the Zend_Application::run() method does not return this value. Here's where what I've been rambling about should click. I merely have to override the Zend_Application::run() method with one of my own, like so:
class My_Application extends Zend_Application
{
public function run()
{
return $this->getBootstrap()->run();
}
}
This protects me from hassle when my copy of the Zend Framework needs updates or upgrades but still allows for the functionality I needed. In the index.php file I switch out all references to Zend_Application with My_Application and everything should roll.
Professional Development with the Zend Framework: Introduction
Table of contents for Professional PHP Development
- Professional Development with the Zend Framework: Introduction
- Professional Development with the Zend Framework: Unit Testing
Talk to a random sample of developers and you'll find a wide range of opinions regarding frameworks. Some people swear by frameworks; some people swear they will never touch a framework. Regardless of your opinion frameworks do serve a valuable purpose: they are tools that are capable and quite effective at developing professional developers.
Frameworks are not unique to any one language. I've watched PHP develop from a scripting language designed to simplify dynamic elements in a personal home page to an "object capable" (snicker) language that people apply object oriented principles with. With the recent rise in available of PHP frameworks, development — professional, "enterprise", or otherwise — using frameworks is becoming more and more prevalent.
Why the Zend Framework?
Personally, I've only worked with a few frameworks and none more so than with the Zend Framework (ZF) which is why I chose it for this series. There are quite a few tutorials out there on how to get started with the framework and I don't intend for this to be a quick and easy "Hello World" tutorial. If you are after something along those lines I'd suggest reading Pádraic Brady's book Zend Framework: Surviving the Deep End. Rather, I'd like to walk through how to use the framework as a learning tool. This will be useful knowledge for even the freshest of beginners but I think it will be especially useful to a developer looking to take his or her framework-driven projects to the next level.
One benefit found in using the Zend Framework comes from its design as a use-at-will framework which means the component library is useful separate from the MVC stack. More concisely, if there is a component of the framework, e.g., the Twitter service wrapper, that you would like to use it is possible to just grab that component and run with it. (I believe the ZF team has worked hard in trying to keep components as decoupled as possible. That said, it is entirely possible that you might have to grab a couple components.)
In this series I will be using the the framework "in all its glory" including the MVC stack. As stated earlier I will assume that you understand the basics on getting your app up and running, but I will have to walk you though some places where I tend to differ from some of the conventions found in the various sources of guidelines for ZF development.
Source Code
To truly benefit from this series you will need to see the progression of the project from early stages to polished and ready for deployment. That wouldn't be difficult except that I don't know at what point you stumbled upon this series. To better facilitate housing each step I will host the code for this series on GitHub. (If you have not yet experimented with Git I — and many others — highly recommend giving it a shot.)
Each installment of this series will be a branch in the Git repository. There should be roughly one branch per installment unless there is something terribly clever or complicated and I'll try to separate it out for you.
You can browse the repository online or clone it. I also encourage you to fork the project and add your commentary. After all giving back to the PHP community is encouraged. The code is licensed under the GPLv3 free software license.
Environment
To follow along with the series you will need to have access to several tools. First and foremost you will need a copy of the Zend Framework. The release at the time of writing is version 1.9.2. I like to use the release branch associated with the current minor version as my development code base. In other words I'll pull from the svn repository branches/release-1.9 instead of the tag for release-1.9.2. This allows my development to receive all bug fixes and improvements for the 1.9.x family.
You will also need a copy of PHPUnit. Sebastian Bergmann maintains steller documentation on installing and using PHPUnit. While not necessary if you just want to gather some new practices or tips on using the framework, PHPUnderControl (PHPUC) is something I'll mention and use throughout this series. Several other tools integrate with PHPUC including PHP Code Sniffer, PHP Documentor, and dbdeploy.
I'll be using PHP version 5.2.9 on my development environment. While PHP 5.3 is the current version it's sadly likely that the adoption rate will be as slow as usual. To take full advantage of PHPUnit and PHPUC, Xdebug will also be used on my development machine(s).
Now, if I haven't lost you, let's move on to some actual developing; well, if you call using mkdir development.
The Directory Structure
At first glance, the recommended Zend Framework directory structure is incredibly complex. I know because the first time I saw my eyes glazed over. But there is a reason for the deep structure and it's masquerading around as our good friend Mr. Separation of Concerns. Take a moment to digest the structure in Figure 1.
Figure 1 — Recommended Zend Framework Structure
Pay no attention to the little cross-hair like symbol on all the directories. That just means that the directory is in the Eclipse build path. In all this is not a bad directory structure. It has a places outside of the document root (which is the public directory, by the way) for tests, configuration files, application cache files, uploaded files, et cetera.
However, in my opinion this structure does not make sense for a production product. For example, when this project is deployed, the tests do not need to go with it. They need to be present on every developer's workstation and the build server, but the final deployment of the product has no reason to keep them around. So, my first change is to separate the tree(s) that compose the production-necessary files from the test and development files. (I'll also cheat and make the change look more impressive by collapsing the expanded directories.)
Figure 2 — Modified "ProDev" structure
As you can see, we
- added a tools directory,
- added the src directory (which now contains all of our application code),
- removed the build sub-directory from the scripts directory, and
- added a directory called database with a sub-directory of deltas to the scripts directory.
The tools directory will house local copies of the various external tool libraries, e.g., PHPUnit, that are needed for the build process. I keep local copies to ensure that no matter where the project is being developed, the environment is consistent. For example, I might have a PHPUnit instance on my development box that is version 3.4 of the project but the build server might be at version 3.3. Having the local project copy — or reference, really — means that I don't have to worry about what version is installed where. I know it will work.
The src directory is where the application code will reside including the reference to the framework. Keeping it contained inside this directory allows the project's development files to remain separate from the application code that will be distributed in final form.
The scripts/build directory is unnecessary as the build script(s) belongs in the project root.
Finally, I added the database and database/deltas directory to the scripts directory to house the script(s) necessary to create and initialize the database for the application — assuming there is one. The deltas part will be confusing to you if you are not familiar with dbdeploy. Essentially this folder will contain a series of sql files prefixed by a number, e.g., 001_create_professionals_table.sql. The three digit number increments by one with each script. I don't yet know what happens after 999_x.sql because I have not made it that far in a project. We'll touch on database and delta scripts later on.
Stub the Necessary Files
The main "hello world" files in a Zend Framework application are no secret. There must be an index.php script, a .htaccess file, a Bootstrap.php file complete with an implementation of Zend_Application_Bootstrap_Bootstrap, so on and so forth. All of these files are included in the Git repository. Clone away.
The interesting bits are the unit test scripts and the build script. For the unit tests — in the tests directory — the scripts you will find in this initial distribution of the ProDevZF application are the phpunit.xml file (a configuration file used by the PHPUnit engine; a bootstrap.php script (used to set up necessary resources to run the scripts); and an AllTests.php (which is a bit strange at this point considering the test suite is empty). Feel free to poke around the contents of those files before the next installment of this series where I will explain them.
The build script is a whole different beast. Welcome to the world of Ant. If you aren't into Ant because you hate Java — or for other more noble reasons — there is a similar tool called Phing. You can probably use Phing instead of Ant but I will not because I'm using Java-based products for my continuous integration. Since build scripts in Ant are covered in great detail on the Internet (the series of tubes you are connected to right now) I will elect to not explain the build script. If you'd like me to explain the whats and whys, leave me a comment and I'll work it into a supplementary post.
Words. So many of them.
At long last this introduction is over. I appreciate your patience as I set the stage for the coming articles. I am hopeful that no other installment in this series is quite as lengthy.
My Car Is Self-aware
My car — the 1990 Acura Integra LS I purchased when I turned 17 years old — is obviously self aware and capable of self-multilation. Every now and again I will start thinking about getting a new car. My car has its quirks and is definitely getting up there in age. But I always planned on driving it in to the ground. Some would say that it was successfully driven into the ground when I had to replace the power steering rack; or when a burnt valve needed replacing earlier this year; and those people would be correct. But something led me to decide that I favored a $1,400 repair job on a car that's already paid for completely over a new debt.
So rewind a few days and you'll find that I started a new job on September 1 which led me to begin seriously considering going after the Jeep Wrangler I've been lustfully eyeing for the past six months or so. It is evident that my Integra knows my thoughts because sure enough on Wednesday, September 2 a coolant hose finally cracks and sends antifreeze all over my engine bay.
Over the past few days I've learned a very important lesson regarding coolant hoses in automobiles: when one of them cracks just replace them all. As my girlfriend will attest I now know the local auto parts store employees on a first name basis, and her truck might actually be capable of getting to the store without any intervention from humans. Tracking down the hoses for a twenty-year-0ld car has been quite the endeavor.
Nevertheless, I can now say that my upper and lower radiator hose, heater hose, bypass hose, and garden hose have been replaced. Ok, the garden hose part isn't true mainly because I live in an apartment and don't own a garden hose. Which brings me to next weekend. I'll be heading down to Houston to flush my radiator of the water that is in it now and replace it with a proper 50/50 mixture of coolant to water.
I've dubbed this week the Great Hose Debacle of 2009.
Do YOU Pass the Beer Test?
As a form of self-validation — I told you my decision was difficult, didn't I? — I've spent some time reading some articles about how to find and hire the perfect candidate, top reasons for leaving your job, and reinforced some principles I've held based on conversations with other developers in the past. One of the "gut checklist" items from an article on the Atlassian blog is to decide if the new employee passes the beer test. Simply put this is a subjective analysis that indicates whether a person would be interesting enough to hold a conversation with outside of work.
While the original post was meant to help in the vetting process, I think it applies equally to applicants during the job search and interview process. Community is an aspect of the technological world that when neglected will have a devastating effect on the work environment. Thus it is imperative that a candidate takes time to observe the interaction among the community members and determines what, if any, his or her role will be in the community.
I must admit, however, that I cheated on my last beer test. (The test I was giving to the potential job, not the one I was taking.) As I mentioned, I learned about the position from a friend and colleague of mine and he already passed the beer test. The very fact that the team I was applying to become a member of passed his beer test was good enough for me.
That said, I've attempted to determine what qualities I look for in a beer test that I would give. First and foremost, I value interests that are diversified. In a group setting I'd like to have conversations with people that oppose my views as much as I'd like to have the proverbial choir to preach at. Having a broad spectrum of interests leads to a healthy pool of topics to choose from.
Along the same lines being able to articulate thoughts and opinions is among one of the most important qualities a beer buddy, if you will, can have. Without expression of ideas in a way that each party in the conversation can absorb growth will be stifled. There is not a quantifiable way to distinguish if a person can articulate thoughts in a decent manner because it is entirely dependent upon the individual. The important factor to consider is if the mutual articulation is well received and if your potential beer buddy or buddies can understand what you are trying to tell them.
These two qualities are the most important, in my opinion of course, factors that should be considered when administering a beer test.
Dropping the Equivalent of a Child
I've known for quite some time that I am overweight and I've finally put it in terms that disgust me. I need to lose the equivalent of a 9–12 year old boy to get within my "ideal" weight range according to the Mayo Clinic. I'm currently carrying around 260 lbs. which is roughly 90 pounds too many. The CDC study shows that 90 pounds is roughly the 97th percentile of 9-year-old and the 50th percentile of 12-year-old boys. My goal is to remove this parasitic child from my body.
Every weight loss plan worth its salt is rooted in a well-planned diet. Unfortunately, I do not have a registered dietitian at my disposal — and I am absolutely enamored by great food — which is going to make my new required choice to eat historically bland food very difficult. But it is something I must do. I will be eating primarily chicken, pork, and talapia with the occasional lean beef and salmon steak. I will get my fiber from broccoli, apples, bananas, black beans, whole wheat bread, green beans, carrots, spinach, brown rice, oatmeal, and other fruits and vegetables as they appeal to me in the supermarket. For recipes I will consult the South Beach Diet Cookbook as that particular fad diet is supposedly recommended for cyclists.
Which brings me to my exercise. My primary catalyst for exercise will be on my Jamis Ventura Race that I purchased on July 27, 2009. I don't know if I need much more motivation, but for good measure I will be participating in the Lance Armstrong Foundation LIVESTRONG Challenge in October. I'm registered to ride the 90-mile course. Between now and then I have over 1800 miles of training rides planned. The many hours on the bike should produce significant weight loss.
I am supplementing my cycling with an eight week training plan for a 5K run. The day before I ride the 90-mile LIVESTRONG Challenge course I'll participate in the 5K fun run. As it is a fun run I don't necessarily have to train to be the best, but the competitor inside me demands that I run the best I can.
I also firmly believe that no exercise regimen is complete without torturous hours in the weight room. I'll look nowhere other than the Fat Loss programs Alwyn Cosgrove introduces in The New Rules of Lifting. His introductory or beginner workouts kicked my ass before, so I have the utmost confidence in his program development skills.
NROL Exercise Book
I will be blogging this entire process complete with diet updates, exercise reports, progress photos, and metric tracking. I have weekly progress photos and weigh-ins planned with almost daily post updates. Because I will want to memorialize this forever, I decided to house the posts and information on a separate blog. Keep track of my journey at http://thejourney.carouth.com.
New Position at Texas A&M
September 1st will be my first day in a new position at Texas A&M University in the Division of Marketing and Communications. For the past year I have been a member of the Division of Research and Graduate Studies — Systems Group (RGS) web development team; say that three times fast. I learned of an opening through a colleague, Ben, and could not pass up the opportunity to apply. I'll be working with some great people and in an influential role on the University's web presence.
Reflecting on the past year and three months I feel that I made a positive impact on the web development group at RGS and also managed to grow as a developer and a community member in the process. One of my more notable contributions to the University came in October of 2008 when I implemented the Academic Master Plan white paper submission application. The development cycle was blazing fast and I worked like an employee at a startup for six days straight on that project. I believe that my hard work and dedication has paid off. I am leaving behind a project that I have grown particularly fond of, but I am confident that it is in good hands and that my original vision will come to fruition; someday.
I don't know exactly what my new position has in store for me but I am hopeful that it will push me into new areas and allow me to add to my skill set. One particular area of interest is the mobile development market. At the University we are in a position that a powerful presence on the mobile web will have a tremendous impact. Measures have already been taken but there is a significant amount of ground work that must be done before we are known as pioneers in the mobile education market. In the coming years I hope I can push us in that direction.
I am looking forward to working more closely with Chris Weldon and thankful for the new toys, err tools, I will have at my disposal. Wish me luck!