Last night during one of my final email checks of the day, I got an email message from a recruiter. What made this particular email interesting was that the recruiter didn’t bother to hide any of the addresses he had sent this email to, and I was able to see just how many people get targeted in these types of emails. In this case, it was 416 (or so I’m told–someone counted). I went to sleep shortly thereafter, and slept in, taking Friday off. When I woke up and finally got around to my first email check of the day, I was puzzled to see a thread in Gmail that was 61 messages long. Some poor schlub had hit reply-to-all on that recruiter’s email, and drama followed. People replied-to-all complaining at first, but then the emails quickly turned to seeing the humor in the situation. Then people started to introduce each other…

Over the years, I’ve encountered a number of people trying to specialize too narrowly in their jobs, to the detriment of all involved. Here are a few examples of the behavior I see most often…

I continue to find useful the script I posted some time ago that creates a basic site structure in Drupal. Its not uncommon that a customer will want a leg up on migrating their content into Drupal, or will have a basic structure in mind even before they fill it with content.

I recently started working in Drupal 6, now that many of the modules I typically use are at least in beta for Drupal 6. So, I found that I needed to update the script as follows:

I am starting development of a significant new Web site implemented in Drupal, and have as my team five talented, but relatively inexperienced, developers with little existing knowledge of Drupal. This is my attempt to provide a quick orientation to Drupal from a developer’s perspective, based on my experience.

Recently, I needed to create end-user documentation for a desktop application. Although screencasting is a possible alternative, I didn’t feel it was appropriate in this type of situation, where the end user really needs something printer-friendly to have in hand while using the application.

Although I did want the document to be highly visual, I wasn’t looking forward to the tedious process of capturing screens manually, one by one, then inserting them into a document, manually, one by one. I needed something that would streamline both of these processes so I could concentrate on making good documentation.

It seems I make a new release of ZoomifyImage once a year like clockwork. This time around, I fixed a minor bug and made a few enhancements including writing temporary files to the system temporary directory and accounting for changes in ZODB’s transaction handling.

A customer on a newly launched Drupal e-commerce site I produced reported the following error:

Please enter a valid ZIP Code for the sender. (error -2147219498) usps configuration error. Please notify the site administrator.

Which occurred during the checkout process and only happened when a zip code contained a “+ 4″ code at the end.

Of course, I often find Google to be the best debugging tool of all, and I quickly found this post containing a workaround by Kenneth Bartlett that not only made it so I didn’t have to untangle the shipcalc module’s code, which would likely mean debugging Web Services calls to USPS, but is actually a pretty good solution in its own right I think.

The only thing I didn’t like about it was that it directly patched an e-commerce module file at modules/ecommerce/address/address.module. Whenever I use a piece of customizable software like Drupal (or Wordpress, osCommerce, etc.) I avoid directly patching both the core code and any third party modules, because this creates a maintenance burden for me when I want to upgrade the core software or an affected module, which could potentially wipe out these kinds of patches. I have my hands maintaining my own code, I don’t want to worry about modules I didn’t write.

I am reading The Second Coming of Steve Jobs by Alan Deutschman, and although the book was published way back in 2000, it was written at a time when Apple had already made a strong comeback, so I thought that it would still be a relevant case study of Job’s and Apple’s success.

As someone relatively new to Ruby on Rails, I managed to confuse myself on one of my Rails projects recently when I decided to follow some very logical advice in Obie Fernandez’s The Rails Way that said that has_and_belongs_to_many (habtm) relationships were essentially deprecated in Rails, and that has_many :through was the preferred way to handle many-to-many relationships.

With has_many :through, the join table becomes a full-fledged rails model, meaning that you have more flexibility to extend the functionality of that model as your application evolves in the future–a very sensible best practice. So, I decided to convert an existing relationship that I had specified as habtm to has_many :through. I began to see errors that initially confused me, along the lines of NameError: Uninitialized Constant …. I had misnamed my join model and table because I was still thinking from the habtm perspective instead of treating the new model as I would any other model in a has_many…belongs_to relationship.

This post is a recent, non-confidential internal memo I wrote to a co-worker as a sort of post-mortem on a long-term digital preservation project. Although its in very rough form, and alludes to some things that won’t make sense to those outside of Cornell University Library, (and I tend to be pretty loose in how I deal with topics, such as the relationship between performance and scalability for example, and I assume some familiarity with certain technologies), I thought there might be enough meat hear to interest others working in the area of digital preservation.