Taverner Choir (Andrew Parrott, Conductor) – Arvo Pärt, John Tavener – Out Of The Night – 01 – Pärt – Magnificat

(from Robert Hodgin)

As the reference, this was not a good experience. The first obnoxious thing they do is send an email as if they are the candidate. They didn’t tell the candidate they were doing so, but they used his name in the from field, and signed his name at the bottom. Nowhere in the missive does it mention that the email is automatically generated by a third party. The email itself even included the ancient and outdated “if you’re using AOL, copy and paste this link…” line. If you don’t respond within precisely 23 hours of the first email, the system sends an automated followup (pretending to be a reply from the job candidate) bugging you to fill it out.

Clicking through the link takes you to a set of basic information about your relationship with the candidate with one key field you must fill out: your area of expertise. More on this in a moment. Once you get to the actual survey, it turns out to be a set of 23 pretty generic “does this person do the job and play well with others” type questions. Then it asks you to specifically name the reference’s weaknesses (a fair question, certainly), but tries to sugar coat it by saying “We all realize that no one’s perfect; in fact, we find that the majority of references provide helpful information in this section.” Huh? So since the information is going to be helpful, you’re hoping to get more negative feedback than I would otherwise give?

Then we get to the really obnoxious part: The tiny non-obvious opt-out checkbox. If you don’t opt-out, you (as the non-job-seeking reference) get added to their “Passive Candidate Compiler™”, which does pretty much what you expect: build a database of people who haven’t otherwise indicated an interest in new positions who can be spammed at the drop of a hat. Furthermore, since you have been given ZERO information about what company is hiring your co-worker, you don’t know whether you want to allow them to keep your contact info.

I’m sure skillsurvey.com is cheaper than hiring a real person to call these references. I don’t know if it actually provides better information. But from the receiving end, it’s not a good experience. Don’t be lazy. Call the references directly. If you must use an automated pre-screening system like this, at least use one that doesn’t play these silly games. Using this service negatively impacts your image.

I was working with the Redi-Pak product from redimat.com.

I’ve got a Canon Pixma Pro 9000 II that has a flat-feed for printing on sheets up to 1.2mm thick. The mats are spec’d for .04 to .06 inches (1.0 to 1.5mm) thick, which seemed like it would probably work.

The first thing was to figure out how to operate the flat feed mechanism. Thanks to a helpful post over at imaging-resource.com, I got that figured out. The tricky bit is closing the front paper tray most of the way, lifting it up, and then deploying it back down from the higher pivot point. This sets the tray up so that it is level with the rollers, and you feed your work in backwards from normal print direction.

The second problem was that the printer absolutely positively refuses to print on anything with a hole in it. It has some kind of detection mechanism (probably part of the paper feed/misfeed sensing system) that throws an error if you just naively feed through a mat with a window. Taping a sheet of paper over the hole didn’t fix the problem, so I think it must be a pressure sensor in the feed rollers rather than an optical sensor. I ended up cutting a custom-sized piece of matting that fit into the hole, and held it in with tape.

The final problem involved smudging. For whatever reason, the printheads would sometimes brush against the unprinted area and smudge the clean mat. Setting the printer driver for printing on thick media helped, and I solved the problem (for the most part) by putting a sheet of paper over the area that tended to smudge.

The technique is relatively labor intensive (each mat has to be fed individually, bringing back memories of burning hundreds of CDs on a slow burner), so it is probably unsuited to mass-production. In bulk, printing on a small area, each print took around 4 minutes. Overall, I was pretty happy with the results. Printing on the mat allows a customization of the final product that doesn’t obscure the actual image. This technique could be used to print on the backing board as well, with details like photographer, contact info, date, location, etc. Doing that would be much nicer than the more typical sticker.

I’ll try and remember to post pictures later.

I entered my usual id. They told me to use a https url (guys, http auth can be encrypted – don’t judge my endpoint, or the URL from which I delegate). I went and found the google OpenID url (https://www.google.com/accounts/o8/id), and was told it wasn’t an OpenID 2.0 url. I went and found the OTHER one (the same URL as my google profile). This FINALLY prompted a message that informed me that they didn’t, in fact, support any providers other than this very short list:

• pip.verisignlabs.com
• openid.trustbearer.com
• myopenid.com
• myvidoop.com

Really? you support myvidoop.com and verisign’s beta implementation, but not Google? Good going, Microsoft. If the supported list is that short, you should just show provider logos and forgo the “enter url” box. At the very least, show me that list BEFORE I try to log in.

I don’t really want a Live account. It appears I need one to use the service with which my health provider has chosen to partner. Bother.

#!/bin/sh
rm -v django/utils/unittest/*.py*
wget http://hg.python.org/unittest2/archive/tip.tar.gz -O unittest2.tar.gz
tar --wildcards --no-wildcards-match-slash --strip-components=2 --directory=django/utils/unittest -xf unittest2.tar.gz unittest2-*/unittest2/*.py
rm -v unittest2.tar.gz
sed -i 's/^from unittest2/from django\.utils\.unittest/' django/utils/unittest/*.py
echo "unittest2 updated"

Run it from the root of the svn checkout.

If you have a models file like this (artificial, but play along):

from django.db import models
from random import random
rand_val = random()

class MyModel(models.Model):
    r = rand_val

After you import MyModel in some other module, you can’t re-load the class definition of MyModel.

You might think that calling reload() on models would do the trick. What actually happens is:

• models.py is reloaded (the file is executed again)
• so models.rand_value changes…
• but models.MyModel.r does not!

Classes that inherit from models.Model seem to be immortal singletons. I tried removing them from sys.modules as arthurk is doing. I tried deleting all references to the variables in my code. The first instance came back every time, even though python was shown to be reloading the module and re-executing the code within.

In most use cases, this is exactly what you want. It usually would be inefficient to have multiple copies of MyModel available in different parts of your code.

Unfortunately, I needed multiple instances for testing purposes. I ended up settling for a less comprehensive testing solution.

I’ve never had any trouble like this with my mail service before. Don’t use Ontrac.

I spent a bunch of time setting up and configuring VMs with test environments. I can now test in Ubuntu, OS X, Windows, and have a couple of configurations for each of those. I don’t have every possible supported combo, but it’s a good start. I spent more time than I should have messing with virtualenv. I still don’t have automated scripts to do everything I need, but I’m not going to invest more time in that right now.

I also spent a while becoming acquainted with the details of how tests are actually run. I’ve done some modification of the test runner to fix some of the hard-coded paths, but it’s still not working the way I want it to. I think that in the end, the right thing to do is probably to leave the existing test infrastructure as-is, and then move everything to the new consolidated single test directory at the end of the project, after the tests are cleaned up and moved to unittests. The alternative is to move them one at a time as I get them cleaned up, but then we’ll have to have some interm test running code that checks both options. I think it’s probably best to leave my branch as close to trunk as possible so that patches can go back and forth as improvements are made.

I need to update the documentation on contributing to include a note that new patches should use unittests not doctests.

So in summary – not a lot of committed code, but a bunch of work that should make things more productive for next week.