Dict Diff and Test Driven Development

I recently wrote a short function called dict_diff() that would take two dicts, compare them, and return another two dicts that contain only the differences between the original dicts (the code is available as a gist). It works something like:

dict_diff(
    {'a': {'ab': 12}, 'b': {'ba': 21, 'bb': 22}, 'c': {'cc': 33}},
    {'a': {}, 'b': {'ba': 21, 'bc': 23}, 'c': {'cc': 33}},
)

# outputs: (
#    {'a': {'ab': 12}, 'b': {'bb': 22}},
#    {'b': {'bc': 23}}
# )

I wrote it to make the output of assertEqual() a lot easier to read when dealing with large dicts that are not equal. It is a recursive function, but other than that it is fairly simple and nothing very special. What is different is that I wrote the function using test-driven development (TDD).

Generally when writing recursive functions I tend to get a bit caught up trying to ensure that the recursive part of the function works correctly from the beginning and lose sight of what the function is actually supposed to be doing. By knowing what the expected output would be ahead of time I was able to take a test-driven development approach and write the test cases beforehand, then just work my way through making all of the tests pass. By starting with the simple tests first and working my way through to the more complex ones it meant everything just fell into place and I didn't have to worry if I broke anything when I introduced the recursive stuff.

In the past I have tended to just write the tests in tandem with the code (sometimes before, sometimes after) and not really put a lot of thought into planning it all out with test cases. Being a simple function I knew what most of the results should be ahead of time without having to put much thought into it, but it was valuable to see how well this approach worked. I think I'll try to spend more time planning out my test cases to drive my development in the future.

New Blog

I have finally set up my new blog after many months of thinking about doing it.

Ever since I first heard about using static site generators for blogs the idea appealed to me. By their nature the content of blogs do not need to be generated dynamically so using static html pages means a lower resource overhead than using something with a database backend. Another bonus is that I no longer have to worry about keeping on top of the upgrade/patch cycle to fix security issues that comes with using something like Wordpress.

I was mainly looking for a static site generator written in Python so that if I ever wanted to make any modifications, I would be working with a programming language I enjoy. The two main ones I came across that were actively being developed (with releases) were Nikola and Pelican. I eventually chose Pelican over Nikola because all of its dependencies were pure python libraries, making it easier to set up in a virtualenv.

I have also been meaning to have a play with Bootstrap for a very long time, so I took the opportunity to play around with it over the last few days and have come up with a simple Pelican theme called bootstrap-jerrykan. I am pretty happy with the result.

So, here is my new blog.

Environment Variables of a Running Process

When creating init scripts or trying to debug services on Linux it can be handy to know what the environment variables are for a running process. It turns out that you can retrieve these variables from /proc (along with lots of other rather useful information). The environment variables are located in /proc/$PID/environ where $PID is the ID of the process we are interested in.

cat can be used to print out the environment variables, but the entries are separated by null characters which makes them a bit difficult to read. To view the entries in a slightly more legible form we can pipe the output through tr to replace the null characters with new line characters:

cat /proc/$PID/environ | tr '\000' '\n'

References: