Slightly Technical

I came across this post about Ruby Mendicant University while reading up on Prawn, a Ruby PDF generation library. RMU is an interesting idea in its own right – is it a new idea? – but what I liked about the post, what connected with me, was the discussion of the ‘plateau’ of learning that comes after grasping the basics of the language, when the need is to discover about good style and efficient, elegant coding. That’s something very familiar.

There are a lot of people who have gone through the initial gauntlet only to plateau and find that while they can play by ear, they can’t quite read the music

Because I often work alone and I have to somehow solve the problems I take on I am slowly grinding away at my Ruby ignorance. It’s great to find neat and expressive ways to achieve things, and it’s always depressing to leave a trail of ugly-looking code in one’s wake, so there are sticks as well as carrots. But as the interviewer prompts, ‘Underwear + ??? = Ruby Knowledge. Meaning, there’s bloody nothing in the middle range.’ In other words, there’s a deafening internet silence just at the point when guidance could be most valuable. This stage includes all sorts of really interesting things, things I know I want to know about but which are nevertheless frustratingly unknown unknowns.

My previous post perhaps illustrates the rather unfocused understanding I have gained so far; I wasn’t able to make the correct assumption about the precedence of the operators because I wasn’t taking into account the = operator in the statement. Un-fluent thinking.

I would guess that in a team with a strong leader, or with a mentor, this stage can be crossed pretty fast. But for those people who are more isolated, the idea of focused group learning online, via IRC, sounds smart. And it looks to be a success so far.

I wanted to define a variable in a way that allowed it either to be the result of a method or, if that method didn’t produce anything, a preset default value.

The method was written so that it would return nothing if a certain condition was not met. Here’s my experimental version:

def foo(argument)
  if argument.class == "".class
    return argument
  end
end

foo("bar")
=> "bar"

foo(123)
=> nil

Then I tested to see what happened if I wrote an expression to evaluate the output. I used the ‘or’ operator. It behaved as expected:

foo("bar") or "Nope!"
=> "bar"

foo(123) or "Nope!"
=> "Nope!"

But although when calling experimental method it does not seem to matter what kind of object is given on the right hand side of the evaluation…

foo("bar") or {"test"=>1, "me"=>2}
=> "bar"

foo(123) or {"test"=>1, "me"=>2}
=> {"me"=>2, "test"=>1}

… a similarly written expression in the real script would receive nil from a method, yet that returned value of nil would be chosen in preference to the object on the right hand side. Effectively:

foo(123) or {"test"=>1, "me"=>2}
=> nil

I changed the evaluation operator from ‘or’ to ‘||’, and it worked nicely, effectively:

foo(123) || {"test"=>1, "me"=>2}
=> {"me"=>2, "test"=>1}

Here is Programming Ruby 1/e on the or and || operators:

… both “or” and “||” evaluate to true if either operand is true. They evaluate their second operand only if the first is false. As with “and”, the only difference between “or” and “||” is their precedence.

http://ruby-doc.org/docs/ProgrammingRuby/html/tut_expressions.html#S1

On Monday I had the privilege to see a 4mm/ft scale model of a Terrier, a small British railway steam locomotive of the 1870s, that can run on live steam. It’s quite common for people to construct motorized models at this scale, but not to build ones that run on the same principles as the original. The cylinders, where power is developed, are 12” diameter by 20” stroke on the full-size locomotive; that means those of the model, to scale, are 4mm diameter by 6.6mm stroke. The valves, which control the admission and exhaust of steam, will be a fraction of that size. Truly remarkable.

Libre Graphics Meeting 2010 featured a number of talks about fonts. I’m enjoying Nicolas Spalinger’s talk on practices for designing, releasing, maintaining and packaging open fonts at the moment, and there are several more.

Three recent things show how far, at least in public, web fonts have moved.

Google’s web fonts subscription service, with its previewer

Apple’s attempt to own HTML5 (associated with its efforts to diss Flash), including a natty web fonts/visual effects demo that only runs on Safari (unless you play with the referer string, I hear)

And finally, an excellent roundup of the state of play by Richard Fink on A List Apart.

Slightly further behind the scenes, the W3C Web Fonts Working Group is currently bickering about the format of metadata in WOFF files, so I am confident that the spec will move forward in the none too distant future. Happy days!