Overblog Suivre ce blog
Administration Créer mon blog

Flex et Maven: installer le Flex-SDK dans votre repository Maven

30 Novembre 2011 , Rédigé par benkirane Publié dans #La technologie Flex

Une des premières difficulté lorsqu'on souhaite industrialiser des applications Flex est l'installation des dépendances Flex dans le repository Maven propre à votre entreprise. Cette démarche n'est pas recommandé du tout par Adobe lorsqu'on lit, par exemple, une des seules pages "officielles" du Web qui parlent de Flex et Maven: https://docs.sonatype.org/display/FLEXMOJOS/Installing+Flex+SDK+into+maven+repository. Pour vous aider dans cette démarche, un très bon lien vers un repository Github qui fournit un script et des fichiers de description pour l'installation des dépendances Maven du Flex-SDK est à suivre => https://github.com/piercer/flex_sdk_maven_install.

Un article de l'auteur du repository se trouve à l'adresse suivante http://www.dz015.com/?p=419.

Par contre, je vous conseille de positionner plutôt le repository Maven de Sonatype dans votre fichier settings.xml. Celui-ci fournit la plupart des dépendances nécessaires au bon fonctionnement des applications Flex. Ajouter, pour cela, les lignes suivantes dans votre fichier settings.xml autour des balises <repositories>:

<repository>
       <id>sonatype</id>
       <name>Sonatype Repository for Flex dependancies</name>
       <url>https://repository.sonatype.org/</url>
       <releases>
              <enabled>true</enabled>
       </releases>
       <snapshots>
              <enabled>false</enabled>
       </snapshots>
</repository>

Pour effectuer convenablement cette installation, il vous faudra aussi le plugin Maven bundle-publisher-maven-plugin qui se trouve à cette adresse :

http://mirrors.ibiblio.org/pub/mirrors/maven2/org/sonatype/plugins/bundle-publisher-maven-plugin/1.1/bundle-publisher-maven-plugin-1.1.jar

Pour l'installer manuellement, la commande maven est :

mvn install:install-file -Dfile=<path-to-file>/bundle-publisher-maven-plugin-1.1.jar -DgroupId=org.sonatype.plugins \
-DartifactId=bundle-publisher-maven-plugin -Dversion=1.1 -Dpackaging=maven-plugin


Lire la suite

Java EE 5 : tutoriel très complet

22 Novembre 2011 , Rédigé par benkirane Publié dans #La technologie Java-JEE - Documentations

Un tutoriel très complet sous forme de documentation pour le développement Java EE 5 est disponible sur le site d'Oracle à l'adresse suivante: http://download.oracle.com/javaee/5/tutorial/doc/docinfo.html
Lire la suite

Consultation des données d'un annuaire LDAP: le freeware JXplorer

10 Novembre 2011 , Rédigé par benkirane Publié dans #Les outils

Dans le cadre de développements en connexion avec un anuaire LDAP, il est toujours important d'avoir un outil de consultation des données. Je vous propose un outil qui fait bien le travail et très simple à utiliser. Il est open-source et écrit en Java. Cet outil est JXplorer et vous pouvez le télécharger sur le site officiel: JXplorer.

Lire la suite

Debuggage TCP/IP ou HTTP: le plugin TCP/IP Monitor d'Eclipse

9 Novembre 2011 , Rédigé par benkirane Publié dans #Les outils pour le debbuguage

Sur certains projets, il peut être très intéressant de voir les requêtes LDAP ou autre qui passent sur le réseau soit en TCP ou en HTTP. Pour cela, un outil très simple à utiliser existe. Il s'appelle TCP/IP Monitor et c'est un plugin d'Eclipse.

