Antichesse (o ^ω^ o)
Comme ça faisait un moment que je n'avais pas créé des beans à la main (et utilisé Spring Context aussi), je me le note au cas où ça se reproduirait.
Voici le diagramme résumé
Tout est dit ! Et j'adore Kotlin c'est vous dire. Mais je préfère me tirer une balle que de faire du annotation-driven-development avec un java-procedural-spring-singleton-base programming.
Si je disais précédemment que la PF pure était un cancer, alors Spring et ce mode de programmation est un cancer metastasé !
Merci à @Philou qui me comprends et qui m'a offert ce lien.
L'idée n'est pas mal : vous ajoutez des annotations dans votre code Java et un processeur d'annotations piloté par un plugin Maven va générer pour vous la configuration Kubernetes de votre application. Etant donné que je n'aime pas trop m'embêter avec Kubernetes (je n'arrive plus à apprendre toutes les technos de la terre, surtout les technos ops, elles sont en train de me tuer), j'apprécie d'autant plus cette initiative.
Via Riduidel.
Je viens de découvrir que JPA vous permet d'annoter les méthodes de vos entités (avec des annotations particulières), afin de les exécuter durant le cycle de vie de leur enregistrement :
- @javax.persistence.PrePersist
- @javax.persistence.PreRemove
- @javax.persistence.PreUpdate
- @javax.persistence.PostLoad
- @javax.persistence.PostPersist
- @javax.persistence.PostRemove
- @javax.persistence.PostUpdate
Je trouve que c'est une très bonne idée car cela peut être pratique, mais c'est aussi terrible car cela ajoute de la complexité à quelque chose comme Hibernate qui est trèèèèèèèèès loin d'être un framework simple à la prise en main.
Add a @KnownIssue annotation for TestNg tests that already have a related bug on Jira, and they will be skipped until it is resolved.
La communauté TestNG est prodigieuse. Le principe est le suivant :
- Lorsque vous avez un bug vous créez un ticket et un test reproduisant ce bug.
- Tant que le ticket est ouvert, le test - s'il échoue - ne plantera pas votre build.
- Si le test passe mais que le ticket est encore ouvert, alors le build va planter, vous forçant donc à fermer le ticket.
Cette annontation à ajouter en supplément du @Test vous garantira disposer d'un issues tracker toujours synchro avec l'état réel de votre code base.
Un post intéressant sur les annotations JetBrains pour exposer le contrat d'une méthode (cf. programmation par contrat, JML). Si ces annotations peuvent servir à du code Kotlin pour plus facilement recevoir des données provenant d'un code Java, alors je pense que cela peut être une excellente idée de les utiliser afin d'avoir un code Java qui soit Kotlin friendly.
Le lien vers la doc officielle.
Pour Chlouchoutte. Toutes les petites annotations existantes en Kotlin et qui produisent un code Java-friendly. L'autre point intéressant de l'article est qu'il montre le code Java produit à partir du code Kotlin.
Un projet que vient de me montrer Aurélien et qui permet d'ajouter des annotations plus parlantes et dédiées au développeur dans le code du type : @WTF, @BossMadeMeDoIt, @IAmAwesome, @LegacySucks...
Il semble même que l'on puisse générer une JavaDoc à partir de ces annotations histoire de documenter techniquement la qualité interne et ressentie du code.
Autant utile que drôle !