ckyl a écrit 3877 commentaires

J'ai des cas de figure où acheter le matos pour pouvoir

Je ne répondrais pas à la Zenitramerie qui consiste à trouver les contre exemples.

Un autre cas de figure est où la criticité de la chose n'est pas importante

Ce n'est pas vraiment une question de criticité. Pour les trucs critiques les procédures et le type de test sont différentes et complémentaire. C'est d'ailleurs pour ca que la QA, les test engineers et le release engineering existent.

le time to market (vaut mieux un truc buggué à l'heure qu'un truc non buggé dans un marché déjà saturé par les autres)

La troisième version c'est il vaut mieux un truc qui marche maintenant avec une feature de moins. Plutôt que d'accumuler une dête technique monstrueuse sous le pretexte du TTM.

D'ailleurs ton TTM il s'écroule après 6 mois quand une équipe passe 50% de son temps à résoudre ses problèmes et faire du support pendant que l'autre continue au même rythme voir devient plus véloce. Les deux ont livrés à temps pourtant…

C'est mon constat ayant bossé sur des codes de toute taille et dans quelques domaines où les tests sont un peu plus compliqués que dans la plupart des domaines (systèmes distribués, réseaux, grosse appli JS, moteur de recherche, big data etc.).

Et j'ai aussi eu l'occasion d'experimenter la chute de vélocité à moyen terme et l'empilement des BR d'une équipe quand on a joué la carte du "trop compliqué à tester" pendant quelques mois. On a passé un/deux mois à faire le taff qui aurait du être fait, plus longtemps que si on l'avait fait pendant le dev, et c'est reparti…

Quand je code tout seul pour le fun c'est étrangement la même chose.

Pas pour rien que gmail (par exemple!) a été en beta pendant des années

Tu parles encore d'un truc dont tu ne connais absolument rien. T'as une idée de comment fonctionne l'engineering et la code base chez Google ? Tu as des fait sur gmail en particulier ?

genre un Linux ça a combien de RC parce que tes tests unitaires n'ont pas été suffisants?

AFAIK Y'a 0 TU dans Linux… Au passage prendre Linux comme exemple pour la gestion de projet est souvent une très mauvaise idée.

Sans compter le test qu'il faut pour débugger, car le code est juste mais le test est faux.

C'est étrange. J'ai du bosser sur quelques millions de ligne de codes et les seuls tests que j'ai eu a debugger sont ceux de gens qui soit disaient que c'était compliqué de tester, soit qui s'en foutait et soit qui pissait du mauvais code. En se penchant dessus on fait quelque chose qui juste marche. Dans les autres cas, la seul raison d'y toucher était un changement fonctionnel (et c'est à ca que ca sert).

Bref, je tiens juste à signaler que oui, c'est important, mais… Ca dépend, en fait. De beaucoup de choses (taille ou criticité de la cible ou des délais ou…)

Comme toujours il y a quelques raisons valides. Et comme souvent les gens utilisent ces quelques mais pour se convaincre qu'ils sont dedans et couper toute reflexion plutôt que de réfléchir à pourquoi c'est difficile et trouver des réponses efficaces. Non la couverture n'est pas un objectif. Non le but n'est pas d'appliquer bêtement un principe. Le but c'est d'ameillorer la qualité, la vélocité et donc te permettre de coder des nouveaux trucs plutôt que de débugger ou de passer 6 mois sur 12 en recette.

En même temps cette image ça doit faire 3/4 ans qu'elle tourne. Depuis le temps la question ne doit plus se poser ;)

Depuis quelques années, c'est le fait d'améliorer la parallélisation qui permet de continuer à monter en performance.

Qui peut se faire au niveau de la tâche elle même ou du job ;)

Le réponse qu'on t'a faite était très juste. Si par nature tu as un parallélisme au niveau du job et que tu cherches à maximiser la bande passante, cas que tu décrivais initialement, il ne faut pas aller chercher les emmerdes à le faire au niveau de la tâche. Tu fais de l' embarrassingly parallel. Si ton scheduler tient pas 50000 tâches, change le, fixe le ou fait une pauvre glue producteur-consommateur autour. C'est la bonne solution. Pas de complexifier le métier, introduire des bugs et se taper un speedup sous-linéaire alors qu'il pourrait l'être.

