Spam comments are getting inventive

May 4th, 2011

I check comments that have been caught as spam every now and then. They seem to be getting very inventive… This one caught my eye because it looks like it’s a bit confused about the name of the profession that creates styles. I never realized that lawyers designed web pages!

I enjoy your blog.. pleasant colours & topic. Would you pattern this website by yourself or have you actually hire an attorney to make it work available for you?

“Time” columns and Rails

January 3rd, 2008

In SQL, there is a data type TIME which holds time of day information without date information. There is no equivalent class in Ruby. Rails (ActiveRecord) deals with this by adding some dummy date data and using the standard Ruby Time class. Currently the dummy date used is 2000-01-01, though since I can’t find any documentation on this, I guess it could be changed to something else in the future.

This means you can run into some odd issues if you aren’t careful when comparing values from SQL TIME columns with times in your code.

For example, if you have a record r in your database with the value “13:30:00″ stored in a column called arrival_time of SQL data type TIME:

Time.parse("2000-01-01 13:30") == r.arrival_time       # unless the dummy date AR uses has changed

"13:30:00" == r.arrival_time_before_type_cast

Time.parse("13:30") != r.arrival_time         # unless today is 1st January 2000

Working with SVN after restoring the repository from a backup

October 3rd, 2007

Last week, I tried to upgrade the control panel software (Plesk) on work’s hosted virtual dedicated server. Its pretty straightforward, just click the button and it all works, right? Wrong! Just click the button, and Plesk misconfigures itself, killing both the control panel and all our websites…

A quick phonecall to tech support, and they say they can either (a) replace the current mess with the backup and we’ll be back up and running in 20 minutes, or (b) try to fix the current mess with the help of Plesk, which could be a while…

I went for option (a). I guess I could have gone for (b) and fiddled around with the Apache config manually, but minimizing website downtime was the priority and I reckoned (a) would be faster.

Unfortunately, option (a) meant we lost all changes made since the last backup, including a couple of small SVN commits.

Trying to commit to the restored repository resulted in “base checksum mismatch” errors for the files that had been in the lost commits. svn update also resulted in errors due to files that should have been in the repository not being there. After Googling and finding loads of stuff telling me that the repository must have got corrupted and how to fix its BDB database, it occurred to me that actually a pretty simple fix would just be to replace everything in the problem .svn folders in my working copy with what they should now have in them. So here’s what I did:

  1. Commit all changes that SVN will let you commit.
  2. Copy working copy to somewhere safe in case something goes horribly wrong.
  3. Checkout the directories that are causing problems as a new working copy.
  4. Manually copy the necessary .svn directories from the fresh working copy to the original working copy.
  5. svn add/delete as necessary.
  6. Commit changes.

Seems to have worked fine. Luckily all my changes that wouldn’t commit were in only 3 directories though, or it would have been pretty time-consuming doing all the copies!

More on date_select/select_date

October 3rd, 2007

I’ve recently been attempting to write Javascript code to work with the values in select boxes created through both date_select (works with dates that are accessed through a method on an object) and select_date (works with any date object you pass to it). Rather inconveniently, Rails names/ids the select boxes differently for these 2 cases.

date_select style ids:
id="<objectname>_<methodname>_3i" for day
id="<objectname>_<methodname>_2i" for month
id="<objectname>_<methodname>_1i" for year

select_date style ids:
id="<prefix>_day" for day
id="<prefix>_month" for month
id="<prefix>_year" for year
where <prefix> is either “date” or whatever you specify in the options to select_date.

Using the output of date_select

August 28th, 2007

Hmmm, after lots of time spent writing things like

item = = "#{params[:item]['date(1i)']}-#{params[:item]['date(2i)']}-#{params[:item]['date(3i)']}"

I’ve accidentally found out that[:item]) is clever enough to see these 3 parameters, know that they’re from a date_select, and combine them to form a date.

The Rails API for the date_select method specifies this now. I’m fairly sure it didn’t a while back…

Eclipse on Ubuntu gotcha

August 22nd, 2007

I’ve finally worked out why Eclipse has been crashing with out-of-memory errors all the time since I upgraded to Ubuntu Feisty.

Before this release, I was using a version of Eclipse I had installed manually. This time, I’m using the version packaged by Ubuntu.

The application launcher provided by Ubuntu calls /usr/bin/eclipse, which is a shell script wrapping the call to /usr/lib/eclipse/eclipse (which is what actually launches Eclipse). This wrapper adds some -vmargs to the call, which means that Eclipse ignores any -vmargs you’ve specifed in your eclipse.ini file… such as the ones to increase the Java heap size so as to stop Eclipse crashing with out-of-memory errors if you’re working on a large project.

Simple solution - change the launcher to call /usr/lib/eclipse/eclipse instead of /usr/bin/eclipse.

More complicated solution available in this Ubuntu bug report.

Quick tip: ruby’s inject method

August 22nd, 2007

If you’ve been using the online version of the Pickaxe book as your ruby reference, you won’t know about this very useful little method in the Enumerable module. It allows you to do something cumulative with each item in your Enumerable object.

For example, to sum prices in an array of items ordered:

order = [item0, item1, item2]
total_price = order.inject(0) {|sum, item| sum + item.price}

instead of:

order = [item0, item1, item2]
total_price = 0
order.each {|item| total_price += item.price}


  • The method parameter is the starting value for whatever the cumulative value is - in this case, sum.
  • The first block parameter is the cumulative value, the second is the current object from the Enumerable.
  • The value returned by the statement in the block is set as the starting value for the next object from the Enumerable.

For more details, see this article on ruby arrays on

What happens when a migration fails

August 3rd, 2007

So… you’re writing a migration, you think you’ve got it right - time to try it out. You run
rake db:migrate
to apply your migration, and it doesn’t work.

Your database has some of the changes from the migration in it, and the rest aren’t there. How do you get it back into the state it was in before you attempted the migration?

You might think that
rake db:migrate VERSION=nn
(where nn is the migration number before the one that failed)
would do the job, presuming that your failed migration’s self.down method runs the statements to rollback your changes in the same order as the self.up method makes the changes.

Unfortunately, nothing happens. Rails knows it didn’t complete the migration, so has left the current schema version number as at the end of the last migration which did complete.

At this point, you are faced with opening up your database and reverting the changes that did get made manually…

There is, however, a patch in rails-trac to fix this issue - if you are using a database that supports transactions round data definition statements (such as Postgres). Once installed, your migration is wrapped in a transaction, which is rolled back if any errors occur. Yippee!

How to get references, functions etc into your Rails test database

June 25th, 2007

Your rails app comes with 2 tasks to clone your database structure into the test database: db:test:clone, which does everything through ruby, and db:test:clone_structure, which dumps the SQL needed to recreate the database structure, then reloads it, in a DB-specific fashion. You can switch which version is run by the db:test:prepare task in environment.rb.

Find this bit:

# Use Active Record's schema dumper instead of SQL when creating the test database
# (enables use of different database adapters for development and test environments)
# config.active_record.schema_format = :ruby

Uncomment the last line shown above, and replace :ruby with :sql - that’s it!

If, like me, you’re using postgres databases, this does the trick - now db:test:prepare dumps the structure of your dev/production database using pg_dump -s … and loads it into the test database using psql.

A couple of caveats:

  • If you’re using functions written in a language that needs to be created after a new database is created, you must connect to your test database as a superuser, as only superusers can add languages.
  • If you’re using views in MySQL, the views are carefully removed from the dumped structure, so won’t be in your test database.

Running rake in production mode

June 18th, 2007

This is the second time now that this has had me tearing my hair out. Last time, I couldn’t work out how to get rake db:migrate to operate on the production database. After a while on Google, I managed to find:

%> rake --require=config/environment.rb db:migrate

It worked like a treat, even on the Windows server my app’s deployed on (though with \ as the path separator, not /).

Until now, that is.

I’ve just switched to using the paginating_find plugin for paging result sets, as it allows me to use all the find options, unlike the rails default pagination. It works fine in both development and production, and rake is happy in development mode. It doesn’t like the command above, though, if you happen to call the find method in your migration. For some bizarre reason, the find method aliasing goes wrong, and you get an infinite loop. The overwritten find method is supposed to call the original find method, but ends up calling itself recursively instead.

Back to Google… nothing on this problem that I could find.

Rethink: it must be something with the way production mode is specified, since it’s only a problem when running rake like this.

Back to Google again: this time to look for alternative methods to specify that rake should use the production environment. Finally found a way, thanks to a post on a TextDrive forum:

%> RAILS_ENV=production rake db:migrate

That solves the problem on Linux, how about on Windows?

%> set RAILS_ENV=production
%> rake db:migrate