rick's blog

I'm working on transitioning our rails deployment process (which consists of some shell scripts on the server) to SwitchTower. ST is so good, it inspires folks to write poetry. But, I have a growing stack of patches that I need applied to the latest version of Rails. I think the easiest way to do this is with a rake task:

There are two main things I dislike about working with Flash: Messing with the complicated OBJECT tag, and duplicating work. The object tag forces you to properly encode your flash variables, and write them twice (once for Internet Explorer, once for other browsers). Yuck. Luckily, this is a solved problem with FlashObject. This provides a simple javascript API to replace HTML elements with Flash elements in just a couple simple lines of code, without having to mess with that awful OBJECT tag. It also handles the flash variable encoding stuff for me, so I can get back to writing the website. One of Digett's latest projects, the Quintessa redesign with Six88, allowed us to flex our flash muscles and kick it up a notch.

If you're a unix system administrator, rsync is the obvious choice for speedy remote backups. It only sends the differences of files, allowing me to quickly synchronize a directory of important files offsite.

Duane Johnson recently released a set of ruby gems for productizing your Rails app. This allows you to write an application, and customize it as needed for multiple clients. This is a very interesting idea for the kinds of products we write. BillBoards is an application that will be suitable for most clients. But, these clients can conceiveably have their own unique requirements. With a productized application, we'll have one codebase for the whole app, and any customizations for each client in a separate location. This gives us less duplication in code, so I can improve BillBoards in one location without worrying about making the same changes for each client.

Here's something I ran into while doing some querying of the BillBoards database: PostgreSQL's LIKE operator acts differently than others that I'm used to. Both MySQL and SQLServer perform case insensitive matches, but not PostgreSQL. Searches for 'bob' won't return 'Bob,' for instance.

I downloaded the second episode of the Ruby on Rails Podcast to hear the interview with Dave Thomas (author of Agile Web Development with Rails), but I was surprised when my little Rails extension was discussed.

We have been bootstrapping our new BillBoards product for the Boerne Chamber of Commerce website for about the last week and a half. BillBoards is a hosted text ad solution that I've written using the Ruby on Rails framework. But, why does the internet need another ad service? It differs in two main aspects. One, it allows the Boerne Chamber website to display focused ads from businesses that are members of the chamber, rather than some random advertiser that happened to have purchased the right keywords. Secondly, we've implemented a basic auctioning system so that all the members have a fair chance to get the ad spots they desire.

Since our move to PostgreSQL, I've run in to an odd issue. I use transactional fixtures to reduce the time it takes to run my tests. This works great, unless the test case actually uses ActiveRecord::Transactions. The nested transactions seem to be causing problems, so I needed a way to turn off transactional fixtures for that single test method. Here's what I found after some digging through ActiveRecord::Fixtures:

An interesting question was posed yesterday. What's a good way to encrypt data for a web application? The problem with typical symmetrical encryption, is that a key must still be present to decrypt the data (if you want automation, anyhow). So, I opted for a PKI method. Sentry is a little ruby module I wrote that uses some undocumented OpenSSL classes. Basically, it creates a simple RSA private and public key, and encrypts the private key with a symmetrical encryption algorithm. So, only a simple password (and not a full RSA private key) is needed to decrypt something. It's still not automated though.

Though I’m fairly comfortable with MySQL, I decided to make the move to PostgreSQL for our Ruby on Rails project. Installing it was a little hairy for someone so accustomed to Windows, but DarwinPorts greatly eased the pain. The only show stopper was the fact that I was comparing some dates in SQL using the MySQL built-in function UTC_TIMESTAMP(). All the dates in the database are in UTC format, so I needed to use that function instead of the common NOW() to do the comparison. However, this was very easily remedied with a PostgreSQL function: