Uniquely identifiable URLs are necessary for many web applications. For example, a website that provides book reviews may identify the URL of a specific book like this: www.example.com/books/8839/. The easiest way to identify entities in Django is to use the unique primary key of each object, which by default is an auto-incremented positive integer.

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.

I recently inherited a codebase that used the jQuery AlphaNumeric plugin extensively. This plugin can be used to restrict users from entering certain characters into a form field. The functions included for this plugin (alphanumeric, alpha, and numeric) claim to allow only alphabetic and/or numeric characters to be entered in the form field being acted on.

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.

In most window managers (WMs) that allow for multiple workspaces, additional monitors simply increase the size of each workspace. Since January I have been using a window manager that handles multiple monitors very differently, xmonad. Instead of increasing the workspace size to fit onto two monitors, each monitor displays a separate workspace, so the number of visible workspaces is increased.

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 upgraded my Thinkpad to Ubuntu 9.04 (Jaunty Jackalope) recently. My laptop has a solid-state drive and I had tweaked the boot process previously so it was down to 15 seconds. I had heard that Jaunty had drastically decrease the boot time, but I figured my computer could not boot much faster than it already had since I had modified the boot process drastically.

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.