Blog Xebia France

Steve Blank, créateur du Customer Development, revient dans cet article sur Lean Startup et son importance dans n’importe quelle entreprise (et pas uniquement les startups). Si les grandes entreprises sont très concentrées sur l’exécution, elles ne doivent pas oublier l’innovation dans un marché qui change rapidement avec des innovations disruptives de plus en plus fréquentes. Lean Startup est l’outil approprié pour leur permettre d’innover et de s’adapter rapidement. Steve Blank revient aussi sur l’importance des données ainsi que la nécessité de comprendre ce que les clients veulent.

Product Ownership dans le brouillard

Par Gilles Mantel

Le French SUG a mis en ligne sur sa chaîne YouTube un certains nombre de videos du dernier Scrum Day qui s’est déroulé au centre de conférence d’IBM le 11 Avril. Vous retrouverez les keynotes d’ouverture et de fermeture et les sessions des 2 amphithéâtres. Nous avions fait un retour des sessions dans cet article de blog, c’est maintenant l’occasion d’en découvrir certaines par vous même et de nous donner votre avis si vous n’avez pu assister à l’événement. Vous retrouverez notamment la video de notre retour d’expérience orientée Product Owner. Nous parlons des techniques classiques que le Product Owner doit maîtriser dans un contexte SCRUM, mais également de pratiques plus avancées qui permettent de continuer d’avancer dans un contexte très incertain (le brouillard). Ces pratiques sont à la frontière du Product Owner à la SCRUM et la gestion de produit à l’anglo-saxonne. Le produit dont nous parlons est aujourd’hui déployé en production.

Mobilité

Un meilleur visualiseur de logs pour Android

Par Gautier Mechling

Jake Wharton a sorti cette semaine PID Cat, une surcouche à l’utilitaire "adb logcat" permettant de consulter les journaux (logs) d’un appareil Android.
Ce nouveau script en ligne de commande ajoute de la couleur à la sortie de logcat pour la rendre plus lisible, et offre la possibilité de filtrer les logs par application en saisissant leur "package name" (comme ce que propose déjà Eclipse via le plugin ADT) plutôt que leur PID.

Web

AngularJS va être porté sur Dart

L’équipe Angular, durant la présentation de sa roadmap pour la version 1.2, a annoncé le portage du Framework MVC sous Dart.

D’un point de vue technique cela peut être très intéressant pour le framework. Il disposera d’un typage plus fort, et pourra donc avoir une injection de dépendance plus robuste que celle actuelle. De plus le projet Web UI sous Dart permettra à Angular de faire son entrée dans l’ère du Web Component. Actuellement, les composants de base comme le $compiler ou le $scope ainsi que les directives ng-bind et ng-repeat sont déjà portés.

Cependant, avec cette nouvelle étape, Google fait un de pas de plus vers la construction d’une stack web complète dont il a le contrôle. En effet, le géant de la recherche gère désormais son propre moteur de rendu en la personne de Blink, son langage client et serveur avec Dart et son framework MVC client avec Angular, lui permettant ainsi potentiellement d’appliquer ses propres standards mais le protégeant aussi de litiges judiciaires comme il avait pu avoir avec Oracle sur Android.

Source

Github du portage

Le coin de la technique

Sortie de Java EE 7 et de Glassfish 4.0

Par Antoine Michaud

Oracle a annoncé, mercredi 12 juin 2013, la disponibilité de Java EE 7. On pourra en particulier noter la sortie de JMS 2.0, JAX-RS 2.0 et un support amélioré pour les applications comprenant du HTML 5, avec notamment la gestion des WebSockets et l’utilisation simplifiée des flux JSON.

L’implémentation de référence d’Oracle de JEE 7, Glassfish 4, est sortie quant à elle lundi 10 juin dernier.

À la (re)découverte de la UICollectionView

Simone Civetta — Mon, 17 Jun 2013 11:58:30 +0000

Vous avez peut-être déjà travaillé avec la classe UICollectionView, mais savez-vous comment personnaliser entièrement la mise en page et les transitions de vos données ? De même, avez-vous déjà eu à mettre en œuvre un UICollectionViewLayout personnalisé ?

Si la réponse est "non", alors une lecture de cette article s’impose.

Parmi les nouveaux composants UI introduits par iOS 6, un des plus appréciés est la UICollectionView. Nous verrons ici comment se servir de cet objet en réalisant une galerie photo animée.

La UICollectionView est un composant qui gère une collection ordonnée d’éléments et les présente au travers de vues complètement personnalisables.

Par exemple, il est possible de présenter des données sous forme de cellules dans une grille, un carrousel ou bien encore dans une vue rotative. La CollectionView obtient ses données d’un dataSource qui se conforme au protocole UICollectionViewDataSource. Elle les affiche via des classes de type UICollectionViewCell.

Un protocole UICollectionViewDelegate est mis à disposition par UIKit afin d’interagir avec la CollectionView. Il permet notamment d’identifier les éléments sélectionnés.

La UICollectionView, de façon similaire à la UITableView, est une sous-classe de la UIScrollView, rajoutant un dataSource, des événements (sélection, désélection, etc) et un layout. Si nous n’utilisons que de simples collectionViews au travers de Storyboards pour réaliser nos interfaces, l’usage du layout peut passer inaperçu. En réalité, il constitue un des principaux atouts de ce composant car il est conçu pour encapsuler toute la logique d’affichage des éléments.

Notre objectif est d’obtenir une galerie dans laquelle les images suivantes et précédentes seront semi-transparentes et sur lesquelles un redimensionnement sera appliqué. La taille de l’image augmentera au fur et à mesure qu’elle s’approchera du centre de l’écran. L’image suivante présente le résultat souhaité:

Création du UICollectionView

Note: Si nous devions cibler la version 5.0 d’iOS (qui ne supporte pas les UICollectionViews), nous pourrions utiliser la très bonne librairie PSTCollectionView, réalisée par Peter Steinberger, qui réplique parfaitement le comportement de l’UICollectionView.

La mise en place d’une UICollectionView n’a rien de complexe : il suffit d’instancier ce composant à travers un storyboard ou bien directement via le code. Chaque image de la galerie sera contenue dans une cellule de type XBGalleryCell (Une sous-classe de UICollectionViewCell). Par exemple :

XBGalleryLayout *layout = [[XBGalleryLayout alloc] init];
self.collectionView = [[UICollectionView alloc] initWithFrame:CGRectMake(0, 0, 320, 320) collectionViewLayout:layout];
self.collectionView.dataSource = self;
self.collectionView.delegate = self;
[self.collectionView registerClass:[XBGalleryCell class] forCellWithReuseIdentifier:@"GalleryCell"];

Le code ci-dessus crée une UICollectionView avec une taille arbitraire, un layout de type XBGalleryLayout. Un dataSource et delegate sont également définis. La méthode registerClass permet enfin d’attribuer la classe de la cellule à un reuseIdentifier spécifique, ce qui permet à UIKit d’allouer puis réutiliser un objet de classe “XBGalleryCell” pour chaque cellule ayant reuseIdentifier égal à “GalleryCell”.

Pour obtenir le nombre d’éléments de la CollectionView, nous mettons en place les méthodes suivantes :

- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section { ... }
- (NSInteger)numberOfSectionsInCollectionView:(UICollectionView *)collectionView { ... }

De même, pour obtenir la cellule associée à un élément de la source de données, nous utilisons le code suivant :

- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *cellIdentifier = @"GalleryCell";
    UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:cellIdentifier forIndexPath:indexPath];
    [cell setImageWithURL:[self.imageUrls[indexPath.row] url] placeholderImage:self.placeholderImage];
    
    return cell;
}

UICollectionViewCell

Nous continuons avec la UICollectionViewCell qui, de la même façon que la UITableViewCell, présente le contenu d’un élément de la dataSource :

@implementation XBGalleryCell

- (id)initWithFrame:(CGRect)frame
{
    if (self = [super initWithFrame:frame]) {
        self.imageView = [[UIImageView alloc] initWithFrame:self.bounds];
        self.imageView.contentMode = UIViewContentModeScaleAspectFit;
        [self addSubview:self.imageView];
    }
    return self;
}

- (void)setImageWithURL:(NSURL *)url placeholderImage:(UIImage *)placeholderImage
{
    [self.imageView setImageWithURL:url placeholderImage:placeholderImage];
}

@end

UICollectionViewLayout

Le principal atout de la UICollectionView est le UICollectionViewLayout. Cette classe permet de configurer l’aspect et les animations des items contenues dans notre UICollectionView. UICollectionViewLayout est une classe abstraite qui doit nécessairement être sous-classée et qui contient toutes les informations sur la mise en page d’une UICollectionView.

Grâce au UICollectionViewLayout, nous pouvons appliquer les transitions, les effets d’opacité et de redimensionnement des images que nous avons décrits en début d’article.

