In the previous unit, we covered operators and boolean logic. Those comparisons that return True or False? Now we put them to work. Conditional statements let your program make decisions based on those boolean results.

In the previous unit, we covered variables and data types. Now let's look at what you can actually do with those values. Operators are how Python performs calculations and makes comparisons. They're the verbs of programming.

In the previous unit, we set up Python and drew our first shapes with Turtle. Now it's time to understand how Python stores information. Variables and data types are the building blocks of every program you'll write.

This is the first unit in my Python tutorial series. We're starting with the absolute basics: what programming is, how to set up Python on your machine, and your first program. By the end, you'll have a little turtle drawing shapes on screen.

When I set out to teach my kids programming, I wanted something different from the typical "Hello World" progression. I wanted them to see what their code was doing, immediately, on screen. That's what led me to Python's Turtle library.

Turtle gives you a little cursor that you can move around the screen with code. Tell it to go forward, turn left, change colors. The feedback is instant and visual. For someone just starting out, that connection between typing code and seeing something happen is everything.

This course grew out of that experience. It starts with the absolute basics (what even is programming?) and builds through thirty-four units to a working Snake game. Each unit has theory, code examples, and a mini project. The projects all use Turtle, so you're building something visual every step of the way.

Date handling is one of those things that seems simple until it isn't. I've been using Day.js on a few TypeScript projects lately, and it's become my go-to for anything date-related. At around 2KB gzipped, it's tiny compared to alternatives, and the API is clean enough that I rarely need to check the docs.

In the previous posts, I covered what REST is and how resources and methods work. Now let's look at what makes an API robust: status codes that communicate clearly, security that protects your data, and design patterns that keep things maintainable. These are the things I wish I'd understood better when I started building APIs.

In the previous post, I covered what REST is and where it came from. Now let's look at how it actually works. This is where the principles become concrete.

I've been working with APIs for years, but I recently went back to understand REST from first principles. When you use a weather app to check the forecast, something interesting happens behind the scenes. The app sends a request to a server, the server fetches the data, and it sends back the forecast for your location. This exchange happens through an API, a set of rules that lets software applications talk to each other.

That sounds simple enough. But how do the client and server actually communicate? Many standards have been proposed over the years, but REST emerged as the dominant approach for building networked applications. I wanted to understand why.

How can two people who've never met exchange secret information over an open network? It's a question that sounds impossible until you see the answer: public-key cryptography.