Forem: Shailesh Vasandani

How to get your app running when it just won't start

Shailesh Vasandani — Fri, 18 Jun 2021 03:08:26 +0000

Probably the most frustrating thing as a software developer is when you're excited to make an important change, eager to code something really neat, but your local dev environment absolutely refuses to get into gear. This has happened to me a few times now at my new internship, and as a result I've picked up a handful of new ways to try and kick some life into an app that just fails to start. So, I thought I'd share them with you all!

1: Turn it off and on again!

I know it's simple, but it could save you a LOT of time! GIPHY

Okay, I'll admit it, you probably tried this already. However, if you haven't, it could be worth a shot.

Plus, some dev environments — especially at larger companies — take full advantage of advances like hot reloading and live code injection. These are only a few, but there's a whole host of packages and dependencies whose sole goal is to remove any friction between you and writing your code (including recompiling, reloading, re-anything).

With features like these, who needs to restart apps nowadays? Clearly, you do. So go ahead and give it the old IT crowd restart. It probably won't hurt, and it might even help.

If it doesn't, though, you could try to...

2: Get rid of your compiled folder

This was a neat little trick that has helped me a lot recently. Sometimes, the folder where all the magic compilation happens (think dist/ for npm) can get corrupted. If that's the case, a simple restart won't do much to help. Times like these call for a little more incisive action! Removing the folder with all the compiled files can help clear out any of that corruption, and your app should recompile everything when you start it up again. There's not much a good old rake assets:clean or a rm -rf dist/ can't fix!

3: Reset your dev database

Sometimes, the issue isn't with the app at all. It's very possible that the dev database is causing some underlying issue, so that no matter how many times you restart your app or delete the compiled files, it still won't work. This can be very frustrating, since database errors can happen without any warning. Often you'll see logs pointing you in the general direction of a fix, but these logs can be cryptic and confusing, especially if you're not too familiar with the app. Maybe it got corrupted, or maybe some database operation ran when it shouldn't have. In either case, nuking the whole thing is a reliable (if overkill) way to resolve the issue.

If you've got a decent dev environment set up, it should be as easy as running a few make commands. If not, though, you might be in for a world of hurt. Don't forget to brush up on your SQL before diving in!

4: Pull in the latest commits

You might not be the only one experiencing the issue. Maybe some more experienced engineers caught wind of it, and even fixed it for you! However, you'll never know unless you pull their latest changes in. This might not be super effective in a company that uses microservices, since most of the code is encapsulated in different repos, but for companies that use a monorepo, this could be a game changer. Moving parts are always prone to breaking, and sometimes another team pushes something that maybe should've gone through another review. Sure, they might have fixed it 5 minutes afterwards, but you'll never know unless you pull those most recent commits in.

Bonus: If you've been working on something in a separate branch, you've got (essentially) two options — rebase, or merge. While both have their pros and cons, I'm generally a fan of rebasing. But keep an eye out for a post further down the line where I go into more detail looking at the differences between the two!

5: Delete your dependencies and reinstall them

If the problem isn't with your app, isn't with your database, and isn't even with your repo, it might be somewhere else entirely! Apps nowadays rely on a vast network of dependencies, almost to a ridiculous extent (I'm looking at you, is-odd). It's like a very fragile house of cards where one false commit can cause the whole thing to throw errors like candy at a parade. (Do they throw candy at parades? Weird analogy.) In any case, one of your dependencies could have gotten corrupted. The easiest fix? Delete that node_modules folder! Delete those gems! Run that npm install or bundle install! Revel in your newfound lack of errors!

Note: there's a not insignificant chance that doing the above may cause the entire thing to implode even more, so please do it with caution. Some maniacal glee, sure, but mostly caution. Dependencies can be sensitive.

So there you have it! My not at all exhaustive list of ways to possibly rejuvenate your app (or make things worse). I hope my experiences have helped you, even a little, and be sure to stop by regularly for even more interesting posts. If you found this one useful, consider buying me a coffee. Until next time!

How to store data client-side with IndexedDB

Shailesh Vasandani — Fri, 22 Jan 2021 03:01:00 +0000

Imagine a calculus exam where you had to do all the calculations in your head. It's technically possible, but there's absolutely no reason to do it. The same principle applies to storing things in the browser.

Today, there are a number of widely implemented technologies for client-side storage. We have cookies, the Web Storage API, and IndexedDB. While it's entirely possible to write a fully functioning web application without worrying about any of these, you shouldn't. So how do you use them? Well each of them has a use case that they're best suited to.

A quick overview of browser storage

Cookies

Cookies, being sent on basically every request, are best used for short bits of data. The big advantage of cookies is that servers can set them directly by using the Set-Cookie header, no JavaScript required. On any subsequent requests, the client will then send a Cookie header with all previously set cookies. The downside of this is that large cookies can seriously slow down requests. That's where the next two technologies come in.

Web Storage

The Web Storage API is composed of two similar stores — localStorage and sessionStorage. They both have the same interface, but the latter lasts only while the browsing session is active. The former persists as long as there is available memory. This memory limit is both its largest advantage and disadvantage.

Because these values aren't sent along with every request, it's possible to store large amounts of data in them without affecting performance. However, "large" is relative, and the storage limit can vary wildly across browsers. A good rule of thumb is to store no more than 5 MB for your entire site. That limit isn't ideal, and if you need to store more than that, you're probably going to need the third and final API.

IndexedDB

IndexedDB, one might argue, is criminally underrated. Despite being supported across basically every browser, it's nowhere near as popular as the other two. It's not sent with every request like cookies are, and it doesn't have the arbitrary limits of Web Storage. So what gives?

The reason IndexedDB is not very popular is, it turns out, that it's an absolute pain to use. Instead of using Promises or async/await, you need to define success and error handlers manually. Many libraries encapsulate this functionality, but they can often be overkill. If all you need is to save and load data, you can write everything you need yourself.

Wrapping IndexedDB neatly

While there are lots of ways to interface with IndexedDB, what I'll be describing is my personal, opinionated way of doing so. This code works for one database and one table, but should be easily modified to fit other use cases. Before we jump into code, let's make a quick list of what requirements we need.

1. Ideally, it's some sort of class or object that we can import and export.

2. Each "object" should represent one database and table only.

3. Much like a CRUD API, we need methods to read, save, and delete key-value pairs.

That seems simple enough. Just a side note - we'll be using ES6 class syntax here, but you can modify that as you wish. You don't even need to use a class if you're only using it for one file. Now let's get started.

Some boilerplate

We know essentially what methods we need, so we can stub those out and make sure all the functions make sense. That way, it's easier to code and test (which I didn't do because it was for a personal project, but I really should get onto that).

Hey, it looks like you're on a slightly narrower screen. The code blocks below might not look too good, but the rest of the article should be fine. You can hop on a wider screen if you want to follow along. I'm not going anywhere (promise).

     class DB {
        constructor(dbName="testDb", storeName="testStore", version=1) {
          this._config = {
            dbName,
            storeName,
            version
          };
        }

        set _config(obj) {
          console.error("Only one config per DB please");
        }

        read(key) {
          // TODO
        }

        delete(key) {
          // TODO
        }

        save(key, value) {
          // TODO
        }
      }

Here we've set up some boilerplate that has all of our functions, and a nice constant configuration. The setter around _config ensures that the configuration can't be changed at any point. That will help both debug any errors and prevent them from happening in the first place.

With the boilerplate all done, it's time to move on to the interesting part. Let's see what we can do with IndexedDB.

Reading from the database

Even though IndexedDB doesn't use Promises, we'll be wrapping all of our functions in them so that we can work asynchronously. In a sense, the code we'll be writing will help bridge the gap between IndexedDB and more modern ways of writing JavaScript. In our read function, let's wrap everything in a new Promise:

      read(key) {
        return new Promise((resolve, reject) => {
          // TODO
        });
      }

If and when we get the value from the database, we'll use the resolve argument to pass it along the Promise chain. That means we can do something like this somewhere else in the code:

      db = new DB();

      db.read('testKey')
        .then(value => { console.log(value) })
        .catch(err => { console.error(err) });`

Now that we have that set up, let's look at what we need to do to open up the connection. To open the actual database, all we need to do is call the open method of the window.indexedDB object. We're also going to need to handle three different cases — if there's an error, if the operation succeeds, and if we need an upgrade. We'll stub those out for now. What we have so far looks like this:

      read(key) {
        return new Promise((resolve, reject) => {
          let dbRequest = window.indexedDB.open(dbConfig.dbName);

          dbRequest.onerror = (e) => {
            // TODO
          };

          dbRequest.onupgradeneeded = (e) => {
            // TODO
          };

          dbRequest.onsuccess = (e) => {
            // TODO
          };
        });
      }

If the open errors out, we can simply reject it with a useful error message:

      dbRequest.onerror = (e) => {
        reject(Error("Couldn't open database."));
      };

For the second handler, onupgradeneeded, we don't need to do much. This handler is only called when the version we provide in the constructor doesn't already exist. If the version of the database doesn't exist, there's nothing to read from. Thus, all we have to do is abort the transaction and reject the Promise:

      dbRequest.onupgradeneeded = (e) => {
        e.target.transaction.abort();
        reject(Error("Database version not found."));
      };

That leaves us with the third and final handler, for the success state. This is where we'll be doing the actual reading. I glossed over the transaction in the previous handler, but it's worth spending the time to go over now. Because IndexedDB is a NoSQL database, reads and writes are performed in transactions. These are just records of the different operations being performed on the database, and can be reverted or reordered in different ways. When we aborted the transaction above, all we did was tell the computer to cancel any pending changes.

Now that we have the database though, we'll need to do more with our transaction. First, let's get the actual database:

      let database = e.target.result;

Now that we have the database, we can get the transaction and the store consecutively.

      let transaction = database.transaction([ _config.storeName ]);
      let objectStore = transaction.objectStore(_config.storeName);

The first line creates a new transaction and declares its scope. That is, it tells the database that it'll only be working with one store, or table. The second gets the store and assigns it to a variable.

With that variable, we can finally do what we set out to. We can call the get method of that store to get the value associated with the key.

      let objectRequest = objectStore.get(key);

We're just about done here. All that's left to do is to take care of the error and success handlers. One important thing to note is that we're checking to see if the actual result exists. If it doesn't we'll throw an error as well:

      objectRequest.onerror = (e) => {
        reject(Error("Error while getting."));
      };

      objectRequest.onsuccess = (e) => {
        if (objectRequest.result) {
          resolve(objectRequest.result);
        } else reject(Error("Key not found."));
      };

And with that done, here's our read function in its entirety:

      read(key) {
        return new Promise((resolve, reject) => {
          let dbRequest = window.indexedDB.open(_config.dbName);

          dbRequest.onerror = (e) => {
            reject(Error("Couldn't open database."));
          };

          dbRequest.onupgradeneeded = (e) => {
            e.target.transaction.abort();
            reject(Error("Database version not found."));
          };

          dbRequest.onsuccess = (e) => {
            let database = e.target.result;
            let transaction = database.transaction([ _config.storeName ], 'readwrite');
            let objectStore = transaction.objectStore(_config.storeName);
            let objectRequest = objectStore.get(key);

            objectRequest.onerror = (e) => {
              reject(Error("Error while getting."));
            };

            objectRequest.onsuccess = (e) => {
              if (objectRequest.result) {
                resolve(objectRequest.result);
              } else reject(Error("Key not found."));
            };
          };
        });
      }

Deleting from the database

The delete function goes through a lot of the same steps. Here's the whole function:

      delete(key) {
        return new Promise((resolve, reject) => {
          let dbRequest = indexedDB.open(_config.dbName);

          dbRequest.onerror = (e) => {
            reject(Error("Couldn't open database."));
          };

          dbRequest.onupgradeneeded = (e) => {
            e.target.transaction.abort();
            reject(Error("Database version not found."));
          };

          dbRequest.onsuccess = (e) => {
            let database = e.target.result;
            let transaction = database.transaction([ _config.storeName ], 'readwrite');
            let objectStore = transaction.objectStore(_config.storeName);
            let objectRequest = objectStore.delete(key);

            objectRequest.onerror = (e) => {
              reject(Error("Couldn't delete key."));
            };

            objectRequest.onsuccess = (e) => {
              resolve("Deleted key successfully.");
            };
          };
        });
      }

You'll notice two differences here. First, we're calling delete on the objectStore. Second, the success handler resolves right away. Other than those two, the code is essentially identical. This is the same for the third and final function.

Saving to the database

Again, because it's so similar, here's the entirety of the save function:

      save(key, value) {
        return new Promise((resolve, reject) => {
          let dbRequest = indexedDB.open(dbConfig.dbName);

          dbRequest.onerror = (e) => {
            reject(Error("Couldn't open database."));
          };

          dbRequest.onupgradeneeded = (e) => {
            let database = e.target.result;
            let objectStore = database.createObjectStore(_config.storeName);
          };

          dbRequest.onsuccess = (e) => {
            let database = e.target.result;
            let transaction = database.transaction([ _config.storeName ], 'readwrite');
            let objectStore = transaction.objectStore(_config.storeName);
            let objectRequest = objectStore.put(value, key); // Overwrite if exists

            objectRequest.onerror = (e) => {
              reject(Error("Error while saving."));
            };

            objectRequest.onsuccess = (e) => {
              resolve("Saved data successfully.");
            };
          };
        });
      }

There are three differences here. The first is that the onupgradeneeded handler needs to be filled in. That makes sense, since setting values in a new version of the database should be supported. In it, we simply create the objectStore using the aptly named createObjectStore method. The second difference is that we're using the put method of the objectStore to save the value instead of reading or deleting it. The final difference is that, like the delete method, the success handler resolves immediately.

With all that done, here's what it looks like all put together:

      class DB {
        constructor(dbName="testDb", storeName="testStore", version=1) {
          this._config = {
            dbName,
            storeName,
            version
          };
        }

        set _config(obj) {
          console.error("Only one config per DB please");
        }

        read(key) {
          return new Promise((resolve, reject) => {
            let dbRequest = window.indexedDB.open(_config.dbName);

            dbRequest.onerror = (e) => {
              reject(Error("Couldn't open database."));
            };

            dbRequest.onupgradeneeded = (e) => {
              e.target.transaction.abort();
              reject(Error("Database version not found."));
            };

            dbRequest.onsuccess = (e) => {
              let database = e.target.result;
              let transaction = database.transaction([ _config.storeName ], 'readwrite');
              let objectStore = transaction.objectStore(_config.storeName);
              let objectRequest = objectStore.get(key);

              objectRequest.onerror = (e) => {
                reject(Error("Error while getting."));
              };

              objectRequest.onsuccess = (e) => {
                if (objectRequest.result) {
                  resolve(objectRequest.result);
                } else reject(Error("Key not found."));
              };
            };
          });
        }

        delete(key) {
          return new Promise((resolve, reject) => {
            let dbRequest = indexedDB.open(_config.dbName);

            dbRequest.onerror = (e) => {
              reject(Error("Couldn't open database."));
            };

            dbRequest.onupgradeneeded = (e) => {
              e.target.transaction.abort();
              reject(Error("Database version not found."));
            };

            dbRequest.onsuccess = (e) => {
              let database = e.target.result;
              let transaction = database.transaction([ _config.storeName ], 'readwrite');
              let objectStore = transaction.objectStore(_config.storeName);
              let objectRequest = objectStore.delete(key);

              objectRequest.onerror = (e) => {
                reject(Error("Couldn't delete key."));
              };

              objectRequest.onsuccess = (e) => {
                resolve("Deleted key successfully.");
              };
            };
          });
        }

        save(key, value) {
          return new Promise((resolve, reject) => {
            let dbRequest = indexedDB.open(dbConfig.dbName);

            dbRequest.onerror = (e) => {
              reject(Error("Couldn't open database."));
            };

            dbRequest.onupgradeneeded = (e) => {
              let database = e.target.result;
              let objectStore = database.createObjectStore(_config.storeName);
            };

            dbRequest.onsuccess = (e) => {
              let database = e.target.result;
              let transaction = database.transaction([ _config.storeName ], 'readwrite');
              let objectStore = transaction.objectStore(_config.storeName);
              let objectRequest = objectStore.put(value, key); // Overwrite if exists

              objectRequest.onerror = (e) => {
                reject(Error("Error while saving."));
              };

              objectRequest.onsuccess = (e) => {
                resolve("Saved data successfully.");
              };
            };
          });
        }
      }

To use it, all you'd have to do is create a new DB object and call the specified methods. For example:

      const db = new DB();

      db.save('testKey', 12)
        .then(() => {
          db.get('testKey').then(console.log); // -> prints "12"
        })

Some finishing touches

If you want to use it in another file, just add an export statement to the end:

      export default DB;

Then, import it in the new script (making sure everything supports modules), and call it:

      import DB from './db';

Then, use it as is.

As always, don't forget to follow me for more content like this. I'm currently writing on dev.to and Medium, and your support on either platform would be very much appreciated. I also have a membership set up, where you can get early previews of articles and exclusive access to a whole bunch of resources. Also, if you've particularly enjoyed this post, consider supporting me by buying me a coffee. Until next time!

JAVASCRIPT IRL: Examples of JavaScript's filter function in real life

Shailesh Vasandani — Thu, 14 Jan 2021 18:33:38 +0000

JavaScript array methods are super useful, and learning how to use them can really help improve the readability of your code. This is the third and final part of this series, and today I'll be discussing the filter function and how you can use it to make your code more concise. It's probably the easiest of the three to understand, since it's fairly straightforward, but it's always helpful to have examples on hand to understand exactly how it does and doesn't work.

Psst — don't have time to read through the entire article? Follow me on Instagram to get short, digestible posts on all things web development.

The filter function is called on an array and — like map — takes in one parameter: a callback. It performs this callback function on every element in the array, and includes the element in a new array if the callback returns true. Now, you might think that you can replicate this functionality without too much effort using map, but the key difference here is that map always returns an array with the same length as the original. (Well, almost always, but that's a bit more complicated and not really in the spirit of map to begin with.) On the other hand, filter will create an array that's only as large as the number of elements that pass the callback.

That may seem like a lot, but it honestly works just like you'd expect to. Let's take a look at a simple example:

A trivial example

Here, we add filter the array to only include all elements greater than 2:

      const arr = [1,2,3,4,5];
      const newarr = arr.filter(el => el > 2);

      console.log(newarr); // => [3,4,5]

The important thing to note here is that newarr is only of length 3; it doesn't return a null or undefined for the first two elements — it simply omits them entirely. We'll use this property to our advantage in the very next example.

Deleting caches (but properly this time)

If you've read my article on the map function, you'll recognize this example. However, it can still be improved: the null values that we returned could end up throwing an error later down the line. To avoid that, we're going to use filter to return an array that consists only of the elements that match the condition.

This is what it looks like:

      self.addEventListener('activate', e => {
        // Delete all caches that aren't named currentCache.
        e.waitUntil(
          caches.keys().then(cacheNames => {
            return Promise.all(cacheNames.filter(cacheName => {
              return cacheName !== currentCache;
            }).map(cacheName => {
              console.log('Deleting out of date cache:', cacheName);
              return caches.delete(cacheName);
            }));
          })
        );
      });

Again, very similar to the previous example. The key difference here is that before we map each cache to its delete function, we're filtering out all the caches that don't match our condition. That way, the currentCache won't appear in the array being passed to the map and thus we avoid any null values.

Let's look another example:

Filtering posts in a blog

On my blog page, I use a tagging system to allow users to filter content and view only the posts they're interested in. To do this, I actually created a JavaScript library called dynamic-tags. While creating it, I needed to find a way to take all of the posts on the page and only display the ones that matched the given filter.

While this could have devolved into a nasty mess of for loops and if statements, I used the filter function to make things both readable and efficient. Here's how it ended up:

      function filterPosts() {
        activePosts = posts;
        tagFilter.forEach(tag => {
          activePosts = activePosts.filter(post => tagDict[tag].includes(post));
        });
      }

Effectively three lines of code do much of the heavy lifting. In it, we go through each selected tag and call filter on activePosts to progressively remove any post that doesn't contain that tag. Even though filter might seem like a very minor abstraction over a plain for loop, we can see in this example just how concise and readable it makes your code.

Let's take a look at one final example:

Making things searchable

As an extension to the library I created above, I also wanted to create a system where users could search for topics and filter posts based on that. This is still a work in progress, but it already includes several useful examples of the filter function in action.

Let's take a look at my favorite one:

      populateSearchBox(el) {
        let searches = this.allTags.filter(tag => tag.toLowerCase().includes(el.childNodes[0].data.toLowerCase()));

        let searchBox = this.filter.querySelector(this.classListToSelector(this.searchBoxClass));
        if (searchBox) {
          searchBox.innerHTML = "";

          searches.forEach(search => {
            if (!this.tagFilter.includes(search)) this.addTagTo(search, searchBox, false);
          });
        }
      }

In this snippet, instead of filtering out posts, we're actually filtering out suggestions in the search box. Here, the filter function is used to ensure we're only appending suggestions that haven't already been selected. That is, we don't want a user to be filtering by topics that they've already filtered out.

The actual filter function is quite interesting — it looks for all the tags that contain the phrase inside the search bar. For example, given the tags ['May', 'June', 'July'], typing a 'y' into the search bar should return ['May', 'July']. On the other hand, typing 'J' should return ['June', 'July'].

Wrapping it up

And that's a wrap! I hope these examples gave you an idea of how the filter function is used in production, and how it can help make code more readable and versatile. Let me know in the comments if you've used the filter function in a cool way, and make sure to read the other two posts in the series if you haven't already!

JAVASCRIPT IRL: Examples of JavaScript's reduce function in real life

Shailesh Vasandani — Sun, 10 Jan 2021 19:00:23 +0000

JavaScript array methods are super useful, and learning how to use them can really help improve the readability of your code. This is the second part of a series on JavaScript array functions, where I dive into examples from real, production codebases. Today's function is reduce, which (for me at least) was the most abstract one of the three. By virtue of its abstractness, however, it's also the most powerful. In fact, it's possible to do the jobs of the other two using just reduce alone! (Even though you shouldn't. Definitely, absolutely, do not do this.)

Much like the map function, reduce is called on an array, and takes in two parameters: a callback, and an initial value. However, the callback looks a little different than the one in map — instead of taking one parameter, it takes two: an accumulator, and the current element. This gets to the very heart of the reduce function: starting with the initial value, it iterates over every element in the array, returning the result of the callback function as the accumulator to the next iteration of the loop. If that sounds confusing, don't worry. That's what the examples are for!

A trivial example

Before we get into code, I want to really drill down into what reduce does. An analogy that I found really helpful goes as follows:

Imagine a line (i.e. array) of people. You want to find the sum of their ages; that is, you want to reduce your array of people into a single number — their combined age. To do that, you'd probably use a calculator app and go down the line one person at a time, adding to your total as you go. That's exactly what the reduce function does — the initial value is 0, the accumulator is the running total in your calculator, and the current element is the person you're currently in front of.

With that in mind, let's see a simple example using the same sort of analogy:

      const arrayOfPeople = [
        {
          name: 'John Doe',
          age: 21
        },
        {
          name: 'Mary Sue',
          age: 34
        },
        {
          name: 'Gary Stu',
          age: 43
        }
      ];
      const combinedAge = arrayOfPeople.reduce((acc, curr) => acc + curr.age, 0);

      console.log(combinedAge); // => 98

To visualize how this works, use the same line of people analogy. Imagine you have a calculator, and you need to count the combined ages of these three people. You'd start off with 0 in your calculator — that's the initial value. Then you'd go up to John Doe, ask them their age, and add that to the value in your calculator. 0 plus 21 gives 21, so that's the running total so far. Then you'd go up to Mary Sue and ask them for their age. They say 34, so you add that to your calculator; 21 plus 34 gives 55, so now that's your running total. Finally, you'd go up to Gary Stu, ask them their age, and add that in. 55 plus 43 gives 98 — and that's exactly what reduce returns.

Now that we have that under our belt, let's look at some real-life examples:

Converting HTML nodes to strings

In this example, I was writing a feature for my blog that allowed the user to share a post to dev.to. I needed to select a bunch of tag elements on my page and convert them into a comma-separated string as part of the post frontmatter. This is the perfect use case for reduce; it takes an array of objects and squashes or reduces them down into a single value. Here's how I did it:

      const tagString = ` tags:${Array.from(document.querySelectorAll(".tags span.tag")).reduce((acc, curr) => { 
        return acc + (acc == "" ? "" : ", ") + curr.textContent;
      }, "")}` ;

Don't be fooled by the complicated looking ternary operator — it's only there to make sure that the first element doesn't have a comma before it. Otherwise, all the reduce function is doing is adding commas between the text contents of all of the tags.

Before we move on, a good question is why I couldn't use a function like join to do this. The answer is that you can't join an array of HTML nodes — you need to get their textContent property to see what they contain. What I could've done instead is map each element of the array to their textContent and then join them, but one method is much better than two. Hence, the reduce function. On an unrelated note, if you'd like to see some examples of the map function being used, be sure to check out my article.

With that said, let's look at another example:

Formatting comments

I recently implemented a comment section on my blog, and as part of that I wanted users to be able to apply basic formatting to their comments. This included bold, italics, code, and linebreaks. Because I didn't want to use any external libraries or parsers, however, I had to convert raw Markdown data into safe HTML elements. To do this, I needed to separate the input data by line, escape any HTML, and then run a custom Markdown converter on each line.

That seems like a lot, but it's the perfect job for a workhorse like reduce. I can perform the HTML escaping in the callback, and extract any useful code like the Markdown parsing to an external function. Here's what I ended up with:

      return body.split('\n').reduce((acc, curr) => {
        let text = document.createTextNode(curr);
        let p = document.createElement('p');
        p.appendChild(text);
        if (curr.trim().length === 0) return acc;
        return acc + (acc === "" ? "" : '</p><p class="comment-body">') + safeMarkdownToHTML(p.innerHTML);
      }, "");

The first few lines are just a way to leverage the browser's built-in HTML escaping with the createTextNode function. After that, I use a ternary operator (again!) to make sure that the first element doesn't have any unwanted content appended before it. Finally, I return the results of the (recursive) Markdown parsing function. While it may seem like a lot at first, by breaking it down into pieces, we can see how the final product is constructed. In this case, reduce serves as one tool among many to achieve this goal. By the way, let me know down in the comments if you'd like to see a post on parsing Markdown — it's a great introduction to recursion and string manipulation.

Let's take a look at one final example:

Making JavaScript effects accessible

On several pages on my website — my home page, blog page, and design page, for example — I use a typewriter effect as a bit of eye-candy. While cool-looking (I'm quite proud of the effect, to be honest), it's important to recognize that not everybody sees the internet in the same way. This effect in particular is quite inaccessible to people who use screen readers, so I had to find a way to convert the array of disparate words into one long phrase that could be read out via the aria-label attribute.

To do this concatenation, I once again reached for reduce. Because of the nature of the function, I was able to make a logical, grammatically correct sentence that would make sense when read out. Here's what that reduce function looked like in context:

      let t = new Typewriter(
        el, 
        el.dataset.speed, 
        el.dataset.pause, 
        JSON.parse(el.dataset.text), 
        [...new Set(JSON.parse(el.dataset.text))]
          .reduce((acc,curr) => acc + ", and " + curr.trim()), "")
      );

Super simple, super sweet — all I had to do was add ", and" between each element of the array. Again, I didn't end up using join because I had to call trim on each piece of text. Using reduce allows the array to be transformed and mutated while it's being collected, which is perfect for this use case. By the way, if you're interested in learning more about accessibility on the web, and in particular with JavaScript, be sure to subscribe to my mailing list — I'm going to have a lot of posts dedicated to the topic in the near to medium future.

Wrapping it up

I hope these examples gave you an idea of how the reduce function is really used in a codebase, and how it can help make code more readable and versatile. Let me know down in the comments if you have any interesting uses for the reduce function, and keep an eye out for the final post in the series!

JAVASCRIPT IRL: Examples of JavaScript's map function in real life

Shailesh Vasandani — Wed, 06 Jan 2021 17:08:14 +0000

JavaScript array methods are super useful, and learning how to use them can really help improve the readability of your code. However, since most developers start off with basic for loops and while loops, making the switch to more abstract constructions like map, reduce, and filter can be quite difficult. There are lots of posts describing these functions and giving examples, but very few actually compile a list of these being used in a real codebase. It's all well and good to see how you can increment every element of an array using map, but it's not so often that you'll actually be using that in a codebase.

This is going to be a small three-part series where I go over real-life examples of map, reduce, and filter. Let me know in the comments what you thought of this post and if you'd like me to change anything for the next two posts! Without further ado, here are some examples of map in a real production environment.

The map function is called on an array, and takes in one parameter: a callback. It performs this callback function on every element in the array, and returns a new array of the same length as the original. The value at each index in the new array is the result of the callback on the element at that index in the original array. Let's take a look at a trivial example before we dive in:

A trivial example

Okay, so I know I said you wouldn't be incrementing an array by 2 in a codebase, but(!) for the sake of posterity, I thought I might add it anyway:

      const arr = [1,2,3];
      const newarr = arr.map(el => el + 2);

      console.log(newarr); // => [3,4,5]

In this case, the callback returns the value of el + 2; the new array thus contains the elements of the old array but with 2 added to them.

Now let's look at some real-life examples:

Deleting caches with a service worker

In this example, the service worker for a webpage needs to delete any outdated caches. Because it uses Promises and asynchronous programming, the return value looks a little different. However, the concept of the map function remains the same:

      self.addEventListener('activate', function(event) {
        // Delete all caches that aren't named currentCache.
        event.waitUntil(
          caches.keys().then(cacheNames => {
            return Promise.all(
              cacheNames.map(cacheName => { // map function
                if (cacheName != currentCache) {
                  console.log('Deleting out of date cache:', cacheName);
                  return caches.delete(cacheName); // returns a callback to delete this cache
                }
              })
            );
          })
        );
      });

While the nested callbacks can make this look intimidating, we can see that the map function is actually super simple: if the cacheName is not equal to the currentCache, we return a callback that deletes the cache. Otherwise, we return null. Without the map function, we'd have to use a for loop and a temporary array, and push every element to the temporary array if it satisfied the condition.

Let's look another example:

Saving nested objects to local storage

As part of a What-You-See-Is-What-You-Get (WYSIWYG) editor that I've been making, I decided to store the actual data in local storage. If you're not sure what local storage is, it's a super useful storage API exposed at window.localStorage where you can set key-value pairs for retrieval at a later date. The only issue with this is that my content was wrapped in a data binding — a complicated structure, but suffice it to say that I had an array of Binding objects, and the content that I actually wanted to store was in the nested property Binding.boundobj.obj. This is the perfect use case for map:

      const saveToStorage = () => {
        localStorage.setItem(contentName, JSON.stringify(contentobj.map(binding => binding.boundobj.obj)));
      }

This is a super simple fix: instead of creating a complicated for loop where I push the nested property into a new array, I can create a one-liner just by using the map function to return the nested property for each element.

Let's take a look at one final example:

To create a table in React

This code snippet is taken from a React component designed to create a custom table with a heading row. You can see it in action at Terraling; scroll down to any of the Property tables to see how the headers are visually distinct from the table data. This is what some of the code to generate those tables looks like:

      <div className={`headers row row-${keys.length}`}>
        {
          headers.map((header, i) => {
            return (
              <span key={i} className="header name">{header}</span>
            )
          })
        }
      </div>

Since the header data is passed into the component via the array headers, I needed to transform each element from a string into an entire span element. While this can be done with a for loop, using the map construction allows for more readable and concise code. Anyone who reads the code is better able to understand what happens to each element in the headers array.

Wrapping it up

I hope these examples gave you an idea of how the map function is really used in a codebase, and how it can help make code more readable and concise. It truly is a versatile construction, and I highly recommend getting familiar with it by using it in your own code. Let me know down in the comments if you have any interesting uses for the map function, and keep an eye out for the next two posts in the series!

Microblog: adding estimated reading time to my blog posts

Shailesh Vasandani — Sat, 02 Jan 2021 16:58:33 +0000

Blogs that show an estimated reading time can get upwards of 400% increased click-through rates. Since I roll my own stack for my statically built blog posts, I thought it would be a fun exercise to try and add this useful metric to my blog page.

The stack

In general, HTML templaters are designed to take custom data and merge them with predefined templates. My current blog post templating setup is a single Java program which uses almost Markdown-like syntax to insert content into a prewritten HTML file. I won't go into the details too much, but suffice it to say that it regenerates both the blog posts and any internal links — for example, the "Recommended Posts" section at the bottom. Let me know in the comments if you'd like to see a post on how I made my own templating system!

Aside from each blog post, it also generates a JSON file that my blog page taps into to show the post previews. By doing this, I can effectively have a purely static site that is as responsive as something like a WordPress site. Overall, the stack consists of Java as the site generator, and HTML, CSS, and JavaScript as the frontend technologies.

Getting the actual numbers

Calculating reading time is supposedly quite simple — just take the number of words in your article, and divide by the average reading speed of approximately 265 words. When it comes to blogs with code, however, this number can change dramatically. If the code is very dense, even a few words can take a minute or two. Excessively verbose code, however, can just be skimmed over. I decided that I would simply count the code by line, assigning the equivalent of about 1 line per word.

That may seem very little, but remember that code often has lots of lines containing no more than a single character, and also since I try to write my code to be readable and atomic; that is, each line should be short, sweet, and understandable. In addition, I decided to reduce the target speed from 265 to 200, solely because the number seems a lot nicer. Why not 250, you ask? I don't know. Arbitrary numbers in hand, the formula to calculate reading time is pretty simple:

      readingTime = (numWords + linesOfCode) / 200;

Code is never so simple, is it

While it would be super useful to simply plop that formula in the Java file somewhere and have everything work, that would be far too easy. You see, I wrote my Java templating program with the goal of extracting repeated code and making functions testable. To this end, I have lots of functions that each do one thing and then call other functions, passing along any necessary variables as parameters and eventually returning the template String that becomes the final product.

Since Java can only return one value (excluding using arrays to return multiple), any other information that needs to be returned needs to be passed in as an argument and changed inside the inner function. However, ints in Java are passed-by-value (well technically everything is, but we conveniently ignore that). This means that I can't simply pass in a pointer to a wordCount variable and update it inside the inner function, like I might be able to in C. So we're stuck in a rut — how do we get out?

Enter the hackiest solution I've probably ever done so far. Instead of passing an int into a function, I'm passing in an int array of length 1. Java passes this reference along, and I'm able to change the value of the first element in this single element array, bubbling up this value to the outer function. Because I have about three or so layers of nesting, my functions look a little like this:

      public String buildHTML(String filename) {
        // ...
        int[] wordCount = new int[1]; // pass by "reference"
        String content = buildContent(fileScanner, wordCount);

        readingTime = wordCount[0] / 200;

        // ...
      }

      public String buildContent(Scanner fileScanner, int[] wordCount) {
        // ...
        else if (lineArray[0].toUpperCase().equals("P")) {
          content += buildParagraph(lineArray[1], wordCount);
        } else if (lineArray[0].toUpperCase().equals("CODE")) {
           content += buildCode(fileScanner, wordCount);
        }

        // ...
      }

      public String buildParagraph(String pData, int[] wordCount) {
        // ...
        wordCount[0] += content.split(" ").length; // actually setting the data

        //...
      }

      public String buildCode(Scanner fileScanner, int[] wordCount) {
        // ...
        while (fileScanner.hasNextLine()) {
          wordCount[0]++; // one "word" per line

          // ...
        }

        // ...
      }

As you can see, we're successfully able to pass that value down the chain and read it when it comes back. Not bad for a pass-by-value language like Java. To see the end result, take a look at my blog page and look at the top of any of the posts.

I hope that hearing about how I added this feature helped inspire you to tackle some annoying bug or implement an interesting feature idea you have. Let me know down in the comments if you've ever had to pull a hacky fix like I have just to fix one super tiny thing!

How I landed my first tech internship (and how you can too)

Shailesh Vasandani — Mon, 28 Dec 2020 18:48:54 +0000

I think by now everyone with a LinkedIn account has seen at least one post announcing an internship or job offer. For people who've been searching for ages and sending out resumes into what seems like a bottomless void, these posts can seem like a slap in the face. But no longer — today, I'll be talking about my experience applying for a job internship, and how you can take actionable steps to increase your chances of getting an offer too.

Every post I've seen so far that talks about getting an internship (and I've seen many) have always said the same things: code up some projects, don't get discouraged, write a good resume, prep for interviews, so on, so on. I think we all now these tips by now, and this post is more about what else you can do. Of course all these things are important, but there are a lot of factors that can affect one's ability to, say, code projects: low motivation, too little free time, or even just a lack of good ideas. (With respect to that last one, keep an eye out for a post I'll be writing in the future about some good project ideas that aren't just clones of already existing apps.)

So, what can you do to improve your chances? Let's find out:

Find someone who knows that they're doing

While it's possible to have a long and successful career without ever having a mentor, there's a reason this type of professional relationship is so popular. Mentors don't just help with what you're doing now, they also serve as a useful guide for what your future may be. Many mentors are themselves professional working software engineers, so they can also prove to be useful initial points of contact in the professional world. You've all heard about networking — having a mentor is your chance to tap into a useful subgraph (get it) of contacts. If your mentor is well-respected, and they can vouch for your ability, you may even be able to get into direct contact with recruiters, which bodes very well for your chances of at least landing an interview.

That's all well and good, but how might you even go about finding a mentor? It's easier than you think. For students at universities, a significant portion of your tuition is about the network and the contacts you build. Reach out to professors and ask if they know any past students looking for mentorship opportunities. Even if they aren't explicitly looking to be mentors, many will jump at the chance to pass on their knowledge and help a younger student break into the professional scene. Aside from professors, look to your peers, and don't be afraid to ask. Send lots of cold emails — some people won't ever respond, but you only need one good response to make it all worthwhile.

For people outside of universities, but in bootcamps or similar programs — ask your instructors. They may not be able to mentor you, but they very well may know people who will. If your program brings in guest instructors for certain sections, speak to them to, and cold email if you have to. The anxiety that comes with cold emailing might be crushing, but people reply more than you'd expect, and again — you only need one.

Finally, for people with no program or university to rely on, it may seem like finding a mentor may be impossible. This is not the case. You'll probably get more unopened emails and rejected opportunities, but in the age of the internet, you can definitely still find an engineer or senior figure willing to share knowledge with you. Find a coding blog you like and reach out. Email the instructor of a coding course you enjoyed. If you're genuine about your interest and can show that you really engaged with what people have to say, they're usually more than willing to help. Even if they can't be your mentor, they can definitely point you in the right direction.

As a student at university, it was definitely easier for me to find a mentor; I met mine through a research professor that I reached out to via a cold email. Keep in mind I was only a sophomore at the time, and had just barely taken a class on Data Structures. Because the professor could tell I was truly interested in the subject, he reached out to a former student and professional engineer, who gladly accepted me as a mentee. On that note, another way you can increase your odds:

Projects are good, collaborative projects are better

Need I say more? We all know the importance of contributing to open source, but even if it doesn't go that far, try finding a partner or group to make a project with — almost every useful project online is the result of many ideas and contributions. Nobody can master everything, but by working together, you reduce the number of bases you need to cover.

This advice extends to research groups too. This largely applies to university students only, but if you get the chance to conduct research or development with a team, don't hesitate to take it. Your part might be as simple as writing a small program to clean up some data, but: a) you can list the entire project that you contributed to on your resume, b) you can develop some team-based skills, and c) you can possibly find contacts for your network in that team.

If you're not a university student, don't worry. Maybe you don't have access to research opportunities, but reach out to fellow developers (either through Github, Twitter, your bootcamp) and see what they're building. Any contribution is a meaningful contribution, and essentially all widely-used pieces of software were written by a large team of people, not just one developer.

Working on a team is all well and good, but what can you do by yourself to stand out? Well, that's what the third and final tip in this post is for.

Maintain an online presence

Chances are, you're going to need to put your website or your email on your resume. Perhaps the recruiter will click on these links, perhaps not. What is significant is how these links look, and how you present yourself on the internet. It's a very good idea to have some sort of presence — that can be as simple as a single-page portfolio, to a full on website with a blog and some other good stuff (e.g. what I'm attempting to do with my blog). Whatever the case, spend some time doing up your virtual face. After all, websites are essentially ubiquitous, and if you're not too familiar with how they're made, learning about static web development can help your resume both in the skills department and the projects department.

This tip is one where you can engage with it as much as you have the energy and time to. Having a simple website is good. Having a custom domain (I'm quite proud of mine, which is literally my name) is even better. Having a blog presence can take you further still. No matter how far you choose to take it, make sure to nail the fundamentals. Take advantage of semantic HTML. Always design for accessibility. Use SSL. Make sure everything works on mobile and desktop. Use responsive images. By nailing these, you're showing the recruiter and anyone else who sees you on the web that you care, and that you're willing to dedicate the time to really get the details right.

How did I use these tips to get a tech internship?

I was offered an internship position for Summer 2021 after applying to several dozen companies — I only ever received interview offers from a handful. The reason I even got those, however, was due to the tips I just outlined. My mentor helped proofread my resume and cover letters and, when I was offered interviews, helped me prep for those as well. If I ever had any questions about how to approach a recruiter about an issue, he helped me with advice. Without a mentorship figure, I never would've known how to react to different situations.

Another significant reason for my offer was the extensive experience I had working on different teams. Sure, I had a few individual projects, but by showing recruiters and interviewers that I had experience working on teams on larger projects, I signaled to them that I would be a good fit for their programs. It also didn't hurt that I had more projects on my resume; even if I didn't build every single one from scratch, I still contributed meaningfully to each of them. Like I said before, software is almost always built by a team working together, not a superpowered developer writing thousands of lines a day.

Lastly, and perhaps the most evident, is the online presence I've slowly been curating. My website is simple, but it's fairly polished, and I'm not ashamed to display it on my resume and across my online accounts. With the tech blog alongside it, I'm also signaling to any interested recruiters that I'm truly passionate about what I do. I can't say for sure how much this helped, but I'm almost certain it had some positive influence on my chances.

And that's a wrap!

Let's go over all those tips really quickly just to wrap up:

Tip 1: Find a mentor or a mentorship figure who has experience in the field.

Tip 2: Work on projects with people, and learn to work well in a team.

Tip 3: Maintain a strong online presence with a strong focus on the fundamentals.

I hope that some of these tips were useful, and made you think a little differently about how to approach the tireless business that is applying for internships. Do you have any other unusual tips for getting ahead in the internship race? Let me know in the comments. If you're still searching though - and I'm sure you've heard this advice lots - try not to get too demotivated. You're doing great. You're still on track. You've got this.

Microblog: using closures to create JavaScript factories

Shailesh Vasandani — Fri, 25 Dec 2020 18:49:03 +0000

Hi everyone! In today's Microblog post, we'll be looking at JavaScript closures and how you can use them to make factories.

First, though — why learn about this technique? Well, even though many people dive straight into frameworks like React and Angular, it's always good to understand the fundamental vanilla JavaScript underlying those frameworks. As a result, you'll be able to do more both with and without the frameworks supporting you. Now, onto closures:

What are closures?

Good question. At their core, closures are simply an enclosed scope inside a function. They allow an inner function to access the variables in an outer function. A super simple example would look something like this:

      const addTo = (numberOne) => {
        return (numberTwo) => {
          return numberOne + numberTwo;
        }
      }

      const addToFive = addTo(5);
      const addToTen = addTo(10);

      addtoFive(3); // => 8
      addToTen(3); // => 13

When the addTo function is called with a parameter, it returns another function that has access to the numberOne variable; this returned function is the closure. Both addToFive and addToTen each have their own unique scope, where the variable numberOne equals 5 and 10 respectively. As a result, when calling those functions with 3 as a parameter, they give the expected results of 8 and 13. Now, onto factories:

What are factories?

Factories are generally used in testing to create objects without creating the full object declaration inline. A simple example might look this:

      /* User {
        {string} firstName
        {string} lastName
        {number} age
      }
      const createUser = (userObj) => {
        // create mock user
        let user = {
          firstName: "John",
          lastName: "Doe",
          age: 21
        };

        Object.keys(user).forEach((userKey) => {

        });

        return user;
      }

This allows us to scope our testing to be more relevant to the tests we perform.

      // WITHOUT FACTORY
      const returnsFalseForMinors = () => {
        // irrelevant data in test
        let user = { firstName: "John", lastName: "Doe", age: 17 });

        console.assert(functionToTest(user), false);
      }

      // WITH FACTORY
      const returnsFalseForMinors = () => {
        let user = createUser({ age: 17 });

        console.assert(functionToTest(user), false);
      }

Factories and closures, together?

When we use factories together with closures, we're able to dynamically generate useful functions that don't have to take too many parameters. Here's an example from the codebase for my photography page, where I needed to add and remove different classes for large amounts of objects:

      // closure and factories, working together
      const removeAndAdd = (remove, add) => {
        return (el) => { 
          el.classList.remove(remove);
          el.classList.add(add);
        }
      }

      // methods generated by the factory for use later
      const leftToCenter = removeAndAdd("left", "center");
      const centerToRight = removeAndAdd("center", "right");
      const rightToCenter = removeAndAdd("right", "center");
      const centerToLeft = removeAndAdd("center", "left");

      // ...

      const movePrev = () => {
        if (currentIndex <= 0) return;
        else {
          centerToRight(images[currentIndex]);
          leftToCenter(images[--currentIndex]); // decrement inline
          labelText.innerHTML = (currentIndex + 1) + "/" + numImages;
          labelTitle.innerHTML = altText[currentIndex];
        }
      }

      const moveNext = () => {
        if (currentIndex + 1 >= numImages) return;
        else {
          centerToLeft(images[currentIndex]);
          rightToCenter(images[++currentIndex]); // increment inline
          labelText.innerHTML = (currentIndex + 1) + "/" + numImages;
          labelTitle.innerHTML = altText[currentIndex];
        }
      }

As you can see, by using a closure as a function factory, I was able to avoid repeating calls to each element's classList, making my code more readable and semantic in the process.

I hope this short post gives you an idea of the power of closures in JavaScript, and I'm hoping to make a longer post further down the line detailing the most powerful ways these can be used. Make sure to follow me to be notified when that post drops.

If you found this post useful, please consider buying me a coffee. Until next time!

Microblog: creating interactive and semantic toggleable CSS buttons

Shailesh Vasandani — Wed, 16 Dec 2020 21:27:57 +0000

Hello everyone! As part of this new series, I'll be delivering some short and sweet tips and tricks about random things throughout the website — ranging from a unique visual interaction, to a nice bit of JavaScript code, to anywhere in between. Hopefully this also means that I'll be able to write a bit more frequently, so keep an eye out of those posts over the next few months!

Toggle time

Today, we'll be looking at the toggleable tags on my website, which as you may have noticed (or not), have changed somewhat in the past few days. Instead of boring hover states whose background color fades in and out, they now peek out from the bottom and fly up when they're toggled. While this effect is super simple for a normal link, making it toggleable posed a fair few challenges.

Some of these challenges included buggy animations, since toggling a tag would lead directly from an :active CSS state to a :hover state, and some issues were also caused by JavaScript updating elements or redrawing the DOM nodes. I solved most of these challenges by using two pseudo-elements instead of one, but enough talking — let's look at some CSS!

      .tag {
        position: relative;
        border: 1px solid var(--text);
        padding: 0.5em;
        margin: 0.2em;
        transition: 0.1s linear;
      }

      .tag:after {
        content: '';
        position: absolute;
        background: var(--text);
        opacity: 1;
        z-index: -1;
        bottom: 0px;
        left: 0px;
        width: 100%;
        height: 0px;
        transition: none;
      }

      .tag:before {
        content: '';
        position: absolute;
        background: var(--text);
        opacity: 0;
        z-index: -1;
        top: 0px;
        left: 0px;
        width: 100%;
        height: 0px;
        transition: none;
      }

Here we have the styling for each tag, along with their respective pseudo-elements. So far so good.

      .tag:hover {
        cursor: pointer;
        transition: 0.1s linear;
      }

      .tag:not(.active):hover:after {
        height: 3px;
        opacity: 1;
        transition: 0.1s linear;
      }

      .tag:not(.active):hover:before {
        height: 100%;
        opacity: 0;
        transition: none;
      }

Now when we hover over a tag that's not active, we use the :after pseudo-element to create that nice peeking effect. The :before element here stretches up to fill the tag, but has its opacity set to 0, so we can't see it anyway. Now for the part that makes it all work smoothly: the :active state:

      .tag:active {
        color: var(--bg);
        transition: 0.1s linear;
      }

      .tag:not(.active):active:after {
        height: 100%;
        opacity: 1;
        transition: 0.1s linear;
      }

      .tag:not(.active):active:before {
        height: 100%;
        opacity: 0;
        transition: none;
      }

But wait! How is it both :active and :not(.active)? Well, the :active state occurs when a user presses down on the button. In this case, the :after pseudo-element fills up the entire tag, giving it a solid background. The :before pseudo-element remains the same, but that's all about to change:

      .tag.active {
        color: var(--bg)
      }

      .tag.active:after {
        height: 0px;
        opacity: 0;
        transition: none;
      }

      .tag.active:before {
        height: 100%;
        opacity: 1;
        transition: none;
      }

Assuming the user let go of the mouse while clicking on the tag, the :after pseudo-element immediately shrinks back down to 0 height, and the :before pseudo-element immediately takes its place. The user shouldn't notice anything happen though, because we've been matching the :before pseudo-element to the :after for some time now. Now we repeat the whole process, but in reverse:

      .tag.active:hover:after {
        height: 0px;
        opacity: 0;
        transition: none;
      }

      .tag.active:hover:before {
        height: calc(100% - 3px);
        opacity: 1;
        transition: 0.1s linear;
        transition-property: height;
      }

Since the :before pseudo-element is aligned to the top, we need to use CSS calc() to get the right height. The effect we get here is almost like an inverted version of the original, but actually there's no inversion at all, just some fancy pseudo-element usage. Last but not least, let's take a look at what happens when an active tag is clicked:

      .tag.active:active {
        color: var(--text);
      }

      .tag.active:active:after {
        height: 0px;
        opacity: 1;
        transition: none;
      }

      .tag.active:active:before {
        height: 0px;
        opacity: 1;
        transition: 0.1s linear;
      }

That's right, we now have an .active:active selector. A bit confusing, but unfortunately I was too lazy to rename the active class. With this set of styles, the :before pseudo-element rises up, giving the impression that the negative space on the bottom is sliding up to cover the tag.

That's all for today! I hope you enjoyed this slightly shorter format, and maybe even learned a trick or too. Perhaps one day down the line I'll write a post explaining more of the styling behind my website, but right now I think staying short and sweet is my best bet. Be sure to take a look at the post on my website, and until next time!

My experience doing coding interviews in the age of Zoom

Shailesh Vasandani — Sun, 13 Dec 2020 05:26:01 +0000

I've never been one for interviews. Even when I was younger - especially when I was younger - I always dreaded the idea of talking to people, being questioned and cross-examined for what seemed like hours. Then again, I knew even less when I was younger than I do now, and it's often easier to talk about things one knows than things in general. In this blog post, I'll be talking about my experience doing a spate of online coding interviews, what sort of questions they asked, and some tips for acing your own interviews. Let's dive in!

Generic applicant #133412

Even getting to the interview stage feels like quite the accomplishment. In today's software engineering market, it can often feel like we're throwing resumes and cover letters out into the void, waiting and then eventually forgetting about emails that will never arrive. I am no coding prodigy, and I am very far removed from the stories of talented engineers applying to 15 ultra-prestigious companies (FAANG? big-N? unicorns?) and getting interviews with all of them. I've come to realize, however, that while there is a certain prestige to being employed at Google or Facebook or Amazon, even getting an interview at all is a significant achievement.

Software engineers get paid well, and our skills are highly desirable across the entire market. Short of something disastrous like the internet being obliterated, or worse, WordPress becoming easy to use, software engineers will always be in demand. However, with the proliferation of bootcamps and online courses, there are millions of extremely talented and proficient coders who are all vying for the same few spots. Getting your foot in the door already puts you near the top of the pile, and is definitely something worth celebrating.

What the interview process (might) look like

A foot in the door is important, but even more important is nailing the subsequent interview. I had the opportunity to take part in two onsite interviews, and both were unique and challenging in their own ways. I want to go over one of the questions I was asked, and since for most companies you're able to choose the language you'd like to use, I'll be describing my solutions in ES6 JavaScript. The task in this instance was to create a Least-Recently-Used cache, with a statically set size, supporting just two operations: set(Key k, Value v), and get(Key k).

Before we jump into the code, let's go over what an LRU Cache is meant to be. It functions very similarly to a hashtable or Map() in JavaScript, except it has a fixed size and only stores the keys that have been used the most recently (hence the name), evicting the older keys as necessary. Depending on your coding background, you might implement this data structure using Object-Oriented Programming or not; I chose to use the OOP paradigm. Let's dive in to the skeleton of the code:

      class LRUCache {
        constructor(size) {
          this.size = size;
          // more to add here
        }

        set(key, value) {
          // TODO
        }

        get(key) {
          // TODO
        }
      }

      // main
      let c = new LRUCache(3);

      c.set(1, 1); // => cache should look like [{1=1}, {}, {}]
      c.set(2, 2); // => cache should look like [{2=2}, {1=1}, {}]
      c.set(3, 3); // => cache should look like [{3=3}, {2=2}, {1=1}]
      c.set(4, 4); // => cache should look like [{4=4}, {3=3}, {2=2}]

      c.get(3); // => "3", cache should look like [{3=3}, {4=4}, {2=2}]
      c.get(1); // => "-1" or null

Thanks to ES6, we're finally able to use intrinsic class declarations in JavaScript. Before we go into the LRUCache class, let's look at some of the other code we've set up. Right below the class, we've declared a quick test to ensure that we understand how the cache is supposed to work. How horrible it would be to spend the better part of 30 minutes coding up the class only to find out that you misunderstood it from the beginning! By writing out expected behavior like this, you get two benefits: you can double check with the interviewer that you understand the problem correctly, and you have a very simple test ready to go before you even write any application code. With that, you have my very first tip:

Tip 1: Tests before code. Talk through an example run of the program or data structure with your interviewer, and write it down. They are there to help you, and want to see you succeed. Take advantage of that, and use them as a sounding board to see if you've overlooked anything.

Now that we have our mini test example set up, let's actually consider how we're going to implement this data structure. In terms of efficiency, we're aiming for O(1) time for both operations. It is easy to see that simply getting and setting the values in a Map will take O(1) time, but what we really need to be concerned with is all the extra stuff that comes with a cache. Specifically, how are we going to evict and update the cache in constant time?

The most semantic way to do this would probably be some sort of queue. It makes sense — the first value we set is likely the first one evicted (assuming no extraneous gets), which suits a queue's FIFO structure. The only issue with this implementation is that a queue only has pointers going in one direction, so if we need to find the node before a given node, that will take O(n) time.

To remedy this, we can make one minor modification, and use a doubly linked list instead of a queue. The general idea is the same, except that you can get both previous and next pointers in a doubly linked list in O(1) time. To implement this, let's make a new class representing a node on this linked list:

      class Node {
        constructor(value, prev, next) {
          this.value = value;
          this.prev = prev;
          this.next = next;
        }
      }

Super simple, and if you're familiar with linked lists you should recognize the general syntax: the value of the node, and the two pointers in either direction. Now that we have this, however, we need to use it. This also brings us to our second tip:

Tip 2: Complexity to code, not vice versa. If you know your data structures (and you should), you'll have a general idea of the complexities generally associated with each of them. As you get exposed to more complex code, you'll also have an intuition for what the best complexities you can obtain for a specific problem will be. Use this to your advantage — if you need to find items in O(1) time, you're going to need a hashtable. Need the minimum in constant time? Min-heap. These associations will become the building blocks of your programming.

That said, a common way of using node-based linked lists is to have a pointer pointing towards the head of the linked list, but in this case, both ends of the list are important to us. As a result, we'll be using pointers to both the head, and the tail of the linked list. Let's add those, along with our hashtable, to our cache constructor.

      constructor(size) {
        this.size = size;
        this.map = new Map();
        this.head = null;
        this.tail = null;
        this.stored = 0;
      }

I also added a new variable called stored to help us keep track of how many keys we have stored in the cache. That way, we can avoid having to count every element in the hashtable each time. That brings us to our third tip:

Tip 3: Lose space to gain on time. Space is very, very cheap compared to processing cycles. In the correct context, a hashtable will almost always be more cost-effective than a simple array, because spending O(n) time searching for items costs significantly more than the extra space required for a hashtable. Space is almost always the cheaper alternative, so when you can, sacrifice space to get a faster algorithm.

Now that we have all our properties set up, all we have to do is implement the methods themselves. Let's start with the set() method, since we know that we'll need to set something before even considering getting anything. We know that if our cache is empty, stored === 0, and all we have to do is make a new node and set our head and tail pointers:

      set(key, value) {
        if (stored === 0) {
          // first object that we will be storing
          let node = new Node(value, null, null);

          // set doubly linked list
          this.head = node
          this.tail = node;

          // set in Map for O(1) retrieval
          this.map.set(key, node);

          this.stored++;
        } else {
          // TODO
        }
      }

If stored isn't 0, though, we need to check if it's a value that already exists in the cache, or one that we'll have to add. If it's the former, we're going to have to update it to be at the tail of the list (i.e. the last to be evicted). This is because of the intrinsic property of an LRU cache, where any key that is recently used needs to be moved to the back of the queue. To do that, we can simply excise it from the list and append it to the end:

      else {
        if (this.map.has(key)) {
          // we can set key as most recently used if it's already in the cache
          this.map.get(key).value = value; // update value

          if (this.stored === 1) return; // if only one object
          else {
            if (this.map.get(key) === this.tail) return; // if already MRU
            else if (this.map.get(key) === this.head) {
              // special case if it is the head
              this.head.prev = this.tail; // now it is circular

              this.head = this.head.next;
              this.head.prev = null;

              this.tail = this.tail.next;
            } else {
              // general case
              let node = this.map.get(key);

              // slice node out of order
              node.next.prev = node.prev;
              node.prev.next = node.next;

              // set node's pointers
              node.next = null;
              node.prev = this.tail;

              // put node at tail
              this.tail.next = node;
              this.tail = node;
            }
          }
        } else {
          // TODO
        }
      }

This is a lot to take in, but it really is just verbose code. First, note that we can use the has() method of the JavaScript Map in our conditional. Then, if the key is already at the end, we don't have to do anything more. However, if it isn't at the end, we need to move it there. This is a bit easier if it is currently the head, since we can link the two together to form a circular queue. We can then simply shift the head and tail pointers, and null any other pointers that need to be null, and we're in business. On the other hand, if it is not the head, we do the more traditional operation of setting previous pointers to the previous node, and next pointers to the next node. Finally, we append it to the end and set the tail node accordingly.

If this part is a little confusing, take the time to sit with the code and understand it. Reason through it out loud. In an interview environment, talk to your interviewer about what you're trying to do, and then try to do it. This, incidentally, is my fourth tip:

Tip 4: Words can speak louder than actions. Talking is extremely important. A coding interview is a chance for the interviewer to see what you'd be like on their team, and if there's one thing that facilitates working on a team, it's communication. If you're not sure how to implement some code, but you have an idea in your head, talk it through. Your interviewer will be there to help you, and you get the bonus of being able to show them that you know how to communicate both in code and outside of it.

Now that we've got that sorted, we need to take care of the situation where we're adding a new value to the cache when there are already values there. There are two possibilities here: if there's still empty space in the cache (i.e. this.stored < this.size), and when the cache is full and we need to evict. Let's take a look at both of these:

      else {
        // if it's not in the cache, we have a few conditions
        if (stored < this.size) {
          // add to the Map freely
          let node = new Node(value, null, null);

          // we have at least one node in the doubly linked list
          this.tail.next = node;
          this.tail = node;

          // set in Map for O(1) retrieval
          this.map.set(key, node);

          this.stored++;
        } else {
          // eviction time
          this.head = this.head.next;
          this.head.prev = null;

          // set in Map for O(1) retrieval
          this.map.set(key, node);

          let node = new Node(value, this.tail, null);
          this.tail = node;
        }
      }

Surprisingly, the case where we have to evict is just as short as the one where we have to add new nodes. This is because the structure of our program allows us to evict in constant time, simply removing the head and shifting all the nodes down. When we're adding new nodes to the end, we do something similar, but instead of shifting the nodes down we simply append to the end.

Now that we're through the set() method, let's take a look at the get() method. When getting a value, we obviously need to return the value, but we also need to move the key to the tail of the queue. Sound familiar? That's because it is. We can extract that logic to a function and save ourself a lot of work, which brings us to our fifth and final tip:

Tip 5: Code like you would in the real world. It's easy to say, and harder to do. However, if you usually feel comfortable extracting logic to smaller testable units — all power to you. If you don't usually do that and have a more procedural style, code that way in the interviews. You're not going to be able to fool the interviewer by coding in a neater or more understandable style than you do normally, so don't let it be a stumbling block. Code the way you normally do, and embrace your code.

I like to code by avoiding repeated logic, and extracting lots of things to functions. Here's what the logic looks like extracted to a function called setMRU(), where MRU means Most Recently Used:

      setMRU(key) {
        if (this.stored === 1) return; // if only one object
        else {
          if (this.map.get(key) === this.tail) return; // if already MRU
          else if (this.map.get(key) === this.head) {
            // special case if it is the head
            this.head.prev = this.tail; // now it is circular

            this.head = this.head.next;
            this.head.prev = null;

            this.tail = this.tail.next;
          } else {
            // general case
            let node = this.map.get(key);

            // slice node out of order
            node.next.prev = node.prev;
            node.prev.next = node.next;

            // set node's pointers
            node.next = null;
            node.prev = this.tail;

            // put node at tail
            this.tail.next = node;
            this.tail = node;
          }
        }
      }

You've seen all this before, so now let's take a look at the get() method and see how simple that is now:

      get(key) {
        // first, set the node to MRU
        setMRU(key);

        return this.map.get(key).value;
      }

And that's it! We've successfully coded an LRU cache, all in ES6 JavaScript, that performs super fast. Before we wrap up, a once over of the 5 tips:

Tip 1: Tests before code.

Tip 2: Complexity to code, not vice versa.

Tip 3: Lose space to gain on time.

Tip 4: Words can speak louder than actions.

Tip 5: Code like you would in the real world.

And finally, just to recap, this is the final solution we arrived at for the LRU cache problem:

      class Node {
        constructor(value, prev, next) {
          this.value = value;
          this.prev = prev;
          this.next = next;
        }
      }

      class LRUCache {
        constructor(size) {
          this.size = size;
          this.map = new Map();
          this.head = null;
          this.tail = null;
          this.stored = 0;
        }

        set(key, value) {
          if (stored === 0) {
            // first object that we will be storing
            let node = new Node(value, null, null);

            // set doubly linked list
            this.head = node
            this.tail = node;

            // set in Map for O(1) retrieval
            this.map.set(key, node);

            this.stored++;
          } else {
            if (this.map.has(key)) {
              // we can set key as most recently used if it's already in the cache
              this.map.get(key).value = value; // update value

              setMRU(key);
            } else {
              // if it's not in the cache, we have a few conditions
              if (stored < this.size) {
                // add to the Map freely
                let node = new Node(value, null, null);

                // we have at least one node in the doubly linked list
                this.tail.next = node;
                this.tail = node;

                // set in Map for O(1) retrieval
                this.map.set(key, node);

                this.stored++;
              } else {
                // eviction time
                this.head = this.head.next;
                this.head.prev = null;

                // set in Map for O(1) retrieval
                this.map.set(key, node);

                let node = new Node(value, this.tail, null);
                this.tail = node;
              }
            }
          }
        }

        get(key) {
          // first, set the node to MRU
          setMRU(key);

          return this.map.get(key).value;
        }

        setMRU(key) {
          if (this.stored === 1) return; // if only one object
          else {
            if (this.map.get(key) === this.tail) return; // if already MRU
            else if (this.map.get(key) === this.head) {
              // special case if it is the head
              this.head.prev = this.tail; // now it is circular

              this.head = this.head.next;
              this.head.prev = null;

              this.tail = this.tail.next;
            } else {
              // general case
              let node = this.map.get(key);

              // slice node out of order
              node.next.prev = node.prev;
              node.prev.next = node.next;

              // set node's pointers
              node.next = null;
              node.prev = this.tail;

              // put node at tail
              this.tail.next = node;
              this.tail = node;
            }
          }
        }
      }

      // main
      let c = new LRUCache(3);

      c.set(1, 1); // => cache should look like [{1=1}, {}, {}]
      c.set(2, 2); // => cache should look like [{2=2}, {1=1}, {}]
      c.set(3, 3); // => cache should look like [{3=3}, {2=2}, {1=1}]
      c.set(4, 4); // => cache should look like [{4=4}, {3=3}, {2=2}]

      c.get(3); // => "3", cache should look like [{3=3}, {4=4}, {2=2}]
      c.get(1); // => "-1" or null

That's all for today, folks! I hope my experience helped you out even a little, seeing what the coding interview experience was like in the era of Zoom and remote learning. Good luck out there, and be sure to take a look at the rest of my blog!