I’ve been messing around with Ruby and Rails lately, and generally liking what I’ve found. In many ways, this is really the nicest framework I’ve ever used for solving the types of problems it aims to solve… Here are some notes made along the way.
After instaling the ruby gem for this handy looking library, I noticed that it wouldn’t actually produce rendered pictures of any of my graphs to a file as the documentation’s example shows. A quick look into the code revealed a dependency on the ‘dot’ utility from GraphViz. RPMs of this are widely available for Red Hat Linux, and if you using Darwin Ports on OS X a simple ‘sudo port install graphviz’ will get you going…
While fiddling with the RollingFileOutputter in Log4r, I somehow got the idea, possibly from misreading either the documentation or somebody else’s commentary somewhere, that the options hash to the constructor took a parameter called ‘count’ along with ‘maxsize’ and all the other usual things you’d expect a rolling log system to want.
It doesn’t. Perusing the source code for RollingFileOutputter shows that although there’s an instance variable called ‘count’ that’s used to figure out what to name the next log file, the only things that ever happen to this variable are its zeroing out at initialize-time, and its being incremented whenever a rollover condition (current file size or age) is hit.
As such you can’t expect to automatically rotate through four log files ‘mycrummy-00000.log’, ‘mycrummy-00001.log’, etc., with rollover back to 00000 at the end… If you run long enough you’ll eventually end up looking at ‘mycrummy-867530.log’ (or whatever) which probably isn’t quite what you’re after.
This should be pretty straightforward to fix, and depending on how active Log4r is, I’d be happy to submit a patch, although I’m still new to Ruby and probably not as appropriately efficient and idiomatic in its use as I ought to be. Either way, I remain curious as to whether the current behavior is an oversight, a by-design intention, or just incompatibility with a deranged and unreasonable personal fetish of mine about how rolling log files should work. I’d be happy to find out, and will freely bear any necessary culpability for whatever deranged and unreasonable personal fetishes I may have.
Anybody out there know?
Having played with Rails for a couple of months, I’ve noticed something really strange about the Rails community… something rare enough that I’m not used to seeing it in Developer World.
They’re nice.
And helpful.
Above all, many folks in the Rails community are nice and helpful in such a conspicuously generous way that it makes working with Ruby and Rails, something that’s already intriguing, fun and pleasant, even more so.
I don’t know what exactly made them this way. Is it something about the experience of working with these technologies that brings out more pleasantness in people, or inspires great reductions in obnoxious behavior? Is it a function of the type of people attracted to this environment? Or is it just that the initial core of the community has been so manifestly non-dickheaded that it’s managed to inspire others to emulate a positive ideal rather than an unpleasant one?
Things I haven’t seen much of:
They’re weird. Weird I tell you. But it’s a good kind of weird.
The following is a brief description of a problem I recently encountered while working on a Rails project. I haven’t had time to fully research what happened, so some of what appears here may be tantamount to a yeti sighting. Any Rails cluelessness, general ineptitude, or incalculable ignorance demonstrated below are solely my fault. It’s my hope that if someone googles around trying to solve a similar problem, they may stumble across this and find it modestly useful.
The problem was as follows. I had a Rails app that had been working correctly for several weeks. During deployment I had to switch from filesystem backed session storage to database session storage to deal with the fact that the application was being served by multiple web servers lying behind a load balancer. I altered my environments.rb in the usual recommended manner, created a sessions table in MySQL, and was off to the races. Or so I thought…
The app proceeded to basically work… except the flash text I was using to communicate status text never went away. There it was… haunting me from page to page… “Login successful!” Thank you, but I got it the first time. Begone, dam-ned unsightly green box that looked fine the first time, but that doesn’t still need to besmirch my otherwise pristine browser window!
Switching back to filesystem sessions made the problem go away, and the flash returned to behaving as usual. Going back to the database restored the problem.
My configuration was Rails 1.0.0, Ruby 1.8.4, and the 2.7 mysql gem. I was running a 4.1.x series MySQL, and I tried this on both a Mac OS X system, and two Red Hat Enterprise Linux servers with the same results.
After I groveled in puzzlement in the rubyonrails IRC channel for a while, Jeremy Durham and Marcel Molina both suggested switching to edge rails with ‘rake freeze_edge’. Given that time was running short, the problem appeared persistent, and I’m a newcomer to the source code of Rails itself and not yet entirely confident at my ability to troubleshoot apparent oddities in it (or even yeti sightings), I did this…
... and the problem utterly went away. This leads me to suspect (although remember, I may have seen the yeti here somewhere) that something was a bit amiss in or around the 1.0.0 Rails gem involving database backed sessions, and that this problem has been remedied since then in the Rails subversion tree. Everything else appears to not have suffered in any way from switching to the trunk version of rails.
In summary, as much for any search engines indexing this page as for any human readers my problem was:
Mike Clark has written an interesting blog post on the changes to Rails unit testing in Rails 1.0. He includes some justification and performance measurements.
If you’ve been reading Agile Development In Rails, then this will save you a little bit of confusion by making some sections of chapter 12 work properly.
While following the discussion in chapter 12 of Agile Web Development in Rails , using MySQL as my database, I had a few frustrating moments with test fixtures.
I found that the database contents specified in my test fixture were not being restored between the runs of individual test cases, thereby causing every test after the first one that removed something from the database to fail.
Some digging around seemed to show that the behavior had changed in Rails 1.0 and that the text of my printing of the book seems to be, understandably, a bit out of date.
It seems that Rails now, by default, relies on database transactions to restore the database to its pre-test-run state. If your MySQL setup is using the defaut MyISAM engine for its tables, transactions aren’t supported, and the database will not be returned to its initial state in this scheme.
To deal with this problem you have two options:
test/test_helper.rbin your Rails project to disable transactional fixtures to set
use_transactional_fixtures=falseand
use_instantiated_fixtures=true
This gets things behaving as the book (which BTW is very good) would lead you believe they would.
Post a new entry