The Microsoft Touch Mouse Needs Better Software

I've recently picked up a Microsoft Touch Mouse in post-Christmas sales with a huge discount, and I thought I'd describe my experience.

The mouse itself is a nice (Apple-inspired) concept: a multitouch sensor replacing good ol' mouse buttons and wheel; after enduring several mice with hardware defects, having one (almost) without any mechanical moving parts feels reassuring.

Actual usage is slightly less natural than you'd expect. Scrolling is probably the trickiest activity, since in practice it now depends on friction between your finger and the mouse surface, and you have no mechanical feedback.
Right-clicking is also a bit weird, if you're in the habit of resting your index finger while doing it: the sensor detects "rested index + clicking middle" as a different (void) activity, not as a right-click, so you'll need to actually lift the index as you click with the middle finger, or move all the way and right-click with your index finger.

I believe the two items above are to be blamed for 99% of bad reviews; they break long-standing muscle memory for power users, who are heavy on their scrolling and right-clicking, and give a feel that the mouse will randomly decide what to do rather than respond to actual gestures.

The scrolling speed can be adjusted in the driver properties, reducing awkwardness, but there is no tweak for the right-click problem. And this is where Microsoft really failed: there is no way to easily customize the device.

The driver defines a limited set of gestures that you can turn on or off, but you cannot override their assignment (i.e. what they actually do) nor create new ones. Some of these gestures are quite nice: three-finger swipes will bring up the Windows equivalent of Apple's Expose'; two-finger swipes work like Win+Arrows (probably the best feature in the Windows 7 Aero desktop), thumb swipes perform Back/Forward in a very natural way. Unfortunately there is a long list of other gestures that one would really need (open/close browser tabs, a middle-click replacement, window resizing, etc etc) and there is no way to add them; worse, there is no way to simply remap existing gestures to new commands, which should be dead easy; one can only remap left and right click, which nobody will ever do.

Apparently there is a C#/C++ SDK for the sensor (32bit and 64bit), and some students have already come up with nice improvements (like the one shown in this embedded video), but it's a shame that Microsoft, a software company first and foremost,  let down this lovely piece of hardware so badly by not shipping a proper gesture editor or mapper. I really do hope they'll release updated drivers with more features in the near future.

VBScript, PowerShell, Python, IronPython, Jython, or... ?

In my job, more and more I find that we end up building distributed architectures, i.e. multi-server installations where services are routinely spread around 20+ Windows boxes, plus the occasional Unix. These services have specific startup and shutdown sequences and dependencies, so they can't just be set to Automatic startup; we usually provide batch files to manage them, but this is quickly becoming ugly and unreliable as the number of machines go up every year. It's also tricky to test actual service availability -- some are binary-based, some are HTTP based, some are Weblogic services, etc etc etc... So I'm investigating alternatives.

The first, natural choice for me was obviously Python: it does everything I need, it's flexible etc. However, distributing scripts to customers is a bitch; either you compile everything with cx_freeze (crashy) or py2exe (no python 3! no 64bit bundling! party like it was 2004! have fun tracking down which un-redistributable DLL or manifest you need on each release...), or you drop an entire environment and teach the customer what python is -- not ideal.

The traditional "native" approach to these problems in the Windows world is VBScript. It's fairly flexible, doesn't need to be deployed on Windows Win2003+ (yes, we still deal with loads of Win2003 servers), documentation is extensive and there are plenty of resources out there.
The problem with VBScript, apart from the ugly syntax and pseudo-OOP quirkiness, is that it's clearly seen as legacy by Microsoft. Year after year, running scripts becomes more cumbersome, security checks increase and new technologies don't expose the necessary interfaces. Does it make sense, in 2011, to invest time and effort building solutions that are, de-facto, already obsolete?

So we come to PowerShell, Microsoft's "future of scripting", which must be the less intuitive shell I've ever had the pleasure to deal with. I simply can't get my head around the way it deals with input and output; it doesn't seem to have reference assignment, so you have to retrieve an object on every line before you can use it; the syntax seems to combine the worst of Perl and Bash, and it quickly becomes unreadable. Also, deploying it on anything older than Vista has to be done manually and has to be justified to customers.

