Some time ago, I wrote up my data protection strategy. I’m no longer using most of what I describe in that article for two reasons:

• For various reasons, we are now using Windows as our primary laptop computing platform.
• Backing up to an external hard drive is not robust against ransomware such as CryptoLocker that encrypts your files and holds them hostage until you pay the criminal or organization deploying the attack.

This second point is particularly important: in addition general practices to keep from running ransomware (or other malicious software) in the first place, the best protection against CryptoLocker-style attacks is a good backup strategy where the backups are kept out of reach of the backed-up system. These attacks typically try to encrypt all the data files they can find, including on external drives and network shares, so if your backups are stored on such a drive they’ll be scrambled too.

However, if you have good backups out of reach of your computer, and you get hit, you can recover relatively easily: reset the computer from install media, restore data from backups, and go on your merry way. Being careful, of course, to avoid opening potentially-malicious files, as it’s quite possible that the infection arrived through some document that is saved in your backups.

This week, Michael Ludwig and I had a paper published that we’ve been working on for quite some time. ‘Dependency Injection with Static Analysis and Context-Aware Policy’, describing our Grapht dependency injector, has been published in the Journal of Object Technology.

We wrote Grapht to support algorithm configuration in LensKit, our open-source recommender systems toolkit. We didn’t want to write a new dependency injection framework; initially, we built LensKit on top of Guice, and then migrated to PicoContainer when Guice wasn’t a good fit for our needs. But PicoContainer also made it difficult to implement the kind of configuration support we wanted to provide, so we finally broke down and wrote our own.

Grapht provides two major advantages over existing injectors:

• It pre-computes component graphs before instantiating any objects. These graphs can then be analyzed and manipulated to implement whatever diagnostics, visualization, or configuration transformation an application desires. In LensKit, we use this to generate graphs of recommender configurations and to automatically separate pre-computable model components from those that must be instantiated at runtime.

• It supports context-sensitive policy, making it far easier to configure object graphs that include arbitrary compositions and re-use of components. This is important in LensKit, because it allows us to create simple components and remix them in arbitrary ways to implement the full recommender.

This fall, I’m teaching CS 3320, Internet Software Development. The class hasn’t been offered for a while, and students seem quite excited to take it (it’s currently maxed out with a full waitlist).

Since this is the first time in a while that this class has run, I’m recreating it from scratch. You can check out the course web site here, including the syllabus and list of resources; I expect that I’ll also be publishing assignments and lecture notes there as the semester progresses.

One of the big tasks in getting this ready has been selecting a tech stack. There’s just so many to choose from! Three primary goals have driven my decisions:

• Provide students with a full-stack experience, from storing data on the back end to interactive JavaScript and AJAX.
• Minimize the number of distinct technologies, particularly languages, that students have to learn in order to gain this experience.
• Don’t layer too much magic on top of the underlying infrastructure (e.g. HTTP and HTML), so that students can gain a good conceptual understanding of how things work.

I made some chili. People generally liked it, and were interested in the recipe, so here it is.

Derived from a recipe on Oh She Glows, in turn adapted from Maintenance with Ashley.

The spices are pretty flexible.

• 1 tbsp oil
• 2 cloves garlic, minced (or just some minced garlic)
• 1 orange bell pepper, chopped
• 1 poblano pepper, chopped
• 1 sweet onion, chopped
• 1 shallot, chopped
• Some chopped carrot
• Cumin
• Chili powder (lots of it)
• Salt
• Dash of cayenne
• Some Mexican oregano
• Grains of Paradise
• Beans — more on this below
• 1 large but not industrial can diced tomatoes with juice
• 2–3 baby bella mushrooms, cut up
• 1 tbsp unsweetened cocoa powder
• Squirt of lime juice
• 1C vegetable stock

Mercurial has a useful command, hg summary, that prints out some basic information about your current repository status. git status prints most of this information, but omits some useful details such as the ID and message of the most recent commit.

The following shell script will fix this, printing the current commit followed by the output of git status:

#!/bin/sh

HEAD_REV=`git rev-parse --short HEAD 2>/dev/null`
if [ "$?" -ne 0 ]; then
    exec git status
fi
HEAD_MSG=`git show -s --format=%s HEAD`

echo "Parent revision is $HEAD_REV: $HEAD_MSG"
exec git status

Save this script somewhere on your $PATH as git-summary (~/bin is a good option). If you are on Windows, save it in a file called git-summary in the usr\bin subdirectory of your Git installation (often C:\Program Files\Git). Then you can run git summary to see this augmented display: