Forem: Nathan

A Totally Legitimate Way to Look More Productive on GitHub

Nathan — Fri, 17 Apr 2026 06:38:44 +0000

Yes, I have a repo whose sole purpose is to make my GitHub profile look busier than it is. No, I'm not ashamed. And here's how you can do it too.

It's quite easy to spot when I started it.

How It Works

Github's contribution graph tracks commits across all your repos, public and private, as long as they're on the default branch and the commit email matches your account. The whole system is activity-based: it doesn't care what you committed, just that you did. Which means it's trivially gameable.

The plan is simple: a private repo, a scheduled GitHub Action as the engine, and a Python script to make it look human.

GitHub Workflow

With a free GitHub Account, you have access to 2,000 minutes of free actions compute every month, so let's use that to run a 25s action.
A GitHub Workflow also allows you to define cron jobs, so we can simply define one to run every day.

Create a file at .github/workflows/contributor.yml:

First, define the trigger with a cron job:

on:
  schedule:
    # Runs at 08:00 UTC every day
    - cron: '0 8 * * *'

Define the job and give it permission to push commits:

jobs:
  daily-commits:
    runs-on: ubuntu-latest
    permissions:
      contents: write # Grants permission to push commits

Add the steps. First, checkout the repo:

steps:
  - name: Checkout repository
    uses: actions/checkout@v3

Set up Python and install dependencies:

- name: Set up Python
  uses: actions/setup-python@v4
  with:
    python-version: '3.9'

- name: Install dependencies
  run: pip install holidays

Configure git. Make sure to use the same email address as your GitHub account, else contributions will not be counted:

- name: Configure Git
  run: |
    git config --global user.name "Nathan Brodin"
    git config --global user.email "nathan@brodin.dev"

Run the auto-commit script:

- name: Run Auto-Commit Script
  run: python autocommit.py

Finally, push changes:

- name: Push changes
  run: git push

A Tiny Script To Make It Look Realistic

If you would make the exact same amount of commits, monday to sunday, even on Christmas day, you would easily be flagged as a faker. So to make it look natural, we'll write a tiny Python script to handle that. Create a file called autocommit.py:

First, add the imports:

import random
import subprocess
import datetime
import holidays

Define the git_commit function (must come before main()):

def git_commit(timestamp):
    with open("activity_log.txt", "a") as f:
        f.write(f"Commit made at {timestamp}\n")

    subprocess.run(["git", "add", "activity_log.txt"])

    message = f"Update activity log: {timestamp}"
    subprocess.run(["git", "commit", "-m", message])

Create the main() function. First, get today's date and check for weekends:

def main():
    today = datetime.date.today()

    if today.weekday() >= 5:
        print("Today is a weekend. Skipping.")
        return

You also skip public holidays, using the holidays package:

    country_code = "NO"  # Replace with your country code
    country_holidays = holidays.country_holidays(country_code)
    if today in country_holidays:
        print(f"Today is a holiday ({country_holidays.get(today)}). Skipping.")
        return

Remove days where you shouldn't be working (birthday, grandma's funeral...):

    quiet_days = {
        datetime.date(2026, 1, 1),
    }
    if today in quiet_days:
        print("Today is a quiet day. Skipping.")
        return

Randomize the count of commits, and weight them to make it more natural. Make sure the sum sums up to 100.

    # Randomize Commits: 0 commits has a 32% chance, max capped at 9
    num_commits = random.choices(
        range(10),
        weights=[32, 10, 8, 8, 8, 7, 8, 8, 6, 5],
        k=1
    )[0]
    print(f"Scheduled for {num_commits} commits today.")

Finally, call the commit function in a loop:

    for i in range(num_commits):
        current_time = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        git_commit(current_time)


if __name__ == "__main__":
    main()

Good job, You're now officially a 10x engineer (with a healthy work/life balance), at least visually.

Full code:

# .github/workflows/contributor.yml

name: Daily Contribution Automation

on:
  schedule:
    # Runs at 08:00 UTC every day
    - cron: '0 8 * * *'
  # Allows to run this workflow manually from the Actions tab for testing
  workflow_dispatch:

jobs:
  daily-commits:
    runs-on: ubuntu-latest
    permissions:
      contents: write # Grants permission to push commits

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.9'

      - name: Install dependencies
        run: pip install holidays

      - name: Configure Git
        run: |
          git config --global user.name "Nathan Brodin"
          git config --global user.email "nathan@brodin.dev"

      - name: Run Auto-Commit Script
        run: python autocommit.py

      - name: Push changes
        run: git push

# autocommit.py

import random
import subprocess
import datetime
import holidays

def git_commit(timestamp):
    with open("activity_log.txt", "a") as f:
        f.write(f"Commit made at {timestamp}\n")

    subprocess.run(["git", "add", "activity_log.txt"])

    message = f"Update activity log: {timestamp}"
    subprocess.run(["git", "commit", "-m", message])

def main():
    country_code = "NO"
    today = datetime.date.today()

    # Weekend Check
    if today.weekday() >= 5:
        print("Today is a weekend. Skipping.")
        return

    # Holiday Check
    country_holidays = holidays.country_holidays(country_code)
    if today in country_holidays:
        print(f"Today is a holiday ({country_holidays.get(today)}). Skipping.")
        return

    # Quiet Days Check
    quiet_days = {
        datetime.date(2026, 1, 1),
    }
    if today in quiet_days:
        print("Today is a quiet day. Skipping.")
        return

    # Randomize Commits — 0 commits has a 32% chance, max capped at 9
    num_commits = random.choices(
        range(10),
        weights=[32, 10, 8, 8, 8, 7, 8, 8, 6, 5],
        k=1
    )[0]
    print(f"Scheduled for {num_commits} commits today.")

    for i in range(num_commits):
        current_time = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        git_commit(current_time)
        print(f"Commit {i+1}/{num_commits} created.")

if __name__ == "__main__":
    main()

Between Tradition and Modernity: Building a Full Stack App with Django and React

Nathan — Mon, 13 Apr 2026 08:15:14 +0000

If I tell you I made a full-stack app with React 19 (+ Compiler), Tanstack Router, tailwindcss, Base UI, and pnpm, you would probably expect a Hono backend or Tanstack Start Server functions with Drizzle, or at least some cutting-edge TS solution. Well, I've built a Django backend, and it works pretty well!

The Constraints vs. The Freedom

When starting a new project, you always face constraints. Your job as the person designing the software architecture is to find the most elegant way to build around them.

Here are the constraints I was handed:

Django for the backend (to match the team's existing legacy projects).
Keycloak for authentication.
Dockerizing the entire stack for self-hosted deployment.

The freedom? I got to decide absolutely everything else.

If you’ve read my previous blog posts, you know I’ve fallen in love with the Tanstack ecosystem. I went with Tanstack Router, Query, Form, Table, and Pacer. Notice that I didn't go with Tanstack Start. Given the actual goals of this app, I couldn't justify the SSR overhead, and I absolutely did not want to spend a single second fixing hydration issues (I still have nightmares about them).

For the UI, I finally got to use TailwindCSS and shadcn/ui at work, freeing myself from plain CSS and the horrors of styled-components. I really love the pattern of creating headless, reusable components:

export function PageHeader({ className, children, ...props }: React.HTMLAttributes<HTMLElement>) {
  return (
    <header
      className={cn('grid auto-rows-min items-start gap-2', className)}
      data-slot="page-header"
      {...props}
    >
      {children}
    </header>
  )
}

(Yes, it kind of looks like styled-components in a way. Maybe time is a flat circle?)

A quick shoutout to two other bangers in the frontend stack:

Paraglide JS: After fighting with react-i18next (lack of type safety, fetching all keys client-side), I switched to Paraglide JS on Tanstack's recommendation. Zero downsides so far.
Knip: Analyzes your codebase for unused files, exports, and dependencies. Even with the strictest ESLint/Prettier setup, you’ll have dead code. Knip is a godsend for cleanup.

Bridging the Gap: The Auth Weirdness

Let's talk about the weird authentication layer in the app, that I am not a big fan of.

The client authenticates with Keycloak. This means I need to check auth on the frontend (using react-oidc-context and oidc-client-ts, which have pretty bad documentation) and store the auth context.

I then pass the key to the backend during API calls, where Django verifies it using jwt.decode against the public key. It doesn't sound that bad, except that Django has its own pre-built auth system with user tables, and Keycloak isn't designed to store app-specific user metadata. So, I had to build a weird, performant sync layer between the two (e.g., if a Keycloak email changes, reflecting it locally in the Postgres DB). It’s clunky, but it works.

Type Safety is still possible

I love type safety. Coming from TypeScript, and having played with C and Dart in school, dynamic typing gives me hives.

Out of the box, Python can feel a bit like the Wild West compared to a strict TypeScript setup. With standard dependencies often living in a simple .txt file and optional linting, it gives you a lot of freedom. But that freedom means you have to actively put in the work to enforce a strong Developer Experience, otherwise code quality can slip quickly.

However, having a Python backend and a TypeScript frontend doesn't mean you have to sacrifice end-to-end type safety. Here is how I forced the two to play nice:

Django properly defines the models with strict types and comments.
Backend views have full documentation on response types using those models.
drf-spectacular generates the OpenAPI specs.
Orval generates TS types and query hooks from those specs.
The frontend consumes the Tanstack Query Hooks to fetch data.

And just like that... End-to-end type safety. You know exactly what the endpoint needs, and exactly what it's going to return. When you make a change in a model, you get the feedback all the way to your frontend component.

DX: Making the Containers Bearable

After the users, my top priority is the developers (and code quality). Because of the strict constraints, I got to tear my hair out properly learning Docker. Setting up multiple services, ensuring they communicate, and managing deployment across two environments in a server full of existing apps was a massive headache.

But once it works, Docker is magic. Starting the project takes one command. You get fully reproducible environments between local dev and production. So now you can use the "But it works on my machine" excuse more confidently.

I also spent some time creating Make commands. These Docker commands are quite long and spending 5 minutes going up in the terminal history trying to find the specific command to run the tests can be quite annoying. So I wrote a Makefile. Now, a simple make codegen spins up the OpenAPI specs and frontend types:

COMPOSE_FILE := docker-compose.dev.yml
ENV_FILE     := .env.local
COMPOSE      := docker compose -f $(COMPOSE_FILE) --env-file $(ENV_FILE)

.PHONY: codegen
codegen: schema types ## Generate both Schema and Types

.PHONY: schema
schema: ## Generate Open API schema from Backend
    $(COMPOSE) exec backend python manage.py spectacular --file openapi.yml --validate

.PHONY: types
types: ## Generate TypeScript types from Open API schema
    $(COMPOSE) exec frontend pnpm run generate-types

I also built a strong CI pipeline. It handles backend linting and formatting, 800+ Django tests, migration checks, OpenAPI schema validation, Frontend Schema Types validation, frontend type checking, frontend build, and finally Playwright tests.

It sounds heavy, but it only takes ~7 minutes if all steps run, thanks to aggressive caching, sharding, and parallel jobs. If I only touch backend code, the pipeline finishes in 2 minutes. Stop the pipeline early, run only what changed. It’s worth the initial setup time.

Boring isn't bad

Django is not the most exciting tech, but it’s great for a CRUD app exposing APIs to Postgres. Yes, I still have to handle some complexity: RBAC, Redis caching, querying a Clickhouse DB with raw SQL, and WebSockets for live notifications, but I’m not building a crazy app for millions of users.

Django is simple, predictable, and LLMs understand it perfectly. Need a cache layer? Two lines of code. It’s fast enough that running 800+ tests (including DB writes) takes 10 seconds.
I still have some issues with it, like if there is an internal server error, an endpoint will return some html by default. So you need a custom middleware to formalize all kinds of errors. And of course, it has to be in Python. But overall: it just works.

The Silo Problem: Designing APIs in a Vacuum

Now, for a bit of a reality check regarding backend development.

In theory, backend engineers handle incredibly important tasks: complex business logic, rock-solid security, scaling, and database optimizations. This should put to shame frontend engineers like me who spend 2 hours changing the color of a button.

But in my early years of corporate experience, my reality has been quite different. I have only encountered codebases where basic software engineering practices, like mandatory PR reviews, automated testing, or even basic linting, just weren't part of the culture. When teams don't put effort into those foundations, you quickly end up with messy codebases, weak RBAC, major security oversights, and poor performance. More importantly, I’ve encountered the "Silo Problem."

It goes like this: the backend team designs their database models and endpoints in isolation, without involving the frontend or the designer. The result never maps to what the UI actually needs, data models that clash with the design system, endpoints structured in a way that require several workarounds on the client just to render a basic view, and OpenAPI specs handed down after the fact that rarely match the live responses. I've seen it more than once, and it never stops being painful.
If you are a backend developer adding a new endpoint, you aren't doing it for fun. You are doing it because the user interface needs that data. Designing APIs without consulting the client-side needs is like building a steering wheel without checking what kind of car it's going into.

Thankfully, on my current project, I am the frontend, backend, and DevOps engineer. Everything communicates nicely, because I actually talk to myself.

The Corporate Reality

I started this new grad job in mid-2025 at a small non-tech company, specifically because I wanted the freedom to build good products and actually care about software architecture.
And I did get that freedom. I spent hours refining small details, optimizing DX, and over-engineering the type safety.

But as the months go by, a weird realization has set in. This app will never scale to the hundreds of thousands of users I was used to handling in previous roles. Projects like this one are inherently temporary, business priorities shift, tools get replaced, and what matters today might be irrelevant in two years. The business goal is to ship a working solution, not to build a lasting technical marvel.

It's a strange feeling. You pour real craft into something and the honest answer is: it probably didn't need to be this good. But I think that's okay. The craftsmanship wasn't wasted: I learned a lot building it this way, and I'd rather over-engineer once and learn than ship something I'm not proud of.

And at the end of the day, I get to log off and live in one of the most beautiful places in the world. That counts for something.

"You Wouldn’t Steal a DIV": How I Built My Portfolio

Nathan — Thu, 12 Mar 2026 14:35:18 +0000

A story about how I built my portfolio and what went through my mind while building it

Hello, World! Here's my first ever blog.

I wanted to talk a bit about my portfolio, how I built it, why I made some of these architectural and design decisions, and why I shamelessly 'borrowed' my way to designs I love.

1 Stack, 2 Stack, Tech Stack, 4

(If you didn't read that header in Slim Shady's voice, I don't know what to tell you.)

First of all, let's talk tech stack. I used to have all of my personal projects (including my previous portfolio) built with Next.js. These were small side projects, without complicated logic, and with simple needs. Yet, I would always run into Next.js edge cases. Turbopack was failing my dev builds because it wouldn't play nice with Contentlayer, HMR was taking actual seconds to refresh, and production builds were taking 50 seconds for projects that barely scaled. When I got to choose a stack for a new project at my job, I couldn't justify the Next.js overhead for production apps, considering the friction I had with small personal projects.

At that time, everyone was talking about Tanstack Start: the "DX God." But even their starter app had linting and TS issues, so I wasn't fully impressed. I stuck with only Tanstack Router for that project, and as weeks passed by working with the entire Tanstack Ecosystem (except Start), I was really enjoying it. The documentation is well written and extensive (even too much sometimes), DX actually made sense, and I could find all of the features I liked about Next.js (file base routing for example) while still having great performance (15s builds).

So this led me to give a second chance to Tanstack Start, and I built this portfolio with it! I still love Vercel's UX, and wander around their dashboard to see how I should implement my stuff, but I think I'll leave Next.js behind for now. And personal projects are made to experiment with stuff. So I just want to try out different tech and see what I like or not, purely on feelings.

Then for the component library, I was really into coss ui. I stumbled upon it randomly one day and loved it so much. My Nathan's AI project already had a UI heavily inspired by cal.com: send button, message suggestions... So when I saw they had a shadcn/ui library with that kind of style, it was perfect for what I needed.

I can also consider myself a proud Open Source Contributor after getting two PRs merged into coss ui (a 2-line diff and I'm not even kidding, but quality over quantity, I guess...?).

Stealing...I Mean, Getting Inspired By Chanhdai and Zed

Now I'm not going to lie and say I designed and coded everything myself. I took large parts of the code and page layout from the open-source portfolio by Chanhdai and design inspiration from zed.dev, which I had previously attempted in unfinished side projects (https://trends.brodin.dev and https://ui.brodin.dev if they're still available).

I still went a different way than Chanhdai for the code implementation. For example, I chose to store my content in markdown files using Content Collections. I did this specifically so I could easily serve my portfolio's content in plain text, perfect for LLM consumption, which ties right back into the needs of my Nathan's AI project.
I also used Base-ui (because of coss ui) for components, and generally went with a different style. So this was not just a simple copy/paste or a fork, there was still a lot of work involved.

For Zed, I took the same fonts for the headings and text, and the grid layout with the "diamonds" at the intersections. It really adds personality to my portfolio (not my personality since I stole it, but some personality).

Also, by a great coincidence, Chanhdai had very basic sound design, like a sound when changing the theme, and I wanted to push things further by having different sounds around the entire app. I was looking around on the web for good sound libraries and all, but couldn't find anything interesting. Then the next day, I saw a tweet about the upcoming release of Soundcn, which was exactly what I was looking for. So now you get a bunch of sounds when clicking on stuff in my portfolio. It's a nice touch!

From good to WHOA

Lastly, the thing that elevated my portfolio from a good portfolio to a Whoa portfolio are the dither shaders (from Paper Shaders) that I have for page headings and section dividers. I had dither shaders in mind since the first day I saw them on React Bits, but couldn't find a good way to integrate them. So it ended up being a crossover between inspiration from the heading of zed.dev (open the dev console and see data-paper-shader on the headings) and Fumadocs, which had them as well.

To wrap things up

So in conclusion, I would say this portfolio is a cross between Chanhdai and Zed, with a better stack.

Go ahead, click around to hear the sound integration (it gets annoying after a while, be careful), check out the dither shaders on the headings, and check out the source code here if you want to steal from me like I did from everyone (but at least leave a star on the repo).

Blog Title reference: This classic: "You Wouldn't Steal a Car"
My Portfolio: brodin.dev
Initially posted on my blog