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

Live from Atlassian Summit: breaking product news

Le blog de Valiantys - jeu, 10/13/2016 - 00:42

It was in front of a 3,200-strong audience that Mike Cannon-Brookes took to the stage to officially open the 2016 Atlassian Summit. Sharing details of the event’s 75 sessions across seven tracks, Mike was quick to thank the attending customers, ecosystem partners and AUG leaders, highlighting their role in driving the continued success of what is today ...

The post Live from Atlassian Summit: breaking product news appeared first on Valiantys Blog - Atlassian Expert.

Catégories: Blog Société

SOAT lance le Paris Redis Meetup

Rejoignez la communautĂ© des utilisateurs et des curieux de Redis ! Ce Meetup est un lieu de partage oĂą chacun est invitĂ© Ă  proposer des prĂ©sentations, des workshops ou des retours d’expĂ©rience. LA SOIRÉE DE LANCEMENT DU MEET’UP AURA LIEU LE 24 OCTOBRE ! Pour ce tout premier Meet’Up, GrĂ©gory Boissinot, CTO chez SOAT, vous […]
Catégories: Blog Société

SOAT présent à l’Agile Tour Bordeaux !

Les 28 et 29 octobre prochains, retrouvez Aldrik Kleber, l’un de nos Coachs, Ă  l’Agile Tour Bordeaux. Il y prĂ©sentera sa confĂ©rence Matrix Agility : arrĂŞtons de parler agilitĂ© et soyons agile ! Le descriptif : Je souhaiterais vous faire part d’une rĂ©vĂ©lation surprenante. J’ai longtemps observĂ© les agilistes et ce qui m’est apparu quand […]
Catégories: Blog Société

SOAT vous donne rendez-vous à l’Agile Tour Lille

Retrouvez GĂ©raldine Legris, Coach Agile chez SOAT, les 13 et 14 octobre 2016 lors de l’Agile Tour Lille. Vous la retrouverez lors d’un atelier, Gothamocratie, quand Gotham City adopte l’holacratie qu’elle co-animera avec Pablo Pernot et Dragos Dreptate. Le descriptif : Il s’agit de dĂ©couvrir au travers de la ville de Gotham City le modèle […]
Catégories: Blog Société

[Microsoft Experiences’16] Tester, Monitorer et Déployer son application mobile

Dans cette session sous-titrĂ©e “Permis de tester”, Nicolas Humann, Adrien Siffermann et Philippe Sentenac nous accueillent pour nous faire dĂ©couvrir les usages du « testing mobile » et comment Visual Studio Team Services, Xamarin Test Cloud & Hockey App, permettent d’amĂ©liorer la qualitĂ© des applications mobiles pour iOS, Android & Windows. Visual Studio Team Services […]
Catégories: Blog Société

JS et Programmation Fonctionnelle - Part 1

Taverne d'Arma - Programmation - mar, 09/13/2016 - 11:20

Je vais me lancer sur une série d'articles concernant la programmation fonctionnelle, appliquer au monde JS. L'objectif pour moi est de préparer, à terme, une présentation sur le sujet. Aujourd'hui, je vais donc commencer par les bases : c'est quoi au juste la programmation fonctionnelle.

Du rĂ´le de la fonction

Fonctionnelle comme fonction. Mais la fonction dont on parle ici correspond-elle au mots-clés 'function' de notre langage ? Presque, mais pas tout à fait. En fonctionnel, une fonction est un élément prévisible qui prend des paramètres entrants et qui renvoies une nouvelle valeur. Cela implique que :

  • Les paramètres entrants ne sont pas modifiĂ©s
  • Le retour de la fonction est un nouvel objet ou une nouvelle valeur
  • Tout appel avec des paramètres identiques renvoi le mĂŞme rĂ©sultat

Les avantages de ce type de fonction sont multiples :

  • Meilleure testabilitĂ© : elles ne dĂ©pendent pas d'un Ă©tat.
  • Meilleure reproductibilitĂ© : si l'on trouve un bug, il suffit de rappeler la fonction avec les mĂŞmes paramètres pour obtenir les mĂŞmes rĂ©sultats.
  • Meilleurs "scalabilitĂ©" : on ne mute pas les objets, il n'y aura donc pas de problème de concurrences sur des threads diffĂ©rents.
De l'immutabilité

Je viens de glisser le point dans le dernier avantage, mais l'un des grands principes de la programmation fonctionnelle est de tirer à maximum parti d'objet immutable : c'est-à-dire un objet qui ne peut pas être modifié. La conséquence, c'est qu'à chaque fois que l'on veut modifier un objet, nous allons créer une nouvelle instance complètement indépendant de l'objet.

Encore une fois les avantages sont multiples :

  • La scalabilitĂ©, comme abordĂ© plus haut.
  • La limitation des effets de bord : vu que l'on ne modifie pas un objet, l'on ne risque pas de modifier par inadvertance un objet qui aurait Ă©tĂ© transmis Ă  d'autres parties de l'application.

Bien entendu, la plupart des applications ne peuvent pas être 100% immutable : l'idée est d'isoler au maximum les endroits où un état est mémorisé et de ne faire ces mutations que de manières conscientes et complètement volontaire.

De la programmation déclarative

La programmation impérative met en avant le "comment" : ajoute 1 au compteur, passe à l'élément suivant, modifie tel caractère, ... L'objectif de la programmation déclarative est de s'attacher au "quoi". Pour s'approcher au maximum de ce style, la programmation fonctionnelle, mais en avant non pas les données, mais les traitements : le but est de décrire des chaînes de traitement qui vont s'appliquer aux données.

Prenons l'exemple très simple d'une somme. En impératif :

function sum(vals) {
  var total = 0;
  for(var i = 0; i < vals.length; i++) {
    total = total + vals[i];
  }
  return sum;
}

Et en fonctionnelle :

function sum(vals) {
  return vals.reduce(add);

  function add(e1, e2) {
    return e1 + e2;
  }
}

Le code est équivalent, mais dans le second cas, il décrit l'intention : réduire la liste en additionnant ses éléments.

Pour résumé

La programmation fonctionnelle a pour objectif :

  • d'amĂ©liorer la lisibilitĂ© du code (style impĂ©ratif).
  • de faire du code plus facile Ă  tester et Ă  debugger (pas d'effet de bord).
  • d'ĂŞtre plus rĂ©sistant aux concurrences.

Par contre, l'immutabilité est une contrainte qui demande une certaine discipline à l'usage.

Fonctionnelle versus POO

Souvent, ces deux paradigmes de programmations sont mis en oppositions. Faut-il faire de la POO, ou faut-il faire du fonctionnelle ? Aujourd'hui, je pense sincèrement qu'il faut faire les deux :

  • La POO permet de bien structurer son application et d'y faciliter la navigation
  • Le fonctionnelle permet de rendre son code plus lisible

Utiliser les deux, c'est avoir accès aux forces de chacun. Pourquoi se priver ?

Catégories: Blog Individuel

Specification by example et documentation vivante

Specification by example & documentation vivanteEn 2015,  avec Brice nous avons prĂ©sentĂ© une session Ă  Agile Grenoble intitulĂ©e “Specification by example : venez assister Ă  la naissance d’une documentation vivante”. Depuis nous avons prĂ©sentĂ© Ă  plusieurs reprises cette session qui est Ă  chaque fois accueillie avec enthousiasme. Elle se compose en 3 parties : prĂ©sentation de la thĂ©orie, un exemple concret interactif et un retour d’expĂ©rience. La collaboration Ă©tant ag15_logo_speaker_blancau cĹ“ur de ce processus, cette mĂ©thode implique tous les intervenants d’un projet : analystes mĂ©tier, dĂ©veloppeurs, testeurs et managers.

Des exemples utiles à différentes phases du projet

Comme l’explique le livre de Gojko Adzic, travailler avec des exemples est intéressant lors des différentes phases du projet :

  • ComprĂ©hension partagĂ©e : en amont du dĂ©veloppement, travailler avec des exemples permet de lever des ambiguĂŻtĂ©s et de s’assurer que l’on parle bien des mĂŞmes choses. De plus si tous les intervenants sont impliquĂ©s Ă  cette phase, cela joue aussi sur la dynamique d’équipe.
  • Acceptance test : dès le dĂ©but du dĂ©veloppement, l’exemple est entrĂ© dans l’outil d’automatisation. Il devient un « acceptance test » de la double boucle TDD. Il prend alors un  rĂ´le de pense bĂŞte : il reste rouge tout le long du dĂ©veloppement et passe vert lorsque le logiciel satisfait toutes les exigences.
  • Regression test: une fois vert l’exemple change encore d’objectif. Il sert maintenant Ă  dĂ©tecter les rĂ©gressions. Un bon exemple nous indique dans quelle fonctionnalitĂ© s’est glissĂ© le bug.
  • Documentation vivante: un autre aspect est maintenant de jouer un rĂ´le  documentaire de l’application. Cette documentation Ă©volue en mĂŞme temps que le logiciel et est vĂ©rifiĂ©e en continu.  Il arrive parfois que l’ajout d’une fonctionnalitĂ© rende obsolète certaines contraintes qui avaient Ă©tĂ© ajoutĂ©es prĂ©cĂ©demment. En passant rouge, les exemples nous indiquent l’impact du changement.
Où se trouve la poule aux œufs d’or ?

8218-FX-6-0-13-6-9-0-90-5-5-95-95Cette mĂ©thode n’est pas magique. Son implĂ©mentation demande des efforts et un changement culturel. Aussi j’insiste rĂ©gulièrement sur le fait que cette mĂ©thode apporte Ă©normĂ©ment de valeur sur l’Ă©tape de comprĂ©hension partagĂ©e et de documentation vivante.

A mon sens, il n’y a pas d’autres mĂ©thodes qui challengent autant l’expression du besoin et la documentation. Aussi comme trop d’information tue l’information, quand je suis face Ă  des questions sur l’exhaustivitĂ© oĂą la qualitĂ© des exemples, j’essaye d’identifier Ă  quelle phase profite l’exemple. Si j’investis sur la documentation, l’exemple a certainement de la valeur. Par contre si je rajoute des exemples uniquement pour me protĂ©ger de la rĂ©gression, j’essaye de voir si je ne peux pas les rajouter dans d’autres tests (robustesse, intĂ©gration, etc…)

La phase de compréhension partagée porte en elle même beaucoup de valeur. A cette étape c’est le besoin qui est challengé. Les « product owners » doivent illustrer le besoin par des exemples concrets. En ayant des représentants de l’équipe métier, développement et test, l’interaction des différents points de vue va enrichir l’idée initiale.

Dans l’exemple pratique de la présentation, nous tentons d’illustrer l’impact du changement en ajoutant une règle qui est incohérente avec une autre. Sur cette simulation cela semble simpliste, mais nous avons récemment vécu cette illustration :

Nous voulions légèrement modifier un calcul affiché à l’écran. Il était difficile, tant le système était complexe, de détecter que cela rendait obsolète une autre fonctionnalité.

Pour moi l’efficacitĂ© de cette mĂ©thode est Ă  rapprocher du principe « Mutal Benefit » de eXtrem Programming : une mĂŞme activitĂ© (la rĂ©daction d’un exemple) apporte de la valeur dès l’instant prĂ©sent. Le principe est d’Ă©crire un exemple parce que cela est utile maintenant pour dĂ©finir ce que doit faire l’application. Pas uniquement parce qu’un jour il va potentiellement servir. En automatisant la vĂ©rification de l’exemple on rĂ©cupère les fruits de cet investissement tout au long de la vie du projet.

Emblem-question.svgLes questions qui reviennent souvent

Lors de nos diverses présentations certaines questions sont récurrentes. En voici quelques-unes :

  • Vous parlez de pyramide des tests, n’êtes-vous pas en train de faire une pyramide inversĂ©s ?
    • Effectivement, le nombre d’exemples augmente avec le temps et le besoin de documentation. Cependant ce n’est qu’une partie des tests. Nous nous en servons comme test d’acceptance et de nombreux tests unitaires sont Ă©crits en mĂŞme temps que le code. Notez que cette documentation est très utile pour les testeurs pendant les recettes lors des phases de livraison.
  • Est-ce que l’approche est similaire Ă  celle du TDD ? C’est-Ă -dire que si on n’arrive pas Ă  tester c’est qu’il y a un problème de design ?
    • Par le fait d’automatiser des exemples, il y a forcĂ©ment une influence sur le design. Cependant ce n’est pas son objectif, le besoin est beaucoup plus chahutĂ© par cette approche. Si le besoin n’est pas très clair, on a une opportunitĂ© de s’en rendre compte dès la phase de comprĂ©hension partagĂ©e. A ce stade le changement coĂ»te moins cher.
  • A propos de l’impact au changement, n’y a-t-il pas moyen de l’identifier avant le dĂ©veloppement ?
    • Effectivement si une incohĂ©rence n’a pas Ă©tĂ© levĂ©e lors de la 1ère phase, ce n’est que lorsque le code va ĂŞtre modifiĂ© que l’on va savoir quel est l’impact du changement. Cependant comme cette incohĂ©rence est connue, cela permet de statuer et de mettre Ă  jour la documentation. On a alors une nouvelle source de vĂ©ritĂ© sur ce que fait l’application (l’autre Ă©tant le code).
  • Quel est le coĂ»t pour la mise en place de cette mĂ©thode ?
    • Ce n’est pas facile de rĂ©pondre Ă  cette question quantitativement. Cela dĂ©pend de l’organisation mise en place. Sur notre projet, les dĂ©veloppeurs ont pris en charge une bonne partie (~20-30% temps de dĂ©veloppement). Cependant tout le monde s’accorde pour dire que cela vaut le coup : l’application a peu de bug, il y a moins d’incomprĂ©hension. C’est aussi l’unique documentation utilisĂ©e par le mĂ©tier, les dĂ©veloppeurs et les testeurs.

J’espère vous avoir donné envie de tenter l’aventure Specification by example. La présentation est disponible sous SlideShare et le code sous GitHub.

The post Specification by example et documentation vivante appeared first on Agilité, Architecture, C++ "in the mix".

Catégories: Blog Individuel

Ouvrir avec l’explorateur vos bibliothèques #SharePoint et #OneDrive…

Le blog de Patrick Guimonet - sam, 09/10/2016 - 16:47
C’est l’une des demandes les plus fréquentes des utilisateurs, comment manipuler les fichiers stockés dans SharePoint et OneDrive dans l’explorateur de Windows. En effet malgré des améliorations significatives dans l’interface, ...
Catégories: Blog Individuel

Contenu Festival #SharePoint et #Office 365 de mai 2016 Ă  Paris #SPSParis

Le blog de Patrick Guimonet - sam, 09/10/2016 - 15:44
Merci à tous pour votre participation au Festival #SharePoint et #Office 365 de mai 2016 à Paris ! En effet, c’est grâce à vous que ces évènements et en particulier le SharePoint Saturday Paris ont été un très grand succès ! Si ce...
Catégories: Blog Individuel

Productivité personelle - Mon organisation

Taverne d'Arma - Programmation - sam, 09/03/2016 - 09:10

J’ai récemment effectué une présentation au boulot concernant la productivité personnelle. Le but était de parler des grands principes partagés par différentes méthodologies (Personal Kanban, GTD, ...). Je comptais partager les slides ici mais, en eux-même, ils n’ont guère d'intérêt. A la place je me suis dit que parler de ma propre organisation serait probablement plus intéressant.

Personal Kanban

Vous avez surement déjà aperçu ses tableaux de post-it a colonne multiple, contenant en général au minimum “Todo, En-Cours, Done”. Personal Kanban est une méthode qui se base dessus et dont les grands principes sont :

  • Toutes nos actions sont des tâches Ă  mettre dans ce tableau.
  • Une tâche va toujours de l’avant, elle ne doit pas reculer.
  • Les colonnes correspondent au “en-cours” sont limitĂ© au nombre de tâche qu’elles peuvent contenir. Quand l’on arrive au plafond, il faut s’arranger pour terminer des tâches.
  • On choisit la tâche que l’on effectue en fonction du contexte (temps dispo, niveau de concentration, lieu, …) et non pas seulement en fonction de la prioritĂ©.

Bref, on retrouve le principe de base des méthodes d’organisations, le recensement des tâches, et on y adjoint un mécanisme nous forçant à terminé les tâches commencés plutôt que d’en prendre une nouvelle.

Au quotidien j’utilise :

  • Des post-it papier, si possible, pour le boulot
  • Un outil informatique (Trello), pour le perso (histoire d’y avoir accès de partout)

Quel que soit l’outil, le point important est de créer une tâche “rapidement” avec un libellé, et potentiellement une “catégorie” (un projet par exemple).

C’est léger et souple d’utilisation, bref, c’est une méthode qui me correspond bien. J’ai tellement fait rentrer le mono-tasking dans mes habitudes qu’en général mon en-cours n’excède pas une tâche.

Pomodoro

En complément du Kanban, je pratique de temps à autres la méthode Pomodoro. C’est en quelque sort mon “mode de productivité” quand j’ai besoin d’être concentré, d’aller vite, et d’abattre beaucoup de travail. Cette méthode est à mon sens très efficace et présente quelques avantages :

  • On se rend compte du temps qui passe.
  • On se force Ă  des crĂ©neaux ininterrompu de concentration.
  • Mais en se prĂ©voyant les breaks nĂ©cessaire Ă  ne pas saturer.

Revers de la médaille : elle demande une discipline que j’ai du mal à appliquer en permanence. C’est pour cela que je la pratique “à la demande” uniquement.

Autres petites pratiques

En dehors de ces méthodologies, il y a aussi quelques principes que j’applique pour booster ma productivité :

  • Pas de notification visuel, ou très peu. Ma boĂ®te reçoit ses mails discrètement et je les consulte quand j’en ai envie, et non dès qu’ils arrivent. J’évite aussi de laisser ouvert les rĂ©seaux sociaux et autres petites pollutions de ce genre. Je prĂ©fère me rĂ©server des moments pour aller les consulter.
  • Je connais mes moments “productifs” : ces pĂ©riodes de la journĂ©es oĂą vous abattez deux fois plus de boulot qu’à tout autre moment. Personnellement c’est entre 7h et 11h que je suis le efficaces. Entre 11h et midi, c’est la catastrophe. Je regagne un peu de productivitĂ© en dĂ©but d’après midi et, fin d’après midi, je commence Ă  saturer et Ă  avoir du mal. Du coup je m’assure de faire les tâches difficile dans ces crĂ©neaux lĂ .
  • Je profite de mes temps de transport pour faire ma veille. Dès qu’un article intĂ©ressant arrivent dans mon flux RSS, je l’envoi sur pocket pour que ma liseuse le rĂ©cupère. Cela m’évite de lire Ă  un moment oĂą je pourrais faire quelque chose de plus profitable. Cerise sur gâteau, je sais aussi que je lit mieux sur ma liseuse que sur Ă©cran.
Catégories: Blog Individuel

Code fonctionnel en PHP

Taverne d'Arma - Programmation - lun, 08/29/2016 - 12:38

Ah le php... Une technologie que je n'apprécie guère pour des tas de bonnes et mauvaises raisons. Mais il faut bien lui reconnaître une qualité : il est très facile de lui trouver un hébergement.

Mais là n'est pas le sujet du jour ! Un nouveau projet s'ouvre à moi et, bien qu'il soit en php, je n'ai pas envie de mettre de coté mon centre d'interêt du moment : la programmation fonctionnelle. Me voilà donc à chercher comment la mettre en oeuvre en php.

PHP et Closure.

La base de la programmation fonctionnelle, c'est de manipuler des fonctions. Et l'un des outils très utile autour des fonctions, ce sont les Closures : des fonctions qui "embarque" avec elle des variables en plus de leur paramètre entrant.

En php, la closure est un peu particulière car il faut expliciter les variables qui sont utilisable à l'intérieur de la fonction. Elle se déclare ainsi :

function ($param) use ($varEmbarque1, $varEmbarque2) {
    // Mon corps de méthode
    // $varEmbarque1 et $varEmbarque2 sont accessible
}

Un exemple d'utilisation ?

public function raise($event) {
    Arrays::each($this->listeners, function($fn) use($event) {
        call_user_func($fn, $event);
    });
}

Je reviendrai plutard sur le Arrays::each. Ce qui est important ici c'est que each appelle la méthode pour chaque élement du table. La valeur de l'élement est alors donné en paramètre. Ici ma fonction a besoin de deux élements pour fonctionner : une callback contenue dans le tableau, et un évènement à transmettre. L'un est passé en paramètre, l'autre est passé via la closure.

Et si comme moi vous n'aimez pas spécialement les fonctions anonymes (question de lisibilité), vous pouvez appliquer le pattern builder :

public function raise($event) {
    Arrays:each($this->listeners, $this->emit(event));
}

// (DomainEvent) -> (Fn) -> ()
private function emit($event) {
    return function($fn) use($event) {
        call_user_func($fn, $event);
    };
}
Manipulations de collections et plus si affinité.

map, filter, ... Ces petites fonctions de manipulations de collections sont le premier outil issue du fonctionnel que j'ai utilisé. Je les trouve tellement confortable que je n'ai pas envie de m'en passer.

Malheureusement les fonctions fournies par php sont limitées (map, filter et reduce uniquement). En fouillant un peu sur internet, je suis tombé sur underscore.php, une librairie très sympathique qui fournit le panel complet des fonctions de ce genre (all, any, find, ...).

Petit bonus, elle nous offre aussi des fonctions de manipulations de fonctions tels que compose, memoize, once et throttle qui peuvent s'avérer très pratique.

Et enfin, les monades

Dernier outils du fonctionnel : les monades. Je ne les utilise pas encore tout à fait naturellement mais je reconnaîs ce qu'elles peuvent apporter. Cette fois-ci j'ai envie de les utiliser davantage et pour cela, j'ai trouvé la librairie php-functional.

Les monades, ce sont des outils très utiles tels que Either qui présente deux "chemins" (réussite ou échec), avec deux types de retours différents, ou Maybe qui est une autre façon de gérer l'abscence de valeur.

Un exemple d'utilisation :

// (String, String) -> Either[FunctionalError, User]
protected function checkAuthentification($login, $password) {
    return $this->userRepository
        ->findByLogin($login)
        ->bind($this->checkPassword(Password::fromValue($password)));
}

$this->userRepository->findByLogin() est une fonction qui renvoi un Either. Bind permet d'appliquer à la valeur retourné une autre fonction qui renverra elle aussi un Either uniquement dans le cas Right (chemin de succès). La fonction donné à bind sera appellé avec la valeur en paramètre.

A l'intérieur de findByLogin, on va retrouvé deux retour possible :

\Monad\Either\Right::of($user);

ou

\Monad\Either\Left::of(new FunctionalError("Utilisateur inconnu"));

Dans un code classique, j'aurai utilisé un mécanisme d'exception qui aurait pas forcément été aussi lisible.

En sortie de checkAuthentification j'ai toujours une Either. L'appellant pourra donc faire quelque chose comme cela :

// (String, String) -> Either[FunctionalError, User]
public function exec($login, $password) {
    $user = $this->checkAuthentification($login, $password);
    $user->map($this->storeInSession())
         ->map($this->raiseUserConnected());
    return $user;
}

En cas de succès de l'authentification, j'effectue deux fonctions :

  • Stockage en session
  • Lever d'un Ă©vènement

Quand je veut extraire définitivement la valeur de la monade, je peut faire ceci :

$myEither->extract()

Je m'arrêterais ici dans l'explication sur les monades : ils faudraient un article entier (voir plus) pour vraiment démontrer leurs valeurs.

Des commentaires Ă©tranges ?

Vous avez pu apercevoir au-dessus de mes fonctions des commentaires ayant cette forme :

// (String, String) -> Either[FunctionalError, User]

Ces commentaires sont uniquement présent à des fins de documentations. C'est une manière de donner des indications sur les types utilisés sans passé par une phpDoc bien plus verbeuse : je trouve toujours les javadocs / phpdocs aussi useless...

Ces quelques indications me sont bien plus précieuses et sont suffisament légère pour que je garde la discipline de les rajouter à chaque fois.

Catégories: Blog Individuel

[Article extérieur] Déployer Let’s Encrypt sur Heroku et nom de domaine custom chez [OVH]

Mathieu Robin - ven, 08/26/2016 - 09:49

Salut à tous ! ça faisait un bail !

J’ai publiĂ© sur Medium (j’ai voulu essayer), un article nommĂ© « DĂ©ployer Let’s Encrypt sur Heroku et nom de domaine custom chez [OVH]« .

Je vous laisse tout le plaisir de le lire en cliquant sur le lien ci-dessus. Bonne lecture !

Flattr this!

Catégories: Blog Individuel

The Mostly Adequate Guide to FP

Taverne d'Arma - Programmation - jeu, 08/04/2016 - 07:19

En continuant mes recherches a propos de programmation fonctionnelle en javascript, je suis tombé sur un ouvrage disponible gratuitement : The Mostly Adequate Guide to FP. Disponible en ebook ou pour une lecture «en ligne», ce livre d’environ 150 pages abordent les différents aspects de la programmation fonctionnelle de manière plutôt didactique.

Au sommaire : currying, composition, monades et applicative. A mon sens les explications sont un peu moins facile à appréhender que celle-présente dans «Functional Programming in Javascript» mais elles sont tout de même facile à suivre.

Mention spéciale pour le chapitre sur la composition que je trouve vraiment très complet. Ici l’auteur nous présente vraiment une autre manière de développez et d’agencer nos fonctions. Les exemples donnés sont vraiment très parlant et illustre l’intérêt de cette approche. Je pense notamment à des déclarations comme celle-ci qui sont un exemple de concision :

var loudLastUpper = compose(exclaim, toUpperCase, head, reverse);

loudLastUpper(['jumpkick', 'roundhouse', 'uppercut']);
//=> 'UPPERCUT!'

Après la lecture de ces deux ouvrages, me voilà complètement armée pour passer à la pratique ! Et pour m’échauffer, j’ai suivi les exercices de NodeSchool sur le sujet ( «functional javascript» ). Ces exercices n’explore pas la composition ni les monades, mais le reste y passe.

Au passage pour ceux qui ne connaisse pas (et c’étais mon cas il y a quelques jours), NodeSchool est un site vraiment sympa bourré de «tutoriel» sous la forme d’exercice+corrigé. Vraiment très sympa :)

Catégories: Blog Individuel

Retour sur Devoxx 2016 : WildFly Swarm

Le blog des experts du groupe Infotel - ven, 05/20/2016 - 11:04
Cette annĂ©e Devoxx France s’est tenu pendant 3 jours du 20 au 22 avril au Palais des Congrès de Paris. Infotel a permis Ă  de nombreux collaborateurs de participer Ă  cette Ă©ventement. FrĂ©dĂ©ric JOSEPH nous fait un retour sur WildFly … Lire la suite →
Catégories: Blog Société

IaaR !

ĂŠtre Agile - Thierry Cros - ven, 03/04/2016 - 20:06

etre-agile.png IaaR ! est un acronyme :

  • Intention
  • Attention
  • Action
  • RĂ©pĂ©tition.

C'est un "protocole" de transformation qui fait appel aux trois maîtrises de la voie toltèque (Attention, Transformation, Intention).

Intention

D'abord poser une intention.
Respecter ces trois recommandations :

  • Visualisation++ : faire appel Ă  l'imagination pour visualiser une scène correspondant Ă  l'Ă©tat souhaitĂ© et atteint. Le "++" signifie que cette visualisation incorpore non seulement des images, Ă©galement des sons, des sensations... Bref fait appel Ă  plusieurs sens. Au-delĂ  de l'aspect sensoriel, cette visualisation crĂ©atrice possède une dimension Ă©motionnelle : l'esquisse d'un lĂ©ger sourire pourrait apparaitre sur le visage pendant cette visualisation crĂ©atrice ;
  • 100% d'accord : autrement dit "ZĂ©ro doute". Du cĂ´tĂ© du pratiquant c'est comme si c'Ă©tait dĂ©jĂ  fait dans le monde de l'Intention et qu'il restait simplement Ă  rĂ©ifier - rendre rĂ©elle - cette visualisation ;
  • UC 10 : Universe Compliant level 10 se souvenir simplement que nous sommes dans un monde soumis Ă  diffĂ©rentes lois (lĂ©galitĂ© du pays, lois physiques...) et que la rĂ©alisation de l'intention s'inscrit dans ces lois. UC 10 signifie ainsi que le rĂ©sultat dĂ©pend aussi de ces lois.
Attention

Alors, à quoi allons-nous prêter attention afin que cette Intention se réalise ?
Notre perception de la réalité est-elle suffisamment... réaliste ?
Quels indicateurs, quel management visuel, que "sur-veiller"...

Action

Si ce cadre fonctionne grâce à la force de l'Intention, il reste que nous sommes acteurs de la réalisation. Quelles actions envisageons-nous ?

Répétition

Probablement un ingrédient "secret" de ce processus : selon le changement, il est vain d'imaginer qu'une habitude engrammée pendant des décennies va disparaître subitement. Il faudra donc répéter... Et répéter encore jusqu'au succès.
D'autant plus que ce processus itératif offre un espace - bien connu des Agilistes - à la fois de feedback (l'inspection des Scrumiens) et d'amélioration.

Magie !

Lorsque je présente IaaR ! en formation ou accompagnement, j'insiste sur le côté "magique" de cette pratique, fortement inspirée par la voie toltèque telle qu'exprimée par Don Miguel Ruiz (IaaR est un acronyme que j'ai concocté à partir d'un protocole présenté par Don Miguel Ruiz).
Magique car elle fait appel à des "procédés psychologiques" peu ou pas connus généralement.
Magique car elle suppose un certain lâcher-prise, une confiance dans ce pouvoir de l'Intention.

Pratiquer !

Je ne peux que vous engager Ă  pratiquer IaaR !.
Démarrez par une intention simple, qui puisse se concrétiser dans la journée par exemple, pour vous entraîner à cette pratique.
Et faites confiance dans le pouvoir de votre Intention !
Intention ou Foi ou Amour.

teo-compressee.jpg

Toltèque Agile

Catégories: Blog Individuel

Agile en 2016

ĂŠtre Agile - Thierry Cros - mer, 03/02/2016 - 08:47

etre-agile.png L'histoire continue... Un nouveau billet, ma vision de l'agile en 2016. Entre mutations, sacrifices et heureuses surprises.
Mais... Que signifie agile aujourd'hui ? Entre un manifeste tout autant historique qu'abandonné, pertinent sur le fond et obsolète sur la forme... Nous trouvons autant de définition de l'agile qu'il y a d'Agilistes.

Agile : qu'es aco ?

Je tente une définition, sous forme de mindmap, de ce qu'est pour moi l'agile aujourd'hui.

agileMindmap.jpg

Ce triptyque décrit

  • le domaine d'application
  • l'essence de l'agile
  • son intention.
VICA

Une traduction de l'acronyme anglais VUCA. Si l'origine est finalement la prise de conscience de la complexité du développement logiciel, c'est bien de volatilité, d'ambiguïté... Que nous parlons aussi.
Et comme notre monde est de plus en plus complexe, l'agile devient d plus en plus pertinent.
Cela pose la question de la première valeur agile : les personnes et leurs interactions plus que les processus et les outils. Lorsque le système est mieux maitrisé une approche qui priorise les "processus" redevient pertinente.

Empirique

L'image reprend les quatre axes qui me semblent essentiels dans une approche agile empirique. Grosso modo ce sont des principes de l'Extreme Programming.

Équilibres

Après une quinzaine d'années de pratiques j'en arrive à me dire que la finalité de l'agile c'est l'équilibre.

  • Valeur et qualitĂ© : apporter de la valeur aux Utilisateurs, Ă  l'organisation, sans sacrifier la qualitĂ© interne (ou maintenabilitĂ©) dans une lucragilitĂ© dĂ©viante ;
  • responsabilitĂ© et bien-ĂŞtre : l'hĂ©donisme Ă©tait inscrit dans l'agile dès le dĂ©but. Si certains parlent de "bonheur au travail' en ces temps de novlangue oĂą les mots perdent leur sens, je m'en tiens plutĂ´t au bien-ĂŞtre.



Et Toltèque Agile est mon nouveau site.

Agile en 2016 ?

Je constate sur le terrain plusieurs patterns qui reviennent régulièrement.
La qualité est bien souvent sacrifiée sur l'autel de la valeur ajoutée, elle-même malmenée (voir plus loin). Il m'arrive plusieurs fois par an d'entendre un discours tel que "nous faisons de l'agile sur ce produit depuis plusieurs années et nous avons de gros problèmes de qualité...".
De fait il s'agit bien souvent de Scrum et de sa vraie fausse bonne idée : la définition de fini.
Bien entendu, c'est une bonne idée... Lorsque ceux qui l'élaborent ont déjà une bonne notion de ce qu'est "fini" au sens professionnel du terme. Autrement dit, encore faut-il avoir conscience de la nécessité de code propre... Et de ce qu'est un code propre. Dieu merci, il existe des corpus tels que craftsmanship pour élever le niveau.

Valeur... Un glissement sémantique existe entre valeur et priorité. Trier un backlog par priorité, oui. Encore faut-il se poser la question de la qualité de la priorisation. Trop souvent, ce sont les classiques nécessités techniques et/ou fonctionnelles, les diminutions de risques... Qui dictent les priorités au détriment de la qualité.
Si en tant que Product Owner vous planifiez par story d'XP mais finalement avec une stratégie inchangée, êtes-vous vraiment agile ? Pour le moins, monitorez-vous la valeur métier produite (et stockée...) à chaque itération ?

Versions fréquentes... C'est une pratique emblématique de l'Extreme Programming, que l'on retrouve dans le premier principe agile. Or, le célébrissime 'produit partiel potentiel livrable" de Scrum est inconséquent. J'ai rencontré par exemple une équipe qui pratiquait Scrum tout en livrant une version par an... Scrum peut-être, agile certainement pas !

Valorisation des faiseurs... Si effectivement les équipes deviennent plus autonomes (voir toutefois la question du ScrumMaster), il reste que fondamentalement les commerciaux et autres managers sont généralement mieux payés et bénéficient de privilèges (places de parking, voitures de fonction...) que n'ont pas les Faiseurs... It's a long way...

ScrumMaster omniprésent : sans ouvrir le débat sur l'utlité d'un ScrumMaster, il faut quand même se poser la question de sa pertinence dans une équipe agile (je ne parle pas de Scrum). Les Dévelippeurs ont-ils besoin d'un ScrumMaster ? Quand leur réponse est oui, qui choisit la personne en charge de ce rôle ? Au final, ce rôle est-il compatible avec l'auto-organisation consubstantielle à l'agile dans son côté systématique ?

Les Managers deviennent agiles : bien souvent sans avoir la moindre idée de ce que cela signifie, bien au-delà des quelques gentilles pratiques du Management 3.0.

Il reste que l'agile se généralise. Quelle (grande) société aujourd'hui n'a pas expérimenté voire déployé l'agile ?
Peu à peu, la nécessité d'autonomiser les équipes grandit.
La gamification (je t'aime... Ma non troppo) détend un peu les relations. Les Managers prennent conscience que les personnes dans l'équipe sont des êtres humains avant d'être des ressources.

Dans cet ordre d'idée, la question du développement personnel (des Managers mais aussi de tout membre de l'équipe) se pose. Il n'est qu'à voir tous ces Coachs et autres spécialistes de la Mindfulness qui se précipitent vers nous.
Bref... Nous sommes au milieu du pont.
Ce Nouveau Monde que nous inventons est encore empreint de travers de l'ancien.
Mais la dynamique est bien en marche.

Catégories: Blog Individuel

"Exigence" : un terme vraiment agile ?

ĂŠtre Agile - Thierry Cros - jeu, 02/11/2016 - 12:17

etre-agile.png Il vous arrive peut-être de lire ou d'entendre parler d'exigences dans un contexte agile. Avant d'indiquer pourquoi je crois que ce n'est pas très pertinent, je voudrais rappeler un postulat : les mots ont un sens. Non seulement un sens, une histoire.
Les exigences correspondent initialement Ă  une certaine technique d'expression de besoins.

Confusion entre expression de besoins et exigences

Que ce soit via

  • une liste d'exigences
  • une modĂ©lisation d'interactions en cas d'utilisation
  • un ensemble Ă©mergent de user stories de l'Extreme Programming
  • ...

Il s'agit bien d'exprimer des besoins. Autrement dit, le point commun à toutes ces techniques est leur finalité : exprimer des besoins.
Utiliser le terme "exigences" renvoie donc à cette technique ancienne basée sur des listes de besoins parfois classés en besoins fonctionnels, non-fonctionnels...

Exigence ?

Au-delà de l'aspect historique qui renvoie à des pratiques sensiblement différentes, ce terme d'exigence pose un problème sémantique.
La base d'une planification agile est qu'il existe, dans un environnement complexe, une variable d'ajustement des plans. Cette variable peut ĂŞtre

  • le budget
  • la date des livraisons
  • la qualitĂ© (en termes de maintenabilitĂ©, Ă©volutivitĂ©...)
  • le contenu.

Les méthodes agiles telles que XP recommandent de jouer plutôt sur le contenu.
Ce qui signifie que les besoins ne sont - par nature et de façon générale - pas des exigences au sens autoritaire et définitif du terme.

Conduite du changement

Mais je crois que "le pire" dans l'utilisation de ce terme est en terme de conduite de changement. À ce compte-là continuons d'utiliser "chef de projet" pour ScrumMaster ou bien lotissement pour les versions fréquentes mises en exploitation. Cela ne facilite pas la prise de conscience que nous évoquons des rôles, pratiques, principes radicalement différents.

Et donc...

Expression de besoins est le nom donné à cette activité. Remplacer "exigence" par "besoin" me semble donc plus pertinent, par exemple
outil d'expression de besoins plutôt que outils de gestion d'exigences lorsqu'il s'agit de gérer des stories.

Par ailleurs, les règles de gestion et autres "contraintes" à respecter sont reprises d'une part dans des tests d'acceptation (qui constituent une story tout autant que la carte) ou bien dans une définition de fini lorsqu'il s'agit d'éléments communs à plusieurs besoins.

Franchissons vraiment le pont vers la rive agile, ne restons pas au milieu !

Aigle

Catégories: Blog Individuel

Soirée Hazelcast

Paris Java User Group - dim, 11/15/2015 - 17:04

En ces dures moments, nous espérons que vous allez tous bien ainsi que vos familles et votre entourage.

Catégories: Association

Un mois de novembre plein d’activité

Paris Java User Group - ven, 10/30/2015 - 11:10
Un mois de novembre plein d’activité
Catégories: Association

Zenika, sponsor du DevFest

Zenika - mar, 10/13/2015 - 08:34

Toute l’équipe de Zenika Nantes sera au rendez-vous et vous accueillera sur son stand pour cette édition 2015 du DevFest, le 6 novembre 2015 prochain à la Cité des Congrès de Nantes. DevFest_Nantes_2015

Zenika au DevFest Partenaire historique du DevFest et du GDG Nantes, Zenika sera bien présent pour cette 4ème édition d’une journée de conférences autour des thèmes du Web, Cloud & BigData, Mobile & Objects Connectés, Découverte. Matthieu Lux, consultant Zenika responsable de l’offre Web à l’agence Zenika Lyon, initiera un livecoding pour vous... Read Zenika, sponsor du DevFest

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux