DEV Community: amionweb

Your AI Agent Probably Doesn't Need a Vector Database

amionweb — Sat, 30 May 2026 17:09:59 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

Your AI Agent Probably Doesn't Need a Vector Database

There's a reflex in agent-building right now. You decide your agent should "remember things," and within ten minutes you're comparing managed vector-DB tiers, picking an embedding model, and quietly arguing with yourself about chunk size and overlap.

Hermes Agent — one of the more capable open agents you can run yourself — skips all of that for its long-term memory. It remembers past sessions with SQLite and full-text search. No embeddings. No vector index. No cosine-similarity threshold to babysit.

The first time I noticed this, I assumed it was a placeholder. The thing you rip out before you're serious. The longer I sat with it, the more it looked like the serious choice, and the reflex looked like the placeholder.

This post is about why that is, where it breaks down, and what it should change about how you build memory into your own agents. If you've never touched embeddings, don't worry — the next two sections get you up to speed in plain language. If you build RAG for a living, skip to "Where keyword search actually loses."

Two different problems hiding under one word

"Memory" gets used for two jobs that have almost nothing in common, and conflating them is where a lot of agent designs go wrong.

The first job is recall: what happened in our past sessions? You asked me to set up a deploy script last Tuesday; can I find that conversation and the script we landed on? This is retrieval over a growing pile of transcripts.

The second job is user modeling: who is this person and how do they like to work? Not a specific event, but a slowly-built profile — they prefer terse answers, they're on Windows, they hate when I touch their config without asking.

These want different tools. Recall is a search problem. User modeling is a summarization-and-inference problem. Hermes treats them separately, and that separation is half the reason the design holds together. Recall runs on full-text search. User modeling is handed off to Honcho, which maintains an evolving, "dialectic" model of you across conversations. Two problems, two mechanisms, no forcing one tool to do both.

The rest of this post is about the recall half, because that's the part everyone instinctively reaches for a vector database to solve.

A 90-second primer: vectors vs. full-text search

If you already know this cold, skip ahead. If not, here's the whole idea.

A vector database stores text as embeddings — long lists of numbers a model produces, positioned so that things with similar meaning sit close together. Ask "how do I get a refund," and it can surface a passage about "returning a purchase" even though they share no words. That semantic reach is the superpower. The cost: you run an embedding model on everything going in and every query coming out, you store and index the vectors, and you accept that retrieval is fuzzy and a little opaque. Why did it return that? Because the math said it was near. Good luck reading the math.

Full-text search — what SQLite's FTS5 gives you — is the grown-up version of keyword matching. It indexes the actual words, then ranks results by a relevance formula (BM25: roughly, rarer words that appear more often in a document score higher). Search "refund policy shopify," and you get the sessions where those terms actually show up, ranked best-first. It's fast, it's cheap, and crucially, you can read exactly why a result matched.

One reaches for meaning. The other reaches for words. The conventional wisdom says agents need meaning, so they need vectors. Hermes quietly bets that for session recall, words are enough, and the places where they aren't can be patched more cheaply than a vector stack costs.

How Hermes actually remembers

Three layers, and none of them are exotic. That's the point.

1. Every session goes into SQLite, indexed by FTS5. All your CLI and messaging conversations land in one local database file (~/.hermes/state.db), full-text indexed. When something might be relevant later, the agent searches its own history the way you'd search a codebase: by terms, ranked by relevance, and it gets back the actual messages — not a lossy paraphrase of them. Conceptually, recall looks closer to this than to a similarity query:

-- not the literal Hermes query, but the shape of it
SELECT session_id, snippet(messages, 0, '[', ']', '…', 12)
FROM   messages
WHERE  messages MATCH 'deploy AND script AND staging'
ORDER  BY rank;          -- BM25 relevance, best first

In practice these come back in around 20ms against the local file. There's no network hop, because there's nowhere to hop to.

2. A separate, bounded layer holds curated notes. Next to the raw log, Hermes keeps two small agent-maintained files in ~/.hermes/memories/: a running MEMORY.md of facts worth keeping (capped around 800 tokens) and a USER.md profile (around 500). They're injected into the system prompt as a frozen snapshot when a session starts, and the agent edits them deliberately with add, replace, and remove operations. This is the distilled layer — not everything that was ever said, but the handful of things the agent decided were worth writing down in plain language. It's the difference between your shell history and the README you keep by hand. The condensing work happens here, on what to keep, and stays out of the recall path, so search itself never hands back a guess.

3. Deep user modeling is delegated. For a richer, evolving picture of who you are, Hermes can hand off to Honcho, which reasons about each conversation after it ends and accumulates insight about your preferences, habits, and goals. It's optional, and it's deliberately a different system from raw recall.

Here's the whole shape:

   ┌────────────────────────────────────────────────┐
   │  this conversation (working context)            │
   └───────────────┬────────────────────────────────┘
                   │ when relevant, search the past
                   ▼
   ┌────────────────────────────────────────────────┐
   │  SQLite + FTS5  (~/.hermes/state.db)            │
   │  raw sessions · keyword/BM25 · returns messages │
   └────────────────────────────────────────────────┘
        ▲                                   ▲
        │ distilled by hand                 │ separate track
   ┌──────────────────────────┐   ┌──────────────────────────┐
   │ MEMORY.md / USER.md       │   │ Honcho (optional)        │
   │ agent-curated facts       │   │ evolving user model      │
   └──────────────────────────┘   └──────────────────────────┘

No embedding service anywhere in the recall path. No vector index to keep warm. A database file you could open and read on a plane.

Why this is a better default than it sounds

I want to be fair to vectors later, so let me be specific about what the boring approach buys you first.

It costs almost nothing to run. Every embedding-based memory pays a tax on both ends: you embed what you store, and you embed every query. At low volume that's noise. For an always-on agent that's reading and writing memory all day, it adds up, and it adds a network dependency to a path that now works with a local file and zero API calls.

You can debug it. This is the one I underrate every time. When an FTS-backed agent recalls the wrong thing, you can run the query yourself and see precisely why. When a vector-backed agent recalls the wrong thing, you're staring at cosine distances trying to reverse-engineer the embedding model's taste. One of these you fix on a Tuesday afternoon. The other becomes a ticket that says "memory feels off sometimes."

It's portable and inspectable. The memory is a file. You can back it up, copy it to another machine, grep it, audit what your agent knows, and delete what it shouldn't. Try explaining to a security reviewer what's inside your vector index. Now hand them a SQLite file they can query.

It doesn't drift under you. Swap your embedding model — a new version, a different provider — and strictly, your old vectors live in a different space than your new ones. Teams paper over this, but it's a real, recurring source of "why did retrieval quietly get worse." Keyword indexes don't have model-version baggage. The word "refund" in 2024 is the word "refund" in 2026.

It works offline and on tiny hardware. The whole pitch of Hermes is an agent that lives on infrastructure you own, possibly something cheap. Full-text search is right at home there. A vector stack wants more.

None of these are clever. Added together, for the specific job of "find the relevant past conversation," they're hard to argue with.

Where keyword search actually loses

Now the honest part, because "you never need vectors" would be the wrong lesson.

Full-text search fails exactly where you'd expect: when the words don't match but the meaning does. If three months ago you discussed "rolling back a release" and today you ask about "reverting a deploy," BM25 may shrug. It has no idea those are the same idea. Embeddings would catch it. Other genuine weak spots:

Conceptual or fuzzy queries ("that thing we tried when latency spiked") where you can't supply the keywords because you don't remember them.
Synonym-heavy or jargon-rich domains, where the same concept has ten surface forms.
Cross-lingual recall, where the stored text and the query aren't even in the same language.

This is real, and pretending otherwise would be the kind of advocacy this challenge is already full of. But two things soften it in Hermes's design, and the second one is the interesting part.

First, the curated MEMORY.md layer records the facts that matter in clean, canonical language. So your most important memories don't hang on whether you can reproduce the exact words from a six-week-old transcript.

Second — and this is what a vector-DB reflex misses — the thing doing the searching is an agent, not a dumb retrieval pipeline. If "reverting a deploy" comes back empty, a capable agent can just try "rollback," then "release," then "revert" on its own. A RAG pipeline fires one query and lives with whatever it gets. An agent can rifle through its own filing cabinet, reformulating until it finds the drawer. That recovers a surprising amount of what naive keyword matching would drop, and it costs nothing but a few extra tokens. It won't fully close the semantic gap. It narrows it without an embedding in sight.

And when that isn't enough? FTS5 and a vector index aren't enemies. The mature move is hybrid: keyword search for the 90% that's precise and cheap, embeddings layered on for the conceptual long tail. Hermes is literally built this way. Keyword recall ships by default, and you can run a semantic provider — Mem0, Supermemory, Honcho — alongside it, never replacing the built-in store. The hybrid model isn't a hack you bolt on later. It's the shipped design. Starting with vectors gets the order backwards: you pay for the expensive, fuzzy tool first and add the cheap, precise one afterward, if ever.

A decision guide you can actually use

Strip away the framework and here's the call for your agent's memory:

If you need…	Reach for	Why
"Find the session where we did X"	Full-text search (FTS5)	Cheap, fast, debuggable, exact
Bounded long-term facts	Agent-curated notes (MEMORY.md)	Keeps what matters in clean, canonical language
"Who is this user, how do they work"	A user model (e.g. Honcho)	Different problem from recall
Recall across synonyms/concepts	Add embeddings (hybrid)	The one place vectors clearly earn it
Everything, day one	Start with FTS, measure, then add	You'll likely never hit the wall

The general principle Hermes is quietly demonstrating: default to the boring, legible tool, and add the expensive, opaque one only when you can point at the specific query it failed. That's not a memory rule. That's just engineering. It's easy to forget in a field where every blog post assumes a vector database the way older ones assumed jQuery.

The takeaway

The interesting thing about Hermes's memory isn't that it's clever. It's that it's deliberately not clever, and it works anyway. SQLite, full-text search, a summarization pass, and a separate track for modeling the user. Four ordinary pieces, each doing one job it's genuinely good at.

I came in expecting to find a corner that had been cut. I left thinking most agent projects cut the corner in the other direction — reaching for vectors out of habit, paying for semantic recall they rarely exercise, and trading away the things that actually matter day to day: cost, portability, and being able to answer "why did it remember that?"

If you're about to add memory to an agent, try the boring version first. Index the text. Summarize the old stuff. Search by words. Measure where it genuinely fails before you reach for the embeddings. There's a decent chance, like me, you'll be surprised how rarely you need to.

If you've shipped agent memory both ways, I'd like to hear where full-text search ran out of road for you — that boundary is the actually-interesting question, and nobody seems to write it down.

I added up everything Google gives developers for free after I/O 2026. It's kind of absurd

amionweb — Sat, 23 May 2026 16:23:28 +0000

This is a submission for the Google I/O 2026 Writing Challenge

I added up everything Google gives developers for free after I/O 2026. It's kind of absurd.

Most of the I/O 2026 coverage is about whether AI is coming for our jobs. I went looking for something more practical and, honestly, more fun: how much can you actually build without paying Google a cent?

I expected "a free trial and then a paywall." What I found, after poking around AI Studio and the docs, is that you can build a genuinely real AI app — multimodal, grounded in live search, even fully offline — for $0. Here's the complete free stack after I/O 2026, what you can build with it, and where the free ceiling actually is.

1. AI Studio itself — a free playground for every model

Google AI Studio is free to use in your browser. No credit card. You get a playground for the entire model lineup — Gemini 3.5 Flash, the image models, video, speech — plus the run settings that matter: temperature, the Thinking level dial, structured outputs, function calling, and a one-toggle Grounding with Google Search.

For a beginner, this alone is huge: you can test prompts against frontier models, see exactly how each setting changes the output, and click "Get code" to export a working snippet — before writing a single line yourself. It's the cheapest way to learn what these models can do, and it costs nothing.

💡 [Screenshot spot: the AI Studio playground with a model selected and the free run-settings panel visible.]

2. The Gemini API free tier — enough to prototype a real app

The Gemini API has a free tier you can use with an API key from AI Studio. It's rate-limited (limited requests per minute and per day), but for learning, prototyping, and small projects it's genuinely enough to ship something real.

That means you can wire Gemini 3.5 Flash or 3.1 Flash Lite into a side project — a chatbot, a summarizer, a classifier — and run it for free while you build. You only start paying when you graduate to production volume. For most people learning this stuff, you'll build three projects before you ever hit a bill.

(Rate limits change over time — check the current free-tier limits before you architect around them.)

3. 5,000 free Google Search groundings a month

This is the one that surprised me. AI models have a knowledge cutoff — they don't know recent events. The fix is grounding: letting the model search Google before answering. And Google gives you 5,000 grounded prompts per month for free (after that it's about $14 per 1,000).

5,000 free real-time-grounded answers a month is plenty for a personal project or an early-stage app. Your free chatbot can answer questions about today's news, not just its training data. Flip one toggle in AI Studio and it just works.

4. Gemma 4 — not a free tier, actually free forever

Here's where "free" stops meaning "free tier" and starts meaning yours.

Gemma 4 is Google's open-weight model family, released under a license that lets you download the weights and run them on your own hardware — no API, no key, no per-token cost, ever. The small versions (the ~2B and ~4B "E-series") run on a laptop, a phone, even a Raspberry Pi. The bigger ones (a 26B mixture-of-experts and a 31B dense model with a 256K context window) run on a decent GPU.

The implications are wild for a beginner: you can build an AI app where nothing is metered and nothing leaves your machine. Download once from Hugging Face or Kaggle, and your inference cost is exactly zero, forever. For anything privacy-sensitive — personal data, offline tools — this is the whole game.

5. Free image, voice, and more (in the playground)

In AI Studio you can also experiment for free with the parts of the stack people assume cost money on day one:

Image generation — try Imagen and the "Nano Banana" image models right in the playground.
Speech — text-to-speech voices you can steer with prompts.
Real-time voice — the Live API for talking to a model out loud.

You won't run these at production scale for free, but for learning what's possible and building a demo, the playground is an open sandbox.

What you can actually build for $0

Stack it all together and a beginner can ship, for free:

A multimodal chatbot (text + image input) on the Gemini free tier...
...that stays current using the 5,000 free monthly Google searches...
...prototyped and debugged entirely in AI Studio's free playground...
...or, if privacy matters, rebuilt to run 100% offline and unmetered on Gemma 4.

That's not a toy. That's a real, shippable app, built on a $0 budget. A year ago this would have cost real money or required a research lab.

The honest catch

Free isn't infinite, and pretending otherwise will burn you:

Free-tier rate limits are real. You'll hit requests-per-minute caps fast if you loop API calls — batch your work and design around the limits (I learned this the hard way).
Prompts on the free tier may be used to improve Google's models. Don't send anything sensitive through the free API. (This is exactly where running Gemma 4 locally earns its keep.)
Preview models can change or vanish. Don't hard-code a preview model into something you can't easily update.
"Free to prototype" ≠ "free at scale." The moment you have real traffic, you'll cross into paid — so know which model tier you're on before you grow (the price gap between tiers can be 6×).

The takeaway

The loudest story out of Google I/O 2026 is about AI replacing developers. The quieter, more useful story is that the cost of becoming one of those developers just dropped to zero. A free playground, a free API tier, 5,000 free grounded searches a month, and a genuinely free, run-it-yourself model family — that's a complete on-ramp, and it costs nothing but your time.

If you've been waiting for a "good time" to start building with AI, this is it. Open AI Studio, grab a free key, and ship something this weekend. The only thing it'll cost you is the afternoon.

Free-tier details, grounding allowances, and model availability are from Google AI Studio and the Gemini API docs during the I/O 2026 window; limits change, so verify the current numbers before relying on them. I drafted this post with AI assistance and verified the free-tier specifics against Google's docs and AI Studio myself.

Your AI can read. Gemma 4 can see

amionweb — Sat, 23 May 2026 07:20:24 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

Your AI can read. Gemma 4 can see. Here's what that actually changes.

For two years, talking to an AI meant typing. You described things in words, the AI answered in words. If you wanted help with a photo, a handwritten note, or a screenshot, you first had to translate it into a paragraph — and hope you didn't leave out the part that mattered.

Gemma 4 is multimodal, which is a clunky word for a simple idea: you can show it a picture instead of describing one. I spent an afternoon doing exactly that, and the gap between "tell the AI" and "show the AI" turned out to be bigger than I expected.

Here's what multimodal actually means, three things I showed it, and how you can try it yourself in about five minutes — free, no fancy hardware.

"Multimodal" in one sentence

A mode is a type of input: text is one mode, images are another, audio is a third.

A text-only model is like texting a friend who can only read words. A multimodal model is like video-calling that friend — you can hold something up to the camera and they just see it.

Gemma 4 handles text, images, and audio through the same model. You don't bolt on a separate "image reader." The thing that understands your sentence is the same thing that understands your photo. That matters more than it sounds, and the examples make it obvious.

Three things I showed it

I didn't write clever prompts. I literally uploaded a photo and asked a plain question, the way you'd ask a knowledgeable friend.

1. A drooping houseplant. I uploaded a photo of a sad-looking plant and asked, "What's wrong with this?" It pointed out the yellowing lower leaves and damp-looking soil and suggested I was overwatering — and to check that the pot actually drained. I never told it the leaves were yellow. It looked.

2. A handwritten grocery list. My handwriting is genuinely bad. I snapped a photo and asked it to type the list out. It read all but one item correctly (it guessed "tomatoes" where I'd scrawled something closer to "tamarind" — fair). Typing that list myself would've taken longer than photographing it.

3. A screenshot of a line chart with no title. I asked, "What's the trend here?" It described the steady climb, called out the dip in the middle, and noted the sharp rise at the end — reading the shape of the data, not just labels. For someone who finds charts intimidating, that's a quiet superpower.

None of this was perfect. It got one grocery item wrong, and if I'd asked it to read tiny dense text it would've struggled. But "show instead of describe" changes the kind of help you can ask for. You stop being the translator.

Why this is a bigger deal than it looks

Three reasons this matters beyond the novelty:

You skip the translation step. Describing an image in words is lossy and slow. A photo carries everything at once — color, layout, handwriting, the thing you didn't think to mention.
It opens AI to people who don't love typing. Point a camera at a problem and ask about it. That's a far lower bar than composing the perfect prompt.
The small versions run on your own machine. Gemma 4 comes in sizes small enough to run on a laptop or even a phone, offline. So "show the AI a photo" doesn't have to mean "upload my private photo to someone's server." It can all happen on your device. For anything personal — documents, medical photos, your kid's homework — that's the difference between useful and no thanks.

That last point is the one I keep coming back to. A model that can see, running entirely on hardware you own, with no internet connection, would have sounded like science fiction in 2023. It's a free download in 2026.

Try it yourself in five minutes

You don't need a powerful computer to start. Two paths, easiest first.

Path A — zero install (browser, free)

Go to Google AI Studio (aistudio.google.com) and sign in with a Google account.
Start a new prompt and pick a Gemma 4 model from the model dropdown.
Click the image/upload icon, add any photo from your computer — a plant, a receipt, a whiteboard, a chart.
Type a plain question: "What is this?" or "Read the text in this image."
Watch it answer based on what it sees.

That's the whole thing. No setup, no card, no code.

Path B — run it on your own machine (offline, private)

If you want it running locally with nothing leaving your computer:

Install Ollama from ollama.com (one download, Windows/Mac/Linux).
Open a terminal and pull the small multimodal model:

   ollama run gemma4:e4b

The first run downloads the model once (a couple of gigabytes). After that it works with no internet.

In the chat prompt, point it at an image file on your computer and ask your question. It reads the picture locally — nothing uploaded.

Start with Path A to feel the magic, switch to Path B when you want privacy.

What I'd explore next

The thing I want to try next is audio: Gemma 4 hears as well as sees, which means you could hand it a voice memo and a photo together and ask one question about both. We're early in figuring out what that unlocks.

But the simple version is already enough to change how I use AI day to day. I type less. I show more. And the friend on the other end of the video call finally has eyes.

If you try it, show it something weird and tell me what it said — that's the fun part.

Want to go deeper? The official models are on Hugging Face and Kaggle, all free to download.

RoboFire: Cloud Clash Game Challenge Submission: Alibaba Cloud Web Game

amionweb — Sun, 27 Apr 2025 10:35:47 +0000

This is a submission for the Alibaba Cloud Challenge: Build a Web Game.*

What I Built

An exciting arcade-style game where you control a robot shooting down clouds and collecting coins while avoiding dangerous obstacles!

Demo

Live url: https://robo-fire.vercel.app/

amionweb / robo-fire

RoboFire: Cloud Clash 🤖☁️

An exciting arcade-style game where you control a robot shooting down clouds and collecting coins while avoiding dangerous obstacles!

🎮 Play Now

Play RoboFire: Cloud Clash

✨ Features

🎯 Intuitive controls with keyboard support
🌟 Beautiful visual effects and animations
🎨 Smooth gameplay mechanics
📈 Progressive difficulty system
🏆 High score tracking
🎵 Engaging sound effects
📱 Responsive design

🕹️ How to Play

Use Arrow keys or WASD to move your robot
Press Spacebar to shoot at clouds
Collect falling coins to score points
Avoid obstacles (lightning bolts and asteroids)
Reach level 10 to win!

🚀 Getting Started

# Clone the repository
git clone https://github.com/amionweb/robo-fire

# Navigate to the project directory
cd robofire-cloud-clash

# Install dependencies
npm install

# Start the development server
npm run dev

🛠️ Built With

React
TypeScript
HTML5 Canvas
TailwindCSS
Vite

🎯 Game Mechanics

Clouds: Shoot them to create collectible coins
…

View on GitHub

☁️ Alibaba Cloud Services Implementation

For RoboFire: Cloud Clash, I used Alibaba Cloud Object Storage Service (OSS) to host and serve the static game files, and configured a custom domain for a professional, fast-loading experience.

Services Used:

Object Storage Service (OSS)
- Why: OSS provides a highly reliable, scalable, and cost-effective way to store static web assets like HTML, CSS, JavaScript, and images.
- How Integrated:
- Built the game locally with npm run build.
- Uploaded the build folder contents directly to an OSS bucket.
- Configured the bucket for static website hosting (setting the index document to index.html).
- Experience: OSS made it extremely easy to deploy updates — I just re-upload the latest build files. The performance was excellent with low latency globally.
Domain Management + Custom Domain Binding
- Why: Custom domains make the game more shareable and professional.
- How Integrated:
- Purchased or linked an existing domain via Alibaba Cloud Domains.
- Mapped the domain to my OSS bucket via a CNAME record.
- Configured HTTPS using Alibaba Cloud SSL certificates for secure access.
- Experience: Domain setup was straightforward following Alibaba Cloud's documentation. Enabling HTTPS ensured that game assets loaded securely without browser warnings.

Benefits:

Fast content delivery worldwide
Very low maintenance and update cost
Scalable without worrying about backend servers

Challenges:

The initial learning curve with setting correct bucket permissions (public read) for the static website.
Slight delay (~10–15 mins) when applying custom domain settings and SSL.

🎯 Game Development Highlights

Simple Yet Addictive Gameplay:

I designed RoboFire: Cloud Clash to have a fast gameplay loop — move, shoot, collect, avoid — making it highly engaging even with minimal mechanics.

Progressive Difficulty

One of the coolest features is the dynamic level system. As players collect coins, the enemy cloud speed increases, making higher levels genuinely challenging without introducing complex new elements.

Clean Responsive Canvas Integration

Using HTML5 Canvas inside a React environment with Vite made rendering super fast and allowed the game to adapt nicely to different screen sizes (desktop, tablet, mobile).

Retro-Futuristic Visuals

I’m especially proud of the polished visual design — a clean, modern robot combined with nostalgic arcade-style effects like glowing coins and cloud explosions.

Optimized Performance

Despite animations and firing mechanics, the game remains lightweight (~a few MBs), fast-loading, and smooth at 60fps even on lower-end devices.

From Components to Creativity: Building a Portfolio with KendoReact

amionweb — Mon, 24 Mar 2025 06:45:29 +0000

This is a submission for the KendoReact Free Components Challenge.

What I Built

I built a personal portfolio website using React and KendoReact components. The portfolio showcases my skills, experience, projects, and testimonials from clients. The website is designed to be responsive, with a clean and modern UI that adapts to both light and dark themes. The portfolio includes several sections such as:

Hero Section: A visually appealing introduction with a 3D animated background and a call-to-action to download my resume or get in touch.
About Section: A brief introduction about myself, my skills, and what I specialize in.
Experience Section: A timeline of my professional experience, highlighting key roles and responsibilities.
Projects Section: A showcase of my featured projects, including technologies used and completion status.
Technologies Section: A detailed breakdown of my technical skills, categorized by frontend, backend, and DevOps.
Testimonials Section: Client testimonials with ratings, displayed in a grid layout for desktop and a carousel for mobile.
Contact Section: A form for visitors to get in touch with me, along with my contact information and social media links.

The portfolio is built with a focus on user experience, leveraging animations and transitions to create a smooth and engaging browsing experience.

Demo

https://kendo-portfolio-lemon.vercel.app/

amionweb / kendo-portfolio

KendoReact Experience

I leveraged KendoReact's free components extensively throughout the portfolio to create a polished and professional UI. Here are some of the key components I used:

Card Components: Used in multiple sections (About, Experience, Projects, Testimonials) to display content in a structured and visually appealing way.
TileLayout: Used in the About section to display my skills in a grid layout with staggered animations.
Fade Animation: Applied across various sections to create smooth fade-in animations as the user scrolls through the page.
Button Components: Used for call-to-action buttons, theme toggling, and navigation.
ProgressBar: Used in the Projects and Technologies sections to visually represent skill levels and project completion status.
Chip and ChipList: Used in the Projects section to display the technologies used in each project.
Avatar: Used in the Testimonials section to display client images.
Input and Label: Used in the Contact section for the form fields.
Drawer: Used in the mobile navigation menu to provide a smooth and responsive user experience.
AppBar: Used for the navigation bar, which is fixed at the top and adapts to the scroll position.

By using these KendoReact components, I was able to focus more on the overall design and functionality of the portfolio, rather than spending time building UI components from scratch. The components provided by KendoReact are highly customizable and integrate seamlessly with React, making the development process efficient and enjoyable.

AIm to Impress

Delightfully Designed

Kendo React Challenge Submission

amionweb — Mon, 24 Mar 2025 06:26:56 +0000

This is a submission for the KendoReact Free Components Challenge.

What I Built

Demo

KendoReact Experience

AIm to Impress

Delightfully Designed

Stellar contract CRUD Tutorial: Smart Contract Challenge

amionweb — Mon, 19 Aug 2024 06:55:47 +0000

This is a submission for the Build Better on Stellar: Smart Contract Challenge : Create a Tutorial

Your Tutorial

Stellar contract CRUD Tutorial A Step-by-Step Guide from Zero to Hero

amionweb ・ Aug 19 '24

#stellarchallenge

Here’s a structured submission for the "Build Better on Stellar: Smart Contract Challenge":

What I Created

For the "Build Better on Stellar: Smart Contract Challenge," I developed a comprehensive smart contract for managing products on the Stellar blockchain. This contract includes CRUD (Create, Read, Update, Delete) operations, allowing users to manage product listings effectively. The functionalities include:

Create a Product: Adds a new product to the system with details like name, description, and price.
Get a Product by ID: Retrieves a product's details using its unique ID.
Update a Product: Updates the product's details, including its name, description, and price.
Delete a Product: Marks a product as inactive without removing it from storage.
Permanently Delete a Product: Completely removes a product from storage.
Delete All Products: Clears all products from the system.

This contract enhances the Stellar developer experience by providing a practical example of managing data through smart contracts. Developers can utilize this contract as a blueprint for their own projects, easily adapting it to different use cases by modifying the product data structure or extending functionalities.

Journey

Research and Content Creation

My journey began with researching the Stellar smart contract capabilities and the Soroban SDK, which is used to build smart contracts on Stellar. I studied existing examples and documentation to understand best practices and the nuances of developing smart contracts in Rust.

Motivation

The motivation behind this submission was to create a flexible and practical example of a smart contract that could be immediately useful to other developers. The goal was to provide a straightforward implementation of CRUD operations, which are fundamental for many applications. By using this example, developers can get a head start on building and deploying their own smart contracts.

Learning and Experience

Throughout this process, I gained a deeper understanding of:

Smart Contract Development: From writing and deploying smart contracts to handling data persistence on the Stellar blockchain.
Stellar Ecosystem: How to interact with the Stellar network using Soroban SDK and the specific requirements for smart contracts.
Rust Programming: Leveraging Rust for building secure and efficient smart contracts.

I am particularly proud of creating a well-documented and functional contract that simplifies the complexities of smart contract development on Stellar. It is designed to be a practical resource for beginners and experienced developers alike.

Future Goals

Moving forward, I plan to:

Extend Functionality: Add features such as user authentication and role-based access control to the contract.
Improve Documentation: Create more detailed tutorials and examples to help developers integrate and customize smart contracts in their projects.
Explore Other Use Cases: Develop smart contracts for different applications, such as financial transactions or decentralized voting systems, to broaden the scope of practical implementations on Stellar.

This submission represents a foundational step in the journey of integrating smart contracts into real-world applications on the Stellar blockchain. It is designed to be both educational and practical, providing a valuable tool for developers looking to build on Stellar.

Stellar contract CRUD Tutorial A Step-by-Step Guide from Zero to Hero

amionweb — Mon, 19 Aug 2024 06:55:24 +0000

In this tutorial, we'll guide you through creating a Stellar smart contract from scratch. You'll learn how to implement basic CRUD (Create, Read, Update, Delete) operations for managing products in a decentralized application (dApp). By the end of this tutorial, you'll be able to add, update, delete, view, and get all products using a Stellar smart contract.

Prerequisites

Before we dive into the code, make sure you have the following:

Set Up Environment / Project Installation Guide

A) Environment Setup:

Install Rust, using command:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
nstall the Soroban CLI using below mentioned command. For more info visit => Soroban docs
cargo install --locked soroban-cli
Install Node.js
Get the Freighter Wallet extension for you browser.
Once enabled, then got to the network section and connect your wallet to the testnet.
Install wasm32-unknown-unknown package using command:
rustup target add wasm32-unknown-unknown
To configure your CLI to interact with Testnet, run the following command:

soroban network add \
  --global testnet \
  --rpc-url https://soroban-testnet.stellar.org:443 \
  --network-passphrase "Test SDF Network ; September 2015"

Step 1: Setting Up the Project

First, create a new Rust project by running the following command in your terminal:

stellar contract init product-crud

Navigate to the project directory:

cd product-crud

These dependencies allow us to interact with Stellar's Soroban platform.

Step 3: Defining the Product Struct

In your lib.rs file, start by defining the Product struct. This struct will hold the details of each product.

#![no_std] // We don't use the Rust standard library in smart contracts
use soroban_sdk::{contracttype, Env, String};

// Struct to represent a product in our dApp
#[contracttype]
#[derive(Clone)]
pub struct Product {
    pub id: u64,              // Unique ID for the product
    pub name: String,         // Name of the product
    pub description: String,  // Description of the product
    pub price: u64,           // Price of the product
}

Explanation:

The Product struct is defined with fields such as id, name, description, and price. This struct will store information about each product.

Step 4: Setting Up the Contract

Next, define the main contract structure and the CRUD operations. Here's how you can start:

use soroban_sdk::{contract, contractimpl, symbol_short, Symbol};

// Define a contract type called ProductContract
#[contract]
pub struct ProductContract;

// Enum for referencing product storage
#[contracttype]
pub enum Productbook {
    Product(u64),
}

// Symbol to track the total count of products
const COUNT_PRODUCT: Symbol = symbol_short!("C_PROD");

Explanation:

The ProductContract struct is defined as the main contract.
Productbook is an enum used to store and retrieve products by their ID.
COUNT_PRODUCT is a symbol used to track the number of products stored.

Step 5: Implementing the Create Operation

Now, let's implement the function to create a new product.

#[contractimpl]
impl ProductContract {
    pub fn create_product(
        env: Env,
        name: String,
        description: String,
        price: u64,
    ) -> u64 {
        let mut count_product: u64 = env.storage().instance().get(&COUNT_PRODUCT).unwrap_or(0);
        count_product += 1;

        let new_product = Product {
            id: count_product,
            name,
            description,
            price,
        };

        env.storage()
            .instance()
            .set(&Productbook::Product(new_product.id.clone()), &new_product);
        env.storage().instance().set(&COUNT_PRODUCT, &count_product);

        log!(&env, "Product Created with ID: {}", new_product.id);

        new_product.id
    }
}

Explanation:

The create_product function increments the count_product by 1 and creates a new product with the provided details.
The product is then stored in the contract's storage, and the ID of the newly created product is returned.

Step 6: Implementing the Read Operation

Let's add a function to retrieve a product by its ID.

impl ProductContract {
    pub fn get_product_by_id(env: Env, product_id: u64) -> Product {
        let key = Productbook::Product(product_id);

        env.storage().instance().get(&key).unwrap_or(Product {
            id: 0,
            name: String::from_str(&env, "Not Found"),
            description: String::from_str(&env, "Not Found"),
            price: 0,
        })
    }
}

Explanation:

The get_product_by_id function retrieves a product from storage by its ID. If the product is not found, it returns a default Product with "Not Found" values.

Step 7: Implementing the Update Operation

Now, add a function to update the details of an existing product.

impl ProductContract {
    pub fn update_product(
        env: Env,
        product_id: u64,
        new_name: Option<String>,
        new_description: Option<String>,
        new_price: Option<u64>,
    ) {
        let key = Productbook::Product(product_id);
        let mut product = Self::get_product_by_id(env.clone(), product_id);

        if let Some(name) = new_name {
            product.name = name;
        }
        if let Some(description) = new_description {
            product.description = description;
        }
        if let Some(price) = new_price {
            product.price = price;
        }

        env.storage().instance().set(&key, &product);

        log!(&env, "Product with ID: {} has been updated.", product_id);
    }
}

Explanation:

The update_product function allows updating the product's name, description, and price. If new values are provided, they replace the existing ones.

Step 8: Implementing the Delete Operation

Finally, let's implement a function to delete a product by its ID.

impl ProductContract {
    pub fn delete_product(env: Env, product_id: u64) {
        let key = Productbook::Product(product_id);

        if env.storage().instance().has(&key) {
            env.storage().instance().remove(&key);

            log!(&env, "Product with ID: {} has been deleted.", product_id);
        } else {
            log!(&env, "Product with ID: {} does not exist.", product_id);
        }
    }
}

Explanation:

The delete_product function removes a product from storage by its ID. If the product doesn't exist, a message is logged.

Step 9: Implementing the Get All Products Operation

Lastly, let's add a function to retrieve all products.

impl ProductContract {
    pub fn get_all_products(env: Env) -> Vec<Product> {
        let count_product: u64 = env.storage().instance().get(&COUNT_PRODUCT).unwrap_or(0);
        let mut products = Vec::new(&env);

        for i in 1..=count_product {
            let product = Self::get_product_by_id(env.clone(), i);
            products.push_back(product);
        }

        products
    }
}

Explanation:

The get_all_products function iterates through all the stored products and returns them as a vector.

Step 10: Testing and Deploying the Contract

In order to deploy the smartcontract you will need an account. You can either use the an account from the Freighter Wallet or can configure an account named alice in the testnet using the command:
soroban keys generate --global alice --network testnet
You can see the public key of account alice:
soroban keys address alice

=> Go inside the /product-crud directory and do the below mentioned steps:

Build the contract:

soroban contract build

Alternte command:

cargo build --target wasm32-unknown-unknown --release

Install Optimizer:

cargo install --locked soroban-cli --features opt

Build an Opmize the contract:

soroban contract optimize --wasm target/wasm32-unknown-unknown/release/hello_world.wasm

Steps to the Deploy smart-contract on testnet:

deploy the smartcontract on the testnet and get deployed address of the smartcontract using the following command:

stellar contract deploy --wasm target\wasm32-unknown-unknown\release\hello_world.wasm  --network testnet --source alice

Deployed address of this smartcontract: contract_address

*NOTE: If you get the XDR Error error: xdr processing error: xdr value invalid, then follow this article.

Invoke functions from the smart-contract:

#### To invoke any of the function from the smartcontract you can use this command fromat.

soroban contract invoke \
  --id <DEPLOYED_CONTRACT_ADDRESS> \
  --source <YOUR_ACCOUNT_NAME> \
  --network testnet \
  -- \
  <FUNCTION_NAME> --<FUNCTION_PARAMETER> <ARGUMENT>

Here are example soroban contract invoke commands for each of the functions in the ProductContract smart contract, using dummy data. Replace <DEPLOYED_CONTRACT_ADDRESS>, <YOUR_ACCOUNT_NAME>, and other placeholders with actual values.

1. Create a Product

soroban contract invoke --id <DEPLOYED_CONTRACT_ADDRESS> --source <YOUR_ACCOUNT_NAME> --network testnet -- create_product --name "Sample Product" --description "A description of the sample product." --price 1000

2. Get a Product by ID

soroban contract invoke --id <DEPLOYED_CONTRACT_ADDRESS> --source <YOUR_ACCOUNT_NAME> --network testnet -- get_product_by_id --product_id 1

3. Update a Product

soroban contract invoke --id <DEPLOYED_CONTRACT_ADDRESS> --source <YOUR_ACCOUNT_NAME> --network testnet -- update_product --product_id 1 --new_name "Updated Product" --new_description "Updated description of the product." --new_price 1200

4. Delete a Product

soroban contract invoke --id <DEPLOYED_CONTRACT_ADDRESS> --source <YOUR_ACCOUNT_NAME> --network testnet -- delete_product --product_id 1

5. Permanently Delete a Product

soroban contract invoke --id <DEPLOYED_CONTRACT_ADDRESS> --source <YOUR_ACCOUNT_NAME> --network testnet -- delete_product_permanently --product_id 1

6. Delete All Products

soroban contract invoke --id <DEPLOYED_CONTRACT_ADDRESS> --source <YOUR_ACCOUNT_NAME> --network testnet -- delete_all_products

Explanation of Parameters

--id <DEPLOYED_CONTRACT_ADDRESS>: The address where the smart contract is deployed.
--source <YOUR_ACCOUNT_NAME>: The account name used to invoke the contract.
--network testnet: The network on which the contract is deployed (e.g., testnet).
<FUNCTION_NAME>: The function you want to invoke in the smart contract.
<FUNCTION_PARAMETER <ARGUMENT>: The parameters required by the function.

Replace placeholders with actual values to interact with your deployed contract on the Stellar testnet.

Conclusion

Congratulations! You've successfully created a Stellar smart contract that performs CRUD operations for managing products. This guide walked you through setting up a Rust project, defining the contract and product structure, and implementing each CRUD operation step by step. You can now use this knowledge to build more complex dApps on the Stellar network.