Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activités liées au développement d’applications informatiques en entreprise.

Agrégateur de flux

Le 24 juin, le Meltdown bar accueille la League of Mobile

 Le 24 juin prochain, dans une atmosphère 100% gaming, le pub Meltdown Paris (11ème) ouvre ses portes à la communauté Android et iOS !

 

League of Mobile, qu’est ce que c’est ? C’est une soirĂ©e mobile sortant du cadre professionnel ! Cet afterwork a pour but de rassembler des dĂ©veloppeurs passionnĂ©s de la communautĂ© Android et iOS pour un battle de questions dans un lieu 100% gaming, le Meltdown Paris (11ème). Ce sera Ă©galement l’occasion d’Ă©changer sur ses connaissances mobiles.


Xebia aura le plaisir d’offrir aux participants la première tournĂ©e de boissons ainsi que des plateaux apĂ©ritifs

Que la guerre commence Dès 19h, le Meltdown Paris vous accueillera ! Ce contest prendra la forme d’un Quiz et se dĂ©roulera en trois manches.

 

Pour en savoir plus et vous inscrire, rendez-vous sur le site de la League of Mobile A très vite !
Catégories: Blog Société

Demain, OCTO accueille le meetup Puppet

OCTO accueille le meetup Puppet parisien, le mardi 9 juin à 19h.

Au programme, une présentation sur le Software Craftmanship et sur comment tester son code Puppet.

C’est aussi et surtout l’occasion d’échanger avec des gens passionnés par Puppet.
Donc venez avec vos questions et vos retours d’expĂ©rience, on partagera ensemble autour d’un buffet !

Pensez à vous inscrire et notez bien l’adresse :
OCTO Technology
50 avenue des Champs Elysées (métro Franklin Roosvelt) – 5ème étage

 

Edit :
la vidéo est en ligne http://youtu.be/Q2opUJXX_VY
slides https://speakerdeck.com/alexraoul/le-software-craftmanship-quelle-signification-pour-du-code-puppet
et repo https://github.com/alex-raoul/minbeaker-apache_pfs

Catégories: Blog Société

Lundi 15 juin 2015 - Soirée Hibernate !

JUG Toulouse, Groupe d'utilisateur Java - ven, 06/05/2015 - 19:30

Attention adresse différente: Epitech Toulouse 14 rue Claire Pauilhac (Inscrivez vous).

On n'est pas que des cobayes: ORM et NoSQL sont-ils solubles? (Emmanuel Bernard)50min

Vous voulez savoir ce que la persistance dans du NoSQL implique dans une architecture Java?

Java est le fief de l'Orienté Objet où les ORMs poussent comme des champignons. Est-ce que les ORMs apportent encore des bénéfices dans le monde du NoSQL et de la persistance polyglotte? On discutera aussi le pourquoi et le comment du design de données dans le NoSQL.

Comme dans l'émission, On n'est pas que des cobayes, on tentera de faire cohabiter ORMs et NoSQL en y analysant le résultat. Parmi les défis relevés, on pourra y voir:

  • Peut on survivre avec un seul produit NoSQL ?
  • NoSQL implique-t-il des cauchemardas de duplications de donnĂ©es?
  • JPA et NoSQL c'est comme faire rentrer une pièce ronde dans un trou carrĂ©?
  • Les ORMs ne peuvent pas abstraire proprement les modèles de donnĂ©es NoSQL?
  • Les ORMs c'est comme la nitro, ça booste les performances... ou pas?
  • Abstraire les langages de requĂŞtage NoSQL, c'est trop difficile?.
  • Sans l'accès natif aux APIs NoSQL, point de salut?
  • Les ORMs n'apportent pas vraiment de valeur dans un monde NoSQL?

Venez discuter et débattre.

Hibernate BoF 20mins (Emmanuel Bernard)

On prendra le reste du temps pour discuter des autres projets Hibernate:

  • Qu’est-ce qu’Hibernate Search, quels sont les nouveautĂ©s?

  • Qu’est-ce qui se passe du cĂ´tĂ© d’Hibernate ORM?

  • Hibernate Validator, Bean Validation, quĂ©sako?

  • [insĂ©rer votre question ici]?

On fera ~ 55 min pour la première présentation et ~ 20 mins pour la BoF si ça rentre pour vous.

Multitenancy avec CDI/JPA et Spring/Hibernate (Florian Beaufumé 30min)

Les applications multi-clients, par exemple en cloud, isolent souvent les données de leurs différents clients. Il existe plusieurs stratégies de mise en oeuvre dont la multitenancy qui permet à une unique instance applicative de servir dynamiquement des données isolées de clients différents. Nous allons présenter le principe de multitenancy, ses variantes et montrer deux implémentations Java, l'une à base de CDI et JPA, l'autre à base de Spring et Hibernate.

Bio :

Emmanuel Bernard : https://emmanuelbernard.com/bio/

Florian Beaufumé est un architecte logiciel et spécialiste Java et web de 17 ans d'expérience. Il a créé sa société, Adeliosys, en 2007 et est depuis un consultant indépendant. Il a travaillé pour des grands comptes, des éditeurs de logiciels, des SSII et des startups dans les domaines tels que les banques, les assurances et l'aéronautique.

Catégories: Association

OCTO ACADEMY lite sur les Big Data le 11 juin

Jeudi 11 Juin de 19h Ă  21h, OCTO ACADEMY lite propose aux Ă©tudiants une formation gratuite sur les Big Data. Inscrivez-vous vite !

Des Small Data aux Big Data : méthodes et technologies

L’importance de la donnée et les informations que nous pouvons en tirer est en train de révolutionner notre monde !

Quelles valeurs ont les données, comment créer de la valeur avec les données ?

De plus en plus massives et hétérogènes, l’exploitation de ces données induit de faire appel à de nouvelles méthodes et technologies qui changent notre manière de percevoir et de comprendre notre environnement.

Comment les changements en termes de moyens de stockage, de capacitĂ© de calcul et de mĂ©thode d’analyse des donnĂ©es donnent une nouvelle place aux donnĂ©es dans notre quotidien ?

De la statistique au machine learning, en passant par les nouvelles architectures big data, Benjamin et Michel vous feront découvrir le monde la data science contemporaine, qui préfigure l’intelligence artificielle de demain.

Benjamin est Expert en nouvelles technologies Big Data et Michel, Data scientist et statisticien de formation.

Tous deux sont Consultants chez OCTO Technology.

Pour vous inscrire, rendez-vous sur le site d’OCTO.

Articles suggested :

  1. – Vivez l’expĂ©rience formation avec OCTO
  2. Savoir utiliser & configurer Elasticsearch
  3. Les Géants du Web

Catégories: Blog Société

Xebia TV 2.0 est en ligne! Retour sur ce projet…

Xebia-TV-logo-final

La nouvelle version de Xebia TV est désormais accessible ici.

Cette mise Ă  jour a pour objectif d’amĂ©liorer l’expĂ©rience utilisateur grâce Ă  un meilleur design et un nouveau player Youtube personnalisĂ©.

L’arrivĂ©e de cette version est aussi l’occasion de revenir ensemble sur ce projet et les solutions techniques que nous avons retenues pour sa rĂ©alisation.

Petit retour en arrière…

Pour ceux qui ont manquĂ© la mise en service de Xebia TV, celle-ci a eu lieu le 29 septembre 2014. L’idĂ©e Ă  l’origine de ce projet Ă©tait de faciliter la vie des Xebians qui ne pouvaient pas assister en personne Ă  toutes les sessions de XKE ou de tech events. Ainsi, Xebia TV leur permettrait de les revoir Ă  la demande et mĂŞme d’interagir en live avec les animateurs par chat.

Une première version de l’application vit le jour au cours d’un hackathon que nous avions organisĂ© dans le cadre d’un XKE. Suite Ă  ce hackathon, nous avons continuĂ© Ă  travailler dessus. Le projet gagnant en maturitĂ©, la dĂ©cision fut prise d’en ouvrir l’accès au public pour arriver Ă  sa première mise en production.

Depuis, nous avons effectuĂ© pas mal de refactorings et repensĂ© l’ergonomie et la conception de l’application pour vous prĂ©senter cette nouvelle version.

Nos choix techniques

xebiatv

  • Organisation des fichiers sources en DDD.
  • CotĂ© front-end :
    • Application : AngularJS, Less et l’API de Google pour crĂ©er un player Youtube personnalisĂ© que nous avons encapsulĂ© en directive rĂ©utilisable ;
    • Build  : Gulp et Bower.
  • CotĂ© back-end :
    • Application : NodeJS, Express, Bluebird et SuperAgent ;
    • Stockage : Les vidĂ©os sont actuellement hĂ©bergĂ©es et indexĂ©es sur Youtube.
  • Industrialisation :
    • Tests : Karma, Mocha, Sinon et Chai ;
    • Integration continue : Codeship ;
    • Plateforme : Elastic Beanstalk
La mise Ă  jour 2.0
  • Ajout d’une page d’accueil :

    • PrĂ©sentation de Xebia TV
    • Notification et liens vers le live en cours
    • Affichage du programme des lives prĂ©vus pour la journĂ©e
    • Liens vers les vidĂ©os les plus populaires
  • Utilisation d’un player Youtube personnalisĂ© :

    • Look & feel original
    • Compatible HTML5 selon le navigateur utilisĂ©
  • Écran Live :

    • Remplacement des images affichĂ©es Ă  la place du player si aucun live n’est en cours
    • Correction d’un bug empĂŞchant le chat de fonctionner correctement
  • Écran V.O.D. :

    • Les descriptions accompagnant les vidĂ©os sont formatĂ©es pour une meilleure lisibilitĂ©
    • AmĂ©lioration graphique des vignettes des vidĂ©os
    • Il est dĂ©sormais possible d’accĂ©der Ă  une vidĂ©o spĂ©cifique en copiant/collant son url dans la barre d’adresse du navigateur
  • Refontes techniques :
    Cela ne vous intéressera que modérément mais nous autres, les développeurs, nous aimons le gain de maintenabilité obtenu par ces refontes.
    En rĂ©sumĂ©, ces refontes nous ont permis d’adopter un design DDD, d’intĂ©grer des librairies comme Bluebird/SuperAgent et de nettoyer le code source d’origine. Pour rappel, dans le contexte du hackathon, tous les membres de l’Ă©quipe n’Ă©taient pas des experts AngularJS/NodeJS. Après tout, l’intĂ©rĂŞt de ce hackathon Ă©tait aussi de dĂ©couvrir des technologies que l’on n’avait pas forcĂ©ment l’habitude de manipuler.

Pour finir, merci à Sarah Buisson, Mathieu Breton et Jérémy Vinai pour la réalisation de cette version.

Catégories: Blog Société

Ne mettez pas tous vos glands dans le même panier – Soirée Apache Flink le 17 Juin 2015

Alpes JUG - ven, 06/05/2015 - 10:58

Le mercredi 17 Juin l’AlpesJUG a le plaisir d’organiser une soirĂ©e autour d’Apache Flink.

Apache FlinkPrésentation

Apache Flink est un des nouveaux projet de la fondation Apache, qui permet le traitement de données en flux ou en batch. Au cours de cette séance, nous vous présenterons le fonctionnement de Flink au travers de quelques exemples et illustrerons les points forts d’Apache Flink : Rapide, Expressif, Simple à utiliser. Nous rentrerons un peu plus dans le cœur du système pour voir ses points forts et les perspectives qu’il semble ouvrir.
Nous ne rentrerons pas dans le détails de Gelly (Graph processing API) ni de la Libraire dédiée au Machine Learning.

Les conférenciers Stéphane Thiers

Stéphane Thiers

Jerome Blachon

Jerome Blachon

Laurent Tardif

Laurent Tardif

Laurent Tardif : Il a joué avec Lucène et les systèmes de search chez Kelkoo, avant d’approcher Hadoop et Pig chez Yahoo.
Aujourd’hui il adore jouer aux Légos, aux Kapla et donner son avis, c’est pour cela qu’il accompagne les équipes dans leur transformation : Agile, Devops, CI, BigData dans un esprit Agile … La rencontre avec Flink lui a permis de faire cohabiter ces 2 mondes.
Stéphane Thiers est expert .NET / C# / BDD chez Persistent Systems France.Il a passé ses 10 dernières années à développer des logiciels chromatographiques en environnement agile distribué.
Jerome Blachon, Aujourd’hui développeur .NET pour un logiciel de chromatographie. Passé par Dassault Systèmes et l’INRIA.

Inscriptions

Inscriptions : https://plus.google.com/u/0/events/c91p93colm7idjt8r7srl07dnr0
Cette soirée se déroulera sur le campus à la Maison Jean Kuntzman le Mercredi 17 Juin à partir de 19h00.

Catégories: Association

Node for API: Architecture et Ecosystème d’Express et Hapi

Dans mon prĂ©cĂ©dent article j’exposais les raisons pouvant nous amener Ă  opter pour la plateforme Node.js pour rĂ©aliser des API REST. PlutĂ´t que de rĂ©implĂ©menter la roue au-dessus des fonctionnalitĂ©s bas niveau du coeur de Node, le choix d’un framework s’impose.

Au sein de l’Ă©cosystème Node, deux frameworks tiennent le haut du pavĂ© pour la rĂ©alisation d’API: express et hapi. Dans cet article nous allons Ă©tudier leur architecture ainsi que leur histoire, leur dynamique et communautĂ©.

Les Concurrents

Ces deux frameworks se dégagent quant à la réalisation de services REST.
Le premier, Express est plus orientĂ© framework d’application Web.
Quant au second Hapi, il est – comme son nom le suggère – axĂ© sur la rĂ©alisation d’API.

Pourquoi ce choix?

Hapi et Express ont tout d’abord Ă©tĂ© sĂ©lectionnĂ©s en raison de leur importance dans l’Ă©cosystème, et de leur utilisation dans des projets d’envergure, Ă  dimension industrielle.
De plus ceux-ci ont une approche bien diffĂ©rente, qu’il est intĂ©ressant d’Ă©tudier.
Ceci est en partie liĂ© au fait qu’Hapi est API centric, alors qu’Express est plus orientĂ© Framework Web.

Nous avons Ă©cartĂ© dans cette Ă©tude les frameworks construits au-dessus d’express, ceux-ci sont très orientĂ© MVC et introduisent des conventions pour libĂ©rer le dĂ©veloppeur de nombreuses dĂ©cisions. Les plus consĂ©quents dans cette catĂ©gorie sont Kraken, Sails, Locomotive ou Loopback.
Parmi les autres recalĂ©s, il y a Koa, celui-ci Ă©tant une revisite d’express Ă  la sauce Es6 tirant partie des gĂ©nĂ©rateurs, et Restify qui a quelques similaritĂ©s avec Express tout en Ă©tant plus API centric, sans avoir une portĂ©e comparable Ă  Hapi.

Rentrons maintenant dans le vif du sujet, et commençons par Express.

Quelques Statistiques

Avant de rentrer dans le vif du sujet, voici quelques statistiques pour se faire une première idĂ©e de l’aura des deux frameworks.

MĂ©triques Express Hapi Github stars 19k 4,2k Github fork 3,6k 0,6k StackOverflow 15k 180 Contributor 177 114 Github require ~360k 6k

Que veulent dire ces chiffres? Quelle interprétation en tirer? Difficile de dire quoi que ce soit sans avoir un idée du contexte et de la portée des frameworks.
Par exemple ceci exprime que les deux frameworks n’ont pas la mĂŞme anciennetĂ©, ce qu’illustre ce google trend. Une analyse qualitative des deux frameworks est nĂ©cessaire, tant en terme d’architecture et d’Ă©cosystème. C’est le but de cet article.

Les présentations

Histoire de satisfaire son (Ă©ventuelle) envie de voir du code – et avoir un premier contact avec les deux frameworks – voici ici deux exemples minimaux tirĂ©s des documentations officielles.

Hello Express
var express = require('express');
var app = express();

app.get('/', function(req, res) {
    res.send('hello world');
});

var server = app.listen(3000, function () {
    console.log('Example app listening at http://%s:%s',
                server.address().address, server.address().port);
});
Hello Hapi
var Hapi = require('hapi');

var server = new Hapi.Server();
server.connection({ port: 3000 });

server.route({
    method: 'GET',
    path: '/',
    handler: function (request, reply) {
        reply('Hello, world!');
    }
});

server.start(function () {
    console.log('Server running at:', server.info.uri);
});
Express

Express est un cadriciel à la fois simple et flexible; la documentation officielle le décrit comme un minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

Architecture

S’il fallait rĂ©sumer Express, je dirais que c’est un micro-framework bien conçu au dessus des fonctionnalitĂ©s web du serveur http de node.js, une API qui se charge principalement de router les requĂŞtes aux bons middlewares.

Le framework n’est pas opiniâtre, il n’impose pas de structure rigide. Il ne s’appuie pas sur le principe Convention over Configuration, Ă©tant flexible tant pour la structure que pour les middlewares utilisĂ©s.
En effet un des motos d’express est @batteries not included. C’est l’Ă©cosystème de middlewares construit autour de connect puis express qui apportent les fonctionnalitĂ©s.

Middleware

Le concept de middleware prĂ©date express et a Ă©tĂ© introduit dans node par connect. Attention, middleware n’est pas Ă  interprĂ©ter au sens large d’intergiciel, mais dans le sens introduit entre autres par Rack, une interface ruby pour le serveur Web.

Le principe est d’Ă©viter d’avoir un handler monolytique qui se charge de gĂ©rer l’intĂ©gralitĂ© d’une requĂŞte. A la place on va utiliser une collection de handlers qui se chargent de faire un traitement spĂ©cifique, et qui font ĂŞtre chaĂ®nĂ©s, un peu comme une pipeline unix.

Concrètement, un middleware est une fonction avec trois arguments. Les deux premiers items req et res sont là pour accéder aux informations de la requête, et pour manipuler la réponse. Le dernier est une callback next pour éventuellement passer la main au prochain middleware de la chaine.
Voici un exemple simple de middleware, qui se chargera juste de logger l’heure courante, avant d’invoquer le prochain chaĂ®non.

function (req, res, next) {
  console.log('Time:', Date.now());
  next();
}

Construire un serveur revient donc Ă  chaĂ®ner les middlewares, prĂ©traitements, pour accumuler des informations avant de traiter les diffĂ©rents cas, selon notre logique mĂ©tier. Ainsi on a des middlewares pour gĂ©rer l’authentification, logger les requĂŞtes, parser les cookies et corps des requĂŞtes, rĂ©gler certains headers de la rĂ©ponse et ainsi de suite jusqu’Ă  l’Ă©mission de la rĂ©ponse.

 Cycle de vie Requete express

Attention par contre, l’ordre de ces middlewares est crucial et critique, il faut donc bien les chaĂ®ner dans l’ordre qu’il convient. De plus on Ă©vitera de mĂ©langer la logique mĂ©tier avec des considĂ©rations transverses, ou liĂ©es Ă  HTTP comme la journalisation, ou la gestion du cache. En rĂ©alitĂ©, il y a deux grand types de middlewares, ceux pour gĂ©rer le cas nominal, et ceux pour gĂ©rer les cas d’erreurs. On bascule en mode erreur dès qu’un middleware en appelant next avec un argument, l’erreur. A cela s’ajoute les handlers de requĂŞtes placĂ©s en bout de chaĂ®ne qui ne manipulent que la requĂŞte et la rĂ©ponse.

Express middlewares Routage et sous applications

Le routage est le coeur de la fonctionnalité apporté par express:
Il s’agit d’associer Ă  une route particulière – c’est Ă  dire Ă  des pattern d’url et des verbes http particuliers – les middlewares et handlers qui se chargeront de traiter les requĂŞtes. Ce routage n’est pas restreint Ă  des routes statiques, on peut avoir recours Ă  des routes dynamiques ce qui permettra de rĂ©cupĂ©rer des variables de chemin (pathvariables). L’algorithme de routage est assez simple, pour chaque requĂŞte entrante on va suivre la chaĂ®ne de middlewares, et exĂ©cuter seulement ceux dont la route va s’appareiller avec la mĂ©thode et l’url demandĂ©es.

Par consĂ©quent, il faut prendre soin de mettre les plus spĂ©cifiques avant les plus gĂ©nĂ©rales sachant que la première route qui matche l’emportera.

A noter qu’il est aussi possible de construire des sous-applications, des sous routeurs que l’on viendra monter sur son serveur final. Ceci permet ainsi de dĂ©couper son api et de concevoir des composants rĂ©utilisables comme par exemple un module d’administration.

Ecosystème Historique

Express est le plus ancien des deux frameworks, d’ailleurs son dĂ©veloppement a commencĂ© en 2009 dès les dĂ©buts grand public de node. Un premier jalon en 2010, une beta en juillet, suivie de plusieurs release candidates jusqu’en novembre avec la publication de la  v1.

Construit Ă  l’origine sur connect et largement inspirĂ© par Sinatra (Sinatra inspired web development framework), il s’est vite Ă©tabli comme le framework web de rĂ©fĂ©rence sur la plateforme node. Son principal developpeur fut tj, TJ Holowaychuk travaillant Ă  VisionMedia notamment Ă  l’origine des bibliothèques nodejs superagent et supertest. Dernièrement le flambeau a Ă©tĂ© repris par @dougwilson, Tj se concentrant sur go, et transfĂ©rant le dĂ©pot Ă  StrongLoop (compagnie centrĂ©e sur Node Ă  l’origine LoopBack un des frameworks construit sur express).

Rythme de développement

Express est actuellement en version 4, la version 3 Ă©tant toujours maintenue. Le passage de la 3 Ă  la 4 correspond Ă  la suppression de connect en tant que dĂ©pendance, et de l’extraction des middlewares dans des modules spĂ©cifiques. Chaque passage de version majeure est documentĂ© Ă  la fois avec la liste des nouvelles fonctionnalitĂ©s (v3, v4) et un guide de migration (v2 vers v3, v3 vers v4).

Une version 5 est en préparation sur sa propre branche. La release RTM étant prévu pour ce mois de juillet, en attendant les versions alphas sont déjà disponible sur npm, npm install express@5.0.0-alpha.1. Pour plus de détails, on se réfèrera à la Pull Request #2235 qui détaille les changements et améliorations prévues.

Communauté

De part sa philosophie nodesque, batteries not includes express apporte un nombre limitĂ© de fonctionnalitĂ©s. Celles-ci sont apportĂ©es par les middlewares qui ont Ă©tĂ© dĂ©veloppĂ©s en grand nombre. Ceux-ci vont faciliter les diffĂ©rents aspects que peut nĂ©cessiter la bonne rĂ©alisation d’une appli Web et/ou API REST et rĂ©pondent aux diffĂ©rents besoins. Les principaux sont rĂ©pertoriĂ©s sur le site officiel.

La communautĂ© d’express est assez consĂ©quente. Il s’agit du framework MVC le plus populaire ce qui se constate Ă  la fois par le nombre d’Ă©toiles du projet, et de questions stackoverflow. D’ailleurs le E de MEAN du nom de la stack javascript – annoncĂ© par certains comme le successeur de LAMP – correspond Ă  Express.

Niveau communication, en plus du site vitrine, qui contient aussi tutoriel et documentation, le projet est bien entendu hĂ©bergĂ© sur github. Pour engager la communautĂ©, il existe un google group dĂ©diĂ© ainsi qu’un channel irc #express et un chat gitter. De nombreux cours sont disponibles en lignes, dont celui de nodeschool expressworks.

Hapi

Hapi est un rich framework for building applications and services.
hapi enables developers to focus on writing reusable application logic instead of spending time building infrastructure.

Architecture

La philosophie d’hapi se distingue d’express avec des choix que l’on pourrait qualifier de radicalement diffĂ©rents. En effet, Hapi abstrait le serveur HTTP node. Il introduit un cycle de vie des requĂŞtes et propose une autre architecture pour favoriser l’isolation des diffĂ©rents composants de l’application et ainsi Ă©viter les impacts inattendus.

Configuration over code

Hapi a une approche centrée configuration.
Mis à part la création des handlers de requête et leur logique métier, construire le serveur reviendra à configurer les différentes propriétés et fonctionnalités du serveur, les plugins chargés, et surtout les différentes routes de notre API.

Cycle de vie Hapi

La spĂ©cification de route en hapi est le meilleur exemple pour illustrer cette diffĂ©rence d’approche avec express. Dans ce dernier, les routes sont ajoutĂ©es via diffĂ©rentes mĂ©thodes pour chaque verbe http. A contrario, l’api d’Hapi offre une seule mĂ©thode qui va prendre en argument un object de configuration dĂ©crivant la route.

// express
app.get('/my-route', myHandler)
// hapi
server.route({path:'/my-route', method: 'GET', handler: myHandler})

On retrouvera cette approche d’objets de configuration Ă  la fois pour le serveur et les diffĂ©rents plugins que l’on chargera.

Les avantages de cette approche sont nombreux. Ceci permet notamment Ă  de nombreuses prĂ©occupations comme les performances, la robustesse et la sĂ©curitĂ©, d’ĂŞtre traitĂ©es nativement sans compromettre la flexibilitĂ©. Ceci permet aussi grâce Ă  la rĂ©flexion de produire facilement de la documentation, de gĂ©nĂ©rer du code. On peut aussi facilement configurer le comportement du serveur dans les diffĂ©rents environnements en changeant juste les paramètres.
Ainsi Ă  titre d’exemple, on pourra aisĂ©ment dĂ©sactiver la mise en cache en production, ne pas activer certaines surcouches comme la journalisation des requĂŞtes pour les test. Ceci permet aussi de dĂ©ployer plusieurs version de l’application, de facilement mettre en place un système de feature flipping ou de gĂ©rer l’Ă©volution de certaines parties du serveur.

Architecture de plugin et modularization

