Posted on 25th January 2010. Tagged as web, cakephp, php
Yesterday, I wrote asbo.org.uk, a site which provides really basic visualisation of the UK's anti-social behaviour order data from 1999-2007. This data was recently released by data.gov.uk.
I wrote the whole site, wrangled the data, and deployed it yesterday afternoon, in about six hours. I've got some contract work coming up using CakePHP, so I wanted to try it out, and I wanted to see what I could do in such a short space of time. I'm quite pleased with the results. There's no analysis of the data, just presentation, but I was trying to see what I could do in the time I had, rather than develop features.
Originally, I wanted to write a 'how safe am I' sort of application, which could offer data about the types of crime most likely to occur in a given area, but this idea was pretty much killed by the time I saw the actual data available. Maybe I don't know enough about Excel-scraping, but I considerably reduced the scope of this project because the data was such a mess - it's just not worth the time to extract information from arbitrarily formatted spreadsheets. Formatting the single table of data used on asbo.org.uk took about three hours, which seems like a waste.
I was generally quite impressed with CakePHP; it's laid out in a sane way, though coming from Python some of the automatic discovery of models in the controllers feels a little bit magic, and I'm not sure I'm comfortable passing around arrays of data rather than data objects themselves, but it's not a deal breaker. I do like the layout system, something I commonly implement with blocks in Django, but seeing it formalised as part of the recommended approach to application templating is nice.
There's quite a lot of buzz aroundProject Sikuli at the moment, so I spent time today playing with it.
Sikuli is a GUI automation engine which uses a vision engine to identify elements on screen. In practise, it works well as a quick way to script repetitive desktop actions, without having to learn the AppleScript actions an application provides, or how to hook into a desktop accessibility framework to manipulate applications. Instead, you tell the Sikuli engine how you expect regions of the screen to look, and then how to further manipulate them with clicks, key-presses and so on.
That is quite an abstract explanation, so here is a practical example.
Every morning, when I sit down at my desk, I do two things: I do some basic maintenance on my Mac, and I print out my day planner sheet. This only takes maybe 5 minutes, but I need to wait in front of the screen and click the right buttons at the right time. That's pretty dull, so here's how I'm using Sikuli to automate that.
First of all, the maintenance script. I use CleanMyMac to perform one big system clean every morning, which requires a few steps; launching the application, scanning for files to clean, approving the list of files, running the cleaning process, then closing the application.
My Sikuli script for doing this looks like this:
The script is fairly self-explanatory. First, it switches to (or opens) the CleanMyMac application, then runs the scan process. The script sleeps for five seconds, the searches for the 'scan finished' message, and goes to sleep again until that message is displayed. Then it performs the clean operation, and again waits for the 'clean finished' message. After this, it closes the application.
At no point is this script passing events directly to the application, nor is it querying the application to get information about its state; it's just examining the frame-buffer and looking for patterns which are similar to those specified in the script. On the Sikuli website, they claim their vision engine is smart enough to still work even if an application slightly changes it's visual style, but I haven't been able to test this.
This is the script for printing my day planner:
First, it closes then re-opens Pages so that it is in a predictable state. Then, the script manipulates the 'recent documents' drop-down, to open my 'Day Sheet 2' document. Notice that the script uses the 'wait' function frequently so that the vision engine isn't searching for an image before it has been drawn by the operating system. Once the document is open, we pass the operating system the ⌘P keyboard shortcut to open the print dialogue, then click 'print'. Finally, Pages is closed, and I check my printer tray. Here's a screen-cast of this in action. Note that I use the 'Run and show each action' button to start the script. This way, you can see the vision engine matching and highlighting each element on the screen:
Sikuli does have some limitations; You can't copy and paste between scripts, which I think is due to how the IDE stores image region data on the filesystem. Also, scripts seem wedded to the IDE, so you can't launch a script without needing to click the 'run' button in the IDE, but as the IDE is really just a thin wrapper over an underlying Jython instance, I'm sure this would be possible with a little more digging.
The obvious next step is to properly test how well Sikuli does deal with visual changes; using Sikuli to test web applications would be a great addition to the toolbox (and it would eliminate the problems with brittle tools like Selenium), and the IDE and language is simple enough for non-programmers to take some of the burden of writing tests.
I'm quite looking forward to the future of Sikuli. I'd like to see this visual search technology make it into more traditional scripting environments like AppleScript, though I'm not sure that'll happen any time soon, but anything which reduces reliance on bending traditional accessibility frameworks to perform in this role is a step forward.
"This is my project base. There are many like it, but this one is mine."
Today I finally got around to putting my Django project base on Github. I've been using this base for about six months now, and after a lot of rewrites and different approaches, it's now reasonably stable. I've been starting a lot of new projects recently, and repeatedly fixing the same small bugs in this project template, so I decided to spend a few hours this afternoon cleaning it up and making it public.
I'm not totally satisfied with my use of shell scripts to do some of the bootstrap actions (ideally I'd use Fabric for all of these tasks), and longer-term I want to make it easier to rename the django project rather than using search/replace in TextMate.
I know there are a lot of similar projects to this on Github, but none of them worked exactly like I wanted (I think too many depend on zc.buildout and similar), and while I'm not crazy about re-inventing the wheel, I hope there are enough other people out there who share my preferences who will find this useful.
