Blog::new

It seems that I wasn’t the only one making the connection with the open source ecosystem.

How long do you think an email address can stay in the spam lists ? I just quizzed a bunch of friends about this, one immediately answered “indefinitely”. He’s right.

Back in 1992-93, my first job was being a trainee at the INRIA. There was no web back then, we actually witnessed its birth (and all we did was shrug). Usenet was the main channel for discussions, and I used to post in a few newsgroups. Spam was exceptionnal, people doing it (generally college kids who didn’t know better) were rebuked by people receiving their messages and would even apologize when they would realize what they had done.

By some strange twist of fate, I find myself working again at the INRIA today, some 15 years later. I started on april 2nd. When I first logged on my office machine and looked at my mail, I was very surprised to find about 45 spams in it. Most of them were directed at my own address, rather than at one of the mailing lists I had been subscribed to by default.

I was rather surprised but given the amount of spam we get these days, I figured it was to be expected, since it couldn’t be possible that this was because my address was a “once valid” one (since the INRIA has kept the same policy for creating logins and mail addresses, in effect they had “ressurected” an email address that used to exist 15 years ago). Or so I thought. Then I noticed that some of this spam was directed at a host of the inria.fr domain that couldn’t possibly be “seen” from outside. It was the host I used to post to Usenet from.

So it really goes like this : create an email adress, post on Usenet or somewhere where it will be harvested, disable the adress, wait 15 years, enable the adress… and watch the spam pour in.

Yuck.

After screwing up some potentially good shots at the last concert I attended, I figured it would be a nice opportunity to apply one of the principles mentioned in the original article which led me to open this blog : write for yourself, as a way to order your thoughts. So here goes.

A concert is generally fast moving subjects in low, yet high-contrast light conditions. If anybody can think of worse conditions to take pictures, I’m seriously curious to hear about them. Therefore you need wide-aperture lenses. f2.8 is a minimum, constant if possible. Stabilised optics are even better. On my Canon 20D, I am lucky enough to carry the 17-55mm f2.8 IS and the 70-200mm f2.8 IS. The first one is also a very good walk-around lens. The 2nd is of the “pry from my cold dead hands” kind.

Camera setup :

• aperture priority (AV) mode. Set it to the widest aperture you have.
• increase ISO, depending on the light conditions. 400 is the usual minimum, 800 is more common, 1600 is tolerable. You need to get 1/25 maximum exposure time (above that, you’ll get motion blur no matter what, IS or not - unless the whole band is under heavy sedation)
• no flash : it bothers the performers, and it’s useless (except in very small venues, in which case it will bother the performers even more). Don’t even think about it, flash is explicitly forbidden in most venues anyway.
• spot metering mode (or anything close enough your camera has). This is very important, because your camera has very little chances to figure out the right exposure by itself. More on this below.
• if needed, under-expose a little. Noise or under-exposure can be fixed (to some extent), blur cannot. So if the current lighting won’t give you a short enough exposure time, set the exposure down a bit. 1.5 stop is generally the most you can afford without getting picture you won’t be able to ressuscitate. Be aware that even the best image noise processors will leave this caracteristic “plastic-like” look on skin, or turn hair into blur (which is avoidable, but takes time).
• yet, a concert is one of the situations where motion blur can actually look good. But it’s generally better if you have it on the subject you’re shooting while not on the background.
• standard, “one-shot” auto-focus mode. If your camera has some kind of ‘focus servo’ mode (where the camera automatically keeps focus on the subject if it moves), don’t use it. You’ll be reframing often (and often significantly), and the focus will be messed up. (This is the bit which cost me a bunch of good pictures last time).
• burst mode : fast moving subjects, talking (well, singing) in many cases - shooting in burst mode will increase your chances of taking a good picture where the subject doesn’t look goofy.

