Page 2 of 65

Humilité, empathie et égo

Fleid 2 commentaires

Plus le temps passe, et plus j’ai la conviction que la plupart de nos problèmes professionnels sont en réalité des effets de bord de nos problèmes personnels profonds.

Après tout, cela paraît logique : on l’avait vu dans Peopleware, nous sommes vraiment dans des métiers liés aux relations interpersonnelles, bien plus qu’à de l’expertise technologique. Confere votre dernier projet : le plus gros problème c’était plutôt la techno, ou plutôt le chef de projet / PO qui ne voulait pas comprendre que la techno ne pouvait pas faire ce qu’il voulait?

Screenshot du film Office Space, pour un effet comique

Par problèmes personnels j’entends les conséquences de la condition humaine, qu’elles soient innées ou acquises. À un niveau macro, cela se visualise à travers toutes les particularités de l’égo qui font de nous des animaux tant sociaux qu’asociaux. Pas de panique, je ne suis pas psy, ni philosophe, je ne creuserai donc pas plus dans cette direction 😉

Ce qui m’interpelle plutôt c’est l’égo, et comment la présence d’une personne à l’égo atrophié ou surdéveloppé peut nuire complétement à une dynamique de groupe. Cela peut se manifester par une déférence trop importante à la hiérarchie, à la limite de l’obédience, ou à l’inverse par une rébellion permanente, souvent générée par le sentiment d’être injustement spolié d’une chose ou d’une autre par le groupe. Le pire étant peut-être l’apathie détachée : « le monde brûle autour de moi mais vraiment, que font les autres pour corriger ça ? ». Il y’en a d’autres, des manifestations d’égos incontrôlés, vous en faites autant l’expérience que moi, et bien souvent elles se combinent et sont amplifiées par nos biais cognitifs naturels.

Screenshot de Shining, pour un autre effet comique

Lors d’un dysfonctionnement en milieu professionnel, il est d’ailleurs facile de blâmer une « mauvaise dynamique de groupe » et courant d’essayer d’y remédier via un changement des méthodes de travail en équipe (SCRUM, Lean…). Je crois sincèrement que cela ne peut pas marcher sans y associer un travail sur soi de chacun des membres de l’équipe, vers une prise de conscience des casseroles qu’on traîne et qu’on impose au groupe.

De mon côté, la seule recette que je vois pour adresser tout ça c’est juste d’être soi-même relativement carré dans ses baskets. Parce qu’au final, la seule personne sur laquelle on a prise, c’est soi-même. et je crois assez fort que si on arrive déjà à tenir son propre égo dans les clous, on rend un service énorme au monde. Imaginez si tout le monde faisait pareil ! 🙂

Pour travailler sur ce sujet, rien de révolutionnaire : cultiver son empathie (mais pas trop) et développer son humilité (lisez l’intro de l’article wikipedia, il est top), autrement dit régler ses problèmes ou du moins les prendre en mains…

Etre humble ce n’est pas être un bisounours. L’humilité n’empêche pas la fierté, ni de lutter face à un égo démesuré en face, bien au contraire. Pour moi l’humilité c’est se connaître, et s’accepter tel que l’on est, avec ses forces et surtout ses faiblesses. De cette maturité vient la sagesse de ne pas projeter sur les autres la douleur issue de ses propres failles, et de ne pas prendre pour soi la projection de la douleur des autres. En clair : arrêter de faire de tout une histoire d’égo.

Je ne sais pas vous mais pour moi c’est un travail quotidien, difficile, qui n’a pas de fin. Souvent j’échoue, mais ça ne m’empêche pas d’y croire et de persévérer 😉

Un dernier screenshot rigolo, cette fois de Orange is the new black

Revue : Big Data par Nathan Marz et James Warren

Fleid Laisser un commentaire

Je vais aller droit au but: vous savez comme je vois le DWH Toolkit de Kimball & Co comme LE bouquin de référence pour le décisionnel, et bien c’est très simple, voilà son équivalent côté Big Data. A mon sens c’est une lecture incontournable, d’autant plus si vous avez déjà écrit ou prononcé les mots « Lambda Architecture ».

Notez que je ne suis pas le seul à en dire du bien, c’est un ouvrage qui a été largement encensé depuis qu’il est sorti, et franchement il le mérite!

Nathan Marz (Twitter, Site) c’est un ancien de Twitter et l’un des créateurs d’Apache Storm, la techno de stream processing la plus utilisée dans la stack Hadoop. Il a fait ses preuves.

Couverture : Big Data chez Manning

Au delà du fond, vraiment passionnant, la forme est également au top. En effet on alterne des chapitres théoriques avec des exemples d’implémentation technique, sur des technologies variées, toujours dans le cadre de la mise en place d’un même système de web analytics. Ça donne un fil rouge au bouquin qui rend sa lecture vraiment digeste.

Morceaux choisis:

  • Les techniques fondamentales liées au Big Data: des systèmes (storage & compute) qui ont conscience de leur nature distribuée, des données immutables, le tout pour permettre le scaling horizontal (ajout de machines) le moins douloureux possible

  • Pour rendre un système de données résistants aux erreurs humaines : on conserve les données dans un format immutable (on ne peut qu’ajouter, ni supprimer ni mettre à jour) et des algorithmes en re-calcul complet (recomputation, à opposer aux chargements incrémentaux)

  • D’où l’architecture lambda : un master dataset immutable avec une ligne de chargement en re-calcul complet (batch + serving layers), mais ce sera lent, donc on y adjoint d’une ligne de chargement rapide (speed layer), à côté, qui gèrera les delta en attendant le prochain batch. Et pour l’utilisateur, une vision unifiée qui brasse des données issues du batch et du streaming.

Schéma de la Lambda Architecture

  • Côté Master Dataset, on utilise une techno robuste qui assure le caramel en batch write / batch read : du filesystem, en mode distribué avec HDFS. Là-dessus on emploie une modélisation particulière (fact-based model, une normalisation complète), si possible structurée via un framework de serialization genre Avro, ProtoBuf ou Thrift.

  • On prépare des batch views dans le Serving Layer, à coup de Map/Reduce en Java ou Python, à destination d’une base batch write / random read orientée requêtage ad-hoc. Ici on va indexer et dénormaliser, pour le confort des utilisateurs.

  • Sur le Speed Layer, le but va être de reproduire la même chaîne de traitement qu’en batch (un des inconvénients de la méthode), mais sur un volume bien moindre de donnée, pour s’approcher du temps réel. On parle Kafka pour gérer la queue multi-utilisateur, Storm pour le stream processing incrémental, et Cassandra pour gérer le random read / random write à exposer aux utilisateurs.

Si vous voulez avoir le pourquoi de tout ça, expliqué de façon propre et illustrée, direction le bouquin, il vaut le coup.

Je recommande plus que vivement 🙂

Revue : I <3 Logs (I Heart Logs) par Jay Kreps

Fleid Laisser un commentaire

Dans mon chemin d’apprentissage vers les nouvelles architectures de données, j’ai croisé ce petit bouquin rapide de Jay Kreps, et je ne peux que le recommander.

Jay Kreps c’est l’un des inventeurs d’Apache Kafka, quand il était encore chez Linkedin, et depuis c’est le co-fondateur de Confluent, la société commerciale qui édite la plateforme open source. Alors oui, fatalement, il a un petit biais en faveur des plateformes d’intégration basées sur les logs, mais il a surtout une grosse expérience sur le sujet à partager.

Couverture : I heart Log

Evacuons tout de suite le reproche principal qui est fait à ce bouquin: il est court, très court. Vu son prix, il est vrai que ça le rend vraiment cher à la page. Mais pour moi c’est le condensé parfait des idées sous-jacentes au grand retour à venir du temps réel dans l’intégration de données (confère). Donc je lui pardonne son prix (et j’aime signaler au marché qu’il va dans la bonne direction grace à mes achats). Pas de problème si vous surveillez votre budget, direction le blog de Confluent qui dans ses articles reprend beaucoup du contenu du livre. C’est moins bien organisé, mais avec un peu de patience on remet tout dans l’ordre. Dans le cas contraire, je vous encourage vivement de casser la tirelire 😉

Morceaux choisis:

  • La différence entre « Physical Logging » (on log le résultat de l’opération, ex: le contenu de la ligne) et « Logical Logging » (on log l’opération, ex : la requête SQL)
  • Différence qui découle dans 2 architectures de centralisation des logs: le « Primary Backup Model » pour le « Physical Logging » (on écrit sur un master, on forward le résultat de l’écriture aux systèmes esclaves), versus le « State Machine Model » pour le « Logical Logging » (on log la transaction en amont, elle est dupliquée pour traitements sur tous les systèmes en aval). Chacun avec ses avantages et inconvénients
  • Tout ça découle de l’idée de dualité de l’information: tables vs événements, une notion qu’on retrouve en BI, lorsqu’on modélise un processus métier et qu’on peut choisir entre conserver le stock vs les transactions d’un processus métier
  • Cette idée va être structurante dans la construction d’un système de log centralisé, à savoir comment connecter chaque type de système source. Les logs issus des applications auront tendance à être logiques, ceux connectés directement sur les bases plutôt physiques
  • L’objectif de mettre en place un système de log centralisé étant bien sûr d’isoler chaque consommateur de chaque source, pour que chacun puisse vivre sa vie en bonne intelligence
  • Le fait de mettre en place un système centralisé de log implique le passage au temps réel: l’unité de traitement n’étant plus le batch (à savoir une fenêtre temporelle: 1h, 1 jour, 1 semaine) mais bien le log, manifestation d’une opération unitaire du processus
  • A ce titre, on peut alors s’interroger sur la possibilité de mettre en place du « Stream Analytics » (merci Microsoft de nommer les produits de manière aussi explicite ;)), c’est à dire le traitement des informations en continu, plutôt que via un ETL, pour les contextes décisionnels. Il est à noter qu’il a été prouvé mathématiquement qu’il est possible d’implémenter toutes les opérations considérées comme bloquantes (distinct, max, top…) en streaming via le windowing et le caching

Je recommande vivement!

I heart Logs, Jay Kreps (Amazon.fr)

S’ouvrir l’esprit

Fleid 3 commentaires

C’est en lisant l’article tout récent de Troy Hunt que j’ai mis des mots sur une sensation ressentie dernièrement:

There’s this odd thing that tends to happen in many peoples’ careers and I suggest it’s particularly prevalent in technology: you get really, really good at something and then it hits you – you have to stop it. Well actually, you could continue doing it, but not if you want to “progress” against traditional measures such as seniority and income.

En français dans le texte:

Il y a cette chose étrange qui se produit dans la carrière de beaucoup, et qui je crois est prévalent dans la technologie: lorsqu’on devient vraiment, vraiment bon dans son domaine, l’évidence se fait: on doit arrêter. En fait rien n’empêche de continuer, mais cela va à l’encontre d’une progression sur des métriques comme la séniorité et le salaire.

C’est d’ailleurs une idée qui se marie très bien avec certaines théories dont on a déjà parlé ensemble, particulièrement le fait que les sur-performeurs ont tendance à rester coincés sur le poste qu’ils occupent (pourquoi les promouvoir, ils sont tellement bons là où ils sont!). Une autre problématique c’est que plus le gap est important entre son niveau d’expertise et repartir à 0 dans un nouveau domaine, plus le cerveau fuit la possibilité: ça fait trop mal à l’égo. Et tout un tas d’autres raisons.

Bien évidemment, rien de dramatique de mon côté: j’aime la BI sur SQL Server et cela reste mon gagne pain principal. Cependant je prends conscience de certains faits: le sujet n’est plus qu’une part minime de ma veille technologique, et au final, les projets excitants qui se dessinent à l’horizon concernent des technologies différentes.

Quels sont justement les sujets sur lesquels je creuse en ce moment? J’en ai déjà parlé:

  • Le Machine Learning, via le parcours Data Science de l’Université John Hopkins sur Coursera.
  • R, le langage de manipulation de données, via le même parcours
  • Python, un langage objet avec une syntaxe simple, pour me remettre gentiment dans le bain du « vrai » développement. L’excellent tutorial pour Python c’est Learn Python the Hard Way
  • L’intégration de données moderne, via des lectures et vidéos dont je vous reparlerai plus tard, à transposer sur Azure avec entre autres Event Hub et Stream Analytics

Evidemment ça fait beaucoup de front, alors j’alterne sur des cycles de 2/3 mois: Coursera, Intégration, Python… Et tant qu’à causer logistique, je me suis équipé de Coach.me, qui permet de rester motiver dans la durée grâce au principe des chaînes/streaks. L’autre nouvelle habitude c’est de pousser mes développements perso sur Github, comme ça je m’améliore aussi sur la partie ALM. L’avantage d’avoir commencé par Coursera c’est qu’une partie des premiers cours était dédiée à Github et au Markdown.

Franchement je m’éclate. L’ensemble débloque des scénarios d’usage vraiment sexy, genre « Internet of Things » (marketing power!), avec par exemple: la mise en place d’un dashboard web qui affiche en temps réel la température de la pièce. Rigolo non?

Pour ça on mélange un tas de technos et c’est ça qui est top:

  • Une board Arduino Yun
    • Jouer avec les composants électroniques pour cabler le capteur
    • La logique embarquée (du pseudo C) pour relever la température chaque seconde
    • Le module wifi pour envoyer le relevé vers Azure, auquel en accède en Python en y intégrant le SDK Azure
  • Côté Azure
    • Paramétrer l’Event Hub en PowerShell
    • Implémenter la logique d’agrégation dans Stream Analytics via du pseudo SQL et une logique de streaming
    • Finalement écrire les résultats dans Power BI avec l’API Rest

Et je vous avoue que voir la courbe de température évoluer en temps réel quand on réchauffe le capteur en le touchant, c’est bête mais ça provoque de la vraie joie!

Tout ça pour dire que je vous dois une série d’articles sur tout ça, et que je m’y mets de ce pas! En attendant, n’hésitez pas à vous y mettre de votre côté. Oui ça peut faire peur toutes ces technos étranges, mais en persévérant ça finit par rentrer 😉

Un sauteur de haie qui oublie de sauter, mais qui finit quand même la course!

SQLRally Nordic : Construire une plateforme BI moderne en PaaS avec Azure

Fleid 6 commentaires

Si vous vous demandiez ce qui a expliqué ce long silence hivernal, voici l’une des principales raisons!

En effet j’ai été invité début mars à présenter une session au SQLRally Nordic 2015 à Copenhague. Pour ceux qui ne la connaissent pas, c’est une belle petite conférence sur 2 jours (4 tracks), payante, et si vous allez voir la liste des speakers vous verrez que le niveau est assez sympathique.

Tant qu’à me mettre en risque j’ai joué le tout pour le tout, en choisissant un sujet novateur et un peu provocateur. Parce que oui, faire de la BI en PaaS dans le Cloud, c’est provocateur!

Gif animé de Loki, personnage Marvel

Faîtes moi confiance, ça passe dans le Cloud, sans aucun problème!

Bon je ne m’attendais pas non plus à déclencher une bagarre générale dans la salle, mais j’ai quand même eu un peu d’appréhension que cela dégénère en un débat sur la théorie fondamentale du datawarehousing, dans la langue de Shakespeare. Rien de tout ça, la session s’est bien déroulée, la preuve en vidéo (oui je dois travailler sur mon accent… et ma démo!) :

Les idées que j’expose dans ce talk me parlent beaucoup en ce moment (architectures lamba/kappa, software containers, micro-services), si vous avez un peu de temps je pense que ça vaut le coup d’oeil. Par ailleurs j’ai proposé cette même session au PASS Summit 2015 (oui je suis un malade, mais ça n’est pas non plus un grand risque vu le peu de chance d’être sélectionné), et je vais globalement travailler dessus pour l’améliorer et pourquoi pas la présenter en France avant la fin de l’année.

Dans l’attente, les slides et les références que je conseille très vivement, avec une mention spéciale à Martin Kleppmann et son talk « Turning the database inside out« , juste exceptionnel:

Le printemps arrive, c’est le bon moment d’apprendre!

Fleid Laisser un commentaire

Des tas de d’événements à l’horizon, le beau temps revient, c’est le moment de sortir et déclencher les opportunités 🙂

C'est en forgeant qu'on prend des poissons dans les dents

De mon côté j’en fais moins sur le blog, mais je présente beaucoup plus:

  • Cette semaine : le SQLRally Nordic. Alors ok, c’est demain et après-demain, sur Copenhague, donc c’est vraiment ce qu’on appelle vous prévenir à la dernière minute… Mais s’il y a des aventuriers, vous êtes les bienvenus à la session que je présente : « Modern BI Platforms using Azure in PaaS ». Entre nous, j’ai un peu d’appréhension sur ce sujet. C’est la première fois que je présente dessus, c’est des technos nouvelles, des idées nouvelles (Lambda/Kappa architectures), qui remettent vraiment en cause le statu quo. En plus c’est en anglais, durant l’une des meilleures conférences payantes SQL Server en Europe: c’est un vrai challenge. Je vous en dirai plus à mon retour!
  • La semaine prochaine, le BizTalk Summit France à Paris chez MS. Au départ c’était pour rendre un coup de main à mon camarade Michel Hubert (Monsieur le Regional Director!), au final je me suis bien marré à préparer cette session sur l’Internet of Things (IoT) avec Azure. J’ai monté une chouette petite maquette avec un Arduino Yun, Azure Event Hub + Stream Analytics et Power BI. Alors n’ayez pas peur du nom de la conférence (oui BizTalk ça peut faire peur ;)), c’est une journée de sessions gratuites avec des sujets vraiment intéressants : DevOps, SaaS, Mobilité… Venez vous ouvrir l’esprit 😉
  • En mai, le SQLSaturday Lisbon 2015, évidemment au Portugal! Un retour sur la session que j’avais présentée aux JSS2014 (premiers pas sur Azure Machine Learning), mise à jour et en anglais. Il faut savoir que Lisbon c’est un gros SQLSat – il n’y a qu’à voir le line-up – et c’est pour moi une vraie fierté d’y avoir été invité.

J’ai aussi postulé aux SQLSaturdays Torino, Edinburgh et Paris, on verra si ça passe 😉

Et derrière moi :

  • Les Techdays 2015 : à mon sens une belle session avec David Joubert sur l’utilisation d’Azure Machine Learning pour la détection du SPAM. A noter notre approche que je trouve originale: on se met à la place de celui qui doit écrire un mail, et qui a peur de ne pas passer les anti-spam côté réception. Le système mis en place lui permet de directement tester ses textes dans Excel, avec un scoring en un clic effectué via Power Query et les API Azure Machine Learning. Les détails chez David!

Ça bouge beaucoup en ce moment, ne restez pas sur la touche 😉