Have you watched this video?

If not, you’re living in the past. Self-driving cars are coming, that’s something that we all know by now, and that should not scare us, even though many people are trying to demonize this technology.

I’m not writing this post to debate whether or not self-driving cars will kill the driving experience; what I want to ensure with this post is that ENGINEERS WON’T CODE ANYTHING IN YOUR CAR THAT WILL KILL YOU OR WILL KILL OTHERS. Engineers are smart people, cars need pass lots of security tests before they are put in the market, and what is most important: the most important reason behind self-driving cars is to increase security as close to 100% as possible in order to preserve the human life.

Using the same scenario that the video uses, I will try to explain why engineers don’t need to program your car in order to kill you or to kill someone else, but rather saving your life and the others.

This is the scenario:

  • You have a fully connected car, equipped with tons of sensors (cameras, proximity sensors, GPS, heat sensors…) all around the car, processing in real time.
  • You have one truck on front, loaded with dangerous materials that can fall any time.
  • You have one vehicle, at your same level, on both your left and your right. Let’s say, a car with 4 people inside on your left; on your right, a motorist without helmet.

Under this scenario, what the video proposes is that, in case the truck loses its load, the car would have 3 different choices, and every one of those options involves, without any other alternative, putting your life or other’s life in danger:

  • If the car decides to go straight, you will hit the load and/or the truck, and therefore, YOUR LIFE MIGHT BE IN DANGER.
  • If you decide to skip the collision with the truck, two things might happen:
    • In order to preserve as many lives as possible, the card decides to go right, so there’s a big chance of hitting the motorist, putting THE MOTORIST LIFE IN DANGER.
    • Your car has detected that what you have on your right is car, so in case of collision with it, there is a bigger chance for its passengers to survive, and therefore, the car, knowing that, decides to go right and hits the car, putting THE 4 PASSENGER LIVES IN DANGER.

Oh man! There is no escape… there is no hope in humanity. Engineers will have to decide what lives are more valuable, and we all are going to die!

Well, eventually, we all are going to die, but it won’t be because your car is trying to kill you. Think about again for a second: you have a self-driving car, full of sensors, and tons data being processed in real time, so the question is…

Is that scenario valid?

Absolutely not! You have a ‘smart car’! You should never be even in that scenario. Because your car has cameras, it can easily detect that what it has on front is truck with a dangerous load, so it can maintain a proper security distance; even the car would know that has vehicles on both sides, and therefore, it would even reduce speed as necessary until NO ONE IS ON DANGER, and when possible, it would change lines, so it would avoid any dangerous situation. The car can even detect what’s approaching it, and plan many alternatives ahead of time, rather than deciding who’s live should be in danger.

Engineers won’t program your car to kill anyone, but rather will make use of all the technology available in order avoid these kind of dangerous situations. Self-driving cars are there to make your life and other’s life easier, and more comfortable.

Think about it for a second, the car will always avoid dangerous situations, and for every possible scenario, engineers are working full time in order to ensure that there is always a solution that will TAKE YOU HOME SAFELY.

Here you can find the slides that I used for my presentation at Chicago Code Camp 2015. It was an amazing experience, and I only have words of gratitude to the organization and sponsors; it is awesome to find events for developers of such high quality for free.

There are tons of text editors out there, and every single developer has its own preference: Sublime Text, TextMate, Notepad++, GEdit, Emacs… same thing happens with IDEs, such as Eclipse, IntelliJ, XCode, RubyMine, Android Studio, Visual Studio… every single one has its own pros and cons; however, if there’s a text editor that is the preference of the so-called “hardcore programmers”, that is Vim.

Vim is a free and open source text editor based on Vi; you will probably have it installed on your computer, so go ahead, open your terminal and type vim test.txt; your terminal will turn into a full and rich text editor, which is awesome. There are great tutorials out there to learn how Vim works (if I have to choose one, this interactive tutorial is my favorite) that will show you how to get the best form Vim.

While I’ve used Vim in the past for minor things (squash my git commits, do a simple edition on a file…), it has been this last month when I’ve started to use Vim intensively: every single day I have to work on a remote instance of a Debian machine that contains a Rails application. In the past, when I had to work with Rails, I used Sublime Text or RubyMine, but never Vim before, and I was very happy with results.

Vim is totally customizable, and you can add as many plugins and fancy stuff as you can imagine, which converts Vim into a great development tool (as you can see in the following video):

However, Vim is not “my tool”. Maybe I’m used to “the graphical” text editors, maybe I don’t want to learn a whole new set of shortcuts (yeah, when I press Cmd + F I want to do a search, and want I type something I want to write something… yeah, I’m looking at you, “INSERT MODE”) or maybe, I’m just human and variety is just the spice of life, and I am that kind of developer who doesn’t like to use Vim for everything.

Just to illustrate how “hard” is to me to get used to Vim, I have found this little joke to be very appropiate:

How do you generate a random string? Put a first year CS student in front of Vim and ask him to save and exit.

The only thing that I can do is to learn as many Vim features as I can, but looks like I will continue using my mouse, using the arrow keys… and using any other text editor or IDE when I can ;)

Recently, I joined the “O’Reilly Reviewers” program, and the first book that fell into my hands was Learning Android, by Marko Gargenta and Masumi Nakamura.

