I’m writing some software that interfaces with the GPIOs on a Raspberry Pi. I found myself wanting to test this software on my Mac while I was developing it, meaning I’d need to make “mock GPIO files” to test against. The trick was that I needed something I could send to
select(2) and signal an “exceptional condition,” since that’s how Linux indicates an interrupt on a GPIO. This ended up being an education for me on both TCP out-of-band data and, surprisingly, pseudo terminals.
Often enough, in Python, I find myself wanting to do something with a key’s value in a dictionary, but only if the key exists. I think that the most obvious way to write this is:
if key in some_dict:
However, I always thought looking up the key in the dictionary twice was wasteful. Instead I preferred to write the following code, which remains readable but does only a single dictionary look up:
value = some_dict.get(key)
if value is not None:
Surely one dictionary look up is faster than two!
Unfortunately I think my assumption was wrong.
When it comes to dealing with dates and times in Python, my first choice is the standard library’s
datetime module. However, while
datetime supports time zones in general, it has no knowledge of any specific time zones. It lacks a time zone database, information about all the world’s time zones past and present. PEP 431 would add such a database to the standard library, but it seems to be stalled.
I am aware of two libraries you can use when you need time zone information in Python,
pytz seems to be the most popular time zone library by far. However,
dateutil has the same time zone information and a lot of other useful date and time functionality besides. Is there any reason to use
dateutil seems to be a superset of
As it turns out, yes, there is at least one good reason to prefer
Jekyll has the ability to use latent semantic indexing (LSI) to determine related posts within your blog. I wanted that same functionality in Middleman, so I wrote an extension for Middleman, middleman-related-articles. I don’t have enough posts for it to make any difference for me right now, but I’ll be interested in seeing how it behaves as this blog grows. I’m also really interested in feedback from any other users. After I get a little more confidence using this extension myself (and maybe after this issue in rb-gsl gets resolved) I’ll probably try and advertise it a bit to Middleman users.
This blog is made with Middleman, but I tried out three other static blog generators before I settled on Middleman: Pelican, Jekyll, and Octopress.
Once I decided I wanted to make a static blog, Jekyll was the first software I thought of. However, I then considered that if I wanted to extend whatever package I was using, I might be better off with something written in a language I was familiar with, so I started with Pelican instead, which is written in Python. After a few hours of reading the documentation and playing with it, I found two problems with Pelican that put me off it.
When I wanted to build a static blog I tried Jekyll first. I think that was a marketing accomplishment for its author(s). Thanks to all the buzz that it received following its release in late 2008, Jekyll is the first software I think of when I think of “static blogging.” Its popularity was probably boosted thanks to both GitHub’s support for Jekyll in GitHub Pages as well as a spate of WordPress vulnerabilities.
I acknowledge that Jekyll was far from the first “static site generator” or even “static blog generator.” Consider, for example, Blosxom which was around at least by 2002, or nanoc which was first released in 2007. Nonetheless, thanks to all the buzz around Jekyll, it became my prototype for “static blogging.” It then took me until 2014 to get around to taking it for a spin, and eventually rejecting it.