Technology

Well, it's that time again: I've decided to switch blog platforms. To commemorate the occasion, I thought I'd share a little bit of my personal blogging history.

I mentioned awhile back that one of my coworkers and I were considering putting together a simple resource site for Drupal users in educational contexts; today, http://drupaledu.org is live (many thanks to Acquia for providing the hosting)!

Over the last few months I've been pretty dissatisfied with the performance of this blog. Not only were page load times sometimes upwards of 10 seconds, but occasionally my swap usage would max out and crash the server, requiring a hard reboot. And it's a blog, for crying out loud—nothing this simple should ever flat-out crash a server, even if it's only got 256MB of RAM.

Last November my coworker Adrian Rollett and I got the opportunity to present a talk at DrupalCamp Austin; I've blogged about the content previously, but now that the video is up, I thought I'd post it here as well. Without further ado…

At the end of my recent post on building a cron service for your Zend Framework application, I mentioned a couple of weaknesses in the approach I took. Most notably, my cron service lacked any kind of locking mechanism to prevent cron runs from overlapping.

Recently, in a fit of narcissism, I decided that my blog needed to be Twitter-aware; that is, I wanted all my posts to display automatically-generated lists of all Twitter tweets that reference them (via the backtweets.com API). Loading these backtweets is a bit resource-intensive, so I figured it'd be best to offload the work to a scheduled background task (e.g., a cron job).

A couple of days ago I blogged about how Doctrine's SoftDelete behavior can keep other listeners' preDelete() hooks from firing; after a bit of coding this morning, I believe I have a solution.

In my initial setup, I had applied the SoftDelete behavior in the model itself via the following YAML config:

Post:
  actAs:
    SoftDelete:

Then, in my Zend_Application bootstrap, I was assigning my ACL listener like so:

One of my projects at work lately has been a searchable index of about 80,000 images, each involving about 20 fields' worth of metadata. It's a Drupal project, so it was pretty easy to set up the appropriate content types, fields, and so forth, but when it came time to set up searching, I made a few regrettable assumptions that cost me a lot of time.

In my recent post on using Zend_Acl with Doctrine record listeners, I described a way to automate a Doctrine-based application's access control logic based on certain event hooks in Doctrine's record listener system. I still think it's a fairly elegant approach, but as I've been working with it, I discovered one behavior I didn't quite expect.

Zend_Acl is a very powerful tool to help manage access control logic, but it can be a bit difficult to determine exactly where and how to use it.

In previous Zend Framework apps I've written, I often handled access control at the level of the controller action. Each action was represented in the ACL as a resource, and the ACL logic was applied by a custom plugin just prior to any action dispatch.