Ruby Exercises - Continued

It has been a few days since I forced myself to start coding in Ruby. So far, it's been very rewarding. I have been coding simple things that I had already coded before: towers of Hanoi, anagrams, reverse polish notation, primes "up to", great common divider, lowest common denominator, etc. The whole point is not to learn new algorithms ... it's to learn Ruby.

I have tried to become aware of my areas of uncertainty/darkness. Whenever I code and I get this feeling that I am cutting corners or avoiding a problem, I take a moment to analyze my doubts. This is all part of my new life philosophy I have adopted since I read: Make a Mess, Clean it Up!

Avoidance is easy. It's easy to code "around" a problem rather than looking things up. I have read about this recently: Creeping featurism and the ratchet effect. I understand the argument for laziness. But, I think there is also something else - something I would like to call "checkbox mentality".

This phenomenon occurs when you are working on a task and would like to finish it - to cross is off your list. But, at some point during the execution of that task, you realize that the problem is more complicated than you thought. As such, not only are you not done, you now have to divide your task in a collections of subtasks.

Here is an example for something I worked on today. I tried to put as many tasks as I could remember I did. (photo exported from FreeMind btw)


Everytime you subdivide your task, you create more work for yourself. You create something that requires effort.

I had to Google. I had to go back to the book. Sometimes I had to go back for reference reasons. Some other times, I had to go back because my brain did not register what I thought I had read and understood. It's all part of learning. It's all part of being a professional and striving for perfection.

Now I know: if it hurts it's because I'm doing the right thing. :)

Ruby Exercises

I have mentioned before that I was in the process of reading Programming Ruby (2nd edition). The more I read it, the more I love Ruby.

However, as I have learned in the past, reading a book about a programming language does NOT mean that I truly understand the depths of what I am reading. Consequently, I have decided to come up with a series of exercises/drills/katas to force me to use Ruby.

Though I would like to come up with an actual list custom-designed for my needs, for the mean time I have decided just start programming and stop making excuses.

Virtual Desktops

I had made a list of things to do this morning. I sat down with my iBook -- ready to go. Then I realized I needed to take care of something that I had been missing for a while: virtual desktops on Mac OS X.

I thought I'd give Mac OS X's Exposé a chance and that installing a virtual desktop manager might have prevented from fully understanding and/or appreciating Exposé.

Don't get me wrong, I think Exposé is great. But, to me, it's more of a "where's-that-window" feature than an organizational tool. In contrast, virtual desktops do allow me to truly separate my windows into "concerns". When I use virtual desktops, I usually set up as many as 10 virtual desktops: my development desktop (where I code), my "testing" desktop, my log-and-top desktop, my research desktop (Google), my email desktop, my "personal" desktop, and a few spare ones for other things that might come up but that I don't want to mix with everything else.

A few people have commented on the overkill-ness of my setup. It's definitely a new way to organize your work. If virtual desktops are meant to (poorly) emulate multiple monitors, let me ask you this: What would you do differently if you had 2, 3, 5, 10 monitors?

Virtual desktops create virtual screen real estate. As a side-effect, they give you enough space to prevent you from "managing" your windows. On each desktop you can create static spatial arrangement. Once I open, resize and position a window, I barely touch it anymore. In the same way that if you always put your stapler at the same place on your desk, you won't have to look for it and will probably be able to reach for it without even looking. For me, the keyboard shortcuts become natural extensions to mental processes (I need to check the log => 3rd desktop => Command-Option-3) -- very little conscious thought is required, it becomes automatic.

(Interesting idea: real world Exposé for the the stuff on your desk. I guess that would be a very Matrix-like effect where you would throw all your stuff in the air, the moment would freeze, you pick your stapler and everything falls back exactly where it was)

When you use Exposé, you have to make the mental effort of not only recognizing the things you are looking at (which is even harder for look-alike windows on your OS), but to track down their varying positions. After all, Exposé does have the annoying tendency to change the position of the windows it displays based on an algorithm I don't fully understand. Arguably, I shouldn't have to understand it either.

So, I guess, for me, it's not just a question of screen real-estate. It's a whole organizational system derived from spatial arrangement of different desktops and a contract with myself that the concern of a specific desktop is respected. That is, that desktop 9 is where my email "lives" and that desktop 3 has my "tail -f" log terminal, "top" terminal and root privileges terminal at their respective positions.

Learning Rails and Ruby

When was it again that the Ruby on Rails buzz started? I remember watching the Quicktime video (it wasn't this one: Creating a weblog in 15 minutes - but it was very similar) and having that sinking feeling that I was missing something important. I remember doing some research and trying to find the facts that would indicate that it was too good to be true.

Then I decided to buy this book: Programming Ruby (2nd edition). It was a setback. Having programmed in Python for 3-4 years by then, I was resisting learning Ruby - a language similar yet different. The examples from the early chapters didn't convince me enough to keep at it. I put the book on hold for a while and pursued other interests.

But Rails was always in the back of my mind. I remember discussing it with some colleagues and "forcing" them to watch the video (hey, it's only 15 minutes, right?). I did like to watch the look on their faces.

I was doing some more Rails research when I came across an article which basically said, get this book: Agile Web Development with Rails and to come back to Ruby afterwards. This was an important breakthrough in my Rails learning - I read the Rails book, learned Rails and was convinced to come back to Ruby -- I'm back on "Programming Ruby" these days ... it seems I get it now.

This reminds me of this quote: "I see a lot of Rubyists worrying that Rails is stealing the show. Geez, folks, LET it steal the show." from Steve Yegge's Bambi Meets Godzilla. Rails was, for me, a major incentive to learn more about Ruby. Not to say I wouldn't have gotten around to learning it anyway down the line... but Rails just brought a lot of attention to the Ruby community.

But one thing struck me last night as I was reading the book. Ruby is both more and less complicated than Python. For example, classes seem to be packed with more methods than Python, which seems like steepening the learning curve to me. And the syntax doesn't always seem as clean as Python's (I never minded the forced indentation in Python - that took me 5 minutes to get used to). And there's also these LISP reminiscent blocks and closures which I'm still trying to FULLY grasp.

So, why does programming in Ruby seems so natural then?

I can think of 2 reasons right now:

• A lot of the minor annoyances I had when programming in other languages have been taking care of by Ruby. The sum of all of the little nice things in Ruby do add to a lot.


• There is a "this-wasn't-slapped-together" feeling that I sometimes had in Java and even Python.

I'll have to think about that some more.