Crazy Or Genius?: Tag rails

TigerEvents 0.7.1 - It's About Time

Sean — Thu, 25 Jan 2007 02:35:00 +0100

So….. I have actually had a release version of Tigerevents for a long time now. 0.7.0 is actually powering my.dsu.ca now, but was never officially released. As I added several features since then, as mentioned a while ago, I decided to just increment the release number, and push it out there.

This decision was prompted by an organization other than the DSU contacting me, saying they wanted to use it, and if I could just add this one little feature enhancement…...

Needless to say, the idea of other people using this pleases me, and hopefully in the near future I can point out to other in production instances.

The code, as always, is available at the Sourceforge, and Rubyforge locations for download.

Finally Giving In

Sean — Sun, 19 Nov 2006 18:03:00 +0100

Over the last few years I have been asked to present something at various local conferences (mostly just CEOS). This has always ended up with me saying, “sorry, I don’t have the time”. Recently, I have come to the realization that I am likely going to always be “busy” with various other things. So I made a decision.

More recently, I have been asked to give a talk at DevEast. Rather than my traditional “sorry I don’t have time”, I decided to give in and accept. I am now going to be giving a talk about Ruby on Rails that will encompass a lot of the basics, as well as sharing some of my own experiences with it over the last year.

Win, lose, or draw, at least in a few days I will be able to say I’ve tried.

Writing Database Code In Rails: Migrations and Neutrility

Sean — Wed, 23 Nov 2005 18:12:00 +0100

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).

TigerEvents Breaks 50! (Downloads That Is)

Sean — Tue, 08 Nov 2005 01:27:00 +0100

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!

Sean — Thu, 03 Nov 2005 19:44:00 +0100

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.

Woo! TigerEvents 0.5.0 Public Release

Sean — Fri, 07 Oct 2005 12:42:00 +0200

Finally, after long hours, little sleep, and lots of work, the 0.5.0 release of TigerEvents, code named “It’s Finally Our So I Can Take A Break” was released the other day on both Sourceforge and Rubyforge.

The focus of this release was getting all the proper administration interface stuff working properly (sorry front end only users) and trying to document it enough so a person can take the code, set it up, and run it on another machine.

Now that the initial file release is out, all I have to do is upgrade my.dsu.ca (merging is going to be a pain in the ass), work on 0.6.0 (which involves merging my development branch back into the trunk, ugh), and redo that ugly, ugly interface.

Regarding the interface, I plan to do something even more minimalistic than some people’s ideas (the one’s I am getting are awesome though, don’t stop). It will, at the very least, grant more open space, as opposed to cramming everything important into a small area. A primary advantage of starting out small is that it will be simple (except for all the XMLHTTPRequest stuff I need to do), and if people want more, I just add more, instead of scalling back and forth.

Oh, and I will do my best to get rid of that blinking text box.

A License To Bitch

Sean — Tue, 04 Oct 2005 21:16:00 +0200

As already mentioned I have been working on a project called TigerEvents, which powers the my.dsu.ca website.

This project, written entirely in Ruby On Rails, took 4 part time students 2 months to code a working, publicably usable beta. Pretty sweet, since some of us had other, paying, supposedly full time jobs on the go as well, and all of us had other responsibilities.

The my.dsu.ca website has gotten 102430 requests since Aug 25. Not bad I suppose, but I think we can do better than that.

The main problems? I know it, you know, it’s the visual layout. Sure it sucks. A layout like this is when a graphical artist that is supposed to do work totally flakes out and techies are left in charge. Also high up on that list is usability. Some things work well, some things…...... not so well (hey, it’s beta). So how do we fix this? Well…..... I am hoping that you, the public, the intended audience, the actual, non-involved USERS could give me a hand here. Let me know what you like, let me know what you don’t like, let me know what YOU would like to see.

Go ahead, chew me out, rip it to shreds, praise it, stomp it, love it, hate it. Just give me something I can use.