DEV Community: Spencer Lepine

Demystifying Bash and Zsh on Mac

Spencer Lepine — Mon, 14 Oct 2024 10:08:43 +0000

If you’re a mac-based developer like me, and you never quite understood the difference between Bash and Zsh, this article is for you. In my experience, configuring the shell and $PATH has always been a confusing and fragile task.

Let’s demystify the shell and define best practices for configuring your local machine.

TL;DR - Zsh and Bash or both unix shells, Zsh is a beefed up version. macOS defaults to Zsh, linux defaults to Bash. For a local machine, configure Zsh. For scripting and deployments, use Bash (cross-platform).

History

Bash is the original unix shell that has been around since 1989. It’s deeply embedded into both Linux and macOS systems. Apple began moving towards Zsh (pronounced “Zee Shell”) due to licensing changes. Zsh is an extended and improved version of Bash. Eventually, in the release of macOS Catalina in 2019, Zsh became the default shell for macOS.

Linux default shell: Bash
macOS default shell: Zsh

Terminal: Which to Use?

It’s recommended to stick with Zsh as your default shell for local development. It includes more modern features and better community support.

You’ll want to configure both your terminal shell and code editor default shell. To find out what your currently using, open the terminal and run the following command:

$ echo $SHELL
/bin/zsh

Scripting: Which to Use?

It’s recommended to use Bash for scripting and deployment. This is best for compatibility and cross-platform usage, as most Linux systems still use Bash.

No configuration is needed, you’ll just add a simple shebang to the top of your script. Here’s an example hello.sh

#!/bin/bash

# This is a comment. It won't be executed.

# Define a function
greet() {
    echo "Hello, World!"
}

# Call the function
greet

# make the script executable
chmod +x hello.sh

# run the script
./hello.sh

One-time Laptop Setup

Ensure your local machine has the proper Zsh setup by reviewing the following steps.

It’s highly recommend to install Homebrew as well, which helps you avoid manually configuring the $PATH for tools/languages (e.g. JavaScript, Python, Java).

Open your terminal and set your default shell to Zsh

chsh -s $(which zsh)

2.Create the .zshrc config file

nano ~/.zshrc

# ~/.zshrc

# Enable color support
autoload -Uz compinit
compinit

# Set prompt
PROMPT='%F{cyan}%n@%m %F{green}%~ %F{yellow}%% %f'

# Enable command completion
setopt complete_in_word
setopt auto_cd
setopt correct

# Set History Options
HISTSIZE=10000
SAVEHIST=10000
setopt append_history
setopt share_history

Install Homebrew (macOS package manager)

/bin/bash -c "$(curl -fsSL [https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh](https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh))"

cat ~/.zshrc
# verify homebrew added the $PATH variable

# ~/.zshrc

# ...

# Homebrew Path
# export PATH="/usr/local/bin:$PATH" # For Intel Macs (legacy)
export PATH="/opt/homebrew/bin:$PATH"  # For Apple Silicon Macs

Verify Homebrew and Zsh are configured

$ source ~/.zshrc
$ echo $SHELL
/bin/zsh
$ brew --version
Homebrew 4.3.17
$ echo $PATH
/opt/homebrew/bin:...

Set the default shell for your code editor

For example, if you’re using Visual Studio Code:

Open Visual Studio Code
Open the search tool (hit Cmd + Shift + P )
Search “Open User Settings (JSON)”, hit enter
Ensure the Zsh shell is set:

"terminal.integrated.defaultProfile.osx": "zsh"

Migrating to a New Laptop

If you want to mirror an existing Zsh configuration to a new mac, it’s pretty straight-forward.

[old laptop] Export/save your existing .zshrc config

# ~/.zshrc
# Misc
export EDITOR=vim
export PATH=$HOME/bin:/usr/local/bin:$PATH

# Enable color support
autoload -Uz compinit
compinit

# Set prompt
PROMPT='%F{cyan}%n@%m %F{green}%~ %F{yellow}%% %f'

# Enable command completion
setopt complete_in_word
setopt auto_cd
setopt correct

# Set History Options
HISTSIZE=10000
SAVEHIST=10000
setopt append_history
setopt share_history

# Homebrew Path
# export PATH="/usr/local/bin:$PATH" # For Intel Macs (legacy)
export PATH="/opt/homebrew/bin:$PATH"  # For Apple Silicon Macs

# Node.js
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion
nvm use v20
# Node.js end

# pnpm
export PNPM_HOME="/Users/notspencer/Library/pnpm"
case ":$PATH:" in
  *":$PNPM_HOME:"*) ;;
  *) export PATH="$PNPM_HOME:$PATH" ;;
esac
# pnpm end

# oh-my-zsh
export ZSH="/Users/notspencer/.oh-my-zsh"
ZSH_THEME="robbyrussell"
plugins=(git)
source $ZSH/oh-my-zsh.sh
# oh-my-zsh end

# pyenv
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
if command -v pyenv 1>/dev/null 2>&1; then
  eval "$(pyenv init --path)"
  eval "$(pyenv init -)"
fi

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
# pyenv end

[old laptop] Generate a list of your existing Homebrew packages

$ brew list
==> Formulae
wget python

[new laptop] Configure Zsh on your new machine

# Set your default shell to Zsh
chsh -s $(which zsh)

# copy paste your existing .zshrc config
nano ~/.zshrc

# apply the config, look for any errors or missing installs
source ~/.zshrc

[new laptop] Install any missing tools/languages as needed.

# install homebrew
/bin/bash -c "$(curl -fsSL [https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh](https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh))"

# install packages
brew install wget python

What is PATH?

You may have noticed your Zsh config using $PATH, but what is it exactly?

Whenever you install various tools on your local machine like homebrew, executable files are downloaded in /bin directories (short for binary). PATH is an environment variable for your operating system to find these executable files. It’s a list of directories, separated by colon ( : ), including the default /usr/local/bin.

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:<HOMEBREW_PATH>:<CUSTOM_PATH>

While most of the time, you only need to set it up once, it’s possible you’ll need to append another path if a software/tool comes with an executable in a custom directory.

Conclusion

As a developer, it’s not required to be an expert on Zsh and Bash, but it’s useful to have context on where and why we use them. This article has covered the use-cases for each shell, as well as steps to configure your local machine. By following the best practices, we can avoid breaking our existing configuration, and use the blueprint to quickly set up a new machine.

GET, POST, PUT & DELETE with Next.js App Router

Spencer Lepine — Sat, 31 Aug 2024 11:16:25 +0000

This article presents boilerplate code for API routes using Next.js App Router (docs), for a todo-list CRUD (Create, Read, Update, Delete) application. The App Router supports both client-side and server-side rendering, allowing for complex routing and dynamic site content.

Getting Started

Prerequisites:

NodeJS >= v18

Find the example code on GitHub: https://github.com/spencerlepine/nextjs-app-router-todo

Alternatively, you can clone and bootstrap a Next.js project directly with this command:

npx create-next-app@latest --example nextjs-app-router "https://github.com/spencerlepine/nextjs-app-router-todo"

Endpoints

We’ll implement the following endpoints:

GET /users/:userId/todos
POST /users/:userId/todos
PUT /users/:userId/todos/:itemId
DELETE /users/:userId/todos/:itemId

GET

// Next.js v14 App Router
// GET /users/:userId/todos
// app/api/users/[userId]/todos/route.ts
import { NextRequest, NextResponse } from "next/server"; // v14.x.x
import { todoItemDb } from "@/lib/db";

type TodoItem = {
  id: string;
  title: string;
  completed: boolean;
};

export const GET = async (
  req: NextRequest,
  { params, query }: { params: { userId: string }; query: {} }
) => {
  try {
    const { userId } = params;
    // const { limit, page } = query; // optional

    // Query the database
    const todoItems: TodoItem[] = await todoItemDb.getAll(userId);

    return NextResponse.json({ todoItems: todoItems }, { status: 200 });
  } catch (error) {
    console.error("Error processing request:", error);
    return NextResponse.json(
      { error: "Internal server error" },
      { status: 500 }
    );
  }
};

POST

// Next.js v14 App Router
// POST /users/:userId/todos
// app/api/users/[userId]/todos/route.ts
import { NextRequest, NextResponse } from "next/server"; // v14.x.x
import { todoItemDb } from "@/lib/db";

type TodoItem = {
  id: string;
  title: string;
  completed: boolean;
};

export const POST = async (
  req: NextRequest,
  { params }: { params: { userId: string } }
) => {
  try {
    const { userId } = params;
    const { title } = await req.json(); // request body

    if (!title) {
      return NextResponse.json(
        { error: "Invalid request body" },
        { status: 400 }
      );
    }

    // Handle your business logic here (e.g., update the database)
    const newTodoItem = await todoItemDb.createOne(userId, title);

    return NextResponse.json(newTodoItem, { status: 201 });
  } catch (error) {
    console.error("Error processing request:", error);
    return NextResponse.json(
      { error: "Internal server error" },
      { status: 500 }
    );
  }
};

PUT

// Next.js v14 App Router
// PUT /users/:userId/todos/:itemId
// app/api/users/[userId]/todos/[itemId]/route.ts
import { NextRequest, NextResponse } from "next/server"; // v14.x.x
import { todoItemDb } from "@/lib/db";

type TodoItem = {
  id: string;
  title: string;
  completed: boolean;
};

export const PUT = async (
  req: NextRequest,
  { params }: { params: { userId: string; itemId: string } }
) => {
  try {
    const { userId, itemId } = params;
    const todoItem = await req.json(); // request body

    if (!todoItem || typeof todoItem !== "object") {
      return NextResponse.json(
        { error: "Invalid request body" },
        { status: 400 }
      );
    }

    // Handle your business logic here (e.g., update the database)
    await todoItemDb.updateOne(userId, itemId, todoItem);

    return NextResponse.json({ success: true }, { status: 200 });
  } catch (error) {
    console.error("Error processing request:", error);
    return NextResponse.json(
      { error: "Internal server error" },
      { status: 500 }
    );
  }
};

DELETE

// Next.js v14 App Router
// DELETE /users/:userId/todos/:itemId
// app/api/users/[userId]/todos/[itemId]/route.ts
import { NextRequest, NextResponse } from "next/server"; // v14.x.x
import { todoItemDb } from "@/lib/db";

export const DELETE = async (
  req: NextRequest,
  { params }: { params: { userId: string; itemId: string } }
) => {
  try {
    const { userId, itemId } = params;

    await todoItemDb.deleteOne(userId, itemId);

    return NextResponse.json(
      { message: "Todo item deleted successfully" },
      { status: 200 }
    );
  } catch (error) {
    console.error("Error processing request:", error);
    return NextResponse.json(
      { error: "Internal server error" },
      { status: 500 }
    );
  }
};

Data Fetching & Rendering

Now with the endpoints built, we're able to make requests to our backend. App Router will use server-side rendering by default.

Client-side Rendering

If you have dynamic content or additional API requests from the frontend, add "use client"; to pages (or components) and use fetch or axios .

// Client-side rendering (CSR) - Next.js v14 App Router
// src/app/page.tsx

"use client";

