Photo by Harish Shivaraman on Unsplash
The Planet of The Bugs, Book 1
Learn the fundamentals of debugging
🪐 The Planet of The Bugs - First Act
"With great power comes great responsibility." - Uncle Ben
In the original Renderland saga, we learned about Renderland's history, its new savior, and the invaders who sought to destroy it. The planet was invaded by an intelligent species of bugs.
This part will trace back the origin and history of those bugs and how they came into existence.
This article series will primarily focus on:
Understanding why bugs occur
Learning how to identify bugs and the debugging process.
Learn how to use debugging tools.
Last but not least, how to prevent bugs.
💡 I highly recommend you practice along to get the most out of this article. The source code and demo are available below:
The Origins of the Bugs 👾
I was back on earth watching Planet of The Apes when my TV started peeping and glitching then the screen turned blue. I tried switching it off, but suddenly got sucked into a portal and found myself in Renderland again!
Years have passed since the battle on Renderland and the bugs have been evolving, they are more complex now, reproduce and spread at incredible speeds, and can even hide in plain sight!
What is a software bug?
I was greeted by the federation's chairman, Dennis Ritchie 👴🏻 who then started briefing me about how the once-defeated bugs have been regrouping and are seeking revenge!
Dennis explained that bugs were a natural result of the complex systems and languages used to build programs. Sometimes, the simplest mistakes, like a misplaced semicolon, could cause a catastrophic failure.
The BugBook
BugBook is a popular social network used by billions on the planet of bugs, it allows bugs to share updates and communicate with each other across the entire planet. it was invented by a young genius named Bug Zuckerbug.
The Conspiracy Plan
Say we have two bugs, Mandible and Colonel Cutter who would like to communicate secretly via BugBook to conspire and plan on attacking Renderland again.
Mandible and the Colonel communicate by sending their messages to BugBook servers, which then relay the messages.
This process follows a model known as the request-response-cycle that describes how clients and servers communicate over a network via a protocol such as HTTP or Web Sockets.
😷 The Right Hosts!
Just like viruses or parasites in real life, bugs need hosts to survive and vectors so they could reproduce and spread.
BugBook, as both a social network and a business, has multiple departments that manage various operations such as authentication, messaging, storage, analytics, and finances through software and employees. The software involved includes web and mobile apps, databases, caches, networks, servers, firewalls, CDNs, etc, which are all possible areas that bugs could attack.
💡 Bugs can reproduce and spread via two primary hosts, humans, and machines:
❌ 👨🏿💻 Humans: Sometimes people mess up during software development, mistakes such as miscommunication or misplanning, conflict, putting in the wrong data, misunderstanding requirements, or making programming mistakes.
❌ 🤖 Machine: Sometimes, bugs can be really sneaky and find ways to multiply by taking advantage of glitches in machines. This can happen when there are issues with things like compatibility, versioning, memory, storage, or networks.
🎯 The Bug Hunter Training - Second Act
- “I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.” — Bruce Lee
In order to defeat the newly evolved bugs, our hero needs to train further and learn new skills.
🥷 The Search Party
We decide to form a search party that consists of the federation's top heroes. Together, we'll go out on a hunt, traditionally known as debugging which is the process of identifying, analyzing, and resolving errors or bugs in computer programs.
🔎 Identifying Bugs
To prove a bug exists, we need to reproduce it. This step may involve running the program multiple times to confirm the existence of the bug. It involves comparing the current VS the desired behavior of the program.
❌ Current Behavior: Modal closes before confirming user info.
✅ Desired Behavior: Modal closes after confirming user info.
🔁 Reproducing:
Attempting to recreate the same or at least similar conditions that led to the occurrence of the bug.
| OS | Version | Environment |
| MacOS Ventura | 13.0.1 | https://hashnode.com |
Other details such as error messages. For example, let's try this snippet here:
let bug;
console.log(bug.name);
Trying to access an undefined property
If you contribute to open-source projects, you'd find issue templates such as this New Bug Template from Cal.com.
🕵️ Inspecting:
Locate the source of the problem: Once the problem has been replicated, the next step is to locate the source of the problem. This can be done through tools like debuggers, logging, or by analyzing the code, depending on factors such as the environment and type of bug.
Most IDEs and browsers come with
Debuggersthat let you pause and examine a program's execution.There are logging and monitoring services such as Sentry, and Prometheus that let you locate bugs that happen in production environments via tracking events.
The 4th part of this series will discuss these in more depth.
🔐 Isolating Bugs
After locating the bug, the next step is to isolate it. This involves identifying the parts in which the bug occurs and any other relevant info.
💡 Let's take go back to BugBook for a minute:
🐞 Mandible: Tries to send the plan details via a encrypted message using BugBook.
Nothing happens when he clicks on the send button. Let's try to figure out what's causing this problem.
What we know so far:
It occurred when he was trying to send a message via BugBook.
He was using a 10th Generation iPad on a home WiFi network.
What we don't know:
- Whether the issue is from the bug's side or BugBook's side.
Remember, the first step in debugging is identifying the bug and proving its existence. Also, bugs can be caused by humans or machines.
💡 BugBook has 4 environments, namely, localhost, dev, staging and prod.
We'll use a very common problem-solving technique known as divide and conquer. We'll break down the BugBook system into smaller units and investigate each.
The plan is to split into teams and follow our training to investigate this issue in each dedicated environment. Remember the request-response-cycle? We'll start from there:
🖥️ The Frontend
Also known as the client, this is the part responsible for sending requests to the server and delivering responses back to the user. It consists of a user interface, logic, and a communication protocol, possibly HTTP or Web Sockets.
This means that the bug could be in the Markup (HTML, CSS) or the Scripting language (JavaScript).
🔙 The backend
When a Bug presses the send button on BugBook, a lot goes behind the scenes such as confirming the identity of the sender, locating the receiver, storing the message, and transferring it via a network, securely of course!
🪣 The Buckets
Let's use the analogy of a lab with buckets to help explain how to isolate bugs that may occur in a large system.
Thankfully, we have debugging, monitoring, and logging tools that help us record and assign labels on each bug we catch so we could place it in the right bucket.
Summary
Find out where the bug is and how much of the system it affects.
Think about any recent changes that might be connected to the bug.
Use debugging tools such as log files, tracing, or a debugger to pinpoint the source of the bug.
🛣️ The Pathways
This refers to predicting a program's behavior by mapping out all possible execution paths, which can be divided into two main categories.
Happy Path
Assumes everything is perfect and the program will behave as intended.
Sad Path
Assumes everything is a trap and extra caution is required. Involves thorough testing and analysis of edge cases and disaster recovery methods.
The 3 Questions Method
I usually ask myself 3 simple questions whenever I try to solve problems at work and on personal projects.
What?
Understanding a problem is 50% of the solution. This helps me understand the problem I am dealing with at a deeper level. This is where I'll ask questions and try to clarify everything before I attempt anything.
How?
After formulating a good understanding of the problem, I'd then start exploring the possible solutions and comparing them.
Why?
Why choose approach A over approach B or C?
Hunter Code of Conduct
You have now passed your basic hunter exam. Go out there and gain more skills and become the best hunter you could become!
And of course, each Hunter had to swear an oath after completing the Bug Hunter training.
Document every bug along with the necessary information to help others verify and reproduce.
Submit error/ bug reports when possible.
Conclusion
Practice is the best way to learn! You could try exploring Open Source projects for bugs. This will help you gain practical skills. There are also several bug bounty programs that you can participate in and hopefully earn some cash. Best of luck hunters!
This is a continuation of the Renderland Saga which previously had:
The other parts of the saga will explore each concept in detail. Stay tuned!
The Planet of The Bugs, The Markup Tribes (Explores HTML and CSS)
The Planet of The Bugs, The Scripts Tribe
The Planet of The Bugs, The Web (Explores Networking, CORs)