Reprise du message précédent :
Vavr c'est aussi un truc qui a un service rendu assez limité, demande une courbe d'apprentissage importante pour quiconque arrive sur le projet et devient une plaie sans nom le jour où tu veux/dois t'en débarrasser. Extra bonus quand une dépendance que t'utilises utilises une autre version incompatible de Vavr, c'est par exemple un emmerdement notoire quand tu utilises Guava.
 
Pour moi ces libs sont de fausses bonnes idées.

Non justement plus l'app est grosse moins ça se voit, en tout cas le hello world n'est clairement pas une bonne métrique.
 

<compilerArgs>
   <compilerArg>
       -Amapstruct.defaultComponentModel=spring
   </compilerArg>
</compilerArgs>

• Lombok: Effectivement un plugin pour ton IDE est le bienvenue. J'y vois aucun inconvénient vu tout ce qu'un IDE apporte dans le cadre de Java (IntelliJ what else?). La magie ajoutée est somme toute assez faible mais bien pratique, elle évite aussi des conneries (equals hashcode que t'oublies d'updater quand tu ajoutes un champ), permet de créer des builders qui si ils sont écris à la main n'ont aucun intéret, les withers quand tu fais des objets immutables sont pratique aussi, @Slf4j, @AllArgsConstructor, c'est du code généré que t'as pas besoin d'écrire et de maintenir. Et évidemment que ça enhance les .class c'est comme ça que ça fonctionne, maintenant j'ai jamais eu un seul bug de débugging du à Lombok, mais je peux comprendre ton avis.  

• MapStruct: clairement écrire un mapper c'est très chiant et ça n'a aucune valeur, pourquoi le faire, justement ça vise à être automatisé. Tu peux oublier des champs lorsque tu en ajoute encore une fois, c'est du compile time donc les perfs sont excellentes, il gère tout un tas d'edge case. Concernant ton problème de mvn clean ça viendrait pas de ton IDE (Eclipse?). Pour Spring suffit soit d'avoir une property dans le pom.xml si tu veux ça d'activé tout le temps, soit de régler ton componentModel dans l'annotation @Mapper, c'est mentionné dans la doc ici, je ne comprends pas l'argument d'avoir une ligne de plus dans ton pom.xml quand on voit la taille qu'ils font

• Vavr: si tu aimes la programmation fonctionnelle, que t'as envie d'avoir des vraies collections immutables, alors je te le conseille

Pour le coup c'est Guava la fausse bonne idée donc. Vavr est complètement standalone et n'importe aucune dépendance.  
L'intérêt est énorme si tu considère les bénéfices qu'apportent les value type comme Option, Either et Try sur ton code, et les collections immutables sont superbes.

 
Vavr EST une dépendance.
Mais surtout c'est un choix incroyablement structurant pour ton projet, donc un truc à ne pas faire à la légère, sinon t'as juste un lava layer moisi qui vient s'empiler sur le reste.

Oui c'est strucurant mais d'une bonne manière pour moi
Ca fait plusieurs années que je l'enseigne à mes dev, les retours sont très bon et ça évite tout un tas de connerie, je suis néanmoins d'accord avec toi sur le fait qu'il y'a une courbe d'apprentissage, mais 2-3 ateliers / 3-4 katas et c'est réglé  

 
 
Le kernel GNU/LINUX, à l'époque, c'était beaucoup de macro c ou c++ et du code, c ou c++ et le langage de base (proc) il le semble.
J'ai vaguement etudier/constaté.

 
Pardon, mais c'est franchement tiré par les cheveux. En plus, de nouveau, quand tu as des trucs comme lombok, c'est vraiment une réponse bancale au problème "on a un truc verbeux, alors on rajoute du code pour éviter de faire du code", ce qui est complètement abscons comme raisonnement, la bonne logique serait de choisir un langage qui, de base, n'est pas verbeux et n'a donc pas besoin de ces plugins.
 
Tu veux de la perf, Go est infiniment moins verbeux, et sans aucun plugin ni stack qui devient compliquée pour palier au langage lui même, tu veux de la flexibilité, python/node/php, la même, les alternatives ne manquent pas.
 
Au passage, tu remarqueras que des plugins comme Lombok, sont globalement absent des autres langages, et il y a une bonne raison a cela, quand ton langage sait être concis, ça ne sert a rien...

Y'a pas que le langage qui est verbeux y'a aussi des concepts comme javabean qui s'attendent à ce que t'aies des getters setters, c'est pas le langage qui les impose c'est les concepts que des gens ont rajouté par dessus, et dans ce cas précis quel intérêt d'écrire ce genre de chose toi même. Après pour ce cas précis également y'a plus besoin de lombok vu que les record sont arrivés.
 
Quand tu choisis Java tu choisis aussi la JVM et ce qu'elle t'apporte, et heureusement il y'a d'autres langages qui permettent d'émettre du code pour cette VM, néanmoins je pense que c'est possible de faire du code propre directement en Java, les gens ne prennent juste pas le temps, ou sont mal renseignés.
 
Pour Go sincèrement j'en ai écrit pas mal et les error check a chaque ligne, les generics qui existent pas ils fournissent du tooling pour générer du code aussi pour ça, pas d'overloading de fonction c'est sacrément chiant, bref c'est pas la panacée, mais la lib standard est bien fournie, y'a plein de choses qui en font un truc pas aussi mature que Java a ce niveau, c'est mon avis en tout cas.
 
Après je vois pas en quoi Java et flexibilité ne vont pas ensemble. Libre à toi d'utiliser nodejs si c'est ce que tu souhaites oui, maintenant JS en tant que langage à plein de défauts aussi, PHP on n'en parle pas y'a du WTF à foison même si ça reste très souple et facile à utiliser / déplacer, et pour finir y'a pas mal de dev .Net qui diraient pas non à un Lombok like, ce qui n'est pas possible

Excuse me sir, do you have time to talk about our Lord and savior Martin Odersky.

I'm actually busy talking with Rich Hickey
 
Mais oui je suis d'accord avec la où tu veux en venir, par contre on parlait de courbe d'apprentissage et elle est encore différente, par contre c'est vrai que t'as le temps d'apprendre Scala pendant que ça compile

Après, le Java, c'est vrai qu'on peut en écrire sans avoir à foutre du Spring partout, et que ça marche souvent bien mieux comme ça. Le problème, c'est que les frameworks et outils évitent en principe que tout parte en live dès qu'on dépasse 50 000 lignes de code.
Evidemment, quand on a 500 000 lignes et une armée de code monkeys, il faut que ce soit structuré, sinon on va au devant de pas mal d'emmerdes.
A fonctionnalité équivalente, il n'est pas déraisonnable de penser que  Python prendra 4 fois moins lignes de code. Mais on ne rencontre pas beaucoup de bases de code de 100 000 lignes de Python.

C'est de moins en moins vrai, après c'est sûr que compiler du Clojure ça va toujours aller plus vite.
 
Si tu utilises un build tool récent et que tu touches pas trop à des bibliothèques qui font beaucoup de dérivation automatique, honnêtement l'expérience est pas si différente de Kotlin + Gradle.

Kotlin pour le coup des qu'il y'a des extensions un peu partout c'est d'une lenteur l'IDE saccade comme pas possible parfois, ça ne m'arrive jamais en Java

 
 
J'avais posté ce message il y a 6 mois. Je viens de passer 1 an dans ce nouveau département, sans aucune contribution notable.. Incroyable.
 
Je viens de voir un autre embauché se faire jeter après un essai infructueux... Je vais essayer de trouver quelque chose qui me va mieux, mais la période est vraiment difficile.  
Les petits projets perso c'est bien gentil mais ça remplacera jamais une expérience dans l'industrie au contact d'une vrai codebase.
 
 
 
 

 
Une armée de monkeys avec du Python te fera une codebase de merde quelle que soit sa taille.
Le problème c'est pas le langage, ce sont les gens que tu prends, comment tu les fais bosser.

this.

tu n'arrives pas à trouver un truc en remote ou bosser pour une ssii histoire de remplir un peu mieux ton CV pour rebondir ailleurs plus tard ?
 
dans quel coin si c'est pas indiscret?

Je ne sais pas ton niveau (et j'aurai du mal à juger en java de toute façon), mais n'élimine pas complètement l’hypothèse de la boite toxique/pourrie

OFC mais la pile de merde aura des chances d'être plus petite par construction: il est possible de faire du Java en Python (sans parler du fortran) mais ça va rebuter, et ça amène des brouettes d'emmerdements.

Le langage contribue quand même, dans les outils qu'ils te donne, dans la conception de la librairie standard (qui est une grosse source d'exemples & apprentissage), etc…

Une machine Java en dure, encore...
Mais si ça tourne sur un truc interchouche j'aime pas le concept.

Et sinon, au téléthon, qui a lieu en ce moment ( DONNEZ BANDE DE PINGRES) , on voit les premiers enfants complètement gueris par un traitement génétique  
 
1 injection , et ils sont définitivement guéris.  
 
Alors certes, c'est une maladie rare, mais ça donne vraiment de l'espoir pour les autres malade. Et merci à la secu de prendre ça en charge ( cout de l'inject 1.6M€ de mémoire)
 
 

Rire :
Oui, mais si tu donne, après c'est une habitude.
Une autre :
L'état veut le beurre, l'argent, l'épouse, la vache, la ferme, le terrain, et une décoration posthume, je vous dit quand dit l'inspecteur : demain.

 
Oui, et le langage fait aussi office de filtre sur la qualité des développeurs que tu trouves.
Genre trouver un dev Scala complètement nul, c'est un peu plus dur que trouver un dev Java complètement nul.
 
Mais si tu pars du postulat que t'as des devs mauvais, y'a aucun langage qui viendra te sauver

Exactement ça filtre les devs le langage.
 
Sinon day 06, 6 minutes, done , l'an dernier c'était déjà plus dur à ce moment.

@AllArgsconstructor, c'est la plaie, ça empêche de rechercher uniquement des endroits où le constructeur est appelé, tu te retrouves avec tous les endroits où la classe est utilisée. Ça casse l'intégration avec les plugins Spring et Guice dans IntelliJ en supprimant la possibilité de naviguer vers le bean definition. Et si t'as la mauvaise idée de ré-organiser l'ordre de champs de même type, ça casse tout au runtime

Ca s'utilise avec parcimonie

Bon. Hayabusa-2 n'a pas ouvert la saison 2020-2021 des feux de brousse australiens
 

AOC 6 done en 1h05
 
J'imagine que Flaie l'a fait en 8 mn

Lombok c'est une plaie : n'importe quel IDE  peut créer les getters/setters pour toi gratuitement, et ça évite une énième manipulation des classes au runtime (ça a l'air de rien, mais au final ça pèse au démarrage, comme Spring)
Equals/hashcode, c'est le pire. C'est des méthodes importantes, surtout pour des entités, que tu peux coller dans des sets via les relations...
Le jour où tu fais ça, tu as un tout petit peu intérêt à maîtriser ce qu'il y a dans ton implémentation... Et qu'elle soit en cohérence avec tes contraintes dans ta dB, etc.

Bref.. Spring ajoute assez de magie a la con et de couches de proxies et de bidouillage du bytecode que c'est vraiment pas nécessaire d'en ajouter pour des trucs que l'ide peut faire simplement.

Mapstruct, déjà j'aime mieux parce qu'il génère a la compilation.
Mais quand bien même : automatiser le mapping ça va bien si tes DTO sont très proches de tes entités. Du coup ça peut vouloir dire que tu as pas besoin des dto .

Edit: ah merde c'était 6 mn

Franchement, 1h05 pour ça, on va pas se mentir, c'est nul. Je paye quand même très fort ma connaissance approximative de Python. Je pourrais probablement le faire en moitié moins de temps si je ne passais pas mon temps dans la doc. Mais moins de 10mn, même pas en rêve.

Mais le problème, c'est que comme je saute de langage à chaque mission, j'oublie les détails des uns et des autres, il me faut un peu de temps pour m'y remettre.
Je ne sais pas comment tu fais, Flaie, pour maîtriser sur le bout des doigts chaque langage que tu connais. Il faut vraiment que tu codes tout le temps, non ?

Aimer, c'est tout.
Suis le lapin blanc....

 
6 minutes et des bananes pour les 2 parties (et ça ne me fait arriver que 427e)
J'aurais peut-être gagné une minute avec Python, à voir.
 

 
Oui ton IDE peut le générer, sauf que du coup c'est du code source sans valeur que tu te trimballes, qui gache de l'espace dans ton fichier etc. Moi ça ne me plait pas, notons que les records sauvent en partie ce problème.
Concernant equals/hashCode, il ne faut pas utiliser @Data sur des entités, puisque pour des entités le equals/hashCode doit surtout prendre en compte l'ID, donc forcément Lombok qui génère un equals/hashCode pour tous les champs c'est problématique
Par contre toujours concernant Lombok ça intervient à la compilation, c'est un préprocessor tout comme MapStruct, y'a pas de problème runtime, l'overhead est vraiment plus que minime.
Finalement pour les DTO, je suis d'accord la plupart du temps dans les projets que je vois ils ne sont pas nécessaire, mais pour une API plus controllé ils sont censé être différents, ne pas exposer des trucs internes à ton organisation ou plutôt épouser des standards de nommage du marché etc, et dans ce cas là ben MapStruct ça permet d'éviter ça, et c'est mieux que Dozer et autres joyeuseries.
 
 

Ben pour l'instant je trouve ça assez simple et je perçoit très vite où l'énoncé veut en venir, aujourd'hui si tu sais ce qu'est un Set, y'a en fait pas de problème, mais oui après je connais très bien les langages que j'utilise dans ce genre de puzzles pour ne pas avoir à chercher dans la documentation à tout va.
T'inquiètes pas ça va se corcer, et je vais bientôt mettre 1h ou 2 comme les autres
 
 
 
En partie oui, c'est une de mes passions.
 

Je viens de lire les messages d'il y a 6 mois, et les réponses qui t'ont été données à l'époque. Je pense qu'elles étaient bonnes à l'époque et qu'elles le sont toujours aujourd'hui.
 
De ce que tu dis, clairement tu as des lacunes, et il te faut les combler urgemment. Et il n'y a pas d'autre manière de les combler que de coder par soi-même. Un violoniste n'apprend pas le violon une fois qu'il est dans l'orchestre, il s'entraine chez lui tous les jours avant.
Il faut que tu saches produire du code correct tout seul, et que les solutions que tu proposes passent certains critères de qualité que tu es sensé connaître à bac+5. Il y aura bien sûr moyen d'apprendre et s'améliorer sur le tas, quand les revues de code te proposeront des solutions meilleures, mais les équipes de dev attendent de leurs membres un minimum de savoir-faire. Et ce savoir-faire, il devient obsolète rapidement, donc il faut tout le temps se mettre à jour. Si tu aimes coder, - tu dis que c'est ce que tu veux faire -, normalement ça doit venir tout seul. Mais si tu veux faire ce métier uniquement pour des perspectives de salaire ou je ne sais quoi, euh, tu n'as aucune chance dans ce métier.
 
Dans tous les cas, dans le métier, coder c'est 30% du taf, le reste, c'est poser parfois des questions (pertinentes) et surtout chercher par soi-même.

 
Relis le titre du topic.    

mon mauvais, je ne connaissais point ce dénommé jovalise

 
1500 de qi pour conclure minimum.

Au moins j'aurai comblé mes lacunes(et je continue à apprendre) mais c'est frustrant de pas pouvoir développer quotidiennement..  

Est ce que tu as fait le point sur tes lacunes? as-tu déjà tenté des formations en ligne genre udemy, etc?
Sinon participer à des projets open source sur la même techno qu'au travail, lire du code et voir comment les devs expérimentés font.

Juste comme ça, il y en a combien parmi vous qui envisagent de passer ou de repasser sur Mac (depuis M1) quand les modèles HDG (genre 16" ou future 14" ) en seront équipés ?

 
Moi qui suis un ancien musicien pro, je te félicite pour la comparaison, parce que c'est ABSOLUMENT ça. On progresse bien évidemment aussi quand on joue dans l'orchestre, mais cela ne remplace pas le travail personnel. (une chose que bcp de gens ignorent, c'est qu'on peut parfois travailler plus longtemps ses partitions pour l'orchestre seul à la maison que dans l'orchestre pour ne pas se planter comme une quiche devant tous les collègues)
 

 
+1000

 
Si un jour tu ne continues pas à apprendre, tu pourras nous le faire savoir stp.