Introduction

Error handling is where a lot of otherwise-good Java code quietly goes wrong. Exceptions get swallowed, null leaks across boundaries, and stack traces arrive with no context about what the program was trying to do.

Good error handling is not about catching everything. It is about being deliberate: fail fast on programmer errors, recover gracefully from expected failures, and never lose the information a future on-call engineer will need.

Introduction

Python’s error handling reads deceptively simply — try, except, done. But the difference between code that fails clearly and code that fails mysteriously comes down to a handful of habits: catching the right exception, preserving the original cause, and knowing when not to raise at all.

This post covers the practices that keep Python failures debuggable in production.

Prefer EAFP over Look-Before-You-Leap

Python idiom favors EAFP — “Easier to Ask Forgiveness than Permission.” Rather than checking whether an operation will succeed, attempt it and handle the failure:

Introduction

A Java Dockerfile can be three lines and technically work — or it can be a 700 MB image that runs as root, rebuilds from scratch on every code change, and gets OOM-killed under load. The difference is a handful of well-understood practices.

This post walks through building Java images that are small, secure, cache-friendly, and container-aware.

Start From a Slim, Current JRE — Not a JDK

You need a JDK to build, but only a JRE to run. Shipping a full JDK bloats the image and widens the attack surface.

Introduction

The typical first-draft Python Dockerfile — FROM python, COPY . ., pip install -r requirements.txt — produces an image that is close to a gigabyte, reinstalls every dependency whenever a single source file changes, and runs as root with a Python process that ignores SIGTERM.

This post covers how to fix all of that: small images, cached dependency installs, a non-root runtime, and clean shutdowns.

Pick the Right Base Image

python:3.12-slim is the pragmatic default: a Debian-based image with Python but without the large build toolchain. Avoid the full python:3.12 (hundreds of MB of tools you don’t run) and be cautious with alpine — its musl libc frequently breaks or slows down packages with C extensions (NumPy, pandas, database drivers), forcing slow source builds.

Introduction

Most Java codebases have plenty of tests and still get burned by production bugs. The problem is rarely quantity — it’s that the tests exercise the wrong things: they assert internal wiring instead of behavior, they mock away every collaborator until nothing real is left, or they cover the happy path ten times and the failure path zero times.

Good tests are fast, deterministic, and tell you something true about behavior. This post covers the practices that make JUnit 5 and Mockito tests actually earn their keep.

Introduction

Python’s testing tools are lightweight enough that it’s easy to write a lot of tests without writing good ones. A suite that mocks every collaborator, duplicates the same assertion ten times with different inputs pasted in by hand, or chases a coverage number will pass in CI and still miss real bugs.

pytest gives you fixtures, parametrize, and monkeypatch — the tools that make it just as easy to write the right tests as the wrong ones. This post covers how to use them well.

Introduction

Java is often discussed as a single programming language.

In reality, Java is part of something much larger: the Java Virtual Machine (JVM) ecosystem.

The JVM has become a powerful runtime for multiple languages, each solving different problems while sharing the same platform.

What Makes the JVM Special

The JVM provides:

• Platform independence
• Automatic memory management
• Just-in-time compilation
• Mature tooling and debuggers

Languages built on the JVM inherit these benefits without needing to reimplement them.

Introduction

For a long time, Java was associated with large, monolithic enterprise applications running on heavyweight application servers.

Then the industry shifted toward:

• Microservices
• Containers
• Cloud-native architectures
• Kubernetes

Many assumed Java would struggle to adapt.

Instead, Java evolved — and in many cases, thrived.

From Monoliths to Microservices

Early Java enterprise applications often relied on:

• Large EAR/WAR deployments
• Heavy application servers
• Centralized databases

Modern Java architectures look very different:

• Small, focused services
• Independent deployments
• Stateless APIs
• Horizontal scalability

Frameworks like Spring Boot dramatically simplified Java service development by removing boilerplate and enabling rapid startup.

Introduction: Isn’t Java… Old?

Every few years, a new programming language becomes the next big thing.

• Python for data science
• JavaScript everywhere
• Go for cloud-native systems
• Rust for memory safety

And inevitably, someone asks:

“Does Java still matter today?”

The short answer is yes.
The long answer is yes — for more reasons than most people realize.

Java is no longer the “boring enterprise language” people love to mock. In fact, Java has quietly evolved while continuing to power some of the world’s largest and most critical systems.