Ruby Reports

Blog Has Moved

2007-01-21T01:01:58.435362-08:00

Ruby Reports 0.7.0

2006-12-25T16:58:30.320809-08:00

Ruby Reports 0.7.0 : The St. Nick Edition
------------------------------------------------------------

Ruport now has a brand new formatting system, some massive cleanup in
the internals, and merry chunky bacon for all!

== What is Ruby Reports? ==

Ruport is a framework specialized for business reporting. It provides
a custom toolkit that has features such as database interaction, data
manipulation, extensible formatting, and flexible report generation.

Ruby Reports makes reporting less painful by providing a simple and
consistent way of developing your applications. This lets you focus on
your task without undue friction.

== Installation ==

sudo gem install ruport -y

Detailed instructions here: http://ruport.infogami.com/Installation

== New To Ruport? ==

Please see our not-yet-complete getting started guide:
http://ruport.infogami.com/Getting_Started_With_Ruport

== Resources ==

Links to our mailing list, developer wiki, some basic examples, and
other resources can be found on our project homepage:
http://ruport.infogami.com

== Changelog ==

changes since 0.6.1

- The formatting system has been replaced with a new approach which is hopefully
 more flexible and simple.  Many of the plugins have gained some new features.

- All of the legacy formatting tools in format.rb have been removed.
 (Namely, Text Filters)

- rope is now implemented via Ruport::Generator, which can be customized to
 build your own code generation tools for Ruport.

- Several simplifications have been made to the Report DSL.  (Now has
 erb/textile methods and other feature enhancements)

- Constructor for Data::Table added to Kernel for convenience.  [ Table() ]

- Invoice engine removed.  Will be re-released as an extension soon.
 See the Ruport mailing list for a temporary solution

== Project News ==

We've put together a project roadmap which we'll update as things progress:
http://stonecode.svnrepository.com/ruport/trac.cgi/wiki/ProjectRoadmap

This is helpful if you want to see the 'big picture' of where Ruport is headed.

== Acknowledgments ==

Thank you to Stefan Mahlitz and llasram for the patches!


----------------------------------------------------------------------------

That's all folks.  any questions or comments, feel free to use the
Ruport mailing list!

New Default output for text format.

2006-12-22T00:54:35.058978-08:00

Our old text format centered everything, which looked like this:

+--------------------------------------------------------------------------+
| id |    name     |    phone     |    street    |      town       | state |
+--------------------------------------------------------------------------+
| 1  |    Inky     | 555-000-1234 | Druary Lane  |   Union City    |  CT   |
| 2  |   Blinky    | 525-0529-123 | Apple Street |   Robot Town    |  NJ   |
| 3  |    Clyde    | 247-219-4820 | Sandbox Hill | Alvin's Landing |  PA   |
| 4  |   Pacman    | 283-102-8293 |  Rat Avenue  |    Southford    |  VT   |
| 5  | Mrs. Pacman | 214-892-1892 |  Conch Walk  |    New York     |  NY   |
+--------------------------------------------------------------------------+

Which isn't that bad.

But the new alignment is certainly an improvement for most data:

+--------------------------------------------------------------------------+
| id |    name     |    phone     |    street    |      town       | state |
+--------------------------------------------------------------------------+
| 1  | Inky        | 555-000-1234 | Druary Lane  | Union City      | CT    |
| 2  | Blinky      | 525-0529-123 | Apple Street | Robot Town      | NJ    |
| 3  | Clyde       | 247-219-4820 | Sandbox Hill | Alvin's Landing | PA    |
| 4  | Pacman      | 283-102-8293 | Rat Avenue   | Southford       | VT    |
| 5  | Mrs. Pacman | 214-892-1892 | Conch Walk   | New York        | NY    |
+--------------------------------------------------------------------------+

Think the old layout looks better? Not to fear, you can get it back:

my_table.as(:text) { |e| e.layout.alignment = :center }

Thanks to llasram for contributing this!

