Un choc de simplification dans le developpement

Restons ouvert aux contributeurs potentiels

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

Je voulais juste intervenir sur ce sujet ;

[…] C'est principalement la raison pour laquelle je ne voyais pas d'un très bon œil l'utilisation de Docker (problème sous Windows) ou le passage a libgit2 (nécessité de Visual studio à l'époque). Je ne suis jamais fan d'imposer un OS, un soft, une version de navigateur, etc qui ne soit pas ultra nécessaire, pour moi c'est ça rester ouvert au maximum.

firm1

Il faut revoir ta définition de l'open-source. Ce n'est pas "Il faut rendre le projet compatible avec TOUT". Avec ce genre de raisonnement, à coté, le monde merveilleux des bisounours et des licornes n'est plus une utopie…

Développer un truc open-source, c'est certes "ne pas fait faire de trucs trop spécifiques", mais faut penser à un truc… si on développe ZdS, c'est aussi.... pour faire tourner ZdS ! Notre code est ouvert ; si quelqu'un veut utiliser ZdS dans son coin, qu'il le fasse. Ça s'appelle plus de la "mise à disposition" en fait…

Et à propos de la stack NPM, et ça fait plusieurs fois que je vois ça ; je ne suis pas dev front, mais c'est quand même un des standards du dév front justement. Je dis ça…

P.S : pour le déploiment : capistrano, anyone ?

Édité par Talus

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0

Youhou, j'adore revenir de 10 jours de vacances et tomber sur ce genre de chose.

Bon, je ne vais pas paraphaser Javier une semaine plus tard mais plutôt le citer, parce que ce qu'il dit c'est aussi ma façon de voir les choses :

Pour npm de ce que j'en ai compris le problème n'est pas l'outil, mais la façon dont il est utilisé. Builder des fichiers front avec npm tout le monde le fait, balancer le résultat du build directement sur la prod par contre je pense que pas grand monde s'y risque. With all due respect je pense que tu fais un mauvais procès : c'est pas npm en lui-même qui est en cause, mais la communication autour des outils. Et là, on est tous responsables. Et sans vouloir être méchant j'ai plus l'impression que tu fais l'autruche en disant "haha je l'avais dit, npm c'est dla merde". Toutes les discussions (sur le site en tout cas) à propos de npm portait sur l'environnement de développement, là le problème est bien plus emmerdant, parce qu'il touche à l'intégration continue et au processus de mise en prod. Sans dire que les deux ne sont pas liés, ta remarque me semble hors-sujet.

Javier

J'appuie un point particulier : jusqu'à la MEP de la v1.4, je n'ai jamais eu de problème spécifique à la prod avec npm.

Un énorme problème qu'on a avec ces environnements, c'est qu'ils ont été installés je ne sais pas quand, je ne sais plus par qui, par quelqu'un qui ne maîtrise visiblement pas totalement les piles front comme npm et la procédure de déploiement standard de Django. Et, dans le cas de npm, comme c'est un outil qui évolue très trop vite, sans réelle mise à jour.

En bref : on ne maîtrise pas nos serveurs… le vrai problème est sans doute là.

Pour répondre au reste du message : je n'ai entendu que des mauvais retours sur les outils comme Behave et lettuce. Un exemple, mais ce n'est pas le seul.

Selenium, ça me semble être une bonne idée, mais c'est à discuter ailleurs : c'est pas simple à mettre en place et ça nécessite du temps de développement et de maintenance.

Sinon je suis très d'accord avec ce message de Talus :

Il faut revoir ta définition de l'open-source. Ce n'est pas "Il faut rendre le projet compatible avec TOUT". Avec ce genre de raisonnement, à coté, le monde merveilleux des bisounours et des licornes n'est plus une utopie…

Développer un truc open-source, c'est certes "ne pas fait faire de trucs trop spécifiques", mais faut penser à un truc… si on développe ZdS, c'est aussi.... pour faire tourner ZdS ! Notre code est ouvert ; si quelqu'un veut utiliser ZdS dans son coin, qu'il le fasse. Ça s'appelle plus de la "mise à disposition" en fait…

Et à propos de la stack NPM, et ça fait plusieurs fois que je vois ça ; je ne suis pas dev front, mais c'est quand même un des standards du dév front justement. Je dis ça…

Talus

Quant à capistrano, je n'ai pas la moindre idée de ce que c'est, et je n'ai pas vraiment le temps de passer des plombes à me renseigner dessus. Si quelqu'un maîtrise déjà le sujet…

En faisant des recherches SpecFox j'étais tombé sur cet article.

Je le trouve proprement à chier. Et écrit par des mecs qui clairement :

  • ne font pas du web
  • n'ont jamais utilisé Selenium
  • ont des préjugés de merde "ouh ruby berk", "ouh c'est hype c'est mal", "moi j'bouffe du code au petit matin"

J'entends bien que ce blog est une référence dans le monde Python, tant mieux. Mais cet article me semble vraiment surtout pas à prendre comme argent-comptant dans le contexte de ZdS.

Édité par Javier

Happiness is a warm puppy

+3 -0

Pour moi, le principal message est quand même là : ce genre de chose n'est intéressant que dans le cadre de tests simples où l'on est certains que des non-programmeurs vont développer ces fameux tests comportementaux.

Cas qui ne me semble pas vraiment s'adapter à ZdS. Pour nous, je ne vois vraiment pas l'intérêt de cette chose pas rapport à un simple binding officiel de Selenium et des systèmes tests unitaires.

D'autre part je ne sais pas ce que tu appelles "ne font pas du web", mais si, Sam et Max travaillent beaucoup dans le web.

Auteur du sujet

J'appuie particulièrement le message de Javier ci-dessous et j’insiste même sur le "Je le trouve proprement à chier."

Pourquoi ?

  • C'est bien connu que les mecs de Sam et Max sont des gros trolls
  • Son article ne dis pas qu'un outil particulier est pourri, son article remet complètement en cause la logique TDD. Ce qui n'aide pas à qualifier son article de bon quand on sait que bon nombre d'entreprises travaillent dans ce sens.
  • Dans le même article, il va prétendre que les doctests suffisent à remplacer ce qui est fait avec lettuce. Encore une déception
  • Il préconise des tests d’intégration à base de python "que seul le dev python peut écrire et comprendre", ce qui réduis l'utilité du test à un TNR

Donc oui c'et complètement le profil du mec qui a mal vécu la guerre Ruby vs Python

+0 -0

@firm1, si tu veux convaincre quelqu'un, commence par éviter les attaques ad hominem (points 1 et 5) et donne des arguments. Là c'est juste un méta-commentaire de l'article, ça n'a aucun intérêt. Ce qui m'intéresse, c'est un article de quelqu'un qui a utilisé ce genre d'outil dans un vrai contexte…

De toutes façons je ne pense pas que ce soit vraiment le sujet ici, par contre ça mériterait un sujet dédié.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte