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.)

Apgar and a Balanced Scorecard

In "Apgar and Software and Bears, oh my!" I wrote up some initial thoughts in response to Daniel Read's Does Software Needs an Apgar Score? post (Apgar scores are a simple 5 metric assessment of newborn babies that results in a score from 0-10, any baby with a score lower than 4 is treated to some rigorous neonatal care). I've had a little bit more time to think about it (aren't weekends a wonderful thing?), and I wanted to write a little bit more about it. (By the way, Steve Benz posted Apgar, Metrics, and CVS about a different way to think about Apgar scores and improving software development.)

One thing I did (implicitly) was to turn a theoretical 'Software Apgar Score' into a dashboard (sometimes called a balanced scorecard). I've spent some time reading the Robert Kaplan's work on this, and I agree with a lot of what he has to say. (Take a look at The Strategy-Focused Organization or The Balanced Scorecard for more information, straight from the horses mouth.)

The basic idea is that you can (should) create a dashboard for measuring progress, and that that dashboard needs to be aligned with your goals. It's also important that you measure leading and not lagging indicators. The fact is that you need something more than a single dial ('Did we cut a release this week?') and less than a 100 page document. Four to six metrics seems to be about right from everything I've read and tried.

It's the choosing of which ones to measure that can be hard. The metrics are going to be different depending on what you want to do, which makes the task of picking them even harder. Wouldn't it be cool to have a catalog of metrics though, with some tagging to indicate which ones are useful for what kinds of software or organization?

I told Daniel, if he was serious about building something, I'd rather see a deep and broad catalog than a single tool. He had a great response:

Pat, this is exactly what I was thinking of as the next step! I like your term "deep and broad catalog" of software types cross-referenced with score-able attributes. I'm thinking of three key elements for this system:

• a guideline for what are considered ideal qualities for a "score-able attribute"
• a guideline for what constitutes a "software type" (language? context? purpose?)
• a consistent scoring system that will be useful across the variety of software types and score-able attributes (one idea I had was that all programs start off with a score of 100 and then points are taken off for lack of certain things, which sort of reverses the additive nature of the medical Apgar)

A tool to keep track of all this would be nice too. :-) Maybe the simplest place to start would be a wiki, but another option would be to use a taxonomy-driven tool like Drupal, which would be more structured from the start. And a custom tool is always a good option. I'd be happy to host it, but unfortunately my time is limited as far as putting the real grunt work in.

And of course it will be easy to get everyone together and agree on all of these things. Seriously, though, if others are crazy enough to jump in and give this a go, I'm crazy enough to participate. Bob Glass has already agreed to run an article in his Software Practitioner newsletter, and if we had some kind of framework along the lines of what I've described above, with some salient questions for soliciting feedback, then between the article and whatever interest we can generate on the web, it might come together into something useful.

Once the database of software types and score-able attributes is built, I like your idea of a front-end tool for managers, designers, tech leads, developers, consultants, etc. to use to identify the desired "software type" and see what the consensus was on the score-able attributes for that type.

Tim Bray, Comparing Intrisics

Not too long ago, Tim Bray made a presentation at a PHP conference in Frankfurt. Several people jumped on some of the slides Tim used (see Floyd's post at InfoQ for a fairly balanced take). Everyone seemed interested in his comparison of maintainability and scalability between PHP, Rails, and Java. While I thought that was interesting (and a bit flawed, that's a topic for another post though), something else was even more interesting to me. Check out this slide (but remember while these show a ranking of the three languages, they aren't graded):

To me it's really interesting to look at the three comparisons on the right:

• Dev Speed: Rails wins here, with PHP second and Java third
• Dev Tools: Rails and PHP tie for second behind Java
• Maintainability: Rails wins here too, with Java second and PHP third

Something that leaps out to me is that Dev Tools are created and improved as a reaction to the friction a language throws in the way of 'Dev Speed' and the obstacles it presents to 'Maintainablity'. This becomes more interesting in light of the constant cry that Ruby isn't ready for prime time because it doesn't have 'real' development tools. (Please note, I am pretty happy with the Ruby tools I've got — not that I'd turn up my nose at newer, better, shinier toys, err tools though.)

Now, I don't think there's anything wrong with good tools ... I can do a lot of fancier things in a well stocked kitchen than I can when I'm camping. When a language doesn't get in your way, they seem less important though. Maybe that's why Ruby doesn't have them yet, and why most of the Rubyists don't complain too much about it.

I asked Tim what he thought. He replied,

Your hypothesis - that tools are created in response to language/developer friction, of which Ruby clearly has less - is plausible. But there are things that I can do easily in NetBeans that would increase my productivity tremendously if I could do them in Ruby, so even if you're right about the motivation for tool-building, the quality-of-life issue is real.

When I asked him about specific tools he thought would help, he listed two

1. Integrated IDE with editing/refactoring/debugging/testing all at the touch of a button.
2. "Find usages" - find me all the places this method is called. That's huge because once you have it, you empower yourself to do all sorts of automated refactoring support.

Technorati tags: Ruby Rails

Ruby Certification: Is It Worth It?

For some reason industry certification is a real hot-button. Some people think they're not worth the paper their printed on, while others base hiring decisions on them. I'm encouraged by the fact that the university is putting some real training behind the certification, but I wonder if the Ruby community is ready for (or interested in) something like this. What do you think?

Ruby Certification: What should it cover?

I've been asked to take part in setting up a Ruby Certification course for a large univesity (no names until they announce it, sorry). I'm participating, but I have two questions that are lingering in my mind. I'd like to ask for your feedback on one of them here. (I've also recently agreed to do some blogging over at InfoQ and I'll discuss the results one there.)

Certification is kind of a hairy deal. A lot of people love them, and others think they're evil incarnate (or something close). I've never been a big fan of them, butI see this as being a bit different than the typical 'take a test and earn a cert' plan. The university is planning a series of three (non-credit) classes that will focus on Ruby and Ruby on Rails, with a pass-fail grading system. Anyone passing the three classes (which will have a significant hands-on, practical portion) will be recieve the certificate.

So, here's my question — What topics need to be covered to make a certificate work like this work? (For extra credit, what kinds of hands-on exercises do you think would help cement a student's understanding of those topics?)

Update: I'll dicuss the feedback on both questions at InfoQ later on ... for now, all the discussion will happen here

Apgar and Softtware and Bears, Oh My

Daniel Read wrote a great post about Apgar tests and software and Edward G Nilges wrote a response. (Read more about the Apgar test over at wikipedia). Daniel's and Edward's posts are worth reading before you get too much further here, go ahead ... I'll wait.

I think there are some good and bad things underlying the analogy (as there are with most analogies). Let me walk through them, the bad first:

• The biggest issue is that there are a lot of variances in the way software is written and its success measured. Without some standardization, it will be hard to get a meaningful, universal dashboard (which is what the Apgar really is). That doesn't mean that there couldn't be Apgar-like dashboards for different kinds of projects and organizations — and having those would probably be a good thing.
• The Apgar is somewhat subjective (gameable, to use a term that showed up frequently in the comments of Daniel's and Edward's posts). It's hard to imagine that a similar dashboard for software wouldn't be gameable as well. (Whether or not a team is gaming the tests is probably a great metric for the health of the software.)
• The Apgar is a lagging indicator. You don't know the score until the process is over, and you can't do much to go back and fix things. It does help you identify cases where an urgent response is needed, but knowing that things are headed south earlier would be much better.

And then the good:

• The Apgar isn't just given once, it's given immediately and again at 5 minutes (and several more times if the baby isn't thriving). Being able to apply the same test iteratively, watching for improvement, will help ensure that your corrective action is actually working.
• The Apgar is simple. As Daniel said, there are five metrics each of which is assigned a score of 0-2, and the total score (0-10) is the single measure that's used. Almost anyone can learn to rate an infant or understand the resulting score. This simplicity would be important for any software dashboard.

So, where do we go from here? Maybe it's time to build a list of what you think is important to a healthy software project. Some things that come to my mind are: a solid test suite, documentation, frequent releases, more than one developer with the commit bit set, and traffic on a project specific mailing list. What are you looking for?

Author Interview: Jarkko Laine

Jarkko Laine is a 26-year-old web developer from Tampere, Finland. He's worked on web-related technologies since 1997, first for fun and then slowly turning the passion into a business. He and Christian Hellsten co-wrote Beginning Ruby on Rails E-Commerce: From Novice to Professional for Apress, which was published on the 6th of November 2006. A little while ago, Jarkko and I did this interview.

---

How did you discover Ruby?

Jarkko: I was working for some projects on OpenACS, a web framework built on AOLServer and TCL, when my friends and then OpenACS core team members Lars Pind and Peter Marklund from Collaboraid in Copenhagen, hired David Heinemeier Hansson to give them an introduction on Rails. They were instantly sold and raved me about it. In two months I was working on my first commercial project on Rails. So I came to Ruby because of Rails, but I actually learned Ruby (reading the Pickaxe2 from cover to cover) before doing any major Rails work. I had a very strong theoretical background in OO programming from university so for me everything in Ruby clicked right away.

Do you think that learning Ruby before RoR gives you an advantage over Rails hackers with less Ruby background?

Jarkko: I don't necessarily think you need to know Ruby inside and out _before_ jumping on Rails. But Rails leans so strongly on many Ruby idioms that you lose a lot if you just think you can wing it. You still see people iterating over containers an picking items from them manually when they could just write array.map(&:id). I think many people who think Rails benefits are overrated actually think so because they can't see the pros Ruby brings in.

How much Ruby does someone who's picking up Rails need to learn to really become proficient with Rails?

Jarkko: I think understanding the object model ("everything is an object") is crucial, as well as all the container methods like map/collect and inject. I think those + the Ruby basics are enough to get you going. However, if you really want to be proficient, you need to know your tools well, and that means knowing your Pickaxe. I don't want to frighten people, though. If you're a good OO hacker, you can pick up Ruby very quickly, and in the process experience a lot of those "oh, why didn't we have this in language X?" moments.

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

Jarkko: Currently it's Ruby and Rails all the way. I love doing the front end stuff, too, but I couldn't think of doing it on top of anything else than Rails these days.

How did you come to write a book about Ruby?

Jarkko: My co-author Christian Hellsten was contacted by Apress and he asked me if I would want to join in. Christian is the one of us with very strong domain knowledge about the subject and I'm then the Rails guy, although that difference is very subtle.

One thing that sort of leaps out is your relationship with Christian. Did you two work together before starting the book? How did you meet?

Jarkko: We haven't actually met, not in person. I think that's one of the true miracles brought by the internet and open source. You can work together with people you have never met but whom you've learned to trust because of what they've done. I think many Rails core team members met for the first team in person in Chicago Rails conf and the rest now in London. Still they've been working on a common goal and vision with a noticeable success.

What sets your book apart, why should people buy it?

Jarkko: We tried to write a very practical book. The book is structured task-oriented, and the different Rails concepts are introduced when they're needed in the building process. So I think it's a very good choice for people who like to learn by doing.

Can you give us an example of this?

Jarkko: The book is organized by tasks, just like proposed recently by Kathy Sierra. We don't have a chapter for ActiveRecord, for example, we have a chapter for creating a shopping cart. We do cover a lot of ActiveRecord (sprinkled around the book), but ours is not a reference book at all.

What was the most rewarding part of writing your book?

Jarkko: Every time I submit a chapter draft in the middle of a night I feel like finishing a marathon. Tired, but still very happy. It's also an honor to be able to give back something to the great community that has built around Ruby and Rails, hopefully taking their success even further.

Yyou talked about marathons as a metaphor for writing and about athletic training. Are you a runner? What's the last race you were in?

Jarkko: I'm a national level orienteer. Orienteering is a sport where you run through an unmarked course in forest with the help of a map and a compass. It's quite a big sports in the Nordic and perfect for people that want more mental challenge than just running mindlessly :-) That said, I run also some track and road races.

What was the biggest challenge in writing it?

Jarkko: I think every writer with a day job knows how hard it is to sit down and start writing when others go to bed. Adding 10 to 20 hours/week of training of an athlete to that brings us very close to an impossible equation. Fortunately, our editors at Apress are a very good combination of understanding and pushiness so we have been able to progress all the time, despite sometimes feeling exhausted.

What did you learn from writing it?

Jarkko: People say that the best way to learn something is teach about it, and the same goes for writing a book. There's tons of background digging needed that never makes it into the book but that make you know a lot more about the subject than you ever did. Apart from that, the writing process in itself is a good lesson of self-discipline that I can recommend to everyone.

What are your favorite five libraries for Ruby?

Jarkko: Rails is obviously something of a living legend for me. Zed Shaw's mongrel web server is also no short of a wonder. But I also love all the smaller gems, like Geoff Grosenbach's Gruff graphing library. Other things I use daily are Test::Unit + RCov (with the Rails plugin, I'm a testing junkie) and Jamis Buck's Capistrano, the brilliant deployment tool.

What do you think is next for Ruby?

Jarkko: Native unicode support (I hope ;-)

What do you think is next for Rails?

Jarkko: A MySpace-sized Rails app (which seems to be the only way to silence the "it doesn't scale" folks).

What's next for you?

Jarkko: See the previous question — I'm working on dotherightthing.com.