DEV Community: Jose Rodriguez Marrero

From Vibe Coding to Real Engineering: Why the Strategy Pattern Matters

Jose Rodriguez Marrero — Mon, 06 Apr 2026 18:08:49 +0000

There’s a new kind of developer emerging.

You’ve probably felt it yourself.

You open your editor, describe what you want, and code appears. APIs scaffold themselves. Business logic materializes. Entire features come together in minutes. It feels like magic.

This is what people are calling vibe coding.

And to be clear, it’s not a bad thing.

Vibe coding is incredible for:

prototyping ideas quickly
exploring new domains
getting unstuck

But here’s the catch:

Vibe coding optimizes for speed of creation.
Engineering optimizes for survivability over time.

And that’s where design patterns quietly step in.

The Problem You Don’t Notice at First

Let’s say you’re building a payment system.

You prompt your AI:

“Create a payment processor that supports credit card, PayPal, and crypto.”

And you get something like this:

public class PaymentProcessor
{
    public void ProcessPayment(string type, decimal amount)
    {
        if (type == "CreditCard")
        {
            // credit card logic
        }
        else if (type == "PayPal")
        {
            // PayPal logic
        }
        else if (type == "Crypto")
        {
            // crypto logic
        }
    }
}

It works. It’s fast. It’s clean enough.

Until…

You add Apple Pay
Then Google Pay
Then region-specific providers
Then fraud rules
Then retry policies

Suddenly that method becomes a branching maze.

And every change feels risky.

The Smell

This is the moment where good engineers pause and ask:

“What is changing in this system?”

In this case:

payment methods are changing
payment logic varies per method

That’s your signal.

Enter the Strategy Pattern

Instead of stuffing all behavior into one class, you pull the variation out.

You define a contract:

public interface IPaymentStrategy
{
    void Process(decimal amount);
}

Then implement each behavior independently:

public class CreditCardPayment : IPaymentStrategy
{
    public void Process(decimal amount) { /* ... */ }
}

public class PayPalPayment : IPaymentStrategy
{
    public void Process(decimal amount) { /* ... */ }
}

public class CryptoPayment : IPaymentStrategy
{
    public void Process(decimal amount) { /* ... */ }
}

And your processor becomes:

public class PaymentProcessor
{
    private IPaymentStrategy _strategy;

    public void SetStrategy(IPaymentStrategy strategy)
    {
        _strategy = strategy;
    }

    public void ProcessPayment(decimal amount)
    {
        _strategy.Process(amount);
    }
}

What Just Changed?

This is subtle, but powerful.

Before:

The processor decided how payments were handled
Adding new behavior meant modifying existing code

After:

The processor delegates how to a strategy
New behavior is added by introducing new classes

No existing code needs to change.

Why This Matters (Especially in the AI Era)

AI is very good at generating solutions.

But it doesn’t always optimize for:

long-term maintainability
extensibility
fault isolation
architectural clarity

That’s your job.

The Strategy Pattern gives you:

1. Isolation of Change

Each payment method lives in its own class.

A bug in crypto payments doesn’t ripple into credit card logic.

2. Open for Extension, Closed for Modification

You don’t rewrite your system to grow it.

You extend it.

That’s the difference between:

a system that evolves
and one that eventually collapses under its own weight

3. Runtime Flexibility

You can swap behavior dynamically:

processor.SetStrategy(new PayPalPayment());

Or more realistically:

var strategy = resolver.Resolve(paymentType);
processor.SetStrategy(strategy);

Now behavior is driven by configuration, not conditionals.

The Bigger Shift

The Strategy Pattern isn’t really about interfaces.

It’s about this mindset:

“My objects shouldn’t own behavior that changes frequently.”

Instead:

“They should delegate that behavior to something interchangeable.”

That’s how you build systems that last.

Vibe Coding vs Engineering

Vibe coding gets you to:

“It works.”

Design patterns get you to:

“It will keep working when everything changes.”

You don’t need patterns for every piece of code.

But when you see:

growing conditionals
branching logic
behavior that varies by type

That’s your cue.

One Line to Take With You

Strategy lets you change behavior without changing the code that uses it.

If you internalize that, you’ll start seeing it everywhere.

And that’s when you stop just generating code…

…and start designing systems.

Written by Jose
Proofread/Edited by ChatGPT 5.4

My Dev Environment Hated Me (And How I Fixed It)

Jose Rodriguez Marrero — Sun, 22 Mar 2026 23:22:33 +0000

A returning developer's battle with devcontainers, Docker image tags, and OAuth callbacks that ghost you like a bad Tinder date.

I'm back. After a few months away to deal with a family medical situation (more on that at the end), I've returned to the industry with a mission: build portfolio-worthy, production-grade projects and sharpen my .NET skills back to a competitive level.

My first project? A Feature Flag Service — a clean architecture .NET API that evaluates feature flags deterministically using rollout strategies like percentage-based rollouts and role-based targeting. Think LaunchDarkly, but built by me, from scratch, with a focus on solid engineering principles.

Before writing a single line of business logic, I had to do something deceptively simple: set up my dev environment.

Two hours later, I had four separate errors and a story worth writing about.

The Setup

The plan was clean and modern:

Devcontainer for a reproducible, containerized development environment
Claude Code inside the container for AI-assisted development
.NET 10 because why not use the latest?
VSCode Dev Containers extension to tie it all together

Here's what my devcontainer.json looked like going in:

{
  "name": "Feature Flag Service",
  "image": "mcr.microsoft.com/devcontainers/dotnet:1-10.0-bookworm",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {},
    "ghcr.io/devcontainers/features/node:1": { "version": "lts" }
  },
  "forwardPorts": [5000, 5001],
  "postCreateCommand": "dotnet restore && dotnet tool restore"
}

Looks reasonable, right? Narrator: It was not reasonable.

Bug #1 — The Image That Doesn't Exist

Error response from daemon: failed to resolve reference 
"mcr.microsoft.com/devcontainers/dotnet:1-10.0-bookworm": not found

Right out of the gate. Docker couldn't pull the image because the tag 1-10.0-bookworm simply does not exist.

Here's the thing about Docker image tags — they're not automatically generated for every version of every framework. The mcr.microsoft.com/devcontainers/dotnet image only has published tags up to 8.0 and 9.0. No 10.0 yet.

But there's a second twist: .NET 10 dropped Debian (Bookworm) entirely. Starting with .NET 10, Microsoft switched the default base OS to Ubuntu. So even if the tag existed, -bookworm would be wrong.

The fix: Drop down to the latest available devcontainer image:

"image": "mcr.microsoft.com/devcontainers/dotnet:9.0"

Lesson: Always verify Docker image tags exist before assuming they do. The pattern <language>:<version>-<os> isn't guaranteed — check the registry.

Bug #2 — The OAuth Callback That Ghosted Me (Main Event)

This one is the real star of today's post. Container built successfully. Claude Code installed. Time to log in.

claude auth login --claudeai

Browser opens. I authenticate. I'm redirected back to VSCode and... nothing. The terminal just hangs. Waiting. Forever.

Eventually:

Failed to retrieve auth status after login

What's actually happening here is a fascinating networking problem.

The Root Cause

When you run claude auth login, Claude Code spins up a localhost callback server on a random ephemeral port. The OAuth flow works like this:

Claude Code starts listening on localhost:RANDOM_PORT
Your browser opens claude.ai/oauth/authorize
You authenticate in the browser
The browser is redirected back to localhost:RANDOM_PORT/callback
Claude Code receives the token and stores it

The problem? You're inside a container. The browser lives on your host machine. The callback server lives inside the container. That random port is never forwarded, so the callback from the browser never arrives. Claude Code sits there waiting for a knock on a door that nobody can reach.

