Forem: Swabri Musa

Beyond the Chatbot: My Wild Ride Building Autonomous AI Agents in Google's 5-Day Intensive

Swabri Musa — Thu, 04 Dec 2025 08:41:51 +0000

This is a submission for the Google AI Agents Writing Challenge: Learning Reflections

Here’s my reflection for the Google AI Agents Writing Challenge: Learning Reflections. Over the five days doing the course, my perspective has shifted dramatically—from focusing on prompt crafting to understanding the deeper realities of designing and managing agentic systems. It has been an intense, eye-opening experience, revealing both the exciting promise and the practical challenges of building real-world AI agents.

The Glow-Up: Ditching Prompts for Agentic Magic (And the Messy Reality)

Before the Google Intensive, my workflow revolved around crafting detailed prompts—carefully engineered inputs designed to coax the best possible output from an LLM. I had heard of frameworks like LangChain and others emerging in the agentic tooling space, but I never felt I had a clear starting point or the architectural grounding to use them effectively. Prompt work was familiar, predictable, and—honestly—limiting.

Then came the Google 5-Day AI Agents Intensive—co-hosted with Kaggle—a concentrated, high-impact deep dive that reshaped my understanding of what modern AI systems can be. Over five days of focused coding sessions and dense technical lectures, I was introduced to the world of agentic architectures: systems that reason, use tools, maintain state, coordinate tasks, and behave less like scripted assistants and more like autonomous collaborators. I walked in as a prompt engineer and walked out with the perspective of an Agent Architect.

But here’s the reality check: building agentic systems in 2025 is both exciting and unforgiving. These systems come with hallucination challenges that can derail reliability, latency constraints that make real-time applications difficult, and infrastructure costs that can escalate quickly—contributing to why many projects never make it to production. The course didn’t hide these issues; it equipped us with strategies to mitigate them.

What follows are the key insights that resonated most—and the practical complexities they revealed.

Takeaway 1: The Agentic Loop—Your Blueprint for AI That Actually Thinks

At its heart, the course drilled in the Agentic Loop: Observe → Think → Act. It's not some fluffy flowchart; it's the beating pulse of agent architecture. Think of it as your AI's daily yoga: breathe in the world, ponder deeply, then do something epic.

Loop Component	What It Does (The Dream)	Tech Magic (Gemini/ADK Style)	2025 Reality Check
Observe	Sucks in user vibes or tool feedback—like eavesdropping on the universe.	Kickoff prompt or tool call results.	Data chaos here? Hello, garbage-in-garbage-out hallucinations that cascade like dominoes.
Think	The agent's inner monologue—raw reasoning magic.	System prompt screaming, "Reason step-by-step, you genius!"	Without guardrails, this is where bias creeps in or models drift, turning "smart" into "stubbornly wrong."
Act	Boom—respond or tool up. No half-measures.	Function calling (Day 2's highlight reel).	Multiple loops? Latency skyrockets from chained LLM calls, killing your app's snappiness.

My Gut Punch Reflection: Day 1 was a wake-up call—force that explicit reasoning in prompts, or your agent's "thoughts" become a black box of bugs. Logging those Thought fields? It's like therapy for your code. But in production? Non-determinism means one run's a poet, the next's a liar. The fix? Layer in RAG for fact-grounding and verification loops—stuff the course hinted at, but 2025's screaming for bulletproof versions.

Takeaway 2: Tools Aren't Just Add-Ons—They're the Agent's Secret Sauce

Day 2? Tools galore. Suddenly, your agent's not stuck in a chat bubble—it's calling APIs, scraping weather, crunching data. We geeked out on the Model Context Protocol (MCP) to wire up functions like check_weather(city) and let Gemini play quarterback: "Do I need this? How?"

Hands-On "Aha" Moment: Integrating was easy-peasy; the real drama? Crafting tool descriptions that don't confuse the model into a wild goose chase. It's prompt engineering 2.0—precise, or your agent tools up for the wrong party.

But spice alert: In the wild, tool chains amp up costs (token bloat from endless calls) and latency (waiting on external APIs feels like 90s internet). Plus, integration fails? Your agent's left flailing, hallucinating workarounds. Pro tip from the trenches: Budget for retries and fallbacks, or watch ROI evaporate—CIOs are underestimating these by up to 1,000%.

Takeaway 3: Memory Isn't a Crutch—It's Your Agent's Super-Ego

Day 3 hit like espresso: Chatbots are amnesiacs; agents need memory. We sliced it smart:

Short-Term (Context Window): Conversation history for that seamless chit-chat flow. Miss it, and your agent's repeating itself like a bad date.
Long-Term (RAG Magic): Vector stores injecting proprietary facts, keeping things fresh without bloating the prompt.

This duo turns a flaky responder into a domain wizard—multi-turn tasks, no sweat, no outdated hallucinations from stale training data.

Reflection with Edge: Love it, but 2025's data deluge means RAG can choke on junk, spawning more hallucinations than it cures. And persistence? State management across sessions adds latency layers. The course armed me, but scaling this means wrestling model drift—your agent's "memory" fading like old tattoos.

Takeaway 4: Observability—Your Debug Lifeline

Day 4's eval and observability module? Developer catnip. You can't ship agents blind—monitor or mourn.

Evaluation: LLM-as-a-Judge for scoring outputs on relevance, safety, the works. Objective? As hell.
Observability: Trace everything—tool picks, inputs/outputs, loops. It's your X-ray for LLM weirdness.

My "Oh Snap" Moment: In a world where 80% of AI projects flop pre-prod, this is your shield. Log hallucinations for patterns, benchmark latency SLAs (<5s, anyone?), and iterate. Without it, agents are black-swan waiting to happen—risky for regs in finance or health.

Wrapping the Chaos: Multi-Agent Mayhem (And Why It's Worth the Fight)

Day 5's multi-agent deep dive? Mind-blown emoji x1000. Specialized squads—a Researcher digging dirt, Planner mapping paths, Critic calling BS—chatting via A2A Protocols. Monolith agents? Cute. This scales to enterprise epics.

The intensive wasn't fluffy theory; it was code-stained hands and "Eureka!" highs. Now? I'm geared to evolve my AI tinkering from garage hacks to production beasts—guardrails and all.

If you're itching to level up, dive in. The AI frontier's bumpy, but oh, the views.

My Next Hustle

Next up: My capstone beast—a collaborative marketing assistant powered by three agents: one for wild ideation, one for deep-dive research, and a drafting dynamo. Pulling multi-agent vibes from Day 5 and RAG smarts from Day 3, with hallucination checks to keep it honest (and latency tweaks for that snappy feel).

Big thanks for reading—let's agent-ify the future, one guarded loop at a time!

My Journey Through `this` in JavaScript: From Confusion to Clarity

Swabri Musa — Wed, 14 May 2025 14:57:47 +0000

When I first started learning JavaScript, one word kept showing up in every tutorial, every error message, and every weird behavior I couldn't explain: this.

At first, I thought I understood it — "this means the object, right?" But then I wrote a function that behaved differently than I expected. Then I used it inside a callback... and it broke. The more I used this, the less I understood it.

So I decided to stop guessing — and finally understand how this really works.

This blog is the journey I wish I had when I started. If you’re new to JavaScript or have ever muttered, “Why is this undefined?”, then this one’s for you.

Part 1: What is `this`, Really?

Let’s start from the top.

In JavaScript, this refers to the execution context of a function — in other words, who is calling the function. Unlike other languages where this is fixed to the class or object, JavaScript’s this is dynamic — it can change depending on how a function is called.

Think of it like this: every time a function runs, JavaScript sets up an environment — an “execution context” — and part of that setup is deciding what this should point to.

That’s the core idea:

this is determined by the call site (where the function is called), not where it was defined.

Part 2: The Building Blocks — Execution Context

Every time JavaScript runs code, it creates an execution context — an environment where the code executes. There are three major types:

Global context – the default one. In browsers, this points to the window object.
Function context – when you call a function. this depends on how you call the function.
Eval context – rarely used, so we’ll skip it.

Let’s test the global context:

console.log(this); // In browsers, logs: Window

So far, so good. But the real fun starts when we look at functions…

Part 3: Four Ways `this` is Set (The Binding Rules)

Let’s walk through the 4 primary ways JavaScript decides what this means in a function.

1. Default Binding

If you just call a function without any context:

function sayHello() {
  console.log(this);
}

sayHello(); // In browsers: logs Window (or undefined in strict mode)

In non-strict mode, this is the global object (window in browsers).
In strict mode, this is undefined.

Beginner Tip: Strict mode is safer. Use "use strict"; at the top of your file or function to avoid bugs.

2. Implicit Binding

When you call a function as a method of an object, this points to that object.

const user = {
  name: "Alice",
  greet() {
    console.log(`Hi, I’m ${this.name}`);
  }
};

user.greet(); // Hi, I’m Alice

Seems simple, right?

But watch this curveball:

const greet = user.greet;
greet(); // Oops! this is now window or undefined

By pulling the function out, we lost the context. That’s a common beginner trap.

3. Explicit Binding

JavaScript gives you tools to control this manually with call, apply, and bind.

function introduce(role) {
  console.log(`${this.name} is a ${role}`);
}

const person = { name: "Bob" };

introduce.call(person, "Developer"); // Bob is a Developer
introduce.apply(person, ["Designer"]); // Bob is a Designer

const boundFn = introduce.bind(person, "Engineer");
boundFn(); // Bob is an Engineer

🛠️ Use these when you need to control this precisely — like in event handlers or reused functions.

4. `new` Binding

Calling a function with new creates a brand-new object and binds this to it.

function Car(model) {
  this.model = model;
}

const myCar = new Car("Toyota");
console.log(myCar.model); // Toyota

Here, this refers to the new object being created. That's constructor magic.

⚡ Climax: Enter Arrow Functions — and Lexical `this`

Arrow functions behave differently — they don’t get their own this. Instead, they "borrow" it from the place where they're defined (lexical scope).

const team = {
  name: "Dev Team",
  arrowFunc: () => {
    console.log(this.name);
  },
  regularFunc: function () {
    console.log(this.name);
  }
};

team.regularFunc(); // Dev Team
team.arrowFunc();   // undefined or window.name

Arrow functions do not bind this — great for callbacks, terrible for object methods.

Gotchas and Fixes: Pitfalls I Tripped Over

Losing `this` in a callback:

const app = {
  name: "MyApp",
  start: function () {
    setTimeout(function () {
      console.log(this.name); // undefined
    }, 1000);
  }
};

Fix with arrow function:

setTimeout(() => {
  console.log(this.name); // MyApp
}, 1000);

Or save context:

const self = this;
setTimeout(function () {
  console.log(self.name);
}, 1000);

Nested function madness:

const group = {
  name: "Study Group",
  show: function () {
    function inner() {
      console.log(this.name); // undefined
    }
    inner();
  }
};

group.show();

Fix with arrow function:

show: function () {
  const inner = () => {
    console.log(this.name); // Study Group
  };
  inner();
}

The “Aha!” Moment: Practice Makes Perfect

Here’s a final example that combines it all:

const event = {
  title: "Tech Talk",
  organizers: ["Alice", "Bob"],
  announce: function () {
    console.log(`Event: ${this.title}`);
    this.organizers.forEach(function (organizer) {
      console.log(`${organizer} is organizing ${this.title}`);
    });
  }
};

event.announce();

The forEach function loses this, so it doesn’t know about title.

Fix with arrow function:

this.organizers.forEach((organizer) => {
  console.log(`${organizer} is organizing ${this.title}`);
});

Boom. Now this works like we expect — because arrow functions keep this from the announce method.

Wrapping Up: How I Learned to Stop Worrying and Love `this`

Understanding this isn't about memorizing rules — it's about recognizing patterns:

Where was the function called? That’s what defines this.
Arrow functions are great for keeping this consistent.
Use bind, call, or apply when you need to take control.
Practice with real examples — try tweaking code and logging this.

this may seem confusing at first, but once you see how it flows through your code, it becomes a powerful tool — not a mystery.

Your Turn

Try this: Take a function you wrote recently and ask yourself — “What is this right now?” Log it. Play with it. Break it. Then fix it.

Still have questions? Drop them below. Let’s decode JavaScript — together.

Want to Go Deeper?

Why Choose CSS Grid Over Flexbox for Layouts

Swabri Musa — Fri, 09 May 2025 08:31:27 +0000

When it comes to building modern, responsive web layouts, two CSS layout systems dominate the conversation: Flexbox and Grid. While both are powerful tools in your CSS arsenal, understanding when to use one over the other is key to writing clean, maintainable, and scalable CSS.

This article will explore why CSS Grid often makes more sense for full-page layouts while acknowledging where Flexbox still shines.

First Principles: Understanding the Core Differences

Before diving into specifics, let's establish the fundamental difference between these two layout models:

Flexbox is a one-dimensional layout model designed for laying out items in a single row or column.
CSS Grid is a two-dimensional layout system designed for laying out items in rows and columns simultaneously.

This fundamental difference determines when you should reach for one over the other.

5 Reasons to Choose CSS Grid for Layouts

1. True Two-Dimensional Control

Flexbox excels when your content flows in a single direction (horizontal or vertical). But as soon as you need to manage both axes—placing items in specific positions across rows and columns—Grid becomes the clear winner.

/* Using Grid for a 3x3 layout */
.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: auto auto auto;
  gap: 1rem;
}

With this simple code, you can place items in specific cells, span them across multiple columns or rows, and define the entire layout structure in one declaration.

2. Named Template Areas for Semantic Layouts

One of Grid's most powerful features is the ability to define grid areas by name, making your layouts more readable and maintainable.

.container {
  display: grid;
  grid-template-areas:
    "header header"
    "sidebar main"
    "footer footer";
  grid-template-columns: 200px 1fr;
}

.header  { grid-area: header; }
.sidebar { grid-area: sidebar; }
.main    { grid-area: main; }
.footer  { grid-area: footer; }

This semantic layout approach is remarkably intuitive. Anyone reading your code can immediately visualize the layout structure without having to calculate flex-based widths and orders.

3. Better for Page-Level Layouts

For full-page layouts—dashboards, blogs, web apps—CSS Grid allows you to define an entire page structure at once. With Flexbox, you'd typically need to nest multiple flex containers to achieve the same result, leading to more complex HTML and potential performance issues.

Example of nested Flexbox vs. clean Grid code

Nested Flexbox approach:


  Header content

    Sidebar content
    Main content

  Footer content

.page-container {
  display: flex;
  flex-direction: column;
  min-height: 100vh;
}

.content-container {
  display: flex;
  flex: 1;
}

.sidebar {
  width: 200px;
}

.main-content {
  flex: 1;
}

Cleaner Grid approach:


  Header content
  Sidebar content
  Main content
  Footer content

.page-container {
  display: grid;
  grid-template-areas:
    "header header"
    "sidebar main"
    "footer footer";
  grid-template-columns: 200px 1fr;
  grid-template-rows: auto 1fr auto;
  min-height: 100vh;
}

.header { grid-area: header; }
.sidebar { grid-area: sidebar; }
.main-content { grid-area: main; }
.footer { grid-area: footer; }

4. More Predictable Alignment and Spacing

CSS Grid provides more intuitive alignment and spacing tools when dealing with multiple rows and columns. The gap property works consistently across both dimensions, and alignment properties like justify-items and align-items are more predictable across complex layouts.

.grid-container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 20px;
  justify-items: center;
  align-items: center;
}

With Flexbox, you might need various combinations of margins, paddings, and justify-content properties to achieve the same spacing consistency.

5. Reduced HTML Nesting

With Flexbox, complex layouts often require nested containers. Grid lets you build more complex designs without excessive HTML nesting, keeping your markup cleaner and more semantic.

When to Stick with Flexbox

Flexbox still has its place in your CSS toolkit! It shines for:

Navigation menus and toolbars where items flow in a single direction
Form controls that need to be aligned in a row
Card layouts with dynamic content where items need to wrap naturally
Centering a single element both horizontally and vertically

/* Simple navigation with Flexbox */
.nav {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

/* Centering with Flexbox - still unbeatable for this */
.centered-box {
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh;
}

Decision Matrix: Flexbox vs. Grid

Use Case	Flexbox	Grid
One-dimensional layout	✅ Perfect fit	❌ Overkill
Two-dimensional layout	❌ Complicated	✅ Perfect fit
Component-level layout	✅ Great	✅ Good
Page-level layout	❌ Clumsy	✅ Ideal
Precise item placement	❌ Hard	✅ Easy with areas
Content-driven layouts	✅ Flexible	❌ More rigid

🔚 Conclusion: Master Both, Know When to Use Each

The best CSS developers don't choose one layout system exclusively. Instead, they:

Use Grid for broader page layouts and structural design
Use Flexbox for UI components and one-dimensional sections
Often combine both in the same project for maximum flexibility

By understanding the first principles—Grid for two-dimensional layouts and Flexbox for one—you'll make smarter decisions and write cleaner, more maintainable CSS.

From Go to Rust: A Developer's Journey Through Systems Programming

Swabri Musa — Sat, 05 Apr 2025 18:03:12 +0000

As a Golang developer building robust, scalable backend systems, I've always appreciated Go's elegant simplicity. Its minimal syntax and powerful standard library have been my trusted tools for creating efficient software solutions for years. But recently, I decided to step outside my comfort zone and explore Rust, a language I'd been hearing so much about. What began as casual curiosity evolved into a fascinating journey that's changed how I think about systems programming.

The Engineer's Perspective on Language Philosophy

With my background in Electrical Engineering, I've always approached programming from a systems perspective, trying to understand how things work from first principles. This mindset helped me appreciate both languages for what they truly offer:

Go: As someone who builds distributed systems and event-driven architectures with technologies like Kafka, I value Go's approach to simplicity. Its straightforward concurrency model makes developing scalable services almost intuitive.
Rust: My interest in low-level programming and computational efficiency drew me to Rust's promise of performance without sacrificing safety. What I discovered was a language that complements my methodical approach to problem-solving.

The transition between these languages feels like switching between different engineering disciplines—each with its own principles, trade-offs, and elegant solutions to complex problems.

Syntax: From Familiar Comfort to Expressive Power

Coming from Go's minimalist syntax, Rust initially felt overwhelming. The differences start with the fundamentals:

In Go (my comfort zone):

// Simple and straightforward
func ProcessChunks(data []byte, chunkSize int) []string {
    var results []string
    // Processing logic
    return results
}

In Rust (my new challenge):

// More explicit, with lifetime annotations and ownership details
fn process_chunks<'a>(data: &'a [u8], chunk_size: usize) -> Vec<String> {
    let mut results = Vec::new();
    // Processing logic with ownership considerations
    results
}

After working with both languages on various projects—from my text indexer "Jam-Text" in Go to newer experiments in Rust—I've found that Rust's verbosity actually encourages more thoughtful program design. The compiler forces me to think about issues I might have overlooked in Go.

Error Handling: From Checking Nil to Embracing Results

Error handling was one of the biggest mental shifts. During the Jam-Text hackathon project, our team wrote plenty of Go code with the familiar pattern:

index, err := CreateTextIndex(documents)
if err != nil {
    log.Fatalf("Failed to create index: %v", err)
}

Rust's approach felt alien at first:

let index = create_text_index(documents)?;

The ? operator seemed like magic compared to Go's explicit error checking. But after using it in practice, I realized how it transforms error handling from boilerplate into expressive flow control. This reminded me of designing circuits in my engineering days—where signal propagation followed natural paths with built-in safeguards.

Concurrency: Goroutines vs. Ownership-Based Threading

Having implemented parallel processing in my Go projects, especially for chunk handling in the text indexer, I was skeptical about Rust's more complex threading model:

In Go:

// From my Jam-Text project
for _, chunk := range chunks {
    wg.Add(1)
    go func(c []byte) {
        defer wg.Done()
        // Process chunk concurrently
    }(chunk)
}

In Rust:

let handles: Vec<_> = chunks
    .iter()
    .map(|chunk| {
        thread::spawn(move || {
            // Process chunk with ownership guarantees
        })
    })
    .collect();

for handle in handles {
    handle.join().unwrap();
}

The Rust version requires more consideration about data ownership, but after working through borrow checker errors (and there were many!), I found my concurrent code had fewer subtle bugs. The compiler was catching race conditions that might have shipped to production in my Go code.

The Borrow Checker: From Frustration to Enlightenment

If I'm being honest, my first few weeks with Rust were humbling. Coming from Go's garbage collector, Rust's ownership system felt like trying to solve a puzzle where the rules kept changing. I struggled with basic operations that would have been trivial in Go.

The breakthrough came when I approached it like an engineering problem rather than a programming task. I drew out memory diagrams on paper, thinking about ownership transfers the way I'd think about signal flow in a circuit. Suddenly, the borrow checker wasn't my enemy—it was a collaborator helping me design better systems.

Practical Applications: Where Each Language Shines

Through my journey with both languages, I've developed a practical sense of when to use each:

Go: For my distributed systems work, API services, and when rapid development is crucial. My custom implementation of the Unix ls command in Go is a perfect example of leveraging Go's standard library and simplicity for system utilities.
Rust: When performance and memory safety are critical. I've started migrating some computational components of my projects to Rust, especially those dealing with data processing algorithms similar to the SimHash fingerprinting we implemented in Jam-Text.

Lessons for Golang Developers Considering Rust

If you're a Gopher thinking about exploring Rust, here's what I wish someone had told me:

Start small: Don't try to rewrite your entire Go application. Begin with a self-contained utility or module.
Expect the learning curve: Your productivity will drop temporarily—embrace it as part of the learning process.
Think in ownership: Before writing code, sketch out which functions and structures own which data.
Learn to love the compiler: Those cryptic error messages are actually saving you from subtle bugs.
Bring your Go discipline: Go's emphasis on simplicity and readability remains valuable in Rust code.

The Unexpected Benefits

What surprised me most wasn't the technical capabilities of Rust, but how learning it improved my Go code. I now write more memory-conscious Go, think more carefully about mutability, and design better abstractions. The mental models from Rust have made me a better programmer overall.

During my time at Zone01 Kisumu as a software developer, I've had the opportunity to work with both languages, and I've found that this dual perspective makes me a more versatile problem solver. Each language has taught me something valuable about the other.

Conclusion: Two Languages, One Engineering Mindset

As someone with a background in Electrical Engineering who approaches programming from first principles, I've come to see Go and Rust not as competing technologies but as complementary tools in my development arsenal. Go offers simplicity and productive development for scalable services, while Rust provides control and safety for performance-critical components.

The journey from Go to Rust isn't about leaving one language behind—it's about expanding your mental models and having more tools to solve complex problems. For a methodical thinker interested in distributed systems and computational efficiency, having both languages at your disposal is invaluable.

I'm continuing to build with Go while exploring Rust's ecosystem, just as I continue developing my expertise in container orchestration, infrastructure automation, and event-driven architectures. The intersection of these technologies provides endless opportunities for creating efficient, robust software solutions.

Have you made a similar journey between programming languages? I'd love to hear about your experiences in the comments. And if you're working on interesting projects in either Go or Rust, let's connect!

Building Jam-Text: A High-Performance Text Indexer in Go

Swabri Musa — Sun, 16 Mar 2025 17:43:57 +0000

Last month, I teamed up with some brilliant folks—Elijah, Kevin, Jerome, and Godwin—for a hackathon challenge: build a fast, scalable text indexer in Go. The goal? Create a tool that could chew through massive text files, fingerprint chunks for similarity, and retrieve content lightning-fast.

The result was Jam-Text, a CLI-powered indexer with SimHash fingerprints, vector similarity via random hyperplanes, and a sprinkle of multi-threading magic. Here’s the story of how we built it, the hurdles we faced, and what I learned along the way.

The Challenge: Speed, Scale, and Similarity

The hackathon’s problem statement was deceptively simple:

Parse a text file into chunks (say, 4KB each).
Generate SimHash fingerprints.
Build an in-memory index.
Enable quick lookups.
Bonus points for parallel processing and fuzzy matching.

But beneath that simplicity lay a beast—how do you make it fast and scalable for huge datasets while keeping memory in check?

We started with a basic question: What’s similarity anyway?

For plagiarism detection, you want exact or near-exact matches.
For content finding, semantic similarity matters more (e.g., "cat" vs. "feline").

This led us to a hybrid approach:

SimHash for exact lookups (per the CLI spec).
Vector similarity with random hyperplanes for fuzzy, scalable searches.

Diving In: The Big Idea from LSH

Our inspiration came from Moses Charikar’s paper, "Similarity Estimation Techniques from Rounding Algorithms". It introduced Locality-Sensitive Hashing (LSH)—a genius trick to fingerprint complex data (like text chunks) into short, comparable sketches.

The paper offered three flavors:

Min-Hash: Great for detecting overlap (e.g., duplicates).
Random Hyperplanes: Converts text into vectors (word counts), measures cosine similarity—perfect for meaning.
Earth Mover Distance: A fancy distribution metric (overkill for us).

We chose random hyperplanes for its semantic power, pairing it with SimHash to meet the CLI’s -h <simhash_value> requirement. Here’s how we stitched it together.

Building Jam-Text: The Tech Journey

Step 1: Chunking the Text

We started with a chunker package to split files into fixed-size chunks (default 4KB). Early versions were single-threaded—slow for big files. So, we added a worker pool, splitting the file into sections and processing them in parallel with goroutines.

`chunker/chunker.go`

func (c *Chunker) ProcessFile(filePath string) ([]Chunk, error) {
    fileSize := getFileSize(filePath)
    numWorkers := 4
    chunkChan := make(chan Chunk, 100)
    var wg sync.WaitGroup
    sectionSize := fileSize / int64(numWorkers)

    // Spin up workers
    for i := 0; i < numWorkers; i++ {
        start := int64(i) * sectionSize
        end := start + sectionSize
        if i == numWorkers-1 { end = fileSize }
        wg.Add(1)
        go c.processSection(filePath, start, end, chunkChan)
    }

    // Collect chunks
    go func() { wg.Wait(); close(chunkChan) }()
    var chunks []Chunk
    for chunk := range chunkChan { chunks = append(chunks, chunk) }
    return chunks, nil
}

Step 2: Fingerprinting with a Hybrid Twist

Next, we tackled fingerprinting in the simhash package.

SimHash hashes words into a 64-bit fingerprint—fast and compact.
Vector similarity: Each chunk became a vector (word counts over a simple vocabulary), and we generated 10-bit sketches using random hyperplanes.

`simhash/simhash.go`

type Fingerprint struct {
    SimHash     uint64
    VecSketches []int
}

func Hash(content []byte) Fingerprint {
    vector := toVector(string(content))
    return Fingerprint{
        SimHash:     simHash(string(content)),
        VecSketches: vectorSketches(vector, 10),
    }
}

Step 3: Indexing with LSH

The index package stored SimHash for exact lookups and LSH bucketing for vector sketches.

`index/index.go`

type Index struct {
    Entries    map[uint64]IndexEntry
    LSHBuckets map[int][]IndexEntry
    mu         sync.RWMutex
}

func (idx *Index) AddEntry(fp simhash.Fingerprint, offset int64) {
    idx.mu.Lock()
    defer idx.mu.Unlock()
    idx.Entries[fp.SimHash] = IndexEntry{Fingerprint: fp, Offsets: []int64{offset}}
    bucketKey := fp.VecSketches[0]
    idx.LSHBuckets[bucketKey] = append(idx.LSHBuckets[bucketKey], entry)
}

Step 4: CLI Magic

The cli package brought it to life with commands like index, lookup, compare, and fuzzy.

Example CLI usage

./textindex -c index -i large_text.txt -s 4096 -o index.idx
./textindex -c lookup -i index.idx -h 3eff1b2c98a6
./textindex -c compare -i doc1.txt -i2 doc2.txt -o report.txt
./textindex -c fuzzy -i testdata.idx -h $HASH -threshold 0.8

Challenges and Triumphs

The Vocabulary Headache

Vector similarity needed a vocabulary. Building it dynamically was slow, so we pre-sampled from the file. Not perfect, but it worked for the demo.

Balancing Speed and Memory

SimHash was lean (8 bytes/chunk).
10 vector sketches bumped it to ~18 bytes/chunk.
We tuned it down from 20 sketches to 10—good enough for fuzzy matching without hogging RAM.

Scaling with LSH

Linear search was... bad. LSH buckets improved recall and speed, but tuning the sketch size vs. false positives was tricky.

What’s Next?

We’re thinking about:

Incremental Indexing for real-time updates.
Approximate Nearest Neighbors (ANN) for even faster fuzzy searches.
Persistent Storage (LSM trees, RocksDB?).

Would you use Jam-Text? Have thoughts on improvements? Let’s discuss in the comments! 🚀

From Traditional to Docker: A Developer's Guide

Swabri Musa — Sun, 03 Nov 2024 08:02:00 +0000

For developers familiar with traditional deployment methods, Docker introduces a new paradigm of containerization. This guide bridges the gap by comparing familiar concepts with Docker's approach, making the transition more intuitive.

Understanding the Shift

Traditional vs. Docker Deployment

Traditional Deployment:

1. Install specific OS version
2. Install runtime environment
3. Install application dependencies
4. Configure environment variables
5. Start application

Docker Deployment:

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o main .

FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/main .
CMD ["./main"]

The Docker approach encapsulates everything in a single, reproducible configuration file.

Key Differences

1. Environment Consistency

Traditional:

Environment-specific configurations required
"Works on my machine" syndrome
Manual documentation of setup steps

Docker:

Build once, run anywhere
Guaranteed consistency across environments
Self-documenting infrastructure as code

2. Dependency Management

Traditional:

# System-wide installation risks conflicts
go get github.com/some/dependency
python install -r requirements.txt

Docker:

# Dependencies isolated per container
COPY requirements.txt .
RUN pip install -r requirements.txt

3. Resource Management

Traditional:

Applications share system resources
Complex resource allocation
Potential conflicts between applications

Docker:

Isolated container resources
Built-in resource limits
No cross-application interference

docker run --memory=1g --cpus=2 myapp

Essential Docker Commands

# Build an image
docker build -t myapp .

# Run a container
docker run -d -p 8080:8080 myapp

# View logs
docker logs container_id

# Stop a container
docker stop container_id

Container vs VM Architecture

Virtual Machines

Full OS for each instance
Higher resource overhead
Complete isolation
Minutes to start

Containers

Shared host OS kernel
Minimal resource overhead
Process-level isolation
Seconds to start

Best Practices

Build Efficient Images

   # Use multi-stage builds
   FROM node:alpine AS builder
   # Build stage...

   FROM alpine:latest
   # Production stage...

Handle Data Persistence

   # Create named volumes
   docker volume create mydata
   docker run -v mydata:/data myapp

Compose Multiple Services

   # docker-compose.yml
   version: '3.8'
   services:
     app:
       build: .
       ports:
         - "8080:8080"
     db:
       image: postgres:13
       volumes:
         - pgdata:/var/lib/postgresql/data

Getting Started Steps

Start with single-container applications
Learn Docker Compose for multi-container setups
Master Docker networking concepts
Implement container orchestration
Adopt continuous integration practices

Common Pitfalls to Avoid

Don't run containers as root
Avoid storing sensitive data in images
Don't ignore container logs
Remember to clean up unused resources

Next Steps

Explore Kubernetes for orchestration
Implement CI/CD pipelines with Docker
Learn about Docker security best practices
Study container monitoring solutions

Understanding Error Handling: From Try-Catch to Result Types

Swabri Musa — Wed, 30 Oct 2024 23:46:50 +0000

Introduction

Error handling is a fundamental aspect of writing reliable software, yet many developers find themselves struggling with different approaches across programming languages. Whether you're coming from a try-catch background or exploring functional programming's Result types, understanding these patterns can significantly improve your code quality.

1. The Traditional Approach: Try-Catch

Most developers start their journey with try-catch blocks, a familiar pattern in languages like Java, JavaScript, and Python. Let's look at how this works:

try {
    const data = JSON.parse(userInput);
    processData(data);
} catch (error) {
    console.error("Failed to process data:", error.message);
}

Why Try-Catch?

Intuitive and widely understood
Separates happy path from error handling
Supports error hierarchies and specific error types

2. Go's Error as Values

Go took a different approach, treating errors as regular values that functions can return:

func processFile(path string) error {
    data, err := os.ReadFile(path)
    if err != nil {
        return fmt.Errorf("reading file: %w", err)
    }

    result, err := processData(data)
    if err != nil {
        return fmt.Errorf("processing data: %w", err)
    }

    return nil
}

Benefits of Error Values

Explicit error handling
Forces developers to consider error cases
Composable with other language features
Clear error propagation

3. Result Types: The Functional Approach

Languages like Rust and functional programming introduce Result types, representing either success or failure:

fn process_data(input: &str) -> Result<Data, Error> {
    let parsed = json::parse(input)?;
    let processed = transform_data(parsed)?;
    Ok(processed)
}

Why Result Types?

Type-safe error handling
Pattern matching support
Chainable operations
Prevents unhandled errors at compile time

4. Modern Patterns and Best Practices

Today's error handling often combines multiple approaches:

a. Error Context

Adding context to errors helps with debugging:

try {
    await processUserData(userData);
} catch (error) {
    throw new Error(`Failed to process user ${userId}: ${error.message}`, {
        cause: error
    });
}

b. Structured Error Types

Define clear error hierarchies:

class ValidationError extends Error {
    constructor(message: string, public field: string) {
        super(message);
        this.name = 'ValidationError';
    }
}

class NetworkError extends Error {
    constructor(message: string, public statusCode: number) {
        super(message);
        this.name = 'NetworkError';
    }
}

5. Making the Right Choice

Consider these factors when choosing an error handling approach:

Language ecosystem and conventions
Project requirements and constraints
Team experience and preferences
Performance considerations
Debugging and monitoring needs

Conclusion

Error handling isn't just about catching exceptions—it's about building robust systems that gracefully handle failure. Whether you choose try-catch blocks, error values, or Result types, the key is consistency and clarity in your approach.

Remember:

Choose patterns that match your language's idioms
Add meaningful context to errors
Consider the maintenance implications
Keep error handling consistent across your codebase

What's your preferred error handling pattern? Share your experiences in the comments below!

JavaScript Methods for Go Developers: A Beginner's Guide

Swabri Musa — Sat, 05 Oct 2024 11:00:28 +0000

Introduction

As a Go developer stepping into the world of JavaScript, you might find yourself both curious and puzzled by how JavaScript handles objects and methods. Don't worry! This article will guide you through the world of JavaScript methods, drawing comparisons with your Go experience to make learning easier.

1. From Structs to Objects: A New Way of Thinking

In Go, you're used to working with structs - organized, clearly defined data structures. JavaScript introduces you to a more flexible world of objects. Let's compare:

// Go struct
type Person struct {
    Name string
    Age  int
}

JavaScript

// JavaScript object
const person = {
    name: "John",
    age: 30
};

Notice how JavaScript objects are more relaxed? You don't need to define types beforehand! This flexibility can be freeing, allowing you to focus more on what the code does rather than how it's structured.

a. Safety vs. Flexibility

Go: Go's way of handling data types helps prevent errors early on and keeps things consistent.
JavaScript: JavaScript is more flexible, letting you change things on the fly. This can be handy but might cause unexpected issues if you're not careful.

// Go won't let you put a word where a number should be
person := Person{Name: "Alice", Age: 25}
person.Age = "twenty-five" // This will cause an error

// JavaScript lets you change types as you go
const person = { name: "Alice", age: 25 };
person.age = "twenty-five"; // This is allowed, but might cause problems later

In simple terms: Go likes to keep things predictable, while JavaScript gives you more freedom but expects you to be more careful.

b. Changing Values

Go: In Go, it's not easy to change values in a struct unless you specifically set it up that way.
JavaScript: Objects can be changed easily by default, so you can modify their properties without any special setup.

// Go: Need special setup to change values i.e through a pointer value
func (p *Person) SetAge(age int) { p.Age = age }

// JavaScript: Can change values easily
person.age = 35;

In simple terms: Go makes it harder to accidentally change things, while JavaScript lets you make changes quickly and easily.

c. Memory Management

Go: Go requires you to manage memory more directly, which gives you control but can be more complex.
JavaScript: JavaScript handles memory for you, making it easier to use but sometimes less predictable in performance-heavy applications.

// Go: You need to manage memory yourself
p := &Person{Name: "Bob", Age: 40}

// JavaScript: Memory is handled for you
const person = { name: "Bob", age: 40 };

In simple terms: Go gives you more control over how your computer's memory is used, while JavaScript does this job for you automatically.

2. Methods: Adding Behavior to Data

In Go, you might define methods like this:

func (p Person) SayHello() string {
    return "Hello, my name is " + p.Name
}

JavaScript does it differently:

JavaScript

const person = {
    name: "John",
    sayHello: function() {
        return "Hello, my name is " + this.name;
    }
};

See that this keyword? It's JavaScript's way of referring to the object itself, similar to how Go uses the receiver. This allows methods to be more adaptable and aware of their context.

3. The Flexible Nature of JavaScript Methods

Unlike Go's strict rules, JavaScript lets you add methods to objects on the spot:

JavaScript

person.greet = function(greeting) {
    return `${greeting}, I'm ${this.name}`;
};

console.log(person.greet("Hi there")); // Prints: "Hi there, I'm John"

This flexibility can be both powerful and potentially confusing for Go developers used to more rigid structures. It opens up many possibilities for dynamic behavior and quick modifications.

4. Different Ways of Organizing Code: Prototypes vs. Classes

Now, let's look at a fundamental difference in how Go and JavaScript organize code. Understanding this will help you grasp why JavaScript behaves the way it does.

Object-Oriented Programming (OOP)

OOP is a way of organizing code around "objects," which contain both data and the functions to work with that data.

Class-Based OOP

In class-based OOP, a class is like a blueprint for creating objects. It defines what kind of data and behavior (methods) an object should have.

Go's Approach: While Go isn't a traditional OOP language, it supports a form of class-based OOP through types and methods. Instead of classes, Go uses structs to define data structures, and methods can be associated with these structs.

Prototype-Based OOP

Prototype-based OOP is a different approach that focuses on reusing existing objects as templates (prototypes) for new objects.

JavaScript's Approach: JavaScript uses a prototype-based model where objects can directly inherit from other objects. This is very flexible because you can add new properties and methods to objects even after they're created.

JavaScript

function Person(name) {
    this.name = name;
}

Person.prototype.sayHello = function() {
    return "Hello, I'm " + this.name;
};

const john = new Person("John");
console.log(john.sayHello()); // Prints: "Hello, I'm John"

This approach allows for dynamic inheritance and can be quite powerful once you get used to it. It encourages more flexible and reusable code.

5. The Tricky 'this' Keyword

In Go, it's always clear which object a method belongs to. In JavaScript, the this keyword can be more complicated. Its value can change based on how a function is called:

JavaScript

const person = {
    name: "Alice",
    greet: function() {
        console.log("Hello, I'm " + this.name);
    }
};

person.greet(); // Prints: "Hello, I'm Alice"

const greetFunc = person.greet;
greetFunc(); // Prints: "Hello, I'm undefined"

Understanding how this works in different situations is crucial in JavaScript and often confuses developers coming from languages like Go. It's important to learn how this behaves in different contexts to avoid common mistakes.

Conclusion

Moving from Go to JavaScript involves embracing a more flexible approach to objects and methods. While it may feel less structured at first, this flexibility allows for powerful coding patterns and expressive code.

As you continue learning JavaScript, remember:

Embrace the flexibility of JavaScript objects.
Get comfortable with the this keyword and its quirks.
Explore prototype-based OOP and its possibilities.
Practice, practice, practice!

Happy coding, and welcome to the world of JavaScript methods!

What parts of this topic would you like to learn more about? Feel free to ask questions or share your experiences in the comments below!

Forem: Swabri Musa

Beyond the Chatbot: My Wild Ride Building Autonomous AI Agents in Google's 5-Day Intensive

The Glow-Up: Ditching Prompts for Agentic Magic (And the Messy Reality)

What follows are the key insights that resonated most—and the practical complexities they revealed.

Takeaway 1: The Agentic Loop—Your Blueprint for AI That Actually Thinks

Takeaway 2: Tools Aren't Just Add-Ons—They're the Agent's Secret Sauce

Takeaway 3: Memory Isn't a Crutch—It's Your Agent's Super-Ego

Takeaway 4: Observability—Your Debug Lifeline

Wrapping the Chaos: Multi-Agent Mayhem (And Why It's Worth the Fight)

My Next Hustle

My Journey Through `this` in JavaScript: From Confusion to Clarity

Part 1: What is this, Really?

Part 2: The Building Blocks — Execution Context

Part 3: Four Ways this is Set (The Binding Rules)

1. Default Binding

2. Implicit Binding

3. Explicit Binding

4. new Binding

⚡ Climax: Enter Arrow Functions — and Lexical this

Gotchas and Fixes: Pitfalls I Tripped Over

Losing this in a callback:

Fix with arrow function:

Nested function madness:

Fix with arrow function:

The “Aha!” Moment: Practice Makes Perfect

Fix with arrow function:

Wrapping Up: How I Learned to Stop Worrying and Love this

Your Turn

Want to Go Deeper?

Why Choose CSS Grid Over Flexbox for Layouts

First Principles: Understanding the Core Differences

5 Reasons to Choose CSS Grid for Layouts

1. True Two-Dimensional Control

2. Named Template Areas for Semantic Layouts

3. Better for Page-Level Layouts

4. More Predictable Alignment and Spacing

5. Reduced HTML Nesting

When to Stick with Flexbox

Decision Matrix: Flexbox vs. Grid

🔚 Conclusion: Master Both, Know When to Use Each

From Go to Rust: A Developer's Journey Through Systems Programming

The Engineer's Perspective on Language Philosophy

Syntax: From Familiar Comfort to Expressive Power

Error Handling: From Checking Nil to Embracing Results

Concurrency: Goroutines vs. Ownership-Based Threading

The Borrow Checker: From Frustration to Enlightenment

Practical Applications: Where Each Language Shines

Lessons for Golang Developers Considering Rust

The Unexpected Benefits

Conclusion: Two Languages, One Engineering Mindset

Building Jam-Text: A High-Performance Text Indexer in Go

The Challenge: Speed, Scale, and Similarity

Diving In: The Big Idea from LSH

Building Jam-Text: The Tech Journey

Step 1: Chunking the Text

chunker/chunker.go

Step 2: Fingerprinting with a Hybrid Twist

simhash/simhash.go

Step 3: Indexing with LSH

index/index.go

Step 4: CLI Magic

Example CLI usage

Challenges and Triumphs

The Vocabulary Headache

Balancing Speed and Memory

Scaling with LSH

What’s Next?

Would you use Jam-Text? Have thoughts on improvements? Let’s discuss in the comments! 🚀

From Traditional to Docker: A Developer's Guide

Understanding the Shift

Traditional vs. Docker Deployment

Key Differences

1. Environment Consistency

2. Dependency Management

3. Resource Management

Essential Docker Commands

Container vs VM Architecture

Virtual Machines

Containers

Best Practices

Part 1: What is `this`, Really?

Part 3: Four Ways `this` is Set (The Binding Rules)

4. `new` Binding

⚡ Climax: Enter Arrow Functions — and Lexical `this`

Losing `this` in a callback:

Wrapping Up: How I Learned to Stop Worrying and Love `this`

`chunker/chunker.go`

`simhash/simhash.go`

`index/index.go`