Consider South's orm object, http://south.readthedocs.org/en/latest/ormfreezing.html, which provides "frozen-in-time" versions of ORM models:

(Pdb++) from my_app.models import MyModel
(Pdb++) MyModel
<class 'my_app.models.MyModel'>
(Pdb++) orm['my_app.MyModel']
<class 'my_app.models.MyModel'>
(Pdb++) orm['my_app.MyModel'] == MyModel
False

Notice that the magic South frozen model appears to be in the same namespace as my real model: my_app.models!

This is at best stupid, and at worst potentially dangerous.

It makes perfect sense that South needs some mechanism for providing "frozen models" (ie, which match the database schema at the time of migration, of the current schema), but they are emphatically not the same as the real models (don't have any of the real methods, etc), so it should be made very clear that they are different! There are many ways this could be done, but one very simple step would be putting them in a different namespace, which makes it clear that these models are frozen, and references the migrations they belong to:

(Pdb++) orm['my_app.MyModel']
<class 'south.frozen_models.my_app.models_0003.MyModel'>

Additionally, this is a bad code smell which could potentially lead to bugs: because the "frozen model class" is lying about where it's from, any code which relies on the module path will do surprising things. In fact, it's such a big problem that pickle explicitly checks for this case:

(Pdb++) import pickle
(Pdb++) pickle.dumps(orm['my_app.MyModel'])
*** PicklingError: Can't pickle <class 'my_app.models.MyModel'>:
    it's not the same object as my_app.models.MyModel

To deploy my application, I use a collection of bash scripts known lovingly as explode. At its core, explode uses rsync to copy my source tree exactly as it appears on my laptop up to the production server:

project="myproject"
src_dir="~/code/myproject"
target_dir="~/myproject-deploy"

ssh "$server" "
    /etc/init.d/$project stop;
    cd $target_dir;
    git commit -am 'pre-deploy commit';
"
rsync "$src_dir/" "$server:$target_dir/code/"
ssh "$server" "
    cd $target_dir;
    git commit -am 'post-deploy commit';
    /etc/init.d/$project start;
"

Now, at this point you're probably thinking:

• Doesn't that mean that your deploy could contain files which aren't in source control?
• What if you forget to pull before you deploy?

And those are definitely real problems.

But I've found that the popular alternative, deploying from the project's source control repository, has two significant drawbacks when deployments to environments other than production (staging, testing, demos, etc) are considered:

• Pushing quick, experimental changes is annoying when a full commit to source control is required. You can often tell when a project deploys from source control because the commit log will contain clusters of commits with messages like "trying foo", "nope, that didn't work, trying bar", ... etc.
• If the deploy script doesn't verify that there are no uncommitted changes to the local source code before deploying, the deployed code will be different from the local code... And if it does, it can make quick deploys frustrating.

Obviously these are not insurmountable problems, but I've found it easier to base my deployments on rsync and add sanity checks around production deployments ("working tree contains uncommitted changes... are you sure you want to deploy?") than it is to base my deployments on source control and add workarounds for deployments to non-production environments.

Now, to be clear: deplying with rsync isn't the be-all-and-end-all... It definitely has problems: rsyncing a source tree is significantly (significantly!) slower than a git push, and it's no where near as reproduceable as pulling from master. But it works well for me :)

Oh, and the git commit that's part of the deployment? While not necessarily related to rsync, I think it's worth mentioning too: the deployment's git repository contains the entire environment, including the Pyhton virtual environment! So if, for just about any reason, a deploy fails, git checkout HEAD^ will restore the deployment to a working state (the repository doesn't contain logs, the database, user data, though... As much fun as that would be, it would also be slightly impartial).

tl;dr: rsync makes it super easy to deploy to non-production environments, and deploying to production can be reasonably safe if a few sanity checks are performed.

An anti-pattern I've often seen is using try/except incorrectly in an attempt at duck typing:

try:
    widget.frob()
except AttibuteError:
    # widget can't be frobbed
    do_something_else()

This is fundamentally broken because it will conceal bugs in the widget.frob() method (ie, if there's a bug in widget.frob() which causes an AttibuteError to be raised).

In this situation, the only safe way to use try/except would be:

try:
    widget_frob = widget.frob
except AttibuteError:
    # widget can't be frobbed
    do_something_else()
else:
    widget_frob()

This ensures that bugs in widget.frob() won't be accidentally hidden.

Of course, this code is no where near as pretty as the "incorrect" version, which is why I've come to believe that using try/except for duck typing could be considered an anti-pattern, and that hasattr is generally preferable (except in situations where performance is important, as try/except will almost certainly be faster):

if hasattr(widget, "frob"):
    widget.frob()
else:
    # widget can't be frobbed
    do_something_else()

And of course, all this goes without saying that a naked except: is always an absolutely terrible idea...

In yesterday's post looking at MintChip's hosted API's crypto, I noticed that MintChip's certificate authority does not have any name constraints. This was surprising, because this seemed like a simple and obvious issue with an otherwise well designed system... But after some experimentation, it seems that OpenSSL simply ignores nameConstraints, so they would be mostly worthless even if they were used.

$ openssl req -new -x509 -keyout trusted_ca.pem -out trusted_ca.pem -nodes
...
Organizational Unit Name (eg, section) []: New Trusted Authority
...
$ ./add_name_constraints.py trusted_ca.pem mintchip_ca.crt > mintchip_with_constraints.crt
$ openssl x509 -noout -text -in mintchip_with_constraints.crt
Data:
    ...
    Issuer: OU=New Trusted Authority
    Subject: CN=Remote MintChip Certificate Authority, OU=Remote MintChip, O=Royal Canadian Mint, C=CA
    ...
    X509v3 extensions:
        ...
        X509v3 Name Constraints: critical
            Permitted:
              DNS:does_not_exist.com

$ cat trusted_ca.pem mintchip_with_constraints.crt > ca_list.crt
$ openssl s_client -CAfile ca_list.crt -connect remote.mintchipchallenge.com:443
CONNECTED(00000003)
depth=2 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=New Trusted Authority
verify return:1
depth=1 /CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
verify return:1
depth=0 /CN=remote.mintchipchallenge.com/OU=Remote MintChip Server/O=Royal Canadian Mint/C=CA
verify return:1
...
SSL-Session:
    ...
    Verify return code: 0 (ok)
---

$ openssl s_client -CAfile mintchip_with_constraints.crt \
    -connect remote.mintchipchallenge.com:443
CONNECTED(00000003)
depth=1 /CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
verify error:num=2:unable to get issuer certificate
issuer= /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=New Trusted Authority
verify return:0
...
SSL-Session:
    ...
    Verify return code: 2 (unable to get issuer certificate)
---

$ openssl req -new -x509 -nodes -config name_constraints_on_dirNames.cfg \
>   -out dirName_constraints.crt
...
$ ./add_name_constraints.py trusted_ca.pem mintchip_ca.crt \
>   dirName_constraint.crt > mintchip_with_dirName_constraints.crt
...
$ openssl x509 -noout -text -in mintchip_with_dirName_constraints.crt
Certificate:
    ...
    X509v3 extensions:
        ...
        X509v3 Name Constraints: critical
            Permitted:
              DirName: CN = bad_common_name

$ cat trusted_ca.pem mintchip_with_dirName_constraints.crt \
>   > ca_list_with_dirName_constraints.crt
$ openssl s_client -CAfile ca_list_with_dirName_constraints.crt \
>   -connect remote.mintchipchallenge.com:443
CONNECTED(00000003)
depth=2 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=New Trusted Authority
verify return:1
depth=1 /CN=Remote MintChip Certificate Authority/OU=Remote MintChip/O=Royal Canadian Mint/C=CA
verify return:1
depth=0 /CN=remote.mintchipchallenge.com/OU=Remote MintChip Server/O=Royal Canadian Mint/C=CA
verify return:1
...
SSL-Session:
    ...
    Verify return code: 0 (ok)
---