Posts on Abhijit Hota

Vanity import paths in Go using Caddy

Wed, 12 Jun 2024 14:41:53 +0000

I recently published a small Go tool and wanted to publish it on my own domain like go.abhijithota.com/modfmt (instead of github.com/abhijit-hota/modfmt) leveraging “vanity” import paths. Since I already had a small VPS running Caddy, I thought it would be neat to make it work for this.

Vanity import paths

When you download a module via go get or go install, if the import URL is not a known VCS provider, it requests the URL over HTTPS/HTTP and expects an HTML response with a specific meta tag in the head which looks like:

<meta name="go-import" content="<import-prefix> <vcs> <repo-root>">

So for a package called go.abhijithota.com/modfmt whose source code is hosted at a GitHub repo (https://github.com/abhijit-hota/modfmt), the meta tag would be:

<meta name="go-import" content="go.abhijithota.com/modfmt git https://github.com/abhijit-hota/modfmt">

Using Caddy to make the vanity URL work

The bare minimum thing you need to do is handle a specific path on your domain or subdomain to respond with the relevant HTML with the meta tag. Your Caddyfile would look something like this:

go.abhijithota.com {
    header Content-Type text/html

    handle /modfmt {
        respond <<HTML
        <!DOCTYPE html>
        <html>
            <head>
                <meta name="go-import" content="go.abhijithota.com/modfmt git https://github.com/abhijit-hota/modfmt">
            </head>
        </html>
        HTML 200
    }

    handle {
        redir https://abhijithota.com # or wherever you want to
    }
}

This gives you a working vanity URL which you can use to install and get modules from.

Distinguishing requests from Go

Go appends a ?go-get=1 query parameter to the HTTPS request so that we can distinguish between normal queries and queries from the Go tools (go get, etc.). We can use this to distinguish between what to do when someone visits the URL via a browser, etc. For instance, we can choose to redirect to our original GitHub page:

go.abhijithota.com {

    # For path /modfmt
    handle /modfmt {
        # Check if the request has a ?go-get=1 appended by Go
        @from_go query go-get=1

        # If yes, then send back the required HTML
        handle @from_go {
            header Content-Type text/html

            respond <<HTML
            <!DOCTYPE html>
            <html>
                <head>
                    <meta name="go-import" content="go.abhijithota.com/modfmt git https://github.com/abhijit-hota/modfmt">
                </head>
            </html>
            HTML 200
        }

        # If not, then redirect to our GitHub repo
        handle {
            redir https://github.com/abhijit-hota/modfmt # You can also redirect to the pkg.go.dev page for the module
        }
    }

    handle {
        redir https://abhijithota.com
    }
}

The order of Caddy’s handle directives act like a fallthrough. If the first one is not matched then the next one is checked and so on. In the above case, we check the request for a ?go-get=1 query parameter using a named matcher. If the match is successful then we send the HTML required. If it isn’t, then the next in chain is used. Here, we have a handle which basically matches everything. In our case, we redirect to GitHub

We should also probably not leave the HTML page blank. The easiest thing to do here is use a http-equiv="refresh" to redirect to your GitHub repo:

<!DOCTYPE html>
<html>
    <head>
        <meta name="go-import" content="go.abhijithota.com/modfmt git https://github.com/abhijit-hota/modfmt">
        <meta http-equiv="refresh" content="0; url=https://github.com/abhijit-hota/modfmt" />
    </head>
</html>

Go to https://go.abhijithota.com/modfmt?go-get=1 to see the redirect in action.

If you don’t want to redirect, you can write some basic HTML and CSS with the repo and docs URL and the installation instructions. At that point you might want to serve an HTML file directly.

Generalizing our setup

We don’t want to repeat the handle /modfmt block every time we want to publish a package. We can leverage Caddy’s snippets and import directive to repeat the same pattern for a number of packages.

(gomodhandler) {
	handle /{args[0]} {
        @from_go query go-get=1

		handle @from_go {
			header Content-Type text/html
			respond <<HTML
			<!DOCTYPE html>
			<html>
			    <head>
			        <meta name="go-import" content="go.abhijithota.com/{args[0]} git https://github.com/abhijit-hota/{args[0]}">
			        <meta http-equiv="refresh" content="0; url=https://github.com/abhijit-hota/{args[0]}" />
                </head>
			</html>
			HTML 200
		}

		handle {
			redir https://github.com/abhijit-hota/{args[0]}
		}
	}
}

go.abhijithota.com {
	import gomodhandler modfmt
	import gomodhandler foo

	handle {
		redir https://abhijithota.com
	}
}

The above Caddyfile introduces a snippet called gomodhandler which is basically the same /modfmt handler as we saw before but replaced with arguments. Think about it as a way to template the configuration from the configuration itself. When you import a snippet, that snippet gets inlined with the given arguments.

For comparison, here is the same configuration without snippets:

Caddyfile

go.abhijithota.com {
	handle /modfmt {
        @from_go query go-get=1

		handle @from_go {
			header Content-Type text/html
			respond <<HTML
			<!DOCTYPE html>
			<html>
			    <head>
			        <meta name="go-import" content="go.abhijithota.com/modfmt git https://github.com/abhijit-hota/modfmt">
			        <meta http-equiv="refresh" content="0; url=https://github.com/abhijit-hota/modfmt" />
                </head>
			</html>
			HTML 200
		}

		handle {
			redir https://github.com/abhijit-hota/modfmt
		}
	}

	handle /foo {
        @from_go query go-get=1

		handle @from_go {
			header Content-Type text/html
			respond <<HTML
			<!DOCTYPE html>
			<html>
			    <head>
			        <meta name="go-import" content="go.abhijithota.com/foo git https://github.com/abhijit-hota/foo">
			        <meta http-equiv="refresh" content="0; url=https://github.com/abhijit-hota/foo" />
                </head>
			</html>
			HTML 200
		}

		handle {
			redir https://github.com/abhijit-hota/foo
		}
	}

	handle {
		redir https://abhijithota.com
	}
}

This setup will have the following behavior for modfmt and foo:

Installing the module go.abhijithota.com/<pkg> via go get or go install will install the module from the GitHub repo.
Visiting go.abhijithota.com/<pkg> will redirect to the respective GitHub repo.
Visiting go.abhijithota.com/<pkg>?go-get=1 will return the HTML with the meta tag and redirect to the respective GitHub repo due to the http-equiv="refresh" tag.
Visiting any path on go.abhijithota.com other than modfmt or foo will redirect to abhijithota.com.

We are all set now to release our Go modules on our own domains or subdomains with vanity URLs.

Acknowledgement

This post was inspired by Márk Sági-Kazár’s post on vanity import paths in Go which talks about their use-cases, using them effectively, best practices and much more in detail.

Method Middlewares with JavaScript Proxies

Fri, 17 May 2024 17:45:52 +0530

You have an object that is a collection of methods:

const myFunctions = {
    constant: (x) => 1,
    linear: (x) => x,
    sine: (x) => Math.sin(Math.PI * x),
    cos: (x) => Math.cos(Math.PI * x),
};

And you want to do the same operation based on the result of the methods:

const scaleToRange = (y, [yi, yf]) => y * (yf - yi) + yi;

const y = myFunctions.sine(x);
const yScaled = scaleToRange(y, [Y_MIN, Y_MAX]);

No problem at all. 100/100 code. No notes. Commit. Push. Rejoice your life.

But you slowly realize that you don’t want to see the unnecessary yScaled declaration because it is not relevant to your function flow¹. For whatever elitist reason that will make you feel like a better developer, you think that it’d better if you could just abstract this scaleToRange function into the object itself.

// Your dream code which is objectively worse
const y = myFunctions.sine(x, [Y_MIN, Y_MAX]);

You realize what you want is a middleware to your method calls. So you resort to the obvious JavaScript abuse that you love doing so much:

const myFunctions = Object.fromEntries(
	Object.entries({
		constant: (x) => 1,
		linear: (x) => x,
		sine: (x) => Math.sin(Math.PI * x),
		cos: (x) => Math.cos(Math.PI * x),
	}).map(([key, fn]) => [key, (x, [yi, yf]) => (yf - yi) * fn(x) + yi])
);

Now there’s another problem. “3 iterations to declare the object?”, you scoff. Being a JavaScript developer, performance is of utmost priority to you. A dormant section in your brain lights up immediately. “Proxies!”, you exclaim, “aren’t they supposed to do something like this?”. A proxy technically is a middleware after all.

You instinctively open your Bible and lookup for the documentation on JavaScript proxies, simultaneously fighting your sane sub-conscious thoughts, that are fragments of an article long forgotten about how you probably don’t need proxies.

After a few minutes, you come up with this:

const myFunctions = new Proxy(
	{
		constant: () => 1,
		linear: (x) => x,
		sine: (x) => Math.sin(Math.PI * x),
		cos: (x) => Math.cos(Math.PI * x),
	},
	{
		get: (target, key) => {
			const fn = target[key];

			return (x, [yi, yf]) => {
				const y = fn(x);
				return (yf - yi) * y + yi;
			};
		},
	},
);

Explanation

A Proxy in JavaScript is used to intercept and redefine fundamental operations of an object that it wraps. It has two parameters. A target - which is your original object you want to proxy stuff to and from. And a handler - which is an object that contains how you proxy the target object. It returns the modified object.

In the above code, we are creating a Proxy object for the myFunctions object. The handler object has a get method which is called whenever a property is accessed on the myFunctions object. The get method receives the target object and the key of the property that is being accessed. That enables us to intercept the property access and manipulate it before returning it.

You hear Jerusalem bells ringing. The Roman cavalry choirs are singing. A portal opens up next to you. Brendan Eich steps out and hands you a medal. You have done it. You commit your code and go to sleep. This high will help you fight your imposter syndrome for the next 3 days.

This post has become annoyingly self-aware.

I realize that the given example flows pretty nicely. But in my actual use-case it felt out of place. ↩︎

my 2024 fumble list

Fri, 29 Dec 2023 14:48:55 +0530

resolutions 2024

i don’t write down resolutions every year. they are mostly just a background thought in my mind like “i should read more next year” or “i should release my projects next year”. this year i’m writing them down cause why not.

most of these are increasing the things i enjoyed doing in 2023. some of these are stuff that can never happen (completing side projects) and some of these are totally new stuff that i want to try!

here we go. no priority intended.

consumption

reading

read anything properly everyday

a good article, a short story, an essay, a poem, a chapter. anything. i’ve noticed i’m not good with books but i go through articles and short stories often. planning to add some more habit and structure to it.
books

i miss how i used to read books. now i have a love hate relationship with them. i know i can’t hit these goals. but here we go.
- at least one book every 2 months ((re)starting slow!)
- try to complete books you thought to complete first

movies

i love movies. my movie watching habit came back in 2023. no goals other than just watch a lot of them. maybe a target of 150 is good. 100 is too easy (2 movies a week) and 200 is a little too hard (4 a week). so 3 movies a week it is.

i wouldn’t mind if i don’t hit this target though as long as i’m content with the variety of movies i watch. happy ones, sad ones, funny ones, tragic ones, artsy ones, silly ones, old ones, new ones, good ones, bad ones, everything. except horror. it would be a cold day in hell when i start watching horror.

games

i played a couple of games this year that i really liked. hoping to continue the trend. mainly will focus on first person puzzles (portal’s my favourite game!), platformers, roguelikes and anything which i find fun.

i also know what you’re thinking. “i’m sure you have games that you didn’t complete”. i do. i have enough things that make me worried about completing them. games are not those (yet).

creation

writing

even if i read 0 words next year, i should have written to my heart’s content. movie and game reviews, posts like this, articles on what i am working on. just. type words on screen.

software/coding

well. of course. it wouldn’t be a software developer’s resolution list unless it had this. want to complete a few projects next year. but more than that i want to pick up a few new things:

i learnt gamedev a few months ago (!) and after completing all the 2d chapters of Chris Bradfield’s godot book, i couldn’t get the time (skill issue) to get more into it. thinking to change that next year. if you want to see my newfound gamedev skills, check out space rocks, one of the games from the book. i made a few changes and made it run on web (mostly). pretty fun.
more creative coding! it’s a rite of passage to get into shaders after a few hours of game dev. that’s what i did. realised i’m not very good at it. but i still want to make some pretty stuff dance on screen. mathematical simulations are on top of that. maybe i’ll binge watch and code along the entire coding train catalogue. reminds me of my codepen days.

photos

i love clicking photos. i should take more photos and more than that, properly share it even if i personally find most of them mid.

misc

travel

travelled a good amount in 2023. want to do more of it in 2023 – both solo and with closed ones.

people who know me would be surprised by this. i do a lot of things but don’t really share them. but i should. i feel like sharing more is the more general term for shipping more. share the things you write, share the movies you like, share your thoughts, share the things you make, share the photos you take.

i suck at all these. maybe this post could be a start to fixing it.

thanks for reading and watch me fumble all of these in 2024.

In my midwit phase

Wed, 27 Dec 2023 16:46:28 +0530

Everyone has seen this or a variation of the midwit meme.

If you think the meme describes 3 different types of people, you’re both right and wrong because:

every midwit meme describes a journey, not a classification.

— sunil pai, etc. (@threepointone)

Lately at work I’ve been working on a pretty interesting thing which has me reaching for certain tools and techniques that I’ve thought to be overkill in the past. Being all day on Hacker News and reading a bunch of elitist comments parading about tech minimalism and ownership can only do so much.

The thing is, I’m beginning to realise performance isn’t really difficult in modern applications if you choose the right tools – be it programming languages or libraries you use. If you’re thoughtful, even the bare minimum amount, you’ll get enough juice out of your system.

What’s difficult is to scale performance in presence of constraints.

And coming to my previous point, I used to believe all these shiny technologies are overkill. Turns out I’ve never worked with actual constraints for actual scale. Hence, the midwit meme. I feel I’m entering that phase. Containers, microservices, Kubernetes and serverless all make sense to some extent now because I see some need for them. I’ve become mid. Enjoyer of technologies.

Now I might be doing disservice to these technologies by putting them into a category in which only us midwits believe in. But I only do so because, as cool as it all is, it sure should be simpler. It sure should be easier. And I believe realising how to do that would mean going further right in the chart.

What comes then, I don’t know. I’m not in a rush to find out.

Containerisation for DevOps

Mon, 11 Sep 2023 18:00:00 +0530

Background

In October 2022, A certain company reached out to me to write an article about DevOps and containerization. I never got to complete it in time and when I did, they didn’t respond.

I did a good amount of research for this article, provided I did not know much about the space. Now that I work for a DevOps shop, I thought it was only fair to publish this article.

I don’t think the writing is the best but it’s better to publish it than to let it rot in my drafts.

You can directly skip to the section about software development lifecycle if you’re already aware of DevOps. Despite, I think the immediate next sections act as a good primer.

DevOps

Despite being the simple amalgamation of the words, development and operations, DevOps as a concept is inherently misunderstood. It isn’t a word well defined in literature. Although the common consensus however is that it’s ideally about a culture in your team which maximises ease and quality of releases and development-to-deployment speeds leveraging collaboration, tooling and other methodologies.

According to GitLab, DevOps is

people working together to conceive, build and deliver secure software at top speed. [it] enables software developers (devs) and operations (ops) teams to accelerate delivery through automation, collaboration, fast feedback, and iterative improvement.

DevOps itself is never concerned with the actual application business logic. Like a management methodology, it is about making development and operations team more integrated, making the software supply more efficient in the process.

Characteristics of devops

The meanings and henceforth the rules of DevOps change org to org but there are certain properties that must be aligned in the DevOps movement:

Collaboration and Shared Responsibility

From Rouan Wilsenach’s article about DevOps culture,

It’s easy for a development team to become disinterested in the operation and maintenance of a system if it is handed over to another team to look after.
Workflow Automation/Tooling

From The Tao of Hashicorp,

focus on the end goal and workflow, rather than the underlying technologies. […] As technologies evolve and better tooling emerges, the ideal workflow is just updated to leverage those technologies. Technologies change, end goals stay the same.
Feedback and Communication

From O’Reilly’s approach to building a DevOps culture

A team taking a more DevOps approach talks about the product throughout its lifecycle, discussing requirements, features, schedules, resources, and whatever else might come up. The focus is on the product, not building fiefdoms and amassing political power. Production and build metrics are available to everyone and prominently displayed.

What is Containerization?

Containerization, in simplest of terms, means isolation. It is one way of doing OS-level virtualization, which basically means running a program, be it a simple application or a whole another OS, on top of your current OS.

A lot of containerization software exist in the industry today. However the one that completely turned the landscape by providing a easier UI is Docker. For the rest of the article, when we say containers, we mean Docker containers.

The problems faced in DevOps

Development of almost all software can be boiled down to the 7 steps: plan, build, test, package, secure, release, deploy and monitor. This is called the software development lifecycle. A DevOps driven team would need to care about the efficiency of all these steps and sure enough, teams face issues in all of the steps. We’re going to see what are some of the common problems faced in some of these steps.

Plan

Planning involves gathering requirements, laying the roadmap, prioritising and making sure everyone is on board with what’s on the whiteboard. These are not exhaustive and still difficult.

Sometimes, a designer might want to see how feasible is an element, or a PM wants to see what a certain feature will be used like.
Build

Only writing code (not programming) is probably the easiest part of the cycle. The difficult thing is setting things up, choosing the tooling, checking for cross-platform issues, etc. The problem increases during onboarding of a new hire in your team and you have to help them setup their systems with all the tools and technologies that you use.
Test

Building quality into software is incredibly mandatory for anything remotely serious. Integration or even unit testing can help check for errors well before deployments, in the developers’ local machines itself. How do you ensure your tests cover most of the cases, inputs or scenarios without a lot of friction in setting them up or risking your own system?
Package

This is the stage where you basically “build” your application, service or library for production usage by your end-users. You would build a web application, compile a service binary or something similar. This brings with it problems like; Where to build? What tools to build with? How to check if the builds are consistent?
Secure

After we have built our website, executable or something else, how to verify if it is not tampered with? How to check if a build is actually what we want?

We also want to check if the applications do not cause any harm to the underlying system running it.
Releases & Rollbacks

This is where the consistency of the build comes into play, especially if you have a distributed system. Rollbacks are also crucial when things go wrong. But they can be hard to implement correctly and sometimes lead to longer downtimes.

Why Containerization?

The problems described above demand a few things in common. Faster development, immutability of builds and security via isolation. With containerisation, all of these are addressed to in one way or the other.

Reproducible environments

Docker follows a declarative text-file based approach for creating images via its configuration file called the Dockerfile. It is a one-stop shop for all your configurations and versions of tools. You can manage this

What is declarative? Instead of writing code that says “Start this app on port 8080”, you say “port = 8080” and start the container.

This feature of containers makes them absolutely easy for abstracting and composing different environments. Want a staging environment? No problem. Change some variables and spin up another container without worrying about what will happen to the production environment.

Versatile builds

In the previous section, we saw the problems that come with packaging and security. Docker images are meant to be read-only and immutable. This works greatly for security as we don’t want our build to be tampered with. After an release image/container is built, it is pushed to a registry like GitHub Container Registry or Docker Hub.

Creating a Docker image or container also means that you don’t have to worry about configuration drift or dependency mismatch. Everything that is needed for a particular application will be bundled into the image, thereby giving consistent builds. Not to mention, since the Dockerfile it’s basically just code, can be version controlled via an SCM like Git.

The benefit of images not only comes when releasing but also when rolling back inevitable bugs that get into the application. If your image releases are versioned, which they are in most cases, all you have to do to is pull up a previous version from your registry, spin it up and take the current one down.

Consistent development tools

You can ship not only your entire production application wherever and however you want to, but also speed up development with including tools inside your containers. New developer joining your team? New container for them.

Tools like VSCode Dev Containers make this process super easy. You can have project wise development containers and all a new developer has to do is pull and start the container.

Testing via Isolation

We discussed the importance of testing and its problems. How do we properly ensure that tests are made against as rigorous scenarios as possible without harming our development or CI system? Run them inside containers!

Technologies like ory/dockertest provide a first-class experience in spinning up entire databases inside containers and testing your code in them!

Security via Isolation

As we discussed in the earlier paragraphs, when we use containers, we package and ship applications with their dependencies, rather than having to rely on the underlying operating system. This significantly reduces the risk of vulnerabilities in the application. This also protects against the dependencies installed in the OS being exploited.

With proper auditing, at least a smoke-test verification of all the dependencies that goes to our containers, we can protect our apps against a lot of threats.

Another thing to note is that each container runs in its own isolated environment. This isolation prevents containers from interacting with each other, which reduces the chances of security breaches or accidental leaks. You can start a billion containers and be sure that if one fails, others will remain intact, or at worst, fail because of different reasons.

Resource conscious

Containers are much lighter than their heavy virtualization counter-parts - virtual machines.

In traditional virtualization, something called hypervisors emulate hardware to run Virtual Machines. Containerization on the other hand is about just running another process on top of your base OS using various kernel mechanisms like chroot, namespaces and cgroups.

The benefit that comes with ditching the hypervisor can be seen in real life examples. For example, Google starts around 2 billion containers per week! And that was in 2014. That gives us an idea about how lightweight they actually are.

Containers also allow us to limit the resource usage like memory or CPU with easy configurations.

Enables Collaboration

A last point that might be a bit stretched but can definitely become a reality is containers can be run by anyone. The designer in your team doesn’t have to learn about npm or Webpack to look at the application. They just need to install Docker on their machine, download the code, and start the container.

Albeit not a better solution over staging environments or tunnels, teams actually use this sometimes!

Conclusion

Containerization is often cited as one of the key technologies that enables DevOps culture. They allow for much more rapid and consistent deployment of applications, and they make it much easier to manage dependencies and isolate applications from each other. This makes it possible to deploy applications much more frequently, and to do so with much less risk.

When we go back to the characteristics of DevOps and see how containers solve the problems posed in the software development lifecycle, we can see it all coming together.

Containerization make workflow automation better by making the CI more efficient with isolated testing. They make packaging and releasing a breeze with images and containers. They enable iterative development and quick feedback by making it easy for anyone to reproduce environments suited to the scenarios being tested.

In the end, it’s safe to say that containerization is a capable catalyst for incorporating DevOps methodologies in the team. It is no silver bullet but they make complex application deployments quick and reliable.

Poor man's CI/CD with GitHub Webhooks

Wed, 05 Oct 2022 10:32:17 +0530

Background

In my 5th semester of college (mid 2021), I was in-charge of the Web Operations team at E-Cell IITM. Our responsibility was to make web applications for events, workshops and competitions. The tech stack was primarily Node.js with Express, React and MongoDB for the database. If you’re a full-stack developer, you might know this as the MERN stack.

The environment was fast-paced. We were building a lot of things and breaking more of them in the process. It was like a startup. The highest number of users for an application was only 6.5k. And that’s the reason we could experiment a lot of stuff. Following best practices was something we tried a lot to inculcate by adding tools like linters, formatters, pre-commit hooks, etc. but again, we were all freshers; making and breaking things and somewhere down the line we would just push something with just a commit message of fix stuff.

We have an in-premise server in the institute cluster for hosting the MERN applications. It is just an Ubuntu box with pm2 installed for running Node.js apps. A lot of our time was spent in deploying very, very minor changes. Fix-a-typo-in-a-static-page-level minor. The process was generally this:

Connect to institute’s VPN if you’re not in Insti’s network
SSH into the server
git pull
npm run build if it’s a React application
pm2 restart frontend-server

Easy and simple. Manual and boring. Perfect characteristics of something that needs to be automated. Automation is the mother of invention when it comes to software development and so I went looking for answers.

Self-hosted GitHub Actions

The first and the most obvious solution was to use GitHub Actions. I’ve never used them before and was pretty excited to learn and use it. My excitement was soon doubled when I got to know that you can self-host them. I was able to learn it and setup it for our backend Node.js monolith in a day. But something felt off.

It required installing a lot of stuff to a rather humble machine. It also demanded a lot of memory relative to what our applications were using. To give you an idea, our main backend service uses 105 MB at maximum whereas the runner used around 1 GB in average.
The action was such that it checked out the whole repository every time. The repository was, in a way, large.¹
All our applications stayed in the home directory ($HOME). I could not figure out how to checkout the repository in the same place where it was and got around it by adding post-job scripts.
We weren’t looking at a lot of scale so this level of sophistication felt overkill.

All we wanted to do was to run a few scripts on a git push. Surely, there was a minimal way of doing this?

The hack which seemed like the solution

Webhooks are an elegant way to communicate from server to client. They are one of the simpler ways to implement event-driven architecture. Think of webhooks as a third-party server sending an HTTP POST request to your own server. This doesn’t require you to keep asking that server for data or keep an open connection. GitHub offers Webhooks for a lot of repository and organisation level events.

Here’s how they work:

You provide a URL and a secret to GitHub. GitHub stores the hash of that secret.
You choose the events you want a webhook for.
Whenever that event happens, GitHub sends a JSON or XML payload via a HTTP POST request to the URL you provided in step 1. It also sends the signature which is derived from the secret you provided.
In your server, you check the signature with your original signature. If it’s correct, you handle the payload however you want to.

The payload being talked about contains a lot of information related to the event.

And there was it. A simple HTTP POST containing relevant data. The idea was to commit and push with a commit message starting with deploy. The commit message, committer, files changed, etc. would be included in the payload for the push event. And here’s how it panned out in our case:

Provide a URL like https://ecell.iitm.ac.in/api/gh-webhook
Choose to send the webhook only on push events.
When we receive a webhook, check if the commit message starts with deploy, the committer is one of the admins and some code is changed.
Run a simple script:
```
git pull
npm run build
pm2 restart
```

Step by step instructions

Let’s try to replicate this with an example repository and localhost as the server. Find the repository here: webhook-example.

Adding the webhook to the repository

Choose a repository you want to work on. You can fork the example repository. Make sure to rename .template.env to .env and change the secret string if you want to.
Go to Settings > Webhooks > Add webhook. Or just visit https://github.com/<username>/<repo-name>/settings/hooks/new.
We will start the server and expose it via a tunnel. I’m using cloudflared but you can use anything else if you want to.
As you can see, we have chosen application/json as the content type cause we want the payload in JSON. For the secret, you can put any random string but make sure you remember/note what you put there. For the example repository you also have to update your .env file. Details in the next section.

Note about SSL: We’ve only disabled it because it’s just a demo. Enable this without fail in your real applications.

Listening to the webhook in your server

The index.js is the entry point for our server. It’s a simple static site server in Node.js which serves a React build. We mount the webhook listener in the /webhook route. Notice how we used this route in the URL we provided to GitHub in the previous step.
```
// Mount the webhook listener
app.use('/webhook', webhookRouter);
```

In webhook.js, we first parse the .env file which contains our secret.

dotenv.config();
const SECRET = process.env.GH_WEBHOOK_SECRET;

Next we add 2 middlewares. The first middleware stores the raw request buffer. We do this because parsing damages the integrity of the signature.
```
bodyParser.json({
	verify: (req, res, buf) => {
	req.rawBody = buf;
  	},
})
```

The second middleware verifies the signature sent with our secret that only we and GitHub knows. This way we know the request is actually a valid one from GitHub. This is why SSL is so important because without that you’re exposing this request to MITM attacks.

const body = Buffer.from(req.rawBody, 'utf8');
const ghSign = req.get('x-hub-signature-256');
const ourSign = 'sha256=' + crypto.createHmac('sha256', SECRET).update(body).digest('hex');
if (ghSign !== ourSign) {
   throw new Error();
}

And finally, we listen to it in the POST handler.

webhookRouter.post('/', async (req, res) => {
 	console.debug(req.body)
}

At this point, if you push some changes, you can see the payload in your terminal where the server is running:

{
    "ref": "refs/heads/master",
    "repository": {
        "name": "webhook-example",
        "full_name": "abhijit-hota/webhook-example"
    },
    "pusher": {
        "name": "abhijit-hota",
        "email": "abhihota025@gmail.com"
    },
    "head_commit": {
        "id": "6c386ca6d6f3df80ea7b0abd59c3b9a8c3983726",
        "message": "chore: add comments and increase legibility",
        "timestamp": "2022-10-05T22:19:21+05:30",
        "author": {
            "name": "abhijit-hota",
            "email": "abhihota025@gmail.com",
            "username": "abhijit-hota"
        },
        "added": [],
        "removed": [],
        "modified": [
            ".template.env",
            "index.js",
            "webhook.js"
        ]
    }
}

I’ve removed a lot of stuff from the payload and have just shown the relevant ones. Now all that left is to run commands based on the data we get. More on this in the next section.

Building and executing commands

We’re only going to see how to solve it for Linux but it shouldn’t be that hard to build queries for Windows systems in a similar way, if you’re using Windows at all for deployments.

We check for the commit message and the pusher. You can of course, choose your own logic here:

const { head_commit: commit, pusher } = req.body;

if (!commit.message.startsWith('deploy') || pusher.name !== 'abhijit-hota') {
    return res.send('Deployment skipped.');
}

We create an array of commands to run. And we add to it as we go over the changes. The code is pretty self-explanatory and I’ve added comments too.


const commands = ["cd "];
const changes = [...commit.modified, ...commit.added, ...commit.removed];

const requiresReinstall = changes.any((change) => change.startsWith('package'));
if (requiresReinstall) {
    commands.push('npm install');
}

const hasFrontendChanges = changes.any((change) => change.startsWith('frontend'));
if (hasFrontendChanges) {
    commands.push('cd frontend'); 
    const requiresReinstallInFrontend = changes.any((change) => change.startsWith('frontend/package'));
    if (requiresReinstallInFrontend) {
        commands.push('npm install');
    }
    commands.push('npm run build');
}
commands.push('npm start');

Join the whole command string with && and run it.

const cmd = commands.join(' && ');
console.debug("Command to run:", cmd);
exec(cmd); // exec from child_process

Let’s put it to test! We commit with the message deploy: test and we see the message:
```
Command to run: cd /home/kreta/work/misc/webhook-example && git pull --all && git checkout main && npm start
```
npm start in the package.json starts the server in localhost:8080. And sure enough:

It’s a hack at the end of the day

The performance cost is way less than GH Action runners. We run a separate Node.js server for this which only takes up like 50 MB of RAM. I’m sure we can remove all the fluff from there and make it leaner but it works for now.
For multi-repo systems, you can create organisation-level webhooks and change the command according to the repository field in the payload.
“But Abhijit, there’s no CI at all!”. Just add an npm test somewhere and log the reports, email, etc. if you care about it.

Addressing the obvious thoughts in your head, yes, it can break and there’s no way of knowing if the command is faulty. But you can setup logging, alerts etc. It’s your system. It’s code. It cannot get more IaC than this. I set this up on the actual server almost a year ago and it hasn’t been changed ever since. As you can see, this is a setup once and forget kinda system.

But if your infra is changing a lot of times and requires really good monitoring, please don’t use this. This is a hack and I’m not very fond of hacks. Except for this one. This one, I’m proud of.

First principles are good

The simplest solutions are the best ones. If we go backwards from a solution to the problem, we can find better ways of thinking. Some hacks and workarounds can sometimes go against the practice of using the right tools and can feel like reinventing the wheel. But if the trade-off is worth it, maybe it is the best solution for it after all. Remember to scale with common sense.

The repository was larger than needed because it had a whole Bootstrap theme template. ↩︎

My arsenal of CLI tools

Sun, 17 Jul 2022 08:43:07 +0530

Background

I’ve been seriously using Linux for (just) over 2 years. The thing I take pride in is my pragmatic, albeit flashy at times, CLI setup. This article could be a dotfiles repository but I keep it private because I think it’s too risky.

Let’s look into some tools I use daily.

My terminal setup

kitty, the best terminal emulator

fast

panes, tabs, windows

a plethora of configurable keybindings

really good plugin model and ecosystem

remote control allows amazing interop between other software

fantastic scroll-back buffer manipulation capabilities

little features such as following links via keyboard, selecting text, etc.

zsh

ohmyzsh

powerlevel10k

Bunch of plugins

Tools of trade

There are a lot of awesome articles and resources that list out amazing CLI tools.

I’m going to be talking about the tools which have stuck with me and I actually use, hence the use of word “My” in the title.

Let’s go over the tools categorically as Julia Evans does in her CLI list.

Replacement for standard tools

batcat

The cat command with other niceties such as syntax highlighting, paging, line numbers, etc.
fd

A faster, user-friendlier find
ripgrep

A faster, user-friendlier grep¹
dua

A tool to check how much space on disk, a particular directory/file is occupying and to delete it in a nicer way. Can be an alternative to du and rm.
btop

Powerful and pretty resource monitoring tool, alternative to top. One of my favorite tools here because of the convenient keyboard bindings.
procs

Prettier ps with extra features. I mainly use it as it displays the PID of a server associated with its TCP port. Very handy to clear dangling processes. Only if this was possible in btop.
tldr

Provides short usage examples for common commands. I don’t dislike man pages but they can be really hard to sift through when you are just looking for a basic example.

Just as a little game, guess what command I’ve tldred the most.²

micro

I need a quick, in-terminal editor a lot of times. Even though I use a lot of CLI tools, I’m not acquainted with vi³ or nano. I prefer the “vanilla” editor keys such as arrow keys for moving among words, Ctrl+X/Ctrl+V, Shift+Arrow for selecting, etc. micro is a perfect tool to me for this situation.

New(ish) inventions

zoxide

A directory autojumper based on frecency. zoxide isn’t a new invention in itself but autojumping tools are. If there’s a tool that I’d take with me to my grave, it would be this. I’ve used it more than I can admit.
dragon

Render a GUI list of files from the CLI to drag somewhere. I generally use this to drag files into my browser like upload boxes, email attachments, etc.
eget

If it’s not obvious by now, I love tools. And all of these CLI tools are hosted on GitHub. eget makes it way easier to download releases and extract them into the one of many bin directories Linux has.
entr

A small filesystem watcher. I don’t use this much as I rely on language specific tooling like air for Golang.
chezmoi

Powerful and easy dotfile manager using Git. I have auto-commit/push turned on and regularly do a chezmoi re-add so I’m not scared of losing my configuration at all.
viu

View images in the terminal. Good for previewing files. When I came across this for the first time, it was sorcery to me. Thanks again, Kitty.
nnn

I haven’t tried a lot of CLI file managers because nnn was the first I tried and my mind just said, yep, I’m not going to move off this.

Along with the awesome keyboard navigation features, the real deal for me was the plugin system which leveraged my already existing tools. It has a preview plugin which ties with viu, a dragon plugin, a KDE Connect plugin to send files to otehr devices, and a zoxide plugin for autojumping.

JSON/YAML/CSV things

dasel

Super convenient conversion among JSON <-> CSV <-> YAML <-> etc. It’s simple and just converts one format to the other. No fancy transformation stuff.
jq

Super powerful JSON toolkit. jq has a relatively steeper learning curve but I’ve been successfully using it with the help of this cheat sheet and occasional trips to the manual.
tv

It’s a CLI CSV viewer. It’s just better than cating CSVs.

Miscellaneous

These don’t really fall under CLI tools, but are CLI extensions or alternatives to other tools.

kdeconnect-cli

I do a lot of file sharing from and to my phone and KDE Connect works flawlessly.
spotify-tui and spotifyd

Call me crazy but trying Spotify in the terminal was one of the reason I pay for Spotify Premium. Worth it.

Useful aliases

These are some useful aliases built on top of above mentioned tools and standard tools that I frequently use:

share:

A Wrapper around KDE Connect that shares screenshots and files

share() {
  # `share ss`: Shares latest screenshots/image in the clipboard
  if [[ $1 = "ss" ]]; then 
      img_path=/tmp/$(date +"%d_%m_%y-%H_%M_%m").png
      xclip -selection clipboard -t image/png -o >$img_path
      kdeconnect-cli -n sam --share $img_path

  # `share /some/path/file.ext`: Shares files
  else
      kdeconnect-cli -n sam --share $1
  fi
}

j2c & c2j

Convert JSON <-> CSV

j2c() {
  dasel -r json -w csv
}
c2j() {
    dasel -r csv -w json
}

dmv/dcp

I constantly face this situation where I have to mv or cp the latest downloaded file to the folder I’m currently at. This alias was my solution

dmv() {
  __fname="$(ls -t ~/Downloads | head -n 1)"
  __fpath="$HOME/Downloads/"$__fname""
  mv "$__fpath" \.
}
dcp() {
    __fname="$(ls -t ~/Downloads | head -n 1)"
    __fpath="$HOME/Downloads/"$__fname""
    cp -a "$__fpath" \.
}

str

Shortcut to generate random strings. Useful for placeholders, development secret keys, etc.
```
str() {
  # Usage: `str 8`
  node -p "crypto.randomBytes($1/2).toString('hex');"
}
```
pskill

Usage: pskill foo. Slightly dangerous alias that kills all processes matching foo.
```
pskill() {
  procs $1 --no-header --only pid | xargs kill -15
}
```

m

Quick maths! Stole it from this HN comment.

m() {
  python3 -c "from math import *; print($*)"
}

A hyperbolic rant

I love the CLI. Dare I say, it’s the easiest way of getting things done if you know what you’re doing. And of course, that’s a gigantic “if”.

Compare the following 2 conversations:

Bob: Hey, how do I [do this] using [that] such that [something] becomes [something else] and [that particular thing] is not messed up?

Alice: Ah, give me a minute!

[10 minutes later]

Alice: Here, yank this into the terminal and run it.
$ dothis --use=that \
  --from=something \
  --to=something-else \
  --ignore=that-particular-thing
Bob: Nice.

vs.

Alice: Hey, how do I connect to Wi-Fi?

Bob: There should be a Wi-Fi icon thingy in the bottom-right corner.

Alice: There isn’t.

Bob: There should be.

Alice: There isn’t.

Bob: You are using Winwoes 10, right?

Alice: Yes.

Bob: Okay, go to Control Panel.

Alice: How?

Bob: Go to start and search for it

Alice: Okay, I’m here.

Bob: Now, on your top-left side, you’ll see a blue button which says View. Change the view to category, then you’ll see the Network and connectivity settings, go there. You’ll see Networks tab. Go there. You’ll see wireless networks, click that. Now you should see the Wi-Fi.

Alice: I don’t.

Bob: FFFUUUUUUUUU

Now, this is obviously a hyperbole. And I’m not bashing GUIs (geddit?). I’m not saying CLIs should be the norm. I’m merely saying that learning how to use the CLI properly will make you a power user.

Conclusion

Thanks to the creators of these incredible tools mentioned above.
Thanks to Rust and Go for modernizing CLIs and keeping them alive. If I’ve to take a guess, making CLIs in these new, shiny languages made them appealing to new developers.

I started using ripgrep before learning enough grep so I can’t really tell how better it is in terms of UX. The benchmarks speak for the performance. ↩︎
You are correct ↩︎
I’m gonna learn vi some day. ↩︎

Node.js Import Aliases

Tue, 05 Jul 2022 17:09:43 +0530

The Problem

Oftentimes, as a Node.js codebase grows, this happens:

import { UserModel } from "../../../../db/models/index.js";
import { validate } from "../../../../lib/utils.js";
import { SERVICE_API_KEY } from "../../../../lib/constants.js";

There are a few problems with this:

Sensitivity to folder structure changes: A good IDE or editor can auto-import but not all of them are without errors. Also, what if you change something outside your general IDE?
Clutter: It just simply looks bad

The Solution

A new field in package.json called imports was stabilized in Node.js v14. It was introduced earlier in Node.js v12. It follows certain rules and lets you “map” certain aliases (custom paths) to a path of your choice and also declare fallbacks.

Here’s the documentation for the same.

We can solve our example problem by adding this to our package.json:

"imports": {
  "#models": "./src/db/models/index.js",
  "#utils": "./src/lib/utils.js",
  "#constants": "./src/lib/constants.js"
}

and use them in your code anywhere like this:

import { UserModel } from "#models";
import { Validate } from "#utils";
import { SERVICE_API_KEY } from "#constants";

Note

The entries in the imports field of package.json must be strings starting with # to ensure they are disambiguated from package specifiers like @.
The values should be relative paths from the root of the project. The root is where your package.json is.

In the above example, we assumed package.json was at the root and all the relevant files were inside a src directory.

You should see your application run fine but your IDE of choice may show some errors. Undesirable red and yellow squiggles are no one’s favorite. It would also auto-import from the actual relative path instead of the path alias. That’s no fun.

jsconfig.json to the rescue. (tsconfig.json if you’re in a TypeScript project.)

In your jsconfig.json, add the following

"compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "#models": ["./src/db/models/index.js"],
      "#utils": ["./src/lib/utils.js"],
      "#constants": ["./src/lib/constants.js"]
    }
}

The above configuration tells your IDE’s LSP to look for code in the given prefixes. Refer to the documentation of the property to know more.

Now we have sweet auto-imports from the desired location:

Fallback dependencies

As seen in the documentation, you can also use this property for conditionally setting up fallback packages or polyfills. From the documentation:

// package.json
{
  "imports": {
    "#dep": {
      "node": "dep-node-native",
      "default": "./dep-polyfill.js"
    }
  },
  "dependencies": {
    "dep-node-native": "^1.0.0"
  }
}
[Here, if the] import #dep does not get the resolution of the external package dep-node-native (including its exports in turn), and instead gets the local file ./dep-polyfill.js relative to the package in other environments.

Frontend projects

I haven’t tried this approach with frontend applications. They generally use a bundling system like Webpack or Rollup which have their own way of resolving aliases. For example, for Vite (which uses Rollup and ESBuild), you should add this to your vite.config.js:

import path from "path";

export default defineConfig({
//   Some other config
	resolve: {
		alias: {
			"#": path.resolve(__dirname, "./src"),
		},
	},
});

and in your jsconfig.json:

{
	"compilerOptions": {
		"baseUrl": ".",
		"paths": {
			"#/*": ["src/*"]
		}
	}
}

The above configuration maps everything starting with # to immediate folders and files below src. YMMV.

