As the Physics webmaster, I'm in charge of transitioning most of the static department content into SiteCore, as the powers that be get wise to the ways of version control. Unfortunately, I'm not the biggest fan of SiteCore. Major gripes include:

• Poorly conceived versioning. Some things are versioned, some things aren't. No tools (that I've found yet) for analyzing history except on a per-page scope. Also, can only commit changes at the page level, which makes a single "I added alt tags to all my images" commit impossible.
• Browser-only interface. That's right, no scriptable API short of driving a browser through a script. This one is so huge, I'm not really sure what else to say. Surely people occasionaly want to do something that the designers hadn't planned for, like, oh, importing data from a preexisting database.

Anyhow, to overcome the major limitation, I'm driving my browser through a script. Thanks to the magic of WebDriver/Selenium for making this possible.

]]>

Recently I've been writing up an article for one of the Elsevier journals using their elsarticle LaTeX package. Unfortunately, their BibTeX style file, elsarticle-num.bst (version 1.1, 2008-10-13), is a bit broken. With the help of Nicolas Markey's excellent Tame the BeaST, I've fixed it up, so it runs without errors (!), works with natbib's \citet{}, and conforms with the examples posted in the International Journal of Biological Macromolecules' author guide.

Update: Oct. 6. Turns out the code linked from Elsevier is out of date. Rishi over at River-Valley (writers of the elsarticle package) pointed me to some more up to date documentation and source. Version 1.2 fixes most of my problems (with elsarticle-num-names.bst), but I'm still not sure why it doesn't replace elsarticle-num.bst entirely...

]]>

I just discovered inotify and it's command-line incarnation inotifywait (in inotify-tools on Debian). Now I can watch the data come in from home. If only I had the laser- and photodiode-alignment screws motorized... Anyhow, checkout my script.

]]>

I've been scripting up a few things recently and my inability to send nicely formatted PGP/MIME messages was starting to really bug me. I had been encrypting my logwatch output with gpg and just emailing the raw gpg out to myself, but it's annoying to have to ESC-P every time I want to decrypt a log. The tipping point came while I was writing up a script to automatically email grades out to my students (not that any of the student's care about PGP, but it's the principle of the thing ;), since there's no way I'm going to send them raw gpg output (they would die) and there's also no way I'm going to hold Mutt's hand while it signs the emails. I dunno why Mutt doesn't have some --batch mode options to support PGP, but there it is.

So I wrote my own. Not very complicated really, just implementing the RFC 3156 specs. There's obviously room for improvement, but it works well enough to make me happy at the momemt. You're welcome to take a look and email me with [encrypted!] feedback.

]]>

Ah, it has been a while, but I am excited about a new python module I wrote so I shall post again ;). Actually, there has been a lot of Python learning over the past two months. It started out when I felt the need to setup a bug-tracker to keep track of all the things going wrong with my cantilever calibration software :p. Since I'm using git for versioning, I naturally wanted a 'distributed bugtracker'. Luckily there are a number of nice ones out there. I've been using Bugs Everywhere. My other favorite is Ditz, but I like being able to hack away on BE in my familiar Python.

Besides helping keep track of my bugs, I've enjoyed hacking away at BE. In the process I've learned some cool tricks such as Python decorators (see this tutorial for some really neat examples) and Bash autocompletion.

Meanwhile, the calibration code developed, and I was getting tired of keeping assorted keyword arguments default in sync (how many times do I have to repeat minFreq=500?). The way to avoid repeating yourself in this situation is to use *args or **kwargs (see wxPython's endorsement). I don't trust myself to keep my code in sync enough to use args, so lets focus on *kwargs. Consider the following example:

>>> def A(a=1):
...     return a
>>> def B(b=2):
...     return b
>>> def C(**kwargs):
...     return A(**kwargs)+B(**kwargs)
>>> C(a=3,b=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in C
TypeError: A() got an unexpected keyword argument 'b'

Hmm, how to split the kwargs into those for A and those for B? So I wrote the splittable_kwargs module. See the docstrings for some usage examples and more info. With my module the above example becomes

>>> from splittable_kwargs import splittableKwargsFunction
>>> @splittableKwargsFunction()
... def A(a=1):
...     return a
>>> @splittableKwargsFunction()
... def B(b=2):
...     return b
>>> @splittableKwargsFunction(A,B)
>>> def C(**kwargs):
...     akw,bkw = C._splitargs(C, kwargs)
...     return A(**bkw)+B(**akw)
>>> C(a=3,b=4)
7

In other news, my current side project is a MySQL-based, multi-user, archiving, command-line grade database. Down with web-forms ;). More information to come as the project progresses.

]]>