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.

One Task Per Email: Loop Over Write Actions — Automation For Explorers

Day 20 · ~12 min●

A loop with a write call inside it — you create one task per email. What is the difference between a loop that reads and a loop that writes, from a correctness standpoint?

Writes are side-effecting — if the loop dies halfway, I've already created some tasks that I can't take back? So I want the loop to be tight and predictable?

Exactly. Keep the loop body small — one extract, one write, one append to the log. No branching inside the loop that could skip silently. Here's the core body:

python

for m in messages:
    title = m.get("snippet", "")
    toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": title})
    created.append(title)

And the outer function returns the full list of titles — so the caller can see exactly what was created even if they didn't log mid-loop?

The return is your audit trail. If the call site prints or writes the list to disk, every task that was created is accounted for — no silent losses:

python

def create_task_for_each_email(max_results: int) -> list:
    emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
    messages = emails.get("messages", [])
    created = []
    for m in messages:
        title = m.get("snippet", "")
        toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": title})
        created.append(title)
    return created

What if one of the writes throws mid-loop — do I lose everything that succeeded before the failure?

Without a wrapper, yes — the exception propagates and the caller sees nothing. A production version wraps the write in try/except and keeps going on failures, logging the broken ones. For a first write loop, let failures propagate so you see them loud and early.

So every multi-write script is basically this shape — iterate, write, accumulate, return — and production hardening is the try/except wrap I already know?

Iterate, write, collect. Swap the write enum and you have bulk creates for any Composio app. Week 4 wraps this exact loop with the defensive patterns.

Bulk Writes

TL;DR: One read, a tight loop, one write per item, return the audit list.

Single read — fetch the whole batch once
Tight loop body — extract, write, append
Return audit list — the titles that were written

Why accumulate titles not ids

Return	When useful
Titles written	Logging, printing, human review
Server-side ids	Chained updates to the same tasks later
Count only	Status dashboards, nothing else

Titles tell you what was written. Ids let you mutate it later. Pick the one your caller needs; bulk scripts usually want the titles.

Day 20 · ~12 min●

A loop with a write call inside it — you create one task per email. What is the difference between a loop that reads and a loop that writes, from a correctness standpoint?

Writes are side-effecting — if the loop dies halfway, I've already created some tasks that I can't take back? So I want the loop to be tight and predictable?

Exactly. Keep the loop body small — one extract, one write, one append to the log. No branching inside the loop that could skip silently. Here's the core body:

python

for m in messages:
    title = m.get("snippet", "")
    toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": title})
    created.append(title)

And the outer function returns the full list of titles — so the caller can see exactly what was created even if they didn't log mid-loop?

The return is your audit trail. If the call site prints or writes the list to disk, every task that was created is accounted for — no silent losses:

python

def create_task_for_each_email(max_results: int) -> list:
    emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
    messages = emails.get("messages", [])
    created = []
    for m in messages:
        title = m.get("snippet", "")
        toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": title})
        created.append(title)
    return created

What if one of the writes throws mid-loop — do I lose everything that succeeded before the failure?

So every multi-write script is basically this shape — iterate, write, accumulate, return — and production hardening is the try/except wrap I already know?

Iterate, write, collect. Swap the write enum and you have bulk creates for any Composio app. Week 4 wraps this exact loop with the defensive patterns.

Bulk Writes

TL;DR: One read, a tight loop, one write per item, return the audit list.

Single read — fetch the whole batch once
Tight loop body — extract, write, append
Return audit list — the titles that were written

Why accumulate titles not ids

Return	When useful
Titles written	Logging, printing, human review
Server-side ids	Chained updates to the same tasks later
Count only	Status dashboards, nothing else

Titles tell you what was written. Ids let you mutate it later. Pick the one your caller needs; bulk scripts usually want the titles.

def create_task_for_each_email(max_results: int) -> list: emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results}) messages = emails.get("messages", []) created = [] for m in messages: title = m.get("snippet", "") toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {"title": title}) created.append(title) return created

Bulk Writes

TL;DR: One read, a tight loop, one write per item, return the audit list.

Single read — fetch the whole batch once

Tight loop body — extract, write, append

Return audit list — the titles that were written

Why accumulate titles not ids

Return	When useful
Titles written	Logging, printing, human review
Server-side ids	Chained updates to the same tasks later
Count only	Status dashboards, nothing else

Titles tell you what was written. Ids let you mutate it later. Pick the one your caller needs; bulk scripts usually want the titles.

Bulk Writes

TL;DR: One read, a tight loop, one write per item, return the audit list.

Single read — fetch the whole batch once

Tight loop body — extract, write, append

Return audit list — the titles that were written

Why accumulate titles not ids

Return	When useful
Titles written	Logging, printing, human review
Server-side ids	Chained updates to the same tasks later
Count only	Status dashboards, nothing else

Titles tell you what was written. Ids let you mutate it later. Pick the one your caller needs; bulk scripts usually want the titles.

Bulk Writes

Why accumulate titles not ids

Bulk Writes

Why accumulate titles not ids

Bulk Writes

Why accumulate titles not ids

Sign up to practice

Bulk Writes

Why accumulate titles not ids

Sign up to practice