Forem: Nikkhiel Seath

Serial and Parallel JS Promises

Nikkhiel Seath — Tue, 28 Jun 2022 00:00:00 +0000

A week ago, I was looking at a bug. Some operations were being performed that resulted in the change of state of the IndexedDB storage.

(I can't share all the details so please, bear with me)

For one of the operations, a piece of data was being calculated again and this should not have been happening as this data was already calculated as a part of another operation and any following operations should have referred to this pre-calculated data.

The way these operations were being performed was not exactly apparent and clear as a list of these operations was basically being passed on to another method which was using some deep-nested logic to execute them.

Turns out that Promise.all was being used to resolve the results from all the operations in the list.

Difference between Serial and Parallel

In my mind, I had formed a general model of the process: Operation 1 is performed and then Operation 2 is performed and so on.
This model where operations happen in a sequence is called Serial and if I am being honest, this is how I usually think that things are done.

Turns out that there is another model: Operation 1 is being performed and simultaneously, Operation 2 is being performed. There is no exact order/relation between the end of Operation 1 and start of Operation 2.
This model is called Parallel and this was one of the reasons behind the bug I was looking into.

What does Promise.all do?

const bakeCake = (): Promise<CakeDetails> => {// something};
const eatCake = (): Promise<EatenCakeDetails> => {// something};


Promise.all([bakeCake(), eatCake()]).then((result) => {
    console.warn('Result', result);
});

In life, you first bake the cake and then eat it.

But, using the above code example you can bake and eat the cake simultaneously (assuming that the eatCake fallbacks to baking a cake in case one doesn't already exists).

What is it good for?

It is basically a way to perform concurrent operations in JS.

It should only be used to perform independent asynchronous operations.

Based on the above statement, the cake example is an incorrect usage of Promise.all and a similar mistake was the reason behind the bug I was looking at.

Is it a way to perform operations parallelly?

No. It is not.
It may look like that the operations are being performed parallelly but, they are not. Instead, the right term for this behavior is Concurrent.

The thing responsible for executing a piece of JS is single-threaded and therefore, only a single operation can occupy it at a time.

And in the case of Promise.all, this thing is actually bouncing between multiple operations by starting an operation, suspending it and then, starting of another one, suspending it, resuming the previous one and so on.
Therefore, we can't call it parallel because, at a give time only single operation is being worked on.

(NB: I am using simplified names to prevent confusion caused by terminology)

Does it have a performance impact?

Is Promise.all faster then waiting for every promise to be resolved before proceeding on to the next one?
I am not so sure. I am yet to find a definitive answer and I shall share my thoughts on the same later.

References

This post is based on what I have learnt after taking care of that bug and reading other articles on the internet.

Symbols in package.json

Nikkhiel Seath — Mon, 06 Jun 2022 20:52:50 +0000

Recently, I came across a dependency error. Basically, a package being used by a
project didn't have the correct version of a dependency listed as a peer.

{
    // package that had the issue
    "peerDependencies": {
        "package-a": "^6.5.7"
    }
}

{
    // project that used the said package
    "dependencies": {
        "package-a": "~6.6.7"
    }
}

In this post I shall try to explain what symbols like ~ ^ and those numbers
mean?

Talking about the numbers first

I intially found it a bit weird that there are two decimals in this version
string. But, now, I know better.
Each of those digits represents a change in the version. Depending upon the
position of the digit that was incremented, the change can be divided into:

Major - A Breaking Change or a New feature
Minor - A change that maintains backwards compatiblity
Patch - A minor bug/error fix

Turns out that there is a whole set of rules defining what these digits are and
under what circumstances should and which digit be incremented. This rule set is
referred to as Semantic Versioning.
So, for a package with version string 8.5.4:

8 => Major Version
5 => Minor Version. Like: 5th revision of version 8
4 => Patch Version. Like: 4th revision of the 5th revision (of version 8)

And now if a typo was fixed then, the digit representing "patch" would be
incremented making the new version string 8.5.(4 + 1) = 8.5.5.

In a proper production level released package, the minimum "major" is 1 and
minor, patch range from 0 to 9. (The first release is usually 1.0.0).

On the other hand, for a package that is released for development purposes,
usually has the "major" as 0 (and possibly no limit on range of major and
minor).

Talking about the symbols

Before I jump on symbols, I shall like to give a brief on what package.json
stores.

What exactly does package.json store?

A package.json file basically lists all the "pieces of code" (aka dependencies)
that the current project (which itself is a piece of code) may be dependent
upon.
Along with this, it stores what version of these "pieces of code" should
actually be used.

This version requirement can be:

strict: Only v1 of package-a
a little less strict: Either v2.3 or v3.1 of package-a
flexible: Anything after v3 of package-a will do fine.

How do symbols help?

Symbols like: ~, ^, <, || basically represents the above requirement in a
compact manner.

< aka less-than
- Corresponds to major, minor, patch
- <4.3.0 means any major or minor or patch update less than 4.3.0
- 4.2.9 or 3.1.7 would work
> aka greater-than
- Corresponds to major, minor, patch
- >4.3.0 means any major or minor or patch update greater than 4.3.0
- 5.1.6 would work but 4.2.9 won't

This is where it gets slightly tricky

The following symbols can allow updates to major, minor or patch depending upon which of them is defined.

~4.3.5 means a totally different thing than ~4
and ^7.8.6 is different from ^7.0.6.

~ aka tilde
- Allows patch update if a minor version is defined or a minor update if no patch version is defined
- For ~4.3.5
- Only patch updates would be allowed
- Greater than or equal to 4.3.5 but, less than 4.4.0
- ~4.3.6 would work but, ~4.4.1 won't work
- For ~4
- Only minor and patch updates would be allowed
- Greater than or equal to 4.0.0 but, less than 5.0.0
- 4.4.2 would work but, 5.0.0 won't work
^ aka carret
- Allows updates less than the left most non-zero digit
- If major is zero and minor is a non-zero number then, only patch updates would be allowed
- If major is non zero and minor is zero then both minor and patch updates would be allowed
- For ^0.3.5
- Greater than or equal to 0.3.5 but, less than 0.4.0
- 0.3.6 or 0.3.9 would work but, 0.4.x won't work
- For ^4.0.5
- Greater than or equal to 4.0.5 but, less than 5.0.0
- 4.1.5 would work but, 5.x.y won't work

Wrapping Up

This post obviously doesn't contain explanation for all the combantions possible
with all the relevant symbols. Instead, it is just an attempt to better explain
the concepts that confused me.

In a later post, I shall be sharing some actual examples using
node-semver, which is the tool that npm
uses to parse these Semantic Versioning Complaint dependencies version.

Managing vim plugins using pathogen

Nikkhiel Seath — Sun, 10 Apr 2022 11:32:06 +0000

I have been using pathogen as a plugin manager for my neovim.
It is a very simple tool that requires no special commands to install a plugin.
Just clone the plugin repository to a specified folder (bundle by default) and pathogen will add the plugin to the runtime-path(*) on next restart.

It works fine but, the thing is, what if you end up migrating your system or for some reason, you had to recover your vim config. There is no way to keep a record of the plugins you had installed previously.
Zum Beispiel:

vim-plug stores the plugins installed in the vimrc between call plug#begin() and call plug#end().

I wanted something quick and similar to vim-plug's solution.
So, I wrote a mini bash script.

It is just a combination of a PLUGINS[] meant to hold the url(s) for all the plugins used and a for-loop that clones them to the bundle directory.

Here is the code

plugins.sh

#!/bin/bash
# I STORE THE plugins LIST IN A SEPARATE shell file
export plugins=(
"https://github.com/flazz/vim-colorschemes.git colorschemes"
# ...OtherPlugins
)

plug_install.sh

#!/bin/bash

# THE FILE THAT CONTAINS THE plugins LIST
source plugins.sh

cd ./bundle
for plugin in "${plugins[@]}"; do
    git clone -q $plugin
done

Sure, there may be some more sophisticated tools for the same out-there but, till now, this script works for me.

Caveats

Yes, there are some caveats like:

There is no check if a plugin already exists and this may be a problem for people who install new plugins frequently.

(NB: I may update the script to address these caveats)

Custom Cloned Directory Name?

Yes, you can still specify a custom-directory name for the plugin so that it is registered under the runtime-path appropriately. And all you need to do is add the directory name after the git url.

"https://SOME_GIT_URL.git CUSTOM_DIRECTORY_NAME"

For example in the above image, I have specified colorschemes as the custom-directory-name and hence, git will clone the vim-colorschemes plugin to colorschemes directory and not vim-colorschemes directory.

Using it

(I have presumed that you are using the same file/variable names as my dotfiles)

Add the new plugin's git repository url to plugins list specified in plugins.sh
Run the plug_install.sh
Start your vim instance and run :CheckHealth to see if the installed plugin is setup correctly

You can see this setup in action in my dotfiles repository.

NB: Let me know if you have any questions. :)

optimus-manager on arch linux

Nikkhiel Seath — Mon, 04 Apr 2022 16:45:42 +0000

In this post I am sharing how to use optimus-manager to shift between Integrated and NVIDIA GPU on Arch Linux with i3 as the tiling windows manager and no display manager.
(That is you start your Xserver using the startx command).

The official documentation just mentions that prime-offload and prime-switch need to be run at start and end of the Xserver (respectively) but, it fails to mention to how to do this setup.

Without wasting any further time, lets get started.

Steps

Open up your .xinitrc located under $HOME or ~. If it doesn't exist then, create one.

Look at the following code-block:

# MENTION HERE COMMAND THAT IS RUN AT THE START OF XServer
# and before starting up `i3` (#a)

nitrogen --restore &
picom &
i3

# MENTION HERE COMMAND THAT IS RUN AT THE END OF XServer
# and after exiting `i3` (#b)

Place the command to run prime-offload at #a:

if [[ -f /usr/bin/prime-offload ]]; then
    /usr/bin/prime-offload
fi

nitrogen --restore &
picom &
i3

Place the command to run prime-switch at #b:

nitrogen --restore &
picom &
i3

if [[ -f /usr/bin/prime-switch ]]; then
    sudo /usr/bin/prime-switch
fi

Verify

Your final .xinitrc should be like this:

if [[ -f /usr/bin/prime-offload ]]; then
    /usr/bin/prime-offload
fi

nitrogen --restore &
picom &
i3

if [[ -f /usr/bin/prime-switch ]]; then
    sudo /usr/bin/prime-switch
fi

Basically, we are checking if prime-offload exists then, run it at the start of XServer. Technically, not exactly at start but, before we run our compositor and i3 instance.
And then, we are checking if prime-switch exists then, run it after the i3 instance has ended.

You can read more about .xinitrc here

Setting up project-level gitconfig

Nikkhiel Seath — Sun, 03 Apr 2022 08:57:09 +0000

Last week, I completely shifted my system to Arch Linux and during this process, I lost some config(s), settings, etc.

git config was one of them. I used to have a separate config like username, email, ssh key to use based on which project I was working on.
For example, my work projects require a different set of credentials (username, email, ssh-key) than the credentials I use on my personal projects.

I have done this before too but, after a while, I just tend to forget how to do it. This time, I am writing it in a post so that I can refer to it when required.

Steps

Go to the directory where you store the projects and create a .project.gitconfig with the desired credentials:

[user]
    name = work-username
    email = username@work-domain.com

Edit the user level .gitconfig present under $HOME/.gitconfig to include the following condition:

[includeIf "gitdir:ABSOLUTE_PROJECT_DIRECTORY_PATH"]
    path = "ABSOLUTE_PROJECT_DIRECTORY_PATH/.project.gitconfig"

Basically, we are telling git:

"If you find a .git directory nested under this path then, use these set of credentials."

Verify

Now, go to a project inside the work/project-root directory and verify that the correct credentials is being used:

git config --list | grep -P "user|email"

Note (or Gotcha)

Keep in mind that this config will only be used by git if it finds .git directory at that path or a parent .git directory.
For example:

work/
|- .work.gitconfig
|- project-a/
   |- .git/
|- project-b/
   |- .git/

Now, my .work.gitconfig will be used when I am inside project-a or project-b but, not inside work.

One doesn't simply exit VIM

Nikkhiel Seath — Tue, 01 Jun 2021 15:27:19 +0000

Around four years ago, I introduced myself to VIM. I had joined a Discord Community composed of Sophisticated Developers, Linux Users. And among these were VIM users. They had a certain vibe to them that made me desire their company. That is how my journey to a better path began.

No, this path was not better because it involved VIM. It was better as it made me acquire an attitude that most never aim for but should.

The attitude was to KEEP EXPLORING FOREVER.

My journey began with writing that first letter on VIM after learning how to enter Insert Mode and then exiting the same to navigate the document.
VIM showed me the beauty that simplicity could hold and the complexity that minimalism could contain.
It enabled me to explore solutions for even the most basic features that other text editors contain.

During this journey that began from VIM and shall continue forever, I encountered a MEME similar to this one

And it made me realise the great significance VIM holds for me. It enabled me to keep learning and exploring to find solutions and inspired me to apply the same to other aspects of my life.

I shall now like to end this brief to encourage the reader to always seek learning in every endeavour that you undertake. Yes, you will fail and fall but, soon, you will learn how to pick yourself up.