Meku a écrit 812 commentaires

Ça me rappelle l'époque de mes études (il y a 10~5 ans). On avait régulièrement des présentations à faire. La vaste majorité utilisait PowerPoint, ou OpenOffice Impress (moi aussi au début). Et à chaque fois c'était une galère monstre le moment venu de la présentation : incompatibilité entre le fichier du présentateur et le PC sur lequel tournait la présentation (MS Office pas installé ou mauvaise version, rendu différent, etc.). Ça rajoutait bien du stress au début de la présentation…

Au bout d'un moment, une partie des étudiants ramenaient carrément leur PC portable pour afficher la présentation, comme ça ils n'avaient plus de soucis de compatibilité avec leur fichier. Mais c'était une nouvelle galère, car il fallait relier le portable au vidéo projecteur, et donc plein d'emmerdes à nouveaux (autant sous tous les OS, Windows, Linux, MacOS).

Alors qu'au final, le plus sûr et le plus simple était de faire un export en PDF. Il y avait toujours un lecteur Adobe Reader sur les postes de présentation (au pire, on se ramenait avec un lecteur pdf portable et léger en plus de sa présentation). Mais peu de personnes s'en sont aperçu : PowerPoint était trop ancré dans la tête des gens (ou sa copie OpenOffice Impress pour les pauvres) : c'était l'outil (l'unique) pour fabriquer et afficher des présentations. Le formatage des cerveaux était tel que peu de gens se sont posé la question d'une alternative, alors que pourtant PowerPoint était associé à un gros lot d'emmerde et d'incertitudes.

Beamer a été salutaire pour moi les dernières années d'études.

Le PPA Kernel de Ubuntu est très rapide à proposer les dernières versions des noyaux :
http://kernel.ubuntu.com/~kernel-ppa/mainline/

Au zoo de La Flèche aussi (Sarthe)

http://www.zoo-la-fleche.com/listes-des-animaux-page-virtuelle/panda-roux

Cela mériterait bien un comparatif entre ces deux OS !

Ouais, une sorte d'asile quoi.

Objet : H F, C de D J / ASSOCIATTION LINUX (M Verité) (sic)

Après LinuxRf, DLFP devient tout simplement « Linux » \o/.

Sans parler de l'associattention…

Je me rappelle de ce sentiment indescriptible quand je me suis rendu compte après des heures de déboggage que les tabs et les espaces étaient interprétés différemment dans le Makefile. Ça doit ressembler à ce que ressent la petite fille quand elle se rend compte qu'il y a un ogre ou une soricère dans la maison en pain d'épice et qu'elle est coincée dedans.

C'est parce que bien avant d'intégrer Guile, Make était une extension du langage Whitespace !
---> []

Un aperçu du carnage :

/o\ \o/

Oui m'enfin tu ne vas pas dire à tous les utilisateur de ton appli d'aller modifier ce paramètre du noyau eux-même…

Compatible Windows !

Ah cool ! Important pour fabriquer les botnets à large échelle, ça ! /o\

Le plus con c'est quand la boite (ou une division de la boite) travaille dans le domaine de la sécurité informatique, et filtre justement tous les sites nécessaires aux employés pour faire leur travail…

Moi en faisant des recherches techniques, il m'arrive souvent de tomber sur des sites filtrés car rangés dans les catégories : « institutions scolaires », « matériaux éducatifs », « recherche d'emploi » (man job… non même pas, c'était pour un truc obscur en C++ en fait), voire « mauvais goût » (pourtant je ne travaille pas sous Windows).

Heureusement, la plupart du temps je peux poursuivre en cliquant sur le bouton « CONTINUER SUR LE SITE NAZI ».

Le plus drôle c'est quand c'est une partie de l'Intranet qui est catégorisée « site dangereux » (et là, on peut pas passer outre le filtrage).

Reste à voir si cela va donner quelque chose de stable et utilisable, Wine n'étant pas le pied de ce côté.

Que veux-tu dire par là ? Personnellement, je suis plutôt impressionné de tout ce qu'on peut faire tourner avec wine aujourd'hui, et de façon stable.

Mais on s'en fou du dopage ! C'est carrément négligeable face au tourbillon !!!

On pourrait construire une dizaine de piscines indépendantes de 3x50m en parallèle, chacune avec son tourbillon.

C'est vrai, d’où l’intérêt de concevoir en fonction des testes pour ne jamais avoir ce genre cas. Ce cas veut juste dire que tu as une surface énorme de bug potentiel, et je ne parle pas de surface d'attaque de sécurité.

C'est vrai. Depuis que je code en faisant beaucoup de tests, ma façon de concevoir des logiciels a évolué dans ce sens. Il faut aussi parfois convaincre les architectes systèmes, qui ne s'en rendent pas forcément compte vu qu'ils n'écrivent pas les tests.

Concernant vos tests, vous faites de la revue de code de test ? Les tests (non unitaire) sont écrit par des personnes différentes ? La couverture est bien vérifié ?

Hélas, non, on n'a pas de revue de code (code de test ou non). C'était prévu à l'origine, mais bon… C'est un des premiers trucs qui saute dès qu'on a des retards ou problèmes de budgets. Il faut aussi des gens capables d'auditer du code ou des tests.

Certains tests de pré-intégration ont été fait par des personnes qui ne codaient pas les logiciels testés. Je suis un peu mitigé sur le résultat (mais c'est peut-être déjà mieux que si ce n'était pas le cas).

La vérification de la couverture… C'est dans la TODO list.

Il faut trouver un juste milieu, ça dépend des types de logiciels je pense.

Les tests couvrant de haut niveau peuvent parfois être vite limités par la combinatoire des cas possibles (qui explose). Dans ce cas, on peut couvrir en haut niveau les cas nominaux et les cas d'erreur courants, et laisser les tests de plus bas niveau couvrir les autres cas d'erreur.

Le choix du niveau du test (bas ou haut niveau) peut aussi se faire en fonction de la complexité de mise en oeuvre du test. C'est parfois bien plus facile de stimuler (ou simuler) une erreur bas niveau en unitaire, plutôt qu'en test de haut niveau ou test sur environnement intégré (par exemple, des cas de race condition).

Sur le projet sur lequel je travaille (un système distribué), on a trois niveaux de tests :
- test unitaire bas niveau : on test les rouages, les algos, les traitements des données, …
- test de pré-intégration : on test le comportement du composant logiciel, s'il répond bien aux entrées, sans forcément regarder dans le détail les données qui sortent. C'est un test de plus haut niveau déjà.
- test de validation : tous les composants sont intégrés, on test alors qu'ils communiquent bien ensemble (interfaces), ainsi que les cas nominaux en partant du bas de la chaîne jusqu'au résultat final. Les cas d'erreurs peuvent par contre être extrêmement chers à mettre en place.

On a bien sûr pas la même couverture sur chacun de ces niveaux de tests.

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).