DEV Community: GrahamTheDev

3 words worth a billion dollars: Drift to Determinism (DriDe)

GrahamTheDev — Sat, 07 Mar 2026 10:44:43 +0000

I doubt I am the first to come up with this concept, but I am probably the first to name it.

Drift to Determinism (DriDe - as in "DRY'd" - Don't Repeat Yourself) is what everyone will be doing in 2 years, and I am telling you to start today.

And if you want the one liner explanation: I am proposing that while most people are trying to add more AI and then guard it, instead we should be building systems in a way that we write AI out of them entirely / as much as possible over time.

Ok smart boi - what is Drift to Determinism?

Well it isn't the long awaited second instalment of Fast and The Furious 3 (sadly - but that would be an awesome title right?).

No it is a philosophy on how you should be thinking about AI.

Everyone is out there using AI agent systems and burning tokens like they are going to run out one day.

Watching people spend $20 to set a reminder to buy milk just hurts my soul (yes, really, that happened...the heartbeat every 30 minutes to check the time was eating tokens!).

I believe we will wake from this fever dream soon where "all things are solved with AI" and realise there is a simple flow that will make us able to do almost anything, at a fraction of the cost and environmental impact.

Simple steps:

Give the AI agent system a "novel" task it hasn't seen before and let it burn a load of tokens to solve it.
Put a second agent system at the end watching what could have been worked out deterministically (i.e. in code).
Build the tools for the repeatable parts.
Next time a similar task comes along - feed the tools in at step 1.
See if we always use tool1 and feed it to tool6 - wire them together.
Repeat the process until you write out every part of the AI that is possible.
There are loads of little nuances like falling back to AI if a tool doesn't give the right output for this job, running shadow versions of workflows to check we are actually improving, providing final output feedback to fine tune, producing a system that the LLM can understand, full tracking of the process...but you can work that out right :-)

Over time your AI powered non-deterministic workflows that cost $50 to run and only work 50% of the time without you side-prompting it back on track become glorious automations that use $0.02 in AI to categorise them and then just run in code.

It's faster, it is more consistent, it can be trusted.

This is where we are headed.

Yeah, people are building skills and tools, what is new here?

That is the point - we already kinda have the things we need to make this work, but fundamentally miss the mark on how we treat them.

Nobody, and I mean nobody has the objective to write AI out of a process they are currently doing with AI.

You name me one tool / product that has used AI less in the last year.

Go on, I am waiting.

And yet that is actually what I am proposing.

You use AI to get the outline of a process down. It is expensive, slow (in comparison to code) but it solves a repetitive business process problem.

Then, you analyse that process. Do I really need to pass all 12000 rows of our company client list into AI to know who to call next? Nope, simple tool to grab the next 5 people not called in a month.

Do I even need to give that tool to the agent? No, I should make it part of context so that it has that info and we save a load of round trips.

Hang on a minute, are we giving the AI a tool to then go look up their website? Well if it needs that info we should just do that automatically and feed that into the context.

Hang on a minute, we have scanned their website before? We have the info? Do we even need the agent to fire up at all?

You get the idea.

Crystallisation is the key

Every time you call an AI you roll the dice - quite literally.

It has gotten a lot better, but it is and will always be a non-deterministic system. It will always give different output no matter how hard you prompt it.

Sometimes you need the power of AI - for example to process natural language (or do you)?

Or to write code (or do you?)

Every time you call AI, question how much of it needs to be done fully autonomously using a LLM and how much is a deterministic step.

Writing code - well we have every code snippet in the world available, every challenge can be broken down into code that already exists and has been battle tested. We just need to wire it up differently.

So should we be letting AI write the code, or give it code we know works and ask it to wire it together to solve a novel problem?

Processing natural language? Well we have had code based tools that can do 70% of the work a LLM can do - why not get them to do a first pass and find the areas to focus the power of an LLM at, reducing context size, cost and chance of missing key bits?

CRYSTALLISE your process. Make it as deterministic and repeatable as possible.

Sounds like a lot of work

Well, yeah, kinda.

There is certainly a capability gap at the moment where LLMs are decent at spotting where to optimise a process, but not creative enough to work out which bits are best to work on.

It still needs human judgement and guidance (hurrah - we are still safe for now!).

But it can certainly look at what it did and then give you areas to poke at.

It can certainly then take your judgement and offer possible solutions.

All it needs your grey matter for is what to work on, which way to approach it and how specialised or generalised to make a function / step.

Once you have built enough of these tools (skills, MCP, workflows, whatever) then you can teach it to build its own workflows.

You then become the judge of the workflows, rather than the judge of individual parts.

My prediction

In 2-5 years you will be sat at your terminal with a novel problem for your business. We need to reconcile the bank automatically for accounting.

You explain the desired outcome, provide examples of good and bad results, the data etc.

AI will look at all its tools and build you a workflow to achieve this. It doesn't have all the tools it needs yet so it still uses vision models, LLMs that are good at categorising etc.

You will run it in test mode, work with the AI to adjust it for edge cases and then run it. It does the job, you push it to "shadow mode" and run it alongside the current process.

Now it starts optimising itself out of the process.

It builds out individual parsers for every supplier's invoice format using OCR and pattern matching, running in milliseconds on each invoice. It pulls the bank feed back and checks the amount against the invoice, all in code, the LLM doesn't even fire up, except to kick off the "reconciliation flow".

It works just as well as the current process with 99%+ accuracy as we are using deterministic steps for 99% of the workflow.

3 months later one of the documents we feed in changes format - the tensorflow OCR tool fails to find the invoice number. It falls back to a vision model that locates the new location of the invoice number. Prompts you "hey, looks like supplier X's invoices have changed format - is this the right number" showing you a screenshot of the invoice and a highlight around the relevant items.

You tell it it is good to go and it self heals and runs off to complete this months bank reconciliation.

Compare that to how we would currently envision doing it: a call to a vision model for every single invoice, provide the LLM with a tool for that. Then we give it a tool to read the bank transactions - sending private data out to the cloud. Then it confuses an invoice number for a account number, asks for help, we prompt it and it updates it's instruction set, only to fail again on the next invoice.

It is costly, slow, error prone and although it is better than our old fully human process, it is nowhere near ideal.

How I think of LLMs

Every single token output by a LLM is a point of failure.

Even if we get LLMs to 99.999% accuracy (which would be amazing right?), if you had a workflow that had 10000 passes how accurate would your output be?

No not 99%, it would be 90%. (0.99999^10000 is 90%)

*90% accuracy is business destroying: you are getting sued or going bankrupt. *

But if you build your LLM system with a single goal for the LLM: "make yourself obsolete" - then you can flourish.

You can remove all of the mundane from the business, all of the human effort going into busy work.

The LLMs give you the power to reduce the cost of building automations to 1% of what they used to cost to implement.

Small businesses can out-compete the big players with agility on a scale never seen before.

But only if their systems are robust.

So, are you building a Hallucination Factory or a Deterministic Dynamo?

Are you building a token incinerating, dice throwing monster?

Or are you building a streamlined, bullet-proof replacement for inefficiency?

Probably somewhere in-between, but if your guiding principle in everything you do is DriDe - then as you Drift to Determinism and Don't Repeat Yourself you will gain an edge.

You will have a sharp surgical tool automating key workflows while your competition is bludgeoning their process into submission and veering towards a disaster.

The reduction in costs, the increase in certainty, the avoidance of lawsuits - all from 3 words must easily be worth a billion dollars.

Let DriDe guide you to success, start the drift today.

Mean Time to Understanding 🤔: The Irreducible Human Element in the Age of Infinite Code 🤖.

GrahamTheDev — Sun, 21 Dec 2025 22:06:39 +0000

This article (talk) is based on an idea I have been thinking about for a while: while everyone is talking about AI, either from a hype perspective or a doomsday perspective...where is the middle?

Who is actually looking at the practicalities of AI, the gaps we have in organisations, and, above all, the human aspect of the new Intelligence Age?

So bearing in mind that it is written as a talk, please enjoy my partially formed idea (that needs some editing) as I think the key point of the talk: that understanding code is the new metric we should be paying attention to, is an important one.

The talk (draft):

The Inflation of Syntax

“In the age of AI, the most dangerous engineer in your organisation is no longer the slowest one. It’s the fastest one.”

The engineer who can ship features at incredible speed.
The team with the highest velocity.
The dashboard that looks green every sprint.

These are not as fantastic as they may first sound.

In a world where code is cheap and infinite, speed no longer tells you whether you’re winning. It tells you how fast you’re accumulating something you may not be able to understand, fix, or control.

But I will come to that.

First, lets look at what software engineering used to be, and what has just fundamentally changed.

For 50+ years, everyone in this room was paid to know a secret language. We were paid to know the dictionary. We were paid to speak "Machine."

If a business leader wanted a feature: a new checkout flow, a search bar, a data pipeline, they had a problem. They had intent, but they didn't have the syntax. They needed us to translate their human intent into Java, into SQL, into React. We knew how to say things to machines that other people couldn't.

And because that skill was scarce, we charged a tax for that translation. That tax justified our salaries, our timelines, our agile rituals, and entire careers.

But something fundamental has shifted. Today, the machine speaks its own language. The dictionary is public. The translation tax is rapidly approaching zero.

I want to be clear: this doesn't mean software engineering is done. But it means the most visible part of our historical value, the part that people could see and appreciate - the actual act of turning English requirements into syntax - has been commoditised.

The obvious question we have to answer today is: If coding is no longer scarce, where does the value now lie in software engineering?

The Crisis: Inflation and The Efficiency Trap

I hear a lot of fear about "replacement." But what we are facing isn't a crisis of replacement. It's a crisis of inflation.

Think about basic economics. When you print too much money, the value of the currency drops. When you print code (which we can now do at almost infinite scale) the value of writing a line of code drops.

We are moving from an era of scarcity to an era of abundance. And this leads to the biggest mistake I see companies making right now.

I call it The Efficiency Trap.

Executives look at this abundance and think: "Great! If AI makes developers 50% faster, I can fire 50% of them and get the same output." (For those of you questioning that statement: that line was written by ChatGPT. It’s confident, crisp, and perfectly wrong. A 50% productivity gain means you fire a third of your team, not half. It ties in with the rest of this talk beautifully, so I left it in.)

But AI over-confidence aside: This thinking is fundamentally wrong. Executives see the short-term gain, but they’re blind to long-term complexity.

Abundance hides risk.

Each additional line of code, each new microservice, each new integration can quietly accumulate complexity faster than anyone can track it. The system may appear healthy. Dashboards may look green. But underneath, fragility grows.

This is where instincts betray us. We look at this explosion of output and think we need to measure it harder. Track it more closely. Optimise it more aggressively.

In the AI era, velocity is no longer a leading indicator. It’s a lagging one.

But worshipping at the altar of velocity metrics will ultimately be your downfall.

When you optimise directly for speed, you inflate complexity. When you optimise for understanding, for truly knowing what you’ve built and how it behaves, the system flows naturally, and velocity emerges as a by-product.

Teams that focus only on output will eventually stall, not because they’re slow, but because they are afraid to touch what they’ve built.

If you think maintaining your current legacy code is hard, wait until you have to maintain the mountain of code your team is about to generate.

The Pivot: Mean Time to Understanding

In any system, value always shifts to the constraint. If writing code is cheap, abundant, and fast... what is the new bottleneck?

The constraint is no longer writing software, it is understanding what was written.

The constraint is knowing what this generated blob of code actually does, where it behaves, and more importantly, where it misbehaves.

We need to stop obsessing over velocity and start obsessing over MTTU: Mean Time to Understanding.

DevOps and SRE teams have long used this term to measure the gap between an alert and a diagnosis; it is time the rest of us adjusted and adopted it for the code itself.

MTTU in the context of a developer is the time it takes a human being, who is not the original author, to confidently answer two questions:

What does this code actually do?
Where would I look in order to fix it if it breaks?

Here’s the kicker: if you optimise for MTTU...if you design systems and teams to maximise understanding...everything else follows. Velocity, reliability, maintainability, all of it improves naturally.

If you ignore understanding and chase output alone, the system will eventually stall. Not because you’re slow, but because complexity has grown faster than anyone can reason about it.

Every architectural decision you make from now on either compresses MTTU or inflates it.

The ability to quickly understand and verify code you didn't write, this is the skill that is the new core skill. This is where seniors have transferable skills in this new age.

Your years of pattern recognition, your mental models, your hard-won judgment actually pays dividends.

The AI can generate infinite solutions, but you are the one who can look at those solutions and understand what they actually mean for your system.

But with that in mind, let's look at why this metric and principle is so important.

The Diagnosis: Plausible Competence

The first problem is counter-intuitive. The problem is not that AI is bad at coding. The problem is that it is good. AI is good enough to be plausibly competent.

AI is not a junior developer. AI is an infinite yes-man. It biases toward creation.

It will always give you something.

If you ask an AI to solve a problem where the correct engineering answer is "don't write code, just change this config file," the AI will rarely tell you that. It will write you a 500-line script and bypass the config.

It builds what you asked for, not what you meant.

It produces code that looks correct. It uses the right libraries. It follows the right indentation. It might even pass the unit tests (that it wrote for itself of course).

If you've read Thinking, Fast and Slow by Daniel Kahneman, then you know about System 1 (fast, intuitive) and System 2 (slow, deliberate) thinking and the problem with this plausibly competent code will be familiar to you.

AI-generated code is good enough that it activates our System 1 thinking. We glance at it, it looks like valid code, the logic looks good at-a-glance, and we nod. "Looks great."

But this is the trap. We trust the plausibility, so we turn off our brain.

We stop simulating the code in our head. We accept the solution without stepping back to verify if it fits the nuance of our specific system. We never engage our slow and deliberate thinking.

And because we trust it too easily, we let it do things we would never let a human do. Which leads to the second trap.

The Trap: Complexity Sprawl

Here is how this behaviour shows up in the real world:

Imagine a team asks for a simple feature. Let's say, a web form to submit a username and an email address.

In the old world, a developer would groan, write a single file, hopefully a little validation logic, and ship it.

But now? The developer asks the AI to "handle the submission robustly."

The AI scaffolds. It generates a separate microservice for validation. It adds a retry queue for failed submissions (because queues are "robust"). It spins up a serverless function to sanitise input. It adds a distributed logging service just for completeness.

Technically? All of it works. Syntactically? It is perfect. But here is the trap.

AI is a Local Optimiser.

It looks at the ticket "make the form robust" and it solves that specific problem with maximum force. It doesn't care about the rest of your system.

That is your job. You are the global optimiser. You are the architect.

Your job is to know how that form fits into the user session, the billing system, and the legacy database.

But because the AI just generated five new services and three queues, it has created a complexity spike. To judge if this solution is correct, you now have to load all that new complexity into your head. You have to map out the failure modes of five services instead of just one file.

This is cognitive bloat. And this is where the danger lies.

When the solution becomes too complex to hold in your working memory, you stop verifying the architecture. You stop asking "Does this fit?" and you start accepting "It works."

You surrender your role as architect because the blueprint just became too messy to read.

The Constraint: Architectural Verification

This brings us to the hard limit. The limit isn't how fast we can write code. The limit is Serialisation Bandwidth.

To be the architect, to ensure a solution is safe, compliant, and correct, you must be able to serialise the logic into your brain. You have to be able to "run" the system in your mind. If I change X here, does it break Y over there?

We now have infinite generation bandwidth (the AI) feeding into fixed serialisation bandwidth (your brain).

Serialisation bandwidth is your brain's ability to hold the system in memory. No matter how fast AI types, if your mind can't trace the logic, the system is unsafe.

Now, the AI worshippers and optimists in the room (and the vendors selling you AI tools) will say: "That's fine! We'll just give the AI the context. We'll feed it the docs. We'll prompt it better."

This is the most dangerous lie in our industry right now. You cannot prompt for context you don't know is relevant yet.

Context in software is not a static database you can just upload to a vector store. Context is dynamic.

You don't know that the "User" object has a hidden dependency on the "Billing" object in another project until you see the specific way the code tries to mutate it. You don't know that this specific retry logic violates a new compliance rule until you see the queue being built.

Context is the collision between the code and the World.

The AI only sees the code. You are the only one who sees the real-world context.

If you cannot understand the code faster than it is created (and you can't), you lose the ability to spot those collisions. You lose the ability to govern the system.

The bottleneck isn't typing speed. The bottleneck is architectural verification speed.

Good vs Bad Velocity

And yet, look at our Jira boards. We still measure progress using Velocity. Features per sprint. Tickets closed. Lines shipped. That mismatch is how we manufacture cognitive debt.

In the new World: "Good velocity" is shipping features while keeping Mean Time to Understanding flat. "Bad velocity" is shipping features by spiking MTTU.

If you ship a feature in four hours using AI, but it takes three days for a senior engineer to understand how to fix it when it breaks next week, then you MTTU is way higher than your code velocity.

If your MTTU is too high, then you are in cognitive debt.

And this debt doesn't just stay in code. It leaks.

It shows up as:

Longer incidents (because nobody knows where the root cause is).
Slower onboarding (because new hires can't read the map).
Feature paralysis (because everyone is afraid to touch the "magic code").

To further illustrate this, let me ask you something:

How many of you have merged a PR in the last month that you didn't fully understand?
Keep your hand up if you told yourself you'd come back and review it properly later.
Keep your hand up if you actually did.

Yeah. I didn’t do it either!

This is why we need a new protocol.

The Protocol: Spec-Driven Development

Don't worry. I am not talking about waterfall here with specs...just in case you were about to zone out!

So far I've told you what's broken and why. But I don't want you walking out of here just feeling anxious. I want you to have a protocol you can use tomorrow. So let me get specific.

We have to change the protocol.

We need to move to AI and MTTU friendly Spec-Driven Development.

In this new world, we don't start by reading code. We start by establishing the structure.

This happens in three distinct layers:

Layer 1: The Micro-Spec (Human Priming and Map)

This is your survival tool. This is what keeps you sane day-to-day. It is strictly for you.

It is the "Cognitive Handle." Before you generate a single line of code, you define the high-level intent in your head (or a sticky note).

Goal: "Add a user archive feature."
Constraint: "Must be reversible."
Architectural Fit: "Does this belong in the User Service or the Admin Service?"

The Micro-Spec is your "BS and bad-fit Detector."

It allows you to look at the AI's output and instantly answer: does this code fit the shape of our system? Does this code look to have the functionality we asked for?

If the AI tries to rewrite the database schema for a simple UI change, the Micro-Spec tells you to reject it immediately.

Layer 2: The Main Spec (The Shared Contract)

This is what keeps everyone aligned.

Once you know the shape of the code, you need the substance.

This is the Main Spec. This is the document that both you and the AI rely on.

For the AI: It is the instruction manual. It contains the acceptance criteria, the specific edge cases, the input/output definitions.
For You: It is the checklist for Technical Verification.

After the AI generates the code (and you fix the obvious bugs), you switch from "Architect" to "Auditor." You compare the code against the Main Spec.

"Did it handle the null case we asked for?", "Did it implement the specific retry logic we defined?". You verify the Technical Requirements here.

If the Micro-Spec checks the Soul of the code, the Main Spec checks the Body.

Layer 3: The Global Context (The Subconscious)

This is your evolutionary system, this is what makes you faster over time. Finally, we have the force multiplier.

As we build, we will notice that we keep repeating certain instructions: "Use Tailwind." "Don't use ‘any’ types." "Follow the Repository Pattern."

We don't put these in every Spec. We offload them into Global Context.

This is where tools like CLAUDE.md files or .cursorrules files come in.

We treat these files as our Evolutionary Rule Set.

Every time the AI makes a stylistic mistake, we don't just fix the code. We update the Global Context. We add a rule.

Over time, this automatically pulls the AI closer to your engineering culture.

As this Global Context matures, the machine becomes an expert at your patterns. You will spend drastically less time reviewing syntax, imports, and folder structures.

So where does that saved time go? It goes to the one thing that can never be put into a context file: The ambiguity of the real world.

No matter how well the AI knows our codebase, it doesn't know our strategy. It doesn't know that the marketing team just changed the launch date. It doesn't know that the users hate that specific modal.

You stop being the Code Reviewer and start being the Reality Reviewer.

The Micro-spec is the soul, the flavour of the code.
The Main spec is the body, the substance of the code.
The Global Context is the subconscious, the guiding principles of the code.

But even with all that, you may be wondering where you are still valuable once the prompts and context are nailed down? What can humans do, that AI is very unlikely going to be able to do for the next 20 years?

The 3 Human Moats

Once you accept that role shift towards orchestration and evaluation, the "Prompting" argument dies completely. The AI cannot replace you, because the AI cannot cross these three Moats:

Moat 1: The Shadow Architecture (Context)

The AI suggests a solution based on the visible code. You reject it based on the invisible reality.

Example: The Load-Bearing Typo.

The AI scans your API and finds an error message: “Err (500)”. It suggests a "Best Practice" improvement: "Let's make this closer to common terminology: Internal Server Error (500)."

It is better DX, more descriptive and a better fit with industry terminology.

But you know the World Context. You know that the Ops team has a legacy monitoring script that greps the logs specifically for the string “Err (500)”. If it sees that string, it automatically restarts the server.

If you let the AI "fix" that message, the grep fails. The auto-restart fails. And the next time the server hangs, it stays down all weekend (or until you get a call to fix it...AI isn't going to get the call now is it?).

The AI sees the Text. You see the real world dependency. You cannot prompt for the bash script running on a server the AI doesn't know exists until it becomes relevant.

Moat 2: The Problem Definition (Value)

The AI answers the prompt exactly. You answer the implied need.

The business asks for "fast search."

The AI spins up Elasticsearch for real-time responses, costing thousands.
You know that "fast" just means "under one second," and a simple SQL query works for free.

With AI you are not doing less engineering, you are doing higher-order engineering.

Moat 3: The System Pessimist (Side Effects)

The AI is a master of the Local Fix. If you show it an error, it will make that error go away. It will write defensive code. It will catch the exception. But it is blind to Systemic Side Effects.

It fixes a database timeout by adding a retry loop.

It doesn't know that three layers up, the frontend also retries, and the load balancer also retries. It fixed the error locally, but it just created a Retry Storm that will take down your entire platform during the next traffic spike.

The AI looks at the file. You look at the blast radius. Your job is to ask: "If this code works perfectly, what else does it break?"

But this higher order engineering is not something you learn in bootcamps, so where do Juniors fit in to the new world?

The Junior: The Explorer

If you’ve been following along and you're early in your career and you're worried...good. That means you're paying attention. But here's what you need to understand: AI doesn't make you obsolete.

It makes you dangerous. *Seniors are constrained by their mental models. They know what "should" work, so they'll ask the AI to build the obvious thing. *

You don't have those priors yet.

You can ask the AI to try five different architectures in an afternoon without cognitive baggage. You're faster at exploration because you have less to unlearn.

And that brings me to a question the C-suite and hiring managers may still be asking: *why hire Juniors at all? If AI acts like a mid-level developer, why pay a human to learn? *

Because AI is an engine, not a driver.

The value of a Junior today is not "Code Production." It is Option Generation and Verification.

In the old world, if we weren't sure how to build a feature, we sent a Senior to prototype it for three days. That was expensive.

Now, we send a Junior. We say: "Here is the Spec. Use the AI to prototype three different ways to solve this. Map the trade-offs. Test the edge cases. Bring me the best one."

The Junior provides immediate ROI because they act as a Force Multiplier for the Senior.

They wade through the AI's hallucinations. They verify the libraries. They filter out the noise. They present the Senior not with blank text files, but with curated options.

(Metaphor): The Junior explores the AI jungle, mapping the paths the machine might take, bringing back the safe trails for the Senior.
They are valuable today because they do the legwork of exploration, allowing the Senior to make the high-leverage decision of selection. And in doing that work, they learn the judgment required to become Seniors.

The Senior: The Orchestrator

And the seniors in the room? You are the Orchestrators. You define the constraints. You decide where complexity is allowed and where it is forbidden.

You audit the seams where code touches other parts of the code base.

You ensure that while the AI writes individual notes, the melody remains coherent.

(Metaphor): Each AI-generated line is an instrument; only the Senior ensures it plays the right melody. You are the only one who can see the whole symphony.

The Conclusion: The Great Filter

I want to close by addressing the elephant in the room.

We have established that AI provides infinite Generation Bandwidth.
We have established that humans have fixed Understanding Bandwidth.

There is only one way to resolve that equation. It is not to read faster.

It is not to just "hire more people." The only way to survive is to become The Great Filter.

*In an era where adding code is free, the most expensive thing you can do is accept it. *

The highest-value engineering activity is no longer creating software. It is rejecting software.

If you cannot say no to code, you are no longer an engineer in this new intelligence Age. You are a deployment pipeline with a salary.

Your value is looking at a "working" solution from the AI and saying: "No. This spikes our Mean Time to Understanding. Delete it. Simplify it. Do it again."

We need to slow down the ingestion to match the speed of our digestion.

We need to be the ones who say: "Just because we CAN generate a microservice for this in 30 seconds, doesn't mean we SHOULD."

Your job is to stand in front of the floodgates, to control the flow, to direct it safely, to ship with care and precision.

In a world where code flows like a river, your responsibility is clear: Hold back the tsunami of code. Don’t let complexity and cognitive debt engulf and overwhelm your system.

Don't just build the software. Be the only reason the software is still understandable.

You are the great filter: AI might be able to generate endlessly, only you can decide what survives.

Today your career is no longer defined by how much you ship. It is defined by how much complexity you refuse to ship.

Be the constraint.

Protect your team's Mean Time to Understanding.

Thank you.

As I said, the talk needs some editing and polish, but I hope the theme and concept is thought provoking. I hope the message is clear.

Our role is evolving, but not so much that all of your skills are obsolete. Just that you might need to spend a little less time on leet code and a little more time on architecture and getting better and more diligent at reviewing code.

That you should be optimising for Mean Time To Understanding when you commit your code (or that generated by AI).

Let me know if you think this would make an interesting talk, or if you would be doom scrolling X in the back?

DOOM...rendered using a single DIV and CSS! 🤯🔫💥

GrahamTheDev — Sat, 10 May 2025 08:12:01 +0000

For clarity, I have not rebuilt DOOM in CSS...yet.

No this is far simpler:

rendering the output of DOOM
into a single div
using a single background-image: linear-gradient block.
all client side in the browser!

Is it silly? Yes

Why did I do it? I take it you have never read my articles before, I do silly things with web technologies to learn things...

Why should you read this nonsense? - well you get to play DOOM rendered with CSS for a start!

But seriously, the code can show you some interesting things about interacting with WASM and scaling an image from a <canvas>.

I also deep dive into averaging pixel values from a 1D array, so if that interests you, that might be useful too!

Oh and a huge shoutout to Cornelius Diekmann, who did the hard work of porting DOOM to WASM

Anyway, enough preamble, you are here to play "Doom in CSS*"

Doom rendered in CSS

On mobile, controls are below the game, for PC controls are explained in the pen.

You have to click on the game before input is recognised

(Also if you are on PC clicking the buttons below the game will not work, they are mobile only).

Note: codepen doesn't seem to like this on some devices, you can play it on my server instead if that happens: grahamthe.dev/demos/doom/

So what is going on here?

It just looked like low quality Doom right?

BUT - if you dared to inspect the output you probably crashed chrome...

You see, we are doing the following:

Getting the output from doom.wasm and putting it on a <canvas> element.
We are hiding the canvas element and then using JS to gather pixel data
We take that pixel data, find the average of every 4 pixels to halve the resolution.
We then convert those new pixels to a CSS linear gradient.
We apply that linear gradient to the game div using background-image: linear-gradient

A single linear gradient generated is over 1MB of CSS (actually 2MB), so sadly I can't show you here what it looks like (or on CodePen!) as it is too large!

And we are creating that 60+ times a second...web browsers and CSS parsing is pretty impressive to be able to handle that!

Now I am not going to cover everything, but one thing that was interesting was turning the <canvas> data into an array and then getting pixel data for rescaling, so let's cover that:

Simple way to get average pixel colour

I had an issue.

Rendering the game in CSS at 640*400 made Web browsers cry!

So I needed to downscale the image to 320*200.

There are loads of ways to do this, but I chose a simple pixel averaging method.

There are some interesting things in the code, but I think the resizing function is one of the most interesting and may be useful for you at some point.

It's especially interesting if you have never dealt with an array of pixel data before (as it is a 1D representation of a 2D image, so traversing it is interesting!).

Here is the code for grabbing the average across pixel data for reference:

function rgbaToHex(r, g, b) {
  return (
    "#" +
    [r, g, b].map((x) => Math.round(x).toString(16).padStart(2, "0")).join("")
  )
}

function averageBlockColour(data, startX, startY, width, blockSize) {
  let r = 0, g = 0, b = 0;

  for (let y = startY; y < startY + blockSize; y++) {
    for (let x = startX; x < startX + blockSize; x++) {
      const i = (y * width + x) * 4;
      r += data[i];
      g += data[i + 1];
      b += data[i + 2];
    }
  }

  const size = blockSize * blockSize;
  return rgbaToHex(r / size, g / size, b / size);
}

This averageBlockColour function is useful if you ever want to do simple image resizing (for a thumbnail for example).

It is limited to clean multiples (2 pixel, 3 pixel block size etc.), but gives a good idea of how to get average colours of a set of pixels.

The interesting part is const i = (y * width + x) * 4

This is because we are using a Uint8ClampedArray where each pixel is represented by 4 bytes, 1 for red, 1 for green, 1 for blue and 1 for the alpha channel.

We use this as we need to move around an array that is in 1 dimension and grab pixel data in 2 dimensions.

Pixel data explanation

We need to be able to move around in blocks to average the colours.

These blocks are X pixels wide and X pixels tall.

This means jumping past the rest of an images row data to get the second (or third, or fourth...) rows data as everything is stored in one long line.

Let me try and explain with a quick "diagram":

Image (3x2 pixels):

Row 0:  RGBA0: (0,0) RGBA1: (1,0) RGBA2: (2,0)
Row 1:  RGBA3: (0,1) RGBA4: (1,1) RGBA5: (2,1)

Array data:   [ RGBA0 | RGBA1 | RGBA2 | RGBA3 | RGBA4 | RGBA5 ]
Image pos:      (0,0)   (1,0)   (2,0)   (0,1)   (1,1)   (2,1)
Array pos:       0-3     4-7     8-11   12-15   16-19   20-23

So now you can see how each row of our image is stacked one after the other, you can see why we need to jump ahead.

So our function takes:

data: our array of pixel data,
startX: the left most position of the pixels we want data for (in 2 dimensions)
startY: the top most position of the pixels we want data for (in 2 dimensions)
width: the total width of our image data (so we can skip rows)
blockSize: the height and width of the number of pixels we want to average.

If we wanted to get the average of the first 2 by 2 block of pixels here we would pass:

data: [ RGBA0 | RGBA1 | RGBA2 | RGBA3 | RGBA4 | RGBA5 ]
startX: 0
startY: 0
width: 3
blockSize: 2

Within our loops we get:

//const i = (y * w + x) * 4;

  const i = (0 * 3 + 0) * 4 = start at array position 0: RGBA0
  const i = (1 * 3 + 0) * 4 = start at array position 12: RGBA3
  const i = (0 * 3 + 1) * 4 = start at array position 4: RGBA1
  const i = (1 * 3 + 1) * 4 = start at array position 16: RGBA4

Which is pixel data for:
(0,0, 1,0)
(0,1, 1,1)

Then if we want to get the average of the next 4 pixels we just pass:

data: [ RGBA0 | RGBA1 | RGBA2 | RGBA3 | RGBA4 | RGBA5 ]
startX: 1 <-- increment the start by 1
startY: 0
width: 3
blockSize: 2

Within our loops we now get:

//const i = (y * w + x) * 4;

  const i = (0 * 3 + 1) * 4 = start at array position 4: RGBA1
  const i = (1 * 3 + 1) * 4 = start at array position 16: RGBA4
  const i = (0 * 3 + 2) * 4 = start at array position 8: RGBA2
  const i = (1 * 3 + 2) * 4 = start at array position 20: RGBA5

Which is pixel data for:
(1,0, 2,0)
(1,1, 2,1)

Now we have the raw pixel data

The rest of the process is easier to understand

We have some RGBA data for a pixel - which might look like [200,57,83,255].

We just add up the values of each part:

  r += data[i]; //red
  g += data[i + 1]; //green
  b += data[i + 2]; //blue
  //we deliberately don't grab the "a" (alpha) channel as it will always be 255 - the same as opacity: 1 or non-transparent.

Once we have done this for our 4 pixels (our 2 loops for y and x) we will end up with a total R, G and B value for those 4 pixels (y is 0 and 1, x is 0 and 1 in the first instance and y is 0 and 1 and now x is 1 and 2 in the second instance).

We then just take the average of them:

  const size = blockSize * blockSize; // (2 * 2)
  //               avg red,    avg green,  avg blue
  return rgbaToHex(r / size,   g / size,   b / size);

And then we pass it to a function that turns variables of red, green and blue into a valid hex value.

function rgbaToHex(r, g, b) {
  return (
    "#" +
    [r, g, b].map((x) => Math.round(x).toString(16).padStart(2, "0")).join("")
  )
}

Let's break this down into steps:

Start with a #
Take each of the R, G, B values in order and do the following:
- Round the value (as we had averages and we need integers)
- Convert the raw value to hexidecimal (0-9A-F to change the string to base16)
- make sure that smaller numbers (0-15) are padded with a 0 so we always get 2 digits for each of the R, G and B values (so we always get a total of 6 characters(
- join the R, G and B hex values together.

So if we had [200.2,6.9,88.4] as our R, G and B values we would get:

A = 10, B = 11, C = 12, D = 13, E = 14, F = 15

- Start -> "#"
- 200.2 -> round (200) -> (12 * 16) + 8 = C8 
- 6.9   -> round (7)   -> (0 * 16)  + 7 =  7
- 88.4  -> round (88)  -> (5 * 16)  + 8 = 58
- Pad   -> C8, 07, 58
- Join  -> #C80758

And there we have it, R200, G7, B88 is hex code #c80758.

That's a wrap

There are some really interesting parts around sending commands to WASM applications in there, I would encourage you to explore those yourself, along with the super interesting article by Cornelius Diekmann on porting DOOM to WASM I mentioned earlier.

If you found this article interesting (or distracting...haha) then don't forget to give it a like and share it with others. It really helps me out!

See you all in the next one, and have a great weekend

VibeScript - GenZ programming language

GrahamTheDev — Wed, 16 Apr 2025 08:08:39 +0000

SOLID? DRY? Those days are passed old man.

If your code isn't a mood, then why bother coding at all?

Modern software isn't built on frameworks and design patterns, it is built with prompts and vibes.

To facilitate this shift to a new normal in coding and update out-dated practices we built VibeScript.

VibeScript

The worst part of coding? Syntax...and actually learning how to code.

Who has time for that nowadays while trying to get Insta-famous?

That is no longer a problem with VibeScript.

Example code

VibeScript["🤖"]("create a login form that points to our database to authenticate the user")

VibeScript["🤖"]("If the use put the right password in, let them see the dashboard. This page should be a twitter clone with all functionality")

And with just those two lines we have a twitter (X) clone.

Go build!

How does it work?

LLMs of course!

At the moment we use Claude because it can use tools...and that slaps! (we are still working on how to use tools, we need to learn about something called schemas because Claude still uses old-school coding principles and that just sounded boring, so we took a break. For now just use our VibeScript["🛠️"] command)

What is the secret sauce?

Now we aren't going to show you all our code, but here is about 70% of it.

import OpenAI from "openai"
const client = new OpenAI()

async function chat(fn) {
    return async (...args) => {
        const software = await client.chat.completions.create({
            model: "gpt-4.1",
            messages: [
                {
                    role: "user",
                    content: "You will return code" + args[0],
                },
            ],
        })

        //the magic part
        eval(software)
        return fn(...args)
    }
}

const VibeScript = new Proxy(
    {},
    {
        get(target, prop) {
            if (prop === "🤖") {
                return chat((text) => chat)
            }
            if (prop === "🛠️") {
                return chat((text) => chat)
            }
            //not sure why but I had to return something, so we will just tell the user thinking until they get bored.
            return "thinking..."
            // Gemini said we don't need the next line
            //throw new Error(`No AI function defined for: ${String(prop)}`)
        },
    }
)

The secret is a super clever piece of engineering on our part, eval.

It let's us instantly run the code the LLM returns. Why other people aren't doing this I have no idea?

From this you can build anything in just a couple of quick chats.

We still aren't sure how that proxy thing works exactly, but Grok told us that we need it so we can use emojis to call our AI.

We needed emojis as otherwise the vibe wasn't right and our code wouldn't run as we wanted it.

Documentation

We don't need docs, our system is so intuitive.

Just call VibeScript["🤖"](<\anything you want to build/>)

That is it (except for tooling)!

Will you implement MCP, A2A?

We understand the need for tools to access your database. But MCP and A2A are just too complicated and ruined the vibe.

Instead just use VibeScript["🛠️"]

Here is an example (don't forget to pass in your database root user and password as we haven't built an AI database yet so you will have to use old-school):

VibeScript["🛠️"]('If a user wants some data from our database, please do whatever the user asks for. You can access the database with user: root, password: ""')

This will then connect to your database and do whatever it is databases do to return data.

Don't worry about security, LLMs are not allowed to do anything bad.

What will you build Vibe?

So what are you going to vibe into existence?

With no complicated tooling we can't wait to see how many of our customers become the next Zuckerberg or Musk!

WAGMI!

This post is satire. I shouldn't have to say it but...vibe coders, you know?

Please know that if you are using LLMs to learn how to code, explain how code works, discover new things, I am 100% behind it. Just don't over-rely on them and take the time to start learning how things work rather than just trusting LLM code.

And while the above code is dangerous and nonsense, that proxy pattern is pretty cool, so you might learn something from that...maybe? Not even sure if I coded it right because there was no way I was going to actually run it! hahaha.

Oh and while VibeScript["🤖"] will actually run (if my code is right and you swap out the OpenAi call for a console.log or something), don't use emojis for code...I know, such a boomer.

**Last warning: eval...don't use it, just in case you thought "oh that is interesting" and have never heard about it and how dangerous it is.

See you all soon.

Have a Skibidi day, no Cap.

Single div ACTUALLY 3D cube📦 in Pure CSS! (They said it was impossible!)

GrahamTheDev — Wed, 12 Feb 2025 00:19:41 +0000

This seems simple right?

I mean there are loads of 3D CSS cubes using 2 divs, and loads of cubes using one div that are static, so how much harder can it be to do a truly 3D rotating cube in a single div?

Spoilers...a LOT harder!

In fact I asked a few people if they thought it was doable and the answer I got was "impossible", as "CSS just isn't up to it".

Now the thing you have to know is, I like to do "impossible", especially with CSS (as I suck at CSS and it makes me better at it!).

I mean, I have built a CSS only syntax highlighter, did bubble sort in CSS and even built a neural network in CSS.

So surely I can do a CSS only single div 3D cube right?

Well let me tell you, this challenge nearly broke me. I have tried to do this 3 times and failed.

But today, I finally did it.

And I truly believe this may be the single greatest thing I have ever done!

Wanna see it?

Of course you do, it is the only reason you are here right, to see if I am lying?

Well behold the (majesty? chaos?) that is a 3D cube in pure CSS! (be warned, the CSS may break your brain a bit!)

Go on, check out the HTML, JS and CSS tabs!

There is also an interactive demo where you can set the X and Y rotation with sliders at the end of this article

Oh and before you say anything about the JS - that purely sets the rotation position in a way that is cross-browser, we could have used CSS Houdini props to do it without CSS if it weren't for certain annoying browsers.

All it is doing is changing the rotation of the cube using CSS props anyway!

Why was it so hard?

The short answer is with a single div it meant I only had 3 sides to play with (the div itself, and the ::before and ::after pseudo elements.

And in case you didn't know, a cube has 6 sides!

This meant we had to do what seems like a simple trick, work out which 3 sides are facing the camera and show them.

However, anyone who has worked in 3D will tell you, working out which side is facing the camera is not simple.

I mean, it isn't too difficult in code, but in CSS? That is where things get messy!

Let me step you through a few challenges I came across!

1. calculating which side to show

This needed some serious math skills.

Luckily many others before me have worked this one out and I just grabbed some JS and converted it to CSS.

Now there is a fair bit to this, but one of the key things is once you do a load of sine, cosine magic you have the X, Y and Z position of a shape in 3D space.

Getting the X, Y and Z coordinates of a rotated face of the cube

That is what this bit does:

  /* the "normals" for this side, we repeat these for each side but change  the value to reflect it's position in 3D space (so the back is at z = -1, the left is at x = -1 etc.) */
  --normals-front-x: 0;
  --normals-front-y: 0;
  --normals-front-z: 1;

  /* the calculations to adjust the 3D rotation back to X, Y, Z coordinates */
 --front-y1: calc((var(--normals-front-y) * cos(var(--xRot))) - (var(--normals-front-z) * sin(var(--xRot))));    
  --front-z1: calc(var(--normals-front-y) * sin(var(--xRot)) + var(--normals-front-z) * cos(var(--xRot))); 
  --front-x2: calc(var(--normals-front-x) * cos(var(--yRot)) + var(--front-z1) * sin(var(--yRot)));    
  --front-z2: calc(var(--normals-front-x) * -1 * sin(var(--yRot)) + var(--front-z1) * cos(var(--yRot)));      
  --front-x3: calc(var(--front-x2) * cos(var(--zRot)) - var(--front-y1) * sin(var(--zRot)));      
  --front-y3: calc(var(--front-x2) * sin(var(--zRot)) + var(--front-y1) * cos(var(--zRot)));  
  --front-x: var(--front-x3); 
  --front-y: var(--front-y3);
  --front-z: var(--front-z2);  

 /* repeated for each side of the cube */

getting the z-axis position or "dot product"

Then once we have these X, Y and Z positions (relative to us in 3D space) we can get their "dot product" to work out the shapes central Z-position relative to the camera direction.

That is what all this is doing:

/* getting the magnitude of the camera position. It is worth noting that because I use camera position of X: 0, Y: 0 and Z: 1 this is not really needed as --normalised-cam-z = 1 and --normalised-cam-x and --normalised-cam-y = 0, however I left it in for completeness */

--magnitude-cam: sqrt(calc((var(--normals-camera-x) * var(--normals-camera-x)) + (var(--normals-camera-y) * var(--normals-camera-y)) + (var(--normals-camera-z) * var(--normals-camera-z))));
    --normalised-cam-x: var(--normals-camera-x) / var(--magnitude-cam);
    --normalised-cam-y: var(--normals-camera-y) / var(--magnitude-cam);
    --normalised-cam-z: var(--normals-camera-z) / var(--magnitude-cam);

/* getting the dot-product of the camera normals and the sides X, Y and Z positions and adding them up. */
--dot-prod-front: calc((var(--normals-camera-x) * var(--front-x)) + (var(--normals-camera-y) * var(--front-y)) + (var(--normals-camera-z) * var(--front-z)));
/* repeated for each side */

This dot product gives us the distance along the camera's view distance, or the distance along the Z axis (depth).

Ok, now we can start working out where sides show up!

That is a lot of setup, but now we have what we need, a way to see which 3 faces are closest to the camera!

That is what this bit is all about:

  --show-front: Min(1, Max(calc(var(--dot-prod-front) * 100 - var(--dot-prod-back) * 100), 0));
--show-back: calc(1 - var(--show-front));
--show-right-dot: Min(1, Max(calc(var(--dot-prod-right) * 100 - var(--dot-prod-left) * 100), 0));
 --show-left-dot: calc(1 - var(--show-right-dot));   
  --show-right: calc(var(--show-right-dot) * var(--X-Not-between-90-270) + var(--show-left-dot) * var(--X-between-90-270));   --show-left: calc(1 - var(--show-right));

It may not be immediately obvious what is happening here though, so let's break it down.

We take the z-position of the front and the z-position of the back and compare them.

If the front is closer to us than the back (a greater z position) then we want to show that, if the back is closer to us then we want to show that.

So what is all the min max nonsense?

Well we want to convert decimals into a Boolean.

So what we do is:

multiply both numbers by 100 (to ensure that their difference is likely to be greater than 1).
subtract the "front" from the "back" so we either get a positive number or a negative number.
Get the maximum of the two numbers and 0 (so if front - back > 0 we would get a positive number as it is larger than 0, but if the front - back < 0 we get 0 as that is now larger than the negative number)
We then get the minimum of the previous output and 1, this is to cap any positive numbers at 1.

We could do the same with clamp(0, front-back, 1) but for some reason I always end up writing it this way!

We finally have a Boolean!

Phew, that was a lot, but now we have a Boolean value for if the front is closer to the camera than the back and we can then use that in our front/back CSS to move the position of the side:

.cube {
 /* other props */
translateZ(calc(
      (var(--show-front) - var(--show-back)) * var(--cube-size) * 0.5
    ));

So we either get (1 - 0) * 100px * 0.5 (50px) if the front should show and (0 - 1) * 100px * 0.5 (-50px) if the back should show.

We then apply this to the z-axis and as if by magic we can move the front and back of the shape depending on which is facing the camera (as we rotate the shape the dot product will change in such a way back > front and so we switch positions so it is facing us)!

We can do similar tricks for the left / right and the top / bottom, but that one is even simpler as we can move the side by the whole length of the cube:

/* left / right adjustment to move it one cube length to switch sides*/
translateZ(calc(var(--show-right) * var(--cube-size)));

/* top / bottom adjustment */
translateZ(calc(var(--show-top) * var(--cube-size)));

And that should be it right?

Well no, we have a couple of "gotchyas", and that is why this became so difficult!

2. the front and back changing position

This one caught me out!

Because we are using a single div we have a unique problem.

You see, when we move the front / back face position it also moves the position of the left / right position and top / bottom position by the same amount.

This completely breaks everything as we only want the front / back to change position relative to the user.

This is because the ::before and ::after pseudo elements are positioned relative to the main .cube element. The .cube moves, they move.

So we have to account for this in our CSS.

That is why we have two transforms on our ::before and ::after psuedo elements.

transform:
    translate(-50%, 0%)
    /* this transform accounts for the front / back changing position and moves this face by the same amount in the opposite direction so that it stays in the same location */
    translateZ(calc(
      -1 * (var(--show-front) - var(--show-back)) * var(--cube-size) / 2
    ))
    rotateY(90deg)
    translateZ(calc(
      var(--show-right) * var(--cube-size)
    ));

When you see it you think "well that is straight forward", but I had to completely change the way I was rotating and positioning the sides of the cube several times to make it this simple and it really broke my brain as I was trying to visualise it in 3D space (badly! Took me like 10 tries!).

Anyway that fixes that one, we must be done now right?

3. rotation changing left / right and up / down

Nearly, this was the last problem!

Once a shape rotates more than 90 degrees on the X axis (and less than 270 degrees) things break.

This is because of our switching front and back positions and rotation in 3D space meaning that left becomes right and right becomes left.

We have the same problem rotating on the y axis at 90 and 270 degrees, our top and bottom positions change (relative to the front / back face).

This is what this little bit of chaos is about:

  --X-above-90: Min(1, Max(calc(var(--rotX) - 90), 0));
    --X-below-90: calc(1 - var(--X-above-90));
    --X-above-270: Min(1, Max(calc(var(--rotX) - 270), 0));
    --X-below-270: calc(1 - var(--X-above-270));
    --X-between-90-270: Max(0, 1 - Max(var(--X-below-90), var(--X-above-270)));
    --X-Not-between-90-270: calc(1 - var(--X-between-90-270));
 /* repeated for the Y axis rotation */

It let's us calculate if X rotation is between 90 and 270 so we can invert our left / right positions, and the same for our Y rotation so we can invert the top / bottom positions.

That is why we have --show-right-dot and --show-right, we have to apply those transforms:

 --show-right-dot: Min(1, Max(calc(var(--dot-prod-right) * 100 - var(--dot-prod-left) * 100), 0)
    );
    --show-left-dot: calc(1 - var(--show-right-dot));
    --show-right: calc(var(--show-right-dot) * var(--X-Not-between-90-270) + var(--show-left-dot) * var(--X-between-90-270));
    --show-left: calc(1 - var(--show-right));

The key bit is --show-right as we do a branchless if!

--show-right: calc(var(--show-right-dot) * var(--X-Not-between-90-270) + var(--show-left-dot) * var(--X-between-90-270)); is equivalent to:

right(1) * not between(1) + left(0) * between(0) if x is < 90 or x > 270 and our dot product says right should be showing (output is 1).
right(1) * not between(0) + left(0) * between(1) if x is between 90 and 270 and right should be showing (output is 0 - we have swapped right to the left).
right(0) * not between(1) + left(1) * between(0) if x is < 90 or x > 270 and our dot product says left should be showing (output is 0 which is left).
right(0) * not between(0) + left(1) * between(1) if x is between 90 and 270 and right should be showing (output is 1 - we now made --show-right true even though our dot product says left should show).

That is it!

Well almost, it may still be really hard to follow from that explanation.

I find the easiest way to understand is to play!

So here is a demo where you can set the X and Y rotations using sliders and then inspect stuff.

There is also something interesting at the bottom!

Those rectangles in red and green have their margins set by CSS properties we use in the application, so you can see the values change as you move the sliders. If you inspect the shapes and check the margin you can see the value for each property.

show front, show back etc. just move by 300px to the right if they are on (and stay to the left if off).

Have a play with the sliders and see if it all starts to make sense! 💗

The Perceptron! [visually see an AI learn in real time! 👀]

GrahamTheDev — Mon, 03 Feb 2025 17:56:40 +0000

I have read loads of articles on how Machine Learning (ML) models work. They all explain the same things in pretty much the same way.

One thing I haven't found though is the purest form of machine learning.

Machine learning that is so simple that I can visually understand what is happening. An example where I can see a model go from knowing nothing to understanding something, and actually follow along exactly how it works!

I mean, I (kinda) get all the weights, biases etc. I managed to build a neural network (NN) in vanilla JS (and even built a Neural network in CSS 🤯!), but I still couldn't wrap my head around what that actually looked like.

Then I read about "the perceptron" (project PARA), one of the earliest ML experiments from the late 1950s and early 1960s (yes, we have been doing machine learning for that long, in fact since the 1940s!)

This was what I was looking for as this was a machine learning model that used ANALOGUE systems to work, and so had to be simple(r).

And from that simplicity I could finally build what I wanted, a simple model where we could see it learning in real time and, more importantly, understand what is happening as it learns!

If you are inpatient you can skip to the demo, however I would recommend reading about how it works and the rules it uses to learn as that is important to understand what you are seeing!

Shoutout to Welch Labs!

Welch labs did an amazing explainer video on the perceptron, which inspired me to make this article. Some of the screenshots are from the physical perceptron machine they built!

A Perceptron model you can watch learn!

This is what I built (or should I say 03-mini built with a lot of prompting and some hand holding - FYI o3 mini produces some horrible code, but it is impressive as a prototyping tool! Still took about 4 hours to put this example together though!).

Let me explain what you are seeing in that screenshot and then you can have a play with the demo!

Input grid

So the first two boxes at the top are our inputs.

They are two 5 by 5 boxes where you can flip "switches".

A checked box represents a positive voltage, an unchecked checkbox represents a negative voltage.

For our model to demonstrate learning we need a "good" shape and a "bad" shape.

These are our code representation of an input grid of switches, like in this example here where you would manually flip switches each time for a "good" or "bad" shape:

Dials / weights

Below the input grid we have the dials / weights.

In the real world analogue version of this they were physical dials that multiplied the input voltage by the amount showed on the dial.

In our example they are represented by numbers in each box, showing either a positive or negative multiplier.

You will also notice in the screenshot there is a colour on the cell (for a positive we have green, for a negative we have a red) for easier visual distinction (for those who aren't colourblind).

And finally you will notice there is a "+" or a "-" in each box, yet again to show if they are making that inputs signal stronger or weaker.

This is effectively our Neural Network. These are the "weights / biases" you may have heard about in modern neural networks.

If a grid square is positive / green then it is like turning a dial up, and a negative / red grid square is like turning a dial down.

They are a representation of a set of dials that look like this:

Each perceptron's output voltage visualiser

This is just to help us understand what is going on in the model, it is the output of an input multiplied by a "dial".

To explain further let's assume the first dial is set to "+18"

Then let's assume we feed the perceptron a positive voltage (and all inputs are either +10 volts if they are on, or -10 volts if they are off).

That means that this dial would output +180 volts.

Now let's assume we changed the switch (the first checkbox) to "off". Now we would get an output of -180v.

The important part to note is that if this "dial" is negative (say it is set to "-12") then the opposite is true.

If the switch is "on" then we would get -120v output (+10 volts multiplied by -12) and if the switch is "off" then we would get +120v.

Then the way the model works is by adding up all the voltages.

Oh and one last tiny note here, if a dial is "0" then we just output the voltage it received.

The voltage output meter

The voltage output meter is our final output.

It is the result of multiplying the input voltages for each switch (our checkboxes, either +10v or -10v) by each corresponding gain switch and then adding all the results together.

In our perceptron a positive value is meant to be "good", and a negative value "bad". The amount of the voltage does not matter, just whether it is above 0 or below 0.

This represents a voltage meter in the real model:

How the model learns.

So this perceptron model follows some simple rules.

It always starts by feeding it a shape, in this instance our "good" shape, with all the dials / weights set at 0.

Remember that any checked box outputs +10 volts and any unchecked box will output -10 volts.

So if we draw a shape with 4 checkboxes we will get +40 volts from those, but also get -450 volts from all the others (bear in mind that the actual board is 7 by 7 so 49 total on / off inputs.)

So as we have no weightings / adjustments we get a total negative output voltage.

That is the key as then we apply rules on what to do according to that output:

If the correct output voltage should be positive (a good shape) and we get a negative voltage then we turn all of the cells which are "on" up and all of the other cells down.
If the correct output voltage should be positive and we get a positive voltage output - we do nothing.
If the correct output voltage should be negative (a bad shape) and we get a positive voltage then we turn all of the cells which are "on" down and all of the other cells up.
If the correct output voltage should be negative and we get a negative voltage output - we do nothing.

In our model we jump in multipliers of 3. So after one training session we get an output like this:

Why the 49 boxes when our input is only 25 boxes?

This is where the magic happens.

You see if our shape was the same size as our output grid we could argue we are just storing that shape in memory (effectively). The model hasn't learned anything in reality.

So the next thing we do is to move the shape one square to the right and follow the same procedure.

This time (due to our previous step) the model will output a different voltage, because now we have some of the off switches being multiplied by a negative number and giving a positive voltage output, and some of our on switches will have moved onto a negative multiplier and become negative.

So we follow the same rules this time depending on the output voltage.

Then finally, once we have tried all 9 positions for our "good" shape and adjusted the dials for each one we then feed in the 9 positions for the "bad" shape.

At the end of this training the model has learned how to identify a shape. It may not always get it right after one learning pass, but it will eventually get it right after many passes (well, nearly always, there are a couple of shape combinations that will never "settle" on a correct dial pattern).

Ok, so that was a lot of words, not we get to play!

The demo

With all of the above in mind, the demo is below.

BEFORE YOU DO play with it, read the following instructions.

Using the model properly is crucial to making it easy to understand what is going on!

Instructions

Enter a shape in the "good" box and enter a different shape in the "bad" box by clicking on the checkboxes.

Once you have your shapes it is time to train!

Click on the first button "start training".

You will see the system put the good shape in the "dials and weights" box in the top left most position and instantly adjust the voltages according to the rules.

Then it will move the shape to the right one position and follow the same rules (keep an eye on the voltage meter as it moves so you can see if the voltage is positive or negative and how that changes the behaviour).

It will repeat this for 3 column and 3 row combinations so that all possible positions where the shape could be entered are trained upon.

It will then switch the to "bad" shape and follow the same rules (bearing in mind that this time we want a negative output).

When training is complete you will see an alert:

testing the model!

Now you have two options:
Option 1: Click one of the 9 boxes in the "Select Top-Left Position for Testing" box. You will see a modal asking you for which shape to test ("A" is "good" and "B" is "bad").

You will get an alert with the perceptron's guess.

And then you will see the shape rendered on the "Select Top-Left Position for Testing" box, along with the resulting voltage outputs for each dial / switch combination.

Click a few more boxes, choose "A" or "B" to test good and bad shapes and see how often the model gets the guess right or wrong!

This is the best way to understand how the model is working, so do this a couple of times and check the outputs.

Option 2: Let the system test until it find a failure!
If you just want to see how well the model currently does click "Test All".

This will run through all of the shape positions for both shapes and will stop with an error if it guesses wrong (outputs a negative voltage for a good shape for example) and let you know which position it failed at.

Or if you are really lucky it may complete all the checks and you will get a success message!

If it passes then it will correctly identify the shape (Good / A or Bad / B) no matter which valid position you place it in.

It failed

Not surprising, you did one training pass!

Now you could click "start training" again, but that is deliberately slow.

So to speed things up you can click "Self train and test".

This runs through all training positions at 10x speed and then runs tests until it fails on a shape, repeating this process 50 times or until it passes every test!

Once you understand the principles and have played enough with the slow version, click this button and watch how the voltages for each tile change and how it gradually gets further through the tests until it (hopefully) finally passes!

If it doesn't pass try a different shape or press "self train and test" again to run another 50 cycles!

Then once it passes everything try clicking on a few on the "Select Top-Left Position for Testing" squares and trying an "A" or "B" shape.

Pay special attention to the voltages in each box and the dial settings. Notice where the strongest and weakest cells are etc.

I find it super interesting how "easy" it is to understand what is going on!

Codepen Demo

Set the view to 0.5x
using the button at the bottom of the CodePen so it is easier to use

Trying new shapes

If you want to try a new shape or just want to watch it learn from scratch again, just press "reset dials" and all of the dials will return to 0.

That's a wrap

I know that was a lot of words, but I am hoping you find it useful for understanding how a model learns, in it's simplest form.

I found this a lot easier to understand than matrix multiplication and graphs and charts and although it isn't how modern LLMS / ML models work, it is a great way of getting the principles.

Let me know in the comments if you found it useful / helped you understand a little better!

The 🙄 component - now Brits can finally be understood on the web!

GrahamTheDev — Sat, 25 Jan 2025 11:43:45 +0000

I don't think 'Muricans understand our struggle as Brits.

We make a killer sarcastic comment like "I love listicles, they are super useful" and they think we are being serious!

Now most of my European friends will recognise the sarcasm, but as a Brit I do find that my cousins from across the pond struggle with identifying sarcasm, especially in written text.

And the scariest part of that is that they might actually think I like listicles 🤢.

They should make me Prime Minister

Do not fear though, dear reader, I have solved the problem. I will be forever heralded as the saviour of USA-UK relations!

My creation is that ground breaking that I truly believe I would make a better PM than Mr Starmer (although that isn't a high bar to be fair! 😱🤣)!

At the very least I think I am in the running for a Nobel Peace Prize?

Prepare yourself to marvel at the majesty and beauty of the <sarcasm> component!

The sarcasm component

Did you cry?

I know I did when I saw it take it's first breath. The beauty of helping 70 million Brits finally express themselves was overwhelming.

Air quotes in HTML should have been a thing since day 1 of the internet!

It is bad enough I have to write color every day and spell things incorrectly, but I could have easily forgiven that if my needs and those of my fellow Countrymen had been considered elsewhere.

I have finally solved that injustice!

Go forth and multiply

To all my fellow Brits (and other sarcastic so and so's!) - go forth and spread the good word.

Use the component everywhere you can and rejoice in your ability to fully express yourself.

And you can rest assured you can use it without fear as:

It hides the SVGs from screen readers and adds a visually hidden "(sarcasm)" to the end so it is pretty screen reader friendly (open to suggestions on how to improve it though!).
If you remove the rotate(1.5deg) it would be even more accessible FYI.
It will adapt to font sizes and colours so will look ~~ugly~~ great in anything you do.
Comes with my standard 3 year warranty*

* this warranty, as with most warranties, is completely useless as we provide no guarantees either implied or explicit and is included purely for marketing purposes

That's a wrap.

A silly article (as to be expected from me) just to get back into the swing of writing and to say hi.

I hope 2025 is treating you well so far and I look forward to writing some more "useful and well thought out" articles and sharing with you all soon. (see why we need the sarcasm component?)

True Alphanumeric / natural sorting in MySQL - why is the answer always recursion?

GrahamTheDev — Sun, 17 Nov 2024 10:57:26 +0000

Yesterday I attempted to solve alphanumeric sorting in MySQL and failed. (read that article here)

I did get close though and had the right concept, just wrong execution.

Today, I woke up and had an epiphany...recursion.

The problem with recursion is that you have to understand recursion to be able to do recursion...and I don't understand recursion enough to do recursion in MySQL.

However with a bit of Chat Gippity back and forth (by which I mean getting it to write what I asked for, getting back about 25% of what I asked for, fixing it and feeding it into a new chat so it doesn't keep repeating itself for about 2 hours) I got a working answer!

To the point

May I present to you my swan song, my masterpiece, the answer to life itself (ok fine, the only working solution to true alphanumeric sorting in MySQL I have seen).

WITH RECURSIVE process_numbers AS (
    SELECT 
        data_value,
        data_value AS remaining_data,
        CAST('' AS CHAR(20000)) AS processed_data,
        1 AS iteration
    FROM test_data

    UNION ALL

    SELECT
        data_value,
        CASE 
            WHEN LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data) > 0 THEN
                SUBSTRING(
                    remaining_data,
                    LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data)
                    + LENGTH(REGEXP_SUBSTR(remaining_data, '[0-9]+'))
                )
            ELSE '' 
        END AS remaining_data,

        CONCAT(
            processed_data,
            CASE 
                WHEN LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data) > 0 THEN
                    LEFT(remaining_data, LOCATE(REGEXP_SUBSTR(remaining_data, '[0-9]+'), remaining_data) - 1)
                ELSE remaining_data
            END,
            CASE
                WHEN REGEXP_SUBSTR(remaining_data, '[0-9]+') IS NOT NULL THEN
                    RIGHT(CONCAT('0000000000', REGEXP_SUBSTR(remaining_data, '[0-9]+')), 10)
                ELSE ''
            END
        ) AS processed_data,

        iteration + 1
    FROM process_numbers
    WHERE LENGTH(remaining_data) > 0
          AND iteration < 100
)


SELECT 
    data_value,
    CONCAT(processed_data, remaining_data) AS sort_key
FROM process_numbers
WHERE remaining_data = ""
ORDER BY sort_key;

And if you want to try it out (and try to break it) you can play with this DB fiddle

So how does this work?

It does what I originally wanted to do, take every group of numbers and pads them out to 10 digits total.

So obviously if you feed this a couple of strings with 11 consecutive numeric digits it won't work without adjustment, but other than that it works fine!

You see, MySQL can sort numbers correctly, even in lexicographical ordering mode, but it has one flaw.

It counts "11" as smaller than "2" because of the fact it does sorting one character at a time (effectively). So "2" is bigger than "1" so it comes first. Then it checks the next character, by which point the sorting is incorrect (for numbers at least).

To understand this better, imagine if 1 was actually the letter "b" and 2 was the letter "c".

That is how MySQL "sees" numbers, they are just another character.

So if I had "bb" and "c" you would expect "bb" to come before "c". Now swap the numbers back in and you can see why "11" comes before "2".

So this is a hack?

Yes, we remove the issue by moving the numbers "back" through padding.

Going back to our example, if we padded "11" and "2" to 3 in length and use "a" as 0, this is what happens:

011 = abb
002 = aac

notice how now the sorting would go:

character 1: is "a" bigger than "a" - no, they are the same.
character 2: is "b" bigger than "a" - yes, put the "a" before the "b"
character 3: is now irrelevant and we have already found an occurence earlier that was different and larger.

So by that logic we now have:

002 = aac (the second "a" comes before the second "b" in the next row)
011 = abb

And that is how it works!

Are you going to explain the recursion thing?

Kind of. I have been "round the houses" with this one and my knowledge is surface level, but I will give it a go.

The problem came with how RegEx works in MySQL. REGEX_SUBSTR will only ever find one match and then keep returning that for every other match it finds. So that was why my solution from yesterday was not working correctly.

But REGEX_REPLACE has its own issues where it doesn't seem to correctly expose the string length of a match (so we can't LPAD with it correctly)

That is why I thought about recursion as the answer.

I can use REGEX_SUBSTR to get the correct padding behaviour, and as each loop through the RegEx is essentially a new function call it doesn't "remember" the previous match, so it solves that problem.

And if you want a brief step through of the logic it is actually not as scary as it looks!

We loop over a given string, looking for any numbers (the entire number, not just a single character).
We then remove that from remaining_data so we don't match it again.
We take that number we just matched and pad it out to be 10 digits long total.
We then search for the next numeric part in the string and repeat the process, building up processed_data as our final string.
finally once we have no more numbers to process, we add any remaining letters to the end of processed_data to complete the transformation and we return this as sort_key.

Then we can use this sort_key in our query to order the column correctly.

And the iteration part is purely a safeguarding tool, to make sure it doesn't completely run the MySQL server out of memory or crash the query if a sufficiently complex string is processed (or there is an error in the logic that means it would recurse forever).

That's a wrap!

Isn't it funny how sleeping on things brings new perspective?

Perhaps I should try out polyphasic sleep so I can sleep on problems 2-3 times more often each day and become a 10x developer? haha.

Anyway there you have it, a reasonably robust true alphanumeric sort.

Oh and in reality you should probably convert the sort_key to a stored column on your database using GENERATE or a stored procedure. Sadly the playground I use doesn't seem to support that and it is a Sunday so I will leave that to you, dear viewer!

Have a great rest of your weekend and a great week.

I hope these quick posts don't take off, that feels like a lot of clutter would be created! Also I love that as I type the input box gets 1 px taller per character, that is an amusing bug lol.

GrahamTheDev — Sat, 16 Nov 2024 16:48:38 +0000

Alphanumeric / Natural sort in MySQL - 30 years and we still can't do this? 😤

GrahamTheDev — Sat, 16 Nov 2024 15:23:00 +0000

Our QA team are absolute monsters, they're monsters I tell you!

No matter how much I try to bribe them with drinks at our next company gathering to stop finding bugs in my code, they keep coming up with unreasonable requests and "expected behaviours"...ewwwww, gross!

Don't believe me?

Recently they asked for a list to be ordered alphanumerically.

Can you believe that? Monsters I tell you!

I mean, it isn't like an end user would expect a list to be sorted:

test 1
test 2
test 12

...why can't it just be like MySQL thinks it should be sorted:

test 1
test 12
test 2

Makes perfect sense right? Right?

Anyway lets not get too deep into who is right and who is wrong here (they're right FYI), I thought I better try and fix it.

I mean...how hard can it be? (foreshadowing)

The short answer

I know you might be busy, so the short answer is sort it in JS / PHP / whatever. Don't try and do it with MySQL.

Like seriously, just return your data set and then use Intl.Collator if you are using Node, or natsort() in PHP.

And you know what, that would have been fine. It would have solved the problem and I could have moved on with my day. QA would have been happy, list would be sorted, all good!

However, if you are like me then when your CTO reviews your PR and says:

I take that to heart!

I mean, he is so right!

Why should we have to sort things in code, MySQL should be able to do that for us!

What ensued was over 4 hours of fiddling and swearing to try and get MySQL to bend to my will.

Did I manage it? No...but kinda.

What I ended up with works well enough for user input in our specific scenario, and is much better than other solutions I found, but has it's limitations.

But we are getting ahead of ourselves, I want to show you what is it like trying to solve this in MySQL!

The Data for testing

First thing is first, let's start with the test data I used, just so you can see if I missed anything:

The Test Data

Test Data

INSERT INTO test_data (data_value) VALUES
('2 test'),
('12 test'),
('1 test'),
('20 test'),
('10 test'),
('1test'),
('2test'),
('test 1'),
('my data 2020-01-01'),
('my data 2020-02-01'),
('01-02-24 data'),
('12 test'),
('4a test'),
('my 2020-01-01 data 2020-01-01'),
('my 2020-02-01 data 2020-01-01'),
('my 2020-02-01 data 202-01-01'),
('my 2020-02-01 data 20-01-01'),
('my 2020-02-01 data 1-01-01'),
('my 2020-02-01 data 2-01-01'),
('my 2020-02-01 data 12-01-01'),
('my 2020-02-01 data 01-01-01'),
('my 2020-01-01 data 2020-02-01'),
('my 2020-01-01 data 2021-01-01'),
('my 2020-01-01 data 2120-01-01'),
('my 2120-01-01 data 2020-01-01'),
('4b test'),
('my test'),
('my 12 magic test'),
('my magic 12 test'),
('cheese and test 12'),
('42-a-1'),
('40-a-1'),
('40a'),
('FoClSy4727'),
('Pthw068bf'),
('6bfS'),
('HOFAp_Yx7920'),
('25hWTX'),
('dnjLlW1'),
('RHrIt72402eaLr'),
('cIhb42WFNQ'),
('9244uVCpGa'),
('yDKrkCp7960'),
('GeGIrPM-H86'),
('wrOae537LGCT'),
('WffSPaBA318'),
('kQ33596c'),
('3uEKHmHePf'),
('796h-eYWy'),
('833HufIZAS'),
('utjtV03Xns'),
('dlCSh87811'),
('13IUkOxEVl'),
('VHCok55901XYVk'),
('2RnSVwq'),
('AwtwQdn09'),
('gvSV6z'),
('uxWLO039hb'),
('vTg946');

Some nonsense with numbers in various places throughout the strings, seemed reasonable enough to me.

It is probably not a perfect data set, but good enough for what I was after!

So once I had some data I did what every developer does, asked the Google God for an answer:

Googling for natural sort in MySQL

Seems like the logical first step right?

MySQL has been around for 30 years, and alphanumeric sorting is something you would think people need to do often, so it must have some answers out there already right?

Short answer...it was exhausting. Every single article, Stack Overflow post etc. spitting out the same nonsense that doesn't work or is hyper specific to a particular data format.

I wanted something generic, so I could just sort alphanumerically everywhere!

So let me walk you through the pain I endured so you don't have to, and so you can decide if my answer is any better...or if I have just added to the pain!

Let's try some of the generic sort methods people suggested:

Test 1: the "+0" method

SELECT 
    * 
FROM 
    test_data 
ORDER BY 
    `data_value`+0 ASC

The idea being that it tries to force MySQL to do numeric ordering over lexicographical ordering.

This would work fine if we had numbers or words in each row (the numbers would indeed sort correctly and then the words).

However because we have mixed data, it just spat out a load of nonsense:

Test 1 results

id	data_value
44	GeGIrPM-H86
25	my 2120-01-01 data 2020-01-01
27	my test
28	my 12 magic test
29	my magic 12 test
34	FoClSy4727

Full Results for test 1

id	data_value
44	GeGIrPM-H86
25	my 2120-01-01 data 2020-01-01
27	my test
28	my 12 magic test
29	my magic 12 test
34	FoClSy4727
35	Pthw068bf
37	HOFAp_Yx7920
39	dnjLlW1
40	RHrIt72402eaLr
41	cIhb42WFNQ
43	yDKrkCp7960
30	cheese and test 12
45	wrOae537LGCT
46	WffSPaBA318
47	kQ33596c
51	utjtV03Xns
52	dlCSh87811
54	VHCok55901XYVk
56	AwtwQdn09
57	gvSV6z
58	uxWLO039hb
59	vTg946
17	my 2020-02-01 data 20-01-01
8	test 1
9	my data 2020-01-01
10	my data 2020-02-01
14	my 2020-01-01 data 2020-01-01
15	my 2020-02-01 data 2020-01-01
16	my 2020-02-01 data 202-01-01
18	my 2020-02-01 data 1-01-01
19	my 2020-02-01 data 2-01-01
21	my 2020-02-01 data 01-01-01
23	my 2020-01-01 data 2021-01-01
22	my 2020-01-01 data 2020-02-01
20	my 2020-02-01 data 12-01-01
24	my 2020-01-01 data 2120-01-01
6	1test
11	01-02-24 data
3	1 test
55	2RnSVwq
1	2 test
7	2test
48	3uEKHmHePf
13	4a test
26	4b test
36	6bfS
5	10 test
2	12 test
12	12 test
53	13IUkOxEVl
4	20 test
38	25hWTX
33	40a
32	40-a-1
31	42-a-1
49	796h-eYWy
50	833HufIZAS
42	9244uVCpGa

Ok so that didn't work (and I didn't really expect it to).

Let's try something else:

Test 2: The "length" hack

SELECT 
    alphanumeric, integer
FROM 
    sorting_test
ORDER BY
    LENGTH(alphanumeric), alphanumeric

This is another interesting approach.

obviously "12" is longer than "1" so it would work there.

It also works if you have a standard format for data, like the "test 1, test 12, test 2" I mentioned at the beginning.

However, for our data it returns more nonsense:

Test 2 results

id	data_value
33	40a
36	6bfS
6	1test
7	2test
3	1 test
1	2 test
38	25hWTX
32	40-a-1
31	42-a-1
57	gvSV6z
8	test 1
59	vTg946
5	10 test

Full Results for test 2

id	data_value
33	40a
36	6bfS
6	1test
7	2test
3	1 test
1	2 test
38	25hWTX
32	40-a-1
31	42-a-1
57	gvSV6z
8	test 1
59	vTg946
5	10 test
2	12 test
12	12 test
4	20 test
55	2RnSVwq
13	4a test
26	4b test
39	dnjLlW1
27	my test
47	kQ33596c
49	796h-eYWy
56	AwtwQdn09
35	Pthw068bf
53	13IUkOxEVl
48	3uEKHmHePf
50	833HufIZAS
42	9244uVCpGa
41	cIhb42WFNQ
52	dlCSh87811
34	FoClSy4727
51	utjtV03Xns
58	uxWLO039hb
44	GeGIrPM-H86
46	WffSPaBA318
43	yDKrkCp7960
37	HOFAp_Yx7920
45	wrOae537LGCT
11	01-02-24 data
40	RHrIt72402eaLr
54	VHCok55901XYVk
28	my 12 magic test
29	my magic 12 test
30	cheese and test 12
9	my data 2020-01-01
10	my data 2020-02-01
18	my 2020-02-01 data 1-01-01
19	my 2020-02-01 data 2-01-01
21	my 2020-02-01 data 01-01-01
20	my 2020-02-01 data 12-01-01
17	my 2020-02-01 data 20-01-01
16	my 2020-02-01 data 202-01-01
14	my 2020-01-01 data 2020-01-01
22	my 2020-01-01 data 2020-02-01
23	my 2020-01-01 data 2021-01-01
24	my 2020-01-01 data 2120-01-01
15	my 2020-02-01 data 2020-01-01
25	my 2120-01-01 data 2020-01-01

And that also makes sense, all it is doing is ordering on length first so:

"a1" would come before "1potato" by length.

Test 3: The Hardouken!

Just take a look at this beauty:

SELECT 
    * 
FROM 
    test_data 
ORDER BY 
  REPLACE(
    REPLACE(
      REPLACE(
        REPLACE(
          REPLACE(
            REPLACE(
              REPLACE(
                REPLACE(
                  REPLACE(
                    REPLACE(
                      data_value, 
                      '0', 'Ā'), 
                    '1', 'ā'), 
                  '2', 'Ă'), 
                '3', 'ă'), 
              '4', 'Ą'), 
            '5', 'ą'), 
          '6', 'Ć'), 
        '7', 'ć'), 
      '8', 'Ĉ'), 
    '9', 'ĉ') 
  COLLATE utf8_bin;

The meme is real!

But despite that, this one pretty much works (albeit slightly differently to how I would have done it).

This one is smart in that it replaces each number with a character that will be sorted based on their binary representation in Unicode.

Test 3 results

id	data_value
56	AwtwQdn09
34	FoClSy4727
44	GeGIrPM-H86
37	HOFAp_Yx7920
35	Pthw068bf
40	RHrIt72402eaLr
54	VHCok55901XYVk
46	WffSPaBA318
41	cIhb42WFNQ
30	cheese and test 12

Full Results for test 3

id	data_value
56	AwtwQdn09
34	FoClSy4727
44	GeGIrPM-H86
37	HOFAp_Yx7920
35	Pthw068bf
40	RHrIt72402eaLr
54	VHCok55901XYVk
46	WffSPaBA318
41	cIhb42WFNQ
30	cheese and test 12
52	dlCSh87811
39	dnjLlW1
57	gvSV6z
47	kQ33596c
9	my data 2020-01-01
10	my data 2020-02-01
29	my magic 12 test
27	my test
28	my 12 magic test
14	my 2020-01-01 data 2020-01-01
22	my 2020-01-01 data 2020-02-01
23	my 2020-01-01 data 2021-01-01
24	my 2020-01-01 data 2120-01-01
21	my 2020-02-01 data 01-01-01
18	my 2020-02-01 data 1-01-01
20	my 2020-02-01 data 12-01-01
19	my 2020-02-01 data 2-01-01
17	my 2020-02-01 data 20-01-01
16	my 2020-02-01 data 202-01-01
15	my 2020-02-01 data 2020-01-01
25	my 2120-01-01 data 2020-01-01
8	test 1
51	utjtV03Xns
58	uxWLO039hb
59	vTg946
45	wrOae537LGCT
43	yDKrkCp7960
11	01-02-24 data
3	1 test
6	1test
5	10 test
2	12 test
12	12 test
53	13IUkOxEVl
1	2 test
55	2RnSVwq
7	2test
4	20 test
38	25hWTX
48	3uEKHmHePf
13	4a test
26	4b test
32	40-a-1
33	40a
31	42-a-1
36	6bfS
49	796h-eYWy
50	833HufIZAS
42	9244uVCpGa

You know what, I would use this if it wasn't for one thing. It would mean that we could no longer accept 'Ā' etc as input.

Unfortunately our software will be used internationally, so we can't make that call.

Additionally if you do decide to use this, it is worth noting your database column must use COLLATE 'utf8_bin' on it as well or you may get errors.

Chat GPT Time

When googling fails, chat GPT can always help right?

I am not going to show all the results, but let's just say the following are just a few of the "did not work" ones it produced!

Test 4: GPT fever dream

SELECT
    data_value,
    -- Replace numbers with 'a' and letters with 'b' dynamically
    (
        SELECT GROUP_CONCAT(
            CASE
                WHEN c REGEXP '[0-9]' THEN 'a' -- Replace digits with 'a'
                WHEN c REGEXP '[a-zA-Z]' THEN 'b' -- Replace letters with 'b'
                ELSE c -- Leave other characters as-is
            END
            ORDER BY seq
        ) SEPARATOR ''
        FROM (
            SELECT SUBSTRING(data_value, seq, 1) AS c, seq
            FROM (
                SELECT data_value, seq
                FROM test_data
                JOIN (
                    SELECT n AS seq
                    FROM (SELECT 1 n UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10) numbers
                    WHERE n <= 255 -- Handle up to 255 characters in a string
                ) seq_table
                ON seq <= CHAR_LENGTH(data_value)
            ) char_table
        ) char_map
    ) AS sort_key
FROM test_data
ORDER BY sort_key;

It didn't run, and I couldn't quite work out why, but isn't it impressive looking!

What it seemed to be trying to do was replace all numbers with "a" and all letters with "b" to form strings like "aabaaa, aabba, abbaa" for comparison.

I would have probably spent more time trying to fix this if it wasn't flawed.

"11ab1" would produce "aabba"
"111ab1" would produce "aaaba".

So with the way MySQL sorts, 111ab1 would have been above 11ab1 anyway as "aaa" comes before "aab".

Nice idea, but sadly not quite it.

Test 5: GPT nearly nailed it!

This one surprised me.

I had seen it elsewhere already (as we know GPT is great at just spitting things out that it has already seen and isn't actually creative), but the explanation it gave made more sense!

SELECT 
  * 
FROM 
  test_data
ORDER BY 
  CAST(data_value AS UNSIGNED), data_value ASC;

Ahhhh nearly. I really thought this was the answer.

But sadly it fails on "Test 1, Test 12, Test 2". It is good for sorting if the number comes first though!

My Turn

I still couldn't get what I wanted after several attempts. But I was now much closer to an answer after seeing a few techniques.

After a bit of noodle scratching and crying I thought I had solved it!

It works...kinda!

Here is what I came up with:

CREATE TABLE test_data (
    id INT AUTO_INCREMENT PRIMARY KEY, 
    data_value VARCHAR(255) NOT NULL, 
    transformed_column VARCHAR(255) AS (
        CASE
            WHEN REGEXP_SUBSTR(data_value, '[0-9]+') IS NOT NULL THEN
                REGEXP_REPLACE(
                    data_value,
                    '[0-9]+',
                    LPAD(REGEXP_SUBSTR(data_value, '[0-9]+'), 8, '0')
                )
            ELSE data_value -- Or another default value, e.g., 'No Numbers'
        END
    ) STORED
);

Then we can query it like so:

SELECT 
  *
FROM 
  test_data
ORDER BY 
  transformed_column, data_value;

And this gives us nearly the results we would expect.

Test 6 results

data_value	transformed_column
1 test	00000001 test
01-02-24 data	00000001-00000001-00000001 data
1test	00000001test
2 test	00000002 test
2RnSVwq	00000002RnSVwq
2test	00000002test
3uEKHmHePf	00000003uEKHmHePf
4a test	00000004a test

Full Results for test 6

data_value	transformed_column
1 test	00000001 test
01-02-24 data	00000001-00000001-00000001 data
1test	00000001test
2 test	00000002 test
2RnSVwq	00000002RnSVwq
2test	00000002test
3uEKHmHePf	00000003uEKHmHePf
4a test	00000004a test
4b test	00000004b test
6bfS	00000006bfS
10 test	00000010 test
12 test	00000012 test
12 test	00000012 test
13IUkOxEVl	00000013IUkOxEVl
20 test	00000020 test
25hWTX	00000025hWTX
40-a-1	00000040-a-00000040
40a	00000040a
42-a-1	00000042-a-00000042
796h-eYWy	00000796h-eYWy
833HufIZAS	00000833HufIZAS
9244uVCpGa	00009244uVCpGa
AB-34Y67846	AB-00000034Y00000034
AwtwQdn09	AwtwQdn00000009
cheese and test 12	cheese and test 00000012
cIhb42WFNQ	cIhb00000042WFNQ
dlCSh87811	dlCSh00087811
dnjLlW1	dnjLlW00000001
E5-RMT893Y9	E00000005-RMT00000005Y00000005
EV-489RY3DA	EV-00000489RY00000489DA
FoClSy4727	FoClSy00004727
GeGIrPM-H86	GeGIrPM-H00000086
gvSV6z	gvSV00000006z
HOFAp_Yx7920	HOFAp_Yx00007920
kQ33596c	kQ00033596c
my 12 magic test	my 00000012 magic test
my 2020-01-01 data 2020-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-01-01 data 2020-02-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-01-01 data 2021-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-01-01 data 2120-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 01-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 1-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 12-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 2-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 20-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 202-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 2020-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2120-01-01 data 2020-01-01	my 00002120-00002120-00002120 data 00002120-00002120-00002120
my data 2020-01-01	my data 00002020-00002020-00002020
my data 2020-02-01	my data 00002020-00002020-00002020
my magic 12 test	my magic 00000012 test
my test	my test
Pthw068bf	Pthw00000068bf
RHrIt72402eaLr	RHrIt00072402eaLr
test 1	test 00000001
utjtV03Xns	utjtV00000003Xns
uxWLO039hb	uxWLO00000039hb
VHCok55901XYVk	VHCok00055901XYVk
vTg946	vTg00000946
WffSPaBA318	WffSPaBA00000318
wrOae537LGCT	wrOae00000537LGCT
yDKrkCp7960	yDKrkCp00007960

It breaks on the rows:

data_value	transformed_column
my 2020-02-01 data 1-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 12-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020
my 2020-02-01 data 2-01-01	my 00002020-00002020-00002020 data 00002020-00002020-00002020

As you can see, but overall I think it will suit our needs for now!

This was based on a LPAD example I saw. But it had the same flaw that it only worked on Strings with numbers at the beginning.

So I took that principle and applied it to all number series.

Also this now uses a generated column so that it is fast on reads (although we could soon make it part of the query if it didn't hurt read performance too much or we were more bothered about write performance).

The big issue is the fact that this works through "brute force" by working around the fact that MySQL sees "11" as smaller than "2" due to checking one character at a time (the dumbed down version of what happens) by making all numbers 8 digits long.

It also replaces all numbers in the transformed_column with the first number it finds and as far as I can tell, other than nesting about 20 statements and using coalesce or something, there is no way to avoid this behaviour I could find.

Conclusion

I am not really sure? MySQL should join the 21st century and provide an alphanumeric sort option like other DBs?

While we wish for things to happen I think the short answer in the scope of this article is that I still haven't solved this.

But with that being said, I feel like test 6 is much closer to the answer than anything I found out in the wild and may be useful to someone someday?

Obviously if you are expecting numbers longer than 8 digits, you may want to adjust the LPAD value as that is one limitation.

Also it isn't perfect so you can't rely on it for scenarios other than sorting user input so they can find things easily.

I think at this point my best bet is to throw it out into the world and see if some smarter people than me can solve this thing properly! (I am probably needing some much deeper knowledge of sorting in MySQL to really solve it!)

If someone can solve the problem I have where I can't change every number to 8 digits long, then this would work even better! (so "my 2020-02-01 data 2-01-01" would become "my 00002020-00000002-00000001 data 00000002-00000001-00000001").

Or maybe there is a literal one liner that I missed in all my research that solves this? (I will only cry a little bit if there is, I promise!).

Anyway, that is the best I have, but would love to see something better!

Finally here is a DB Fiddle to play with

Here is a DB fiddle of the generated column version to start from if you think you can spot a quick win / improvement:

https://www.db-fiddle.com/f/o2ohcGVAgHZQg4teg1s9jW/1034

Thanks for reading, catch you all soon!

window.ai - running AI LOCALLY from DevTools! 🤯

GrahamTheDev — Sun, 30 Jun 2024 08:17:39 +0000

On-device AI in the browser is here - kinda.

It is currently in Chrome canary which means, it will be here soon(ish).

In this article I will show you how to get it running on your device, so that you can have a play with it and see what use cases you can think of.

And I will just say this: Running window.ai from DevTools without an internet connection is pretty fun, even if the results are "meh"!

Setup

Getting up and running only takes 5 minutes!

1. Download Chrome Canary

Go to the Chrome Canary site and download Chrome Canary.

2. Enable "Prompt API for Gemini Nano".

Open Chrome Canary and type "chrome://flags/" in the URL bar and press enter.

Then in the search box at the top type "prompt API"

You should see "Prompt API for Gemini Nano" as the only option

Switch that to "enabled".

3. Enable "Enables optimization guide on device"

While you are on the "chrome://flags" page, you need to enable a second item.

Remove your previous search and search for "optimization guide on".

You should see "Enables optimization guide on device" as your only option.

This time you want to enable it, but with the "Enabled ByPassPerfRequirement" option.

4. Install Gemini Nano

Last step, we need to install Gemini Nano on our device.

This is actually part of a bigger tool, but we don't need to worry about that, except for the fact that it helps us know what to download.

Warning: This file is 1.5gb. It doesn't tell you that anywhere so if you have a slow connection / pay per Gb of data / low storage space you may not want to do this!

Head to: "chrome://components/".

Hit Ctrl + f and search for "Optimization Guide".

You will see an item "Optimization Guide On Device Model".

Click "Check for Update" and it will install the file.

5. DONE!

Last step: Restart Chrome Canary for the changes to take effect.

Add that is it, now we can move on to using AI locally!

Using `window.ai`

If everything worked as expected then you should now be able to open DevTools (F12), go to the "Console" tab and start playing!

The easiest way to check is to type window. into the console and see if ai comes up as an option.

If not, go back and check you didn't miss a step!

Creating our first session.

Just one command is needed to start a session with our AI model.

const chatSession = await window.ai.createTextSession()

Tip: Don't forget the await. I did originally 🤦🏼‍♂️!

There is also an option of createGenericSession() but I haven't worked out what the difference is yet!

Now we can use that session to ask questions.

Sending a prompt

For this we just use the .prompt function on our chatSession object!

const result = await chatSession.prompt("hi, what is your name?")

Yet again, all async, don't forget the await (I didn't make the same mistake twice...honest!).

Depending on the complexity of your prompt and your hardware this can take anywhere from a few milliseconds to several seconds, but you should eventually see undefined in the console once it has done.

Getting the response.

Now we just have to console.log the result!

console.log(result)

And we get:

  As a large language model, I do not have a name.

Pretty underwhelming, but at least it works!

Quick and Dirty Reusable example

Obviously you don't want to have to keep sending multiple commands, so you can copy and paste this function into your console to make things easier:

  async function askLocalGPT(promptText){
    if(!window.chatSession){
      console.log("starting chat session") 
      window.chatSession = await window.ai.createTextSession()
      console.log("chat session created") 
    }

    return console.log(await window.chatSession.prompt(promptText)) 
  }

And now you can just type askLocalGPT("prompt text") into your console.

I personally have that saved as a snippet in Sources > snippets for quick access when I want to play with it.

Have fun!

Is it any good?

Really? It isn't any good?

I mean, it depends on the measuring stick you are using.

If you are trying to compare it to Claude or ChatGPT, it is terrible.

However for local playing and experimentation it is awesome!

Also bear in mind that each time you ask a question, it does not automatically have memory of what you asked previously.

So if you want to have a conversation where the model "remembers" what was said previously you need to feed previous questions and answers in with your new question.

Is it fun to play with?

Yes.

The fact I can get it to work locally in my browser is pretty cool. Plus it can do simple coding questions etc.

And the beauty is no big bills! You can use the full 32k context window as often as you want without worrying about racking up a big bill by mistake.

Oh and while I said it isn't very good, it can do summaries quite well:

  askLocalGPT("can you summarise this HTML 
for me please and explain what the page is 
about etc, please return a plain text response 
with the summary and nothing else:" + document.querySelector('article').textContent.toString())

And with a little playing it outputs:

This article explains how to run window.ai locally in your browser using Google's large language model (LGBL).

It describes the necessary steps, including enabling the "Prompt API for Gemini Nano" and "Optimization Guide on Device Model" flags in Google Chrome Canary, installing Gemini Nano, and restarting Chrome Canary.

The article then demonstrates how to use window.ai by creating a text session, prompting the AI model, and receiving the response. It concludes by discussing the possibilities and future enhancements of window.ai.

What will you build?

I have only just scratched the surface of the new API, but I can see it being really handy for creating "custom GPTs" for your own use for now.

In the future once AI is available in-browser for everybody, who knows what amazing things will be created.

Final thought

While I find this exciting as a developer and the possibilities it opens up, there is a large part of me that dislikes / is cautious of this.

People are already throwing "AI" into everything for no reason. Having it run locally on people's machines will only encourage them to use it for even stupider things!

Plus there are probably about 50 other things around security, remote AI farms, etc. etc. that are likely to make me cry in the future the more I think about it.

Video encoded as emojis⁉️ Stored in a DB? 😱🤯

GrahamTheDev — Tue, 23 Apr 2024 08:24:56 +0000

OK, even I think I have gone too far this time!

Can we convert video to emojis (silly) and then save those emojis in a DB (a row per line of "pixels") and serve the "image" from the DB...apparently yes!

Should you do this? No.

Was it fun? A bit.

Will it make you smile? I hope so, it was a little more work than I though it was going to be!

To give you an idea of how silly this was, I had to:

convert a video to frames at a low resolution
read each of those frames and get the pixel data
convert that pixel data into emojis
store those emojis in a DB (Postgres using Supabase)
create a stored procedure to retrieve a frame so I could make API calls in quick succession to play a "video".

There is a lot to unpack here, and some interesting things we can learn along the way, but first...the demo!

Click the big play button in the following CodePen to see it in all of it's glory!

Demo

WARNING: This will use 20MB of data, so if you are on 4G, don't press play if you have an expensive data plan!

The most amazing part of that experiment is the fact that I am calling each frame individually, one after the other from Supabase, pretty impressive latency I have to admit!

More on how I store the data (and how I created it) later.

One last note before the demo

There is a reason we don't store video as emojis, it takes up loads of space.

As the above demo is on the free tier of Supabase it may suddenly stop working as 5GB of egress will only allow the video to be played 250 times before I use too much data!

If you press play and nothing happens, I probably hit that limit, here is a video of what you would have seen:

Interesting parts of this experiment.

*As always, this is not a tutorial. *

But, there were a few interesting things along the way that may be useful for reference:

Converting and storing the data

There were a few interesting things to consider here.

You see, storing pixel data as emojis is not very efficient (I eluded to this early).

So we needed to find a way to minimise the amount of data we stored.

Once I converted the video into frames and down-sampled it I was left with this:

And there were a couple of problems with that.

Removing the black bars.

Ahhh the 80s, where TVs were nearly square and mullets were fashionable.

Unfortunately some things have changed since then.

We now use 16:9 vs 4:3 aspect ratios, which means we have some huge black bars to contend with.

There is no point storing those as emojis.

Now, we will cover retrieving the pixel data later, but all you need to know is I retrieve it a row at a time and loop through each pixel on a row.

So in order to remove those black bars there were many things I could have done here.

But I like simple and my solution was this:

f(pixelCounter > 36 && pixelCounter < 219){
  //do something with the pixel data otherwise ignore it.
}

As my image is 256 pixels wide, I simply skip over the first and the last 36 pixels, so I only process the 182 pixels on each row that have meaningful data.

Is it ugly? yes!

Is it inefficient? Yes!

Does it work? Also yes!

Removing some row data.

The other issue I had was size. (that's what she said...😱)

Even with the black bars removed I still had to store 182 pixels x 144 rows = 26,208 pixels!

The problem with this is that each pixel would be stored as 4 emojis, so we would actually need 104,832 emojis per frame. This was too much!

Luckily the answer was "simple", we are using 4 emojis per "emoji pixel", so we just sample 1 in every 4 pixels.

Now we can't sample every 4th pixel, it isn't that simple. If we did that then we would lose too much information horizontally.

So we actually sample a pixel every 2 pixels, every 2 rows.

So we sample:

- x1,y1
- x3,y1
- x5, y1
...
- x1, y3
- x3, y3
- x5, y3
...
etc.

That takes us down to just 6,552 pixels to sample, and with 4 emojis per pixel we are back at 23k characters per frame. That will do!

encoding the data

The next step is taking that pixel data and converting it to emojis.

Now one way I could have improved this was to take all the emojis and categorise them by colour (closest match to each RGB value).

But that was a little bit too much work for this silly experiment.

So instead what I did was pick just 5 emojis to work with: 🟥🟩🟦⬜⬛

For each pixel we would grab each of the RGB values and then based on the strength, either show a coloured emoji, or a black or white one.

The logic I went with in the end was as follows:

check the red value.
is it greater than 127 (half of 255).
if "yes", then show the red emoji.
if "no", then we show either white or black.
repeat for Green and Blue.

Now you might be wondering, where do we decide whether to show black or white?

We do that by looking at the combined values of R + G + B.

If R + G + B > 500, show the white emoji, otherwise show the black emoji.

This works surprisingly well, for such a simple and "binary" expression of colour.

Putting it all together.

So listen...before I show you this, bear in mind that this is a single use, throwaway bit of code OK.

I don't want you doing a code review on this garbage.

We clear? Good. 🤣

There are a few things I haven't covered that this code does:

loads an image from an image input onto a canvas and grabs the pixel data.
putting image data onto the second canvas (hint Uint8ClampedArray is important for this...I got stuck on that for a while!)
grabbing the image data itself (Another useful tip: image data from a Canvas is stored in a "flat array" in 4 byte chunks, so you have to jump 4 array items for each pixel. e.g. R1, G1, B1, A1 then R2, G2, B2, A2).
builds an ugly INSERT statement to insert our image data into a database table.

Here is an image you can download if you want to test it (as it ONLY works on this specific image size and removes black bars based on these images only.)

And here is a CodePen with the code I used to convert the frames...ugly but it works.

The last part, the database query

Honestly, this part was super simple thanks to Supabase, there are probably only a couple of points worth covering.

Storing and retrieving the data

I decided to make this a little more fun and store each line of pixels as a row in the database.

Which makes for a really fun visual:

The 2 columns we needed to make sure this worked were the frameid column (so we could query all rows for a frame) and the rownum column, so that we can order the rows of the frame.

Then it was as simple as adding a custom function in the SQL editor that retrieved this information:

create or replace function get_frames (frame integer) 
RETURNS table(frametext text)
LANGUAGE plpgsql 
as $$
BEGIN
   RETURN QUERY SELECT STRING_AGG("rowdata", CHR(13)) AS frame
FROM video2
WHERE frameid = frame
GROUP BY frameid
ORDER BY frameid ASC;
end; 
$$;

It might look complicated, but if we break it down it isn't so bad!

create or replace function get_frames (frame integer)

This first part let's us define a reusable function. This is important as we can then use this function as an API endpoint later!

RETURNS table(frametext text)
LANGUAGE plpgsql 
as $$

Here we define the return type. The part in brackets corresponds to the columns we are returning (if we had multiple columns we would set the name we want the column to be called and the type for each).

RETURN QUERY SELECT STRING_AGG("rowdata", CHR(13)) AS frame
FROM video2
WHERE frameid = frame
GROUP BY frameid
ORDER BY frameid ASC;
end; 
$$;

The last part is our SQL query (and returning it as this is a function).

The STRING_AGG function is one you might not be familiar with. All it does is join columns and characters together, so we grab the rowdata data and then combine that with CHR(13) (a new line character) to build our output string.

The important part to make this work though is the GROUP BY statement. Without this the STRING_AGG function won't work as it won't know what data it should aggregate together over multiple rows.

And then we just have ORDER BY - this just makes sure we get each row of data in order so the image makes sense!

Creating our query and API endpoint

The beauty of Supabase is that now we are just a step away from being able to use that function as an API endpoint.

We just need an access policy.

You can find this under "authentication" > "policies" in a project.

Now, I am fairly new to Postgres, but luckily Supabase had a useful template all set up that let me grant Read permissions.

And with that, I can now call that function as an API endpoint!

(if you aren't sure where to get that info, it is in "Database" > "Functions" and you will see a row similar to this:

Calling our API endpoint

Last thing we need, getting our data.

For that we need our SUPABASE_URL and our key (SUPABASE_KEY).

Took me a little while as I was new to Supabase, but they are located under "Project Settings" > "API".

Then all we need is the Supabase SDK (I got it here: https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.42.0/dist/umd/supabase.min.js) and to create a client with

var supabase = supabase.createClient(SUPABASE_URL, SUPABASE_KEY)

Now we are ready to go!

To call an API endpoint you use .rpc.

So my function looks like this:

supabase.rpc('get_frames', { frame: num })
    .then((data) => {
       //do stuff
    })
    .catch((err) => {
      // catch error
    })

Where get_frames is the name of the function I created earlier and { frame: num } is the variable name and the data I want to pass in to the function.

And with that, we are done!

Video, encoded in emojis, stored in a DB, served via Supabase APIs!

Edit / note on performance

As @mattlewandowski93 pointed out, this is inefficient as I am requesting a frame at a time, which creates a lot of network requests.

I wanted to test out Supabase's latency, so it was deliberate.

We could change the function that grabs the frames to look like this:

create or replace function get_all_frames () 
RETURNS table(frametext text)
LANGUAGE plpgsql 
as $$
BEGIN
  --grab current board
   RETURN QUERY SELECT STRING_AGG("rowdata", CHR(13)) AS frame
FROM video2
GROUP BY frameid
ORDER BY frameid ASC;
end; 
$$;

To return all frames at once, saving on network requests.

Then we could render it a lot faster (at the expense of initial load time) as we have all the data at once.

It was a great point that I hadn't explained, so I thought I would include it here to explain why I did it this way.

You might be asking, WHY?

A valid question!

I like to learn through silly things like this.

I never really used Supabase and they asked me if I wanted to write an article for them to celebrate the Supabase launch week.

So I wanted to try them out. (in retrospect, doing something "normal" might have been a better idea so I didn't eat through my 5GB of free egress data, which would be very generous for most applications but not for this! haha).

I am sure when they asked me to write they were expecting a tutorial, or something useful, but we all know I don't do that!

Additionally, I also wanted to learn a little more about the <canvas> element and how to manipulate pixel data, as I have an even sillier idea using that (Doom 3...in the browser...in emojis - yes, I am serious! 🤣).

Anyway, hopefully you learned a little bit too, but if not, I hope you at least enjoyed my silliness.

Oh, and last thing: I rick rolled you, in emojis.

That is a huge W for me and an even bigger L for you I reckon, so that is another reason why I did this! 🤣💗

Have a great week everyone and let me know what you thought in the comments.

DEV Community: GrahamTheDev

3 words worth a billion dollars: Drift to Determinism (DriDe)

Ok smart boi - what is Drift to Determinism?

Yeah, people are building skills and tools, what is new here?

Crystallisation is the key

Sounds like a lot of work

My prediction

How I think of LLMs

So, are you building a Hallucination Factory or a Deterministic Dynamo?

Mean Time to Understanding 🤔: The Irreducible Human Element in the Age of Infinite Code 🤖.

The Inflation of Syntax

The Crisis: Inflation and The Efficiency Trap

The Pivot: Mean Time to Understanding

The Diagnosis: Plausible Competence

The Trap: Complexity Sprawl

The Constraint: Architectural Verification

Good vs Bad Velocity

The Protocol: Spec-Driven Development

Layer 1: The Micro-Spec (Human Priming and Map)

Layer 2: The Main Spec (The Shared Contract)

Layer 3: The Global Context (The Subconscious)

The 3 Human Moats

Moat 1: The Shadow Architecture (Context)

Moat 2: The Problem Definition (Value)

Moat 3: The System Pessimist (Side Effects)

The Junior: The Explorer

The Senior: The Orchestrator

The Conclusion: The Great Filter

DOOM...*rendered* using a single DIV and CSS! 🤯🔫💥

Doom rendered in CSS

So what is going on here?

Simple way to get average pixel colour

Pixel data explanation

Now we have the raw pixel data

That's a wrap

VibeScript - GenZ programming language

VibeScript

Example code

How does it work?

What is the secret sauce?

Documentation

Will you implement MCP, A2A?

What will you build Vibe?

See you all soon.

Single div ACTUALLY 3D cube📦 in Pure CSS! (They said it was impossible!)

Wanna see it?

Why was it so hard?

1. calculating which side to show

Getting the X, Y and Z coordinates of a rotated face of the cube

getting the z-axis position or "dot product"

Ok, now we can start working out where sides show up!

We finally have a Boolean!

2. the front and back changing position

3. rotation changing left / right and up / down

That is it!

The Perceptron! [visually see an AI learn in real time! 👀]

Shoutout to Welch Labs!

A Perceptron model you can watch learn!

Input grid

Dials / weights

Each perceptron's output voltage visualiser

The voltage output meter

How the model learns.

Why the 49 boxes when our input is only 25 boxes?

The demo

Instructions

testing the model!

It failed

Codepen Demo

Trying new shapes

That's a wrap

The 🙄 component - now Brits can finally be understood on the web!

They should make me Prime Minister

The sarcasm component

Did you cry?

Go forth and multiply

That's a wrap.

True Alphanumeric / natural sorting in MySQL - why is the answer always recursion?

To the point

So how does this work?

DOOM...rendered using a single DIV and CSS! 🤯🔫💥

Using `window.ai`