Reprise du message précédent :

Le problème est peut être là hein, je partais du principe que l'utilisateur avait une idée de ce qu'il voulait

Ben en l'occurence, le client vient de benner le projet sur lequel je bosse comme prestos depuis un an, tout le monde dégage à la fin du mois prochain.

Question git: un tree, comment on décide dans quel ordre les objets sont? Parce-que ça influence le hash de l'objet...

 
Aucune idée. Hamon est relativement invisible pour le moment, Mélenchon en est retourné à ses bonnes vieilles méthodes avec sa horde de fanatiques, le PS est en ruines avec quelques éléphants qui pensent encore pouvoir se payer sur la bête. Y'a plus rien.

J'ai le même constat, j'espérai rater un truc, mais visiblement non

Je vais faire un fork du PS, un Kickstarter et roulaiz

 
this :  
- projets trop gros
- aucune idée de la cible, à part des fantasmes à la con
- achats / légal qui exigent qu'on puisse avoir droit de cuissage sur 60 generations si le contrat "ne livre pas", avec l'idée que le fournisseur doit porter tous les risques si ça foire
 
Faut pas s'étonner si les fournisseurs prennent du gras, ce serait suicidaire de pas le faire.
 

Au mieux il y a une idée du problème à résoudre, pas de la solution

 
Tu penses qu'un ministre fait sa carrière à coup de 12 story points ? Avec Edouard Philippe qui assiste au sprint planning ? Non on lance de grands travaux colossaux puis pour tout un tas de raisons (les systèmes ne sont pas tout à fait au point, les données un peu bancales, la documentation pas tout à fait à jour, les cas particuliers sont nombreux, il y a plein de gens qui ne sont pas d'accord pour tout un tas de raison, t'as pas de profils techniques parce que fonctionnaire blablabla et pic d'activité blablabla) tu prends quelques gros acteurs qui savent faire parce que coordonner 500 gus c'est compliqué, tu fais quelques gros marchés parce que ça prend moins de temps que d'en faire 250 et ça coûte moins cher facialement.
 
Et généralement 99,99% des gens sont de bonnes fois et ne cherchent pas à planter le projet. Les grands complots cyniques sont généralement du flan et quand tu regardes la rentabilité des SSII tu t'aperçois que c'est pas si folichon.
 

 
Quand t'es soumis à des dizaines d'articles de lois, qui sont très complexes et évoluent, de process existants, que des centaines de personnes travaillent déjà avec un système de même type et ne maitrisent pas l'outil informatique de base...

 
Ah merde, je croyais que t'avais une certaine expérience en informatique

10% de marge opérationnelle

Le mec pense qu'un projet industriel coûte 6000$ et recoure massivement à des stagiaires pour des emplois déguisés

 
Ouais enfin entre le ministre et les mecs qui prennent la décision du presta, il y a des tas de niveaux. Et il y a plein de granularités de projets différents.
 
Ce qui me choque, c'est pas tant que des projets puissent partir en couille : a la limite ça peut arriver.
 
Mais par contre, que le payeur ne se donne jamais les moyens de vérifier qu'il ne se fait pas fourguer de la merde (parce que ça, objectivement, ça arrive. Souvent. Et sciemment de la part des fournisseurs : quand chez Portos, tu n'a aucun référent technique sur une équipe de 8 personnes pendant 4 ans, et que tu as un turnover de la totalité de l'équipe par tiers tous les 12 mois, et que tous les nouveaux entrants sont des juniors, ben faut pas s'attendre à des miracles, hein)
 
Donc, le MJ (ou ICDC, ou autre) paye, se fait refourguer de la merde (mais ça se voit pas forcément) au fil du temps comme c'est de la merde, et que par nature, c'est des applis à longue durée de vie, et que le code des marchés publics impose de changer de fournisseur régulièrement, ben il n'y a que très rarement d'investissement pour améliorer la qualité.. Je peux pas poster de capture des Sonar des projets qu'on a entrés, mais franchement, c'est honteux..
 
Ca fait exploser les coûts de maintenance, mais comme le montant de marché n'augmente pas, et que les fournisseurs refusent de rogner sur leurs marges, ben c'est un cercle vicieux.
 
