FasterCSV API Shim for 1.9

FasterCSV has become csv.rb in Ruby 1.9. This is awesome, but it does change the names of the constants, which means your code will not run without some modification on 1.9

Ruport wants to work peacefully on both 1.8 and 1.9 without too much duplication of effort, so here's the hack JEG2 and I came up with to get things running (defined at the top level).

if RUBY_VERSION > "1.9"    
 require "csv"  
 unless defined? FCSV
   class Object  
     FCSV = CSV 
     alias_method :FCSV, :CSV
   end  
 end
else
 require "fastercsv"
end      

If you're using FCSV in other work outside of Ruport, you may find this shim useful for compatibility.

This marks the beginning of the attempt to make Ruport fully 1.9 compatible. Keep an eye on trunk in the coming weeks, and please help test!

It's OK to Let Software Die

I think we should let PDF::Writer die.

Why single out a specific library? Just because I'm fairly familiar with some details of it. It's nothing personal and the message behind this post is intended to apply to many projects. For example, the Ruby Core team has publicly stated that they want to see the standard cgi.rb library replaced. I'm sure we all feel that way about some software. I'll stick with PDF::Writer and you can mentally replace it with a project you are familiar with.

Now back to the point: I think we should let PDF::Writer die. I guess that sounds kind-of drastic, but give me a chance to explain. There's a great quote that Matz, the creator of Ruby, showed on a slide in a talk he gave to Google recently. It said, "OSS Should Move Forward or Die." That's an important truth.

Why are Matz and I so ready to start handing out the destruction? The reason is not at all complicated: a project can get to the point where it's hindering more than it's helping. I believe PDF::Writer is there.

I have the utmost respect for Austin and his work to build PDF::Writer. Back then, it was a welcome effort. Today is a different time though and the landscape has changed:

• Austin no longer keeps PDF::Writer up
• PDF::Writer's new maintainers (more like patch appliers) don't completely understand the system
• There are several known issues that just aren't practical to fix for various reasons
  
• PDF::Writer is a vast and complex code base
• There are serious performance issues with the library
• The API is far from ideal, requiring complex wrapping for just about any implementation
• It would be a substantial effort to port the library to Ruby 1.9
  

If we put all of this together, the picture becomes clear: PDF::Writer has stopped "moving forward" as Matz put it. It's on life support. That's worse than being dead because it means we're burning valuable effort to keep things in this obviously less than ideal state.

Now, if we could just get the coroner to call the time of death for PDF::Writer, we could move on. Where would we go next? Who knows. Anywhere is better though, because we would again be moving forward. Some options we might explore in the immediate future:

• Using a different format for printable content, RTF perhaps
• Piping some HTML through html2ps and ps2pdf
• Prince XML

The fact is, we've used all three of those options in production applications at work within the last two years. None of them are perfect. Prince is amazing, but so is the price tag. html2ps is just shy of being as useful as we would love it to be in some areas. And if you really need PDF, substituting just may not be an option. That said, all three supported our needs better than PDF::Writer.

Perhaps the only viable long term solution is a shinny and sleek rewrite of PDF::Writer. We know we have at least a few people interested in the project, so if we could free them from monitoring the life support systems we might just have the beginnings of a rebirth effort. That's the way we need to get things moving.

The moral is simple: it is not just OK to let PDF::Writer (or whatever project) die, it can actually be a blessing. Sure, we would mourn the loss of a once great resource, but eventually we will also choose to move on. That's for the good of us all.

RIP PDF::Writer.

New Beginnings

Mike Milner and I always are wondering how to make Ruport more accessible to the community, and often like to try new things to try to stir people up and encourage them to get involved in things. This new blog is the latest attempt at that.

For as long as the project has been active, we've largely relied on the mailing list as our primary means of interacting with our users and contributors. That has been an invaluable resource, but as Ruport grows, we need to grow our methods of interaction as well.

Up until a few months ago, virtually all the discussion about Ruport was about building the software itself, not about building things using Ruport. While there is still room for plenty of that, it's about time that we let the tools we've built shine through the cool stuff we've created. We are also long overdue for that necessary kick in the pants that comes along with realizing that not everything in Ruport is a fragrant bed of roses.

So here is my invitation to you:

If you've got opinions share them. If you've got cool hacks, bring them on. If you'd like to teach us a thing or two about stuff you've learned while working with Ruport, come share your knowledge.

On the flip side, if something about the software is driving you nuts, challenge the status quo. Mike and I come up with a lot of ideas, and I'd like to think at least some of them are good, but I know that not all of them are. We've got a lot of other people who've got their hands in Ruport's development, and we invite them to take an active role in helping to shape the project, instead of just trusting the two of us to guide things in the right direction.

In almost three years of working on this project, I've always struggled with the notion that it's nearly impossible to make business reporting fun. But hell, we can try. I challenge all our users and contributors to help make things interesting. You don't need to be an expert or a guru to participate, just have a desire to share your thoughts with others, and a willingness to participate in any discussions that may come up.

If you're interested in joining up and helping with this blog, please email me at gregory.t.brown at gmail.com. Though there will be no minimum level of participation on the blog, I ask you to wait until you've at least drafted a first post that you can share before asking for an invite. It can be pretty much anything... opinions, a tutorial, a code example from your work, whatever. With a little effort and some luck, this blog will become a great resource for us all, and maybe even bring some fun into the mix.

Please help us make this possible. It will please the Pacman Ghosts.

-greg