I. Codebase

“One codebase tracked in revision control, many deploys”

There’s really not much here that would be different in PHP versus any other language. Who isn’t using some form of revision control these days?

II. Dependencies

“Explicitly declare and isolate dependencies”

There are a few tools available to PHP developers to help manage dependencies. The PEAR package manager may help here, but has its flaws. Pyrus, the PEAR2 package manager, looks promising. There’s also Composer. I’ve heard of people using their operating system’s package manager (e.g. RPM) to deploy their PHP applications and manage dependencies. I’m not sure if there any tools in PHP to enforce dependency isolation.

III. Config

“Store config in the environment”

The simplest option here is to use environment variables. Many frameworks, including Zend Framework, allow you to have environment-specific configuration such as development, test, and production. This is not recommended for twelve-factor apps as it doesn’t scale as new environments are added.

IV. Backing Services

“Treat backing services as attached resources”

There’s not really anything to say here that’s specific to PHP.

V. Build, release, run

“Strictly separate build and run stages”

Phing or the more general-purpose Ant could work here. Even though it’s not written in PHP, there’s no reason why you couldn’t use Capistrano for this. I don’t think the run stage typically applies to PHP, as it happens implicitly as part of the release stage. However, there are tasks such as flushing the APC cache (if apc.stat=0) that might be considered part of the run stage.

VI. Processes

“Execute the app as one or more stateless processes”

PHP processes are already stateless and shared-nothing. This makes PHP a great fit for twelve-factor apps. Memory space or the filesystem should be used as a short-lived, single-process cache. If you’re using an asset manager, such as Assetic, then any assets should be compiled and cached during the build stage.

VII. Port binding

“Export services via port binding”

I don’t think port binding applies to PHP applications—at least not in the way it’s meant in twelve-factor. PHP relies on a web server and uses something like FastCGI or PHP-FPM to communicate with the web server. PHP 5.4 will have its own built-in web server, but this is intended for development use only. It’s really the combination of PHP and its web server that will be bound to a port. This brings up challenges when it comes to dependency management, as the web server itself is now a dependency.

VIII. Concurrency

“Scale out via the process model”

I’m not sure how processes would become first-class citizens in a PHP web application. However, each individual request/response cycle is handled by its own process. In that regard, PHP already uses the process model.

IX. Disposability

“Maximize robustness with fast startup and graceful shutdown”

PHP processes are very disposable. Again, this is just part of how PHP works.

X. Dev/prod parity

“Keep development, staging, and production as similar as possible”

Nothing specific to PHP here. Although, it’s not uncommon for PHP developers to use SQLite in development and MySQL or PostgreSQL in production. This is not recommended for a twelve-factor app—use the same software and versions of backing services in all environments.

XI. Logs

“Treat logs as event streams”

There are tons of logging options in PHP. Zend_Log_Writer_Stream lets you send log data to a PHP stream. Alternatively, StatsD and the PHP StatsD library look pretty good.

XII. Admin processes

“Run admin/management tasks as one-off processes”

This is easy enough in PHP. If you want an interactive shell with readline history, tab completion, and quick access to documentation then check out phpsh.

Zend Framework 2.0 should be released soon, and it has been four years since the last major release (1.0). This is not to imply that Zend Framework has been stagnant—far from it. There has been a ton of development effort and many improvements to Zend Framework since 1.0. I have a great amount of trust in the team, and I have complete confidence that Zend Framework 2.0 will be an awesome framework. This post is intended to make the case for rapid release cycles for software in general, and is not meant to be a criticism of Zend Framework or the development processes behind it. However, the discussions around Zend Framework’s release cycle are what’s prompting me to make this post.

First, let me describe what I mean by a “rapid release cycle”. In this context, I mean rapid releases of major versions. Put simply, major versions are those that allow backwards compatible breaks. This is somewhat controversial. I don’t think anyone really has any big concerns with the rapid release of minor (introduction of new features while maintaining backwards compatibility) or maintenance (bug and/or security fix) releases. “Rapid” depends on the context. Both Chrome and Firefox have adopted a six-week release cycle. As I mentioned before, six months could be considered “rapid” for a framework.

For a framework (and maybe for other software), I think the following rules are necessary in order for a rapid release cycle to work:

• Minimize backwards compatibility changes between major releases. Targeted and strategic refactoring, rather than major overhauls, are preferable if you are releasing often. Small backwards compatibility changes makes migrating from one major version to another much easier.
• Mark some major releases as “Long Term Support” (LTS) releases. Provide bug fix updates and security patches to these releases for three to five years. This provides a “safe” option to those who value stability and don’t want to upgrade very often. In the context of Zend Framework, it is obviously Zend’s decision if they want to take on this burden. If not, then I don’t think a rapid release cycle is viable.

What are the concerns with a rapid release cycle? I’ll paraphrase, and then address, the major concerns that I’ve heard.

“Rapid releases of major versions are just for psychological effect and has no affect on the delivery pace of new features.” This is both true and false. See my earlier post on iterative vs. incremental development. If development is incremental and driven entirely by a pre-determined roadmap then there is no tangible differences between a “normal” and a rapid release cycle. The development of many consumer software packages is perceived as incremental, in which case major version bumps are mostly psychological. However, if you take an iterative development approach and build-in outside learning from end-users into your process, then a rapid release cycle gives you the chance to change course based on outside feedback. Learning opportunities are introduced that you would have never had if your software wasn’t actually used by real people in the real world.

“Rapid release cycles are for consumer software where you don’t have to care for backward compatibility.” This is related to the previous concern. My response is that rapid release cycles are for any product where learning from real-world usage and outside input can be used to improve the product. To quote Steve Blank, “There are no answers inside the building.”

“It forces people to upgrade too often and rewrite their code, or get left behind.” See my earlier note about minimizing backwards compatibility changes in each major release. Additionally, it is much easier to automate upgrades if the backwards compatibility changes are small. There should be little code rewriting for applications built using the framework with each major version upgrade of the framework.

“Having lots of end-of-life (EOL) versions being used could be a security risk.” See my earlier note about providing LTS releases. Each major release should come with a pre-determined EOL date. It is the responsibility of the end-user (in the case of a framework, the developer) to be aware of a release’s EOL date. Using EOLed software is always a security risk.

While not specifically a concern with rapid release cycles, there’s a general mentality that major releases are “our chance to get it right.” Hopefully you’re a better software developer than you were even six months ago. Chances are you know more than you did then, and would approach solving problems differently now. Think six months before that, and six months before that. Now project this into the future. Where will you be in six months? Will you know more than you do now? Will you approach solving problems differently than you do now? If you’re a good software developer, you will never get it “right”—you will always be better six months from now than you are today and know more than you know today. A rapid release cycle allows you to apply new learning, knowledge, and perspective as often as possible. Do your best today, and give yourself opportunities to do your best in the future as well.

Update (2/9/2011): I will no longer be giving this presentation. Instead, SXSW has invited me to curate a Workshop on Big Data and APIs for PHP Developers. While I would have really enjoyed giving my Zend Framework talk, this new Workshop is shaping up to be an excellent session. The Workshop’s speakers will be Laura Thomson, Eli White, Julie Steele, Dennis Yang, and David Zülke. I’ll update my blog with more details later.

Atom Syndication Format

Most of VPR’s web content is currently stored in a proprietary content management system (CMS). The first step was publishing the needed content from the CMS out into an open format. VPR’s Dan Allen published from the CMS Atom feeds of the various content we would need for the new homepage.

PHP and Zend Framework

Once we had the needed Atom feeds, we created a Zend Framework web application to import these feeds. Components such as Zend_Feed_Reader made the job easier. The weather data comes from the National Oceanic and Atmospheric Administration’s (NOAA) National Weather Service’s National Digital Forecast Database XML/REST Service. The market data comes from the Google Finance API.

CouchDB

All of the data (except for weather, which is pulled directly with a bit of caching) is stored in CouchDB. Since we’re storing documents with varying metadata (i.e. Atom entries) choosing a document-oriented database made a lot of sense. CouchDB’s map/reduce views make for very efficient queries. Its RESTful HTTP API provides a lot of options for scaling and caching. We’re caching documents within the Zend Framework application and conditionally requesting these documents from CouchDB with ETags when a cache is available. The current cache is simply file-based but we’re considering using Memcached for even better performance. On a related note, the homepage itself also supports conditional HTTP requests.

Apache and nginx

We had the pleasure of working with another great Vermont company, ClearBearing, on this project. ClearBearing handles the infrastructure layer for VPR.net. The current website was (and still is) served up by Apache. ClearBearing already had nginx in place as a reverse proxy to handle caching. Since we weren’t replacing the entire CMS we needed a way for the existing CMS and this new application to coexist. We decided to host the new application separately (still administered by ClearBearing) and reverse proxy requests for certain URIs (primarily the homepage) to the new application. This provides a clean separation between the new application and the existing CMS while still allowing for them to be hosted on the same domain from an end-user perspective.

Licensing

You’ll notice that all of the standards used are open standards and all of the technologies used are free and open source software. Additionally, all of the code we have written for VPR is licensed to them under the permissive New BSD License. This means that VPR is free to use this code however they want, study and modify the code, and redistribute the code as-is or modified. They can do all of this without paying additional licensing fees.

Design

While this post is primarily about the technology behind VPR’s new homepage, I should mention that Found Line’s Jason Pelletier designed the new homepage and implemented all of its HTML and CSS. We worked closely with Jonathan Butler and John Van Hoesen, Vice President for News & Programming, to make sure the new design meets the needs of website visitors and the organization.

Next Steps

The launch of this new homepage was just one iteration with many more to come. As Jonathan Butler mentioned in his blog post, VPR has plans to further improve online services for their listeners. Look for a redesigned VPR Classical page soon. There are also plans for better mobile access to VPR and VPR Classical programming. Fortunately much of the work that has been done can be leveraged to create additional online services for VPR’s listeners.

A special thanks for the support of VPR’s listeners—you made this new homepage possible! If you have questions, comments, complaints, or suggestions about the new homepage then please contact VPR directly with your feedback (although you’re welcome to comment here as well).

Zend Framework is a free/open source web application framework. It can be used either as a component library or as a full-stack Model–View–Controller (MVC) framework. As compared to its 1.x counterparts, Zend Framework 2.0 is easier to learn, trivially simple to extend, and more performant. It is also easier to use just specific parts of the framework as needed. We will explore the many features of Zend Framework 2.0 including its tooling, functional testing, form, database, pagination, date, markup, navigation, and MVC components. Zend Framework 2.0 takes advantages of several new features in PHP 5.3 including closures/lambdas, namespaces, and late static binding. We will explore some of these new features to understand why PHP 5.3 is a requirement for Zend Framework 2.0 and how you can leverage these new features within your application itself. An example web application will be provided that you can use as a reference when building your own Zend Framework web application.

For those wondering, Zend Framework 2.0 is not out yet but SXSW is not until next March and Zend Framework 2.0 will most likely be released by then. The description above is based on the Zend Framework 2.0 Requirements and discussions on the Zend Framework contributors mailing list.

Over the last year, Magento has increased in popularity as a viable open source eCommerce platform for the mid to large scale online retailer. This rapid growth has lead to many questions on what has been fixed, what continues to be a problem, and how complex a system an eCommerce engine needs to be.

Have you used Magento? Are you considering using it for an upcoming project? Do you have a specific problem that Magento solves for you and would like to share your story? Join the roundtable and compare notes with others who have experience with Magento.

Meetings are open to the public via RSVP. You will have the chance to network and connect with fellow PHP developers.

To Participate:

1. Register on Eventbrite.
2. Sign up for the Burlington, VT PHP User Group list on Google Groups.
3. Forward this link to anyone else you feel would be interested in this meeting’s topics.

Next up for me was Derick Rethans’ Xdebug talk. Xdebug is an extremely useful tool for PHP developers. I’ve used its stack trace feature as well as its code coverage analysis via PHPUnit. I’ve also dabbled with its profiling capabilities. The session introduced me to several other Xdebug features with which I’d like to experiment.

After that I had the pleasure of seeing Matthew Turland’s talk on New SPL Features in PHP 5.3. New SPL data structures in PHP 5.3 include stacks, queues, heaps, priority queues, and sets. Matthew provided test code that compared the performance and memory usage of each these new data structures to that of using PHP’s array functionality.

I skipped the first afternoon session to take part in the Hack Track which happened to coincide with Zend Framework’s May Bug Hunt Days. I was granted commit access and directly committed my first bug fix, a small change to make HTTP headers case-insensitive.

Others stuck around to fix more bugs while I went to check out Bill Karwin’s Models for Hierarchical Data with SQL and PHP. Examples of hierarchical data include categories/subcategories, bill of materials, and threaded discussions. Bill talked about four main approaches to storing hierarchical data in SQL databases: adjacency list, path enumeration, nested sets, and usage of a closure table.

The adjacency list is a naive approach that almost everyone tries first. Basically, each entry knows its immediate parent. The problem with this approach is that querying deep trees can be very inefficient involving many joins. Path enumeration involves storing an enumerated chain of ancestors in each entry. This can be very efficient and take advantage of indexing. However, there is no referential integrity with this approach. The nested set approach seemed a bit complicated. I don’t feel I can explain it properly here, so you’ll have to check out Bill’s slides if you’re interested in how this works. The closure table approach made the most sense to me and didn’t seem overly complicated. Not only do you store each entry, but you also store every path including those from the parent node to each descendant, those from each ancestor to its child node, as well as a reflexive reference from the node to itself.

My final session of the day was Travis Swicegood’s Building Real-Time Applications with XMPP, the Extensible Messaging and Presence Protocol. If you’ve use Google Talk then you’ve used XMPP. As a web developer, the request and response pattern in HTTP is ingrained into my thinking. However, XMPP is a very different creature in that it keeps a socket open during what can be a lengthy exchange of messages. While I don’t think HTTP is going away anytime soon, real-time applications involving potentially large numbers of publishers and subscribers (e.g. Twitter) are becoming more prevalent and XMPP is well suited for this environment.

The field I was indexing, and subsequently using to find and delete documents, was a 40 character SHA-1 hash. While trying to track down the bug in my application, I discovered that only documents having a SHA-1 hash beginning with a digit were getting duplicated (in other words, were not being found when I tried to delete them) and that documents having a SHA-1 beginning with a letter were not getting duplicated (in other words, were being found and deleted).

A Stack Overflow post on searching numbers with Zend_Search_Lucene had the information I needed to fix the bug. First, I changed the hash field from a text field to a keyword field which prevented it from being tokenized (this, of course, required me to delete the existing index and re-index every document). Second, when searching on the hash field I replaced the default Text analyzer with the TextNum analyzer. These two changes seemed to do the trick, as I haven’t seen any duplicate search results after having run several index updates.

In the past you may have implemented consisted layouts in PHP using “includes” but, as you’ll see, layouts are much easier to manage than “includes”. The primary improvement over “includes” is that you can change the entire layout of your website without editing every single PHP script. This is because the layout decides where the content gets placed instead of each PHP script including the needed partials (e.g. header and footer). This is accomplished through an implementation of the Two Step View pattern.

If you’re using Zend_Tool then you can enable layouts using the command zf enable layout. This will create a layout view script, application/layouts/scripts/layout.phtml, and add the following line to the production section of your application/configs/application.ini file:

resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts/"

Zend_Layout has a front controller plugin that has two main jobs. First, it takes care of rendering the layout for us. Second, it retrieves what are called “named segments” from Zend Framework’s response object and assigns them as variables in your layout. A segment named “default” is assigned to the variable named content. Typically (unless you do something to override this) the “default” segment will contain the output of your individual controller actions. This means that you can render the content of your controller actions wherever you’d like in your layout view script by outputting the value of $this->layout()->content.

In the demo blogging application, Postr, I’ve also created a header layout view script, application/layouts/scripts/header.phtml, and a footer layout view script, application/layouts/scripts/footer.phtml. The header and footer layout view scripts are rendered by outputting the results of $this->render('header.phtml') and $this->render('footer.phtml'), respectively.

In my next post in this series I plan on taking a look at the Entry controller (application/controllers/EntryController.php) in the demo blogging application, Postr. We’ll explore its actions and corresponding view scripts. Zend_Form, Zend_Paginator, and modeling domain objects will be touched on briefly, but explored in more depth in later posts.

Model

Your domain objects. There is no Zend_Model since your domain logic is specific to your application. However, there are some best practices that have emerged in the Zend Framework community including Data Mappers (which I’ll talk about later).

See example Models in application/models/

View

The presentation layer. The default implementation uses PHP templates called view scripts. View script files have a default suffix of .phtml. There should be no domain logic in your view scripts. By default, there is one view script per controller action (we’ll see what that means shortly).

See example Views in application/views/

Controller

Connects the Model and the View. Each Controller contains one or more actions. The Controller’s job is to interpret input and pass it to the Model and also to provide Model data to the View.

See example Controllers in application/controllers/

By default, Zend Framework will route requests based on URI segments as follows:

:controller/:action[/:key/:value]

A few example URIs:

• foo/bar (foo controller, bar action)
• foo/bar/baz/shaz (foo controller, bar action, baz=shaz)

It is possible to customize this routing in pretty much any way conceivable but I’d suggest sticking with the default routing until you have a good handle on how it works.

In my next post in this series I plan on taking a slight detour so that we can explore a very useful component, Zend_Layout.