Et le payeur, qui pourtant a des clauses de qualité dans son contrat, ne fait JAMAIS payer les pénalités prévues, soit que les clauses ne sont pas applicables, soit parce qu'il n'a même pas le moyen de mesurer ladite qualité : les audits CAST du code au MJ, c'était une fois par an max.
Comment tu veux détecter une dérive avec une mesure par an? Tu peux pas. Et quand tu t'en aperçois c'est trop tard.
 
bref, pas de complot, effectivement, par contre des pratiques déplorables de certains fournisseurs, et un manque de volonté et/ou de capacité à imposer et contrôler un certain niveau de prestation de la part du client, oui. Ca existe, c'est quasi constant sur les projets des grandes administrations publiques, et ça coûte un pognon invraissemblable qui gagnerait à être investi ailleurs.
 
Enfin, j'invente rien, hein : les 2 projets du MJ et le projet ICDC sur lesquels je bosse, c'est ça : des dévs juniors, des stagiaires, des pratiques d'un autre temps, pas d'industrialisation, etc..
 
Sur la petite appli MJ, en TMA chez Groupe Ouvert : 3 ETP en maintenance sur 50 kLoC, pas de PIC, pas de TUs, procédure de construction en 18 pages word, avec des opérations manuelles genre "on change dans le pom le chemin du fichier de configuration si on construit pour la prod ou pour la préprod" ), une procédure d'install du même tonneau (pour un war et un jar, hein, on parle pas d'un truc compliqué), migration Spring pas finie parce que "onn'a pas trouvé de version d'acegi-security compatible avec la nouvelle version de Spring.. Evidemment ducon : acegi-security c'est devenu Spring Security dans l'intervalle)
 
En moins d'un an, à 1,5 ETP, on a réduit le code à 35kLoC, on avait une PIC, 80% du code sensible couvert par des TIs/TUs, une procédure d'installation en 2 commandes (une pour le war, une pour le jar), avec rollback possible en une commande.
 
 
Ce qui me scandalise là dedans, c'est :  
 
- Du côté Groupe Ouvert :
  * Comment les dévs acceptent de bosser comme ça? Pourquoi? Qu'est-ce qu'il advient des juniors qui bossent pendant 2 ans dans ces conditions sans y voir un problème? Quel absence d'amour propre et de conscience professionnelle peut justifier de faire de la merde comme ça, et de s'en contenter?  
  * Quel enculé il faut être pour décider de staffer le projet avec des gens qui n'y connaissent rien, pour ne jamais demander une expertise technique sur le truc, pour faire faire  une migration technique complexe à des juniors sans encadrement? Pourquoi? Pour augmenter la marge de 10 ou 20%? Quel mépris du client faut-il pour faire ça?  
 
- Du côté MJ :
  * Comment accepter d'avoir des procédures d'install aussi pourries? Pourquoi ne pas imposer un fonctionnement uniforme (le MJ normalise les machines sur lesquelles les applis tournent en production : ils pourraient très bien poser des principes d'arborescence, fournir 2 ou 3 scripts SH qui gèrent 90% des cas, mais ils ne le font pas. A la place, ils ont une boîte de presta qui gère l'exploit, et qui à chaque livraison d'une version, enrobe encore les scripts d'install fournis par les prestas dans leurs propres moulinettes pour que ça soit uniforme.
Du point de vue de la boite qui fait l'exploit, ça serait supprimer leur business, donc soit. MAis du point de vue du client, il n'y a rien qui justifie de payer à chaque coup un truc qui pourrait avoir été fait une seule fois correctement.
  * Quand ils s'aperçoivent que l'appli est pourrie, au bout d'un an ou deux parce que leur outil est un vieux tromblon moisi, pourquoi ils n'appliquent pas les pénalités prévues?
  * Quand ils sont contents d'une presta, qu'ils voient qu'il y a un vrai savoir faire qui a été mis en place, pourquoi ça n'entre pas en ligne de compte?
 
Enfin, merde, on parle de mecs qui sont moins exigeants sur les références de leurs prestas pour des projets à des millions d'euros qu'ils ne le seraient vis à vis d'un artisan qui refait leur salle de bains.  
 

ce monde a besoin de se purger de Java, de Spring, de Spring Batch et de Jenkins

 
Oh fuck, c'est ce que je connais le mieux, à part Spring Batch.  
Blague a part, je te donne raison,  Java vieillit mal, et Jenkins avec.

Perso on a remplacé tous nos jobs Jenkins par du gitlabci.

 
En quoi?
 

Okay et ce super raisonnement mène à ces super résultats. Faut continuer comme ça alors

J'espère que tu troll parce que d'une, je pense pas qu'un projet industriel coûte 6000$ (tu sors ça d'où ?   ), et de deux j'ai aucun stagiaire chez moi

