Reprise du message précédent :
Update un projet qui a plus de 8 ans, en JS, c'est vraiment un plaisir. Le truc est tellement old que pour chaque dépendance faut limite tout réécrire. Et y'en a des centaines.

Alors que mon vieux projet perso en PHP écrit majoritairement en 2006 et qui tourne encore, il est passé crème sur un upgrade en PHP 7.4 en mettant à jour ma Debian de 2 versions majeures

Entre un projet perso et le coeur même de Vates, je pense qu'il y a un monde.

En plus j'ai réussi à le passer en node 16 là, en une aprem++. Mnt faut voir si tout fonctionne vraiment bien. Y'a des libs qui ont pris presque 10 versions d'un coup.

J'ai un projet en angular 1.5 et ça me faisait chier de faire les évols en angular.
Du coup j'ai sorti react. Codé un pont pour pouvoir utiliser composants et les classes react depuis angular. Et j'ai du coup aussi réussi à vendre un migration avec pour objectif fin avril.

Pour le contexte. Grosse appli angular avec plein de code métier et du delivery continu et un seul dev. Donc migrer tout en react c'est trop velu.
Donc je fais du delivery et migration au fur et à mesure. Car derrière il faut aussi retester ce qui a migré.

Je comprends ta douleur.

Là dans le projet dont je parlais, j'ai aussi du AngularJS 1.5, du React, du vieux JS + Jade, des vieux utils JS qui servent un peu partout, et le server bloqué en Node 8. Tout ce beau monde cohabite dans le même projet.
D'où la misère pour update les dépendances.

Le but c'est migrer le server (api) en Node 16 et faire que le reste fonctionne. On réécrit l'ancien AngularJS vers un nouveau projet (en React) donc pas besoin de le maintenir plus que ça. L'ancienne partie React est facile a update. Il reste les utils à réécrire et le server à update. Genre virer bluebird qui est partout ou ce genre de truc.

ca vous fait pas peur cette tendance aux applis jetables?
 
j'ai encore du code en prod que j'ai écrit en stage y'a 20 ans... et qui marche. A quoi bon passer son temps a réécrire avec le truc à la mode? elle est où la valeur ajoutée?

Le scope des solutions vates a un poil bougé en 7 ans

 
Pour répondre à ta première question, pas du tout.  
 
Je comprends pas la fierté d’avoir du code qui tourne depuis 20 ans. Je parle en général, pas spécialement pour toi.  
 
Je nuance mon propos car tout dépend ce que tu dev, mais dans le Web ça bouge énormément. Comme l’a dit Flo, le projet dont je parle a été commencé y’a longtemps, et il a énormément bougé. Note que le code écrit y’a 7 ans fonctionne encore très bien et est en prod.  
 
Sauf qu’aujourd’hui les besoins ont changés, les technos aussi donc je vois pas pk on irait maintenir du AngularJS par exemple qui était déjà une purge à l’époque.  
En plus on s’améliore tjs en dev, on a tjs une meilleure vision de l’archi, de la façon de faire etc, donc réécrire pour que ce soit plus lisible, ou plus maintenable ça me paraît être une bonne idée. Sans compter les fix de sécurité que tu as en mettant à jour les packages.  
 
Après je ne parle pas de réécrire juste pour réécrire sans aucune plus value à part mettre le framework à la mode hein.  
 
Mais parfois, même sans réécrire, t’es poussé à update par la force des choses.  
 
Exemple récent : notre workflow d’achat a changé. Pour répondre aux nouveaux besoins, on doit mettre à jour la version de l’api de Stripe. Sauf que si je mets à jour l’api et donc dépendance de Stripe, il faut mettre à jour absolument toutes nos références dans le code car beaucoup de fonctions sont dépréciés depuis 2014 (oui on était encore sur l’api de 2014).  
Pour éviter ça, je peux bloquer l’ancienne version, ne pas toucher au code qui fonctionne, et installer une autre version du package a jour que j’utiliserais pour la nouvelle Api. Sauf que ça, c’est possible qu’à partir de npm 6.9 et no spoil, on est pas en 6.9.
Du coup, quitte à mettre à jour npm, autant mettre à jour Node, et donc profiter des ajouts pour alléger notre code et virer des dépendances qui deviennent inutiles.  
 
Autre exemple : dans la boîte quasi tout est en React mnt. Donc le vieux projet Angular, plutôt que de le maintenir, on en a fait un projet à part (plus facile à gérer vu qu’il n’est plus dans le monolithe) et tlm peut contribuer dessus vu que c’est du React. En plus d’ajouter plein de features supplémentaires pour nos utilisateurs.  
 

 
Sur des machines outils ou de l'embarqué c'est normal. Pour le reste le monde évolue. 'as jeté un coup d'oeuil au web d'il y'a 20 ans

C'est normal de maintenir et faire évoluer les dépendances surtout si le besoin change.

Réecrire parce que angular est pénible c'est plus discutable.

Ce qui me pose vraiment problème c'est le côté "obligé" à cause des dépendances non maintenues, des effets de mode, etc. Parce que la tu exploses tes coût d'une évolution fonctionnelle parce que faut refaire plus que sur des technos plus stables.

En angular qui serait une purge est le parfait exemple : y'a 5 ans tout le monde en était satisfait. Dans 5 ans plus personne ne voudra faire de react. Mais tu dois refaire ou te retrouver isolé, avec une dépendance non maintenue et des soucis de recrutement...

A titre personnel, la même que d'avoir construit un meuble qui te survivra, ou un aménagement quelconque, le fait d'avoir vraiment fini quelque chose et de savoir qu'il tiendra dans le temps.

Côté organisation, avoir réglé un problème et pouvoir passer à un autre projet sans arrière pensée. Sans ça tu es obligé d'augmenter la taille d'équipe pour chaque nouveau projet si les anciens peuvent revenir sur le tapis à tout moment.

Et ils nous refont la même avec rust.

Le web c’est compliqué parce que la Ui (et UX) vieillit quoi que tu fasses. Mais ce qui pourrait juste être un problème de CSS/HTML devient un problème plus large parce que c’est templatisé, et les technos web changent constamment à un rythme effrayant je trouve.
 
Venant historiquement du back et ayant fait des projets qui appelaient du code mainframe qui avait 30 ans, je suis d’accord avec Lorill sur le coût prohibitif que les technos web engendrent. C’est une evol à 20 jours ? 40? Ah oui faut tout réécrire dans la dernière techno.
Fait rigolo: le stack sur lequel je bossais était websphere + struts + SAP + mainframe (pacbase pour générer du COBOL) n’importe quel feature coûtait en général un ratio 10/3/1, parce que déjà à l’époque on devait payer un max de dette technique alors même que le projet était pas fini
 
Après je comprends que t’as pas le choix, pour des raisons de support, recrutement, etc… mais ça rend le côté magique “regarde j’ai monté un workflow utilisateur complet en 1 aprem” assez fake, parce que ce workflow on va le repayer 5x dans le futur, alors que le code back sera beaucoup plus stable

https://www.google.fr/search?client [...] cQBQjLCCgA
 
´tain je comprends vraiment rien au marketing, y’a des dizaines d’articles qui parlent d’un produit mieux que les autres suite à une PR. Le merdier est introuvable dans le commerce

Leur cas est un peu particulier : ils ont tout leur code en react, c'est compréhensible qu'ils veuillent aussi passer le code dont ils font l'"acquisition" en react. Angular existe toujours. AngularJS c'est un peu particulier. Ça marche, mais le web étant ce qu'il est (ça tourne sur une plateforme qui change, dont les failles de sécurité apparaissent avec le temps, contrairement à l'appli VB qui tourne sur un vieux Windows 2000 au cul de la machine outil du client depuis 20 ans) faut au moins mettre à jour. Mais migrer une vieille app AngularJS à une version moderne c'est quand même pas le même coût que passer en react.

 
Fig.1 : le front

 
Bah justement non. Le front est passé sans problème. C’est le back qui pose soucis la.

 
Bah quand tu maintiens les dépendances de temps en temps c’est facile. Quand rien a été update depuis plusieurs années, ça se complique.
 
J’ai jamais dit qu’on réécrivait tout juste pour tout réécrire hein.  
Le projet angular a fait son temps, aujourd’hui on le sort du monolithe et il représente même pas 10% du nouveau projet. Donc je vois pas l’intérêt de mettre du code angularJS aujourd’hui en prod sur un projet. Sachant qu’on va devoir compléter par 90% de nouveau code.    
 
Ça fait 5 ans que je fais du React, j’ai pas l’impression que les gens sont passé à autre chose.
 
Et pour le côté des dépendances je suis d’accord avec toi. C’est pour ça que j’en mets très peu, ou alors vraiment si ça fait gagner un temps fou et que le truc est vraiment bien maintenu. Depuis que je suis chez Vates, je passe mon temps à virer des dépendances.  

Y a aussi une tendance chez les devs peu/pas expérimentés à se reposer sur des dépendances externes, pensant que ça va leur faire gagner du temps.  
A très court terme peut-être. Mais en général c'est mal choisi (qui est derrière la dépendance, c'est quoi sa maturité, c'est quoi le bus factor...) et tu le paies assez vite. Sans compter le fait qu'en général on se retrouve à utiliser 20% des features de la dépendance mais qu'on paie pour 100%.  
Dans tous les langages tu peux faire de la merde sur ces aspects mais la juniorité des devs JS n'aide pas sur cet aspect fondamental.  
Dans ma boîte depuis 2 ans on essaie de simplifier au maximum les dépendances (infra, back et front) et y avait un certain passif quand je suis arrivé (genre un rabbitmq pour gérer 500 messages par jour).

5 ans ça reste "peu".
Vu d'ici il n'est pas rare que du code reste valide 10, voire 20 ou même 30 ans sur des applis de gestion un peu costaud (on a toujours en prod un truc de 1995 ici...).
 
Perso j'ai du code d'il y a 15 ans qui tourne toujours en prod et n'a aucune raison de bouger pour encore quelques années...tel que ça évolue (ou en tout cas l'impression que j'en ai), du code React (ou autre machin JS moderne) qui tournera encore tel quel dans 10/15 ans sans que ce soit totalement obsolète je suis pas sûr qu'il y en aura des masses.

Si le code tourne plus c'est parce-que la plateforme qui est dessous (le navigateur) a changé, auquel cas ton code custo aurait pas nécessairement aidé

Dites ya des gens qui ont testé les chauffages infrarouge longs? Je cherche un truc style chauffe pied, je me posais la question entre ça ou céramique (le reste me semble tout atteindre des températures beaucoup trop hautes pour être sous un bureau et potentiellement pas loin des pieds / cables), mais les IR longs me semblent tous avoir d'énormes surfaces (genre 1/2m2 pour pour 400W)

Les backend en JS  

Je suis en train de changer d'idée pour l'aménagement du 2étage, je sais vraiment pas ce qui qui est un bonne idée
https://www.icloud.com/sharedalbum/ [...] A60B53B316
ici j'ai déplacé la chambre de façon qu'on ait pas besoin de la traverser pour aller à la terrasse, et la salle de bains est proche de la chute verticale.

C'est quoi la "chute verticale"?

Avoir la SdB près de la terrasse c'est pratique genre si t'y mets des jardinières / un petit jardin, ou bien que tu t'es retrouvé sous la flotte. Mais tuje sais pas si t'as expliqué le principe, c'est la chambre principale pour avoir plus de place en bas? Ou bien c'est pour louer?

De mon souvenir des photos du bâtiments ça met la chambre au nord-est c'est ça? (IIRC ta terrasse est plein sud?)

C'était quoi les autres idées?

 
Ça fonctionne très bien.    
 
Si y’avait que moi, je réécrirais tout en TS.  

Sinon pytest ça reste un bonheur, pas juste l'API mais la CLI, j'ai beaucoup utilisé —lf (ça exécute les tests qui ont échoué au run précédent, ou tous si le dernier run a réussi), là je teste —sw pour la première fois et ça poutre aussi (ça fait tourner les tests jusqu'au premier échec, au run suivant ça reprend de ce test et ca continue la séquence)

Il avait mis des plans avec la pièce où la chambre est aménagée en SdB non?

Le nombre de types qui prennent une dépendance pour le moindre truc    
Et quand ils décident de faire eux même c'est souvent crypto/gestion des secrets  

pardon, la descente de eaux usées

merde, j'ai détruit le fichier, mais avoir la douche et le lit inversés par rapport à ce plan.

Ah ok donc ça simplifie la gestion des eaux en plus?

Et moi en Clojure, mais dependamment des collègues c'est plus ou moins une bonne idée

oui, c'est un artisan avec qui je discutait qui insistait pour que j'inverse à cause de la gestion des eaux usées.
 
Et du coup c'est pas forcément mal d'intégrer la "niche" naturelle qui est créée par la cage d'escalier à une chambre.

Franchement je préfère cette organisation perso, j’aime bien les salles d’eau pas loin de l’entrée et les chambres à l’inverse et plus à l’écart, et ici il y a pas la place pour un “hall de nuit” donc bon.

j'ai raté ces questions, non c'est une chambre d'amis qui auront aussi accès à une petite cuisine
 
oui, ça met la chambre au nord est, le plan de coupe est à peu près est.

je me suis dit aussi qu'avoir les toilettes près de la terrasse peut être sympa.
 
En fait je voulais pas trop envisager ça parce que le plafond est plus bas à cet endroit, mais j'ai été percer le plafond là-bas hier et je découvre que y'a rien qui empêche de le surélever comme à dans le reste de l'étage, la charpente a la même tronche partout.

Ça c'est une excellente nouvelle

OK (c'était principalement pour une question de températures en été, le nord-est c'est probablement ce qu'il y a de mieux pour éviter de cuire sans PAC).

Yep, ça évite de traverser tout l'appart pour aller pisser et quand tu bois des bières sur la terrasse c'est plus pratique.

La question se posant plus pour la douche je présume? Après tu pourrais faire un truc à la jap ou la SdB même sert plus ou moins de douche (tout carrelé avec une évacuation dans le sol de la SdB) mais ça fait masse de travaux et le risque de fuite quand c'est au 3e est un peu stressant, surtout si c'est au dessus de chez toi

Questions sur Python.
 
Bon, comme vous le savez maintenant, je suis ma fille sur ce langage pour son apprentissage. De plus, on l'utilise aussi au boulot pour certaines choses au niveau du back-end sur certaines choses bien précises.
 
J'ai quelques questions d'ordre général.
 
Ça fait des mois que je fais des recherches et j'avoue que je suis un peu frustré par certaines choses.
 
Si par exemple on veut utiliser python, on va dire pour remplacer PHP, j'ai pas l'impression que Apache soit particulièrement adapté, comparativement à PHP. J'ai l'impression que c'est bcp moins straightforward. Je me trompe ? Faut-il mieux dans ce cas là utiliser un autre web server? Quelle est la meilleure solution que vous recommandez ?
 
Pour les GUI, c'est un peu pareil. Il existe plein de trucs mais rien n'est jamais parfaitement abouti. Il y a bien sûr tkinter qui s'est bien amélioré, surtout si on utilise ttk. Il y a aussi PyQT, mais je trouve pas cela super. C'est okish on va dire. Si on veut faire une app pro multiplatform, c'est quoi votre recommandation ? On est d'accord que PyQT est ce qui existe de mieux ?
 
Sur le jeu vidéo, pareil, j'ai fait énormément de recherches sur des solutions pour faire des plateformers simples pour que lorsque ma fille sera assez forte avec l'object model (elle progresse bien d'ailleurs), on puisse utiliser ses connaissances pour faire des petits jeux "simple". Mais je veux que les petits jeux simples, malgré leur simplicité soient cools. Pas juste 2 carrés qui bougent sur un écran.
Ce que je vois, c'est qu'il y a plein de choses, mais rien n'est abouti. Le mieux documenté, c'est PyGame, mais bon, pas de gravity quoi et plein de choses dans ce genre manquent à l'appel... Mon but n'est pas de la décourager avec un réinventage constant de la roue d'emblée.
 
Il existe des choses comme python arcade qui sont quand même bien plus adaptées, mais la documentation n'est jamais à jour. il faut fouiller partout et ça demande un vrai gros investissement en recherche au bout du compte (ceci dit, les quelques tutos récents que j'ai finalement trouvés sont une parfaite application de l'object model en python et en plus, Tiled est supporté out of the box ainsi que les sprite maps, donc je pense au final m'orienter là dessus).
 
Vous connaissez mieux en librairies pour faire des jeux en python qui permettent de parfaire ses skills en prog sans réinventer la roue ? J'ai loupé quelque chose ?
 
De plus, aucun moyen de faire un jeu qui tournera ensuite sur iOS ou sur Android de manière satisfaisante. On reste bloqué sur du desktop, ce qui est un peu idiot vu que les petits jeux sont bien plus utiles sur un smartphone ou sur un iPad.
 
Bref, c'est quand même là encore assez frustrant.
 
Du coup, je me pose certaines questions.
 
Est-ce que je dois poursuivre avec elle sur python une fois qu'elle aura bien assimilé l'object model (donc d'ici quelques mois), ou est-ce que vous pensez qu'on devrait switcher sur par exemple javascript qui permet de faire un peu tout, y compris des jeux multi-plateformes sur mobile (par exemple en utilisant des choses comme phaser) tout en jouant un peu progressivement avec des trucs genre Unity2D et C# et garder python pour l'école, les problèmes de math, le prototyping, faire des apps rapides en tkinter pour des besoins "scolaires" ?
 
 
 
 
 

Oui, c’est surtout la douche le pb.  
 
Là, un léger avantage que j’ai c’est que c’est du parquet actuellement au sol sous la future douche, donc je peux explorer mes options à la scie sauteuse. Au lieu de sortir le marteau-piqueur.