 Courses from Joel Lord

Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries – anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment.

docker

The end is nigh. Your application is almost ready, and you will need to deploy it. And with the deployment, the endless tweaking to get everything running on your production servers. 

If only there were a way to test everything first. That is where containers will come in to save the day. With containers, you not only run your code in an environment similar to the production server, but you also run your code in precisely the same environment. 

In this talk, the attendees will learn about how to create container friendly applications and how to use containers to share their code with their team.

Containers for Software Developers

While "It works on my computer" might give you an excuse to close a bug ticket in the backlog, it doesn't really work when you're working on a team.

You need to ensure that your application can run regardless of what hardware your teammates are running or libraries they have installed.

Docker solves this problem by collecting everything your application needs to run into a container.

Containers aren't just for source code. They can hold configuration, scripts, and even their own filesystem. It's similar to a Virtual Machine, without having to bring a full operating system along for the ride.

Because containers run in isolation, there is some configuration involved to allow for files to be saved and containers to communicate with one another.

One of the most useful ways to get your head around Docker is to see it in action.

Follow along with Joel Lord as he works through the process of preparing an application to run in separate containers for the frontend and backend of an application that searches for gifs and re-encodes them with a caption supplied by the user.

You'll see how to configure the separate containers to communicate with one another, work with environment variables, and persist data to your local machine. Along the way, you'll pick up some tips on useful commands and bash scripting. Finally, you'll learn how to use Docker Compose to make it easy to run multiple containers simultaneously.


Containerize Full-Stack JavaScript Applications with Docker

Now that all three tiers of your application are available in containers, you'll need to push those images to container registries. Registries are the container equivalent to repositories for your code. Registries can be public or private. 

In this lesson, we'll use Docker Hub to push our images. Docker Hub repositories allow you share container images with your team, customers, or the Docker community at large.

Docker images are pushed to Docker Hub through the `[docker push](https://docs.docker.com/engine/reference/commandline/push/)` command. A single Docker Hub repository can hold many Docker images (stored as **tags**).

Images pushed to a public registry can be downloaded by using the `docker pull` command. Once they have the image downloaded, they can use Docker run to start each container just like you did in the previous steps.

Push a Docker Container Image to Docker Hub

