Developing in a decade

Posted in Uncategorized

NDC London 2013 – D2 – Juval lowy – the zen of architecture

Le pitch:

Pour l’architecte débutant il y a plein d’options
Pour le senior il ne reste plus que quelques options

L’architecture est l’art de décomposer un grand problème en beaucoup de petits. Pour cela on parle en général de décomposition fonctionnelle, pas technique. La décomposition peut être fonctionnelle mais aussi temporelle (workfkows, séquences).

Mais si on y regarde de plus près est ce que c’est vraiment une bonne solution? Prenons une maison, est qu’on peut vraiment découper la construction d’une maison en fonction de l’usage qu’on voudrait des pièces? Puisqu’on l’a fait comme ça on devrait pouvoir rajouter une chambre à une maison simplement en copiant la définition d’une chambre existante, non?

Une bonne manière de découper un système ne doit pas être base sur les fonctionnalités mais sur la volatilité. Ceci n’est pas spécifique au soft mais fait partie des règles générales de bon design.

On doit donc identifier les zones de changement et les isoler dans des services. L’idee est de minimiser l’impact produit par le changement.

Le problème est que la volatilité n’est pas aussi simple à voir et prévoir que le fonctionnel, que cela prend plus de temps et surtout qu’il doit y avoir une bonne implication du business car ce sont eux qui sont capables de définir les zones de changement du business et donc du système. Puis il y a aussi dans ces phases de conception l’effet Dunning-krugger. . On minimise toujours les impacts du changement.

Les axes de volatilité.
Un système change soit avec le temps, soit avec l’usage qui en est fait, mais dans tous les cas il ne faut jamais designer un système à partir des besoins parce que par définition votre architecture devra changer en fonction de l’evolution des besoins, ce qui sera le cas par définition…

Ces deux axes doivent être indépendants.

Si on reprend l’exemple de la maison et qu’on se concentre sur la volatilité: les meubles peuvent changer, les occupants, l’apparence, les outils…si je déplace la maison les changement seront la situation géographique, les voisins.

Donc si on y regarde bien la pièce pour faire à manger qui nous apparaissait comme un bloc fonctionnel important n’en est pas un. Le vrai besoin est de prendre soin des occupants, et donc de pouvoir les nourrir, pouvoir faire la cuisine à la maison n’est finalement qu’une solution (on peut très bien commander une pizza ou sortir manger au Resto, le besoin initial sera quand même comblé).

Avant de commencer le design d’un système il faut donc essayer de définir une liste des zones de volatilité avant de rentrer plus dans les détails. Puis lors de la mise en place toujours avoir les abstractions nécessaires.

20131205-184243.jpg

20131205-184558.jpg

Pour conclure:

20131205-185945.jpg

20131205-190026.jpg

 

 

Notes: Juval est certes une référence mais il le sait et aime le dire…ça c’est pour le coté négatif. Sinon c’est vraiment un bon talk, avec plein d’énergie et de bon sens. Le concept principal de ce talk qui est la volatilité est vraiment un point important auquel j’étais arrivé il y a quelques années mais sous une forme loin d’être aussi claire et aboutie.

Tagged with: , , ,
Posted in Event

NDC London 2013 – D2 – Gojko Adzic et Christian Hassa – how i stop worrying about flexibility

20131205-162241.jpg

Nous devrions pouvoir commencer a vendre la flexibilité comme un bénéfice et non comme une contrainte. Dans la plus part des cas de la vie courante on paye plus cher pour pouvoir profiter de cela alors que dans notre métier cela fait peur.

A travers un exemple complet, nous voyons une équipe performante utilisant scrum et un burndown chart qui ne descend pas. En fait il descend bien par rapport aux prévisions initiales mais pas avec les nouvelles choses qui sont ajoutées au plan initial au fur et à mesure. Au bout d’un certain temps une fois ce pb identifié, les po décident de couper ds les fonctionnalités, de voir ce qui est vraiment prioritaire et le reste a faire est alors réajusté et descendu à zéro pour pouvoir livrer.

Un des problèmes majeurs de l’adoption agile est bien sur que l’agilite n’est adopté que pour les cycles de développement mais que le produit final n’est finalement présente à l’utilisteur ou client qu’au bout d’un temps long et qu’on a pas gagné grand chose finalement – waterscrum fall.

Aujourd’hui les équipes sont capables de livrer du code rapidement, alors que ce n’etait pas le cas 10 ans avant mais la prochaine étape dans notre métier sera de vraiment amener l’agilite au niveau business.

20131205-163923.jpg

Ce qui nous éloigne de l’idee des roadmap. Celles ci sont mauvaises car elles représentent une pensée et une vision linéaire.

Pour nous guider nous pouvons nous appuyer sur les travaux de palchinsky qui inventa malgré lui le élan il a plus de 100 ans.

20131205-164250.jpg

Dans notre industrie quand nous parlons de roadmaps nous ne parlons pas vraiment de cartes routières avec des options différentes de temps ou trajets mais bien des routes fixes avec une date d’arrivee attendue. Il faudrait pouvoir revenir à quelque chose de plus souple.

Les user stories devraient pouvoir servir de blocs de base mais devraient faire partie d’un contexte permettant de les replacer dans un apport de valeur:

20131205-165824.jpg

20131205-170137.jpg

Ces travaux ont amené la création des impact maps (note: voir le bouquin de gojko sur impact mapping):

20131205-170359.jpg

Ces maps peuvent aussi servir sur du legacy pour commencer une discussion exploratoire avec un client qui permettra d’aider rapidement à la création de valeur:

20131205-170637.jpg

Note: un point important issu d’une question, comment fait ton pour prioriser ? En fait on ne le fait pas, on doit obliger le business a choisir quel sera le prochain impact pour le business et du coup travailler l’itération sur cet impact.

Une autre solution complémentaire ce sont les story maps. On décrit les événements qui décrivent une situation, puis on associe les stories qui pourraient répondre avec le système à ces situations et enfin on est capable de prioriser dans le contexte global du map:

20131205-171803.jpg

