Devops for Growth
82.4K views | +1 today
Follow
 
Scooped by Mickael Ruau
onto Devops for Growth
Scoop.it!

Understanding Degrees of Code Flexibility | DaedTech

So I’m going to define some concepts to flesh out an idea. This isn’t exactly a formalized theory or anything. It’s rather just a working lexicon of how I think about my application. This is a scale of system flexibility for a given future change. Or, put another way, here is a way of assessing how much effort on the part of the entire development/operations group doing X for the aforementioned user will be, from least to most significant.

Users can do it themselves.An IT-level change is required (e.g. changing a config file, swapping out images, etc.)An architect/dev change is required to configuration (e.g. XML for an IoC container)A non-compiled source code change is required (e.g. you update the markup for a site but not the underlying code)An Open/Closed Principle Compliant source code change is required (basically adding new code).A localized tweak to existing code is required.A substantial change to existing code is required spanning various modules.
Mickael Ruau's insight:

None of this is even remotely comprehensive, but my goal here is really just to encourage people to understand at design time the difficulty of changing something at production time. It seems quite often to be the case that people don’t really think about this, and simply because no one has ever pointed it out to them.


Your mileage may vary on the number of categories in the list and your preference for certain options, but at the core of this is a basic and incredibly important idea: you should always play “what if” when it comes to changes that users might request and understand how much of a headache it will be for you if the “what if” comes true.


Oh, and also try to minimize the number of headaches. But hopefully that goes without saying.

No comment yet.
Devops for Growth
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...
Scooped by Mickael Ruau
Scoop.it!

Incident Review: Google Cloud Outage - DZone Performance

Incident Review: Google Cloud Outage - DZone Performance | Devops for Growth | Scoop.it


Google Cloud apologized for the service outage and any inconvenience caused its downstream customers. The organization specified the root cause as “a latent bug in a network configuration service which was triggered during a leader election charge.” The cloud giant has assured customers there are now “two forms of safeguards protecting against the issue happening in the future.”

With the massive adoption of public cloud, this latest incident (in a long year of outages) illustrates how significant the impact a public cloud vendor outage can be downstream. It also illustrates how vulnerable enterprises are to third-party vendor outages.

You can clearly see that many enterprises rely on public Internet, services, and infrastructure to conduct their business and deliver digital experiences to their clients. While there are many positives to this situation, the challenge is that those same businesses have little to no control over the underlying infrastructure on which their organizations run.
Three Key Lessons for Any Company

Below are three critical lessons that we took away from this outage, which you can apply to your own business:

While failure is bound to happen, don’t overlook the importance of communicating to the end user through a proper error page. Don’t assume your users will find your status page or go to Twitter to see your communications. They will have already moved on to your next competitor, and will eventually read about it in the news. If there was one thing that confused the end users in this instance, it was the Google error page that greeted people. Most people would have expected an error message from the company they were trying to reach, not the hosting company. It’s a little unclear if Google Cloud allows folks to modify this. Perhaps it’s not possible. However, any company should be ready for such failures, and implement a process where they are able to change the DNS or CDN configuration to point people to a proper error page with their own branding and messaging to apologize for the failure in their own words. And ideally, make it fun. Don’t be afraid to be human and relate to the end users. A proper error page is always better than confusing error pages (as in this instance), obscure errors (such as “the server failed to respond”), or worse, nothing at all and hanging on into infinity to connect to the server.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

De la résilience IT à la résilience business

De la résilience IT à la résilience business | Devops for Growth | Scoop.it
Il est aisé de constater à quel point la crise sanitaire a ébranlé les entreprises. Si le business est indissoluble de l'IT depuis bien des années
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Questionnement sur NoSQL - NoSQL

Questionnement sur NoSQL - NoSQL | Devops for Growth | Scoop.it


Lorsque l'on aborde le monde du NoSQL, et aussi celui du Big Data, il faut justement mettre de côté, je dirais même oublier, tout ce que l'on connaît du monde du SGBDR, monde qui est familier à tant de personnes.



Les bases de données relationnelles existent depuis la fin des années 70, donc depuis plus de 40 ans. Elles ont amené avec elles :
- une modélisation (entre autre Merise avec un MCD et un MPD)
- un typage fort des données
- une gestion de données structurées, en lignes et en colonnes (on appelle cela aussi des données tabulaires)
- un stockage des données en ligne dans les fichiers de la base de données
- une normalisation forte
- des contraintes d'unicité et d'intégrité référentielle
- un moteur transactionnel
- des propriété ACID

Elles sont utilisées dans le monde de l'OLTP, du Datawarehouse et du Datamart.



Les SGBDR sont des logiciels qui s'exécutent sur une seule machine où la scalabilité verticale a toujours été de mise dès qu'il fallait ajouter de la ressource matérielle (mémoire ou CPU).

Certes, il y a bien quelques exceptions comme le cluster Oracle RAC qui fonctionne sur un ensemble de machines, mais les ressources (mémoire et disque) sont partagées, ce qui ne sera pas le cas des clusters en NoSQL et Big Data où les noeuds du cluster ne partagent rien (architecture Shared-Nothing).

Ce sont toutes ces caractéristiques qui ont donné leurs forces aux SGBDR, mais aussi leurs faiblesses (je devrais plutôt dire leurs limites).



L'avènement du Web au début des années 2000, les réseaux sociaux, les smartphones, les emails, l'internet des objets (IoT)..., bref tous ces canaux de diffusion d'informations diverses sont à l'origine de ce que l'on a appelé un déluge de données.

Et ce volume vertigineux de données n'a pu être collecté, stocké, géré, analysé et exploité par les solutions informatiques de l'époque, les SGBDR étant même incapables de répondre à cette fameuse problématique des 3V (Volume, Vélocité et Variété) issue du monde du Big Data.
Mickael Ruau's insight:

Pour répondre à cette problématique des 3V, on a du tout réinventer.

En particulier, voici ce qui a été mis en place (attention, il s'agit de grandes généralités sur le NoSQL et le Big Data, et il existe bien entendu des exceptions) :

- on ne travaille plus sur une seule machine, mais sur un ensemble de machines (nœuds) qui travaillent de concert et qui forment un cluster

- les données, provenant de l'extérieur et qui sont ingérées par des solutions de type NoSQL et Big Data, sont distribuées sur les différents nœuds du cluster. On va ainsi pouvoir paralléliser les traitements, et comme les nœuds ne partagent rien (ni CPU, ni RAM à cause de l'architecture Shared-Nothing), il est facile de rajouter des nœuds pour avoir plus de puissance (scalabilité horizontale)

- on traite de la donnée en masse, et l'on se moque donc des problématiques de cohérence, d'intégrité et de qualité des données. Tout cela doit être vu (si nécessaire) en amont, dans les systèmes qui sont à l'origine de l'information

- le fait de traiter de la données en masse implique aussi que l'on n'a pas besoin de moteur transactionnel, ni de schéma de données. Car le principe est plutôt de faire du WORM (Write Once / Read Many) : on écrit une fois l'information qui est immuable, et on l'exploite plusieurs fois. Comme il n'y a pas de schéma, l'insertion de données ne pose en général pas de problème. C'est à la lecture que les problèmes seront éventuellement rencontrés, lorsque l'on voudra lire par exemple une clé dans un document JSON, clé qui n'existe pas

- l'information étant plutôt immuable, on n'a pas de mise à jour. Si ce besoin persiste, on a plutôt tendance à ne pas faire une mise à jour, mais on insère la nouvelle donnée, et on historise (versionne) l'ancienne donnée

- on exécute des requêtes et des calculs de type analytiques, qui portent non plus sur l'intégralité des données d'une ligne, mais sur quelques colonnes qui ont un sens métier, d'où le stockage de données en colonnes, et non plus en ligne

- les bases NoSQL ne sont pas faites pour faire des jointures. Au contraire, on dénormalise à fond, et on n'hésite pas à répéter l'information (tout le contraire des SGBDR donc)

 

Tout ceci ne constitue que des grandes généralités.

