DEV Community: evozon

State management with a little help from my friends

evozon — Fri, 01 Sep 2023 07:03:22 +0000

Starting from a well-known Beatles song title (I know… I am old school/deprecated), I will try to summarize my own experience around state management. I will share my way of “doing it” nowadays with a little help from a couple of very useful libraries. Also, I want to reveal in the following few chapters the experiences and ideas taken from daily work and my teammates over the years that brought me to this point.

There is a beginning for everything…

We can all agree that state management in general is one of the most discussed and applied ideas over the last 6-7 years. I am happy that it was part of my daily work during its evolution path. There are a lot of debates around the “perfect” library for state management, the “perfect” way of data modeling, and of course the strongest debate around the “perfect” paradigm where the battle between functional and object oriented will never end. For sure, these are all constructive and come with real options on the table for every taste. For me, personally, it is hard to say how thankful I am to all the people who worked to develop and promote this idea. I consider they offered more options for building our software design than most of us thought.

First of all, the state management idea completely replaced the MVVM imposed on the market by Angular 1 in a period when some of us did not even imagine an aspect like this. Don’t judge me. I still appreciate a lot what MVVM and Angular 1 made for web development. For sure it was a real rocket for those ages, but the evolution to what we have today, became necessary and somehow inevitable. It’s just that everything has its time… React simply introduced the unidirectional data flow, the idea of state, the reactivity, and the observer pattern in components. So, the rules of the game got changed very fast. Also, the controllers, views, and models started to be a little bit deprecated words in the JS ecosystem. I will try in the next few lines to show how full of intensity was my first interaction with the state management concept.

The pain of the first attempt

After years of jQuery and the magic of Angular 1, I started more than 6 years ago with React+Redux. That was one of the most painful moments in my career. It was hard in the first weeks to adapt my mindset and to accept the functional ideas and the new way of thinking, modeling, handling, and mapping the data.

The first round ended up with a KO victory for React+Redux. This was the starting point for one of the most successful projects and moments in my whole career. I think I was lucky that I started with a library that offers a lot of control over the flow for both actions and data. It enforces immutability in such a way that even a fool can see the benefits after a while, and the tooling for it cannot be ignored. Although I now have various preferences and generally make other choices, my admiration for it is still at the same level.

Another awesome part was that I was simply forced by the project and of course by the respect for clean code, to use it at its maximum level and to have after the whole period, some quite clear pros and cons regarding how a state management should “look like”. The bad part is that even though I implemented/applied most of the things that nowadays are on the market as Redux toolkit, I still had to write a huge amount of code to achieve the usual things.

The design became very composable, making it easy to combine various bits and pieces to achieve the desired state or result. However, for every feature, there were too many subcomponents to be combined and too many files to be added. So, the whole ceremony became rather a treat for a generator and most of the time a real pain for every smart developer.

After this period, every great thing should come to an end. So, a new project came into my professional life with new decisions regarding the tech stack I should use.

A little more wisdom

I felt that going on with the same Redux approach, without getting out of my big comfortable zone, should be a mistake and I should not make the mistake of not being open enough to new things as I was when I picked Redux. The next try was around Mobx, another great popular idea in the last few years. I tried both the Mobx-State-Tree with its functional trends and of course, the well-known “vanilla” Mobx which better satisfies the eyes of OOP fans. Even more, I wrote with typescript decorators a wrapper for Redux that is close in terms of sugar syntax to Mobx API. I think after these two experiences (even if Redux offered me the satisfaction of a great project and I felt I was able to handle everything) that Mobx is a better and more modern approach, a next step in evolution I would say.

It does great things behind the scenes and removes a lot of boilerplate code. It also promotes the easy creation of multiple states, well separated (as a parallel, somehow is the same concept where React won a battle with Angular for creating fast and easy components). Redux has somehow the same possibility, even if it is a single object called state as “the only source of truth”. In the end, that object is separated into all the child nodes you consider as independent pieces necessary for storing things related to a clearly defined object. Also, mapping of “state” in any of the components is not for the whole state, but rather for desired keys from it. In the end, if we judge impartially, almost all of them share similar ideas but are packaged and sold differently.

Enjoy the concept

There are also several others that are very popular and worthy of mention (Jotai, XState or Recoil). Honestly, I consider Redux and Mobx as main trend setters in this field. Every library has its own story. Some of them are very light. Some of them offer a complex API and soome of them promote functions and others promote objects. Each with their own arguments. The greatest thing is that it promotes and encourages:

usage of the observer pattern
reactivity
a clear and unidirectional data flow
components with almost no business logic
a very good encapsulation of concepts and features.

Any of these are great in their own way and this paper is not about suggesting one of them. I would rather encourage people to be happy if the project uses any form of state management. Try to use it right. Use all its capabilities and build over main state management ideas in general (and of course, remove the mistakes and all kinds of strange combinations of writing logic everywhere that ends with a merge of “if” statements inside components).

This concept of state management offered a lot, actually a new way of being to the software development world, but if we look behind the exposed API, these libraries are quite easy to understand, without areas with such a complexity that could scare any developer. I would say that is more a lot of sugar syntax over some modern and great practices/patterns. Based on these thoughts and experiences I decided to encourage building a state management mechanism on our own.

I did it my way

To be honest I took part of the idea from the colleague who started the project and applied some reactive concepts quite before they became popular in the JS ecosystem (some people are simply very clever and visionary, and we should respect and be glad that they are around us). I picked the initial idea. “With that little help” from RxJS subjects and Immer the result seems to support the cause for a nice evo-home-made state management.

Below is a GitHub link. There you can see the generic structure of an observable state, the observer React hook, and a very small example of a concrete usage. What you see there is like what we use every day. However, there are several other features that are obviously not representative for this moment. Our states, for example, can broadcast data to other windows. Or they can use the internal subject to create some custom streams with RxJS. Another aspect that may worry some people is the composability of the states. When the composition is about data modeling, the composite design pattern may satisfy the needs. Also, a state can very easily react/subscribe to other state changes.

Check out some code on my Github!

Final Thoughts

Before I end this little post about such a great and big subject, I want to also share some personal ideas regarding the usage of a state management system. I think we should avoid using it for static data that is initialized at the beginning and remains the same for the whole app lifecycle. I’m using the same approach for any kind of data that is not observable and we shouldn’t monitor its value change.

The authentication token sent for API requests is a good example here. The updates of its value, where this is the case, usually will not request an immediate reaction. Another very important thing is to not store ephemeral data, and this is a quite common mistake for state management. With or even without RxJS it is very easy to write your own messaging system or events bus to decouple areas and to not overuse your state that will then need a lot of cleanup.

Article written by Alexandru Ilies

A Proven Method to Easily Project Your Next Sprints Velocity in SCRUM [Spreadsheet Template Included]

evozon — Mon, 28 Aug 2023 09:51:17 +0000

TL;DR

I am presenting a simple method to calculate a team’s sprint capacity and project the velocity for the next sprints provided the team’s project backlog of work items exists and it’s estimated in story points. A spreadsheet template is included for you to consult, use or get some inspiration from.

Background

I have been working with SCRUM for quite some years and have developed over time a simple method to keep track of the team’s capacity and to project the next sprint(s) velocity. It worked pretty well for me so I’m making it public hoping that it will enhance the way you run your sprint planning.

Note: This article assumes that your team has a backlog of work items already in place and they are estimated in story points.

Scrum Framework

Your First Sprint

Say you are a Scrum Master and you need to run your first sprint. What tools can you use to help you? Most probably the company you work for has such tools and you can reach your peers for help. If not, you can develop your tools. And since sprint planning involves a few calculations, the most used software for that is spreadsheets.

What do you need to capture?

Sprint start and end date
List all team members
List the working days in the sprint (0.5 for part-time, 0 for days off)
Fill in the availability for each member on each working day. This will sum up to the total number of working days in the sprint = sprint capacity.

That’s all! These are the bases for the simple math that will help you plan your sprint.

Your First Sprint

Roll up Your Sprints into an Overview Sheet

To have a clear and simple view of all your sprints you need to roll up your sprints into a master sheet, the Overview. To accomplish that you must list your sprints in a column and each refers to the capacity calculated in each sprint sheet.

Overview Sheet

Overview sheet. Refer to each sprint capacity in the first sheet

To project the velocity, you need historical data. But, in the first sprint, you don’t have historical data so you cannot use a formula. What you can do is put a reasonably realistic number there such as the number of sprint working days in the team: the capacity.

Sprint 1

Sprint 1. Projected Velocity = Sprint Capacity (only for Sprint 1)

At the end of sprint 1, you will have the real velocity (actually completed story points). You use that value to project the Sprint 2 velocity:

Sprint 2 Projected Velocity = (Sprint 2 Capacity) * (Story Points per Day in Sprint 1)

Note: Story Points per Day = (Completed Velocity / Sprint Capacity)

For the next sprints, the Projected Velocity will be Sprint Capacity multiplied by Average Story Points per day in Previous Sprints.

Sprint 4

Sprint 4. (Projected Velocity) = Sprint Capacity * (Average Story Points per Day in Previous Sprints)

After 5 sprints your projected velocity will be very realistic. Also, the average completion rate will be closer to 100%.

Completion Rate

Completion Rate. As your sprints are progressing the average completion rate will converge towards 100%.

That’s it! All you need is to (1) at Planning fill the team presence & days off, plus (2) fill the Committed Velocity if it is different from Projected Velocity, then (3) at Sprint End fill the Completed Velocity in the Overview sheet. Three manual steps and the rest are formulas! By the way, don’t worry, all the formulas are already in the Google Spreadsheet template provided at the end of this article.

Summary Table – Columns Explainer
The Overview table above has a good number of columns and they need a brief description.

Sprint # is the Sprint Number or the Sprint Name.

Sprint Start is the start date of the sprint.

Sprint Capacity is the sum of available working days for your members: developers or developers plus testers if you want to include testers in the Capacity calculation.

Projected Velocity is the estimated story points that the team will deliver at the end of the sprint. It is an ideal value, the actual one (completed velocity) will be smaller or higher.

Committed Velocity is the number that your team commits to deliver at the end of the sprint. It may be the same as Projected Velocity, or different. Your team might decide to under-commit, to allow for some work to be injected into the sprint. For example, you can decide that your committed velocity to be 80% out of your projected velocity, to allow for 20% work variation – items that are added in the sprint during the sprint, due to the nature of your project.

Completed Velocity is the number of story points your team delivered at the moment of sprint end.

The Completion Rate is a percentage and represents how much your team has delivered compared to the ideal (projected) velocity. Completion rate = completed velocity / Projected velocity.

Velocity / Capacity is an output quotient that offers you an idea about how many story points are delivered per day, used only to project the next sprint’s velocity.

Become pro: include availability and ramp-up

Your team is not fixed. Some members might not be 100% dedicated to a single team. If a member is part-time, 4 hours out of 8, you can account for that very simply: your daily capacity is not 1 but (e.g.) ½., or they might be in the team Monday to Wednesday, and in the other week Thursday to Friday, etc.

Sprint with Ramp-Up

When you have a new joiner, her first sprint will have a ramp-up factor of 0-10%. That is, her expected measurable output will be close to zero, as she is learning. Each sprint you will increase the ramp-up factor by 10%-20%, so after 5-10 sprints the recent joiner will be reasonably up to speed. This has to be monitored and adjusted for each person, as they adjust and learn at a different pace.

Sprint with Availability

Member Capacity = (Days at Work * Ramp-Up Factor)

And done. Your sprint planning will run smoothly on some simple input data and simple formulas. All your sprints data will be nicely stored and the business can use it in various ways.

As promised, here’s the Sprint Planning Template:

View the template.

Copy the template.

The Romanian translation was published in Today Software Magazine – Estimarea vitezei sprinturilor în SCRUM.

Thanks to Stefania Isaila and Ovidiu Rus for reading drafts of this and providing valuable feedback.

Written by Vasile Tomoiaga

Survey Creation Made Simple: Exploring React Flow's UI Features

evozon — Thu, 17 Aug 2023 13:25:55 +0000

A comprehensive guide on leveraging the power of React-Flow to create a dynamic survey creation UI.

Surveys have long been used to acquire vital data from a variety of audiences. However, developing and creating surveys is a complex undertaking that usually requires technical expertise as well as close attention to user experience. As a front-end developer, you understand the importance of providing users with an intuitive and enjoyable experience, and React Flow brings some of the smoothest and best-animated UI that you can get out of the box for that purpose. So, in this article, I’ll show you how you can simplify survey creation by using React Flow for an intuitive User Interface.

What is React Flow?

React Flow is a library for building node-based applications. These could vary from simple static diagrams to complex visual editors and data visualizations. It supports custom node types and edges, and it includes pre-installed components such as a minimap and viewport controls.

Why would you use React Flow to create surveys?

It looks great. With minimal effort, you receive an out-of-the-box responsive and animated UI that looks impressive.
It’s easy to use. Its drag-and-drop functionality allows users to easily design and modify the survey layout, resulting in a dynamic and engaging user experience.
If you’re already using React, which the majority of web apps are built with, it integrates really well.
Is React Flow free for commercial use?
It’s free for non-commercial use under the MIT License, and you might be able to access some of the paid features, if you plan to use it for educational purposes or in open-source projects but you would have to contact them for that. Otherwise, for commercial use, there is a paid subscription involved, which adds additional support and benefits.

How does React Flow work?

We'll go over the key steps for creating an interactive User Interface that allows users to easily design surveys using React Flow as the interface of choice. So, let’s dive in!

Step 1: Setting Up the Project
To get started, let’s set up a new React project and install the React-Flow library. Open your command line interface and execute the following commands:

Step 2: Creating the Survey Canvas
The first step is to create a canvas where users can design their surveys. We’ll utilize React-Flow’s components to accomplish this task effectively.

Step 3: Adding Survey Elements
Now, let’s empower users to add survey elements such as questions, options, and more. We’ll utilize React-Flow’s actions to handle the addition of these elements.

Step 4: Bringing It All Together
Now, let’s combine the survey canvas and element palette components to create a seamless and powerful survey creation UI.

Final thoughts:

In conclusion, with its dynamic UI, customization choices, responsiveness, community support, connection with React, comprehensive feature set, and extensibility, React Flow is an excellent alternative for generating surveys. With React Flow as the user interface, creating surveys becomes a breeze. It’s super easy and efficient for users to design and launch their surveys without any hassle.

It empowers you to create engaging and user-friendly survey experiences while leveraging the benefits of the React ecosystem.

Article written by Mihai Moldovan, originally published here. and edited by Cristina Strimbu.

How to Effortlessly Keep Your PHP Projects Up-to-Date

evozon — Tue, 08 Aug 2023 11:10:21 +0000

Are your dependencies old enough to go to school? Do you have that one big-ticket that haunts you in the backlog, which aims to upgrade PHP, a Composer package, or the framework’s version? Keep on reading – we’ve got you covered. We faced these challenges as well and, thanks to that, we managed to come up with a solution: developing a tool that makes the upgrade process automatic, continuous, and fun!

As a developer, it’s essential to keep up with the latest tools and technologies and apply them to your projects. With software development constantly evolving (faster and faster lately), it’s natural to have new solutions emerging regularly. By staying up-to-date with these advancements, you can enhance your skills and knowledge, improve your workflow, and ultimately produce better-quality software. In today’s digital age, where cybersecurity threats are becoming increasingly sophisticated, it’s crucial to use the latest tools and technologies to ensure the security of your applications. As you most probably already know, outdated distributions may have vulnerabilities that hackers can exploit. This exposes the software and the users to various threats such as data breaches, malware, and ransomware attacks.

By using up-to-date versions, you (and developers in general) can achieve the following:

Take advantage of the latest security features and updates and ensure the software’s security against cyber threats, giving users peace of mind and preventing potential damage to an organization’s reputation;
Work more efficiently, reduce development time, and deliver more features and functionality to the users;
Prove a commitment to personal and professional growth, which can help you stand out in a competitive job market.
Here at Evozon, we understand the need to constantly improve ourselves and our projects and to deliver high-quality software built on top of the most recent technologies. Consequently, we set a goal to automate the upgrade process, and we’ve created a tool that enables us to keep our projects up-to-date.

World, meet Future!

What is Future? An open-source tool written in Go that streamlines the process of upgrading projects developed using PHP and Composer.

Future offers an automatic, pipeline-based, and efficient way of upgrading projects, saving developers time and effort. How? By splitting the whole process into three distinct phases. Each one focuses on a specific aspect of the upgrade process: the platform, the dependencies, and the codebase. Now, it’s important to also note that each phase is optional and fully configurable. Moreover, all the changes Future applies are made in an isolated environment, without affecting your project.

GO Development Banner (here)

Let’s Dive Deeper into The Process

Phase 1: Upgrading the platform

The first phase involves upgrading the platform that your project runs on. This is essential, as running your project on an outdated platform can result in compatibility issues and security vulnerabilities. Future automates this process by creating a fully configurable Docker container, built using the most recent versions of your platform-related dependencies (such as PHP, databases, etc.). Later, you will use it to run your project’s test suite. Thus, it eases the upgrade process, without worrying about compatibility issues or breaking your app’s functionality. If the upgrade fails, Future provides detailed information about the failure’s reason and proposes the next steps to overcome it.

Phase 2: Upgrading existing Composer dependencies to the latest version

Once you have upgraded the platform, the next step is to upgrade all Composer dependencies to their latest version. Future checks your composer.json file and updates each package to its latest version. If the process fails, you’ll receive detailed information about the not-updated package(s) and what you have to do next to address the situation. Thus, we offer a step-by-step approach that allows you to upgrade your project’s dependencies in small, non-scary iterations.

Phase 3: Upgrading the code to the latest standards automatically

The final phase of the upgrade process involves upgrading your codebase to the latest standards. Future achieves this through the use of Rector, a powerful tool that automates the process of upgrading your codebase by applying a configurable set of refactoring rules. This includes using features added in the latest PHP versions, removing deprecated code, applying modern coding standards, or creating custom refactoring rules.

If all the phases have been successfully executed, Future runs your project’s test suite inside the created Docker container, making sure that the upgrade has not broken your app’s functionality. Throughout each step of the way, Future provides useful feedback on what has been performed. Also, if necessary, detailed information about the error that occurred. This way, you can take the proper actions: apply the upgrade or address the reported issues.

How to upgrade your PHP project using Future

Getting started with Future is really easy. However, it requires two important prerequisites:

CI pipeline;
Test suite.

We believe all projects should have these. Also, we strongly encourage you to add them to your project in case they are missing. Not only for using Future, but for the sake of developing high-quality and robust software.

After managing to meet the prerequisites, all you need to do is:

Install the package;
Add Future as a new and independent step in your pipeline;
Configure the step in order to meet the needs of your project;
Run the pipeline;
Go through the provided summary and apply the suggested changes;
Go to 4.

Code Snippet
Future can be installed as a development-only package in any Composer-based PHP project. For more information, check our GitHub repository. Once installed, you need to create a new step in your CI flow that will create an up-to-date environment in the form of a Docker container. That’s where your project’s test suite will be run after updating all the Composer dependencies and applying the Rector-related refactoring rules. Future provides templates for the main web-based Git repositories, which you can use and configure to match your project’s needs (see the code snippet below).

`future-proofing:

    stage: future

    allow_failure: true

    needs: []

    image: php:fpm-alpine #replace this with the platform you target for the upgrade

    #services:define the services required to run your test suite

    #variables: define the variables required to run your test suite

    before_script

            #performall the necessary steps required to run your project’s test suite

            –  composer install –no-interaction –no-scripts –prefer-dist

    script

            – vendor/bin/future bump-php

            – vendor/bin/future bump-deps

            – composer update -W –no-interaction –no-scripts

            – vendor/bin/rector init



            #register rector rule sets

            – vendor/bin/future add-ruleset \\Rector\\Set\\ValueObject\\SetList::CODE_QUALITY



             #register rector rules

              – vendor/bin/future add-rule \\Rector\\Restoration\\Rector\\Class_\\RemoveFinalFromEntityRector::class



               #exclude rector rules

                – vendor/bin/future skip \\Rector\\CodingStyle\\Rector\\ClassConst\\VarConstantCommentRector::class



                 – vendor/bin/rector process src –no-progress-bar –no-diffs



                  #run your project‘s test suite

                   – vendor/bin/phpunit –no-interaction –colors=never`

Continuous Integration Job Template for Implementing Future

To avoid affecting the workflow of your team, you must allow this step to fail. If something went wrong, Future will collect and provide useful feedback as output which you can use to take action. To facilitate this, create a corresponding ticket that addresses each failure one by one. Once all the failures have been addressed and the Future-related step has passed, you can apply the upgrades Future has made in the isolated container to the main repository through the use of the binary provided by Future (see the section below). Then, you can remove the allow_failure: true option. At the same time, it’s essential to make the job a part of the definition of done of your project, ensuring that any future merge request will be future-proof. One important aspect to keep in mind: once you get to the latest versions, you stay there!

Example of a Successful Pipeline that Uses Future

Demo: Watch Future in action

To better understand the process and highlight Future’s power and simplicity, we created a short demo where we upgrade an application using the binary. Join us as we enhance our app’s platform, Composer dependencies, and codebase and address the challenges we face! The process we present below is just a fraction of what Future can do. It reflects the steps that you should automate in your project’s pipeline when defining the CI step. We recommend using the binary locally only when committing the changes to the repository when the job passes.

Conclusion

Future is an open-source tool that automates the upgrade process of Composer-based PHP projects and provides the resources to make upgrades a step in the workflow of your projects. Therefore, it allows you to stay up-to-date with greater ease. We welcome any contribution and feedback and look forward to your thoughts about Future.

Article written by Ioan Ovidiu Enache, originally published here.