HOST                          DEVCONTAINER
┌──────────────┐              ┌─────────────────────┐
│   Browser    │──callback──X─▶│  claude auth login  │
│              │  :RANDOM      │  (listening on      │
└──────────────┘  NOT FORWARDED│   RANDOM port)      │
                               └─────────────────────┘

The Fix — Bind Mount Your Host Credentials

The cleanest solution: log in on your host machine once, then mount your credentials into the container.

Claude Code stores OAuth tokens in two places on your filesystem:

~/.claude/ — credentials, config, session data
~/.claude.json — onboarding state (easy to miss this one!)

Update your devcontainer.json mounts:

"mounts": [
  "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind",
  "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind"
]

Then on your host machine (not inside the container):

claude auth login

Complete the OAuth flow normally. Rebuild the container. Done — Claude Code inside the container picks up your credentials automatically, no login required.

Lesson: OAuth callback flows assume the browser and the listening server are on the same machine. In containerized environments, that assumption breaks. Bind mounts are your friend.

Bug #3 — `postCreateCommand` Needs a Map

postCreateCommand failed with exit code 1

Vague. Unhelpful. Classic.

Running the commands manually revealed the culprit:

dotnet restore
# error: Specify a project or solution file.

The container doesn't automatically know which solution to restore. A simple fix:

"postCreateCommand": "dotnet restore FeatureFlagService.sln && dotnet tool restore"

Lesson: Be explicit in automation. Commands that work fine interactively (where you're already in context) can fail in scripts because that context doesn't exist.

Bug #4 — The SDK vs. Target Framework Mismatch

error NETSDK1045: The current .NET SDK does not support targeting .NET 10.0.
Either target .NET 9.0 or lower, or use a version of the .NET SDK that supports .NET 10.0.

Remember how we switched to the .NET 9 devcontainer image? Right. The SDK is .NET 9. The project targets .NET 10. They don't agree.

Rather than installing a custom SDK (more complexity, more maintenance), I downgraded all project files to target net9.0:

find . -name "*.csproj" | xargs sed -i \
  's/<TargetFramework>net10.0<\/TargetFramework>/<TargetFramework>net9.0<\/TargetFramework>/g'

One command. All five .csproj files updated. Verified with:

grep -r "TargetFramework" --include="*.csproj"

Lesson: Your container image's SDK version and your project's target framework must align. When they don't, decide which one you're willing to move — usually it's easier to adjust the project than rebuild the image.

The Final `devcontainer.json`

Here's where we landed after all four fixes:

{
  "name": "Feature Flag Service",
  "image": "mcr.microsoft.com/devcontainers/dotnet:9.0",

  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {},
    "ghcr.io/devcontainers/features/node:1": { "version": "lts" }
  },

  "forwardPorts": [5000, 5001],
  "portsAttributes": {
    "5000": { "label": "HTTP", "onAutoForward": "notify" },
    "5001": { "label": "HTTPS", "onAutoForward": "notify" }
  },

  "mounts": [
    "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind",
    "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind"
  ],

  "containerEnv": {
    "CLAUDE_CONFIG_DIR": "/home/vscode/.claude",
    "ASPNETCORE_ENVIRONMENT": "Development"
  },

  "remoteUser": "vscode",
  "containerUser": "vscode",

  "postCreateCommand": "dotnet restore FeatureFlagService.sln && dotnet tool restore",
  "postStartCommand": "git config --global --add safe.directory ${containerWorkspaceFolder}",

  "customizations": {
    "vscode": {
      "extensions": [
        "ms-dotnettools.csharp",
        "ms-dotnettools.csdevkit",
        "humao.rest-client",
        "eamodio.gitlens",
        "editorconfig.editorconfig",
        "streetsidesoftware.code-spell-checker"
      ],
      "settings": {
        "editor.formatOnSave": true,
        "editor.tabSize": 4,
        "files.eol": "\n",
        "dotnet.defaultSolution": "FeatureFlagService.sln"
      }
    }
  }
}

Wrapping Up

Four bugs. One working dev environment. Two hours I'll never get back — but also two hours that gave me a much better understanding of how Docker networking, OAuth flows, and devcontainer configuration actually work under the hood.

The Feature Flag Service itself is still ahead of me. Clean Architecture layers to wire up, a deterministic hashing strategy to implement, unit tests to write. But the foundation is solid, the tooling is in place, and Claude Code is authenticated and ready to pair program.

Next post: getting into the actual code — implementing the evaluation engine and the strategy pattern at the heart of this thing.

A note on the comeback: I stepped away from software development for a couple of years to deal with a family medical situation. That chapter is now closed, and I'm back — sharper, more intentional, and honestly more motivated than ever. If you're a developer who's taken time away for life reasons, this blog is partly for you. It's possible to come back. Let's build.

Tags: #dotnet #devcontainers #docker #claudecode #webdev #programming #cleanarchitecture #debugging

🧠 Backing Fields in C#: What They Are and Why You Should Care

Jose Rodriguez Marrero — Sat, 31 May 2025 18:11:22 +0000

As a C# developer, you've probably written something like this:

public string Name { get; set; }

Short. Sweet. Gets the job done.

But what if you need to sneak in a little logic? What if you want to say, “Hey! You can't set Age to -200!”?

That’s when it’s time to meet your new(ish) best friend: backing fields.

🔙 Wait… What’s a Backing Field?

A backing field is just a private variable that stores the actual value for a property.

Think of it like this:

// Backing field
private string _email;

// Property using that field
public string Email
{
    get => _email;
    set => _email = value;
}

You're basically wrapping that private _email in a nice public interface (Email) so other parts of your code can use it safely.

✨ Auto-Properties: The Lazy Magic

When you write this:

public string Email { get; set; }

The compiler quietly creates something like:

private string _email; // 👻 invisible to you!

public string Email
{
    get => _email;
    set => _email = value;
}

No muss, no fuss — but also no customization. You can’t sneak in any logic. It’s like ordering black coffee when you really need a vanilla oat milk latte with light foam and a shot of espresso (a.k.a. validation).

💡 So When Do You Need a Backing Field?

Glad you asked. Here are a few classic cases:

1. Validation

charp

private int _age;

public int Age
{
    get => _age;
    set => _age = value < 0 ? 0 : value; // No negative ages allowed!
}

2. Logging or Side Effects

private string _name;

public string Name
{
    get => _name;
    set
    {
        Console.WriteLine($"Changing name from {_name} to {value}");
        _name = value;
    }
}

3. Transforming Input

Here’s a real-world example from a product filter class I'm currently building:

private List<string> _brands = [];

public List<string> Brands
{
    get => _brands;
    set => _brands = [.. value.SelectMany(p => p.Split(',', StringSplitOptions.RemoveEmptyEntries))];
}

Now, instead of forcing users to send ["Nike", "Adidas"], they can just send:

new List<string> { "Nike,Adidas", "Puma" }

And you’ll still end up with:

["Nike", "Adidas", "Puma"]

That's right, homeys!!✨

Quick Comparison

Feature	Auto-Property	Backing Field
Super simple	✅ Yup	❌ More typing
Add logic or validation	❌ Nope	✅ Totally
Trigger side effects	❌ Not a chance	✅ All day
Transform data on set	❌ Can't do it	✅ Yes, chef

🧵 Wrap-up

Backing fields are like the secret sauce behind well-behaved properties. Sure, auto-properties are great for the everyday stuff, but when you need more control, don’t be afraid to write things out manually.

Whether you're validating data, formatting input, or just want to sneak a Console.WriteLine in there — backing fields have your back (literally).

What’s your favorite use case for a backing field? Ever tried doing too much with an auto-property and had it backfire? Drop a comment — I’d love to hear your war stories.

Static + Generics = Trouble? Why Your C# Code Smells and How to Clean It Up

Jose Rodriguez Marrero — Wed, 28 May 2025 02:53:45 +0000

So there I was… writing some C# code for my, minding my own business, when bam — the compiler drops this wisdom on me:

⚠️ CA1000: Do not declare static members on generic types

And I’m like...

“Okay compiler, but can you explain that like I’m five?”

Let’s break it down.

🍱 Static + Generics: What’s Actually Going On?

You might write something like this:

public class SnackBox<T>
{
    public static int SnackCount;
}

Seems harmless. But if you use it like this:

SnackBox<string>.SnackCount = 5;
SnackBox<int>.SnackCount = 10;

Console.WriteLine(SnackBox<string>.SnackCount); // 5
Console.WriteLine(SnackBox<int>.SnackCount);    // 10

You suddenly realize: 😱 Each version of T gets its own static member.
So now you’ve got dozens of mini snack boxes floating around in memory — each hoarding their own SnackCount.

🧽 What This Has To Do With Real Code

Let’s say you’re writing a helper to apply specs to a query:

public static class SpecificationEvaluator<T>
    where T : BaseEntity
{
    public static IQueryable<T> GetQuery(IQueryable<T> query, ISpecification<T> spec)
    {
        if (spec.Criteria != null)
        {
            query = query.Where(spec.Criteria);
        }

        return query;
    }
}

Looks fine, right?

Well, sort of. But this triggers CA1000, and for good reason:

You now have a separate static class per type — e.g., SpecificationEvaluator<Product>, SpecificationEvaluator<Order>, etc.
That increases memory usage
It’s harder to use (you have to specify the type every time)
And worst of all... the compiler is silently judging you 😬

🧹 The Fix: Static Class, Generic Method

We can clean this up by moving the generic parameter from the class to the method:

public static class SpecificationEvaluator
{
    public static IQueryable<T> GetQuery<T>(IQueryable<T> query, ISpecification<T> spec)
        where T : BaseEntity
    {
        if (spec.Criteria != null)
        {
            query = query.Where(spec.Criteria);
        }

        return query;
    }
}

Now you can call it like:

var result = SpecificationEvaluator.GetQuery(products, productSpec);

No generic class instantiations
Cleaner syntax
The compiler stops yelling 🎉

✅ TL;DR — What Did We Learn?

❌ Don’t Do This	✅ Do This Instead
`static class MyHelper<T>`	`static class MyHelper`
Static method inside generic class	Generic static method inside static class
One copy per `T`	One reusable method for all types
CA1000 warning	✨ No warning, no surprises ✨

🎯 Final Thoughts

If you've ever been confused by that CA1000 warning or wondered why your static generic utility felt “off,” you’re not alone.

Just remember:

Static classes are like toolboxes.
You don’t need a separate toolbox for every kind of screw. 🧰

Happy coding! 👨‍💻👩‍💻
Have you encountered CA1000 before? Drop a comment — I'd love to hear your story or tips!

IEnumerable vs IReadOnlyList in .NET: When Should You Use Each?

Jose Rodriguez Marrero — Fri, 23 May 2025 23:10:32 +0000

If you’re working in C# and .NET, you’ll quickly run into different collection interfaces like IEnumerable<T> and IReadOnlyList<T>. At first glance, they seem pretty similar—both let you work with a set of items in a read-only way. So when should you use each? In this post, I’ll break down the differences, show real-world use cases, and give you code samples so you know exactly when to reach for one or the other.

Quick Definitions

IEnumerable<T>

The simplest way to represent a sequence of items that you can iterate over (with foreach). It doesn’t let you access by index or get the count directly.

IReadOnlyList<T>

Represents a read-only list of items. You can access items by index and get the number of items, but you can’t change the collection.

Code Examples

Example 1: Using `IEnumerable<T>`

public IEnumerable<string> GetAllProductNames()
{
    // Could return from a database query, LINQ, etc.
    return products.Select(p => p.Name);
}

// Usage
foreach (var name in GetAllProductNames())
{
    Console.WriteLine(name);
}

When to use:

When you only need to iterate (loop) over the items.
When the results might be streamed, generated, or filtered on-the-fly.
You don’t need to know the exact number of items or their positions.

Example 2: Using `IReadOnlyList<T>`

public IReadOnlyList<Product> GetFeaturedProducts()
{
    // Return a fixed, materialized list
    return featuredProducts.AsReadOnly();
}

// Usage
for (int i = 0; i < GetFeaturedProducts().Count; i++)
{
    var product = GetFeaturedProducts()[i];
    Console.WriteLine($"{i}: {product.Name}");
}

When to use:

When you need to access items by their index (e.g., list[0]).
When you want to expose the count (list.Count).
When you want to guarantee that the collection is fixed and can’t be changed by the consumer.

Feature	IEnumerable	IReadOnlyList
Can loop with foreach	✅	✅
Access by index	❌	✅
Get count	❌	✅
Immutable/read-only	❌ (just iterates)	✅ (read-only contract)
Deferred execution	✅ (often)	❌ (usually materialized)

How to Decide Which to Use

Use IEnumerable<T> when you want to keep things simple, just need to loop, or want to allow streaming of results.
Use IReadOnlyList<T> when you want the safety and convenience of a fixed, read-only list that exposes both count and index-based access.

Real-World Examples

Repository Pattern (Read-only)

Use IEnumerable<T> for large datasets you want to stream or filter on demand.
Use IReadOnlyList<T> for methods that return a set of results you want to lock down (like the top 10 products).

API Response

Use IReadOnlyList<T> to return a clear, fixed collection (helps with serialization and contracts).
Use IEnumerable<T> internally, especially when chaining LINQ queries.

Quick Tip for Juniors

If you want to let others loop through your data, use IEnumerable<T>.
If you want to let others see how many items you have and access by index—but not modify anything—use IReadOnlyList<T>.

Got questions or want more real-world .NET tips? Drop a comment below!

Taming Your First Docker Build in 5 Minutes

Jose Rodriguez Marrero — Fri, 23 May 2025 16:53:29 +0000

Ever wished your app “just worked” on every machine? Docker gives you consistent, isolated environments—no more “it works on my machine” drama. In this hands-on guide, you’ll go from zero to a running container in five minutes flat.

🛠 Prerequisites

Docker Desktop (macOS/Windows) or Docker Engine (Linux) installed
A simple sample app. We’ll use a minimal ASP.NET Core “Hello World” API, but you can swap in Node.js or static files.

# Check you have Docker:
docker --version

📄 Crafting Your Dockerfile

Create a file named Dockerfile in your project root:

# 1. Base runtime image
FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80

# 2. Build stage
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish

# 3. Final image
FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Tip: Replace MyApp.dll with your project’s DLL name.

🏗 Building the Image

Run:

docker build -t infraforge-dev-hello .

-t infraforge-dev-hello tags your image
. tells Docker to use the current folder as the build context
You’ll see logs of each layer being built and cached

▶️ Running & Testing

Start your container and map port 80 → 8080:

docker run --rm -p 8080:80 infraforge-dev-hello

--rm cleans up the container when you stop it
Navigate to http://localhost:8080 or run:

curl http://localhost:8080

✨ Quick Wins & Optimizations

.dockerignore

bin/
obj/
.vs/

Layer caching: put infrequently changing instructions (e.g., RUN dotnet restore) early.
Multi-stage builds: keeps final image slim—our example already uses one.

🐞 Troubleshooting Tips

Verbose output:

docker build --progress=plain .

Inspect broken images:

docker run --rm -it infraforge-dev-hello /bin/bash

Common pitfalls: wrong file paths, missing dependencies, port mismatches.

🐳 Deep Dive: Understanding the Container Lifecycle

Docker containers transition through well-defined states. Knowing these helps you manage, debug, and automate effectively:

Created: Container exists, but not running.

docker ps -a
# STATUS: Created

Running: Main process is executing.

docker ps
# STATUS: Up X seconds

Paused: Process temporarily frozen.

docker pause <container_id>
docker unpause <container_id>

Exited: Process finished or crashed.

docker ps -a
# STATUS: Exited (1) X seconds ago

Removed: Container deleted.

docker rm <container_id>

Common Lifecycle Commands

# List all containers (running + stopped)
docker ps -a

# Start a stopped container
docker start <container_id>

# Stop a running container (graceful shutdown)
docker stop <container_id>

# Force-restart
docker restart <container_id>

# Remove
docker rm <container_id>

Why it matters:

CI/CD automation: detect “Exited” states to trigger alerts or restarts.
Resource cleanup: proactively remove unused containers to free disk space.
Debugging: start a crashed container interactively to inspect logs or shell in.

📚 Next Steps

Scan for vulnerabilities:

docker scan infraforge-dev-hello

Push to a registry:

docker tag SOURCE_IMAGE TARGET_IMAGE:TAG
# example: docker tag infraforge-dev-hello infraforge-dev/infraforge-dev-hello:v1.0
docker push infraforg-dev/infraforge-dev-hello:v1.0

Automate with GitHub Actions: integrate docker build & docker push on every PR.

Additional Resources:

Docker Official Docs – Get Started & Dockerfile Best Practices
The definitive guide from Docker: an end-to-end “Get Started” tutorial plus the full Dockerfile reference and best-practices guide to optimize builds.
https://docs.docker.com/get-started/
https://docs.docker.com/engine/reference/builder/
Docker Curriculum by Prakhar Srivastav
A free, community-driven, step-by-step walkthrough of Docker fundamentals, from images and containers to multi-stage builds and networking.
https://docker-curriculum.com/
Play with Docker
An in-browser Docker playground—spin up real Docker hosts and containers without installing anything. Great for experimenting with Dockerfiles, commands, and networking.
https://labs.play-with-docker.com/

That’s it—five minutes to your first Docker build, plus a clear view of what happens under the hood. Drop a comment if you hit any snags or have tips of your own!

Jose (@infraforge-dev)

From Code to Purpose: Kickoff at InfraForge-dev

Jose Rodriguez Marrero — Fri, 23 May 2025 15:45:08 +0000

👋 Hello Dev.to — I’m Jose!

Ever wonder how many CI/CD pipelines it takes to deploy an e-commerce API? (Spoiler: less than you think, but more than one!)

I’m Jose, a .NET backend & DevOps engineer on a mission to forge purposeful solutions—not just code and configs, but the clear reasons behind each decision. After a year of deep dives into cloud architecture, containerization, and front-end wizardry (Angular 18 + TypeScript, I see you!), I’m finally sharing my experiments in real time.

🔨 What I’m Working On

InfraForge E-Commerce API: An ASP.NET Core backend serving thousands of products in under 100 ms.
Pipeline Playground: GitHub Actions → Docker → AWS Elastic Beanstalk (and yes, I’ll show you how to tame that YAML monster).
Frontend Fun: Angular 18 UI that drinks from my API’s firehose—spoiler: caching matters!

🚀 Why You’ll Stick Around

I’m all about demystifying the “magic” of DevOps and API design. Expect:

Deep-dive posts on performance tweaks, security hardening, and real-world trade-offs.
Code snippets you can copy/paste (and modify).
Honest “what went wrong” behind the scenes.

So hit that 🌟, follow along, and drop a comment to say hi! Next up: “Taming Your First Docker Build in 5 Minutes.”

— Jose (@infraforge-dev)