Technology

You may have noticed quite a few changes to the website recently —what you haven't seen, however, is any new content from me. For some reason, I've been having trouble with words over the past few years. I find myself becoming significantly more introverted with each passing year, and I think that's caused me to be a lot more reserved about public introspection —which is sort of sad, because I've always enjoyed sharing my work with people through this and other mediums.

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.