My data was scattered across apps, scripts, spreadsheets and notes. None of it was connected in any way. And most of it wasn't even owned by me, I couldn't export my habits data and query it myself.

Atlas - What I Built

I started small, just a simple habit tracker to see whether I did my flashcards and guitar practice.

Then one day I went for a run, got annoyed at Strava (again), and thought: why not just add runs to my own dashboard?

And that's how it went. Runs turned into workouts, books, movies, games, subscriptions. Everything lives in one system - one database, one API, multiple ways to interact with it.

What It Can Do

Right now, my system lets me:

• Track finances, subscriptions, and portfolio value
• Manage books, movies, and games with ratings and history
• Analyze runs and workouts
• Aggregate YouTube videos and articles
• Learn with flashcards
• Run small custom tools like timers

Everything is queryable and connected.

Alfred - My True Assistant

Once everything lives in one place, a different interface becomes possible.

I built a simple agent that can query my database and call API endpoints.

Instead of navigating UIs, I just ask:

• "What books did I read this year?"
• "What are my highest-rated movies?"
• "Add a flashcard for Informatieverwerkingssystemenbeheer (I love Dutch)"

This only works because the data is mine, structured, and accessible. It turns an LLM into a real assistant, just like Alfred from Batman.

Why Bother, It Seems Like a Lot of Work

You may be thinking: this must have taken a huge amount of time to build.

It didn't. Most of the functionality came together over a single weekend. AI makes this kind of thing actually feasible. If I had to carefully design and implement every part of this system by hand, I probably wouldn't even start.

But today I can spin up OpenCode, and in a matter of minutes end up with tools I'll use for years.

One day I decided I didn't want to use Anki anymore. Within an hour, I had all my data migrated into a system I fully control. It cost me about $1 in inference (thanks, QWEN) and now I can extend it however I want.

Under the hood, the stack is very simple:

• SQLite database
• Bun + Hono backend
• React frontend, CLI, Raycast
• Vercel's AI SDK for AI integration
• Hosted on a Raspberry Pi through Tailscale

That's another advantage. Because it's personal, you can keep it simple - you don't need insane kubernetes architecture or analytics.

Join Me

I strongly believe that personal software should be personal. A one-size-fits-all SaaS will never fit you as well as something you control. And the barrier to building it is lower than it's ever been.

Since this project is meant to be adjusted perfectly to you, I'm not sharing a codebase. Instead, I created a starting prompt that captures the idea and architecture.

Feel free to paste it into any coding agent you like — Lovable, v0, Claude Code, or any other. The output should give you a solid starting point for iterating.

Personal Backend Prompt - GitHub Gist

Build something that actually fits your life. And if you want to share it, I'd love to see it.

The Joy of Starting Something New

Starting a new project is always fun. You have an amazing idea (one that you still truly believe is amazing), you create some initial code, maybe a website, maybe just a README, and push it to GitHub. Then you spend a day or two adding features. But over time, it becomes less exciting. You face your first barriers, you realize how much work is required. And then a new idea comes along! You abandon the previous project entirely and are already pushing a new repo to GitHub, creating an infinite loop. Or, after a while, you just get bored by the amount of work needed to really polish a project and leave it unfinished.

The Brain Behind the Loop

There’s a reason starting projects feels amazing while finishing them feels… like a chore.

Dopamine Hits from Novelty

Our brains love dopamine, and novelty is one of its strong triggers. Each new idea or repo gives a small rush of satisfaction. We feel the immediate hit of accomplishment, even from the smallest things. That’s why first commits, first UI, or first working features feel so magical. But the excitement fades as the work becomes repetitive and requires persistence.

Perfectionism and Overwhelm

Completing a project often means polishing it, fixing all the edge cases, and writing documentation - the type of work that is boring and not immediately rewarding. Who will really notice that your app doesn’t break in some insanely rare edge case? Our brains prefer the creative spark over the grind, so perfectionism can make finishing feel impossible.

The Illusion of Progress

Even though your contributor graph shows you’re active, there’s a huge difference between activity and completion. This can lead to guilt or dissatisfaction because you did a lot, but there’s nothing tangible to show for it. That’s exactly how I felt, and it was the moment I decided to take actionable steps.

Slowing Down

I knew I had to focus on the most important things and push them to the very end, so I could feel a real sense of accomplishment, not just a momentary one that later leads to dissatisfaction. I decided to set strict rules for myself:

Only two ongoing projects

From now on, I will only work on two projects at a time. I find this number is a sweet spot: it gives flexibility while still limiting distraction. I will try my best to finish them. I’ve already caught myself thinking about new ideas, but instead of starting them and falling back into the loop, I add them to my development ideas list. Describing the idea in the note gives me a small dopamine hit, and then I return to my current work.

Archiving projects

Starting a new project doesn’t bind me to finishing it. Some projects turn out not to be worth it, they can require huge amounts of work with little return. That’s why I allow myself to abandon projects. But here’s the thing: abandoning now means never returning to them. Previously, I would leave projects unfinished, still thinking I might get back to them. Now, leaving a project means completely archiving the repository and letting it go. The power of archiving isn’t just practical, it frees mental space and stops the guilt loop.

Current Focus

Following these rules, I am now focusing on two projects. If you read this blog in the distant future, I hope you click on them and see polished, complete work:

• arcade - classic games in your terminal
• mini-lang - simple interpreter written in go

Join me!

If you’ve ever felt the same frustration, that sense of lack of accomplishment, consider this your sign. And remember: done doesn’t have to mean perfect - just 90% is enough to feel proud.

You learn more about the topics

A lot of the time, I write a blog post not to teach others, but to learn about the topic myself. When I want to understand something better, writing a post forces me to slow down, break things apart, and go deeper into the details.

If I just read about the topic I might skim it and move on. But when I know I'm going to explain it to others, I have to really understand what is it about. And another bonus: once you write about something, you remember it better, it sticks. Trying to explain an idea clearly to someone else, forces you to organize your thoughts, and that makes learning way more effective.

You learn how to express yourself

I’m not a native English speaker, so for me this one is huge. Writing blog posts has been an amazing way to practice putting my thoughts together in a way that’s clear and (hopefully) fun to read. Even if you are a native speaker, though, writing helps you sharpen that skill.

It's one thing to know something in your head, but it's another to explain it so someone else can understand it without confusion. That’s a skill a lot of people (especially software engineers) overlook, but being able to communicate your ideas well can set you apart.

You grow your presence and reputation

A great side effect is that putting your writing out there builds a presence. I like the idea of being part of a community, and blogging is one of the easiest ways to add to it. Your words stick around, and they can reach way more people than you’d expect.

In my opinion, creating new stuff feels really rewarding. There’s the excitement of knowing someone might stumble across your post through a Google search or recommendation. It’s a great feeling to know you’ve helped someone or taught them something new.

It can also even help professionally. Think about it: if you’re a recruiter choosing between two candidates with the same technical skills, and one of them has a blog full of engaging posts, wouldn’t you lean toward the one who clearly loves what they do? It shows passion, consistency, and a willingness to share knowledge.

That said, don’t fall into the “content trap”. It’s tempting to think more is better, but blasting out AI-generated slop won’t do you any favors. Authenticity matters. It’s better to publish fewer posts that genuinely reflect your thoughts and experiences.

So, how to start?

If you’re a developer, I’d definitely recommend building your own blog. Otherwise there are countless tools that make it ridiculously easy to get started: WordPress, Ghost, Medium, Substack, heck, even LinkedIn posts can count as blogging.

Keep a running list of blog ideas, topics you want to learn about or knowledge you want to share. Whenever an idea comes, just add it to the note. And whenever you find some free time… just write!

It doesn’t need to be perfect, polished, or even particularly good at first. You’ll learn, you’ll practice, and you’ll slowly get better without even noticing.

And a year from now, you might scroll back to your very first post, cringe a little, and then smile at how far you’ve come. That’s the journey, and blogging lets you see it in real time.

Most people see two massive hurdles: learning vim motions and setting everything up from scratch. Fair enough - they're real barriers. But once you get past them, they become the very reasons you'll never want to leave.

Moving like you think

Remember when you first tried vim and thought "who the hell designed this?" HJKL for navigation, no mouse, everything feels backwards. I definitely had that moment. Spent weeks feeling like I was coding with oven mitts on.

But then something clicked. The editing commands started making sense - d for delete, c for change, y for yank. Your fingers start remembering patterns. ci" to change inside quotes, dap to delete around a paragraph. It stops being about memorizing commands and becomes about expressing what you want to do.

The speed thing everyone talks about? Honestly, that's not the point. It's more about staying in flow. When you can edit text as fast as you think about it, you don't get pulled out of your train of thought by clunky interactions.

Building your own lightsaber

Here's where Neovim gets interesting - it ships as basically a text editor with potential. No fancy autocomplete, no git integration, no file tree. Just raw editing power waiting for you to shape it.

This terrifies beginners and delights tinkerers. I fall firmly in the second camp.

With tools like lazy.nvim and the Lua ecosystem, setting up Neovim has become surprisingly pleasant. You're not fighting arcane config files anymore - you're building something that fits exactly how you work.

Want that sleek VS Code file explorer? There's nvim-tree. Need AI autocompletion like Cursor? Supermaven or Copilot work beautifully. Fancy UI elements? You've got telescope, lualine, and a whole ecosystem of plugins that can make Neovim look however you want.

My setup knows that when I hit <space>ff, I want to find files. <space>e toggles my file explorer. gd jumps to definitions. These aren't arbitrary mappings - they're extensions of how I think about navigating code.

And honestly? I'm constantly tweaking it. New plugin catches my eye? I'm trying it out. Found a better way to organize my keymaps? I'm refactoring the whole thing. Some people set up their config once and forget about it, but for me, tinkering with Neovim is half the fun. It's like having a hobby that directly improves your work.

The terminal is home

There's something satisfying about doing everything in the terminal. While others are alt-tabbing between their editor, terminal, and browser, I'm living in tmux sessions where everything flows together.

My Neovim sits alongside running servers, git operations, and build processes. No context switching, no separate applications fighting for screen real estate. Just one cohesive workspace where the keyboard rules everything.

This setup has made me more comfortable with command-line tools in general. When your editor is terminal-native, you naturally start reaching for grep, sed, and all the other Unix tools that make development more powerful.

This workflow feels lightweight and efficient to me. No Electron apps eating RAM, no vendor lock-in, just tools that do exactly what they say they do.

Neovim still surprises me. Not with flashy features, but with how well it gets out of my way and lets me focus on what matters - writing good code.

The Problem

Adding likes and views to a static blog creates this weird tension. Static sites are pre-rendered at build time and cached globally, which makes them lightning fast. But engagement features are dynamic, user-specific, and need real-time updates.

The naive approach? Make everything dynamic. But there's a better way.

Why Not Suspense?

Suspense looks tempting because it seems to give you the best of both worlds:

// This seems like a good idea...
<Suspense fallback={<div>Loading views...</div>}>
  <ViewCount slug={post.slug} />
</Suspense>

At first glance, this looks perfect. The page loads fast, shows a loading state, then hydrates the engagement data. It feels like you're getting instant page loads with progressive enhancement.

The problem is that Suspense breaks static generation. When Next.js sees Suspense boundaries, it assumes the page needs server-side rendering because it has dynamic content. This means your pages can't be pre-rendered at build time anymore.

Instead of having pre-built pages that can be prefetched and cached in your browser, every page navigation now needs to hit a server. Even if that server is fast, it's still slower than having the page already loaded in your browser. Plus, you lose the amazing prefetching benefits that make static sites so good.

The Magic of Static Sites + Prefetching

Here's what makes static sites feel so fast: Next.js automatically prefetches all the links on your page when they come into view. So when someone's reading your blog post and they see a link to another post in your navigation or footer, Next.js quietly downloads that page in the background.

When they actually click the link, the page appears instantly because it's already loaded. This is what makes well-built Next.js sites feel like native mobile apps, instant navigation between pages.

If you break static generation with Suspense, you lose this prefetching magic. Now every page navigation needs to hit a server, which kills that snappy feeling.

The Better Approach

Instead, I render a static shell and fetch engagement data on the client side:

// This keeps your page static
export default function BlogPost({ post }: { post: BlogPost }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div className="flex gap-4">
        <EngagementStats slug={post.slug} />
      </div>
      <div className="markdown">{post.content}</div>
    </article>
  );
}

The EngagementStats component fetches both views and likes after the page loads. This way, the page itself is completely static and gets all the prefetching benefits, but the engagement features are still dynamic.

Choosing the Right Database

For storing likes and views, I use Redis (specifically Upstash Redis). You might wonder why not just use a regular database like PostgreSQL.

Redis is perfect for this type of simple data because it's an in-memory database. That means it stores everything in RAM instead of on disk, which makes it incredibly fast. When someone likes a post, I can increment the counter and check if they've already liked it in just a few milliseconds.

For engagement features where you're doing lots of simple reads and writes (getting view counts, incrementing likes, checking if someone already liked something), Redis is way overkill in the best way. It's like using a sports car for grocery shopping, but hey, groceries get done really fast.

Building the View Counter

First, I created API routes for views and likes:

// app/api/views/[slug]/route.ts
import { NextRequest, NextResponse } from "next/server";
import { getViewCount, recordViewCount } from "@/lib/actions/viewCount";

export async function GET(
  request: NextRequest,
  { params }: { params: Promise<{ slug: string }> },
) {
  try {
    const { slug } = await params;

    // Get current views and record this view in parallel
    const [currentViews] = await Promise.all([
      getViewCount(slug),
      recordViewCount(slug), // Auto-record the view on GET
    ]);

    return NextResponse.json({
      views: currentViews.views + 1, // Return incremented count
    });
  } catch (error) {
    console.error("Error fetching/recording views:", error);
    return NextResponse.json(
      { error: "Failed to fetch views" },
      { status: 500 },
    );
  }
}

Then the client component that handles both views and likes:

// components/blog/engagement-stats.tsx
"use client";

import useSWR from "swr";
import { ShowViews } from "./show-views";
import { LikeButton } from "./like-button";

interface EngagementStatsProps {
  slug: string;
}

export function EngagementStats({ slug }: EngagementStatsProps) {
  const {
    data: likes,
    error: likesError,
    isLoading: likesLoading,
  } = useSWR(`/api/likes/${slug}`);
  const {
    data: views,
    error: viewsError,
    isLoading: viewsLoading,
  } = useSWR(`/api/views/${slug}`);

  const isLoading = likesLoading || viewsLoading;

  return (
    <div
      className={`flex items-center gap-2 transition-all duration-500 ${
        isLoading ? "translate-y-1 opacity-0" : "translate-y-0 opacity-100"
      }`}
    >
      <ShowViews views={views?.views ?? 0} hasError={!!viewsError} />
      <LikeButton
        slug={slug}
        count={likes?.count ?? 0}
        liked={likes?.hasLiked ?? false}
        isLoading={likesLoading}
        hasError={!!likesError}
      />
    </div>
  );
}

Building the Like Button

For likes, I wanted to prevent people from spamming the button, so I added IP hashing and server actions:

// lib/actions/likeCount.ts
"use server";

import redis from "../redis";
import { getHashedIP } from "./hashIP";

export async function getLikeCount(slug: string) {
  const hashedIp = await getHashedIP();
  const likeKey = ["likes", "blogs", slug].join(":");
  const userLikeKey = ["ip", hashedIp, "liked", slug].join(":");

  const [likeCount, hasLiked] = await Promise.all([
    redis.get<number>(likeKey),
    redis.get(userLikeKey),
  ]);

  return {
    count: likeCount ?? 0,
    hasLiked: !!hasLiked,
  };
}

export async function toggleLike(slug: string) {
  const hashedIp = await getHashedIP();
  const likeKey = ["likes", "blogs", slug].join(":");
  const userLikeKey = ["ip", hashedIp, "liked", slug].join(":");

  const hasLiked = await redis.get(userLikeKey);
  const pipeline = redis.pipeline();

  if (hasLiked) {
    // Unlike
    pipeline.decr(likeKey);
    pipeline.del(userLikeKey);
  } else {
    // Like
    pipeline.incr(likeKey);
    pipeline.set(userLikeKey, "1");
  }

  await pipeline.exec();
  const newCount = Math.max(0, (await redis.get<number>(likeKey)) ?? 0);

  return {
    success: true,
    newCount,
    liked: !hasLiked,
  };
}

The like system also needs API endpoints to handle both fetching current like state and toggling likes. Here's the API route that connects to our server actions:

// app/api/likes/[slug]/route.ts
import { NextRequest, NextResponse } from "next/server";
import { getLikeCount, toggleLike } from "@/lib/actions/likeCount";

export async function GET(
  request: NextRequest,
  { params }: { params: Promise<{ slug: string }> },
) {
  try {
    const { slug } = await params;
    const result = await getLikeCount(slug);

    return NextResponse.json({
      count: result.count,
      hasLiked: result.hasLiked,
    });
  } catch (error) {
    console.error("Error fetching likes:", error);
    return NextResponse.json(
      { error: "Failed to fetch likes" },
      { status: 500 },
    );
  }
}

export async function POST(
  request: NextRequest,
  { params }: { params: Promise<{ slug: string }> },
) {
  try {
    const { slug } = await params;
    const result = await toggleLike(slug);

    if (result.success) {
      return NextResponse.json({
        count: result.newCount,
        hasLiked: result.liked,
      });
    } else {
      return NextResponse.json(
        { error: "Failed to toggle like" },
        { status: 500 },
      );
    }
  } catch (error) {
    console.error("Error toggling like:", error);
    return NextResponse.json(
      { error: "Failed to toggle like" },
      { status: 500 },
    );
  }
}

And the like button component:

// components/blog/like-button.tsx
"use client";

import { mutate } from "swr";
import { useTransition } from "react";
import { Heart } from "lucide-react";

interface LikeButtonProps {
  slug: string;
  count: number;
  liked: boolean;
  size?: "sm" | "md" | "lg";
  isLoading?: boolean;
  hasError?: boolean;
}

export function LikeButton({
  slug,
  count,
  liked,
  size = "md",
  isLoading = false,
  hasError = false,
}: LikeButtonProps) {
  const [isPending, startTransition] = useTransition();

  const sizeConfig = {
    sm: { icon: 14, text: "text-xs", gap: "gap-1" },
    md: { icon: 16, text: "text-sm", gap: "gap-1" },
    lg: { icon: 20, text: "text-base", gap: "gap-2" },
  };

  const config = sizeConfig[size];

  const handleLike = () => {
    const newLiked = !liked;
    const newCount = liked ? count - 1 : count + 1;

    // Optimistic update
    mutate(
      `/api/likes/${slug}`,
      { count: newCount, hasLiked: newLiked },
      false,
    );

    startTransition(async () => {
      try {
        const response = await fetch(`/api/likes/${slug}`, {
          method: "POST",
        });

        if (response.ok) {
          const result = await response.json();
          mutate(`/api/likes/${slug}`, result, false);
        } else {
          // Revert on error
          mutate(`/api/likes/${slug}`, { count, hasLiked: liked }, false);
        }
      } catch (error) {
        console.error("Failed to toggle like:", error);
        mutate(`/api/likes/${slug}`, { count, hasLiked: liked }, false);
      }
    });
  };

  return (
    <button
      onClick={handleLike}
      disabled={isPending || isLoading}
      className={`group flex items-center ${config.gap} transition-colors disabled:opacity-50`}
    >
      <Heart
        size={config.icon}
        className={`transition-colors ${
          liked
            ? "fill-black stroke-black"
            : "stroke-neutral-600 group-hover:stroke-black"
        }`}
      />
      <span
        className={`${config.text} transition-colors ${
          liked ? "text-black" : "text-neutral-600 group-hover:text-black"
        }`}
      >
        {hasError ? "0" : count}
      </span>
    </button>
  );
}

Why This Works So Well

This approach keeps pages static while adding interactivity. The initial page load is instant because it's served from a CDN, and the engagement data loads in the background. Pages work without JavaScript (progressive enhancement), and there are no hydration mismatches.

Most importantly, you keep all the prefetching magic that makes static sites feel so snappy.

Making It Even Better with SWR

For an even smoother experience, I use SWR throughout the engagement system. SWR (stale-while-revalidate) is a data fetching library that handles caching, revalidation, and optimistic updates.

The basic idea is that SWR shows you cached data immediately (stale), then fetches fresh data in the background (revalidate). It also gives you tools for optimistic updates, where you update the UI immediately and then sync with the server.

My EngagementStats component uses SWR to fetch both views and likes data:

const {
  data: likes,
  error: likesError,
  isLoading: likesLoading,
} = useSWR(`/api/likes/${slug}`);
const {
  data: views,
  error: viewsError,
  isLoading: viewsLoading,
} = useSWR(`/api/views/${slug}`);

With SWR, clicking like/unlike feels instant because the UI updates immediately with mutate(), even before the server responds. If the server request fails, I manually revert the optimistic update to keep the UI in sync.

Wrapping Up

You don't have to sacrifice static generation to add dynamic features. Keep your shell static, load engagement data client-side, and make sure everything works without JavaScript first. Your users get fast page loads, instant navigation between pages, and engaging interactions without any compromises.

This tutorial will walk you through the process, highlight the pitfalls I hit, and show you the final working solution.

Why Dynamic OG Images?

Static OG images are fine, but dynamic ones let you:

• Show the post title, tags, and excerpt on the image
• Automatically update images when you change your content
• Avoid manually designing a new image for every post

Step 1: The Naive Approach (and Why It Fails)

My first attempt was to use a dynamic route handler for OG images:

// app/blog/[slug]/opengraph-image.tsx
import { getBlogPostBySlug } from "@/lib/postsLoaders";
import { ImageResponse } from "next/og";

export const alt = "My Blog";
export const size = { width: 1200, height: 630 };
export const contentType = "image/png";

export default async function Image({ params }: { params: { slug: string } }) {
  const post = getBlogPostBySlug(params.slug);
  // ...generate image...
}

My getBlogPostBySlug function used fs.readFileSync to read markdown files from disk. This worked perfectly in development.

But in production, all OG images broke.

Step 2: Understanding the Problem

Here’s what I learned:

• In development:
  Your local server has access to the file system, so fs works.
• In production (Vercel, Netlify, etc.):
  Dynamic route handlers (like opengraph-image.tsx) run in a serverless/edge environment, which does not have access to your project’s file system (except for /public).
  Any attempt to use fs to read files will fail.

Key lesson:

You cannot use fs to read files in dynamic route handlers in production.

Step 3: The Docs Confusion

The Next.js docs show examples using fetch or even fs to load assets. The key detail is:

• If you use generateStaticParams to enumerate all possible slugs at build time, Next.js will generate the OG images as static assets, and you can use fs (because it runs at build time).
• If you don’t, the handler runs at request time in production, and fs will fail.

Step 4: The Solution — Static Generation with generateStaticParams

To make it work, I added a generateStaticParams export to my OG image route:

// app/blog/[slug]/opengraph-image.tsx
export async function generateStaticParams() {
  const { getAllBlogPosts } = await import("@/lib/postsLoaders");
  const posts = getAllBlogPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Now, Next.js knows all possible slugs at build time and generates the OG images as static files. This means:

• You can use fs in your handler (it runs at build time).
• Your OG images are fast and reliable in production.

Step 5: The Final Working Code

Here’s the complete code for my OG image route:

// app/blog/[slug]/opengraph-image.tsx
import { getBlogPostBySlug } from "@/lib/postsLoaders";
import { ImageResponse } from "next/og";

export const alt = "jakmaz.com";
export const size = {
  width: 1200,
  height: 630,
};
export const contentType = "image/png";

export default async function Image({ params }: { params: { slug: string } }) {
  const post = getBlogPostBySlug(params.slug);

  if (!post) {
    return new Response("Not found", { status: 404 });
  }

  return new ImageResponse(
    <div
      style={{
        height: "100%",
        width: "100%",
        display: "flex",
        flexDirection: "column",
        justifyContent: "space-between",
        backgroundColor: "#FFFFFF",
        color: "#111827",
        padding: "64px",
        fontFamily: "sans-serif",
        boxSizing: "border-box",
        position: "relative",
      }}
    >
      {/* Left accent bar */}
      <div
        style={{
          position: "absolute",
          top: 0,
          left: 0,
          width: "12px",
          height: "100%",
          backgroundColor: "#000000",
        }}
      />

      {/* Title + Tags + Excerpt */}
      <div style={{ display: "flex", flexDirection: "column", gap: "32px" }}>
        {/* Tags */}
        <div style={{ display: "flex", gap: "12px", flexWrap: "wrap" }}>
          {post.tags.map((tag, index) => (
            <div
              key={index}
              style={{
                backgroundColor: "#000000",
                color: "#FFFFFF",
                padding: "8px 16px",
                borderRadius: "8px",
                fontSize: "18px",
                fontWeight: 600,
              }}
            >
              {tag}
            </div>
          ))}
        </div>

        <h1
          style={{
            fontSize: 72,
            fontWeight: 800,
            lineHeight: 1.1,
            margin: 0,
          }}
        >
          {post.title}
        </h1>
        <p
          style={{
            fontSize: 32,
            color: "#6B7280",
            margin: 0,
            maxWidth: "80%",
            lineHeight: 1.4,
          }}
        >
          {post.excerpt}
        </p>
      </div>

      {/* Footer author name */}
      <div
        style={{
          display: "flex",
          justifyContent: "space-between",
          width: "100%",
          fontSize: 28,
          color: "#6B7280",
          fontWeight: 600,
        }}
      >
        <span>jakmaz.com</span>
        <span>{new Date(post.date).toLocaleDateString()}</span>
      </div>
    </div>,
    {
      ...size,
    },
  );
}

export async function generateStaticParams() {
  const { getAllBlogPosts } = await import("@/lib/postsLoaders");
  const posts = getAllBlogPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Step 6: Alternative — Dynamic API Route (No fs!)

If you want to generate OG images dynamically (e.g., always up-to-date, or for slugs not known at build time), you can use an API route:

// app/api/og/route.tsx
import { ImageResponse } from "next/og";

export const runtime = "edge";

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const title = searchParams.get("title") || "My Blog";
  // ...generate image using title...
  return new ImageResponse(<div>{title}</div>);
}

But:
You cannot use fs in this API route in production. Pass all needed data via query params, or use a database or pre-bundled JSON.

Key Takeaways

• Don’t use fs in dynamic route handlers unless you’re sure they run at build time.
• Use generateStaticParams to statically generate OG images for all known slugs.
• For dynamic images, use an API route and pass all data via query params or use a runtime-available data source.

This post walks you through a minimal LSP setup using lazy.nvim for plugin management.

What is LSP?

LSP stands for Language Server Protocol - it defines a standard way for editors and language-specific servers to communicate.

By connecting Neovim to language servers, you get:

• Syntax checking (errors, warnings)
• Auto-completion
• Go-to-definition, references
• Hover documentation
• Code actions (like quick-fixes, rename, refactor)
• Formatting

Plugins Used

We’ll use the following Neovim plugins:

• mason.nvim
  Easily install and manage LSP servers, formatters, linters, and debuggers from inside Neovim.

• mason-lspconfig.nvim
  A bridge between Mason and Neovim’s built-in LSP client. It ensures the correct servers are installed and makes them easy to configure.

• nvim-lspconfig
  Official plugin for configuring and launching language servers. It handles the actual connection between Neovim and each server.

Step 1: Create lsp-config.lua

To keep things organized, start by creating a new file for LSP-related plugins:

~/.config/nvim/lua/plugins/lsp-config.lua

If you're using a plugin manager like lazy.nvim or packer.nvim, this is where you’ll define and configure your LSP setup.

Step 2: Install mason.nvim - A Package Manager for LSPs

First, we need a way to install and manage language servers without dealing with npm, pip, or system package managers. That’s exactly what mason.nvim does.

What is Mason?

mason.nvim is a plugin that downloads and manages:

• LSP servers
• Formatters (like prettier, black, clang-format)
• Linters (like eslint, flake8)
• Debuggers

All directly from Neovim - cross-platform and without leaving your config.

Add this to your lsp-config.lua:

return {
  {
    'mason-org/mason.nvim',
    opts = {},
  },
}

Now What?

Restart Neovim and run:

:Mason

This opens an UI where you can:

• Browse all available LSP servers, linters, and formatters
• Install or uninstall them with a keypress
• See what's already installed

Neovim doesn't yet know which language servers to connect to, or how to talk to them. Let’s fix that next.

Step 3: Install mason-lspconfig.nvim - Connecting Mason to Neovim

Now that mason.nvim is installed, you might be wondering:

“How does Neovim know which LSP servers to actually set up and connect to my code?”

That’s where mason-lspconfig.nvim comes in.

Why We Use mason-lspconfig.nvim

This plugin acts as a bridge between Mason and Neovim's built-in LSP client. It:

• Automatically installs LSP servers listed in ensure_installed
• Helps match Mason’s internal server names to the config names expected by Neovim
• Makes setup smoother and less error-prone

Add this to your lsp-config.lua:

{
  "mason-org/mason-lspconfig.nvim",
  opts = {
    ensure_installed = {
      "lua_ls",
      "pyright",
      "ts_ls",
      "rust_analyzer",
      "clangd"
    },
  },
},

This tells Mason to automatically install these popular LSP servers on startup:

• lua_ls: for Lua (great for configuring Neovim)
• pyright: Python
• ts_ls: JavaScript & TypeScript
• rust_analyzer: Rust
• clangd: C and C++

You can find the full list of supported servers here.

After this step:
Neovim now knows:

• Which LSP servers to install
• Where to find them (via Mason)
• That these servers are available for connection

But we still haven’t actually hooked up Neovim to the servers. That’s what we’ll handle next using nvim-lspconfig.

Step 4: Connect to LSP Servers with nvim-lspconfig

So far, we've told Mason which language servers to install and manage. But installing the servers is only half of the setup - we still need to tell Neovim how to connect to each server and actually start using them.

That's exactly what nvim-lspconfig is for.

What is nvim-lspconfig?

nvim-lspconfig is the official plugin maintained by the Neovim team that provides easy configurations for connecting to LSP servers. Each language server needs to be started with some settings, and this plugin handles the boilerplate for you.

In short, it’s the final link in the chain:

• Mason installs the servers
• mason-lspconfig tells us which ones we want
• nvim-lspconfig starts them and connects them to Neovim

Without this, the servers would be installed on your system, but Neovim wouldn’t use them.

Add this to your lsp-config.lua:

{
  "neovim/nvim-lspconfig",
  config = function()
    local lspconfig = require("lspconfig")

    lspconfig.lua_ls.setup({})
    lspconfig.pyright.setup({})
    lspconfig.ts_ls.setup({})
    lspconfig.rust_analyzer.setup({})
    lspconfig.clangd.setup({})
  end
},

This code:

• Loads the lspconfig module
• Calls .setup({}) for each installed server
• Initializes each language server so it attaches to your files when you open them

You can customize the {} part for each server to pass in specific settings, root directories, or formatting options - but keeping it empty works as a good starting point.

How to Check if It's Working

Once you've saved your config and restarted Neovim, open a file in one of the supported languages (like .lua, .py, or .rs), and run:

:LspInfo

This will show you:

• Which servers are currently installed
• Which ones are attached to your current buffer
• Whether your LSP setup is working properly

You should also see things like:

• Function names and types on hover
• Inline diagnostics under problematic code
• Completion suggestions from the language server

At this point, you're connected - LSP is up and running.

Result

Our resulting config is

return {
  -- Mason: installs and manages external tools like LSP servers
  {
    'mason-org/mason.nvim',
    opts = {},
  },

  -- Mason-LSPConfig: tells Mason which servers to install and links them to lspconfig
  {
    'mason-org/mason-lspconfig.nvim',
    opts = {
      ensure_installed = {
        'lua_ls', -- Lua (great for editing Neovim config)
        'pyright', -- Python
        'ts_ls', -- TypeScript / JavaScript
        'rust_analyzer', -- Rust
        'clangd', -- C / C++
      },
    },
  },

  -- nvim-lspconfig: connects Neovim to installed LSP servers
  {
    "neovim/nvim-lspconfig",
    config = function()
      local lspconfig = require("lspconfig")

      lspconfig.lua_ls.setup({})
      lspconfig.pyright.setup({})
      lspconfig.ts_ls.setup({})
      lspconfig.rust_analyzer.setup({})
      lspconfig.clangd.setup({})
    end
  },
}

With this setup:

• LSP servers are installed automatically.
• Neovim is connected to the servers and offers full IDE functionality.
• Keymaps work out-of-the-box when a server is active.
• Code actions look great thanks to Telescope.

It’s minimal, modular, and fully powered by lazy.nvim.

Interested in my full Neovim setup and dotfiles? Check them out here: jakmaz/dotfiles

Edit: I removed newsletter on my website in favor of RSS feed but this post remains relevant!

Adding an email newsletter to your website is a great way to engage visitors and build an audience. I wanted a solution to keep users updated with every new post while keeping things simple and cost-effective.

Choosing a Newsletter Service

To find the right service, I set a few requirements:

1. Free tier – No upfront cost for small mailing lists.
2. Custom domain support – The ability to send emails from my own domain.
3. API access – So I could programmatically add subscribers.

After testing several options, I found that Sender.net met all my requirements. It offers a free plan with:

• Up to 2,500 subscribers
• 15,000 emails per month

This was more than enough for my needs, so I proceeded with the next steps.

Step 1: Creating a Simple React Form

Let's start with a basic email subscription form in Next.js. This form will collect the user's email and submit it when they click the button.

export default function Subscribe() {
  return (
    <form className="flex flex-col gap-2">
      <div className="flex gap-2">
        <input name="email" type="email" placeholder="Email Address" />
        <button type="submit">Subscribe</button>
      </div>
    </form>
  );
}

What This Code Does:

• It creates a simple input field for the email address.
• It includes a "Subscribe" button for submission.
• Right now, it doesn't send data anywhere—we'll handle that in the next steps.

Step 2: Adding an API Action to Handle Submissions

To connect our form to Sender.net, we need a backend function that will:

• Send a POST request to Sender.net’s API.
• Pass the user's email along with our API token for authentication.

Instead of creating a separate API route, we’ll use Next.js Server Actions, which allow calling server-side functions directly from a form.

Securing the API Key

Before we write our API request, we need to store the Sender.net API key securely.
Create a .env.local file in your Next.js project root and add:

SENDER_TOKEN=your_sender_net_api_key

Make sure to restart your Next.js server after adding this to load the environment variable. If you're new to environment variables in Next.js, check out the official .env documentation.

Adding backend logic

Create actions.ts and add the following:

"use server";

export async function addNewsletterSubscriber(_: unknown, formData: FormData) {
  // Extract the email submitted via the form
  const email = formData.get("email");

  // Define the API URL for Sender.net
  const url = new URL("https://api.sender.net/v2/subscribers");

  // Set request headers, including authentication with our API token
  const headers = {
    // Secure API key from environment variables
    Authorization: "Bearer " + process.env.SENDER_TOKEN,
    "Content-Type": "application/json",
    Accept: "application/json",
  };

  // Data payload to send in the request
  const data = {
    email: email,
    trigger_automation: false, // Prevents triggering automation flows in Sender.net
  };

  try {
    // Send the request to Sender.net
    const response = await fetch(url, {
      method: "POST",
      headers,
      body: JSON.stringify(data),
    });

    // Parse the response
    const responseData = await response.json();

    // Handle success or failure
    if (response.ok && responseData.success) {
      return { message: "Subscription successful!" };
    } else {
      console.error("Subscription failed:", responseData);
      return { message: "Subscription failed. Please try again." };
    }
  } catch (error) {
    console.error("An error occurred:", error);
    return { message: "An error occurred. Please try again later." };
  }
}

What This Code Does:

• Extracts the submitted email from the form.
• Sends a POST request to Sender.net with the email.
• Uses an API token stored in .env.local (keeps it secure).
• Handles success and error cases gracefully.

Step 3: Connecting the Form to the API

Now, let's modify our frontend form to use the API action. This will make the form interactive—when the user submits their email, it will actually be stored in Sender.net.

Update the Subscribe component:

"use client";

import { addNewsletterSubscriber } from "@/lib/actions";
import { useActionState } from "react";

export default function Subscribe() {
  // useActionState connects our form to the server action
  const [response, formAction, isPending] = useActionState(
    addNewsletterSubscriber,
    undefined,
  );

  return (
    <form action={formAction} className="flex flex-col gap-2">
      <div className="flex gap-2">
        <input name="email" type="email" placeholder="Email Address" required />
        <button disabled={isPending}>Subscribe</button>
      </div>
      {/* Display feedback message after submission */}
      <p>{response?.message}</p>
    </form>
  );
}

What This Code Does:

• Uses useActionState() to connect the form to our server action.
• Calls addNewsletterSubscriber when the form is submitted.
• Displays a message (Subscription successful! or Subscription failed.).
• Disables the button while the request is pending.

Step 4: Testing and Deploying

Now that everything is set up:

1. Run your Next.js app and enter an email into the form.
2. Check your Sender.net account to see if the email was added.
3. Deploy to production (e.g., Vercel, Netlify) with your .env properly configured.

Summary

By following this guide, you’ve successfully:

• Built a React form for newsletter signups.
• Connected it to Sender.net’s API using Next.js Server Actions.
• Ensured security by storing the API key safely.

Now, your website visitors can subscribe to your newsletter seamlessly! 🎉

Innotech Labs and My First Coding Experience

In 2016, free coding workshops called Innotech Labs started in my town, led by Konrad Strzelecki. I signed up and really enjoyed the experience. The labs were held every weekend morning, and I found myself waiting the whole week for them. Each session, Konrad brought a big pack of cookies, and we worked on a variety of cool projects. We played with drones, built Lego Mindstorms robots, coded in Scratch, and even started with JavaScript—my first programming language.

The labs continued for a couple of years before they eventually stopped. After they ended, I asked for materials to continue learning on my own, but eventually, I also took a break as I started high school and focused on other things.

Rediscovering Coding

A few years later, I came across a YouTube video that sparked my interest in coding again. The video showed how to send a bee script over WhatsApp using Python, which was exciting for me because it involved automation—something I always enjoyed. I followed the tutorial, downloaded Python, and successfully sent the script to a friend. The fun of making it work led me to explore more with automation.

I searched for more tutorials and found a video about creating a Piano Tiles bot using pyautogui, a Python library for automation. That project opened up a new world for me. I spent a lot of time coding Python scripts for automating tasks, mostly involving screen scanning and desktop apps. I even started exploring APIs and sending requests, which made me realize just how much coding could do.

Finding My Path

In high school, I studied to become an automation technician, but I soon realized that I wasn’t really interested in electronics and physical systems. I knew I wanted to focus on software, so I decided to pursue Computer Science at Maastricht University.

Once I started my university studies, I began learning the fundamentals of programming and computer science in a structured way. While I had played around with coding before, this was where I started learning real concepts. I explored topics like Java, static typing, computer networks, data structures, and much more. Though I haven’t learned everything yet, I’m enjoying the process and feel like I’m building a strong foundation.

Beyond just the coursework, I’ve started working on side projects that allow me to create useful tools and solutions. It's rewarding to see something I’ve built help others, and that drives me to continue learning and improving my skills.