I came across Aimersoft DVD Backup, and ran it. Not looking too bad to begin with.

The actual window, however, is appalling:

It is a little hard to see, but the window is not actually connected to the titlebar. You can actually see the objects that are in obscured windows in the gap between them!

Finally, the text from the close confirmation sheet just cracked me up:

Surely, they can tell if a copying task is in progress, and display a dialog then. If not, then just quit immediately!

For the SQL savvy, it can look like:

CREATE TABLE event (
…more columns here…
start datetime,
finish datetime,
count integer CHECK (count >= 0),
CONSTRAINT event_starts_before_finish CHECK (start < finish)
);

There are two types of constraint here: the column-level constraint, which in this instance can be done with django, and the table-level constraint, which in many systems cannot be a part of a column definition. In PostgreSQL, my DBMS of choice, it is possible to define a constraint that affects more than one column as part of a column, but I prefer not to. Note also that I am using the syntax form that allows me to name the constraint. This means I can alter or drop it later.

As I mentioned, django can do the first type of constraint, as long as it is a > 0 constraint, using one of the field types that subclasses PositiveInteger. However, there is no functionality built into django to do the latter. And I would like to use them.

It is possible to just add the constraints to an already existing database: indeed, that is what I did for work. Having the constraints at the database level means that, since I have more than one interface to my datastore (don’t ask: one of them is for an old SOAP interface I need to keep around), I want to ensure that even if someone accesses it outside of django, they cannot put in data that breaks these constraints. Similarly, if I use an interface other than the admin interface, or heaven forbid, open up the database in raw form, I cannot accidentally put in data that breaks this validation.

But, pure database level constraints don’t give very nice feedback in django. It is nicer to have the pretty red boxes around my field than the traceback. So, I want the validation to occur on the field level as well. As long as I am using django’s forms (and my API for RESTful access will use them for validation), then I will have these errors nicely presented.

So, to that end, I have created some code that allows for the definition and enforcement of both of these types of constraint.

The column form allows for a new keyword argument to a field:

count = models.IntegerField(constraint=">= 0")

Notably, the string that can be passed in must conform to the pattern “cmp value”, where cmp is one of the comparison operators (<, >, <=, >=, =, !=), and value is a valid value for this column type. It will be passed to the to_python() method of this field when comparing. There must be a string between the two parts.

The other form is a new attribute on the Meta class of a model.

check_constraints = (’start < finish’,)  

This must be a tuple of strings, where a string is of the form “column cmp column”. Again, there must be a space either side of cmp, and each column name must be a valid column. Not meeting these criteria will result in a validation error.

From these definitions, the database constraints will be applied, and validation of forms will also occur.

I have deliberately made the constraints simple (ie, not callable objects) so that they can easily be converted to database constraints. For instance, they can effectively be transferred straight through to the database (with the addition of the column name in the case of the column constraint).

I am going to create a ticket in the django trac, and submit a patch. Guessing I should write up some test cases, though!

I had installed the Passenger Prefpane, which greatly simplifies the management of VirtualHost-based serving of sites, at least for Rails and other ruby-based frameworks. With a little work, you can use the same setup to serve Django projects.

Rather than re-detail the setup, I’ll just point you to the mod_passenger setup, and the Passenger Prefpane setup pages.

Now, to set up a Django project: obviously you need a django project. Create one, and note where it is located. I stick all of mine in ~/Sites.

Add a file to the root of this project, called passenger_wsgi.py. It needs to contain the following data:

import os, sys
sys.path.append('/Users/matt/Sites') # Replace with your directory
os.environ['DJANGO_SETTINGS_MODULE'] = 'testing.settings' # replace with your projectname.
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Now, add the site to the Passenger prefpane. My site is the testing.local site:

Now visit the address and ensure that it works. You should get the basic “you need to set up django” message.

To get the admin media served by the standard apache setup, I created a link inside the /Library/WebServer/Documents directory to /Library/Python/2.5/site-packages/django/contrib/admin/media. This can be done inside the Terminal:

sudo ln -s /Library/Python/2.5/site-packages/django/contrib/admin/media /Library/WebServer/Documents/admin-media/

Then, change the ADMIN_MEDIA setting in your django projects to “http://localhost/admin-media/“. This is probably the weakest point in the setup, as it will only work for pages served to your machine, not others on your network.

# URL prefix for admin media -- CSS, JavaScript and images. Make sure to use a
# trailing slash.
# Examples: "http://foo.com/media/", "/media/".
ADMIN_MEDIA_PREFIX = 'http://localhost/admin-media/'

I had some issues with mod_passenger serving the data for localhost (and arne, my actual machine’s name) from the first installed VirtualHost. To overcome this, I put in a new file into /etc/apache2/other/localhost.conf, which looks like:

<VirtualHost *:80>
  DocumentRoot "/Library/WebServer/Documents"
  <directory "/Library/WebServer/Documents">
    Order allow,deny
    Allow from all
  </directory>
</VirtualHost>

This forces unnamed, or other sites to work as intended. Including the /User/*/Sites directories.

But you can get notifications from anywhere. A Perl script is included, but that didn’t work on my server. So I wrote one in Ruby:

#! /usr/bin/ruby

# A ruby class for sending notifications to Prowl.

require 'uri'
require 'net/http'
require 'net/https'

class String
  def urlencode
    gsub( /[^a-zA-Z0-9\-_\.!~*'()]/n ) {|x| sprintf('%%%02x', x[0]) }
  end
end

class Hash
  def urlencode
    collect { |k,v| "#{k.to_s.urlencode}=#{v.to_s.urlencode}" }.join('&')
  end
end

class Prowler
  def initialize user, pass
    @url = URI.parse('https://prowl.weks.net/api/add_notification.php')
    @username = user
    @password = pass

    @http = Net::HTTP.new(@url.host, @url.port)
    @http.use_ssl = true
  end

  def send_notification app, evt, desc

    options = {
      'application' => app,
      'event' => evt,
      'description' => desc
    }

    req = Net::HTTP::Get.new("#{@url.path}?#{options.urlencode}")
    req.basic_auth @username, @password
    @http.request(req)
  end

end

# How to use?
# p = Prowler.new('username', 'password')
# p.send_notification('App','Event','Desc')

Here is the logo from the Adelaide City Council (which has been in use for about 7 years):

Wonder which came first…

If I overlay one one the other, we see they are not identical:

It turns out that git was not in my path. Putting a link from /usr/local/bin/git to /usr/bin/git fixed that all up.

These functions only work when the initial output option is not set as “Show as HTML”. The list of functions is as follows:

• exit_discard
• exit_replace_text
• exit_replace_document
• exit_insert_text
• exit_insert_snippet
• exit_show_html
• exit_show_tool_tip
• exit_create_new_document  

This is all well and good, but what about when you are in another language?

Simple. Just ensure your exit code matches. The values start at 200, for exit_discard, and 205 is exit_show_html.

This is probably not the best way to do it, as these may change in the future. But, I couldn’t think of another way, at least not offline.

Another good example of a PHP “quirk” is the way PHP handles constants. It was one of the major factors affecting performance. Just removing all the constants allowed us to improve the performance by almost 2x (we left one constant to be precise).

From The Need for Speed.

That’s right - PHP is up to 2X faster if you don’t use constants. You know, that means hardcode values in…

diff -r 5e13047a2284 Support/hg_commit.rb
--- a/Support/hg_commit.rb	Mon Apr 27 11:38:15 2009 +0930
+++ b/Support/hg_commit.rb	Mon Apr 27 11:39:00 2009 +0930
@@ -79,7 +79,7 @@
   commit_paths_array = matches_to_paths(commit_matches)
   commit_status = matches_to_status(commit_matches).join(":")
   commit_path_text = commit_paths_array.collect{|path| path.quote_filename_for_shell }.join(" ")
-  commit_args = %x{"#{commit_tool}" --status #{commit_status} #{commit_path_text} }
+  commit_args = %x{"#{commit_tool}" --diff-cmd hg,diff --status #{commit_status} #{commit_path_text} }

   status = $CHILD_STATUS
   if status != 0