Forem: Amr Mohamed

Stop posting AI generated posts on dev

Amr Mohamed — Tue, 22 Apr 2025 13:15:42 +0000

I don’t wanna be rude here but I have used the dev community as my safe zone to read fun stuff, genuine tech opinions and I used to write sometimes about some JS things..

I’m currently seeing AI generated content everywhere, not only that, I’m seeing posts that has the same account replying with almost the same tone in different posts and are AI generated.

I honestly see the value of AI and helping you to write, but using it like an automated tool to spit out posts and random comments is just very ugly. Please stop doing that :)

The sense of achievement while using AI

Amr Mohamed — Mon, 21 Apr 2025 16:36:20 +0000

Ever since AI tools emerged and became a thing my sense of achievement while using these tools became…a bit challenged I’d say.

Whenever I had free time or some kind of innovative idea came into my mind to solve something that should generally be kept unsolved (like creating an Alexa app to ask her about the next arrival of Tram 21 in Berlin, Lichtenberg) I’d open my laptop, my eyes would pop and I’d spend hours or maybe a couple of days implementing the idea. It usually take a lot of time to do the little things like deployment, infra code or doing the bar minimum of CSS and user experience…duuuh.

Now, I just open my beloved Cursor editor or open Lovable or anything similar and type a couple of prompts, keep telling the AI to fix a bug or two and I get my desired output almost 2x faster than I would do it myself. Don’t get me wrong here, I still think I’m better if the task includes deep dives or general engineering skills like performance improvements and what’s not, but doing these side small projects are just very easy nowadays.

Sense Of Achievement

I don’t know about you, but the process of developing such side projects is the key factor for my satisfaction and happiness…relying on these tools made my sense of achievement levels drops significantly and led sometimes to me just talk to an AI tool to help me validate the idea..and I eventually stop caring about implementing it, cause why should I?

I even thought about passing this article to an AI tool to make it a bit interesting in terms of writing and more engaging cause my English is not perfect after all..do these AI tools take the sense of achievement from us eventually at work too? Cause come on, CEOs are coming with insane statements about vibe coding and using AI tools everywhere.

My takeaways from this

To be honest, I hate it and love it at the same exact time. Recently I have been creating some small utility tools for my life tasks and it is insanely good at doing some of the code for these tasks. At the same time, I think I should rely on these tools a bit less, let my imagination of how to implement something figure the heck of my side ideas a bit instead of jumping to a non stop agentic mode without even providing consensus for the outcome.

What do you all think about this? How do you cope with this feeling or how do you feel about these tools eating your creativity like it does with me?

Why Singletons Are Bad?

Amr Mohamed — Sun, 15 Aug 2021 00:42:16 +0000

Singleton is a widely known design pattern that generally allows you to create a global object that can be accessed from anywhere in your application and it will assure that this object will be initiated only once per lifetime of your application/code.

Before digging into why such a pattern could cause lots of problems in your codebase let us first try and implement it and imagine a use case where it would fit.

How To Implement?

From its name a singleton is a single entity or object that would be created only once, how could we achieve something like that? how could we for example declare an object of type class A for example and disallow any other creations of instances of the same type?

Let us look at the code and discuss it further:

class Singleton {
    private static instance: Singleton;
    private constructor() {

    }
    static getInstance() {
        if (!Singleton.instance) {
            Singleton.instance = new Singleton();
        }
        return Singleton.instance;
    }

    // some other logic
}

let a = Singleton.getInstance();
let b = Singleton.getInstance();

// both a and b points at the same instance

What can we deduce here is that we have made our constructor a private function, meaning if we simply tried let c = new Singleton() an error would occur as we can not access private methods in our class.

Another thing we did is we created a private static member of our Singleton type and then we create a public method that initiates our private static instance if it is not initiated and simply returns it. By doing that we assure that whenever we call the getInstance function we will have the same instance in our codebase.

A Use Case

Where could we use something like this in our application? someone could purpose that if for example, we have an application that requires some kind of authentication we could make our User object treated as a singleton so our whole application code could access it and manipulate it if needed.

class SingletonUser {
    data: any;
    private static instance: SingletonUser;
    private constructor() {}
    //...singleton logic


    changeData(data) {
        this.data = data;
    }

    // some other logic
}

By this, we could for example change the user's data when he logs in or logs out and so on.

Why Singletons Are Bad?

If we think about it for a second we now have our user's object globally initiated and any method or class in our codebase have an access to such object and could easily manipulate it, this could result in creating bugs and issues that are hard to maintain and find because you will have to figure out which part of your codebase changes or interacts with your singletons.

Another reason is that singletons increase coupling and decrease cohesion because if you want to change the behavior or extend its functionality you will have to change the class of the singleton.

The problem here arises when you have lots of areas that depend on your singleton and depend on its functionality, if somehow you needed to change the functionality of your singleton you will now be at risk that all of the areas that depended on it might crash or act in incorrect behavior.

Singletons also could cause you a nightmare when you are writing unit tests for your application. The idea behind unit testing is being able to test your functions/classes/modules without depending on other dependencies, when using singletons we will then have to initiate the correct shape for our singletons so that our methods/classes/modules would act correctly when under testing.

Singletons also violate the Single Responsibility Principle : In addition to their main responsibility, they are also responsible for implementing their own lifecycle.

When a class has multiple responsibilities "Like Singletons" it makes it harder to maintain and test, now you will need to test not only one responsibility but 2 and usually singletons carry lots of logic inside of them because they are being consumed through your whole application.

There are a lot of SOLID principles that Singletons violate like the Dependency Inversion Principle and Open / Closed Principle

Conclusion

Generally, I believe that Singletons have their own use cases but I would not recommend using them as Singletons are very much like the good things in life, they're not bad if used in moderation and through my coding career that never happened :D

Why NaN === NaN returns false in JavaScript ?!

Amr Mohamed — Wed, 04 Aug 2021 01:01:06 +0000

When people start exploring topics about JavaScript they get to feel a little weird sometimes and they also start to wonder why the heck do JavaScript act in such a manner, there have been even Github Repos like You Don't Know JS that explains how JavaScript works and so.

Today I wanted to explain a gotcha topic that people usually post memes about and hate on JavaScript because of such a topic ( Which I kinda understand why they do so ), I will be explaining why NaN === NaN results in a Falsy expression. Let us get started with some basics first.

What is the difference between `==` and `===`

Whenever we compare two variables using the double equal operator we compare them using only their values, meaning if a variable A contains some value and variable B contains some other value and we did A == B what will happen is that JavaScript will check their current values and return true if they are equal.

but what if we did something like this: "1" == 1, what would be the result of such expression?

A normal person with some logical understanding would definitely guess that the output would be false because we are comparing a string to a number even if they have the same characters.

What will actually happen is that this output will be expressed as true. Why is that? When we use the double equal operator JavaScript will attempt to convert and compare operands of different types, meaning that they both would be converted to the same type and in case of comparing a number to a string JavaScript will try and convert the string to a number type like this: Number("1") == 1 which will output in that case true.

What if we have a case in which we actually want to compare the types of the variables we have and then compare their values without attempting any conversion?
In that case, using the triple equal operators or the Strict equality would come in handy, what the strict equality operator simply does is checking if the operands are of the same type and then checks if they have the same value or not.

let a = "1";
let b = 1;

console.log(a == b) // true;
console.log(a === b) // false;

We could simply imagine that JavaScript under the hood does something like this when using the strict equality:

let a = "1";
let b = 1;

console.log(typeof a == typeof b && a == b)  // in case of doing a === b;

What is `NaN`

According to the MDN documentation NaN is:

NaN is a property of the global object. In other words, it is a variable in global scope.

So basically NaN is simply a global object that describes what a not number is or whenever we have a variable that we are attempting to convert to a number and we fail it simply gives us NaN like this:

let a = "hello world";
let convertedToNumber = Number(a);

console.log(convertedToNumber); // NaN;

What is `typeof`

typeof is simply a JavaScript operator that returns a string that indicates the type of an operand.

There are basically 9 types in JavaScript:

Undefined "undefined"
Null "object" (see below)
Boolean "boolean"
Number "number"
BigInt "bigint"
String "string"
Symbol "symbol"
Function object (implements [[Call]] in ECMA-262 terms) "function"
object "object"

Whenever typeof is used one of these types would be the result, an example for that would be:

typeof "" // string;
typeof 1 // number;
typeof function() {} // function;
typeof true // boolean;

Why `NaN === NaN` returns `false`?

And finally, let us get into the core of this article, why when we explained how strict equality works and what is NaN does this expression provide us with a falsy value?

let us simplify the answer by looking into the strict equality comparison algorithm:

let us define the following two operands: x, and y.

according to the JavaScript documentation ( This is a snippet from the docs ), the comparison algorithm works in the following matter:

The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows:

If Type(x) is Number, then
If x is NaN, return false.
If y is NaN, return false.

This means that the algorithm first checks if one of the operands is NaN before even checking their types and if so it will return false anyways.

This may be a weird implementation of the comparison algorithm but there are some workarounds for this, we could use built-in functions like Number.isNaN() to check whether the giving parameter is a NaN or not instead of comparing it with NaN directly

let invalidNumber = Number("asdasdasd"); // NaN;

let resultOfNormalComparison = invalidNumber === NaN; // false;
let resultOfBuiltInComparison = Number.isNaN(invalidNumber); // true;

