Forem: Adrian Jiga

6 Things About The Terminal That Confuse Everyone (And Nobody Warns You About)

Adrian Jiga — Mon, 30 Mar 2026 19:22:18 +0000

You open a terminal for the first time in and stare at a black screen with a blinking cursor. You type something. You press Enter. Nothing happens. No confirmation, no progress bar, no “Done!”, just the cursor blinking back at you like it’s waiting for something else.

So you type it again. Still nothing. You close the terminal and go back to clicking around in a GUI.

That’s how most people’s first experience with the terminal ends. Not because the command was wrong. Because the terminal was working exactly as intended, and nobody explained how it actually behaves before handing it to you.

There’s a concept in psychology called the curse of knowledge. Once you know something well enough, you lose the ability to remember what it felt like not to know it. The thing that was once confusing becomes invisible, not because it stopped being confusing, but because your brain quietly filed it away and moved on.

Terminal guides are written almost entirely by people who are deep under the curse of knowledge. They know what the $ symbol means. They know why the screen goes blank after a successful command. They know what happens when you press Ctrl+C. None of it registers as something that needs explaining anymore so they skip straight to the commands, and beginners hit a wall they never saw coming.

This isn’t a guide about commands. It’s about the six things that will confuse you before you even get to commands, the behaviors that feel broken until you understand why they exist.

These are the six that get everyone.

1. When it says nothing, that means it worked

Coming from graphical interfaces, you’re trained to expect feedback. You save a file, the title bar updates. You install software, a progress bar fills. Something always confirms that the thing happened.

The terminal doesn’t work like that.

When a command succeeds, you get your prompt back. That’s it. No checkmark, no “Success!”, no output of any kind. Just the cursor, ready for the next command.

$ cp cypress/fixtures/user.json cypress/fixtures/user.backup.json
$

That blank line isn’t the terminal ignoring you. The file was copied. The terminal is done. It moved on.

This is a deliberate design choice, not an oversight. The philosophy is that output means something went wrong, or you specifically asked for information. Silence means everything went fine. Once you internalize that, it actually feels clean, you’re only reading output when there’s something worth reading.

But until it clicks, every successful command feels like a failure.

2. Your password is invisible and that’s intentional

The first time you’re asked to enter a password in the terminal, you type it and watch nothing appear. Not dots, not asterisks. Nothing. The cursor just sits there.

The natural assumption is that the keyboard has stopped working. It hasn’t.

The terminal hides password input completely, not even placeholder characters, to prevent what’s called shoulder surfing. If someone’s watching your screen, they can’t tell how many characters your password is, which gives them nothing useful. Even the length of your password stays hidden.

$ sudo pacman -Syu
[sudo] password for adrian:

Type your password and press Enter. It’s being captured. The blank input is the feature.

3. The `$` in tutorials is not part of the command

Every terminal guide, every Stack Overflow answer, every documentation page shows commands like this:

$ cd Documents
$ npx cypress run
$ php artisan serve

The $ is the prompt symbol. It’s what the terminal prints to indicate it’s ready for input, it’s marking where your command starts, not contributing to it. When you see $ npm install, you type npm install.

You’ll also see % on Zsh, # when running as root, and sometimes no symbol at all. The character varies, but the role is always the same: it’s a separator between the terminal’s state and your input.

Nobody explains this upfront because to anyone who’s been using a terminal for more than a week, it stopped registering as something that needed explaining. But copy-pasting that $ is one of the most common things that breaks a first command.

4. Ctrl+C does not copy, it kills

In every other context, Ctrl+C copies selected text. In the terminal, it sends an interrupt signal that stops whatever is currently running.

If you’re running a test suite, a server, a long install, or anything else that’s actively executing, and you reach for Ctrl+C trying to copy something, you’ve just cancelled it.

$ npx cypress run
Running: login.cy.js (1 of 8)

  Login flow
    ✓ loads the login page (432ms)
    ✓ logs in with valid credentials (1204ms)
    - should redirect after login

^C

That ^C in the output is the terminal’s way of showing you the interrupt happened. Six test files never ran. The process is gone.

To copy in most terminals, the shortcut is Ctrl+Shift+C. To paste, Ctrl+Shift+V. The extra Shift is the only difference between copying text and killing a process.

Once you know what it actually does, Ctrl+C becomes one of the most useful things in the terminal. Stuck in a command that won’t finish? Ctrl+C. Accidentally started something you didn’t mean to? Ctrl+C. It’s the universal escape hatch. Just not for copying.

5. If you accidentally open Vim, here’s how to get out

At some point running git rebase -i, forgetting the -m flag on a commit, or following a tutorial that assumes you know what you’re doing, you will end up inside Vim without meaning to. You’ll know because the screen looks nothing like a normal editor, your keyboard seems to be doing unpredictable things, and there’s no visible way to close it.

$ git commit
# Vim opens automatically because no -m flag was provided
# The screen fills with your diff and a blinking cursor
# Nothing you type makes sense

The exit commands:

Without saving: Press Esc, type :q!, press Enter.

Saving and exiting: Press Esc, type :wq, press Enter.

That’s all you need for now. The reason the keyboard feels broken is that Vim is a modal editor, it operates in different modes, and the same key does different things depending on which mode you’re in. When you first open it, you’re in normal mode, where most keys are commands rather than characters. Pressing g doesn’t type the letter g. It does something else entirely.

Esc returns you to normal mode from wherever you are. From normal mode, :q! quits without saving and :wq saves and quits. You don’t need to understand anything else about Vim to get out of it, and getting out of it is usually all you need.

6. Different tutorials show different commands and they’re all correct

You follow a guide that tells you to run one command. You follow another guide and it shows something completely different for the same task. Both claim to be correct. One of them doesn’t work on your machine.

This isn’t a mistake. It’s because “the terminal” isn’t one thing.

The terminal is the window. The shell is the program running inside it and the shell is what actually interprets your commands. Different shells have different syntax, different built-in commands, and different defaults. The most common ones you’ll encounter are Bash (the default on most Linux systems and older Macs), Zsh (the default on macOS since Catalina), and Fish (a friendlier alternative some developers prefer).

Most of the time the commands are identical across shells. But not always. Array syntax, certain string operations, some scripting features, these behave differently depending on which shell you’re in. A script written for Bash won’t necessarily run correctly in Fish.

On top of that, the operating system matters. A guide written for Ubuntu will use apt. The same guide for Arch-based systems uses pacman. On macOS you’d reach for brew. On Windows, you’re likely in PowerShell or WSL, and neither of those behaves like a Unix shell by default.

# Ubuntu / Debian
sudo apt install git

# Arch / CachyOS / Manjaro
sudo pacman -S git

# macOS
brew install git

# These do the same thing. Different OS, different package manager, different command.

When a command isn’t working and you’ve typed it correctly, the first thing to check is whether the guide was written for your system. The second thing to check is which shell you’re actually running. You can find out with echo $SHELL. Most of the time, that’s the answer.

The people writing terminal guides have been using the terminal long enough that these behaviors stopped being noticeable. The invisible password, the silent success, the $ symbol… none of it registers as something that needs explaining anymore. It’s been second nature for so long that the gap between their experience and a first-timer’s isn’t visible to them.

The result is that beginners hit these moments, feel like they’re missing something obvious, and conclude the terminal is just not for them. That’s not a skill problem. It’s an orientation problem.

The terminal is an old interface with a lot of implicit conventions that nobody wrote down because everyone who used it had learned from someone who already knew. Once you see what those conventions are, the rest of it, the commands, the flags, the piping, all of it, starts making sense a lot faster.

The six things above aren’t edge cases. They’re the first six walls. Most people hit at least three of them in their first session.

Now you know they’re coming.

You’ve Been Installing Software the Hard Way

Adrian Jiga — Fri, 27 Mar 2026 17:30:55 +0000

Before I used Linux, I installed software the way most people do. You open a browser, search for the thing you want, find the official website, download an installer, click through a wizard, and eventually the software appears on your system. Sometimes it takes five minutes. Sometimes you download something from the wrong site and end up with a toolbar you didn’t ask for. Sometimes the installer asks you to restart your computer to install a text editor.

It works. But it doesn’t scale, and it doesn’t age well. After a while you have no idea what’s installed on your machine, where it came from, or how to update it cleanly. And updating is the part that really shows the cracks. You find out a new version is available because the software told you, you go back to the website, download the new installer, click through the wizard again, and hope it cleans up after itself properly.

Package managers solve this. And once you’ve used one properly, going back to the old way feels like a step backward.

What is a package manager, actually?

A package manager is a tool that handles installing, updating, and removing software on your system. Instead of you hunting down the right installer for the right version on the right website, you just tell the package manager what you want, and it handles the rest. It knows where to get the software, what version to grab, and what other software it needs to work.

That last part is important. Most software depends on other software. A video editor might need a specific audio library. A web framework might need a particular runtime version. A database client might need a specific version of a driver that itself needs a specific version of something else. When you install things manually, you’re responsible for tracking all of that yourself, and it’s exactly as painful as it sounds.

A package manager does it automatically. You ask for one thing, it figures out the entire chain of dependencies, and installs everything in the right order.

Think of it like ordering from a restaurant versus going to three different grocery stores to buy ingredients, then cooking everything from scratch, then figuring out mid-recipe that you’re missing something. Both approaches get you fed. One is a lot less effort.

Windows: the platform that came late to this

For most of its history, Windows didn’t have a built-in package manager. You installed software by downloading executables and running them. Each installer did whatever it wanted: some added themselves to the PATH, some didn’t, some left behind registry entries when you uninstalled, some didn’t. Some bundled additional software you didn’t want and hoped you’d miss the checkbox.

That changed with winget, which Microsoft released in 2020 and has been steadily improving since. It’s built into modern Windows and lets you install software straight from the terminal:

winget install Mozilla.Firefox
winget install Git.Git
winget install Microsoft.VSCode
winget install Spotify.Spotify

It’s not as mature as what Linux has had for decades, but it’s a real package manager with a real repository and it works well for common tools. You can even export your installed packages to a file and use it to restore your entire setup on a new machine, something that would have taken an afternoon doing manually before.

Before winget, the community filled the gap. Chocolatey has been around since 2011 and has a massive package repository. It’s still widely used, especially in corporate environments where IT teams need to automate software deployments across hundreds of machines. Scoop is another popular option, leaning more toward developer tools and command-line utilities, and it installs everything to your user directory without needing admin privileges, useful if you’re on a work machine where you don’t have full admin access.

If you’re a developer on Windows, any of these will improve your life compared to the download-and-run approach.

macOS: Homebrew became the de facto standard

macOS doesn’t ship with a package manager for general software either. Apple gives you the App Store for GUI apps and that’s about it. For developers who need command-line tools, libraries, and utilities, the App Store isn’t the answer.

The community built one that became so widely adopted it’s essentially assumed to be installed on any developer’s Mac.

Homebrew is that tool. You install it with a single command, and then the whole thing just works:

brew install git
brew install node
brew install ffmpeg
brew install wget
brew install imagemagick

Homebrew calls its packages “formulae” for command-line tools and “casks” for GUI applications. Want to install a desktop app without touching a browser?

brew install --cask firefox
brew install --cask visual-studio-code
brew install --cask vlc
brew install --cask discord

It handles updates cleanly too. brew update refreshes the package list, brew upgrade upgrades everything outdated. One command and your whole system is current. Compare that to opening five different applications, clicking “check for updates” in each one, and waiting for them to download and restart individually.

MacPorts is the older alternative that predates Homebrew and some people still prefer it, particularly for certain scientific or research tools. But Homebrew won the adoption battle years ago. If you’re on a Mac, Homebrew is almost certainly already there.

Linux: this is where it gets interesting

Linux distributions have had package managers since the 1990s. It’s baked into how the whole system works, not bolted on afterward. On Linux, the package manager isn’t a convenience, it’s the primary way you’re expected to interact with software. The entire operating system, including the kernel, the desktop environment, and every tool installed on it, is managed through it.

That means when you run a system update on Linux, you’re not just updating one application. You’re updating everything at once, in one command, in a consistent and predictable way.

The package manager you get depends on which distribution you’re using, because Linux distros are built around different packaging formats and different philosophies about how software should be distributed.

Debian and Ubuntu use apt (Advanced Package Tool). It manages .deb packages and is probably the most widely recognized Linux package manager:

sudo apt install git
sudo apt install vlc
sudo apt install htop
sudo apt update && sudo apt upgrade

The update command refreshes the list of available packages. The upgrade command actually installs newer versions. It’s a two-step process, which trips up newcomers who run apt update and wonder why nothing changed.

Fedora and Red Hat use dnf, which manages .rpm packages. The commands are similar enough that switching between them doesn’t take long to get used to:

sudo dnf install git
sudo dnf install vlc
sudo dnf upgrade

Arch Linux (and Arch-based distros like CachyOS, Manjaro, or EndeavourOS) use pacman. It’s fast, minimal, and does exactly what you ask with no ceremony:

sudo pacman -S git
sudo pacman -S vlc
sudo pacman -Syu

The -Syu flag is the one you’ll type constantly on Arch: it syncs the package database, updates all packages, and upgrades the system in one shot. Rolling release distributions like Arch stay current by design, so running this regularly is just part of the workflow. Think of it like a standing order. Rather than manually restocking your pantry item by item whenever something runs out, you’ve arranged for everything to be automatically topped up at once.

openSUSE uses zypper. Void Linux uses xbps. Alpine uses apk. Every major Linux distribution has its own tool, but the underlying concept is always the same: a central repository of packages, a tool to interact with it, and automatic dependency resolution.

The AUR: Arch’s unique addition

If you use Arch or an Arch-based distro, you’ll eventually hear about the AUR, the Arch User Repository. It’s worth understanding because it’s unlike anything the other ecosystems have.

The official Arch repositories contain software that the Arch team maintains and packages. The AUR is a community repository where anyone can submit a PKGBUILD, a script that describes how to download, build, and install a piece of software. It’s not precompiled packages you install directly. It’s instructions that your machine uses to build the software locally from source.

The result is that practically anything you could want is available on Arch. Obscure tools, proprietary software, niche utilities, things that haven’t made it into official repositories anywhere. If it exists, someone has probably written a PKGBUILD for it. Tools like yay or paru let you interact with both the official repos and the AUR with the same syntax, so in practice you barely notice the distinction.

The AUR is a bit like a community cookbook where anyone can contribute recipes. The official repos are the curated menu, tested, maintained, guaranteed to work. The AUR is the full cookbook, vastly more options, but you’re expected to use some judgment about what you try.

BSD: the same idea, different world

BSD systems, FreeBSD, NetBSD, OpenBSD, have their own package managers. FreeBSD uses pkg, which manages binary packages similar to how apt or pacman works:

pkg install git
pkg install vim
pkg upgrade

FreeBSD also has the Ports collection, which is conceptually similar to the AUR: a collection of build scripts for thousands of pieces of software that you compile from source on your own machine. It’s been around since the early 1990s and was actually an inspiration for how Arch’s own packaging system was later designed.

If you ever find yourself on a BSD system, the commands are a little different but the mental model is exactly the same. Same restaurant, slightly different menu, same way of ordering.

Language-level package managers

Here’s something worth pointing out: once you start writing code, you’ll use package managers that have nothing to do with your operating system.

npm manages JavaScript packages. pip manages Python packages. cargo manages Rust crates. composer manages PHP dependencies. gem manages Ruby libraries. These all work on the same principle as system package managers, a central registry, version resolution, automatic dependency management, but they operate at the language level rather than the system level.

The npm install you run inside a project is the same concept as apt install on your system. The pip install requests you run in a Python script is the same concept as brew install wget on your Mac. Same idea, different scope.

Once you see that pattern, it sticks. Every new package manager you encounter, no matter the language or platform, immediately makes sense. The commands are different, but you already understand what’s happening underneath.

And that’s really the point of understanding any of this. Not to memorize the flags, but to understand what the tool is actually doing. When you do, the rest follows naturally.

I Tried CachyOS and Now I Can't Stop Booting Into It

Adrian Jiga — Mon, 16 Mar 2026 18:46:42 +0000

I've been a Linux user for a while now. Not in the "I rice my desktop for eight hours and post it on r/unixporn" way, but in the "I genuinely enjoy understanding what's happening under the hood" way.

My main machine is a MacBook Air M2. It handles everything work-related without complaints: Cypress, Docker, the whole stack. But I have a secondary laptop that was just sitting there, waiting for a purpose. I'd cycled through a few distros on it over time, never fully committing to any of them. Recently I decided to give CachyOS a proper shot.

What I didn't expect was how much I'd actually enjoy using it day to day, well beyond just recording videos.

So what is CachyOS?

CachyOS is an Arch Linux-based distro with one core obsession: making your system as fast as possible.

Most Linux distributions are built to run on as many machines as possible: old ones, new ones, everything in between. That's great for compatibility, but it means they leave a lot of performance on the table if you're running modern hardware. Think of it like a car that's been tuned to run on any fuel, even the cheap stuff. It works, but it's not running at its best.

CachyOS takes a different approach. It targets newer CPUs specifically and compiles its packages to actually take advantage of what your hardware can do. The installer detects your CPU and picks the right optimized build automatically; you don't configure anything, it just handles it. On top of that, it ships with a custom kernel tuned specifically for desktop responsiveness. In plain terms: the system feels snappy. Applications open faster, the desktop stays fluid even when something heavy is running in the background, and that sluggishness you sometimes get on Linux when things are under load is just... less present.

It's not placebo either. I was skeptical going in, but the difference on my secondary laptop is real and noticeable from the first boot.

The installation experience

I want to talk about this because it's one of the things that surprised me most.

CachyOS uses a graphical installer, which means you don't have to manually partition drives or write config files to get up and running. For an Arch-based distro, that's already a big deal. But what stood out was how many choices it actually gives you during installation without making those choices feel overwhelming.

You pick your desktop environment; there are over 17 options, including KDE Plasma, GNOME, Hyprland, and a bunch of tiling window managers if that's your thing. You pick your filesystem. You pick your shell. I went with KDE Plasma, Btrfs, and fish shell, and the whole process took maybe fifteen minutes.

One thing I genuinely appreciated: the installer automatically sets up Btrfs snapshots if you choose Btrfs as your filesystem. That means before every system update, a snapshot is taken automatically. If something breaks, you can roll back from the boot menu. For a rolling release distro where you're always on the latest everything, that safety net is really reassuring.

What's it actually like to use?

KDE Plasma 6.6 on CachyOS feels smooth in a way this laptop hasn't before. Wayland works out of the box, no weird flickering, no scaling issues, no "this works but that doesn't." It just works, which honestly still surprises me every time because Wayland on Linux has historically been a "your mileage may vary" situation.

The terminal is great from the first launch. Fish shell is pre-configured and actually styled nicely, it has syntax highlighting, autosuggestions, and a clean prompt without you having to touch a single config file. In Bash or Zsh you’d have to manually edit the config files to get the same experience.

There's a welcome app called CachyOS-Hello that opens on first boot and it's genuinely useful, not just a launcher for a wiki. It gives you access to system tweaks, a package installer, and kernel management, all in one place. I spent about twenty minutes in there on the first boot just exploring what was available and enabling a few things.

The package installer itself deserves a mention. It's a GUI that covers basically everything you'd install with pacman, and because CachyOS is Arch-based, the AUR is fully available too. You can do everything through the terminal if you prefer, but having a visual alternative is a nice touch, especially on a machine you're setting up fresh and just want to get apps installed quickly.

The community and transparency

This is something I didn't think I'd care about but ended up appreciating quite a bit.

CachyOS has a packages.cachyos.org dashboard where you can see every package in their repositories: which ones come directly from upstream Arch, which ones have been modified, and which PKGBUILDs are custom to CachyOS. You can see exactly what you're running and why. For a distro that's making a lot of changes under the hood, that kind of transparency matters.

The community has also grown a lot. The project tripled in size in 2025, and the Discord and forums are active. When I ran into a small issue during setup, I found a forum thread that addressed it exactly within about three minutes of searching. That's the kind of community support that makes a real difference when you're setting up a new system.

Who is this for?

CachyOS isn't a beginner distro, and I want to be upfront about that.

If you're just getting started with Linux, something like Linux Mint or Manjaro will treat you better. There's more hand-holding, more documentation aimed at newcomers, and a larger safety net when things go wrong. CachyOS is Arch under the hood, which means it's a rolling release and your system is always getting updated to the latest versions of everything. That's exciting, but it also means you should be comfortable reading update notes occasionally and knowing what to do if a package update causes a problem.

But if you've been using Linux for a while, if you know what a rolling release means, if you've felt the pain of AUR packages breaking on Manjaro because of version mismatches, CachyOS is genuinely worth trying. Because it stays in sync with upstream Arch, the AUR just works. No delays, no compatibility headaches. When a new version of a tool comes out, you get it.

And if you have a secondary machine where you can experiment without risking your main setup, there's really no reason not to try it. The worst case is you flash a different ISO. The best case is you find a system that actually makes your hardware feel alive.

Conclusion

I came to CachyOS for OBS and content creation. I stayed because the system itself became genuinely fun to use.

That progression: secondary laptop gathering dust → CachyOS install → actually looking forward to booting into it happened faster than I expected. It's the distro that gave me the full Arch experience without making me earn it the hard way first, and a desktop that finally feels like it's using my hardware properly.

If you're a Linux person with some experience and a bit of curiosity, give it a shot. Flash the ISO, pick KDE Plasma, and see how your hardware feels when it's not being held back.

How I Fell in Love with Claude Code (And Why You Might Too)

Adrian Jiga — Wed, 28 Jan 2026 09:14:42 +0000

I've always been curious about AI coding tools. Like most developers, I saw the hype, tried a few chat-based assistants, and found myself spending more time copying and pasting code between windows than actually solving problems. It felt clunky. I kept going back to my old workflow because it was just... faster.

Then I tried Claude Code, and something changed.

What even is Claude Code?

Claude Code is a command-line tool from Anthropic. You install it, run claude in your terminal, and suddenly you have an AI that can actually see your project, read your files, run commands, and make changes directly. No more copy-pasting. No more explaining your folder structure. It just works with what's already there.

Install

The native installer is the recommended way to install Claude Code. It doesn't require Node.js.

macOS / Linux:

curl -fsSL https://claude.ai/install.sh | bash

Windows (PowerShell):

irm https://claude.ai/install.ps1 | iex

Alternative: npm (if you prefer)

If you'd rather use npm, you'll need Node.js 18 or higher:

npm install -g @anthropic-ai/claude-code

Note: Don't use sudo with npm install as it causes permission issues.

After installation, verify it worked:

claude --version

You should see something like:

2.1.22 (Claude Code)

Authentication

Before you can use Claude Code, you need to authenticate. You have two options:

Option 1: Claude Pro or Max subscription (recommended)

If you have a Claude Pro or Max subscription, just run:

claude

It will open your browser for a one-time OAuth login with your Claude account.

Option 2: API key

If you're using the Anthropic API directly, set your key:

export ANTHROPIC_API_KEY="your-api-key-here"

Add this to your ~/.bashrc or ~/.zshrc to make it permanent. Then reload your shell config:

# If using bash
source ~/.bashrc

# If using zsh
source ~/.zshrc

Starting your first session

Navigate to any project folder and start Claude Code:

cd ~/projects/my-cypress-tests
claude

You'll see a welcome screen and a prompt where you can start typing:

╭─────────────────────────────────────────╮
│ Claude Code                             │
╰─────────────────────────────────────────╯

>

Now you can just type what you want Claude to do:

> Explain the structure of this project

It will read your files and give you an overview. From here, you can ask follow-up questions, request changes, or have it run commands.

My first real use case

I was stuck on a problem that had been eating my afternoon. After upgrading a dependency in one of my projects, a bunch of tests started failing. The error messages weren't helpful, and I couldn't figure out what had changed.

Out of frustration, I opened Claude Code and just typed something like "these tests broke after I upgraded xmlbuilder2, can you help me figure out why?"

What happened next surprised me. It didn't just throw generic suggestions at me. It asked to look at my package.json, examined the failing tests, checked what changed between versions, and found the issue. A method signature had changed in the new version. It even offered to fix it.

Two minutes. I'd been stuck for two hours.

Why it clicked for me

It understands context. This is the big one. When I'm working on my Cypress tests, Claude Code sees my actual project. It knows I'm using Cypress, not Playwright. It sees my folder structure, my custom commands, my fixtures. When it suggests something, it fits.

It lives in the terminal. So much of my work happens in the terminal anyway: running tests, checking logs, debugging CI pipelines. Having an AI right there, in the same environment, just makes sense. I can run a test, see it fail, and immediately ask "why did this fail?" without switching windows.

It learns my patterns. After working with it on a few files, it picked up how I structure my tests, my naming conventions, how I organize things. When I ask it to write something new, it feels like my code, not generic AI output.

Some real examples

Here are some actual things I've used it for.

Debugging test failures

When a test fails and the error isn't helpful, I can pipe the output directly to Claude Code:

npx cypress run --spec "cypress/e2e/api/orders.cy.js" 2>&1 | claude "The test on line 45 is failing with 'expected undefined to equal 200'. Can you check why?"

It reads the test output, examines the test file, sees the API response structure, and usually spots the issue, like a response property that got renamed or nested differently.

Generating tests from existing patterns

Let's say I have a working test for one integration and need a similar one for another. Instead of copy-pasting and manually changing things:

> Create a new test file for the Jaggaer integration following the same pattern as cypress/e2e/integrations/coupa.cy.js

It reads the existing test, understands the structure, and generates a new file with the right assertions and setup. I just review and tweak if needed.

Converting API tests to Postman

This one saved me a lot of time. I had Cypress tests with all our API calls and the dev team wanted a Postman collection:

> Convert the API calls in cypress/e2e/api/orders.cy.js to a Postman collection JSON file

It extracted all the requests, preserved headers and bodies, and even set up environment variables for things like {{baseUrl}}. Two minutes instead of an hour.

Fixing CI pipeline issues

GitHub Actions failing with weird bash errors? Just paste the error:

> My GitHub Action is failing with this error:
> /home/runner/work/_temp/script.sh: line 3: unexpected EOF while looking for matching `"'
> Can you help me fix it?

It explained that my heredoc syntax was being interpreted by the shell and gave me the corrected version with proper quoting.

Quick refactors

Need to rename something across multiple files or update an import pattern?

> Rename the function "getOrderData" to "fetchOrderDetails" in all files under cypress/e2e/

It shows you what it's going to change, you confirm, and it's done.

Useful one-liners

You can also run Claude Code with a direct prompt instead of starting an interactive session:

# Explain what a file does
claude "explain what cypress/support/commands.js does"

# Find potential issues
claude "review cypress/e2e/checkout.cy.js for flaky test patterns"

# Generate something quick
claude "add a custom command to cypress/support/commands.js that waits for an API response"

This is handy when you just need a quick answer or a single change.

Slash commands

Inside an interactive session, Claude Code has built-in slash commands:

/help          - Show all available commands
/clear         - Clear the conversation history
/compact       - Condense conversation to save context
/config        - View or modify settings
/cost          - Show token usage and estimated cost
/doctor        - Check your installation health
/init          - Create a CLAUDE.md file for your project
/review        - Request a code review
/exit          - Exit Claude Code

The /init command is especially useful. It creates a CLAUDE.md file in your project that helps Claude understand your codebase, conventions, and preferences.

What I appreciate most

It asks before changing things. It shows you what it wants to do and waits for you to say yes. This matters when you're working on real projects.

It admits when it's not sure. I've had it tell me "I'm not certain about this specific behavior—want me to check the docs?" That honesty builds trust.

It remembers what you're working on. Within a session, I can say "actually, apply that same fix to the other files too" and it knows exactly what I mean.

It's not magic

I want to be honest here. It's not perfect. Sometimes it suggests things that don't quite work. Sometimes it misunderstands what I'm asking for. Complex refactors still need oversight.

But it's wrong way less often than I expected. And when it is wrong, explaining why usually gets it to a working solution quickly.

Conclusion

I was skeptical of AI coding tools for a long time. Too much hype, too many demos that didn't hold up on real projects. Claude Code changed how I think about this.

That progression skepticism -> curiosity -> trying it on a real problem -> actually relying on it happened faster than I expected. It's the tool that took debugging from frustrating to manageable, and repetitive tasks from draining to quick.

If you've been curious about AI coding assistants but found them clunky, give Claude Code a try. Start with something that's been frustrating you. You might be surprised.

More information

You can find more usage patterns and documentation here:

Getting Started with Express.js: Middlewares Explained

Adrian Jiga — Tue, 02 Sep 2025 06:34:20 +0000

If you’re building with Express.js, you’ve definitely seen the term middleware thrown around. At first, it might seem like an abstract concept, but once you understand it, middleware becomes one of the most powerful parts of Express.

First, make sure to read part 1 here, where I cover the basics.

In this post, I’ll walk you through what middleware is, how to use it effectively, and some common mistakes you’ll want to avoid. By the end, you’ll know exactly how to structure your middleware so your apps stay clean, efficient, and bug-free.

What is Middleware in Express?

Middleware is just a function that runs between the time your server receives a request and when it sends back a response.

Think of it as “in-between” logic. The request comes in → middleware runs → response goes out.

In fact, even a basic Express route handler is technically middleware:

app.get("/users", (req, res) => {
  res.send("Users page")
})

This handler takes in a request (req), a response (res), and has the potential to take in next, which determines whether or not Express should move on to the next piece of middleware. That’s the key idea.

The Anatomy of Middleware

A middleware function typically looks like this:

function myMiddleware(req, res, next) {
  // Do something with req or res
  console.log("Middleware ran")

  // Call next() so the next function in line runs
  next()
}

The three parameters are:

req → the incoming request object
res → the outgoing response object
next → a function that passes control to the next middleware

If you don’t call next(), the chain stops there.

Global Middleware with app.use

If you want middleware to run for every single request, you can use app.use:

function logger(req, res, next) {
  console.log("Request URL:", req.originalUrl)
  next()
}

app.use(logger)

Now, no matter what route you hit, this logger will run first.

Important: Middleware runs in the order it’s defined. If you place your logger after your routes, it won’t run unless you explicitly call next() inside those routes.

Route-Specific Middleware

Sometimes, you only want middleware to apply to a single route. In that case, you can pass middleware functions directly into your route definitions:

function auth(req, res, next) {
  if (req.query.admin === "true") {
    req.admin = true
    next()
  } else {
    res.send("Not authorized")
  }
}

app.get("/users", auth, (req, res) => {
  console.log("User is admin:", req.admin)
  res.send("Users page")
})

Here’s what happens:

The auth middleware runs first.
If the query string includes ?admin=true, it calls next().
Otherwise, it stops the chain and sends back “Not authorized.”

Passing Data Between Middleware

Notice in the example above, we set req.admin = true. Since each middleware shares the same req and res, you can attach custom properties and access them later.

app.get("/users", auth, (req, res) => {
  if (req.admin) {
    res.send("Welcome, Admin!")
  } else {
    res.send("Users page")
  }
})

Common Mistake: Forgetting return

One of the most common bugs with middleware is forgetting that next() doesn’t stop your function, it just calls the next middleware, then comes back and continues running your code.

function auth(req, res, next) {
  if (req.query.admin === "true") {
    req.admin = true
    next()
  }
  res.send("Not authorized") // Still runs!
}

This causes:

Error: Cannot set headers after they are sent to the client

Fix: use return:

function auth(req, res, next) {
  if (req.query.admin === "true") {
    req.admin = true
    return next()
  }
  return res.send("Not authorized")
}

Middleware Runs Before and After `next()`

Code after next() still runs, but only after the next middleware finishes.

function logger(req, res, next) {
  console.log("Before next()")
  next()
  console.log("After next()")
}

app.get("/users", (req, res) => {
  console.log("Users page")
  res.send("Done")
})

Output:

Before next()
Users page
After next()

This allows you to do things before and after route handlers.

Middleware in a Nutshell

Middleware = a function with (req, res, next)
Runs in order, top to bottom
Call next() to continue the chain
Attach data to req or res to share between middleware
Always return if you don’t want code to continue after next()
Can run before and after the next middleware

Once you internalize this, you’ll see middleware everywhere: logging, authentication, error handling, validation, body parsing, CORS, etc.

Final Thoughts

Middleware is at the heart of Express. It may look like just some functions chained together, but with the right design, you can keep your app organized, reusable, and powerful.

Next time you’re building an Express app, think about what belongs in middleware (e.g. logging, auth, validation, error handling), and your code will thank you.

Getting Started with Express.js: The Basics

Adrian Jiga — Thu, 28 Aug 2025 19:27:57 +0000

When you first dive into backend development with Node.js, it doesn’t take long before you bump into Express.js. It’s practically the default framework for building web servers and APIs in JavaScript, and for good reason, it simplifies the otherwise clunky task of handling requests, responses, and routes.

In this article, we’ll take a thorough look at Express:

what it is and why it exists,
how to set up a simple project,
how routing works in practice,
and a few must-know tricks to get you comfortable.

This will lay the foundation for the next article in the series (Part 2), where we’ll unlock the real magic of Express: middleware.

Why Use Express.js Instead of Plain Node?

You might be thinking: “Wait, Node.js can already create servers, why do I need Express?”

That’s true, but here’s what a basic raw Node server looks like:

const http = require("http")

const server = http.createServer((req, res) => {
  if (req.url === "/" && req.method === "GET") {
    res.writeHead(200, { "Content-Type": "text/plain" })
    res.end("Home Page")
  } else if (req.url === "/users" && req.method === "GET") {
    res.writeHead(200, { "Content-Type": "text/plain" })
    res.end("Users Page")
  } else {
    res.writeHead(404, { "Content-Type": "text/plain" })
    res.end("Not Found")
  }
})

server.listen(3000, () => {
  console.log("Server running on http://localhost:3000")
})

It works, but it gets messy fast. You have to manually check URLs, methods, and headers.

Now look at the equivalent in Express:

const express = require("express")
const app = express()

app.get("/", (req, res) => {
  res.send("Home Page")
})

app.get("/users", (req, res) => {
  res.send("Users Page")
})

app.listen(3000, () => {
  console.log("Server running on http://localhost:3000")
})

Much cleaner. Express handles the boilerplate for you so you can focus on logic.

Setting Up Express

Create a project folder and initialize it:

mkdir express-intro
cd express-intro
npm init -y

Install Express:

npm install express

Create a file called server.js and add:

const express = require("express")
const app = express()

// A simple route
app.get("/", (req, res) => {
  res.send("Hello from Express!")
})

// Start the server
app.listen(3000, () => {
  console.log("Listening on http://localhost:3000")
})

Run the server:

node server.js

Go to http://localhost:3000 and boom, you’ve got a web server.

How Routing Works in Express

Express gives you an intuitive way to define routes. A route is just a combination of an HTTP method and a path.

GET Requests

app.get("/about", (req, res) => {
  res.send("About page")
})

Visiting http://localhost:3000/about will trigger this function.

POST Requests

app.post("/submit", (req, res) => {
  res.send("Form submitted")
})

This would respond when you submit a form with POST /submit.

Dynamic Routes

You can use route parameters:

app.get("/users/:id", (req, res) => {
  res.send(`User ID: ${req.params.id}`)
})

Visiting http://localhost:3000/users/42 would return User ID: 42.

Query Parameters

Express makes query strings easy too:

app.get("/search", (req, res) => {
  const term = req.query.q
  res.send(`You searched for: ${term}`)
})

Visiting http://localhost:3000/search?q=node responds with You searched for: node.

Serving Static Files

What if you want to serve an HTML file or an image? Express has you covered:

app.use(express.static("public"))

Now any files in your public/ folder (like index.html or style.css) will be automatically served.

For example: http://localhost:3000/style.css → serves /public/style.css.

Sending JSON Responses

Since APIs often need to send JSON, Express makes this trivial:

app.get("/api/users", (req, res) => {
  res.json([
    { id: 1, name: "Alice" },
    { id: 2, name: "Bob" }
  ])
})

Visiting /api/users will give you structured JSON, no extra setup required.

Handling 404 Errors

It’s a good practice to handle unknown routes:

app.use((req, res) => {
  res.status(404).send("Sorry, page not found")
})

This will catch any route that wasn’t matched earlier.

Why Express Feels So Flexible

The magic of Express is its simplicity. It doesn’t force you into a strict structure. You can:

Start with just a single file for a prototype.
Gradually break routes into separate files as your app grows.
Add middlewares for logging, authentication, validation, and more (coming in Part 2).

It’s like Lego blocks: small and simple by themselves, but powerful when combined.

What’s Next: Middleware

So far, we’ve built an Express app that can:

serve routes,
return text, HTML, or JSON,
handle query strings and parameters,
and even serve static files.

But every real-world app has “stuff” that needs to happen before (or after) a request hits your route handler: logging, authentication, input validation, error handling.

That’s where middlewares come in.

In Part 2, we’ll break down middlewares in detail how they works, how to write your own, and how to avoid common mistakes. That’s when Express really starts to shine.

The Daily Habit That Sets Apart Great Engineers

Adrian Jiga — Sun, 24 Aug 2025 12:53:36 +0000

After a decade of working alongside engineers at different career stages, I’ve noticed something striking: the most adaptable and innovative engineers share a common trait that goes beyond raw technical skill or natural talent.

It’s not about being the smartest person in the room or having the perfect educational background. It’s about cultivating a deliberate practice of continuous learning that extends far beyond formal education.

The Learning Divide

While average engineers often plateau after mastering their initial tech stack, exceptional ones treat learning as an ongoing process.

This isn’t about learning for learning’s sake. It’s strategic curiosity that compounds over time, creating engineers who can:

Navigate technology shifts without panic
See patterns across different domains
Contribute meaningfully to architectural decisions
Mentor others effectively

How the Habit Forms

The path to continuous learning isn’t always intentional. I’ve observed several common catalysts:

Necessity-driven learning: Project pivots or role changes force rapid skill acquisition. Engineers who embrace this challenge rather than resist it often discover they enjoy the process.

Curiosity-driven exploration: Some engineers naturally gravitate toward understanding how things work under the hood, leading them down fascinating technical rabbit holes.

Community involvement: Contributing to open source projects or engaging with technical communities creates a feedback loop of learning and teaching.

Cross-functional exposure: Working closely with product, design, or data teams broadens perspective and reveals new problem-solving approaches.

Making Learning Sustainable

The key isn’t cramming more study time into already packed schedules. It’s about building learning into your existing workflow:

Learn through work: Choose projects that stretch your skills slightly. Volunteer for initiatives using unfamiliar technologies. Document what you discover for future reference.

Embrace productive struggle: When you encounter something confusing, resist the urge to immediately ask for help. Spend 15-20 minutes trying to figure it out first as this builds problem-solving muscle memory.

Teach to learn: Explaining concepts to colleagues, writing internal documentation, or giving tech talks deepens your understanding and reveals knowledge gaps.

Stay selectively informed: Rather than trying to track every new framework, focus on understanding underlying principles and emerging patterns that transcend specific tools.

The Compounding Returns

Continuous learning creates advantages that multiply over time:

Career resilience: When technologies shift or markets change, continuous learners adapt faster and with less stress.

Enhanced problem-solving: Exposure to diverse approaches provides a richer toolkit for tackling complex challenges.

Increased influence: Engineers who understand multiple domains can bridge communication gaps and drive better technical decisions.

Personal satisfaction: Learning new things keeps work engaging and prevents the stagnation that leads to burnout.

Overcoming Common Obstacles

“I don’t have time”: Start with just 15 minutes daily. Read one technical article during lunch. Listen to a podcast during your commute. Small, consistent efforts compound.

“I don’t know what to learn: Follow your frustrations. What slows you down at work? What decisions do you wish you understood better? Let problems guide your learning priorities.

“Information overload”: Focus on fundamentals over frameworks. Understand networking principles rather than memorizing API endpoints. Learn design patterns rather than chasing the latest JavaScript library.

“I learn but forget”: Apply new knowledge quickly through side projects or work tasks. Teaching others helps solidify understanding.

The Long Game

Continuous learning isn’t about becoming a generalist who knows everything superficially. It’s about developing the confidence and capability to learn anything you need, when you need it.

The engineers I most admire aren’t necessarily the ones who knew the most at any given moment, they’re the ones who could quickly get up to speed on whatever the situation demanded.

In a field where change is the only constant this skill becomes a competitive advantage that grows stronger with time.

Why Every JavaScript Developer Should Know npm-run-all (Your Life Gets Easier)

Adrian Jiga — Fri, 15 Aug 2025 19:48:44 +0000

If you want a platform-independent way to run multiple npm scripts with a single command, without shell hacks or editor specific tasks, use npm-run-all2. It’s a maintained fork of npm-run-all and a drop-in replacement with the same commands: run-p, run-s, and npm-run-all.

This guide shows practical examples you can paste into package.json.

Why npm-run-all2?

It is cross-platform: works the same on macOS, Linux, and Windows and it has simple shorthands:

run-p - run scripts in parallel
run-s - run scripts in sequence

Useful flags: labels, glob patterns, race mode, continue-on-error, and max concurrency: --race, --continue-on-error, --max-parallel, --print-label.

Install

If you've never used the original:

npm i -D npm-run-all2

Migrating from npm-run-all:

npm remove npm-run-all
npm i -D npm-run-all2

Usage (in parallel)

Use parallel for independent long-running tasks (e.g., dev servers, watchers). Let's say you have this in your package.json file:

{
  "scripts": {
    "frontend": "cd frontend && npm run dev",
    "backend": "cd backend && npm run start:dev",
    "start:dev": "run-p frontend backend"
  }
}

Now, if you run

npm run start:dev

you will have both the backend and the frontend servers up and running.

Usage (in sequence)

Use sequential when you need to run scripts in sequence (e.g. format > lint > compile). Let's say you have this in your package.json file:

{
  "scripts": {
    "format": "prettier --write",
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
    "compile": "tsc -p tsconfig.json",
    "build": "run-s format lint compile"
  }
}

Now, if you run

npm run build

you will have basically executed three commands one after the other: npm run format > npm run lint > npm run compile.

More information

You can find more usage patterns and combinations here at these URLs:

JavaScript is fun to learn, if you do it properly

Adrian Jiga — Mon, 11 Aug 2025 13:45:12 +0000

I began my programming journey in high school, where my “Informatics” teacher taught us Pascal. He was very strict about the rules he set—there was no room for creativity; we could only do exactly what he assigned. In college, we studied Java and C++, which I found overly verbose and, to be honest, difficult to read at the time.

QA Automation job

After college, I got a job as a QA Automation Engineer, where I worked with Selenium and Java. Since I never really enjoyed Java (and still don’t), it took me a while to understand how Selenium interacts with it and why it works the way it does.

Studying web dev

A few years into my career, I decided to learn web development, so I started researching which technologies were the most widely used and which tech stacks were considered the best. Like most beginners in web development, I landed on HTML, CSS, and JavaScript. I was already somewhat familiar with HTML and CSS from my QA Automation work, but JavaScript was new to me. At first, I didn’t think too much about it, just that it looked a bit cleaner than Java, but as I learned more about it and discovered what it could do, I slowly began to fall in love with it.

Over time, JavaScript became more than just another technology I wanted to “try out”. It became the language I truly connected with. I didn’t dive straight into building complex applications. Instead, I took my time to study the fundamentals: understanding variables, loops, functions, and how the DOM worked. My first small victories came from writing simple scripts that updated elements on an HTML page—changing text, hiding or showing content, adding a bit of interactivity. Seeing those changes happen instantly in the browser felt magical compared to my earlier programming experiences.

The turning point

Once I felt comfortable with the basics, I wanted to take things further, so I started learning Vue. This opened up a whole new way of thinking about building user interfaces, structuring components, managing state, and writing cleaner, more maintainable code. It was exciting to see how JavaScript could power dynamic applications without drowning me in complexity. From there, I moved on to studying Node.js, which was a turning point. I realized I could now use JavaScript on the back end too, meaning I could handle an entire project using a single language from start to finish.

Conclusion

That gradual progression, fundamentals -> simple scripts -> Vue -> Node.js, allowed me to really understand JavaScript instead of just skimming the surface. It’s the language that took me from being someone who mainly tested software to someone who could build it and that's what I wanted in the end, to build software.

Forem: Adrian Jiga

6 Things About The Terminal That Confuse Everyone (And Nobody Warns You About)

1. When it says nothing, that means it worked

2. Your password is invisible and that’s intentional

3. The $ in tutorials is not part of the command

4. Ctrl+C does not copy, it kills

5. If you accidentally open Vim, here’s how to get out

6. Different tutorials show different commands and they’re all correct

You’ve Been Installing Software the Hard Way

What is a package manager, actually?

Windows: the platform that came late to this

macOS: Homebrew became the de facto standard

Linux: this is where it gets interesting

The AUR: Arch’s unique addition

BSD: the same idea, different world

Language-level package managers

I Tried CachyOS and Now I Can't Stop Booting Into It

So what is CachyOS?

The installation experience

What's it actually like to use?

The community and transparency

Who is this for?

Conclusion

How I Fell in Love with Claude Code (And Why You Might Too)

What even is Claude Code?

Install

Authentication

Starting your first session

My first real use case

Why it clicked for me

Some real examples

Debugging test failures

Generating tests from existing patterns

Converting API tests to Postman

Fixing CI pipeline issues

Quick refactors

Useful one-liners

Slash commands

What I appreciate most

It's not magic

Conclusion

More information

Getting Started with Express.js: Middlewares Explained

What is Middleware in Express?

The Anatomy of Middleware

Global Middleware with app.use

Route-Specific Middleware

Passing Data Between Middleware

Common Mistake: Forgetting return

Middleware Runs Before and After next()

Middleware in a Nutshell

Final Thoughts

Getting Started with Express.js: The Basics

Why Use Express.js Instead of Plain Node?

Setting Up Express

How Routing Works in Express

GET Requests

POST Requests

Dynamic Routes

Query Parameters

Serving Static Files

Sending JSON Responses

Handling 404 Errors

Why Express Feels So Flexible

What’s Next: Middleware

The Daily Habit That Sets Apart Great Engineers

The Learning Divide

How the Habit Forms

Making Learning Sustainable

The Compounding Returns

Overcoming Common Obstacles

The Long Game

Why Every JavaScript Developer Should Know npm-run-all (Your Life Gets Easier)

Why npm-run-all2?

Install

Usage (in parallel)

Usage (in sequence)

More information

JavaScript is fun to learn, if you do it properly

QA Automation job

3. The `$` in tutorials is not part of the command

Middleware Runs Before and After `next()`