Roadmap!

2006-12-05T19:02:43.305829-08:00

Come take a look at the Ruby Reports Roadmap and make some suggestions if you'd like!

Slow and Steady, there will be an 0.7.0 yet!

2006-12-03T23:56:31.022718-08:00

Hey guys,

Just a quick status update to let you know even if I'm a bit behind on things, I'm still planning on replacing the formatting system in trunk with the new one in the phoenix branch.

Here is a sneak peak at the renderer look and feel and the plugin look and feel. Compare it to the related Old formatting engine and old plugin.

It seems like progress to me, but you might need a little understanding of Ruport's internals to really see why phoenix is going to make life easier. I plan on writing some nice articles about that, as soon as I free up some time :)

Ruby Reports 0.6.1 Released

2006-11-23T13:44:32.854888-08:00

Reposting from the Ruport Mailing List

== Overview ==

Ruport 0.6.1 is now out and features the performance enhancements
we've been discussing on the list, as well as any outstanding bugs
with 0.6.0

It also includes better test coverage and improved API documentation.

Enjoy!

== Changelog ==

changes since 0.6.0

- Fixed Table.load() bug.  (Now accepts block properly)
- 100% C0 coverage for Query via Mocha. (Thanks Marshall!)
- Row by row Query iteration no longer grabs entire result set first
- Major performance enhancements to Groupable
- Reformatted and enhanced API documentation
- Added simple table interface example

== Project News ==

=== Ego Statistics

>> 5452+4532
=> 9984

That's file downloads + gem downloads, and it's about to approach 10000!

Our mailing list is up to 73 members, too :)

===  Ruport 0.7 Planning

- Ruport 0.7 will be out December 25th, 2006.  I know that this is
much delayed from my original speculations, but I want to be sure we
have time to do it right, and also try not to fail school :)

The freeze for accepted feature additions to 0.7 will happen at
midnight EST tonight, so if you have any wild and crazy ideas that we
haven't already mentioned and approved, let us know!  You can see the
list here:
http://tinyurl.com/yen7ut

0.7 will be merged into stable on or before December 15th, so if you
find any bugs with 0.6.1, please report them before then so we can get
another release out before 0.7

Since there will be *major* changes in 0.7, I'll likely release a
snapshot called 0.6.99 on the 15th.   Keep an eye out for that.  Also,
in the coming week, testers and the adventurous are invited to start
playing with the code in trunk.

=== OnePointOh, what's that?

- The roadmap for critical milestones for 1.0 will be announced some
time on or before December 1st.  I will have a draft out to the
mailing list for review within the next day or two.

If people are interested, I'd be happy to hold another round table
discussion on IRC so we can discuss and argue about what belongs in
1.0 and what doesn't.

== Acknowledgments ==

- Marshall T. Vandegrift for the patches for Query
- Dudley and Dinko for helping with documentation.
 (Even if they're devs, documentation SUCKS)
- Greg Gibson of BTree Technology for funding a day of work on docs.

There are also people who are doing cool stuff on the development
branch that I didn't mention, but you'll get your kudos on 0.7,
promise!

----------------------------------------------------------------------------

That's all folks.  any questions or comments, feel free to use the list :)

Mailing List Moved!

2006-11-19T12:29:24.411664-08:00

To deal with various problems with our current setup and possibly gain some new bells and whistles, we'll be moving to google groups.

You can sign up here: http://groups-beta.google.com/group/ruby-reports?hl=en

The new list email address will be: ruby-reports@googlegroups.com

I plan to deprecate this list on stonecode.org on 2007.01.20, so please move to the new list! :)

I will keep the list up for some time, but only for archival purposes and also to catch anyone following an old link. After 2007.01.20, please do not email the stonecode address anymore.

Data grouping that is more friendly to the elderly

2006-11-18T13:46:05.572798-08:00

So,

