![New website design](/blog/2021-12/new.png)

The latest version of my website served me well. It came together over the course of a month as a combination of smaller projects: an experimental photography/design portfolio to start (with the same masonry layout live on the [photo](/photo) and [design](/design) pages today), then the word cloud on the homepage, then the video portfolio with the hover-to-reveal-slides effect lifted from a separate video portfolio I had built, and finally a blog built around Jekyll's markdown-based blogging engine.

![Old website design](/blog/2021-12/old.png)

Over time I added new components to the website: a page for my code and makerspace projects, a list of newsletters on the front page. My website design was flexible enough to keep adding to it and tweaking it, but a major problem arose: the site was built in Jekyll using Liquid templating, while all my other dev work was done in Javascript and React. As I became more proficient and found better tooling for building whatever I could imagine on the web with React, Jekyll became comparatively more and more of a hassle to use, to the point where I eventually stopped updating my old website entirely. It sat and prominently advertised an outdated description of me, my interests, and my work.

![Old website having incorrect information](/blog/2021-12/old-wrong.png)

I've wanted to rebuild my website for a while. Specifically, I wanted to rebuild it in NextJS. My website has always been grounds for experimentation, where I pushed my personal boundaries of what I could build visually, often transferring my discoveries to other projects. With the Jekyll-React divide in my work, this stopped being the case; rebuilding my website in NextJS would put it on the same stack as the biggest projects I was working on and make code even directly transferrable -- if I implemented blog post recommendations on a NextJS-based personal blog, for example, I could transfer them over to Postulate much more easily than from a Jekyll-based blog.

Over the summer, I hacked together a new portfolio for a fellowship application; I replicated the photo and design pages on my old portfolio fairly easily, and built new writing and software sections that simply linked to external project pages.

This past week, I finally got around to brushing up the info presented and completing the website, bringing over my old Jekyll blog, film portfolio, and project pages. With React tooling, doing so was a breeze.

The site freshens up the styling overall, introducing some serifs and tone and size variation, while preserving a lot of the old designs I still quite like. It's not as playful as it was before and not as lively as I would like it to be, but it's a good starting point to build on in the next few months or years.

For the sake of leaving a record of this mini-project, here are a few technical highlights.

##  The stack: NextJS + Tailwind, hosted on Vercel

As mentioned previously, I use NextJS for all of my from-scratch web dev projects these days. It's stupidly versatile, allowing you to build a full-stack application as easily as a static web app.

Next automatically turns your React code into static files to serve when possible. (Server-side rendering and client-side hydration are also effortless.) That means that this website, developed in React, would be just as performant and SEO-friendly as my old one.

Next also offers a ton of developer experience goodies. Routing is handled automatically simply by creating folders and files with the same names as you want your URLs to have. For example, a component in `/pages/project/autoturner.tsx` will turn into a page at `samsonzhang.com/project/autoturner`, wrapped in the special template files `_app.tsx` and `_document.html`. This routing is not just convenient but also very powerful; in a later section I'll discuss how I replicated Jekyll's blogging engine using `getStaticPaths` in Next.

Other than these goodies, Next is good old React: functional components, npm packages, and Tailwind for styling handle perfectly.

##  Replacing Jekyll data/Liquid templating with JSX

