I'm pleased to announce that this site has a brand-new look and feel! It's been several years since I've had a truly custom design on the site; the last time, I was running a homemade blogging engine I lovingly referred to as "Blahg," and had no choice but to custom-build the theme. I liked the result, which despite my being a trombonist was heavily piano-themed. But, when I switched off of Blahg to Octopress, I didn't really have time to take the same amount of care with the design —I pretty much just used the standard template with a couple of color changes:
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.
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.
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.