export default async function HomePage() {
  const apiUrl =
    process.env.NEXT_PUBLIC_API_URL || "<http://localhost:3000/api>";
  const data = await fetch(`${apiUrl}/v1/user/mockUser123/todos`);
  const allTodoItems = await data.json();
  return (
    <ul>
      {allTodoItems.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

Static Server-side Rendering

For static pages, use the default Next.js server-side rendering. This will be generated at build-time.

// Server-side rendering (SSR) - Next.js v14 App Router
// src/app/page.tsx

import { db, todoItems } from "../../lib/db";

export default async function HomePage() {
  const allTodoItems = await db.select().from(todoItems);
  return (
    <ul>
      {allTodoItems.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

Dynamic Server-side Rendering

To dynamically render pages (or components) at request time, set and export the dynamic configuration option.

// Server-side rendering (SSR) - Next.js v14 App Router
// src/app/page.tsx

import { db, todoItems } from "../../lib/db";

// Render page request time
export const dynamic = "force-dynamic";

export default async function HomePage() {
  const allTodoItems = await db.select().from(todoItems);
  return (
    <ul>
      {allTodoItems.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

Authentication

To secure page routes and endpoints in your application, consider using NextAuth.js (repository). You can either create your own custom login system and database or integrate with popular auth providers like Auth0 or Google.

Conclusion

In this guide we covered the basic endpoints for CRUD (Create, Read, Update, Delete) API routes, along with data fetching for the frontend. This will be the bread and butter for most applications. To started today, find the example code over on GitHub: https://github.com/spencerlepine/nextjs-app-router-todo

Thanks for reading. If you found the article useful don’t forget to clap. If you have any questions, feel free to reach out to me. Connect with me and follow my journey on 👉 👉 LinkedIn, GitHub

Building Llama as a Service (LaaS)

Spencer Lepine — Mon, 08 Apr 2024 20:56:22 +0000

This is a walkthrough of the development process and system design engineering for the Llama as a Service. LaaS is a website and public API that can serve random Llama images. It will respond with a single image URL, or even a list.

Visit the LaaS website for a demo
View the source code on GitHub
View the walkthrough YouTube video

What I Learned

For this project, there is a frontend built with React hosted on Netlify, connected to the backend.

I built each API with Node.js, Express, and Docker. Services connected to a NoSQL MongoDB database.

Each service is in an independent repository to maintain separation of concerns. It would have been possible to build this in a monorepo, but it was good practice.

Each repository uses GitHub Actions to build, and test the code on every push. Express API was deployed to Heroku when the main branch was pushed.

With each app containerized with Docker, this allows it to be run on any other developer's machine also running Docker. Although I had automated deployments to Heroku without this, I decided to upload each service to a container registry.

Each repository also used a GitHub Actions workflow to automatically tag and version updates and releases. It would then build and publish the most up to date Docker image, and release it to the GitHub Container Registry.

For future use, this makes it crazy easy to deploy a Kubernetes cluster to the cloud, with a simple docker pull ghcr.io/OWNER/IMAGE_NAME command. However, that was beyond the scope of this project because of zero budget.

To manage the environment variables, I was able to share Secrets to the GitHub Action workflows, which are encrypted, and can be shared across an entire organization (meaning multiple repos could access the variables). This allowed me to deploy my code securely to Heroku, without ever hard-coding the API keys.

Another tool I used was Artillery for load testing on my local machine.

Instead of npm, I tried using yarn for the package manager, and it was WAY faster in GitHub Actions even without caching enabled.

Although they did not make it into production, I experimented with the RabbitMQ message broker, Python (Django, Flask), Kubernetes + minikube, JWT, and NGINX. This was a hobby project, but I intended to learn about microservices along the way.

Demonstration

Here is a screen shot of the LaaS website.

If you would like to try out the API, simply made a GET request to the following endpoint:

https://llama-as-a-service-images.herokuapp.com/random

Creating an API

First, I started with a simple API built with Node.js and Express, containerized with Docker. I set up GitHub Actions for CI to build and test it on each push. This will later connect to the database, to respond with image URLs.

Although this API doesn’t NEED to scale to millions of users, it was a valuable exercise for building and scaling a system. I aimed for a minimum latency of 300ms with 200 RPS.

Image Database

With an API ready to connect to the database, it was time to choose between a NoSQL or SQL database.

The answer is obvious for this use case. Let’s walk through the data we have, and the use cases.

We are going to store one single table with image URLs. This could easily be done in either database, but there is one key factor. We need a way to randomly pull a list of images from the database.

A SQL database makes it simple to query a random row, however, this is not horizontally scalable, and with a large data set, we are replicating the ENTIRE database to each new node.

On the other hand, NoSQL databases are horizontally scalable; which leads me to Cassandra, but unfortunately it is very difficult to pull random selections from this type of NoSQL database.

Finally, I settled with MongoDB, which has a built-in $sample method to pull from the records.

Once I got the MongoDB database running locally with Docker, I created a quick script to seed the database.

Now it’s time to connect the API to the database.

Connecting API to the Database

Next, I used the mongoose Node.js API to connect to the local MongoDB.

I created two endpoints; one to upload an image URL, and another to retrieve a random list of images.

Endpoint Load Testing

To experiment with scaling the API, I wanted to do load testing. Keep in mind that this API does not have much logic, meaning caching, or optimizing the code's performance, will have a huge impact.

I found a tool for load testing called Artillery. Following this guide I installed Artillery and began research for the test configuration.

The API currently has the /random endpoint to return an image URL (a string), with very little computation. Let’s stress test this to see the current traffic limit.

The random list endpoint is what we need to optimize. For the starting algorithm though, I seeded 100 image records into the database, and then pulled the ENTIRE list from the database each request. The API would then choose 25 random elements to return. Let’s benchmark how this performs with load testing.

With the first run, API, the limit on the /random?count=25 endpoint was 225 RPS over 15 seconds, with 99% of the response times were under 300ms. We can improve this.

Optimizing the Endpoint

We have many records of image URLs in the database. Somehow, we need to efficiently transform these into a list, pulling random selections from the database.

Let’s optimize the query for pulling documents from the database. Using a special mongodb query, we can drastically reduce the computational load for a single request. Running locally in postman, random?count=25 endpoint went from ~150ms for a single request, to <50ms.

This is the only code we need for this endpoint, compared to the previous 20 lines and O(n^2) space.

With the new query, the endpoint maintains 99% sub-300ms response time with a max of 440 RPS over 15 seconds.

Horizontally Scaling the API

With the containerized Node.js/Express API, I could run multiple containers, scaling to handle more traffic. Using a tool called minikube, we can easily spin up a local Kubernetes cluster to horizontally scale Docker containers. It was possible to keep one shared instance of the database, and many APIs were routed with an internal Kubernetes load balancer.

Horizontally scaling the API to two instances, the random endpoint maintains 99% sub-300ms response time with a max of 650 RPS over 15 seconds. Three API Instances => 99% sub-300ms response time with a max of 1000 RPS over 15 seconds. Five API Instances => 99% sub-300ms response time with a max of 1200 RPS over 15 seconds.

In practice, five instances were the limit of scaling the API horizontally. Even with more instances, the traffic was never sub 300ms response time. Note, this is dependent on the hardware of my local machine, and not accounting for cross-network latency in the real world.

With scaling, we can achieve higher throughput, allowing more traffic to flow, and resiliency, where a failed node can simply be replaced.

Since the image responses are intended to be random, we cannot cache the responses. It would be possible to scale the database with a slave/master system, but without a large data set, it is not worth the time to test. The bottleneck is most likely the API and connections to the database, versus MongoDB not handling read requests. It may be possible to improve the read times with a REDIS database, using in-memory caching, but that is overkill for this project.

Setting up Authentication

After playing around with load testing, I wanted to explore JSON Web Tokens and build an API to handle authentication.

This auth API will generate tokens, which will be sent back to the client as headers. The tokens headers are stored client-side (e.g. cookies, local storage), and sent to the backend each request.

If we expand the backend, we could include the authentication logic in each microservice.

Not practical. Instead, we can decouple the logic into its own service as shown below:

Creating a Gateway API

Instead of exposing the users directly to each microservice, we should route ALL traffic from the clients to the Gateway API. For this, I chose the same tech stack of Node.js/Express. Using a library, I was able to set up a proxy to the other services. In the future, this could be very useful to standardize requests to the backend, track usage, forward data to a logging microservice, talk to a message broker, and more.

Environment Variables and Configuration

Most of the system built, I needed to simplify the process for configuring the Docker containers locally, and how environment variables would be shared to each. Keep in mind, each service needed to access these in GitHub Actions as well, during deployment.

I used the docker-compose files to easily spin up the containers locally. I used default values for the environment variables for local development, and kept the config files separated so it was easy to follow.

This step was just a process of carefully writing the Docker and docker-compose files, and setting up GitHub Actions Secrets. The code could not run without having all env variables, could be hard to debug locally or lead to ambiguity for other developers.

A Simple Frontend

I would talk about building the frontend, but it is just a single page React app I built quickly. It does use a CSS library called Bulma, which is similar to tailwind and worth checking out. I did spend a day implementing a login/signup page, but this was just for the learning experience, and not what I wanted in the final product.

GitHub Actions Testing and Deployment

With most of the code written, it was time to deploy the app. This was actually a bumpy road because I was not sure how to approach this. I was keeping each component in its own repository on my personal GitHub Account, which was getting hard to keep track of.

My solution was to create the Llama as a Service GitHub Organization, which also allowed me to store organization-wide secrets that any repository could access.

Using GitHub Actions, I created workflows to build and test code on every push, and deploy to main branch Heroku (and Netlify for the frontend).

I also created a workflow to tag and version every update, and release the Docker image to the GitHub Container Registry. These packages could be private to the organization, or public. I did not end up using these published containers, but it was really dope to see everything automated.

Deploying to Production

So after deploying the gateway API, frontend, and backend, I hoped all the services would be connected in production. For some reason the http-proxy-middleware was causing problems, and it was not worth redesigning the whole system. I was not ready to work with deploying a Kubernetes Cluster, so I did not use the GHCR Docker packages for deploying.

Instead, I just stripped away the extra services that I had been working on, and stuck with a simple system to deploy. For the final product, there is the frontend deployed on Netlify, which connects to the API on Heroku, with talks to the MongoDB Atlas database (in the cloud).

View the Source Code

If you wish to view all of the source code for this project, you can look through each repository here:

GitHub Organization: github.com/llama-as-a-service
All the GHCR Packages: github.com/orgs/llama-as-a-service/packages
Frontend - github.com/llama-as-a-service/frontend
Images API - github.com/llama-as-a-service/images-service
Authentication API - github.com/llama-as-a-service/auth-service
Gateway API - github.com/llama-as-a-service/gateway-service

If you want to have a repository with Node.js, Express, and Docker set up with GitHub Actions, check out the boilerplate repository here

If you are interested in more projects by me, you can check out the ManyShiba Twitter bot, or more on my website.

Follow my journey or connect with me here:

Creating Custom Git Commands

Spencer Lepine — Mon, 08 Apr 2024 20:56:19 +0000

Every time I clone a repository from GitHub, I always run the same set of commands. This is prone to typos and simply inconvenient. There is a simple solution of combining each step into a single command that automatically runs everything for us.

In this example, I need to clone a GitHub repository, move into the new directory, and then open the project in VSCode.

Instead of multiple commands:

  git clone https://github.com/spencerlepine/readme-crawler
  cd readme-crawler
  code .

It would great to run one command:

    clone https://github.com/spencerlepine/readme-crawler

To achieve this, we can create a script in the


 directory. Make sure this path matches up with your configuration for the terminal (e.g.

 ```PATH=$PATH:$HOME/bin```

).

Let’s create a custom script to combine the git commands.



```sh
  #!/bin/bash

  ((!$#)) && echo missing git URL argument! && exit 1

  git clone $1
  basename=$(basename $1)
  reponame=${basename%.*}
  cd $reponame
  npm install
  code .

Use this script or create your own, and follow these steps to set up the custom command:

Navigate to usr/local/bin ->

cd ~/../../usr/local/bin
Run

vim clone
- Paste the script
Save the file:
- *press ‘ESC’
- *press ‘SHIFT’ + ‘:’
- *type ‘wq’ + ENTER
Create an executable

chmod +x clone
Run the command!

clone https://github.com/spencerlepine/manyshiba-bot.git

Viola! This script will accept one command line argument of the destination repo URL. It will automatically open the new project in VSCode in one command.

Follow my journey or connect with me here:

Git Project Configuration With Husky and ESLint

Spencer Lepine — Mon, 08 Apr 2024 20:56:16 +0000

Working on a project with Git and GitHub is relatively simple. When a project starts to grow however, it is crucial to write clean code that other developers can read. Follow this article to learn how to set up linting and pre-commit hooks for your repository.

Let’s walk through the steps for a one-time setup to configure husky pre-commit and pre-push hooks, ESLint with code styles conventions, prettier code formatter, and lint-staged. Husky automatically runs a script on each commit or push. This is useful for linting files to enforce code styles that keeps the entire code base following conventions.

Walkthrough

Install the dependencies:

npm install husky@4.3.8 lint-staged@10.5.4 prettier@2.8.8 --save-dev

yarn add husky@4.3.8 lint-staged@10.5.4 prettier@2.8.8 --dev

Package.json Updates

Add the following to your package.json to configure all three packages:

{
  "name": "@spencer/example-package",
  // ...
  "scripts": {
    "format": "prettier --write ."
  },
  "prettier": {
    "printWidth": 180,
    "tabWidth": 2,
    "singleQuote": true,
    "semi": true,
    "trailingComma": "es5",
    "bracketSpacing": true,
    "arrowParens": "avoid",
    "proseWrap": "always",
    "requirePragma": false,
    "insertPragma": false,
    "endOfLine": "lf",
    "jsxBracketSameLine": true
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "**/*.(js|jsx|ts|tsx|json|css|md)": [
      "prettier --write"
    ]
  }
}

Configure ESLint (optional)

First, install this package

npm install eslint-config-prettier

Then, run npm init @eslint/config to create a config file and choose preferred code styles.

Alternatively, use this example file. In the root directory, create .eslintrc:

{
  "extends": [
    "eslint:recommended"
  ],
  "plugins": [
    "prettier"
  ],
   "parserOptions": {
    "ecmaVersion": 2017
  },
  "env": {
    "es6": true
  },
  "rules": {
    "no-console": "off",
    "no-unused-vars": "off",
    "react/prop-types": "off",
    "quotes": [
      2,
      "double",
      {
        "avoidEscape": true
      }
    ]
  }
}

Everything in action

After making changes, commit the files, and see lint-staged automatically run, triggered by the pre-commit hook.

my-project$ git commit -m 'example commit message'
✔ Preparing lint-staged...
✔ Running tasks for staged files...
✔ Applying modifications from tasks...
✔ Cleaning up temporary files...
[example-branch 4bc4030] add new husky setup
 4 files changed, 59 insertions(+), 44 deletions(-)

All files have been linted and automatically fixed with prettier, or denied if too many errors were thrown. Now we can push the "clean" code.

my-project$ git push origin example-branch
# npx lint-staged
# ... (no errors found)
# npm test
# ... (PASS)
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 375 bytes | 375.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://github.com/spencerlepine/my-project.git
   4bc4030..b558038  example-branch -> example-branch

Boilerplate

See a working example here: GitHub repository.

Notes

A useful trick is the -–no-verify flag to SKIP the pre-commit or pre-push hook.
Use this option to skip the husky script in case you force a commit/push.

my-project$ git push origin my-branch --no-verify
# husky will not run "npm test"
... pushing to GitHub

When husky released v7, it had some major changes to the configuration. There are many articles and Stack Overflow answers about husky, but some of them are misleading if they were using v4.

Hope this article helped! Interested in more, check out more articles here.

Follow my journey or connect with me here:

ManyShiba - The World's Greatest Twitter Bot

Spencer Lepine — Mon, 08 Apr 2024 20:56:14 +0000

ManyShiba is the greatest Twitter bot ever created. Bless your soul with a daily photo of the almighty Shiba. Be uplifted by the spirit of this holy and sacred creature to free your soul.

For so long, I felt that something was missing in my life. After being blessed by the presence of a divine Shiba Inu dog, I had my answer. I could cleanse my soul each day by reminding myself of this divine being. But that couldn’t be it, there had to be some way I could bless EVERYONE.

Behold - your new favorite Twitter bot - @ManyShiba. (source code: GitHub)

So what exactly is the ManyShiba Bot?

This is a simple Node.js app connected to the Twitter API. The app is deployed on Heroku and connected to the Twitter developer account.

Each time the script runs, a new dog image will be fetched from the Shibe.online API. That image will then be uploaded and posted on the Twitter feed.

Technologies:

To build this app, there were three technologies I worked with.

Node is a popular Javascript runtime environment that can easily run on Heroku. Heroku is a PaaS and great tool to deploy a small app for free.

The Shibe.online API is a third party service to retrieve a link for dog pictures. Since there are many random photos to use in that database, it is the perfect resource for finding many new photos.

Finally, the twit library is a Twitter API Client for Node that simplifies the REST requests. Since this app will only be posting tweets, there are on advanced requests being made to the Twitter API.

With each of these tools, we can have a functioning Twitter bot. Here are the steps for code:

Save the Twitter API configuration
Initialize the Twit Client with the configuration
Fetch a random image from Shibe.online
Convert the image from a URL to base64
Tweet the image

After registering a Twitter App, make sure to enable Read/Write permissions in the App settings. Create an .env file in the root of the project based on .env.example. We can use this data in our file with an object like this:

const config = {
  consumer_key: process.env.TWITTER_API_KEY,
  consumer_secret: process.env.TWITTER_API_SECRET,
  access_token: process.env.TWITTER_API_ACCESS_TOKEN,
  access_token_secret: process.env.TWITTER_API_ACCESS_TOKEN_SECRET,
}

In app.js we can import twit and pass along the config obj:

import twit from 'twit';
...
const twitterClient = new twit(config);

Before we tweet anything, we first need to generate the content to post. This is where we will retrieve an image from the Shibe.online API. Note, the Shibe endpoint will return a list of image URLs stored on a third party server. We must download this image, because posting an image URL does not actually display it on the feed.

const API_ENDPOINT = 'http://shibe.online/api/shibes?count=1&urls=true&httpsUrls=false';
...
const fetchRandomImage = async (tweetFunction) => {
  const resultList = await fetch(API_ENDPOINT).then(res => res.json());
  const newImage = resultList[0];
  return newImage
}

After retrieving a URL from Shibe.online, we must fetch the image as well. We can convert the data from the image URL and convert it to a base64 string in memory. Since we are saving the image data, a Tweet will always load the image since it does not depend on the third party image database anymore.

Note, you can use any library for HTTP requests like axios. This example uses the http and node-fetch libraries available on npm.

import fetch from 'node-fetch';
import http from 'http';
...
const urlToBase64 = async (imgUrl, tweetFunction) => {
  await http.get(imgUrl, async (httpRes) => {
    httpRes.setEncoding('base64');
    // Exclude -> "data:" + httpRes.headers["content-type"] + ";base64,";
    let body = "";
    await httpRes.on('data', (data) => {
      body += data;
    });
    await httpRes.on('end', () => {
      tweetFunction(body);
    });
  }).on('error', (e) => {
    console.log(`Got error: ${e.message}`);
  });
}

const fetchRandomImage = async (tweetFunction) => {
  ...
  await urlToBase64(newImage, tweetFunction);
}

With a base64 string, we need to upload it as media context to Twitter. After uploading it, we have access to a media_id. This media_id can be attached to the actual Tweet, which will cause the image to render on the feed. For this project, there is no text context attached to this Tweet.

...
const tweetImage = (tweetContent) => {
  if (tweetContent) {
    twitterClient.post('media/upload', { media_data: tweetContent }, function (err, data, response) {
      // now we can assign alt text to the media, for use by screen readers and
      // other text-based presentations and interpreters
      var mediaIdStr = data.media_id_string
      var altText = "Shiba Inu"
      var meta_params = { media_id: mediaIdStr, alt_text: { text: altText } }

      twitterClient.post('media/metadata/create', meta_params, function (err, data, response) {
        if (!err) {
          // now we can reference the media and post a tweet (media will attach to the tweet)
          var params = { status: '', media_ids: [mediaIdStr] }

          twitterClient.post('statuses/update', params, function (err, data, response) {
            console.log(data)
          })
        }
      })
    })
  }
}

fetchRandomImage(tweetImage);

With each step tied together, we can retrieve Shiba images and generate Tweets with media content. To see the source code, head over to the GitHub repository.

With a working Twitter bot, I could run the script with Node on my local machine. However, it wouldn’t be automated if I had to run it manually. To solve this, I decided to deploy everything onto Heroku. This service allows node servers to run not just simple static files.

With Heroku Scheduler, you can configure script executions. Make sure to add this script to your package.json file:

{
  ...
  “scripts”: {
    “start”: “node app.js”
  }
}

Adding a setting to execute the script on a timer makes the bot automated. I decided to let the bot create a daily Tweet with this tool. Our ManyShiba bot is now fully functional!

View the source code on GitHub.

Follow my journey or connect with me here:

Portfolio Site Continuous Integration GitHub Action

Spencer Lepine — Mon, 08 Apr 2024 20:56:11 +0000

After learning about GatsbyJS and building a static Portfolio site and blog, I searched for systems to deploy this website. At this point, I had purchased the domain name through AWS Route53, but I still needed somewhere to host the static files.

I chose to deploy the site through Digital Ocean Droplet. This was a remote Ubuntu virtual machine with an IP address I could route to. Once I installed apache web server software and connected domain name, the website was live.

There was still one problem with this deployment process. Updating the website took several steps. After local development, I needed to build/generate the static files with Gatbsy locally, and push them to the GitHub repo. Then, I would ssh into the Ubuntu Droplet, clone the updated repo again, and replace the static files for apache to serve.

Steps to deploy were repetitive. Having to remember terminal commands and finding passwords was inconvenient. I was unable to build the static files on the remote Ubuntu machine with limited hardware specs.

One improvement I made was writing a script to delete and copy new files when deploying on Digital Ocean. This addition did not solve everything, as I hard-coded my github username and repository name.

# RUN the script:
# sudo ./syncBuild.sh portfolio-site

GITHUB_LINK="https://github.com/spencerlepine/$1.git"

git clone "$GITHUB_LINK"
echo -e "$GREEN successfully cloned repo$NC \n"

echo "Removing the current public folder"
rm -r -d public
echo "Moving into the github repo folder"
cd $1
echo "Moving public folder contents OUT of repo folder"
mv public ..
echo -e "$GREEN Successfully copy news files $NC \n"
echo "Moving back into parent directory"
cd ..

echo "Deleting leftover github repo files"
rm -d -r  "$1"

echo "Restarting apache server"
systemctl restart apache2

echo -e "$GREEN Public folder sync complete! $NC"

echo "Visit: spencerlepine.com"

# "syncBuild.sh" 52L, 956C

Although this process took less than 10 minutes, switching between the IDE, GitHub, the terminal, and the browser was annoying. It would be better to automate this process. To do that, we can use a GitHub action that will trigger on every repository update. A handy feature of GitHub repositories is the ability to store secrets/environment variables. We can use this to store passwords directly connected to the repository, so all credentials needed for the project are stored in one place.

Let’s create the GitHub workflow file:

name: CI

on:
  push:
    branches: [ master ]

jobs:

  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
    - name: Deploy Static Files
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USERNAME }}
        key: ${{ secrets.KEY }}
        passphrase: ${{ secrets.PASSPHRASE }}
        port: ${{ secrets.PORT }}
        script_stop: true
        script: |
          # change directory to where website files are stored
          # clone the repository
          # remove the current public folder w/ static files
          # enter the repo folder
          # extract the public folder from the repo folder
          # remove the leftover GitHub repo files
          # restart the web server
          echo “Visit deployed site: spencerlepine.com”

Conclusion

This GitHub action will use another ssh-action action to handle the remote ssh connection. After storing the connection credentials in the GitHub repository secrets, this can securely/dynamically connect to the remote Ubuntu machine. The last key for this action job is the script, or verbatim Ubuntu commands that will be run. For the sake of brevity, I have only written pseudo-code for the deployment steps.

With this file saved in the .github folder in the project, GitHub can execute the action and connect to our remote server autonomously. After adding a blog post or updating the website, the only step required is pushing the code to GitHub (which I would do anyways). Now, the GitHub workflow will handle all of the steps to connect to the host server, delete old static files, and download the fresh static files.

The continuous integration for this website is completely automated now. This saves me time and effort. No need to worry about forgetting how to deploy later on.

View the source code on GitHub.

Follow my journey or connect with me here:

Quickly Open GitHub Repo in Browser From Terminal

Spencer Lepine — Mon, 08 Apr 2024 20:56:09 +0000

I work a lot with the Git CLI and GitHub repository cloned on my local machine. I need a fast way to open the repository web page in the browser. Here is how I solved this, specifically on macOS.

To start, the the quickest way to get the remote url is the following bash command:

git remote -v | awk '/origin.*push/ {print $2}' | xargs open

That command alone is not very helpful, since it will be difficult to memorize and type out repeatedly.

Instead, we can create a user-friendly command to use in the macOS terminal. By creating a custom named script in the bin directory, the terminal will execute it when the command is used.

First, navigate to the bin directory:

$ cd ~/../../usr/local/bin

# Make sure this path matches up with your 
# configuration for the terminal (e.g. PATH=$PATH:$HOME/bin)

Now create the script file, here I named the command repo-open:

$ vim repo-open

Now paste the script contents into the file editor:

 #!/bin/bash

git remote -v | awk '/origin.*push/ {print $2}' | xargs open

Save the file:

press ‘ESC’
press ‘SHIFT’ + ‘:’
type ‘wq’ + ENTER

Create the executable:

$ chmod +x repo-open

That’s it! Now you can run the new script in the terminal. If we are in a directory with a .git folder, we can run repo-open, and it will open the remote URL in the default browser.

$ repo-open
# opens new page in the browser

Optionally, you can dig a little deeper into writing these scripts. Here are a few examples for Mac and Windows:

Bash script for Mac:

function gbrowse {
    gbrowsevar=$(git config --get remote.origin.url)
    printf "${gbrowsevar}"
    start $gbrowsevar
}

Script for Windows:

# GIT: open remote repository using Google Chrome
function gbrowse {
    NC='\033[0m' # No Color
    SB='\033[1;34m' # Sky Blue
    PP='\033[1;35m' # Purple
    gbrowsevar=$(git config --get remote.origin.url)
    printf "\n${PP}→ ${SB}gbrowse:${NC} Chrome\n"
    printf "${gbrowsevar}\n"
    start chrome $gbrowsevar
}

# GIT: open remote repository using Firefox
function fbrowse {
    NC='\033[0m' # No Color
    SB='\033[1;34m' # Sky Blue
    PP='\033[1;35m' # Purple
    fbrowsevar=$(git config --get remote.origin.url)
    printf "\n${PP}→ ${SB}fbrowse:${NC} Firefox\n"
    printf "${fbrowsevar}\n"
    start firefox $fbrowsevar
}

That’s all for today, I hope this article was helpful. If you have any questions, feel free to connect with me.

Follow my journey or connect with me here:

TypeScript Development Set Up for VSCode

Spencer Lepine — Mon, 08 Apr 2024 20:56:07 +0000

Looking to set up VSCode for a TypeScript project? This article will walk through the initial configuration steps for just that.

This walk-through assumes you have the already have the following installed:

To begin, let’s install the typescript module globally:

$ npm install -g typescript
$ tsc --version

Great! Now we can code our .ts files. A small issue remains. In order to compile those files to .js, we must run tsc or npm run build manually. To avoid this, we can auto-compile on save in our IDE.

Configure Auto-Compile on Save

Using the build tasks in VSCode, you can trigger auto-compile on save. This can be done through the settings search bar, or the application's menu bar in macOS.

Option 1:

Enter CMD+SHIFT+P
Select: Tasks: Configure Default Build Task
Choose: tsc: watch - tsconfig.json

Option 2:

Find tabs: in OS VSCode menu bar
Click: Terminal (open dropdown)
Select: Configure Default Build Task
Choose: tsc watch option

Now during development, anytime you save the .ts files, it will generate .js output automatically.

Hiding Compiler Output In Editor File Tree

After running tsc build, it will populate the directory with compiled files. You may find .js, .js.map, or .d.ts. files, which could be useful to explore when learning. However, these can clutter up the file tree in the IDE.

There is an easy was to hide these files in the workspace, without deleting them from the file system.

To configure the following VSCode settings, it can be done in the global settings.json file, or for the projects workspace

To set up a workspace, Do "CMD+SHIFT+P" => "Preferences: Open Workspace Settings". This creates the <rootDir>/.vscode/settings.json file in the project directory. Note, you include the .vscode folder in the git history, unless a team is not sharing these settings.

To find the settings file do "CMD+SHIFT+P" => "Preferences: Open User Settings (JSON)" or "CMD+SHIFT+P" => "Preferences: Open Workspace Settings".

Add the following options for file ignoring to the VSCode settings.json:

{
    "files.exclude": {
        "**/.git": true,
        "**/.DS_Store": true,
        "**/*.js.map": true,
        "**/*.js": {"when": "$(basename).ts"}
    }
}

{
  "files.exclude": {
    "**/.git": true,
      "**/.DS_Store": true,
    "**/*.d.ts": {
      "when": "$(basename).ts"
    },
    "**/*.js": {
      "when": "$(basename).ts"
    },
    "**/*.js.map": {
      "when": "$(basename)"
    }
  }
}

Using .gitignore

When using git for your TypeScript project, you are not committing the compiled JavaScript code. You most likely will ignore the files generated, so you can configure that in the .gitignore. Be aware of needed files however, for example a jest.config.js file.

Keeping the source .ts files, a .gitignore file may look like this:

*.js
!jest.config.js
*.d.ts
node_modules
!lambda/*.js

Configure Format On Save

Optionally, you can avoid wasting time on formatting with formatOnSave. Add the following key to your settings.json file to enable:

"[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": true
  }

Conclusion

That's it! You can now begin development for your new TypeScript project, with auto-compile and format-on-save enabled. The main purpose of this article was to document the setup project for my own use, and strengthen my understanding by teaching.

That’s all for today, I hope this article was helpful. If you have any questions, feel free to connect with me.

Follow my journey or connect with me here:

What I Learned During 100DaysOfCode

Spencer Lepine — Mon, 08 Apr 2024 20:56:05 +0000

I recently completed a popular challenge on Twitter named #100DaysOfCode. There is no barrier to entry, and you just need to code for at least 1 hour a day. This is a great challenge to motivate yourself and see your progress alongside others.

In my case, it was not my first time coding when I started this. However, the challenge helped me stay dedicated and build upon each skill I learned.

To see the original README journal, see this repository

Day 1–10: The Challenge Begins!

It all started with a ton of useful lessons on ES6 skills. There was a lot of new syntax and tricks that I never knew about. Since I started learning Javascript before ES6 was released, there were quite a few features I needed to practice.

ES6 Course - Scrimba

Having just completed a small course on the React framework, I worked on implementing ES6 skills I picked up to make small projects. Here is a simple React app connected to GitHubs REST API. This helped me learn how to make fetch calls and save the data to state.

spencerlepine/github-api-react - GitHub

Each day I worked on different React concepts. Connecting/modifying a mock database locally. Working with state and props and pass data around. My most effective learning styles was learning-by-doing. After reading the docs and seeing a new feature, I would realize how I could use it to improve my project.

To wrap up this part of the challenge, there were some coding challenges from Cyber Dojo to help practice problem solving. I was able to solve “Align Columns”, “LCD Digits”, “Wonderland Number”. Check out my repo with my solutions here:

spencerlepine/cyber-dojo-exercises - GitHub

Day 11–20: Just Getting Started

At this point, there was some great momentum and I was always feeling more motivated to learn. The Scrimba React course had a lot of great lessons on all the basics of React.

The React Bootcamp - Scrimba

I built a controlled-form in React that would update state based on events and targets. Next up was the big concept of hooks and functional components. Little did I know this was only the START of what is possible in React.

The React course was complete, which led me to start a new project called Spotify Top Songs. This site would connect to the Spotify Web API with client-side authentication. When a user connected their account, they could select various artists from a menu. The script would then generate a playlist by accessing the top 5 songs of each artist.

This time, code was much more organized with the components and logic separated. With so many fetch calls and bits of logic to intertwine, it was important to build everything slowly and cleanly.

spencerlepine/spotify-top-songs - GitHub

I learned about prop-types and default props, which can be pretty handy. Worked React higher order components and children components. Started learning about AWS S3 buckets. To practice, I deployed my Spotify Top Songs to the S3 bucket.

After discovering the behemoth of AWS products, I wasted no time working to set up an AWS EC2 instance to host a static site, which I would connect to my Route53 domain.

Just before reaching day 20, a worked on an in-browser Chess React app. This was just another opportunity to practice Javascript and apply knowledge.

Day 21–30: Gaining Momentum!

With a solid understanding of React, it was time to double down on more computer science fundamentals. It was exciting to build toy projects, but that wouldn’t be enough.

After finding the CS50 course online, I watched the lectures on C and Python. This was very useful to learn about memory pointers and how the interpreter reads code. Dave is a GREAT teacher and I would highly recommend going through the course.

Lots to learn about memory allocation, what libraries are doing under the hood, string manipulation, and regex.

Alongside CS50 was more material about React memo and Context API — write a component to access a ‘global’ state in a separate file. Import that file and render through that in any component of choice. Custom hooks that handle business logic. React router basics. Conditional rendering. All of these skills would allow me to start creating real multi-page sites!

Day 29 was the day I started working on Galvanize basic prep lessons.

Day 31–40: Diving Deeper

CS50 included some lessons about data structures and SQL. I worked on some really good challenges for the CS50 Fiftyville assignment.

It was time for me to learn how to connect a database. I began working with MongoDB and Node.js. I used Postman to practice making requests.

With a lot of data to store in state, I needed a way to organize it all. Thats where React Redux came up — createStore, redux philosophies, subscribe, dispatch, combineReducer. Abstracting reducers to handle each state in isolation. combineReducers to combine everything and handle state more cleanly in a rootReducer.

With MongoDB connected to React, I was able to work on a MERN app that could read/write from the database. Connecting back-end/front-end routes and using controllers for the fetch logic/requests.

Day 36 was when I began the QuickCar react app. Connected it to a backend MongoDB Atlas server. Add reducer + actions for post/fetch from frontend. Save the data in redux state. I created forms and routes with components connected to the Redux state using useSelectors.

Day 41–50: Working on QuickCart

As I worked through some lessons for Galvanize basic prep, I also started lessons on freeCodeCamp. Got a better understanding of Regex from that.

Next came Javascript algorithm practice + Object Orientated Programming review. Inheriting methods from parent objects. Using Object.prototypes to reuse methods.

I revisited my AWS account. Started basic portfolio site using React — Set up LAMP stack server to host website. Direct AWS Route53 domain to DigitalOcean droplet. Set up SSL, MySQL, and WordPress. Working to set up a blog too.

With a working site, it would be really nice to have a blog hosted on the domain. I attempted to set up a blog. Researched Gatsby, GraphCMS, ButterCMS, GraphQL. Queries were not working. Unable to route to posts. This was a difficult concept to navigate, but along the way I learned a lot about apache and setting up ssl.

Day 51–60: A Working Blog!

Gatsby.js was the answer. Instead of using a headless CMS, I settled with local md files to use for an article. During this challenge, I spent many hours working with the ‘mdx’ plugin. I tried to connect a CMS through queries and GraphQL, but it was very difficult.

Around this time I continued working through Learn.co lessons for Flatiron prep. There were two main sections on Javascript and Ruby. The Ruby material was interesting and they even did a review on Object Oriented Programming.

Flatiron wasn’t the only school that I was preparing for though. I completed my technical assessment by creating a basic HTML page with images and a clickable button.

The last major assignment on hand was working through more of the freeCodeCamp Javascript fundamentals material.

Day 51–60: Coding Bootcamp!

No, I didn’t start a coding bootcamp, but I was getting ready! I got accepted into Flatiron (they didn’t do a TAA anymore), accepted into General Assembly, and I was studying to pass my Hack Reactor technical assessment. My target was in August, which was over 100 days from this point.

Making sure I could get into these schools was my main priority, but I continued learning and working on projects on the side.

I worked on building the QuickCart app and added tons of features. Import/Export a grocery database. Improve the UI and styles. Upload images for a product in the form. Convert images to base64 strings. Work with file blobs and cropping images. Generate suggested products with a recommendation algorithm. Work on authentications between the front/back-end for the MERN app. Add a “cart” to store items until purchase.

At this point, the grocery app was still connected to MongoDB. I was able to use localStorage and save some user data, but I knew I needed EVERYTHING to be in the cloud.

With all that work done, I began Hack Reactor premium prep. The technical admissions assessment was going to be difficult, so this would help me prepared my vocalization and problem solving.

This is where I began working testing. Test driven development is integral to Software Engineering. I was able to appreciate my code much more after practicing it.

Day 71–80: Hack Reactor and Firebase

At this point, I was making really good progress in my Hack Reactor prep work. I was able to learn the basic methodology of testing my code. Whenever I worked on Javascript challenges, it was important to practice writing tests and get used to the upfront setup.

This week was my first attempt at the Hack Reactor TAA, and I passed! This was incredible, because I got to choose between GA, Flatiron, and Hack Reactor.

I continued working on QuickCart on the side. There were some bug fixes and UI improvements that needed to be done. I migrated from MongoDB to Firebase for the backend. I had to read through the docs and get familiar with Firestore.

One of the most important themes of this week was practicing problem solving. Hack Reactor was really pushing best practices and effective communication. Each day I worked on a toy problem/code challenge. With a timer running, I would work on my pseudo-code BEFORE starting and really explain/verbalize my thought process as much as I could.

Now that I was able to write small tests for a challenge, I wanted to work on writing tests for a real project. I started learning how to use Enzyme and Jest for React test-driven-development. The process is tedious at the start, but it will ensure the code is more robust. This was difficult for me at first, because I wasn’t sure if my React test was written incorrectly, or I needed to pass the test now instead. There were lots of features to read Docs about, like redirecting, testing contexts/store, and tons more.

Day 81–90: Test Driven Development and APIs

The TDD practice with React was the birth of Woofer. I wanted to work on a project and build it from the ground up writing tests. I did my best to write a test FIRST before writing code. This project did not go very far during my challenge, since there were other priorities. It was going to take a long time to complete the idea, and it was just good practice to implement testing.

I documented/planned out the Woofer app before starting. I made wireframes and planned out the logic/routing ahead of time. It was taking WAY too much time to work with mock stores and complex routing in testing. I even fell into certain anti-patterns with testing after researching about tests online.

spencerlepine/woofer - GitHub

I stepped away from the deep rabbit hole of React TDD. I went back to QuickCart and migrated EVERYTHING to client-side. Now it was one complete React app with firebase authentication built in. I was able to host this site on Heroku too, so anyone could use it.

spencerlepine/quickcart - GitHub

One feature I had been eager to add to the grocery app was “searching products”. With an empty form, users could manually input EVERY detail about a product, but nobody would want to use that. By connecting to the OpenFoodFacts API, I could search a dump of thousands of grocery products. This was an open source dump that anybody can contribute to. They also feature nutrition score data, so it can help users see healthier options.

Day 91–100: The Final Stretch

After learning so much with Javascript and best-practices for writing code, it was time to USE these skills. I continued working through Hack Reactor prep material. I learned about higher order functions, scopes, and hoisting. There were lessons about terminal commands and important dev tools like homebrew. It was time to upgrade my developer workflow, and get familiar with industry standard software.

Here I read about Node.js, npm, semvar, and modules. This was everything I need to know about how projects are set up and how developers are able to work together. There needs to be structure and conventions throughout the code base so everyone is on the same page.

I also added a some features to QuickCart on the side again. I connected a Google Custom Search Engine to allow image searches for a product. Instead of having the user upload or snap a photo, they could simply link an existing photo. This allowed me to store the image sources with links, instead a long base64 string with image data. That would improve scalability and prevent product images from being lost easily.

The next Hack Reactor prep section was about Git and GitHub. This was a REALLY useful sections to go through because it will be the backbone of any project. Knowing how to properly document and collaborate on a project makes everything so much more compatible. Your code needs to be readable and maintainable. People can review your code and merge branches to improve the project. You could even checkout different commits and revert your code. Before I learned about these practices, I would always CTRL+Z my file and start over again, wasting so much time.

More work on Mocha and Chai testing was done. Getting familiar with different libraries and how they have similar functions.

Conclusion

Challenge complete! After 100 days of coding, I was able to explore new features and concepts relating to Javascript and software development. The dedication allowed me to keep my momentum and build upon what I learned the previous day.

Here is an overview of everything I learned:

ES6 Javascript
Functional vs. OPP programming
Javascript algorithms and data structures
Node.js
Redux
React
SQL
Python
Comp Sci fundamentals
MongoDB
Firebase
React Context, state, props, controlled forms
CMS
Hosting a static site
Procedure for problem solving (pseudocode, breaking it down)
Mocha/Chai testing
React Jest/Enzyme testing
Connecting to APIs (Spotify Web API, GitHub REST API, OpenFoodFacts API)
Fetch calls + axios
Separating the front-end / back-end
Deploying to Heroku

Projects

Explore more projects — or check out the ones mentioned in the article:

QuickCart
- Make a shopping list with personal grocery data to help budget.
- Source Code: GitHub Repo
Portfolio Site
- Portfolio and blog website (Visit Here) created by Spencer Lepine. Built using static pages created with GatsbyJS…
- Source Code: GitHub Repo
Cyber Dojo Exercises
- Personal solutions to various Cyber Dojo exercises. Code is written in Python and tests use 'asserts' with pytest. All…
- Source Code: GitHub Repo
Woofer
- Tinder for Pets Web App. Swipe and connect with other furry friends in the area.
- Source Code: GitHub Repo
React Chess
- Play chess in the browser by with drag and drop moves. This was created using the Javascript React framework. component…
- Source Code: GitHub Repo
Study Garden
- Improve focus and discipline with this timer app. Study until the timer runs out and add plants to your personal…
- Source Code: GitHub Repo
Spotify Top Songs
- Generate a Spotify playlist based on the top rated songs of your favorite artists. Connect user Spotify accounts to…
- Source Code: GitHub Repo
GitHub User Overview
- This React App allows the user to type a username get an overview of their GitHub repos using the GitHub REST API.
- Source Code: GitHub Repo
CS50 Problem Sets
- My solutions to the online CS50 course generously provided by Harvard University.
- Source Code: GitHub Repo

Interested in working together?

Follow my journey or connect with me here:

Software Engineering Workflow

Spencer Lepine — Mon, 08 Apr 2024 20:56:02 +0000

This is a collection of resources and my general workflow for Software Engineering. Note: workstation is running MacOS.

Dependencies/Libraries:

Homebrew - package manager for linux-based OSs.
Git - version control, manage files during project development
Node.js + Nvm - runtime for javascript without a browser
Npm - large organization of libraries/packages available to use in projects.
Python 3 - python language interpreter for python ^3.0.0.
MySQL - SQL database software for development
Redis - real time data storage with different data structures in a cache
Heroku CLI - manager for Heroku apps from the command line
Amazon CLI - manager for AWS services from the command line

Communication:

Slack
Zoom

Recording:

Other Software:

Chrome - main browser with debugging tools
Postman - API platform for easy endpoint testing
Flux - screen eye strain assistance
GIMP - photo editing software

Toy problems:

Note taking:

Notion

IDE:

VSCode:

MacOS Quick Action: Open Folder from finder -> Configure Quick Action
ESLint Extension - Integrates ESLint JavaScript into VS Code.
Bracket Pair Colorizer Extension - A customizable extension for colorizing matching brackets
Open In Default Browser Extension - A VSCode extension to fast open html file in browser
Stylelint Extension - Modern CSS/SCSS/Less linter

settings.json:

    {
       "editor.lightbulb.enabled": false,
       "editor.parameterHints.enabled": false,
       "editor.renderWhitespace": "all",
       "editor.snippetSuggestions": "none",
       "editor.tabSize": 2,
       "editor.wordWrap": "off",
       "emmet.showExpandedAbbreviation": "never",
       "files.trimTrailingWhitespace": true,
       "javascript.suggest.enabled": false,
       "javascript.updateImportsOnFileMove.enabled": "never",
       "javascript.validate.enable": false,
       "eslint.alwaysShowStatus": true,
       "explorer.confirmDelete": false,
       "python.pythonPath": "/usr/bin/python3",
       "workbench.editorAssociations": {
           "*.ipynb": "jupyter.notebook.ipynb"
       },
       "[javascript]": {
           "editor.defaultFormatter": "vscode.typescript-language-features"
       },
       "css.validate": false,
       "window.zoomLevel": 2,
       "editor.hover.sticky": false,
       "editor.formatOnPaste": true,
       "editor.formatOnSave": true,
       "editor.defaultFormatter": "vscode.json-language-features",
       "workbench.iconTheme": "material-icon-theme",
       "security.workspace.trust.untrustedFiles": "open",
       "liveshare.allowGuestTaskControl": true,
       "liveshare.allowGuestDebugControl": true,
       "liveshare.anonymousGuestApproval": "accept",
       "python.defaultInterpreterPath": "/usr/bin/python3",
       "editor.largeFileOptimizations": false,
    }

Interested in working together?

Follow my journey or connect with me here:

Preparing for My Amazon Front End Engineer Interview

Spencer Lepine — Mon, 08 Apr 2024 20:56:00 +0000

This article covers all the study material and advice that helped me ace my Amazon Front-End Engineer I (FEE) interview (November 2022, remote onsite). This is relevant to both the 60min phone interview and final round on-site. I’ll break it down into two sections, technical and behavioral.

Note, if you’re brand new to the FEE role, I’d recommend skimming through this article first.

Interview Stages

The initial 60-minute phone screen is typically more laid back, but still focused. It’s an opportunity to talk about your background and motivation to work at Amazon. You’ll want to be up to speed with LeetCode-style problems (mostly medium, rarely hard) and familiarized with the LPs (Leadership Principles).

For the full on-site, I’d recommend reviewing this entire article.

Here’s brief visual for the interview pipeline at Amazon:

Amazon Interview Stages: Application → Online Assessment (OA) → Phone Screen (60min) → Onsite (4 rounds) → Team Matching

Technical Skills & Coding Challenges

You likely won’t use an IDE during the interview, allowing you to focus on the concept/design, instead of wasting time on bugs. In my job-hunt experience, this style of using plain JS/CSS/HTML was unique to Amazon and I took some time to brush up on vanilla JS.

Here’s a breakdown of what I studied for the technical portion:

LeetCode problems (mostly medium, a few hard)
Verbalizing your thought process
Vanilla JS and DOM API (practice building simple widgets)
Frontend system design basics

For the online assessment (OA) and coding challenges, it’s best to practice LeetCode style problems (medium difficulty, rarely high). When solving these problems, I briefly think about edge-cases/constraints, write all the psuedo-code, then attempt the problem. Don’t hesitate to check in with the interviewer at checkpoints, asking if you’re on track or they have any thoughts. Even if you don’t solve 100% of the problem, an interviewer still values the progress you make.

It’s critical to verbalize your thought process while solving problem. Whether you are explaining your implementation, or thinking through the problem, the interviewer is assessing how you work through it. Avoid going silent if possible. I pretty awkward at this, so to practice I did talked through LeetCode problems in recorded mock Zoom meetings (like this video)

For the on-site final round, you’ll work on a frontend system-design question, which will be solved using vanilla JS, CSS, and HTML (including DOM API). Keep in mind that the difficulty level may vary based on your experience, potentially covering a broader scope than outlined in this article.. Note, this could vary based on your level of experience, so difficulty level could be a larger scope than this article. You may need to brush up on the DOM methods and syntax. I recommend building several small widgets to practice. Make sure you understand selectors, event listeners, and modifying styles with JS. If you are unsure what kinds of widgets I am talking about, look through this page.

Make sure you understand frontend system design basic: component design, state management, performance optimizations, and APIs. To delve into this check out this playlist with TONS of detailed videos.

Example Questions

Find the missing number in the array
Determine if the sum of two integers is equal to the given value
Merge two sorted linked lists
Copy linked list with arbitrary pointer
Copy linked list with arbitrary pointer
(system design) Design a restaurant listing application where user can make orders and customize their orders by adding additional stuffs like toppings, salads etc. (example)
(system design) Design an accordion component

Resources

LeetCode Questions: Amazon Interview Questions (2024) | Glassdoor
LeetCode Questions: Amazon-Tagged Leetcode Questions (wuyaheng.github.io)
Design Questions: Amazon Front End Interview Questions | The Official Front End Interview Handbook 2024
Article: https://www.educative.io/blog/crack-amazon-coding-interview-questions
Video Playlist (Frontend System Design): https://www.youtube.com/playlist?list=PLI9W87-Dqn7j_x6QtR6sUjycJR7nQLBqT

Soft Skills & Behavioral Questions

Each interview will include a behavioral question relating to one of the 16 LPs. You don’t have to be an expert, but take some time to learn & familiarize yourself with them.

My advice would be to prepare 1-2 stories per LP before the interview, as you will need to share concise answers on the spot. I’d recommend jotting down keywords for each story to reference. These can be related to work experience, internships, school projects, personal projects, volunteering, extracurriculars, or any situation where you demonstrated leadership, problem-solving, or collaboration. It doesn't have to be strictly work-related.
To tell a concise/structured story, you can use the STAR framework, or slightly adapt it. STAR helps to give clearer context and outcomes.

An important theme is that technical skills can easily be taught, soft skills cannot. A valuable candidate has great personality and team collaboration skills.

Example Questions

Why Amazon? (watch an example answer from an ex-Amazon interviewer)
Tell me about a time you failed at work. What did you learn from it?
Tell me about a challenge you faced. What was your role & the outcome?
Tell me about a time you disagreed with a coworker/manager/decision
Tell me about a time you had to work or make a decision quickly / under a tight deadline

Resources

Additional Resources

In no particular order, here’s a list of more material I found useful:

Article: Amazon Front-End Engineer Interview Prep
Article: Understanding Amazon’s Front-End Engineering Interview
Article: How I Landed a Front-End Engineering Job at Amazon
Video: Rejected by Amazon - Frontend and Software Engineer - Full Loop Interview Exp with no degree at all
Video: Amazon Front End Interview Prep | Software Engineer
Video: Amazon Frontend Interview Experience 2022 | Frontend Engineer 2
Video: Amazon Interview Experience | Software Engineer
LeetCode Post: Amazon Virtual Onsite - FrontEnd Engineer II Offer
Google search: “reddit amazon front end engineer”

🚀 Nail Your Tech Interviews with FAANG+ Experts. Get 20% off on Mock Interviews.

Mock interviews and thorough feedback to help you land your dream tech role faster.

Trusted by over 25,000 experienced tech professionals.

Start Practicing Now

Conclusion

TL;DR - practice LeetCode medium, brush up on vanilla JavaScript and CSS fundamentals, verbalize your thought process, prepare stories for each LP, and be confident.

This covers just about everything I used to prepare for my FEE interview. Keep in mind, my interviews were fully remote, and this is biased to my experience for an entry level position.

I hope you found this article useful! If you have any questions and would like to connect, you can find me over on LinkedIn or shoot me an email.

DEV Community: Spencer Lepine

Demystifying Bash and Zsh on Mac

History

Terminal: Which to Use?

Scripting: Which to Use?

One-time Laptop Setup

Migrating to a New Laptop

What is PATH?

Conclusion

GET, POST, PUT & DELETE with Next.js App Router

Getting Started

Endpoints

GET

POST

PUT

DELETE

Data Fetching & Rendering

Client-side Rendering

Static Server-side Rendering

Dynamic Server-side Rendering

Authentication

Conclusion

Building Llama as a Service (LaaS)

What I Learned

Demonstration

Creating an API

Image Database

Connecting API to the Database

Endpoint Load Testing

Optimizing the Endpoint

Horizontally Scaling the API

Setting up Authentication

Creating a Gateway API

Environment Variables and Configuration

A Simple Frontend

GitHub Actions Testing and Deployment

Deploying to Production

View the Source Code

Creating Custom Git Commands

Create an executable

Run the command!

Git Project Configuration With Husky and ESLint

Walkthrough

Package.json Updates

Configure ESLint (optional)

Everything in action

Boilerplate

Notes

ManyShiba - The World's Greatest Twitter Bot

So what exactly is the ManyShiba Bot?

Technologies:

Portfolio Site Continuous Integration GitHub Action

Conclusion

Quickly Open GitHub Repo in Browser From Terminal

TypeScript Development Set Up for VSCode

Configure Auto-Compile on Save

Option 1:

Option 2:

Hiding Compiler Output In Editor File Tree

Using .gitignore

Configure Format On Save

Conclusion

What I Learned During 100DaysOfCode

Day 1–10: The Challenge Begins!

Day 11–20: Just Getting Started

Day 21–30: Gaining Momentum!

Day 31–40: Diving Deeper

Day 41–50: Working on QuickCart

Day 51–60: A Working Blog!

Day 51–60: Coding Bootcamp!

Day 71–80: Hack Reactor and Firebase

Day 81–90: Test Driven Development and APIs

Day 91–100: The Final Stretch

Conclusion

Projects

Interested in working together?

Software Engineering Workflow

Dependencies/Libraries:

Communication:

Recording: