DEV Community: mbadr3227-sys

I built a content recommender as a graph, and it found similarities I wasn't looking for

mbadr3227-sys — Sun, 16 Aug 2026 23:01:05 +0000

Most beginner recommendation projects are a dictionary lookup. You type
"comedy", it returns the comedy list. That works, and it is also the
reason those projects are forgettable: a dictionary can tell you what is
similar, but it can never tell you what is interestingly different.

I wanted the second thing. So I modelled the catalogue as a weighted
graph instead, and ended up finding a kind of similarity I had not
designed for.

The project is called CreatorRoute. It recommends short-form content
formats: you name a video you liked, and it gives you close matches plus
a few deliberate outliers.

The data

Forty rows of short-form videos, hand-written, five attributes each:

id,title,niche,hook_type,length,editing_style,cta_type
4,Stop posting at 9am,marketing,contrarian,short,jump-cut,comment
23,Stop using this transition,editing,contrarian,short,jump-cut,comment

Remember those two rows. They matter later.

The one rule I followed while writing the dataset: every attribute value
had to repeat across several rows. Unique values produce isolated nodes,
and isolated nodes make a graph that cannot be traversed. If every video
had its own one-off hook_type, there would be no edges to walk.

Building the graph

Every video is a node. Two nodes get an edge when they share at least
one attribute. The edge weight is the inverse of the number of shared
attributes:

ATTRIBUTES = ["niche", "hook_type", "length", "editing_style", "cta_type"]


def shared_attributes(a, b):
    return sum(1 for attr in ATTRIBUTES if a[attr] == b[attr])


def build_graph(items):
    graph = {item_id: [] for item_id in items}
    ids = list(items)

    for i in range(len(ids)):
        for j in range(i + 1, len(ids)):
            a, b = items[ids[i]], items[ids[j]]
            shared = shared_attributes(a, b)

            if shared > 0:
                weight = 1 / shared
                graph[ids[i]].append((ids[j], weight))
                graph[ids[j]].append((ids[i], weight))

    return graph

Inverting the count is the whole trick. Four shared attributes gives a
weight of 0.25; one shared attribute gives 1.0. More in common means a
shorter edge, which means shortest-path algorithms rank by similarity
without any extra work.

The range(i + 1, ...) avoids comparing each pair twice.

Where BFS failed

My first plan was breadth-first search alone. Depth 1 for close matches,
depth 2 for discovery. Clean, simple, no weights needed.

It did not work. At 15 items, a BFS from any node reached 10 of the 14
others at depth 1. One shared attribute is enough for an edge, and with
five attributes across a small catalogue, nearly everything connects to
nearly everything.

BFS answers is this reachable, and in how many hops. In a dense graph,
the answer is almost always "yes, one hop", which is not a ranking. A
video sharing four attributes and a video sharing one were both simply
"neighbours".

Where Dijkstra fixed it

Dijkstra's algorithm walks the same graph but accumulates weight instead
of counting hops:

import heapq


def dijkstra(graph, start):
    distances = {start: 0}
    heap = [(0, start)]
    settled = set()

    while heap:
        dist, current = heapq.heappop(heap)

        if current in settled:
            continue
        settled.add(current)

        for neighbor, weight in graph[current]:
            new_dist = dist + weight
            if new_dist < distances.get(neighbor, float("inf")):
                distances[neighbor] = new_dist
                heapq.heappush(heap, (new_dist, neighbor))

    del distances[start]
    return distances

Same neighbours, real ordering. Something four-fifths identical scores
0.25 and something barely related scores 1.0.

BFS was not wasted, though. It moved jobs: it now supplies the discovery
list, pulling nodes at depth 2 that share nothing directly with your pick
but sit two hops away. Two algorithms, two questions, one graph.

The part I did not plan

Here is the output for "Stop posting at 9am", a marketing video:

Because you liked: Stop posting at 9am
(marketing / contrarian / jump-cut)

  Closest matches:
    - 3 mistakes killing your ad spend  [0.25]
    - The one word killing your CTA     [0.25]
    - Stop using this transition        [0.25]

  Worth exploring:
    - 6 free tools I use daily
    - 5 onboarding flows that work
    - My first 1000 orders

The third close match is about video editing. The second is about
copywriting. Neither is marketing.

They rank at the top because they share contrarian + short +
jump-cut + comment. The graph had quietly learned to match on
format rather than topic — same shape of video, different
subject entirely.

I did not build that. I built "count shared attributes". Treating topic
as one attribute among five, rather than as the primary key, was enough
for structural similarity to emerge on its own. A dictionary keyed on
category could not have surfaced it, because the key would have thrown
the other four attributes away before the comparison started.

Search has the same trade-off

The CLI needs to find your video before it can recommend anything, and
that turned out to be its own small lesson in complexity.

prefix_search uses binary search over a sorted index — O(log n), but
only matches titles that start with your query. keyword_search scans
every title at O(n) and matches anywhere. Searching "ad" finds nothing
with the fast one and four titles with the slow one, including
"Rewriting a bad ad live".

The CLI tries fast first and falls back:

def find_matches(items, index, query):
    hits = prefix_search(index, query)
    return hits if hits else keyword_search(items, query)

At 40 items the difference is unmeasurable. Writing both anyway made the
trade-off concrete in a way that reading the Big O table never did.

What I would change

The dataset is hand-written, which caps how much the graph can surprise
me — I chose the attributes, so I partly chose the connections. Real
scraped data would be a better test.

The build_graph function is O(n²): every pair compared. Fine at 40
items, painful at 40,000. The fix is bucketing by attribute value and
only comparing within buckets, which I have not needed yet.

And attributes are currently equal. Sharing an editing_style counts as
much as sharing a niche, which is probably wrong. Weighting them
differently is the obvious next experiment.

Takeaway

If you are working through a recommendation project, resist the
dictionary. The graph is not much more code — under 200 lines total, no
dependencies outside the standard library — and it gives you somewhere
to put a second algorithm, a real reason to care about edge weights, and
occasionally a result you did not design.

Code: github.com/mbadr3227-sys/creatorroute

I Kept Rewriting the Same Five Lines of Pandas, So I Built a Terminal Tool Instead

mbadr3227-sys — Thu, 06 Aug 2026 07:49:34 +0000

Every time I opened a new dataset, I typed the same thing:

df.shape
df.head()
df.isna().sum()
df.describe()
df.corr()

Five lines, every single time, in a fresh notebook cell. It took maybe forty seconds. But it was forty seconds of typing something I already knew I wanted, before I could start on the part I actually cared about.

So I built DataPeek — a terminal program that does all of it from a menu. You point it at a CSV, press a number, and read the answer.

This was my portfolio project for Codecademy's CS 101: Introduction to Programming, and I want to write about the parts that surprised me, not just what the tool does.
The shape of the thing

The whole program is two files.

main.py runs the interface: it prints a banner, loads a file, shows a menu, and loops until you quit. data_tools.py holds the analysis — one function per menu option, each taking a DataFrame and printing a report.

The piece that ties them together is a dictionary:
ACTIONS = {
"1": dt.show_overview,
"2": dt.show_head,
"3": dt.show_missing,
"4": dt.show_stats,
"5": dt.show_value_counts,
"6": dt.show_correlations,
"7": dt.filter_and_export,
}
My first version was a long if/elif chain. It worked, but every new feature meant editing the loop, and the loop kept growing. Storing the functions in a dictionary meant the loop stopped changing entirely:
action = ACTIONS.get(choice)
if action is None:
print("I don't know that option. Try a number from the menu, or 'q'.")
continue
action(df)
Adding a feature is now a function plus one line in the dictionary. That was the first moment the project taught me something I hadn't gone looking for: functions are values you can store, not just things you call.

Users type whatever they want

I had never written a program that asked for input before. Every prior exercise ran on data I controlled — a CSV I'd already inspected, a variable I'd set myself two lines earlier.

The first time I ran DataPeek, I broke it within thirty seconds. I typed python main.py at the prompt — the program was already running, and it was asking me for a file path, but my hands typed the command anyway out of habit. Then I pressed Enter on an empty prompt to see what would happen.

Both times, it held. It told me it needed a file path and asked again.

That only worked because I'd already spent most of my later commits writing guards instead of features. The number prompt became this:
def ask_int(prompt, default, low, high):
raw = input(prompt).strip()
if not raw:
return default
try:
value = int(raw)
except ValueError:
print(f"Not a number. Using {default}.")
return default
if not low <= value <= high:
print(f"Out of range. Using {default}.")
return default
return value
Eleven lines to read one number. It felt like overkill when I wrote it, and correct the first time the program survived something I hadn't planned for.

File loading got the same treatment — separate except blocks for a missing file, an empty file, a malformed CSV, and a permissions error, each with a message that says what to do next. pd.read_csv raises genuinely different exceptions for these, and catching them separately means the user gets "That doesn't look like a valid CSV" instead of a stack trace.

The general lesson: input validation isn't a finishing touch. It's most of the work of making a program usable by anyone but you.

Making a terminal readable

Terminal output has no styling. No bold, no colour, no layout. All you have is spaces and newlines, and it turns out that's enough if you're deliberate.

f-string alignment did most of the work:
print(f"{col[:24]:<25}{count:>10,}{pct:>9.1f}%")
Left-align the label, right-align the numbers, truncate anything too long, and the columns line up. Right-aligned numbers are easier to compare because the digits stack.

For missing values I added a crude bar:

bar = "#" * int(pct / 5)

One # per five percent. It's about as simple as a visualisation gets, and it still beats reading percentages down a column — you see the worst offenders without comparing anything.

The part that took longest wasn't the code

I want to be honest about the time breakdown, because the tutorials never are.

Writing the program took an afternoon. Getting it to run took considerably longer, and none of that time was spent on Python.

PowerShell refused to activate the virtual environment — Windows blocks script execution by default, and the fix is a single Set-ExecutionPolicy command that I only found by reading the error message properly instead of panicking at the red text. Then pip install pandas died partway through with [Errno 28] No space left on device. My drive had 130 MB free out of 75 GB. Clearing temporary files bought me a gigabyte, which was just enough.

Then Git wasn't installed. Then I ran git remote add pointing at a GitHub repository I hadn't created yet, and spent a minute confused by Repository not found before realising the repository genuinely did not exist.

None of these are interesting problems. All of them are real ones, and they're the actual content of "build a project on your own machine" — the step that tutorials compress into a single line that reads set up your environment.

Where the correlation code got interesting

df.corr() gives a full matrix. Every pair appears twice, and the diagonal is all 1.0. Useful to look at, annoying to rank.

To get a sorted list of distinct pairs, I walked only the upper triangle:

for i, col_a in enumerate(corr.columns):
for col_b in corr.columns[i + 1:]:
value = corr.loc[col_a, col_b]
if pd.notna(value):
pairs.append((col_a, col_b, value))

pairs.sort(key=lambda pair: abs(pair[2]), reverse=True)

Slicing from i + 1 skips the diagonal and everything below it. Sorting on abs() means a correlation of -0.8 ranks above +0.3, which is what you want — strength matters more than direction when you're scanning for what to look at next.

What I'd do next
ASCII histograms, so numeric distributions are visible not just summarised
Group-by summaries, since that's the next thing I always reach for
Saving a full report to a text file
What it actually taught me

I expected to learn pandas. I already knew pandas. What I learned was that the distance between code that works and code someone else can use is mostly made of error handling, clear messages, and structure that lets you add things without breaking what's there — plus a surprising amount of getting a machine to cooperate before any of it runs at all.

The code is on GitHub: github.com/mbadr3227-sys/datapeek

If you also keep typing the same five lines, feel free to steal it.

Content