vendredi 18 octobre 2013

Le conte de la course d'aviron entre les États-Unis et le Japon

Ce conte nous est rapporté par Debito Arudou, depuis son site www.debito.org, et originalement nommé The tale of the boat race between the us and japan.

Debito aurait reçu ce texte en janvier 1997 d'un étudiant diplômé de UCLA nommé Dave Friedman.

En voici la traduction :
La grande course américaine 
Deux grandes entreprises américaine et japonaise ont décidé de s'engager dans une course d'aviron. Les deux équipes se sont entraînées durement et longtemps pour atteindre leur meilleur niveau. Le jour J, les deux équipes se sentaient prêtes. Les japonais gagnèrent avec 1.5 km d'avance. 
Les américains étaient très déçus par cet échec et le moral était au plus bas. La direction de l'entreprise décida que les raisons de l'échec devait être identifiées. Elle engagea un cabinet de conseil pour étudier le problème et recommander des mesures correctives. 
La conclusion des consultants fut la suivante : les japonais avaient 8 rameurs et 1 barreur. Les américains avaient 1 rameur et 8 barreurs. 
Après une année à étudier le problème, et des millions dépensés, le cabinet de conseil conclut qu'il y avait trop de barreurs, et pas assez de rameurs. 
Le jour de la course approcha et la hiérarchie s'en trouva complètement réorganisée. La nouvelle structure comprenait 4 barreurs principaux; 3 barreurs, 1 par partie : avant, milieu et arrière; et un nouveau système d'évaluation des performances pour inciter le rameur à ramer plus efficacement. 
Les japonais remportèrent la course avec 3 km d'avance. 
A nouveau humilié, l'entreprise américaine renvoya le rameur pour performance insuffisante, et donna un bonus aux managers pour avoir découvert le problème.

mercredi 16 octobre 2013

L'aléatoire en informatique

Vous savez surement lancer un dé ? Ça vous donne un nombre aléatoire entre 1 et 6. Rien de plus simple dans la réalité que de générer un nombre aléatoire. On utilise beaucoup les dés à 6 faces dans toutes sortes de jeu. On appelle ça un D6. Il existe aussi des dés à 20 faces, des D20, et on monte jusqu'à 100 faces même !

Bref, dans la réalité, on sait faire. Comment s'en sort l'informatique ? L'ordinateur ne lance pas un dé pour faire ça, ça prendrait trop de temps ! Certains algorithmes demandent des centaines de milliers de chiffres aléatoires à générer, il faut pouvoir les générer rapidement. Le plus connu est la méthode Monte-Carlo, utile pour calculer des probabilités à de très grandes échelles.

Pour générer ces nombres, on ne va pas faire de l'aléatoire, mais du pseudo-aléatoire. C'est presque aléatoire, mais pas vraiment.

L'idée est de générer une simple suite de nombre, de la forme un = A un-1 + B.
On choisit un point de départ, u0.
Ensuite, u1 = A . u0 + B
Puis u2 = A . u1 + B
etc...

Ainsi on généré la suite un : u0, u1, u2.... Qui nous donne autant de nombre aléatoire que l'on veut !
Pour avoir des nombres qui imite le fonctionnement d'un dé, on va ajouter un modulo 6 pour être sur de rester entre 1 et 6, ce qui nous donne la formule d'un générateur congruentiel linéaire :

un = [A un-1 + B] mod m

Et là, si vous avez suivi, vous avez envie de dire `mais, la suite va toujours avoir la même tête pour le même u0`, et je vous répondrais que c'est vrai. u0 est appelé la graine du générateur, ou `seed` en anglais. Il faut pouvoir la choisir.... aléatoirement !
En pratique, on utilise souvent la date actuelle, ce qui suffit à avoir une génération assez aléatoire.

Enfin, les constantes A et B doivent être choisies pour obtenir les meilleurs suites aléatoires possibles. De nombreux mathématiciens se sont pencher sur le problème, au hasard, A = 31415821, B = 1 et C = 108, et on obtient le générateur de Robert Sedgewick.

Il existe aussi d'autres formules pour créer la suite, d'autre choix de constante, mais le principe de base est toujours le même, un élément de départ u0, puis une suite un = f(un-1).

L'erreur que font la plupart des développeurs est de réinitialiser la graine trop souvent avec la même valeur. Si on initialise la suite selon la seconde actuelle, et qu'on lance l'algorithme 3 fois pendant la même seconde, et bien on tombera 3 fois sur le même résultat, pas super aléatoire.

La méconnaissance de la base de la génération des nombres pseudo-aléatoires amène beaucoup de suspicion et de crainte quand à leurs utilisations, alors qu'en pratique, c'est une simple suite mathématique !

Pour les plus développeurs d'entre vous, l'article de Microsoft sur l'utilisation de la classe Random en C# est concis avec un exemple très précis des erreurs à ne pas faire : Random (Constructeur)

La valeur initiale par défaut est dérivée de l'horloge système et a la résolution finie. En conséquence, les objets Random différents qui sont créés successivement par un appel au constructeur par défaut ont des valeurs initiales par défaut identiques et produisent ainsi des jeux identiques de nombres aléatoires. Ce problème peut être évité en utilisant un seul objet Random pour générer tous les nombres aléatoires. Vous pouvez également le contourner en modifiant la valeur de départ retournée par l'horloge système, puis en fournissant explicitement cette nouvelle valeur de départ au constructeur Random(Int32).

vendredi 4 octobre 2013

Les CVs ne servent à rien

Les CVs et les lettres de motivation sont inutiles pour recruter un bon informaticien. En fait, ils sont inutiles pour n'importe quel genre de travail.

Ai-je envie de recruter le candidat le plus capable de faire un CV complet, concis, précis, parfait ? Je ne sais pas, peut-être, si le job que je veux lui proposer est de rédiger des dizaines de CVs par jour. Mais je voulais recruter un très bon informaticien. Alors je n'ai pas lu les CVs, ni les lettres de motivation.

Non, à la place, j'ai envoyé un test. Un test technique précisément, que les candidats devaient résoudre. Un test qui mêlait code informatique et réflexion mathématique. Rien de très compliqué, juste pour voir de quoi le candidat était capable. On m'a pris pour un original ! Quel idée, alors que lire un CV suffirait largement à savoir de quoi un candidat est capable.

Imaginons qu'à la place de vouloir recruter un informaticien, vous souhaitez recruter un jongleur.

- Recruteur : `Alors comme ça, vous savez jongler jusqu'à 5 balles ?`
- Candidat : `Oui, 5 balles, et facilement en plus.`
- Recruteur : `Et avec des quilles ?`
- Candidat : `5 quilles aussi.`
- Recruteur : `Formidable, on vous embauche !`

A aucun moment vous ne souhaitez voir le jongleur faire une démonstration ? Hélas, c'est ce qu'il se passe souvent en informatique, les recruteurs n'ont que très rarement les capacités d'évaluer techniquement les candidats. Donc on recrute sur CV. On joue au Bingo des mot-clés. `HTML`, `JavaScript`, `NodeJS`, `MySQL`, `PHP` BINGO ! On vous embauche.

Je préfère demander aux candidats d'envoyer un code. Si le code est bon, je lirai le CV, sinon le candidat sera éliminé d'office. Certains CVs de développeurs expérimentés se sont fait éliminés, pendant que j'interviewais des jeunes diplômés. Pourtant si on regardait les CVs, il n'y avait pas photos, le développeur expérimenté était meilleur. Mais le CV n'est que le reflet de la capacité d'un candidat à savoir rédiger un document hyper formaté. En aucun cas cela ne reflète ses capacités techniques.

Il y a quelque temps, un institut de recherche n'a pas retenu ma candidature pour un poste qu'il proposait. Il recherchait un développeur pour créer un logiciel de récupération de données automatisées sur des détecteurs répartis dans des champs de culture, pour créer différents rapports. Je n'ai pas eu d'entretien. Réponse du recruteur : `Nous n'avons pas retenu votre candidature, votre CV n'est pas assez orienté informatique industrielle`.

Je n'ai jamais eu de chance au jeu du bingo.



Bonus : Technical Interviewing - You're Doing it Wrong!

Un point sur les méthodes modernes d'entretien.