Most of the online educational content was mostly a lazy copy of the docs and did a poor job of respecting the viewer’s time. I felt like something better should exist so I started work on a dead simple resource where a course was just a collection of 3 minute videos so people could learn tools worth learning quickly.

Oh boy, have things have changed in the meantime.

• All of my marketing for calmcode happened on Twitter back in the day. People started sharing and the site grew a lot. Roughly to a million visits after all these years. But Twitter changed and a calmcode update now results in crickets.

• LLMs happened and it seems to have taken over how people do short-term learning. When people have a pressing issue they don’t even go to the docs anymore and go straight for the coding agent. Heck, they may not even read the code much anymore either.

• As a result I wonder how many people are interested in doing the long-term learning for code-related topics. It’s not completely gone, people still sign up for calmcode even today, but it’s way less “interesting for my career” than before.

• Some, but certainly not all, of the tools have started showing their age. We didn’t have uv back we started, and now it’s pretty much the thing that’s replaced all the other things.

This has led to a lot of reflection on my end. What should I do with calmcode?

The simplest answer is that doing nothing is totally fine. Hosting the site is cheap (by design) and I am happy to keep it up if only for the good memories. So many people have reached out to me to tell me how the site has ignited their career, so … as regular calm coders will know … “there is no rush” to change anything.

That said, if I’m honest I should admit that it has become less fun to make content for calmcode. The fact that it’s hard to get people to come to the site is a big part of it. It’s much easier for me to try to make interesting YouTube videos about topics that interest me and to get people to watch that compared to the calmcode site.

So here’s where I have landed: I will merge the calmcode mailing list with my personal substack. Most of my stuff on YouTube is similar in spirit to calmcode anyway, so it feels natural to do. That way I can still update people with interesting content and this won’t required any big changes too.

Speaking of some interesting content: there’s a new AnyWidget tutorial that explains how you can make bespoke widgets for Python notebooks. I’ve also been making a bunch of those widgets and I have some demos of that here. There’s a lot of fun that you can have with these widgets, like what I’m doing here with the McNugget Graph. I also made a video on my new favorite way to share data. So if you want to download some fun old school video game datasets, check here and here.

One final thing: this isn’t me saying that I’ll never do anything on calmcode again. Who knows, if the right collaborators show up I might be open to revamping it. But until then, I’m just going to keep the site up and you can keep up to date with my stuff via substack.

If people want to say “hi” they can certainly do that here.

Either way, I also wanted to say thanks to everyone who tries to code calmly. It always makes my day when people tell me that!

Yours,
Vincent

I recently made a tool called wigglystuff that ships a `Matrix` widget. It behaves like a numpy array but you're also able to change the numbers by dragging them around in the browser. It effectively turns a matrix into something that could be part of an online form. If you combine such a widget with a reactive notebook it's pretty easy to come up with compelling demos!

Here's a demo of a matrix that represents PCA. There's a `n x 3` matrix of randomly sampled colors that I multiply with a `3 x 2` widget that you can control. This means that you're able to map colors unto a two dimensional plane. Here's what that might look like:

If you're good at curiosity, this might trigger some questions.

• When I move the first number in the matrix the points expand. Why?

• When I move the second number ... I introduce an angle away from the x-axis. Why?

The widget is great at the interaction bit, but if you're even mildly curious you'll immediately be able to check your knowledge. And you might bounce into things that you might not have expected.

Let's try one more.

Notice how we get into a perfectly straight line here? Why? There's more than one great argument to be made here: the columns are not independant, but you can also just do the algebra.

But notice how you just bump into great questions by just playing around? You have to be deliberate about it, mind you, curiosity needs to be activate. But when you do, you're really working on some great motivation to dive deep once you've spotted something curious. Playing can be an act to make something interesting that wasn't before. This feels especially for topics like linear algebra. That single matrix has tonnes of applications, and you should feel free to explore them with some deliberate play.

Don't get me wrong, there's loads of great YouTube videos now that will teach you linear algebra too ... but videos are a one way street. All you can do is listen. That's note the same as playing and being an active participant.

tldr

More educational notebooks need to leverage play via widgets. They are a perfect method for deliberate play.

If you're interested in a longer demo, you'll enjoy this YT tutorial that does a deep dive on matrix widget.

And yet, it has a twist that no book talks about.

Model

Typically, when tutorials make a model for the Titanic dataset, you'll see features like the number of siblings, the age, and the passenger class go into a model. It might try a few models and (if they bothered to do cross validation the right way and if they added a dummy model) you'd get a table that looks like this:

You might look at this table and conclude that the boosted model performs best, albeit without a lot of margin from the other models.

But let's now consider a fun twist.

Typically the models would focus on features like age, passenger class, gender, and the amount that was paid for the ticket. But the really interesting thing is that you can get a model that's pretty much in the the same ballpark as far as accuracy goes, but just zooming in on one and only one column.

There is one feature that people forget about ... it's the `name`!

If you make a pipeline with a CountVectorizer, that one-hot encodes every single token in the name column then you get a model in the same ballpark. You could also repeat the same exercise but with an embedding model from sentence-transformers.

The histogram boosting model still performs better, but the fact that name model even gets close ... that is friggin' interesting! It only uses **one single feature**! Turns out the name has ample information, it has a title for a person as well as the gender and maybe the last name is a proxy for wealth.

I never really understood why books would skip this super interesting fact. What if the `CountVectorizer` approach was more accurate? You could easily simulate such a situation by removing a few columns and pretending that those were not available. Would that make the model better? Or would we prefer a model that goes beyond the name?

Reflecting

Honestly, it's kind of bonkers that this dataset became so popular as a tutorial. There's no practical utility for the dataset what-so-ever and it will never be applied for anything. Given ample business cases for these models it makes a lot more sense to focus on those dataset.

That said, There is one final comment worth mentioning with regards to vibe coding and these kinds of conclusions. I imagine that there are many other data sets with a fun twist, and my hope is that vibe-coding can actually help us document these. LLMs are good enough to help you write scikit-learn pipelines for these sorts of small blogposts, so I hope more folks will join me to share more of these data science anekdotes. It feels like they're missing on the internet.

If that sounds interesting, you might enjoy this vibe-coding exercise I did for marimo. We're working on better LLM integration so we're investigating the space while also recording some vibe-coding exercises.

Let's say that I want it to work on a marimo notebook. In that case I want it to make changes to one, and only one, file. But claude's permissions go way beyond that. It can edit any file, and even has access to all the command line tools, including the ones that can rm -rf.

That example is all about removing capabilities, but sometimes I also want to be able to add them. Let's say that I built a custom Python class that knows where to find the right docs and can fetch it in an effective format ... can I add that to claude loop? No! Instead, we are forced to have claude try and search the web, but why are we wasting our tokens on that?!

Enter bespoken

It’s stuff like this where my new tool can help out. For a full demo, you can check this YouTube video:

You can also check the docs for an overview but the main point of the library is to let you write code like this:

You can configure the LLM, but also the tools that it can call. In the above example we constrain the agent by only giving it access to edit one (and only one) file. You’re also able to add tools that only the human can trigger and all custom tools can generate pretty forms from the terminal. It’s at version 0 now, but it comes with enough bells and whistles to make it clear what this framework can become.

Let me know!

I hope this sounds interesting. Feel free to reach out on socials, or leave a message on Github.

When I released it, I hinted Hamel Husain that you could use it to annotate data and that maybe this way people might finally start to look at their data. Don’t just make it easy, make it fun.

Turns out this was a total nerd snipe, and Hamel invited me to talk about it on his live-stream here. The benefit of this first link is that it also has dialogue at the start where I showcase my streaming/work setup but you can also see the more polished demo-recording below:

Announcing molabel

I figured the livestream was also a great opportunity to showcase a new thing that I had been working on: molabel. The library contains an annotation widget that gives you simple labelling interfaces that work straight from your notebook. It works by letting you pass a custom rendering function to for your examples, after which you can attach labels and notes to each. You can use the mouse for this, as well as keyboard shortcuts or a bluetooth gamepad.

This is what the widget looks like:

You create this widget with a call like this:

from molabel import SimpleLabel

widget = SimpleLabel(
    examples=list_of_examples, 
    render=render_function
)

The list_of_examples can be any Python list of things that you would like to render. You'd typically pass a list of dictionaries, but you're allowed to pass whatever you like. The only thing that the widget cares about is that you also pass a render function that can take each example and turn it into something html-like that the widget can render. You could use a string, but any object that has a _repr_html_ would also work. That means that you can also directly use mohtml and FastHTML.

If the widget knows how to render, it can take care of the rest.

The widget will store all the annotations that you generate and you can wire it up in such a way that data is automatically sent to a database on your behalf. If you have a gamepad at-the-ready you can also give this demo hosted on GitHub pages a spin right away. It runs a marimo notebook in WASM on the front-end, so you can give the widget a spin without installing anything locally.

Loads of use-cases are covered

This widget can feel pretty basic at first glance. There's really only a binary "yes"/"no" choice with an extra option to "skip". While it might seem basic, let's take a step back and appreciate what we've already got covered here. As-is, you can use this for:

• binary classification

• multi-label classification (each label is binary, after all)

• the "is this a match?" kinds of queries for retrieval

• comparisons between two choices, one of which is better

Keeping it simple also means less human errors and more labels. I have seen annotation interfaces with 27 classification labels and it's maddening. Having a simpler interface means less cognitive overhead and it will just give you more labels with higher quality.

Not only that, but we allow you to add plenty of context via the textbox too. So if you want to explain why there is an issue with an example, maybe for finetuning an LLM later, that's totally possible here. You could theoretically even use this widget only to add a note to each example, ignoring the labels all-to-gether. Note that you can use the text-to-speech API from the browser for free here, so you could also use your voice while annotating with a gamepad.

Why

I have been telling people to take data quality serious for years now and instead of talking about it I now want to start making tools for it. The focus of these tools will be to make it easy to get started, but also to make it fun. I have *literally* found a way for AI engineers to expense a gamepad for work, so hopefully that alone will be enough to finally get more people to use look at their data.

ps. a final note

Lastly, and this is important, another reason to get excited is that the gamepad is also a great ergonomic device. You can sit in a comfortable chair and use a device that is designed for comfort. I have suffered from RSI in the past and it is something to take serious. I spent over $3000 to figure out what ergonomic boards would work well for me. This led me to start a YouTube channel where I review ergonomic boards and I am looking forward to reviewing devices/gamepads for annotation in the near future.

What follows is an anekdote of a Flask app that was functional, but also kept breaking somewhat randomly. It’s for an app that I do want to release soon, but I had to take a step back and learn something about vibe-coding first.

A Flask app

Imagine that I have a Flask webapp, one that starts like this:

from flask_sqlalchemy import SQLAlchemy
from flask import Flask 

# Init app
app = Flask(__name__)
app.config = {...}

# Init DB 
db = SQLAlchemy()
db.init_app(app)

# Init the rest
...

Then I might also have some tests, these use fixtures and might look a little bit like this:

from app import app as flask_app
from flask import session


@pytest.fixture
def client():
    flask_app.config['TESTING'] = True
    flask_app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///:memory:'  # Use in-memory SQLite for tests
    
    with flask_app.app_context():
        db.create_all()  # Create all tables
        # Create a test user if needed for your tests
        test_user = User(email='test@example.com', is_verified=True, is_paying=False, message_interval_days=7)
        db.session.add(test_user)
        db.session.commit()
        
    with flask_app.test_client() as client:
        yield client
        
    with flask_app.app_context():
        db.session.remove()
        db.drop_all()  # Clean up after tests

This `client`-fixture is used all over the place in the test suite, and what's nice here is that it makes sure that each test starts with a fresh database. This feels good, vibe-coding checks out, so let's move on and have it write some more code.

Odd behavior

What could go wrong, you might ask?

A lot! It's very subtle, but consider the flask app one more time.

from flask_sqlalchemy import SQLAlchemy
from flask import Flask 

# Init app
app = Flask(__name__)
app.config = {...}

# Init DB 
db = SQLAlchemy()
db.init_app(app)

# Init the rest
...

The fixture overrides `app.config` variables, but these changes happen *after* `db` is initialized. So if you accidentally have a `SQLALCHEMY_DATABASE_URI` environment variable pointing to production... the fixture will still use it! And notice the fixture's cleanup code:

    ... 

    with flask_app.test_client() as client:
        yield client
        
    with flask_app.app_context():
        db.session.remove()
        db.drop_all()  # Clean up after tests

Imagine debugging this. Tests don't fail or prevent this - all you see is production user tables drop randomly.

I initially suspected a misconfigured migration. The AI assistant suggested Docker deployment issues. A bunch of time was wasted here.

The fix?

The quick fix, suggested by the bot, after pointing out that `pytest` was the culprit was to add this to the `conftest.py` file:

import os

# This runs before any tests are collected
def pytest_configure(config):
    # Explicitly override DATABASE_URL to ensure we never connect to a real database
    os.environ["DATABASE_URL"] = "sqlite:///:memory:" 

This will prevent the database losing tables when running pytest, but it doesn't address the fact that the project itself needs to be more strict with regards to separating local/production environments.

My conclusion

So who'se fault is it that the setup broke?

It is easy to blame the AI here, but that would be silly. The project was set up in the wrong way because *I did not pay attention to it*. I could have easily been more safe, and pragmatic even, by strictly following two `.env.prod` and `.env.local` files. I could have taken the time to set up the project and get the deployments in order before I even write the app. But I allowed the assistant, and myself, to YOLO around. Unit tests are simply not enough.

So in short, vibe-coding ... it is both extremely impressive and extremely untrustworthy at the same time. It's stuff like the story above, but also things like "forgetting about csrf-tokens" in web forms that constantly reminds me of this. But at the end of the day, the lesson here isn't that "vibe coding sucks", but rather that "you need to get better at these tools if you want to use them".

That means vibe coding defensively, thinking ahead and maybe investing in a solid cookiecutter as a solid starting point. Do that right, and you’ll get more productive for sure now.

ps. Just to give one example of something that I was finally able to wrap up thanks to vibe-coding defensively: you can now use gamepads from Python!

I know this is going down the “probability nerd snipe” territory, but I was wondering how close I could get a Python API to this notation. After all, this is *very* compact compared to any SQL that you might write.

Enter peegeem

I wrote a small library in Python that allows for *exactly* this. Not only does it give you the fancy notation, you're also able to declare the probabilistic graphical model that outlines the causal relationships between your variables.

from peegeem import DAG

# Define the DAG for the PGM, nodes is a list of column names, edges is a list of tuples
dag = DAG(nodes, edges, dataframe)

# Get variables out
outcome, smoker, age = dag.get_variables()

# Use variables to construct a probabilistic query
P(outcome | (smoker == "Yes") & (age > 40))

# Latex utility, why not?
P.to_latex(outcome | (smoker == "Yes") & (age > 40))

It's pretty darn neat! It's really like writing down maths and you get a data-list out with all relevant probability values. But want to know the real kicker? You can use this in a notebook together with some widgets!

Again, it helps to be a probability nerd here, but one clever thing we can do is combine our query ability with the ability to use reactive components and charts. By doing this, you kind of get a domain specific environment instead of just a domain specific language to interface with.

This is super exciting and I hope to work on more projects like this one. If you're keen to learn more, and see an extensive demo, you might enjoy this marimo livestream that I did for it last week.

I'm happy to generate code, but I am unwilling not to learn from it. The other day I vibe-coded my favourite board game for my blog (link) but I was amazed at how the technology was applied. The game involves stacking buildings and I would've assumed that HTML canvas would be required. But Claude was able to do it all with CSS and HTML divs directly. Skipping such lessons would be a waste.

I’m happy to experiment, but I am unwilling to ignore my productivity. It’s really never been easier to write tools for yourself to make your life easier. So maybe you should? I wrote a new backend for my blog in a few evenings and it’s really gotten to the point where I love writing again. I wrote about the new layout here, but I also started working on a system for Python based webcomponents that integrates with the blog. I also made mopaint, which is a widget that looks like MSPaint that you can use from a notebook to draw. All relatively small projects, but huge boost to my productivity!

I’m happy to toy with code, but I am unwilling not to toy with ideas. If implementation becomes easier, maybe we should take more time brainstorming ideas. Instead of thinking “I want to write code that does X for me” you might want to think “What API makes it more enjoyable for me to write code that does X for me?” first. The best example of this has been the smartfunc library that I made that makes it easier for me to interact with LLMs for rapid prototyping. It’s been featured on Simon Willisons blog and also started trending a little bit on YouTube and hackernews.

I’m curious to hear if I’m the only one exploring such boundaries, but can recommend folks to at least consider it. It’s certainly seems to have made me enjoy the ride more *and* more productive.

Jack Conte, of Patreon and Pomplamoose fame, recently stated that “we might be witnessing the death of the follower”. Where from 2019-2023 you would have had a good time on social media by gaining a large following you now need to make sure that you get picked up by the algorithm of whatever platform you are on. In short, that means that the fact that you follow me no longer guarantees that you’ll be able to hear me anymore. It’s a good interview, I can recommend a listen!

Fact of the matter is that a few people started pointing this out to me, asking me if I stopped posting ever since I became a dad, which is not the case. The discovery mechanism of the internet has changed and it seems to favor content that is willing to adapt to the platform. You may have noticed this on YouTube and on LinkedIn. Thumbnails and titles really matter more and posts that share links get downvotes by the algorithm because it leads people off the platform.

In short: it seems like maintaining an email list is pretty much the only way for me to really guarantee that folks can be kept up to date with stuff that I do.

Just to name a few things that I’ve done in the past few weeks.

• I revamped my personal blog by vibe-coding a personal editor in Flask. Details can be found here. It also features a basic RSS feed that people can follow.

• I learned about some CSS tricks while implementing the santorini board game for HTML. Details, and the live game, are on my blog.

• I built a “newspaper” that make summaries of popular hackernews discussions. You can find it on thedailybin.com and you can learn all about how it’s made on YouTube or on my blog. It’s been an entertaining way for me to keep up to date without getting distracted/sucked into a lot of threads.

• I made a new tool that I pretty much use daily called `mohtml`. It’s a library with 50 lines of Python that can generate most of HTML in a functional style. There’s a calmcode course for it and a YouTube deep dive.

• I also made a Python notebook widget called mopaint that allows you to draw images in a MSPaint themed drawing utility. Once drawn, you can use the drawing to pass it forward to other tools. This includes vision models!

And this is just my personal stuff, not even mentioning some of the things that I am doing over at marimo. So I guess there’s plenty of material for me to share.

The goal of my newsletter will be to keep folks in the loop via email. That way you should hear a signal from me even if I cannot reach you over social media anymore. Substack seems like the simplest provider to set this up, but I might switch in the future. Time will tell if I like the platform.

Hope you like it!

Subscribe now