Forem: Serge Matveenko

PHP Punishes You for Writing Good Code

Serge Matveenko — Thu, 27 Nov 2025 21:04:30 +0000

Most programming languages guide you toward good code.

PHP… doesn’t.

In fact, PHP often feels like it actively punishes you for trying to write clean, safe, maintainable software — while rewarding shortcuts that age horribly in production.

This isn’t about syntax preferences or “PHP vs X” flamewars.
It’s about direction of least resistance.

In good languages, writing good code is the easiest path.
In bad languages, writing bad code is the easiest path.

PHP is a masterclass in the second category.

Direction of Least Resistance

Every language nudges you in a certain direction.

Some push you toward correctness.
Some push you toward chaos.

The language you use shapes your habits — and often your codebase’s long-term fate.

Rust: Least resistance → correctness

Rust actively fights you when your design is unsafe.

If you:

forget ownership rules,
share mutable state incorrectly,
misuse lifetimes,
ignore concurrency safety,

…it refuses to compile.

Rust doesn’t trust you — and that’s a feature.

Yes, it’s harder to write code at first.
But the language is aligned with your intent.

Good design is the shortest path to success.

Python: Least resistance → readability

Python is permissive — but not anarchic.

You can write awful Python, but you must work at it.

Idiomatic Python naturally pushes you toward:

simple structures,
predictable flow,
readable naming,
explicit behavior.

Example:

# Python: obvious, readable, boring (perfect)
users = [u for u in users if u.is_active]

Trying to outsmart Python usually makes your code uglier, not shorter — which nudges you back toward clarity.

PHP: Least resistance → disaster

PHP’s “happy path” is often:

global state
weak typing
silent failures
inconsistent APIs
magical behavior
legacy defaults

You can write good PHP.

But PHP makes you work for it.

PHP Makes Bad Code Easy

Let’s look at what happens when you do the lazy thing in PHP.

1. Everything is globally accessible

$_GET['id']
$_POST['password']
$_SESSION['user']

No structure.
No boundaries.
No encapsulation.

The language encourages direct access to state from anywhere.

Good design requires:

request objects
input validation layers
parameter objects
DTOs

Bad design requires… nothing.

2. Type safety is optional (and mostly ignored)

PHP has types.

The ecosystem largely ignores them.

By default:

function add($a, $b) {
    return $a + $b;
}

What are $a and $b?

Integers?
Floats?
Strings?
Objects with __toString()?
Null?

Good PHP requires:

function add(int $a, int $b): int {
    return $a + $b;
}

But now:

every call site must cooperate,
legacy code breaks,
frameworks fight you,
plugins betray you,
runtime errors appear instead of coercion.

PHP punishes you for being strict.

3. Errors default to… ignoring errors

$result = file_get_contents($url);

What if:

the file doesn’t exist?
the request fails?
permissions are wrong?
timeout occurs?

The function can fail silently.

No exception.
No structured error.
Just false.

Now every clean implementation requires:

if ($result === false) {
    throw new RuntimeException("Failed to fetch file");
}

Meanwhile, the “dirty” version works… until it doesn't.

4. Frameworks simulate what the language doesn’t provide

Why do PHP frameworks feel so heavy?

Because they fake:

type systems
DI containers
routing DSLs
validation layers
request lifecycles
security models

They are duct tape on a language that refuses to grow a spine.

And when you follow best practices?
You fight:

configuration hell
annotation magic
runtime surprises
reflection hacks

The “right” way is the hardest way.

Cargo Cult vs First-Class Safety

Rust and Python make correctness normal.

PHP makes correctness custom.

In PHP:

testing is extra
type safety is optional
architecture is emulated
tooling is external
contracts are implied
discipline is manual

In other words:

PHP works great if you don’t care deeply about software engineering.

And becomes expensive when you do.

So Why Is PHP Popular?

Because:

✅ You can deploy something in 10 minutes
✅ You don’t need a build system
✅ You don’t need to understand types
✅ You don’t need architecture
✅ You don’t need experience
✅ You don’t need discipline

And:

❌ You pay for all of that later.

Popularity correlates strongly with:

low barrier to entry,
cheap prototypes,
instant gratification.

Not with:

long-term maintainability,
safety,
correctness.

The Most Important Question

Maybe this is the real reason some languages are popular
— and others are trusted.

PHP optimizes for:

shipping now
understanding later
fixing in production

Languages like Rust optimize for:

thinking now
shipping safely
trusting code later

Final Take

PHP does not force you to write bad code.

It just gently rewards you for it.

And the better you try to be…
the more friction you feel.

Versioned Deploys for Flutter Web: Fast Loads, Instant Updates

Serge Matveenko — Fri, 07 Nov 2025 11:20:17 +0000

Flutter Web apps are fast—until the browser cache gets in the way. Anyone who’s deployed a new version knows the pain: users stuck on stale bundles, missing features, or broken screens until they hit a hard refresh.

This post walks through a proven versioned deploy pattern for Flutter Web, using Nginx and simple cache rules to make updates instant and repeat loads nearly instantaneous.

This approach is especially critical for embedded Flutter Web apps like Telegram Mini Apps or other environments that heavily cache web views. Platforms such as Telegram can aggressively cache app bundles—sometimes so persistently that developers need to completely reinstall the app to clear stale versions. Using versioned deploys ensures updates reach users immediately, even in these restrictive caching environments.

How It All Works

Before we dive deeper, let’s unpack what’s happening under the hood:

Browsers love caching. When they see a file like main.dart.js, they assume it rarely changes and keep serving it from local storage. That’s great for speed—until you ship an update.
Flutter builds are static bundles. After flutter build web, you get JavaScript (main.dart.js), WebAssembly (canvaskit.wasm), and other assets. These are ideal for long-term caching.
Nginx controls caching via HTTP headers. By attaching Cache-Control and immutable directives, we tell browsers how long to keep files and when to refetch them.
Version folders act as unique cache keys. Instead of trying to invalidate caches, we generate a new folder name per release (like /v1.0.1/). The browser automatically fetches the new files since the URLs have changed.

For example:

On your first visit, you might download /v1.0.0/main.dart.js.
After a new deploy, the page now references /v1.0.1/main.dart.js.
The browser sees it as a totally new file and fetches it fresh.

This technique avoids conflicts between versions and keeps old assets available for rollbacks or debugging.

Why Flutter Web Needs This

When you build Flutter for the web, it produces a set of files like:

main.dart.js
flutter_service_worker.js
assets/
canvaskit/

They’re large but static—perfect for long-term caching. The problem? Browsers keep serving the old ones after each deploy, even when your app should update.

We fix that by separating mutable entry points from immutable versioned assets.

Architecture Overview

Entry Points (never cached)         Versioned Assets (aggressively cached)
├─ index.html                       ├─ /v1.0.0/main.dart.js
├─ config.json                      ├─ /v1.0.0/flutter_service_worker.js
└─ flutter_bootstrap.js             └─ /v1.0.0/canvaskit/canvaskit.wasm

Entry points — lightweight files that load the app. Always fetched fresh.
Versioned assets — compiled Flutter bundles served from a versioned folder like /v1.0.0/. Cached for a year with immutable.

Each new deploy introduces a new folder, effectively cache-busting automatically.

The Bootstrap Logic

The bootstrap script handles version discovery and initializes Flutter with the correct paths:

(function () {
  'use strict';
  fetch('/config.json', { cache: 'no-store' })
    .then(r => r.json())
    .then(cfg => {
      const version = cfg.version || 'local';
      const base = version === 'local' ? '/' : `/${version}/`;
      const userConfig = { assetBase: base, entrypointBaseUrl: base };
      console.log('Loading Flutter app from:', base);
      _flutter.loader.load({ config: userConfig });
    })
    .catch(err => console.error('Bootstrap error', err));
})();

config.json

{
  "version": "v1.0.0",
  "apiUrl": "https://api.example.com"
}

Every deploy updates the version field. The Flutter loader then fetches from the corresponding folder.

Nginx Configuration

Here’s the minimal Nginx setup to make this work:

# Never cache entry points
location = /index.html {
    add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0";
}
location = /config.json {
    add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0";
}
location = /flutter_bootstrap.js {
    add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0";
}

# Aggressively cache versioned assets
location ~ ^/([^/]+)/(.*)$ {
    set $req_version $1;
    set $asset_path $2;

    if ($req_version != $active_version) {
        return 404;
    }

    add_header Cache-Control "public, max-age=31536000, immutable";
    try_files /$asset_path =404;
}

$active_version can be set via an environment variable or included file so Nginx knows which version is current.

This ensures only the active version is served, preventing old assets from being reused after deployment.

Cache Behavior

Entry Points

Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0

Always fetched from the network.
Detects new versions immediately.

Versioned Assets

Cache-Control: public, max-age=31536000, immutable

Cached for one year.
Never revalidated while version remains the same.

New version = new folder = automatic cache bust.

What Users Experience

First Visit

Loads entry points and versioned assets.
Flutter initializes normally.

Second Visit (Same Version)

Entry points fetched fresh.
Bulk assets loaded instantly from cache.

After Deployment

Entry points detect new version.
App loads new version’s assets automatically.
Old cached files remain but aren’t used.

Zero downtime, no forced refresh.

Best Practices

Use semantic versions like v1.2.3.
Keep entry points small for fast version detection.
Validate versions in Nginx to avoid stale assets.
Log the version in the browser console for debugging.
Purge or rotate old folders occasionally to save storage.

Why It Works

Version in URL = cache key — instant cache busting.
Immutable assets — best‑case caching for performance.
Fresh entry points — ensures the browser always learns about updates.
Server‑side validation — protects against stale or mismatched bundles.

This simple pattern turns Flutter Web deploys from a headache into a smooth, predictable process—all with standard Nginx and a few lines of JavaScript.

Podman on GitLab CI: Fast, Efficient Container Builds — No DinD Required

Serge Matveenko — Thu, 16 Oct 2025 08:18:15 +0000

If you’re still relying on Docker-in-Docker (DinD) for container builds in GitLab CI, there’s a cleaner, faster way: Podman. Combined with GitLab’s cache, Podman lets you use RUN --mount=type=cache just like on your local machine — without a privileged Docker service. This approach gives you rootless, reproducible builds that efficiently reuse dependency caches across pipelines.

Inspired by my tiny repo lig/coredns-zoner, this guide generalizes the setup for popular languages and package managers. We’ll also note one caveat about GitLab.com’s cache implementation and how a self-managed GitLab can provide even faster caching.

Why Use Podman in CI?

No Docker-in-Docker service: Build inside a single container image (like quay.io/podman/stable) — no privileged daemon required.
Rootless operation: Works seamlessly with GitLab’s container executor.
Native caching: Podman/Buildah natively support RUN --mount=type=cache, letting you reuse dependency caches across builds.

How `RUN --mount=type=cache` Speeds Up Builds

When you use RUN --mount=type=cache,target=/some/dir in your Containerfile, the specified directory persists across builds. This avoids redownloading dependencies and refetching packages every run.

Common examples:

Go: /go/pkg/mod
Rust: /cargo/registry, /cargo/git
Node: /root/.npm or /usr/local/share/.cache/yarn
OS packages: /var/cache/apk, /var/cache/apt

These caches are available only during the RUN step — they’re not stored in the image itself, just reused between builds to save time.

A Real-World Example

In lig/coredns-zoner, Podman is used with cache mounts directly in the Containerfile:

FROM alpine/git AS clone
WORKDIR /src
RUN --mount=type=cache,target=/src/.git \
    git init -b master && \
    git remote add origin https://github.com/coredns/coredns.git || \
    git remote set-url origin https://github.com/coredns/coredns.git && \
    git fetch --tags --prune --auto-gc && \
    git switch -d $(git describe --tags --no-abbrev origin/HEAD) > /dev/null && \
    git reset --hard

FROM golang:1-alpine AS build
WORKDIR /src
COPY --from=clone /src /src
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=source=plugin.cfg,target=/src/plugin.cfg,relabel=shared \
    go generate && go build

FROM alpine AS app
ENTRYPOINT ["/coredns"]
COPY --from=build /src/coredns /coredns

The key part: Git and Go caches are mounted for reuse between builds — no extra scripting or hacks.

The project’s .gitlab-ci.yml runs Podman builds without DinD, caching Buildah’s temporary data inside the project workspace:

stages:
  - build

build:
  stage: build
  image: quay.io/podman/stable:latest
  variables:
    TMPDIR: ${CI_PROJECT_DIR}/.local/tmp
  before_script:
    - mkdir -p ${CI_PROJECT_DIR}/.local/tmp
    - echo "$CI_REGISTRY_PASSWORD" | podman login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
  script:
    - podman build --pull --cache-from "${CI_REGISTRY_IMAGE}" -t "${CI_REGISTRY_IMAGE}" .
    - podman push "${CI_REGISTRY_IMAGE}"
  cache:
    paths:
      - .local/tmp/buildah-cache-0

Making Cache Persistent Between Pipelines

There are two complementary layers of caching:

GitLab CI file cache
A directory (e.g., TMPDIR) is cached inside the project workspace, persisting data used by RUN --mount=type=cache between jobs and pipelines.
Registry-based image cache
Podman/Buildah can also store cached layers in the container registry. Use both --layers and --cache-to/--cache-from flags to enable it:

   podman build \
     --layers \
     --cache-to=type=image,ref="$CI_REGISTRY_IMAGE:build-cache" \
     --cache-from=type=image,ref="$CI_REGISTRY_IMAGE:build-cache" \
     -t "$CI_REGISTRY_IMAGE" .

Using both methods — file cache for dependency directories and registry cache for build layers — yields the best speed gains.

Example Containerfile Patterns

Go modules

FROM golang:1.22-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod go mod download
COPY . .
RUN --mount=type=cache,target=/go/pkg/mod CGO_ENABLED=0 go build -o /out/app ./cmd/app

Rust (cargo)

FROM rust:1-alpine AS build
WORKDIR /src
ENV CARGO_HOME=/cargo
RUN mkdir -p /cargo/git /cargo/registry
COPY Cargo.toml Cargo.lock ./
RUN --mount=type=cache,target=/cargo/registry --mount=type=cache,target=/cargo/git cargo fetch
COPY . .
RUN --mount=type=cache,target=/cargo/registry --mount=type=cache,target=/cargo/git cargo build --release

Node (npm)

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci --prefer-offline
COPY . .
RUN --mount=type=cache,target=/root/.npm npm run build

Alpine packages (apk)

FROM alpine:3
RUN --mount=type=cache,target=/var/cache/apk apk add --no-cache build-base git

⚙️ Cache mounts exist only during the RUN step. If you need artifacts created in a cached directory, copy them elsewhere within the same RUN.

Practical Notes Before Setting Up CI

TMPDIR** controls Buildah’s cache location**. Any RUN --mount=type=cache targets are automatically stored there — no Containerfile changes are required.
Keep ***TMPDIR***** inside your project workspace** so GitLab can cache it between jobs.
Enable layer caching by using --layers with --cache-to/--cache-from for a portable, registry-backed build cache.

Generic `.gitlab-ci.yml` Example

stages: [build]

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  CACHE_IMAGE: $CI_REGISTRY_IMAGE:build-cache
  TMPDIR: ${CI_PROJECT_DIR}/.ci/tmp

build:
  image: quay.io/podman/stable:latest
  stage: build
  before_script:
    - mkdir -p "$TMPDIR"
    - echo "$CI_REGISTRY_PASSWORD" | podman login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
  script:
    - podman build --pull --layers \
        --cache-from=type=image,ref="$CACHE_IMAGE" \
        --cache-to=type=image,ref="$CACHE_IMAGE" \
        -t "$IMAGE" .
    - podman tag "$IMAGE" "$CI_REGISTRY_IMAGE:latest"
    - podman push "$IMAGE"
    - podman push "$CI_REGISTRY_IMAGE:latest"
  cache:
    paths:
      - .ci/tmp/

Key Advantages

No Docker-in-Docker: Podman runs natively within a single container, eliminating DinD complexity.
Local-like caching: The same RUN --mount=type=cache behavior you use locally now works seamlessly in CI.
Registry cache support: Combine GitLab cache with Podman’s registry cache for best performance.

Caveat: GitLab.com Cache Behavior