In the last lesson [Create a Custom Image with a Dockerfile running Node.js](https://egghead.io/lessons/docker-create-a-custom-image-with-a-dockerfile-running-node-js?pl=introduction-to-docker-afaf), our backend stopped working again because it couldn’t find the database.

One of the advantages of running containers is that they run in isolation. As far as the container is concerned, nothing exists outside of it. It behaves as if it was its own operating system. This is why the backend can’t find the database on "localhost". The two containers are running on the same host but as far as the backend is concerned, there is no database. The same goes for the database. It can’t see anything outside of what is running in its container therefore it can’t see the backend application running.

When you need a way for multiple containers to talk to each other, Docker has a tool called networks to help you. We'll use a network to allow our backend to successfully connect to the database.

Allow Containers to Communicate through Docker Networks

You will learn how to create your own images that will include all the source code of your application, along with a specific version of Node.js and all the dependencies that are needed. Once you are done, you will be able to share this image with other people and this will ensure that everyone is running the same environment. It will event let people that don’t have Node.js run this server. This will also have the added benefit of cleaning up everything once you close the application.

You'll notice that we will run into the same error stating we can't connect to the database. This is expected and we'll fix this in [Allow Container to Communicate through Docker Networks](https://egghead.io/lessons/docker-allow-container-to-communicate-through-docker-networks)

Create a Custom Image with a Dockerfile running Node.js

First, we'll see how you can have different run-times installed in a docker container that isn't dependent on your system's current installs. You don't need anything but docker to run these containers! We will demonstrate this by installing the latest version of Node.js in a docker container and compare that to the version of Node.js I'm running on my machine.

Next, you'll see how to pass environment variables to containers. This is important because you will use these variables for API calls as well as configuring databases, and more!

Use Environment Variables for Docker Containers

In this lesson, you will learn how to start basic containers and how to use them in your day to day developer life. You will also learn how to start a database container that can be used with the demo application for this course.

Running Your First Container

JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

First, we'll get a tour of the application and what it does then we will start configuring a fresh project. 

The application UI is simple. It asks for a keyword and will search and display a random GIF from Giphy. Once you are satisfied with the image, you will be able to add a caption to it. The server will deconstruct the GIF frames, add the caption and re-create the GIF for you. Everything is then saved to a database so that all the users can benefit from your creations.

The tech involved to do this is a Vue frontend, Node.js backend, and MySQL database. I'll walk you through cloning, installing dependencies, configuring the giphy API key that we use, and starting the application. You'll notice at the end we'll need to configure the database. We'll get an error but this is expected!

Configure and Run a Node.js API Powered by a Vue Application

Now that you have three containers ready to be used, you will learn how to create a docker-compose.yaml file. By using Docker Compose, you will be able to share a single YAML file and anyone will be able to run your application.

Docker-compose is part of the Docker tools suite and is an application that will take a YAML file to start all of your containers with one single command. 

Using Compose is basically a three-step process:

1. Define your app’s environment with a `Dockerfile` so it can be reproduced anywhere.
2. Define the services that make up your app in `docker-compose.yml` so they can be run together in an isolated environment.
3. Run `docker-compose up` and Compose starts and runs your applications. 

Compose works in all environments: production, staging, development, and testing.

Use Docker Compose To Share An Entire Application

Introduction for the lesson on using environment variables in a front-end container

Mini talk - Access Environment Variables in a Dockerfile to Build a Front-End Container

In this small talk, the instructor explains why you need to use a multi-step build to prepare your front-end container.

Mini talk - Containerize the Front End of an Application with a Multi-Step Docker Build

Docker containers that are running on your local machine can't communicate with each other. In this mini talk, the instructor explains why and shows a demonstration of Docker networks.

Mini talk - Allow Containers to Communicate through Docker Networks

This course will take you through the process of preparing an application that's configured for development to deployed on a Kubernetes cluster.

First, you will need to tweak your application so that it can run in containers. Then, you will see how you can use containers to complement your application and run a database without even installing the actual software. Eventually, you will create a whole environment with your containers that will enable you to start all the applications with a single command. This can be useful to share the application with your colleagues.

We'll make sure you have the correct software installed on your machine to get started.

You will need a few software installed:

- [Node.js](http://nodejs.org)
- [Docker](http://docker.com/) or [Podman](http://podman.io/)
- [git](http://git-scm.com/)

As well as an [API key from giphy](http://developers.giphy.com/)

Course Intro: Containerize Full-Stack JavaScript Applications with Docker

Running our server as a Non-Root user is very important for testing things such as quality assurance. Many things can get missed when using a privileged account such as your root user account. Here we need to set up and change the Nginx configuration to run as a Non-Root user. 

This container uses two steps. The first step uses a container to build the production version of your VueJs application. This container won’t be deployed on a server, its purpose is to create the necessary files for the second step. It's fine to leave this container running as root. 

In the next step of the build, the Nginx server is the one that will need to run as a non-root user because it is actually run on servers you want to deploy to. To do so, you will first need to change the Nginx configuration to run the build using the Nginx user with files modified for that user to access them.

Run an Nginx Image as Non-Root Within a Multi-Step Docker Build Process

Starting up our server and running the curl command `curl localhost:3000/health`, we find that we get an error. Our server is complaining about us not having a database. Since this is a fresh install, we have no data at all. SQL comes with a file called `init.sql` inside of your `db` folder that will create a database, add the necessary tables for our application, and prepopulate the table with a single entry. We just have to put it in the folder that MySQL will use to populate the database!

Integrate a MySQL Docker Container Into an Application

Running MySQL in a Docker Container is great for being able to emulate various environments. The more advanced containers will include a bunch of executables and runtimes that will allow you to do run more intricate commands. These commands can be very useful for sharing with other teams for testing purposes. It doesn't matter what runtimes they have on their end, by using the `docker` command, you'll be able to specify what runtimes to use to execute your code. 

Run MySQL in Docker Container

The containers you built in the previous lessons are running as root for a few reasons. First of all, we read and write files from the file system in order to install tools like jq or to change some configuration files. And second, we are running servers on ports that are restricted to the root user (such as port 80).

While the risks are very limited in your own environment, you will need to have security in mind when you are deploying those containers to a production server. Some hosts will prevent any container where the user is root to be running at all.

From the Dockerfile, we will specify the use that builds the container will be the `node` user that the node image gives us. To do this we will need to set permissions for the node user to add and modify specific files.

Create a Node.js Non-root Image

This lesson uses some advanced concepts and some bash scripting to build a better Dockerfile. By using the concepts showed here, you will be able to build more future-proof and production-ready containers. If you prefer to focus on the content about containers, feel free to ignore this lesson and come back to it later on if needed.

Currently, we use `sed` to overwrite the hard-coded path to the API. This works well when there is a single value to replace. Now if one of your team members replaced the value of localhost:3000, your build will break.

We'll use `jq` to fix this issue. Jq is a command-line tool that makes it easy to change values in a JSON file. The base image that we used for building the application does not contain this tool, but that is not an issue. To install `jq`, you will need to download the [binary](https://github.com/stedolan/jq/releases/download/jq-${JQ_VERSION}/jq-linux64.), we'll need that to execute `jq` commands in our Dockerfile. This will allow us to update specific properties i

Modify a JSON Configuration File with jq

In the previous lesson, [Containerize the Front End of an Application with a Multi-Step Docker Build](https://egghead.io/lessons/egghead-containerize-the-front-end-with-a-multi-step-build?pl=introduction-to-docker-afaf), we managed to put all of our front-end in a container and we can now distribute this container to the rest of our team. This will work well with stand-alone websites but as soon as you need to connect to an API, this could become an issue. 

You will need to specify the base URL of your server and this would need to be done as an environment variable. The problem here is that since our application lives in a browser, it can’t read the environment variables from the server.

In the last lesson, you’ve seen that all requests were made to `http://localhost:3000`. This means that this value was hard-coded somewhere in the front end source code. The first thing you will want to do is to find out where this was coded and make sure that it is only defined in one place.

The fix here will be to create a bash script that updates the hardcoded `localhost:3000` URL to a BASE_URL environment variable and update the instances that are used within the frontend app to your environment variable. This script will be called in the projects Dockerfile and override the original entry point.

Access Environment Variables in a Dockerfile to Build a Front-End Container

For your front end, a VueJs application has been created from the CLI. VueJS, just like React and Angular applications have a development mode as well as a production mode.

Once you are ready to deploy this application, you won’t want to use the same code as you do when you develop. In fact, you will need to run another script to build a production application. This script will take all of your JavaScript files and merge everything into a single minified JavaScript file. It will do the same for your CSS. By doing so, you will end up with a minimal set of files that can be served over any static file webserver. In this case, you will be using an Nginx server to serve those files. Nginx is an open-source, high-performance HTTP server that will be able to handle many requests to your front end.

We'll do this with a multi-step build in a Dockerfile that will discard the first container that we use to build the source code and run it in a container that's built on top of the nginx image.

Containerize the Front End of an Application with a Multi-Step Docker Build

When comparing two visually similar websites, it can often be challenging to precisely identify the subtle differences between them. To facilitate a rapid analysis of these discrepancies, a practical technique involves leveraging Chrome's integrated developer tools to capture full-page screenshots of each site. Subsequently, these screenshots can be uploaded to a platform like AI Studio. There, the AI can analyze the images and generate a report detailing the variations. This entire process, leveraging a few quick shortcuts, can be completed in under a minute, delivering a comprehensive breakdown of the differences for efficient comparison and analysis.

Quickly Compare Two Sites Using AI Studio with Chrome Full Page Screenshots

It's fairly trivial to create a React project, but there's always a big hurdle between creating it locally and making it shareable so that someone else can run it. This lesson walks you through the process of automating creating a React project locally, creating the repository where it's going to be hosted, and creating shareable links where it can be run so that you can quickly and easily create single one-off demos and shoot them over to your friends and coworkers for sharing your code ideas in a working environment.


```bash
share-react-project() {
  if [[ -z "$1" ]]; then
    echo "Usage: share-react-project <project_name>"
    return 1
  fi

  local project_name="$1"
  local github_username=$(gh api /user --jq '.login')

  echo "Creating Vite project: $project_name"
  pnpm create vite "$project_name" --template react

  cd "$project_name"

  echo "Initializing Git repository"
  git init

  echo "Adding all files to Git"
  git add .

  echo "Creating initial commit"
  git commit -m "Initial commit"

  local codesandbox_link="https://codesandbox.io/p/github/${github_username}/${project_name}"

  echo "Adding CodeSandbox link to README.md"
  echo "" >> README.md
  echo "## CodeSandbox" >> README.md
  echo "[![Open in CodeSandbox](https://assets.codesandbox.io/github/button-edit-blue.svg)](${codesandbox_link})" >> README.md

  echo "Adding README.md to Git"
  git add README.md

  echo "Committing README.md changes"
  git commit -m "Add CodeSandbox link"

  echo "Creating GitHub repository: $github_username/$project_name"
  gh repo create "$github_username/$project_name" --public

  echo "Pushing to remote 'origin'"
  git push -u origin main

  echo "Project '$project_name' created successfully!"
  echo "GitHub repository: https://github.com/$github_username/$project_name"
  echo "CodeSandbox link: $codesandbox_link"
}
```

Automate Creating a Local React Project, GitHub Repository, and Live Hosted Demo in a Single Command

[Verdaccio](https://verdaccio.org/) is a fully featured NPM registry that you can run locally on your machine. It’s a great tool for testing your release process, running end-to-end tests, and simulating real-world scenarios like deploying packages, installing them, and verifying functionality as an end user would.

Nx includes a [generator](https://nx.dev/features/generate-code) that simplifies setting up Verdaccio. To configure it, run:

```shell
npx nx g @nx/js:setup-verdaccio   
```

This command installs the necessary NPM packages and creates a `project.json` file with a `local-registry` target. To start the local registry, open a new terminal window and run:

```shell
npx nx local-registry
```

This will:
- Launch the Verdaccio registry.
- Configure NPM to point to the local Verdaccio server at `http://localhost:4873`.

> **Note:** A `project.json` file provides an advanced way to define scripts, offering more flexibility than a traditional `package.json` for managing complex targets.

Setup local Verdaccio server to release NPM packages

Learn how to spin up a local NPM registry powered by Verdaccio to test deploy your NPM packages.

In TypeScript, developers often begin by defining the structure of their data using type definitions or interfaces, which is a powerful way to ensure type safety. However, as applications grow and become more complex, simply defining the shape of an object might not be enough to guarantee its consistent creation and behavior throughout the codebase. This often leads to situations where objects that are intended to be of a certain "type" might be missing crucial properties or have incorrect data, which can be difficult to track down and debug.

This lesson tackles the question of when and why to move beyond basic type definitions and embrace classes in TypeScript. It demonstrates how classes provide a more robust mechanism for defining object structure, enforcing type constraints, and ensuring consistent object creation. By establishing a clear blueprint for objects, classes not only improve compile-time type safety but also offer runtime benefits and better code organization, ultimately helping developers avoid common pitfalls associated with loosely structured objects in larger TypeScript projects.

Stop Avoiding Classes in TypeScript

Karabiner isn't only for your keyboard. It can also hijack your mouse buttons and enable them to be similar to layers on your keyboard, where holding down a mouse button can allow you to tap keys on your keyboard to trigger commands and macros that can completely revolutionize your workflows. For example, you can hold down the right mouse button and tap on R to go to references in VS Code. Or hold down the right mouse button and tap the left mouse button to chop up videos and Screenflow.

This completely unlocks a whole new world of possibilities and use cases for your mouse as you can hover your mouse over anywhere on the page. And just tapping keys on your keyboard allows you to trigger mouse actions, to trigger keyboard actions, or to trigger macros and applications and terminal commands. and anything that your imagination can come up with. 

Karabiner: Rethinking Right-Click as a Macro Command Center

Make an HTML table more readable on mobile devices by using the ::before pseudo-element. We add labels to each cell, so they appear like cards when the table is viewed on smaller screens. The ::before content is set using a data-label attribute for each cell to enhance mobile viewability without horizontal scrolling.



Create a mobile friendly table with the before pseudo-element

Learn to use CSS ::before pseudo-element for mobile-friendly HTML tables. Add labels to cells for enhanced readability on mobile, avoiding horizontal scroll.

Any app of a decent size has event flows and messages being passed around. At a certain point it becomes complicated to explain it through prose and you want to turn towards diagrams. Now setting aside the time to create diagrams that accurately describe what's happening in your codebase can be quite time consuming. Luckily, with today's AI tools, we can now just do basic walkthroughs with rough recordings over codebase dictating what's going on along the way and then upload that to tools like AI Studio and then ask it to generate diagrams in a text-based format such as Mermaid that will then generate the flowcharts and diagrams for us. So this video walks us through this process of recording a rough video, uploading it to AI Studio and then asking AI Studio to generate the proper Mermaid diagram syntax.

Generate Mermaid Flow Chart Diagrams with Gemini 2.0 from Rough Screen Recordings

I'm a diehard Karabiner user and anytime I start doing something repetitively I always move it into my Karabiner configuration. Sometimes I'll fall into scenarios where I want to trigger a command, but I also want to know if that command succeeded or failed. Since Karabiner can trigger any command, setting up the command is fairly straightforward, but knowing whether it succeeded or failed became much more difficult. Luckily for me there is a package called terminal-notifier that you can install from homebrew and you can pipe the output of your command to terminal-notifier. And have a seamless way of triggering your keyboard shortcut which runs a command and you can be notified of the results.

Use Karabiner to Trigger a Terminal Command and Get Notified of the Results

There are a lot of scenarios when inspecting a site in Chrome where you don't want any click events to fire and you don't want any scripts to run. Or maybe something is animating in and out of the page and you want to capture it at a certain moment. This is a great use case for pausing script execution, which is kind of using the debugger manually by going into the Chrome DevTools and the Sources tab and clicking the pause button to essentially pause the entire page. This will give you a chance to inspect any of the elements and styles you want to inspect. And you don't have to worry about fire and click events or anything that might interrupt your investigation into the elements and styles that you want to find.

Pause Script Execution in Chrome to Easily Inspect Elements

Gemini 2.0 has a context window of a million tokens, and this means that you can upload hundreds of files and allow it to inspect and analyze massive refactors across entire code bases. 

This lesson demonstrates concatenating an entire code base into a single file and then uploading it to AI Studio. Once within AI Studio, we ask it to find the types of tasks that it can evaluate for us. Then we select one of the tasks and ask it to generate instructions for that task. Once those instructions are complete, we then turn them over to Windsurf's Cascade agent, and we allow Windsurf's Cascade to do all of the work for us as we sit back, relax, and let the AI do our jobs.

Joel Lord

Search Results