Pour paramétrer, par exemple, la possibilité de voir les requêtes vers un annuaire LDAP faite depuis votre poste local. Il suffit de modifier le hostname du serveur LDAP de l'application que vous êtes entrain de tester en le positionnant sur localhost. Ensuite, vous pouvez configurer TCP/IP Monitor afin qu'il serve de proxy entre votre machine et le serveur LDAP distant. La procédure est la suivante:

  • ouvrez TCP/Monitor dans Eclipse en cliquant sur Window -> Show View -> Others. Taper alors TCP pour retrouver le plugin (sinon faut l'installer). Cliquez dessus
  • la fenêtre suivante s'affiche alors:

Fenêtre TCP/IP Monitor Cliquez sur le bouton Add.. pour ajouter une nouvelle redirection de port.

  • la copie d'écran suivante illustre la manière de configurer cette redirection.

Configuration de TCP/IP Monitor

Voilà TCP/IP Monitor est prêt à recevoir toute les requêtes destinés à votre serveur LDAP pour peu que vous aillez bien configurer votre application comme décrit plus haut.

Lire la suite

Oracle SQLPlus : démarrer une instance Oracle

7 Novembre 2011 , Rédigé par benkirane Publié dans #Divers trucs et astuces pour Oracle

Pour démarrer une instance Oracle incluant les listeners, il faut suivre les étapes suivantes:

  1. Se connecter à SQL Plus en mode DBA (il faut bien sûr avoir les droits) en lançant la commande suivante: sqlplus / "as sysdba "
  2. Lancer ensuite la commande startup pfile=<chemin vers le fichier d'initialisation .ora>/<nom fichier d'initialisation de la base>.ora
Lire la suite

Ma compréhension de SCRUM: le déroulement d'un projet

4 Novembre 2011 , Rédigé par benkirane Publié dans #La gestion de projets

Dans mon billet précédent, j'ai présenté les fondamentaux du framework SCRUM. Aujourd'hui, je continue sur les aspects théoriques avec le déroulement d'un projet SCRUM.

Comment se déroule un projet SCRUM?

Dans les grandes lignes, un projet SCRUM se déroule en 5 étapes que je détaillerais dans la suite du billet:

  1. Etape 1: la Réunion de Planification de version ou Sprint 0,
  2. Etape 2: la Réunion de Planification du Sprint,
  3. Etape 3: le Sprint, cette étape ainsi que la précédente sont itératives. Elles peuvent donc être reproduites N fois jusqu'à la décision par le PO de terminer le produit.
  4. Etape 4: la Revue de Sprint,
  5. Etape 5: La Rétrospective.

Le schéma ci-dessous résume, visuellement, ces 5 étapes. Scrum Planning

Que fait-on pendant pendant la Réunion de Planification de version (Sprint 0) et qui sont les acteurs présents ?

Dans la réalité, avant la réalisation d'un projet SCRUM, il faut commencer, comme pour un projet traditionnel, par une analyse plutôt high level des besoins. La Réunion de Planification de version peut alors avoir lieu. L'objectif de celle-ci est d'élaborer le backlog initial et planifier la release. Pour cela on mettra en œuvre des pratiques comme la vision du produit, la priorisation du Backlog, l'identification des risques, la décomposition en user stories, l'estimation de l'effort en points, la définition de fini et de la durée des itérations, le planning de la release, la formation de l'équipe (s'il y a lieu), l'organisation de l'espace de travail. Pour chaque User Story, on devrait pouvoir calculer un ratio Valeur Business de la US / Effort qui est le ROI.

Que fait-on pendant pendant la Réunion de Planification du Sprint et qui sont les acteurs présents ?

Une fois le Backlog initial élaboré, la Planification du Sprint peut alors commencer. L'équipe sous la Direction du SM (Direction dans le sens orientation) choisit les US qui ont les ROI les plus élevés comme premières à réaliser dans le premier Sprint. Une fois ce que l'équipe a accumulée une somme d'effort qu'elle est capable de fournir pendant la durée d'un Sprint, elle positionne les autres US dans les Sprints suivants. L'équipe construit alors le Sprint Backlog qui représente l'ensemble des fonctionnalités à réaliser pendant le Sprint. Chaque US est alors découpée en tâches techniques élémentaires qui seront à leur tour estimée. L'élaboration de cet artefact est le principal objectif de cette Réunion. Le PO peut y assister à titre consultatif.

Comment se déroule un Sprint ?

Le Sprint est l'étape de réalisation du projet SCRUM par excellence. Il peut durer de 2 semaines à 2 mois en fonction du contexte de projet et de sa complexité. Ceci dit il faut bien garder à l'esprit que le principe est de livrer à la fin du Sprint une première version du logiciel qui fonctionne incluant l'ensemble des fonctionnalités contenues dans le Sprint Backlog. Pendant le Sprint, tous les matins (de préférence), pendant 15 mins maximum, un Daily Scrum Meeting a lieu pour voir l'état d'avancement des tâches. Chacun doit répondre à trois questions: quelles sont la(les) tâche(s) terminée(s) la veille s'il y en a ? quelles sont la(les) tâche(s) du jour ? quels problèmes ont été rencontrés ? En cas de problème, le SM doit mettre en oeuvre des actions pour les résoudre au plus vite. Pendant toute la durée du Sprint, les résponsabilités suivantes sont attribuées:

  • le SM doit garantir que l'équipe n'est pas perturbée par des sollicitations extérieures. Il doit aussi garantir qu'elle a sa disposition tous les moyens pour travailler et faire avancer les différentes tâches.
  • le reste de l'équipe réalise concrètement chacune des tâches qu'il a indiqué effectuer pendant le Daily Scrum Meeting.

