Jonathan's Techno-Tales

Wordpress

2007-02-10T16:32:00.000-05:00

I decided to migrate to wordpress.com for my blog.

I initially copied all my blogger entries through the API. After a lot of fighting with the formatting, I concentrated on my entries (3) since January 1st, 2007.

So, this is where it happens now.

Ruby Streams

2007-02-02T22:30:00.000-05:00

I've been thinking about my business days problem some more. And this time I turned to Ruby, a language which I am becoming quite familiar with.

This is my naive implementation of streams in Ruby. Streams are thus functions. The actual class name is 'Proc', a lambda returns a 'Proc'. Each call returns a new value.


def stream_from(value)
  lambda {value = value.succ}
end

class Proc
  def filter
    f = lambda do
          value = self.call
          return (yield(value) ? value : f.call)
        end
  end

  def take(n)
    result = []
    n.times {result << self.call}
    return result
  end
end

As for "filter", it takes a predicate passed as block. The filter becomes a "decorator" for the stream.

This is a nice example of closures. The 'value' parameters becomes the state for the stream. Also of note, the use of the variable 'f' to fake recursion of an anonymous function.

Prints the 20 next business days:


s = stream_from(Date.today).filter {|date| date.cwday < 6}

puts s.take(20)

Note that my "contract" with stream_from is that what I pass it implements succ. Here's an example with integer:


s = stream_from(4)

puts s.take(20)

And, of course, filters can be chained. The next Monday that falls on a 17th:


s = stream_from(Date.today).filter {|date| date.day == 17}.filter {|date| date.cwday == 1}

puts s.call.to_s

Here's the same code as before, but with a function cast as a block:


def monday?(date)
  date.cwday == 1
end

s = stream_from(Date.today).filter {|date| date.day == 17}.filter(&method(:monday?))

I decided consciously to avoid optimizations here. It did keep my code short and clean. Besides, you should only optimize based on need.

There's much more to streams... combining streams together, maps, more complicated generation of the next value, etc.

So, here's your next interview questions:

"What's the first 3 prime numbers after 5,000,000,000 which has a 3 as last digit?"


s = stream_from(5_000_000_000).filter{|x| x.prime?}.filter{|x| x.mod(10) == 3}

puts s.take(3)

I leave the code for "prime?" to your imagination.

The concept of command-line pipes springs to mind. One of the reason the command line is so powerful, is that you can combine filters together to perform truly complicated tasks. Another reason is that each filter does only one thing and does it well.

It's all about thinking in pipes.

The Story of business_days(...)

2007-01-31T00:37:00.000-05:00

I've been really busy with work recently. However, while going over my requirements for the nth time, something caught my eye: business days. In particular, finding the date 7 business days from a another date.

Far from being a hard task, it fell more into the annoying category. Or maybe it would make for a good interview question. In the end, how complicated or simple can someone make such a function?

A little background first. I had to use JavaScript, a language I'm only superficially familiar with. Also, after discussion with the customer, the definition of business days was Monday to Friday. No holidays are included... In fact, which holidays? And from what region/country?

Having flirted with Haskell recently and being "influenced" by the SICP lectures, a few ideas came to mind.

"business days" is a subset of "days", and both are infinitely lists. If I have a list of all the days and I filter it through the is_business_day(date) function, and I access the element at position 7, I get the answer. I was getting pretty angry with my inability to accomplish my task in such a straightforward way. I started to understand what people mean when they talk about the expressiveness of a programming language.

I then turned to Ruby for ideas. The succ function came to mind, I made that my starting point.

function include(value, list) {
  for (var i=0; i < list.length; i++) {
    if(list[i] == value) return true;
  };
  return false;
}

function succ(date) {
  return new Date(date.getTime() + 1000 * 60 * 60 * 24);
}

function is_business_day(date) {
  return include(date.getDay(), [1,2,3,4,5]); // mon-fri
}

function business_succ(date) {
  var result = succ(date);
  return is_business_day(result) ? result : business_succ(result);
}

function repeat(f, x, n) {
  if(n == 1)
    return f(x);

  return f(repeat(f, x, n-1));
}

function days(date, n) {
  return repeat(succ, date, n);
}

function business_days(date, n) {
  return repeat(business_succ, date, n);
}

Personally, the moment of enlightenment came when I realized that iterating for days or business days was the same code and that it could be made even more generic by the repeat function.

A few comments:

the include function would usually be borrowed from prototype.js

recursion has become part of my day-to-day programming techniques

all functional

definitely not the shortest code I've written, but all pieces are both trivial and reusable

a definite LISP-like flavor

proof that SICP and friends have been damaging my brain :)

I didn't "get" bookmarklets

2007-01-04T10:45:00.000-05:00

I have only recently been fully aware of the joys of bookmarklets. Of course I had the del.icio.us bookmarklets for quite a while now, but, the idea had not fully sank in until recently. I didn't "get" bookmarklets.

Yesterday I re-discovered Google Reader and with it came its own, very useful, bookmarklet: Subscribe....

Today I decided to wrote my own: booktrack...

Booktrack is a web application to keep track of the books I read. It keeps track of what I want to read, what I'm reading now and what I'm done reading. This was inspired by librarything.com.

When it came to data entry, I had integrated with the amazon search API and it was working great. However, when people talk about books they usually link directly to the entry at amazon. Being on the page and having to log into my application to look for the exact same book seemed like a task that could be automated.

This was a spur-of-the-moment idea. A what-if that needed answering. 5 minutes later, I had it and it was working. It is relatively crude, but I'll take the iterative approach on this one.

Now I'm wondering what else I could do with that? What else needs a bookmarklet? What have I missed? This is all part of me trying to keep an eye out for stupid and repetitive tasks.

Useful: latest

2006-11-27T21:38:00.000-05:00

I reinstalled my computer from the ground up recently. This has given me a lot of opportunity to question, rethink and automate my day-to-day activities.

As part of my ongoing effort to redeploy my rails applications to my production environment in the most intelligent hands-off way, I've been looking for a way to "detect" the latest deployment.

Here's the script that resulted:


#!/usr/bin/env ruby
$VERBOSE = true

pattern = ARGV[0]
pattern ||= '*'

latest = Dir.glob(pattern).sort_by {|f| File.mtime(f)}.last

puts latest unless latest.nil?

It takes, optionally, a bash-style glob. ( latest 'booktrack*' )

I'm finding it surprisingly useful. Let me know if it helps you out.

Automation - continued

2006-11-19T21:42:00.000-05:00

It has been roughly a month since I started voluntarily pushing the limits of automation in my life. This has been mixed blessing.

PROS:

medium to long -term quality of life is improved
helps me assimilate Ruby libraries
(spending a lot of time on gotapi.com)

CONS:

spending a fair amount of time automating
still facing the initial resistance to automation

A Story: Mac OS X Screenshots

3 words: CMD-SHIFT-4

One of the joys of working with Mac OS X is the screenshot mechanism part of the OS. Nothing to install, it is expected that you would want to take screenshots easily. You type CMD-SHIFT-4, you get a crosshair, you select a region, then a file is created on your desktop. Painless.

CMD-SHIFT-4 takes care of the file creation, a mental block in process of saving a screenshot. In the spirit of Don't Make Me Think, I can testify that one question I don't want to answer when taking a screenshot is "what filename should I save this as...?" Imagine taking a picture with a camera and being asked to give it a filename... I just want to save the screenshot, I will come back to it later. In fact, I just want a long list of screenshots I take to be dumped somewhere, as a chronological series of things I found interesting.

Mac OS X already takes care of incrementing the filename automatically. Image 1.png, Image 2.png, etc... That's great. However, I was not so hot about the default "dumping" location. So, naively, I created a folder called "dump" to which I would push the pictures when cleaning up. What I had not fully absorbed was that I would have a filename conflict on my hands every time I did that. If I had dumped a few screenshots to "dump", took a few more, and tried to push my files to "dump" again, chances would be very good I would have, for example, 2 files named "Image 1.png", the second one wanting to overwrite the first.

Before I had become such a stickler for automation, I had decided to zip the pictures, name the file based on the date and push it to "dump". This involved the manual steps of, selecting only the pictures on the desktop, selecting the "archive" option from the menu, finding out what was today's date, renaming the file in ISO style date format and moving the file to "dump".

Today, while contemplating the mess that my desktop was becoming, I realized how badly in need of automation this process was. So, 15 minutes of hacking later, I had a script that would select the pictures on the desktop (only the ones matching the screenshot naming convention), find out how many pictures I had moved so far (stored in a magic file in the destination directory), move the files while changing their names incrementally. A little more work was involved in figuring out how to have automator run this script as a plugin.

Now, I have what I wanted: screenshots stream.

Revisited: Thinking versus doing

2006-10-31T14:12:00.000-05:00

I've talked about this before. But Knowing, doing and learning puts it better.

I liked this:

...we really don’t know something until we use it. Understanding that we can’t really separate knowing from doing explains why people who love to code are so much better at it than those who don’t: they try stuff out.

And this:

The cycle of learning is to learn a little, then use what you’ve learned, then learn some more.

Reinforces what I said, while being more articulate.

Rails for fun

2006-10-20T23:49:00.000-04:00

After months doing other projects at work, I've been "drafted" for some Java this week. Specifically, I'm making a middleware servlet. Since I knew I was going to do the Java-thing again, I bought Head First Servlets and JSP. Like the others books in this series, it's really really good. Yes, I have mentioned this series twice before, but rest assured that I am not getting any money from this. People who know me know that I have trouble not mentioning the things I love.

Java is still not great, but it's not as bad as I remembered it to be. And maybe it's the machines we have at work, but it feels insanely fast. INSANELY fast. But I digress.

I've been programming in Rails for about a year now. I have 4 fully-functional personal webapps to my count. I also have forkmapit.com that I coded part of. However, much of the credit goes to my friend Daniel.

I eat my own dog food. All the applications I developed, I use on a daily basis. I coded my applications to solve actual problems that I was having. Application development, however, is an iterative process. You release something and your users tell you how close (or far) you are from what they thought they would get. I am my own customer, and I am pretty demanding. When you're forced to use your own application, you soon discover the annoyances and the many ways you could make it better. Tonight, I hit the mental threshold where I decide to fix bugs, streamline and improve.

After a week of Java, going back to Rails is a much needed break. I code in Rails for fun. Like myself, a lot of people using Rails have normal 9-to-5 jobs where they code in whatever technology will ensure a regular paycheck. In many ways, Rails is double-edges sword. It's a pleasure to work with ... but a curse to those who have to "go back" to, say, Java for work. I mentioned to coworkers that going back to Java after having used Ruby felt like having your hands tied behind your back and trying to program by typing with your nose...

The application I was working on, I call "tvguide". With "tvguide", I keep track of the episodes for the TV shows I watch. It was a plain application with a little bit of AJAX to update the numbers in a table.

It was a glorified spreadsheet.

No more... I implemented photo upload to the application, thumbnails for my listings, I completely changed (and improved!) the presentation, I took out pre-RJS DIY AJAX. Best of all, I have a much better application now, with more features and LESS code.

I want the tools I use to empower me. Rails and Ruby are such tools. As for "fun", I would say it's a side effect of using good tools.

Ruthless Automation

2006-10-19T07:36:00.000-04:00

How many people truly use computers to automate repetitive daily tasks? Even if they do, to what extent are they automating these tasks?

I've always been a fan of automating boring and/or repetitive stuff out of my way, but I never conciously made an effort to automate all I could automate. That was until I read Saving Time and Pragmatic Project Automation.

I can think of 4 reasons for automating your tasks:

It forces you to really "understand" a task. What am I exactly doing here? Is there a better way? Is this robust?

It documents a task. Not just a series of steps in your head anymore. The script is the intent, the all encompassing series of steps you need to do combined with the things you need to "touch" to accomplish your tasks.

It saves times. This one is obvious and is the most often presented reason. I would dare say that taking 10 minutes to automate something that would have taken 5 minutes is still worth it. Read on.

It hones your skills. Makes you practice your soft-scripting skills

In light of #4, you can now see automation as an end rather than a means.

Daily automation will expose you to a lot of small problems. "How would I get the third column from that file?" "How would I insert a line after a match in a file?" "How many lines are in that file?" "How many times is the word 'tomato' in that file?" Note here that everything is a file in UNIX, so these examples are more general than they appear.

The more you automate, the better a programmer you become. The better a programmer you are, the easier it is to automate. You can also consider better understanding, better process documentation and time-saving as welcomed side-effects.

Mocking Ruby

2006-09-14T13:13:00.000-04:00

No... not like it has been recently.

The question came up of whether I had been using mock objects before and how I would do it in Ruby. Having read recently Pragmatic Unit Testing, I had a few ideas on how to proceed. However, the rules change when you are using Ruby instead of Java.

Here is the test code I answered my questions with:


puts "before: #{Time.now}"

class Time
  def self.now
    'mock answer'
  end
end

puts "after:  #{Time.now}"

Outputs:


before: Thu Sep 14 13:02:46 EDT 2006
after:  mock answer

No wrapper class. No factories.

For the sake of full disclosure:

You might want to save a pointer to the old method.

The way you would do that is a little cumbersome for static methods . But it's very clean otherwise.

namei

2006-07-24T11:01:00.000-04:00

I stumbled today on namei, an executable found on Linux. I'm not sure why I've never been exposed to it before, FreeBSD not packaging it comes to mind, but this is truly useful. In a world of softlinks, with all their benefits and drawbacks, namei follows the trail until it reaches a real end point.

Here's a sample output on a RHEL box:


# namei `which java`
f: /usr/bin/java
 d /
 d usr
 d bin
 l java -> /etc/alternatives/java
   d /
   d etc
   d alternatives
   l java -> /usr/lib/jvm/jre-1.4.2-gcj/bin/java
     d /
     d usr
     d lib
     d jvm
     l jre-1.4.2-gcj -> java-1.4.2-gcj-1.4.2.0/jre
       d java-1.4.2-gcj-1.4.2.0
       d jre
     d bin
     - java

The best part is that I know exactly how this was coded ... and that I don't have to do it myself.

Thinking versus doing

2006-07-21T11:08:00.000-04:00

Ever had the feeling that:

the task at hand would be easier if you mastered the topic more?

you had researched a topic thoroughly but had nothing to show for it?

In the last few months, I've become more aware the tradeoffs required to program. There is a constant battle between thinking and doing. More importantly, there is a need to be careful about over-thinking and over-doing.

Thinking	Doing
research RTFM planning designing	implementing experimenting practicing typing (!)

Pitfalls of "thinking" too much?

less/no results
less/no practice
less/no hands-on experience to guide

Pitfalls of "doing" too much?

