DEV Community: Valery Odinga

Trust, but Verify: Fighting Credential Fraud with Solana

Valery Odinga — Tue, 02 Jun 2026 20:45:40 +0000

A mother walked into a neighbourhood pharmacy and handed over a prescription for her sick child. The chemist reached for a bottle, dispensed the medicine with confidence, and told her how to apply it. She went home and did exactly what she was told.

The medicine was wrong. It was meant for adult dermatological use. Applied to a child's eyes, the damage was irreversible.

The chemist wasn't necessarily malicious. But something had failed long before that counter interaction, there was no easy way to verify that this person was actually qualified to dispense prescription medicine. No quick check. No public record a patient could pull up on their phone before handing over trust.

We check Yelp reviews before visiting a restaurant. We check ratings before getting into an Uber. But the pharmacist who handles our prescriptions, the electrician wiring our home, the contractor managing our building, for these we largely take their word for it, or at best call a licensing board that might or might not pick up.

That bothered us. And it led our group to start building Veryfy.

The Real Problem: Credentials Live in Silos
Professional licenses, certifications, and service authorisations exist, but they're scattered. They live in government databases, PDF certificates pinned to office walls, or email attachments. To verify one, you either:

Call an office that's open 9–5, or
Trust a paper document that could have been printed this morning.
The information asymmetry is staggering. The professional always knows exactly what their credentials say. The patient, the customer, the client, they're almost always flying blind.

What if a license was something you could independently verify in seconds, from your phone, before you walked into that pharmacy? No phone call. No middleman. Just a hash, a blockchain, and a yes or no.

That's the idea behind Veryfy, a decentralised credential verification protocol we are currently developing.

What Veryfy Does
Veryfy is an on-chain license verification protocol built on Solana. In plain terms:

An issuer (a licensing body, an institution, a platform) registers on-chain and issues a license tied to a specific credential or asset.
That license is written to the blockchain permanently, publicly, and tamper-proof.
Anyone:- a patient, a customer, an auditor can verify that license instantly, without asking the issuer.
No more "trust me, I'm licensed." The license speaks for itself.

How It Works
It's in three parts:

The Blockchain Layer (the source of truth) Every license is stored as a record on the Solana blockchain. It holds: who issued it, who holds it, whether it's active or revoked, and when it expires. Once written, nobody, not even the issuer can quietly change it. Revoking a license creates a new public record, not a silent deletion.

The API Layer (the bridge) A lightweight Go server handles the off-chain logic: hashing documents, validating requests, exposing clean HTTP endpoints. This is what a hospital system, a pharmacy app, or a government portal would integrate with.

The Web App A React frontend gives issuers a dashboard to issue and revoke licenses, and gives anyone a public verification page scan the QR code, and instantly see if the license is real.

A Peek Under the Hood
If you're technical, here's the part that makes it work cleanly.

Each license is stored as a Program Derived Address (PDA) on Solana- an account whose address is deterministically derived from the content it represents. Specifically, it's seeded by a 32-byte SHA-256 hash of the credential document:

rust
seeds = [b"license", asset_hash.as_ref()]

,
This means: given any document, you can compute its hash and look up exactly one on-chain record no index, no search, no intermediary. The blockchain address is the lookup key.

A license record looks like this:

rust
pub struct License {
    pub holder: Pubkey,          // who holds the license
    pub issuer: Pubkey,          // who issued it
    pub status: LicenseStatus,   // Active | Revoked | Expired
    pub expiry: i64,             // 0 = never expires
    pub asset_hash: [u8; 32],   // the credential's fingerprint
}

And only the registered issuer authority can revoke it enforced at the contract level, not just in application logic:

rust
#[account(
    has_one = authority @ VeryfyError::UnauthorizedIssuer,
)]
pub issuer: Account<'info, Issuer>,

Back to That Pharmacy
Imagine this instead: the pharmacy's license is issued on-chain by the national pharmaceutical regulatory body. Before a patient enters, they scan a QR code on the door. The app hashes the pharmacy's registration document, looks it up on-chain, and returns:

License Active - Issued by National Pharmacy Council- Valid until Dec 2026

Or:

License Revoked - Revocation recorded 14 March 2025

No phone call. No trusting a certificate in a frame. Just a public, unforgeable record.

That's not science fiction. The infrastructure to do this already exists. What's been missing is a standardised way to put credentials on-chain and make verification dead simple.
Trust, but Verify: Fighting Credential Fraud with Solana

Veryfy is currently under active development. We have built a functional prototype running on a local Solana validator with a connected React UI and Go API, but we are working hard to expand it. Our immediate roadmap includes:

License Renewal - completing the on-chain implementation for extending license validity.
QR Code Verification Flow - so the pharmacy-door scenario above is a real UX, not just a thought experiment.
Institutional Integrations - working with licensing bodies to pilot real credential issuance.
Try It / Contribute
The full source code is open on GitHub: github.com/odingaval/veryfy.git

Since Veryfy is actively under development, we welcome contributions! The stack is Rust (Anchor), Go, and React/TypeScript - if any of those are your world, we would love to have you collaborate with us.

And if you've ever been on the wrong side of an unverifiable credential as a patient, a customer, or someone who's had to just hope the person helping them was who they said they were, we'd genuinely like to hear your story in the comments. That's the problem we are trying to solve.

Building Cursor for Community: A Buildathon Built on Time Pressure

Valery Odinga — Mon, 25 May 2026 17:26:08 +0000

Over the weekend, I attended an event hosted by Cursor Kenya, bringing together developers, builders, and tech enthusiasts to explore modern AI-assisted development workflows and collaboration tools.

The sessions focused on how developers can build faster using AI, improve productivity, and rethink how software is developed in collaborative environments. We also got introduced to tools like Sentry for monitoring and debugging applications, received credits to experiment with, and later moved into a buildathon challenge.

What followed was not just a coding exercise, but a very tight constraint problem: we had one hour to build a working prototype.

That constraint became the foundation of everything we built.

The Reality of Hackathons and Time Constraints

Anyone who has participated in hackathons or coding competitions knows that time is the most limiting resource.

In theory, teams are supposed to:

brainstorm ideas,
design a solution,
divide tasks,
build a working prototype,
and prepare a demo all within a few hours or days.

In reality, most of the time disappears into coordination.

Even simple things like:

Who is working on what?
Has this feature been pushed?
Can someone review this?
Where is the latest version?

…become friction points.

And in fast-paced environments like hackathons, bootcamps, or team coding sessions, that friction slows everything down.

During the buildathon, that limitation was very visible because the time window was extremely small, just 60 minutes.

Where the Idea Started

The idea for Cursor for Community did not start as a product idea. It started as a response to the constraint.

We quickly realized that if time is the biggest limitation, then anything that adds delay to collaboration becomes a problem.

Most developer workflows rely heavily on:

pushing code to GitHub,
waiting for updates,
reviewing changes after commits,
and communicating separately through chat tools.

That works in normal development cycles, but not in time-bound environments.

So instead of trying to optimize existing workflows, we asked a different question:

What if collaboration happened in real time, inside the coding environment itself?

That question became the foundation of the project.

Building Cursor for Community

Cursor for Community was designed as a collaboration platform for hackathons, bootcamps, and any environment where multiple developers build together under time pressure.

The main goal was simple: reduce the delay between writing code and collaborating on it.

Instead of waiting for commits or pull requests, developers could work in a shared space where progress is visible instantly.

The system focused on three core ideas:

real-time visibility,
faster feedback loops,
and reduced coordination overhead.

This allowed teams to stay focused on building rather than managing workflow transitions.

Real-Time Code Tracking

One of the core features was live code tracking.

Instead of waiting for someone to push changes to GitHub, team members could join a shared workspace and see updates as they happened.

This changed the collaboration model from:

“push → wait → review”

to:

“write → see → react”

This small shift significantly reduces the lag between development and feedback, especially in time-constrained environments like hackathons.

It also makes it easier for teammates to stay aligned without constant status updates.

Team Chat for Fast Coordination

To support collaboration, we added a team chat system inside the platform.

The goal was not to replace existing communication tools, but to keep communication close to the code.

Instead of switching between messaging apps and code editors, teams could:

ask questions,
coordinate tasks,
and resolve blockers quickly in the same environment.

This reduced context switching, which is often one of the biggest productivity killers in fast-paced development.

AI Agent Chat for Development Support

We also integrated an AI agent chat directly into the workspace.

This allowed developers to:

ask coding questions,
debug issues faster,
get explanations,
and receive suggestions while building.