A quoi sert la Revue de Sprint et qui sont les acteurs présents ?

La Revue de Sprint sert principallement à faire une démonstration du produit réalisé pendant le Sprint. Ceci même si le produit n'impémente pas toutes les fonctionnalités ciblées dans le Product Backlog. En ce basant sur ce dernier comme support, l'objectif est de montrer les fonctionnalités terminées à 100%, les fameuses User Stories afin de déterminer celles qui sont achevées. Dans l'idéal, c'est au PO de faire cette démonstration mais n'importe quel membre de l'équipe pourra la faire. Dans tous les cas, l'équipe doit être présente afin d'écouter, en direct, les remontées de l'assistance et d'intéragir avec elle. Il faudra veiller à bien préparer la démonstration avant que le public n'arrive. Ceci afin d'éviter les temps d'attente trop long avant le début de la démonstration. Celle-ci est destinée à un public parfois extérieur au projet, il faudra donc bien expliquer son contexte, celui de la démonstration, les données utilisées (données les plus explicites possibles), les fonctionnalités implémentées, etc... En cas de bug ou de problème lors de la démonstration, il faut le dire explicitement, éviter les "ça marchait il y a 10 minutes". La transparence est une valeur importante de la Revue de Sprint. Elle permet aussi de voir les fonctionnalités qui marchent bien et celle qu'il faudra revoir pendant le Sprint suivant ou tout simplement abandonner à l'initiative du PO.

A quoi sert la Retrospective et qui sont les acteurs présents ?

A la fin du Sprint, l'équipe dans son ensemble se réunit avec les développeurs, le SM, le PO et même le client. Cette réunion permet de faire un point sur le Sprint qui vient de se dérouler dans sa globalité. Les éléments suivants sont discutés:

  • ce qui s'est bien passé pendant le Sprint,
  • ce qui ne n'est pas bien passé et qu'il faudra améliorer:mettre en place un plan d'actions à la charge de l'équipe à suivre pour cette amélioration,
  • ce qui reste de l'ordre de l'inconnu.

Cette réunion est un axe d'amélioration important pour l'équipe toujours dans le but de satisfaire au mieux, non seulement, les exigences du client mais aussi le travail de l'équipe elle-même.

Lire la suite

Ma compréhension de SCRUM: les fondamentaux

3 Novembre 2011 , Rédigé par benkirane Publié dans #La gestion de projets

J'ai participé la semaine dernière à une formation de 2 jours sur SCRUM. Ne pouvant mettre en pratique tout de suite mon apprentissage, je me suis dis qu'il serait intéressant d'en faire quelques billets qui résument ma comprehension de SCRUM. Les deux premiers présenteront les aspects théoriques de SCRUM avec un premier billet sur les fondamentaux de SCRUM et un second sur le déroulement d'un projet SCRUM. Les billets qui suivront seront plus axés sur ma vision de SCRUM dans la pratique.

Qu'est ce que SCRUM ?

SCRUM est un framework qui décrit un ensemble d'acteurs et leur rôle, d'artefacts (les inputs et outputs de projet) et de time-boxes (événements à durée fixe). Ceci dans le but de mettre en oeuvre, de manière itérative et incrémentale, un projet complexe (informatique ou pas) dans des les meilleurs délais avec la meilleure satisfaction du client puisque la priorité est donnée à ce qui a le plus de valeur pour lui. Dans la suite, je décrirais les différents éléments qui le compose principalement pour des projets informatiques.

A qui s'adresse SCRUM ?

SCRUM est composé de plusieurs principes dont je ferais la liste plus tard dans ce billet. L'un de ces principes est qu'une équipe SCRUM doit s'auto-organiser pour gérer un projet. J'en ai conclu qu'il faut que les personnes qui participent à une équipe SCRUM doivent avoir une certaine expérience en développement. Je dirais au moins 2/3 ans. Dans le cas contraire, une auto-organisation prendrait beaucoup trop de temps ainsi que la prise de décision. Une équipe SCRUM a une taille idéale de 7 personnes +- 2. Je dirais qu'à partir de 5 personnes pour des projets de taille raisonnable, on peut inclure un seul développeur junior. Celui-ci commencerait le projet par du peer-programming (programmation à 2) dans le but de monter en compétences et connaître les bonnes pratiques rapidement.

