DEV Community: Collins Kipruto

# Two Sleepless Nights, One Big Challenge: Building Resili at the Zone01 Hackathon 🌍🌧️

Collins Kipruto — Mon, 31 Aug 2026 09:33:20 +0000

After two sleepless nights, countless ideas, debugging sessions, and team discussions, we finally made it to the finish line.

I recently had the opportunity to participate in an in-house hackathon at Zone01, focused on one of the most important challenges facing communities and businesses today: the Green Economy.

The challenge wasn't simply to build software.

We had to identify a real-world problem, understand who was affected by it, and use technology to design a solution that could make a meaningful difference.

The Challenge

We were given seven different tracks to choose from:

🌊 Lake Victoria Water Quality Monitoring & Intelligence Platform
💧 Smart Irrigation & Water Management for Smallholder Farmers
🌱 Carbon Footprint & Sustainability Reporting for SMEs
☀️ Solar Installation Monitoring & Asset Management Platform
♻️ Smart Waste Management & Route Optimization
🌧️ Climate Risk Intelligence & Resilience Platform
🐟 Fish Traceability Platform

After discussing the different challenges, my team decided to take on Track 6: Climate Risk Intelligence & Resilience Platform.

And that is where Resili was born.

🌧️ The Problem We Wanted to Solve

Flooding is a major challenge for communities living in flood-prone areas, particularly around the Lake Victoria region.

One of the biggest problems isn't necessarily the lack of information.

It's getting the right information to the right people early enough to act.

When communities receive warnings too late, there may not be enough time to move people, protect property, relocate livestock, or prepare essential supplies.

We asked ourselves:

What if technology could help communities receive trusted flood warnings days before a disaster occurs?

That question became the foundation of our project.

Introducing Resili

Resili is a climate resilience and early-warning platform designed to help communities prepare for potential flooding before it happens.

The idea is to combine verified information, risk intelligence, and community communication into a single platform.

Instead of simply telling someone:

"A flood is coming."

We wanted the system to answer:

Where is the risk?
How serious is it?
Who is likely to be affected?
How much time do people have to prepare?
What actions should they take?
Where should they go if evacuation becomes necessary?

The goal is to move from reacting to disasters to preparing for them.

🤝 Working With Local Authorities

One of the most important parts of our idea was collaboration with county governments and relevant authorities.

A climate warning system is only useful if people trust the information it provides.

For that reason, Resili was designed around the idea of using verified and signed sources to communicate important warnings.

The system could help authorities:

Monitor potential flood risks.
Identify vulnerable areas.
Issue verified warnings.
Notify affected communities.
Provide recommended preparedness actions.
Coordinate evacuation efforts when necessary.

This creates a communication chain between risk intelligence → authorities → communities.

🧠 More Than Just an Alert System

We didn't want Resili to be another application that simply sends notifications.

We wanted it to provide actionable information.

For example, instead of only receiving:

⚠️ Flood Warning

a resident could receive information such as:

HIGH FLOOD RISK

📍 Your area may be affected.

⏱️ Prepare for possible evacuation.

🎒 Keep essential documents and supplies ready.

🐄 Move livestock and valuable equipment to safer locations.

📢 Follow instructions from verified local authorities.

This approach makes the information more useful because people know what to do next.

💻 Building Under Pressure

The most interesting part of the hackathon wasn't just the final product.

It was the process.

We had a very limited amount of time to go from:

Problem → Idea → Architecture → Development → Testing → Demo

And we had to make decisions quickly.

There were moments when things didn't work.

There were features we wanted to implement but couldn't complete within the available time.

And, of course, there was a lot of debugging. 😅

But that is probably one of the biggest lessons I took from the experience:

You don't need perfect conditions to build something meaningful. You need a clear problem, a focused team, and the willingness to keep iterating.

👨‍💻 What I Learned

This hackathon taught me several things beyond writing code.

1. Start With the Problem

It's easy as a developer to immediately think:

"What technology can I use?"

But the better question is:

"What problem are we actually solving?"

Understanding the problem helped us decide which features were actually important.

2. Teamwork Matters

Building a project under time pressure requires everyone to contribute.

Ideas need to be challenged.

Tasks need to be divided.

People need to communicate.

And sometimes you need someone on the team to say:

"This feature is nice, but we don't have time for it. Let's focus on what matters."

That discipline was extremely important for us.

3. Constraints Can Improve Your Thinking

Having only a short amount of time forced us to focus on the MVP.

Instead of trying to build everything, we had to ask:

What is the smallest version of this idea that can demonstrate real value?

That's a lesson I want to carry into future projects.

🏆 The Result

After two intense and sleepless nights, we successfully completed the hackathon and presented Resili.

I'm extremely proud of what our team managed to accomplish in such a short period.

But more importantly, I'm grateful for the opportunity to work on a problem that goes beyond technology.

Climate change and extreme weather events affect real people.

As developers, we have an opportunity to build systems that don't just make life more convenient, but can potentially help communities become more informed, prepared, and resilient.

A huge thank you to my amazing teammates and everyone at Zone01 who made this experience possible.

Two sleepless nights.

One challenging problem.

One great team.

And one solution we are proud to call Resili. 🌍💻

Zone01 #Hackathon #ClimateTech #GreenEconomy #ClimateResilience #FloodManagement #EarlyWarningSystems #SoftwareDevelopment #TechnologyForGood

🚀 Go Journey – Day 3: Accessing a Relational Database

Collins Kipruto — Wed, 29 Jul 2026 13:03:42 +0000

Today I wrapped up another milestone in my Go learning journey—connecting a Go application to a relational database.

Over the past few days, I've been building my backend fundamentals step by step. I started with RESTful APIs, moved on to web applications, and today I learned how to interact with a MySQL database.

One thing that stood out was how Go connects to a database. Instead of jumping straight into queries, you first configure the connection using the MySQL driver's Config struct and generate a DSN (Data Source Name) with FormatDSN(). After that, establishing the connection is surprisingly straightforward:

db, err := sql.Open(...)
if err != nil {
// handle error
}

This pattern has become very familiar to me. Whether I was building HTTP servers, writing REST APIs, or now working with databases, I keep seeing the same Go idiom:

Perform an operation.
Capture the result and err.
Check if err != nil.
Handle the error before moving on.

At first, I wondered why Go checks for errors so frequently. But the more I build with it, the more I appreciate the language's philosophy. By handling errors immediately, you're forced to think about what could go wrong and make your applications more reliable.

Another interesting observation was how similar querying multiple records and retrieving a single record by ID are. The structure is almost identical—the main difference is using Query() when expecting multiple rows and QueryRow() when expecting just one. That consistency made the concepts much easier to grasp.

Ironically, this was the topic I was most nervous about before starting. I expected databases to be the hardest part of the journey, but they turned out to be the smoothest so far. It's a reminder that sometimes the things we anticipate the most end up being the easiest once we dive in.

Looking forward to the next challenge as I continue building with Go.

🚀 Go Journey – Day 1: Building my first RESTful API with Gin

Collins Kipruto — Sun, 19 Jul 2026 10:47:36 +0000

Last week, I officially started learning how to build RESTful APIs in Go.
To keep things simple, I focused on the fundamentals before jumping into larger projects. My first API can:
✅ Retrieve all albums (GET /albums)
✅ Add a new album (POST /albums)
✅ Retrieve a specific album by its ID (GET /albums/:id)
Along the way, I learned what some of Gin's core features actually do instead of just copying code from tutorials.
A few concepts that finally clicked for me:
🔹 gin.Context
Carries information about the incoming HTTP request.
Helps read request data, validate input, and send responses back to the client.
🔹 Context.IndentedJSON()
Converts Go structs into properly formatted JSON.
Sends the JSON back to the client along with the appropriate HTTP status code.
🔹 BindJSON()
Reads the JSON sent in the request body.
Maps that data directly into a Go struct, making it easy to work with user input.
One thing I'm trying to do differently this time is document everything I learn instead of rushing to the next topic. I even created a README explaining what each function in my project does, because I want to understand the "why" behind the code—not just make it work.
This is only the beginning, but every endpoint I build is helping me understand how backend systems communicate with clients.
Next up:
Input validation
Better error handling
Connecting the API to a database
Authentication
I'm looking forward to seeing how much I improve over the next few months. 🚀

Go Journey – Day 2: Building My First Web Application in Go 🚀

Collins Kipruto — Sun, 19 Jul 2026 10:44:29 +0000

I shared my experience building my first RESTful API in Go. This week, I took the next step in my Go journey by learning how to build web applications.

The next milestone? Working with relational databases in Go.

My goal with this series is simple: learn Go one step at a time while documenting the journey. By the end, I want to have enough knowledge to build a complete web application—from the backend to the frontend—and I hope others who are learning Go can follow along too.

What I Learned This Week

This week was all about understanding how a web application works under the hood. Instead of just writing code, I focused on understanding the flow of a request and how different components fit together.

Here are some of the concepts I covered.

Storing Data with Structs

The first step was learning how to represent data using Go structs.

For the wiki application, each page was represented as a struct containing the page title and body.

type Page struct {
Title string
Body []byte
}

This became the foundation for everything else in the application.

Saving Data

After creating the struct, I learned how to save a page to disk.

Each page is stored as a text file, using the page title as the filename. This gave me a better understanding of how Go handles file operations and methods.

Loading Existing Pages

Saving data isn't enough—you also need to retrieve it.

I learned how to read the stored files back into memory so users can view pages that were previously created.

Although simple, this really helped me understand the flow of data in a web application.

Understanding net/http

One of the biggest topics this week was Go's net/http package.

I learned how HTTP requests move through the application and how Go uses handlers to respond to users.

Some of the things I explored included:

Creating routes
Handling requests and responses
Redirecting users when a page doesn't exist
Understanding http.ResponseWriter
Understanding *http.Request

Seeing how everything connects made the request-response cycle much clearer.

Template Caching

One of my favorite takeaways was learning about template caching.

At first, I was parsing HTML templates every single time a request came in.

func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
t, err := template.ParseFiles(tmpl + ".html")
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}

err = t.Execute(w, p)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
}

}

Then I learned there's a much better approach.

Instead of repeatedly reading template files from disk, you can parse them once when the application starts.

var templates = template.Must(
template.ParseFiles("edit.html", "view.html"),
)

This small change improves efficiency and is considered the better practice.

It was a great reminder that writing code isn't just about making it work—it's also about making it perform well.

Path Validation and Closures

Another interesting concept I encountered was path validation.

I learned how validating request paths prevents users from accessing invalid or unexpected routes.

While implementing this, I was introduced to closures in Go—something I had heard about before but hadn't used in a practical example.

That's definitely a topic I plan to explore further.

My Biggest Takeaway

This week taught me that building web applications is about much more than displaying pages.

It's about understanding:

how data flows,
how requests are processed,
how files are managed,
how templates are rendered efficiently,
and how to build applications that are secure and maintainable.

Every chapter makes me appreciate Go's simplicity even more.

What's Next?

The next chapter of my journey is working with relational databases in Go.

Once I have that in place, I'll begin combining everything I've learned into a larger project instead of isolated tutorials.

If you're also learning Go, I'd love to hear what you're currently building or what topics you think I should explore next.

Thanks for reading, and see you in the next chapter!

Happy coding! 🚀

Series: Learning Go in Public

✅ Part 1: Building My First RESTful API
✅ Part 2: Building My First Web Application
🔜 Part 3: Working with Relational Databases in Go

Building a Go Payment API Library From Scratch

Collins Kipruto — Thu, 09 Jul 2026 13:03:30 +0000

description:

Insights on pointers, methods, resource management, and HTTP clients while building an open-source Go library.

tags:

golang, backend, webdev, learning

A few days ago, a couple of friends and I decided to take a detour from our usual routines to build something practical: a Go library for payment APIs.

The goal is simple. Instead of every Go developer writing custom, repetitive code to integrate payment gateways, they can just import our open-source library straight from GitHub.

Building a library forces you to think deeply about architecture, developer experience, and language fundamentals. Here is everything this project has taught me so far.

1. Client Structure and a Sharper Grip on Pointers

Setting up the base client structure required a lot of intentional data modeling. In doing so, I gained a much clearer understanding of pointers in Go. Deciding when to pass a struct by value versus passing a pointer to mutating states is a critical choice when designing an API client that other developers will rely on.

2. Deconstructing the Authentication Flow

Implementing authentication gave me a front-row seat to the full request-response lifecycle. I broke down the exact steps needed to establish a secure connection:

URL Construction: Building clean, dynamic endpoints.
Request Creation: Preparing payloads and setting secure headers.
Validation: Verifying our data before it leaves the application.
Transmission & Response: Sending the request to the admin server and handling the incoming payload cleanly.

3. Functions vs. Methods: The Concrete Difference

While the terms are often used interchangeably in other languages, Go draws a distinct line between functions and methods.

A Function is a standalone block of code used to execute a program routine.
A Method is simply a function that contains a receiver, meaning it belongs to a specific type.

// This is a standalone function
func ClearCache() {
    // logic here
}

// This is a method belonging to the 'User' struct type
func (u *User) DeactivateAccount() {
    // logic here
}

4. Resource Management: Why You Must `defer Body.Close()`

One of the biggest gotchas for newer Go developers is resource leakage via HTTP responses. When you make a network request, the server keeps the connection open until you explicitly close it.

Using defer response.Body.Close() right after checking for errors is mandatory.

Think of it like borrowing a book from a library. If you keep borrowing books and never return them, your state keeps looping on "borrowing." Eventually, the library runs out of space, and you cannot borrow anymore. In Go, failing to close the body will cause your application to run out of memory and file descriptors.

5. Staying Flexible with `http.Client.Do()`

When interacting with different payment endpoints, you encounter various HTTP verbs like POST, GET, PUT, and DELETE.

Instead of wrapping our client in strict, specialized helpers, we relied on Go's native http.Client.Do() method. Because .Do() accepts a completely custom *http.Request object, it accommodates any HTTP method seamlessly. If an upstream payment provider suddenly changes a route from a POST to a PUT, our underlying architecture remains intact and resilient.

Wrapping Up

This project is turning out to be an amazing engineering journey. By building this library, I am moving past just "using" payment APIs to truly understanding how they function under the hood.

I'll be sharing more updates as my team moves closer to our alpha release. If you have any tips on building clean SDKs in Go, let me know in the comments below!

What I Learned Building My First Go Project (go-reloaded)

Collins Kipruto — Wed, 17 Jun 2026 09:42:25 +0000

During my first week at Zone01 Kisumu, I worked on a project called go-reloaded. It was my first real hands-on experience using Go, and it helped me understand not just the language, but also how to think like a developer.

In this article, I’ll share what I learned, the challenges I faced, and the key concepts that made everything click.

What the Project Was About

The goal of the project was to build a small Go program that works with command-line arguments and processes input using Go’s standard libraries.

This was my first time interacting deeply with:

os package
command-line arguments (os.Args)
basic Go program structure

At first, it felt confusing, but step by step, things started to make sense.

What I Learned

How command-line arguments work in Go I learned that Go provides access to raw input from the terminal using: os.Args

This returns a slice of strings where:
os.Args[0] is the program name
os.Args[1:] are the actual inputs

Working with the os package The os package became one of the most important parts of the project.

I used it to:
Read input arguments
Handle program execution flow
Understand how programs interact with the system

This helped me realize that Go is very close to the system level compared to JavaScript.

Breaking problems into smaller steps One of the biggest lessons wasn’t about code—it was about thinking. Instead of trying to solve everything at once, I learned to:

Understand the problem first
Break it into smaller tasks
Solve each part step by step

This made debugging much easier.

Challenges I Faced

At the beginning, I struggled with:

Understanding how os.Args works
Knowing where to start in the code
Handling errors when inputs were missing

Sometimes I would get stuck just trying to figure out what the program was actually receiving.

But debugging helped me a lot. Printing values at each step made things clearer.

Key Takeaways

Go is very explicit compared to JavaScript
The os package is powerful for system-level interaction
Command-line arguments are simple but very useful
Problem-solving is more important than syntax
Debugging is part of learning, not a failure

Final Thoughts

This project was a big step in my learning journey. It helped me understand how Go works and how to approach programming problems more effectively.

I’m still learning, but each project is making things clearer.

Next, I’m looking forward to building more complex projects and improving my backend and DevOps skills.