Reggie's picayune

I think the way private methods are defined, is one of Ruby’s few weaknesses. The main problem being that they separate the private methods from the methods that use them. For example, I prefer this:

To:

Because the former keeps the internal_method code close to the methods that use it.

This issue is minimised if we keep classes small, but that’s not always as easy as it sounds.

I’m also not particularly convinced about most arguments for making methods private. It takes a much more far sighted developer than me, to be sure that a method that I currently only use internally, won’t be useful externally later.

I’d also be more convinced of the necessity to privatize methods if accessing private method was particularly hard, but it is not: send(:private_method)

It is also worth considering what is being written. If the code is part of a shared library (a gem for example), there is a more convincing argument for privatizing methods. However, if the Ruby code is written as part of a monolithic application (a Rails app for example), then I think the argument is far less convincing.

Surely the only good reason for using a private method, is where the logic is only valid within the context of the current object, and using it outside that context is likely to result in errors. That is, external use will break things.

For example where I do use private methods is in Rails controllers, where public methods could accidentally be exposed by a routing error causing security vulnerabilities and unexpected usage. If only the action methods are public, this vulnerability is greatly reduced.

In summary, I’d say that a method should only be private if using it externally breaks something. If calling it externally doesn’t break anything, why restrict its use unnecessarily.

One common question asked when people start using Ruby, is which books should I read. For me there are three essential Ruby books. However, I don’t think anyone should just read all three at once, and certainly not if they are just starting with Ruby. Here I wish to list those books, and why they should not be read together. The three books are:

• How: Dave Thomas’ Programming Ruby
• When: Russ Olsen’s Design Patterns in Ruby
• Why: Pat Shuaghnessy’s Ruby under a microscope

For me, there is no better starting point for a Ruby developer than Dave Thomas’ Programming Ruby. It was the second Ruby book I read (I started with “Agile Web Development with Rails”), and it was the first to really bring home the elegance of Ruby, and how I could use it. Then and now, most of my Ruby development is done in a Rails environment, but I know that Rails stands on the shoulders of the giant that is Ruby. So even if all you want to do is develop Rails applications, I’d strongly recommend that you start by reading Programming Ruby. I’m confident you’ll be a better Ruby developer for it.

For me, Programming Ruby is all about how to program Ruby. What the syntax is, what to put where to get it to work, and how the core objects work together. And for this, I’ve yet to read a better book.

I’d been developing Ruby apps for a few years when I came across Russ Olsen’s fabulous Design Patterns in Ruby. It had a fundamental effect on the way I write my Ruby code. This wasn’t a book that taught me how to program, rather it made me think about the choices I make in coding in certain ways. This book is all about when to use certain coding patterns. When to split code into separate objects, when to use other objects to manage processes, and when to refactor code.

Design Patterns in Ruby will improve the way you write Ruby code, but I am confident that to get the best from it, you must first have a good appreciation of how Ruby works. For that, you need to have used Ruby in anger. It’s not a book for a new Ruby developer.

The last of the three books in my trilogy, is Pat Shuaghnessy’s Ruby Under a Microscope. I have only just finished reading this book in the last couple of days. It is easily the best Ruby book I’ve read since reading Design Patterns in Ruby. It is a fascinating investigation of how Ruby works under the bonnet. It teaches why Ruby works the way it does.

For me, Ruby Under a Microscope is THE book to read once you have learnt the lessons from reading the other two books, and used those to write Ruby code, and hone your skills.

So if you’ve got this far, I hope you will understand why I think these three books shouldn’t be read at the same time. They represent three stages of moving from a beginner to a seasoned Ruby developer, and it’s not until you’ve master the lessons from one, that you should move onto the next in my opinion. That takes time and effort, but it is well worth it. They are three excellent books. Just don’t rush to read all three at once.

I have recently had to split a class into two and found raising exceptions via a new error class was key to the success of this process.

I’ve been working on Geminabox. The goal was to add the facility for Geminabox to act as a proxy for RubyGems.

At an early stage of the development, there was a requirement to split the Geminabox class into two. The problem was that this class was both handling the storage of local gems, and the HTTP requests for this service. This made it difficult to hook into Geminabox to store a new local gem, without also loading up the Sinatra component that was handling the HTTP requests.

A key to understanding the problem is to have a look at the original Geminabox#handle_incoming_gem method. This method calls further Geminabox instance methods to handle the storage of the incoming gem.

The solution was to create a new class that would handle the gem storage, and for Geminabox#handle_incoming_gem to pass the new gem to that class. The new class was called GemStore.

In the original Geminabox class, the error handling was combined into a single method that also controlled the output of an HTML error report via HTTP. That method being Geminabox#error_response. This method could be called by a number of Geminabox instance methods active in the gem storage process. The raising of errors needed to be separated from the mechanism for displaying error messages.

The result was a new error class GemStoreError. Now GemStore could raise a GemStoreError when a problem was identified. Then any process using GemStore could easily identify these errors and handle them appropriately.

With GemStore and GemStoreError in place Geminabox#handle_incoming_gem could be refactored, and other processes could use GemStore to store gems within Geminabox.