GYROtechie

Sadly, I was not able to spend nearly as much time on the rewrite project this week as I wanted to. I have a code release early next week for another project, and I still had a number of things to wrap up there. So, the rewrite project had to be put on hold for the second half of the week.

I did make some progress early in the week though. I now have 8 models working with all the relationships set up and behaving as expected. I decided to use a single-table inheritance pattern for a few of the models as well. This works really well. I debated the value of it early on. I really don’t like to see applications that seem to use complicated design patterns just for the sake of it. I’ve seen some extreme cases where it almost seemed like the developers were flipping through the Gang of Four Design Patterns Book making sure they used as many as they could. Early on it just seemed more practical to put some if blocks in various places to account for the different view behaviors I wanted to have, but in the end I realized that the single-table inheritance made the most sense.

So, why would I want to use single-table inheritance? In this application, I have a model called Attachment. An attachment can be of various file types (PDF, MOV, MP3, etc.). For the most part the differences are in how the attachments are displayed to the user. This is going to require an if block on the view regardless, so I was not sure how the inheritance model would benefit the design. To help me decide, I listed out all the things that I knew needed to be different for each of the types. The deciding factor was when I remembered the need to provide a way for users to convert the video files to flash videos for display on the site. This extra work of video conversion really belongs in it’s own class and not in the Attachment class. So, that was it; I had to do it.

Of course it’s really not a headache at all.  I created a Video model which inherits from Attachment, and I added a field called ‘type’ to the Attachments table. There is not a table in the database for Videos. Rather when a Video object is created, ActiveRecord persists it to the Attachments table with a type of “Video”. And when I lookup a Video for retrieval, ActiveRecord knows to get it from the Attachments table but retuns a Video object.

There are a few things to remember when using this pattern. As with learning many things in rails, one of the best things to do is go to the command line.

>> my_video = Attachment.new(:name => "my video", :type => "Video", :file_name => "video231.mov")
=> #<Attachment id: nil, name: "my video", type: nil, file_name: "video231.mov", activity_id: nil, created_at: nil, updated_at: nil>
>> my_video.type= "Video"
>> my_video
=> #<Attachment id: nil, name: "my video", type: "Video", file_name: "video231.mov", activity_id: nil, created_at: nil, updated_at: nil>
>> my_video.class.to_s
=> "Attachment"

As you can see here, I created an Attachment and tried to set the type to “Video”, but the result is a type with a value of nil. Next I set the type to “Video” and this appears to work, but calling the .class method reveals that the object is an Attachment which is not really what I wanted. The correct way to create the object is this:

>> my_video = Video.new(:name => "my video", :file_name => "video231.mov")
=> #<Video id: nil, name: "my video", type: "Video", file_name: "video231.mov", activity_id: nil, created_at: nil, updated_at: nil>
>> my_video.class.to_s
=> "Video"

As you can see, I now have the correct object type giving me access to all the methods and attributes of both a Video and an Attachment object. Those of you from Java land should think of the Attachment class as abstract. In most cases you should work with the sub class instead of the parent.

I hope this is helpful to those of you learning Rails and ActiveRecord. Please feel free to ask me questions or just let me know you stopped by.

As a final commentary on my progress with the rewrite project, here is the output from calling rake stats:

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |   538 |   371 |       7 |      43 |   6 |     6 |
| Helpers              |    19 |    17 |       0 |       1 |   0 |    15 |
| Models               |    51 |    33 |       8 |       0 |   0 |     0 |
| Libraries            |     0 |     0 |       0 |       0 |   0 |     0 |
| Model specs          |   125 |   101 |       1 |       0 |   0 |     0 |
| View specs           |   625 |   485 |       0 |       0 |   0 |     0 |
| Controller specs     |  1392 |  1032 |       0 |       6 |   0 |   170 |
| Helper specs         |    66 |    42 |       0 |       0 |   0 |     0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  2816 |  2081 |      16 |      50 |   3 |    39 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 421     Test LOC: 1660     Code to Test Ratio: 1:3.9

Not too impressive just yet. Especially when you consider that most of the lines shown are from the generators.

Here’s an interesting issue that I ran into while setting up a bunch of new models for a new application. Ultimately I discovered that “type” is a reserved field name for classes that inherit from ActiveRecord.

When I tried to create a new object, one of the fields would not accept a value and remained nil. Here’s what I saw from the console.

>> a = Attachment.new(:name => "some name", :type => "Video")
=> #<Attachment id: nil, name: "some name", type: nil, file_name: nil, activity_id: nil, created_at: nil, updated_at: nil>

I was not seeing an error except from my rspec test which conveniently popped up since I’m running autotest.

ActiveRecord::RecordInvalid in 'Attachment should create a new instance given valid attributes'
Validation failed: Type can't be blank

I had a many-to-one relationship between two tables. In my design there is an Activity model which has many Attachments. An Attachment can be of various file types. For example it could be a PDF, image, video, etc. Since I felt there would be very little difference in behavior for the different types, I simply added a type field to the Attachments table so I could evaluate that for a few various display options. I knew about the single-table inheritance that is built into ActiveRecord, but it didn’t occur to me right away that this could be the cause of my problem. When I tried to start up Mongrel and insert a new Attachment through my browser, I got failures again, but of course this was because the persistence failed. Ahhh, I had the validates_presence_of :type in my Attachment model class which of course won’t allow persistence of a nill value to the database. So I was back to why it was nil in the first place. I removed validates_presence_of from the model and of course the record was persisted with a nil value for the type field. And still no errors. I checked the database and just as expected found the record with a NULL value for type.

Next I inserted a new row to the database manually with a type value. Then it comes. The moment when I get to slap my forehead and feel kinda silly. As soon as I hit the refresh on the browser to see the list of Attachments, I get the following error:

The single-table inheritance mechanism failed to locate the subclass: 'Video'.
This error is raised because the column 'type' is reserved for storing the class in case of inheritance.
Please rename this column if you didn't intend it to be used for storing the inheritance class or
overwrite Attachment.inheritance_column to use another column for that information.

This is a great error. It’s well worded, tells me what the problem is and how to fix it. I just wish this would have been thrown when trying to persist an object to data with an invalid type. But hey, now I get to add that as my own validation method.

I eventually decided to use single-table inheritance after all because there turns out to be more that just a few differences in how I need to treat these attachments.

Well, we’re at the end of week one and I feel like we’ve made some decent progress on the big rewrite project. We spent some time going through the data design of the old application in order to get a lot of that back in our heads and sketched out on paper. We also spent some time learning a little more about Ruby and Rails in general, plus some specific things such as ActiveRecord. We also spent time installing and getting our environment set up like we want it. Finally, we started creating our Rails models.

The existing database was fairly well designed, but it does not use any kind of data modeling framework. I had created my own data access layer which essentially amounts to a set of function libraries for every type of data access and manipulation needed. These functions go beyond simple data access though; quite a bit of business logic (and even *gasp* some view logic) has crept in over time. When faced with restrictions from the CMS I was working in, it was just too easy to hack out something that would work. Because to fix things the right way meant, well, a big rewrite. So we decided to make a few modifications to the database design to make it  fit better with Rails ActiveRecord style development. On paper, our new design has 21 models so far.

It’s now the end of the week. We’ve learned a lot. (Like Matz said at the Lone Star Ruby Conf last weekend, the best way to learn is just to get in there and start working with it.) Our environments are (mostly) set up like we need. We’ve designed out our data models on paper. It was important to me to follow a BDD process using rspec and autotest from the beginning, so we’ve got those things set up and working as well. We created a Rails app, decided we needed to change a few things, scrapped it and started again. We have half a dozen models in the newest attempt and (almost) have those all talking to each other how they need to. I can’t wait to see how far we can get next week.

I ran into an annoying problem with Wordpress recently. The problem was with the author for each of my posts. I wrote several posts with no troubles; the posts were showing me as the author as expected.  However, after adding a new user account to the blog, all my posts started showing up with the new user as the author of my posts. I’m currently running 2.6.1, but I’ve heard others talk about this with previous versions as well. To get around this bug, I would go into the data base and update the post_author field in the wp_posts table. This worked but was frustrating to have to do this for every post.

So, here’s what I did to fix it. While logged into my account, I changed the new user to a role of subscriber then changed them back to the role I wanted them to be. Now when I write my posts the author tag is correct again.

After further investigation, I found that the error may have something to do with the wp_usermeta table. There was a record in this table for the new user with a meta_key of wp_user_level and meta_value of 1. After changing this other user account to subscriber then back again, this record was removed. I’m not sure if other changes were made in the process, but you may be able to solve this by simply deleting that record as well.

I hope that helps anyone else out there frustrated by this issue.

UPDATE (09/23/2008) - I ran into this same problem on a different Wordpress installation today. This time, the above solution did not work. The problem was that my admin account was missing the entry in the wp_usermeta table all together. I corrected this by inserting the value for my account with the following SQL:

insert into wp_usermeta VALUES(null, 1, 'wp_user_level', '10')

Where 1 is the id of my account. You can determine the correct id by looking at the wp_users table.

We really had a great time at the Lone Star Ruby Conference this past weekend. I’ve been to a number of conferences in the past for other technologies or programming languages, but this one really stands out for a number of reasons. It was not over-commercialized with tons of vendors trying to sell you something every time you turn around. Also, some of the biggest names in the Ruby world were there. And not just there, but they were hanging out with the group just like any other conference attendee. I love that these guys who are revered by most are just normal guys; they don’t put themselves up on a pedestal and have big egos.

There were several great talks but my favorites were:

• James Edward Gray II discussed lesser known Ruby gems, some of which I will definitely be using shortly.
• Evan Phoenix gave a fun and informative commentary on the past and current state of Ruby and the Ruby community.
• Yukihiro Matsumoto, the creator and still guardian of Ruby, gave a great keynote.
• Gregg Pollack & Jason Seifer gave a whirlwind run through of innovative happenings and tools from the past year.
  
• Yehuda Katz demonstrated using screw-unit which is a nice BDD test framework for Javascript. I’m really excited about testing this one out on my own. We’ve all suffered through the countless hours debuging with firebug. I love that tool, but I look forward to not needing it as much.
• Glenn Vanderburg gave a great talk on tactical design where he layed out a compelling argument for teaching good design using a few simple and easy to remember principles.

All around, this was a great conference. The more I get involved with the Ruby community, the more I enjoy it. I even had the chance to catch up with some old friends. Here’s a picture of myself and Todd, one of my old co-workers from San Antonio.

After this weekend, we’ve been inspired to get started on a Ruby project that we’ve been talking about for some time. We have a large PHP application that has been growing for almost 3 years. It’s not the cleanest of designs and is built on top of an out-dated CMS. The trouble is that fixing it up with another PHP CMS or migrating to a PHP framework like Cake would involve a lot of time, and maintaining it as is has become very complicated.  So, we’ve decided to re-write it from the ground up using Ruby on Rails. I plan to catalogue the experience here so stay tuned.

Shannon and I are getting pretty excited about the upcoming conference this weekend. We’re both fairly new to Ruby and look forward to the learning opportunities. We hope to meet some new friends there who are just as excited about Ruby as we are.

If you were at the conference as well and reading this afterward, please let us know you stopped by.

Look what the FedEx guy brought today. Updated business cards with our new logo. My talented sister-in-law took our logo and made this nice design. We’re quite pleased with the look.

Technology used:

• PHP
• SQL - (MySQL database)
• Linux CRON for scheduling email notifications
• Smarty template engine for page views (www.smarty.net)
• Selenium for testing
• HTML, CSS, Javascript for presentation
• Subversion version control system

The client, Little Giant Steps, wanted to adapt their web training application. The original application was for clients who had received a personal evaluation and had an individualized program created for them. The goal for this project was to provide a new training site where clients who had not been evaluated would receive a more standardized training program. There were new features required like gathering survey data and pre-screening clients to ensure that the training would fit their needs. Access needed to be restricted so that only clients who passed the pre-screening would be allowed to sign up for the training and a survey was required prior to beginning training. After 5 months the system needed to send email notifications to clients requesting they return to the web site to take another survey. This would allow the administrators, as well as the clients, to evaluate the progress that had been achieved.

Technology used:

• PHP
• SQL - (MySQL database)
• Smarty template engine for page views (www.smarty.net)
• Selenium for testing
• HTML, CSS, Javascript for presentation
• Subversion version control system

This organization, Little Giant Steps, wanted to create an online training site for the parents of the children they work with. The concept was to create a customized training program for each user which would include streaming videos and downloadable materials. Each client would have a limited amount of time where they could log in to a secure site to view their training information. An administrative site was also needed to manage the bank of training exercises and vast number of online videos (over 1,000 videos as of 08/01/2008). The trainers needed to be able to log in and create the custom training programs, check on client status, and view reports. We were able to create this application with all these features and more. The project is running on a Linux/Apache/PHP server with a MySQL database (standard LAMP configuration).