DEV Community: Samuel Thuku

Day 3: CLI or Polar? Learnt Lightning Both the Hard and the Easy Way

Samuel Thuku — Thu, 11 Jun 2026 01:54:06 +0000

Some people learn to swim by reading a book. Others get pushed into the deep end. Today was both. Somewhere in the middle, a lifeguard(Polar) showed up.

Today the goal was simple on paper. Learn the Lightning Network, understand how it works and continue with the setup. The CLI came first. No shortcuts. No GUIs. Just a terminal and a lot of commands.

The LND binaries for version 0.20.1-beta were downloaded and extracted. After that, lnd and lncli were moved into /usr/local/bin so the system could actually find them.

Then came the first real friction point.

LND was executed, but it immediately threw errors.

At first, it looked like a simple config issue. It was not.

LND does not just run, it needs to be explicitly told what environment it is living in

So it had to be run with the correct flags

--bitcoin.active
--bitcoin.regtest
--bitcoin.node=bitcoind

Without those, LND defaults to btcd which was not even running. That mismatch alone broke everything.

Once it was pointed to bitcoind, things finally started behaving.

That was the first real lesson LND is strict. If the environment is not described properly it refuses to guess.

Next came Bitcoin Core configuration

That meant editing bitcoin.conf and adding ZMQ

bash id="wtthwk" zmqpubrawblock=tcp://127.0.0.1:28332 zmqpubrawtx=tcp://127.0.0.1:28333

The file was saved. Everything looked right. Nothing worked.

LND kept failing silently until the real issue surfaced. bitcoind was still running the old config.

Restarting it fixed everything instantly.

Three terminal windows were opened Alice, Bob and a general workspace

Wallets were created

bash alice create bob create

Passwords were set. Seed phrases were skipped since this was regtest.

At first both nodes showed synced_to_chain=false Still catching up on 101 blocks from yesterday.

Then suddenly true

That moment when everything just clicks into place.

Alice was funded next

A new address was generated

bash alice newaddress p2wkh

1 BTC was sent from the regtest wallet then blocks were mined

bash bitcoin-cli generatetoaddress 6

100,000,000 sats appeared

Still one of the most satisfying moments in the stack

Lightning setup came next

Bob’s pubkey was grabbed and nodes were connected

bash alice connect <bob_pubkey>@localhost:9736

Then a channel was opened

bash alice openchannel --node_key=<bob_pubkey> --local_amt=1000000

A few blocks later the channel became active

Alice had 1M sats Bob had 0

For now

First payment

An invoice was created

bash bob addinvoice --amt=50000 --memo="Lightning Coffee"

Payment went through using payinvoice

And it worked

Nothing moved in the channel. Only the state changed.

That is the system in one line.

Alice Bob Charlie

A simple chain formed next

Alice had no direct channel to Charlie but payment still flowed

Bob became the router

A tiny fee was earned for forwarding it

That is when Lightning stopped feeling like nodes and started feeling like a network

Polar came next

After surviving the CLI setup, polar felt like the easy mode reward

It was not

Polar depends on Docker containers. Without Docker running properly nothing starts

So Docker had to be installed and healthy first

Only then did Polar work

Two LND nodes were dragged onto a canvas and started

Everything came up instantly

No config files, no flags, no terminal juggling

But under the hood it was still Docker running LND exactly like before

Polar does not remove complexity. It wraps it

The Problem Lightning Solves

Bitcoin on chain does 2-7 transactions per second.Visa does tens of thousands. Blocks take on average 10 minutes to be mined and added to the chain

That makes real time payments impossible

Lightning fixes this by moving transactions off chain

One on chain transaction opens a channel After that payments are instant and nearly free

Think bar tab You do not swipe for every drink You settle at the end

How a Channel Actually Works

A Lightning channel is a 2 of 2 multisig wallet

Both participants control it Neither can move funds alone

Every payment updates shared state Old states are invalidated using revocation keys If someone cheats they lose everything

That is the enforcement layer

So when sats moved between Alice and Bob nothing changed on chain Only state moved

Invoices and the Preimage

Invoices are hash locks

A secret preimage is generated and only its hash is shared

Payment locks funds to that hash

Reveal the preimage and funds are claimed

It was verified manually by hashing and matching the invoice hash

It matched exactly

That is the moment cryptography stops being abstract and starts being real

Multi Hop Routing

Alice Bob Charlie

Alice does not know Charlie Charlie does not know Alice Bob just forwards payments

Bob earns a small fee

Each node only sees one hop That is onion routing

Forwarding history showed the fee instantly

Small but real

That is the incentive system working

Channel Close Options

Cooperative close is clean both parties agree funds settle on chain

Force close is fallback one party disappears and state is broadcast then locked by timelock

Both were tested Cooperative was instant Force close felt like waiting for the chain to settle a dispute

Both are necessary

Why This Matters

Lightning is already live

Strike enables global Bitcoin payments
Bitnob enables cross border remittances
Cash App supports Lightning at scale
Pick n Pay accepts Bitcoin in stores

What used to feel experimental is already infrastructure

Day 3 Summary

CLI forced everything to be understood flags btcd vs bitcoind ZMQ wallets channels failures

Polar showed what happens when all of that runs inside Docker with a UI on top

Both mattered

Lightning channels are multisig with evolving state Payments are hash locked Routing is trustless Timelocks enforce fairness

Somewhere between broken configs and running containers money moved without banks without intermediaries and without permission

Just math doing its job

Day 2: Bitcoin Explorer - The "I Should Have Just Used Bitcoin-CLI" Edition

Samuel Thuku — Tue, 09 Jun 2026 21:57:01 +0000

Previous day's adventure

Morning: Docker Debacles

So there I was, bright-eyed and bushy-tailed, ready to build a Bitcoin Explorer. The PDF said "just use Bitcoin Core." Simple. Elegant. Boring.

Where's the fun in that?

Me, apparently: "You know what would make this 100x harder? Docker."

My inner voice, screaming: "NOBODY SAYS THAT."

But I couldn't help myself. I love creating problems where none exist. It's my superpower. And my curse.

Let me walk you through the hour I spent trying to get a Bitcoin node running in Docker, as documented by my increasingly unhinged command history:

2015  E: Unable to locate package doker.io
2016  E: Couldn't find any package by glob 'doker.io'

Note to self: "docker" has a 'c' in it. Remember this for next time. (I won't.)

After finally installing Docker correctly (spelling matters, who knew?), I pulled the image:

2019  sudo docker pull lncm/bitcoind:v27.0

Then came the first attempt at running it:

2020  docker run -d --name bitcoin-node -p 18443:18443 lncm/bitcoind:v27.0 bitcoind -regtest -rpcbind=0.0.0.0 -rpcallowip=0.0.0.0/0

Permission denied. Of course.

2021  sudo docker run -d --name bitcoin-node -p 18443:18443 lncm/bitcoind:v27.0 bitcoind -regtest -rpcbind=0.0.0.0 -rpcallowip=0.0.0.0/0

Container runs! Then immediately dies. Great.

2022  sudo docker ps
# (empty. of course.)

This pattern repeated. A lot. Like, a lot a lot.

2023  sudo docker run... (dies)
2024  sudo docker start bitcoin-node (fails)
2025  sudo docker rm -f bitcoin-node (rage delete)
2026  sudo docker run... (dies again)

I went through this loop so many times that I think I achieved some kind of meditative state. The five stages of Docker grief:

Denial: "It'll work this time, I just need one more flag"
Anger: "WHY WON'T YOU STAY RUNNING"
Bargaining: "Please... I'll use any image... just work..."
Depression: stares at terminal for 3 minutes
Acceptance: "Fine, I'll try a different image"

2029  sudo docker run -d --name bitcoin-node -p 18443:18443 lncm/bitcoind:v27.0 bitcoind -regtest -rpcbind=0.0.0.0 -rpcallowip=0.0.0.0/0 -rpcuser=user -rpcpassword=pass
2030  sudo docker logs bitcoin-node
# Error: No such file or directory - something about config

At some point I switched to the ruimarinho/bitcoin-core image, then the official bitcoin/bitcoin image. Same problems, different flavors.

The actual issue? The command arguments were in the wrong place. The bitcoind part needed to be after the image name, not before. And the flags needed to be passed correctly. And I needed to accept that I'd wasted 45 minutes on something that should have taken 2.

2064  sudo docker run -d --name bitcoin-node -p 18443:18443 bitcoin/bitcoin:27.0 -regtest=1 -rpcbind=0.0.0.0 -rpcallowip=0.0.0.0/0 -rpcuser=user -rpcpassword=pass -server=1
2065  sudo docker ps
# FINALLY. A running container.

Victory dance performed. Neighbors concerned.

The Cookie Crisis

But wait! The adventure wasn't over. Now I needed to talk to this container.

2071  docker exec bitcoin-node bitcoin-cli -regtest -rpcuser=user -rpcpassword=pass createwallet "dev_wallet"
# works!
2074  sudo docker exec bitcoin-node bitcoin-cli -regtest -rpcuser=user -rpcpassword=pass getblockchaininfo
# returns something!

But then... I got lazy. Or forgetful. Or both. (Spoiler: both.)

Instead of using the -rpcuser and -rpcpassword flags every time, I thought I'd set up a bitcoin.conf file. Classic mistake - assuming configuration works on the first try.

2085  nano ~/.bashrc
# added some aliases. felt powerful.
2091  nano ~/.bitcoin/bitcoin.conf
# added rpcuser=user, rpcpassword=pass, regtest=1
2092  bitcoin-cli getblockchaininfo
# Error: Could not locate RPC credentials. No authentication cookie found.

Turns out, the Docker container doesn't magically know about my local bitcoin.conf. It has its own filesystem. Its own config. Its own existential crisis about why it was created.

Moral of the story: Just use the flags. Or mount a volume. Or, you know, don't use Docker at all like the PDF suggested. BUT WHERE'S THE FUN IN THAT?

Finally, Some Actual Coding

After the Docker disaster, I needed to write actual Python. Remember the PDF? The challenges?

I opened explorer_starter.py and started implementing. The RPC helper was already there (bless the bootcamp authors), but it had a small problem:

resp = requests.post(url, data=data, auth=("user", "pass"))
# Missing .json() and return statement

Fixed that. Then came the challenges.

Challenge 1: Blockchain Info (Easy mode)

def show_blockchaininfo():
    info = rpc("getblockchaininfo")
    print(f"Blocks: {info['difficulty']}")  # Wait, difficulty? Not blocks?

Um. That's not what the PDF asked for. Nice try, past me. Fixed it to actually show chain, blocks, AND difficulty.

Challenge 2: Wallet Balance

def show_wallet_balance(wallet_name):
    try:
        info = rpc("getbalance", wallet=wallet_name)
        if info is not None:  # Fixed: "is not None" not "is not None"
            print(f"Balance for {wallet_name} is: {info}")

This worked! Mostly. When the wallet was loaded. Which it wasn't, half the time.

Challenge 3: List Transactions (The Typo Trap)

This one got me good. Look closely:

if tx['category'] in ('recieve', 'generate', 'immature'):  # RECIEVE?!

I wrote 'recieve' instead of 'receive'. My editor didn't catch it. The Python interpreter didn't catch it (it's a valid string, just the wrong one). But Bitcoin Core definitely caught it - because transactions have category 'receive', not 'recieve'.

So my "IN" transactions were always empty. Everything showed as "OUT". Including incoming money.

That's not ideal for a wallet display.

"Wait, why does Alice have negative balance? She just mined 101 blocks!"

Found it. Fixed it. Facepalmed appropriately.

Challenge 4: Decode Transaction

This was actually fun. Looking at raw transactions, seeing the inputs and outputs, understanding the structure. The coinbase transaction (mining reward) has no inputs - just a special coinbase field.

def decode_transaction(txid):
    tx = rpc("getrawtransaction", [txid, True])
    print(f"Size: {tx['size']} bytes")

    print("\nInputs")
    for vin in tx['vin']:
        if 'coinbase' in vin:
            print("COINBASE (mining reward) - money printer goes brrr")
        else:
            print(f"From: {vin['txid'][:20]}...")

It's like being a blockchain detective. Except instead of solving crimes, you're just... looking at numbers. Glorious numbers.

Challenge 5: Block Details

def show_block(blockhash=None):
    if blockhash is None:
        blockhash = rpc("getbestblockhash")  # Get the tip if none provided
    block = rpc("getblock", [blockhash, 1])

    print(f"==== Block #{block['height']} =====")
    print(f"Hash: {block['hash'][:20]}...")
    print(f"Time: {block['time']}")
    print(f"Transactions: {block['nTx']}")

This worked beautifully. I felt like a real blockchain explorer. Not a fake one. A legitimate one.

Bonus Feature: UTXO Explorer

The PDF had a homework suggestion: "Show UTXO set for a wallet." I decided to implement it because I'm an overachiever (and also because the transactions weren't showing up correctly and I wanted to debug).

def show_wallet_utxos(wallet_name):
    utxos = rpc("listunspent", [0, 9999999], wallet=wallet_name)

    print(f"\n--- UTXOs for {wallet_name} ---")
    total = 0
    for utxo in utxos:
        amount = utxo['amount']
        total += amount
        print(f"TxID: {utxo['txid'][:10]}... | Amount: {amount} BTC")

    print(f"Total Balance: {total} BTC")

UTXOs (Unspent Transaction Outputs) are Bitcoin's version of "here's exactly where your money is." It's like having a wallet full of gift cards instead of a single bank balance. Each UTXO is a specific output from a specific transaction that hasn't been spent yet.

Bitcoin doesn't have "balances" - it has UTXOs. Your wallet just sums them up to show you a number. Mind blown? Mine was.

The RPC Helper Evolution

Throughout the day, my rpc() function got some upgrades:

def rpc(method, params=None, wallet=None):
    url = "http://127.0.0.1:18443/"
    if wallet:
        url = f"{url}wallet/{wallet}"

    data = json.dumps({
        "jsonrpc": "1.0", 
        "id": "explorer",
        "method": method, 
        "params": params or []
    })

    try:
        resp = requests.post(url, data=data, auth=("user", "pass")).json()
        if resp.get("error"):
            print(f"RPC Error: {resp['error']}")
            return None
        return resp["result"]
    except Exception as e:
        print(f"Connection error: {e}")
        return None

Error handling! JSON parsing! Proper returns! It's almost production-ready. (Please don't put this in production.)

The Final Working Explorer

After all the debugging, the typo fixes, the Docker nightmares, and the existential crisis about why I chose this path, I had a working Bitcoin Explorer that could:

Show blockchain info (chain type, block height, difficulty)
Check wallet balances (Alice had 101 BTC, Bob had... nothing. Poor Bob.)
List recent transactions (with correct IN/OUT directions!)
Decode any transaction (peer into the matrix)
Display block details (hash, height, time, tx count)
Show UTXOs (because I'm fancy)

What I Learned Today (The Real TL;DR)

Docker is powerful but hates me personally. The container approach is great for isolation, but debugging flags and paths will make you question your life choices. If the PDF says "just run Bitcoin Core locally," maybe... just do that?

JSON-RPC is actually pretty straightforward. Send JSON, get JSON. No magic. Just data. Beautiful, predictable data.

Bitcoin transactions are just directed graphs. Inputs point to previous outputs. Outputs point to... nothing, until they become inputs. It's all connected. It's beautiful. It's also why UTXOs exist.

Typos will betray you every time. 'recieve' vs 'receive' cost me 20 minutes. Spell check your strings, people.

Reading blockchain data is empowering. Being able to query the chain, see balances, decode transactions - it feels like you're looking at the raw fabric of digital scarcity. (Okay, that's dramatic. But it is cool.)

Tonight's Homework (That I'll Definitely Do)

[x] Complete all 5 explorer challenges (DONE)
[ ] Try the multisig bonus exercise (maybe tomorrow)
[x] Add UTXO feature (already did, overachiever style)
[ ] Calculate total fees in a block (sounds fun)
[ ] Search transactions by address (for the next release)

A Note on the Multisig Section

The PDF mentioned 2-of-2 multisig as preparation for Lightning. The idea: Alice AND Bob must both sign to spend. Neither can steal alone. It's the foundation of trustless payment channels.

I glanced at the 03_multisig.sh exercise. Then I glanced at the clock. Then I glanced at my coffee cup (empty). Then I decided multisig is a "tomorrow problem."

Future me is going to be so annoyed at past me.

Final Stats

Metric	Value
Docker containers created	12
Docker containers killed	11
Typo-induced debugging sessions	4
Times I said "why isn't this working"	47
Times the answer was "because Docker"	32
Lines of Python written	~150
UTXOs discovered	Too many
Sanity remaining	Minimal
Fun had	Actually, quite a lot

Tomorrow: Lightning Network! Where channels open, payments route, and I inevitably break everything again.

Same bat-time, same bat-channel. (But hopefully fewer Docker commands.)

P.S. If you're doing this bootcamp and your explorer isn't working, check your wallet names. I spent 10 minutes querying "alise" before realizing I can't type. bitcoin-cli listwallets is your friend. Use it.

P.P.S. - The cookie file is at ~/.bitcoin/regtest/.cookie if you're running locally. Save yourself the pain I endured.

From Blocks to Blinks: My Bitcoin Lightning Network Bootcamp Adventure(Day 1)

Samuel Thuku — Mon, 08 Jun 2026 16:17:23 +0000

I woke up thinking I was just going to attend a normal Bitcoin bootcamp. By the end of the day I had fought with a build system, wrestled a missing CMake installation, mined coins on a private chain, and casually sent transactions between wallets named Alice and Bob like it was nothing.

It was the kind of day that feels longer than it actually is not because it was boring, but because every hour had a different kind of problem to solve.

The first battle: a machine with no sudo

The day started with what looked simple on paper: install Bitcoin Core and run it in regtest mode. In reality, I was working on a managed machine without sudo access. That one detail changed everything.

