Being a technical presenter, I've often run up against the issue of how to present code snippets.

The easiest route is to simply cut-and-paste into your presentation software. However, such code is basically unreadable: it's hard to get indentation correct, and the lack of syntax highlighting makes them difficult to read (syntax highlighting helps users understand the purpose of the various language constructs).

I'm speaking at PHP Quebec this week. While I live a scant 1.5 hours away from the venue, this is the first I've been to the conference. The snow gods have declared their wrath already, but I plan to thwart them and drive up to Montreal this evening regardless.

I'm giving two talks and participating in a panel discussion this week. The first talk is entitled "Practical Zend Framework Jutsu with Dojo," and, while it may look like a familiar topic of mine by this point, I've spent the last several days reworking the talk entirely, and am very much looking forward to presenting it tomorrow. (My copy of "Presentation Zen" could not have come soon enough! and that's all I'll say about that.)

On Friday, PHP Quebec has introduced a "Framework Bootcamp" track, including sessions by myself, Fabien Potencier of symfony, and Derick Rethans representing eZ Components. My talk that day is entitled "Zend Framework Little Known Gems." While hardly a completely original talk (Aaron Wormus did a "Hidden Gems" series of posts for DevZone a couple years back, and Zend's own Shahar Evron did a similar talk at last fall's IPC), this will be my first time doing a Zend Framework talk on something other than the MVC stack (or how to use components with the MVC stack). Leaving my comfort zone, so to speak.

Towards the end of the day, Fabien, Derick, and myself will be corralled onstage together for a "Framework Comparison".

If you're headed up to PHP Quebec this week, I look forward to meeting you or seeing you again!

I'm really not sure I understand these "seven things" or "tagged" memes, but I'm going to give it a shot, after Keith Casey did a drive-by tagging of me on New Year's Eve.

So, without further ado, seven things you may not know about me…

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:

• 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.

In the last two entries in this series on models, I covered using forms as input filters and integrating ACLs into models. In this entry, I tackle some potential infrastructure for your models.

The Model is a complex subject. However, it is often boiled down to either a single model class or a full object relational mapping (ORM). I personally have never been much of a fan of ORMs as they tie models to the underlying database structure; I don't always use a database, nor do I want to rely on an ORM solution too heavily on the off-chance that I later need to refactor to use services or another type of persistence store. On the other hand, the model as a single class is typically too simplistic.

In my last post, I discussed using Zend_Form as a combination input filter/value object within your models. In this post, I'll discuss using Access Control Lists (ACLs) as part of your modelling strategy.

ACLs are used to indicate who has access to do what on a given resource. In the paradigm I will put forward, your resource is your model, and the what are the various methods of the model. If you finesse a bit, you'll have "user" objects that act as your who.

Just like with forms, you want to put your ACLs as close to your domain logic as possible; in fact, ACLs are part of your domain.

A number of blog posts have sprung up lately in the Zend Framework community discussing the Model in the Model-View-Controller pattern. Zend Framework has never had a concrete Model class or interface; our stand has been that models are specific to the application, and only the developer can really know what would best suit it.

Many other frameworks tie the Model to data access — typically via the ActiveRecord pattern or a Table Data Gateway — which completely ignores the fact that this is tying the Model to the method by which it is persisted. What happens later if you start using memcached? or migrate to an SOA architecture? What if, from the very beginning, your data is coming from a web service? What if you do use a database, but your business logic relies on associations between tables?

While the aforementioned posts do an admirable job of discussing the various issues, they don't necessarily give any concrete approaches a developer can use when creating their models. As such, this will be the first in a series of posts aiming to provide some concrete patterns and techniques you can use when creating your models. The examples will primarily be drawing from Zend Framework components, but should apply equally well to a variety of other frameworks.

I've been playing a lot with Dojo lately, and have been very impressed by its elegant publish-subscribe system. Basically, any object can publish an event, and any other object can subscribe to it. This creates an incredibly flexible notification architecture that's completely opt-in.

The system has elements of Aspect Oriented Programming (AOP), as well as the Observer pattern. Its power, however, is in the fact that an individual object does not need to implement any specific interface in order to act as either a Subject or an Observer; the system is globally available.

Being a developer who recognizes good ideas when he sees them, of course I decided to port the idea to PHP. You can see the results on github.

I've fielded several questions about setting up an autocompleter with Zend Framework and Dojo, and decided it was time to create a HOWTO on the subject, particularly as there are some nuances you need to pay attention to.