Forem: Sivasubramanyam A

Using different Git commit authors for personal and work projects

Sivasubramanyam A — Mon, 07 Oct 2019 19:14:25 +0000

If you are somebody like me who has both personal and work projects in your development setup, you will probably be setting up the commit author each time you clone a repo.

While it's foolproof, it can feel annoying to do this often. I was looking for a solution to this and here's what I found.

It is possible to include .gitconfig files in other .gitconfig files. An interesting feature in Git is that you can do this conditionally.

Let's use this feature to our advantage now. In your ~/.gitconfig, do the following:

# ~/.gitconfig

[user]
    email = personal@email.com
    name  = Siva

[includeIf "gitdir:~/work/"]
    path = .gitconfig-work

What this does is that, it sets the commit author's name to Siva and email to personal@email.com. When a repository's path starts with ~/work, it includes the configuration in .gitconfig-work. Now, if .gitconfig-work has the following contents, the commits in that repo alone will use the following user(essentially overriding the previous user).

# ~/.gitconfig-work

[user]
    email = official@company.com
    name  = Mr. Siva

Using the above setup, all Git repositories, except the ones under the path ~/work/ use my personal details and the ones under ~/work are committed with my official details.

How are identicons generated?

Sivasubramanyam A — Sun, 06 Oct 2019 13:06:52 +0000

We have seen them everywhere. From GitHub to Stack Overflow, identicons have been the face of users who do not have an associated Gravatar or a profile photo.

I wanted to figure out how these were generated and came across this blog post by GitHub where they announced the introduction of identicons on their site.

Our Identicons are simple 5×5 “pixel” sprites that are generated using a hash of the user’s ID. The algorithm walks through the hash and turns pixels on or off depending on even or odd values. These generated patterns, combined with hash-determined color values, ensures a huge number of unique Identicons.

While the identicon itself is a 5x5 image, one can notice that it is symmetrical. The fourth and fifth columns mirror the second and first columns respectively. This implies that it's sufficient to express these in a 3x5 matrix. So, a 15 digit(3 x 5 = 15) sequence is sufficient to represent an identicon. As for the color, we can use a 6 bit sequence from this 15 bit number itself and generate a color code in the hex format.

Let's try and build this now.

The 15 digit sequence has to be based on the given string and should be reproducible. Let's use hashing to solve this. We can use this example from MDN to generate the hash. The SHA-1 algorithm shouldn't be used for anything serious but since this is a fun little project, let's go with it.

function hexString(buffer) {
  let byteArray = new Uint8Array(buffer);

  let hexCodes = [...byteArray].map(value => {
    let hexCode = value.toString(16);
    let paddedHexCode = hexCode.padStart(2, '0');
    return paddedHexCode;
  });

  return hexCodes.join('');
}

function getHash(message) {
  let encoder = new TextEncoder();
  let data = encoder.encode(message);

  return window.crypto.subtle.digest('SHA-1', data);
}

async function handleInput() {
  let userInput = document.getElementById('message').value;
  let hash = hexString(await getHash(userInput));

  console.log(hash);  // logs f10e2821bbbea527ea02200352313bc059445190
}

Now, we need to convert this 40 character long hash into a 15 bit sequence.

In the above matrix, the value of n at position (i, j) is given by i*3 + j. We can then simply look at the nth position of the hash for 0 <= n <= 14.

This can be represented in code as:

for (let i = 0; i < 3; i++) {
  for (let j = 0; j < 3; j++) {
    let n = hash.charAt(i*3 + j);
  }
}

To determine the mirrored values to fill the fourth and fifth columns, we can modify the above code to:

for (let i = 0; i < 5; i++) {
  for (let j = 0; j < 5; j++) {
    let J = j > 2 ? (4 - j) : j;
    let n = hash.charAt(i*3 + J);
  }
}

Using the above code, we have arrived at the hash f10e2821bbbea52. We now need to find a way to use this hash to determine which of the boxes in the grid have to be filled. One trivial solution to this is to take each of these characters and check if it is divisible by 2 in the decimal form.

for (let i = 0; i < 5; i++) {
  for (let j = 0; j < 5; j++) {
    let J = j > 2 ? (4 - j) : j;
    let n = hash.charAt(i*3 + J);
    let shouldFill = parseInt(n, 16) % 2;
  }
}

All that's left is to determine the color of the fill. While we can just use a sequence of 6 digits from the hash f10e2821bbbea52 that we generated above, let's use some of the extra characters from the 40 character long hash that we generated previously.

function getColor(hash) {
  return `#${hash.slice(-6)}`;
}

let color = getColor('f10e2821bbbea527ea02200352313bc059445190');
console.log(color);  // logs #445190

Now putting this all together using some JavaScript and HTML Canvas, we get a working generator that produces identicons similar to the ones generated by GitHub.

lego, not yet another Static Site Generator

Sivasubramanyam A — Sat, 05 Oct 2019 08:04:59 +0000

I have been working for over a year on lego, a static site generator written in JavaScript. When I decided to rewrite my site, I had a wide variety of SSGs to choose from. I eventually narrowed down my choices to the following:

Gatsby - I really liked how optimised the output was with Gatsby. The only issue I had with Gatsby was the slow build timings.
Hugo - I loved Hugo for its speed. However, the templating language was frankly too disappointing.
Jekyll - This was fast enough for my site's size and the templating language, Liquid, was pretty similar to Jinja2. However, doing Gatsby like optimisations was challenging.

I had way too much free time on my hands so I did what every bored developer does. Write my own framework. In this case, I decided to write my own static site generator that emulates the good parts of these three frameworks.

I had a few requirements out of this and decided to try building it for a week or so and see how feasible this was.

Support Liquid(recently added Nunjucks support).
Support Markdown posts, data in YAML(later extended to JS and JSON).
Transpile and uglify JS with terser, use PostCSS for CSS(both use browserslist to determine targets).
Revision assets like JS, CSS and images.
Optimise images.
Extract and inline critical styles with critical for all pages.
Minify HTML of all pages.
Generate a tag-wise listing of posts. For example, site/tags/javascript should list all pages tagged JavaScript.
Live Reload during development.

Surprisingly it turned out pretty well. There were still a few rough edges but I quickly ported over my site in the hopes that I could fix them.

This is when the fun began.

lego was taking about 5-6 seconds to start up. While this was not that bad compared to Gatsby, I wanted to squeeze out as much performance out of it as I could. The whole purpose of this project was to learn something and have fun in the process so I decided to profile lego. A few interesting things stood out.

Just requiring PostCSS plugins was taking a second or two.
Some code paths were running more often than necessary.

After fixing these, it came down to about 2-4 seconds.

This is when I started looking into caching. While coming up with a technique for this was challenging, the actual implementation was rather trivial. After implementing caching, I felt satisfied with this whole endeavour of writing my own SSG. I now had a fast, performant SSG that generated an optimised site.

Right now, lego starts up a development server for my own site in under 600ms. Rebuilds take under a couple hundred milliseconds. Production builds take about 20 seconds!

I wrote a benchmark to test all this. When Liquid templates are used, lego is about 1.5x faster than Jekyll and when Nunjuck templates are used, lego is a cool 8.7x faster than Jekyll.

I then added a few more things like RSS Feed generation and sitemap generation based on my own needs. While lego supports auto-generating responsive images, I think it's a little less robust and I will start paying attention to it in the coming days.

If you are feeling adventurous and want to try this out,

Run npm i -g @astronomersiva/lego.
Generate a site using lego g my-awesome-site. This will generate a dummy site.
Run lego s to start the server.

You can also checkout the code on GitHub.

Have a great weekend folks!