D’une manière globale, ces options permettent une collaboration transverse efficace et non linéaire:

20131205-172029.jpg

On doit essayer de faire de l’adaptive planning et le vendre comme un bénéfice de l’agile.

Note: Comme d’habitude, Gojko est impressionnant d’énergie et de conviction sur scene et c’est vraiment un talk agréable à regarder. Au niveau des idées on est vraiment très proches du discours de Jez Humber d’hier. Dans les deux cas, il s’agit de voir comment on peut avoir une boucle de feedback -au niveau business, pas que code- la plus courte et efficace possible.

Tagged with: , , , ,
Posted in Event

NDC london 2013 – D3 – Simon Brown sketching architecture

20131206-090334.jpg

L:architecture represented les decisions significantes où celles ci sont mesurées par le coût de leur changement.

Simon présente un exercice qu’il fait avec ses étudiant, partir d’une liste de besoins, leur laisser 40min et leur demande d’architecturer cela. Le résultat doit être des dessins représentant le système.

On se rends compte de plusieurs choses:
- Le plus difficile n’est pas de concevoir Mais representer les elements
- lord de la presentation des solutions, les gens expliquent des chooses autour de lemurs dessins, ce qui veut dire que le gros des informations est toujours ds leur tête!

Notre industrie s’est beaucoup améliorée ces 10 dernières années avec l’agilite mais rien n’a été fait pour améliorer la représentation des éléments techniques et fonctionnels d’architecture. UML n’etant pas une valide, ou en tout cas pas suffisante.

Sketching architecture
Dessinons des choses simples:

20131206-091331.jpg

The origami sketch(celui qu’on doit plier pour que cela puisse prendre du sens…)

20131206-091503.jpg

Celui qui privilégie la technique:

20131206-091724.jpg

Dans tous les cas, aucune représentation n’est bonne. Le mode de représentation n’est pas clarifié et juste lié à l’interprétation des gens qui on fait les dessins au moment ou ils l’on fait (ces couleurs veulent t’elles dire qq. chose ou c’est juste que les gens avaient des feutres différents?…)

Tout est base sur des suppositions, à la fois au moment de la réalisation des dessins mais aussi après coup au moment de leur lecture…

Tout ça pour se rendre compte que globalement nous n’avons pas les bons moyens de communication

20131206-092557.jpg

Quelques faits supplémentaires:
- collaborative design : faire du pair architecture est bon! (Note: oui oui oui)
- on ne peut tout mettre ds un seul modèle, c’est souvent la source du pb, on essaye de tout mettre ds un dessin
- en général pas besoin d’uml, on se débrouille très bien avec des dessins mais ce qu’il manque c’est un certain formalisme commun
- se poser la question: est ce que vous pourriez coder ce dessin tel quel?

Solutions

Bien mettre des boîtes pour encapsuler ce qui va ensemble

Se mettre d’accord sur un ensemble simple d’abstractions (pas forcément de notation standard)

Définir progressivement le niveau de détail avec l’approche C4:

.

20131206-093204.jpg

Les 4 C:

Contexte
- que construisons nous, qui l’utilise (acteur, rôles, personés…), comment cela rentre ds le système

Containers
- qu’elles sont les décisions techniques de haut niveau, comment les containers communiquent, en tant que développeur ou Vait je devoir mette mon code

20131206-094038.jpg

Components
- de quels composants, service le container est constitué, est ce que les choix et responsabilités sont clairs?

Component
Vue détaillée d’un composant. Faire attention à ce niveau de détail à ne pas mettre de noms mais plutôt de décrire des responsabilités (le nom peut être mal interprété alors que la signification restera)

Trucs supplémentaires:
- dessiner sur papier ou bobard mais utiliser des post It pour les boîtes,
- toujours se poser la question de comment on coderait un truc juste pour voir si on a le niveau d’infos supplémentaires

Des dessins efficaces restent le meilleur moyen de communiquer sur une architecture. Cela devrait faire partie des choses que tous les développeurs devraient apprendre à mieux faire.

Ces dessins sont des moyens de communication avant tout mais ce ne sont pas des modèles précis, quand vous en avez besoin faites de l’uml.

D’une forme agile, il s’agit avant tout pour chacun de trouver la bonne abstraction et de trouver ce qui marche le mieux pour son équipe.

Pour finir une petite réduction sur son bouquin valable 1 semaine:

20131206-095512.jpg

Tagged with: , , , ,
Posted in Event, Uncategorized

NDC London 2013 – D2 – Richard astbury – actor model with orleans

Nous nous posons tout d’abord la question du pourquoi du modèle acteur: fin du paradigme de Moore, difficultés du multi threadig, etc…

Par rapport aux archi multi couches elles déplacent en général les pb de concurrence au niveau de la base. Cette dernière présente le nœud du problème en termes de scalabilite et de concurrence. De la même manière les bases distribuées en mémoire ne font que cacher le pb et cqrs tout en apportant une solution acceptable par le compromis de la consistance éventuelle n’apporte pas solution réellement satisfaisante.

A propos des acteurs, ils apportent 3 choses:
- une unité de calcul
- maintien un état interne mutable
- peut envoyer des messages aux autres acteurs

Ce qu’on remarque tout de suite c’est qu’il n’y a pas d’etat global partagé, donc rien que L’on peut corrompre simplement. Tout cela avec un certain nombre de bénéfices:

20131205-151629.jpg

What is Orleans?

C’est une implémentation du modèle acteur par Microsoft qui tourne sur azure. Il est conçu pour des applications larges en pure c# avec un modèle de programmation qui se veut simple.

Notions:
- grain = acteur
- silo = serveur

Un grain est une classe .net, instance unique sur un seul thread, ses messages son gères par une queue et supporte async. On se rend compte qu’un grain n’est pas très loin dans son modèle d’une instance de node.js.

Un silo, hébergé des grains et gère leur cycle de vie. Supporte le clustering et peut gérer le déplacement d’un grain d’un silo à un autre.

Au niveau architecture, Orléans tourne sur azure avec un worker rôle, des le démarrage il s’enregistre dans une table storage d’azure.

S’en suit une petite DEMO de tout cela qui reste très dans l’esprit demos Microsoft mais qui paraît sympathique au premier abord.

Il n’y toujours aucune info officielle aujourd’hui mais il semble y avoir pas mal d’activité autour en ce moment et des annonces de disponibilité devraient suivre dans les prochaines semaines

n’hésitez pas a suivre Richard sur twitter (@richorama) pour les dernieres news sur Orleaans

Tagged with: , , , ,
Posted in Event

NDC London 2013 – D2 – Uncle Bob – Expectations CEO

Robert c Martin – the reasonable expectations of your new Cto

20131205-114135.jpg

20131205-114222.jpg

Le talk commence comme d’habitude par quelque chose qui n’a rien a voir… On parle de forces, de gravité et de courbure de l’espace. Le tout en jetant une clé USB en l’air – qui aurait coûté des milliards au prix des premières mémoire qu’il a acheté…

Nous arrivons sur le code et la production de code. Le code est partout, par exemple ds un voiture il y a plus de 100 millions de lignes de code – probablement codées par des jeunes tard la nuit et rien que cela devrait nous effrayer!

Mais il arrivera bien un jour ou une catastrophe arrivera en entraînant la mort de piliers de personnes due à une erreur de programmation. A ce moment les politiciens s’indigneront et nous demanderont comment cela a pu arriver. A ce moment la il vaudra mieux être des professionnels et avoir des réponses correctes.

Par exemple avec Challenger, les ingénieurs savaient que la navette n’etait pas sûre et avait prévenu leur hiérarchie de celà mais cette dernière ne les a pas écoutés. Peut être que l’un d’entre eux aurait pu appeler les journaux et prévenir de cela devant le public et peut être que tout cela aurait pu être évité… C’est cela être professionnel, c’est être capable de prendre des responsabilités.

Maintenant, oncle bob prend la casquette de Cto. Quelles sont ses attentes?

Ne pas livrer de la merde, jamais“.

Si on a un doute, on ne livre pas, on fait tout ce qu’il faut pour être sûrs pour pouvoir livrer quelque chose de correct.

Être toujours prets”

Ne jamais être dans un état ou l’on dit qu’il faut attendre de fixer des choses, de préparer des choses pour la livraison, etc…

Aujourd’hui les cycles tournent autour de 2 semaines, mais on se rend compte que les cycles se réduisent de plus en plus avec le temps et que cela s’améliore à chaque fois. Plus le cycle est court plus la boucle de feed-back est courte.

Stable productivité
Il faut faire en sorte que la complexité du système soit stable, ne pas produire du mauvais code, ne pas le compliquer inutilement de sorte qu’il soit aussi de développer le système demain comme dans un an.

Amélioration continue
Afin de garantir la notion précédente, il faut essayer de faire en sorte que le code soit toujours mieux, en tout cas pas plus mauvais après qu’on l’ait touché.

Adaptabilité simple
On doit être capable de s’adapter au changement sans que cela coûte un bras ou prenne plus de temps que d’habitude.

Ne pas avoir peur du changement de notre code”
On a souvent envie de nettoyer du vieux code pourri mais on évite car on a peur de ce qu’on va casser. Il faut éviter ces situations et avoir tout ce qu’il faut pour que cela n’arrive pas. Donc faire des tests, du Tdd.

Extrême qualité
Ne jamais livrer des choses dont on sait qu’elles contiennent des buts et faire tout ce qui est en notre pouvoir pour être sûrs de cela. Il faut faire en sorte que les équipes de tests n’aient rien a faire en fin de projet. Il faut qu’ils soit intègres au début du projet au niveau des spécifications et non plus à la fin.

Automatisation
Les tests manuels ne sont pas un gage de qualité car ils grossissent de manière exponentielle avec le temps et quelqu’un finira par vouloir les supprimer car ils sont trop coûteux.

Rien de fragile
On doit produire du code et des applications robustes, il ne doit pas avoir d’effets de bord, une partie ne doit jamais être impactee par un changement d’une autre partie.

L’equipe doit être solidaire
Il faut travailler ensembles, L’unite est l’equipe, il ne doit pas y avoir de rôles obscurs que l’on ne peut remplacer et qui poseront problème si la personne est malade ou en vacances.

Estimations honnêtes”
Il faut toujours être sûrs de ce que l’on fait et pouvoir garantir ce que l’on a promis. Ce qui implique d’etre capable de dire non quand nos estimations ne sont pas plaisantes à entendre.

Apprendre beaucoup et continuellement”
Il faut réserver du temps en permanence pour toujours s’améliorer, vous êtes responsables de votre carrière.

Mentoring
C’est un des principaux problèmes de notre industrie, être capables d’apprendre les uns des autres. Ne pas jeter des jeunes dans l’industrie avec des responsabilités parce qu’ils n’en sont pas capables à la sortie de l’ecole mais plutôt leur apprendre le métier et partager ses expériences.

Notes: bon, c’est du clean coder tout craché mais c’est sympa de voir énoncer ces principes sous une forme voilà les quelques principes que j’attends de vous développeurs en tant que chef.

20131205-124532.jpg

 

Tagged with: , , , ,
Posted in Event

NDC London 2013 – D2 – Christian weyer – html5,angular and phonegap

Il faut commencer par rappeler l’importance d’une application native: avoir accès aux fonctions natives du téléphone, de meilleures performances, déploiement sur un store…
A l’inverse les applications pures mobiles, sont à priori plus souples mais plus restraintes. Une meilleure approche aujourd’hui semble être une approche hybride.

Si on regarde aujourd’hui html5, il s’agit d’une vrai plateforme complète qui s’enrichi de jours en jours.

Pour cela, on doit décider de ce qu’on veut comme interface. Soit un look and feel identique partout soit une approche native liée au système que l’on targette. On peut aussi choisir de faire quelque chose de dédié complètement différent afin de ne pas avoir à coller à l’une des deux précédentes approches.

Note: s’en suit une prestation rapide de angular, bootstrap que je zappe ici car sans intérêt.

Quelques découvertes sympa au niveau des frameworks css qui s’integrent de mieux en mieux avec angular: chocolatechip-ui, lungo.js avec lungo-angular-bridge ou ionic.js qui s’integrent tous les deux très bien avec angular. L’interet de ça est de garder entièrement le template html et de ne switcher que le css : par ex bootstrap pour le desktop et iconic pour le mobile.

Nous arrivons à phone gap. Démos d’utilisation très simple des commandes de base.

Petit note sur la demo, sur le projet Xcode généré il suffit de faire une petit modification sur le fichier config.xml pour définir la page de démarrage d’une part et la liste des serveurs authorises (que l’on passe à * pour le dev).

Il faut noter aussi qu’il y a aujourd’hui des plugins pour accéder aux fonctions natives sous forme de directives angular afin de profiter simplement du meilleur des deux mondes.

Pour le debug, on note aussi que l’on peu debugger directement le code d’une webview iOS (ce qui portera donc notre code html5 dans l’appli native phonegap) dans safari après avoir connecté le téléphone.

Quelques tops supplémentaires:
- utiliser fastclick.js pour éviter les 300ms de delais normales lies au contexte click touch swippe
- fx pour le multigesture : hammerjs
- tester sur des vrais devices!

Note: Pour ceux qui ont essayé tout cela il y a quelques temps déjà et en avaient été déçus (comme moi :-), les dernières version de phonegap -3.1- fonctionnent vraiment bien et son fiables.

20131205-145202.jpg

 

Tagged with: , , , ,
Posted in Event

NDC London 2013 – day 2

Robert c Martin – the reasonable expectations of your new Cto

20131205-114135.jpg

20131205-114222.jpg

Le talk commence comme d’habitude par quelque chose qui n’a rien a voir… On parle de forces, de gravité et de courbure de l’espace. Le tout en jetant une clé USB en l’air – qui aurait coûté des milliards au prix des premières mémoire qu’il a acheté…

Nous arrivons sur le code et la production de code. Le code est partout, par exemple ds un voiture il y a plus de 100 millions de lignes de code – probablement codées par des jeunes tard la nuit et rien que cela devrait nous effrayer!

Mais il arrivera bien un jour ou une catastrophe arrivera en entraînant la mort de piliers de personnes due à une erreur de programmation. A ce moment les politiciens s’indigneront et nous demanderont comment cela a pu arriver. A ce moment la il vaudra mieux être des professionnels et avoir des réponses correctes.

Par exemple avec Challenger, les ingénieurs savaient que la navette n’etait pas sûre et avait prévenu leur hiérarchie de celà mais cette dernière ne les a pas écoutés. Peut être que l’un d’entre eux aurait pu appeler les journaux et prévenir de cela devant le public et peut être que tout cela aurait pu être évité… C’est cela être professionnel, c’est être capable de prendre des responsabilités.

Maintenant, oncle bob prend la casquette de Cto. Quelles sont ses attentes?

Ne pas livrer de la merde, jamais“.

Si on a un doute, on ne livre pas, on fait tout ce qu’il faut pour être sûrs pour pouvoir livrer quelque chose de correct.

Être toujours prets”

Ne jamais être dans un état ou l’on dit qu’il faut attendre de fixer des choses, de préparer des choses pour la livraison, etc…

Aujourd’hui les cycles tournent autour de 2 semaines, mais on se rend compte que les cycles se réduisent de plus en plus avec le temps et que cela s’améliore à chaque fois. Plus le cycle est court plus la boucle de feed-back est courte.

Stable productivité
Il faut faire en sorte que la complexité du système soit stable, ne pas produire du mauvais code, ne pas le compliquer inutilement de sorte qu’il soit aussi de développer le système demain comme dans un an.

Amélioration continue
Afin de garantir la notion précédente, il faut essayer de faire en sorte que le code soit toujours mieux, en tout cas pas plus mauvais après qu’on l’ait touché.

Adaptabilité simple
On doit être capable de s’adapter au changement sans que cela coûte un bras ou prenne plus de temps que d’habitude.

Ne pas avoir peur du changement de notre code”
On a souvent envie de nettoyer du vieux code pourri mais on évite car on a peur de ce qu’on va casser. Il faut éviter ces situations et avoir tout ce qu’il faut pour que cela n’arrive pas. Donc faire des tests, du Tdd.

Extrême qualité
Ne jamais livrer des choses dont on sait qu’elles contiennent des buts et faire tout ce qui est en notre pouvoir pour être sûrs de cela. Il faut faire en sorte que les équipes de tests n’aient rien a faire en fin de projet. Il faut qu’ils soit intègres au début du projet au niveau des spécifications et non plus à la fin.

Automatisation
Les tests manuels ne sont pas un gage de qualité car ils grossissent de manière exponentielle avec le temps et quelqu’un finira par vouloir les supprimer car ils sont trop coûteux.

Rien de fragile
On doit produire du code et des applications robustes, il ne doit pas avoir d’effets de bord, une partie ne doit jamais être impactee par un changement d’une autre partie.

L’equipe doit être solidaire
Il faut travailler ensembles, L’unite est l’equipe, il ne doit pas y avoir de rôles obscurs que l’on ne peut remplacer et qui poseront problème si la personne est malade ou en vacances.

Estimations honnêtes”
Il faut toujours être sûrs de ce que l’on fait et pouvoir garantir ce que l’on a promis. Ce qui implique d’etre capable de dire non quand nos estimations ne sont pas plaisantes à entendre.

Apprendre beaucoup et continuellement”
Il faut réserver du temps en permanence pour toujours s’améliorer, vous êtes responsables de votre carrière.

Mentoring
C’est un des principaux problèmes de notre industrie, être capables d’apprendre les uns des autres. Ne pas jeter des jeunes dans l’industrie avec des responsabilités parce qu’ils n’en sont pas capables à la sortie de l’ecole mais plutôt leur apprendre le métier et partager ses expériences.

Notes: bon, c’est du clean coder tout craché mais c’est sympa de voir énoncer ces principes sous une forme voilà les quelques principes que j’attends de vous développeurs en tant que chef.

20131205-124532.jpg

Christian weyer – powerfull html5 applications with angular and phonegap

Il faut commencer par rappeler l’importance d’une application native: avoir accès aux fonctions natives du téléphone, de meilleures performances, déploiement sur un store…
A l’inverse les applications pures mobiles, sont à priori plus souples mais plus restraintes. Une meilleure approche aujourd’hui semble être une approche hybride.

Si on regarde aujourd’hui html5, il s’agit d’une vrai plateforme complète qui s’enrichi de jours en jours.

Pour cela, on doit décider de ce qu’on veut comme interface. Soit un look and feel identique partout soit une approche native liée au système que l’on targette. On peut aussi choisir de faire quelque chose de dédié complètement différent afin de ne pas avoir à coller à l’une des deux précédentes approches.

Note: s’en suit une prestation rapide de angular, bootstrap que je zappe ici car sans intérêt.

Quelques découvertes sympa au niveau des frameworks css qui s’integrent de mieux en mieux avec angular: chocolatechip-ui, lungo.js avec lungo-angular-bridge ou ionic.js qui s’integrent tous les deux très bien avec angular. L’interet de ça est de garder entièrement le template html et de ne switcher que le css : par ex bootstrap pour le desktop et iconic pour le mobile.

Nous arrivons à phone gap. Démos d’utilisation très simple des commandes de base.

Petit note sur la demo, sur le projet Xcode généré il suffit de faire une petit modification sur le fichier config.xml pour définir la page de démarrage d’une part et la liste des serveurs authorises (que l’on passe à * pour le dev).

Il faut noter aussi qu’il y a aujourd’hui des plugins pour accéder aux fonctions natives sous forme de directives angular afin de profiter simplement du meilleur des deux mondes.

Pour le debug, on note aussi que l’on peu debugger directement le code d’une webview iOS (ce qui portera donc notre code html5 dans l’appli native phonegap) dans safari après avoir connecté le téléphone.

Quelques tops supplémentaires:
- utiliser fastclick.js pour éviter les 300ms de delais normales lies au contexte click touch swippe
- fx pour le multigesture : hammerjs
- tester sur des vrais devices!

Pour ceux qui ont essayé tout cela il y a quelques temps déjà et en avaient été déçus (comme moi :-), les dernières version de phonegap -3.1- fonctionnent vraiment bien et son fiables.

20131205-145202.jpg

Richard astbury – actor model with orleans
@richorama

Nous nous posons tout d’abord la question du pourquoi du modèle acteur: fin du paradigme de Moore, difficultés du multi threadig, etc…

Par rapport aux archi multi couches elles déplacent en général les pb de concurrence au niveau de la base. Cette dernière présente le nœud du problème en termes de scalabilite et de concurrence. De la même manière les bases distribuées en mémoire ne font que cacher le pb et cqrs tout en apportant une solution acceptable par le compromis de la consistance éventuelle n’apporte pas solution réellement satisfaisante.

A propos des acteurs, ils apportent 3 choses:
- une unité de calcul
- maintien un état interne mutable
- peut envoyer des messages aux autres acteurs

Ce qu’on remarque tout de suite c’est qu’il n’y a pas d’etat global partagé, donc rien que L’on peut corrompre simplement. Tout cela avec un certain nombre de bénéfices:

20131205-151629.jpg

What is Orleans?

C’est une implémentation du modèle acteur par Microsoft qui tourne sur azure. Il est conçu pour des applications larges en pure c# avec un modèle de programmation qui se veut simple.

Notions:
- grain = acteur
- silo = serveur

Un grain est une classe .net, instance unique sur un seul thread, ses messages son gères par une queue et supporte async. On se rend compte qu’un grain n’est pas très loin dans son modèle d’une instance de node.js.

Un silo, hébergé des grains et gère leur cycle de vie. Supporte le clustering et peut gérer le déplacement d’un grain d’un silo à un autre.

Au niveau architecture, Orléans tourne sur azure avec un worker rôle, des le démarrage il s’enregistre dans une table storage d’azure.

S’en suit une petite DEMO de tout cela qui reste très dans l’esprit demos Microsoft mais qui paraît sympathique au premier abord.

Il n’y toujours aucune info officielle aujourd’hui mais il semble y avoir pas mal d’activité autour en ce moment et des annonces de disponibilité devraient suivre dans les prochaines semaines

Juval lowy – the zen of architecture

Le pitch:
Pour l’architecte débutant il y a plein d’options
Pour le senior il ne reste plus que quelques options

L’architecture est l’art de décomposer un grand problème en beaucoup de petits. Pour cela on parle en général de décomposition fonctionnelle, pas technique. La décomposition peut être fonctionnelle mais aussi temporelle (workfkows, séquences).

Mais si on y regarde de plus près est ce que c’est vraiment une bonne solution? Prenons une maison, est qu’on peut vraiment découper la construction d’une maison en fonction de l’usage qu’on voudrait des pièces? Puisqu’on l’a fait comme ça on devrait pouvoir rajouter une chambre à une maison simplement en copiant la définition d’une chambre existante, non?

Une bonne manière de découper un système ne doit pas être base sur les fonctionnalités mais sur la volatilité. Ceci n’est pas spécifique au soft mais fait partie des règles générales de bon design.

On doit donc identifier les zones de changement et les isoler dans des services. L’idee est de minimiser l’impact produit par le changement.

Le problème est que la volatilité n’est pas aussi simple à voir et prévoir que le fonctionnel, que cela prend plus de temps et surtout qu’il doit y avoir une bonne implication du business car ce sont eux qui sont capables de définir les zones de changement du business et donc du système. Puis il y a aussi dans ces phases de conception l’effet Dunning-krugger. . On minimise toujours les impacts du changement.

