Ruby Conversion Methods

I've been reading Avdi Grimm's Confident Ruby. It teaches you how to write "methods that tell a good story".

I didn't know much about the different conversion methods there are in Ruby, so I'm going to do a quick overview of what I've learned so far with the book.

This is useful while writing methods and classes, since we can make our classes more flexible and our methods more forgiving while not making our code timid, as Avdi says.

Implicit Conversions

These are used by the core libraries to assert objects are of a similar type and a have a well defined conversion to the target type.

def strict_repeat(text)
  text = text.to_str

  3.times do
    puts text
  end
end

strict_repeat(2)  # Won't work
# ~> -:2:in `strict_repeat': undefined method `to_str' for 2:Fixnum (NoMethodError)
# ~>    from -:9:in `<main>'

strict_repeat('2')
# >> 2
# >> 2
# >> 2

Explicit Conversions

If we want to be more forigiving, we can use explicit conversions. These are not used by the core libraries, except for string interpolation.

def forgiving_repeat(text)
  text = text.to_s

  3.times do
    puts text
  end
end

forgiving_repeat(2.30)  # OK
# >> 2.3
# >> 2.3
# >> 2.3

String interpolation uses these conversions, since we want to get and object's textual representation.

class Demo
  def to_s
    "demo"
  end
end

puts "to_s: #{Demo.new}"
# >> to_s: demo

Conversion Functions

These are functions (i.e. don't use the self implicit argument) from the Kernel module.

We can use them if we want to convert some object to a certain type while ensuring it's done in the most sensible way possible: the explicit conversions will be the last option.

def sensible_repeat(text)
  text = String(text)

  3.times do
    puts text
  end
end

sensible_repeat(['what', 'the'])
# >> ["what", "the"]
# >> ["what", "the"]
# >> ["what", "the"]
/2014/06/20/ruby-conversion-methods/

Hardware Fails, Sometimes

Sometimes it's not the code you write, it's the hardware being used. I'd like to think it's not the common scenario. Code can easily (more or less) be fixed, while hardware...

Well, you don't expect it to fail, so time is burned.

Totally Fictional Example

Nexus 10 we use at the office (for development, no less) with a broken magnetometer.

First: find the problem, discard any software error. Debugging, testing, wasted hours.

Second: demonstrate to the technical support there's really something wrong about the device. Emails, screenshots, debugging, tests. Wasted hours.

And it's still sitting on my desk waiting for the official tech support to do something about it.

On my fictional desk, sorry.

Fictional "fuck you!", compass sensor.

/2014/06/03/hardware-fails-sometimes/

Learning To Fall

And I'm not talking about success and business.

Learning to skate in your twenties is fun. And, fuck, you learn to fall. You have to. In front of people. And that by itself is something.

By the way, the culprit: a black Kroma with green wheels and white trucks.

/2014/05/10/learning-to-fall/

Rails, Two Years Later

More than two years ago I had my first contact with Ruby on Rails. Since then I've done a lot of different stuff (technically speaking) and my vision (i.e. opinion) of this framework has changed substantially.

More Than Two Years Ago

Basically two points:

Note: I know these aren't strong cases against Rails

1. It's Too Much

By then I was fully invested learning and using Python and Flask. I played a bit with Sinatra, too.

I loved the overall simplicity of these frameworks (or microframeworks).

from flask import Flask

app = Flask(__file__)

@app.route('/')
def index():
  return "Hello World!"

app.run()

2. You Don't Know What's Going On

So many auxiliar and utility classes, methods, etc. If you don't know Ruby, you end up not knowing what's Rails and what's standard library.

"Hello".blank? # Bzz! It's rails!
"Hello".strip.empty? # Ruby alternative

Would something similar happen if you learned Python while using Django?

But!

But I hadn't come across the problems I've had to face these last months.

Building a full featured CMS, that started with simple enough requirements but didn't stop to grow in features (that's another story) with Sinatra was a rich learning experience.

  • I've learnt to organize Sinatra apps like a boss
  • I've been able to apply a lot of neat Ruby tricks (cleaner code!)
  • I've faced standard problems and researched proper solutions
    • User authentication
    • File uploading and transcoding
    • Asynchronous tasks

Some days ago I resuscribed to Code School, and after resuming its Rails courses I can say I really like it: I understand the decisions behind the facilities provided, behing the magick.

I still recommend starting with a microframework if it's going to be the first contact with a specific language.

As usual, the right tool for the right job.

/2014/03/12/rails-two-years-later/

Everybody Has Ideas

A little (but recurrent) argument I have with a friend, on idea vs execution:

  • He says the idea is everything
  • I say an idea is nothing without proper execution

No agreement forecast.

/2014/03/11/everybody-has-ideas/