Snowball – End Result

Snowball wasn’t bad all things considering. Sure the chicken was dry, the dean forgot what awards he was supposed to present, my end of year slideshow crashed, and the place was apparently too dark and none of the award presentation photos came through clear. But in the end, people said they enjoyed themselves, that my speech wasn’t too shabby, and that they wanted a copy of my slideshow to take a look at it.

And once all my work was done, I could luxiriate in a Friday night off, drink, and dance.

It was fun, but I am oh so glad I don’t have to plan that ever again.

Writing Database Code In Rails: Migrations and Neutrility

As I recently said, I switched TigerEvents over from using a MySQL input file to migrations. There were many decisions behind this choice.

* I wanted the code to be database neutral. Using migrations would allow me to automatically support MySQL, PostgreSQL, and SQLite by making changes to one file instead of 3.
* I know that the database for TigerEvents is going to change at some point in the near future. Rather than write multiple upgrade scripts manually, I could just use the built in migration functions to do it better.

* If for some reason I make a mistake and problems occur on the production site, it is easier to roll back to a previous version using migrations than dump the database, roll back the code, reload the database, etc. (Note, we still make sure to back up the database, cause not doing that is just tempting fate)

* Migrations will, in theory, make development easier. Someone made a change to the schema? Just run rake migrate, and your database is automatically updated. I think this is easier than reinitializing a database and then loading it with data repeatedly (though the second part of this can be handled with Fixtures).

While an awesome introduction to getting started with Migrations has already been written, I feel that the ‘database neutral’ stuff is missing. Using my own experience, several items must be taken into account, mostly due to MySQL usage and certain programming that were being used.

Already Existant Database

So we already had a database. A somewhat large database with a number of tables. I didn’t want to spend a lot of time manually creating the migration code from scratch. Was there a quicker way? You betcha. There was a rake task called db_schema_dump which will dump all the table data from your database to a file called schema.rb. So, once we do that, all we have to do is copy this information to the self.up section of a migration and we are done, right? Unfortunatly, it is NOT that easy. The problem is (in my case) that MySQL data types do not necessarily behave the same. Mostly, this deals with constraints, but also has to do with the boolean data type itself.

Constraints

In MySQL, you can do int(8). In rails, this would be translated into something like :integer, :limit => 8. However, PostgreSQL only has smallint, integer, and bigint, not constraint values. Therefore, the previous rails code returns an error, as PostgreSQL chokes on the SQL command that rails sends it. Therefore, while it is true that you don’t need to know specific SQL syntax, you DO need to know what kind of data you can feed various databases. For TigerEvents, I just generalized items and made the following changes:
:integer, :limit => 8 became :integer

:integer, :limit => 1 which translated to tinyint(1) in MySQL became :boolean

:timestamp became :datetime (which gave me extra functionality). Now, I by no means know if these are the optimal solutions, but they did work.

Boolean Data

We have a few boolean flags in our database. However, MySQL does not have a boolean data type. Instead, tinyint(1) is generally used. Well, generally that is ok, as ActiveRecord will automatically use tinyint(1) when connecting to MySQL and boolean when connecting to PostgreSQL and SQLite. However, since we started out with MySQL, there were numerous statements such as

@newgroups = Group.find(:all, :conditions => [“approved = 0”])

where 0 is supposed to indicate false. However, since this does not translate to false with PostgreSQL and SQLite, we have a problem. Solution: use placeholders. You are acually allowed to do this:

@newgroups = Group.find(:all, :conditions => [“approved = ?”, false])

ActiveRecord takes the value and automatically translates the value into the proper data type, depending on the database type.

So once again, while you don’t need to know specific SQL query usage, it is important to keep data types general, and passed values abstracted if you want to create database code which is database neutral (at least for MySQL, PostgreSQL, and SQLite).

Battle Beams

Today, someone mentioned that all disputes in the Computer Science Building should be settled through battle on the beams suspended over the atrium. This individual also went so far as to state that this was a traditional mode of challenge on a certain mailing list in the past (which remains to be seen). Obviously, I missed out on quite a bit in the past here, but I feel it might be worthwhile to revive this tradition.

However, a few changes:

Install a cross beam (or two) in between the two central beams already there. Then combatants can start of on their own beam without arguments of who steps out first. Additionally, this would allow individuals to jump from beam to beam, thus hightening the overall entertainment value.

Include other trials, such as a rock climbing challenge at the local gym. American gladiator style knocking the opponent off will be permitted, as will random projectiles launched by the audience.

The ‘My Kung Fu Is Powerful’ challenge, where contestants attempt to immitate the over the top martial arts moves they see in the movies. For added entertainment, said moves must also be performed on the beams.

Perhaps the most difficult challenge in the overall scheme of things would be the ‘Oral Algos Quiz Challenge’. Personally, I would rather battle over a tiger pit.

With the social acceptance of geeks these days, and the success of shows such as ‘Beauty and the Geek’, I think this might have potential. Think of the entertainment! We could broadcast events live over the internet. “Geeky Gladiators” will surely be a hit. Revenue will be raked in hand over fist, and will help build another two floors on the CS building.

Update For some reason I missed out on a ‘Gauntlet’ style challenge. This challenge would involve competitors running through an area with multiple sentry guns. For visible scoring/less chance of permanent injury (we want victors to come back after all), the sentry guns would probably be loaded with paintballs.

The Ball Season Has Begun

As some of you might know, I enjoy going to formal events. Weddings, balls, whatever, you invite me to a function where I can get spiffy and wear a suit, and I am there.

Ball season has once again begun, and better than ever. Things kicked off last night with the DASSS/DSS Formal Ball. Much fun was had in between drinking, dancing, and conversation with various arts students. I am very glad that I was invited and went to this.

Upcoming:

Friday, November 25th – Snowball

You should all come. Seriously. Buy tickets from the CS Infodesk. I’m going to be MC and all that.

TigerEvents Breaks 50! (Downloads That Is)

One month after the first official release of TigerEvents and we have achieved the following:

* 31 downloads on Sourceforge
* 20 downloads on RubyForge

* 17 downloads directly from TigerOnRails

* Currently Ranked 3,682/105,551 projects on Sourceforge (Top 5%!)
* Currently Ranked 83/999 Projects on RubyForge (Top 10%!)

* One individual (from the Netherlands) actually testing out trunk and submitting tickets

Wow, this totally, totally exceeds expectations.

World Usability Day!

Today is World Usability Day. A day to work towards better user experiences in products and experiences. I also decided to use this day as a deadline for the next release of TigerEvents, one of the software packages I work on. 39 closed issues later……………… a brand new release. All that remains is to migrate my.dsu.ca to a new server, upgrade to the new version, and then all users can revel in…….. well……. errr………. actually, I must admit there isn’t anything major in a regular user’s perspective.

Removing that pesky sidebar proved troublesome (due to Javascripting and CSS issues), and is unfortunatly pushed back (I’m working on it!). You will see that events actually have their formatting preserved, so no more giant block paragraph that is a pain in the ass to read. There are also some more subtle rearrangements and additions to some options, which I think will make posting events easier for people. Admins get a little more, mostly avoiding huge lists of groups and users when trying to navigate (pagination helper is your friend).

And the backend stuff is where most of the changes occured. I personally refactored the code so that the authentication stuff is easier to drop into other code (important since we want to use it in multiple projects. Additionally, I refactored the code to make the entire system database neutral, and to have as much as possible done through ruby. This includes important things such as setup and schema migration. This was the longest and largest changeset I have done in a while, and I am glad it is over. Of course, I need to pass this on to several budding developers so they don’t make the same mistakes, so………. check back at some point in the future.

What however, is the future of this project? The individuals working on it (and by that I mean myself and Oliver) have decided we want to refocus on putting the ‘my’ into the ‘my.dsu’. Upcoming, expect to see new skins, a better actual interface devoid of those confusing multiple columns, and other things that will help the USER kick ass. So think of this World Usability Day not as a day for which we bring out a ton of usability fixes, but a day where we begin to devote more attention to where it is needed.

You know, after we take a much needed break.