Hapi s’est construit en rĂ©action Ă  un des problèmes d’express, le fait qu’il ne passait pas Ă  l’Ă©chelle d’un point de vue organisationnel. En effet, express permet de construire une API très rapidement, cependant ceci se fait au dĂ©pend de la maintenabilitĂ©. Notamment le montage des routes est un goulot d’Ă©tranglement oĂą il faut coordonner les changements au risque de grosses surprises. Hapi et son système de plugin ont Ă©tĂ© conçus pour Ă©viter cela et offrir un cadre pour Ă©crire des applications rĂ©utilisables de façon très modulaire.

Un plugin est un composant logique, rĂ©utilisable, et indĂ©pendant apportant un certain nombre de fonctionnalitĂ©s aux serveurs. Pour dĂ©velopper les fonctionnalitĂ©s transverses, qui s’appliqueront Ă  l’ensemble des requĂŞtes, hapi donne un certain nombre de points d’entrĂ©e sur le traitement de la requĂŞte.
PlutĂ´t que de concevoir le traitement d’une requĂŞte par une suite de fonctions dĂ©finies par l’utilisateur, Hapi dĂ©finit un cycle de vie de la requĂŞte, avec ses points d’extension associĂ©s. C’est sur ces Ă©vĂ©nements – comme la rĂ©ception de la requĂŞte, la fin de l’authentification, le dĂ©but d’Ă©mission de la rĂ©ponse – que l’on peut accrocher des traitements. Pour ce faire il s’appuie sur l’api d’EventEmitter de Node.js.

hapi-hooks

Il existe un bon nombre de plugins « natifs », dĂ©veloppĂ©s par l’Ă©quipe derrière hapi, et reconnaissables (ou pas) Ă  leur nom assez original. Parmi les quasi indispensables il y a Joi pour la validation de schĂ©ma, Good pour le monitoring et logging (avec une extension pour le rejeu), aussi tv pour le debuggage intĂ©ractif, Bell pour l’authentification tierce.

Les plugins ne se rĂ©duisent pas aux fonctionnalitĂ©s transverses, c’est un cadre pour dĂ©couper le code, et c’est d’ailleurs la manière recommandĂ©e de structurer son application. En terme de structure, Hapi offre aussi un moyen d’injecter des dĂ©pendances, de mettre Ă  disposition des objets et fonctionnalitĂ©s Ă  l’ensemble des parts du serveur.

Une bonne synergie

Les deux approches de configuration et de plugin se nourrissent mutuellement. Ainsi Hapi offre un cadre que l’on pourra facilement Ă©tendre et configurer, cadre offrant nativement sĂ©curitĂ© et robustesse et nombre de fonctionnalitĂ©s que l’on attend d’un serveur web: cache, authentification, validation, rĂ©flection….

De part l’aspect configuration, et le fait d’avoir des handlers en un seul bloc – en faisant abstraction des points d’extension bien dĂ©finis – le routage est totalement dĂ©terministe. Ceci est une grande force d’Hapi, et surtout cela rend les collisions de routes dĂ©tectables. Le cas prĂ©sent le serveur ne dĂ©marrera pas, et affichera une erreur explicite alors que dans express ce problème potentiel est totalement silencieux et invisible, un vrai « Middleware hell ».

Ecosystème Historique

Hapi est nĂ© bien plus rĂ©cemment au Lab Walmart avec une Ă©quipe dĂ©diĂ©e sous la houlette de Eran Hammer aka hueniverse. Le projet a commencĂ© en aoĂ»t 2012, nĂ© des frustrations et limitations de l’utilisation des outils existants. N’ayant pas trouvĂ© un framework amĂ©liorable dans le sens souhaitĂ©, l’Ă©quipe est partie from scratch, reprenant quelques bonnes pratiques mises en place sur un prĂ©cĂ©dent projet, sledge.
Le principal grief contre express est le passage Ă  l’Ă©chelle d’un point de vue organisationnel. Le montage des routes est un goulot d’entrainement oĂą il Ă©tait frĂ©quent que des membres d’Ă©quipe se marchent les uns sur les autres en insĂ©rent de nouvelles routes.

Dans un premier temps basĂ© sur express en proposant une abstraction au dessus, Hapi s’en est rapidement dĂ©tachĂ©. Après une sĂ©rie de version mineures, la première version majeure est sortie en avril 2013 faisant suite Ă  la V0.13. Hapi passe avec brio son baptĂŞme de feu lors du black friday 2013 Ă  Walmart, sur lequel Eric Hammer est revenu dans quelques talks et entretiens.

Une v2 est sortie en Jan 2014, suivant la v1.20 en raison de changements incompatibles pour raisons de sĂ©curitĂ©. S’en suivent au cours de l’annĂ©e 2014 de nombreuses versions majeures, en raison de changements non retrocompatibles, occasionnĂ©s par l’extraction de nombreuses fonctionnalitĂ©s dans des modules sĂ©parĂ©s et d’une refonte d’api.

Rythme de développement

Ces 8 versions majeures – 7 versions majeures en 10 mois – en un laps de temps si court peuvent donner l’impression d’une certaine instabilitĂ©. Cependant Hapi est jeune, la SemVer pousse Ă  vite bumper la version majeure une fois la v1 sortie.
De plus ces changements sont très bien documentés, chacun étant associé à une estimation du temps de mise à jour, de la complexité, des risques, et des dépendances!

La version actuelle, v8, a Ă©tĂ© un refactoring majeur du framework et de son api. Les diffĂ©rentes interfaces existantes pour configurer le serveur ont Ă©tĂ© unifiĂ©es. C’est ainsi que des mĂ©thodes comme pack ont disparu (un pack Ă©tant la composition de plusieurs serveurs en un unique objet).
L’objectif Ă©tait celui de simplifier l’expĂ©rience de dĂ©veloppement en rendant l’api plus simple et prĂ©visible. D’amĂ©liorer l’expĂ©rience DĂ©veloppeur en gagnant en simplicitĂ© et apprenabilitĂ© sans perdre en puissance.
Ce gros refactor a Ă©tĂ© fait dans l’Ă©tat d’esprit des « breaking changes worth taking » revendiquĂ© par le mainteneur principal. La communication sur la v8 laisse Ă  penser qu’il est peu probable d’avoir de nouvelle version majeure dans les mois qui viennent.
A titre d’exemple, voici l’estimation associĂ©e Ă  la dernière version majeure publiĂ©e:

  • Upgrade time : moderate to high – a couple of days to a week for most users
  • Complexity : moderate – a very long list of changes, all well understood with no side effects
  • Risk : moderate – no side effects but a lot of changes to keep track of
  • Dependencies : moderate to high – every plugin must be verified to be compatible or upgraded

On retrouvera ainsi les notes de sortie des versions majeures de l’annĂ©e 2014: v8 en novembre, v7 en octobre, v6 en juin, v5 en mai, v4 en avril, v3 en mars.

Communauté

Bien que nĂ© a Wallmart, Hapi a su s’en dĂ©tacher, et attirer une communautĂ© consĂ©quente autour de lui. NĂ©anmoins il est indĂ©niable que son crĂ©ateur garde pour l’instant un leadership certain sur la vie du framework. Cependant ceci n’a pas empĂŞchĂ© 900 pull requests d’ĂŞtre acceptĂ©es, et 21 personnes composent actuellement l’organisation hapijs. Le dĂ©pĂ´t initialement sur le compte de WallmartLab a Ă©tĂ© migrĂ© sur cette organisation. Celui-ci contient bien entendu le framework hapi, mais aussi l’ensemble des plugins de l’Ă©cosystème, et le code source du site contenant la documentation et divers tutoriels.

Toute la dynamique et le développement du plugin se fait via github et ses issues ce qui permet à la fois visibilité et centralisation des discussions. Tout cela est organisé grâce à un système de tag très bien pensé des issues: bug, security, dependency, discussion, documentation, release notes, breaking changes, question, request, test.

Comme Express il dispose d’un channel IRC #hapi, d’un chat gitter, et d’un cours nodeschool makemehapi.
A noter aussi l’existence d’un programme de mentoring pour assister les dĂ©veloppeurs dans leur montĂ©e en compĂ©tence sur hapi.

Hapi et Express: la Synthèse

Si on revient Ă  une analyse naĂŻvement, purement quantitative des mĂ©triques, express se dĂ©tachait nettement d’hapi. Cependant on vient de voir que ceci est en grande partie dĂ» Ă  des raisons historiques. De plus ceci concerne la communautĂ© et la visibilitĂ©, plus que l’utilisation d’un point de vue industriel.

Si express est pas mal utilisĂ© dans nombreuses startups ayant optĂ© pour node, difficile Ă  trouver des projets d’ampleur, et de grandes entreprises l’utilisant. D’ailleurs netflix l’a abandonnĂ© suite Ă  des problèmes de performance Ă  grande Ă©chelle . A contrario Hapi est utilisĂ© par de nombreuses boites commerciales d’envergure listĂ©es sur leur site: notamment Disney, mozilla, Paypal, npm. Sans parler bien entendu de Wallmart.

Cela rejoint la recommandation qui Ă©merge de cette analyse qualitative quant au choix d’un framework node pour la rĂ©alisation d’API REST. Dans le cadre d’un POC, avec une Ă©quipe rĂ©duite qui a dĂ©jĂ  une expĂ©rience d’express, celui-ci fera aisĂ©ment le job.
Cependant pour un projet d’ampleur, que ce soit pour la taille de l’Ă©quipe, la durĂ©e, ou l’audience, il est avisĂ© d’opter pour Hapi.

Articles suggested :

  1. Pourquoi utiliser Node pour réaliser mon API ?
  2. Node for API: Express et Hapi en pratique
  3. Designer une API REST

Catégories: Blog Société

Xebia accueille le Software Craftsmanship Paris

logo-crafts

Le lundi 15 juin Xebia accueille la communauté parisienne du Software Craftsmanship.

Une fois par mois, plusieurs artisans du logiciel se rĂ©unissent Ă  Paris pour Ă©changer autour des bonnes pratiques de dĂ©veloppement et bien sĂ»r pour coder. Actuellement, l’Ă©vĂ©nement se dĂ©roule sous forme d’Open Space : les participants proposent des sujets (discussions, katas, dojos, etc.) et les participants votent. Les sujets les plus sollicitĂ©s seront abordĂ©s dans la soirĂ©e. Il est Ă©galement possible de proposer des lightning talks au dĂ©but de l’Ă©vĂ©nement. Un buffet est offert par Xebia Ă  la fin de l’Ă©vĂ©nement.

Comment y participer ? Inscrivez-vous ! Les inscriptions ouvrent aujourd’hui (vendredi 5 juin) Ă  19h.

Catégories: Blog Société

Parcours d’un agiliste au KanbanDay

Parcours d’un agiliste au KanbanDay Pour avoir eu la chance d’assister à la première édition du KanbanDay, je vous propose une restitution de cette expérience qui fut extrêmement enrichissante. Après avoir participé à quelques salons Agile ces derniers mois, je me suis rendu compte que,...
Catégories: Blog Société

Revue de Presse Xebia

RDP

La revue de presse hebdomadaire des technologies Big Data, Cloud et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

AgilitĂ© The Epidemic of Managing Without Soul – Henry Mintzberg http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochet%2Fhttp://twitter.com/nicolaslochetPar Nicolas Lochet

Au premier abord, cet article peut sembler anodin. Et puis on s’aperçoit qu’il est de Henry Mintzberg et il prend toute sa puissance.

Henry Mintzberg nous partage ici quelques histoires, vĂ©cues ou racontĂ©es sur les consĂ©quences d’un management sans âme. Ă€ l’heure du management 3.0, de l’entreprise libĂ©rĂ©e et pour ainsi dire de la prise de conscience de l’importance du rĂ´le du manager, il est important de se rappeler Ă  quel point nos actes peuvent ĂŞtre destructeurs s’ils sont faits sans âme.

Un joli rappel qu’une entreprise ce n’est pas juste un organigramme que je vous propose donc de parcourir !

Lean Startup and How It Almost Killed Our Company http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochet%2Fhttp://twitter.com/nicolaslochetPar Nicolas Lochet

Cet article d’Helen Walton peut susciter pas mal de controverses. C’est un retour d’expĂ©rience sur le Lean Startup chez Gamevy une entreprise qui fait des jeux d’argent sur internet. Helen partage les difficultĂ©s rencontrĂ©es par les fondateurs de Gamevy dans la mise en place d’une approche Lean Startup et dĂ©nonce un certain nombre de pièges de l’approche, notamment dans le cas de marchĂ©s avec des barrières d’entrĂ©e Ă©levĂ©e.

On pourrait argumenter sur la dĂ©finition du MVP et c’est peut ĂŞtre une bonne idĂ©e de relire cet article de Steve Blank que nous avions partagĂ© rĂ©cemment, il y a sans doute ici quelques pistes qui peuvent expliquer les confusions.

Toutefois ceci Ă  part, l’article reste un excellent retour, dĂ©taillĂ©, d’une expĂ©rience poussĂ©e de mise en place du Lean Startup. Les mises en garde ne sont pas dĂ©nuĂ©es de sens et cela peut sans doute ĂŞtre lĂ  des avertissements utiles si vous envisagez ces approches.

Bonne lecture !

Mobilité Annonce d’Android M http://blog.xebia.fr/author/jmartinezhttp://twitter.com/jeremmartinezhttp://github.com/jeremiemartinezPar Jeremie Martinez

Google a finalement bien annoncé une nouvelle version d’Android lors de la Google IO de la semaine dernière. La version preview nommée M est disponible dés maintenant. Google a donc mis en ligne une API overview disponible à ce lien afin de résumer les impacts majeures de cette nouvelle version sur nos développements. Au programme, gestion des permissions, App Linking, Auto-Backup, BLE, Direct Share ou encore authentification par empreinte digitale.

Comment intégrer Maps dans vos applications Wear http://blog.xebia.fr/author/jmartinezhttp://twitter.com/jeremmartinezhttp://github.com/jeremiemartinezPar Jeremie Martinez

Avec la Google IO 15 de la semaine dernière, les développeurs de Google Maps ont annoncé sur cet article qu’il est maintenant possible d’intégrer Maps dans vos applications Wear. Cette possibilité apporte donc un vrai usage sur montre puisqu’elle vous permettra de guider vos utilisateurs sans sortir leur téléphone.

Cet article vous montre comment intĂ©grer facilement Maps avec des exemples de code très simple. De plus, l’API est quasi-identique Ă  celle disponible sur tĂ©lĂ©phone.

Un point sur la gestion des permissions en M http://blog.xebia.fr/author/jmartinezhttp://twitter.com/jeremmartinezhttp://github.com/jeremiemartinezPar Jeremie Martinez

Dans cet article,  Dave Smith fait un point sur la nouvelle gestion des permissions sur Android M. En effet, avec M, l’utilisateur aura dĂ©sormais la possibilitĂ© de refuser certaines permissions de nos applications, offrant ainsi une gestion plus fine Ă  chaque utilisateur. On peut alors se demander comment vont marcher les applications dĂ©jĂ  existantes ? L’auteur a fait ce test afin de voir selon chaque permission le comportement adoptĂ© par Android M. On observe par exemple que des informations vides sont gĂ©nĂ©ralement remontĂ©es en lecture. En Ă©criture, tout sera acceptĂ© mais pas pris en compte. Cependant des bugs ont dĂ©jĂ  commencĂ© Ă  apparaĂ®tre. Il est donc important de repasser sur nos applications afin de vĂ©rifier que le comportement gĂ©nĂ©ral n’est pas altĂ©rĂ©.

PromiseKit sort en version 2, avec interopérabilité Swift/Obj-C http://blog.xebia.fr/author/pdrouillyPar Pascal Drouilly

PromiseKit sort sa version 2, complètement rĂ©-Ă©crit en Swift. Pour des raisons de language dynamique vs statique, deux classes sont crĂ©Ă©es (Promise<T> pour Swift, et AnyPromise pour Obj-C). On peut utiliser les AnyPromise dans une chaĂ®ne de Promise<T>. Pour voir les Promise<T> en Obj-C, c’est plus compliquĂ©, mais en gros l’interopĂ©rabilitĂ© est assez bien assurĂ©. Ils ajoutent aussi la notion de cancellation. Allez voir tous les dĂ©tails sur leur blog post.

Craftsmanship  Tests End-To-End : Point trop n’en faut – Craftsmanship http://github.com/sbuissonPar Sarah Buisson

Les tests End-To-End (e2e) :  Ces tests simulant les cas d’utilisation rĂ©els de bout en bout, la tentation est grande d’en abuser, voir de n’utiliser qu’eux. Or, qu’ils soient manuels ou automatisĂ©s, ils sont longs Ă  utiliser, couteux Ă  mettre en place et difficiles Ă  maintenir. En consĂ©quence ils ne doivent prendre la place des test d’intĂ©gration , et surtout, les tests End-To-End ne doivent pas remplacer les tests unitaires.

Le site Tricentis nous gratifie d’un white-paper sur les tests End-To-End, un sujet Ă©galement repris par le blog Google-testing.

Front Lodash – underscore: la fusion ? http://www.gravatar.com/b48c1ee560ff6432a574dceb746dff79http://blog.xebia.fr/author/romain-niveau%2Fhttp://twitter.com/RomainNVhttp://github.com/rniveauPar Romain Niveau

Lodash et underscore.js sont deux librairies bien connues du monde javascript. Toutes les deux apportent moult fonctions très utiles dans le développement de tous les jours.

Mais parfois ces deux librairies se recoupent, elles utilisent les mĂŞmes APIs (60% si on en croit Jeremy Ashkenas, crĂ©ateur d’underscore).

Faut-il alors fusionner ces librairies ?

C’est en tout cas le but des discussions engagĂ©es entre les deux crĂ©ateurs des deux librairies. Et mĂŞme si cela ne semble pas gagnĂ© d’avance, c’est peut ĂŞtre une bonne idĂ©e pour l’avenir.

Pour plus de dĂ©tails sur ces discussions, c’est par ici.

Polymer est prĂŞt pour la production http://www.gravatar.com/aa58d11447d7dac262978cddbb592f37http://twitter.com/a_bacharhttps://github.com/abacharPar Abdelhakim Bachar

Le 29 Mai 2015, l’équipe de Polymer a releasé la version 1.0, cette nouvelle version est complètement réécrite. Elle est 3 fois plus rapide sur Chrome, 4 fois plus rapide sur Safari, 36% moins de code que la 0.5 et surtout prête pour la production.

Toute la documentation est Ă  jour sur le site et la nouvelle version contient :

  • Un nouveau system de data binding plus rapide et plus facile Ă  utiliser.
  • Fini le /deep/ et ::shadow, maintenant on peut utiliser les Custom CSS Properties pour styler les composants.
  • Shady DOM qui est un shim très rapide pour le shadow DOM.
  • Utilisation des Behaviors pour partager le code entre Elements.

Aussi, cette version arrive avec un catalogue d’Elements :

  • Iron Elements : Elements de base (iron-ajax, iron-form…).
  • Paper Elements : Elements pour Google Material design.
  • Google Web Components : Elements pour l’API des services Google (Analytics, Map…).
  • Gold Elements : Elements pour le e-Commerce.
  • Neon Elements : Elements pour les animations et les effets.
  • Platinum Elements : Elements pour le push, le mode offline…
  • Molecules : Pour le moment ne contient qu’un seul Element pour utiliser la bibliothèque marked.

Vous trouverez l’annonce officielle ici

Back  Monolith first http://www.gravatar.com/97b6bcdd484a51fead09db2a904158a2http://blog.xebia.fr/author/amichaudhttp://twitter.com/AMichaud34http://github.com/antoinemichaudPar Antoine Michaud

A l’heure de la grande vague des microservices (et surtout de notre tout dernier techtrends back), voici un article intĂ©ressant, intitulĂ© MonolithFirst, Ă©crit par Martin Fowler sur son blog. Si vous vous posez la question : « Dois-je partir sur des microservices sur ma nouvelle application ? », cet article vous donne donc un Ă©lĂ©ment de rĂ©ponse avec un YAGNI en règle.

Attention Ă  ne pas trop tout prendre au pied de la lettre, notre auteur modĂ©rant lui-mĂŞme son propos en prĂ©cisant aussi l’argumentaire contraire.

DevOps Le CTO de Nike expose sa stratĂ©gie Continuous Delivery http://twitter.com/xebialabsFrPar Richard Mathis En tant que gĂ©ant dans le monde du sport, Nike est maintenant très impliquĂ© dans l’utilisation des nouvelles technologies et Chris Satchell, son CTO, dirige dĂ©sormais une Ă©quipe de plus de 1 400 Ă©lĂ©ments. Ayant rĂ©cemment adoptĂ© le Continuous Delivery, Satchell nous livre dans cet article (http://blog.heavybit.com/blog/2015/3/23/nikecto-wheelhouse) l’expĂ©rience qu’il en a retirĂ©, avec ses propres DO and DO NOT. Le coin de l’Alliance XebiaLabs sera prĂ©sent Ă  la convention annuelle du CRIP 2015 http://www.gravatar.com/0c83f57c786a0b4a39efab23731c7ebchttp://twitter.com/xebialabsFrPar XebiaLabs Les 16 et 17 juin, XebiaLabs est sponsor de la convention du CRIP (Club Infrastructure et Production), au cours de laquelle la SG CIB rĂ©alisera un tĂ©moignage de la mise en Ĺ“uvre de notre solution XL Deploy (17 juin matin Ă  9h30, « Continuous Delivery Ă  grande Ă©chelle dans une banque d’investissement »). Managers, directeurs et responsables d’infrastructure et/ou de production, nous vous invitons Ă  venir assister Ă  cet Ă©vĂ©nement en vous inscrivant avec le code d’inscription 422XEB sur le site(http://www.crip-asso.fr/beecrip/) officiel.
Catégories: Blog Société

[événement] Retours sur AgileGamesNight

Agile Nantes - mer, 06/03/2015 - 09:46
Qu’est ce qui s’est passĂ© ?

Vendredi soir, c’Ă©tait la première nuit de jeux agiles. Une cinquantaine de personnes se sont retrouvĂ©s Ă  la cantine numĂ©rique, pour une nuit inĂ©dite.

L’accueil des participants s’est dĂ©roulĂ©e de 18h Ă  19h, c’Ă©tait la pĂ©riode d’Ă©chauffement. Des Icebreaker  ont Ă©tĂ© lancĂ©s et des propositions de jeux Ă©taient aux programme. L’auto-organisation Ă©tait au coeur de l’Ă©vĂ©nement. Chacun pouvait donc proposer un jeu et s’inscrire Ă  d’autres.

A 19h,  tout le monde a trouvĂ© une place dans les diffĂ©rents ateliers proposĂ©s, jusqu’Ă  la pause sandwich de 21 h.

Après s’ĂŞtre restaurĂ©s, les joueurs ont dĂ©marrĂ©s de nouveaux ateliers dans la bonne humeur, jusqu’Ă  la fermeture de la cantine numĂ©rique, Ă  1h du matin.

Découvrez la soirée en  quelques images.

 

Catégories: Association

WWDC 2015 : le 8 juin suivez la keynote Apple chez Xebia

wwdc

Le 8 juin prochain dĂ©butera la WWDC 2015 d’Apple oĂą l’on devrait y dĂ©couvrir iOS 9 et OSX 10.11. Après les rĂ©vĂ©lations fracassantes de l’annĂ©e dernière avec l’annonce de Swift, que nous rĂ©serve Apple pour cette annĂ©e ?

Venez le découvrir en suivant l’événement dans nos locaux à Paris et échanger avec nos experts sur les nouveautés techniques de l’écosystème iOS.

Les rumeurs

Très peu de choses ont filtrĂ© sur la confĂ©rence. NĂ©anmoins des rumeurs persistantes indiquent qu’Apple pourrait annoncer son offre de streaming musical, concurrent direct de Spotify, Deezer et autres.

On peut Ă©galement espĂ©rer entendre parler de Swift 1.3, lui qui a dĂ©jĂ  Ă©tĂ© mis Ă  jour par deux fois depuis sa sortie l’annĂ©e dernière.

La soirée

Pour suivre cet événement, Xebia organise une soirée qui permettra de visionner la keynote en projection sur grand écran. Nous aurons également la possibilité d’échanger sur les impacts techniques concernant les nouveautés du système.

Pendant la projection, Xebia vous offrira à boire et à manger afin de digérer plus facilement les annonces !

Pour vous inscrire, c’est par ici.

Rendez-vous le 8 juin, à 18h45 au 156 Boulevard Haussmann au 7ème étage (à gauche sous le porche). La keynote commencera dès 19h.

Catégories: Blog Société

Utiliser Zookeeper avec Curator API pour du « Service Discovery »

Suite Ă  la prĂ©sentation de Zookeeper dans un article prĂ©cĂ©dent, la mise en oeuvre d’un cas pratique s’imposait ! Je vous propose donc d’utiliser Zookeeper pour mettre en oeuvre un « Service Discovery ». Nous utiliserons le framework Curator qui offre une API haut niveau pour manipuler Zookeeper.

Le framework Curator a été initié par les développeurs de Netflix afin de rendre plus digeste l’API original de Zookeeper. Et bien leur en a pris car grâce à cette API, toutes les solutions qu’apporte Zookeeper ne sont plus que quelques lignes de code à ajouter à votre projet. Sachez que l’API Curator vous permet de mettre en oeuvre d’autres “recettes” telle que Leader Election, Locks, Barriers, Cache, … bref je vous invite à aller jeter un coup d’oeil à la page des recettes du projet Curator.

Pour réaliser notre tutorial nous allons utiliser spring-boot. Ne vous inquiétez pas si vous ne connaissez pas ou peu spring-boot son utilisation sera réduite au stricte minimum. Vous pouvez trouver le code source de cet article sur mon github.

Nous utiliserons une instance standalone de Zookeeper. Je vous invite à utiliser le tuto de l’article précédent pour installer et configurer votre instance (ne vous inquiétez pas cela ne vous prendra pas plus de 10 minutes).

L’API Curator pour le « Service Discovery »

Pour rĂ©pondre au problème de « Service Discovery », il faut d’abord que notre service s’enregistre auprès de Zookeeper pour annoncer « Hey oh ! Je m’appelle service-truc. Je suis en version x.y et si on veut m’appeler je suis disponible Ă  l’adresse http://service-truc« .

Ensuite une application cliente va vouloir consommer le service-truc. Elle va donc aller voir Zookeeper et lui demander « Alors voilĂ . J’ai besoin d’appeler le service-truc vous en l’auriez en stock ? » (oui l’application client est polie elle vouvoie Zookeeper).

Pour voir ce que cela donne en terme de code, nous allons mettre en oeuvre un exemple tout simple avec un service nommĂ© « simple-tax-api » qui permet de calculer un prix TTC Ă  partir d’un prix HT fournit en entrĂ©e. Nous allons enregistrer le service auprès de Zookeeper puis nous dĂ©velopperons une application cliente de « simple-tax-api » et qui, pour l’utiliser, demandera Ă  Zookeeper de lui fournir toutes les informations nĂ©cessaires pour l’appeler.

DĂ©pendances Maven

Ajouter les dépendances suivantes pour utiliser l’API Curator :

<dependency>
  <groupId>org.apache.curator</groupId>
  <artifactId>curator-framework</artifactId>
  <version>2.7.1</version>
</dependency>
<dependency>
  <groupId>org.apache.curator</groupId>
  <artifactId>curator-x-discovery</artifactId>
  <version>2.7.1</version>
</dependency> 
DĂ©velopper le service de calcul du prix TTC

Cette partie a pour objectif d’être anecdotique, voici à quoi ressemble cet incroyable service REST :

@RestController
@RequestMapping(value = "/taxapi")
public class TaxRest {
 
   private static final double TVA = 0.2;
   
   @RequestMapping(value = "/ttc", method = RequestMethod.GET)
   public double add(@RequestParam("ht") double ht) {
      return ht * (1 + TVA);
   }

} 
Enregistrer le service dans Zookeeper

Bien entendu la première chose à faire est de se connecter à Zookeeper. Pour cela nous utilisons CuratorFrameworkFactory. Dans l’exemple de code ci-dessous, nous demandons à nous connecter à un Zookeeper déployé en local avec 3 tentatives maximum. Les tentatives de connexion commencent lorsque l’on appel start() sur notre instance de CuratorFramework:

CuratorFramework curator = CuratorFrameworkFactory.newClient("localhost", new ExponentialBackoffRetry(1000, 3));

curator.start();

Une fois connecté à Zookeeper, nous utilisons ServiceDiscoveryBuilder pour préciser dans quel rangement le service veut s’enregistrer. Dans notre cas, nous n’allons pas être très imaginatif, nous allons nous enregistrer dans le rangement “services”. A noter que JsonInstanceSerializer nous permet d’annoncer que nous allons stocker des informations supplémentaires (nommé payload par Curator framework) qui peuvent être assez complètes et faciles à écrire grâce à l’utilisation de JSON. Dans notre cas ce payload sera une simple String qui contiendra la version du service qui viendra s’enregistrer auprès du naming service.

JsonInstanceSerializer<String> serializer = new JsonInstanceSerializer<String>(String.class);

ServiceDiscovery<String> discovery = ServiceDiscoveryBuilder.builder(String.class)
      .client(curator())
      .basePath("services")
      .serializer(serializer)
      .build();

Avec cela, nous avons tous les Ă©lĂ©ments nĂ©cessaires pour enregistrer concrètement notre service auprès du « Naming Service ». Dans ce morceau de code, nous dĂ©clarons concrètement que notre service nommĂ© « simple-tax-api » en version 1.0 est disponible sur « http://localhost:{serverPort}/taxapi »

ServiceInstance<String> instance =
      ServiceInstance.<String>builder()
              .name("simple-tax-api")
              .payload("1.0")
              .address("localhost")
              .port(serverPort)
              .uriSpec(new UriSpec("{scheme}://{address}:{port}/taxapi"))
              .build();
discovery.registerService(instance);

Le code suivant récapitule ce que nous venons de voir cette fois sous la forme d’une configuration Java Spring

@Configuration
public class ServiceDiscoveryConfiguration implements CommandLineRunner{
  @Autowired
  ServiceDiscovery<String> discovery;
  /**
   * serverPort est fourni au démarrage en ligne de commande
   */
  @Value("${server.port}")
  private int serverPort;
  public void run(String... args) throws Exception {
      ServiceInstance<String> instance =
              ServiceInstance.<String>builder()
                      .name("simple-tax-api")
                      .payload("1.0")
                      .address("localhost")
                      .port(serverPort)
                      .uriSpec(new UriSpec("{scheme}://{address}:{port}/taxapi"))
                      .build();
      discovery.registerService(instance);
  }
  @Bean(initMethod = "start", destroyMethod = "close")
  public CuratorFramework curator() {
      return CuratorFrameworkFactory.newClient("localhost", new ExponentialBackoffRetry(1000, 3));
  }
  @Bean(initMethod = "start", destroyMethod = "close")
  public ServiceDiscovery<String> discovery() {
      JsonInstanceSerializer<String> serializer =
              new JsonInstanceSerializer<String>(String.class);
      return ServiceDiscoveryBuilder.builder(String.class)
              .client(curator())
              .basePath("services")
              .serializer(serializer)
              .build();
  }
}
DĂ©veloppons l’application utilisant « simple-tax-api »

Le dĂ©part du code est identique Ă  l’enregistrement du service dans Zookeeper puisqu’il s’agit de s’y connecter puis d’obtenir une instance de ServiceDiscovery. Cette partie du code Ă©tant strictement identique, je ne reviens pas dessus.

Pour rĂ©cupĂ©rer des informations sur le « service-tax-api », nous utilisons l’instance de ServiceDiscovery en lui demandant de nous retourner la liste des instances actuellement disponibles pour nous fournir le service :

Collection<ServiceInstance<String>> services = discovery.queryForInstances("simple-tax-api");

Ensuite dans notre exemple, nous nous limitons à prendre le premier élément disponible et appelons le service dessus:

if (services.iterator().hasNext()) {
  // Nous utilisons par défaut le premier dans la liste
  ServiceInstance<String> serviceInstance = services.iterator().next();
  logger.debug("version du service: {}", serviceInstance.getPayload());
  String serviceUrl = serviceInstance.buildUriSpec() + "/ttc?ht={ht}";
  Map<String,Double> params = new HashMap<String, Double>();
  params.put("ht", totalHT);
  totalTTC = restTemplate.getForObject(serviceUrl, Double.class, params);
}

et voilĂ  !

Pour rĂ©fĂ©rence rapide, voici ci-dessous le code des deux principales classes composant notre application client du service « simple-tax-api ».

Pour récupérer le code complet vous pouvez le trouvez sur mon github.

@Configuration
public class ServiceDiscoveryClientConfiguration {
  @Bean(initMethod = "start", destroyMethod = "close")
  public ServiceDiscovery<String> discovery() {
      JsonInstanceSerializer<String> serializer =
              new JsonInstanceSerializer<String>(String.class);
      return ServiceDiscoveryBuilder.builder(String.class)
              .client(curator())
              .basePath("services")
              .serializer(serializer)
              .build();
  }
  @Bean(initMethod = "start", destroyMethod = "close")
  public CuratorFramework curator() {
      return CuratorFrameworkFactory.newClient("localhost", new ExponentialBackoffRetry(1000, 3));
  }
}

@RestController
@RequestMapping(value = "/ecommerce/api")
public class PriceCalculatorRest {
  Logger logger = LoggerFactory.getLogger(getClass());
  @Autowired
  ServiceDiscovery<String> discovery;
  RestTemplate restTemplate = new RestTemplate();
  @RequestMapping(value = "/total", method = RequestMethod.POST,
          consumes = MediaType.APPLICATION_JSON_VALUE)
  public double totalPanier(@RequestBody List<Article> articles) throws Exception {
      double totalHT = 0;
      double totalTTC = 0;
      for (Article article : articles) {
          totalHT += article.getPriceHT();
      }
      Collection<ServiceInstance<String>> services = discovery.queryForInstances("simple-tax-api");
      logger.debug("Le service 'simple-tax-api' est fourni par {} instance(s)", services.size());
      if (services.iterator().hasNext()) {
          // Nous utilisons par défaut le premier dans la liste
          ServiceInstance<String> serviceInstance = services.iterator().next();
          logger.debug("version du service: {}", serviceInstance.getPayload());
          String serviceUrl = serviceInstance.buildUriSpec() + "/ttc?ht={ht}";
          Map<String,Double> params = new HashMap<String, Double>();
          params.put("ht", totalHT);
          totalTTC = restTemplate.getForObject(serviceUrl, Double.class, params);
      }
      return totalTTC;
  }
}
Assemblons le tout Lancement du service « simple-tax-api »

Tout d’abord nous nous assurons que Zookeeper en standalone est bien dĂ©marrĂ©.

./zkServer.sh start

Comme nous avons dĂ©veloppĂ© l’application avec spring-boot, nous pouvons produire facilement un jar avec un tomcat embarquĂ© avec la commande maven suivante:

mvn clean package spring-boot:repackage

puis nous lançons deux instances de notre service

java -Dserver.port=8000 -jar simple-tax-api-1.0-SNAPSHOT.jar
java -Dserver.port=9000 -jar simple-tax-api-1.0-SNAPSHOT.jar
Lancement de l’application cliente

De manière identique nous produisons un jar avec un tomcat embarqué avec la commande maven:

mvn clean package spring-boot:repackage

puis pour exécuter le jar

java -jar simple-client-1.0-SNAPSHOT.jar

Pour dĂ©clencher l’appel Ă  service-tax-api, nous appelons le service REST de notre application simple-client:

curl -X POST -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '[
{
    "name":"toto",
    "priceHT": 45.0
},
{
    "name":"titi",
    "priceHT": 55.0
}
]
' http://localhost:8080/ecommerce/api/total

Nous avons alors les logs suivantes qui apparaissent:

Le service 'simple-tax-api' est fourni par 2 instance(s)
version du service: 1.0
appel de l'url: http://localhost:8000/taxapi/ttc?ht={ht}
Conclusion

Grâce Ă  l’API Curator manipuler Zookeeper est accessible Ă  tous, alors … Ă  vous de jouer !!

Catégories: Blog Société

Strata+Hadoop World London 2015

strata+hadoop

Du 5 au 7 mai 2015 avait lieu Ă  Londres la confĂ©rence Strata + Hadoop World. OrganisĂ©e par O’reilly et Cloudera, elle regroupe les acteurs majeurs du monde du Big Data, mais aussi de la Data Science. Nous y Ă©tions. Voici un compte rendu des thèmes majeurs abordĂ©s et des meilleurs sessions de la confĂ©rence.

Les Keynotes

Les journĂ©es de la confĂ©rence dĂ©marrent par des prĂ©sentations courtes sur l’utilisation du Big Data dans diffĂ©rentes entreprise et l’impact de ces nouvelles technologies dans notre vie. Des intervenants de Santander Group, Teradata, Shazam, Google, The Financial Times, entre autres, nous ont exposĂ©s leur vision du Big Data.

Voici selon nous les Keynotes les plus marquantes :

Cait O’Riordan de Shazam a donnĂ© une confĂ©rence passionnante sur l’utilisation des donnĂ©es Ă  Shazam. Utilisant les donnĂ©es de leur service, Shazam est en mesure de prĂ©dire quelles chansons vont devenir des tubes et avoir un aperçu de la structure des chansons Ă  succès. En particulier, ils peuvent identifier les parties de chansons qui attirent le plus l’attention.

Julia Angwin (ProPublica) nous raconte le temps qu’elle a passĂ© et l’argent qu’elle a dĂ©pensĂ© en essayant de protĂ©ger sa vie privĂ©e. Elle nous pose la question suivante : voulons-nous vivre dans une sociĂ©tĂ© oĂą seuls les riches peuvent acheter leur moyen de sortir de la surveillance omniprĂ©sente?

Tim Harford (Financial Times) nous expose, Ă  l’aide d’histoires passionnantes de Matt Parker et Mario Capecchi, les contraintes pour rendre concrètes des idĂ©es innovantes qui apportent des amĂ©liorations marginales ou sur le long terme.

Vous pouvez retrouver l’intĂ©gralitĂ© des Keynotes de la confĂ©rence ici.

Spark, Spark, Spark et encore Spark

A en juger par le nombre de tĂ©moignages d’entreprises s’intĂ©ressant Ă  cet outil et de sessions sur le sujet, Spark apparait dĂ©sormais, s’il fallait encore en douter, comme le futur moteur standard de traitement de donnĂ©es distribuĂ©es.

MRSpark

Apache Spark: What’s new; what’s coming : par Patrick Wendell de Databricks

Dataframes : Bien qu’elle soit en pleine mutation et ne sera stable que dans la version 1.5 de Spark, l’API de Spark SQL est clairement l’un des projets les plus importants de Spark. Les Dataframes sont mĂŞme destinĂ©es Ă  remplacer Ă  terme les RDDs comme structure de donnĂ©es de base manipulĂ©e par les dĂ©veloppeurs.

spark-future

L’idĂ©e est d’offrir la mĂŞme souplesse et les mĂŞme fonctionnalitĂ©s dont bĂ©nĂ©ficient dĂ©jĂ  les utilisateurs de R et Python. La manipulation de vos donnĂ©es devient encore plus simple et intuitive. Voici par example le code permettant de calculer une moyenne d’age par dĂ©partement en Spark core puis en Spark SQL avec les Dataframes :

spark-sql

Data Sources : Il s’agit d’une API pour la manipulation de donnĂ©es structurĂ©es dans Spark introduite dans la version 1.2 dans le cadre du paquet Spark SQL. Elle apporte une nouvelle façon de lire les donnĂ©es en dehors de l’API InputFormat d’Hadoop

Projet Tungsten : Il s’agit d’un vaste projet d’optimisation de Spark composĂ©s de plusieurs initiatives :

  • L’utilisation de format binaire et une gestion explicite de la mĂ©moire Ă  l’aide de la classe sun.misc.Unsafe pour s’affranchir des limites du GC.
  • mais Ă©galement l’utilisation d’algorithmes et de structures de donnĂ©es optimisant l’utilisation des caches CPU (L1/L2/L3) ainsi que de la gĂ©nĂ©ration de code.

Nous pouvons nous attendre à voir les premiers résultats de ce projet dans la version 1.4 de Spark.

spark-tomorrow

Spark on Mesos : présenté par Dean Wampler de Typesafe

 Mesos : Spark Ă  l’origine a Ă©tĂ© crĂ©e comme un outil “to spark an ecosystem in Mesos”.

mesos-spark

Le projet est très activement dĂ©veloppĂ© (et supportĂ© par Mesosphere). Twitter et Apple (Siri) l’utilisent en production. Toutefois, bon nombre des contributeurs originaux sont maintenant chez Databricks Ă  l’oeuvre sur d’autres tâches. Pour certains projets, il est peut-ĂŞtre idĂ©al, mais aujourd’hui la combinaison Spark + YARN est plus dynamique qui plus est pour des traitements de donnĂ©es stockĂ©es sur HDFS. Cependant de nombreux acteurs parient sur une future utilisation massive de Mesos (Dean Wampler prĂ©dit qu’il y aura plus de cluster Mesos que de cluster YARN dans 5 ans).

Apache Spark: The faster new execution engine for Apache Hive : par Xuefu Zhang (Cloudera) et Rui Li (Intel)

L’initiative Hive on Spark ( HIVE-7292 ) fait de grand progrès et promet l’obtention d’excellentes performances, notamment comparĂ©e Ă  l’exĂ©cution de requĂŞtes Hive avec MapReduce.

hive-spark

Machine Learning avec Spark : Sean Owen de Cloudera nous a prĂ©sentĂ© l’utilisation d’un algorithme de Machine Learning avec Spark : A taste of random decision forests on Apache Spark. Il viendra donner cette mĂŞme prĂ©sentation lors du Spark User Group, le 11 juin prochain Ă  Paris.

Stream All your Data

Les pipelines de traitements de données en "temps réel" étaient dans tous les esprits des membres de la conférence. Tout le monde en parlait et voulait comprendre comment les mettre en place au sein de leur entreprise. Deux sessions furent particulièrement instructives à ce sujet et prédisaient, chacune à sa manière, la transition des traitements de données en mode batch vers des systèmes de traitements de flux de données en continu.

Systems that enable data agility: Lessons from LinkedIn : par Martin Kleppman

Martin Kleppman nous Ă  prĂ©sentĂ©, en prenant pour exemple l’infrastructure mise en place chez LinkedIn (oĂą furent crĂ©Ă©s Apache Kafka et Apache Samza) comment mettre en place un vĂ©ritable Data Backbone au sein de son datacenter. L’idĂ©e globale est que nous devrions archiver toutes les donnĂ©es de nos SI, y compris celles contenues dans les bases de donnĂ©es (voir Ă  ce sujet ces trois articles) en tant que logs (au sens de sĂ©quence totalement ordonnĂ©e d’Ă©vĂ©nements en append-only).

data-bus

Pousser ces Ă©vĂ©nements en temps rĂ©el dans un outil comme Kafka rend ces flux de donnĂ©es rapidement disponibles pour le traitement et l’analyse, composables et permet de rejouer Ă  volontĂ© les traitements sur celles-ci.

kafka-future

Say goodbye to batch : Tyler Akidau (Google)

Tyler nous à présenté les concepts derrière Millwheel, le framework de traitements de données en temps réels massivement utilisé chez Google, rendu disponible à travers le projet Google Cloud Dataflow.

Ces concepts permettent notamment de pouvoir traiter des flux de donnĂ©es en se basant sur la date d’occurence d’un Ă©vĂ©nement et pas de la date de traitement de celui-ci, permettant de s’affranchir de la Lambda Architecture.

event-time-skew
processing-time
event-time

Vous pouvez consulter les slides ici.

Conclusion

Cette deuxième édition de la conférence Strata+Hadoop en Europe (la première avait eut lieu à Barcelone en 2014) fut passionnante et inspirante. Y étiez-vous ? Si oui, dites nous dans les commentaires les sessions que vous avez préférées.

Catégories: Blog Société

ncrafts.io jour 2

NCrafts 2015, ce sont deux jours de conférences mémorables. Après avoir fait un retour sur le premier jour, voici un article qui résume certaines des conférences auxquelles nous avons assisté lors du deuxième jour.

Puisque l’Ă©dition 2015 est dĂ©jĂ  passĂ©e, nous ne pouvons que vous encourager Ă  ne pas manquer la prochaine Ă©dition. En attendant, si le sujet vous tient particulièrement Ă  cĹ“ur, sachez que Sandro Mancuso propose une formation en France en partenariat avec Xebia Training.

Dichotomy between things and processes 
http://www.gravatar.com/37a6259cc0c1dae299a7866489dff0bdhttp://blog.xebia.fr/author/nullhttp://twitter.com/mathiasverraesPar Mathias Verraes

En keynote, Mathias Verraes nous a parlĂ© de l’importance de rĂ©flechir Ă  notre modĂ©lisation avant d’implĂ©menter une solution. Il part d’un exemple simple de deux stories qui ont le mĂŞme objectif mais Ă©crites d’un point de vue diffĂ©rent :

En tant qu’acheteur,

 je souhaite pouvoir tĂ©lĂ©charger la facture d’un achat

 afin de l’utiliser comme garantie

En tant que vendeur,

 je dois mettre à disposition une facture pour tout achat

 afin de donner un justificatif d’achat au client

De ces deux user stories, la modélisation peut changer car elle est inconsciemment induite par la description de la story et le fait que nous souhaitions coller le modèle de données au plus proche de la réalité.

Au lieu de ça, nous devrions prendre le temps de rĂ©flechir au modèle et notamment aux Ă©vènements qui en dĂ©coulent en s’appuyant sur des questions du type :

  • qu’est-ce qui change ?
  • pourquoi ces changements ?
  • dans quelles circonstances ces changements apparaissent ?
  • qu’est-ce qui les dĂ©clenchent ?

ncrafts1

De plus, l’event storming offre un ensemble de pratiques permettant de rĂ©pondre Ă  ces questions. Cela nous permet de mettre en avant les notions de temps (dĂ©pendances chronologiques du parcours utilisateur), les contraintes, les intentions, etc.

Full-Time Pair-programming
http://twitter.com/houssamfakihPar Houssam Fakih

Tout le monde clame haut et fort que le pair-programming est une solution pour bon nombre de problèmes lorsqu’on souhaite travailler efficacement en Ă©quipe. Houssam nous offre dans ce talk un retour d’expĂ©rience de trois annĂ©es de pair-programming non-stop.

Le parallèle qu’il effectue avec le sport et notamment l’haltĂ©rophilie est dĂ©routant : nous sommes invitĂ©s Ă  regarder ensemble des vidĂ©os YouTube de sportifs en train de soulever de la fonte. Pourtant c’est complètement appropriĂ© avec son discours sur les qualitĂ©s qu’il faut possĂ©der pour pratiquer le pair-programming Ă  plein temps. Tout est une question de coordination : pour que la magie opère il faut dès le dĂ©part discuter sur l’objectif de la session de coding afin que les deux dĂ©veloppeurs soient bien alignĂ©s. Il est primordial de rester focalisĂ© sur la tâche pour limiter le temps de switch lorsqu’on s’Ă©change le clavier. La vitesse de dĂ©veloppement doit Ă©galement ĂŞtre adaptĂ©e au moins rapide pour progressivement l’amener vers une vĂ©locitĂ© plus Ă©levĂ©e lors de sa montĂ©e en compĂ©tence sur le projet. Ne vous privez jamais du feedback que vous procure un nouvel arrivant dans l’Ă©quipe.

pairprogramming.jpg

Houssam nous prĂ©vient : pair-programmer est fatiguant et il faut savoir se mĂ©nager. Faire des pauses rĂ©gulières pour s’aĂ©rer le corps et l’esprit.

D’autres points très intĂ©ressants sont Ă©voquĂ©s : la flexibilitĂ©, la balance, la propriĂ©tĂ© du code, le partage de connaissances, l’unicitĂ© de la configuration et des outils pour toute l’Ă©quipe. Ce n’est pas parce qu’on pair-programme qu’on ne peut pas chercher l’amĂ©lioration continue : il est toujours utile de faire intervenir un coach dans l’Ă©quipe qui analysera d’un point de vue extĂ©rieur comment les pairs travaillent, se relaient et rĂ©alisent la performance de dĂ©livrer le bon logiciel. Notez au passage que ce vocabulaire empruntĂ© au sport prend tout son sens dans ce contexte. À la fin de la session, on peut proposer une petite rĂ©trospective, savoir sortir de sa zone de confort, mesurer le temps de l’Ă©change des rĂ´les driver/navigator ainsi que sa frĂ©quence ou maĂ®triser les outils afin de ne pas frustrer son pair.

xebiaessentials.jpg

Pour rĂ©sumer le pair programming est une pratique très enrichissante. Houssam nous invite Ă©videmment Ă  la pratiquer et mĂŞme Ă  expĂ©rimenter d’autres voies : le cross programming (pairer avec un expert du domaine), le mob programming (pairer avec toute l’Ă©quipe en mĂŞme temps).

L’une des questions en fin de talk a particulièrement retenu l’attention : qu’en est-il des problèmes humains qui sont engendrĂ©s par cette pratique riche en interactions sociales ? La rĂ©ponse de Houssam est assez catĂ©gorique : si le dĂ©veloppeur ne parvient pas Ă  s’intĂ©grer Ă  l’Ă©quipe dont les membres sont nĂ©cessairement tous dĂ©jĂ  "compatibles", il va très vite Ă©mettre le souhait de quitter le projet. Cette intĂ©gration Ă©choue en majoritĂ© Ă  cause du mode de travail collaboratif constant (dont on a finalement pas tant l’habitude que cela – notre système Ă©ducatif est basĂ© quasi exclusivement sur le travail personnel) plutĂ´t que pour des problèmes humains.

Building the future of User Experience
http://twitter.com/VincentGuiguiPar Vincent Guigui

Au dĂ©but de la prĂ©sentation, Vincent a attirĂ© notre attention avec la question suivante : avez-vous remarquĂ© comment peut-on ĂŞtre limitĂ© par les IHMs (Interfaces Homme-Machine) de nos jours ? Imaginez vous devant votre PC, vous vous retrouvez souvent limitĂ© par la taille de l’Ă©cran, obligĂ© de scroller de haut en bas ou de gauche Ă  droite selon l’action rĂ©alisĂ©e. Nous sommes aussi limitĂ©s car dans la plupart des IHMs, lorsqu’on interagit avec un outil, un site ou autre, nous devons taper sur des touches, cocher des cases, scroller, etc. Ne serait-il pas plus simple de juste demander quelque chose avec sa voix, ou de faire des signes, par exemple ? Nous avons besoin de davantage interagir avec les systèmes qui nous entourent et ce le plus naturellement possible.

Pour améliorer cela, le futur imaginé nous permettra d’utiliser davantage nos sens :
  • le son en utilisant des hauts parleurs directionnels qui sauraient interagir avec la bonne personne,
  • le touchĂ© grâce au retour haptic par exemple,
  • l’odeur pour manipuler l’humeur (et reproduire l’envie qui nait en nous lorsqu’on passe devant une boulangerie).
En plus de nos sens, il rendra nos objets du quotidien plus intelligents :
  • utiliser sa bague pour gĂ©rer le volume,
  • nos chaussettes pourraient nous alerter quand on marche trop vite,
  • mĂŞme chose pour les fourchettes et le fait de manger trop rapidement,
  • ou encore les ceintures et les quantitĂ©s mangĂ©es,
  • les brosses Ă  dents pourraient nous indiquer la qualitĂ© de notre brossage en plus de la durĂ©e minimum,
  • etc.

Ce futur n’est pas si lointain, les choses sont en train de changer. Vincent nous donne beaucoup d’exemples d’applications ou dispositifs qui sont en cours de construction ou sont dĂ©jĂ  arrivĂ©s pour nous aider Ă  amĂ©liorer nos interactions avec les machines. Voici quelques uns :

  • La Kinect de Microsoft aujourd’hui nous permet d’interagir avec une application tout simplement en bougeant son corps,
  • L’Oculus Rift et HoloLens nous offrent des belles perspectives pour le futur avec la rĂ©alitĂ© augmentĂ©e.

L’expĂ©rience utilisateur est en train d’Ă©voluer pour justement se rapprocher plus de l’utilisateur, pour rentre nos interactions avec nos appareils et services plus intuitives, plus naturelles. 

Enterprise Tic-Tac-Toe
http://twitter.com/ScottWlaschinPar Scott Wlaschin

Rien que le titre de ce talk est inspirant : que viennent faire accolĂ©s l’un Ă  l’autre le qualificatif souvent associĂ© dans notre industrie Ă  l’artillerie lourde et le nom d’un jeu simpliste ? C’est tout l’intĂ©rĂŞt du sujet proposĂ© par Scott : nous montrer que la programmation fonctionnelle peut apporter des rĂ©ponses simples Ă  des problèmes qualifiĂ©s de compliquĂ©s ou de transverses dans nos projets.

Tout d’abord, que regroupe ce terme entreprise (attention du second degrĂ© a Ă©tĂ© malicieusement insĂ©rĂ© dans cette Ă©numĂ©ration) ?

  1. sĂ©paration des responsabilitĂ©s (NdT: separation of concerns) : parce que bien souvent les Ă©quipes ne s’aiment pas et ne veulent pas savoir ce que les autres font, il est bon de bien dĂ©couper les responsabilitĂ©s
  2. sécurisation : parce que les développeurs du backend ne font pas confiance aux développeurs du frontend
  3. documentation : parce que l’Ă©quipe de maintenance n’a pas le niveau pour lire le code
  4. scalabilité : parce que le directeur technique veut se construire un CV à base de mot-clés à la mode

En programmation fonctionnelle, une partie de la sĂ©curitĂ© nĂ©cessaire dans un projet peut ĂŞtre implĂ©mentĂ©e par un système de type consistant : en effet, puisqu’on ne fait pas confiance Ă  l’interface utilisateur qui va mal gĂ©rer les états du système, les conversions de types primitifs ou l’Ă©tat interne du système alors le passage systĂ©matique par des types explicites limite les cas d’erreurs.

Pour garantir une certaine sĂ©paration des responsabilitĂ©s, Scott nous expose alors un concept que nous connaissons sous le terme de Generics et qui se nomme Parametric Polymorphism en programmation fonctionnelle. Cela permet par exemple au tic-tac-toe de masquer l’Ă©tat interne du jeu Ă  l’interface tout en conservant ce paramètre au fur et Ă  mesure des appels.

Comment fournir un log systĂ©matique des appels en programmation fonctionnelle ? En utilisant de l’AOP, des annotations java ou des attributs .net, de l’instrumentation de bytecode ? Rien de tout cela : il suffit de composer les fonctions (l’opĂ©rateur >>) afin d’entourer sa fonction principale par des logs sur les paramètres ou les valeurs de retour.

Une fois que notre programme fonctionne, le frontend web aura besoin de nous invoquer avec un format proche de ses technologies et de son formalisme habituel : HTTP et JSON. Cependant le type de retour du tic tac toe pour l’instant n’est pas JSON friendly : il comporte de nombreux dĂ©tails d’implĂ©mentations inutiles voire dangereux d’exposer aux clients. C’est pourquoi un nouveau type de retour est introduit pour ce besoin : ApiResult.

MĂŞme avec ce type spĂ©cifique un problème persiste : le JSON ne respecte pas le système de type que l’on manipule avec un langage fonctionnel. Le client peut toujours nous envoyer une payload qui ne pourra pas ĂŞtre transformĂ©e en type. Par exemple si on doit Ă©crire un programme qui gère le stockage d’un fichier de configuration :

  1. type File : c’est bien trop dangereux,
  2. type TextWriter : le client peut Ă©crire n’importe quoi dans le fichier de configuration,
  3. interface clĂ©/valeur : ce n’est pas encore type safe,
  4. interface avec toutes les fonctions possibles : l’Ă©tat n’est pas bien gĂ©rĂ©,
  5. interface avec seulement une seule fonction : dans ce cas le client n’a d’autre choix que d’utiliser la fonction de crĂ©ation/mise Ă  jour de la configuration.

C’est l’application du Principle Of Least Priority ou capability based security. Le bon effet de bord d’implĂ©menter la sĂ©curitĂ© est que cela induit souvent un bon design. Dans le tic tac toe, cela se traduit par le changement du type GameState en NextMoveInfo avec une seule fonction disponible : MoveCapability. Scott nous montre ensuite sa mise en application avec l’instanciation d’un vrai jeu qu’il fait tourner devant nous. Nous constatons que ça peut paraĂ®tre compliquĂ© de parser les rĂ©ponses et de les renvoyer au prochain tour. C’est Ă  ce moment que HATEOAS est mentionnĂ©. Pour l’implĂ©menter en F#, il encode ses NextMoveInfo en guid. Le bĂ©nĂ©fice principal est que c’est bien le serveur qui a la maĂ®trise du schĂ©ma et que c’est au client d’interprĂ©ter les liens plutĂ´t que de devoir connaĂ®tre les URI Ă  l’avance. Cela permet un dĂ©couplage clair entre client et serveur.

En rĂ©sumĂ©, cette confĂ©rence est un excellent exemple de ce qu’il est possible de faire avec un langage fonctionnel de nos jours. De plus le ton rĂ©solument second degrĂ© du sujet entretien l’intĂ©rĂŞt durant toute la prĂ©sentation. Le cĂ´tĂ© dĂ©monstration avec le code F# qui s’exĂ©cute devant nos yeux dans Visual Studio fini de captiver les dĂ©veloppeurs que nous sommes.

When DDD meets documentation
http://twitter.com/cyriuxPar Cyrille Martraire

Pour chauffer la salle, Cyrille commence par nous faire un petite dĂ©mo d’un synthĂ©tiseur analogique avec lequel il peut gĂ©nĂ©rer du pitch, de l’echo et toute sorte d’effets. Rien Ă  voir avec la confĂ©rence mais ça permet de dĂ©tendre l’atmosphère.

Puis il enchaine avec ses slides Ă  un rythme ultra rapide, Ă  base de gif animĂ©s et de mots en plein Ă©cran pour maintenir l’attention. Sur la forme : c’est une très bonne surprise.

Le pitch du talk de Cyrille est accrocheur : la documentation peut-ĂŞtre au moins aussi cool que le code ! D’habitude, la rĂ©daction d’une documentation est une souffrance, souvent peu Ă  jour : bref on a l’impression que ça ne sert Ă  rien et que c’est inutile. En fait, il faut complètement revoir notre rapport Ă  la documentation et inverser les responsabilitĂ©s : ce n’est pas au dĂ©veloppeur de documenter son code, c’est le code qui doit s’auto-documenter pour le dĂ©veloppeur.

cyriux.jpg

Mais quel est le lien entre la documentation et le DDD ? Les deux notions sont centrĂ©es autour de la connaissance du domaine. OĂą doit-on mettre la connaissance ? Comment transfĂ©rer cette connaissance vers des vraies documentations ? Votre objectif aujourd’hui avec la documentation est de ne pas la rĂ©diger vous mĂŞme mais bien de la gĂ©nĂ©rer Ă  partir des mĂ©ta-donnĂ©es dĂ©jĂ  disponibles : l’exemple du BDD est particulièrement parlant. C’est une documentation exĂ©cutable qui sera toujours Ă  jour car elle est la prĂ©-condition Ă  la livraison du logiciel.

En DDD, on peut ajouter des annotations autour des notions comme le bounded context ou des core concepts qui permettent de dégager un glossaire toujours à jour.

Si vous respectez l’architecture hexagonale, vous pouvez tirer parti de vos packages ou de vos annotations pour gĂ©nĂ©rer un diagramme avec les types internes au domaine versus les ports et adapters en interface du domaine. Vous pouvez mĂŞme dĂ©bogguer votre design en dĂ©tectant des anomalies comme une dĂ©pendance externe Ă  votre bounded context. Si vous avez du mal Ă  gĂ©nĂ©rer un diagramme qui vous parait pourtant simple ? Vous venez de dĂ©bogguer votre design : refactorez pour que la gĂ©nĂ©ration soit plus simple et vous constaterez Ă©galement une simplification dans la conception.

La clĂ©, c’est de gĂ©nĂ©rer les graphiques les plus simples possibles : prenez votre base de code et retirez tout le superflux. Le maĂ®tre mot, c’est un diagramme pour un usage, une histoire.

Vous pouvez utiliser certains outils de génération de diagrammes à partir de simples fichiers textes. Ces fichiers pourront être placés au plus près du code, mis en gestion de configuration et mis à jour en même temps que le code en lui même lorsque vous faites évoluer votre logiciel.

D’autres examples de gĂ©nĂ©ration de documentation sont mentionnĂ©s par Cyrille : gĂ©nĂ©rez un nuage de tags de vos types, vos noms de variables et vos fonctions pour connaitre la qualitĂ© de votre ubiquitous langage ; demandez Ă  votre logiciel de vous expliquer les rĂ©sultats qu’il vous rend.

ncrafts5

Voici d’autres phrases choc qui peuvent vraiment vous faire changer la vision que vous vous faites de la documentation :

  1. si vous connaissez votre design et que vous savez ce que vous faîtes, votre documentation est déjà à moitié générée,
  2. si vous écrivez des tests et du code de qualité, la documentation sera quasiment gratuite,
  3. le talent requis pour Ă©crire une bonne documentation est similaire au talent requis pour introduire un bon design.

Le mot de la fin de cet excellent et rafraichissant talk de Cyrille est le suivant : la documentation est seulement emprisonnĂ©e dans votre code. Vous n’avez qu’Ă  la libĂ©rer !

Hands’ on: you are a seasoned TDD practitioner? Join us in the battle agains the kata diamond!
http://twitter.com/morlhonPar Jean-Laurent de Morlhon
http://twitter.com/brunoboucardPar Bruno Boucard

Que serait une confĂ©rence sur le craft sans un vrai coding dojo ? Les experts du domaine Jean-Laurent et Bruno nous ont proposĂ© un kata dont la simplicitĂ© de l’Ă©noncĂ© n’avait d’Ă©gal que le challenge pour l’implĂ©menter. MalgrĂ© une salle relativement petite et bien chauffĂ©e par la matière grise en fonctionnement, la plupart des pairs sont venus Ă  bout de l’exercice. Mais comme bien souvent dans ces Ă©vènements, le plus important n’est pas le rĂ©sultat mais bien le chemin pris pour y arriver.

 

C’est pourquoi nous avons passĂ© environ une demie heure Ă  dĂ©briefer sur notre session de code. Cet exercice est intĂ©ressant pour savoir si le TDD peut vraiment nous aider. En effet, dès le second ou le troisième test, on arrive vite Ă  bloquer sur l’implĂ©mentation KISS et il faut se retrousser les manches pour imaginer l’algorithme final. Or, le TDD permet tout de mĂŞme d’avancer en baby step si on se donne le temps de tester des parties plus petites du rĂ©sultat attendu.

Je vous encourage à pratiquer ce kata pour vous faire une idée de ce que nous avons expérimenté durant ces deux heures.

Catégories: Blog Société

NewsLetter des Participants aux formations ĂŠtre Agile

ĂŠtre Agile - Thierry Cros - dim, 05/31/2015 - 20:58

etre-agile.png Vous avez participé à une formation Être agile (Extreme Programming, Scrum, Kanban...). Vous pouvez souscrire à la NewsLetter qui vous est réservée.

Cette NewsLetter est mensuelle.
Pour accéder au formulaire de souscription, cliquez sur le lien suivant.
Je souhaite souscrire Ă  la NewsLetter des Participants aux formations ĂŠtre Agile

NewsLetter ĂŠtre Agile

Catégories: Blog Individuel

Vision et Lean Startup : les slides #JournéeAgile Mons 27 mai 2015

ĂŠtre Agile - Thierry Cros - ven, 05/29/2015 - 06:42

leanStartupVision.jpg Après l'article Vision et Lean Startup, voici donc les slides utilisés lors de la conférence Journée agile à Mons le 27 mai 2015.
D'une certaine manière, les quatre piliers de la keynote consacrée au bonheur au travail - liberté, responsabilité, bonheur au travail, performance - sont une vision d'une transformation.

Vision_et_Lean_Startup : les slides

Quelques liens complémentaires

Lean Startup

Vision

Catégories: Blog Individuel

Retour sur la Maker Faire Paris 2015

ekito people - mar, 05/26/2015 - 00:00

Les 2 et 3 mai, c’Ă©tait la Maker Faire Paris, Ă©dition 2015. Après une journĂ©e sur place, il est temps d’en faire le compte-rendu de rigueur.

Qu’est-ce qu’une Maker Faire ?

Faisons simple, et reprenons le mĂŞme paragraphe que pour le billet sur l’Ă©dition prĂ©cĂ©dente.

Le nom de Maker Faire peut se comprendre comme « Foire aux fabricants », « Faire » étant une forme vieillie du mot « Fair » signifiant « Foire », et comme un jeu de mots entre « Maker » (fabricant) et « Faire » (le verbe français). Donc une Maker Faire est la grand-messe des adeptes du mouvement des makers, dédiée au DIY (Do It Yourself) et DIWO (Do It With Others). On y trouve autant les makers eux-mêmes, qui viennent y présenter leurs dernières inventions (que ce soit dans le domaine pratique, ludique, éducatif ou artistique), que les fabricants de matériel dédié à ces derniers (à savoir : imprimantes 3D, graveuses et découpeuses, matériel de prototypage électronique, etc.)

Pour information, la Maker Faire est une manifestation sous licence, les droits sur les noms et logos étant détenus par le magazine Make.

Quoi de neuf cette année ?

Tout d’abord, le lieu : cette Ă©dition 2015 de la Maker Faire a dĂ©mĂ©nagĂ© du bâtiment du Cent Quatre Ă  un pavillon de la foire de Paris. Si l’espace dĂ©diĂ© aux stands n’a pas vraiment augmentĂ© (si on ne compte pas la zone dĂ©diĂ©e aux drones volants), la frĂ©quentation a Ă©tĂ© complètement boostĂ©e.

#MFP15 "35.000 participants pour la 2ème édition de la @MakerFaireParis" @Bertier_Luyt (pour rappel: 8.000 en 2014) pic.twitter.com/49H1X89RQm

— Makery France (@makeryfr) May 3, 2015

Deuxième changement : autant l’Ă©dition prĂ©cĂ©dente Ă©tait restĂ©e relativement confidentielle, autant cette annĂ©e nous avons eu droit aux petits plats dans les grands avec un discours d’ouverture par Axelle Lemaire. Et il faut l’avouer, mĂŞme si elle avait inaugurĂ© le Grand Builder, je ne l’ai absolument pas reconnue (se lever Ă  3h45 pour prendre l’avion n’aidant pas non plus).

Une maker faire à l'Elysée?Pourquoi pas, selon Axelle Lemaire "L'esprit maker plaît au gouvernement" #MFP15 @makeryfr pic.twitter.com/2GuKzuc13n

— carine claude (@carine_claude) May 2, 2015

Que pouvait-on y voir ?

MĂŞme si certains stands prĂ©sents Ă©taient dĂ©jĂ  lĂ  l’annĂ©e dernière, il y a heureusement quelques nouveautĂ©s. La liste ci-dessous n’est pas exhaustive, n’ayant Ă©tĂ© prĂ©sent que le samedi, d’autant plus qu’il semblerait qu’il y ait eu quelques stands diffĂ©rents le dimanche.

Côté drones

Comme indiquĂ© prĂ©cĂ©demment, la Maker Faire accueillait cette annĂ©e une zone dĂ©diĂ©e aux drones volants, protĂ©gĂ©e du reste du pavillon par un filet de sĂ©curitĂ© allant jusqu’au plafond. Malheureusement, Ă  part quelques rares essais, je n’ai pas pu assister Ă  de vĂ©ritables dĂ©monstrations.

009 - Zone de vol

 

Autre petit drone sympathique, celui fait par un FabLab Ă©tudiant, PMCLab. Taille rĂ©duite, contrĂ´le via Bluetooth Low Energy (qu’est-ce donc ?), et structure faite Ă  l’aide d’une imprimante 3D.

015 - PMCLab - BlueDrone

Côté robotique

Tout d’abord, le projet Arpel. Il s’agit d’un assistant de rĂ©Ă©ducation post-traumatique via un exosquelette. Ce projet est actuellement Ă  l’Ă©tat de prototype fonctionnel.

024 - Arpel

 

Toujours dans la catégorie du bras robotisé, cette réalisation de Vladimir Kadir, âgé seulement de 16 ans : un bras robotisé, principalement composé de pièces de récupération.

016 - Robotic hand

Se baladait dans le pavillon un mini-dalek autonome. Je n’ai malheureusement pas pensĂ© Ă  le prendre en photo, mais il ne lui manquait que la parole.

Pour terminer sur le sujet de la robotique, nous avons eu droit à quelques prestations du groupe « One Love Machine Band », entièrement composé de robots.

Côté ateliers

Parmi les ateliers prĂ©sents, deux ont eu un succès monstre : l’atelier de soudure Ă©lectronique, et l’atelier de dĂ©coupe. Le premier permettait de faire un petit badge lumineux en soudant quelques composants sur un circuit en forme de Makey. Le second laissait aux visiteurs des scies Ă  chantourner Ă©lectriques afin que ces derniers puissent dĂ©couper les formes qu’ils souhaitaient dans du bois. Après essai, autant le premier atelier s’est dĂ©roulĂ© sans gros problème, autant le second a souffert d’une erreur… d’aiguillage.

020 - Atelier soudure 021 - Atelier découpe Côte impression 3D

Peu de grosses nouveautĂ©s cĂ´tĂ© impression 3D cette annĂ©e. PlutĂ´t une consolidation des tendances de l’an dernier : les imprimantes en kit ont toujours la cĂ´te, les filaments spĂ©ciaux (base plastique + ajout de bois, mĂ©tal, fibre de carbones) se sont plus montrĂ©s que l’an dernier, etc. Le tout mis bout Ă  bout semble signer une maturitĂ© de la technologie de dĂ©pose de filament fondu.

Ă€ noter, une imprimante 3D Ă  filament d’un volume assez consĂ©quent : la Volum3DMax 110, avec un volume d’impression de 40cm x 50cm x 55cm.

005 - Volum3DMax

 

D’un point de vue logiciels, Ă  part la quasi-omniprĂ©sence de Sketchup (avec des dĂ©monstrations de personnes qui savent vraiment l’utiliser), j’ai pu remarquer un nouveau venu, orientĂ© vers les dĂ©butants : 3DSlash. Le but de ce logiciel est d’usiner un cube faisant jusqu’à 256 pouces d’arĂŞte afin d’obtenir la forme souhaitĂ©e. Il est utilisable en ligne, ou bien une version pour Windows, OS X ou Linux peut ĂŞtre tĂ©lĂ©chargĂ©e.

3DSlash

Côté gravure laser

Contrairement Ă  ce que j’espĂ©rais, il n’y a pas eu Ă©normĂ©ment de graveuses laser en kit prĂ©sentĂ©es cette annĂ©e. Le seul modèle qui a retenu mon attention est LaserBot, une graveuse laser sur roues lui permettant de graver sur des longueurs importantes (elle a Ă©tĂ© initialement crĂ©Ă©e afin de graver des planches de surf).

003 - LaserBot 004 - LaserBot Divers

Le projet (toulousaing !) Thingz, basĂ© sur un Arduino, promet d’apprendre Ă  utiliser ce dernier de manière plus simple Ă  l’aide de modules pouvant ĂŞtre branchĂ©s sans se prĂ©occuper du sens de branchement. J’ai trouvĂ© l’idĂ©e assez sympathique, mĂŞme si les fonctions fournies (du moins celles listĂ©es dans le manuel) ne laissent pour le moment pas Ă©normĂ©ment de marge sur ce que l’on peut en faire. Par contre, pour des dĂ©butants, c’est tip-top.

006 - Thingz

 

Suite au projet ayant consistĂ© Ă  travailler avec des Spheros, je n’ai pu m’empĂŞcher de remarquer cette Sphero modifiĂ©e afin d’ĂŞtre plus… imposante :-)

018 - Sphero

Et pour finir, la machine Ă  rendre les gens heureux, qui Ă©tait encore en construction le samedi.

#mfp15 la machine Ă  rendre les gens heureux se construit au fur et Ă  mesure du week-end, selon les suggestions des visiteurs #bubulles #diwo #diy #makerfaireparis

A video posted by Makery France (@makeryfr) on May 3, 2015 at 5:45am PDT

 

The post Retour sur la Maker Faire Paris 2015 appeared first on ekito people.

Catégories: Blog Société

Retour sur DevoxxFR 2015 CDI

Le blog des experts du groupe Infotel - ven, 05/22/2015 - 15:31
Cette annĂ©e encore, de nombreux Infoteliens ont participĂ© au Devoxx France qui s’est tenu pendant 3 jours du 8 au 10 juin au Palais des Congrès de Paris. François NASSOY nous fait un retour sur CDI Introduction Contexts and Dependancy … Lire la suite →
Catégories: Blog Société

Événement #Startup #BackToBasics

ekito people - dim, 05/17/2015 - 23:01

Venez participer à notre événement #Startup #BackToBasics le mardi 9 juin, de 12h à 13h30.

Même format que notre précédent événement, Pitch Me Up, mais avec un contenu légèrement différent.

Le principe : venez présenter à vos collègues startupeurs vos trois fondamentaux :

  • la douleur que vous adressez (i.e., les problèmes de vos clients)
  • votre cible ; qui ils sont, leurs profils, ce qui les fait rĂ©agir…
  • vos canaux d’acquisition ; ceux mis en place, et Ă©ventuellement ceux testĂ©s puis rejetĂ©s
Startup Back To Basics Problem Cible Canaux

Back to Basics

Chaque moment de partage durera 5 minutes.
Puis une courte séance de questions-réponses avec le public, pour qu’il vous challenge ou vous propose des idées.

Partagez vos 3 fondamentaux : douleur, cible et acquisition.

Au premier hors-sujet hop, carton jaune !
Attention à ne pas déraper… ce sont vos collègues startupeurs qui vous surveilleront.

La préparation de votre présentation est l’occasion parfaite d’un peu d’introspection et de prise de recul :

  • La douleur que vous adressez est-elle aiguĂ« ? Votre cible en a-t’elle un niveau de conscience suffisant ?
  • Connaissez-vous vraiment votre cible, pouvez-vous l’affiner ?
  • Pouvez-vous prouver ces points ? Ou certains sont-ils encore Ă  l’état d’hypothèses non vĂ©rifiĂ©es ?
Pourquoi ne parler que de ces 3 composants ?

Nous rencontrons trop souvent des entrepreneurs, qui par envie de travailler au plus vite sur la solution perdent de l’énergie en créant une startup qui repose sur un problème qui n’en est pas un.
Et ça… c’est un vrai problème :-) !

Fondations instables

MĂŞme si tout semble avancer… sur des fondations instables la chute est garantie !

 

Local maxima

Au moins la chute force Ă  ouvrir les yeux. Le pire serait de ne jamais arriver Ă  franchir un palier, sans comprendre pourquoi.

Format

On n’a pas vraiment changĂ© d’avis sur l’utilitĂ© et la valeur d’un pitch. Donc :

  • Interdiction absolue de parler de vous (votre startup, votre Ă©quipe, votre super nom !)
  • Interdiction absolue de parler de votre proposition de valeur, votre solution
  • Interdiction absolue de parler de tous les trucs supers cool et qui marchent super bien auprès des B.A.
  • Interdiction absolue de parler de vos mĂ©triques off-the-charts, vos recrutements, etc. Bref, vous avez compris, tout ce qui n’est pas votre #Problème, votre #Cible ou votre stratĂ©gie d’#Acquisition. #BackToBasics :)
Infos plaisir

Notre Chef en résidence cuisinera des assiettes complètes que vous pourrez acheter sur place (6,5 €), et nous vous offrirons les boissons.

abc

Dom, notre Chef en résidence en train de réfléchir à votre futur menu.

 

Détails pratiques

Camping Toulouselogo_ekito_big

Cet événement est co-organisé par Le Camping Toulouse et ekito.

Il est ouvert à toutes les startups, qu’elles soient co-produites par ekito, en présélection, au Camping, à La Passerelle, dans une pépinière privée ou publique, un petit peu de tout ou bien rien de tout ça.

Inscription gratuite et obligatoire, par ce formulaire.

Rendez-vous au GrandBuilder, 15 rue Gabriel Péri, à 12h pour commencer à se rencontrer, manger et boire un coup. Début des présentations à 12h30, pour que chacun puisse retourner travailler à 13h30 maximum.

Vous pouvez venir assister sans présenter vos bases. Mais inscrivez-vous quand même.

Enfin, si vous n’ĂŞtes pas dispo le mardi 9, nous avons d’autres Ă©vĂ©nements pour vous :

Ă€ bientĂ´t !

The post Événement #Startup #BackToBasics appeared first on ekito people.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux