Leo's Technical Blog

Things a Ruby Developer Should Know?



Leo Soto

advising, ruby, asking

Things a Ruby Developer Should Know?

Posted by Leo Soto on .

advising, ruby, asking

Things a Ruby Developer Should Know?

Posted by Leo Soto on .

I'm currently working on a Ruby on Rails web application. I'm happy again because the language doesn't get on my way while programming. But I'm far from being a seasoned Ruby programmer, so I've been learning a lot.

Something that amazes me, is how people develop on Rails without knowing too much of Ruby, at least on my work environment. And how comfortable they seem! It may show how easy is to do web applications with Rails, but I don't think that it's a good thing overall (for them, that is. Rails is OK). They may argue that Rails is a good enough tool to solve their problem, so they don't need anything else, but how can they assert that without having an idea about the other possibilities? Almost everything is good enough when you don't have alternatives. Heck, 64 kilobytes of memory were good enough for people some years ago.

That doesn't work for me. I feel unpleasant when I'm using a programming tool almost blindly. I must know why (at least the basic) things work, and if times suffices, how they work.

So after a few weeks of using Ruby again, I must say that Ruby is a nice language. Its expressiveness is superb, and I can't emphasize enough how much that matters. Half of Rails greatness comes for the flexibility of the language upon it is built.

If you are already using Rails, this secret weapon called Ruby is right there, waiting to be used. You haven't to pay anything. So, please, use its expressiveness to make your program clearer. Short the distance between what you write and what you solve. It's not Lisp, but it's closer. They now call it "writing internal DSLs", but take the hype with a grain of salt: they are not new, and they aren't the silver bullet. They should be in your toolbox, though.

You can decide to not use some Ruby tricks, but only after knowing why is a bad idea to use them on the problem at hand. Not because you are too lazy to learn about the language.

Every programmer who is currently working on a Rails application and hasn't learned enough of Ruby is missing a lot. By now, this is my list of things a Ruby developer should know, in no particular order:

  • How to simulate keywords parameters
  • How to write mix-ins

  • What is method_missing

  • How source files are imported/evaluated

  • What are blocks and how to write methods that accept them
  • How to define anonymous functions
  • How to use the *eval methods

But who am I to establish what a Ruby developer should know? In fact, I still don't know too much about two of the items of my list. I'm sure there are other topics where I'm so ignorant that I haven't heard of them.

So, what's missing on this list?