After instaling the ruby gem for this handy looking library, I noticed that it wouldn't actually produce produced 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 ro 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:

* Flame wars

* Unimaginative name calling

* Badgering and condescension about newcomers' misunderstandings and blind spots. Perhaps the environment's cleanliness makes for less of "this kind of obvious":http://blogs.msdn.com/oldnewthing/archive/2006/03/02/542115.aspx (namely the kind of obvious that is just _so_ obvious that it seems to entail multiple pages of painstaking explanation, delivered with maximal sanctimoniousness and profuse patronizing)

* Automatically vicious and defensive reactions to people's problems and questions, where every question is interpreted by default as a personal attack.

They're weird. Weird I tell you. But it's a good kind of weird.

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:

* Flame wars

* Unimaginative name calling

* Badgering and condescension about newcomers' misunderstandings and blind spots. Perhaps the environment's cleanliness makes for less of "this kind of obvious":http://blogs.msdn.com/oldnewthing/archive/2006/03/02/542115.aspx (namely the kind of obvious that is just _so_ obvious that it seems to entail enail multiple pages of painstaking explanation, delivered with maximal sanctimoniousness and profuse patronizing)

* Automatically vicious and defensive reactions to people's problems and questions, where every question is interpreted by default as a personal attack.

They're weird. Weird I tell you.

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.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had a some 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:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> in your Rails project to disable transactional fixtures to set <pre>use_transactional_fixtures=false</pre> and <pre>use_instantiated_fixtures=true</pre>

This gets things behaving as the book (which BTW is very good) would lead you believe they would.

Mike Clark has written an interesting "blog post":http://www.clarkware.com/cgi/blosxom/2005/10/24 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":http://pragmaticprogrammer.com/titles/rails/index.html, then this will save you a little bit of confusion by making some sections of chapter 12 work properly.

Mike Clark has written an interesting "blog post":http://www.clarkware.com/cgi/blosxom/2005/10/24 on the above changes to Rails unit testing in Rails 1.0. He includes testing, and included some justification and performance measurements. You can read it at:

I've been messing around with Ruby and Rails lately, and generally liking what I've found. Here are I'm thinking about documenting some notes made along the way. jottings on what I've run into under this page.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some 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:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> in your Rails project to disable transactional fixtures to set <pre>use_transactional_fixtures=false</pre> and <pre>use_instantiated_fixtures=true</pre> <pre>use_instantiated_fixtures=true</pre>.

This gets things behaving as the book (which BTW is very good) would lead you believe they would.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some 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:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> in your Rails project to disable transactional fixtures to set <pre>use_transactional_fixtures=false</pre> =use_transactional_fixtures=false= and <pre>use_instantiated_fixtures=true</pre>. =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some 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:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit <pre>test/test_helper.rb</pre> =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of "Agile Web Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , using [[MySQL]] as my database, I had some 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 Rail now, by default, 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. state.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of "Agile Web _Agile Development in Rails":http://pragmaticprogrammer.com/titles/rails/index.html , Rails_, using [[MySQL]] as my database, I had some 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 Rail 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.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

While following the discussion in chapter 12 of _Agile Development in Rails_, Rails_ by Dave Thomas, using [[MySQL]] as my database, I had some 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 Rail 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.

To deal with this problem you have two options:

* *Use MySQL Transactions:* Create your database tables using the transaction-supporting InnoDB engine. There's a good chance you want to do this for other reasons anyway.

* *Change Rails' Behavior to that of pre-1.0:* Edit =test/test_helper.rb= in your Rails project to disable transactional fixtures to set =use_transactional_fixtures=false= and =use_instantiated_fixtures=true=.

database...