Why spot metering : as I said, you’re shooting subjects in high-contrast light conditions. What’s more, the performers themselves will very often be highly contrasted, namely wearing dark clothes. The part which you want to be properly exposed is the face (a shot where the subject’s face is either under or overexposed will generally look bad, no matter the rest). If you use any other metering mode, it’s quite likely the camera will evaluate an exposure longer than what you need, because of the subject’s dark clothes, or the dark surroundings. Not only you’ll get motion blur, you will also have overexposed faces.

So when shooting, you need to lock light metering on the subject’s face first. Only then go ahead with focusing, reframing if needed (it often is), shooting. This is a quick reflex game, it does take some practice.

Finally, some more general tips : ear plugs, small torch light (always comes in handy), high-capacity memory card. Behave nicely try to be as inconspicuous as possible (don’t ever try to attract the performer’s attention - you’ll be thrown out, and if not you should be).

(add : a compilation of links regarding concert photography).

… paralysis, frustration, and generally unhapiness, as explained by this very interesting post from Garr Reynold’s Presentation Zen blog (the video of the TED presentation is worth your time).

Two equally interesting applications to what is explained here :

• a political/economical one : the current trend of offering a plethora of choices to customers is actually alienating, and is only meant to drive consumption. Another paradox there is that behind all these choices are actually a diminishing numbers of actual makers and suppliers. These choices are actually “more of the same”, or more precisely “an ever-growing more of an every-diminishing same” (cf. Naomi Klein’s No Logo)
• a UI design / programming one : whenever you want to add another user-configurable option to your program, think hard. Very, very hard. In this case, the frustration will come not from the fear of missing an hypothetic “even better” choice, but from being asked questions you don’t care about, or really don’t want to deal with.

To wit, a few hours after reading this post, I was looking at akregator’s configuration panel. In it, there’s an option to set the archive back-end. It’s a combo, with only two choices : “metakit”, or “no archive”. That this option is clearly unfinished is one thing, the real problem is that it should never have been implemented at all. Which end-user wants to deal with that ? This is really geek stuff, and even then, those who take a kick out of trying every single program of their favorite linux distribution, fine-tuning their environment down to the pixel, but never actually produce anything useful.

This is a spot-on answer to one of my favourite pet peeve : wannabe’s who claim they can’t live without such and such tool or feature, so removing them would be extremely bad, so please leave it or make it an option. They call to freedom while they’re actually selfish morons. This post is part of the clue bat they should be beaten with.

I had the privilege to meet Gnome’s founder, Miguel de Icaza at the first GUADEC back in… oh my, 2000, has it been that long already. I was still co-leading gtk– at the time. Miguel is a brilliant fellow, full of energy and spirit. But at the time I was disagreeing with most of his views. So it is with some amusement that I caught the following bit in a recent interview :

derStandard.at: What would - in retrospect - be the one piece of software that you most regret having written in plain C cause C# was not around at that time?

Miguel de Icaza: Everything that I ever wrote for the desktop.

And just before that :

I would not waste time in the 99% of the application that copes with high-level issues doing it in a low-level language.

You don’t say.

Gee, Miguel, C++ was there at the time too. It’s far from being as high level as C#, but it’s still better than C. (that said, believe it or not, I very much hope that mono will grow to be a commonly used platform for desktop apps on Linux, because C# is just so much better than C++ - but please drop GTK as a graphic toolkit, that can only be a temporary solution. Debugging through two levels of completely different object models will always be a nightmare)

Following up on my ‘ajax sux’ post, this post by Jeff Atwood. I agree with his conclusion : after all these years we should be able to make something better for app development than this hodge-podge of different technologies. There is a clear need for thin-client apps, but there’s gotta be a better way than Ajax to fulfill it.

It’s ironic that a couple of weeks after this silly display of zealotry, this interesting video on how to deal with poisonous users would be highlighted on slashdot. We’re quite fortunate with Rosegarden that we almost never had to deal with this problem. I can only think on one occurrence, but the guy actually turned into a valuable contributor once we explained the problem to him.

