Posts on Gryt

The miracle of AI agent-assisted learning

robin@gryt.io (Robin Penea) — Thu, 02 Apr 2026 17:27:05 +0200

Everybody’s talking about the impact of AI code generation. It’s a big deal. But I found incredible value on the other side: AI assisted learning. Here’s my blueprint.

The situation

There’s a specific category of code where I’m happy to delegate the implementation to an AI: I’m proficient with the language and framework, the feature is well-scoped, edge cases are discussed, and the plan is solid. For any other situation, I strongly disagree with the complete AI delegation. For a toy-project, sure. For a product… Not so sure.

To put it simply: by delegating a non-trivial/non-mastered code, I’m losing touch with the project. More specifically, I cannot feel the rough edges of the structure anymore. Refactoring becomes a prayer to the LLM gods. I hope it doesn’t fuck up, because I won’t be able to unfuck it.

The situation I needed to resolve is the following:

When I’m still actively learning, how can I leverage the incredible power of an AI agent?

This approach emerged over months of learning new languages, tech stacks, and more.

TLDR

You can download the SKILL.md and start developing with this approach by typing:

/guide I want to implement feature X

The setup

I’ll implement an LRU (Least Recently Used) cache in Python to illustrate my approach. Keep in mind that it can be applied to virtually any situation. The setup is the following, in split windows:

Open an AI Agent (Claude Code, Codex, OpenCode, amp, etc)
Open your favorite code editor

In the agent window, write the following prompt:

I want to develop an LRU cache. Your role is to guide me through the implementation.
Let's discuss the plan, I will confirm when it's ready.

### Keywords

**`hint`** — I'm stuck. Give one targeted nudge: a single pointer, help.
Do not review the full implementation.

**`check`** — I want a review of my work on the current step:
1. Read the changed files.
2. Critique: correctness, idioms, edge cases.
3. Suggest specific improvements if needed.
4. If the step is complete and solid: confirm and present the next step.
5. If not: give focused feedback and wait for another `check`.

## Hard constraints:
- **Never write, edit, or create code files** unless the user explicitly asks.
- **Never give a full implementation** unless explicitly asked — guide, don't solve.
- You may read files, search the codebase, and run tests/CLI commands.

I DO 100% OF THE IMPLEMENTATION. The goal of the AI is to provide guidance, not replace me
The discussion of the plan is absolutely fundamental. This improves the quality of the Agent output, and clarifies your ideas. More on this below
I keep the “unless the user explicitly asks” to still delegate some mechanical refactoring
hint and check make it fast to type, and act as checkpoints

The conversation

Here’s what the conversation looked like after my initial prompt (edited for brevity). I intentionally added clarifying questions to show you how we can shape the plan:

🤖 Agent

LRU Cache — Implementation Plan

 Before we start, what language do you want to implement this in?

 ---
 Here's the plan we'll follow. Review and confirm:

 Step 1 — Data structures: hashmap for O(1) lookup + doubly linked list for usage order. Define Node and LRUCache with sentinel head/tail.
 Step 2 — List helpers: remove(node) and insert_front(node).
 Step 3 — get(key): hit → move to front + return value. Miss → return -1.
 Step 4 — put(key, value): update or insert at front; if at capacity, evict the tail sentinel's predecessor first.
 Step 5 — Edge cases: capacity 1, key overwrite, get after eviction.

 ---
 Does this plan look good, or do you want to adjust anything (language, structure, scope)?

👨🏻‍🦱 Me

I will do the implementation in Python. We can use dict for the hashmap, but what could we we use for the doubly linked list?

🤖 Agent

Python doesn't have a built-in doubly linked list, so you have two options:

 1. Roll your own Node class — [...] gives you full control.
 2. Use collections.OrderedDict — it hides all the interesting mechanics.

 For learning purposes, I'd recommend option 1. It forces you to implement the list operations yourself, which
 is the whole point of the exercise.

 Ready to start with Step 1?

👨🏻‍🦱 Me

I’d rather start with collections.OrderedDict to have a good idea of the general shape, write the tests, and then implement the custom Node. We will use those test for non regression. Update the plan.

🤖 Agent

Good approach. Updated plan:

 Step 1 — Implement with OrderedDict

 Build LRUCache using collections.OrderedDict. Methods: get(key) and put(key, value).
 - move_to_end() handles the "mark as recently used" logic
 - Eviction is just popping from one end

 Step 2 — Write tests

 Cover: basic get/put, capacity enforcement, eviction order, overwrite existing key, capacity 1, get after
 eviction.

 Step 3 — Re-implement with custom Node

 Replace the OrderedDict internals with your own doubly linked list + plain dict. The class interface stays
 identical — tests should pass unchanged.

 Step 4 — Verify non-regression

 Run the same test suite against the new implementation.

 ---
 Confirm and I'll walk you through Step 1.

👨🏻‍🦱 Me

Plan confirmed. Write it to plan.md with the instructions and checklist that you maintain for each step. Add a notes section that will be updated with learning I had along the way.

🤖 Agent

Step 1 — Implement with OrderedDict

 Create a file lru_cache.py with a class LRUCache that has:

 - __init__(self, capacity: int)
 - get(self, key: int) -> int — return the value or -1 if not found
 - put(self, key: int, value: int) -> None — insert or update; evict LRU if over capacity

 Two hints to get you started:
 - OrderedDict.move_to_end(key) moves a key to the right (most recent) by default
 - OrderedDict.popitem(last=False) pops from the left (least recent)

 Give it a go — use check when ready.

👨🏻‍🦱 Me

check

And repeat until the feature is done!

Unlocking the potential

This approach has several benefits:

You still develop, but the Agent is present all along to guide/respond to your questions.
If the task spans more than a couple of hours, you will likely be interrupted. plan.md is the shared state with the LLM. Resume tomorrow by prompting Read plan.md and let's continue.
You can switch models without starting from scratch.
Commit the plan.md file! When you’re finished, delete it and carry on.
If you start a new feature, reset the context window (/new, /clear or whatever) and start from scratch. Same process.

You absolutely should adapt the plan granularity to your level of proficiency. I identified the following levels:

`Level 1`

You have no idea of what’s going on. You’re discovering something totally new. The best example is when I follow a tutorial, and I’m totally unable to predict what should be done next or how. Here the plan should be very detailed, to guide you almost line by line. It’s OK to be dumb, the goal is to level up.

`Level 2`

You’re starting to feel the direction of the development. It’s still foggy in your head, but there’s something. If the Agent tells you to implement X, Y and you have a (vague) idea of how… Share it with the agent!

To implement X, Y, I’m guessing that I should refactor foo.py and reorder bar(). Is it right?

This is where real mastery happens. Form a hypothesis, test it, reassess. That’s the key to reach level 3.

`Level 3`

Your opinions about what and how things should be done are getting stronger. You start to challenge the Agent’s guidance. This is a great place to be. The plan should start to be more abstract. If it’s too detailed, it will rob you of the hard mental training needed to level up. I’ve found myself discussing on a tangent with the Agent for 2h because I noticed something in the implementation while coding.

If you’re not already a master of the tech, this step is impossible to explore without writing the code yourself.

`Level 4`

The stack is your home. The goal is only to have a copilot to delegate some mechanical tasks, but the implementation is still yours. The plan should only serve as a global reminder, but it should almost fit in your head. The Agent must also have it with plan.md :).

What’s next?

I tested this approach on several topics where I wanted to learn:

Containers orchestration
Learning a new programming language (Zig)
Learning advanced Programming Language concepts: type checker, compilers, etc

It felt like a boon. In a day, I absorbed a week’s worth of Docker Swarm concepts. In a couple of weeks, I was writing idiomatic Zig, something that would have taken months on my own. But the real point is this:

I learned.

I’m now able to understand and do more. The AI only made it possible faster.

I did not delegate the effort of writing, understanding, forming a hypothesis. The Agent gave me instant access to a personalized, always available teacher. And as a teacher myself, this is so gratifying to continue my learning journey.

You can download the SKILL.md and start developing with this approach by typing:

/guide I want to implement feature X

My Favorite (Tech) Talks

robin@gryt.io (Robin Penea) — Fri, 03 Oct 2025 13:19:48 +0200

Watching (tech) talks is a hobby of mine. It puts me in a kind of meditative mood while watching the explanation unfolding.

Here’s a list of my all-time favorite talks. Very few of them are about a specific language / framework. The majority is to make you think and re-assess your mental models.

Updated - 02/10/2025

Updated - 01/03/2021

Here are the new talks (Description in the following tables):

• • •

General

Title	Description
Boundaries - Gary Bernhardt	Thoughts on architecture of a project and how to define the boundaries between modules
Growing a Language - Guy Steel	Deep thinking about the emergence of a programming language and the paradigm that stems from it
Hammock Driven Development - Rich Hickey	How to tackle complex problems
How To Design a Good API - Joshua Block	A gold mine of advices to build a solid architecture
Inventing On Principle - Bret Victor	A complete different take on how programming is a tool to create
Livable Code - Sarah Mei	What does software archicture mean today? What is going with this building metaphore?
Simple Made Easy - Rich Hickey	The difference between simple and easy. Simple can become complexe, easy becomes complicated
The Big OOPs - Casey Muratori	Where does OOP come from? How is it used and mis-used? 2h30, and every minute is worth it
What We Know We Don't Know - Hillel Wayne	We pride ourselves with our “scientific thinking”. We are however deeply driven by beliefs. What works? what doesn’t? What can we really prove?

Low Level

Title	Description
A talk near the future of Python - David Bazley	1h of LiveCoding to build a complete machine, compiled in WASM. Bonkers.
CPU Caches Why it Matters - Scott Meyers	How does the CPU works and how can we leverage its power
Containers From Scratch - Liz Rice	Build Docker from scratch in 30mins in Go to understand what Docker is about
Data-Oriented Design and C++	Technical architecture to yield the maximum performances with your data structures
Dynamic Phase Alignment in Audio - Sander J. Skjegstad	How to compensate phase-shifting when recording 2 mics with incredible graphics
File Pilot: Inside the Engine - Vjekoslav Krajačić	What’s more common than a FileExplorer? Watch and see how incredibly optimized it can get
Indistinguishable From Magic - Todd Fernandez	Todd worked on CPU production and explains the process of building one. So much complexity
JSON Explained - Jesse Wilson	Deep dive on how JSON parsing works and why it works that way

Functional programming

Title	Description
Programming Clojure With Hand Tools - Tim Ewald	An elegant analogy of programming and woodworking. It starts slowly, but so satisfying
Solving Problems The Clojure Way - Raffal Dittwald	3 ways to solve the same problem: procedural, object oriented, functional (written in JavaScript)
Why isn’t Functional Programming the Norm ? - Richard Feldman	History of programming language to understand why the functional paradigm is adopted (or not) by the industry

Fun & Crazy

Title	Description
Art of code - Dylan Beattie	An exploration of every form of art using code. Fractals, music, Conway’s game of life, you name it
Improper Hierarchy - Tom Murphy	This dude reverse engineers a Nintendo console in a peculiar way. Mind blowing.
Wat - Gary Bernhardt	Lightning talk about JavaScript quirkness
How to Hack a Painting - Tyler Hobbs	Mixing art and programming to (re)produce abstract paintings

Non Tech Talks

Title	Description
Creativity - John Cleese	Monty Python’s John Cleese explains how he sees and ritualizes creativity. Fun and insightful
Higgs Explained (CERN)	A multi-part CERN serie that explains the Higgs boson in layman terms
Terence Tao continuing history’s cleverest cosmological measurements - 3Blue1Brown	The famous mathematician Terence Tao explains how we measure astronomical distances
The Craft of Writing Effectively - Larry McEnerney	Mr McEnerney deconstructs the non-fiction writing process to be the most effective
What Bodies Think About: Bioelectric Computation Outside the Nervous System	An incredible biotech talk that explores how the body might be linked to eletrical signals

What Unit Tests tells about Human Nature

robin@gryt.io (Robin Penea) — Mon, 17 Jun 2019 10:35:32 +0100

It’s Friday night. after an intense week of work, you’re about to take off to enjoy your week-end. Your boss storms in the office:

“You’re still here! Great, I need you to add a hot fix in our Phronabulax System. We expect a demo Monday morning very early, everything has to be ready!”

Well. That was unexpected. You know your boss, he/she wouldn’t ask if it wasn’t really urgent. You grumble a bit but still go dig into the code to do the work.

My enthusiasm and fervor to do this on a Friday night cannot be overstated. Thank you boss.

30 minutes later, you commit your work and breathe a sigh of relief. Wait! You completely forgot the tests! You didn’t add a new test covering the modification. There might be unintended side effects. What shall you do?

Without a doubt, you shutdown your computer and leave. This can wait Monday, and the fix was trivial!

Are you a bad developer? An impostor? Nope, I certainly hope not. I think you’re just a Human.

What is a Unit Test?

I won’t delve into the details of Unit Testing, TDD (Test Driven Development) or any purely technical aspect. I’d like to scratch what is hidden beneath Unit Tests. More precisely, what it reveals about us, about our Human Nature.

The formal definition of a Unit test by Wikipedia states:

In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use

As any proper formal definition, it’s absolutely opaque for anyone who doesn’t already know what is a Unit Test.

One might ask “What’s the point of the definition then?”. To look educated and unreachable my dear!

When you ask why the bridge is red and your friend starts explaining.

A Unit Tests is a piece of code that you write that will execute a subset of your real program to verify its behavior.

If I input 5, it should spit "Hello", If I input 42, it should crash, and so on.

I don’t have the time to write tests

And I agree with you, me neither. Writing tests requires time, the structure of the test is a craft in itself. Having a decent test coverage is a real effort. Still, I have a question for you:

Do you test what you develop?

I mean it in the simplest sense: you write some code, run the program and check if it works as intended. Chances are, you are doing it all the time. You might even yell at your computer because the compilation / startup time to test it takes more than 2,4 seconds.

Compilation took 4 seconds, my mug is empty and the Coffee Machine is broken. This is unbearable.

Unit Tests are merely an automated way of doing what you already do by hand. But I understand, it’s time consuming and the feature has to be delivered yesterday. So why write tests?

Human After All

Because you are just a Human! I believe testing reveals something very interesting about us, as Humans: we’re absolutely fallible, and even more while coding.

Don’t believe me?

What is the quality of you work when you slept 3 hours ? When there’s a disturbing noise in the office? When you neighbor keeps chewing that dreadful, juicy candy?

My sleep routine is tight, my work is perfect. Any question?

Let’s assume you always sleep 8 hours each night and that your noise canceling headphones does wonder.

What about that dark corner of the project? The one that makes everyone look at their feet when you need to modify it? It was written ages ago by a dark ninja-shaman on a moonless night? Nobody understands it and even less dares to touch it?

I don't want to make a fix below water level. PLEASE GOD NO!

Yes, it makes you cringe every time you approach it.

That’s exactly why Unit Tests exist: because you’re just a Human. You can be tired, angry, not concentrated. Because you don’t have the time nor the energy, the Unit Test will execute the 526 cases that you don’t want to check yet another time.

Down the Rabbit Hole

What I find incredible is not that the discovery that we are deeply flawed. The Atlantic Ocean could be filled with the ink spilled on this topic for the last 3000 years.

What is amazing is our resourcefulness. As soon as we admit that eating every dish of that damn Chinese self-serve buffet turns us into brainless oysters for the rest of the afternoon, we start constructing countermeasures.

I shall open at the afternoon break. Until then, let me die in my soy sauce.

Unit Test are for me the product of humble yet very sharp minds, who acknowledge their weakness but still want to get the job done, in the best possible way.

See it that way: we are tool builders. We don’t have claws or big furs, so we build tools to compensate. Writing tests is an answer to our daily stupidity.

The Beatitude Of The Fool

When I started doing tests, I was closer to the attitude of the rebel Teenager than the excited newbie: “Yeaaaah! Whatever. I still ship good code. Meh”.

But, as the test coverage grew, I started to notice an interesting pattern:

Customer requests feature X
I implement feature X
I don’t write any test, feeling confident. The day was sunny, my focus was Zen-like while writing the code
I ship the feature X
Customer gets back to me “Thanks Robin! X works great, however Y is broken!”
I’m sorry what? I dig in, and see the regression
I (finally) write a test, the test fails. I fix the bug and ship again

Rince and repeat. That feeling, between the “I’m sorry what?” and the understanding that by simply adding a couple of tests, the bug could have been prevented is priceless. It’s a mix of shame and anger.

After a couple of iterations, I systematically wrote a test for any feature. And that my friends, was a pure Dopamine shot.

We have a great Tests Coverage. The project is bulletproof!

Now, I see my tests as a handcrafted parachute. I can code and feel the bliss of the Fool. I can be Human, stupid, tired, and my tests have my back. Oh, what a feeling!

Side Effects and Cult

A beautiful side-effect of testing your program, is that it puts you in the shoes of the user of your API. You write an incredibly efficient program, great! How usable it is?

Remember, you don’t have the time to write tests, do you think your colleague will have the time to understand your crazy Logorrhea of functions, variables and convoluted classes? Of course not!

Testing gives you a feedback on how your API feels. This is extremely useful, because you won’t be able to know that before having to modify it again.

However, I want to add a big nuance:

Not everything should be tested

You know how it’s called when someone tells you “If you don’t test X, you’re worthless”? Religion Fever.

In my humble opinion, it’s as stupid to refuse to test anything than to insist on testing absolutely everything.

Our brother Robin did not write a test for the project POC-to-be-dropped-and-rewritten-anyway. He shall be excommunicated from the Church Of The Right Software.

Some situations makes the tests impossibly hard to write or maintain.

In many cases, I don’t write any UI test. Why? Because I have a limited time, and I honestly care little about UI testing. It makes perfect sense for huge projects, with very strict UI designs.

I see testing more as a state of mind, a humbling affirmation of our imperfection and a celebration of our imagination to face it.

As with any craft, it has to be practiced and repeated. Sometimes your tests will be useless and badly written. Other times it will fit perfectly to your project.

It takes time, but it’s worthwhile. You’ll thank yourself for doing it, trust me.

Powerpoint and Chickens

robin@gryt.io (Robin Penea) — Thu, 20 Dec 2018 15:32:12 +0100

Do you remember that day — probably a rainy one — when you sat in a conference room? Your heart was filled with eagerness to dive into the speaker’s mind. You even prepared by documenting about the topic, to fully comprehend the genius striding in front of you.

The common purpose

And then, as the drama unfolded in the room and the rain kept pouring outside, this slide came up:

Here's a short summary of my ideas, in 5 small bullet points.

“Oh dear”, you whispered, “Not again… Not this Powerpoint presentation…”. You know it when you see it. The Powerpoint to end all Powerpoints. The one with slides so dense, that a pair of opera-binoculars should be provided on each chair.

The mandatory tool to brain numbing presentations.

Yes my friend, you’re about to spend a long, excruciating hour. You’ll watch the speaker spit 3 zillion data per minute, while your brain turns into a mishmash of tears, agony, and forgotten eastern curses inherited from your mother side. Who would have guessed that these memories could be retrieved? Bonkers!

I call this phenomenon the Chicken Hypnosis, or the Gallus Gallus Apathy — Latin makes things so chic —. We have all seen dozens of Powerpoint presentations where you ask yourself: What is the point of this Powerpoint? To help the speaker or to hypnotize chickens, namely, the audience?

The real purpose

Much ink has been spilled on the Powerpoint issue: Back in 2003, the NASA pointed that Powerpoint makes you dumb, some physicists chose to ban Powerpoint altogether and searching for “Powerpoint hate” on Google yields 24 400 000 results.

But still, (almost) everybody uses a form of Powerpoint to do a presentation. It can’t be for nothing! Indeed, I believe that a Powerpoint has a great purpose: to support the speaker. To provide some anchor, in the turmoil of a long explanation.

A Powerpoint purpose is 2-folded:

Condense information in a digestible format to sum important points
Provide multimedia content to animate the presentation

But, what really matters is the explanation of the speaker. Filling slides up to death is an innocent act of laziness, not malevolence.

How did we get there?

Tool & User

I think Powerpoint is a very efficient tool. Without any prior knowledge, you can put together titles, bullet points and incredible-yet-utterly-useless animations.

However, who is using Powerpoint? For the vast majority, people who are not professional speakers (me too!). They are business men, developers, physicists, or anything that is not directly centered on a Speaker / User Experience. For them, making a presentation is mandated by their job, but they surely didn’t study to do presentations or animate conferences.

Mix the ease of use of Powerpoint with the lack of interest of its users, and you get this new Super-Villain: The Destroyer Of Minds (DOM for the closest friends).

Misuse of the Tool

From here, the resulting presentation has many chances of being failed. We already covered the densely-packed slides, but there’s another killer hiding in plain sight: The lifeless presentation.

Will he finish the talk? Will he jump? Will the restaurant still have my favorite Cheesecake?

Everything feels empty. There can be a lot on each slide… Or not. The speaker is slow and monotonous. Add a last slide, and the abyss will swallow you in the eternal bliss of infinite boredom.

In this case, the Powerpoint has taken the driver seat. The trigger to speak is the “Next Slide Button” — not what the speaker intends to say.

Down the Rabbit Hole

It gets even worse. To be so easy to use, Powerpoint has a killer-feature: The Bullet Point.

It might seem innocuous, but I think it’s exactly the reason for which presentations get such a bad press: it transforms complex ideas into a sequence of bullet points, waiting to be unstacked, one by one.

A presentation can have multiple purposes: make you think, spark a heated debate, provide a different perspective on a known issue.

A set of bullet points is a drowning of creativity. Said plainly, you cannot express complex ideas with bullet points. It’s like describing a car with karate moves: it’s not meant for that.

"Here are the seats, and you can lower the windows like so." — Damn, this picture could almost make the opposite point! Note to self: choose a worse karate picture.

Still, why do we cram so much data in our slides? Because we have the illusion that the audience must know everything. WRONG! 90% of the time, you are presenting your deep work to people who might not have the slightest idea of your passion.

They are just curious / forced to be here / bored / sitting in the wrong conference room.

Oh dear, this is about the Java programming language? I’m just a Peruvian Coffee Beans aficionado!

As you can see, the Abstract Factory Pattern makes it so easy to spawn new objects.

How should we approach it?

You might yell at me:

“Very well then, should I empty my slides? Fill them? Simplify everything? Put only complex diagrams?”

Breath. I understand. You think about that presentation you already hated even before finishing it. We all have been culprit of such an abomination.

I will calmly answer with 2 questions: Who is your audience? What are your constraints?

If you can’t answer, the presentation is already doomed. Call it a day and start doing some improv class, you’ll have better chances.

Is your audience young children, discovering science? International astrophysists waiting for your Boson revelation? Do you have 20 mins or 2 hours? Can you draw something while talking? Is it online or in a real room, with real people?

They told me that it will be in Sydney's Opera with Kung-Fu Senseis. Something's Wrong.

This is going to determine the shape and content of your presentation. Who cares if you used a distributed micro-service architecture if your audience can’t tell the difference between Internet and Google Chrome?

If the answer to these questions keeps Powerpoint in the race, I can see 2 possible presentation general “shapes”.

TBP aka The Big Presentation

You give an important talk, on a topic you have been working on for months / years. By God, reduce the load per slice, add schemas and animations to make it easier to grasp the idea. Yes, use bullets point to sum up and the end of a section, but not to articulate a complex topic.

Your hard work deserves a proper presentation. It would be a shame to flush your years-long sweat in the toilet of “Slides Mediocrity”. Your audience will probably not have the same depth as you do. And if they do, the questions is the perfect time to dig in.

If you already know you’re dealing with specialists, add references, data, but remember: YOU are the reason they’re wasting their life in this small room for an hour. Not your slides. Not your fancy animations.

Machine-gun Slides

If you have (like myself in recent instances) have to produce hundreds of slides on a topic, you have to be efficient rather than beautiful.

Getting your point across without spending 2 hours on each Powerpoint can make a difference. Again, know your constraints and deal with it.

Some people have such a mastery of the content that the Powerpoint becomes a character of the presentation. For example, Larry Lessig, with his “Lessig Method” is known to fire many, many slides for a single presentation. And it works!

A tool — nothing more, nothing less —

Everyone has a love / hate relationship with Powerpoint. In the end, it’s just a tool. Like any tool, it can be properly used and misused.

Because it’s easy to start with, you can dump your Ph.D thesis in your slides. Job done, back to real work. Not so fast!

Your presentation is a part of your work. Don’t spoil it by doing a cheap stunt. You deserve better.

The Gallus Gallus Apathy can, and should be prevented! To arms my fellow Powerpointers!

Powerpoint is a tool, not the tool. When you only have a hammer, every problem looks like a nail.

Surrendering is transforming yourself into a nail, while Powerpoint is happily smashing on you.

Surrendering, is transforming your audience into chickens.

You’re not a Nail nor a Chicken. You’re a Human. Embrace it.

Qt Model / View

robin@gryt.io (Robin Penea) — Thu, 25 Oct 2018 15:00:12 +0200

The Shock

The first time I’ve read the Qt Model / View documentation, I was shocked. Flabbergasted. Blown away. I started with a vague idea of the purpose of the Model / View, and finished convinced that I understood even less. My first implementation of the pattern was an utter failure: it looked like a Frankenstein implementation of a boilerplate code written by a crazy monkey. This was not right, the Qt documentation is known to be of quality — detailed, explanatory and coherent.

After multiple attempts and many hours reading and re-reading the doc, I started to grasp the concept. The deep understanding came when I had to write about this topic. Heck, I’ve written whole chapters on the Model / View!

I entertain myself imagining how this marathon-length documentation came to be:

A Qt framework developer glances over the Model / View documentation and utters to himself “This is not right. It makes no sense at all”. He then pounds on his keyboard in a sweated rush of the documentation-muse inspiration. He looks at his masterpiece and proudly says “It’s now much clearer! Let’s add my stone to the cathedral and update the official doc”.

After several iterations of this episode, the current doc now takes longer to read than The Lord Of the Rings. And boy, it’s a long story! Don’t get me wrong, the documentation is exhaustive in the deepest sense of exhaustiveness. But, it’s also exhausting when you discover the Model / View pattern. The underlying principle is drown in a plethora of details which are useless at the beginning.

This article aims for exactly that, understanding the Model / View pattern with a simple example. I won’t cover all the bells and whistles that you can implement with Model / View.

TL;DR — Show me the code!

You just want the source code to understand all by yourself? Everything is available on GitHub. Don’t worry, it’s less than 150 lines of C++.

The Goal

The goal is simple: build a simple Model / View example of a list of countries. It will be a read-only Model, no editing to keep things really simple (the edition will be covered in a separate post). We’ll display a list of countries and upon a country selection, a country details widget will be updated.

The final Model / View application

A country is composed of 3 pieces of data:

Name
Flag
Capital

The Principle

In my mind, the Model / View has 2 main goals:

Cleanly separate the model’s data source from the display. This makes the update of the data source less prone to impact the View side.
Leverage the Qt signal / slot mechanism to update multiple views from a unified data source.

Here’s a simplified diagram of the Model / View architecture:

Model / View architecture diagram

You feed the Model with your data source. It can be a CSV file, rows from a database query or the result of an HTTP request. The Model name is misleading, it actually handles your model classes. In our example, we’ll create a CountryModel that will be the owner of a Country list. The real data is in the Country class, the CountryModel just loads it and makes it available for potential clients.
The data is provided to the View through the Model. The View can be a Qt type : QListView, or QTableView. It really depends on what your model can offer (rows and/or columns) and what type of display your want. To enforce the separation, the format is completely domain agnostic. Here, there’s no Country class at all, only a generic bundle. We’ll come back soon to this.
The user interacts with the View to produce events — select a row, delete a row, etc. Each event triggers an exchange between the View and the Model. The user wants to delete a row? Tell the Model about it and wait for the result with a slot.

The beauty of this architecture is that it fulfills our 2 goals:

The data source can be completely changed from CSV values to Database queries, the View would not have any idea about it.
Because the Model provides signals and slots, we can even connect multiple Views on a single Model. Each View will connect to the Model’ slots and get any update.

The Model

The code is done inside a Qt Widget project. We’ll start the basic build block — the Country.h class:

#include <QString>

struct Country {
 QString name;
 QString capital;
 QString flagIcon;

 Country(const QString& name, const QString& capital, const QString& flagIcon) :
 name(name),
 capital(capital),
 flagIcon(flagIcon) { }
};

The flagIconis the path to the PNG icon stored in a .qrc file, nothing fancy. The real deal starts with CountryModel.h, the owner of a Country list:

class CountryModel : public QAbstractListModel
{
 Q_OBJECT
public:

 enum CountryRoles {
 CapitalRole = Qt::UserRole,
 };

 CountryModel(QObject* parent = 0);
 ~CountryModel();

 int rowCount(const QModelIndex& parent = QModelIndex()) const override;
 QVariant data(const QModelIndex& index, int role) const override;

private:
 QVector<Country*> countries;
};

Let’s break it down. CountryModelextends QAbstractListModel, which is a kind of Model that provides rows of data. The View displaying CountryModel’s data will configure itself by calling:

rowCount() to measure its widget size according to the number of rows.
data() to retrieve the actual data. It returns a QVariant, the generic Qt union type to transfer data back and forth without being restricted by a strong C++ type.

These functions come from QAbstractListModel, so we have to override them to provide the real data size and content. For our purpose, the data is simply a QVector of Country*.

Now, rowCount() and data() both take a special argument: a QModelIndex. We’ll dive in greater length about this topic in the post about the editable Model / View. For now, just consider it as an opaque object that handles data indexes from the Model’s perspective. To retrieve a Country from countries at a specific index, we’ll do an index.row(). Things get hairy when we update the data — adding, deleting lines — because this will mess up the index. That’s why Qt uses an internal index handler to keep track of what moved with QModelIndex.

Finally, the enum CountryRoles. We’ll skip it for now. It will come to light in the implementation of the function data().

• • •

Let’s switch the CountryModel.cpp, with CountryModel’s contructor & destructor:

#include <QIcon>

CountryModel::CountryModel(QObject* parent) :
 QAbstractListModel(parent),
 countries()
{
 countries
 << new Country("France", "Paris", ":/flags/fr.png")
 << new Country("Great Britain", "London", ":/flags/gb.png")
 << new Country("Japan", "Tokyo", ":/flags/jp.png")
 << new Country("United States of America", "Washington, D.C", ":/flags/us.png");
}

CountryModel::~CountryModel()
{
 qDeleteAll(countries);
}

countries is initialized in the constructor. You can replace it with whatever your data source is: database, CSV file, etc. The country’s icon is a path pointing to a .qrc resource stored in the project. The destructor just cleans up the Country*stored in countries.

The meat of the class lies in the following functions, starting with rowCount():

int CountryModel::rowCount(const QModelIndex& parent) const
{
 Q_UNUSED(parent)
 return countries.size();
}

The function takes a QModelIndex& parent, because you data source could be tree (think of a directory / files structure). Each directory would be a parent, and its size would be different from its neighbors. As our model is a flat list, we can safely ignore the parent and return countries.size().

Next, the implementation of data():

QVariant CountryModel::data(const QModelIndex& index, int role) const
{
 const Country& country = *countries.at(index.row());

 switch (role) {
 case Qt::DisplayRole:
 return country.name;

 case Qt::DecorationRole:
 return QIcon(country.flagIcon);

 case CountryRoles::CapitalRole:
 return country.capital;

 default:
 return QVariant();
 break;
 }
}

So, data() takes 2 parameters:

index to know the index of the requested data — the country index in our case.
role to indicate the type of the data it wants to retrieve.

data() is not called to retrieve a whole row (i.e. a full Country object). It’s called for each piece of data it wants to display. How does it know which piece of data it wants to display? That’s the point of the role parameter! There are predefined roles that can be requested by the View. In a QListView, the content of a displayed row will be Qt::DisplayRole.

First, we retrieve the Country for a given index.row(). Then, the switch(role) { … } block comes into play. if the View want’s to see the Qt::DisplayRole, we return the country.name. If the View wants to see the Qt::DecorationRole (the icon just at the left of the row label), we return a QIcon(contry.flagIcon). Every return value must be able to be converted to a QVariant, this lets data() to have a generic signature.

Alright, the principle seems sound. But what if we want to display custom data? Here, a Country also owns a capital, which could — and will — be used by the View. That’s where the forgotten enum CountryRoles strikes back. Let me avoid you some scrolling:

enum CountryRoles {
 CapitalRole = Qt::UserRole,
};

Here, we defined a custom role, CapitalRole that takes the Qt::UserRole value. Qt::UserRole is simply the starting value (0x0100) for user defined roles. If you have more data to provide in your Model, just continue to add custom roles in your enum.

A last important detail —data() is const. In other words, it cannot changeCountryModel, and can only callconst functions. If you want to generate thumbnails on the fly for a country’s flag, you’re in for a world of pain. By design, the data() functions expects to retrieve const-data and returns a QVariant to be copied by value. There are possible workarounds with a QIdentityProxyModel. If you’re going with QML, the Qt folks were thoughtful with QQuickImageProvider.

The View

The View is straightforward, in a usual MainWindow class, The form looks like this:

UI Form of the MainWindow

On the left, the most important widget is countryListView, a QListView that will display the data coming from CountryModel.
On the right, countryCapitalLabel and countryNameLabel will be updated with the currently selected Country.

The source is short, starting with MainWindow.h:

#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QMainWindow>
#include <QItemSelection>

#include "CountryModel.h"

namespace Ui {
    class MainWindow;
}

class MainWindow : public QMainWindow
{
     Q_OBJECT
public:
     explicit MainWindow(QWidget *parent = 0);
     ~MainWindow();

private slots:
     void onSelectionChanged(const QItemSelection& selected, const QItemSelection& deselected);

private:
     Ui::MainWindow *ui;
     CountryModel countryModel;
};

#endif // MAINWINDOW_H

onSelectionChanged() will be called each time a selection changes on countryListView.
countryModel is the CountryModel member variable that will feed the data to countryListView.

The last piece of the puzzle hides in MainWindow.cpp, starting with the constructor:

#include "MainWindow.h"
#include "ui_MainWindow.h"

#include <QItemSelectionModel>

MainWindow::MainWindow(QWidget *parent) :
 QMainWindow(parent),
 ui(new Ui::MainWindow),
 countryModel()
{
 ui->setupUi(this);
 setWindowTitle("Model / View sample - countries");

 ui->countryListView->setModel(&countryModel);

 QItemSelectionModel* selectionModel = ui->countryListView->selectionModel();
 connect(selectionModel, &QItemSelectionModel::selectionChanged,
 this, &MainWindow::onSelectionChanged);
}

The whole magic happens when countryListView->setModel(&countryModel) is called. Because CountryModel extends QAbstractListModel, this call is generic from countryListView’s perspective. If we decide to update CountryModel to store the countries in a database, countryListView couldn’t care less.

The next lines are here to update our custom country name / capital labels. The selection of a QListView is also handled by a Model, this time it’s a QItemSelectionModel. The implementation of onSelectionChanged() looks like this:

void MainWindow::onSelectionChanged(const QItemSelection& selected, const QItemSelection& deselected)
{
 Q_UNUSED(deselected)

 QModelIndexList list = selected.indexes();
 const QModelIndex& index = list.first();

 QString countryName = index.data(Qt::DisplayRole).toString();
 ui->countryNameLabel->setText(countryName);

 QString countryCapital = index.data(CountryModel::CapitalRole).toString();
 ui->countryCapitalLabel->setText(countryCapital);

}

The parameters selected & deselected encapsulate the current state of the countryListView. From here, we retrieve the currently selected indexes (QListView can support multiple selections). We take the first index, and start working with our now-old-friend, QModelIndex.

To update countryNameLabel, we get the data from the Model, using the index.data() function. Remember CountryModel::data() with the role parameter? Here it is, in all its glory! The returned QVariant is converted to a QString and then passed to countryNameLabel. The same pattern is used for countryCapitalLabel, although we rely on our custom role — CountryModel::CapitalRole — to target the right piece of data.

• • •

As you can see, there’s still no trace of CountryModel around, even though it’s working behind the scene. It took less than 150 lines of C++ code to scaffold a generic data source that can be plugged in a standard QListView. In my humble opinion, it’s quite a treat to achieve this much with so little code.

Again, everything is available on GitHub, go and take a look.

The first time I really understood Model / View like so, I wondered. Is the documentation size inversely proportional to the simplicity of the concept it tries to explain? Is it a just a smokescreen, some kind of conspiration? Is life like the Model / View documentation, so simple and yet so hard to explain?

Going deeper

If you want to dig deeper in Qt, I co-wrote a whole book about the Qt framework, Mastering Qt 5. The Model / View is covered inside out, with the full data CRUD explanation, QML implementation to connect to a Model — it takes 3 chapters to cover the material.

Mastering Qt 5 cover

The book aims to teach you how to be a well-rounded Qt developer. We took our years of experience, frustrations, discoveries and joys about Qt and poured them into these 500 page. We explore the inner working of the Qt signal / slot system, build advanced multi-threaded applications, explain how Qt can work with C++11/14 and much more.