Django Management.tmbundle

Did some work on my Django Management.tmbundle last night.

It now handles running tests when (a) The apps are not directly in the project root, but inside another folder, for instance; and (b) the app/ file has been split into seperate files.

The main reason I made this was so that I could run tests and have clickable links in the results window for the location of failing tests.

There is still much to do on this. I am considering re-writing it in python rather than ruby, so I can programmatically find the app name, rather than guess it. I also want to refactor the hell out of it and make it much nicer.

Anyway, if you are interested, you can find the most recent version at - and I think it also appears in TextMate’s getBundles bundle.

Images in placeholder for input fields

Since I have been doing a heap of web/html dev lately, I’ve taken to noticing things. Today, on MacWorld, I noticed this:


Clicking in the search box results in:


So, there is an image in the placeholder. This is very neat!

Unfortunately, it appears this might not be a part of the HTML5 spec, but is done using JavaScript.

Copy password button in

I don’t know if this is new or not, but I haven’t noticed it before. My normal workflow for and finding a forgotten password (ie, my Twitter one to put into a new app) is to open the password entry, and copy the value.

Today, I noticed a Copy button at the bottom of the window:

Keychain Access

This still requires you to enter your keychain password to authorise the copy, but saves a step or two.

Combining recurring events with approval

A while ago, I talked about the issues with taking a set of potentially recurring events and merging them into the least number of events that fully describe all of the occurrences. This was a bit of a challenge, but with a TDD process, I was able to get something that, as far as my testing tells me works. Thus, deleting one middle occurrence of a recurring event results in two events being left, and re-creating that occurrence results in the one event being created.

This goes even further, with occurrences that touch or overlap being merged into potentially a new event. This is a requirement of our problem domain, since these events are used to see if a person is available to perform a task, and two adjacent occurrences would otherwise make it hard to determine if the person is indeed available.

So, it turns out that this is only part of the problem. In addition, changes to availability may require approval by a manager. So, in addition to being able to merge objects, we also need to be able to merge pending objects with one another, and mark pending objects as superseding other objects. And, even more fun, if a pending object is created that matches a pending-deletion object, for instance, then that object is restored: the two pending events cancel one another out. Finally, a pending object can also be ‘psuedo-merged’ with an availability, where it then is the union of the two events, and supersedes the approved event!

This problem is even stickier than the previous part. Having said that, I have it working, although at this stage it is not possible to have recurring pending events. Things were made even more difficult by the way that I handle superseding events. This cannot be just references in the database, as events and occurrences may be deleted and created by saving another event, so a different method of keeping track of which events are superseded is required.

The good news is, this is coming along well. It did occur to me on the way home today that without ‘never ending’ events, this would possibly collapse the problem space down. Occurrences would no longer need to be recreated quite as often, and indeed they may be the sole storage representation: abstract events could then be created on the fly, purely for descriptive purposes. All I need is some way to represent events that don’t have an end date…

…or I could make it that never-ending events must end in 2050. Then, any event that ends that year will be represented to the user as never-ending. This seems like a slippery Y2K-style slope, but if I keep moving the goal-posts, then it might work. And simplify my code immensely. It turns out there are only ~2100 weeks until then, and my events at this stage only occur weekly (it makes the simplification simpler to only have to look for weekly patterns, and that is how people usually determine their schedule).

I’m glad we had this little chat.

Combining recurring events

On a project I am working on for work at the moment, we have a need to handle recurring events. These events need to be merged if they are the same and can be simplified in any way. As it turns out, this is quite a tricky problem.

There are really only two ways that events can be merged. If two events have the same frequency, and occur on the same day, or on consecutive days according to the period, and they have the same start and finish times, then they can be merged into one.

Similarly, if two events have the same period, occur on all of the same days, and overlap or touch in times, they can be merged into a single event.

From there, it starts to get complicated. Two events that partially overlap may be able to merge parts of themselves, possibly resulting in an extra event being created.

For instance, an event every Tuesday at 9am-12noon, that lasts for 10 weeks, and another event every Tuesday 11am-2pm that starts 5 weeks later, and also runs for 10 weeks, will result in 3 events: one that lasts 5 weeks 9-12, one that lasts 5 more weeks 9-2, and one that lasts a further 5 weeks 11-2.

This on its own is easy to deal with, but as soon as you consider events that have no end date, things get tricky quickly.

Typing the ° symbol on iPhone.

For future reference: press and hold 0, and the ° will appear.