Posted by Doug
Thu, 13 Oct 2005 21:36:14 GMT
I thought it was a one off, but I’ve got several data classes in my Rails projects that aren’t derived from ActiveRecord. I’m using these to encapsulate some data and logic that doesn’t necessarily need to be it’s own table associated with some ActiveRecord model. Let me give a concrete example.
I now have three models that need to record a time. It’s not a DateTime or a Date. It’s just a time: “7:00 am”. I need to be able to sort these models based on that 12 hour time. I suppose I could have just stored the time as a 24-hour time integer. Even if I had done that, there still would have been some helper methods needed to convert to a 12 hour clock string. So, this approach seems as good as another.
WARNING: I’m proving to be pretty bad at naming classes. This example illustrates that point.
So I have a TimeString class. It’s got hour, minute, and ampm accessors. It also knows how to dump and load itself to/from YAML. My ActiveRecord models have special accessors to contain one of these TimeStrings. I have a before_save filter to convert the contained TimeString to a YAML string and save that in the database. In essense I have a column in my database that acts_as_object. I think a component to implement this feature would be generally useful.
The code looks like this:
class TimeString
attr_settor: :hour, :minute, :ampm
# some class implementation details
def dump
YAML.dump(self)
end
def TimeString.load(string)
YAML.load(string)
end
end
And it’s used like this:
class MyClass < ActiveRecord::Base
attr_accessor :time
before_save :save_time
def save_time
self.time_obj = self.time.dump
end
def time
@timex ||= TimeString.load(self.time_obj)
end
def time=(obj)
self.time_obj = obj.dump
end
end
This assumes you have a database column called time_obj. That column contains the YAML dump of the object. The time method is an accessor that returns a real TimeString object. The time= method takes a TimeString object and dumps it to the database column.
The technique is both neat and hackish at the same time. It’s proved to be useful. The pattern is fairly generic. This example uses my TimeString class that you may or may not think is necessary, but could really apply to any class you wanted to contain. The only thing that’s proved to vary is the obj= method on the ActiveRecord model. That varies based on how you want to be able to set the contained object. In some cases I want to pass in an already instantiated object. In others I want to be able to pass in some parameters to create the contained object.
I’m not exactly sure how to go about doing it, but I like the idea of converting this into an acts_as_object class method that would set up the appropriate stuff.
Posted in Programming, Ruby on Rails | Tags Rails | 2 comments
Posted by Doug
Mon, 10 Oct 2005 03:30:48 GMT
I was actually hoping to title this blog post “Five Easy Steps to Faster Testing.” Unfortunately not. Here’s why I’m complaining about testing performance:
$ time rake
blah blah blah blah blah
Started
.................
Finished in 81.306421 seconds.
115 tests, 353 assertions, 0 failures, 0 errors
blah blah blah blah blah blah
Started
.......................
Finished in 85.885546 seconds.
89 tests, 703 assertions, 0 failures, 0 errors
real 3m5.970s
user 1m48.390s
sys 0m8.410s
Ugh. It get’s really, really annoying to have to do that a few times in an evening.
So, I had heard that SQLite was really, really fast. I thought that most of my bottle neck in testing is loading and unloading the database. I’m still using MySQL with old MyISAM files; so not transactions for me. The directions on How to use SQLite in Ruby on Rails seemed so clear, I was sure I could get it working in no time.
My plan was to leave MySQL as my development and production databases, but switch to SQLite for testing. The first problem turned out to be what I’m calling a bug in DarwinPorts portfile for SQLite. It appears that swig must be installed before you install SQLite, but it’s not a dependency. So, install swig via ports, sqlite3 via ports, and sqlite3-ruby via gems. OK, I’m working.
Second problem: rake wants to just dump the structure from development and then load that into testing. But the schema from MySQL isn’t compatible with SQLite. OK, I modify the Rakefile to not do that.
So now I’m running my tests. Keep in mind all my tests pass with MySQL. The first thing I note is that my tests don’t seem to be running that much faster. Then I see a test fail. Then things get really slow; no wait, it’s hung. The thing is I have no idea why my test failed and then another one hung. By this point I had sunk more time into it than I had to spare. I decided to punt.
I don’t mean to trash-talk SQLite. I’m sure it’s a marvelous database and I’m the screwup for not being able to get it to work smoothly. But, I did loose probably four or five hours to this experiment. I had to write something to account for my time.
Posted in Test Driven Development, Ruby on Rails | Tags Rails, SQLite, testing | 1 comment
Posted by Doug
Sat, 17 Sep 2005 06:05:04 GMT
It’s been a pretty good couple of days for Rails coding. I’ve done a bunch of validation tweaks, mostly finished the calendar, and begun on group scheduling.
I was having problems using embedded hidden forms for all my edit and add links on events. I did a couple things to improve the performance of the page. First, I ditched the embedded forms and made them separate page loads. It was cool to have the embedded forms the magically appear and disappear; I miss it. Several people suggested I just embed a single edit form and a single add form and use Javascript to update the values before it’s submitted. If I were a Javascript stud that’s what I’d do. Maybe when I’m all grown up I’ll be smart enough to do that.
The other thing I did was change how I tested for events on calendar days. I had a find_by_day method that would basically find(:all).select { |expr| expr.occurs_on?(day) }. I’d then loop over the calendar days calling that function. What I decided to do instead was simply collect all the TimeExpressions into a single list in the controller and let the view do the select for each day. This exposes more of the model’s logic a little. I like the way the code looks to simply calll find_by_day for each day. However, only doing one find and then doing the selects in the view shaved a fair amount of time off the page load.
So I’m doing some “group scheduling” too. It’s quite limited. The TimeExpressions I’ve been working with is really to build a “free-busy” schedule of available times to book appointments. What I need to do is allow a user to invite another user to an appointment. These two users may have to negotiate an appointment time. So, it makes sense for my Invitations to acts_as_versioned. I had seen acts_as_versioned discussed a couple times on the maling list. Let me just say, I’m really happy with it. I was able to set it up without too much fuss. It works pretty much exactly as advertised. Thanks technoweenie!
Finally, to send out the initial invitations I finally got around to coding some AJAX stuff. It’s quite simple; just a link that makes a single request to send the invitation. I felt so sophisticated! Only about an hour or so to get it studied, written, tested and committed.
Posted in Programming, Ruby on Rails | Tags AJAX, Calendars, Rails, Ruby | no comments
