DEV Community: Ouma Asoyoh

Building a web scraper in go: Understanding the go standard libraries.

Ouma Asoyoh — Mon, 28 Sep 2026 20:49:25 +0000

Web scraping is one of those projects that looks simple at first:

«Send a request → get a webpage → extract some information.»

But once you start implementing it, you quickly discover that there are several pieces involved.

Recently, I started learning how to build a web scraper in Go. What interested me most was that I could build most of the foundation using Go's standard library.

In this article, I'll break down the main packages involved, what each one does, and how they fit together to create a simple web scraper.

The basic architecture

Before looking at individual packages, it helps to understand the flow.

A basic scraper can be thought of as:

URL
│
▼
HTTP Request
│
▼
HTTP Response
│
▼
Response Body
│
▼
HTML/Text Processing
│
▼
Extract Information
│
▼
Validate / Store Data

In Go, different standard library packages can handle different parts of this process.

Some of the important ones are:

net/http
io
net/url
strings
net/http/httptest

Let's look at each one.

"net/http" — communicating with websites

The first thing a scraper needs to do is communicate with a web server.

This is where the "net/http" package comes in.

A simple HTTP GET request looks like this:

package main

import (
"fmt"
"net/http"
)

func main() {
resp, err := http.Get("https://example.com")
if err != nil {
fmt.Println(err)
return
}

defer resp.Body.Close()

fmt.Println("Status:", resp.Status)

}

The important part is:

resp, err := http.Get("https://example.com")

This sends an HTTP GET request to the server.

The server responds with an "http.Response".

The response contains information such as:

resp.Status
resp.StatusCode
resp.Header
resp.Body

For example:

fmt.Println(resp.StatusCode)

might produce:

200

A "200" response generally means the request was successful.

Why "defer resp.Body.Close()" matters

You'll often see this immediately after making an HTTP request:

defer resp.Body.Close()

Why?

Because the response body is a resource that needs to be closed when we're finished with it.

Think of it like opening a file.

You open it:

Open
↓
Read
↓
Close

HTTP response bodies follow a similar pattern.

So this:

resp, err := http.Get(url)

if err != nil {
return
}

defer resp.Body.Close()

means:

«Once this function finishes, close the response body.»

This is important for avoiding resource leaks.

"io" — reading the response

Getting the response isn't enough.

The actual webpage content is inside:

resp.Body

But "resp.Body" is an "io.ReadCloser".

We need to read it.

One simple approach is:

body, err := io.ReadAll(resp.Body)

if err != nil {
fmt.Println(err)
return
}

fmt.Println(string(body))

The "io.ReadAll()" function reads everything from the reader.

The result is a byte slice:

[]byte

That's why we convert it to a string:

string(body)

For example:

fmt.Println(string(body))

could produce HTML like:

<!DOCTYPE html>

Example Domain

Now we have the webpage content in memory.

Understanding "io.Reader"

One of the concepts I found particularly useful while learning this was the idea of an "io.Reader".

Go uses interfaces extensively.

Many things can be represented as a reader:

File
│
├── Reader
│
HTTP Response Body
│
├── Reader
│
Memory buffer
│
└── Reader

This means functions such as:

io.ReadAll()

can work with many different sources.

For example:

data, err := io.ReadAll(resp.Body)

The function doesn't need to know that the data came from a website.

It only needs something that implements the "io.Reader" interface.

This is one of the ideas that makes Go's standard library very composable.

"net/url" — working with URLs

When building a real scraper, URLs quickly become more complicated.

You may need to:

parse URLs
inspect their components
modify query parameters
construct URLs
resolve relative links

Go provides the "net/url" package for this.

For example:

package main

import (
"fmt"
"net/url"
)

func main() {
rawURL := "https://example.com/products?page=2"

u, err := url.Parse(rawURL)
if err != nil {
    fmt.Println(err)
    return
}

fmt.Println("Scheme:", u.Scheme)
fmt.Println("Host:", u.Host)
fmt.Println("Path:", u.Path)
fmt.Println("Query:", u.RawQuery)

}

The output would be something like:

Scheme: https
Host: example.com
Path: /products
Query: page=2

Instead of treating a URL as just a string, we can work with its individual components.

Query parameters

Suppose our scraper needs to request:

https://example.com/products?page=2

Instead of manually constructing the string, we can use "url.Values".

params := url.Values{}

params.Set("page", "2")

u := url.URL{
Scheme: "https",
Host: "example.com",
Path: "/products",
RawQuery: params.Encode(),
}

fmt.Println(u.String())

This produces:

https://example.com/products?page=2

This becomes especially useful when building scrapers that need pagination.

For example:

/products?page=1
/products?page=2
/products?page=3
/products?page=4

"strings" — processing extracted data

Once we've downloaded a webpage, we'll often need to work with text.

The "strings" package provides many useful functions.

For example:

title := " Example Product "

title = strings.TrimSpace(title)

fmt.Println(title)

Output:

Example Product

We can also search for text:

if strings.Contains(title, "Product") {
fmt.Println("Found product")
}

Or split strings:

links := "home,products,contact"

parts := strings.Split(links, ",")

for _, link := range parts {
fmt.Println(link)
}

Output:

home
products
contact

These operations become useful after extracting information from HTML.

A simple scraper using these packages

Now let's combine what we've learned.

Suppose we want to download a webpage and print its HTML.

package main

import (
"fmt"
"io"
"net/http"
)

func main() {
url := "https://example.com"

resp, err := http.Get(url)
if err != nil {
    fmt.Println("Request failed:", err)
    return
}

defer resp.Body.Close()

if resp.StatusCode != http.StatusOK {
    fmt.Println("Unexpected status:", resp.Status)
    return
}

body, err := io.ReadAll(resp.Body)
if err != nil {
    fmt.Println("Failed to read response:", err)
    return
}

fmt.Println(string(body))

}

The flow is now:

http.Get()
↓
http.Response
↓
resp.Body
↓
io.ReadAll()
↓
[]byte
↓
string

That's the foundation of our scraper.

Extracting information from the response

Downloading the HTML is only half the job.

A scraper is useful because it extracts specific information.

For example, imagine the response contains:

Go Web Scraping

Learning Go is interesting.

We could perform very simple text processing with "strings".

html := `

Go Web Scraping

Learning Go is interesting.

if strings.Contains(html, "Go Web Scraping") {
fmt.Println("Title found")
}

However, this approach becomes fragile very quickly.

HTML is structured data, so for serious HTML parsing, a dedicated HTML parser is usually more appropriate.

For example, Go developers commonly use:

golang.org/x/net/html

This is not part of the Go standard library, but it works naturally with the standard library's HTTP and I/O packages.

Parsing HTML with "golang.org/x/net/html"

After downloading a webpage, we can parse the HTML into a document tree.

Conceptually:

HTML Document
│
▼

│
┌────┴─────┐
▼ ▼

│
┌────┴────┐
▼ ▼

The parser allows us to navigate this structure instead of treating HTML as plain text.

A simplified example:

doc, err := html.Parse(resp.Body)
if err != nil {
fmt.Println(err)
return
}

Now "doc" represents the parsed HTML document.

From there, we can walk through the nodes and look for elements such as:

Finding links

Links are particularly important when building a crawler.

Suppose we have:

About

Products

A crawler could find those "href" attributes and then visit them.

Conceptually:

Page A
│
├── /about
│
└── /products
│
▼
Page B

This is where web scraping starts becoming web crawling.

A scraper might extract information from one page.

A crawler can follow links and discover additional pages.

"net/http/httptest" — testing the scraper

One of the most useful packages I encountered was:

net/http/httptest

Testing a scraper against a real website is not always a good idea.

The website could:

change its HTML
become unavailable
block requests
return different data
become slow

Instead, we can create a fake HTTP server.

Example:

server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "

Hello

")
}))

defer server.Close()

Now we have a local test server.

We can send our scraper to:

server.URL

instead of a real website.

Testing a scraper with a fake server

For example:

func TestScraper(t *testing.T) {
server := httptest.NewServer(http.HandlerFunc(
func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "

Hello

")
},
))

defer server.Close()

resp, err := http.Get(server.URL)
if err != nil {
    t.Fatal(err)
}

defer resp.Body.Close()

body, err := io.ReadAll(resp.Body)
if err != nil {
    t.Fatal(err)
}

if !strings.Contains(string(body), "Hello") {
    t.Fatal("expected Hello in response")
}

}

Now our test doesn't depend on the internet.

We control exactly what the server returns.

That's extremely useful.

Testing different HTTP responses

We can also test how our scraper handles errors.

For example:

server := httptest.NewServer(http.HandlerFunc(
func(w http.ResponseWriter, r *http.Request) {
http.Error(w, "Not Found", http.StatusNotFound)
},
))

Now our scraper receives:

404 Not Found

We can verify that our program handles that situation correctly.

We can also test:

200 OK
301 Redirect
403 Forbidden
404 Not Found
500 Internal Server Error

This is where testing becomes much more valuable than simply checking whether the scraper works once.

Putting the packages together

At this point, the roles of the packages become clearer.

They aren't competing packages.

They form a pipeline.

         URL
          │
          ▼
      net/url
          │
          ▼
      net/http
          │
          ▼
    HTTP Response
          │
          ▼
         io
          │
          ▼
      HTML data
          │
          ▼
    x/net/html
          │
          ▼
    Extract data
          │
          ▼
       strings

What I learned beyond the packages

The biggest lesson for me wasn't actually the individual packages.

It was understanding how they work together.

Before this, it was easy to think of web scraping as:

Download webpage
Extract information

But a more realistic system looks like:

URL
↓
HTTP request
↓
Timeout handling
↓
HTTP status validation
↓
Response body
↓
HTML parsing
↓
Data extraction
↓
Data validation
↓
Storage
↓
Tests

And once you start building a real scraper, additional concerns appear:

retries
timeouts
redirects
rate limiting
robots.txt
concurrent requests
duplicate URLs
malformed HTML
authentication
logging
error handling
data persistence

That's where a simple scraper starts turning into a real software engineering project.

A small mental model

The way I'm currently thinking about Go web scraping is:

net/http
↓
"Talk to the website"

io
↓
"Read what the website sent"

net/url
↓
"Understand the address"

x/net/html
↓
"Understand the HTML structure"

strings
↓
"Clean and process text"

httptest
↓
"Test everything without depending on the real website"

Once you understand those responsibilities, the code becomes much easier to reason about.

What's next?

My next step is to move beyond a basic scraper and explore how to build a more robust crawler in Go.

Some areas I want to explore are:

HTTP clients and custom timeouts
HTML tree traversal
Extracting links and images
URL normalization
Concurrent scraping with goroutines
Rate limiting
Retry strategies
Structured data models
Testing edge cases
Persisting scraped data
Handling failed requests
Building a complete CLI scraper

The interesting part is that the deeper I go, the more I realize that web scraping is not really about scraping.

It's about understanding how different parts of a software system communicate.

And Go's standard library provides many of the building blocks needed to understand and build those systems.

# What I Learned from Building with GIS Data and the Copernicus API at the KijaniSpace Hackathon

Ouma Asoyoh — Wed, 29 Jul 2026 06:51:50 +0000

As software developers, we often spend most of our time building APIs, databases, authentication systems, and web applications. That's certainly been my focus recently, especially working with Go, JWT authentication, and backend services.

Last week, however, I had the opportunity to participate in the KijaniSpace Hackathon, held at Zone01 Kisumu, and it introduced me to an entirely different side of software development.

Our challenge was to build solutions using:

Geographic Information Systems (GIS)
The Copernicus API
IoT devices where applicable

It was an opportunity to see how software can interact with our physical world.

What is GIS?

GIS (Geographic Information Systems) is a technology used to collect, analyze, visualize, and manage data that has a geographic location.

Imagine not just storing information like:

Temperature
Population
Vegetation
Buildings
Roads

...but also knowing exactly where that information exists on Earth.

That location data allows developers to build intelligent systems capable of answering questions like:

Which farms are experiencing drought?
Which roads are likely to flood?
Which areas are losing forest cover?
Where should new infrastructure be built?

GIS transforms ordinary data into meaningful geographic insights.

Discovering the Copernicus Program

Before this hackathon, I had heard very little about Copernicus.

Copernicus is the European Union's Earth Observation Programme. It provides free satellite imagery and environmental data collected by the Sentinel satellite missions.

Through its APIs, developers can access information about:

Land cover
Vegetation health
Weather patterns
Water bodies
Air quality
Climate changes
Disaster monitoring

What amazed me most is that much of this data is openly available for developers to build impactful applications.

Where IoT Fits In

Some teams also explored Internet of Things (IoT) solutions.

IoT devices can collect real-world information through sensors measuring:

Soil moisture
Temperature
Humidity
Water levels
Air quality

When combined with GIS and satellite imagery, these sensors create even richer datasets that enable better decision-making.

Imagine combining satellite observations with live sensor readings from farms or rivers. That's incredibly powerful.

My Biggest Takeaways

Although my background is primarily in backend development, this hackathon taught me several valuable lessons.

1. Software is Everywhere

Software doesn't stop at websites and mobile apps.

It powers agriculture, healthcare, climate science, environmental conservation, logistics, transportation, and countless other industries.

2. Learning New Technologies Quickly Is a Superpower

Hackathons force you to become comfortable being uncomfortable.

You rarely have the luxury of mastering every technology beforehand. Instead, you learn by building.

3. Collaboration Matters

Great products aren't built by developers alone.

Working with teammates who have different skills and perspectives often produces better solutions than working in isolation.

4. Open Data Creates Opportunities

One of the most exciting discoveries was how much high-quality public data exists today.

Developers can use satellite imagery and environmental datasets to create products that solve genuine problems affecting communities around the world.

Final Thoughts

I left the KijaniSpace Hackathon with more than just experience.

I gained a new appreciation for geospatial technologies, Earth observation, and the growing role software developers can play in solving environmental and societal challenges.

As I continue building backend systems in Go, I'll also be exploring how geospatial data, APIs, and IoT can be integrated into future projects.

Sometimes the best way to grow as a developer isn't by learning another programming language.

It's by discovering an entirely new domain where software can make a difference.

Thank you to KijaniSpace, Zone01 Kisumu, the organizers, mentors, and every participant who made the event an incredible learning experience.

Happy coding!

# Understanding Backtracking Through a Tetris Optimizer in Go

Ouma Asoyoh — Tue, 14 Jul 2026 18:22:47 +0000

When I first heard the term backtracking, it sounded like a complicated algorithm reserved for computer scientists. After spending the last couple of weeks learning it and implementing it in a Tetris Optimizer project, I realized something surprising:

Backtracking is simply the art of making a decision, checking whether it works, and if it doesn't, undoing it and trying something else.

This article explains backtracking using a practical project instead of abstract examples.

The Problem

Imagine you have several Tetris pieces (tetrominoes), and your goal is to fit all of them into the smallest possible square.

It might look something like this:

A A
A A

B B B
  B

C C C C

D
D
D D

The challenge is to arrange every piece so that:

No pieces overlap.
No piece extends outside the board.
Every piece is used exactly once.
The board is as small as possible.

This is much harder than it looks.

My First Thought

Initially, I thought I could simply place one piece after another.

Place A
Place B
Place C
Place D
Done!

Unfortunately, programming isn't always that kind.

Sometimes the first position you choose for piece A makes it impossible to place D later.

The mistake wasn't with D.

The mistake happened much earlier.

Enter Backtracking

Backtracking works like this:

Place a piece.
Try placing the next one.
If you get stuck...
Remove the last piece.
Try a different position.
Repeat until every piece fits.

It's essentially saying:

"If this path doesn't work, let's go back and explore another one."

Visualizing the Search

Suppose we have four tetrominoes.

Start

 ├── Put A at (0,0)
 │      ├── Put B
 │      │      ├── Put C
 │      │      │      ├── D fits ✅
 │      │      │      └── D fails ❌
 │      │      └── Try another position
 │      └── Move A elsewhere
 └── Try another position for A

Every branch represents another possibility.

Backtracking explores these branches until it finds one that works.

How It Looks in Go

The heart of the algorithm is surprisingly small.

func solve(index int) bool {

    if index == len(pieces) {
        return true
    }

    for every position {

        if piece fits {

            place(piece)

            if solve(index + 1) {
                return true
            }

            remove(piece)
        }
    }

    return false
}

Everything revolves around four actions:

Check if the piece fits.
Place it.
Continue recursively.
Remove it if necessary.

That final step—removing the piece—is what gives backtracking its name.

Why Remove the Piece?

Imagine solving a maze.

You choose the left path.

After walking for a while, you reach a dead end.

Do you stay there forever?

No.

You walk back to the last intersection and try another direction.

Your algorithm does exactly the same thing.

Place piece

↓

Dead end

↓

Remove piece

↓

Try another location

The Biggest Lesson I Learned

The code wasn't the difficult part.

The difficult part was learning how recursive calls think.

Once I stopped imagining recursion as "functions calling functions" and started imagining it as exploring a decision tree, everything became much clearer.

Drawing recursion trees on paper helped me understand why the algorithm behaved the way it did.

Why This Isn't Brute Force

Many people assume backtracking is just brute force.

Not quite.

Brute force explores every possibility.

Backtracking stops exploring a path the moment it knows that path cannot succeed.

For example:

Can piece C fit?

No.

Don't continue.

Go back immediately.

That early rejection saves an enormous amount of work.

Making the Solver Faster

My Tetris Optimizer taught me that backtracking alone isn't enough.

Several improvements can dramatically reduce runtime:

Start with the smallest possible board.
Place the most restrictive pieces first.
Skip positions where a piece obviously cannot fit.
Stop searching as soon as a valid arrangement is found.
Avoid repeating board states you've already explored.

Small optimizations can turn a solver that runs for minutes into one that finishes in seconds.

What I Took Away

Learning backtracking changed how I think about programming.

It taught me that solving complex problems doesn't always require knowing the answer immediately.

Instead, it requires having the confidence to:

Make a decision.
Test it.
Admit when it doesn't work.
Undo it.
Try again.

That lesson applies far beyond algorithms.

Sometimes the fastest path to a solution begins with the willingness to step back.

Final Thoughts

If you're currently learning recursion or backtracking, don't get discouraged if it feels confusing at first.

Almost everyone struggles with it initially because the challenge isn't writing the code—it's changing the way you think about problem-solving.

Once that mental shift happens, backtracking becomes one of the most elegant techniques you'll ever use.

Happy coding!

[Boost]

Ouma Asoyoh — Sat, 04 Jul 2026 21:25:09 +0000

Choosing the Right Backend Framework: Django vs. Gin vs. Ruby on Rails.

Ouma Asoyoh — Sat, 04 Jul 2026 21:23:58 +0000

Every application we use today—from banking apps to social media platforms—has something working behind the scenes. That hidden engine is called the backend.
The backend is responsible for processing requests, storing data, handling authentication, enforcing business rules, and ensuring everything works as expected when users interact with an application.
One of the first decisions backend developers make is choosing a framework. A framework provides the tools, structure, and best practices needed to build applications faster and more securely.
Today, let's look at three popular backend frameworks: Django, Gin, and Ruby on Rails.

Django (Python) Django is one of the most mature and feature-rich backend frameworks available. Built using Python, it follows the philosophy of "batteries included." This means many features developers need are already built into the framework, including: User authentication Admin dashboard Database ORM Security protections URL routing Form validation Because so much comes ready to use, developers can spend more time solving business problems instead of rebuilding common features. Best for: Content management systems E-learning platforms Business applications APIs Startups building products quickly Advantages: Fast development Excellent security features Large community Extensive documentation Scales well for many applications Trade-offs: The framework includes many components, so it can feel heavier than minimalist frameworks.
Gin (Go) Gin is a lightweight web framework built for the Go programming language. Unlike Django, Gin keeps things minimal. It gives developers speed and flexibility while letting them choose many of the additional tools they want to use. One reason many developers enjoy Gin is its impressive performance. Since Go is a compiled language designed for concurrency, Gin can efficiently handle many requests simultaneously while using relatively few system resources. Best for: REST APIs Microservices High-performance systems Real-time services Cloud-native applications Advantages: Extremely fast Lightweight Excellent concurrency support Easy to deploy Great for scalable services Trade-offs: Developers often need to choose and integrate additional libraries themselves, which can mean more setup than frameworks like Django.
Ruby on Rails (Ruby) Ruby on Rails has influenced modern web development more than many people realize. It introduced ideas like Convention over Configuration, allowing developers to spend less time configuring projects and more time building features. Rails emphasizes developer productivity. Many startups have used it to build products quickly because it helps developers move from idea to working application in a short time. Best for: Startup MVPs SaaS applications E-commerce platforms Social platforms Business applications Advantages: Rapid development Clean project structure Large ecosystem Mature tooling Excellent developer experience Trade-offs: Rails may not match Go-based frameworks in raw performance, though it is more than capable for many production applications. Which One Should You Learn? There isn't a single "best" framework. The right choice depends on the kind of problems you're solving. Choose Django if: You enjoy Python. You want lots of built-in functionality. You want to build complete applications quickly. Choose Gin if: You enjoy Go. Performance matters. You're interested in cloud-native development and microservices. Choose Ruby on Rails if: You value developer productivity. You want to build products rapidly. You appreciate clear conventions and an opinionated framework. Final Thoughts A framework is just a tool. What matters most is understanding backend fundamentals—HTTP, databases, authentication, APIs, security, caching, and application architecture. Once you understand these concepts, learning a new framework becomes much easier. Rather than chasing whichever framework is trending today, invest in mastering the principles behind backend development. Frameworks evolve, but solid engineering fundamentals remain valuable throughout your career. As I continue learning backend development, one thing has become increasingly clear: every framework has its strengths. The key isn't finding the "perfect" framework—it's choosing the one that best fits the problem you're trying to solve.Every application we use today—from banking apps to social media platforms—has something working behind the scenes. That hidden engine is called the backend. The backend is responsible for processing requests, storing data, handling authentication, enforcing business rules, and ensuring everything works as expected when users interact with an application. One of the first decisions backend developers make is choosing a framework. A framework provides the tools, structure, and best practices needed to build applications faster and more securely. Today, let's look at three popular backend frameworks: Django, Gin, and Ruby on Rails.
Django (Python) Django is one of the most mature and feature-rich backend frameworks available. Built using Python, it follows the philosophy of "batteries included." This means many features developers need are already built into the framework, including: User authentication Admin dashboard Database ORM Security protections URL routing Form validation Because so much comes ready to use, developers can spend more time solving business problems instead of rebuilding common features. Best for: Content management systems E-learning platforms Business applications APIs Startups building products quickly Advantages: Fast development Excellent security features Large community Extensive documentation Scales well for many applications Trade-offs: The framework includes many components, so it can feel heavier than minimalist frameworks.
Gin (Go) Gin is a lightweight web framework built for the Go programming language. Unlike Django, Gin keeps things minimal. It gives developers speed and flexibility while letting them choose many of the additional tools they want to use. One reason many developers enjoy Gin is its impressive performance. Since Go is a compiled language designed for concurrency, Gin can efficiently handle many requests simultaneously while using relatively few system resources. Best for: REST APIs Microservices High-performance systems Real-time services Cloud-native applications Advantages: Extremely fast Lightweight Excellent concurrency support Easy to deploy Great for scalable services Trade-offs: Developers often need to choose and integrate additional libraries themselves, which can mean more setup than frameworks like Django.
Ruby on Rails (Ruby) Ruby on Rails has influenced modern web development more than many people realize. It introduced ideas like Convention over Configuration, allowing developers to spend less time configuring projects and more time building features. Rails emphasizes developer productivity. Many startups have used it to build products quickly because it helps developers move from idea to working application in a short time. Best for: Startup MVPs SaaS applications E-commerce platforms Social platforms Business applications Advantages: Rapid development Clean project structure Large ecosystem Mature tooling Excellent developer experience Trade-offs: Rails may not match Go-based frameworks in raw performance, though it is more than capable for many production applications. Which One Should You Learn? There isn't a single "best" framework. The right choice depends on the kind of problems you're solving. Choose Django if: You enjoy Python. You want lots of built-in functionality. You want to build complete applications quickly. Choose Gin if: You enjoy Go. Performance matters. You're interested in cloud-native development and microservices. Choose Ruby on Rails if: You value developer productivity. You want to build products rapidly. You appreciate clear conventions and an opinionated framework. Final Thoughts A framework is just a tool. What matters most is understanding backend fundamentals—HTTP, databases, authentication, APIs, security, caching, and application architecture. Once you understand these concepts, learning a new framework becomes much easier. Rather than chasing whichever framework is trending today, invest in mastering the principles behind backend development. Frameworks evolve, but solid engineering fundamentals remain valuable throughout your career. As I continue learning backend development, one thing has become increasingly clear: every framework has its strengths. The key isn't finding the "perfect" framework—it's choosing the one that best fits the problem you're trying to solve.

What a Mini Conference on Computer Graphics Taught Me About Building Better Technology

Ouma Asoyoh — Mon, 08 Jun 2026 11:03:22 +0000

Every time you unlock your phone, watch a film, or open an app — computer graphics are quietly doing the heavy lifting. We just rarely stop to think about it. 🖥️

This past Saturday, I had the privilege of attending a mini conference on Computer Graphics at Zone01 Kisumu, and it genuinely shifted the way I think about technology.

So, what are computer graphics? At its core, it's the field that deals with how computers generate, process, and display visual content — from the icons on your screen to the cinematic visuals in blockbuster films. It sits at the intersection of mathematics, physics, and creativity, and that combination alone makes it fascinating.

Here's what stood out to me:

🔢 Mathematics is the invisible engine. Vectors, matrices, and transformations are what make images render, move, and feel real. As someone who sometimes questioned why math mattered in tech — I get it now.

🎮 The applications are everywhere. Gaming, animation, medical imaging, architectural visualisation, AI-generated visuals, simulations, and the interfaces we interact with daily — computer graphics is the backbone of all of it.

🌍 The future is wide open. With the growth of AR/VR, AI-driven design tools, and real-time rendering, this field is only expanding. For young developers and entrepreneurs in Africa, that's not a distant opportunity — it's a present one.

What hit me most was realising that building great digital products isn't just about writing clean code. It's about understanding how users see and experience what you build. Design, visuals, and interaction are not afterthoughts — they are the product.

As an aspiring technology entrepreneur, this session reminded me that solving real problems requires a wide lens. The more disciplines I understand, the better products I can imagine and build.

Technology is not one thing — it's a mosaic. And computer graphics is one of its most vivid tiles. 🎨

To anyone building in tech: when did you first realise that your field connected to something much bigger than you expected? I'd love to hear your story.

ComputerGraphics #SoftwareDevelopment #TechInAfrica #Zone01Kisumu #Innovation #LearningEveryDay #ArtificialIntelligence #GameDevelopment #TechEntrepreneur #DigitalInnovation #StudentLife #FutureOfTech

DEV Community: Ouma Asoyoh

Building a web scraper in go: Understanding the go standard libraries.

Example Domain

Go Web Scraping

Go Web Scraping

Finding links Links are particularly important when building a crawler. Suppose we have:

Hello

Hello

# What I Learned from Building with GIS Data and the Copernicus API at the KijaniSpace Hackathon

What is GIS?

Discovering the Copernicus Program

Where IoT Fits In

My Biggest Takeaways

1. Software is Everywhere

2. Learning New Technologies Quickly Is a Superpower

3. Collaboration Matters

4. Open Data Creates Opportunities

Final Thoughts

# Understanding Backtracking Through a Tetris Optimizer in Go

The Problem

My First Thought

Enter Backtracking

Visualizing the Search

How It Looks in Go

Why Remove the Piece?

The Biggest Lesson I Learned

Why This Isn't Brute Force

Making the Solver Faster

What I Took Away

Final Thoughts

[Boost]

Choosing the Right Backend Framework: Django vs. Gin vs. Ruby on Rails.

What a Mini Conference on Computer Graphics Taught Me About Building Better Technology

ComputerGraphics #SoftwareDevelopment #TechInAfrica #Zone01Kisumu #Innovation #LearningEveryDay #ArtificialIntelligence #GameDevelopment #TechEntrepreneur #DigitalInnovation #StudentLife #FutureOfTech

Finding links

Links are particularly important when building a crawler.

Suppose we have: