Subclassed

Conversation silos are an anti-pattern

2012-01-10T00:22:00.000Z

It looks (to me) like people just stopped commenting on blog posts. More and more, I might find some great, very technical post, just to discover it has zero comments; ironically, I'd probably got there through a link on Hacker News or Reddit or G+, where it'd have dozens (if not hundreds) of comments. The original author might or might not know about the conversation; if it's happening on one of the large portals, he'll probably find out because of the traffic surge and its side-effects (db crash, bandwidth bill, etc), but if it's happening in a smaller community he doesn't participate in, he might remain completely oblivious to its existence.

This is a sad anti-pattern, exactly as bad as Disqus; it's just another way of building information silos. It's even more sad to see this model being pushed by the geek community, who should know better. Yes, trackback/pingback and RSS have failed; but there must be a better way to interlink the debate across this bunch of URLs we call "the web".

IntelliJ PyCharm 2.0 and Jython 2.2 don't really go together

2012-01-04T03:27:00.000Z

UPDATE: Dmitry Jemerov from IntelliJ responded, explaining what the situation is. TL;DR: 2.2 is simply too old, other features might come if there is demand. I've amended the post to reflect this.

Let me preface this rant by saying that I've been happily using JetBrains PyCharm for a few months, and it's certainly one of the best Python IDEs out there. The price is ridiculously low and if you're serious about Python, buying PyCharm is one of the best investments you can make. It can be used for free for 30 days, so you really should give it a shot.

This said, if you happen to work with Jython 2.2, you'll probably want to use something else. The claim that Jython is fully supported as a runtime, while literally true, ~~is somehow stretched~~ is only valid for 2.5+.

Let's say you work on Windows, and you have your Jython installed under C:\jython-2.2 (yes, it's damn old, but it's still the most widely-deployed release out there -- just ask IBM and Oracle).

You create a new project in PyCharm, then go to Settings -> Python interpreter, remove the preconfigured CPython runtime, then click on Add and point to your C:\jython-2.2\jython.bat. Bang, "SDK is not valid". The list of library paths, which supposed to be automatically generated by the IDE picking up the environment configuration, is now empty.

Still, PyCharm should be smart enough to parse arbitrary .py files in specific directories, right? So let's click on Add... to point to C:\jython-2.2\Lib, then OK.
Now let's create a .py file, "from pprint import pprint", the module is recognised; "Run" the script, output is correct, life is good: Jython is indeed supported as a Python runtime.

Ok, let's do some file I/O, "import os"... uh, os is not recognised as a valid module. Same for sys. Apparently, they are somewhat special in Jython and are implemented directly into the main jar, so PyCharm can't see them for autocompletion or any other smart feature. I don't know what else is "special" in Jython 2.2, but I'd rather not have to find out.

Which brings us to the main shortcoming of PyCharm as a Jython IDE: it simply won't recognise or parse any Java jar. This is somewhat surprising, considering how the program is basically a spin-off of IntelliJ IDEA, a Java IDE, and is completely built on Java. In fact, it shares the codebase with the Python Plugin for IDEA. One would think PyCharm would be ideally suited to the task of handling the "Python on Java" mesh that is Jython, but alas that's not the case. A quick search on the IntelliJ forum brings up recent posts stating that full Jython support for autocompletion is simply not on the cards; Jython is supported as a runtime and nothing more. In fact, the Python plugin for IDEA ~~probably~~ handles a Jython setup better than PyCharm, and that's not going to change any time soon. The main target for PyCharm are clearly Django/web developers, not integrators. UPDATE: see this blog post for more details on the real situation.

This state of things is a bit saddening. I don't know if this is a way for JetBrains to avoid cannibalizing its main cash-cow (IDEA), or simply a commercial oversight; the fact is that we have a product, ideally positioned to completely own a niche, which simply refuses to do so and actually delivers a second-rate experience. I hope JetBrains will re-evaluate their stance at some point, because it's a bit of a shame really.

The Microsoft Touch Mouse Needs Better Software

2011-12-28T11:39:00.000Z

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... ?

2011-12-21T13:05:00.000Z

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

2011-12-06T21:34:00.001Z

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

2011-09-16T11:13:00.005+01:00

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

2011-06-20T12:47:00.001+01:00

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

2011-03-23T21:54:00.005Z

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

2011-02-25T08:33:00.010Z

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."

Valid keywords for KIO.Job.addMetaData

2010-10-24T20:49:00.006+01:00

I spent three hours last night, pulling my hair out, while trying to add a custom HTTP header to a StoredTransferJob generated by KIO.storedHttpPost.

In my naivety, I thought KIO.Job.addMetaData(key,value) would accept an HTTP header name as key, and the actual header value as value. I was twice wrong: "key" is a limited list of accepted keywords (documented in the obscure DESIGN.metadata file, buried in the KDE source tree and not linked by any tutorial), and "value" is the complete header (e.g. "Content-Type: application/x-www-form-urlencoded"). It's essential to get the key right, or the metadata will be silently dropped (argh); I had to fiddle with Wireshark to find out. By the way, the two essential keys you probably want to remember are "content-type" and the life-saving ~~"CustomHTTPHeader"~~"customHTTPHeader" (DAMN LOWERCASE C!!! it's wrong in the design document, btw.).

(That's the terrible thing about KDE APIs: lots of barely-documented quirkiness hidden under an appearance of ease-of-use. You start developing thinking that it's all going to be easy, and find out along the way that things are not really as simple as they seem. I guess I should be thankful that at least they have good web tools to browse and grep their source, and fairly complete doxygen docs... but it still hurts more than it should.)

If anything can go wrong...

2010-07-23T20:00:00.001+01:00

Blogger forced people to move off FTP publishing... expect breakage.

The joys of Python and Qt

2010-03-09T20:30:00.003Z

I'm currently working on a tutorial regarding MeeGo, the new Linux-based embedded platform born by the merging of (Nokia-sponsored) Maemo and (Intel-adopted) Moblin. MeeGo is probably the closest thing we'll ever get to a real "Linux for the masses": differently from Android, where Linux is just a kernel for Java to run on top, here we'll have the full GNU toolchain, X display, desktop technologies based on FreeDesktop standards, RPM packages, etc etc.

The main development toolkit for MeeGo, from now on, will officially be QT. This seems to fly in the face of reason, having two existing GTK-based codebases from both "parent" systems which have already been deployed on production devices, but it's actually a very smart choice, as I was reminded just today.

This morning, I was working on a laptop running Windows XP. I built a couple of forms with Qt Designer, then fired up my trusty IDE and wrote the main code, about 150 lines of Python that will download some files, manage a few controls and then display a web page.

After completing a full set of tests on the local machine, I copied it to my (Maemo) phone, and again it was working perfectly -- without any change, recompilation, deployment, anything. Then I went home and copied it back to a different laptop running Kubuntu Linux, and again it was running just fine. Had I had a Mac (or iPad?) laying around, I'm confident it would have run there as well without any change. Consider that the version of QT and PyQt was slightly different on all machines, just to give it a further twist.

Obviously this level of portability has a price. I had to write my code using constructs like QSettings and QNetworkAccessManager rather than messing directly with the Windows Registry or HTTP_PROXY variables. I have yet another (leaky) abstraction layer on top of the OS, which may or may not be to everyone's taste, and the program runs in a sandboxed runtime, which might be slower than natively-compiled code (although this is debatable, these days); but I didn't have to write three different codepaths for each and every interoperation with the OS. I didn't have to worry about having a $HOME or a %HOME%. If I have to worry about packaging is just because I have to write about the ins and outs of a particular platform; in other circumstances I could have simply relied on python tools to do the right thing.

Python and QT could finally deliver the dream of portability that Java promised, if only we give them a sporting chance.

CallBlocker for Maemo

2010-03-03T15:25:00.004Z

Last week, Vinu Thomas came up with an ingenious script that will silently drop calls on your N900 if they come from a list of "blocked" callers. I never thought you could do that, but apparently there have been quite a few apps for this sort of things on more established platforms like Symbian and iPhone.

At first I suggested a few minor improvements to the script, then I thought I might as well repackage it in a proper application with a proper GUI. I asked permission to Vinu (something the author of "pycallblocker" didn't bother to do), and then I went ahead and put it on Garage.

So there you have it: CallBlocker 1.0 for Maemo 5. Note that it relies on the python2.5-qt4-gui package, currently available only in the extras-testing repository.

The current feature-set is quite limited: you basically enter a list of phone numbers, and callers (exactly) matching them will be sent a busy signal or redirected to voicemail.

It did get quite a warm reception on talk.maemo.org, so I'm motivated to keep development ongoing (at the expense of other, still-unreleased stuff I have almost ready). The current plan is to release a 1.1 version with support for suffix wildcards (e.g. entering +441234*, all numbers beginning with +441234 would be matched and dropped) and better daemon management. Then, time permitting, I'd like to have a 2.0 with features like blocking all withheld/private numbers, blocking SMS texts, blocking specific contacts from address book, blocking all numbers not in addressbook, blocking only during some hours, and possibly even a "whitelist" mode.

Once it reaches a certain maturity, I'll probably consider moving it to the Ovi Store, at which point PyQt licensing issues might arise, but we'll cross that bridge when we get to it.

KDE 4.4.0 on Kubuntu Karmic 9.10 -- a note of warning

2010-02-21T23:56:00.001Z

I just upgraded my Kubuntu 9.10 "Karmic Koala" from KDE 4.3.4 to 4.4.0 using the backports repository. A note of warning: take a backup.

It took me something like 4 or 5 runs of apt-get dist-upgrade / apt-get -f install to get back a working setup. APT complained about a couple of things (python-qt3-doc conflicting with some newer package which includes the same examples, and Bilbo having been renamed Blogilo) but eventually pulled it through.

I was smart enough to backup the .kde home directory before launching a 4.4 session, and I'm glad I was. First run: Plasma crashed hard on a segfault, and didn't restart. Ok, this happened with some past upgrade already, let's just move away the old .kde home... got back a default desktop. Playing around with widgets, I hit another crash. And another. The culprit was always the Plasma Desktop, actual applications were running fine. Eventually, I moved back the old .kde home except the plasma* files under .kde/share/config/. This gave me back all my old KDE settings, except for Plasma. Win, I thought, and merrily set out to recreate my previous desktop arrangement.

Another crash.

So uhm. I'll try to track down what exactly Plasma doesn't like in my setup (which was, for the record, with two panels on left and right edge; Lancelot and a couple of QuickAccess widgets on the left, task manager and shutdown button on the right; two Plasma "views" and 4 virtual desktops), but if you are planning a similar upgrade, make sure you put aside some time for it, and get a good backup beforehand.

(I guess the question now would be "is it worth it?". Well, KDE does look more polished, applications are faster to launch and more responsive... it does look like we're finally at the point where one could upgrade from a 3.5.x release to 4.x and feel a bit awestruck.)

Mobile applications for Nokia phones with... javascript ?!?

2010-02-09T08:16:00.005Z

A few days ago the lovely folks at NSManchester, an Apple user group, gave a chance to "the enemy" (i.e. Nokia) to present their technology stack and business strategies for attracting developers.

The two presenter were a bit underwhelming (understandable after they went through the usual, hellish experience with British railway services), and there was little talk of my beloved Maemo, but it's hard to dismiss the technology stack they have chosen to go forward. Key element seems to be the QT library they acquired last year, which I know and love through the original Python bindings. It's powerful and as cross-platform as it can be, with a lot of mindshare in the Linux and Windows communities; this said, it's still C++, and it's hard to get excited about C++ these days. Also, the runtime will gradually appear on new and recent phones but probably won't make it to older ones.

The second development platform they are pushing, however, was more of a surprise to me. Apparently, you can use JavaScript to write applications for recent smartphones (S60 5th ed. -- N97 and 5800 -- and S60 3rd ed. FP2 -- e.g. E72, N85, N96 etc). You can access GPS coordinates, contacts and calendar items, as well as having complete freedom to design the UI with standard HTML and CSS. You don't need to sign the resulting packages, the barrier to entry is lowered dramatically. This is potentially a game-changer, and I don't know why Nokia are not shouting it from the rooftops. Early adopters include Netflix, which uses a basic JavaScript interface to stream their Flash content (!) -- so yes, you can use flash as well. My head simply went "boom"; I must look into this stuff.

One other thing I noticed was the presenters' style, typically European: self-deprecation and brutal honesty about things that work and ones that don't. It was refreshing, after weeks of Yanks propaganda from Google and Apple pushing their new gadgets as "fantastic", "amazing", "revolutionary" etc etc etc...

Backupify

2010-01-29T23:17:00.001Z

Thanks to the lovely gPodder on my Nokia N900, I've recently discovered the net@night podcast by Leo Laporte. Like many regular podcasts, it's mostly full of random chatting and showmanship. In this respect, "new media" tend to be exactly like "old media": forced by their own schedule to blabber for the sake of it. But I digress.

The best segment of Laporte's show is usually an interview with someone from a startup, which is a good way of finding out about new services. Yesterday, it made me sign up for Backupify, a "social media backup tool" which will scrape your GMail / Delicious / Facebook / Flickr / Twitter / Blogger / Wordpress etc etc and store all the resulting data in a safe place on Amazon's cloud. Not a bad idea: the first 20 years of the Age of the Internet should have taught us, if anything, that data is ephemeral and can disappear at the flick of a switch. What happened to Geocities is proof that today's giants won't necessarily be with us tomorrow. Conscious of this state of things, Backupify gives you the option to drop your data on your own Amazon server, so that it will still be available if they go belly-up; quite a honest approach for a startup. It used to be a pay-only service, then went free to accelerate growth and get some venture capital; they will move to a freemium model after January 31, so you better try it out now if you can.

Good "Web 2.0" services usually expose APIs that make backups relatively easy for a programmer, but who's got time to write dedicated scripts AND the foresight to run them regularly? Myself, I've probably written half a dozen GMail scrapers, but I hardly ever ran them more than once. I've exported this Blogger-powered site once, and it was a nightmare. Backupify makes it very easy to "set up and forget", and that's good. The data will only be as good as what the various sites will allow; for example you will never be able to "restore" a Twitter account, so Backupify will only give you a PDF of your (and your friends') twits, which is the best you can expect. For Google Spreadsheets you get XLS files, for Blogger you get a big XML containing all your posts, etc etc.

The only problem with the site is the password anti-pattern: in order to get at your data, they often have to ask for your login details, and will store them on their servers. They do use OAuth if the service supports it (like Facebook or Google), but otherwise you'll have to trust them with your credentials. This makes them a very good target for black-hat hackers, among other things. I do hope they know what they are doing.

How the Nokia N900 is improving my life

2010-01-25T11:18:00.003Z

(Small things, but...)

Today I had to took my car to the garage, so had to tell my manager I'd likely be late (public transport is not terrible in our area, but it still takes me about twice the time to get to the office than it would with the car). I'm also down with a laryngitis and I can barely whisper.

I could have booted my home laptop to send an email or IM, but meanwhile the bus would have come and gone. So I hit the road anyway, and thought I would somehow email from the phone.

But then, the Nokia N900 is no Blackberry; it's a full-fledged linux desktop in your pockets. When I enabled the 3G data connection, the button nearby was the one to set your IM status(es) to Online; so I fired that up, looked up my manager in the wonderfully integrated address book, and she was online, so while I sit on the bus, we had a friendly chat about things to do, without having to share them with other commuters or strain my poor throat.

All the while, I was listening to the latest Python 411 podcast about the (apparently terrific and currently-slashdotted) Sikuli project, updating expenses on the little program I've developed (which I'll upload to the Ovi Store in a few weeks, I promise), and browsing Google Reader. The 30-mins commute was over in what seemed like seconds, and the experience was basically the same I could have had while sitting at my desk with a regular laptop.

This little thing is simply outstanding. Apple's new "iWhatever" better have a SIM slot, or they can kiss goodbye to their iPhone marketshare.

The personal-GPS market has just died

2010-01-21T22:12:00.000Z

Nokia just announced that the turn-by-turn navigation addons to their (underwhelming) gps software, Ovi Maps, will now be offered free of charge, completely undercutting TomTom and friends. They can do this thanks to the recent acquisition of Navteq, the top map-making company in the world (which is still selling map data to competitors at a hefty price, by the way, including Google); and they have to do it, because Google is doing it as well on Android and iPhone.

If Nokia can really deliver (i.e. actually improve Ovi Maps, which is quite frankly not as good as commercial competitors yet), 2010 will be remembered as the year that GPS devices became obsolete, like it happened to PDAs about three years ago. TomTom shareholders better run for the hills.

Remote shutdown on Windows

2010-01-19T10:54:00.001Z

This might sound useless or obvious to many, but i didn't know it and it made my life easier today...

If you ever need to shutdown a remote Windows machine, and you can't access it with Remote Desktop or similar tools, you can use Shutdown.exe from another Windows machine, like this: shutdown /m \\my-remote-host

Additional parameters can be seen with /? but the most useful ones are:

/r: reboot after shutdown
/f: force shutdown -- useful when the machine looks stuck, which is what happened to me today...
/d xx:yy: give a reason for reboot. See /? for the available codes.

I hope this means I can say goodbye to dangerous hard-reboots...

Nokia Ovi Store Policies on SaaS / subscriptions: fail

2010-01-18T14:51:00.005Z

(Chances are that nobody will answer this question, like it happened to this developer on forum.nokia.com, but what the hell)

I have an interesting business idea. I'll develop a mobile application with some interesting functionality, and I'll give it away for free. The application will contain an option to upload some data to a remote server, which you will then access from any computer as a regular site. The website will have some advanced features to analyze the data etc etc. The site will operate as SaaS, with a free 30-day trial. Basically, the site will make the real money, in a way similar to what FeedDemon and NewsGator tried a few years ago in a different market.

Now, if I wanted to do that on Nokia platforms, I would try and put my mobile app on the Ovi Store as a free download, right? After all, it will be a useful program in its own right, with the online services being 100% optional. Nokia / Ovi get a free, useful app enriching its (crappy) customer experience, the developer gets a big distribution channel, it's a win-win!

Except that landlords don't like uppity sharecroppers. From the Ovi Terms & Conditions:

4.7. Free Content Restriction

You are prohibited from collecting future charges from end users for Content that those end users were initially allowed to obtain for free. This is not intended to prevent distribution of free trial versions of Your Content with a later upsell option to obtain the full version of the Content. Such free trials for Content are permitted. However, if You want to collect fees after the free trial expires, You must collect all fees for the full version of Your Content through the Program. In this Agreement, "free" means there are no charges or fees of any kind for use of the Content. All fees received by You for Content distributed via the Program must be processed by Nokia.

Now, I can see the motive behind such a "racket clause". Nokia doesn't want Ovi to end up a cesspool of trialware, or to be associated with "click once and pay forever" scams. But the rule is too broad, and it reads like any SaaS scenario is simply out of the question (especially when you consider that Ovi does not support "subscriptions" at the moment, only one-off payments). SaaS is probably the best revenue model in the software world at the moment, and Nokia is telling developers they can't use it.

I honestly do not know if Apple put similar restrictions in place on their store. They probably did (and then some), control-freak as they are, and this is why I wouldn't want to touch the iPhone ecosystem with a barge pole. But Nokia was supposed to be trying hard to regain developer mindshare...

So the question I'd like to ask, before I shell out for the Ovi "publisher" license, is: dear Nokia, my application does something useful on your mobiles. It will then, optionally, send some data to my server, and I will personally collect money to have people access that data on the web, aggregated in various ways. Can I put the app on Ovi?

More notes on N900

2010-01-12T00:41:00.002Z

The N900 is lovely, but the more I use it, the more I get the feeling that releasing it as a mass-market phone might have been a bit premature.

Take the "grid" icons. Technically, you can sort them: each icon can be given a "priority" number, and the lower it is, the higher it will appear. Technically, you can create additional subfolders and even auto-sort icons depending on the application classification (office, media etc). Unfortunately, all of this must be done *by manually editing an XML file* (/etc/xdg/menus/hildon.menu) plus several other text files (the .desktop and .application files in /usr/share/applications/hildon). For a consumer-grade device, this is shocking. It's even worse: if you mess up said files, the system goes in a "reboot loop" from which is very hard to escape (hint: get the flasher tool and use it with only parameter --enable-rd-mode, then fix the file, then use flasher again with --disable-rd-mode; if that doesn't work, you'll have to do a full reflash).

Also, it does not work with the SIM cards from network Three in UK and Denmark; considering that Three is a favourite of data-heavy users, who should be the main target for this device, this was a big mistake.

Some applications are clearly half-baked (Maps), and the Ovi Store is still closed. You make a big launch taking over the entire ad-space on Gizmodo for a day, and your supposedly flagship applcation store is not working ?

Nokia are slowly addressing these issues by releasing over-the-air updates, which is good, but the overall feeling remains: as released (late), the N900 is for hackers and hobbyists. Which, considering the platform potential and role, is a crying shame.

N900 first impression

2010-01-07T23:21:00.001Z

Cool. Feels sturdier than iPhone. Opening the battery compartment is shockingly hard, which is surprising if you think that Nokia always paid a lot of attention to battery slots etc. The hardware keyboard is undoubtedly better than virtual ones, and key size is about right for my clumsy fingers. Desktop navigation is da bomb, incredibly better and more customizable than anything seen before. Default browser is lovely if a bit idiosyncratic, mostly due to the erratic touchscreen. Ah, the touchscreen: worse than iPhone, sorry. The stylus is still quite handy. Apps: quite a bit of them, after enabling the extras repository, and decent quality. Will try the ovi store later. The feeling is that, finally, Nokia built a device for the internet: the network is taken for granted and integrated everywhere. The web experience is so good that custom clients (e.g. for twitter or facebook) are hardly needed. I'm writing this post from MaStory, but I could have used blogger.com and the experience would not have been much worse. And of course, this phone runs linux. Which means that you can hack it to death, and that the market is fully open. S60 developers can officially retire, Maemo is simply on another planet. Now let's hope Nokia won't blow this massive chance...

Plasma + Python + QThread = bad

2009-12-05T23:52:00.001Z

DOM manipulation performed in a QThread launched from a KDE Plasma applet written in Python is officially a very bad idea. Minidom: crash. QDomDocument: crash. !Fun.

If you can't fix it, rebrand it

2009-11-30T08:17:00.004Z

The reputation of the KDE ecosystem was tarnished by a crappy release process for KDE4. Essential desktop components simply weren't ready for release in 4.0 and 4.1 (some of them still are mostly vaporware) after a huge barrage of hype had massively raised expectations, and this generated a lot of (well deserved) bad publicity. The answer?

Go and rebrand it, so that the development process can be broken up more easily and people will be persuaded to blame the right developers for each component. And while we are at it, let's throw out KDE's well-earned reputation for deep integration, the idea of the DE as a complete platform for users and developers. Let's give users the idea that KDE is just a "compilation" of bits and bobs thrown together for no particular reason, on the way overlapping as much as possible with the concept of "distribution", making it fun for companies to explain the difference and for developers to understand what they can and cannot rely on for their apps. Now KDE is supposed to be just a "community", a "club" of like-minded (C++) people hanging out in Gran Canaria and the like.

Yeah, that will be fun.

Honestly, I've been a big KDE fan for ages, but the development process for KDE4 was clearly wrong on so many levels. Developers' reactions to user feedback in the last two years have been astonishingly patronizing, and this is just another instance of it. Just admit that errors were made and get to work, please, instead of wasting time jet-setting from one "conference" to another (preferably in remote islands with good nightclubs), talking about marketing b*llocks.

Akonadi vs Plasma: a tale of disorganized, randomic development

2009-11-29T15:20:00.001Z

The Akonadi::ItemView class, which should provide a default, out-of-the-box view of data stored by Akonadi (KDE 4 technology), depending on the type of resource it represents, cannot be included in a Plasma.Applet (KDE 4 technology) but only in a KXmlGuiClient or KXmlGuiWindow (KDE 3 technology).

Clearly dogfood isn't as tasty as apple pie.