DEV Community: Yousra S

Weekend Challenge: Earth Day Edition - Cleaning our Earth

Yousra S — Mon, 20 Apr 2026 01:00:46 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

Have you ever walked through a street or a park, spotted a plastic bag tangled in a bush, a few bottles scattered on the grass and felt that small but familiar pang of helplessness? You might pick one up. But then you wonder: what about the rest? What if others could see this too? What if we could work on it together?

Keeping our planet clean is one step closer to taking better care of this beautiful home we all share. This is what Terrae helps us do.

Terrae is an Android app that lets people report and clean up trash together. You spot litter, you open the app, take a photo, and in seconds Google Gemini AI has analyzed the severity and pinned it to a shared map. Someone nearby can claim the spot, take an after-photo to prove it's clean, and earn points and badges.

Core features:

Report: Photo a spot that has trash → Gemini 2.5 Flash rates severity (LOW / MEDIUM / HIGH), generates a description, and pins it to the map
Shared Map: Real-time Google Maps markers color-coded by severity, with a peek-able bottom sheet showing nearby reports
Feed: Image-first list of reports sorted by distance
4-Gate Clean Validation: the app enforces four gates before awarding points when requesting to clean a place:
1. You can't clean your own report
2. You must be within 100m of the trash location
3. You must take an after-photo as proof
4. Gemini AI must confirm the area actually looks clean
Points + Badges: Reporting earns 5–20 pts, cleaning earns 10–50 pts (scaled by severity). Badges: First Report, First Clean, Earth Warden (5 cleans), Green Guardian (10 cleans)
Profile: Points counter, stats, badge grid, share CTA

Demo

flow when user cleans a place	flow when reporting a place

Pictures of the different app screens:

Map Screen	Feed Screen	Profile Screen

Code

yousrasd / Terrae

An Android app to keep our Earth clean by bringing people together to remove trash they find

Terrae

Terrae is an Android app for reporting trash hotspots and coordinating cleanup. Users can capture or select a photo, let Gemini classify the severity, publish the report to a shared map and feed, and earn points and badges by contributing cleanups.

What the app does

Report trash
- Start from the map
- Choose Camera or Gallery
- Run Gemini image analysis
- Confirm and publish the report
Browse nearby reports
- View reports on the map with severity-colored markers
- Browse the same data in the feed
- Open a report detail view from map/feed
Track cleanup progress
- Open a report
- Tap I'll Clean This
- Confirm readiness from a bottom sheet before camera capture
- Validate cleanup with proximity checks, photo proof, and Gemini verification
Earn rewards
- Reporting and cleaning award points
- User profile tracks reports, cleans, and badges

Core product flows

1. Report flow

Map -> Report -> Source picker -> Camera/Gallery -> AI analysis…

View on GitHub

How I Built It

The Stack

Kotlin + Jetpack Compose for the UI, Firebase (Firestore, Storage, anonymous Auth) for the backend, Google Maps Compose for the shared map, Gemini 2.5 Flash via OkHttp for the AI brain and Copilot CLI for agentic development.

Architecture is MVVM with a use case layer: domain interfaces → use cases → single ViewModel → Compose screens. Hilt wires everything together.

The Workflow

I used GitHub Copilot agent mode with three custom agents, each with a specific role, all grounded by a shared copilot-instructions.md that encoded the full architecture, data models, screen structure, and coding conventions:

Agent	Role
`android-implementor`	Implements each story: writes the Kotlin/Compose code, write unit and component tests, verifies the build compiles
`maestro-qa`	After each story ships, writes and runs Maestro UI test flows against a real physical device
`doc-agent`	Invoked once at the end to generate project documentation

The pipeline per story:

Plan story → android-implementor builds it → I review + validate →
maestro-qa writes & runs tests → tests pass → next story

I started by using Copilot Cli's plan mode to break the project into 16 stories with a clear dependency graph. From there, I fed each story to the dev agent. It would implement, confirm the build succeeded, and present what it built. I'd review, test on my physical device, and give the go-ahead. Then the QA agent automated the verification.

I stayed in the loop as the decision-maker at every handoff. The agents knew the architecture (from copilot-instructions.md), respected the patterns, and flagged when something didn't fit. I orchestrated the flow and validated every step.

It was bit challenging at times. One challenge was keeping the agents aligned with the architecture. Early on, they would drift and generate inconsistent patterns, so I had to reinforce strict rules inside copilot-instructions.md.

Prize Categories

Best Use of Google Gemini
Gemini 2.5 Flash does two critical jobs in Terrae through two dedicated agents:

ScanAgent — When you report a trash spot, Gemini looks at your photo and returns a structured JSON response with severity (LOW/MEDIUM/HIGH), a human-readable description, and a confidence score. That severity drives the map marker color and the points reward. A stray bottle cap is LOW (5 pts to report, 10 to clean). A scattered pile of bags and debris is HIGH (20 pts to report, 50 to clean).

CleanAgent — When you claim to have cleaned a spot, Gemini looks at your after-photo and decides whether the area actually looks clean. It returns isClean, confidence, and reason. The threshold is 0.6 — below that, the clean is rejected and the user is told why.

Both agents use the same model (gemini-2.5-flash) via OkHttp with base64-encoded images and structured text prompts. Both return JSON that the app parses into typed Kotlin data classes.

Thanks to Gemini, the app can autonomously judge severity of pictures, and validate that work was actually done.

Best Use of GitHub Copilot

I used Copilot's agent mode with three custom agents, each with a defined role, all grounded in a shared copilot-instructions.md that encoded the full architecture, data models, and conventions:

android-implementor — the dev agent, implementing each story in Kotlin/Compose
maestro-qa — the QA agent, writing and running Maestro UI tests against a real device after each story
doc-agent — the documentation agent, invoked once at the end

I first started the plan mode through Copilot CLI and came up with solid plan thanks to copilot. Once the plan was defined and stories broken down,
the pipeline per story was then: dev agent implements (and makes sure the build is successful) → I review and validate → QA agent runs tests → tests pass → next story. I stayed in the loop as the decision-maker at every step.

At the end, doc agent writes final doc of the entire project.

What i liked about this workflow is that, even though I delegated all the work to AI, I was there orchestrating the different flows (dev -> qa-> doc) and validating any AI work.
Copilot CLI made the entire developement workflow fun.

You can see the details workflow here.

What's Next

That was a fun challenge. Thanks DEV community for such a great theme idea.

I would love to keep building on it. For example, adding actual account creation, a leaderboard.

And of course expand it to iOS. Right now it's Android only, but the idea works on any phone.

This was one of the most fun builds I’ve done in a while, especially experimenting with AI agents in the loop for mobile app developement.

I'm curious to hear from other developers. How are you integrating AI agents into your daily coding workflow?

Avoiding Stale Data: Redis Caching Gotchas

Yousra S — Mon, 16 Jun 2025 01:33:47 +0000

Caching data with Redis can lead to stale data if the right operations aren't used carefully ⚠️🕰️.

What is Redis? 🚀

For those unfamiliar, Redis is an open-source, in-memory data structure store used as a database, cache, and message broker. It supports data structures such as strings, hashes, lists, sets, and more.

Its most appealing feature is speed — Redis keeps data in memory, making it incredibly fast for reads and writes. It's a popular choice for caching data that needs to be accessed quickly and frequently.

Redis Gotchas ⚠️🐍

One Redis operation, HSET, doesn’t allow you to set an expiry directly. You have to invoke a second operation, EXPIRE, to set a TTL (time-to-live) for the cache.

Gotcha: Calling HSET then EXPIRE without a transaction could lead to stale data if, for example, the EXPIRE command fails while the HSET succeeds.

HSET depends on the EXPIRE command to clear the cache and sync it with new data by reinvoking the backend.

➡️ If EXPIRE fails, the cached data will stay forever and become stale. If your app depends on fresh data, this could lead to showing outdated info. 😬

import redis

redis_client = redis.Redis(host='localhost', port=6379, db=0)

cities = ['Mississauga', 'Oakville']
for city in cities:
    key = f"weather_{city}"
    redis_client.hset(key, mapping={
        'temp': 22,
        'wind': 5,
        'condition': 'Cloudy',
        'city': city
    })
    redis_client.expire(key, 10)

Why It Matters 💡

When caching, expiration is just as important as storing data. Stale data in a cache can be worse than no cache at all — it tricks your app into thinking it’s working with fresh info. 🚫🕰️

The Solution: Use Transactions or Lua Scripts 🔐🐉

To ensure that both commands succeed or fail together, we should wrap them in a pipeline within a transaction (MULTI/EXEC) or use a Lua script.

A Redis pipeline allows multiple commands to be sent to the server as a single batch, reducing network overhead and minimizing the impact of network
glitches. For example, without pipelining, if two dependent write operations are executed separately, one might reach the Redis server while the other
could be lost due to a network issue. With pipelining, both operations are transmitted together in one network packet, making it more likely
that either both are received or both are dropped — offering a basic form of network-level consistency.

However, it's important to note that pipelining does not guarantee atomicity — commands are still executed one after the other by Redis, and
failures in individual commands do not roll back others.

To ensure true atomic execution, Redis transactions should be used. Using a transaction ensures that all operations within the block are executed
sequentially and without interference from other clients. The MULTI command queues the operations, and EXEC executes them all at once. This provides a
degree of isolation: no other client's commands are interleaved during the execution of the transaction.

transaction = redis_client.pipeline(transaction=True)
for city in cities:
    key = f"weather_{city}"
    transaction.hset(key, mapping={
        'temp': 22,
        'wind': 5,
        'condition': 'Cloudy',
        'city': city
    })
    transaction.expire(key, 10)

transaction.execute()

Heads up: Redis transactions are not fully atomic. If one command fails, others won't be rolled back — partial changes can still persist.

True Atomicity with Lua Scripts 🧙‍♂️✨

Redis guarantees atomicity when using Lua scripts. All operations run as one indivisible block — no other commands can run until the script finishes.

If the script completes, all changes are applied in order.

If there’s a runtime error, the entire script aborts and no changes are made.

But be careful! Lua scripts block the entire Redis server while running. If a script takes too long, it can slow down or freeze Redis for other clients.
So keep Lua scripts super fast .

cities = ['Mississauga', 'Oakville']
lua_script = """
for i = 1, #KEYS do
    local base = (i - 1) * 5
    local key = KEYS[i]
    redis.call('HSET', key, 'temp', ARGV[base + 1], 'wind', ARGV[base + 2], 'condition', ARGV[base + 3], 'city', ARGV[base + 4])
    redis.call('EXPIRE', key, tonumber(ARGV[base + 5]))
end
return #KEYS
"""

keys = [f"weather_{city}" for city in cities]

# For each city, pack values: temp=22, wind=5, condition='Cloudy', city=city, expire=10
args = []
for city in cities:
    args.extend(['22', '5', 'Cloudy', city, '10'])

redis_client.eval(lua_script, len(keys), *keys, *args)

Final Thoughts 💭

Always consider atomicity when working with Redis for critical caching.
Stale cache is worse than no cache — it can cause hidden bugs and confusing behavior.
Redis is fast and simple, but it can fail silently — wrap multi-step operations when consistency matters!

That's it for today!

Hope this article helped you avoid some Redis gotchas.

Happy coding and creating! ✨🚀

👉 You can also read this article on my website.