Gregory is a free software developer from Connecticut. He is currently an undergraduate student at the University of New Haven pursuing a double major in Computer Science / Mathematics. His primary focus has been working on Ruby Reports for the last year. This summer, Gregory participated in Google Summer of Code, working on Ruport to implement several features requested by the community. Gregory is also an active member of the new_haven.rb and NYC.rb Ruby Users Groups.

Due to space constraints, there are a couple of excerpts to this interview, located here and here.

How did you discover Ruby?

Greg: I’ve been working with James Edward Gray II for many years now. JEG2 was my mentor when I was learning Perl, and eventually, he started working in Ruby.

Like most others, he was heading into Ruby because he was sick of waiting for Perl 6 to come out, and I guess I was too. I started playing with Ruby, and by the time I did my first paid job in it (A simple web crawling app), I was hooked.

What role does Ruby play in your day to day work/hacking?

Greg: Aside from school and the occasional C# meltdown at work, Ruby is nearly the only language I deal with day to day. I know enough Java to get around, but thankfully have no need for it. At work, I use ruby for system administration, ad hoc reporting, and the usual Perlish one liner glue apps. In my day to day hacking, aside from Ruport I do a decent amount of work with www-mechanize, and also write little tools for my own personal use. I’ve even written a simple little script that allows me to record,sort,and search a TODO list inside of irb. :)

Tell us a bit about Ruport.

Greg: Ruport is Ruby Reports, part software library, part a mountain of hacks.

Right now, Ruport is really awesome for manipulating tabular data. It might take a little getting used to, but the tools we have are really powerful. It’s also great for the quick ‘grab something from the database, drop a few columns, add a calculated field, and output this as a PDF and a CSV’ type stuff. This is my main focus in Ruport, making the ad hoc reporting as easy as possible. But James Healy has been adding really cool, more advanced stuff, such as systems to build invoices and graphs and things like that.

JEG2 has described it as a sort of abstraction so that you don’t need to learn the libraries Ruport makes use of (such as FasterCSV, PDF::Writer, ERb, Scruffy, etc) you just learn one library and can use them all. This is more-or-less what Ruport is all about.

So I think that Ruport might be useful to a broad audience, and we try to be really open to new ideas. I’m not joking when I say that 90% of my favorite features of Ruport came from the ideas people have shared with me.

Also, I have to say, even if I started Ruport, we now have 4 developers on the project. They are all busy with other things of course, so it’s true that I still produce the most code on the project, but they produce a lot of the coolest stuff in Ruport, and help me with all sorts of not-so-glamorous tasks that involve a lot of hard work. I just wanted to mention them because they are often modest about their contributions, and I think the world of them. We’re trying to build a strong community, and Dinko, Dudley, and James have been a huge part of this.

Tell us about your experiences working on Ruport in the SoC.

Greg: I slept too little, got outside too little, drank too much caffeine and angered my friends and family. ;)

Seriously though, I came into the summer anticipating a 12 week sprint, with only small breaks in between. This is more-or-less how it went. The more work you put into something like this, the more you want to push yourself.

I found myself a little scared at times, because in order to accomplish the tasks I had set out for GSoC, we needed to uproot a lot of old systems in Ruport and either do some serious reworking, or scrap them entirely. Luckily, our test coverage was halfway decent initially, and now is quite good for the most part.

As far my feelings about the big picture of the whole summer, I don’t think there could have been a better community builder. Our mailing list had 20 something people on it before GSoC, now it’s around 45. Downloads have skyrocketed, and people are almost always lurking in #ruport. Having folks around that are interested in what we are doing is an incredible motivator, and has proven to be wonderfully helpful.

Like many others, I was frustrated about payment delays. But aside from that, it was a great way to spend the summer.

How did the SoC help you work on Ruport?

Greg: It gave me a legit excuse to put the amount of time I did into Ruport. It would have been a lot harder to sell to family, friends, and employers the idea of me spending basically all my free time on some random piece of software. GSoC gave me something to tell people to explain why I was sitting in front of a computer for long hours.

It also helped pull in a lot of new users / contributors / developers. People came in because they saw the GSoC projects being mentioned, and decided to look around. I do hope that they continue to stick around, now that Summer of Code is over.

Finally, it was motivating to know that there was some measuring stick for my performance, and the fact that this measuring stick was tied to paychecks made it even more compelling to finish the program successfully. This helped get me out of bed on days where I felt like “If I find another bug in Ruport, I’m going to quit the project”.

What was the role of your mentor?

Greg: To annoy me and make me angry. I mean that in the nicest way possible. David Pollak was very helpful to me because he made me think about things from a very different perspective, the view of the end user. Before he brought this up, I had this very heavy bias that caused me to assume that everyone who used Ruport was a hacker, and a highly skilled one at that.

David opened my eyes to the folks that didn’t want to have to go cross their eyes looking at some crazy meta-programming, but just needed a quick HTML table from an ActiveRecord model or something like that. At first, I was frustrated with the idea of ‘read the source for class Foo’ being an insufficient answer, but over time I learned to be a bit more user friendly.

Because of this, we ended up generating a lot more stuff to open up to developers of all sorts of different skill levels. I think the biggest contribution in this regard has been the Ruport bliki, and the yet-to-be-completed cookbook we’re working on. Reaching out to these folks have paid massive dividends, since some great ideas have come from people very new to Ruby, who would have probably been scared away from Ruport 6 months ago.

David also helped give me reality checks and kept me on task. When I gave him a list of 200 items for a milestone, he was quick to say “Do you think you can get this done on time?”, which often made me rethink my plan. :)

Though it would have been nice to work with someone with a ton of domain knowledge relevant to my project, I think the non-technical advice that David offered was equally valuable.

In hindsight, what would you do differently?

Greg: I think I would have defined more concrete goals. Honestly, my ‘deliverables’ were slightly vague because at the time I didn’t have enough domain knowledge for some of the tasks I was planning on doing. For example, Rails support was a breeze, at least to get something of the ground. I had *no idea* what to expect going into GSoC, so my proposal was really loose.

Having tighter objectives may have reduced the fun factor a bit, but the biggest trouble I had this summer was figuring out when something was ‘done’ and moving onto the next thing. I worked with what I had by trying to work with really simple ideas first, and letting the community make requests for improvements. Still, I think this made the summer extremely hard to plan out for me, and also made it difficult to evaluate my progress at any given time.

So I guess I would have maybe done some serious polling of the community beforehand, to see if I could get people to agree on a set of concrete tasks for me to work on. This way, people could know what to expect, and also, it’d make it easier for me to say ‘Oh, I’ll have to work on that after the SoC, because I still need to meet milestone X’.

I also think I would have spent more time documenting my code as I went along. We lucked out on RuportDay because most of the API got documented, but throughout the summer, Dudley and I were *awful* about keeping the API docs or any other form of documentation up to date.

With all this in mind, maybe I would have made the scope of my project a bit smaller, to leave room for things like documentation. :)

What advice do you have for next year’s hopeful participants?

Greg: First and foremost, don’t expect GSoC to be your primary income for the summer. Hopefully logistics will improve next year so people get paid faster, but I think just because of the nature of the program, prompt payment will be tough to pull off.

Even if this is the case, my other piece of advice would be to make sure you can put a sufficient amount of time into your project. It’s incredible how quickly you can get behind if you don’t stay on top of your project and put a lot of hours into it. I put on average 40-50 hrs a week into Ruport this summer. I’m not sure if that’s how much most people would need to put in, but plan for no less than 20hrs / week.

If those two things are something you’re willing to deal with, then just try to find a community need that interests you. GSoC isn’t necessarily about the most flashy projects, just things that will be helpful to the community.

Ryan Leavengood wrote a great piece of advice on this topic, and you should probably check that out if you plan to apply.

Oh yeah, this may sound sort of crazy, but get outside and get some exercise, make sure you still spend time with your friends and family, and take a break now and again. I went about 7 or 8 weeks into the program before I realized it was driving me crazy to neglect these things. Honestly, this may be the most important advice about GSoC i can offer, because this will help make sure you don’t burn out.

What are your favorite 5 Ruby libraries?

Greg: I’m a big fan of Ruby’s standard library. There are so many things in it that just rock. PStore may be one of the coolest things in there, whenever you need an instant mini-database.

I also think that DRb rocks. I haven’t had nearly enough of a chance to play with it, but just having a tool like that so readily accessible is great.

I also love James Edward Gray II’s FasterCSV. The standard library CSV lib isn’t that bad, but I think that a lot of FasterCSV surprises me less, and it doesn’t hurt that it’s more than 8x faster. I do a ton of CSV parsing, so this is important to me.

www-mechanize has come so far in the last few months that it’s literally quite fun to work with. It is *very* useful for saving a few minutes on some boring web form through automation.

Finally, I guess it’s sort of self-centered but one of my favorite libraries in Ruby is Ruport. Of course, my favorite things about Ruby Reports are often things that contributors or one of the other developers have offered. It’s also fun to know that once I generalize something into Ruport, it’ll save me time in the future and maybe help some other people too.

What do you think is the next big thing for Ruby?

Greg: We have Rails. I don’t know if we need another big thing.

I fear the biggest thing for Ruby is a major shift in the community, from a place where everyone knows each others names, to something more like other language communities. This has it’s pluses and minuses, but for me, I hope we can keep Ruby grass roots as long as possible.

On the technical side, I’m curious to see how Ruby will change when 1.9 and YARV become part of our daily lives. JEG2 and I played around with it a bit during the ICFP contest, and I was pretty impressed at the performance gain. With people doing so much cool stuff with 1.8, I’m hoping 1.9 will bring us even new innovations.

What’s next for you?

Greg: Well, I decided to go part time this semester to try to pick up some extra work and/or work on some personal projects. So I guess I can offer a blatant self-promotion and say I’m looking for work!

But other than that, I want to see Ruport through to 1.0 and hopefully keep up the momentum we gained during the summer.