DEV Community: Philip Damwanza

Calculating Days in JS: A Beginner's Guide

Philip Damwanza — Thu, 13 Aug 2026 07:19:12 +0000

Ever wanted to know what numerical "day of the year" a date falls on (e.g., January 31st is day 31, but February 1st is day 32)?

We can do this easily by subtracting January 1st from our target date and converting milliseconds into days!

JavaScript
function dayOfTheYear(date) {
const year = date.getFullYear();

// Get January 1st of that exact year
const startOfYear = new Date(year, 0, 1);

// Find the difference in milliseconds
const diffTime = date.getTime() - startOfYear.getTime();

// Convert milliseconds to days (1000ms * 60s * 60m * 24hrs)
// Plus 1 because January 1st itself is Day 1, not Day 0!
const diffDays = Math.floor(diffTime / (1000 * 60 * 60 * 24)) + 1;

return diffDays;
}

console.log(dayOfTheYear(new Date("2026-01-01"))); // Output: 1
console.log(dayOfTheYear(new Date("2026-02-01"))); // Output: 32

Building QrStamp: A Lightning-Fast QR Code & Analytics Tracker in Go

Philip Damwanza — Mon, 03 Aug 2026 07:12:05 +0000

Need a lightweight, self-hosted service to generate trackable QR codes without dealing with third-party SaaS limits? I built QrStamp—a minimalist, high-performance web application powered by Go, SQLite, and vanilla web tech.

Why Go & SQLite?
Go (net/http): Delivers blazing-fast server execution and concurrency for handling redirects and stats tracking effortlessly.

SQLite (modernc.org/sqlite): Provides zero-config, embedded data storage so the entire app runs as a single portable file.

QR Generation: Uses github.com/skip2/go-qrcode to encode PNG assets on the fly.

Core Backend Architecture
The heart of QrStamp relies on atomic database transactions. When someone scans a unique tracking link (e.g., /qr/{id}), the server immediately looks up the destination URL and increments the scan counter in a single step:

Go
func (db *DB) ScanAndGetURL(id string) (string, error) {
tx, err := db.Begin()
if err != nil {
return "", err
}
defer tx.Rollback()

var originalURL string
err = tx.QueryRow(`SELECT original_url FROM qrcodes WHERE id = ?`, id).Scan(&originalURL)
if err != nil {
    return "", err
}

_, err = tx.Exec(`UPDATE qrcodes SET scans = scans + 1 WHERE id = ?`, id)
if err != nil {
    return "", err
}

return originalURL, tx.Commit()

}
The Result
With a modern dark-mode UI, instant QR rendering, and a real-time scan metrics counter, QrStamp is the ultimate quick utility project for anyone looking to sharpen their backend skills in Go.

Building DevSpot Kenya: A Lightweight Tech Event Aggregator in Go

Philip Damwanza — Mon, 03 Aug 2026 06:13:00 +0000

If you have ever tried keeping up with tech meetups, developer workshops, and hackathons across Kenya, you know how scattered the information can be. Announcements are often buried across various social platforms, making it tough to stay in the loop.

To solve this, I built DevSpot Kenya—a lightweight platform designed to aggregate local technology events into a single, centralized hub.

The Tech Stack
To keep things fast, reliable, and straightforward, I used:

Backend: Go (using the Gin framework) for high-performance routing and lightweight API endpoints.

Database: SQLite for simple, file-based data storage during development.

Scraper & Ingestion: Custom event scraper and API handlers to ingest event batches and clean up link data.

Containerization: Docker for smooth deployment and local testing.

How the Backend Comes Together
Here is a quick look at how the core Gin router handles setting up endpoints for incoming events:

Go
package main

import (
"net/http"
"github.com/gin-gonic/gin"
)

type Event struct {
ID string json:"id"
Title string json:"title"
Location string json:"location"
EventDate string json:"event_date"
}

func main() {
r := gin.Default()

r.GET("/api/events", func(c *gin.Context) {
    // Fetch events logic here
    c.JSON(http.StatusOK, gin.H{
        "message": "Fetching DevSpot Kenya events...",
    })
})

r.Run(":8080")

}
What I Learned
Simplicity Wins: Using Go combined with SQLite cut out unnecessary configuration overhead, letting me focus entirely on clean data ingestion and API logic.

Environment Management: Properly setting up .gitignore early on saved me from pushing local database files and build binaries to GitHub.

3 Simple Go Habits That Will Save You Hours of Debugging

Philip Damwanza — Mon, 03 Aug 2026 05:59:02 +0000

We have all been there. You look at a Go function you wrote just two weeks ago, and it looks like a complete mystery. Writing code that compiles is easy. Writing Go code that is readable, maintainable, and easy to debug is the real superpower.The Go philosophy values simplicity and clarity over cleverness. You do not need to master complex architecture to write better code today. Here are three simple, actionable habits you can start using in your next package.1. Use Meaningful Names (But Keep Go Idioms in Mind)Go prefers short variable names, but they must still carry clear meaning based on their scope. Avoid cryptic, single-letter names for long functions or global states.❌ Bad:gofunc process(d time.Duration) {
// confusing if the function is long
let t := time.Now().Add(d)
}
Use code with caution.✅ Good:gofunc process(expiryTimeout time.Duration) {
deadline := time.Now().Add(expiryTimeout)
}
Use code with caution.Why it matters: Code is read far more often than it is written. While a short r is fine for a receiver or a brief loop index, use descriptive names for data that travels through your application logic.2. Keep Functions Small and Return EarlyGo code can quickly become unreadable if you deeply nest your if statements. Use the "return early" strategy by handling errors immediately. This keeps your successful code path aligned to the left of your screen.❌ Bad (Deeply Nested):gofunc SaveUser(u *User) error {
if u != nil {
if u.IsValid() {
err := db.Save(u)
if err == nil {
return nil
}
return err
}
return errors.New("invalid user")
}
return errors.New("nil user")
}
Use code with caution.✅ Good (Return Early):gofunc SaveUser(u *User) error {
if u == nil {
return errors.New("nil user")
}
if !u.IsValid() {
return errors.New("invalid user")
}
return db.Save(u)
}
Use code with caution.Why it matters: Returning early eliminates the "arrow anti-pattern" (deeply nested code). It makes your functions incredibly easy to read, test, and debug from top to bottom.3. Comment the "Why," Not the "What"Go features self-documenting syntax. Your comments should not repeat what the code plainly states. Instead, use them to explain why a specific approach or workaround was necessary.❌ Bad:go// Increment total by one
total++
Use code with caution.✅ Good:go// Retry limit is set to 3 to prevent hammering the third-party billing API
const maxRetries = 3
Use code with caution.Why it matters: Avoid stating the obvious. Use comments to provide critical business context or architectural constraints that the code itself cannot show.
Clean Go code is not about perfection. It is about empathy for the next developer who touches your project—even if that developer is you.Pick just one of these habits for your next pull request, and notice how much easier debugging becomes!

The One-Line Bug That Broke Five People's Imports at Once

Philip Damwanza — Tue, 28 Jul 2026 07:07:47 +0000

We're building a forum app in Go for our Zone01 Kisumu cohort — five of us, split by feature: auth, posts, comments, filters, and me leading the core/integration side. Two weeks in, everything was compiling fine. Then one morning I pulled the latest code and the whole project refused to build.

The error looked something like this:

internal/posts/categories.go:6:2: package forum/internal/models is not in std

"Not in std"? My package isn't in the standard library. Weird flex, Go, but okay — what actually happened?

The setup

Here's the thing about Go modules that I hadn't really internalized until this bit me: the line at the top of go.mod

go
module github.com/kahenda/forum

isn't just a label. It's the namespace your entire project lives inside. Every internal import — internal/models, internal/auth, whatever — has to be spelled out as github.com/kahenda/forum/internal/models, because that prefix is literally derived from that one line.

Somewhere along the way, a teammate's branch had a go.mod that said module forum instead — probably from running go mod init fresh without checking what was already there. When that got merged, our shared go.mod briefly had the wrong module name. Nobody noticed immediately, because that specific person's own code still compiled — they'd written their imports against the wrong name too, so it was internally consistent for them.

The explosion happened for everyone else, because our code was written against the correct name, and now the correct name didn't exist anymore.

Why the error message was so confusing

package forum/internal/models is not in std doesn't sound like "your go.mod changed." It sounds like Go is looking for your package in its own standard library folder — which, technically, it is! Once the module name changes, Go has no idea forum/internal/models is your code. It just goes looking for it in /usr/lib/go/src/forum/..., finds nothing, and reports exactly that.

If I hadn't already known what module in go.mod actually controls, I'd have spent an hour convinced my Go installation was broken.

The fix

Two-part fix, and both parts matter:

Restore the correct module line:
go
module github.com/kahenda/forum
Fix every file that had been written against the wrong prefix:
go
// before
import "forum/internal/models"

// after
import "github.com/kahenda/forum/internal/models"

That second part is the annoying one — it's not a global find-and-replace across the whole codebase, just whichever files got written during the window when go.mod was wrong. We caught them one build error at a time, which is tedious but at least Go tells you exactly which file and line.

What I'd tell past-me

Treat go.mod like you'd treat a database schema in a team project — something one person owns and everyone else pulls, never something anyone regenerates locally without checking first. It's such a small file that it's easy to forget it's load-bearing for literally every import in the project.

Anyone else had a one-line config change cascade into a dozen confusing error messages? What was yours?

How I Made Sure You Can't Like and Dislike the Same Post at Once

Philip Damwanza — Tue, 28 Jul 2026 07:05:31 +0000

Quick one today. While building the reactions feature for our team's forum project (Go + SQLite), I hit a question that sounds obvious until you actually have to implement it: what happens when a user likes a post, then clicks dislike on the same post? Do they end up with both a like and a dislike registered? Because that would be a bug — a post shouldn't be simultaneously liked and disliked by the same person.

The naive approach (don't do this)

The tempting first instinct is: every click on Like or Dislike just inserts a new row into a reactions table.

sql
INSERT INTO reactions (user_id, target_type, target_id, value)
VALUES (?, ?, ?, ?);

This breaks immediately. Click like, then dislike, and now you've got two rows for the same user and the same post — one with value = 1, one with value = -1. Your like/dislike counts are now both incremented, which is exactly the bug we're trying to avoid.

The fix: let the database enforce the rule

Instead of trying to handle this entirely in application code, I put a constraint directly on the table:

sql
CREATE TABLE reactions (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER NOT NULL,
target_type TEXT NOT NULL CHECK (target_type IN ('post','comment')),
target_id INTEGER NOT NULL,
value INTEGER NOT NULL CHECK (value IN (1,-1)),
UNIQUE (user_id, target_type, target_id)
);

That UNIQUE (user_id, target_type, target_id) line is doing the real work. It tells SQLite: this combination can only exist once. No matter what your application code does, the database itself won't let a user have two reaction rows for the same post.

Now the application logic gets simple

With that constraint in place, "toggle a reaction" becomes a clean three-way decision:

go
func SetReaction(db *sql.DB, userID, targetID int64, targetType string, value int) error {
var existing int
err := db.QueryRow(
SELECT value FROM reactions WHERE user_id = ? AND target_type = ? AND target_id = ?,
userID, targetType, targetID,
).Scan(&existing)

switch {
case err == sql.ErrNoRows:
    // no reaction yet — insert
    _, err = db.Exec(`INSERT INTO reactions (user_id, target_type, target_id, value) VALUES (?, ?, ?, ?)`,
        userID, targetType, targetID, value)
    return err

case existing == value:
    // clicked the same button again — remove it (toggle off)
    _, err = db.Exec(`DELETE FROM reactions WHERE user_id = ? AND target_type = ? AND target_id = ?`,
        userID, targetType, targetID)
    return err

default:
    // switching like <-> dislike — update in place
    _, err = db.Exec(`UPDATE reactions SET value = ? WHERE user_id = ? AND target_type = ? AND target_id = ?`,
        value, userID, targetType, targetID)
    return err
}

}

Three outcomes, mapped directly to what a user actually expects:

First click → your reaction gets recorded.
Click the same button again → your reaction gets removed (un-like / un-dislike).
Click the other button → your reaction flips.
Proving it actually works

The satisfying part was writing a test that walks through all three states in sequence and checks the counts after each step:

go
repo.ToggleReaction(userID, "post", postID, Like)
// likes = 1, dislikes = 0

repo.ToggleReaction(userID, "post", postID, Like) // same button again
// likes = 0, dislikes = 0 (toggled off)

repo.ToggleReaction(userID, "post", postID, Like)
repo.ToggleReaction(userID, "post", postID, Dislike) // switch
// likes = 0, dislikes = 1

Seeing that last assertion pass — dislikes went up exactly as likes went down, never both — was a nice moment. It's a small feature, but it's the kind of thing that's genuinely broken in a lot of quickly-built apps, and a single UNIQUE constraint is all it took to make it structurally impossible to get wrong.

Anyone else have a case where a database constraint saved you from writing a pile of application-level validation code?

[Boost]

Philip Damwanza — Mon, 20 Jul 2026 07:39:32 +0000

Philip Damwanza

Jul 20

SQLite vs. PostgreSQL: Two SQL Giants Built for Different Worlds

#database #productivity

1 min read

SQLite vs. PostgreSQL: Two SQL Giants Built for Different Worlds

Philip Damwanza — Mon, 20 Jul 2026 07:39:01 +0000

If you are writing raw SQL queries, your code might look identical whether you use SQLite or PostgreSQL. However, under the hood, they operate in completely opposite ways. SQLite is a serverless database, meaning the entire database is just a single file sitting directly on your disk with zero setup required. PostgreSQL, on the other hand, is a full client-server database that runs as a dedicated background process, requiring network connections to read and write data.

Because of this difference, they solve entirely different problems. SQLite shines in local development, mobile apps, and standalone CLI tools because it completely bypasses the network, making it incredibly fast and lightweight for single-user scenarios. However, the moment an application goes live on the web and needs to handle multiple users saving data at the exact same millisecond, SQLite will lock up. That is where PostgreSQL takes over, utilizing advanced row-level locking to handle thousands of concurrent readers and writers flawlessly.

How I Fixed a Git Merge Conflict (Without Losing My Code)

Philip Damwanza — Mon, 20 Jul 2026 06:53:20 +0000

We’ve all been there: you are busy coding, and suddenly you get a scary error saying your code conflicts with a teammate's work. Git won't let you pull their changes because it's afraid of overwriting your unsaved files. Instead of panicking, I used git stash. This command acts like a temporary clipboard—it safely hides your current work away so your workspace becomes completely clean.

With a clean screen, I was able to safely update the project, fix the conflicting lines of code by hand, and make sure everything compiled perfectly. Once the team's updates were safely pushed, I ran git stash pop to bring my hidden work right back. Git wasn't trying to break my project; it was just protecting my code. Next time you get stuck, remember the golden rule: Stash your work, fix the conflict, and pop it back!

Why Everyone Says "It Depends" When You Ask About the Best Programming Language

Philip Damwanza — Fri, 10 Jul 2026 12:03:20 +0000

Ask any developer "what's the best programming language?" and you'll get the same annoying answer: "it depends."

For example, Go is great for fast, simple backend services. Python is great for quick scripts and data work. JavaScript basically runs the entire web whether you like it or not. Rust is great when you can't afford a single memory bug. None of them are "the best" — they're just the best tool for a specific job.

Asking for the best language is like asking a carpenter for the best tool. Hammer? Screwdriver?
So all in all it actually depends what you're building.

Nobody Warns You How Much Debugging Is Reading, Not Coding

Philip Damwanza — Thu, 09 Jul 2026 12:41:59 +0000

When people picture "coding," they picture fast typing and features coming to life. Nobody pictures the real majority of the job: staring at a stack trace or lets say a particular project trying to figure out why something that should work, isn't.

Here's what nobody tells you starting out — getting good at debugging has almost nothing to do with how well you write code, and everything to do with how well you read.

The real difference between beginners and experienced devs isn't complex knowledge — it's that experienced devs read carefully and form a hypothesis before touching anything. Beginners (me included) tend to skip straight to changing code and hoping. It feels faster. It rarely is.
One thing i'd like to advise other fellow beginner devs is ....Slow down, read the error properly, and follow the stack trace to where it actually starts — not where it ends up.

What's a bug that taught you this the hard way?

[Boost]

Philip Damwanza — Thu, 09 Jul 2026 08:25:32 +0000

AI tools reshaping technical reading habits

Dumebi Okolo

Jul 8

Has the audience for technical articles dropped?

#discuss

1 min read