Ci-dessous l’implémentation utilisée pour XBGalleryLayout (le code complet est disponible sur gist à cette URL https://gist.github.com/viteinfinite/5735887) :

 @implementation XBGalleryLayout
- (id)init
{
    self = [super init];
    
    if (self) {
        
        // Taille des cellules
        self.itemSize = CGSizeMake(imageWitdh, imageHeight);
        
        // Configuration de l'aspect
        self.minimumLineSpacing = -10; // Espace minimum entre les cellules
        self.sectionInset = UIEdgeInsetsMake(0, imageLeftMargin, 0, imageLeftMargin); // "Padding"
        
        // Direction de défilement
        self.scrollDirection = UICollectionViewScrollDirectionHorizontal;
    }
    return self;
}
...
@end

Modifier l’aspect et l’animation des cellules

Grâce à la méthode layoutAttributesForElementsInRect il est possible de modifier l’aspect (layout attribute) des éléments affichés à l’intérieur d’une région de l’écran, et notamment de modifier l’opacité et la taille selon la position d’une cellule à l’écran.

Un objet de type UICollectionViewLayoutAttributes permet de configurer les propriétés suivantes :

frame
center
size
transform3D
alpha
zIndex
hidden

L’implémentation de cette méthode dans notre XBGalleryLayout est la suivante :

- (NSArray*)layoutAttributesForElementsInRect:(CGRect)rect
{
    NSArray *layoutAttributes = [super layoutAttributesForElementsInRect:rect];
    
    CGFloat horizontalCenter = (CGRectGetWidth(self.collectionView.bounds) / 2.0f);
    
    [layoutAttributes enumerateObjectsUsingBlock:^(UICollectionViewLayoutAttributes *layoutAttributes, NSUInteger idx, BOOL *stop) {
        
        CGPoint centerInCollectionView = layoutAttributes.center;
        CGPoint centerInMainView = [self.collectionView.superview convertPoint:centerInCollectionView
                                                                      fromView:self.collectionView];
        
        if (centerInMainView.x > -80 && centerInMainView.x < self.collectionView.frame.size.width + 80){
            
            CGFloat translateYBy = [self translateYByOffset:centerInMainView.x fromCenter:horizontalCenter];
            CGFloat scaleBy = [self scaleByOffset:centerInMainView.x fromCenter:horizontalCenter];
            CGFloat alpha = [self alphaByOffset:centerInMainView.x fromCenter:horizontalCenter];
            
            CATransform3D transform = CATransform3DIdentity;
            transform = CATransform3DScale(transform, scaleBy, scaleBy, 1.0);
            transform = CATransform3DTranslate(transform, 0.0, translateYBy, 0.0);
            layoutAttributes.transform3D = transform;
            layoutAttributes.alpha = alpha;
        }
    }];
    
    return layoutAttributes;
}

Un UICollectionViewLayout permet également de contrôler lorsque la collectionView doit arrêter le défilement inertiel. Ce contrôle est rendu possible grâce à la méthode targetContentOffsetForProposedContentOffset:withScrollingVelocity: qui nous donne la possibilité de modifier le content offset (c’est à dire le décalage du contenu) à partir du contentOffset initialement prévu et de la vélocité de défilement. En d’autres termes, il est possible de forcer la collectionView à réduire l’inertie afin de positionner l’image courante au centre de l’écran :

- (CGPoint)targetContentOffsetForProposedContentOffset:(CGPoint)proposedContentOffset
                                 withScrollingVelocity:(CGPoint)velocity
{
    
    CGFloat offsetAdjustment = MAXFLOAT;
    CGFloat horizontalOffset = proposedContentOffset.x + imageLeftMargin;
    
    CGRect targetRect = CGRectMake(proposedContentOffset.x, 0, self.collectionView.bounds.size.width, self.collectionView.bounds.size.height);
    
    NSArray *array = [super layoutAttributesForElementsInRect:targetRect];
    
    for (UICollectionViewLayoutAttributes *layoutAttributes in array) {
        CGFloat itemOffset = layoutAttributes.frame.origin.x;
        if (fabsf(itemOffset - horizontalOffset) < fabsf(offsetAdjustment)) {
            offsetAdjustment = itemOffset - horizontalOffset;
        }
    }
    return CGPointMake(proposedContentOffset.x + offsetAdjustment, proposedContentOffset.y);
}

Conclusion

La UICollectionView est un élément extrêmement flexible qui permet de s’affranchir de nombreuses complexités, et qui permet notamment une personnalisation en profondeur de la présentation d’une collection d’éléments.

Ce qui rend le composant UICollectionView particulièrement intéressant est la façon dont il est architecturé. Grâce au UICollectionViewLayout, les responsabilités sont partagées efficacement entre les classes. Cela permet une séparation plus propre entre la logique du contrôleur et celle de la vue et donc une meilleure maintenabilité du code.

Atelier ElasticSearch

Eric Briand — Fri, 14 Jun 2013 12:52:00 +0000

Que vous soyez ingénieurs Java, DEV ou OPS, venez découvrir l’outil ElasticSearch avec David Pilato et Xebia.

Le fil conducteur de l’atelier est la découverte des fonctions de bases et plus avancées dans un scénario réel d’entreprise.

Après une présentation des fonctionnalités de l’outil par David Pilato (ElasticSearch), vous vous familiariserez avec ElasticSearch notamment à travers des requêtes de base ainsi que l’administration de l’outil. Vous serez alors prêt pour la mise en œuvre d’un scénario plus orienté entreprise avec l’indexation de données d’une base de données MongoDB et le requêtage plus avancé de ces données.

Cet atelier aura lieu le mardi 2 juillet dans les locaux de Xebia. Vous pouvez dès maintenant vous inscrire sur Eventbrite.

Help, my velocity is like a roller coaster

Ludovic Pérot — Fri, 14 Jun 2013 12:00:55 +0000

Un ami m’a dit un jour que le Scrum Master était, au-delà du gardien de la méthode, le garant de la vélocité de l’équipe. Depuis, je me suis approprié cette formule que je trouve excellente. Pour garantir la vélocité, il faut la connaître et qu’elle soit fiable. Bien souvent, pour des équipes Scrum débutantes, il est possible d’être confronté à une vélocité qui fait le yoyo d’un sprint à l’autre. Ou encore, récemment, je me suis trouvé dans cette situation : le Scrum Master et le Product Owner d’une équipe pensaient qu’ils ne connaissaient pas la vélocité de leur équipe. Etonnant non ? Et pourtant, dans quelques cas la vélocité a du mal à émerger. Je vous propose quelques bons réflexes à avoir pour stabiliser la vélocité de votre équipe et l’accompagner sur le chemin du rythme soutenable.

Cas d’exception : la vélocité du Sprint 1

1 produit (ou projet), 1 équipe, 1 vélocité. Cette porte ouverte enfoncée dans les règles de l’art, comment faire pour déterminer la vélocité du premier sprint ? Le cas idéal est d’obtenir l’engagement de l’équipe. Il consiste à demander sur quel ensemble de User Stories l’équipe s’engage à l’issue du sprint, un peu comme un pari. C’est souvent difficile, surtout avec une équipe en construction ou composée de juniors. Dans ce cas de figure, il arrive assez souvent que l’équipe retourne la question au Scrum Master : Mais quelle est notre capacité ?

Luttez contre la tentation d’une espèce de règle de trois "Poids du sprint / coût en Jours Homme / cours du point de complexité". Si vous vous posez la question du "Pourquoi", direction ce billet.

Au delà de l’engagement de l’équipe, vous pouvez proposer à l’équipe un périmètre à fournir en ‘best effort’. Là, cela peut être le client ou le sponsor qui sera difficile à convaincre. Il peut en effet considérer l’approche comme trop permissive ou pas assez engageante. A vous de faire au mieux avec les moyens du bord…

Une autre approche se pratique également : l’équipe a un backlog produit priorisé, et les stories en haut de la pile satisfont la Definition of Ready. il suffit dès lors de piocher les stories une par une, tant que l’équipe est capable de les terminer. Ainsi, à la fin de ce premier sprint la vélocité émerge naturellement : c’est la somme des complexités des US livrées.

La vélocité des autres sprints

Comment aidons-nous nos amis Scrum Master et Product Owner dont je vous parlais un peu plus haut ? En fait, c’est assez facile. Une vélocité, ils en avaient une, ils ne la voyaient simplement pas. Quelques sprints s’étaient déroulés (4 de mémoire), et effectivement, les vélocités constatées avaient l’évolution d’un chariot de montagnes russes. Voici mes quelques conseils pour faire émerger simplement la vélocité d’une équipe.

1. Surtout, ne touchez pas aux estimations

Selon le Scrum Master, le coupable était tout trouvé : "Les estimations ne sont pas fiables". STOP, alerte bouc émissaire. Les estimations ont bon dos, ce ne sont que des estimations. Les accabler cache souvent (toujours ?) un problème bien plus profond. Vous avez un backlog priorisé et estimé ? Surtout, ne touchez à rien. Dans le cas qui nous intéresse, si nous avions touché aux estimations, cela signifiait que nous éliminions l’historique de vélocité. Et donc, que nous nous éloignions encore un peu plus du but à atteindre.

2. Faites une moyenne des vélocités constatées

Du très classique. Là, nous avions les vélocités A, B, C, D : il suffit d’en faire la moyenne E pour poser la vélocité du Sprint 5. OK, c’est un peu dirigiste, mais parfois l’auto-organisation montre ses limites. Ensuite, une fois la situation rétablie, il sera toujours temps de ne se fier qu’à la moyenne des 3 dernières, ou autre, suivant votre préférence.

3. Posez clairement la Définition de Fini

La définition de "fini" (Definition of Done pour les anglophiles) n’est parfois pas clairement établie. Le dommage collatéral est limpide : non définie ou mal définie, comment savons-nous qu’une US est effectivement terminée ? Si vous ne l’avez pas déjà fait, prenez 20 minutes avec l’équipe pour dresser la (ou une première …) liste des quelques critères de votre DoD. Vous en sentirez rapidement le retour sur investissement.

4. Vérifiez que vos stories ne sont pas trop grosses

Là encore, retour aux fondamentaux : vos stories sont-elles INVEST ? Et en particulier, sont-elles ‘S’ (Small) ? Manipuler des grosses stories est porteur d’un risque assez évident. Vous vous exposez au risque plus fort de ne pas les finir pendant le sprint. Et en conséquence, une grosse story, à la complexité importante, pèse sur la vélocité. Si vous ne la finissez pas, c’est autant de points de complexité qui ne sont pas pris en compte dans la vélocité, mais surtout c’est une US qui apporte de la valeur métier qui n’est pas livrée !

5. En fin de sprint, limitez l’en-cours

C’est un bon réflexe à aller piocher chez Kanban. La limite de l’en-cours est un pilier des méthodes agiles. Scrum limite l’en-cours par la timebox qu’est le sprint. Du côté du Kanban, nous limitons l’en-cours à chaque étape du processus de fabrication du logiciel. Si en fin de sprint vous avez beaucoup de Stories en-cours, il ne faut pas hésiter à faire des choix forts : protéger la terminaison des stories de plus grande valeur, même au détriment d’autres. C’est à ce prix que la vélocité est la mieux préservée.

Voilà un petit lot de bonnes pratiques et réflexes pour faire émerger ou améliorer votre vélocité. Cette liste n’est pas absolue et définitive, il ne tient qu’à vous de la compléter / la critiquer !

DroidCon Paris les 17 & 18 juin 2013

Xebia France — Fri, 14 Jun 2013 07:44:00 +0000

DroidCon, la conférence exclusivement réservée à Android, prendra place cette année à Paris les 17 et 18 juin 2013.

Après une Google I/O 2013 marquée par de nombreuses nouveautés, la DroidCon devrait nourrir la communauté Android de discussions et de présentations passionnantes.

Au programme : performance, qualité et industrialisation des développements, marketing et monétisation de ses applications ou encore usages divers et variés d’Android. Par ailleurs, le lundi après-midi sera entièrement réservé à un Barcamp géant, ce qui devrait permettre l’émergence de sujets encore plus nombreux !

Nous y serons pour vous dire si 2013 est bien l’année de la révolution pour Android…

Workshop Continuous Delivery le 9 juillet

Xebia France — Thu, 13 Jun 2013 08:21:00 +0000

Le déploiement automatique des applications est l’un des piliers essentiels du "Continuous Delivery".

Deployit est une solution transverse qui offre à l’ensemble des acteurs (Dev & Ops) une solution unifiée pour déployer et configurer leurs applications sur l’ensemble de leurs environnements.

Dans ce workshop de 3 heures, nous verrons comment coupler Deployit à un moteur d’intégration continue (Jenkins) afin d’inclure l’activité "déploiement et configuration" des applications dans différents environnements.

Agenda

Présentation de l’environnement de Workshop,
Définition d’un job de build,
Définition d’un job de packaging,
Définition d’un job de déploiement,
Configuration d’un pipeline,
Gestion de la configuration,
Promotion d’une application dans un autre environnement.

Pré-requis

Chaque participant devra :

se munir d’un ordinateur et avoir installé au préalable: VirtualBox et un client SSH (ex putty),
avoir une connaissance de Maven et Jenkins.

Ce workshop est gratuit, inscription sur eventbrite obligatoire.

Lieu

156 boulevard Haussmann
75008 Paris
Batiment A, 7ième étage

Kanban – Faire des promesses que vous pouvez tenir

Yannick Quenec'hdu — Wed, 12 Jun 2013 06:39:14 +0000

Être toujours plus rapide, innover et mettre rapidement votre produit sur le marché, avoir un retour à court terme sur son investissement – C’est le leitmotiv des startups et des entreprises du Web. C’est ici que le Lean Startup et le déploiement continu sont efficaces. C’est aussi la raison de l’adaptation rapide et majeure des pratiques agiles. Nous pouvons concevoir au plus vite et de manière itérative en prenant en compte au fil de l’eau de la création du produit le retour des clients.

Mais est-ce que cela est reproductible chez toutes les entreprises ? Est-ce que la vitesse de mise sur le marché (que l’on nomme aussi le TTM) est le facteur le plus important pour les entreprises ? Il faut aussi maintenir cette vitesse dans le temps, maintenir les coûts et fournir un produit de qualité, mais il y a aussi d’autres facteurs tels que la sécurité, la maintenabilité. Il faut les intégrer à des systèmes existants de l’entreprise et parfois conserver la compatibilité avec les anciennes versions qui sont chez vos clients, etc.

En 2011, je mettais pour la première fois en oeuvre des indicateurs de prédictibilité avec mon acolyte Etienne. Au-delà du premier engouement pour ses indicateurs, j’ai remarqué une nouvelle manière de faire de l’Agile. Nous fournissions des indicateurs précis et en temps réel aux équipes. Nous pouvions dépasser cette limite réductrice de l’indicateur vélocité. La collecte d’information obtenue nous permettait de mieux comprendre ce qu’il se passait dans le projet et la direction que nous allions prendre. Nous pouvions mesurer notre futur et l’améliorer avec ces indicateurs factuels.

Depuis, nous avons mis en place les indicateurs Kanban et les indicateurs de prédictibilité sur moult projets. Pour une grande entreprise, le plus important n’était pas la vitesse ou la productivité – même si tout le monde souhaite réduire les coûts et éliminer les gaspillages. Ce n’est pas non plus la flexibilité en essayant de prendre en compte les changements au fil de l’eau du projet. Ce qui importe le plus pour une entreprise, c’est de respecter les exigences de leurs clients et/ou sponsors de leurs produits. De fournir le logiciel lorsque l’entreprise en a besoin, d’être un fournisseur fiable et de confiance. En un mot, tenir ses promesses.

Agilité et Prédictibilité

Beaucoup de grandes entreprises adoptent les méthodes agiles parce qu’elles ont entendu et vu que ces approches fonctionnent. Mais ils ne les utilisent pas de la même manière, parce qu’ils ne les utilisent pas pour les mêmes raisons que les petites entreprises.

Les grandes entreprises adaptent les pratiques agiles et fabriquent des hybrides, un peu de cascade en combinant des estimations agiles et de la planification classique, et injectent cela dans les pratiques de l’entreprise. Nous le vivons chaque jour quand une grande entreprise vous demande de venir les accompagner dans leur transition Agile.

Pourquoi ces hybrides de pratiques ? Parce que les méthodes classiques proposent des indicateurs de pseudo-prévisibilité qui, même si nous savons qu’ils sont erronés, ont le mérite d’exister pour l’entreprise et de rassurer.

Comment combiner les besoins de ces grandes entreprises, qui fonctionnent pour la plupart sur des approches classiques, avec l’apport des pratiques agiles ?

L’essentiel est de comprendre ce dont l’entreprise a besoin. Il ne s’agit pas de réaliser des changements au fil de l’eau en suivant un plan. Il s’agit d’avoir un plan qui inclut la capacité à réagir aux changements.

Il ne faut pas abandonner nos principes de répondre aux changements et redéfinir les priorités. Mais ce n’est pas notre premier objectif. Il faut répondre à leurs premiers besoins, en proposant des indicateurs qui permettent de donner une vision réaliste de la vie d’un projet en temps réel.

Nous faisons cela en gardant l’équipe concentrée sur la fabrication du produit et en essayant de chasser tout le reste. Les pratiques Kanban et leurs indicateurs permettent de répondre aux besoins des entreprises en proposant une palette d’indicateurs, dont la prédictibilité peut répondre à leur premier besoin.

Les équipes peuvent utiliser les indicateurs Kanban pour gérer les priorités et contrôler le flux d’activité de façon dynamique, équilibrer l’activité entre la création de valeur et la réduction de dette technique, mieux respecter leurs engagements à date fixe, limiter le travail en cours pour réduire les délais et améliorer le temps de réalisation, contrôler la variabilité de leurs User Stories. Vous pouvez également utiliser les données du débit et le diagramme de flux cumulé, afin de vous projeter vers l’avant et prévoir ce qui va se passer.

Ce qui est intéressant, c’est de voir comment les mêmes idées et pratiques sont utilisées de manières très différentes par des entreprises très différentes – petites ou grandes – pour atteindre ce succès, qu’elles soit axées sur des itérations courtes et de réponses aux changements rapides ou axées sur la gestion de grands programmes avec des indicateurs de prédictibilité.

27 Juin 2013 : Big Data Day chez Xebia

Xebia France — Tue, 11 Jun 2013 12:35:00 +0000

Inscriptions

Merci de vous inscrire à chaque partie de la journée à laquelle vous souhaitez participer :

9h30-12h00 : Les essentiels du Big Data. Inscriptions sur invitation uniquement.
13h00-18h20 : Le Big Data en pratique. Inscriptions ici.
18h30-21h : Soirée de clôture. Inscriptions ici.

Agenda

Salles	Map	Reduce
09:00 – 09:30	Petit déjeuner
09:30 – 10:30	L’avenir du Big Data pour votre entreprise vu par Amazon Boris Lecoeur (Amazon)
10:30 – 11:00	Petit déjeuner
11:00 – 12:00	Les coulisses du Big Data chez Bouygues Télécom Guillaume Pinot (Bouygues Télécom)
12:00 – 13:00	Déjeuner
13:00 – 14:00	Ask bigger questions with Cloudera and Apache Hadoop Graham Gear (Cloudera)	Analytics and Aggregation on MongoDB Norberto Leite (10gen)
14:05 – 15:05	Atelier Hadoop : Explorer le comportement de vos utilisateurs Bertrand Dechoux (Xebia)	Géolocalisation avec MongoDB Charles Blonde (Xebia)
15:10 – 16:10	Neo4j: Graphs are everywhere Cédric Fauvet (NeoTechnology)	The Matrix and DataStax Hayato Shimizu (DataStax)
16:15 – 17:15	Atelier Neo4j : The power of the graph Mathieu Breton (Xebia)	Cassandra Nextgen avec CQL3 et Datastax driver Guillaume Balaine (Xebia) et Clément Lardeur (Xebia)
17:20 – 18:20	ntroduction au NoSQL avec Couchbase Tugdual Grall (Couchbase)	Atelier Amazon : Analyses haute performance à coûts optimisés Stephan Hadinger (Amazon)
18:30 – 21:00	Buffet de clôture

Légende

Conférence Big Data

Conférence NoSQL

Pause

9h-12h: Les essentiels du Big Data

L’avenir du Big Data pour votre entreprise vu par Amazon

Depuis les réseaux sociaux à vos sites web, le volume des données capturées ne cesse d’augmenter. Amazon Web Services propose des services stockage, de base de données et de traitement Hadoop qui vous permettent de transformer ces données en informations pertinentes pour votre entreprise. Découvrez comment les clients d’Amazon Web Services innovent en utilisant les services élastiques de Big Data sur AWS.

Intervenant : Boris Lecoeur

Les coulisses du Big Data chez Bouygues Télécom

Guillaume Pinot, responsable étude et architecture self care web chez Bouygues Télécom viendra vous présenter son retour d’expérience sur la mise en place d’une solution Big Data. Il sera accompagné de Julien Buret, consultant chez Xebia en mission chez Bouygues Télécom depuis un an et demi.

Intervenants : Guillaume Pinot, Julien Buret

13h-18h20 : Le Big Data en pratique

Ask bigger questions with Cloudera and Apache Hadoop

Big Data is often defined as a set of problems burdening a business : In this session, see how Cloudera, with the help of Hadoop and related technologies, is able to address the opportunity the growing data volumes offers a business. The session will include an overview of the challenges Big Data poses to existing data management infrastructure and discuss how the Hadoop ecosystem solves these problems, including a technical breakdown of the major components of a Big Data architecture. Concluding the discussion will be some Cloudera case studies showing how and why Cloudera technology is being applied today.

Intervenant : Graham Gear

Atelier Hadoop : Explorer le comportement de vos utilisateurs

Les logs sont des mines d’or, trop rarement exploitées à leur juste potentiel. Analyser votre visibilité sur le net, connaître l’impact de vos campagnes marketing, découvrir les habitudes de vos utilisateurs ou encore l’influence de la latence de votre service sur leur comportement, tout cela n’est que le début. Ensemble nous allons voir comment Hadoop vous donne les moyens pour répondre à ces questions.

Intervenant : Bertrand Dechoux

Data Processing with MongoDB

Talk will cover using MongoDB aggregation framework, map reduce engine and integration with Hadoop.

Intervenant : Norberto Leite

Atelier MongoDB

Geolocalisation avec MongoDB : MongoDb propose un ensemble de fonctions permettant de facilement exploiter les données géographiques. Dans cet atelier, nous mettrons en pratique grâce à OpenStreetMap les différentes possibilités offertes par MongoDB.

Intervenant : Charles Blonde

Neo 4j: Graphs are everywhere

From websites adding social capabilities to Telco’s providing personalized customer services to innovative bioinformatics research, organizations are adopting graph databases as the best way to model and query connected data. Neo Technology researchers have pioneered graph databases since 2000 and have been instrumental in bringing the power of the graph to numerous organizations worldwide, including 25 Global 2000 customers, such as Cisco, HP, Accenture, Deutsche Telekom, and Telenor. Come learn about common use cases of Neo4j and hear how Neo4j is helping drive value for customers.

Intervenant : Cédric Fauvet

Atelier Neo4j: The power of the graph

Vous pensez que le graphe c’est seulement pour les réseaux sociaux ? Je vais vous montrer que non !

Au travers d’un cas autour d’un site de e-commerce, nous allons étudier comment une base NoSQL orientée graphe telle que Neo4j va vous permettre d’exploiter au mieux les informations clients pour améliorer l’expérience utilisateur et potentiellement augmenter vos ventes.

Intervenant : Mathieu Breton

The Matrix and DataStax

Intervenant : Hayato Shimizu

Cassandra Nextgen avec CQL3 et Datastax driver

Recently, the general availability release of the Cassandra CQL driver came out. Using it, we are going to explore its new features through simple exercices : Bound statements, Query Builder, Atomic Batches, Async I/O, Node discovery, etc.

Intervenants : Guillaume Balaine, Clément Lardeur

Introduction au NoSQL avec Couchbase

Cette présentation commencera par une courte introduction au NoSQL. Cette introduction expliquera les raisons pour lesquelles de plus en plus de projets utilisent ce type de solutions et les limitations des architectures classiques. Tugdual fera également le tour des différentes approches (Clé Valeur, Document, Colonnes, Graph) et solutions.

Une fois cette rapide introduction effectuée, vous verrez en détail la solution Couchbase Server 2.0. Couchbase est une base de donées NoSQL orientée Document développée en Open Source. Tugdual presentera en s’appuyant sur des démonstrations

le développement d’applications Java (et/ou autres selon les gouts) sur du NoSQL en expliquant les bénéfices des solutions,
se basant sur des structures de données flexibles (Document JSON),
l’utilisation de Map Reduce pour la création de requetes complexes,
la mise en place et l’administration d’un cluster, et les défis associés.

Intervenant : Tugdual Grall

Atelier Amazon : Analyses haute performance à coûts maîtrisés

En savoir plus sur les outils, techniques et technologies pour travailler de manière productive avec des données à n’importe quelle échelle. Vous découvrirez la gamme d’outils d’analyse des données disponible sur AWS et que vous pouvez utiliser pour collecter, stocker, analyser et partager vos données, pour des volumes allant du giga-octets au péta-octets (1024 tera-octets). Nous discuterons d’Amazon Elastic MapReduce, d’Hadoop, de données structurées et non structurées, et des types d’instances Amazon EC2 qui permettent des analyses hautes performances à coûts optimisés.

Intervenant : Stephan Hadinger

Intervenants

	Boris Lecoeur Boris Lecoeur a une longue carrière dans l’IT, spécialisé sur les solutions High Tech et permettant aux clients de tirer un maximum de bénéfices de la technologie. Dans son rôle de Partner Development Manager chez Amazon Web Services, Boris travaille avec les partenaires technologiques et services qui ont choisi AWS pour développer leurs offres, leurs business et leur services. Parmi les partenaires technologiques, on compte des fournisseurs indépendants de logiciels (ISV), ainsi que des fournisseurs d’outils de développement, de gestion et de sécurité et de solutions SaaS et PaaS. Parmi ces partenaires de services, on compte des intégrateurs de systèmes (IS), des cabinets de conseil, des revendeurs, des distributeurs à valeur ajoutée (VAR) et des infogéreurs .
	Guillaume Pinot Responsable étude et architecture Self Care chez Bouygues Télécom.
	Norberto Leite Senior Solution Architect at 10gen.
	Graham Gear Graham Gear is a Systems Engineer with Cloudera and advises organisations across Europe on how to bring Hadoop to bear against their Big Data challenges and opportunities. As an engineer at heart, Graham regularly gets involved in helping to resolve and refine Hadoop development and operational concerns, while also helping to identify new or streamlined branches of analytics to help benefit the business as a whole. With over 10 years of experience as a professional developer and consultant, Graham has worked on many large scale, data driven systems across many different industries. Having begun his career working at a defence research institution implementing sonar algorithms leveraging MPI on large Beowulf clusters, then spending time in the commercial world working on massively parallel web scale solutions, he feels he has found his new home with Hadoop and enjoys applying it to the Big Data uses cases faced by todays Enterprises. Graham is an Apache software committer.
	Bertrand Dechoux Tombé jeune dans les data en étudiant l’apprentissage automatique (Machine learning), Bertrand Dechoux est devenu passionné de leur problématiques associées : vitesse, volume et variété. Utilisant Hadoop depuis début 2010, il continue d’intervenir sur cet écosystème aussi bien dans sa mise en place en tant que consultant Xebia que dans sa démocratisation en tant que formateur Xebia training.
	Charles Blonde Consultant Xebia.
	Cédric Fauvet Business Development France at Neo Technology.
	Hayato Shimizu Hayato is a technical solutions architect for DataStax EMEA division. Prior to joining DataStax in May this year, Hayato architected and delivered a massively scalable hybrid cloud infrastructure for an IPTV platform by the largest independent broadcaster in the UK using Cassandra. He also had contributed to successful technical deliveries of large scale software/infrastructure projects at other organisations, including BBC, HSBC, AOL, and Citrix.
	Mathieu Breton : /[mathieu] bʀətɔ̃/ (n.m.) Consultant Xebia, membre actif de la communauté Web à Paris. Chevalier de l’ordre du mérite des Single Page Applications. Evangéliste Dart, instructeur Neo4J, docteur ès Grails et contributeur Ember.JS.
	Guillaume Balaine Guillaume is a polyglot developer passionate about the Web and the world of startups. He is an adept of best practices such as BDD and TDD that are now becoming standard in the industry. He is also a certified Cassandra Trainer and a Big Data afficionado in general. For the past 8 month, he has been working on the strategic Orange project Libon, as an API engineer. You can follow him at http://igosuki.github.io
	Clément Lardeur Clement Lardeur is a young Java/JEE and Web developper passionate about « Clean Code », TDD, Refactoring, and other best practices that make us modern developers. As a software engineer, he is particularly interested in technical challenges that offers Big Data and mainly by the Cassandra database for which he has hosted the last workshop in Xebia. At the heart of strategic IT projects, he currently works for SFR to completely overhaul their e-commerce parts. In the past, he also worked for the CNIL and the French Prime Minister to dematerialized their documents with an ECM solution. Clement is also involved in open source projects having contributed to the YouTestIt! project that aims to improve quality thanks to acceptance tests. He has recently started a blog http://clardeur.blogspot.fr/ and you can follow him on twitter @ClemLardeur.
	Stephan Hadinger Stephan Hadinger a une longue carrière dans l’IT, spécialisé dans les domaines Infrastructure, B2C et B2B afin de permettre aux entreprises de tirer un maximum de bénéfices de leurs investissements technologiques. Dans son rôle d’Architecte Solutions avec Amazon Web Services, Stephan travaille avec des entreprises françaises de toutes tailles pour les aider à migrer vers la Cloud et utiliser leur IT pour mieux servir leurs clients.
	Tugdual Grall Tugdual « Tug » Grall, est Technical Evangelist chez Couchbase, et un développer passionné. Il travaille actuellement avec les communautés de developpers en Europe pour faciliter l’adoption du NoSQL. Tugdual contribue aux SDKs Java et NodeJS de Couchbase. Avant de rejoindre Couchbase, Tug était le CTO d’eXo la société qui a créé l’outil de développement sur le cloud www.codenvy.com et la pateforme sociale eXo Platform. Auparavant Tugdual a travaillé comme product manager et développeur dans l’équipe Oracle Fusion Middleware sur la plateforme Java EE. Tug a participé a de nombreuses conférences DevoxxFR, MixIT, 33degree, FOSDEM, Google I/O, JavaOne et de nombreux meetups/groupes utilisateurs. Tugdual est co-fondateur du NantesJUG qui organise depuis 2008 des réunions mensuelles autour l’écosystème Java. Lorsqu’il a le temps, il tient un blog http://tugdualgrall.blogspot.com et une application déployée sur Google App Engine http://www.resultri.com. Vous pouvez le suivre sur Twitter.

Revue de Presse Xebia

Xebia France — Tue, 11 Jun 2013 07:43:20 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

Le Kata Toyota une alternative à la rétrospective

Par Yannick Quenec'hdu

Cet article qui date déjà d’un an a été rédigé d’une manière très ludique pour présenter le principe du Kata Toyota comme une alternative aux rétrospectives.

Interview Gojko Adzic

Dans son dernier livre, Gojko Adzic, déjà auteur de « Spécification par l’exemple » nous permet de découvrir l’Impact Mapping, « une technique de planification stratégique qui permet aux entreprises de ne pas s’égarer durant les phases de développement logiciel ou de livraison de projets, en identifiant clairement les hypothèses, en aidant les équipes à aligner leurs activités avec les objectifs métiers principaux, et en facilitant les décisions stratégiques. »

Dans Cette interview chez InfoQ Gojko Adzic revient sur le contenu de son livre, les motivations et les raisons comme le besoin de challenger les hypothèses, de tout mesurer ou encore de garder du budget pour apprendre et expérimenter.

Mobilité

Google déconstruit Android petit à petit

Par Gautier Mechling

Ces derniers temps, nous avons pu voir certaines fonctionnalités clés d’Android se séparer du système d’exploitation pour être disponibles à travers le Google Play Store, en tant que services ou applications autonomes.
Cette semaine, c’est au tour du clavier par défaut d’Android d’être disponible en téléchargement sur le store.
Google déconstruit Android petit à petit en retirant certains composants pour les mettre à disposition différemment.
Cet article nous présente en détails la situation et explique en quoi cette séparation des composants ancrés au cœur du système est une bonne nouvelle, à la fois pour Google et ses partenaires mais aussi pour les utilisateurs d’Android.

objc.io #1 – Lighter View Controllers

Par Simone Civetta

Le premier numéro du nouveau magazine Web créé par Florian Kugler, Chris Eidhof et Daniel Eggert, objc.io, qui parlera des meilleures pratiques et techniques avancées du développement Objective-C.

Cette première edition se compose de cinq articles décrivant la manière d’écrire des viewControllers plus propres en séparant les responsabilités entre plusieurs classes ainsi que des techniques permettant de tester efficacement le code d’un viewController. Le dernière article présente quelques bonnes pratiques sur l’utilisation des API de view containement introduites dans iOS 5.

Web

Liste de liens autour d’AngularJS

https://github.com/jmcunningham/AngularJS-Learning

Cette page GitHub référence un ensemble de liens (articles de blog, videos, livres …) autour d’AngularJS, surement à garder dans vos favoris si la techno vous intéresse!

Le coin de la technique

Être notifié des mises à jour de ses artefacts maven

Le plugin Versions de Maven possède un goal indiquant les dépendances de notre build à jour et celle dont une mise à jour est disponible.

mvn versions:display-dependency-updates

Cependant, il peut être plus agréable d’être notifié par mail des nouvelles versions de nos dépendances. Le site artifact-listener permet soit en téléchargeant son fichier pom.xml, soit en choisissant directement ses artefacts via l’interface web de recevoir une notification à chaque nouvelle mise à jour de ceux-ci.

Le projet est open source sous license Apache V2, et est disponible sous github.

Javascript, retour aux bases : constructeur, prototype et héritage

Pierre Gayvallet — Mon, 10 Jun 2013 06:57:51 +0000

Depuis quelques temps, l’utilisation du javascript se démocratise. De langage permettant de faire clignoter un texte ou défiler un bandeau de pub sur votre site multimania, il est progressivement devenu un outil à part entière de toute application web, jusqu’au point, atteint récemment, d’être auto suffisant, et ainsi de voir émerger un certain nombre de librairies permettant de réaliser la partie interface d’une application (presque) exclusivement en javascript.

Pourtant, on partait de loin ! Très longtemps considéré par la majorité comme un language de bidouilleur tout juste bon à sortir du code inmaintenable, on aura tout entendu sur javascript : depuis « nan mais de toute façon javascript ca marche pas » jusqu’a « nan mais javascript c’est nul, c’est pas orienté objet : y a pas de classe » en passant par »nan mais moi le prototype j’ai rien pigé, pourquoi ils ont fait ca, sérieux ? », sans oublier le fameux « c’est quoi ce mot clef ‘this’ qui change tout le temps ? c’est vraiment le comportement voulu ? ». Encore maintenant, alors qu’il est devenu un des outils de tous les jours de pas mal de développeurs, ce genre de question perdure, démontrant que le mysticisme autour de javascript n’est toujours pas vraiment levé…

C’est pourquoi je pense qu’il est très important de comprendre les particularités de ce langage lors de son utilisation. Langage dont les concepts sont, de plus, aussi simples que puissants, pour peu que l’on accepte qu’il ne fasse pas tout comme les autres… Cette série d’articles, qui débute avec celui-ci, aura donc cet objectif : la compréhension des concepts inhérents au langage, ainsi que les subtilités et astuces tournant autour. Back to basics.

Dans ce premier article, je vais donc tenter de montrer le plus simplement possible les différentes approches pour faire de l’orienté objet » et des « classes » en javascript (sujet qui, contrairement aux idées reçues, est abordé depuis quelques temps maintenant), jusqu’à arriver sur l’approche prototype, concept apparemment proche du voodoo, que je ne manquerai pas de démystifier. Aller, c’est parti !

La déclaration inline

Parce qu’il faut bien partir de zéro, la première façon de construire un objet en javascript est la déclaration inline. Tout le monde a en effet déjà du croiser une déclaration de ce type :

var myObject = {
 a : 1,
 b : 2,
 sum : function() {
  return this.a + this.b;
 }
};

Ceci est une simple déclaration d’objet. On observe qu’on peut lui spécifier des méthodes comme propriétés, et que ces méthodes peuvent utiliser le mot clef « this ». Il est donc possible de déclarer un objet de cette manière.Cependant, on n’a pas ici de notion de classe ou de constructeur, aucune réutilisation possible. Si l’on veut déclarer un nouvel objet disposant des mêmes méthodes, il faut recommencer la déclaration… Pas très pratique.

Heureusement, des méthodes plus convaincantes existent.

Le constructeur auto déclarant

Car comme peu semblent le savoir, il est en fait très facile de déclarer un « constructeur » d’objet en javascript. En effet, toute fonction peut servir de constructeur : il suffit simplement de l’appeler avec le mot clef ‘new’. Cela peut effectivement être très déroutant au début – une fonction qui est une classe ? einh ? quoi ? – mais une fois le concept accepté, on retrouve une utilisation se rapprochant beaucoup de ce qu’on peut trouver dans les language OO plus « classiques ».

Prenons un exemple tout simple :

var Dog = function() {   // defining Dog constructor
 this.hasTail = true; // defining a property
 this.bark = function() { // defining a method property
  console.log("wouf wouf");
 }
}

var bobby = new Dog(); // instanciating the constructor

bobby.hasTail; // returns true
bobby.bark();  // print "wouf wouf" to the console

Et voila, voici une classe toute bête. On observe quand même que pour définir une propriété des futures instances, il faut utiliser le mot clef this. En effet ‘var’ ne suffit pas. C’est d’ailleurs une particularité intéressante dont on peut se servir pour déclarer des variables privées de l’instance :

var Dog = function() {
 var shout = "wouf wouf"; // defining a local var.
 this.bark = function() {
  console.log(shout); // local scope access the 'shout' variable
 }
}

var bobby = new Dog();

bobby.bark();  // print "wouf wouf" to the console
bobby.shout;   // undefined , not attached to the instance

Comme pour une fonction classique, il est également possible de passer des paramètres à un constructeur :

var Dog = function(breed) {
 this.breed = breed;
}

var bobby = new Dog("terrier");

bobby.breed;  // returns "terrier"

Cette méthode fonctionne bien. Cependant un problème de taille apparaît : comme la déclaration des méthodes se fait lors de l’instanciation, les instances ne partageant pas leurs méthodes.

En d’autres termes :

var Dog = function() {
 this.bark = function() {
  console.log(shout);
 }
}

var bobby = new Dog();
var felix = new Dog();

(boddy.bark == felix.bark); // returns false. They both declared their own method.

Si ce n’est pas très gênant sur une faible volumétrie d’instances, cela le devient cependant vite sur une application ‘full’ javascript avec des centaines de milliers d’objets, voir plus. De plus, il n’est pas possible de faire de l’héritage de classe avec cette approche (nous reviendrons sur ce point), ce qui est encore plus problématique en vu de notre objectif…

C’est ici que l’utilisation du prototype entre en jeu.

Constructeur et prototype

Alors, qu’est-ce qu’un prototype ? Et bien dit simplement, c’est une liste de propriétés, attaché à un constructeur, qui va servir de « fallback » lorsque l’on cherche à accéder à une propriété manquante d’une instance dudit constructeur. En effet, lorsque l’on cherche à accéder à une propriété sur une instance, on (comprendre : le langage) va d’abord regarder si l’instance contient cette propriété, et dans le cas contraire, va ensuite vérifier si le prototype de son constructeur la contient.

Si vous ne saviez pas ce qu’était un prototype avant le paragraphe précédent, vous en êtes probablement au même point ici. C’est normal. Ici un exemple sera plus efficace que toutes les définitions du monde.

Toute fonction déclaré possède nativement une propriété « prototype » initialement vide :

var Dog = function() {}; // declaring constructor
Dog.prototype;     // prints "{}" : prototype exists and is empty

Une propriété rajouté sur le prototype du constructeur devient disponible sur les instances :

Dog.prototype.bark = function() { // defining a method on the Dog prototype
 console.log("wouf wouf");
};

var bobby = new Dog();
bobby.bark(); // using the prototype declaration - prints "wouf wouf" to the console

var felix = new Dog();
(bobby.bark == felix.bark); // instances share same reference - returns true;
bobby.bark = Dog.prototype.bark // which is the prototype property - returns true;

Voila. C’est tout pour le principe de base, qui est au final aussi simpliste qu’inhabituel : on défini un constructeur, on lui rattache des propriétés (qui peuvent être des fonctions) via son prototype, on instancie le constructeur, l’instances dispose des propriétés définie sur le prototype de son constructeur. Voila, c’est tout. Simple non ?

Un peu plus sur l’utilisation du prototype

Il y a plusieurs subtilités à connaitre quant à l’utilisation des prototypes :

On peut surcharger sur une instance une propriété définie sur son prototype. Cependant cela ne surcharge que sa propre référence, et ne touche donc pas à la déclaration du prototype. Si l’on reprend la classe Dog telle que définie si dessus :

var bobby = new Dog();
var felix = new Dog();

bobby.bark = function() { console.log("beeeee !") }; // setting the bark property on dogA

bobby.bark(); // using the instance function, prints "beeee !" to the console

felix.bark(); // still using the prototype function, prints "wouf wouf" to the console.

Une modification du prototype est immédiate sur les instances déjà existantes et les futures. En effet le prototype est une référence des instances, et le « fallback » se fait au moment de l’accès à la propriété.

var bobby = new Dog();

bobby.bark(); // prints "wouf wouf" to the console

Dog.prototype.bark = function() { console.log("meow meow"); } // overrides the prototype bark method

bobby.bark(); // now prints "meow meow" to the console.

Nous arrivons à une particularité beaucoup plus intéressante : l’extension. En effet, tout comme une méthode modifiée sur le prototype est immédiatement active, un rajout l’est aussi :

var bobby = new Dog();

bobby.sleep(); // Raise a TypeError : has no method sleep

Dog.prototype.sleep = function() { console.log("Zzz Zzz"); }

bobby.sleep(); // now prints "Zzz Zzz" to the console.

La classe d’une instance (enfin, techniquement, le constructeur) est accessible via la propriété constructor. Cela permet également d’accéder à son prototype (même s’il est très rare d’y voir une utilité) :

bobby.constructor === Dog; // bobby constructor is Dog, returns true

bobby.constructor.prototype.bark // direct access to the prototype

Et le mot clef instanceof de javascript fonctionne bien avec les constructeurs :

bobby instanceof Dog; // bobby is an instance of Dog, returns true

Héritage, première approche

Nous sommes donc capable de déclarer un constructeur et un prototype, ce qui se rapproche énormément d’une déclaration de classe dans des langages OO plus classiques. Cependant, il nous manque une particularité souvent indispensable de l’orienté objet : l’héritage entre classes.

En javascript, il est possible de faire de l’héritage simplement en étendant un prototype à partir d’un autre. C’est par ce moyen que nous allons parvenir à faire notre première implémentation de l’héritage en javascript. Démonstration:

var Dog = function() {}; // defining Dog constructor and prototype
Dog.prototype.bark = function() { console.log("wouf wouf"); };

var Doberman = function() {}; // defining Doberman constructor
for(key in Dog.prototype) {   // copying all Dog prototype property into the Doberman property
 Doberman.prototype[key] = Dog.prototype[key];
}
Doberman.growl = function() { console.log("aouww"); }; // then adding some Doberman specific functions

var rufus = new Doberman();

rufus.bark();  // using the Dog bark method, prints "wouf wouf";
rufus.growl(); // using the Doberman growl method, prints "aouww";

Nous avons donc ici bel et bien deux déclarations de prototype, dont l’un étend les propriétés de l’autre. C’est la manière la plus simple de rendre disponible des méthodes dans différents prototypes, et peut être suffisant pour les besoins d’héritages les plus simples.

Attention cependant à ne surtout pas faire cela :

var Dog = function() {};
Dog.prototype.bark = function() { console.log("wouf wouf"); };

var Doberman = function() {};
Doberman.prototype = Dog.prototype; // warning : never do that : will share the same prototype !
Doberman.growl = function() { console.log("aouww"); };

Car dans ce cas la, Dog et Doberman partageraient le même prototype. Tout rajout ou modification sur l’un sera aussi effectif sur l’autre. Ce qui déclenche en général des effets de bord assez magnifiques et qui peuvent être compliqués à identifier.

Les limites de cette approche

On arrive ici dans les parties les plus techniques. Pour comprendre le besoin, il faut tout d’abord pointer du doigt deux problèmes de notre approche précédente qui, au final, ne fait que copier, à un instant T, les propriétés d’un prototype vers un autre.

Premier problème : instanceof ne fonctionne pas correctement :

rufus instanceof Doberman; // returns true
rufus instanceof Dog; // oh no, return false, ack !

En effet, nous avons simplement étendu le prototype du second avec des méthodes du premier. Les constructeurs de Dog et Doberman n’ont rien en commun.

Le second problème est qu’avec notre technique actuelle, nous avons perdu une partie de la magie du prototype :

var Dog = function() {}; // defining Dog
Dog.prototype.bark = function() { console.log("wouf wouf"); };

var Doberman = function() {}; // defining Doberman
for(key in Dog.prototype) {
 Doberman.prototype[key] = Dog.prototype[key];
}
Doberman.growl = function() { console.log("aouww"); };

var bobby = new Dog();
var rufus = new Doberman();

Dog.prototype.lick = function() { console.log("it tickles !") }; // adding a new method to the Dog's proto

bobby.lick(); // Dog instance can use this new method, prints "it tickles !"
rufus.lick(); // Doberman instance can't ! TypeError : Object [object] has no method 'tickle'

Et oui ! Comme nous avons juste, à un moment donné, copié les propriétés d’un proto vers l’autres… les modifications apportées après cette copie n’affectent pas ce dernier.

Le chainage de prototypes

Heureusement, il est possible de palier ces problèmes en chaînant les prototypes. Et oui, un peu comme dans Inception : a prototype in a prototype, we have to go deeper !

Expliqué simplement, nous allons faire en sorte que le prototype de Doberman ai lui même comme prototype Dog ! Ainsi, les instances de doberman regarderont dans le prototype de Doberman qui lui même regardera dans celui de Dog (même ce n’est pas exactement ca, mais nous allons le voir juste en dessous)

Alors, comment fait-on ça ? comme ceci :

var Dog = function() {}; // defining Dog constructor
Dog.prototype.bark = function() { console.log("wouf wouf"); }; // adding methods to Dog proto

var Doberman = function() {}; // defining Doberman constructor

var Surrogate = function() { // defining doberman surrogate constructor.
    this.constructor = Doberman;
};
Surrogate.prototype = Dog.prototype;  // setting Dog as the Surrogate prototype
Doberman.prototype = new Surrogate(); // then setting a surrogate instance as Doberman prototype

var rufus = new Doberman(); // here we go !

Comme on le voit en dessus, il y a en effet une subtilité : un prototype ne peut lui même avoir de prototype. Par contre, un constructeur peut avoir comme prototype une instance d’un autre constructeur disposant lui même d’un prototype ! Ce qui revient au comportement voulu, de manière un peu détournée.

Et c’est ce qu’on fait ici : On crée un constructeur intermédiaire »Surrogate » dont le prototype est Dog. puis on instancie ce constructeur, ce qui nous donne une instance ayant accès aux méthodes du prototype Dog. Et on fait de cette instance le prototype de notre constructeur Doberman. Et voila ! On arrive ici à avoir un héritage de ‘classe’ très proche de celui qu’on pourrait trouver en java par exemple :

var rufus = new Doberman();
Dog.prototype.lick = function() { console.log("it tickle") }; // adding new method to Dog prototype
rufus.lick(); // it works ! prints "it tickle" // rufus instance has access to the new method !

rufus instanceof Doberman; // still returns true
rufus instanceof Dog; // yippie ! now returns true !

Et de plus, notre autre problème est au passage corrigé : instanceof se comporte maintenant correctement. En effet, en interne, ce mot clef se base sur la chaine de prototype pour savoir si x est instance de X !

Situation réelle

Je sais ce que vous vous dites : oui mais…. si je dois faire ca à chaque fois que je veux faire un héritage de classe, ça va être un peu compliqué non ? Eh bien, c’est sur que dans l’état actuel des choses, c’est du code qui n’est pas vraiment réutilisable. Si l’on devait refaire le tour de passe passe du surrogate à chaque fois, cela serait un peu compliqué. Heureusement, ce code est facilement factorisable pour permettre une réutilisation :

var extendClass = function(child, parent) {
    var Surrogate = function() {};
    Surrogate.prototype = parent.prototype;
    child.prototype = new Surrogate();
};

var Dog = function() {};
Dog.prototype.bark = function() { console.log("wouf wouf"); };

var Doberman = function() {};
extendClass(Doberman, Dog); // using extendClass to makes Doberman inherits from Dog.
new Doberman().bark();  // works as previously : prints "wouf wouf"

Et voila. On est maintenant capable de faire étendre ‘simplement’ un constructeur à un autre constructeur via une méthode réutilisable.

En pratique on peut encore aller plus loin et définir une « Classe » de base qui permettra une déclaration plus facile de nos futur classes hérités :

// definiting the base constructor for all classes, which will execute the final class prototype's initialize method if exists
var Class = function() {
    this.initialize && this.initialize.apply(this, arguments);
};
Class.extend = function(childPrototype) { // defining a static method 'extend'
    var parent = this;
    var child = function() { // the child constructor is a call to its parent's
        return parent.apply(this, arguments);
    };
    child.extend = parent.extend; // adding the extend method to the child class
    var Surrogate = function() {}; // surrogate "trick" as seen previously
    Surrogate.prototype = parent.prototype;
    child.prototype = new Surrogate;
    for(var key in childPrototype){
        child.prototype[key] = childPrototype[key];
    }
    return child; // returning the child class
};

Ce qui nous permet désormais une déclaration de nos « classes » beaucoup plus lisible :

var Dog = Class.extend({
    initialize : function() { // initialize is called by constructor at instanciation.
  this.numberOfLegs = 4;
 },
    bark : function() { console.log("wouf wouf"); }
});

var Doberman = Dog.extend({
   growl : function() { console.log("aouwww"); }
});

var rufus = new Doberman();
// now play with it !

Et voila. Cette dernière approche est beaucoup plus satisfaisante : on peut définir simplement et de manière lisible nos classes javascript.

En pratique, c’est ce qui est utilisé dans presque toute les librairies actuelles : le système d’extension de vue/model de backbone par exemple, utilise simplement une version un peu plus avancé de notre méthode extend. Dans Angular, le système de cascading dans les scope fonctionne aussi comme cela : chaque scope fils a comme prototype le scope parent ! Et avant eux, mootools et prototype (la librairie) proposaient déjà une approche OO avec des méthodes similaires.

C’est également sur ce concept que se basent les transcompiler javascript tels que Coffeescript ou TypeScript pour leur approche objet.

Pour ceux qui veulent aller plus loin, il existe, depuis ECMAScript 5 (sur les navigateurs modernes donc) une alternative viable pour gérer la chaîne de prototype (et pas seulement) : Object.create (et au passage, un autre pointeur dailyjs).

Alors, au final, le prototypage, plutôt simple non ?

Xebia sera présent à dotSacle

Pablo Lopez — Fri, 07 Jun 2013 07:07:24 +0000

DotScale, la conférence technique sur les applications surdimensionnées, a lieu aujourd’hui, à Paris.

L’affiche est plus qu’alléchante ; au menu, les créateurs de frameworks star dans les domaines du BigData, comme Hadoop et ElasticSearch, mais aussi dans les domaines de l’infra (OpenStack, OpsWork), et des très grands du Web (Google Cloud Engine, Heroku, WordPress.com).

Nous serons sur place pour vous faire vivre, ce qui sera, nous l’espérons, un des évènements de l’année en ce qui concerne le monde des applications "hors normes".

J’ai essayé Bower, l’outil de gestion des dépendances front-end

Florent Duveau — Wed, 05 Jun 2013 12:55:57 +0000

Pourquoi ?

Le management de librairies externes a toujours été un casse-tête pour les développements front en javascript. Combien de fois sommes-nous allés sur le site de jQuery afin de récupérer la dernière version, de la remplacer dans notre dossier “/libs” et de faire la modification dans notre balise ...

config.js

require.config({
 baseUrl: 'js',
 paths: {
  jquery: 'libs/jquery/jquery',
  underscore: 'libs/underscore/underscore',
  backbone: 'libs/backbone/backbone',
  babysitter: 'libs/backbone.babysitter/lib/backbone.babysitter',
  wreqr: 'libs/backbone.wreqr/lib/backbone.wreqr',
  marionette: 'libs/marionette/lib/backbone.marionette',
  json2: 'libs/json2/json2',
  hogan: 'libs/hogan/web/1.0.0/hogan',
  mustache: 'libs/mustache/mustache',
  text: 'libs/requirejs-text/text',
  bootstrap: 'libs/bootstrap/docs/assets/js/bootstrap'
 },
 ...
});

Voilà, ça marche.

Je ne suis tout de même pas totalement satisfait. Hogan s’intègre très mal à bower, je suis obligé de spécifier la version dans mon import requirejs. Je devrai donc manuellement le changer lors d’une future mise à jour. De plus, les urls sont, comme je le craignais, hétérogènes. Si pour jquery, underscore ou backbone, la logique est la même, pour bootstrap je dois utiliser un chemin plus que douteux. Pour finir, tous mes composants ne possèdent pas de component.json. Je ne suis donc pas totalement sûr de la compatibilité entre mes versions. Tout ceci est sans doute imputable à la relative jeunesse du projet.

Pour conclure

Bower a eu la bonne idée de se reposer sur github pour sa gestion des composants, ce qui rend le catalogue immensément riche dès à présent. Sa simplicité et sa non-intrusion dans les autres briques du projet est aussi très appréciable. Couplé à grunt, bower devient un allié très puissant. Yeoman l’intègre d’ailleurs par défaut dans son workflow de création d’applications web.

Tout n’est pas rose cependant. Les projets sur github ont des architectures différentes et prennent plus ou moins (ou pas du tout) en compte bower. Ceci entraine une certaine frustration dans l’import des librairies. La solution serait qu’un compte github soit entièrement dédié aux imports des composants comme c’est déjà le cas avec le compte "Components" (https://github.com/components) qui ne possède pour l’instant que 33 repos. Bower pourrait aussi devenir plus strict dans l’ajout de librairies à son catalogue, comme par exemple obliger la présence du fichier component.json ou le respect d’une certaine architecture. Entre la qualité et la quantité, il faut souvent choisir...

Le fait que bower importe tous les fichiers des repos est aussi parfois frustrant dans la mesure où on n’utilise souvent qu’un fichier dans tout le repository.

Les choses devraient tout de même s’améliorer avec l’adoption massive de cette solution (si adoption il y a). Bower reste un outil pratique et je vais continuer à l’utiliser pour mes prochains projets front !

Revue de Presse Xebia

Xebia France — Tue, 04 Jun 2013 12:23:03 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

GameStorming, Reference Guide

uxdesign.smashingmagazine.com/2013/04/11/rainbow-spreadsheet-collaborative-ux-research-tool/

Gamestorming est un livre proposant un nombre incroyable de propositions d’outils proche du jeu pour conduire des réunions en entreprise (par exemple des réunions de type rétrospective ou brainstorming ou encore liées à l’innovation). Malheureusement ce livre ressemble à une longue liste et fini par être difficile à lire. C’est la que viennent nous aider trois ressources:
- un document Google Document (en espérant que le lien ne soit pas invalide rapidement) servant de guide de référence https://docs.google.com/document/d/1U_9_Of_lcpkzbRpThpSh7paIBPNG9m7vAcrG3wj0_cA/edit
- le site associé au livre http://www.gogamestorm.com/
- une application iPhone « Gamestorming Card Deck » qui récupère le contenu du site et le met dans une forme de pile de cartes pour se créer des decks pour préparer des ateliers

Rainbow spreadsheet collaborative UX research tool

Par Yannick Quenec'hdu

Cette article présente une petit outil pour les designers pour mieux appréhender le ressenti des utilisateur face à la création de nouveau produit.

Pour renforcer l’Agilité IT, il est nécessaire d’accepter l’échec.

http://www.lemondeinformatique.fr/actualites/lire-pour-renforcer-l-agilite-it-il-est-necessaire-d-accepter-l-echec-53610.html

Quel ScrumMaster ou Coach Agile n’a pas entendu une fois (au moins) dans sa carrière un Chef de Projet, un représentant du métier ou un DSI dire « L’agilité ça ne marche pas » au moindre problème rencontré sur un projet Scrum par exemple et aussitôt déclarer l’abandon des projets Agiles dans son organisation.

Cet article du Monde rapporte une étude du cabinet Gartner sur la nécessité pour une organisation (DSI, Métier, tous les acteurs en fait) de savoir accepter un taux d’échec des projets (de l’ordre de 20 à 28%). L’objectif de ce changement de mentalité et de pousser les organisations à tirer le bilan de leurs échecs, afin d’apprendre à s’améliorer et ainsi minimiser les pertes et identifier plus tôt les points de blocages.

C’est Lean, c’est Agile, c’est Lean startup.

Web

Sortie Ember JS RC 5 et Ember Data 0.13

Par Benoit Lemoine

Cette semaine fut riche pour l’écosystème Ember, avec la sortie de la version 0.13 de Ember Data et la sortie de la version RC5 de Ember.

Le framework JavaScript étant dans la dernière ligne droite vers la version finale 1.0, la version RC5 n’apporte que des corrections de bugs et des optimisations.

À l’inverse, Ember Data voit sortir sa première version officielle, mais reste extrêmement instable, et doit être considéré comme une version alpha. La librairie est encore sujette à beaucoup d’évolution, et va en particulier mettre l’accent sur le support des promesses et la gestion d’erreurs dans sa prochaine version.

Minimifier un projet Angular

Une des problématiques récurrentes sur les projets Angular est la minimisation du code javascript. Par défaut, angular base son système d’injection de dépendances sur les noms des paramètres, et donc le changement de nom de ceux-ci par la minimisation du code casse ce beau système. On se retrouve alors avec un nombre conséquent d’erreurs javascript du type missing provider, …

Cet article explique comment écrire son code javascript pour contourner cette problématique.

Comprendre le fonctionnement de la JVM – Article 2/2

Pierre Laporte — Mon, 03 Jun 2013 08:01:21 +0000

Dans le premier article de cette série, nous avons vu comment la JVM optimise notre code. Ici, intéressons nous à la manière dont la mémoire est gérée et aux différents Garbage Collectors.

L’hypothèse générationnelle

Toute la gestion de la mémoire opérée par la JVM se base sur une hypothèse générationnelle, résumée par la phrase "la plupart des objets meurent jeunes" ou encore "La plupart des objets créés deviennent très rapidement inaccessibles".

L’idée derrière cette hypothèse est que les applications créent de nombreux objets pour leur fonctionnement, mais que seule une faible partie d’entre eux a une longue durée de vie. Ainsi, les différentes étapes d’un traitement génèrent beaucoup d’objets transitoires mais une seule donnée finale.

Le graphique suivant résume la quantité d’objets créés par une application en fonction de leur âge.

Note : un objet est considéré comme toujours en vie s’il existe un autre objet vivant qui le référence.

Les espaces mémoire utilisables

Dans cette optique, la mémoire utilisable de la JVM est fragmentée en deux zones : la young generation qui contient les nouveaux objets et la old generation qui contient les objets ayant une longue durée de vie.

La young generation est elle-même fragmentée en trois espaces distincts : l’Eden dans lequel tous les objets sont crées et deux zones dites "Survivor" qui servent de sas d’entrée dans la old generation.

Le cycle de vie de tous les objets commence dans l’Eden. Au premier passage du garbage collector, si l’objet est toujours vivant il est déplacé dans la zone "Survivor 1". À chaque prochain passage du GC, il sera déplacé dans l’autre zone "Survivor" jusqu’à un certain seuil. Au delà, il sera déplacé dans la old generation.

Prenons l’exemple d’une application avec 2 types d’objets A et B avec un seuil générationnel de 4. Tous les objets sont crées dans l’Eden et ont un âge de 1. Au premier passage du GC, seul B (âge : 2) est toujours utilisé, il est donc déplacé dans le Survivor 0 tandis que A1 est collecté. Au second GC, un nouvel objet A2 (âge 1) est crée, B (âge : 3) est toujours utilisé et est déplacé dans Survivor 1. Au troisième passage du GC, A2 (âge : 2) et B (âge : 4) sont toujours vivants et donc déplacés dans Survivor 0. Enfin, au cinquième GC, l’age de B (âge : 5) dépasse le seuil générationnel, B est donc transféré dans la old generation tandis que A2 (âge: 3) passe dans le Survivor 1.

Les collections

Deux types de collections ont été implémentés d’après l’hypothèse générationnelle : les collections mineures qui récupèrent la mémoire dans la young generation et les collections majeures qui récupèrent la mémoire dans la old generation. On confond parfois collection majeure et Full GC, ce dernier terme indique une collection dans la young et la old generation.

Par application de l’hypothèse, les collections mineures sont celles qui arriveront le plus souvent. Les espaces mémoire et le garbage collector sont donc spécialement optimisés pour que celles-ci durent le moins de temps possible.

Les collections majeures sont bien plus coûteuses, car elles doivent scanner l’intégralité de la mémoire pour déterminer si les objets de la old generation sont toujours vivants.

Les pauses du GC

Les algorithmes de GC imposent parfois une pause de l’application (Stop The World). Dans ce cas de figure, le garbage collector fige tour à tour chacun des threads de l’application lorsqu’ils atteignent un point d’arrêt. Cette première étape peut déjà prendre un certain temps, en effet, le GC ne peut pas figer tous les threads en une seule fois tant que ces derniers ne sont pas dans un état cohérent. Ensuite, le GC élimine les objets non utilisés et redémarre tous les threads de l’application.

L’un des objectifs d’une JVM correctement paramétrée est d’avoir le moins de Full GC possible, cet objectif est atteint lorsque l’application passe moins de 5% de son temps figée à cause du GC.

La old generation n’existe que pour optimiser le travail du Garbage Collector et diminuer les pauses éventuelles de l’application. Lorsque l’âge d’un objet a dépassé un certain seuil, on peut affirmer que cet objet constitue l’exception de l’hypothèse générationnelle : sa durée de vie sera bien plus longue que la majorité des objets de l’application. Il n’est alors plus utile de le scanner pour déterminer s’il est un objet à faible durée de vie, cela ne ferait que ralentir le travail du GC dans l’Eden.

Les logs

Pour pouvoir tuner une JVM, il est nécessaire d’avoir les logs du garbage collector. Ces derniers contiennent énormément d’informations et permettent de prendre des décisions éclairées et de mesurer les progrès effectués.

Les logs peuvent être activés par l’option -Xloggc:logs/gc.log qui crée un fichier gc.log dans le dossier logs/. Il est également recommandé d’ajouter des informations complémentaires avec les options -XX:+PrintGCDetails et -XX:+PrintTenuringDistribution. Ces deux options donnent des détails sur la manière dont la mémoire est utilisée et permettent d’identifier très facilement les problèmes de dimensionnement de la heap.

La lecture des logs peut-être très fastidieuse sans les outils appropriés. Il est possible d’utiliser HPJmeter (gratuit, www.hp.com/go/hpjmeter), GCViewer (gratuit et open-source, https://github.com/chewiebug/GCViewer) ou JClarity Censum (payant, www.jclarity.com/products/censum/).

Les types de collections

Il existe deux stratégies pour le nettoyage de la mémoire : Mark & Evacuate et Mark, Sweep & Compact.

Dans la stratégie Mark & Evacuate, le GC travaille en deux phases : dans un premier temps, tous les objets vivants de l’application sont marqués. Ces mêmes objets sont ensuite recopiés dans une nouvelle zone mémoire et les pointeurs sont réécrits pour référencer les nouvelles adresses.

Le principal avantage de cette stratégie est que la mémoire n’est pas fragmentée. En effet, la zone nettoyée peut être considérée comme vide à l’issue de la copie puisque les objets vivants ont été "déplacés". L’inconvénient de cette stratégie est qu’elle est plus coûteuse en mémoire à cause de la copie des objets. Cette copie nécessite du temps et au moins autant d’espace que d’objets vivants, elle est donc réservée à des espaces à taille raisonnable. Son principal avantage est que son temps d’exécution est proportionnel au nombre d’objets vivants.

C’est cette stratégie qui est utilisée dans la young generation et qui fait le passage des objets depuis l’Eden vers un Survivor, puis d’un Survivor à l’autre et enfin d’un Survivor vers la old generation.

Dans la stratégie Mark, Sweep & Compact, en revanche, ces inconvénients n’existent pas. Le GC travaille en trois temps : dans le premier, il marque les objets vivants. Les objets morts sont ensuite supprimés, ce qui a pour effet de fragmenter la mémoire. La mémoire devra alors être compactée pour que l’espace libéré forme un bloc contigu.

L’avantage de cette stratégie est donc la vitesse d’exécution des deux premières phases et la moindre consommation mémoire. L’inconvénient est que la phase de défragmentation est quant à elle très coûteuse en temps.

Le choix d’un Garbage Collector

Plusieurs garbage collectors ont été développés pour permettre la récupération de la mémoire dans différents contextes. On distingue les GC qui travaillent dans la young generation de ceux qui travaillent dans la old generation. Dans cet article, intéressons nous aux GC les plus fréquemment utilisés : ParallelGC (young) + ParallelOldGC (old) et ParNew (young) + CMS (old).

Les GC Parallel et ParallelOld

Initialement, le garbage collector de la JVM n’utilisait qu’un seul thread, ce qui rendait son exécution particulièrement longue sur les heap de plusieurs giga-octets. Les GC "Parallel" permettent de régler ce problème en créant un nombre de threads proportionnel au nombre de cores disponibles sur le serveur.

Les GC "Parallel" font partie de la catégorie "Throughput". Leur objectif est de récupérer le plus de mémoire possible en un minimum de temps. Ils sont utilisés dans des applications sans contrainte "temps-réel" car les pauses peuvent être assez longues (plusieurs secondes). On les active, par exemple, sur les traitements batchs.

Ces garbage collectors offrent le meilleur ratio entre overhead et mémoire libérée.

Dans la young generation, on peut activer le GC Parallel via l’option -XX:+UseParallelGC. Ce dernier suit la stratégie Mark & Evacuate et a donc un temps d’exécution proportionnel au nombre d’objets vivants dans la young generation. Dans une JVM correctement tunée, avec une heap de quelques Go, les temps de pause se comptent en dizaines de millisecondes.

Dans la old generation, on peut activer le GC Parallel via l’option -XX:+UseParallelOldGC. Celui-ci suit la stratégie Mark, Sweep & Compact et a donc un temps d’exécution plus long car proportionnel à la taille de la heap. Dans une JVM correctement tunée, pour une heap de quelques Go, les pauses du ParallelOldGC peuvent prendre plusieurs secondes. Ces temps de pauses augmentent considérablement lorsque la taille de la heap se compte en dizaines de Go.

Il est possible de spécifier le nombre de threads utilisables par les GC parallèles via l’option ParallelGCThreads (par exemple, pour 8 threads, -XX:ParallelGCThreads=8).

Les GC ParNew et CMS

Les garbage collectors parallels sont particulièrement inadaptés aux problématiques temps réel. Par exemple, sur des sites à très fort traffic comme Twitter, des pauses de plusieurs secondes ne seraient pas acceptables. Deux garbage collectors ont donc été ajoutés : CMS (Concurrent Mark & Sweep) et ParNew. Ils permettent de minimiser les temps de pause, mais impliquent un overhead plus important.

Ces deux garbage collectors offrent le meilleur ratio entre temps de pause et mémoire libérée.

Dans la young generation, on peut activer le GC ParNew via l’option -XX:+UseParNewGC. Ce dernier est relativement semblable au ParallelGC (stratégie Mark & Evacuate, temps d’exécution proportionnel au nombre d’objets vivants) à la différence près qu’il a un overhead plus important que ce dernier. La principale caractéristique de ParNew est qu’il est compatible avec CMS et qu’il peut lui envoyer des informations sur l’utilisation de la young generation, chose que le ParallelGC ne peut pas faire. Les pauses de ParNew sont bloquantes et sont de l’ordre de la milliseconde dans une JVM correctement tunée.

Dans la old generation, on peut activer le GC CMS via l’option -XX:+UseConcMarkSweepGC. Comme pour ParallelOldGC, il a un temps d’exécution proportionnel à la taille de la heap. En revanche, l’exécution de CMS ne bloque pas les threads de la JVM, elle se fait pendant l’exécution de l’application et partage donc le temps CPU avec cette dernière.

CMS suit la stratégie Mark, Sweep & Compact mais n’effectue la compaction qu’en dernier recours, c’est à dire lorsque la heap est tellement fragmentée qu’un objet de la young generation ne peut pas être déplacé dans la old generation car il n’existe pas de bloc contigu suffisamment grand pour l’y acueillir. Dans ce cas de figure, on parle alors de promotion failure et la JVM déclenche un Full GC parallèle (bloquant) pour compacter la heap.

Grâce à la communication entre ParNew et CMS, il est possible de déclencher un cycle de CMS lorsque l’utilisation de la young generation dépasse un certain seuil, donné par l’option InitiatingHeapOccupancyPercent en pourcentage (valeur par défaut : 45%).

Le GC Garbage First

Un nouveau garbage collector baptisé G1 (Garbage First) a été introduit en version béta dans la JVM 1.6 et est considéré stable depuis la JVM 1.7.

La force de G1 tient dans les objectifs qui peuvent lui être définis. Par exemple, si l’on souhaite qu’aucune pause ne dépasse 300ms, il suffit de spécifier l’option -XX:MaxGCPauseMillis=300 pour que les cycles de G1 s’arrêtent une fois ce délai dépassé.

Attention toutefois à ne pas spécifier une limite trop basse. Si la durée maximale est trop faible, G1 se déclenchera plus souvent pour pouvoir libérer de la mémoire et cela aura donc un effet contre-productif. Si malgré des déclenchements plus fréquents, la heap est complètement remplie, la JVM déclenche un Full GC parallèle qui est bloquant pour nettoyer toute la heap.

Objectifs de tuning et indicateurs

Lorsque l’on souhaite affiner le comportement de la JVM, il est important de définir des métriques qui vont permettre de mesurer l’état d’une application en fonction du temps. Les indicateurs les plus souvent utilisés sont :

Temps passé dans le GC sur toute la durée de l’application en pourcentage. Lorsque cet indicateur est supérieur à 5%, cela signifie que des actions peuvent être menées sur la heap, le garbage collector ou le code de l’application.
Temps passé dans le GC par minute (minimum, moyenne et maximum). Cet indicateur fonctionne sur le même principe que le précédent mais indique en plus la durée maximale de pause que l’application a subi
Fréquence de lancement des GC. Lorsque cet indicateur est élevé, il faut analyser la quantité de mémoire libérée à chaque GC pour déterminer un éventuel problème de dimensionnement de la heap
Nombre de Full GC. Les full GC bloquent l’application, il faut donc faire en sorte d’avoir un nombre de Full GC proche de 0.

Piège 1 : Ne pas activer les logs GC

Il est assez fréquent de voir des applications sur lesquelles les logs GC ne sont pas activés par peur que cela allonge le temps de collection. Ces craintes sont généralement toujours infondées car la quantité d’information écrite par le GC dans son log est très faible (de l’ordre d’un ou deux tweets).

Le vrai problème que cause ce piège est que sans les logs du GC, il est impossible de connaître les informations qui permettront de tuner efficacement une JVM, comme par exemple l’utilisation des différents espaces, ou la vitesse de création des objets.

Piège 2 : Fixer au démarrage la taille de la heap

L’un des paramétrages fréquemment constatés dans une JVM est le pattern Xms=Xmx (ou sa variante ms=mx). Il permet d’allouer toute la mémoire dont la JVM aura besoin à son démarrage et de ne jamais restituer cette mémoire à l’OS. La justification habituelle de ce pattern est que cela permet de s’affranchir d’appels systèmes malloc et free, qui sont coûteux, et donc d’améliorer les performances de la JVM.

Cependant, ce paramétrage est rarement une bonne idée.

Plus la heap est volumineuse, plus les temps d’exécution du garbage collector vont être importants. La réduction de la taille de la heap peut être une stratégie utilisée par la JVM pour améliorer les performances de l’application en diminuant les pauses du GC, or si la taille de la heap n’est pas modifiable, cette stratégie ne peut pas être implémentée.

Il faut également savoir que l’augmentation et la diminution de la taille de la heap ne se font que lors de full GC, c’est à dire que lorsque l’application est déjà en pause. Or une JVM correctement tunée passe moins de 5% de son temps dans des full GC. En résumé, ce pattern tente d’accélérer une portion marginale de l’exécution d’une application, tout en entraînant une diminution des performances globales.

Piège 3 : libérer la mémoire avec System.gc()

On tombe parfois sur des appels à System.gc() ou Runtime.gc() dans certaines bases de code. L’idée est alors de forcer le démarrage du garbage collector plutôt que de le subir.

Cette approche a plusieurs inconvénients. Tout d’abord, d’après la spécification Java, un appel à System.gc() n’entraîne pas nécessairement le démarrage du Garbage Collector. Il ne faut donc pas nécessairement partir du postulat "Un appel à System.gc() lance le garbage collector". Dans OpenJDK, cette méthode déclenche effectivement le garbage collector, mais il ne s’agit que d’un détail d’implémentation.

Mais le véritable problème est que c’est un full GC qui est déclenché, ce qui provoquera une pause dans l’application pour aller collecter des objets dans toute la heap (young et old generation, éventuellement permanent generation).

Si le traitement précédant l’appel à System.gc() a produit des objets à faible durée de vie, alors ces derniers ont probablement déjà été collectés par un young GC, ce qui veut dire que nous allons collecter toute la heap pour récupérer des objets déjà éliminés. Dans le cas contraire, rien ne nous garantit qu’un Full GC n’a pas déjà été exécuté, on aboutit alors à deux full GC au lieu d’un seul.

Il est possible de désactiver totalement la méthode System.gc() sur toute une JVM par le paramètre -XX:+DisableExplicitGC, mais ceci ne fonctionne que sur OpenJDK et n’est qu’une solution de contournement.

Lorsque l’on paramètre une JVM, on essaye d’obtenir le moins de Full GC possible, et les appels à System.gc() rendent cet objectif inatteignable.

Conclusion

La JVM, dans son paramétrage par défaut, tente de s’adapter le plus possible au profil de consommation mémoire de l’application. Lorsque l’on souhaite affiner le comportement de la JVM, il faut s’assurer de comprendre la situation courante et d’avoir les informations requises pour pouvoir justifier qu’un paramétrage différent donnera de meilleurs résultats. Pour cela, il est impératif d’avoir les logs d’exécution du GC et de solides connaissances sur le fonctionnement des GC.

Dans cet article, nous avons pu voir que la gestion de la mémoire est un sujet très complexe et passionnant. Les ressources sont nombreuses sur le sujet et il ne faut pas hésiter à expérimenter pour bien comprendre le fonctionnement interne de la JVM.

Les outils du développeur moderne

Guillaume Balaine — Fri, 31 May 2013 08:34:18 +0000

L’âge de pierre du développement logiciel a été dominé par la répétition de tâches : coder, compiler, livrer. Au fil des ans, les développeurs des différentes tribus ont développés leurs “bifaces” pour s’améliorer : outils de build, de packaging et autres. Les développeurs ont gagné en efficacité et se sont libérés du temps pour des tâches plus nobles, telles que les tests automatisés, l’optimisation, l’architecture logicielle ou plus simplement le métier de l’application. De nos jours, les outils de développements sont légion, et il en apparaît de nouveaux régulièrement. Ainsi, il devient parfois difficile de s’y retrouver.

Evaluer un outil

Comme le dit un proverbe Français : “Les mauvais ouvrier ont toujours de mauvais outils”. Mais qu’est-ce qu’on bon outil, et plus particulièrement, un bon outil de développement logiciel ? Quel intérêt d’investir du temps et de chercher de meilleurs outils que ceux qui sont en place ? Quel gain pour mon projet, mon équipe ? Et ces nouveaux outils, quels sont-ils ?

Les outils de développement recouvrent à la fois, les capacités du système d’exploitation, du langage de programmation utilisé, mais aussi de l’IDE et des différents frameworks que vous pouvez être amenés à choisir. Tout programme pouvant aider le développeur à travailler de façon plus efficace est un outil de développement. Voici les qualités que nous sommes en droit d’attendre d’eux :

Productivité : Un outil doit permettre d’effectuer une tâche plus rapidement, ou plus efficacement, et avec une qualité au moins égale à la procédure qui le précède.
Intégrabilité : Être opérable dans mon environnement, sans perturber ma chaîne d’outil, si possible être en synergie avec les autres outils et fonctionner sur plusieurs OS.
Fiabilité : Être fiable, fonctionner en adéquation avec la documentation, et de façon homogène en fonction des environnements.
Simplicité : Être facile à prendre en main et ne pas devenir un obstacle dans mon workflow.

Nous allons passer en revue les outils qui peuvent vous changer la vie au cours du cycle de vie d’un projet.

Concevoir

La conception est le départ des idées et la définition sur laquelle se basera le développement. Avant d’être avancée ou technique, elle doit être claire. Les outils d’aide à la conception vous permettront de produire une représentation compréhensible par tous les intervenants sur un projet, de partager une vision. Il faut privilégier les outils simples et schématiques :

FreeMind est un outil open source pour faire des "Mind Maps", c’est à dire des diagrammes à idées avec des liens entre elles.
Google Docs propose des outils "office" classiques gratuits et concis et qui vont droit au but, de plus il est très simple de faire de l’édition concurrente.
yEd est un outil de modélisation utilisé notamment par le projet Apache Ivy, on peut y faire de l’UML, du BPMN ou tout autre type de représentation populaire, l’outil est gratuit et très simple à prendre en main.

Partager…

… la base de code

Partager des fichiers et la base de code est essentiel dans un projet. La meilleure façon de le faire est d’utiliser un outil de gestion des sources. Subversion a été longtemps populaire, mais depuis quelques années, l’outil montant est Git, créé par Linus Torvald pour gérer les sources du projet Linux.

Le principal avantage de Git sur Subversion est que chaque développeur peut faire des commits sur sa machine sans impacter directement le dépôt commun. Cela permet donc aux développeurs :

de faire des commits plus petits, ce qui facilite les merge par Git ;
de réduire l’effort de merge manuel quand il y a malgré tout des conflits.

Git possède également des algorithmes de merge de fichier beaucoup plus performants que Subversion. Le travail en local sur chaque poste facilite les manipulations de branches et les développeurs acquièrent rapidement plus de maîtrise sur leur base de code.

De nombreux outils permettent de gérer ces dépôts de manière distribuée, en proposant des batteries d’outils de gestion de projet et d’interaction avec les autres développeurs autour de votre base de code.
Le plus populaire est de loin Github, gratuit pour les projets open source. Gitlab est une version open source à installer soi-même.
Il existe aussi des outils graphiques tels que gitk, SourceTree d’Atlassian, qui lui est payant. Enfin, Git s’intègre aussi très bien à Eclipse via EGit et IntelliJ.

… le travail

Il est également appréciable d’avoir un outil de gestion des tâches qui intègre la méthodologie Agile et le cycle de vie d’une tâche dans un backlog (journal de bord) Kanban ou Scrum par exemple.
Pour ce faire les principaux sont JIRA d’Atlassian (payant), Redmine (open source), Mantis (open source) et Trello (en ligne, gratuit), mais les plateformes de gestion des sources comme Github possèdent leur propre système.
Ces outils possèdent tous des APIs qui permettent de les intégrer à des SI et des outils de reporting existants. Grâce à cette trace gardée dans ces outils, on peut facilement retrouver les spécifications d’une implémentation et éventuellement le code associé, ce qui réduit dramatiquement le temps de résolution des erreurs et améliore la maintenabilité des projets, permettant d’allouer des ressources à l’avancement de celui-ci.

Coder avec …

… un langage

Malheureusement le cadre de cet article ne nous permet pas de traiter de tous les langages de programmation prêts pour de vrai projets de production. Il faudrait un livre entier pour traiter des différents points forts et faibles de chacun. Nous allons nous limiter à quatre langages qui ont la côte ces derniers temps :

Java : Le leader, très grosse communauté, beaucoup d’outils ;
Groovy : Présent dans beaucoup de projets sous forme de scripting, d’outils de monitoring ;
Scala : Le langage fonctionnel qui monte ;
JavaScript : L’assembleur du web, qui passe maintenant côté serveur.

… un IDE

Les environnements de développement les plus populaires sont IntelliJ et Eclipse. Ces deux IDE permettent de développer dans à peu près n’importe quel langage. Pour choisir votre IDE de rêve, penser à soupeser :

L’intégration des technologies que vous utilisez : compilation automatique, complétion de code, formatage, plugins dédiés aux frameworks utilisés, moteur de templates ;
Un contrôle complet à partir du clavier pour une productivité maximale ;
Zero Turn Around : mon IDE doit être capable de minimiser le temps entre l’écriture de mon code et le feedback (tests ou redéploiement) ;
Build incrémental : les classes modifiées doivent être recompilées rapidement, sans déclencher un build complet ;
Les capacité de refactoring.

Il arrive parfois que ces deux IDE phares soient tout simplement trop gros pour votre projet. Parmi les éditeurs de texte à fort potentiel pour les développeurs, je vous conseille SublimeText. Pour les puristes, Emacs, Vi ou TextMate remplissent toujours leur rôle avec brio.

… un Framework

Le Framework, comme son nom l’indique, offre un cadre de travail pour des technologies à travers un certain nombre de concepts. La problématique du Web est riche, et il est intéressant de voir comment les nouveaux frameworks tentent de répondre à la fois à ses impératifs, et de satisfaire les besoins d’industrialisation des SI d’entreprise.

Il existe aujourd’hui deux Frameworks Web en vogue pour la JVM intégrant de nombreuses JSR :

Grails, grâce à son moteur de plugins, et aux principes Convention Over Configuration et Don’t Repeat Yourself (Groovy, Spring), permet de démarrer des projets en un temps record et d’intégrer toutes sortes de technologies externes. Il permet de faire du Domain Driven Development et de générer une application entière à partir d’un simple modèle de données.
Play, grâce à la forte optimisation du langage Scala par la compilation statique et à son footprint mémoire faible, est un framework à haute performance. De plus, son modèle d’IO itératif, permet d’être directement asynchrone, ce qui est nécessaire pour des applications web utilisées à grande échelle.

Pour rester dans le Web, depuis la montée en puissance de HTML5, un nouveau framework Javascript naît chaque mois. L’un des plus prometteurs est AngularJS. Le but de ces frameworks est de créer des applications Web performantes tout en respectant les standards W3C. AngularJS est un MVC côté client. Il embarque des directives (mise à jour du DOM), de l’injection de dépendances entre composants, des intercepteurs pour les requêtes http, et des services (injectables et réutilisables dans les controleurs), et surtout une méthodologie de tests unitaires, basée sur Testacular.

Tester …

… unitairement

Tester le code est fondamental. Les tests unitaires sont là pour tester la logique interne de chaque méthode. Idéalement on appliquera le Test Driven Development qui permet d’avoir un code plus proche des spécifications.
Quelques librairies disponibles :

Java : FestAssert, Mockito ;
Groovy : Spock, Geb ;
Scala : ScalaTest, Specs2 ;
Javascript : Testacular, Qunit.

… en intégration

La dynamique entre les composants doit également être testée à travers les tests d’intégration et fonctionnels.
Pour tester des pages web, PhantomJS ou son spin-off CasperJS permettent d’émuler un navigateur et exécuter des scénarios sous forme de script Javascript.
Dans le cas d’une API REST écrite avec la JSR 311 (JAX-RS), Apache CXF permet de générer automatiquement des clients de test.

… sous pression

Souvent délaissés par manque de temps ou délégués à des équipes dédiées, les tests de performance doivent être intégrés au plut tôt dans le cycle de développement pour évacuer des problèmes structurants pour l’application. Pour nous aider, il existe un certain nombre d’injecteurs, citons :

Gatling permet d’exécuter des scénarios à l’aide d’une DSL écrite en Scala, consomme peu de ressources et s’intègre bien avec Maven et Jenkins.
JMeter a une interface graphique plus complète et peut adresser un large panel de protocoles

Livrer

Pour s’assurer en permanence que l’application est livrable, il faut automatiser le build, les tests automatisés et le packaging. Il existe un certain nombre de serveurs d’intégration continu (CI) qui permettent d’ordonnancer ces étapes. Le plus populaire est sans doute Jenkins, dont Cloudbees propose un hébergement en ligne, ainsi que Travis, plus ouvert sur les autres langage que Java.

Pour automatiser le déploiement de machines dans un environnement Cloud, il existe Chef, Capistrano et Puppet, ainsi que des outils en ligne tels qu’Amazon Web Services. Ce sont généralement des scripts qui déploient des machines ou des ASGs (Auto Scaling Group) dans le Cloud puis activent des services tels que les connecteurs à des bases de données ou l’installation de serveurs.

Monitorer et debugger

Votre application est enfin codée, testée, livrée, mais il y a des soucis en production. Pour vous aider à poser un diagnostic, la boite à outils s’alourdit encore un peu. Tout d’abord, il y a des outils de console essentiels pour démarrer l’analyse :

nmap : scanner de ports, vous permettra de vite trouver les erreurs de visibilité réseau ou de configuration de firewall ;
lsof, ps, top : déterminer quels programmes sont lancés et utilisent une ressource dans le système ;
ssh, scp : se connecter à une machine distante et y copier des fichiers, créer des tunnels pour connecter des programmes à travers une machine.

Si les problèmes se trouvent dans une page Web, tournez vous alors vers Firebug, Chrome Dev Tools ou modern.ie, suivant votre navigateur. Il y a là tout le nécessaire pour faire de l’introspection de page.

Pour pouvoir tirer de l’information des entrailles de votre application, il reste les logs et le monitoring. Pour ça, penchez vous sur :

Graphite : pour effectuer des graphes de toutes les métriques de votre application ;
JavaMelody : Pour vérifier l’activité du réseau et des requêtes ;
VisualVM : pour observer vos Thread applicatifs et l’utilisation de la mémoire en direct ;
Nagios ou Ganglia : Plateforme de monitoring et de lancement d’alerte pour être prévenu au plus tôt des pannes ;
Logstash ou Graylog2 : si la gestion et l’analyse de vos log est complexe.

Conclusion

Les bénéfices cumulés des outils de développement contrebalancent largement le coût initial et leur support. Ils peuvent changer complètement la vie d’un projet, les développeurs pouvant se concentrer sur de la vraie valeur ajoutée : la qualité des livrables.

Nous n’avons traité ici que quatre langages, mais n’allez pas vous imaginer qu’ils sont les seuls à être outillés, C#, Ruby, Clojure, et les autres, recèlent aussi de nombreuses pépites, comme Cucumber ou Luminus par exemple. Cela sera peut-être le sujet d’un prochain chapitre.

Gardez à l’esprit que le meilleur outil est celui qui vous va et qui vous facilite la vie. A vous maintenant de vous forger votre boite à outil sur mesure, adaptée à vos contraintes. Testez, mesurez les gains, jugez, recommencez.

What’s new in Android ?

Thomas Guerin — Thu, 30 May 2013 07:34:00 +0000

Google I/O s’est terminé le 17 mai et après 3 jours de sessions non stop, il est temps de revenir sur les annonces faites lors de la conférence. En 2013, Android représente au total pas moins de 900 millions d’activations avec près de 2.5 milliard d’applications installées chaque mois. Ces chiffres confirment la bonne santé de l’OS mobile au robot vert. Les annonces de cette année vont d’ailleurs dans ce sens car les développeurs de la plateforme Android ont eu le droit à leur lot de bonnes nouvelles.

Android Studio

Une des plus grosses surprises reste l’annonce du nouvel environnement de développement : Android Studio. En effet après des années à développer le plugin ADT pour Eclipse, Google s’oriente maintenant vers un IDE qui s’appuie sur IntelliJ. JetBrains a d’ailleurs écrit une entrée dans leur blog suite aux nombreuses questions suscitées par cette annonce. Il en ressort qu’Android Studio et le plugin Android d’IntelliJ sont construits à partir de la même base de code. Toutes les nouvelles fonctionnalités présentes dans Android Studio seront donc disponibles dans les prochaines releases de la version 13 d’IntelliJ.

Android studio est actuellement disponible en early preview et dispose de nouvelles fonctionnalités intéressantes dont notamment :

Le support du nouveau système de build : Gradle,
Un éditeur graphique plus abouti, permettant de voir le rendu sur plusieurs devices en même temps,
Possibilité de voir la valeur d’une ressource suivant la langue directement dans le code.

Un nouveau système de build

Lors de la présentation "The New Android SDK Build System", Xavier Ducrochet nous a introduit le nouveau système de build pour Android : Gradle. Le plugin Android est actuellement en version 0.4.1 et propose déjà un ensemble de fonctionnalités prometteuses. Entre autres un système de flavors qui permet de construire différentes versions d’une même application mais aussi de facilement mettre en place du multi-apk. Pour plus d’informations concernant ce système de build, la documentation officielle est vraiment claire et met à disposition des projets d’exemple.

Cette annonce va de paire avec celle d’Android Studio qui intègre déjà le support de Gradle. Seule ombre au tableau, ce plugin utilise un nouveau format (.aar) pour packager les librairies nécessitant des ressources Android qui n’est pas compatible avec le format apklib de Maven Android. Il faut attendre la séance de questions pour apprendre qu’il est prévu que le plugin Maven pour Android utilise ce nouveau format. D’ailleurs certaines librairies comme ActionBarSherlock prévoit déjà de le supporter.

Google Play Services

Location APIs

C’est au cours de la keynote que les nouveaux services intégrés dans le projet Google Play Services ont été présentés. Tout d’abord trois nouvelles API de localisation font leur apparition :

Fused Location Provider : API de haut niveau permettant de s’abstraire des location providers (GPS, WI-FI) pour récupérer les informations de géolocalisation adaptées au besoin,
Activity Recognition : API capable de déterminer l’activité de l’utilisateur (en voiture, à vélo …) afin de permettre aux applications de s’adapter au contexte d’utilisation en améliorant ainsi l’expérience utilisateur,
Geofencing : offre la possibilité de déclencher des triggers quand un utilisateur entre ou sort de zones géographiques précises.

Avec ces nouvelles API, le développement d’application dont le contenu nécessite de s’adapter au contexte d’utilisation devrait être simplifié. Elles ont aussi pour but de réduire la consommation de batterie liée à la récupération d’informations de géolocalisation.

Game Services

Il s’agit d’un ensemble de fonctionnalités qui permettent de rendre les jeux plus attractifs auprès des utilisateurs. Il est maintenant possible de mettre en place des récompenses ou des leaderboards afin de fidéliser le joueur. Afin d’améliorer l’expérience cross-device, l’avancement d’un jeu peut maintenant être sauvé dans le cloud afin de pouvoir reprendre sa partie, et ce, peu importe le device utilisé. Pour finir, le développement d’applications multi-joueurs en temps réel est facilité avec ces nouvelles APIs.

Google Cloud Messaging

Il fait maintenant partie intégrante du projet Google Play Services et se voit doté de nouvelles fonctionnalités :

upstream : bien qu’abandonné par Hangout le protocole XMPP refait son apparition afin de permettre une communication bi-directionnelle entre le serveur et un device,
seamless multi-device messaging : Google permet de grouper les devices d’un même utilisateur afin d’envoyer de manière uniforme des notifications à un utilisateur. Par exemple si un utilisateur reçoit la notification et traite l’information sur son téléphone il ne l’aura pas en double sur sa tablette par exemple.

Le principal avantage des Google Play Services est qu’ils sont mis à jour au travers du Play store indépendamment de la version de l’OS (jusqu’à la 2.2). Par contre les émulateurs actuels ne permettent pas de les tester nativement, c’est pourquoi une image contenant les play services devrait voir le jour via le SDK Manager. Tous ces Google Play Services seront présentés plus en détails dans un prochain article.

Traduction simplifiée

Google lance un nouveau service professionnel de traduction d’application directement intégré dans la console Play. Il a été présenté plus en détails au cours de la session "Building Android Apps for Global Audience". On y apprend que la tarification se fait au nombre de mots, le prix du mot variant d’une langue à l’autre. De plus l’utilisateur est en mesure de suivre l’état d’avancement de ses traductions. Pour finir le traducteur peut, via un système de commentaires, demander des précisions concernant le contexte d’utilisation d’un mot afin de le traduire au mieux.

Beta testing/Staged rollouts

Dans la nouvelle version de la console Play il est maintenant possible de faire tester une version d’un apk à un ensemble réduit d’utilisateurs. Ces groupes de testeurs peuvent être soit un Google Group soit une Google+ Community. Ces utilisateurs ne pourront pas laisser d’avis publics directement sur Google Play, il faut donc penser à leur fournir un canal de communication spécifique (email, site web…)

En plus du beta testing, il est possible de faire du "staged rollouts". Cela consiste à releaser de manière progressive une nouvelle version d’une application afin de pouvoir contrôler l’évolution de l’avis des utilisateurs vis à vis des nouvelles fonctionnalités mais aussi s’assurer que le nombre de crash n’augmente pas.

Et les autres annonces…

Lors de la session "Best Practices for Bluetooth Development", on apprend qu’il sera possible d’utiliser la technologie Bluetooth Low Energy à partir de la version 18 de l’API sur les devices mettant à disposition cette technologie.

Pour finir la dernière annonce concerne la Google TV qu’il a été possible d’apercevoir fonctionner sous Jelly Bean. Une mise à jour vers la toute dernière version d’Android devrait voir le jour au cours de l’année.

Graphite – les bases

Charles Blonde — Wed, 29 May 2013 13:25:26 +0000

Graphite est un outil pour grapher différentes métriques qui peuvent être aussi bien des indicateurs systèmes (utilisation CPU, espace disque disponible, etc …), des indicateurs applicatifs (utilisation de la heap d’une JVM, requêtes par secondes d’une base de données, etc.) ou des indicateurs métiers exposés en JMX par exemple. Théoriquement, il n’y a pas de limite aux informations qui peuvent être stockées dans Graphite du moment qu’il s’agit de données numériques. Il est très facile de créer ses propres indicateurs.

Si l’installation basique de Graphite est relativement aisée, les choses deviennent un peu plus complexes lorsqu’il s’agit d’optimiser l’installation et de comprendre son comportement interne pour l’adapter à vos besoins.

Dans cet article je parlerai uniquement des mécanismes de Graphite et de son installation dans un environnement mono-serveur. La montée en charge et la haute disponibilité ainsi que les outils s’appuyant sur Graphite feront l’objet d’articles ultérieurs.

Les mécanismes de base

Lors de l’installation initiale de Graphite, on se retrouve vite perdu dans les différents éléments à installer ainsi dans le grand nombre de fichiers de configuration différents. Il est donc important de faire le point sur le mode de fonctionnement interne de Graphite.

Les composants de Graphite

Graphite est une application codée en Python, qui est composé de trois éléments distincts.

Carbon

Il s’agit du ou des processus qui vont être responsables de la collecte des métriques. Le premier qui se nomme Carbon est composé de trois daemons :

carbon-cache.py : Processus qui collecte les données afin de les stocker par la suite. Il écoute par défaut sur les ports 2003 et/ou 2004.
carbon-relay.py : Processus facultatif qui permet à Graphite de répliquer et de répartir les données entre plusieurs carbon-cache.py.
carbon-aggregator.py : Processus facultatif qui permet de bufferiser et d’agréger les données en amont du carbon-cache.py afin de limiter les écritures de données et ainsi réduire les IO qui sont en règle générale le premier facteur limitant.

Dans une installation basique mono-serveur, seul le processus carbon-cache.py est utilisé.

Whisper

Il s’agit de la base de données de type fichier à taille fixe utilisée pour stocker les métriques. Whisper est comparable à RRD (Round Robin Database) et fournit à la fois une bibliothèque Python utilisée par Carbon et des outils en ligne de commande afin de manipuler les fichiers de données.

Graphite Webapp

Comme son nom l’indique, il s’agit de l’application web, écrite en Python et utilisable avec Apache (ou autre serveur HTTP) via le module WSGI.
L’application accède aux données provenant de Whisper et les affiche sous la forme de graphiques et de tableaux de bord.
Une base de données est nécessaire pour stocker uniquement les préférences utilisateurs et la sauvegarde des graphiques et des tableaux de bord. Par défaut, SQLite est utilisée, mais il est possible d’utiliser MySQL. Au vu de la faible volumétrie de données stockées, SQLite répond au besoin pour une installation mono-serveur.

Les protocoles

Plusieurs protocoles sont disponibles pour envoyer des informations vers Graphite.

Texte brut

Il s’agit du protocole standard le plus simple à utiliser. Le port par défaut pour envoyer des données en texte brut est le 2003.
Le format d’un message est le suivant :

Il est très facile d’envoyer des messages dans ce format grâce à nc ou à un programme de quelques lignes de codes : il suffit d’écrire des chaînes de caractères dans une socket.

Pickle

Dans ce protocole utilisant le port 2004 par défaut, l’objectif est de bufferiser les données afin de les envoyer par lot (avec une limite à 500 métriques environ afin d’éviter de dépasser les 1Mo/message).
Pour ce faire, Graphite utilise le mécanisme de “pickle” qui peut être considéré comme la sérialisation interne de Python. Ainsi, il est très délicat d’utiliser ce protocole avec un programme écrit dans un autre langage.
Le format des messages, avant sérialisation, est le suivant :

[(path, (timestamp, value)), ...] avec la taille du message comme entête.

AMQP

AMQP (pour Advanced Message Queuing Protocol, RabbitMQ par exemple) peut également être utilisé comme source de données. Dans ce cas, deux options sont disponibles :

Le nom de la métrique est dans le routing key et le message a le format suivant :
```
 
```
Le nom de la métrique est directement dans le message :
```
  
```

Les métriques

Chaque métrique est stockée dans son propre fichier qui par défaut a une taille fixe : il sera créé et alloué automatiquement lors de la première utilisation. Il est assez facile d’estimer l’occupation totale sur le système de fichiers.

Les métriques sont définies par un “chemin” séparé par des points. Par exemple :

servers..cpu.total.idle
servers..diskspace.root.byte_avail

Le répertoire de stockage des métriques par défaut est /opt/graphite/storage/whisper et l’extension des fichiers utilisée est .wsp.

Installation mono-serveur

Dans cet article, nous allons faire l’installation de Graphite sur Amazon EC2 avec des distributions de type Amazon Linux qui sont basées sur des Red-Hat. Il est facile de faire le même type d’installation sur toute autre distribution où la principale différence résidera dans le nom des packages nécessaires.

Afin de générer du trafic, j’utilise Diamond qui est un outil pour collecter différentes métriques et ayant de nombreux plugins (collector). De base, seules les informations systèmes sont reportées.

Une fois connecté sur le serveur, l’installation à partir des binaires disponibles sur Launchpad est assez rapide. Lors de la rédaction de cet article, la dernière version stable de Graphite est la 0.9.10.

# Installation des packages nécessaires (valable pour Redhat/CentOS/etc...)
sudo yum install django-tagging Django python-zope-interface pycairo python-twisted httpd mod_wsgi --enablerepo=epel

mkdir /tmp/graphite

#Installation de Carbon
cd /tmp/graphite/
wget https://launchpad.net/graphite/0.9/0.9.10/+download/carbon-0.9.10.tar.gz
tar xzf carbon-0.9.10.tar.gz
cd carbon-0.9.10
sudo python setup.py install

# Installation de Whisper
cd /tmp/graphite/
wget https://launchpad.net/graphite/0.9/0.9.10/+download/whisper-0.9.10.tar.gz
tar xzf whisper-0.9.10.tar.gz
cd whisper-0.9.10
sudo python setup.py install

#Installation de la Webapp
cd /tmp/graphite/
wget https://launchpad.net/graphite/0.9/0.9.10/+download/graphite-web-0.9.10.tar.gz
tar xzf graphite-web-0.9.10.tar.gz
cd graphite-web-0.9.10
sudo python setup.py install
#Configuration carbon
cd /opt/graphite/bin
sudo cp /opt/graphite/conf/carbon.conf.example /opt/graphite/conf/carbon.conf
sudo cp /opt/graphite/conf/storage-schemas.conf.example /opt/graphite/conf/storage-schemas.conf

#Lancement de Carbon
sudo ./carbon-cache.py start

#Configuration de la webapp
sudo rm /etc/httpd/conf.d/wsgi.conf
sudo cp /opt/graphite/examples/example-graphite-vhost.conf /etc/httpd/conf.d/vhost-graphite.conf
sudo cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi
sudo cp /opt/graphite/webapp/graphite/local_settings.py.example /opt/graphite/webapp/graphite/local_settings.py
cd /opt/graphite/webapp/graphite

# Configuration de la base de données nécessaire pour la Webapp : sqlite par défaut. 
# Le script va créer la base de données et proposer de créer un compte utilisateur graphite
sudo python manage.py syncdb

# L’utilisateur apache doit pouvoir lire et écrire dans le répertoire de stockage
sudo chown -R apache:apache /opt/graphite/storage/

# Lancement d’Apache
sudo service httpd start

À ce stade, vous avez un processus carbon-cache.py qui écoute sur les ports 2003 et 2004 pour recevoir des métriques et une application web disponible à travers Apache, qui écoute sur le port 80 et accessible via navigateur. Il s’agit cependant de la configuration par défaut qui risque vite de se trouver limitée.

Configuration de Graphite

Si vous laissez fonctionner votre application quelques jours, vous allez rapidement vous rendre compte que la rétention des données par défaut est de 24h. Pour y remédier, il est nécessaire de réaliser quelques ajustements.

Stockage

La gestion du stockage est réalisée dans le fichier storage-schemas.conf et est composé d’un ensemble de bloc du type :

[title]
pattern = 
retentions =

où :

title : Un titre logique
pattern : Il s’agit d’une expression régulière qui va être appliquée à chaque métrique et la première qui correspond sera utilisée. Les blocs sont lus dans l’ordre, du début du fichier jusqu’à la fin.
retentions : la règle de rétention à utiliser qui a la forme suivante
```
timePerPoint:timeToStore, timePerPoint:timeToStore, …
```
avec:
- timePerPoint : la durée d’un point (1sec, 1min, 10 min, 1h , etc …)
- timeToStore : le temps de rétention avec cette précision (1 journée, 1 semaine, etc …)

Quelques exemples

[mongodb]
pattern = ^mongodb\.
retentions = 1s:4h, 1m:6d, 1d:1y

Explications : Toutes les métriques qui commencent par “mongodb” vont être stockées de la façon suivante:

1 point par seconde pendant 4h
1 point par minute pendant 6 jours
1 point par jour pendant 1 an

Taille du fichier par métrique : 275Ko.

[default]
pattern = .*
retentions = 1s:1d, 1m:30d, 1h:1y

Explications : Pour toutes les métriques, stocker les données de la façon suivante :

1 point par seconde pendant un jour
1 point par minute pendant 1 mois
1 point par h pendant un an

Taille du fichier par métrique : 1,6Mo

Vous avez maintenant configuré Graphite avec la précision que vous souhaitez. Relancez le service carbon-cache.py et….rien ! En effet, ce fichier n’est lu que lorsqu’une métrique inconnue est reçue et qu’un nouveau fichier de données doit donc être créé. Les fichiers existants ne seront donc pas modifiés !

Dans ce cas vous avez deux solutions :

Solution de facilité : Vous pouvez vous permettre de perdre les données existantes et il suffit de supprimer le répertoire de stockage (/opt/graphite/storage/whisper/ par défaut). Attention à un autre point cependant : par défaut et afin de limiter l’impact des créations de fichiers, Carbon va limiter le nombre de créations maximums de nouvelles métriques à 50 par minute. Ne vous inquiétez donc pas si certaines métriques n’apparaissent pas immédiatement (le processus-carbon-cache.py se monitor lui-même et il est donc possible de suivre le nombre de créations par minute directement dans Graphite)
Solution avec récupération des données : Whisper vient avec plusieurs outils de visualisation et de manipulation des données qui vont nous permettre de modifier la durée de rétention. Exemple d’utilisation pour une métrique bien précise :
```
sudo whisper-resize.py  1s:4h 1m:6d 1d:1y
```
Il est bien sûr possible de faire des modifications en masse en scriptant un petit peu:
```
find /opt/graphite/storage/whisper/servers/ -name "*.wsp" -exec sudo whisper-resize.py --nobackup {} 1s:4h 1m:6d 1d:1y \;
```

Il est aussi possible d’afficher des informations sur un fichier de métriques afin de connaître la rétention utilisée :

whisper-info.py

Agrégation

L’agrégation se produit lorsque l’on change de zone de précision (eg : passage de 1 point par seconde à 1 point par minute).
Il est possible d’intervenir sur l’agrégation grâce au fichier facultatif storage-aggregation.conf dont le format ressemble à celui storage-schemas.conf. Il est composé de suites de blocs du type :

[title]
pattern = 
xFilesFactor = 
aggregationMethod =

Où :

title: Un titre logique.
pattern: Il s’agit d’une expression régulière qui va être appliquée à chaque métrique et la première qui correspond sera utilisée. Les blocs sont lus dans l’ordre, du début du fichier jusqu’à la fin.
xFilesFactor: Ratio (entre 0 et 1) pour représenter le nombre de points nécessaires du palier précédent pour que la valeur soit non nulle. Cette valeur est utile lorsque le palier précédant n’est pas complet et qu’il manque des données. La valeur par défaut est 0.5.
aggregationMethod: L’opération à appliquer pour agréger les données. La valeur par défaut est average.

Example :

[min]
pattern = .*min$
xFilesFactor = 0.1
aggregationMethod = min

Explications : Lors de l’agrégation, pour que la valeur agrégée soit non nulle, il faut qu’il y ait au moins 10% des valeurs du palier précédant et la valeur minimum sera utilisée.

Comme pour le fichier storage-schemas.conf, la modification de ce fichier sera sans impact sur les métriques déjà créées. Il faut utiliser l’utilitaire whisper-resize.py avec les options –xFilesFactor et –aggregationMethod afin de modifier les options adéquates. À noter qu’il existe aussi l’utilitaire whisper-set-aggregation-method.py qui permet de modifier uniquement l’opération à appliquer sur les valeurs.

Whitelist/blacklist

Il est possible, au niveau du serveur Carbon, de gérer une liste de métriques acceptées ou au contraire rejetées. Bien entendu la configuration idéale est de ne pas envoyer de métriques inutiles, toutefois, il est parfois pratique de les exclure dans une configuration centralisée.
Afin d’activer la prise en charge des blacklist/whitelist, il faut tout d’abord ajouter une option dans le fichier de configuration carbon.conf :

USE_WHITELIST = true

Ensuite il faut créer les fichiers whitelist.conf et blacklist.conf dans le répertoire de configuration de Carbon (/opt/graphite/conf par défaut). Des fichiers d’exemples sont mis à disposition, il suffit de les renommer :

sudo cp /opt/graphite/conf/whitelist.conf.example /opt/graphite/conf/whitelist.conf
sudo cp /opt/graphite/conf/blacklist.conf.example /opt/graphite/conf/blacklist.conf

La syntaxe de ces deux fichiers est assez simple. Ils consistent en une suite d’expressions régulières Python.
Si vous utilisez Diamond pour envoyer des métriques systèmes et que vous ne souhaitez pas avoir les détails de chaque CPU mais seulement le total, rien de plus simple. Il suffit de rajouter la ligne suivante dans blacklist.conf :

# Remove individual CPU details
^servers\..*\.cpu\.[a-z]+[0-9]+\..*

Ainsi les métriques du type ci-dessous seront ignorées

servers..cpu.cpu[0-9].

Pour que les autres métriques soient acceptées, il faut qu’une ligne acceptant toutes les métriques soit ajoutée dans le fichier whitelist.conf :

#Accept all metrics
\.

Il est fortement recommandé de commenter chaque ligne ajoutée à ces deux fichiers, la lecture des expressions régulières n’est pas forcément des plus aisée.
Un redémarrage du processus carbon-cache.py est nécessaire lorsqu’une option dans le fichier carbon.conf mais les modifications des fichiers whitelist.conf/blacklist.conf sont prises à chaud.
Attention également à ne pas ajouter de lignes vides dans le fichier blacklist.conf ! En effet, une ligne vide sera interprétée comme une expression régulière matchant tout et par conséquence toutes vos métriques seront ignorées !

Le fichier carbon.conf

Le fichier de configuration principal pour le processus carbon-cache.py est le fichier carbon.conf et il est divisé en trois parties distinctes :

[cache]
####
# carbon-cache.py configuration
####
[relay]
####
# carbon-relay.py configuration
####
[aggregator]
####
# carbon-aggregator.py configuration
####

Dans notre installation mono-serveur avec uniquement un seul processus, les parties [relay] et [aggregator] sont tout simplement ignorées.

Le fichier par défaut est par ailleurs très bien auto documenté et permet principalement de définir les protocoles et les ports d’écoutes des différents processus.

Conclusion

Vous avez maintenant une installation Graphite installée et configurée parfaitement. Vous allez ajouter régulièrement de nouvelles métriques à grapher et vos tableaux de bord deviendront de plus en plus critiques: pour un web-commerçant qui suit son activité à la journée, comment se passer du nombre de ventes en temps (quasi) réel comparé à celui de la semaine précédente (si l’activité est très "journalisée") ?

La montée en charge et la haute disponibilité deviendront vite des pré requis indispensables à votre installation. Graphite permet de fonctionner dans un tel environnement, cela fera l’objet d’un second article.

Revue de Presse Xebia

Xebia France — Tue, 28 May 2013 06:00:00 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

Augmentation des évaluations Agiles, bonne ou mauvaise nouvelle ?

http://www.agilex.fr/2013/05/evaluation-agile-bonne-mauvaise-nouvelle/

Où l’on parle de change management, de management agile et la perte des valeurs dans des déploiements en masse de l’agilité.

Visual management for having a baby

Par Yannick Quenec'hdu

Une approche amusante du management visuel. Xavier Quesada Allue, futur papa, se lance dans un management visuel pour coordonner la venue de son futur bébé.

http://www.xqa.com.ar/visualmanagement/2010/09/visual-management-for-having-a-baby/

Arrêtez d’estimer, commencez à livrer

http://pragprog.com/magazines/2013-02/estimation-is-evil

« Arrêtez d’estimer, commencez à livrer »: derrière cette phrase provocatrice se cache un vrai problème: le besoin classique des managers de prévoir les releases d’un projet mais aussi l’impossibilité de prévoir avec justesse aussi bien le besoin que le temps nécessaire pour en réaliser le développement. Cet article de Ron Jeffries, un des signataires du Manifeste Agile, revient sur ce problème de l’estimation et en général de prévoir le futur surtout que ces prévisions sont souvent effectuées au début du développement d’un projet quand l’équipe a le moins de connaissance sur celui-ci.

Web

AngularJS : Monochromatic-rainbow et triangle-squarification

Par Bastien Caudan

L’équipe d’AngularJS a annoncé jeudi dernier deux nouvelles versions de leur framework : 1.0.7 (monochromatic-rainbow) et 1.1.5 (triangle-squarification).

La mise à jour de la branche stable (1.0.7) apporte son lot de corrections de bugs et d’améliorations de la documentation.

La nouvelle version de la branche instable (1.1.5) quant à elle, enrichit le framework de nouvelles fonctionnalités. Les améliorations concernent principalement les animations avec notamment la possibilité de déclencher une animation sur l’événement de son choix ou encore la désactivation des animations de manière globale. On peut noter qu’il est maintenant possible d’utiliser les opérateurs ternaires dans les expressions et qu’une directive ngIf a été introduite pour insérer ou retirer un élément du DOM, contrairement au ngShow qui ne fait que changer la visibilité.

Une amélioration importante est le nommage des controllers via la syntaxe :

ng-controller="MyController as my"

Un controller nommé est ajouté au scope ce qui permet d’accéder directement à ses propriétés et à ses méthodes. Une vidéo illustrant cette fonctionnalité est déjà disponible sur egghead.io.

Polymer et Web components, le futur des frameworks UI Web ?

http://www.2ality.com/2013/05/google-polymer.html

Lors de son récent évènement I/O 2013, Google a présenté une nouvelle interface utilisateur web nommée Polymer. Non ce n’est pas un nouveau framework MVC javascript, donc vous pouvez rester. Polymer a pour but de promouvoir les composants Web (composés entre autre du Shadow DOM sur lequel se base Angular ou encore des imports HTML). Pour résumer, Polymer a pour but de mettre en avant les futurs standards HTML 5 en particulier sur la partie interface utilisateur. Enfin, bonne nouvelle, les deux frameworks majeurs que sont Ember.js et Angular.js ont annoncé qu’ils tireront parti de ces composants Web.

Vous trouverez plus d’infos sur ces deux articles:

http://www.2ality.com/2013/05/web-components-angular-ember.html

Comprendre le fonctionnement de la JVM – Article 1/2

Pierre Laporte — Mon, 27 May 2013 08:33:57 +0000

Origines

Depuis 1996, Java et la JVM ont envahi nos équipements pour devenir des éléments incontournables de notre quotidien. Avant de s’intéresser aux détails et aux forces de la JVM, il est important de comprendre la relation entre le langage Java et cette dernière.

Au démarrage, Java se voulait un langage multi-plateformes, principalement guidé par le principe WORA : "Write Once, Run Anywhere". La JVM ne comportait qu’un nombre limité d’optimisations par rapport à aujourd’hui, et Java était critiqué à raison pour sa lenteur. C’est en 2000 que le langage a bénéficié d’un second souffle avec l’intégration de Hotspot dans la JVM 1.3.

La technologie Hotspot, quant à elle, est motivée par une toute autre problématique : concevoir une technologie qui maintienne l’aspect multi-plateformes de Java tout en profitant des optimisations de chaque machine (type de CPU, architecture matérielle).

Java est le langage dans lequel nous développons nos applications, Hotspot est le support par lequel nos applications sont de plus en plus optimisées à chaque nouvelle version de la JVM.

Concepts majeurs

Chaque application Java est constituée de fichiers source (.java) qui sont compilés en bytecode. Ce bytecode est ensuite utilisé par la JVM et transformé en code natif.

Grace à cette séparation entre le langage et la plateforme d’exécution, nous tirons aujourd’hui de nombreux bénéfices : les applications Java sont de plus en plus optimisées sans avoir à être recompilées, d’anciens langages ont été portés sur la JVM pour pouvoir profiter de ces mêmes optimisations (Jython, JRuby) et de nouveaux langages ont émergé pour combler les lacunes de Java (Clojure, Scala).

La JVM s’occupe de la gestion de la mémoire en segmentant la heap en plusieurs sections : la "Young Generation" est l’espace dans lequel tous les objets sont crées; la "Old Generation", quant à elle, contient les objets ayant une longue durée de vie. Il existe deux autres zones mémoire que sont la "Permanent Generation" qui contient la définition des classes de l’application et le "Code Cache" qui est l’espace dans lequel la JVM stocke et manipule le code optimisé.

Tout au long de l’exécution d’une application, la JVM maintient des compteurs qui lui permettent de détecter le code souvent exécuté. C’est sur ce code que les optimisations vont être le plus utiles et c’est donc sur celui-ci que la JVM travaille (Just-In-Time Optimisation).

Le cycle d’exécution d’un fragment de code commence donc toujours en mode interprété. Lorsqu’il est détecté par le profiler, il est ensuite passé à l’optimiseur avec des données complémentaires sur son exécution (nombre d’appels, code appelant, …). Une fois que l’optimiseur a appliqué des transformations sur ce code, il stocke le résultat dans le "Code Cache".

Le compilateur javac optimise-t-il le code ?

Pour éviter toute optimisation inutile, le compilateur javac n’effectue presque aucune opération sur le code source Java. Prenons l’exemple d’un "Hello world !" dans lequel on a ajouté du code mort.

public final class NoOptimisation {
    private final static void empty() {}
    private final static void dead() {
        String bar = "Bar";
    }
    public static void main(String... args) throws Exception {
        for(int i=0; i<10_000_000; i++)
            empty();
        System.out.println("Hello world");
    }
}

Si l’on compile cette classe et que l’on analyse le bytecode produit, on constate que la méthode empty() a été compilée en l’état, qu’elle est toujours appelée depuis la méthode main(), et que la méthode dead() et la variable bar sont également présentes dans le bytecode.

$ javap -c -p NoOptimisation
[...]
  private static void empty();
    Code:
       0: return        
[...]
  private static void dead();
    Code:
       0: ldc          #2  // String Bar
       2: astore_0      
       3: return        
[...]
  public static void main(java.lang.String...);
    Code:
[...]
       3: ldc          #6  // int 10000000
       5: if_icmpge    17
       8: invokestatic #4  // Method empty:()V
[...]

Ce comportement est normal : la quasi totalité des optimisations sur le code sont effectuées par Hotspot, durant l’exécution de l’application, si et seulement si le code est souvent utilisé. Dans le cas présent, la méthode dead() ne sera jamais supprimée car elle n’est jamais utilisée, sa suppression serait donc une perte de temps. La boucle d’appels de la méthode empty() sera quant à elle bien supprimée après un certain nombre d’itérations.

Temps de chauffe

Au démarrage d’une application, l’intégralité du bytecode est interprété par la JVM. La JVM entre alors dans une phase de chauffe, durant laquelle elle optimise les fragments de code fréquemment utilisés jusqu’à ce qu’elle atteigne un point d’équilibre permettant à l’application de fonctionner à vitesse maximale.

Pour bien se rendre compte de ce temps de chauffe, on peut exécuter la classe NoOptimisation en mode interprété uniquement (-Xint), en mode mixte (-Xmixed, le mode par défaut) et en mode compilé (-Xcomp) uniquement en comparant les temps d’exécution.

$ time java -client -Xint NoOptimisation
Hello world
real    0m0.201s
user    0m0.190s
sys     0m0.013s
$ time java -client -Xmixed NoOptimisation
Hello world
real    0m0.073s
user    0m0.063s
sys     0m0.017s
$ time java -client -Xcomp NoOptimisation
Hello world
real    0m1.647s
user    0m1.643s
sys     0m0.033s

On voit que le mode interprété est plus long que le mode mixte, ce qui est logique.

Cependant, on remarque aussi que le mode compilé est considérablement plus long que le mode mixte. Ceci est normal : dans ce mode, la moindre méthode invoquée se retrouve compilée, même si elle n’est appelée qu’une seule fois, ce qui est inutile.

Le mode mixte de la JVM est donc le mode qui permet d’obtenir les meilleures performances le plus rapidement possible.

Compilation du code

La JVM peut le compiler les fragments de code "hot" en code natif. Cette compilation se fait alors en utilisant tout le jeu d’instructions du processeur sur lequel l’application s’exécute.

Dans ce cas de figure, le code compilé est stocké dans le Code Cache et tous les pointeurs vers ce code sont réécrits pour référencer la version optimisée. S’il s’agit d’une compilation d’un bloc de code particulier dans une méthode, par exemple une boucle, on parle alors de "On Stack Replacement (OSR)", la JVM modifie la pile d’instructions de la méthode pour que le prochain GOTO mène sur le code compilé et non plus sur le code interprété.

On peut voir la JVM à l’oeuvre en activant les logs de compilation (-XX:+PrintCompilation).

$ java -client -XX:+PrintCompilation NoOptimisation
  61  1    NoOptimisation::empty (1 bytes)
  61  1 %  NoOptimisation::main @ 2 (26 bytes)
  71  1 %  NoOptimisation::main @ -2 (26 bytes) made not entrant
[...]

Le format utilisé est le suivant : d’abord, un timestamp indique à quel moment (timestamp) la compilation a eu lieu. Ici, les compilations ont eu lieu à 61ms et 71ms.

Ensuite, un nombre entier indique l’id de compilation associé à l’optimisation. Il existe deux compteurs distincts, le premier pour les compilations de méthodes et le second pour les compilations OSR, c’est pourquoi les deux premières lignes portent le même id.

Le champ suivant est une série de caractères donnant des indications sur la nature de la compilation.

b    La compilation a bloqué l'exécution du programme;
*    La compilation a donné lieu à un wrapper en code natif;
%    La compilation a donné lieu à un OSR;
!    La méthode compilée peut lever des exceptions;
s    La méthode compilée est synchronisée;
n    La méthode est déclarée comme du code natif.

On peut donc lire que la méthode empty() a été compilée à 61ms et qu’elle représente un seul octet de code. On voit également qu’un bloc de la méthode main a été compilé et remplacé à la volée (OSR) à 61ms.

Enfin, la troisième ligne nous indique que la JVM a détecté à 71ms qu’une de ses optimisations a produit un code incorrect. Elle a désoptimisé ce code et est revenue en mode interprété. Le bloc optimisé a été marqué comme not-entrant, ce qui veut dire qu’il ne peut plus être exécuté. Comme il s’agit d’un retour en arrière, la JVM utilise l’id de compilation de l’optimisation annulée. Ceci explique pourquoi la troisième ligne a l’id 1 : elle concerne l’optimisation #1 faite à la ligne 2.

Fusion et remodelage de code

L’une des optimisations effectuées par la JVM consiste à remplacer l’appel d’une méthode par le corps de cette méthode (inlining). Dans notre cas, l’appel de la méthode empty() peut être fusionné dans la méthode main(). Et c’est exactement ce que fait la JVM. On peut s’en rendre compte en affichant les logs d’inlining (-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining).

$ java -client -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining NoOptimisation
  @ 8  NoOptimisation::empty (1 bytes)  inline (hot)
[...]

La méthode empty de la classe NoOptimisation a été fusionnée car la JVM a détecté qu’elle était souvent appelée.

La taille des méthodes est un facteur très impactant pour la fusion de code. Si une méthode dépasse la taille autorisée (-XX:MaxInlineSize=), elle ne sera pas fusionnée dans d’autres blocs de code. À l’opposé, si une méthode est considérée comme triviales, très courtes (-XX:MaxTrivialSize=), elle sera presque immédiatement fusionnée dans le code appelant. Typiquement, les getters et setters sont toujours très rapidement fusionnés.

La fusion de code par la JVM permet de rendre de nouvelles optimisations possibles. Reprenons l’exemple de code présenté par Brian Goetz dans la conférence "Towards A Universal VM" (Devoxx 2009).

public interface Holder {
  T get();
}
public class MyHolder implements Holder {
  private final T content;
  public MyHolder(T someContent) {
    content = someContent;
  }
  @Override public T get() {
    return content;
  }
}
public String getFrom(Holder h) {
  if(h == null)
    throw new IllegalArgumentException("h cannot be null");
  else
    return h.get();
}
public String doSomething() {
  MyHolder holder = new MyHolder<>("Hello World");
  return getFrom(holder);
}

Analysons comment la méthode doSomething() va être optimisée.

Dans un premier temps, la JVM va fusionner le code de la méthode getFrom() dans la méthode doSomething() car la méthode getFrom() est courte. La méthode doSomething va donc devenir :

public String doSomething() {
  MyHolder holder = new MyHolder<>("Hello World");
  if(holder == null)
    throw new IllegalArgumentException("h cannot be null");
  else
    return holder.get();
}

Grace à cette fusion, on constate que la branche if(holder == null) ne pourra jamais être exécutée car la variable holder est toujours initialisée. Cette branche est devenue du code mort, la JVM va donc la supprimer et aboutir au code suivant :

public String doSomething() {
  MyHolder holder = new MyHolder<>("Hello World");
  return holder.get();
}

La méthode getFrom() référençait l’interface Holder, ce qui obligeait la JVM à effectuer l’invocation de la méthode get() à travers l’interface. À présent la JVM sait qu’elle a affaire à un type concret et peut donc remplacer le code de la méthode get() par son contenu, ce qui donne le pseudo-code suivant :

public String doSomething() {
  MyHolder holder = new MyHolder<>("Hello World");
  return holder.content;
}

Enfin, à travers l’analyse avancée du bytecode (Escape Analysis), la JVM va remarquer que la référence someContent est conservée en l’état dans la variable content, que cette dernière est une référence finale et qu’elle n’est jamais modifiée. Elle va donc pouvoir remplacer l’appel au constructeur de MyHolder et arriver au code suivant :

public String doSomething() {
  return "Hello world";
}

Suppression des locks inutiles

La JVM procède aussi à un nettoyage du code synchronisé. Lorsqu’un fragment de code implique une section critique (bloc synchronized) mais qu’il n’est utilisé que par un seul thread, la Hotspot peut modifier la nature du verrou utilisé, voire le supprimer complètement.

public class LockRemoval {
  private static void run(int times) {
    StringBuffer accumulator = new StringBuffer();
    for(int i=0; i
Dans cet exemple se cachent de nombreux locks. En effet, la classe StringBuffer est synchronisée pour pouvoir être partagée entre plusieurs threads. Dans notre cas, c’est inutile et il aurait été préférable d’utiliser la classe StringBuilder qui n’est pas synchronisée.
Si l’on exécute le programme avec l’élimination de locks (-XX:+EliminateLocks), on constate que la JVM a bien supprimé les entrées en section critiques et leurs sorties pour optimiser le programme.
$ java -XX:+EliminateLocks -XX:+PrintEliminateLocks LockRemoval 10000000 8
++++ Eliminated: 623 Unlock
++++ Eliminated: 612 Unlock
++++ Eliminated: 483 Lock
++++ Eliminated: 234 Unlock
++++ Eliminated: 217 Lock
[...]
Note : le paramètre -XX:+PrintEliminateLocks n’est disponible que sur une version de développement d’OpenJDK.
Les deux modes de la JVM
La JVM dispose de deux modes de fonctionnement adaptés à des applications bien différentes.
Le premier mode est le mode "client", aussi nommé "C1". Il est utilisé pour les applications desktop, ayant une faible durée de vie (comptée en heures).  Dans ce mode, la JVM démarre plus rapidement mais n’effectue que peu d’optimisations sur le code et a pour objectif de ne pas utiliser beaucoup de ressources matérielles.
Le mode client est utilisé pour les applications desktop (NetBeans, IntelliJ, SQL Developer, …).
Le deuxième mode est le mode "server", aussi appelé "C2" ou "opto". Il est utilisé sur les serveurs, pour lesquels la durée de vie est bien plus longue (comptée en jours). Dans ce mode, la JVM démarre plus lentement compte tenu des optimisations effectuées pour atteindre le point d’équilibre.  La limitation sur les ressources matérielles du mode client n’existe plus ici : toutes les optimisations possibles sont activées.
Le mode serveur est activé sur tous les serveurs d’applications (Tomcat, Glassfish, JBoss).
Pour aller plus loin : quelques pièges à éviter
Piège 1 : vouloir tout compiler
On pourrait avoir envie de compiler toute une application, puisque, par définition, le code natif est plus rapide que le code interprété. Cependant, c’est une mauvaise idée.
Que ce soit par le paramètre -Xcomp ou le paramètre -XX:CompileThreshold=1, toutes les méthodes seront compilées avant d’être exécutées et même fusionnées. Problème : lorsque le Code Cache est plein, la JVM peut tenter, en dernier recours, d’éliminer du code natif qui n’est plus utile (-XX:+UseCodeCacheFlushing). Si toutefois cette tentative se solde par un échec, la JVM cesse d’optimiser le code. Les threads de compilation sont arrêtés et ne peuvent pas être redémarrés. La JVM fonctionne alors sur ce qu’elle a pu optimiser jusque là.
Piège 2 : forcer des paramètres de la JVM sans certitude
Lorsque l’on fait un tuning de la JVM, il faut s’assurer que ce tuning améliore réellement la situation et pouvoir expliquer ses choix. Il faut donc sans cesse mesurer les performances de son application pour vérifier qu’à chaque nouvelle version, le tuning apporte toujours un gain de performances.
Appliquer un ensemble de paramètres à une JVM sans avoir prouvé leur utilité revient à appliquer des solutions à un problème qui n’est pas diagnostiqué.
Piège 3 : optimiser prématurément son code
On l’a vu, la JVM modifie profondément le code qu’elle exécute. On tombe parfois sur des méthodes rendues illisibles pour des raisons de performance.  Or à chaque nouvelle mise à jour, la JVM se dote d’améliorations qui rendent ces astuces obsolètes, voire nuisibles.
Un bytecode optimisé ne ressemble pas au source Java dont il est issu. Il vaut mieux écrire un code maintenable, éviter les optimisations prématurées et laisser la JVM s’occuper de rendre le code plus véloce.
Conclusion
Lorsque l’on paramètre une JVM, il faut toujours appliquer la règle "Diagnostiquer avant de soigner", c’est à dire prouver l’existence d’un problème et prouver qu’il sera résolu par un paramètrage manuel avant d’appliquer ce dernier. Il faut également vérifier après chaque mise à jour de l’application ou de la JVM que ce paramétrage profite toujours au projet. Au démarrage d’un projet, il est préférable de laisser les réglages par défaut tant que ces derniers n’ont pas montré leurs limites.
La JVM est une plateforme très évoluée qui ne prend des décisions que lorsqu’elles sont justifiées par un contexte d’exécution. À chaque mise à jour, elle devient de plus en plus performante et c’est ce qui en fait une plateforme incontournable aujourd’hui.

Introduction à Lean Startup

Yannick Grenzinger — Thu, 23 May 2013 12:10:00 +0000

Commençons par un constat : 9 produits sur 10 échouent (et souvent la Startup qui porte un de ces produits). C’est en partant de ce bilan qu’Éric Ries publie en septembre 2011 The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses qui devient un succès mondial et un véritable mouvement avec ses conférences et ses nombreux meetups (par exemple Lean Startup France).

L’objectif de Lean Startup, dans la continuité des méthodes Agiles, est de réduire le cycle de développement d’un produit afin de réduire les risques d’échec, de mesurer le progrès et d’obtenir de précieux feedbacks des clients, et cela de manière régulière. De cette façon, les entreprises, en particulier les startups, peuvent concevoir leurs produits ou services pour répondre aux demandes de leur clientèle sans nécessiter un important budget de démarrage ou de coûteux lancements de produits.

Si on se permet la remarque, cette méthode va encore plus loin que les méthodes Agiles comme Scrum et remet en cause les méthodes de réalisation d’un produit traditionnellement présentes dans les entreprises fondées sur des mythes comme :

Nous savons ce que le client veut,
Nous pouvons prédire le futur,
Avancer selon le plan c’est progresser.

À l’instar des préceptes de Lean Management, la philosophie Lean Startup cherche à éliminer les gaspillages et accroître la création de valeur pendant la phase de développement du produit. L’objectif est d’obtenir les meilleures chances de réussite sans nécessiter un important financement, des Business Plan élaborés ou un produit parfait. Eric Ries estime que les retours des clients au cours du développement du produit font partie intégrante du processus Lean Startup, et veille à ne pas investir trop de temps à concevoir des fonctions ou des services que les utilisateurs ne veulent potentiellement pas.

Éric Ries s’est fortement inspiré de l’ouvrage de Donald Reinertsen le « The Principle of Product Development Flow », du »Customer Development » de Steve Blank, des méthodes de Design UX ou encore du monde Agile pour créer une approche de lancement de produits qui repose principalement sur :

la validation des hypothèses
des expérimentations scientifiques,
un apprentissage constant,
des déploiements en production les plus fréquents possible.

Lean Startup est vue comme une méthode d’amélioration continue du produit en trois étapes : construire – mesurer – apprendre

Construire

« Aucun business plan ne survit au premier contact avec le client » – Steve Blank

Tout produit est un ensemble d’hypothèses qu’il va falloir valider de façon qualitative et quantitative sur le terrain. Ces hypothèses, en particulier les plus risquées, doivent être validées par un MVP ou Minimum Viable Product.

Ce MVP est la plus simple version d’un nouveau produit. Il permet à une équipe d’apprendre au maximum, avec une validation des clients et avec le moindre effort. Il y a différents types de MVP (‘magicien d’Oz’, concierge, test papier, pré-vente, Landing Page avec un appel à action, vidéo) mais tous ont pour objectif de recueillir des retours concrets des utilisateurs afin de trouver la meilleure adaptation au marché pour le produit.

Si cette étape en est rendue à un vrai logiciel, il faut utiliser au maximum les techniques de développement modernes en découpant en itérations courtes et efficaces. Cela va du déploiement sur le Cloud, de la mise en place de l’intégration continue jusqu’au déploiement continu en passant bien sûr par les méthodes d’organisation projet Agile telles que Scrum ou Lean Software Management avec les pratiques Kanban.

Mesurer

« Les clients ne s’intéressent pas à vos solutions, ils se soucient de leurs problèmes » – Dave McClure

Dans Lean Startup, la validation des hypothèses se fait de façon scientifique avec des méthodes aussi bien qualitatives que quantitatives. On peut même aller jusqu’à dire qu’il y a une certaine obsession de la mesure !

Les méthodes qualitatives reprennent les outils connus de l’expérience utilisateur tel que l’interview d’utilisateurs. Il s’agit de rencontrer les utilisateurs afin qu’ils utilisent le produit tout en observant leurs réactions ou encore en leur posant des questions.

Les méthodes quantitatives telles que les méthodes de type A/B testing sont encore plus utilisées, associées à des outils d’analyse du trafic et de l’activité comme Google Analytics. Pour créer une mesure qualitative de qualité, il faut aussi choisir les bons indicateurs clés de performance. Cela peut être le taux d’acquisition comme le nombre d’utilisateurs créant un compte sur le site ou encore l’engagement de ceux-ci en faisant le ratio entre le nombre d’utilisateurs actifs par mois et par jours.

Pour donner un exemple très simple, dans le cadre d’un MVP de type Landing Page, on peut créer deux versions du site avec deux propositions de valeur différentes. En utilisant la technique de l’A/B testing et en mesurant le nombre de personnes donnant leur email pour être informé de la sortie du produit, on peut ainsi déterminer quelle solution intéressera le plus les clients potentiels.

Apprendre

« Les startups qui réussissent sont celles qui parviennent à itérer assez de fois avant d’épuiser leurs ressources » – Éric Ries

La construction et la mesure ont un seul véritable objectif : apprendre, apprendre, apprendre ! Il faut alors utiliser au maximum l’usage de feedbacks de la clientèle afin d’adapter davantage ses produits aux besoins spécifiques de ses clients.

Lean Startup permet d’apprendre quels sont les éléments, les fonctionnalités qui apportent de la valeur ou au contraire celles qui créent du gaspillage. Mais pas seulement ! La méthode permet aussi de tester le marketing du produit ou encore son Business Model. Si les indicateurs sont bons, c’est alors le signe qu’il faut persévérer et continuer d’améliorer l’existant. Au contraire, si les indicateurs sont mauvais, il faut alors pivoter.

Le pivot est une nouvelle hypothèse stratégique qui va nécessiter un nouveau MVP. Des pivots à succès permettent de mettre le produit sur le chemin d’un business ayant une croissance durable.

Il y a plusieurs types de pivot par exemple :

Zoom In : ce qui était considéré comme une fonctionnalité d’un produit devient le produit dans son ensemble,
Zoom Out : ce qui était considéré comme le produit dans son ensemble devient une seule fonctionnalité d’un produit plus large,
Customer Segment : on change le type de client qu’on souhaitait adresser originalement,
Customer Need : on réalise que le segment de clients qu’on vise a un problème plus intéressant à résoudre que celui anticipé,
Platform : on change d’une application à un service ou inversement,
Value Capture : on change la façon dont on capture la valeur, c’est-à-dire le modèle de revenu,
Channel : on change la façon dont on délivre le service au client,
Technologique : Tout en conservant la solution apportée au client, on va utiliser une technologie complètement différente.

Cependant, il ne faut pas oublier que les expérimentations sont rarement définitives et les résultats de chaque apprentissage doivent être contrebalancés par la vision et le jugement sans mettre la tête dans le sable.

Dans ce premier article, j’espère vous avoir présenté de façon claire la pratique du « Lean Startup » dont tout le monde commence à parler. C’est aussi le début d’une série qui vous présentera plus en détail certains outils de cette méthode, par exemple, le Lean Canvas.

Quelques liens:

http://en.wikipedia.org/wiki/Lean_Startup

Backbone, deux ans après

Yves Amsellem — Wed, 22 May 2013 08:15:01 +0000

Backbone fut une des premières librairies à offrir une structure aux applications JavaScript. Avec le succès qu’on lui connaît — trello, airbnb, linkedin. Cet article se propose de synthétiser l’expérience de deux ans de développements à ses côtés — mauvais jours inclus — d’identifier des bonnes pratiques et d’entrevoir la suite de l’aventure.

Plus simple, tu meurs

Backbone repose sur le pattern observeur de Smalltalk : les modèles stockent les données et émettent des évènements auxquels les vues s’abonnent — modification d’un attribut, réception d’une requête serveur, erreur de validation, etc. Les vues s’abonnent également aux évènements de l’interface — clic, saisie, etc. Les vues sont orchestrées par un routeur : abonné aux changements d’URL, il sélectionne quelles vues afficher.

Backbone canalise la puissance des deux célèbres librairies $ et _, auxquelles il ajoute peu, en définitive (une liste d’évènements et une interface restful). Avec jQuery, il s’entoure d’une myriade de plugins, et, comme il ne présuppose pas de la façon dont il sera utilisé, peut en intégrer de nombreuses autres aussi facilement — templating, charts, amd, etc.

De nombreux mécanismes concourent à rendre ses accès rest transparents : model.save crée l’objet s’il n’existe pas côté serveur, ou le met à jour sinon, model.fetch et model.destroy parlent d’eux-mêmes, model.url indique l’adresse de la ressource serveur, model.parse manipule la réponse serveur lorsqu’elle n’est pas similaire à l’objet souhaité, etc (en interne, les appels serveur sont effectués avec jQuery).

Cette approche minimaliste permet un debug très rapide : identifier la template concernée puis la vue qui la manipule et l’URL serveur de son modèle, vous y êtes presque. Les erreurs sont explicites, les responsabilités faciles à déceler. Il est extrêmement rare de se retrouver à éplucher le code source de Backbone pour essayer de démêler une situation étrange.

Simpliste, peut-être

Backbone n’est pas exempt de défauts. Le premier d’entre eux est le caractère rudimentaire du routeur. Ce dernier associe URLs et méthodes sans offrir de filtre d’accès global sur celles-ci. Ainsi, chacune des méthodes doit dupliquer le code de vérification si leur affichage dépend des droits de l’utilisateur. Il faudra avoir recours à une extension Backbone pour bénéficier de cette fonctionnalité.

Le deuxième problème que l’on peut rencontrer est la gestion manuelle de l’imbrication de modèles. Lorsque Backbone récupère des données du serveur, il les enrobe dans un modèle (ou une collection s’il s’agit d’une liste). Cependant, cet enrobage n’est pas récursif : seul le premier niveau se voit allouer un objet et seulement lui lèvera des évènements. Les raisons de ce fonctionnement sont détaillées dans la documentation et, ici aussi, des extensions Backbone sont disponibles (de notre côté, nous avons utilisé Associations).

Une autre source d’ennui est le manque de précision de certains évènements. Par exemple, l’ensemble des accès serveur — get, put, post, delete — se soldent par un évènement sync en cas de succès, sans indiquer de quel appel http il s’est agi. Cette information est rarement nécessaire, il faut l’avouer, mais quand c’est le cas, il faut alors surcharger la méthode sync du modèle en question (nous verrons comment un peu plus bas).

Backbone est un cadre de travail ouvert : de nombreux choix sont laissés à la discrétion du développeur. Des librairies comme Marionette ou Chaplin s’appuient sur Backbone et offrent une opinion plus appuyée côté client. Rendr, développé pour airbnb, offre même une intégration côté serveur.

Bonnes pratiques

Il existe bien des manières de construire des applications Backbone ; la librairie, elle, n’en préconise pas de particulière. Ceci dit, certaines idées ont fleuri au fur et à mesure.

Lorsqu’une vue manipule une collection (une liste de modèles) et qu’elle désire offrir des actions individuelles sur chaque modèle, il est plus simple de créer une sous vue par modèle et de lui confier la gestion des actions de son modèle. Plusieurs autres librairies — Ember et Angular, par exemple — utilisent de nombreux data-attributes dans le DOM pour ces cas de figure, là où Backbone peut s’en passer complètement.

Lorsqu’une vue doit être ajoutée au DOM, il est plus efficace qu’elle le soit par la vue (ou le routeur) qui l’a instanciée. En d’autres termes, une vue gagne à ne pas indiquer d’attribut el (le nœud du DOM auquel elle est liée — qu’il soit présent dans la page ou non). Ainsi, elle n’a pas comme prérequis la présence d’un élément dans le DOM. Cet élément est couramment présent dans le template de la vue parente : cette dernière est donc la mieux à même d’ajouter ses filles aux nœuds adéquats — se référer à l’exemple d’une liste ajoutant ses items dans son contenu (elle peut également le faire dans un sous sélecteur).

Les vues sans attribut el présentent un second avantage : puisqu’elles n’ont pas de nœud auquel s’attacher, elles se voient affecter un div — configurable — sur lequel est positionné les écouteurs d’évènements. Lorsque la vue n’est plus nécessaire, et que son nœud est détruit, ses écouteurs d’évènements le sont alors aussi. En revanche, si la vue est rattachée à un attribut el existant, ce dernier est potentiellement nécessaire à d’autres vues, il ne peut pas être détruit : le nettoyage de la vue est alors plus délicat.

Lorsqu’une vue est retirée du DOM, elle doit être supprimée de la mémoire. Cependant, tant qu’un objet a des références vers d’autres, le Garbage Collector JavaScript ne peut le supprimer. Elle devient ce qu’on appelle alors une vue fantôme ; elle continue à avoir un effet sur l’application : une case à cocher effectuant deux fois son action habituelle, par exemple. Une discussion animée sur ce sujet est en cours pour les futures versions de Backbone. En attendant, une pratique couramment retenue consiste à ajouter une méthode close aux vues, souvent déclenchée par le routeur lors de la navigation d’une vue vers une autre (et en cascade pour les vues filles).

Lorsqu’il devient nécessaire de surcharger Backbone, plusieurs choses sont à prendre en compte. La plus importante, imputable au langage JavaScript, est l’absence de mot clé super, qui contraint à l’utilisation du prototype de la classe à surcharger (comme expliqué dans l’aparté sur super de la documentation). À noter également : la méthode extend — issue d’Underscore — remplace les références d’attributs au lieu de les étendre. Ainsi, une classe fille définissant l’attribut events n’héritera pas de ceux de sa classe mère (si celle-ci en définit). En revanche, si seule la classe mère définit des évènements, ceux-ci sont bien hérités par la fille.

Lorsqu’une information de l’interface utilisateur n’est reliée à aucune donnée côté serveur, il est tout de même pertinent de s’appuyer sur un modèle — sans url, donc — auquel la vue peut apporter des modifications et s’abonner. Une convention de nommage est une bonne idée dans ce cas de figure. Par exemple, le tri d’une collection dans un tableau sur chaque attribut peut reposer sur un modèle, au lieu d’utiliser des variables dans la vue.

Lorsqu’une closure est utilisée dans une méthode d’une vue, le this de cette closure n’est pas la vue elle-même. Underscore propose des méthodes bind et bindAll pour parer ces cas de figure. À utiliser avec modération — pour des raisons de performances — ces méthodes peuvent souvent être remplacées par un simple self = this.

Lorsque la méthode toJSON tend à être modifiée pour le templating, la création d’une autre méthode est recommandée. En effet, toJSON est utilisée également par Backbone pour l’envoi des modèles au serveur. Utiliser des mixins/helpers dans les templates est aussi une piste intéressante.

Lorsqu’une gestion centralisée des erreurs serveur est souhaitée, la surcharge de la méthode sync commune à tous les composants est possible.

Idées reçues

Une des idées les plus discutées du moment est le manque de productivité de Backbone vis-à-vis de ses compétiteurs Angular ou Ember. Pour des applications basiques, c’est évident. Mais, dès qu’une application est élaborée, la différence est beaucoup plus ténue : l’intégration naturelle de Backbone avec jQuery et ses dérivés lui ouvre la quasi intégralité des librairies créées ces dix dernières années sur le web. C’est là où réside la force de la simplicité de Backbone : il propose de ne pas réinventer la roue, plutôt de pousser un cran plus loin la manière dont les applications web ont été construites jusque-là.

Pour l’avoir utilisé depuis sa version 0.3.3, Backbone s’est raffiné agréablement, profitant des améliorations d’Underscore, peaufinant sa gestion d’évènements, sans devenir compliqué : au contraire, ces améliorations l’on rendu plus cohérent encore. Et migrer d’une version à une autre n’a jamais été très difficile.

Backbone 1.0 est daté du 20 mars. Si l’on se rapporte aux issues actuelles, certaines choses mineures restent à traiter, et il semble qu’une gestion des vues imbriquées soit en discussion, avec à la clé le détail des opérations laissées à la discrétion des développeurs. Difficile aujourd’hui de prédire si Backbone se dotera d’opinions plus prononcées sur la création d’applications web ; il semble que sa popularité en dépende. La simplicité de l’ensemble et sa grande adaptation à tous les cadres en font une librairie d’une excellente qualité. La liste pléthorique d’applications réelles en tirant partie, sa popularité sur Github, soulignent à nouveau, l’élégance et la pertinence de cette modeste librairie aux 4 classes.

Revue de Presse Xebia

Xebia France — Tue, 21 May 2013 12:00:08 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

Lean Startup suck here are 10 reasons

http://nanodome.wordpress.com/2011/10/05/lean-startups-suck-here-are-10-reasons-why/

Un article pas vraiment Lean startup correct, mais il faut toujours tenir compte des contres arguments. Même si dans ce cas, c’est parfois un peu « too much »…

Predict project failure using cumulative flow diagrams

http://www.kanbanway.com/predict-project-failure-using-cumulative-flow-diagrams

Cet article, du blog « Project Management – The Kanban way« , décrit les apports du diagramme de flux cumulé sur la mesure de la prédictibilité, dans une démarche de gestion de projet Kanban.

Agile is not Democracy

http://businesscraftsmanship.tumblr.com/post/50495117127/agile-is-not-democracy

L’objectif des jeux et des votes utilisés en coaching n’est peut être pas compris de tous.

Le coin de la technique

Go passe en version 1.1

http://pcottle.github.io/learnGitBranching/

Go, le langage de Google, passe en version 1.1. Déjà réputé pour, il gagne encore en performance avec cette mise à jour. Pour ceux qui ne connaitrait pas Go, c’est un langage compilé et fortement typé qui se veut proche de la programmation système (et qui veut donc concurrencer C/C++). Son gros avantage étant la facilité avec laquelle on peut exécuter du code en parallèle avec les goroutines. Et pour finir pourquoi GO ? quelques réponses ici.

Apprenez Git graphiquement

Par Florent Le Gall

Vous utilisez Git ou envisagez d’y passer bientôt ? Vous souhaitez apprendre à utiliser ses fonctionalités avancées : branches / merge / rebase / cherry-pick ?

Cette application web permet de saisir des commandes Git et de voir le résultat immédiatement dans un graphe. L’application propose aussi des exercices à résoudre de plusieurs niveaux de difficulté.

Reactor : création d’application asynchrone pour la JVM

L’annonce sur le blog de Spring

Basé sur le pattern éponyme (http://en.wikipedia.org/wiki/Reactor_pattern), Spring partage avec la communauté son framework Reactor. Celui-ci, comparable dans les objectifs à Vert.x, permet de créer des applications hautement performante et facilement scalable.

L’architecture de Reactor se compose de trois briques de bases :

Consumer
Selector
Event

Les Consumer s’occupe d’un traitement métier, et sont enregistrés auprès du framework. L’application envoie des events au framework, et le selector s’occupe de dispatcher les events au bon Consumer.

Le framework Reactor sera notamment intégré dans la version 2.3 de grails afin de proposer nativement une api de gestion des événements. Pour plus d’information sur ce nouveau projet de Spring :

Le github du projet

Xebia et les Duchess vous invitent à prendre le café

Mathieu Breton — Tue, 21 May 2013 06:00:00 +0000

Le 27 mai prochain, Xebia héberge avec joie une nouvelle soirée Les Mains dans le Code des Duchess France sur CoffeeScript.

Vous trouvez JavaScript trop verbeux ? Vous aimez les classes ? Vous êtes un fonctional hipster ? CoffeeScript peut vous intéresser !

Le but de ce Hands-On est de vous apprendre CoffeeScript, un langage compilant vers JavaScript, dont la syntaxe s’inspire de Ruby et Python.

Cette session débutera par la démonstration de l’implémentation d’un champ de mine en TDD en 20 min top chrono. Ensuite, vous attaquerez le coeur du sujet en fabriquant une partie d’un Space Invaders en CoffeeScript. Cet atelier sera animé par Benoît Lemoine, Jean-Laurent de Morlhon et Mathieu Breton.

Pour s’inscrire, c’est ici.

Lieu : Xebia
156 Boulevard Haussmann
Batiment A, 7ième étage

UITableView + API GitHub + CocoaPods = Keep it Simple, keep it Stupid!

Alexis Kinsella — Mon, 20 May 2013 12:00:00 +0000

Nous avons vu dans un article précédent comment utiliser RestKit pour se faciliter la vie lorsque nous travaillons avec des services web exploitant le format JSON. Toutefois, l’utilisation d’un framework fullstack peut se révéler contraignant dès lors que l’on sort du cadre pour lequel il a été destiné. Malheureusement, cela arrive souvent assez rapidement.

Nous verrons dans cet article comment reproduire une application similaire à celle construite grâce à RestKit, sans pour autant abandonner l’idée de gagner du temps grâce à l’utilisation de quelques librairies bien choisies :

Le monde iOS, comme tout environnement mature, dispose de nombreuses librairies Open Source intégrables dans vos projets via l’utilisation d’un Dependency Manager. Dans notre cas, nous utiliserons CocoaPods déjà présenté dans un article précédent.

La création de ce tutoriel fait suite à une présentation en XKE d’une session d’1h30 d’introduction aux développements iOS. Ce tutoriel est donc réalisable en un temps raisonnable en suivant les instructions ci-dessous.

Création du projet

Avant d’utiliser CocoaPods, vous devrez créer un projet de type Empty Application pour iOS via XCode:

Vous aurez ensuite à créer un fichier Podfile à la racine de votre projet XCode avec les dépendances suivantes:

platform :ios, '5.0'
pod 'JSONKit', '1.5pre'
pod 'Underscore.m', '0.2.0'
pod 'AFNetworking', '1.1'
pod 'MBProgressHUD', '0.6'
pod 'SVPullToRefresh', '0.4'
pod 'SDURLCache', '1.2'
pod 'AFHTTPRequestOperationLogger', '0.10.0'
pod 'DCKeyValueObjectMapping', '1.3'

Puis, vous devrez exécuter la commande suivante pour générer le workspace et intégrer le code des dépendances:

pod install

Il faudra alors relancer votre projet en ouvrant le fichier *.XCodeWorkspace, plutôt que le fichier *.XCodeProject. Vous serez alors prêt à développer votre application.

Création du StoryBoard

Nous avons choisi de créer une application vide. Il nous faut donc créer un StoryBoard qui contiendra les différentes vues que nous aurons à créer. Pour cela, nous allons nous rendre dans le menu: File > New > File… et sélectionner StoryBoard dans la section iOS > User Interface. Vous pourrez, par exemple, nommer le fichier: UITableViewTutorial.storyboard

Une fois le storyboard créé, il est nécessaire de l’associer en tant que storyboard par défaut afin qu’il soit utilisé au lancement de l’application. Cela peut être réalisé via l’onglet de configuration Target Summary de la target par défaut, ici UITableViewTutorial.

Création d’un UITableViewController

Nous souhaitons afficher un listing de données, un table view controller correspond donc à notre besoin. Nous devons créer un table view controller dans le storyboard de l’application et l’assigner comme vue de démarrage de l’application. Afin de faciliter la navigation, nous souhaitons également créer un navigation controller.

XCode facilite la création de ces deux view controllers en faisant glisser depuis l’explorateur d’objets un élément de type: Navigation Controller sur le storyboard. Cela aura pour effet de créer automatiquement le navigation controller, le table view controller ainsi que la liaison de navigation entre les deux view controllers.

Lorsqu’un projet a été créé sans storyboard avec un template de type Empty Application, il est nécessaire de modifier le code d’initialisation de l’application et de supprimer le code inutile généré. La méthode de démarrage de l’application application:didFinishLaunchingWithOptions: dans la classe AppDelegate doit retourner tout simplement la valeur YES:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
 return YES;
}

Coloration des barres de navigation

La coloration des barres de navigation peut-être customisée via l’édition des propriétés Status Bar et Top Bar de l’onglet Simulated metrics du navigation controller. Nous choisirons la couleur noir, plus passe-partout que le bleu de l’interface iPhone un peu vieillissant.

Titre de la table view

Le titre de la table view peut être changé via la propriété Title de l’onglet Navigation Item. Nous l’appellerons Repositories.

Style des cellules

Le style de la cellule sera de type Subtitle et correspond donc à un type standard qui peut être configuré via propriété Style de l’onglet Table View Cell du prototype de cellule du tableau.

Identifiant de réutilisation

Afin d’optimiser la performance de ses table views, iOS permet la réutilisation de ses cellules. Pour en bénéficier, un identifiant de cellule réutilisable doit être défini. Nous utiliserons l’identifiant RepositoryCell, configurable via la propriété Identifier de l’onglet Table View Cell.

Association de la table view avec son controller

Nous n’avons pas encore créé de table view controller, nous allons donc le créer via le menu File > New > File … et choisir Objective-C class dans la section iOS > Cocoa Touch. Le controller s’appellera GHRepositoryTableViewController.

Une fois la classe créée, nous pouvons associer la table view avec son controller via la propriété Class de l’onglet Custom Class de la table view. Il doit correspondre au nom de la classe du controller gérant la vue.

Récupération des données

Flux de données

Le service web utilisé sera toujours le service de listing des répositories GitHub d’une organisation donnée.

https://api.github.com/orgs/:organization/repos

Le flux de données correspondant à la liste des repositories de l’organisation FaceBook correspond à la structure suivante:

[
 {
    "default_branch": "master",
    "homepage": "http://three20.info/",
    "html_url": "https://github.com/facebook/three20",
    "owner": {
        "login": "facebook",
        "avatar_url": "https://secure.gravatar.com/avatar/193c1a93276f729041fc875cf2a20773?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-org-420.png",
        "gravatar_id": "193c1a93276f729041fc875cf2a20773",
        "url": "https://api.github.com/users/facebook",
        "id": 69631
    },
    "has_downloads": false,
    "created_at": "2009-02-19T06:31:51Z",
    "watchers": 6961,
    "has_issues": true,
    "description": "Three20 is an Objective-C library for iPhone developers",
    "pushed_at": "2012-10-18T09:30:54Z",
    "forks": 1207,
    "git_url": "git://github.com/facebook/three20.git",
    "ssh_url": "git@github.com:facebook/three20.git",
    "svn_url": "https://github.com/facebook/three20",
    "has_wiki": true,
    "master_branch": "master",
    "clone_url": "https://github.com/facebook/three20.git",
    "size": 4704,
    "forks_count": 1207,
    "fork": false,
    "updated_at": "2012-10-23T19:37:21Z",
    "watchers_count": 6961,
    "name": "three20",
    "open_issues": 252,
    "url": "https://api.github.com/repos/facebook/three20",
    "private": false,
    "id": 132321,
    "language": "Objective-C",
    "mirror_url": null,
    "open_issues_count": 252,
    "full_name": "facebook/three20"
  }
...
]

Modélisation du modèle métier

La modélisation métier proposée dans les tutoriels précédents sera reprise. Nous avons donc une interface et une implémentation correspondant aux classes GHOwner et GHRepository à ajouter.

Définition de la classe GHOwner

Interface

@interface GHOwner : NSObject
@property (nonatomic, strong) NSString *gravatar_id;

@property (nonatomic, strong, readonly) NSURL *avatarImageUrl;

@end

Implémentation

#import "GHOwner.h"
@implementation GHOwner

- (NSURL *)avatarImageUrl {
    NSString *gravatarUrlStr = [NSString stringWithFormat:@"https://secure.gravatar.com/avatar/%@?s=44&d=404", self.gravatar_id];
    return [NSURL URLWithString: gravatarUrlStr];
}

@end

Définition de la classe GHRepository

Interface

#import "GHOwner.h"
@interface GHRepository : NSObject

@property (nonatomic, strong) NSNumber *forks;
@property (nonatomic, strong) NSString *language;
@property (nonatomic, strong) NSString *name;
@property (nonatomic, strong) NSNumber *open_issues;
@property (nonatomic, strong) GHOwner *owner;
@property (nonatomic, strong) NSString *url;
@property (nonatomic, strong) NSNumber *watchers;
@property (nonatomic, strong, readonly) NSString *description_;

@end

Implémentation

#import "GHRepository.h"
@implementation GHRepository

- (NSString *)description_ {
    return [NSString stringWithFormat:@"%@ - %@ Forks - %@ Watchers - %@ Issues", self.language ? self.language : @"No Language", self.forks, self.watchers, self.open_issues];
}

@end

Chargment des données avec AFNetworking

AFNetworking est une librairie HTTP très appréciée pour sa simplicité d’utilisation et son efficacité via l’utilisation des Operation Queues. Nous l’utiliserons pour nous faciliter le travail d’accès aux données du service via HTTP.

Dans la méthode viewDidLoad: du table view controller, nous appellerons une méthode qui aura la responsabilité de charger les données et déclencher le rechargement du composant. Nous appellerons cette méthode loadDataWithCallback.

- (void)loadDataWithCallback:(void(^)())callback {
    AFHTTPClient *httpClient = [AFHTTPClient clientWithBaseURL:[NSURL URLWithString:@"https://api.github.com"]];
    NSURLRequest *urlRequest = [httpClient requestWithMethod:@"GET" path:@"/orgs/facebook/repos" parameters:nil];
    [self showProgressHUDWithMessage:NSLocalizedString(@"Chargement des données", nil) graceTime:0.5];
    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:urlRequest];
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
  ...

        [self.tableView reloadData];
        [self dismissProgressHUD];
  if (callback) {
            callback();
        }
    }
    failure:^(AFHTTPRequestOperation *operation, NSError *error) {
        XBLogWarn(@"Error: %@", error);
        self.dataSource = [NSArray array];
        [self.tableView reloadData];
        [self showErrorProgressHUDWithMessage:NSLocalizedString(@"Erreur de chargement des données !", nil) afterDelay:0.5];
        if (callback) {
            callback();
        }
    }];
    [operation start];
}

Il est nécessaire d’appeler cette méthode au chargement de la vue, dans la méthode viewDidLoad si nous souhaitons que les données soient chargées automatiquement lors du premier affichage de la vue:

- (void)viewDidLoad
{
    [super viewDidLoad];
    [self initProgressHUD];
    [self loadDataWithCallback:^{}];
}

Logging des requêtes / réponses HTTP

Afin de faciliter le travail de déboggage via le traçage des appels HTTP, la micro extension AFHTTPRequestOperationLogger de la librairie AFNetworking a été ajoutée. Elle permet d’afficher les informations relatives aux requêtes effectuées via la librairie.

- (void)setupNetworkingLogger {
    [[AFHTTPRequestOperationLogger sharedLogger] startLogging];
    [[AFHTTPRequestOperationLogger sharedLogger] setLevel:AFLoggerLevelDebug];
}

Cette méthode doit être appelée au démarrage de l’application et son initialisation prend donc place dans la classe AppDelegate:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self setupNetworkingLogger];
    return YES;
}

Ajout d’indicateurs de chargement

Nous souhaitons ajouter un indicateur de chargement qui apparaît lors du requêtage des données, et qui disparaît une fois les données chargées. Un message d’erreur doit être affiché lorsque le chargement des données termine en erreur. Nous utiliserons la librairie MBProgressHUD, qui propose une approche intéressante : l’indicateur de chargement n’apparait que si le temps d’execution de l’opération devient « long ». Si le chargement est suffisamment rapide, l’indicateur n’apparaît pas, et contribue à la fluidité de l’expérience utilisateur

Dans un premier temps, le code suivant doit être ajouté au table view controller:

#pragma mark - Progress HUD

- (void)initProgressHUD {
 self.progressHUD = [[MBProgressHUD alloc] initWithView:self.navigationController.view];
}

- (void)showProgressHUDWithMessage:(NSString *)message graceTime:(float)graceTime {
 self.progressHUD.mode = MBProgressHUDModeIndeterminate;
 self.progressHUD.labelText = NSLocalizedString(message, message);
 self.progressHUD.graceTime = graceTime;
 self.progressHUD.taskInProgress = YES;
 [self.navigationController.view addSubview:self.progressHUD];
 [self.progressHUD show:YES];
}

- (void)showErrorProgressHUDWithMessage:(NSString *)errorMessage afterDelay:(float)delay {
 self.progressHUD.mode = MBProgressHUDModeText;
 self.progressHUD.labelText = errorMessage;
 [self.progressHUD hide:YES afterDelay:delay];
 self.progressHUD.taskInProgress = NO;
 [self.navigationController.view addSubview:self.progressHUD];
}

- (void)dismissProgressHUD {
 self.progressHUD.taskInProgress = NO;
 [self.progressHUD hide:YES];
}

Une variable d’instance doit également être ajoutée dans la déclaration de l’interface privée du table view controller:

@interface GHRepositoryTableViewController ()
@property (nonatomic, strong) MBProgressHUD *progressHUD;
@end

Puis le composant MBProgressHUD doit être initialisé dans la méthode viewDidLoad du controller.

- (void)viewDidLoad
{
    [super viewDidLoad];
    [self initProgressHUD];
}

Mapping du JSON avec le modèle de données

Pour convertir les données reçues au format JSON, nous utiliserons 2 librairies. La première, JSONKit, est reconnue pour sa stabilité et ses performances. Elle permet de convertir une structure de données JSON vers une représentation de données au format NSDictionary / NSArray. Dans un second temps ce format intermédiaire pourra être converti vers notre modèle de données grâce à la librairie DCKeyValueObjectMapping.

- (void)buildDataSourceFromResponseData:(id)responseObject {
    NSString *jsonString = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
    NSArray *json = [jsonString objectFromJSONString];
    DCParserConfiguration *parserConfiguration = [DCParserConfiguration configuration];
    parserConfiguration.datePattern = @"yyyy-MM-dd'T'HH:mm:ss'Z'";
    DCKeyValueObjectMapping *parser = [DCKeyValueObjectMapping mapperForClass: GHRepository.class andConfiguration:parserConfiguration];
    self.dataSource = [parser parseArray:json];
}

Le code de chargement devient donc:

- (void)loadDataWithCallback:(void(^)())callback {
    AFHTTPClient *httpClient = [AFHTTPClient clientWithBaseURL:[NSURL URLWithString:@"https://api.github.com"]];
    NSURLRequest *urlRequest = [httpClient requestWithMethod:@"GET" path:@"/orgs/facebook/repos" parameters:nil];
    [self showProgressHUDWithMessage:NSLocalizedString(@"Chargement des données", nil) graceTime:0.5];

    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:urlRequest];
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {

        [self buildDataSourceFromResponseData:responseObject];

        [self.tableView reloadData];
        [self dismissProgressHUD];
        if (callback) {
            callback();
        }
    }
    failure:^(AFHTTPRequestOperation *operation, NSError *error) {
        XBLogWarn(@"Error: %@", error);
        self.dataSource = [NSArray array];
        [self.tableView reloadData];
        [self showErrorProgressHUDWithMessage:NSLocalizedString(@"Erreur de chargement des données !", nil) afterDelay:0.5];
        if (callback) {
            callback();
        }
    }];
    [operation start];
}

Il faut également ajouter une property dans l’interface privée de la classe pour stocker le table de résultats. Nous l’appellerons dataSource:

@interface GHRepositoryTableViewController ()
@property (nonatomic, strong) MBProgressHUD *progressHUD;
@property (nonatomic, strong) NSArray *dataSource;
@end

Support du caching de données

La librairie SDURLCache sera utilisée pour fournir un support de cache fichier stockant les réponses HTTP. La librairie s’appuie sur les en-têtes HTTP et le code de retour pour décider si les données de réponse doivent être mises en cache ou non. Cela permet une consultation des données offline si aucune connectivité est disponible lors d’un requêtage ultérieur. Le code d’initialisation est à intégrer à la classe AppDelegate.

- (void)setupUrlCache {
    SDURLCache *URLCache = [[SDURLCache alloc] initWithMemoryCapacity:1024*1024*2
                                                         diskCapacity:1024*1024*20
                                                             diskPath:[SDURLCache defaultCachePath]];
    [NSURLCache setSharedURLCache:URLCache];
}

Il faut également modifier la méthode application:didFinishLaunchingWithOptions: pour appeler la méthode ajoutée:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self setupUrlCache];
    [self setupNetworkingLogger];
    return YES;
}

Configuration du table view controller

Plusieurs méthodes issues du protocole UITableViewDataSource sont à renseigner pour finaliser l’implémentation initiale du table view controller.

numberOfSectionsInTableView:

Cette méthode permet de renseigner le nombre de sections dans la table view. Ici nous n’avons besoin que d’une seule section qui est la section par défaut. Nous pouvons donc retourner la valeur: 1.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
 return 1;
}

tableView:numberOfRowsInSection:

Cette méthode permet d’indiquer combien nous avons de lignes par section. Ici, nous en avons autant qu’il y a de résultats dans les données chargées. Cette valeur correspond donc au nombre de résultats présents dans la variable dataSource:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
 return self.dataSource.count;
}

tableView:cellForRowAtIndexPath:

Cette méthode permet de configurer la cellule correspondant à l’index fourni en paramètre. Nous utilisons ici la notion de reuseIdentifier pour recycler les cellules ayant déjà servi (dans un souci de performance). Il est important de noter que le reuseIdentifier doit être une variable statique, sans quoi le mécanisme de réutilisation de cellule ne fonctionne pas correctement.

En titre de cellule, nous choisirons d’afficher le nom du repository. En detail, nous utiliserons la propriété description_ qui regroupe différentes informations importantes à propos du repository.

Nous choisirons également d’afficher une image sur chaque cellule. Cette image n’est autre que le gravatar de l’auteur du repository. L’identifiant du gravatar est fourni par l’API, tout comme son URL. Cependant, l’URL ne convenant pas à notre besoin, nous décidons de la reconstruire en indiquant que nous souhaitons une image d’une taille de 44 pixels, ainsi qu’une erreur 404 lorsque l’image n’est pas trouvée. Ce dernier point est important car nous voulons pouvoir afficher une image placeholder dans le cas où une image n’a pas encore été chargée (lorsqu’elle n’existe pas ou bien lorsqu’il n’est pas possible de la récupérer faute de connectivité).

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *CellIdentifier = @"RepositoryCell";
    UITableViewCell *repositoryCell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];
    GHRepository *repository = self.dataSource[(NSUInteger) indexPath.row];
    repositoryCell.textLabel.text = repository.name;
    repositoryCell.detailTextLabel.text = repository.description_;
    [repositoryCell.imageView setImageWithURL:repository.owner.avatarImageUrl placeholderImage:self.defaultAvatarImage];
    return repositoryCell;
}

A noter que la méthode setImageWithURL:placeholderImage: est fournie par la librairie AFNetworking et ne fait pas partie de l’API de base iOS.

L’avatar par défaut doit être initialisé au chargement de la vue, il faut donc l’ajouter à la méthode viewDidLoad:

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.defaultAvatarImage = [UIImage imageNamed:@"github"];
    [self initProgressHUD];
    [self loadDataWithCallback:^{}];
}

Nous devons également ajouter une property dans l’interface privée de la classe:

@interface GHRepositoryTableViewController ()
@property (nonatomic, strong) MBProgressHUD *progressHUD;
@property (nonatomic, strong) NSArray *dataSource;
@property (nonatomic, strong) UIImage *defaultAvatarImage;
@end

Fonctionnalités supplémentaires

Ajout du Pull To Refresh

Une fonctionnalité intéressante à ajouter dans les views de type table view est le pull to refresh. La librairie SVPullToRefresh permet de l’ajouter sans être invasive, pour cela il suffit d’implémenter une méthode dans le table view controller:

- (void)setupPullToRefresh {
    __weak typeof(self) weakSelf = self;
    [self.tableView addPullToRefreshWithActionHandler:^{
        [weakSelf loadDataWithCallback:^{
            [weakSelf.tableView.pullToRefreshView stopAnimating];
            [weakSelf.tableView reloadData];
        }];
    }];
}

Il est également nécessaire d’appeler cette méthode au chargement de la vue, dans la méthode viewDidLoad:

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.defaultAvatarImage = [UIImage imageNamed:@"github"];
    [self setupPullToRefresh];
    [self initProgressHUD];
    [self loadDataWithCallback:^{}];
}

Ajout de l’Infinite Scrolling

La fonction d’infinite scrolling fait partie des comportements naturels que l’on s’attend à trouver sur une table view lorsqu’on souhaite afficher des données paginées. Lorsque l’on atteint en scrollant la fin des premiers résultats chargés, les résultats suivants sont chargés automatiquement, permettant de poursuivre le scroll. Encore une fois, la librairie SVPullToRefresh nous vient en secours puisqu’elle en propose une implémentation clean et surtout non invasive.

Tout comme pour l’ajout de la fonction de Pull to Refresh, il est nécessaire d’ajouter un code d’initialisation. Pour cela, nous allons ajouter une méthode setupInfiniteScroll:

- (void)setupInfiniteScroll {
    __weak typeof(self) weakSelf = self;
    [self.tableView addInfiniteScrollingWithActionHandler:^{
        if (weakSelf.nextPageURL) {
            [weakSelf loadDataWithCallback:^{
                [weakSelf.tableView.infiniteScrollingView stopAnimating];
                [weakSelf.tableView reloadData];
            }];
        }
        else {
            [weakSelf.tableView.infiniteScrollingView stopAnimating];
        }
    }];
}

Et modifier encore une fois la méthode viewDidLoad: de notre table view controller pour ajouter son initialisation:

- (void)viewDidLoad {
    [super viewDidLoad];
    self.defaultAvatarImage = [UIImage imageNamed:@"github"];
    [self setupPullToRefresh];
    [self setupInfiniteScroll];
    [self initProgressHUD];
    [self loadDataWithCallback:^{}];
}

Nous devons également ajouter une propriété permettant de stocker l’URL de la page suivante si l’information nous a été renvoyée par les en-têtes:

@interface GHRepositoryTableViewController ()
@property (nonatomic, strong) MBProgressHUD *progressHUD;
@property (nonatomic, strong) NSMutableArray *dataSource;
@property (nonatomic, strong) UIImage *defaultAvatarImage;
@property (nonatomic, strong) NSString *nextPageURL;
@end

La méthode tryFindNextPageUrl: est ajoutée au table view controller afin de permettre d’extraire le lien vers la page de données suivante:

- (void)tryFindNextPageUrl:(NSHTTPURLResponse *)response {
    NSString *linkHeader = response.allHeaderFields[@"Link"];
    if (linkHeader) {
        NSArray *links = [linkHeader componentsSeparatedByString:@","];

        NSString * __block nextPageURL = nil;
        [links enumerateObjectsUsingBlock:^(NSString *link, NSUInteger idx, BOOL *stop) {
            NSArray *linkParts = [link componentsSeparatedByString:@";"];
            NSString *rel = [linkParts[1] componentsSeparatedByString:@"\""][1];
            if ([rel isEqualToString:@"next"]) {
                nextPageURL = [linkParts[0] stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"<>"]];
                *stop = YES;
            }
        }];
        self.nextPageURL = [nextPageURL substringFromIndex:@"https://api.github.com".length];
    }
    else {
        self.nextPageURL = nil;
    }
}

Cette méthode est appelée depuis la méthode loadDataWithCallback: qui est modifiée comme suit:

- (void)loadDataWithCallback:(void(^)())callback {
    AFHTTPClient *httpClient = [AFHTTPClient clientWithBaseURL:[NSURL URLWithString:@"https://api.github.com"]];
    NSString *path = self.nextPageURL ? self.nextPageURL : @"/orgs/facebook/repos";
    NSURLRequest *urlRequest = [httpClient requestWithMethod:@"GET" path:path parameters:nil];
    [self showProgressHUDWithMessage:NSLocalizedString(@"Chargement des données", nil) graceTime:0.5];
    XBLogInfo(@"[GET] Requesting JSON payload at: %@", urlRequest.URL);
    AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:urlRequest];
    [operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
        [self tryFindNextPageUrl: operation.response];
        [self buildDataSourceFromResponseData:responseObject];
        [self.tableView reloadData];
        [self dismissProgressHUD];
        if (callback) {
            callback();
        }
    }
    failure:^(AFHTTPRequestOperation *operation, NSError *error) {
        XBLogWarn(@"Error: %@", error);
        self.dataSource = [NSMutableArray array];
        [self.tableView reloadData];
        [self showErrorProgressHUDWithMessage:NSLocalizedString(@"Erreur de chargement des données !", nil) afterDelay:0.5];
        if (callback) {
            callback();
        }
    }];
    [operation start];
}

La méthode d’initialisation du Pull To Refresh doit également être modifiée pour réinitialiser le dataSource et l’URL de page suivante afin d’assurer un bon fonctionnement lors d’un rechargement des données de la première page de résultat:

- (void)setupPullToRefresh {
    __weak typeof(self) weakSelf = self;
    [self.tableView addPullToRefreshWithActionHandler:^{
        weakSelf.nextPageURL = nil;
        weakSelf.dataSource = nil;
        [weakSelf loadDataWithCallback:^{
            [weakSelf.tableView.pullToRefreshView stopAnimating];
            [weakSelf.tableView reloadData];
        }];
    }];
}

Conclusion

A travers ce tutoriel, nous avons vu comment charger un listing de données depuis une API Web avec un minimum de code en s’appuyant sur différentes librairies du monde Open Source. Ces librairies ont été facilement intégrées au projet à l’aide du Dependency Manager CocoaPods : AFNetworking, JSONKit, DCKeyValueObjectMapping, SDURLCache, SVPullToRefresh

Les librairies tiers Open Source rendent trivial un développement qui était il y a peu de temps autrement plus complexe à mettre en oeuvre. Elles nous offrent presque gratuitement des fonctionnalités avancées telles que le Pull To Refresh, l’Infinite Scrolling ou bien encore la mise en cache des données avec un minimum d’effort.

Le code source de cet article est bien entendu disponible sur GitHub à l’adresse suivante: https://github.com/xebia-france/UITableViewTutorial

Intégration de RestKit avec une UITableView

Alexis Kinsella — Mon, 20 May 2013 10:09:00 +0000

Nous avons découvert dans un précédent article comment utiliser RestKit pour récupérer des structures de données JSON depuis une ressource HTTP et les mapper sur un modèle métier. Nous allons voir dans ce nouvel article comment adapter le code existant pour afficher les résultats dans une UITableView iOS. Pour cela, nous allons continuer à travailler avec les APIs GitHub, et nous fixer pour objectif d’afficher les utilisateurs d’une organisation .

Notes:

La version actuelle de RestKit est la 0.20. Cet article met en oeuvre la version 0.10.

Installation

Dans un premier temps, nous allons créer un projet adapté pour iOS via Xcode. Vous devrez sélectionner dans l’assistant de création de projet une application pour iOS avec un template de type Empty Application.

Dans un second temps, nous allons cibler dans notre fichier de Podfile la plateforme iOS, puis ajouter une dépendance appelée SDWebImage qui sera présentée plus tard:

platform :ios

pod 'JSONKit',                          '1.5pre'
pod 'LibComponentLogging-Core',         '1.2.2'
pod 'LibComponentLogging-NSLog',        '1.0.4'
pod 'Reachability',                     '3.0.0'
pod 'RestKit',                          '0.10.1'
pod 'Underscore.m',                     '0.1.0'
pod 'SDWebImage',                       '2.6'

Les autres dépendances ont été ajoutées lors de notre précédent article. Pour plus d’informations sur l’utlisation de CocoaPods, c’est par ici

Description de l’API GitHub

En complément de l’accès au listing des repositories d’une organisation, nous allons utiliser une seconde ressource de l’API GitHub qui permet de lister les utilisateurs d’une organisation. L’URL est la suivante:

https://api.github.com/orgs/:organization/public_members

Pour une organisation telle que xebia-france, la liste des utilisateurs ressemblera à cela:

[
  {
    "url": "https://api.github.com/users/adutra",
    "login": "adutra",
    "avatar_url": "https://secure.gravatar.com/avatar/e96398d35fcd2cb3df072bcb28c9c917?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-user-420.png",
    "gravatar_id": "e96398d35fcd2cb3df072bcb28c9c917",
    "id": 463876
  },
  {
    "url": "https://api.github.com/users/akinsella",
    "login": "akinsella",
    "avatar_url": "https://secure.gravatar.com/avatar/0b9d9365c299078a5cd97cfb9861de37?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-user-420.png",
    "gravatar_id": "0b9d9365c299078a5cd97cfb9861de37",
    "id": 322456
  },
  {
    "url": "https://api.github.com/users/aurelienmaury",
    "login": "aurelienmaury",
    "avatar_url": "https://secure.gravatar.com/avatar/15706981ae8b52786c1587170bb53da6?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-user-420.png",
    "gravatar_id": "15706981ae8b52786c1587170bb53da6",
    "id": 191001
  },
  ...
]

Le modèle métier

Notre modèle métier ne change pas, vous pouvez le retrouver dans l’article d’introduction à RestKit.

Le point d’entrée d’une application iOS est une classe qui étend la super classe UIRespsonder et qui implémente le protocole UIApplicationDelegate.

Nous allons donc créer une classe appelée AppDelegate. Son interface sera la suivante:

#import 

@interface AppDelegate : UIResponder 

@property (strong, nonatomic) UIWindow *window;

@end

Le point d’entrée réel de l’application est la méthode application:didFinishLaunchingWithOptions: du protocole UIApplicationDelegate. C’est ici que nous ajouterons le code d’initialisation de RestKit:

#import "AppDelegate.h"
#import 
#import "NSDateFormatter+XBAdditions.h"
#import "GHRepository.h"
#import "GHUser.h"

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self initializeLoggers];
    [self initializeRestKit];

    return YES;
}

- (void)initializeLoggers {
    RKLogConfigureByName("RestKit/*", RKLogLevelInfo);
}

-(void)initializeRestKit {
    [self initializeObjectManager];
    [self initializeObjectMapping];
}

- (void)initializeObjectManager {
    RKObjectManager *objectManager = [RKObjectManager managerWithBaseURLString:@"https://api.github.com/"];
    objectManager.client.cachePolicy = RKRequestCachePolicyDefault;
    // RKRequestCachePolicyDefault = RKRequestCachePolicyEtag | RKRequestCachePolicyTimeout
}

- (void)initializeObjectMapping {

    // Github date format: 2012-07-05T09:43:24Z
    // Already available in Restkit default formatters
    [RKObjectMapping addDefaultDateFormatter: [NSDateFormatter initWithDateFormat:@"yyyy-MM-dd'T'HH:mm:ss'Z'"]];

    RKObjectMappingProvider *omp = [RKObjectManager sharedManager].mappingProvider;

    RKObjectMapping *repositoryObjectMapping = [GHRepository mapping];
    [omp addObjectMapping:repositoryObjectMapping];
    [omp setObjectMapping:repositoryObjectMapping forResourcePathPattern:@"/orgs/:organization/repos"];

    RKObjectMapping *userObjectMapping = [GHUser mapping];
    [omp addObjectMapping:userObjectMapping];
    [omp setObjectMapping:userObjectMapping forResourcePathPattern:@"/orgs/:organization/public_members"];
}

@end

Dans la méthode initializeObjectMapping, nous avons déclaré un pattern de chemin de ressource complémentaire: "/orgs/:organization/public_members", qui permet de mapper la liste des utilisateurs sur la classe GHUser du modèle métier.

Création d’un StoryBoard

Depuis iOS 5.0 Apple propose dans Xcode la notion de storyboard. Plutôt que de manipuler isolément des fichiers XIB (Morceaux d’interface graphique), Apple a tenté de fournir un ensemble plus consistant et visuel permettant de manipuler l’ensemble des vues et leurs interactions. Par exemple, le storyboard permet d’accéder à une cartographie des vues applicatives, ou encore des marqueurs visuels représentant les liaisons entre ces vues. Le résultat est plutôt convainquant bien qu’un peu difficile à manipuler si vous n’êtes pas équipé d’un grand écran haute densité.

Dans le contexte de l’application développée, 2 vues de type UITableView seront proposées, l’une listant les utilisateurs d’une organisation Github, l’autre listant les repositories de cette même organisation. Les vues seront accessibles grâce à une UITabBar.

Sur le storyboard, vous pouvez observer deux vues de type Navigation Controller. Ces deux vues ont pour rôle de gérer la navigation dans l’application. Par défaut, elles sont matérialisées par une barre en haut de l’écran qui affiche le titre, un bouton retour sur la gauche permettant de revenir à l’écran précédent, et d’autres actions.

Pour créer un storyboard semblable à celui présenté, vous devez dans un premier temps insérer un TabBar Controller comme suit:

Pour cela, après avoir cliqué sur votre storyboard, vous pouvez faire glisser un objet TabBar Controller depuis le navigateur d’objet de base à droite d’Xcode:

Puis vous devez insérer deux Table View Controllers:

Les deux controllers créés avec le tab bar controller sont inutiles, vous pouvez les supprimer:

Vous devez maintenant relier les Navigation Controller associés aux TableView Controller avec le TabBar Controller. Pour cela vous réalisez un clic droit sur le TabBar Controller, l’écran suivant apparaitra:

Vous cliquerez et tirerez le curseur depuis le symbole plus de la ligne qui indique view controller, jusqu’à chacun des deux Navigation Controller:

Vous obtiendrez le résultat suivant:

Pour chacune des vues, vous devrez affecter un StoryBoard Id qui servira à identifier la vue de façon unique:

Vous pourrez configurer le style de la barre de navigation de votre TableView Controller depuis la combo Top Bar:

Vous pourrez configurer le titre du TableView Controller via l’inspecteur d’attribut en cliquant sur sa barre de navigation:

Vous pourrez alors configurer le controller de chacun des TableView Controller:

Si vous souhaitez customiser les icônes et titres des items du TabBar Controller, vous pourrez le faire depuis l’inspecteur d’attributs comme suit:

Pour terminer, vous devrez marquer le TabBar Controller comme étant la vue initiale du StoryBoard, c’est à dire la vue de démarrage. Pour cela, vous devrez cocher la case Is Initial View Controller de l’inspecteur d’attributs:

Les controller applicatifs

Une fois le StoryBoard configuré, nous pouvons maintenant nous concentrer sur les controller applicatifs. Ceux dédiés à la gestion des vues listant respectivement les utilisateurs et les repositories sont très similaires, nous étudierons donc uniquement l’UITableViewController de la vue listant les repositories.

Nous pourrions choisir de travailler bas niveau et implémenter complètement notre controller, cependant RestKit fournit une classe qui pré-mâche une bonne partie du travail. La classe fournie par RestKit fonctionne par délégation, nous avons donc toujours à étendre la classe UITableView dans l’interface du controller:

#import 

@interface GHRepositoryTableViewController : UITableViewController

@end

Le code de l’interface est plutôt succinct, cependant, il nous renseigne sur le fait que notre implémentation à besoin de mettre en oeuvre le protocole RKTableControllerDelegate qui permet de réagir à différents événements générés par RestKit.

Dans notre implémentation, nous allons commencer par déclarer une classe d’extension. Cela permet de déclarer des propriétés qui ne sont accessibles que par l’implémentation de la classe. Une catégorie ne pourra pas accéder, par exemple, aux données de la classe d’extension:

@interface GHRepositoryTableViewController ()
@property (nonatomic, strong) RKTableController *tableController;
@property (nonatomic, strong) UIImage* defaultAvatarImage;
@end

Une classe d’extension est définie par le nom de la classe qu’elle étend ainsi que des parenthèses vides.
Les propriétés tableController et defaultAvatarImage correspondent à des propriétés privées de l’implémentation du controller.
La propriété tableController représente le controller RestKit auquel nous allons déléguer le traitement de notre classe.

Evénements d’initialisation du controller

#import 
#import 
#import "GHRepository.h"
#import "GHRepositoryTableViewController.h"
#import "SDImageCache.h"
#import "SDWebImageManager.h"
#import "GHRepositoryCell.h"
#import "UIImageView+WebCache.h"
#import "UIColor+XBAdditions.h"
#import "UIScreen+XBAdditions.h"

@interface GHRepositoryTableViewController ()
...
@end

@implementation GHRepositoryTableViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    [self configure];
}

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    [self.tableController loadTableFromResourcePath:@"/orgs/xebia-france/repos"];
}

...

@end

Dans un premier temps, sur l’événement viewDidLoad:, nous allons configurer notre controller. Cette configuration est déléguée à différentes méthodes que nous allons voir par la suite.
Puis, sur l’événement viewWillAppear:, nous allons initialiser la demande de chargement de la la table avec les données JSON renvoyées par la ressource de l’API GitHub. Nous le faisons en appelant la méthode loadTableFromResourcePath du controller RestKit tableController que nous avons au préalable initialisé sur l’événement viewDidLoad.

@implementation GHRepositoryTableViewController

...

- (void)configure {
    self.defaultAvatarImage = [UIImage imageNamed:@"github-gravatar-placeholder"];
    [self configureTableViews];
    [self configureTableController];
}

...

@end

Dans la méthode configure, nous configurons les views gérées par le controller, puis le controller en lui-même.

Configuration des vues

Les vues à initialiser sont la table en elle-même, ainsi que ses sous-vues, en l’occurrence ici, la vue gérant le Pull to refresh:

- (void)configureTableViews {
    [self configureTableView];
    [self configurePullToRefreshTriggerView];
}

- (void)configureTableView {
    self.tableView.backgroundColor = [UIColor colorWithPatternImageName:@"bg_home_pattern"];
    self.tableView.separatorStyle = UITableViewCellSeparatorStyleNone;

    [self.tableView registerNib:[UINib nibWithNibName:@"GHRepositoryCell" bundle:nil] forCellReuseIdentifier:@"GHRepository"];
}

- (void)configurePullToRefreshTriggerView {
    NSBundle *restKitResources = [NSBundle restKitResourcesBundle];
    UIImage *arrowImage = [restKitResources imageWithContentsOfResource:@"blueArrow" withExtension:@"png"];
    [[RKRefreshTriggerView appearance] setTitleFont:[UIFont fontWithName:@"HelveticaNeue-Bold" size:13]];
    [[RKRefreshTriggerView appearance] setLastUpdatedFont:[UIFont fontWithName:@"HelveticaNeue" size:11]];
    [[RKRefreshTriggerView appearance] setArrowImage:arrowImage];
}

La configuration des vues permet principalement de définir les aspects cosmétiques de celles-ci. Néanmoins, la vue de la table est ici associée avec le Nib qui sera utilisé pour customiser le rendu des cellules:

[self.tableView registerNib:[UINib nibWithNibName:@"GHRepositoryCell" bundle:nil] forCellReuseIdentifier:@"GHRepository"];

Cette ligne de code indique que le Nib (Correspondant au fichier du même nom et portant l’extension .xib) sera utilisé pour effectuer le rendu des cellules ayant l’identifiant GHRepository.

Configuration du controller

- (void)configureTableController {
    self.tableController = [[RKObjectManager sharedManager] tableControllerForTableViewController:self];

    self.tableController.delegate = self;

    self.tableController.pullToRefreshEnabled = YES;
    self.tableController.variableHeightRows = YES;

    self.tableController.imageForOffline = [UIImage imageNamed:@"offline.png"];
    self.tableController.imageForError = [UIImage imageNamed:@"error.png"];
    self.tableController.imageForEmpty = [UIImage imageNamed:@"empty.png"];

    [self.tableController mapObjectsWithClass:[GHRepository class] toTableCellsWithMapping:[self createCellMapping]];
}

- (RKTableViewCellMapping *)createCellMapping {
    RKTableViewCellMapping *cellMapping = [RKTableViewCellMapping cellMapping];
    cellMapping.cellClassName = @"GHRepositoryCell";
    cellMapping.reuseIdentifier = @"GHRepository";

    cellMapping.heightOfCellForObjectAtIndexPath = ^ CGFloat(GHRepository *repository, NSIndexPath* indexPath) {
        ...
        return height;
    };

    [cellMapping mapKeyPath:@"name" toAttribute:@"titleLabel.text"];
    [cellMapping mapKeyPath:@"description_" toAttribute:@"descriptionLabel.text"];

    return cellMapping;
}

C’est dans la méthode configureController que nous déclarons le controller RestKit. Celui-ci est initialisé via l’instance partagée de la classe RKObjectManager. Nous déclarons le controller applicatif comme délégué du controller RestKit, ce qui permet à celui-ci de déléguer le traitement de certains événements au controller applicatif.
La méthode configureController permet également de configurer l’activation du mécanisme de Pull to refresh, ainsi que les images associées à différents états de la vue en cas d’erreur ou autre. Nous indiquons également que les cellules de la table auront une hauteur variable, qui sera calculée ou bien définie sur les mapping de cellule que nous verrons plus tard.
Enfin, la méthode configureController définit les mapping à utiliser pour associer les objets de la collection affichée par le controller avec les éléments de la vue. Les cellules sont mappées selon une configuration de type RKTableViewCellMapping. Cette classe définit non seulement les mapping entre les objets de la collection et les éléments de la cellule, mais également le nom de la classe qui sera utilisée pour instancier la cellule et l’identifiant de réutilisation de la cellule.

Calcul de la hauteur de la cellule

La méthode heightOfCellForObjectAtIndexPath implémentée lors de la configuration des mapping de cellule permet de calculer la hauteur d’une ligne. En l’occurrence, la méthode permet de calculer la hauteur de la description compte tenu de contraintes et informations fournies telles que la largeur maximale allouée, la taille de la police utilisée ou bien encore la hauteur prise par les autres éléments de la cellule.

...
#define FONT_SIZE 13.0f
#define CELL_BORDER_WIDTH 88.0f // 320.0f - 232.0f
#define CELL_MIN_HEIGHT 64.0f
#define CELL_BASE_HEIGHT 48.0f
#define CELL_MAX_HEIGHT 1000.0f
...
@implementation GHRepositoryTableViewController
...
- (RKTableViewCellMapping *)createCellMapping {
    RKTableViewCellMapping *cellMapping = [RKTableViewCellMapping cellMapping];
    ...
    cellMapping.heightOfCellForObjectAtIndexPath = ^ CGFloat(GHRepository *repository, NSIndexPath* indexPath) {
        CGRect bounds = [UIScreen getScreenBoundsForCurrentOrientation];
        CGSize constraint = CGSizeMake(bounds.size.width - CELL_BORDER_WIDTH, CELL_MAX_HEIGHT);
        CGSize size = [repository.description_ sizeWithFont:[UIFont systemFontOfSize:FONT_SIZE]
                                          constrainedToSize:constraint
                                              lineBreakMode:UILineBreakModeWordWrap];
        CGFloat height = MAX(CELL_BASE_HEIGHT + size.height, CELL_MIN_HEIGHT);

        return height;
    };
    ...
    return cellMapping;
}
...
@end

Configuration du rendu des cellules

Nous n’avons pas encore terminé, puisque nous devons maintenant configurer le rendu des cellules. Lors de la configuration du controller, nous avons défini des mapping de cellule qui s’appliquent sur un objet représentant la cellule, dont le type est GHRepositoryCell. Nous devons donc créer la classe correspondant au type GHRepositoryCell.

L’interface sera la suivante:

#import 
#import "GHRepositoryCell.h"

@interface GHRepositoryCell : UITableViewCell

@property (nonatomic, strong) IBOutlet UILabel *titleLabel;
@property (nonatomic, strong) IBOutlet UILabel *descriptionLabel;

@end

et l’implémentation :

#import "GHRepositoryCell.h"
#import "QuartzCore/QuartzCore.h"

@implementation GHRepositoryCell

- (void)layoutSubviews {
    [super layoutSubviews];
    self.imageView.frame = CGRectMake(10,9,44,44);
    self.imageView.layer.masksToBounds = YES;
    self.imageView.layer.cornerRadius = 3.0;
}

@end

Nous devons également créer le Nib / Xib correspondant de la cellule ayant le rendu souhaité via l’assistant de création de fichier:

Une fois le fichier *.xib créé, un objet Table View Cell doit être ajouté:

Sa taille doit être configurée avec une largeur de 320 pixels et une hauteur de 44 pixels:

Un label correspondant au titre doit être ajouté. Il sera configuré pour s’adapter à la largeur de l’écran, aura pour coordonnées: [66, 5, 232, 16], une taille de police 13, ainsi qu’un style de retour de ligne de type Word Wrap.

Un label correspondant à la description doit également être ajouté. Il sera configuré pour s’adapter à la largeur de l’écran ainsi qu’à la hauteur de la cellule. Il aura pour coordonnées: [66, 20, 232, 18], une taille de police 13, ainsi qu’un style de retour de ligne de type Word Wrap.

Il faudra ensuite créer les liens entre les IBOutlet de la classe représentant la cellule et les éléments graphiques correspondants du fichier Xib. Pour cela il faut passer l’éditeur en mode splitté avec le code source d’un côté et le fichier Xib de l’autre. Faire un clic droit sur l’encoche dans la goutière sur les lignes correspondant aux définitions de variables typées IBOutlet et tirer un lien vers l’élément graphique du Xib:

Ajout d’un avatar aux cellules

L’ajout d’avatars aux cellules du table view des utilisateurs peut être réalisé facilement grâce à l’extrait de code suivant provenant de la classe GHUserTableViewController:

- (void)tableController:(RKAbstractTableController *)tableController willDisplayCell:(UITableViewCell *)cell forObject:(id)object atIndexPath:(NSIndexPath *)indexPath {
 GHUser *user = object;
 GHUserCell *userCell = (GHUserCell *)cell;
 [userCell.imageView setImageWithURL:[user avatarImageUrl] placeholderImage:self.defaultAvatarImage];
}

Un avatar par défaut doit être chargé dans la méthode viewDidLoad: dans le cas où l’avatar de l’utilisateur ne pourrait être récupéré:

    self.defaultAvatarImage = [UIImage imageNamed:@"github-gravatar-placeholder"] ;

Conclusion

Nous avons vu à travers cet article comment utiliser RestKit dans une application iOS pour récupérer une collection de données et l’afficher dans une vue de type UITableView. RestKit nous a permis de simplifier l’implémentation tout en réduisant fortement le nombre de lignes de code à produire.

Code source

Le code source de l’article est disponible sur le repository GitHub restkit-tutorial-ios.

Xebia à Agile France 2013

Nicolas Jozwiak — Fri, 17 May 2013 12:47:33 +0000

L’édition 2013 d’Agile France, la conférence de référence pour les praticiens agiles, se tiendra les 23 et 24 Mai prochains. Tout comme les années précédentes, cette 8^ième édition se déroulera dans le superbe cadre du Chalet de la Porte Jaune dans le Bois de Vincennes.

Agile France c’est l’occasion de venir partager et essayer de nouvelles choses pendant 2 jours complet et sur 7 salles en parallèle (voir le programme complet à cette adresse).

Cette année encore, Xebia est présent avec 5 sessions :

N’hésitez pas à venir nous rencontrer pour parler d’agilité avec nous!

Le mois du JS chez Xebia

Xebia France — Fri, 17 May 2013 08:50:52 +0000

Le mois de juin, synonyme de beau temps, de longues soirées ensoleillées et du début de l’été doit son nom à Junon, déesse de la maternité, de la fécondité et du mariage. Cette année, le mois de juin sera également le mois du JS chez Xebia.

De plus en plus de code est exécuté coté navigateur et les bases de codes JavaScript deviennent de plus en plus importantes, chaotiques et difficiles à maintenir. C’est pour mettre de l’ordre dans cette jungle que sont apparus les frameworks MVC coté client.

Pendant ce Mois du JS, nous vous invitons à venir découvrir et manipuler les trois grands acteurs de cette mouvance, à savoir :

Ember
Backbone
Angular

Au cours de ces ateliers, vous développerez la même application avec chacun des frameworks de façon à avoir une base de comparaison viable. Chaque atelier sera encadré par des Xebians ayant travaillé sur des projets « de la vraie vie » avec les technologies présentées.

La dernière soirée sera consacrée à une table ronde, animée par Jean Laurent de Morhlon, où nous tenterons de « compiler » les expériences acquises avec ces différents frameworks, pour que, lors de votre prochain projet Web, vous fassiez le meilleur choix technologique.

Alors, êtes-vous prêt pour le grand chelem ? Vous restreindrez-vous à une seule soirée ? Aucune obligation, tous les événements sont, bien-sûr, indépendants.

Comme pour tous les TechEvents Xebia, vous aurez besoin d’amener votre ordinateur portable.

Pour participer, quatre billetteries, une par soirée :

Seconde édition : From User Stories to Acceptance tests avec Gojko Adzic

Xebia France — Thu, 16 May 2013 13:57:36 +0000

Suite au succès rencontré lors de la première formation de Gojko Adzic en février « From User Stories to Acceptance tests », nous avons décidé de renouveler l’expérience les 20 et 21 juin avec une offre promotionnelle (consultez le site).

Cet atelier intensif de 2 jours vous donnera les moyens d’optimiser la communication entre le management et les équipes afin d’assurer la qualité du logiciel dés le départ. Gojko vous apportera les outils indispensables pour concevoir et livrer un logiciel sur mesure au travers d’une gestion du besoin et de pratiques de spécifications et de tests.

Big Data Day le 27 Juin chez Xebia

Xebia France — Wed, 15 May 2013 07:55:07 +0000

La quantité de données créées aujourd’hui par les nouveaux usages du Web est impressionnante. Imaginez : stocker la quantité de données produites en 24 heures revient à équiper chaque être humain sur terre d’une clé USB d’1Go tous les jours ! Ces données sont ensuite de véritables trésors pour les entreprises qui les possèdent et savent les utiliser.

Vos données valent de l’or, il est temps de les exploiter.

Nous vous invitons le 27 Juin 2013 au Big Data Day Paris chez Xebia. Venez découvrir les conseils des grands du Big Data autour d’applications concrètes.

Au programme :

09h30 – 12h50 : Les essentiels du Big Data, Keynote d’ouverture, retour d’expérience de Bouygues Telecom et présentation d’Amazon (sur invitation uniquement).
14h00 – 18h15 : Le Big Data en pratique, des présentations et ateliers par les grands du Big Data et des professionnels.
19h30 – 22h00 : Soirée de clôture.

Retrouvez le programme détaillé sur notre site dédié

Revue de Presse Xebia

Xebia France — Tue, 14 May 2013 08:00:22 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

Scrum-ban, par Corey Lada

http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/07/01/Scrumban

Une traduction de Fabrice Aimetti, de l’article de Corey Lada "Scrum-ban", décrivant toutes les étapes du passage d’un processus Scrum à un flux tiré kanban, dans une démarche Lean.

Comme le dit Fabrice "Ca date de 2008, mais ça n’a pas vieilli. Que du bonheur !". Alors bonne lecture ;).

Booster vos Rétrospectives

Vous voulez changer le format de votre rétrospective ? plans-for-retrospectives.com vous permettra d’en élaborer le plan. Le format est claire et propose, à ce jour, 62 activités qui vous permettons de trouver l’inspiration. De plus les sources sont souvent citées, vous pourrez ainsi approfondir les sujets.

UX et Produit Minimum Viable

Les slides de cette présentation donnée par Anders Ramsay nous présentent rapidement ce qu’est un Produit Minimum Viable et comment est-il lié aux pratiques UX et leur impact. Pour l’auteur, le MVP est le noyau d’une pratique Agile / Lean efficace et il fournit quelques stratégies sur la façon de s’y prendre pour concevoir un MVP efficace.

Mobilité

Le design pour une plateforme Android devenue mature

http://engineering.appfolio.com/2012/11/16/css-architecture/

Le design des applications Android souffre de la comparaison avec celles disponibles sur iOS d’Apple. Le manque de consistence et la fragmentation de l’ergonomie entre les différentes applications et les différents téléphone Android a grandement contribué à ce problème. Pourtant, la qualité du système Android s’est grandement améliorée aussi bien sur les possibilités de Design, la consistence ou encore les outils de développement. Il est donc temps de fournir à Android de bonnes applications!

Cet article de Smashing Magazine donne les pistes en se basant principalement sur le "design guidelines" maintenant fourni par Google.

Web

Web – CSS architecture

Par Florent Le Gall

Un article intéressant présentant quelques anti-patterns trop souvent observés en CSS, les risques qu’ils cachent, et comment les éviter.

Le coin de la technique

Comprendre et configurer le garbage collector

Le garbage collector est encore aujourd’hui un des composants les plus méconnus des JVM. Celui ci a pour mission de désallouer les objets qui ne sont plus utilisés par le programme afin de libérer de la mémoire pour les nouveaux objets. En fonction de la manière dont il est configuré, le passage du garbage collector peut prendre plusieurs secondes. Pendant ce temps, l’ensemble des threads de la jvm est suspendu, et donc le serveur ne répond plus aux requêtes du client.

Dans cet article, Andreas Müller nous décrit comment il a répondu à cette problématique sur des sites grands publics, et explique le fonctionnement de la mémoire, du garbage collector, et comment tunner celui-ci en fonction des besoins de votre application.

Le driver Java Cassandra-CQL de Datastax est sorti en GA

Par Guillaume Balaine

Le driver Java de Datastax pour CQL, le nouveau langage de requêtes dont la version 3 a été introduite dans Cassandra 1.1 est finalement maintenant entré en GA (version 1). Un certain nombre de features qui reprennent le meilleur des clients qui existaient jusqu’ici et/ou qui étaient impossible avec Thirft se voient implémenter dans ce Driver. Connection pooling, Streaming, Prepared statements, Query DSL, etc. L’article de Datastax est ici, le code ici.

Google I/O – J-1

Thomas Guerin — Tue, 14 May 2013 07:41:51 +0000

Google I/O est la conférence des technologies Google qui se déroule chaque année, depuis 2008, au Moscone Center de San Francisco. Cette année elle s’étend sur 3 jours, du 15 au 17 mai, sous la forme de sessions techniques et de code labs.

Les détails du programme sont disponibles à l’adresse suivante : https://developers.google.com/events/io/sessions. De nombreuses tracks sont présentes avec bien sûr les classiques comme Android, Google Cloud Platform, Chrome mais celle qui retient l’attention est la track Glass.

Bien que le programme soit clairement défini, une question subsiste : Quel sera le contenu de la keynote ? Des mots clés comme Key Lime Pie vs Jelly Bean 4.3, Nexus Q, Glass reviennent souvent sur les blogs techniques mais qu’en sera-t-il réellement?

Cette année j’ai la chance de pouvoir y assister et de vous fournir un retour sur les faits marquants de la conférence. Vous pourrez ainsi suivre en live son déroulement sur twitter (à partir de 18h heure française) ou directement sur https://developers.google.com/live/. Pour finir une synthèse des principales sessions sera disponible sur notre blog dans une série d’articles à venir.

Xebia Event Cassandra 21 Mai

Xebia France — Mon, 13 May 2013 12:01:48 +0000

Xebia organise un atelier Cassandra le 21 Mai prochain

Le 21 Mai prochain, Xebia organise dans ses locaux un Hands-On de deux heures sur les nouveautés de Cassandra 1.2 et le nouveau Java Driver de Datastax.

Cassandra est un datastore open source, orienté colonne, aux performances linéaires. Lors de cet atelier, nous parlerons du modèle distribué de Cassandra, des formats des données et du nouveau langage de requête CQL. Vous apprendrez à dénormaliser, indexer les données d’un réseau social basé sur la musique dans Cassandra avec CQL et Java Driver et éviter les pièges les plus évidents du requêtage dans un cluster distribué.

L’atelier ne nécessite pas de connaissances préalables pour Cassandra, mais il est préférable de maîtriser Java et d’avoir un environnement pré-configuré.

Cette session sera animée par des consultants travaillant chez Xebia dont le formateur Cassandra Guillaume Balaine, Pierre Laporte, Arnaud Lemaire, Mathieu Breton, Clément Lardeur et Joachim Rousseau

Les inscriptions se font ici.

Revue de Presse Xebia

Xebia France — Tue, 07 May 2013 09:07:00 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

Méthodes Agiles : Gérer les entreprises comme des logiciels

http://internetactu.blog.lemonde.fr/2012/12/21/methodes-agiles-gerer-les-entreprises-comme-des-logiciels/?buffer_share=72967

Un article du monde intéressant à bien des égards. Il n’est pas courant de voir Le Monde publier un papier sur l’agilité.

Au-delà des définitions "imprécises" (voir les idées reçues) qui sont données aux différentes méthodes agiles, cet article relate en effet le projet de construction d’une automobile en utilisant le Lean Start Up, par Joe Justice.

On y retrouve les principales étapes et caractéristiques des méthodes employées pour réaliser ce produit. Le sujet avait déja buzzé en début d’année dernière, le voilà réapparaitre sur Le Monde il y a quelques semaines.

Apprenons tôt et souvent : l’acquisition disciplinée de connaissances

Un article long et détaillé d’Allistair Cockburn sur "l’acquisition disciplinée de connaissances en matière de développement de produit". L’article commence par comparer la courbe d’acquisition de connaissances idéale au cours d’un projet (inspirée de différentes méthodes telles que Lean Startup) et celle qu’on croise typiquement sur les projets que ce soit en terme de marketing ou de développement. Le projet commence avec des idées géniales, de grands espoirs et aucune prise en compte que certaines de ces idées sont peut être complètement fausses.

Pour réussir un projet, ses membres doivent apprendre quatre choses :
1. Comment travailler ensemble et, tout simplement, est-ce qu’ils peuvent faire ce travail ?
2. A quels endroits leurs idées techniques sont imparfaites ?
3. Combien cela coûtera-t-il à développer ?
4. Et enfin, sont-ils en train de construire la bonne chose, le bon produit ?

Pour répondre à ces questions, l’article propose de nombreuses stratégies connues (livrer le plus souvent possible, intégration continue) jusqu’à d’autres moins utilisées comme le "walking skeleton" ou le prototypage papier.

Scrum : un écueil pour les SSII ? et Kanban ?

Dans cet article http://www.areyouagile.com/2009/09/scrum-un-ecueil-pour-les-ssii-et-kanban/, datant de 2009, Pablo Pernot (société Smartview – Blog Are You Agile ?) nous décrit la difficulté pour les SSII d’appliquer le cadre Scrum, à la fois auprès de ses clients et dans leurs projets interne (cadre forfaitaire, stabilité des équipes, maturité des clients). Pablo aborde ensuite les apports d’un système Kanban dans l’amélioration du processus Scrum, permettant de réduire les obstacles cités précédemment.

Je pense, qu’au delà des problématiques décrites par Pablo, qui malheureusement ne sont pas propres aux SSII mais à toute organisation actuelle, et malgré quelques imprécisions ("Mon objectif est de définir des User Story (ou MMF : minimal marketable feature) assez compactes et assez indépendantes les unes des autres pour qu’elles puissent être abordées unitairement et assez rapidement" => Le MMF n’est pas la définition de Users Stories compactes, cela relève plus des critères INVEST, mais d’identifier les fonctionnalités minimales à réaliser permettant une livraison rapide d’un produit), Kanban se révèle de plus en plus comme un complément indispensable (j’oserais même indissociable) du cadre Scrum (comme décrit par Laurent Morisseau lors du ScrumDay 2013), tout comme l’eXtreme Programming apporte une plus-value essentielle à Scrum dans les pratiques d’ingénieries.

Le coin de la technique

Les websockets arrivent avec Java EE 7

La nouvelle version de Java EE arrivera en 2013 et intégrera les fonctionnalités de la norme HTLM 5, notamment les websockets grâce à la JSR 356. Pour rappel, websocket est la solution proposée par le W3C pour permettre au serveur de pusher des informations vers le client, sans utiliser les nombreux hacks développés au fil des ans pour contourner cette limitation du protocole HTTP (comet, long pooling, iframe, flash, …).

Cet article vous présente la JSR 356, api de JEE7 pour utiliser les websockets coté serveur et client.

Les développeurs plus âgés ont-ils plus de savoir-faire ?

L’étude relatée dans cet article sur InfoQ a tâché de répondre à la question "Les développeurs plus âgés ont-ils plus de savoir-faire ?" et s’est basée sur les statistiques du site Stack Overflow. Et même si le résultat peut être biaisé et ne pas représenter l’ensemble de la population des développeurs, le résultat est sans appel : oui le nombre d’années passées à développer augmente le savoir faire. Cela peut paraître naturel pour un Software Craftsman mais cela semble beaucoup moins clair dans beaucoup d’organisation où la progression passe par la case Chef de Projet.

La road map de Java EE 7 approuvée par le JCP

http://www.veillemag.com/L-agilite-est-elle-a-la-portee-des-entreprises-francaises_a1225.html

La JSR 342, qui contient l’ensemble des spécifications de Java EE7 a été approuvée par le JCP. JEE7 comprend donc officiellement 14 nouvelles JSR et 9 maintenance release. Parmis les nouvelles JSR, on note l’arrivée de nouvelles api pour :

la gestion des web sockets (JSR 356)
la création et le parsing du format JSON (JSR 353)
la gestion des batchs (JSR 352)
la gestion des taches en asynchrone (JSR 236)

Les api servlet, JPA, EJB, JSP, JSP, JMS, EJB, Bean Validation et CDI sont également mise à jour. La sortie de Java EE 7 est prévue pour fin 2013.

L’annonce du résultat est disponible sur cet article et le résultat du vote sur la page de la JSR 342.

En finir avec le Pilotage Excel Driven

Renaud Chevalier — Mon, 06 May 2013 07:55:00 +0000

Avez-vous déjà rencontré ce genre de fichier Excel dont l’auteur vous explique fièrement qu’il gère finement le pilotage de ses 25 collaborateurs ? Vous savez, ce genre de fichier qui contient 156 lignes, non 157, non 158, non… enfin beaucoup de lignes, dont chacune détaille qui, quand, quoi, comment, avec qui, sur quoi, pour quand, pourquoi, pour qui, le tout avec un identifiant unique bien sûr. Quelque chose comme ça :

Ah, si vous n’êtes pas l’un de ces collaborateurs, peut-être est-ce vous qui utilisez ce fichier que vous considérez comme la clé de voute de votre réussite professionnelle et que vous n’abandonneriez pour rien au monde. Ce genre de fichier Excel est un peu un miroir aux alouettes, il donne à son auteur une impression de maîtrise et de détail, le fichier est extensible et l’on peut ajouter autant de lignes que nécessaire. Pourtant la réalité n’est pas aussi simple.

Aujourd’hui, nous allons voir ce que nous reprochons à ce fichier Excel et comment s’en passer définitivement.

J’ai souvent été confronté dans différentes missions, sur de gros projets, avec beaucoup d’acteurs (internes / externes), à des fichiers Excel de plusieurs centaines de lignes tenus par les équipes de pilotage d’équipes Scrum (équipes étendues). La mise à jour du fichier se fait généralement lors de réunions hebdomadaires interminables et non productives. La lecture du fichier se fait généralement … jamais. C’est malheureusement trop souvent le cas dans des mises à l’échelle. L’agilité se fait au niveau de l’équipe mais on retrouve les bonnes vieilles techniques de management pour synchroniser l’ensemble des parties prenantes (marketing, tests, infra…).
Nous retrouvons la structure la plus courante du fichier Excel : le Qui / Quand / Quoi. Voici un exemple :

Avec ce type de fichier, à moins d’avoir une mémoire d’éléphant, il devient impossible d’avoir une vision globale. Les acteurs sont démotivés, n’écoutent plus, n’ont plus envie de venir en réunion, les tâches perdent de leurs pertinences et ne sont plus traitées, de nouveaux degrés d’alerte apparaissent, la priorisation est de plus en plus difficile, voire impossible… Plus grave encore, des éléments plus structurants pour la fluidité du travail passent totalement inaperçus et ne permettent pas d’anticiper les problèmes : surcharge, goulots d’étranglement non visibles, détection des points de blocage, etc.

Outre les problèmes de fond, des problèmes logistiques viennent s’ajouter : maintenance du fichier, suivi et mise à jour, accès concurrents, versionning, etc.

Dans ce contexte, comment piloter l’activité, maîtriser tous les sujets et anticiper les risques afin de permettre aux équipes Agiles de travailler le plus efficacement possible ? Soyons réaliste… C’est IMPOSSIBLE !!!

Management visuel et Stand-up

Malgré la popularité de ce format, les équipes de pilotages souffrent et ne peuvent que rarement exploiter la mine d’informations contenues dans ce fichier. Je vais donc vous présenter une solution simple pour se débarrasser de cette boîte de Pandore en reprenant quelques principes du Manifeste Agile :

Favoriser la communication plutôt que les processus et les outils,
Favoriser un logiciel qui fonctionne plutôt qu’une documentation exhaustive.

Le principe est d’instaurer un management visuel et changer le format du weekly en Stand-Up. Dans quel but ? Avoir une vision globale, rendre visible l’avancement des tâches, rendre visible les goulots d’étranglement et les points de blocage, réduire le temps du weekly, favoriser la communication, améliorer la cohésion, etc.

Afin de ne pas réinventer la roue, nous proposons un stand-up calqué sur le Daily SCRUM. À tour de rôle, pendant 3 minutes, chaque participant répond à trois questions :

Qu’est-ce que j’ai fait la semaine dernière ?
Quels sont les problèmes que je rencontre ?
Qu’est-ce que je compte faire cette semaine ?

La deuxième étape est de responsabiliser les participants à la levée des obstacles. Ils disposent de 30 minutes pour communiquer entre eux de leurs actions potentielles. L’objectif est de lever un maximum d’obstacles.

La troisième étape est de clore officiellement le standup et de fixer la date du prochain weekly, normalement une semaine plus tard, mais au mois de Mai cela peut changer ;-)

Le point clé de cette solution est de concevoir la structure de l’affichage visuel. Le principe du tableau est inspiré de l’approche Kanban mais nous ne reprenons pas tous les principes. Nous garderons un découpage de l’espace en zones de travail dans lesquelles vont transiter les tâches. L’objectif est d’identifier en un coup d’oeil le volume de travail dans un état précis, tout en conciliant une simplicité d’utilisation. Par rapport à un Kanban classique, les tâches n’auront pas forcément le même cycle de vie, il faut donc rester simple sur la structure du flux de travail.

Le Lean board

Lors d’une précédente expérience, j’ai participé de l’intérieur à une transformation Lean pour l’IT. Les équipes de Coachs ont déployés dans chaque équipe de développement un Kanban assez différent de ce que l’on a l’habitude de voir. L’objectif de celui-ci était de rendre visible le « Qui fait quoi? ». Attention : l’état d’esprit est toujours Agile, il n’est pas question ici de tracking mais bien de limiter toute forme de gaspillage. J’ai trouvé ce format parfaitement adapté pour modéliser notre fichier Excel.

Comment ça marche?

Le tableau est divisé en quatre colonnes. L’aspect visuel est le suivant :

Avec quelques Post-It en plus :

Dans la colonne de gauche, nous listons les sujets, les thèmes principaux qui vont constituer un regroupement cohérent de tâches de la colonne « To Do », la correspondance entre les 2 est assurée par un alignement horizontal (ligne de nage) :

Lorsqu’un acteur démarre une tâche, il la positionne dans sa zone personnelle de la colonne « In Progress » :

Il n’est nullement ici question de « fliquer » les individus, mais bien de détecter les surcharges. Si l’aspect nominatif vous rebute, utilisez un avatar.
Enfin lorsque la tâche est terminée, vous savez ce qu’il se passe ?

Bien vu ! Elles passent à « Done ». Vous noterez également que nous ajoutons des cases supplémentaires pour visualiser des situations particulières et ne pas surcharger les cases individuelles :

Stand-by : les tâches en attentes,
Blocked : les tâches bloquées,
Impediments : les problèmes à régler.

Retour d’expérience

J’ai mis en place cet outil chez deux clients, le premier avec une dizaine d’acteurs et le second avec une trentaine d’acteurs. Voilà mon retour d’expérience.

Règle n°1 : Le « grooming »

L’ajout de sujets et de tâches pendant le weekly ne fonctionne pas. Le consensus des acteurs sur la ou les nouvelle(s) tâche(s) et la rédaction des post-its constituent une perte de temps. De plus, il faut revoir régulièrement la priorisation des tâches. Ce n’est pas l’objectif du weekly. Rappelez-vous que tout le monde est debout. L’objectif est d’être efficace.

Il y a besoin de « groomer » et il faut prévoir un temps pour ça.

Règle n°2 : Un bon weekly est un weekly préparé individuellement

À l’échelle de la semaine, une rétrospective sur ce que l’on a fait, son engagement à venir et expliquer succinctement les problèmes que l’on rencontre ne s’improvise pas (mode « arrache »). Afin d’éviter les temps de recherche (effet découverte), il faut préparer son weekly pour être le plus synthétique possible. Chaque acteur dispose seulement de 3 minutes de temps de parole. Il n’y a rien de plus désagréable pour une assemblée que d’écouter quelqu’un qui vient en « touriste ».

Règle n°3 : Rendre l’urgence visible

Pour rendre les urgences visibles, il faut attirer l’oeil avec des signaux immédiatement perceptibles. Je vous conseille de ne pas dépasser 2 niveaux d’urgence afin de ne pas multiplier les signaux. Le management visuel pourrait devenir contre productif. Vous pouvez utiliser ça:

Remarque : étant donné que le tableau ne gère pas la priorisation (les tâches sont seulement classées par sujet), comment gérer l’urgence sans un signal visuel? Notez donc l’importance de cette règle accompagnée d’une revue régulière des urgences en « grooming » (règle n°1).

Règle n°4: Identifier les points de blocage

Afin d’identifier les points de blocage, pointer les tâches en cours toutes les semaines avec un point ou un bâton. Cette technique permet de rendre visibles les tâches qui stagnent.

Pour éviter cela, il est important de définir des tâches avec une bonne granularité. Idéalement, une tâche à un objectif bien précis avec un résultat attendu explicite et doit pouvoir être résolue en une semaine (notion de « SMART »). Si une tâche stagne, essayez d’identifier pourquoi et n’hésitez pas à la redéfinir, la découper ou même la supprimer lors de la séance de « grooming » (règle n°1).

Règle n°5: Instaurer des KPI ludiques

Afin de challenger les acteurs, mesurez toutes les semaines le nombre de tâches urgentes et celles qui vont le devenir, définissez des seuils et mettez en place un système de récompense si les objectifs sont atteints. Utilisez ces indicateurs pour encourager, créer de la cohésion et un esprit d’équipe.

Règle n°6: De la rigueur dans les post-it

Sur un gros volume de tâches, cela évite que votre tableau ne ressemble à un amas de feuilles qui inquiète plus qu’il ne rassure. Cela permet aussi de garder le contrôle. Pour cela, définissez une taille et un gabarit de post-it et respectez-le !

Règle n°7: Un peu de couleur

Vous pouvez avoir besoin d’identifier visuellement des types de tâche. Dans ce cas, attribuer une couleur par type. De même que pour les règles n°3 et 6, respectez toujours le code couleur (anticiper le réapprovisionnement de post-it) et limitez leur nombre pour éviter l’effet « arbre de noël » :-)

Et alors, ça marche?

Dans les deux cas, en l’espace de 3 semaines, les acteurs se sont appropriés l’outil. Le pilotage est redevenu efficace, avec une vrai visibilité, les urgences ont diminuées et les risques ont de nouveau été anticipés… sans parler du regain de cohésion engendré par la reprise de la communication.

Il faut néanmoins faire attention à « l’effet soufflé » ! Sans un grooming efficace (règle n°1) et une vigilance sur les post-it (règles n°6 et 7), le tableau peut rapidement devenir contre productif. L’animateur du weekly (Directeur de Programmes dans les deux cas) doit rester vigilant pour garder la dynamique du début.

Limitation : la mise en place a été effectuée dans des contextes distribués où il était possible aux acteurs de se rassembler sur site une fois par semaine. Si le déplacement n’est pas possible, rien n’empêche aux acteurs absents d’avoir une case « In Progress » pour donner de la visibilité à l’assemblée. Un suivi hors cérémonie est alors nécessaire et le besoin de dématérialisation reste entier (cf section suivante).

Et le fichier Excel dans tout ça?

Dans certains contextes, pour diverses raisons (culturelles, légales, simples sauvegardes…), les entreprises ont besoin d’écrits et de traçabilité et ce n’est pas NÉGOCIABLE. Welcome in the real world! Les puristes diront que ce n’est pas Agile… Sûrement !!! Mais en attendant de transformer toute l’organisation, on peut réfléchir à des solutions intermédiaires.

Voici deux propositions qui marchent : la première, abandonner le fichier Excel. Dans ce cas, la question du compte rendu de weekly est clairement posée. L’objectif est de garder une trace des changements intervenus au tableau. La seconde, garder le fichier Excel. Il faut alors le mettre à jour à chaque weekly. La mise à jour à tour de rôle est alors une bonne pratique.

Pour aider la prise de décision, posez-vous les bonnes questions :

Est-ce vraiment utile ?
Quels sont les objectifs du document ?
À qui le document est-il destiné ?
Le document est-il utilisé ?
Qui rédige et quand ?
Etc.

Dans tous les cas, rappelez-vous pourquoi vous passez au Management Visuel. Evitez la marche arrière et contentez-vous du minimum vital… Soyez EFFICACE !!!

Hadoop Summit 2013 à Amsterdam, le rattrapage

Bertrand Dechoux — Thu, 02 May 2013 09:50:43 +0000

Le premier Hadoop Summit en Europe est fini. Mais si vous n’avez pu y participer, il est toujours temps de se rattraper en consultant les slides et les vidéos des présentations renseignées sur le planning. Bien sûr, cela ne vous permettra pas de participer aux échanges ‘de couloirs’. Mais il ne faut pas non plus oublier que la communauté française est active au travers du Hadoop User Group France avec des réunions mensuelles. Pour ceux près de Paris, c’est l’occasion de partager de vive voix ses expériences. Et pour tout le monde, un accès à d’autres présentations, en français cette fois-ci.

Pendant ce Hadoop Summit européen, nous avons pu assister à de nombreuses présentations. Voici quelques notes concernant celles qui nous ont le plus marqué.

What the point of Hadoop?

Matt Aslett, directeur de la recherche à 451 Research, a ouvert cette conférence avec une question fondamentale : pourquoi Hadoop ? Sa réponse est à la fois simple et très nuancée puisque contextuelle. Il s’agit d’une plate-forme d’une très grande flexibilité, ce qui est à la fois une aubaine et un frein.

C’est avec humour qu’il a fait le rapprochement avec l’histoire des aveugles et de l’éléphant. Bien sûr en fonction de ce que vous voyez (ce qui dépend de votre métier et de votre expérience) Hadoop peut être quelque chose de très particulier pour vous et de complètement différent pour quelqu’un d’autre. Il existe cependant bien un chemin standard pour franchir le fossé de l’adoption :

stockage : récupérer les données des composants existants dans votre SI et centraliser les logs/événements qui devaient être jetés auparavant.
nettoyage/filtrage/extraction : fournir à votre SI les données avec le format et la granularité que chaque composant est capable de gérer.
analytique : utiliser, finalement, la puissance de calcul d’Hadoop afin de faire les analyses directement sur cette plateforme.

Chaque étape permet de profiter de plus en plus des avantages d’Hadoop mais le chemin est à prendre dans le bon sens au risque de mettre la charrue avant les bœufs. Il est important de maitriser la complexité du SI existant et sa migration.

Matt Aslett redéfinit plus précisément la problématique (total data) en quatre axes.

totalité : Hadoop permet de stocker la totalité de vos données. Faites le et profitez des économies d’échelle.
exploration : les données brutes étant stockées, il est possible de les analyser afin de comprendre les informations qui peuvent se révéler utiles. Le fait de ne pas avoir à sélectionner/préparer les données avant de les stocker est clairement un avantage afin d’éviter de biaiser l’exploration.
fréquence : les processus existants peuvent être portés sur la plateforme afin d’augmenter leur fréquence d’exécution, par exemple du mois au jour. On ne parle pas de temps réel mais cela peut tout de même révolutionner les dynamiques d’un métier.
dépendance : enfin de plus en plus de solutions permettent de requêter un cluster Hadoop avec du (pseudo-)SQL. Cela permet de réutiliser les compétences acquises mais fournit aussi un lien technique, maitrisé et connu, pour intégrer Hadoop dans le SI.

Pour ceux qui souhaitent comprendre le buzz derrière cette technologie, c’est définitivement une keynote à rattraper (vidéo et slides).

Enterprise Integration of Disruptive Technologies

Yahoo!, Facebook et Twitter sont souvent cités comme modèles pour leur utilisation des nouvelles technologies, telle que Hadoop. Cependant, même s’il y a certainement beaucoup à apprendre de ces entreprises, « les géants du web », peu d’entreprises peuvent se considérer comme similaires à celles-ci, notamment en France. Une entreprise peut-elle tirer parti d’Hadoop sachant que son SI est déjà complexe, qu’il est critique, qu’il ne doit pas être perturbé et que de plus cette entreprise est par culture très conservatrice et prudente? Alasdair Anderson nous a montré que c’était possible en nous expliquant la mise en place d’Hadoop chez HSBC : slides.

Si vous êtes persuadé de l’intérêt d’Hadoop mais que vous n’arrivez pas à envisager son intégration dans votre entreprise, cette présentation vous permettra certainement de prendre du recul par rapport aux problématiques que vous prévoyez. Des entreprises ont franchi le pas et de plus en plus exposent leur migration. Comme second exemple, il est opportun de rappeler le retour d’expérience fait par Mathias Herberts concernant le Credit Mutuel Arkea lors d’un meetup du HUG. Le retour d’expérience de Criteo sur leur utilisation est certainement à voir aussi, la vidéo sera uploadée prochainement sur le site du HUG.

Hadoop Now, Next and Beyond

Eric Baldeschwieler, CTO et fondateur d’Hortonworks, a ouvert la seconde journée en retraçant l’évolution d’Hadoop : depuis sa naissance, son utilisation chez Yahoo! puis les améliorations à venir. Ce fut l’occasion de faire un tour de l’écosystème et notamment des nouvelles briques à venir. L’initiative Stinger a pour but d’accélérer Hive par un facteur de 100. Cela passera notamment par Tez. Ce nouveau framework d’exécution utilisant YARN remplacera MapReduce afin de fournir des requêtes à latences faibles, prérequis nécessaire pour une exploration interactive des données stockées sur Hadoop. La sécurité est également revue : Knox a pour objectif de proposer une solution plus flexible et plus customisable que l’existant se reposant sur l’obligation d’utiliser Kerberos. Et c’est également au tour du data management de se voir cibler avec le projet Falcon, disponible sur github sous l’ancien nom Ivory et désormais un projet Apache.

Pour reprendre le sujet : la video et les slides.

Hadoop and the Enterprise Data Warehouse

Patrick Angeles, director of field engineering à Cloudera, est revenu sur l’intégration d’Hadoop en entreprise ; spécifiquement sa relation avec les data warehouse et data marts mais plus généralement avec les différentes couches nécessaires pour analyser les données métiers. La volumétrie, la variété et la vitesse des données impacteront l’architecture utilisée pour le décisionnel mais on retrouve cependant de grands schémas, des patterns. Si vous souhaitez mieux comprendre comment Hadoop peut compléter, voire remplacer, certaines briques de votre information décisionnelle, c’est une présentation à ne pas manquer : slides.

En conclusion

Cette confèrence Hadoop Summit 2013 à Amsterdam était un événement unique puisque le premier en Europe. Etant un spin-off d’une conférence déjà bien établie, les speakers étaient triés sur le volet. Elle a rassemblé des intervenants d’entreprises dont l’implication n’est plus à démontrer : Hortonworks, MapR, Cloudera mais aussi Yahoo!, Facebook, LinkedIn, Twitter… On a apprécié le fait d’avoir un public mixte, composé à la fois de décideurs, de concepteurs et d’exploitants. C’est un plus pour favoriser l’adoption d’Hadoop mais surtout pour crééer une synergie nécessaire au succes de sa mise en place. Bien que previsible en regardant la liste des speakers, on regrettera le fait que la vision d’Hortonworks était peu nuancée par ses compétiteurs. Enfin si l’on devait comparer juste le nombre de participants (500), cela reste une petite confèrence même par rapport à des conférences nationales (devoxx france : 1500). La communauté s’agrandit cependant de jours en jours et s’il fallait donner un conseil pour Hadoop Summit 2014 en Europe, cela serait seulement : ne la loupez pas.

Revue de Presse Xebia

Xebia France — Mon, 29 Apr 2013 21:12:54 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

L’agilité est-elle à la portée des Entreprises Française ?

Par Couthaïer FARFRA

« L’entreprise agile est une entreprise qui adapte en permanence son organisation afin de correspondre au mieux aux attentes évolutives du marché et de ses clients. Dans un pays ou chaque évolution est source de contestation est-il possible que les entreprises deviennent agiles ? »

Au travers de cette introduction, Jean-Pierre Malle (M8 Institut), nous fais part de sa réflexion sur la capacité des entreprises Françaises à devenir « Agiles », au travers de 3 modes d’organisation habituellement vu au sein d’une Entreprise : Organisation orientée « Métier » ; Organisation orientée « Processus » ; Organisation orientée « Services ».

Implementing Minimum Viable Changes As Part of a Lean Startup For Change Approach

http://agileconsulting.blogspot.fr/2012/04/implementing-minimum-viable-changes-as.html

Un article sur le Lean Start up… du 25 avril 2012.

Cet article est Intéressant car il détaille une façon de produire des petits incréments, permettant de valider les hypothèses du MVC (Model-View-Controller), le tout en s’appuyant sur un Kanban/ Backlog des hypothèses.

Cette démarche met également en avant l’absolue nécessité de travailler en équipes représentatives et rapprochées.

Le coin de la technique

Lancement du projet Spring XD

Par Eric Briand

Springsource a annoncé le lancement d’un nouveau projet Spring : Spring XD (eXtreme Data). Cette nouvelle initiative vise à adresser et simplifier des problématiques qu’engendre les projets Big Data telles que :

Flux important de données en provenance de différentes sources à stocker sur HDFS
Statistiques en temps réel sur de gros volume de données transitant
Gestion de workflows, batchs, map reducing
Export de données aussi important vers des bases SQL ou NoSQL

Ce projet va se baser sur des projets Spring déjà existant comme Spring Batch, Spring Integration ou encore Spring Data. Le projet n’en est encore qu’à ses prémises, mais vous pouvez déjà allez sur le github du projet ou sur le JIRA du projet pour suivre en suivre l’évolution, et voir y contribuer !

JBoss AS devient Wildfly

Jboss AS, le serveur d’application open source de red hat change de nom. Afin d’éviter une confusion entre la communauté JBoss, qui regroupe une centaine de projet (notamment JBPM, JBoss drools, JBPM, …), et le serveur d’application éponyme, la société Red Hat a organisé un concours pour renommer son serveur. C’est finalement Wildfly qui l’emporte. JBoss 7.1.1 sera donc la dernière version sous l’appelation JBoss.

Le nouveau site web du projet se trouve ici.

MRunit sort en version 1.0

Par Bertrand Dechoux

MRunit, la librairie pour tester unitairement et facilement vos jobs MapReduce, vient de sortir en version 1.0. Cela marque la première release depuis la promotion de ce projet en tant qu’Apache TLP (Top Level Project), autrement dit depuis sa sortie de l’incubateur apache. La release précédente, la 0.9-incubating, date d’un an environ. Cette mise à jour apporte trois nouveautés majeures :

Support d’entrées multiples (MRUNIT-64).
- Jusqu’à présent, l’API ne permettait de fournir qu’un seul couple de clef/valeur en entrée. Avec plusieurs, il sera plus facile de tester les implémentations utilisant (à bon escient ou non) un état entre les traitements des différentes clef/valeur.
Support du cache distribué (MRUNIT-98).
- Le cache distribué permet aux jobs de partager facilement des jeux de données de petites tailles (et/ou de la configuration). Il facilite ainsi l’implémentation de jointures faites seulement dans la phase de map. Avec le support du cache distribué dans les tests, il est désormais possible de tester ce genre de fonctionnalités afin d’éviter de futures régressions.
Support des OutputFormats (MRUNIT-101).
- L’interface OutputFormat spécifie comment les données doivent être enregistrées à la fin d’un job. Jusqu’à présent, la libraire avait fait le choix de mocker cette partie afin de récupérer facilement les résultats. Le désavantage était qu’il n’était pas possible de vérifier le fonctionnement de l’OuputFormat utilisé avec les particularités du job.

Si vous souhaitez en savoir plus, les release notes sous JIRA fournissent un inventaire exhaustif.

Retour sur le ScrumDay 2013

Clément Rochas — Mon, 29 Apr 2013 07:30:32 +0000

Nous étions présents au ScrumDay 2013 et nous vous proposons un retour rapide sur quelques sessions que nous avons suivies. Le programme était (très) riche, aussi ne soyez pas étonnés de ne pas trouver un compte-rendu de toutes les sessions. Le nombre de tracks parallèles a même été un sujet de frustration pour certains d’entre nous… Il a donc fallu faire des choix et espérer que ceux-ci soient les bons.

Vous pouvez retrouver les vidéos de beaucoup de sessions sur la chaine du French Scrum User Group

Coach : Aidez-moi à marcher

Si vous avez lu l’ouvrage « Coacher une équipe agile », vous avez une idée des outils plébiscités par Véronique Messager. Accompagnée pour cet atelier de Magali Baton, championne de Judo et coach certifiée HEC, le duo a démarré l’atelier par une mise en situation amusante et finalement très représentative des situations rencontrées par les coachs et les Scrum Masters dans la vie de tous les jours. Il s’agissait de faire lever de sa chaise Magali… Elle veut, mais elle n’y arrive pas : »je suis coincée, je n’arrive plus à me lever pour marcher, je souhaiterais y arriver, aidez-moi ! »

Les participants ont essayé de la faire lever. Certains ont cherché la raison, d’autres ont voulu l’assister, d’autres encore ont voulu la soudoyer ou même la forcer !

Cette habile métaphore des situations du quotidien a permis à nos deux coachs de débriefer et de catégoriser les interactions : questions ouvertes/fermées, injonctions/conseils… et d’insister sur la position basse que le coach se doit d’avoir.

Malheureusement, le slot trop court et les questions de l’assemblée ne nous ont pas laissé le temps de faire la seconde partie de la mise en pratique. Je retiendrai que la professionnalisation des coachs et les passerelles de plus en plus évidentes entre coach et coach agile annoncent encore de beaux débats entre les personnes qui considèrent que les coachs agile peuvent être des mentors et ceux qui considèrent que cette autre posture d’accompagnement n’a pas lieu d’être dans l’accompagnement agile.

#OMG : mon équipe fait son haka en Kanban Style

Vous avez sans doute lu l’excellent ouvrage de Laurent Morisseau « Kanban pour l’IT » (si ce n’est pas le cas, courez vite l’acheter) où il décrit avec pédagogie la force de l’utilisation d’un Système Kanban dans l’amélioration des processus de développement logiciel. Dans cet atelier, Laurent annonce la couleur dès le début « J’ai écrit un livre sur Kanban, d’accord, mais maintenant je vais vous expliquer comment l’utiliser pour améliorer le processus Scrum » (à quelque chose près), c’est ce qu’on appelle du ScrumBan.

Pendant une heure, Laurent Morisseau nous a démontré comment mettre en oeuvre des pratiques Kanban, au sein d’un dashboard Scrum, afin d’en améliorer le processus de fonctionnement et ainsi éviter les goulets d’étranglement et les baisses d’activité, dans une démarche de planification du Juste à Temps (JAT). La démonstration des apports de Kanban se fait au travers de ce que Laurent a appelé les 3 « Scènes de crime » (entre autres) :

Une Story = 1 développeur
Le goulet d’étranglement entre les différentes étapes (conception, développement, tests)
Un Product Owner débordé

Cette présentation, associée à l’aisance de Laurent, a été passionnante, bien que trop courte à mon avis. D’autant plus que j’ai eu l’occasion, avec mon collègue Clément Rochas, de mettre en application ces principes avec succès auprès d’un de nos clients.

Si vous souhaitez en savoir plus, je vous propose une série de vidéos de cette présentation.

Booster votre SCRUM avec Lean Start Up

Très bonne présentation de M. Olivier Lafontan qui, en un peu plus de 45 minutes, a su restituer l’essence du lean Start Up.

Après une courte présentation de Scrum, la problématique est posée : « Scrum nous permet de faire efficacement un logiciel en collaboration avec le Product Owner (priorisation, user story). Est-ce pour autant suffisant pour savoir si nous avons développé le BON logiciel, celui qui apportera la VALEUR attendue par ses futurs utilisateurs ? »

La recherche de la valeur utilisateur, le Graal des projets en Lean Start Up.

Après une courte présentation des 7 principaux outils Lean Start Up, on reste toujours sur sa faim concernant le « Customer Developpement », pratique qui permet de mieux connaitre ses futurs clients, de découvrir ce que sont leurs problèmes.

Quelques outils furent également rapidement présentés comme l’incontournable Lean Canvas, mais également la validation Board de leanstartupmachine.com qui permet de dérouler les hypothèses sur les différents incréments du produit.

Cette présentation était donc intéressante pour découvrir le Lean Start Up et connaître sa valeur ajoutée, mais la durée de la présentation ne permettait pas de creuser réellement le sujet.

On ne peut donc parler que d’une mise en bouche. Le site leanstartupmachine.com permet d’approfondir ses connaissances, avec notamment une étude de cas à télécharger.

Keynote : Culture Hacking

Une Keynote engagée qui nous a présenté 5 « hacks » permettant d’améliorer la culture de l’entreprise et la motivation des équipes tirés en particulier de l’expérience de Zappos :

Hack 1 : la façon dont vous entrez dans la pièce peut affecter la culture
Hack 2 : il faut savoir détruire quelque chose
Hack 3 : votre entreprise n’est pas un médicament
Hack 4 : la frustration est une opportunité
Hack 5 : il faut créer des rituels pour donner de l’énergie

Je suis personnellement resté sur ma faim, car l’ensemble de la présentation ne me semble pas adapté à la culture et au contexte français avec son utilisation massive de prestataires extérieurs à l’entreprise. De plus, la présentation n’expliquait pas les concepts psychologiques de ces hacks. Présenter les concepts fondamentaux, le « pourquoi » permettrait de mieux les réadapter à des contextes différents.

L’agilité selon Starcraft 2

Le sujet abordé par Christophe Héral était difficile par sa spécificité. Le monde de Starcraft 2 et de l’eSport a son vocabulaire et son contexte difficile à retranscrire pour le néophyte. J’ai trouvé que la notion de feedback constant était le seul vrai rapport entre l’Agilité et le jeu. Un des problèmes de la comparaison est surtout que Starcraft 2 à haut niveau est principalement une activité où on se retrouve seul face à l’adversaire alors que les problèmes de l’Agilité sont surtout liés à la gestion d’une équipe, d’un groupe de personnes. Par contre, étant connaisseur du jeu, je pense que la comparaison serait très intéressante avec la stratégie produit voire d’entreprise.

L’art d’avoir tort

Dans cette atelier, Laurent Bossavit nous a fait la démonstration par le jeu que nous sommes mauvais pour faire des estimations. Plus précisément, nous ne sommes pas calibrés pour. Pour cela, il nous a fait une petite introduction à la pensée probabiliste. Mais nous n’avons pas à être vexés par ce constat d’échec, car même les experts font très souvent de mauvaises estimations (pour aller plus loin, il faut lire « Expert Political Judgment: How Good Is It? How Can We Know? » de Philip Tetlock). Par exemple, si un expert déclare un événement comme impossible, il a 15% de chances de se produire ; s’il déclare un événement comme certain, il a 27% de chances de ne pas se produire (on voit l’effet de l’optimisme sur les probabilités).

Cependant nous pouvons nous améliorer ! Pour cela, il faut à la fois s’entrainer à faire des estimations, mais aussi à y ajouter notre pourcentage de confiance sur la question puis vérifier et mesurer nos jugements. Pour cela, deux sites peuvent nous aider à nous entrainer : http://predictionbook.com/ et http://www.goodjudgmentproject.com/

1 Feature Owner, 5 Product Owner, 5 Teams 4 Great Products

Dans cette conférence, Bertrand Dour a pris la métaphore du groupe de rock pour présenter une organisation produit et il revient beaucoup sur l’exemple de l’organisation mise en place chez Spotify. Une conférence qui a démarré difficilement, le temps de faire comprendre la métaphore. Au final, on en retient surtout qu’une organisation traditionnelle avec ses manageurs, son besoin de contrôle, de métriques et sa peur de l’inconnu sont difficilement compatibles avec une organisation organique et très agile à la Spotify (le groupe de rock). Pourtant, il faut un porteur de la vision globale, par exemple un chef de produit, qui va organiser les différentes équipes techniques, qui va être garant de la cohérence, mais aussi facilitateur en cas de conflit et organisateur de rétrospectives sur l’ensemble des équipes du produit.

Identifiez et traitez les signaux et comportements freinant l’adoption de l’agilité

Petit atelier animé par Éric Siber assez sympathique, même si on était beaucoup trop nombreux au départ. L’idée était de voter pour des signaux et comportements dans une équipe Agile, décider si c’était des problèmes nuisant à l’Agilité pour enfin en discuter, définir quels principes de l’Agilité et surtout du manifeste Agile, ils remettaient en cause et trouver des solutions. À refaire dans une table ronde ou pourquoi pas une rétrospective !

DDD & BDD Games

Pour résumer, il n’y a pas de bons modèles métiers ! Un excellent jeu à découvrir animé par Cyril Martraire qui vous permettra de mieux comprendre la notion de « Bounded Context » en DDD et pourquoi il est impossible d’unifier la vision de l’ensemble des acteurs d’une entreprise ou d’un produit au sein d’un même modèle, sous peine de voir ses objets métiers devenir d’énormes listes de champs disparates. En gros, comme dans une démarche UX, il faut se mettre à la place de l’utilisateur (le métier ciblé ici) et concevoir le modèle métier en fonction et en se limitant à ce point de vue. La deuxième partie de l’exercice avait pour but de nous apprendre l’écriture de tests fonctionnels sous forme BDD.

Agile appliqué à toute l’entreprise : Retour d’expérience sur le marché du paiement électronique

Par Ludovic Pérot

Ce REX était animé par Bruno Sbille, accompagné de son client Frédéric Dujeux. Le REX précédent ayant un peu débordé, ils ont dû aller à l’essentiel et faire des coupes pour tenir le timing, un peu dommage. Surtout quand on choisit cette session pour son orateur, car Bruno est excellent à ce jeu-là. Les orateurs nous ont bien expliqué comment la sauce a pris, sans mettre de côté les difficultés et les challenges qu’ils ont rencontrés. Nous y avons appris qu’ils ont opté pour l’approche projet pilote et pas un big bang, que l’identification des Scrum Masters et leur accompagnement n’a pas été complètement fluide… Un REX classique, ça manquait un peu de Star Wars (Bruno est un grand fan), mais les orateurs nous ont bien fait découvrir leur parcours de presque deux ans.

Paris Groovy & Grails User Group @ Xebia

Aurélien Maury — Mon, 29 Apr 2013 07:52:26 +0000

La prochaine édition du Groovy & Grails User Group de Paris se tiendra le 29 mai à 19h30 dans les locaux de Xebia.

J’aurai le plaisir de pouvoir vous parler de ma dernière expérience sur un site grand public basé sur Grails : un service de comparaison de voyages train, avion et voiture à travers l’Europe.

Je vous montrerai rapidement l’architecture générale, les différents backends en jeu et la difficulté à collecter et agréger les résultats de chacun. Ensuite je porterai votre attention sur l’utilisation de GPars et des Actors.

Vous saurez comment cette librairie a aidé à résoudre les problèmes de concurrence sans compromettre les performances. Vous découvrirez le monde merveilleux de l’organisation d’Actors, du message flow, du dimensionnement de ThreadPool et les stratégies de tests associées.

Cette étude de cas de la Vraie Vie ® vous révelera le potentiel de ce superbe outil : GPars vs Wild

Réservez sur Meetup.

Revue de Presse Xebia

Xebia France — Tue, 23 Apr 2013 07:00:30 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

Agilité - Coaching ou mentoring ?

Dans scrum, pour ne citer que cette méthode, il n’y a pas de coaches! Le garant de la méthode est le scrum master. Pourtant de plus en plus on fait appel à lui car la conduite du changement nécessite souvent un peu d’abstraction. Si vous discutez avec un coach professionnel, vous vous rendrez compte que l’on attend souvent d’un coach agile des actions que se refuse à faire un coach. Dans cet article vous trouverez les limites que se fixent les coaches et les mentors.

Extrait:

Un mentor n’est donc pas neutre (mais le coach l’est-il vraiment ?), bien au contraire, il y a de l’affection entre le mentor et son « protégé ». Car le propre du mentor c’est de protéger l’autre. Le mot est fort, mais c’est bien de cela qu’il s’agit. Il « veille sur » jusqu’à l’autonomie de la personne. Si le coach met à l’épreuve le coaché, rédige un contrat tripartite, définit un plan en « x » séances, pose des questions « percutantes », met en avant les contradictions, laisse le choix, ne donne ni conseil ni ne forme (c’est en tout cas ce que les principaux écrits français avancent), le mentor quant à lui, a pour intention d’accueillir, de guider, d’enseigner, d’entraîner, d’être un modèle. Le mentor présente des défis au protégé et lui fournit l’occasion de faire ses preuves.

Comment le pragmatisme de l’équipe IT d’Obama a surclassé celle de Romney

Par Ludovic Pérot

Cet article est rangé dans la catégorie ‘agilité’ de notre revue de presse, mais il balaie beaucoup de sujets. How Team Obama’ tech efficiency left Romney IT in dust décrit les choix forts de l’équipe IT d’Obama (cloud, open source, open architecture, devOps). Cette stratégie leur a permis de présenter une facture presque 15 millions de dollars inférieure que celle de Romney dans leurs budgets de campagne respectifs. L’article donne l’ensemble des coûts IT dans la campagne du futur vainqueur, un éclairage rare et très factuel. A quand le même article pour des campagnes françaises ?

16 moyens de torturer vos développeurs

Un excellent article qui vous donne 16 astuces pour torturer vos développeurs du plus classique Windows, son antivirus qui rend la machine inutilisable, être dans l’équipe de maintenance, le management par la prise d’otage aux plus extremes comme bloquer toutes les librairies tiers sans des mois de validation, travailler obligatoirement dans une VM et même les daily stand up de 45 min!

Web

Sortie de jQuery 2.0

Par Benoit Lemoine

La tant attendue version 2.0 de jQuery est enfin sortie ! Comme prévu, cette version marque un tournant dans la vie de la célèbre librairie Javascript en cessant le support des vieux navigateurs que sont Internet explorer 6, 7 et 8. Mais pas de panique, l’équipe de jQuery continue de maintenir la branche 1.9 en parallèle de la version 2.0, de façon à pouvoir utiliser les éventuelles nouvelles API sur les anciens navigateurs. L’arrêt du support des vieilles versions d’Internet Explorer a permis une réduction de la taille de la librairie d’environ 12%, ainsi que l’amélioration globale des performances de la librairie. Autre nouveauté, les build personnalisés sont maintenant bien mieux découpés, et permettent le téléchargement d’une version de jQuery contenant, ou non, 12 module différents.

Attention cependant, jQuery 1.9 et 2.0 partageant les même API, si vous utilisez toujours une version plus ancienne, il peut être nécessaire de migrer vos applications. Pour vous aider, vous pouvez toujours utiliser le plugin migrate.

Modulariser votre projet Angular

Avec le gain de popularité du framework angular, les best practices commencent à émerger. Cet article décrit comment structurer et organiser nos projets en fonction de leur taille. Les projets angular peuvent être divisés en modules (un peu comme un projet Maven). Tout comme sur un projet Java, les modules permettent de regrouper vos composants (les services, controllers, directives et filtres) par fonctionnalités ou par couches : structurant ainsi votre application.

Ember.js RC3 arrive dans les bacs

Cette nouvelle version du Framework MVC JS à la braise sort moins d’un mois après la dernière release candidate. On y retrouve une amélioration des performances via l’agglomération du buffering et de l’insertion des vues enfants contiguës, la suppression asynchrone des objets ( afin de prévenir les désabonnements massifs d’écouteurs de grosse grappe d’objet ) et un allégement de l’empreinte mémoire pendant la phase de rendue des vues.

Ce millésime marque aussi le début d’un chantier d’amélioration de la testabilité des applications Ember avec en autre, des corrections et améliorations de la méthode App.reset qui sert à ré-initialisaser le context d’une application Ember comme si vous veniez de faire un rechargement de votre page. Dans le même esprit le pipe de continious delivry d’Ember, géré par Travis, expose désormais les derniers builds à l’adresse builds.emberjs.com.

Autre nouveauté plus inattendue, la transition des champs de formulaire d’un format helper view classique vers des helpers input plus générique. Exemple :

Avant :

{{view Ember.TextField valueBinding="name"}}
{{view Ember.Checkbox checkedBinding="isActive"}}
{{view Ember.TextArea valueBinding="name"}}

Maintenant :

{{input value=name}}
{{input checked=isActive}}
{{textarea value=name}}

La team Ember conseil l’utilisation des ces nouveaux helpers plus “dynamiques”.

Plus de détails : http://emberjs.com/blog/2013/04/21/ember-1-0-rc3.html

Le coin de la technique

Oracle repousse une nouvelle fois la sortie de Java 8

Par Eric Briand

Après les nombreux déboires d’Oracle en matière de sécurité ces derniers temps avec les nombreuses failles du framework Java, Oracle a décidé de repousser la release de Java 8. Dans un long billet de blog, Mark Reinhold, l’architecte en chef du projet, explique les raisons de ce choix :

Ne pas répéter les erreurs du passé : Ne pas aller trop vite pour se retrouver une nouvelle fois confronté a une suite de problèmes de sécurité.
Ne pas enlever le projet Lambda de la release : Enlever ce projet de la release reviendrai à le faire sortir en 2016 (si le rythme d’une release tous les deux ans est maintenu) et ferai perdre beaucoup de se son intérêt à cette release du framework.
Prendre le temps de passer en revue les évolutions

Mark parle aussi de la possibilité de repousser la release encore plus pour permettre au projet Jigsaw d’être dans la version 8 du framework java mais il semblerait que le retard causé par l’introduction de ce projet serait bien trop conséquent. La sortie de Java 8 est maintenant prévue pour le mois de mars de l’année 2014.

Expérience Utilisateur

UX Design for startup

Un excellent ebook d’une centaine de pages sur l’UX design dans le cadre d’une startup mais surement aussi applicable sur beaucoup de produits d’entreprise. On y parle de Lean Canvas, du besoin de connaître vos utilisateurs, de méthodes UX comme le prototypage ou l’utilisation des métriques et enfin liste une série d’outils. Cet ebook est aussi une excellente lecture pour toute personne s’intéressant à une méthodologie type Lean Startup.

UX et Agilité

Télécharger un exemplaire du TechTrends

Même si Agilité et Expérience Utilisateur adressent tous deux les problèmes qui existent dans le développement logiciel traditionnel pour offrir une meilleur solution pour l’utilisateur final, il semble parfois difficile de les faire cohabiter. L’article "UX and Agile: tying the knot" de UX Magazine revient sur cette question et nous offre quelques éléments de réponse. Nous devrions mettre en place des méthodes adaptatives et flexible (Agile, Lean) et il faudrait se recentrer sur l’utilisateur en réinterprétant le célèbre triangle du management de projet (le planning, le coût et le scope) pour trouver un équilibre entre:

est-ce viable? peut-on se permettre de la faire ?
est-ce faisable? peut-on le construire ?
est-ce désirable? est-ce que l’utilisateur sera intéressé ?

Point intéressant, l’article nous dit que faire venir un excellent UX designer ou Scrum Master ne résoudra pas tous les problèmes. Il faut que l’organisation évolue et comprenne que l’objectif de l’entreprise et sa vision font partie de l’expérience utilisateur globale.

Xebia à Mix-IT 2013

Nicolas Jozwiak — Mon, 22 Apr 2013 14:25:00 +0000

Cette année, la conférence Mix-IT se tiendra les Jeudi 25 et Vendredi 26 Avril. Basée à Lyon, elle est organisée par le Lyon JUG et le Club Agile Rhône-Alpes. Plus de 50 speakers animeront pendant ces deux jours des ateliers et des conférences.

On y parlera notamment d’agilité, de langages (Scala, Kotlin), de Web et de NoSQL.

Xebia participe à cet événement en animant 3 slots :

Scrum Metal Jacket par Jean-Louis Rigau et Nicolas Jozwiak
Comment tester une application HTML 5 ? par Jean Laurent de Morlhon
C’est le moment de se lancer dans s’cas la ! par Jean Helou (avec la complicité de Ludwine Probst et Mathieu Chataigner)

Vous pouvez découvrir le programme complet ici.

La conférence TechTrends 2013

Xebia France — Fri, 19 Apr 2013 09:48:44 +0000

TechTrends, késako ?

Parmi les valeurs de Xebia, "Sharing Knowledge" a été appliquée de nouveau au travers de son projet "TechTrends".

Mardi 16 avril 2013, des intervenants de hauts rangs ont présenté à un public de cinquante décideurs techniques les tendances technologiques, tirées du savoir-faire et de l’expérience de nos 80 consultants, de nos CTOs et de notre président, lors de la première conférence des TechTrends.

Cette matinée avait pour ambition de présenter un aperçu global des sujets approfondis dans le magasine des TechTrends 2013.

Les speakers

Les tendances technologiques de demain ont été présentées par xebians qui travaillent au quotidien au coeur des problématiques abordées :

Thibaud Cavin, responsable mobilité, "l’informatique de demain sera mobile ou ne sera pas" ;
Jean-Laurent de Morlhon, CTO, "le Web remet en cause notre héritage informatique" et "l’agilité, c’est un peu tous les jours" ;
Pablo Lopez, CTO, "l’infrastructure de l’entreprise est en profonde mutation" et "les données valent de l’or, il est temps de les exploiter" ;
Luc Legardeur, président, a partagé son expérience manageriale et les clés de la réussite du projet TechTrends.

Percevoir le futur

Xebia se propose de publier de façon trimestrielle un magasine spécialisé sur un de ses piliers (Agilité, Big Data, Infrastructure, Langage, Mobile, Web). Il sera possible de s’abonner, afin de se tenir en permanence au fait des évolutions perçues par les professionnels compétents que nous comptons dans nos rangs.

Actuellement, il vous est possible de télécharger le document via le site : http://techtrends.xebia.fr/.

D’autres évènements d’échange autour de ces sujets seront organisés, nous espérons vous y voir nombreux.

Ci-joint, la présentation de la conférence :

Le TechTrends est disponible !

Luc Legardeur — Wed, 17 Apr 2013 13:19:11 +0000

Le monde des nouvelles technologies évolue de plus en plus vite et apporte chaque année son lot d’usages nouveaux et d’innovations, tous plus prometteurs les uns que les autres.

Cependant, cette foison de nouveaux concepts technologiques et méthodologiques s’accompagne d’un dilemme. Il s’agira de choisir entre expérimenter, adopter (ou non) en différenciant le mainstream de l’effet de mode.

L’une des valeurs fondatrices chez Xebia est « Sharing Knowledge ».

C’est donc avec grand plaisir que nous vous présentons sur notre site dédié la première version de notre TechTrends, synthèse du savoir-faire de nos 80 consultants français qui, en 2012, ont passé plus de 880 jours en R&D dans le cadre de nos XKE (Xebia Knowledge Exchange), organisé 50 TechEvents avec les éditeurs et acteurs de notre communauté et expérimenté les technologies dont nous vous parlons dans ce document.

Organisé en quatre thèmes (Architectures Orientées Web, Infrastructure d’entreprises, Langages de la JVM and Friends, Agilité and Craftsmanship), ce document vous propose également deux études plus poussées dans des domaines qui révolutionnent et continueront de révolutionner l’IT à l’avenir : Big Data et les applications mobiles d’entreprise.

Le TechTrends est un document à destination de toutes celles et ceux qui doivent opérer des choix structurants pour leur IT et souhaitent bénéficier du retour d’expérience terrain de ceux qui ont déjà expérimenté les technologies d’aujourd’hui et de demain.

Nous espérons qu’il vous guidera dans les décisions importantes que vous aurez à prendre.

Nous vous en souhaitons bonne lecture et rendez-vous en septembre pour le prochain numéro dédié au Web.

Revue de Presse Xebia

Xebia France — Tue, 16 Apr 2013 08:00:54 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité
- The Battle : Priorisation using MoSCoW vs Kano Analysis (Par Couthaïer Farfra)
- 5 raisons de célébrer ses erreurs au travail (Par Clément Rochas)
Web
- Browser Diet (Par Yannick Grenzinger)
- Afficher une page mobile en moins d'une seconde (Par Florent Le Gall)
Le coin de la technique
- Les nouveautés de JPA 2.1 (Par Jean-Eudes Couignoux)
- Java Microbenchmark Harness (Par Pierre Laporte)
- Lingual : une interface SQL pour Cascading (Par Bertrand Dechoux)

Agilité

The Battle : Priorisation using MoSCoW vs Kano Analysis

Par Couthaïer Farfra

Lors d’une récente formation j’ai eu à décrire le modèle Kano, outil parmi les pratiques Agiles d’aide à la priorisation des besoins et j’avoue être plus à l’aise avec la méthode MoSCoW (Must have ; Should have ; Could have ; Won’t have), dont je trouve l’approche plus assimilable par des porteurs du besoin métier.

J’ai eu l’occasion d’échanger sur ce sujet avec Gilles Mantel (Coach Agile Xebia et membre de la FSUG) dont les explications du fonctionnement de Kano me sont alors parues très claires et pertinentes.

Aujourd’hui je vous propose de vous faire votre propre opinion, au travers de 2 vidéos, décrivant pour l’une la méthode MoSCoW (du site Agile Academy) et l’autre le modèle Kano.

A ma gauche MoSCoW	A ma droite Kano
Battle MoSCoW vs Kano
Cliquer ici pour voir la vidéo.	Cliquer ici pour voir la vidéo.

Bonne lecture et n’hésitez pas à me faire part de vos opinions sur le sujet!

5 raisons de célébrer ses erreurs au travail

Dans cet article de 2010 mais toujours d’actualité, Alexander Kjerulf commence par citer Zappos, l’entreprise dont le nom était sur toutes les lèvres la semaine dernière au scrumday après la keynote de Robert Richman. Il donne ensuite 5 raisons de célébrer ses erreurs au travail!

Quand vous célébrez vos erreurs, vous apprenez de ces dernières;
Vous ne perdez plus votre temps à couvrir vos arrières;
Quand les erreurs sont célébrées, vous renforcez votre créativité et votre innovation;
Les failles ouvrent souvent de nouveaux horizons;
Quand vous célébrez vos erreurs, vous en faites moins!

Web

Browser Diet

Cliquer ici pour voir la vidéo.

Un guide des performances front-end très complet et efficace qui va du javascript/jquery jusqu’aux sélecteurs CSS en passant par les stratégies de chargement de fichier et la compression des images:

http://browserdiet.com/

Afficher une page mobile en moins d’une seconde

Par Florent Le Gall

Un talk très instructif donné par Ilya Grigorik (ingénieur chez Google).

Pourquoi 1 seconde ? C’est le temps maximum qu’un utilisateur mobile passera à attendre le chargement d’une page sans penser à autre chose.
Pourquoi est-ce difficile ? Les réseaux mobiles ont une latence beaucoup plus élevée que les réseaux filaires, afficher une page web nécessite très souvent plusieurs requêtes.
Comment y arriver ?
- Une seule requête HTTP par page.
- Inliner le contenu essentiel à la page.
- Reporter le chargement du contenu non-essentiel dans d’autres requêtes HTTP.

Le talk en video :

Les slides : http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier.pdf

Le coin de la technique

Les nouveautés de JPA 2.1

Par Jean-Eudes Couignoux

Pour les inconditionnels des ORM, Red Hat a récemment publié la version 4.3.0.Beta1 de son très populaire framework Hibernate. Cette version apporte le support de JPA 2.1 (spécification de JEE7 pour gérer la persistance des données), et nous donne donc l’occasion de faire un point sur les évolutions futures de la norme :

le support des procédures stockées (plus de détails dans cet article : http://relation.to/Bloggers/CallableStatementSupport)
la possibilité de générer des requêtes de mise en jour et de suppression de données via l’API criteria (UPDATE et DELETE)
de nouveaux mots clefs dans la syntaxe JPQL : FUNCTION pour utiliser directement les fonctions du SGBD, ON pour définir des critères supplémentaires pour les jointures et TREAT qui permet d’utiliser des propriétés d’une sous classe de l’entité pour une jointure ou une clause where.
la possibilité d’injecter un entityManager en mode "UNSYNCHRONIZED". Celui-ci n’appellera pas la méthode flush à moins d’avoir rejoint explicitement une transaction (entityManager.joinTransaction()). Ceci permet de modifier des entités sans que les modifications soit sauvegardées en base de données.

Java Microbenchmark Harness

Par Pierre Laporte

Effectuer des tests de performance demande beaucoup de rigueur. Il en faut encore plus lorsqu’il s’agit de microbenchmarks, destinés à mesurer l’efficacité d’une méthode ou d’une classe.

Pour aider les testeurs à faire des tests probants et faire face à un grand nombre de microbenchmarks erronés sur internet, un framework de microbenchmark (Java Microbenchmark Harness) a été intégré aux outils livrés avec OpenJDK. Ce framework a d’ores et déjà été utilisé pour vérifier les performances de l’api java.util.concurrent (JSR-166) , l’inclusion de nouveaux langages dynamiques (JSR-292, InvokeDynamic) et plus récemment pour le projet Lambda (JDK 8).

Lingual : une interface SQL pour Cascading

Par Bertrand Dechoux

Cascading fait partie des solutions telles que Pig ou Hive vous permettant de grandement réduire la complexité de conception et de maintenance de vos jobs MapReduce pour un cluster Hadoop. De nombreuses surcouches ont été créées afin de se détacher de la verbosité de java mais surtout afin de fournir des abstractions encore plus élevées. Cascalog (clojure) et Scalding (scala) sont les deux exemples les plus connus. Le dernier de la famille, Lingual, vient de sortir finalement au grand jour. Il se distingue de ses ainés en proposant à ses utilisateurs un langage plus connu : le SQL. Il se place ainsi en concurrence directe avec Hive qui lui aussi propose de traiter les données par l’intermédiaire de requêtes formulées en (pseudo-)SQL. Affaire à suivre.

Seconde session de l’atelier NginX le 23 avril chez Xebia

Xebia France — Mon, 15 Apr 2013 15:42:34 +0000

Après le succès de l’atelier NginX du 9 avril, Xebia a décidé d’organiser une seconde session le 23 avril prochain.

Description:

Facebook, GitHub, Dropbox et bien d’autres arrivent à gérer des millions de connexions simultanées. Leur secret ? Le serveur http NginX ! Xebia et eNovance s’associent pour vous faire découvrir ce serveur conçu dans la lointaine Russie, dont le succès n’est plus à faire. Que vous soyez ops ou devs, cet atelier s’adresse à vous qui avez l’habitude de travailler avec Apache en front de vos applications web.

Au cours de cette soirée, nous aborderons les différentes configurations possibles grâce à NginX comme la gestion du SSL, la configuration des logs et du monitoring, le reverse proxy et le load balancing. Cette session sera également l’occasion de profiter d’un retour d’expérience de Cédric Lecomte qui est expert NginX chez eNovance.

Cet atelier, animé par Séven Le Mesle, Stéphane Moreau, Gérôme Egron et Guillaume Arnaud, aura lieu le mardi 23 avril à 19h dans les locaux de Xebia.

Vous pouvez dès maintenant vous inscrire sur Eventbrite.

Adresse :
156 Boulevard Haussmann à Paris
Bâtiment A – 7ième étage

Xebia accueille un handson du Paris Scala User Group

Jean Helou — Wed, 10 Apr 2013 11:10:59 +0000

Le PSUG vous propose un rejeu du handson scala de Devoxx le 15 avril à 19:30 dans les locaux de Xebia.

Vous n’avez pas pu aller à Devoxx ? Vous y étiez, mais la foule en délire vous a empêché de vous approcher de la salle du hands’on Scala avant que nous ne soyons contraints de fermer les portes pour raisons de sécurité ? Vous aviez choisi de ne pas faire ce hands’on mais la keynote de Martin Odersky vous a convaincu que Scala est l’avenir ?

Ne vous inquiétez pas, l’équipe des flatmapDukes organise une scéance de repêchage pour le hands’on ! Ce hands’on vous permettra de découvrir le langage Scala à travers la pratique d’une série de tests unitaires commentés. Les animateurs sont là pour vous aider ou répondre aux questions.

Ca se passera le Lundi 15 avril chez Xebia a partir de 19h, inscriptions sur l’eventbrite.

Xebia est présent au Scrum Day 2013

Ludovic Pérot — Wed, 10 Apr 2013 09:18:17 +0000

Le Scrum Day a lieu ce jeudi 11 avril 2013 au centre de conférences IBM.

Sponsor de l’évènement, Xebia y tiendra un stand où vous pourrez nous rencontrer à chaque pause. Venez discuter avec nous Agilité et Scrum !

Et nous partageons lors des différentes sessions :

A 11h, amphithéâtre Pascal, ‘Product Ownership dans le brouillard’, un retour d’expérience donné par Audrey Pedro, Gilles Mantel et Luis Diaz, Product Manager chez Emailvision ;
A 14h, Salle Longchamp, le lightning talk ‘Comment changer le monde’ de Yannick Grenzinger ;
A 15h30, Salle Convention, ‘Escapade au pays du backlog’, un atelier animé par Ludovic Perot.

Revue de Presse Xebia

Xebia France — Tue, 09 Apr 2013 07:27:36 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Agilité

8 conseils pour réussir son logiciel

Florent Lothon, du blog L’agiliste, nous offre en avant première (petits veinards) un document dans lequel il décrit ses 8 conseils pour réussir son logiciel. Rien de nouveau par rapport à ce que tout bon Agiliste se doit de connaitre, mais un petit rappel ne fait jamais de mal.

Le changement c’est simple comme une mélodie

Sur son blog Qualitystreet, Jean-Claude Grosjean propose une vidéo intéressante sur l’acceptation du changement par le jeu.

Ca se pase ici http://www.qualitystreet.fr/2013/04/08/le-changement-cest-simple-comme-une-melodie/

Web

AngularJS : Universal-irreversibility et quantum-manipulation

Par Dmytro Podyachiy

L’équipe AngularJS a annoncé jeudi dernier deux releases de leur célèbre framework web: 1.0.6 (universal-irreversibility) et 1.1.4 (quantum-manipulation).

La mise à jour de la branche stable vers 1.0.6 apporte principalement la correction de bugs et l’amélioration de la documentation.

La release 1.1.4 est beaucoup plus prolifique. Il s’agit de la branche dite instable (même si tous les tests passent) dans laquelle l’équipe ajoute des nouvelles fonctionnalités qui seront plus tard intégrées dans une future branche stable. Cette version apporte l’amelioration de la directive ngRepeat qui devient plus flexible et plus rapide, les intercepteurs http basés sur les promises, le “watch” sur les collections ainsi que le support de la génération dynamique des templates.

Mais la nouveauté la plus importante est bien sûr le tant attendu support des animations (directive ngAnimate), permettant de simplifier considérablement l’intégration des animations dans les applications Angular. Le créateur de framework, Miško Hevery, a même fait une présentation à ce sujet : la vidéo est ici.

Chrome devient blink, blink

L’actu web de la semaine est très certainement l’annonce de Google qui va migrer le moteur de rendu de son butineur dans sa version 28, pour Blink. Le géant de la recherche sera suivi par Opera qui avait changé dernièrement pour Webkit.

Blink est un fork de Webkit, il est né de la volonté de l’équipe de Chromium de permettre au navigateur Open source d’accélérer ses évolutions futures. En effet, Webkit est basé sur une architecture multi-thread différente de celle utilisée par Chromium/Chrome, ce qui entraînait pour les développeurs du projet une charge de travail supplémentaire à chaque évolution de ce dernier.

La question qui vient tout de suite à l’esprit pour les gens qui font du web reste : Qui dit nouveau moteur de rendu, dit comportements différents !?

Eh bien non répond l’équipe, du moins pas pour l’instant, car dans les premiers mois ils seront occupés par un refactoring façon caterpilar, où ils vont supprimer pas loin de 7000 fichiers et 4,5 millions de lignes de code source “legacy”. Le navigateur va donc surtout gagner en performance. Toutefois, Google assure qu’il continuera à respecter les standards du web pour les prochaines évolutions.

Cette nouvelle pour moi, est une bonne chose au vu de la crainte que commençait à engendrer l’omniprésence de WebKit. Un nouveau moteur de rendu obligera les différentes implémentation à respecter les standards si elles veulent rester dans la course. Ceci dit, on peut légitiment se demander si Google commence à faire cavalier seul dans le but d’intégrer la VM Dart qui avait été refusé à l’époque par l’équipe de WebKit, une manière pour eux d’installer leur langage sur Chrome, Android, Chrome OS et Opera…

PS : Vous pouvez aussi connaitre les vraies/fausses raisons du fork ici

Le coin de la technique

Un build incassable ?

La version 1.8.2 de git est arrivée courant Mars 2013. En plus des habituelles corrections de bug (lien vers la release note), cette version apporte un nouveau hook : le pre-push. Pour rappel, un hook est une fonctionnalité de git permettant d’éxecuter un script shell avant ou après une action : par exemple un commit.

Ce nouveau hook va par exemple nous permettre de toujours lancer un build maven avant de faire un push, et donc d’éviter l’éternelle question : Mais qui a encore cassé le build ?

Pour créer un nouveau hook sur votre projet, Il faut :

renommer le fichier pre-push.sample en pre-push
donner les droits d’exécution à ce fichier
modifier le fichier en écrivant votre script shell.

Evènements de notre communauté en France et à l’étranger

Séminaire 17 avril 2013: Karavel optimise ses opérations IT avec Deployit et AppDynamics

Par Aurélie Amet

Durant toute une après-midi, apprenez à optimiser vos Opérations IT en Automatisant vos Déploiements et en Monitorant efficacement vos Applications en Production.

Encore des places disponibles

Retour sur Devoxx France 2013

Benoît Lemoine — Fri, 05 Apr 2013 10:03:00 +0000

Devoxx France 2013 s’est achevé en cette veille de week-end de Pâques 2013 et on peut dire que, pour cette deuxième édition française, l’essai a été transformé. Durant trois jours, les universités, conférences et autres quickies se sont enchainés à un rythme frénétique sur des sujets aussi variés que Java, les langages alternatifs, le web, Big Data ou encore l’agilité. En effet, cette édition se voulait une ouverture du monde javaïste vers l’écosystème dont il dépend.

Cet article se veut un compendium des impressions des Xebians au terme de ces trois jours.

Programmation Fonctionnelle

La keynote d’ouverture du jeudi matin par Martin Odersky semble donner le ton de ce Devoxx : il va y avoir de la programmation fonctionnelle, beaucoup de programmation fonctionnelle. Cependant, M. Odersky se fait l’avocat d’une approche mixte objet/fonctionnel, afin de tenter de tirer le meilleur des deux mondes. Le programme ne dément pas ce ressenti, au cours de ces deux jours on entendra parler de foncteurs, de monades, de morphismes, mais surtout, et c’est le plus important, on apprendra à utiliser ces objets aux noms barbares. Et, même si Scala se tient finalement sur le haut du podium comme langage de démonstration, on entendra aussi parler de Clojure, de Java 8 et même de Typescript ! Et c’est justement en parlant de programmation fonctionnelle coté client que M. Odersky lâche une bombe au cours du B.O.F du Paris Scala User Group : un compilateur Scala vers Javascript est en cours d’écriture.

Web

Les applications et architectures Web au sens large sont un autre des axes majeurs de cette édition de Devoxx. En effet, on entendra beaucoup parler de framework Web (coté serveur et coté client), de Javascript, de CSS et d’architecture favorisant la distribution des composants sur le Web, sujet dont Habib Guergachi est un virulent avocat, comme il l’a démontré au cours de sa keynote du vendredi matin. Plusieurs API Javascript peu connue sont présentées, tel que la gamepad API permettant de communiquer avec une manette de jeu au sens large (une guitare de guitar Hero ou un tapis de danse étant des "manettes de jeu") ou encore des API Web permettant la capture et l’analyse vocale. Coté serveur, Matt Raible a mis à jour sa célèbre comparaison de framework Web et donne à l’heure acutelle toujours Grails gagnant, talonné de près par Play. Il fait malheureusement le choix de ne pas différencier les versions 1 et 2 de Play Framework.

Divers

Les langages alternatifs étaient également à l’honneur cette année puisque que nous avons eu le droit à des sessions sur Ceylon, Groovy, Scala, Fredge, Clojure et Golo. Ce qui confirme la tendance à toujours miser sur la Java Virtual Machine tout en cherchant des alternatives plus productives que Java. Comme à la session précédente, Devoxx a été l’occasion pour nous autres développeurs de ~~nous ré-émerveiller~~ ~~de diodes qui clignotent~~ voir des systèmes embarqués avec les multiples démonstrations de Raspberry Pi,de Beaglebone et autre Arduino, ces petites cartes permettant à tout bon geek de bricoler des solutions de domotique ou encore de faire tourner WebSphere 8.5 … si si c’est possible .

Les GPU et les Intel Xeon Phi ont fait parler d’eux pour le calcul distribué. Murex a par exemple fait un retour d’expérience sur une implémentation GPU/CPU de la Méthode de Monte-Carlo qui leur a permis de diminuer leur temps de calcul par un facteur 100 par rapport à un calcul pure CPU. Cette transition à été effectué en trois mois grâce à OpenCL,

Autres

Certains sujets ne touchaient pas directement notre métier de développeur, mais n’en restaient pas moins intéressants pour s’ouvrir à d’autres univers. Par exemple, la keynote d’ouverture présentée par Clarisse Herrenschmidt, concernant l’histoire des signes et de leur sens, était une présentation de sémiologie très intéressante, y compris pour un parterre de développeurs peu habitués à ce sujet. Dans la même veine, la conférence de Michaël De Smet au sujet du mécanisme de brevet logiciel européen était très enrichissante de par son objectivité sur un sujet qui est souvent, et pas complétement à tort, diabolisé.

Conclusion

Comme l’année dernière, ces trois jours très intenses intellectuellement ont été une occasion inouïe, pour nous français, de découvrir les tendances actuelles dans le monde du développement logiciel et d’en tirer des enseignements souvent applicables directement sur nos projets. Et pour les malchanceux qui n’ont pas pu être présents, sachez que le site Parleys a été totalement refondu en HTML5 (et vaut sacrément le détour) et que l’ensemble des sessions filmées à ce Devoxx France seront en accès gratuit, comme nous l’a annoncé Stephan Janssen, père de Devoxx, lors de sa keynote.

Un grand merci à l’équipe d’organisation de Devoxx et à l’année prochaine !

Revue de Presse Xebia

Xebia France — Tue, 02 Apr 2013 07:30:03 +0000

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Web

Sortie de Ember.js RC2

La nouvelle release candidate du framework MVC JavaScript Ember.Js, la 1.0-RC2, vient d’apparaitre. Cette dernière mouture au delà de corriger des bugs, et compléter la documentation, apporte des améliorations comme :

la possibilité d’accéder a des controllers or du package "App" avec la syntaxe "pacakage/controller". Ainsi pour accéder a un controller "Blog.PostController" dans le helper render vous pourrez faire {{render ‘blog/posts’}} ;
la capacité d’injecter un modèle différent de celui de base dans le helper render ;
l’extraction automatique du model des ObjectController quand ceux-ci sont passer en paramètre d’une action ou d’un linkTo ;
le support de JQuery 2.0. Pour rappelle JQuery 2.x ne supporte internet explorer qu’a partir de la version 9 ;
l’ajout d’une nouvelle view Ember.LinkView pour l’ajout de balise a avec un comportement de linkTo intégré ;
une propriété ENV.LOG_VERSION pour activer/désactiver les logs de version au démarrage ;
une amélioration de l’initialisation de démarrage. Ce qui entraine la dépréciation de App.initialize au profit de App.deferReadiness et App.advanceReadiness.

Annonce officielle

Jongo .4 est disponible

Par Benoît Guérout

Par Yves Amsellem

Jongo — pour requêter en Java comme dans le shell Mongo — fête le retour du printemps avec une release, la 0.4.
Au menu, de nombreuses pull requests et raffinements proposés par la communauté :

Update et Insert acceptent des objets en paramètres — update.with(pojo), insert(pojo, pojo)
Les Command peuvent être jouées — runCommand(..).as(pojo)
@id est devenu un alias pour simplifier @JsonProperty("_id")
@ObjectId permet de manipuler tous les ObjectId en String
Et de nombreuses autres surprises

N’attendez plus pour le télécharger sur maven central et commencer l’exploration de sa documentation.
Un fois n’est pas coutume, laissez votre feedback sur la mailinglist.

Mozilla et Epic porte le célèbre moteur de jeu Unreal 3 sur le navigateur

En combinant WebGL, Emscripten (un outil permettant de compiler des applications C+ vers Javascript) et la toute nouvelle librairie asm.js, le portage d’Unreal 3 peut, selon Mozilla, rivaliser avec les performances natives. C’est une excellente nouvelle pour le futur du web et c’est la preuve qu’il est possible de faire des application de plus en plus riche sur un navigateur.

L’annonce officielle est ici: https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/

Expérience utilisateur

L’expérience utilisateur est une communauté de pratiques