Forem: Fred

Solana Passkeys on the Web (No Extension Required)

Fred — Mon, 12 Jan 2026 19:46:12 +0000

Passkeys are the most important UX upgrade for wallets since mobile. Instead of seed phrases and browser extensions, users authenticate with the same biometrics they already use every day: Face ID, Touch ID, or Windows Hello.

This post walks through a minimal Vite + React demo that uses the LazorKit SDK to:

Create a passkey-based smart wallet
Display the wallet address
Send a standard SOL transfer on devnet

This is an example demo, not a full product. LazorKit is pre-audit—don’t use it in production.

Why passkeys for Solana

Traditional wallets require users to:

Install a third‑party extension or app
Save (and never lose) a seed phrase
Jump through popups and approvals

Passkeys flip this flow:

The private key stays in secure hardware (device enclave)
Users authenticate with biometrics
The browser handles the UX

That’s the closest we have to “Web2 login” on-chain.

What we’re building

A single-page demo with three sections:

Passkey connect (create or restore)
Airdrop (optional devnet funding)
SOL transfer (standard tx, signed by passkey)

Everything is intentionally small and readable.

Core idea: wrap your app in LazorKit

The provider handles the passkey flow and smart wallet management.

import { LazorkitProvider } from '@lazorkit/wallet';

export default function App() {
  return (
    <LazorkitProvider
      rpcUrl="https://api.devnet.solana.com"
      portalUrl="https://portal.lazor.sh"
    >
      <YourApp />
    </LazorkitProvider>
  );
}

From here, you can use the useWallet hook anywhere.

Passkey connect flow

import { useWallet } from '@lazorkit/wallet';

export function ConnectButton() {
  const { connect, disconnect, isConnected, wallet } = useWallet();

  if (isConnected && wallet) {
    return <button onClick={() => disconnect()}>Disconnect</button>;
  }

  return <button onClick={() => connect({ feeMode: 'paymaster' })}>Connect</button>;
}

When connect() runs, the browser prompts for passkey creation or authentication. No seed phrase, no extension.

Sending SOL (standard transaction)

import { useWallet } from '@lazorkit/wallet';
import { SystemProgram, PublicKey, LAMPORTS_PER_SOL } from '@solana/web3.js';

const { signAndSendTransaction, smartWalletPubkey } = useWallet();

const destination = new PublicKey('RECIPIENT_ADDRESS');
const instruction = SystemProgram.transfer({
  fromPubkey: smartWalletPubkey,
  toPubkey: destination,
  lamports: 0.01 * LAMPORTS_PER_SOL
});

const signature = await signAndSendTransaction({
  instructions: [instruction]
});

This is a regular devnet transfer. It requires SOL for fees. (Paymaster support is optional and not included in this demo.)

What the demo includes

Passkey connect + disconnect
Smart wallet address display
Copy‑to‑clipboard for wallet address
Recipient input with .env default
Optional devnet airdrop button
Readable docs + tutorials

How to run it

npm install
cp .env.example .env
npm run dev

Then open the Vite URL and click Connect Passkey Wallet.

Repo structure (high‑level)

src/
  components/
    ConnectButton.jsx
    AirdropButton.jsx
    TransferButton.jsx
    StatusPanel.jsx
  lib/config.js
  App.jsx
  main.jsx

What’s next

This demo is intentionally minimal. Some easy next steps:

Add SPL token transfers (USDC)
Integrate a swap aggregator (e.g., Jupiter)
Add session management or device recovery UX

References

LazorKit Docs: https://docs.lazorkit.com/
LazorKit GitHub: https://github.com/lazor-kit/lazor-kit
Repo Github : https://github.com/FredMunene/sollaz

If you’re building Solana UX in 2026, passkeys aren’t optional anymore; they’re the baseline.

Beating GitHub API Limits on Static Hosting with Caching

Fred — Wed, 24 Sep 2025 09:27:15 +0000

When I first built my projects page, I pulled data directly from the GitHub API. It worked fine locally, but once I deployed it to a static hosting platform, a problem appeared: API rate limits.

GitHub’s API only allows a limited number of unauthenticated requests per hour. On static hosting (like GitHub Pages), there’s no server-side environment to hide API keys or manage authentication. This meant that every visitor’s browser hit the GitHub API directly. A few visitors were enough to exhaust the limit and break the project feed.

This challenge made me rethink the architecture. Instead of relying on live API calls, I built a static JSON caching system:

A Node.js script (update-projects.js) fetches repositories from the GitHub API. The data is saved to static/projects.json.
The frontend loads data from this JSON file instead of calling the API.

To keep the data fresh, I added a GitHub Actions workflow that:

Runs every Monday at midnight UTC.
Fetches the latest repositories.
Updates static/projects.json only if changes are detected.

Commits and pushes updates back to the repo, which triggers redeployment.

This approach gives me the best of both worlds:

Fast, reliable static hosting without API failures.
Fresh data automatically updated on schedule.
Zero risk of hitting API limits for visitors.

What started as a limitation turned into a neat solution that blends static hosting with automation.
Check out my portfolio gitongacode.co.ke

Understanding ERC-4337 Through Gasless USDC Transfers: A Beginner-Friendly Guide

Fred — Sat, 26 Jul 2025 17:40:16 +0000

Account abstraction has been a hot topic in Ethereum development for years, and ERC-4337 finally brought it to life.
If you've ever struggled to send USDC or USDT because you lacked just a bit of ETH for gas fees, you're not alone — and ERC-4337 is part of the solution.

If I got a cent every time I asked a friend for ETH just to send a stablecoin, I’d probably have ten dollars by now.

The Frustration: Gas Fees & ETH Dependency

Let’s say you’re holding only USDT in your wallet. You want to send it to a friend. But wait, you need ETH for gas. Suddenly, you’re scrambling to:

Bridge or buy ETH
Beg friends for a top-up
Or worse, use a centralized exchange,cmon😖

This UX is not friendly, especially for everyday users or newcomers. The requirement to hold a second token (ETH) just to use your actual token (USDT/USDC) feels broken.

Enter ERC-4337: Account Abstraction in Practice

Buzzword : Account Abstraction
The truth is when users interact with a blockchain, it will feel confusing, messy, and a little intimidating. They are dealing with long wallet addresses, strange gas fees, and weird signing messages that make them hesitate.

That’s where account abstraction comes in. Think of it like a user-friendly cover that hides all the complicated parts behind the scenes. It turns Ethereum from something that feels like programming into something as easy as sending an SMS.

ERC-4337 brings "smart accounts" to wallets, allowing wallets to function like smart contracts with custom logic.

What that means:

Anyone can sponsor your transaction fees (via “bundlers” and “paymasters”).
Fees can be paid in tokens other than ETH — including USDC, USDT, DAI, or even loyalty points.
Multisig, social recovery, time locks, and more — all baked into your wallet logic.(other cool stuffs)

The technical magic:

ERC-4337 introduces a new transaction flow called UserOperations. Instead of regular msg.sender transactions, wallets now submit operation requests to a Bundler, which packages and submits them on-chain. These are verified and executed using a smart contract wallet.

What You Can Do Now

You can send USDC without needing ETH, because a Paymaster covers the gas.
Check out Base. It lets people transact using stablecoins like USDC without ever needing ETH for gas. You can log in with your email, batch actions into a single click, and even have the app cover gas fees, all designed to make using Ethereum as easy as using any Web2 app.

Have you tried using a smart wallet with gasless USDC transactions? Or are you still pinging friends for ETH like it’s 2019? Let’s talk

Getting Started with Smart Contracts on Polkadot: A Guide to Ink

Fred — Mon, 14 Jul 2025 13:31:06 +0000

Introduction

In this tutorial, we’ll walk through deploying a smart contract written in ink! (Rust-based smart contract language) using the use.ink UI playground. We’ll also set up and connect our wallet using the Polkadot.js extension to sign transactions and deploy the contract to a test network.
You can check out my article on deploying smart contracts locally here.

Prerequisites

Before we start, make sure you have:

Rust installed since we will compile locally.
A modern browser (I’ll be using Firefox).
The Polkadot.js extension installed.
Some test tokens (usually on a testnet) Claim here.

Setting Up Polkadot.js Extension

Install the extension Download it from Mozilla Add-ons or Chrome Web Store.
Create a wallet
- Open the extension.
- Click “+” to create a new account.
- Save your seed phrase securely (very important!).
- Give your account a recognizable name.
Get test tokens
Depending on which network you're deploying to (e.g., PassetHub), you might need some test tokens. You can request them from a faucet.
Verify connection
Visit Polkadot.js Apps to make sure your account shows up.

Writing or Uploading Your Contract on use.ink

Visit use.ink playground:
Upload your compiled .contract file
You can interact with your smart contract after following through the steps and instantiating.
Final results:

Troubleshooting

1. `AccountUnmapped`

Example error:

AccountUnmapped
An `AccountID32` account tried to interact with the pallet without having a mapping.Call [`Pallet::map_account`] in order to create a mapping for the account.

Mapping simply means linking your wallet account to the on-chain account system so it can interact with smart contracts and pallets properly. It does not create a new address — it just registers it on-chain.

Solution

Visit the polkadot developer page here.
Change the network on the far left!

Change to test paseo and choose PassetHub- contracts : via IBP1.
Go to Developer section, then Intrinsics. - In the submit the following extrinsic field, select revive and mapAccount() as appropriate and submit.

2. `Polkadot extension doesn't connect on the Polkadot site or use.ink site`

The wallet extension is not connecting by default, no worries!

Solution

Access the polkadot extension.
Click on Connect Accounts and confirm in the popup.
Refresh the page.

Conclusion

Deploying ink! smart contracts using use.ink and Polkadot.js is now easier than ever. By following these steps, you can quickly upload, deploy, and interact with your contracts on a test network.

Always remember to use test tokens first, and verify your wallet connection to avoid common errors like AccountUnmapped.

Solving the Two Sum Problem in Rust: Brute Force vs HashMap

Fred — Thu, 24 Apr 2025 10:52:41 +0000

I’ve been diving into Rust and decided to challenge myself with some LeetCode problems. One of the first ones I tackled was the classic Two Sum problem — and, it turned out to be a great way to practice Rust basics like iterating over vectors and using HashMap.

In this post, I’ll walk you through how I approached the problem first with a brute-force solution, and then optimized it using a hash map. I’ll also break down what “time complexity” really means as we go.

The Problem

You're given an array of integers nums and a target integer target. Your task is to:
Return the indices of the two numbers such that they add up to the target.

Constraints:

Each input has exactly one solution.
You can’t use the same element twice.
You can return the answer in any order.

🧠 First Attempt: Brute Force

Here’s what I started with. Just loop through the list twice and try every possible pair of numbers:
src/lib.rs

pub fn two_sum(nums: Vec<i32>, target: i32) -> Vec<i32> {
    // Loop through each number with index i and value c
    for (i, c) in nums.iter().enumerate() {
        // Loop again for every possible pair
        for (j, c2) in nums.iter().enumerate() {
            // If indices are different and values add up to target, return them
            if i != j && c + c2 == target {
                return vec![i as i32, j as i32];
            }
        }
    }
    vec![] // Return empty vector if no pair is found 
}

⏱️ Time Complexity: `O(n²)`

This means if the list has:

10 numbers → ~100 comparisons,
1,000 numbers → ~1,000,000 comparisons.

Why? Because for each number in the list, I’m looping through the entire list again to check all combinations. That’s n times n, which is n².

Space Complexity: `O(1)`

I’m not storing any extra data structures, so the space stays constant, no matter how big the input is.

The Better Way: HashMap

The brute-force worked, but it wasn’t efficient — especially with larger inputs.
So I decided to use a HashMap to improve performance. Here’s the idea:

While looping through the list, I check if the “complement” of the current number (i.e., target - current number) has already been seen.
If it has, we’ve found our pair.
Otherwise, I add the number and its index to the map.

src/lib.rs

use std::collections::HashMap;

pub fn two_sum_hashmap(nums: Vec<i32>, target: i32) -> Vec<i32> {
    let mut map = HashMap::new(); // Create a HashMap to store number -> index

    for (i, c) in nums.iter().enumerate() {
        let complement = target - c; // Calculate the number we need to complete the target

        // Check if we already saw the complement before
        if let Some(&j) = map.get(&complement) {
            return vec![j, i as i32]; // If found, return the stored index and current index
        }

        // Otherwise, insert current number and index into the map
        map.insert(c, i as i32);
    }

    vec![] // Return empty vector if no solution found (shouldn't happen)
}

⏱️ Time Complexity: `O(n)`

Only one loop. For each number, we do a constant-time HashMap lookup. So the number of operations grows linearly with the input size.

10 numbers → 10 operations
1,000 numbers → 1,000 operations

Way faster than the brute-force approach.

Space Complexity: `O(n)`

We use a HashMap that stores up to n items — one for each number in the list.

✅ Tests to Make Sure It Works

I wrote some basic tests to make sure both versions work correctly:
src/lib.rs

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_two_sum() {
        let nums = vec![2, 7, 11, 15];
        let target = 9;
        let result = two_sum(nums, target);
        assert_eq!(result, vec![0, 1]); // 2 + 7 = 9
    }

    #[test]
    fn test_two_sum_hashmap() {
        let nums = vec![3, 2, 4];
        let target = 6;
        let result = two_sum_hashmap(nums, target);
        assert_eq!(result, vec![1, 2]); // 2 + 4 = 6
    }
}

Final Thoughts

Both versions solve the problem correctly — the brute-force is simple and clear, while the HashMapversion is more efficient and scalable.

Nested loops are easy to write, but expensive in terms of performance.
HashMaps are your best friend when you need fast lookups.
Rust’s enumerate, iter, and HashMap are powerful once you get used to the syntax.

🔁 Use brute-force for learning, but aim for the HashMap solution in interviews or production code.

This exercise helped me practice both problem-solving and writing idiomatic Rust. If you’re also learning Rust and using LeetCode to improve, I’d love to hear how you’re approaching these problems!

Building a Super Cool Contact Form That Actually Sends Emails 🚀✉️

Fred — Wed, 20 Nov 2024 22:23:13 +0000

Hey there, web dev enthusiasts! Ever wanted to create a contact form that doesn't just sit there looking pretty, but actually sends emails? Buckle up, because I'm about to show you how to build a contact form that'll make your portfolio website feel like a pro communication machine!

Prerequisites

A sprinkle of Javascript magic
A Gmail account. (because who doesn't have one?)
Node.js and npm installed. Install here.

Step 1: Project Setup

Let’s start by creating a new Node.js project.
Type below on your terminal and run:

mkdir email-form-project
cd email-form-project
npm init -y

Next, we grab some necessary dependencies:

npm install express nodemailer body-parser multer dotenv

We'll check out what each one individually handles.

Step 2: The Secret Sauce- `.env` File

Time to keep our secrets.. secret!We store our email credentials in an .env file. This keeps sensitive data, like your Gmail credentials, out of the light, like a digital ninja.

EMAIL_USER=your-email@gmail.com
EMAIL_PASS=your-app-password

Set environment variables in the file .env for Email and App Password . I used Google App passwords. Read about it here.

Step 3: Create the Server in `server.js`

We’ll set up an Express server and configure the route that handles form submissions. Inside server.js add this code:

require("dotenv").config(); // module to load environment variables from .env file
const express = require("express"); // express is a webframework for Node.js
const nodemailer = require("nodemailer"); // nodemailer is  a module to send emails
const bodyParser = require("body-parser"); // middleware to parse incoming request bodies
const path = require("path"); // handle file and directory paths
const multer = require("multer"); // middleware to manage form data

const app = express();
const upload = multer();

app.use(express.json());
app.use(bodyParser.urlencoded({ extended: true }));
app.use(upload.none());

express.json() : parses incoming requests with JSON payloads.
bodyParser.urlencoded({ extended: true }): parses URL-encoded data(tyically used in HTML forms).
upload.none(): tells muter not to handle file uploads in the form, since there no file attachments.

// Serve the index.html file
app.get("/", (req, res) => {
  res.sendFile(path.join(__dirname, "index.html"));
});

// Serve static files from the "static" folder
// Uncomment below code if you include css files, and images in your static folder
// app.use("/static", express.static("static"));

// Setting up Nodemailer Transporter
const transporter = nodemailer.createTransport({
  host: "smtp.gmail.com", 
  port: 587, // specific port for non-secure SMTP communication
  secure: false,
  auth: {
    user: process.env.EMAIL_USER,
    pass: process.env.EMAIL_PASS,
  },
});

// Handling POST requests and Sending emails
app.post("/submit", async (req, res) => {
  const { name, email, subject, message } = req.body;

  try {
    const info = await transporter.sendMail({
      from: `"${name}" <${email}>`,
      to: `"your-name" <your-name@gmail.com>`, // Your target email address
      subject: subject,
      text: message,
      html: `<b>${message}</b>`,
      replyTo: `"${name}" <${email}>`,
    });
    console.log("Message sent: %s", info.messageId);
    res.status(200).send("Email sent successfully!");
  } catch (error) {
    console.error("Error sending email: ", error);
    res.status(500).send("Failed to send email");
  }
});

transporter.sendMail() is an asynchronous operation that could take some time. It behaves like a super-efficient assistant who can handle time-consuming tasks without making everything else wait in line!
More about async/await here.

// Starting the Express Server
const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

This sets up a simple Express server that:

Serves an HTML form, accepts form submissions via a POST request.
Uses Nodemailer to send the form data as an email to a specified address.

Step 4: The HTML Form in index.html

Create an html form for our users to input their contact details.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Email Form</title>
</head>
<body>
  <h1>Contact Us</h1>
  <form action="/submit" method="POST">
    <label for="name">Name:</label>
    <input type="text" id="name" name="name" required><br><br>

    <label for="email">Email:</label>
    <input type="email" id="email" name="email" required><br><br>

    <label for="subject">Subject:</label>
    <input type="text" id="subject" name="subject" required><br><br>

    <label for="message">Message:</label><br>
    <textarea id="message" name="message" rows="4" required></textarea><br><br>

    <button type="submit">Send Message</button>
  </form>
</body>
</html>

A snippet of what our HTML code looks like on a browser:

Time to Test! 🕹️

Run below commands in your terminal:

node server.js

Open http://localhost:3000/ and BAM!. 💥 Your contact form is ready to send emails like a communication superhero!

Pro Tips

Always use app passwords for Gmail
Keep your .env file top-secret (add it to .gitignore)
Test, test, and test again!

Ready to level up your portfolio website? Go forth and communicate! 🚀📧
Catch the full project on my GitHub: Project Link
Want to see it in action? Check out my portfolio: www.gitongacode.co.ke

Building a Simple RESTful API in Go for Managing Blog Posts

Fred — Fri, 08 Nov 2024 02:16:54 +0000

Introduction

We know the best way to learn is to build stuff while learning, so I got into building a RESTful API to manage blog posts. It’s a simple project that lets you create, read, update, and delete posts—basically, the classic CRUD operations. I chose Go because I'm familiar with it,😂😂😎😂! It's a great language for this kind of project, and it makes the whole process smoother since I already know my way around it. Plus, Go’s performance is top-notch, which makes it perfect for handling API requests quickly.

1. Overview

In this tutorial, we’ll walk through the entire process of creating a simple RESTful API in Go to manage blog posts. The API will allow us to perform the basic CRUD operations: Create, Read, Update, and Delete posts. We'll structure the application with a few simple files to keep things clear.

2. Our Entry Point

FILE: main.go

package main

import (
    "log"
    "net/http"

    "your_project/route" // import your route package
)

func main() {
    r := route.NewRouter() // initialize the router
    log.Fatal(http.ListenAndServe(":8080", r)) // start the server
}

In this file, we set up the HTTP server and the routes using the mux router. The server listens on port 8080, and we define all the routes inside the route.NewRouter() function.

3. Post Model

FILE: model.go

package model

type Post struct {
    Title   string
    Content string
    Tags    []string
    Author   string
}

This Post struct is our model, which represents a blog post. It contains fields for Title, Content, Tags, and Author. Each post will be stored in memory with these fields.

4. Setting Up Routes for CRUD Operations

FILE: route.go

package route

import (
    "github.com/gorilla/mux"

    "your_project/handler"
    "your_project/middleware"
)

func NewRouter() *mux.Router {
    r := mux.NewRouter()
// create a post
    r.HandleFunc("/create", handler.CreatePost).Methods("POST")
// list the titles of all posts
    r.HandleFunc("/list", handler.ListPosts).Methods("GET")
// get a post by the post title
    r.HandleFunc("/post", handler.GetPostByTitle).Methods("GET")
// edit a post
    r.HandleFunc("/edit", handler.UpdatePost).Methods("PUT")
// delete a blog post
    r.HandleFunc("/delete", middleware.RequireAuth(handler.DeletePost)).Methods("DELETE")
    return r
}

Here, we define all the routes for the CRUD operations:

Create Post: POST /create
List All Posts: GET /posts
Get Post by Title: GET /blogs
Update Post: PUT /edit
Delete Post: DELETE /delete

5. Implementing the Handlers

FILE: handler.go

package handler

import (
    "encoding/json"
    "fmt"
    "net/http"

    "your_project/model"
)
// a in-built memory database to store and retrieve our posts.
var allPosts = make(map[string]model.Post)

Create Post(POST)

func CreatePost(w http.ResponseWriter, r *http.Request) {
    var post model.Post
    // read content from request body into a new decoder
    decoder := json.NewDecoder(r.Body)
    // decode content into our Post struct
    err := decoder.Decode(&post)
    if err != nil {
        http.Error(w, "Failed to decode request body", http.StatusInternalServerError)
        return
    }
    // check for unique post title
    _, ok := allPosts[post.Title]
    if ok {
        http.Error(w, "Post title already exists", http.StatusBadRequest)
        return
    }

    // append post to our memory
    allPosts[post.Title] = post

    // prints out structs with field names
    fmt.Fprintf(w, "%+v", post)
}

Get Post(GET)

func ListPosts(w http.ResponseWriter, r *http.Request) {
    titles := []string{}

    for _, post := range allPosts {
        titles = append(titles, post.Title)
    }

    if len(titles) == 0 {
        http.Error(w, "no posts found", http.StatusNotFound)
    }

    json.NewEncoder(w).Encode(titles)
    // uncomment to print out structs with field names
    // fmt.Fprintf(w,"%+v",titles)
}

Get Post by Title(GET)

func GetPostByTitle(w http.ResponseWriter, r *http.Request) {
    // retrieve title of post
    title := r.URL.Query().Get("title")
    if title == "" {
        http.Error(w, "Title is required", http.StatusBadRequest)
        return
    }

    // check title is present
    post, ok := allPosts[title]
    if !ok {
        http.Error(w, "Post not found", http.StatusNotFound)
        return

    }

    // encode the contents
    if err := json.NewEncoder(w).Encode(post); err != nil {
        http.Error(w, "Post not found", http.StatusInternalServerError)
        return
    }
}

Update Post(PUT)

func UpdatePost(w http.ResponseWriter, r *http.Request) {
    // get title
    // check title is provided
    title := r.URL.Query().Get("title")
    if title == "" {
        http.Error(w, "Title is required", http.StatusBadRequest)
        return
    }

    // check if such post exists
    post, ok := allPosts[title]
    if !ok {
        http.Error(w, "BlogPost not found", http.StatusNotFound)
        return
    }
var updatedPost model.Post

    // read request body
    if err := json.NewDecoder(r.Body).Decode(&updatedPost); err != nil {
        http.Error(w, "Failed to decode request body", http.StatusBadRequest)
        return
    }

    // update post
    allPosts[title] = updatedPost
    post = updatedPost

    // return ok status
    w.WriteHeader(http.StatusOK)

    // return updated content
    json.NewEncoder(w).Encode(post)


}

Delete Post(Delete)

func DeletePost(w http.ResponseWriter, r *http.Request) {
    title := r.URL.Query().Get("title")

    // retrieve post
    _, ok := allPosts[title]
    if !ok {
        http.Error(w, "No post with such title", http.StatusNotFound)
    }
       // deletes the post from the map.
    delete(allPosts, title)

    w.WriteHeader(http.StatusOK)
}

These handler functions handle the logic for each CRUD operation. They read the request body (for POST and PUT requests), interact with the in-memory database (allPosts), and send responses accordingly.

6. Middleware (Authentication)

FILE: auth.go

package middleware

import "net/http"

func RequireAuth(f http.HandlerFunc) http.HandlerFunc {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // check if user is authenticated
        token := r.Header.Get("Authorization")
        if token != "Bearer Secret" {
            http.Error(w,"Unathorized", http.StatusUnauthorized)
            return
        }
        f.ServeHTTP(w,r)
    })
}

This middleware function checks for a valid Authorization header. If the token isn’t Bearer Secret, it returns an unauthorized response.

7.Run the Aplication

Run the following commands to initialize and tidy up dependencies:
run to install.

cd your_project
go mod init your_project
go mod tidy

8. Testing our API

Once the API is up and running, you can test the endpoints using curl commands.

Run the server:

go run main.go

Using `curl`

Then, in another terminal window, use curl to test:

Create Post:

curl -X POST -H "Content-Type: application/json" -d '{"title":"My First Post", "content":"This is the content.", "author":"John Doe"}' http://localhost:8080/create

Get Post by Post Title:

curl -X GET 'http://localhost:8080/post?title=My%20First%20Post'

Get All Posts Titles:

curl http://localhost:8080/list

Update Post

curl -X PUT -H "Content-Type: application/json" -d '{"Title":"My First Post", "Content":"Updated content.", "Author":"John Doe"}' 'http://localhost:8080/edit?title=My%20Blog%20Post'

Delete Post

curl -X DELETE -H "Authorization: Bearer Secret" 'http://localhost:8080/delete?title=My%20First%20Post'

Using `Thunder Client`

Thunder Client is a lightweight and powerful API testing tool, typically used within Visual Studio Code (VS Code). It offers a user-friendly interface to make API requests.

Check out how to use Thunder Client to make API requests :

Conclusion

And there you have it—your very own RESTful API for managing blog posts, built with the power of Go! 🚀. From creating posts to updating, deleting, and viewing them.
But wait—Want to add user authentication, store data in a database, or make your API even more scalable? Go for it! 🔥

Pointers in Go Explained

Fred — Thu, 31 Oct 2024 21:45:49 +0000

If you’re new to Go or programming in general, you may have come across pointers and felt a bit intimidated. I’ve been there! When I first encountered pointers, I saw the ampersand (&) and asterisk (*) symbols and instantly thought, What is happening here?

In this post, we’re going to break down pointers with a simple analogy and see how they work in Go. By the end, you’ll understand what pointers do and why they’re powerful tools in programming.

What are Pointers?

Imagine you’re looking at a map that shows the addresses of houses. Each house has an address, but that address doesn’t tell you anything about what’s inside the house—only where it’s located. In programming, variables are like those houses: each one has a memory address, where its data is stored.

A pointer holds the address of a variable, not the actual data inside the variable. It’s like writing down the address of a house so you can find it later.

So, What is a Variable?

A variable is the named spot in memory where data is stored. You can think of it as a specific house with a unique address on our map.
We use variables names because they are easy for us to remember, while memory addresses are often n hexadecimal form like 0x564B4.

package main

import "fmt"

func main(){
    var balance int = 35
    fmt.Println("Age:",age)  //Output the value of balance
    fmt.Println("Memory Address:", &age)//Output the address of balance
}

balance is a variable, that holds the value 35
&balance is the memory address of balance. which Go represents as a hexadecimal numbers like 0x50C

Working with Pointers in Go

In Go, you use the ampersand (&) to get the address of a variable, and the asterisk (*) to access the value at that address.

1.Declaring a Pointer

You can create a pointer that points to an address of a variable. Here's how:

package main

import "fmt"

func main() {
    balance := 35             // Our variable
    balancePtr := &balance        // Pointer to the memory address of balance

    fmt.Println("Balance:", balance)             // 35
    fmt.Println("Pointer:", balancePtr)      // Memory address of balance (e.g., 0x50C)
    fmt.Println("Value at Pointer:", *balancePtr) // 35, value at that address
}

Breakdown:

balance := 35 creates an integer variable with a value of 35.
balancePtr := &balance creates a pointer balancePtr that holds the address of balance.
*balancePtr lets us access the value stored at balancePtr's address, which is 35.

Why Use Pointers?

Pointers allow you to work with data directly in memory, without making copies. This is useful for larger data structures or when modifying data across functions.

Example of a function that modifies a variable's value:

package main

import "fmt"

func updateBalance(balancePtr *int) {
    *balancePtr = 40  // Change the value at the address
}

func main() {
    balance := 35
    fmt.Println("Before:", balance) // 35

    updateBalance(&balance)  // Pass the address of balance to the function
    fmt.Println("After:", balance)  // 40, since updateBalance modified the value directly
}

The breakdown:

updateBalance takes a pointer balancePtr as a parameter.
*balancePtr = 40 changes the value at memory held by balancePtr.
In main, when we pass &balance to updateBalance, updateBalance directly changes balance's value without returning anything.

Key Points

Pointer store memory addresses, not values.
& gives you the address of a variable.
* allows you to access the value at an address.
Pass by reference: By passing pointers to functions(as parameters), you can modify variables directly without returning them.

The End

Pointers may feel strange at first, but they become second nature with practice. Using pointers efficiently can improve memory usage and program performance.Understanding pointers will make you a stronger Go developer and give you more control over how data flows in your programs.

Errors are Values: A Guide to Error Handling in Go

Fred — Wed, 23 Oct 2024 22:48:25 +0000

"Errors are values" embodies a core design philosophy in Go's error handling system, setting it apart from many other languages.

Imagine a car:
Other languages(Exception-Based): A car's engine suddenly explodes, and the car stops immediately. You have no choice but to address the engine problem before you can proceed.
Go(Error as Value): A car's low fuel light comes on, but the engine keeps running. You can make a choice: stop for gas, or try to reach a gas station. The car's performance is impacted, but you can control your options.

Why Go Rocks:

Control: You, as the developer, have total control over how errors are handled, preventing code execution from crashing abruptly.
Explicit Decisions: Every error is explicitly checked. You are forced to consider what actions should be taken (try again, log it, recover or exit).
Simple and Elegant: Error values fit within Go's clean syntax and contribute to clean code.

1. The `error` Type

In go, errors are represented using the built-in error type.
It is an interface with a single method.

Example:

type error interface {
    Error() string
}

Any type that implements the Error() method qualifies as an error.

2. Custom Errors

fmt.Errorf is used to create an error. The function may return both the result and the error.The error message should start with small caps.

Example:

package main

import (
    "fmt"
)

func divide(a, b int) (int, error) {
    if b == 0 {
        return 0, fmt.Errorf("cannot divide %d by %d", a, b)
    }
    return a / b, nil
}

3. Handling Errors

When the function returns two values(result, err), you can explicitly check the second value; err != nil and if there's an error, you can handle it.

Example:

package main

import (
    "fmt"
)

func main() {
    result, err := divide(10, 0)
    if err != nil {
        fmt.Println("Error:", err)
    } else {
        fmt.Println("Result:", result)
    }
}

4. Custom Error Types

You can create a custom error by defining a struct that implements the error interface. Learn about interfaces here

Example:

package main

import (
    "fmt"
)

type DivideByZeroError struct {
    message string
}

func (e *DivideByZeroError) Error() string{
    return e.Message
}

func customDivide(a, b int) (int, error) {
    if b == 0 {
        return 0, &DivideByZeroError{"cannot divide by zero"}
    }
    return a / b, nil
}

5. Wrapping and Unwrapping Errors

Since release of Go 1.13, the errors package provides utilities for wrapping and unwrapping errors, enabling adding more context to errors.

fmt.Errorf is used with %w to wrap the original error for context.
errors.Unwrap extracts the original error wrapped with another error.

Example:

package main

import (
    "fmt"
    "errors"
)

func openFile(filename string) error {
    return fmt.Errorf("openFile: failed to read file %s: %w",filename, errors.New("file not found"))
}

func main() {
    err := openFile("test.txt")
    if err != nil {
        if unwrappedErr := errors.Unwrap(err); unwrappedErr != nil {
            fmt.Println("Original error:", unwrappedErr)
        }
        fmt.Println("Error:", err)
    }
}

6. Panic

You can handle severe errors using panic. This is for unexpected situations that your program cannot recover from. When a function panics, it stops execution and begins unwinding the stack, running deferred functions in reverse order.

Example:

package main

import "fmt"

func doPanic() {
    panic("something went wrong")
}

func main() {
    fmt.Println("Starting...")
    doPanic()
    fmt.Println("This will never be printed")
}

7. Handling Panic

You can recover from a panic by using defer and recover.

Defer : The defer keyword schedules a function to be executed after the surrounding function returns, or in case of a panic, before the stack unwinds. Deferred functions clean up resources or handle any final tasks.

Example:

package main

import "fmt"

func cleanup() {
    fmt.Println("Clean up done.")
}

func riskyOperation() {
    defer cleanup()
    panic("Something went wrong")
}

func main() {
    riskyOperation()
    fmt.Println("Main finished")  // This will not be printed because of the panic
}

In this example, the cleanup function is deferred and will run before the program crashes, but the "Main finished" message will never be printed because the panic stops the normal flow.

Recover: recover is used to catch a panic and prevent it from terminating the program. It is typically used in a deferred function.

Example:

package main

import "fmt"

func riskyOperation() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r)
        }
    }()
    panic("A critical failure")
}

func main() {
    riskyOperation()
    fmt.Println("Main continues normally after recovering from panic")
}

In this case, the recover function catches the panic and the program can continue running after the panic.

8. Error Handling Best Practices:

Always check for errors: In Go, ignoring errors is possible but discouraged.
Return wrapped errors for context: This helps in debugging by providing more detail about the error path.
Avoid using panic for regular error handling: It's better to return errors using the error type and let the caller decide how to handle them.
Libraries should not use panic for expected errors: Instead, they should return error values, allowing the client code to handle them.

Conclusion

Go's error handling approach helps developers like you write reliable and easy-to-maintain programs. It gives you the flexibility to manage errors in a way that fits your application, leading to clearer and more robust code.

My TDD Journey: How It Saved My Go Code (and My Sanity!)

Fred — Wed, 25 Sep 2024 14:27:15 +0000

What is it Really?

Test Driven Development (TDD) is basically a safety net for your code. It makes sure the code does what you want it to do (intention).
Plus, it helps keep your code clean and organized, so it doesn't turn into a chaotic mess.
I got to talk about TDD with a bunch of cool Go devs at the Gophers Kisumu meetup on 21st September. It was awesome to see so many people interested in it, and we had some great discussions about how it can help you write better code.

How simple is it?

TDD is a cyclic process of three main steps: Red, Green, and Refactor. You start by writing a test for a new feature before writing the code that implements it.

Red: Write a failing test.
Green: Write just enough code to pass the test.
Refactor: Improve the code while keeping all tests passing.

See TDD in action

I came up with an engaging example that the audience could relate to: a robot(functionality) that welcomes attendees.

😡
First, you write a little test that makes your code throw its hands up and say 'Nope, can't do that yet!'

package main

import "testing" // the testing package is used to write unit tests

// Note on the naming convention TestXxx, and a *testing.T argument. 
func TestWelcome(t *testing.T) {
    robot := NewRobot()
    greeting := robot.Welcome("Alice")
    expected := "Welcome, Alice"

    if greeting != expected {
        t.Errorf("Expected %s but got %s", expected, greeting)
    }
}

The test will fail😞 because the 'Welcome' method does not yet exist. Here, we have created the need for the functionality we’re about to create.

✅
Then you write just enough code to make your "red" test turn "green.
Drum rolls!!🥁 We create the Welcome method within our Robot struct:

package main

type Robot struct{}

func NewRobot() *Robot {
    return &Robot{}
}

func (r *Robot) Welcome(name string) string {
    return "Welcome, " + name
}

By running the test again, we see it pass, indicating that your implementation meets the specified requirement.
Now, our test ensures that our code serves its intended purpose.

🤖 Refactor
Now for the fun part!😎 You get to clean and refactor your code. But don't forget - all your tests have to keep passing! It's like a coding dance: refactor, test, refactor, test, and so on!

Why you should care about TDD? Let me tell you...

Intent: It makes makes you think clearly about what your code needs to do BEFORE you dive into code.

Better Design: TDD often leads to smaller, more focused functions and classes, as developers must consider how their code interacts with the tests.

Bugs:🐛 By catching issues early through testing, TDD helps create more reliable software and reduces the likelihood of defects in production.

Let's chat about TDD! What are your thoughts?

Forem: Fred

Solana Passkeys on the Web (No Extension Required)

Why passkeys for Solana

What we’re building

Core idea: wrap your app in LazorKit

Passkey connect flow

Sending SOL (standard transaction)

What the demo includes

How to run it

Repo structure (high‑level)

What’s next

References

Beating GitHub API Limits on Static Hosting with Caching

Understanding ERC-4337 Through Gasless USDC Transfers: A Beginner-Friendly Guide

The Frustration: Gas Fees & ETH Dependency

Enter ERC-4337: Account Abstraction in Practice

The technical magic:

What You Can Do Now

Getting Started with Smart Contracts on Polkadot: A Guide to Ink

Introduction

Prerequisites

Setting Up Polkadot.js Extension

Writing or Uploading Your Contract on use.ink

Troubleshooting

1. AccountUnmapped

Solution

2. Polkadot extension doesn't connect on the Polkadot site or use.ink site

Solution

Conclusion

Solving the Two Sum Problem in Rust: Brute Force vs HashMap

The Problem

Constraints:

🧠 First Attempt: Brute Force

⏱️ Time Complexity: O(n²)

Space Complexity: O(1)

The Better Way: HashMap

⏱️ Time Complexity: O(n)

Space Complexity: O(n)

✅ Tests to Make Sure It Works

Final Thoughts

Building a Super Cool Contact Form That Actually Sends Emails 🚀✉️

Prerequisites

Step 1: Project Setup

Step 2: The Secret Sauce- .env File

Step 3: Create the Server in server.js

Step 4: The HTML Form in index.html

Time to Test! 🕹️

Pro Tips

Building a Simple RESTful API in Go for Managing Blog Posts

Introduction

1. Overview

2. Our Entry Point

3. Post Model

4. Setting Up Routes for CRUD Operations

5. Implementing the Handlers

6. Middleware (Authentication)

7.Run the Aplication

8. Testing our API

Using curl

Using Thunder Client

Conclusion

Pointers in Go Explained

What are Pointers?

So, What is a Variable?

Working with Pointers in Go

1.Declaring a Pointer

Why Use Pointers?

Key Points

The End

Errors are Values: A Guide to Error Handling in Go

Why Go Rocks:

1. The error Type

2. Custom Errors

3. Handling Errors

4. Custom Error Types

5. Wrapping and Unwrapping Errors

6. Panic

7. Handling Panic

8. Error Handling Best Practices:

Conclusion

1. `AccountUnmapped`

2. `Polkadot extension doesn't connect on the Polkadot site or use.ink site`

⏱️ Time Complexity: `O(n²)`

Space Complexity: `O(1)`

⏱️ Time Complexity: `O(n)`

Space Complexity: `O(n)`

Step 2: The Secret Sauce- `.env` File

Step 3: Create the Server in `server.js`

Using `curl`

Using `Thunder Client`

1. The `error` Type