The thread linked above on the merits of KDE’s new file manager, Dolphin has pretty much all of the standard features of the clueless user who can’t tolerate having to change his ways. His point is that his current way of working is the best one and must not be altered, more specifically must not be simplified or “dumbed down”. I’m pretty sure there’s a strong correlation between how much a user wants his environment to be configurable, and how not unproductive he actually is. I.e., the more you care about fine-tuning your tools, the less you actually use them. The extreme being, you guessed it, PC tuners :-). View it as a form of procrastination if you will, I’ve yet to see someone who’s adamant about “having choice” (which really means wanting to use his pet apps and considering that anything else is crap) also producing anything useful.

That won’t prevent him from demanding to see the data from usability tests, only if those contradict his own usage patterns of course (which are completely geekish but he can’t realise that).

On a side note, you have to be impressed by Aaron’s tactful and patient behavior all throughout the thread.

This slashdot story prompted me to write a post about free software and politics which I had hinted in a footnote of my first post.

Before carrying on, for the sake of clarity I should state that in France, I’m center-left, in the US I’m a dangerous leftist.

The author of the slashdot story is puzzled to see that right-wing people are more likely to use free software than left-wing ones. But, given that free software is generally considered to be a ‘left’ value, one would have thought it would be the opposite (and, as some comments explain, I believe it is the case in France). However there are two ways to see the problem :

You can consider the software industry to be the perfect example of capitalism and free entreprise in action, and therefore free software, aiming to destroy it, to be anti-capitalist (thus left-oriented).

Or, you can consider that free software, being the empowerment of the individual, is an even better free enterprise illustration against the state-like monopoly of the software industry. One of the basic postulate behind right-wing politics is that the free market always finds the best solution, eventually, a solution which state-driven economics (i.e. socialism) cannot hope to find. And that’s exactly what free software postulates : give free reign to developpers and they will create software that the industry (which is a state-like structure) can’t possibly produce. And there you have why libertarians such as ESR who believe in minimal government also support free software.

At this point it’s hard to resist indulging into an obvious statement : the little I’ve learned about economics clearly show that free market (or, the combination of everybody’s selfish motives) does reach equilibrium, only the worst one. And you have a perfect example of this in free software : people prefer to start their own project than to collaborate with an existing one. The very philosophy of free software gives them a perfect reason to do so : “let the users decide”. Only the users don’t have perfect market knowledge, they don’t evaluate different pieces of software rationally, but emotionally. Because they liked what the author said in an interview, because they like the looks, or some specific feature, but not because it’s really better written or designed (they may sometimes argue so but honestly, have they really looked at the code ?). So sometimes there is indeed stabilisation over a few pieces of software, each fitting its own niche. Most of the time however you get a big old duplication of efforts, with zealots on each side arguing on how their own favorite is really the best one and the other side are just a bunch of morons.

So there. If free market really was working so well, we wouldn’t have two incomplete desktop frameworks and Microsoft would be long gone. Instead, it seems that the State as a government system is still the best working solution : letting devs do what they like whenever possible, and constraining them to do what’s needed the rest of the time. And that’s why I’d rather pay taxes than letting the market decide if a school or a road should be built or not.

A long time ago, in a galaxy… err, no, scratch that. A long time ago (circa 1999-2000), I used to work for a company which was making software debugging and testing tools. One of the main product was a C++ tool akin to Purify. You’d apply it on your code and it would show you mem leaks, uninitialized pointers, etc… all these pesky bugs which make C/C++ development so enjoyable.

At some point I was working on a GUI in C++, and during an informal meeting with the main boss, he told me that I should be using our C++ tool on my code. I wasn’t. Why ? Two reasons. One, because I was reasonably confident about my code. That sounds preposterous and conceited, but I about 99% of the mem allocations in my code where done in a “managed” way. That is, the framework I was using (ok, that was Qt, version 2.x at the time) was handling them for me (yay for object trees).

Upon explaining this to him, he proceeded to show me how wrong I was. He sat down at the keyboard, downloaded the product’s last version, untarred it, and, if I recall correctly, first wasted a few minutes trying to install it correctly. Then he tried to apply it on my code. “Applying” meant recompiling my code with the tool, since it was pre-processing the code (’instrumenting’ was the exact term) to stuff it with calls to its own libraries before passing it to the actual compiler, then linking with its own libs. I don’t recall exactly if we couldn’t even get passed that stage, or if the resulting binary was dumping core too quickly to yield any relevant information (if you’ve used this kind of tool, you know that even system libs are likely to trip it), but it ended up with him finally giving up and concluding with “well, you really should use it”.

And that was a perfect demonstration of the 2nd and most important reason why I wasn’t using our tool : because it was too darn complicated to use. And from that I shall derive what I think is the single most important feature of a any software testing tool, no matter the language or the framework : ease of use. Using it should be a no-brainer.

Compare the above with a similar tool which we happily use with rosegarden from time to time : valgrind (valgrind appeared about a couple of years after the events above happened). Using valgrind amounts to typing valgrind program-to-check from the command line, and it will present you with a bunch of error reports, most of them relevant (unlike that tool above which would spout a bunch of false alarms). No rebuild, no relink with exotic libs, just run your usual build (compiled with debug info in so you’d get useful stack traces for each error found), and there you go. Sure it runs way slower than usual, but waiting is much less of a problem then spending brain cycles on getting the tool to work.

Software development is hard and complicated. So it’s pretty obvious that any tool you use in order to make it less hard and complicated absolutely must not itself be hard and complicated. And yet it seems most such tools completely forget about this, putting cleverness above anything else. “Look at how our tool could find this obscure bug!” Yes, but look at what it took to find it…

So what, you’ll say, TANSTAAFL. This is software dev, not walking in the park. True, but the unavoidable consequence is that no matter how effective it is, the tool won’t be used. Nobody will use your debugging tool if it takes hours to get working. A regression test suite will soon be left to rot if it’s too hard to run and maintain. You can have a team which sole purpose is to bear the brunt of dealing with all test-related issues, but that causes a whole new bunch of problems (communication, training, etc…) A test team should do high-level tests, not functional, fine-grain ones. Those really are for the guy writing the code, and the only way to get him to do them is to make him want to do them. And a developer won’t be willing to do something unless it clearly makes his job less complicated.

Why do we use IDEs for Java programming ? Because that squiggly red line under that bit of code I’ve just typed there telling me there’s something wrong is helpful. I don’t even have to try building the code to get that error. The gain is obvious. That’s how any test tool should be : so simple to use that I will want to use it, without being constrained by some PHB.

Unfortunately there’s still no way around the work needed to build a test suite, for instance. But at the very least build it so that running it is as easy as possible (and that’s hard too ). Actually in that case, the suite may be based on a test tool, but it becomes a test tool itself so, sorry, it’s up to you to make it easy to use (another lesson I learned the hard way).

It seems this cute little device is enjoying a growing attention from geeks all around. I’ve just taken a long look at it and was very much interested : open API (with a 3rd party Ruby module to boot, a large and dynamic community… then I came across this deal-killer : you can’t pilot the nabaztag directly, all requests have to go through Violet’s server. If the thing has an embedded web server (like all these devices have), you can’t reach it through your LAN.

The usual reaction would be to wonder what the hell ever came through their mind when they took this decision, but I suppose they had a good reason to do things that way. At least I hope so, otherwise it boggles the mind that designers of a rather clever device would make such a blunder. And sure enough they paid the price for it, since it seems that last Christmas their servers keeled over under the registration requests of the new rabbits.

I’ll still keep an eye on it, hopefully they’ll change this.