vendredi 28 juillet 2017

VISER LA PERFORMANCE EN MODE AGILE Part I (Le Rôle du facilitateur)

Satisfaire le client en délivrant régulièrement un logiciel opérationnel et à grande valeur ajoutée, favoriser la collaboration, l’excellence technique et la simplicité, en encouragent un rythme soutenable. l’ensemble étant sous-tendu par la mise en place d’une politique d’amélioration continue.




« favoriser, encourager et soutenir » sont donc les mots d’ordre du manager agile. il devient un facilitateur au service d’une équipe qui doit parvenir à s’auto-organiser.

Faciliter, cela consiste à aider un groupe, une ou des personnes, à apprendre, explorer, trouver des solutions, atteindre un consensus…

La posture de facilitateur vise à améliorer le fonctionnement d’un groupe pour garantir l’atteinte des objectifs. 

Plusieurs principes guident cette posture : le respect des contributions de chacun, que ce soit dans le monde des idées ou dans le monde des actions. 

Le manager quitte sa position « haute » de celui qui réfléchit et décide pour les autres au bénéfice d’une position « basse » qui aide les collaborateurs à réfléchir et décider.

Sources : 

mardi 11 juillet 2017

La check-list Code Performance

La check-list Performance


Quelques points à vérifier :

  • Les objets sont dupliqués uniquement lorsque cela est nécessaire. Si vous devez dupliquer des objets, envisagé de mettre en œuvre Clone et décider si le clonage profond est nécessaire.
  • Pas de boucles d'attente avec des traitements lents -> favoriser des méthodes en asynchrone et les Threads. 
  • Évitez les gros objets en mémoire ou utilisez la classe String pour contenir de gros documents qui devraient être manipulés avec de meilleurs outils. Par exemple utiliser StringBuilder/StringBuffer au lieu de String.
  • Ne laissez pas le code de débogage dans le code de production.
  • Évitez les System.out.println (); dans le code, -> enrouler les logs dans une déclaration de conditionnement booléen comme if(DEBUG) {...}
  • "L'optimisation qui rend le code plus difficile à lire ne doit être implémentée que si un profiler ou un autre outil a indiqué que la fonctionnalité doit être optimisée. Ces types d'optimisations devraient être bien documentés et le code qui effectue la même tâche devrait être conservé". - UNKNOWN.

jeudi 6 juillet 2017

Quelques bonnes pratiques concernant l'utilisation des exceptions



Ne jamais ignorer une exception


//traitement susceptible de lever une exception
        }catch(Exception ex){
            ex.printStackTrace(); //il faut pas ignorer
        }

Ne pas utiliser la clause throws de manière exhaustive

public void funAction() throws A, B, C { // trop d'exceptions sur le throws
    //corps de la méthode
}

Les exceptions ne sont pas faites pour le contrôle de flux

while(true){
//faire quelque chose
if(condition d'arrêt)
throw new FinDeLaBoucleException(); // ne pas utiliser les exceptions pour controler le flux
}

Attention au return dans un bloc finally !

public int methode(){
try{
return 3;
}finally{
return 4; // pas de return dans un block finally
}
}

Eviter le catch Error ou Throwable

try {

} catch (Error e) { // pas de catch Error ou Throwable
System.out.println("Une erreur est survenue : " + e);
}

lundi 18 mai 2015

Road to the Cloud (3) : Monolith Vs Microservices Applications (1)

Road to the Cloud (3) : Monolith Vs Microservices Applications

Monolithic architecture (monolithic architecture pattern)

"une seule brique avec tout les services ... et un seul WAR"

Avantages :

- Simple
- La scalabilité est obtenue à travers un cluster / load balancer

Inconvenants : 

- Le code source devient énorme a travers le temps donc difficile a lire et a comprendre ... le développement devient lent, l’environnement de développement aussi.
- Comme l'application devient énorme l’intégration continue doit être moins fréquente car il faut compilé et déployé tout le code.
- La scalabilité devient difficile car elle peut ce faire uniquement en verticale donc achat des serveurs plus performants.
- A long terme l'entreprise va être forcé à utiliser les mêmes technologies car puisque l'application devient énorme le coût du changement de technologie devient grand.

Microservices architecture (microservices architecture pattern)

"plusieurs briques indépendantes avec un système de communication entre eux ... plusieurs WARs"



Avantages :

- Une scalabilité horizontale et verticale (déploiement sur un ou plusieurs serveurs/JVMs.)
- Facile à comprendre et à gérer car chaque partie du code est presque indépendante.
- Le développement devient plus rapide car l'utilisation de l’environnement de développement et déploiements/tests deviendrons plus rapides.
- Chaque application peut être développé/amélioré et déployé indépendamment des autres.
- Les problèmes rencontrés en "run-time" sur une brique n'affecterons pas tout le système donc ça augmente la disponibilité.
- L'obligation de garder la même technologie au fil du temps n'est plus d'actualité.

Inconvenants :

- Nécessite une bonne coordination entre les équipes qui travaillent sur différentes briques.
- Il faut développer et gérer un système de communication entre les briques.
- Des scénarios de tests plus complexe.
- La transformation des transactions distribuées en use cases est assez difficile.
- Complexité de gérer et déployé des briques avec peut être différentes technologies.


Une solution pour l'existant

Pour les applications existantes qui souffrent de problèmes de scalabilité et lenteur ce qu"on peut retenir c'est que à un moment le coût de la scalabilité verticale va explosé (upgrade des serveurs pour gérer la demande qui augmente avec le "computing everywere" ...)


La solution est de faire sortir la ou les briques qui consomment le plus de ressources a fin de pouvoir les déployées séparément.

La séparation doit se faire au niveau du code aussi a fin de pouvoir l'améliorer et changer les technologies utilisées pour augmenter la performance.










vendredi 15 mai 2015

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Le pourquoi: Assurer l’intégration, la performance, et la qualité du code avec les outils suivants : 

Jenkins (un "fork" open source de hudson / outil d'intégration continue).
JUnit (tests unitaires).
JMeter (test de charges).
PMD (la définition de nombreux règles qui assurent la qualité de code).
Maven (La gestion des dépendances et automatisation de la production).

A chaque "build" l'application est compilée, analysée ,testée (JUnit), déployée et re-testée (JMeter).


Les résultats des analyses sont disponible juste après :



PMD :
JMeter :
JUnit :
Maven permet d'automatiser le tout en définissant un ou plusieurs fichiers POM (pom.xml) qui contient le nom du projet, le numéro de version, les dépendances vers d'autres projets, les bibliothèques nécessaires à la compilation, les noms des contributeurs etc.

 <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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>spring</artifactId>
<version>0.0.2-SNAPSHOT</version>
<packaging>war</packaging>
<name>test</name>

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.1.6.RELEASE</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>WebContent\WEB-INF\web.xml</webXml>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat6-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<url>http://localhost:8090/manager</url>
<server>TomcatServer</server>
<path>/SpringMavenCLITest</path>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<targetJdk>1.6</targetJdk>
<linkXref>false</linkXref>
<failOnViolation>false</failOnViolation>
<failurePriority>1</failurePriority>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
<goal>cpd-check</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>1.10.1</version>
<executions>
<execution>
<id>jmeter-tests</id>
<phase>verify</phase>
<goals>
<goal>jmeter</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.11</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>2.12</version>
</dependency>
</dependencies>
<configuration>
<includes>
<include>**/*.class</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>2.3</version>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<linkXRef>false</linkXRef>
<targetJdk>1.6</targetJdk>
<rulesets>
<ruleset>/rulesets/basic.xml</ruleset>
</rulesets>
</configuration>
</plugin>
</plugins>
</reporting>

</project>



 Pour finir il faut configurer jenkins pour démarrer notre intégration continue.









mercredi 6 mai 2015

Road to the Cloud (2) : Twelve-Factor Applications

Road to the Cloud (2) : Twelve-Factor APP

Le "Twelve-Factor App" est un ensemble de design patterns qui déterminent si une application à une architecture "cloud-native" donc architecturalement destiné à profité des avantages que propose le cloud c-a-d rapidité robustesse et scalabilité.



Codebase

Un dépôt centralisé et unique avec gestion de version et multiples déploiement (plusieurs versions peuvent être déployées au même temps).


Dependencies

La gestion des dépendances via un outil approprié ex: Maven, NPM ...

Config

La configuration, ou tout ce qui est susceptible de différer entre
des environnements de déploiement est injecté via des variables d'environnement au niveau du système d'exploitation.

Backing services

Les services de sauvegarde (ex : base de données ...) doivent être considérés comme ressources attachées et consommées dans tous les environnements de la même façon.

Build, release, run

Les processus "Build/release/run" doivent être séparés et indépendants.

Processes

L'application doit s'exécuté comme un ou plusieurs "stateless process" qui ne partagent absolument rien entre eux. toute relation possible doit être externalisée (ex cache, base de données).

Port binding

L'application doit être "self-contained" (tout les composants nécessaires doivent être packagés/emballés dans même installation)  et expose tous ces services via "port binding".

Concurrency

Les processus doivent être "mis à l’échelle" horizontalement à fin de résoudre les problèmes de concurrences.

Disposability

La robustesse est garanti à travers des processus qui redémarre rapidement et se termine correctement.

Dev/prod parity

Les environnements Dev, Pré Prod  et Production doivent être très proche voir similaire.

Logs

Au lieu de gérer des fichiers logs, il faut gérer les logs autant qu'événements stocker centralement pour indexation et analyse.

Admin processes

Les tâches administratives ou de gestions, tels que les migrations de bases de données, sont exécutés en tant que processus ponctuels "one-off" dans des environnements identiques.











lundi 27 avril 2015

Road to the Cloud (1) : NoSQL / Hibernate OGM (Object/Grid Mapper)

Road to the Cloud (1) : NoSQL / Hibernate OGM (Object/Grid Mapper)


Le 2015-02-27 a connu le lancement de la version stable du framework Hibernate pour les bases de données NoSQL appelé Hibernate OGM le but est de porté la facilité de développement JPA au monde NoSQL ainsi les développeurs familiarisés avec JPA n'aurons aucun problème à changer de cape.

Le pourquoi : une scalabilité horizontale et évolutivité.


- Un schéma flexible capable d'accepter les changements plus facilement (Evolution).
- Un système facilement distribué sur plusieurs serveurs. (le besoin supplémentaire en stockage ou en montée en charge se traduit simplement par l’ajout de nouveaux serveurs).



Donc si vous visez de porter votre application vers le cloud et d'avoir des milliers d'utilisateurs (Données) a moindre coût le choix du NoSQL est obligatoire.

L'architecture Hibernate OGM permet l'utilisation des requêtes JP-QL en les transformant en requêtes DataStore donc le développeur n'aura pas a écrire des requête NoSQL, donc même réutiliser l'existant.



La définition des beans avec annotations JPA/EJB3 reste la même sauf l'introduction de hibernate search qui pourra aussi être un autre moyen de recherche.


Exemple de requête JP-QL simple : 

                EntityManager emSearch = emf.createEntityManager();
Query query = emSearch.createQuery("from Data d where d.name like :name")
.setParameter("name", "XXX%");

Exemples de requête DataStore Ex: MongoDB: 

- Update du montant :
db.Data.update({ "_id" : NumberLong(351) },{ "$set" : { "montant" : "1" } },false, false )

- Delete par ID :
db.Data.remove({ "_id" : NumberLong(143) })

- Recherche Par ID : 
db.Data.find({ "_id" : NumberLong(143) })


- Insert des données :
db.Data.insert({"_id" : NumberLong(131300),"montant" : "0.16364626911022928101857587535050697624683380126953125","description" : "Description2134956245","name" : "Name170565634","date" : ISODate("2015-04-17T10:36:46.583Z"),"parent_id" : NumberLong(13118),"rows" : [NumberLong(13123),NumberLong(13122),NumberLong(13125),NumberLong(13124),NumberLong(13127),NumberLong(13126),NumberLong(13129),NumberLong(13128),NumberLong(13119),NumberLong(13121),NumberLong(13120)]})

- Recherche par champs Name :
db.Data.find({ '$query' : { "name" : "Name-414524582" ,  "_id" : NumberLong(13) }})

- Recherche ID >13 et ID < 130  :
db.Data.find({ '$query' : { "_id" : { $gt: NumberLong(13), $lt: NumberLong(130) } }})

- Recherche par objet incorporé :
db.Data.find({"location.y" : "Y-400967006"} )


Les bases de données suivantes sont supportées : couchDb, mongodb, ehcache, infinispan, neo4j.

Pour l'exemple nous allons utilisé la base données MongoDB :


Pour la visualisation les données le plugin eclipse MonjaDB :


Le Fichier Persistence.xml : 



Télécharger l'exemple : Test APP