A designer knows he has arrived at perfection not when there is no longer anything to add but when there is no longer anything to take away

- Jon Bentley in Programming Pearls

Nerd-sniping myself over Go range expressions

Sat, 02 Jul 2022 17:03:48 +0530

The background

I stumbled across a situation while writing a Golang project where I needed to loop over a slice returned by a function. The function being strings.Split. No big deal. I wrote the following:

for _, id := range strings.Split(path, "/") {
    // Something()
}

There’s another way of writing the same thing:

splitPath := strings.Split(path, "/")
for _, id := range splitPath {
    // Something()
}

To the novice-eyed, like me, it would seem the latter was an optimized version as the function is only called once before the loop and hence more performant. I did not care about the negligible performance gain I would get as the path variable passed to the split function would be limited in length by application constraints.

But what if it wasn’t?

tldr; It doesn’t matter how you write it. They are both the same. From the Golang spec,

The range expression x is evaluated once before beginning the loop, with one exception: if at most one iteration variable is present and len(x) is constant, the range expression is not evaluated.

This seems obvious once you know about it because it’s such a low-hanging fruit for the compiler. It’s not even compiler optimization. It’s compiler duty.

From here, I’m going to write about how I nerd-sniped myself into finding the answer to this and naturally, spent around 4 hours benchmarking, trying to figure out assembly, checking the compiler optimization wiki, some trivial experimentation that confirmed my theory and one line in the spec that made it all come together.

