Pratiquons le Design Pattern Delegate (ou Façade) : Démos avancées

 

Le design pattern delegate ( ou façade ) est un pattern très utilisé et facile à expliquer.

Deux démos, une simple et une seconde très avancée, vous permettent de pratiquer sereinement ce design sans difficulté.

Ainsi, les ingrédients de ce blog sont divisés en deux parties:

  • La première partie, contenant une démo simple, n'exige aucun prérequis (mis à part un peu de java 8).
  • La seconde partie, contenant une démo très avancée, nécessite de connaître un peu spring-batch et en particulier son FlatFileItemReader (retrouvez un article sur le sujet ici).

Spring-Batch (Part I) : Tester unitairement & mocker simplement. FlatFileItemReader

 

 

 

 

Comment tester unitairement et simplement les trois composants principaux de Spring-Batch: Reader, Processor, Writer?

Plus précisément comment mocker le(s) contexte(s) spring-batch pour ces trois composants?

Ce billet, sur plusieurs parties, présente quelques démos pratiques permettant de réaliser ce genre de tests unitaires (et d'intégration en prime).

Les démos sont réalisées en combinant le duo de spring: spring-batch et spring-boot.
Ce duo simplifie grandement (voire à outrance) la configuration de spring et laisse en arrière-plan beaucoup trop de complexité.

La première démo permet de réaliser un projet spring-batch avec un job contenant un seul step, le tout configuré avec java (no xml).

L'unique (step du) job consiste à charger en base (BD) les lignes d'un fichier csv nommé entreprises.csv.

Nul besoin à ce stade de processor!

Ainsi, notre job contient uniquement les composants nécessaires: un reader et un writer.

A la fin de cette première partie, nous écrirons un test TU Junit du reader.

Le seul intérêt de tester unitairement le(s) reader(s) est lorsque le métier exige un traitement personnalisé ce qui est généralement le cas! 🙁

Une fois le test TU posé et automatisé, le(s) refactoring(s) et les évolutions (agilité oblige) deviennent des opérations plus sûres.

Java et les tests

mavenjenkinsjunitsonarqube

Imaginons une organisation qui se lance dans le développement Java et souhaite monter sa première plate-forme de développement Java. Que peut-on lui conseiller pour la partie tests ?

Lorsqu'on parle de test en Java un des premiers noms qui vient à l'esprit est JUnit. Puis on pense à l'intégration continue qui permet de tester la non régression au fil de l'eau, par exemple avec Maven (mais en fait Maven s'occupe surtout du build). Et enfin éventuellement à Sonar (qui s'appelle SonarQube depuis peu) pour la qualité logicielle, et à Test Director (maintenant HP Quality Center) pour la gestion de plans de tests. Et en poussant un petit peu on arrive à se souvenir qu'on pourrait faire de la gestion des exigences, par exemple avec DOORS. Ah oui, et aussi qu'il faut gérer les bugs, par exemple avec Mantis, Jira ou Bugzilla.

Améliorez les performances: Parallel processing with Camel & Spring (Partie 1/2)

Ce billet s'inscrit dans la catégorie optimisation des performances.

Il se fixe comme objectif d'illustrer avec démo détaillée comment améliorer significativement les performances de nos projets.

Et cela sans se lancer dans l'aventure d'écrire des kilomètres de code lourd de gestion du 'parallel processing' car nous allons laisser la puissance du framework Camel opérer.

Sachez néanmoins que de nombreux problèmes de mauvaise performance peuvent être traités sans recours aux implémentations complexes de parallélisme.

Voici deux situations où il faudrait réfléchir sur l'apport du parallélisme :

- Si les tâches ou opérations ne prennent que très peu de temps (échelle quelque sec). La gestion/monitoring des threads devient coûteux.

- Si les ressources mémoire, CPU et IO sont déjà fortement utilisées; sachez que le parallélisme consomme davantage de ressources.

Le billet veut s'inspirer (librement) des deux étapes décrites dans la démo du chapitre 10 du livre "Camel in action".

L'essentiel du code source est fourni ici.

Sachez néanmoins que le code présenté ci-après a été largement adapté et pour certaines parties complètement réécrits.

En effet, comme j'utilise Spring, toutes les parties de code sont adaptées ou réécrites en fonction.

En particulier j'utilise l'implémentation spring ThreadPoolTaskExecutor de l'interface TaskExecutor à la place de la méthode statique de Executors de java.

Le billet est organisée en deux parties:

- La première partie permet d'exécuter en séquentiel notre démo,

- La seconde permet adapte la première partie pour une exécution parallèle.

Nous donnons quelques indications sur le temps d'exécution de chacune des parties.

Avec les bons paramètres nous pouvons diviser par quatre le temps d'exécution voire plus.

Le framework Camel offre avec son java DSL des fonctions permettant d'obtenir simplement de meilleurs performances en parallélisant les tâches.

Comme d'habitude nous le combinons avec le framework Spring v3+ car peut-on faire autrement?

Dans le domaine de performance, il est utile d'identifier les deux limites: CPU-bound et IO-bound.

Distinguer ces deux limites permet d'identifier le bon choix pour améliorer les performances.

En guise de conclusion, dans le domaine d'exécution parallèle, Camel simplifie grandement la vie des développeurs.

Néanmoins, il leur reste la responsabilité de la cohésion des données.

Passons à la mise en pratique.

Présentation, étape par étape, de Spring-DATA-JPA

Ce billet présente une démo pour illustrer, étape par étape, comment utiliser Spring-Data-JPA.

Ce billet peut être considéré traitant le même thème que Construction de requêtes en Java : comment faire le bon choix ?.

Nous détaillons, dans une première partie, la prise en main du "framework" Spring-Data-JPA avant de progresser dans notre compréhension.

Le projet Spring-Data-JPA est l'un des projets de Spring reposant sur Spring-Data.

Spring-Data réduit considérablement le coût économique de la couche d'accès aux données relationnelles ou NoSQL.

Il simplifie l'accès aux bases de données SGBDR ou de type NoSQL.

Spring-Data peut-être combiné avec le framework QueryDSL (Domain Driven Design) afin de réaliser des requêtes complexes.

Avec Spring-Data-JPA, le développeur bénéficie d'un certain nombre de méthodes d'accès à la base sans écrire une ligne de code d'implémentation.

Le projet Spring-Data-JPA vise à améliorer la mise en œuvre de la couche d'accès aux données en réduisant considérablement l'effort d'écriture du code d'implémentation en particulier pour les méthodes CRUD et de recherche.

La notion centrale dans Spring-Data-JPA est la notion "Repository". Le repository est une interface à écrire par le développeur.

Il déclare, dans cette interface, les méthodes utiles d'accès aux données et Spring-Data-JPA fournit les implémentations nécessaires.

Notez que la même approche est appliquée à des contextes autres que JPA comme pour les bases non relationnelles.

Vous pouvez télécharger les sources de la démo1 ici.

Avec Spring-Data, écrire des méthodes de requête à la base se fait en 3+1 étapes:

  • Déclarer une interface Repository,
  • Ecrire la signature de la méthode de requête (CRUD ou de recherche),
  • Configurer Spring pour la génération automatique,
  • Appeler dans le client (ou test unitaire) les méthodes du Repository

C'est aussi facile!

Mais là on n'a fait que survoler la surface de Spring-Data.

Nous allons détailler ces étapes ci-après dans la démo.

Mylyn 3.5 – Intégration de Hudson dans Eclipse

La nouvelle version 3.5 du module Mylyn permet d'avoir accès à la plate-forme d'intégration Hudson directement depuis l'environnement de développement de Eclipse.

Ainsi plus besoin de sortir de Eclipse, toutes les informations sont disponibles depuis Eclipse :

  • l'état des jobs d'intégration est rafraîchi automatiquement dans Eclipse et une notification s'affiche indiquant si un build échoue
  • les résultats des tests du job sous Hudson s'affichent dans la vue JUnit comme s'il s'agissait de tests unitaires lancés en local.
  • les traces de la console du build Hudson sont affichées dans la vue console de Eclipse