EditorConfig defines coding conventions for groups of files and instructs text editors to adhere to these conventions. To solve my problem, I just create a file called .editorconfig that sets indentation for my files and with my EditorConfig plugin installed Vim takes care of the rest. Here’s an example .editorconfig file I could add to my project that uses jQuery expander and jQuery pagination:

1
2
3
4
5
6
7
8
9
10
11

[*.js]
indent_style = space
indent_size = 4

[jquery.expander.js]
indent_style = space
indent_size = 2

[jquery.pagination.js]
indent_style = tab
indent_size = 4

With this .editorconfig file, all JavaScript files use 4 spaces for indentation except for jquery.expander.js which uses 2 spaces and jquery.pagination.js which uses hard tabs with a column width of 4. If I put my .editorconfig file under version control, other developers working on my project can see the coding conventions I defined and if their text editor has an EditorConfig plugin installed their editor will automatically use the correct indentation as well.

Example EditorConfig files can be seen in my own projects (such as in my dotfiles repo) and in the various EditorConfig plugin codebases. More information on EditorConfig can be found at the EditorConfig website.

EditorConfig plugins are available for 6 different editors now. If you like the idea, try out EditorConfig for your favorite editor and tell us what you think. If you don’t like the idea or have a problem with EditorConfig please submit an issue, add a thread to the mailing list, or send me an email voicing your concern.

Generating an authors file

Subversion denotes authors by usernames while Git uses name and email. An authors file can be used to map subversion usernames to Git authors when creating the Git repository, like so:

git-svn clone --stdlayout --authors-file=authors.txt http://your/svn/repo/url

The trickest part about making an authors file was finding all the authors. I found this command useful for finding usernames of all Subversion committers:

svn log | awk '($0 ~ /^r/) {print $3}' | sort -u

A similar method of creating an authors file is presented here.

Removing git-svn-id messages

When migrating from Subversion, every commit messages has a git-svn-id line appended to it like this one:

git-svn-id: http://svn/repo/url/trunk@9837 1eab27b1-3bc6-4acd-4026-59d9a2a3569e

If you are planning on migrating away from your old Subversion repository entirely, there’s no need to keep these. The following command (taken from the git filter-branch man page) removes these git-svn-id lines from all commit messages in the current branch:

git filter-branch -f --msg-filter 'sed -e "/git-svn-id:/d"'

Removing empty commit messages

Subversion allows empty commit messages, but Git does not. Any empty commit messages in your newly migrated git repository should be replaced so commands like git rebase will work on these commits.

This command will replace all empty commit messages with “<empty commit message>”:

git filter-branch -f --msg-filter '
read msg
if [ -n "$msg" ] ; then
    echo "$msg"
else
    echo "<empty commit message>"
fi'

Poking around

After you’ve cleaned up your new master branch, you should cleanup other branches you plan to keep. Just git checkout each branch and repeat the same steps. To find the remote subversion branches available for checkout use git branch -a.

Migrating between version control systems may be a good time to permanently cleanup commit history with a git rebase or eliminate large files that were never used with a git filter-branch. Just remember to make backups of previous working versions of branches before changing them, just in case.

django-reversion

The django-reversion application was started in 2008 by Dave Hall. Reversion uses only one table to store data for all version-tracked models. Each version of a model adds a new row to this table, using a JSON object representing the model state. Models can be reverted to previous versions from the admin interface.  This single-table version structure makes django-reversion very easy to install and to uninstall, but it also creates problems when model fields are changed.

django-revisions

The django-revisions application was created by Stijn Debrouwere in 2010 because the existing Django model history applications at the time were abandoned or suffered from fundamental design problems. Revisions uses a model history method called same-table versioning (design details outlined here). Same-table versioning adds a few fields to each version-tracked model which allows it to record the most recent version of each model as well as old versions in the original model table. Model changes are simplified because they change all versions at once and no new tables need to be added to use revisions (just new fields on existing tables). The only problem I found with revisions was that it does not currently support database-level uniqueness constraints. Adding unique=True to a model field or a unique_together Meta attribute will result in an error. Currently uniqueness constraints must be specified in a separate way for Revisions to honor them when saving models.

django-simple-history

The django-simple-history application was based on code originally written by Marty Alchin, author of Pro Django. Marty Alchin posted AuditTrail on the Django trac wiki in 2007 and later revised and republished the code in his book Pro Django in 2008, renaming it to HistoricalRecords. Corey Bertram created django-simple-history from this code and put it online in 2010.

Simple History works by creating a separate “historical” model for each model that requires an audit trail and storing a snapshot of each changed model instance in that historical model. For example, a Book model would have a HistoricalBook created from it that would store a new HistoricalBook instance every time a Book instance was changed. Collisions are avoided by disabling uniqueness constraints and model schema changes are accepted by automatically changing historical models as well. This method comes at the cost of creating an extra table in the database for each model that needs history.

My conclusions

When testing these three applications myself, I immediately eliminated django-reversion because I needed to allow easy model schema changes for my project. I found that both django-revisions and django-simple-history worked well with schema migrations through South (which I use on everything). Django-revisions worked better for data migrations in South (due to only needing to change one model), but the uniqueness constraint problems with django-revisions would have been problematic for some of my models. So eventually I settled on django-simple-history.

I did not find any Linux applications that will capture/upload a screenshot and copy the URL but I discovered a thread in the Dropbox forums with a script that does just that.  I added comments to the script, changed the variable names, removed the need for a temporary file, and added a notify-send call as a visual cue (should work on Ubuntu).  I have the script mapped to Ctrl-PrtScrn in Ubuntu.

Revealing the primary key of an entity is often not desirable. An astute visitor of the website mentioned above may be able to guess information from the URL such as how many book reviews are available on the website or how old specific reviews are.

The code snippet below demonstrates one way to use a unique but cryptic identifier for an object without needing to change the way primary keys are generated. There are two notable extensions to the basic Django Model in the below code:

1. The encrypted_pk and encrypted_id model properties return an AES-encrypted version of the primary key as a 13 character base-36 string.
2. The get method of the default manager can be queried with an encrypted primary key by using the keyword argument encrypted_pk.

Feel free to use this code however you want.

Unfortunately, this plugin is ineffectual. I have witnessed unexpected behaviors of varying significance associated with this plugin:

1. Forbidden characters can be input by pasting with CTRL+V in Chrome
2. Forbidden characters can be input by selecting Edit->Paste in Firefox and IE
3. Forbidden characters can be input by middle-click pasting in Linux
4. The arrow keys, Home button, End button, and Delete button do not work in input fields using this plugin’s functions in Firefox
5. The context menu is disabled (right clicking on an input field does nothing)
6. And most importantly, instead of using a list of allowed characters, a list of disallowed characters is used so these are the only characters that are actually forbidden:

   !@#$%^{&*()+=[]’;,/{}|”:?~`.-}

The code is so brief that patching the current plugin would be pointless, so instead I wrote a replacement that acts similar enough that I did not have to change any of our pre-existing code that depended on the AlphaNumeric plugin.

First I created restrict, a very basic modifier function that takes a sanitizer function as an argument. The sanitizer function should manipulate the string to be valid input (if it was not already) and return the valid version of this input. The restrict function is triggered whenever the input field is altered and will immediately replace the text in the field with sanitized text.

Most of the restricts I would want to use on an input field can be represented by a regular expression, so I created the regexRestrict function that takes a regular expression as input and uses restrict to replace matches to this regular expression found in the string.

The restrict and regexRestrict functions provide every feature that the AlphaNumeric plugin promises, but they don’t use the same syntax as the AlphaNumeric plugin. To be able to drop this plugin into a codebase that currently uses the AlphaNumeric plugin, we’d need an equivalent to the alphanumeric, alpha, and numeric functions with all of their stated features. To allow the code that relied on the AlphaNumeric plugin to continue functioning, I created replacements for all three of these functions. These functions take the same inputs as their AlphaNumeric plugin equivalents.

The restrict and regexRestrict functions and the alphanumeric plugin replacement that uses these functions can be found on github.

Paradigm difference between these two WM styles:

1. Each additional monitor extends the workspace size
   • One large workspace is visible at a time (ex: workspace 1 spans across all monitors)
   • When the workspace changes, both monitors change
   • When removing a monitor, workspaces must shrink in size, bunching windows together
2. Each additional monitor allows another workspace to be visible
   • Each monitor displays one workspace at a time (ex: monitor 1 currently showing workspace 3 and monitor 2 currently showing workspace 1)
   • When the workspace on one monitor changes the workspace on the other monitor does not need to change
   • When removing a monitor, one less workspace will be displayed

There are many times when I want to be able to keep one monitor static while changing the other monitor. For example I may want a video to stay on one monitor while I work on the other monitor. In most window managers this restricts me to one workspace because changing workspaces would change both monitors. In xmonad, the workspace that contains the video can be placed on one monitor and the visible workspace on the other monitor can changed freely without interfering with the first monitor.

Since using xmonad, I have found “1 workspace per monitor” window management much more productive and comfortable. I wish more window managers would at least make this kind of workspace/monitor handling an option. I have had problems with xmonad recently and I have been trying to switch back to a more popular window manager with free-floating windows like Gnome, KDE, Xfce, or Openbox.

So far my biggest problem with switching to other window managers has been the lack of “1 workspace per monitor” support. Xmonad has greatly increased my productivity with two monitors and it’s hard for me to switch away from it for this reason. Hopefully I will find out how to effectively emulate this behavior in other window managers.

I was wrong. The first time I rebooted I was amazed at the speed of the boot. My boot logger recorded the boot as taking 8 seconds. I have rebooted once more since I installed Jaunty and that boot only took 7 seconds.

The main reason the boot time is so fast is due to my solid state drive. That is how I got my boot down to 15 seconds before. However, 7 seconds is a ridiculously fast boot time in my opinion. Especially since it seems like it takes only about 3 seconds until my login manager is loaded and waiting for me.