DEV Community: Nabil Tharwat

Boosting My Productivity With Git Worktrees

Nabil Tharwat — Tue, 17 Sep 2024 18:43:05 +0000

I often work on several features simultaneously, which leads me to stash changes and forget about them while switching to other tasks. I tried using git hooks and terminal aliases as reminders, but they were either too much hassle or easy to ignore. So, I had to find a better solution.

This article was originally posted on my blog over a year ago but I keep coming back to it. Re-sharing it to the world :)

Git in a nutshell

Git stores information as a list of snapshots. A snapshot is a stored version of the repository at a given point in time. Each commit represents a snapshot in the git world.

The working tree is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. This is the place in which you do your work before staging and committing.

Git Work Trees

Git Worktrees are a way to manage multiple git working trees at the same time without the hassle of git stash. They allow us to work on branches as sub-directories to a repository, completely alleviating the pain of stashing changes when an urgent, unrelated change is required.

The worktree module allows you to checkout multiple versions of the project in separate sub-directories in the same root directory of the repository. Take the following diagram for example on the traditional approach:

In this example I have two stashed changes (which could be hundreds of lines of code) and 3 branches, feature-1, feature-2, and fix-1. By the time I finish working on the fix-1 branch and push it my brain would've jumped to the next task and completely forgot about the previous features until I'm reminded of them again.

Instead, with worktrees, it looks like this:

With worktrees the directory structure contains each worktree (branch) in a separate directory. This allows me to seamlessly switch from a branch to another simply by changing the directory I'm currently working in. My usual workflow with this approach consists of the following:

Open a terminal in the project's directory
Create a worktree with a branch name
code . to open VSCode in the worktree directory

When I want to switch from a worktree to another all I have to do is either create a different worktree using the same steps if I don't have it created already, or simply open a different directory with VSCode and start hacking away immediately.

Creating a worktree

Creating a worktree is as simple as running git worktree add directory-name branch-name for existing branches or git worktree add directory-name -b branch-name to create a new branch.

Deleting a worktree

After you're done working on a branch you can safely remove the worktree to stop polluting your directory structure. Simply run git worktree remove directory-name. This doesn't delete the underlying branches so you can safely check them out again later.

Gotchas

Worktrees are checkouts of repository branches, therefore untracked files are not copied. Files like .env won't be copied, so make sure to copy them after creating a worktree and install dependencies if any exist.

Also note that the directories created for the worktrees will show up in git status logs when executed in the root repository directory. These gotchas are nothing to me compared to forgetting hours of work though.

Thank you for reading! You can read more on my blog and support my work on GitHub Sponsors!

Big O Notation

Nabil Tharwat — Fri, 21 Jun 2024 11:30:50 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

Big O describes the efficiency of the worst case scenario of an algorithm. It helps categorize algorithms, but isn't accurate to describe real performance. An algorithm that does constant time O(1) may be slower due to complexity than a linear one O(N).

You're doing state wrong

Nabil Tharwat — Sun, 09 Jun 2024 12:40:51 +0000

Implementing component state as a combination of booleans may seem like the easiest way to do it, but let's do something different.

Cover by Namroud Gorguis on Unsplash

This article is framework- and language- agnostic. Code examples presented are written in a generic form.

Consider a music player

That can play, pause, and stop. Developers are often tempted to represent
each state in a separate boolean:

const isStopped = createState(true)
const isPlaying = createState(false)
const isPaused = createState(false)

If you think about this for a moment, each of those boolean states can be either true or false. Counting all possibilities yields 8 possible state variations, when our component only has 3 actual states. Which means we have 5 impossible states in our tiny component.

Impossible states are states that the component is never meant to be in, usually indicating a logic error. The music player can't be playing and stopped at the same time. It also can't be paused and playing at the same time. And so on.

Guard statements usually accompany boolean states for this reason:

if (isStopped && !isPlaying && !isPaused) {
    // display stopped UI
} else if (!isStopped && isPlaying && !isPaused) {
    // display playing UI
} else if (!isStopped && !isPlaying && isPaused) {
    // display paused UI
}

And state updates turn into a repetitive set of instructions:

// To play
setIsPlaying(true)
setIsPaused(false)
setIsStopped(false)

// To stop
setIsPlaying(false)
setIsPaused(false)
setIsStopped(true)

Each addition and modification later to the component needs to respect these 3 valid states, and to guard against those 5 impossible states.

Hello, state machines!

Every program can be simplified into a state machine. A state machine is a mathematical model of computation, an abstract machine that can be in exactly one of a finite number of states at any given time.

It has a list of transitions between its defined states, and may execute effects as a result of a transition.

If we convert our media player states into a state machine we end up with a machine containing exactly 3 states (stopped, playing, and paused), and 5 transitions.

Now we can represent our simple machine in a single state that can be anything, from a Union Type to an Enum:

type State = 'stopped' | 'playing' | 'paused'

enum State {
    STOPPED,
    PLAYING,
    PAUSED
}

Now state updates can be a single, consistent instruction:

setState('stopped')
// or
setState(State.STOPPED)

With this approach we completely eliminate impossible states, make our state easier to control, and improve the component's readability.

What about effects?

An effect is anything secondary to the component's functionality, like loading the track, submitting a form's data, etc. An action.

Let's consider forms. A form is usually found in one of four states: idle, submitting, success, and error. If we use boolean states we end up with 4 booleans, 16 possible combinations, and 12 impossible states.

Instead, let's make it a state machine too!

The code behind this machine can be as simple as another method on the component:

enum State {
    IDLE /* default state */,
    SUBMITTING,
    ERROR,
    SUCCESS
}

const submit = (formData: FormData) => {
    setState(State.SUBMITTING)

    postFormUtility(formData)
        .then(() => {
            setState(State.SUCCESS)
        })
        .catch(() => {
            setState(State.ERROR)
        })
}

The exception

Obviously there are cases where a component may truly have only 2 states, therefore using a boolean for it works perfectly. Examples of this are modals to control their visibility, buttons to indicate a11y activation, etc.

const isVisible = createState<boolean>(false)

const toggle = () => {
    setState(!isVisible)
}

The problem starts to form when you introduce multiple booleans to represent variations of the state.

I still need booleans!

You can derive booleans from your state. Control your component through a single state machine variable, but derive a hundred booleans from it if you want.

Using the form example:

enum State {
    IDLE /* default state */,
    SUBMITTING,
    ERROR,
    SUCCESS
}

const state = createState(State.IDLE)

const isSubmitting = state === State.SUBMITTING
const hasError = state === State.ERROR
const isSuccessful = state === State.SUCCESS

Wrap up

Thinking of components as state machines has helped me simplify a lot of codebases. It's effect on the overall accessibility of a codebase is truly immense. Try it and tell me what you think! 👀

Thanks for reading! You can follow me on Twitter, or read more of my content on my blog!

Making a Build System Using NPM Scripts

Nabil Tharwat — Fri, 02 Dec 2022 15:21:35 +0000

Cover by Guillaume TECHER on Unsplash.

This article was written on my phone. Do not expect these scripts to actually work except for the last set.

npm scripts are a way to execute multiple npm modules and system commands through npm. You may already be familiar with npm run, which is the interface we use with npm to execute those commands, and the interface we'll use to run our build system by the end of this article.

From my Release Management for Modern Software Development article:

A build system is a set of transformations that transform a source into an artefact. It may be a simple command that starts up a compiler, a script to generate pdf from text files, or even a GUI solution that builds your project and generates a binary.

Our build system will be composed of the following steps:

Linting
Type-checking
Unit testing
Snapshot testing
E2E testing
Building
Generating static content from build
Pushing built assets to a live deployment

The Basics

npm scripts are stored in the package.json under "scripts". Each key in the "scripts" object corresponds to a script that can execute multiple commands. They allow us to execute system commands, user executables, and executable nodejs command-line scripts.

The following is a simple package.json with a single command that prints "Hello, world!" to the terminal.


{
    "scripts": {
        "echo": "echo \"Hello, world!\""
    }
}

Notice I escaped the quotation marks. This is to avoid operating system differences. Windows handles chunks of text using double quotes, while most Linux distributions can handle them using single quotes.

Running npm run echo in a terminal window should execute the echo command specified then print "Hello, world!" to that terminal window.

Exit Codes

Running processes return a code to the parent process or operating system known as "exit code" or "return code" upon termination. This code generally helps the operating system and other scripts decide what to do.

For example, on POSIX systems a process exit code 0 is a graceful termination. Meanwhile, an exit code between 1 to 255 would mean the process terminated unexpectedly. In case a code is not returned the code of the previous command is used.

Common Chaining Operators

Terminal commands allow us to use several special operators to do more than run a single command. The && (and) operator allows us to execute multiple commands in series provided they all return exit code 0 or nothing at all. The || (or) operator allows us to run multiple commands in series conditionally, running only each command iff the preceding command fails (returns exit code other than 0).

For example, echo \"hello\" && play will execute the echo and if that succeeds will execute the play. If the echo fails then the whole script will terminate and the initiating process will terminate with code other than 0.

On the other hand, invalid_command || echo "\hello"\ will execute the echo iff the invalid_command command fails.

There are tons of operators we can use in our npm scripts but I won’t go through them for the sake of simplicity. I will however use a utility called npm-run-all that will help us make our build system with simpler commands.

Initial Build Scripts

The simplest version of our build system is a collection of commands that execute in series using the && operator. We'll also depend on executing npm scripts through other npm scripts. Let's assume these commands actually work.

{
    "build": "npm run checks && npm run test && npm run transpile && npm run css && npm run generate && npm run deploy",
    "transpile": "babel",
    "css": "postcss",
    "test": "npm run unit && npm run snap && npm run e2e",
    "checks": "npm run lint && npm run typecheck",
    "typecheck": "tsc --noEmit",
    "lint": "eslint",
    "generate": "node scripts/generate.js",
    "deploy": "node scripts/deploy.js",
    "e2e": "cypress",
    "unit": "jest",
    "snap": "jest"
}

In this example, we assume we have a few JS script files in the /scripts directory. Our build script runs all the checks and build steps we need. If any of these commands fails the whole chain fails and the build is terminated.

To execute this build system we would need to either create a script that combines multiple commands npm run checks && npm run test && npm run build && npm run generate && npm run deploy like I did in build or run this whole line by hand every time. Maybe save it as an alias. This is difficult to read and requires a lot of repeatedly nested npm run. We can change that with npm-run-all though!

npm-run-all

{
- "build": "npm run checks && npm run test && npm run transpile && npm run css && npm run generate && npm run deploy",
+ "build": "run-s --print-name checks test transpile css generate deploy",
- "test": "npm run unit && npm run snap && npm run e2e",
+ "test": "run-s --print-name unit snap e2e",
- "checks": "npm run lint && npm run typecheck",
+ "checks": "run-s --print-name lint typecheck",
  "transpile": "babel",
  "css": "postcss",
  "typecheck": "tsc --noEmit",
  "lint": "eslint",
  "generate": "node scripts/generate.js",
  "deploy": "node scripts/deploy.js",
  "e2e": "cypress",
  "unit": "jest",
  "snap": "jest"
  "typecheck": "tsc --noEmit",
  "lint": "eslint",
  "generate": "node scripts/generate.js",
  "deploy": "node scripts/deploy.js",
  "e2e": "cypress",
  "unit": "jest",
  "snap": "jest",
}

In this example, we utilise the helper binary run-s from npm-run-all to execute multiple commands in series without the npm run spam. This is much easier to read and provides more fine-grained control over our scripts. The --print-name flag prints the name of the script before it’s run so we can differentiate the output logs better. Its shorthand is -n.

Parallelised Scripts

run-p is another utility which, as you might have already guessed, executes scripts in parallel. Each script in its own child-process. run-p is useful for development scenarios where you want to run multiple servers with a single command (e.g., local dev database and a nodejs dev server), and can used to
parallelise testing and pre-build checks to improve our build times. So, let’s parallelise our testing scripts!

{
- "test": "run-s -n unit snap e2e",
+ "test": "run-p -n --aggregate-output unit snap e2e",
}

I supplied the --aggregate-output flag to avoid interleaving the output of every parallel command. This delays the printing of each command’s output until it has finished so we can have comprehensible logs.

Pre And Post Scripts

pre- and post- scripts are npm scripts that execute before and after another script with a matching name. They allow us to simplify our commands and give them more semantic meaning. Npm executes these scripts on its own once we execute a command with matching pre- and post- scripts. You can have either or both at the same time, npm won't mind. This example from the npm docs sums it up pretty well:

{
    "scripts": {
        "precompress": "{{ executes BEFORE the `compress` script }}",
        "compress": "{{ run command to compress files }}",
        "postcompress": "{{ executes AFTER `compress` script }}"
    }
}

Applying this to the build scripts we end up with the following:

{
+ "prebuild": "run-s -n checks test",
- "build": "run-s -n checks test transpile css generate deploy",
+ "build": "run-s -n babel & css",
+ "postbuild": "run-s -n generate deploy",
}

We can take this build system one step further and utilise glob-like execution.

npm-run-all glob-like execution

We can use glob-like patterns to specify npm-scripts. The difference is one; the separator is : instead of /. We call scripts with the : separator subcommands. A test:e2e script can be referred to as subcommand e2e of test. npm-run-all can execute all subcommands of a given command through the * glob operator. For example, run-s test:* executes all subcommands of test which may include test:e2e and test:unit.

We’ll use it to structure our commands into a neater flow:

{
- "prebuild": "run-s -n checks test",
+ "prebuild": "run-s -n check:* && run-p -n --aggregate-output test:*",
  "build": "run-s transpile css",
  "postbuild": "run-s -n generate deploy",
- "test": "run-p -n --aggregate-output unit snap e2e",
- "checks": "run-s -n lint typecheck",
- "typecheck": "tsc --noEmit",
  "transpile": "babel",
  "css": "postcss",
+ "check:types": "tsc --noEmit",
- "lint": "eslint",
+ "check:lint": "eslint",
- "e2e": "cypress",
- "unit": "jest",
- "snap": "jest",
+ "test:e2e": "cypress",
+ "test:unit": "jest",
+ "test:snap": "jest",
  "generate": "node scripts/generate.js",
  "deploy": "node scripts/deploy.js",
}

I’ve created a simple, executable set of these scripts that you can run on your system without having to install any dependencies. All these commands do is output their names, but this should be enough to give you a general idea of how a real build system like this will work at runtime. Just make sure to initialize a new project with npm and add these scripts to the package.json.

"scripts": {
    "prebuild": "run-s -n check:* && run-p -n --aggregate-output test:*",
    "build": "run-s transpile css",
    "transpile": "echo transpile",
    "css": "echo css",
    "postbuild": "run-s -n generate deploy",
    "check:types": "echo tsc",
    "check:lint": "echo eslint",
    "test:e2e": "echo e2e",
    "test:unit": "echo unit",
    "test:snap": "echo snap",
    "generate": "echo generate",
    "deploy": "echo deploy"
}

The following is the output on my Windows 10 machine. By default, npm prints each running command before executing it. You can hide these npm logs using the -s or --silent flag to ignore some of the spam that may be output.

λ npm run build

> project@0.1.0 prebuild
> run-s -n -s check:* && run-p -n --aggregate-output -s test:*

> project@0.1.0 check:types C:\Workspace\Projects\project\package.json
> echo tsc

tsc

> project@0.1.0 check:lint C:\Workspace\Projects\project\package.json
> echo eslint

eslint

> project@0.1.0 test:e2e C:\Workspace\Projects\project\package.json
> echo e2e

e2e

> project@0.1.0 test:snap C:\Workspace\Projects\project\package.json
> echo snap

snap

> project@0.1.0 test:unit C:\Workspace\Projects\project\package.json
> echo unit

unit

> project@0.1.0 build
> run-s -n -s transpile css

build

> project@0.1.0 transpile C:\Workspace\Projects\project\package.json
> echo transpile

transpile

> project@0.1.0 css C:\Workspace\Projects\project\package.json
> echo css

css

> project@0.1.0 postbuild
> run-s -n -s generate deploy

> project@0.1.0 generate C:\Workspace\Projects\project\package.json
> echo generate

generate

> project@0.1.0 deploy C:\Workspace\Projects\project\package.json
> echo deploy

deploy

Conclusion

This is just one way of doing things. You can go crazy with this kind of stuff, it’s literally a bunch of terminal commands! But for anything more complicated I resort to (and recommend) task runners, bundlers, and toolsets. They allow a lot more flexibility, options, and plugins, and can integrate much better with tools that don’t have CLIs.

You’ve reached the end! What a journey, amirite? You can find more articles on my personal blog. Thanks for reading!

I Struggled Without a Mentor, These Tips Helped Me Learn to Code

Nabil Tharwat — Sun, 09 May 2021 22:45:06 +0000

Learning to code is not a straight path, these tips helped me get better at it. Hopefully by the end of this article you'd have enough of a foundation to require minimal bounce.

Photo by Mathew Schwartz on Unsplash.

Thanks to my friend Omar Abdelaziz for helping out with this article. It means a lot.

Stick to a single road

You may be tempted to learn every single tool out there, and while it may be possible, is it really worth it? You usually need a single tool and nothing more to get a job done. Learn what you need. Look at the market and stay up to date with its trends. Stick to a roadmap until you need another one.

Watch less, build more

Tutorials are fun and dandy until you stop watching them. They give you a feeling of confidence because you're following and succeeding in that. But is following all you need? Will you use tutorials when you're assigned tasks in a real world scenario?

A serious lot of developers have contacted me about this issue. They follow a lot of tutorials, but fail to even get started on their own. Don't get me wrong, tutorials are good, but too much of anything is bad.

Focus on building projects on your own. If you're going through a tutorial, build the same project on your own after finishing the tutorial. This time though, don't even look at the tutorial.

You need less than you think. (AKA Avoid over-engineering)

Most of the time, you'll most likely think you need a hundred tools to get a job done. This is often a mislead view and is amplified by your lack of knowledge and confidence.

For example, you may be tempted to use the most complicated tools you know, when instead you could build the same thing with much simpler tools. Over-engineering is bad, avoid it.

Build problem solving & debugging skills

Solving problems is the core of computer science and so it's an essential tool to have up your sleeve. It helps you break down complex problems into tiny easy tasks and solve them efficiently bit by bit. Debugging skills help developers pinpoint various types of errors and bugs around an application. They'd make your life much easier. Trust me.

Don't be afraid to make mistakes, and ask questions

Mistakes help us learn, and if you're starting out you'll need to make lots of them. Making mistakes means you're pushing your knowledge boundaries. Pushing your boundaries is a sign of growth. Questions are essential to your growth. Don't be afraid to ask "dumb" questions. They're probably beneficial to you, even if they're "dumb" to more experienced others.

Take notes, blog, and teach others

Writing is essential. Whether you're writing notes for yourself, blogging online for others, or teaching those who seek your help, writing is essential and beneficial. When you're publishing these notes and blog posts you not only help others, but help yourself by deepening your knowledge and receiving feedback.

Avoid FOMO

Fear of missing out (FOMO) is a social anxiety stemming from the belief that others might be having fun while the person experiencing the anxiety is not present. It is characterized by a desire to stay continually connected with what others are doing.

Learn to deal with it, live with it, and control it. Avoid chasing every shiny new tech. Doing so will save you a ton of time and headache. Chances are very few companies are going to adopt this new tech. And if many do, their systems that already use other tools will be too much of a cost to replace just to use this new tech. Have the confidence to choose what to learn.

Don't leave the basics behind

If you've been going through courses/tutorials back-to-back, chances are you've missed a bunch of basics on the way. Go back and learn them thoroughly. You'll thank me later.

Be kind to yourself

We're not born with knowledge. You were not born knowing how to code, and neither were your peers. Building foundations takes time and effort. Don't give up, don't push yourself too much, and enjoy the journey. Burnout is real.

Don't let coding take over other aspects of your life

Coding can be fun and tempting, but sitting all day doing nothing but that is a complete waste of time and energy. Go out, keep in touch with friends, play music, learn to do other things aside from coding. You may as well create content around coding, just don't sink in too deep into coding.

Stop waiting for perfect opportunities

If you've built projects, gone through courses, and prepared yourself for the job, you're probably "ready". Stop waiting for the "perfect opportunity". If you are, you're already missing out. Start going out of your comfort zone. Start applying to companies. Do your best, and show it off. It's a good learning experience as well.

Start interacting with the community

Coding is not a singular act nor a one-man effort. It's a community, and you're part of it, like it or not. You may refrain from contributing to it, but why do that when you can instead contribute back to the community that helped you get started? Start interacting with the community already! Here are ways you can do that:

Follow developers blogging about all sorts of things on DEVCommunity
Stay up to date with everything by visiting HackerNews
Follow industry/community leaders on Twitter
Join developer communities online! Valarium is a discord community I started a couple years back. It's mostly in Arabic but everyone's welcome!
Join Reddit developer communities! They're rich of content and joy!

These tips helped me personally, and I had to bounce around perhaps too much because I didn't know them at the time. Now you don't have to!

Thanks for reading! You can follow me on Twitter, or read more of my content here or on my blog!

What's your biggest struggle with Regular Expressions?

Nabil Tharwat — Wed, 05 May 2021 07:07:37 +0000

There seems to be a shared struggle when it comes to Regular Expressions. Some suffer readability, some think it's completely useless, others find it difficult to learn. What do you think? What are struggles you face with Regular Expressions?

