Python virtual environments are a fantastic method of insulating your projects from each other, allowing each project to have different versions of their requirements.
They work (at a very high level) by making a lightweight copy of the system Python, which symlinks back to the real thing whenever necessary. You can then install whatever you want in
lib/pythonX.Y/site-packages (e.g. via
pip), and you are good to go.
Depending on what provides your source Python, however, upgrading it can break things. For example, I use Homebrew, which (under the hood) stores everything it builds in versioned directories:
$ readlink $(which python) ../Cellar/python/2.7.8_2/bin/python
Whenever there even a minor change to this Python, symlinks back to that versioned directory may not work anymore, which breaks my virtual environments:
$ python dyld: Library not loaded: @executable_path/../.Python Referenced from: /Users/mikeboers/Documents/Flask-Images/venv/bin/python Reason: image not found Trace/BPT trap: 5
There is an easy fix: manually remove the links back to the old Python, and rebuild the virtual environment.
Nearly two years ago, GitHub introduced contribution calendars on everyone's profile, which roughly visualize how frequently one has been "contributing" for the past year. Through 2013, mine displayed some interesting patterns and features, many of which scream that they have a story:
Having used GitHub as the primary code host for multiple full-time jobs, and a few growing open-source projects, I now believe that these calendars introduce, for me, two negative effects that vastly outweigh their benefits.
I have been having trouble receiving email from Gmail via IMAP today. The Google Apps status dashboard does not reveal anything is wrong, so lets go spelunking!
openssl to make the connection to transparently handle the TLS connection:
$ openssl s_client -crlf -connect imap.gmail.com:993 * OK Gimap ready for requests from 22.214.171.124 zh1mb199258645pbc
We have a connection! The
-crlf is critical for Gmail as the line endings are important to the "Gimap" server (and the protocol in general, but other servers I have tested are more accepting). If you weren't using encryption, you would
nc imap.gmail.com 143 instead of using OpenSSL.
Lets poke the server a little.
I've been building a VFX pipeline for Shadows in the Grass that allows for artists to work in whatever applications they are the most skilled.
One little thing which has been a bit annoying is that somewhere between Blender and Houdini (of all pairings), geometry transferred via Collada does not have properly qualified normals. This results in some wacky behaviour when you start transforming your models:
Note that when spinning the above sphere, the normals are getting dragged along with the surface, but they remain pointing in the same direction in world space; they are not spinning with the surface. A very obvious effect of this is that the light appears to be spinning around the sphere, even though the light is stationary.
There is a simple enough fix, however.
I've been provisioning a pile of tiny VPSes (from Digital Ocean) for tiny web services for the last few weeks. While tuning one such site, I made an incorrect assumption that caused MySQL to fall over: Digital Ocean boxes default to having no swap space.
Assuming you want a little bit of leeway in your memory limits, it is easy to add some swap:
# Create a 1GB blank disk image. dd if=/dev/zero of=/var/swap.img bs=1M count=1024 # Activate it as swap space. mkswap /var/swap.img swapon /var/swap.img # Set it to activate at startup. echo "/var/swap.img none swap sw 0 0" >> /etc/fstab