mardi 13 avril 2010

Guide de revue de code

Ci dessous un memorandum sur les points qui ont été mis en défaut sur des projets réel avec des conséquences réelles sur les charges et le planning du projet.

Chacun de ces points est à mettre en oeuvre le plus tôt possible, plus le temps passe et plus le coût est élevé pour revenir dans une démarche de qualité.

Bonne pratiques de développement


Structuration des projets


Un projet devrait contenir un minimum de dépendances entre les modules. La seule raison motivant un découpage de garantir l'indépendance des cycles de vie. Un projet IHM possédants des script de traitement par lot devrait être structuré de la manière suivante :

- Un projet-parent
- Un projet dao + business + service
- Un projet IHM (war)
- Un projet batch
- Un projet factorisant le code de test (Constitution de jeu de test)
- Un jeu de test de référence
- Un jeu de test restreint
- Un jeu de test à volumétrie normale

Recommandations


Utiliser des interfaces uniquement si nécessaire, quand il existe une probabilité réelle qu'une interfaces ait plusieurs réalisations.
Ne pas se servir des exceptions pour remonter des codes d'erreurs.

Bonnes pratiques de codage de tests unitaires


Un test unitaire doit pouvoir partir d'une base vierge
Dans les tests junits dérivés de spring, vérifier que les méthodes d'extraction communes sont dans la méthode onSetUp().
Penser à valider le programme par des jeux de test importants. Si certains tests génèrent des erreurs en occupant trop de mémoire, il vaut mieux ne pas masquer le problème en augmentant la taille mémoire sur la machine de développement. Sur le long terme, il vaut mieux résoudre résoudre le problème par la conception sans utiliser la puissance du matériel.

Bonnes pratiques d'écriture


La manière de coder peut améliorer la reprise du code dans le cas de maintenance. Il est possible d'utiliser des outils de type checkstyle ou PMD. Toutefois, ces outils ne sont pas toujours pertinents parce que trop verbeux.
Formater le code de manière homogène en utilisant un outils de formatage automatique
Mettre des commentaires quand c'est nécessaire
Sur la couche DAO : vérifier que les noms de méthode sont cohérents entre eux
Vérifier que les noms de variables permettent de deviner leur contenu
Vérifier que les tests unitaires donne des messages explicite en cas de plantage (pas de fail sans argument)
Ne pas utiliser les séquences : « ? : » pour les tests if. Toujours mettre des crochets

lundi 22 mars 2010

Merger à l'aide de SVN

Utilisation des patch dans SVN



Avec SVN, pour reporter les modifications d'une branche vers une autre. Il existe plusieurs méthodes :

  • La commande merge fournie avec SVN (Méthode recommandée): Cette méthode ne s'applique que si les fichiers modifiés sont connecté au référentiel SVN, mais ce moyen est le plus simple.
  • Méthode utilisant l'IDE eclipse : Elle présente des avantage pour la représentation de changes. Contrairement à ce que l'on pourrait croire, il s'agit rarement de la méthode la plus simple, en effet le fourmillement d'options sur une GUI entraine une certaine confusion.
  • Méthode basée sur les fichiers de patch : cette méthode utilise le standard udiff et peux s'appliquer sur des fichiers n'étant pas connectés au référentiel de source. Cette méthode n'est pas automatique mais elle est souple.

Pour illustrer un report nous allons utiliser l'exemple d'un report d'une correction de bug sur la branche en maintenance (lot 1) vers la branche en cours de développement (lot 2), la branche lot 2 est en cours de développement, c'est donc le tronc.




De The French Hack


Cette opération s'effectue en 5 temps :

  • Récuppération du numéro de révision
  • Checkout de la branche sur laquelle le report est effectué
  • Report des modifications et fusion
  • Résolution des conflits
  • Commit

Méthode en ligne de commande utilisant subversion (Méthode recommandée)



La première opération consiste à repèrer dans l'historique la version à partir de laquelle nous souhaitons effectuer le report. Nous pouvons nous baser sur les dates de modifications, les commentaires, les dates de création de branches... tou ce qu'on veut !

bash> svn log -r{20100401}:HEAD http://svnserver/my-product/developpement/branches/my-module-dao-lot1

Récuppération du numéro de révision


Problème des droits acces
------------------------------------------------------------------------
r3389 | zegugusse | 2010-04-28 12:15:38 +0200 (mer, 28 avr 2010) | 1 line

Le montant des couts pour que les valeurs jusqu'a 9 999 999 999 puissent etre stockées et non arrondies
------------------------------------------------------------------------
r3390 | zegugusse | 2010-04-29 09:25:29 +0200 (jeu, 29 avr 2010) | 1 line

Problème des droits
------------------------------------------------------------------------
r3394 | zegugusse | 2010-05-04 09:12:01 +0200 (mar, 04 mai 2010) | 2 lines


------------------------------------------------------------------------
r3394 | ungusse | 2010-05-04 09:12:01 +0200 (mar, 04 mai 2010) | 2 lines

Création des branches lot2

------------------------------------------------------------------------
r3397 | ungusse | 2010-05-04 09:12:33 +0200 (mar, 04 mai 2010) | 1 line


------------------------------------------------------------------------
r3528 | ungusse | 2010-05-26 12:09:30 +0200 (mer, 26 mai 2010) | 2 lines

Ajout des codes d'erreur

------------------------------------------------------------------------
r3574 | lotrgusse | 2010-06-01 15:25:34 +0200 (mar, 01 jun 2010) | 1 line

Ajout du libellé long . Change D76.
------------------------------------------------------------------------
r3577 | zegugusse | 2010-06-01 16:09:25 +0200 (mar, 01 jun 2010) | 1 line

Defect Client D58
------------------------------------------------------------------------
r3579 | lotrgusse | 2010-06-01 17:35:41 +0200 (mar, 01 jun 2010) | 1 line

Modification du comportement de l'écran de sélection des cibles.
------------------------------------------------------------------------
r3583 | zegugusse | 2010-06-02 12:22:50 +0200 (mer, 02 jun 2010) | 1 line

Defect Client D58
------------------------------------------------------------------------


Checkout de la branche sur laquelle le report est effectué




svn co http://svnserver/my-product/developpement/branches/my-module-branch my-module-dao-trunk-workcopy


Report des modifications et fusion


Maintenant, nous allons reporter les changements intervenu sur la branche my-module-branch entre les versions 1000 et la HEAD


svn merge -r1000:HEAD http://svnserver/my-product/developpement/branches/my-module-dao-lot1 my-module-dao-trunk-workcopy

  • Le premier paramètre (http://svnserver/my-product/developpement/branches/my-module-dao-lot1) indique la branche d'ou est effectué le rapport
  • Le second paramètre (my-module-trunk-workcopy) est le chemin du repertoire sur lequel le report est appliqué



Voici le résultat :

[hudson@vm01 ~]$ svn merge -r2650:HEAD http://svnserver/my-product/developpement/branches/my-module-dao-lot1 my-module-dao-trunk/
U my-module-dao-trunk-workcopy/src/sql/data/load-ref-dev.bat
U my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/service/common/impl/UtilisateurServiceImpl.java
C my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java
U my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/business/projet/impl/ProjetBusinessImpl.java
G my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/business/objectif/impl/ObjectifBusinessImpl.java
C my-module-dao-trunk-workcopy/pom.xml



  • U indique que nous avons procédé à un update
  • G indique que nous avons procédé à une fusion sans conflit
  • C indique un conflit


Ensuite nous pouvons observer le resultat à l'aide de la commande : svn st


[hudson@vm01 ~]$ svn st my-module-dao-trunk-workcopy
? my-module-dao-trunk-workcopy/pom.xml.fusion-gauche.r2650
? my-module-dao-trunk-workcopy/pom.xml.courant
? my-module-dao-trunk-workcopy/pom.xml.fusion-droit.r2862
M my-module-dao-trunk-workcopy/src/sql/data/load-ref-dev.bat
M my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/service/common/impl/UtilisateurServiceImpl.java
? my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java.courant
? my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java.fusion-droit.r2862
? my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java.fusion-gauche.r2650
C my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java
M my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/business/projet/impl/ProjetBusinessImpl.java
M my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/business/objectif/impl/ObjectifBusinessImpl.java
C my-module-dao-trunk-workcopy/pom.xml


  • M indique que le fichier est modifié (Un check in est nécéssaire)
  • C indique un conflit (Il est nécessaire résoudre)


Résolution des conflits


Avec un éditeur résoudre les conflit dans my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java puis indiquer que le conflit est résolu


vi my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java
svn resolved my-module-dao-trunk-workcopy/src/main/java/com/mycompany/jt/dao/BuildingSecondaireDAO.java

Commit


Pour finaliser, il faut commiter nos modifications

svn ci my-module-dao-trunk-workcopy/



Méthode se basant sur les fichiers de patch



Sous UNIX, une ligne de commande génère ces fichiers de patch :

svn diff http://svnserver.mycomp/my-product/developpement/trunk/my-project -rN:M

N est la version d'origine M est la version cible.

Pour appliquer ces patchs, se plaçer à la racine du projet à patcher, utiliser la commande :

patch -p0 >mypatchfile

où p est la profondeur


Méthode sur eclipse



Contrairement à ce que l'on pourrait croire, l'utilisation d'eclipse peut être plus difficile que celle de la ligne de commande.


  • Se placer sur la branche sur laquelle on souhaite effectuer les reports.





  • Choisir l'ensemble des révisions à reporter. Autrement, l'option starts from copy reporte l'ensemble des modification depuis la création de la branche (ce qui peut n'être pas adéquat dans le cas où la branche à subi plusieurs recopies)







  • Preview permet de voir quelle sont les révision concernées :








jeudi 7 janvier 2010

Mysql en case insensitive sur linux Red hat

Dans le fichier my.ini, sous la section mysqld, ajouter la ligne suivante :

lower_case_table_names=1

mercredi 2 décembre 2009

Install Mysql from the zipped installation

Customize a MySQL installation from a zip file is easy :

Look in the configuration file and set the path in it correctly.


"D:\myproject\MySQL\MySQL Server 5.1\my.ini


Once done, you can set it up as a windows service using the simple command line


"D:\myproject\MySQL\MySQL Server 5.1\bin\mysqld.exe" --install
"D:\myproject\MySQL\MySQL Server 5.1\bin\mysqld.exe" --remove


Change the root password



mysqladmin -u root password NEWPASSWORD

lundi 30 novembre 2009

Configuring JNDI Javamail resource over SSL for SMTP

You declare your JAVAMAIL resource into the server.xml (or in the appropriate context file in your configuration directory) file of your tomcat :

              <Resource name="mail/MailServer" auth="Container"
type="javax.mail.Session"
mail.smtp.host="smtp.mailserver"
mail.smtp.port="465"
mail.smtp.auth="true"
mail.smtp.user="myuser"
password="mypassword"
mail.smtp.starttls.enable="true"
mail.smtp.socketFactory.class="javax.net.ssl.SSLSocketFactory"
/>


Then your resource is accessible via this URI in your webapp :

java:comp/env/mail/MailServer


Also, you must copy the two files
activation.jar and mail.jar in your tomcat common/lib server.

You may refer to the JIRA documentation where I had this hint

http://www.atlassian.com/software/jira/docs/v3.13/smtpconfig.html

mercredi 30 septembre 2009

Définition ORACLE

Définitions :

Instance :

Une instance oracle est un processus destinée à servir les données.
Listener :
Un listener est un processus gérant les connexions lourdes de sql net. Le listener n'est pas indispensable pour faire fonctionner le JDBC
Tablespace :
Un Tablespace est la définition d'un espace sur le système de fichier contenant les données. Dans les bases de données modernes, la notion de Tablespace est plus discrète, car elle ne fait pas référence au données mais au système.
User :
Un user est un espace de table. La notion de schema qui est beaucoup parlante est identique à celle du user.
Database :
Est un ensemble de schémas.

mercredi 16 septembre 2009

Débuter en JSF

Faire un tag combobox :

myCommandBean est le nom du bean mise en correspondance la combobox. #{myCommandBean.myfield} est le nom du champ qui stocke l'information.

<h:selectOneListbox  id="myCommandBean"          binding="#{myCommandBean.myfield}" size="1" >
<f:selectItems
value="#{myCommandBean.myfieldList}" />
</h:selectOneListbox>


Le fichier face-config.xml contient la configuration de Jface :

<managed-bean>        
<managed-bean-name>myCommandBean</managed-bean-name>
<managed-bean-class>com.mybusiness.MyCommandBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>


Ces lignes permettent de déclarer le bean de stockage des informations de la combo box dans la session. Les valeurs affectée à ce bean pourront être exploitée durant toute la session. C'est une bonne idée que d'utiliser ce scope par défaut.

public List getMyfieldList() {
List list = new ArrayList();
list.add(new SelectItem("01", "moncul"));
list.add(new SelectItem("02", "machemise"));
return list;
}


Le getter dans le bean com.mybusiness.MyCommandBean utilise une propriété HtmlSelectOneListbox


public HtmlSelectOneListbox getMyfield() {
return myfield;
}

public void setMyfield(HtmlSelectOneListbox myfield) {
this.myfield = myfield;
}