Bonjour à tous,
Voici les news de la communauté maven pour le mois d’août.
Ce mois-ci a été bien occupé dans la communauté avec les releases de produits (continuum, archiva) et de nombreux plugins

(Lire la suite…)

Bonjour à tous,
Voici les news de la communauté maven pour le mois de juillet.
Après un mois de juin assez chargé, le mois de juillet est celui du repos … (ou plutot celui du travail de fond)

(Lire la suite…)

Un petit post rapide qui ne va en rien révolutionner votre manière de voir le monde mais peut-être faire évoluer celle de voir les versions des artifacts Maven…

(Lire la suite…)

Bonjour à tous,
Voici les news de la communauté maven pour le mois de juin.
Ce mois-ci il y a du lourd avec la sortie des versions 1.1 et 2.0.7 de maven et deux versions 1.0-alpha d’archiva

(Lire la suite…)

Bonjour à tous,
Voici les news de la communauté maven pour le mois de mai.
Un mois relativement calme qui aura vu peu de releases mais certaines très attendues par la communauté !!!

(Lire la suite…)

Bonjour à tous,
Voici les news de la communauté maven pour le mois d’avril.

(Lire la suite…)

Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J’en entends déjà pester « encore un truc de geek »…Le pilotage par les tests se résume à ces deux points clés:

• remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l’ambiguïté du langage courant par des spécifications exécutables c’est à dire vérifiables concrètement et fournissant une réponse sans appel: « vert » ou « rouge ».

• Piloter non pas sur un « reste à faire » – concept obscur car que met on dans le « reste à faire »? – mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d’avoir un outil permettant aux « fonctionnels » d’écrire simplement – c’est à dire dans leur vocabulaire – les spécifications exécutables et permettant aux « managers » de piloter les développements.

(Lire la suite…)

Les annonces dans la communauté maven étant très riches, nous vous fournirons désormais en début de chaque mois un récapitulatif des annonces du mois précédent.

(Lire la suite…)

Les besoins en terme de qualité de code amènent de plus en plus de projets à s’intéresser et à coder des Tests Unitaires. Et comme appréhender le logiciel en cours de production est complexe, des indicateurs dits « de couverture de tests » sont utilisés en complément.
Loin de moi l’idée de remettre en cause cet indicateur représentant le pourcentage de code métier exécuté par les tests. Il présente plusieurs intérêts:

• fournir une valeur quantitative représentant la part de logiciel testé
• fournir une visualisation (sous forme de rapport html maven ou autre) du code exécuté et surtout du code non exécuté. J’y vois là le double avantage :

• de mieux maitriser le risque. Le code non testé est connu.
• de permettre d’améliorer le test lui-même. En effet, du code peut ne pas être testé simplement parce qu’un cas un peu particulier a été omis et visualiser ces portions oubliées du code aide à affiner les tests. D’aucuns diront que si on fait du TDD (« Test Driven Development »), le code non testé est inutile et n’aurait donc pas du être écrit. Je peux les rejoindre dans cette approche extrême. Après, il y a la réalité des projets et du test aujourd’hui…

Reste que cet indicateur de « couverture de test » se contente de « voir » le code exécuté. That’s all et ca n’est peut-être pas suffisant.
(Lire la suite…)

J’ai trouvé à plusieurs reprises lors d’audits d’optimisation de performances des soucis liés à une mauvaise utilisation d’hibernate, d’où le nom d’antipattern d’utilisation d’Hibernate.

Contexte

Utilisation d’Hibernate en Java (et .Net je suppose).
On cherche à accéder à un objet en Java via sa clé primaire. La requête est effectuée via une Query Hibernate.
Exemple de code:

1
2
3

Query tQuery =getSession().createQuery("from ParamCourtierPo where codeBanque=:codeBanque");
tQuery.setInteger("codeBanque", pParamCodeBanque);
ParamCourtierPo param = (ParamCourtierPo) tQuery.uniqueResult();

(Lire la suite…)