Before we proceed into this, have some context about the original scenario. The function should split a separated string called path with / as delimiter and extract all integers into an array like this:

func ExtractInts(path string) []int {
	pathIds := []int{}
	for _, v := range strings.Split(path, "/") {
		if v != "" {
			val, _ := strconv.Atoi(v)
			pathIds = append(pathIds, val)
		}
	}
	return pathIds
}

Benchmarking the two functions

I put together a quick small project to bench the thing consisting of main.go and main_test.go:

`main.go`

package main

import (
	"strconv"
	"strings"
)

func WithOptim(path string) int {
	pathIds := []int{}
	pathIdsStr := strings.Split(path, "/")
	for _, v := range pathIdsStr {
		if v != "" {
			val, _ := strconv.Atoi(v)
			pathIds = append(pathIds, val)
		}
	}
	return len(pathIds)
}

func WithoutOptim(path string) int {
	pathIds := []int{}
	for _, v := range strings.Split(path, "/") {
		if v != "" {
			val, _ := strconv.Atoi(v)
			pathIds = append(pathIds, val)
		}
	}
	return len(pathIds)
}

`main_test.go`

package main

import (
	"strings"
	"testing"
)

var path = strings.Repeat("734/956/831/811/", 100_000)

var resultWithOptim int

func BenchmarkWithOptim(b *testing.B) {
	var r int
	for n := 0; n < b.N; n++ {
		r = WithOptim(path)
	}
	resultWithOptim = r
}

var resultWithoutOptim int

func BenchmarkWithoutOptim(b *testing.B) {
	var r int
	for n := 0; n < b.N; n++ {
		r = WithoutOptim(path)
	}
	resultWithoutOptim = r
}

The variables r, resultWithOptim and resultWithoutOptim are needed to escape compiler optimizations and get reliable benchmarks.

Check out this section from the awesome benchmarking article by Dave Cheney.

Results

I ran the benchmark a couple of times.¹

In most cases, it was neck-and-neck:

BenchmarkWithoutOptim-8     63	 18067614 ns/op
BenchmarkWithOptim-8        64	 17833483 ns/op
3.282s

BenchmarkWithoutOptim-8     64	 17879142 ns/op
BenchmarkWithOptim-8        66	 17943536 ns/op
3.287s

BenchmarkWithoutOptim-8     66	 17915000 ns/op
BenchmarkWithOptim-8        66	 17567501 ns/op
3.292s

BenchmarkWithoutOptim-8     56	 18344452 ns/op
BenchmarkWithOptim-8        57	 17649186 ns/op
2.090s

In some cases the one with optimizations performed better:

BenchmarkWithoutOptim-8     64	 18446009 ns/op
BenchmarkWithOptim-8        73	 18054308 ns/op
3.548s

BenchmarkWithoutOptim-8     63	 18466071 ns/op
BenchmarkWithOptim-8        70	 18600002 ns/op
3.422s

