Forem: Victor Chigbo

Chess Engine in C #1: The 10x12 Mailbox

Victor Chigbo — Sat, 11 Apr 2026 07:36:05 +0000

While going through the video, I came across this illustration:

So I paused, went further to do some research and discovered that the picture illustrated a 10x12 mailbox board representation. Let's go this rabbit hole together and understand what is going on here.

So What is Board Representation?

Board representation is simply a way for the chess engine to represent the chessboard(of course), the pieces on the board, and their movements. It also helps to track other important pieces of game states like which side to move, castling rights, possible en passant moves, and The Fifty Move amongst others.

There are many ways to represent a chessboard in a chess engine but they can be classified into two types of board representation methods, namely:

Piece-centric Representation: They use an array, list or set to keep track of all the pieces on the chessboard, where they are on the board and other related information. Representation methods under this category include piece lists, piece sets, and bitboards.
Square-centric Representation: This category focuses on the board rather than the pieces. They use arrays to represent the number of squares on the board, and whether it is emptied or occupied(and that's why they are called 'mailboxes'). They are very helpful in determining off-board movements. In this category, you can find 8x8 boards, 10x12 boards, 0x88(16x8) boards, etc.

And of course, they can be mixed together to create better results too.

My Experience

Looking at the code so far, the board representation technique used here employed a combination of the 10x12 mailbox, a bitboard using the 64bit integer and a 13 by 10 piece list. I have not gone far enough to explain the bitboard and the piece list, but I can fully understand how the mailbox works.

It works by encompassing the 64-square board inside a 120-element array(10x12), containing the real chessboard for the engine. There is the possibility of a chess piece going off board, and that is where the extra squares come in. They form a protective border around the chessboard and can be given a value of offBoard, such that when the engine is generating moves and a move goes off the board, the move generation stops there.

A 10X12 Chess Game Grids Offset Representation

The 8x8 chessboard with all 32 pieces on it

If you noticed, there are two extra ranks in the first image. This is because of how the knight moves.

The knight's moves

If there were only one extra rank top and bottom and a knight is at g1, the chess engine won't be able to account for the extra two steps that are placed above or below the single border. That's why there's an extra one. For the horizontal borders, assuming that knight is at h3, the extra steps can go over to the other side.

Code

In order to represent the board, two arrays are needed; one for converting a number from the 120-square board into its 64-board equivalent and vice-versa.

extern int Sq120ToSq64[BOARD_SQ_NUMBER]; // BOARD_SQ_NUMBER = 120
extern int Sq64ToSq120[64];

Then a macro is created to return the 120-based equivalent of a position when it's file and rank are given.

#define FR2SQ(f, r) ( (21 + (f) ) + ( (r) * 10 ) ) // f is file, r is rank

A function will be used to initialize the board and fill the arrays.

void InitSq120ToSq64() {
    int index = 0;
    int file = FILE_A;
    int rank = RANK_1;
    int sq = A1;
    int sq64 = 0;

    for (index = 0; index < BOARD_SQ_NUMBER; ++index) {
        Sq120ToSq64[index] = 65;
    }

    for (index = 0; index < 64;  ++index) {
        Sq64ToSq120[index] = 120;
    }

    for (rank = RANK_1; rank <= RANK_8; ++rank) {
        for (file = FILE_A; file <= FILE_H; ++file) {
            sq = FR2SQ(file, rank);
            Sq120ToSq64[sq] = sq64;
            Sq64ToSq120[sq64] = sq;
            sq64++;
        }
    }
}

First of all, the arrays Sq120ToSq64 and Sq64ToSq120 are filled with the integers 65 and 120 respectively which are impossible values in the games. Then the function runs a nested loop, for each rank, and for each file inside a rank.

The sq is initially set to A1, representing the first file inside the first rank. Using the FR2SQ1 function, the sq is set to the 120-based equivalent of it's position. Basically, if the position is A1, then sq is equal to (21 + 0) + (2 * 0) which is 21. After that, the integer at Sq120toSq64[sq] is set to the value of sq64 and integer at Sq64toSq120[sq64] is set to the value of sq. Then the value of sq64 is increased by 1 and the loop continues until all the files and ranks are iterated.

In the main function of the chess engine, the chess representation technique can be printed on the console like this:

#include <stdio.h>
#include "defs.h"

int Sq120ToSq64[BOARD_SQ_NUMBER];
int Sq64ToSq120[64];

int main() {
    AllInit(); 

    /* int index = 0;

    for (index = 0; index < BOARD_SQ_NUMBER; ++index) {
        if (index % 10 == 0) {
            printf("\n");
        }

        printf("%5d", Sq120ToSq64[index]);
    }

    printf("\n\n");

    for (index = 0; index < 64; ++index) {
        if (index % 8 == 0) {
            printf("\n");
        }

        printf("%5d", Sq64ToSq120[index]);
    }

    return 0;
}

Once you compile and run the whole program, you are going to get this:

As you can see, the console printed out the Sq120ToSq64 array and the Sq64ToSq120 array, each containing the respective values of the chessboard inside the 120 square array, marked from 0 to 63 and it's 120-based equivalent, marked from 21 to 98.

This was a long one 😅, but I believe you were able to learn something new 😊
If you haven't read the previous article, click here so that you can follow along and if you want to see the code, you can click here to view the Github repo.

Until the next commit....bye 👋

Chess Engine in C #0: Intro

Victor Chigbo — Mon, 06 Apr 2026 15:45:45 +0000

This project is something I picked up from Codecrafters' Build Your Own X repository. It's something I want to use to understand low-level and systems programming in C, build my consistency muscle, and just get better at the things I do as a techie.

The project instructions is based a 107-video Youtube playlist, totalling at approximately 15 hours(At the end of this, I'll add the total time I've spent on the project too 😅). I started this project in the early hours of Easter Sunday, 2026, and so far this is what I've learnt from it:

UCI Protocol: UCI stands for Universal Chess Interface and this is a open, text-based communication protocol that enables chess engines
to communicate with GUIs.
Files and Ranks: Files are columns that go up and down the chessboard, and each board has eight of them, labelled from a to h while ranks are rows that go from side to side across the chessboard and are referred to by numbers 1 to 8. Together, they can be used to identify squares on the chessboard and track movements of pieces too. A popular naming convention used in the game of chess is the file-first method, where a square is identified by it's file, then it's rank. For example, the lower right-hand square is h1, which means, 'h-file, first rank'.

Niche Rules

In the second video, there are three niche moves that we have to consider while making the chess engine. They are:
a. Fifty Moves: The fifty-move rule in chess states that a player can claim a draw if no capture has been made and no pawn has been moved in the last fifty moves.
b. Threefold Repetition: The threefold repetition rule states that if a game reaches the same position three times, a draw can be claimed.
c. En Passant: En passant ("in passing") is a special chess pawn capture that occurs when a pawn moves two squares forward from its starting position and lands immediately adjacent to an opponent’s pawn.

So yeah. That's it for now! As always, if you want to see the Github repo, you can click here.

Until the next commit....bye 👋

Java ATM CLI Dev Log #4: Final Entry

Victor Chigbo — Tue, 17 Mar 2026 15:55:58 +0000

So this is the final entry for this project. This will cover the summary and what I've learnt so far from the project. I want to give a big shoutout to Marshall Odii for helping me with fixing the issues I had with the transfer method.

So this project was me taking a step further to learn Java and give myself basics of how financial systems work. Attention to detail is an important skill because you have to be sure of whatever you are doing. If you ever feel sleepy, drowsy or whatever while working on systems like these, the best thing for you to do in order to save yourself from a very big disgrace and loss to leave your laptop and take a nap.

It also opened my eyes to system design and software architecture. The project is obviously a monolith but within it, I applied a Domain-Driven Design to how it is structured and it helps me to navigate through the codebase, especially when I'm debugging it.

As for the fix, this is what he did. Recall how I previously wrote transferCash and makeTransfer in AccountService.java and AccountDAO.java respectively:

// AccountService.java
public static void transferCash(Account sender, Account receiver, double amount) {
        if (sender.getBalance() > amount) {
            double newSenderBalance = sender.getBalance() - amount;
            double newReceiverBalance = receiver.getBalance() + amount;

            boolean isTransactionSuccessful = AccountDAO.makeTransfer(sender.getId(), receiver.getId(), sender.getAccountType(), receiver.getAccountType(), newSenderBalance, newReceiverBalance);

            if(isTransactionSuccessful) {
                System.out.println("Transaction Successful!");
                sender.setBalance(newSenderBalance);
                System.out.println("Withdrawal successful. New balance: $" + sender.getBalance());
                sender.stringifyAccount();
            } else {
                System.out.println("Transaction Failed!");
            }

        } else {
            System.out.println("Insufficient funds.");
        } 
    }

// AccountDAO.java
public static boolean makeTransfer(int senderId, int receiverId, String senderAccountType, String receiverAccountType, double newSenderBalance, double newReceiverBalance) {
        String senderQuery = "UPDATE accounts SET balance = ? WHERE customerId = ? AND accountType = ?";
        String receiverQuery = "UPDATE accounts SET balance = ? WHERE customerId = ? AND accountType = ?";
        boolean isTransactionSuccessful = false;

        try (
            Connection conn = DBHelper.getConnection()) {
            conn.setAutoCommit(false);

            // For the sender account
            try (PreparedStatement senderStmt = conn.prepareStatement(senderQuery);) {
                senderStmt.setDouble(1, newSenderBalance);
                senderStmt.setInt(2, senderId);
                senderStmt.setString(3, senderAccountType);
                int senderRowsAffected = senderStmt.executeUpdate();

                if (senderRowsAffected == 0) {
                    conn.rollback();
                    return false;
                }
            } catch (SQLException e) {
                e.printStackTrace();
                conn.rollback();
                return false;
            }

            // For the receiver account
            try (PreparedStatement receiverStmt = conn.prepareStatement(receiverQuery)) {
                receiverStmt.setDouble(1, newReceiverBalance);
                receiverStmt.setInt(2, receiverId);
                receiverStmt.setString(3, receiverAccountType);
                int receiverRowsAffected = receiverStmt.executeUpdate();

                if (receiverRowsAffected == 0) {
                    conn.rollback();
                    return false;
                }
            } catch (SQLException e) {
                e.printStackTrace();
                conn.rollback();
                return false;
            }


            conn.commit();   
            System.out.println("\nBalance Updated Successfully!");

            isTransactionSuccessful = true;

        } catch (Exception e) {
            e.printStackTrace();

            isTransactionSuccessful = false;
        }

        return isTransactionSuccessful;
    }

This is he what he did:

// AccountService.java (Marshall)
public static void transferCash(Account senderAccount, Account recipientAccount, double amount) {
        // Solution: Validate sender has sufficient balance before attempting transfer
        if (senderAccount.getBalance() < amount) {
            System.out.println("Insufficient funds. Cannot complete transfer.");
            return;
        }

        // Solution: Calculate new balances
        double newSenderBalance = senderAccount.getBalance() - amount;
        double newRecipientBalance = recipientAccount.getBalance() + amount;

        // Solution: Use makeTransfer() which performs both updates in a single transaction
        // This prevents deadlocks that occur when using separate connections
        boolean isTransactionSuccessful = AccountDAO.makeTransfer(
            senderAccount.getId(),
            recipientAccount.getId(),
            senderAccount.getAccountType(),
            recipientAccount.getAccountType(),
            newSenderBalance,
            newRecipientBalance
        );

        if (isTransactionSuccessful) {
            // Solution: Update account objects only after successful database transaction
            senderAccount.setBalance(newSenderBalance);
            recipientAccount.setBalance(newRecipientBalance);

            System.out.println("\nTransfer Successful!");
            System.out.println("Amount transferred: $" + amount);
            System.out.println("\nSender Account:");
            System.out.println(senderAccount.stringifyAccount());
            System.out.println("\nRecipient Account:");
            System.out.println(recipientAccount.stringifyAccount());
        } else {
            System.out.println("Transfer Failed! Please try again.");
        }
    }

// AccountDAO.java (Marshall)
public static boolean makeTransfer(int senderId, int receiverId, String senderAccountType, String receiverAccountType, double newSenderBalance, double newReceiverBalance) {
        String senderQuery = "UPDATE accounts SET balance = ? WHERE customerId = ? AND accountType = ?";
        String receiverQuery = "UPDATE accounts SET balance = ? WHERE customerId = ? AND accountType = ?";
        boolean isTransactionSuccessful = false;

        // Solution: Fixed - Manual connection management to ensure proper rollback on exceptions
        // Using try-with-resources can cause issues because connection closes before rollback
        // Solution: Using a single connection for both updates prevents deadlocks
        Connection conn = null;
        try {
            conn = DbHelper.getConnection();
            // Solution: Disable auto-commit to enable transaction control
            // This ensures both updates happen atomically (all or nothing)
            conn.setAutoCommit(false);

            // For the sender account
            try (PreparedStatement senderStmt = conn.prepareStatement(senderQuery)) {
                senderStmt.setDouble(1, newSenderBalance);
                senderStmt.setInt(2, senderId);
                senderStmt.setString(3, senderAccountType);
                int senderRowsAffected = senderStmt.executeUpdate();

                if (senderRowsAffected == 0) {
                    // Solution: Rollback transaction if sender update fails
                    conn.rollback();
                    return false;
                }
            }

            // For the receiver account
            try (PreparedStatement receiverStmt = conn.prepareStatement(receiverQuery)) {
                receiverStmt.setDouble(1, newReceiverBalance);
                receiverStmt.setInt(2, receiverId);
                receiverStmt.setString(3, receiverAccountType);
                int receiverRowsAffected = receiverStmt.executeUpdate();

                if (receiverRowsAffected == 0) {
                    // Solution: Rollback transaction if receiver update fails
                    conn.rollback();
                    return false;
                }
            }

            // Solution: Commit transaction only if both updates succeeded
            conn.commit();   
            System.out.println("\nBalance Updated Successfully!");
            isTransactionSuccessful = true;

        } catch (SQLException e) {
            // Solution: CRITICAL FIX - Explicitly rollback on exception to prevent hanging/deadlocks
            // If we don't rollback, the transaction remains open and can cause the database to hang
            if (conn != null) {
                try {
                    conn.rollback();
                } catch (SQLException rollbackEx) {
                    System.err.println("Error during rollback: " + rollbackEx.getMessage());
                }
            }
            System.err.println("Error during transfer transaction: " + e.getMessage());
            e.printStackTrace();
            isTransactionSuccessful = false;
        } catch (Exception e) {
            // Solution: CRITICAL FIX - Explicitly rollback on exception to prevent hanging/deadlocks
            if (conn != null) {
                try {
                    conn.rollback();
                } catch (SQLException rollbackEx) {
                    System.err.println("Error during rollback: " + rollbackEx.getMessage());
                }
            }
            System.err.println("Unexpected error during transfer: " + e.getMessage());
            e.printStackTrace();
            isTransactionSuccessful = false;
        } finally {
            // Solution: Ensure connection is always closed, even if rollback fails
            if (conn != null) {
                try {
                    conn.close();
                } catch (SQLException closeEx) {
                    System.err.println("Error closing connection: " + closeEx.getMessage());
                }
            }
        }

The explanations to the code blocks are in the comments, but basically, you first have to disable auto-commit in order to turn the queries into ACID transactions. Then, in two separate try blocks, you execute the updates for the sender and receiver accounts, and after that, you commit the transactions.

In summary, I learnt:

JDBC
Domain-Driven Design basics
ACID
Basics of operations in financial systems

So yeah. That's just it.

If you want to see the project, you can click here.

Until next time....bye! 👋

Java ATM CLI Dev Log #3: VTU Features

Victor Chigbo — Fri, 26 Dec 2025 19:16:26 +0000

Building this feature, was easy to say the least.

The volume of code to write was much but with the help of Gemini (via Gemini Code Assist), I was able to write everything out. One thing I did which I didn't like is how I hardcoded the airtime plans and data plans into the code. I did it because I want it to work first, and now it is working, what I will do now is to put the VTU plans into the database and retrieve them when needed. That's how it's done.

While running the code, I noticed a UX flaw: Each time I finish using a service and I want to use another one, after selecting it, I'll have to put my PIN back again.

As you can see, after withdrawing money from Jane Doe's account, I decided to buy airtime, but when I selected 'Recharge Airtime/Data', I was asked to put in my PIN number again. That is bad UX (user experience). Before I go ahead to implement any other feature, I will make sure to fix this issue.

The one thing in my mind that I want to learn while building this project is caching. This is simply storing data in a temporary place in the application so that I can access it faster without going to retrieve it from the database every single time. Knowing how to cache data will help me to build more efficient applications wherever I find myself. With time, I will get to learn this and update you as well.

If you want to check out the GitHub repo, you can click here and see it for yourself. Well, that's it for now.

Until the next commit, bye 👋

Java ATM CLI Dev Log #2: Transfer Cash, Hanging?

Victor Chigbo — Mon, 15 Dec 2025 23:52:18 +0000

I never expected building this feature to be so crazy to me.

While building the feature, everything was going smoothly, until the function started to hang during execution. I did some deep dive with ChatGPT and Gemini to see if I could get to the bottom of it. In the process, I got to learn about COMMIT, ROLLBACK, what transactions are in databases and why they are important in financial applications like this one which I am building.

Transactions are basically a sequence of SQL statements that are treated as a single logical unit, which starts with a data change and ending it using COMMIT or ROLLBACK. COMMIT means that the transaction was successfully while ROLLBACK is to roll back any changes made in the event of an error occurring.

Going into the project proper, these were the pieces of code I used for the transfer transactions:

// AccountService.java
public static void transferCash(Account sender, Account receiver, double amount) {
        if (sender.getBalance() > amount) {
            double newSenderBalance = sender.getBalance() - amount;
            double newReceiverBalance = receiver.getBalance() + amount;

            boolean isTransactionSuccessful = AccountDAO.makeTransfer(sender.getId(), receiver.getId(), sender.getAccountType(), receiver.getAccountType(), newSenderBalance, newReceiverBalance);

            if(isTransactionSuccessful) {
                System.out.println("Transaction Successful!");
                sender.setBalance(newSenderBalance);
                System.out.println("Withdrawal successful. New balance: $" + sender.getBalance());
                sender.stringifyAccount();
            } else {
                System.out.println("Transaction Failed!");
            }

        } else {
            System.out.println("Insufficient funds.");
        } 
    }

// AccountDAO.java
public static boolean makeTransfer(int senderId, int receiverId, String senderAccountType, String receiverAccountType, double newSenderBalance, double newReceiverBalance) {
        String senderQuery = "UPDATE accounts SET balance = ? WHERE customerId = ? AND accountType = ?";
        String receiverQuery = "UPDATE accounts SET balance = ? WHERE customerId = ? AND accountType = ?";
        boolean isTransactionSuccessful = false;

        try (
            Connection conn = DBHelper.getConnection()) {
            conn.setAutoCommit(false);

            // For the sender account
            try (PreparedStatement senderStmt = conn.prepareStatement(senderQuery);) {
                senderStmt.setDouble(1, newSenderBalance);
                senderStmt.setInt(2, senderId);
                senderStmt.setString(3, senderAccountType);
                int senderRowsAffected = senderStmt.executeUpdate();

                if (senderRowsAffected == 0) {
                    conn.rollback();
                    return false;
                }
            } catch (SQLException e) {
                e.printStackTrace();
                conn.rollback();
                return false;
            }

            // For the receiver account
            try (PreparedStatement receiverStmt = conn.prepareStatement(receiverQuery)) {
                receiverStmt.setDouble(1, newReceiverBalance);
                receiverStmt.setInt(2, receiverId);
                receiverStmt.setString(3, receiverAccountType);
                int receiverRowsAffected = receiverStmt.executeUpdate();

                if (receiverRowsAffected == 0) {
                    conn.rollback();
                    return false;
                }
            } catch (SQLException e) {
                e.printStackTrace();
                conn.rollback();
                return false;
            }


            conn.commit();   
            System.out.println("\nBalance Updated Successfully!");

            isTransactionSuccessful = true;

        } catch (Exception e) {
            e.printStackTrace();

            isTransactionSuccessful = false;
        }

        return isTransactionSuccessful;
    }

After talking to a dear friend of mine who is a senior engineer who has some experience working with Java in a bank, he told me that this was actually bad practice (Damn 😑). So I did some modifications in the AccountService and came up with these two functions, debitAccount and creditAccount. Makes sense, right? 😅

// AccountService.java
public static void debitAccount(Account account, double amount) {
        if (account.getBalance() > amount) {
            double newBalance = account.getBalance() - amount;
            boolean isTransactionSuccessful = AccountDAO.changeBalance(account.getId(), account.getAccountType(), newBalance);

            if(isTransactionSuccessful) {
                System.out.println("Transaction Successful!");
                account.setBalance(newBalance);
                System.out.println("Withdrawal successful. New balance: $" + account.getBalance());
                account.stringifyAccount();
            } else {
                System.out.println("Transaction Failed!");
            }
        }  else {
            System.out.println("Insufficient funds.");
        }
    }

    public static void creditAccount(Account account, double amount) {
        double newBalance = account.getBalance() + amount;
            boolean isTransactionSuccessful = AccountDAO.changeBalance(account.getId(), account.getAccountType(), newBalance);

            if(isTransactionSuccessful) {
                System.out.println("Transaction Successful!");
                account.setBalance(newBalance);
                System.out.println("Withdrawal successful. New balance: $" + account.getBalance());
                account.stringifyAccount();
            } else {
                System.out.println("Transaction Failed!");
            }
    }

But after everything I did, it all finally led to this:

At this point, I decided to stop and finish up the remaining features of the application, then come back to this one and fix it properly. By then, I must have gain some mastery in how to deal with transactions properly in Java.

If you want to check out the GitHub repo, you can click here and see it for yourself. Well, that's it for now.

Until the next commit, bye 👋

Video Streaming Server: My Experience On NodeJS

Victor Chigbo — Mon, 01 Dec 2025 14:25:39 +0000

During the weekend(28th November, 2025), I decided to bring out some free time and learn how to send media data(i.e. music audio, videos) through a server in a network. I learnt about streams and how they work to ensure that even big files can be sent to a device across the Internet.

The project is built with NodeJS and it runs smoothly. The next thing I want to do now is to implement transcoding in the server. Transcoding is simply the process of converting one digital format to another. You know that thing where you go to YouTube and select the video quality you want to stream? Yeah, that's transcoding.

If you click here, it will take you to the repository and if you follow the instructions exactly as it is, you'll get this

So yeah. That's it for now.

Till the next commit 👋

Java ATM CLI Dev Log #1: WithDraw Cash

Victor Chigbo — Mon, 03 Nov 2025 13:41:21 +0000

Before I talk about this dev log, lemme give you a backstory to understand what led me to start the project, and every other thing in-between.

Prelude

Between late August 2025 and early September 2025, I did some extensive research into the demand for developers in Nigeria (I'm based in Nigeria at the time of writing this article), what market demands for them the most and how much a person gets at the end of the year. The answer I got is fintech, so I went deeper into it.

Looking at the backend side of things in the fintech space, the languages that are dominant include Java and C# (and their respective ecosystems). Having a basic knowledge of Java, and seeing the annual pay of devs in the space (₦3M to ₦9M in Nigeria, $30K to $150K globally), I told myself, "Alright. Let's get into this!".

Now that's settled, let's get into the main business of today.

The Project And Today's Update

The project simply simulates the experience of using an ATM machine via CLI. I've learnt a couple of things so far which include JDBC, Domain Driven Design(DDD) basics, Data Access Objects(DAOs), some understanding of software architecture as a whole, and the parts of the Java Standard Library which makes it an excellent fit for the fintech industry.

I started the project two months ago, making inconsistently consistent changes to it as time went on. I stopped for a while because of exams but after that, I got back into it, alongside other things I am doing, and today, I managed to finish the first feature: Withdraw Cash.

Initially, I thought that this is something that is going to be done within a short period of time, but it took longer than expected, and for good reason. On the surface level, 'Withdraw Cash' is a one-line SQL command to change the customer's account balance, but it transformed into a combination of checks, constraints and conditions working together to perform a specific task, and the logic has to be right. After all, na money matter be this!.

Just to illustrate how important it is to get it right, there are two images below that shows the impact of a single, small mistake I made when creating the withdrawCash function.

In this image, it shows a successfully transaction process, withdrawing $200 from the balance, and printing out the new balance being $4800.

But in here, the balance shown is the amount withdrawn previously.
How?!

This is what happened:

Instead of passing the new balance to the query(abstracted within a class) to make the change in the DB,

 double tempAmount = account.getBalance() - amount;
 boolean isTransactionSuccessful = AccountDAO.changeBalance(account.getId(), account.getAccountType(), tempAmount);

I passed the amount to be withdrawn.

 double tempAmount = account.getBalance() - amount;
 boolean isTransactionSuccessful = AccountDAO.changeBalance(account.getId(), account.getAccountType(), amount);

And that's how a variable misplacement can cause a company to lose billions of dollars at a stretch.

It's a very scary thing and no one wants that to happen, but we prevent stuff like this from happening by writing tests. They help to conduct checks on individual parts of our codebase to ensure that they are working properly.

So yeah, that's it for today. I'll be making more dev logs like this on the things I'm learning and building, so If you want to stay tuned for more stuff like this, make sure to smash the Follow button on your screen.

Until the next commit, bye 👋

Intro

Victor Chigbo — Wed, 29 Oct 2025 08:47:54 +0000

Hey there 👋

My name is Victor Chigbo, aka Chivicks Hazard. I'm a frontend developer, a budding software engineer, and basically, a tech nerd. I like talking about tech wherever I go, and learning and trying new things about the tech industry.

It been almost two years since I joined this platform and it's awkward how I haven't posted anything here. Even on other platforms where I engage with people often (such as LinkedIn and X), I haven't been posting my stuff there as often as I should and want to.

As someone who likes reading, I love to express myself via writing. It's like a direct channel to where my brain can open itself to the world. It's a way in which I can share my ideas and thoughts fluently, allowing others to see what I see.

So without further ado, this is my official debut into the DEV community 🎉
If you like tech tips, nerdy tech projects (this is where I'll be sharing my 'basement' projects 😅😂), tech rants, opinions, and the likes, feel free to stick around so that we can grow together.

We move ✊🔥