DEV Community: Joseph Ndungi

Building Plots in Angular for Data Visualization

Joseph Ndungi — Tue, 24 Mar 2026 08:37:18 +0000

Introduction

Data is easier to understand when you can see it. Tables are useful, but charts help you quickly spot trends, patterns, and outliers. In this post, I will share how I built plots in Angular for a linear regression tool and some lessons I learned along the way.

Why plots matter

When working with models like linear regression, numbers alone are not enough. You need visuals to answer questions like:

Are predictions close to actual values
Are errors randomly distributed
Are there outliers affecting the model

Plots such as residual charts and QQ plots make this very clear.

Choosing a plotting library

In Angular, one of the easiest ways to create charts is by using Plotly.

Plotly works well because:

It supports many chart types
It is interactive out of the box
It works nicely with Angular components

To use it, install the Angular wrapper:

npm install plotly.js angular-plotly.js

Then register it in your module:

import { PlotlyModule } from 'angular-plotly.js';

@NgModule({
  imports: [PlotlyModule]
})
export class AppModule {}

Preparing your data

Most APIs return data as arrays of objects. For example:

[
  { Fitted: 1.2, Residual: 0.3 },
  { Fitted: 1.5, Residual: -0.2 }
]

Before plotting, you need to map this into arrays:

const x = data.map(d => d.Fitted);
const y = data.map(d => d.Residual);

This is a very common step when working with charts.

Creating a simple plot

Here is an example of a residual plot:

createResidualPlot(data: any[]) {
  const trace = {
    x: data.map(d => d.Fitted),
    y: data.map(d => d.Residual),
    mode: 'markers',
    type: 'scatter',
    name: 'Residuals'
  };

  const layout = {
      title: 'Residuals vs Fitted',
      xaxis: {
        title: {
          text: 'Fitted Values',
        }
      },
      yaxis: {
        title: {
          text: 'Residuals',
        }
      },
    };

  this.residualPlot = {
    data: [trace],
    layout
  };
}

And in your HTML:

<plotly-plot
  [data]="residualPlot.data"
  [layout]="residualPlot.layout"
  style="width: 100%; height: 400px">
</plotly-plot>

Supporting multiple plots

As your app grows, you may need several plots:

Residuals vs fitted
Actual vs fitted
QQ plot
Cook’s distance

A good approach is to create one function per plot and store each result:

this.residualPlot = {...};
this.qqPlot = {...};
this.actualVsFittedPlot = {...};

This keeps your code clean and easy to manage.

Handling multiple datasets

One challenge I faced was supporting multiple securities. Each one had its own set of plots.

Instead of overwriting data, I stored them in a map:

visualizationMap[security] = visualization;

Then when the user selects a security, I load its plots.

Improving user experience

At first, all plots were shown in the main screen. This worked for one dataset but became messy with many.

A better solution was:

Add a graph button in the table
Open plots inside a popup
Show charts only when needed

This keeps the interface clean and focused.

Common issues to watch out for

Here are a few things that can go wrong:

Undefined data

If you try to access data.Fitted instead of mapping an array, your plot will not render.

Missing module

If Angular does not recognize plotly-plot, make sure you imported PlotlyModule.

Final thoughts

Adding plots to an Angular app can greatly improve how users understand data. With a library like Plotly, you can build powerful and interactive visuals with little effort.

Start simple. Focus on one plot. Then grow your solution step by step.

In my case, moving charts into a popup and supporting multiple datasets made a big difference in usability.

Happy Coding!

Implementing OpenID Connect Authentication in Angular 19 Without NgModules

Joseph Ndungi — Thu, 26 Feb 2026 11:48:14 +0000

Authentication is one of those things that looks simple from the outside and then quickly humbles you once you start wiring it properly.

Over the past day, I implemented OpenID Connect authentication in an Angular 19 application using Node v20.18.3. I am not using NgModules. The entire app is built using standalone APIs, which makes things cleaner but also slightly different from older tutorials you may find online.

This post walks through the setup, the structure, the issues I ran into, and how I fixed them.

Tech stack:

Node v20.18.3
Angular 19.2.20
angular auth oidc client
Identity Server as the OpenID provider

No NgModules. Everything is standalone.

Step 1. Install the OIDC client

npm install angular-auth-oidc-client

This library handles the heavy lifting. Token exchange. Storage. Refresh. State handling. You should not manually handle tokens.

Step 2. Configure authentication in app.config.ts

Because this is a standalone Angular app, everything is configured using ApplicationConfig.

import { ApplicationConfig, provideAppInitializer, inject } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideHttpClient } from '@angular/common/http';
import { AuthModule, StsConfigLoader } from 'angular-auth-oidc-client';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(),

    importProvidersFrom(
      AuthModule.forRoot({
        loader: {
          provide: StsConfigLoader,
          useFactory: OidcConfigLoaderFactory,
        },
      })
    ),

    provideAppInitializer(() => {
      const oidcSecurityService = inject(OidcSecurityService);
      const router = inject(Router);

      return oidcSecurityService.checkAuth().toPromise().then((result) => {
          if (result?.isAuthenticated) {
            router.navigate(['/dashboard']);
          }
        });
    })
  ]
};

Important detail.

Calling checkAuth on app startup is mandatory. Without it, the redirect from Identity Server will not be processed and login will look broken.

This was the first major issue I faced.

Login seemed to work. Tokens were returned. But Angular never picked them up. The fix was adding checkAuth in provideAppInitializer.

Step 3. OIDC configuration

In your config loader:

{
  authority: 'https://your-identity-server',
  redirectUrl: window.location.origin,
  postLogoutRedirectUri: window.location.origin,
  clientId: 'your-client-id',
  scope: 'openid profile api',
  responseType: 'code',
  silentRenew: true,
  useRefreshToken: true
}

Always use responseType code with PKCE.

Step 4. Implement login

Your login service can be simple:

login(): void {
      this.oidcSecurityService.authorize(undefined, {
      customParams: { prompt: 'login' }
    });
}

Why prompt equals login?

This was another issue I ran into.

The app was not redirecting to the Identity Server login page. It was silently authenticating and returning tokens.

The reason was that I already had an active SSO session. The Identity Server detected the session and immediately redirected back without showing the login screen.

Adding prompt equals login forces the login page to appear.

Step 5. Guard your routes properly

Routes:

export const routes: Routes = [
  { path: 'login', component: LoginComponent },

  {
    path: '',
    component: LayoutComponent,
    canActivate: [AuthorizationGuard],
    children: [
      { path: '', redirectTo: 'dashboard', pathMatch: 'full' },
      { path: 'dashboard', component: DashboardComponent },
      { path: 'management', component: LicenceManagementComponent }
    ]
  },

  { path: '**', redirectTo: '/login' }
];

Guard:

canActivate(): Observable<boolean | UrlTree> {
  return this.oidcSecurityService.checkAuth().pipe(
    map(({ isAuthenticated }) => {
      if (isAuthenticated) {
        return true;
      }
      return this.router.parseUrl('/login');
    })
  );
}

Another issue I encountered here was destructuring incorrectly.

My custom isAuthenticated method was already returning a boolean, but in the guard I destructured it as if it was an object. That silently broke navigation and kept redirecting back to login.

Fixing the observable type fixed the routing loop.

Step 6. Redirect after login

After authentication, Angular returns to whatever URL was used as redirectUrl.

If that is login, you will land back on login.

The fix is simple.

Inside LoginComponent:

ngOnInit() {
  this.securityService.isAuthenticated().subscribe(isAuth => {
    if (isAuth) {
      this.router.navigate(['/dashboard']);
    }
  });
}

Now authenticated users never stay on login.

Step 7. Do not manually store tokens

The library already stores tokens in localStorage using DefaultLocalStorageService.

Do not decode and persist tokens manually.

If you need profile info:

this.oidcSecurityService.getAccessToken().subscribe(token => {
  const decoded = jwtDecode(token);
  console.log(decoded.sub);
});

Keep it clean.

Bonus. Lazy loading

You can lazy load the authenticated area:

{
  path: '',
  component: LayoutComponent,
  canActivate: [AuthorizationGuard],
  loadChildren: () =>
    import('./features/app.routes').then(m => m.APP_ROUTES)
}

This improves performance and keeps login lightweight.

Challenges I Faced

Login appeared to do nothing
Root cause was active SSO session
Fix was prompt equals login
Tokens were returned but Angular did not recognize authentication
Root cause was missing checkAuth on startup
Fix was adding provideAppInitializer
After login it kept returning to login page
Root cause was incorrect guard observable typing
Fix was correcting the guard implementation
Redirect URL landed on login instead of dashboard
Fix was redirecting inside LoginComponent when authenticated

Final Thoughts

Implementing OpenID Connect in Angular 19 without NgModules is actually clean once you understand the lifecycle.

The key ideas are:

Always call checkAuth on startup
Let the library manage tokens
Keep guards simple
Understand how redirect URLs affect routing
Force login prompt only when needed

Authentication is less about writing code and more about understanding flow.

Once you get the flow right, everything becomes predictable.

Below is a sample Angular app repository.

👉GitHub Repository

If you are implementing this on Angular 19 with Node 20 and standalone APIs, this structure should save you a few hours of debugging.

And probably a bit of frustration too.

Happy Coding!
👉For More blogs

Performance and Scalability

Joseph Ndungi — Wed, 06 Aug 2025 07:20:22 +0000

From Timeouts to Triumph: A Practical Guide to High-Performance APIs

🚀 Introduction

Recently, our team was working on an API designed to fetch data and generates files at the end of the day. A client requested a large dataset, spanning from August 31st of last year to the current date. To handle this, we shared a script designed to pull the data from over 80 different endpoints.

When we ran the script, we quickly realized some of the files were not being generated. The reason was clear from the terminal errors: timeouts. The database was getting hammered by an overwhelming number of queries and joins all at once.

My initial thought was that the client given her size would surely have the resources to handle the load. But we soon understood the real issue: we were hitting the maximum connection limit of the SQL database. It was a classic race condition where too many requests were competing for limited database connections, causing the system to fail. So, what were we supposed to do? This scenario highlights a critical challenge in building scalable systems.

🚀 Optimizing APIs for High Throughput

High throughput means handling a large volume of requests quickly and efficiently. When your APIs are slow, the first instinct is often to look at the server's CPU or RAM. But usually, the real bottleneck is how you're accessing your data. In our example, running 80+ queries at once created a traffic jam at the database level.

Key Strategies:

Write Efficient Database Queries: Your database is your foundation. If it's slow, everything is slow.
- Index Everything: The single most important thing you can do. Without an index, your database has to do a "full table scan" to find data, which is like reading an entire book just to find one name. With an index, it's like using the book's index—incredibly fast. Identify the columns you frequently filter or join on (WHERE, JOIN...ON) and index them.
- Analyze Your Queries: Use tools like EXPLAIN (in SQL) to see exactly how your database is executing a query. It will show you if you're using indexes correctly and highlight inefficient steps.
Use Asynchronous Operations and Job Queues: Not every task needs to happen immediately. For a long-running job like generating historical data files, the API's only responsibility should be to say, "Okay, I've received your request and will work on it."
- How it works: Instead of processing the request and making the user wait, the API endpoint adds a "job" to a queue (using tools like RabbitMQ, AWS SQS, or Redis). Separate "worker" processes then pick up jobs from this queue one by one and do the heavy lifting: querying the database, processing the data, and generating the file.
- Benefits: This prevents API timeouts, allows you to control concurrency (e.g., only run 5 jobs at a time), and makes your system much more resilient to spikes in load.

📈 Handling Concurrent Requests

The issue of hitting the database's "maximum connection" limit is a classic scalability problem. When hundreds or thousands of requests try to talk to the database at once, the database can't keep up and starts refusing new connections, leading to timeouts and errors.

Key Strategies:

Implement Connection Pooling: This is non-negotiable for any high-performance application. Instead of each request opening a brand new, expensive connection to the database, a connection pool maintains a "pool" of open connections.
- How it works: A request "borrows" a connection from the pool, uses it for its query, and immediately returns it. This is thousands of times faster and prevents you from exhausting the database's connection limit. Most modern web frameworks and database libraries have this built-in, but you must ensure it's enabled and configured correctly.
Design Bulk Endpoints: Instead of having the client call 80+ separate endpoints, design a smarter API. Create a single endpoint that can accept a larger, more complex request.
- Example: Create a POST /api/v1/Clients endpoint that accepts a JSON payload with a date range ("startDate": "2023-08-31", "endDate": "2024-08-04"). Your backend can then intelligently break this single request into smaller, manageable chunks and feed them to your job queue system without overwhelming anything.
Use a Load Balancer: You should never run a critical application on a single server. A load balancer is a traffic cop that sits in front of multiple instances of your application. It distributes incoming requests evenly across them, ensuring no single server gets overwhelmed. If one server fails, the load balancer automatically redirects traffic to the healthy ones.

🧠 Caching Strategies That Actually Work

Caching is the art of storing the results of an expensive operation so you don't have to do it again. If users are frequently requesting the same data, hitting your database every single time is incredibly wasteful.

Key Strategies:

Application-Level Caching: This is the simplest form, where you store frequently accessed data in your application's memory. It's fast but limited, as the cache is lost if the app restarts and isn't shared between different server instances.
Distributed Caching with Redis: This is the gold standard for backend caching. Redis is an extremely fast, in-memory data store that all your application servers can connect to.
- How it works: When a request for data comes in, your application first checks if the result is in Redis.
  1. Cache Hit: If it's there, you return the data from Redis immediately without ever touching the database. This is lightning-fast.
  2. Cache Miss: If it's not there, you query the database, get the result, store it in Redis for next time, and then return it to the user.
- This dramatically reduces the load on your database for read-heavy operations.
Content Delivery Networks (CDNs): A CDN is a network of servers distributed around the globe. It's primarily used to cache "static" assets like images, videos, CSS, and JavaScript files closer to your users, which drastically reduces load times. Some CDNs can also cache API responses, which is perfect for public data that doesn't change often.

Final Thoughts

The initial problem of timeouts wasn't a resource failure; it was an architectural failure. The solution wasn't bigger servers, but a smarter approach. By optimizing queries, handling concurrency with queues and connection pools, and leveraging caching, you can build systems that are not only performant but also scalable and resilient. Performance is a feature, and it starts with design.

Happy Coding!

It works on my machine

Joseph Ndungi — Wed, 16 Jul 2025 10:18:49 +0000

A Developer's Guide to Controlled Chaos, 'QA Love', and Sanity

Alright, let's be real. Three years in, and I've uttered "it works on my machine!" with a mix of frustration and genuine confusion for some time. We've all been there, fueled by the "move fast and break things", only to be brought crashing back to reality by the unsung heroes (and occasional villains, depending on your mood) of the software world: Quality Assurance.

Three years in the industry (so proud of myself), this is my take on how to navigate the wild world of rapid development, embracing QA counterparts, and, most importantly, keeping my sanity intact when the deadlines loom.

Move Fast and Break Things (Until QA Calls)

Remember those early days? The thrill of pushing code, seeing it work (mostly), and the belief that speed trumped all? "Move fast and break things," we chanted, picturing ourselves as agile ninjas, fearlessly innovating. And then came the bug reports.

It usually starts with a polite, "Hey, I found something..." which quickly escalates to a detailed, step-by-step reproduction that makes your blood run cold. You re-read your code, convinced it's flawless, only to realize that, yes, you did forget to handle that edge case where the user tries XYZ. Or maybe you forgot that not everyone has the same super-fast internet connection you do.

The point is, "move fast and break things" isn't an excuse for carelessness. It's a philosophy born from a desire for iteration, not destruction. The "breaking" should be controlled, intentional, and, ideally, caught before it hits a client. Think of it like a scientist conducting an experiment: you're pushing boundaries, but you're also recording your findings and anticipating potential side effects.

This means unit tests aren't just for senior devs; they're your first line of defense. Code reviews aren't just a formality; they're a chance for another pair of eyes to spot your blind spots. And most importantly, understanding the user flow from a non-developer perspective is crucial. Because let's face it, we developers sometimes live in a bubble of perfect conditions and ideal user behavior.

Why QA is Actually Your Best Pal

Let's talk about QA. For many of us, especially when we're new and perhaps a little insecure about our code, QA can feel like the enemy. They're the ones finding all the flaws, pointing out your mistakes, and sometimes, making you question your life choices. I've been there, grumbling under my breath about "bug reports" and "edge cases that no one would ever do."

But here's the honest truth: QA is the devil's advocate, and that's a good thing. They are literally paid to try and break your software. Their job is to look at your beautiful, carefully crafted code and imagine every twisted, illogical, and downright bizarre way a human might interact with it. And trust me, humans are very good at being bizarre.

Think of it this way: every bug QA finds is a bug that a client doesn't. Every frustrating back-and-forth over a bug report is a lesson learned, a better understanding of edge cases, and ultimately, a more robust product.

So, how do we stop fearing them and start appreciating them?

Communicate, communicate, communicate: Don't just toss your code over the fence and wait for the inevitable. Talk to your QA team early in the development cycle. Understand their testing plans, share your assumptions, and ask for their input. They might even spot potential issues before you write a single line of code.
Provide clear context: When you submit a feature or a bug fix, don't just say "done." Explain what you've done, what you've tested, and any known limitations. The more information they have, the more efficiently they can test.
Embrace the feedback: It's not personal. It's about the software. When they find a bug, try to understand why it's a bug from their perspective. Ask questions. Learn.
Show appreciation: A simple "thanks for catching that" goes a long way. They're doing critical work, often under pressure, to ensure your hard work shines.

Building a strong partnership with QA isn't just about making your life easier; it's about delivering better software. They are your allies in the quest for quality.

Underpromise, Overdeliver (and Keep Your Sanity)

Every developer knows the feeling of being asked, "How long will that take?" and instantly feeling a cold sweat. Stakeholders want answers, and they want them fast. The pressure to promise the moon can be immense.

But here's the secret sauce, the developer's survival strategy: underpromise, overdeliver.

This isn't about being lazy or intentionally slow. It's about being realistic, building in buffer time, and managing expectations. Here's how it plays out:

Pad your estimates: When you think something will take 2 days, say 3. When you think it'll take a week, say a week and a half. Why? Because things always come up. Unexpected bugs, new requirements, environment issues, that one meeting that drags on for two hours – life happens. That extra buffer isn't wasted time; it's sanity insurance.
Break down tasks: Don't estimate a monolithic "build the whole feature" task. Break it down into smaller, manageable chunks. This makes your estimates more accurate and allows you to track progress more effectively. "Develop API endpoint" is easier to estimate than "build social media integration."
Communicate scope changes: This is huge. If a stakeholder suddenly asks for a "small" addition that you know will add significant time, speak up immediately. Don't let scope creep silently derail your timelines.
Manage expectations: If you hit a roadblock, communicate it early. Don't wait until the day before the deadline to announce a delay. Proactive communication builds trust, even when things go awry.
Celebrate the "overdelivery": When you estimate 3 days and finish in 2, you're a hero. It feels great, and it builds confidence with your stakeholders. This creates a positive feedback loop.

This strategy isn't just about hitting deadlines; it's about reducing stress, avoiding burnout, and maintaining a healthy work-life balance. When you consistently deliver what you promise (or even a little more), you build a reputation for reliability. That reputation is worth its weight in gold.

The Human Element in the Machine

So, there you have it. Three years in, and I've learned that being a good developer isn't just about writing elegant code. It's about understanding the chaotic dance of rapid development, forging strong alliances with your QA team, and mastering the art of managing expectations.

It's about controlled chaos, not careless breaking. It's about seeing QA as your partner, not your enemy. And it's about being honest with yourself and others about what's achievable, ensuring that when you do deliver, you do it with a sense of accomplishment, not exhaustion.

Keep coding, keep learning, and remember: we're all just trying to build cool stuff without completely losing our minds.

What's your biggest "it works on my machine!" moment?

Happy Coding!

Navigating Kenyan Roads on Two Wheels

Joseph Ndungi — Mon, 09 Jun 2025 17:46:40 +0000

Answering the Big Question: Is It Safe to Cycle on Kenyan Roads?

The other day, as I proudly showed off my new bicycle, a friend looked at me with the kind of genuine concern, leaned in and asked the question that’s on every aspiring Kenyan cyclist's mind: “Lakini, is it even safe to cycle on our roads?”

It’s a fair question. Let’s be honest: Kenyan roads are a special kind of ecosystem. It’s a concrete jungle where matatus frequently challenge the laws of physics, boda bodas materialize out of thin air, and some potholes have their own postal codes. The idea of navigating this beautiful chaos on a metal frame with two skinny wheels can seem, well, insane.

And yet, my answer, after a few hundred kilometres clocked and a thick layer of dust permanently attached to my soul, is a cautious but resounding YES.

It can be safe. It can be incredibly rewarding. It can be the best thing you do for your body and mind. But it’s not about luck. It's about being smart, being prepared, and being more visible than a traffic police officer on a Friday afternoon. Here’s how I learned to stop worrying and love the ride.

Section 1: The Golden Rules of Staying Safe

Think of this as your survival guide. It’s less about having the strongest legs and more about having the sharpest wits.

Be a Human Traffic Light (Be Hyper-Visible)

Your number one job on the road is to make sure everyone can see you. You need to be impossible to ignore.

Dress Loud and Proud: This is not the time for your cool, all-black aesthetic. Think neon. Hi-vis yellow, fluorescent green, blinding orange. You want to look like a highlighter pen that’s decided to take up a sport.
Lights, Camera, Action!: Lights are not just for the night. A flashing white front light and a red rear light are your best friends, even in the bright midday sun. Modern daytime flashlights are designed to be seen from over a kilometre away. Look for something with at least 100 lumens for the rear and 200+ lumens for the front. They cut through the visual noise and scream “I AM HERE!” to distracted drivers.

Master the "Matatu & Boda Boda Dance"

This is a delicate art form that requires observation, prediction, and a healthy dose of pessimism.

The First Commandment: Assume You Are Invisible. Seriously. Engrave this on your helmet. Never, ever assume a driver, rider, or pedestrian has seen you. Always ride as if you’re a ghost they can drive right through. This mindset keeps you sharp.
Be Boringly Predictable: Sudden moves are for blockbuster movies, not for your daily commute. Ride in a straight, predictable line. Use clear hand signals before you turn or stop. Want to move out to avoid a pothole? Check your shoulder, signal, and then move. No surprises.
Claim Your Lane (When Safe): It feels counterintuitive, but hugging the far edge of the road can be dangerous. It invites drivers to squeeze past you with only inches to spare. Instead, ride about a meter from the curb. This makes you more visible, forces cars to give you a proper berth when overtaking, and gives you an escape route if you need to dodge a sudden obstacle.
The Power of the Gaze: At junctions and roundabouts, try to make eye contact with drivers. A simple nod or glance is often all it takes to confirm they’ve registered your existence. It’s a silent, two-wheeled conversation that can save your skin.

Choose Your Battlefield (Route and Timing)

You wouldn't learn to swim in the middle of the ocean, so don't learn to cycle on Mombasa Road at 5 PM.

Beginner Havens: Start somewhere peaceful. Explore the quiet roads in residential estates on a Sunday morning. Better yet, head to controlled environments. Karura Forest offers beautiful, car-free trails perfect for building confidence. The climb up Ngong Hills is tough, but the views and relatively low traffic are worth it.
The Magic Hour: The secret to blissful Kenyan cycling is the time of day. Set your alarm for 5:30 AM. Riding between then and 7:30 AM is a different world. The air is cool and crisp, the sun is rising, and the roads are wonderfully empty. You get your exercise in before the chaos even wakes up.

Section 2: Gearing Up (The Tech and The Tin)

Cycling can look like an expensive hobby, but you can get started without selling a kidney.

Your First Trusty Steed: You do not need a KES 200,000 carbon fibre race bike that weighs less than your lunch. For Kenyan roads, a sturdy Mountain Bike (MTB) or a versatile Hybrid Bike is your best bet. Their tougher frames and wider tires are perfect for handling our… character-filled road surfaces. Good quality second-hand bikes from reputable dealers are a fantastic way to start.
The Non-Negotiables:
- A Helmet: If you have a head, you need a helmet. Full stop. Modern helmets are light, well-ventilated, and some even have tech like MIPS (Multi-directional Impact Protection System) for extra safety.
- Lights: Yes, them again. They are that important.
- Water Bottle & Cage: You will sweat. A lot. Hydration is critical.
The "My Life is So Much Better Now" Gear:
- Padded Cycling Shorts (Bibs): Let’s talk about your behind. After 10km on a bike seat, it will start complaining. After 20km, it will file a formal grievance. Padded shorts are the single greatest invention for cycling comfort.
- Gloves: They absorb vibrations, protect your hands if you fall, and improve your grip when things get sweaty.
- A Small Pump & Puncture Repair Kit: Getting a flat tyre is a rite of passage. Learning to fix it on the side of the road makes you feel like a self-sufficient genius.

Section 3: The Incredible Rewards (Why We Do This)

So you’ve dodged the potholes and bought the gear. Why is it all worth it?

The Unwind Button

As a tech enthusiast, I spend my days staring at screens. Cycling has become my analogue escape, my ultimate unwind button. It’s a space where the only notifications are the changing gears and my own heartbeat. I started tracking my rides on Strava, a social network for athletes. At first, it was just to see how far I’d gone. But it quickly became a fascinating data stream of my own progress.

Seeing my average speed increase from 15 km/h to 20 km/h, watching my elevation gain stack up week after week, and conquering a hill that left me breathless a month ago—it's incredibly motivating. It gamifies fitness. If you want to see the stats and follow my journey, you can find me on Strava under the username Joseph Ndungi.

Discover a Hidden Kenya

From a car, you see Kenya. On a bike, you experience it. You smell the rain hitting the tarmac in Limuru’s tea fields. You feel the sun on your back as you coast down the hills. You hear the cheerful "Niaje!" from kids in a small village. You discover tiny cafes and viewpoints you’d never notice while stuck in traffic. It’s a sensory overload in the best possible way.

Finding Your Tribe

The best part? You don't have to do it alone. The cycling community in Kenya is booming, friendly, and diverse. Riding in a group is not only safer but also way more fun. Most groups organize weekly/monthly rides to advocate for cycling in the city, and clubs have rides for all skill levels. The camaraderie of a pre-ride coffee and a post-ride discussion about who conquered which hill segment on Strava is half the fun.

Conclusion: Your Invitation to the Road

So, back to that big question: Is it safe to cycle on Kenyan roads?

The road itself is neutral. It's how you approach it that matters. With the right mindset (assume you're invisible), the right gear (be a traffic light), and the right company, it is not only safe, but it's also one of the most life-affirming, stress-busting, and adventurous hobbies you can pick up in this country.

So, start small. Borrow a bike and ride around Karura this weekend. Look up a beginner group ride. Just start. The road is waiting, and it's more beautiful than you can imagine.

Happy ~~Coding~~ Cycling!

Tradeoffs Between In-Memory Checks and Database Queries

Joseph Ndungi — Tue, 20 May 2025 12:19:52 +0000

To Cache or Not to Cache: Tradeoffs Between In-Memory Checks and Database Queries

In software engineering, many real-world problems boil down to tradeoffs, and one recurring decision is whether to query the database multiple times or fetch once and operate on data in memory. This seemingly small architectural choice can shape performance, reliability, and maintainability in ways that are easy to overlook but matter deeply in production.

One of the most fundamental and frequently encountered tradeoffs revolves around data access: when faced with needing multiple pieces of information about a single entity (like a user or an order), should we fetch everything once and perform checks in our application's memory, or should we make several targeted queries to the database, asking for specific answers each time?

This isn't just an academic exercise. It's a decision that impacts user experience, system stability, and development velocity. It surfaces during critical business operations: activating a new user, processing a customer order, validating complex state transitions in a workflow, or authorizing access based on multiple criteria. Get it wrong, and you might build a system that's sluggish, brittle, or scales poorly. Get it right, and you pave the way for a responsive, robust, and maintainable application.

Consider a common scenario: activating a user account. The business rules might be simple: "Activate the user only if they exist, they are not currently frozen, and they are not already active." This seemingly straightforward task immediately presents two primary implementation paths, each with profound implications. Do we load the entire user record – ID, status, flags, maybe even recent activity – into our application's memory and then run our checks? Or do we ask the database three specific questions: "Does user X exist?", "Is user X frozen?", "Is user X active?"

Recently, while working on a user activation/deactivation feature, my team encountered this dilemma. It sparked a healthy debate, reminding us that even familiar problems deserve fresh consideration based on the current system context, expected load, and evolving architecture.

This article delves into the engineering tradeoffs between these two fundamental approaches. We'll explore the nuances of performance, the subtleties of data consistency, the impact on code clarity, and the long-term effects on scalability, helping you make more informed decisions in your projects.

The Two Approaches

Let’s establish the two primary paths we considered. They apply not just to user activation, but to many workflows: order validations, access checks, billing logic, etc.

Option 1: Single Query, In-Memory Validation

This approach front-loads the data fetch. You query once—ideally in a single row fetch or join—and get everything you might need about the entity (e.g., a user). Then you perform all logical checks using in-memory operations.

This is appealing for its simplicity. All checks are co-located, there’s just one database hit, and your business logic can proceed without waiting for more network calls.

Option 2: Multiple Targeted Queries or Stored Procedures

Here, you break the logic down. You might ask, “Does this user exist?”—issue a quick query. Then, “Are they frozen?”—issue another. Each check is independent, minimal, and potentially reusable across the codebase or services. Often, this is done via helper methods or stored procedures that encapsulate business logic within the database.

Key Tradeoffs and Considerations

So, which is better? As with most design decisions, it depends. Let’s explore the dimensions that influence the choice.

1. Performance

Performance is often the most immediate concern. Each database call has inherent latency, especially in distributed systems or cloud-hosted architectures.

In-Memory Wins: Every database query incurs latency – the time it takes for the request to travel over the network to the database, be processed, and for the response to travel back. Even on fast networks, this "round-trip time" (RTT) adds up. Fetching once drastically reduces this overhead. In cloud environments, especially across availability zones or regions, network latency can be significant, making single fetches markedly faster for the end-user or calling service. Think of it as making one phone call versus three separate calls – the setup time for each call adds up.
Multiple Queries Can Shine When: Each query is light, well-indexed, and operates on narrowly scoped data. This is especially true when you don’t need the full object and can get away with querying just what you need.
Network Bandwidth: Option 1 might transfer more data in total if the user object is large and you only need small parts of it. Option 2 transfers minimal data per query, potentially saving bandwidth if the network is constrained, but increases the number of network packets.

However, remember that latency is multiplicative, not additive. Two 10ms queries in serial cost more than one 15ms query. The cost of multiple calls adds up, especially in high-throughput systems.

If your system operates over a high-latency network, in-memory is often the safer bet.

2. Readability and Maintainability

Code that’s easy to understand is easier to extend and debug. That’s not just a nicety—it’s critical for long-term maintainability.

Single Fetch Flow: This makes it easier to read through a function and understand the full validation logic. Everything you need is right there, in one place.
Modular Checks: Breaking out logic into discrete, self-contained checks (e.g., isUserFrozen(userId)) can lead to better separation of concerns and reusability. This is useful if validations are reused in multiple flows or services.
Cognitive Load: For simple cases, the inline checks (Option 1) might be easier to grasp immediately. For complex validation logic involving multiple conditions, breaking it down into well-named modular functions (Option 2) can make the overall process easier to understand and test, even if it requires navigating between different functions or files.
Testing: Unit testing the logic of Option 1 is simple once the object is mocked. Integration testing requires a database connection. Option 2 lends itself well to unit testing each check function individually (if they are in the application layer) or requires integration testing if relying heavily on database procedures.

On large teams or in domain-heavy environments, modular checks can also reflect business rules more clearly and be more testable.

There’s a tradeoff between linear simplicity and modular clarity. Pick what fits your team and codebase style.

3. Scalability and System Load

Under light usage, either approach may be fine. But under heavy load, the wrong choice can put significant pressure on either your database or your application servers.

Fewer DB Calls = Less Load: If thousands of requests per minute all make 3–5 queries each, your database will feel it. One query per request can significantly reduce load.
Memory Footprint Matters: Fetching large objects into memory, especially with relations, joins, or blobs, can increase pressure on your application memory, garbage collector, or runtime.

This is often a balancing act. In-memory operations reduce I/O but increase RAM usage. If you’re memory-constrained or running in a serverless environment, you might prefer lean, focused queries.

Think about which resource is your bottleneck—CPU, memory, or database—and design accordingly.

4. Data Freshness

This one is subtle but crucial in systems with concurrency.

Stale Reads (The In-Memory Risk): In Option 1, you fetch the user data at the beginning of the operation. If, between the time you fetched the data and the time you perform a check (e.g., user.isActive()), another concurrent process modifies the user's state in the database (e.g., an administrator activates them), your in-memory object is now stale. Your check will be based on outdated information, potentially leading to incorrect decisions or errors (like trying to activate an already active user).
Real-Time Accuracy (The Multiple Query Benefit): Each targeted query in Option 2 goes directly to the database at the moment the check is needed. This significantly reduces the window for stale data. The result of isUserActive(userId) reflects the state in the database at right then. This is crucial in systems with high concurrency where data changes frequently.
Race Conditions: This highlights the potential for race conditions. Imagine two requests trying to activate the same inactive user simultaneously. With Option 1, both might fetch the inactive user, pass the in-memory check, and then both attempt the activation database update. With Option 2, the second request's isUserActive check is more likely to see that the first request has already completed the activation (depending on transaction isolation).

In systems with high concurrency or strict consistency requirements, in-memory checks can create race conditions unless mitigated with transactions or optimistic locking.

Favor targeted queries when freshness matters more than performance.

5. Atomicity and Transactions

Much of this debate becomes moot inside a well-structured transaction.

Transaction Scope: If you're wrapping everything in a transaction, a single read with in-memory checks keeps things consistent and simple. You lock the state at the beginning.
Multiple Queries Need Coordination: Without a transaction, issuing separate queries can lead to time-of-check to time-of-use (TOCTOU) issues—i.e., you checked the state, but it's changed before you acted on it.

That’s why transaction boundaries are vital. Use them if you need to validate and mutate in one go.

If you're not using transactions, the risk of inconsistent reads increases with each separate query.

When to Use Each Approach

These guidelines can help you decide based on your context:

✔ Use In-Memory When

You are performing multiple checks on different attributes of the same entity within a single request or function scope.
You would likely need to fetch most of the entity's data eventually anyway for the main operation.
Minimizing database round-trips and network latency is a primary performance concern (e.g., high-traffic API, cloud environment).
The operations need to be atomic, and you can comfortably wrap the entire fetch-check-update sequence in a single database transaction.
The risk of the data becoming stale between the initial fetch and the checks is acceptably low for the use case, or mitigated by transactional locking.
The memory footprint of the fetched object is manageable for your application servers under expected load.

✔ Use Multiple Queries or Stored Procedures When

The validation logic is complex and highly reusable across different parts of the application or even different services (promoting DRY).
Data freshness is paramount, and the risk of acting on stale data read moments earlier is unacceptable due to high concurrency.
Individual checks are significantly cheaper (e.g., hitting perfect indexes for boolean flags) than fetching the entire object, and network latency is low.
You need to enforce strict data access patterns or security at the database level, often achieved via specific stored procedures that only expose necessary checks/actions.
Application server memory is extremely constrained, making loading potentially large objects undesirable.
You are operating in a distributed system where ensuring consistency across multiple steps requires careful orchestration, and individual checks are natural integration points.

Final Thoughts

Software engineering is a series of tradeoffs, and this one is prevalent yet easy to underestimate. As with caching, the allure of “faster” or “cleaner” must be balanced against consistency, observability, and correctness.

In some cases, a hybrid approach works best: one main fetch with a few “fresh” spot checks for sensitive attributes. In others, the business rules themselves may dictate the approach, particularly in systems with strict audit, concurrency, or compliance requirements.

Ultimately, a well-reasoned tradeoff, documented and understood by the team, is far more valuable than rigidly adhering to a set of principles. Understand the forces at play – performance, consistency, maintainability, scalability – and choose the path that best serves your application's needs, both today and in the foreseeable future.

Happy Coding!

The Pressure is Real

Joseph Ndungi — Fri, 09 May 2025 06:10:07 +0000

From Junior to Senior: Navigating the Path in Software Engineering

When you land your first role as a software engineer, you're full of excitement and maybe a bit of impostor syndrome. You’ve passed coding interviews, built a few side projects, and even perhaps shipped some production code. But then the reality hits: transitioning from a junior developer to a senior one is less about typing faster or writing the most elegant one-liner, and more about communication, ownership, and soft skills that no tutorial ever quite teaches.

1. The Pressure is Real—But So is the Growth

Junior developers often face a unique kind of pressure. You’re expected to learn quickly, ship code reliably, and adapt to a team dynamic you didn’t encounter in school or bootcamp. Deadlines loom. Bugs sneak in. Code reviews are humbling (if not outright bruising). You’re often trying to figure out not just how to do something, but why it’s done that way.

The good news? Every developer—yes, even the 10x engineer you think has it all figured out—started here. The journey from junior to senior isn't about avoiding mistakes. It’s about learning from them.

2. Communication: The True Superpower

Ask any senior engineer what skill they value the most in others, and chances are high they’ll say communication. Writing code is one part of the job; explaining what it does, why it matters, and how it fits into a broader system is another.

As a junior, you may hesitate to speak up in meetings or on Teams. Over time, you realize that good communication doesn’t mean having all the answers—it means asking good questions, writing clear documentation, updating projects and QA, and being transparent about blockers. It also means learning to give and receive feedback constructively.

Even within dev-to-dev interactions, communication shows up unexpectedly: your Git commit messages, the clarity of your variable names. It's all part of the engineering conversation.

3. Prompt Engineering: A New Literacy

In today’s AI-powered dev world, prompt engineering is becoming a surprisingly valuable skill. Knowing how to interact with AI tools like ChatGPT or GitHub Copilot is a productivity boost.

For juniors, the key is in learning how to ask for what you need. That means writing specific, detailed prompts. Instead of “Help me fix this bug,” try “Here’s the error I’m seeing in my Angular app when I load FullCalendar with custom options…”

Prompt engineering is just communication with a machine. And like all communication, it improves with empathy, precision, and practice.

4. Technical Interview Prep: Algorithms vs. System Design

When you’re early in your career, interview prep often centers around LeetCode-style algorithm questions. And yes, they matter—especially if you’re applying to FAANG or similar companies.

But as you move toward senior roles, interviews change. You’ll be asked to explain trade-offs in architecture, design scalable systems, or debug a failing integration with limited information. This is where system design interviews come in.

Here’s the truth: Senior engineers don’t always write more code—they design better systems. They think in terms of APIs, scalability, observability, failure tolerance, and developer experience. If algorithms are the grammar of engineering, system design is the storytelling.

5. Soft Skills Are Not Optional

There’s a myth that software engineering is all about hard skills—algorithms, syntax, performance tuning. But what separates a senior from a junior is often the soft stuff: mentorship, stakeholder management, conflict resolution, empathy.

Senior engineers often act as glue for their teams. They bring people together, prevent miscommunication, and create psychological safety. They help onboard juniors, manage up to product managers, and influence architectural decisions—not just by authority, but by trust.

If you're the kind of person who listens actively, stays calm during outages, and explains trade-offs instead of just pushing an opinion, you’re already practicing senior behavior.

6. Freelancing vs. Full-Time: Two Roads to Growth

The rise of freelancing platforms and remote-first companies has made software engineering more flexible than ever. So what’s better—freelancing or full-time?

There’s no right answer. Freelancing can offer variety, autonomy, and higher pay per hour. But it also demands strong self-management, marketing, and client communication skills. You're your own tech lead, PM, and support team.

Full-time roles offer stability, mentorship, and a structured career ladder. They’re especially valuable for juniors who want to grow under the guidance of experienced teammates and develop broader systems thinking.

In truth, many devs try both across their careers. The key is understanding what kind of growth you need right now.

7. Mentorship & Paying It Forward

One of the most underrated parts of seniority is mentorship. At some point, you’ll be the one reviewing code, explaining the architecture, or helping someone debug a gnarly issue you’ve seen before.

Mentorship isn’t just about teaching—it’s about learning to explain clearly, listen patiently, and see things from someone else’s level of experience. It makes you better, too.

Juniors who ask questions, document what they learn, and share knowledge early on are already setting the foundation for mentorship.

Final Thoughts

The path from junior to senior developer isn’t linear. It’s a winding road full of messy PRs, awkward retros, unexpected breakthroughs, and moments when you feel like you finally get it—only to hit a new challenge that humbles you all over again.

Along the way, many junior developers fall into the trap of trying to be a jack of all trades—dabbling in frontend, backend, DevOps, AI, design, you name it. While it’s great to explore and stay curious, spreading yourself too thin can leave you feeling overwhelmed and underdeveloped in any one area. Depth, not just breadth, is what builds trust and leads to meaningful contributions.

And here’s something many of us learn the hard way: you don’t have to figure it all out alone. Seeking mentorship is not a weakness—it’s a strength. Learning from those who’ve already walked the path can save you months of frustration, help you avoid common pitfalls, and accelerate your growth in ways books and courses can’t. Whether it’s a senior on your team, a community mentor, or even a peer who’s just one step ahead, reach out, ask questions, and stay open.

Ultimately, becoming a senior engineer isn’t about having all the answers. It’s about learning how to ask the right questions, communicate clearly, grow intentionally, and lift others as you rise.

Happy Coding!

Web performance

Joseph Ndungi — Tue, 23 Jan 2024 06:18:53 +0000

Web performance is all about making websites fast, including making slow processes seem fast

In essence, web performance is about both the measurable aspects and the user's perceived experience when interacting with a site or app

Key areas include

Reducing Load Time: This involves minimizing the size and number of files needed to render a website, and using techniques like preloading to speed up the process.
Usability from the Start: We focus on loading website assets efficiently, enabling users to start interacting with the site quickly. Techniques like lazy loading enhance this experience.
Smoothness and Interactivity: A seamless user experience is crucial. We explore best practices in creating smooth animations and responsive interfaces.
Perceived Performance: It's not just about how fast a website loads, but how fast it feels to the user. Strategies like engaging loading screens can significantly improve user perception.
Performance Measurements: We delve into various metrics and tools for measuring and optimizing web performance, ensuring that the site not only performs well but continues to do so over time.

Maintaining optimal performance is relatively straightforward for basic websites. However, the task becomes more challenging with intricate web applications, where delivering a consistently smooth user experience is crucial.

The problem that exists is that while our website may behave as expected on our devices, our users won’t be accessing the device from our devices, but their own and under different circumstances.

In light of this, I have put together a selection of key metrics that are essential for evaluating the performance of websites

1. First Contentful Paint (FCP)

This performance metric, known as First Contentful Paint (FCP), gauges the time taken for the initial piece of content on a website - be it text, images, or other elements - to appear on the user's screen.

FCP measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page. Images, non-white canvas elements, and SVGs on your page are considered DOM content; anything inside an iframe isn't included.

FCP plays a significant role in shaping a user's perception of the page's loading speed, making its optimization vital.

It's important to aim for an FCP of 1.8 seconds or less for client websites to ensure optimal performance.

2. First Meaningful Paint (FMP)

Sounds pretty similar to First Contentful Paint (FCP), right? There’s a key difference.

As the name suggests, FMP is how long it takes for the first meaningful content to display (i.e., whatever users actually want to view).

This value is often the same as First Contentful Paint (FCP) but varies based on your client’s website.

3. Largest Contentful Paint (LCP)

This perceived performance metric is the time it takes for the largest piece of content to load on your client’s website (e.g., a video embed, image slideshow, text body).

It’s worth noting that LCP falls under Google’s Core Web Vitals, which means it directly impacts a website’s performance on Google search results.

It makes sense when you think about it. LCP is useful for a website visitor to gauge how long they’ll have to wait to access your client’s full website (which often determines whether they’ll stay or not).

When you measure LCP either using Lighthouse or PageSpeed Insight, it usually provides a list of reasons why your LCP was given a certain score and how you can optimize for it.
Some of the common things you can do to optimize for LCP.
Optimize Server Response Time

To speed up your website, use a Content Delivery Network (CDN) for your images, CSS, JavaScript, HTML, and static files. This helps with caching and improves a metric known as Time To First Byte (TTFB), which is the time it takes to receive the first byte of data from the server. TTFB affects key performance metrics like Largest Contentful Paint (LCP) and First Contentful Paint (FCP).

Enhance Resource Discovery
Load critical resources affecting LCP as soon as possible. Browsers have a preload scanner that prefetches items like images and stylesheets marked with rel=preload. Ensure your images' URLs are in the srcset or src attributes, and preload CSS background images and fonts.

Prioritize Key Resources
Ensure important resources load first. Use the fetchpriority="high" attribute for essential images. De-prioritize less critical resources to conserve bandwidth.

Other Optimizations

Switch to modern image formats like WebP, ideally using an image CDN for format compatibility.
Implement responsive images to suit different screen sizes.
Compress images to reduce size without losing quality.
Set appropriate cache settings to minimize repeat load times.
Eliminate unnecessary CSS and JavaScript.
Optimize font sizes for efficiency.

4. Cumulative Layout Shift (CLS)

Similar to Largest Contentful Paint, CLS also falls in the Google Core Web Vitals bucket.
Users often find it annoying when content they are reading suddenly shifts to a different spot on the page. This can happen due to images loading and pushing down existing content or dynamic additions like ads that force content to move.

As developers, we might not notice these shifts easily, especially if we're using fast internet connections where images load quickly or are already cached, making our testing less representative of actual user experience.

Cumulative Layout Shift (CLS) is a crucial metric that tracks these unexpected layout shifts over a webpage's life. A layout shift happens when visible elements move abruptly. CLS gives insight into how frequently this occurs on a webpage.

There are two kinds of layout shifts:

Unexpected Layout Shift: This is unintentional and occurs without the developer's design intent. It negatively impacts the user experience.
Expected Layout Shift: This is intentional, usually triggered by user actions, like clicking a button to reveal more content or animations.

The goal is to have no layout shifts on your webpage. However, a CLS score of 0.1 or less for 75% of all page loads is considered acceptable.

To optimize for CLS, ensure that all your images have a fixed height and width, or add aspect ratio to them, so that the browser can reserve a place for them in the rendered page.

5. First Input Delay (FID)

Wrapping up Google’s Core Web Vitals is First Input Delay (FID). Have you ever been to a website where, after it finished loading, there was a noticeable delay when you tried to click a link or a button? This delay is what First Input Delay (FID) measures. FID tracks the time it takes for a webpage to respond to user interactions like clicks, taps, or key presses while it's still loading. To achieve a good FID score, the response time should be 100 milliseconds or less.

To enhance First Input Delay (FID), focus on these key optimizations: Minimize the initial load of JavaScript, use Web Workers for complex tasks to free up the main thread, implement on-demand script loading, defer non-critical scripts with the defer attribute, employ code-splitting and lazy loading techniques for efficient script management, and reduce the usage of pollyfills to lighten the JavaScript load.

Summarized visual for the above metrics.

More Metrics

6.Page Load Time
This metric measures how long it takes for your client's website to fully render on a user's screen after their initial click.

7.Time to First Byte (TTFB)
TTFB is the duration it takes for a user's browser to obtain a data byte from a web server following a user’s initial click.
As a benchmark, aim for a time to first byte of no more than 600 milliseconds.

8.Speed Index
Speed Index is the rate at which a webpage loads progressively over time. In contrast to FCP, this metric considers the entire page loading process rather than solely focusing on one part.

9.Time to Interactive (TTI)
TTI is the time it takes for your client’s website to become responsive to user interactions (e.g., getting a successful response after clicking a ‘Download’ button).

While you can’t technically control how your visitors behave on your site, you certainly can optimize content to drive behavior.

References

Code Coverage vs. Test Coverage

Joseph Ndungi — Wed, 20 Sep 2023 11:50:38 +0000

Code coverage quantifies the portion of code lines activated during testing, while test coverage gauges the degree to which tests encompass the software's capabilities or specifications.

Code coverage reveals which code segments were triggered or bypassed.
Test coverage highlights the functionalities assessed from an end-user perspective.

Both metrics are vital in gauging the thoroughness of the testing procedure. However, individually, they provide only a fragmentary insight into the overall testing quality.

What is Code Coverage?

This metric evaluates the lines of code activated by test cases, comparing total lines to those tested. It gauges how much of a program's source code is tested, aiming for higher coverage to reduce potential undetected bugs.

def checkNumber(num):
 if num > 0:
   return "Positive"
 elif num < 0:
   return "Negative"

Consider I have a test case that gives the input to the num variable as 10 and calls the function checkNumber. When it’s time to execute the if block, it runs line by line.

Now since the if block was entered, the program exits after the return statement. So the code checked for two lines of code out of four, which means 50% of the code. In simple words, I covered just half of the code in my program, hence my code coverage is 50%.

Measuring Code Coverage

Code coverage is often represented as a percentage indicating the portion of code executed during testing. It can be assessed through various methods such as statement, branch, condition, and function coverage.

Above is an example of a conditional block to determine the coverage of the code. In testing terms, it is referred to as branch coverage, since a decision-making block becomes a root of a branch, where one branch means the condition returned true and the other one is false.

Statement coverage

The statement coverage in testing just verifies that all the executable lines of code have been implemented at least once.

General formula for calculating statement coverage:

Statement coverage = (Number of executed statements / Total number of statements) * 100%

Branch coverage

Branch coverage measures how well testing has covered possible paths in the code. Represented as a percentage, it indicates the proportion of branches executed during testing, with 100% implying all branches were tested.

Branch coverage = (Number of branches executed / Total number of branches) * 100%

Condition coverage

Condition coverage tracks how often each Boolean expression in the code evaluates to both true and false during testing. It's commonly used in control structures like if statements and loops.

Condition coverage = (Number of conditions tested / Total number of conditions) * 100%

Function coverage

Function coverage is a code coverage metric used to assess how test cases exercise the functions in the program when tested. It responds to the question, "How many functions in my code have been called at least once?"

The resulting ratio is then reported as a percentage, indicating the proportion of functions that have been tested. The formula for calculating function coverage is as follows:

Function coverage = (Number of called functions / Total number of functions) * 100%

If a function is not invoked during testing, it's probably not being exercised correctly and may have flaws.

Why perform Code Coverage?

Code coverage is vital for code quality and reliability because it:

Highlights untested or unused code.
Evaluate the effectiveness of the test suite and pinpoint areas needing more testing.
Indicates potential areas with bugs, prioritizing which code segments to inspect first.
Helps identify and remove unnecessary "dead code."

Advantages of Code Coverage

Code coverage is a valuable measure for assessing the quality and completeness of tests. Other advantages of code coverage include the following:

Increased software reliability as a result of extensive testing.
Shorter development cycles because developers can focus on testing critical portions of the code.
Easier debugging because code coverage can assist in detecting bug-infested portions of code.
Better code quality since code coverage identifies portions of code that may contain errors.
Increased confidence in the codebase, as code coverage identifies untested code sections

Limitations of Code Coverage

Code coverage is a valuable metric for assessing code quality, but it has limitations:

High code coverage doesn't necessarily equate to high-quality code.
Perfect code coverage doesn't guarantee the absence of defects or that all functionalities are tested.
While code coverage measures code execution, it doesn't evaluate the test quality or overall system design.
Relying solely on code coverage might result in overlooking poorly written or inefficient tests.
Different tools may be required for various languages, adding to the implementation complexity.
Implementing code coverage can be time-intensive and costly.

Code Coverage Tools:

Coverage.Py for Python: This tool provides details on the execution status of Python code components and can be installed using pip install coverage.
JaCoCo for Java: Operated by JUnit tests, it offers results in binary format.
Testwell CTC++ for C++: Downloadable from third-party sites, it stands out by indicating the execution frequency of each code line, rather than just its execution status.

What is Test Coverage?

Test coverage plays a pivotal role in software creation and evaluation. It measures the extent of features tested, offering insights into potential risks. Unlike code coverage, which gauges the proportion of code executed in tests, test coverage focuses on feature validation. Ensuring comprehensive test coverage is vital for maintaining software quality and minimizing bugs.

While code coverage provides insights into the software's inner mechanics and guides improvement areas, test coverage offers a user-centric perspective.

Why Test Coverage?

The objective of assessing test coverage is to confirm that vital business needs are adequately tested, leaving no substantial testing voids. It entails evaluating if all pertinent scenarios, including edge cases, are addressed and if the tests are sufficient enough to spot potential problems. This evaluation aids in pinpointing testing deficiencies and highlighting areas for software improvement.

Measuring Test Coverage

Test coverage focuses on assessing the extent to which business requirements are examined, distinguishing it from code coverage. It offers a subjective insight into the thoroughness of tests in relation to business requirements rather than presenting a precise numerical value.

Key test coverage metrics include:

Specification Coverage: Verifies that every requirement of the software has undergone testing and is fulfilled.
Product Coverage: Confirms that every feature and component within the product has been scrutinized.
Risk Coverage: Highlights potential software vulnerabilities and checks if adequate tests have been conducted to address these concerns, minimizing potential challenges for users.
Functional Coverage: Assures that the software's functional criteria are comprehensively tested.
Test Execution Coverage: Offers insights into test outcomes, guaranteeing that the software undergoes rigorous testing prior to its official release.

Benefits of Test Coverage

Enhances software quality through comprehensive evaluation.
Diminishes the risk of new defects and resolves existing ones.
Easy to employ due to its black-box testing approach, requiring less code-specific knowledge.
Pinpoints untested components, ensuring all product features are validated.
Economizes on time and finances, reducing expensive bug corrections.
Boosts confidence in the product by ensuring holistic examination.
Facilitates quicker testing of code modifications, expediting release cycles.

Drawbacks of Test Coverage

Restricted scope, potentially missing issues like security risks or performance glitches.
Might give an overconfident perception of code quality.
The effectiveness hinges on the quality of the tests.
Inadequate test coverage can be like navigating blindly, posing unnecessary risks.

Test Coverage Tools:

PyUnit: A Python-based unit testing framework, PyUnit is renowned for facilitating the easy creation of test cases, tests, suites, and fixtures.
JUnit for Java: This open-source unit testing framework aids developers in tasks like writing, executing, and analyzing tests. Additionally, JUnit can handle user interface and regression testing.

Code Coverage vs. Test Coverage

Quantitative vs. Qualitative: Code coverage measures the percentage of lines of code tested, while test coverage gauges the depth and quality of tests.
Focus: Code coverage looks at executed lines of code, while test coverage assesses the thoroughness of the entire testing activity.
Approach: Code coverage employs a white-box testing method, examining the internal logic of the code. Test coverage, on the other hand, uses a black-box approach, considering the software's external functionality.
Usage: Typically, code coverage is applied in unit tests, while test coverage is used in integration or system tests.

Code Coverage or Test Coverage?

The choice between the two depends on specific goals. Both are crucial for a holistic testing approach.

Use code coverage during development to ensure every code line is tested. It's especially valuable for confirming specific code segments run during tests. On the other hand, when assessing the overall code efficacy, especially for performance, test coverage proves more beneficial, allowing swift issue resolution.

Each project's unique demands will guide the decision to employ either, or potentially both, types of coverage.

Summary

Both code and test coverage are critical metrics for determining software correctness. Code coverage verifies and validates code quality by evaluating the number of codes executed while running automated tests. It ensures that all parts of the code have been tested and that there are no defects or bugs present.

In comparison, test coverage is a measure of the overall quality of the testing process. Both metrics are important, and deciding which to use depends on your specific scenario.

References:

https://testsigma.com/blog/code-coverage-vs-test-coverage/
https://saucelabs.com/resources/blog/code-coverage-vs-test-coverage