DEV Community: Ahmad Seder

Updating Production data; Script checklist

Ahmad Seder — Thu, 15 Apr 2021 03:29:25 +0000

Bugs are inevitable if you write code bugs will come; We can't ensure 100% bug-free software; that's why we have QA cycles and steps before deploying to production. The nastiest bugs are the ones that need data altering after fixing; For example, you have a point of sale system, and a wrong tax calculation happened and stored in your DB, then you need to update the data after fixing the bug. This tax bug might be a simple one, but imagine one with workflows, and the data object needs to go through different stages before it's done.
In this article, we will talk about a checklist that might help when such cases happen.
When you have such type of bugs, first of all, you need to assist it by answering the following question:

Is it blocking the customer?
Is it reproducible?
Is the fix determined?
Is the damage known?

Your primary focus should be unblocking the customer, even if that means you go and fix the data manually. Then you can reproduce the issue and stop it - this might happen before fixing it - the fix might be as simple as try-catch and log the error, now you should figure out the damage, work on a real fix and write a script to alter the data.

Script Checklist

Ensure you know what you will change, get the affected data, and print some logs; Put the data and the results somewhere and preferably a file system, then email it.
Make sure it is reversible; yes, your code effect must be reversible if something went south.
Take a copy of the data, if possible, before altering it.
Ensure that the code you wrote is working, get help from some reviewers, run it in a different environment if possible.
Calculate the estimated time for your script, and this is crucial for all parties (Engineering, Support, and the customers )
Have proper logs, for example( [ScriptName][PRE]I am changing the Product with ID 3, from value X, to value Y ), [ScriptName][POST][Success]Changing the Product with ID 3, from value X, to value Y ), [ScriptName][POST][Failure]Changing the Product with ID 3, from value X, to value Y, due to REASON and TRACE ).
Have a progress indicator, such as [ScriptName][Progress] 10% 9/100 are done successfully, 1/100 failed Running for 3 minutes and 9 seconds ETA is 30 Minutes
Have a kill switch. You might add a simple boolean in your DB and read it before each iteration. In software, nothing guaranteed
Email the results once its done
Make the code very flexible so you can run it only on a small set of data as a start
Make sure the audit log is clean and clear. You don't want to confuse your customers with unfamiliar names on the audit log.
Secure the script accessor. If you run it over HTTP or other, you must secure it, avoid hacking, and, most importantly, someone running it by mistake. Use an encoder for the endpoints and simple passwords such as "IKnowWhatIAmRunning,TheTaxUpdateScript", or add expiry date on the code.
The script code is a code, make it reusable and leave it well documented.

At some point, you might need to make your script framework or just a nice Abstract Class and implement the logic of the script.

Conclusion
The software will have bugs, and hopefully, they are the friendly type. In case you needed something to alter the data, make sure it is reversible, keep it visible to everyone in terms of updates, and make sure it is secure and not easy to run.

I hope you don't ever need to do this, but if you do, I hope it helps.
What other points can we add to this list?

[Discussion] Challenges in Frontend for SaaS Apps.

Ahmad Seder — Wed, 10 Mar 2021 22:59:19 +0000

Dealing with SaaS apps requires some specific considerations on the frontend. Some might be related to the tools, architecture, or libraries on the whole FE stack.

What challenges did you face?
How you fixed those challenges?
Which area do you think is underdeveloped?

I would love to share and expand my experience in this field as a series "Frontend for SaaS Apps Series" and your points will help me define the right scope and starting point.

Keeping up with the "constant catching up" in Frontend engineering

Ahmad Seder — Sun, 06 Sep 2020 11:38:55 +0000

The frontend engineers face a challenge "Constant catching up" there almost every day a new thing to learn or a new framework to check, and that needs a lot of energy and a long breath to do.

Furthermore, frontend apps are getting more complex, and the use cases are going beyond building a website or an app. We start seeing architectures and solutions to simplify the technology we learned in a few weeks, and those solutions need a few weeks to learn.

In this article, I will try to focus on the frontend constants that each of us should know to overcome the main challenge of the frontend engineering -"Constant catching up "- by abstracting the frontend frameworks/libraries.

What are the constants in frontend engineering?

Everything should run in a browser.
We have to communicate with servers to load data, save data, or load assets.
Users have to interact with our apps.
We, as engineers, have to write code to make the above happen.

The entire history of software engineering is that of the rise in
levels of abstraction. Grady Booch

Everything should run in a browser.

This fact should be a relief for all of us, because if we understood how browsers work, then we have come a long way of establishing our career as frontend engineers based on its core.

Two main things you need to focus on:

DOM Manipulation
Event Loop

DOM manipulation is crucial, and you need to understand how it works and what it does, and what might go south. Frameworks leverage DOM in different ways, but still, they are using the same APIs.

When looking at any FE Framework, please look at how they deal with DOM manipulation and how they deal with the fact that DOM operations are performance expensive.

For example, React deals with that with the Virtual DOM to optimize the rendering process.

Here is a gist from Paul Irish, listing the most expensive methods and properties that make the browser reflow - the process of synchronously calculate the style and layout, and ask the browser to repaint the affected elements -.

Event Loop, it's known that each tab has a single thread, but still we write async code all the time with JS on the browser; how is that possible?

Event loop is the answer. Wikipedia defines it as "In computer science, the event loop is a programming construct or design pattern that waits for and dispatches events or messages in a program. The event loop works by making a request to some internal or external "event provider", then calls the relevant event handler."

The event loop interacts with web APIs such as ( DOM, XMLHttpRequest, and more ). We have a task queue, which has all the tasks to be run, including your callbacks, and we have the call stack something being processed and the event loop, which takes from the queue to the call stack when the call stack is empty. Call stack adds to the queue ( Callbacks ) and interacts with the web APIs.

Check this excellent talk by Philip Roberts, What the heck is the event loop anyway? | Philip Roberts | JSConf EU also Loupe that visualizes the event loop by Philip as well.

Client-server communication

Our app runs in the browser, and it needs to load assets, load data, and save data.

Loading Assets

How the browser load assets will affect the performance, and the user experience is one reason we have bundlers and different HTML attributes of prefetching and lazy loading.

This topic is crucial because you will know why some tools exist, handle specific performance issues, and mostly why specific features exist in some frameworks such as React.lazy().

Look at how we started with client-server communication and ended with mentioning a feature from one of the most popular frontend libraries.

Loading Data / Saving Data

Loading & Saving data need a client-server communication; it might be a pulling technique or pushing such as sockets. Browsers have limits on the number of concurrent requests per domain, affecting how we show our users' data and how they interact with our application.

HTTP interceptors might take place in our apps, validate data or transform it, etc. Those interceptors will use the browser fetch/XMLHttpRequest API or and add some logic around it despite that they come with a framework or a separate library.

User experience

FE Apps are interactive, so we need input from the user or wait for her action to apply logic, such as updating the DOM.

Updating the DOM task can be pretty straight forward such as

document.getElementById("myDiv").innerHTML = "New Content";

or a very complex one such as managing two way data binding in VueJS

<input v-model="message" placeholder="edit me">

<p>Message is: `{{ message }}`</p>

At the low level, they will both use the event loop and let the browser take the right action.

User experience is not only about DOM manipulation or performance, but some frameworks also provide a design system to maintain UI consistency.

Developer experience

The rise of frontend frameworks & libraries focuses a lot on how engineers interact with this tool, and we are grateful for that. They care about our productivity, the clarity of code we write, the amount of code we produce, how it can scale, and how easy and fast we can go.

The community around a specific tool is crucial for its success, its problems, and how it resolves it is what gives it its early adopters.

Developer experience, or DX, doesn't stop here but goes to cover the learning curve, productivity, tools, and much more.

To keep with the constant change, you have to know what value is the tool adding to you as an engineer, and DX is directly impacting the UX, don't compromise over it.

Let's try to abstract a feature from React and Angular.

React

In React, let's take the first feature, Composition.

"The key feature of React is composition of components. Components written by different people should work well together. It is important to us that you can add functionality to a component without causing rippling changes throughout the codebase."

What it affects?

Developer experience, reuse the code easily.
User experience, consistency.

JSX contributes the most to the composition feature, but the browser doesn't understand JSX. That's why we have transpilers to convert a component to JS code that can interact with the DOM APIs; nevertheless, it has VirtualDOM, it will use the DOM.

Angular

SPEED AND PERFORMANCE / Code splitting

"Angular apps load quickly with the new Component Router, which delivers automatic code-splitting so users only load code required to render the view they request."

What it affects?

User experience, the performance of the apps will be faster.
Developer experience, you don't have to worry about this. We got your back.

Code splitting will be done internally in Angular AOT compiler to decide how to split the code, and the browser has to determine when to load which chunk and how.

Summary

We should focus on understanding the constant things or the things that are hard to change in frontend engineering. We should understand how our apps are running internally inside the browser to correctly use the right tool, framework, library, or even the line of code to achieve our goal.

Becoming a sound frontend engineer implies that we have a smooth learning curve journey, our minds are open to quickly grasping new frameworks, concepts, or features. The code we write, the passion we feel while writing it, and our pride after achieving our goals are priceless.

For a simple reason, we write frontend apps, deliver value for our users, and the value will not be enough if we, as engineers, haven't enjoyed the journey.

How ownership can make you a better software engineer

Ahmad Seder — Sat, 18 Apr 2020 20:42:34 +0000

First of all, I will define what ownership means from my perspective as a software engineer.
Ownership, the actions that the software engineers do because they know that their work is crucial to the success of the project, team, and the company they are working at; It's not only about actions, feelings and passion are important as well here.

Ownership will force you to learn more

If you have ownership then you are committed to the best quality you can deliver; When you commit to quality you will start reading more about your deliverables, about the technology stack you are using, what makes it better, etc.

For example
if you are a frontend engineer that your task is to create a contact form.
If you just want to deliver it you can do that in no time, but if you are committed to the best quality I am sure you will start searching for other contact forms, maybe you will stumble upon some weird terms such as a11y, A/B testing, performance budget, or analytics.

So your "Ownership" leads you to learn more to deliver the best quality.

Ownership will make you a better team player

Teamwork is a quality attribute of any software engineer, to the point that we stopped writing it down in our CVs because you have to have it as much as having good problem-solving skills.

Ownership will force you to communicate with your teammates and go far and beyond to help them get the work done because you are a crucial part of their success and you know it.

Owners will not point fingers, they will jump in to help because they care about how to make it work rather than blaming someone. And as humans, we love to be helped so we have to help to earn that.

Ownership will enhance your debugging and engineering skills !!

Debugging skills is essential for any software engineer. because we build both software and bugs, the beauty of it is that we KNOW it.

Imagine you are at home watching Netflix at 2:00 AM, and boom slack notification in your production issues channel; without thinking you will go and check it out and you replied I am taking a look.
After your initial investigation, you found that the bug is data returned in a wrong format from BE.
You put a quick fix in the FE to unblock the customers - because you care - and then you went back to trace WHY it's wrong as a Frontend engineer you reached the ORM class and found the root cause.
You went through 3 or 4 microservices, and found the root cause!! You are CHOSEN!!
And simply sent a slack message to the engineer working on the ORM, and said hey I think the incident is related to those lines, next day at work she will buy you coffee and respect what you did

You debug because you are committed to the success of everyone around you, and it's a brain training the more you do the better you will be.

Ownership will make you take more responsibilities

The more ownership you have the more you will know, the more you are respected among your teammates, and in your company; That will make you a go-to person in some cases even if you don't know anything about that topic you will start being curious about it, check the "LEARN MORE"

More responsibilities mean a bigger role, more challenging tasks, and maybe a raise :P.

Summary

For whatever reason that doesn't make you feel like an owner, I have to jump in here and tell you to do it even if it for yourself not for anyone else, you will grow no matter what.

There is a myth that says, If sharks stopped moving they will die.
Keep moving for your own sake you will grow and make people around you grow as well, you will make

Have the faith that if you do good you will be rewarded, in your current position or somewhere else.
Ownership will make you a better software engineer because you will:

Learn more.
Become a better team player.
It will enhance your debugging and engineering skills.
It will open the path for more responsibilities.