re-inventing the wheel
less than optimal solutions
less/no benefits from accepted best-practice (other people's mistakes)

The key is to constantly switch modes. Code a little bit, research a little bit, refactor/readjust your code, research with your newly acquired experience, and so on.

...

A typical scenario: ASCII downcast

On one of the project I am working on, we ask for city names and display their peer-produced restaurant reviews. The problem comes with cities like "Montréal" which contain accents. We capture the string as UTF-8, that's not the problem. Inserting it into a URL is another matter, although it works, it does make for ugly URLs: Montr%E9al.

The problem becomes, how do I convert "Montréal" to "Montreal"? More broadly, how do I remove all the accents? This is something I call "ASCII downcast", I would be happy to learn the real name of this process -- it would surely guide my efforts towards a solution.

Here are the steps I followed:

I googled for a few keywords
(ruby, conversion, ASCII, UTF-8, downcast)
I researched the Ruby standard library
(especially: Iconv)
I experimented a little bit in irb
(utf-8 to ASCII, utf-8 to iso8859-1 to ASCII)
I googled for more keywords, including problem-specific keywords
(e-acute, escape sequences)
I investigated the tr function of String
I researched tr and multi-byte encoding

Time elapsed: ~1 hour.

This could have taken a LOT longer. Consider that I'm already quite familiar with encodings, conversions, that I had sample files with the same content in multiple encodings, and that I knew the command-line versions of tr and iconv.

The solution that I came up with is:

convert UTF-8 to ISO-8859-1 (raise exception if not possible)
use the tr function and map all accented characters to non-accented correspondent characters
manually map characters -- a one-shot investment
detect other "evil" characters (raise exception if needed)

It works, but it feels like a hack. I feel like I'm missing a library somewhere that already does that. I cannot believe that this problem has not been solved before and it implies I didn't do my research well enough.

This reminds me of another similar situation I faced recently with Flickr-style tags. We implemented a "naive" version of tags for the above mentioned projects only to find this.

It was a learning experience, both coding it and being humbled by a better solution.

JavaScript: The Final Frontier

2006-07-18T09:36:00.000-04:00

While I was in California, I stopped by Borders to have a look. I thought it would be bigger and more exciting. But it was just another bookstore, much like the ones we already have in Montreal. Incidentally, I did found a great bookstore a few days later: DigitalGuru.

However, Borders had a sale on a few books, one of which was: Head Rush AJAX. I mentioned before that I have a great respect for the Head-First series. I could complain that their books are quite verbose, but that's a small price to pay -- they drive the message across.

Once, in high school, at the very beginning of the semester, our English (ESL) teacher told us to write an essay. At the end of the semester, she asked us what we had learned this year. We made a point to explain her that we didn't really learn anything and that it had been a waste of time. We probably used gentler words though. She took out the essays we had completely forgotten about. She asked us to review them. What a difference! We cringed at the mistakes we had made, at our poor vocabulary, at our incredible lack of skills -- at least in comparison with our current level. Thank you for opening my eyes, Mme Lacasse!

It is too easy to think that we aren't improving because we lack the perspective of the before and after.

When I closed the "Head Rush AJAX" book, I thought: "Thanks for nothing..." But I was mistaken. Really mistaken. I only realized afterwards, when faced with my first AJAX problem, that I understood the concepts and I knew what to do. And I knew it wasn't like that before I had read the book. There is skill in teaching without people realizing how much they are learning.

Now I can play with AJAX, feed XML back in the requests and manipulate the DOM. But JavaScript is one of the topics I don't master when it comes to web development. I can "get by" but I definitely don't feel in control. I am waiting anxiously for "Head First JavaScript" as hinted inside their last book.

I could definitely go for more effortless learning.

Remembering Kanjis

2006-06-16T07:47:00.000-04:00

A few years ago, I decided to learn another language. English is not my first language and I remember fondly having to learn it. Learning English had been fun and challenging. It had also given me perspective on languages and thought processes.

For various reasons, my non-obvious choice was: Japanese. Japanese is an interesting language, but one of the most challenging aspect is definitively the writing systems. Japanese consists of 3 writing systems: hiragana (Japanese phonetic characters), katakana (Japanese phonetic characters - used for foreign words) and kanji (Chinese characters). Both hiragana and katakana contain 46 characters (or more, depending on how you count - the point is the order of magnitude) while kanji has ~50000 characters. But, you only need ~3300 to be a literate Japanese adult.

How do you go about learning ~3300 characters? Incidentally, maybe you don't... But you would be missing a whole part of the language. It all depends on your level of involvement.

I have seen too many too many books "throwing" Kanjis at me without a specific goal. Flashing thousands of Kanjis in front of me will not help me learn them. It's all about memory and learning techniques. The correct associations must be created in your head to retain the data. Some of the concepts I strongly believe in are explored here

Yesterday, I picked up A Guide to Remembering Japanese Characters. Worth mentioning:

Detailed explanation of origins and meanings (interesting)
Suggestion for memorizing (mnemonic)
Components making up character (divide and conquer)
school level of the character (track your progress)

The amazing part is that it was the only book, at least in the language bookstore I was in, that was taking this approach! I especially like the first point, learning where the characters are from and why the characters are like that -- which, to me, creates a whole new dimension to the problem.

Another recent example for me was Head First Design Patterns -- a really good book on patterns. The introduction also explains a bit about why the book presents material the way it does: an interesting mix of "cognitive science, neurobiology, and educational psychology". I think there is much of to be learned about "how" to teach rather than "what" to teach.

Doing GTD

2006-06-04T12:11:00.000-04:00

It's been a while since I wrote.

I've actually been doing what's in Getting Things Done. I started reading the book around Christmas and, ironically, it had been one of the things I couldn't get done. I put the book aside when it started to explain the high-level view of how to get organized. That would have been fine if I had known that we would get into specifics in later chapters.

When I finished the book, I knew what to do but there were 2 things I needed:

to reread the appropriate sections
to set aside a whole day to do my inventory

That's what I did. And I thought it was pretty painful. :)

I went around my apartment and my car writing down every single thing that needed doing. I tried not to "limit" my brainstorming, I wrote everything that sprung to mind. It took me 2-3 hours and I collected ~200 items.

At that point, I sat down and went completely through my "inbox". I decided on using plain .txt files and managing them with a TextMate (of RoR fame) project. Incidentally, I could go on and on about how great TextMate is, but that's not the subject of today's post.

I ended up dividing my items into the following files:

waiting for
agendas
at home
car
errands
phone
read/review
research
projects
someday

Tomorrow I'm doing my first weekly review and I might reorganize some of the categories. For example, "research" and "at home" are messy right now and might turn into "at computer" and "at home" when I'm done cleaning them up. I understand the need to "work" with the system a bit and iteratively make things better - I won't get it perfect the first time around. Consequently, I accept to live in my imperfect system.

I can testify that after you start using the system, your brain starts to trust it. But it doesn't happen instantly either... You keep checking your lists to see if you are not forgetting anything. Then you start realizing that some lists don't need you to check them constantly. Especially if you divided your actions appropriately.

Things that I want to address are:

time required
energy needed

I already have "context" taken care of. Maybe I also want to puts "tags" on my items. We'll see... that might require something more complicated than my current setup , and it might not be worth it.

Ruby Exercises - Continued

2006-05-21T21:01:00.000-04:00

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

2006-05-19T10:49:00.000-04:00

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

2006-05-18T10:45:00.000-04:00

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

2006-05-15T10:42:00.000-04:00

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.