
I was recently browsing Reddit and saw a developer mention how much they love the itertools module. One comment stuck with me:

> "On top of my head I think pairwise is my preferred. It is very useful in so many contexts."

If you’re building backends with FastAPI, "many contexts" usually means handling data streams, calculating changes, or optimizing database hits. Today, let’s look at two specific tools—pairwise and its newer sibling batched—and how they can transform your API code.

### Analyzing Trends with itertools.pairwise

In a financial app, you rarely care about a single price; you care about the change. pairwise (introduced in Python 3.10) is the cleanest way to compare a value with the one that came before it.

**The FastAPI Example: Stocks Volatility Checker**

Imagine an endpoint that receives a sequence of stock prices and needs to identify "volatile" moments where the price jumped more than 2% between ticks.

```python
from fastapi import FastAPI, HTTPException
from itertools import pairwise
from pydantic import BaseModel

app = FastAPI()

class StockData(BaseModel):
    symbol: str
    prices: list[float]

@app.post("/analyze-volatility")
async def analyze_volatility(data: StockData):
    if len(data.prices) < 2:
        raise HTTPException(status_code=400,
                            detail="Need at least 2 prices to compare")

    jumps = []
    # (p1, p2), (p2, p3), (p3, p4)...
    for prev_price, current_price in pairwise(data.prices):
        change = (current_price - prev_price) / prev_price

        if abs(change) > 0.02:  # Over 2% change
            jumps.append({
                "from": prev_price,
                "to": current_price,
                "change_percent": round(change * 100, 2)
            })

    return {"symbol": data.symbol, "volatile_moments": jumps}
```

The API endpoint can be tested with a simple curl request:

```bash
curl -X POST http://localhost:8000/analyze-volatility -H "Content-Type: application/json" -d '{"symbol": "AAPL", "prices": [150.0, 152.0, 151.0, 153.0, 154.0]}'
```

Before `pairwise`, we usually had to mess around with range indexes or "zip with a slice," which looked like this: `zip(prices, prices[1:])`. Not only is that harder to read, but it also creates an unnecessary copy of the list in memory.

**So why use it?**

- Zero Memory Overhead: It uses an iterator, meaning it yields values one by one rather than creating a new list.

- Less Logic Needed: Unlike chunking, pairwise creates an overlapping window. If you have [A, B, C, D], it yields:

(A, B)

(B, C)

(C, D)

- Excellent for: Calculation of deltas, trend analysis, and pathfinding (connecting point A to point B).

### Scaling with itertools.batched

While pairwise helps us read the data, batched (new in Python 3.12) helps us write or send it.
If you have 10,000 stock updates to save to a database or send to a third-party notification service, doing it one-by-one is a performance killer. You need to group them.

**The FastAPI Example: Bulk Notification Service**

Let's build a service that takes a massive list of price alerts and sends them to a messaging provider in batches of 10 to respect rate limits.

```python
from fastapi import FastAPI
from itertools import batched
import asyncio

app = FastAPI()

async def send_to_provider(batch):
    # Simulate an external API call
    await asyncio.sleep(0.1)
    print(f"Sent batch: {batch}")

@app.post("/push-alerts")
async def push_alerts(alerts: list[str]):
    # batched('ABCDEFG', 3) --> ABC, DEF, G
    count = 0
    for chunk in batched(alerts, 10):
        await send_to_provider(chunk)
        count += 1

    return {"status": "Alerts sent", "total_batches": count}

```

Batching (also known as chunking) is one of the most common patterns in backend engineering. Before Python 3.12, we had to use complicated "recipes" from the documentation or third-party libraries like more-itertools.

**So why use it?**

- The Efficiency Factor: In a FastAPI context, the biggest bottleneck is usually I/O (Input/Output).

- The Problem Solved: Sending 1,000 individual SQL INSERT statements or 1,000 separate HTTP requests creates massive overhead, therefore batched allows you to group these into a single database transaction or a single bulk API call.

- Pro-Tip: batched yields tuples. If your downstream function (like a database driver) requires a list, you can simply call list(chunk).

---

You don't always need a heavy data-processing library like Pandas to handle sequences. Sometimes, the most elegant solution is already sitting inside Python’s standard library. By using pairwise and batched, you make your FastAPI endpoints more readable and significantly more efficient.


pairwise and batched are two free power-ups that can be used to improve the performance of your Python backend, without much effort.

Python Backend Free Power-Ups: pairwise and batched


Testing visual elements is straightforward with Playwright, but how do you verify that a specific sound effect played when a user clicked a button or an in-game event occurred? Since automated browsers in CI pipelines don't have "ears," we have to get creative.

The easy answer is Monkey-patching for browser Web Audio APIs and the HTMLAudioElement to intercept audio playback and verify it in our test assertions.

The most reliable way to track audio in a browser is to override the global functions responsible for playing sound. This includes:

`HTMLAudioElement.prototype.play()`: For sounds triggered by `<audio>` tags or `new Audio().play()`.

`AudioBufferSourceNode.prototype.start()`: For sounds played using the Web Audio API, common in games and complex interactive experiences.

By overriding these methods, we can record every attempt to play a sound file into a global array on the window object, which Playwright can then inspect.

1. Creating the Audio Helper (as a fixture)
   First, let's build a clean, AudioMonitor class and wrap it in a Playwright fixture. This ensures that every test gets its own isolated instance of the monitor, preventing "state leaking" when running tests in parallel.

```typescript
// fixtures/audio-fixture.ts
import { test as base, Page } from '@playwright/test'

export class AudioMonitor {
  constructor(private page: Page) {}

  async start() {
    await this.page.addInitScript(() => {
      ;(window as any).soundsPlayed = []

      // --- 1. Patch Standard HTML5 Audio ---
      const originalHtmlAudioPlay = HTMLAudioElement.prototype.play
      HTMLAudioElement.prototype.play = function (...args) {
        const soundName =
          this.src.split('/').pop()?.split('.')[0] || 'unknown_html_audio'

        ;(window as any).soundsPlayed.push({
          name: soundName,
          src: this.src,
          type: 'HTMLAudio',
          timestamp: Date.now(),
        })

        return originalHtmlAudioPlay.apply(this, args)
      }

      // --- 2. Patch Web Audio API ---
      const originalBufferSourceStart = AudioBufferSourceNode.prototype.start
      AudioBufferSourceNode.prototype.start = function (...args) {
        const soundName =
          (this as any).audioName ||
          (this.buffer
            ? `buffer_len_${this.buffer.length}`
            : 'unknown_web_audio')

        ;(window as any).soundsPlayed.push({
          name: soundName,
          type: 'WebAudio',
          timestamp: Date.now(),
        })

        return originalBufferSourceStart.apply(this, args)
      }
    })
  }

  async getPlayedSounds(): Promise<string[]> {
    return await this.page.evaluate(() => {
      return (window as any).soundsPlayed?.map((s: any) => s.name) || []
    })
  }

  async verifyExpectedSounds(expectedSounds: string[]) {
    const playedSounds = await this.getPlayedSounds()
    const missing = expectedSounds.filter(
      expected => !playedSounds.some(played => played.includes(expected))
    )
    return { played: playedSounds, missing }
  }
}
```

In my case, I use a base fixture to extend the Playwright test fixture and include the audioMonitor fixture.

```typescript
// Extend Playwright's base test to include our audioMonitor fixture
export const test = base.extend<{ audioMonitor: AudioMonitor }>({
  audioMonitor: async ({ page }, use) => {
    const monitor = new AudioMonitor(page)
    await monitor.start()
    await use(monitor)
    // Cleanup is automatic as the window object is destroyed with the page
  },
})

export { expect } from '@playwright/test'
```

2. Now use it in your tests:

```typescript
// tests/audio-feature.spec.ts
import { test, expect } from '../fixtures/audio-fixture'

const SOUNDS = ['sound_1', 'sound_2', 'sound_3', 'sound_4']

test('should play expected sounds when audio is ON', async ({
  page,
  audioMonitor,
}) => {
  await page.goto('/somepage')

  // Trigger action that should play the expected sounds
  await page.getByTestId('somebuttonid').click()

  const { missing } = await audioMonitor.verifyExpectedSounds(SOUNDS)

  expect(missing.length, `Missing sounds: ${missing.join(', ')}`).toBe(0)
})
```

Pros of this approach:

- Fixture-Based Isolation: Unlike singletons, fixtures are local to the test worker. This is critical for parallel execution.

- Headless Friendly: This solution doesn't rely on system audio output, making it perfect for CI/CD environments (Docker, GitHub Actions) where no sound card exists.

- Zero Dependencies: It leverages native browser APIs and Playwright’s built-in addInitScript and test.extend capabilities.

- Timing & Sequence: Because we capture a timestamp for every sound, you can even assert that "Sound A" played before "Sound B."

- Traceability: Because these interactions happen in the browser context, these "sounds" will actually show up in your Playwright Console Logs if you add the console.log mentioned above, making the Playwright HTML Report much more descriptive.

Cons of this approach:

While powerful, this method captures the intent to play audio. It doesn't guarantee that the user actually heard it (e.g., if the OS volume is zero or a physical speaker is unplugged). However, for functional E2E verification, ensuring the application code correctly calls the playback APIs is the gold standard for automated testing.


How to test browser audio in Playwright by intercepting HTML5 and Web Audio API calls—ensuring reliable sound tests.

Testing Browser Audio with Playwright


In this blog post I will share my experience with building a native Raycast extension for repository management, which is one of my "daily drivers" on my Mac to improve my productivity and efficiency. Note there are endless possibilities and you can build anything you can imagine with Raycast.

In the past I was juggling between multiple repositories across different directories and various subdirectories like which cloned into a specific project directory. At some point I needed a fast way to open projects in Cursor. My initial solution was a shell script using AppleScript dialogs, but it had annoying issues:

- **Focus problems** - dialogs appeared in the background
- **Requires mouse** - couldn't navigate with keyboard only
- **Not native** - felt clunky and out of place

Therefore, the solution was to build a native Raycast extension that provides:

- **Repo discovery** - discover repositories across different directories and subdirectories
- **Repo focus** - always appears where Raycast is
- **Keyboard-first** - arrow keys + Enter to select
- **Live filtering** - type to search repositories instantly
- **Multiple actions** - open in Cursor, Finder, Terminal, or copy path
- **Native feel** - looks and behaves like built-in Raycast commands

So let's show an example of how to do this.

Create a new directory and initialize the project:

```bash
mkdir my-repo-extension
cd my-repo-extension
npm init -y
npm install @raycast/api
```

Create `package.json` with the Raycast extension schema:

```json
{
  "$schema": "https://www.raycast.com/schemas/extension.json",
  "name": "repository-opener",
  "title": "Repository Opener",
  "description": "Open repositories from ~/work and ~/git directories in Cursor", // these are the directories you want to scan for repositories
  "icon": "📁",
  "author": "your-name",
  "categories": ["Developer Tools"],
  "commands": [
    {
      "name": "list-repos",
      "title": "Open Repo",
      "subtitle": "Repository Opener",
      "description": "List and open repositories",
      "mode": "view",
      "keywords": ["repo", "repository"]
    }
  ],
  "dependencies": {
    "@raycast/api": "^1.62.0"
  },
  "scripts": {
    "build": "ray build -e dist",
    "dev": "ray develop"
  }
}
```

Create `src/list-repos.jsx`:

```jsx
import {
  List,
  ActionPanel,
  Action,
  showToast,
  Toast,
  Icon,
} from "@raycast/api";
import { execSync } from "child_process";
import { useState, useEffect } from "react";
import path from "path";
import os from "os";

function getRepositories() {
  const homeDir = os.homedir();
  const allRepos = [];

  // Scan main directories
  const mainDirs = [
    path.join(homeDir, "work"),
    path.join(homeDir, "git") // these are the directories you want to scan for repositories
  ];

  for (const dir of mainDirs) {
    try {
      const output = execSync(
        \`find "\${dir}" -maxdepth 1 -mindepth 1 -type d 2>/dev/null\`,
        { encoding: "utf8" }
      );
      const repos = output.split("\\n").filter(Boolean);

      for (const repoPath of repos) {
        const repoName = path.basename(repoPath);
        const parentDir = path.basename(path.dirname(repoPath));
        allRepos.push({
          name: repoName,
          path: repoPath.trim(),
          parent: parentDir,
        });
      }
    } catch (error) {
      // Skip if directory doesn't exist
    }
  }

  // Also scan subdirectories (myproject, myproject2, etc.)
  const subDirs = [
    path.join(homeDir, "work", "myproject"),
    path.join(homeDir, "git", "myproject2"),
    path.join(homeDir, "work", "myproject"),
    path.join(homeDir, "git", "myproject2"),
  ];

  for (const dir of subDirs) {
    try {
      const output = execSync(
        \`find "\${dir}" -maxdepth 1 -mindepth 1 -type d 2>/dev/null\`,
        { encoding: "utf8" }
      );
      const repos = output.split("\\n").filter(Boolean);

      for (const repoPath of repos) {
        const repoName = path.basename(repoPath);
        const grandParent = path.basename(path.dirname(path.dirname(repoPath)));
        const parent = path.basename(path.dirname(repoPath));
        allRepos.push({
          name: repoName,
          path: repoPath.trim(),
          parent: \`\${grandParent}/\${parent}\`,
        });
      }
    } catch (error) {
      // Skip if directory doesn't exist
    }
  }

  // Remove duplicates and sort
  const uniqueRepos = allRepos.filter(
    (repo, index, self) => index === self.findIndex((r) => r.path === repo.path)
  );

  return uniqueRepos.sort((a, b) => a.name.localeCompare(b.name));
}

async function openInCursor(repoPath, repoName) {
  try {
    const cursorPaths = ["/usr/local/bin/cursor", "/opt/homebrew/bin/cursor"];

    let cursorCommand = null;
    for (const cursorPath of cursorPaths) {
      try {
        execSync(\`test -x "\${cursorPath}"\`, { stdio: "ignore" });
        cursorCommand = cursorPath;
        break;
      } catch (error) {
        continue;
      }
    }

    if (cursorCommand) {
      execSync(\`"\${cursorCommand}" "\${repoPath}"\`, { stdio: "ignore" });
    } else {
      execSync(\`open -a "Cursor" "\${repoPath}"\`, { stdio: "ignore" });
    }

    showToast(Toast.Style.Success, "Success", \`Opening \${repoName} in Cursor\`);
  } catch (error) {
    showToast(Toast.Style.Failure, "Error", "Failed to open repository");
  }
}

export default function Command() {
  const [repositories, setRepositories] = useState([]);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    const fetchRepos = async () => {
      setIsLoading(true);
      const repos = getRepositories();
      setRepositories(repos);
      setIsLoading(false);
    };

    fetchRepos();
  }, []);

  return (
    <List isLoading={isLoading} searchBarPlaceholder="Search repositories...">
      {repositories.map((repo) => (
        <List.Item
          key={repo.path}
          title={repo.name}
          subtitle={repo.parent}
          accessories={[{ text: repo.path }]}
          icon={Icon.Folder}
          actions={
            <ActionPanel>
              <Action
                title="Open in Cursor"
                icon={Icon.Code}
                onAction={() => openInCursor(repo.path, repo.name)}
                closeOnAction={true}
              />
              <Action.Open
                title="Open in Finder"
                target={repo.path}
                application="Finder"
                icon={Icon.Finder}
              />
              <Action.CopyToClipboard
                title="Copy Path"
                content={repo.path}
                icon={Icon.CopyClipboard}
              />
              <Action.Open
                title="Open in Terminal"
                target={repo.path}
                application="Terminal"
                icon={Icon.Terminal}
              />
            </ActionPanel>
          }
        />
      ))}
    </List>
  );
}
```

Now build the extension and add it to Raycast:

```bash
npm run build

# Add to Raycast
# Open Raycast Settings > Extensions > Add Local Extension
# Select your project folder
```

1. Open Raycast (Cmd + Space)
2. Type "repo" to find your command
3. Start typing to filter repositories
4. Press Enter to open in Cursor
5. Raycast automatically closes!

The script extension will have the following features:

### **Smart Repository Discovery**

The extension scans multiple directory patterns:

- `~/work/*` and `~/git/*` for main repositories
- `~/work/myproject/*` for project subdirectories
- Easy to extend for your own directory structure

### ⌨️ **Keyboard-First Navigation**

- Type to filter repositories instantly
- Arrow keys to navigate
- Enter to open (primary action)
- Tab to see secondary actions

### 🎯 **Multiple Actions**

Each repository offers several actions:

- **Open in Cursor** (primary) - opens the project
- **Open in Finder** - for file browsing
- **Copy Path** - quick path copying
- **Open in Terminal** - launch terminal in repo

### 🚀 **Auto-Close Behavior**

The `closeOnAction={true}` prop makes Raycast disappear after opening a repository, creating a smooth workflow.

What else i'm going to leverage using Raycast?

- **Project Templates** - Create new projects from templates
- **Environment Manager** - Switch between development environments
  and more...

![open-repo-with-raycast](/images/raycast-kazi-repo.png)

---

_Have you built any cool Raycast extensions? Please share them with me!_


A simple example of how you can leverage Raycast to improve your workflow.

Raycast For Developers


As developers, we've all been there: pushing commit after commit just to test a GitHub Actions workflow, waiting for runners to spin up, only to discover a simple syntax error or logic bug. What if I told you there's a better way? Here enters `act` - a tool that lets you run GitHub Actions locally using Docker containers.

So what exactly is act?

act is an open-source tool that reads your GitHub Actions workflow files and runs them locally using Docker containers that closely mimic GitHub's hosted runners. Think of it as a local simulator for your CI/CD pipelines. The tool was created to solve a fundamental problem: the slow feedback loop when developing GitHub Actions. Instead of the traditional "commit, push, wait, debug, repeat" cycle, act lets you iterate quickly on your local machine.

Under the hood, act performs several key operations, such as:

- Parsing your workflow files (.github/workflows/\*.yml).
- Creating Docker containers that match GitHub's runner environments.
- Mounting your repository into the container.
- Executing the workflow steps just like GitHub would, but locally.
- Providing real-time feedback in your terminal.

act uses container images that replicate the Ubuntu, Windows, and macOS environments that GitHub provides, complete with pre-installed tools and software.

### Installation and Basic Usage

```bash
# via Homebrew
brew install act

# via curl
curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash
```

```bash
# Run all workflows
act

# Test specific events
act push
act pull_request
act workflow_dispatch

# Test specific workflow file
act -W .github/workflows/my-workflow.yml

# Dry run to see what would execute
act --dry-run
```

Let's try to look at a simple workflow file and see how it works. This workflow should be triggered on a pull requests and pushes.
In terms of functionality, it should detect changes in a large JSON file and if there are changes, it should run a script to update the file.
It also validates each modified JSON file in parallel and provide feedback on some required validations.

Most of the logic is handheld in a script or composite action, it's just for the sake of the example.

Here's a simplified version of the workflow:

```yaml
name: Config Validation

on:
  pull_request:
  push:
    branches: [master]
  workflow_dispatch:
    inputs:
      config_path:
        description: 'Specific config file to validate'
        required: false

jobs:
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      has-changes: ${{ steps.changes.outputs.has-changes }}
      configs: ${{ steps.changes.outputs.configs }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Detect changed config files
        id: changes
        run: |
          if [ "${{ github.event_name }}" = "workflow_dispatch" ] && [ -n "${{ inputs.config_path }}" ]; then
            CONFIG_PATH="${{ inputs.config_path }}"
            echo "Manual validation requested for: $CONFIG_PATH"
            echo "has-changes=true" >> $GITHUB_OUTPUT
            echo "configs=[\"$CONFIG_PATH\"]" >> $GITHUB_OUTPUT
            exit 0
          fi

          if [ "${{ github.event_name }}" = "pull_request" ]; then
            BASE_SHA="${{ github.event.pull_request.base.sha }}"
          else
            BASE_SHA="HEAD~1"
          fi

          CHANGED_FILES=$(git diff --name-only $BASE_SHA HEAD -- 'configs/' | grep '\.json$' || true)

          if [ -z "$CHANGED_FILES" ]; then
            echo "No config files changed"
            echo "has-changes=false" >> $GITHUB_OUTPUT
            echo "configs=[]" >> $GITHUB_OUTPUT
            exit 0
          fi

          # Assuming 'jq' is available on the runner (it is on GitHub's default runners)
          CONFIGS_JSON=$(echo "$CHANGED_FILES" | jq -R -s -c 'split("\n") | map(select(length > 0))')
          echo "has-changes=true" >> $GITHUB_OUTPUT
          echo "configs=$CONFIGS_JSON" >> $GITHUB_OUTPUT

  validate-configs:
    needs: detect-changes
    if: needs.detect-changes.outputs.has-changes == 'true'
    runs-on: ubuntu-latest
    strategy:
      matrix:
        config: ${{ fromJson(needs.detect-changes.outputs.configs) }}
      fail-fast: false
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Validate config file
        run: |
          echo "🔍 Validating: ${{ matrix.config }}"
          npm run validate-config -- "${{ matrix.config }}"
```

### Testing with act

```bash
# Test the entire workflow
act workflow_dispatch

# Test with specific input
act workflow_dispatch --input config_path="configs/app-settings.json"

# Test pull request simulation
act pull_request

# Debug with verbose output
act workflow_dispatch -v
```

This few simple commands saved me a lot of time when developing and testing the workflow.

Although it's not a perfect solution, it's a great tool to have in your arsenal when developing and testing GitHub Actions workflows. Let's look at some of its limitations that you should be aware of.

- Limited GitHub Features: No access to GitHub's REST API, can't post PR comments or update statuses, some GitHub-specific contexts might not work.
- Container Image Sizes: The full GitHub runner images are large (several GB), though act offers smaller alternatives.
- Platform Differences: On some cases, there might be differences between local Docker containers and GitHub's actual runners that can occasionally cause issues.

Some usage tips to take it further:

1. Use the `--reuse` flag to reuse containers between runs, this can speed up the process significantly.
2. Use the `--container-architecture` flag to specify the architecture of the container image to use.
3. Use the `--verbose` flag to get more detailed output.
4. Use the `--dry-run` flag to see what would execute without actually running it.
5. Use the `--list-workflows` flag to list all available workflows.
6. Make sure to run your scripts (if you use any in your workflows) independently, so you can test them separately.

Make sure to check the [act repository](https://github.com/nektos/act) for more details and advanced usage.


If you're working with GitHub Actions and workflows I'm sure you've encountered the pain of testing them. This is the solution for you.

Testing your GitHub Workflows Locally


Before I joined my current team, the word "dependency injection" felt like an academic buzzword. We built some of our services in Go, and frankly, I didn't see the point of introducing a framework for something that could be done manually.

That mindset changed the moment we had to write robust integration tests for a new a complex API. Our challenge was to ensure a critical user flow—involving user authentication, data processing, and persistence—worked flawlessly. We needed to test the service without hitting a real, shared database instance, which would lead to flaky, non-deterministic tests.

This is where dependency injection (DI), and specifically the fx framework, transformed our approach.

#### The Problem: Tightly Coupled Components

Here's a simplified example to illustrate the problem. Our service, in its initial form, was a mess of hard-coded dependencies. An OrderProcessor would directly instantiate a DatabaseClient, which made testing difficult. We couldn't swap out the real database for a mock since the OrderProcessor was tightly coupled to the concrete implementation.

```go
// Tightly coupled code
type OrderProcessor struct {
    dbClient *database.Client // A concrete implementation
}

func NewOrderProcessor() *OrderProcessor {
    // The dependency is created inside the service itself
    client := database.NewClient(options)
    return &OrderProcessor{dbClient: client}
}
```

This is a classic violation of the Dependency Inversion Principle, where high-level modules (our OrderProcessor) shouldn't depend on low-level modules (the DatabaseClient implementation). Instead, both should depend on abstractions (interfaces).

#### The Solution: Inverting Control with fx

Fx allowed us to flip this on its head. We refactored our code to depend on interfaces.

First, we defined the contracts:

```go
// An abstraction for the database client
type DatabaseClient interface {
    Get(key string) (string, error)
    Put(key, value string) error
}

// An abstraction for our service
type OrderProcessor interface {
    ProcessOrder(orderID string) error
}
```

Next, we made our OrderProcessor a provider function that simply declared what it needs to work:

```go
// Our service now depends on the DatabaseClient interface, not a concrete type.
func NewOrderProcessor(db DatabaseClient, logger Logger) OrderProcessor {
    return &orderProcessor{
        db:  db,
        logger: logger,
    }
}
```

The magic of fx is that it handled the "wiring." In our main application, we provided the real implementations.

```go
// In main.go for production
app := fx.New(
    fx.Provide(NewDatabaseClient), // Provides the real database client
    fx.Provide(NewLogger),         // Provides the real logger
    fx.Provide(NewOrderProcessor),
    fx.Invoke(StartService),
)
```

As for our integration tests, we did something completely different. We provided mock implementations instead.

#### The Payoff: Integration Tests with Confidence

This is where DI truly shines. Our test suite could now create an fx application that uses fakes and mocks.

```go
// In order_processor_test.go
func TestOrderProcessor(t *testing.T) {
    // Create a mock database client for the test.
    mockDB := &MockDatabaseClient{}
    mockLogger := &MockLogger{}

    // Manually create the service with the mock dependencies.
    service := NewOrderProcessor(mockDB, mockLogger)

    // Now we can test the service's logic without any external dependencies.
    orderID := "order-123"

    // This test runs in milliseconds because it doesn't need a real database connection.
    err := service.ProcessOrder(orderID)
    assert.NoError(t, err)

    // We can even assert on what methods were called on our mock.
    assert.Equal(t, 1, mockDB.Calls("Get"))
}
```

This approach gave us several powerful benefits:

- Speed: Our tests went from being slow and network-dependent to running in a fraction of a second.

- Reliability: Tests no longer failed due to network latency, connection issues, or shared state. They were completely deterministic.

- Isolation: We could test our OrderProcessor logic in complete isolation from the external world, ensuring it did exactly what we expected with the dependencies we provided.

- Code Clarity: The dependency signatures made it immediately obvious what each component needed to function.

Ultimately, integrating fx wasn't about adding complexity; it was about embracing a pattern that simplified our application's design and made it infinitely more testable and maintainable. For any developer building a service with external dependencies, DI is not just a good practice—it's a game-changer.


From slow, flaky tests to fast, reliable ones. Using Go's Fx framework to build maintainable and testable services.

Go's Fx: Dependency Injection To Easily Unlock Your Integration Tests


I first got to know NotebookLM from a YouTuber I follow, who recommended this amazing tool for analyzing financial reports of public companies. As an investor in the stock market, I was intrigued, but as a software developer, I got even more excited. I immediately started thinking about how I could apply and leverage this to my own work. Could it help me manage documentation, understand complex PRDs or requirements, design a TLD, HLD or even brainstorm new features? The answer is yes.

So basically, for those who are not familiar with NotebookLM, it is a personal research assistant that can go through vast amounts of documentation (docs, links, videos, etc.), generate summaries, and even help you brainstorm. It’s an incredibly powerful tool for software developers looking to boost their effectiveness.

#### Things you can do with NotebookLM:

**Learn a New Codebase:**
When you join a new large project, the first few weeks could be blur of documentation and code. Instead of spending days manually reading through hundreds of files, you can upload key modules, architecture diagrams, and design documents to NotebookLM.

Then, you can ask NotebookLM to "Summarize the core functionality of the OrderProcessing module." (which is of course an example module).
You can also solve questions with it by simply prompting "Explain why the UserAuthentication service interacts with the Database layer in this specific way."

**Streamlining Project Planning and Requirements:**
Project specifications, user stories, and technical requirements can be a mess sometimes. I'm sure most of you are familiar with how much its easy to give up on tools like Confluence for example, which can become a hell of outdated documents and projects. Therefore, you can upload all related documents for a new feature; PRDs, the technical design doc, and the user stories.

Then you can consolidating information. I ask it to "List all the user-facing requirements for the new dashboard" or "What are the key dependencies for implementing Feature X?"

You can also leverage it for test cases ideas based on user stories.

![NotebookLM Mind Map](https://res.cloudinary.com/dtt2usukl/image/upload/v1756379322/NotebookLM-Mind-Map-Apollo_y7mqps.webp)_NotebookLM Mind Map_

**Learning Assistant:**
Learning new languages, frameworks, and tools is a constant part of a developer's life. I've started using NotebookLM as my personalized study guide. I upload tutorials, documentation, and best-practice guides from the web and usually generate it as a "podcast" which I find much more efficient to learn something new.

You can ask it to explain concepts, comparison of different technologies or frameworks, and some other specific questions.

By grounding its responses in my chosen learning materials, NotebookLM becomes a highly effective tutor tailored specifically to my needs.

![NotebookLM](https://res.cloudinary.com/dtt2usukl/image/upload/v1756379148/Screenshot_2025-08-28_at_14.04.51_iyzlov.png)_Summarizing an article to a short podcast_

---

I encourage you to give it a try and let me know what you think!


Summarize articles, reports, create mind maps, brainstorm features & generate test cases ideas based on your data using NotebookLM.

Get Smarter With NotebookLM


If performance and SEO is a fundamental aspect of your website, you should be monitoring it. Playwright & Lighthouse integration is an excellent way to start.

This setup allows you to run performance audits as part of your regular test suite, catching performance regressions before they reach production.

### Why Combine Playwright with Lighthouse?

Lighthouse is Google's open-source tool for improving web page quality. It audits performance, accessibility, SEO, and best practices. However, running Lighthouse manually or through basic CI scripts doesn't integrate well with your existing test infrastructure. Playwright, on the other hand, is excellent for browser automation but doesn't have built-in performance auditing capabilities. By combining them, you get:

- Automated performance regression testing
- Integration with your existing Playwright test suite
- Consistent browser environments across tests
- Detailed performance metrics and reports
- CI/CD pipeline integration

### Setting Up the Integration

Let's start by installing the required dependencies. You'll need Playwright and the `playwright-lighthouse` integration library:

```bash
npm install --save-dev @playwright/test playwright playwright-lighthouse get-port
```

The `get-port` package is crucial for managing ports dynamically, ensuring tests don't conflict with each other.

### Creating the Lighthouse Test Fixture

The key to this integration is setting up a proper Playwright fixture that manages the Chrome debugging port. Here's an example setup:

```typescript
// tests/performance/lighthouse.ts
import { chromium, Browser } from 'playwright'
import { test as base } from '@playwright/test'

const getPortPromise = import('get-port')

type LighthouseFixtures = {
  port: number
  browser: Browser
}

export const lighthouseTest = base.extend<{}, LighthouseFixtures>({
  port: [
    async ({}, use) => {
      const { default: getPort } = await getPortPromise
      const port = await getPort()
      await use(port)
    },
    { scope: 'worker' },
  ],

  browser: [
    async ({ port }, use) => {
      const browser = await chromium.launch({
        args: [`--remote-debugging-port=${port}`],
      })
      await use(browser)
    },
    { scope: 'worker' },
  ],
})

export const test = lighthouseTest
```

**What's happening here?**

1. **Dynamic Port Allocation**: `get-port` ensures each test worker gets a unique debugging port, preventing conflicts in parallel execution
2. **Worker Scope**: Both fixtures use `worker` scope, meaning they're shared across tests in the same worker process
3. **Chrome Remote Debugging**: The browser launches with `--remote-debugging-port`, which Lighthouse needs to connect and run audits

### Now for the actual tests measurement

Now let's create actual performance tests. The beauty of this approach is that you can test multiple pages with different performance thresholds:

```typescript
// tests/performance/lighthouse.spec.ts
import { test } from './lighthouse'

const thresholds = {
  accessibility: 90,
  'best-practices': 90,
  seo: 90,
}

const urlsToTest = [
  { name: 'Homepage', uri: '/' },
  { name: 'About Page', uri: '/about' },
  { name: 'Blogs Page', uri: '/blogs' },
]

test.describe('Lighthouse Audits', () => {
  for (const pageInfo of urlsToTest) {
    test(`Check Lighthouse scores for ${pageInfo.name}`, async ({
      page,
      port,
    }) => {
      await page.goto(`http://someurl.com`)
      const { playAudit } = await import('playwright-lighthouse')
      await playAudit({
        page,
        port,
        thresholds,
      })
    })
  }
})
```

Few things to note here - You do have a clear method for flexible thresholds, then you can set different performance standards for different pages, which can be crucial for dynamic websites which various different pages and content.
Also, in this way you can easily add new pages.

When you run these tests, Lighthouse evaluates several key areas which you should be familiar with:

### Performance Metrics

- **First Contentful Paint (FCP)**: When the first text/image appears
- **Largest Contentful Paint (LCP)**: When the main content is likely loaded
- **Speed Index**: How quickly content is visually displayed
- **Cumulative Layout Shift (CLS)**: Visual stability measure

### Other Audits

- **Accessibility**: Screen reader compatibility, color contrast, ARIA labels
- **Best Practices**: HTTPS usage, console errors, deprecated APIs
- **SEO**: Meta tags, structured data, "crawlability"

### Advanced Configuration Options

You can customize the Lighthouse configuration for more specific testing needs:

```typescript
const advancedThresholds = {
  performance: 85,
  accessibility: 95,
  'best-practices': 90,
  seo: 90,
  pwa: 80,
}

const lighthouseConfig = {
  extends: 'lighthouse:default',
  settings: {
    onlyCategories: ['performance', 'accessibility', 'best-practices', 'seo'],
    skipAudits: ['uses-http2'], // Skip specific audits if needed
  },
}

// In your test
await playAudit({
  page,
  port,
  thresholds: advancedThresholds,
  config: lighthouseConfig,
  reports: {
    formats: {
      html: true,
      json: true,
    },
    name: `lighthouse-report-${pageInfo.name}`,
    directory: './lighthouse-reports',
  },
})
```

### Integration with Playwright Config

Your `playwright.config.ts` should include a dedicated performance testing project:

```typescript
// playwright.config.ts
import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  testDir: './tests',
  projects: [
    // ... other projects
    {
      name: 'Performance',
      fullyParallel: true,
      testDir: './tests/performance',
      use: {
        headless: true, // Performance tests should run headless
      },
    },
  ],
})
```

### Running the Tests

Execute your performance tests with a dedicated npm script:

```json
{
  "scripts": {
    "test:performance": "npx playwright test --project=Performance"
  }
}
```

Before running the tests, make sure your development server is running:

```bash
# Terminal 1: Start your app
npm run dev

# Terminal 2: Run performance tests
npm run test:performance
```

### CI/CD Integration

For continuous integration, you'll want to build and serve your application statically. Here we're using a simple GitHub Actions workflow to run the tests.

```yaml
# .github/workflows/performance.yml
name: Performance Tests

on: [push, pull_request]

jobs:
  performance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '22'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build application
        run: npm run build

      - name: Start server and run tests
        run: |
          npm start &
          npx wait-on http://localhost:3000
          npm run test:performance
```

### Best Practices and Tips

#### 1. Set Realistic Thresholds

Don't start with perfect scores (100/100). Begin with current performance levels and gradually improve:

```typescript
const realisticThresholds = {
  performance: 70, // Start here, aim for 90+
  accessibility: 85, // Should be high from the start
  'best-practices': 80,
  seo: 75,
}
```

#### 2. Test Multiple Device Types

Lighthouse can simulate different devices:

```typescript
await playAudit({
  page,
  port,
  thresholds,
  config: {
    extends: 'lighthouse:default',
    settings: {
      emulatedFormFactor: 'mobile',
      throttling: {
        rttMs: 150,
        throughputKbps: 1600,
        cpuSlowdownMultiplier: 4,
      },
    },
  },
})
```

#### 3. Handle Dynamic Content

For pages with dynamic content, ensure they're fully loaded before auditing:

```typescript
test('Performance test with dynamic content', async ({ page, port }) => {
  await page.goto('http://localhost:3000/dashboard')

  // Wait for dynamic content to load
  await page.waitForSelector('[data-testid="dashboard-content"]')
  await page.waitForLoadState('networkidle')

  const { playAudit } = await import('playwright-lighthouse')
  await playAudit({ page, port, thresholds })
})
```

#### 4. Monitor Performance Over Time

Store results and track performance trends:

```typescript
const results = await playAudit({
  page,
  port,
  thresholds: {}, // Don't fail on thresholds, just collect data
  reports: {
    formats: { json: true },
    directory: './performance-history',
  },
})

// Store results in your preferred monitoring system
await storePerformanceMetrics(results, pageInfo.name)
```

### Troubleshooting Common Issues

#### Port Conflicts

If you encounter port conflicts, ensure you're using `get-port` correctly and that tests aren't running in shared browser contexts.

#### Timeout Errors

Increase Playwright's timeout for performance tests:

```typescript
test.setTimeout(60000) // 60 seconds for performance tests
```

#### Inconsistent Results

Performance can vary between runs. Consider:

- Running tests multiple times and averaging results
- Using consistent hardware in CI
- Disabling CPU throttling for development testing

---

That's it. Would love to hear your thoughts and feedback.


Integrate Lighthouse performance audits into your Playwright test suite for automated performance monitoring and regression testing.

Measure Website Performance with Playwright & Lighthouse


You've built a high-performance Python application using asyncio, but you've noticed a bottleneck. The culprit? Your logging. This is a common issue as logging seems to be a a trivial operation, but it can be a significant performance killer.

By default, Python's logging module uses blocking handlers, which means your application pauses every time it writes a log message.
Before we delve right in, it's important to say that in most cases, synchronous logging is perfectly fine. It's simple, reliable, and the default behavior. It works well for applications that aren't I/O-bound or where logging operations are infrequent.

But if you're building a high-performance I/O-bound application, you'll want to consider asynchronous logging. This article will walk you through why traditional logging can slow down your code and how to implement a simple yet effective asynchronous logging solution using Python's standard library.

Why do we even need to care about async logging? Here's a simple example:

```python
import logging
import time

logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(message)s')

def process_data(item):
    """Simulates a blocking data processing task."""
    logging.info(f"Starting to process item: {item}")
    time.sleep(0.1)  # Simulates work
    logging.info(f"Finished processing item: {item}")

if __name__ == "__main__":
    data_items = range(5)
    for item in data_items:
        process_data(item)

    logging.info("All data processed.")
```

When you move into a high-concurrency environment, this approach falls apart.

With the Async logging approach, instead of writing directly to a file or a remote service, log messages are placed in a queue and processed in a separate thread. This allows your primary application code to continue executing without waiting for the I/O to complete.

Imagine a web server handling thousands of concurrent requests. If each request logs synchronously, the application spends valuable time waiting for log files to be written. This increases latency and drastically reduces the number of requests it can handle per second. Asynchronous logging solves this by offloading the logging work to a background thread.

The good part, is you don't need a third-party library to achieve this. Python's standard library provides the `logging.handlers.QueueHandler` and `logging.handlers.QueueListener` for this exact purpose.

First, create a Queue, then use QueueHandler.
By using these, you'll create a thread-safe queue that will hold the log messages, then, the your main application logger will use the QueueHandler to put log records into the queue. This is a non-blocking operation, so your app remains fast.

Lastly, use QueueListener. It runs in a separate thread. It reads messages from the queue and passes them to a "worker handler" (e.g., a FileHandler) that performs the actual, slow I/O operation.

Here's another code example:

```python
import logging
from logging.handlers import QueueHandler, QueueListener
from queue import Queue
import threading
import time
import asyncio

# 1. Setup a queue for logging
log_queue = Queue(-1)

# 2. Setup the worker handler that will actually write the logs
worker_handler = logging.FileHandler("async_app.log")
worker_handler.setFormatter(logging.Formatter('%(asctime)s - %(message)s'))

# 3. Setup the listener in a separate thread
listener = QueueListener(log_queue, worker_handler)
listener.start()

# 4. Setup the main application logger to use the QueueHandler
async_handler = QueueHandler(log_queue)
logger = logging.getLogger('my_async_app')
logger.addHandler(async_handler)
logger.setLevel(logging.INFO)

async def handle_request(request_id):
    """Simulates a fast, asynchronous request handler."""
    logger.info(f"Async: Starting request {request_id}")
    await asyncio.sleep(0.01)  # Simulate non-blocking work
    logger.info(f"Async: Finishing request {request_id}")

async def main():
    """Simulates a high-concurrency environment."""
    tasks = [handle_request(i) for i in range(10)]
    await asyncio.gather(*tasks)

if __name__ == "__main__":
    start_time = time.time()
    asyncio.run(main())
    end_time = time.time()
    logger.info(f"Total time elapsed: {end_time - start_time:.4f} seconds")

    # It's important to stop the listener gracefully
    listener.stop()
```

Happy logging!


Focusing on high performance I/O bound Python Applications? Do not forget Asynchronous logging to prevent bottlenecks in your app.

Welcome toKazi's Dev Blog

Latest Articles