The first part of the book is a brief introduction to the Java programming language, used to develop for Android. After this introduction, you will start the creation of a Twitter-like application called Yamba that covers the core concepts of every Android application: activities, fragments, services, content providers, async tasks, etc.

The book follows always the same structure: it will introduce you the concept that you are about to apply in your app, and right after that, you will introduce your new changes in the program; with all the new code in place, you will see a more detailed explanation of what you did. In my opinion, this is a great approach to fix the concepts in your mind, as you will understand every step that you’ve taken in a very simple way. However, you will find numerous errata in the code, and this could make you feel that you’re doing something wrong when that’s not the case.

Also, to start the development, you will need to use a library called “yambaclientlib.jar”, and the book provides a URL that, instead of pointing to the JAR file, it will take you to the Github repository of the library; what I had to do was to clone this respository, and inside the libs folder you will find the JAR file that you need in your application.

Finally, I was expecting to use Android Studio in this book, since Android Studio was released in the Google I/O 2013 and it’s the new IDE recommended by Google, but instead, you will use Eclipse and the ADT plugin.

Overall, I enjoyed reading this book, and I liked how clear and well explained were the concepts of Android development, but at the same time, it was frustrating to see all the those errors in the code; this will cause some beginner students to abandon the book.

I review for the O'Reilly Reader Review Program

A new version of Ruby (concretely, Ruby 2.1.0) was released on December 25th, 2013. It’s time to go through all the new features!

First of all, let’s make sure we’re on the same page; in your terminal, run the following command and make sure you have the version 2.1.0 installed in your computer:

$ ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin13.0]

New features

The most relevant changes introduced in Ruby 2.1.0 are: (release notes here)

  1. def's return value: no more void methods
  2. Rational and Complex Literals
  3. Refinements
  4. New Exception#cause
  5. New Garbage Collector

def's return value: no more void methods

In previous versions of Ruby, the return value of a method definition was always nil. Here we have an example:

$ irb
irb(main):001:0> RUBY_VERSION
=> "2.0.0"
irb(main):002:0> def test_method
irb(main):003:1> end
=> nil

However, in Ruby 2.1.0, method definitions return always a symbol that matches the name of the method:

$ irb
irb(main):001:0> RUBY_VERSION
=> "2.1.0"
irb(main):002:0> def test_method
irb(main):003:1> end
=> :test_method

This feature is very useful in those classes that are longer than usual. In old Ruby implementations, we used to have the private keyword followed by all the private methods, but in long classes this keyword was easy to miss out. Here we have an example of an old implementation:

module TestModule
  def public_test_method

    def private_test_method

Knowing that private can accept a symbol, in Ruby 2.1.0 we can combine the method and its visibility:

module TestModule
  def public_test_method

  private def private_test_method_1

  private def private_test_method_2

Rational and Complex Literals

In Ruby 2.1.0, the suffix i for complex numbers has been introduced:

$ irb
irb(main):001:0> (5+3i) + (2+2i)
=> (7+5i)

Working with rationals is also a better experience; the suffix r has been introduced as a helper for the Rational class.

$ irb
irb(main):001:0> (3/5r) + (2/3r)
=> (19/15)


In Ruby, all the classes are open; this means that we can modify classes without any restriction. Refinements are an elegant solution to apply our modifications only under certain scopes:

module URLBuilder
  refine String do
    def url_builder

class Article
  using URLBuilder

  def initialize(title)
    @title = title

  def build_article_url

As a result, when we execute this code, we will obtain:

irb(main):01:0> article = Article.new("My First Article")
=> #<Article:0x007f89f89d3080 @title="My First Article">
irb(main):02:0> article.build_article_url
=> "http://www.jcocaramos.com/my-first-article"

We can verify that String#url_builder only exists in the scope of the Article class so easily:

irb(main):01:0> "My First Article".url_builder
NoMethodError: undefined method `url_builder' for "My First Article":String
  from (irb):1
  from /Users/jorgecoca/.rbenv/versions/2.1.0/bin/irb:11:in `<main>'

new Exception#cause

Often when a lower-level API raises an exception, we would like to re-raise a different exception specific to our API or library. Currently in Ruby, only our new exception is ever seen by users; the original exception is lost forever, unless the user decides to dig around our library and log it. We need a way to have an exception carry a “cause” along with it.

This explanation can be found here.

In Ruby 2.1.0, now we can do something like this:

class CustomExceptionClass
  def method_with_exception
    cause = nil
      raise "2nd message" # RuntimeError
    rescue => e
      raise StandardError, "1st message"

rescue Exception => e
  puts "Caught exception: #{e.message} [#{e.class}]"
  puts "Caused by: #{e.cause.message} [#{e.cause.class}]"

The output of this code will be:

Caught exception: 1st message [StandardError]
Caused by: 2nd message [RuntimeError]

New Garbage Collector

Ruby 2.1.0 incorporates a new Generational Garbage Collector that replaces the old implementation of the stop-the-world mark and sweep algorithm.

The key idea and observation is that objects that are most recently created often die young. Therefore, we can split objects into young and old based on whether they survive a garbage collection run. This way, the garbage collector can concentrate on freeing up memory on the young generation.

Ruby has been always accused of putting performance in a secondary place, but with these changes we can see that the Ruby core team takes performance seriously.