Edit:
This part is being edited after recieving comments about why actually NaN is not equal to NaN from a mathematical prespective, I came accross this answer in stackoverflow and it helped me alot, would recommend it to anyone: answer

Conclusion

You could somehow disagree on the implementation of the comparison algorithm but there are workarounds to check if a given variable or parameter is a NaN or not as shown above.

References:

JavaScript Generators...What and Why?

Amr Mohamed — Mon, 26 Jul 2021 21:39:19 +0000

Generators in JavaScript are one of the concepts that took me a while to get my head around and to fully understand its power and usages. In this post, I will walk you through a simple explanation of how Generators work and some practical uses of it ( How to create an infinite loop without crashing your application for instance )

What is a generator?

First, let us talk about the broad idea of what generators are. The way I understood it generators are a special type of function that does not return a value but instead it returns multiple values whenever you ask for them.

Generators can be imagined as a way to stop the execution of a function at a specific point and retrieve the output and then continue the execution. What makes the execution stops is a special keyword called yield so whenever this keyword is found this means that a value is being generated by the generator function.

Let us look at a simple example.

function* basicGenerator() {
  yield 1;
  yield 2;
  yield 3;
  return 4;
}

Here we defined our generator function, whenever we want to create a generator function we have to provide an asterisk after the function keyword.

If we thought about the output of such a function we would probably say that it will output 4, but here comes the tricky part, generators return a generator object which looks like // [object Generator]

This object will be responsible for the execution of the function.

function* basicGenerator() {
  yield 1;
  yield 2;
  yield 3;
  return 4;
}
let generator = basicGenerator();

let firstResult = generator.next();
console.log(firstResult);
// {value: 1, done: false}

Here we executed the basicGenerator() function and it returned a generator object and we logged its output. The Generator object contains three main functions, a next() to continue the execution and returns an object of value and done ( will discuss it in a moment ) and a throw() that stops the generator's execution and throws an error and a return() that finishes the execution the return a value.

Let's first look at how the next() function works, when we execute it the generator function will point to the next execution level or the next yield keyword and will return a value of the previous yield keyword. So in the above code the first next() will return {value: 1, done: false} and will point to the next yield that shall return 2 in the next execution.
You might ask what does done refer to? done will always be true until there are no more yields available for execution or the execution pointed to a return keyword, at that moment any next() calls shall return an undefined value.

According to what we said above we should understand the output of the code below:

function* basicGenerator() {
  yield 1;
  yield 2;
  yield 3;
  return 4;
}
let generator = basicGenerator();
let data = {};
while(!data.done) {
    data = generator.next();
    console.log(data.value);
}
// [1,2,3,4]

Here we created a while loop that will keep asking for values till the generator returns an indicator done : false that indicates that there are no more executions available in our generator.

Generators are iterable

Another thing that should be taken into account is that generators are iterable and a for...of could be used to iterate over the values of a generator like this:

function* generateSequence() {
  yield 1;
  yield 2;
  yield 3;
}

let generator = generateSequence();

for(let value of generator) {
  console.log(value); 
}
// 1 2 3

Passing values to generators

One of the very handy features in generators is you can actually pass an argument to the generator and it will be read in the execution level that the generator is pointing at. Lets look at an example to further explain this.

function* basicGenerator() {
  let res = yield 1;
  console.log(res); // Passing This
  let res2 = yield 2;
  console.log(res2); // Done Passing
  yield 3;
}

const generator = basicGenerator();
generator.next();
generator.next("Passing This");
generator.next("Done Passing");

As shown above, now we not just calling the yield keyword, we are also assigning a variable to its output, and when we call the generator next() function we first pass no arguments ( the first next is by default will neglect any passed arguments ) and then we pass whatever we want, so the second next will have Passing This passed to it and thus it will assign this value to the first variable in our execution which is res and then we pass another argument and res2 shall receive the Done Passing value.

This could be very handy as now we not just control the execution of our Generators but we also could pass arguments to them and manipulate their behavior accordingly.

Why would we use Generators?

One of the use cases that generators are used for is simulating an infinite loop. For example, if you decided that you want to create an ID generator that starts from 0 till Infinity you would do something like this:

function* infiniteIdGenerator() {
  let start = 0;
  while (true) yield start++;
}

const generator = infiniteIdGenerator();
generator.next(); // 0
generator.next(); // 1
generator.next(); // 2
generator.next(); // 3
// ...Infinity

And now you could generate a new ID whenever you want and it will be guaranteed that it will be a uniquely created one.

Another use case is throttling, throttling is basically delaying the execution of some code or function.

export function* throttle(func, time) {
  let timerID = null;
  function throttled() {
    clearTimeout(timerID);
    timerID = setTimeout(func.bind(window, arg), time);
  }
  while (true) throttled(yield);
}

const generator = throttle(() => console.log("some logic"), 300);
generator.next();

Conclusion

I explained some of the core concepts of generators today but actually, there are way more than I said today, there are other ways generators are used like generators composition, and even it is used in one of the most famous redux libraries, redux-saga that allows it to create side-effects with generators.

Closures and their practical uses

Amr Mohamed — Sun, 25 Jul 2021 01:43:27 +0000

What the heck are closures anyways?

According to the official Mozilla website closure is:

The combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

When I first read this the first time I couldn't fully understand what it actually means or how closures function in JavaScript or pretty much any other programming language.

I would have loved it if someone explained it to me in a simpler way.
Basically, a closure is a way that allows functions that are living inside outer functions to access the outer function's scope, the scope could be either variables or even other functions that live inside of it.

function outer() {
  let name = "Amr";
  function inner() {
    console.log(name);
  }
  inner();
}

outer();

In the above snippet there is a declaration of a function called outer and inside of it we declared two things:

A variable called name
Another function called inner

We then invoked the inner function inside the outer function scope and logged the variable name, if we thought about the output of such code we would think that this code snippet is wrong because there is no variable called name inside the inner function scope, thus the console would definitely output undefined.

At this exact point closure shines, the idea here is that function inner has an access to the scope of the outer function, meaning that it actually sees the variables or objects declared inside of our beloved outer function and this also would work if we did something like this:

function outer() {
  let name = "Amr";
  function inner() {
    console.log(name);
  }
  return inner;
}

let innerFunc = outer();
innerFunc();

After returning the inner function when invoking the outer function, we could invoke the inner function and still get the value declared before in our outer function and that is the whole point of closures.

Uses of closures

Now comes the fun part, where on earth on our codebase could we use such a strong feature?

Let us start by thinking about a very basic scenario, what if we have an application that contained a counter, and whenever the user does something (let us say clicks a button ) the counter is incremented by 1.

A basic solution for such a scenario would be like this:

let counter = 0;

function incrementCounter() {
  counter++;
}

Here we defined a global variable for our counter and a function called incrementCounter that increments our counter by one.
This solution would work but the problem here is that our counter is defined globally and this could allow other functions to manipulate the counter current value thus making our code less maintainable and at risk of bugs.

Here closures would solve such problem by the following code:

function counterClosure() {
  let counter = 0;
  function increment() {
    counter++;
  }
  return increment;
}

let increment = counterClosure();
increment();

Now we defined our counter variable inside a function called counterClosure and whenever we want to increment it we can simply call the inner function which is called increment and the counter variable would be enclosed and not manipulated by other functions.

this could even be refactored a little bit:

function counterClosure() {
  let counter = 0;
  function increment() {
    counter++;
  }
  function getCounter() {
    return counter;
  }
  return {
    increment: increment,
    getCounter: getCounter,
  };
}

let { getCounter, increment } = counterClosure();
increment();
console.log(getCounter()); // 1

Now we can get access to our counter using the getCounter function returned.

Another use case which I personally used before if what if we needed to create HTML elements and pass content to these elements whenever we are creating them?
lets look at how closures would solve this:

function elementCreator(open, close) {
  return function (content) {
    return `${open} ${content} ${close}`;
  };
}

const br = elementCreator("<div>", "</div>");
const header = elementCreator("<header>", "</header>");

const headerContent = header("Hello this is a header");
console.log(headerContent); // <header> Hello this is a header</header>

Here we defined a function that simply returns another function that takes content as a param, this is very handy as we now created functions for creating div and header elements and we just need to pass content to such functions, we could also use composition to even pass another element inside, for example, the div element like this:

const divWithHeader = header(div("hello div"));
// <header> <div> hello div </div> </header>

Conclusion

This is it for this post about closures, there are numerous other uses of closures that I did not cover today but in the end, I would definitely encourage using closures in scenarios like encapsulating logic ( defining private variables ) and in composition ( This comes very handy if you are in love with functional programming )

Forem: Amr Mohamed

Stop posting AI generated posts on dev

The sense of achievement while using AI

Sense Of Achievement

My takeaways from this

Why Singletons Are Bad?

How To Implement?

A Use Case

Why Singletons Are Bad?

Conclusion

Why NaN === NaN returns false in JavaScript ?!

What is the difference between == and ===

What is NaN

What is typeof

Why NaN === NaN returns false?

Conclusion

JavaScript Generators...What and Why?

What is a generator?

Generators are iterable

Passing values to generators

Why would we use Generators?

Conclusion

Closures and their practical uses

What the heck are closures anyways?

Uses of closures

Conclusion

What is the difference between `==` and `===`

What is `NaN`

What is `typeof`

Why `NaN === NaN` returns `false`?