Forem: Zoe Lin

Reading Solana Data — What Started to Feel Real in My Second Week

Zoe Lin — Sat, 02 May 2026 10:28:35 +0000

Before this week, I still thought of blockchain data as something more abstract than it probably needed to be.

I expected it to feel very different from the kinds of APIs and database reads I was already used to in Web2. But during the second week of 100 Days of Solana, that started to change. What made the difference was actually querying the data myself.

What started to feel familiar

The first shift came when I read a wallet balance directly from devnet. That did not feel as unfamiliar as I expected. It felt more like making a read call and getting back public state.

Fetching recent transactions made that idea clearer. Once I could see signatures, slots, timestamps, and statuses directly in the terminal, Solana started to feel less like a black box and more like a system I could inspect.

What surprised me most

What surprised me most was how consistent the pattern felt across different tasks. I used RPC calls to read balances, fetch transaction history, compare the same address across devnet and mainnet, and then render that data in a browser dashboard.

The tools changed, but the core flow stayed very similar: connect to an RPC endpoint, query public data, and display the result in a useful way.

That was the point where the “public database” framing started to feel real to me.

What changed in my mental model

The accounts-vs-databases comparison also helped a lot. My Web2 instincts still apply in some ways, but Solana accounts are not rows in private tables. They are public state objects on a shared ledger, with different rules around storage, ownership, and access.

If the first week helped me understand wallets and keypairs, the second week helped me understand that blockchain data is something I can query directly.

For me, that was the point where Solana started to feel less abstract and more like a real development environment.

Wallet Experiments — What Clicked for Me in My First Week of Solana

Zoe Lin — Mon, 27 Apr 2026 17:39:04 +0000

One of my biggest highlights from Week 1 of 100 Days of Solana was realizing how the same keypair model appeared across very different wallet experiences.

I generated a keypair, connected Phantom in a browser app, compared CLI, browser, and mobile wallets, and explored how they behaved on devnet. The screenshot below shows one of the moments that stood out most to me: connecting a browser wallet and seeing the address and balance appear inside the app.

What surprised me most was how much the UX could change while the core identity model stayed the same. That was the point where wallets stopped feeling like “accounts” and started making more sense as tools for managing keys.

Next, I’m looking forward to learning how to read more on-chain data and understand what is happening underneath the wallet interface.

Identity on Solana — Think SSH Keys, Not Usernames

Zoe Lin — Mon, 27 Apr 2026 11:48:49 +0000

If you come from Web2, identity usually means something managed by a platform. It might be a username on GitHub, an email address tied to your company account, or a password stored in a product database. In all of those cases, identity exists because a service stores it, recognizes it, and decides how authentication works.

This post is my attempt to explain how that changes on Solana in a way a Web2 developer would understand.

Why this felt unfamiliar at first

That is why Solana identity felt unfamiliar to me at first. I kept trying to understand wallets as if they were just another version of app accounts. That mental model was useful for getting started, but it was also misleading. After working through the first five days of 100 Days of Solana, the idea started to make much more sense.

The biggest shift was realizing that a wallet is not really the identity itself. It is the interface for managing the identity. The underlying identity is the keypair.

The SSH analogy that made it click

A Solana keypair feels a lot like an SSH keypair. You have a public key that can be shared, and a private key that stays with you. You prove control by signing with the private key. The basic mechanism is very similar. The difference is that SSH usually proves access to one server, while a Solana keypair works across a whole network.

That distinction matters because it changes what identity actually means. In Web2, identity is usually granted by a platform. A company stores your account, your profile, and your login credentials. If needed, it can lock you out, reset your password, or suspend the account. On Solana, identity is not granted by a company. It is proven cryptographically. If you control the private key, you control the account.

This also makes a public key very different from a username. A username is selected by a user, stored in a company database, and limited to a specific service. A public key is generated cryptographically, portable across applications, and not controlled by one company. The same keypair can be used to hold assets, sign transactions, interact with programs, and participate in governance without creating a separate identity for every app.

What the first five days helped me understand

That idea became much clearer to me because the first week of the challenge forced me to work with the same identity model through different tools.

On Day 1, I generated a keypair and funded it on devnet. That was the first time I really saw a wallet address as something produced from cryptographic keys rather than from account registration. On Day 2, I created a persistent wallet and saved it locally, which made the relationship between the keypair and the wallet feel much more concrete. On Day 3, I looked at balances in both SOL and lamports, which reminded me that the user-friendly wallet experience is only one layer on top of lower-level data structures. On Day 4, I connected Phantom in the browser and saw that my app could read the public address and balance without ever touching the private key. On Day 5, I compared CLI, browser, and mobile wallets and realized that even though their user experience feels very different, they are all ultimately managing the same thing.

The wallet types also made the tradeoffs easier to see:

The CLI wallet felt the most direct and scriptable, which made it great for development and testing, but it also felt the least secure because the private key was just a file on disk.
The browser wallet added a much better user experience, with password protection and approval popups, which made it feel more suitable for dApp interactions.
The mobile wallet felt more natural for personal use because it could rely on device-level protections and a more familiar everyday interface.

What changed in my mental model

What changed across those experiences was the interface and security model. What stayed the same was the identity model.

I think that is the part that makes Solana identity different from the Web2 model many developers are used to. In Web2, identity is usually defined inside a platform boundary. On Solana, identity starts from a cryptographic keypair and can move across applications without asking each one to create or approve a new account. That is why ownership feels different too. The network does not ask whether a company recognizes you. It only checks whether the signature is valid.

If I had to summarize it simply for another Web2 developer, I would say this: on Solana, identity is not a username stored by a platform. It is a cryptographic keypair that you control. Once that idea clicked for me, wallets, ownership, and on-chain interaction all started to make much more sense.

For me, that was the point where Solana identity stopped feeling abstract and started feeling practical.

Agent Launchpad — Why Google Cloud Next ’26 Feels More Buildable for Developers

Zoe Lin — Fri, 24 Apr 2026 10:11:40 +0000

After watching the Google Cloud Next ’26 keynotes, the idea that stayed with me most was Google’s effort to make AI agents feel closer to real development work.

What stood out this year was the push behind the agentic enterprise and the Gemini Enterprise Agent Platform. The message felt clear: building an agent is no longer only about model output. It also involves deployment, data, security, governance, and the ability to fit into real workflows. That is what made this announcement interesting to me.

This point mattered to me because I have already used Google Cloud labs, deployed web projects on GCP, and experimented with Google AI Studio for testing chatbot and agent-style ideas. Through those experiences, I found Google’s ecosystem friendly in a practical way. I could move step by step from learning to testing, then to deployment, while still being able to check settings, usage, and limits. That gave me more confidence to try things without feeling lost too early.

Because of that background, this year’s keynote felt more concrete than abstract. I was not only hearing a big vision about agents. I was hearing a platform story that connects more of the parts developers usually struggle with after the demo stage. Once a project needs tools, permissions, deployment, monitoring, and business context, the work changes. That is where many interesting prototypes slow down.

What I liked most about Google Cloud Next ’26 was that it framed this problem clearly. The value was not only in making agents more capable. The value was in making the path around them more complete. For developers, especially newer builders, that matters a lot. The hardest part is often not getting the first result from a model. The harder part is turning that result into something stable, usable, and worth improving.

I still think there is room to make this direction easier to learn. The vision is strong, but newer developers will need more simple examples and clearer paths from experimentation to deployment. Google already does a good job with labs and guided learning, so I hope that continues as these agent workflows become more advanced.

What made Google Cloud Next ’26 memorable for me was how well it connected with my own experience. When the platform reduces friction, I get to spend more time thinking about the agent itself: what it should do, how it should help, and where its limits should be. That is why this year’s announcements stayed with me. They made the distance between learning and launching feel shorter.

Green Habit Coach — AI-Powered Habit Analysis and Eco Coaching

Zoe Lin — Sun, 19 Apr 2026 19:17:49 +0000

What I Built

I built Green Habit Coach, a web app that helps users reflect on their daily habits and get practical eco-friendly suggestions.

Users can log in, fill out a short habit form, and receive an analysis result based on their lifestyle inputs. The app looks at habits such as transportation, meat consumption, air conditioning usage, disposable item usage, recycling behavior, and bring-your-own habits.

After the analysis, users get an eco score, a short summary, top issues, suggestions, and a simple 7-day challenge plan. They can also continue the experience by asking follow-up questions through an AI coach, such as what to improve first this week or which habit is the easiest to start tomorrow.

I wanted to make sustainability feel more personal, more practical, and easier to act on in everyday life.

Demo

Code

GitHub Repo

How I Built It

I built the frontend with React + Vite and the backend with FastAPI.

On the frontend, users can log in, submit their habit data, view their latest analysis, load history records, and ask follow-up questions in the coach section.

On the backend, the app handles authenticated API requests, habit analysis, history storage, coach thread creation, and coach follow-up messaging.

The app uses:

Auth0 for login and protected API access
Backboard for the follow-up AI coach experience
SQLite + SQLAlchemy for storing analysis history
Firebase Hosting for the frontend
Google Cloud Run for the backend

One of the biggest parts of this project was not just building the features, but also making the whole flow work in deployment. I spent a lot of time debugging Auth0 configuration, CORS between the frontend and backend, Cloud Run deployment issues, and async backend integration for the coach flow.

That was actually one of the most valuable parts of the project, because it made the app feel like a real full-stack product instead of only a local demo.

Prize Categories

I’m submitting this project for:

Best Use of Backboard
Best Use of Auth0 for Agents

Backboard powers the coach conversation flow and makes it possible to continue the user journey after the initial habit analysis.

Auth0 helps connect the experience to real authenticated users, protect backend routes, and keep history data scoped to the correct user.

What I Learned

This project helped me practice real full-stack development, especially:

frontend/backend integration
cloud deployment
authentication
production debugging
building AI features that feel useful

It also gave me more experience turning a simple idea into a deployed product with a complete user flow.

Email Drafter — Multi-Agent Email Writing with Google ADK and Cloud Run

Zoe Lin — Fri, 17 Apr 2026 06:51:30 +0000

What I Built

I built Email Drafter, a small web app that turns structured user input into a polished email draft using a multi-agent workflow.

The app takes:

recipient type
purpose
tone
language
key points

Instead of using one giant prompt, I split the workflow into multiple specialized roles.

The system works like this:

one agent plans the email
one agent reviews the plan
one agent writes the final draft
one orchestrator coordinates the workflow

I also deployed the system as separate services on Cloud Run, so the app feels much closer to a real distributed AI workflow instead of just a local prototype.

I picked email drafting because it is a practical use case where planning, reviewing, and writing feel like naturally separate tasks. That made it a good fit for experimenting with multi-agent orchestration.

Cloud Run Embed

Your Agents

This project uses three specialized agents plus one orchestrator.

Researcher Agent

Creates a structured email plan from the user input.
Judge Agent

Reviews the plan and checks whether it is complete enough before moving on.
Content Builder Agent

Writes the final email draft from the approved plan.
Orchestrator Agent

Coordinates the workflow between the other agents and returns the final result to the frontend.

The overall flow is:

Frontend -> Orchestrator -> Researcher -> Judge -> Content Builder -> Final Email Draft

Key Learnings

This project helped me understand why multi-agent systems can be useful even for a relatively small app.

A few things stood out while building it:

Splitting the workflow made debugging easier. It was much easier to tell whether the issue came from planning, review, or writing than trying to fix one large prompt.
Deployment was harder than the basic prompt logic. Getting multiple services running locally, wiring them together, and then deploying them to Cloud Run took more effort than writing the first version of the agents.
Prompt wording had a big impact on output quality. Small instruction changes made a noticeable difference between getting a planning-style response and getting something that looked like a real email.
Multi-agent design felt more modular and production-oriented. Even for a simple email drafting tool, separating responsibilities made the system easier to reason about and improve.

Demo

Hack Desk — Minimal Coding Setup for Global Hack Week

Zoe Lin — Tue, 14 Apr 2026 10:33:13 +0000

My Global Hack Week setup

My laptop, mouse, and a clean desk setup for building, debugging, and shipping projects.

@mlhacks

LogoForge — AI SVG Logo Generator for Brand Concepts

Zoe Lin — Mon, 13 Apr 2026 08:48:05 +0000

What I Built

I built LogoForge, a small web app that generates SVG logo concepts from a brand name, industry, style, and keywords using the Gemini API.

The app supports single and 3-variation generation, validates the model output as structured JSON, retries once if validation fails, and lets users preview the SVG, download it, and copy the JSON output.

I also refactored the project into a frontend and backend proxy setup so the API key is not exposed in the browser. That made the app feel much closer to something I would actually deploy instead of just keeping as a local prototype.

Demo

In the demo, I show the input flow, SVG generation results, color palette and brand story output, and the difference between single and 3-variation generation.

My Experience

This project taught me that prompting works much better when I treat it like writing a product spec instead of giving a loose instruction. The clearer I was about the UI, output format, and SVG constraints, the better the generated app became.

The biggest lesson was reliability. A raw model response can look correct but still fail in subtle ways, so adding validation and a retry step made the app much more stable.

I also learned a lot from the deployment side. I started with a simpler client-side setup, then moved the Gemini call behind a backend proxy and deployed the frontend and backend separately. That part felt much more like real engineering work than just prompt experimentation.

During testing, I also occasionally ran into temporary Gemini API availability issues under high demand. The overall app flow and deployment setup still worked as expected, but it reminded me that real-world AI apps need both prompt design and engineering safeguards.

What I Learned

Clear constraints produce better results
Structured output still needs validation
SVG is a great way to create visual output without image generation
Small engineering steps like retries and safer secret handling make a big difference
AI tools can speed up prototyping, but reliability still depends on developer judgment

Dark Dish Lab — Cursed Recipe Generator for Strange Culinary Ideas

Zoe Lin — Sun, 05 Apr 2026 18:21:11 +0000

What I Built

Dark Dish Lab is a tiny, delightfully useless web app that generates cursed food or drink recipes.

You pick:

Hated ingredients
Flavor chaos (salty / sweet / spicy / sour)

Then it generates a short “recipe” with a horror score, a few steps, and a warning.

It solves no real-world problem. It only creates regret.

Demo

YouTube demo

Code

GitHub repo

How I Built It

Frontend: React (Vite)
- Ingredient + flavor selection UI
- Calls backend API and renders the generated result
Backend: Spring Boot (Java 17)
- POST /api/generate endpoint
- Generates a short recipe text and returns JSON
Optional AI: Google Gemini API
- If AI is enabled and a key is provided, it asks Gemini for a very short recipe format
- If AI is disabled or fails, it falls back to a non-AI generator
Notes
- Only Unicode emojis are used (no emoji image assets)
- API keys are kept in local env files and not committed

How I Leveraged Google AI

Gemini (via the Gemini API) is the text generator behind Dark Dish Lab’s “cursed recipe” output.

Instead of using AI as a generic chatbot, I use it as a formatting engine:

Input: selected ingredients + flavor axes (salty/sweet/spicy/sour)
Output: a short, structured recipe (name, 3 steps, 1 warning)

To keep the experience stable and demo-friendly, I added a few guardrails:

Server-side API key only (kept in backend/.env.local, not committed)
Strict prompt constraints (no emojis, short length, fixed format)
Fallback generator when Gemini is disabled/unavailable
Output trimming to avoid unexpectedly long responses

Prize Category

Best Use of Google AI — I integrated the Gemini API to generate short, structured cursed recipes from the user’s selected ingredients and flavor axes.
Community Favorite angle — Try to generate the most cursed combo you can. Comment your ingredient + flavor picks and the horror score you got. Bonus points if your friends refuse to read it.

Ops Hub — Notion MCP Dashboard for Assets, Subscriptions & Daily Digest

Zoe Lin — Thu, 26 Mar 2026 18:34:30 +0000

What I Built

Ops Hub is a Notion-first dashboard for asset and subscription operations (built with Notion MCP + Python).

It helps centralize scattered operational info (devices, warranties, renewals) into one workspace and turns it into a daily workflow:

Assets Ops: track equipment (3C / appliances), maintenance schedule, warranty dates, and manuals.
Subscription Ops: track renewals, pricing, and generate cancellation drafts.
Daily Digest: one command generates a Daily Digest — YYYY-MM-DD page in Notion with:
- KPI summary (counts + upcoming renewal cost)
- actionable lists with deep links to the exact items

All outputs stay inside Notion, so it’s easy to review and act (human-in-the-loop friendly).

Video Demo

Show us the code

GitHub Repo

Run locally (Poetry):

cp .env.example .env
poetry install
poetry run python -c "from homeops_mcp.server import create_daily_digest; print(create_daily_digest(14))"

How I Used Notion MCP

Notion is the source of truth (databases, views, templates, and the dashboard). The MCP server turns Notion context into an automated ops workflow:

Reads Notion databases to find:
- assets due for maintenance soon
- warranties expiring soon
- subscriptions renewing soon (within N days)
Writes back into Notion:
- status fields like Next Action and Lifecycle Stage
- helpful notes like Manual Notes (maintenance guidance) and Cancel Instructions (cancellation draft)
Generates a Daily Digest page in Notion with KPIs + clickable action lists, so I can review everything in one place.

This makes the workflow feel like “superpowers”: I stay in Notion, run one command, and get an updated dashboard plus a daily report ready to act on.

Data Model (Notion Databases)

Assets

Maintenance: Last Maintenance + Maintenance Interval (days) → Next Maintenance (formula) → Next Maintenance Date (calendar)
Ops fields: Next Action, Lifecycle Stage
Docs: Manual Notes, Manual URL, Warranty End

Subscriptions

Renewal tracking: Renewal Date, Billing Cycle, Status
Ops fields: Next Action
Output: Cancel Instructions (draft)

Daily Digest (Auto Report)

A single run creates a Daily Digest — YYYY-MM-DD page in Notion with:

KPI Summary (maintenance / renewals / renewal cost / warranty)
Clickable action lists linking to the exact items

Generated by create_daily_digest(14) and saved as a child page under the dashboard.

Tech Stack

Python (MCP server)
Notion MCP + Notion API
Poetry (dependency & virtualenv)