Cela dit, comme souvent, on ne peut pas te contredire car tu passes du coq à l'âne: De "J'ai 50000 images indépendantes que j'ai pris avec mon gros kiki et je veux minimiser le temps de traitement total" à "J'ai une tâche qui demande du parallélisme et je veux du temps réel".

Ça na rien de la théorie, c'est très pratique et pragmatique.

Sans tests:
- Tu livres de la merde (je trouve toujours au moins un bug à chaque fois que j'écris un test)
- Tu n'as pas à te poser la question de ce que tu es en train d'écrire. Donc tu écris un truc pourri et non spécifié
- Tu fais un gros doigt d'honneur au mec qui reprendra ton code qui ne saura jamais ce que c'était sensé faire
- Tu empêches les gens d'ajouter des tests par la suite par ce que tu codes pas testé est pas écrit pour être testable
- Tu n'as aucun moyen de traquer tes régressions
- Tu plombes la productivité de ton équipe en empêchant de détecter les régressions.

Tu ne perds pas de temps à écrire des tests. Ce que tu peux faire par contre c'est accepter de livrer de la merde. J'appelle pas ça gagner du temps mais plutôt, grappiller quelque heures maintenant pour perdre des semaines ou des mois dans pas longtemps et pour toujours. Ça coûte toujours beaucoup plus cher de faire les tests après.

Pour le moment je pense que je peux encore compter sur mes doigts le nombre de cas ou l'absence de test pouvait se justifier. Par contre il me faudrait beaucoup plus de doigts pour compter le nombre de fois ou on a essayé de le justifier et on s'est mangé grave ensuite. Être un petit projet ou tu codes tout seul ne change rien la dessus.

Y'a un peu une raison si toutes les équipes finissent fatalement par mettre "unit test", "fonctional test", "code review" et "QA review" dans leur definition of done. Pouvoir encore penser que ça coûte cher me fait juste peur en fait.

C'est dispo quelque part ?

AFAIK aucune chance vu le conflit d'intérêt, employeur… IBM ;)

J'indique juste qu'il y a une solution officielle (jamais essayée) et qu'il est possible de se le faire avec un effort raisonnable si ça le fait pas.

C'est pas une question de taille d'équipe ou d'outil. C'est une question d'organisation de son travail.

Si tu n'arrives pas un avoir un historique propre c'est que tu t'es laissé embarqué et que tu es en train de faire n'importe quoi. À chaque fois que je me retrouve à faire des choses que je ne voudrais pas (et c'est bien trop souvent) c'est que j'ai merdé lors du dev en faisant tout et n'importe quoi.

C'est comme les tests, ça coute pas plus cher bien au contraire… Ça te force à réfléchir à chaque incrément, à bien le délimiter, le spécifier et le tester. Si tu passes cette étape, t'as l’impression d'aller plus vite mais tu fais juste plus n'importe quoi.

Normalement il y a un connecteur officiel d'IBM. Aucune idée de si ca demande une configuration server side (je pense pas) ni du coût du bordel.

Autrement en sortant ton éditeur de code y'a moyen. Des devs de mon équipe s'étaient motivés à le faire et ça marchait (mail, cal, contacts). Je sais pas si un projet libre existe, mais si y'a des motivés c'est jouable.

Bon en même temps on utilise Lotus Notes, donc impossible d'interagir avec quelque chose d'autre

Tu peux utiliser Outlook ;)

Pour les obsédés de la pureté de l'historique et autres révisionnistes

Faire des historiques propres c'est avoir compris:
- Que l'on écrit le code une fois mais qu'on le lit et maintient pendant 10 ans après.
- Qu'un code ca se fait toujours relire avant d'être mergé. Et c'est faire preuve de respect pour le relecteur et surtout ca permet d'attraper plus facilement les erreurs (les changements ont une sémantique). Tu valides chaque changement. Puis l'enchainement des changements.
- Qu'un code ca se fait merger dans plein de branches (maintenance & co). Un historique propre et simple ca permet de pas partir à la chasse aux cherry pick ou de devoir detricoter un gros commit (par ce que l'absence de rebase poussent les gens à faire des gros commits).
- Qu'un code sera maintenu par quelqu'un d'autre et qu'il te pourrira quand il cherchera un bug ou cherchera si un changement était voulu.

Les obsédés sont juste des gens qui font leur boulot quoi… A ton avis pourquoi la plupart des projets libres fonctionnement par patch atomiques dont tu publies les révisions successives jusqu'a ce que ca soit mergé à un moment ?

Ce que je veux dire, c'est que ce projet montre que les émulateurs de terminaux ne sont fait que pour afficher du texte, et qu'il serait peut être temps d'avoir la possibilité d'afficher des images, de lire du son, etc..

Alors qu'on nous rabache qu'un navigateur web n'est pas fait pour jouer des videos ou lire des sons et que c'est suffisant de cliquer sur un lien qui va ouvrir une ouvrir une application ?

T'es pas un peu fou ?

C'est la même justification et solution que bzr, et ca explique aussi pourquoi tout le monde trouve bzr improductif (bon y'a pleins d'autres raisons aussi).

Tant que c'est local, je veux pouvoir réordonner, fusionner, modifier, supprimer mes commits. Ca n'a aucun sens de:

1. Se tapper des historiques pourris type: "Commit 1", "Oups ajout du fichier manquant", "Commit 2", "Oups correction d'un bug introduit par commit 1". Quand toutes ces étapes ont été attrapées avant que le code soit publique.

2. Perde le découpage des commits (si tu sors le diff de ta branch pour mettre à plat comme recommande certains SCM. Sisi ! ).

Ton code avant de passer publique, il passe en code review. Avoir un historique propre ca permet de faire des codes review simples. Et pouvoir modifier ses commits ca permet d'updater facilement ses patchs suite à la code review.

Je ne vois pas pourquoi tu as été inutilisé alors que c'est particulièrement vrai.

Le rebase local, et ce qui gravite autour, est LA fonctionnalité qui booste le plus la productivité d'un développeur et la propreté de la base de code.

À choisir il vaut souvent mieux un dépot SVN avec un client local type git qu'un DCVS qui n'offre aucune facon simple et rapide de travailler ses commits et d'itérer son dev.

"Le rebase c'est pourri" c'est le genre de chose qui quand tu les acummules font que bzr est presque une blague.

Il y a surtout le trou entre l'algorithme est correct et l'implémentation est déterministe. Le trou étant: l'implémentation fait ce que l'algo dit. Tu peux avoir un défaut d'implémentation totallement détermiste, ca va même être générallement le cas en dehors du C.

Si tu as un peu de temps tu pourrais faire la même chose sur le code troué de NetBSD ? À vue d'oeil en regardant le patch il est pas impossible qu'un analyseur statique ne lève pas grand chose.

Faire une proposition ferme à l'aveugle à l'ensemble d'une promo ca fait surtout blaireau, incompétent et donne une idée de la qualité du recrutement.

les élèves seront placés dans des start-ups innovantes et ambitieuses à des postes de lead développeurs, directeurs techniques et architectes web

Voilà j'ai pas d'autre mot qui me viennent que LOL.

Professionnellement…

Tres pratique, un bon commercial te rappelle rapidement pour te demander de quoi tu parles parce que la il ne voit pas

Le bon commercial il ne prêtant pas connaître quoi que ce soit à l'informatique. C'est pas son job.

Il te reçoit pour comprendre grosso modo ce que tu fais, il te montre ce qu'il pense pouvoir te correspondre, il te laisse sélectionner les cibles, il te laisse faire ton CV pour celle-ci. Il n'envoit jamais un CV que tu n'as pas validé, et n'envoit rien ni ne contacte jamais personne sans te prévenir.

C'est rare mais ca existe…

Le plus triste c'est les boîtes qui laissent passer ca alors que c'est très simple à regler. Si ils bidonnent une fois, ils placent plus jamais un mec en entretient… Simple et efficace.

C'est ce qu'a fait OVH, qui après peut se permettre d'embaucher localement le gens qui n'ont par exemple aucune envie de s'enterrer à Paris

Oui tu mises sur la deuxième partie de la population dont je parlais: attirer les talents du bassin local. Par contre tu prends le risque de ne pas pouvoir recruter en dehors de ce bassin. Accepter un job pour eux revient à devoir déménager dans une région où tu es sur de devoir déménager dès que tu pars de chez eux. Hors tu sais très bien que tu n'y finiras pas ta carrière.

Pour les gens sans aucune attache ca ne pose aucun problème. Ceux qui ont quelques valises sous les bras (gosses, emploi de conjoint etc.) auront du mal à se faire aspirer préférant pouvoir rebondir plus facilement. Ne pas oublier que les bons quand ca leur plait pas, ou qu'ils s'ennuient ils se tirent rapido…

Hors OVH, l'avantage d'Internet, c'est que tu peux développer de partout à travers le monde.

Pour notre exemple précis c'est du gros pipeau. La plupart des boîtes, dont OVH, veulent garder leur R&D dans leurs bureaux. Pour notre exemple si ils veulent du monde la condition ce que les mecs soient près à venir à Roubaix.

Voilà pour en revenir au sujet initial tu peux pas avoir le beurre et l'argent du beurre. Les bassins d'emploi ont des contraintes, les entreprises perdues en ont d'autres.

Si tu cherches des bons il faut comprendre où ils sont actuellement, pourquoi et ce que tu peux leur offrir pour qu'ils viennent chez toi plutôt qu'ailleurs. Donc oui c'est pas facile et long à recruter. Mais souvent il suffit de regarder les propositions pour vite comprendre: il doit manquer autant de talents que de propositions acceptables…

Évidemment par définition les bons c'est plus rare que le reste.

Maintenant je constate deux choses:
1- Ceux qui ont choisi leur boulot en premier se sont presque tous tirés de France. Et pour une bonne raison.
2- Ceux qui ont choisi de garder leur localisation moisissent hors des 5/10 bassins les plus attractifs du monde, et attendent uniquement qu'une boite intéressante s'implante.

Les 1 tu ne pourras les recruter que si tu t'allignes sur l'interet du projet, le salaire, et sur le bassin d'emploi. En France ca va être ces deux derniers le problème. Les hauts salaires de dev sont bien en deca de ce que tu trouves ailleurs. Et Paris est surement le seul bassin attractif (lire tu retrouveras un taff identique facilement).

Les 2 il y a un énorme vivier, c'est même pas cher. Tu peux l'exploiter mais personne de 1 ne voudra venir. Regarde OVH à Roubaix. Qui va volontairement aller s'enterrer là bas ?

Maintenant si les startup de Londres arrive a se trouver des bons devs et mais pas les Francaises il faut se poser des questions non ? MAintenant dans tous les cas c'est pas 42 qui va les former.

justement parce qu'il y a de la valeur que c'est plus difficilement délocalisable

Et c'est exactement ce que je dis. Le seul truc qui nous tiens dans la course c'est la qualité de l'éducation.

Bof, c'est donc mieux d'en faire des chomeurs maintenant, curieux raisonnement.

En faire des chomeurs ? J'aimerai savoir pourquoi ?

42 a vocation à former des dev pour des starts-up, c'est ça faire de la valeur.

Oui enfin pour avoir une petite idée de ceux que recrutent les startup qui brassent du pognon et de qui elles recrutent, j'ai envie de dire que le profile formé à la pratique ca va pas le faire longtemps. Enfin pas pour celle pour qui l'informatique fait rentrer le pognon.

Quand à tes histoires sur le marché ultracompétitif, il faut que tu comprennes qu'un pays ne peux pas avoir que des ingé.

Je ne généralise rien du tout. On parle d'une école particulière qui nous sort un "ouaish en 3 ans sans aucun préalable on vous forme des meilleurs éléments qu'un cursus universitaire en 5/8". Le seul truc qu'ils oublient c'est qu'ils ne visent pas du tout la même chose. Le discours des lascars est très clair depuis des années, il y a certains types de poste qu'ils ont du mal à pourvoir, ou pas au prix qu'ils sont prêt à mettre et ils donc veulent former pour. C'est "louable" en soit.

Maintenant là ou est l'"anarque" c'est que ce n'est pas du tout sur les postes ingé/dev de haut niveau qu'ils ont ce problème. Alors leur com pourrait faire croire que c'est ca qu'ils forment. Non ils ont des besoins précis sur des postes ou des technos. Après chacun fait son choix et investi dans ce qu'il croit bon pour lui en connaissant les conséquences et perspectives.

Sur ! Il vaut mieux que les boulangers se réunissent pour faire une école où on apprend à vendre du pain que d'apprendre le commerce !

Pourquoi spécialiser les gens en interne quand on les paient des clopinettes en stage alors qu'on peut le faire pendant 3 ans avant ? Et pourquoi vouloir leur apprendre plus que ce dont on a besoin ?

Personne n'a dit le contraire. Mais l'expérience montre qu'il vaut mieux viser les emplois à forte valeur ajoutée non ?

L'informatique va suivre exactement le même chemin que les autres industries au fur et à mesure que les compétences vont se répendre sur la planète. Et il n'y aucune contrainte physique.

Former que des techos, c'est d'une part un énorme risque de former nos chomeurs de dans 10/15 ans… D'autre part les gens qui innovent et font de la valeur ils leur faut en général un peu de culture. Notre marché est ultra-compétitif.

Question bonus: En quoi ça prouve quoi que ce soit sur la qualité effective d'une source aléatoire ?

Tu nous parles de comportement indéfini. Mais tu peux très bien avoir un comportement défini et totalement pourri. Si tu remplaces le code réel par le code de rand(3), il passe ton test ou pas ? ;)

Si on est développeur et qu'on atteint la quarantaine, quelle différence fait une spécialisation plus ou moins grande qu'on a pu avoir lors de ses études?

C'est pas une question de spécialisation, c'est une question de connaissance et de culture servant comme base à notre métier. Personne ne veut du vieux techos pour pisser du struts. Pourquoi l'embaucher et le payer plus cher alors qu'un jeune sorti de l'école est moins cher, plus performant, plus malléable et plus soumis ?

Le senior ça se justifie si tu as la culture et que tu as emmagasiné des compétences et de l'expérience au cours de ta carrière. T'as fait 10 ans de PHP planqué ? Cool, ciao.

Maintenant les gens qui recherchent des techos avec 10+ d'XP, cherchent des gens très compétents. Et pour être très compétent il faut avoir de solides bases en CS en plus d'être bon en technique et d'avoir emmagasiné de la bouteille. Dans plein de domaines avoir un peu de maths et de physique ça aide aussi. Et hors personne extra-ordinaire, toutes ces bases si tu ne les as pas à la base tu ne vas pas les découvrir. Tu vas rester dans ton vase clos.

J'ai l'exemple d'une boite, qui pour simplement accéder aux entretiens techniques te file un problème à résoudre. Pour être grossier, il faut identifier qu'on peut réussir à transformer en problème du sac à dos, comprendre ce que ça implique, choisir une solution pour l'implémenter, la discuter, faire l'implémentation la plus performante possible et expliquer sa solution et en faire l'analyse. Si on te file ça, c'est par ce que ton métier c'est ça. Pas uniquement faire de la glue d'API. Sinon je prends un stagiaire ou un indien.

C'est con mais c'est pour ça que je ne mise pas cher sur quelqu'un qui n'a eu que des projets au cours de sa formation. Finalement si tu es motivé tu peux presque retirer toute la partie pratique des études, tu n'auras aucun problème pour l'acquérir par toi même. Par contre le reste tu es comme un con, c'est beaucoup plus difficile à aller chercher. Les trucs qui finalement me servent le plus de mes études, ce sont des cours ou je n'ai pas touché un ordinateur, ni fait un projet.

Comme disait un excellent prof de réseau, si vous voulez savoir comment fonctionne tel protocole aller lire la RFC et une implémentation; moi je vais vous expliquer pourquoi, son histoire et ce qui en découle…

Bha l'ambition de l'école me semble clairement affichée. D'ailleurs le discours est cohérent avec ce que disent les gens en photo sur le site depuis des années: On veut pouvoir embaucher facilement des techos prémachés exactement pour ce dont on a besoin. Des techniciens; jetables, pas cher. Ils feraient mieux d'aller en Inde ca coûte moins cher…

C'est généraliste et en même temps pointu, on apprend pas à tout le monde à écrire du C.

Si. (si on parle de former des développeurs)

Et au passage on leur fait aussi bouffer de la prog fonctionnelle, de l'OO, mais aussi des cours d'algorithmie, de complexité, d'OS, d'architecture, de réseau, de concurrence etc.

Savoir utiliser l'API d'Android, le langage industriel du moent et se faire inculquer le métier pour des gens expérimentés ca vient après. Bref une école qui te propose de louper tout ce que tu peux difficilement apprendre ailleurs mais qui sont les bases pour des métiers où l'on est payé pour utiliser son cerveau, mais qui prétend t'apprendre ce que va de toute facon apprendre en bossant avec des gens compétent ou en t'intéressant à la chose…