The short, executive summary:

• One trip to Israel
• One trip to The Netherlands
• One trip to California's Bay Area
• One trip to Atlanta, GA
• Three minor releases of Zend Framework
• Seven webinars, six for zend.com and one for Adobe
• Three conferences attended as a speaker, including:
  • One six-hour workshop
  • One three-hour tutorial (as a co-presenter)
  • Four regular sessions
  • Two panel sessions (one scheduled, one for an uncon)
  • Two uncon sessions (one as a co-presenter)
  • One foul-mouthed Pecha Kucha talk
• Ten Burlington, VT PHP User's Group meetings attended; I spoke at many
• One Bug Hunt week organized
• Two books reviewed as a technical editor
• Six articles for DevZone
• 50 blog entries (including this one)

Read on for the gruesome, month-by-month breakdown.

January and February

I started coding Zend_Form in earnest in January, and had a preview ready for testing mid-month. The pace continued into February, as I addressed user feedback and issues, and continued working feverishly towards what would become Zend Framework's 1.5.0 release.

I also answered many questions for and had many discussions with Cal Evans relating to his "Guide to Programming Zend Framework".

March

I gave my first webinar of the year early in March, on the subject of Zend_Form; it was very well attended, but unfortunately there was an issue recording the sound, so the recording was never released. After two more failed attempts at re-recording, we gave up. I apologize to all who have wanted to view it.

While working towards the 1.5.0 release, Ralph Schindler and I also finished up final touches on Zend_Layout and the various "placeholder" view helper implementations.

On 17 March 2008, we released Zend Framework 1.5, our first minor release following 1.0.0.

I started blogging tips and tricks for 1.5, and also writing articles for DevZone during March, and had tremendous amounts of feedback. In fact, one blog post, on "Login and Authentication", is still one of the most trafficked on my blog after 9 months.

I also began what I envisioned as a series of Vim posts, but, alas, it has resulted only in two.

April

Following the 1.5 release, I did weekly posts for a month or so covering various features of Zend Framework, including Front Controller plugins, Action Controller helpers, and View helpers. Towards the end of the month, the entire team participated in a Q&A webinar to discuss the 1.5 release.

May

At the beginning of the month, I released the last in my series of 1.5 tutorials on DevZone, covering Form decorators. This has saved me countless hours on IRC and in the mailing lists explaining how this aspect of forms work.

During this month, we also finally announced that Zend Framework would be partnering with Dojo to provide an out-of-the-box RIA solution. I began work identifying the various integration points and creating proposals for implementation. I also did a Q&A webinar with the Dojo team outlining the proposed integration.

At the end of the month, the ZF team reorganized the subversion repository to allow for an "Extras" repository, and also to ensure that projects originating in the laboratory or extras and migrating to the standard library retain all history. Even with the big notices we put on the ZF site, articles on DevZone, and posts on various blogs, we still get questions on this seven months later. Let this be a lesson to you: plan your repositories for any contingency as early as you can!

June

I started June with a trip to Israel, to visit the Zend offices. I met up with Andi in Newark, and we flew from there to Israel several rows apart in coach. One of the best meals I've ever had was after we landed and he invited me to his sister's place for dinner, and we dined on chicken marinated in home-pressed olive oil and fresh herbs, hummus, and pitas baked with fresh oregano. The rest of the week was spent in the office, in endless meetings.

Four days after returning from Israel, I flew to Amsterdam for the Dutch PHP Conference, to which I'd been invited to speak. My good friend Remi took the train up to Amsterdam to meet me the day I flew in, and we walked and walked and walked around the city, until dinnertime. Stefan Koopmanschap then met us for a lovely dinner, and I returned to the hotel to finish screenshots for the six-hour workshop on Zend Framework I was presenting the next day. The entire conference was wonderful, and I met many fantastic people, including Stefan Priebsch, Lorna Jane Mitchell, Andries Seutens, and many, many more -- plus many familiar faces, such as Sebastian Bergmann, Derek Rethans, Mike Van Dam, Felix de Vliegher, and Marco Tabini.

On my blog, I started raising the question of how we will refer to Abstract classes and Interfaces in PHP 5.3, but I think my arguments went largely unheard and/or misunderstood.

The last half of the month was spent working on both Dojo integration with Zend Framework (a task that turned out fairly easy, in large part due to some wonderful guidance from Pete Higgins), and preparing Zend_Test_PHPUnit for inclusion in Zend Framework 1.6.

July

I think I'll remember July as the month of the neverending release cycle.

August

On 8 August 2008, PHP 4 officially died. I thought about drinking a toast for about 3 seconds, forgot about it, and finished my beer.

The following Monday, we released the second release candidate of Zend Framework 1.6.0.

August, too, became part of the month of the neverending release cycle.

September

Finally, on 2 September 2008, we released 1.6.0 into the wild. My contributions included, as noted earlier, Dojo integration, PHPUnit integration, and code assistance on our Captcha solution and file upload support.

The next day, I gave yet another webinar on Zend Framework and Dojo integration, but finally actually had some code samples and working demos to show off, soundly quieting the claims of vaporware. I also started learning about Dojo release builds, under the tutelage of Pete Higgins.

Mid-month saw the fourth annual Zend/PHP Conference, this time in Santa Clara. I was involved in a marathon of seven different sessions over three days. I've rarely been so exhausted, and it's a wonder I remember anything following -- but I had a wonderful time with the PHP community following, including Jon Whitcraft, Rob Allen, the ibuildings crew, and more.

I also finally got to meet David Sklar, to whom I owe the fact of my first public speaking engagement at the first ZendCon.

Following ZendCon, there were announcements that two colleagues at Zend I respect highly were leaving for new opportunities: Mark de Visser left to join Sonatype as its CEO, and Cal Evans left to head ibuildings' new Center for PHP Expertise. I wish them both luck in their new endeavors.

October

I helped Wade Arnold complete testing of Zend_Amf as we prepared for the Zend Framework 1.7.0 release, and learned a fair deal about Flex in the process.

During this time, I also completed a technical review of Zend Framework in Action. Rob Allen and Nick Lo had contacted me earlier in the year, but I'd been unable to commit to it. In July, I agreed, only to get sucked into the neverending release cycle. Fortunately, in October I had time to complete the review. The book is very well written and organized, and I can't recommend it highly enough. I was able to give some constructive feedback and have some dialog with Rob that, hopefully, helped clarify a few areas of Zend Framework, and will hopefully help their readers.

For the 1.7 release of Zend Framework, I worked on performance benchmarking, profiling, improvements, and a best practices guide.

Late in the month, I delivered a webinar with Lee Brimelow for Adobe to showcase the upcoming AMF support in Zend Framework.

November

The last few days of October and first week of November, I organized a bug hunt week for Zend Framework, culminating in a Bug Hunt Day event held and organized by PHP Belgium and phpGG (The Netherlands). We closed out close to 150 issues over the course of the week and a couple dozen during the Bug Hunt Day, and got many contributors started on the path of professional bug squashing enlightenment.

The second week of November, I flew down to Atlanta, GA, to attend php|works.. err, php|works/pyworks. First off, a huge thank you to Elizabeth Naramore, who helped me fairly last minute to make sure I had a room to stay in. While there, I presented my Dojo and Zend Framework talk, but with some updated content. Of course, every presenter's nightmare occurred, and I had to reboot my laptop mid-stream. I surprised myself, and, I think, the attendees by actually being able to continue speaking while we waited for my machine to reboot.

I also presented a Pecha Kucha talk -- I re-branded the phrase as "Pikachu" a couple weeks earlier (a reference to the iconic character in Pokemon, a game I play with my daughter), and that phrase has, for better or for worse, stuck. My talk was on how to be banned from an open source project, and I swore entirely too much. It was a nice release, however, as I try to be politic in public usually, and sometimes just need to rant.

I got to see a ton of old and new friends alike while there -- former Zenders Mike Naberezny and Paul M. Jones, Keith Casey, Matthew Turland, Ivo and a bunch of the ibuildings crew, Pollita (sorry, I have to stop linking everyone now...), Sebastian... basically, a ton of the usual suspects. I also met a lot of new people, many of them introducing themselves as ZF users; I appreciate all of you introducing yourselves, as you are the reason I code.

The following Monday, 17 November 2008, we released Zend Framework 1.7.0, timed to coincide with the the Adobe MAX conference, as AMF support was our major story for the release. Zend_Amf has generated tremendous buzz in both the PHP and Flash/Flex communities, due to the simplicity and robustness of its design. This release also marked the first release to include the extras repository -- which now ships with community-contributed JQuery support.

December

Chris Shiflett and Sean Coates organized this year's PHP Advent Calendar, and solicited entries from a select group of PHP community members a week in advance. I didn't volunteer to contribute for the first week, but managed to get mine in on the first day... only to see it appear the very next. Hopefuly, my guide to responsible contributions will help those wondering how to report and/or fix bugs in open source projects.

I started blogging more, in part due to more free time in the evenings (it's nice when the kids go to bed at a reasonable hour!), and in part due to finally putting a number of ideas into a blogging "backlog" so that I could pick up and post when I had time. From this, I added an entry on mumbles/irssi integration, autocompletion with ZF and Dojo, created a simple pubsub implementation for PHP, and started a series of posts on how to architect models (and some concrete tips for doing so). I have more posts in December than I have in several other months combined.

Reflection

This past year, I became much more involved with both the Zend Framework and greater PHP communities, and feel I have enriched my life with many wonderful new friends -- some local, some global. I feel truly fortunate to be working in a job I love, contributing to a project that helps others do the jobs they love, and part of such an accepting and vibrant group of people.

Looking back, I travelled less, though because most of it was in a five month period, it felt like more. On that note, I vow never to do back to back trips across the big pond, as it was incredibly exhausting.

Looking ahead to 2009

I have several things to look forward to already in 2009. I'll be continuing my series of posts on models. In February, I will have an article published in a print magazine for the first tiem. I'll be speaking at PHP Quebec in March, presenting two sessions and sitting in on a panel. I hope to speak at several other conferences, and potentially write more articles and tutorials. Overall, I want to contribute more to the ecosystem of best practices in PHP, particularly in the areas of testing and deployment strategies.

I hope this post finds you in good health and spirits, and that you have a fantastic start to the new year!

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.

I've tried a variety of IRC clients over the months, starting with Pidgin (poor interface for IRC), mirc (huge difficulties figuring out the UI), xchat (not bad, but seemed a bit heavy), Chatzilla (I liked the interface, but once you got many tabs going, it was unwieldy switching around between them; I also hated that Firefox dying or restarting caused Chatzilla to do likewise), and now irssi.

So far, irssi is the best I've tried -- I can run it in screen, allowing me to keep it open as long as my machine is running. The interface is reasonable, and cleanly keeps channels separate from private messages. Opening, closing, and manipulating windows is easy. And it's highly scriptable... including in a language I actually use! The perl bindings are top notch, though sometimes cryptic. What's important, however, is that there are plenty of examples out there if you want to try doing something. So, I figured I'd write up a quick plugin to trigger notifications.

I've been using a number of different notification servers for linux, and personally like both gnotify and mumbles. Both are very lightweight and offer network protocols for triggering notifications.

I first tried using gnotify. It has a very, very simple TCP protocol, and I've had success creating messages from the shell, PHP, and perl. Unfortunately, for some reason, using it in irssi displayed some odd behavior: I'd lose the cursor and the ability to enter input from the time a notification triggered until it completed (i.e., the notification disappeared). Forking the process did not appear to help.

So, I decided to try out mumbles. Mumbles is written in python, and has themeable notifications -- already a plus. It runs via dbus by default, but can also optionally spawn a server that implements the Growl protocol -- making it accessible for any process to send notifications. Additionally, it has a command-line utility for triggering notifications -- by default over dbus, but optionally by contacting the growl server, if running.

Growl's protocol is a bit involved, and I didn't want to spend too much time on this. So, I did a quick, dirty hack: I used backticks to trigger the CLI utility. And it works fantastically -- no delays whatsoever. Here's the code:

# $HOME/.irssi/scripts/mumbles.pl
use strict;
use Irssi;
use Irssi::Irc;
use vars qw($VERSION %IRSSI);

$VERSION = '0.1.0';
%IRSSI = (
    authors     => \"Matthew Weier O'Phinney\",
    contact     => 'matthew@weierophinney.net',
    name        => 'Mumbles notifications for irssi',
    description => 'This script enables mumbles notifications for irssi',
    license     => 'New BSD',
	changed     => \"2008-12-10\"
);


sub mumbles_sig_printtext {
  my ($dest, $text, $stripped) = @_;

  if (($dest->{level} & (MSGLEVEL_HILIGHT|MSGLEVEL_MSGS)) && ($dest->{level} & MSGLEVEL_NOHILIGHT) == 0)
  {
    if ($dest->{level} & MSGLEVEL_PUBLIC)
    {
      mumbles($dest->{target} . \" : \" . $text);
    }
  }
}

sub mumbles {
    my $message = shift;
    my $response;

    $message =~ s/[^!-~\s]//g;

    `/usr/bin/mumbles-send -g 127.0.0.1 -s \"IRC\" \"$message\"`;
}

Irssi::command_bind 'mumbles' => sub {
    my ($message) = @_;
    mumbles($message);
};

Irssi::signal_add({
  'print text'    => \&mumbles_sig_printtext
});

This triggers a notification for any "highlight" event -- basically, anytime anybody "says" my name in a channel, or mentions a keyword I've marked for highlighting. Additionally, I created a "mumbles" command so that I can send test messages (usage: "/mumbles "this is the message..."). You could certainly bind to other events, such as topic changes, joins, parts, etc -- I'm only interested in highlight events.

You may note the regexp in there. One thing I discovered was that most messages contained control and non-ascii characters that often resulted in unreadable notifications, as well as some nasty messages reported by irssi. The regexp removes anything not in the ascii character set or the set of whitespace definitions prior to emitting the notification.

Something else I needed to do was configure compiz to ensure that the notifications actually popped above my windows. I did this by going into the compiz configuration manager, selecting "General Options", selecting the "Focus & Raise Behaviour" tab, and modifying the "Focus Prevention Windows" to read as follows:

(any) & !(class=Mumbles)

To test it, I placed the script in $HOME/.irssi/scripts/mumbles.pl, and then, in irssi, executed "/load mumbles.pl".

Once I had it to my liking, I symlinked it into my $HOME/.irssi/scripts/autorun/ directory, allowing it to run as soon as irssi loads. I can now have irssi running in a screen session, or minimize the terminal, and get notifications -- keeping me productive and informed at the same time.

UPDATED 2008-12-12: Added information on how to load the script, as well as fixed the location to the autorun directory. Thanks, @sidhighwind!

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.

There are a variety of resources on vimgrep. The vim documentation includes a chapter on it, and a quick google search on the subject turns up some nice tutorials immediately. If you've ever used grep, the syntax is very straightforward:

vimgrep /{pattern}/[g][j] {file} ...

The "g" option indicates that all matches for a search will be returned instead of just one per line, and the "j" option tells vim not to jump to the first match automatically. What does the "g" flag really mean, though, and how are searches returned?

Vimgrep returns search results in what's known as a "quickfix" window, and this is where the vimgrep documentation falls apart... it doesn't explain what this is, or link to it (which would be a nice indication that it actually has a separate topic for this).

The Quickfix window is a pane that shows a search result per line. Each line shows the file that matches, the line number, and the contents of that line:

/home/matthew/git/bugapp/application/controllers/helpers/GetForm.php|10| * @var Zend_Loader_PluginLoader

You can't do much from this window; it simply serves as a visual indicator of what file you're currently looking at from the list. However, in the main window, you can start iterating through the results one at a time, using a subset of the Quickfix commands. As a quick summary:

• :cc will move to the next match in the list
• :cn will move to the next match in the list
• :cp will move to the previous match in the list
• :cr will rewind to the first match in the list
• :cla will fast forward to the last match in the list

When done, you can simply close the Quickfix window/pane, and continue working.

I should note that vimgrep is cross-platform. On *nix-based systems, it defaults to using the native grep command, but it also contains an internal (slower) implementation for use on operating systems that do not provide grep by default. You may also map the command to alternate implementations if desired.

I personally use this feature most with the project plugin. Project maps vimgrep to two different commands: <Leader>g and <Leader>G. The first will grep all files in the current project at the current level; the second does the same, but also recurses into subprojects. This is an incredibly easy way to refactor code, particularly for name changes.

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 git-svn, this 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 git-svn.

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!

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:

• What is the minimum code necessary to reproduce the issue or show the desired API?
• What is the expected result?
• What is the actual result?

What makes up a good issue report?

A good issue report has to contain the above three points, plain and simple. Without this information, a reviewer simply does not have the tools with which to properly deal with the issue.

Reproduce code

Quite often, you'll find that an application breaks. It is up to you to find the root cause of that breakage: what minimal amount of code do I need to write in order to cause the breakage to occur? Sometimes this will require a little digging -- you may have a result that is unexpected, but it may be a symptom of something breaking earlier.

For example, in working on Zend_Form in the past couple weeks, I had a number of issues reported against how the new MultiCheckbox element was working. One issue noted that populate() was not properly populating the checkboxes.

When pressed for reproduce code, the reporter provided the $_POST array with which they were trying to populate the form:

$_POST = array(
    'foo' => array(
        0 => array(0 => 'bar'),
        1 => array(0 => 'baz'),
        2 => array(0 => 'bat')
    )
);

In looking at it, I knew immediately that it was related to another issue that had been reported. In that issue, the reporter noted that the input elements rendered by Zend_Form for MultiCheckbox elements had redundant array notation:

    <input type=\"checkbox\" value=\"foo\" name=\"foo[][]\" value=\"bar\" />

In the former case, we're seeing a symptom of the latter case: the redundant array notation was causing a form submission that simply could not populate the element. If the reporter of the former case had looked at the form used to send the $_POST data they posted in the tracker, either they likely would have noticed the similar issue already reported in the tracker -- or I, as the reviewer, would have been able to quickly mark the bug as a duplicate.

Regardless, the main point is this: using the value of a POST request to reproduce an issue is not doing your homework. You need to look for the minimal code necessary to reproduce the issue, and the value provided in $_POST is typically a symptom of an issue that has already occurred.

Another rule of thumb with creating reproduce code is to keep the environment minimal. Try writing up fresh code in a scratchpad that you can run over and over again until you get the result that you're trying to report. This does a few things: it helps simplify the use case causing the issue, and it often will help you track down exactly where things begin to break. Sometimes, and I can attest to this, it helps you find places where you're doing things wrong in your own code in the first place, alleviating the need entirely to submit a report.

What does the reviewer do with this code? Well, a good developer will use it as a test case in the unit test suite -- which is another reason to keep the code down to the minimum required to reproduce the issue. This code will often end up in the test suite in order to document the issue report -- as well as to prove, once a solution is in place, that the issue has been resolved.

The above advice is useful even when reporting a feature request, this information is useful. The reviewer then gets an idea of the desired API, and they can write a test case against it.

Expected Results

In addition to the reproduce case, you should provide the expected results. These show clearly your expectations of the code. The reviewer can use this information in several ways:

• In the test suite, the reviewer can use the expected results in assertions to verify the issue (or prove that it is now corrected)
• To show where the reporter has flawed assumptions. In some cases, the expectations of the code are different than the documented assertions, and the reviewer can then point out where the differences lie -- which helps to educate the reporter in proper usage of the code.
• In the case of a feature request, this will indicate how the reporter expects the new feature to behave. The reviewer can then use that expectation as an assertion in the test suite.

Actual Results

The actual results are important as they contrast against the expected results, showing where the breakage is. If the reviewer cannot recreate these results, then it likely means that the reproduce code provided is not the actual code needed to reproduce the issue, or it may mean that environmental differences -- differences in OS or PHP version, for instance -- may be a factor in recreating the issue.

In the case of a feature request, you could omit the actual results, as there won't be any.

Always search for your issue or feature request

Finally, one additional mantra to add to your repertoire: search the issue tracker and/or mailing lists before reporting an issue or requesting a feature. I cannot tell you how many bugs I've closed as duplicates, or how many times I've had to respond to an email with the phrase, "this is a known issue." It pays to do your homework: search and see if others have made the same request. In many cases, you may actually find a solution to your issue posted by others -- either a way to extend a class to get the behaviour you're expecting, a patch to the software, or even a note regarding what public release or snapshot contains a fix. There's no reason to waste people's time by reporting a known issue.

The best time to search for your issue, believe it or not, is after you've done the other steps. Until you know exactly what code reproduces the issue, and have clearly defined your expectations and the real results, it can be difficult to identify when your issue matches another.

In Conclusion

• What is the minimum code necessary to reproduce the issue?
• What is the expected result?
• What is the actual result?
• Have you searched for similar requests in public forums?

If you can start answering the above questions before posting your issues, you'll start receiving more detailed and useful responses from those reviewing your issues or feature requests, and reduce the number of "I don't understand" or "I need more information" responses. Guaranteed.

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.

My first idea was to add the directive 'Header add X-Server-Ip "%{SERVER_ADDR}e" in my httpd.conf. However, due to the nature of our load balancer, Apache was somehow resolving this to the load balancer IP address on all machines of the cluster -- which was really, really not useful.

I finally stumbled on a good solution, however: you can set environment variables in apachectl, and then pass them into the Apache environment using the PassEnv directive from mod_env; once that's done, you can use the environment variable anywhere.

In my apachectl, I added the line "export HOSTNAME=`hostname`". Then, in my httpd.conf, I added first the line "PassEnv HOSTNAME", followed by the directive 'Header add X-Server-Name "%{HOSTNAME}e"'. Voila! I now had the hostname in the header, which gave me the information I needed for debugging.

Here's the short version:

• One trip to Belgium and The Netherlands.
• Two trips to Israel.
• Two trips to Atlanta, GA (not counting the return trip from Europe, when I was stranded for a day due to storms in the Northeast).
• Three different user groups attended, with three presentations.
• One major Zend Framework release
• One PEAR release.
• One podcast.
• One webinar.
• One book published.
• One conference attended.

What follows is my month-by-month breakdown:

January

I finished up the last of my three chapters for The PHP Anthology, 2nd Edition, and promptly used my advance to buy the family a Wii.

I was also introduced to Ivo Jansch through work, and had him wow me with one of the ibuildings products.

February

Mid-month, my boss at Zend, Boaz, got the go-ahead to use the ibuildings WDE platform to build our new website CMS; part of the plan would include training at the ibuildings home office in Vlissingen, NL... which meant I had to get my passport pronto.

Towards the end of the month, I was invited to BostonPHP to present building a simple Zend Framework CRUD application, along with Chuck Hagenbuch of the HORDE project. While there, Nate Abele heckled me, and then joined Chuck and myself for an impromptu framework panel; a good time was had by all.

March

I flew to Brussels, Belgium, where I met my supervisor, Boaz, so we could go to Vlissingen. We spent the day in Brussels, walking around and visiting such sites as the Cathedral of St. Michael, La Grand Place, and the Mannekin Pis.

Our visit to ibuildings was very productive, and I was very impressed by the team there; everybody was very knowledgeable and skilled. I presented a Zend Framework overview, as well as an abbreviated version of the Best Practices talk I'd given with Mike Naberezny at the 2006 ZendCon; the latter ignited a ton of questions and enthusiasm.

On returning home, I had a ton of work to do on the zend.com CMS, and this continued in spurts through November. The job was made much easier by the ibuildings WDE product.

I closed out a ton of MVC issues in the Zend Framework, and we released the first beta version late in the month.

April

At the beginning of the month, our landlord threw us for a loop and announced he was going to sell our apartment... meaning that we either had to step up our plans to purchase a home, or start looking for a new rental. Ultimately, we ended up looking for a rental, due to time constraints. The next two months would be highlighted with the look for a new place as well as countless showings of our apartment to potential buyers.

Mid-month, we packed up the family and flew down to Atlanta, GA, to visit my wife's family. While there, we were able to go to the Atlanta Zoo and see Mei Lan, their baby panda -- way cute!

May

Mid-month, we found a new place in Richmond, VT -- a small village about 10 minutes from Burlington, near where we originally lived when we first moved to Vermont.

During the first RC for Zend Framework, released at the end of the month, I introduced the ViewRenderer, a feature for auto-rendering views based on the current controller and action name -- a feature common to many frameworks. However, it ostensibly broke a ton of existing applications by being enabled by default -- not one of my more popular decisions. Since the 1.0.0 release, I've heard little grumbling about it, and it's now often cited as an ease-of-use feature -- go figure.

June

The first week of June, I flew to Tel Aviv, Israel, to start training people on the new CMS, as well as to work with our entire ebiz team to finalize the work plan for completing the CMS. It was, needless to say, my first time to Israel or the Middle East, and I was constantly confronted with culture shock. Europe was an easy transition to make, but Israel was completely foreign to me -- everything from the way people drove, to the architecture, to the food was different. Unfortunately, I arrived a day late due to a flight cancellation, and missed the tour of Jerusalem my supervisor had planned for all of us. However, he took me to the city of Yafa, an Arabic city where the Israeli's originally tried to settle before building Tel Aviv to the north. The architecture was amazing, as were the winding, narrow streets of the old city.

I was also told during this trip that Andi had requested transferring me full-time to the Zend Framework team. I would spend the next week or two weighing my options, and ultimately decided to do so.

A week after I returned, we moved into our new rental in Richmond. The kids love the new place, which has a bedroom for each of them, a yard, and porches on each entrance.

Somehow, I also found time to record my first (and so far only) PHP Abstract podcast.

July

We released Zend Framework 1.0.0 at the beginning of the month, marking our first stable release. While many still view it as incomplete, the overwhelming feedback has been positive, and we've had over 2 million downloads to date.

I accepted the transfer to the Zend Framework team, but the condition was made that I would stay part-time on the ebiz team until the new site was launched. This meant that the next 5 months were spent splitting my time between the two projects, often working late and on weekends to get work done.

Towards the end of the month, we took a long weekend camping in Vermont's Northeast Kingdom. The weather was unseasonably wet, but we persevered and had a great time. 5 days of offline time was definitely needed!

I also finally released the first stable version of File_Fortune on PEAR, over a year since I'd first proposed it. The package interfaces with mod_fortune files, allowing both the ability to read and write such files, with full binary compatability.

August

Not much to report in August, except work, work, and more work.

September

My ebiz supervisor, Boaz, flew me to Tel Aviv for a second time, this time to perform a "brain dump" for the rest of the team before I transitioned fully out of the team, and also to help setup our new data center and release procedures. This time, Boaz took me to Jerusalem himself during my last full day in the country. If you've never been to the city, you should definitely put it on your list of things to do before you die. With my degree in religion, the place was full of meaning for me, but it would be putting it lightly to say that religion is palpable in the air there. We visited the Wailing Wall, the Via Dolorosa, the Church of the Holy Sepulchre, and listened to the muezzins sing the call to prayer for the muslims. The tour was simply amazing.

A few days after I returned, I flew down to New York City for a special meeting of NYPHP, where Mark de Visser presented on various Zend products and initiatives, and I gave a Zend Framework overview.

A week after the NYPHP presentation, I did a zend.com webinar on the Zend Framework MVC layer.

October

October was the month of ZendCon. I presented a full-day tutorial on best practices and unit testing with Sebastian Bergmann and Mike Naberezny; despite the length and subject matter, we were SRO for most of the day.

I also did a main-stage presentation on Zend Framework's MVC components, directly following Terry Chay -- an intimidating situation at best. From the feedback I've seen, the presentation was well-received, and I had somewhere between 120 and 150 attendees -- phenomenal! (Even more amazing was how many people were familiar with MVC in general!)

One great thing about the conference was the fact that I got to network with a number of framework developers, both Zend Framework and otherwise, including Nate Abele of CakePHP as well as Paul M. Jones of the Solar framework. Many good conversations were had.

Late in the month, The PHP Anthology, 2nd Edition, my first published book as an author, was finally released!

November

I spent much of the month working on Zend_Layout, a much requested component that simplifies and automates Two Step Views in Zend Framework. I also started work implementing Zend_View Enhanced, a set of view helpers for making complex views with Zend_View possible.

I also started playing with Twitter a bit, and came up with a Zend_Service_Twitter proposal for interacting with the Twitter API via PHP.

And finally, the Sunday before Thanksgiving, we finally launched the new Zend.com site, which was well-received in the blogosphere.

December

A goal I've had for some time has been to form a PHP user group in the Burlington area. A friend of mine pointed out to me sometime this fall that there's actually already a Google Group formed; he and the original founder started planning a meeting for early December. I spoke at this inaugural meeting, presenting Zend Framework's MVC layer yet again; a good time was had by all, and a lot of enthusiasm for future meetings was generated.

I finished up Zend_Layout and Zend_View Enhanced with the help of Ralph Schindler, and got a new proposal up for Zend_Form, just in time for my holidays to begin -- 11 days with family and with little to no internet connectivity during a trip to Atlanta, GA for one of only a handful of Christmases I've spent without snow.

Summary

This year was incredibly busy -- three cross-seas trips, one cross-continent trip, a move, and several trips along the Eastern Seaboard; three user group presentations, and eight presentations over the course of the year; one conference; one move; one PEAR release; one podcast; one webinar; one book; and countless hours of programming.

My goals for the coming year? I'm too tired to even think about it ;-).

This seemed really inefficient to me, especially considering that it made it incredibly difficult to merge changes from his development branch into his production branch (deleting and re-adding directories breaks the merge process considerably). I knew there had to be a better way.

I'd heard of the svn:externals property before, but never really played with it. As it turns out, it exists for just this very type of situation. The problem is that the documentation of svn:externals in the SVN book doesn't indicate at all how the property should be set, and most howto's I've read omit one or more very important details. I finally figured things out through some trial and error of my own, so I'm going to share the process so others hopefully can learn from the experience as well.

It's actually pretty easy. This assumes that your project layout looks something like this:

project/
    branch/
        production/
    tag/
    trunk/

• In the top of your project trunk, execute the following:

  svn propedit svn:externals .
  

• This will open an editor session. In the file opened by your editor, each line indicates a different external svn repo to pull. The first segment of the line is the directory where you want the pull to exist. The last segment is the svn repo URL to pull. You can have an optional middle argument indicating the revision to use. Some examples:
  • Pull framework repo from head:

    framework http://framework.zend.com/svn/framework/trunk
    

  • Pull framework repo from revision 2616:

    framework -r2616 http://framework.zend.com/svn/framework/trunk
    

• After saving and exiting, update the repo:

  svn up
  

• Commit changes:

  svn commit
  

One thing to note: any directory you specify for an svn:externals checkout should not already exist in your repository. If it does, you will get an error like the following:

svn: Working copy 'sharedproject' locked
svn: run 'svn cleanup' to remove locks

I show using revisions above; you could also pin to tags by simply checkout the external repository from a given tag. Either way works well.

Then, when moving from one branch to another, or from the trunk to a branch, you simply set a different svn:externals for each branch. For instance, your current production might check from one particular revision, but your trunk might simply track head; you then simply determine what the current revision being used is on your trunk, and update svn:externals in your production branch when you're ready to push changes in.

Hope this helps some of you out there!