Les axes de volatilité.
Un système change soit avec le temps, soit avec l’usage qui en est fait, mais dans tous les cas il ne faut jamais designer un système à partir des besoins parce que par définition votre architecture devra changer en fonction de l’evolution des besoins, ce qui sera le cas par définition…

Ces deux axes doivent être indépendants.

Si on reprend l’exemple de la maison et qu’on se concentre sur la volatilité: les meubles peuvent changer, les occupants, l’apparence, les outils…si je déplace la maison les changement seront la situation géographique, les voisins.

Donc si on y regarde bien la pièce pour faire à manger qui nous apparaissait comme un bloc fonctionnel important n’en est pas un. Le vrai besoin est de prendre soin des occupants, et donc de pouvoir les nourrir, pouvoir faire la cuisine à la maison n’est finalement qu’une solution (on peut très bien commander une pizza ou sortir manger au Resto, le besoin initial sera quand même comblé).

Avant de commencer le design d’un système il faut donc essayer de définir une liste des zones de volatilité avant de rentrer plus dans les détails. Puis lors de la mise en place toujours avoir les abstractions nécessaires.

20131205-184243.jpg

20131205-184558.jpg

Pour conclure:

20131205-185945.jpg

20131205-190026.jpg

Posted in Uncategorized

NDC London 2013 – Day one

Voici un petit résumé en texte et images des quelques sessions que j’ai été voir aujourd’hui.

Jon Skeet c#5 async

Jon porte la moustache aujourd’hui, c’est bizarre mais c’est pour une bonne cause :-)

Encore un talk sur async de Jon mais c’est toujours un plaisir de l’écouter et il y a toujours des choses nouvelles.

Tout d’abord, petit rappel, ”Asynchrone” n’est pas le multithreading mais bien le principe de commencer une tâche à un moment et de la finir plus tard.

Async ds c#5 n’a rien de magique mais est la juste pour supprimer le code spaghetti, accidental complexity, qui existait avant – Tasks comprises – dans les versions précédentes de c#. Nous voyons en détail une implémentation complete de machine à état telle qu’elle est implémentée implicitement dans le compilateur lors de l’utilisation d’async/await.

Petit rappel sur l’utilisation de async/await avec des lambdas, pas forcément très lisible au premier abord, mais c’est fou ce que c’est sexy:

20131204-111610.jpg

 

Don syme – Making magic, combining data,information, services and programming

Pour rappel, Don travaille pour MS research et est le créateur de F#.

20131204-120155.jpg

Il met tout d’abord en avant le fait que internet apporte un besoin de manipulation de données sans commune mesure avec ce que l’on avait par le passé ou les quantités de données étaient plus restreintes, leur types moins nombreux et moins changeants.

20131204-115230.jpg

 

Cela amène au fait qu’il y a un vrai besoin dans notre workflow de travail de pouvoir manipuler simplement des données structurées et typées dans le langage et cela sans effort particulier et avec l’outillage nécessaire. Don nous parle donc ici des Type Providers de F#.

Il ne rentre pas dans les détails techniques de la création de nouveaux types adaptés à nos besoins mais nous montre plutot des choses qui existent qui sont incluses dans le packages des types crées par la communauté et comment on peut très simplement et rapidement travailler avec.

par exemple avec le provider Freebase (une sorte de wikipedia en version données structurées):

20131204-121816.jpg

Tout ceci est très simple et dynamique (dans l’édition du code) mais statiquement typé. En termes de fonctionnement:

20131204-122124.jpg

Un autre exemple avec des données en XML:20131204-122503.jpg

F# type providers permettent une manipulation implicite des types à partir des données. De nombreux providers existent déjà créés par la communauté, vous pouvez en avoir un petit apperçu ici: http://blogs.msdn.com/b/dsyme/archive/2013/01/30/twelve-type-providers-in-pictures.aspx

Pour conclure avec une petite image de promo de F#:

20131204-123836.jpg

 

Jez Humble - Lean enterprise

Jez s’intéresse et présente depuis longtemps des choses autour du continuous delivery. De part son travail avec Thoughtworks et Martin Fowler, il a été amené a voir une certaine vision de l’apport de valeur dans la construction d’un produit.

Imaginez les projets comme un portefeuille d’investissements. Est ce que vous voudriez investir tout votre argent dans une seule valeur, de devoir attendre plusieurs années sans savoir ce qui se passe , de savoir que cela serait très cher dans tous les cas et sans être vraiment sûrs d’avoir un retour sur investissement. Cela parait improbable si nous voulions confier notre avenir et nos économies à un courtier qui nous parlerait de placements sous cette forme, mais c’est néanmoins ce que font presque toutes les entreprises quand elles décident de développer un logiciel…

Il faut donc trouver des solutions ou l’on apporte de la valeur plus rapidement et de manière plus sure. Pour en revenir au portefeuille d’actions, c’est justement ce qui est fait. Un certain nombre d’options sont testées en meme temps, certaines ne fonctionnent pas et on le sait très rapidement et quelques unes fonctionnent bien et on doit le savoir rapidement aussi. Leurs gains sont la aussi pour compenser les pertes issues des petits tests improductifs.

20131204-152243.jpg

 

Continuons l’experimentation.
Dans cette recherche, on se pose la question sur les “stories agiles”. Elles pourraient être problématiques dans l’absolu car a aucun moment elles ne précisent la valeur qu’elles apportent au produit. Elles sont utilisées dans l’agilité pour décrire simplement un problème à résoudre, une fonctionnalité à mettre en place, mais elles n’indiquent pas le bénéfice qui en est attendu. Une solution pourrait être le modèle Hypothesis Driven:

20131204-152701.jpg

Sur cette base d’hypotheses il convient de faire des tests ou expériences pour les valider. Pour cela une des meilleures manières est de mettre en production des solutions d’AB testing.

D’ailleurs, Microsoft avec Bing realize ce genre d’experiences plusieurs centaines de fois à un même moment. Quand vous allez sur bind, il y a en fait plusieurs milliers de version différentes (combinaisons d’options testées) du moteur de recherche que les utilisateurs finaux utilisent.

20131204-153317.jpg

 

Une autre vision pour l’apport de valeur est de responsabiliser les équipes et surtout de les organiser autour d’un produit.

Par exemple chez Amazon:

You build it you run it (amazon cto)

Ce principe simple est important car il oblige les équipes a gérer une offre de bout en bout et non plus de créer quelque chose avec lequel d’autres équipes devront se débrouiller. Tout cela s’articule autour de 2 principes:

  • Créer des équipes petites (1 -big- pizza team size, 7-12 people)
  • Organiser ces équipes autour de produits ou services et non plus de projets
  • Isoler ses données produit et ne pas permettre aux autres d’y toucher (pas de super base de données centralisée qui contient la terre entière donc)

20131204-154544.jpg

 

 

 

Les projets tuent la créativité alors que les produits peuvent être en amélioration continue.

Une des idées pour introduire tout cela avec du code legacy ou monolithique existant est d’appliquer les patterns issus de “Strangler application”. Cela se rapproche aussi des couches d’extensions et d’anti-corruption que l’on retrouve dans le DDD. On isole le legacy et on construit petit à petit des silos propres et isolés autour, ce qui vaut mieux qu’une approche big bang ou l’on essaye de jeter tout le legacy pour créer un truc tout neuf (ce qui ne fonctionne jamais)

20131204-155226.jpg

Pour conclure:

  • toujours se concentrer sur l’apport de valeur pour le client
  • s’organiser autour des modèles business et leur cycle de vie pas les projets, les projets tuent l’innovation
  • disrupt tour Own business modèle
  • disrupt tour Own architecture
  • innovation is a mindset

 

Jon skeet – lessons learned from Nodatime.

La gestion du temps a toujours été problématique et même si elle s’est amélioree avec les différentes versions de .net.

Noda Time est d’abord apparu comme un port de la librairie Java joda Time.
Si on commence à creuser un peu les problèmes arrivent vite ne serait ce que avec les Time zone. Mais d’autres problèmes existent : devrait on tenir compte de la relativité, des leap seconds?…sans compter les calendriers ou les journées ne commencent pas à minuit mais à la tombée de la nuit…

Every project should have à Malcolm.

Malcolm est un collègue de Jon qui s’occupe d’un certain nombre de taches sur NodaTime.

Il s’agit d’une personne qui ne va pas toucher beaucoup le code mais qui va s’occuper de la partie édition et des tâches annexes, doc, build, releases,scripts, compatibilité, etc… Il est compliqué d’etre à fond sur le dev d’un projet oss et de gérer ces problèmes en plus.

Note: C’est effectivement un point important et il faut trouver son Malcolm!

Petite session très intéressante sur l’importance de la gestion du temps et comment le System.DateTime actuel est insuffisant. Mais il est aussi très intéressant de voir  comment quelqu’un comme Jon vit un projet open source qu’il a créé. Il nous explique notamment comment même en étant très content du niveau de qualité du code du projet, il se pose des questions sur le niveau de non-utilisation de sa librairie et comment la partie communication d’un projet open source est aussi importante que la qualité de ce qu’elle présente

 

Mark rendle – hidden complexity

Using dynamic for tdd.

Utiliser dynamic au lieu de var peut être très intéressant en tdd car cela passe l’etape de créer quelque chose tout de suite juste pour que ça compile et que le test puisse nous indiquer qu’il ne passe pas. L’écriture de code est plus fluide comme ça et cela améliore la façon dont on peut faire du TDD.

De la même manière on peut se rajouter un helper de type dynamic sur une classe statique pour simuler une factory.

20131204-175354.jpg

Using DynamicObject
En utilisant dynamic object on peut simplement se créer des mocks ou même mieux des règles qui nous permettent par convention de faire un certain nombre de choses et limiter la friction lors du dev en tdd.

Abusing operator overloads
On peut faire des tas de choses rigolotes qui simplifient l’écriture et permettent de faire des choses qui augmentent l’expressivité des tests en surchargeant les opérateurs. On peut a peu près tout faire et chose intéressante True et False sont aussi des opérateurs que l’on peu surcharger. Sachant qu’ils sont à la base des expressions binaires qu’on essaie de manipuler, en partant de ce principe on peut contourner un certain nombre de choses qu’il ne serait pas possible d’exprimer autrement.

Note: session très instructive, Mark étant un contributeur important du monde open source .Net, ses retours et expériences sont toujours très intéressants!

Je reviendrais plus tard dans un post dédié sur cette utilisation des dynamiques dans les tests et ce que cela peut apporter.

Bonne journée de conférence, hate de voir le reste!

 

Tagged with: , , , , ,
Posted in Event

NDC london 2013 – Keynote Dan North

Comme vous avez pu le constater, je suis un grand fan de la NDC depuis des années car c’est une conférence qui a su allier l’excellence des présentations techniques et les talks d’artisans expérimentés qui viennent partager leur longues expériences, le tout dans un contexte très technos Microsoft pour ne rien gâcher. Cette année j’ai loupé Oslo parce que j’ai préféré au DDD exchange qui avait lieu au même moment et parce qu’il y avait pour la première fois une version Londonienne.

Donc pour ceux que cela intéresse, c’est tout aussi bien en termes de contenu et d’organisation que la version Norvégienne, c’est un peu plus près et peu être aussi dans un contexte Londonien un peu mieux connu (encore qu’à Oslo tout le monde parle anglais et on est jamais vraiment perdus ;-).

London Excel building

London Excel building

La conférence se passe à l’Excel qui est un nouveau -énorme- centre de conférences et d’évènements à Londres.

Note pour plus tard, le bâtiment est tellement énorme, qu’il peut être intéressant de se renseigner avant sur la location précise à l’intérieur ou se passe l’évènement ;-) J’étais tout content avec mon hotel à 100m de l’entrée du centre de conférences mais c’était sans compter que la NDC se passe à l’autre bout du bâtiment, 1 km plus loin…

Cette année, je ne ferais pas de posts live de chaque session car cela n’a qu’un intérêt limité et que c’est une tache plus ou moins difficile suivant les sessions. J’essayerai donc de faire du live tweet (sur @rhwy, au cas où hein…) et posterai un petit récapitulatif de la journée dans la mesure du possible.

here we go

Note: les petites notes qui apparaissent sous cette forme en italique, sont des commentaires perso.

Dan North Keynote – Jackstones : the journey to mastery

Dan est quelqu’un de formidable à écouter car inspire beaucoup de sympathie et est très enthousiaste et quoi qu’on puisse en penser, c’est important et cela se ressent quand vous écoutez quelqu’un.

Dan nous parle de software craftmanship mais à sa manière…Cela part du principe qu’en discutant avec un certain nombre de personnes, la vision du craftman us, n’est pas forcément la même que cela de l’anglais, ni que celle de l’allemand. Du coup il faudrait peut être regarder un peu plus loin. C’est dans ce sens qu’il s’intéresse à cette quête de la maitrise.

Il nous donne différents exemples dans différents contextes et métiers de ce que représente cette maitrise. Il n’oublie pas de nous rappeler que les exemples, tout comme les modèles, sont des projections et mauvais par essence mais qu’il peuvent être utiles de manière restreinte pour une illustration (rappelez vous, tous les modèles sont mauvais, mais certains peuvent être utiles).

Par exemple pour un pianiste de concert:

The concert pianist

The concert pianist

Ces qualités sont d’ailleurs pour un compositeur, qui en plus d’avoir toutes les qualités de l’instrumentiste de concert doit savoir en plus les techniques de composition ainsi qu’une connaissance approfondie de l’histoire de la musique.

Notes: L’analogie est intéressante, mais surtout ce qu’il l’est encore plus à mon sens c’est cette distinction entre apprentissage d’un coté et pratiques d’un autre. Cette distinction est importante car l’un ne va pas sans l’autre mais on ne les distingue pas assez souvent. 

Dans nous rappelle qu’on parle souvent de pratique (practice, practice, practice!) et il en faut pour automatiser un certain nombre de gestes. C’est vrai dans tous les métiers, l’excellence ne s’obtient qu’à partir du moment où les gestes de base sont automatiques et où l’esprit est libre pour s’intéresser à des choses plus pointues ou créatives. Néanmoins, par rapport à notre métier, Dan nous interpelle pour savoir si on a déjà vraiment répété 2 fois le même code. Non bien sur. C’est pour ça que en plus de l’aspect manuel de la pratique, il y a l’aspect apprentissage. On ne répète jamais exactement 2 fois le meme code, par contre on apprend à chaque foi. Sans complètement automatiser notre geste, cette répétition, nous donne à chaque fois une meilleure compréhension du problème et des solutions.

Une série d’autres exemples s’en suit avec par exemple le joueur de Hockey sur glace. Cela parait idiot, mais avant de pouvoir devenir un bon joueur, ou joueur tout court, il faut déjà maitriser parfaitement le patin à glace.

Notes: j’aime beaucoup cette illustration car elle se rapproche bien de ce que l’on pourrait avoir dans notre métier. Avant de pouvoir devenir un professionnel du développement vous devez savoir programmer ainsi qu’un certain nombre de choses, et ça vous pouvez l’apprendre à l’école. Cela montre bien que ce que vous faites à l’école est juste l’ensemble des bases pour commencer dans le métier mais que quand vous sortez de l’école comme un débutant qui est prêt à apprendre le métier, pas un architecte-chef-de-projet-développeur-presque-senior-dans-2-ans…

Nous arrivons à la fin sur le sujet du talk, les jackstones et les origamis. Dan nous parle d’un origami -un modèle de pliage plus ou moins en forme d’étoile- qu’il essayait de faire étant petit sans y arriver. Beaucoup plus tard, en étant adulte, il est retombé dessus et alors qu’il pensait y arriver beaucoup plus facilement -puisque adulte- il s’est arrêté exactement au meme endroit. Ce qui était finalement normal, puisqu’il n’avait eu aucun apport supplémentaire de connaissances ou de pratiques sur le sujet entre temps!  Puis il est revenu dessus un peu plus tard en faisant et refaisant le modèle, jusqu’au moment où il a vu la lumière. A partir tout s’enchaine et il arrive au bout de la construction. Puis il en fait d’autres, et encore, et encore.

Dan North - happy with JackStones

Dan North – happy with JackStones ;-)

Notes: Cette illustration de “j’ai vu la lumière” est très intéressante car c’est un point essentiel dans l’apprentissage. Elle représente en fait le moment où l’on a acquis suffisamment de connaissances dans un sujet particulier pour être capable d’aller plus par soi même, de comprendre de manière autonome comment les éléments peuvent se combiner et en quelque part de pouvoir commencer à être créatif.

Dans une deuxième partie nous montre sa vision de l’approche de la maitrise. On reste quand même proche du software craftmanship, puisque l’on parle des roles de l’apprenti, du compagnon et du maitre.

As an apprentice

As an apprentice

Une note importante dans tout ce discours, est bien sur que tout cela est une réflexion sur les rôles de chacun mais qu’en aucun cela n’enlève l’obligation de connaitre ses bases (théories, languages, XP, TDD, SOLID, etc…) et qu’il s’agit bien des bases à connaitre en tant qu’apprenti pour pouvoir aller plus loin.

Une vision importante du compagnon à retenir, c’est qu’en tant que compagnon, vous êtes déja un modèle pour d’autres, et donc que c’est à chacun de définir la projection de soi même que l’on veut faire parvenir aux autres. Il ne faut pas se contenter de montrer son compte github pour montrer ce que l’on a fait/peut faire mais bien d’avoir son espace dans lequel tout est maitrisé et dans lequel on indique la direction de comment on voudrait que les autres nous voient, ce qui nous intéresse et ce que l’on veut mettre en avant, bref, ce pourquoi on voudrait être reconnu.

Bref, une keynote très sympa et enjouée, très instructive par rapport à l’échange d’idées et la confirmations de choses personnellement ressenties. Merci Dan!

Tagged with: , , ,
Posted in Event