Note de lecture : SQL Server DMVs in Action, par Ian W. Stirk

Note : 5 ; Plus centré sur des cas d’utilisation que sur l’exploration des possibilités des DMVs

Les « dynamic management views » ou DMV constituent la mécanique permettant d’interroger SQL Server sur son comportement, les optimisations possibles. Elles sont une source d’information extrêmement précieuse pour améliorer les capacités de SQL Server en production ! Un livre consacré à cette mine d’information était donc susceptible d’élargir mon horizon sur l’exploitation de SQL Server.

J’ai hélas été déçu par l’approche empruntée : Au lieu d’explorer de manière systématique et organisée les possibilités offertes par les DMVs, les auteurs ont orienté leur approche sur les cas d’utilisation. Cette approche n’est pas mauvaise en soi, car elle a l’avantage du pragmatisme : vous recherchez comment optimiser les temps d’attente ? L’un des cas d’utilisation et le script associé en parlent ! Vous voulez améliorer l’indexation des tables : idem ! Par contre, difficile de dire si l’on a laissé de côté des informations plus exotiques mais qui pourraient s’avérer intéressantes. On n’a pas une très bonne idée de ce que l’on a couvert ou pas une fois la lecture terminée.

Concernant les sous-ensembles couverts, certains ne le sont pas, comme les DMVs liées à Service Broker, alors que les DMVs de la CLR le sont ! Un curieux choix éditorial. Dois-je préciser que j’ai hardiment sauté la partie consacrée à la CLR.

Parmi les choses intéressantes, on notera les recettes de cuisines pour l’exploitation des DMV, comme l’utilisation des doubles snapshots pour faire de la synthèse soustractive de valeurs.

Bref, le livre me laisse un peu sur ma faim, bien que beaucoup de matériel soit largement et directement exploitable. On notera aussi que cette approche par les cas d’utilisation correspond parfaitement à la philosophie de la série « in action » de l’éditeur.

image

Référence complète : SQL Server DMVs in Action : Better queries with dynamic management views – Ian W. Stirk – Manning 2011 – ISBN : 978 1 935182 73 3

SQL Server DMVs in Action

https://www.goodreads.com/book/add_to_books_widget_frame/1935182730?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Publicités

Gojko Adzic : Making impact !

L’association We Do Product Management nous proposait ce 11 Mars une soirée exceptionnelle avec 2 orateurs. Gojko Adzic himself nous proposera une présentation sur le thème “making impact” tandis que Nicolas Gouy nous gratifiera d’un développement autour de l’Agile with GUTS !

Zenika accueillait cette soirée : un grand merci à Sébastien Sacard et Lisa Marçais du côté du WDPM, et aussi à Al chez Zenika pour son aide avant, pendant et après la soirée !

On commence d’ailleurs par une petite présentation du WDPM avant d’attaquer les choses sérieuses.

image

Making Impact par Gojko Adzic

La définition amont d’un produit se heurte à des facteurs d’imprédictabilité. Facteurs que l’on connait par ailleurs depuis plus de 100 ans :

  • Le facteur local
  • Le facteur temps
  • Le facteur Humain

Ces facteurs ont été identifiés par Peter Palchinsky. Dans The Ghost of the Executed Engineer, les auteurs reviennent sur certains désastres de l’Union Soviétique illustrant les facteurs de Palchinsky. Intéressons-nous spécifiquement à l’un d’entre-eux: le canal de la Baltique à la Mer Blanche.

image

Ce canal peut être considéré comme un succès, car il a bel et bien vu le jour, comme prévu. Cependant, il échoue aux 3 critères da Palchinsky et malgré son existence c’est effectivement un échec cuisant :

  • Le facteur temps : la construction du canal n’a pas anticipé l’évolution des cargos. En définitive, le canal s’est avéré rapidement trop peu profond pour les nouveaux navires !
  • Le facteur local : Sa situation septentrionale le rend gelé, donc impraticable 6 mois par an !
  • Le facteur humain : creusé à main d’hommes par des prisonniers dans des conditions extrêmes, il aura coûté le vie à 200000 d’entre-eux !

Autre exemple d’échec : le PC Junior d’IBM. Cette aventure coûta à IBM pas moins de 2 milliards de dollars ! Et pourtant, le géant de l’informatique ne fit jamais que délivrer exactement ce que l’utilisateur voulait ! Mais il échoua sur l’imprédictabilité du facteur humain.

D’un point de vue du Product Manager, on tend à planifier comme si tout était sous notre contrôle. Il faut au contraire créer des plans à même d’exploiter cette imprédictabilité au lieu de la combattre vainement.

Rechercher de nouvelles idées, essayer de nouvelles choses.

Cette approche trouve une incarnation dans le Set Based Design, l’aptitude à essayer différentes solutions en éliminant progressivement les moins valables.

En 2002 (ou était-ce en 2003 ?) Ducati se lance dans l’aventure Moto GP. Plutôt que d’essayer de construire d’emblée la meilleure moto, les ingénieurs conçoivent un engin sur lequel ils peuvent essayer multitude d’options. Après des débuts laborieux, celle-ci devient redoutable en seconde moitié de saison et l’écurie finit 2nd au championat constructeur !

Vous courrez après le déploiement continu ? Mais qu’en est-il de votre capacité à multiplier les versions, les comparer, créer des variations ? Cette approche permet d’expérimenter et d’apprendre. Bref essayer de nouvelles idées pour comprendre dans quelle direction il convient de se diriger !

La survivabilité

Le principe est simple : si votre expérimentation échoue, que les dommages en soit minimes … en tout cas que cela ne fasse pas couler l’entreprise !

Les connaissances et les pratiques d’ingénierie sont là … mais pas l’état d’esprit du product management !

Selection

Il faut faire le nettoyage sur ce qui ne sert à rien ou ce qui a échoué. En développement logiciel on ne supprime jamais rien (on garde, on ne sait jamais…). Et ce code ou ces composants morts deviennent un passif qui nous empêche d’avancer.

Non aux roadmaps, oui aux map of roads"

Mauvaise nouvelle pour les agilistes : le Product Manager n’est pas intéressé par les User Stories ! Ou plutôt, il est intéressé par leur faible granularité et leur côté “survivable” !

C’est le boulot du Product Manager de se créer des options, et les User Stories sont un bon outil pour cela : explorer des directions, sélectionner, changer d’option … bref tout sauf un plan linéaire ! Quelque chose qui ressemblerait à un plan avec un GPS pour s’y diriger. Ce GPS, c’est l’impact Mapping !

L’alignement rapide avec l’impact Mapping

L’impact mapping, c’est avant tout 4 questions pour arriver à une meilleure solution : 

  • Pourquoi ?
  • Qui ?
  • Comment ?
  • Quoi ?

Ce framework nous aide, car il nous évite de nous enfermer dans une logique unidirectionnelle, il nous permet d’explorer des variations : cette hypothèse contribue-t-elle au pourquoi ? Dois changer le “quoi” … ou m’intéresser à un autre acteur… S’il est parfois difficile de déterminer le pourquoi, les clients ont souvent moins de mal à dire ce qu’ils ne veulent pas. C’est un autre moyen d’arriver à nos fins !

On peut rapprocher l’approche Impact Mapping du Design Thinking : se générer des options, les explorer et les éliminer ! On a changé le mode dialogue au niveau du product management : on est passé du sacro-saint périmètre aux options et à leur contribution à un objectif…

Nicolas Gouy : Agile with GUTS

Nicolas est l’auteur d’un ebook portant ce titre et publié par infoQ.

image

Désolé pour la piètre qualité de la photo, vraiment l’éclairage (ou son absence, plutôt) m’a rendu la tâche difficile…

Parlons de valeur

Tout d’abord, c’est une notion subjective ! Et comme l’a indiqué précédemment Gojko Adzic, elle est subordonnée aux facteurs d’imprédicatabilité. Histoire de bien commencer, et de commencer fort (je dois dire), Nicolas nous parle des Shreddies. Les voici en image, pour illustrer le propos.

image

En passant d’un modèle à l’autre (sic !), Schreddies a vu son chiffre d’affaire s’envoler : la valeur n’est pas une question de sens commun ! Mais cela se travaille. Pourtant, sur nos projets agile, nous arrêtons notre horizon au backlog, comme si ce qu’il y avait avant était tabou !

Dans GUTS, il y a “G”, et ce “G”, c’est le Goals ! Notre but, c’est d’avoir un impact en étant en empathie avec notre client.

Le “U” quand à lui, c’est “Uncertainty”, et nous retrouvons les éléments que nous a partagé Gojko juste avant : il nous faut être à l’aise avec cela, et même en tirer parti. Comment ? En “crash testant” nos idées, en les validant au plus tôt.

Le “T” est plus original, car il s’agit du “Trade Off”. La solution parfaite est rarement un but désiré et raisonnable : il faut faire des compromis intelligents. Sur ce point, je ne suis pas sûr d’avoir compris ce que Nicolas voulait dire (exprimé plus simplement : je n’ai en fait rien compris). Bon, je verrais cela plus tard…

Le “S” signifie lui “Speed”. Une notion qui devrait remplacer celle de vélocité. Si la seconde notion couvre l’idée d’abattre plus de travail en moins de temps, la seconde consiste plutôt à atteindre un but plus rapidement … donc à être intelligent sur la manière d’y arriver ! C’est donc en fait remplacer la notion de périmètre par celle d’objectifs !

Quand on met l’acronyme ensemble, eh bien on parle bien entendu de “courage”. Et avoir du courage, c’est savoir être pertinent : toujours chercher à faire plus avec moins !

Molecular Structure of Nucleic Acids

Un article qui marque l’histoire des sciences n’est pas nécessairement un monument. L’article original de Watson et Crick décrivant la structure de l’ADN, la fameuse double hélice tient en un peu moins de deux pages de l’édition de Nature datant du 25 Avril 1953. Il vaudra aux deux auteurs associés à Wilkins, le prix Nobel de médecine en 1962.

Pour l’anecdote, le dessin de la double hélice est dû à Odile Crick, la femme de l’un des auteurs, peintre de profession. Ce dessin est par ailleurs la seule oeuvre pour laquelle elle est connue.

Moins drôle : le point de départ de l’article de Watson et Crick est une photographie, connue sous le nom de “photo 51”, prise par Rosalyn Franklin, que Wilkins a montré aux deux auteurs sans en informer sa collègue ! Voici la photo en question

image

Rosalyn Franklin apparait uniquement dans les remerciements de l’article, une bien piètre reconnaissance de sa contribution par ailleurs involontaire !

Rendez-vous au Scrum Day 2014 !

Cette année le ScrumDay change de lieu ! La belle affaire me direz-vous : il a changé de lieu presque chaque année ! Mais cette fois, il quitte le centre de Paris pour aller chez Mickey.

Rassurez-vous, je suis presque sûr que nous ne serons pas obligé de nous coiffer d’une paire d’oreilles signées Walt Disney. J’animerais pour ma part un atelier avec mon collègue Benoit Nouyrigat. Allons-y pour une petite présentation : c’est l’Acceptance Tests Workshop !

Teaser, teaser…

Le développement guidé par les acceptance tests devient un standard dans le monde agile. Cela signifie que les tests fonctionnels seront au moins décrits avant le début des développement.

Mais partant de là, il existe de nombreuses façons de procéder, de multiples variations.

Cet atelier s’articule autour d’une pratique que nous utilisons régulièrement : l’acceptance test workshop. Il s’appuis sur l’intelligence collective pour faire émerger les tests fonctionnels pour valider le développement et assurer la compréhension partagée des fonctionnalités attendues.

Cet atelier vous donnera l’opportunité de pratiquer cette nouvelle technique sur des exemples que vous aurez construit. 

Comment ça marche ?

Les participants à cet atelier forment des équipes de 4 à 5 personnes. A partir d’une courte étude de cas, ils devront élaborer quelques users stories sur la base desquels ils devront décliner des tests d’acceptance en groupe en revêtant des Personna (développeur, Product Owner, Testeur, etc.).

Lors d’une première phase, on cherchera à décrire les tests sous forme libre, en se concentrant sure la couverture de la specification en cas passants et non-passants.

La seconde phase accentuera l’aspect formel des spécification de tests via la formalisation Given / When / Then utilisée pour les tests BDD (Behavior Driven Development).

Voilà, vous savez (presque) tout sur ce quii se passera durant cette atelier. Libre à vous de vous joindre à moi et à Benoit !

Rendez-vous au Scrum Day 2014 !

ScrumBeer de Mars (en images)

Cela aurait dû être une ScrumBeer de Février, mais une collision de dates avec l’Agile Playground en a décidé autrement. C’est donc début Mars que nous nous sommes retrouvés en petit comité d’agilistes !

C’est dans un bar faisant la place belle aux jeux (et à la bière, bien sûr) que nous nous sommes retrouvés.

image

Outre nos discussions de comptoir habituelles, Arnaud nous proposait d’apporter notre contribution aux revues des propositions du ScrumDay 2014.

J’ai dit : le ScrumDay 2014 !

image

Après une rapide selection initiale, revue des propositions en binômes.

image

J’ai eu le plaisir de me livrer à l’exercice avec Pablo Pernot dont je dois dire que je le croise trop peu souvent !

image

L’exercice est intéressant, mais je le vois plutôt dans ce contexte comme une agréable récréation. J’espère que le comité de sélection ne regardera pas le résultat de nos cogitations de manière trop appuyée, d’autant que le filtrage initial a été particulièrement arbitraire !

Il faut un peu varier les plaisirs lors de nos rencontres. Mais pas trop quand même : les discussions, le p’tit verre de rouge ou la bière et la charcuterie, ça reste notre fond de commerce !

image