Attachment_fu is a great plugin by Rick Olsen (a.k.a. techno-weenie). I use this plugin for one of the sites I maintain. I recently ran into a situation where I needed to regenerate the thumbnails for all the uploaded images. Attachment_fu provides no built-in support for this, so I had to get creative. A quick search on Google revealed a post by Michael D. Ivey that seemed like a reasonable thing to do, but was not sufficient by itself. So in this blog, I plan to cover the steps I took to automate the regeneration of thumbnails when you are using attachment_fu.

Welcome to another edition of me talking about some website that's been kicking my butt for months on end. If you remember back in this blog, I was beginning to build a revamped version of my family's restaurant website. From what I can gather, and my timestamps seem to be telling the truth on this one, I broke ground on the new site approximately January 29, 2008. Had anyone been around me at the time, I'm sure they would have swiftly commented under their breath "Well, so much for his weekends for the next year". Luckily for me, that wasn't the case this time.

When designing a web site, most of the work goes into making a well-designed and usable frontend interface. What doesn't get nearly as much love is the backend administrative interface. Like security, it typically comes as an after thought if at all. However, with this website, I needed a reasonably functional administration section that would allow me to manipulate data in the models and a somewhat presentable interface that wasn't so arcane that it was unusable. While I did write some custom code to manage certain aspects of the site, developing an entire administration section from scratch was about as palatable as a dish of warmed up horse droppings. Say hello to my new best friend, ActiveScaffold.

As I mentioned in a previous blog, Rails recently introduced RequestForgeryProtection. I wanted to take full advantage of this functionality to help protect against CSRF-based attacks. I realize it's not a perfect method, but every layer helps. One of the observations I made when reviewing some of my code is that I had a number of actions within my controllers that did not validate the type of HTTP method supplied. Therefore, actions like deleting a blog or media file would work regardless of the HTTP method provided by the user as long as the user was logged in. Not a huge problem, right? Well, not quite.

Over the weekend, Rails 2.0 was released to the masses. Packed with a flurry of changes, I decided to take the plunge. After grabbing a Coke, turning on some music, and firing up TextMate, it was time to rock and roll. One of the new features included in the release was  RequestForgeryProtection, one that I wanted to take full advantage of to help protect against CSRF-based attacks. Considering I've been keeping current with each release cycle of Rails, I was hoping that the upgrade from 1.2.6 to 2.0 would be a piece of cake. Well, long story short, it wasn't. Not suprising I'm sure, but it was another late night of code wrangling that ended up putting me to bed around 5:20am on a Saturday morning.

It's 2am and like the cat in the picture, I'm a little disgruntled. The one thing I've always disliked about Rails on a Mac is the fact that RMagick is so darn hard to get working properly. You can do it from source, but then you have to update it manually. You can try to use MacPorts, but that's a very fragile process. I had it working in Tiger, but to be quite frank, I'm not sure how that happened and it must have been more of an accident than anything else.

In this installment of a blog, I'm going to be covering how I managed to get RMagick up and running using a combination of RubyGems and MacPorts. I'll start by saying, it was a very clumsy process. After having everything installed manually using a great tutorial on Rails Envy, I decided to scrap that in belief there had to be an easier way. When I tried to use  MacPorts and then install the RMagick gem, I kept running into an error about it not being able to find the freetype library. It was indeed on the system (/opt/local/lib/...), but it wasn't where the gem installer was expecting it (/usr/loca/lib/...). Give me a break.

For those familiar with the Rails community, it's likely at some point you've bumped into a Ruby gem called ZenTest. Zentest aims to make the process of ensuring test code coverage and automating testing a whole lot easier. One of the components of ZenTest is called 'autotest'. Autotest is a continuous testing facility that automatically runs tests based on changes in your code. In other words, when you make changes to your code, autotest detects it and runs the corresponding tests. Take autotest, stir in some of Pat Eyler’s RedGreen gem, add a touch of growlnotify, and now you have a setup that automatically runs tests when you make source code changes to your Rails project and then notifies you of the results via Growl.

It's been nine months since version 1.0 of the new site was originally launched back on New Years. Since that time a number of bug fixes and other improvements have been made based on feedback from users and the my general urge to write some Ruby code. When I began developing the new site, I knew little about Ruby and even less about Rails. Looking back through my 5,284 lines of production code and 11,330 lines of test code that currently make up the site's codebase, you can almost see a pattern of improvement in my Ruby kung-foo as time progressed. Had I to do it all over again, I'd probably make some significant changes to the underlying plumbing and would better utilize some DRY principles that I didn't fully understand when this all began. Do you see where I'm going with this? Yes, that's correct, the site is getting re-written from the ground up.

It was an early morning here at the apartment and I was just getting ready to sneak in a few levels of Call of Duty 3 before the girlfriend awakened. Unfortunately for me, I checked my email before I picked up the XBox360 controller only to find that random comments were being added to various entries on the website. You guessed it, comment spam and the kind that points you towards those sites only adults should visit. I knew it was only a matter of time, but why the 4th of July? Oh well, I've been meaning to implement captchas for sometime now and courtesy of a variety of spam friendly ip addresses have finally gotten around to spending a few lovely minutes with Rails to do so.

I'm always looking for ways to make improvements to the site. Sometimes the ideas come from my friends, once in a while from users who submit ideas through the feedback form, and other times I'm a victim of my own inspiration. Regardless of where the ideas come from, I sometimes have a hard time keeping my hands of the keyboard even when I should be packing for vacation. Just before the Mayweather fight about a week ago and only a few hours away from my departure to Florida, I decided to add a little more functionality to the search form on the music section.

One of the limitations of the standard search is that when you search for some term, you are returned all results for each album individually. So searching for "oakenfold" would return dozens of results, even though the results only stem from maybe 10 albums. I wanted to make it possible so that you could search and just be returned the albums relevant to the search. Thus, I started writing code.

Since RoR makes it easy to add AJAX functionality, I used the observe_form method combined with the find_by_contents method provided by the acts_as_ferret plugin. With about 20 lines of code and some modifications to my CSS , searching through music is a whole lot easier. To try it out for yourself, just head on over to to the music section and type in a search term. Rather than pressing enter, just watch as the results magically appear before your eyes.