Forem: Rodrigo Oler

How to Detect and Remove the Axios Malware from Your Project

Rodrigo Oler — Tue, 31 Mar 2026 13:15:48 +0000

If your project may have installed the malicious Axios releases, treat it like a real incident.

The fastest path is to verify exposure, contain execution, and rotate anything sensitive that may have been available during the install window.

Start with verification

Use the tools you already have:

npm ls axios
npm ls plain-crypto-js
grep -n "axios@1.14.1\|axios@0.30.4\|plain-crypto-js@4.2.1" package-lock.json

If you are using pnpm or yarn, inspect the corresponding lockfile and workspace tree as well.

The goal is not just to know whether Axios appears in the repository.
The goal is to know whether the malicious versions were resolved and installed.

Treat the install window as suspicious

The public writeups from Aikido Security, Socket, Semgrep, and StepSecurity all point to the same response pattern: assume exposure until you have evidence otherwise.

Look for:

installs that ran postinstall or other scripts
temporary files created during package installation
background child processes spawned by npm
outbound traffic during dependency install windows

If you have EDR or SIEM visibility, focus on process lineage and network logs first. That is where a lot of the evidence will show up.

Contain first

Do not wait for a perfect forensic picture before you act.

Start containment with:

npm ci --ignore-scripts

Then rebuild from a clean lockfile and package manifest.

If the affected package executed on a machine or in CI where secrets were available, rotate:

API keys
npm tokens
cloud credentials
CI secrets
signing keys

If you are unsure whether a secret was exposed, treat it as exposed.

What to check on endpoints

Search for:

unusual curl, python3, or shell execution during dependency install
files written to /tmp
unexpected child processes from npm
connections to attacker-controlled infrastructure

If you think an affected machine executed the package, assume the install path was a compromise path until proven otherwise.

What to keep in place after cleanup

Once you contain the incident, keep a few defensive defaults:

pin dependencies more aggressively
review lockfile changes in PRs
keep npm ci --ignore-scripts in CI
restrict outbound access from build jobs where possible
document the response path for future dependency compromises

That makes the next incident much easier to handle.

Useful tools

The tools most often mentioned in the incident response guidance are:

Snyk
Socket
Semgrep

Those tools do not replace response work, but they help you move faster.

Originally published on my blog.

How to Protect JavaScript Projects Against Supply Chain Attacks

Rodrigo Oler — Tue, 31 Mar 2026 13:15:02 +0000

The Axios incident is a useful reminder that npm risk is not abstract.

A practical defense model for JavaScript projects starts with a few boring but effective controls.

The baseline

Use these defaults:

pin versions and keep lockfiles committed
run npm ci --ignore-scripts in CI
review dependency changes like code changes
use short-lived credentials where possible
rotate secrets after suspicious installs
separate build credentials from runtime credentials

That will not eliminate supply chain risk, but it removes a lot of avoidable exposure.

Why this matters

The main mistake teams make is assuming supply-chain risk is just a vulnerability scanning problem.

It is broader than that.

It is a process problem:

install policy
dependency review
secret scope
CI isolation
incident response

If those pieces do not work together, a malicious package has a much easier time moving through your system.

What to put in CI

At minimum, I would recommend:

npm ci --ignore-scripts

Then add policy around:

lockfile diffs
minimum release age rules for critical packages
package allowlists for sensitive environments
alerts for unexpected dependency ownership changes

Tools like Renovate and Dependabot help, but only if you configure them with policy instead of treating them as passive update bots.

Why the Axios case is useful

The Axios incident is not interesting because it was unique.
It is interesting because it was plausible.

The attack worked because it used the same trust paths teams already rely on every day: a popular package, a maintainer account, and an install-time hook.

That is why the best defenses are often boring, repeatable controls.

A practical checklist

Before you ship, check that you can answer these questions:

Who reviews dependency changes?
Which builds can execute install scripts?
Which secrets are present in CI?
What happens if a package becomes compromised tomorrow?
How fast can you rotate credentials if that happens?

If those answers are fuzzy, that is where to start.

Originally published on my blog.

Axios Supply Chain Attack: How the 2026 npm Compromise Happened

Rodrigo Oler — Tue, 31 Mar 2026 13:15:01 +0000

Axios was compromised on March 31, 2026 through a supply-chain attack that turned a trusted npm dependency into a cross-platform malware delivery vector.

What makes this incident worth studying is not just the package name. It is the way the attack combined account compromise, malicious package publication, install-time execution, and platform-specific behavior.

The public reporting from StepSecurity, The Hacker News, and Snyk points to malicious releases axios@1.14.1 and axios@0.30.4, plus a staged package named plain-crypto-js@4.2.1. The payload used postinstall, then branched by operating system and reached out to attacker infrastructure.

What happened

The attacker did not need to make Axios look radically different.
They only needed the package to behave differently during installation.

That is what makes the incident dangerous:

it happened inside a trusted package
it executed during install
it behaved differently on macOS, Windows, and Linux
it used a staged dependency to make the chain less obvious

Why this matters

Many teams still think about package compromise as a rare edge case.
The Axios incident shows the opposite. A popular package can become a malware delivery vehicle without changing its role in the codebase or its reputation in the ecosystem.

That means dependency trust is not stable. It needs to be managed.

What defenders should focus on

The practical lessons are straightforward:

treat install scripts as a real risk surface
inspect lockfiles, not just manifests
run CI with npm ci --ignore-scripts
rotate secrets after suspicious installs
look for temporary files and unusual outbound traffic during dependency installation
keep runtime and CI environments separated as much as possible

If a package ran in an environment with credentials, assume those credentials may have been exposed until proven otherwise.

A simple mental model

When you review incidents like this, think in layers:

how the package was compromised
how the payload executed
how the attacker gained persistence or second-stage execution
what data or credentials were present at install time
what the team can do differently in CI and developer machines

That model keeps the response practical instead of emotional.

What to check first

If you suspect exposure, start with:

npm ls axios
npm ls plain-crypto-js
grep -n "axios@1.14.1\|axios@0.30.4\|plain-crypto-js@4.2.1" package-lock.json

Then check:

CI logs for installs that ran scripts
developer machines that used the affected lockfile
/tmp or other writable paths for suspicious files
outbound traffic during dependency installation

The real takeaway

The important lesson is not just that Axios was compromised.
It is that supply chain risk is now a normal part of JavaScript security work.

If you build and ship JavaScript software, you need a response path for upstream trust failures before they happen.

That includes install policy, secret rotation, dependency review, and incident response.

Originally published on my blog.

Pyth Oracle: A Simple Way to Integrate Price Feeds with Bun and Elysia

Rodrigo Oler — Tue, 31 Mar 2026 13:13:57 +0000

If you need market data in a clean, modern stack, Pyth is one of the easiest oracle systems to work with.

The reason is simple: Pyth gives you real-time price feeds, and its API surface is built for developers. For off-chain integration, Hermes exposes those updates through a web API. For on-chain use, Pyth provides the contract-side update flow you use to verify and read prices on the target chain.

That makes Pyth useful in two different places:

as a price source for backend services
as an oracle layer for smart contracts

For a lot of teams, the off-chain side is where the fastest value appears first.

Why Pyth feels easy to integrate

Pyth is not trying to be a generic data platform. It is focused on market data, so the mental model stays simple:

choose the feed you want
fetch the latest update
expose it in your app
use it where your product needs a trusted price

Pyth’s Hermes service is the cleanest way to start if you want REST access. It serves the latest price update data through an API, and the docs also show that Pyth has a broader API reference for on-chain and off-chain integrations.

That is a good fit for teams that want to move quickly without wiring up a large data stack.

Why Bun works well here

Bun is a very natural fit for this kind of integration because it gives you:

a fast runtime
built-in fetch
TypeScript support out of the box
easy package management

In practice, that means you can write a small service that fetches oracle data and exposes it through a REST endpoint without much ceremony.

Why Elysia makes the REST layer nicer

Elysia is a strong match for Bun because it is built to be ergonomic, type-safe, and fast to wire up.

For a tiny oracle service, that matters more than people think:

route definitions stay readable
request validation is easy to add
the code stays close to the actual API contract
you can expose OpenAPI docs if you want the service to be self-describing

This is the kind of setup that stays pleasant even when the service grows.

A minimal Bun + Elysia example

Here is a simple REST wrapper around Hermes:

import { Elysia, t } from 'elysia';

const app = new Elysia()
  .get(
    '/price/:feedId',
    async ({ params, set }) => {
      const url = new URL('https://hermes.pyth.network/v2/updates/price/latest');
      url.searchParams.append('ids[]', params.feedId);

      const response = await fetch(url);

      if (!response.ok) {
        set.status = 502;
        return {
          error: 'Failed to fetch price feed',
        };
      }

      const feeds = (await response.json()) as Array<{
        id: string;
        price: {
          price: string;
          conf: string;
          expo: number;
          publish_time: number;
        };
      }>;

      const feed = feeds[0];

      if (!feed) {
        set.status = 404;
        return {
          error: 'Price feed not found',
        };
      }

      return {
        id: feed.id,
        price: feed.price.price,
        confidence: feed.price.conf,
        exponent: feed.price.expo,
        publishedAt: feed.price.publish_time,
      };
    },
    {
      params: t.Object({
        feedId: t.String(),
      }),
    },
  )
  .listen(3000);

console.log(`Pyth proxy running on http://localhost:${app.server?.port}`);

The pattern is straightforward:

the client calls your API
your API calls Hermes
your API returns a clean JSON shape to the rest of your system

That is usually enough to get a production-friendly integration started.

When this pattern is useful

This setup works especially well for:

dashboards that need live asset prices
trading tools
liquidation monitors
risk checks
internal services that need a stable oracle adapter

It is also a nice boundary if you do not want every frontend or service to know about oracle-specific details.

What to keep in mind

The biggest mistake is treating oracle data like plain public JSON.

You still need to think about:

feed freshness
precision and decimals
fallback behavior
stale data handling
whether the value is meant for display, decisions, or on-chain settlement

If the price is going into a smart contract, use the chain-side integration and follow the update flow from the docs.

If the price is only for your app or backend, Hermes through Bun + Elysia is a very clean path.

Bottom line

Pyth is easy to integrate because it keeps the problem focused: real market data, exposed through a developer-friendly API.

With Bun and Elysia, you can turn that into a tiny REST service very quickly. That gives you a neat separation between price feeds, your backend logic, and whatever UI or smart contract consumes the data.

For teams that want to move fast without making the oracle layer complicated, this is a very practical stack.

Originally published on my blog.

Why Hono + Bun Is a Strong Default for New JavaScript Backends

Rodrigo Oler — Tue, 31 Mar 2026 13:13:55 +0000

If you are starting a new JavaScript backend today, Hono with Bun is one of the most sensible combinations you can pick.

Not because it is trendy. Not because it is the smallest stack on paper. It is a strong default because it removes a lot of the usual friction: startup time, package-manager overhead, framework bloat, and runtime lock-in.

That matters more on new projects than on old ones. Greenfield code has a rare advantage: you can choose a stack based on current tradeoffs instead of legacy constraints. Hono and Bun are worth a serious look because they optimize for exactly that moment.

What Hono and Bun actually are

Hono is a small web framework built on Web Standards. Its official docs describe it as fast, lightweight, and compatible with many JavaScript runtimes, including Bun, Node.js, Deno, Cloudflare Workers, Fastly, and others.

Bun is an all-in-one JavaScript and TypeScript toolkit. It gives you a runtime, package manager, test runner, and bundler in a single executable. Its docs emphasize fast startup, built-in tooling, and Node.js compatibility.

Together, they cover two different layers of the stack:

Hono handles HTTP routing, middleware, and request handling.
Bun handles the runtime, package installation, scripts, tests, and bundling.

That combination reduces the number of tools you need to stitch together before you can ship something useful.

Where the performance comes from

Performance is the main reason people reach for this stack, but it is worth being precise about what “fast” means here.

Hono is fast because it stays close to the platform

Hono is designed around Web Standard APIs instead of inventing a large framework abstraction. That keeps the runtime surface area small and makes it easier to run the same app across multiple environments.

Its docs also highlight a few performance-related choices:

RegExpRouter is designed for very fast route matching.
hono/tiny is intentionally small, with a minimal footprint.
The framework avoids unnecessary dependencies.

That does not magically make every app fast. It does mean the framework itself is less likely to become the bottleneck.

Bun is fast because the toolchain is integrated

Bun’s performance story is broader than the runtime alone. It is fast because the developer workflow is built into one tool.

Instead of waiting on a separate package manager, test runner, and bundler, you get:

quick installs
quick startup
fast script execution
built-in testing
built-in bundling

Bun’s docs describe it as a fast, all-in-one toolkit and note that it is powered by JavaScriptCore under the hood. That gives it a very different profile from the usual Node.js + external-tooling setup.

The practical result is less time spent waiting on scaffolding, cold starts, dependency installs, and repetitive local workflows.

The real win is system-level speed

The biggest mistake is thinking this stack is only about raw request throughput.

In practice, the speed comes from the whole system:

the framework is lean
the runtime starts quickly
the tooling is built in
the app can stay portable across runtimes

That combination improves both local development and deployment-time behavior.

Who maintains them

For a new project, maintainership matters almost as much as performance. Fast software with weak stewardship is a future problem.

Hono is maintained by Yusuke Wada, with router work attributed in the project to Taku Amano and the wider Hono contributor community. The public repository shows Hono as a long-lived open source project with active contributors.

Bun is maintained by the Oven team, via the oven-sh/bun project, and it also has a large contributor base. That matters because Bun is not a side experiment anymore. It is a substantial, actively developed runtime and toolkit.

The important part is not just that both projects are open source. It is that both are moving quickly while still being built around clear ideas:

Hono: standards-first, portable, small
Bun: integrated, fast, low-friction

That gives them a healthier long-term shape than a lot of “fast” tools that rely on one narrow implementation trick.

Why this is a good choice for new projects

If you are starting from zero, Hono + Bun gives you a very clean baseline.

1. You get a smaller decision surface

New projects often waste time on framework debates that have nothing to do with the product.

With this stack, you can move quickly without assembling a large architecture first. Hono gives you routing and middleware without excess ceremony. Bun gives you the surrounding tools without forcing a separate ecosystem of scripts and dependencies.

That makes the first commit easier and the next ten commits less annoying.

2. You stay closer to web standards

Hono’s standards-based approach makes future migration easier. If you later need to move between Bun, Node.js, serverless edge platforms, or containerized services, the app code is less likely to need a rewrite.

That portability is especially valuable for:

APIs
internal dashboards
edge functions
proxies and middleware services
small backends that may grow over time

In other words, you are not just buying speed. You are buying optionality.

3. Bun reduces the cost of the boring parts

Most projects are slowed down by boring work, not hard work.

Package installs, test runs, local scripts, and build steps happen constantly. Bun makes those chores cheaper. That improves feedback loops for the whole team, which is where most productivity gains actually come from.

For a new project, that is a strong advantage because you feel it immediately on day one.

4. The ecosystem fit is good for modern backends

If your backend is mostly:

JSON APIs
auth flows
CRUD endpoints
edge-friendly logic
small composition-heavy services

then Hono is a natural fit. It has the ergonomics of a lightweight framework without locking you into a heavy abstraction layer.

If your team also wants a modern local workflow, Bun fits that same philosophy well.

A minimal example

This is the kind of setup that shows why the stack feels so clean:

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello from Hono on Bun'))

export default app

You can run code like this with very little setup, and that is exactly the point. For a new service, fewer moving parts usually means fewer ways for the project to become sluggish later.

When I would not pick it

No stack is universally correct.

I would hesitate if:

the team needs maximum Node.js compatibility with very old packages
the service depends on niche native modules
the project is already deeply standardized on another runtime
the organization prefers very conservative tooling over speed and portability

Those are valid reasons to stay with a more established stack.

But if you are building something new and you want a fast, modern default, Hono + Bun is hard to ignore.

Bottom line

Hono and Bun are a good pairing because they solve adjacent problems well.

Hono gives you a small, standards-based framework that works across runtimes. Bun gives you a fast runtime and a single toolchain for installs, tests, builds, and scripts. The result is a stack that is simple to start, fast to iterate on, and flexible enough to survive early product changes.

That is why I would seriously consider it for any new JavaScript backend, especially if the project needs to move quickly without creating a lot of long-term framework debt.

Originally published on my blog.

Why Daily Standups Are Becoming Useless in the AI Era

Rodrigo Oler — Sat, 28 Mar 2026 22:00:14 +0000

Daily standups were supposed to improve coordination.

In practice, they often became a ritual that burns engineering time without giving much back. The old 15-minute promise sounds harmless, but in most real teams it becomes 30 minutes, 1 hour, or even 1 hour 30 minutes once the conversation starts and people wait their turn.

Strictly speaking, "daily" is the cadence and "standup" is the ceremony. In practice, people just use "daily" as shorthand for the meeting itself.

That is where the math gets ugly.

Why it used to make sense

Standups were useful when teams had poor visibility and weak async tooling. They helped surface blockers, expose dependencies, and give managers a quick snapshot of progress.

The problem is that many companies kept the ceremony long after the reason for it weakened.

Today, engineers already have:

ticket boards
pull request summaries
commit history
Slack updates
AI-generated status recaps

If the status already exists in the system of record, forcing the whole team into a synchronous update ritual is usually redundant.

The real cost

The meeting itself is not the full cost. The expensive part is the context switching before and after it.

Let’s make the assumptions explicit:

5 workdays per week
one daily standup every workday
everyone attends
the realistic range is 30 minutes to 1 hour 30 minutes per day

Cost per engineer

If the daily lasts 30 minutes:

per week: 2.5 hours
per month: 10.8 hours
per year: 130 hours

If the daily lasts 1 hour 30 minutes:

per week: 7.5 hours
per month: 32.5 hours
per year: 390 hours

A single engineer can lose 130 to 390 hours per year to a ritual that is supposed to save time.

Visualizing the waste

The charts make the hidden tax easier to see.

6-person startup

If the team has 6 people:

30 minutes per day = 780 hours per year
1 hour 30 minutes per day = 2,340 hours per year

That is roughly 0.4 to 1.1 full-time work-years every year.

300-person company

If the company has 300 people:

30 minutes per day = 39,000 hours per year
1 hour 30 minutes per day = 117,000 hours per year

That is roughly 18.8 to 56.3 full-time work-years every year.

What AI changed

AI did not remove the need for communication. It removed a lot of the manual work that used to justify the meeting.

Teams can now get:

better summaries
faster blocker detection
cleaner async updates
more visible project state

So the daily often becomes a low-value repetition of information people already have.

What should replace it

Not silence. Better communication.

For most teams, that means:

async updates in Slack, Linear, Jira, or Notion
clear ownership
visible blockers
short syncs only when a real decision or dependency needs conversation

If the team still needs a live meeting, it should be because it is solving something that cannot be solved async.

Reading yesterday’s task list is not that.

The rule I would use

keep a daily only if it consistently removes blockers faster than async communication
otherwise, replace it with written updates or a few syncs per week
reserve live meetings for decisions, incidents, and real collaboration

Bottom line

Daily standups made sense when information was hard to see.

In the AI era, they are often just a recurring tax on engineering time.

If the meeting cannot prove its value, it should not survive by habit.

Why Daily Standups Are Becoming Useless in the AI Era · Rodrigo Oler

Daily standups used to be a coordination tool. Today, with better async workflows and AI-assisted status sharing, they often waste engineering time at scale.

oler.pages.dev

How to Safely Remove Xcode Without Breaking Command Line Tools (CLT)

Rodrigo Oler — Tue, 17 Jun 2025 19:01:18 +0000

If you once built iOS/macOS apps but no longer need Xcode — or you simply want to free up tens of gigabytes of disk space — this guide shows how to safely remove Xcode without losing Command Line Tools (CLT) that keep your terminal environment working.

Why Would You Remove Xcode?

Xcode occupies 10–30 GB depending on version and simulators.
You no longer develop for iOS/macOS.
You want to free SSD space but keep git, clang, make, brew, etc., functional.

Step 1: Ensure Command Line Tools (CLT) Are Installed

Before deleting Xcode, you must have CLT installed. Check with:

xcode-select -p

If you see:

/Applications/Xcode.app/Contents/Developer

That means the CLT isn't set.

To install CLT directly:

softwareupdate --list

Find the latest Command Line Tools, like:

* Label: Command Line Tools for Xcode-16.4

Then install it:

sudo softwareupdate -i "Command Line Tools for Xcode-16.4"

Once done, verify:

xcode-select -p

Expected:

/Library/Developer/CommandLineTools

Now your CLI tools will work without Xcode.

Step 2: Remove Xcode Safely

To fully remove Xcode:

sudo rm -rf /Applications/Xcode.app

Or simply drag Xcode.app to the Trash via Finder and empty the Trash.

Step 3 (Optional): Free Additional Space

Xcode leaves extra files. You can remove them:

sudo rm -rf ~/Library/Developer/Xcode
sudo rm -rf ~/Library/Caches/com.apple.dt.Xcode
sudo rm -rf ~/Library/Application\ Support/Xcode
sudo rm -rf ~/Library/Preferences/com.apple.dt.Xcode.plist
sudo rm -rf ~/Library/Developer/CoreSimulator

Warning: The last line removes all iOS simulators, if any remain.

Step 4: Reset Command Line Tools (if needed)

If xcode-select complains:

sudo xcode-select --switch /Library/Developer/CommandLineTools

Step 5: Confirm Everything Works

Test key tools:

git --version
clang --version
make --version

All should work fine without Xcode.

Summary

Task	Command
Check CLT	`xcode-select -p`
Install CLT via terminal	`sudo softwareupdate -i "Command Line Tools for Xcode-XX.X"`
Remove Xcode	`sudo rm -rf /Applications/Xcode.app`
Remove extra files	`rm -rf ~/Library/...` (as listed above)
Set CLT path manually	`sudo xcode-select --switch /Library/Developer/CommandLineTools`
Verify tools	`git --version`, `clang --version`, `make --version`

Why This Is Useful

Saves ~20 GB of space.
Keeps Terminal fully working.
Great for backend, Python, Rust, Go, or web developers who don’t build for Apple platforms anymore.

Bonus: Automation Script

Here’s a simple shell script to automate this process:

#!/bin/bash

echo "Checking for Command Line Tools..."
if ! xcode-select -p | grep -q CommandLineTools; then
  echo "Installing Command Line Tools..."
  latest_clt=$(softwareupdate --list | grep -B 1 "Command Line Tools" | head -n 1 | awk -F'* Label: ' '{print $2}')
  sudo softwareupdate -i "$latest_clt"
else
  echo "Command Line Tools already installed."
fi

echo "Removing Xcode..."
sudo rm -rf /Applications/Xcode.app

echo "Cleaning extra files..."
rm -rf ~/Library/Developer/Xcode
rm -rf ~/Library/Caches/com.apple.dt.Xcode
rm -rf ~/Library/Application\ Support/Xcode
rm -rf ~/Library/Preferences/com.apple.dt.Xcode.plist
rm -rf ~/Library/Developer/CoreSimulator

echo "Setting Command Line Tools path..."
sudo xcode-select --switch /Library/Developer/CommandLineTools

echo "Done. Your Terminal environment is safe and clean!"

How to free up space on your Mac's ssd (256GB)

Rodrigo Oler — Sat, 08 Mar 2025 22:17:56 +0000

If you have a Mac with a 256GB SSD, you might notice that your storage fills up quickly. I managed to free up 100GB, going from only 20GB free to 120GB! Here’s a simple guide to help you do the same, using a built-in Terminal command and the CleanMyMac app.

1. Find Big Files with `du`

The du (disk usage) command helps you see which folders and files are taking up the most space. Open Terminal and type:

cd ~  # Go to your user folder

du -sh -- * .[^.]* | sort -hr

What does this command do?

du -sh -- * .[^.]*: Shows the size of each file and folder, including hidden files.
sort -hr: Sorts the results from largest to smallest, so you can easily find the biggest files.

Where to Look for Large Files

Once you run the command, check these common storage hogs:

~/Downloads: Old downloads you no longer need.
~/Library/Caches: App caches that build up over time.
~/Movies and ~/Music: Large media files.
~/Desktop: Temporary files left on your desktop.

To delete files you no longer need, use:

rm -rf path/to/file-or-folder

Be careful! Make sure you don’t delete important files.

2. Use CleanMyMac for Easy Cleanup

CleanMyMac is a simple app that helps clean up your Mac automatically.

How to Use CleanMyMac:

Download and install CleanMyMac from the official website.
Open the app and click Smart Scan.
Review the files it suggests for deletion.
Confirm the cleanup to free up space.

CleanMyMac removes junk files, app leftovers, and system caches safely.

3. More Tips to Free Up Space

🗑️ Empty the Trash

Sometimes, files stay in the Trash and still take up space. Open Finder > Trash and click Empty.

🗃️ Manage iCloud Storage

If you use iCloud Drive, old files might be taking up local space. Go to System Preferences > Apple ID > iCloud and adjust storage settings.

🚀 Delete Unused Apps

Check your installed apps in Finder > Applications and delete ones you don’t need.

Conclusion

By following these simple steps, you can easily free up gigabytes of space on your Mac. The du command helps you find large files, while CleanMyMac makes cleaning easy.

Try it out and let me know if it worked for you! 🚀

Fixing docker's malware warning on macOS Sequoia

Rodrigo Oler — Thu, 09 Jan 2025 16:38:34 +0000

Recently, while trying to open Docker locally on my Mac OS Sequoia (version 15.2), I encountered an error message indicating a "malware warning." This happened on January 9, 2025, and after a brief search on GitHub, I found a simple and effective solution to fix the issue.

Diagnosis

The error was reported in issue #7520 of the official Docker for Mac repository. In the thread of this issue, a user named cdcaires shared a set of commands that resolved the problem.

Solution

The commands to resolve the issue are:

brew uninstall --cask docker --force
brew uninstall --formula docker --force
brew install --cask docker

What do these commands do?

brew uninstall --cask docker --force: Removes the cask version of Docker, even if it’s corrupted.
brew uninstall --formula docker --force: Removes the CLI version of Docker.
brew install --cask docker: Reinstalls the Docker Desktop application.

How to Apply the Solution?

Open the Terminal on your Mac.
Copy and paste the commands above, one by one.
Ensure Docker is reinstalled without errors.
Open Docker again. The malware warning should disappear.

Conclusion

If you’ve encountered this issue in your development environment on Mac OS Sequoia, this solution should work. I hope this tip saves you time and avoids frustration!

If you want to check the original discussion, here is the link to issue #7520 on GitHub and the comment with the solution.

Introduction to @let in Angular 18

Rodrigo Oler — Tue, 21 May 2024 19:17:19 +0000

Angular 18 has an exciting new feature under development for developers: the @let directive. This tool will help you create variables quickly and easily within HTML code. It's important to note that this feature is still being developed and has not yet been merged into a release within Angular 18. Let's understand how it works and look at some cool examples of its potential use.

Update: According to a comment by Denes Papp on dev.to, the merge has now happened in version 18.1.0, and the @let directive is now official. For more details and useful links, you can check out his comment here. Thanks to Denes for the update!

What is `@let`?

The @let directive allows you to create variables directly in the HTML code. This means you can do simple operations like joining text or calculations without needing to write more complex code elsewhere in your program.

How to Use `@let`

Here’s a simple example:

<div>
  @let greeting = 'Hello, ' + name + '!';
  <h1>{{ greeting }}</h1>
</div>

In this example, we are creating a variable greeting that concatenates the string "Hello, " with the variable name, and then we display it on the screen.

Usage Examples

1. Calculating Total Prices

Imagine you have a list of products and you want to show the total price of each one. You can do it like this:

@for (product of products; track product.id) {
  @let totalPrice = product.price * product.quantity;
  <div>
    <p>{{ product.name }} - Total: {{ totalPrice | currency }}</p>
  </div>
}

Here, totalPrice is calculated by multiplying the product’s price (product.price) by the quantity (product.quantity).

2. Formatting Dates

You can format dates easily. Suppose you have a list of events:

@for (event of events; track event.id) {
  @let formattedDate = (new Date(event.date)).toLocaleDateString();
  <div>
    <p>{{ event.name }} - Date: {{ formattedDate }}</p>
  </div>
}

Here, formattedDate converts the event date (event.date) to a more readable format.

3. Showing Messages Based on Conditions

You can create messages based on conditions, like checking if a user is active:

@for (user of users; track user.id) {
  @let statusMessage = user.isActive ? 'Active' : 'Inactive';
  <div>
    <p>{{ user.name }} - Status: {{ statusMessage }}</p>
  </div>
}

In this example, statusMessage is set to "Active" if the user is active (user.isActive), or "Inactive" if not.

More Complex Examples

4. Calculating Average Grades

Let’s calculate the average grades of students:

@for (student of students; track student.id) {
  @let total = student.grades.reduce((sum, grade) => sum + grade, 0);
  @let average = total / student.grades.length;
  <div>
    <p>{{ student.name }} - Average: {{ average.toFixed(2) }}</p>
  </div>
}

Here, we calculate the sum of the grades (total) and then the average (average), displaying it with two decimal places (toFixed(2)).

5. Filtering Items in a List

Suppose you want to show only the available products:

@for (product of products; track product.id) {
  @let isAvailable = product.stock > 0;
  @if (isAvailable) {
    <div>
      <p>{{ product.name }} - In stock: {{ product.stock }}</p>
    </div>
  }
}

In this case, isAvailable checks if the product has stock (product.stock > 0).

Benefits of `@let` with `| async`

One of the challenges in Angular before the introduction of @let was handling asynchronous data, especially when dealing with observables. Typically, you would use the | async pipe, but this often required additional directives like *ngIf to avoid undefined values, or you had to create extra components or subscribe manually in the TypeScript code.

With @let, handling async data becomes more straightforward and elegant:

<div>
  @let data = (data$ | async);
  @let processedData = data ? data.map(item => item.value) : [];
  <ul>
    @for (item of processedData; track item) {
      <li>{{ item }}</li>
    }
  </ul>
</div>

Here, data$ is an observable, and using @let, we can directly process the asynchronous data within the template without needing extra directives or subscriptions. The @let directive handles the async pipe and processes the data in a more readable and concise way.

When Not to Use `@let`

Although @let is very useful, there are times when it’s not the best choice:

Complex Logic: If the logic you need is very complicated, it’s better to do it in TypeScript, outside the template.
Reusability: If you need to use the same logic in multiple places, it’s more efficient to create a function or method in the component.
Performance: In some situations, especially with many items, @let can impact performance. It’s important to test and make sure everything is running fast.

Conclusion

@let in Angular 18 is a powerful and easy-to-use tool that helps simplify code. With it, you can create local variables directly in HTML, making your code cleaner and easier to understand. Use @let for simple operations and keep complex logic in TypeScript. This way, you get the best of both worlds!

Resolving viewport duplication in Next.js 13.4

Rodrigo Oler — Sat, 22 Jul 2023 00:56:06 +0000

Introduction
The Problem
The Solution
Conclusion

Introduction

When working with Next.js, it's common to encounter some technical issues along the way. One such problem that may arise is the duplication of the viewport tag. This article aims to address this issue specifically, providing a solution to resolve the viewport duplication problem in components in Next.js 13.

The Problem

Before we present the solution, it's crucial to first understand the problem at hand. When using the viewport tag directly in the code, as shown below:

import './globals.css'
import { Inter } from 'next/font/google'

const inter = Inter({ subsets: ['latin'] })

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <head>
        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
      </head>
      <body className={inter.className}>{children}</body>
    </html>
  )
}

The Solution

To solve this problem, we need to change the way we are defining the viewport. Instead of placing it directly in the code, we should specify it in the metadata.

The solution was discovered and documented in a StackOverflow thread.

import './globals.css'
import type { Metadata } from 'next'
import { Inter } from 'next/font/google'

const inter = Inter({ subsets: ['latin'] })

export const metadata: Metadata = {
  title: 'Create Next App',
  description: 'Generated by create next app',
  viewport: 'width=device-width, initial-scale=1, maximum-scale=1', // <-- now here
}

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body className={inter.className}>{children}</body>
    </html>
  )
}

Conclusion

In the world of software development, we often come across technical challenges. These challenges may seem daunting at first glance, but with the power of the development community and the constant exchange of knowledge, the solution is often just a post away.

Resolvendo a duplicidade do viewport no Next.js 13.4

Rodrigo Oler — Sat, 22 Jul 2023 00:22:46 +0000

Introdução
O Problema
A Solução
Conclusão

Introdução

Quando trabalhamos com o Next.js, é comum encontrar alguns problemas técnicos ao longo do caminho. Um desses problemas que pode surgir é a duplicidade da tag viewport. Este artigo tem como objetivo abordar especificamente essa questão, fornecendo uma solução para resolver o problema da duplicidade do viewport em components no Next.js 13.

O Problema

Antes de apresentarmos a solução, é crucial entender primeiro o problema em mãos. Ao utilizar a tag do viewport diretamente no código, como mostrado abaixo:

import './globals.css'
import { Inter } from 'next/font/google'

const inter = Inter({ subsets: ['latin'] })

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <head>
        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
      </head>
      <body className={inter.className}>{children}</body>
    </html>
  )
}

A Solução

Para resolver este problema, precisamos mudar a forma como estamos definindo a viewport. Em vez de colocá-la diretamente no código, devemos especificá-la no metadata.

A solução foi descoberta e documentada em um tópico no StackOverflow.

import './globals.css'
import type { Metadata } from 'next'
import { Inter } from 'next/font/google'

const inter = Inter({ subsets: ['latin'] })

export const metadata: Metadata = {
  title: 'Create Next App',
  description: 'Generated by create next app',
  viewport: 'width=device-width, initial-scale=1, maximum-scale=1', // <-- now here
}

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body className={inter.className}>{children}</body>
    </html>
  )
}

Conclusão

No mundo do desenvolvimento de software, muitas vezes nos deparamos com desafios técnicos. Esses desafios podem parecer intimidantes à primeira vista, mas com o poder da comunidade de desenvolvimento e a troca constante de conhecimentos, a solução está frequentemente a apenas um post de distância.

Forem: Rodrigo Oler

How to Detect and Remove the Axios Malware from Your Project

Start with verification

Treat the install window as suspicious

Contain first

What to check on endpoints

What to keep in place after cleanup

Useful tools

How to Protect JavaScript Projects Against Supply Chain Attacks

The baseline

Why this matters

What to put in CI

Why the Axios case is useful

A practical checklist

Axios Supply Chain Attack: How the 2026 npm Compromise Happened

What happened

Why this matters

What defenders should focus on

A simple mental model

What to check first

The real takeaway

Pyth Oracle: A Simple Way to Integrate Price Feeds with Bun and Elysia

Why Pyth feels easy to integrate

Why Bun works well here

Why Elysia makes the REST layer nicer

A minimal Bun + Elysia example

When this pattern is useful

What to keep in mind

Bottom line

Why Hono + Bun Is a Strong Default for New JavaScript Backends

What Hono and Bun actually are

Where the performance comes from

Hono is fast because it stays close to the platform

Bun is fast because the toolchain is integrated

The real win is system-level speed

Who maintains them

Why this is a good choice for new projects

1. You get a smaller decision surface

2. You stay closer to web standards

3. Bun reduces the cost of the boring parts

4. The ecosystem fit is good for modern backends

A minimal example

When I would not pick it

Bottom line

Why Daily Standups Are Becoming Useless in the AI Era

Why it used to make sense

The real cost

Cost per engineer

Visualizing the waste

6-person startup

300-person company

What AI changed

What should replace it

The rule I would use

Bottom line

Why Daily Standups Are Becoming Useless in the AI Era · Rodrigo Oler

How to Safely Remove Xcode Without Breaking Command Line Tools (CLT)

Why Would You Remove Xcode?

Step 1: Ensure Command Line Tools (CLT) Are Installed

Step 2: Remove Xcode Safely

Step 3 (Optional): Free Additional Space

Step 4: Reset Command Line Tools (if needed)

Step 5: Confirm Everything Works

Summary

Why This Is Useful

Bonus: Automation Script

How to free up space on your Mac's ssd (256GB)

1. Find Big Files with du

What does this command do?

Where to Look for Large Files

2. Use CleanMyMac for Easy Cleanup

How to Use CleanMyMac:

3. More Tips to Free Up Space

🗑️ Empty the Trash

🗃️ Manage iCloud Storage

🚀 Delete Unused Apps

Conclusion

Fixing docker's malware warning on macOS Sequoia

Diagnosis

Solution

1. Find Big Files with `du`

What is `@let`?

How to Use `@let`

Benefits of `@let` with `| async`

When Not to Use `@let`