Within the Zend Framework 2 repository,
I recently performed a conversion from DocBook 4 to 5.
The latter is a more modern version of the toolchain, and offers a somewhat
simpler syntax and workflow. For example, you no longer need to track how many
levels deep you are in your chapter sections — you simply use a
One of the nicer changes is that you do not need to specify a doctype any more;
you simply declare XML namespaces on your root elements and continue merrily on
your way. This actually allows us to remove some actions in our build process,
and makes validation much simpler.
Interestingly, for DocBook5 being available in beta since 2005 and an official standard since 2009, there is very little material on migrating from DocBook 4 to 5.
A number of programming design patterns look very similar. One of these is the Proxy pattern, which, at first glance, can look like a number of others: Decorator, Flyweight, even plain old object extension. However, it has its own niche, and it can provide some incredible flexibility for a number of programming scenarios.
In the past six weeks, I've delivered both a webinar and a tutorial on Zend Framework 2 development patterns. The first pattern I've explored is our new suite of autoloaders, which are aimed at both performance and rapid application development — the latter has always been true, as we've followed PEAR standards, but the former has been elusive within the 1.X series.
Interestingly, I've had quite some number of folks ask if they can use the new autoloaders in their Zend Framework 1 development. The short answer is "yes," assuming you're running PHP 5.3 already. If not, however, until today, the answer has been "no."
Zend Framework has offerred a code generation component since version 1.8, when
we started shipping
Zend_CodeGenerator largely mimics PHP's
Reflection API, but does the opposite: it instead generates code.
Why might you want to generate code?
zf.shto generate controller classes and action methods).
Zend\CodeGenerator in the ZF2 repository is largely ported from Zend Framework
1, but also includes some functionality surrounding namespace usage and imports.
I used it this week when working on some prototypes, and found it useful enough
that I want to share some of what I've learned.
I've been working on a proposal for including service locators and dependency injection containers in Zend Framework 2.0, and one issue I've had is trying to explain the basic concept to developers unfamiliar with the concepts — or with pre-conceptions that diverge from the use cases I'm proposing.
In talking with my wife about it a week or two ago, I realized that I needed an analogy she could understand; I was basically using her as my rubber duck. And it turned out to be a great idea, as it gave me some good analogies.
Chris Shiflett has asked the question, why don't people blog anymore? In this age of real-time streams and dead-simple status updates, blogs often feel like the uncared-for step-child or a website; indeed, many folks are trading their blogs for pages that simply track their various lifestreams (tweets, facebook status, flickr images, and more).
While this sort of thing is trendy and interesting, it also sucks:
I've been investigating ways to incorporate third-party repositories and
libraries into my Git projects. Subversion's
svn:externals capabilities are one compelling feature for that particular
VCS, and few, if any, other VCS systems, particularly the DVCS systems, have a
truly viable equivalent. Git
submodules aren't terrible, but they assume you
want the entire repository — whereas SVN allows you to cherry-pick
subdirectories if desired.
Why might I want to link only a subdirectory? Consider a project with this structure:
docs/ api/ manual/ html/ module_specs/ library/ Foo/ ComponentA/ ComponentB/ tests/ Foo/ ComponentA/ ComponentB/
On another project, I want to use ComponentB. With
svn:externals, this is easy:
and now the directory is added and tracked.
With Git, it's a different story. One solution I've found is using
git-subtree, an extension to Git. It
takes a bit more effort to setup than
svn:externals, but offers the benefits
of easily freezing on a specific commit, and squashing all changes into a
Jon Whitcraft recently had some questions about how to use it, and I answered him via email. Evidently what I gave him worked for him, as he then requested if he could post my guide — which you can find here.
Last year, a new conference launched, Brooklyn Beta. The buzz I heard about it from attendees was amazing; words like "inspiring," "intimate," and "energizing" were all used to describe the experience. I found myself wishing I'd made time in my schedule to attend.
Fast forward a few months, and a new conference has been announced, the PHP Community Conference. It has similar goals to Brooklyn Beta: create a conference where we can talk about the language we love so passionately.
ZF2 development is ramping up. We've been at it for some time now, but mostly taking care of infrastructure: converting to namespaces, re-working our exception strategy, improving our test suites, and improving our autoloading and plugin loading strategies to be more performant and flexible. Today, we're actively working on the MVC milestone, which we expect to be one of the last major pieces necessary for developers to start developing on top of ZF2.
A question I receive often is: "How can I contribute to ZF2?"
Consider this your guide.
You've heard about PHP namespaces by now. Most likely, you've heard about — and likely participated in — the bikeshedding surrounding the selection of the namespace separator.
Regardless of your thoughts on the namespace separator, or how namespaces may or may not work in other languages, I submit to you several reasons for why I think namespaces in PHP are a positive addition to the language.