I manage a number of websites running on Zend Server, Zend's PHP application platform. I've started accumulating a number of patterns and tricks that make the deployments more successful, and which also allow me to do more advanced things such as setting up recurring jobs for the application, clearing page caches, and more.
Here's the scenario: you have code that will emit headers and content, for instance, a front controller. How do you test this?
The answer is remarkably simple, but non-obvious: namespaces.
Paul M. Jones has started an interesting discussion rethinking the MVC pattern as applied to the web, which he has dubbed Action-Domain-Responder (ADR). If you haven't given it a read yet, click the link and do that; this page will still be sitting here waiting when you return.
I agree with a ton of it — heck, I've contributed to it a fair bit via conversations with Paul. But there's been one thing nagging at me for a bit now, and I was finally able to put it into words recently.
Controllers — Actions in ADR — can be explained as facades.
That time of year again — wrap-up time. Each year, it seems like it's the busiest ever, and I often wonder if it will ever slow down. As usual, I'm restricting myself to primarily professional activities out of respect for the privacy of my family.
The short, executive summary:
Read on for the gruesome, month-by-month breakdown.
I've been using IRC regularly for the past six to nine months, in large part
due to the growing ZF community on the Freenode
#zftalk channel (unfortunately, I simply don't have time to be in that
particular channel any more, but you can generally find me in
but also to keep in contact with other peers, friends, and colleagues.
One difficulty, however, is keeping productivity high while staying on IRC. To me, the ultimate client would provide me notifications when somebody mentions my name or a watch word — allowing me to read the channel at my leisure, yet still respond to people in a timely fashion.
Chris Hartjes today was on a quest for a "find in project" feature for Vim. "Find in Project" was a feature of Textmate that he'd grown accustomed to and was having trouble finding an equivalent for.
The funny thing is that Textmate is a newcomer, and, of course, vim has had such a feature for years. The thing to remember with vim, of course, is its unix roots; typically if you know the unix command for doing something, you can find what you need in vim. In this case, the key is the vimgrep plugin, which ships in the standard vim distribution.
I've been playing around with Git in the past couple months, and have been really enjoying it. Paired with subversion, I get the best of all worlds — distributed source control when I want it (working on new features or trying out performance tuning), and non-distributed source control for my public commits.
Github suggests that
when working with remote repositories, you turn on the
autocrlf option, which
ensures that changes in line endings do not get accounted for when pushing to
and pulling from the remote repo. However, when working with
actually causes issues. After turning this option on, I started getting the
error "Delta source ended unexpectedly" from
git-svn. After a bunch of aimless
tinkering, I finally asked myself the questions, "When did this start
happening?" and, "Have I changed anything with Git lately?" Once I'd backed out
the config change, all started working again.
In summary: don't use
git config --global core.autocrlf true when using
My good friend, Rob, hosts my site for me, in return for helping with server maintenance. After being on Gentoo for the past three years, though, we decided it was time to switch to something a little easier to maintain, so last night we wiped the system partitions and installed Ubuntu server.
I'll say this: the setup is much faster! However, we had a few gotchas that surprised us — it didn't setup our RAID array out-of-the-box, which led to a good hour of frustration as we tried to verify that the install wouldn't wipe it, and then to verify that we could re-assemble it. (We succeeded.) Additionally, we second-guessed a few things we shouldn't have, which led to needing to back out and reconfigure. But what was over a 12 hour install with Gentoo we accomplished in a matter of a few hours with Ubuntu server — so it was a huge success that way.
Unfortunately, our mysqldump of all databases… wasn't, a fact we discovered only after importing it into the new system. I ended up losing my blog database and PEAR channel database. Fortunately, the PEAR channel has not changed at all in the past year, so we had an old backup that worked, and I had a snapshot of my blog database from three weeks ago I was able to use. As a result, there are a few missing entries, but for the most part, all works. If you commented on one of those missing entries, my apologies.
Now that the install is done, I'm also finalizing some design changes to my blog — it's time to leave the black and white for more colorful grounds. Look for a revamp in the coming weeks!
Full disclosure: I am employed by Zend to program Zend Framework. That said, the following is all my opinion, and is based on my experiences with Zend Framework, as well as answering questions on a variety of mailing lists and with other OSS projects (PEAR, Solar, and Cgiapp in particular).
One of my biggest pet peeves in the OSS world is vague bug/issue reports and feature requests. I cannot count the number of times I've seen a report similar to the following:
<Feature X>doesn't work; you need to fix it now!
If such a report comes in on an issue tracker, it's invariably marked critical and high priority.
What bothers me about it? Simply this: it gives those responsible for maintaining Feature X absolutely no information to work on: what result they received, what was expected, or how exactly they were using the feature. The reviewer now has to go into one or more cycles with the reporter fishing for that information — wasting everyone's time and energy.
Only slightly better are these reports:
<Feature X>doesn't work — I keep getting
<Result X>from it, which is incorrect.
At least this tells the reviewers what they reporter is receiving… but it doesn't tell them how they got there, or what they're expecting.
So, the following should be your mantra when reporting issues or making feature requests:
Ivo already pointed this out, but I want to point it out again: Boy Baukema writes a very nice entry regarding backwards compatibility on the ibuildings.nl corporate blog.
Backwards compatibility (BC) is a tricky thing to support, even when you strive hard to, as Boy puts it, "think hard about your API" prior to release. Somebody will always come along and point out ways it could have been done better or ways it could be improved. I've had to wrestle with these issues a ton since joining the Zend Framework team, and while it often feels like the wrong thing to do to tell somebody, "too little, too late" when they have genuinely good feedback for you, its often in the best interest of the many users already using a component.
I had the pleasure of meeting Boy last year when visiting the ibuildings.nl offices, and he's got a good head on his shoulders. He does a nice job outlining the issues and a number of approaches to BC; if you develop a project for public consumption, you should definitely head over and read what he has to say.