DEV Community: Vicente G. Reyes

How I Shaved 10 MB Off My Portfolio in One Command

Vicente G. Reyes — Wed, 03 Jun 2026 03:41:29 +0000

PageSpeed Insights had been staring at me for weeks. Desktop was holding at 91. Mobile was stuck at 63. I'd already fixed the obvious stuff — non-blocking fonts, preconnects, fetchpriority on the hero image. But there it was, every single run:

Improve image delivery — Est savings of 985 KiB

Nearly a megabyte of wasted transfer, just from six project screenshots. And that was just the images visible above the fold. The full list across all projects was worse.

The culprit: every image I'd ever uploaded through the Django admin was a PNG. Some of them were over 1 MB. WebP would have cut most of them by 80%. I knew this. I just hadn't done anything about it.

So I wrote a management command to fix the backlog, and then made the model auto-convert on every future upload so I'd never have to think about it again.

The Problem With PNGs in a Portfolio

When you're building a portfolio, you screenshot your work and drag it into the admin. That screenshot is usually a PNG — lossless, full-size, straight from your display. Nobody optimises it because the admin accepts it and it shows up fine in the browser.

But "shows up fine" isn't the same as "loads fast." A 1.4 MB PNG of a law firm homepage does not need to be 1.4 MB. Served as WebP at quality 85, it's 175 KB. Same visual result. Eight times smaller.

Multiply that across 28 projects and you're looking at tens of megabytes that mobile users on slow 4G are downloading just to scroll past thumbnails.

The One-Time Backlog Fix: A Management Command

First, I needed a way to convert everything that was already in S3. A management command was the right tool — it runs in the production container with full access to the Django ORM and the configured storage backend, so it can read and rewrite files without needing to know whether they're on S3, local disk, or anywhere else.

# backend/projects/management/commands/convert_images_to_webp.py

from io import BytesIO

from django.core.files.base import ContentFile
from django.core.management.base import BaseCommand
from PIL import Image

from backend.projects.models import AudioWork, Project


def _to_webp(field_file, quality: int = 85) -> tuple[ContentFile, str] | None:
    try:
        with field_file.open("rb") as f:
            img = Image.open(f)
            img.load()
    except OSError as exc:
        return None, str(exc)

    mode = "RGBA" if img.mode in ("RGBA", "LA", "P") else "RGB"
    img = img.convert(mode)

    buf = BytesIO()
    img.save(buf, format="WEBP", quality=quality, method=6)
    buf.seek(0)

    old_name = field_file.name
    new_name = old_name.rsplit(".", 1)[0] + ".webp"
    return ContentFile(buf.read(), name=new_name), new_name


class Command(BaseCommand):
    help = "Convert project and audio work images stored in S3 to WebP format."

    def add_arguments(self, parser):
        parser.add_argument("--quality", type=int, default=85)
        parser.add_argument("--dry-run", action="store_true")
        parser.add_argument("--skip-existing", action="store_true", default=True)

    def _convert_field(self, obj, field_name, quality, dry_run, skip_existing):
        field = getattr(obj, field_name)
        if not field:
            return "skip-empty"

        name = field.name or ""
        if skip_existing and name.lower().endswith(".webp"):
            return "skip-webp"

        webp_file, new_name = _to_webp(field, quality)
        if webp_file is None:
            self.stderr.write(f"    ERROR: {name}: {new_name}")
            return "error"

        old_size = field.size
        new_size = webp_file.size

        if dry_run:
            savings = old_size - new_size
            self.stdout.write(
                f"    [dry-run] {name} → {new_name} "
                f"({old_size // 1024} KiB → {new_size // 1024} KiB, "
                f"saves {savings // 1024} KiB)"
            )
            return "would-convert"

        field.delete(save=False)
        getattr(obj, field_name).save(new_name.split("/")[-1], webp_file, save=True)
        self.stdout.write(
            self.style.SUCCESS(f"    ✓ {name} → {new_name}")
        )
        return "converted"

    def handle(self, *args, **options):
        quality = options["quality"]
        dry_run = options["dry_run"]
        skip_existing = options["skip_existing"]

        for project in Project.objects.exclude(image="").exclude(image__isnull=True):
            self.stdout.write(f"  {project.title}")
            self._convert_field(project, "image", quality, dry_run, skip_existing)

        for work in AudioWork.objects.exclude(cover_image="").exclude(cover_image__isnull=True):
            self.stdout.write(f"  {work.title}")
            self._convert_field(work, "cover_image", quality, dry_run, skip_existing)

The logic is straightforward: open the file from storage, convert to WebP with Pillow, delete the original, save the new one. The --dry-run flag prints what would happen without touching anything — which I always run first in production.

The Pillow mode handling is worth noting

WebP supports transparency, so if the source image is RGBA (PNG with alpha channel) or has a palette with transparency, I keep it in RGBA mode. Everything else gets converted to RGB first. Trying to save a palette-mode image directly to WebP will throw an error.

mode = "RGBA" if img.mode in ("RGBA", "LA", "P") else "RGB"
img = img.convert(mode)

Running it

# See what will happen without writing anything
docker compose -f docker-compose.production.yml run --rm django \
  python manage.py convert_images_to_webp --dry-run

# Run for real
docker compose -f docker-compose.production.yml run --rm django \
  python manage.py convert_images_to_webp

The dry run output on my portfolio:

Project: Leagogo Law Firm
  [dry-run] projects/LAA_Law.png → projects/LAA_Law.webp (1423 KiB → 175 KiB, saves 1247 KiB)
Project: Flower Head Events
  [dry-run] projects/Flower_Head_Events.png → projects/Flower_Head_Events.webp (1187 KiB → 83 KiB, saves 1103 KiB)
Project: HSM Homes
  [dry-run] projects/HSM_Homes.png → projects/HSM_Homes.webp (1117 KiB → 92 KiB, saves 1024 KiB)
Project: Big Boy Shawarma
  [dry-run] projects/BigBoyShawarma.png → projects/BigBoyShawarma.webp (898 KiB → 43 KiB, saves 855 KiB)
...
Would convert: 30

30 images. Thousands of KiB saved. One command.

The Permanent Fix: Auto-Convert on Upload

The command handles the backlog. But what about the next project I add? I don't want to run the command manually every time I upload a screenshot.

The fix is in the model's save() method. After the original file is written to storage, detect if it needs conversion and replace it in place:

# backend/projects/models.py

from io import BytesIO
from django.core.files.base import ContentFile
from django.db import models
from PIL import Image


def _convert_to_webp(field_file, quality: int = 85) -> ContentFile | None:
    try:
        with field_file.open("rb") as fh:
            img = Image.open(fh)
            img.load()
    except OSError:
        return None

    mode = "RGBA" if img.mode in ("RGBA", "LA", "P") else "RGB"
    img = img.convert(mode)

    buf = BytesIO()
    img.save(buf, format="WEBP", quality=quality, method=6)
    buf.seek(0)

    filename = field_file.name.rsplit("/", 1)[-1].rsplit(".", 1)[0] + ".webp"
    return ContentFile(buf.read(), name=filename)


def _save_as_webp(instance, field_name: str) -> None:
    field = getattr(instance, field_name)
    if not field or str(field.name).lower().endswith(".webp"):
        return
    webp = _convert_to_webp(field)
    if webp is None:
        return
    field.delete(save=False)
    getattr(instance, field_name).save(webp.name, webp, save=True)


class Project(models.Model):
    image = models.ImageField(upload_to="projects/", blank=True, null=True)
    # ... other fields

    def save(self, *args, **kwargs):
        updating_image = not kwargs.get("update_fields") or "image" in (
            kwargs.get("update_fields") or []
        )
        super().save(*args, **kwargs)
        if updating_image:
            _save_as_webp(self, "image")

The important detail: super().save() runs first. That writes the original file to storage. Then _save_as_webp opens it, converts it, deletes the original, and saves the WebP. Yes, this means two writes to S3 per upload — but uploads happen rarely and through the admin, so the overhead is irrelevant. The read path, which runs on every page load, now always gets WebP.

The update_fields check prevents unnecessary conversion when saving unrelated fields. If someone updates just the project title from the admin, the image field is left alone.

The Result

After running the command and deploying the model change:

30 existing images converted from PNG to WebP
Average reduction: ~80% per image
Largest single saving: 1,247 KiB (a 1.4 MB PNG → 175 KB WebP)
PageSpeed Insights no longer flags "Improve image delivery" for S3-hosted images
Every future upload auto-converts — no manual intervention needed

The mobile performance score still has room to improve (the mobile LCP is dominated by React's JS parse time, which is a different problem). But knocking nearly 10 MB of unnecessary image weight off the page is a clean, permanent win.

What I'd Do Differently

If I were starting fresh, I'd use an ImageField subclass that intercepts the file before it's written — cleaner than the post-save dance. But overriding save() is pragmatic and works perfectly fine with Django admin, DRF serializers, and anything else that goes through the ORM.

I'd also consider storing images at display dimensions rather than full screenshot resolution. Even as WebP, a 1137×651 image served at 399×190 is wasting pixels. A future create_thumbnail step alongside the WebP conversion would push things further. That's next.

Building an RSS Feed for a Django + React Portfolio (With a Styled Browser View)

Vicente G. Reyes — Tue, 02 Jun 2026 07:33:42 +0000

RSS isn't dead. Developers still use feed readers, and having a proper /rss.xml or /blog/rss URL is a small but meaningful signal that your site is a real publication. My portfolio runs on a split stack — a React SPA on Vercel and a Django REST API on a separate domain — so adding RSS turned out to be more interesting than I expected. Here's exactly what I built, the bugs I hit along the way, and the final result.

The Setup

Frontend: React + Vite, deployed on Vercel at vicentereyes.org
Backend: Django (cookiecutter-django), deployed at backend.vicentereyes.org
Goal: RSS feed available at two URLs:
- vicentereyes.org/rss.xml — the classic URL people expect
- vicentereyes.org/blog/rss — the canonical feed linked from the blog page

The Django Feed

Django ships with a syndication framework that makes building RSS feeds straightforward. I created blogs/feeds.py:

from io import StringIO

from django.contrib.syndication.views import Feed
from django.utils.feedgenerator import Rss201rev2Feed

from .models import BlogPost

_SITE = "https://www.vicentereyes.org"
_FEED_URL = f"{_SITE}/blog/rss"
_XSL_URL = f"{_SITE}/rss.xsl"


class StyledRssFeed(Rss201rev2Feed):
    def write(self, outfile, encoding):
        buf = StringIO()
        super().write(buf, encoding)
        xml = buf.getvalue()
        # Insert XSL PI after the <?xml ...?> declaration line
        split = xml.index("\n") + 1
        outfile.write(xml[:split])
        outfile.write(f'<?xml-stylesheet type="text/xsl" href="{_XSL_URL}"?>\n')
        outfile.write(xml[split:])


class LatestBlogPostsFeed(Feed):
    feed_type = StyledRssFeed
    title = "Vicente Reyes - Blog"
    link = f"{_SITE}/blog"
    description = "Latest posts from Vicente Reyes"

    def feed_url(self):
        return _FEED_URL

    def items(self):
        return BlogPost.objects.order_by("-date_published")

    def item_title(self, item):
        return item.title

    def item_description(self, item):
        return item.brief

    def item_link(self, item):
        return f"{_SITE}/blog/{item.slug}-{item.uid}"

    def item_pubdate(self, item):
        return item.date_published

    def item_author_name(self, item):
        return item.author_name

Why My Analytics Was Logging Every Page Visit Twice (And How I Fixed It)

Vicente G. Reyes — Mon, 01 Jun 2026 01:40:14 +0000

I built a custom analytics system into my portfolio backend — a Django REST API that records page visits — and wired the React frontend to call it whenever someone lands on a project or blog post detail page. It worked, except for one problem: every visit was logged twice.

This is the story of chasing the wrong root cause, wasting time on a fix that didn't work, and landing on a dead-simple solution that lives outside React entirely.

The Setup

The backend is a Django REST API with a PageVisit model. The frontend calls a single endpoint whenever a user lands on a detail page:

// POST /api/analytics/track/
{ "page_type": "project", "object_id": 33 }

On the React side, the call lives in a useEffect inside ProjectPage:

useEffect(() => {
  if (project?.id) api.trackPageView('project', Number(project.id));
}, [project?.id]);

The project data comes from a useProject hook that reads from localStorage cache first, then fetches from the API.

The Symptom

After visiting two project pages, the admin showed this:

637  Project  33
636  Project  33
635  Personal Projects  -
634  Project  30
633  Project  30

Two records per project visit, every single time.

First Suspect: React StrictMode

My first instinct was React StrictMode. In development, <React.StrictMode> intentionally double-invokes effects to surface side effects — it mounts the component, runs cleanup, then remounts it. If the effect fired on both the original mount and the simulated remount, that would explain exactly two records per visit.

The standard fix is a useRef guard: store the last tracked ID in a ref, and skip the call if it matches.

const trackedProjectId = useRef<string | null>(null);

useEffect(() => {
  if (project?.id && trackedProjectId.current !== String(project.id)) {
    trackedProjectId.current = String(project.id);
    api.trackPageView('project', Number(project.id));
  }
}, [project?.id]);

The logic: on the first run, the ref is null, so we track and set it to "33". On StrictMode's simulated remount, React preserves state and refs, so the ref is still "33" — the condition is false, and the second call is skipped.

I pushed this fix. The visits still doubled.

The Real Cause: A Full Remount, Not a Preserved One

React StrictMode's "double-invoke effects" behavior comes in two flavors. In the version I was thinking of, state and refs are preserved between the simulated unmount and remount — so a ref guard works perfectly. But if the component is fully remounting (fresh component instance, all state and refs reset to initial values), the ref starts as null again on every mount, and the guard is useless.

That's what was happening here. The component wasn't getting StrictMode's gentle "simulate and preserve" treatment — it was being torn down and recreated. Each fresh mount started with trackedProjectId.current = null, saw a project with id = 33, passed the guard, and fired the tracking call.

I confirmed this by looking at the hook. The useProject hook initializes from localStorage cache:

function useFetchSingle<T>(fetcher: () => Promise<T>, cacheKey: string) {
  const [data, setData] = useState<T | null>(() => readCacheSingle<T>(cacheKey));
  // ...
  useEffect(() => {
    fetcher().then((res) => { setData(res); /* write cache */ });
  }, []);
}

On a full remount, useState runs its initializer again. If the project is cached, data starts as the cached project immediately — project.id is available on the very first render, so the tracking effect fires right away. Then the component remounts again from scratch, the same initializer runs, the same project loads from cache, and the effect fires again.

A ref-based guard can't survive a full remount. By definition, refs reset to their initial value on a new component instance.

The Fix: Move Deduplication Outside React

If the component lifecycle can't be trusted to hold state across mounts, the guard needs to live somewhere that can: a module-level variable. In JavaScript, module-level variables are initialized once per page load and persist for the lifetime of the session, completely independent of component mount/unmount cycles.

I added a Set at the top of api.ts, outside the api object:

const _tracked = new Set<string>();

export const api = {
  // ...
  trackPageView: (
    pageType: 'professional_projects' | 'personal_projects' | 'audio_works' | 'blog_post' | 'project',
    objectId?: number,
  ) => {
    const key = `${pageType}:${objectId ?? ''}`;
    if (_tracked.has(key)) return Promise.resolve();
    _tracked.add(key);
    setTimeout(() => _tracked.delete(key), 3000);
    return fetch(`${BASE_URL}/analytics/track/`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ page_type: pageType, ...(objectId != null && { object_id: objectId }) }),
    }).catch(() => {});
  },
};

How it works:

On first call with "project:33", the key isn't in the set — we add it and fire the request.
Any duplicate call within the next 3 seconds hits _tracked.has(key) and returns immediately without a network request.
After 3 seconds, the key is removed, so legitimate return visits (user navigates away and comes back) are recorded correctly.

The 3-second window is long enough to absorb any double-mount behavior (which happens within milliseconds), and short enough that it doesn't suppress real repeat visits.

Component Code Stays Clean

Because the deduplication now lives in api.ts, the component code doesn't need any guard logic:

// ProjectPage.tsx
useEffect(() => {
  if (project?.id) api.trackPageView('project', Number(project.id));
}, [project?.id]);

// BlogPostPage.tsx
api.blogPost(lookup).then((data) => {
  setPost(data);
  if (data.id) api.trackPageView('blog_post', Number(data.id));
  // ...
});

Clean call sites, no leaking implementation details into components.

Takeaway

When a useRef guard doesn't fix a double-invocation problem, the component is fully remounting — not doing React StrictMode's state-preserving remount. In that case, any component-level guard will be reset on every mount and is useless.

The fix is to move the deduplication to a layer that outlives the component: a module-level variable. It's outside React's rendering model entirely, so no mount/unmount cycle can touch it.

Building a Resume Download Gate: Email Collection, Signed Tokens, and an S3 Lesson

Vicente G. Reyes — Fri, 29 May 2026 03:32:12 +0000

I wanted a soft gate on my resume download. Not a paywall. Just an email field — enough friction to filter bots, enough signal to know who's interested. What started as a straightforward feature turned into a three-part lesson: stateless token signing, S3 public access, and email delivery mechanics.

Here's the full story.

The Feature

The flow I wanted:

Visitor clicks "Download Resume" on the About page or Hero
A modal asks for their email
Backend validates the email (format + disposable domain check)
A signed, time-limited link is emailed to them
They click the link, the PDF opens

No database tokens. No cron jobs. No permanent S3 URLs floating around.

Part 1 — The Model and the Gate

The Resume Model

Resume follows the singleton pattern I already use for page headers — force pk=1 on every save, restrict add/delete in admin. One row, forever.

class Resume(models.Model):
    pdf = models.FileField(upload_to="resume/", storage=private_resume_storage)
    last_updated = models.DateField(default=date.today)

    def save(self, *args, **kwargs):
        self.pk = 1
        super().save(*args, **kwargs)

ResumeDownloadRequest logs every email that requests a link — no tokens, no expiry columns, just a record of who asked and when.

class ResumeDownloadRequest(models.Model):
    email = models.EmailField()
    created_at = models.DateTimeField(auto_now_add=True)
    unsubscribed = models.BooleanField(default=False)

    class Meta:
        ordering = ["-created_at"]

The unsubscribed flag is there for a future newsletter broadcast — when a new blog post goes out, skip anyone who opted out.

Blocking Disposable Emails

Before signing anything, the email is checked against a frozenset of ~70 known throwaway domains:

# core/validators.py
DISPOSABLE_EMAIL_DOMAINS: frozenset[str] = frozenset({
    "mailinator.com",
    "guerrillamail.com",
    "yopmail.com",
    "10minutemail.com",
    "trashmail.com",
    # ... ~70 total
})

def is_disposable_email(email: str) -> bool:
    if "@" not in email:
        return False
    domain = email.rsplit("@", 1)[-1].lower().strip()
    return domain in DISPOSABLE_EMAIL_DOMAINS

The serializer calls it in validate_email so DRF surfaces it as a standard field error.

Part 2 — `django.core.signing.TimestampSigner`

This is the part I hadn't used before. Django ships a signing module in django.core.signing that most people only know from cookies and sessions. It's a general-purpose tool for producing tamper-proof, time-limited strings — no database, no cache, no state anywhere.

from django.core import signing

signer = signing.TimestampSigner()

# Sign a payload — embeds the current timestamp
token = signer.sign_object({"pk": 1, "email": "user@example.com"})
# → "eyJwayI6MSwiZW1haWwiOiJ1c2VyQGV4YW1wbGUuY29tIn0:1wSd5Q:EHGb3ife..."

# Verify — raises SignatureExpired if older than max_age seconds
data = signer.unsign_object(token, max_age=900)  # 15 minutes
# → {"pk": 1, "email": "user@example.com"}

The token is three colon-delimited parts: base64-encoded JSON payload, a base64-encoded timestamp, and an HMAC signature derived from SECRET_KEY. Tamper any part and it raises BadSignature. Wait too long and it raises SignatureExpired.

No rows inserted. No rows deleted. The server is completely stateless between the two requests.

The Two API Views

RESUME_TOKEN_MAX_AGE = 900  # 15 minutes

class ResumeRequestDownloadView(APIView):
    authentication_classes = []
    permission_classes = []

    def post(self, request):
        serializer = ResumeDownloadRequestSerializer(data=request.data)
        if not serializer.is_valid():
            return Response(
                {"data": None, "message": "", "errors": serializer.errors},
                status=status.HTTP_400_BAD_REQUEST,
            )
        email = serializer.validated_data["email"]
        resume = Resume.objects.filter(pk=1).first()
        if not resume:
            return Response(
                {"data": None, "message": "No resume available.", "errors": None},
                status=status.HTTP_404_NOT_FOUND,
            )
        ResumeDownloadRequest.objects.create(email=email)
        signer = signing.TimestampSigner()
        token = signer.sign_object({"pk": resume.pk, "email": email})
        download_path = reverse("api:resume-download") + f"?token={token}"
        download_url = request.build_absolute_uri(download_path)
        expires_minutes = RESUME_TOKEN_MAX_AGE // 60
        self._send_download_email(email, download_url, expires_minutes)
        return Response({
            "data": None,
            "message": f"Check your inbox — the link expires in {expires_minutes} minutes.",
            "errors": None,
        })

    def _send_download_email(self, email, download_url, expires_minutes):
        body = (
            f"Hi there!\n\n"
            f"Here's your link to download my resume:\n\n"
            f"{download_url}\n\n"
            f"This link expires in {expires_minutes} minutes.\n\n"
            f"— Vicente Reyes\n"
            f"   https://vicentereyes.org"
        )
        with contextlib.suppress(Exception):
            send_mail(
                subject="Your resume download link",
                message=body,
                from_email=settings.DEFAULT_FROM_EMAIL,
                recipient_list=[email],
                fail_silently=True,
            )

class ResumeDownloadView(APIView):
    authentication_classes = []
    permission_classes = []

    def get(self, request):
        token = request.query_params.get("token", "")
        if not token:
            return Response(
                {"data": None, "message": "", "errors": {"token": ["This field is required."]}},
                status=status.HTTP_400_BAD_REQUEST,
            )
        signer = signing.TimestampSigner()
        data = None
        with contextlib.suppress(signing.SignatureExpired, signing.BadSignature):
            data = signer.unsign_object(token, max_age=RESUME_TOKEN_MAX_AGE)

        if data is None:
            try:
                signer.unsign_object(token)
                return Response(
                    {"data": None, "message": "Download link expired. Please request a new one.", "errors": None},
                    status=status.HTTP_410_GONE,
                )
            except signing.BadSignature:
                return Response(
                    {"data": None, "message": "Invalid download token.", "errors": None},
                    status=status.HTTP_400_BAD_REQUEST,
                )

        resume = Resume.objects.filter(pk=data.get("pk")).first()
        if not resume or not resume.pdf:
            return Response(
                {"data": None, "message": "Resume not found.", "errors": None},
                status=status.HTTP_404_NOT_FOUND,
            )
        return HttpResponseRedirect(resume.pdf.url)

The expired-vs-tampered distinction matters: 410 Gone tells the frontend "the link was real but timed out, ask again." 400 means the token is garbage. Different messages, different user actions.

Part 3 — The S3 Bypass

I shipped it. It worked. Then I opened the S3 URL directly:

https://bucket.s3.amazonaws.com/media/resume/Vicente_Reyes_Resume.pdf

The PDF downloaded. No token, no email, no gate.

What Went Wrong

Two settings in production.py:

AWS_QUERYSTRING_AUTH = False   # plain URLs, no signed query strings
AWS_DEFAULT_ACL = None         # objects inherit bucket ACL → public-read

resume.pdf.url was returning a permanent, unauthenticated S3 URL. The gate was checking ID at the front door while the back window was wide open.

The Fix: Per-Field Private Storage

Changing AWS_QUERYSTRING_AUTH globally would break every other media file — blog covers, project screenshots, testimonial avatars — all meant to be public. The right scope is narrower: only the resume field needs private storage.

django-storages supports this through custom storage classes. Pass a callable to FileField's storage parameter and Django calls it at runtime to get the storage instance.

# core/storages.py
from django.conf import settings
from django.core.files.storage import FileSystemStorage
from storages.backends.s3boto3 import S3Boto3Storage

def private_resume_storage():
    if getattr(settings, "AWS_STORAGE_BUCKET_NAME", None):
        return S3Boto3Storage(
            location="media",
            default_acl="private",
            querystring_auth=True,
            querystring_expire=120,   # presigned URL valid for 2 minutes
            custom_domain=None,       # presigned URLs need the real S3 endpoint
            file_overwrite=False,
        )
    return FileSystemStorage()

# models.py
class Resume(models.Model):
    pdf = models.FileField(upload_to="resume/", storage=private_resume_storage)

Now resume.pdf.url returns a presigned URL:

https://bucket.s3.amazonaws.com/media/resume/filename.pdf
  ?X-Amz-Algorithm=AWS4-HMAC-SHA256
  &X-Amz-Credential=...
  &X-Amz-Expires=120
  &X-Amz-Signature=...

Valid for 120 seconds. The direct URL without the signature returns a 403. Sharing the URL or bookmarking it is pointless.

Why `custom_domain=None`

The production config has AWS_S3_CUSTOM_DOMAIN set. Custom domains don't support AWS Signature v4 query parameters — the presigned URL would be malformed. Setting custom_domain=None on the private storage instance forces django-storages to use the real S3 endpoint for that field only.

The Migration Surprise

Switching the storage callable requires a migration even though no columns change. Django records the storage class in migration state, so changing it from default to a callable produces a ~ Alter field pdf on resume migration. It's a no-op at the database level but Django needs it for consistency.

Part 4 — Email-First, Not Token-First

The original frontend flow returned the token in the API response and called window.open(downloadUrl, '_blank') immediately. The PDF opened before the user even checked their email.

The problem: someone could submit any email address, get the immediate download in their browser, and the link would go to whoever owned that inbox. The email was a log entry, not a gate.

Switching to email-first fixes it. The token is built server-side, put in the email body, and never returned to the frontend:

# Before
return Response({"data": {"token": token}, ...})

# After
self._send_download_email(email, download_url, expires_minutes)
return Response({"data": None, "message": "Check your inbox...", ...})

The frontend modal now shows a confirmation state instead of opening a new tab:

{sent ? (
  <div className="text-center space-y-4">
    <CheckCircle size={48} className="text-neo-green" />
    <h2 className="text-2xl font-black uppercase">Check Your Inbox</h2>
    <p className="font-medium opacity-80">
      A download link has been sent to <span className="font-black">{email}</span>.
      It expires in <span className="font-black">15 minutes</span>.
    </p>
    <Button variant="dark" size="md" onClick={onClose} fullWidth>Done</Button>
  </div>
) : (
  // ... form
)}

Part 5 — The Sender Name

First real email came in showing Portfolio Backend V2 as the sender. Not ideal.

The display name in From: headers comes from DEFAULT_FROM_EMAIL. It was hardcoded in the settings default:

# Before
DEFAULT_FROM_EMAIL = env(
    "DJANGO_DEFAULT_FROM_EMAIL",
    default="Portfolio Backend V2 <noreply@vicentereyes.org>",
)

# After
DEFAULT_FROM_EMAIL = env(
    "DJANGO_DEFAULT_FROM_EMAIL",
    default="Vicente Reyes <noreply@vicentereyes.org>",
)

One-line fix. The env var takes precedence if set on the server, so updating the default in code is just the fallback.

The Full Stack at a Glance

Browser                     Django                       S3
  │                            │                          │
  │ POST /api/resume/           │                          │
  │   request-download/         │                          │
  │   { email }                 │                          │
  │ ─────────────────────────► │                          │
  │                            │ validate email            │
  │                            │ block disposable domains  │
  │                            │ log ResumeDownloadRequest │
  │                            │ TimestampSigner.sign()    │
  │                            │ build_absolute_uri()      │
  │                            │ send_mail() ──────────────────► inbox
  │ ◄───────────────────────── │                          │
  │   { message: "Check        │                          │
  │     your inbox" }          │                          │
  │                            │                          │
  │ [user clicks email link]   │                          │
  │                            │                          │
  │ GET /api/resume/download/  │                          │
  │   ?token=<signed>          │                          │
  │ ─────────────────────────► │                          │
  │                            │ verify token (15 min)     │
  │                            │ resume.pdf.url ──────────► presigned URL
  │                            │                          │   (120 sec)
  │ ◄───────────────────────── │                          │
  │   302 → presigned URL      │                          │
  │                            │                          │
  │ GET presigned URL ─────────────────────────────────► │
  │ ◄───────────────────────────────────────────────── PDF│

What I'd Do Differently

Rate-limit the POST endpoint. Right now someone can hammer POST /api/resume/request-download/ with valid emails and flood inboxes. A simple per-IP throttle class on the view would fix it.

Consider Celery for the email send. send_mail in the request/response cycle means the API response waits for the SMTP round trip. On Mailgun it's fast, but wrapping it in a task would make the response instant and give you retries for free.

The existing S3 object still needs its ACL changed manually. The private storage fix applies to new uploads. Vicente_Reyes_Resume.pdf was already uploaded as public. Re-uploading via admin or changing the object ACL in the AWS console closes that gap.

How I Added Live Charts to the Django Admin Without Installing a Single Package

Vicente G. Reyes — Thu, 28 May 2026 05:17:50 +0000

The Django admin is a powerful tool that most developers underuse. Out of the box it gives you a filterable, searchable table for every model — but it stops short of anything visual. If you want to see trends over time, you're staring at rows.

I recently added a PageVisit model to my portfolio backend to track which blog posts, projects, and services people actually read. After 73 visits in two days I realised most of them were bots — but that problem aside, I also wanted a fast way to see visit trends without leaving the admin. Here's how I wired up three Chart.js charts with no new Python dependencies.

The Setup

The PageVisit model records one row per visit:

class PageVisit(models.Model):
    PAGE_TYPE_CHOICES = [
        ("blog_post", "Blog Post"),
        ("project", "Project"),
        ("service", "Service"),
    ]
    DEVICE_TYPE_CHOICES = [
        ("desktop", "Desktop"),
        ("mobile", "Mobile"),
        ("tablet", "Tablet"),
        ("bot", "Bot"),
        ("unknown", "Unknown"),
    ]

    page_type = models.CharField(max_length=20, choices=PAGE_TYPE_CHOICES)
    object_id = models.PositiveIntegerField()
    ip_address = models.GenericIPAddressField(null=True, blank=True)
    timestamp = models.DateTimeField(default=timezone.now)
    browser = models.CharField(max_length=100, blank=True, default="")
    os = models.CharField(max_length=100, blank=True, default="")
    device_type = models.CharField(max_length=10, choices=DEVICE_TYPE_CHOICES, blank=True, default="")

The goal: a bar chart of daily visits, a doughnut of visits by page type, and a doughnut of visits by device — all rendered above the standard changelist table, with a 7d / 30d / 90d toggle on the bar chart.

Step 1 — Inject Chart Data via `changelist_view`

Django admin's ModelAdmin exposes a changelist_view method you can override to inject arbitrary context. The trick is to query your aggregates there and pass them as JSON so the template can hand them straight to Chart.js.

import json
from datetime import timedelta

from django.contrib import admin
from django.db.models import Count
from django.db.models.functions import TruncDate
from django.utils import timezone

from .models import PageVisit


@admin.register(PageVisit)
class PageVisitAdmin(admin.ModelAdmin):
    # ... list_display, list_filter, etc.

    def changelist_view(self, request, extra_context=None):
        try:
            period = int(request.GET.get("days", 30))
            if period not in (7, 30, 90):
                period = 30
        except (ValueError, TypeError):
            period = 30

        # Django admin's ChangeList rejects unknown query params and redirects.
        # Strip 'days' before super() sees it.
        if "days" in request.GET:
            params = request.GET.copy()
            params.pop("days")
            request.GET = params

        since = timezone.now() - timedelta(days=period - 1)

        daily = (
            PageVisit.objects.filter(timestamp__gte=since)
            .annotate(date=TruncDate("timestamp"))
            .values("date")
            .annotate(count=Count("id"))
            .order_by("date")
        )
        by_type = (
            PageVisit.objects.values("page_type")
            .annotate(count=Count("id"))
            .order_by("page_type")
        )
        by_device = (
            PageVisit.objects.values("device_type")
            .annotate(count=Count("id"))
            .order_by("device_type")
        )

        extra_context = extra_context or {}
        extra_context["chart_period"] = period
        extra_context["chart_daily_labels"] = json.dumps(
            [row["date"].strftime("%b %d") for row in daily]
        )
        extra_context["chart_daily_data"] = json.dumps(
            [row["count"] for row in daily]
        )
        extra_context["chart_type_labels"] = json.dumps(
            [row["page_type"] for row in by_type]
        )
        extra_context["chart_type_data"] = json.dumps(
            [row["count"] for row in by_type]
        )
        extra_context["chart_device_labels"] = json.dumps(
            [row["device_type"] for row in by_device]
        )
        extra_context["chart_device_data"] = json.dumps(
            [row["count"] for row in by_device]
        )

        return super().changelist_view(request, extra_context=extra_context)

One non-obvious gotcha: Django admin's ChangeList treats any unrecognised query parameter as an invalid filter and issues a redirect to strip it. If you pass ?days=7 directly to super().changelist_view(), Django silently redirects to the clean URL and your parameter disappears. The fix is to read days from request.GET first, then pop it so super() never sees it.

Step 2 — Override the Changelist Template

Django's template loading checks templates/admin/<app_label>/<model_name>/change_list.html before falling back to the built-in. Create that file and extend the default:

portfolio_backend_v2/
  templates/
    admin/
      analytics/
        pagevisit/
          change_list.html   ← this file

The template loads Chart.js from CDN, renders three chart boxes above {{ block.super }} (which outputs the normal table), and reads the injected context variables:

{% extends "admin/change_list.html" %}

{% block content %}
  <script src="https://cdn.jsdelivr.net/npm/chart.js@4.4.0/dist/chart.umd.min.js"></script>
  <style>
    .pv-charts {
      display: grid;
      grid-template-columns: 2fr 1fr 1fr;
      gap: 1.5rem;
      margin-bottom: 2rem;
      align-items: start;
    }
    /* ... */
  </style>

  <div class="pv-charts">
    <div class="pv-chart-box pv-chart-bar">
      <div class="pv-chart-box-header">
        <h3>Visits</h3>
        <div class="pv-period-toggle">
          <a href="?days=7"  class="{% if chart_period == 7  %}active{% endif %}">7d</a>
          <a href="?days=30" class="{% if chart_period == 30 %}active{% endif %}">30d</a>
          <a href="?days=90" class="{% if chart_period == 90 %}active{% endif %}">90d</a>
        </div>
      </div>
      <canvas id="pvDaily"></canvas>
    </div>
    <!-- doughnut boxes ... -->
  </div>

  {# djlint:off #}
  <script>
    (function() {
      new Chart(document.getElementById("pvDaily"), {
        type: "bar",
        data: {
          labels: {{ chart_daily_labels|safe }},
          datasets: [{
            data: {{ chart_daily_data|safe }},
            backgroundColor: "#417690",
            maxBarThickness: 48,
          }],
        },
        options: {
          maintainAspectRatio: false,
          scales: { y: { beginAtZero: true, ticks: { precision: 0 } } },
        },
      });
      // ... doughnuts
    })();
  </script>
  {# djlint:on #}

  {{ block.super }}
{% endblock content %}

Two things worth noting in the template:

{# djlint:off #} / {# djlint:on #} — djLint's formatter breaks Django template tags inside <script> blocks, splitting {{ variable|safe }} across multiple lines. Wrapping the script in these comments disables reformatting for that section.
maintainAspectRatio: false with an explicit CSS height on the canvas — without this, Chart.js stretches the canvas to fill its container and the bar chart looks enormous when there are only a few data points. Set height: 200px !important on the canvas element via CSS and maintainAspectRatio: false in the chart options.
maxBarThickness: 48 — caps bar width so early-stage data with just one or two bars doesn't produce a chart that looks like two rectangles filling the box.

The Result

The PageVisit changelist now shows:

A bar chart of daily visits for the selected period, with 7d / 30d / 90d toggle buttons in the top-right corner of the chart box
A doughnut chart of all-time visits broken down by page type (blog post / project / service)
A doughnut chart of all-time visits broken down by device (desktop / mobile / tablet / unknown)

Below the charts the standard Django admin table renders as normal — filters, search, pagination all work unchanged.

What It Didn't Require

No new Python packages. No admin theme swap. No JavaScript build step. The only external dependency is Chart.js loaded from jsDelivr, which is a single <script> tag.

Django's changelist_view override and template inheritance are enough. If you already have a working admin and a model worth charting, you can have this running in under an hour.

The Django Singleton Model: How to Manage Page Headers Without a CMS

Vicente G. Reyes — Wed, 27 May 2026 02:53:30 +0000

I've always wondered how to handle those single-record things in a CMS-driven site. You know what I mean — the home page hero, the blog page header, the pricing section banner. They're not a list. There's no "add another." There's exactly one of them, and a non-technical client or even your future self needs to be able to edit them from an admin panel without touching code.

For the longest time I either hardcoded the content and lived with the guilt, or reached for something heavyweight like Wagtail. But neither felt right for a lean Django + React setup.

The actual answer turned out to be embarrassingly simple: the singleton model pattern.

The Problem

Django models are designed to store collections of things. But some things aren't collections — they're configuration. A home page header isn't a list of headers. It's the header. One row. Forever.

If you leave it as a normal model, three bad things can happen:

Someone adds a second row in the admin and breaks the frontend.
You delete the only row and the API 404s until someone notices.
You have to write HomePageHeader.objects.first() everywhere and pray row 1 never becomes row 5.

The singleton pattern closes all three gaps.

The Implementation

The core trick lives in the model's save() method: force pk=1 before every write.

class HomePageHeader(models.Model):
    AVAILABILITY_CHOICES = [
        ("open_to_work", "Open to Work"),
        ("currently_booked", "Currently Booked"),
        ("freelance_only", "Freelance Only"),
    ]

    availability_status = models.CharField(
        max_length=20,
        choices=AVAILABILITY_CHOICES,
        default="open_to_work",
    )
    hero_image = models.ImageField(upload_to="hero/", blank=True, null=True)
    heading_line1 = models.CharField(max_length=100, default="BUILDING")
    heading_highlight = models.CharField(max_length=100, default="DIGITAL")
    heading_line2 = models.CharField(max_length=200, default="PRODUCTS THAT")
    heading_accent = models.CharField(max_length=100, default="SLAP.")
    subtitle = models.TextField(
        default="I'm Vicente Reyes. Freelance Full-Stack Developer, Shopify & WordPress Expert, & Musician.",
    )
    primary_button_label = models.CharField(max_length=100, default="View Projects")
    primary_button_url = models.CharField(max_length=200, default="#projects")
    secondary_button_label = models.CharField(max_length=100, default="Book a Call")
    secondary_button_url = models.URLField(
        default="https://calendly.com/vicentereyes/30min",
    )

    class Meta:
        verbose_name = "Home Page Header"
        verbose_name_plural = "Home Page Header"

    def __str__(self):
        return "Home Page Header"

    def save(self, *args, **kwargs):
        self.pk = 1
        super().save(*args, **kwargs)

That's the whole trick. By pinning self.pk = 1 before calling super().save(), Django will always INSERT OR REPLACE (or UPDATE) the same row. A second save never creates a second record — it just updates the first one.

The verbose_name_plural matching verbose_name is a small cosmetic touch: Django's admin sidebar normally pluralizes the label, so "Home Page Headers" would appear. Keeping both the same gives you "Home Page Header" in the sidebar — which correctly implies there's only one.

Locking Down the Admin

The model alone prevents duplicates at the database level, but the admin still shows an "Add" button. Lock it out explicitly:

@admin.register(HomePageHeader)
class HomePageHeaderAdmin(admin.ModelAdmin):
    list_display = ("availability_status", "heading_line1", "heading_highlight")

    def has_add_permission(self, request):
        return not HomePageHeader.objects.exists()

    def has_delete_permission(self, request, obj=None):
        return False

has_add_permission returns True only when the table is empty — meaning the first time the row is created, the "Add" button appears. Once it exists, the button disappears. has_delete_permission always returns False, making the row permanent from the admin's perspective.

The same pattern applies to every page header in the project:

@admin.register(BlogPageHeader)
class BlogPageHeaderAdmin(admin.ModelAdmin):
    list_display = ("badge_text", "heading_line1", "heading_highlight")

    def has_add_permission(self, request):
        return not BlogPageHeader.objects.exists()

    def has_delete_permission(self, request, obj=None):
        return False


@admin.register(ServicesPageHeader)
class ServicesPageHeaderAdmin(admin.ModelAdmin):
    list_display = ("heading", "subheading", "cta_heading")

    def has_add_permission(self, request):
        return not ServicesPageHeader.objects.exists()

    def has_delete_permission(self, request, obj=None):
        return False

Each page section gets its own model, its own admin class, and its own locked-down row.

The View

With the model and admin locked down, the view is a one-liner:

class HomePageHeaderView(APIView):
    def get(self, request):
        obj, _ = HomePageHeader.objects.get_or_create(pk=1)
        return Response(
            HomePageHeaderSerializer(obj, context={"request": request}).data,
        )

get_or_create(pk=1) is the runtime complement to the model-level pk=1 pin. If the row doesn't exist yet (fresh database, new environment), it creates one with all the field defaults. If it does exist, it returns it. The view never returns a 404 for a missing singleton — it self-heals.

The Serializer

Nothing special here, but the HomePageHeader has one field worth noting — availability_status uses Django choices, and the serializer surfaces both the raw value and the human-readable label:

class HomePageHeaderSerializer(serializers.ModelSerializer):
    availability_display = serializers.CharField(
        source="get_availability_status_display",
        read_only=True,
    )
    hero_image_url = serializers.SerializerMethodField()

    class Meta:
        model = HomePageHeader
        fields = [
            "availability_status",
            "availability_display",
            "hero_image_url",
            "heading_line1",
            "heading_highlight",
            "heading_line2",
            "heading_accent",
            "subtitle",
            "primary_button_label",
            "primary_button_url",
            "secondary_button_label",
            "secondary_button_url",
        ]

    def get_hero_image_url(self, obj):
        if not obj.hero_image:
            return None
        request = self.context.get("request")
        if request:
            return request.build_absolute_uri(obj.hero_image.url)
        return obj.hero_image.url

get_availability_status_display is a Django built-in that returns the human-readable choice label — so the frontend gets "Open to Work" rather than "open_to_work". The hero_image_url method builds an absolute URL so the React frontend gets a fully qualified image path regardless of where the API is hosted.

The Full Flow

The full stack for any singleton page header looks like this:

Model — fields with sensible defaults, save() pins pk=1
Migration — standard makemigrations / migrate
Admin — has_add_permission blocks duplicates, has_delete_permission blocks deletion
View — get_or_create(pk=1) for self-healing on fresh environments
Serializer — flat output, no nesting needed
Router — one URL, no {id} segment needed

The React side just does GET /api/home-header/ and maps the flat JSON to component props. No special handling, no conditional rendering for missing data.

When to Use This (and When Not To)

This pattern is ideal when:

The content is truly a one-of-a-kind configuration for a specific page or section
You want non-technical users to edit it from Django Admin
You don't want to pull in a full CMS dependency

Skip it when:

The content might ever need more than one instance (use a regular model)
You have dozens of these (consider django-solo, which packages this pattern as a reusable base class and adds caching)
The content changes rarely and has no images (environment variables or a settings dict is simpler)

Takeaway

The singleton model isn't exotic — it's just a model with one enforced row. Three lines of code in save() and two overrides in ModelAdmin are all it takes to turn a generic Django model into a safely editable, self-healing, single-record configuration object.

I spent way too long hardcoding hero text before I figured this out. Now every page section that needs admin-editable content but only ever has one instance gets this treatment by default.

How I Caught and Fixed an N+1 Query in My Django REST API

Vicente G. Reyes — Sat, 23 May 2026 11:51:01 +0000

Every performant API eventually runs into the same silent killer: the N+1 query problem. It doesn't crash your app. It doesn't throw errors. It just quietly makes every list endpoint slower as your data grows — and it's almost invisible until Sentry flags it in production.

Today, Sentry caught one on my /api/blog-posts/ endpoint. Here's exactly what happened and how I fixed it in three lines of code.

What Is an N+1 Query?

An N+1 query happens when your code fetches a list of N records, then fires an additional query per record to fetch related data — totalling 1 + N database hits instead of a flat 2 or 3.

In Django, this usually happens silently because the ORM is lazy by default. Accessing a related object on a model instance that wasn't eagerly loaded triggers a fresh SELECT on the spot. With 30 blog posts, that's 30 silent queries you never wrote.

The Offending Code

The BlogPostViewSet looked clean on the surface:

class BlogPostViewSet(viewsets.ReadOnlyModelViewSet):
    queryset = BlogPost.objects.all()
    serializer_class = BlogPostSerializer
    lookup_field = "uid"

And the serializer:

class BlogPostSerializer(serializers.ModelSerializer):
    tags = BlogTagSerializer(many=True, read_only=True)
    series = BlogSeriesSerializer(read_only=True)
    ...

Spot the problem? BlogPost has two relations:

series — a ForeignKey to BlogSeries
tags — a ManyToManyField to BlogTag

When DRF serializes a list of 30 posts, it accesses post.series and post.tags on each one. Without eager loading, Django fires two extra queries per post — one to fetch the series, one to fetch the tags. That's 1 + 60 queries for a 30-post list.

The featured action had the same issue:

@action(detail=False, methods=["get"])
def featured(self, request):
    queryset = BlogPost.objects.filter(date_published__isnull=False).order_by(
        "-date_published",
    )[:3]

A fresh BlogPost.objects call with no eager loading.

The Fix

Django gives me two tools for this:

select_related() — for ForeignKey and OneToOne relations. Issues a SQL JOIN and fetches everything in a single query.
prefetch_related() — for ManyToMany and reverse FK relations. Issues a second query and caches the results in Python.

The fix:

class BlogPostViewSet(viewsets.ReadOnlyModelViewSet):
    queryset = BlogPost.objects.select_related("series").prefetch_related("tags")
    serializer_class = BlogPostSerializer
    lookup_field = "uid"

    @action(detail=False, methods=["get"])
    def featured(self, request):
        queryset = (
            BlogPost.objects.select_related("series")
            .prefetch_related("tags")
            .filter(date_published__isnull=False)
            .order_by("-date_published")[:3]
        )
        serializer = self.get_serializer(queryset, many=True)
        return Response(serializer.data)

With 30 posts, the list endpoint now costs 3 queries regardless of dataset size:

SELECT * FROM core_blogpost ...
SELECT * FROM core_blogseries WHERE id IN (...)
SELECT * FROM core_blogtag INNER JOIN core_blogpost_tags WHERE blogpost_id IN (...)

The Bonus Fix

While auditing the blog endpoint, I spotted the same pattern in TestimonialViewSet. Its serializer accesses project.title and project.slug, but the queryset had no select_related:

# Before
queryset = Testimonial.objects.all()

# After
queryset = Testimonial.objects.select_related("project")

One extra line, one less N+1.

How to Spot This in Your Own Code

The pattern is always the same — look for any ViewSet or view where:

The queryset has no select_related or prefetch_related
The serializer accesses a related field (source="relation.field", nested serializers, SerializerMethodField that touches obj.relation)

Tools that help catch this before Sentry does:

django-debug-toolbar — shows query counts per request in the browser
nplusone — raises exceptions in tests when N+1 queries are detected
Sentry Performance — catches it in production with query traces

The best time to catch an N+1 is during code review. Any time you write a nested serializer, ask: does the queryset for this view eagerly load this relation?

Takeaway

The Django ORM's lazy evaluation is a feature, not a bug — but it requires discipline at the queryset layer. A clean-looking viewset with objects.all() is often hiding a query storm one serializer away.

The rule of thumb: every relation accessed in a serializer needs a corresponding select_related or prefetch_related on the queryset. Make it a checklist item on every PR that touches a ViewSet.

Post-Mortem: Why My Blog Cover Images Silently Failed to Restore from S3

Vicente G. Reyes — Fri, 22 May 2026 09:09:36 +0000

Six blog posts on my portfolio had broken cover images for longer than I'd like to admit. The images were in S3. The management command to restore them had been written and run. And yet — nothing. Blank covers, every time.

Here's the full breakdown of what went wrong, why, and how it got fixed.

The Setup

My portfolio backend is a Cookiecutter Django project running on a DigitalOcean droplet with Docker Compose. Blog post cover images are stored on AWS S3. The cover field on the BlogPost model is an ImageField that stores a relative path like blog_posts/deploy.webp — Django's S3 storage backend handles prepending the media/ prefix and building the full URL.

When I migrated away from using Hashnode as a headless CMS and imported all posts into my own Django backend, the cover images came along as CUID-based filenames (e.g. blog_posts/cmoxrumae00ms2em7bje5at07.png). Those CUIDs don't exist in S3 — the actual files were uploaded separately with descriptive names like deploy.webp, manual.webp, sortinghashnode.webp.

To fix this, Gemini wrote restore_covers.py, a management command with two matching strategies:

Exact CUID match — looks for blog_posts/{cuid}.webp etc. in S3
Fuzzy slug match — tokenizes the post slug and looks for S3 filenames with overlapping keywords

The command was run. Six posts still had broken covers.

Root Cause 1: The Fuzzy Matcher Couldn't Tokenize Concatenated Filenames

The S3 filenames are lowercase concatenated words: sortinghashnode.webp, trackingpage.webp, postmortem.webp. The fuzzy matcher works by calling get_keywords() on both the post slug and each S3 filename, then computing the set intersection.

Here's the problem. get_keywords() uses re.findall(r"[a-zA-Z0-9]+", text) to tokenize. Applied to a filename:

get_keywords("sortinghashnode.webp")
# → {"sortinghashnode"}   ← one token

And for the post slug:

get_keywords("sorting-hashnode-series-posts-how-to-display-the-latest-post-first")
# → {"sorting", "hashnode", "series", "posts", "display", "latest", "first"}

The intersection of {"sortinghashnode"} and {"sorting", "hashnode", ...} is empty. Score = 0. No match.

The same failure applied to every concatenated filename in the bucket. trackingpage.webp couldn't match a slug containing tracking and page. postmortem.webp couldn't match a slug containing mortem (since post is a stop word). None of them scored above 0.

The fix was to replace the plain set intersection with substring containment, enforcing a minimum token length of 4 characters to prevent false positives from short words:

min_token_len = 4
overlap = set()
for pk in post_keywords:
    for fk in file_keywords:
        if pk == fk or (
            len(pk) >= min_token_len
            and len(fk) >= min_token_len
            and (pk in fk or fk in pk)
        ):
            overlap.add(pk)

Now "sorting" in "sortinghashnode" → True, score += 1. "hashnode" in "sortinghashnode" → True, score += 1. The correct file gets matched.

Root Cause 2: No AWS Credentials in the Local Environment

The second reason the command silently failed: it was run via docker compose -f docker-compose.local.yml, which loads .envs/.local/.django. That file has no AWS credentials.

When storage.listdir("blog_posts") is called with no S3 credentials, it either errors out silently (caught by a bare except Exception) or returns an empty list because the local filesystem storage backend is active instead of S3. The command's output showed:

Could not list storage directory directly: ...
Fuzzy matching won't be available.

But the overall command still exited 0 with a summary that made it look like it ran fine. With zero files in storage_files, the fuzzy loop had nothing to iterate over — so every post hit the "no existing file found in storage" branch.

The management command is designed to run in the production container, where .envs/.production/.django already has the correct AWS credentials wired up.

Root Cause 3: One Image Was Never Uploaded to S3

Even with both fixes above, the post "How I Fixed the Hashnode GraphQL API Stale Cache Bug (Stellate CDN)" would still have a broken cover — because no matching file exists in S3 at all. The DB had blog_posts/cmlyqj0cc006627lvguola3gg.png and no file with a descriptive name was ever uploaded for it.

This one requires a manual upload via Django admin.

The Fix

For the five posts with known S3 matches, I wrote a Django data migration that directly sets the correct cover paths:

COVER_FIXES = {
    "how-to-manually-backup-wordpress-sites-via-ssh": "blog_posts/manual.webp",
    "deploying-cookiecutter-django-on-a-digitalocean-droplet-ubuntu-24-04-lts": "blog_posts/deploy.webp",
    "post-mortem-the-march-2026-axios-supply-chain-attack": "blog_posts/postmortem.webp",
    "sorting-hashnode-series-posts-how-to-display-the-latest-post-first": "blog_posts/sortinghashnode.webp",
    "tracking-page-views-in-a-react-spa-with-google-analytics-4": "blog_posts/trackingpage.webp",
}

def fix_covers(apps, schema_editor):
    BlogPost = apps.get_model("blogs", "BlogPost")
    for slug, cover_path in COVER_FIXES.items():
        BlogPost.objects.filter(slug=slug).update(cover=cover_path)

This runs automatically on python manage.py migrate during the next production deploy — no manual SSH step needed.

For the fuzzy matcher, the substring containment fix was patched into restore_covers.py so future runs work correctly for any similarly named files.

For the sixth post, a manual image upload to Django admin is the remaining action item.

What I'd Do Differently

The real issue is that the restore command's failure mode was too quiet. It logged "fuzzy matching won't be available" but still printed a clean summary with zeroes in the "could not restore" column for cases where the file list was empty. That made it look successful.

A better design: if storage.listdir() fails entirely, the command should exit early with a non-zero code rather than continuing with no files to match against. Silently succeeding at nothing is worse than loudly failing at something.

The slug-to-filename mismatch was also a predictable problem from the start. The files were uploaded manually with short descriptive names, but the DB records came from Hashnode with long CUIDs. A mapping file (even a simple JSON dict of slug → filename) would have made the restore command deterministic instead of relying on fuzzy heuristics.

When's the DEV shop coming back? I need to buy stuff before the end of June!

Vicente G. Reyes — Thu, 14 May 2026 06:19:27 +0000

Deploying Cookiecutter Django on DigitalOcean (Ubuntu 24.04 (LTS) x64)

Vicente G. Reyes — Sat, 09 May 2026 03:16:05 +0000

A no-fluff deployment runbook for getting a Cookiecutter Django project live on DigitalOcean using Docker and Traefik. Covers the full path from droplet provisioning to a working production deployment with SSL, plus the gotchas I keep hitting.

Pre-flight Checklist

Before touching the droplet, confirm:

Cookiecutter Django project generated locally with production = Docker, Traefik (or Nginx), Postgres, and your email backend of choice (Mailgun, SendGrid, Anymail, etc.)
Project pushed to a private GitHub repo
Domain registered with DNS access
DigitalOcean account ready
Local SSH keypair (~/.ssh/id_ed25519) ready
All .envs/.production/* files prepared locally (these are git-ignored and must be transferred separately)

Required env files:

.envs/.production/.django
.envs/.production/.postgres

Generate strong values for DJANGO_SECRET_KEY, DJANGO_ADMIN_URL, POSTGRES_PASSWORD, etc:

python -c "import secrets; print(secrets.token_urlsafe(64))"

1. Spin Up the Droplet

Image: Ubuntu 24.04 (LTS) x64
Plan: Basic — minimum 2 GB RAM / 1 vCPU. Postgres + Django + Traefik + Redis on 1 GB will OOM during builds.
Auth: SSH key (paste your ~/.ssh/id_ed25519.pub)
Region: Closest to your users
Hostname: something descriptive (e.g. myapp-prod-sg1)

Note the public IPv4 once it's provisioned.

2. DNS Records

In your domain registrar (or DigitalOcean DNS):

Type	Name	Value	TTL
A	@	`<droplet_ip>`	3600
A	www	`<droplet_ip>`	3600

Traefik will provision Let's Encrypt SSL automatically once DNS resolves and ports 80/443 are open. Wait for DNS to propagate before bringing up the stack — otherwise Let's Encrypt will rate-limit you on failed challenges.

dig yourdomain.com +short

3. Initial Server Hardening

Connect as root

ssh root@<droplet_ip>

Update packages

apt update && apt upgrade -y

Create a non-root user

Replace <username> with your chosen username throughout this guide.

adduser <username>
usermod -aG sudo <username>

Mirror SSH keys to the new user

rsync --archive --chown=<username>:<username> ~/.ssh /home/<username>

Configure UFW

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Port 80 needs to be open (not just 443) because Traefik uses it for the Let's Encrypt HTTP-01 challenge and to redirect HTTP traffic to HTTPS.

Reconnect as the new user

exit
ssh <username>@<droplet_ip>

Lock down SSH

sudo nano /etc/ssh/sshd_config

Set:

PermitRootLogin no
PasswordAuthentication no

Reload SSH (no full reboot needed):

sudo systemctl reload ssh

Test from a new terminal before closing the current session — if you locked yourself out, the live session is your only way back in.

4. Install Docker & Compose Plugin

# Remove any old versions
sudo apt remove -y docker docker-engine docker.io containerd runc

# Install dependencies
sudo apt install -y ca-certificates curl gnupg lsb-release

# Add Docker's GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repo
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Allow your user to run docker without sudo
sudo usermod -aG docker $USER
newgrp docker

# Verify
docker --version
docker compose version

5. Set Up GitHub Deploy Key

Since the repo is private, the droplet needs SSH access to clone and pull.

ssh-keygen -t ed25519 -C "<username>@yourdomain.com"
# Press enter through prompts (no passphrase, default location)
cat ~/.ssh/id_ed25519.pub

Copy the output and add it as a deploy key on the GitHub repo:

Settings → Deploy keys → Add deploy key

Read-only access is fine unless you're pushing from the server.

Test the connection:

ssh -T git@github.com

6. Clone the Project

cd ~
git clone git@github.com:<your-username>/<your-repo>.git
cd <your-repo>

7. Transfer Production Env Files

The .envs/.production/ folder is git-ignored, so SCP it from local:

From your local machine:

scp -r .envs/.production <username>@<droplet_ip>:~/<your-repo>/.envs/

Verify on the droplet:

ls -la ~/<your-repo>/.envs/.production/
# Should show .django and .postgres

Lock down permissions:

chmod 600 ~/<your-repo>/.envs/.production/.django
chmod 600 ~/<your-repo>/.envs/.production/.postgres

8. Configure Production Domain

Update `.envs/.production/.django`

nano .envs/.production/.django

Critical variables:

DJANGO_ALLOWED_HOSTS=yourdomain.com,www.yourdomain.com
DJANGO_SECURE_SSL_REDIRECT=True
DJANGO_SERVER_EMAIL=noreply@yourdomain.com
DJANGO_DEFAULT_FROM_EMAIL=hello@yourdomain.com
MAILGUN_API_KEY=<key>
MAILGUN_DOMAIN=mg.yourdomain.com

Update `compose/production/traefik/traefik.yml`

nano compose/production/traefik/traefik.yml

Replace every instance of the placeholder domain with yours. Look for:

- "Host(`example.com`) || Host(`www.example.com`)"

And the Let's Encrypt email:

email: "your_real_email@yourdomain.com"

Use a real, monitored email — Let's Encrypt sends expiry warnings here.

9. Build and Launch

docker compose -f docker-compose.production.yml up --build -d

First build takes 5–10 minutes. Watch logs:

docker compose -f docker-compose.production.yml logs -f

What to look for:

traefik should successfully obtain Let's Encrypt cert (search logs for certificate obtained)
django should boot without import errors
postgres should be ready and accepting connections

Common first-run failures:

Cert acquisition fails → DNS hasn't propagated yet, or port 80 is blocked
Django can't connect to DB → .envs/.production/.postgres mismatch
502 from Traefik → Django container crashed, check logs django

10. Run Migrations & Create Superuser

# Migrations
docker compose -f docker-compose.production.yml run --rm django python manage.py migrate

# Superuser
docker compose -f docker-compose.production.yml run --rm django python manage.py createsuperuser

# Collect static (usually handled at build time, but run if needed)
docker compose -f docker-compose.production.yml run --rm django python manage.py collectstatic --noinput

Never run makemigrations on the server. Generate migrations locally, commit them, pull on the server, then migrate.

11. Update the Sites Framework

Cookiecutter Django uses Django's Sites framework (especially for django-allauth email links). Update the default site:

docker compose -f docker-compose.production.yml run --rm django python manage.py shell

from django.contrib.sites.models import Site
site = Site.objects.get(pk=1)
site.domain = "yourdomain.com"
site.name = "Your App"
site.save()
exit()

12. Smoke Test

https://yourdomain.com loads with valid SSL (no warnings)
https://yourdomain.com/<DJANGO_ADMIN_URL>/ → admin login works
Sign up flow → confirmation email arrives
Password reset email arrives
Static files serving (CSS/JS load, no 404s in DevTools)
http://yourdomain.com redirects to https://

13. Updating Deployments

For subsequent deploys:

cd ~/<your-repo>
git pull
docker compose -f docker-compose.production.yml up --build -d
docker compose -f docker-compose.production.yml run --rm django python manage.py migrate

If you changed env vars, restart the django service:

docker compose -f docker-compose.production.yml restart django

14. Backups

Cookiecutter Django ships with a backup command for Postgres:

# Create backup
docker compose -f docker-compose.production.yml exec postgres backup

# List backups
docker compose -f docker-compose.production.yml exec postgres backups

# Restore (replace with actual backup filename)
docker compose -f docker-compose.production.yml exec postgres restore backup_2026_05_09T00_00_00.sql.gz

Add a cron job for daily backups + offsite sync to S3 / DO Spaces:

crontab -e

0 3 * * * cd /home/<username>/<your-repo> && docker compose -f docker-compose.production.yml exec -T postgres backup >> /home/<username>/backup.log 2>&1

15. Troubleshooting Cheatsheet

Symptom	Likely Cause	Fix
500 on signup/login	Email backend misconfigured	Check Mailgun/SendGrid keys in `.envs/.production/.django`
502 Bad Gateway	Django container down	`docker compose ... logs django`
SSL cert not issued	DNS not propagated, port 80 blocked, or Let's Encrypt rate limit	Wait, check `ufw status`, check Traefik logs
Static files 404	`collectstatic` not run, or whitenoise misconfigured	Re-run collectstatic, check `STATIC_ROOT`
`ALLOWED_HOSTS` error	Domain missing from env	Add to `DJANGO_ALLOWED_HOSTS`, restart django
OOM during build	Droplet too small	Resize to 2GB+ or build images locally and push to registry
`permission denied` on docker socket	User not in docker group	`sudo usermod -aG docker $USER && newgrp docker`

16. Next Steps (Optional Hardening)

CI/CD: GitHub Actions workflow → SSH into droplet → git pull && docker compose up --build -d. Use repo secrets for the SSH key.
Monitoring: Sentry (already wired in Cookiecutter Django) + Uptime Robot for external checks.
Logs: Ship to a service (Logtail, Papertrail, Datadog) instead of relying on docker logs.
Secrets management: Move from .env files to Doppler, Infisical, or DO's encrypted env vars for team workflows.
Database: Move Postgres off the droplet to DO Managed Postgres once you have real traffic. Update DATABASE_URL and you're done.
CDN: Serve static/media from DO Spaces + a CDN edge.

Wrapping Up

Your Django app should now be live behind HTTPS, with auto-renewing SSL, a hardened server, and a clear path for future deploys and backups. From here, the obvious next investments are CI/CD, observability, and moving your database to a managed service once traffic justifies it.

Automating Cloudflare WARP Based on WiFi SSID (Linux Guide)

Vicente G. Reyes — Wed, 06 May 2026 05:53:26 +0000

If you frequently switch between trusted and untrusted networks, manually toggling your VPN becomes tedious fast.

This guide shows how to automatically connect or disconnect Cloudflare WARP based on your WiFi network name (SSID) using NetworkManager on Linux.

🧠 Why This Matters

Not all networks are equal:

🏠 Trusted WiFi (Home) → You may not need WARP
☕ Public WiFi → You definitely want WARP
🏢 Office networks → Might conflict with VPN routing

Instead of manually toggling WARP every time, we can hook into network state changes and automate it.

⚙️ How It Works

Linux systems using NetworkManager support dispatcher scripts—these are triggered automatically when network events occur (e.g., connecting to WiFi).

We leverage this to:

Detect the current SSID
Apply conditional logic
Toggle WARP via CLI

🔧 Step-by-Step Implementation

1. Ensure WARP CLI is Installed

Make sure warp-cli is available. Then register and test:

warp-cli register
warp-cli connect
warp-cli status

2. Create a NetworkManager Dispatcher Script

Dispatcher scripts live here:

/etc/NetworkManager/dispatcher.d/

Create a new script:

sudo nano /etc/NetworkManager/dispatcher.d/99-warp-toggle

3. Add Logic Based on SSID

#!/bin/bash

INTERFACE="$1"
STATUS="$2"

# Trigger only when a connection is established
if [ "$STATUS" = "up" ]; then
    SSID=$(iwgetid -r)

    if [ "$SSID" = "home_wifi" ]; then
        echo "Connecting WARP for $SSID"
        warp-cli connect

    elif [ "$SSID" = "office_wifi" ]; then
        echo "Disconnecting WARP for $SSID"
        warp-cli disconnect

    else
        echo "Unknown network: $SSID — no action taken"
    fi
fi

4. Make the Script Executable

sudo chmod +x /etc/NetworkManager/dispatcher.d/99-warp-toggle

5. Apply Changes

Restart NetworkManager:

sudo systemctl restart NetworkManager

Or simply reconnect your WiFi.

🧪 Testing

Switch between your networks:

Connect to home_wifi → WARP should connect
Connect to office_wifi → WARP should disconnect

Verify with:

warp-cli status

⚠️ Things to Watch Out For

Requires iwgetid (usually part of wireless-tools)
Dispatcher scripts run as root
Some networks may block WARP traffic
Avoid rapid toggling (WARP CLI is tolerant, but don’t spam it)

🧩 Optional Enhancements

🔹 Add Logging

echo "$(date): Connected to $SSID" >> /var/log/warp-toggle.log

🔹 Use a case Statement (Cleaner Scaling)

case "$SSID" in
  "home_wifi")
    warp-cli connect
    ;;
  "office_wifi")
    warp-cli disconnect
    ;;
  *)
    echo "No rule for $SSID"
    ;;
esac

🔹 Default Behavior Strategy

You can invert the logic:

Always connect WARP by default
Explicitly disable only on trusted networks

💡 Final Thoughts

This approach is:

⚡ Event-driven — no polling loops
🪶 Lightweight — no extra services
🔌 Extensible — plug in more automations

You’re essentially turning your machine into a context-aware system—reacting intelligently to its environment.

Once you get comfortable with dispatcher scripts, you can extend this pattern to:

Auto-sync files on trusted networks
Trigger backups only at home
Change DNS / proxies dynamically

Happy hacking 🚀

I vibe coded a Design System! See it here! https://ice-design-system.vicentereyes.org See the landing page here https://ds.vicentereyes.org

Vicente G. Reyes — Tue, 05 May 2026 11:25:27 +0000

ice-design-system.vicentereyes.org

ice-ds — Neobrutalist React Component Library

A neobrutalist React component library with hard shadows, bold colors, and accessible primitives. 30+ components. MIT licensed. TypeScript-first.

ds.vicentereyes.org

DEV Community: Vicente G. Reyes

How I Shaved 10 MB Off My Portfolio in One Command

The Problem With PNGs in a Portfolio

The One-Time Backlog Fix: A Management Command

The Pillow mode handling is worth noting

Running it

The Permanent Fix: Auto-Convert on Upload

The Result

What I'd Do Differently

Building an RSS Feed for a Django + React Portfolio (With a Styled Browser View)

The Setup

The Django Feed

Why My Analytics Was Logging Every Page Visit Twice (And How I Fixed It)

The Setup

The Symptom

First Suspect: React StrictMode

The Real Cause: A Full Remount, Not a Preserved One

The Fix: Move Deduplication Outside React

Component Code Stays Clean

Takeaway

Building a Resume Download Gate: Email Collection, Signed Tokens, and an S3 Lesson

The Feature

Part 1 — The Model and the Gate

The Resume Model

Blocking Disposable Emails

Part 2 — django.core.signing.TimestampSigner

The Two API Views

Part 3 — The S3 Bypass

What Went Wrong

The Fix: Per-Field Private Storage

Why custom_domain=None

The Migration Surprise

Part 4 — Email-First, Not Token-First

Part 5 — The Sender Name

The Full Stack at a Glance

What I'd Do Differently

How I Added Live Charts to the Django Admin Without Installing a Single Package

The Setup

Step 1 — Inject Chart Data via changelist_view

Step 2 — Override the Changelist Template

The Result

What It Didn't Require

The Django Singleton Model: How to Manage Page Headers Without a CMS

The Problem

The Implementation

Locking Down the Admin

The View

The Serializer

The Full Flow

When to Use This (and When Not To)

Takeaway

How I Caught and Fixed an N+1 Query in My Django REST API

What Is an N+1 Query?

The Offending Code

The Fix

The Bonus Fix

How to Spot This in Your Own Code

Takeaway

Post-Mortem: Why My Blog Cover Images Silently Failed to Restore from S3

The Setup

Root Cause 1: The Fuzzy Matcher Couldn't Tokenize Concatenated Filenames

Root Cause 2: No AWS Credentials in the Local Environment

Root Cause 3: One Image Was Never Uploaded to S3

The Fix

What I'd Do Differently

When's the DEV shop coming back? I need to buy stuff before the end of June!

Deploying Cookiecutter Django on DigitalOcean (Ubuntu 24.04 (LTS) x64)

Pre-flight Checklist

1. Spin Up the Droplet

2. DNS Records

3. Initial Server Hardening

Connect as root

Update packages

Create a non-root user

Mirror SSH keys to the new user

Configure UFW

Reconnect as the new user

Lock down SSH

4. Install Docker & Compose Plugin

5. Set Up GitHub Deploy Key

Part 2 — `django.core.signing.TimestampSigner`

Why `custom_domain=None`

Step 1 — Inject Chart Data via `changelist_view`

Update `.envs/.production/.django`

Update `compose/production/traefik/traefik.yml`