DEV Community: Aleix Morgadas

React @loadable/component with Continuous Deployment

Aleix Morgadas — Sun, 31 Jan 2021 21:27:16 +0000

When you combine @loadable/component React Library with a Continuous Delivery/Deployment pipeline, you end up with a broken website when a user is navigating meanwhile a deployment is ongoing. And that's not good.

Here an example ⤵

You see that, meanwhile navigating, the browser aims to fetch a static file that is no longer available since it has been replaced with the new version.

It causes user frustration since the website no longer works plus it doesn't tell you what to do.

LinkedIn's Solution

I'm sure that if you used LinkedIn lately, you have seen the next screen.

And that's the solution I applied for the same problem.

Applying the Solution

Just create a ErrorBoundary Component that handles the inner component errors and ask the user for a Refresh.

import React from 'react';

class ErrorBoundary extends React.Component {
    constructor(props) {
      super(props);
      this.state = {
        error: null,
        errorInfo: null,
      };
    }

    componentDidCatch(error, errorInfo) {
      this.setState({
        error,
        errorInfo,
      })
      // You can also log error messages to an error reporting service here
    }

    render() {
      if (this.state.errorInfo) {
        // Error path
        return (
          <div className="error-boundary">
            <h2>Something went wrong 😖</h2>
            <button onClick={() => window.location.reload()}>Reload Application</button>
          </div>
        );
      }
      // Normally, just render children
      return this.props.children;
    }
  }

  export default ErrorBoundary;

And then wrap the <Router>...</Router> with the ErrorBoundary Component like:

function App() {
  return (
    <ErrorBoundary>
      <Router>
        ...
      </Router>
    </ErrorBoundary>
   );
}

Then the example solution looks like:

Source Code

Source Code at https://github.com/aleixmorgadas/react-loadable-component-with-continuous-deployment

⚡️ Feedback welcomed !(•̀ᴗ•́)و ̑̑ ⚡️

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

Single-responsibility principle applied to an Organization

Aleix Morgadas — Sun, 03 Jan 2021 00:00:10 +0000

Single-responsibility principle says:

Every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility.

Therefore,
"A class should have only one reason to change".

I have seen this principle being applied to multiple concepts like modules, APIs, Systems, etc. But I haven't seen it applied to an Organization yet. Maybe because it doesn't make any sense at all, but I will try to resonate about it.

Bear with me, we might not get into any point but worth to try it out 😁

Let's start replacing computer concepts by organization concepts

Every ~~class~~ organization in a ~~computer program~~ society should have responsibility over a single part of that ~~program;s functionality~~ society's needs, which it should encapsulate. All of that ~~module, class or function's services~~ organization, product or entity should be narrowly aligned with that responsibility.

Therefore,
"An organization should have only one reason to change".

Does it have any sense at all? It depends.

Single-responsibility seems to only make sense at Why level (company's purpose), not at What level (what the company offers, like products and services).

When I say why level and what level, I'm referring to the Golden Circle by Simon Sinek in his book, Start with Why.

Image's source.

So, in order to be a SOLID Organization, you need...

to have a single and well defined organization's purpose, which it should drive why the organization exists in the first place.

The only reason to an organization to change is that the purpose isn't useful anymore.

It might be that:

The purpose is already accomplished
There is no need to exist because there is not a demand
People don't believe in the purpose anymore

Discussion and feedback welcomed 😁

What do you think? Are you in a SOLID Organization? Does this make any sense? 🤣

Applying SOLID to an organization

Aleix Morgadas — Fri, 25 Dec 2020 12:24:25 +0000

SOLID Principles can be applied to many things. Classes, modules, systems... why not apply them to an organization as a whole? 🤔

I intend to write an article's series to see how each letter of SOLID applies to an organization and answer:

How this Principle applies to an Organization?
Are there any other Principles that aim to focus on the same already known by the Industry?
Is it useful to apply this Principle to an Organization at all?
Implications of applying and not applying the Principle.

Before I even start writing the first article about Single-responsibility principle applied to an Organization, what do you think? Is it applicable SOLID to an organization at all?

In a Lean context, create a system that can evolve over time is a waste or worth in an early stage?

Aleix Morgadas — Sat, 17 Oct 2020 19:45:32 +0000

Imagine that you have already validated a possible need for a product and you start to create the first Minimum Viable Product, that's not a Prototype.

Even though you have less risk, you still need to try a lot of stuff. The system will be changing fast and often, and sometimes you need to replace the whole system.

In this context, do you think that investing in the next points is a waste or actually worth to do:

Continuous Delivery System
Good practices
Automated testing
Monitoring
Analytics

If you think it's not worth at an early stage, then when you think it's worth?

Lean Explained "Mathematically"

Aleix Morgadas — Fri, 09 Oct 2020 14:35:04 +0000

Lean is all about reducing waste iteratively

From this idea, I will put some "math" in order to visualize when we are being lean and when we aren't.

The simplest graphic

Let's start with a simple graphic that might represent Lean.

It looks like an Horizontal Asymptote

where the goal is 0 waste.

So, we think about lean as an horizontal asymptote, we can admit that we will never achieve 0 waste. It helps us to be more humble about our own expectations, since there's no end in lean, only improvement over time.

Expanding the graph

When we are reducing waste, we know that there's a bottom line that's the real cost.

Even though we can sense where it might be, we cannot know where is it in real precision.

We might have the next situation, where we aim to reduce too much that we start under delivering based on our own standards.

We know that Lean is about reducing waste, but we don't know for sure what's real waste and what isn't. So, sometimes, we try to reduce waste where it was real cost. Causing the next situation:

In this situation, we have to be aware that it might happen and measure the delivery quality to know that we aren't delivery below our own standards.

It's OK that it happens, and it will happen to you. This process will let into new leanings.

Now, we are aware of how the graphic should look like, and that we might reduce the cost and not the waste because we cannot determine precisely the real cost of delivering, the question is:

How do we improve over time? Via Iterations

Simplest graphic + Iterations

Iteration helps us to measure improvement. It helps us to know where we were, where we are, but not where we will be.

What's an Iteration?

Based on dictionary.com:

a different form or version of something: They designed the previous iteration of our logo.

a development strategy that involves a cyclical process of refining or tweaking the latest version of a product, process, or idea to make a subsequent version: Our startup is relying on rapid iteration in the next software development cycle.

IMHO, Lean is more than 1st definition than the 2nd, and I will explain myself why.

Lean is a methodology, an approach and a mindset in how we approach stuff. It might be deliver an MVP, verify a business hypothesis, build a car or put a rocket in orbit.

With a Lean approach, we embrace the change for the sake of improvement of how we do stuff, not in what we build.

Let' imagine an unrealistic situation where we have a perfect product, that it doesn't need any more improvement. Meanwhile we don't need to iterate it anymore (2nd definition of iteration), we can still reduce waste in how we do the stuff in some way or another.

But, in the real world, we have to iterate the product, the what, and how we deliver it, the how. That's why Lean is often combined with other practices and methodologies like Agile, but they focus on different areas.

What's an iteration in Lean specifically?

An iteration is context dependent and fluid.

Let's break the idea that it's every two weeks or once a month.

I consider that an iteration starts when someone, regardless of the title and responsibilities, detects a waste and ends when have been passed enough time to determine that the waste has been, or should have been, reduced. Then, you see if you need to continue reducing the waste, or if you could dedicate the effort somewhere else.

Therefore, there are multiple iterations happen simultaneously.

You might have an iteration of 2 days of X topic, and iteration of 1 month for Y topic.

I wouldn't say that an iteration in Lean requires to deliver something to the costumer in any form per se, but it should let into waste reduction to achieve it.

Number of iterations ?

I would say, as much as you can, but let's be rational.

There's tension between delivery something to the customer and delivery something with 0 waste.

The more iterations you have, the more you can measure and more you can apply stuff to reduce the waste.

Lean without a goal, it's 100% waste

If you dedicate all your energy to detect and reduce waste, Lean itself becomes waste.

Have in mind that you want to achieve your goal, lean helps you to do it without wasting as much as resources as you would do it without it.

How do I would propose an improvement?

First, I take time to observe how we are performing and based on my intuition, I will start getting some data to verify as soon as possible if that's waste or not in a way that it doesn't interrupts my delivery work.

After that, I would use something like this canvas ⤵️

It helps me to:

Reduce down the waste scope as much as I can
The length of the iteration
What do I consider that there's waste backed up with data
Different solutions to reduce that waste
Which is my expectation of the ideal situation and which metrics I would measure to know if the iteration has been a success or not, and if we need further improvement or it's OK as it is.

Who is involved in doing this exercise to propose an improvement?

I will heavy recommend you that you don't do this canvas alone. If you can perform this scenarios with the team the better. Collaboration over individualism as much as you can here.

Do this exercise with your teammates really helps you to scope down the problem space and be very specific about what do you and other expect about the iteration.

How a more realistic Lean graphic looks like?

At beginning, reducing waste won't be possible. You don't even know how the processes are, the team dynamics, etc.

First, you take time to observe and then you propose a solution to minimize the waste you detected.

Also, assume that the cost fluctuates overtime as you know more about what you want to accomplish/which is your goal, and the learnings you have along the process.

Feedback

I would really appreciate any feedback you have about the article. Any points that are not clear enough, or that I might be mistaken :-)

We all should product design, is the new we all should sell

Aleix Morgadas — Sun, 06 Sep 2020 11:58:39 +0000

✋ Disclaimer: I'm learning about product design and I aim to share my learnings so far. Take this into account meanwhile reading this article, and share your thoughts and feedback if you think there is something that can be improved please! 😊

Six years ago, I was working in a small consultancy firm based in Barcelona. Because of the limited resources, the phase we all should sell became a mantra.

Since then, I have never stopped hearing it. If you are near to any startup or entrepreneur, you will eventually hear it 👂.

There is a reason why you would say this, the resources are limited, and hiring one person to be the only responsible for selling might not be possible 😖.

Instead, you aim to everyone in the company tries to sell the product in some way or another. This might sound good, but some inconveniences are out of scope for this post.

But, what do we understand by product design?

Product Design is a process that goes from analysis of user-needs to a problem-solving approach to improve the quality of life of the end-users and their interaction with the environment.

It is about problem-solving, about visualizing the needs of the end-users and bringing a solution.

It's a quite broad description since it varies a lot from company to company, and it might involve different "roles" that collaborate on the product design like:

UX Designer
Data Analyst
Prototyper
...

And it usually involves the next phases:

Then,

Why we all should product design is the new we all should sell?

How we are designing products is changing in our industry. Roles as UX Designer, Product Designer, User Researcher are becoming more and more important in how we build and ship products, and the impact on the users cannot be overlooked.

Still, having a team with dedicated people for each role and responsibility is a rare situation in a startup, similar to the sales department 😜.

Instead, as a team, you aim to cover the important aspects of Product Design in a loop-based way.

The important point here is to perform the different phases in a meaningful way. I do think in most startups that phases happen in some way or another, but giving the proper structure will help identify you, as a team, at which point you are at and what you should expect of your work, analyze the outcomes and improve based on data.

Involving the right people in each phase

Phase	Who (Does or performs some tasks as)	What	How
1. Empathize	People that work with data, analytics and has a more product owner role, marketing people	Research about the people you are creating the product for	User Testing, User Interview, Email Surveys, ...
2. Define	People that works with data, analytics and has a more product owner role	Create a starting point from the user insights	OKR workshop, Define the hypotheses, Align about the MVP (Lean Inception)
3. Ideate	Everyone	Bring the facts and assumptions into the table and start a Brainstorming session to know the next learning you want to achieve with the given data	2 - 3 days workshop focused on Brainstorming and conceptualization
4. Prototype	Product Owner, UX Designer, Engineers, Data Analysts	Design and iterate a prototype that help you answer your hypothesis	See different prototyping tools
5. Test	Product Owner mainly	Put in place the prototype to grater further information	Via User Interviews or Analytics Tools

Some resources that will help you start with Product Design

DynamoDB as EventStore

Aleix Morgadas — Sat, 22 Aug 2020 16:45:03 +0000

I would like to share with you how we managed to deploy a solution to store Domain Events in DynamoDB in 2 days (and mostly because of AWS permission issues...😅).

We needed to store how the user interacted with different Domain Models and decouple that storage from the monolithic so they can grow independently. We aimed to create something super simple, or at least not that complex, in 2 to 3 days.

We decided to give a try to process events as:

Monolith sends message to ➡️ SQS ➡️ Triggers Lambda to store it into ➡️ DynamoDB Table

Even though DynamoDB might not be an optimal solution to be used as Event Store, we have given it a try for the next reasons:

It is fully managed by AWS
It is cheap enough
We don't require high write throughput nor read for the moment.
Able to encrypt the content

Implementation

We decided to go with:

Terraform as Infrastructure as Code
Python for AWS Lambda

Source Code

Feedback

What would you do differently? Did I miss something? Did you have a similar solution for a similar problem?

Which best practices can you afford in a Startup and which you cannot?

Aleix Morgadas — Sat, 18 Jul 2020 10:24:06 +0000

Even though what we understand as Best Practices might vary person to person, team to team and company to company depending on their context, I will assume some of them during this post to create the debate 😊

Anyone working in a tech startup, without a huge budget at least, is familiar with some of the next situations:

"We need this as soon as possible"
"There's no time for testing, we need to work on this other thing"
"Why dedicate two weeks to improve X, if we might need to close in next month?"
etc.

It's true that those situations might be seen as tension between "product management" and "engineering", as an example, where someone wins and another loses.

I like to see them in another way, we are all collaborating to deliver a product to the customers, but we need to make tradeoffs in the different delivery areas. There's no I win you lose. We all win or we all lose.

A Delivery area is engineering, UX, Product Design, Marketing, ..., anything needed to deliver the product.

That being said, everyone, in their own area of expertise, has an opinion about what's the best and what's not acceptable.

Between that spectrum, there are some best practices that we might consider required and others optional. But which ones are required that really help in the product success and which didn't really help that much compared to others?

From the engineering point of view, I consider the next Best Practices as required:

Test-Driven Development:

IMHO, the most important practice by far.

Continuous Delivery: A simple Continuous Delivery pipeline really helps in
- Faster Feedback Loop, the tests break sooner
- No human factor to deploy the solution to production
- Team can see the results of their daily work in the development environment
- Be confident in releasing to production soon and often, being able to push fixes faster and without human factor most of times

It at least requires some sort of testing, without testing the feedback loop is longer than it should be.

Trunk Based Development

I consider that be working in one thing at a time, and always working in the trunk branch really helps in smaller iteration cycles.

Essential Monitoring

Have a way to see how your system is behaving in terms of how many 2XX, 4XX and 5XX responses codes there are per day/week helps you react faster in case you broke something, without needing to constantly check the application in case it broke something.

And you? Do you consider some other best practices to be more crucial? Which is your opinion about it?

I do agree that it does depend on each case, but I do think there are some that really are required 😁

Monitoring for Startups. Which affordable solutions are you all using?

Aleix Morgadas — Thu, 09 Jul 2020 22:01:55 +0000

Often, or at least to what I've been exposed to, the Startups have a reduced budget for infrastructure and they are in constant delivery pressure.

This two constant implies that you have some issues in production that you might no realise easily that they are happening.

I would say, that when the Startup is an early stage, the website traffic is still low. So we don't need a huge infrastructure support a lot of logs per minute.

That's when Affordable Monitoring comes into play. I would define Affortable Monitoring to a small budget solution is at least able to:

Centralized Logging with Search capabilities
- For Backend, Frontend and Mobile
- At least 7 days retention time
Alerts when the service is down or in degraded service state
Some metrics like:
- Request Per Second
- 2XX, 4XX, 5XX errors in a period of time
- Mean Response Time

We should also define what a small budget means. I would say 20-30EUR/month for all the services, not per host.

Here what we are using 😄 ↓

We have been using CloudWatch because we are using AWS as a Cloud Solution, and most of the requirements are in the free tier so it's a cheap solution for us.

It's true that it doesn't support, as far as I know, frontend logs. That's why we were considering Rollbar for the React WebApp.

And you? What do you propose as a good stack with those constraints? Would you adopt Grafana, Prometheus that early? What about ELK Stack? Is it worth compared with CloudWatch? Self-managed or third party hosted? Which metrics do you monitor?

Feature Toggle at Nginx Level

Aleix Morgadas — Fri, 03 Jul 2020 16:34:31 +0000

I would like to share with you how we manage to replace, using a cookie as a "Feature Toggle", the entire web application at run-time using Nginx.

Application Toggle might be a better name for this scenario tho 😂

The Need

The scenario is that we have two independent Web Applications, as example we used a React App and a Vue App. One is the legacy version that should be replaced with a new version that needs to be build from scratch.

There are different risks in replacing a fully functional application with a new one, and a lot of good reasons to not replace a working application by a new one but that's out of the scope of this article 😜.

Some risks are:

We miss some obvious features
Late feedback from the team-mates and the end user
Late integration in the release process

A possible solution

Include the new application under a Feature Toggle at Nginx Level so:

The application is included in the CI/CD pipeline and available in the different environments
Teammates can check how the application is growing in the development and production environment without disturbing the current application
Given the point where you can share the application with end users, you have it already available and tested by the team in the production environment.

The implementation

Using the map nginx module.

You can use a Cookie to map from which point you want to serve the Web Application from like:

    map $cookie_Toggle $app {
        default /workdir/react-app/;
        true /workdir/vue-app/;
    }

    server {
        listen       80 default_server;
        server_name  _;

        access_log   /var/log/nginx/local-wc.access.log;
        error_log    /var/log/nginx/local-wc.error.log;

        location / {
            root $app;
            try_files $uri $uri/ /index.html =404;
        }
    }

Quite simple and straightforward 😄!

Depending on the Toggle cookie, you can switch between Legacy Application and the new Application.

We a Browser Extension as Cookie Editor to switch the cookie value in a non-developer way.

Demo

Source Code

Demo + Source Code at https://github.com/aleixmorgadas/feature-toggle-at-nginx-level/

Feedback

Looking forward to hear about different strategies you used in similar situations! 😋

I hope it helped you in some way :)

What to do when you join a product company. A guide with special focus on learning

Aleix Morgadas — Sat, 23 May 2020 15:31:50 +0000

I'm currently joining a small product company based in Barcelona. The company released the first MVP some months ago, therefore there's already a product and users in place. Plus I already knew them before joining, that's super! 🎉

Even though they have already an on-boarding phase, I try to follow the next phases to become as familiar and productive as soon as possible with the product and team dynamics. In summary, it's all about making learning phase as short and valuable as possible.

Before joining the company:

1. Become familiar with the product

I become a user right away. I use the product each day to be familiar with the experience, benefits and drawbacks of the product.

By doing that, I identify:

🚶 User Journeys/User Flows

Being familiar with the application and the information in each page helps me to create a mental map about the pages, the interactions and the data.

😄 Value Proposition

Which are the benefits for the users, why the users pay for that solution.

📊 Business Models

How the company win money, and where they might be investing resources to make the product better.

🔄 Possible feedback loops

I search for ways that the users can give feedback to the product team, and how they are doing to listen in order to improve the product. It can be in the product itself or in the social networks.

It helps me be aware how much they care about the users feedback and how they involve them in the product development cycle

2. Become familiar with the market

🔤 Be familiar with the market language/jargon

As developer, I want to use a language that it's as near to the product people as possible. Sharing the same understanding on wording is crucial!

🔎 Be familiar with the important actors of the market

Competitors, regulation, ... whatever that has an impact in the market and the company's product is valuable to be familiar with.

Either because some product features addresses some already visible problems or because some features/user flows are inspired on some of those products.

After joining the company:

3. Assert that what I learned in the steps 1 and 2

Having the first conversations with the team about what did you learn, and expanding the product knowledge with those conversations.

It's important to not limit those conversations with the development team, I strongly suggest to have that conversation with all team members, like marketing, product, finance, ...

It will help you to have a better picture about the product, but also it will help your teammates to know how the product is perceived from outside. Both parties learn from this exercise.

🔡 Give importance to the Glossary. On the second step, you became familiar with the business language. It's time to assert that learning by creating a Glossary.

In case you're not familiar with the "Glossary", it's a list of wording and meaning for each thing that your team-mates refer to.

When you start speaking with your team-mates, they start saying stuff like, just check the XYZ, and you are like... what does XYZ mean?. In this step, you are recording all those new concepts because you will use them in your day to day job.

The Glossary will help the next person that joins the company to not get lost in all this new jargon.

But also helps you to know if the product people speaks the same language as the developers do. And that's super important. If you start finding that the product people say XYZ and then developers say, oh, that means ABC in the code... you will hard a time translating between tech and business, and that's something you could start investing energy and time to correct overtime.

What you aim to do is to create a shared and ubiquitous language between business and developers. It's a common concept in Domain-Driven Design.

4. Become familiar with the systems in place

Once I understand the product, the users and the value proposition, I try to understand the different systems that the company manages. To do so, I do somehow the next questions:

How many independent systems do you manage?

Having a big picture of all the systems, and how they are connected between them helps me as a starting point to organize all the concepts in my head. I do need to know and understand where everything belongs and which is each system purpose.

Are those systems self-managed or a third party manages them?

Knowing which systems are self-managed gives me an overview of the approach of the company/teams to develop software. Like, if they prefer to setup a self-managed Redis cluster over using the Cloud provider solution. I also ask the reason of why something is self-managed when there are good third party managed solutions when I consider that some tool might not be a core-business system.

Which are the deployment steps for each self-managed systems?

An important thing to know is how those systems are deployed. Is it manual? Continuous Deployment? you need other systems to be deployed when you deploy X system?

Which teams are in charge of those systems?

After knowing the systems, I ask for which teams are in charge. Here I tend to identify how the teams are structured. By domain-bounderies or by layers (frontend, backend, ...).

Also, identify which dependency there are between teams. It's important to know if there are a lot of dependency between teams to release something or they are quite independent.

5. Which tools do they use in their day to day?

Any tool that are uses during the day to day to deliver work. Not only related to development, but anything around that.

[ ] Development tools? Ex: VSCode, IntelliJ, GitHub, AWS, ...
[ ] Monitoring tools? Ex: Kibana, Grafana, ...
[ ] Design tools? Ex: Figma, Sketch, Adobe Suit, ...
[ ] Analytics tools? Ex: Google Analytics, Matomo, ...
[ ] Management tools? Ex: Jira, Trello, ...
[ ] Communication tools? Ex: Meet, Slack, ...
[ ] Other tools? Ex: hotjar, Google Drive, ...

Knowing the tools in place, plus if they are being paid or the free version, gives you a vision about how those tools affect your way of working. Also, if there are paid tools, trying to propose an alternative might be harder to convince people about the benefits vs replace a free tool.

I try to understand what all roles uses like the designers and marketing team, so I can have a better understanding on their work and how much I need to understand their tools to have a good communication between us.

Disclaimer: I don't say that the tools are the only thing you need to understand to have a good communication. Indeed, I consider that you need to do an extra effort to understand all the disciplines and areas of the company. Don't think that this a low effort task. By far, communication is still, at least for me, the where most of my energy goes.

6. Team dynamics/methodologies

Common stuff here:

Are you using some Agile methodology? If so, which one and which and how?
How do you provide feedback? Do they have 1:1? Retrospectives?
How do you plan a backlog?
How is a week in this team?

Conclusions

Doing this steps you have the "base knowledge" about:

The product value proposition and jargon. Spending less time during Development time trying to understand what people means about XYZ.
Which systems do what, and which teams manages them.
Which tools you should use in your day to day basis, and also tools from your colleges that you need to collaborate with.

I think those steps happen naturally in any company, some in a structured way others in a unstructured. This guide is only a way to give a way to gather the knowledge faster.

Open for Feedback

This is a live article. I'm more than open to other experience from people in a similar situations and practices 😄

Attributions

Photo by Element5 Digital on Unsplash

What means "High Performing Team" to you?

Aleix Morgadas — Wed, 04 Mar 2020 18:26:04 +0000

I have been using to the term High ~~Performance~~ Performing Team when debating with team-mates and friends about performing, way of working, and so on.

After a while, we realized that we were meaning different things when we were thinking about a High Performing Team.

I would like to know what means High Performing Team to you, which are the characteristics and how do you identify them.

Thank you for sharing your thoughts and opinions! (/^▽^)/

Edit: Replaced ~~Performance~~ by Performing due to a misunderstanding 😓