DEV Community: Collins Kipruto

100 DAYS OF DEVOPS

Collins Kipruto — Tue, 06 Oct 2026 13:04:21 +0000

Process Monitoring and Docker Installation — Day 2

One thing I appreciate about the KodeKloud challenges is how closely they simulate real-world scenarios where DevOps practices can be applied. Each challenge gives me an opportunity not only to complete a task, but also to understand the reasoning behind the tools and commands I am using.

Today, I worked on two main challenges and spent some additional time exploring Linux process and network monitoring.

1. Temporary User Setup with an Expiry Date

The first task involved creating a temporary user account with an expiry date.

I used:

sudo useradd -e 2027-01-08 kareem

This introduced me to an important aspect of Linux user management: controlling how long an account remains active.

I also explored commands such as userdel for removing users and learned how user account properties, including expiry dates, can be modified when necessary.

This is particularly useful in environments where temporary access needs to be granted to developers, contractors, or other team members for a specific period.

2. Installing Docker and Starting the Docker Service

The second task involved installing Docker packages and starting the Docker service.

The installation itself was fairly straightforward, especially with the official Docker documentation available as a reference. However, one important lesson I picked up was to understand the system before installing software.

I used:

cat /etc/os-release

This allows you to identify the operating system and its version, which is important because installation steps and package repositories can vary between distributions.

It reminded me that in DevOps, following documentation is important, but understanding the environment you are working in is just as important.

Process Monitoring with `lsof`

Another area I explored today was process monitoring.

Process monitoring involves observing running processes, their resource usage, and their interactions with the operating system. One of the tools I used was lsof.

lsof stands for List Open Files. In Linux, many resources are represented as files, so lsof can provide useful information about which processes have files, devices, or network connections open and which users are associated with them.

For example:

lsof

can provide information about processes and the resources they are currently using.

I also learned that lsof can be useful when investigating network connections, including IPv4 and IPv6 connections. With the appropriate permissions, it can also be used to investigate resources associated with specific users or processes.

This gave me a better understanding of how Linux administrators and DevOps engineers can investigate what is happening on a system instead of simply guessing when something goes wrong.

Exploring Network Information

I also spent some time exploring Linux networking commands and learning how to identify different types of network information.

Some of the commands I used were:

hostname -I

Displays the IP addresses assigned to the host.

curl ifconfig.me

Shows the public IP address visible to the internet.

ip a

Provides detailed information about network interfaces and their assigned addresses.

ip route

Displays the system's routing table, including information about gateways and routes.

These commands helped me understand the difference between local network information and the public IP address used when communicating with external networks.

Exploring SSH

Another interesting thing I learned today was how SSH can be used for remote administration.

SSH allows an authorized user to connect to another machine remotely. However, having the machine's IP address alone is not enough. The target machine needs to have SSH access available, and the connecting user must have the appropriate credentials and permissions.

I would like to explore this further by setting up a controlled environment with a friend and learning how SSH authentication, networking, and remote administration work in practice.

Final Thoughts

Day 2 gave me a broader view of what happens underneath the applications I build.

From managing user accounts and installing Docker to monitoring processes and exploring network information, I am starting to see how individual Linux skills fit into the bigger DevOps picture.

There is still a lot to learn, but that is what makes the journey exciting.

Day 2 complete. On to Day 3.

100 DAYS OF DEVOPS

Collins Kipruto — Mon, 05 Oct 2026 12:13:32 +0000

Linux Commands — Day 1 🐧

Today marks day one of my journey toward becoming a DevOps Engineer.

I’ve started this journey with the help of KodeKloud Engineer and LabEx. My first KodeKloud task was to create a Linux user with a non-interactive shell.

Along the way, I learned about SSH (Secure Shell), different types of Linux shells, and how Linux manages users through files such as /etc/passwd.

Here are some of the commands I used:

ssh user@server
# Connect to a specific server

sudo useradd -s /sbin/nologin jim
# Create a user with a non-interactive shell

getent passwd jim
# Verify that the user was created

The output helped me understand how Linux represents users:

jim:x:1001:1001::/home/jim:/sbin/nologin
│   │ │    │    │ │         │
│   │ │    │    │ │         └── Login shell
│   │ │    │    │ └──────────── Home directory
│   │ │    │    └────────────── User information/comment
│   │ │    └─────────────────── GID
│   │ └──────────────────────── UID
│   └────────────────────────── Password placeholder
└────────────────────────────── Username

It may seem like a small task, but understanding these fundamentals is important as I continue building my Linux and DevOps skills.

Day 1 done. More to learn.

3 Months on Lockdown 🔒

Collins Kipruto — Mon, 21 Sep 2026 14:05:29 +0000

Wow! I can’t believe it has already been 3 months and 3 weeks since I joined Zone01. Time really does move fast.

When I joined, I came in with a mission: to become a strong DevOps engineer.

I also had a bigger vision for myself — to write code that is clean, flexible, maintainable, and sustainable, while continuously learning and contributing to the developer community.

And, of course, I wanted to prove something to myself: even with AI becoming a huge part of software development, there is still a place for developers who understand the fundamentals, can solve problems, and know how the systems they build actually work.

Getting my hands dirty with Go

One of the biggest things Zone01 has pushed me into is Go.

Before joining Zone01, Go was a language I had never worked with — honestly, I had barely heard about it.

Three months later, I have built three projects using Go.

The biggest difference isn't just that I learned the syntax. I've started understanding concepts around:

HTTP servers and routing
APIs
File handling
Concurrency
Data structures and algorithms
Testing
Dockerizing applications
Working with the terminal
Reading and debugging other people's code

There have definitely been moments where Go made me question my life choices. 😂 But that's also where most of the learning happened.

Learning from the people around me

One of the things I appreciate most about being in a developer-focused environment is the constant exposure to other people's work.

Everyone is working on something different, solving problems in their own way and pushing themselves in different directions.

That environment keeps me on my toes.

You might think you're doing well until you see someone else building something that makes you think:

"Okay... I need to learn that too."

And that's a good thing.

Apparently, Docker isn't a programming language

Another funny discovery: Docker.

When I first heard about Docker, I honestly thought it was another programming language I needed to learn.

Now I'm starting to understand containers, images, Dockerfiles, networking, ports and how applications can be packaged and deployed consistently.

And I'm only getting started.

Two hackathons later...

I also had the opportunity to participate in two hackathons during these first few months.

Both experiences pushed me beyond simply writing code.

They required working under pressure, collaborating with others, quickly understanding a problem, making technical decisions and actually building something within a limited amount of time.

Definitely challenging — but definitely worth it.

What's next?

I still have 8 months and 1 week left in this journey.

If the first three months have taught me this much, I'm excited to see what the remaining time will look like.

For the next 2 months and 1 week, my focus is:

1. Build a bakery management project with Go

I want to take what I've learned so far and apply it to a practical project involving things like inventory, sales, payments and reporting.

2. Go deeper into DevOps

My focus will be on:

Docker and containerization
Linux and terminal proficiency
Networking fundamentals and protocols
Understanding how applications are deployed
Improving my understanding of CI/CD and infrastructure

There is still a lot to learn.

But that's exactly why I'm here.

3 months down. 8 months and 1 week to go.

Let's see what happens next.

An Old Discovery

Collins Kipruto — Mon, 21 Sep 2026 13:32:51 +0000

Today, I decided to revisit one of my biggest projects this year, PINUC, to see how I could improve it based on the knowledge I’ve gained since joining Zone01.

As soon as I opened the root project folder, it felt strangely unfamiliar. It looked like someone else’s code. I couldn’t easily remember where some of the configuration files were or why I had structured certain parts of the project the way I did.

It took me quite some time just to understand some of the code I had written and remember what certain lines were doing.

And that’s when I realised something I had previously overlooked: the importance of writing comments and documenting your code.

I used to ignore comments because I thought:

“I’m the one writing the code. How could I possibly forget it?”

Well… apparently, I could. 😂

Looking at PINUC months later made me realise that code isn’t only written for the developer you are today. It is also written for the developer you will become months or even years from now.

Comments and documentation are almost like leaving a note for your future self:

“Hey, this is what I was thinking when I built this.”

Now, as I continue my journey toward becoming a better developer, I’m going back through PINUC and working on improving its codebase, structure, configuration, and overall maintainability.

It’s interesting to revisit an old project with new knowledge. What once seemed perfectly structured now gives me plenty of things I would do differently.

And honestly, I think that’s a good sign.

Growth means being able to look at your old code and recognise how much you’ve learned since writing it.

For those who have not yet checked the webiste here is the link: https://pre-inspected-used-cars-git-master-collins-projects-3eca33c8.vercel.app/

# 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.

DEV Community: Collins Kipruto

100 DAYS OF DEVOPS

Process Monitoring and Docker Installation — Day 2

1. Temporary User Setup with an Expiry Date

2. Installing Docker and Starting the Docker Service

Process Monitoring with lsof

Exploring Network Information

Exploring SSH

Final Thoughts

100 DAYS OF DEVOPS

Linux Commands — Day 1 🐧

3 Months on Lockdown 🔒

Getting my hands dirty with Go

Learning from the people around me

Apparently, Docker isn't a programming language

Two hackathons later...

What's next?

1. Build a bakery management project with Go

2. Go deeper into DevOps

An Old Discovery

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

The Challenge

🌧️ The Problem We Wanted to Solve

Introducing Resili

🤝 Working With Local Authorities

🧠 More Than Just an Alert System

💻 Building Under Pressure

👨‍💻 What I Learned

1. Start With the Problem

2. Teamwork Matters

3. Constraints Can Improve Your Thinking

🏆 The Result

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

🚀 Go Journey – Day 3: Accessing a Relational Database

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

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

Building a Go Payment API Library From Scratch

description:

tags:

1. Client Structure and a Sharper Grip on Pointers

2. Deconstructing the Authentication Flow

3. Functions vs. Methods: The Concrete Difference

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

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

Wrapping Up

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

Process Monitoring with `lsof`

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

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