I honestly can't see a good solution here. I keep looking at IronPython, but its infrastructure baffles me and I wouldn't know where to start redistributing programs (I don't use Visual Studio). It's clearly a second-class citizen in the .Net world, with all that it entails.

Maybe Jython? After all, the products we install will drop JREs absolutely everywhere, so I could leverage that. I'd like to avoid going full-Java if I can, I hate the whole byzantine toolchain and I'm not really up to speed with post-1.4 changes; plus, there's always a degree of customization required in each environment, so I'd like to keep stuff as easily-editable as possible.

Please feel free to drop any suggestions in comments, I could really do with them!

State of Python 3

I want to start a little side-project, basically a few lines of HTTP automation and mail sending; nothing that some Taco Bell Programming couldn't handle, but I don't particularly like shell scripts and I figured it'd be cleaner in Python.

It's 2011 and One Should Really Use Python 3, right ? The box I'll work on is a brand new Debian Testing where Python 2.x is not even installed, perfect! I'll just grab virtualenv... Waitamminute, "python" doesn't even run, but I'm sure I had installed the python3 package...? Oh, "python3" in Debian doesn't give you /usr/bin/python but rather /usr/bin/python3 !
Thank you, Debian Project, for your consistent inconsistency dealing with anything Python-related. Ok, so a quick run of update-alternatives and that's sorted.

Now I'll

easy_install virtualenv

... sorry, easy_install3 virtualenv, of course... oops, syntax error, clearly a Python 2.x package there. Does easy_install discriminate between 2.x and 3.x package? Er, no. Joy.

Whatever, I'll just grab virtualenv.py and drop it in /usr/local/bin, right? cool, works a treat. Activated my virtualenv, let's try again to download a couple of libs... paramiko: syntax error, clearly a 2.x package. funkload: syntax error, again a 2.x package. I know, I'll use pip! ... no difference.

Basically I can choose whether to handle libraries like it was 2001, website after website, setup.py after setup.py; or I can develop like it was 2009, i.e. with python 2.x.

I think for now I'll choose life, and drop python 3.

Python WMI, services and UAC

In this day and age, security-conscious Windows users "enjoy" the protection of User Access Control (UAC), a feature introduced with Vista and now a stalwart of the Microsoft world in Windows Server 2008 and Windows 7. This is why you get prompted to "allow this program to make changes to your computer" every time you install a program, or if you run a lot of "legacy" Win32 applications.

Under UAC, even when you are a local administrator, the programs you launch will not, by default, enjoy all system privileges you would expect. Until you get prompted by UAC to allow for system access, processes will run under a basic user profile.

This is a problem when you try to interoperate with Windows from Python. As soon as you try to manipulate system objects, for example to start/stop services, you'll get a lot of "Access Denied" return codes.

One solution, obviously, is to use the "Run as Administrator" option to launch python.exe, so that you get prompted by UAC and the resulting process will effectively run under elevated privileges. Note that it's not enough to launch Command Prompt (cmd.exe) with "run as an administrator" and to then call python.exe from there. You must explicitly hunt down python.exe in explorer and right-click on it, nothing less will do.

This is fine and dandy for the basic REPL interpreter, but what if you need to do it from a script? How do you elevate the process from inside a running python.exe?

The answer is to use ShellExecute with the "runas" verb, like this:

import win32api
win32api.ShellExecute( 0, # parent window
    "runas", # need this to force UAC to act
    "C:\\python27\\python.exe", 
    "c:\\path\\to\\script.py", 
    "C:\\python27", # base dir
    1 ) # window visibility - 1: visible, 0: background

UAC will then prompt the user and elevate the process. For an example script that you can only run under elevated privileges, check this:

import wmi
c = wmi.WMI()
serviceToStart = 'aspnet_state' # example
for service in c.Win32_Service(Name=serviceToStart): 
    service.StartService()

Note: I haven't tested this with py2exe yet, but at worst you should be able to right-click on the py2exe-generated binary and select to Run as Administrator anyway.

Random Linux tips

Playing with Arch Linux, I was forced to learn a thing or two about terminals. For example, I've often seen that silly annoyance where VI would start typing A, B etc when using arrow keys in insert mode; apparently it's due to a mismatch between what VI thinks the $TERM type should send and what actually gets there. In my case, I had to add the following option in my .vimrc: set term=builtin_xterm Also: xterms colors and options go in a .Xresources file, which must be loaded at some point with "xrdb -merge .Xresources" Meanwhile, emacs was taking ages to start up. Turns out it's doing some funky things with hostnames, you can use strace to see where it gets stuck polling for what emacs thinks is the machine name, and make sure that name can be resolved quickly (e.g. fix your /etc/hosts). Who knew grep can use colours? grep --color=auto (note: the "auto" scheme assumes a dark background for the terminal). And who knew there was such a thing as colordiff?

Social experiments with Facebook IDs

Having just watched "The Social Network", I stumbled on a post on Twitter pointing to graph.facebook.com, the free API you can use to scrape the shit out of FB (well, almost).

Turns out the API will work with IDs. Since FB started as a Harvard-only site, the first few hundred users were all Harvard alumni, obviously. So I started thinking about simple experiments like finding the most popular surnames, certain of having my class-based prejudices reinforced by loads of Winklevoss-style "aristonames". Turns out the most common names are actually Asian -- the elites of tomorrow, of course.

That's the issue, isn't it? Harvard is (supposedly) a top institution, churning out the "elites of tomorrow"; they won't all become Mark Zuckerberg, but they probably won't be homeless either.

So, as a joke, I wrote a script looking for Wikipedia pages dedicated to the first 1000 users of Facebook. Turns out there are a lot of very common names, which obviously result in false positives; unfortunately Wikipedia doesn't give you easily-parsed metadata (here's a new project for Jimbo Wales and friends), so I couldn't do things like discarding everyone born before 1970. With a bit of patience, I narrowed down the number to a rough 6%. Some of them are (or were) Facebook employees, of course, but there are also young poets, writers and comedians.

You would probably get better results by replacing Wikipedia with LinkedIn, which would include more successful businesspeople and professionals -- Harvard's bread and butter. Obviously you could also start digging across the entire FB userbase, beyond the first lucky Harvardites.

These web APIs are a great tool for smart researchers; you now have a lot of data to be correlated with a little bit of programming glue and very little time. The result might not be scientifically exact, but could still unearth surprising insights.

XKCD Fanfiction

Panel 1:
Stick Figure A: "Can you believe it? I once touched Michael Jackson's HAND!"
Stick Figure B: "So what?"

Panel 2:
SFB: "You touched the hand of a singer famous for grabbing his private parts while dancing. Did this improve your life in any way?"

SFA: "..."

Panel 3:
SFB: "I mean, did you ever SPEAK to him? Did he write you a SONG or something?"

Panel 4:
SFA: "No, but last year Donald Knuth waved at me through a cafeteria window."
SFB: "Dude, that's AWESOME!"


ALT-TEXT: "He was really looking at some Finnish creep behind me, one Snoopy Torvalds I think. Yeah, never heard of him either."