Forem: Valery Odinga

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.