28 December 2011

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.

21 December 2011

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!

06 December 2011

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.