Humor: Tetris

Jedi apprentice:

I'm thinking about applying to a realtime operating system company. They have a position that requires extensive JavaScript knowledge. I'm thinking about implementing Tetris in JavaScript.

Jedi master:

It'd be better if you wrote a realtime operating system in JavaScript and got it to run on bare metal using V8...but, hey, Tetris is good too.

Python Concurrency Spreadsheet

I'm a fan of Nicholas Piël's Asynchronous Servers in Python blog post. In a similar vein, my buddy Shailen Tuli and I put together the following spreadsheet. Feel free to view it on Google Docs and make corrections.



A few notes:

It is not my goal to use this spreadsheet to pick favorites. Rather, I'm trying to use this spreadsheet to point out differences among the different approaches.

I know very little about DieselWeb, MultiTask, FriendlyFlow, Weightless, Fibra, and Cogen. All I know is that Nicholas Piël's pointed them out as generator-based libraries.

Some of these libraries support multiple approaches at the same time. For instance, Twisted lets you use a mix of callbacks, generators, and threads. Similarly, Tornado lets you use a mix of callbacks and threads. However, it's important to point out the compromises involved. For instance, if you're using Tornado, you can't have 5000 concurrent clients to a WSGI server; instead you have to switch over to the asynchronous callback API.

When I say things like "Can handle 5000 clients?", I don't mean that each of those requests is actively being served. There's only so much CPU to go around! Rather, I mean you can have 5000 clients that are each in various stages of completion, and the server as a whole is mostly waiting on IO.

You can also read my other blog posts Python: Concurrency and Python: Asynchronous Networking APIs and MySQL.

Ruby: Working Around SSL Errors on OS X

Have you ever seen the following error:

SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

Apparently, this is a standard problem for Ruby on OS X. The problem is that Ruby is unable to find the root certificates necessary to verify a given certificate. A typical (and very bad) workaround is to turn off certificate validation using some code that looks something like:

...verify_mode = OpenSSL::SSL::VERIFY_NONE

There's a good blog post called How to Cure Net::HTTP’s Risky Default HTTPS Behavior. It shows you how to force all certificates to be verified, but it doesn't show how to make use of the operating system's most up-to-date list of root certificates.

After reading a ton of different blog posts, this is the approach that I created for my Rails app:

# config/initializers/fix_ssl.rb
# 
# Work around errors that look like:
#
#   SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

require 'open-uri'
require 'net/https'

module Net
  class HTTP
    alias_method :original_use_ssl=, :use_ssl=
    
    def use_ssl=(flag)
      # Ubuntu
      if File.exists?('/etc/ssl/certs')
        self.ca_path = '/etc/ssl/certs'
      
      # MacPorts on OS X
      # You'll need to run: sudo port install curl-ca-bundle
      elsif File.exists?('/opt/local/share/curl/curl-ca-bundle.crt')
        self.ca_file = '/opt/local/share/curl/curl-ca-bundle.crt'
      end

      self.verify_mode = OpenSSL::SSL::VERIFY_PEER
      self.original_use_ssl = flag
    end
  end
end

As the code says, you'll have to execute "sudo port install curl-ca-bundle" on OS X to install the root certificates. Unfortunately, I don't know what the brew version of that is.

Hopefully this will be fixed properly soon.

Google Developer Relations Jobs

I work as a developer advocate at Google. I think it's the most exciting job at the most interesting company in the world, but of course I'm biased ;) In fact, when I came to Google, it turned out to be roughly twice as good as I was hoping it would be. We have a bunch of openings right now. If you're both a hardcore coder as well as a hardcore extrovert, you should think about applying (through me, of course!).

By the way, the interview process is somewhat challenging. You should definitely plan on spending some time in front of a whiteboard. I heartily recommend two books, Cracking the Coding Interview and RESTful Web Services.

The video below is from Google Developer Day 2011, Moscow. Not everyone has to go to Moscow, but I think it conveys part of why I find this job so much fun :)



By the way, we also have other positions within developer relations as well as within Google as a whole.