En ce qui concerne le NoSQL, pour répondre aux différents besoins (use cases), on a inventé 4 grands types de bases NoSQL :

- orientées clé / valeur, comme Redis. Souvent utilisées avec les sites web de e-commerce où la clé représente l'ID de session de l'internaute, et la valeur est un champ géré par l'application (pas par la base) et qui peut être la sérialisation des articles issus du panier de l'internaute

- orientées documents, comme CouchBase ou Mongo. Par document, on entend des données au format XML, mais surtout JSON car elles prennent moins de place

- orientées colonnes, comme Cassandra (ou HBase mais sur un cluster Hadoop), pour faire des requêtes analytiques

- orientées graphes, comme Neo4J. Ce type de bases gère un graphe qui est un ensemble de nœuds reliés par des relations qui ont une direction. Un exemple simple est de sniffer le réseau informatique, et d'importer le fichier de Log dans la base graphe. Un premier type de nœuds représentera les machines avec leurs IP, et un second type les ports utilisés.
On aura un premier type de relation entre les machines et leurs ports d'écoute, et un second type de relation d'un port d'une machine à un autre port pour symboliser les paquets réseau. Il est alors possible d'interroger la base pour obtenir par exemple le Top 10 des 10 machines qui supportent le plus de trafic.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

No Plan Survives First Contact With Customers – Business Plans versus Business Models

No Plan Survives First Contact With Customers – Business Plans versus Business Models | Devops for Growth | Scoop.it
No campaign plan survives first contact with the enemy Field Marshall Helmuth Graf von Moltke I was catching up with an ex-graduate student at Café Borrone, my favorite coffee place in Menlo Park. This was the second of three “office hours” I was holding that morning for ex students. He and his co-founder were both…
No comment yet.
Rescooped by Mickael Ruau from LEAP EntrepreneurshiԀPassion - lasting enterprise action practices
Scoop.it!

The Lean Startup Framework: Closing the Academic–Practitioner Divide - Dean A. Shepherd, Marc Gruber, 2021

The Lean Startup Framework: Closing the Academic–Practitioner Divide - Dean A. Shepherd, Marc Gruber, 2021 | Devops for Growth | Scoop.it
The lean startup framework is one of the most popular contributions in the practitioner-oriented entrepreneurship literature. This study seeks to generate new insights into how new ventures ar
Via Oliver Durrer swissleap.com
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Micro-SaaS Ebook: Retention & Support

Micro-SaaS Ebook: Retention & Support | Devops for Growth | Scoop.it


It can be challenging to balance providing great support to existing customers with further developing the product to attract new customers. If you did a minimum viable product (MVP) launch correctly, your product currently lacks a ton of features and has more than a few bugs. You will be getting a lot of bug reports and feature requests (and occaissional feature demands) from customers who are at times frustrated and confused. If you launched really well, the backlog will be much more than you can reasonably handle.

Navigating support as a solo founder can be a minefield and it’s important to have a strategy before frantically wading into the queue of emails and tickets.
The Guiding Principle: Every support ticket is an opportunity

But there’s hope. It’s too easy to view support tickets in a negative light. It’s a long task list that you need to check off before getting back to work on product. It’s a stream of grumpy users who can’t even read the dang instructions you so clearly wrote out inside the app.

But this is completely the wrong mentality because the reality is that every support ticket is a massive opportunity. Your worst customer is not the one sending you a support email every day for two weeks, your worst customer is the one who signs up for your app, then cancels without ever giving you a word of feedback. Customers who take the time and energy to write you a support email have now taken a vested interest in getting your app to work for them. It’s important to listen to them, ask follow-up questions and not just view the goal as getting the customer from A to B as quickly as possible.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Early Adopter Definition

Early Adopter Definition | Devops for Growth | Scoop.it

What Is the Early Adopter Tax?

The early adopter tax refers to the premium that early adopters pay for new technology as new tech always costs more upon release. In addition to the cost, the early adopter tax includes the bugs and defects in new technology that have not yet been ironed out, as well as missing out on the new features that are included in successive iterations.

 

How Do You Market to Early Adopters?

The best ways to market to early adopters include understanding what they need, meeting them in person, providing them with a product they can use right away, targeting specific individuals and companies, addressing an existing alternative, and telling a story.

 

What Percentage of People Are Early Adopters?

Approximately 13.5% of people are early adopters.2

 

Mickael Ruau's insight:
 

The term "early adopter" comes from a book by Everett M. Rogers, titled, Diffusion of Innovations (1962) in which he discusses five types of adopter stages for products. The five types are (1) innovator, (2) early adopter, (3) early majority, (4) late majority, and (5) laggard.1

 
 

Advantages and Disadvantages of Being an Early Adopter

Early adopters of hardware that is content-reliant may face a lack of ways they can use their equipment until producers catch up. For example, early adopters of recorded media players may have only had a shortlist of titles they could choose from when the hardware was first released from manufacturers. The expectation is that over time, more content would become available for the chosen media format, but there is no guarantee.

 

For instance, after the introduction of high-definition television, early adopters waited for television broadcasters to supply more and more of their shows in the new format that took advantage of the higher visual clarity. When it came to high-definition home video playback, a format war arose between manufacturers of Blu-ray and HD DVD players. Early adopters of either disc player were anticipating their format would eventually win out as the high-definition video disc of choice for the market.

 

In those early years, entertainment companies released movies and the video content might have been published on either one of the formats. This left early adopters with limited options on the content their disc players could access. Only rarely did content get published by entertainment companies for both standards. Eventually, the Blu-Ray platform became universally adopted for high definition video discs, leaving early adopters of HD DVD players with unsupported equipment that would have to be replaced.

 

Early adopters may enjoy a period of prestige by being the first to own a new form of technology, yet they also face the high probability that the equipment or service they are using will be made obsolete in future iterations of the product. In addition, the price they pay to be an early adopter is high as the technology is new. This also results in a loss of value as successive iterations will be more advanced. As a result, early adopters experience more defects in new technology that hasn't been fully tested.

 

As early adopters are the first to use a product they can provide feedback to the manufacturer about where the product can be improved, thereby having some influence on the technology. This unique position can also lead them to be a thought leader on the new tech as they are one of the few people who know how the technology works. If they position this right, it can lead to competitive advantages.

 
Pros
  • Prestige

  • Some influence on developing the technology

  • Gaining a competitive advantage

  • Becoming a thought leader on the tech

Cons
  • Limitations in applicability

  • Risk of utilizing soon to be obsolete product

  • High price for new technology

  • Loss of value

  • Higher risk of defects

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

The 5 Pillars of the AWS Well-Architected Framework | AWS Partner Network (APN) Blog

The 5 Pillars of the AWS Well-Architected Framework | AWS Partner Network (APN) Blog | Devops for Growth | Scoop.it


The AWS Well-Architected Framework helps cloud architects build the most secure, high-performing, resilient, and efficient infrastructure possible for their applications. The framework provides a consistent approach for customers and AWS Partner Network (APN) Partners to evaluate architectures, and provides guidance to implement designs that scale with your application needs over time.

In this post, we provide an overview of the Well-Architected Framework’s five pillars and explore design principles and best practices. You can find more details—including definitions, FAQs, and resources—in each pillar’s whitepaper we link to below.

Read the full Well-Architected whitepaper >>
1. Operational Excellence
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

How Adopting a Design-First Approach Helps Teams Treat APIs as Products

How Adopting a Design-First Approach Helps Teams Treat APIs as Products | Devops for Growth | Scoop.it
Treating APIs as products is a concept that is rapidly gaining adopting across the API space, and organizations are increasingly seeing the benefits of using product management principles when developing APIs. This approach involves applying the same level attention and planning to your API portfolio, as you would to any of the other software products your team is delivering.

This was also a popular concept at the recent Nordic API Austin API Summit. The conference featured a number of talks that touched on this topic, including: Why Productization Is the Key to Unlocking API Value from Pete Clare of Vanick Digital, and Embedding API-as-a-Product Culture from Rahul Dighe of Paypal.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Lire Etude CIO : Mettre les données au service de la stratégie d’entreprise

Lire Etude CIO : Mettre les données au service de la stratégie d’entreprise | Devops for Growth | Scoop.it
La donnée n’a de valeur que si elle est exploitée. Ce qui importe réellement aux organisations, c’est l’information qui peut en être tirée pour assurer le pilotage optimal de l’activité. Pour devenir une organisation pilotée par les données, être « data driven », il faut disposer d’indicateurs pertinents à tous les niveaux, depuis l’exécutif jusqu’aux opérationnels sur le terrain. Et donc aller chercher les données partout où elles se trouvent, y compris à partir de capteurs (IoT). Mais ce n’est là qu’une première étape. Les données doivent être fiables et arriver au bon moment, suffisamment complètes mais aussi rapidement disponibles. Au-delà du pilotage quotidien ou stratégique, l’information est aussi nécessaire pour piloter les risques susceptibles de frapper l’organisation. Il faut comprendre ce risque, le mesurer puis prendre les décisions pertinentes pour l’assumer ou le contrecarrer. La donnée elle-même peut d’ailleurs être un facteur de risque si son existence, sa conservation ou les risques pesant sur elle ne sont pas conformes aux réglementations en vigueur, notamment le RGPD.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Finding Early Adopters: The Mechanical Pencil Challenge

Entrepreneurship activities to find early adopters are central to any entrepreneurship curriculum. This exercise demonstrates where and how to find a business model’s Early Adopters
Mickael Ruau's insight:
Comments

Entrepreneurship students often struggle getting their first customers interviews because they lack a functional definition of Early Adopters.

This exercise uses mechanical pencils, and a 10-minute competition between students, to introduce Early Adopters in a way that not only contrasts them with Early Majority and Late Majority customers, but also demonstrates where and how to find a business model’s Early Adopters.

We are very proud that this exercise was a finalist in the prestigious USASBE 3E Competition, which recognizes the best experiential entrepreneurship exercises at the USASBE 2019 Conference!

The key questions this lesson plan answers are:

  1. Who is the target for our customer interviews?
  2. How and where do we find people for our customer interviews?
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Créer des plans de tests de charge réalistes-

Créer des plans de tests de charge réalistes- | Devops for Growth | Scoop.it
Faire des tests de charge réalistes n'est pas forcément évident pour de nombreuses raisons. Mais l'effort en vaut la peine, car cela peut fausser les résultats s'ils ne sont pas réalistes. Dans cet article, nous verrons comment réaliser des tests de charges et comment éviter certains pièges.
Mickael Ruau's insight:

Table des matières

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Joshua Bloch: Bumper-Sticker API Design

Joshua Bloch: Bumper-Sticker API Design | Devops for Growth | Scoop.it
My conference session How to Design a Good API and Why it Matters has always drawn large crowds; on InfoQ was the third most viewed content last year. When I presented this session as an invited talk at OOPSLA 2006, I was given the opportunity to write an abstract for the proceedings. In place of an ordinary abstract I decided to try something a bit unusual: I distilled the essence of the talk down to a modest collection of pithy maxims, in the spirit of Jon Bentley's classic Bumper-Sticker Computer Science, Item 6 in his excellent book, More Programming Pearls: Confessions of a Coder (Addison-Wesley, 1988).

It is my hope that these maxims provide a concise summary of the key points of API design, in easily digestible form
Mickael Ruau's insight:

 

Watch Presentation: How to Design a Good API & Why it Matters

Joshua Bloch is Chief Java Architect at Google, author of Effective Java, Second Edition (Addison-Wesley, 2008), and coauthor of Java Puzzlers: Traps, Pitfalls, and Corner Cases (Addison-Wesley, 2005) and Java Concurrency in Practice. He was a Distinguished Engineer at Sun Microsystems, where he led the design and implementation of numerous Java platform features including JDK 5.0 language enhancements and the Java Collections Framework. He holds a Ph.D. from Carnegie-Mellon and a B.S from Columbia.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Développer une application modulaire en Java-

Développer une application modulaire en Java- | Devops for Growth | Scoop.it
Cet article présente les bases du développement d'une application modulaire. Il présente également un exemple complet d'implémentation en Java.

Mickael Ruau's insight:

Table des matières

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Lire Etude CIO : Des infrastructures aux processus et applications, comment bâtir un SI flexible ?

Lire Etude CIO : Des infrastructures aux processus et applications, comment bâtir un SI flexible ? | Devops for Growth | Scoop.it
Pour répondre à des besoins qui changent constamment, les métiers attendent de l’IT une capacité à s’adapter en temps réel aux évolutions du business. Pour offrir cette agilité, toutes les couches du système d’information doivent pouvoir s’adapter facilement, de l’infrastructure physique aux applications, de façon à ne pas remettre en cause l’architecture tous les matins. Cette agilité de bout en bout suppose un certain nombre de prérequis. Au niveau applicatif, opter pour une approche plateforme facilite les évolutions. Il faut également une industrialisation des processus IT, du développement à la mise en production, afin d’accélérer les déploiements.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Malika Mir, DSI du groupe Bel : « 70% des projets actuels ont démarré avec le design thinking. »

Malika Mir, DSI du groupe Bel : « 70% des projets actuels ont démarré avec le design thinking. » | Devops for Growth | Scoop.it
Malika Mir, DSI du groupe agroalimentaire Bel, revient sur la transformation de la DSI grâce au design thinking, sur ses enjeux data et green tech.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Est-ce qu’on met un site en production aujourd’hui ?

Est-ce qu’on met un site en production aujourd’hui ? | Devops for Growth | Scoop.it
LE site qui vous indique si aujourd’hui est un bon jour pour la mise en production de votre site, certifiée par de nombreuses agences web.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Customer Discovery For (Lean) Startups | GoFounder Library

Customer Discovery For (Lean) Startups | GoFounder Library | Devops for Growth | Scoop.it
Finding out who your customers are and what they need is an important step for building a strong startup and launching a successful business.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

A curated list of customer development resources (40+) � [updated: Oct 2020] | by Bas Wenneker

A curated list of customer development resources (40+) � [updated: Oct 2020] | by Bas Wenneker | Devops for Growth | Scoop.it
Customer development. I love it. Finding out what works and what not is super important and often overlooked by entrepreneurs who what to ship asap. I too want to ship asap, but I also want to ship…
Mickael Ruau's insight:

Once, I was the guy who thought ‘if I build this, they will come’. And of course, they didn’t. Don’t make the same mistake, read this.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

How We Build Micro Frontends. Building micro-frontends to speed up… | by Jonathan Saring | Bits and Pieces

How We Build Micro Frontends. Building micro-frontends to speed up… | by Jonathan Saring | Bits and Pieces | Devops for Growth | Scoop.it
At Bit, we build tools for over 100,000 developers working with components. Our tools help developers build, reuse, and collaborate on independent components to speed up development and improve…
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

2021: Low code serverless functions with WebAssembly-powered DSLs

2021: Low code serverless functions with WebAssembly-powered DSLs | Devops for Growth | Scoop.it
Serverless functions are the "A" in JAMstack. However, traditional serverless functions from public clouds have poor performance, limited language and framework selections, and are generally not well suited for complex tasks such as AI inference. In this talk, we will present a new type of serverless functions, based on WebAssembly, that supports Domain Specific Languages (DSLs) specifically designed for application tasks. The WebAssembly functions are low code, very fast, and can be deployed on edge network nodes.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Dix raisons pour échouer ses tests unitaires

Dix raisons pour échouer ses tests unitaires | Devops for Growth | Scoop.it
Faire des tests unitaires dans ses développements fait aujourd'hui partie des pratiques courantes, en particulier depuis l'avènement d'eXtreme Programming et des développements agiles… Et pourtant, malgré la maturité de l'outillage dont on dispose aujourd'hui (Junit, TestNG, Mockito, JMockit…), qui ne s'est jamais retrouvé confronté en arrivant sur un projet legacy à la fameuse ritournelle : « Les TU ? On les a désactivés, on n'arrivait plus à les faire marcher ! » ? Alors, pas si faciles les tests unitaires ? Écrire des TU est une chose, les pérenniser en est une autre… Voici 10 anti_pratiques à ne pas suivre, tirées d'expériences réelles, qui pourraient précipiter vos tests unitaires dans les oubliettes…
Mickael Ruau's insight:

Table des matières

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Agile Coaches, Agile Guides and Other Family Members

Agile Coaches, Agile Guides and Other Family Members | Devops for Growth | Scoop.it


When one is journeying into the unknown, plans have limited value simply because one doesn't know. The bigger the plan, and the more superficially complete the plan, the greater the challenges when innovating.

But why spend time on planning when you could get yourself a guide? Someone who has been over the same, or similar, territory before and can help you navigate the obstacles?

In truth many teams do secure the services of a guide. These people go by the name Agile Coach. However, even as the Agile Coach has become an accepted role in development teams a number of problems have built up with the role.
Conflicts in coaching

Question: should an Agile Coach present solutions?

When in the role as an Agile Coach I have spent days agonising when the organization and team expect me, their Agile Coach, to fix things. But I know, as a coach, I should help them find their own solution. Is it right for me to hold back my knowledge? Am I best serving my client by not doing what they expect me to do?

Question: When a team are content with their way of working, should an Agile Coach initiate change?

The biggest conflict in agile coaching is between the way organisations often view the coach role and the way coaches themselves see their role. Companies frequently see the coach as a change bringer, but coaches usually see their role as an enabler. In coaching terms this the difference between directive and non-directive coaching.

Many agile coaches take their lead from the earlier field of business coaching. Authors like John Whitmore and Myles Downey have long advocated a non-directive style of coaching where the coach helps the individuals resolve their own problems. Whitmore writes:

"Coaching is a management behaviour that lies at the opposite end of the spectrum to command and control. ... A skillful coach rarely provides or prescribes solutions." Coaching for Performance, Whitmore, 1992

In their work coaches often utilize the Socratic method to help coachees unlock problems and decide actions. Unfortunately, asking lots of questions, and not providing solutions, is usually not what companies expect from their coaches.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Getting Real: The smarter, faster, easier way to build a successful web application | Basecamp

A must-read for anyone building web apps, packed with keep-it-simple insights, contrarian points of view, and unconventional approaches to software design.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Comprendre le patron de conception Circuit breaker

Comprendre le patron de conception Circuit breaker | Devops for Growth | Scoop.it
L'évolution des besoins (réductions des coûts et du time to market, concept d'ATAWAD (AnyTime, AnyWhere, AnyDevice)…) a mis en avant certaines architectures (architecture applicative cloud ready, architecture microservices, architecture distribuée…).

Cela a engendré de nouvelles problématiques, en particulier l'augmentation du nombre de dépendances et donc potentiellement soumises à la latence du réseau.

C'est à ce moment qu'apparaissent à nouveau les Illusions de l'informatique distribuée :

Le réseau est fiable.
Le temps de latence est nul.
La bande passante est infinie.
Le réseau est sûr.
La topologie du réseau ne change pas.
Il y a un et un seul administrateur réseau.
Le coût de transport est nul.
Le réseau est homogène.

Et ces illusions ne prennent pas en compte la partie dépendance et son lot de problèmes (crash, temps de réponse lent, réponse non conforme…).

Pour répondre à ces défis, la philosophie de design for failure (les traitements applicatifs doivent, dès leur conception, prévoir le cas où les composants qu'ils appellent pourraient tomber en erreur) a pris encore plus d'importance.

Et donc nous sommes passés de : « prévenir toutes les défaillances » à : « les défaillances font partie du jeu ».

Parmi toutes les solutions composant le design for failure, nous allons nous pencher sur le patron de conception (design pattern) « Circuit Breaker » popularisé par Michael Nygard dans le livre « Release It! ».

Mais avant cela, faisons un tour rapide sur d'autres solutions permettant de gérer des problèmes de dépendances.
Mickael Ruau's insight:

 

Table des matières

No comment yet.