edit : t'es tellement blasé, t'a quel âge en fait, 80

 
Alors c'est du bon ? Tu peux faire un mini topo ?

Globalement oui.  
Plus facilement maintenable. Et plus simple a gérer au niveau des clics clics.
 
La machine tient mieux. Avec Jenkins on avait genre 5 tasks max.  
 
Mnt on a 5 runners qui ont plusieurs jobs. Et vu qu’on est 30 dev, si on push tous en même temps c’était le bordel avant.  
 
La syntax des fichiers gitlabci est très simple à comprendre, on peut vraiment tout custom, sauf mettre ses propres fonctions dedans.  
 
Après notre archi est pas hyper lourde.  
On a genre 1 gros projet avec 4 micros services front et leur équivalent back. Donc environ 9/10 projets qui sont update en parallèle.  
A chaque push, on exécute les TU.  
Quand on marge sur dévelop, même chose + analyse Sonar.  
 
Si on merge develop dans release, on tag + déploiement possible dans intégration ou recette. Ensuite on a d’autre regex pour gérer le deploy dans préprod ou prod, mais absolument tout est config depuis le gitlabci.  
 
Notre gestions des versions est fait avec des scripts intégrés dans le gitlabci, ou via npm pour le front. Même les push dans le nexus.  
 
 
 
 Bref gitlabci nous a vraiment simplifié la vie.

Merci pour ton retour

Si tu as des questions plus précise je pourrais faire un schéma. Ou montrer un bout du fichier ou demander à nos ops.

Je garde l'option sous le coude, mais niveau tests « c'est compliqué » chez nous (on est sur Travis pour la partie « basique » des tests, mais les tests métiers sont très chiants à faire par rapport à ce qu'on y gagnerai)

Après je connais que les TU front.  
 
Les test back y’a tu et integration mais je ne sais pas comment ils sont gérés.  
 
On a des task postman pour tester nos parcours API et mnt gatling.  
+ un raspberry qui balance les infos de notre stack ELK.  
 
Et des bots qui push sur mattermost en cas de problème.  
 
Bref trop d’outils et parfois trop de spam au moindre fait.

J'aime bien les softs que t'utilise, j'ai les mêmes à la maison (jaune de Damas)

 
Pareil ici, je préfère largement: le fichiers de build sont dans le répo du projet, et pas dans une conf xml sur un serveur distant, et je kiffe le build automatique de nouvelle branches.
 

 
Pas de first-class functions, generics implementes comme on peut avec un type-erasure pourri, pas de pattern matching, pas de async/await, Optional qui aurait du rester une classe privee du framework, pas de data objects, et j'en passe; et une volonté d'implémenter comme on peut sans rien casser une partie de ces concepts (et d'autres), ce qui donne par ex. les interfaces fonctionnelles ou les interfaces avec des méthodes, mais ça pue le retrofit malhabile.

Plus un problème depuis Java 8. Certes t'as pas véritablement de first-class functions, mais les interfaces fonctionnelles font plutôt bien le job.
 

Y'a quelques edge cases un peu pénibles, mais rien rencontré de vraiment problématique dessus.
 

Ça c'est super pénible, effectivement.
 

CompletableFuture ?
 

J'ai du mal à voir pourquoi, parce que les gens l'utilisent n'importe comment ?
 

?
 

 
Évidemment que c'est du retrofit, on parle de faire évoluer de façon compatible un langage qui a plus de 20 ans qui n'était pas du tout, du tout fonctionnel à l'origine.
Tout en gardant à l'esprit que Java n'est pas le seul langage à tourner sur la JVM.
Sur la même JVM, tu fais tourner Java, Scala et Kotlin, mais aussi du code Java d'il y a 15 ans. Plutôt pas mal en fait.
 
Alors ouais, Java est un "vieux" langage, qui à la base était conçu pour être facile à aborder par les développeurs C++. Ces décisions de design ont un impact encore aujourd'hui.
Mais dans ce cadre là, ça vieillit bien. Pour profiter de choses un peu plus modernes -> Kotlin.

 
Jenkins 1 ou 2 ?

allez on va aller googler jest, pour voir comment les hipsters on renommé setup, teardown et assert ce mois-ci

 
Tu peux faire tout ça avec des JenkinsFile et des pipelines.
 

 
Alt__ a répondu.
 
Pour DataObjects, tu penses à la JSR 12?  
 
S'il s'agit du fantasme Lombok, à savoir écrire le moins de code possible, c'est à dire juste des attributs.... franchement... Les IDE font tous ça trèèèèès bien. Et l'écriture de ces trucs impose aussi de se poser 2 ou 3 questions sur l'identité et l'immutabilité des choses qu'on expose.
 
 

 
J'ajouterais là dessus que c'est pas malhabile, comme rétrofit : réussir à construire une VM et un langage qui restent rétrocompatible pendant 20 piges, c'est pas exactement simple.
 
Alors je comprends que ce genre de considération touche une burne sans faire bouger l'autre à plein de gens qui codent des applis mobiles qui ont 2 ans de durée de vie, mais le code métier un peu velu, les algos, ça ne change finalement pas tant que ça.Et dans ce domaine là, le mec qui a choisi JEE de base est plus serein que celui qui a choisi Play! qui est plus serein que celui qui a choisi JS en utilisant leftpad.
 
En Java et avec JEE, je gagne : une certaine garantie de longévité de mon code, plein d'implémentations possibles de runtimes pour faire tourner mon bouzin, des gratuits, des payants, des robustes, des clustrisables, etc.... Des librairies à la pelle, testées éprouvées dans une variété de cas d'utilisation que très peu de langages peuvent offrir.
 
Et par dessus tout ça, on a aussi la gestion du parallélisme et du multithreading, qui a quand même son importance dans un contexte où on a de plus en plus de coeurs par processeur. En JS/Node, on bricole à partir de process fils.

J'arrive un peu tard mais non, je pense que c'est pas légal : un travailleur détaché en France doit être payé au dessus du salaire minimum français.

 
le top 10 mesures politiques géniales. la 3ème va vous épater.

en fait je sais pas si les travailleurs détachés sont un si gros problème que ça. Ils sont vraiment en train de sortir l'Europe de l'Est de la fange avec ça.

 
2. Il me semble.

C'est pour ça que Dieu Odersky inventa Scala.

Jenkins Blue Ocean est pas trop mal je trouve, pas besoin de se farcir de configuration en XML de nos jours. Après c'est vrai que le go est plus naturel pour les outils de CI, et y a l'air d'avoir des alternatives pas mal.

Scala    
 
J'en fais un ptit peu avec Gatling en ce moment. J'ai jamais vu une doc aussi merdique.

La doc de Gatling? C'est développé par des Frenchys, faut aller les insulter sur gitter

Oui la doc de Gatling.

C'est surtout leur moteur de recherche qui est à chier, j'ai du faire une dizaine de recherche, pas une seule fois ça a été.
J'ai à chaque fois trouvé un lien qui renvoi sur le site d'alvin alexander. ou d'un autre qui fait un peu de gatling et qui permet de s'en sortir.

 
Ce que alt repond c'est en gros "oui c'est vrai mais... ", et c'est pas franchement convaincant pour moi, du coup on sera pas d'accord, je reponds pas point par point.
Quand je vois des langages plus recents comme Rust par ex, tout est tellement plus elegant que java fait vieillot a cote, stou, surtout quand on parle de parallélisme et du multithreading.
Apres si tu veux considerer l'ecosysteme c'est un debat a part, la je parlais que du langage.
 
Ah et pour les data objects je parle bien du concept de la JSR 12, mais pas forcement implemente comme ca: par ex les struct en rust. Et je trouve que c'est plus propre d'avoir un type d'objet dedie a ca que d'utiliser une classe.

"We Dare You To Explain Luke’s Plan To Rescue Han In ‘Return of the Jedi’"
 
https://uproxx.com/movies/what-was- [...] he-jedi/2/  
 

Hindsight is 20/20 et tout ça.

Tu peux pas vraiment reprocher à un langage conçu dans les années 90 d'avoir fait des choix qui étaient pertinents alors. Et typiquement ajouter des génériques réifiés et des structs ça implique de casser beaucoup de choses niveau rétrocompatibilité, c'est un choix qui a été fait pour C# mais qui n'aurait pas forcément été bénéfique pour l'écosystème Java.