Avez vous déjà essayé de maîtriser votre empreinte numérique sur internet ? gérer votre e-reputation ?

Chaque seconde, se publient sur internet des centaines de nouveaux messages sur tous les sujets (twitter, facebook, blogs, etc). Des amis, des collègues, et même des inconnus peuvent vous référencer ou vous citer sans que vous ne soyez jamais au courant.

Heyitsi vous propose d’être tenu au courant de ce que les différents moteurs de recherches trouvent sur vous sur internet.

inscrivez vous vite,  il y a actuellement 200 comptes ouverts gratuits ! le site est toujours en développement, soyez indulgent

rendez vous sur: http://www.heyitsi.com

Suite à la création de votre compte heyitsi, un mail de confirmation vous sera envoyé par mail. il est possible que cet mail arrive dans le répertoire des spam(courrier indésirable) de votre boite mail.

dans un premier temps: menu netbean/profile/advanced/calibrate

ensuite attach mode / change / application / local / direct / next next > recopier la chaine et ajouter au script de lancement

profile/attach profiler, edit filter (supprimer les filtres) > cliquer attach

ensuite on doit avoir accès au call tree dans netbean

RETOURS D’EXPERIENCES

Société (e)pistema,

bertrand.gorge@epistema.com

A lire: scrum and XP from the trunches

Ce qui est le plus important dans scrum:

• le daily scrum (le matin: on sais ce que l’équipe fait aujourdh’ui)
• la demo (permet de conclure un dev, on sait ou on en est, responsabiliser et valorisation du développer)
• le howto demo (sert de spec)
• le sprint planning meeting: réunion en début de sprint pour valider le contenu du sprint. completion du howtodemo
• la DOD (definition of done) etapes du processus de développement : valider, complete, vraiment complete

Les erreurs:

• mélanger la maintenance et e développement
• de ne pas faire de taches (mais uniquement des stories), c’st le découpage en tache qui permet de lever les loups.
• de splitter une équipe travaillant sur le même projet dans le cas de gros projets (13 developper c’est beaucoup)
• de démarer une story sans howtodemo(ni spec) > mécontantement client
• de ne pas faire de demo, de ne pas faire de daily scrum.

les points positifs:

• productivité
• satisfaction client
• croissance rapide de l’équipe
• meilleur prédictibilité des efforts (calcul de la velocité)
• moins de spec

SOCIETE SAP

paul.el.khoury@sap.com

environnement:

• 1 scrum master
• 2 product owner
• 11 team member
• entre la france et l’allemagne

daily metting par videoconference

step1:

• 11 personnes, 30 min daily scrum > trop long trop de monde
• > le projet a été dévisé en 2 equipes

step2:

• 2 equipes de 5 et 6 dev, 15min daily meeting

Ce qu’ils ont appris, les bonnes pratiques:

1. day to day focus
2. scope réaliste pour le sprint backlog
3. identifier avec le client si le sprint est dédié à du bugfix ou a des évolutions
4. la videoconf marche bien

Les reproches sur la méthode

1. chaque story a tendance a devenir un projet en sois

L’objectif était d’avoir une présentation générale du produit.

La présentation très intéressante nous a exposé comment JBPM permet au monde marketing de discuter avec les développeur en mettant en place un graphique (diagramme d’état) éditable en ligne que le développeur importe dans son environnement de développement. Le principe est effectivement très séduisant.

Nous ne sommes cependant pas trop entrés dans les détails de l’implémentation de ces états. A chacun de se faire son idée en installant le produit. La démonstration enregistrée nous montre comment rapidement mettre en place un business process et comment cela fonctionne a travers les pages générées par le framework.

Les état des process sont persisté en BDD (de nombreux conecteurs sont disponibles).

Les règles ne sont pas déployables à chaud et il faut faire très attention lors de la modification d’un Business Process (en l’occurrence, la suppression d’un état peut s’avérer impossible)

La seule représentation disponible actuellement est le diagramme d’état (pas de tables de décisions).

JBPM peut s’intégrer facilement a un projet java en standalone.

Ayant un peu travaillé avec JRules, il semble que JBPM soit un peu moins complet, mais cependant semble bien plus simple à mettre en place et rapidement en plus (d’après le second interlocuteur ayant mis en place le produit dans son entreprise)

ref. jBPM 4.1 (démos vidéo)

L’outil a l’inconvénient de son avantage, c’est un outil complet qui rends les choses simples difficiles pour un novice.

Voici donc comment simplement sniffer les request/response HTTP:

• Premiere chose à faire: configurer le “Capture filter” dans les options

• Aller dans “Edit/preference/Protocols/HTTP” et ajouter les ports que vous voulez sniffer dans “TCP Ports”
• Lancer la capture (Start)
• Configurer le “Display Filter” = http.response==True or http.request==True
• Et voilà le résultat:
  

Ce framework utilise log4j pour tracer les requettes, donc ecrire au choix:
- dans un fichier texte
- une base de donnée
- ou une Socket qui va nou permettre avec Sql Profiler qui va nous permettre d’exploiter les requettes sous forme de graph.

Un outils vraiment pratique à découvrir sur le site.

Depuis, je suis tombé sur CAP. qui s’intègre aussi à eclipse et qui parrait beaucoup plus complet. à voir…

j’ai cependant noté quelques points négatifs:
- la demo fonctionne beaucoup mieux sous IE que sous Firefox (pb d’alignements, affichage plus lent)
- le compte utilisateur (screen, conf des portlets) est stockée sur le serveur > chaque modif = requette en BDD. il est possible que cela pose des problèmes lors de montée en charge.
- lifeRay n’est pas simple à mettre en place.
- De nombreuses questions qui restent en attente sur le forum
- j’ai fait planter la demo en ligne en modifiant mes user’s properties.

Un outil très intéressant mais qui manque un peu de maturité.

pour faire cela il suffit d’ajouter des mot clefs dans vos sources.

par exemple:

ainsi, au moment du commit, CVS va se charger de compléter les informations dans le fichier:

plus de détails ici