Meku a écrit 819 commentaires

C'était bien ça, j'avais essayé la version du 13 juillet. Merci.

Dans la listes des choses importantes, j'ajouterais quelques compétences qui me paraissaient évident mais qui en fait, ne sont pas partagées par tout le monde (certains cumulent l'absence de tous ces points) :

• Savoir se remettre en question, évaluer un peu son travail, prendre du recul, se demander ce qu'on aurait pu faire mieux (pour une prochaine fois). Certains n'ont pas du tout conscience qu'ils perdent du temps bêtement, ou qu'ils font n'importe quoi.

• Savoir évoluer (la suite logique de se remettre en question). Certains développeurs stagnent pendant des années avec des méthodes très inefficaces, et ne s'améliorent pas, comme s'ils n'acquéraient pas d'expérience.

• Être un peu autonome, débrouillard. Savoir chercher par soi-même sur le net quand on a un problème technique (notamment les problèmes de langage ou d'API). Il y a des gens qui sont incapable de se démerder d'un problème de ce genre, d'aller sur Internet (même quand on leur dit !), et qui vont bloquer pendant des jours (c'est peut-être plus le cas de certains « vieux » ?).

• Savoir faire de la conception logicielle. Sans même entrer au niveau de la méthodologie ou des langages de conception, il y a des développeurs qui ne savent ni concevoir, ni comprendre une conception (les relations entre les modules, les classes, etc.). Personnellement, je me demande comment on peu espérer être efficace ainsi (c'est un peu comme être analphabète). Autant sous-traiter offshore…

• Ne pas avoir peur du code. J'en ai vu qui vous font un ulcère dès qu'il s'agit de modifier une ligne de code, dans leur propre code en plus (remarque moi aussi je suis au bord de l'ulcère quand je lis leur code :D). Et je ne vous parle même pas d'aller lire et explorer du code nouveau… Si on a peur du code, ou si on ne l'aime pas, ben on ne fait pas du développement.

J'ajouterais que ça ne couvre pas tous les problèmes, notamment tout ce qui est résultat erroné. Exemple : lors d'un traitement, le logiciel affiche « Foo » alors qu'on attendait plutôt « Bar ». Ça n'a rien d'un bug technique, mais plus de logique. Pour détecter ces bugs, il faut bien tester !

Je n'écris pas de tests unitaires. […]
Seulement, je n'ai pas le temps. Le fait est que je factorise mon code le plus possible, ce qui fait que les bugs sont très vite détectés, et donc corrigés, lors de l'utilisation courante du code incriminé.

Pourtant ça en fait gagner, du temps ;-)
Bien sûr, au début quand on n'est pas habitué à écrire des tests, ça prend un certain temps, c'est comme pour tout. Mais un bug découvert en développement coûte moins cher que s'il est découvert plus tard (en validation ou chez le client).

Quand on développe, on ne pense pas forcément à tous les cas qui peuvent survenir (cas nominaux comme cas d'erreurs). Par contre, quand on écrit des tests, on y pense plus facilement vu qu'on va essayer de retourner le soft dans tous les sens (on essaie d'imaginer toutes les combinaisons possibles en entrée). Et donc on peut revenir sur son code et colmater les cas oubliés. Sans compter les trucs dont on se dit « c'est trivial, ça ne peut que marcher » puis l'on se rend compte en testant que non, c'est quand même buggué… Maintenant, je considère carrément que du code non testé c'est du code qui ne marche pas (et j'ai déjà la ceinture et les bretelles grâce à Ada).

À une époque, sur un projet, on a tenté la production rapide sans tests (on code un truc puis on le valide immédiatement en plateforme intégrée), mais on a fini par abandonner, ça coûtait plus cher au final : régressions dans tous les sens (« ah merde, ça touche ça aussi ? »), tests à la con non passés car plus difficiles une fois tout intégré, qualité du soft moins bonne. Je faisais notamment beaucoup de factorisation de code aussi ;-)

Quand tu as un soft avec énormément de fonctionnalités, une bonne batterie de tests unitaires c'est redoutable contre les régressions. Ça me permet de coder plus vite, puisque je passe moins de temps à tout vérifier 3 fois avant de passer le bulldozer dans le code. Je vérifie une fois, puis si je casse des choses, les tests me le révéleront très vite.

Mais… ? Tu ne leur fais pas résoudre quelques expressions C++ et constructions du langage ambiguës durant ton entretien ? Comment savoir si ce sont des vrais bons sans ça !?

Je partage ta liste de points importants.

Aujourd'hui je sais de quoi il s'agit, mais à la sortie de l'école (il y a 5 ans), je n'avais jamais vu aucun de tous les points que tu as cités (sauf le travail en équipe à la limite, en projet école, ou TP si on veut). Je n'ai eu aucune formation là dessus durant mes études et je le déplore. J'ai dû tout apprendre sur le tas :-/

Aujourd'hui ça me parait même incroyable que ces points ne soient pas abordés dans un cursus informatique (au moins pour une partie, je pense notamment à la gestion de version et l'écriture de tests). C'est pourtant si important !

J'ai testé le dernier live-CD de Rebecca Black OS, et j'ai l'impression qu'il ne fonctionne pas comme prévu chez moi…

Au boot, j'arrive sur un écran avec une barre en haut, et les boutons « Login », « Switch User » et « Shutdown ».

Et à part ça, je ne peux rien faire, rien lancer d'autre. Lorsque j'ouvre une session, je reviens sur cet écran (comme si ça avait crashé).

Est-ce que quelqu'un a essayé et a une autre expérience que moi ? J'ai une carte intel intégrée (i945 GM).

(n'étant pas français, je n'étais peut-être pas le public visé non plus).

Tu es Belge ?

-> []
Désolé /o\

3.11 devrait être un numéro de version prohibé. Il faudrait directement passer de 3.10 à 3.12. Comme le numéro de chambre 13 dans certains hôtels, ou le siège n°13 dans les avions, entre autres /o\

Faudra songer à porter le coup fatal un jour.

Et le GPS dans l'alimentation des iMac alors, c'est du poulet ?

Faut pas utiliser d'iMac non plus.

Pour ceux qui ne connaissent pas, essayez de tester un doublage à la polonaise :) En fait c'est comme un mec qui lirait les sous-titre à ta place, très intéressant ! Je me demande si cette technique est employée ailleurs qu'en Pologne.

C'est d'ailleurs toujours la même voix masculine, pour tous les films, et pour tous les personnages (hommes, femmes, enfants). Et sans intonation surtout. Genre « AAAAAAAAAAAAAHHHHHHHHHHHHHH !!!! » serait doublé en « ah. ». Du moins, c'était comme ça à l'époque où j'en ai vu (il y a 15 ans), mais ça n'a probablement pas changé. Les Polonais y sont habitués et ça ne les choque pas, par contre ça les fait marrer d'entendre nos doublages. Ils ne sont pas habitués à entendre des acteurs Américains parler une autre langue avec une autre voix.

C'est marrant, à chaque fois que j'entends parler de cette technique de doublage, c'est sur la Pologne. Du coup je me demande aussi quels sont les pays qui ont utilisé ce procédé. À mon avis pas mal de pays de l'est ont dû faire pareil, ça coûtait bien moins cher qu'un doublage complet.

Je n'ai pas regardé beaucoup de films doublés comme ça. Ça a toujours été un peu dur de s'y faire, mais je crois qu'il m'est arrivé parfois de ne plus m'en rendre compte au bout de quelques minutes (quand on est plongé dans l'histoire) ; comme quoi ça marche ;-)

Une fois j'ai vu un Louis de Funès comme ça (les gendarmes je-ne-sais-plus-quoi). Au bout d'un moment mon cerveau avait réussi à filtrer la voix du doubleur, et je n'entendais plus que la VF. Du coup je me demande si monotonie de la voix n'est pas une technique, pour ne pas masquer l'intonation de la VO, et laisser le spectateur profiter de la bande son originale (et gérer le mixage intonation/doublage lui-même).

Rage quit en représailles, suite à l'affaire DLFP ?

=> []

Ils ont reçu une nouvelle mise en demeure ? /o/

Oui mais bon, ils ont dû faire :

$ whois linuxrf.org
NOT FOUND

[…] vous appelle linuxrf…

Ça explique pourquoi ils n'ont pas trouvé les mentions légales /o\

tu es un chef, un patron, un manager (à lire d'un air ironique).

Dans ma boite maintenant, le terme c'est « leader ». « Manager » c'est trop has been.

Oui effectivement, c'est plutôt ça (j'ai fait un test rapide avec 4.7.2).

Eh ben, on a l'impression de repartir de zéro dans le domaine des pilotes graphiques… C'est un peu triste quelque part.

Du coup je me demandais, tous ces constructeurs qui ne veulent ni publier de spec, ni fournir de pilote pour Linux, pour quel(s) OS ils distribuent leurs pilotes alors ?

À condition de ne pas avoir besoin de déménager (cause emploi par exemple, ou séparation, ou trop petit pour agrandissement de la famille, …).

Auquel cas, tu peux te retrouver à devoir remettre au pot pour obtenir ton nouveau logement (si tu changes de région, ça peut être plus cher, ou si tu prends plus grand).

Ton cas est idéal quand tu sais que tu as atteint une taille de logement suffisante pour tes besoins, et que tu n'auras pas à bouger (retraite ?)

Pour l'occasion, je vous livre l'adresse d'un vestige de l'ancien Web, le Web 1.0, voire Web 0.95. Il vit encore, ce n'est pas un fossile (dans le code on peut voir une trace de news désactivée pour la bonne année 2013), c'est une sorte de dinosaure ayant traversé les âges sans mutation, une sorte de monstre du Loch Ness :

http://www.gardiens-concierges-employes-immeubles-syndicat-defense.fr/

Au boulot j'ai un gcc 2.8.1 (mars 1998) avec lequel on compile en statique (pas le choix, GNAT 3.14 ne savait pas encore faire des bibliothèques dynamiques) et j'avais tenté l'expérience : il fait bien le tri des symboles utilisés par le programme.

Celles qui ont ces interrupteurs sans l'indicateur lumineux, oui :(

Je suis d'accord. Le rouge/vert fonctionne est un symbole assez fort dans mon cas, alors que le orange/gris pas du tout (le orange se rapproche du rouge, d'où ma confusion).

Mais encore faut-il que les couleurs soient parlantes.

Ça marche à peu près avec ma souris sans fil (vert ON, rouge OFF, heureusement que je ne suis pas daltonien…) parce que le code couleurs est assez « fort », mais il a fallut quand même que j'habitue mon cerveau.

Dans le cas d'Ubuntu avec son thème orange, ça saute pas à mon cerveau que orange c'est ON. Et l'autre couleur, je ne la vois pas si l'état est déjà sur ON, donc je ne peux pas comparer à la volée.

Avec la multiprise, bouton allumé/éteint, pour un état électrique c'est quand même bien plus intuitif. C'est à peu près le seul cas que j'arrive à trouver intuitif dans la vie réelle pour ce type d'interrupteur.