Chill Bits

Files System Dev – 11/02

—

Making Border Rendering Production-Ready

Today was a transition day — from “it works in a test folder” to “it’s a real production feature.”

1. Stabilised Border Rendering (3mm & 5mm)

I finalized both pipelines:

  • 3mm border
  • 5mm border

Both now support:

  • Centered deterministic crop (Step 1)
  • Exact mm-based border addition (Step 2)
  • Absolute print size logic (6×4 == 4×6)
  • Auto-orientation based on source image ratio
  • DPI-consistent pixel conversion
  • Strict dimension validation
  • Tolerant but reliable image comparison
  • Composite + diff output on failure

The key improvement:

The system now fails loudly when it should. Earlier, the comparison falsely passed even when crops were visibly wrong. Fixing that exposed how important normalization + proper reference binding really is.

Lesson:

Never trust a visual pipeline without a self-test that can actually fail.

2. Converted Commands to Production Mode

Reworked both border commands to:

  • Accept UUID
  • Accept expected print size (8×12, 6×4, etc.)
  • Resolve source path via UploadSession
  • Use temporary working directories
  • Publish final output
  • Print public URL
  • Exit non-zero on failure

This was a big shift:

From:

test-border-renderer/original.jpg

To:

php artisan border:process-one-5mm {uuid} 8x12

Now it’s not a test utility — it’s an operational tool.

Lesson:

Production readiness is mostly about boundaries:

  • Input validation
  • Deterministic math
  • Clear exit codes
  • No partial state leaks

3. Implemented Absolute Size Normalisation

Added second param:

8x12

Normalized logic:

  • 8×12 == 12×8
  • Canonicalized for hashing + orientation
  • Derived mm consistently
  • Border subtraction applied deterministically

This removes ambiguity and makes the API predictable.

Lesson:

Normalize early.

Hash normalized data.

Never hash raw user input.

4. Built Bulk Border Generation Endpoint

New endpoint:

POST /api/v1/border-generation

Features:

  • Payload hash → request_key
  • Idempotent behavior
  • Request-level + per-image tracking tables
  • Status roll-up logic
  • Dedicated log file
  • Supports both 3mm & 5mm
  • Handles duplicate requests gracefully

If the same payload is posted again (even reordered images), it returns the same request.

That’s a big architectural win.

Lesson:

Idempotency is not optional in batch systems.

5. Fixed Lumen Compatibility Issue

Hit:

Call to undefined function public_path()Code language: JavaScript (javascript)

Reminder:

Lumen ≠ Laravel.

Replaced helper usage with basePath resolution.

Lesson:

Assume nothing. Especially helpers.

6. Unified EXIF Extraction

Aligned:

  • ReextractImageExif (command)
  • ProcessImageExif (job)

Extracted shared logic to a common service.

Now:

  • Command re-extract
  • Upload async job
  • Any future pipeline

All use the same extraction code.

Lesson:

Two code paths doing the same thing will eventually diverge.

Centralize early.

7. Ensured Dropbox Publishing Consistency

Updated new border jobs/commands to:

  • Reuse existing Dropbox publish service
  • Follow same path conventions
  • Store Dropbox URL in tracking records
  • Log publish lifecycle

No parallel upload logic. One path only.

Lesson:

Integration code must have a single source of truth.

What I Really Learned Today

  1. Image processing is math.
  2. Image processing in production is engineering.
  3. Engineering in production is mostly about:
    • Idempotency
    • Determinism
    • Observability
    • Failure clarity

The border feature started as “add white around image.”

It became:

  • Size normalization
  • Crop geometry
  • Pixel/mm/DPI conversions
  • Hash-based request dedupe
  • Async job orchestration
  • Multi-destination publishing
  • Log isolation
  • Schema design

And that’s the real story of backend development:

The visible result is simple.

The invisible guarantees are everything.