Normally you’d just:

apt-get install bitcoin-core

But that wasn’t an option here. So the entire setup became a kind of “build everything yourself” exercise.

I cloned the Bitcoin repository and immediately ran into the first wall: dependencies and build tools. CMake, Boost, libevent all the usual suspects. The system version of CMake either wasn’t suitable or wasn’t consistently available, so I had to improvise.

That turned into a long detour.

The CMake scavenger hunt

What followed was basically a mini treasure hunt across installation methods:

Tried system packages (limited by permissions)
Searched for existing CMake binaries across /usr, /opt, and $HOME
Installed CMake manually using Kitware’s release script
Then reinstalled it again after path issues
Fixed PATH in .zshrc multiple times
Verified with cmake --version more times than I care to admit

At one point I even had multiple competing installations of CMake and had to figure out which one the shell was actually using.

There was a moment where cmake existed, but not where Bitcoin Core expected it. Another moment where it existed in $HOME/cmake, but the PATH pointed somewhere else entirely.

That part of the day felt less like development and more like debugging my own environment.

The Bitcoin Core build struggle

Once CMake finally behaved, I tried:

cmake -B build

It failed. Not because Bitcoin Core was broken, but because dependencies were still missing or not properly aligned.

That led to the next strategy: building via the depends system.

So I:

Entered depends/
Ran make -j4
Attempted to compile dependencies manually
Rebuilt everything with flags to avoid GUI components (NO_QT=1)
Cleaned build artifacts with git clean -fdx
Restarted configuration multiple times

At some point the build directory had been created, deleted, and recreated so many times it stopped feeling like a project folder and started feeling like a scratchpad.

Eventually, I got to a working configuration using the toolchain file:

cmake -B build --toolchain depends/x86_64-pc-linux-gnu/toolchain.cmake
cmake --build build -j4

That was the turning point. From there, Bitcoin Core actually compiled.

First successful run: regtest mode

Once bitcoind finally started, everything shifted from setup pain to actual exploration.

I configured:

~/.bitcoin/bitcoin.conf
regtest mode (so I wasn’t touching real Bitcoin)
RPC access for CLI interaction

Then I started playing with the node.

The first real confirmation that everything worked:

bitcoin-cli -regtest getblockchaininfo

Seeing a valid response from a freshly built Bitcoin node felt like crossing a threshold. At that point, all the earlier frustration made sense.

Wallets, mining, and “fake” Bitcoin that feels real

We created wallets:

Alice
Bob

Then generated addresses:

bitcoin-cli -regtest -rpcwallet=alice getnewaddress
bitcoin-cli -regtest -rpcwallet=bob getnewaddress

Then came mining:

bitcoin-cli -regtest generatetoaddress 101 "$ALICE"

The reason for 101 blocks was explained: coinbase maturity rules. Only after 100 confirmations do mined rewards become spendable.

That moment when Alice suddenly had spendable Bitcoin made the abstract idea of mining click properly. It wasn’t just theory anymore. It was observable state changes in a ledger I could control.

Sending transactions between Alice and Bob

The next step was moving coins around:

bitcoin-cli -regtest -rpcwallet=alice sendtoaddress "$BOB" 10

Watching balances update between wallets felt surprisingly interactive. It wasn’t “simulation” in a toy sense it was a real node executing real consensus rules, just in a private sandbox.

We checked:

mempool state
transaction IDs
wallet balances
block confirmations

At one point I tried querying transactions with placeholder TXIDs, broke the command formatting a few times, and had to carefully inspect outputs to understand what actually got recorded.

That part taught something subtle: Bitcoin CLI is extremely literal. It doesn’t guess intent. It just executes exactly what you pass.

Flash quizzes and satoshis

Interspersed with the technical work were flash quizzes. They were fast-paced, and surprisingly fun. Answering correctly sometimes earned satoshis, which added a small but motivating game layer to the learning.

It changed the tone of the day. Instead of just debugging and reading outputs, there was a competitive rhythm to it.

Mining, decentralisation, and what actually matters

One of the bigger conceptual takeaways was mining and decentralisation.

Seeing mining in regtest mode made it clear that:

Mining is not “creating money from nowhere”
It’s validating state transitions
It enforces agreement on history through work

And decentralisation stopped being a slogan. It became a system where no single command or machine dictates the ledger even though in my setup, I was temporarily “all miners at once.”

That contrast actually helped understanding rather than hurting it.

The quantum computing concern

I had a lingering worry going into the session: if quantum computers become powerful enough, could they break Bitcoin’s cryptography and render it worthless?

We discussed it, and the key point that stuck was this:

Bitcoin’s security relies heavily on elliptic curve cryptography (ECC), specifically secp256k1. While quantum computers theoretically pose a threat via Shor’s algorithm, the practical barrier is still enormous. We are not at a point where private keys can be derived from public keys at scale.

Also, Bitcoin isn’t static. If that ever became a real threat, the protocol could migrate to quantum-resistant signature schemes through upgrades.

So the fear didn’t disappear, but it became more grounded. Less “Bitcoin will suddenly die”, more “cryptography evolves with threats”.

Ending the day

By the end of the session, I had:

Built Bitcoin Core from source under constraints
Fixed multiple environment/tooling issues without sudo
Run a regtest node
Created wallets
Mined blocks
Sent transactions
Explored the blockchain via CLI

But more importantly, I had gone from treating Bitcoin as a peer-to-peer trading tool I occasionally used, to understanding it as a system with rules I could directly interact with.

And then there’s Lightning Network which is what tomorrow is about. Today was the foundation. Tomorrow is where things start moving fast.

For a first day, it wasn’t smooth. But it was the kind of messy that actually teaches you something.

Why Does Google Keep Changing My Language? (And How to Fix It)

Samuel Thuku — Sun, 17 May 2026 09:33:19 +0000

Have you ever searched for something on your browser and suddenly Google decides you now speak a completely different language just because of where you are? 😂

Maybe you searched for a programming tutorial and got results in French.
Maybe you traveled somewhere and your browser started showing local language websites you never asked for.
Or maybe Google saw your IP address and thought:

“Ah yes, this person definitely wants everything translated.”

Meanwhile you are just trying to search in peace. 😭

The good news is that there’s a permanent fix.

Instead of letting Google guess your language and region based on your location, you can customize the Google search engine URL so your browser always forces:

English results
English interface
US-based search ranking
Minimal personalization
No annoying country redirects

And the best part?

It does NOT slow down your internet or increase latency.

The Permanent Fix

We are going to create a custom Google search engine URL.

Use this URL:

https://www.google.com/ncr/search?q=%s&hl=en&gl=us&lr=lang_en&pws=0

What each part means:

hl=en

Forces Google interface language to English.

gl=us

Makes Google prioritize US-style search results.

lr=lang_en

Prioritizes English-language pages only.

pws=0

Reduces personalized search results.

ncr

Means “No Country Redirect.”
Stops Google from redirecting you to country specific domains like:

google.fr
google.de
google.co.ke

Step-by-Step Setup Guide

Chrome

Open:

chrome://settings/searchEngines

Click:

Add

Then enter:

Search Engine:
Google English

Shortcut:
g

URL:
https://www.google.com/ncr/search?q=%s&hl=en&gl=us&lr=lang_en&pws=0

Now click:

Save

Then click the 3 dots beside the new search engine and choose:

Make Default

Done ✅

Microsoft Edge

Open:

edge://settings/searchEngines

Click:

Add

Enter:

Search Engine:
Google English

Shortcut:
g

URL:
https://www.google.com/ncr/search?q=%s&hl=en&gl=us&lr=lang_en&pws=0

Save it and set it as default.

Done ✅

Firefox

Open:

about:preferences#search

Firefox handles this a little differently.

Create a new bookmark with this URL:

https://www.google.com/ncr/search?q=%s&hl=en&gl=us&lr=lang_en&pws=0

Then assign a keyword like:

Now whenever you type:

g your search here

Firefox will use your custom Google setup.

Done ✅

Bonus Tip: Disable Browser Location Access

Even after changing the search URL, some browsers still share your location.

You can disable that too.

Chrome / Edge

Open:

chrome://settings/content/location

or:

edge://settings/content/location

Then choose:

Don't allow sites to see your location

Done ✅

Final Result

After this setup:

Google stops changing languages randomly
Search results stay in English
Country redirects disappear
Results become more consistent
Your browser behaves the same no matter where you travel

No VPN required.
No extensions required.
No slowdown.

Just clean, predictable Google searches.

About the Author

Written by Samuel Thuku, a software engineer who enjoys solving annoying everyday tech problems, automating things that should have worked properly in the first place, and making the internet a little less chaotic one fix at a time. 😄

Battling the Ghost in the Server: A Tale of Rsync, Tildes, and Misleading Banners.

Samuel Thuku — Fri, 15 May 2026 07:29:11 +0000

By 4:47 PM, all I wanted was one final win before shutting down my laptop: copy a few files from a remote shared server to my local machine. A task so simple it barely deserved a second thought.

Or so I believed.

What started as a routine rsync command quickly spiraled into a full-blown terminal drama featuring misleading error messages, hostile authentication policies, disappearing sessions, and a server banner that outright lied to my face. Every fix uncovered a new problem, every command felt like a puzzle, and the humble file transfer turned into an unexpected battle against a highly secured shared machine.

This is the story of how a “five-minute task” became an afternoon-long debugging thriller — and the exact commands, mistakes, and lessons that finally led to victory.

Today at the office, this "five-minute task" turned into an epic tech thriller. Here is the story of how a routine file transfer turned into a battle of wits against a shared machine, the commands that saved the day, and the valuable lessons learned along the way.

Step 1: The First Attempt (The False Start)

Armed with confidence, I opened my terminal. I knew the target IP address (192.168.1.6) and I knew my destination (the current directory, represented by a trusty dot .).

I confidently typed:

rsync -pvarh 192.168.1.6 .

The Climax:

rsync: [sender] link_stat "/home/username/192.168.1.6" failed: No such file or directory

The Lesson:

Terminal networks are literal. Because I forgot the username and the colon (:), rsync thought I was looking for a local folder named 192.168.1.6 inside my own home directory. Oops.

Step 2: Fighting the Authentication Loop

Alright, easy fix. I needed to tell rsync to use SSH to talk to the remote server. I added my username and the IP address.

But then, a new boss appeared: the corporate password policy.

Every time I made a slight typo in my password, the server completely dropped my connection instantly. No second chances. No "Please try again." Just a cold, hard termination.

To bypass this and force the terminal to let me try typing my password properly without dropping the session, I brought out the SSH options flag:

rsync -pvarh -e "ssh -o PubkeyAuthentication=no" username@192.168.1.6:~ .

By telling rsync to ignore my local public keys, it forced a direct, clean password prompt.

Step 3: The Gaslighting Server Banner

I ran the command. The password prompt appeared. I carefully typed my password and hit Enter.

Suddenly, my screen flashed this aggressive warning:

════════════════════════════════════════
User does not exist or password incorrect
════════════════════════════════════════

I panicked. Did I get locked out? Is my account deleted?

But wait... right underneath that scary banner, the terminal printed:

rsync: [sender] link_stat "/home/username/~" failed: No such file or directory

The Plot Twist:

The password was correct! The server had logged me in successfully, but a custom corporate security banner was programmed to print that terrifying "incorrect password" message anyway just to confuse unauthorized guests (and exhausted sysadmins).

However, a new problem arose: rsync was looking for a literal folder named ~ instead of recognizing it as my home directory. On highly secure shared machines, the shell often blocks shortcut symbols like the tilde (~) from expanding.

Step 4: Sweet, Sweet Victory

With the final puzzle piece in place, I realized I had to stop using shortcuts and give the server exact, absolute paths. No more tildes.

I swapped ~ for the full, explicit path /home/username/ and ran the final command:

rsync -pvarh -e "ssh -o PubkeyAuthentication=no" username@192.168.1.6:/home/username/ .

The Result:

The incremental file list loaded perfectly, the progress bars flew across the screen, and the files safely landed on my local machine. Success!

Key Takeaways for Your Next Server Battle

Colons Matter

Always use:

user@IP:/path

for remote targets.

Without the colon, you are just talking to your own computer.

Beware of Banners

Don't trust every error message you read on a shared corporate server; look at the actual terminal output underneath the scary boxes.

Be Explicit

Shortcuts like ~ are great for local terminal work, but when automating or crossing servers, spell out the full path (like /home/username/) to avoid confusion.

Stop Solving Solved Problems: Escaping the Cycle of Duplicated Code

Samuel Thuku — Wed, 11 Mar 2026 07:55:54 +0000

It’s a scenario that plays out in countless offices and home offices every day: a software developer stares at a tricky problem, cracks their knuckles, and begins architecting a solution in their mind. They envision the modules, the APIs, and the elegant lines of code that will slay the dragon. Days, or even weeks, later they emerge with a working solution, proud of their creation, only to discover (or have a colleague point out) that an open-source library or internal tool already does the exact same thing.

Sometimes the existing tool is even better than what the developer built.

This phenomenon is the source of a well-worn joke in the industry: “Every time a developer encounters a problem, they start building a solution, completely missing that it already exists.” While it’s funny, the reality behind it is a costly and frustrating cycle of duplicated effort. It’s a multifaceted issue rooted in psychology, corporate culture, and sometimes a lack of training. It’s often summarized by the pejorative term “Not Invented Here” (NIH) syndrome.

The Case for “Proudly Found Elsewhere”

The cost of this duplication is staggering. It’s not just wasted development hours. It’s the compounded cost of maintaining multiple, slightly different implementations of the same thing. Every bug fix has to be applied in multiple places. Every new developer has to learn multiple systems. Over time, the software ecosystem becomes bloated and brittle.

This is why a cultural shift toward “Proudly Found Elsewhere” is so important. It’s a mindset that prioritizes solving the business problem over the personal satisfaction of writing every line of code. It recognizes that standing on the shoulders of giants, whether they are open-source maintainers or a team in the next building, leads to faster delivery, higher quality, and more sustainable software.

How to Build a “Proudly Found Elsewhere” Culture

Moving past NIH syndrome requires a conscious effort from both individuals and organizations.

For organizations: Build a marketplace, not a black hole.
If you want code to be reused, you have to make it easy to find and easy to use. This means investing in internal component marketplaces where teams can publish their libraries with clear documentation, usage examples, and versioning. It also means fostering a culture of collaboration where teams are encouraged to talk to each other about their technical challenges and share solutions.

For organizations: Incentivize reuse.
Change the metrics. Reward engineers who contribute to internal libraries and those who choose to reuse them. If a project is delivered faster and with fewer bugs because it leveraged existing components, that should be celebrated as a win, not dismissed as “not doing real work.”

For developers: Ask “Why not?” before “How?”
Before writing a single line of code for a common problem like logging, authentication, or data validation, make it a habit to search for existing solutions. Ask your teammates. Check the company wiki. Look for open-source libraries. Assume the solution already exists until you can prove that it doesn’t.

For developers: Contribute, don’t fork.
If you find an existing library that covers 80% of what you need, don’t immediately decide to build the remaining 20% from scratch. Consider contributing the missing feature back to the original project. Another option is extending it with a plugin. Improving an existing tool is almost always better than creating a new one that will have to be maintained forever.

The Nuance: When Reinvention Is the Right Choice

It’s important to acknowledge that reinventing the wheel isn’t always a bad thing. Sometimes it leads to innovation. As developer Lea Verou has argued, using a massive, bloated library for a tiny fraction of its features can introduce significant performance overhead and long-term maintenance costs. If you only need 5% of a library’s functionality, writing a small, purpose-built function might actually be the smarter choice.

For example, parsing a few lines of simple Markdown for bold text and links doesn’t necessarily require a 1,700-line library. A small custom function might do the job more efficiently and with far less complexity.

The key is intentionality. The goal is to stop the accidental or arrogant reinvention of wheels, the kind that happens because a developer didn’t look, didn’t ask, or didn’t care. By shifting our focus from the pride of creation to the satisfaction of solving real problems efficiently, we can escape this costly cycle.

We should celebrate finding the perfect existing solution just as much as we celebrate building a new one from scratch.

My Brain on Concurrency: Goroutines, Mutexes, and a Coworking Space Analogy

Samuel Thuku — Thu, 05 Mar 2026 00:09:14 +0000

For the past week, I've been deep in the weeds of Go. I've built a few REST APIs and CLI tools, so I understand the syntax fairly well. But there is a pillar of Go that I kept treating like a black box: Concurrency.

I understood the value of it, making programs fast by doing multiple things at once but I didn't understand the mechanics.I mapped it to something I deal with every day, a busy coworking space.

Here is what I learned about Goroutines, Mutexes, and the often overlooked RWMutex, reframed through the lens of freelancers fighting over resources.

1. The workers: Understanding Goroutines

Imagine a single-threaded program as a co-working space with just one person working there. They have the whole place to themselves. They can spread out, take calls, and use the whiteboard without interruption. It's peaceful, but if they get stuck waiting for a client to email them back, the entire office goes idle.

Goroutines are like inviting more freelancers into that space.

Now you have multiple people working on their own projects independently. One is designing a logo, another is writing a blog post, a third is on a sales call. They are all making progress simultaneously. The beauty of Go is that it doesn't necessarily need a separate physical room (OS thread) for each freelancer. The Go runtime acts like a hyper-efficient community manager, shuffling the freelancers onto available desks as needed, allowing thousands of them to coexist without renting a skyscraper.

Where you actually use this: Think about a web server. In languages like Python or Ruby, each incoming user request typically takes up an entire OS thread, which is heavy and limits how many users you can handle. In Go, each request is handed off to a lightweight Goroutine. This is why Go is so popular for building high-throughput APIs. When thousands of people hit your app at the same time, you're not crashing—you're just activating more freelancers.

2. The Problem: The Resource Contention

But hiring more freelancers creates a new problem. What happens when multiple freelancers need to use the same shared resource?

In my coworking space analogy, imagine there is only one premium conference room with a video setup. If two freelancers have back-to-back client calls booked at the exact same time, we have a conflict.

I wrote a small program to simulate this. I imagined a booking system for that conference room. Two Goroutines (freelancers, Alice and Bob) check the calendar simultaneously. They both see that the 10 AM slot is free. They both book it. Suddenly, we have double-booking chaos. Two clients show up to the same meeting link, and the freelancers look unprofessional.

This is a Race Condition. Both processes were able to read the calendar at the same time, assumed the resource was available, and acted on that stale information.

Where you actually see this: This exact scenario happens in e-commerce during flash sales. Imagine 100 people trying to buy the last pair of sneakers. Without protection, your inventory system checks stock for all 100 at once, sees "1 available," and approves every purchase. You've now oversold inventory and have 99 angry customers. The race condition isn't just a coding error, it's a financial disaster.

3. The Receptionist: Introducing Mutexes

This is where I learned about Mutexes (Mutual Exclusion Locks). A Mutex is like a receptionist at the front desk.

The rules are simple:
The Lock: When a freelancer wants to check or modify the conference room calendar, they must go to the receptionist and ask for the physical booking logbook. The receptionist hands it over and tells everyone else to wait.

The Work: The freelancer can now safely look at the calendar, see the free slot, and write their name down. They know no one else can sneakily modify it while they are writing.

The Unlock: When they are done, they hand the logbook back to the receptionist, who can then give it to the next freelancer waiting in line.

I refactored my program to introduce a receptionist (the Mutex). By ensuring that only one freelancer could hold the logbook at a time, the chaos stopped.

The output finally made sense. Alice grabbed the logbook, checked the calendar, booked her slot, and handed it back. Only then did Bob receive the logbook. When Bob looked at the calendar, the 10 AM slot was clearly marked as taken, so he booked the 11 AM slot instead. No double-booking, no chaos.

Where you actually use this: Any time you have a shared resource that needs to stay consistent. This could be a bank account ledger (ensuring two withdrawals don't overdraft you), a connection pool to a database (ensuring two Goroutines don't grab the same connection), or a simple in-memory cache (Go maps will actually crash if one Goroutine tries to read while another writes). Mutexes are the gatekeepers for your critical data.

4. The Optimization: The RWMutex (Reader/Writer Mutex)

But then I ran into a performance problem. My receptionist (the standard Mutex) was doing their job too well.

In my co-working space, we added a bulletin board next to the reception desk. It lists all the upcoming community events. This board is read by dozens of freelancers every hour, but it is only updated once a week by the community manager.

Under my current receptionist rules, if someone wants to read the bulletin board, they have to take the logbook and lock everyone else out. This means if one person is slowly reading the events, twenty other people can't even glance at it. Worse, if someone is reading it, the community manager can't post the weekly update. Everything is blocked for everyone, even for simple look-ups. My program was running slowly because read operations were queuing up behind each other for no reason.

This is where I discovered the RWMutex (Read-Write Mutex).

The RWMutex is a smarter receptionist with different rules for readers and writers:

Multiple Readers: If a freelancer just wants to look at the bulletin board (a read operation), the receptionist lets them look simultaneously. Ten people can read the board at once without blocking each other.

Exclusive Writer: However, if the community manager needs to update the board (a write operation), the receptionist becomes strict. They wait for all current readers to finish, then lock the board exclusively. No one can read while the manager is updating, ensuring no one sees a half-finished, inconsistent version of the board.

When I refactored my code to use an RWMutex, I saw a huge performance boost. For data that was read frequently but written to rarely, the RWMutex allowed hundreds of Goroutines to access it simultaneously. The system only slowed down during the occasional write, which is exactly what I wanted.

Where you actually use this: Think about a configuration service for a large application. Thousands of microservices might be reading the configuration values every second to know which database to connect to. However, a developer updates the configuration maybe once a day. Using a standard Mutex here would be massive overkill—readers would be blocked waiting for other readers. An RWMutex allows all those read operations to happen in parallel, keeping the system fast while still protecting the occasional write.
Key Takeaways from My Journey

If you are just starting with Go concurrency, here are the mental notes I wish I had:

Goroutines are like freelancers: They allow your program to handle thousands of tasks at once, which is why Go excels at web servers and data pipelines.

Race conditions are like double-booking: They lead to corrupted data, oversold inventory, and inaccurate balances.

Mutexes are the receptionist: They ensure that only one task can modify a critical resource at a time, keeping your data safe.

RWMutex is a smarter receptionist: It lets multiple readers share the resource for better performance, perfect for configuration data or any read-heavy workload.

Use the Race Detector: Go's built-in race detector acts like a security camera. It showed me exactly where my double-booking was happening, saving me hours of debugging.

Concurrency is powerful, but it forces you to think about your program not as a linear script, but as a living system of independent actors competing for shared resources. It's a paradigm shift, but getting these concepts to click was incredibly satisfying.

_
Thuku Samuel is a software engineer passionate about clean code and Go programming._

Building a Calculator in Go: A Masterclass in Software Engineering Best Practices

Samuel Thuku — Mon, 23 Feb 2026 12:06:05 +0000

When I set out to build a calculator in Go, I thought it would be a weekend project. After all, how complex could a calculator be?

I could not have been more wrong.

What started as a simple calculator evolved into a complete software engineering bootcamp. From requirements to architecture, from testing to security, this tiny project taught me more about professional development than many large-scale systems I have worked on.
The Humble Calculator: More Complex Than You Think

Before writing code, I asked myself: what does a professional calculator actually need?

Basic arithmetic and advanced functions

A responsive graphical interface

A command-line interface for power users

Calculation history

Cross-platform compatibility

Comprehensive tests

A secure API layer serving both interfaces

This became my requirements document, forcing me to think about edge cases and constraints before coding.

Lesson 1: Even small projects benefit from written requirements.

Architecture: Layering Like an Onion

I chose a clean layered architecture:
text

calculator/
├── cmd/
│ ├── cli/ # CLI entry point
│ └── gui/ # GUI entry point
├── docs/
├── internal/
│ ├── core/ # Core logic
│ ├── parser/ # Expression evaluation
│ ├── service/ # Tokenization
│ ├── ui/ # Fyne interface
│ └── api/ # API layer
├── go.mod
├── go.sum
└── Makefile

Each layer has a single responsibility. The core knows nothing about the interfaces. The parser evaluates expressions independently. The API layer orchestrates everything securely for both the GUI and CLI.

Lesson 2: Clean architecture benefits projects of any size.

The API Layer: Building a Secure Foundation

The most important decision was creating an API layer between the interfaces and business logic. This single abstraction transformed my application.

Both interfaces share the exact same underlying logic. But simplicity does not mean sacrificing security. A production-ready API needs multiple layers of protection.

Input validation comes first. Every expression is checked for empty values, length limits prevent denial of service attacks, and a whitelist ensures only valid characters are accepted. No unexpected symbols, no control characters, nothing that could be used for injection.

Structural validation follows. The API checks for consecutive operators and ensures parentheses are properly balanced. Only well-formed expressions reach the calculation engine.

Panic recovery wraps everything. Despite best efforts, bugs happen. The API catches any panics, logs them, and returns friendly errors instead of crashing.

Audit logging tracks every request. Timestamps and expressions are logged for debugging, performance monitoring, and security forensics. This proved invaluable when users reported unexpected behavior.

Standardized responses ensure consistency. Every calculation returns the same structure with result, success indicator, and execution time. Both the GUI and CLI parse the same response format.

All this complexity remains invisible to both interfaces. The API stays simple while the implementation handles the hard parts.

Lesson 3: Security is built in from day one, not added later.

Lesson 4: Good APIs abstract complexity behind simple interfaces.
The Beauty of Shared Logic

With the API layer in place, both interfaces enjoy several benefits automatically.

The GUI gets a responsive experience with proper error handling. The CLI gets the same reliability for scripting and automation. When I fixed a bug in the parser, both interfaces benefited immediately. When I added security validation, both interfaces became more secure without any changes to their code.

This is the power of the API layer. It becomes the single source of truth for calculation logic, and every interface simply plugs into it.

Lesson 5: Build once, use everywhere.
The History Feature: Ring Buffers

Displaying the last 3 operations required a fixed-size history. Go's container/ring provided the perfect solution:

go

var operationHistory = ring.New(3)

func addToHistory(expression string, result float64) {
    opString := fmt.Sprintf("%s = %v", expression, result)
    operationHistory.Value = opString
    operationHistory = operationHistory.Next()
}

When users press equals, operations are added to the ring, automatically overwriting the oldest entry. The GUI displays this history visually, while the CLI could easily add a history command.

Lesson 6: Know your standard library.
The UI Challenge: Custom Button Colors

Fyne is a delightful UI toolkit, but customizing button colors required creativity. The solution stacked colored rectangles behind transparent buttons:

go

btn := func(label string, textColor color.Color, bgColor color.Color, tapped func()) fyne.CanvasObject {
    txt := canvas.NewText(label, textColor)
    txt.TextStyle = fyne.TextStyle{Bold: true}

    bg := canvas.NewRectangle(bgColor)
    button := widget.NewButton("", tapped)
    button.Importance = widget.LowImportance

    content := container.NewStack(bg, button, txt)
    return withHeight(content, 75)
}

Number buttons became blue, operators orange, and clear red.

Lesson 7: Understanding composition lets you break free from default constraints.
Testing Through the API

Testing through the public API exercises the entire flow in one go:

go

func TestAddition(t *testing.T) {
    result, err := api.Calculate("2+2")
    if err != nil || result != 4 {
        t.Errorf("Expected 4, got %v", result)
    }
}

func TestDivisionByZero(t *testing.T) {
    _, err := api.Calculate("5/0")
    if err == nil {
        t.Errorf("Expected error for division by zero")
    }
}

When I refactored internal code, tests caught regressions immediately. Because the API serves both interfaces, testing it once covers both the GUI and CLI.

Lesson 8: Test through your public API.

Error Handling: Graceful Failure

A calculator that crashes on invalid input is useless. Every edge case was anticipated:

Division by zero returns an error

Invalid decimals are handled

Consecutive operators are validated

Empty calculations default to zero

The calculator state remains consistent even after errors, whether accessed through the GUI or CLI.

Lesson 9: Users will find creative ways to break your software. Handle it gracefully.
The Development Lifecycle

This project followed the full software lifecycle:

Requirements gathering

Architecture design

API-first implementation

Building both interfaces against the same API

Testing and refactoring

Documentation

Release

Each phase taught something valuable.

Lesson 10: Building software is about understanding problems, not just writing code.
The Big Picture

The API layer transformed my calculator from a single application into a platform serving both a graphical interface and a command-line interface. It enables consistent behavior across interfaces, comprehensive testing, and easy addition of future clients. Each layer does one thing well, and they all work together seamlessly.

Lesson 11: Think platform, not application.
Key Takeaways

Start with requirements to prevent scope creep

Architect for change with clean separation of concerns

Build an API layer first even with multiple interfaces

Design for multiple interfaces so business logic remains interface-agnostic

Build once, use everywhere by sharing logic through the API

Know your standard library for perfect data structures

Understand UI composition to break free from defaults

Test through your public API for fearless refactoring

Handle errors gracefully because users break things

Document decisions for your future self

Embrace the full lifecycle as each phase teaches something

Keep APIs simple while implementation handles complexity

Build security in from day one with validation, recovery, and audit trails

Think platform, not application for maximum re-usability

A calculator seems simple, but building one properly touches on every aspect of software engineering. It is the perfect project for learning industry best practices without overwhelming complexity.

The API layer was the unexpected hero. It forced me to think about my software as a platform serving multiple interfaces, made security foundational, simplified testing, and kept both the GUI and CLI beautifully ignorant of underlying complexity.

If you want to level up your skills, build something simple the right way. Start with requirements, design the API first, then build your interfaces against it. You will be surprised how much you learn.

Happy coding!

Thuku Samuel is a software engineer passionate about clean code and Go programming.