Quels sont les acteurs d'un projet SCRUM et leurs rôles?

Les acteurs principaux d'un projet réalisé en SCRUM sont le client et l'équipe SCRUM. Le client ou son représentant est appelé Product Owner (PO). Il a la charge de la mise en oeuvre des besoins du client et de leur priorisation. L'équipe SCRUM est elle composée d'un capitaine de navire qu'est le Scrum Master (SM) et des autres membres de l'équipe, les développeurs, les acteurs principaux. Comme au Rugby dont Scrum tire son nom (mêlée en français), la réussite d'un projet SCRUM est liée, essentiellement, à la performance de l'équipe. C'est l'une des raisons qui me poussent à dire qu'elle doit avoir, de manière globale, une certaine expérience en développements. Le SM a la résponsabilité de l'avancement du projet, de sa qualité et est un pare-feu entre l'équipe et son environnement (principalement le client). Il doit faire en sorte que l'équipe ne soit pas parasitée par autre chose que la réalisation des tâches qui lui incombe. C'est un facilitateur et un animateur. Enfin, l'équipe est responsable des estimations de charges, de la réalisation du projet et de sa propre amélioration dans son efficacité et la qualité de ses développements.

Quelles sont les valeurs de SCRUM?

SCRUM est basé sur une ligne directrice qu'il faut toujours concervée à l'esprit. C'est le Manifeste Agile qui est composé des quatre valeurs suivantes:

  • privilégier les Individus et leurs interactions,
  • privilégier la collaboration avec le client,
  • privilégier la disponibilité immédiate des logiciels,
  • privilégier la réactivité face aux changements.

En résumé, SCRUM ce sont des individus qui travaillent ensemble pour rendre un service, rapidement disponible et très changeant, au client.

Quels sont les principes de SCRUM?

Des valeurs de SCRUM découlent 12 principes qui font les fondements de ce framework:

  1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  2. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  4. Les experts métier et les développeurs doivent collaborer quotidiennement au projet.
  5. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  6. La méthode la plus efficace pour transmettre l'information est une conversation en face à face.
  7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  8. Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  9. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
  10. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
  11. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.
  12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

De ma compréhension de SCRUM, l'agilité consiste à l'habilité de mettre en oeuvre tel ou tel principe en fonction du contexte du projets, des individus qui le composent, de l'environnement du client, du degré de maturité de l'agilité dans l'entreprise, ... Il faudroit voir cela comme un programme, basée sur une librairie, et qui fait appel à l'une ou l'autre de ses méthodes en fonction du besoin.

Que sont les artefacts dans SCRUM?

Les artefacts sont des éléments en entrée et en sortie d'un projet SCRUM. En entrée de la réalisation d'un projet SCRUM par une équipe, on aura ainsi les éléments suivants:

  • Le ProductBacklog (Panier de Produit): liste priorisée des fonctionnalités à réaliser. Celles-ci sont, généralement, appelées User Stories.
  • Le SprintBacklog (Panier de Sprint): User Stories à réaliser dans un Sprint découpées en tâches élémentaires.

En sortie, pour avoir une vue simple du reste à faire et du réalisé, on a :

  • Les BurnDown Charts: Représentation graphique très simple de l'état d'avancement du projet basé sur le Reste à faire.

Ci-dessous, un exemple de ce que peut être un Product Backlog: Exemple de Product Backlog

Qu'est ce qu'une User Story?

Une User Story (US) est une fonctionnalité qui, comme son nom l'indique, raconte une histoire. Celle-ci est sensée pouvoir être spécialisée à l'infini. Elle est décrite de la manière suivante: En tant qu'<acteur>, je peux <réaliser une fonctionnalité>.

Que sont les time-boxes?

Les time-boxes sont des événements à durée fixe qui ponctuent le déroulement d'un projet SCRUM. On en décompte 6:

  1. La Réunion de Planification de version (Release Planning),
  2. La Réunion de Planification du Sprint (Sprint Planning),
  3. La Réunion Quotidienne (Scrum Daily Meeting), aussi connue sous le nom de Stand-up meeting (car elle se fait debout généralement),
  4. Le Sprint,
  5. La Revue de Sprint (Sprint Review),
  6. La Rétrospective.
Lire la suite