Fragments

Simulate Tests To Use Real Dependencies

deamking@icloud.com (Dream king) — Fri, 16 Jan 2026 03:06:04 GMT

This approach entered my workflow a few weeks ago after a colleague, Remedan Ridwan, pointed me to Testcontainers. What stood out wasn’t the tooling itself, but how little code was required to run real dependencies in tests. With Docker already becoming standard, it became practical to exercise integration paths against actual services rather than substitutes.

Most test strategies break down not because individual components are hard to test, but because the environment they run in is assumed rather than exercised.

Applications don’t run against a database in isolation. They run inside an environment: databases, message queues, caches, object stores, authentication services, clocks, filesystems, and network boundaries. Bugs tend to emerge at the seams between these pieces, especially where configuration, protocol behavior, or timing is involved.

Mocks simplify this environment aggressively. That simplification is often intentional, but it also removes entire classes of behavior that only exist when real systems are present.

What “Mocking the Environment” Usually Means

In practice, “mocking the environment” tends to mean one of the following:

Replacing external services with in-memory implementations
Mocking interfaces that represent networked systems
Using lightweight substitutes that approximate behavior (e.g., SQLite for Postgres, localstack-style APIs, fake SMTP servers)

These approaches are fast and convenient. They also tend to encode assumptions about how the environment behaves rather than verifying those assumptions.

For example:

A mocked queue acknowledges messages immediately, bypassing retry or backoff paths. In a real system like RabbitMQ, a consumer restart triggers redelivery, revealing missing idempotency in message handlers.
In-memory databases permit concurrent writes without contention. A real PostgreSQL instance under load introduces blocking transactions, timeouts, or deadlocks that surface only with actual concurrency.
Fake caches return values instantly, hiding latency from misses. A real Redis instance introduces spikes that affect downstream logic.
Mocked services respond synchronously, missing rate limits like 429 errors from real endpoints.
Test doubles accept any token, ignoring expiry or clock skew enforced by real auth providers.
Local mocks enable atomic writes. Real object stores like S3 show partial or eventual consistency.
Mocks never fail DNS, bypassing retry logic in real networks.

Using Real Dependencies as Disposable Infrastructure

An alternative approach is to run real services with production-grade binaries inside tests, and treat them as disposable infrastructure.

This is the model Testcontainers supports.

Rather than mocking a database client or a queue interface, the test starts an actual instance of the dependency in a container:

The same database engine
The same message broker
The same object storage service
The same auth provider or proxy

The test code interacts with these services over the same protocols used in production. Configuration, startup behavior, and failure modes are preserved.

Databases are a common example, but they’re not the point. The point is environment simulation.

Example: Database as One Dependency Among Many

A database example is illustrative because it’s familiar.

// Container wraps testcontainers with database and cache connections
type Container struct {
    PostgresContainer *postgres.PostgresContainer
    RedisContainer    *redisContainer.RedisContainer
    DB                *gorm.DB
    Redis             *redis.Client
}

// Terminate gracefully shuts down all containers
func (c *Container) Terminate() error {
    ctx := context.Background()

    if c.PostgresContainer != nil {
        if err := c.PostgresContainer.Terminate(ctx); err != nil {
            return err
        }
    }

    if c.RedisContainer != nil {
        if err := c.RedisContainer.Terminate(ctx); err != nil {
            return err
        }
    }

    return nil
}

// CleanupDatabase cleans all test data from database tables
func (c *Container) CleanupDatabase(t *testing.T) {
    t.Helper()

    if c.DB == nil {
        return
    }

    // Dynamically get all user tables from information_schema
    var tables []string
    err := c.DB.Raw(`
        SELECT table_name
        FROM information_schema.tables
        WHERE table_schema = 'public'
        AND table_type = 'BASE TABLE'
        AND table_name NOT LIKE 'pg_%'
        AND table_name NOT LIKE 'sql_%'
    `).Scan(&tables).Error

    if err != nil {
        t.Logf("failed to get table list: %v", err)
        return
    }

    // Truncate all found tables
    for _, table := range tables {
        err = c.DB.Exec("TRUNCATE TABLE " + table + " CASCADE").Error
        if err != nil {
            t.Logf("failed to truncate table %s: %v", table, err)
        }
    }
}

// CleanupCache clears all Redis cache data
func (c *Container) CleanupCache(t *testing.T) {
    t.Helper()

    if c.Redis == nil {
        return
    }

    err := c.Redis.FlushAll(context.Background()).Err()
    if err != nil {
        t.Logf("failed to flush Redis cache: %v", err)
    }
}

// CleanupAll cleans both database and cache
func (c *Container) CleanupAll(t *testing.T) {
    c.CleanupDatabase(t)
    c.CleanupCache(t)
}

// SetupTestMain sets up shared containers for a test package
// Should be called from TestMain to initialize containers once per package
func SetupTestMain() (*Container, func() int) {
    ctx := context.Background()

    // Setup PostgreSQL
    postgresContainer, err := postgres.Run(ctx,
        "postgres:15-alpine",
        postgres.WithDatabase("testdb"),
        postgres.WithUsername("testuser"),
        postgres.WithPassword("testpass"),
        testcontainers.WithWaitStrategy(
            wait.ForLog("database system is ready to accept connections").
                WithOccurrence(2).
                WithStartupTimeout(5*time.Minute)),
    )
    if err != nil {
        panic("failed to start postgres container: " + err.Error())
    }

    host, err := postgresContainer.Host(ctx)
    if err != nil {
        panic("failed to get postgres host: " + err.Error())
    }

    port, err := postgresContainer.MappedPort(ctx, "5432")
    if err != nil {
        panic("failed to get postgres port: " + err.Error())
    }

    cfg := &config.Config{
        Database: config.Database{
            Host:        host,
            Port:        port.Int(),
            User:        "testuser",
            Password:    "testpass",
            Name:        "testdb",
            MaxIdleConn: 10,
            MaxOpenConn: 100,
        },
    }

    dbConn, err := db.NewPostgres(cfg)
    if err != nil {
        panic("failed to connect to test database: " + err.Error())
    }

    // Setup Redis
    redisContainer, err := redisContainer.Run(ctx,
        "redis:7-alpine",
        testcontainers.WithWaitStrategy(wait.ForLog("Ready to accept connections")),
    )
    if err != nil {
        panic("failed to start redis container: " + err.Error())
    }

    redisHost, err := redisContainer.Host(ctx)
    if err != nil {
        panic("failed to get redis host: " + err.Error())
    }

    redisPort, err := redisContainer.MappedPort(ctx, "6379")
    if err != nil {
        panic("failed to get redis port: " + err.Error())
    }

    redisClient := redis.NewClient(&redis.Options{
        Addr: redisHost + ":" + redisPort.Port(),
    })

    // Test Redis connection
    err = redisClient.Ping(ctx).Err()
    if err != nil {
        panic("failed to connect to test redis: " + err.Error())
    }

    container := &Container{
        PostgresContainer: postgresContainer,
        RedisContainer:    redisContainer,
        DB:                dbConn,
        Redis:             redisClient,
    }

    // Return cleanup function for TestMain
    cleanup := func() int {
        if err := container.Terminate(); err != nil {
            println("failed to terminate containers:", err.Error())
            return 1
        }
        return 0
    }

    return container, cleanup
}

// RunStandardMigrations runs migrations for common models used across tests
func (c *Container) RunStandardMigrations(t *testing.T) {
    t.Helper()

    err := c.DB.AutoMigrate(&user.User{}, &user.Preference{})
    require.NoError(t, err)
}

This verifies more than CRUD correctness:

Connection negotiation
Authentication
Schema compatibility
Transaction semantics
Driver behavior

But the same pattern applies elsewhere.

The same test suite can bring up:

A Redis instance with real eviction behavior
A Kafka broker with actual partitioning and offsets
An S3-compatible object store that enforces request signing
An SMTP server that accepts and rejects messages based on protocol rules

Each container adds realism that mocks typically erase.

Why This Is Not “Just Another Mock”

It’s tempting to think of containers as “better mocks.” That framing is misleading.

Mocks simulate behavior. Containers instantiate systems.

A containerized dependency:

Has startup time
Has configuration errors
Has resource limits
Can fail in partial or unexpected ways

Those properties are inconvenient, but they’re also where integration bugs come from.

When tests exercise real services, failures tend to be less surprising. Not because the code is better, but because the assumptions are weaker.

Cost and Constraints

This approach is not free.

Tests are slower
Docker becomes a test dependency
Parallelism must be controlled
CI resource limits matter

It also shifts test failures from “logical mismatch” to “environmental mismatch,” which can be harder to debug if logs and observability aren’t captured.

Adopting this style of testing usually forces a rethink of the CI process. Cloud CI environments are optimized for fast, isolated test runs, not for standing up short-lived infrastructure. If these bugs are meant to be caught in CI, pipelines need to account for container startup time, resource allocation, and artifact collection.

That said, many of these issues are often easier to surface locally than in CI. A developer running tests with real dependencies on their machine can reproduce configuration errors, protocol mismatches, and startup failures quickly, without waiting on a constrained CI environment.

In my small monolithic application, using Testcontainers did not meaningfully affect CI time. Container startup was fast, Docker overhead was negligible, and tests did not introduce noticeable delays. The additional realism came without a proportional cost.

Where This Tends to Pay Off

Running real dependencies is most useful where code behavior depends on:

Protocol details
Configuration correctness
Ordering and timing
Cross service interactions
Version specific behavior

In other words, places where mocks tend to encode guesses.

Using real services doesn’t eliminate bugs. It mostly eliminates a specific category of bug: the one where the system behaved correctly according to your test, and incorrectly according to reality.

Scope

This is not an argument against mocking. It’s an argument against pretending the environment is simpler than it is.

Testcontainers provides a way to reconstruct small, controlled slices of reality inside tests. Databases are just one visible example.

Whether that trade-off is worthwhile depends on where failures are expensive and surprises are unacceptable.

A Case for Trunk-Based Development

deamking@icloud.com (Dream king) — Mon, 14 Jul 2025 14:03:01 GMT

Why do we hold onto our code for so long before showing it to each other?

Most teams I’ve worked with (and most setups I’ve used) default to some version of: Create a feature branch → Work for a few days → Push a PR → Wait for review → Hope it merges clean.

It feels normal. Professional, even. But after watching a video by Dave Farley, I started wondering whether that approach, however polished, is fundamentally at odds with what continuous integration was meant to be.

And if we’re honest, the cost of holding onto code is real:

Merge conflicts that eat hours
Integration bugs that don’t show up until late
Review cycles that turn into backlogs
Features that go stale before they ship

So here’s my proposal:

What if we stopped working in isolation and started working in the open, every day? What if the default wasn’t to hide changes, but to integrate them immediately?

A Simpler Model, Hiding Less

Enter: Trunk-Based Development (TBD).

The idea is disarmingly simple:

Everyone commits to a shared main (or trunk) branch
If you do branch, the branches live for a few hours, max a day
You commit often (multiple times a day, ideally)
You use feature flags, dark launching, or branch by abstraction to hide incomplete features, not separate them

The goal isn’t just faster merging, it’s always working on the same “truth” of the codebase, together.

You shrink the distance between your work and everyone else’s.

You don’t wait to be “done” to integrate. You integrate to help get to “done.”

Why It’s Worth Considering (Even If It Feels Radical)

I haven’t rolled out TBD on a team yet, but I want to. Here’s why it’s compelling to me:

🧩 It removes the "two truths" problem

Every branch is a fork in reality. Testing, debugging, and merging all become harder when you're working on different timelines. TBD says: stop forking reality.

⚡ It tightens feedback loops

If your changes break something, you know immediately. If they work well, others can build on them, right now.

🤝 It encourages better engineering habits

Small, testable commits. Stronger CI/CD. Less cowboy coding. More collaboration. This model nudges you toward sustainable speed.

🌱 It helps you grow as a developer

When you ship partial features behind flags and test unfinished ideas in production (safely), you start thinking more modularly. You work in smaller steps. You get better at decoupling.

So, How Do You Work Without Branches?

We’d need some process guardrails to make this safe and practical. Based on what I’ve learned, here’s what adopting TBD might look like:

✅ Daily-or more frequent-commits to main

Work in small, composable chunks. A few lines of logic. A tiny refactor. A test case. Ship that. Move on.

✅ Feature flags everywhere

Use toggles to control whether a feature is active, not whether the code exists. That means you can commit unfinished work without affecting users.

✅ Strong CI/CD pipelines

If commits go straight to main, your tests better catch regressions fast. Ideally, your test suite gives you high confidence on every push.

✅ Dark launching and branch by abstraction

Need to deploy backend logic without exposing a UI? Do it. Want to refactor a critical path gradually? Abstract it, then replace it behind the scenes.

Why This Isn’t Just About Speed

One of the most surprising things I took away from Dave Farley’s talk was that trunk-based development isn’t just about faster releases. It’s about trust.

Trust that your teammates won’t break things carelessly. Trust that your process can catch bugs early. Trust that your code doesn’t have to be perfect before it’s shared.

It’s not about being reckless. It’s about choosing visibility over isolation. And when you do that, something strange happens: People talk more. Teams align better. Features ship more predictably.

The Trade-Off

Adopting this would mean letting go of “I’ll push when I’m done.” It would mean embracing partial work in main. It would mean making integration a habit, not a milestone.

But the payoff? No more last-minute merges. No more “Oh wait, you changed that too?” No more testing code that will never actually ship.

Final Thought

Git made branching feel cheap. But integration costs? Those are still high, especially when you do them late.

TBD flips the script: it makes integration cheap and isolation costly.

That shift, mental, technical, and cultural, is what makes it worth exploring.

If you’re building something fast-moving and collaborative, I think this approach deserves more attention. I’m still learning, still poking holes, but the direction feels right.

And maybe, just maybe, it's time we stop treating integration as the thing we do at the end, and start treating it as the thing we do all the time.

The Gold Rush for AI Assistants

deamking@icloud.com (Dream king) — Fri, 30 May 2025 14:03:01 GMT

Learning MCP

There’s a particular feeling I get when the tech world starts buzzing like everyone just heard the same secret at once. Right now, that secret is: AI assistants are the next big platform.

But beneath the noise, I’ve been wrestling with a quieter question:

If everyone’s racing to build the next AI assistant, where does someone like me a developer who’s not at OpenAI or Google actually fit in?

This is me talking to my past self, the one who felt both inspired and slightly paralyzed by this wave. I’m writing this because I think the most valuable seat at this table might not be the one building the assistants, but the one forging the tools they use.

Assistants Need Tools, Not Just Intelligence

Every assistant, no matter how fancy the model, becomes useless the moment it hits a wall. Ask it to book a flight? It needs a travel API. Want it to manage your files? It needs a storage service. Assistants are only as capable as the tools they can call.

And here’s the thing: most developers are focusing on the assistant layer the chat UIs, the voice apps, the agent runners. But there’s a quieter, more foundational layer underneath all of that: the tools. The APIs. The MCP servers.

What is an MCP Server?

MCP stands for Model Context Protocol. It’s a standardized way for AI assistants to interact with software. Think of it as a shared grammar that allows an AI to command a wide range of apps without custom code for each.

An MCP server acts as a translator sitting beside a particular application. It knows how to take a natural-language request and turn it into something the app understands whether that’s a Python call in Blender or a GitHub API query.

It handles:

Tool discovery: What can this app do?
Command parsing: What is the AI asking for, and how do we do that here?
Response formatting: How do we return something meaningful?
Error handling: What happens when something goes wrong?

On the other end, the MCP client lives with the AI assistant. It talks to the MCP server, relays messages, and feeds responses back into the AI. All of this happens via a protocol that’s transport-agnostic (HTTP, WebSocket, even stdin/stdout), and uses JSON Schema to describe capabilities.

This architecture allows an assistant to use any MCP-compliant tool the same way a GitHub server, a database query engine, or a local file browser. It’s the glue that binds natural language to real action.

What That Looks Like for Me

I’m starting to shift my mindset from “app developer” to “toolmaker for assistants.”

That means I’m asking:

Can I build an MCP server around something I already use or maintain?
Can I turn some internal service like a chunked file uploader or a tagging system into a callable tool for AI?
Can I write my tools in a way that feels native to this protocol-first world?

We’re not just building web apps anymore. We’re building AI-accessible utilities.

Where I’m Investing My Time

Here’s the roadmap I’m following loosely, but intentionally:

1. Master MCP-friendly APIs

Whether it’s OpenAPI specs or JSON Schema definitions, I want my tools to be discoverable and callable without extra glue code.

2. Wrap Existing Services in MCP Servers

That chunked upload system I’ve been building? I’m wrapping it in an MCP server so any AI assistant can manage file uploads through it.

3. Understand Orchestration

I’m learning how AI assistants string tools together using orchestration layers like LangChain and AutoGen. This helps me make my tools composable.

4. Go Deep in One Domain

My focus is on developer tools and healthcare. I want to create AI-usable services that are actually helpful in these spaces.

5. Keep an Eye on Standards

The MCP spec is evolving. I’m watching how it handles things like authentication, permissions, and plugin discovery so I can build forward-compatible tools.

A Safe Prediction and a Big Shift

Here’s the shift I can’t stop thinking about:

In the near future, apps won’t be things people install. They’ll be installing services assistants who know enough tools for the day to day.

Instead of getting a user to download your app, onboard, understand your UI, sign in, and learn your flow you’ll just have an MCP-compliant server. The user tells their assistant (GPT, Gemini, whoever), “I need this done,” and your tool quietly powers the response.

There’s no app store. No tutorials. No language barrier or digital literacy hurdle. Whether the user is tech-savvy or not, the assistant becomes the interface and your MCP server becomes the service.

This changes everything. Customer support, ecommerce, onboarding, payment flows all the traditional barriers of software UX fade into the background. It’s not about building the prettiest UI anymore. It’s about being callable.

The moment that clicked for me, I realized: building tools for this world isn’t just a new opportunity. It’s a whole new lens.

Why This Matters (Zooming Out)

There’s a deeper shift happening here. AI assistants aren’t just a trend they’re a new way of interacting with software. But assistants can’t do anything alone. They need ecosystems. They need you.

If you’re a developer wondering how to catch this wave, you don’t need to reinvent intelligence. Just build something useful and make it callable.

I think the next generation of successful devs won’t be the ones who built the assistants. It’ll be the ones who quietly empowered them.

And if you're unsure where to start look at the tools you’ve already built. Chances are, one of them just needs a spec and a little polish to become someone else’s missing piece.

First Time at the Booth

deamking@icloud.com (Dream king) — Tue, 20 May 2025 14:03:01 GMT

I didn’t know how hard it would be to explain YeneHealth until I had to.

I was at ETEX 2025, Ethiopia’s tech expo showcasing AI, cybersecurity, smart cities, and all the buzzwords that usually sound like they belong to somewhere else. But this time, they didn’t. They belonged here. To us.

We had a sponsored booth, its not our first time showing up at this scale. I had the chance to represent YeneHealth. My first thought? I hope they don’t ask too many questions. Because, truthfully, I only had the “About Us” version of YeneHealth in my head. And that version isn’t built for conversations.

It’s hard to explain YeneHealth because it’s not one thing. We work across so many edges of healthcare, data, community, and technology that trying to condense it into an elevator pitch feels like trying to summarize a whole family history in one sentence. At first, I stumbled. I said the same few phrases, something about “improving access to reproductive healthcare” and “data-driven community engagement” but I could see people nodding politely, not curiously.

Then something shifted. I started telling stories.

Not pitch-perfect ones, just real ones. Like how we started by trying to solve a small pain point. Or how we learned from the communities we served. Or how our team wasn’t a bunch of detached techies but people with skin in the game, literally and metaphorically.

And people leaned in.

I didn’t have all the history. I still don’t. But the more I talked, the more I understood why we do what we do, and how much that matters.

What I Didn’t Expect to Learn

Events like ETEX aren’t just for showing off. They’re for sharpening your story.

When you stand behind the booth, you’re not pitching, you’re pressure-testing your message. Every confused face or curious question forces you to refine. Every person who gets it becomes a mirror that tells you, “Yes, that landed.”

It’s also a kind of low-key battlefield. The investors and potential partners? They don’t wear badges that say “VC.” They walk around in simple clothes, ask casual questions, and listen closely. And they love teams who can explain their product clearly, without the fluff. You’ll only catch them if you show up prepared and present.

For Any Startup Thinking of Skipping the Booth

Don’t.

Especially if you’re technical. Bring your engineers. Bring your designers. Let the people who build the product explain it. There’s a magic that happens when someone who’s knee-deep in code explains why they care about what they’re building. People listen differently.

It’s also one of the rare chances to collect live, honest, unfiltered feedback. Think of it as a mini focus group that actually volunteered to talk to you.

And for the team? Motivation skyrockets. There’s something energizing about seeing strangers get excited about what you’re building. It reminds you why the long hours and unresolved tickets matter.

Event Review

The venue Addis International Convention Center was massive. The kind of space that makes you think, “Wow, this country is dreaming big.” And it felt good to be part of that dream, even just for a day.

I walked in nervous and walked out grateful. I thought I was going there to explain what we do. But I ended up understanding it better myself.

If you ever get the chance to represent your team at an event like this take it. You won’t just represent your product. You’ll rediscover it.

Chucked Uploads, Persistent Sessions

deamking@icloud.com (Dream king) — Fri, 16 May 2025 14:03:01 GMT

I was wiring up a file upload system in Node.js, not the flashy, frontend kind with progress bars and drag-and-drop zones, but the backend guts. The part that takes a stream of chunks, holds onto them safely, and eventually stitches them together into the final file.

I didn’t want to build an HTTP server. I didn’t want a frontend client. I just needed a Node.js class that could handle uploads in pieces, reliably, resumably, and testably.

Turns out, that second word resumably is where things got tricky.

Why Chunked Uploads?

Let’s set the stage. Chunked uploads matter when:

Files are large (video, images, backups)
Network stability is unreliable
You want to support pause/resume functionality

I wanted a simple API:

startUpload(id, filename);
appendChunk(id, chunkIndex, data);
completeUpload(id);

Later, I added a session-based version with metadata and visibility support:

startSession(id, totalChunks, originalName, targetPath, visibility);
receiveChunk(id, chunkIndex, chunk);
finalizeUpload(id);

Two APIs, one underlying system. It worked. Until I restarted the process.

The Problem: Memory Is Not Persistence

All session state lived in memory:

private sessions = new Map<string, UploadSession>();

So if the process crashed or restarted, it lost track of what chunks were received. It couldn’t resume an upload. The actual chunk files were still on disk, but without the metadata, they were just orphaned data.

It hit me: resumability isn’t just about chunk files, it’s about remembering the upload state.

That meant one thing: I had to persist session metadata to disk.

The Fix: Metadata Files

Every session now gets a metadata.json file alongside its chunks:

{
  "id": "upload123",
  "originalName": "photo.jpg",
  "totalChunks": 3,
  "receivedChunks": [0, 1],
  "targetPath": "/storage/uploads/photo.jpg",
  "visibility": "public"
}

When the server starts, I call:

loadSessionsFromDisk();

It crawls the upload directory, finds metadata files, and reconstructs the sessions map. Just like before, but now durable.

This one change made everything more robust. Unexpected crash? No problem. The next chunk will pick up right where the last one left off.

Logging Progress

While I was at it, I added a tiny improvement: log progress.

getProgress(sessionId); // → 66.6%

This was especially helpful in tests (and will be even more useful in real UIs). It's based on the receivedChunks.size / totalChunks ratio.

Testing the Whole Flow

I didn't want to trust myself to remember how this worked in 6 months. So I wrote unit tests:

✅ Session creation
✅ Chunk appending
✅ Upload completion
✅ Progress tracking
✅ Session recovery after restart

One test even manually simulates a restart:

// Start session, write chunks
// Simulate restart: new ChunkManager()
// Call loadSessionsFromDisk()
// Finalize and assert output file exists

What I Learned

State is the hard part. Writing files is easy. Remembering what's been written and why, is where the real design lives.
Tests give you courage. I could refactor, extend, and restart with confidence because tests had my back.
Resumability isn’t magic. It’s just careful persistence, plus a willingness to think through failure modes.

What’s Next?

Support for retrying failed chunks
Expiring old sessions
Moving files to cloud storage after finalization
Exposing this to a real client or CLI

If you're building file upload systems in Node, I hope this helps you skip the mental potholes I hit. And if you're like me, building to understand, I hope this gave you a little more clarity than you had before.

As always, I’m still learning. If you’ve built something like this before, I’d love to hear how you approached it.

When Values Are Sold for Dreams

deamking@icloud.com (Dream king) — Sun, 04 May 2025 14:03:01 GMT

I watched something today that I can’t unsee. Link, Similar Video

A man asking for a daughter’s hand in marriage. An Ethiopian family. A Chinese groom. A bride far too young. The kind of young that makes you stop and ask: how did we get here?

They didn’t speak the same language. A translator stood between them like an uneasy bridge, and yet no one seemed to acknowledge the absurdity of it. Not once did someone ask the obvious question: how do you build a life with someone when you can’t even understand each other’s words? Instead, the focus was on logistics. His salary, 92,000 a month. His marital status, divorced, with two daughters. Then the bidding began. And I don’t say that metaphorically. It was a negotiation cloaked in ceremony.

I wish I could say it was an outlier. But this is becoming disturbingly common: daughters sent off to foreign men under the label of marriage and opportunity. It’s easy to call it cultural. It’s harder to call it what it really is: transactional. Daughters traded for stability. Futures sold for the promise of prosperity. And in some cases, trafficked, under the illusion of consent.

Some might argue the girl knew what she was doing. Maybe she even wanted it. Maybe she dreamed of a better life, of escape. But I doubt it. When you can’t speak the same language as your future husband, when you’re too young to understand what marriage even means, can we really call that a choice? And this is where the responsibility falls, on the parents, on the elders. These are people who understand what life outside your home, your language, your people really costs. They know what it means to raise children in a culture that may never fully accept them. Where the mother might never belong. Where she will have no voice and no one in her corner. They know all this, and still, they send her off.

How do you justify shipping your daughter to a man you don’t know, in a country you don’t understand, where she won’t be able to speak for herself? How does that feel okay? More disturbingly, how are there still no policies, no protections, no systems in place to name this for what it is?

It’s human trafficking, dressed up as marriage.

And yet we rarely say those words out loud. Because to say them would mean asking harder questions. About who benefits. About why entire communities stand by as this happens in broad daylight. About the quiet complicity of those who should know better. About the shame we hide behind tradition. And maybe the hardest truth: we’ve normalized it. We’ve let it blend into the background noise of poverty and ambition. So much so that when someone calls it trafficking, people flinch, not because it’s wrong, but because they know it’s true. We tell ourselves it’s about opportunity. About love. About progress. But what I saw wasn’t love. It wasn’t opportunity.

It was a negotiation.

A family selling their daughter for a chance at a life they’ll never live themselves. And I’m not blaming the girl, she’s too young to know what’s being taken from her. What disappoints me most is the elders. The ones who should’ve known better. The ones who chose silence.

The Dangerous Fantasy of Western Worship

There’s a sickness in our culture, and I don’t say that lightly. We’ve wrapped the Western world, and anything foreign, really, in this glossy fantasy. As if proximity to whiteness or wealth is salvation.

We’ve confused escape with empowerment. Let me be clear: I’m not against intercultural love. Real love crosses borders, learns languages, builds bridges. But that’s not what this was. This was grooming, facilitated by family, celebrated by community, and ignored by the state.

Poverty Is Not a Permission Slip

Yes, we live in poverty. Yes, we are struggling. But poverty doesn’t excuse the erosion of values. It doesn’t make it acceptable to sell your child, literally or metaphorically, for the illusion of escape. Values are what shape societies. And when the elders, the supposed guardians of those values, begin to trade them for short-term gain, what hope do we have?

What scares me most is that society didn’t condemn what happened in that video. It celebrated it. Comment after comment praising the union, the “luck,” the opportunity. Not one person seemed to ask: how can a marriage work without communication? What does it say about us that this kind of transaction is even possible?

A Broken Mirror

When a society rewards the sacrifice of its own daughters, we are no longer talking about isolated incidents. We are staring into the face of systemic failure.

Governments love to talk about economic growth. But what about moral collapse? What happens when a generation grows up believing their worth is measured in dollars and passports? What does that do to their identity? Their sense of possibility?

We’ve replaced values with fantasies. We’ve confused imitation with aspiration. We think the only way forward is out.

But a culture that abandons its foundation can only fall.

Rebuild From Within

Here’s what I’m still wrestling with: how do we begin to rebuild?

We can’t undo that girl’s story. But maybe we can learn from it. Maybe we can start asking better questions.

Not “how do we escape poverty?” But “how do we rise with dignity?”

Not “how do we get out?” But “what can we build right here?”

If this post feels angry, it’s because it is. If it feels unfinished, that’s because it is. I don’t have neat answers.

But I do know this:

We cannot afford to sell our future for the illusion of someone else’s dream.

Especially not when the price is our values.

Would you like to publish this as a standalone post or part of a series exploring culture, values, and development?

The Strength to Not Take Sides

deamking@icloud.com (Dream king) — Sun, 13 Apr 2025 14:03:01 GMT

Sometimes, Sticking to What's Right Means Not Taking Sides

Living in Addis, you know how tough dealing with landlords can be. It often feels unfair, and arguments happen. Today, I saw one get pretty heated in my neighborhood.

A landlord was fighting with his tenant over a small thing – a broken socket worth maybe 200 birr. But it was clear the anger was about more than that. They both started shouting insults. It was ugly, but the kind of thing you unfortunately see sometimes.

Here’s what got me thinking: The tenant's wife was there. She'd been quiet while the landlord insulted them. But when her own husband started firing back with nasty insults, she told him repeatedly, "Stop. Stop insulting him." He was too angry to listen.

So, she picked up a stick and actually hit her husband – hard, broke the stick, enough to get his attention and make him stop the insults.

Honestly, I was surprised. My first thought was, "Shouldn't she be on his side?" Usually, you back up your family, right? Especially when they're fighting someone else.

But she didn't. It wasn't that she agreed with the landlord. It seemed like she just believed that insulting people was wrong, period. Even if her husband was doing it. Even if he was angry for a good reason. She wanted them to leave with respect, not by sinking to the same level of insults.

I understood why the husband was mad. He felt disrespected just for being a tenant. His anger made sense.

But his wife showed a different kind of strength. It wasn't about fighting back louder. It was about sticking to her own rule: We don't act ugly, even when we're treated badly. That takes real discipline, especially when it means going against your own loved one in the heat of the moment.

What I Took Away:

It made me think. Maybe being strong isn't always about blindly supporting "your side." Sometimes, real strength is sticking to what you believe is right, even if it's uncomfortable or means telling your own people they're wrong. It's easy to just jump in and fight with your group. It’s much harder to hold onto your own principles.

Seeing that wife choose her principle (no insults) over just backing up her husband really stuck with me. It showed a quiet, powerful kind of strength. It's definitely something worth thinking about.

Thinking About File Storage

deamking@icloud.com (Dream king) — Sat, 12 Apr 2025 14:03:01 GMT

There’s a funny thing that happens when you try to rebuild a system you thought you understood.

You start with confidence, convinced you’re just a few lines of code away from "solving" the problem. Then, somewhere along the way, the code teaches you that the problem was never what you thought it was.

That’s exactly what happened to me this week.

I set out to build a clean, Laravel-inspired file storage system in TypeScript. The kind of thing you’d package, publish, and forget about. But somewhere between implementing visibility handling, path generators, and file streams, the work stopped being about "files", and started being about designing for reality.

🪵 The Illusion of Just "Saving Files"

When I first wrote:

fs.writeFileSync(path, contents);

I felt like the job was done. Simple, right? Write the file, return the path. On to the next feature.

Except real systems don’t work that way.

In the real world, "saving a file" has baggage:

Where does it live? (Path logic.)
Who can access it? (Visibility rules.)
What happens when storage moves to S3? (Abstraction.)
What happens when the upload is slow, or interrupted? (Resilience.)
How do you test it all without hardcoding assumptions? (Flexibility.)

Laravel doesn’t hide these problems. It just makes them composable. That’s the genius. And that’s the part I’ve been chasing in this rewrite.

🗂 Paths Are Strategies, Not Strings

One of the first design dead ends I hit was hardcoded file paths.

You upload an avatar? You might write:

const path = `users/${userId}/avatar.png`;

But this kind of logic spreads like weeds. Before long, it’s tangled across your codebase. Worse, it ties your logic to a single assumption: that file paths are static.

Laravel’s model taught me something smarter: treat paths as a strategy.

So I wrote:

interface PathGenerator {
  generatePath(originalName: string): string;
}

And suddenly, my logic stopped caring about hardcoded assumptions.

Now I could swap strategies:

DatePathGenerator: store files by upload date.
UserPathGenerator: store files under user directories.
Future-proof: write a SlugPathGenerator, a UUIDPathGenerator, whatever.

The shift is small on the surface. But underneath, it turns your storage system into something that can adapt as requirements evolve, without rewriting business logic.

🔐 Visibility Isn’t a Folder Name, It’s a Policy

The next trap I walked into was treating public and private as if they were just folders.

But that’s not how Laravel thinks about it.

When you save a file in Laravel:

Storage::put('photos/cat.png', $contents, 'public');

you’re not just writing to a path. You’re setting an intent: this file can be shared. The implementation decides how that’s enforced, locally it might be folder-based, on S3 it might be ACLs.

So in my system, I updated my path resolver to reflect that intent:

const targetVisibility = visibility ?? this.defaultVisibility;
return path.join(this.root, targetVisibility, filePath);

Now visibility isn’t an afterthought. It’s baked into the path, enforced by design.

That might seem small. But small design decisions like this prevent big security mistakes later.

🌊 Streams: Where Happy Path Code Goes to Die

And then came the humbling part: testing file streams.

It’s easy to write:

await storage.writeStream('file.txt', readableStream);

and call it a day. But streams don’t always behave. If you don’t handle:

slow streams,
interrupted streams,
unclosed streams,

your tests will hang. Your production code will too.

I wrote tests that simulated:

normal uploads,
network-like latency,
interrupted connections.

And every time the test failed, the design got better. I added proper end and destroy calls. I added error listeners. I added timeouts.

You don’t really "get" streams until you see one hang your test suite at 2AM.

💡 The Shift: Laravel’s Storage Model Is a Way of Thinking

When I started this project, I thought I was building a file storage system.
What I’ve realized is: I’m actually building a mental model.

Laravel’s storage isn’t just about reading and writing files, it’s about designing for:

change,
failure,
policy,
and most of all: clarity.

Week 2 wasn’t about finishing features. It was about learning to ask better questions:

What does the code assume?
What happens when those assumptions break?
How can design prevent human error, not just handle it?

The code will change. The model will stay.

🔥 What’s Next

This week was all about:

Path strategies.
Visibility policies.
Testing for real-world file behavior.

Next week?
We’ll dig into:

Signed URLs.
Slow and interrupted uploads.
Custom path generators.
Edge cases that I nearly skipped, but I’m glad I didn’t.

Because the more I work on this, the more I realize:
It was never about the files.

It was always about designing for the real world.

Transform your Articles

deamking@icloud.com (Dream king) — Thu, 10 Apr 2025 14:03:01 GMT

For a while, reading blog posts on the YeneHealth app felt like squinting through fog.

Text was jammed up against the screen edges. Fonts were tiny and inconsistent. Paragraphs melted together without spacing, hierarchy, or structure. It felt like someone had dumped raw HTML into the app and called it a day.

And that’s exactly what happened.

The app’s mobile blog reader used the flutter_html package to render HTML content, but we never styled it. No typographic rhythm, no responsive spacing, no attention to how it felt to actually read. The content was there, sure. But it looked like it didn’t want to be read.

The Web had horrible styles. Telegram had web styles and mobile just got left behind.

HTML by itself doesn’t care about how it looks. That’s CSS’s job. And in the browser, that’s easy: you set a style tag or load a stylesheet, and you’re off to the races.

But in Flutter? Rendering HTML is just a starting point. The flutter_html package maps HTML elements to Flutter widgets, and if you don’t tell it how things should look, it just… doesn’t.

So when we pulled blog content from our CMS and rendered it using flutter_html, we ended up with this:

<p> tags with no margin.
Lists (<ul>, <ol>) with weird indentation and default bullets.
<blockquote> elements that looked like normal text.
Zero spacing between headers and paragraphs.
No readable font, no consistent font sizes, no zoom.

It was readable the way a wall of raw Markdown is readable, technically possible, but practically painful.

Rebuilding the Reading Experience

I didn’t want to rebuild a full HTML layout engine. I just wanted to give the content room to breathe. So I started with the web styles that had been working well:

 body {
  font-family: Georgia, serif;
  font-size: 1.1rem;
  line-height: 1.8;
  color: #333;
  background: #fff;
  padding: 2rem 1rem;
}

 p {
  margin: 1em 0;
  line-height: 1.5;
  font-size: 1.1rem;
  margin-bottom: 1.5rem;
}

 h1, h2, h3, h4 {
  font-size: x-large;
  margin: 2.5rem 0 1.5rem 0;
  line-height: 1.25;
  color: #333;
}

 ul {
  list-style-type: circle;
  margin-top: 1.5rem;
  margin-bottom: 1.5rem;
}

 li {
  font-size: 1.1rem;
  margin-left: 2em;
  margin-bottom: 0.5em;
}

 blockquote {
  font-style: italic;
  border-left: 4px solid #ccc;
  padding-left: 1rem;
  margin: 1.5rem 0;
  background: #f9f9f9;
}

Then I translated those into Flutter styles using the flutter_html styling system:

Html(
  data: htmlContent,
  style: {
    "body": Style(
      fontFamily: 'Georgia',
      fontSize: FontSize(18.0),
      lineHeight: LineHeight.number(1.8),
      padding: HtmlPaddings.symmetric(horizontal: 16.0),
      backgroundColor: Colors.white,
      color: Colors.black87,
    ),
    "p": Style(
      fontSize: FontSize(16.0),
      margin: Margins.only(bottom: 20),
      lineHeight: LineHeight.number(1.6),
    ),
    "ul": Style(
      listStyleType: ListStyleType.DISC,
      margin: Margins.symmetric(vertical: 16),
      padding: HtmlPaddings.zero,
    ),
    "li": Style(
      fontSize: FontSize(16.0),
      margin: Margins.only(bottom: 8, left: 24),
    ),
    "blockquote": Style(
      fontStyle: FontStyle.italic,
      padding: HtmlPaddings.only(left: 16),
      border: Border(left: BorderSide(color: Colors.orange, width: 4)),
      backgroundColor: Color(0xfff9f9f9),
      margin: Margins.symmetric(vertical: 24),
    ),
    "h1": Style.fromTextStyle(headerStyle),
    "h2": Style.fromTextStyle(headerStyle),
    "h3": Style.fromTextStyle(headerStyle),
    "strong": Style(
      fontWeight: FontWeight.bold,
      color: Colors.black87,
    ),
    // Add more tag styles as needed
  },
)

Each element got just enough care to read clearly. Paragraphs had room. Lists were indented and styled. Quotes were visually distinct. And above all: it looked intentional.

Not flashy. Just thoughtful.

Why It Matters

In the end, this wasn’t about style, it was about respect.

Respect for the reader’s attention.
Respect for the writer’s voice.
Respect for the medium.

What frustrated me most about the original mobile blog experience wasn’t just that it was unreadable. It’s that it had been left that way. It didn’t feel like anyone cared enough to ask: is this comfortable to read? And when something is hard to read, it might as well not exist.

All that effort from our content team? Ghosted by a UI that didn’t care to carry it well. This wasn’t just a design oversight. It was a failure of storytelling. And that’s what finally pushed me to fix it not because I had the time, but because I was tired of watching good writing go unseen.

So I made the effort to bring typographic care to Flutter and React. I recreated line heights. I tuned font sizes. I gave margins the room they deserved. I stopped treating HTML as data and started treating it as literature. It still isn’t perfect. I’m still tweaking line spacing and wondering if 1.5 is too loose or just right. But that’s the work. You keep adjusting the margins until the story breathes again.

The Deeper Lesson

Interfaces are not neutral.
The way you present content changes the way it’s perceived.

This wasn’t just about making it “pretty.” It was about making it possible to engage. Because no matter how good your ideas are, if your reader has to pinch, squint, and scroll sideways to reach them… they won’t.

And honestly? Neither would I.

Local File Storage with TypeScript

deamking@icloud.com (Dream king) — Tue, 08 Apr 2025 14:03:01 GMT

There’s this silent moment that always comes when you’re abstracting infrastructure, storage, queues, databases. It’s the moment right after you get the first thing working, and you ask yourself: What’s this really going to grow into?

That moment hit me like a freight train after I wrote the first few lines of my TypeScript version of Laravel’s file storage system. I had the interface, a LocalStorageDriver, and a Storage registry in place. You could .put() and .get() files. It worked. But I realized I wasn’t building this for now, I was building it for the next hundred features. And that meant it couldn’t just work; it had to be built to grow.

And that’s where metadata, testing, and error handling came in.

Why Metadata Isn’t Optional

The past version of me didn’t think about file metadata. If a file was there and I could read it, that was good enough. But that version of me had never tried to build a media library, generate signed URLs, or organize files by type.

Metadata isn’t just nice-to-have, it’s the foundation of a real file management system. You need to know what a file is, not just whether it exists.

So I designed a shape:

interface FileMetadata {
  path: string;
  size: number;
  mimeType: string;
  visibility: 'public' | 'private';
  lastModified: Date;
}

This became the backbone of how I understood files. And it forced my local driver to become smarter. I pulled in fs-extra for filesystem access, and mime-types to infer MIME type based on file extension. Then I wrote a getMetadata() method that pulled it all together.

What changed for me here was realizing that this structure wasn’t just a utility. It was a contract, one that all future drivers (S3, GCS, Azure) would have to honor.

Testing Like the System Depends on It (Because It Does)

Here’s the truth: I don’t write tests because I love writing tests. I write tests because Future Me is a chaotic gremlin who will absolutely break things.

So I wrote a suite of integration tests for the local driver:

Can it write and read files?
Does it report the right metadata?
Does exists() behave sensibly?
What happens when the file doesn’t exist?

I used Vitest, but any modern framework will do. What mattered wasn’t the tool, it was the intention:

If this was the only thing I could read about the system in 6 months, would I understand how it’s supposed to behave?

That’s my bar now.

Error Handling That Isn’t an Afterthought

The filesystem is a messy place. Files vanish. Paths are wrong. Disks fill up. If you pretend that won’t happen, your app will crash the first time reality says otherwise.

So I wrapped my reads in try/catch, and made sure errors came with meaningful messages:

try {
  const data = await fs.readFile(fullPath);
} catch (err: any) {
  if (err.code === 'ENOENT') {
    throw new Error(`File not found: ${path}`);
  }
  throw err;
}

No vague "Something went wrong." Give me context. And while we’re at it, I added optional logging, so I could debug without digging into stack traces.

The Takeaway: Make the Boring Parts Boring

I don’t want file storage to be exciting. If I’m thinking about it, something probably went wrong. So my goal is to make this whole system predictable.

Metadata lets me make smart decisions about files
Testing protects me from my own future recklessness
Error handling ensures I hear the crash before it becomes a crater

When you’re building abstractions, the goal isn’t cleverness. It’s trust. I want to trust that .put() will work the same on local or S3. I want to trust that getMetadata() gives me the same shape every time.

That trust starts with being just a little obsessive right now.

If you're building something similar, my advice is: don’t skip this step. Make the boring parts boring. You’ll thank yourself later.

Next up? Cloud drivers. Let’s make this thing fly.

Respect for Teachers

deamking@icloud.com (Dream king) — Sun, 30 Mar 2025 14:03:01 GMT

Today, as I scrolled through LinkedIn, I came across a video that truly moved me. A teacher was sharing a heartfelt tribute to his hero,his wife. In the video, she stood holding their child in one arm while skillfully managing a video camera with the other, capturing her husband's online course lectures. It was a beautiful, selfless act, a reminder of the silent sacrifices made behind the scenes. His public acknowledgment of her support was touching, and it made me think about the dedication of teachers in general, especially in the digital age.

The way education is evolving, with teachers adapting to online courses and new modes of learning, is commendable. More than ever, they are required to be content creators, communicators, and mentors in ways previous generations never imagined. This shift should be encouraged and supported. But as I reflected on the honor this teacher gave to his wife, I was struck by another post,a stark contrast to this moment of gratitude and respect.

A student had openly insulted his teacher, boasting that he could get the entire course material from an AI model. What troubled me even more was not just the comment itself, but the overwhelming agreement from others in the replies. The casual dismissal of teachers, the idea that they are obsolete in a world of abundant information, was both disturbing and disappointing.

Respect is Not Optional

There was a time when respect for teachers was a given. You could disagree with their methods, you could challenge their perspectives, but the fundamental principle remained,teachers deserved respect. Not because they were flawless, but because they carried the responsibility of shaping generations. Respecting elders, mentors, and those who dedicate their lives to education is not something they should have to earn. It is a principle.

In many countries, including mine, teachers are not paid well. The profession is not seen as a lucrative or prestigious career path, and that reality deters many brilliant minds from pursuing it. Teaching, once considered one of the most honorable professions, is now often met with indifference or even disdain. If only we treated teachers as champions,if only we recognized their immense contributions and rewarded them accordingly,we could cultivate a generation rooted in strength, wisdom, and wealth, not just in material terms but in intellectual and moral prosperity.

The Lessons That Stay With Us

Thinking back to my own years as a student, I don’t just remember classroom discussions or lecture notes. I remember the teachers who stood out, the ones who disciplined me, the ones who praised me, the ones who argued with me, and the ones who encouraged me. The ones who challenged my thinking and, in doing so, shaped who I am today.

A teacher may believe their primary role is to deliver subject material, but their impact goes far beyond that. As students, we absorb everything, from the way they speak to how they carry themselves. A single word from a teacher can stay with a student for life. A moment of kindness, a lesson in patience, a display of ambition, or even a firm reprimand,all of these contribute to shaping identities. True teachers don’t just deliver content; they ignite curiosity, challenge assumptions, and inspire growth. They don’t dictate destinies, but they open doors to possibilities.

A Generation at Risk

What happens when an entire generation grows up without these lessons? When they fail to understand the value of history, culture, and principles? When learning becomes transactional rather than transformational? When experience is dismissed as irrelevant in the face of instant information?

The thought is unsettling. Knowledge without wisdom is dangerous. A world that does not value teachers is a world that does not value learning in its truest sense.

Technology is an incredible tool, but it cannot replace mentorship. AI can provide answers, but it cannot challenge perspectives. The future must not be one where we trade the depth of human teaching for the convenience of machine-generated knowledge.

Teachers matter. Their work matters. And our respect for them should not waver, no matter how much the world changes.

The Hidden Cost of Speedy Fixes

deamking@icloud.com (Dream king) — Tue, 18 Mar 2025 07:51:04 GMT

Rabbit hole of problems

For a long time, I took pride in solving problems fast. A bug popped up? Fixed in minutes. A deployment issue? Quick patch. A failing test? Just tweak the conditions. It felt good to move quickly, to be the person who could handle things under pressure. But then my boss pointed something out:

"You're solving the same problems over and over. Why do they keep coming back?"

I hadn’t noticed it before, but he was right. The fixes weren’t really fixes, they were patches. I was treating symptoms, not causes. And worse, I was making future work harder for myself and my team. That’s when I started looking into why quick fixes are so tempting and so dangerous.

The Quick Fix Mindset: Why We Do It

This mindset, prioritizing immediate solutions over sustainable ones, doesn’t come from laziness. It’s usually the result of external pressures and ingrained habits. Here are some key factors that drive it:

1. Pressure to Deliver Fast

Deadlines are tight, production issues need immediate attention, and there's an unspoken expectation that developers should always be shipping. Under this pressure, investing time in a well-thought-out solution feels like a luxury.

2. Technical Debt Becomes Normalized

When teams regularly push out quick fixes, technical debt piles up. But because it accumulates slowly, it becomes the default way of working. It’s like living with a messy desk, you stop noticing how much it slows you down.

3. Lack of Long-Term Thinking

If the goal is just to make it through the next sprint or the next release, long-term sustainability gets ignored. The future-you (or worse, your teammates) will have to deal with the consequences.

4. Resource Constraints

Not enough time, not enough people, not enough budget, these constraints force teams to take the easiest route to getting things done. But quick fixes often cost more in the long run.

5. Reinforcement of Bad Habits

If quick fixes are rewarded, if they lead to praise, promotions, or just surviving another deadline, developers keep using them. But success in firefighting doesn’t mean the fire isn’t still spreading.

The Hidden Costs of Quick Fixes

While quick fixes might feel like wins in the moment, they come with serious downsides:

1. Accumulating Technical Debt

Shortcuts add up. That function you copied and pasted instead of refactoring? Now there are five versions of it across the codebase. That hardcoded config? It’s breaking in production because no one knew to change it. Every quick fix compounds the complexity of future work.

2. Decreased Product Quality

Patching instead of solving leads to fragile systems. One fix breaks another part of the app. Edge cases go unhandled. The user experience degrades. Eventually, the product becomes unreliable, slow, and frustrating.

3. Developer Burnout

Constantly fixing the same types of issues is exhausting. Developers feel like they’re always putting out fires instead of building something meaningful. This can lead to frustration, disengagement, and ultimately burnout.

4. Missed Opportunities for Real Innovation

If all the energy goes into maintaining a broken system, there’s little time left for improving it. The team stays stuck in a cycle of reactivity rather than proactively creating better solutions.

Breaking the Cycle: Moving Beyond Quick Fixes

Shifting away from a quick-fix mindset takes effort, but it’s worth it. Here are some strategies that have helped me (and my team) focus on long-term sustainability:

1. Slow Down to Speed Up

It feels counterintuitive, but taking the time to do things right the first time saves more time later. Instead of immediately jumping to a quick fix, step back and ask: What’s actually causing this issue?

2. Refactor Regularly

Schedule time for refactoring and technical debt cleanup. It’s like servicing a car, skip it too long, and things start breaking down.

3. Make Technical Debt Visible

Keep track of where debt is accumulating. Add tickets for refactoring. Document workarounds so they don’t become permanent hacks.

4. Push for Sustainable Practices

Advocate for better testing, code reviews, and automation. Make the case to stakeholders that solid engineering saves money and time in the long run.

5. Shift the Culture

Encourage a team mindset where quality is valued over speed. Recognize and reward well-thought-out solutions, not just quick turnarounds.

The Takeaway

Quick fixes can feel like victories, but they often create more problems than they solve. I learned this the hard way, by repeating the same fixes over and over until someone pointed it out. The shift away from patching toward sustainable problem-solving isn’t easy, but it makes for a stronger team, a healthier codebase, and a better product.

Next time you’re about to reach for the fastest fix, ask yourself: Is this really solving the problem? Or just delaying it? The answer might change the way you code.

Our Voices, Our Stories, Our Future

deamking@icloud.com (Dream king) — Sun, 16 Mar 2025 14:01:28 GMT

Our Voices, Our Stories, Our Future

Growing up, technology wasn’t just about gadgets for me, it was about curiosity and inspiration. Even with limited access to cutting-edge tech in Ethiopia, I was fascinated by how the world was changing. But more than what I saw, it was what I heard that shaped my perspective.

Two shows, Tech and Tunes Radio Show and TechTalk with Solomon, were more than just programs. They made complex topics feel personal, relevant, and exciting. They didn’t just report on technology; they sparked ambition and built a community of tech enthusiasts.

Looking back, I see how these shows laid the foundation for a generation of innovators. Many of Ethiopia’s young developers, engineers, and entrepreneurs found inspiration through voices like these, voices that told our stories, shared our challenges, and celebrated our progress.

Now, podcasts are carrying that legacy forward, giving this generation a platform to connect, learn, and create the future. Just as those early shows shaped my dreams in technology, today’s podcasts are doing the same for countless young Ethiopians.

Building Community Through Podcasts

Life in Ethiopia comes with challenges, whether it’s navigating school, work, or personal growth. But podcasts remind us that we’re not alone. They create spaces where we can share struggles, celebrate wins, and uplift each other.

Hearing someone talk about the same problems you’ve faced is powerful. It builds a sense of connection and shows that, together, we can find solutions, support one another, and create real change.

The Power of Ethiopian Role Models

Podcasts go beyond entertainment, they inspire and empower. They connect us with remarkable individuals from all walks of life: entrepreneurs, artists, scientists, and activists. Through these conversations, we learn about perseverance, passion, and the incredible potential within us.

These voices make success feel attainable. They remind us that Ethiopian innovation isn’t just a dream, it’s happening right now.

A Bright Future for Podcasting

As the digital landscape evolves, Ethiopian podcasts are becoming a powerful force for change. Their accessibility and personal connection make them ideal for empowering young people, fostering innovation, and preserving our rich cultural heritage.

Yet, many of our innovators remain unseen. Our sense of community is still too small. We don’t always recognize the dreamers and builders shaping Ethiopia’s future. But podcasts are changing that. They bring us closer, amplify voices that deserve to be heard, and remind us that greatness exists in each of us.

Check These Out, You Won’t Regret It!

If you haven’t explored Ethiopian podcasts yet, now is the time! Here are some incredible shows that will make you think, laugh, and inspire you to take action:

🎙️ Dejaf Podcast - Unfiltered conversations on real life issues.

🎙️ Gugut Podcast - Fun and deep discussions with fresh voices.

🎙️ Devtopia - Tech, innovation, and how the youth are shaping the future.

🎙️ Meri Podcast - Eye-opening talks on social issues, personal growth, and empowerment.

Podcasts aren’t just background noise, they’re like sitting in on the most interesting discussions you wish you could be part of. The question is, are we ready to listen?

The Trap of Stability

deamking@icloud.com (Dream king) — Mon, 03 Mar 2025 14:03:01 GMT

When you were younger, you weren’t afraid to take risks. You built things just to see if they would work, spoke up without overthinking, and threw yourself into challenges because failure didn’t seem like a big deal.

But over time, something shifted. You earned a title, built a reputation, and found a place in the world. Stability became the goal. And with it came an unspoken fear what if taking a risk now means losing everything you’ve built?

How Status Makes Us Play It Safe

In the beginning, the goal was to get better, to grow, to prove yourself. But at a certain point, the focus shifts from growth to preservation. You start making safer choices, avoiding anything that could shake the foundation you’ve built.

You hesitate before taking on ambitious projects because failure would be too public.
You stop learning new skills because you don’t want to be bad at something again.
You say less in meetings because you’d rather protect your reputation than risk being wrong.

Ironically, the very thing that once drove your learning, experimenting, improving is now the thing you avoid. You don’t want to start over. You don’t want to look foolish. So, you trade curiosity for certainty, and in doing so, you stop moving forward.

The Slow Fade Into Stagnation

This mindset doesn’t hit all at once. It happens gradually, in small, justifiable steps.

At first, you avoid unnecessary risks. That makes sense. But soon, you start avoiding necessary risks, too. The risks that could push you further, expand your perspective, or help you grow. Before you know it, you’re not evolving, you’re just maintaining.

And that’s the real danger: not failure, but stagnation.

Breaking the Cycle

So what’s the way out? It’s not about recklessness. It’s about remembering that growth doesn’t stop just because you’ve “made it.”

Stay a beginner in something. Whether it’s a new skill, a new industry, or just a new way of thinking, keep yourself uncomfortable.
Redefine success. If success only means maintaining what you have, you’ll always be stuck. Instead, let it mean learning, experimenting, and evolving.
Take small risks. You don’t have to bet everything, but you do have to bet something. Speak up. Try something new. Do the thing that makes you nervous.

At the end of the day, the question isn’t whether you’ll fail. The question is: will you let the fear of failure stop you from growing?

Because the most dangerous thing isn’t losing what you have, it’s never becoming more than what you are now.

A Deep Dive into os/exec Package

deamking@icloud.com (Dream king) — Sat, 11 Jan 2025 14:01:28 GMT

At the heart of this city is the kernel, the all-powerful manager that directs traffic, ensures smooth communication, and enforces the rules. Just as a city's mayor coordinates activities through various departments, the kernel executes commands that keep your computer running efficiently. Every time you launch an application, run a script, or perform a system task, the kernel is hard at work, processing your requests and executing commands to get the job done.

The os/exec package in Go is your toolkit for interacting with the kernel, allowing you to run external commands from within your Go programs. It's like having a direct line to the city's command center, giving you the power to execute tasks with precision and efficiency.

Customizing Command Execution

When it comes to interacting with the operating system in Go, the standard library provides a straightforward way to execute external processes. The os/exec package is the key to unlocking this functionality. In this blog post, we'll explore how to use it to call external commands and tools.

Using the Cmd Struct and Run Method

The most straightforward way to execute an external process is by creating a Cmd struct and calling its Run method. This approach is perfect for calling OS utilities and tools, ensuring that your program doesn't hang indefinitely waiting for the process to complete.

func main() {
  prc := exec.Command("ls", "-l")
  err := prc.Run()
  if err != nil {
    panic(err) 
  }
}

The Run method executes the command and waits until it completes. If the command exits with an error, the err value will not be nil, allowing you to handle errors accordingly.

If you run this command and nothing seems to happen, don't worry, the command has been executed. In subsequent sections, we will look at how to capture the output of execution as well as how to manage user input from commands.

In case a command is not found in the OS binary registry, you can locate it using exec.LookPath("ls"), which helps ensure that your system functions as expected.

Handling Input/Output Streams

The output from executed commands is crucial and can be bound to any writer, be it Standard Output, a file, or any other writer implementing the io.Writer interface.

package main

import (
 "bytes"
 "fmt"
 "os/exec"
)

func main() {
 prc := exec.Command("ls", "-a")
 out := bytes.NewBuffer([]byte{})
 prc.Stdout = out
 err := prc.Run()
 if err != nil {
   fmt.Println(err)
 }
 if prc.ProcessState.Success() {
   fmt.Println("Process run successfully with output:")
   fmt.Println(out.String())
 }
}

In this code snippet, we create a new exec.Command object representing the ls command process. We then use a bytes.Buffer object to capture the output of the command. The prc.Stdout field is set to out, meaning that any output from the command will be written there.

After running the command using prc.Run(), we check for errors. If there are none, we verify if the command ran successfully using prc.ProcessState.Success(), printing both a success message and the output.

Combined Output

You can also use a command's CombinedOutput method, which assigns both standard output and standard error to a buffer.

func main() {
    cmd := exec.Command("ls", "-a")
    out, err := cmd.CombinedOutput()
    if err != nil {
        log.Fatalf("cmd.Run() failed with %s\n", err)
    }
    fmt.Printf("combined out:\n%s\n", string(out))
}

This method simplifies capturing all output types from a command into one variable.

Interacting with External Bash Shells

The following program demonstrates how to interact with an external Bash shell using command execution and buffered I/O:

package main

import ( 
  "bufio"
  "fmt" 
  "os" 
  "log"
  "os/exec"
  "strings" 
  "errors"
) 

type Shell struct{} 

func (Shell) CmdFromString(p []string) (cmd *exec.Cmd, err error) {
 if len(p) == 0 { return nil, errors.New("endline clicked") }
 if len(p) == 1 { return exec.Command(p[0]), nil }
 return exec.Command(p[0], p[1:]...), nil 
} 

func main() {
 input := bufio.NewScanner(os.Stdin)
 shell := Shell{}
 for input.Scan() {
  cmd, err := shell.CmdFromString(strings.Fields(input.Text()))
  if err != nil { continue }
  
  out, err := cmd.CombinedOutput()
  if err != nil { log.Panic(err) }
  fmt.Printf("Output \n%s", out)
 }
}

This program allows users to enter commands interactively; as they type commands, it relays them to Bash and captures their outputs.

Error Handling and Exit Status

The os/exec package includes two primary error types: exec.Error and exec.ExitError. It's essential to check for both types of errors and handle them accordingly:

Handling exec.Error: This error occurs when a command cannot be executed due to issues like being not found or not executable.
Handling exec.ExitError: This error arises when a command executes but returns a non-zero exit status indicating failure.

By understanding these concepts within Go's os/exec package, you can effectively manage external command execution in your applications. Happy coding!

Error Handling Demystified

deamking@icloud.com (Dream king) — Sat, 26 Oct 2024 03:06:04 GMT

In an era where user expectations are high, implementing proper error handling mechanisms is not just a best practice; it’s a necessity. Just as we strive for balanced nutrition to support our well-being, prioritizing error management is crucial for the health of our applications.

The approach to error handling varies significantly between testing environments and production settings. This distinction is crucial for ensuring both the reliability of applications and the overall user experience.

During the testing phase, error handling serves as a critical tool for developers to identify and rectify issues before deployment. In this controlled environment, developers can simulate various scenarios, allowing them to observe how their application responds to unexpected inputs or failures. The primary aim here is to uncover bugs and ensure that all potential errors are addressed. Comprehensive logging and detailed error messages are often employed to facilitate debugging, providing developers with insights that can lead to improvements in the codebase.

Error handling in a production environment focuses on maintaining application stability and user satisfaction. Once an application is live, it is essential that it operates smoothly for end-users, even when unforeseen errors occur. In this context, error handling mechanisms must be robust yet discreet. This often involves implementing user-friendly error messages that guide users without exposing them to technical jargon. Additionally, logging errors for later analysis becomes paramount, enabling developers to monitor application health and address issues proactively.

By implementing a variety of error handling approaches, you can proactively address potential issues, enhance application reliability, and maintain user trust. Below are some widely recognized error handling techniques employed across different programming languages.

Error Handling Approaches
Error Handling Approach	Best Practiced Language	Description
Try-Catch Blocks	Java, Python, C#, JavaScript	Allows developers to wrap potentially error-prone code in a `try` block and handle exceptions in a `catch` block.
Return Values for Error Indication	C, Go	Functions return specific values to indicate success or failure, requiring the caller to check these values.
Custom Exception Classes	Java, Python	Developers create their own exception classes to provide more context about errors that occur within applications.
Logging and Monitoring	Python, JavaScript, Ruby	Implementing logging mechanisms to track errors and monitor application health in real-time.
Type System Approaches	Rust, Haskell, Elm	Utilizing the type system to encode possible failures and ensure proper handling of error states through constructs like `Option` or `Result`.
Defensive Programming	C++, Java	Anticipating potential errors and implementing safeguards within the code to handle unexpected situations gracefully.
Graceful Degradation	JavaScript	Ensuring that applications can continue to function in a limited capacity even when errors occur.
Fail-Fast Principle	Go, Java	Designing systems to fail immediately upon encountering an error, preventing further propagation of issues.
Asynchronous Error Handling	JavaScript	Managing errors that occur in asynchronous operations effectively without blocking the main execution thread.
Checked Exceptions	Java	Enforcing compile-time checks for certain exceptions that must be either caught or declared in the method signature.

Effective strategies for managing errors in software applications.

1. Error handling, "try...catch"

In languages that utilize try-catch blocks, errors are treated as side effects of execution rather than as values, emphasizing the need for recovery and separation of error handling from normal program logic. This approach involves wrap potentially error-prone code in a try block and handle exceptions in a catch block.

try {
  // code...
} catch (err) {
  // error handling
}

To create robust try...catch error handling, one should employ specific exception types that accurately reflect the nature of errors within your application. This enables targeted debugging and error resolution. Additionally, provide clear and informative error messages that convey the root cause of the issue, aiding in swift problem identification and resolution.

Overreliance on try-catch blocks can be a dangerous habit. By catching generic exceptions without specific handling, developers can easily ignore underlying issues, leading to a false sense of security. It's like using a blanket solution to a complex problem. While it might temporarily silence the error, it doesn't address the root cause. This can result in delayed bug detection, increased maintenance costs, and potential system failures.

2. Return Values for Error Indication

Functions can signal errors by returning specific values, often distinct from the regular return type. In Golang functions can return multiple values, one of which can be an error value. The error type is commonly used for this purpose. Returning specific values to indicate error conditions can lead to more explicit and controlled error handling. By carefully examining the return value, developers can make informed decisions about how to proceed.

func OpenFile(filename string) (*os.File, error) {
    file, err := os.Open(filename)
    if err != nil {
        return nil, err
    }
    return file, nil
}

This approach feels right. That's because errors are usually of immediate interest; the error is either actionable (and must be handled) or there's some important context that needs to be captured (local variables). Errors as values result in both compact and readable code. Although having to explicitly handle errors every time can sometimes be a bit challenging.

New Year at Yenehealth

deamking@icloud.com (Dream king) — Mon, 09 Sep 2024 07:51:04 GMT

Enkutatash, at yenehealth

Enkutatash, the Ethiopian New Year, was more than just a celebration, it was a time for family, thanks, and looking back. My mother, glowing with excitement, was busy spreading kettema around the house, making it smell comforting and familiar.

Even though it was raining heavily outside, which didn’t match the new year's promise of spring, the festive mood was strong. At work, everyone was buzzing with energy. People were dressed up, their faces full of joy. I felt a bit awkward in my casual clothes, but my colleagues were too wrapped up in the celebration to care.

Lunch was a treat. The food from a popular restaurant was delicious, but the real highlight was sharing it with the team. It was the first time we all ate together, and it was nice to see my colleagues enjoy a tradition I knew very well.

The day was packed with coffee, dancing, and laughter. We even invited our neighbors to join in. As the day ended, we gave Beza a pair of earbuds for finding the last googly eyes.

The day showed me how important workplace culture is. In a world focused on speed and technology, it can be tough to build a sense of community. But at Yenehealth, I saw how a positive, supportive culture makes a difference. It’s a place where people feel valued, inspired, and connected.

Fun and Effective Commit Messages

deamking@icloud.com (Dream king) — Mon, 26 Aug 2024 07:51:04 GMT

Conventional Commits is a set of rules. These rules help you write clear and consistent commit messages. Think of it like a secret code. It helps you and your teammates talk better about code changes. Here are some of the most common types of commit messages you'll encounter:

New Feature!

When you add something exciting to your application, like a shiny new button or a cool new page, you use feat. This tells everyone, “Hey, check out this awesome new feature!”

Example:

feat: add a dark mode toggle

Squash Bugs!

If you find and fix a pesky bug that’s been causing trouble, you’ll want to use fix. This shows that you’ve solved a problem, making the app better for everyone.

Example:

fix: correct typo in the login error message

The Little Things

Sometimes, you need to make changes that don’t change how the app works. This could be updating a library or cleaning up the code. You call these chores. They keep everything tidy without changing any features.

Example:

chore: update README with installation instructions

Document the Journey

When you make changes to the documentation, like fixing a typo or adding new instructions, you’ll use docs. This is important because it helps everyone understand how to use the app.

Example:

docs: update API documentation for new endpoints

Make It Pretty

If you change how the code looks without changing what it does, use style. This includes fixing indentation or removing extra spaces. This keeps the code looking sharp!

Example:

style: format code to follow style guide

Improve the Code

When you change the code to make it better, but you don’t add features or fix bugs, you use refactor. This is all about improving the structure of the code.

Example:

refactor: simplify user authentication logic

Speed Things Up

If you make changes that make the app faster or more efficient, you’ll want to use perf. Everyone loves a speedy app!

Example:

perf: optimize image loading for faster page rendering

Ensure Quality

When you add tests to check that your code works or fix existing tests, you use test. This helps keep the code reliable.

Example:

test: add unit tests for user login functionality

The Foundation

You mark changes that affect the build system or external dependencies with build. This includes things like updating a package. This ensures your project runs efficiently.

Example:

build: upgrade to latest version of Node.js

Continuous Integration

If you make changes related to continuous integration configurations, you’ll use ci. This helps automate the testing and deployment process.

Example:

ci: update GitHub Actions workflow for deployment

Going Back in Time

When you need to undo a previous change, you use revert. It’s like hitting the rewind button!

Example:

revert: remove feature that caused crashes

The Why?

Using these conventions helps keep your commit history clear and organized. It’s like having a well-labeled filing cabinet for all your code changes. When everyone follows the same rules, understanding the project becomes easier. This is especially helpful when you look back at your work months later.

Flags 2.0 Making Use of Runner

deamking@icloud.com (Dream king) — Fri, 01 Mar 2024 14:03:01 GMT

Let's walk through a simple command-line tool that greets a user by name. We'll enhance this tool by incorporating the flag package to personalize the greeting based on user input. Here we will be looking at the NewFlagSet method in the flags package

type Runner interface {
    Init([]string) error
    Run() error
    Name() string
}

type GreetCommand struct {
    fs *flag.FlagSet

    name string
}

func NewGreetCommand() *GreetCommand {
    gc := &GreetCommand{
        fs: flag.NewFlagSet("greet", flag.ContinueOnError),
    }

    gc.fs.StringVar(&gc.name, "name", "World", "name of the person to be greeted") // -name
    gc.fs.StringVar(&gc.name, "n", "World", "name of the person to be greeted")    // -n
    return gc
}

func (g *GreetCommand) Name() string {
    return g.fs.Name()
}

func (g *GreetCommand) Init(args []string) error {
    return g.fs.Parse(args)
}

func (g *GreetCommand) Run() error {
    fmt.Println("Hello", g.name, "!")
    return nil
}

func root(args []string) error {
    if len(args) < 1 {
        return errors.New("you must pass a sub-command")
    }

    cmds := []Runner{
        NewGreetCommand(),
    }

    subcommand := os.Args[1]

    for _, cmd := range cmds {
        if cmd.Name() == subcommand {
            cmd.Init(os.Args[2:]) // parse the flags
            return cmd.Run()
        }
    }

    return fmt.Errorf("unknown subcommand: %s", subcommand)
}

func main() {
    if err := root(os.Args[1:]); err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
}

Running the Program with Flags

Let's see how this code works in action. To greet someone named dre we can run:

go run main.go greet -name dre

This will output:

Hello dre !

The -name flag allows us to override the default name ("World") and personalize the greeting.

Expanding on the Runner Interface for Composable Commands

Let's delve deeper into its purpose and how it facilitates composability for various command types.

The Power of Interfaces: Defining Common Behavior

The Runner interface defines a contract for different sub-commands within our program. It outlines three essential methods:

Init([]string) error: This method handles initialization tasks for the command, typically involving parsing flags using the flag package.
Run() error: This method executes the core functionality of the command.
Name() string: This method returns the unique name of the command, used for identification during sub-command selection.

By defining these methods in an interface, we create a blueprint for any sub-command within our application. Any struct implementing this interface automatically becomes a valid sub-command.

Composability in Action: Adding a New Command

Let's illustrate this concept by introducing a new command: stats. This command might retrieve and display program usage statistics. Here's a simplified example of the stats command:

type StatsCommand struct {
  // ... relevant fields for stats command
}

func (s *StatsCommand) Init([]string) error {
  // Handle any initialization specific to stats command (e.g., no flags)
  return nil
}

func (s *StatsCommand) Run() error {
  // Implement logic to retrieve and display stats
  fmt.Println("Program Usage Statistics...")
  // ...
  return nil
}

func (s *StatsCommand) Name() string {
  return "stats"
}

This StatsCommand struct implements the Runner interface, making it a valid sub-command. We can now add it to the list of available commands in the root function:

func root(args []string) error {
  // ... existing code
  
  cmds := []Runner{
      NewGreetCommand(),
      &StatsCommand{}, // Add StatsCommand to the list
  }
  
  // ... remaining code
}

With this modification, users can now execute the stats command alongside the existing greet command.

Benefits of Composable Commands

The Runner interface promotes code reusability and simplifies adding new functionalities. By adhering to this interface, developers can create various sub-commands with unique purposes while maintaining a consistent structure within the program. This modular approach makes the codebase cleaner and easier to maintain as the number of commands grows.

Further Enhancements

The Runner interface can be further extended to include additional methods specific to command management, such as providing help messages or handling errors specific to each command type. Explore these possibilities to create a more robust and flexible command-line application framework in Go.

Flags in Go

deamking@icloud.com (Dream king) — Thu, 29 Feb 2024 14:03:01 GMT

Introduction

In the realm of Go applications, the flag package reigns supreme when it comes to wielding command-line arguments. It empowers you to gracefully accept user-specified instructions, tailoring your program's behavior on the fly.

Key Functionalities:

Defining Flags: Craft flags using functions like String, Int, Bool, Var and more. Each flag carries a name (short and long versions), a default value, and a usage description.

var name string
var verbose bool

func init() {
  flag.StringVar(&name, "name", "", "Your name (default: empty)")
  flag.BoolVar(&verbose, "verbose", false, "Enable verbose output")
}

Parsing Arguments: When your program launches, unleash the flag.Parse() function. It meticulously dissects the command-line arguments, matching them to the meticulously defined flags and assigning the extracted values to their designated variables.

flag.Parse()

Accessing Values: Once parsing is complete, the flag variables hold the user-provided values, ready to be employed within your program's logic.

fmt.Println("Hello,", name)
if verbose {
 fmt.Println("Verbose mode enabled!")
}

Making Connections Flexible with Go's flag Package: A Real-World Example

The flag package empowers you to create command-line programs with dynamic configurations through user-defined flags. We'll delve into how this code leverages flags to control retry attempts and data for an HTTP request.

type ArrayValue []string

func (s *ArrayValue) String() string {
    return fmt.Sprintf("%v", *s)
}

func (a *ArrayValue) Set(s string) error {
    *a = strings.Split(s, ",")
    return nil
}

func main() {
    retry := flag.Int("retry", -1, "Defines the max retry count")

    var logPrefix string
    flag.StringVar(&logPrefix, "prefix", "", "Logging prefix")

    var arr ArrayValue
    flag.Var(&arr, "array", "Input array to iterate through. ")

    flag.Parse() // required for assigning values

    logger := log.New(os.Stdout, logPrefix, log.Ldate)
    retryCount := 0
    for retryCount < *retry {
        logger.Println("*Retrying connection")
        post()
        logger.Printf("Sending array %v\n", arr)
        retryCount++
    }
}

func makePostRequest(data []byte) ([]byte, error) {
    url := "http://localhost:8080" // Target URL
    req, err := http.NewRequest("POST", url, bytes.NewBuffer(data))
    if err != nil {
        return nil, err
    }
  
    req.Header.Set("Content-Type", "application/json")
    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }
    return body, nil
}

func post() {
    data := []byte(`{"message": "Hello from Go!"}`)
    responseBody, err := makePostRequest(data)
    if err != nil {
        fmt.Println("Error:", err)
    } else {
        fmt.Println("Response:", string(responseBody))
    }
}

Running the Program with Flags

Let's see how this code works in action. To retry this request twice we give an integer of 2 and prefix the logs we named "dre," we can run:

go run main.go -retry 2 -prefix dre

This will output:

dre2024/03/02 *Retrying connection
Response: {"message": "Hello from Go!"}
dre2024/03/02 Sending array []
dre2024/03/02 *Retrying connection
Response: {"message": "Hello from Go!"}
dre2024/03/02 Sending array []

Let's break down the code's flow:

Flag Parsing: The program starts by parsing the command-line arguments using flag.Parse(). This allows users to control retry count, logging prefix, and the input array via flags.
Logging Setup: Based on the -prefix flag, a logger object is created using the log package. This ensures informative logs with user-defined prefixes.
Retry Loop: The program enters a loop that continues until the maximum retry count (retry) is reached. Inside the loop:
Making the Request: The post function constructs a POST request to a designated URL (http://localhost:8080). It utilizes a helper function, makePostRequest, which is responsible for building and executing the request.

This example explores a practical example of using the flag package in Go. The flag package empowers you to create command-line programs with dynamic configurations through user-defined flags. We'll delve into how this code leverages flags to control retry attempts and data for an HTTP request.

Understanding the Code

The code defines a program that attempts to send data via a POST request. However, the magic lies in its configurability through flags.

The ArrayValue struct tackles a specific challenge: handling comma-separated lists of strings from the -array flag. Standard flag functions don't handle this natively.

The Set method parses the user's input, splitting the comma-separated string into individual values stored within the ArrayValue slice. The String method provides a user-friendly way to represent the array content when needed (e.g., during logging).

The flag.Var function accepts a value with the following interface, ArrayValue implements this inteface

type Value interface {
    String() string
    Set(string) error
}

retry: This flag, defined with flag.Int, allows users to specify the maximum number of retry attempts before giving up.
prefix: Defined with flag.StringVar, this flag lets users set a prefix for log messages, adding context to their output.
array: This custom flag utilizes flag.Var and a ArrayValue struct to accept a comma-separated list of strings as input.

The flag.Parse() function is crucial, as it interprets command-line arguments and assigns them to the corresponding flags.

Stop Fighting Go and Started Listening

deamking@icloud.com (Dream king) — Thu, 02 Mar 2023 14:03:01 GMT

For a long time, I wrote Go the way I wrote other languages: by instinct, by habit, and, honestly, by muscle memory from years of reaching for dependencies to solve my problems.

It wasn’t that I didn’t trust Go’s standard library. I just didn’t think about it. Need logging? Grab a package. Need an HTTP client? Surely, there’s a better one than the built-in net/http. I treated the standard library like a set of training wheels, something to outgrow once I needed “real” functionality.

But Go had other plans for me.

The Moment It Clicked

It started with a simple problem: logging.

I needed to log messages to a file. Easy enough. I wrote a function like this:

func logMessage(message string, file *os.File) {
    timestamp := time.Now().Format("2006-01-02 15:04:05")
    logLine := fmt.Sprintf("%s %s\n", timestamp, message)
    file.Write([]byte(logLine))
}

It worked. But something about it felt… brittle. What if I wanted to log to the console instead? Or store logs in memory for testing? Or send them to a remote service? Each new destination meant rewriting this function.

That’s when I noticed something about os.File. It implemented io.Writer. And io.Writer wasn’t just for files, it was for anything that could accept a stream of bytes.

So I rewrote the function:

func logMessage(message string, writer io.Writer) {
    timestamp := time.Now().Format("2006-01-02 15:04:05")
    logLine := fmt.Sprintf("%s %s\n", timestamp, message)
    writer.Write([]byte(logLine))
}

And just like that, my little function transformed.

Now, it didn’t care where the logs went. It could write to a file, sure, but also to os.Stdout, a bytes.Buffer, or even a network connection. I hadn’t added complexity. I had removed assumptions and in doing so, I had made my code far more powerful.

Go Was Trying to Teach Me Something

I had spent so much time trying to make Go work the way I wanted that I had ignored the patterns it was trying to show me.

Interfaces like io.Writer weren’t just there for convenience; they were a way of thinking. A way to decouple code, to make it composable, to let it flow.

I started seeing the same lesson everywhere:

The http.Handler interface made middleware trivial.
io.Reader and io.Writer allowed me to compose data transformations like UNIX pipes.
The built-in context package helped me control timeouts and cancellations without bolting on extra dependencies.

Go’s standard library wasn’t just a set of tools, it was a philosophy. One built around simplicity, composability, and minimal assumptions.

The Shift in Mindset

I used to reach for dependencies first. Now, I pause. I look at the standard library. I ask myself, What is Go trying to show me here?

Most of the time, the answer is already there, I just wasn’t listening.

Takeaway: The real power isn’t in external libraries; it’s in understanding the language’s own patterns. Once you stop fighting Go and start listening to it, everything changes.