Forem: SOVANNARO

10 Developer Canon Events, Ranked From S Tier to C Tier

SOVANNARO — Wed, 18 Mar 2026 16:01:08 +0000

If you clicked on this, you’re probably a developer. Or you’re in the process of becoming one.

Either way, welcome. You’re about to go through the same painful, slightly embarrassing, weirdly universal experiences every developer goes through.

At some point, I realized we all collect the same stories. Different languages, different stacks, different jobs, same pain. It’s almost funny how predictable it is.

So here’s a ranking of 10 developer canon events, from S tier all the way down to C tier, based on how common they are and how deeply they scar your brain.

1. “I’ll add tests later.”

The deadline is tomorrow.
The feature works.
And “later” feels like a reasonable plan.

It never is.

Every developer has said this at least once, and most of us have said it more than once. Untested code has a way of surviving just long enough to become someone else’s problem, and then eventually your problem again.

Somewhere in almost every codebase, there’s a little graveyard of comments like:

TODO: add tests

Nobody is coming back for them.

I’m putting this in B tier. Very common. Very real. But somehow still not as destructive as some of the others.

2. “It’s just a small fix” on Friday afternoon

It’s 4:30 p.m. on a Friday.

You have one tiny fix. Two lines. Maybe three. You tell yourself it’ll be quick. You push it, close your laptop, and mentally leave work.

Then later that night, Slack starts lighting up.

This is one of those lessons developers usually only need once. After that, the rule gets burned into your nervous system:

Do not push on Friday unless you absolutely have to.

There’s a reason this is basically engineering folklore.

S tier. No debate.

3. Debugging for hours, only to find a typo

You rewrote the function twice.
You pasted the error into ChatGPT. Then Claude. Then Cursor. Maybe even Gemini too.
Still nothing.

Three hours later, you finally spot it.

A variable was named receive in one place and recieve in another.

That’s it. That was the entire problem.

Debugging is already hard enough, but what makes it worse is how often the final answer is completely stupid. Not “complex.” Not “architectural.” Just stupid.

And honestly, that’s part of being a developer.

A tier.

4. “We should just rewrite it from scratch.”

The old codebase is messy. It’s ugly. It makes weird decisions. Half the naming feels cursed.

So naturally, you think:
“We should rebuild this properly.”

This idea is incredibly seductive, especially when you’re newer and still believe clean starts solve messy systems.

Usually, they don’t.

A few months into the rewrite, you realize the old code wasn’t random. A lot of those weird decisions existed for a reason. Not always a good reason, but still a reason.

This is one of those mistakes that makes you respect legacy systems a little more, even when you still hate them.

I’m putting this in B tier. Painful, common, and humbling.

5. “Works on my machine.”

You build the feature.
You test it.
It works perfectly.

Then your teammate pulls the branch and nothing works.

Different Node version. Missing environment variables. Hidden dependency. Local config that never made it into the repo. Some mystery setup step nobody documented because you assumed everybody “just knew.”

These five words may be the most famous excuse in software:

It works on my machine.

And to be fair, sometimes it really does.

That doesn’t help anyone else.

S tier. This is one of the most universal developer experiences on earth.

6. Accidentally committing your API key

This one hits fast.

You push your project to GitHub, feel good for about ten seconds, then notice your API key is sitting there in public like it pays rent.

Immediate panic.

Now you’re rotating credentials, deleting commits, checking logs, and promising yourself that from this day forward you will absolutely use environment variables like a responsible adult.

This is the kind of mistake you make once, and if you’re smart, never the same way again.

B tier.

7. Forgetting one `await`

Nothing crashes.
Nothing throws an error.
The function just quietly returns undefined.

You stare at the code forever because everything looks correct. And that’s the worst part. It looks correct.

Then you add one word:

await

Suddenly everything works.

Losing an entire afternoon to one missing word is such a specific kind of developer pain that I almost have to respect it.

A tier.

8. Looking at your old code and feeling embarrassed

You open a file you wrote last week.

And somehow it already feels like it was written by a stranger.

Why is the variable called data2?
Why is there a function named finalFix?
Why did you think this made sense?

It’s uncomfortable, but it’s also a good sign. If your old code makes you cringe, it usually means your standards improved.

That’s growth. Annoying growth, but growth.

B tier.

9. Getting woken up because production is down

This one feels different from the others.

Your phone goes off in the middle of the night. Production is broken. You’re half asleep, opening logs with one eye and trying to remember how your own system works while your brain is still basically dreaming.

Every developer who’s been through this remembers their first time.

It’s the moment you realize code is not done just because you stopped looking at it. Systems stay alive after you close your laptop, and when they break, they drag you back in.

It’s not fun. But it definitely feels like a real milestone.

A tier.

10. Thinking something will take two days

You look at a ticket.
It seems manageable.
You think, “Yeah, probably two days.”

It is never two days.

There’s always something. Edge cases. Setup problems. Random blockers. A weird issue in a library nobody has touched in three years. A missing requirement. A bug that only appears in staging for reasons known only to the gods.

We all know estimates are bad. We still give them anyway.

That’s what makes this one so funny.

C tier only because it’s less dramatic than the others, even though it happens forever.

Final thoughts

If you’ve done all of these, you’re either experienced, unlucky, or working in software long enough that those two things have become the same thing.

The funny part is that none of these moments really mean you’re bad at your job. They mostly mean you’re doing the job for real.

That’s something I wish more developers understood early on.

A lot of the pain in software isn’t a sign that you don’t belong here. It’s the opposite. It means you’re in it. You’re shipping, breaking things, fixing things, learning the hard way, and slowly building better instincts.

That’s the actual path.

Messy commits, bad estimates, forgotten awaits, Friday deploy trauma and all.

And if you’re building your own project, portfolio, or little side app while collecting these canon events, here’s one thing that may actually help:

👉 Check this link here

I’d only add links like this sparingly, but if it helps support your work, fair enough.

Supercharge Your Development Workflow with MyToolHub: The Ultimate Tool Collection for Developers

SOVANNARO — Tue, 02 Dec 2025 08:45:08 +0000

Introduction

As a developer, having the right tools at your fingertips can make all the difference. From code formatting to debugging, to converting and organizing data, the tools you use are integral to streamlining your workflow and boosting productivity. That’s where MyToolHub comes in.

MyToolHub is a one-stop hub for a wide range of online tools designed to make developers' lives easier. Whether you're working on a personal project, collaborating on a team, or just looking for quick fixes for common coding issues, MyToolHub has the perfect utility for the job.

Why Developers Should Use MyToolHub

For developers, time is money. The fewer distractions you face while working on your code, the more productive you'll be. That’s why having a toolset that can quickly solve your problems is so valuable. MyToolHub offers an extensive collection of tools that help you save time, fix issues, and optimize your code—all without needing to install anything.

Here are just a few of the tools developers can use:

1. Code Formatters & Beautifiers

Clean code is not only easier to read but also easier to maintain. With MyToolHub, you get a variety of formatters for languages like:

JSON Formatter
JavaScript Formatter
HTML/CSS Formatter
SQL Formatter
XML Formatter

Just paste your messy code into the tool, and it will instantly reformat it into a clean, readable version.

2. Minifiers for Optimized Code

If you're focused on performance and efficiency, minifying your code can help reduce file sizes. MyToolHub has minifiers for:

JSON Minifier
XML Minifier
SQL Minifier

These tools help you shrink your code to reduce load times and improve performance—vital for production-ready applications.

3. Data Manipulation Tools

Working with data is a big part of development, and MyToolHub has tools that make it easier to manipulate and convert data formats:

JSON Query
CSV to JSON Converter
Base64 Encoder/Decoder
Image to Base64

For tasks that involve transforming or viewing data, these utilities make it simple to get the job done quickly.

4. Developer-Specific Utilities

Sometimes, you just need a quick utility to solve a specific problem. MyToolHub provides a variety of niche tools that are perfect for developers:

Cron Parser: Break down cron expressions and understand the timing easily.
GraphQL Formatter: Quickly format your GraphQL queries.
JWT Decoder: Decode and verify JSON Web Tokens.

These utilities are designed to save developers time by offering instant solutions for common development tasks.

How MyToolHub Fits into Your Workflow

The best tools are the ones that integrate seamlessly into your workflow. MyToolHub is designed to be fast, responsive, and accessible. You don't need to download anything or sign up for an account—simply visit the site and start using the tools.

Moreover, MyToolHub is constantly updated to ensure that the tools stay relevant to developers' needs. Whether it's adding support for new programming languages or improving existing tools, MyToolHub ensures you're always working with the best resources available.

The MyToolHub Edge for Developers

Speed: All tools are online and ready to use with zero installation.
Simplicity: You don’t need to spend time figuring out complex settings—just get in, get your job done, and get out.
Free: The majority of MyToolHub’s tools are completely free to use, with no hidden costs or subscriptions.
Reliability: We carefully test and select the best tools, ensuring that they work efficiently every time.

How to Get Started

It’s simple! Just head over to MyToolHub and explore the full suite of tools designed specifically for developers. Whether you need to format code, convert data, or minify resources, you’ll find the right tool in just a few clicks.

Start supercharging your development workflow today. MyToolHub is here to make your coding life easier.

Conclusion

As developers, we’re always on the lookout for tools that make our work faster, cleaner, and more efficient. MyToolHub offers a comprehensive set of free online tools that save you time and help you tackle everyday development tasks with ease. Whether you're dealing with formatting, data manipulation, or debugging, MyToolHub has got you covered. Visit today and unlock the full potential of your development workflow!

Share and Connect

If you’ve found these tools useful, share them with your developer network! We’re always looking to connect with like-minded professionals and improve our platform based on your feedback.

😂 Funny Memes of Docker: Learn with Laughter!

SOVANNARO — Sat, 26 Jul 2025 12:16:12 +0000

We’ve covered a lot about Docker and how to containerize web apps. But before we wrap things up, let’s take a breather.

Learning is always better with a bit of humor—so here are some funny Docker memes that also teach valuable lessons!

🧍‍♂️ Be Like Docker – The COVID Edition

Isolation is Docker’s core idea—apps stay in their own containers, unaffected by others.

Just like during COVID:
“Be like a Docker container. Stay safe. Stay isolated.” 🦠🐳

💻 "It Works on My Machine" – Classic Dev Pain

Before Docker, devs would say:

“It works on my machine…”

But in QA or production? 💥
With Docker, your app works the same everywhere.

🦇 Batman Says: "Just Docker It!"

Dev: “It only works on my system.”
🦇 Batman: Slaps “Use Docker!”

Docker images package all your app needs—making it portable and predictable.

🤝 Dev vs Tester

Dev: “It works on my laptop.”
Tester: “And I don’t care. Fix it in QA.”

🥲 Docker removes this argument entirely.

📦 Containers Are Everywhere!

Modern apps run in:

Microservices
Serverless systems
Streaming platforms

And Docker is behind the scenes powering it all.

📋 Too Many Setup Steps?

“Install JDK, app server, dependencies…”

😩 Too much hassle.
💡 Docker solves it all with a single image.

🔥 Works in Dev, Fails in Prod?

Dev: “It works in dev.”
Ops: “It’s crashing in prod!”

Docker ensures consistency across all environments.

🧠 Team Lead Logic

Dev: “It works on my machine.”
Lead: “We’re not shipping your machine to the client.”

😂 Use Docker. Always.

☁️ Cloud vs Local Machines

Running Docker in the cloud?
✨ Clean. Scalable. Beautiful.

Running 10 containers on your 8GB RAM laptop?
💻 Might feel like a dumpster fire 🔥😅

🥵 Explaining Docker = Hard Work

Explaining Docker isn’t easy.
But memes make it better!

Hope all my effort helped you understand Docker more clearly.

🏗️ Going to Microservices?

Boss:

“We’re moving to microservices.”

Everyone:

“Time to Dockerize everything!”

It’s a fun, modern way to build scalable systems.

👶 Kid Dev Logic

Kid: “It works on my machine!”
Manager: “Let’s ship your laptop to the client.”

No, seriously—just use Docker.

🖥️ Docker vs Virtual Machines

VMs = Heavy.
Docker = Lightweight, portable, fast, and scalable.

Choose Docker. Every time. 🐳✅

☕ Final Words: Laugh, Learn, Docker!

Memes are fun—but the message is real. Docker fixes many common dev problems and helps you build with confidence.

Take a break—you earned it. See you in the next section! 👋

📦 Supercharge Docker with Extensions: A Look at Log Explorer

SOVANNARO — Sat, 26 Jul 2025 11:58:48 +0000

If you're using Docker regularly, you’ve probably spent a fair bit of time digging through logs the hard way. What if I told you there’s an easier (and much cooler) way?

In this post, I’ll walk you through one of Docker’s most helpful features—Extensions—and how to use the Log Explorer extension to make log management way easier.

🔌 What Are Docker Extensions?

Docker Extensions are like mini-apps that plug right into Docker Desktop. You can find them in the “Add Extensions” tab, and they’re designed to:

Save time
Improve visibility
Solve everyday DevOps headaches

Whether you're dealing with images, containers, volumes, or logs—chances are there's an extension for that.

🔍 Example: Log Explorer by Docker

Let’s look at a real example: the Log Explorer extension. It's perfect when you want to see what your containers are doing without opening each one individually.

🛠️ How to Install Log Explorer

Here’s how to get it up and running:

Open Docker Desktop
Go to the “Add Extensions” tab
Search for “log”
Find “Logs Explorer” by Docker
Click Install

Once installed, you’ll find it under your Extensions section.

📋 What Can Log Explorer Do?

This tool gives you a central view of logs across all your containers. Key features include:

✅ View logs from all containers (running or stopped)
✅ Filter logs by container name
✅ Search logs in real-time
✅ Toggle between stdout and stderr
✅ Colored log streams for better readability (e.g., blue for accounts, red for loans)

💡 Real-World Use Case

Let’s say you're running multiple microservices using Docker Compose. Here’s how Log Explorer fits in:

docker compose up -d

Then:

Open Logs Explorer in Docker Desktop
Instantly view logs from all containers
Filter by service (e.g., cart, orders)
Search for errors or keywords
Troubleshoot without bouncing between terminals

🧠 Final Advice

If something feels slow or repetitive in Docker, check the Extensions tab.
There's probably a tool that already solves it—like magic.

Log Explorer is just one of many Docker Extensions that can save you time, reduce headaches, and help you focus on what actually matters: building awesome stuff.

💬 Have you used Docker Extensions before? Share your favorites in the comments!

🐳 Docker Compose Basics: `up`, `down`, `stop`, and `start` Explained Simply

SOVANNARO — Sat, 26 Jul 2025 11:47:37 +0000

Working with multiple microservices? Docker Compose is your best friend. It lets you start, stop, and manage multiple containers using just a few commands.

In this post, you'll learn the difference between:

docker compose up
docker compose down
docker compose stop
docker compose start

🔼 `docker compose up`

This command creates and starts your containers based on the docker-compose.yml file.

docker compose up -d

-d = “detached mode” – run containers in the background
It builds containers if they don’t already exist
Useful for starting fresh or restarting your entire system

🔽 `docker compose down`

This command stops and removes all containers, networks, and volumes created by Docker Compose.

docker compose down

Cleans up everything
Helps save space on your machine
Use it when you're done or want to restart everything fresh

🛑 `docker compose stop`

This command only stops your running containers. It does not delete them.

docker compose stop

Use this when:

You want to pause development
You plan to restart the containers later without rebuilding

▶️ `docker compose start`

This command restarts containers that were previously stopped using stop.

docker compose start

⚠️ If the containers were removed using down, this command won't work — they no longer exist.

💡 Real Example Flow

Here’s a typical workflow when using Docker Compose:

# Start all services
docker compose up -d

# Stop them without removing
docker compose stop

# Start them again
docker compose start

# Stop and remove everything
docker compose down

✅ Summary Table

Command	Action	Removes Containers?
`docker compose up`	Builds & runs containers	❌ No
`docker compose stop`	Stops containers only	❌ No
`docker compose start`	Starts containers that were stopped	❌ No
`docker compose down`	Stops and removes everything	✅ Yes

🔍 Final Notes

Most of the time, you'll use up and down.
If you're working on a project temporarily, stop and start are great tools to keep things light.
Always double-check your docker-compose.yml file — correct indentation is very important!

Let me know if you'd like me to add:

A visual diagram to help reinforce this flow
A downloadable cheat sheet
A GitHub sample project

Happy Dockering! 🐳

🚀 Learn to Start and Stop All Microservices with Docker Compose

SOVANNARO — Sat, 26 Jul 2025 11:23:45 +0000

In this lecture, you'll learn how to use Docker Compose to easily start and stop multiple microservices using just a few simple commands.

🧩 Why Use Docker Compose?

Docker Compose helps you run multiple containers (like microservices) at once using a single command, rather than running them one-by-one with separate docker run commands.

🛠 The `docker-compose.yml` File

Docker Compose needs a special file named docker-compose.yml where you define all your services (containers). Without this file, the docker compose up command won't work.

📌 Important: Run docker compose up from the folder where the docker-compose.yml file is located.

▶️ Starting All Microservices

To start all the containers (microservices), run:

docker compose up -d

-d means "detached mode" (runs in the background so your terminal stays free).
Example: If you're in the correct folder and run this command, it will start all services defined in the docker-compose.yml.

Then you can check that everything is running with:

docker ps

It will list all the running containers.

✅ Confirm Services Are Working

You can now test each microservice (like Accounts, Loans, Cards) using tools like Postman to send API requests. If you get a successful response, your services are working fine!

⛔️ Stopping All Microservices

To stop and remove all running containers, use:

docker compose down

This command stops and deletes all the containers created by Docker Compose.

📝 If you just want to stop them but not delete, use:

docker compose stop

However, it’s usually better to use down so everything is cleaned up.

🔁 Recap of Key Commands

Command	What It Does
`docker compose up -d`	Starts all containers in background
`docker ps`	Shows running containers
`docker compose down`	Stops and removes containers
`docker compose stop`	Only stops containers (doesn’t remove)

⚠️ YAML File Tips

Indentation in docker-compose.yml is very important.
Be careful with spaces — YAML files break easily if formatting is wrong.
You can find the sample file in the GitHub repo.

💡 Summary

With Docker Compose, you can:

Start all microservices with one command ✅
Stop and delete them easily ✅
Save time compared to running containers one by one ✅

This makes it super efficient to manage your microservices during development.

3 Microservices, 1 YAML File, 1 Command: The Power of Docker Compose

SOVANNARO — Sat, 26 Jul 2025 11:14:27 +0000

🛠️ Problem: Too Many `docker run` Commands

Right now, you have Docker images for three microservices:

accounts
loans
cards

To run each one, you’d normally do:

docker run -p <port>:<port> <image-name>

But imagine doing that for 100 microservices or even just multiple instances.
💡 Manually running each with docker run becomes slow and painful.

✅ Solution: Use Docker Compose

What is Docker Compose?

Docker Compose is a tool that lets you:

Define all microservices in one YAML file.
Start or stop all services with just one command.

👉 Instead of typing docker run multiple times, you write everything once in a file called docker-compose.yml.

⚙️ What Can Docker Compose Do?

Start all microservices with docker compose up
Stop everything with docker compose down
Set memory limits
Link services together with a shared network
View logs, restart services, and more

Docker Compose is installed automatically with Docker Desktop

📄 Let's Create a `docker-compose.yml`

Put the file anywhere you want (e.g., in your accounts project folder).

Step-by-step Structure:

services:
  accounts:
    image: "your-username/accounts:s4"
    container_name: accounts-ms
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          memory: 700m
    networks:
      - easybank

  loans:
    image: "your-username/loans:s4"
    container_name: loans-ms
    ports:
      - "8090:8090"
    deploy:
      resources:
        limits:
          memory: 700m
    networks:
      - easybank

  cards:
    image: "your-username/cards:s4"
    container_name: cards-ms
    ports:
      - "9000:9000"
    deploy:
      resources:
        limits:
          memory: 700m
    networks:
      - easybank

networks:
  easybank:
    driver: bridge

🔍 Explanation:

Key	Meaning
`services:`	Section where you define each microservice
`image:`	The Docker image to use (add your Docker Hub username)
`container_name:`	Give your container a readable name
`ports:`	Map internal ports to your machine
`deploy > resources > limits:`	Restrict memory usage
`networks:`	Allow microservices to talk to each other
`easybank (at bottom):`	Creates a shared network all services use

🤝 Why Use `networks:`?

Without a shared network, microservices can’t talk to each other.
Adding them to the same network (like easybank) enables communication.

✅ Final Steps

To check if Docker Compose is installed:

docker compose version

If not, visit the Docker Compose install page and follow the steps for your OS.

🎯 What’s Next?

Now that your docker-compose.yml is ready, you can:

Start all services with:

docker compose up

Stop all services with:

docker compose down

🧠 Summary

docker-compose.yml lets you manage all services in one file.
You define images, ports, memory limits, and networks.
Use docker compose up to launch everything with one command.
It saves time and avoids manual repetition.

🐳 Which Docker Image Approach Should You Use?

SOVANNARO — Sat, 26 Jul 2025 09:30:00 +0000

In this course, we looked at three popular ways to create Docker images for microservices:

Dockerfile
Buildpacks
Jib

Now you might wonder:
Which one is the best?
The truth is — there is no one "best" method. Each has its own pros and cons, and your choice depends on your specific needs.

🔧 1. Dockerfile

✅ Pros:

Gives maximum control and flexibility.
You can customize it to fit almost any requirement.

❌ Cons:

You need to write and maintain it yourself.
You must know best practices for performance and security.
Each microservice needs its own Dockerfile.

🚀 2. Buildpacks

✅ Pros:

Easiest to use — no need to write Dockerfiles.
Supports multiple languages (Java, Python, Node.js, etc.).
Great for multi-language microservices projects.
Offers features like caching, modular builds, and security metadata.

❌ Cons:

Slower and uses more memory, especially on local machines.
Has some performance issues on macOS.

☕ 3. Jib (from Google)

✅ Pros:

Designed specifically for Java projects.
Very fast and lightweight — saves memory and disk space.
Works smoothly across Windows, macOS, and Linux.

❌ Cons:

Only supports Java.
Less flexible compared to Dockerfile for complex setups.

🤔 So… What Are We Using in This Course?

We’ll use Jib for three main reasons:

Faster & lighter – Great for local development on regular laptops.
Our microservices are Java-only, so Jib is a perfect fit.
Fewer issues on macOS – Buildpacks can be slow or buggy on Macs.

🏁 Final Advice

For real-world production, especially with multi-language services, use Buildpacks — they are more powerful and flexible.
If you're working with Java-only and want a quick, easy setup, Jib is a great choice.
If you need full control and have special requirements, use a Dockerfile.

👉 There’s no “bad” option — just choose what fits your project and team best.

🐳💡 What Is Jib?

SOVANNARO — Fri, 25 Jul 2025 16:23:53 +0000

Jib is a tool created by Google to help Java developers create Docker images for their applications without writing a Dockerfile and even without installing Docker locally (optional). It works only for Java applications.

Think of Jib as a shortcut that turns your Java app into a Docker image easily.

🛠 Why Use Jib Instead of Other Tools?

Only for Java apps (not Node.js, Python, etc.).
No need to write a Dockerfile.
Faster than Buildpacks (another tool for creating Docker images).
Can work without Docker installed, by pushing images directly to a remote repository (like Docker Hub).

🚀 Steps to Use Jib with Maven

Let’s say you want to containerize a Java microservice named cards using Maven.

1. 📦 Go to Jib GitHub

Link: https://github.com/GoogleContainerTools/jib

There you’ll find guides on how to use Jib with Maven or Gradle.

Since you're using Maven, follow the Maven instructions.

2. 🧩 Add Jib Plugin to `pom.xml`

Open your cards service’s pom.xml file and add the following plugin:

<build>
  <plugins>
    <!-- existing plugins like spring-boot-maven-plugin -->

    <plugin>
      <groupId>com.google.cloud.tools</groupId>
      <artifactId>jib-maven-plugin</artifactId>
      <version>3.3.2</version>
      <configuration>
        <to>
          <image>your-dockerhub-username/cards:S4</image>
        </to>
      </configuration>
    </plugin>
  </plugins>
</build>

Make sure to:

Replace your-dockerhub-username with your actual Docker Hub username.
Ensure packaging is set to jar.

3. 🧹 Clean Project

Before building, clean the previous builds:

mvn clean

4. 🔧 Build Docker Image Using Jib

Now, generate the Docker image:

mvn compile jib:dockerBuild

This will create a Docker image using your local Docker (no need for a Dockerfile).

✅ If successful, it will build the image very quickly (in the demo: ~11 seconds).

5. 🐋 Check Docker Image

Run:

docker images

You’ll see the cards image listed there.

6. ▶️ Run the Docker Container

Now run your container:

docker run -d -p 9000:9000 your-dockerhub-username/cards:S4

-d means run in background.
-p 9000:9000 means map local port 9000 to container port 9000.

7. 📬 Test the API

Use Postman or browser to test if the service is running:

http://localhost:9000/api/create

✅ If you get a response, everything is working fine!

❓Why the "43 Years Ago" Timestamp?

You might see that the Docker image says it was created "43 years ago".

This is NOT a bug!
It’s a feature to optimize caching. If nothing changes, the image content and date stay the same, which makes builds faster and more efficient.

💻 What If You Don’t Have Docker Installed?

You can still build the Docker image and push it to a remote registry (like Docker Hub) directly.

Run this command instead:

mvn compile jib:build

This will push the image to Docker Hub (or GCR/ECR) instead of building it locally. Just make sure your image name is correct and you are logged in.

✅ Summary

Step	What You Do
1️⃣	Add Jib plugin to `pom.xml`
2️⃣	Clean your project
3️⃣	Run `mvn compile jib:dockerBuild`
4️⃣	Check the image with `docker images`
5️⃣	Run it with `docker run`
6️⃣	Test it using Postman
🧠	Remember: No Dockerfile needed!

🆚 Jib vs Buildpacks

Feature	Jib	Buildpacks
Language Support	Only Java	Java, Python, Node, etc.
Dockerfile Required	❌ No	❌ No
Fast Build	✅ Yes	❌ Slower
No Docker Needed	✅ Yes (optional)	❌ No

🚀 What Are Buildpacks?

SOVANNARO — Wed, 23 Jul 2025 17:08:21 +0000

Buildpacks help you automatically create Docker images from your source code — no need to write a Dockerfile.

✅ Think of it like this:

You give your app, and it builds the Docker image for you — optimized, secure, and fast.

🏗️ Who Created Buildpacks?

Originally developed by Heroku
Later improved by Heroku + Pivotal
Now called Cloud Native Buildpacks

🔍 What Does Buildpacks Do?

Scans your source code and dependencies
Automatically builds a Docker image
Follows all best practices:

✅ Security
✅ Caching
✅ Compression
✅ Layer optimization

📦 You don’t have to know or write Dockerfile instructions at all.

🛠️ Languages Supported

You can use Buildpacks with:

Java ✅
Go
Python
Ruby
PHP
Node.js
And more!

🧪 How To Use Buildpacks (For Java Spring Boot)

🟩 Step 1: Add Packaging to `pom.xml`

Make sure this line exists:

<packaging>jar</packaging>

🟩 Step 2: Add Docker Image Name to `pom.xml`

Inside <configuration> of the spring-boot-maven-plugin, add:

<image>
  <name>your-docker-username/${project.artifactId}:tag</name>
</image>

📌 Example:

<name>sovannaro/loans:S4</name>

✅ sovannaro = your Docker Hub username
✅ loans = your microservice name
✅ S4 = a version or tag (optional)

🟩 Step 3: Use the Spring Boot Plugin

Make sure this plugin is inside your pom.xml:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
</plugin>

🟩 Step 4: Run the Buildpacks Command

Go to your terminal, and run:

mvn spring-boot:build-image

☕ This tells Maven to use Buildpacks to build a Docker image from your Spring Boot app.

🕒 The first time, it may take 5–10 minutes (downloads dependencies and base images)

✅ It scans your Java version and app setup
✅ It builds a production-ready image

🟩 Step 5: Run Your Docker Container

Use the image you just created:

docker run -d -p 8090:8090 sovannaro/loans:S4

✅ Your app should now run at http://localhost:8090
✅ You can test it with Postman or a browser

📉 Why Buildpacks Are Better

Feature	Dockerfile	Buildpacks
Manual work	✅ Required	❌ Not needed
Security	❌ You must handle	✅ Handled for you
Image size	📦 Bigger	📦 Smaller (e.g. 456MB → 311MB)
Skill needed	💻 Docker knowledge	😌 Just Java/Maven
Maintenance	😩 Tedious	🎉 Simple

📌 Summary

Buildpacks = No Dockerfile Needed

Build Docker images automatically
Follows best practices (security, performance, compression)
Works with many programming languages
Perfect for developers who don’t want to become Docker experts

🌩️ The 15-Factor Methodology: A Friendly Guide to Cloud-Native Application Development

SOVANNARO — Sun, 20 Jul 2025 04:43:34 +0000

🚀 Introduction

Cloud-native development can feel overwhelming—containers, microservices, orchestration, and all the moving parts. That’s where the 15-Factor Methodology comes in. Think of it as a checklist or compass for building apps that are scalable, resilient, and easy to manage—no matter how complex things get.

Originally an extension of the famous 12-Factor App principles from Heroku, this updated methodology helps modern developers like you craft cloud-ready apps with confidence.

Let’s dive in—factor by factor—and explore how each principle empowers you to create applications that thrive in the cloud.

🔢 1. One Codebase, One Application

Imagine each application as a living, breathing creature. It deserves its own dedicated codebase—not shared, not tangled, just clean and focused.

✅ One app = One codebase
🚫 Don’t mix multiple apps in one repo
🧩 Reuse code? Use libraries or services instead

Why it matters: Cleaner separation means fewer bugs and faster deployments. Your team always knows where to look and what they’re changing.

🌐 2. API First

Build your app like a platform from day one. That means designing the API before the UI or integrations.

🤝 Promotes teamwork—front-end and back-end teams can work in parallel
🔁 Easier to maintain and scale
🧪 Testing is simpler and more robust

Tip: Use tools like Swagger or Postman to define your API early.

📦 3. Dependency Management

Your app relies on libraries, tools, and frameworks—but it should declare those openly.

📄 Use dependency manifests (like pom.xml, package.json)
📦 Let build tools handle installations (Maven, Gradle, npm)

Golden Rule: If someone clones your repo, they should be able to install all dependencies without asking questions.

🏗️ 4. Design, Build, Release, Run

Separate your app’s lifecycle into four clear stages:

Stage	Purpose
Design	Choose tools and features wisely
Build	Compile and bundle your code with dependencies
Release	Add config, make it a unique release
Run	Execute in the cloud, confidently

Why: Separation prevents surprises—no more “it worked on my machine” moments.

🔐 5. Configuration, Credentials & Code

Keep secrets... secret. Never hard-code configs or credentials.

🗂️ Use environment variables or external config files
🔐 Separate from your codebase
🎯 Bundle only defaults—store the rest securely

Pro Tip: Tools like Vault, AWS Parameter Store, or Kubernetes Secrets help manage this well.

📜 6. Logs

Your app shouldn’t manage logs. Just print them—and let tools do the rest.

🖨️ Write logs to stdout
🕵️ Use log aggregators like ELK, Grafana, or Datadog to analyze

Think of logs as breadcrumbs: simple, chronological, and valuable.

♻️ 7. Disposability

In the cloud, things come and go quickly. Your app should too.

⚡ Start fast
🧹 Shut down gracefully (finish tasks before exiting)
🤖 Use tools like Docker and Kubernetes for resilience

This flexibility keeps your system healthy under pressure.

🔌 8. Backing Services

Treat external resources like plug-and-play parts.

💾 Database, cache, queue = attached resources
🔁 Swap easily (e.g., local DB ➡️ cloud DB)
🔌 Connect via URLs, not hardcoded connections

Change environments without touching the code.

🌍 9. Environment Parity

Keep environments as similar as possible—dev, test, staging, production.

🕐 Close the time gap (faster deployment)
👥 Close the people gap (DevOps culture)
🛠️ Close the tools gap (consistent services)

Containers (like Docker) are your best friend here.

⚙️ 10. Administrative Processes

Every app needs maintenance—but run these tasks separately and on demand.

🔄 Migrations, batch jobs, cleanup = admin tasks
🛠️ Version control and package them like the main app
🎯 Run them in the same environment, just not always running

Think of them like one-time-use utilities.

🔉 11. Port Binding

Your app should listen on a port, just like a mini web server.

🧩 Self-contained (Spring Boot, Node.js, etc.)
🚪 Binds to a port (e.g., localhost:8080)
🌐 Works seamlessly with routing layers (like NGINX, Kubernetes)

This makes your app easier to deploy and scale.

🧠 12. Stateless Processes

Apps should be stateless—no saved memory between requests.

🔁 Store state in a separate service (DB, Redis, etc.)
📤 Each instance runs independently
☁️ Makes horizontal scaling (adding more instances) a breeze

Stateless = Simple = Scalable

👥 13. Concurrency

Your app must serve many users at once.

⚖️ Handle requests in parallel (threads, async tasks)
💪 Scale horizontally across machines
🧱 Classify roles: web, worker, scheduler, etc.

Plan your architecture for traffic surges before they happen.

📊 14. Telemetry

You can’t fix what you can’t see. That’s why telemetry is critical.

📝 Logs for visibility
📈 Metrics for performance
🔍 Traces for request flow
❤️ Health checks for uptime
📣 Events for insights

Think of it like the control room in a spaceship—you need constant feedback.

🛡️ 15. Authentication & Authorization

Finally, security first—always.

🪪 Authentication: Who are you?
🛂 Authorization: What are you allowed to do?
🔐 Use standards like OAuth 2.1 and OpenID Connect

A secure app is a trustworthy app. Don’t skimp here.

🎯 Final Thoughts

The 15-Factor Methodology is more than a checklist—it’s a mindset. When you build cloud-native apps using these principles, you’re setting yourself up for:

🚀 Easier deployment
🛠️ Faster debugging
📈 Seamless scaling
🧘‍♀️ Peace of mind

By following these 15 principles, you can build software that’s ready for the modern world—resilient, reliable, and robust.

Now it’s your turn! Which factor do you find most useful? Or which one are you excited to implement in your project?

Let’s keep building—one factor at a time. ❤️

☁️ Building Cloud-Native Applications: A Simple Guide to Doing It Right

SOVANNARO — Wed, 16 Jul 2025 16:50:41 +0000

In today’s fast-moving digital world, cloud-native applications are the secret sauce behind the success of many tech-savvy businesses. But what exactly are cloud-native apps, and how do you build them the right way?

Let’s break it down in a simple, fun, and friendly way so you can enjoy the ride while learning how to build powerful, future-ready cloud-native applications.

💡 What Are Cloud-Native Applications?

🧑‍💻 In Simple Terms

Cloud-native applications are apps specially built for the cloud. That means they’re designed to take full advantage of the cloud's superpowers like scalability, flexibility, and speed. They’re made to grow with your needs—no matter how fast your user base or data expands.

🧭 The Official Definition (From CNCF)

According to the Cloud Native Computing Foundation (CNCF), cloud-native technologies help developers build and run scalable, resilient, and manageable apps in modern environments—like public, private, or hybrid clouds. These technologies include:

🧱 Containers
🔗 Microservices
🔄 Immutable Infrastructure
🔍 Observability
🤖 Automation

These systems are loosely coupled, meaning they’re not overly dependent on each other. This allows teams to make changes quickly and reliably—with less risk and more speed.

🧭 Guiding Principles: How to Build Cloud-Native the Right Way

A smart team at Heroku came up with the 12-Factor App Methodology to guide developers in building cloud-native apps. These principles help you build web applications that are:

✅ Easy to deploy across any cloud platform
📈 Ready to scale up as your user base grows
💼 Portable across different systems
⚡ Agile and quick to update

Later, in his book "Beyond the Twelve-Factor App," Kevin Hoffman added 3 more factors—bringing us to the 15-Factor App approach. These updates include modern insights into how today’s apps are built and deployed.

🌟 Key Characteristics of Cloud-Native Applications

Let’s explore the traits that make cloud-native apps truly shine:

🔧 Microservices

Instead of one big, tangled app, cloud-native apps are made up of small, independent services. These "microservices" can be built, tested, and deployed separately. That means more flexibility and less stress when making changes.

📦 Containers (Hello, Docker!)

Containers help package your app and all its dependencies so it runs the same—anywhere. Whether it's on your laptop or a massive cloud data center, containers (like Docker) make sure everything just works.

📈 Scalability & Elasticity

Cloud-native apps grow with demand. They scale automatically—adding or removing resources as needed—so you don’t waste time (or money) managing servers manually.

🛡️ Resilience & Fault Tolerance

Even if one part fails, the app keeps running smoothly. Cloud-native apps are built with failure in mind, using smart tools like load balancers and auto-healing to recover quickly.

🔌 Cloud-Native Services

Why build everything from scratch? Cloud-native apps tap into ready-made cloud services like:

☁️ Managed databases
✉️ Messaging systems
🔐 Identity & security services These tools save time and boost performance.

🚀 DevOps Friendly

Cloud-native apps embrace DevOps culture—a mindset where developers and operations teams work together. With CI/CD pipelines, you can push updates faster, safer, and more often.

🔍 Cloud-Native vs. Traditional Apps

Here’s how cloud-native apps compare to old-school enterprise applications:

Cloud-Native Apps 🧠	Traditional Apps 🏛️
Predictable behavior	Often unpredictable
OS-independent (runs anywhere)	OS-dependent
Efficient use of resources	Oversized & wasteful
Fast and continuous updates	Slow waterfall development
Self-healing & scalable	Slower recovery from failure

🎯 Conclusion: Why It Matters

Building successful cloud-native applications isn’t just about using fancy tools. It’s about embracing a mindset—one that values flexibility, automation, and smart architecture.

By using microservices, containers, cloud services, and DevOps practices, you can build apps that are:

🔄 Easy to update
📏 Able to scale as you grow
🧱 Strong and resilient
🌍 Portable and efficient

So whether you're a solo developer or part of a large team, cloud-native is the future. Start building the right way today—and unlock the full potential of the cloud!

☁️ Final Thought

Cloud-native isn’t a buzzword. It’s a modern approach that lets you build applications that are fun to develop, easy to maintain, and ready for anything. Embrace it—and let your apps soar!

Forem: SOVANNARO

10 Developer Canon Events, Ranked From S Tier to C Tier

1. “I’ll add tests later.”

2. “It’s just a small fix” on Friday afternoon

3. Debugging for hours, only to find a typo

4. “We should just rewrite it from scratch.”

5. “Works on my machine.”

6. Accidentally committing your API key

7. Forgetting one await

8. Looking at your old code and feeling embarrassed

9. Getting woken up because production is down

10. Thinking something will take two days

Final thoughts

Supercharge Your Development Workflow with MyToolHub: The Ultimate Tool Collection for Developers

1. Code Formatters & Beautifiers

2. Minifiers for Optimized Code

3. Data Manipulation Tools

4. Developer-Specific Utilities

Share and Connect

😂 Funny Memes of Docker: Learn with Laughter!

🧍‍♂️ Be Like Docker – The COVID Edition

💻 "It Works on My Machine" – Classic Dev Pain

🦇 Batman Says: "Just Docker It!"

🤝 Dev vs Tester

📦 Containers Are Everywhere!

📋 Too Many Setup Steps?

🔥 Works in Dev, Fails in Prod?

🧠 Team Lead Logic

☁️ Cloud vs Local Machines

🥵 Explaining Docker = Hard Work

🏗️ Going to Microservices?

👶 Kid Dev Logic

🖥️ Docker vs Virtual Machines

☕ Final Words: Laugh, Learn, Docker!

📦 Supercharge Docker with Extensions: A Look at Log Explorer

🔌 What Are Docker Extensions?

🔍 Example: Log Explorer by Docker

🛠️ How to Install Log Explorer

📋 What Can Log Explorer Do?

💡 Real-World Use Case

🧠 Final Advice

🐳 Docker Compose Basics: `up`, `down`, `stop`, and `start` Explained Simply

🔼 docker compose up

🔽 docker compose down

🛑 docker compose stop

▶️ docker compose start

💡 Real Example Flow

✅ Summary Table

🔍 Final Notes

🚀 Learn to Start and Stop All Microservices with Docker Compose

🧩 Why Use Docker Compose?

🛠 The docker-compose.yml File

▶️ Starting All Microservices

✅ Confirm Services Are Working

⛔️ Stopping All Microservices

🔁 Recap of Key Commands

⚠️ YAML File Tips

💡 Summary

3 Microservices, 1 YAML File, 1 Command: The Power of Docker Compose

🛠️ Problem: Too Many docker run Commands

✅ Solution: Use Docker Compose

What is Docker Compose?

⚙️ What Can Docker Compose Do?

📄 Let's Create a docker-compose.yml

Step-by-step Structure:

🔍 Explanation:

🤝 Why Use networks:?

✅ Final Steps

🎯 What’s Next?

Start all services with:

Stop all services with:

🧠 Summary

🐳 Which Docker Image Approach Should You Use?

🔧 1. Dockerfile

🚀 2. Buildpacks

☕ 3. Jib (from Google)

🤔 So… What Are We Using in This Course?

🏁 Final Advice

🐳💡 What Is Jib?

🛠 Why Use Jib Instead of Other Tools?

7. Forgetting one `await`

🔼 `docker compose up`

🔽 `docker compose down`

🛑 `docker compose stop`

▶️ `docker compose start`

🛠 The `docker-compose.yml` File

🛠️ Problem: Too Many `docker run` Commands

📄 Let's Create a `docker-compose.yml`

🤝 Why Use `networks:`?

2. 🧩 Add Jib Plugin to `pom.xml`

🟩 Step 1: Add Packaging to `pom.xml`

🟩 Step 2: Add Docker Image Name to `pom.xml`