Graham Glass, etc.

My Ruby on Rails Experience, Part 6

This is part 6 of the series; part 5 is here.

I've ported most of my PHP application to Rails now; it has taken about 6 days of intense effort and so far I remain very impressed by the productivity and expressive power of both Ruby and Rails.

I resolved the database issues described in my last few posts by simply embedding the address fields into the School and Student tables.

I ran into another issue yesterday evening that I haven't had much time to investigate. I start a Ruby web server directly from within the RadRails Eclipse environment, which I think spawns a process to run the Ruby WEBrick web server. If I use the web application for just a few minutes, the response times go from about 1/2 second to 2 seconds, and the memory usage climbs from about 25M to 35M. The performance continues to get worse after that. These are both signs of a pretty big memory leak; about 200K per HTTP operation.

I couldn't find reference to any obvious Ruby-related memory leak problem on the net, so I'll need to do some simple experiments to narrow down the cause:

• starting WEBrick from outside Eclipse
• trying a different HTTP server
• running a Ruby memory leak detector if I can find one

I'll blog what I find out. I want to put this issue behind me very soon.

Part 7 of this series is here.

My Ruby on Rails Experience, Part 5

This is part 5 of the series; part 4 is here.

On yesterday's blog entry I described an issue I found with the Rails ActiveRecord framework. Here is a summary:

Let's say that in my domain model I have a School and a Teacher, and both have an Address. Good database design suggests that you have separate tables for School, Teacher and Address, and that entries in the School and Teacher tables contain a key to their respective Address. Here's an article on IBM DeveloperWorks that says that same thing; see the section called "Complex Datatypes".

To recap, there's a one-to-one mapping between School and Address, a one-to-one mapping between Teacher and Address. The School and Teacher tables each contain a key to an Address.

In addition, I'd like there to be a dependency relationship between School and Address so that when a School is deleted, its associated Address is also automatically deleted. I'd also like the same dependency to exist between Teacher and Address.

Ruby on Rails includes a framework called ActiveRecord that directly supports access to relational databases without having to write any custom code. A scaffolding tool generates Ruby classes based on the names of your SQL tables, and the runtime system introspects SQL tables to add the appropriate accessors to the Ruby classes. The only thing you have to do is to "annotate" the Ruby classes with words like "has_one", "belongs_to" and "has_many" to indicate the relationships between the entities.

The current version of ActiveRecord requires that if model A has a dependency on model B, then class A must "belong_to" class B and the table for A must contain the key to B. In my case, since Address is dependent on School, it means that I'd have to put a key to the School into my Address table, which violates good database design principles.

Since I don't want to warp my database design to fit a current limitation of Rails, I added a few lines of custom code to my School and Teacher classes to implement the desired dependency. If you're interested, here's the code from School:

class School < ActiveRecord::Base
    belongs_to :address # yuch

    # use callback hook to implement dependency   
    before_destroy { |m| m.address.destroy if m.address }

    # when new address is assigned, delete old one
    def address=(new_address)
        address.destroy if address
        new_address.save if new_address
        self[:address_id] = new_address.id
    end
end

Clearly, this is not ideal. It would not be hard for Rails to directly support my common use case so that no custom code is needed.

Tomorrow I'm going to post some ideas on how to improve and simplify ActiveRecord.

Part 6 of this series is here.

Hacking Hours

Ye Gods! It's 7:11am and I'm still hacking on Rails, listening to the "Best of James Bond 007" soundtrack. I guess this means I'm a lost cause. 19 hours of straight coding. But the refrains of "MoonRaker" keep me going!

My Ruby on Rails Experience, Part 4

This is part 4 of the series; part 3 is here.

I just finished another 14-hour Rails coding session and things are still going fairly well. The data structures that were originally implemented using my custom PHP tuple code have translated into about 50 SQL tables stitched together using the Rails ActiveRecord framework.

I've only encountered one design issue so far with Rails, which I've posted to the Rails forum. Here's the issue:

I have a School object and an Address object which are mapped to SQL tables called "schools" and "addresses", respectively. Since a School can have an Address, the schools table contains an address_id column which references a row in the addresses table. So far, so good: this is standard database design.

In Rails, if table A contains a reference to table B, then the Ruby class A is marked with a "belongs_to: B" and the Ruby class B is marked with "has_one: A". Then, if you turn dependencies on, Rails will automatically destroy A if B is destroyed. In the Rails tutorials, they often use A=Invoice and B=Order, so if an Order is destroyed, its Invoice is destroyed as well.

The problem is, in my case A=School and B=Address, and it makes no sense for the School to be destroyed when the Address is destroyed; it should be the other way around.

At first glance, it looks to me that ActiveRecord is assuming that if a table A contains a reference to a table B then table B is the parent of the relationship. Based on my simple use example, this is often not the case; indeed, it's often the other way around.

The net result so far is that I'm unable to use the built-in dependency mechanism to do automatic propagation of destruction and will have to write custom code instead. This sucks. My hope is either that I'm missing something in the documentation or that Rails is fixed to deal with this common use case.

Now that I've got all the entity-relationships implemented, it's time to write some application logic.

Part 5 of this series is here.

My Ruby on Rails Experience, Part 3

This is part 3 of the series; part 2 is here.

I just finished a 14-hour porting session of my application from PHP to Ruby on Rails. So far, I've had a very good experience. In a relatively short amount of time, I was able to define around 15 domain objects, map them and their relationships to SQL, create their corresponding CRUD screens, add user login authentication, and create a simple home page with menu. In addition, I added several custom features such as a template helper method for editing HTML fields using the WYSIWYG FCKEditor.

The main issue I had was related to the default naming convention for SQL tables and their corresponding models. My domain includes classes like Syllabus, Curriculum, Class, Template, Reference. Each of these caused a problem when using the Rails framework:

• Syllabus has the unusual plural form Syllabi.
• Curriculum has the unusual plural form Curricula.
• Class is a Ruby reserved word.
• Template is an instance variable in ActiveController.
• Reference is an SQL reserved word.

I managed to overcome the first two problems by using the Rails set_table_name feature. I overcame the last three problems by renaming my classes to Klass, Skeleton and Link.

Tomorrow I'm going to improve the look of the CRUD screens and start to add some application logic.

I'm having a great time learning Ruby and Rails; it reminds me a lot of the thrill of learning Smalltalk and its corresponding framework.

Part 4 of this series is here.

My Ruby on Rails Experience, Part 2

This is part 2 of the series; part 1 is here.

After installing Ruby on Rails, the next step was to upgrade my MySQL 4.1 server to version 5.0 and migrate my existing database. This took about 30 minutes, thanks to the flawless MySQL installer.

The next step was to select a Ruby IDE. I ended up picking RadRails, an Eclipse-based IDE with a ton of extensions for both Ruby and Ruby on Rails. In a couple of minutes I was able to define a default Rails application, define a web server, and access the application; all from within the IDE.

Part 3 of this series is here.

My Ruby on Rails Experience, Part 1

This blog series will document my experience porting a non-trivial software application from PHP to Ruby on Rails.

The first thing I did was to visit the Ruby On Rails site. Then I clicked on the download menu and followed the instructions to get hold of Ruby Gems. This took me to RubyForge. After downloading and installing Ruby Gems, I figured out that I needed to download Ruby first. Duh. Shouldn't the Ruby on Rails site suggest this before downloading Ruby Gems?

Anyhow, I went to the main Ruby language site to download the latest version of the language. The download link there took me to the RubyForge page for the language. Then I downloaded the latest release and ran the installer. When the installer asked me for the directory, the "Install" button refused to highlight and let me continue. I got around this obvious bug by adding and then immediately removing a letter from the install path; at this point the installer let me continue.

After installation, I noticed that Ruby Gems was automatically installed by the language installer, therefore making my original install redundant. So I removed the initial installation of Ruby Gems and used the one that comes with the language instead. Finally, I used Ruby Gems to install Ruby on Rails and everything seemed to work.

When I created my first demo by typing "rails demo" and the ran it using "ruby script/server", the welcome page at "http://localhost:3000/" came up in my browser with the top heading truncated. I looked at the source of the page and it looks like the style sheet is a bit messed up.

Overall, my installation experience wasn't too bad, but could easily have been better. My recommendations to the Ruby crew are:

• fix the installer bug
• on the Ruby on Rails site, instruct people to download Ruby, not Ruby Gems
• fix the style sheet on the demo program so the top heading is not truncated

My next step is to create a simple home page for my product that allows me to add, view, modify and delete a simple education artifact.

Part 2 of this series is here.

New Venture, Part 7

This is part 7 of the series; part 6 is here.

My working vacation to Thailand was very productive, and as a result I'm about one month ahead of schedule. I consider the current PHP-based prototype an alpha version because it implements a decent subset of the final functionality without stuff like security, content versioning, scalability and internationalization.

The next step is to port the PHP code to Ruby on Rails. I'm hoping to get an initial port done in about a week, at which point I'll add the additional features necessary for an invitation-only beta 1 release at the end of December.

Since I'm not familiar with Ruby on Rails, I expect the initial port will not take full advantage of the language or the framework. It's not a big deal though because I still have plenty of time in the schedule to polish the design and code. I will blog any interesting things I find out while I'm doing the port. It should be a lot of fun!

Part 8 of this series is here.

Indonesia and Thailand

I just got back from a great two-week trip to Indonesia and Thailand. My brother Blair lives in Indonesia, so the first half of my trip was spent catching up with him and enjoying Jakarta. The second half of my trip was spent in Phuket, playing during the day and programming at night. My Thailand photos are here. My favorite one is me on an elephant.

New Venture, Part 6

This is part 6 of the series; part 5 is here.

It's been a month since my last update, and I've made very good progress on the prototype of my education product. At this rate, the prototype will be finished before the end of the year at which point it will be time to create the production version.

I've known all along that the PHP prototype is 100% throw-away code, and I'm reading some books on Ruby to make sure it's the right choice for the production code. Since I have a strong background in Smalltalk, I've found the language quite easy to learn with just a few areas that don't initially impress me. I'm going to wait until I've written a bunch of Ruby code before making any criticisms though, because it's possible that there are some good usability reasons for the parts I don't like.

When I have a little more free time I'm going to blog about some programming language ideas of my own. This might sound odd, but I don't think that programming languages of the future are going to be object-oriented, at least not in the sense that Java, Smalltalk and Ruby are. Stay tuned for more details on this topic.

Part 7 of this series is here.