BenchmarkWithOptim-8        64	 18917323 ns/op
BenchmarkWithoutOptim-8     58	 18092279 ns/op
3.215s

But in some cases the one without any optimizations performed faster!

BenchmarkWithOptim-8        55	 18848131 ns/op
BenchmarkWithoutOptim-8     68	 19239865 ns/op
2.395s

BenchmarkWithOptim-8        57	 18323290 ns/op
BenchmarkWithoutOptim-8     63	 17598465 ns/op
2.206s

Digging into the why

The first resource I came across was the Compiler And Runtime Optimizations wiki which stated nothing about such behaviour.

I also tried converting the code into Assembly using Compiler Explorer but couldn’t understand any of it.

Was the compiler calling the function only once? Are the 2 ways of writing same? I had no way of knowing. Then I thought of something so trivial I felt dumb.

The trivial experiment

Consider the following code:

func Nums() []int {
    print("Nums called\n")
	return []int{1, 2, 3, 4, 5}
}

func Loop() {
	for _, v := range Nums() {
		print(v)
	}
}

func main() {
	Loop()
}

And surely enough, Nums called is only printed once to STDOUT. This felt so obvious once I realised it.

Eureka + Facepalm moment

Googling “go range internals” gave me this article by Robbie V which sent me to the Go language specification where I found this:

The range expression x is evaluated once before beginning the loop, with one exception: if at most one iteration variable is present and len(x) is constant, the range expression is not evaluated.

Conclusion

There’s nothing much to conclude but there’s a lesson to learn. In Robbie V’s article, the Step 1 was to RTFM. Unlike that, I dove right into benchmarking which was like comparing two sum functions which returned a + b vs. b + a. I discovered a lot but this shouldn’t have taken so much of my time.

It’s a reminder on how we can take some slightly interesting things, like the one I talked about here, for granted and never realise the machinery of it.

As to which function is better to write, that would be an opinion.

Other languages

I tried the same thing in a few other languages I’ve coded in because I never realised this:

JavaScript

function nums() {
	console.debug('Nums called');
	return [1, 2, 3, 4, 5];
}

function loop() {
	for (const v of nums()) {
		console.debug(v);
	}
}

loop();

Python

def nums():
    print("Nums called")
    return [1,2,3,4,5]

def loop():
    for l in nums():
        print(l)

loop()

Using go test -bench=. -run=xxx

Specs:
```
goos: linux 
goarch: amd64 
cpu: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
```
Order of function execution was changed a few times. ↩︎

Posts on Abhijit Hota

Vanity import paths in Go using Caddy

Vanity import paths

Using Caddy to make the vanity URL work

Distinguishing requests from Go

Generalizing our setup

Acknowledgement

Method Middlewares with JavaScript Proxies

my 2024 fumble list

resolutions 2024

consumption

reading

movies

games

creation

writing

software/coding

photos

misc

travel

share more stuff

In my midwit phase

Containerisation for DevOps

Background

DevOps

Characteristics of devops

What is Containerization?

The problems faced in DevOps

Why Containerization?

Reproducible environments

Versatile builds

Consistent development tools

Testing via Isolation

Security via Isolation

Resource conscious

Enables Collaboration

Conclusion

Poor man's CI/CD with GitHub Webhooks

Background

Self-hosted GitHub Actions

The hack which seemed like the solution

Step by step instructions

Adding the webhook to the repository

Listening to the webhook in your server

Building and executing commands

It’s a hack at the end of the day

First principles are good

My arsenal of CLI tools

Background

Tools of trade

Replacement for standard tools

New(ish) inventions

JSON/YAML/CSV things

Miscellaneous

Useful aliases

A hyperbolic rant

Conclusion

Node.js Import Aliases

The Problem

The Solution

Note

Fallback dependencies

Frontend projects

Nerd-sniping myself over Go range expressions

The background

Benchmarking the two functions

main.go

main_test.go

Results

Digging into the why

The trivial experiment

Eureka + Facepalm moment

Conclusion

Other languages

JavaScript

Python

`main.go`

`main_test.go`