Rather than leaving the environment to search for answers, teams could interact with an AI assistant in real time while coding.

This was especially useful during the buildathon, where every minute mattered and blocking issues needed immediate resolution.

Mentor Mode for Guided Collaboration

Another important feature was mentor integration.

Mentors could join the workspace directly, observe what teams were building, and provide guidance in real time.

This made mentorship more interactive:

debugging could happen live,
architectural suggestions could be given immediately,
and teams could get feedback without breaking their flow.

Instead of mentorship happening in scheduled check-ins, it became part of the development process itself.

Tools, Support, and Buildathon Environment

During the event, we also got exposure to observability and debugging tools like Sentry, along with credits that helped teams experiment quickly.

The environment encouraged rapid prototyping,not polished production systems, but functional ideas built under pressure.

That setup aligned perfectly with the challenge: build something useful in a very short time window.

Outcome and Ranking

By the end of the buildathon, our project ranked 3rd overall.

But more importantly, we managed to turn a constraint into a product idea and build a working prototype within the limited time.

The one-hour constraint was not just part of the challenge it shaped the direction of the idea itself.

It highlighted how much of development time is often lost not in writing code, but in coordinating work between people.

Cursor for Communities emerged from that realization: that collaboration tools matter just as much as coding tools, especially when time is limited.

Not Everyone Has a GPU: My Gemma Hackathon Experience

Valery Odinga — Thu, 21 May 2026 05:21:38 +0000

When I joined the Gemma 4 challenge on DEV Community, I was genuinely excited. I had been looking forward to experimenting with modern open AI models in a real project environment and pushing myself technically during the hackathon.

Like most developers entering hackathons, I started with big ideas.

I wanted to build something meaningful, something that would really showcase what Gemma could do. On paper, everything looked possible. But once I started working locally, reality kicked in very quickly.

My hardware simply could not keep up with the setup I originally wanted.

At first, I tried forcing things to work. I closed every unnecessary application, monitored memory usage constantly, and spent hours messing with configurations just to make things run. Some attempts were painfully slow, others failed completely, and at certain moments my machine sounded like it was doing more than it should have.

That was the moment I had to make a decision.

I could either spend the entire hackathon fighting hardware limitations, or I could adapt and continue building with what I actually had.

So I pivoted.

Instead of using the larger setup I had originally planned for, I switched to Gemma 2B. At that point, I focused on building my hackathon project: AfyaKuu.

AfyaKuu is an offline-first, privacy-preserving AI diagnostic and training platform designed for healthcare workers in low-resource, disconnected environments.

Powered by Google Gemma 2, AfyaKuu provides real-time clinical support and interactive nurse education without requiring a single byte of internet connectivity.

The idea behind the project was simple but important: bring accessible AI assistance to healthcare workers who often operate in environments where internet access is unreliable or completely unavailable. The system was designed to support decision-making and learning while respecting strict privacy constraints.

Even with the smaller Gemma 2B model, I was able to implement the core functionality and test real interactions. It wasn’t the perfect setup I had imagined at the beginning, but it worked — and that mattered more during a hackathon.

And surprisingly, that constraint changed how I approached building.

Working with limited resources forced me to think more carefully about efficiency, prompt design, and system behavior. I couldn’t rely on brute compute power, so I had to be intentional about every part of the pipeline. In a strange way, the limitation made the system design cleaner and more focused.

It also made me reflect more deeply on accessibility in AI development.

A lot of AI conversations assume access to powerful GPUs, fast cloud infrastructure, and stable internet. But that is not the reality for many developers and users around the world. Students, indie builders, and engineers in low-resource environments are often left out of that narrative.

For projects like AfyaKuu, that gap is not theoretical — it is the entire problem being solved.

Lightweight models like Gemma 2B make it possible to actually deploy AI systems in places where infrastructure is limited. That changes who gets to build, and who gets to benefit.

By the end of the hackathon, I realized the project was no longer just about using Gemma. It became a reminder that innovation does not always happen in ideal conditions. Sometimes it happens through constraints, adaptation, and persistence.

Did I use the setup I originally imagined? No.

Did I still build something meaningful? Yes.

Not everyone has GPUs, cloud credits, or high-end machines.

But people will still build anyway.

TurboQuant: The Google Algorithm That Could Quietly Change the Future of AI

Valery Odinga — Tue, 12 May 2026 09:57:17 +0000

On March 24, 2026, researchers at Google introduced something that, at first glance, sounded almost forgettable:

TurboQuant.
Its just an algorithm.

But hidden inside that algorithm is a solution to one of artificial intelligence’s biggest and most expensive problems: memory.

And surprisingly, memory, may be the real bottleneck slowing AI down.

The Problem Nobody Talks About

Modern AI systems like chatbots and virtual assistants appear almost magical. They remember context, answer questions instantly, summarize documents, and hold conversations that feel natural.

But behind the scenes, these systems are struggling with a growing issue.

Every conversation, every prompt, and every generated response creates more data that the model must keep track of. To do this, large language models use something called a key-value cache, often shortened to a KV cache. This is like AI’s short-term memory.

The longer the conversation becomes, the larger this memory grows. Eventually, memory usage becomes enormous, so much that AI companies spend billions on hardware simply to keep models running efficiently.

In many cases, memory has become a greater limitation than processing power itself.

That is where TurboQuant enters the picture.

What Exactly Is TurboQuant?

TurboQuant is a compression algorithm designed to reduce the amount of memory AI systems need while maintaining performance and accuracy.

In simple terms, it allows AI to remember more while using far less space.

Normally, compression comes with a tradeoff.

Compress a photo too much and it becomes blurry. Compress audio too aggressively and it sounds distorted. The same is usually true for AI data: smaller memory often means lower accuracy.

TurboQuant attempts to break that tradeoff.

According to Google Research, the algorithm can compress AI memory dramatically, in some cases down to only a 3 bits per stored value, while preserving the quality of the model’s responses.

That is what makes it important.

The Two-Pipeline Strategy

TurboQuant does not rely on a single trick. Instead, it works through two connected pipelines.

The first pipeline is called PolarQuant.

Rather than compressing information directly, PolarQuant reorganizes it into a more efficient form. It separates vectors into components such as direction and magnitude, making the data easier to shrink without losing essential meaning.

Imagine giving out directions.

Instead of saying:

“Walk three steps east and four steps north,”
you simply say:
“Walk five steps in this direction.”

The information becomes cleaner and more compact.

The second pipeline uses a mathematical concept called the Johnson–Lindenstrauss lemma through a method known as Quantized Johnson–Lindenstrauss, or QJL.

This stage aggressively compresses the data while preserving relationships between pieces of information.

That detail matters more than it sounds.

AI models do not necessarily need exact numbers. What they need is the ability to preserve relationships — which words relate to each other, which ideas are similar, and which concepts are connected.

QJL helps maintain those relationships even after heavy compression.

Together, the two pipelines allow TurboQuant to shrink memory usage dramatically without severely damaging performance.

Why This Matters More Than People Realize

TurboQuant may not attract the same attention as new AI chatbots or image generators, but its implications are enormous.

Lower memory usage means:

cheaper AI infrastructure,
faster inference speeds,
longer context windows, and the possibility of running advanced models on smaller hardware. That last point is especially important.

Today, the most powerful AI systems depend on expensive GPUs and massive data centers. If algorithms like TurboQuant reduce memory requirements enough, advanced AI could become more accessible to startups, researchers, schools, and developers around the world.

It could also shift the economics of the AI industry itself.

For years, the dominant assumption has been simple: better AI requires bigger hardware. **TurboQuant **challenges that idea by suggesting that smarter compression may matter just as much as raw computing power.

The Quiet Revolution

The most transformative technologies are not always the loudest.

Sometimes progress comes from hidden optimizations deep inside infrastructure, improvements users may never see directly, but experience every day.

If TurboQuant succeeds, AI could become:

faster,
cheaper,
and accessible on smaller devices.

I experienced this limitation firsthand while working on a project that required Gemma 4. My system simply did not have enough RAM to run it without crashing, forcing me to switch to the much smaller Gemma 2B model instead.

That experience revealed that:
the future of AI is not only about building bigger models, but making powerful models efficient enough for everyone to use.

And that is why TurboQuant matters.

Stop Searching, Start Contributing: How GoodFirstGo is Making Open Source Approachable

Valery Odinga — Tue, 31 Mar 2026 20:22:21 +0000

Remember the first time you tried contributing to open source?

If you were like most developers, the experience involved staring at a massive, complex codebase on GitHub, clicking the Issues tab, and immediately feeling overwhelmed. The ecosystem is massive, and while hundreds of maintainers out there are actively asking for help, finding those rare "beginner-friendly" issues requires sifting through mountains of bugs and features that require deep domain knowledge.

I realized developers shouldn't have to write custom GitHub API queries or dig through unrelated repositories just to make their first Pull Request.

That’s exactly why I built GoodFirstGo.

What is GoodFirstGo?
GoodFirstGo is a CLI tool built entirely in Go that brings the perfect open-source issues directly to your terminal.

Instead of mindlessly browsing GitHub, you tell the CLI what language you want to work in, and it hands you a curated list of active repositories searching for help with the good-first-issue label.

Key Features Under the Hood
1.Smart Language Filtering: Want to practice your Python? Rust? Go? Just pass a --language flag.
2.Repository Health Filters: Filter out dead projects by mandating a minimum number of stars (--stars 100).
3.Recency: Nobody wants to comment on an issue from 2008. The --age flag ensures you're only looking at issues created recently, this week, or this month.

Mode: This is my favorite part. By passing the --learning flag, the CLI will output specialized tutorials and resources tailored to the specific language of the issue you are about to tackle!

Seeing it in Action
Because GoodFirstGo compiles down to a single binary, you don't need any complex runtimes or dependencies to use it. If you have Go installed on your machine, getting started takes ten seconds:

bash
go install github.com/odingaval/GoodFirstGo/cmd/goodfirstgo@latest

Once installed globally, you can query GitHub instantly. Let's say I want to find a beginner-friendly Go issue in a repository that has at least 500 stars, and I want to see learning resources for Go before I dive in.

I just type:

bash
goodfirstgo --language go --stars 500 --learning --limit 5

Instantly, I get a clean UI output of 5 high-quality repositories looking for help, right in my terminal window. Add a Github Token to your environment, and it bypasses rate limits entirely.

Why build a CLI instead of a website?
Modern web apps are great, but the Terminal is where developers live. By keeping the tool inside the CLI environment, you can search for issues, clone the resulting repository, and open your IDE without your hands ever leaving the keyboard.

Plus, writing a CLI in Go is just incredibly fun. It leverages Go's standard net/http efficiently alongside Cobra for powerful, responsive shell commands.

Looking to Contribute?
The absolute best part about GoodFirstGo? Because it is a tool explicitly designed to get beginners into open-source software, the project itself is heavily monitored for first-time contributors!

If you've never made an open-source contribution before, cloning the repository and adding a small feature to GoodFirstGo is the perfect place to start.

Check out the source code, download the latest binary, or star the repository here: 👉 github.com/odingaval/GoodFirstGo

Let me know what your first Pull Request ends up being!

Building a Concurrent TCP Chat Server in Go (NetCat Clone)

Valery Odinga — Tue, 24 Mar 2026 13:05:53 +0000

In this project, we built a simplified version of the classic NetCat ("nc") tool — a TCP-based chat server that allows multiple clients to connect, send messages, and interact in real time.

The goal was not just to recreate a chat system, but to deeply understand:

TCP networking
Go concurrency (goroutines & channels)
State management in concurrent systems
Client-server architecture

At its core, the system needed to:

Accept multiple client connections
Allow clients to send messages
Broadcast messages to other clients
Track when users join or leave
Handle unexpected disconnects (like Ctrl+C)

This introduces a key challenge:

«Multiple clients interacting with shared state at the same time.»

TCP Server Basics

The server listens for incoming connections using:

listener, _ := net.Listen("tcp", ":8989")

Then continuously accepts clients:

for {
    conn, _ := listener.Accept()
    go handleConnection(conn)
}

Important concept:

"Accept()" blocks until a client connects
Each client is handled in a separate goroutine

This allows multiple users to connect simultaneously.

Goroutines and Concurrency

Each client runs in its own goroutine:

go handleConnection(conn)

This means:

One slow client does not block others
Each connection is handled independently

However, this introduces a problem:

«Multiple goroutines modifying shared data can cause race conditions.»

The Shared State Problem

We needed to track all connected clients:

var connections map[net.Conn]string

But multiple goroutines might:

Add clients
Remove clients
Broadcast messages

At the same time.

This can cause:

Data corruption
Crashes ("fatal error: concurrent map writes")

Solution 1: Mutex

One approach is using a mutex:

mu.Lock()
connections[conn] = name
mu.Unlock()

But this introduces:

Complexity
Potential deadlocks
Performance bottlenecks

Solution 2: Channels (The Go Way)

Instead of sharing memory, we used channels to communicate changes.

This follows Go’s philosophy:

«“Do not communicate by sharing memory; share memory by communicating.”»

ChatRoom Architecture

We designed a "ChatRoom" struct:


type ChatRoom struct {
    chatters map[*Client]struct{}
    history  []string

    Register   chan *Client
    Unregister chan *Client
    Broadcast  chan Message
}

Only one goroutine manages "chatters" and "history"
Other goroutines send events via channels

The Event Loop

The core of the system is the "Run()" method:


for {
    select {
    case client := <-Register:
    case client := <-Unregister:
    case msg := <-Broadcast:
    }
}

This acts like a central controller.

Handling Events

1. Client Join

Ask for name
Add to chatters map
Send chat history
Broadcast join message

cr.chatters[client] = struct{}{}

2. Message Broadcast

Append to history
Send to all clients except sender

for c := range cr.chatters {
    if c != sender {
        c.receive <- message
    }
}

3. Client Leave

Remove from map
Close channel
Broadcast leave message

Handling Ctrl+C (Unexpected Disconnects)

When a client presses Ctrl+C:

TCP connection closes
"ReadString()" returns "io.EOF"

We detect this:
if err != nil { // client disconnected }

And broadcast:

"%s has left the chat"

Message Flow

Here’s how a message travels:

Client sends message
Goroutine reads it
Sends it to "Broadcast" channel
"Run()" receives it
Loops through clients
Sends message to each client’s "receive" channel
Client writer goroutine prints it

Main Concepts were:

1. TCP is Just a Stream

Everything is bytes
Messages are manually structured ("\n")

Blocking is Normal_

"Accept()" blocks waiting for connections
"ReadString()" blocks waiting for input

But only within their goroutine.

3. Goroutines Enable Concurrency

Lightweight threads managed by Go
Thousands can run efficiently

4. Channels Simplify Concurrency

Avoid shared memory issues
Centralize state management
Create predictable flow

Challenges Faced

Handling empty messages
Debugging raw string issues
Understanding blocking behavior
Managing client disconnects
Avoiding race conditions

This project goes beyond just building a chat app.

It revealed:

How real-time systems work
How servers handle multiple users
How to design safe concurrent programs

In many ways, this is a mini version of real-world systems like chat apps, multiplayer servers, and messaging platforms.

Building this TCP chat server helped me understand how powerful Go is for concurrent systems.

By combining:

TCP networking
Goroutines
Channels

we can build scalable, real-time applications with relatively simple code.

What Actually Happens When a Form Hits a Go Server

Valery Odinga — Wed, 04 Feb 2026 08:31:26 +0000

I’ve been learning how to build web servers in Go, and just yesterday, I tried connecting a simple HTML form to my backend.

I expected the flow to be straightforward: user clicks Submit, Go runs my code, output appears. Instead, the page refreshed, my server logs looked fine, but nothing rendered.

That experience made me realize I didn’t fully understand what actually happens when a form hits a Go server.
This article breaks down that process from the browser sending a request, to Go’s net/httphandlers responding focusing on the clear understanding that finally made things click for me.

What Happens When You Click “Submit”

Clicking Submit doesn’t run your Go code. It sends an HTTP request.

The browser packages the form data, chooses a method (usually POST), and sends everything to the server. After that, the browser just waits.

On the Go side, the server is already running and listening. When the request arrives, net/httpmatches the URL to a handler function and calls it. That’s the moment your code actually runs.

Inside the handler, you read the form values, process them, and write a response using http.ResponseWriter. Whatever you write there is what the browser receives and displays.

Why My POST Route Wasn’t Responding

At one point, my server was running fine. The homepage loaded, and my logs showed that the POST route was being hit. Still, nothing showed up in the browser.

The issue wasn’t that the handler wasn’t running it was that I wasn’t sending anything back.

In Go, handling a request and responding to it are two separate steps. If your handler reads the form data but never writes tohttp.ResponseWriter, the browser has nothing to display.

Also the GET and POST aren’t interchangeable. A form that sends a POST request will never hit a GET-only handler, even if the URL looks correct. If the method doesn’t match, your code simply won’t run.

Once I made sure the request method matched and that I was actually writing a response, things finally started to work.

In Go,http.ResponseWriter is how your handler talks back to the browser. Think of it as a pen: whatever you write with it becomes the body of the HTTP response.

For example:

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "Hello, world!")
}

w is the ResponseWriter.

Fprintln(w, ...) writes text into the response.

When the handler finishes, the server sends everything you wrote back to the browser.

If you never write tow, the request still “works” on the server side, but the user sees… nothing. That’s exactly why my POST requests seemed to do nothing: the handler ran, but didn’t write a response.

ResponseWriter also lets you set headers, status codes, or even send files. But at its core, it’s just the channel for your server’s response.

Running a Go server isn’t magic it just listens for requests. Clicking a form’s Submit button sends an HTTP request. Your handler runs when the request matches its URL and method, and http.ResponseWriter is how you send the output back to the browser.

Once I understood this simple flow, everything clicked: method mismatches explain why GET worked but POST didn’t, and writing to ResponseWriter explains why nothing showed up at first.

If you’re starting with Go web servers, remember: request arrives → handler runs → write a response. Master that, and the rest becomes much easier.

Creating an AI App with Genkit and Gemini: A Beginner’s Guide

Valery Odinga — Wed, 08 Oct 2025 14:36:25 +0000

Artificial Intelligence (AI) tools are now easier than ever to build and Genkit by Google makes it surprisingly simple to create, test, and run your own AI-powered applications.

In this guide, I’ll walk you through how I created a Recipe Generator App using Genkit and Gemini, set up the environment, and explored its interactive Developer UI.

But wait, what is Genkit Really?

Genkit is an open-source framework by Google that helps developers build AI agents and workflows quickly and intuitively.

It integrates seamlessly with Gemini, Vertex AI, and other AI providers, allowing you to focus on your app’s logic instead of boilerplate code or API setup.

Step 1: Setting Up the Environment

Make sure you have the following installed:

Node.js (v18 or later)

npm or yarn

A Gemini API key (you can get one from Google AI Studio
Then create a new folder for your project and install Genkit:

npm install genkit @genkit-ai/google-genai
That’s it! You now have everything you need to start building.

Step 2: Set Your Gemini API Key

Genkit needs your Gemini API key to connect with the model.

You can set it temporarily in your current terminal session:

export GEMINI_API_KEY=<your-api-key>

Or, make it permanent by adding it to your shell profile:

echo 'export GEMINI_API_KEY=<your-api-key>' >> ~/.bashrc
source ~/.bashrc

but I stored mine in a .env file and loaded it with dotenv for better security. That's also another option for you.

Step 3: Create Your First Genkit App (Recipe Generator)
Let’s create something fun, a recipe generator that crafts meal ideas based on ingredients.

Start by creating your project structure:

mkdir src
touch src/index.ts

Then add the following code:

import 'dotenv/config';
import { googleAI } from '@genkit-ai/google-genai';
import { genkit, z } from 'genkit';

// Initialize Genkit with the Google AI plugin
const ai = genkit({
  plugins: [googleAI()],
  model: googleAI.model('gemini-2.5-flash', {
    temperature: 0.8,
  }),
});

// Define input schema
const RecipeInputSchema = z.object({
  ingredient: z.string().describe('Main ingredient or cuisine type'),
  dietaryRestrictions: z.string().optional().describe('Any dietary restrictions'),
});

// Define output schema
const RecipeSchema = z.object({
  title: z.string(),
  description: z.string(),
  prepTime: z.string(),
  cookTime: z.string(),
  servings: z.number(),
  ingredients: z.array(z.string()),
  instructions: z.array(z.string()),
  tips: z.array(z.string()).optional(),
});

// Define a recipe generator flow
export const recipeGeneratorFlow = ai.defineFlow(
  {
    name: 'recipeGeneratorFlow',
    inputSchema: RecipeInputSchema,
    outputSchema: RecipeSchema,
  },
  async (input) => {
    // Create a prompt based on the input
    const prompt = `Create a recipe with the following requirements:
      Main ingredient: ${input.ingredient}
      Dietary restrictions: ${input.dietaryRestrictions || 'none'}`;

    // Generate structured recipe data using the same schema
    const { output } = await ai.generate({
      prompt,
      output: { schema: RecipeSchema },
    });

    if (!output) throw new Error('Failed to generate recipe');

    return output;
  },
);

// Run the flow
async function main() {
  const recipe = await recipeGeneratorFlow({
    ingredient: 'avocado',
    dietaryRestrictions: 'vegetarian',
  });

  console.log(recipe);
}

main().catch(console.error);

This defines a Genkit flow that sends a text prompt to Gemini and returns an AI-generated recipe.

Step 4: Run and Test the Flow

Start your Genkit development server:

genkit start -- npx tsx --watch src/index.ts

You’ll see output like this:

Genkit Developer UI running at http://localhost:4000

Step 5: Interacting with the Developer UI

Open your browser and navigate to http://localhost:4000

This is the Genkit Developer UI, a powerful playground for testing and debugging your AI flows.

Here’s what you can do inside the Developer UI:
1.Explore Your Flows

You’ll see your recipeGenerator flow listed under the Flows tab.
Click it to open an interactive testing panel.

Provide Inputs

Enter your ingredients into the input box (for example,
chicken, garlic, tomatoes, basil)
and hit Run Flow.

View AI Responses

You’ll get an instant response from Gemini — usually a full recipe suggestion!
The UI also shows structured input/output data, so you can see exactly how your flow behaves.

Inspect Traces

Switch to the Traces tab to dive deeper into how your flow executed.
You can monitor latency, errors, and data transformations — great for debugging or optimization.

You just built your first Genkit app!

From here, you can:
Add more steps to your flow (like nutrition facts or cooking time)
Integrate it with a web frontend or API endpoint
Explore the Genkit dashboard for real-time monitoring and collaboration

Blockchain Was Cool, But Superchains Are Cooler

Valery Odinga — Thu, 17 Jul 2025 08:06:56 +0000

Welcome to the World of Blockchain (No, It’s Not a Fancy Prison 🔗)

If you’ve heard of Bitcoin or Ethereum, you’ve heard of blockchain—the tech behind them. But what is it?

Imagine blockchain as a giant, un-cheatable spreadsheet that everyone can see but no one can secretly edit. Instead of living on one computer, it’s copied across thousands, making it nearly impossible to hack.

Why does this matter?

No more needing a bank to send money

No sneaky changes—once something’s recorded, it’s there forever

It’s like digital democracy for money

How Blockchain Works (Without Making Your Brain Hurt

Let’s break it down with a pizza analogy (because everything’s better with pizza).

You order a pizza (this is your "transaction")

The pizza shop writes it down in their ledger (a "block")

They add it to a chain of all past orders (the "blockchain") ⛓️

Every customer has a copy of this ledger—so if the shop tries to say you didn’t pay, everyone else has proof you did.

*Boom. That’s blockchain. *

*The Problem: Blockchains Can Be Slow and Expensive *

Early blockchains (Bitcoin and old-school Ethereum) are like a single cashier at a packed fast-food joint.

Slow? Transactions take minutes (or hours)
Expensive? Fees can cost more than your coffee

Congested? Too many orders = delays

This is why we needed an upgrade. Enter…

*Superchains: The Blockchain Avengers *

If regular blockchains are flip phones , Superchains are 5G smartphones—faster, smarter, and way more powerful.

*What Makes Superchains So Cool? *

Modular Design – Like a buffet where each dish is made by a specialist (one chain handles security, another speed, etc.).

Shared Security – Instead of every chain hiring its own bouncer , they share a super-bouncer .

Instant Communication – Different blockchains can talk seamlessly (like WhatsApp for crypto)

Real-World Example: Optimism’s Superchain

Optimism (a big Ethereum upgrade) is building a Superchain highway , where multiple blockchains run together—faster, cheaper, and way smoother.

*Why Should You Care? *

Faster transactions – No more waiting 10 minutes for your coffee payment to go through.

Lower fees – Sending crypto could cost pennies instead of dollars.

More apps, less hassle – Games, social media, and finance apps will work like the internet, but decentralized.

*Final Thought: The Future is Super *

Blockchain was the Model T Ford revolutionary but clunky. Superchains? They’re the Tesla of crypto sleek, fast, and ready for mass adoption.

So, if you thought blockchain was cool… just wait until you see what Superchains can do.