Now this is ridiculous

Generics in JavaScript.

Who came up with this? Let’s put things in context: JavaScript is a dynamic language. It turns out that this characteristics deeply upsets many people, particularly those who prefer to rely on a compiler to check their code for them before running it. It turns out that these guys also have a hard time imagining their objects in memory, what do they look like, what they do, and so on, and for them ECMAScript 4 will bring types, that is, variables declared both with the var keyword and a special type declaration after the variable name. There is an illusion built around statically typed languages. I know it: I’ve already advocated them as the silver bullet that never existed. But I was wrong, and I admit it. Personally I think that dynamic languages are the future.

The problem with statically typed languages is that “collections” or “containers” of things should also be typed, because otherwise you spend a good deal of CPU time boxing and casting instances, because otherwise you might as well “put a cat in a dog collection” as one commenter put in the Ajaxian page above.

I am sorry but, in the case of JavaScript, the evolution of the current draft is becoming ridiculous, even after you throw in all your arguments about performance, IDE support and who knows what else:

[source:javascript] function reprimand(list:List.< +Employee>) { … } var writingTeam:List. = new List.(); reprimand(writingTeam); // no error if ECMAScript adopts this style of variance annotation [/source]

ActionScript 3 developers can already enjoy this “syntax sugar”. Ugh! Continue reading

Playing with Dashcode

I’ve been playing with Dashcode today, creating my first ever Dashboard widget (something that I wanted to do for some time) as part of a whole project I’m working on right now.

Basically I’ve discovered that there are, roughly speaking (and please correct me if I’m wrong), two kinds of Dashboard widgets:

  1. Those that you cannot resize, but have nice shadows, “glass” effects and gradients;
  2. and those that you can resize, but do not have shadows, “glass” effects and gradients.

There is no way to get resizable and shadowy widgets at once. At least, not that I’ve found. It seems like Dashcode generates at design time the background images (as a PNG file) for the widgets you’re working on (I suppose that this is done using Quartz), and this cannot be done at runtime (I suppose, again, because of performance considerations…!).

Of course I discovered this while creating a widget that would have had to look good and be resizable. Of course I couldn’t get both :) Another thing that makes me wonder about this dichotomy is this phrase in Apple’s own documentation:

Live resizing means that your widget can change its size and contents based on the user’s preference. Try to limit using live-resizing to cases where it is absolutely necessary. If your content can be shown in a fixed, simple user interface, do so.

All in all, my first impression of Dashcode is that it is a fine IDE, somewhat buggy, but fine for what it does. I still prefer TextMate for editing the JavaScript code inside the widgets, but that’s a personal preference. The workflow for creating widgets is easy to follow, the object model is easy to understand, and I could have a reasonably useful widget in just a couple of hours of work.

Archimedes Reloaded

Give me an API and I’ll move the web.

OK, I’m actually building the API myself this time. That’s why so few posts this month. RESTful, featuring multiple export formats, secure, configurable, usable on top of any existing Django application. It can even generate its own wrappers in a myriad of programming languages.

6 blogs you should read… absolutely

Maybe you don’t have the time or will to read those damn 6 books every year. And maybe that’s fine (for you). I will give you a list of 6 blogs that you can add to your RSS reader. If you care a little about software engineering, new technology trends, and enjoy reading well-written, usually lengthy articles (as I do), IMHO you should be checking these.

25981406_9bad3cd488.jpg

No, mine isn’t in the list :) You can proceed without fear now. Continue reading

Creative Processes

It always start with a white space, like this blog post.

It could happen on a sheet of paper, or lately an empty <textarea>, but the feeling is the same. You get the first flow of ideas, rushing through your head. That’s why I always have a small Moleskine notebook in my pocket; you never know when these things will happen, how long they will last, and when you’ll have another one. Paper has an obvious advantage on computers: you do not need electricity.

I do not “have” an idea; the idea has me. It comes, and then it goes. My task is to write it down, or let it go. I choose.

Jadis you would have started writing in the old-fashioned way; pen, pencil, paper, but the keyboard has got our attention. It’s a different feeling; before, just one hand was to held responsible for my stuff; now it’s every one of my fingers. Simultaneously. It has an advantage, which is to make things go faster. I can write faster, almost as fast as I think. But I need electricity, though.

I can create not only texts but also code. I can later make that code run on the computer, on mine or even on yours. I can talk to those computer, to make them do what I want. We’re new wizards, in a world that would turn crazy any 16th century man. We talk to the machine, and it answers us.

Then I go back, I erase, I reorder paragraphs, I re-read, I spellcheck, I smile, sometimes I tear off the page and start from scratch (the equivalent of selecting “Edition / Select All” & hitting the delete key).

Sometimes I publish, sometimes you read me. There is a nice randomness in all of this, and I clearly enjoy it. Thanks for being there.

Commentaire sur Profession-Web

J’ai poste le commentaire suivant dans un article paru aujourd’hui sur Profession-Web:

“On n’est là pour lui, car C’EST LUI QUI ENGAGE.”

Je pense que l’état d’esprit de la phrase ci-dessus explique le turnover élevé et le bas rendement en général de l’industrie du software et du web en Suisse (particulièrement dans le consulting). Je ne suis en aucun cas d’accord avec cette façon de voir les choses.

L’employeur me paie un salaire, certes, mais il faut être clair sur un point: en tant qu’employé je lui offre 40 heures par semaine de mon temps CPU. Et ce n’est pas peu, compte tenu des open-space bruyants, des interruptions sans cesse et des horribles environnements de travail que certaines entreprises offrent a ses employés. Sans compter celles qui se donnent un plaisir de payer des salaires bien en-dessous de ce que le marché offre, ou qui n’offrent aucun programme de développement de carrière, sous la justification de voir les développeurs comme des machines à taper du code et rien d’autre.

On ne travaille pas POUR un employeur, mais AVEC un employeur. La différence est ENORME. Ce n’est pas une relation unidirectionnelle, mais bien bidirectionnelle.

Lors d’un entretien, c’est aussi au “candidat” de voir en quelques minutes si le cadre de travail, le projet et surtout les gens, sont agréables, intéressants, pour savoir s’il vaut la peine de signer le contrat. L’employeur doit donc aussi préparer l’entretien, chaque jour, en faisant de son entreprise celle qui sortira du lot, pour que les meilleurs viennent à lui.

Le livre “Peopleware” a été écrit il y a 20 ans exactement, et pourtant peu de professionnels RH en Suisse romande en ont entendu parler (encore moins lu). Le marché du soft et du web n’est pas similaire aux autres: le turnover peut tuer une entreprise qui compte sur le génie de ses employés, mais il faut savoir aussi que c’est la branche de l’industrie dans laquelle il est le plus simple du monde de changer de travail.

Alors, pas d’autre solution: il est temps de changer les mentalités.

Tant que les sociétés ne se rendent compte (à la façon de Apple, Sun, Microsoft ou Google) qu’il faut créer un cadre de travail exceptionnel pour y accueillir des gens exceptionnels, tout cela pour créer des services et des produits exceptionnels, qui vont générer des bénéfices exceptionnels, les entretiens d’embauche suivront un cours plutôt “classique”, avec une claire distinction “employeur / employé” basés sur une hiérarchie digne du moyen âge, et non pas du 21ème siècle.

Reducing Code Entropy

This is a rant: I am tired of seeing virtual methods implemented in child classes that, at some point or another, call the method of the same name in the base class. For me this is a sign of poor architecture. A bad, bad smell in code.

Let’s say that you have a base class, called, well, BaseClass (the examples are in C++, but you can take this idea to any other OO language):

[source:c]

class BaseClass { public: // constructor, destructor, copy // constructor, assignment operator…

virtual void doSomething();

}

void BaseClass::doSomething() { // provide some basic behavior here, // and a comment that says something like:

// IMPORTANT NOTE to implementors of subclasses:
// this method should always be called before your code!

}

[/source]

And then you derive a class from this base class, called, well, DerivedClass:

[source:c]

class DerivedClass : public BaseClass { public: // constructor, destructor, copy // constructor, assignment operator…

virtual void doSomething();

}

void DerivedClass::doSomething() { BaseClass::doSomething(); // WTF???

// do something else...

}

[/source]

As stupid as it might sound, this code is hard to understand, debug and maintain, because it includes an unneeded dependency from the child to the base class – that is, another one, besides the fact that one derives from the other!

Continue reading