Jekyll had a nice feature where, if you put a json, csv, or yaml file in a `_data` folder, you could reference the dataset as `site.collection.[filename]` in Liquid templating (a templating language similar to Django's) and loop through it.

For my photo portfolio page, for example, I had the following CSV file with the filename and relevant info of every photo I wanted to display:

```csv
name,date,caption
xc1,November 2019,Springbok Gazelle Cross Country Race 2019
arno1,June 2019,Phillips Academy Prom 2019
css1,2017,Columbia Secondary School middle school graduation/stepping up ceremony 2017
sw-6,Summer 2018,Antelope Canyon
march7,Winter 2019,March for Our Lives in Boston.
march6,Winter 2019,March for Our Lives in Boston.
march1,Winter 2019,March for Our Lives in Boston.
march10,Winter 2019,March for Our Lives in Boston.
...
```

Then, in an include, I could write the following:

```html
{% for photo in include.data %}
{% assign name = photo.name | split: "." %}
<div class='photo'>
	{% if name.last == 'mp4' %}
	<video class='portfolio-item' id='{{ name[0] }}' autoplay loop muted>
	    <source src='{{ site.baseurl }}/img/{{ include.folder }}/{{ include.data }}' type='video/mp4'>
	</video>
	{% else %}
	<img class='portfolio-item' id='{{ name[0] }}' src='{{ site.baseurl }}/img/{{ include.folder }}/{{ include.data }}{% if include.folder == "photo" %}.jpg{% endif %}'>
	{% endif %}
</div>
{% endfor %}
```

This kind of templating was an order of magnitude better than copy-pasting HTML or modifying the DOM through client-side Javascript.

React and JSX, through their use of XML and JS syntax, feels even more natural. Here's the equivalent section of code as above:

```jsx
{galleryArray.map(item => (
    <div className="px-4 md:w-1/2 lg:w-1/3 mb-8" key={item.name}>
        {item.name.slice(-3) === "mp4" ? (
            <video
                src={`/portfolio-${isDesign ? "design" : "photo"}/${item.name}`}
                className="shadow-md w-full"
                autoPlay={true}
                muted={true}
                loop={true}
            />
        ) : (
            <img src={`/portfolio-${isDesign ? "design" : "photo"}/${item.name}`} alt="" className="shadow-md w-full"/>
        )}
    </div>
))}
```

Where `galleryArray` is simply the CSV file converted to a JSON file and imported with `import PhotoGallery from "../components/PhotoGallery"`. It could also be an array of objects defined in one page or component file and then exported to multiple pages, a technique I used for the various "experience" lists across the website.

![Experience list on new website](/blog/2021-12/experience.png)

Jekyll includes are another basic but vital templating feature, allowing you to put re-used chunks of code in a file and insert them throughout your site by writing `{% include filename.html [prop]=[value] %}`.

In React, the functionality of these includes is of course replaced by components with XML syntax, i.e. `<Component [prop]={[value]}/>`.

## Replicating my blog in NextJS

Jekyll's templating features were super useful, but most impressive was its blog engine. It was spectacularly simple. Have a `_posts` folder, put markdown files in it with the necessary frontmatter, and Jekyll would throw the page up at `samsonzhang.com/yyyy/mm/dd/title-of-your-post`. I posted 65 blog posts this way:

![Screenshot of markdown files for blog posts](/blog/2021-12/posts.png)

Replicating this blog engine, more or less, was the most technically involved part of rebuilding my website.

The ability to do so hinged on NextJS's "dynamic routing" and build-time path specification features.

Dynamic routing means that, instead of specifying the exact URL of every page that Next will serve to visitors, you can specify a format of URL to fit, like `/project/[slug]`, and Next will look at some non-predetermined data to see if the page is valid.

In the case of a truly data-driven app, like a social media app, this is a crucial feature: you can't generate a static file for every single `/@username` address, for example. That's much better handled at the time that the request hits the server, when the server can then check against the database of users to see if there's one under the requested username, a condition that may change rapidly as accounts are created and deleted and usernames are changed.

For sites like blogs, this is a less necessary but still highly useful feature. Here the separation between data and code happens not at request time, but build time. For example, if a blog is using an external CMS, it might be useful for the build process to make an API call to that CMS to get the latest content and render it into static files, rather than having all that content be part of the dev codebase.

Here, the markdown files I wrote for Jekyll functions like an external CMS. I can read them in (at least their filenames) with the following Node.js code:

```js
const fs = require("fs");
const files = fs.readdirSync(process.cwd() + "/posts/");
```

Now, in two steps, NextJS allows me to generate a page from each file. In a file under `/pages/[year]/[month]/[day]/[slug].tsx` (brackets literally in the filenames), a structure that reflects the structure of Jekyll's auto-generated URLs, I first specify a function `getStaticPaths`. This function returns an array of objects specifying the URL params of each page I want to generate -- one per markdown file in the `posts` folder.

```js
export const getStaticPaths: GetStaticPaths = () => {
    const fs = require("fs");
    const files = fs.readdirSync(process.cwd() + "/posts/");

    const paths = files.map(file => ({
        params: {year: file.substr(0, 4), month: file.substr(5, 2), day: file.substr(8, 2), slug: file.substr(11, file.length - 14)}
    }));

    return {paths, fallback: false};
}
```

Then, when generating each page, I want to read information from that file and pass it to my React component. I can do this through the `getStaticProps`, specified in the same file:

```js
export const getStaticProps: GetStaticProps = ({params}) => {
    const filename = `${params.year}-${params.month}-${params.day}-${params.slug}.md`;

    const fs = require("fs");
    const fm = require("front-matter");
    const thisFile = fs.readFileSync(process.cwd() + "/posts/" + filename);
    const thisFm = fm(thisFile.toString());

    return {
        props: {
            title: thisFm.attributes.title,
            date: thisFm.attributes.date || null,
            tags: thisFm.attributes.tags ? thisFm.attributes.tags.split(" ") : [],
            body: thisFm.body,
            filename: filename,
        }
    };
}
```

Note that, using a package called `front-matter`, I'm able to read the same frontmatter that Jekyll relied on. That's the stuff at the beginning of a post between triple-dash lines that looks like this:

```markdown
---
title: peace
layout: post
tags: moments musing
date: '2020-02-23 11:16:49'
---

I sat on the floor of my room...
```

Now here's the entirety of the main function in the post TSX file:

```js
export default function BlogPost(props: BlogPostProps) {
    const {title, body, tags} = props;

    const markdown = remark()
        .use(remarkParse)
        .use(remarkFootnotes)
        .use(remarkRehype, {allowDangerousHtml: true})
        .use(rehypeStringify, {allowDangerousHtml: true})
        .processSync(body);

    const stripped = stripMarkdown(body);
    const readingTime = getReadingTime(stripped);

    return (
        <div className="max-w-3xl mx-auto px-4">
            <SEO title={title}/>
            <BackLink/>
            <h2 className="font-bold text-4xl leading-[1.4]">{title}</h2>
            <div className="text-xl my-8">
                {tags.map(tag => (
                    <Link href={`/blog/${tag}`} key={"tag"+tag}>
                        <a className="mr-2">#{tag}</a>
                    </Link>
                ))}
                <p>{format(getDateFromBlogPostProps(props), "MMMM d, yyyy")}</p>
            </div>
            <p className="opacity-50 my-8 uppercase font-bold">{readingTime} min read</p>
            <div dangerouslySetInnerHTML={{__html: markdown.value.toString()}} className="prose mt-8" style={{fontSize: 20}}/>
            <div id="hyvor-talk-view" className="border-top pt-6 mt-6"/>
            <script type="text/javascript" dangerouslySetInnerHTML={{__html: `
            var HYVOR_TALK_WEBSITE = 1008; // DO NOT CHANGE THIS
            var HYVOR_TALK_CONFIG = {
                url: false,
                id: false
            };
            `}}/>
            <script async type="text/javascript" src="//talk.hyvor.com/web-api/embed"/>
        </div>
    )
}
```

First, note that I read in the title, body, and tags from the props passed. (Date is read by the `getDateFromBlogPostProps(props)` call later on, a function that I define elsewhere.) The title and tags can be used directly as a string and array of strings respectively.

Body, on the other hand, is a markdown string -- the entirety of the markdown file for the blog post, minus the frontmatter. To display this, I need to first convert it to HTML.

Thankfully, a ton of good JS tooling exists for this. I used Unified's `remark` along with a few plugins to get the job done. There's a lot of `allowDangerousHtml` and `dangerouslySetInnerHTML`, which would be huge holes for XSS attacks if you were letting dynamic user content through, but I'm doing all of this at build time with local files so it shouldn't be a problem.

The `stripMarkdown` function I call to get the reading time also uses `remark`. It looks like this:

```js
export function stripMarkdown(md: string): string {
    return remark()
        .use(strip)
        .processSync(md)
        .value
        .toString();
}
```

The last thing worth mentioning is the [Hyvor Talk](https://talk.hyvor.com/) embed at the end of the component. Hyvor is a super-easy way to throw comments sections up on statically generated websites. It used to be free and my plan still is; looks like the lowest starting plan now is $5/month. I don't get many comments on my blog, but Hyvor has worked well for the few I've gotten; its main sell (in my eyes) is its simplicity, demonstrated by being able to be transferred from Jekyll to NextJS in a pretty direct copy+paste.

Anyways, `getStaticPaths` and `getStaticProps` combined have the effect of making NextJS generate fully pre-rendered HTML files for every one of the paths specified _at build time_ without you having to code a React page for every single path.

The main blog page, at `/blog`, also uses `getStaticPaths` to bring in data from the markdown files at build time rather than serving the files themselves to the client.

![Screenshot of new blog page](/blog/2021-12/blog.png)

It's similar to the function for single blog pages, but it returns an array of posts rather than a single one:

```js
export const getStaticProps: GetStaticProps = () => {
    const fs = require("fs");
    const fm = require("front-matter");
    const files = fs.readdirSync(process.cwd() + "/posts/");
    const posts = files.map(file => {
        const thisFile = fs.readFileSync(process.cwd() + "/posts/" + file);
        const thisFm = fm(thisFile.toString());
        return {
            title: thisFm.attributes.title,
            date: thisFm.attributes.date,
            tags: thisFm.attributes.tags ? thisFm.attributes.tags.split(" ") : [],
            body: thisFm.body,
            filename: file,
        }
    })

    return {props: {posts: JSON.parse(JSON.stringify(posts))}};
}
```

A last use of `getStaticPaths` and `getStaticProps` is for generating tag filter pages, which of course also rely on the data in these markdown files. Here's what that code looks like:

```js
export const getStaticPaths: GetStaticPaths = () => {const fs = require("fs");
    const fm = require("front-matter");
    const files = fs.readdirSync(process.cwd() + "/posts/");
    const tags = files.reduce((existingTags, file) => {
        const thisFile = fs.readFileSync(process.cwd() + "/posts/" + file);
        const thisFm = fm(thisFile.toString());
        const thisTags = thisFm.attributes.tags ? thisFm.attributes.tags.split(" ") : [];
        let newTags = [...existingTags];
        for (let tag of thisTags) {
            if (!existingTags.includes(tag)) newTags = [...newTags, tag];
        }
        return newTags;
    }, []);

    const paths = tags.map(tag => ({
        params: {tag: tag}
    }))

    return {paths, fallback: false};
}

export const getStaticProps: GetStaticProps = (context) => {
    const fs = require("fs");
    const fm = require("front-matter");
    const files = fs.readdirSync(process.cwd() + "/posts/");
    const posts = files.map(file => {
        const thisFile = fs.readFileSync(process.cwd() + "/posts/" + file);
        const thisFm = fm(thisFile.toString());
        return {
            title: thisFm.attributes.title,
            date: thisFm.attributes.date,
            tags: thisFm.attributes.tags ? thisFm.attributes.tags.split(" ") : [],
            body: thisFm.body,
            filename: file,
        }
    }).filter(d => d.tags.includes(context.params.tag));

    return {props: {posts: JSON.parse(JSON.stringify(posts)), tag: context.params.tag}};
}
```

The pages:

![New blog tag page](/blog/2021-12/tag.png)

A last complication of bringing my blog over is that many blog posts still made use of Liquid template tags, such as `{% include youtube-gen.html ... %}` for YouTube video embeds and `{% highlight ... linenos %}` for code blocks.

Thankfully, these were easy enough to replace. If I were using MDX, I could use a proper React component for the YouTube embeds; instead, I just replaced the template tag with some plain HTML:

```
<div class="yt-container">
    <iframe
        src="{youtube URL}"
        frameBorder="0"
        allowFullScreen
    ></iframe>
</div>
```

Code blocks, on the other hand, are a built-in markdown feature (though not language-based highlighting; this is configurable and Jekyll had it set up automatically, but I haven't bothered to do it on my site). I simply replaced occurrences of `{% highlight %}` and `{% endhighlight %}` with the triple-backtick ``` code block indicator of markdown.

## Conclusion

I don't know how much I'll post on my blog, or on my website for that matter. My digital garden has branched out to [Twitter](https://twitter.com/wwsalmon), [Substack](https://samsonzhang.substack.com), and my own platform of [Postulate](https://postulate.us/@samsonzhang), just to mention a few.

There are tons more features to build. My code and building portfolio isn't optimized for the _amount_ of stuff I've built, I think, requiring too much scrolling to get to anything, and most of the projects still link to external project pages. I would want to build a post recommendation feature and improve my blog in a million other ways if I were to go back to using it as my main blog.

In the meantime, if you want to keep up to date on what I build, subscribe to my [Substack](https://samsonzhang.substack.com) and follow me on [Twitter](https://twitter.com/wwsalmon) 😁

Rebuilding my personal website and blog in NextJS (from Jekyll)

**Run `npx create-next-app [your-project-name] -e https://github.com/wwsalmon/next-tailwind-typescript-example`.**

That's it. `cd` into your project and get to work with Typescript and Tailwind fully set up, no extra frills included.

I made [`next-tailwind-typescript-example`](https://github.com/wwsalmon/next-tailwind-typescript-example) after manually setting up Typescript and Tailwind a few too many times. `create-next-app`, Tailwind, and Next make manual set up easier than ever, but it's still tedious to do it over and over again.

If you're curious, though, here's what the six-step manual setup looks like:

1. Run `npx create-next-app [your-project-name]` to get a Next project created and packages installed and such.
2. Install Typescript with `npm i typescript @types/react @types/node`. Rename all your `js` files to `tsx` ones. `tsconfig.json` and `next-env.d.ts` files will be created when you first run `npm run dev` or `next dev`, so you don't have to worry about any manual config.
3. Install Tailwind with `npm i tailwindcss postcss-preset-env -D`.
4. Create a `postcss.config.js` with the following contents:
	
	```
	module.exports = {
	    plugins: ['tailwindcss', 'postcss-preset-env'],
	} 
	```

5. Create a `tailwind.config.js` with the following contents:
	
	```
	module.exports = {
	  purge: [
	    './**/*.html',
	    './**/*.tsx',
	  ],
	  theme: {},
	  variants: {},
	  plugins: [],
	}
	```
	
6. Add the following to the top of your `global.css` file:
	
	```
	@tailwind base;
	@tailwind components;
	@tailwind utilities;
	```

Now get cracking away at whatever you're building!

I like to strip out `create-next-app`'s default contents as well, i.e. deleting `Home.module.css`, deleting the contents of `public` and `pages/api`, and clearing the contents of `index.js` and `global.css`. I also add a `_document.tsx` file to make it easy to link Google Fonts, for example. All of these configurations are made in my example repo.

How To Set Up Tailwind and Typescript in Next.js IN ONE STEP

![](/blog/2021-01/updately-notifications/follow.jpg)

My personal favorite feature in [the 0.3.0 release of Updately](https://preview.mailerlite.com/q7e6t2) was comments. Updately is meant to be a social platform, but there was previously no way to interact with others' posts other than viewing them. Discussion was facilitated, but on different platforms. Comments brought Updately one step closer to being a social platform in its own right.

There was a major flaw, though: users had no way of knowing if another user had left a comment on their update, and reminders had to be sent by other platforms anyways. That's because Updately currently doesn't have any sort of notification system.

Today, I'm going to build a notification system for Updately, using a MongoDB collection just like user profiles, updates, and comments. Notifications will be created when comments or replies to comments are left, and users will see their notifications through the frontend when they log in. In the future, notifications can be expanded both ways: they can be created for more use cases, such as mentions in updates or comments, and also delivered to users in more ways, such as through email. For now, though, we'll focus on creating them only for comments, and checking them only through the frontend.

## 1. Setting up the schema

The first step is to create a new collection for notifications. We do this by defining a Typescript type, then a schema that is exported as a Mongoose model.

`types.ts`:

```jsx
import {Document} from "mongoose";

export interface Notification extends Document {
    _id: string,
    userId: string,
    authorId: string,
    updateId: string,
    type: "comment" | "reply",
    read: boolean,
    createdAt: string, // date string
    updatedAt: string, // date string
}
```

`models.ts`:

```jsx
import mongoose, {Schema, ObjectId, Model} from "mongoose";
import {Notification} from "../utils/types";

// helper type object
const reqString = {
    type: String,
    required: true,
};

// define schema
const notificationSchema: Schema = new Schema({
    userId: ObjectId, // ID of receiving user
    authorId: ObjectId, // ID of comment author
    updateId: ObjectId, // ID of update of comment to generate link and notification message
    type: reqString, // "comment" | "reply"
    read: {type: Boolean, required: true},
}, {
    timestamps: true,
});

// export as model
export const notificationModel Model<Notification> = mongoose.models.notification || mongoose.model('notification', notificationSchema);
```

Originally this schema actually looked quite different: I had `message` and `link` string fields instead of `updateId`, `authorId`, and `type`. This means that the notification can be displayed as soon as the object is loaded. However, this runs into problems if the user or update information changes, which would change both the message and link for the notification. Attaching IDs and types to the notification and letting the frontend handle message and link generation is therefore much more robust.

## 2. Create notifications on comment creation
Comments are created by hitting `/api/new-comment` with a request containing this body info:

```jsx
{
	commentText: commentText,
	authorId: userData._id,
	updateId: update._id,
	updateAuthorId: update.userId,
	commentId: parentCommentId,
}
```

The API endpoint then uses Mongoose to create the comment. Right afterwards, we can use Mongoose to create the appropriate notifications:

```jsx
mongoose.connect(process.env.MONGODB_URL, {
  useNewUrlParser: true,
  useUnifiedTopology: true,
  useFindAndModify: false,
});

const thisUser = await userModel.findOne({ email: session.user.email });

const newComment = {
  body: req.body.commentText,
  authorId: new mongoose.Types.ObjectId(thisUser._id),
  updateId: new mongoose.Types.ObjectId(updateId),
  isSubComment: !!commentId,
  parentCommentId: commentId ? new mongoose.Types.ObjectId(commentId) : null,
};

const returnComment = await commentModel.create(newComment);

// if comment author is not update author, create notification for update author
if (req.body.updateAuthorId !== thisUser._id.toString()) {
  const newNotification = {
    userId: req.body.updateAuthorId,
    updateId: updateId,
    authorId: thisUser._id,
    type: "comment",
    read: false,
  };
  await notificationModel.create(newNotification);
}

// if comment is subcomment, create notifications for authors of all subcomments of parent comment
if (newComment.isSubComment) {
  const parentComment = await commentModel.findOne({ _id: commentId });
  const subComments = await commentModel.find({ parentCommentId: commentId });
  const commentUserIds = [
    parentComment.authorId.toString(),
    ...subComments.map((d) => d.authorId.toString()),
  ]
    .filter((d, i, a) => a.indexOf(d) === i) // filter out duplicates
    .filter(
      (d) => d !== thisUser._id.toString() && d !== req.body.updateAuthorId
    ); // filter out ID of comment and post author
  for (let userId of commentUserIds) {
    const newNotification = {
      userId: userId,
      updateId: updateId,
      authorId: thisUser._id,
      type: "reply",
      read: false,
    };
    await notificationModel.create(newNotification);
  }
}

```

Now, if I go to my sister's update and post a comment, a notification document is added to the notifications collection in MongoDB Atlas.

![](/blog/2021-01/updately-notifications/posting-comment.jpg)

![](/blog/2021-01/updately-notifications/posting-comment-atlas.jpg)

## 3. Fetch notifications

First, we'll create a new API route `get-notifications` that fetches notifications for the user currently logged in. With Next.js, this is as easy as adding a file `get-notifications.ts` to `/pages/api`:

```jsx
export default async function getNotificationsHandler(req: NextApiRequest, res: NextApiResponse) {
    if (req.method !== "GET") return res.status(405);
    const session = await getSession({ req });
    if (!session) return res.status(403).json({message: "You must be signed in to fetch notifications"});

    try {
        const thisUser: User = await getCurrUserRequest(session.user.email);
        const notifications: Notification[] = await getNotifications(thisUser._id.toString());
        if (notifications.length === 0) return res.status(200).json({notifications: [], users: [], updates: [], updateUsers: []});
        else {
            const uniqueAuthorIds: string[] = notifications.map(d => d.authorId).filter((d, i, a) => a.indexOf(d) === i);
            const uniqueUpdateIds: string[] = notifications.map(d => d.updateId).filter((d, i, a) => a.indexOf(d) === i);
            const users: User[] = await userModel.find({ "_id": {$in: uniqueAuthorIds}});
            const updates: Update[] = await updateModel.find({ "_id": {$in: uniqueUpdateIds}});
            const uniqueUpdateUserIds: string[] = updates.map(d => d.userId).filter((d, i, a) => a.indexOf(d) === i);
            const updateUsers: User[] = await userModel.find({ "_id": {$in: uniqueUpdateUserIds}});
            return res.status(200).json({notifications: notifications, users: users, updates: updates, updateUsers: updateUsers});
        }
    } catch (e) {
        res.status(500).json({error: e});
    }
}

export async function getNotifications(userId: string) {
    await mongoose.connect(process.env.MONGODB_URL, {
        useNewUrlParser: true,
        useUnifiedTopology: true,
        useFindAndModify: false,
    });

    return notificationModel.find({ userId: userId });
}
```

The above function follows a similar pattern as comments. Comment documents themselves only contain update and user IDs, while the user information itself is needed to render the comment in the frontend. Instead of having this fetching happen on the frontend, the API call itself returns an array of all associated user objects, which can then be matched up in the frontend to render the comment. The same is done for fetching relevant update and user objects for notifications here.

It's easy now to use `useSWR` in our navbar component to fetch notifications:

```jsx
const { data: notificationsData, error: notificationsError } = useSWR(session ? "/api/get-notifications" : null, fetcher) || {data: null, error: null};
```

## 4. Display notifications

First, I added a simple notification bell:

```jsx
{
  notificationsData && (
    <button className="mr-4 p-2 relative">
      <FiBell />
      {notificationsData.notifications.length > 0 && (
        <div className="rounded-full w-3 h-3 bg-red-500 top-0 right-0 absolute text-white font-bold">
          <span style={% raw %}{{ fontSize: 8, top: -9 }}{% endraw %} className="relative">
            {notificationsData.notifications.length}
          </span>
        </div>
      )}
    </button>
  );
}

```

Then, I added a dropdown menu to it, using some utility classes I had already defined:

```jsx
{
  notificationsData && (
    <button className="mr-4 px-2 h-10 relative up-hover-button">
      <FiBell />
      {notificationsData.notifications.length > 0 && (
        <>
          <div className="rounded-full w-3 h-3 bg-red-500 top-0 right-0 absolute text-white font-bold">
            <span style={% raw %}{{ fontSize: 8, top: -9 }}{% endraw %} className="relative">
              {notificationsData.notifications.length}
            </span>
          </div>
          <div className="up-hover-dropdown mt-10 w-64">
            {notificationsData.notifications
              .sort((a, b) => +new Date(b.createdAt) - +new Date(a.createdAt))
              .map((notification: Notification) => {
                const thisUpdate: Update = notificationsData.updates.find(
                  (d) => d._id === notification.updateId
                );
                const thisUpdateUser: User = notificationsData.updateUsers.find(
                  (d) => d._id === thisUpdate.userId
                );
                const thisAuthor: User = notificationsData.users.find(
                  (d) => d._id === notification.authorId
                );

                return (
                  <MenuLink
                    text={
                      {
                        comment: (
                          <>
                            <span>
                              <b>{thisAuthor.name}</b> commented on your{" "}
                              {format(new Date(thisUpdate.date), "M/d/yy")}{" "}
                              update
                            </span>
                            <br />
                            <span className="opacity-50">
                              {formatDistanceToNow(
                                new Date(notification.createdAt)
                              )}{" "}
                              ago
                            </span>
                          </>
                        ),
                        reply: (
                          <>
                            <span>
                              <b>{thisAuthor.name}</b> replied to your comment
                              on
                              {" " +
                                (thisUpdateUser.email === session.user.email
                                  ? "your"
                                  : thisUpdateUser._id === thisAuthor._id
                                  ? "their"
                                  : thisUpdateUser.name + "'s") +
                                " "}
                              {format(new Date(thisUpdate.date), "M/d/yy")}{" "}
                              update
                            </span>
                            <br />
                            <span className="opacity-50">
                              {formatDistanceToNow(
                                new Date(notification.createdAt)
                              )}{" "}
                              ago
                            </span>
                          </>
                        ),
                      }[notification.type]
                    }
                    href={`/@${thisUpdateUser.urlName}/${thisUpdate.url}`}
                    nowrap={false}
                  />
                );
              })}
          </div>
        </>
      )}
    </button>
  );
}

```

```
.up-hover-dropdown {
    display: none;
    @apply absolute top-0 right-0 z-40 shadow-lg rounded-md bg-white;
}

.up-hover-button:hover > .up-hover-dropdown, .up-hover-button:focus > .up-hover-dropdown {
    display: block;
}
```

And voila! We have a notification dropdown that works great on desktop and mobile. Clicking the notification takes you to the update with the comment.

![](/blog/2021-01/updately-notifications/bell2.jpg)

![](/blog/2021-01/updately-notifications/notif.jpg)

![](/blog/2021-01/updately-notifications/notif2.jpg)

## 5. Mark notifications as read
First, I made an api route `/api/read-notifications`, to which a notification ID can be posted to mark it as read.

```jsx
import {NextApiRequest, NextApiResponse} from "next";
import {notificationModel} from "../../models/models";
import mongoose from "mongoose";
import {getSession} from "next-auth/client";
import {getCurrUserRequest} from "../../utils/requests";
import {Notification, User} from "../../utils/types";

export default async function readNotificationsHandler(req: NextApiRequest, res: NextApiResponse) {
    if (req.method !== "POST") return res.status(405);
    const session = await getSession({ req });
    if (!session) return res.status(403).json({message: "You must be signed in to mark a notification as read"});
    if (!req.body.id) return res.status(422).json({message: "No notification ID found in request"});

    try {
        console.log(req.body.id);

        const thisUser: User = await getCurrUserRequest(session.user.email);
        const thisNotification: Notification = await getNotification(req.body.id);

        if (!thisNotification) return res.status(404).json({message: "No notification found for given ID"});
        if (thisNotification.userId.toString() !== thisUser._id.toString()) return res.status(403).json({message: "You do not have permission to mark this notification as read"});

        thisNotification["read"] = true;
        await thisNotification.save();
        res.status(200).json({message: "Successfully marked notification as read"});
    } catch (e) {
        res.status(500).json({error: e});
    }
}

export async function getNotification(notificationId: string): Promise<Notification> {
    await mongoose.connect(process.env.MONGODB_URL, {
        useNewUrlParser: true,
        useUnifiedTopology: true,
        useFindAndModify: false,
    });

    return notificationModel.findOne({ _id: notificationId });
}
```

At first, I considered adding an `onClick` handler to the notification link, which Next.js allows to execute before redirecting. This would be easier than parsing anything additional on the navigated to page, I thought. Using an `onClick` handler would cause a wait time before navigation, though. And I soon realized a pretty easy way to have the notification be marked as read on the navigated to page: pass the notification ID as a query param, and run a `useEffect` function to mark the notification as read if it's present.

The link in `navbar.tsx` now looks like this: 

```jsx
href={`/@${thisUpdateUser.urlName}/${thisUpdate.url}?notification=${notification._id}`}
```

And in `[updateUrl].tsx`, a useEffect hook that looks like this:

```jsx
useEffect(() => {
  if (router.query.notification) {
    axios
      .post("/api/read-notification", {
        id: router.query.notification,
      })
      .then((res) => {
        console.log(res);
      })
      .catch((e) => {
        console.log(e);
      });
  }
}, [router.query.notification]);
```

Now we just need to adjust the `navbar` frontend code to display read notifications differently. First I calculate a new variable, the number of unread notifications: `const numNotifications = notificationsData ? notificationsData.notifications.filter(d => !d.read).length : 0` (`notificationsData` is undefined as `useSWR` fetches it).

Now, I only display the badge on the bell if `numNotifications` is above zero:

```jsx
{
  numNotifications > 0 && (
    <div className="rounded-full w-3 h-3 bg-red-500 top-0 right-0 absolute text-white font-bold">
      <span style={% raw %}{{ fontSize: 8, top: -9 }}{% endraw %} className="relative">
        {numNotifications}
      </span>
    </div>
  );
}
```

I also wrapped each notification menu item in a div making the notification half-opacity if it's read:

```jsx
<div key={notification._id} className={notification.read ? "opacity-50" : ""}>
  <MenuLink ... />
</div>
```

With that, we have, more or less, a complete working notification system!

![](/blog/2021-01/updately-notifications/half-opacity.jpg)

## 6. Clear out old notifications

As users get notifications, it'll build up endlessly both on the user side menu and in the database, which we don't want. As a simple fix, whenever a user fetches their notifications, we'll delete all read notifications older than 14 days. This is straightforward to implement with a few array operations:

```jsx
...

// delete read notifications older than 14 days
const oldNotificationIds: string[] = notifications
  .filter((d) => d.read && +new Date() - +new Date(d.createdAt) > 14 * 8.64e7)
  .map((d) => d._id.toString());
await notificationModel.deleteMany({ _id: { $in: oldNotificationIds } });

notifications = notifications.filter(
  (d) => !oldNotificationIds.includes(d._id.toString())
);


...
```

## 7. Conclusion & extensions
That's it for this basic notification system!

There are plenty of improvements to be made. `useSWR` doesn't re-fetch notifications after one is clicked, for example, which is a simple matter of passing a key variable to the hook to fix. If there are a lot of notifications, there's no height limit or overflow on the notification menu, but again this is a simple fix using CSS.

It's easy to extend this system to new types of notifications, too. For example, I added notifications for when users follow each other.

Hopefully this post is a helpful example of how you might implement your own notification system using MongoDB!

![](/blog/2021-01/updately-notifications/follow.jpg)

Implementing Notifications Using MongoDB and Next.js for Updately

![](/blog/2021-01/edyfi-elo/final.jpg)

At the community house [Edyfi](https://edyfi.co/85e37d59e0064c8d8f4f2cb91168eb18), we have a ping pong table. As soon as quanratine ended, we started playing a lot of ping pong.

Ben and Luke put together a roll of white board paper on the wall to track their ping pong games. Over the course of the day, the rest of us added our games as well.

It got chaotic pretty quickly, and I got to thinking -- what if we had an Elo rating system for the house? Matches would have actual stakes attached. This is day two of ping pong being available and we'll be here for two more months, figuring out a rating system felt like a good investment.

Immediately, my mind went to creating a React app. Ben recommended we look for an existing tool first. We found [https://github.com/altuzar/pingpong-elo-ranking](https://github.com/altuzar/pingpong-elo-ranking), but it was a little jank (requiring each player to make an account and log in to log games). At the end of the day, I was surprised to come up short, without a good existing solution. So, building our own it was.

I got as far as typing `create-next-app` into my terminal before restraining myself again. React is so heavy, surely there was a way to do this without React. We would need a database, too. Here, my mind went to AirTable. I set up a table and put in existing games pretty quickly, with a couple of nice fields like auto-incrementing IDs, creation datetime, and winning player determined by score.

![](/blog/2021-01/edyfi-elo/airtable.jpg)

I then set about looking how to calculate Elo through AirTable, but confronted with the difficulty of using formulas across tables and the heft of developing an AirTable app to use scripts, I gave up and decided to use AirTable's API and handle calculations separately.

Considering that AirTable's API requires an authentication token to access, my browser-JS dream went out the window too. I needed to set up serverside functions of some sort, as well as a frontend. Put those needs together, and the best tool by far is...NextJS. I hate to use something as heavy as React for something this simple, but devX trumps stack efficiency for a quick build like this. Let's get into it then!

## Accessing AirTable
First, I created a `.env` file and threw my AirTable key in it. Nice and secure, and NextJS makes this zero-config.

In typical create-next-app fashion, I deleted the `/api` folder, `/public` items, `Home.module.css`, and the contents of `index.js`. I'll leave `globals.css` to have some easy styling.

`npm i airtable` gets me AirTable's JS library. Now it's easy to fetch info for all games using `getServerSideProps`:

```jsx
import Head from 'next/head';
import airtable from "airtable";

export default function Home({games}) {
    console.log(games);

    return (
        <>
            <Head>
                <title>Edyfi ping pong Elo tracker</title>
            </Head>
        </>
    );
}

export async function getServerSideProps(ctx) {
    const base = airtable.base("appJW8IinnjFjPllg");
    const games = await base("Games").select().all();
    const gamesFields = games.map(d => d.fields);
    return {props: {games: JSON.parse(JSON.stringify(gamesFields))}};
}
```

![](/blog/2021-01/edyfi-elo/browser.jpg)

## Calculating Elo
With some nice ES6 array operations, we first get a list of unique players from the game records, then initialize an object with each player's Elo rating:

```jsx
// all unique player names
const allPlayers = [...games.map(d => d["Player 1"]), ...games.map(d => d["Player 2"])]
		.filter((d, i, a) => a.indexOf(d) === i);

// initialize dictionary with each player at rating 1000
let playerElos = Object.fromEntries(allPlayers.map(d => [d, 1000]));

console.log(playerElos);
```

![](/blog/2021-01/edyfi-elo/ratings.jpg)

Now we just need to run through all the games and use the Elo formula to calculate the Elo for each player:

![](/blog/2021-01/edyfi-elo/elo-formula.png)

(Credit: [https://www.coorpacademy.com/en/blog/learning-innovation-en/elo-whos-the-best/](https://www.coorpacademy.com/en/blog/learning-innovation-en/elo-whos-the-best/))

```jsx
// maximum amount rating can be changed per game
const maxChange = 30;

for (let game of games.sort((a, b) => +new Date(a["Date"]) < +new Date(b["Date"]))) {
        const rating1 = playerElos[game["Player 1"]];
        const rating2 = playerElos[game["Player 2"]];
        const expected1 = 1 / (1 + 10 ** ((rating2 - rating1) / 400))
        const expected2 = 1 / (1 + 10 ** ((rating1 - rating2) / 400))
        const score1 = +(game["Win"] === game["Player 1"]);
        const score2 = +(game["Win"] === game["Player 2"]);
        const newRating1 = rating1 + maxChange * (score1 - expected1);
        const newRating2 = rating2 + maxChange * (score2 - expected2);
        playerElos[game["Player 1"]] = newRating1;
        playerElos[game["Player 2"]] = newRating2;
}
```

![](/blog/2021-01/edyfi-elo/elos.jpg)

## Displaying Elo and games
First, let's refactor the earlier calculations into a state variable and `useEffect` hook:

```jsx
const [playerElos, setPlayerElos] = useState(function(){
        // all unique player names
        const allPlayers = [...games.map(d => d["Player 1"]), ...games.map(d => d["Player 2"])]
                .filter((d, i, a) => a.indexOf(d) === i);

        // initialize dictionary with each player at rating 1000
        return Object.fromEntries(allPlayers.map(d => [d, 1000]));
}());

useEffect(() => {
        // maximum amount rating can be changed per game
        const maxChange = 30;

        let newPlayerElos = {...playerElos};

        for (let game of games.sort((a, b) => +new Date(a["Date"]) < +new Date(b["Date"]))) {
                const rating1 = newPlayerElos[game["Player 1"]];
                const rating2 = newPlayerElos[game["Player 2"]];
                const expected1 = 1 / (1 + 10 ** ((rating2 - rating1) / 400))
                const expected2 = 1 / (1 + 10 ** ((rating1 - rating2) / 400))
                const score1 = +(game["Win"] === game["Player 1"]);
                const score2 = +(game["Win"] === game["Player 2"]);
                const newRating1 = rating1 + maxChange * (score1 - expected1);
                const newRating2 = rating2 + maxChange * (score2 - expected2);
                newPlayerElos[game["Player 1"]] = newRating1;
                newPlayerElos[game["Player 2"]] = newRating2;
        }

        setPlayerElos(newPlayerElos);
}, []);
```

For styling, I went with [`water.css`](https://watercss.kognise.dev/), a classless CSS framework. From here, it's super easy to bash out a few HTML tables and get the rest of the site going:

```jsx
<Head>
    <title>Edyfi ping pong Elo tracker</title>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/water.css@2/out/water.css"/>
</Head>
<h2>Player stats</h2>
<table>
    <thead>
        <tr>
            <th>Rank</th>
            <th>Name</th>
            <th>Elo</th>
        </tr>
    </thead>
    <tbody>
        {Object.entries(playerElos)
            .sort((a, b) => b[1] - a[1])
            .map((player, i) => (
                <tr>
                    <td>{i + 1}</td>
                    <td>{player[0]}</td>
                    <td>{Math.floor(player[1])}</td>
                </tr>
            ))
        }
    </tbody>
</table>
<hr/>
<h2>Post new game</h2>
<p><a href="https://airtable.com/shrl6FUmJspGANrPK">+ Post new game through AirTable form</a></p>
<hr/>
<h2>Past games</h2>
<table>
    <thead>
        <tr>
            <th>Date</th>
            <th>Player 1</th>
            <th>Score 1</th>
            <th>Player 2</th>
            <th>Score 2</th>
        </tr>
    </thead>
    <tbody>
    {games.sort((a, b) => +new Date(b["Date"]) - +new Date(a["Date"])).map(game => (
        <tr>
            <td>{format(new Date(game.Date), "M/d 'at' h:mm aa")}</td>
            <td>{game["Player 1"]}</td>
            <td>{game["Player 1 score"]}</td>
            <td>{game["Player 2"]}</td>
            <td>{game["Player 2 score"]}</td>
        </tr>
    ))}
    </tbody>
</table>
```

I'll stop here for this basic implementation, but there's much more that can be done with this interface (some updates, like win/loss counts, are shown in the final image at the top of this post)! Per-game Elo, specific matchup records, player win/loss records, etc. That's just a matter of more lines of code, though, so I won't document it that thoroughly.

![](/blog/2021-01/edyfi-elo/prototype.jpg)

From here, it was a super easy one-click deploy to Vercel, and the site was live for all the members of the house to use. Productivity has since tanked.

Nothing super fancy going on here, but it's pretty amazing how easy it is to bash out a full webapp in less than an hour with today's web technology and services.

Creating a Ping Pong Elo Tracker for Edyfi in 1 Hour

I built and launched a social platform app in three days. Here's how I did it, and what I learned

Understanding the math behind neural networks by building one from scratch (no TF/Keras, just numpy)

![](/blog/2020-09/gd-cover.png)

If you've taken a lab science class in school, you've probably had to fit a line of best fit to experimental data: whether it's to experimentally determine the acceleration of gravity, calculate the results of a chemical reaction, or prove that two variables are correlated. You plug your numbers into a spreadsheet, hit "fit trendline," and out pops a nice linear or exponential equation. But how does Excel or Google Sheets come up with this equation?

This problem is that of training a linear regression model. There are lots of statistics-related theorems and considerations behind it, but this article will focus on an algorithm that computers use to actually find the best fit equation given a dataset. The same principles that empower Excel to find a line of best fit are the fundamentals for a variety of machine learning algorithms and applications, from **deep neural networks** to **recommendation systems.** **Understanding linear regression is a great first step to understanding all the other cool ML algorithms out there — and it's not even that hard!** Let's dive in.

*Note: all graphs, calculations, and even data used in this article were created by me in Python. Check out the source code in [this Jupyter notebook](https://colab.research.google.com/drive/1fwNB1WH03KnEq221Xe1grJeYmkx46pi6?usp=sharing).*

## The basics: mean squared error cost function

Here's a dataset to fit a line to.

![](/blog/2020-09/Untitled.png)

If you've taken Algebra, you should be familiar with the equation for a line:

$$y = mx + b$$

By tweaking m and b, we can conjure up any line that we want to. We can take a few guesses at a line of best fit for our dataset:

![](/blog/2020-09/Untitled%201.png)

Clearly, some of these lines fit the data better than others. Yellow looks the best — green is too steep, and blue isn't steep enough. But how can we know for sure that yellow is better than green and blue? And how can we find not just a good line, but the best line possible?

We can start by coming up with a number to measure how well a line fits the given data. We can use a metric called the mean squared error.

To calculate the mean squared error, take every example and measure the vertical distance between it and the line above or below. Square this distance, then average the squares of all examples.

![](/blog/2020-09/Untitled%202.png)

Here's the formula for calculating mean squared error for our linear equation:

{% raw %}
$$J = \frac{1}{2 \cdot \text{# examples}} \sum_{i = 1}^\text{# examples} ((mx^{(i)}+b) - y^{(i)})^2$$
{% endraw %}

where $$x^{(i)}$$ and $$y^{(i)}$$ are the i-th pair of x and y values in our dataset.

The lower the MSE is, the better the line fits the data. This should make sense — all that MSE is measuring is the average squared distance from the data points to the corresponding predicted value on the line. The smaller this distance, the better the line.

We can use a simple loop in Python to calculate the mean squared error of the three lines we guessed above:

```python
def mean_squared_error(m, b, x_data, y_data):
	num_examples = x_data.size
	J = 0

	for i in range(num_examples):
		J += ((m * x_data[i] + b) - y_data[i]) ** 2

	J = J / (2 * num_examples)

	return J

print(mean_squared_error(1, 50, x_data, y_data))
print(mean_squared_error(2, 50, x_data, y_data))
print(mean_squared_error(4, -50, x_data, y_data))
```

We get that the MSE for the first line — our blue, too low line — is 2070.76. The MSE for the second line — our yellow, seems-best line — is a mere 375.26. The MSE for the third line — the green, too-steep line — is back up to 2280.60.

This confirms our visual findings from before. Our yellow line, with the equation $$y = 2x + 50$$, has the lowest MSE and fits the data much better than the two other lines. By this metric, our blue line is also worse than our green line.

With this metric, we're one step closer to a systematic way to find a line of best fit. We can now guess a bunch of lines, and then check their mean squared error, keeping the one with the lowest MSE and maybe tweaking it some more.

This is random and inefficient, though. Luckily, there's a much better, systematic way of finding the best possible line once we've defined our cost function (MSE).

## Finding the optimal solution: gradient descent

Let's return to one of our bad lines:

![](/blog/2020-09/Untitled%203.png)

If we want to improve it, what should we do? A lot of the points look like they're above the line, so let's increase b to 70.

![](/blog/2020-09/Untitled%204.png)

Looks a little better, and our MSE has dropped by almost 40%, from 2071 to 1286! Let's keep going and increase b to 90.

![](/blog/2020-09/Untitled%205.png)

Another drop, to MSE = 902. Now let's try b = 110:

![](/blog/2020-09/Untitled%206.png)

...and now we've overshot it, with our MSE increasing to 918.

To find the optimal value of b and not overshoot, we might graph the MSE against different values of b.

![](/blog/2020-09/Untitled%207.png)

Looks like the optimal value is just below 100. If you've taken algebra or calculus, your instinct at this point might be to bust out some derivatives or quadratic equations and try to find out exactly what this point is — but it's not so easy, because we don't actually have the equation for this line. Every one of those points above was computed by looping through 100 training examples and averaging their errors.

Instead of finding the optimal value analytically, then, we do it numerically.[^normaleq] These are fancy names for saying that instead of trying to solve an equation exactly, we'll use clever tricks to arrive at the right answer by changing our answers just a little bit, over and over.

Let's go back to our starting point at b = 50. Let's plot the slope of our b vs. MSE plot at b = 50:

![](/blog/2020-09/Untitled%208.png)

We can find the slope at a given point using this formula:

$$\frac{\delta J}{\delta b} = \frac{1}{\text{# examples}} \sum_{i = 1}^\text{# examples} ((mx^{(i)}+b) - y^{(i)})$$

If you've taken calculus, you can take the derivative of our earlier mean squared error function (J) with respect to b yourself and see if your answer matches. If you don't know calculus, just accept that this equation accurately gives us the slope at a given point. Look into derivatives separately if you want.

The point is, once we have this slope, we can nudge b an amount proportional to the steepness of the slope. Think of it like rolling down a hill. If the hill is steeper, you'll roll down more. If it's shallower, you'll roll down less. If you keep rolling down a hill like this, you'll eventually get to the lowest point of the valley — and in this case, our ideal value for b.

In equation form, this is what we're doing:

$$\text{repeat } i \text{ times } \{

b := b - \alpha \frac{\delta J}{\delta b}

\}$$

It might look a little confusing, but all we're doing here is what we said earlier: nudging b an amount proportional to the steepness, or gradient, of the graph of the cost function at that point. $$\alpha$$, or alpha, is called the "learning rate" — it's a multiplier on how much you slide down the hill, something like the strength of gravity or the slipperiness of the hill. If alpha is big, you'll slide down the hill quickly. If it's small, you'll slide down it bit by bit. As you slide towards the bottom of the valley, the gradient will flatten out and steps will become smaller. The value that you're optimizing will then converge to the value that results in the lowest error — the best fit b for your data, in this case.

With a learning rate of 0.5, we roughly converge to a b value around 99 in less than ten steps:

![](/blog/2020-09/Untitled%209.png)

We've only found the optimal value for b, however. Our MSE is still above 800, more than double that of our initial best-guess line, 2x + 50. We could now set b to be 99 and optimize for m, but that wouldn't get us the best answer either. To get the actual line of best fit, we have to optimize for both m and b at the same time.

To do this, we can plot J against both m and b using a contour map:

![](/blog/2020-09/Untitled%2010.png)

![](/blog/2020-09/Untitled%2011.png)

You may have seen contour maps of a mountain or particular region before. Such a map shows the land elevation at a given point. The contour map above does a very similar thing: it shows the mean squared error for every pair of $$m$$ and $$b$$ values. By finding the $$m$$ and $$b$$ values that give us the lowest possible mean squared error, then, we'll have found our line of best fit.

The intuition here — and the math — is the same as before: we find the slope (gradient) at a given point, and roll down the hill (change our parameters) an amount proportional to how steep the slope is. When we calculate the gradient at a certain point, we no longer have just one value, but two values, corresponding to how the cost function changes when you nudge either m or b.

The formula for calculating these two gradient values at a given point are as follows:

$$\frac{\delta J}{\delta b} = \frac{1}{\text{# examples}}\sum_{i = 1}^\text{# examples} ((mx^{(i)}+b) - y^{(i)}) \\
\frac{\delta J}{\delta m} = \frac{1}{\text{# examples}}\sum_{i = 1}^\text{# examples} ((mx^{(i)}+b) - y^{(i)})x$$

Before, we subtracted the gradient with respect to b, times a learning rate, from b to get our new value. We'll do that again here, and we'll do the same separately for m, *at the same time*:

$$\text{repeat } i \text{ times }\\\{\\
b := b - \alpha \frac{\delta J}{\delta b} \\
m := m - \alpha \frac{\delta J}{\delta m}
\\\}$$

Just as before, we can illustrate this two-variable gradient descent visually on our contour map and 3D plot. I plotted gradient descent from three starting points (red: m = 3, b = 150; green: m = 1, b = -200; blue: m = 1, b = 103).

![](/blog/2020-09/Untitled%2012.png)

As you can see, it doesn't matter where you start — gradient descent will eventually lead you to the right answer. In fact, standard practice when training machine learning models is to use small random values for your starting points.

In this case, following the gradient, we find an approximate global minimum at m = 2 and b = 49. Translating back from the world of equations and graphs, this means that the line (approximately) $$y = 2x + 49$$ results in the lowest mean squared error when measured against our dataset, and consequently is the **line of best fit for the dataset**[^theorem], what we've been looking for all along.

Phew! After all that hard work, we're finally done. Let's do a quick recap of what just went down.

- We defined a cost function, something called the "mean squared error" that measures how far the predictions of our model are from the actual data.
- Our objective is to minimize the cost function (in fact, another name for the cost function is the "objective function").
- We started this by graphing the cost function against one parameter, in this case the y-intercept (b) of the line.
- To minimize the cost function, we "nudged" the parameter in the direction that would decrease the cost.
- We used gradient descent is a way to make these nudges systematically, by choosing them proportional to the slope, or gradient, of the graph. It's like rolling downhill!
- We then included our second parameter, in this case the slope of the line, in our graph of the cost function. It can now be visualized as a contour plot, or a 3D surface.
- We can apply the same method as earlier — gradient descent, sliding downhill with the slope of the 3D surface — to optimize both parameters at once. This gives us the optimal parameters m and b, yielding our line of best fit.

This might seem like a lot to take in, especially the mathematical equations. I know it took me a good few learning days to gain a sense of comfort with them. Understanding the math behind how to fit a trendline, though, is incredibly useful for understanding tons of other machine learning algorithms out there.

## Beyond linear regression: a fundamental concept in machine learning

The general pattern of defining a cost function and using gradient descent to optimize for it is ubiquitous in supervised learning algorithms. Fitting a polynomial function to a dataset rather than a straight line, for example, is as easy as defining the cost function as the following:

$$J = \frac{1}{2 \cdot \text{# examples}} \sum_{i = 1}^\text{# examples} ((\theta_0 + \theta_1 x^{(i)} + \theta_2 x^{(i)2}) - y^{(i)})^2$$

where we now have three parameters theta 0, theta 1, and theta 2 to optimize rather than just m and b. In fact, we can throw as many more parameters as we want at the cost function, and very often optimize hundreds or thousands of parameters in just this way.

Instead of a line of best fit (a regression model with continuous outputs), we can train a classifier using the very same cost function-gradient descent strategy. We do this by running the continuous model output through a logistic (or sigmoid) function, which outputs a number between 0 and 1 that we can interpret as a probability of the input belonging to a certain class.

Neural networks use cost functions and gradient descent too, though the cost function and parameter optimization methods are a bit more complicated, involving in-between feed-forward and backpropagation algorithms.

Even some unsupervised learning problems — that is, models where there is no "right" answer that can be provided in training data — use cost functions and gradient descent. When training a recommendation algorithm, like Netflix or Amazon might use to recommend you movies and products, a cost function is defined that simultaneously optimizes for parameters fitting users' preferences and the categorization of different items.

It's easy to just say these things. You might even have heard of gradient descent, and the analogy of sliding down a hill, before reading this article. For me at least, though, it's much more helpful to see the concrete math. I like learning how an algorithm works well enough to be able to code it from scratch, without using TensorFlow or scikit-learn or whatever is out there. Of course, if I'm working on an actual project, I'll use the better-optimized and more advanced tools that these libraries have to offer; even then, though, I'm guided by the intuition I gained from going very hands-on into the math.

A lot of the math isn't super hard, either. In this article, for example, the most advanced things that you need to understand are summation loops and...squares. Sure, there were a few derivatives, but I didn't tell you what they meant, because you don't need to know to build your core mathematical machine learning intuition. This relative mathematical simplicity extends, again, beyond linear regression to most of the common machine learning algorithms in use out there. Neural networks are really just *a lot* of summation loops strung together cleverly. If you fully understand the contents of this article, you're already well on your way to being able to write a neural network from scratch yourself.

To get a rigorous but accessible overview of the math behind gradient descent, linear regression, neural networks, recommendation systems, and everything that I mentioned in this article, I highly recommend Andrew Ng's [free Machine Learning course](https://www.coursera.org/learn/machine-learning) on Coursera. People's minds work differently — maybe trying to understand the math won't be especially helpful for you, but for me it built the foundation of all of my applicable machine learning intuition and knowledge today. Maybe this article will convince you to start building this foundation for yourself :)

[^normaleq]: There actually is a way to find the optimal value analytically, using something called the normal equation. This equation puts all data points in a big matrix, then uses some fancy linear algebra to exactly find the linear regression parameters that minimize the mean squared error. Because it's multiplying matrices together, though, if you have lots of data or lots of variables, the normal equation can become very slow to compute compared to gradient descent.)

[^theorem]: We know that minimizing mean squared error results in the parameters for the best fit line because of the [Gauss-Markov theorem](https://en.wikipedia.org/wiki/Gauss%E2%80%93Markov_theorem?oldformat=true).

How Excel calculates trendlines, and how you can too: an introduction to gradient descent, the most important Machine Learning algorithm

<a href="https://www.producthunt.com/posts/sz-project-tracker" target="_blank" style="border-bottom: 0;">
	![](/blog/2020-07/szpt-ph.jpg)
	</a>

*Also posted on [IndieHackers](https://www.indiehackers.com/post/from-fearing-react-to-ph-webapp-launch-in-2-months-8b9f102b7c) and [DEV.to](https://dev.to/wwsalmon/from-fearing-react-to-ph-webapp-launch-in-2-months-4d58). See the project case study [here]({{ site.baseurl }}/sz-project-tracker)*

Four months ago, I didn't know React or any other JS framework. In fact, having done tons of static web dev work, I was terrified of React. How do you make an entire website in JavaScript??

Still, I wanted to go beyond making landing pages and WordPress templates. I made several attempts at learning React and some backend stuff like the MERN stack. In theory, I know how to spin up a MERN app with a CRUD API and all, but none of these tutorials really stuck with me. I was left not knowing how to deploy the local apps and servers I had built, not knowing how to extend it into something usable.

Eventually, I found my way to serverless-stack.com. This was a huge tutorial that teaches you how to set up an AWS backend (Cognito, DynamoDB, Lambda proxy API), as well as a React frontend connected through it. It didn't teach how to use these tools so much as just use them, throwing new functions and AWS services at you every other page. This is how I learn best, though -- from blitzing through full React page after React page, I started to pick up a better intuition than I had from any tutorial before. I finished the tutorial series in about a week and a half in May.

Throughout the process, I tracked my learning and progress in a markdown file committed to the repo. I did the same for another project. It was really useful to have screenshots and code snippets from previous versions to reference in blog posts, or just for personal reflection. Using a nice, lightweight markdown editor was the best solution I found for jotting down these quick updates, but I kept thinking about how nice it would be to have an app properly designed for this. I looked online, but surprisingly couldn't find one. Well, good thing I've been learning how to make one!

So that's the project that I jumped into: an app to track your projects, making dev and learning logs 10x easier to keep than with a traditional or markdown document editor. I actually ditched the Serverless framework as I was taught in serverless-stack, instead using AWS Amplify CLI to super quickly get all my services up and running; still, serverless-stack served as my main guide, for backend as well as frontend reference.

At some point in the project, I outgrew serverless-stack for both frontend and backend. Frontend came first. Serverless-stack used class components, while newer tutorials used functional components; my code was a hodgepodge of both at the beginning. [Josh Kaufman says that, contrary to the 10,000 hours of learning => expert rule, you can learn something *reasonably* well in 20 hours](https://www.youtube.com/watch?v=5MgBikgcWnY). I remember almost tangibly *feeling* this kind of 20 hour mark. I split off my code into components and lib functions, refactored class components into functional ones with confidence. A partner joined the team, and I was surprised to realize how much better I could recognize good or bad React code in PRs just weeks after not knowing React at all.

Backend came much later -- really in the last week, even. I was scared of the Amplify CLI. There were so many config files, with so many parameters and variables. Every push I made came with the warning that things might break, that data might be lost. So I worked with the backend as little as I could at first. I set up auth, storage, API, and just left it; API schema updates were all I dared to run. I couldn't run away forever, though. Two features, both procrastinated until this very last week, forced me to actually learn. One was making images attached to public updates publicly viewable, as they were uploaded into private S3 buckets. My nicely protective Amplify functions weren't enough for this. Now I had to deal with ACLs, using the full AWS SDK, dealing with credentials and auth tokens directly -- diving straight into the backend config stuff that I feared most. The second feature was adding users to a Mailchimp mailing list on signup. Mailchimp has a nice API, but it can't be called on the clientside, so I had to set up a Lambda function for it. I decided to do this on pre-launch day. "This should be quick," I thought at 2PM; at 11:20PM, having coded discreetly through a meeting, it finally seemed to work. I asked a friend to sign up with her Google account, and felt a huge sense of relief when her email popped up in the Mailchimp audience list.

Progress on this project was quite sporadic, as side-projects often are. I would blitz forwards for a week, knocking out feature after feature and squashing bug after bug, then the rest of my life would catch up to me and I would take a lull. When a partner and mentor joined the team, progress actually slowed down; caught in thinking about containerized environments, CI/CD, delegating work, etc., I lost the motivation that came from tangible progress. I was also consistently working in unfamiliar territory. I had no idea how to solve or even approach many of the problems I came up against; I would stare for hours at documentation and tutorial videos, writing test functions, my frustration growing as I didn't seem to make an inch of progress. Out of many, many repeated such experiences, though, I found that this frustrated deadlock often *did* eventually result in learning and progress. "Micro-framework: let yourself be stuck on things for three hours. Stare at tutorials, write test functions, don't make progress; struggle & learn and eventually it just might click," [I tweeted after one session](https://twitter.com/wwsalmon/status/1280620786664038405). One potential implication, then, is that this kind of learning and from-scratch skill building can't be done in small chunks, but rather require continuous long blocks of time. (Not entirely sure if this is true, maybe it would actually be sped up if broken apart? To be tested, but the value of long continuous blocks of work time is a popular idea)

One day, I was tired of this project sitting around, draining me of my energy as the rest of my life and what I could be doing flew by.

"We're gonna launch in two weeks, by Wednesday, July 8," I told my partner. Planning out features, we frequently said things like, "this isn't necessary for v1, let's implement it for v2." It's the classic "cut scope rather than extending the deadline" -- and it worked. I had a target. My energy was back. I refactored code, redesigned UIs, and added small missing features like crazy, in the course of four or five days sprinting across the remaining distance to a mostly functional, fairly reliable app.

An online community/program I've been a part of, [Summer of Shipping](https://summerofshipping.com/), has demo opportunities at meetings every Thursday. My goal was to demo that Thursday; I grabbed a few screenshots, wrote some copy, and put together a quick landing page (so easy with @rmrm's a17t and Tailwind CSS). My demo was full of bugs (Google sign-in redirected to localhost instead of live site, Twitter URL opened as relative instead of absolute...everything goes wrong in the demo), but it was mostly done and out there!

The idea of a ProductHunt launch was really only in the back of my mind until pretty late on. I had previously launched a [Chrome extension, YouTube Liberation](https://www.producthunt.com/posts/youtube-liberation) on PH. My friends and everyone I reached out to raved about how useful the extension was, but after hyping myself up, greating a fancy animated thumbnail, choosing the day to post to get maximum views, I got all of...three upvotes. For this project, my expectations were basically non-existant. I built it for myself; I hadn't showed many other people, nor did anyone seem especially like they were jumping for it. Still, I had pretty much already made everything I needed when making the landing page. It'd be minimal effort to just hop in Illustrator, turn these into graphics, and toss it up on PH, I thought. This time I at least have the Summer of Shipping network -- maybe it'll get a few signups.

Yesterday morning, I fixed the bugs from the demo, filled out the PH fields, and was about to hit launch when I remembered that PH allowed you to launch through a hunter. It just so happened that @swyx, senior dev advocate at AWS working on Amplify and a huge advocate for the "build in public" mentality that Summer of Shipping and my project tracker alike build upon, had given a talk at Thursday's SoS meeting and seen my demo. I messaged him on Twitter, sending over my prepared slides, asking him if he would be willing to hunt the product for me. I wasn't sure if he would -- were my product, my hastily assembled marketing materials good enough? Would he harshly dismiss me? No! He said yes!

I sent him some more materials. He sent me...bugs that he encountered when he signed up for the app. "Today will be a bit of a bug squashing marathon 😅," I messaged him. "Better prelaunch than postlaunch," he replied.

I had a bunch of other work I was planning to yesterday. For a design job, I needed to put together mockups by Saturday; for an entrepreneurship program, conduct a bunch of customer interviews. Instead of doing this, I ended up spending the whole day fixing bugs and making minor improvements. I changed the url from the abysmal sz-project-tracker-v0.netlify.app to the slightly less abysmal szpt.netlify.app. I wanted a mailing list of people who signed up, so I made a Mailchimp account and looked into their API. This, oh god, this was 8 hours straight of the standstill blundering-my-way-through learning that I had talked about earlier.

Everything was bashed out. The PH page was ready. At midnight, it went live. I woke up at 8:30 AM this morning. The PH page had 8 upvotes. Already broke my 3 upvote record, lmao...but I thought I could do better. I posted on Twitter; I asked @swyx, [@irid](https://twitter.com/coolnalu), and some others to repost; I posted this very blog post, which was originally intended to be mostly promotional but turned into the much more substantial story it is now, on [IndieHackers](https://www.indiehackers.com/edit-post/8b9f102b7c) and [DEV.to](https://dev.to/wwsalmon/from-fearing-react-to-ph-webapp-launch-in-2-months-4d58).

As of writing this post, SZPT has 47 upvotes on ProductHunt, dropping from 13th, to 14th, to 15th on the homepage as the day went on, with 27 new signups on the app. It's not huge -- this app isn't "taking off," so fortunately my AWS bill won't either -- but it's *a good amount* of people using an app that's my first-ever webapp, that I buitl for myself. My only hope is that they'll find legitimate value in it, and value in me as a creator of products.

This is the culmination of two full months of learning and building, from being terrified of JavaScript and writing about the death of hand-written CSS to falling in love with React and CSS frameworks like Tailwind and a17t. Other than technical skills, what have I learned? I think two big ideas have been heavily affirmed:

- "Do to learn, not to do." This is a long-held philosophy of mine, and it's really been the driving force for getting to where I am today. I didn't go to any bootcamps or follow any curriculums in the past two months, but I've made myself so much more valuable by just diving in and trying to make things that I care about (my GitHub got me hired as frontend developer at an early-stage startup!).

- Prioritize connections, people, and communities. Did going to Summer of Shipping talks about the inner workings of authentication or HTTP/CORS help me build my app? No, but it gave me a group of people to be a part of; my work provided value for the community, so mentors could invest their time in me. Indirectly, SoS had a huge impact on my network too, by pushing me to get on Twitter, and creating opportunities for engagement through mentors' and the community's accounts. Through SoS and more broadly on Twitter, I've connected with so many amazing people, building a network of experts and industry professionals as well as people working on their own projects and careers like me, who have kept me going and offered incredible insights and advice when I reached out to them.

These, really, are my two superweapons. They've empowered me so much; the realm of possibilities in front of me seems unbounded. What's next for me? We'll see how szpt goes, maybe I'll work on it a bit more. In the longer term,  I have an amazing mentor pushing me to find something that I would want to work on for the next 5-7 years of my life; I'm chasing lots of other opportunities to keep learning, doing, connecting.

I hope you enjoyed reading this post. In my IndieHackers and DEV.to posts, I spammed this pitch for the app all throughout the article. In this more retrospective, chill blog post, I'll just leave it here at the end:

Whether it's to build in public, keep track of work for reports, or just to learn and reflect better, we could all benefit from logging our projects. SZ Project Tracker makes keeping dev logs or learning journals as easy as posting to Twitter 💨

📝 Write in markdown, drop images in
🌎 Make projects & updates public in just a click

▶▶▶ https://producthunt.com/posts/sz-project-tracker

From fearing React to Product Hunt webapp launch in 2 months!

## Introduction

Recently I’ve been working on [Morse](https://github.com/wwsalmon/morse-wp-theme), a WordPress theme custom-built for small newspapers, drawing on my experience building and then maintaining [*The Phillipian*](https://phillipian.net/)[’s website](https://phillipian.net/) for a year. I wanted this theme to be highly customizable, able to easily accomodate any paper’s branding and maybe even *The Phillipian*’s one day. A big part of this is allowing users to specify what fonts they want to be used.

![](/blog/2020-06/morse-two-fonts.jpg)

To start, it would just be Google Fonts. Good variety, hopefully easy to implement. The vision was that a user could go to the Customizer interface in WordPress, plug in a font name, and watch the preview update to use that font where applicable, then publish it and have their changes go live.

<video src="/blog/2020-06/morse-fonts-demo.mp4"></video>

Honestly, this was one of the features I was most intimidated by. I’ve worked a fair bit with WordPress and PHP, and with JavaScript, but never in combination. I looked through the source code of open-source plugins and themes that had already implemented Google Fonts integration and got lost in their endless includes and complexities, not even knowing where to find the code that mattered.

This morning, though, I managed to figure it out, implementing exactly what I wanted with way simpler code than expected! To solidify my own learning ([learn, build, share, repeat](https://twitter.com/patrick_oshag/status/971100425498841089?lang=en)) and to share this knowledge with anyone else who might want to implement the same functionality in their WordPress theme, I’ve created this post as a little tutorial of my solution.

## WP Customizer

First, let’s create fields in the customizer to allow users to specify fonts. For simplicity, I implemented these as straightforward string fields: users will have to browse through fonts beforehand and enter the exact name. Google Fonts does have an API for getting a list of all available fonts, and some WordPress plugins have implemented fancy lists

We’ll add three different fields: a body font, a heading font, and an accent font (for the occassional button, label, etc.; obviously you can make these options whatever you want). This is straightforward to implement:

```php
function morse_wp_plugin_customizer($wp_customize)
    {
        $wp_customize->add_section('morse-wp-custom-section', array(
            'title' => "Morse WP Theme Overall Settings"
        ));
        $wp_customize->add_setting('morse-wp-font-body');
        $wp_customize->add_control('morse-wp-font-body-control', array(
                'label' => 'Google Font for Body',
                'type' => 'string',
                'section' => 'morse-wp-custom-section',
                'settings' => 'morse-wp-font-body'
        ));
        $wp_customize->add_setting('morse-wp-font-heading');
        $wp_customize->add_control('morse-wp-font-heading-control', array(
                'label' => 'Google Font for Headings',
                'type' => 'string',
                'section' => 'morse-wp-custom-section',
                'settings' => 'morse-wp-font-heading'
        ));
        $wp_customize->add_setting('morse-wp-font-accent');
        $wp_customize->add_control('morse-wp-font-accent-control', array(
                'label' => 'Google Font for Accents',
                'type' => 'string',
                'section' => 'morse-wp-custom-section',
                'settings' => 'morse-wp-font-accent'
        ));
    }
    
    add_action('customize_register', 'morse_wp_plugin_customizer');
```
## Utility Classes

In a template PHP file, we can now access these customizer settings using `get_theme_mod()`, for example `get_theme_mod(``"``morse-wp-font-heading``"``, "Georgia")` to get the heading font, with a default of Georgia if the option has not been set by the user. Now, how do we get this into our CSS?

The trick here is to use utility classes instead of trying to write dynamic fonts into semantic CSS. Instead of specifying that `.article-title h1` should have our heading font, we specify a utility class `.morse-font-heading` that we can apply to any element we want our heading font on. Instead of trying to insert snippets into or overwrite various parts of a stylesheet, then, we can simply add our utility classes in an inline style block using the `wp_head` hook:

```php
function morse_wp_plugin_add_styles(){ ?>
    <style>
        .morse-font-body{
            font-family: <?php echo get_theme_mod("morse-wp-font-body", "Georgia"); ?>
        }
    
        .morse-font-heading{
            font-family: <?php echo get_theme_mod("morse-wp-font-heading", "Georgia"); ?>
        }
    
        .morse-font-accent{
            font-family: <?php echo get_theme_mod("morse-wp-font-accent", "sans-serif"); ?>
        }
    </style>
    <?php
}
add_action("wp_head", "morse_wp_plugin_add_styles");


```

Note: above is only a snippet of the `add_styles` function I actually use. The same approach can be applied to implementing user-specified colors, for example, which I might write about later.

## Web Font Loader

The last step, and the one that confused/intimidated me for a little bit, was how to actually load these fonts from Google Fonts. Google Fonts has a JavaScript Web Font Loader library/API that allows fonts to be dynamically loaded, but I’ve never connected WordPress functionality with JavaScript before. It’s something I’ll have learn eventually, especially with Gutenberg blocks being React-based. In this case, though, I was able to figure out a straightforward solution, based [on this tutorial](https://wordpresssupercharged.com/how-to-improve-page-speed-by-deferring-web-fonts/):

First, download the [Web Font Loader library](https://github.com/typekit/webfontloader/blob/master/webfontloader.js). Throw that JS file somewhere in your plugin or theme, and enqueue it like any other script.

Now, all we need to do is run `WebFont.load()` with our desired parameters to load in our fonts. [Web Font Loader’s GitHub](https://github.com/typekit/webfontloader) provides documentation on what these parameters look like, but here’s a quick example:

```js
WebFont.load({
    google: {
        families: ["Roboto:400,700", "Roboto Mono"]
    }
});
```

Pretty easy, right? WordPress allows us to easily insert inline scripts using `wp_add_inline_script`, which we can include right after we enqueue the Web Font Loader library. All we have left to do, then, is generate the parameters to call based on our Customizer settings. This just takes some simple PHP. First, I create an array of fonts with `array_unique([get_theme_mod("morse-wp-font-body"), get_theme_mod("morse-wp-font-heading"), get_theme_mod("morse-wp-font-accent")])` — `array_unique` making sure I don’t duplicate-request fonts — then turn this into the specific format that the loader wants with a for loop and some string concatenation. For now, I just specified 400 and 700 weights (regular and bold), though it’s only a matter of busiwork if you wanted to allow user-specified weights as well.

Here’s how it all comes together:

```php
function morse_wp_enqueue_fonts(){
    
            wp_enqueue_script( 'webfontloader', plugin_dir_url( __FILE__) . "../js/webfontloader.js", NULL, '', true );
    
            $fonts_array = array_unique([get_theme_mod("morse-wp-font-body"), get_theme_mod("morse-wp-font-heading"), get_theme_mod("morse-wp-font-accent")]);
            $fonts_string = "";
            foreach ($fonts_array as $f){
                    $fonts_string = $fonts_string . "\"" . $f . ":400,700\",";
            }
    
            $config_string = "
    WebFont.load({
      google: {
        families: [
        " . $fonts_string . "
        ]
      }
    });
            ";
    
            wp_add_inline_script( 'webfontloader', $config_string, 'after' );
    }
    add_action("wp_enqueue_scripts", "morse_wp_enqueue_fonts");
```

## And We’re Done!

And there we have it, an easy-to-implement, easy-to-extend solution for loading user-specified Google Fonts into your WordPress theme. There’s a lot more to look into — here are a few ideas:


- Dropdown list of potential fonts
- User-specified font weights
- User-uploaded custom fonts

But, honestly, I thought this feature was gonna be really hard to build, and it turned out to be surprisingly simple, and highly functional for its simplicity. No plugins, no jank hacks going against WordPress’ design, just a few straightforward lines of code.

Find the full source code for the [Morse theme](https://github.com/wwsalmon/morse-wp-theme) and [theme-specific plugin (where the code from this tutorial is located)](https://github.com/wwsalmon/morse-wp-plugin) on [my GitHub](https://github.com/wwsalmon), and let me know what you think of this solution through [Twitter (@wwsalmon)](https://twitter.com/wwsalmon) or in the comments of [the DEV.to post for this tutorial](https://dev.to/wwsalmon/how-to-support-user-selected-google-fonts-in-wordpress-themes-plugins-55f5)!

How to Support User-Selected Google Fonts in WordPress Themes & Plugins

I’ve been working through the [serverless-stack.com](https://serverless-stack.com/) tutorial. It’s awesome, teaching you how to set up an AWS backend, React front-end, and now is going through CI/CD through [Seed](https://seed.run/). Like most tutorials, it does feel like I’m just going through the process, not copy-pasting but reading and re-writing code without being too sure of what it all does and why I’m using it; really in-depth learning only comes with time and experience: building your own project from scratch, dealing with all the considerations, use cases, and bugs that come with that. The usage of Seed instead of CircleCI or TravisCI like I see on almost every repo is also a reminder of the dizzying amount of options out there. I had briefly made a foray into learning MongoDB and Express before this current serverless endeavor, and it seems to be something many recruiters want to see; and there are a million alternatives to the React frontend, from other JS frameworks like Angular and Vue to ditching this totally and just writing straight JS.

The Seed website seemed to use the same AWS and React Bootstrap components that the Serverless tutorial was teaching, so somehow I went into a slight rabbithole and ended up on the [website of Mark Otto](https://markdotto.com/projects/), the creator of Bootstrap, also the top designer at GitHub and Twitter before that (it suddenly made sense why GitHub uses Bootstrap). Scrolling through his projects, I saw a bunch of really cool resources and minisites. A [“code guide”](https://codeguide.co/) with HTML/CSS quality standards and conventions; a [concept for HTML elements](https://mdo.github.io/mdoml/) redesigned for more modern use cases; and “A [curated list](http://wtfhtmlcss.com/) of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas.”

Reading through these pages, I was struck by a sense of nostalgia. At the bottom of the HTML section of the Code Guide, just a two-sentence sidenote, was: “Writing markup in a JavaScript file makes the content harder to find, harder to edit, and less performant. Avoid it whenever possible.” The assertion “JS bad” seems to come up at every conference and on every blog. JS slow, JS inaccessible, JS bad for SEO, JS bad for mobile. And the counterargument — you’re ignoring the developer experience, JS frameworks make it 20x easier and faster to build a powerful web app, build and optimize from there. Ship ship ship. Done is better than perfect. But Mark Otto’s two line snippet didn’t seem to be referring to this, the mess of frameworks and CSS-in-JS and everything else that we’ve found ourselves in. It seems to be speaking of a simpler time, when JS meant scripts adding functionality to a website, not the backbone of the website itself. When being a front-end web developer meant writing nicely organized HTML and perfectly cascading CSS — almost the opposite of what I was invested so heavily in learning now.

To be sure, if you haven’t been able to tell yet, I don’t claim to be anything near a professional web developer. All this fancy JS stuff, backend stuff, most of really high-value web development skills today I’m just getting into. Even for static websites, I’ve never worked with huge codebases and design systems, tested across every browser and device and connection speed, squeezed out every byte and millisecond of loading time from a website. But I’ve read about these things obsessively, and when it comes out to just bashing out a website, I’m confident that I can do it well. At this point, CSS feels like a native language to me. Sure, maybe I don’t memorize all the ins and outs of the grammar, but I grew up with it and so know it comprehensively by experience: all the ways to say something, what “sounds” right and what works but “sounds” wrong, what is good or bad practice not by memorization but by experience. Often I feel faster and more creative designing by bashing out code than in Illustrator. Alternatively, give me a mockup and I can implement it with five completely different sets of CSS.

Recently, I came across something like the following in a friend’s project:

```
    body{
      display: flex;
      justify-content: center;
    }
    
    div{
      display: flex;
    }
    
    container{
      width: 1200px;
    }
```

What on earth? I asked him what his thinking was. “The program where I learned CSS said to use flexbox on everything,” he told me.

Just to center a top level container! Whatever happened to `margin: 0 auto`? Oh, man. Maybe I was just lagging behind the times — was this really best practice now? I remember when flexbox was the dreamlike new thing on the scene, the solution to all of our CSS alignment problems, the end of floats and clearfixes and *tables* (my friend will never know of these dark ages, I guess). Browser support was barely existent, and “[A Complete Guide to Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/)” had just been published on the CSS-Tricks frontpage. Sparingly, I began integrating it into my own projects. Today, it’s a crucial part of my toolkit, but one I chose to take out when needed, not anything like a default. Now we’ve got Grid, too. New CSS developers these days are spoiled.

And CSS frameworks! Bootstrap was heavy, I had always heard. Makes sense for huge web apps, but way overkill for my tiny little websites. And it was just cleaner and easier to get exactly what I wanted with my own from-scratch code. But now, what do we have? Developers aren’t even writing straight CSS anymore. Atomic frameworks like the currently hugely popular Tailwind CSS are the default. Instead of applying classes in HTML and carefully putting together a harmonious stylesheet, you just apply `w-16`, `h-16`, `mx-auto` classes to your markup, and bam — `width: 16px`, `height: 16px`, `margin: 0 auto`.

My gut reaction to this is, nononononono. I want to keep writing the CSS I know and love. It’s elegant, it’s beautiful, it’s my craft. CSS is almost a part of my identity at this point: my artistry, my outlet of creative expression, my value proposition as a part of society. These new frameworks, not to mention ideas like CSS-in-JS and pre-styled React component libraries, seem to be ripping CSS as I know it away from me, threatening to rip a chunk of my very being away from me. And I’m not alone in this — Chris Hawkes, for example, pretty much voices the same sentiment in his video “[Why I Don’t Like Tailwind CSS](https://www.youtube.com/watch?v=qECXE-retvk)” (though I disagree with him that SASS is similar — SASS is still cascading, is still CSS properties, is still what makes CSS CSS in my heart; I love it and use it extensively). 

Yet, resisting means risking straggling behind the unstopping forward-marching standard of “this is the way that things are done.” There are far more advocates than detractors for atomic frameworks. Hawke’s video has 205 dislikes to 241 likes, for example. And these frameworks don’t just throw away CSS — they are built upon the deepest understanding of and experience with it, not just in technical aspects but in core design philosophy. A comment by a Tailwind CSS community manager on Hawke’s video links to a few essays dating back all the way to 2012 diving into HTML and CSS semantics and scalability. They make a compelling argument of the inherent difficulty of writing and maintaining large CSS codebases by virtue of its cascading nature, the proposed solution being using utility classes. This is exactly the solution that utility-focused atomic frameworks provide.

These frameworks being thoroughly thought-out and considered, however, doesn't mean that their users are inheriting this CSS knowledge and understanding. The most common developer-perspective argument I’ve heard for using CSS frameworks is rooted in the “ship ship ship” rapid iteration mindset that seems to be the foundation of the software development and tech industries. Frameworks allow developers to stop worrying about carefully maintaining CSS and instead focus on building and improving their product. CSS, then, is no longer a language to learn by immersion, by painstaking honing of understanding and technique through time and experience, but rather an ugly back layer, a necessary evil, to hide away behind conveniently designed frameworks and component libraries. The understanding of CSS as a fundamental and artistic skill, like sketching with pencil on paper for painters and digital artists, necessary to learn first, learn well, and continuously practice, is dying, maybe dead.

Maybe this is overly drastic or simplistic. [W3C](https://www.w3.org/) certainly isn’t stopping their work tirelessly assessing and improving CSS. Web development is a huge field and industry; not every website is a JS-based webapp that can ditch CSS, and most jobs will still require direct hands-on CSS work. Using frameworks doesn’t allow you to forego CSS knowledge entirely, either. Utility classes correspond to CSS properties; understanding CSS patterns and behavior is crucial to using them well, as I was reminded of while [watching Tailwind CSS developer Adam Wathan](https://www.youtube.com/watch?v=7gX_ApBeSpQ) work through different combinations of flexbox and margin classes to get part of a Coinbase clone looking right. And if nothing else, developers specializing in CSS will be needed to maintain and build frameworks and libraries.

Yet, the state of and most useful skills in web development will continue to ever evolve, and the practice of artistic, intricate, unmaintainable CSS seems to be taking more and more of a backseat. The starkest difference might be in new developers. Sure, intro courses will still start with the basics of HTML and CSS; but moving into any sort of bigger project, frameworks will be much easier to use and in most ways much more effective than slowly mastering raw CSS with time. More developers will be like my friend, setting `display: flex` on everything, struggling with more complex layouts. And maybe that’s okay.

Maybe it’s even for the better. For me, leaving CSS behind is certainly a bigger step forward: moving beyond static web dev, towards JS, towards full-stack, to more powerful frameworks, to bigger and better things. In some ways, particularly with regards to CSS, my perspective is that of a teacher, someone who has been around and knows what I’m doing. Zooming out a bit, though, I’m still very much a student, early in my learning process. From this perspective, I have one last analogy to offer.

CSS is like arithmetic. It’s at the very base layer of the web, what browser engines process to spit out what’s on the screen. Here are the axioms that just *are*, by very definition of the system. CSS frameworks, then, are like algebra. The problems they solve are essentially arithmetic problems, but abstracted a layer. After a while, any arithmetic that you do only passes by in the back of your mind; you think instead in terms of variables, functions, and roots, like utility classes and components to CSS properties. Even higher level JS frameworks and CSS-in-JS, then, are like calculus, abstracting on algebra, providing a whole new pattern for how websites are defined and built. (SASS is like arithmetic tricks, like learning factoring or divisibility rules that provide you shortcuts without actually learning the algebra that makes them work.) As a student, then, maybe my bemoaning the death of CSS as an art is simply that of a student growing out of his comfort zone.

But CSS, in its beautiful, raw, sometimes badly-written form, will forever (probably…?) remain at the core of the web as we know it. Maybe the whole field is moving forward, abstracting on top of it, so new developers can make use of it faster and better; but I’m glad that I started learning web development before atomic frameworks blew up, before grid, before flexbox, when avoiding Javascript for front-end development was a valuable and feasible thing, when CSS was an art and a language I immersed myself in. Now I’m in time to move along with the field, my knowledge of what once was allowing me to especially appreciate what now is and what’s to come.[^ref]

[^ref]: This article was also published on [DEV.to](https://dev.to/wwsalmon/the-artistry-of-css-and-its-death-a-reflection-about-css-and-js-frameworks-and-the-evolution-of-css-1npg) and [IndieHackers](https://www.indiehackers.com/post/css-is-an-art-and-its-dying-a-reflection-on-css-and-js-frameworks-and-the-evolution-of-css-b9187b02f4), where there has been some good discussion!

CSS is an art, and it's dying. A reflection on CSS and JS frameworks and the evolution of CSS

![](/blog/2020-04/raise3.png)

What is recursion? Simply a function that calls itself. As an example, here’s a recursive algorithm for calculating factorials:

```js
function factorial(n) {
    if (n == 2) {
        return 2;
    }
    return n * factorial(n - 1);
}
```

This is a pretty trivial application; the same alg is easy enough to implement with a simple for loop. But for certain complex operations like merge sort, a recursive approach can be much easier and faster.

To be honest, I never thought I’d use recursion outside of my intro compsci class, at least not directly for my own algorithms. I’ve mainly done front-end development — the complexity of my JS functions rarely went beyond a for loop; if we’re fancy, then maybe some multidimensional arrays and manipulation of them. Recursion didn’t seem like something that was useful for functions that weren’t ridiculously complex or specific.

Recently I’ve been working a lot with d3.js, building a charting library for *The Phillipian*’s annual [State of the Academy project](http://pdf.phillipian.net/2019/05102019.pdf). It’s been an amazing project, learning and getting comfortable with d3.js and Javascript in general, as I’ve only used it tangentially in service of non-JS static content before; this project gives me a good starting point for getting more into JS with tools like React. But I digress. d3.js is relevant because using it requires so much more direct and creative programming. It gives you tons of power by aiding with manipulating data and corresponding elements, but you’re leaving behind the world of document flow and generally built-in layout functionality. Coordinates and dimensions are set directly, so you need to come up with your own algorithms for dealing with overlap and even alignment.

As such, the comfort I gained working with arrays on seemingly arbitrary problems has actually come in handy. One such thing, unexpectedly, was recursion! Let me explain.

Here’s the starting point. Nice simple stackedBarChart, and I was just starting to implement labels:


![](/blog/2020-04/startingpoint.png)


The code so far is straightforward. First, I create a polyline, for now with just two points, going from the center of each bar to a certain amount above it. Then, above each of these lines, I render the appropriate text label, and push the right bound of each text label to an array. These right bounds are used to calculate the third point of the polyline, ending right where the text does. (Not sure why it’s not working for “Both” in the example above whoops)

```js
chartGroups.selectAll(".sota-stackedBarChart-label-aboveBar-line")
    .data(d => d)
    .join("polyline")
    .attr("class", "sota-stackedBarChart-label-aboveBar-line")
    .attr("points", d => {
        let x1 = margin.left + x(d[1]) + x(d[0]) / 2;
        let y1 = barHeight / 2;
        let x2 = x1;
        let y2 = -labelBelow;
        return `${x1},${y1} ${x2},${y2}`;
    })
    .attr("stroke-width", separatorStrokeWidth)
    .attr("stroke", lineColor)
    .attr("fill", "none")

let labelRightBounds = [];

chartGroups.selectAll(".sota-stackedBarChart-label-aboveBar-text")
    .data(d => d)
    .join("text")
    .attr("class", "sota-stackedBarChart-label-aboveBar-text")
    .text((d, i) => `${valueLabels[i]}: ${d3.format(".1f")(d[0])}%`)
    .attr("x", d => margin.left + x(d[1]) + x(d[0]) / 2)
    .attr("y", function(d) {
        labelRightBounds.push(d[1] + this.getBBox().x + this.getBBox().width)
        return -2 * labelBelow;
    })
    .attr("alignment-baseline", "bottom")

chartGroups.selectAll(".sota-stackedBarChart-label-aboveBar-line")
    .data(d => d)
    .join("polyline")
    .attr("points", function(d, i) {
        let currentPoints = this.getAttribute("points");
        return currentPoints + ` ${labelRightBounds[i]},${-labelBelow}`;
    })
```

So, okay! Clearly the labels overlapping is a problem. A reference from previous print versions of the survey provide guidance on how to fix this:


![](/blog/2020-04/ref1.png)


Not the above/below thing — we’ll keep all the labels above for simplicity. But the “Yes, on campus” and “Yes, off campus” labels provide a perfect model for how to offset the labels so they don’t overlap: raise the height of the first overlapping label, and move the second overlapping label right until it no longer overlaps. Time to code it!


![](/blog/2020-04/raise1.png)


Whoops, that’s not right!


![](/blog/2020-04/raise2.png)


There we go.

This implementation came with a few notable changes from the previous code. I realized that only the text needed to be rendered to calculate the third point of the polyline, and to discover any overlaps, so instead of first creating a polyline with two points and adding the third later, I started by adding the text in their appropriate default spots.

This time, more than the right boundary of each text label is pushed to the `labelRightBounds` array, but rather an array of both its left boundary position and its width. This allows us to calculate overlap between labels, which I do in a straightforward for loop. Iterating from first to last, if the current element overlapped with the previous one, then I would raise the height of the previous one and extend the left position of the current element.

```js
let labelRightBounds = [];

chartGroups.selectAll(".sota-stackedBarChart-label-aboveBar-text")
    .data(d => d)
    .join("text")
    .attr("class", "sota-stackedBarChart-label-aboveBar-text")
    .text((d, i) => `${valueLabels[i]}: ${d3.format(".1f")(d[0])}%`)
    .attr("x", d => margin.left + x(d[1]) + x(d[0]) / 2)
    .attr("y", function(d) {
        labelRightBounds.push([this.getBBox().x, this.getBBox().width]);
        return -2 * labelBelow;
    })
    .attr("alignment-baseline", "bottom")

let labelHeights = []
let prevRightBound = -labelLeft;

for (let i in labelRightBounds) {
    if (labelRightBounds[i][0] < prevRightBound + labelLeft) {
        labelRightBounds[i][0] = prevRightBound + labelLeft;
        labelHeights[i - 1] -= 1;
        labelHeights.push(-2);
    } else {
        labelHeights.push(-2)
    }
    prevRightBound = labelRightBounds[i][0] + labelRightBounds[i][1]
}

chartGroups.selectAll(".sota-stackedBarChart-label-aboveBar-line")
    .data(d => d)
    .join("polyline")
    .attr("class", "sota-stackedBarChart-label-aboveBar-line")
    .attr("points", (d, i) => {
        let x1 = margin.left + x(d[1]) + x(d[0]) / 2;
        let y1 = barHeight / 2;
        let x2 = x1;
        let y2 = (labelHeights[i] + 1) * labelBelow;
        let x3 = labelRightBounds[i][0] + labelRightBounds[i][1];
        let y3 = y2;
        return `${x1},${y1} ${x2},${y2} ${x3},${y3}`;
    })
    .attr("stroke-width", separatorStrokeWidth)
    .attr("stroke", lineColor)
    .attr("fill", "none")

chartGroups.selectAll(".sota-stackedBarChart-label-aboveBar-text")
    .data(d => d)
    .join("text")
    .attr("x", (d, i) => labelRightBounds[i][0])
    .attr("y", (d, i) => labelHeights[i] * labelBelow);
}
```

Iterating from front to back is nice because previous right boundary shifts are accounted for; i.e. the shifting of a previous label might cause it to overlap with the next one, which will now have to move more. But thinking about this alg reveals that it doesn’t actually account for not just one, but multiple labels in a row overlapping, because if a label is found to be overlapping with a previous label, only the height of this immediately preceding label is raised. If this preceding label was overlapping with its preceding label, this precending label would not get raised another step, as it should if the second label were raised by the third.

To make the heights work, you’d have to iterate from last to first label, raising each one a successive step higher if necessary; but then you wouldn’t be able to account for rightward shifts causing overlap, which propagate from first to last label. To solve this problem we’d have to iterate both forwards and backwards.

One solution is to do just that — loop over everything twice: once first-to-last to apply rightward shifts, and again last-to-first to apply height shifts. But before I could get to that, a different idea took hold. **Recursion!**

Let’s take a look at the final implementation — just the recursive part replacing the for loop, as the rendering code didn’t really change.

```js
function getLabelHeight(i) {
    if (i == labelRightBounds.length - 1) {
        labelHeights[i] = -2;
        return -2;
    } else if (labelRightBounds[i][0] + labelRightBounds[i][1] + labelLeft > labelRightBounds[i + 1][0]) {
        labelRightBounds[i + 1][0] = labelRightBounds[i][0] + labelRightBounds[i][1] + labelLeft;
        let nextHeight = getLabelHeight(i + 1);
        let thisHeight = nextHeight - 1;
        labelHeights[i] = thisHeight;
        return thisHeight;
    } else {
        getLabelHeight(i + 1);
        labelHeights[i] = -2;
        return -2;
    }
}

getLabelHeight(0);
```

We still have our `labelHeights` and `labelRightBounds` arrays, the latter storing the left coordinate and width of each label. We define our recursive function function `getLabelHeight` with parameter `i`, the index of the current label in consideration.

Our first conditional checks for the base case: if the label in consideration is the last label. In this case, we set the corresponding `labelHeights` slot to the default height, and return it (or at least the coefficient of it; -2 in this case because the line is -1 units up, and the text -2. This coefficient increments by one from here on out).

If this isn’t the case, then the next label exists, and the current label either overlaps with it or not. If it doesn’t overlap, then easy, we set the corresponding `labelHeights` slot to the default value and return it. Before we do that, we call `labelHeights(i+1)` so the next labelHeight is calculated.

If it does overlap, or is closer than a specified margin, then we must raise the height of the current label. What do we raise the current label to? To one step higher than the height of the next label. But we don’t know the height of the next label, do we? Let’s find it, by calling the very function `getLabelHeight` on it, passing in `i+1` as the parameter; then we can set the return value of the function as the corresponding `labelHeights`  slot, and return this value for the preceding function call. In the case that the next label is raised because it overlaps with the label after that, it will return a raised height, and the height of the current label will be raised to the appropriate height above that. This applies for however many overlapping labels you have; they might clip out of the SVG Canvas, but the heights will cascade all the way from either the first non-overlapping label or the last one back, forming a nice staircase of heights.

Sounds good. Does it actually work?


![](/blog/2020-04/raise2.png)


Okay, nothing changed, but that was what was supposed to happen. That means that the function works for a two-overlap scenario. Let’s shrink down our window to see the cascade in action:


![](/blog/2020-04/raise3.png)


Hell yeah, there we go!

The recursive function ended up being 16 lines of code, compared to the single loop’s 9; implementing the second backwards loop for the same functionality as the recursive function probably would have at least doubled the line count, so the recursive function is certainly nicer to write, and arguably understand, than a double loop. Is it faster to run? I have no idea. In effect it’s looping over the data the same way: once forward, each function call calling the function on the next label before it returns, up until the last label; and then once backward, each function return propagating to the previous function call for the last operations before turning to the next previous call, all the way up to the first call which returns the value to nothing.

None of this was particularly mind-blowing, but it brought me a lot of joy to use what I had learned forever ago in a classroom on a real project, a neat trick that solved a real, somewhat tricky problem.

Tag: #code