I received a few reports about people actually dying of old age waiting for grouping results to come back in Ruport. Since I got tired of the blood being on my hands (and because one of my jobs required it), grouping by data tags(Groupable) is now a hell of a lot faster.

How much faster you say? Orders of magnitude!

Here it is on 100 records:

real    0m2.063s
user    0m1.976s
sys     0m0.052s

On 2000:

real    0m9.088s
user    0m8.677s
sys     0m0.388s

on 4000:

real    0m31.545s
user    0m29.370s
sys     0m1.388s

Ut oh...  That's not good.

So, due to be out in 0.6.1, you'll see performance more like this:

100:

real    0m2.047s
user    0m1.968s
sys     0m0.068s

2000:

real    0m2.395s
user    0m2.308s
sys     0m0.060s

4000:

real    0m2.774s
user    0m2.620s
sys     0m0.092s

Note the bottle neck in the second set of examples is actually loading
in the big old 20000 line CSV. If you're curious how long it takes to
convert it into 6000 groups, here's the total runtime:

real    0m4.442s
user    0m4.016s
sys     0m0.228s

Hooray!

We're gonna need a new formatting system.

2006-11-11T23:29:35.315091-08:00

When I first wrote Alioth, I was really proud of it.

It involved a bunch of sick metaprogramming tricks, and the underlying idea was cool. One engine per concept, one plugin per output format. Easily share reusable code while leaving room for extension. The unfortunate problem is that I tried so hard to keep engine and plugin decoupled, that they ended up needing this cumbersome indirection to talk to one another. There is also this peculiar problem with the fact that the DSL implementation for our formatting system was so complex (unnecessarily) that it makes hacking on the system really hard. (It's not too tough to build stuff with it once you get your head around it, but tweaking the system itself is rough). We've hit this dead end with it where in order to extend it, we have to abstract a lot of the dangly parts so that you never have to see them as an engine or plugin writer, which means you have to learn more and more terms that get you farther and farther from the most powerful tool you have available to you, plain old ruby.

Things like supporting a build_header method in an engine that relied on access to your plugin would become something like this.

class SuperCoolEngine < Ruport::Format::Engine

   renderer do
     build_header
   end

   # other engine code omitted
end

class SuperCoolPlugin < Ruport::Format::Plugin
   helper(:build_header, :engine => :super_cool) { |eng| ... }
end

Blissfully ignorant that anything but the active_plugin exists, and utterly refusing to relinquish control of process until the very end of rendering, the engine needed a helper inside of your plugin it could pass itself into so you can do some work with it.

This kind of code, once grokked, can be quite powerful and not very painful to remember. However, I think the first thing people think when they encounter this sort of indirect interaction is WTF

We need to fix that.

We also need to get rid of the parts of the DSL which exist only to gloss over the fact that we've got a super complex system designed underneath a relatively simple interface. When I wrote code to generate this interface for you automatically just so you can use Alioth, a lightbulb should have turned on in my head. It finally has and we're going to react in a big way.

This formatting system will be gone before Christmas, hopefully earlier. The underlying concept of the way we do formatting in Ruport will stick around, so if you've been enjoying our idea of a single specification of a process to generate a number of different formats, that won't change. We'll also be doing whatever we can to make this system even more friendly to extension than it already is.

Finally, for those who've learned Alioth or used it extensively, we're going to be working on an abstract layout system. Layout was not something we considered directly when developing the existing formatting system, and that's starting to show. We're not certain just yet what this layout system will look like, but just know that we want to provide a really high level way for you to tell us how you want your report to be arranged, so that you won't need to muck with low level formatting details unless you want to.

This is a tall cup to fill. I really am counting on folks on the mailing list and IRC and blogs to help us define a system for formatting/layout that really meets the needs of our community. Alioth was a great proof of concept, but the complexity it has dragged along with it is starting to make us nervous. Ruport is supposed to relieve headaches, not cause them, and I think by Christmas, we can do that. We just need your help along the way.

acts_as_reportable in 30 seconds or your money back

2006-10-25T09:39:46.444394-08:00

Since 0.6.0 saw our rails support get pluginized, you may want to know how to install it.

Dudley has done a nice job describing this on the ActsAsReportable Trac.

[ANN] Ruby Reports (Ruport) 0.6.0

2006-10-24T00:35:36.049922-08:00

After a lot of hard work from our developers and contributors, we finally have 0.6.0 ready for public consumption. We were more-or-less on schedule, too!

From the release notes:

This release features a number of new features, some performance enhancements,
and several bug fixes.  Ruport now has additional data grouping and
manipulation tools, a new LaTeX plugin for rendering tables, and support for
timeouts and exception handling in our report runner.  Additionally, full
support for ERb within SQL queries was added.

The complete announcement is on the mailing list. My exhaustion created some typos, so please see the (minor) corrections too.

Ruport Presentation at RubyConf

2006-10-22T17:45:12.860902-08:00

So, I just finished my RubyConf talk.

I basically talked about the high level stuff in Ruport and gave the motivation behind the project.

However, I also did a little demo of my efforts on making a statistics report for RubyForge.

I've put the slides online, but you'll need to wait until I get it closer to completion before I unveil the RubyForge stats stuff :)

I got pulled into the hallway by a bunch of folks who are interested in helping out, which is super exciting. Hopefully the mailing list will start buzzing now. :)

Great thanks to David Pollak, my mentor, RubyCentral for putting this together, and to Google for the opportunity. Also, great thanks to the developers and contributors of Ruport who have given me a project worth talking about!

In other news:

0.6.0 will be out very soon (it's feature complete and tested already), but you'll notice that i've been making a few branches in SVN. There were some wild and crazy ideas that we came up with out here at RubyConf, and I'd like to see where they lead us. Looking forward to hearing from you guys on the list, and hope you find the slides neat, if a bit minimalistic.

Keep an eye out for Dinko's Ruport News, which will fill in more details about all things Ruport.

TextPlugin No Longer Useless

2006-10-12T16:07:45.689100-08:00

So, Ruport can do pretty nice little text tables which are ultra sexy when working in IRb. The problem with them? Well, the algorithm was something like O(n^3) or worse, for no real good reason. This means if you had more than a couple hundred rows, you could kiss this format's usability goodbye.

Thanks to Mathijs Möhlmann, we're now down to something that scales a little more sanely. A run against 8000 rows took about 8s for me against some fairly boring rows.

You can see the thread on the mailing list for more details.

Of course, this is put to shame by FasterCSV(~1.5s), but that's because FasterCSV doesn't need to consider layout.

All in all a wonderful contribution to Ruport! Mathijs has also provided a speed up to HTMLPlugin.

I think this certainly makes him contributor of the week. :)

These two features will be in 0.6.0

Acts As Reportable gets it's own mini legs to walk on

2006-10-09T02:28:58.412420-08:00

Hooray! Dudley announced the other day that Rails is officially 'someone elses problem', and by someone else, he meant his. :)

He and Nick Mulder have taken the initiative to break actsasreportable into its own plugin.

The gory details are on the mailing list.

Sorry for not mentioning this earlier. I've been swimming in Perl-land. ;)

Gems on parade

2006-10-09T02:22:07.439822-08:00

>> require "ruport"
>> Ruport.configure { |c| c.source :default, :dsn => "dbi:pg:test", :user => "gforge" }
>> a = Ruport::Query.new("select count(*) from gem_downloads")
>> puts a.result
+---------+
|  count  |
+---------+
| 6277422 |
+---------+

Damn that's a lot of downloads

Sending Ruport to BetaBrite

2006-10-01T16:04:22.057956-08:00

Aaron Patterson has released a new version of the BetaBrite library for Ruby. This is an LCD Screen tool. Though this has absolutely nothing to do with Ruport, I couldn't resist trying out an awesome hack that let's you write to Aaron's LCD Screen and get a photo back:

Just a fun example of what some other Ruby hackers are up to. If you want to check it out for yourself, adapt the snippet below:

require "drb"
require "rubygems"
require "betabrite"
DRb.start_service()
obj = DRbObject.new(nil, 'druby://eviladmins.org:9000')

File.open("out.jpg", "wb") { |a|
  a.write obj.write_simple("Ruby Reports")
}

Ruport Mini Fork is coming!

2006-09-29T01:00:14.469149-08:00

Oh yes, there will be a tiny fork in the road of Ruport.

Or should I say, the railroad.

[ANN] Ruby Reports 0.5.4 Released

2006-09-25T00:10:04.086130-08:00

Yet another maintainence release of 0.5.x

This brings a number of bug fixes, a new example for basic grouping, and a performance enhancement for Table#column_names=

For the full set of notes, see the mailing list announcement

The CHANGELOG for this release has been posted below.

changes since 0.5.3

- Fixed a bug where Table#<< would fail silently if an object could not be
  converted to a Record

- Fixed a bug where setting column names after a table was initialized without
  them caused Table to break.

- Example added for basic grouping functionality

- Table#column_names= reworked to address a performance concern.

- Collection#[] moved to Table#[], since Set#[] is not implemented.

- Quieted some warnings discovered by pat eyler

Ruport Developers Meeting Summary

2006-09-19T17:30:27.790749-08:00

The four Ruport devs got together on Monday morning to discuss the future of Ruby Reports and several other interesting things. I wrote a long post on the mailing list summarizing what we talked about. Below is a small outline:

= Topics Discussed =

Documentation of Ruport's Internals for Developers/Contributors
The 'vision' behind Ruport
Solving the formatting system complexity with an Abstract Layout Engine
How to design complex data manipulation features
Ruport 0.6.0 Timeline
Experimenting with using personas for design guidance

You can find the complete summary in the Ruport ML archives. Anyone interested in commenting or asking questions should hop on the list and do so, since we have a lot of 'wild and crazy' ideas that need taming :)

There is also a transcript of the meeting, for those who prefer reading the raw conversation.

A Sad Goodbye to lilo

2006-09-17T20:11:13.427840-08:00

"On the 12th September Rob Levin, known to many as Freenode's lilo, was hit by a car while riding his bike. He suffered head injuries and was in a coma. Rob was being treated at the Neuro Trauma Intensive Care Unit at a local hospital in Houston, Texas where he passed away on Sept 16th." - Freenode News

It is very sad to hear this. Some of the greatest discussions about Ruport have been via Freenode. Though this wonderful service will surely live on without lilo, it is terrible to see him go this way. On behalf of Ruport, I'd like to offer deep condolences to the family and friends of Rob.

0.5.3 Still Stuck in Gem Never Never Land

2006-09-16T11:14:20.146421-08:00

UPDATE: Tom ran a manual sync which got the gem into rotation... Thanks!

Problems with Rubyforge seem to be just a 'part of life' for Ruport, so I'm sorry to say that 0.5.3 hasn't made it in to the gem system yet. I've done my usual badgering of poor Tom Copeland, and hopefully it'll be available soon.

in the mean time, you can grab it via the download page

[ANN] Ruby Reports 0.5.3

2006-09-15T22:39:39.803023-08:00

= Ruport 0.5.3, the "Sleepy Turtle" edition =

== What is Ruport? ==

Ruby Reports is a software library that aims to make the task of
reporting less tedious and painful. It provides tools for data
acquisition, database interaction, formatting, and parsing/munging.

Ruby Reports provides solid support for processing and formatting all
sorts tabular data.  It also includes tools to help with more
specialized things such as graphing and invoice generation.  It is
highly extensible, so making it fit your particular needs should be
easy.

== Project News ==

The developers of Ruport (James,Dinko,Dudley,and myself) will be
meeting via IRC on Monday, 2006.09.18 at 14:30 UTC

We'll be talking about plans for Ruport 0.6.x as well as tons of other
development related stuff.  Our discussion would likely be boring to
end users, but potential contributors to Ruport or general geeks might
want to lurk at this time.

There is also some API tweaking and feature addition going on in
Ruport's trunk.  Since a merge of these features into stable will
happen in the next couple weeks, testers might want to start trying
out some of the stuff in trunk to see what they think.  If you aren't
already following us via SVN/Trac, then either ignore this or catch up
with us on the mailing list :)

== What's New in this Release? ==

This release is 100% maintainence.  We've uncovered and fixed a
handful of annoying bugs in Ruport, added some tests, and did some
internal cleanup.  If you haven't run into problems, you won't notice
much difference in this release, but should update anyway to avoid
them in the future.

See the CHANGELOG for details, but here's a quick summary:

- rope's build.rb was broken if you used it to generate multiple reports
- I finally removed the 'mandatory data attribute' for Format::Engine
- reorder() was creating tons of unnecessary copies of column_names
- Plugin#rendering_options and Plugin#options now point at two different
  objects.
- Printing out empty tables as text no longer throws an error.

== Installation ==

Ruport and its dependencies can easily be installed via rubygems:

  gem install ruport

If you have trouble or want to try installing manually, see our install guide:

http://ruport.infogami.com/Installation

== Resources ==

You can find more-or-less all of the information we have available via:
http://ruport.infogami.com .  I would recommend subscribing to the
blog since I tend to mention bugs or interesting new features or event
announcements there.

If you need help, We *love* when people use IRC(#ruport) or the Ruport
mailing list.  You can find info about both of these on the Ruport
website.

Finally, Dinko has been doing periodic articles about Ruport for the
Stone Code blog.  These 'Ruport News' articles are great if you want a
very high level look at Ruport from time to time. On the web:
http://www.stonecode.org/blog/?cat=14
Via RSS: http://www.stonecode.org/blog/?feed=rss2&cat=14

== Acknowledgements ==

Greg Gibson of BTree Technology was responsible for uncovering almost
all of the bugs in this release when I was trying to demonstrate
things to him or do jobs for him ;)

ERb support for SQL statements in Ruport

2006-09-15T16:03:07.763281-08:00

One thing I use Ruport a lot for is running the same Query across a few different date ranges or views or (insert minor change here). In work, we often embed some SQL in a report and then just use the usual "hello #{'dlrow'.reverse}" approach. There are two annoying things about this.

They are evaluated immediately, so where you define them matters (we often create functions with a string body and call the function) YUCK!
It doesn't seem obvious if there is a non-sucky way to pull these out of a file and use them.

So now Query and the Report#query method support ERb! If you are using it from within a Report object, it will automatically be evaluated within the context of that report. If you use Query directly, you can pass in a binding to tell it where it should be evaluated.

The ERb is evaluated automatically when the Query object is created, so you don't need to do anything special.

I found this quite handy, so I hope you do too. Below is a very simple example, which is in the trunk/examples

require "ruport"
require "rubygems"

class Foo < Ruport::Report

  SQL = "select * from <%= helper %>"

  prepare do
    source :default, :dsn => "dbi:mysql:foo", :user => "root"
  end

  generate do
    query(SQL)
  end

  def helper; "bar" end

end

Foo.run { |r| puts r.results }

A Quick IRB SQL Client with Ruport

2006-09-10T23:23:06.993670-08:00

>> cheap_sql = Ruport::Report.new
=> #
>> cheap_sql.source :default, :dsn => "dbi:mysql:foo", :user => "root"
=> nil
>> irb cheap_sql
irb: warn: can't alias source from irb_source.
>> def q(*args); puts query(*args); end
=> nil
>> q "show tables"
+---------------------+
|    Tables_in_foo    |
+---------------------+
| account_categories  |
|      accounts       |
|         bar         |
|    chunky_bacon     |
|      companies      |
|    fiscal_years     |
|   journal_entries   |
| journal_entry_items |
|      journals       |
|       periods       |
+---------------------+
=> nil
>> q "select * from chunky_bacon"
+-------------+
| name  | num |
+-------------+
| greg  |  1  |
|  joe  |  2  |
| james |  3  |
+-------------+
=> nil
>> q "select * from chunky_bacon", :as => :csv
name,num
greg,1
joe,2
james,3

One Year of Ruport

2006-09-05T01:50:30.685551-08:00

Here is a one-paragraph per month timeline of Ruport from August 2005 -> August 2006

August(0.1.0)
  Development begins on Ruport as an informal competition between myself and
  JEG2.  The result is that Ruport 0.1.0 is released August 28th combining the
  best of our efforts. (And some ideas stolen from Daniel Berger's Gruf)

September(no release)
  Development continues in house on Ruport, and *Real Work* influences
  what Ruport becomes.  There is no real community to speak of, though a few
  people submit some ideas 

October(no release)
  RubyConf 2005.  I have over 10 people come up to me to talk about
  Ruport.  Most people want graphing support, and PDF support.  These
  things do not show up until *much* later. 0.2.0 release delayed,
  because of feature creep.

November(0.2.0, 0.2.2, 0.2.5. 0.2.9)
  One of the biggest development sprints in Ruport's history.
  This is essentially the start of 'modern' Ruport datastructures,
  which up until this point, weren't even Enumerable!

December(no release)
  The winter is meant to be spent on Ruport.  It is here that I realize how
  far behind Ruport is.  I release the Ruport 0.5.0 Spec.
  (http://stonecode.org/ruport-spec.html)

  I had planned to finish 0.5.0 by the end of January. Needless to say,
  this doesn't happen.  I start the mailing list at this time.

January(no release)
  Ruport slowly gets transformed from dodgey DSL to a library.  I meet
  with Francis Hwang for a code review.  The mailing lists gets its first
  posters.  Dudley Flanders is the very first of these ;)

February(0.3.8)
  After a massively disappointing winter, Ruport finally receives some TLC.
  Simon Claret helps me work on ideas for interacting with ActiveRecord, and
  also submits some PDF table support.  I speak at NYC.rb and get some good
  ideas from the group there.  The new Query model is created at this time, and
  will later be the Only Class That Lives In 0.5.0

March(No Release)
  A seriously boring month.  Some examples are created, not much else.  Talks
  about MailFactory integration begin.

April(0.4.0)
  This month marks a focus on stability, the first time that we've focused on it
  since the start of the project.  I added a bunch of tests and fixed a bunch of
  bugs.  I mention a report DSL, but it doesn't make its way in.

May(No Release)
  A supremely boring month.  I apply for a Google Summer of Code grant, but do
  not announce this on the list.

June(0.4.4, 0.4.5, 0.4.9, 0.4.11)
  Summer of Code begins and development catches ablaze.  The Alioth Formatting
  System is built and replaces the Format::Builder system. acts_as_reportable,
  and the new email system creep in.  All in all, the single most productive
  month in Ruport's history. Dudley Flanders joins as a developer after a great
  round of patches.  Dinko joins the team to begin work on release automation
  and other technical tasks. #ruport becomes a place to hangout on Freenode.

July(0.4.13, 0.4.17, 0.4.19)
  The new Report DSL is implemented which JEG2 claims is the 'sexiest thing in
  Ruport so far'.  Fires are fought inside the new formatting system, and the
  redesign of Ruport's datastructures begins.  Dinko begins Ruport News.

August(0.4.21,0.4.23,0.4.99,0.5.0)
  All of the legacy code from Ruport is removed.  Ruport revisits the idea of
  having a code generation tool, this time around called rope. James Healy
  submits an invoice engine, and a graphing engine, and becomes the 4th
  developer to join Ruport's team.  RuportDay 2006 features a *ton* of
  contributions.  Ruport 0.5.0 is released on the 0.1.0 anniversery.  We begin a
  stable branch of development.