In case you're not familiar with PyPy yet, it's a Python interpreter with JIT compiler.

PyPy has many advantages. It can run Python code faster then any existing interpreter, has a lower memory footprint then CPython, it allows you to choose the right level of language abstraction for your code depending on how fast you need it to be since it supports running Python, RPython and allows you to provide C and C++ extensions and It's 99% compatible with CPython.

One of the major differences and what makes PyPy adoption a non-trivial process is the why PyPy interfaces with CPython extensions. If you're interfacing with C code you need to ensure that you use the right bindings.

CPython extensions use Python's C API which PyPy does not have. PyPy can run some CPython extensions using cpyext but those extensions will run slower on PyPy due to the need to emulate reference counting. That also means that Cython generated extensions will be slower.

PyPy on the other hand has support for the not very commonly used ctypes and CFFI which can be run on both interpreters. CFFI runs much faster on PyPy than ctypes so if you're targeting PyPy it's better to use it. I was told that CFFI has been known to be a bit slower than C extensions on CPython because it does not access the C API directly but it wraps it. I could not find evidence for that claim although it makes sense.

If you're interfacing with C++ code, there has been a discussion to port boost::python to PyPy but I don't think it has been done yet.

PyPy provides cppyy which is written in CPython and thus able to JIT out most of the binding related code. cppyy has multiple backends it can use. In this post I'm going to cover Reflex since it's the default and it is currently the most stable backend.

In this post I'm going to demonstrate how to run Protobuf 2.5.1 on PyPy. Protobuf's compiler generates Python code which relies on a CPython extension in order to interface with the Protobuf implementation and is I mentioned before this is not going to be as fast as it should be for PyPy. Google provides a pure python implementation of Protobuf in version 3.0 which is not yet release and breaks compatibility in some aspects from Protobuf 2.x.

If you've ever developed an open source project on Github you probably have heard about coveralls.io already but you, like me until recently are probably not measuring code coverage accurately enough if you have multiple testsuites (e.g.. unit, functional, integration).

We like package managers. They help us maintain our dependencies easily.

Vagrant has a package manager for it's plugins which make them very easy to install, upgrade or remove but before Vagrant Plugin Bundler we had no way to ensure our Vagrantfile is using the right version of each plugin.

I'm learning how to use Salt Stack so I started a new project that provisions a baseline Vagrant Box for Python development.

I wanted to check that my vagrant box can be provisioned & packaged every single time for every single change I committed into the repository so I created a .travis.yml configuration file in order to do so.

That attempt has failed unfortunately. Read this post to understand why.

Hooks
are scripts that help you enforce policies on your repository by
triggering scripts at certain events that enforce policies such as 'The
commit message must be longer than 20 characters' or 'The test suite
must be run before a commit and if it fails, reject the commit'.

Hooks are available in every VCS I have used before. They are also available in Visual Sourcesafe which is not a VCS.

Last time we talked about selecting and installing the OS.
I have referred you to resources about preseeding and Kickstart in
order for you to have a better grasp about unattended installations.
You've probably attempted (and even succeeded) to perform one already.
In this post I am going to further elaborate on how to improve the
installation and configuration process of a new development machine.

Whenever a new developer arrives to the team he and/or the IT department
usually spends some time on setting up their development workstation.
This time is wasted as the man-hours spent on setting up a new
workstation could have been spent on creating a better product (aka
adding value).