For those with no problems with it, what would you give as advice? What helped you grasp them?

Software Entropy And How To Prevent It

Nabil Tharwat — Tue, 13 Apr 2021 01:01:19 +0000

Software decays. Unlike the general belief that code doesn't just "rot away", which makes sense, but software has its own type of decay, known as "software entropy" or "software rot".

هذه المقالة متوفرة باللغة العربية ⁦🇸🇦⁩

Software Entropy

Software entropy is the process of gradually decreasing the quality of source code until developers can't contribute to it any more. Code becomes obsolete and difficult to maintain, just like anything else.

This happens due to a number of contributing factors mostly related to the psychology and culture of the developers working on the project.

Question remains; how does it decay and how can we prevent it?

Broken Windows

To understand how software rots we need to take a look at the Broken Windows theorem. The Broken Windows theorem is a theorem in crime science which states that crime is the result of disorder found in human societies.

Given a car left on a street for weeks, passers-bys won't care about it. It'll remain as is. Until a window is broken. In the original experiment, they left a car on a street untouched for weeks. But when they broke a window, the car was dismantled in hours.

By the same rule, a broken window in a building left unfixed will be followed with general disorder. Which is why NYC started cracking down on the tiniest things, in order to prevent broken windows.

According to a 2001 study of crime trends in New York City by Kelling and William Sousa, rates of both petty and serious crime fell significantly after the aforementioned policies were implemented. Furthermore, crime continued to decline for the following ten years. Such declines suggested that policies based on the Broken Windows Theory were effective.

— Wikipedia

Broken Windows in Software

Wrong management decisions that developers have to live with, bad designs, or poor code are all examples of broken windows.

Delaying fixing these broken windows to later times will only contribute more to software entropy. We all know that there won't 'another time' or 'later' because you'll be all too busy with new features or critical bugs that will leave even more broken windows.

Failing to fix those windows as soon as possible will leave you in the mentality that "all code is trash, I'll just get this over with". This mentality will greatly accelerate the entropy.

How to Avoid Software Entropy (or Minimize It)

Given all of this, one must simply avoid breaking windows. If you want your codebase to last then you must fix all windows as soon as they're found. Introduce the concept of refactoring to your boss. Temporarily disable features. Label others as "unstable".

Do not leave a broken window in your production code. This will keep the mentality of care and attention to detail among the developers working on the code, and will eventually lead to easier feature addition, maintenance, and testing.

You don’t want to be the first one to make a mess.

— The Pragmatic Programmer

If you liked this article don't forget to love this post! If you found any issues with this article or have questions don't hesitate to comment them! Thanks for reading! You can follow me on Twitter, or read more of my content here or on my personal blog!

Leaking and Non-Leaking Arrow Functions in JavaScript

Nabil Tharwat — Sat, 03 Apr 2021 07:51:20 +0000

When writing arrow functions that shouldn't return any value you may be tempted to return an || operation such as:

/* Leaking Arrow Function */
const arrowThatShouldntReturn = () => someOtherFunction() || undefined;

This may work if someOtherFunction returns a falsy value, but won't work for truthy values.

The Void Operator

The void unary operator evaluates the given expression and then returns undefined. You'll see this operator used all over the React codebase to create non-leaking arrow functions!

To use it we can define our functions as:

/* Non-leaking Arrow Function */
const arrowThatShouldntReturn = () => void someOtherFunction(); // returns undefined

Or when we don't wish to do anything yet:

/* Non-leaking Arrow Function */
const arrowThatShouldntReturn = () => void; // returns undefined

The first method will evaluate someOtherFunction() and return undefined regardless of the returned value. The second method is equivalent to void undefined which evaluates undefined and returns undefined.

Are there other use cases? Yes.

Before ES6

In old times you used to define variables using var. This immediately adds the variable you're declaring to the global object. It also pretty much didn't have restrictions, so you could just var undefined = true and it'd work. This is one of the reasons void 0 used to be the preferred method. There's even an ESLint rule for it! It's not necessary in strict environments though.

HTML

You probably also met the void operator in anchor tags! Ever met this bad boy?

<a href="javascript:void(0)"/>

Yup, that's it. We used it to pretty much create links that preventDefault.

IIFE

You can use it with IIFEs too!

(function() { return true })(); // returns true

void function() { return true }(); // returns undefined

Deep Dive Beyond Operator Overloading in JavaScript

Nabil Tharwat — Fri, 02 Apr 2021 17:59:10 +0000

This is a deep dive into the inner workings of JavaScript engines and how they handle arithmetic operations on primitive and complex objects. We'll go through ordinary and exotic objects, the standard semantics, references, abstract operations, internal methods, and finally how to implement objects that benefit from arithmetic operators.

If you haven't read my previous articles make sure to!

AdditiveExpressions

Before we start, let me note that JavaScript doesn't support operator overloading in the general sense like C++ does for example, but it provides deep workings that allow us to define special methods that are used in arithmetic operations, like Java's toString!

5 + 8;

Let's start with this simple arithmetic addition AdditiveExpression : AdditiveExpression + MultiplicativeExpression. The standard defines the steps for an addition operation:

1.  Let lref be the result of evaluating AdditiveExpression.
2.  Let lval be ? GetValue(lref).
3.  Let rref be the result of evaluating MultiplicativeExpression.
4.  Let rval be ? GetValue(rref).
5.  Let lprim be ? ToPrimitive(lval).
6.  Let rprim be ? ToPrimitive(rval).
7.  If Type(lprim) is String or Type(rprim) is String, then
  a.  Let lstr be ? ToString(lprim).
  b.  Let rstr be ? ToString(rprim).
  c.  Return the string-concatenation of lstr and rstr.
8.  Let lnum be ? ToNumeric(lprim).
9.  Let rnum be ? ToNumeric(rprim).
10.  If Type(lnum) is different from Type(rnum), throw a TypeError exception.
11.  Let T be Type(lnum).
12.  Return T::add(lnum, rnum).

Pretty daunting right? Let's dumb it down!

Semantics

The standard defines any additive operation as the result of two operands, l and r, being left, and right respectively. It also attaches other semantic descriptors like ref, val, prim, str, and num to refer to Reference, Value, Primitive, String, and Numeric values respectively.

JavaScript Engine References

The standard operates using References. References are special objects/variables that reference other variables in memory. This is to save resources so instead of copying a variable every time the engine needs it, it can just reference it, which is more memory and performance efficient. This Reference type can be dereferenced to get the actual value by using the GetValue(V) method.

The GetValue(V) method itself has an algorithm of its own. I've dumbed it down without going too deep as follows:

1. If V is not a reference, return it.
2. If V is invalid reference (as in using a variable that doesn't exist), throw ReferenceError.
3. Else return value.

Exotic and Ordinary Objects

In JavaScript, an exotic object is an object that contains behaviour that goes above and beyond the language itself. These objects require internal methods that are enclosed in double square brackets [[ ]]. Think Array, Proxy, Arguments, and Module for example. The JavaScript engine does a lot of magic using internal methods to work with those objects. You cannot completely replicate this magic using just JavaScript.

Ordinary objects are normal objects that you can build using JavaScript code.

Primitives and Abstract Operations

Primitives in JavaScript are the most basic values that can be represented in the engine directly. This includes booleans, strings, numbers, and others. The standard defines primitive helpers called Abstract Operations. These helper functions allow the engine to directly manipulate values such as add two numbers, subtract, and others. Each primitive type has its own set of helpers.

Now that we have a basic understanding of how things in the EcmaScript world work let's dive into addition.

1.  Let lref be the result of evaluating AdditiveExpression.
2.  Let lval be ? GetValue(lref).
3.  Let rref be the result of evaluating MultiplicativeExpression.
4.  Let rval be ? GetValue(rref).

Up until the forth step all we do is just dereference the references we have. Now we have two values, lval and rval.

5.  Let lprim be ? ToPrimitive(lval).
6.  Let rprim be ? ToPrimitive(rval).

We now turn these values into primitives so we can operate on them easily on the engine level. The abstract operation ToPrimitive converts its input argument to a non-Object type. It has a somewhat long algorithm.

ToPrimitive and @@toPrimitive

ToPrimitive takes two parameters, the value you wish to turn into a primitive, and a Hint PreferredType. This Hint helps ToPrimitive determine the Target type.

When ToPrimitive is called with no hint, then it generally behaves as if the hint were Number. However, objects may over-ride this behaviour by defining a @@toPrimitive method. Of the objects defined in this specification only Date objects (see 20.4.4.45) and Symbol objects (see19.4.3.5) over-ride the default ToPrimitive behaviour. Date objects treat no hint as if the hint were String.

Meaning that if Hint is not present the function falls back to "number" for all objects except Date, which defines Hint as "string". This is one of the reasons Date is an exotic object. Date also defines more internal methods to help with serializing it to JSON.

Ignoring unimportant steps, the ToPrimitive algorithm is:

2. If Type(input) is Object, then
  d.  Let exoticToPrim be ? GetMethod(input, @@toPrimitive).
  e.  If exoticToPrim is not undefined, then
    i.  Let result be ? Call(exoticToPrim, input, « hint »).
    ii.  If Type(result) is not Object, return result.
    iii. Else throw a TypeError exception.
  f.  If hint is "default", set hint to "number".
  g.  Return ? OrdinaryToPrimitive(input, hint).
3.  Return input

The key here is @@toPrimitive at 2.d. Remember what we said about Ordinary and Exotic objects? @@ToPrimitive is an internal method defined only on some exotic objects that control how the object is turned into a primitive. If this method is defined on the object we're working with (Date and Symbol), it'll be called and the result will be returned. Otherwise we'll resort to OrdinaryToPrimitive.

OrdinaryToPrimitive

OrdinaryToPrimtive bears the responsibility of turning ordinary objects into primitives. We're getting close now! It does the following:

3.  If hint is "string", then
  a.  Let methodNames be « "toString", "valueOf" ».
4.  Else,
  a.  Let methodNames be « "valueOf", "toString" ».
5.  For each name in methodNames in List order, do
  a.  Let method be ? Get(O, name).
  b.  If IsCallable(method) is true, then
    i.  Let result be ? Call(method, O).
    ii.  If Type(result) is not Object, return result.
6.  Throw a TypeError exception.

We define a list of method names to call in order. This list can either be [toString, valueOf] if the hint is "string" (as in string concatenation), or [valueOf, toString] if hint is "number" (as in number addition). We then execute this list and return the value of whichever method we find first, in the same order.

We've now called ToPrimitive on both operands and have two primitives to add together. The algorithm for AdditiveExpression continues:

7.  If Type(lprim) is String or Type(rprim) is String, then 
  a.  Let lstr be ? ToString(lprim).
  b.  Let rstr be ? ToString(rprim).
  c.  Return the string-concatenation of lstr and rstr.
8.  Let lnum be ? ToNumeric(lprim).
9.  Let rnum be ? ToNumeric(rprim).
10.  If Type(lnum) is different from Type(rnum), throw a TypeError exception.
11.  Let T be Type(lnum).
12.  Return T::add(lnum, rnum)

We see that if any of the primitives is a string then we convert both of them to strings and concatenate them. Otherwise we convert them to numbers and use the Abstract Operations defined on Number primitives, specifically add(lnum, rnum).

Now we have a pretty good understanding of how addition works! But we're talking about operator overloading! Remember what I said about OrdinaryToPrimitive? OrdinaryToPrimitive looks for toString and valueOf on objects depending on the operation. Which means we can just define them on our custom objects and use arithmetic operators with them!

Operator Overloading Custom Objects

Let's start by defining an object A that doesn't implement these methods:

const A = {
    value: 5,
}

If we try to do arithmetic operations on this object we'll get strings all the time.

A + 5 // [object Object]5
A - 5 // NaN
A * 5 // NaN
A / 5 // NaN

Now let's implement these methods on this object:

const A = {
    value: 5,
    valueOf: function(){
        return this.value;
    },
    toString: function(){
        return String(this.value)
    }
}

Arithmetic operations should now work flawlessly!

A + 5 // 10
A - 5 // 0
A * 5 // 25
A / 5 // 1

So now we can not only just define some methods to use operator overload on our objects, but we also deeply understand how JavaScript engines do it!

How I Get Things Done as a Student-Developer, and How You Can Too

Nabil Tharwat — Mon, 15 Mar 2021 06:28:47 +0000

Being productive as a student and a developer is a hard task. Hopefully by the end of this you'll be a little bit more productive. I'll be sharing my experience with time auditing, goal setting, instant gratification, negative influences, and managing a to-do list.

Don't forget to share your time management habits and how you plan your time in the comments! 👀

What I used to do

What I used to do in the past, which failed miserably, is setting up a strict schedule based on hours, a "from-to" type of schedule. I eventually ran out of time before I could finish the tasks at hand, and would always be frustrated with having to update and maintain it. It was a lot of effort and led to less productivity.

Before you dive into applying any time-management methodology, give yourself time to try it out. There are no silver bullets.

Time auditing

How we spend time is often overlooked. How can you improve your productivity if you don't know how you spend your time in the first place? Research is the foundation. Tracking your habits can give you an idea of what you need to work on and improve, and can guarantee better productivity.

One of the very first steps is to measure exactly how you spend your time. How long transportation takes, studying, being outside, playing video games, scrolling through Instagram, meals, and even breaks.

To track your time-spending habits a simple notebook can do. There are a number of free and premium time-tracking tools out there that all do a great job. Do it for a few days, then check how you spend time and decide how you can improve.

Never categorise what you do as unimportant during the first few days. Add everything to your audit.

Fear as a friend

How many times have you procrastinated but eventually got things done because of fear? Fear of failing a course, fear of ruining a relationship, fear of missing out, etc. There's always something we're afraid of that pushes us to being more productive.

The reason why we're not as productive as we wish to be is because we fail to act; which is the result of one’s complacency in the current moment. One must leverage fear by ensuring that the stakes are too high for one to stay perpetually complacent.

Fear, in itself, is a natural, powerful, and primitive human emotion. It alerts us to the presence of danger or the threat of harm, whether that danger is physical or psychological. If we exploit our fear of the future and use it to our advantage we'll have a solid foundation.

This is what I had in mind, and is what I did. I listed the things that I was most afraid of in the future. Things like finding a job, my social anxiety when meeting new people, etc. I then set goals based on these fears and my dreams. These goals gave me purpose, a way to measure my progress, and had high-enough stakes to keep me on track.

Avoid instant gratification

Instant gratification is the desire to experience pleasure or fulfilment without delay or deferment. Basically, it's when you want it; and you want it now.

Ever woke up and went straight to your phone? Do you check your phone every few minutes at work? Do you keep your phone in sight when sitting with friends or in a meeting? Stop.

Engagement with our cell phones releases dopamine. That's why when you get a text, it feels good. It's why we count the likes. It's highly addictive.

— Simon Sinek

With instant gratification on board, we look beyond what we truly want. We choose not to do the things that help us reach long-term goals — such as job satisfaction or relationships — because they're long-term. They're boring, they take time, and we're impatient. We're reactive. Which is a terrible combination.

This is why we need short-term milestones. Goals can span years, but milestones are short-lived, and grant us enough satisfaction in the present moment that helps us avoid unhealthy addictive behaviour.

If you wait till the end of a season of your favourite TV series just to binge through the whole thing at once, stop doing that. Watch every episode when it comes out, and wait for new episodes. Work on yourself and develop your skills to reach job fulfilment. Insignificant changes add up.

Learn the art of being patient, you'll thank yourself later.

The classic: creating a to-do list

A to-do list will allow you to feel accomplished by showing you the tasks you completed, and a time-audit will tell you how long each task took. This combination will allow incremental, consistent improvement.

Now here are some hacks I use around my own to-do list:

Place the most boring tasks first, the most important second, and the most fun after. This will help you reach that "ah, finally, something fun" after a long day of boring stuff.
Use atomic tasks. Atomic tasks are tasks that take less than a few minutes to complete. For you, they may be shorter, or longer. We can usually keep ourselves focused for 30 minutes tops. Split long tasks into atomic tasks — you'll feel more accomplished.
Order related tasks together. This helps you remain focused.
Don't abandon tasks. If you couldn't finish everything today, don't feel bad! Just move it to the next day.
Get help. More hands on the same tasks means less time.
Avoid train cars. Leave a buffer time between tasks. You may want a bathroom break, a quick snack, etc.
Keep your mind busy with only 1 task. This helps you focus, and eliminates half-work and overthinking.
Less is more The more time you spend on unimportant tasks, the less you spend on the things that truly matter.
Make a food schedule. This will help you overview how much time will be needed to buy ingredients and prepare your daily meals.
Don't go back to completed tasks. Avoid perfectionism. A task done is a task done.
The 15 minute rule. Have 15 minutes of break at least once for every 2 hours of work.

One of the very worst uses of time is to do something very well that need not be done at all.

— Brian Tracy, Eat That Frog

Discipline

Discipline is the difference between the greats and the average. Take more responsibility of yourself. Set a morning routine. Plan ahead, and stick to plans. Hold yourself accountable. And tell no one about it. The only way people should know about your progress is through results. Show discipline. Show results. Never break your discipline.

Discipline is saying "No" when those around you choose to be average. Life doesn't give you what you want, it gives you what you deserve.

— Chris Ross

Choose a suitable routine

My morning routine consists of waking up at 05:00 or earlier, taking a quick shower and meditating. I prepare my breakfast, and enjoy it in the calmness of the early morning — it's really calm then. I then check my to-do list for any left-overs from last night, fix it up and sort my day's tasks, and decide what I want to eat during that day. And with that, my day starts.

It's finally the weekend

The weekend is a whole different matter. No to-do lists, no auditing. Discipline is tiring, remaining focused all the time is tiring. The weekend helps you balance that. Remain faithful to your goals and your discipline, but breaks are necessary to avoid overwork and burnout.

Avoid the cult of productivity.

Don't let your extremely-productive self take control, and don't let your extremely-procrastinating self take control either. Burnout is a thing that you want to avoid at all costs. Accept that it's more terrifying to fail than it is to succeed, and take control of your life.

Final notes

I just want to say that there will always be a challenge. Life will never be a straight line. There will always be a mountain to climb. You'll fall. You'll get bashed in the face with the world's cruellest hammer. And just like you worked hard, you'll fall hard.

I’ve never understood that concept, having something to fall back on. If I’m going to fall, I don’t want to fall back on anything, except my faith. I want to fall… forward. At least that way I’ll see what I’m about to hit.

— Denzel Washington

Thanks for reading! You can follow me on Twitter, or read more of my content here or on my blog!

Protecting Website Copyrighted Content

Nabil Tharwat — Tue, 09 Mar 2021 03:30:22 +0000

Protecting your website's copyrighted content is tricky. Let's see how it's done! 👀

Cover by Jeremy Thomas on Unsplash. This article is available in Arabic on my blog.

Bottom line is no matter how many scripts you load, events you prevent, authentication layers you add, users will always be able to redistribute your content online. Our goal is to reduce the number of users who can achieve this to a percentage we can handle manually.

In this article, I'll be talking about DRM and Forensic Watermarking.

Digital Rights Management (DRM)

DRM tools are a set of access control technologies for restricting the use of proprietary hardware and copyrighted work. The set of tools we'll look at today relate only to the web development side of it.

DRM encryption is the encryption of content such as videos and images to prevent others from using it. This is two-way encryption. Given a key, you can decrypt the contents of said content.

The usual flow is you begin by registering a user, verifying their identity using some payment method, and then granting them access to the encrypted content and the key for that content, thus granting them a license to access that content. The browser then proceeds to decrypt the content on the user's machine to output a valid representation that can be displayed on a webpage.

Currently, the Encrypted Media Extensions API handles that. For it to work you need to have a browser that supports the EME API, a packaging service to encrypt your content, a DRM key generation service, and a Content Decryption Module (CDM) for client-side decryption. The EME API allows you to interact and define CDMs for your application.

This procedure is used by Netflix, Spotify, and others. But there's a twist. Each browser supports a specific DRM service. So you need to make a copy of the original content for each service the browsers that you support can work with.

In general, Widevine is supported by Firefox, Chrome, and Opera, PlayReady is supported by IE/Edge, and FairPlay is supported by Safari.

There's another twist! Once a user has access to your DRM content, they'll be able to redistribute it! Recall that DRM decryption takes place on the user' machine, and so with the proper software they'll be able to output a simple decrypted file to redistribute. This is where Forensic Watermarking comes into the picture!

Forensic Watermarking

Watermarking is the process of adding some information to media. Things like logos, source distributor, etc. But how can something like this benefit us in preventing the redistribution of our content?

Forensic Watermarking is the process of embedding special hidden information about a user in the media itself. Most forensic techniques use footprints left on media to predict the history of the media.

This can be used to detect the user who redistributed a video on the web. Think of it like inspecting a website. You can inspect the media to check the username of the user who redistributed that media, and then decide what to do. This includes legal action.

But there's another twist. Media degrades after operating on it a few times. This can damage the embedded information over time. Users can just record their screen in the case of video, their system's audio output in the case of audio, etc. You won't be able to detect that.

The point of all of this is to reduce the ability of a user to redistribute the content, and this will successfully reduce the percentage of users who have the hardware and software to accomplish this, limiting the number of users to a handful you can manually deal with.

This is more of a forensics thing, and I'm a frontend developer. Hopefully I made it clear enough! If you spot any errors please point it out! 👀

Thanks for reading! You can follow me on Twitter, or read more of my content here or on my blog!

Sources: