How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Count Inbox and Calendar at Once — Automation For Explorers

Day 3 · ~12 min●

Two questions, one function: how many emails are in your inbox right now, and how many events are on your calendar. You want both numbers in a single return — what shape makes that easy to read?

A dict with two keys? Something like {"emails": 3, "events": 2} so the caller knows which number is which?

Exactly that. Named keys are self-documenting — no caller ever has to remember which number came first. The two execute_action calls go back-to-back, each guarded by .get():

python

emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 5})
events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})

So Gmail returns {"messages": [...]} and Calendar returns {"items": [...]} — different keys for the same kind of data. Do I have to memorize the key per API?

One lookup per API, then the pattern sticks. .get(key, []) works no matter what the key name is — swap the string, the skeleton stands. Here's the full function:

python

def inbox_and_events(max_emails: int, max_events: int) -> dict:
    emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_emails})
    events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})
    return {"emails": len(emails.get("messages", [])), "events": len(events.get("items", []))}

What if Gmail is empty one morning? Does the "messages" key still show up, or does the whole response change shape?

Either the key is missing or the list is empty — both shapes are possible. .get("messages", []) handles both cleanly, and len([]) is zero. Your function returns a dict with two valid counts whether your inbox is buzzing or silent.

So I'm really looking at two live APIs at once, and the dict on my screen is a real-time snapshot of my morning?

Live inbox, live calendar, one dict. That is the shape every multi-source function in this track will take — two reads, defensive gets, one return.

Multi-Source Counting

TL;DR: Two execute_action calls, two .get(key, []) safeties, one dict with named keys.

Gmail — response key is messages on every fetch
Calendar — response key is items on every find
Return — {"emails": int, "events": int} so callers read by name

Response keys by API

API	List key
Gmail	`messages`
Calendar	`items`
Tasks	`items`

Named dict keys beat tuples every time: order-independent, self-documenting, and completely refactor-safe when new sources join later.

Day 3 · ~12 min●

Two questions, one function: how many emails are in your inbox right now, and how many events are on your calendar. You want both numbers in a single return — what shape makes that easy to read?

A dict with two keys? Something like {"emails": 3, "events": 2} so the caller knows which number is which?

Exactly that. Named keys are self-documenting — no caller ever has to remember which number came first. The two execute_action calls go back-to-back, each guarded by .get():

python

emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 5})
events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})

So Gmail returns {"messages": [...]} and Calendar returns {"items": [...]} — different keys for the same kind of data. Do I have to memorize the key per API?

One lookup per API, then the pattern sticks. .get(key, []) works no matter what the key name is — swap the string, the skeleton stands. Here's the full function:

python

def inbox_and_events(max_emails: int, max_events: int) -> dict:
    emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_emails})
    events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""})
    return {"emails": len(emails.get("messages", [])), "events": len(events.get("items", []))}

What if Gmail is empty one morning? Does the "messages" key still show up, or does the whole response change shape?

So I'm really looking at two live APIs at once, and the dict on my screen is a real-time snapshot of my morning?

Live inbox, live calendar, one dict. That is the shape every multi-source function in this track will take — two reads, defensive gets, one return.

Multi-Source Counting

TL;DR: Two execute_action calls, two .get(key, []) safeties, one dict with named keys.

Gmail — response key is messages on every fetch
Calendar — response key is items on every find
Return — {"emails": int, "events": int} so callers read by name

Response keys by API

API	List key
Gmail	`messages`
Calendar	`items`
Tasks	`items`

Named dict keys beat tuples every time: order-independent, self-documenting, and completely refactor-safe when new sources join later.

def inbox_and_events(max_emails: int, max_events: int) -> dict: emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_emails}) events = toolset.execute_action(Action.GOOGLECALENDAR_FIND_EVENT, {"query": ""}) return {"emails": len(emails.get("messages", [])), "events": len(events.get("items", []))}

Multi-Source Counting

TL;DR: Two execute_action calls, two .get(key, []) safeties, one dict with named keys.

Gmail — response key is messages on every fetch

Calendar — response key is items on every find

Return — {"emails": int, "events": int} so callers read by name

Response keys by API

API	List key
Gmail	`messages`
Calendar	`items`
Tasks	`items`

Named dict keys beat tuples every time: order-independent, self-documenting, and completely refactor-safe when new sources join later.

Multi-Source Counting

TL;DR: Two execute_action calls, two .get(key, []) safeties, one dict with named keys.

Gmail — response key is messages on every fetch

Calendar — response key is items on every find

Return — {"emails": int, "events": int} so callers read by name

Response keys by API

API	List key
Gmail	`messages`
Calendar	`items`
Tasks	`items`

Named dict keys beat tuples every time: order-independent, self-documenting, and completely refactor-safe when new sources join later.

Multi-Source Counting

Response keys by API

Multi-Source Counting

Response keys by API

Multi-Source Counting

Response keys by API

Sign up to practice

Multi-Source Counting

Response keys by API

Sign up to practice