On GitLab.com’s shared runners, caches are zipped and uploaded to S3 after each job and restored before the next. While reliable, this process can add extra time for large caches (compression and transfer overhead).

A Faster Option for Self-Managed GitLab

In self-managed GitLab, you can mount your S3 storage via FUSE (or another network filesystem). This avoids compression entirely, making caches behave like live directories and dramatically speeding up builds — especially with large dependency sets.

✅ Setup Checklist

Use this checklist to ensure your Podman + GitLab CI caching setup works efficiently:

Prepare the environment

Use a CI image that includes podman (e.g., quay.io/podman/stable).
Ensure your GitLab runner supports the container executor (no privileged DinD needed).

Set up workspace caching

Define TMPDIR=${CI_PROJECT_DIR}/.ci/tmp in your CI variables.
Create the directory in before_script with mkdir -p "$TMPDIR".
Add it to cache: paths: in .gitlab-ci.yml so the contents persist across jobs.

Configure your Containerfile

Use RUN --mount=type=cache for dependency-heavy directories (e.g., /go/pkg/mod, /root/.npm, /cargo/registry).
You don’t need to adapt the file structure — Podman automatically caches those directories under TMPDIR.

Optimize layer caching

Build with --layers enabled.
Add --cache-to and --cache-from pointing to your container registry (e.g., $CI_REGISTRY_IMAGE:build-cache).

Authenticate and push

Log into your registry with podman login in the before_script.
Push both the image and the cached layers to your registry.

Verify caching efficiency

Check build logs for reuse of cached layers and cached mounts.
Ensure cache restoration reduces dependency fetch or install times.

Understand caching trade-offs

GitLab.com runners zip and upload caches to S3, which may slow down large caches.
In self-managed GitLab, prefer a FUSE-mounted S3 bucket or local cache directory for near-instant caching.

Wrap-Up

Using Podman with GitLab CI delivers faster, cleaner, and rootless container builds — no Docker daemon required. By combining file-based caching (via GitLab CI) and registry-based caching (via --cache-to/--cache-from), you can achieve near-local build performance.

RSS: A Great Standard That Can’t Keep Up

Serge Matveenko — Sat, 01 Feb 2025 22:28:48 +0000

RSS (en.wikipedia.org/wiki/RSS) has long been praised as a decentralized, open standard for content syndication. It allows users to aggregate and consume updates from various sources in a unified way. However, as the web has scaled and usage patterns have evolved, RSS has become increasingly inefficient. Its core limitation? The "pull" model, which places an unsustainable burden on both servers and clients.

The Problem with RSS: Inefficient Polling

At its core, RSS clients periodically check (or "poll") a feed URL to see if there are any new updates. This process occurs regardless of whether the server has new content. While this might seem trivial for a handful of users, the situation quickly deteriorates at scale. If thousands or even millions of clients continuously request updates from a server, that server must respond to each one, whether it has new content or not. The result? Unnecessary traffic, wasted resources, and eventual overload.

Worse yet, the polling frequency needs to strike a balance. Poll too infrequently, and users receive delayed updates. Poll too often, and the load on the server spikes dramatically. There’s no elegant way around this trade-off.

A Better Alternative: The Push Model of ActivityPub

ActivityPub (en.wikipedia.org/wiki/ActivityPub), an open standard for federated social networking, takes a fundamentally different approach. Instead of having clients constantly check for updates, it uses a "push" model. When new content is published, the server notifies interested clients (or other federated servers) only when necessary. No polling, no wasted requests—just efficient, on-demand content distribution.

With ActivityPub, no work is done when there are no updates. The server only engages when something new is published, sending notifications to subscribers efficiently. Additionally, the server can handle updates asynchronously, allowing it to plan resource distribution more effectively while notifying clients. This drastically reduces server load, making it far more scalable than RSS, especially in high-traffic environments.

Why RSS Can’t Keep Up

Despite its strengths—openness, decentralization, and ease of implementation—RSS struggles under modern internet-scale loads. The inefficiencies of its polling mechanism make it unsuitable for large-scale deployments where real-time updates and minimal resource consumption are critical.

This doesn’t mean RSS has no place; it’s still useful for niche applications, small-scale syndication, and personal use. But for platforms handling significant traffic, push-based alternatives like ActivityPub provide a more efficient and scalable solution.

The Future of Content Distribution

As the internet continues to grow, so too must our tools for content distribution. While RSS was revolutionary in its time, the modern web demands smarter, more scalable solutions. Push-based protocols like ActivityPub represent the next step in decentralized content sharing—one that eliminates unnecessary load and ensures updates are delivered efficiently. Future standards could extend this push model even further, allowing closer integration with clients by building on top of ActivityPub’s efficient server-to-server communication, enabling more seamless, real-time updates without excessive resource consumption.

RSS isn’t dead, but in an era where scalability matters more than ever, its limitations are impossible to ignore.

The Object-Relational Impedance Mismatch in Database Schema and API Integration

Serge Matveenko — Mon, 19 Jun 2023 10:25:37 +0000

When designing a database-driven application with an accompanying API, developers often encounter the challenge known as the object-relational impedance mismatch. While there is a desire to use the same schema for both components, this mismatch requires additional measures to ensure data security and authorized access. In this blog post, we explore the impact of the object-relational impedance mismatch and the need for a middle layer between the database and API, dispelling the notion that a seamless sharing of schema is feasible.

The Promise of Consistency

Using a unified schema for the database and API holds the promise of consistency, reducing duplication of efforts and simplifying development. Frameworks like Django Rest Framework provide tools to address the object-relational impedance mismatch and achieve a certain level of cohesion by mapping between object-oriented models and relational database structures.

Wrappers and Guards

However, the object-relational impedance mismatch necessitates additional considerations beyond schema alignment. Merely relying on the shared schema is insufficient to address issues related to data filtering and authorized access. Wrappers and guards must be implemented to bridge the gap and mitigate the challenges posed by the mismatch. These components act as intermediaries, addressing the differences in structure and behavior between the object-oriented model and the relational database.

Filtering Internal Data

The object-relational impedance mismatch often requires filtering or sanitizing the data exposed through the API. Certain internal data or sensitive information may not be suitable for public consumption. By incorporating a middle layer, developers can address this mismatch and apply filters and transformations to ensure that only relevant and appropriate information is exposed through the API. This middle layer acts as a bridge, harmonizing the differences between the object-oriented representation and the underlying relational database.

Ensuring Authorized Access

Controlling access to the data is a critical consideration in the presence of the object-relational impedance mismatch. The API should only provide authorized users with the appropriate level of access to the database. The middle layer, acting as a translator between the object-oriented model and the database, can implement robust authentication and authorization mechanisms. By verifying user credentials, roles, and permissions, the middle layer ensures that only authorized users gain access to the requested data, mitigating the challenges presented by the mismatch.

Mixing Semantics and API

Furthermore, incorporating semantic data into the API introduces further complexity in the context of the object-relational impedance mismatch. Semantic data adds meaning and context to the information, enabling more sophisticated interactions and intelligent processing. However, this often requires additional layers of abstraction and customization that may not align with the structure of the shared schema. As a result, accommodating semantic data becomes challenging when trying to seamlessly share the same schema for both database access and API consumption.

Final Thoughts

The object-relational impedance mismatch presents challenges that extend beyond schema alignment in the integration of a database schema and API. While using the same schema holds appeal for its potential simplicity, the need for a middle layer becomes apparent. Wrappers, guards, and additional logic address issues such as data filtering, authorized access, and the incorporation of semantic data. By acknowledging and mitigating the object-relational impedance mismatch, developers can strike a balance between efficiency and security, delivering robust and scalable applications that harmoniously handle the challenges presented by the mismatch.

Tabs vs Spaces Divorce: Judge Rules

Serge Matveenko — Mon, 12 Jun 2023 23:20:26 +0000

Judge: "So, Mrs. Doe, please explain why you're seeking a divorce from your spouse, Mr. Doe."

Mrs. Doe: "Your Honor, I never thought I'd say this, but it's because of the tabs!"

Judge: "Tabs? Could you please elaborate?"

Mrs. Doe: "Certainly, Your Honor. We're both software engineers, and I've always been a firm believer in using spaces for indentation in my code. But Mr. Doe, well, he's a tab enthusiast."

Judge: "Ah, I see. And that's a deal-breaker for you?"

Mrs. Doe: "Absolutely, Your Honor. I mean, we've had our differences in the past, like curly braces placement and even semicolon usage, but this tab thing is just too much to handle. It's like trying to decipher hieroglyphics every time I look at his code!"

Judge: "Interesting. And have you attempted to compromise on this matter?"

Mrs. Doe: "Oh, we've tried, Your Honor. We've even attended counseling sessions, but we just can't seem to find a common ground. It's like living in two separate code universes."

Judge: "I can understand the frustration, Mrs. Doe. Code formatting can be a contentious issue. Is there anything else you'd like to add?"

Mrs. Doe: "Only that this divorce isn't just about our personal lives, Your Honor. It's about the future of clean and readable code. I can't let our disagreement over tabs ruin the harmony of my syntax!"

Judge: "Very well, Mrs. Doe. I believe I have a good grasp of the situation. We'll proceed accordingly. And may I suggest, for the sake of your professional sanity, you both consider adopting an agreed-upon code style in future relationships?"

Mrs. Doe: "Thank you, Your Honor. I'll keep that in mind. But for now, I need to move on to someone who understands the importance of proper indentation."

Judge: "Understandable, Mrs. Doe. The court will take your request into consideration. Case adjourned."

Remember, it's just a joke, and code style preferences should never be taken as grounds for a real divorce!

The Nuance of Code Style: Emphasizing Return Value Significance in Python

Serge Matveenko — Wed, 31 May 2023 12:18:34 +0000

In the world of programming, code style plays a crucial role in making code readable, maintainable, and understandable for developers. While adhering to established coding conventions is essential, there are often nuanced decisions that arise when it comes to certain aspects of code, such as return statements. In this blog post, we'll explore an interesting code style nuance related to return statements and discuss when it might be better to use the bare return as opposed to explicitly returning a value.

Consider the following code snippet:

def odd_or_none(value: int) -> int | None:
    if value % 2 == 0:
        return None
    return value

In this example, the function odd_or_none takes an integer value as input and determines if it's odd or even. If the value is even, the function explicitly returns None, indicating that the resulting value is meaningful within the context of the program's logic. However, if the value is odd, it returns the value itself.

The rationale behind this approach is to differentiate between scenarios where the return value has no particular meaning versus cases where the return value holds significance for downstream logic.

Using return None explicitly in the case of an even value signifies that the resulting None will be used in subsequent code, conveying a specific intention. On the other hand, in methods like __init__ or any other method that always returns None by convention, the bare return statement emphasizes the fact that the result is not going to be used.

Upon reflection, following a consistent code style policy can enhance code readability and clarity. One such policy, which can be employed for functions that have a return type of None, is as follows:

For functions that return None, use the bare return statement. This indicates that the function does not return anything and that the resulting value is of no particular significance.

For functions that return either None or another value (None | Some), use an explicit return None statement. This signifies that the function's return value will be utilized in subsequent code, conveying its relevance.

By adhering to this policy, the codebase becomes more consistent, enabling developers to easily grasp the intent behind different return statements and their implications.

Python is broken? Strings are sequences of strings 🤦

Serge Matveenko — Thu, 04 May 2023 08:03:42 +0000

This is a piece of Python code that works, and no linter will complain about it.

def average_length(strings: Sequence[str]) -> float:
    total_length = sum(len(string) for string in strings)
    return float(total_length) / len(strings)

print(average_length(["foo", "bar", "spam"]))
#> 3.3333333333333335

print(average_length("Hello World!"))
#> 1.0

It looks like "Hello World!" shouldn't be a valid input for the average_length function. The intent is obviously to calculate an average length of a sequence of strings like ["foo", "bar", "spam"]. Why is this happening?

Well, an str instance is a sequence of strings as well: it has length, it's iterable, and it even can be reversed (see https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes). So, from the interpreter's point of view, any string in Python is just a sequence of one-character strings.

I'm not saying that Python is broken. It is the way it is, and it is not changing soon. However, what could be changed that will cause minimal harm but still will make things a bit better? I suggest introducing a built-in single character type, i.e. char. This immediately will result in str becoming Sequence[char] and not Sequence[str]. Other than requiring length to be precisely one, the char type could behave exactly like str.

