Speed, Speed, Speed!

I recently saw a talk from Brian Lonsdorf, where he talks about the obsession with speed in the JavaScript world. I have to say, I agree with him in many points. As a matter of fact, I don’t think it’s only in the JavaScript world (although it might be more evident nowadays) but it’s more or less generalized. It’s all about speed and scale!

Many of us have participated in discussions where an idea is being pitched and, it’s not even a full idea yet,  and people are already focussing on “if it scales”. Or someone ditching some nice abstraction because “this way it will be faster”.  It seems to be a current trend nowadays.

Brian makes (among many others) two points that I think are very interesting:

  1. even if you’re using some kind of abstraction, that does not mean that you can’t make your code more efficient. There are many ways to optimize your code before going into the “bare metal”;
  2. there are very smart people that deal with the “bare metal” daily, and doing a good job at it.

Let me derail a little bit to give an example. In Chapter 3  of his book, Practical Ruby for System Administration, Andre Ben Hamou talks about performance. In that chapter he has a cute little story about a competition between a Ruby and C developers where they aimed at writing some code to perform a task. Bottom line was, although the Ruby code was slower (although having enough performance for that specific job) it took a lot less time to write. He argues there that in order to go to a lower level (like having to resort to C code) there needs to be a very good reason. I couldn’t agree more.

I learnt that lesson the hard way. When I was still in college we had a class on Cryptography, where we had several assignments to do. Some of them involved cracking something and we were evaluated in the following way: first one to crack got 100%; the rest of people got a mark lower and lower depending on how much time they took to crack theirs after the first one (there was some kind of formula). Suffice to say the vast majority of us instead of coding something that would crack it, and leave it running (while we might still be improving our solution) , tried to find a “good solution”. Well, almost everyone gave up on that after the first assignment and it is a good example of what Andre was talking about in his book.

My post might have derailed a little bit from Brian’s original talk, but I think the broader concept is the same: there is so much focus on speed and scale nowadays, that we sometimes forget about maintainability. The war speed vs maintainability is old and will never end. But keep in mind speed sometimes means maintainability.

Think about it: you quickly have to make a fix for a critical bug. The easier it is to fix, the fastest you will make, the happier the client will be.

I encourage you to watch to Brian’s talk and spark some discussion about it.

Advertisements

Why not try Python 3?

So, you’ve been using Python 2 since forever right? Well, Python 2 is still strong but you will, eventually, have to move on. The will be no Python 2.8.

Python 3 is currently on version 3.4.1 and all of  us should at least try it out. Or maybe you want to try some other “Python flavor”, like PyPy for example. Virtualenv will help us.

Sure, you might be working professionally with Python 2 and you still want that to be your default. No worries. If you’re working with Python and not using virtualenv, well… You should use it! Even if you always use the same Python version, you should use it (I will not get tired of saying this). But let’s leave the discussion about using virtualenv for some other time and just accept, for now, that you should use it.

First thing, head to the downloads section and download the latest Python version. I’m writing this on a Mac, so I’ll get the OS X version. After the installation, check, on the command line that Python 3.4 is available:

 $ python3.4 -c “import sys; print(sys.version)”

3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)

[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]

Now we will create a virtual environment that will have Python 3.4 as it’s interpreter. We can achieve that by using the “-p”  parameter. But first, let’s locate the path to of your “new” Python:

$ which python3.4

/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4

Now that we know the path to Python 3.4, we can create our environment:

$ virtualenv -p /Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4 /path/to/the/env

Running virtualenv with interpreter /Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4

Using base prefix ‘/Library/Frameworks/Python.framework/Versions/3.4’

New python executable in /Users/rcastro/.envs/test_python3.4/bin/python3.4

Also creating executable in /Users/rcastro/.envs/test_python3.4/bin/python

Installing setuptools, pip…done.

Let’s activate our new environment and check that Python 3.4 is our default:

$ source ~/.envs/test_python3.4/bin/activate

(test_python3.4)$ python -c “import sys; print (sys.version)”

3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)

[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]

Excellent. This way you can even work with different versions on different projects. Cool, uh?