Forem: Diallo Mamadou Pathé

Refactoring with Polymorphism: Say Goodbye to Complex Conditionals

Diallo Mamadou Pathé — Sun, 02 Mar 2025 22:53:14 +0000

Introduction

Clarity and maintainability are pillars of quality code. Yet, we often find ourselves dealing with complex conditional structures - a series of if, else if, or switch blocks that span multiple lines or, worse, multiple screens. These constructs can quickly become a maintenance nightmare, especially when new conditions are added over time.

Fortunately, object-oriented programming offers us an elegant solution: polymorphism. In this article, we'll explore how this technique can transform complex code into something much more readable and scalable.

The Problem with Conditional Structures

Let's look at a concrete example from an animal management application:

enum FoodType {
    MEAT, VEGETABLES, FISH
}

class Animal {
    FoodType type;
    String name;
    double hungryLevel;

    void eat() {
        if(type == FoodType.MEAT) {
            hungryLevel -= 1;
        } else if(type == FoodType.VEGETABLES) {
            hungryLevel -= 0.5;
        } else if(type == FoodType.FISH) {
            hungryLevel -= 0.8;
        }
        // What if we add new food types?
    }
}

This code presents several issues:

Violation of the Open/Closed Principle: To add a new food type, we must modify the eat() method.
Maintenance difficulty: The more food types we add, the longer the method becomes.
Risk of errors: Complex conditional structures are prone to oversights and bugs.
Potential duplication: If the same logic is required elsewhere, we risk duplicating these conditions.

The Solution: Polymorphism

Polymorphism allows different classes to implement a common method, each in its own way. Here's how to refactor our example:

abstract class FoodType {
    abstract double getSatiation();
}

class Meat extends FoodType {
    @Override
    double getSatiation() {
        return 1.0;
    }
}

class Vegetables extends FoodType {
    @Override
    double getSatiation() {
        return 0.5;
    }
}

class Fish extends FoodType {
    @Override
    double getSatiation() {
        return 0.8;
    }
}

class Animal {
    FoodType foodType;
    String name;
    double hungryLevel;

    void eat() {
        hungryLevel -= foodType.getSatiation();
    }
}

The Benefits of Polymorphism

1. Adherence to the Open/Closed Principle

The Open/Closed Principle, one of the SOLID principles, states that software entities should be open for extension but closed for modification.

With our refactoring, adding a new food type is as simple as creating a new class that extends FoodType:

class Insects extends FoodType {
    @Override
    double getSatiation() {
        return 0.3;
    }
}

No modifications are needed in the Animal class or other FoodType classes.

2. More Readable Code

The eat() method is now reduced to a single elegant line. It clearly expresses the intent without getting lost in implementation details.

3. Improved Encapsulation

Each food type encapsulates its own satiation logic. If we want to change how vegetables satiate, we only need to modify the Vegetables class.

4. Ease of Testing

Testing each food type becomes trivial. We can write unit tests for each implementation of FoodType without worrying about the Animal class.

@Test
void vegetablesSatiationIsFivetenths() {
    Vegetables vegetables = new Vegetables();
    assertEquals(0.5, vegetables.getSatiation());
}

5. Extensibility

We can easily add new behaviors to our class hierarchy without disrupting existing code:

abstract class FoodType {
    abstract double getSatiation();

    // New behavior
    abstract boolean isProcessed();
}

Practical Application in the Real World

Polymorphism isn't just an academic concept; it's used daily in software development:

UI Components: Frameworks like React or Flutter use polymorphism so different components can be rendered consistently.
Payment Strategies: E-commerce applications often use polymorphism to handle different payment methods.
File Format Parsers: Applications that process multiple file formats use polymorphism to encapsulate different parsing logics.

Conclusion

Replacing complex conditional structures with polymorphism is one of the most powerful refactoring techniques. It transforms difficult-to-maintain code into a well-organized set of classes that adhere to SOLID principles.

The next time you find yourself writing a long series of conditions, take a moment to consider if polymorphism might offer a more elegant solution. Your future self (and colleagues) will thank you!

La centralisation freine l’innovation en limitant la diversité, mais favorise la croissance par la commodité et l’efficacité.

Diallo Mamadou Pathé — Fri, 01 Nov 2024 16:46:03 +0000

Les applications des grandes compagnies téléphoniques : innovation ou frein pour les PME et startups ?

Les applications mobiles de certaines compagnies téléphoniques me rappellent les anciennes cassettes “99 en 1”. En unissant sous une seule interface un grand nombre de services – paiement mobile, transfert d’argent, marketplace, réservation de taxis, factures et plus – elles rendent bien sûr la vie plus simple pour les utilisateurs. Mais cette centralisation a un coût, surtout pour les petites entreprises.

Quand une grande plateforme rassemble tous les services locaux, elle monopolise l’attention des utilisateurs et crée une sorte d’écosystème fermé. Pour les PME et les startups, cela signifie moins de visibilité et des obstacles supplémentaires pour percer sur le marché. Sans un appui conséquent, elles risquent de rester dans l’ombre des applications des grandes compagnies qui bénéficient déjà d’une base d’utilisateurs massive et de ressources importantes.

Alors, doit-on vraiment encourager ce modèle ? Il serait peut-être temps de repenser ces plateformes pour qu’elles deviennent plus ouvertes et accessibles aux startups et aux PME locales.

En favorisant des collaborations, en offrant des API ou même en donnant plus de place aux entreprises émergentes, ces grandes applications pourraient devenir non pas un obstacle, mais un tremplin pour l’innovation locale.

Qu’en pensez-vous ? Est-ce que la centralisation des services par les grandes entreprises freine l’innovation, ou au contraire, stimule-t-elle la croissance en offrant plus de commodité ?

Commencer la programmation avec Spring batch

Diallo Mamadou Pathé — Tue, 22 Oct 2024 11:13:53 +0000

Introduction

Dans vos projets personnels ou professionnels, Il vous arrive de faire des traitements sur de gros volumes de données. Le traitement par lots de données est un moyen efficace de traiter de gros volumes de données où celles-ci sont collectées, traitées, puis les résultats par lots sont produits. Le traitement par lots peut être appliqué dans de nombreux cas d'utilisation. Un cas d'utilisation courant du traitement par lots consiste à transformer un grand ensemble de fichiers CSV ou JSON en un format structuré prêt pour un traitement ultérieur.

Dans ce tutoriel, nous allons essayer de voir comment mettre cette architecture en place avec Spring Boot qui est un framework qui facilite le développement d'applications fondées sur Spring.

Qu'est-ce que Spring-Batch?

Spring Batch est un framework open source pour le traitement par lots. Il s'agit d'une solution légère et complète conçue pour permettre le développement d'applications par lots robustes, que l'on trouve souvent dans les systèmes d'entreprise modernes. Son développement est issu d'une collaboration entre SpringSource et Accenture.

Il permet de pallier à des problème récurrents lors de développement de batchs:

productivité
gestion de gros volumes de données
fiabilité
réinvention de la roue.

N.B: En informatique, un batch est un programme fonctionnant en StandAlone, réalisant un ensemble de traitements sur un volume de données.

Architecture de base de Spring Batch

Pour gérer les données d'un batch, on utilise principalement les trois outils suivants:

JobLauncher : il s'agit du composant chargé de lancer/démarrer le programme de traitement par lot (batch). Il peut être configuré pour s'auto déclencher ou pour être déclenché par un évènement extérieur (lancement manuel). Dans le workflow Spring Batch, le JobLauncher est chargé d'exécuter un Job (tâche).

Job : il s'agit du composant qui représente la tâche à qui on délègue la responsabilité du besoin métier traité dans le programme. Il est chargé de lancer de façon séquentielle une ou plusieurs Step.

Step : c'est le composant qui enveloppe le cœur même du besoin métier à traiter. Il est chargé de définir trois sous-composants structurés comme suit :

ItemReader : c'est le composant chargé de lire les données d'entrées à traiter. Elles peuvent provenir de diverses sources (bases de données, fichiers plats (csv, xml, xls, etc.), queue) ;

ItemProcessor : c'est le composant responsable de la transformation des données lues. C'est en son sein que toutes les règles de gestion sont implémentées .

ItemWriter : ce composant sauvegarde les données transformées par le processor dans un ou plusieurs conteneurs désirés (bases de données, fichiers plats (csv, xml, xls, etc.), cloud).

JobRepository : c'est le composant chargé d'enregistrer les statistiques issues du monitoring sur le JobLauncher, le Job et la (ou les) Step à chaque exécution. Il offre deux techniques possibles pour stocker ces statistiques : le passage par une base de données ou le passage par une Map. Lorsque le stockage des statistiques est fait dans une base de données, et donc persisté de façon durable, cela permet le suivi continuel du Batch dans le temps à l'effet d'analyser les éventuels problèmes en cas d'échec. A contrario lorsque c'est dans une Map, les statistiques persistées seront perdues à la terminaison de chaque instance d'exécution du Batch. Dans tous les cas, il faut configurer l'un ou l'autre obligatoirement.

Pour plus d'informations, je vous conseille de consulter le site de Spring.

Après cette explication bref de l'architecture de spring batch,essayons dès à présent de montrer comment mettre en place un job spring batch qui va lire des données à partir d'un fichier CSV que nous allons par la suite insérer dans une base de données."Let's get into coding".

Configuration du projet

Le moyen le plus simple de générer un projet Spring Boot consiste à utiliser l'outil de démarrage Spring avec les étapes ci-dessous:

Se rendre sur le site Spring Initializr
Sélectionner Maven Project et langage Java
Ajouter Spring Batch, JPA, Lombok, H2 Database
Entrer le nom du groupe comme "com.example" et l'artefact comme "SpringBatch"
Cliquez le bouton generate

Une fois le projet généré, il faut le dézipper ensuite l'importer dans votre IDE.

Technologies utilisées:

JDK 1.8
Maven
IntelliJ
Lombok
Spring data JPA
H2 Database

Dépendances du projet

Toutes les dépendances du projet sont dans le fichier pom.xml. Les trois lettres POM sont l'acronyme de Project Object Model. Sa représentation XML est traduite par Maven en une structure de données qui représente le modèle du projet.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.3.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.pathus</groupId>
    <artifactId>SpringBatchExample</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>SpringBatchExample</name>
    <description>Demo of spring batch project </description>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-batch</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>

        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework.batch</groupId>
            <artifactId>spring-batch-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

Structure du Projet

La structure du projet se présente comme suit:

Configuration du Job

Pour activer le traitement par lots, nous devons annoter la classe de configuration avec @EnableBatchProcessing. Nous devons par la suite créer un reader pour lire notre fichier CSV, créer un processor pour traiter les données d'entrée avant d'écrire, créer un writer pour écrire dans la base de données.

import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.configuration.annotation.EnableBatchProcessing;
import org.springframework.batch.core.configuration.annotation.JobBuilderFactory;
import org.springframework.batch.core.configuration.annotation.StepBuilderFactory;
import org.springframework.batch.item.ItemProcessor;
import org.springframework.batch.item.ItemReader;
import org.springframework.batch.item.ItemWriter;
import org.springframework.batch.item.file.FlatFileItemReader;
import org.springframework.batch.item.file.LineMapper;
import org.springframework.batch.item.file.mapping.DefaultLineMapper;
import org.springframework.batch.item.file.transform.DelimitedLineTokenizer;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.ClassPathResource;

import com.pathus90.springbatchexample.batch.StudentProcessor;
import com.pathus90.springbatchexample.batch.StudentWriter;
import com.pathus90.springbatchexample.model.Student;
import com.pathus90.springbatchexample.model.StudentFieldSetMapper;

@Configuration
@EnableBatchProcessing
@EnableScheduling
public class BatchConfig {

    private static final String FILE_NAME = "results.csv";
    private static final String JOB_NAME = "listStudentsJob";
    private static final String STEP_NAME = "processingStep";
    private static final String READER_NAME = "studentItemReader";

    @Value("${header.names}")
    private String names;

    @Value("${line.delimiter}")
    private String delimiter;

    @Autowired
    private JobBuilderFactory jobBuilderFactory;

    @Autowired
    private StepBuilderFactory stepBuilderFactory;

    @Bean
    public Step studentStep() {
        return stepBuilderFactory.get(STEP_NAME)
                .<Student, Student>chunk(5)
                .reader(studentItemReader())
                .processor(studentItemProcessor())
                .writer(studentItemWriter())
                .build();
    }

    @Bean
    public Job listStudentsJob(Step step1) {
        return jobBuilderFactory.get(JOB_NAME)
                .start(step1)
                .build();
    }

    @Bean
    public ItemReader<Student> studentItemReader() {
        FlatFileItemReader<Student> reader = new FlatFileItemReader<>();
        reader.setResource(new ClassPathResource(FILE_NAME));
        reader.setName(READER_NAME);
        reader.setLinesToSkip(1);
        reader.setLineMapper(lineMapper());
        return reader;

    }

    @Bean
    public LineMapper<Student> lineMapper() {

        final DefaultLineMapper<Student> defaultLineMapper = new DefaultLineMapper<>();
        final DelimitedLineTokenizer lineTokenizer = new DelimitedLineTokenizer();
        lineTokenizer.setDelimiter(delimiter);
        lineTokenizer.setStrict(false);
        lineTokenizer.setNames(names.split(delimiter));

        final StudentFieldSetMapper fieldSetMapper = new StudentFieldSetMapper();
        defaultLineMapper.setLineTokenizer(lineTokenizer);
        defaultLineMapper.setFieldSetMapper(fieldSetMapper);

        return defaultLineMapper;
    }

    @Bean
    public ItemProcessor<Student, Student> studentItemProcessor() {
        return new StudentProcessor();
    }

    @Bean
    public ItemWriter<Student> studentItemWriter() {
        return new StudentWriter();
    }
}

Configuration du job et de la Step

La première méthode définit le job et la seconde définit une seule step. Les jobs sont créés à partir des steps, où chaque step peut impliquer un reader, un processor et un writer. Dans la définition de la step, on définit la quantité de données à écrire à la fois et dans notre cas, il écrit jusqu'à 5 enregistrements à la fois. Ensuite, on configure le reader, le processor et le writer à l'aide des beans injectés précédemment. Quand la définition de notre job, il pourra définir différentes step au sein de notre exécution à travers un ordre précis. la step studentStep sera exécutée par le job listStudentsJob.

@Bean
    public Step studentStep() {
        return stepBuilderFactory.get(STEP_NAME)
                .<Student, Student>chunk(5)
                .reader(studentItemReader())
                .processor(studentItemProcessor())
                .writer(studentItemWriter())
                .build();
    }

    @Bean
    public Job listStudentsJob(Step step1) {
        return jobBuilderFactory.get(JOB_NAME)
                .start(step1)
                .build();
    }

Définition du Reader

Dans la configuration de notre batch, le Reader lit une source de données et est appelé successivement au sein d'une étape et retourne des objets pour lequel il est défini (Student dans notre cas).

 @Bean
    public ItemReader<Student> studentItemReader() {
        FlatFileItemReader<Student> reader = new FlatFileItemReader<>();
        reader.setResource(new ClassPathResource(FILE_NAME));
        reader.setName(READER_NAME);
        reader.setLinesToSkip(1);
        reader.setLineMapper(lineMapper());
        return reader;
    }

La classe FlatFileItemReader utilise la classe DefaultLineMapper qui utilise à son tour la classe DelimitedLineTokenizer. Le rôle de DelimitedLineTokenizer est de décomposer chaque ligne dans un objet FieldSet et la propriété names donne le format de l'entête du fichier et permet d'identifier les données de chaque ligne. Cette propriété names est utilisée par la classe d'implantation de transformation de données en objet métier à travers l'objet FieldSet. Il s'agit de la classe indiquée par la propriété fieldSetMapper ( StudentFieldSetMapper).

import org.springframework.batch.item.file.mapping.FieldSetMapper;
import org.springframework.batch.item.file.transform.FieldSet;

public class StudentFieldSetMapper implements FieldSetMapper<Student> {
    @Override
    public Student mapFieldSet(FieldSet fieldSet) {
        return Student.builder()
                .rank(fieldSet.readString(0))
                .firstName(fieldSet.readString(1))
                .lastName(fieldSet.readString(2))
                .center(fieldSet.readString(3))
                .pv(fieldSet.readString(4))
                .origin(fieldSet.readString(5))
                .mention(fieldSet.readString(6))
                .build();
    }
}

L'interface LineMapper quand à elle est utilisée pour mapper des lignes (chaînes) vers des objets généralement utilisée pour mapper des lignes lues à partir d'un fichier

  @Bean
    public LineMapper<Student> lineMapper() {

        final DefaultLineMapper<Student> defaultLineMapper = new DefaultLineMapper<>();
        final DelimitedLineTokenizer lineTokenizer = new DelimitedLineTokenizer();
        lineTokenizer.setDelimiter(delimiter);
        lineTokenizer.setStrict(false);
        lineTokenizer.setNames(names.split(delimiter));

        final StudentFieldSetMapper fieldSetMapper = new StudentFieldSetMapper();
        defaultLineMapper.setLineTokenizer(lineTokenizer);
        defaultLineMapper.setFieldSetMapper(fieldSetMapper);

        return defaultLineMapper;
    }

Definition du Processor

Contrairement à un Reader, les implémentations d'un Processor sont plutôt pour des besoins fonctionnels. Il n'est pas obligatoire et on peut s'en passer si aucun besoin fonctionnel n'est prévu dans notre traitement Dans notre exemple, on a écrit un simple processor qui ne fait que convertir quelques attributs de notre objet student en majuscules et on peut aller au delà de cet exemple avec des cas fonctionnels plus concrets.

import org.springframework.batch.item.ItemProcessor;

import com.pathus90.springbatchexample.model.Student;

public class StudentProcessor implements ItemProcessor<Student, Student> {

    @Override
    public Student process(Student student) {
        student.setFirstName(student.getFirstName().toUpperCase());
        student.setLastName(student.getLastName().toUpperCase());
        student.setCenter(student.getCenter().toUpperCase());
        student.setOrigin(student.getOrigin().toUpperCase());
        student.setMention(student.getMention().toUpperCase());
        return student;
    }
}

Definition du Writer

Le Writer écrit les données provenant du processor (ou directement lues par le Reader). Dans notre cas, Il reçoit du processor les objets transformés et chaque objet sera par la suite persisté dans notre base de donnés et transaction sera validée.

import java.util.List;

import org.springframework.batch.item.ItemWriter;
import org.springframework.beans.factory.annotation.Autowired;

import com.pathus90.springbatchexample.model.Student;
import com.pathus90.springbatchexample.service.IStudentService;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class StudentWriter implements ItemWriter<Student> {

    @Autowired
    private IStudentService studentService;

    @Override
    public void write(List<? extends Student> students) {
        students.stream().forEach(student -> {
            log.info("Enregistrement en base de l'objet {}", student);
            studentService.insertStudent(student);
        });
    }
}

Fichier de configuration du batch (application.properties)

# Enabling H2 Console
spring.h2.console.enabled=true

# To See H2 Console in Browser:
spring.h2.console.path=/h2-console
spring.h2.console.settings.web-allow-others=true

# ===============================
# DB
# ===============================

spring.datasource.url=jdbc:h2:file:~/test1
spring.datasource.username=sa
spring.datasource.password=
spring.datasource.driver-class-name=org.h2.Driver

spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
# ===============================
# JPA / HIBERNATE
# ===============================

spring.jpa.show-sql=true
spring.jpa.hibernate.ddl-auto=update
spring.datasource.continue-on-error=true
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.H2Dialect

header.names= Rang,Prenoms,Noms,Centre,PV,Origine,Mention
line.delimiter=,

logging.level.org.springframework.web=ERROR
logging.level.com.pathus90=DEBUG

Fichier CSV à écrire en base de données

Rang,Prenoms,Noms,Centre,PV,Origine,Mention
1,Mamadou Sanou ,diallo,TOMBO 2,1686,MES FLEURS,BIEN
2,SAFIATOU,DIALLO,A.S. TOURE,191,JACQUELINE,BIEN
3,BoubA ,Camara, vh,1686,koumba diawara ,BIEN
4,SAFIATOU,CondE,kk3,1951,kipe,BIEN

Lancement de l'application

Une fois que que avions fini de mettre en place la configuration du batch, regardons dès à present voir si tout ce qui a été dit plus haut fonctionne

Pour exécuter l'application, il faut chercher le fichier qui contient l'annotation @SpringBootApplication qui est le main de notre application.

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableScheduling;

@SpringBootApplication
@EnableScheduling
public class SpringBatchExampleApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringBatchExampleApplication.class, args);
    }
}

Le lancement du main ci-dessus va démarrer notre job et le batch launcher se présente comme suit :

package com.pathus90.springbatchexample;

import org.springframework.batch.core.BatchStatus;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.JobExecution;
import org.springframework.batch.core.JobParameters;
import org.springframework.batch.core.JobParametersBuilder;
import org.springframework.batch.core.JobParametersInvalidException;
import org.springframework.batch.core.launch.JobLauncher;
import org.springframework.batch.core.repository.JobExecutionAlreadyRunningException;
import org.springframework.batch.core.repository.JobInstanceAlreadyCompleteException;
import org.springframework.batch.core.repository.JobRestartException;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class BatchLauncher {

    @Autowired
    private JobLauncher jobLauncher;

    @Autowired
    private Job job;

    public BatchStatus run() throws JobParametersInvalidException, JobExecutionAlreadyRunningException, JobRestartException, JobInstanceAlreadyCompleteException {
        JobParameters parameters = new JobParametersBuilder().addLong("time", System.currentTimeMillis()).toJobParameters();
        JobExecution jobExecution = jobLauncher.run(job, parameters);
        return jobExecution.getStatus();
    }
}

Un scheduler (planificateur) a été mis en place pour permettre au batch de s'auto déclencher. Dans cet exemple, le batch une fois lancé s'exécuter toutes les 8 secondes. Vous pouvez jouer avec en changeant la valeur fixedDelayen millisecondes.

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

import lombok.extern.slf4j.Slf4j;

@Component
@Slf4j
public class Scheduler {

    @Autowired
    private BatchLauncher batchLauncher;

    @Scheduled(fixedDelay = 8000)
    public void perform() throws Exception {
        log.info("Batch programm&#xE9; pour tourner toutes les 8 secondes");
        batchLauncher.run();
    }
}

En plus d'exécuter le fichier main ci-dessus pour démarrer le batch, on peut également lancé la commande mvn spring-boot:run tout en utilisant une invite de commande.

On peut aussi lancer l'application avec le fichier d'archive JAR et dans ce cas il faut :

Se mettre dans le dossier parent du projet en utilisant une invite de commande et exécuter la commande mvn clean package qui va packager notre projet.
Dans le dossier target, un fichier jar sera crée.
Pour exécuter l'application, utiliser la commande java -jar target/nom_du_fichier_généré-0.0.1-SNAPSHOT.jar

S'assurer aussi que la console H2console a déjà démarré lors du lancement notre application spring batch et la base de données est automatiquement générée ainsi que la creation de la table Student.

On observe bien que notre fichier a été bien intégré dans notre base de données.

N.B:Si on souhaite aussi démarrer le batch manuellement sans passer un schedulerqui va se déclencher en fonction de notre paramétrage , j'ai e xposé une API à l'aide du contrôleur pour appeler le Job Spring Batch.

package com.pathus90.springbatchexample.controller;

import org.springframework.batch.core.BatchStatus;
import org.springframework.batch.core.JobParametersInvalidException;
import org.springframework.batch.core.repository.JobExecutionAlreadyRunningException;
import org.springframework.batch.core.repository.JobInstanceAlreadyCompleteException;
import org.springframework.batch.core.repository.JobRestartException;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import com.pathus90.springbatchexample.BatchLauncher;

import lombok.extern.slf4j.Slf4j;

@RestController
@RequestMapping("/load")
@Slf4j
public class StudentController {

    @Autowired
    private BatchLauncher batchLauncher;

    @GetMapping
    public BatchStatus load() throws JobParametersInvalidException, JobExecutionAlreadyRunningException, JobRestartException, JobInstanceAlreadyCompleteException {
        log.info("Batch demarr&#xE9; &#xE0; la demande");
        return batchLauncher.run();
    }
}

il suffit juste de lancer L'URL : http://localhost:8080/load et le batch se lancera

On arrive en fin de notre premier apprentissage sur la programmation des batchs grâce au framework Spring. Laissez des commentaires ou des questions si vous en aviez !

Bonne apprentissage à tous et j'espère que ce premier tutoriel vous sera bénéfique.

Vous trouverez le code source disponible ici

Références

Strategy Design Pattern in Java

Diallo Mamadou Pathé — Fri, 11 Oct 2024 07:16:34 +0000

The Strategy Design Pattern is a behavioral design pattern that enables selecting an algorithm's behavior at runtime. It defines a family of algorithms, encapsulates each one, and makes them interchangeable. The pattern lets the algorithm vary independently from the clients that use it. This is particularly useful when you want to swap or change algorithms without affecting the client code.

Key Concepts:

Strategy Interface: Declares an interface common to all supported algorithms.
Concrete Strategies: Implement different variations of the algorithm.
Context: Uses a reference to the Strategy interface to call the algorithm defined by a Concrete Strategy.

This pattern is useful when you have multiple ways of performing an operation, and the decision of which to use can change dynamically.

Example Scenario: Payment Methods

Let's consider an online shopping platform where a user can choose different payment methods (e.g., PayPal, CreditCard, etc.). The strategy pattern allows switching between different payment strategies without altering the core logic.

Java Example:
1. Strategy Interface:

public interface PaymentStrategy {
    void pay(int amount);
    String getPaymentType();
}

2. Concrete Strategy Classes:

public class CreditCardPayment implements PaymentStrategy {
    private String name;
    private String cardNumber;

    public CreditCardPayment(String name, String cardNumber) {
        this.name = name;
        this.cardNumber = cardNumber;
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount + " paid with Credit Card.");
    }

    @Override
    public String getPaymentType() {
        return "Credit Card";
    }
}

public class PayPalPayment implements PaymentStrategy {
    private String email;

    public PayPalPayment(String email) {
        this.email = email;
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount + " paid using PayPal.");
    }

    @Override
    public String getPaymentType() {
        return "PayPal";
    }
}

3. Context Class:

public class ShoppingCart {
    private PaymentStrategy paymentStrategy;

    public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

    public void checkout(int amount) {
        paymentStrategy.pay(amount);
    }
}

4. Client Code:

import java.util.ArrayList;
import java.util.List;
import java.util.Scanner;

public class Main {
    public static void main(String[] args) {
        ShoppingCart cart = new ShoppingCart();
        Scanner scanner = new Scanner(System.in);

        List<PaymentStrategy> paymentStrategies = new ArrayList<>();
        paymentStrategies.add(new CreditCardPayment("John Doe", "1234-5678-9012-3456"));
        paymentStrategies.add(new PayPalPayment("john@example.com"));

        System.out.println("Available Payment Methods:");
        for (int i = 0; i < paymentStrategies.size(); i++) {
            System.out.println((i + 1) + ". " + paymentStrategies.get(i).getPaymentType());
        }

        System.out.print("Choose a payment method by number: ");
        int choice = scanner.nextInt();

        if (choice > 0 && choice <= paymentStrategies.size()) {
            cart.setPaymentStrategy(paymentStrategies.get(choice - 1));

            System.out.print("Enter the amount to pay: ");
            int amount = scanner.nextInt();
            cart.checkout(amount);
        } else {
            System.out.println("Invalid choice.");
        }

        scanner.close();
    }
}

Output:

Available Payment Methods:
1. Credit Card
2. PayPal
Choose a payment method by number: 1
Enter the amount to pay: 12
12 paid with Credit Card.

Benefits of the Strategy Pattern:

Open/Closed Principle: New strategies can be added without modifying the client code.
Avoids Conditional Statements: You avoid multiple conditional if/else or switch blocks to choose algorithms.
Runtime Flexibility: Strategies can be changed at runtime.

When to Use:

When multiple related classes differ only in their behavior (algorithm).
When you need different variants of an algorithm and want to switch them dynamically.
When you want to avoid complex conditional logic.

This pattern is particularly useful when the selection of an algorithm needs to happen dynamically, and it simplifies code management for algorithms that may evolve independently.

Demystifying Open Source Contribution: A Beginner's Guide

Diallo Mamadou Pathé — Fri, 05 Apr 2024 08:13:45 +0000

Introduction:
In the realm of software development, open source projects play a crucial role in fostering collaboration, innovation, and community-driven development. However, for beginners, the prospect of contributing to open source can often seem daunting and overwhelming. In this guide, we'll demystify the process of open source contribution and provide a step-by-step roadmap for beginners looking to make their mark in the world of open source.

Understanding Open Source:

Define what open source is and its significance in the tech industry.
Explore the principles of open source, including transparency, collaboration, and freedom.
Highlight the benefits of contributing to open source for both individuals and the community.

Finding the Right Project:

Discuss how to discover open source projects aligned with your interests and skills.
Explore platforms like GitHub, GitLab, and Bitbucket for discovering projects.
Provide tips for evaluating projects, such as checking the project's activity, community size, and documentation quality.

Getting Started:

Guide beginners on setting up their development environment for contributing.
Discuss the importance of version control systems like Git and GitHub for collaboration.
Provide resources and tutorials for beginners to learn Git and GitHub basics.

Contributing to a Project:

Explain the various ways to contribute, such as fixing bugs, adding features, writing documentation, and reviewing code.
Provide guidance on how to find beginner-friendly issues or features to work on.
Discuss best practices for communicating with project maintainers and the community.

Making Your Contribution:

Walk through the process of forking a repository, creating a new branch, making changes, and submitting a pull request (PR).
Provide tips for writing clean code, adhering to project conventions, and writing meaningful commit messages.
Highlight the importance of thorough testing before submitting a PR.

Engaging with the Community:

Emphasize the value of engaging with the project's community through discussions, forums, and mailing lists.
Encourage beginners to participate in project-related events, such as hackathons or meetups.
Discuss the benefits of mentorship and seeking guidance from experienced contributors.

Handling Feedback and Iteration:

Prepare beginners for receiving feedback on their contributions and iterating based on suggestions.
Provide guidance on how to respond to feedback professionally and incorporate suggested changes.
Encourage persistence and resilience in the face of challenges or setbacks.

Celebrating Your Contribution:

Celebrate the moment when your contribution gets merged into the project.
Reflect on the impact of your contribution and the journey of learning and growth.
Encourage continued involvement in open source and the broader tech community.

Conclusion:

Contributing to open source is not just about writing code; it's about becoming part of a vibrant community, sharing knowledge, and making a meaningful impact. By following this beginner's guide, aspiring contributors can embark on their open source journey with confidence, paving the way for collaborative innovation and collective growth in the tech industry.

Understanding ArgumentCaptor in Mockito: A Comprehensive Guide

Diallo Mamadou Pathé — Wed, 01 Nov 2023 14:14:51 +0000

Testing is a critical aspect of software development, and unit testing plays a vital role in ensuring the correctness of your code. When writing unit tests, you often need to verify that specific methods were called with the correct arguments. Mockito, a popular Java testing framework, provides a powerful tool called ArgumentCaptor to capture and inspect the arguments passed to methods during testing. In this article, we will explore ArgumentCaptor, its usage, and best practices for effective testing.

What is ArgumentCaptor?

ArgumentCaptor is a feature provided by the Mockito library that allows you to capture the arguments passed to a method call on a mock object. It is especially useful when you want to verify that specific arguments were passed to a method, rather than just checking if the method was called. ArgumentCaptor simplifies the process of capturing and asserting the values of arguments.

Setting Up Mockito and ArgumentCaptor

Before using ArgumentCaptor, you need to set up your project to use Mockito. You can add the Mockito library as a dependency in your build system, as explained earlier in this article. Once you have Mockito in your project, follow these steps to set up ArgumentCaptor:

Import the required Mockito classes and the ArgumentCaptor class:

import org.mockito.ArgumentCaptor;
import static org.mockito.Mockito.*;

Create an ArgumentCaptor instance for the argument type you want to capture:

ArgumentCaptor<YourArgumentType> argumentCaptor = ArgumentCaptor.forClass(YourArgumentType.class);

Using ArgumentCaptor in Testing

Let's dive into an example to illustrate how ArgumentCaptor is used in testing. Consider a simple class called Calculator with an add method, and we want to test that this method correctly adds two numbers.

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
}

Here's how you can use ArgumentCaptor to test the add method:

import static org.junit.Assert.assertEquals;
import org.mockito.ArgumentCaptor;
import org.junit.Test;

public class CalculatorTest {
    @Test
    public void testAdd() {
        Calculator calculator = mock(Calculator.class);
        ArgumentCaptor<Integer> argumentCaptor = ArgumentCaptor.forClass(Integer.class);

        when(calculator.add(anyInt(), anyInt())).thenReturn(5);

        int result = calculator.add(2, 3);

        verify(calculator).add(argumentCaptor.capture(), argumentCaptor.capture());

        List<Integer> arguments = argumentCaptor.getAllValues();

        assertEquals(2, arguments.get(0).intValue());
        assertEquals(3, arguments.get(1).intValue());
        assertEquals(5, result);
    }
}

In this example:

We mock the Calculator class.
We create an ArgumentCaptor for the Integer argument.
We use when to specify the behavior of the mocked add method, returning 5 when any arguments are passed.
We call the add method with arguments 2 and 3.
We use verify to check that the add method was called with the expected arguments and capture those arguments.
We retrieve the captured arguments using argumentCaptor.getAllValues() and assert that the values are as expected.

Best Practices for Using ArgumentCaptor

Use ArgumentCaptor when needed: ArgumentCaptor is a powerful tool, but it should be used when you specifically need to capture and inspect arguments in your tests. Overusing ArgumentCaptor can make your tests more complex.
Name your captors descriptively: Give your captor variables meaningful names that reflect the purpose of the captured arguments. This helps improve the readability of your tests.
Avoid asserting the order of captured arguments: ArgumentCaptor captures arguments in the order they are encountered, but it's usually better to assert the values themselves rather than their order. This makes your tests more robust and less dependent on implementation details.
Keep your tests focused: Use ArgumentCaptor to test the behavior of specific methods or interactions with collaborators. Avoid using it for unrelated verifications.
Combine ArgumentCaptor with other Mockito features: ArgumentCaptor can be used in combination with other Mockito features, such as verify, when, and any, to create comprehensive and effective tests.
Document your tests: Clearly document the purpose of your tests, including what you're capturing and why it's essential. This helps other developers understand your test cases.

Conclusion
ArgumentCaptor in Mockito is a valuable tool for capturing and inspecting method arguments during testing. It enhances the capabilities of your unit tests by allowing you to verify that specific arguments are passed to methods. By following best practices and using ArgumentCaptor judiciously, you can create more robust and maintainable tests, ultimately leading to higher code quality and reliability in your software projects.

WhatsApp cloud API for java

Diallo Mamadou Pathé — Fri, 25 Aug 2023 12:57:41 +0000

WhatsApp launches a cloud API accessible to all

With WhatsApp Cloud API, Meta provides a free and secure cloud service to facilitate the work of developers.

Until now, the WhatsApp Business API was reserved for medium and large companies who wanted to facilitate exchanges with their customers, all over the world. Now, Meta offers a new version of WhatsApp Business, cloud-based and hosted by the parent company, accessible to all businesses, from SMEs to large groups.

Concretely, WhatsApp Cloud API offers free and secure cloud hosting services. This makes it easily and quickly accessible to developers, who therefore do not have to worry about the details of data storage. With this API, the objective is to be able to customize WhatsApp services, through the configuration of different services that adapt to the needs of the company.

So I just developed a java library Opensource that implements some features offered by this api in other to facilitate their effective integration.

Have a look .....

Mastering Maven: Harnessing the Power of Resource Filtering

Diallo Mamadou Pathé — Fri, 25 Aug 2023 12:55:15 +0000

In the world of software development, configuration management is a critical aspect. Maven, a widely used build automation tool, provides a powerful feature known as resource filtering that simplifies this task. In this guide, we'll dive into how to leverage Maven's resource filtering to streamline your project's configuration management.

Project Setup

Let's start by setting up a hypothetical Maven project. Here's the project structure:

my-maven-project/
├── src/
│ └── main/
│ └── resources/
│ └── config.properties
├── pom.xml

Configuring Resource Filtering

In your pom.xml, configure resource filtering under the <build> section:

<build>
   <resources>
       <resource>
           <directory>src/main/resources</directory>
           <filtering>true</filtering>
       </resource>
   </resources>
</build>

The Config File: config.properties

Create a config.properties file in the src/main/resourcesdirectory:

api.url=${api.baseurl}/v1

Defining Properties

Define properties to be used for filtering in your pom.xml:

<properties>
   <api.baseurl>https://api.example.com</api.baseurl>
</properties>

Building the Project

When you build the project using mvn clean install, Maven will perform resource filtering. It replaces ${api.baseurl} in config.properties with the value defined in the <properties>section of the pom.xml.

Result

After the build, the config.properties file in the target directory (where the compiled resources are placed) will look like this:

api.url=https://api.example.com/v1

Conclusion

Resource filtering in Maven makes managing configurations a breeze, allowing you to inject values into resource files during the build process.

Now that you've learned how to harness the power of Maven's resource filtering, you can take control of your project's configurations with ease. This feature is invaluable for managing different configurations for various environments and simplifying your development workflow.

Understanding SOLID Principles with Java

Diallo Mamadou Pathé — Wed, 23 Aug 2023 19:43:27 +0000

Introduction:

SOLID is an acronym that represents a set of five design principles for writing maintainable and scalable software. These principles were introduced by Robert C. Martin and have become fundamental concepts in object-oriented programming. In this blog article, we will explore each of the SOLID principles and provide Java code examples to illustrate their application.

Single Responsibility Principle (SRP):

The SRP states that a class should have only one reason to change. In other words, a class should have only one responsibility.

Let's consider an example where we have a Customer class that handles both customer data and customer-related calculations:

public class Customer {
    private String name;
    private double balance;

    public void setName(String name) {
        this.name = name;
    }

    public void setBalance(double balance) {
        this.balance = balance;
    }

    public double calculateDiscount() {
        // Calculate discount based on balance
        // ...
    }

    public void saveToDatabase() {
        // Save customer data to the database
        // ...
    }
}

In this case, the Customer class violates SRP. We can refactor it into two classes, Customer for data and DiscountCalculator for calculations, to adhere to SRP.

Solution:
Refactoring the Customer class into two separate classes, one for handling customer data and another for calculating discounts, is a great way to adhere to the Single Responsibility Principle (SRP). This separation of concerns makes your code more maintainable and easier to understand. It also allows for better code reuse, as the discount calculation logic can be used elsewhere in your application without duplicating code.

Here's a revised version of the code following this separation:


public class Customer {
    private String name;
    private double balance;

    public Customer(String name, double balance) {
        this.name = name;
        this.balance = balance;
    }

    public String getName() {
        return name;
    }

    public double getBalance() {
        return balance;
    }
}

public class DiscountCalculator {
    public double calculateDiscount(Customer customer) {
        if (customer.getBalance() >= 100.0) {
            return customer.getBalance() * 0.10;
        } 
        return 0.0;
    }
}

In this code, we have a DiscountCalculator class that calculates the discount based on the customer's balance. When you run the program with a customer whose balance is $120, it will calculate and display a $12 discount (which is 10% of $120).

public class Main {
    public static void main(String[] args) {
        // Create a customer with a balance of $120
        Customer customer = new Customer("Alice", 120.0);

        // Create a DiscountCalculator
        DiscountCalculator calculator = new DiscountCalculator();

        // Calculate the discount for the customer
        double discount = calculator.calculateDiscount(customer);

        // Display the discount
        System.out.println("Discount for " + customer.getName() + ": $" + discount);
    }
}

Open/Closed Principle (OCP):

The OCP states that software entities (classes, modules, functions) should be open for extension but closed for modification. This encourages the use of interfaces and abstract classes.

Let's create a simple example:

public interface Shape {
    double area();
}

public class Rectangle implements Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double area() {
        return width * height;
    }
}

public class Circle implements Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }
}

Here, we can easily add new shapes (e.g., Triangle) without modifying existing code.

Liskov Substitution Principle (LSP):

The LSP states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.

Let's demonstrate this with a Java example:

public class Bird {
    void fly() {
        // Default fly behavior
    }
}

public class Sparrow extends Bird {
    @Override
    void fly() {
        // Specific flying behavior for Sparrow
    }
}

public class Ostrich extends Bird {
     // Ostrich cannot fly, so we don't override fly()

}

In this case, the Ostrich class violates the rule. We can refactor it. Here's a corrected example that better illustrates the principle:

public interface Flyable {
    void fly();
}

public class Bird {
    void move() {
        // Default move behavior
    }
}

public class Sparrow extends Bird implements Flyable {
    @Override
    void move() {
        // Specific flying behavior for Sparrow
        System.out.println("Sparrow is flying.");
    }

    @Override
    public void fly() {
        move(); // Call the overridden move method to demonstrate flying
    }
}

public class Ostrich extends Bird {
    @Override
    void move() {
        // Specific running behavior for Ostrich
        System.out.println("Ostrich is running.");
    }
}

public class Main {
    public static void main(String[] args) {
        Sparrow sparrow = new Sparrow();
        Ostrich ostrich = new Ostrich();

        // Demonstrate flying for Sparrow
        sparrow.fly();

        // Demonstrate running for Ostrich
        ostrich.move();
    }
}

Now, we have a Flyable interface, and the Sparrow class implements it by providing the fly method. The Ostrich class, which can't fly, doesn't implement the Flyable interface.

In the Main class, you can see how to use the fly and move methods to demonstrate flying for sparrows and running for ostriches.

Interface Segregation Principle (ISP):

This principle suggests that clients (classes or modules) should not be forced to depend on interfaces they don't use. In other words, it promotes the idea of having smaller, more specific interfaces rather than large, monolithic ones.

Consider a scenario where we have an interface called Worker that represents workers who have both working and eating behaviors:

public interface Worker {
    void work();
    void eat();
}

Now, let's say we have two classes, Engineer and Waiter, that implement this interface:

public class Engineer implements Worker {
    @Override
    public void work() {
        // Engineer-specific work
    }

    @Override
    public void eat() {
        // Engineer-specific eating
    }
}

public class Waiter implements Worker {
    @Override
    public void work() {
        // Waiter-specific work
    }

    @Override
    public void eat() {
        // Waiter-specific eating
    }
}

In this scenario, both Engineer and Waiter must implement both the work and eat methods, even though they may not use both behaviors. This violates the ISP because clients (in this case, the Engineer and Waiter classes) are forced to depend on methods they may not need.

To adhere to the ISP, we can create smaller, more specific interfaces for each behavior:

public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

Now, our Engineer and Waiter classes can implement only the interfaces they need:

public class Engineer implements Workable {
    @Override
    public void work() {
        // Engineer-specific work
    }
}

public class Waiter implements Workable, Eatable {
    @Override
    public void work() {
        // Waiter-specific work
    }

    @Override
    public void eat() {
        // Waiter-specific eating
    }
}

By doing this, we adhere to the Interface Segregation Principle, and clients are not forced to implement methods they don't use. This results in more flexible and maintainable code.

Dependency Inversion Principle (DIP):

The DIP states that high-level modules should not depend on low-level modules; both should depend on abstractions. Let's illustrate this with an example:

public class LightBulb {
    void turnOn() {
        // Turn on the light bulb
    }
}

public class Switch {
    private LightBulb bulb;

    public Switch(LightBulb bulb) {
        this.bulb = bulb;
    }

    void operate() {
        bulb.turnOn();
    }
}

In this case, Switch directly depends on LightBulb, violating DIP. We can introduce an abstraction to decouple them:

Solution:

public interface Switchable {
    void turnOn();
}

public class LightBulb implements Switchable {
    @Override
    public void turnOn() {
        // Turn on the light bulb
    }
}

public class Switch {
    private Switchable device;

    public Switch(Switchable device) {
        this.device = device;
    }

    void operate() {
        device.turnOn();
    }
}

Conclusion:

Understanding and applying the SOLID principles in your Java code can lead to more maintainable, extensible, and robust software. By following these principles, you can improve code quality and make it easier to adapt to changing requirements. Remember that SOLID is not about following rules blindly but about guiding you to write better software.

Open-source Java Wrapper for WhatsApp Cloud API

Diallo Mamadou Pathé — Fri, 27 May 2022 10:04:57 +0000

WhatsApp launches a cloud API accessible to all

With WhatsApp Cloud API, Meta provides a free and secure cloud service to facilitate the work of developers.

Until now, the WhatsApp Business API was reserved for > medium and large companies who wanted to facilitate exchanges with their customers, all over the world. Now, Meta offers a new version of WhatsApp Business, cloud-based and hosted by the parent company, accessible to all businesses, from SMEs to large groups.

So I just developed a java library Opensource that implements some features offered by this api in other to facilitate their effective integration.

The library is on my github repository

The basic functionalities have been implemented and this library will evolve. It will be deployed on the maven central repository soon.

Thanks..

Gérer un projet agile avec Gitlab

Diallo Mamadou Pathé — Sat, 28 Mar 2020 17:03:18 +0000

Définir les types de spécification fonctionnelle

L’ Issue est la notion centrale pour définir une spécification. J’ai choisi de les catégoriser en plusieurs types avec des Labels :

Epic: C’est une macro-fonctionnalité discutée et qualifiée avec les parties prenantes. L’Epic a un format libre et peut être accompagné de wireframe. On affecte un label Ready lorsqu’elle est entièrement validée par le client.

Story : C’est une fonctionnalité discutée et partagée avec l’équipe. Elle est liée à une Epic et suit les critères INVEST. peut avoir du contenu riche comme des liens vers d’autres Issues ou des sous-tâches ou conditions à cocher.

Task : C’est une tâche technique proposée par l’équipe nécessaire à la réalisation d’une Story. Elle suit les critères SMART.
Bug : C’est un problème relevé par l’équipe découvert en cours de développement et qui ne peut être résolu rapidement. Elle nécessite une repriorisation dans le backlog avec le PO.
Organiser le backlog
Gitlab permet de définir des Boards. Le principe est d’afficher un tableau de colonnes appelées Lists qui correspondent chacune à un Label. Nous pouvons faire des glisser-déposer pour modifier le statut d’une Issue. Nous définissons deux Boards, un pour le backlog produit, l’autre pour le backlog de développement.

Le backlog produit s’organise autour des Epics. Il est priorisé avec les labels de statut de la manière suivante :

High,Medium et Low : J’ai défini trois niveaux de priorisation mais cela peut être différent pour votre contexte. Il convient également de limiter le nombre d’EPICs importants et urgents.

Backlog : Une Epic en High passe en Backlog lorsque son périmètre est délimité avec un label Ready et le développement est confirmé avec le client. Ce n’est qu’à ce moment que l’Epic est discuté avec l’équipe et décomposé en Stories.

Rejected : Il est important de garder une trace des idées formulées mais non retenues. L’Epic est généralement clôturé lorsqu’il est rejeté.

Le backlog de développement s’organise autour des Stories. Il est organisé avec des labels de statut sur l’état de développement :

Backlog : Cette liste est partagée avec les Epics ce qui permet de faire la transition entre les deux backlogs. On met un label Draft lorsque la Story est encore en cours de rédaction.

To Do : La Story ou la Task ou le Bug est au préalable discuté, estimée et assignée. Il convient de la prioriser en fonction des dépendances de développement.

Doing : La Story ou la Task ou le Bug est en cours de réalisation par l‘Equipe. Test : La Story ou la Task ou le Bug est développé par l’Equipe, il doit être vérifié par un autre membre de l’Equipe puis par le PO.

Une fois la Story validée par le PO, l’Issue est fermée.

source : https://medium.com/innovation-sandbox-fr/g%C3%A9rer-un-projet-agile-simplement-avec-gitlab-d942193b52c1

How can I redirect after successful post

Diallo Mamadou Pathé — Sat, 28 Mar 2020 16:26:49 +0000

Forem: Diallo Mamadou Pathé

Refactoring with Polymorphism: Say Goodbye to Complex Conditionals

Introduction

The Problem with Conditional Structures

The Solution: Polymorphism

The Benefits of Polymorphism

1. Adherence to the Open/Closed Principle

2. More Readable Code

3. Improved Encapsulation

4. Ease of Testing

5. Extensibility

Practical Application in the Real World

Conclusion

Further Reading

La centralisation freine l’innovation en limitant la diversité, mais favorise la croissance par la commodité et l’efficacité.

Commencer la programmation avec Spring batch

Introduction

Qu'est-ce que Spring-Batch?

Architecture de base de Spring Batch

Configuration du projet

Dépendances du projet

Structure du Projet

Configuration du Job

Configuration du job et de la Step

Définition du Reader

Definition du Processor

Definition du Writer

Fichier de configuration du batch (application.properties)

Fichier CSV à écrire en base de données

Lancement de l'application

Références

Strategy Design Pattern in Java

Demystifying Open Source Contribution: A Beginner's Guide

Understanding ArgumentCaptor in Mockito: A Comprehensive Guide

WhatsApp cloud API for java

WhatsApp launches a cloud API accessible to all

Mastering Maven: Harnessing the Power of Resource Filtering

Project Setup

Configuring Resource Filtering

The Config File: config.properties

Defining Properties

Building the Project

Result

Conclusion

Understanding SOLID Principles with Java

Single Responsibility Principle (SRP):

Open/Closed Principle (OCP):

Liskov Substitution Principle (LSP):

Dependency Inversion Principle (DIP):

Open-source Java Wrapper for WhatsApp Cloud API

WhatsApp launches a cloud API accessible to all

Gérer un projet agile avec Gitlab

How can I redirect after successful post