Author: Duke

Docker & Docker Compose Commands I Keep Forgetting (Cheat Sheet)

I recently started building a side project and decided to use Docker Compose to manage my containers. While working on it, I noticed that there are quite a few commands I keep reaching for—and I wanted to have them written down somewhere.

In my day-to-day (9–5) work, I don’t use Docker extensively beyond the basic up and down commands, so some of the more advanced or less frequent commands tend to get rusty over time.

While refreshing my Docker and Docker Compose knowledge, I decided to collect all the commands I actually use and put them into one place. Think of this post as a personal cheat sheet—useful for quick debugging, reminders, or getting unstuck when something isn’t behaving as expected. Hopefully, it helps you too. 😊

Docker Compose Commands

Docker Compose allows you to define and run multi-container applications using a single configuration file, making local development and orchestration much easier.. These are the commands I use most.

Starting Services

These commands are used to start one or more services defined in your docker-compose.yml file, either in the foreground or background.

Start all services defined in docker-compose.yml:

docker compose up

docker compose up

Bash

Start in background (detached mode) – you get your terminal back:

docker compose up -d

docker compose up -d

Bash

Start services and force a rebuild of images (useful after changing a Dockerfile or dependencies):

docker compose up --build

docker compose up --build

Bash

Start specific service only:

docker compose up -d service-a

docker compose up -d service-a

Bash

or start multiple services at once:

docker compose up -d service-a service-b

docker compose up -d service-a service-b

Bash

Stopping Services

Use these commands to stop running containers, with options to either keep or completely remove them.

Stop all services (containers are stopped but not removed):

docker compose stop

docker compose stop

Bash

Stop and remove containers (this is what you usually want):

docker compose down

docker compose down

Bash

Stop, remove containers and volumes
⚠️ Warning: This deletes persisted data such as databases.

docker compose down -v

docker compose down -v

Bash

Stop specific service:

docker compose stop service-a

docker compose stop service-a

Bash

Restarting Services

Restarting services is useful after configuration changes or when a container becomes unresponsive.

Restart all services:

docker compose restart

docker compose restart

Bash

Restart specific service:

docker compose restart service-a

docker compose restart service-a

Bash

Viewing statuses

These commands help you quickly check which services are running and their current state.

List running containers for this project:

docker compose ps

docker compose ps

Bash

List all containers (including stopped):

docker compose ps -a

docker compose ps -a

Bash

Docker commands

In addition to Docker Compose, these core Docker commands are useful for inspecting and interacting with individual containers.

Executing Commands in Containers

These commands let you access a running container directly, which is especially helpful for debugging and inspecting the runtime environment.

Using an interactive shell

docker exec -it container_name bash

docker exec -it container_name bash

Bash

If bash is not available (for example, in Alpine images), use sh instead:

docker exec -it container_name sh

docker exec -it container_name sh

Bash

These commands let you enter a running container with an interactive shell, so you can inspect files, run commands, and debug things directly from inside the container.

Cleanup commands

Docker can accumulate unused containers, images, and volumes over time—these commands help keep your system clean.

Remove stopped containers, images or volumes:

docker container prune

docker image prune

docker volume prune

docker container prune

docker image prune

docker volume prune

Bash

or in case you need something more generic

docker system prune --volumes

docker system prune --volumes

Bash

which removes all unused resources, including volumes.

Removing Containers by Name Prefix

While setting up my project, I found some containers from old projects that i had probably forgotten to cleanup. Instead of removing them one by one, because they were a lot, I tried to find a command that removes all of them, by using their prefix (needless to say they were sharing the same prefix). The following command removed all containers with the prefix si:

docker rm -f $(docker ps -aq --filter "name=si_")

docker rm -f $(docker ps -aq --filter "name=si_")

Bash

Viewing Logs

Logs are often the first place to look when something isn’t working. These commands help you inspect service output, debug errors, and monitor behavior in real time.

docker compose logs
docker compose logs -f service-a # -f keeps streaming logs in real time
docker compose logs --tail=100 # Only the last 100 log lines

docker compose logs
docker compose logs -f service-a # -f keeps streaming logs in real time
docker compose logs --tail=100 # Only the last 100 log lines

Bash

So if you wanted to see logs for a specific container, in real time you could use

docker compose logs -f --tail=100 <container-name>

docker compose logs -f --tail=100 <container-name>

Bash

Copy Files From Container

docker cp container_name:/path/in/container ./local-path

docker cp container_name:/path/in/container ./local-path

Bash

`docker-compose` vs `docker compose`

You may see Docker Compose used in two different ways:

docker-compose
docker compose

They do the same thing, but they’re not the same tool.

`docker-compose` (Legacy)

Older, standalone CLI
Installed separately
Common in older projects and tutorials

docker-compose up -d

docker-compose up -d

Bash

`docker compose` (Recommended)

Built into the Docker CLI
Installed by default with modern Docker
Actively maintained and recommended

docker compose up -d

docker compose up -d

Bash

Which One Should You Use?

Existing projects: stick with whatever the project already uses

New projects: use docker compose

Quick Reference Card

This section provides a compact overview of the most commonly used Docker and Docker Compose commands for quick access.

╔═══════════════════════════════════════════════════════════════╗
║                 DOCKER COMMANDS QUICK REFERENCE               ║
╠═══════════════════════════════════════════════════════════════╣
║ COMPOSE                                                       ║
║   docker compose up -d          Start in background           ║
║   docker compose down           Stop and remove               ║
║   docker compose logs -f api    Follow service logs           ║
║   docker compose up --build     Rebuild and start             ║
║   docker compose exec api sh    Shell into service            ║
╠═══════════════════════════════════════════════════════════════╣
║ CONTAINERS                                                    ║
║   docker ps                     List running                  ║
║   docker ps -a                  List all                      ║
║   docker stop name              Stop container                ║
║   docker rm -f name             Force remove                  ║
║   docker exec -it name sh       Shell into container          ║
╠═══════════════════════════════════════════════════════════════╣
║ IMAGES                                                        ║
║   docker images                 List images                   ║
║   docker rmi name               Remove image                  ║
║   docker build -t name .        Build image                   ║
║   docker pull name:tag          Pull from registry            ║
╠═══════════════════════════════════════════════════════════════╣
║ LOGS & DEBUG                                                  ║
║   docker logs -f name           Follow logs                   ║
║   docker logs --tail 100 name   Last 100 lines                ║
║   docker inspect name           Full container info           ║
║   docker stats                  Resource usage                ║
╠═══════════════════════════════════════════════════════════════╣
║ CLEANUP                                                       ║
║   docker system prune           Remove unused                 ║
║   docker system prune -a        Remove all unused             ║
║   docker volume prune           Remove unused volumes         ║
║   docker system df              Check disk usage              ║
╚═══════════════════════════════════════════════════════════════╝
```

╔═══════════════════════════════════════════════════════════════╗
║                 DOCKER COMMANDS QUICK REFERENCE               ║
╠═══════════════════════════════════════════════════════════════╣
║ COMPOSE                                                       ║
║   docker compose up -d          Start in background           ║
║   docker compose down           Stop and remove               ║
║   docker compose logs -f api    Follow service logs           ║
║   docker compose up --build     Rebuild and start             ║
║   docker compose exec api sh    Shell into service            ║
╠═══════════════════════════════════════════════════════════════╣
║ CONTAINERS                                                    ║
║   docker ps                     List running                  ║
║   docker ps -a                  List all                      ║
║   docker stop name              Stop container                ║
║   docker rm -f name             Force remove                  ║
║   docker exec -it name sh       Shell into container          ║
╠═══════════════════════════════════════════════════════════════╣
║ IMAGES                                                        ║
║   docker images                 List images                   ║
║   docker rmi name               Remove image                  ║
║   docker build -t name .        Build image                   ║
║   docker pull name:tag          Pull from registry            ║
╠═══════════════════════════════════════════════════════════════╣
║ LOGS & DEBUG                                                  ║
║   docker logs -f name           Follow logs                   ║
║   docker logs --tail 100 name   Last 100 lines                ║
║   docker inspect name           Full container info           ║
║   docker stats                  Resource usage                ║
╠═══════════════════════════════════════════════════════════════╣
║ CLEANUP                                                       ║
║   docker system prune           Remove unused                 ║
║   docker system prune -a        Remove all unused             ║
║   docker volume prune           Remove unused volumes         ║
║   docker system df              Check disk usage              ║
╚═══════════════════════════════════════════════════════════════╝
```

Bash

Do you have any Docker or Docker Compose commands that have saved you in tricky situations, or ones you use every day?
Feel free to share them—we’d love to expand this cheat sheet with more real-world examples.

January 22, 2026

Naming Conventions: How to Name Your Components Without Fighting Your UI Library
At some point in pretty much every project, whether you’re setting up the infrastructure or introducing an important library that will be used throughout your app, you run into a tiny problem that turns out not to be so tiny: naming conventions.

Let’s take a classic example.

You need a <Modal />.
Your UI library already has a <Modal />.

So you open a file and write the imports, and suddenly you’re staring at something like this:
```
import { Modal } from "@heroui/react";
import { Modal } from "./my-components/Modal";
```
JavaScript
You see? You’re not the only one thinking Modal is a great name for a component about… well, a modal! In my case, I liked the name, but the developers building the HeroUI library also liked it.

Now you have a small issue: how are you going to denote that a modal is one of yours, or that it’s imported from your UI library?

In this example you’re probably thinking, “Well, maybe I’ll just rename one.” Obviously. Maybe <HeroModal />. Maybe <MyModal />. It works, JavaScript has no issues, TypeScript stops complaining, and you move on.

The problem with this approach is that your code may start feeling noisy after a while. Not broken, but slightly uncomfortable. You might see different files using different aliases, which isn’t the best approach. This increases your cognitive load because you have to remember things instead of intuitively understanding them.

That’s usually when people think the issue is naming.

It’s not.

What’s actually happening is that two completely different ideas are being treated like they’re the same thing.

A library modal is just a tool. It renders a dialog, handles focus, animates, and gets out of the way.

A modal in your app has meaning. It shows up for specific reasons. It follows product rules. It has opinions.

Once you see that difference, naming stops being a guessing game.

To avoid all this headache, the best thing you can do is stop for a bit, think about your approach, and decide what naming convention—a pattern, if you’d like—will help you intuitively understand what’s going on in your app without having to scroll up to your imports every time you see a component used.

Naming convention 1: Your app owns “Modal”, the library is the “Base”

This is the easiest convention, the one you probably thought about first. The idea behind this is:
- Your app gets to use the “clean” name Modal
- The UI library gets a more technincal name: ModalBase
Example
```
import { Modal as ModalBase } from "@heroui/react";
```
JavaScript
Then inside your component’s implementation would be:
```
function Modal(props) {
  return <ModalBase {...props} />;
}
```
JavaScript
Other examples for naming your components using this convention could be
```
<ModalBase />

<BaseModal />

<HeroModal /> // (library-prefixed)

<ModalCore />

<UIModal />

<ModalRaw />

<RawModal />
```
JavaScript
Pros
- ✅ Everyone on your team can use <Modal /> without worrying about where it came from.
- ✅ If you ever change your UI library, you only change this wrapper, not your whole codebase.
- ✅ Great for beginners because it keeps things simple and consistent.
Cons
- ❌ If your wrapper grows too much, it can become “magic”. Teammates may not be able to understand why the modal has more complex logic implementation
- ❌ You must be disciplined with naming
Naming convention 2: Name your modals based on what they actually do

In this case you skip the generic name and instead name your modals based on what they are doing. This is helpful for large codebases, not small side projects.

Examples of that could be:
```
<EditProfileModal />

<DeleteAccountModal />

<InviteUserModal />

<SettingsModal />

<ShareModal />

<ConfirmActionModal />

<FeedbackModal />
```
JavaScript
Pros
- ✅ Very clear meaning – you know what <DeleteAccountModal /> does just by reading it.
- ✅ Great for beginners – easier to understand than a generic <Modal /> everywhere.
Cons
- ❌ Can repeat logic – if all modals need the same props or behavior, you might duplicate code.
- ❌ Too many similar names – if you have lots of modals, the list can get long and harder to scan.
Naming convention 3: Use prefix or suffix to show ownership

If the word Modal confuses you because you are not sure where it came from, which is a valid point, you could ignore using the word Modal by itself and instead decide on a good suffix/prefix identifier.

For your UI library component:
```
<AppModal />

<ProjectModal />

<MainModal />

<CoreModal />

<ClientModal />

<CustomModal />

<ETModal /> // Prefixing your modal with your app's initials e.g Energy Tracker app
```
JavaScript
For your App component:
```
<HeroModal />

<LibModal />

<UIModal />

<ModalLib />
```
JavaScript
Pros
- ✅ Very explicit – you can tell at a glance which modal is from your app vs the library.
- ✅ Works well in mixed environments – e.g. multiple UI libraries, monorepos, shared packages.
Cons
- ❌ Names get longer – <AppModal />, <HeroModal /> are not as clean as <Modal />.
- ❌ Can become inconsistent – if people invent new prefixes (<BaseModal />, <CoreModal />, <MainModal />) without a rule.
Naming conventions that usually cause trouble

Most teams try at least one of these at some point.

MyModal sounds harmless but doesn’t mean anything to anyone else.

CustomModal stops being descriptive the moment you have more than one.

Library-branded names everywhere tie your feature code to a vendor, even when it shouldn’t care.

Versioned names like Modal2 or NewModal are usually a sign that a decision was postponed, not solved.

All of them work… until they don’t.

A simple question that keeps things clean

When naming feels hard, this question usually cuts through the noise:

Is this a basic UI building block, or does it express actual product behavior?

If it’s a tool, name it like one.
Example: <ModalBase />, <InputPrimitive />, <ButtonCore />.

If it’s intent, name it like intent.
Example: <EditProfileModal />, <CreateProjectForm />, <DeleteAccountModal />.

That’s the whole trick. You’ll know you’ve landed in a good place when your imports start feeling calm again:

Wrapping up

Naming might look like a small detail, but it affects how your whole project feels. Usually when I’m building a project and it’s time to decide on a UI library, I don’t want to spend time trying to identify names — I just start using whatever the import gives me and continue.

The problem is that after a while I usually find myself needing to refactor because my app is getting more complex. You might say, “Well, it’s fine, you’re following the simple-now, refactor-later idea,” and you might be right. There’s a principle in programming, called YAGNI, that says you shouldn’t build complex systems just in case. You build infrastructure when you know you will need it soon.

This applies directly to naming conventions.
If you’re building a small side project just for fun, go ahead and use the UI library names like <Modal /> and skip the wrappers.

But if you’re building an app you plan to present, monetize, or seriously grow, then stop for a moment, decide on your conventions, and then continue. The time you spend choosing now will be far less than the time you’ll lose later dealing with refactors and headaches.

If you’re just getting started with app development, naming conventions are one of those topics that only start to matter after your environment is properly set up. If you’re still at that stage, you might find these guides useful before diving deeper into UI architecture:
– How to install Git on macOS
– How to install Homebrew on macOS
– How to install npm on macOS
– How to install PostgreSQL on macOS
– How to install Java on macOS
December 23, 2025
How to Install Java on Mac: Step-by-Step Guide
If you’ve ever tried running a Java program on a Mac without setting anything up, you’ve probably seen an error about a missing Java Runtime. That’s because, unlike JavaScript, Java doesn’t come built into your computer — you need to install a Java Development Kit (JDK) first.

In this guide, we’ll go step by step:
- Check if Java is already installed (so you don’t install it twice by mistake)
- Learn what a JDK kit is and why most developers use it
- Install Java on a Mac using either Homebrew or the official Oracle download
- Set up your environment so the java command works anywhere in your terminal
- Verify the installation, uninstall if needed, and fix common issues
Whether you’re new to Java or just coming from another language like JavaScript, this guide will give you a clear path to getting Java up and running on macOS.

Check if Java is Already Installed

Before installing Java, it’s worth checking if it’s already on your Mac. Maybe you’re not on your personal machine, or you installed it months ago for a side project and completely forgot.

To check if Java is already installed:
1. Open your Terminal
2. Type java -version
3. If Java is installed, you’ll see something like:
```
OpenJDK version 11.x
```
Bash
If it’s not installed, you’ll get a message like:
```
The operation couldn’t be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.
```
Bash
If you see the “Unable to locate” message, don’t worry — just continue with this guide to install Java on your Mac.

What is a JDK?

If this is your first programming language, or if you’re like me, coming from another one — in my case, Javascript — you might not know much about the Java ecosystem. And honestly, you don’t really need to at first, right?

Still, because of assumptions, you might expect the installation to be as simple as running brew install java. But when you look it up, you’ll quickly see that the recommended way is to install a JDK instead. Before we continue, let’s take a quick look at what that actually is.

JDK – Java Development Kit is an open-source implementation of Java, maintained by big tech companies such as Oracle, Red Hat, and others.

When we refer to an open-source implementation, it simply means software built according to official rules. In this case, the rules come from the Java SE Specification.

So what does the JDK provide? It contains:
- Compiler – turns your .java files into an executable form called bytecode.
- Runtime (JVM) – executes that bytecode on any computer (Windows, Mac, Linux, etc.).
- Standard library – a huge set of built-in tools to help you out with your code.
It essentially has everything you need to use Java on your machine. The JDK is considered an essential tool for developers working with Java, and the OpenJDK project and Oracle distribute it.

Install Java on Mac

You can install Java on macOS in two main ways:
1. Install Using Homebrew – quick and beginner-friendly
2. Install by Downloading from Oracle
If you’re new to Java or simply want the fastest setup, the Homebrew method is the best choice. (We have a separate post that walks you through installing Homebrew if you don’t have it yet.)

In this guide, we’ll use the Homebrew method.

To find out which is the latest version of Java, you can visit this page.

Install Java using Homebrew

To install Java using Homebrew:
1. Update Homebrew
  Open your terminal and run: brew update
  This makes sure you’re working with the latest package list.
2. Install OpenJDK 21
  After updating, run:
  brew install openjdk@21
3. Verify installation
  Open your terminal and run:
```
java -version
```
Bash
At the time of writing this guide, version 21 is the latest long-term support (LTS) release. If you want to install a different version, just replace 21 with the version number you need (for example, openjdk@17).

Optional: Read More About the Package
You can check out the official Homebrew formula page for OpenJDK here.

Set JAVA_HOME Environment Variable

After installing OpenJDK, you could have tried to verify the installation and found out that you still get
```
The operation couldn’t be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.
```
Bash
In that case, you will need to add the Java home directory to your PATH. Since we installed OpenJDK@21, the command to add this to our PATH is
```
echo 'export PATH="/opt/homebrew/opt/openjdk@21/bin:$PATH"' >> ~/.zshrc
```
Bash
You’ll also see this message in the Homebrew installation logs for OpenJDK, near the end of the process.

What this command essentially does is prepend the existing list of paths with the directory where OpenJDK is installed. So when you ask it to run a java program, it will search first there.

If you installed a different version, change the version accordingly to the command above.

Verify Installation

To verify our installation regardless of the method we used we should type java --version. By now you should be seeing
```
➜  ~ java -version
openjdk version "21.0.8" 2025-07-15
OpenJDK Runtime Environment Homebrew (build 21.0.8)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.8, mixed mode, sharing)
```
Bash
Uninstalling Java (Homebrew)

If you want to remove a specific version of OpenJDK installed via Homebrew, run:
```
brew uninstall openjdk@21
```
Bash
Checking Installed Versions

To see all the Java versions (and other packages) you currently have installed, run:
```
brew list --versions
```
Bash
You might see something like this:
```
...
openjdk@17 17.0.12
openjdk@21 21.0.4
...
```
Bash
This means you have both Java 17 and Java 21 installed on your system.

Choosing an IDE for Java

Now that you’ve installed Java, the next step is picking an Integrated Development Environment (IDE) to support your learning. An IDE helps you compile code, catch mistakes, and debug programs more easily — making your path to mastering Java smoother.

Some popular free choices include:
- IntelliJ IDEA Community Edition, published by JetBrains. This is my personal recommendation, since it’s beginner-friendly and offers a free edition.
- Eclipse, maintained by the Eclipse Foundation
- NetBeans, maintained by the Apache Foundation
Pick one of these tools, set it up, and you’ll be ready to start coding your very first Java programs with confidence!

Troubleshooting Common Issues

Below are some common issues you might face when installing or using Java on macOS.
If you’re dealing with a different problem and haven’t figured out the solution, drop it in the comments — we’ll try to help you out.
Also, if you’ve solved a tricky Java issue yourself, share it in the comments so other readers can benefit too.

Wrong Java Version Running

Cause: Multiple Java versions are installed, and the wrong one is first in your PATH.
Fix: Check which Java is being used
```
which java
```
Bash
Then adjust your PATH so the version you want comes first. You can do that by typing:
```
export PATH="/opt/homebrew/opt/openjdk@<version-you-want>/bin:$PATH"
```
Bash
brew install fails

Cause: Homebrew may be outdated or missing.

Fix: Update Homebrew:
```
brew update
```
Bash
If Homebrew is not installed, see our homebrew installation guide.

java Command Not Found

Cause: OpenJDK is installed but not linked to your environment.

Fix: Link the installed version so the java command is available:
```
brew link --force --overwrite openjdk@21
```
Bash
If you installed a different version, replace 21 with that version number.
November 14, 2025
Am I Too Old to Learn Coding?
I have to say, this is a question I’ve been hearing for a long time since I got into the web development world. It’s a very common question, so please don’t feel like you’re alone when asking it. Many people are in your shoes and wonder the exact same thing.
This question is probably not just about coding, but about change in general. Deep down, the question might not be “Am I too old to learn coding?” but rather “Am I too old to change?” Let’s explore this together.

For those of you looking for a TLDR answer: No! You are not too old!
But I’m quite sure that doesn’t fully convince you—so let me explain.

My Late Start in Web Development

Here’s a short story about me, just so you know we might have been walking a similar path.

I’m not 100% a tech person. I didn’t study Computer Science or anything related when I finished school. I started working in a completely different field—sales in supermarket goods. At some point, I went on to take an MSc in Information Systems, a program designed for non-tech people. It had no coding lessons related to web development.

I discovered web development while browsing sites like Coursera and edX—and I loved it. I was in my mid-30s at the time, and I asked myself the same question: Am I too old to learn coding? Let me tell you what I found out.

By the way, I’ve been working as a web developer for the past 7 years. So yes—there are success stories out there, and yours can definitely be one of them too!

You’re Not Starting from Zero

This is 100% true—you’re not starting from zero. You might be thinking, “But I have no experience with programming. How can that be true?” Well, even if you’re new to coding, programming is about more than just writing code.

While you’ll focus on technical skills when learning for a job, that’s only part of what you’ll need to succeed in tech. Like any job, being a good developer also depends on other important skills, such as:
- Soft skills – How you communicate and work with your team.
- Product skills – How well you understand product requirements and how they should be built.
- People skills – How you interact with clients and stakeholders (the people asking for new features).
- Organizational skills – Coding isn’t just about typing code. It’s also about planning your work, breaking it into smaller tasks, staying focused, and delivering on time.
- Life balance skills – Avoiding burnout, keeping a healthy routine, getting enough rest—these all matter too.
You might think this sounds like a lot—but it’s all true. If you want to grow into a great developer, you’ll need to develop more than just technical knowledge.

From what I’ve seen, the best developers aren’t always the ones who know every new framework or advanced technique. They’re often the ones who are humble, reliable, and great team players.

So if you feel like you have nothing to offer—think again!
You already have experience, even if it’s not from the tech world.
- If you’ve been a taxi driver, you’ve learned how to stay patient and handle people in all situations.
- If you’re a mother, you’ve mastered multitasking and managing emotions—skills that come in handy at work too, especially with your managers!
- If you’ve been a gardener, you probably have a great eye for detail and know how to focus on repetitive tasks.
Every job teaches you something valuable.
So now that we’ve cleared that up — you are skilled, let’s talk about age…

Too Old Compared to What?

This is one of the most common — and most unrealistic — comparisons: “Am I too old?” Too old compared to who?

Are you 15? Then yes, you’re older than a 5-year-old.
Are you 65? Then sure, you’re older than someone who’s 30.

But here’s the real question: You know who you’re younger than?
The version of you a few years from now. I mean you can choose to start learning now—whether you’re in your teens, your 40s, or your 70s.
Or you can wait… and reach your 30s, 60s, or 90s having never started.

So what’s the difference between the version of you who starts learning and the one who doesn’t?

Time will pass either way (Even Gandalf doesn’t help here).

Both versions of you will grow older. But only one will arrive at that next age with a new skill—or even a new career.

So why not start your path right now? Of course, you could avoid it. You could push it away.

What’s the Alternative?

Well, there is one—and it’s a bit grim. I asked myself the same thing when I was wondering, “If I’m too old, what does that really mean?” The answer? You can just wait—wait until death comes sometime in the far future.

Don’t fight for your dreams! Just don’t!

Yes, do nothing. Don’t fight for your dreams. Don’t live the life you want. Don’t start learning and keep learning until you have no energy left. Just stay where you are and let time pass. Eventually, your journey will end.

Does that sound like something you would actually do? No, right? Because in reality, there is no real alternative. You either try — or you don’t. You could try and realize it’s not something you enjoy. Or you could find out it’s something that changes your life — because it turns out to be something you truly love doing.

The Learning Curve: Yes, It’s Real – and Beatable

Ok, now we’re getting somewhere. But is it hard? Will you have tough times? Will you make it through?

Well, I have to be honest — being a programmer is a great profession to be in. Some of its advantages are:

Continuous learning—which can sometimes feel like a disadvantage too.

Great compensation, especially if you’re working fully remote.

Remote flexibility—wherever your laptop goes, you can go.

But it’s not all sunshine. Like any career, programming has its own set of challenges. In my opinion, the two most challenging aspects are the steep learning curve and impostor syndrome.

You might want to reflect a bit before diving in and ask yourself: Is programming really for me? If you’re unsure, don’t worry—we’ve got you covered with a post comparing its pros and cons in more detail.

Let’s talk about the learning curve first. It’s steep. You will feel overwhelmed—sooner or later. That depends on your personality, energy, and life situation. If you’re going through a tough period, it may hit harder.

Why is it so steep? Because there’s so much to learn—and even while learning, you may catch yourself thinking, I don’t know enough. Let me stop you right there: you will never know everything. And that’s perfectly normal.

When I first started, that exact fear hit me hard—How will I ever learn it all? Then I came across a tweet that changed my perspective. It went something like this:

Beginner programmers are anxious because of their uncertainty. Senior programmers find peace in the fact that they’ll never be certain.

That moment was eye-opening for me. I realized: this is just the nature of the game. No one knows everything—and that’s OK. The only thing that truly matters is to show up, keep learning, and keep having fun.

If you can combine fun with perseverance, you won’t lose — I promise.

But even if you’ve got the patience and the motivation to start… is there still a chance this might not work out?

What’s the Worst That Could Happen?

Let’s be honest—there’s always a worst-case scenario. It might look different for each of you, but I’ll try to cover a few common ones that apply to many people starting this journey.

What If You Love Coding but Still Can’t Get a Job?

Yes, this is a tough one. I’ve seen it happen, and I’ve been there myself. Let me tell you how I dealt with it.

When I first started applying for jobs, all employers saw on my CV was: sales, sales, and more sales. No one trusted me because I had no experience. Classic case of “no experience, but no way to get it either.”

At that point, I saw two possible options:
- Get a non-paid internship
- Start building a portfolio with real projects (like websites for friends, local businesses, or anything you can find)
For me, the internship route worked. I landed a 6-month unpaid internship that offered the chance for paid work afterward. Financially, it was a tough decision. But I took it—and it changed everything.

Suddenly, my CV didn’t just say “sales.” It showed real web development experience. The next time I applied for a job, I imagine employers were thinking, “Well, if he managed to work in one company, maybe he can work for us too.”

The day I started that internship was a great one.

What If You Try Coding and Don’t Like It?

This is another real possibility. Not everything is for everyone. Maybe you love the thrill of the first lessons, but later you feel overwhelmed, bored, or just not that into it.

There are two ways this can go:
- You’re just hitting a tough spot and need to push through
- Or you’ve genuinely discovered that coding isn’t for you
If it’s the second one, that’s perfectly fine. You’ve now stopped wondering, “Am I too old to learn coding?”—because you’ve answered a more important question: “Is coding for me?”

And honestly, that’s a win too. Knowing what’s not for you is just as important as finding what is. Now you can move on to your next adventure, with no regrets—because you tried.

You may also like 🎬
Is HTML a Programming Language? Find Out Now!
December 9, 2024
The Truth About CSS: Is It Really a Programming Language?
February 20, 2025
Unmasking Impostor Syndrome In Tech: Watch Out For These Signs
July 9, 2024
The Burnout Syndrome – How to Identify and Overcome It
August 10, 2024

Ready to Start? Let’s Talk About Where to Begin

So, now that you’re (hopefully) feeling more confident—not because there’s nothing to fear, but because you’re ready to commit even with those fears—where do you start?

Well, I can only speak for web development, not every path in programming.

Think of coding like becoming a doctor—there are many different specializations, and no one can explain them all at once. Don’t like that comparison? Try this: imagine walking into a chocolate shop for the first time. How do you figure out what you like? Simple—you start tasting.

From my point of view, the fastest route to getting a developer job is through frontend development.

In case you don’t know, a frontend developer is the person who builds what users see and interact with on a website. I believe it’s the quickest path because you can learn a few core building blocks and start seeing results fast. You’ll be able to create things, show them to potential employers, and feel a sense of progress early on.

This means faster feedback, less overwhelm, and a shorter path to your first job.
November 7, 2025
Why are internet cookies called cookies?
I am sure you have heard of cookies 🍪 no matter how many hours you’ve spent learning programming, or even if you are just a casual user unrelated to the tech world. You’ll see this term used all over the Internet. It’s usually the first thing that pops up when you visit a site for the first time. The site requests that you agree to cookies and explains how it uses them.

A good percentage of internet users often portray cookies as harmful. Mostly because people feel that someone is tracking their behavior while visiting a site — and yes, to some extent, this is true. But have you ever stopped to wonder: why are internet cookies called cookies? Why not use some other kind of delicacy? Like tarts or donuts? 🤭

The Cookie Monster – Sesame Street

The Legacy of Montulli’s Internet Cookies

To fully answer why are internet cookies called cookies, we need to start with Lou Montulli, one of Netscape’s founding engineers.

In 1994, Montulli introduced browser cookies as a technical solution to a frustrating problem: websites had no memory. Each time you loaded a new page, the website had no idea who you were or what you’d done moments earlier — it couldn’t remember if you had logged in, or what items you’d placed in your shopping cart. This limitation made building useful, user-friendly web experiences nearly impossible.

Lou Montulli

Montulli’s solution was simple. He stored small pieces of data in your browser. These allowed websites to “remember” things between visits and page loads. This idea — storing small amounts of information to improve the user’s experience — became a turning point in the history of the web.

But why are internet cookies called cookies and not something else? Montulli himself has explained that while he was brainstorming, he recalled a term from his college days in computer science: “magic cookies.”

As mentioned in Montulli’s blog post

I had heard the term “magic cookie” from an operating systems course from college. The term has a somewhat similar meaning to the way Web Cookies worked and I liked the term “cookies” for aesthetic reasons. Cookies was the first thing I came up with and the name stuck.
Lou Montulli

Many say Montulli also drew inspiration from fortune cookies 🥠 — little treats containing small hidden messages. Similarly, browser cookies contain small packets of information about the user. However, Montulli clarified that the fortune cookie analogy was secondary; the real naming influence came from established computing terminology.

Magic cookies, LSD, and Unix users

The term “magic cookie” existed long before internet cookies, and understanding this connection helps clarify why are internet cookies called cookies today.

In programming, systems often pass a magic cookie — a small piece of data — between each other as a kind of identifier or token. The recipient doesn’t care what’s inside the cookie. Programmers took this idea from early computing.

The term magic cookie appears in the Unix Programmer’s Manual. It helps explain how functions like ftell() and fseek() track file positions using seemingly random numbers. To many programmers, these cookies felt like magic because they just worked.

ftell returns the current value of the offset… It is measured in bytes on UNIX; on some other systems it is a magic cookie, and the only foolproof way to obtain an offset for fseek.
Unix documentation

Montulli liked the term “cookies” partly because of this existing technical jargon and partly because of its playful, light-hearted sound.

For added flavor, some point to the 1970s hacker culture, Unix communities, and counterculture comics like Odd Bodkins by Dan O’Neil. In these circles, magic cookies were tokens with mysterious, sometimes surreal, properties — much like the arbitrary bits of data passed between systems.

So, when asking why are internet cookies called cookies, the answer is clear. It comes from a blend of technical tradition, playful naming, and Montulli’s own preferences.

The Cookie Monster Connection 🍪

It’s hard to discuss cookies without mentioning Cookie Monster from Sesame Street. He devours cookies mindlessly. Browsers behave in a similar way, silently gobbling up cookies in the background. This connection is mostly playful. Still, it helped reinforce the idea of “cookies” being small, harmless, and consumed without much thought. That light-hearted image made the term easier for people to accept at the time.

Why Are Internet Cookies Called Cookies? — A Quick Recap
- Lou Montulli introduced browser cookies in 1994 to give websites “memory.”
- He drew on the existing programming term “magic cookies” as inspiration.
- The term “cookies” was already familiar in tech, playful, and non-threatening.
- Fortune cookies served as a fitting metaphor but weren’t the primary reason.
- Why are internet cookies called cookies? Because it combines tech history with simplicity and charm.
While researching for this post, I stumbled upon an insightful Youtube video discussing hidden heroes like Montulli created by Netguru. I recommend giving it a watch as it delves deeper into Montulli’s journey in pioneering the first-ever cookies.

If you’re into history-related programming trivia, you might also enjoy this post about the origin of the word “bug” in programming. It’s another quirky and surprising piece of tech history that shows how language shapes the tech world we live in today.
September 26, 2025
MacOS Shortcuts – Cheatsheet for New Users

If you’re a new Mac user (like me!), knowing a few common shortcuts can save you tons of time. Here’s a simple cheatsheet of macOS shortcuts — including some of the ones I’ve searched for myself.
You might want to bookmark this — I’ll keep adding more as I come across new and useful shortcuts.

🔄 Basic Editing MacOS Shortcuts

👨‍💻 Developer – Focused macOS Shortcuts

💻 Productivity MacOS Shortcuts

🔤 Other Useful Shortcuts

Since I’m still fairly new to macOS after switching from Ubuntu Linux, I’ve been collecting these shortcuts to help myself — and hopefully to help you too.

You might also find other posts where I share not just shortcuts, but tips for developers and guides on installing tools or setting things up on macOS. These aren’t just for Mac beginners — they’re for anyone adjusting to new workflows. Feel free to check them out here.

September 19, 2025

Husky Hooks: The Easy Way to Improve Your Project Workflow

We all miss stuff sometimes — skipping a test run, forgetting to lint, or pushing code that breaks something.
Yes, guilty as charged! Husky hooks help you catch those issues early by running scripts right when you commit or push. 🐶
It’s a simple way to keep your workflow clean, lower the pressure, save time, and avoid nasty surprises later.

Introduction: Why use Husky hooks in your project?

Husky is a great tool to help you out when working on a project and being proactive. It can catch problems before they are committed and make it into your codebase.

How? By running scripts like tests or linters when committing or pushing your code. It’s a simple way to enforce code quality.

But why not just use native Git hooks or a CI tool like CircleCI or GitHub Actions, you might wonder… and honestly, that’s a fair question — I asked the same thing when I first came across Husky.

The answer really comes down to when you want to catch issues in your code, and whether you’re comfortable setting up native Git hooks or working with a team where shared, versioned hooks make more sense.

Do you want to wait for your CI tool to run all steps just to tell you a test failed or a semicolon was missing?
Or would you rather know right away, before even pushing your code? ⚡

What are you waiting for if you’d like to catch issues immediately? 🚀
Let’s go ahead and install Husky and learn more about this cool tool! 🛠️🐶

Installing and initializing Husky in your project

Installing Husky is straightforward; you just type in your terminal

npm

npm install --save-dev husky

Bash

Or (if you are using yarn)

yarn

yarn add --dev husky

Bash

Now that we’ve installed the package, let’s go ahead and initialize it by typing:

Bash

npx husky init

Bash

Initializing Husky does the following:

creates a .husky directory in your project, which includes:
- a pre-commit hook file
- a _ subfolder for additional settings.
Adds a prepare script to your package.json file to ensure Husky is set up when dependencies are installed.

.husky/pre-commit

The pre-commit file is a Git hook managed by Husky. It runs automatically before each commit, allowing you to run scripts like linters or tests to catch issues early.

When Husky initializes its structure, it adds the following content to this hook file:

pre-commit

npm test

Plaintext

This basically means that whenever you are running your git commit command, Husky will first run npm test. If the tests pass, the commit will go through. If they fail, the commit will be blocked, and you’ll need to fix the errors before trying again.

When I tried this in a brand-new project by making a simple change and committing it, here’s what I saw:

git commit -m "A simple change to see pre-commit hook"

> [email protected] test
> jest

 PASS  src/pages/hello.test.ts
 PASS  src/components/heading.test.tsx

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        0.491 s, estimated 1 s
Ran all test suites.
[playground c6e4aaf] A simple change to see pre-commit hook
 2 files changed, 5 insertions(+), 1 deletion(-)
 create mode 100644 .husky/pre-commit

Bash

See? It ran the two tests included in my project and then finalized the commit process.

.husky/_ folder

This folder is created by Husky and contains setup code that helps your Git hooks run smoothly across different systems.

You usually don’t need to touch anything here — it just works in the background to support the other hook files.

prepare script

When you set up Husky, it adds a prepare script to your package.json file:

package.json

"scripts": {
  "prepare": "husky install"
}

JSON5

This script makes sure git hooks are installed whenever someone installs your project’s dependencies (e.g., by running npm install or yarn install).

This could come in handy if you are sharing your project with a team. The prepare script will ensure Husky works automatically for everyone without any extra steps needed.

Expanding pre-commit: Catch more before it hits your repo

Although running tests before committing is what Husky suggests by default when it initializes, I personally find that a bit too much. It feels like a blocker when all I want is to make a quick commit to save my progress. So instead of leaving npm run test in the pre-commit file, I prefer to remove the testing and go with simpler, quicker checks at that point.

Before we change our pre-commit file, I just want to share a quick tip — did you know you can test Husky hooks without having to write a new commit message every single time?

Good news: you can do exactly that by adding a simple line at the end of your pre-commit file.

pre-commit

npm test

exit 1

Plaintext

exit-1 will stop the script from continuing, which makes it a safe way to test your pre-commit commands without actually committing your changes.

Hook for linting checks

Go to your .husky folder and open the pre-commit file replace its content with:

pre-commit

echo "🐶 Executing pre-commit hook..."
echo ""

# Run lint on staged files

echo "🔍 Running ESLint on staged files..."

npx eslint .

echo "✅ ESLint passed."

Plaintext

By doing this, we’ve added ESLint checks right before committing — simple as that!

To make sure it works, try committing some new changes, and you’ll see the results show up right in your terminal.

🐶 Executing pre-commit hook...

🔍 Running ESLint on staged files...
✅ ESLint passed.

Bash

Awesome, right? No linting errors! 🎉
But what if there were some? What would that look like?

I added a small linting issue (couple of spaces) to test it, and here’s what showed up when I ran it again:

🐶 Executing pre-commit hook...

🔍 Running ESLint on staged files...

/my-project/src/components/Heading.test.tsx
  6:5  error  Delete `··`  

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Bash

All that’s left now is to fix the issue and commit the changes successfully. ✅

Hooks to catch console.log statements

Now that we’ve got linting checks in place, why not expand them a bit and catch things we definitely don’t want sneaking into our code — like console.logs maybe?

Just add the following content to your pre-commit file:

pre-commit

echo "🐶 Executing pre-commit hook..."
echo ""

# Run lint on staged files

echo "🔍 Running ESLint on staged files..."

npx eslint .

echo "✅ ESLint passed."
echo ""

# Match staged JS/TS files
FILES_PATTERN='\.(js|ts)(x)?$'

# Disallowed patterns: console methods
FORBIDDEN='(console.log)'

echo "🔎 Checking staged files for forbidden patterns (e.g. console.log)..."

# Scan staged files for forbidden patterns
if git diff --cached --name-only --diff-filter=ACM | \
    grep -E "$FILES_PATTERN" | \
    xargs grep --with-filename -n -E "$FORBIDDEN" | \
    grep -v '^\s*//'; then

    echo ""
    echo "🚫 COMMIT REJECTED! Found forbidden patterns"
    echo "😅 Please clean them up before committing."
    echo ""
    exit 1
fi

echo "✅ No forbidden patterns found!"
echo "✅ Git pre-commit hook passed. You're good to go 🚀"

exit 0

Plaintext

Let’s check what each part does

echo is a command used to print informational messages in the terminal — basically just outputting text so we can see what’s happening.

exit 0 means the script completed successfully, while exit 1 signals an error or that something failed.

Next, we see:

pre-commit

# Match staged JS/TS files
FILES_PATTERN='\.(js|ts)(x)?$'

# Disallowed patterns: console methods
FORBIDDEN='(console.log)'

Plaintext

In this part, by using FILES_PATTERN, we’re basically saying we only want to match files with the extensions .js, .jsx, .ts, or .tsx — and yep, you guessed it, I’m working in a project that’s transitioning from JS to TS!

The next constant, FORBIDDEN, defines what I don’t want slipping into my commits — for now, that’s just console.logs.

The next part is the trickiest one:

pre-commit

if git diff --cached --name-only --diff-filter=ACM | \
    grep -E "$FILES_PATTERN" | \
    xargs grep --with-filename -n -E "$FORBIDDEN" | \
    grep -v '^\s*//'; then

    echo ""
    echo "🚫 COMMIT REJECTED! Found forbidden patterns"
    echo "😅 Please clean them up before committing."
    echo ""
    exit 1
fi

Plaintext

It’s a loop that goes through all the staged files and checks each one against every pattern we’ve defined, like console.log. If it finds a match, it prints an error message showing the file and the exact pattern it caught.

Otherwise, it lets us know everything’s clean and we’re good to move forward with the commit:

pre-commit

echo "✅ No forbidden patterns found!"
echo "✅ Git pre-commit hook passed. You're good to go 🚀"

Plaintext

To test this script, I added a console.log to one of my files, just to see what it would print when running this hook

🐶 Executing pre-commit hook...

🔍 Running ESLint on staged files...
✅ ESLint passed.

🔎 Checking staged files for forbidden patterns (e.g. console.log)...
src/components/Heading.test.tsx:6:    console.log('test');

🚫 COMMIT REJECTED! Found forbidden patterns
😅 Please clean them up before committing.

Bash

After fixing that and removing the console.log, I ran it again and saw everything passed — no errors, no blocks. Just a smooth, satisfying commit! 🙌

🐶 Executing pre-commit hook...

🔍 Running ESLint on staged files...
✅ ESLint passed.

🔎 Checking staged files for forbidden patterns (e.g. console.log)...
✅ No forbidden patterns found!
✅ Git pre-commit hook passed. You're good to go 🚀

Bash

This script could easily be expanded to catch all console methods like .log, .info, and so on — or even .only in your test files. All you need to do is update the FORBIDDEN constant like this:

pre-commit

# Disallowed patterns: console methods
FORBIDDEN='(console\.(log|info|warn|error|clear|dir)|it\.only)'

Plaintext

Other Git hook ideas to level up your workflow

Although using the pre-commit hook may seem like it’s blocking your workflow or might appear straightforward in terms of what you can do with it, there are other use cases where you can run scripts at different stages, not just on commit.
Here are a few common Husky hooks you can use:

commit-msg – Validate or format the commit message using your project’s guidelines or some conventional ones
pre-push – Run final checks before pushing to remote
post-merge – Automatically sync dependencies or regenerate files after a merge (e.g., run npm install or pnpm install) 🔄
post-checkout – Run scripts after switching branches (e.g., load env files, clean build cache)

These hooks are just examples of what’s possible — you don’t need to use them all, but knowing they exist can help you pick the right tool for the right task.
Start small, and build up as your project grows!

Husky vs GitHub actions: When to use each tool

You might be working on a project that already uses a CI/CD tool like GitHub Actions or CircleCI, and wondering — how is that different from Husky? 🤔
Let’s look at some key differences to help you decide whether Husky is a good fit for your project.

Feature	Husky	CI/CD Tools (e.g., GitHub Actions, GitLab CI)
Runs when?	Locally, before code is committed or pushed	After code is pushed to a remote repository
Best for	Catching issues early, enforcing local standards	Automating builds, tests, deployments
Speed	Instant feedback (runs on your machine)	Slower (runs in external environments)
Purpose	Prevent bad code from leaving your laptop 💻	Handle what happens after it leaves your laptop 🚀

The way I see it, it’s great to save time and feel confident that everything I’m pushing follows the project’s rules and guidelines. That’s why I’d choose to use both: CI/CD tools for automation after pushing, and Husky for those extra checks before the code even leaves my machine.

Local git hooks vs Husky: What’s the difference?

If you’ve worked with Git hooks before, it’s only natural to question what Husky really adds on top of them.
I had the exact same thought when I first came across it. And then it clicked — let’s take a closer look at how they differ. 🔍

Feature	Local Git Hooks	Husky
Setup	Manual – you write and place hook scripts	Managed by Husky with simple commands
Version control	Not tracked by default	Fully version-controlled in your repo
Sharing with team	Hard to sync	Easy to share and maintain across the team

I’d say the most significant and most useful advantage of Husky is that it lets you share your hooks with your team and track them through Git.
I used to try setting up Git hooks manually, even when working solo — but it always felt like this mysterious black box, and I kept putting it off.
Husky makes the whole process way easier and more straightforward. Plus, being able to commit your hooks with the repo and even reuse the same setup across projects? Huge time-saver. Count me in! 🙌

Frequently Asked Questions

Is there a way to temporarily skip Git hooks?

Yes, you can!
If you’re under pressure or just need to skip Git hooks (including Husky hooks) for any reason, you can do it by adding the --no-verify flag to your Git command.

For example

git commit -m "My quick fix" --no-verify

Bash

Just keep in mind — skipping hooks should be the exception, not the habit. Hooks are there to help your workflow, not get in the way. 😉

Another way to do this is by using HUSKY=0 in your script e.g

HUSKY=0 git commit ...

Bash

I got used to using --no-verify when I want to skip hooks, but it’s nice to know that Husky offers an alternative.

Can I use Husky locally even if the rest of the team isn’t?

Absolutely! You can set up Husky on your own without forcing it on others. Since Husky hooks live in the .husky/ folder, you can simply add that folder to .gitignore if you don’t want to commit it.
Alternatively, you can commit it and let others opt in if they want — it’s up to your team’s workflow.

Have you used Husky in your projects, or do you prefer sticking with native Git hooks or CI tools?
Drop a comment and share how you manage your Git workflow — We’d love to hear what’s worked for you! 💬👇

September 12, 2025

How to Do the Copyright Symbol on Mac
If you’re wondering how to type the copyright symbol on a Mac, the solution is quick and easy. Mac keyboards come with built-in shortcuts for special characters, including the copyright symbol.

Why use the copyright symbol?

The copyright symbol © shows that your work is protected by copyright law. You can put it in blog posts, documents, or any other type of creative work. It shows people that your work belongs to you.

Some people also add the year and their name next to it, for example:

© 2025 John Doe

This makes it even clearer who owns the content and when it was created. However, the symbol by itself may not be enough to fully protect your rights in all situations — it’s best to include clear terms and conditions for your website or publications, and seek professional legal advice if you need comprehensive protection.

Typing the Copyright Symbol on macOS

To type the © symbol on a Mac, simply press:

Option (⌥) + G

That’s all you need to do! This shortcut works across most apps on macOS — whether you’re writing in Pages, Word, Google Docs, or even in your browser.

If you are new to Mac and do not know the Option key: it is next to the Command (⌘) key. On most keyboards, there is one Option key on the left side and one on the right side.

If the shortcut mentioned above doesn’t work, you can use the Character Viewer:
- Press Control + Command + Space
- Search for “copyright”
- Double-click the symbol to insert it.
Related Tips: Typing Other Special Symbols on Mac

Mac has shortcut for many symbols. There are some you might also like:
- Trademark (™) – Press Option (⌥) + 2
- Registered Trademark (®) — Press Option (⌥) + R
- Degree (°) — Press Shift + Option (⌥) + 8
- Ellipsis (…) — Press Option (⌥) + ;
- Section (§) — Press Option (⌥) + 6
These shortcuts work almost everywhere on macOS. If you forget them, you can either open the Character Viewer and search for the symbol you want or bookmark this post.

Extra tips for Mac beginners

When I first switched from Ubuntu Linux to macOS, I felt a bit lost. Many things were different. On Linux, I used different key combinations for special characters, and sometimes I had to copy and paste them. On Mac, once I learned the shortcuts, my work became faster. You might be in the same situation — maybe not from Ubuntu, but perhaps you are coming from Windows? Or maybe you are just a newcomer to the computer world.

Regardless, these simple, everyday shortcuts might also help you:
- Command + C to copy
- Command + V to paste
- Command + Z to undo
- Command + Shift + 4 to take a screenshot of a selected area
I’m a new Mac user and have been having questions about shortcuts, processes, and other little details in macOS since I switched from Ubuntu Linux. I started adding these posts to help me remember — and hopefully, they’ll help you too.

Since moving to macOS, I’ve been collecting tips and shortcuts to make my daily work easier. I share them here so they’re easy to find — and maybe they’ll help you too.
August 13, 2025
How to Close a Full Screen on Mac

If you’re new to Mac, like I am, you might be wondering: How do I close full screen on Mac? Don’t worry, it’s very simple once you know how!

Here are three quick and easy methods you can use to exit full-screen mode on your Mac:

A. Use the Green Button

Move your mouse to the top of the screen until you see the menu bar and the three window buttons (red, yellow, green) appear in the top-left corner of the window.

Click the green button to exit full screen and return to normal window size. You can also click it again if you want to go back into full screen.

The green icon is used to expand or minimize windows on a Mac.

Tip: In macOS, the green button is not just for full screen — it’s also used to resize or tile windows. If you hold down the Option key while clicking, you can maximize the window without entering full screen.

B. Press and Hold Esc

In some apps, you can simply press and hold the Esc key to exit full screen. This works in many media apps, like QuickTime or YouTube, when viewed in Safari.

While this doesn’t work in every app, it’s worth trying. Often, when you move your mouse to the top of the screen, you might see a small message saying: “To exit full screen, press and hold Esc.”

Hold Esc for about 3 seconds, and you should see the app switch back to windowed mode.

C. Keyboard Shortcut

For a faster method, press Control + Command + F. This shortcut works in most Mac apps and will toggle between full screen and windowed mode instantly.

Tip: If you’re using a MacBook with the Touch Bar, you might see a dedicated “Exit Full Screen” button appear when you’re in full screen. Tapping it is the same as using the keyboard shortcut.

When Full Screen Won’t Exit

There could be a case that your app may not respond to the methods mentioned above. In this case, try pressing Command + Tab to switch to another app, then close the full-screen one from the Dock.

You can also right-click the app icon in the Dock and select Options > Exit Full Screen if available.

If nothing works, press Command + Option + Esc to force quit the app, then reopen it in normal mode. This is rare, but it’s good to know if a program freezes while in full screen.

Looking for more beginner-friendly Mac tips? Check out our other quick guides for macOS beginners.

August 8, 2025
How to Install Postgres on MacOS
If you’re working on a Node.js project and run into errors like ECONNREFUSED ::1:5432, chances are PostgreSQL isn’t running — or it isn’t even installed. Here’s a quick guide to install postgres on macOS using Homebrew, the most reliable and straightforward method.

Before installing PostgreSQL, make sure you already have Homebrew installed on your Mac. Homebrew is the package manager we’ll be using to install and manage PostgreSQL.

Don’t have Homebrew yet? No worries, we got you covered. Check out our guide: How to Install Homebrew on macOS.

Once you’ve got Homebrew set up, you’re ready to continue.

Step 1: Install PostgreSQL via Homebrew

With Homebrew installed, adding PostgreSQL is easy:
```
brew install postgresql
```
Bash
If you want to install a specific version of postgres, e.g, version 17 type:
```
brew install postgresql@17       
```
Bash
Step 2: Start the PostgreSQL Service

Once installed, start PostgreSQL as a background service:
```
brew services start postgresql
```
Bash
To confirm it’s running:
```
brew services list
```
Bash
You should see something like:
```
Name        Status   User       File
postgresql  started  your-name  Library/LaunchAgents/[email protected]
```
Bash
Step 4: Confirm the Installation

Check that PostgreSQL is installed correctly:
```
psql --version
```
Bash
psql is the interactive command-line tool when working with Postgres

Expected output:
```
psql (PostgreSQL) 17.5 (Homebrew)
```
Bash
In case you are getting a command not found: psql error you have to explicitly link it. For my example, in which i installed version 17, I just had to type
```
brew link postgresql@17 --force
```
Bash
By typing psql --version you should now see the postgreSQL you just installed.

Step 5: Connect to PostgreSQL

You can now open a PostgreSQL shell:
```
psql postgres
```
Bash
Or create your own database:
```
createdb mydb
psql mydb
```
Bash
Step 6 (Optional): Choosing a GUI

If you prefer a graphical interface over the terminal, consider installing
- pgAdmin
- Datagrip
- Postico
- TablePlus
These tools make managing your databases even easier.
August 4, 2025
HTML for Blinking Text – Simple Copy & Paste Code
If you’re here, chances are you’re looking for HTML for Blinking Text — maybe you remember the old-school <blink> tag that used to make text flash or flicker on screen. It looked something like this:
```
<blink>This text will blink</blink>
```
HTML
Unfortunately (or fortunately, depending on your view), the <blink> tag is now considered obsolete and is no longer supported by modern browsers.

Modern browsers no longer support <blink> because it was never officially standardized, causing serious accessibility issues. Visually impaired users, in particular, often rely on assistive technologies that don’t handle blinking content well. Plus, from a design standpoint, constant blinking can be distracting and overwhelming to users.

Blinking Text Using HTML and CSS

So how do you create blinking text today, in a way that’s clean, compliant, and works across all devices? That’s where HTML and CSS come in. With simple CSS animations powered by @keyframes, you can replicate the blinking effect — only better.
```
<p class="blinking">This text will blink using CSS</p>
```
HTML
```
.blinking {
  animation: blink 1s step-start 0s infinite;
}

@keyframes blink {
  50% {
    opacity: 0;
  }
}
```
CSS
This CSS-based method offers more flexibility than the old <blink> tag. You can control timing, opacity, color changes, or even trigger it on events like hover. Plus, it works across all modern browsers, making it a practical solution for attention-grabbing UI elements like warnings or notifications.

You can even combine it with other effects like scaling or background changes for more dynamic visuals. Whether you’re building a retro-style webpage or emphasizing urgent content, this is a reliable, modern solution.

Check this out in our codepen too

See the Pen
Blinking Text by Little Coding Things (@Little-Coding-Things)
on CodePen.

If you’re working on a project and still want that eye-catching flicker using CSS animation is the best and most future-proof way to implement HTML for Blinking Text. It’s responsive, accessible, and keeps your design up to today’s standards.

Want to take it to the next level? Check out our post on creating a blinking eyes animation using CSS!
July 25, 2025
What does git add -a do?
If you’re reading this post, chances are you’re looking for a Git command that stages all changes before committing. To set the record straight: the correct command is git add -A. A quick look at the git add documentation will show you that git add -a doesn’t exist. Instead, git add -A is the command that stages all recent changes — including new, modified, and deleted files.

Let’s take a closer look to see if this is the command you’re really after.

Common Mistake: git add -a

When someone types git add -a, they’re usually trying to stage everything before a commit. It’s often a case of muscle memory or a mistaken assumption that -a stands for “add all.”

In most situations, what the user actually meant was either:
- git add -A to stage everything, or
- git add . to stage changes in the current folder and below
git add . vs git add -A

These two commands are often used interchangeably, but they’re not exactly the same. While both will stage new, modified, and (in modern Git) deleted files, the main difference lies in their scope.

git add -A: Stages Everything, Everywhere

When you run git add -A, Git stages all changes across the entire working tree, no matter where you are in the project.
For example, even if you’re working in a deep directory like src/assets/images, git add -A will still stage changes from higher directories like src/ or the root.

git add .: Stages From the Current Directory Down

On the other hand, git add . only stages changes in the current directory and its subdirectories. The dot (.) refers to “this folder,” so changes in sibling or parent directories won’t be included.

So, When Does It Matter?

If you’re working from the root of your repository, there’s practically no difference between git add . and git add -A in modern Git versions — both will stage everything.

But if you’re working in a subdirectory and want to stage all changes in the project, you should use git add -A.

If you only want to stage changes within the folder you’re in, then git add . is the right choice.

Frequently Asked Questions (FAQ)

Is git add -a a valid Git command?
No — git add -a is not a valid command. If you try it, Git will return an error: error: unknown switch 'a'.
The correct command to stage all changes is git add -A.

Do I need to run git add -A from the root of my repository?
No, you can run git add -A from any directory inside your project, and it will always stage changes across the entire directory

Thanks for being here! 🙌 If you found this post helpful, giving it a like or share means a lot to us — it helps others find it too.

Got another Git command that’s confusing or unclear? Drop a comment below, and we’ll be happy to explain it in a future post or reply directly. We’re here to make Git simpler, one command at a time. 😊
July 16, 2025
Coding Interview Series – Intro to Express.js & Middleware
While preparing for a coding interview, I found myself feeling a bit rusty on theoretical questions and scenarios I haven’t dealt with recently in my everyday work. After all, a developer doesn’t have to remember everything, right? Based on experience, a developer usually just remembers something exists — or has to look it up if they’ve never built anything similar.

So what’s this post about? This — and others coming soon — will be part of a series covering questions I believe are important for any developer to know in order to feel confident going into an interview focused on Express.js. If you can answer these questions, you should feel pretty good. You won’t know everything, but you’ll be in solid shape to show your knowledge and tackle most of what comes your way.

For me, these are basically my notes from preparing for coding interviews, and I figured I’d share them in case they help you too.

We also plan to share a quiz app featuring these same questions in a simple, game-like environment. We’re building it now and will share it with you soon, so stay tuned!

Enough said! Let’s start with some simple questions and gradually go deeper. In each post, I’ll also include links to the next parts of the series.

Each answer in this series isn’t meant to be 100% complete or the final word. The goal is to show the interviewer that you understand the topic well and can explain it clearly. There’s always room for improvement or deeper discussion.

Some questions include additional context to strengthen your understanding or explore the topic more deeply — we’ve marked those with a 🧠 icon.

Others will point you to related resources for continued learning or best practices — those are marked with a 🚀 icon.

Introductory coding interview questions

What is Express.js?

Express.js is a web application framework built on Node.js. It provides a higher-level API for handling HTTP requests. Express.js is commonly used to build REST APIs because it simplifies route handling compared to Node.js.

What are some alternatives to Express.js?
- Koa.js – Created by the same team behind Express
- Fastify – Focuses on speed and performance
- Nest.js – TypeScript-first framework
Why should you use Express.js over Node’s built-in HTTP module?

Node.js provides a low-level foundation, while Express abstracts common patterns, such as routing and middleware, making development faster and more maintainable.

🧠 Deeper – Compare Express and Node Doing the Same Thing

It’s easy sometimes to say something is different, but it would be nice to have a quick glimpse at an actual example. Because of this, below is a simple GET / users route implemented first with Express.js and then with plain Node.js so you can see the practical difference in code size and readability.
```
// Express.js

const express = require('express');
const app = express();

app.get('/users', (req, res) => {
  res.json({ message: 'Users list' });
});

app.listen(3000, () => console.log('Express server on port 3000'));
```
JavaScript
In Express.js if you use res.json() (or pass an object/array to res.send()), Express automatically sets the Content-Type header to application/json; charset=utf-8. You don’t need to call res.setHeader() yourself.
// Node const http = require('http'); const server = http.createServer((req, res) => { if (req.method === 'GET' && req.url === '/users') { res.statusCode = 200; res.setHeader('Content-Type', 'application/json'); res.end(JSON.stringify({ message: 'Users list' })); } else { res.statusCode = 404; res.end('Not Found'); } }); server.listen(3000, () => console.log('Node server on port 3000'));
```
// Node
const http = require('http');

const server = http.createServer((req, res) => {
  if (req.method === 'GET' && req.url === '/users') {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'application/json');
    res.end(JSON.stringify({ message: 'Users list' }));
  } else {
    res.statusCode = 404;
    res.end('Not Found');
  }
});

server.listen(3000, () => console.log('Node server on port 3000'));
```
JavaScript
Middlewares

What is middleware in Express?

A middleware is a function. It runs before the final route handler, and it has access to the request, response, and next callback.

An example of a middleware on a route level could be:
```
// auth middleware
function auth(req, res, next) {
  if (!checkAuthOfUserId(req.params.id)) {
    return res.status(403).send('Access denied');
  }
  next();
}

app.get('/users/:id', auth, (req, res) => {
  res.send(`Access granted to user ${req.params.id}`);
});
```
JavaScript
How many types of middleware do you know?

There are types of middleware:
- Global
- Path based
- Route specific
- Error handling
Examples for each would be:

Global type middleware example
```
const express = require('express');

const app = express();

app.use(express.json());
```
JavaScript
This middleware will run for all incoming requests, regardless of route or method.

Path-specific middleware example
```
// middleware definition
function adminLogger(req, res, next) { ... }

// Apply middleware to all /admin paths (any method)
app.use('/admin', adminLogger);

app.get('/admin', (req, res) => {
  res.send('Admin Home');
});

app.post('/admin', (req, res) => {
  res.send('Admin POST');
});

app.get('/admin/settings', (req, res) => {
  res.send('Admin Settings');
});
```
JavaScript
A path-specific middleware will run on all HTTP methods for any route that starts with that path.

Route-based middleware example
```
function requireAuth(req, res, next) { ... }

app.get('/profile', requireAuth, (req, res) => {
  res.send('Welcome to your profile!');
});
```
JavaScript
This middleware is applied only to a specific route and will run only when a GET request is made to the /profile endpoint.

Error-handling middleware example

Error-handling middleware is a special feature in Express.js that catches errors and handles them in a single location. It has four parameters:
```
function errorHandler(err, req, res, next) {
  // Custom error handling logic
}
```
JavaScript
In Express 5, if a route handler or middleware returns a Promise that is either rejected or throws an exception, Express will automatically call next(err) for you.

What do you know about the app.use function?

app.use() is a method in Express used to register middleware functions. These middleware run before any route handler and can modify the request or response, or end the response cycle.

🚀 Further reading – Using the Right Terms — Path, Route, or Handler?

When working with Express.js, you’ll frequently encounter the terms route, path, and handler. It’s important to understand the distinction between them, as each plays a different role in handling HTTP requests.

Let’s break it down using the following example:
```
app.get('/users', (req, res) => { ... });
```
JavaScript
Path: The URL pattern that the server listens to — here, it’s '/users'.

Route: The combination of an HTTP method (e.g., GET, POST) and a path. In this example, GET /users is the route.

Handler: The callback function that is executed when a request matches the route. In this case, it’s the function (req, res) => { ... }.

Routes

What is a route in Express.js?

A route in Express defines a specific endpoint by combining an HTTP method (such as GET, POST, etc.) with a path, along with the logic (called a handler) that should execute when that request is received.

Example
```
app.get('/hello', (req, res) => {
  res.send('Hello this is route!')
})
```
JavaScript
What’s the difference between app.get and app.post?

Both app.get and app.post define routes.
- app.get() handles GET requests for fetching data.
- app.post() handles POST requests for updating or creating data.
How would you retrieve a route param from a URL like /users/:id?
```
app.get('/users/:id', (req, res) => {
  const { id } = req.params;
  res.send(`User id is ${id}`)
})
```
JavaScript
What’s the difference between req.params, req.query, and req.body?

Property
Source
Example
req.params
Route parameters
/users/:id → req.params.id
req.query
URL query string
/search?q=test → req.query.q
req.body
POST/PUT body
req.body.nameneeds middleware like express.json()

Can a route have multiple middleware functions? How?

Yes, you could add middleware by adding it to the route before the handler.
```
app.get('/secure', authMiddleware, loggingMiddleware, (req, res) => {
  res.send('Access granted');
});
```
JavaScript
What is express.Router() and why would you use it?

express.Router() creates a modular, mini Express app. It helps organize code by separating routes into files.

For example, you might organize all your user-related routes in a separate file, such as:
```
// routes/users.js

const express = require('express');
const router = express.Router();

// GET /users
router.get('/', (req, res) => {
  res.send('User list');
});

// GET /users/:id
router.get('/:id', (req, res) => {
  res.send(`User ID: ${req.params.id}`);
});

module.exports = router;
```
JavaScript
and then import and register them in your main Express application file like this:
```
const express = require('express');
const app = express();

const userRoutes = require('./routes/users');

// Mount user router at /users
app.use('/users', userRoutes);

app.listen(3000, () => console.log('Server running'));
```
JavaScript
What’s next?

In this post, we reviewed key Express.js concepts — from routing and middleware types to error handling. These are the kinds of topics that come up often in coding interviews.

In the next part of this series, we’ll shift gears toward project-level questions. Stay tuned!
July 3, 2025
How to Restart Your Node App Without Nodemon
If you’ve built anything with Node.js, you’ve probably used nodemon to automatically restart your app when files change. It’s been a go-to developer tool for years — but did you know you no longer need it?

With Node.js 18.11 and above, there’s a built-in --watch option. It tells Node to monitor your source files and automatically restart the process when changes are detected.
```
node --watch app.js
```
Bash
That’s it. No configuration, no dependencies, no waiting for external tools to kick in.

It works great when:
- You’re building small or medium apps.
- You don’t need advanced features like custom delay or file filters.
- You want to keep your environment minimal and lean.
Keep in mind that, large projects with complex file structures might still benefit from nodemon or more advanced tools.
June 14, 2025
How to install Git on Mac – MacOS for beginners
So, you’re new to macOS and ready to set up Git? Great choice! Git is one of the essential tools for developers, and installing it should be one of the first steps in your journey. Don’t worry—it’s easier than you think. Let’s get started!

If you’ve never worked with Git before, think of it as a timeline for your files. It’s a tool used to keep track of every change you make, so you can jump backward in time if you break something or experiment freely without losing your original work.

It’s not just for programmers — writers, researchers, and designers also use Git to track versions of their work. Installing Git on your Mac now will save you a lot of headaches later.

Although there’s a small learning curve at first, you’ll quickly find that once you’ve used Git for a while, you can’t imagine working without it — you’ll wonder how you ever managed before.

Check if Git is already installed

If you’re just setting up your Mac, it’s unlikely that Git is already installed. macOS doesn’t come with a fully functional Git by default. Instead, it includes a placeholder located at /usr/bin/git. This placeholder acts as a link to the actual Git version, which gets installed with Xcode or the Command Line Tools.

To check, open your terminal and type:
```
git --version
```
If you see something like:
```
No developer tools were found, requesting install
```
it means that macOS detected that you tried to use a command-line developer tool – git in this case – but the Xcode Command Line Tools are not installed on your system.

From here, you have two main choices for installing Git on your Mac — Apple’s Xcode Command Line Tools or the Homebrew package manager. Both will get the job done, but they have different strengths.
- Xcode Command Line Tools is quick and easy if you just want to start using Git right away, but the version it installs is maintained by Apple and might not always be the latest.
- Homebrew, on the other hand, gives you more control and makes it simple to update Git whenever a new release comes out. If you plan to keep working with Git regularly, I suggest going with Homebrew for its flexibility and ease of maintenance.
Install Git on Mac using Xcode

Xcode is one of the quickest ways to install Git on your system. Since Xcode Command Line tools include Git in the package, to use Git all you need to do is type the following command in your terminal
```
xcode-select --install
```
When the pop-up appears, click Install. Make sure you’re connected to the internet.

Once the installation finishes, confirm it by typing:
```
git --version
```
You should now see something like:
```
git version 2.39.5 (Apple Git-154)
```
Install Git on Mac using Homebrew

Another popular way to install Git on macOS, apart from using Xcode Command Line Tools, is by using Homebrew.

This method is often preferred by developers who want more control over the Git version or are already using Homebrew for managing other software.

You may also like 🎬
How to install Homebrew – MacOS for beginners
December 2, 2024
How to Install Postgres on MacOS
August 4, 2025

To install Git using Homebrew, run the following command
```
brew install git
```
Running this command will display some logs related to the Git installation, such as:
.... ==> Installing git ==> Pouring git--2.47.1.arm64_sequoia.bottle.tar.gz ==> Caveats The Tcl/Tk GUIs (e.g. gitk, git-gui) are now in the `git-gui` formula. Subversion interoperability (git-svn) is now in the `git-svn` formula. zsh completions and functions have been installed to: /opt/homebrew/share/zsh/site-functions ==> Summary 🍺 /opt/homebrew/Cellar/git/2.47.1: 1,685 files, 54.4MB ==> Running `brew cleanup git`... ....
```
....
==> Installing git
==> Pouring git--2.47.1.arm64_sequoia.bottle.tar.gz
==> Caveats
The Tcl/Tk GUIs (e.g. gitk, git-gui) are now in the `git-gui` formula.
Subversion interoperability (git-svn) is now in the `git-svn` formula.

zsh completions and functions have been installed to:
  /opt/homebrew/share/zsh/site-functions
==> Summary
🍺  /opt/homebrew/Cellar/git/2.47.1: 1,685 files, 54.4MB
==> Running `brew cleanup git`...
....
```
Once the installation process is complete, you can verify that Git was installed successfully by typing:
```
git --version
```
You should see
```
git version 2.39.5 (Apple Git-154)
```
With Git successfully installed, you’re now ready to dive into your development journey and take full control of your projects!

🛠 Extra Tip: When installing via Homebrew, you can easily update Git later by running:
```
brew update && brew upgrade git
```
Bash
This ensures you’re always on the latest stable release without waiting for Apple updates. It also makes switching between different Git versions simple, which is useful for testing or specific project needs.

Verify Git configuration

After installing Git, it’s a good idea to configure your identity so your commits are linked to the right name and email address. Run the following commands in your terminal:
```
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
```
Bash
You can check your saved settings with:
```
git config --list
```
Bash
This will show your username, email, and other configuration details. These can be changed at any time if you switch accounts or need to adjust your settings.

Next Steps with Git

Installing Git is just the beginning. The next step is learning a few key commands that will make you productive right away. Start with:
- git init – Create a new repository in the current folder.
- git add <filename> – Stage files you want to include in your next commit.
- git commit -m "message" – Save your staged changes with a short description.
- git status – Check what’s been modified, staged, or committed.
- git log – View a history of all commits in the repository.
Once you’re comfortable with these, try creating a branch with git branch <branchname> and switching to it using git checkout <branchname>. Branching is one of Git’s most powerful features, letting you work on new ideas without touching your main project until you’re ready.

As you explore these commands, remember that consistent practice is the fastest way to build confidence and skill with Git. And if you want to take things a step further, tools like Husky pre-commit hooks can help automate checks and streamline your workflow as you grow.
December 16, 2024

Property	Source	Example
`req.params`	Route parameters	`/users/:id` → `req.params.id`
`req.query`	URL query string	`/search?q=test` → `req.query.q`
`req.body`	POST/PUT body	`req.body.name`needs middleware like `express.json()`

Author: Duke

Docker Compose Commands

Starting Services

Stopping Services

Restarting Services

Viewing statuses

Docker commands

Executing Commands in Containers

Cleanup commands

Removing Containers by Name Prefix

Viewing Logs

Copy Files From Container

docker-compose vs docker compose

docker-compose (Legacy)

docker compose (Recommended)

Which One Should You Use?

Quick Reference Card

Naming convention 1: Your app owns “Modal”, the library is the “Base”

Pros

Cons

Naming convention 2: Name your modals based on what they actually do

Pros

Cons

Naming convention 3: Use prefix or suffix to show ownership

Pros

Cons

Naming conventions that usually cause trouble

A simple question that keeps things clean

Wrapping up

Check if Java is Already Installed

What is a JDK?

Install Java on Mac

Install Java using Homebrew

Set JAVA_HOME Environment Variable

Verify Installation

Uninstalling Java (Homebrew)

Checking Installed Versions

Choosing an IDE for Java

Troubleshooting Common Issues

Wrong Java Version Running

brew install fails

java Command Not Found

My Late Start in Web Development

You’re Not Starting from Zero

Too Old Compared to What?

What’s the Alternative?

The Learning Curve: Yes, It’s Real – and Beatable

What’s the Worst That Could Happen?

What If You Love Coding but Still Can’t Get a Job?

What If You Try Coding and Don’t Like It?

Ready to Start? Let’s Talk About Where to Begin

The Legacy of Montulli’s Internet Cookies

Magic cookies, LSD, and Unix users

The Cookie Monster Connection 🍪

Why Are Internet Cookies Called Cookies? — A Quick Recap

🔄 Basic Editing MacOS Shortcuts

👨‍💻 Developer – Focused macOS Shortcuts

💻 Productivity MacOS Shortcuts

🔤 Other Useful Shortcuts

Introduction: Why use Husky hooks in your project?

Installing and initializing Husky in your project

.husky/pre-commit

.husky/_ folder

prepare script

Expanding pre-commit: Catch more before it hits your repo

Hook for linting checks

Hooks to catch console.log statements

Other Git hook ideas to level up your workflow

Husky vs GitHub actions: When to use each tool

Local git hooks vs Husky: What’s the difference?

Frequently Asked Questions

Is there a way to temporarily skip Git hooks?

Can I use Husky locally even if the rest of the team isn’t?

Why use the copyright symbol?

Typing the Copyright Symbol on macOS

Related Tips: Typing Other Special Symbols on Mac

Extra tips for Mac beginners

A. Use the Green Button

B. Press and Hold Esc

C. Keyboard Shortcut

`docker-compose` vs `docker compose`

`docker-compose` (Legacy)

`docker compose` (Recommended)

`java` Command Not Found

Common Mistake: `git add -a`

`git add .` vs `git add -A`

`git add -A`: Stages Everything, Everywhere

`git add .`: Stages From the Current Directory Down

What’s the difference between `app.get` and `app.post`?

How would you retrieve a route param from a URL like `/users/:id`?

What’s the difference between `req.params`, `req.query`, and `req.body`?

What is `express.Router()` and why would you use it?