At the Rails Way blog, Koz has posted an example of refactoring Ruby code to make it more “human” readable. He states this opinion:

It’s far more important for code to be human readable than incredibly concise.

I agree with the statement, but think its important to define “human readable”. In the example, both the before and after are clearly human readable by the human developer who wrote it. In fact, at the time of writing any piece of code the developer clearly is able to read it, or would not be able complete it.

The reason to create more readable code is not for the benefit of reading it easier at the time of development, it is so you can more easily dive back into it six months later, after you’ve forgotten why you did it the way you did it. There are so many solutions to every development situation, and six months from now you might not being using the same patterns for your development as you were then. Or, a different developer, with different preferences for coding style and patterns, may need to read your code and understand it very quickly.

It’s not that the future developer can’t understand it either way, but simply the reduced time to jump right to the matter at hand and focus in on the solution. As I said in the comment on the post, this particular example shows how to break up the various tasks of the activity of validating this Expense object, so that you can jump right to the validation issue that may be causing the problem. You don’t have to weed through a possibly very lengthy validate method, reading every single line until you find the one that might be at issue. Instead, you can read the descriptions of each validation step at the top (the pseudo code method names serve as descriptions) and thin pinpoint the validation step or steps that need a fix or expansion.

Taking the time to do this type of code refactoring at the point of original development, when you understand what is going on because you are fully involved in it, will save you and/or other future developers massive amounts of time and grief when readdressing the code months from now.

Rails for All, a non-profit Rails promotion organization started by Robert Dempsey, has announced a Ruby on Rails conference in Orlando, Florida next year in early February. They are now accepting proposals for speakers and have posted the hotel information.

I plan to be there and am very much looking forward to it. If you are going, let me know so we can plan to meet up.

The ServerSide has posted an interview with Dr. Holly Cummins from IBM who recently gave a presentation on Garbage Collection. She expresses her disagreement with some common beliefs about GC, and gives some recommendations for understanding your verbose GC and using it to tune the GC.

Some quotes from her presentation are highlighted below.

In response to the claim:

Garbage collection does work and causes pauses and the pauses prevent my application from doing work so the shorter the pause the better.

Dr. Cummins answers:

Not true! Even when a garbage collector spends a lot of time paused, application performance may be better.

Dr. Cummins also disagrees with the claim:

OK, I get that the application would go faster if I could tolerate long pauses, but response times are critical for my application so the shorter the pause times, the better off I will be”

She goes on to give some recommendations on adjusting heap size, choosing the right GC policy, and using a toolkit from IBM.

The slides are provided online in a PDF.

The video can be seen, along with accompanying discussion on the Server Side (once everyone gets over her appearance).