Summer of Code Interview

Recently, I spent some time interviewing Google Summer of Code participant Kevin Clark (of mkrf fame) and his mentor Caleb Tennis. Being able to talk to these two about there experiences was a great opportunity. I think there's some real value for potential participants for future participants and mentors. Take a quick read through and see what you think.

---

To really get us going, would you mind introducing yourselves?

Caleb: I'm Caleb Tennis, a married 20-something Ruby hacker living in Columbus, Indiana. My formal background in in Electrical Engineering, but I spend a majority of my time in the software realm.

The company I work for, AEI is involved in the diesel engine industry. We make products that are used during engine testing, and we also run a facility that provides rooms (commonly known as test cells) to perform the testing. My main job is focused around the hardware and software that keeps the testing facility running. This includes things like our main software controls ateach test cell and the engine inside of it.

A large portion of our software is written in C++, but many of the utilities we use are Ruby based. In particular, we make heavy use the QtRuby toolkit (I just happened to have written a book on it ...) and utilize Rails for a number of internal websites.

Kevin: I'm Kevin Clark. I'm 21 and a few weeks ago decided to cut my senior year at UC San Diego short to work with my friend Josh Susser at Powerset Inc in San Francisco.

I'm known for one of my Rails plugins, ARTS, and my Ruby and Rails centric blog, Gluttonous.

I've been working professionally with Ruby and Rails for about a year and a half, and continue to use it with my work at Powerset.

How about introducing mkrf too (for anyone that wasn't at RubyConf)?

Kevin: mkrf (make rakefile) is a library intended to make building extensions to Ruby easier. It's modeled after mkmf which is in the standard library and generates Makefiles to build C extensions for Ruby. The problem with mkmf is that it's large and unweildly, and nearly impossible to clean-up due to both the coding style and the lack of automated tests. mkmf also isn't object oriented or modular which makes reuse of its code severely difficult at best and impossible at worst.

mkrf tries to fix the issues that exist in mkmf and at the same time make it easier to use for everyone involved. It's object oriented, well tested, and much cleaner than its predecessor. This allows for reuse and make maintenance easier. It also uses rake as a build system rather than make which is easier for many rubyists to maintain.

How did the two of you get involved with mkrf and the Summer of Code?

Kevin: I was finishing my Junior year at UC San Diego and wanted a chance to hack on a Ruby (non Rails) project and become more involved with that side of the community. I had heard about the Summer of Code the year before and been disappointed that Ruby wasn't included in the sponsored groups. This year, with Ruby as a mentoring organization I began looking around for an interesting problem I though I could solve.

I decided on mkrf after hearing Eric Hodel complain about mkmf for 10 or 15 minutes on IRC. I took a look at the codebase and decided it needed a good replacement.

Caleb:David Black put out a call for help early on asking for volunteers to be mentors. I, along with others, replied that I would be interested in helping out. Over the next few weeks applications started trickling in. Google provided a web based interface that allowed potential mentors to look at all of the project proposals and give them a score. Scores ranged from +4 ( very excited about the project and would be happy to mentor it ) to 0 (neutral about the project) to -2 ( the application isn't acceptable ).

Rubycentral received 84 applications, which the group of mentors spent a couple of weeks evaluating and discussing the relative merits. Overtime, based on the scores assigned by potential mentors, the applications became ranked based on which ones had the most interest. In the end, Google allocated 10 projects to Ruby central, meaning that the top ten ranked projects would be accepted and funded.

When the ranking process was complete, David Black then went through each of the 10 funded projects and assigned a mentor based on their comments and, most notably, willingness to mentor. I was initially assigned a different project, however one of the other mentors had expressed a lot of interest in that particular project, so I 'traded' with them and received mkrf (which I had also rated highly).

Wow! I'm kind of shocked that there were 84 submissions this year. Caleb, are there any of those that you think should get some love (either unpaid, or sponsored through some other mechanism)?

Caleb: There were, unfortunately, a lot of really good ones that didn't make it. I think the decision of which ones just barely didn't make the cutoff came down to mentor interest and the fact that we only had ten to choose. Some of the close calls included a neural network toolkit for Ruby, refactoring tools, an XML schema library, and a unix-shell like environment for Ruby. These proposals were quite good; we just didn't have the right people or capacity to support them.

It also seemed like this year there were a LOT of applications for building Rails based sites, like for classroom management, forums, and other full blown sites utilizing Rails. Most of the mentors agreed that these weren't the kinds of projects we were looking for from a RubyCentral standpoint. We wanted projects that were good for the Ruby community as a whole - if they could build off of Rails, then that's great. But we didn't see a lot of value as far from the SoC in supporting the building of pure Rails based CMS systems (and there were quite a few proposals for this very thing).

Tell me a little about how the day to day process worked?

Caleb: After the process was started, Kevin and I had some discussion regarding the types of things he wanted to tackle. He certainly had a very good idea of the types of things he wanted to address in this program. One of them was that the program mkrf was replacing, mkmf, was quite outdated and still using very old Ruby idioms that could be improved upon.

The day-to-day process for us was probably atypical from other projects, though still quite manageable. First, Kevin and I are on opposite US time zones. This means that my evenings are his afternoons, and as such the free time to meet up for discussion wasn't always there. As well, I'm not a big fan of online chat/IM clients because I find myself spending more time using them than actually getting work done, so a lot of our conversation was relegated to e-mail. I'm sure this was a bit of a distraction to Kevin, but he certainly was able to work around it.

I viewed my position as a mentor more of a spiritual guidance provider than a teacher. Kevin is already well skilled in Ruby, so he didn't require any Ruby lessons. There were many times when Kevin would ask my thoughts on which of two ways to proceed, and I was happy to provide them.

The overall process of being a mentor didn't require a lot of effort, but I think that's due to Kevin's knowledge of the domain. I basically left it up to him to define the project, pick what things to work on, and implement them. I was there to download his code, provide some peer review, and make sure the tests all passed.

One of the most defining points of the SoC that Google stressed was that the quality/quantity of code is all relative to the project and not even the most important part. They are genuinely looking to get people more integrated into the open source communities. So, an important part of the overall project was to ensure that the names of the participants, their projects and contributions, were being integrated into the community as a whole. To help with this, I encouraged Kevin to write about the project on this blog, to announce released to the Ruby newsgroup, and to find other ways to get his project and his name known. Speaking about mkrf at Rubyconf was a fantastic way to do this.

Kevin: I had a pretty good idea of how I wanted the code to feel after looking at as many gems' extconfs (extension configuration files for mkmf) as I could track down. Caleb and I talked about how I could approach the problem and I started working at it.

As I made progress (or didn't) I'd check in with Caleb who would take a look at the source and offer suggestions wherever he could. Outside of the source he encouraged me to get a RubyForge project setup and to start talking about the project in the community. Through his coaxing I pulled in a few early users who were able to give great feedback which changed many of the assumptions I had starting out.

Now that the sponsorship is over, where does that leave mkrf?

Caleb: Well, in good hands I hope. I hope Kevin continues to work on it, but even if not that's the beauty of open source - someone else can come in and pick it up and run with it.

Kevin: Unfunded, but not abandoned ;). Work has sucked up a good amount of my time, but mkrf is still on my mind and I want it to get it that little bit further so it can start being adopted throughout the community.

What did each of you learn from the Summer of Code?

Kevin: Being closer to the Rails part of the Ruby community, I hadn't really taken advantage of RubyForge or been active on Ruby-Talk. My project forced me to work with RubyForge and other tools that many Rubyists use on a daily basis, and I started taking notice with respect to what was happening in Ruby outside of Rails. It was really nice, and I feel like I'm closer to Rubyists as a whole and am able to contribute back more easily.

Caleb: It's truly a big project. A quick glance at the website shows just how many projects were involved. And in some cases, the allocation of projects was surprising. For example, Gentoo ( of which I'm a developer ) received more projects than Debian, which is arguably a bit more ubiquitous of a Linux distribution.

I'm not sure if people are aware of how much Google spent on the SoC, but this year it was over $3 Million US dollars. That's purely in payments to students and mentoring organizations, and doesn't include any administrative costs like Google employee salaries, T-Shirts, postage, etc.

What do you think could have been improved about the Summer of Code program?

Caleb: I hate being critical of Google here, because they were great sponsors to have, but I think some folks were really unhappy about the payment system. I know that the first round of student payments were very delayed, causing some frustration. As well, a lot of mentors and students not based in the US found out very late in the game that they would have to file various forms of tax paperwork or be subject to a large withholding in taxes. I know some found it easier to just take a 20% reduction in their payments vs. diving into complicated US tax forms.

The SoC time frame is based somewhat around the US college schedule, which doesn't always mesh well with non-US based students. There were many students who were still in school, with pending final exams, for the first few weeks of the project, and weren't able to get started at the same time as everyone else. As well, some had travel plans or service requirements for a few weeks during the middle of the program, which caused problems with turning in evaluations on time. I don't know how to address this particular problem, but it's definitely something that will have to be improved upon.

But it's only in its second year. I think as time moves on, Google will only get better at these things. I hope their sponsorship continues well on into the future.

Kevin: I'm with Caleb on this, the payment system is where the process broke down. Payments were months late at times which puts a burden on students to secure other sources of income rather than working on their projects. I had to spend time taking little bits of contract work in order to pay rent when I would have rather been working on mkrf. I know others who felt like they needed to drop from the problem because the payment process was delayed so far. That aside, I'm sincerely grateful to Google for putting on the program and would do it all again.

What advice would you give to next year's Summer of Code hopefuls?

Kevin: Keep on task. When things start to slip it's easy to let them get out of hand.

Caleb: This is a very good question. From a generic SoC standpoint, you need to address a couple of things:

1. Your project needs to be of the right scope. The mentoring team is quite familiar with the project being represented, so as such they will have a pretty good idea of how complex your proposed project is. If it's way too simple, you probably won't get picked. As well, if it doesn't seem possible to complete the project in the scope of the summer, it won't get picked as well. Remember, mentors want to pick projects they think will be completed.
2. The quality of your application is critical. If English isn't your strongest language, you really need to get help in making the application read well. Some applications were very difficult to understand, so they received little attention. Introduce yourself, make your project goals clear, and explain why you want to be involved in doing this.
3. You need to be committed to doing the project. This year's SoC had a completion rate of 82%, meaning that 18% of the project didn't make it to the final evaluation. In general, this is due to the abandonment of the project by the applicant. Some just got in over their heads, some just lost interest. Think of the SoC as any other paying job, one in which you are being evaluated by a large diverse group of peers. Make sure you're willing to see the project through, even if it ends up being difficult or time consuming. You were the one who proposed doing it.

Kevin, what do you think you'd bring to a mentoring role?

Kevin: I think it helps that I've been through the process as a student. It gives me some perspective into how that side of thing works and feels and also the de-motivators that keep you from getting the job done. I've also worked with various parts of the community through SanDiego.rb (and now SF Ruby Meetup), the different conferences, and publishing gems and Rails plugins. I feel like I could help make the journey into our little world comfortable and fun.

What advice would you give to other potential mentors?

Kevin: I think to work on any project like this you need to be truly excited about what you're doing. The payments are a good carrot, but that will only get you so far. I think mentors need to be able to help motivate the students by showing them just what sort of an impact they can have on things if they work hard. It's the classic "pulling ones self up by their bootstraps" story in a true meritocracy. It's why I love the hacker sub-culture and the Ruby community in particular. Everyone has a chance to do something new and interesting, and get other people excited about it. I think the Summer of Code gives students that ordinarily wouldn't have that sort of exposure a glimpse into that world and mentors should encourage that.

Book Review: Beginning Ruby on Rails E-Commerce

I've had my copy less than a week now, but this is rapidly climbing my list of favorite Ruby Books. I had the opportunity to interview Jarkko Laine, one of the authors (with Christian Hellsten), and that really whetted my appetite for the book. Now that I'm reading through it, I have to say that I'm even more impressed than I thought I'd be.

The book is built around the development of a book store's online store (and some additional features). Christian and Jarkko do a good job of walking through the development process, leading you along as you learn about Ruby on Rails.

One of the first things that jumped out at me was their description of the Scrum flavor of Agile Development. Not only was this a nice readable description, it was the first of many 'bonus features' I found. I appreciated having a couple of pages devoted to helping improve my development process.

Another nice piece I saw was the coverage of Ferret and the acts_as_ferret plugin. (I interviewed Dave Balmain, the developer of Ferret, a while ago.)

Chapters on localization,integration testing, deployment, and performance tuning (including some good bits on Eric Hodel's awesome Rails Analyzer tools) close out the book and really cap things off well. This book goes way beyond just writing code — it's about writing code right.

My only wish is that they'd have had more coverage of Mongrel (it only gets a mention in a sidebar), SQLite, and PostgreSQL. Oh well, no book is perfect — maybe they'll make it into a Second Edition.

Mini-Interview: Brian Palmer

I posted an article about the Programming Deathmatch held by Berkeley Data Systems on the InfoQ Ruby Community O'Reillynet Ruby blog this morning. I was only able to put in a little bit of my short interview with Brian Palmer into the article, but I didn't want to throw the rest away. Here are all of Brian's answers.

What's your Ruby background?

Brian: I graduated from the University of Utah in August. I worked my way through school as a freelance software consultant, so I had a lot of opportunities to experiment with new languages and technologies.

In late 2001, I ran across Ruby on a site listing comparisons of a bunch of different scripting languages, and it caught my eye because I recalled hearing about it in connection with the Pragmatic Programmer duo. I experimented with a bunch of scripting languages: Lua, Python, TCL, etc., but after about 20 minutes of screwing around with Ruby I was hooked, and I immediately started using Ruby whenever possible. At first it was mostly for code generation and miscellaneous scripts to help me in my 'real' development (I was writing mainly C at the time, for the Palm OS and Pocket PC platforms), but after a while I started using Ruby for OpenGL work, and then I began writing a few web sites in Ruby using the CGI library, which eventually became the main focus of my business. So it was a natural fit to pick up Rails when it was first publiclyreleased, and about 80% of my job has been in Rails ever since.

What was the Death Match like?

Brian: The Deathmatch was fun, but intense. I've never done a coding contest before, it's interesting to see how your coding standards change when you have 10 minutes to write a program. :) You really don't have time to think about what is the most elegant or most efficient solution, you just do the first stupid thing that comes to mind. Of course, maybe that's why I missed one problem in the 2nd round -- once I stopped to think about it I came up with a much better solution, but I didn't finish it until a few seconds after time was up.

Do you think Ruby helped or hurt you in the competition?

Absolutely it helped. Up until the final round, the only criteria was whether you could write a correct program in the time given, so the fact that I could write so little code to create my solutions was obviously a huge plus. The easy readability of Ruby and the direct way that Ruby maps to the way my brain thinks helped me quickly verify that my answers were correct. And of course, when speed is so critical then it's really important that you use a language you are very familiar with, so Ruby was the natural choice for me.

How does it feel to end up working for Berkeley Data Systems after being one of the winners of their contest?

Brian: Berkeley's a lot of fun, it's awesome to get to use Ruby and Rails on such a large system. I've been working as a freelance consultant since high school, so it's very cool to work on something so big instead of the one-man apps I've done up to this point.

Author Interview: Joe Fair

I recently had the opportunity to interview Joe Fair, the author of Payment Processing with Paypal and Ruby. Joe, would you please introduce yourself?

Joe:Sure. I'm a software engineer for L-3 Communications working at the FAA helping make maps for pilots. My bachelors degree is in Computer Engineering from the University of Arkansas, and I have a Master's in Software Engineering from Southern Methodist in Dallas. I've been writing software for almost ten years.

Early in my career I started working on passing information between applications. Reports, billing records, that sort of thing. Later, I found out this is called "Enterprise Application Integration" and there's a whole industry around it. Most of my career has been working with integrations and solving back-end problems. Even now, when I'm on a team doing web applications, most of my time is spent on back-end issues.

How did you discover Ruby?

Joe: Actually, I heard about it at a No Fluff Just Stuff conference in Denver back in 2003. I had asked a panel "What makes you _really_ productive?" and Dave Thomas said, "Ruby". I thought it was interesting, but I never got around to looking at it.

Later, I was looking for a way to test a web application with lots of client-side processing, and I heard about the Watir project. It interacts with the browser to check the checkboxes and click the buttons, which is handy if you have lots of Javascript on your page. I was able to pull together quite a bit of automation without much effort, and I was convinced. I saw a Rails demo at another No Fluff Just Stuff in Dallas, and I was hooked.

What are some things that you don't think Ruby does well?

Joe: The things I don't like are problems I hear other people have had:

• It's slow.
• It's not well documented.
• It's not easy to deploy.
• It's not easy to find help.

For me, the last thing is the killer. I helped write the same application twice in 1999 and 2000 with two different WYSIWYG Java form builders. Both of the form builders were so specialized that it was hard to get consultants and harder to get support. After I left they re-wrote it in JSP's.

It will be easier to get local help as Ruby spreads, so I'm not worried about that aspect. There are some smart people working on all the other aspects, so I think we'll see Ruby just keep growing. Some day it will be Enterprise Ready, whatever that means.

How much of your daily work is done in Ruby?

Joe: Just my play time right now. I've been concentrating on PayPal integration, so I'm catching up on some new things. Mostly RJS right now, but I'd like to write some tools for more generic back-end integrations, too.

What are you using Ruby for?

Joe: I'm putting together some small commercial sites. My role as a government contractor restricts a lot of what I do during my day job, so I have to feed my Ruby habit after hours.

However, I have heard of one project on our campus that used Ruby for some internal tools. It looks like the camel's nose is under the tent, as they say.

A while ago Hal Fulton caught some flak talking about 'sneaking' Ruby into an organization (in an earlier interview here at On Ruby). Talking about the camel's nose sort of echos what Hal was talking about. How would you respond to the people who call sneaking/slipping Ruby into an organization unprofessional?

Joe: The way I look at it, I'm a professional problem solver. If my problem includes "and use Java" and I don't, I'm providing the wrong solution. That's just as bad as providing the wrong functionality. If the customer doesn't care, then I'm solving the problem with the best tool I know.

I looked up that quote, and it seems to me he deserves some flak for "and your bosses may not even know", but the rest of it sounds like the way a lot of change happens in organizations. I've seen new IDE's, new libraries and new techniques bubble up this way. Occationally feathers get ruffled, but more good is done than harm.

What made you want to write a book about Ruby and Paypal?

Joe: In February I went to a Rails Studio class with Dave Thomas and Mike Clark. I was asking Dave about some ideas for an open-source project I had had, and we got onto the subject of some of his recent books. We talked about some other unexplored areas for Ruby, and payment processing was one of them.

I thought about it for about a week and did some research, and put together a proposal. I sent it to Dave fully expecting he would reject it, or reveal that someone else had started it, or ask for a lot of writing samples. I was trying to not get my hopes up. Instead, he said, "Sounds good. I'll send you a contract. Don't let that hold you up." and I was in.

I don't think they'll mind if I mention it here: The Pragmatic Programmers are looking for good book ideas. If you have a good idea send it to them.

What books about Ruby would you like to see someone write/publish?

Joe: That's a great question. We're seeing more books about converting to Ruby and selling Ruby to your organization. The big push back now is that Ruby can't replace Java in the Enterprise. I think Java and Ruby are different solutions that have some overlap, but Ruby won't supplant Java completly. Just like Java didn't supplant C++, nor C++ supplant C, etc. Each language solves a problem, and some languages fit some problems very well.

Having more tools is better than having fewer tools. I'd like to see books about solving new problems that Ruby is a good fit for.

What drew you to the 'Fridays' format?

Joe: I really like the idea of a focused set of instructions to solve a specific problem. Most developers will probably be able to read this Friday, pick a good solution, and get a simple working example working very quickly.

If you had an entire book there would be more information, but it would need to be more of a reference manual rather than a tutorial. Each has its place, but sometimes you just need the tutorial.

What was the most important thing you learned while you were writing your Friday?

Joe: I think that the most important thing about PayPal is just how much flexibility PayPal gives you. You can do a web site with just static web pages all the way up to SOAP messages back and forth. You can have all the complexity you want (and more.)

The most important thing I learned about Ruby is that you have to be careful about your libraries. The ruby2wsdl tools are terrific, but you have to have the latest version, not the one that comes with Ruby.

The most important thing I learned overall is that it is a lot of fun to write a book, and you'll learn a lot along the way.

Which books about other languages (or language agnostic) should more Rubyists be reading?

Joe: I devoured My Job Went to India: 52 Ways to Save Your Job. It's not really about outsourcing at all. It's about creating a quality product (you) and providing value to your customer (the employeer).

Since reading that book, I've spoken at two user groups, started a Testing group and a Java Certification group where I work, paid for my own Rails training, provided feedback to a local community collage, and written this e-Book. I'm increasing the variety of experiences that I've had so I will be seen as more valuable to my employeer.

It's not just for geeks, either. Almost a year ago I loaned it to a millitary officer, and he liked it so much he marked it up and won't give it back.

What are your favorite five Ruby libraries or tools?

Joe:

• Rails - Wow.
• Active Record - Even Better.
• irb - Where has this been all my life?
• soap4r - Makes things SO simple.
• Vi Improved on Windows - It just works.

What's next for you?

Joe: I have a couple of ideas. I'd like to build up my Ruby portfolio, and I've had an idea for an integration book for a long time.

I'd like to go back and read the top couple of dozen of the best software engineering books and papers like Mythical Man Month, Peopleware, and No Silver Bullet. I wonder how many mistakes I've made that some guy warned us about 20 years ago. I always wanted to work through William C Wake's Refactoring Workbook.

What do you think is next for Ruby?

Joe: I'm glad to see the JRuby guys got picked up by Sun. It will be easier to win converts if you don't have to convince your admins to install another language (just keep your boss informed :-)

What do you think is next for Rails?

Joe: More hype, more resistance, more press, and more converts.

I'll bet this happens in the next year:

• Somebody's going to try Ruby on a problem it's not suited for and utterly fail.
• They'll write an article or book bashing Ruby and hyping Java.
• It will get widely read and blogged about, and it will be interpreted to mean Ruby is bad for all problems.
• Through arrogance or ignorace, people will use Ruby anyway and we'll see more success stories.

Eventually, I think the developer community will be able to judge what problems Ruby is better at than the alternatives. Right now I don't think we've seen enough people push the envelope and fail to know where to draw the line.

Technorati tags: Ruby Rails Books interviews

Rails Application Beta Test (Check It Out)

FamilyLearn is a small company here in Utah Valley (20 minutes south of Salt Lake City). When I first ran into them, they had a cool looking application called iMemoryBook (no, it's not a Mac thing). The thing is, it was kind of a ball of mud that was written in Perl and PHP. I spent some time evanlelizing Ruby and Rails, and they've since hired a couple of Ruby and Rails hackers and have rewritten their application in Ruby on Rails.

The application is an online tool for building and publishing "memory books" (Baby albums, Wedding Albums, Books of Rememberance, and the like). I wish I could really do the idea (and the website) justice. The good news is I don't have to.

This morning I got an email saying that they're looking to for beta testers. If you're interested, take a look at beta.imemorybook.com.

If you're a Rails or a UI head, go take a look at what they've done, it's really cool. Even if you're not, you should take a look — it's that cool. (Feel free to pass them some feedback if you think it isn't, this is a beta after all.)