NotNewNotOld_

Vibe coding a blog from scratch: how it actually went

2026-04-27T00:00:00+02:00

I've been building this blog over the past few weeks in a way I'd describe as vibe coding: starting from a rough idea, using an AI assistant heavily, and letting the feature list grow organically rather than designing everything up front. I want to write down how that process actually worked, because it's different from both "I planned it all out" and "I just vibed with no structure."

What vibe coding is (and isn't)

The term gets thrown around loosely. For me it means: you have a goal and a general aesthetic sense of where you want to end up, you use AI to move fast, and you make decisions in the moment rather than in advance. It is not the same as having no process. If anything, I ended up with more supporting documentation than I would have produced on a traditionally-planned project — because when you're moving fast, you need anchors.

The Tech stack: Pelican

The stack is Pelican, a Python static site generator. Content in Markdown, builds to static HTML, served anywhere. I chose it because I wanted full control over the theme with zero JavaScript framework overhead, and because I write Python and it felt natural. Dependencies are managed with uv, which is fast and reproducible.

The initial commit was just Pelican boilerplate with a custom theme skeleton — base.html, a single style.css, and a dev config (pelicanconf.py) vs production config (publishconf.py). That split — dev config vs prod config — proved important: dev has no minification, no image conversion, no feed URLs. Production runs the full pipeline.

CLAUDE.md: the AI context file

First things first. The CLAUDE.md plays an important role as it lays down the vibe coding process and thought cycle. First I added to the file the general instructions I always like to add to reduce clutter and token usage. It also contains all the instructions for Claude Code: what Pelican is, the dev commands, the theme architecture, the custom metadata fields. Every new conversation starts cold — the AI doesn't remember the previous session — so this file provides the context that makes each session productive from the first message. How to execute the plan and how to implement an idea.

Note

Keep CLAUDE.md short and concise.

This is my general setting for every claude development project I've worked on so far:

Direct and casual tone.
No bullet points unless I ask for.
Never use filler words like "certainly", "absolutely", "great question" or "I'd be happy to".
Read existing files before writing. Don't re-read unless changed.
Thorough in reasoning, concise in output.
No sycophantic openers or closing fluff.
No emojis or em-dashes.
Do not guess APIs, versions, flags, commit SHAs, or package names. Verify by reading code or docs before asserting.

Writing and maintaining CLAUDE.md is a meta-discipline of vibe coding: you're not just building the product, you're maintaining the context layer that makes the AI useful. When a new convention emerges, it goes in CLAUDE.md. When a command changes, it gets updated.

IDEAS.md: the living backlog

Early on I created IDEAS.md. Not a roadmap, not a spec — just a flat list of things I thought the blog should eventually do. The format was simple: unchecked items are pending, checked items are done.

- [x] Reading time — show "3 min read" on each article
- [x] Table of contents — auto-generated from ## headings
- [x] Related posts — At the end of a blog post show 2-3 posts from the same category.

I didn't write the ideas myself but just asked the model what the must-haves and good ideas to implement were. When an idea caught my eye I asked the model to add it to IDEAS.md.

What I didn't expect was how useful the structure would become as the project grew. After the first wave of features landed, I moved ideas into sub-groups (content/UX, navigation, SEO, performance, accessibility, tooling) and add new ones. The file became a real backlog.

At any point I could open IDEAS.md and know exactly where things stood. The unchecked items at the bottom are still there: comments, a newsletter, og:image generation at build time, etc. They didn't get dropped; they just haven't been prioritized yet.

One thing worth noting: the ideas file captured why items existed, not just what they were. That's because when I come back to it cold, I remember the design intent.

It's also kind of surprising how the AI model will sometimes propose to join some ideas together because the changes are connected. Without the ideas file this would not have been possible.

README.md: the operations manual

As features accumulated, I needed somewhere to write down how to actually use the blog as an author. Not for readers — for me, six months from now, when I've forgotten which metadata field enables KaTeX or what the Image: field expects.

README.md is that document. It covers everything I need to know and works as a knowledge base for me, but also for the ai model.

Article metadata: both standard Pelican fields and custom fields the theme adds (Image, JustifyContent, Math, etc.)
The draft workflow: Status: draft keeps a post out of all indexes.
Every Markdown feature: footnotes, callouts/admonitions, LaTeX, tables, blockquotes
Image handling: how to add captions, how floats work, what the WebP pipeline does automatically
Etc.

Writing this as I built things meant I was documenting the design decisions while they were fresh. For example, "The hero image is loading=eager because it's above the fold; everything else is lazy" is something I'd forget in a week. Now it's in the README.

DEPLOY.md: planning the future

DEPLOY.md is a bit different from the others.

It first contained a field study of the different platforms I could deploy the project on. It also elaborates on costs, free tiers and etc. I've also added the exact build commands, a pre-deployment checklist, and a content workflow diagram.

Writing deployment docs before actually deploying is a vibe coding habit I've developed: when the AI helps you move fast, it's easy to defer operational concerns until they're urgent. A DEPLOY.md written speculatively forces you to think through the questions — what Python version, what environment variables — while the context is still fresh.

The commit history: feature by feature

I added git to the project so I could commit every block of code and roll back if necessary.

Each commit is roughly one feature cluster. I didn't do tiny atomic commits or one-commit-per-file; I also didn't do giant "big bang" commits. A commit happened when something worked end-to-end and I'd tested it in the browser. That cadence came naturally from the vibe coding loop: ask for a feature, test it, occasionally ask for fixes, ship it when it feels right.

Setting GitHub as remote would also help me deploy to production in the future.

The process of implementing an idea

It's time to put down the whole cycle.

Select an idea and tell the model to implement it. Add any additional concerns or details.
The model will think about it and implement the following plan:
1. The model explains the proposed changes and how it will affect the project.
2. The model waits for any user question and asks for confirmation to proceed.
3. The model will write down a sample post as requested in Claude.md about the features implemented so I can test them.
4. The model will write down the appropriate info into README.MD
5. The model will mark the idea as done on IDEAS.MD
6. The model will commit with an AI generated commit message

I did not produce a single line of code. Not a single edit. This repeatable cycle is what I would call vibe-coding at its best.

I'm so proud of this that I have set an image:

A clear example of getting and idea done

Take the 404 page for example. The idea was:

- [x] add a cool and techy 404 page with awesome animations

The kick was "I would like to implement the idea for a '404 page'". ... Done.

No edits, done in one go.

What vibe coding produced

The blog has more features than I would have built "by hand" in the same time. Not because the AI wrote everything — I reviewed and tested everything — but because the iteration loop is faster. "Add a reading progress bar" goes from idea to working implementation to tested in one session instead of one weekend. The bottleneck shifts from building to deciding what to build next.

The tradeoff is that the codebase has some inconsistencies you'd iron out in a more deliberate project. Some CSS classes are named differently than I'd have named them if I'd designed the whole stylesheet at once. A few plugin files do things that could be merged. That's fine — the product works, the code is readable, and the inconsistencies can be cleaned up incrementally.

The support files — IDEAS.md, README.md, DEPLOY.md, CLAUDE.md — are what turned vibe coding from a chaotic process into a sustainable one. They're the anchors. Without them, you end up with a blog that works today and is unmaintainable tomorrow.

Success

The blog is called NotNewNotOld_ and this post is the first one that's explicitly about the process of building it. There's something slightly recursive about that. The feature list still has unchecked items. More posts are coming.

Best month calendar visual and slicer in Power BI

2026-03-03T00:00:00+01:00

Power BI, surprisingly, lacks a robust calendar slicer that is both capable of showing visual data, slicing dates from a calendar perspective, and also allowing those dates to be consistently synced between report pages. Here is the solution I found, which is now powering a lot of my reports.

The problem

The available options before this solution are limited:

Matrix visual as a hack: works for cross-filtering, but it is not a real slicer and does not sync state between pages.
Third-party visuals: most are not free. Among the free ones, none gave me a complete solution. They basically lack modern features like this one. I've also tried this one, which was very cool, but the selected month did not sync between visuals on different pages (the month not the selected date). It also lacks some features, and the applied measure doesn't retain the month context in which it's displayed which to me is a bug.

The solution: reconfigured Button Slicer

The key is to use the native Button Slicer in Power BI with a specially built dates table that distributes buttons in the shape of a monthly calendar, with a data heatmap included.

Like you see in the image. I was able to build a month calendar visual that displayed all weeks with the corresponding day number shown on the appropriate weekday column and also display a heatmap with data.

I combine this visual with other buttons to select the year and the month, although this can be set in any other way you want:

It feels great when selecting another month or year and sees that all the buttons rearrange to conform a perfect and accurate month calendar slicer.

Note

Note that I'm using a Monday to Sunday configuration. But it's easy to change it, so Sunday goes first.

The following are the steps to achieve this.

Step 1: The slicer dates table (Power Query)

Create a new table in Power Query. Let's call it SlicerCalendarDates. This table generates all dates in a range and expands them by week so that each date appears in its correct weekday column within its related month.

let
    // 1. Build a list of dates
    StartDate = Date.AddYears(Date.StartOfMonth(Date.AddMonths(Date.From(DateTime.LocalNow()), 7)), -5),
    Current_Date = DateTime.Date(DateTime.LocalNow()),
    Current_Month = Date.Month(Current_Date),
    EndDate = Date.AddMonths(Date.EndOfMonth(Current_Date), 12),
    DateList = List.Dates(StartDate, Duration.Days(EndDate - StartDate) + 1, #duration(1, 0, 0, 0)),
    BaseTable = Table.FromList(DateList, Splitter.SplitByNothing(), {"Fecha"}),

    // 2. Add the start of the week (monday in my case)
    AddStartOfWeek = Table.AddColumn(BaseTable, "InicioSemana", each Date.AddDays([Fecha], -Date.DayOfWeek([Fecha], Day.Monday))),

    // 3. Build the whole week list of all the seven days from monday)
    AddDiasSemana = Table.AddColumn(AddStartOfWeek, "DiasSemana", each List.Transform({0..6}, (i) => Date.AddDays([InicioSemana], i))),

    // 4. Expand the list of dates of the week into rows
    ExpandDiasSemana = Table.ExpandListColumn(AddDiasSemana, "DiasSemana"),

    // 5. Add column with the month that the date corresponds to
    AddMesRelacionado = Table.AddColumn(ExpandDiasSemana, "MesRelacionado", each Date.Month([DiasSemana])),

    // 6. Add column with the year that the date corresponds to
    AddAnioMesRelacionado = Table.AddColumn(AddMesRelacionado, "AnioMesRelacionado", each Date.Year([DiasSemana])),

    // 7. Add the long and short name of the month
    AddNombreMes = Table.AddColumn(AddAnioMesRelacionado, "NombreMes", each Text.Proper(Date.ToText([DiasSemana], "MMMM"))),
    AddNombreMesCorto = Table.AddColumn(AddNombreMes, "NombreMesCorto", each Text.Start([NombreMes], 3)),

    // 8. Add the week of the month
    AddSemanaAnio = Table.AddColumn(AddNombreMesCorto, "SemanaAño", each Date.WeekOfYear([Fecha], Day.Monday)),

    // 9. Remove other columns
    ColumnasSeleccionadas = Table.SelectColumns(AddSemanaAnio, {"Fecha", "SemanaAño", "MesRelacionado", "NombreMes", "NombreMesCorto", "AnioMesRelacionado"}),

    // 10. Remove duplicates by date, week and related month
    QuitarDuplicados = Table.Distinct(ColumnasSeleccionadas),

    // 11. Add day number 
    AddDia = Table.AddColumn(QuitarDuplicados, "Dia", each Date.Day([Fecha])),

    // 12. Add day number as text adding an extra padding before so has a different value wheter is the 30th of the previous month or the 30th of the current month.
    AddDiaTexto = Table.AddColumn(AddDia, "DiaTexto", each (if Date.Month([Fecha]) <> [MesRelacionado] then "ㅤ" else "") & Text.From([Dia])),

    // 13. Add a column to apply the order to the text day of the previos step.
    AddOrdenDiaTexto = Table.AddColumn(AddDiaTexto, "OrdenDiaTexto", each
        let
            fecha = [Fecha],
            dia = Date.Day(fecha),
            mesFecha = Date.Month(fecha),
            anioFecha = Date.Year(fecha),
            mesRel = [MesRelacionado],
            anioRel = [AnioMesRelacionado],
            deltaMeses = (anioFecha - anioRel) * 12 + (mesFecha - mesRel),
            orden = 
                if deltaMeses = 0 then dia
                else if deltaMeses = -1 then -600 + dia
                else if deltaMeses = 1 then 600 + dia
                else null
        in
            orden,
        Int64.Type
    ),

    // 14. Add a bool column to know if this row belongs to the same month or it is from another month
    #"Add MismoMes" = Table.AddColumn(AddOrdenDiaTexto, "MismoMes", each Date.Month([Fecha]) = [MesRelacionado]),

    #"Tipo cambiado" = Table.TransformColumnTypes(#"Add MismoMes",{{"MesRelacionado", Int64.Type}, {"SemanaAño", Int64.Type}, {"NombreMes", type text}, {"Fecha", type date}, {"NombreMesCorto", type text}, {"AnioMesRelacionado", Int64.Type}, {"Dia", Int64.Type}, {"DiaTexto", type text}, {"MismoMes", type logical}}),
    #"Columnas reordenadas" = Table.ReorderColumns(#"Tipo cambiado",{"Fecha", "SemanaAño", "MesRelacionado", "MismoMes", "NombreMes", "NombreMesCorto", "AnioMesRelacionado", "Dia", "DiaTexto", "OrdenDiaTexto"}),

    // 15. Add delta date column that will create an invalid date for the dates that don't belong to the same month
    #"Add DeltaDate" = Table.AddColumn(#"Columnas reordenadas", "FechaDelta", each if [MismoMes] = false then Date.AddYears([Fecha], -150) else [Fecha]),

    #"Tipo cambiado1" = Table.TransformColumnTypes(#"Add DeltaDate",{{"FechaDelta", type date}})
in
    #"Tipo cambiado1"

Why the duplicate rows are intentional

April 28, 29, and 30, for example, appear duplicated: one row belongs to April (its natural month), and another belongs to May (because those days fall in the first week of May). This is correct and necessary for the calendar to show the grey adjacent-day cells.

The blank unicode character trick (ㅤ) in step 12 lets the same day number (e.g. "30") have two distinct text values depending on whether it belongs to the displayed month, keeping the correct button order in the slicer. Step 13 then adds a numeric order column so that a day with the unicode prefix always sorts before the same day without it.

On step 15 we added a "Delta Date" column that is the date column we will connect to our date table. This date will convert the dates that don't belong the natural month to "impossible" dates or dates that don't have any records on my main dates table. I did this so that the measures become much easier to calculate. I didn't need to slice by or show any data on those dates.

Step 2: Sort DiaTexto by OrdenDiaTexto

In Power BI's table view, select the DiaTexto column and apply "Sort by column" → OrdenDiaTexto. This ensures buttons appear in the correct order.

Step 3: Relationship with the main dates table

Connect SlicerCalendarDates to your main dates table using FechaDelta → Date with a many-to-many relationship and single-direction filtering (only SlicerCalendarDates filters the dates table).

As mention earlier, by using FechaDelta instead of Fecha, adjacent-month days point to non-existent dates (150 years back), so they bring no data from the main table. This makes measures much easier to write.

Step 4: Configure the Button Slicer

Add the Button Slicer to the report.
Set the field to DiaTexto only.
In the visual format set: maximum 6 rows and 7 columns (one per day of the week).

You should see the buttons rearrange automatically when switching months.

The tedious part: aligning the weekday header

The visual title does not accept consecutive normal spaces — Power BI ignores them. Use the blank unicode character (ㅤ) to manually space the weekday letters in the title. A real example:

"ㅤ‏‏ㅤㅤㅤ‎L‎‏‏‎ ㅤㅤㅤㅤㅤㅤㅤㅤ‎‎‎Mㅤㅤㅤ ㅤㅤㅤ ‏‏‎ ‎ ㅤX ㅤ ‏ ‏ ㅤㅤ ㅤㅤㅤㅤ‎Jㅤ ‏‏‎ ‏‏‎ ‏‏‎‏‏ㅤㅤㅤㅤ ㅤㅤ‎V‎‎ ㅤㅤㅤㅤㅤㅤㅤㅤSㅤ‏‏‎‎ ㅤㅤㅤㅤㅤㅤㅤD"

Adjust the spacing based on your visual width and button margins.

Info

This is the hard / tedious part.

Step 5: Conditional formatting

Use the slicer's conditional formatting for the heatmap and button states. You will create auxiliary measures so that:

Adjacent-month days get a white background and grey text.
Current-month days get a color gradient based on your measure value.
For adjacent days, return the background color as the measure value so the gradient doesn't bleed into those cells.

Key point: REMOVEFILTERS in your DAX measures

Warning

Any measure that operates on date context needs to remove the SlicerCalendarDates filter to work correctly.

Example with previous year sales:

Sales PY = CALCULATE(
    [Sales],
    REMOVEFILTERS(SlicerCalendarDates),
    SAMEPERIODLASTYEAR(Dates[Date])
)

Without REMOVEFILTERS, the slicer table interferes with time intelligence functions.

Final result

A monthly calendar that:

Shows each day in its correct weekday column.
Displays a data heatmap on the buttons.
Syncs natively between report pages.
Slices by date other visuals
Rearranges dynamically when selecting a different month or year.

Note

You can change the size of the visual so it can fit in different places, but remember that you will have to play with the unicode char for the tittle.