À votre avis : un forum sur ce site ?

Je réfléchis depuis quelques temps à l’idée d’élargir ce site à «un peu plus qu’un blog». Parce qu’il faut bien dire ce qui est, l’interactivité d’un blog est assez frustrante. J’écris, certaines personnes répondent en commentaire, et ça ne va pas beaucoup plus loin. Ne vous méprenez pas, j’adore les…

Lire la suite

Livre : Founders at work

Je viens de terminer de lire le livre «Founders at Work», de Jessica Livingston (co-créatrice de l’incubateur Y Combinator). C’est un recueil d’interviews faites auprès de plusieurs créateurs (ou co-créateurs, la plupart du temps) d’entreprises. Le thème général du livre est de s’attarder plus particulièrement sur les premières heures de…

Lire la suite

Durée d’étude et expérience professionnelle

Il existe globalement 3 types de filières de formation :

  • Les études «classiques», en université ou en école d’ingénieur, sur des cursus cours (2 ou 3 ans) ou longs (5 ans).
  • Les études en alternance, avec différentes formules sur des rythmes très cadencés (4 jours en entreprise / 1 jour à l’école) ou très séquencés (3 semaines en entreprise / 1 semaine à l’école).
  • L’autoformation (il ne faut pas négliger les autodidactes, il y en a de très brillants).

Oui, je sais, je simplifie beaucoup les choses, mais c’est pour le bien de mon propos.

Intéressons-nous aux deux premiers types d’études. Elles comportent, l’une comme l’autre, des périodes d’enseignement scolaire magistral (cours en amphi, TD), des périodes d’application pratique (projets) et des périodes de découverte du milieu professionnel (stages ou apprentissage). La seule différence, c’est l’équilibre qui est tenu entre ces trois aspects.
Si je continue à schématiser, ça donne quelque chose comme ça :

  • En université, les cours magistraux forment l’essentiel de la formation.
  • En école d’ingénieur, les projets sont souvent prépondérants, ou tout au moins très importants.
  • En alternance, c’est l’expérience acquise en entreprise qui constitue la majeure partie du temps de formation.

Notez bien que je ne porte pas le moindre jugement sur ces différences. J’en parlerai peut-être dans un autre article, mais ce n’est pas le sujet pour le moment. Sachez juste qu’ayant passé 3 ans à la fac, 4 ans en école d’ingénieur, pour avoir embauché des informaticiens de tous profils et pour avoir donné des conférences dans des établissements assez différents, j’ai une vision assez précise de tout ça.

La chose qui ne cesse de m’étonner, c’est la perception que les informaticiens ont de leurs cursus, et comment ils les présentent lors des entretiens d’embauche.

Des outil de travail rustiques

Cet article est dans la droite ligne du précédent, dans lequel je vous parlais du concept de rusticité au sens large. Là, je voudrais vous donner un exemple concernant certains outils de travail que j’utilise au quotidien − personnellement ou avec mon équipe.

J’ai mis en place plusieurs outils numérique qui servent au travail collaboratif : email, wiki, partage de fichiers, todo-list, buglist, calendrier partagé, … Tout cela est très utile, et ces outils sont devenus essentiels à notre organisation. J’ai déjà parlé de tous ces outils par le passé, et je reviendrai certainement dessus.

Mais d’un point de vu très concret, on a tous besoin d’outils pour :

  • prendre des notes à la sauvette
  • établir des todo-lists éphémères
  • faire des dessins comme support à une réflexion
  • faire des croquis pour échanger des idées en équipe

Je ne sais pas pour vous, mais pour moi c’est vital. Je n’arrête pas de noter des choses, qui ont une durée de vie de quelques secondes à quelques jours. Souvent pour mon propre usage, pour ne pas oublier quelque chose ou pour m’aider à mettre mes idées en ordre quand je réfléchis à un modèle ou une spécification technique. Mais aussi lorsque je travaille avec mon équipe, pour synthétiser graphiquement les idées de chacun.

Pour tout ça, l’outil high-tech qui fait fantasmer tous les geeks, c’est définitivement l’iPad d’Apple. Allié à une application comme Draft, on pourrait y voir le meilleur moyen de faire des croquis rapides et les échanger.

Ah, c’est vrai que ce genre de gadget fait envie. Mais est-ce vraiment nécessaire ?

Pour ma part, j’ai trouvé les deux outils qu’il me fallait : des “post-it” et une ardoise “Velléda”.

Des post-it

Tout le monde connait les post-it, ces petites feuilles adhésives repositionnables commercialisées par 3M. J’en ai utilisé de toutes les tailles : des minis (très pratiques pour coller des notes tout autour de l’écran), des « normaux » (qui s’adaptent à la plupart des besoins), des géants (vite abandonnés).

Maintenant, j’utilise exclusivement des post-it de taille rectangulaire (76×127 mm pour être exact). C’est comme un post-it normal, sauf qu’il est plus large. Pris verticalement, c’est idéal pour faire des listes : la largeur est convenable, et la hauteur − plus grande que pour un post-it carré − convient parfaitement.

Plus loin que la simplicité : la rusticité

J’ai déjà parlé du concept de simplicité sur ce blog. J’espère que tout le monde est convaincu des avantages que cela procure à tous les niveaux :

  • Une interface simple sera plus facile à comprendre et à utiliser ; elle sera plus ergonomique.
  • Un code simple sera plus facile à corriger et à faire évoluer ; il sera plus facile à maintenir.
  • Une procédure ou une méthode sera adoptée d’autant plus rapidement qu’elle sera simple à appréhender et facile à mémoriser.

Nous sommes d’accord, le «simple», c’est bien. Et comme d’habitude, c’est aussi le moment de dire que le «simpliste», ce n’est pas bien. Faire quelque chose de simpliste, c’est lorsqu’on recherche la simplicité aveugle ; quand on confond «en faire moins» avec «en faire le moins». Il faut parfois complexifier un peu un programme pour en simplifier l’ergonomie. Ou faire des concessions sur la simplicité d’une procédure si cela peut en augmenter l’efficacité.

Bref. Ce dont je veux vous parler aujourd’hui, c’est du concept de rusticité.

L’un des fondements du travail d’informaticien, c’est d’aimer la technologie, de se passionner pour l’avant-garde du high-tech, de chercher à connaître les technos du futur. C’est ainsi qu’on cherchera à mettre en œuvre des concepts ou des briques logicielles (ou matérielles) que nous ne maîtrisons pas forcément, pour le plaisir d’apprendre à les utiliser. Souvenez-vous ce que je disais sur la R&D : il ne faut pas confondre développement et veille technologique.

Sans aller jusqu’à faire de la recherche alors qu’on devrait faire du développement, on peut conduire nos choix en se laissant porter par des effets de mode. Quel est la techno «hype» du moment ? Quels sont les derniers «buzzwords» à connaître ?

En entreprise, les facteurs qui conduisent à un choix technologique sont multiples. La stabilité et la pérennité sont très importants. Ils le sont souvent plus que la performance ou le coût.
Ajoutez cela à la simplicité, et vous aboutissez à la «rusticité».

Une techno rustique, c’est quoi ?

Attention à ne pas comprendre de travers ce que j’essaye d’expliquer. Je ne suis pas en train de dire qu’il faut systématiquement utiliser des technologies antédiluviennes, au nom de leur rusticité. Moi je parle de “rusticité high-tech”, si je puis dire 🙂

Prenons un exemple au sujet des langages de programmation :

  1. Coder un site web en Fortran, ce n’est pas rustique, c’est débile. Votre site sera difficile à maintenir, vous aurez du mal à trouver des développeurs Web compétents dans ce langage, vous n’aurez aucun gain de performance par rapport à d’autres langages, et il vous manquera l’accès à un certain nombre de librairies très utiles.
  2. Par contre, une application de calcul scientifique distribuée sur un cluster pourra être codée en Fortran. C’est un choix très répandu : C’est un langage sans allocation dynamique, donc qui s’optimise très bien sur les architectures distribuées ; de nombreux scientifiques continuent à maintenir du code écrit en Fortran il y a 30 ans, sans avoir objectivement besoin de changer de langage ; réutiliser ce code est une bonne idée.

Un exemple concernant l’innovation fonctionnelle :

Kit de survie en entreprise

Contrairement à ce que le titre de cet article pourrait le laisser penser, je ne vais vous parler des situations conflictuelles que l’on peut rencontrer en entreprise. Je vais plutôt vous parler de quelques trucs qui sont facilement applicables, et qui peuvent faciliter les choses dans certaines situations. Ça vaut ce que ça vaut, mais ça peut vous sauver la vie (enfin, presque).

Diviser par deux

C’est une situation que nous avons tous connus : On discute avec une ou plusieurs personnes, chacun argumente dans le sens qui l’intéresse, et au moment où on veut exprimer nos propres idées, elles arrivent toutes en même temps. Au lieu de lister les points importants de manière intelligible, on délivre un amas de non-sens sans queue ni tête. Plus on s’en rend compte, plus on s’embrouille. Au final, quelqu’un d’autre captera la discussion pendant que l’on reprend notre souffle entre deux phrases, et tout le monde oubliera notre pathétique contribution.

Comment faire pour éviter ça ? La technique la plus simple est de systématiquement chercher à diviser nos idées en deux.
Si vous avez une idée en tête, mais que vous ne savez pas par quel bout l’aborder, essayer d’en distinguer deux facettes. Forcez-vous à y trouver deux aspects différents. Cela peut être les avantages et les inconvénients. Ou quelques enseignements liés à votre expérience sur le sujet, comme un “contre-exemple” qui apporterait un éclairage particulier. Prenez le temps de préparer mentalement votre «thèse / antithèse». Le but de la réunion sera de faire la «synthèse» à plusieurs.

Cela paraît débile, mais c’est une vraie méthode d’organisation de la pensée. Je connais une personne qui commence la moitié de ses phrases par « En fait, il y a deux choses dans ce que tu dis » ; c’est crispant à la longue, mais ça a le mérite d’éclaircir les idées de tout le monde quant au propos échangé.

Reconnaître les hypocrites

Tout le monde le sait : en entreprise, il y a des gens sympas et il y a des cons. On est prévenu et préparé à cela. Le problème, c’est quand on a affaire à des cons qui sont assez fourbes pour paraître sympas. Il y a plusieurs profils de ce genre :

Les connaissances informatiques de base

Au fil du temps, j’ai pu observer des lacunes techniques chez beaucoup d’informaticiens. On ne peut évidemment pas tout savoir ; l’informatique est un domaine très large, qui couvre des choses très variées. Mais il y a un certain nombre de connaissances basiques que vous devez absolument maîtriser si vous êtes informaticien.

Valeurs binaires standard

Il me semble absolument nécessaire de connaître de tête les plus importantes valeurs binaires.

Un octet, c’est stocké sur combien de bits ? Et un entier standard ?
Combien peut-on stocker de valeurs différentes en 8 bits ? Et en 16, 24, ou 32 ?

Réponses :

  • Un octet est stocké sur 8 bits. Un entier standard est stocké sur 32 bits. Un «short» est classiquement stocké sur 16 bits, un «long» sur 64 bits.
  • En 8 bits (sur un octet, donc), on a 256 valeurs différentes. En non-signé, cela va donc de zéro jusqu’à 255. En signé, cela va de -128 à +127.
  • En 16 bits (sur 2 octets), on a 65 536 valeurs. De zéro à 65 535 en non-signé ; de -32 768 à +32 767 en signé.
  • En 24 bits (3 octets), on a 16 777 216 valeurs possibles.
  • En 32 bits (4 octets), on a 4 294 967 296 valeurs possibles.
  • En 64 bits (8 octets), on a 18 446 744 073 709 551 616 valeurs.

C’est pas bien compliqué à mémoriser. Gardez juste à l’esprit les ordres de grandeur :

  • 1 octet => 256
  • 2 octets => 65 milles
  • 3 octets => 16 millions
  • 4 octets => 4 milliards
  • 8 octets => beaucoup (je considère que 18 trillions, ça fait trop grand pour être compté).

Mais pourquoi est-ce si important à savoir ? Après tout, on peut recalculer facilement tout ça. Oui, mais pour un informaticien, recalculer ça reviendrait au même qu’un géomètre qui se demande tous les jours combien il y a de centimètres dans un mètre…

Concrètement, ces valeurs ne servent pas forcément tous les jours, mais il faut être capable de les utiliser à bon escient. Si vous faites du développement embarqué, vous aurez sûrement besoin de calculer au plus juste l’utilisation de la mémoire ; et en codant en C, vous devrez choisir le type de vos variables en connaissance de cause. Mais ce n’est pas le seul cas où c’est utile.

Si vous êtes un développeur Web ou un DBA vous aurez à créer des tables dans votre base de données. Pour cela, vous devez connaître les types de données que vous pouvez utiliser. Si on prend l’exemple de MySQL, les nombres entiers peuvent être stockés dans des champs de type TINYINT, SMALLINT, MEDIUMINT, INT et BIGINT. Chacun pouvant être signé (par défaut) ou non-signé (en ajoutant UNSIGNED au type).
Alors pour stocker la taille d’un être humain, en centimètres, un TINYINT UNSIGNED sera sûrement suffisant. Hum… sauf si vous devez gérer les 4 hommes les plus grands du monde qui dépassaient les 255 centimètres. Certains choisissent alors la facilité et stockent tous leurs entiers en utilisant des INT. Mais pourquoi prendre 4 octets, là où la moitié suffirait ?

De la même manière, quel est le type le plus adapté à une clé primaire ? Sur 16 bits, ce serait un peu court ; c’est assez fréquent d’avoir des tables qui contiennent bien plus de 65 milles lignes.
Un petit truc pour y arriver, c’est de réfléchir en terme de rapidité de remplissage de la table : Si vous avez en moyenne une nouvelle ligne par seconde, une clé primaire stockée sur 3 octets (un MEDIUMINT UNSIGNED) se remplira en à peine plus de 6 mois. Si par contre vous passez sur 4 octets (INT UNSIGNED), vous pouvez tenir ce rythme pendant 136 ans. Est-ce vraiment utile de passer sur un BIGINT ?

Langage de script

Quel que soit votre domaine, quelle que soit votre plate-forme, quelles que soient les technologies que vous utilisez, vous ne pouvez pas faire votre travail efficacement si vous ne connaissez aucun langage de script. Évidemment, on peut toujours s’en tirer en mettant au point des «méthodes de contournement». Mais quelle perte de temps ! Cela revient à passer le baccalauréat scientifique avec une calculatrice « 4 opérations » ; c’est possible, mais c’est se mettre soi-même des bâtons dans les roues.