Also, things like chr and ord functions could benefit from a more precise type annotation using char instead of str.

I think this would be a great addition to the language.

Building Resilient Software Architecture: Lessons Learned from the Domino Game

Serge Matveenko — Thu, 06 Apr 2023 19:12:07 +0000

Software development projects are complex, with many moving parts that must work together seamlessly to achieve the desired outcome. When a single weak point or flaw appears in the software architecture, the entire project can be derailed, much like a single domino piece missing from a chain reaction can ruin the entire game.

In a game of dominoes, players must carefully arrange the tiles in a pattern, with each piece dependent on the one before it. One missing tile can cause the entire chain to break down, rendering the game unplayable. Similarly, in software development, every component of the architecture is dependent on the others, and a flaw in any one of them can cause the entire system to fail.

For example, a single security vulnerability in a web application can be exploited to gain access to sensitive data or to bring the entire system down. A weak link in a data processing pipeline can cause errors to propagate through the system, leading to incorrect results or a complete failure of the process. In a distributed system, a single node that goes offline or fails to respond can cause a cascading failure that brings the entire system down.

Just as a missing domino tile can be hard to spot until it's too late, weak points in software architecture can be difficult to detect early on. They may only become apparent when the system is under stress or when a particular scenario is encountered that exposes the flaw. However, unlike in a game of dominoes where the consequences are limited to that one game, the consequences of a software architecture flaw can be far-reaching and costly.

To avoid the risk of a single weak point ruining an entire software project, developers must take a proactive approach to identifying and addressing vulnerabilities in the architecture. This requires a thorough understanding of the system's requirements, potential failure modes, and areas of risk, as well as ongoing monitoring and testing to ensure that the system remains secure and stable over time.

In conclusion, a single domino piece missing can ruin a game, and a single weak point in a software architecture can ruin an entire software project. Both scenarios emphasize the importance of attention to detail, careful planning, and ongoing monitoring to ensure that all components are working together seamlessly. By taking a proactive approach to architecture design and testing, developers can minimize the risk of catastrophic failure and build systems that are reliable, secure, and resilient.

Beyond the Recipe: Why Communication Needs More than Just a Pinch of AI

Serge Matveenko — Tue, 04 Apr 2023 23:55:51 +0000

In the age of Artificial Intelligence (AI), it's easy to think that technology has made everything so simple and effortless. From shopping online to booking travel, everything seems to be automated and efficient. However, a recent caricature from Marketoonist has highlighted the importance of human effort and engagement in our communication and understanding of information.

The caricature shows a man writing an email with the help of AI based on a single sentence, and the recipient using an AI to summarize the email back into one sentence. While this may seem like a quick and easy way to communicate, it emphasizes the fact that just sending a single phrase isn't enough. We still need to see an effort from the author and, more importantly, we need to make some effort to extract an important piece of information out of it. Otherwise, we won't be satisfied enough with that piece of information as we didn't do enough to get it.

This concept is similar to how we don't just want to consume nutrients in a pure form. We need food to taste nice, to look nice, and we need to feel like we did enough cooking the food and extracting nutrients out of it. Similarly, when we communicate with others, we need to put in effort and care to ensure that we're delivering the information effectively and that the recipient is understanding it correctly.

In today's fast-paced world, it's easy to fall into the trap of wanting everything to be done quickly and efficiently. However, it's important to remember that sometimes, the best things in life require a bit of effort and engagement. Whether it's taking the time to prepare a delicious meal or putting in the effort to write a thoughtful email, the end result is always more satisfying when we know we've put in the effort.

The caricature is a reminder that AI is not a substitute for human effort and engagement. While technology has certainly made our lives easier in many ways, we still need to make an effort to connect with others and understand information fully. By doing so, we can ensure that we're not just communicating effectively, but that we're also building meaningful relationships and connections with those around us.

In conclusion, while the caricature may be a humorous representation of our reliance on technology, it also serves as a reminder that human effort and engagement are essential for effective communication and understanding. Let's not forget to put in the effort to truly connect with others and extract important information, just as we don't want to miss out on the taste and nutrients that come from a well-cooked meal.