DEV Community: Aleksandr Hovhannisyan

What Are Higher-Order Components in React?

Aleksandr Hovhannisyan — Thu, 29 Oct 2020 20:34:58 +0000

If you're new to React, or even if you've been using it for a while, you may have heard about these things called higher-order components (HOCs), and shuddered at the apparent complexity of the term. It certainly sounds like something fancy that's beyond a beginner's comprehension. But that's not the case at all—the truth is that higher-order components in React are a very intuitive (and powerful!) design pattern.

In this tutorial, we'll explore what higher-order components are and why you might want to use them. We'll also learn how you can combine them with the React Context API to create reusable components and behaviors. Let's dig in!

Prerequisite Terminology
What Are Higher-Order Components?
Example of Higher-Order Components
- Creating Reusable Stateful Logic with Higher-Order Components
Higher-Order Components and the Power of Composition
Higher-Order Components vs. Wrapper Components
Using Higher-Order Components with the React Context API

Prerequisite Terminology

As a super-quick refresher, note that a React component is just a function that returns a React element:

// This is a component
function Component(props) {
  return React.createElement("img", {
    className: "img",
    width: 1000
  });
}

// This is basically the same component but using JSX
function Component(props) {
  return <img className="image" width={1000} />;
}

That's all you really need to know before moving on.

What Are Higher-Order Components?

Simply put, a higher-order component is a function that returns a component. At the end of the day, it's just a function, like any other that you're used to working with by now in JavaScript and other languages.

To go a bit more into detail, a higher-order component is a special kind of function that:

Accepts a React component as one of its arguments (among others, potentially).
Injects certain props into the component to "decorate" it or extend its behavior.
Returns this "decorated" component so that others can render it later on.

In other words, a higher-order component is essentially a component factory. It's a design pattern that allows you to create new versions of existing components by injecting additional props into them. Notably, higher-order components are used to consolidate reusable, stateful logic in a single place.

Don't get confused—an HOC is not itself a component. Remember: Components are functions that return a React element; higher-order components are functions that return components.

At a high level, without going into any specifics, here's what a higher-order component might look like:

// A higher-order component...
function hoc(Component, other, args) {
  // ... returns a component...
  return function(props) {
    // ...which is just a function that returns an element!
    return <Component someProp="someValue" {...props}>Awesome!</Component>
  }
}

Of course, this doesn't tell you much about why you might want to use a higher-order component. To truly see the benefits, we'll now look at a practical example of higher-order components.

Example of Higher-Order Components

Suppose we're using React to create a blog (e.g., with a static site generator like Gatsby). You can follow along with the code in this tutorial or view the companion CodeSandbox demo.

To kick things off, we'll create a basic presentational component named PostList that represents a generic list of posts. Nothing fancy here:

(File: components/PostList/index.js)

import React from "react";

const PostList = ({ posts }) => (
  <ol>
    {posts.map((post) => (
      <li key={post.id}>
        <a href={post.href}>{post.title}</a>
        <p>{post.description}</p>
      </li>
    ))}
  </ol>
);

export default PostList;

Your blog is going to have three different kinds of posts: recent, popular, and archived. Since we don't actually have any real data to work with here, we'll create some fake data and use that for this tutorial:

(File: containers/Posts/api.js)

const recentPosts = [
  {
    id: 1,
    title: "Recent Post 1",
    href: "/recent-post-1/",
    description: "Recent post 1 description"
  },
  {
    id: 2,
    title: "Recent Post 2",
    href: "/recent-post-2/",
    description: "Recent post 2 description"
  },
  {
    id: 3,
    title: "Recent Post 3",
    href: "/recent-post-3/",
    description: "Recent post 3 description"
  }
];

const popularPosts = [
  {
    id: 1,
    title: "Popular Post 1",
    href: "/popular-post-1/",
    description: "Popular post 1 description"
  },
  {
    id: 2,
    title: "Popular Post 2",
    href: "/popular-post-2/",
    description: "Popular post 2 description"
  },
  {
    id: 3,
    title: "Popular Post 3",
    href: "/popular-post-3/",
    description: "Popular post 3 description"
  }
];

const archivedPosts = [
  {
    id: 1,
    title: "Archived Post 1",
    href: "/archived-post-1/",
    description: "Archived post 1 description"
  },
  {
    id: 2,
    title: "Archived Post 2",
    href: "/archived-post-2/",
    description: "Archived post 2 description"
  },
  {
    id: 3,
    title: "Archived Post 3",
    href: "/archived-post-3/",
    description: "Archived post 3 description"
  }
];

export const getRecentPosts = () => recentPosts;
export const getPopularPosts = () => popularPosts;
export const getArchivedPosts = () => archivedPosts;

In the real world, you'd hit an actual API endpoint rather than returning local, static data. For the purposes of this tutorial, though, we've hardcoded our data for recent, popular, and archived posts in arrays. And at the bottom, we've exported three functions that return these arrays.

Our blog will consist of the following container component:

(File: containers/Posts/index.js)

import React from "react";
import {
  ArchivedPosts,
  PopularPosts,
  RecentPosts
} from "../../components/PostList";

const Posts = (props) => {
  return (
    <article>
      <section>
        <h2>Recent Posts</h2>
        <RecentPosts />
      </section>
      <section>
        <h2>Popular Posts</h2>
        <PopularPosts />
      </section>
      <section>
        <h2>Archived Posts</h2>
        <ArchivedPosts />
      </section>
    </article>
  );
};

export default Posts;

Of course, the three components you see here don't exist just yet, so let's go ahead and create them now. We'll use the fetch functions we defined just a few seconds ago to do that. Keep in mind that in the real world, you'd probably use some Promise-based fetch function to get your data, and thus you'd need to either await your data or chain thens:

(File: components/PostList/index.js)

import React, { useEffect, useState } from "react";
import { getArchivedPosts, getPopularPosts, getRecentPosts } from "../../containers/Posts/api";

// Same as before
const PostList = ({ posts }) => (
  <ol>
    {posts.map((post) => (
      <li key={post.id}>
        <a href={post.href}>{post.title}</a>
        <p>{post.description}</p>
      </li>
    ))}
  </ol>
);

export const RecentPosts = (props) => {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    setPosts(getRecentPosts());
  }, []);

  return <PostList posts={posts} {...props} />;
};

export const PopularPosts = (props) => {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    setPosts(getPopularPosts());
  }, []);

  return <PostList posts={posts} {...props} />;
};

export const ArchivedPosts = (props) => {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    setPosts(getArchivedPosts());
  }, []);

  return <PostList posts={posts} {...props} />;
};

export default PostList;

Basically, each component fetches its respective type of posts after it mounts and renders a PostList, passing along the result of our fake API call to the posts prop.

This works just fine, but notice how we ended up repeating a lot of common logic. Each component:

Initializes an empty array as its state.
Makes an API call on mount and updates its state.
Returns a PostList, injecting the posts prop and spreading the rest.

The only thing that differs is the fetch function that gets called on mount: it's either getRecentPosts, getPopularPosts, or getArchivedPosts. What if we could instead create a helper function—a factory, really—that consolidates this shared logic in a function that spits out specialized PostList components?

That's precisely the idea behind higher-order components in React.

Creating Reusable Stateful Logic with Higher-Order Components

I'll show the higher-order component for this scenario now, in its entirety, and then explain how it works:

(File: components/PostList/withPosts.js)

import React, { useState, useEffect } from "react";

function withPosts(Component, getPosts) {
  return function (props) {
    const [posts, setPosts] = useState([]);

    useEffect(() => {
      setPosts(getPosts());
    }, []);

    return <Component posts={posts} {...props} />;
  };
}

export default withPosts;

Again, it's worth reiterating that a higher-order component is just a function like any other in JavaScript:

function withPosts(Component, getPosts) {
  // ...
}

The key difference between an ordinary function and a higher-order component is that an HOC returns a React component, rather than some other result. If you're curious, the term "higher-order component" is derived from "higher-order function." A higher-order function is one that returns another function. This concept exists not only in JavaScript but also many other languages, especially functional ones.

Our withPosts higher-order component accepts two arguments in this particular case: a React component and a function that should be called to fetch posts (recent, popular, or archived) from our API. Inside the higher-order component, all we're doing is returning a functional React component:

function withPosts(Component, getPosts) {
  return function (props) {
    // ...
  };
}

In fact, if we had wanted to, we could've used the legacy React syntax and returned a class instead, to make it perfectly clear that a higher-order component returns a React component:

(File: components/PostList/withPosts.js)

import React, { useState, useEffect } from "react";

function withPosts(Component, getPosts) {
  // Same as before, but more verbose without hooks
  return class extends React.Component {
    constructor(props) {
      super(props);
      this.state = {
        posts: [],
      };
    }

    componentDidMount() {
      // Again, you'd most likely await this
      const posts = getPosts();
      this.setState({ posts });
    }

    render() {
      return <Component posts={posts} {...props} />;
    }
  };
}

export default withPosts;

In both versions of the code, the inner component accepts props (just like all React components do), initializes an empty array of posts as its state, and calls the fetch function on mount. Once the API call finishes, the component updates its state. Finally, it returns the original Component that we passed in, but injecting the posts array as an additional prop and spreading the remaining props.

Now, using this higher-order component couldn't be easier:

(File: components/PostList/index.js)

export const RecentPosts = withPosts(PostList, getRecentPosts);
export const PopularPosts = withPosts(PostList, getPopularPosts);
export const ArchivedPosts = withPosts(PostList, getArchivedPosts);

Notice that we're calling the higher-order component three times here, once for each type of post. Each time, we're passing in two things:

The component to modify (in this case, our presentational component PostList).
The function that fetches posts (getRecentPosts, getPopularPosts, or getArchivedPosts).

Since the result of a call to a higher-order component is just another component, these exported variables can be rendered. Thus, the code from earlier should make sense:

(File: containers/Posts/Posts.js)

import React from "react";
import {
  ArchivedPosts,
  PopularPosts,
  RecentPosts
} from "../../components/PostList";

const Posts = (props) => {
  return (
    <article>
      <section>
        <h2>Recent Posts</h2>
        <RecentPosts />
      </section>
      <section>
        <h2>Popular Posts</h2>
        <PopularPosts />
      </section>
      <section>
        <h2>Archived Posts</h2>
        <ArchivedPosts />
      </section>
    </article>
  );
};

export default Posts;

Additionally, if we had wanted to, we could've also passed along more props to these components:

(File: containers/Posts/Posts.js)

import React from "react";
import {
  RecentPosts,
  ArchivedPosts,
  PopularPosts
} from "components/PostList";

const Posts = (props) => {
  return (
    <article>
      <section>
        <h2>Recent Posts</h2>
        <RecentPosts prop1="foo" prop2={42} />
      </section>
      <section>
        <h2>Popular Posts</h2>
        <PopularPosts prop1="xyz" />
      </section>
      <section>
        <h2>Archived Posts</h2>
        <ArchivedPosts />
      </section>
    </article>
  );
};

export default Posts;

We're able to do this because of the following two lines of code in our higher-order component:

import React, { useState, useEffect } from "react";

function withPosts(Component, getPosts) {
  // the component accepts props
  return function (props) {
   ...

   // and spreads them here
   return <Component posts={posts} {...props} />;
  };
}

One last thing worth noting with this example: You may be wondering why we didn't just return a PostList from the higher-order component instead of accepting a generic reference to some Component.

In other words, why not do this:

(File: components/PostList/withPosts.js)

import React, { useState, useEffect } from "react";
import PostList from "./PostList";

function withPosts(getPosts) {
  return function (props) {
    const [posts, setPosts] = useState([]);

    useEffect(() => {
      getPosts().then(setPosts);
    }, []);

    return <PostList posts={posts} {...props} />;
  };
}

export default withPosts;

That would certainly save us some typing here, as we'd no longer have to specify PostList as the first argument to each function call:

export const RecentPosts = withPosts(getRecentPosts);
export const PopularPosts = withPosts(getPopularPosts);
export const ArchivedPosts = withPosts(getArchivedPosts);

However, this isn't a good idea in general, as you may run into a situation later on where you actually want to pass in a more customized version of PostList—like one that only shows the first five posts, or one that renders posts as cards instead of in a list, and so on. By accepting a generic reference to a component, our higher-order component is not only more flexible but also easier to test, as we've no longer hard-coded a dependency in the implementation. Instead, we allow the consumer to specify the component to render.

Higher-Order Components and the Power of Composition

If you're with me so far, you may have noticed an interesting fact: Higher-order components accept a component as one of their arguments, but they also return a component. Naturally, this means we can pass the result of one higher-order component as an argument to another, like nested Matryoshka dolls:

Image source: Wikimedia Commons user Fanghong

Consider this toy example:

const Div = (props) => <div {...props} />;

function withX(Component) {
  return function(props) {
    const [x, setX] = useState("");

    useEffect(() => {
      // simulate async fetch/call
      setTimeout(() => {
        setX("x");
      }, 1000);
    }, []);

    // inject x
    return <Component x={x} {...props} />;
  }
}

function withY(Component) {
  return function(props) {
    const [y, setY] = useState("");

    useEffect(() => {
      // simulate async fetch/call
      setTimeout(() => {
        setY("y");
      }, 1000);
    }, []);

    // inject y
    return <Component y={y} {...props} />;
  }
}

export default withY(withX(Div));

The composition happens here:

export default withY(withX(Div));

If you work your way from the inside out, you should understand why we're able to do this: withX returns the Div component with the state variable x injected into it. So, you can think of the export as being this:

export default withY((props) => <Div x="x" {...props} />);

And withY is yet another higher-order component that accepts a generic component and injects the y prop into it. In the end, we get an exported component that has x and y injected dynamically based on the stateful logic in each HOC. So you can think of the export as really being this component:

export default (props) => <Div x="x" y="y" {...props} />);

You'll see this pattern of composing higher-order components frequently in React. For example, your app may have a higher-order component that injects user login information into a component, another that injects theme variables, yet another that injects internationalization settings, and so on:

export default withIntl(withTheme(withUserLogin(MyComponent)));

We'll actually look at a concrete example of one of these in the section on using higher-order components with the Context API. But the key takeaway from this section is that you can compose higher-order components together, allowing you to customize your components by combining HOCs in various ways.

Higher-Order Components vs. Wrapper Components

Throughout this tutorial, I described higher-order components as factories that accept a reference to a component and decorate it with certain props. How does this differ from wrapper components, which accept props and return a component? The two certainly sound similar, but consider this example:

// Option 1: Wrapper component
const Wrapper = (props) => {
  const [state, setState] = useState("");

  // ... mounts and useEffect logic here somewhere (optional)

  return <Component prop1={state} {...props} />;
}

// Option 2: Higher-order component
const HOC = (Component) => {
  const [state, setState] = useState("");

  // ... mounts and useEffect logic here somewhere (optional)

  return function (props) {
    return <Component prop1={state} {...props} />;
  }
}

Notice the difference?

The higher-order component doesn't render anything—it just returns a component definition:

return function (props) {
  return <Component prop1={state} {...props} />;
}

That component instance can be rendered later.

In contrast, the wrapper component returns the result of actually rendering the Component:

return <Component prop1={state} {...props} />;

That's the key distinction between higher-order components and wrapper components:

HOCs are called with component instances, to which the HOC can inject props before the component is rendered. Container components are called with the result of rendering a component instance, not the component instance itself.

Because of this, you can't compose wrapper components like you can higher-order components. The result of a wrapper component is a rendered component, not a reference to a component instance, so it's not nearly as flexible as the HOC pattern.

Using Higher-Order Components with the React Context API

In practice, higher-order components are especially useful when combined with React's Context API. The Context API solves the problem of prop-drilling hell, without introducing a state management library like Redux, immer, zustand, and the many others that are currently competing in React.

By combining higher-order components with the Context API, we can give any deeply nested component in our app access to a particular context's value, without having to write tedious boilerplate or drilling props.

Here's a CodeSandbox demonstrating this. We have an app where every component needs a theme variable, as well as potentially the ability to toggle that theme (e.g., for light and dark modes).

We could define the theme in our App as a local state variable and simply drill it down to every component in the app that needs it. But that's not maintainable at all. Another option is to use a state management library like Redux, although one could argue it's a bit overkill for this scenario, especially now that we can take advantage of React's powerful Context API.

So, let's break down how the demo code works.

We've created a theme context here:

const ThemeContext = React.createContext("light");

By default, our theme starts with the value "light".

Looking at our app's render method, we see it's creating a provider for this context and setting its value to be the app's state:

export default class App extends React.Component {
  state = {
    theme: "light",
    setTheme: (theme) => this.setState({ theme })
  };

  render() {
    return (
      <ThemeContext.Provider value={this.state}>
        <Article />
        <Div />
        <ThemeToggle />
      </ThemeContext.Provider>
    );
  }
}

That state consists of:

The current value of the theme ("light" initially).
A method to update the theme.

Finally, the most relevant part of the code is the following higher-order component, withTheme:

export function withTheme(Component) {
  return function (props) {
    return (
      <ThemeContext.Consumer>
        {(value) => (
          <Component theme={value.theme} setTheme={value.setTheme} {...props} />
        )}
      </ThemeContext.Consumer>
    );
  };
}

This higher-order component accepts a reference to any generic component and returns a new component that's wrapped in ThemeContext.Consumer. Effectively, the HOC consumes the theme's current value and injects this into the component as additional props.

This allows us to then do the following in any of our components:

export default withTheme(MyComponent);

Check it out—here's the code for the ThemeToggle button:

import React from "react";
import { themeMap, withTheme } from "../App";

const ThemeToggle = (props) => (
  <button onClick={() => props.setTheme(themeMap[props.theme])}>
    Toggle theme (current: {props.theme})
  </button>
);

// This gives us access to two additional props: theme and setTheme
export default withTheme(ThemeToggle);

We've defined a simple functional component like any other that you're used to by now, except we inject the theme variables into this component before exporting it. This gives the button access to the theme value as well as the ability to toggle said theme. We do precisely that in the button's onClick handler.

Now, anytime we want a component to be aware of the current theme, all we have to do is wrap it with the higher-order component, and we're done!

As I mentioned earlier, other real-world examples of higher-order components include:

Injecting internationalization settings into a component to regulate text formatting.
Injecting user login info into a component to check permissions.
... and much, much more.

One thing worth noting is that when the value of the context changes, all components that consume it will re-render. But you'd get the same behavior if you were to use a state management library like Redux. When you map state to props in Redux, a state change triggers a prop change, and a prop change causes your connected components to re-render.

Conclusion

The higher-order component design pattern is pretty powerful once you get comfortable with it and realize what it's doing. In a nutshell, higher-order components are component factories that take a component, inject props into it, and return the modified component. As we saw, you can compose higher-order components and even combine them with React's Context API to write powerful, reusable code.

Attributions

The copyright for the React logo used in this blog post's thumbnail belongs to Facebook.

The image of the factory was taken by Patrick Hendry on Unsplash.

An Introduction to HTTP Cookies

Aleksandr Hovhannisyan — Thu, 20 Aug 2020 11:37:54 +0000

Note: This post was originally published on my dev blog. Since reposting it here on Dev.to, I've edited the original considerably. I recommend reading it on my blog for the latest revisions.

Have you ever wondered how a website remembers who you are when you navigate between different pages, or when you close the site and come back later? Why is it that you only have to log in if you've been gone for a really long time? What's this magic glue that seemingly holds these separate pages together as if they're a single unit—and, for you as a user, a single experience?

In this guide, we'll take a look at everything you need to know about browser cookies—you know, those things that a support rep once told you to clear, along with your hard-earned money. We'll look at what cookies are, how they get set, how advertising cookies work, and much more.

The only prerequisite is a basic understanding of how the web works. In particular, we'll be referring to things like HTTP requests, browsers, and servers. Let's dig in!

How Does a Website Remember Who You Are?
What Is a Cookie?
- Types of Cookies: Session vs. Permanent
  - 1. Session Cookies
  - 2. Permanent Cookies
How Do Cookies Get Set in a Browser?
- HTTP Request and Response Headers
- The Set-Cookie HTTP Response Header
- Reading and Creating Cookies via JavaScript
  - HTTPOnly Cookies: Protecting Sensitive Data
The Same-Origin Policy and Session Hijacking
Why Do Websites Ask for My Permission to Store Cookies?
- How Advertising Cookies Work
Where Are Cookies Stored on My Computer?
- Chrome
- Firefox
- Microsoft Edge
How Do I Clear My Cookies?
- What Happens if I Clear My Cookies?
Alternatives to Cookies
- Cookies vs. localStorage vs. sessionStorage
Final Thoughts

How Does a Website Remember Who You Are?

From a technical perspective, each page of a website corresponds to a different "resource" that's hosted on a web server—a computer whose job is to listen for requests from a user's browser and to respond accordingly. For example, when you loaded this page, your browser requested a bunch of different resources from my web server, such as the HTML document itself, its stylesheet, some JavaScript, images, and more. Thus, navigating to a different page on a site initiates a new HTTP request to fetch that resource (and potentially any related resources) from the web server.

Yet the HTTP protocol is stateless, meaning a server does not keep track of any of your prior HTTP requests for the purposes of matching future requests to older ones ("who did this come from?"). This means that HTTP requests sent by your browser need to contain all necessary information in order for the server to identify you. This is especially important if you're trying to access privileged resources that require authentication, like the settings under your user profile. So how exactly is this accomplished?

Websites have a few different options for tracking your identity, as well as managing what's called your session state: information about your current browsing session. In this post, we'll take a look at just one particular approach: storing cookies in your web browser.

What Is a Cookie?

If you Google "what is a cookie," chances are that you'll come across a definition like this:

A cookie is a piece of data that a browser stores on your computer.

Great! Unfortunately, while this definition is accurate, it doesn't actually give you a sense of what a cookie really is or what one looks like. First, it helps to understand what a cookie isn't. Cookies in your browser are not:

Processes that are running in the background.
Malware or spyware that's listening to your activity.
Delicious snacks.

Cookies are literally inert pieces of textual data. And the best way to understand cookies is to actually look at one. Follow these simple steps:

Open your browser's developer tools (Ctrl+Shift+I on Windows / Cmd+Shift+I on Mac).
Navigate to the Application tab in Chrome (Storage in Firefox and Edge).
Expand Cookies in the left-hand panel.
Click a domain that's listed to view the cookies that are associated with it.

For the purposes of this tutorial, I'll be using Reddit as an example. Here are the cookies associated with my Reddit account (I've intentionally obfuscated potentially sensitive values out of an abundance of caution):

True to its definition, a cookie is in fact "just a piece of data" stored on your computer. Each site may store zero or more cookies. Here, Reddit is storing 15 different cookies. A cookie consists of a name, a value, an expiration date or "age," a size in bytes, and so on.

Notice how each cookie stores certain information identifying me as a user, as well as my preferences and settings to help the web server customize my user experience and the results returned in my Reddit feed. For example, redesign_optout is one cookie in this list. Its value is set to true here for my Reddit account because I prefer to use the old interface. Since Reddit uses server-side rendering, the server needs to know which version of the Reddit interface a user wants to fetch: the old one or the new one. There are a few other cookies in the list, some of which are specific to my user profile and current browsing session.

Over on the far right, you'll see a Size column. The size of a cookie is the total number of characters (bytes) in its name and value. For example, the cookie redesign_optout=true has a size of 19 because the combined character length of redesign_optout and true is 19.

Types of Cookies: Session vs. Permanent

There's another column in the table above that deserves our attention: Expires / Max-Age. These two attributes basically tell your browser for how long a cookie should be kept around. There are two types of cookies that we'll look at, each defined by its expiration/max age.

1. Session Cookies

Notice that some cookies have Session as their value under the Expires / Max-Age column:

These are known as session cookies, also called temporary cookies because they're only kept around for your current browsing session. It's up to the browser itself to define what constitutes a "current browsing session." In Chrome and Firefox, this is when you fully shut down your browser (i.e., close all tabs). At that point, the cookie may get cleared.

Why do I say "may"? Because there's a hidden gotcha. When you launch these browsers, some of them give you the option of restoring your previously open tabs. This means that certain browsers may restore a session cookie even after a browsing session has technically ended.

2. Permanent Cookies

While the term "permanent" seems to imply that these cookies never go away, that's not the case at all. A permanent cookie is simply one that has an explicit expiration date and time or that has a max age set to a certain duration in milliseconds. These cookies will be cleared once they've expired.

How Do Cookies Get Set in a Browser?

So we've seen that a cookie is in fact "a piece of data" stored in your browser. But how exactly does a cookie get created in the first place? Where does it come from?

As I mentioned earlier in this post, the HTTP protocol is stateless, meaning a web server does not keep track of any information about your prior HTTP requests. This means that requests sent from your browser to a web server must include all information that the server needs in order to identify you. Guess what? This means that your browser will need to include your cookies for that domain (assuming that you have any) in its requests.

For the upcoming section, you'll only need a basic understanding of how the web works—in particular, the HTTP protocol. Here's a quick refresher:

HTTP Request and Response Headers

HTTP consists of requests and responses. A browser sends a request to a server; the server sends back a response. Both requests and responses can contain data, but they also include certain metadata (supplementary information) about the request/response itself. These are known as request headers and response headers.

For example, a request header may contain some of this information:

The type of device being used to initiate the request (e.g., Windows NT 10.0; Win64; x64).
The browser that's sending the request (e.g., AppleWebKit/537.36 (KHTML, like Gecko)).
The URL that is being requested (e.g., https://www.reddit.com).

... and much more.

Conversely, servers send back a response containing data like images, CSS, HTML, JSON, etc., along with certain metadata about the response itself. This information appears in the response header. For example, servers may tell a browser:

Whether the request was successfully handled, via HTTP response status codes. The most common ones you'll encounter are 200, 304, 404, and 500.
The type of content returned (e.g., application/json).
For how long the content should be cached by the browser.

... and much more.

You can view request and response headers for any HTTP request using the Network tab in your browser's dev tools.

The `Set-Cookie` HTTP Response Header

Here's the key: A server may also send along a Set-Cookie response header that tells your browser to store a cookie. A response may contain as many of these Set-Cookie headers as needed, one for each cookie that needs to get set. Basically, cookies can be generated programmatically on the server side and sent along with responses whenever they need to get set by a browser. But you can also create cookies with JavaScript, as we'll see shortly.

Here's an example of monitoring XHR requests with the Firefox Dev Tools on Reddit and intercepting the Set-Cookie response header:

Now, if you inspect future requests, you'll find that this cookie is included in the Cookie HTTP request header:

Reading and Creating Cookies via JavaScript

Before we move on, note that there's a second way to view cookies in your developer tools. Simply navigate to the Console tab, enter the following code, and press enter:

document.cookie

You'll see one big output string containing name=value pairs of cookies strung together with semicolons. Here, document.cookie is how you create, update, and delete cookies via JavaScript. Notice that some of the supplementary information—like the expiration date or size of the cookie—does not appear in this string. However, those values will get set internally in the browser.

Here's an example of creating a cookie with JavaScript:

document.cookie = 'foo=bar';

Now, this API is a little weird. While you would expect the above line of code to replace the whole cookie string, this new cookie will actually get concatenated to the existing cookie string (or take the place of an existing cookie, if it has the same name). Here's an example of creating three cookies:

Note that you can't create multiple cookies in one go, like document.cookie = 'foo=bar; hello=world; id=123'. You have to call document.cookie = ... separately for each cookie.

When you just specify the name and value of a cookie, it gets created as a session cookie by default. You can also optionally specify an expiration:

document.cookie = 'foo=bar; expires=Su, 20 Dec 2020 20:20:20 UTC';

Note: If "today" is past the above date when you're reading this, the code won't work. And that's because of the next point.

To delete a cookie with JavaScript, you need to set its expiration date to be sometime in the past:

document.cookie = 'foo=bar; expires=Fri, 24 Jul 2020 04:00:00 UTC';

We'll take a closer look at how to delete cookies cookies later in this guide.

HTTPOnly Cookies: Protecting Sensitive Data

If you compare the output of document.cookie to the table that we looked at earlier, you may be surprised to find that some cookies are missing from the output string. And that's because of an additional property that we haven't yet covered: HTTPOnly cookies:

A cookie that is marked as HTTPOnly cannot be read via JavaScript. Usually, you'll find that session cookies are marked as HTTPOnly. This is a safety precaution to protect you against session hijacking, where a malicious actor may try to read your cookie via JavaScript and use it to masquerade as you.

Speaking of session hijacking...

The Same-Origin Policy and Session Hijacking

It's important to understand that every cookie stored on your computer is associated with a specific domain, like reddit.com in the examples above.

Naturally, that begs the following question: If cookies for Site A and cookies for Site B are both stored in the same browser and on the same computer, is it possible for Site B to use Site A's cookies in its request headers? Fortunately, because of the same-origin policy, this is not possible.

If you think about it, that would be pretty dangerous if it were allowed—it would mean that Site B could read cookies stored for Site A in your browser and then use those cookies to hijack your browsing session. All that Site B would need to do is send those exact cookies in a request header to Site A's server, and voila—the server, none the wiser, would think that the request is coming from you, when really it's someone who's impersonating you.

There's a tutorial on how to perform session hijacking that helps drive home the following key point: There is nothing special about you and your browser when you access a particular site. The only way a web server knows who you are is based on the information your browser passes along in an HTTP request. If someone has your session cookies, they can simply copy those cookies locally, refresh the page, and essentially bypass traditional authentication mechanisms like usernames and passwords.

Fun fact: This is why I obfuscated my session cookies (e.g., reddit_session) in the screenshots above. While session cookies are technically temporary, we've already seen that they can stick around for longer than a browser session.

Why Do Websites Ask for My Permission to Store Cookies?

This is typically where the misconceptions and fears arise regarding what cookies are and whether they're dangerous. Remember: A cookie is nothing but a piece of data. It's inert—it's only useful if your browser sends it to a server via an HTTP request. Rather, people are wary of browser cookies because they're (rightfully) concerned about their online privacy.

With the advent of the GDPR in the European Union and the 2018 amendments to the California Consumer Privacy Act, companies were forced to comply with new privacy regulations. Many decided to go about this by showing popups and notices that ask for your permission to store cookies on your computer, rather than simply doing so without your knowledge.

Cookies are important. But certain kinds of cookies pose a privacy concern for users since they can be used to store personally identifiable information about you based on your activity on a particular website. This is typically done with advertising cookies.

How Advertising Cookies Work

Advertising cookies are used by ad networks like Google AdSense to show you personalized content, as well as to share your information with advertisers within the network to collect usage data and analytics. A website is considered to be part of an ad network like Google AdSense if it's paying that network to show ads on its behalf.

This quote from Google's policy on advertising is particularly enlightening about how Google AdSense stores its cookies:

We also use one or more cookies for advertising we serve across the web. One of the main advertising cookies on non-Google sites is named ‘IDE‘ and is stored in browsers under the domain doubleclick.net.

Here's a breakdown of how advertising cookies work:

You visit a site (e.g., https://www.foo.bar) that happens to be part of some ad network (e.g., Google AdSense, which has a domain of doubleclick.net).
The site has ads embedded in its HTML markup, such as in an <iframe>, <img>, or <video>.
Those ads are hosted on the ad network's domain (e.g., doubleclick.net).
When you load the page, your browser requests those ads from the ad network's domain, just like it requests any other resource on the page (images, videos, and so on).
The secret sauce: The ad network sends the requested ads, along with an advertising cookie in the response header.
Your browser records the cookie for that ad network's domain (in this case, doubleclick.net).
When you visit another site that's part of the same ad network, the cookie will follow you.

Note: Steps 4–6 may not occur if you're in private browsing, have an adblocker enabled, or have enabled Enhanced Tracking Protection in Firefox.

This is one of the reasons why people sometimes find that ads are following them around the web no matter where they go, and that these ads are often tailored to the content they previously viewed. For example, if you're shopping online for dog toys and later visit a social media site with ads enabled, you may see ads for dog toys and related accessories in a sidebar. It's not a coincidence—it's an advertising cookie in action, and some people find this to be an invasion of privacy.

Here's a real-world example of inspecting that very IDE advertising cookie that Google mentions. This is on StackOverflow, one of the few sites where I felt it would be safe to temporarily disable my adblocker for this tutorial:

Time for a fun experiment, assuming you're willing to accept cookies and sell your soul to advertisers:

Launch Google Chrome. Firefox's privacy protections are pretty aggressive, which is usually a good thing—but it will get in the way of this valuable learning experience.
Visit a popular website and temporarily disable your adblocker.
Open your devtools and try to find any cookies that seem to be from a Google domain. Look for doubleclick.net in the Domain column (see the screenshot above).
Visit another website that you suspect will show ads, and disable your adblocker again.
Open your devtools and see if there are any cookies from the same ad network domain.

In particular, you'll want to look for the IDE cookie. And what you'll find is that it's exactly the same on the second site as it is on the first one that you visited. I tested this with Quora:

Everything is the same, down to the cookie's expiration date and time.

As we've learned, this is because the advertising cookie is not associated with StackOverflow's or Quora's domain—it's associated with the ad network's domain (in this case, doubleclick.net). So as long as it remains on your computer, it'll follow you around on other sites that are part of the same ad network. Pretty neat—and definitely something to be worried about if you're privacy conscious.

Where Are Cookies Stored on My Computer?

By their very nature, cookies do not sync between browsers. They're just inert pieces of data. So, cookies set in Chrome for a domain have nothing to do with cookies set in Firefox, Edge, or any other browser for the same domain. This is why you'll be prompted to log into your account if you try visiting a site or app with a browser that you don't normally use.

Most major browsers store their cookies in an SQLite database file. You can open this database file using an app like DB Browser for SQLite. Note that the location of your cookies will vary depending on the browser and operating system you're using.

Chrome

Chrome stores its cookies in an SQLite database file named Cookies, which is located here:

Windows: C:\Users\<your_username>\AppData\Local\Google\Chrome\User Data\Default\Cookies
Mac: ~/Library/Application Support/Google/Chrome/Default/Cookies
Linux: ~/.config/google-chrome/Default/Cookies

Apparently, Chrome maintains two separate database tables for cookies—a cookies table and a meta table:

And here's what the data looks like for the cookies table:

Firefox

Like Chrome, Firefox stores its cookies in an SQLite database file. Here's how to find it:

Click the hamburger icon (top-right of your browser) to open the Firefox settings.
Go to Help > Troubleshooting Information.
Locate Profile Folder in the table. Click the Open Folder button.
Scroll down and find cookies.sqlite.

For example, on Windows 10, you'll find your Firefox cookies under C:\Users\<your_username>\AppData\Roaming\Mozilla\Firefox\Profiles\<your_firefox_profile>\cookies.sqlite.

Microsoft Edge

Edge stores its cookies not in a single file but rather as separate files under C:\Users\<your_username>\AppData\Local\Microsoft\Windows\INetCookies:

You can open these files with a plain text editor.

How Do I Clear My Cookies?

There are two ways you can clear your cookies:

Via your browser's developer tools, which we've already used quite a bit in this tutorial.
Via your browser's settings, usually under History.

The first one is the more flexible option of the two, as it allows you to only delete cookies from a particular domain as opposed to all cookies across all domains. You can either right-click a cookie and delete it or simply click the clear icon (a trashcan in Firefox) to delete all cookies:

And as we saw in an earlier section, you can also clear a cookie via JavaScript by setting its expiration date to be sometime in the past.

What Happens if I Clear My Cookies?

If you've been following along, you should already know the answer to this question. Remember: A web server uses cookies as a form of authentication, to ensure that you're allowed to view the pages that you're trying to access. It also uses cookies to personalize your website experience by storing certain settings and preferences. So, if you clear your cookies for a website, two things will happen:

You'll be logged out the next time you visit the site. This is because the browser won't send any cookies to the server when you request that page, so the server won't have any way of knowing who you are. Once you log back in, you'll get a new set of cookies, fresh from the oven.
Your preferences or settings may get cleared for that website or app.

Note that certain other user settings are stored in an app's database rather than in cookies on the client side. So, when you clear your cookies, those other settings will be left untouched.

Alternatives to Cookies

Cookies are just one way that websites can save information on the client side. Browsers may also use:

The Web Storage API: localStorage and sessionStorage.
IndexedDB, typically for large amounts of data.

I use the first option on my blog to store your selected theme (light mode or dark mode). You can explore localStorage just like you would any other storage option in your browser's dev tools:

You can also clear localStorage via the same tab in dev tools or via JavaScript.

Cookies vs. `localStorage` vs. `sessionStorage`

Here's a brief look at the major differences between cookies and the Web Storage API:

Storage	Expiration	Use cases
localStorage	None, but users can manually clear it via dev tools or the console (`localStorage.clear()`).	Storing data on the client side that the server does not need (e.g., preferences, settings).
sessionStorage	Until the end of the current browsing session (i.e., until you shut down your browser).	Storing data specific to the user's current browsing session.
Cookies	Current browsing session, if an expiration/max age is not specified.	Storing data received in a response header. Included in all future request headers.

Final Thoughts

Cookies are a pretty interesting (and sometimes controversial) topic in web development. Some people question whether they're really necessary these days. Others are worried about the privacy implications of advertising cookies that follow you around the web.

In any case, cookies exist, and probably will for quite some time. I hope you now have a better understanding of what browser cookies are and the role that they play on the web!

Binary for Beginners: The ABCs of 0s and 1s

Aleksandr Hovhannisyan — Sat, 08 Aug 2020 15:27:32 +0000

Note: This post was originally published on my dev blog. Also, it's really long, lol. My aim was to create the most comprehensive tutorial on binary numbers—one that I wish I had back when I was learning this stuff. I hope someone out there finds this helpful!

What is 10? If this is your first time learning about the binary number system, then this question may seem odd. Of course it's ten, right?

Let's try something different. Have you ever heard this joke?

There are 10 types of people in the world: those who understand binary and those who don't.

Unless you're familiar with binary numbers, this probably doesn't make much sense. But by the end of this post, you'll come to appreciate this and many other awful developer jokes!

In this beginner's tutorial, we'll look at everything you need to know about the binary number system, but we'll also take a quick look at decimal and hexadecimal, as they're closely related. I'll include relevant bits of code and real-life examples to help you appreciate the beauty of binary.

What Is a Number System?
- Bases, Exponents, and Digits
The Binary Number System (Base 2)
- Binary Is Close to the Hardware of a Computer
- The ASCII Standard
- 1 Character = 1 Byte
The Hexademical Number System (Base 16)
- How to Convert Between Binary and Hexadecimal
- Binary to Hexadecimal
- Hexadecimal to Binary
- Real-World Application: Representing Colors with RGB/Hex
- How Many Colors Are There?
- What Are 8-Bit Colors?
Signed Binary Number System: Two's Complement
- How Does Two's Complement Work?
- The Intuitive Approach: What Does a Leading 1 Denote?
- Two's Complement Shortcut: Flip the Bits and Add a 1
- How Many Signed Binary Numbers Are There?
- What Is the Largest Signed 32-bit Integer?
  - Real-World Application: Video Game Currency
- What Is the Smallest Signed 32-bit Integer?
Basic Arithmetic in the Binary Number System
- Adding Binary Numbers
- Subtracting Binary Numbers
- Multiplying Binary Numbers
- Dividing Binary Numbers
- Integer Overflow and Underflow in Binary
The Binary Number System: Additional Topics for Exploration

What Is a Number System?

Before we look at binary, let's take a step back and discuss number systems in general.

Now, it may be strange to think of number "systems" in the plural if this is your first time learning about them. That's because the majority of the world is familiar with just one: the decimal number system (aka "base ten"), also known as the Arabic number system. This system has digits ranging from 0 to 9, which we use to form numbers in our daily lives.

For example, in the decimal number system, 579 expands to this:

579 = 5(10²) + 7(10¹) + 9(10⁰) = 500 + 70 + 9

As a kid, you were taught that the 5 in 579 is in the "hundreds place," the 7 is in the "tens place," and the 9 is in the ones place. Notice that the 5 is multiplied by one hundred (10²), the 7 by ten (10¹), and the 9 by one (10⁰) to form the decimal number 579. Makes sense, right?

Here, the number 10 is what we call the base (aka radix) of our number system. Notice the powers of 10 in the expanded expression above: 10², 10¹, and 10⁰. For this reason, the terms decimal and base 10 are interchangeable.

In the decimal number system, a number is represented by placing digits into "buckets" that represent increasing powers of ten, starting with 10⁰ in the rightmost "bucket," followed by 10¹ to its immediate left, and so on infinitely:

Any unused buckets to the far left have an implicit value of 0 in them. We usually trim leading zeros because there is no use in saying 00579 when that's mathematically identical to 579.

Why did humans pick 10 to be the base of their preferred number system? Most likely because we're born with ten fingers and ten toes, and we're used to counting with our fingers when we're young. So it's simply natural for us to use this number system!

Bases, Exponents, and Digits

As I've already hinted, the decimal number system (base 10) isn't the only one in existence. Let's use a more general mathematical notation to represent number systems beyond just our familiar one.

In a number system with a fixed base of b, the available digits range from 0 to b - 1. For example, in the decimal number system (b = 10), we can only use the digits 0, 1, 2, ..., 9. When you "run out" of digits in a single bucket, you carry over a one to the next power of the base. For example, to get to the number after 99, you carry a one to the next power of ten: 100.

Now, suppose that we have a string of digits d1 d2 ... dn (where n is just the number of digits). Maybe that's d1 d2 ... dn = 579 from our earlier example. That string expands like this:

d1b^n-1 + d2b^n-2 + ... + dnb⁰

And you can visualize that like this:

Using our same example, d1b^n-1 + d2b^n-2 + ... + dnb⁰ = 5(10²) + 7(10¹) + 9(10⁰)

Again, we have buckets from right to left in increasing powers of our base (10).

Note: The rightmost bucket will always represent dn in any number system. Why? Because any base raised to the power of 0 is just 1.

Now, in reality, you can have a number system that uses a base of 2, 3, 4, 120, and so on. Some of these have special names because they're used more often than others:

Base	Name	Description
1	Unary	Also known as tallying. A number `n` is represented by picking an arbitrary character and repeating it `n` times (e.g., `xxxx` would be `4`).
2	Binary	Only two digits: zero and one. Most commonly used in computing. Everything on a computer is, at the lowest possible level, stored using the binary number system.
8	Octal	Only eight digits are available: `0–7`.
16	Hexadecimal	Fifteen digits: `0–9` and `a–f`. Often used to express binary strings more compactly.
60	Sexagesimal	How many seconds are in a minute? How many minutes in an hour? This is the basis of the modern circular coordinate system (degrees, minutes, and seconds).

For this reason, when discussing number systems, we usually subscript a number with its base to clarify its value. Alternatively, you can prepend a number with a certain string (usually 0b for binary or 0x/# for hexadecimal). So we'd write 579 as 57910, or the binary number 1001 as 10012 (or 0b1001). Otherwise, if we were to merely write the number 1001 without providing any context, nobody would know whether that's in binary, octal, decimal, hexadecimal, and so on because the digits 0 and 1 are valid in all of those number systems, too!

Note: When not comparing number systems, we usually assume that a given number is in decimal unless otherwise noted, and thus the subscript is omitted.

The Binary Number System (Base 2)

So far so good—we're all familiar with decimal numbers because we use them everyday. But what's the deal with the binary number system?

By definition, the binary number system has a base of 2, and thus we can only work with two digits to compose numbers: 0 and 1. Technically speaking, we don't call these digits—they're called bits in binary lingo.

Each "bucket" in a binary string represents an increasing power of two: 2⁰, 2¹, 2², and so on.

The leftmost bit is called the most significant bit (MSB), while the rightmost bit is called the least significant bit (LSB).

Here are some examples of representing decimal numbers in the binary number system:

Zero: 010 = 02. Expansion: 0 (2⁰)
One: 110 = 12. Expansion: 1(2⁰)
Two: 210 = 102. Expansion: 1(2¹) + 0(2⁰)
Three: 310 = 112. Expansion: 1(2¹) + 1(2⁰)
Four: 410 = 1002. Expansion: 1(2²) + 0(2¹) + 0(2⁰)
Five: 510 = 1012. Expansion: 1(2²) + 0(2¹) + 1(2⁰)

Note: Like in the decimal number system, leading zeros are usually stripped from binary strings. The only exception is if you're working with a signed binary number system, where a leading zero indicates that a number is positive and a leading one indicates that it's negative.

Having learned the binary number system, you should now understand the joke from earlier:

There are 10 types of people in the world: those who understand binary and those who don't.

Here, we really mean the binary equivalent of two, which looks like ten to our eyes when it's not properly subscripted: 102 = 1 × 2¹ = 210.

Binary Is Close to the Hardware of a Computer

Why do we bother with using the binary number system in the first place? Doesn't it seem like a whole lot of extra work to represent numbers in this manner when we could instead use the decimal number system? Well, yes—if you're writing these out by hand, it's certainly more work to represent (and manipulate) binary numbers.

You may not see any point in using binary if you haven't learned about computer architecture at a low level. Internally, computers are nothing more than electrical circuits tied to hardware. Current either flows through a wire or doesn't—a binary state. Likewise, computers use logic gates (AND/OR/NOR/XOR) to control the flow of a program's execution, and these take binary inputs (true/false). The best way to represent these low-level interactions is to use the binary number system: 0 means OFF (or false in its logical form) and 1 means ON (or true).

Note: If the whole world were to agree to it, we could just as well instead treat 0 as ON and 1 as OFF. However, it just makes more sense to treat 0 as OFF/false—after all, zero denotes the absence of a value. Hence, it's a natural candidate for representing things like falsehood or the lack of a current flowing through a wire.

Everything on your computer—the files you save and the software you install—is represented as nothing more than zeros and ones. But how is this possible?

The ASCII Standard

Suppose you create a file on your computer and store some basic text in it:

echo Hello, Binary > file

At the end of the day, your computer can't store a character like H, e, l, or o (or even the space between two words) literally. Computers only know how to work with binary. Thus, we need some way to convert these characters to numbers. And that's why the ASCII standard was introduced.

Formally, ASCII is referred to as a character encoding standard. Put more simply, it's a method of representing human-readable characters like H, e, ,, ?, and 9 numerically so that computers can understand and use them like we do.

Here is a typical ASCII chart that you may have seen before:

In the ASCII standard, there are a total of 128 characters, each mapped to a unique number in binary (with an equivalent representation in decimal that we humans understand more naturally):

Arabic digits: 0-9 (10)
Capital letters of the English alphabet: A-Z (26)
Lowercase letters of the English alphabet: a-z (26)
Punctuation and special characters (66)

1 Character = 1 Byte

In the decimal number system, we're used to working with digits. In binary, as we already saw, we're used to working with bits. There's another special group of digits in binary that's worth mentioning: A sequence of eight bits is called a byte.

Here are some examples of valid bytes:

... and any other valid permutation of eight 0s and 1s that you can think of.

Why is this relevant? Because on modern computers, characters are represented using bytes.

Recall that the ASCII standard needs to support a total of 128 characters. So how many unique number can we represent with 8 bits (a byte)?

Well, using the product rule from combinatorics, we have eight "buckets," each with two possible values: either a 0 or a 1. Thus, we have 2 × 2 × ... × 2 = 2⁸ possible values.

In decimal, this is 2⁸ = 256 possible values. By comparison, 2⁷ = 128. And 128 happens to be the number of characters that we want to represent.

So... That's weird, and seemingly wasteful, right? Why do we use 8 bits (one byte) to represent a character when we could use 7 bits instead and meet the precise character count that we need?

Good question! We use bytes because it's not possible to evenly divide a group of 7 bits, making certain low-level computations difficult if we decide to use 7 bits to represent a character. In contrast, a byte can be evenly split into powers of two:

11101011
[1110][1011]
[11][10][10][11]

The key takeaway here is that we only need one byte to store one character on a computer. This means that a string of five characters—like Hello—occupies five bytes of space, with each byte being the numerical representation of the corresponding character per the ASCII standard.

Remember the file we created earlier? Let's view its binary representation using the xxd Unix tool:

xxd -b file

The -b flag stands for binary. Here's the output that you'll get:

00000000: 01001000 01100101 01101100 01101100 01101111 00101100  Hello,
00000006: 00100000 01000010 01101001 01101110 01100001 01110010   Binar
0000000c: 01111001 00001010                                      y.

The first line shows a sequence of six bytes, each corresponding to one character in Hello,.

Let's decode the first two bytes using our knowledge of the binary number system and ASCII:

01001000 = 1(2⁶) + 1(2³) = 7210. Per our ASCII table, this corresponds to H.
01100101 = 1(2⁶) + 1(2⁵) + 1(2²) + 1(2⁰) = 10110, which is e in ASCII.

Cool! Looks like the logic pans out. You can repeat this for all of the other bytes as well. Notice that on the second line, we have a leading space (from Hello, Binary), represented as 2⁵ = 3210 in ASCII (which is indeed Space per the lookup table!).

By the way, what's up with the numbers along the left-hand side of the output? What does 0000000c even mean? Time to explore another important number system!

The Hexademical Number System (Base 16)

As I mentioned in the table from earlier, the hexadecimal number system is closely related to binary because it's often used to express binary numbers more compactly, instead of writing out a whole bunch of zeros and ones.

The hexadecimal number system has a base of 16, meaning its digits range from 0–15.

Note: In technical terms, a hexadecimal digit is called a nibble, but you'll commonly hear people just call them "hex digits."

This is our first time encountering a number system whose digits are made up of more than two characters. How do we squeeze 10, 11, or 15 into a single "bucket" or "slot" for a digit? To be clear, this is perfectly doable if you have clear delimiters between digits. But in reality, that's not practical.

Let's take a step back and consider a simple hexadecimal number:

0x42

What does this mean to us humans in our decimal number system? Well, all we have to do is multiply each digit by its corresponding power of 16:

0x42 = 4(16¹) + 2(16⁰) = 6410 + 210 = 6610

Okay, so that's a simple hex number. Back to the problem at hand: How do we represent the hex digits 10, 11, and so on? Here's an example that's pretty confusing unless we introduce some alternative notation:

0x15

Is this a 15 in a single slot or a 1 and a 5 in two separate slots? One way to make this less ambiguous is to use some kind of delimiter between slots, but again, that's not very practical:

0x8[15]29

The better solution that people came up with is to map 10–15 to the the English letters a–f.

Note: Capitalization doesn't matter, so you can use a-f or A-F. Just be consistent.

Here's an example of a hexadecimal number that uses one of these digits:

0xf4

And here's its expansion:

0xf4 = 15(16¹) + 4(16⁰) = 24010 + 410 = 24410

There's nothing magical about the hexadecimal number system—it works just like unary, binary, decimal, and others. All that's different is the base!

Before we move on, let's revisit the output from earlier when we used xxd on our sample file:

00000000: 01001000 01100101 01101100 01101100 01101111 00101100  Hello,
00000006: 00100000 01000010 01101001 01101110 01100001 01110010   Binar
0000000c: 01111001 00001010                                      y.

The numbers along the left-hand side mark the starting byte for each line of text on the far right. For example, the first line of text (Hello,) ranges from byte #0 (H) to byte #5 (,). The next line is marked as 00000006, meaning we're now looking at bytes #6 through 11 (B to r). Finally, the last label should make sense now that you know the hexadecimal number system: c maps to 12, meaning the byte that follows corresponds to the twelfth character in our file.

How to Convert Between Binary and Hexadecimal

Now that we know a bit about binary and hexadecimal, let's look at how we can convert between the two systems.

Binary to Hexadecimal

Say you're given this binary string and you'd like to represent it in hexadecimal:

011011100101

While at first this may seem like a pretty difficult task, it's actually very easy.

Let's do a bit of a thought exercise:

In the hexadecimal number system, we have 16 digits from 0 to 15. Over in binary land, how many bits do we need to represent these 16 values?

The answer is four because 2⁴ = 16. With four "buckets," we can create the numbers zero (0000), one (0001), ten (1010), all the way up to fifteeen (1111).

This means that when you're given a binary string, all you have to do is split it into groups of four bits and evaluate them to convert binary to hexadecimal!

011011100101
[0110][1110][0101]
6 14 5

Now we just replace 10–15 with a-f and we're done: 0x6e5.

Hexadecimal to Binary

What about the reverse process? How do you convert a hexadecimal number to binary?

Say you're given the hexadecimal number 0xad. What do we know about each hexadecimal digit? Well, from our earlier thought exercise, we know that four bits = one hex digit. So now we just have to convert each indiviual digit to its 4-bit binary representation and then stick each group together!

0xad = 0b10101101

Super easy, just like I promised.

Real-World Application: Representing Colors with RGB/Hex

While we're on the topic of binary and hexadecimal, it's worth taking a look at one real-world use case for the things we've learned so far: RGB and hex colors.

Colors have three components: red, green, and blue (RGB). With LED (light-emitting diode) displays, each pixel is really split into these three components using a color diode. If a color component is set to 0, then it's effectively turned off. Otherwise, its intensity is modulated between 0 and 255, giving us a color format like rgb(0-255, 0-255, 0-255).

Let's consider this hex color: #4287f5. What is it in the RGB format?

Well, we need to split this hex string evenly between red, green, and blue. That's two digits per color:

[42][87][f5]

Now, we simply interpret the decimal equivalent for each part:

Red: 4216 = 4(16¹) + 2(16⁰) = 66
Green: 8716 = 8(16¹) + 7(16⁰) = 135
Blue: f516 = 15(16¹) + 5(16⁰) = 245

That means #4287f5 is really rgb(66, 135, 245)! You can verify this using a Color Converter:

For practice, let's convert this to binary as well. I'll mark the groups of four bits to make it easier to see how I did this (note: you can also convert from the decimal RGB representation if you want to):

0x4287f5 = 0b[0100][0010][1000][0111][1111][0101]

Now, two groups of four bits will represent one component of the color (red/green/blue):

0b[01000010][10000111][11110101]

Notice that each color component takes up a byte (8 bits) of space.

How Many Colors Are There?

As an additional exercise, how many unique colors can you possibly have in the modern RGB format?

We know that each component (red/green/blue) is represented using one byte (8 bits). So the colors we're used to are really 24-bit colors.

That means there are a whopping 2²⁴ = 16,777,216 possible unique colors that you can generate using hex/rgb! The 24-bit color system is known simply as truecolor. And as you can see, it's capable of representing millions of colors.

Note that you could just as well have performed this calculation using hex: #4287f5. There are six slots, each capable of taking on a value from 0 to f. That gives us a total of 16 × 16 × ... × 16 = 16⁶ = 16,777,216 values—the same result as before.

Or, if you're using the decimal RGB format, the math still pans out: 256 × 256 × 256 = 16,777,216.

What Are 8-Bit Colors?

On older systems with limited memory, colors were represented using just eight bits (one byte). These 8-bit colors had a very limited palette, which meant that most computer graphics didn't have gradual color transitions (so images looked very pixelated/grainy). With only 8 bits to work with, you are limited to just 2⁸ = 256 colors!

Naturally, you may be wondering: How did they split 8 bits evenly among red, green, and blue? After all, 8 isn't divisible by three!

Well, the answer is that they didn't. The process of splitting these bits among the color components is called color quantization, and the most common method (known as 8-bit truecolor) split the bits as 3-3-2 red-green-blue. Apparently, this is because the human eye is less sensitive to blue light than the other two, and thus it simply made sense to distribute the bits heavily in favor of red and green and leave blue with one less bit to work with.

Signed Binary Number System: Two's Complement

Now that we've covered decimal, binary, and hexadecimal, I'd like us to revisit the binary number system and learn how to represent negative numbers. Because so far, we've only looked at positive numbers. How do we store the negative sign?

To give us some context, I'll assume that we're working with standard 32-bit integers that most (all?) modern computers support. We could just as well look at 64-bit or N-bit integers, but it's good to have a concrete basis for a discussion.

If we have 32 bits to fiddle with, that means we can represent a total of 2³² = 4,294,967,296 (4 billion) numbers. More generally, if you have N bits to work with, you can represent 2^N values. But we'd like to split this number range evenly between negatives and positives.

Positive or negative... positive or negative. One thing or another thing—ring a bell? That sounds like it's binary in nature. And hey—we're already using binary to store our numbers! Why not reserve just a single bit to represent the sign? We can have the most significant (leading) bit be a 0 when our number is positive and a 1 when it's negative!

Note: This is once again one of those situations where you could just as well do the opposite, except you'd have to convince the whole world to follow your chosen convention.

Earlier, when we were first looking at the binary number systems, I mentioned that you can strip leading zeros because they are meaningless. This is true except when you actually care about distinguishing between positive and negative numbers in binary. Now, we need to be careful—if you strip all leading zeros, you my be left with a leading 1, and that would imply that your number is negative (in a signed number system).

You can think of two's complement as a new perspective or lens through which we look at binary numbers. The number 1002 ordinarily means 410 if we don't care about its sign (i.e., we assume it's unsigned). But if we do care, then we have to ask ourselves (or whoever provided us this number) whether it's a signed number.

How Does Two's Complement Work?

What does a leading 1 actually represent when you expand a signed binary number, and how do we convert a positive number to a negative one, and vice versa?

For example, suppose we're looking at the number 2210, which is represented like this in unsigned binary:

101102

Since we're looking at signed binary, we need to pad this number with an extra 0 out in front (or else a leading 1 would imply that it's negative):

0101102

Okay, so this is positive 2210. How do we represent -2210 in binary?

There are two ways we can do this: the intuitive (longer) approach and the "shortcut" approach. I'll show you both, but I'll start with the more intuitive one.

The Intuitive Approach: What Does a Leading 1 Denote?

Given an N-bit binary string, a leading 1 in two's complement represents -1 multiplied by its corresponding power of two (2^N-1). A digit of 1 in any other slot represents +1 times its corresponding power of two.

For example, the signed number 110102 has this expansion:

110102 = -1(2⁴) + 1(2³) + 1(2¹) = -1610 + 810 + 210 = -610

We simply treat the leading 1 as a negative, and that changes the resulting sum in our expansion.

Two's Complement Shortcut: Flip the Bits and Add a 1

To convert a number represented in two's complement binary to its opposite sign, follow these two simple steps:

Flip all of the bits (0 becomes 1 and vice versa).
Add 1 to the result.

For example, let's convert 4310 to -4310 in binary:

+43 in binary: 0101011
Flipped:       1010100
Add one:       1010101

What is this number? It should be -4310, so let's expand it by hand to verify:

-1(2⁶) + 1(2⁴) + 1(2²) + 1(2⁰) = -6410 + 1610 + 410 + 110 = -43

Sure enough, the process works!

How Many Signed Binary Numbers Are There?

We've seen that in a signed binary system, the most significant bit is reserved for the sign. What does this do to our number range? Effectively, it halves it!

Let's consider 32-bit integers to give us a concrete basis for discussion. Whereas before we had 32 bits to work with for the magnitude of an unsigned number, we now have only 31 for the magnitude of a signed number:

Unsigned magnitude bits:  [31 30 29 ... 0]
Signed magnitude bits:    31 [30 29 ... 0]

We went from having 2³² numbers to 2³¹ positive and negative numbers, which is precisely half of what we started with!

More generally, if you have an N-bit signed binary string, there are going to be 2^N values, split evenly between 2^N-1 positives and 2^N-1 negatives.

Notice that the number zero gets bunched in with the positives and not the negatives:

Signed zero:  0  0  0  0 ... 0 0 0 0
Bits:        31 30 29 28 ... 3 2 1 0

As we're about to see, this has an interesting consequence.

What Is the Largest Signed 32-bit Integer?

The largest signed 32-bit integer is positive, meaning its leading bit is a zero. So we just need to maximize the remaining bits to get the largest possible value:

Num:      0  1  1  1 ... 1
Bits:    31 30 29 28 ... 0

This is 2³¹ - 1, which is 2,147,483,647. In Java, this number is stored in Integer.MAX_VALUE, and in C++, it's std::numeric_limits::max().

More generally, for an N-bit system, the largest signed integer is 2^N-1-1.

Why did we subtract a one at the end? Because as I mentioned in the previous section, the number zero gets grouped along with the positives when we split our number range:

Signed zero:  0  0  0  0 ... 0 0 0 0
Bits:        31 30 29 28 ... 3 2 1 0

So to get our largest signed integer, we need to subtract one—we've effectively "lost" a magnitude of one.

Real-World Application: Video Game Currency

In video games like RuneScape that use 32-bit signed integers to represent in-game currency, the max "cash stack" that you can have caps out at exactly 2³¹ - 1, which is roughly 2.1 billion.

Image source: YouTube

Now you know why! If you're wondering why they don't just use unsigned ints, it's because RuneScape runs on Java, and Java doesn't support unsigned ints (except in SE 8+).

What Is the Smallest Signed 32-bit Integer?

This occurs when we set the leading bit to be a 1 and set all remaining bits to be a 0:

Num:      1  0  0  0 ... 0
Bits:    31 30 29 28 ... 0

Why? Because recall that in the expansion of negative numbers in two's complement binary, the leading 1 is a -1 times 2^N-1, and a 1 in any other position will be treated as +1 times its corresponding power of two. Since we want the smallest negative number, we don't want any positive terms, as those take away from our magnitude. So we set all remaining bits to be 0.

Answer: -2³¹

In Java, this value is stored in Integer.MIN_VALUE.

In C++, it's in std::numeric_limits::min().

Generalizing things once again, if we have an N-bit system, the smallest representable signed int is -2^N-1.

Basic Arithmetic in the Binary Number System

Spoiler: Adding, subtracting, multiplying, and dividing numbers in the binary number system is exactly the same as it is in decimal!

Adding Binary Numbers

We'll first revisit what we learned in elementary school for decimal numbers and then look at how to add two binary numbers.

To add two numbers in the decimal number system, you stack them on top of one another visually and work your way from right to left, adding two digits and "carrying the one" as needed.

Now you should know what carrying the one really means: When you run out of digits to represent something in your fixed-base number system (e.g., 13 isn't a digit in base 10), you represent the part that you can in the current digits place and move over to the next power of your base (the "column" to the left of your current one).

For example, let's add 24 and 18 in decimal:

  24
+ 18
————
  42

We first add the 4 and 8 to get 12, which is not a digit we support in the decimal number system. So we represent the part that we can (2) and carry the remaining value (ten) over to the next column as a 1 (1 × 10¹ = 1010). There, we have 1 + 2 + 1 = 4:

      1  <-- carried
      24
    + 18
————————
      42

Now, let's add these same two numbers (2410 and 1810) using the binary number system:

  11000
+ 10010
———————
 101010

We work from right to left:

Ones place: 0 + 0 = 0
Twos place: 0 + 1 = 1
Fours place: 0 + 0 = 0
Eights place: 1 + 0 = 1
Sixteens place: 1 + 1 = 102 (two)

That last step deserves some clarification: When we try to add the two ones, we get 12 + 12 = 102 (two), so we put a 0 in the current column and carry over the 1 to the next power of two, where we have a bunch of implicit leading zeros:

               1      <-- carry bits
0000  ...    00011000
0000  ...  + 00010010
—————————————————————
0000  ...    00101010

In that column, 1 (carried) + 0(implicit) = 1.

If we expand the result, we'll find that it's the same answer we got over in decimal:

1(2⁵) + 1(2³) + 1(2¹) = 32 + 8 + 2 = 4210

Let's look at one more example to get comfortable with carrying bits in binary addition: 2210 + 1410, which we know to be 3610:

  10110
+ 01110
———————
 100100

Something interesting happens when we look at the twos place (the 2¹ column): We add 12 to 12, giving us two (102), so we put a zero in the 2¹ column and carry the remaining one.

Now we have three ones in the 2² column: 12(carried) + 12(operand1) + 12(operand2) = 112 (three). So we put a one in the 2² column and carry a one yet again. Rinse and repeat!

               1111    <-- carry bits
0000  ...    00010110
0000  ...  + 00001110
—————————————————————
0000  ...    00100100

Once again, it's a good idea to expand the result so you can verify your work:

1(2⁵) + 1(2²) = 3210 + 410 = 3610

Note: We've only looked at examples of adding two binary numbers, but you could just as well stack x numbers on top of one another and add them in binary, just like you would in decimal. How far ahead you need to carry your ones depends on the result that you get in a particular column, represented as a binary string.

Subtracting Binary Numbers

Subtraction is addition with a negative operand: a - b = a + (-b). Now that we know how to represent negative numbers in the binary system thanks to two's complement, this should be a piece of cake: negate the second operand and perform addition.

For example, what's 1210 - 2610? In decimal, we know this to be -1410. Over in binary, we know that 1210 is 01100. What about -2610? We'll represent that using two's complement.

We start by first representing 2610 in binary:

+2610 = 0110102

Now we negate it by flipping the bits and adding one:

26 in binary: 011010
Flipped:      100101
Add one:      100110  = -26

Stack up your operands and add them like we did before:

     11    <-- carry bits
    001100
  + 100110
——————————
    110010

Notice that the result has a leading one, which we know denotes a negative number in signed binary. So we at least got the sign part right! Let's check the magnitude:

-1(2⁵) + 1(2⁴) + 1(2¹) = -3210 + 1610 + 210 = -1410

See what I mean? Adding and subtracting numbers in the binary number system is just as easy as it is over in decimal.

Multiplying Binary Numbers

Let's remind ourselves how we multiply numbers in decimal:

  21
x 12
————

Remember the process? We multiply the 2 by each digit in the first multiplicand and write out the result under the bar:

  21
x 12
————
  42

Then we move on to the 1 in 12 and repeat the process, but adding a 0 in the right column of the result. Add the two intermediate products to get the answer:

   21
x  12
—————
   42
+ 210
—————
  252

Guess what? The process is exactly the same in the binary number system!

Let's multiply these same two numbers in binary. They are 2110 = 010101 and 1210 = 01100:

   010101
x   01100
—————————

Obviously, this is going to be more involved in binary since we're working with bits (and thus longer strings), but the logic is still the same. In fact, beyond having to write out so many intermediate results, we actually have it much easier over in binary. Whenever a digit is 1, you simply copy down the first multiplicand, padded with zeros. Whenever it's a zero times the first multiplicand, the result is zero!

      010101
x      01100
————————————
      000000
     0000000
    01010100
   010101000
+ 0000000000
————————————
  0011111100

Expanding this in binary, we get:

00111111002 = 1(2⁷) + 1(2⁶) + 1(2⁵) + 1(2⁴) + 1(2³) + 1(2²) = 25210

Easy peasy. The same process applies regardless of whether your multiplicands are signed or unsigned.

Dividing Binary Numbers

Let's divide 12610 by 1210 using long division:

    0 1 0 . 5
   _______
12 |1 2 6
  - 1 2
   ————
      0 6
    -   0
   ——————
        6 0
      - 6 0
      —————
          0

Answer: 10.5.

Now let's repeat the process over in the binary number system. Note that I'm going to strip leading zeros to make my life easier since we're working with two unsigned numbers:


      _______
1100 |1111110

Take things one digit at a time, and reference this useful YouTube video if you get stuck:

         0 0 0 1 0 1 0 . 1
        ______________
1 1 0 0 |1 1 1 1 1 1 0 . 0
        -0
        ——
         1 1
        -  0
        ————
         1 1 1
        -    0
        ——————
         1 1 1 1
       - 1 1 0 0
        ————————
             1 1 1
          -      0
        ——————————
             1 1 1 1
           - 1 1 0 0
           —————————
             0 0 1 1 0
             -       0
             —————————
                 1 1 0
                 -   0
                 —————
                 1 1 0 0
              -  1 1 0 0
                 ———————
                 0 0 0 0

Answer: 01010.1.

What does the 1 to the right of the decimal point represent? Well, in the decimal number system, anything to the right of the decimal point represents a negative power of ten: 10^-1, 10^-2, and so on.

As you may have guessed, in the binary number system, these are 2^-1, 2^-2, and so on. So .1 above really means 1(2^-1), which is 1 / 2 = 0.510 in decimal. And of course, the part in front of the decimal point evaluates to 1010.

That gives us 1010 + 0.510 = 10.5. So our answer using binary long division is exactly the same as the one we got over in decimal!

Integer Overflow and Underflow in Binary

What happens if you try to add one to the largest representable N-bit signed integer?

For example, if N = 32, we're really asking what happens if we try adding one to the largest representable 32-bit signed int.

Let's give it a shot:

    0111...11111
  + 0000...00001
————————————————

In the rightmost column, we'll get 12 + 12 = 102, so that's a zero carry a one. But as a result, all of the remaining additions will be 12 + 12 since we'll always carry a one until we get to the leading bit:

    11111111111  <-- carry bits
    0111...11111     (2^{N-1} - 1)
  + 0000...00001     (1)
————————————————
    1000...00000     (-2^{N-1})

And what number is that in signed binary? Hmm... Looks like it's the smallest representable negative number! What we've observed here is called integer overflow. When you try to go past the largest representable signed integer in a given N-bit system, the result overflows or wraps around.

What if we try to subtract one from the smallest representable N-bit signed integer? First, we'll represent -110 as a signed integer in binary:

1 in binary: 0000...00001
Flipped:     1111...11110
Add one:     1111...11111  <-- -1

Now let's add this to the smallest representable signed integer:

   1             <-- carry bits
    1000...00000     (-2^{N-1})
  + 1111...11111     (-1)
————————————————
  1|0111...11111     (2^{N-1} - 1)

Notice that the result carries an additional bit over, yielding a result that has N+1 bits. But our system only supports N bits, so that leading 1 is actually discarded. The result is the largest representable N-bit signed integer, and this is known as integer underflow.

Overflow and underflow are things you should be mindful of in programs that are performing lots of computations, as you may end up getting unexpected results.

The Binary Number System: Additional Topics for Exploration

That about does it for this introduction to the binary number system! We took a pretty in-depth look at decimal, binary, and hexadecimal, and I hope you now have a greater appreciation for the binary number system and the role that it plays in computing.

In reality, there's much more to learn beyond what we covered here. If you're curious, I encourage you to look into representing floating point numbers in binary using the IEE754 format.

I hope you found this helpful! If you struggled with anything in particular, please let me know and I'll try my best to help you out.

Semantic HTML: Building a More Accessible Web

Aleksandr Hovhannisyan — Fri, 31 Jul 2020 12:23:11 +0000

Note: This article was originally published on my blog. It has since been updated on my site.

Semantic HTML isn't just some buzzword that people throw around for no good reason—it's an important concept in front-end development that gives meaning to your HTML markup. When you use semantic HTML, you not only make it easier for sighted users to understand your markup, but you also help unsighted users who rely on screen readers to make sense of your content organization. This is just one part of creating a more accessible user experience.

In this guide, we'll take a look at everything you need to know about building a more accessible user experience through semantic HTML. We'll also touch on some more general accessibility best practices towards the end of the guide.

What Makes HTML Accessible?

Accessibility is a hot topic in front-end development, yet it's also frequently overlooked or executed poorly, even on some of the world's most popular apps and websites. Developers tend to design a user experience with sighted users in mind, forgetting about users who rely on screen readers. Worse still, they may end up using color combinations that have too low of a contrast, or violating a number of other HTML accessibility best practices.

Accessible HTML conveys meaning and content organization to both sighted and unsighted users. Moreover, it uses the right HTML elements for the task at hand, rather than trying to force an element into a different role. Part of creating an accessible user experience means learning how to make the most of semantic HTML.

Unfortunately, developers tend to fall into a number of common traps that violate HTML accessibility best practices. In the following section, we'll take a look at how to use semantic HTML to create an accessible user experience.

Semantic HTML Basics

So let's just clear this up now—there are only two non-semantic HTML elements: <div> and <span>. By definition, this means that anything else is semantic HTML: an element that has some sort of inherent meaning. Some of these are depicted below:

Think of <div>s and <span>s as generic containers: They're simply there for grouping things at either the block or inline level. Beyond that, you can't really attach any meaning to a div: It's just a box.

With all of that in mind, is it fair to say that the term "semantic HTML" a bit overused? Yes—one could argue that there's no need to talk about semantic HTML when pretty much 99% of HTML is semantic.

However, just because <div> and <span> are the only non-semantic HTML elements out there doesn't mean that it's less likely for people to abuse them, rather than using the right HTML elements for the task at hand.

Before we move on, let's do a quick recap of the most notable semantic HTML elements and how they should be used on a website.

Main

The <main> element represents the main content region of a website:

Typically, you'll want to wrap everything in <main> except for your navigation header and footer. Also, note that a page should only ever have one <main> present to avoid confusing screen readers and search engine crawlers.

Header and Footer

You can think of the <header> element as a container for certain "visible metadata" on your page. For example, you can use it at the top of an article to group your title, publication date, tags, and so on. You can also use header elements at the top of material cards, where you'll usually find things like thumbnails, titles, and other descriptive information about the card and its contents. Finally, you can also wrap your site's navbar in a <header> to set it apart from the main content of your site. If a <header> element is at the very top level of your HTML and is not a descendant of other semantic HTML elements, it'll have an implicit aria role of banner, meaning screen readers will say something like "banner landmark" when they encounter it.

On the other hand, a <footer> should be used for anything that logically follows your content, essentially providing additional information. For example, you can wrap an About the Author section in a footer, or a "you may also like" section at the end of an article. Of course, it should also be your go-to element for the literal footer of your website.

The only thing to keep in mind is that <header> and <footer> should never appear as children of each other. In other words, never put a header in a footer, or vice versa.

Article and Section

Simply put, an <article> is a self-contained piece of content that people would understand if you were to redistribute it externally. This means that blog posts, articles, and forum threads are a perfect use case for the <article> element.

On the other hand, <section> represents... well, a section. This one typically confuses people because they're not sure what the difference is between a <section> and a plain old <div>. What makes a section inherently semantic? Well, for one, sections typically have a heading. And if you omit one, you'll get an HTML validation warning. Sections are good for things like:

Comment sections at the end of an article.
The literal sections of a blog post or article, as delineated by headings.
"Chapters" (this one is brought up frequently, but it makes little sense in the context of the web).

Don't use a <section> just to avoid using a <div>. There's nothing taboo about using divs, so long as you're not misusing them.

Nav

Simply put, use a <nav> to group primary or secondary navigation links, either in your top navigation bar or a table of contents, sidebar, breadcrumb links, and so on. Note that you shouldn't stick every single link on your site in a <nav>. Just because something is a link does not mean that it's part of some navigation on your site. So while it's perfectly fine to use multiple <nav>s on your site, you should use this element sparingly and only if it makes sense to do so.

Other Semantic HTML Elements

When talking about semantic HTML, people usually stop at just the generic bunch: nav, main, article, section, header, footer, and aside. But remember: Everything is semantic except for divs and spans. Here are some of the more notable elements:

Forms and their inputs (<form>, <input>, <button>, <textarea>).
Text: anchors (<a>), paragraphs (<p>), lists (ul/ol/li), headings (h1-h6).
Inline markup (e.g., <strong>, <em>, <mark>).
Images (<img>), figures (<figure>), tables (<table>), audio (<audio>), video (<video>).

... and much more. I won't delve into everything here. In a nutshell, any element that can be described as more than just a generic "container" is considered to be semantic HTML.

Creating an Accessible User Experience with Semantic HTML

Now that we've done a quick review of what semantic HTML is, we're ready to look at examples of what you should and should not do in order to create an accessible user experience. For a list of browsers that support HTML accessibility, check out html5accessibility.com.

Don't Use Divs for Interactive Elements

Using divs for user interactions is a terrible practice for web accessibility. In other words, don't do this:

<div tabindex="0" role="button" id="toggle"></div>

If an element's role is <button>, it may as well just be a <button> to begin with.

Worse still, don't add an event listener that checks to see if the user pressed the Enter key as a pseudo-click (I've definitely never done this):

document.getElementById('toggle').addEventListener('keyup', keyEvent => {
    if (keyEvent.key === 'Enter') { 
      doSomething();
    }
});

Just because something is possible with JavaScript and HTML doesn't mean that it's a good idea 😉 (or that it's truly accessible for keyboard and screen reader users). You certainly can do this, but it will take some work to ensure that it's truly accessible. And even then, you'll still get HTML validation warnings because you're trying to dress up a <div> as something that it's clearly not.

Use buttons, anchors, and form inputs for interactive elements on your website. These semantic HTML elements already receive mouse and keyboard focus, have widespread browser support, and respond to user input both with the Enter key and with a traditional mouse click. They are meant to be used as buttons, links, checkboxes, and so on.

Unfortunately, this rule is broken frequently on the web, mainly because of JavaScript frameworks.

Twitter's buttons are divs all the way down (they're using role="button" here):

Gmail also uses divs for its buttons:

Facebook's like button is a div with an image inside it:

But there are sites that do get this right!

The StackExchange network uses <button> elements with nested SVGs:

As does the new Reddit interface (the old one is still using divs):

Q: Should I Use an Anchor or a Button?

This is a good (and common!) question, mainly because developers are concerned with how their user interfaces look. And the answer is simply that it depends on what the button does. If it directs someone to a different page, then that's really an anchor's job; the only way to do it with a button is via JavaScript. So it's perfectly fine to use an anchor in this case and to style it like a button.

Remember: To an unsighted user navigating your site, it won't be important what an element looks like, but rather what the element does. The best that a screen reader can do is to tell you what it is that you've encountered on a page. A screen reader can't possibly infer that a regular old <button> will take you to a different URL—that's the job of an anchor, after all.

So, if your "button" is supposed to direct users to a different page, using <button> would create a frustrating user experience for unsighted people, especially if the button text doesn't clearly indicate that clicking it will take you to a different page or site. In fact, this would be frustrating for sighted users, too, since anchors show a link preview in the bottom-left of your browser when they receive focus or hover events, whereas a button that "silently" directs a user to a different page will not show any such indicator upon focus/hover.

Now, on the other hand, if the button doesn't direct a user to a particular site, then it's perfectly fine (and more sensible) to use <button>. Add a JavaScript click listener to dictate what happens when a user clicks that button. Here are some examples:

Toggle an option or setting.
Serve as a button in a game.
Submit a like/upvote on a particular post.
Submit a comment/post on a site.

Note that some buttons have inherent functions in HTML. For example, a button with type="submit" is used in forms to trigger a form submission event. In this particular use case, an anchor or div would be a completely inappropriate and hacky substitute.

Use More Lists!

I have to say: <ol> and <ul> are probably the two most underrated semantic HTML elements out there. Things are listed are everywhere on the web, yet you rarely see them rendered using lists!

A screen reader won't detect that a <div> is a collection of ordered or unordered items because divs convey absolutely zero meaning—they're not semantic HTML. Note that a <div> has no implicit ARIA role, meaning a screen reader won't narrate anything special when it encounters that <div> (but it will still read its contents). This means that if you have multiple, separate <div>s that each serve as lists, their items will meld together when narrated, and that could get confusing.

On the other hand, when it encounters an <ol> or <ul>, a screen reader will explicitly tell a user that there's a "list with X elements" up ahead. Moreover, the screen reader will narrate when it has exited a list (e.g., NVDA says "out of list"), giving an unsighted user a better sense of where they are on the page.

Here are a few great use cases for HTML lists:

Navigation links in menus and sidebars.
Feeds and posts (e.g., blog posts, social media feeds, forum posts, replies and comments). In most cases, you'll want to use an ordered list since these items are usually sorted by a given parameter, like date published.
Pagination trails. A pagination trail is literally a numbered list of pages—it doesn't get any simpler than that!
Grouped tags and links (e.g., post tags or social media links). Use unordered lists!

Just because lists render with bullet points or numbers by default doesn't mean that they must be reserved for textual lists. In terms of semantic HTML, a list is the perfect container for a group of related items, ordered or not.

The best part is that <li> elements, like <div>s, can accept any flow content (block or inline), including more nested lists. You have nothing to fear with these elements. You should already be resetting margin and padding on your website anyway, so the only thing that remains is resetting list-style and customizing the appearance of your lists on a case-by-case basis.

Let's take another look around the web!

Google renders search results using divs, but an ordered list would probably make more sense here since the top search results are not there by coincidence (i.e., the ordering matters):

Note: Google has hidden elements that provide accessibility guidance to users with screen readers and other assistive technologies, so this "violation" isn't really a big deal. That may apply to some of the other sites and apps, too, though I haven't tested them.

Twitter uses divs for replies:

So does Reddit, both for its old and new interfaces:

StackOverflow gets it right again, using an unordered list for comments (though an ordered list may make more sense here since comments are sorted by the date they're posted):

And so does Spotify, where songs are rendered in an ordered list:

Here's another great example of using a list properly, this time from GitHub:

Notice from these examples that a "list" is really an abstract concept. You shouldn't view <li> as an element that can only contain text. Clearly, it can also contain links, buttons, more lists, images, and anything else that you can think of.

Don't Use Spans for Inline Positioning

Another common mistake is to use <span>s to achieve inline positioning. Developers are taught early on that there's a distinction between block-level and inline elements in HTML; the two classic examples that get brought up are divs and spans, respectively. But while it's true that spans are inline elements, they're not intended to be used for inline positioning. Spans are used to isolate inline portions of text, typically for one of two reasons:

Styling some of the text differently.
Injecting content into the text with JavaScript.

A good example of the second case is if you have text with placeholders, like X comments or X posts, and those placeholder counts need to get set via JavaScript (e.g., once an API call finishes). You'd isolate the placeholders with spans and give them IDs so their text can get set. Here's a real example of that from GitHub's own UI:

In addition, note again how the tabs themselves are rendered in a list. Yay!

If you want inline positioning on block-level elements, <span> is not the right tool for the job. Instead, use CSS to position your elements inline (e.g., with Flexbox).

Don't Abuse ARIA

You may have heard the term "ARIA" used in the context of HTML, but what exactly does it mean?

As defined by the W3 Consortium, ARIA stands for Accessible Rich Internet Applications. It's a set of built-in HTML attributes that developers can use to provide a better user experience to people using assistive technologies like screen readers.

However, as I mentioned before, just because something is available to you doesn't mean that you should abuse or misuse it. Per W3's documentation on ARIA:

Web developers MAY use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in wai-aria-1.1, except where these conflict with the strong native semantics or are equal to the implicit ARIA semantics of a given HTML element. These constraints are intended to prevent developers from making assistive technology products report nonsensical user interface (UI) information that does not represent the actual UI of the document.

Here, "strong native semantics" refers to the fact that semantic HTML elements have intrinsic ARIA roles. You can explore these in the MDN Web Docs for a particular element. For example, the <ol> tag has an implicit ARIA role of list:

Notice that elements also have a set of permitted ARIA roles and permitted content. For example, the descendant of an <ol> or <ul> should only ever be one of <li>, <script>, or <template>—anything else, and an HTML validator will give you an error. Here's an example of such an error:

Element div not allowed as child of element ol in this context.

"Permitted ARIA roles" goes back to the whole "don't use divs as buttons" argument, though it encompasses a much wider issue of misusing elements in general or trying to get an element to masquerade as something completely different. HTML has a diverse set of semantic elements that you can use to build most user interfaces that come to mind—don't resort to hacks.

Use the Right Heading Levels for Your Content

Have you ever used a lower heading level, like h5 or h6, simply because you needed the text to be a smaller font size? While headings do have default font sizes, you shouldn't just pick a level based on the font size that you need. HTML headings communicate your content's hierarchy to screen readers, search engine crawlers, and HTML validation tools. Basically, don't skip levels and go from an h2 to an h6. Imagine how confusing it would be for someone using a screen reader to hear that your content jumped from heading level two to six all of a sudden! Without seeing your site, they'd think that something must've gotten lost in translation.

Use the `<time>` Element for Dates

This is another underrated semantic HTML element. Basically, use the <time> element for dates and times. For example, you can wrap the publication date in a <time> for a forum post, blog post, article, video, and so on.

GitHub uses web component extensions for the <time> element in its UI:

StackOverflow uses <time>:

And so does Twitter:

It's certainly not the end of the world if you don't use <time>, so long as the date itself is part of some other semantic element (e.g., a paragraph or heading) that will make sense in the context in which it's narrated.

General Tips for HTML Accessibility

Semantic HTML is just one piece of the accessibility puzzle—there's a lot more that goes into creating a better user experience on your site. Let's go over some of the finer details.

Don't Overuse the `title` Attribute

Native tooltips should not be relied upon to give users any indication of what an interactive element represents. Moreover, don't combine it with an aria-label because both may end up getting narrated by a screen reader, and that can get really annoying.

Give Images a Descriptive `alt` Attribute

It helps to close your eyes for a moment and imagine that you're hearing the words that you type. You want to paint a picture without going into excessive detail, like mentioning colors, shapes, and so on (unless those are the central focus of the image). You also don't want to start your alt attribute with "An image of..." or "A picture showing..." because that's already a given (screen readers will narrate the <img> tag as a graphic/image).

Use `aria-hidden` and `alt=""` Strategically for Certain Images

Sometimes, you want to hide content from screen readers to avoid presenting irrelevant information to unsighted users. Examples include blog post thumbnails and user avatars. While these elements are usually visible to the sighted user, they're not essential for an unsighted user and can sometimes confuse screen readers. Imagine how annoying it would be if a screen reader were to say Profile photo for user X and then immediately follow that up by reading the user's name—it's repetitive. For this reason, you can use the aria-hidden attribute, or simply set the image's alt tag to be empty. Alternatively, you can use background images (unless you need lazy loading).

Mind Your Color Contrast

So far, the focus has been on making the web a more accessible experience for unsighted users. But that doesn't mean that you should neglect your sighted users. In particular, you'll want to follow best practices with regard to color usage on the web. Here are some general tips:

Stick to one or two colors for your theme. Shades of a single primary color are usually more than enough and can give your site a more cohesive and branded look.
Use colors to convey a sense of elevation and content hierarchy. For example, an element that's lighter than its background is typically perceived as being elevated, while a darker element is depressed into the page. This is especially true for dark mode themes.
Don't use font weights or colors that reduce the contrast between your primary text and its background. You want to maintain at least WCAG AA compliance.

Use Responsive Typography

Smashing Magazine has an excellent guide on responsive and fluid typography, which is about ensuring that your font size scales up and down smoothly (like it does on this site!) depending on the screen width. That way, it's not too large on a mobile device, but it's sufficiently large on a tablet or desktop. Stick to using a minimum font size of 16px for your primary body text and around 12–14px for secondary text. Anything smaller than 12px is going to be terribly difficult to read on a mobile device. At the same time, you don't want your font size to be too large, especially on mobile.

Building a More Accessible Web: Next Steps

I highly recommend that you install a screen reader yourself to audit your own site for accessibility issues. Follow along with the narration. If nothing seems to make sense or flow right, then you have a problem. I personally prefer the NVDA screen reader; it's free and easy to use.

There's also a fantastic tool called WAVE that basically runs an accessibility audit on any given URL and shows the results right there in an interactive session.

I hope you found this guide helpful! If you have any questions, let me know down below.

How to Escape Tutorial Purgatory

Aleksandr Hovhannisyan — Sat, 09 May 2020 14:55:04 +0000

Note: This is a syndicated post. If you'd like to, you can view the original on my dev blog.

We've all been there before: You follow one tutorial after another hoping to find some sense of accomplishment or fulfillment as a developer. Instead, you walk away feeling unsated—hungry for something practical to sink your teeth into. But you never really find it. What you do find is existential panic: Am I cut out for this? When will I actually amount to something as a developer?

Welcome to tutorial purgatory, friend. It's a bit like being chained to a post—you see a world of opportunity spread before you, teasing your imagination, but you can only travel so far before you're reminded of the cold iron wrapped around your ankles.

Stuck in tutorial purgatory? Here are my suggestions for how to escape this hell.

Use Tutorials as a Guide

"Thou follow me, and I will be thy guide" —Virgil, The Divine Comedy

Think about whether you do any of these things when watching or reading dev tutorials:

Blindly copying and pasting code from the tutorial into your own environment.
Cloning starter files from an associated repo that already contain setup code (e.g., HTML or CSS).
Coding along with the tutorial, and finding yourself bored in the process.
Simply following the tutorial without doing any coding yourself.

These are fatal mistakes that will only prolong your sentence in tutorial purgatory. If you're looking to learn something new or to find inspiration to start your own projects or sandboxes, then a tutorial should merely be treated like an answer key on an exam: It shows you the answer, but it should only be referenced once you've made an attempt to solve the problem yourself.

Let's consider WesBos's JavaScript30 course—it's a great way for JavaScript developers to sharpen their vanilla JS skills. But you shouldn't just watch the videos and code along. And you certainly shouldn't use the starter files that Wes provides, except for assets like audio files that you'd have to obtain yourself.

What should you do instead? Use the tutorial for inspiration: Watch the first few minutes to understand what you're tasked with building, but pause it as soon as it starts diving into the implementation details. At this point, you have a rough UI "mockup" to work toward building yourself.

Start from scratch on your own environment and give the problem your best, most creative attempt. If you get stuck, don't immediately give in and watch the video. Instead, research whatever problem you've run into. By now, it's almost guaranteed that whatever issue you're faced with has been documented on StackOverflow or Reddit. Only once you have a working solution should you then resume following the tutorial, comparing your attempt to the solution.

This approach teaches you a fundamental, invaluable skill: learning independently. You need to be able to solve problems on your own and come up with your own solutions. Failure is perfectly acceptable as long as you reflect on it and learn from it.

Who knows? Maybe your solution is even better than the tutorial's. And if it's worse, or you overlooked certain edge cases, then you'll learn from those mistakes, and the entire experience will be far more memorable than if you had just blindly followed the tutorial from the beginning.

Stop Trying to Learn Things That Don't Interest You

I recently came across a fantastic article by Dave Geddes about an experience that developers are all too familiar with: Trying to learn a new technology without any particular goal in mind, struggling to understand why that technology is needed in the first place or how it's supposed to be used, and then venting on the internet because the entire experience has made them feel stupid.

All tools that humans created have one thing in common: They solve a problem. And they're mainly intended to be used by people who have already struggled with said problem. Otherwise, their importance is lost upon the user.

<img src="https://www.aleksandrhovhannisyan.com/assets/img/posts/how-to-escape-tutorial-purgatory/tools.png" alt="xkcd comic about tools">
<figcaption>Source: <a href="https://xkcd.com/1629/">xkcd</a></figcaption>

Beginners force themselves to learn X technology because it's been dangled in their face as the Carrot of Career Growth and Endless Financial Opportunities™. They don't exactly know why they need React, but they can sure as hell regurgitate what other people have told them about it—that it has a virtual DOM, and that having virtual DOMs is... well, a really good thing... to have.

Haven't you ever wondered how things were done without these fancy new technologies or what problems they actually solve? Imagine how many poor, helpless souls could've saved themselves a few hours of torment on StackOverflow if only they had learned JavaScript before dipping their toes in React. Imagine knowing how to harness the power of vanilla CSS and CSS preprocessors instead of handicapping yourself with bloated CSS frameworks like Bootstrap and Tailwind that make my eyes bleed when I read your HTML.

You are, of course, free to learn whatever you want and whenever you want. But pace yourself, and understand the utility of whatever you are learning—these are two of the many keys to escaping tutorial purgatory.

Stop Splurging Money on Courses

For just several hundred dollars, and sometimes thousands over the course of a year, you too can learn Python, React, everything—all the things—and land your very first job as a software developer!

Paid subscriptions to courses are, in my honest opinion and personal experience, the absolute worst thing to ever happen to the Learn to Code industry. They're built for instant gratification—to reward buyers with a sense of accomplishment at checkout and to make them feel like they've taken their first step toward mastering a new skill.

Some people learn best with courses, and that's fine. But there's a certain type of junior developer who doesn't know any better—who equates learning with spending money and earning certifications.

I've written about this before, and I'll say it again: Don't waste money buying courses when there's such a wealth of free information available online. Price tags don't imply any inherent value.

Take a Break

You know what's so great about software development? The fact that there's something in it for everyone. You know what's not so great? It's... really difficult to find that thing.

I sometimes feel like this industry is a sea of oddly shaped locks, and in my hands I hold a pair of keys that don't appear to fully fit in any of them. Most days, I'm passionate about frontend and everything CSS. Other days, my mind is tempted by the allure of mobile app development, machine learning, networking, game dev, and a host of other distractions that I dabble in for minutes at a time, and then quickly abandon.

Does it help that technology is moving so quickly? You've heard this before, so pardon the repetition, but there's a new JavaScript framework born every minute. Will React still be relevant in a few years? What about Vue? Insert X language, framework, etc., and you're confronted with the same problem. Now WebAssembly is the new kid on the block. How do you keep up with all of it?

Be honest: How many more to-do list app tutorials can you tolerate before you lose your sanity? More importantly, are you going to remember any of these things tomorrow or a week from now, or are you only learning them after someone mentioned that you should because reasons?

Sometimes, it helps to just step away from it all for a day or two and put your mind at ease. I get that you're passionate about development, but it shouldn't consume your entire existence. Listen to music, read, watch a movie, play video games, write, work out, and do just about anything but dev 24/7/365.

Tutorial purgatory is a phase—you'll eventually find your calling, work on meaningful projects, and land the job you've dreamed of.

In the meantime, it certainly doesn't hurt to follow a tutorial now and then to sharpen your skills or learn new things. But don't allow tutorials to become a crutch.

Getting Started with Jekyll and GitHub Pages: Your First Website

Aleksandr Hovhannisyan — Sun, 01 Mar 2020 16:27:39 +0000

Note: This is a syndicated post, and a very long one at that! If you'd like to, you can view the original on my dev blog.

Want to make a personal website or blog and share it with the world? Then you've come to the right place! This is the only guide you'll need for getting started with Jekyll. I'll take you from zero to hero with Jekyll and help you understand all the fundamentals.

I moved my old site from pure HTML and CSS to Jekyll a while back and immediately fell in love. There's very little that Jekyll doesn't allow you to accomplish, so it's a perfect, lightweight option for beginners and veterans alike.

Note that some parts of this tutorial assume that you'll be hosting your site with GitHub Pages. If instead you're hosting your site with Netlify or another service, the process should be very similar, and the core concepts of building a site with Jekyll certainly won't change.

All right, enough chit-chat—let's dig in!

Overview: What Is Jekyll?
How to Set Up GitHub Pages
Getting Started with Jekyll
- 1. Installing Jekyll
- 2. Setting Up Your First Jekyll Site
- 3. Configuring Jekyll with GitHub Pages
- 4. Running Jekyll Locally
- 5. Pushing Your Site to GitHub
Typical Jekyll Directory Structure
Configuring Your Jekyll Site
How to Create Pages in Jekyll
- What Is Markdown Front Matter?
- Front Matter Defaults
Where Do I Put My Pages in Jekyll?
Jekyll Blog Posts
- Permalinks to Blog Posts in Jekyll
- You Don't Need an Explicit Date Variable
- Blog Post Front Matter Variables
- Syntax Highlighting
Dr. Jekyll and Mr. Liquid
- Data Types
- Template Tags
- Variables
- Control Flow
- Objects
- Operators
- Filters
Using Jekyll Layout Files to Structure Pages
- Using More Than One Layout
Writing CSS in Jekyll Using SASS
- Modular CSS with SASS Imports
Creating Reusable Components with Includes
Taking Advantage of Jekyll Data Files
- Example 1: Skills and Abilities
- Example 2: Author Bios
- Example 3: Tag Descriptions
Setting Up Google Search Console
- Is It Safe to Upload the Google Search Console Verification File?
GitHub Pages Support for Jekyll Plugins

Overview: What Is Jekyll?

Jekyll is a static site generator. That's just a fancy way of saying that it takes a bunch of HTML, Markdown, CSS, and JavaScript source files, combines them as needed based on layout files that you've specified, processes any template code that you've written, and spits out a build directory (e.g., _site/) that basically houses all of your website's content, ready for hosting on a web server (like GitHub Pages!).

In plain English, Jekyll makes it easy for you to create a website—and, more commonly, a blog—with plain old HTML and Markdown, without having to worry about things like how to add tags to posts or make certain static data accessible on all of your pages. It takes care of these things for you so you can focus on doing what you love the most: writing (or, in my case, writing and dev)!

GitHub Pages, on the other hand, is a free hosting service for static sites that's offered by GitHub to all of its users. And since GitHub accounts are practically free real estate, there's really never been a better time to make your very own website or blog.

The best part? GitHub Pages supports (and even recommends) Jekyll out of the box, meaning you can set up a Jekyll project right now, push the source code to a GitHub repository, and view the live website!

How to Set Up GitHub Pages

If you've already set up your GitHub Pages repo, feel free to skip this section.

You can create as many GitHub Pages sites as you want. Each user can only create one site whose domain is https://yourUsername.github.io. All other repo sites go under https://yourUsername.github.io/repoName. GitHub even lets you configure your own custom domain if you have one.

To get started, visit https://github.com/, sign in, and click the green New button to create a new repo:

Enter the name of your repository. It needs to be your GitHub username followed by .github.io:

That's literally all you have to do to get started with GitHub Pages! As with other repos you own, you'll want to clone it locally and set up your origin remote.

If you want to use any starter themes, GitHub goes over those in its documentation for GitHub Pages. Disclaimer: I'm not sure how these work with Jekyll, so you're on your own if you take that route.

Getting Started with Jekyll

Now that we've set up GitHub Pages, we'll go over everything you need to know to get started with Jekyll. For the remainder of this tutorial, I'll assume you're using Bash as your terminal, either on a Mac/Linux or with the Windows Subsystem for Linux (WSL). I'm sure there's a reasonably painful way to do this all on a Windows terminal like PowerShell, but I wouldn't advise it... because Windows.

1. Installing Jekyll

Jekyll has an excellent, in-depth installation guide for each OS, so I'll let you read that instead of copy-pasting it all here. If you follow the Ubuntu guide, which is what I use via WSL, you'll install these three things:

Ruby, the programming language that powers Jekyll.
Bundler, a Ruby gem (think "module") that lets you manage your project's dependencies with ease.
Jekyll, obviously.

If you're familiar with npm and yarn, Bundler is basically the same idea except for Ruby—it manages your dependencies (gems) via two files called Gemfile and Gemfile.lock, which we'll see shortly.

2. Setting Up Your First Jekyll Site

Assuming that everything went well, it's time to make your first Jekyll site.

Running this command will set up a folder named mysite with all of the necessary starter files and directories:

bundle exec jekyll new mysite

If you already have existing source files in a project directory for your site, you can instead run this:

cd mysite
bundle exec jekyll new . --force

Warning: The second option may end up overwriting existing files. Alternatively, you could set up the project in a different directory and copy over the files when it's done so you have more control.

The end result should be this simple directory structure:

3. Configuring Jekyll with GitHub Pages

Go ahead and open up the Gemfile at the root of your project. You'll find useful comments in there to help you configure Jekyll with GitHub Pages:

Gemfile:

source "https://rubygems.org"

# Hello! This is where you manage which Jekyll version is used to run.
# When you want to use a different version, change it below, save the
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
#
#     bundle exec jekyll serve
#
# This will help ensure the proper Jekyll version is running.
# Happy Jekylling!

# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
# uncomment the line below. To upgrade, run `bundle update github-pages`.
gem "github-pages", group: :jekyll_plugins

# If you have any plugins, put them here!
group :jekyll_plugins do
  gem "jekyll-feed", "~> 0.6"
end

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
# and associated library.
install_if -> { RUBY_PLATFORM =~ %r!mingw|mswin|java! } do
  gem "tzinfo", "~> 1.2"
  gem "tzinfo-data"
end

# Performance-booster for watching directories on Windows
gem "wdm", "~> 0.1.0", :install_if => Gem.win_platform?

First, remove this line if you intend to publish your site on GitHub Pages:

gem "jekyll", "~> 3.8.6"

And then uncomment the line specifying the github-pages gem:

# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
# uncomment the line below. To upgrade, run `bundle update github-pages`.
# gem "github-pages", group: :jekyll_plugins

I also recommend removing this line to get rid of the default minima theme:

# This is the default theme for new Jekyll sites. You may change this to anything you like.
gem "minima", "~> 2.0"

If you do that, you'll also need to remove it from _config.yml by setting the theme to null:

# ...

# Build settings
markdown: kramdown
theme: minima # replace minima with null
plugins:
  - jekyll-feed

# ...

If you don't use theme: null, the github-pages gem will automatically generate a default stylesheet, /_site/assets/css/style.css, that's about 3k lines long, and that you may not want or need for your site. I recommend setting the theme to null so you have control over your styling, but this is up to you.

After doing all of that, run this command to install and update all necessary gems for your site:

bundle install

If all went well, you should see output similar to this:

Bundle complete! 5 Gemfile dependencies, 85 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

You should also now see a Gemfile.lock file at the root of your project. This is like the package-lock.json that npm generates, if you've ever worked in a Node ecosystem. This lockfile gets created the first time you run bundle install, ensuring that anyone who runs the same command in the future installs the exact versions specified in there. That way, everyone's on the same page.

4. Running Jekyll Locally

Let's fire her up and see what we've got:

bundle exec jekyll serve --livereload

By default, this runs your site on localhost:4000 with live-reloading enabled, so if you make changes to your files, Jekyll will regenerate the build directory and automatically refresh your page.

You can change the port in one of two ways. The first is to specify the --port argument:

bundle exec jekyll serve --livereload --port 4001

The second is to add this line somewhere inside your project's _config.yml file:

port: 4001

Note: You can leave the port as 4000 by default. This is just useful to know in case you want to run two Jekyll sites simultaneously on your local since they can't both be on the same port.

Head on over to localhost:4000 to see the starter page. Note that the appearance of this page depends on how you configured Jekyll in the earlier sections. You may see:

The minima theme, which has the most starter content, if you left theme: minima as is.
A mostly blank page with a title placeholder if you deleted the line theme: minima.
A completely blank page, if you set theme: null explicitly like I recommended.

The remainder of this tutorial assumes that your theme is set to null. Some of the screenshots I show may not line up with what you see on your end if you decide to use the minima theme. You may also miss out on learning some useful things about how Jekyll works if you decide to use one of the starter themes instead of writing your own CSS.

5. Pushing Your Site to GitHub

If you haven't already done so, push your Jekyll site to GitHub Pages:

git add . && git push

Then, simply visit https://yourUsername.github.io to view the live version of your website.

Congratulations! If you're with me so far, you're done with the hard part. Now, it's time to actually learn how to customize your site. It's important to step out of your comfort zone. Don't worry if you accidentally "break" a file—just undo those changes with Git.

Typical Jekyll Directory Structure

The Jekyll starter is a bare-bones site. In reality, you're going to need more Jekyll-supported directories for different kinds of tasks:

_data: Where you can store data files for things like skills, projects, work history, and so on.
_drafts: Add this to your .gitignore and store your blog post drafts in here (optional).
_includes: Where you define Jekyll includes, which are sort of like reusable HTML components.
_layouts: HTML layouts define the structure of your site and can be nested in one another.
_posts: Where you'll store all of your blog posts as Markdown files.
_sass: This is where your SASS partials go. You'll then need to import them in _assets/main.scss.
_site: Jekyll's auto-generated build directory, which houses your final, compiled site. It's not pushed to GitHub because it's in .gitignore.
_assets: Mainly for storing images and scripts, but it can also house a main CSS file.

You may be wondering why all of these directory names are prefixed by an underscore. A directory with a leading underscore is special and won't get processed by Jekyll. As a result, it won't appear in the build directory, _site/.

If none of this makes sense to you right now, or if all of this seems overwhelming, don't worry—I'm going to walk you through most of it step by step. Also note that you are free to add any other directories that you need.

Configuring Your Jekyll Site

We already saw that you can edit your Jekyll starter theme in _config.yml, but that's not all that this file allows you to do. In fact, this file houses your entire site's configuration settings. Here's what mine looks like so far:

_config.yml:

# Welcome to Jekyll!
#
# This config file is meant for settings that affect your whole blog, values
# which you are expected to set up once and rarely edit after that. If you find
# yourself editing this file very often, consider using Jekyll's data files
# feature for the data you need to update frequently.
#
# For technical reasons, this file is *NOT* reloaded automatically when you use
# 'bundle exec jekyll serve'. If you change this file, please restart the server process.

# Site settings
# These are used to personalize your new site. If you look in the HTML files,
# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
# You can create any custom variable you would like, and they will be accessible
# in the templates via {{ site.myvariable }}.
title: Your awesome title
email: your-email@example.com
description: >- # this means to ignore newlines until "baseurl:"
  Write an awesome description for your new site here. You can edit this
  line in _config.yml. It will appear in your document head meta (for
  Google search results) and in your feed.xml site description.
baseurl: "" # the subpath of your site, e.g. /blog
url: "" # the base hostname & protocol for your site, e.g. http://example.com
twitter_username: jekyllrb
github_username:  jekyll

# Build settings
markdown: kramdown
theme: null
plugins:
  - jekyll-feed

# Exclude from processing.
# The following items will not be processed, by default. Create a custom list
# to override the default setting.
# exclude:
#   - Gemfile
#   - Gemfile.lock
#   - node_modules
#   - vendor/bundle/
#   - vendor/cache/
#   - vendor/gems/
#   - vendor/ruby/

We'll understand how all of these settings are used once we cover the Liquid templating language. For now, just keep in mind that you can access most of these settings on all of your pages via a globally exposed site variable in a language called Liquid: site.title, site.description, site.url, and so on.

Go ahead and fill in most of these setings (you could also do this later—there's no rush). Additionally, note that you don't need many of the variables that are defined in here, like your email, Twitter username, GitHub username, or your site's base URL, so you can safely delete them. You can also add any other site variables that you'd like.

Note: If you make any changes to this file, you'll need to stop running your site and restart it to see the changes. This is because Jekyll only processes _config.yml once when you execute jekyll serve and doesn't listen for changes. You shouldn't have to change your config too often.

We'll come back to _config.yml in a later section once we've looked at some other Jekyll basics.

How to Create Pages in Jekyll

If you have any experience working with plain old HTML to create sites, you should be familiar with creating an index.html file and placing it at the root of your project directory. This is the page that your web server will send back when the client requests your site's root URL (e.g., https://myawesomesite.github.io/).

In your project directory, you should see a mostly empty file named index.md that looks something like this:

index.md:

---
# Feel free to add content and custom Front Matter to this file.
# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults

layout: home
---

Files ending in .md (or .markdown) are written in Markdown, a widely used markup language that just gets compiled down to HTML. Since it has such a simple syntax, Markdown is often favored in static site generators like Jekyll, Hugo, and GatsbyJS, especially for writing blog posts.

You should be familiar with Markdown if you've ever created a README.md file for your repo or posted anything on StackOverflow, which uses a modified Markdown parser. Note that Markdown is, in a sense, "backwards compatible"—you can still write raw HTML in a Markdown file.

Jekyll uses a modified Markdown parser called kramdown, as noted in _config.yml:

# Build settings
markdown: kramdown

Kramdown extends Markdown with some useful features, like adding classes and IDs to elements without having to resort to the HTML syntax.

Before moving on, let's modify index.md as follows:

index.md:

---
# Feel free to add content and custom Front Matter to this file.
# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults

layout: home
---

# Hello, Jekyll!

If live-reloading is enabled, you should see your page update automatically to display an h1 tag. Otherwise, you may need to refresh manually to see this change.

As I noted earlier, you can optionally also use plain HTML to get the same result:

index.md:

---
# Feel free to add content and custom Front Matter to this file.
# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults

layout: home
---

<h1 id="hello-jekyll">Hello, Jekyll!</h1>

Notice that we have to specify the ID explicitly with HTML, whereas Markdown does it automatically for us. If you wanted to, you could achieve the same result using Kramdown's ID specifier:

index.md:

---
# Feel free to add content and custom Front Matter to this file.
# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults

layout: home
---

# Hello, Jekyll {#hello-jekyll}

To understand more about what goes on behind the scenes in Jekyll, go ahead and expand your Git-ignored _site directory. Remember that this is the build directory that Jekyll creates each time you change a file, while jekyll serve is running. You should see that there's an index.html in there. Open that up to see its contents:

_site/index.html:

<h1 id="hello-jekyll">Hello, Jekyll!</h1>

This reveals an interesting point that will become important later: Where a file ends up in _site/ depends on where it is placed in your project directory. In our case, the index.md at the root of our project directory becomes index.html at the root of _site/.

What Is Markdown Front Matter?

Notice that the comments at the top of index.md mention that you can add custom "front matter" to the file. What exactly does that mean?

This is once again a common feature in static site generators. Anything between the triple-hyphen block at the top of a page is known as YAML front matter, which is just a fancy way of saying it defines certain metadata that you can later use to customize your pages, using YAML as the language. Note that you can add front matter to HTML files, too, not just to Markdown files.

---
layout: home
---

Currently, index.md defines a variable named layout that's assigned a value of home. This doesn't actually do anything yet because we haven't created any layout files (don't worry—we'll learn how to do that in a later section). We even get build warnings for this and a few of our other files:

Build Warning: Layout 'post' requested in _posts/2020-02-14-welcome-to-jekyll.markdown does not exist.
Build Warning: Layout 'default' requested in 404.html does not exist.      
Build Warning: Layout 'page' requested in about.md does not exist.
Build Warning: Layout 'home' requested in index.md does not exist.

Note that there are predefined front matter variables (like layout) that Jekyll recognizes by default and uses to change how a page looks or behaves, without you having to explicitly define what it should do with those variables. In this case, Jekyll uses the layout variable to structure your page's HTML according to a layout file, if you've defined one (more on that later). Check out the official Jekyll docs for the full list of predefined variables.

You can also define any number of custom front matter variables for your own use:

---
myAwesomeVariable: 42
majorKey: Success
---

Since these are not among the predefined front matter variables that Jekyll recognizes, it doesn't know what to do with them, so you'll have to use them yourself via Liquid to achieve your desired result (whatever that may be). We'll learn more about this once we get to the section on Liquid.

While we're on the topic of front matter, go ahead and open up the starter blog post that Jekyll created for us. On my end, it's located under _posts/2020-02-14-welcome-to-jekyll.markdown and has this content:

_posts/2020-02-14-welcome-to-jekyll.markdown:

---
layout: post
title:  "Welcome to Jekyll!"
date:   2020-02-14 07:40:59 -0500
categories: jekyll update
---
You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `jekyll serve`, which launches a web server and auto-regenerates your site when a file is updated.

To add new posts, simply add a file in the `_posts` directory that follows the convention `YYYY-MM-DD-name-of-post.ext` and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Jekyll also offers powerful support for code snippets:

{% highlight ruby %}
def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.
{% endhighlight %}

Check out the [Jekyll docs][jekyll-docs] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll’s GitHub repo][jekyll-gh]. If you have questions, you can ask them on [Jekyll Talk][jekyll-talk].

[jekyll-docs]: https://jekyllrb.com/docs/home
[jekyll-gh]:   https://github.com/jekyll/jekyll
[jekyll-talk]: https://talk.jekyllrb.com/

There's a lot of useful information in this template, so give that a read if you're interested. But note once again the front matter block at the top of the file:

---
layout: post
title:  "Welcome to Jekyll!"
date:   2020-02-14 07:40:59 -0500
categories: jekyll update
---

This time, we define variables for the title of the post, the date when the post was published, and any categories that this post belongs to. We've also declared its layout (but again, that layout file does not yet exist, so it has no effect). All of these variables can be used later on to customize our post pages, like showing the post title in the browser tab. You can learn more about how to use front matter in the Jekyll docs.

Front Matter Defaults

So far, we've seen two pages that have used the predefined global variable named layout, even though we don't yet know what this does or what layouts are in Jekyll.

The starter post that we saw earlier has a layout of post. Surely all of our other posts should have it too, right? If a layout defines the structure of a page, then we'd ideally want all of our blog posts to have the same structure or "skeleton." But do we really have to repeat layout: post in each post's front matter block?

Nope! Open up your _config.yml, and add this YAML somewhere (anywhere):

defaults:
  -
    scope:
      type: posts
      path: _posts
    values:
      isPost: true
      layout: post
  -
    scope:
      type: pages
      path: _pages
    values:
      isPost: false
      layout: default

And then restart your server.

Jekyll allows you to define front matter defaults like we've done here by scope, which you can narrow down using either a path or file type. The above defaults are equivalent to doing this manually in each post that we create under _posts/:

_posts/2020-02-14-an-awesome-post.md:

---
isPost: true
layout: post
---

And doing this manually for each page—like our home page, experience page, contact page, and so on—that we create under a directory named _pages/:

_pages/contact.md:

---
isPost: false
layout: default
---

This is a common pattern that you'll run into in Jekyll: If you find yourself repeating something tediously, there's probably a better, less redundant way to do it.

Where Do I Put My Pages in Jekyll?

This is one of the first questions I asked when I was just getting started with Jekyll, and it's one that I hope to answer here in as much detail as possible.

We've already seen that our posts go under _posts/. So where do our files go for things like the landing page, an experience page, a blog page, or a contact page?

By default, Jekyll looks for all of your site's pages at the root of your project directory. This is to ensure that, for example, index.html appears under _site/index.html once your site is built, as we saw in the previous section.

The Jekyll starter already comes with two such files at the root of the project: index.md (which gets compiled to index.html) and about.md (which gets compiled to about.html). However, as you can imagine, dumping all of your non-post page files into the root of the project directory is not ideal if you want to keep things organized, especially if you end up having lots of pages. So instead, we can store our pages in a custom _pages/ directory and tell Jekyll where to look for them.

First, create this directory, either via a UI or Bash:

mkdir _pages

After doing that, go ahead and move index.md and about.md into this directory:

├── _pages      
│   ├── about.md
│   └── index.md

Now you should see the following page instead of the index.html from earlier:

Hmm... Our index.html and about.html pages have vanished! Plus, our newly created _pages/ directory is nowhere to be found. The latter behavior is expected because the directory has a leading underscore—and if you'll recall, Jekyll doesn't process those kinds of directories unless you tell it to.

It's not Jekyll's fault that our two pages disappeared—we didn't tell it where to look for those files after we moved them to our custom _pages/ directory. So when we request index.html by visiting our localhost's root, we're just given the _site/ directory.

Open up your _config.yml and add this line somewhere:

include: [_pages]

This command defines an array of directories that Jekyll should process when it goes to build your site. In this case, we've defined an array of just one directory: _pages/.

The opposite of include is, as expected, exclude. Check out the commented block at the very bottom of your _config.yml, and you'll see that some files, like Gemfile and others, are excluded from processing by default. You can exclude other files by explicitly defining an exclude list.

Now let's restart the server:

Okay, it looks like that added _pages/ to our build directory, and we can now see an about/ directory that presumably stores our about page. But it's still not serving our index properly when we visit localhost:4000.

The final step is to specify permalinks to our pages using a predefined front matter variable named permalink:

_pages/index.md:

---
permalink: /
---

# Hello, Jekyll!

If you open up about.md, you'll notice that it already had a relative permalink defined in its front matter block:

_pages/about.md:

---
layout: page
title: About
permalink: /about/
---

This is the base Jekyll theme. You can find out more info about customizing your Jekyll theme, as well as basic Jekyll usage documentation at [jekyllrb.com](https://jekyllrb.com/)

You can find the source code for Minima at GitHub:
[jekyll][jekyll-organization] /
[minima](https://github.com/jekyll/minima)

You can find the source code for Jekyll at GitHub:
[jekyll][jekyll-organization] /
[jekyll](https://github.com/jekyll/jekyll)


[jekyll-organization]: https://github.com/jekyll

This explains why we saw the about/ directory in an earlier screenshot.

Save your changes, and Jekyll will rebuild the _site/ directory. If you refresh localhost:4000, you should see the Hello, Jekyll heading that we created before.

If you want to navigate to the About page, simply add /about/ to the end of localhost:4000 in your browser's navigation bar. Or you can use navigation links on your page:

_pages/index.md:

---
permalink: /
---

# Hello, Jekyll!

Check out these other pages:

- [About](/about/)

Result:

Awesome! To make sure you understand how all of this works under the hood, let's take a peek at the _site/ directory that Jekyll generated for us automatically:

_site
├── 404.html
├── about
│   └── index.html
├── feed.xml
├── index.html
└── jekyll
    └── update
        └── 2020
            └── 02
                └── 14
                    └── welcome-to-jekyll.html

Interesting! Now you can continue creating other pages using Markdown under _pages/, remembering to add permalinks to each one—like /experience/, /contact/, and so on. Jekyll will generate separate directories for each of these pages under _site/ using your specified permalinks, just like it did with about/, and plop in an index.html with your compiled Markdown. You'll then be able to navigate to each page.

Jekyll Blog Posts

I want to take a second to demystify some things about blog posts in Jekyll. Most of the lessons here carry over from what we learned about pages; we're just building on what we already know.

Permalinks to Blog Posts in Jekyll

We can give each blog post a permalink, too, just like we did with our pages above. But again, we don't want to have to repeat this every single time we create a post. Let's add a permalink to the defaults in our _config.yml:

defaults:
  -
    scope:
      type: posts
      path: _posts
    values:
      isPost: true
      layout: post
      permalink: /blog/:categories/:title/
  -
    scope:
      type: pages
      path: _pages
    values:
      isPost: false
      layout: default

This is the first instance where we see other front matter variables being referenced. In this case, we reference the categories and title variables defined by each post and use those to create a permalink to each blog post:

permalink: /blog/:categories/:title/

Recall that the starter blog post defines two categories, jekyll and update, plus the title Welcome to Jekyll!:

_posts/2020-02-14-welcome-to-jekyll.markdown:

---
layout: post
title:  "Welcome to Jekyll!"
date:   2020-02-14 07:40:59 -0500
categories: jekyll update
---

So now, if we navigate to localhost:4000/blog/jekyll/update/welcome-to-jekyll, we should see the blog post:

Below is the updated _site/ directory. Notice that now, instead of creating subdirectories for the year, month, and day when a post was published, Jekyll creates subdirectories by nesting categories, then creating one more directory with the post title, and finally placing index.html in there:

_site
├── 404.html
├── about
│   └── index.html
├── blog
│   └── jekyll
│       └── update
│           └── welcome-to-jekyll
│               └── index.html
├── feed.xml
└── index.html

You Don't Need an Explicit Date Variable

The example blog post that Jekyll created for us has this date in its front matter block:

---
#...
date:   2020-02-14 07:40:59 -0500
#...
---

Even though you are free to define a date explicitly like this, you don't actually need to. By default, Jekyll expects your blog post files to use this naming convention and extracts the date information from it, using that date to sort your posts:

yyyy-mm-dd-title-of-the-post-slugged.md

Note: A "slugged" title is in all lowercase, with all special characters removed, and with hyphens in place of whitespace. Jekyll extracts the title information from your file name. But you often want to define the title explicitly in the post's front matter block because it may contain special characters, like colons, exclamation marks, question marks, apostrophes, and so on.

So the date front matter variable is in fact redundant because we already have 2020-02-14 in the file name:

2020-02-14-welcome-to-jekyll.markdown

Let's try an experiment. Remove the date from the post's front matter, and replace the file with this:

_posts/2020-02-14-welcome-to-jekyll.markdown:

---
title:  "Welcome to Jekyll!"
layout: post
categories: jekyll update
---

Welcome to my post! This was published on {{ page.date }}.

Open up the post on your local to see the result:

This is our first look at the syntax of Liquid, the templating language that Jekyll uses to make development easier. You'll see that page.date is among the list of page variables in Jekyll, among many others that you can use.

Blog Post Front Matter Variables

There are three predefined variables unique to Jekyll blog posts:

date: The date when the post was published. If you set this variable, it will override the date in your file name. As we saw earlier, you don't have to specify this if your file name already has the date in it.
category and categories: Specify the category or categories, respectively, to which the blog post belongs. Categories can be used for grouping related blog posts in Jekyll.
tags: Tags are very similar to categories in Jekyll. In fact, there's barely any difference between the two.

For example, this blog post that you're reading was written in Markdown and uses the following front matter variables:

---
title: "Creating a Static Site with Jekyll and GitHub Pages: A Comprehensive Beginner's Guide"
description: Jekyll is a static site generator that makes it easy for you to create a website and blog. If you're interested in getting started with Jekyll, this in-depth guide is for you.
keywords: [jekyll and github pages, getting started with jekyll]
tags: [dev, jekyll, frontend, github]
---

Of these four variables, only tags is a predefined one that Jekyll recognizes and processes. The rest—like title, description, and keywords—are for SEO and allow me to customize my page's head block using some Liquid templating. If you scroll to the top of this post, you'll see that I've used the tags variable to create some clickable tag elements under the post's title.

Syntax Highlighting

Since blog posts use Markdown, and Markdown has support for code blocks, you get syntax highlighting support out of the box with Jekyll.

Older versions of Jekyll used Pygments as the primary syntax highlighter, but now Jekyll uses Rouge. Since Rouge themes are fully compatible with Pygments stylesheets, you can use any of the pre-existing Pygments themes.

Alternatively, you can define your own syntax highlighting theme like I did. Actually, my theme uses the same colors as VS Code for consistency with my screenshots. You can define this theme anywhere in your CSS, as long as it eventually gets linked to the page.

Dr. Jekyll and Mr. Liquid

We now arrive at the long-awaited topic that I've been teasing: Liquid. Fluids. H2O.

Liquid is a template language developed by Shopify with Ruby. Since Jekyll was also written in Ruby, the two are practically a match made in heaven. Here's how it works:

You write Liquid template code in an HTML or Markdown file.
When Jekyll builds your site, it processes the Liquid templates and substitutes them with actual content.

That's it! Liquid is super simple to use and understand. If you've ever worked with Vue, the two are fairly similar, except Liquid doesn't involve JavaScript. It's also obviously more limited.

While it's technically not a "programming" language, Liquid has many familiar programming constructs. Let's review some of the features of the Liquid templating language so you know what's available to you.

Data Types

Strings? "Check". Numbers? 1. You also get Booleans, Nil, and arrays.

Arrays are really powerful in Liquid because they allow you to write more reusable markup—more on that later!

It's a bit tricky to give examples of any of these because they require an understanding of other Liquid concepts.

Template Tags

Template tags ({% ... %}) allow you to declare variables, evaluate conditions, loop over arrays, and do lots of other essential things in Liquid without any of that code actually showing up on the rendered HTML page. In other words, tags are how you embed template logic into your markup.

Here's an exampe of a template tag:

{% if true %}
    <!-- exude awesomeness -->
{% endif %}

Like HTML tags, most template tags in Liquid have a matching end tag, often explicitly prefixed with end. There are a few exceptions, though, like for assigning values to variables.

Speaking of which...

Variables

Yup, Liquid has variables! Declare them, modify them, reassign them—usual variable stuff.

You use the assign tag to declare, or assign a value to, a variable:

{% assign identifier = value %}

As I mentioned in the previous section, the assign tag doesn't need an explicit end tag. This is similar to self-closing vs. explicitly closed tags in HTML.

Control Flow

If and case statements? You bet!

For loops? Yup! Check it out:

{% raw %}

{% for element in someArray %}
    <!-- do stuff here -->
{% endfor %}

Looping is really powerful in Liquid, and there are lots of things you can do.

You can limit the number of iterations, like to show only the three most recent blog posts in a teaser:

{% for post in site.posts limit: 3 %}
    <!-- do stuff here -->
{% endfor %}

Offset a loop at a specified index:

{% for element in someArray offset: 1 %}
    <!-- do stuff here -->
{% endfor %}

Define a range of numbers to loop over (sort of like in Python):

{% for level in (1..3) %}
    <h{{level}}>This is an h{{level}} tag!</h{{level}}>
{% endfor %}

And lots of other neat tricks.

By the way, what's up with those double curly braces in the last example? You're about to find out!

Objects

No, not like the "objects" in other types of languages.

An object in Liquid is anything {{ in double curly braces }}. Objects allow you to evaluate whatever expression you place inside the braces so that it renders on the page when processed, unlike anything in tags.

Here's an example of looping through all of the posts in a website and rendering their titles with a Liquid object:

{% for post in site.posts %}
    <h2>{{ post.title }}</h2>
{% endfor %}

And now, the earlier example should make sense:

{% for level in (1..3) %}
    <h{{level}}>This is an h{{level}} tag!</h{{level}}>
{% endfor %}

Since objects evaluate their contents, the output will be the following HTML:

<h1>This is an h1 tag!</h1>
<h2>This is an h2 tag!</h2>
<h3>This is an h3 tag!</h3>

Operators

Liquid has many of your standard comparison operators, like ==, >, <=, and so on, as well as logical operators like and and or. You also have access to some special operators, like contains, for operating on strings, as well as in for iterating over arrays (which we've already seen).

Filters

Liquid also has filters, which allow you to mutate or process data. They're like the built-in functions you get in many other languages. First comes the data you want to modify, then the piping operator (|), and finally the filter itself, which may or may not take an argument.

For example, you can capitalize the first character of a string:

<li>{{ name | capitalize }}</li>

Notice that this doesn't require any arguments.

Or split one string into an array of strings, using a specified delimiter:

{% assign names = "Billy, Bob, Joel" | split: ', ' %}
<ul>
    {% for name in names %}
    <li>{{ name }}</li>
    {% endfor %}
</ul>

In this case, we put a colon after the filter name and provide an argument: the delimiter for splitting the string.

We can also sort an array:

{% assign sortedPosts = site.posts | sort: "popularity" %}

If popularity is a valid front matter variable on your posts, then this would use that attribute to sort site.posts.

Or append elements to an array:

{% assign myArray = "Billy", "Bob", "Joe" | concat: "Brittany" %}

And much, much more. You get the idea.

Seriously, Liquid is fantastic. I highly recommend that you check out Shopify's documentation to learn more about it. Shopify has tons of code samples for every item in its API, so you can get pretty far with those alone.

Just be aware that when Googling for certain things, you may need to append "shopify" to your query to avoid seeing physics results for actual liquids :)

Using Jekyll Layout Files to Structure Pages

I mentioned layouts several times in the section on front matter variables. Now that we've covered the basics, it's time to finally understand what layouts are all about!

First, let's remind ourselves of these build warnings that Jekyll has been giving us:

Build Warning: Layout 'post' requested in _posts/2020-02-14-welcome-to-jekyll.markdown does not exist.
Build Warning: Layout 'default' requested in 404.html does not exist.
Build Warning: Layout 'page' requested in _pages/about.md does not exist.
Build Warning: Layout 'default' requested in _pages/index.md does not exist.

Layout files are like the skeletons of your website—they define an HTML structure that's common to a group of related pages so they all look consistent, minimizing the amount of repetition that goes into developing your site. Think of a layout file as a placeholder template into which you can plug your content (or potentially nest another layout!).

For example, each page needs to have a head block with certain metadata, a body for the content, a top (or side) navigation bar, and a sticky footer at the bottom. Many of these components remain the same as you navigate from one page to another, perhaps with slight visual differences to indicate where you currently are on the site (e.g., highlighting the current link on the navigation bar).

This is a perfect use case for layouts—instead of copy-pasting the shared HTML structure each time you create a page, simply assign a layout to the pages that need it!

Layout files in Jekyll are housed under the _layouts/ directory. Recall that this is one of those directories that Jekyll looks for automatically, assuming it exists. When you specify a layout variable in a page's or blog post's front matter block, the value that you assign it needs to be the name of an existing layout file (e.g., layout: default if you have a file named _layouts/default.html). If that layout file in fact exists, Jekyll will take your HTML or Markdown file and plug it into the layout file's structure.

It's easier to understand this with an example. If we go back to _pages/about.md, we'll find a layout declared in its front matter block:

_pages/about.md:

---
layout: page
title: About
permalink: /about/
---

Let's rename the layout to default. Functionally, it doesn't make a difference what we name it, as long as there's a layout file with the same name. It's just that default is more idiomatic—it's our website's "default layout."

_pages/about.md:

---
layout: default
title: About
permalink: /about/
---

Let's do the same for _pages/index.md and give the page a title as well, while we're at it:

_pages/index.md:

---
layout: default
title: Home
permalink: /
---

# Hello, Jekyll!

This is the home page.

Let's also create two other pages, blog.md and contact.md:

_pages/blog.md:

---
layout: default
title: Blog
permalink: /blog
---

## My Blog Posts

<ul>
  {% for post in site.posts %}
  <li><a href="{{ post.url }}" class="post-preview">{{ post.title }}</a></li>
  {% endfor %}
</ul>

_pages/contact.md:

---
layout: default
title: Contact
permalink: /contact
---

## Contact

Get in touch!

<form>
  <!-- Form stuff -->
</form>

Next, create the _layouts/ directory and add a file to it named default.html with these contents:

_layouts/default.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>{{ page.title }} - {{ site.title }}</title>
</head>
<body>
    <nav>
        <ul class="nav-links">
            <li><a href="/" {% if page.title == "Home" %}class="active-page"{% endif %}>Home</a></li>
            <li><a href="/about" {% if page.title == "About" %}class="active-page"{% endif %}>About</a></li>
            <li><a href="/blog" {% if page.title == "Blog" %}class="active-page"{% endif %}>Blog</a></li>
            <li><a href="/contact" {% if page.title == "Contact" %}class="active-page"{% endif %}>Contact</a></li>
        </ul>
    </nav>
    <main class="page-content">
        {{ content }}
    </main>
    <footer>
        Proudly made with Jekyll
    </footer>
</body>
</html>

It's your typical HTML file. Let's check it out:

Notice how we take advantage of Liquid several times to customize our pages. For example, the layout file customizes the title bar of each page using front matter variables we defined. The navigation bar applies a class of active-page selectively, depending on what page we're currently on. You can then select this element with CSS and style it accordingly to make it more prominent than the other links.

The most important part is {{ content }}, which you should recognize to be a Liquid object. This is a reserved variable that refers to the literal contents of whatever file Jekyll is currently processing that has its layout set to this layout's name. So, when Jekyll goes to process _pages/index.md, encounters the layout variable, and goes to process _layouts/default.html, the content variable will refer to the contents of index.md.

One final note: If you want to change the site title that appears after the dash in the address bar, then simply change that variable in your _config.yml as I mentioned before:

_config.yml:

# Site settings
# These are used to personalize your new site. If you look in the HTML files,
# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
# You can create any custom variable you would like, and they will be accessible
# in the templates via {{ site.myvariable }}.
title: Your awesome title

Using More Than One Layout

If we open up the starter blog post that we saw earlier, you'll notice that it has a different layout set:

_posts/2020-02-14-welcome-to-jekyll.markdown:

---
layout: post
title:  "Welcome to Jekyll!"
categories: jekyll update
---

The blog post collapses to a "flat" layout and doesn't have the same HTML structure as the other pages:

This is because the post layout doesn't exist. Let's go ahead and create this layout file. This time around, you'll notice that a layout file can itself specify a layout:

_layouts/post.html:

---
layout: default
---

<article id="post">
    <header class="post-header">
        <h1 class="post-title">{{ page.title }}</h1>
        <div class="post-date">{{ page.date | date: "%b %-d, %Y" }}</div>
        <ul class="post-categories">
            {% for category in page.categories %}
            <li class="post-category">{{ category }}</li>
            {% endfor %}
        </ul>
    </header>
    {{ content }}
</article>

Open up the post, and you'll now see that it has the same base layout as all your other pages, but it also has a nested layout specific to blog posts:

Awesome!

You've essentially mastered 90% of Jekyll at this point. Only a few topics remain!

Writing CSS in Jekyll Using SASS

What's a great site without some CSS to make it look pretty?

Jekyll has built-in support for SASS, a CSS preprocessor that allows you to take advantage of things like variables, mixins, functions, selector nesting, and lots more, making it easier to write maintainable stylesheets.

If you don't want to use SASS, you're more than welcome to use plain CSS. The only downside is that you won't be able to take advantage of the many great features that SASS brings to the table.

Modular CSS with SASS Imports

Like pure CSS, SASS allows you to use @import directives to assemble your stylesheets in a modular manner. But it's actually better because it doesn't trigger an additional HTTP call—it's merely for your convenience so you can split up your styles across well-named, more manageable files. The contents of those imports will be plugged in as-is and then transpiled to CSS.

It's worth noting that there are two places where it's suitable to place CSS files in Jekyll: _sass/ and assets/. Notice that the former directory has a leading underscore, whereas the latter does not. If you'll recall, any directory in Jekyll that's preceded by an underscore will not be processed or included in the build output directory, _site/. This means that if you put all of your modular stylesheets under assets/, they'll get transpiled into a bunch of disjoint CSS stylesheets, whereas you really want a single stylesheet.

With this in mind, a typical SASS workflow in Jekyll is to create a single file named /assets/styles/main.scss (known as a SASS manifest), store your modular stylesheets under _sass/, and then consolidate all of those imports in the manifest for transpilation. The result is a single, transpiled CSS stylesheet containing all of the styles that you imported.

For example, on my site, I keep my SASS manifest under assets/styles/main.scss. When Jekyll compiles my site, this file becomes _site/assets/styles/main.css. Then, as long as you include this stylesheet in the head of your default layout, it will load on the page:

<link rel="stylesheet" type="text/css" href="/assets/styles/main.css">

Notice that we reference the compiled version (.css) that's going to live under _site/ once your site is built, not the .scss version that we have access to only in the precompiled source.

Meanwhile, this is what my manifest looks like:

/assets/styles/main.scss:

---
---

@import 'components/topnav';
@import 'general/themes';
@import 'general/general';
@import 'pages/index';
@import 'pages/experience';
@import 'components/cardGrid';
@import 'components/card';
@import 'pages/contact';
@import 'blog/posts';
@import 'components/button';
@import 'components/collapsible';
@import 'components/tag';
@import 'components/tooltip';
@import 'general/highlight';
@import 'components/footer';

The empty front matter block at the top is crucial—if you don't include it, Jekyll won't process this file, and we need Jekyll to process the file so that it generates /assets/styles/main.css.

And here's what my _sass/ directory looks like, in case you're curious:

_sass
├── blog
│   └── posts.scss
├── components
│   ├── button.scss
│   ├── card.scss
│   ├── cardGrid.scss
│   ├── collapsible.scss
│   ├── footer.scss
│   ├── tag.scss
│   ├── tooltip.scss
│   └── topnav.scss
├── general
│   ├── general.scss
│   ├── highlight.scss
│   └── themes.scss
├── pages
│   ├── contact.scss
│   ├── experience.scss
│   └── index.scss
├── colors.scss
├── mixins.scss
└── settings.scss

Creating modular stylesheets and importing them into a SASS manifest makes it much easier to find a particular style that you need to tweak. For example, if I need to adjust a style related to cards, I know I just need to open up _sass/components/_card.scss.

Let's give this a shot. Create a file named _sass/_general.scss with this styling (or really anything you want):

_sass/_general.scss:

* {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

body {
  font-size: 18px;
  font-family: Arial;
}

And then create this file:

assets/styles/main.scss:

---
---

@import 'general';

Once your site rebuilds, you'll find this new file:

_site/assets/styles
└── main.css

Here's what the transpiled, minified stylesheet looks like:

_site/assets/styles/main.css:

* { box-sizing: border-box; margin: 0; padding: 0; }

body { font-size: 18px; font-family: Arial; }

Finally, don't forget to link the stylesheet to your default.html layout. Just add this to your head:

<link rel="stylesheet" type="text/css" href="/assets/styles/main.css">

Here's what your site should now look like:

Need to add more styles? Simply create a new SASS stylesheet under _sass/, possibly in a nested subdirectory to keep things organized, and then just import it into your manifest. It's that easy.

Creating Reusable Components with Includes

With other static site generators like Gatsby, you can take advantage of frameworks such as React to create reusable components. But what if I told you that you can still create components in Jekyll?

I'm talking about Jekyll includes. They're a simple way to reduce repetition in your markup and to create reusable "components" that you can plug in wherever they're needed. Jekyll literally takes the contents of an include file and dumps them wherever the file was included. It's a bit more involved than that, though, because Jekyll includes can take arguments (sort of like props in React!).

Includes are created under the _includes/ directory. An include file is simply an HTML or Markdown file like any other. The only difference is that an include file has access to a special variable named include. The arguments ("props") that you pass in to an include are then accessible under include.nameOfVariable.

For example, let's say you want to use tooltips on your site but don't want to have to copy-paste the same HTML each time you want to use one on a page. This is a perfect use case for includes:

_includes/tooltip.html:

<div class="tooltip tooltip-{{ include.position }}">
    <div class="tooltip-text">
        {{ include.text }}
    </div>
</div>

Here's how we might include a tooltip in another file:

{% include tooltip.html position="top" text="This is a tooltip!" %}

The processed HTML will look like this:

<div class="tooltip tooltip-top">
    <div class="tooltip-text">
        This is a tooltip!
    </div>
</div>

Note that if var is not provided, include.var will default to Nil (undefined).

One last thing worth noting is that includes can be nested, just like layouts can be. So that means you can include as many includes as you want... in your includes 😅.

Here are some example use cases for Jekyll includes:

Inlined SVGs: You can use something like Font-Awesome-SVG-PNG to find SVG icons that you want to use on your site and stick those in an include file. That include could take two arguments: the name of the SVG and an optional class name to apply to it. You can then insert SVGs into any of your pages, without having to copy-paste a huge chunk of HTML.

Lazily loaded, WebP-compatible images and thumbnails. On my website, I have an include that allows me to conveniently insert images into my blog posts with just a single, legible line of markup. You can learn more about how I do this in my blog post on using WebP images in Jekyll.

Post statistics. On my blog, each post shows the date when it was published and a measure of its reading length. This appears on both the preview cards for the posts as well as in the posts themselves. I could copy-paste the same markup in both locations, but if I need to change something later on, I'd need to remember to update it in both pages. Instead, I just create an include file.

Fair use disclosures. Some of my blogs use images from the web for which I do not own the rights. Even though I always disclose the source of these images, Wikipedia still advises that you add a fair-use disclosure to your site as an additional protection against any copyright strikes. I don't find myself needing to use this very often, but when I do, I can simply drop in the include without having to copy-paste a wall of text.

Project cards. My projects appear in two locations on this site: Once on the landing page, with a limited set of featured projects, and again on the Experience page, with the full set of projects. Once again, I can abstract away this component in its own include file.

Linked headings. I wrote an article on how you can create linked headings in Jekyll that goes into this in more depth. But basically, you can set up a simple include file that takes the name of a heading you want to create and the level of the heading and turns it into an anchor heading that users can click.

There's a lot more you can do with includes, but hopefully this gives you a good idea of what's possible!

Taking Advantage of Jekyll Data Files

Consider your online resume or personal website: You likely want to have a page, or at least a section of a page, dedicated to your projects, skills, education, work history, and any relevant hobbies or interests. Within each of those categories, you'll probably have multiple entries, such as:

Lots of different skills, possibly grouped into distinct categories.
Open-source (or not) projects and other samples of work that you'd like to showcase.
(Possibly) multiple degrees, specializations, or certifications.
(Most likely) multiple jobs as part of your work history.
Social media links, each with an icon, the platform name, and a URL to your profile.

Here's a mockup for two of those:

You get the general idea—all websites have static, mostly unchanging data that is often repeated in slightly different ways while retaining the same underlying structure.

I'll refer to all of these examples, and any others that fit the bill, as your site data.

The naive approach to represent site data on a page involves manually defining the markup for every single skill, project, and so on. Got multiple skills? Create a div for one and copy-paste it to create the others. You could certainly minimize some of the repetition here with an include, but you'd still have to copy-paste the include directive itself, and that's not ideal.

This approach has two glaring problems: repetition and poor legibility. Instead of defining the structure once with a template and simply plugging in the data, you end up copy-pasting the same structure and manually changing the data. Suppose you need to update a skill and increase its rating—you now have to track down that particular skill in a sea of HTML and copy-paste some SVGs to get the job done.

This issue is fundamentally about a separation of concerns—your data exists independently of however you decide to structure it at the end of the day. So why marry the two inextricably and make your life more difficult than it needs to be? Keep your data separate from the UI that displays it—you'll be happy that you did.

You do that in Jekyll by creating data files under the aptly named _data/ directory. Data files can use YAML, JSON, or CSV to define just that—your website's raw data, without the associated HTML markup.

Once you've created a data file in Jekyll, it becomes accessible under site.data.fileName across your entire site, in all HTML and Markdown files. But obviously, you're most likely only going to use it on a single page, like an Experience page for projects and skills.

You can then loop over that data using Liquid tags and finally give the data its structure. The key benefit here is that you only need to define the structure once; the data merely gets plugged into your templates when Jekyll goes to process your HTML or Markdown files. You can combine data files with includes to take your experience with Jekyll to a whole new level.

Example 1: Skills and Abilities

Let's say you have a simple file named _data/skills.yml. Suppose it looks something like this:

_data/skills.yml:

- name: Writing
  rating: 5
- name: Jekyll
  rating: 5
- name: Frontend
  rating: 4

You can access this data using site.data.skills. If your YAML defines an array of skills like above, you can iterate over it and define template markup for each element:

_pages/experience.md:

<ul>
    {% for skill in site.data.skills %}
    <li class="skill">{{ skill.name }} - {{ skill.rating }}</li>
    {% endfor %}
</ul>

This is a fairly simple example—in reality, you'd probably want to do more than just render a simple list of elements. But you get the idea—once you have access to the array, you can let your creative juices flow and create all kinds of neat stuff.

Also, note that you can nest arrays in YAML and in Liquid, so you could—like I do on this site—define skill categories and nest the actual skills within them:

_data/skills.yml:

- category: Blogging
  skills:
    - name: Writing
      rating: 5
    - name: SEO
      rating: 4

- category: Languages
  skills:
    - name: English
      rating: 5
    - name: Spanish
      rating: 3

And again, we can give this data more structure:

_pages/experience.md:

{% for item in site.data.skills %}
<h4>{{ item.category }}</h4>
<ul>
    {% for skill in item.skills %}
    <li class="skill">{{ skill.name }} - {{ skill.rating }}</li>
    {% endfor %}
</ul>
{% endfor %}

Example 2: Author Bios

Now let's suppose you run a blog that has multiple authors, not just you.

You can create a data file for each author and define the path to their profile photo, their name, their bio, and a fixed set of social media links, like Twitter, GitHub, and whatnot:

_data/authors.yml:

John Doe:
  photo: john-doe.JPG
  bio: John is a... Well, we don't actually know what he does. Actually, we're not even sure we know who he is.
  socials:
    - type: Twitter
      url: https://twitter.com/realJohnDoe
    - type: GitHub
      url: https://github.com/JohnDoe

Jane Doe:
  photo: jane-doe.JPG
  bio: Jane enjoys long walks on the beach and remaining anonymous on the internet, like 100% of the human population.
  socials:
    - type: Twitter
      url: https://twitter.com/datJaneDoeDoe
    - type: GitHub
      url: https://github.com/JaneDoe

Notice how your Jekyll data files can be as complex as you need, with nested arrays.

Let's assume each post defines an author in its front matter:

_posts/2020-02-13-a-really-awesome-post.md:

---
title: A Really Awesome Post
author: Jane Doe
layout: post
---

Usual lorem ipsum stuff.

The end!

We can now add a bio at the end of each post, ideally in the post.html layout file so we don't have to repeat it for every single post that we publish:

_layouts/post.html:

---
layout: default
---

<article class="post">
    {{ content }}
</article>

{% assign authorData = site.data.authors[page.author] %}
<div class="author-bio">
    <img src="/assets/img/authors/{{ authorData.image }}" alt="{{ page.author }}'s profile picture." />
    <div class="author-name">{{ page.author }}</div>
    <p class="bio">{{ authorData.bio }}</p>
    {% for social in authorData.socials %}
    <a href="{{ social.url }}" class="social-link {{ social.type }}-link">{{ social.type }}</a>
    {% endfor %}
</div>

Jekyll will process these templates, use the author's name as a key into the authors.yml data file, retrieve the relevant information about that author, and substitute it into the template. How cool is that?

Example 3: Tag Descriptions

Let's say each post on your site has tags, like the ones on my blog:

---
title: Jekyll Is Amazing
tags: [dev, jekyll]
---

Now you want to assign descriptions to each tag to dynamically update a page's description based on which tag a user selected. This is what I currently do on my website for the four primary topics I like to write about (dev, CS theory, gaming, and music).

Create a data file named tagDescriptions.yml (or something else) and define key-value pairs in the YAML, where the key is the tag name and the value is the description for that particular tag:

_data/tagDescriptions.yml:

dev: Technical posts. Yay dev!
life: As in, the thing I like to pretend to have...
tag: This is a tag. How exciting!

Then, you can once again take advantage of YAML's associative data nature to assign descriptions to each tag:

_layouts/blog.html:

{% for tag in site.tags %}
<a 
    class="tag" 
    href="/tag/{{ tag }}"
    title="{{ site.data.tagDescriptions[tag] }}">
    {{ tag }}
</a>
{% endfor %}

Neat, right? You can extend this to a lot of other use cases.

Setting Up Google Search Console

So you've started blogging with Jekyll. Awesome work!

But how do you know if you're getting any traffic, or what pages people are clicking, or what queries they're using to find you? What devices are being used? Are most of your users on mobile or desktop? What about your impressions, click count, click-through rate, and overall ranking on Google?

If you're a complete beginner getting started with Jekyll and don't yet have much (or any) traffic to your website, this should be the least of your concerns. Focus first and foremost on creating quality content, and then go ahead and set this up so you can grow your blog.

If you want to track these metrics so you can work on your blog's SEO, then you'll need to set up a Google Search Console account, claim your website as a property, and push a tracking file to your project that Google will provide you. This entire process is free, so there's no good reason not to set it up!

First, head on over to the Google Search Console website and log in with your Google account.

Once you've done that, click Add property:

When prompted to select a property type, choose the URL prefix option and enter the full URL of your site on GitHub Pages:

You'll be asked to verify that you are in fact the owner of this website. Google generates a unique file that you'll need to download, add to your website's repo, and push to GitHub:

GitHub Pages will then build your site and make this file accessible to Google for verification. Once you've uploaded the file, click Verify.

Is It Safe to Upload the Google Search Console Verification File?

Don't worry—there's no security risk associated with doing this. The file can only be used for verifying ownership, not authentication. So if someone downloads your file and tries to use it, they won't be able to access your Google Search Console statistics or anything else associated with your Google Account.

GitHub Pages Support for Jekyll Plugins

The great thing about Jekyll is that it has a large open-source community of creators who publish Jekyll plugins. These are just Ruby gems that extend the functionality of Jekyll and make your life easier.

The bad news? GitHub Pages only supports a limited set of plugins. This means that if you decide to use Jekyll plugins that are not supported by GitHub Pages, they'll work on your localhost but not when you push your site to GitHub.

If you absolutely need to use a plugin for a feature on your Jekyll website, then you'll need to push just the _site/ directory to GitHub instead of pushing your source files. Basically, you'd bypass the build step on GitHub Pages and just publish your static site directly on the web server.

Understandably, this may not be ideal if you want people (e.g., recruiters or other developers) to see your site's source and how you organized your project. So sometimes, you may need to reinvent the wheel to add a new feature to your site.

You can learn more about this issue and its workarounds in this StackOverflow thread.

You're All Set!

Give yourself a big pat on the back—if you made it to the end of this post, then you have a working website and a solid understanding of some Jekyll (and liquid) fundamentals 🎉.

We covered a lot in this tutorial—all the way from installing Jekyll and setting up GitHub Pages to creating pages, blog posts, layouts, includes, stylesheets, data files... Oh my!

If there's anything that this post didn't cover that you'd like to learn more about, you'll most certainly find info about it in the official Jekyll documentation.

I hope you found this tutorial helpful! If you notice any bugs or typos, or if you have any suggestions for improving this post, please do let me know!

Finite State Machine (FSM) Tutorial: Implementing an FSM in C++

Aleksandr Hovhannisyan — Sun, 23 Feb 2020 13:36:26 +0000

Note: This is a syndicated post. If you'd like to, you can view the original on my dev blog.

Finite state machines (FSMs) are used in lots of different situations to model complex entity state. They're especially relevant in game dev for modeling dynamic AI behavior and decision-making. Here's a very rough sketch of what a finite state machine might look like:

An entity may transition from one state to another, or it may remain in its current state. The arrows denote transitions. The conditions under which a transition should take place will need to be coded into the FSM itself.

In this finite state machine tutorial, I'll help you understand the state design pattern by building an FSM from the ground up for a simple problem, using C++ as the primary development language. However, note that you could just as well use a different object-oriented language, like Java or Python. Let's get started!

Finite State Machine Use Case: Modeling a Lightbulb

Suppose we have a lightbulb that can have the following states:

Off
Low
Medium
High

We can model this using an enum.

LightState.h:



#pragma once

enum class LightState {
    Off,
    Low,
    Medium,
    High
};

Every light is initially off. Calling a light's toggle method should advance it to the next state. A light that is off goes to low when toggled. A light that is low goes to medium. And so on. When we toggle a light that is high, it cycles back to off. How would you implement this?

This is actually a question I once encountered during an interview. It's a really great problem because there isn't just a single solution—you can do this in many creative ways. The most basic solution uses the modulo operator and cycles through an array of states, using an index to keep track of the current state.

However, I'd like to use this problem to introduce something called the finite state design pattern. It's not needed to solve this particular problem, but it's definitely useful. And it's also a good way to understand how finite state machines work. In practice, they are used to model more complex situations than just a lightbulb.

We'll look at two approaches to this problem. Let's get to it!

Approach #1: Using a State Transition Table (Map)

Usually, whenever you can model a scenario with finite state machines, you can also model it with a simple state transition table that literally just maps the current state to the next state.

So, we'll model our light's state transitions with an actual map data structure, where the key is the current state and the value is the next state.

LightState.h:



#pragma once
#include <map>

enum class LightState {
    Off,
    Low,
    Medium,
    High
};

std::map<LightState, LightState> lightTransitions = {
    {LightState::Off, LightState::Low},
    {LightState::Low, LightState::Medium},
    {LightState::Medium, LightState::High},
    {LightState::High, LightState::Off}
};

Let's also create our simple Light class.

Light.h:



#pragma once
#include "LightState.h"

class Light
{
public:
    Light();
    void toggle();
    inline LightState getCurrentState() const { return currentState; }

private:
    LightState currentState;
};

Light.cpp:



#include "Light.h"

Light::Light()
{
    currentState = LightState::Off;
}

void Light::toggle()
{
    currentState = lightTransitions[currentState];
}

As I mentioned earlier, a Light starts in the off state. Calling the toggle method advances the light to its next state, using the lightTransitions transition table.

Easy enough, right?

State Transition Table Drawbacks

Now, we arrive at one of the limitations of a state transition table: What if we want to perform a certain action when we arrive at the next state, or before we leave the current state?

For example, maybe we want to toggle the intensity of the lightbulb with each state transition, play a sound, or use some other effects unique to a state.

We could certainly do this—just add some code before and after the line where we're changing the state.

Light.cpp:



void Light::toggle()
{
    // ... do something here before the transition
    currentState = lightTransitions[currentState];
    // ... do something here after the transition
}

But usually, the actions that we want to take before and after a state transition are state dependent. This means that we'll need to use a switch statement, or a bunch of conditionals, to check what state we're currently in so we can act accordingly. That will become very difficult to maintain if the number of states increases!

Hmm... There's got to be a better way. (If there weren't, I wouldn't be writing this post!)

Approach #2: Implementing a Finite State Machine

Now that we've looked at how to create a state transition table, we can implement a finite state machine.

Here's a bit of a thought exercise before we get to the actual implementation details:

Instead of using a state transition table, what if we could delegate the task of determining the next state to the current state that our light is in? In other words, I'm proposing that we do something like this, where invoking a light's toggle method in turn invokes the current state's toggle method.

Light.h:



#pragma once
#include "LightState.h"

class Light
{
public:
    Light();
    // Same as before
    inline LightState* getCurrentState() const { return currentState; }
    // In here, we'll delegate the state transition to the currentState
    void toggle();
    // This will get called by the current state
    void setState(LightState& newState);

private:
    // LightState here is now a class, not the enum that we saw earlier
    LightState* currentState;
};

Light.cpp:



#include "Light.h"

// TODO: set the initial state here
Light::Light()
{
}

void Light::setState(LightState& newState)
{
    currentState->exit(this);  // do stuff before we change state
    currentState = &newState;
    currentState->enter(this); // do stuff after we change state
}

void Light::toggle()
{
    // Delegate the task of determining the next state to the current state
    currentState->toggle(this);
}

Then, somewhere inside the current state's toggle method, we call the light's setState method and pass in the new state that we want to go to:



void SomeLightState::toggle(Light* light)
{
    light->setState(SomeOtherLightState::getInstance());
}

If none of that code makes sense right now, don't worry—I'm about to break it all down step by step.

This is known as the finite state design pattern. Per this pattern, each state is modeled as a concrete class. So we'll need need the following four states for our lightbulb:

LightOff
LowIntensity
MediumIntensity
HighIntensity

Let's model this finite state machine with a simple diagram:

Each class implements a common LightState interface that provides the following three methods:

enter(Light*): What should happen as we enter this state?
toggle(Light*): What should happen when we're in this state?
exit(Light*): What should happen as we're exiting this state?

All three methods accept a pointer to the Light object with which the state is associated.

How do they gain access to this pointer? Well, recall that we invoked toggle in our Light class like so:



void Light::toggle() 
{
    currentState.toggle(this);
}

Basically, we pass in a pointer to ourselves (this). While doing so may seem pointless, it becomes more important in game development because it allows the state to ask the entity certain questions, like how much health it currently has and so on. The state can then use that information to decide what state the entity should transition to. Clearly, in the case of a lightbulb, there isn't really any information to poll.

One final note: Each state class typically follows the singleton design pattern to avoid unnecessary memory allocations and deallocations as we transition from one state to another, and then potentially back to a state that we were already in at one point. With our lights, if we didn't use singletons, we'd have to recreate our states every time we made a transition, and that would be wasteful.

To understand how this all works in practice, we'll implement everything from scratch.

1. The `LightState` Interface

Let's first define the abstract LightState class. You'll notice some forward declarations that are necessary to resolve circular includes that would otherwise throw off the C++ linker.

LightState.h:



#pragma once
#include "Light.h"

// Forward declaration to resolve circular dependency/include
class Light;

class LightState
{
public:
    virtual void enter(Light* light) = 0;
    virtual void toggle(Light* light) = 0;
    virtual void exit(Light* light) = 0;
    virtual ~LightState() {}
};

Since this is a pure abstract class, we cannot create an instance of it. The LightState interface allows us to take advantage of polymorphism so we can refer to a generic "state" without having to specify the true type of state that we're working with.

Note: In practice, you would often take this a step further and create an abstract Entity class. You'd also create an abstract EntityState class that accepts this generic entity in its method signatures. So, instead of having Light* like we do above, we would have Entity*, and Light would simply extend Entity.

2. Concrete State Classes

Next, we'll declare all of our concrete state classes. We'll force each one to be a singleton by doing the following:

Defining a static getInstance method that returns a pointer to the singleton.
Declaring all constructors, copy constructors, and assignment operators as private.

ConcreteLightStates.h:



#pragma once
#include "LightState.h"
#include "Light.h"

class LightOff : public LightState
{
public:
    void enter(Light* light) {}
    void toggle(Light* light);
    void exit(Light* light) {}
    static LightState& getInstance();

private:
    LightOff() {}
    LightOff(const LightOff& other);
    LightOff& operator=(const LightOff& other);
};

class LowIntensity : public LightState
{
public:
    void enter(Light* light) {}
    void toggle(Light* light);
    void exit(Light* light) {}
    static LightState& getInstance();

private:
    LowIntensity() {}
    LowIntensity(const LowIntensity& other);
    LowIntensity& operator=(const LowIntensity& other);
};

class MediumIntensity : public LightState
{
public:
    void enter(Light* light) {}
    void toggle(Light* light);
    void exit(Light* light) {}
    static LightState& getInstance();

private:
    MediumIntensity() {}
    MediumIntensity(const MediumIntensity& other);
    MediumIntensity& operator=(const MediumIntensity& other);
};

class HighIntensity : public LightState
{
public:
    void enter(Light* light) {}
    void toggle(Light* light);
    void exit(Light* light) {}
    static LightState& getInstance();

private:
    HighIntensity() {}
    HighIntensity(const HighIntensity& other);
    HighIntensity& operator=(const HighIntensity& other);
};

I created inlined, empty definitions for the enter and exit methods, as these are not essential for our purposes. They are merely there as placeholders, to show that you could fill those in if you wanted to. For example, you could fill these with print statements, or you could invoke some method on the light object that got passed in, such as light->increaseGlow().

Let's also create definitions for all of the toggle and getInstance methods, to make things clearer:

ConcreteLightStates.cpp:



#include "ConcreteLightStates.h"

void LightOff::toggle(Light* light)
{
    // Off -> Low
    light->setState(LowIntensity::getInstance());
}

LightState& LightOff::getInstance()
{
    static LightOff singleton;
    return singleton;
}

void LowIntensity::toggle(Light* light)
{
    // Low -> Medium
    light->setState(MediumIntensity::getInstance());
}

LightState& LowIntensity::getInstance()
{
    static LowIntensity singleton;
    return singleton;
}

void MediumIntensity::toggle(Light* light)
{
    // Medium -> High
    light->setState(HighIntensity::getInstance());
}

LightState& MediumIntensity::getInstance()
{
    static MediumIntensity singleton;
    return singleton;
}

void HighIntensity::toggle(Light* light)
{
    // High -> Low
    light->setState(LightOff::getInstance());
}

LightState& HighIntensity::getInstance()
{
    static HighIntensity singleton;
    return singleton;
}

I'm taking advantage of static variables to create my singletons in a legible manner. Moreover, note that I'm returning references, and not pointers, to avoid leaking memory.

Notice how each toggle method initiates the appropriate state transition by invoking light->setState(...) and passing in a singleton, via a call to the next state's getInstance method.

3. The `Light` Class

The final piece of the puzzle is the Light class, particularly the setState method.

Light.h:



#pragma once
#include "LightState.h"

// Forward declaration to resolve circular dependency/include
class LightState;

class Light
{
public:
    Light();
    inline LightState* getCurrentState() const { return currentState; }
    void toggle();
    // This is where the magic happens
    void setState(LightState& newState);

private:
    LightState* currentState;
};

Light.cpp:



#include "Light.h"
#include "ConcreteLightStates.h"

Light::Light()
{
    // All lights are initially turned off
    currentState = &LightOff::getInstance();
}

void Light::setState(LightState& newState)
{
    currentState->exit(this);  // do stuff before we change state
    currentState = &newState;  // actually change states now
    currentState->enter(this); // do stuff after we change state
}

void Light::toggle()
{
    // Delegate the task of determining the next state to the current state
    currentState->toggle(this);
}

This is where the enter and exit methods come into play. Before we change states, we call the exit method on the previous state. Then, we set the current state to the new state and invoke the enter method. But again, since we haven't defined the behavior for these two methods, they won't really do anything; they're just here to show you that you could do those things if you wanted to.

And we're done! This is a pretty standard finite state machine implementation, and you can easily extend this to any other object-oriented language, or even to JavaScript.

Testing Our Code

I use Visual Studio whenever I work with C++, so naturally, I'm also going to use the Microsoft Unit Testing Framework for C++ to verify that my finite state machine works as intended. This framework is built into Visual Studio 2017 and 2019. If you're not using Visual Studio, feel free to use a different IDE and whatever framework is available to you; the logic should be similar.

Below is my test file. Note that you may need to change some of your includes if you named your primary project differently:



#include "stdafx.h"
#include "CppUnitTest.h"
#include "../LightbulbFSM/Light.h"
#include "../LightbulbFSM/Light.cpp"
#include "../LightbulbFSM/ConcreteLightStates.h"
#include "../LightbulbFSM/ConcreteLightStates.cpp"

class LightState;

namespace Microsoft
{
    namespace VisualStudio
    {
        namespace CppUnitTestFramework
        {
            template<> static std::wstring ToString<LightState>(LightState* state)
            {
                if (state == &LightOff::getInstance())
                {
                    return L"Off";
                }
                else if (state == &LowIntensity::getInstance())
                {
                    return L"Low";
                }
                else if (state == &MediumIntensity::getInstance())
                {
                    return L"Medium";
                }
                else if (state == &HighIntensity::getInstance())
                {
                    return L"High";
                }

                return L"nullptr";
            }

            namespace TestLightbulbFSM
            {
                TEST_CLASS(TestLightbulbFSM)
                {
                public:
                    TEST_METHOD_INITIALIZE(Initialize)
                    {
                        light = new Light();
                    }

                    TEST_METHOD_CLEANUP(Cleanup)
                    {
                        delete light;
                    }

                    TEST_METHOD(InitialStateIsOff)
                    {
                        Assert::AreEqual(&LightOff::getInstance(), light->getCurrentState());
                    }

                    TEST_METHOD(OffGoesToLow)
                    {
                        light->toggle();
                        Assert::AreEqual(&LowIntensity::getInstance(), light->getCurrentState());
                    }

                    TEST_METHOD(LowGoesToMedium)
                    {
                        light->toggle();
                        light->toggle();
                        Assert::AreEqual(&MediumIntensity::getInstance(), light->getCurrentState());
                    }

                    TEST_METHOD(MediumGoesToHigh)
                    {
                        light->toggle();
                        light->toggle();
                        light->toggle();
                        Assert::AreEqual(&HighIntensity::getInstance(), light->getCurrentState());
                    }

                    TEST_METHOD(HighGoesToOff)
                    {
                        light->toggle();
                        light->toggle();
                        light->toggle();
                        light->toggle();
                        Assert::AreEqual(&LightOff::getInstance(), light->getCurrentState());
                    }

                private:
                    Light* light;
                };
            }
        }
    }
}

Notice how I defined a test method for each state transition:

Initially Off
Off to Low
Low to Medium
Medium to High
High back to Low

Note: The ToString method at the top is needed to resolve a pretty common error that you'll run into with this unit testing framework.

If we run our test suite, we can verify that all of the tests passed:

Awesome!

More Finite State Machine Examples

As I mentioned earlier, this was a pretty trivial use case for finite state machines. In fact, you don't really need the finite state design pattern to solve this particular problem. However, because the problem itself is so simple—a lightbulb that simply changes from one state to another—I felt it was a perfect way to introduce FSMs without overcomplicating things.

That said, I'd like to briefly mention some other situations where you may wany to use a finite state machine:

Modeling a vending machine. This StackOverflow thread offers a pretty good discussion of some design approaches to a real-world interview problem. The accepted answer suggests using the finite state design pattern because of how extensible it is. Interestingly, the second highest rated answer suggests using a state transition table as an alternative.
Modeling AI in a game. This post goes into great detail in the context of game dev. In particular, it highlights one advantage of finite state machines in game dev that I mentioned earlier in this post: The ability to query or "poll" the entity from the state in order to determine what state transition should take place.

Add a Free Contact Form to Your Website with Formspree

Aleksandr Hovhannisyan — Mon, 27 Jan 2020 15:25:16 +0000

Note: This is a syndicated post. If you'd like to, you can view the original on my dev blog.

Formspree is an online platform that makes it easy for you to add a free contact form to your website. It even has paid plans and integrations with other apps, like Slack, Mailchimp, and more. Setting it up takes no more than a few minutes, so let's get started!

Overview: How Does Formspree Work?

It's actually really simple! Here's a quick rundown of how Formspree works:

You specify a Formspree endpoint with your email address (e.g., https://formspree.io/your-email) in your form's markup. More specifically, this URL will be the action attribute of your form.
You make a mock submission once through the form on your live website. Formspree receives your submission and sends you a one-time registration email to activate the form.
Once the form has been activated, all future form submissions on your website will trigger a Formspree notification that's sent to your email address, with the form's contents and any other details.

How to Set Up Formspree 📧

To get started, all you need to do is add a form like this to your site:

<form action="https://formspree.io/your-email" method="POST">
    <input type="hidden" name="_subject" value="Someone sent you a message!" />
    <input type="text" name="name" id="name" />
    <input type="email" name="_replyto" id="email" />
    <textarea name="body" id="message"></textarea>
    <input type="submit" value="Send message" />
</form>

Let's clarify some of the input attributes:

_subject: This will be the subject line for the email that you receive from Formspree; it's a hidden field.
_replyto: Used to auto-fill the address line with the user's email if you respond to the notification email.
body: The message from your user.

The form's action attribute is the Formspree endpoint that I mentioned earlier; it's where the form data is going to be sent when it's submitted. As I noted earlier, to associate this endpoint with your email address, you just have to make a one-time mock submission from your live website (not from your local). Once you do that, you'll be notified that this form needs to be activated:

Note: Don't use your personal email address, as you'll have to expose that to the public in your form's markup. Instead, set up a dedicated email address for your website if you don't already have one.

And here's the email you'll receive from Formspree:

Again, it's important to make the mock submission from your live website and not from your local. It's not like doing it from your local will break anything—it's just that you'll still need to activate the form on the live website in order for it to work properly.

When a user submits a message, they'll have to pass a reCAPTCHA test. You'll then get an email from Formspree with a summary of the user's submission:

Notice that the subject line of this email is whatever I specified for the hidden _subject input. In this case, that's "Someone sent you a message!"

There are two useful links down at the bottom:

You can mark the email as spam if needed.
You can unsubscribe your email from that particular Formspree endpoint.

Finally, as I mentioned earlier, if you reply, the recipient's address will be filled in automatically:

Setting Up a Honeypot Trap for Bots 🍯

While the reCAPTCHA test already provides a solid defense against spam, Formspree also recommends adding a honeypot input field to your form for safe measure:

<input type="text" name="_gotcha" />

When a bot comes along and sticks its head where it doesn't belong, it'll be stuck.

You should give this a class and set the display to none so it doesn't confuse your human users:

<input type="text" name="_gotcha" class="honeypot" />

input.honeypot {
    display: none;
}

Formspree Free Plan Limitations

The free Formspree plan is a good option for most personal websites that don't expect more than 50 submissions per month. If you need more than that for your site, you can opt for one of their paid plans.

That's It!

You're all set to receive messages from your website's visitors.

(Or to hear crickets chirping in your inbox... 🦗)

How to Create Invulnerability Frames in Unity

Aleksandr Hovhannisyan — Sat, 11 Jan 2020 14:23:20 +0000

Note: This is a syndicated post. If you'd like to, you can view the original on my dev blog.

I learned a lot of neat tricks while working on developing one of my first "real" games, Embody, with some classmates. So I figured why not share some of those tips to help other game devs?

In this post, we'll look at how you can make a player flash when they take damage. This is the notion of invincibility frames, also known as i-frames. You'll find this in many retro games, as well as in games like The Binding of Isaac.

GIF source

To keep this tutorial simple, I'll assume that you already have:

A way to detect collisions between projectiles/mobs and the player.
A way to hurt the player. Let's call this method LoseHealth(int amount).

How to Make a Player Flash When Taking Damage (with Coroutines!)

The naive approach is to run a for loop, with an intentional delay between each iteration using deltatime, in your main Update loop, and to try to make the player flash in each iteration. But if you do this, you won't actually observe any flashing. Why is that?

In game development, you have to keep in mind that everything happens within a frame update. What this means is that most game engines have an Update method that runs the entire game's logic in "ticks." So, if you have a for loop inside the update loop, it'll complete all of its iterations in a single frame. Thus, any oascillating UI changes that were intended to be gradual—like the player model flashing—will be (almost) immediate, and therefore imperceptible.

Instead, we want to use coroutines to implement invincibility frames in Unity. A coroutine is simply a method that will run in parallel to the main update loop and resume where it left off in the next update.

Invincibility Frames in Unity

We'll start by adding this method somewhere in our Player script:

private IEnumerator BecomeTemporarilyInvincible()
{
    // logic goes here
}

Notice that this method returns an IEnumerator; all coroutines in Unity do that.

We'll use a flag to keep track of whether the player is invincible. Add this member variable to your script:

private bool isInvincible = false;

Next, when the player becomes invincible, we flip this flag to true:

private IEnumerator BecomeTemporarilyInvincible()
{
    Debug.Log("Player turned invincible!");
    isInvincible = true;
}

Of course, this doesn't do anything (yet!). You're probably wondering:

How do we start the coroutine in the first place?
How do we keep the coroutine running for a set amount of time?
How do we make the player flash while they're invulnerable to damage?

All great questions! We'll address each one in turn.

1. Losing Health and Becoming Invincible (Starting the Coroutine)

Ready for this? It's actually stupidly simple.

Again, I'll assume that you're using something like LoseHealth(int amount):

public void LoseHealth(int amount)
{
    if (isInvincible) return;

    Health -= amount;

    // The player died
    if (Health <= 0)
    {
        Health = 0;
        // Broadcast some sort of death event here before returning
        return;
    }

    StartCoroutine(BecomeTemporarilyInvincible());
}

First, we fail-fast if the player is already invincible. If they're not invincible, the player loses health. If the player died as a result of losing health, we set their health to zero, potentially fire off a death event, and return. Finally, if the player took damage but is still alive, we use StartCoroutine to initiate the coroutine that grants the player temporary invincibility.

Tip: Is your Player script checking for collisions with hostile entities in the world and self-inflicting damage? If so, rethink your approach. Instead, try having your damage sources check for collision with a designated "enemy" layer. This makes your logic much easier to follow.

2. Keep the Coroutine Running for a Set Amount of Time

Here's what we want:

Invincibility should only last for a set period of time.
There should be a fixed delay after each invincibility frame.

Add these two private members at the top of your script:

[SerializeField]
private float invincibilityDurationSeconds;
[SerializeField]
private float delayBetweenInvincibilityFlashes;

SerializeField lets you edit private members through the Unity inspector without having to make them public.

You'll need to initialize these two members via the Inspector pane:

Once you've done that, use them in the coroutine to run a simple loop:

private IEnumerator BecomeTemporarilyInvincible()
{
    Debug.Log("Player turned invincible!");
    isInvincible = true;

    // Flash on and off for roughly invincibilityDurationSeconds seconds
    for (float i = 0; i < invincibilityDurationSeconds; i += delayBetweenInvincibilityFlashes)
    {
        // TODO: add flashing logic here
        yield return new WaitForSeconds(delayBetweenInvincibilityFlashes);
    }

    Debug.Log("Player is no longer invincible!");
    isInvincible = false;
}

I find that a duration of 1.5 s works best, with the delay set to 0.15 s. This means the loop will run 1.5 / 0.15 = 10 times. Since the player model transitions between two states (visible/invisible) across 10 iterations, you'll observe that there are 10 / 2 = 5 flashes in total:

The key part here is the loop, especially the following line:

yield return new WaitForSeconds(delayBetweenInvincibilityFlashes);

We pause coroutines in Unity using WaitForSeconds and pass in the number of seconds to wait. In this case, that's the delay beween each flash, which you've hopefully set in your inspector by now.

3. Make the Player Flash While Invincible

The easiest way to simulate flashing is to repeatedly scale the player's model (or sprite, for 2D) between 0 and 1 during each iteration of the loop. So first, we need to actually get ahold of the player model. We'll add a member for it:

[SerializeField]
private GameObject model;

Note: For this tutorial to work, the Player should consist of a root object (e.g., MainPlayer) that has a collision box and the Player script attached to it. Nested under that object should be the player's model (e.g., Model) as a separate object:

This is important! You should not use the root player object as the model. If you do, this could lead to some very game-breaking bugs, as scaling the root object would also scale the player's collider.

In your editor, go ahead and drag the model object into the appropriate slot in the Player script, like so:

Next, we'll add a method that lets us easily scale this model:

private void ScaleModelTo(Vector3 scale)
{
    model.transform.localScale = scale;
}

And finally, we'll actually do the scaling in our coroutine:

private IEnumerator BecomeTemporarilyInvincible()
{
    Debug.Log("Player turned invincible!");
    isInvincible = true;

    // Flash on and off for roughly invincibilityDurationSeconds seconds
    for (float i = 0; i < invincibilityDurationSeconds; i += delayBetweenInvincibilityFlashes)
    {
        // Alternate between 0 and 1 scale to simulate flashing
        if (model.transform.localScale == Vector3.one)
        {
            ScaleModelTo(Vector3.zero);
        }
        else
        {
            ScaleModelTo(Vector3.one);
        }
        yield return new WaitForSeconds(delayBetweenInvincibilityFlashes);
    }

    Debug.Log("Player is no longer invincible!");
    ScaleModelTo(Vector3.one);
    isInvincible = false;
}

Depending on the numbers you select for invincibilityDurationSeconds and delayBetweenInvincibilityFlashes, you could end up in a situation where the player's invincibility runs out on the loop iteration where we set its scale to zero. Thus, we forcibly scale the model to one at the very end for safe measure.

And that's it—you're all set to use invincibility frames in your game!

Can I Use This Approach in Other Game Engines?

Yes and no.

In game engines like Unreal, there is unfortunately no support for coroutines. As an alternative to this approach, you can keep track of the time that has elapsed since invulnerability was initiated using simple deltatime calculations.

Godot, on the other hand, does have them.

I hope you found this tutorial helpful!

Improve Page Load Speed in Jekyll with the WebP Image Format

Aleksandr Hovhannisyan — Sun, 05 Jan 2020 20:34:31 +0000

Note: This is a syndicated post. If you'd like to, you can view the original on my dev blog.

Run the blog posts on my personal website through Google's PageSpeed Insights or Cloudinary's Image Analysis tool, and you'll find that most of them (with the exception of a few that load iframes) get around 99 on mobile and 100 on desktop. Some of these are packed full of images.

Why does that matter? Because speed is an important factor to consider alongside SEO to improve your site's ranking. Google considers page load speed when determining whether your site provides a positive experience for new and returning visitors. If your site is using too much data—by loading expensive images, iframes, or scripts—your page will load slowly, and users will be more likely to ditch your site in favor of one that doesn't slow them to a crawl.

It's only when I began running my posts through the former tool, PageSpeed Insights, that I discovered a useful optimization: using the WebP image format. Here's how Google describes WebP:

WebP is a modern image format that provides superior lossless and lossy compression for images on the web. Using WebP, webmasters and web developers can create smaller, richer images that make the web faster.

Google even provides a useful command-line tool, cwebp, that allows you to convert images from other formats—like PNG, JPEG, and so on—to WebP. In this post, we'll consider Jekyll specifically and take a look at how you can improve your page load speed by using the WebP image format with just a single include.

Getting Started with WebP in Jekyll

Now, you actually have two options here:

1. Use a plugin

The jekyll-webp plugin generates WebP versions of your images and serves them on demand whenever they're requested; it does not create actual WebP image files under your assets folder.

The downside to this approach is that some plugins—including this one—are not supported by GitHub Pages, so you'll have to run jekyll build and push your _site/ to GitHub, instead of pushing your source.

2. Use Google's CLI utility

Install the cwebp CLI utility yourself and use it to manually convert images to WebP as you add them to your site. This is my preferred option, and it's the one that I'll use in this blog post.

To get started, head on over to Google's installation instructions page for the libwebp executables and libraries. The process is actually really straightforward.

Note: The installation will also come with gif2webp, which can be used to convert GIFs to a WebP equivalent.

Converting an Image to WebP Format with `cwebp`

Assuming the previous step worked just fine for you and that cwebp is now accessible from the command-line, it's time to try it out on an actual image. Here's the general syntax for the command:

cwebp [options] input_file -o output_file.webp

You can specify a number of options, including the compression factor for converting to WebP; this dictates the quality of the resulting image. By default, this factor is set to 75%.

You can learn more about the available options in Google's documentation for cwebp.

For example, let's say you have an image under /assets/img/posts. To convert that to WebP, simply switch to the target directory and execute this command:

cwebp img.png -o img.webp

And that's it! Here's a quick demo of that in action:

You can ignore the output from the tool, as it's not too important.

In this case, notice that the image size was cut in a half—from 16 KB to 8 KB—without a significant loss of quality.

Note: You don't have to switch to the target directory to run the command. You could also just feed it a relative or absolute path from any directory. That said, I prefer to run it from the target directory to make my life easier.

How Do You Use the WebP Image Format?

The good news is that browser support for WebP is high, excluding Internet Explorer (of course 😒) and Safari:

Assuming you want to cover all your bases and ensure that your images are displaying properly, you can use a picture element with a source for the WebP version and a backup img for the regular format:

<picture>
  <source srcset="/path/to/image.webp" type="image/webp">
  <img src="/path/to/image.jpg" alt="Your alt text" />
</picture>

Basically, browsers that don't support WebP will fall back to the plain old img element, while those that do support WebP will use the source element. Awesome!

Except... Do we really have to copy-paste this every time we want to create an image? We also want to avoid having to specify an absolute path to our image every single time we want to insert one in a blog post.

Jekyll Includes and Liquid to the Rescue

Time to make this reusable! Create a file named _includes/picture.html and add this markup:

{% assign img = include.img %}
<picture>
    <source type="image/webp" srcset="/assets/img/posts/{{ page.slug }}/{{ img }}.webp" >
    <img src="/assets/img/posts/{{ page.slug }}/{{ img }}.{{ include.ext }}" alt="{{ include.alt }}" />
</picture>

Let's try to understand this part specifically:

<source type="image/webp" srcset="/assets/img/posts/{{ page.slug }}/{{ img }}.webp" >

Before I explain why this works, you need to know how I like to structure my blog:

All blog post images are under /assets/img/posts/.
Under that directory, each post has its own folder whose name matches the slugged version of the post's title.

Here's a screenshot to make that clearer:

That allows us to get away with this simple and legible include:

{% include picture.html img="my-image" ext="png" alt="My alt text" %}

Notice that we don't have to worry about explicitly stating the path! That will be filled in by Liquid when it goes to evaluate {{ page.slug }}. To top that off, we get to take advantage of WebP behind the scenes, with little effort beyond converting the images.

And That's It!

Of course, it would be even more convenient if there were a Jekyll plugin that generates output files from cwebp and dumps them in your assets folder. That way, you don't have to use the CLI tool manually.

If you wanted to, you could automate this with a script that converts all images in a directory to WebP using the installed CLI. In the process of writing this blog post, I went ahead and created that script.

One final improvement is to add lazy-loading to your images with JavaScript to ensure that your content loads even more quickly.

I hope you found this helpful!

Learn to Code Without Wasting Time & Money

Aleksandr Hovhannisyan — Sat, 04 Jan 2020 15:15:54 +0000

Note: This is a syndicated post. If you'd like to, you can view the original on my dev blog.

I remember reading a short story in high school about an aspiring writer who invested a great deal of time and money in procuring a fancy pen and an ornately bound notebook, purchasing a desk only a serious writer would sit at, furnishing his study with shelves full of old books he'd never read, and daydreaming about the prospect of writing. What was missing from this picture was any ink touching paper—he did anything but actually write.

The same thing often happens with beginners who want to get into software development—they install an assortment of IDEs and tools whose purpose they don't really understand, scour through listicles on the best programming languages for beginners to learn, and generally spend most of their time contemplating programming and trying to come up with ideas for projects instead of... well, programming.

Pick a Language, Any Language

Instead of wasting your time comparing different languages, just pick one and start coding. It really doesn't matter. Learn Java. Learn Python. Learn PHP, JavaScript, Go, Scratch, or any language you want. Anything will do when you're a beginner as long as you actually start somewhere. What you shouldn't do is waste time debating the merits and drawbacks of various languages when you don't even have experience yet—that's what you really need, after all; the language is just a means to an end.

YouTuber Michael Reeves puts it well in one of his videos:

Just pick one and start learning programming... All modern programming languages are wildly powerful, and they can do all kinds of shit.

I recall my programming fundamentals teacher imparting some very wise words in the second semester of my undergraduate studies when he heard me complain about us learning C++, which at the time was completely foreign to me and came with a boatload of frustrations. He said that the degree wasn't intended to teach us how to program in any particular language, and that languages are merely tools for doing a programmer's job. The hope was that we'd be able to pick up any language on demand after graduating from the program. Our goal was to learn how to think like computer scientists instead of confining ourselves to the narrow context of any particular language.

Languages are merely tools for doing a programmer's job.

Now, there is a caveat here worth mentioning: The language you select as a beginner will influence your initial perception of software development and dictate whether you actually end up enjoying coding or if you walk away disappointed.

There's a reason why many university courses expose beginners to Java, C++, or, in the case of MIT, Python: These three languages are very popular and span a number of software development domains, making them practical and useful to know. They're also more accessible to beginners because they're general-purpose languages.

Here's my advice: Don't pick a single language and refuse to part ways with it. The most obvious reason for this is because not every language is suitable for every problem. But in addition, limiting your worldview to just a single language paradigm can seriously stunt your growth as a developer.

Instead, I recommend using your favorite language as a way to learn programming fundamentals, algorithms, and data structures, and to gradually step out of your comfort zone. All of those things are language agnostic and easily transferable. Once you master those skills, you'll find that learning new programming languages will be a matter of getting used to a new syntax (and maybe a new way of thinking, like going from an OOP language to a functional one).

Stop Wasting Money on Courses You'll Never Finish

Udemy, Udacity, Lynda, Vertabelo Academy, Codeacademy Pro, et al. What do these things have in common? They're online platforms that target beginners who feel overwhelmed or disillusioned working professionals who are looking to make a career change as quickly as possible. These platforms are everywhere, but I consider them detrimental to learning how to actually code because they rarely ever provide materials that are of a higher quality than free content that's readily available online.

The biggest problem with these courses is the constant hand-holding—it's a disservice. Doing your own research, making mistakes, breaking your code, and learning how to debug all incredibly valuable experiences that will stick with you forever and ultimately make you a better programmer. Simply copying what an instructor does may help you develop muscle memory, but it won't provide you with the deep level of understanding that only first-hand experience can bring.

Have you ever noticed how Udemy's courses are always on sale? Or that these platforms have hints on practically every problem, or that the instructors outright tell you how to do X thing, or that they even do a Google search right there in the video instead of encouraging students to research these things for themselves? These are all red flags.

Many of these courses involve passive learning, even if they encourage you to type along and do things on your own machine as you watch them done on the instructor’s end. Why? Because you’re not actually discovering problems yourself and then searching for ways to solve those problems. That’s how people learn—through experience, curiosity, and failure.

With many of these platforms, there’s a thin veil of active learning. In reality, you’re doing one of three things:

Typing out everything the instructor wrote by hand.
Straight up copy-pasting their code or cloning a repo from their GitHub.
Not even coding—just listening and hoping it all sticks (spoiler: it won't).

Then, a week later, you find yourself having to revisit a past exercise (or even the associated video) to recall how to do something. If that's the case, then you clearly didn’t learn anything.

Reality: Developers have to constantly search for things online, sifting through Stack Overflow posts, Reddit, YouTube tutorials, articles, and—dare I say it?—official documentation to find answers to their questions. But why bother to seek out these answers on your own when you can pay for an instructor to tell you how it’s done? That makes you feel all nice and safe inside.

In a similar vein, these platforms also shield you from the somewhat tricky (yet valuable) process of setting up a technology on your own machine. Instead, they offer you a nice little sandbox environment where you can code to your heart's content without ever understanding what happens between you writing your code and the computer interpreting and understanding that code. If you plan on seriously investing your time in learning and using a technology in the real world, why not take the time to understand how you can use it on your own computer?

I'll admit: I do understand the appeal of a sandbox environment. It allows you to focus on the important thing—learning the language—without getting bogged down in any of the impediments. Med students don't practice surgery on real patients, after all. But you also can't expect to operate on cadavers forever.

Here are two Udemy course I once purchased thinking that they were the key to achieving whatever goals I had at the time (web development and game development, apparently):

I quit about 10% through both of them because I was bored out of my mind. I am not the type of person who can tolerate sitting in front of lecture after lecture, followed by intermittent "now you try it" exercises that, for the most part, are very trivial. I need a context for anything I do—a genuinely relevant, interesting, and challenging project that I want to work on. To-do list apps don't cut it for me because they're not something I actually want to build. Making games your way isn't what I want to do when I'm learning game dev.

For example, I learned just about everything I know about HTML, CSS, and (some) JavaScript by making my personal website—having a vision for what I wanted and then researching all the necessary parts to bring it to life. I learned both web development and game development on my own time, on my own terms.

Going into the Artificial Intelligence for Games class at the University of Florida, I had absolutely zero knowledge of the Unity game engine or C#—the main technologies we'd be using. How did I learn them in such a short period of time? By working on a game that I came up with and that actually interested me. By Googling, reading tutorials, and actually going through the painstaking process of trying to make something work but hitting roadblocks along the way. And by working with other developers—something that online courses will rarely ever expose you to.

What do you want to make? Figure that out, and just start Googling. If you decide that taking a course is the right path for you, at least don't waste your money on purchasing one—there are plenty of free resources online to get you where you need to go.

Learn to Code by Reading Code

Becoming comfortable with reading other people's code is an essential skill for any developer. Much like how reading books can help you become a better writer by exposing you to different literary styles, techniques, genres, and overarching themes, reading code can make you a better programmer by exposing you to different solutions, architectures, design patterns, and language paradigms.

I distinctly remember my fear of reading other people's code when I only had about a year of experience with programming. You're not familiar with the code, so everything naturally seems foreign to you, and you become frustrated and question why the author used certain naming conventions or design patterns. If you feel like this, you may be diving head-first into a complex project instead of dipping your toes in the water.

Here are my recommendations for how to improve your code reading skills:

Join a site like Code Review on the Stack Exchange network. Beginners (and even advanced programmers) often post their code here for more experienced developers to review. This is an incredibly valuable resource for a budding programmer. I recommend that you read an original poster's code in its entirety, as slowly as you need to. Then, review the responses to see what kinds of feedback other developers provided. Understanding why they made those recommendations can help you avoid making similar mistakes in your own code. If you need to, you can compile a list of common errors that you see and the corresponding recommendations that are provided. With time, though, you shouldn't need such a reference—it will all become second nature through repeated exposure to the same kinds of problems.
Read tutorials. But with a caveat: Never ever follow just a single tutorial blindly, copy-pasting things without understanding what the code is really doing. Instead, open a few (2–3) tutorials on a single topic and review them thoroughly. This is good for two reasons: 1) You're less likely to be misled by inexperienced developers who are actually imparting bad practices, and 2) if there are any discrepancies between the two tutorials, you can research those differences to gain a better understanding of why certain decisions were made in one snippet of code but not in another.

I found the second tip to be especially useful when learning CSS from scratch. Initially, I was quite afraid to read other people's stylesheets because I never really understood what their rules were doing. So what did I do? I read W3Schools, MDN, CSS-Tricks, and other sites to find multiple ways to do the same thing in front-end. Then, for each line of CSS that was presented to me, I would enter the code locally, refresh my browser, and make a mental note of the visual change that occurred. If something was unclear, I would stop right then and Google that particular CSS property to see what exactly it does. All of this involved reading, and reading, and... more reading. It never stops—and it's an important skill to develop if you're serious about dev, regardless of what specialization you choose to pursue.

Get Comfortable with Setting up a Dev Environment

When it comes to working on large code bases, especially ones that are not your own, it's important that you know how to set up your local dev environment correctly, with all the right tools and dependencies. If you're new to this, consider the following exercise: Find an interesting project using GitHub's Explore section and clone it onto your own machine. Then, follow whatever directions they have in their README to set up your dev environment and successfully build the project locally.

There's immense value to be found in this exercise because it's something that all developers need to know how to do on the job. If you run into any problems, do a bit of digging around online; it's likely that others have encountered the same problem before and that they've reported it either on GitHub, StackOverflow, or Reddit. If you have absolutely no luck, then you can consider opening an issue in the repo asking for help.

A big part of this is learning how to ease your way into a terminal environment and relying less on traditional GUIs. In particular, knowing how to work with the Bash shell and its most popular commands will make your life a whole lot easier as a developer. If you want the best of both worlds, consider using Visual Studio Code as your IDE—it's free, has built-in support for terminals, features a marketplace of free extensions, and provides fluid integration with version control software like Git. All of these are things you'll eventually need to use as a programmer.

A Note on Git

Speaking of version control, if you're feeling lost with Git, then know this: There's no better way to "study" or learn Git than to actually use it for a real project. There are tons of online tutorials and videos that claim to help you understand Git in as little as 15 minutes, but they all ironically miss the key point: Git is an applied technology that's difficult to understand or appreciate when it's used in isolation. Things may appear to click when you watch a video, but unless you use Git yourself, you'll forget it the next day.

You absolutely need to associate Git with a hands-on project—ideally one that involves multiple collaborators—to understand why the feature branch workflow is the commonly accepted standard, or why you should never rebase public branches. This will also help you to get comfortable with stashing your work, switching branches, amending commits, and checking out specific commits. These are all things that used to scare me when I had little to no experience with Git, but once you master them, you'll appreciate why they're so important.

I also highly recommend that you avoid using a GUI client for Git, as they prevent you from mastering and remembering common Git commands. The command-line is your friend, not your enemy. If you struggle to remember what a certain command does, or how to achieve something in Git, feel free to reference the Atlassian docs—they're very well written. You'll also find many excellent answers to common Git questions on StackOverflow.

Know that Leetcode Is Not the Answer

Remember the SATs and ACTs? Most people would rather not. It's a time when you're cramming material and vocabulary that you'll likely never need to use in your future, just for the sake of validating your intelligence so you can get into college. I hated the entire process and only appreciated one or two math tricks I learned along the way.

Leetcode is the same. There's this pervasive (and arguably harmful) practice in the hiring industry where a programmer's aptitude is measured by their ability to solve coding puzzles on a whiteboard, and that has spawned a number of platforms like Leetcode, Hackerrank, and others dedicated to helping developers master the art of solving obscure puzzles. I've personally been fortunate enough to not have to go through this ordeal in my interviews, and I hope you don't either.

Have people told you that you should cram Leetcode if you want to get a good job in tech? Stop listening to them. That may be the case if you want to get into elite unicorns, but it's not for the majority of developer positions. The best thing you can do is to work on personal projects and gain a deeper understanding of the technologies you want to work with in the future, as well as a solid grasp of CS fundamentals (which will most certainly come up during an interview). If you find yourself memorizing things, then you're going about this the wrong way.

With all that said, I will admit that there are some rather interesting Leetcode problems that actually get you thinking and test your understanding of fundamental CS data structures. Here are my personal favorites:

So, if you're curious about solving these problems, do give them a shot. But don't waste your time exclusively practicing Leetcode thinking that will somehow make you a better programmer (or a more qualified candidate for whatever position you're seeking). It's a very minor part of the overall picture.

Stop Beating Yourself Up

Failure sucks. A lot. But you need to get used to the feeling of frustration that programming generally brings because it's inevitable.

This is where online programming courses tend to disappoint—once the training wheels come off, and as soon as you’re confronted with an unfamiliar problem, the panic sets in. Because up until now, every problem you'd ever encountered had a solution: an instructor who would happily tell you exactly how to do something.

And then what happens? People turn to Quora, Reddit, or whatever other forums they frequent to vent and seek reassurance, to be told that coding isn’t that difficult and that they're not stupid and that they'll get better with time.

The truth? You’re not stupid. Learning to code is literally learning to speak a new language—there's a rough transition period at the start where you're mostly doing things by rote memorization and repetition, and when few things actually make intuitive sense. But there eventually comes that moment of enlightenment where you look back and realize what it is that you were doing this entire time. It does eventually click and become second nature.

Make no mistake, though: The process of getting there won't be easy. And once you do get there, you'll realize that you're not a programming wizard (is anyone?) and that you still have many knowledge gaps. Unfortunately, people are misled into believing that programming is somehow easier to pick up than any other skill that pays well, or that spending money on courses will guarantee their success. In reality, becoming a good developer requires years of practice, self-motivation, and hard work.

And, of course, you never stop learning.

Create Heading Links in Jekyll Without Any JavaScript (Using Includes)

Aleksandr Hovhannisyan — Wed, 01 Jan 2020 13:29:19 +0000

Note: This is a syndicated post. If you'd like to, you can view the original on my dev blog.

It's a common practice in blogs to make a heading a link; this makes it easier for users to share a specific part of your content without linking to the entire post.

How can we create heading links in Jekyll without losing our sanity and with zero lines of JavaScript?

Answer: with the power of Jekyll includes!

Jekyll Heading Anchors with Includes

Create a file named linkedHeading.html in your _includes folder. Here's what we want to do:

Create a dynamic heading that can be any level we want.
Give the heading an ID that we can reference.
Nest an anchor inside that heading that references the ID from above.
Fill the heading itself with some text.

With Liquid and Jekyll includes, it's super simple to create linked headings. Here's the markup:

{% assign heading = include.heading %}
<h{{ include.level }} id="{{ heading | slugify }}" class="linked-heading">
    <a href="#{{ heading | slugify }}">#</a> {{ heading }}
</h{{ include.level }}>

Simply use the following in your markdown to create a heading anchor in Jekyll:

{% include linkedHeading.html heading="My Heading" level=someNumber %}

Short and sweet! And much more legible than copy-pasting a bunch of heading tags and anchors. Plus, you don't have to introduce any unnecessary dependencies, JavaScript, or gems to get this done.

Note: If instead you want to link the entire heading, simply move {{ heading }} into the anchor itself.

If you're curious, here's how that works:

We pass in a string to heading, which we access via include.heading. We assign this to a local variable so we don't have to keep repeating include.heading.
Using Liquid objects, we specify the level of the heading dynamically with h{{ include.level }}. So if we pass in level=2, then we'll get h2. Do this for both the opening and closing tags.
Give the h tag an ID. The ID will be the string we passed in, but slugged. You can also give it a class name if you want to style it later.
Create a nested anchor that points to the same slug: href="#{{ heading | slugify }}". The anchor text can be anything you want. I was inspired by the CSS Tricks website and used a hashtag.

Then, after the anchor, we simply put a space followed by our unformatted heading string.

Sticky Navbar and Linked Headings

If you have a sticky/fixed navbar like I do on my personal site, you may run into a problem where your heading anchors get stuck under the navbar when you click them.

Fortunately, the fix is a neat little trick: a negative top margin combined with a positive top padding. I like to leave about a 40px difference between the two for spacing:

h2 {
    margin-top: -50px;
    padding-top: 90px;
}

My navbar is 64px tall, so I found that these two numbers work best. Feel free to play around with them. And of course, you can also apply this to other heading levels in case you want to link to them as well.

And That's It!

The best part is that you can pick which headings you want to link to.

I hope you found this post helpful 🙂

DEV Community: Aleksandr Hovhannisyan

What Are Higher-Order Components in React?

Table of Contents

Prerequisite Terminology

What Are Higher-Order Components?

Example of Higher-Order Components

Creating Reusable Stateful Logic with Higher-Order Components

Higher-Order Components and the Power of Composition

Higher-Order Components vs. Wrapper Components

Using Higher-Order Components with the React Context API

Conclusion

Attributions

An Introduction to HTTP Cookies

Table of Contents

How Does a Website Remember Who You Are?

What Is a Cookie?

Types of Cookies: Session vs. Permanent

1. Session Cookies

2. Permanent Cookies

How Do Cookies Get Set in a Browser?

HTTP Request and Response Headers

The Set-Cookie HTTP Response Header

Reading and Creating Cookies via JavaScript

HTTPOnly Cookies: Protecting Sensitive Data

The Same-Origin Policy and Session Hijacking

Why Do Websites Ask for My Permission to Store Cookies?

How Advertising Cookies Work

Where Are Cookies Stored on My Computer?

Chrome

Firefox

Microsoft Edge

How Do I Clear My Cookies?

What Happens if I Clear My Cookies?

Alternatives to Cookies

Cookies vs. localStorage vs. sessionStorage

Final Thoughts

Binary for Beginners: The ABCs of 0s and 1s

Table of Contents

What Is a Number System?

Bases, Exponents, and Digits

The Binary Number System (Base 2)

Binary Is Close to the Hardware of a Computer

The ASCII Standard

1 Character = 1 Byte

The Hexademical Number System (Base 16)

How to Convert Between Binary and Hexadecimal

Binary to Hexadecimal

Hexadecimal to Binary

Real-World Application: Representing Colors with RGB/Hex

How Many Colors Are There?

What Are 8-Bit Colors?

Signed Binary Number System: Two's Complement

How Does Two's Complement Work?

The Intuitive Approach: What Does a Leading 1 Denote?

Two's Complement Shortcut: Flip the Bits and Add a 1

How Many Signed Binary Numbers Are There?

What Is the Largest Signed 32-bit Integer?

Real-World Application: Video Game Currency

What Is the Smallest Signed 32-bit Integer?

Basic Arithmetic in the Binary Number System

Adding Binary Numbers

Subtracting Binary Numbers

Multiplying Binary Numbers

Dividing Binary Numbers

Integer Overflow and Underflow in Binary

The Binary Number System: Additional Topics for Exploration

Semantic HTML: Building a More Accessible Web

What Makes HTML Accessible?

Semantic HTML Basics

Main

Header and Footer

Article and Section

Nav

Other Semantic HTML Elements

Creating an Accessible User Experience with Semantic HTML

Don't Use Divs for Interactive Elements

Q: Should I Use an Anchor or a Button?

Use More Lists!

Don't Use Spans for Inline Positioning

Don't Abuse ARIA

The `Set-Cookie` HTTP Response Header

Cookies vs. `localStorage` vs. `sessionStorage`

Use the `<time>` Element for Dates

Don't Overuse the `title` Attribute

Give Images a Descriptive `alt` Attribute

Use `aria-hidden` and `alt=""` Strategically for Certain Images

1. The `LightState` Interface

3. The `Light` Class