DEV Community: Noor ul hassan

Blockend Logger vs Traditional Pino Logger

Noor ul hassan — Sat, 18 Jul 2026 13:31:04 +0000

Logging is essential, but setting it up with Pino often means boilerplate: installing packages, wiring middleware, passing request IDs manually, and configuring redaction yourself. It works, but it’s repetitive.

Blockend Logger takes a different approach. It uses Pino under the hood but generates a ready‑to‑use, type‑safe logger block directly into your project. You own the code, you can debug it, and you can change it.

Why Blockend Logger Feels Different

Shared logger instance across your app
Automatic request ID propagation with AsyncLocalStorage
Framework adapters generated automatically (Express, Fastify, Hono)
Request logging out of the box
Built‑in redaction for sensitive fields
Pretty logs in dev, JSON logs in prod
TypeScript support baked in

Honest Comparison

Feature	Blockend Logger	Traditional Pino
Setup	`blockend-cli add logger`	Manual install + config
Request IDs	Automatic	Manual middleware
Framework integration	Auto‑generated adapter	Write your own
Request logging	Built‑in	Add middleware manually
Redaction	Preconfigured	Manual setup
Output modes	Pretty dev / JSON prod	Configure transports yourself
TypeScript	Generated `.ts` files	Manual typings

Blockend isn’t replacing Pino — it’s making Pino easier to use. If you want raw control, stick with Pino. If you want sane defaults and less boilerplate, Blockend Logger saves you time.

Learn More

Docs: Blockend Logger Documentation
Source: Blockend on GitHub

Final Word

Logging should help you debug, not slow you down. Blockend Logger is basically “Pino with batteries included.” If you love it, star it on GitHub — that’s the best way to support the project and help more developers discover it.

Build a Dynamic Array in C from Scratch

Noor ul hassan — Tue, 14 Jul 2026 13:04:46 +0000

Build a Dynamic Array in C from Scratch

You've used push() in JavaScript, append() in Python, add() in Java. They feel instant. They never run out of space. You never think about them.

That's a problem — not because those abstractions are bad, but because you're using a tool without knowing what it costs. Every one of those methods is built on ideas you can understand completely. This article will show you how, in C, where the machine hides nothing from you.

By the end you'll have built a working dynamic array and, more importantly, a mental model that makes std::vector, Go slices, and Rust's Vec all obvious.

The Core Idea: Two Layers of Memory

Before writing a single line, you need to understand the central insight that makes a dynamic array possible.

A normal array is a fixed block of memory. You declare int numbers[8] and the compiler carves out exactly 32 bytes on the stack. That's it. If you need a 9th element, you're stuck.

A dynamic array gets around this by living on the heap — a region of memory that your program can request and release at runtime, in any size, at any time. The heap doesn't get freed automatically when a function returns. You control it. That control is what makes resizing possible, and what makes memory bugs possible too.

The dynamic array is two things at once: a block of integers sitting somewhere on the heap, and a small control structure that remembers where that block is, how big it is, and how many elements are currently in it. Everything we build is just bookkeeping those two things correctly.

What You Need to Know First

Memory: Stack vs Heap

When you declare a local variable, it goes on the stack. The stack is fast and automatic — variables appear when a function is called and vanish when it returns.

void foo() {
    int x = 10; // lives on the stack
}               // x is gone here

The heap is different. Memory there persists until you explicitly free it. You ask the OS for a chunk, use it, and free it when you're done. This is what enables data structures that outlive the function that created them.

Pointers

A pointer is a variable that holds a memory address rather than a value.

int score = 99;
int *ptr = &score; // ptr holds the address of score, not 99

&score means "give me the address of score." *ptr means "go to that address and read what's there." They're inverse operations.

Why does this matter? Because when you allocate memory on the heap, you get back an address — a pointer — to where that memory starts. There's no other way to refer to heap memory. Pointers aren't a language quirk; they're the only handle you have on dynamic allocation.

int *numbers = malloc(sizeof(int) * 8);
// numbers holds the address of a 32-byte block on the heap
// numbers[0], numbers[1], ... numbers[7] are all valid

malloc returns a pointer to the allocated block. sizeof(int) gives the size in bytes of one integer (typically 4). Multiply by 8 and you get 32 bytes — room for 8 integers.

Structs

C has no classes. To group related data, you use a struct.

struct IntArray {
    int *data;     // pointer to the integers on the heap
    int length;    // how many elements are currently stored
    int capacity;  // how much space is allocated
};

typedef lets you drop the struct keyword every time you use it:

typedef struct {
    int *data;
    int length;
    int capacity;
} IntArray;

Now IntArray arr; is valid instead of struct IntArray arr;. Small thing, but it adds up.

The -> operator accesses a struct's field through a pointer:

array->length  // same as (*array).length

You'll use -> constantly because our functions always receive a pointer to the struct, not the struct itself. Passing the struct by value would copy all three fields every time — wasteful, and it means modifications wouldn't be visible to the caller.

The Header Files

#include <stdio.h>   // printf, scanf
#include <stdlib.h>  // malloc, realloc, free, exit
#include <stdbool.h> // bool, true, false

stdlib.h is the critical one. Every memory function we use lives there. Without it, malloc and free are undeclared.

stdbool.h exists because C didn't originally have a boolean type. It gives you bool, true, and false as proper names instead of int, 1, and 0.

The Structure

Now that the building blocks are clear, the struct makes obvious sense:

#define DEFAULT_CAPACITY 8

typedef struct {
    int *data;     // address of our integer block on the heap
    int length;    // elements currently stored (logical size)
    int capacity;  // elements we have room for (physical size)
} IntArray;

length and capacity are not the same thing. This distinction is the heart of how a dynamic array works.

capacity = 8  (8 slots exist in memory)
length   = 3  (only 3 are in use)

[ 10 | 20 | 30 | __ | __ | __ | __ | __ ]
  [0]  [1]  [2]

When length == capacity, the array is full and must grow before the next add.

#define DEFAULT_CAPACITY 8 is a compile-time constant. The preprocessor replaces every occurrence of DEFAULT_CAPACITY with 8 before the compiler sees the code. It's not a variable — it has no address and uses no runtime memory.

Creating the Array

IntArray *createArray(int capacity) {

    // Guard against nonsense input
    if (capacity <= 0)
        capacity = DEFAULT_CAPACITY;

    // Allocate the control struct on the heap
    // This gives us room for: one pointer, two ints
    IntArray *array = malloc(sizeof(IntArray));

    if (array == NULL) {
        printf("Memory allocation failed\n");
        exit(EXIT_FAILURE); // no safe way to recover here
    }

    // Allocate the integer block separately
    // The struct just holds a pointer to this block
    array->data = malloc(sizeof(int) * capacity);

    if (array->data == NULL) {
        printf("Memory allocation failed\n");
        free(array); // don't leak the struct we just allocated
        exit(EXIT_FAILURE);
    }

    array->length = 0;        // no elements yet
    array->capacity = capacity; // but we have space reserved

    return array; // return the address of the struct
}

Notice we allocate twice. Once for the struct, and once for the integer data. These are two separate heap allocations, and that's why we must free both when we're done. The struct contains the address of the data block, but it doesn't own it in any automatic sense — we have to track and free it ourselves.

The return type is IntArray * — a pointer. We're not returning the struct itself; we're returning its address. This is the handle the caller will use for every subsequent operation.

Destroying the Array

void destroyArray(IntArray *array) {
    free(array->data); // free the integer block first
    free(array);       // then free the struct
}

Order matters. Free the data block first, then the struct. If you freed the struct first, array->data would be a dangling read — you'd be accessing memory through a pointer to something that's already freed.

Every malloc must have exactly one matching free. This is the discipline C demands. Modern languages have garbage collectors to enforce this automatically. In C, it's on you.

Getting and Setting Elements

int get(IntArray *array, int index) {
    if (index < 0 || index >= array->length) {
        printf("Index out of bounds\n");
        exit(EXIT_FAILURE);
    }
    return array->data[index];
}

void set(IntArray *array, int index, int value) {
    if (index < 0 || index >= array->length) {
        printf("Index out of bounds\n");
        exit(EXIT_FAILURE);
    }
    array->data[index] = value;
}

The bounds check is not optional. Without it, array->data[index] when index >= length reads memory that belongs to something else — possibly another variable, possibly the OS. C won't stop you. The behavior is undefined, which in practice means silent data corruption or a crash that's hard to trace.

Both operations are O(1) because array->data[index] computes directly to a memory address:

address = base_address + (index × sizeof(int))

No searching. One arithmetic operation.

Adding Elements: The Core of a Dynamic Array

This is the function everything else builds toward.

void add(IntArray *array, int value) {

    // Is the array full?
    if (array->length == array->capacity) {

        // Double the capacity — we'll explain why below
        array->capacity *= 2;

        // Ask the OS to resize our integer block
        int *newData = realloc(
            array->data,
            sizeof(int) * array->capacity
        );

        // CRITICAL: store in a temp pointer, not array->data
        // If realloc fails, it returns NULL — if we assigned
        // directly to array->data we'd lose the original pointer
        // and have a memory leak with no way to recover
        if (newData == NULL) {
            printf("Reallocation failed\n");
            exit(EXIT_FAILURE);
        }

        // Only update once we know it succeeded
        array->data = newData;
    }

    // Store the value and advance the length in one step
    array->data[array->length++] = value;
}

realloc is malloc's smarter sibling. It takes an existing pointer and a new size. If it can extend the block in place, it does. If not, it allocates a new block, copies the old data, frees the old block, and returns the new address. The existing contents are preserved either way.

Why double the capacity instead of growing by 1?

If you grew by 1 every time the array filled up, every single add would trigger a realloc and a copy of all existing elements. Adding n elements would cost O(n²) total.

Doubling means resizes happen at sizes 4, 8, 16, 32, 64... Each resize copies everything, but the number of copies per element approaches 2 as n grows. Over many insertions, the average cost per add is O(1). This is called amortized constant time — expensive occasionally, cheap on average.

Removing Elements

Remove by Index

void removeAt(IntArray *array, int index) {

    if (index < 0 || index >= array->length) {
        printf("Index out of bounds\n");
        exit(EXIT_FAILURE);
    }

    // Shift every element after the removed one left by one position
    for (int i = index; i < array->length - 1; i++) {
        array->data[i] = array->data[i + 1];
    }

    // The last position still holds the old value, but we don't
    // erase it — we just stop counting it as part of the array
    array->length--;
}

The loop goes to array->length - 1, not array->length. At the final iteration, i is length - 2 and we read array->data[length - 1]. If the loop ran to length, the last iteration would read array->data[length], which is outside the allocated block.

This is O(n) in the worst case — removing from index 0 shifts every element.

Remove by Value

bool removeValue(IntArray *array, int value) {
    for (int i = 0; i < array->length; i++) {
        if (array->data[i] == value) {
            removeAt(array, i);
            return true;  // remove first match only
        }
    }
    return false; // value wasn't in the array
}

Search linearly, delegate the actual removal to removeAt. Returns false when the value isn't found so the caller can detect the miss.

Reversing the Array

void reverse(IntArray *array) {
    int left = 0;
    int right = array->length - 1;

    while (left < right) {
        // Swap elements at left and right
        int temp = array->data[left];
        array->data[left] = array->data[right];
        array->data[right] = temp;

        // Move both pointers inward
        left++;
        right--;
    }
}

The two-pointer technique. Start from opposite ends, swap, move inward, stop when they meet. O(n) time, O(1) extra space — no second array needed.

The condition is left < right, not left != right. For an odd-length array, they'll converge on the middle element. That element doesn't need swapping with itself, so the loop correctly stops before touching it.

Printing

void printArray(IntArray *array) {
    printf("[");
    for (int i = 0; i < array->length; i++) {
        printf("%d", array->data[i]);
        if (i != array->length - 1)
            printf(", ");
    }
    printf("]\n");
}

The comma logic — print a comma after every element except the last — is a common pattern. The alternative (printing a comma before every element except the first) is equivalent; pick one and be consistent.

Putting It Together

int main() {
    IntArray *arr = createArray(4); // capacity 4, length 0

    add(arr, 3);   // length 1
    add(arr, 7);   // length 2
    add(arr, 6);   // length 3
    add(arr, -2);  // length 4, capacity 4 — full

    printArray(arr); // [3, 7, 6, -2]

    removeValue(arr, 7); // shift left, length becomes 3

    printArray(arr); // [3, 6, -2]

    reverse(arr); // two-pointer swap

    printArray(arr); // [-2, 6, 3]

    destroyArray(arr); // free data block, then free struct

    return 0;
}

Note: the first add after createArray(4) that would require a 5th slot would trigger a resize — capacity doubles to 8. In this main we add exactly 4 elements, so no resize occurs. To see it in action, add a 5th element.

The Gotchas

Assigning realloc directly to the original pointer.

// Wrong — if realloc returns NULL, you've lost your data
array->data = realloc(array->data, newSize);

// Right — check before assigning
int *newData = realloc(array->data, newSize);
if (newData != NULL) array->data = newData;

Freeing in the wrong order.
Free array->data before array. If you free the struct first, you're reading array->data through a dangling pointer.

Using length instead of capacity in the resize check.
The array is full when length == capacity. If you compare against the wrong field, you either resize too early (wasted allocations) or never resize at all (out-of-bounds writes).

Off-by-one in removeAt's loop.
The loop runs to array->length - 1, not array->length. The last iteration reads data[length - 1]. Going one further reads past the end of the allocated block.

Not checking malloc for NULL.
malloc returns NULL when the OS can't satisfy the request. Dereferencing a NULL pointer is undefined behavior. Always check.

Using the array after destroyArray.
After you free memory, the pointer still holds the old address. Reading through it is undefined behavior. Set pointers to NULL after freeing if you need to guard against accidental reuse.

Junior Pattern vs Senior Pattern

Resizing:

// Junior — assigns directly, leaks memory on failure
array->data = realloc(array->data, sizeof(int) * array->capacity);
if (array->data == NULL) exit(EXIT_FAILURE); // original pointer is gone

// Senior — uses temp, original is recoverable on failure
int *newData = realloc(array->data, sizeof(int) * array->capacity);
if (newData == NULL) {
    // array->data is still valid here, nothing was lost
    exit(EXIT_FAILURE);
}
array->data = newData;

Cleanup:

// Junior — frees struct first, then reads dangling pointer
free(array);
free(array->data); // undefined behavior: array is already freed

// Senior — free data first, then the container
free(array->data);
free(array);

Bounds checking:

// Junior — trusts the caller
return array->data[index];

// Senior — validates before accessing
if (index < 0 || index >= array->length) {
    // handle error
}
return array->data[index];

Where This Lives in the Real World

std::vector in C++ is this exact structure. The underlying implementation uses new[] instead of malloc, but the capacity/length distinction, the doubling strategy, and the contiguous memory layout are identical.

Go slices have a header with ptr, len, and cap — those are our data, length, and capacity. When you append past cap, Go allocates a new backing array, copies, and returns a new slice header.

Rust's Vec<T> is the same: a heap-allocated contiguous buffer, a length, and a capacity. The ownership system handles the freeing automatically, but the memory layout underneath is what you just built.

Time Complexity

Operation	Complexity	Why
`get`	O(1)	Direct address calculation
`set`	O(1)	Direct address calculation
`add` (no resize)	O(1)	Write to `data[length]`, increment
`add` (resize)	O(n)	`realloc` copies all elements
`add` (amortized)	O(1)	Resizes are infrequent enough
`removeAt`	O(n)	Shift all elements after index
`removeValue`	O(n)	Linear scan + shift
`reverse`	O(n)	Visit each element once

Your Turn

Extend the implementation with these two functions:

// Insert a value at a specific index, shifting everything right
void insertAt(IntArray *array, int index, int value);

// Return the index of the first occurrence of value, or -1 if not found
int indexOf(IntArray *array, int value);

Constraints: insertAt must handle growth the same way add does. indexOf must return -1, not exit, when the value is absent.

You'll know you're done when this main produces the expected output:

IntArray *arr = createArray(4);
add(arr, 10);
add(arr, 30);
insertAt(arr, 1, 20); // insert 20 between 10 and 30
printArray(arr);      // [10, 20, 30]
printf("%d\n", indexOf(arr, 20)); // 1
printf("%d\n", indexOf(arr, 99)); // -1
destroyArray(arr);

I’m building Blockend

Noor ul hassan — Wed, 17 Jun 2026 10:03:32 +0000

Backend development today depends heavily on external libraries for things that are often just reusable patterns — rate limiting, logging, error handling, and similar utilities.

The issue is not that these libraries are bad. Most of them are well-built and widely used. The real problem is what happens over time: they introduce layers of abstraction between you and your own application. You install them, configure a few options, and move on without ever really seeing what’s happening inside.

Eventually, your system works, but parts of it are no longer fully visible or easy to reason about.

Blockend takes a different approach.

Instead of installing a dependency for these kinds of backend patterns, it brings the actual implementation directly into your project as code. It understands your setup - your framework, your language, your folder structure - and generates clean, readable modules that fit your project naturally.

There is no black box. Nothing is hidden behind an API surface. The code lives in your repository, and you can read it, modify it, or replace it entirely whenever you want.

The goal is simple: reduce unnecessary dependencies and bring backend logic back into the open, where it is easier to understand, debug, and control.

I’m actively building this in public. Feedback is welcome.

Repo: https://github.com/codewithnuh/blockend

Building JobTracker: A Straightforward Job Application Tracker

Noor ul hassan — Sat, 18 Apr 2026 09:11:13 +0000

Job hunting turns chaotic real quick. Tabs everywhere, emails you lose track of, and spreadsheets that get outdated the second you close them. Most trackers either throw too many features at you or hide the useful stuff behind paywalls.

I built JobTracker to fix exactly that mess.

It gives you a clean 7-stage pipeline: Applied, Screening, Interview, Offer, Accepted — plus Rejected and Withdrawn as separate paths. Every time you change status, it automatically logs the change with a timestamp. You can add company details, role, salary range, and the original job link. There are also basic metrics showing interview rate and offer rate.

The app is live and free for core tracking here:

https://job-tracker.noorulhassan.com

I built the frontend with Next.js 15 App Router, Tailwind CSS, shadcn/ui, and SWR for data fetching. Backend runs on Fastify with full TypeScript, Drizzle ORM on PostgreSQL, and Zod for strict validation. Authentication uses httpOnly JWT cookies with rate limiting.

One thing I made sure of is a proper status state machine so you can't make invalid jumps between stages.

Here's how the transitions look in code:

const validTransitions: Record<ApplicationStatus, ApplicationStatus[]> = {
  APPLIED: ['SCREENING', 'REJECTED', 'WITHDRAWN'],
  SCREENING: ['INTERVIEW', 'REJECTED'],
  INTERVIEW: ['OFFER', 'REJECTED'],
  OFFER: ['ACCEPTED', 'REJECTED'],
};

if (!validTransitions[currentStatus]?.includes(newStatus)) {
  throw new Error(`Invalid transition: ${currentStatus} → ${newStatus}`);
}

The full source is open on GitHub:

Frontend: https://github.com/codewithnuh/job-tracker

Backend API: https://github.com/codewithnuh/job-tracker-api

If you're job hunting right now, try the live app. It might actually keep things organized without the usual headache.

If you're a developer, open the repos and take a look. The code uses strict TypeScript, validation at the edges, and keeps things separated properly.

Star both repositories if the tool helps you or if the code looks solid. It helps the project reach more people and gives me real feedback on what to improve.

Follow my GitHub at github.com/codewithnuh for more projects like this.

What's the biggest pain you face when tracking job applications? Tell me in the comments.

Building Free, High-Performance GSAP Components for the Community

Noor ul hassan — Wed, 11 Mar 2026 07:39:45 +0000

As developers, we’re surrounded by component libraries tailored to frameworks like React, Vue, and Angular. They’re great, but they often prioritize functionality over performance, interactivity, or visual flair. That’s why I’ve set out on a mission: to build unique, highly performant, and visually engaging components using GSAP—and provide them free for the community.

GSAP (GreenSock Animation Platform) is an incredibly powerful animation library, but surprisingly few developers leverage it for reusable UI components. My goal is to change that: to craft components that aren’t just visually impressive, but also optimized for real-world performance.

Why GSAP Components?

Performance-First: GSAP’s quickTo() and gsap.ticker allow near-zero per-frame overhead, keeping animations buttery smooth, even in complex UIs.
Unique Interactivity: Components can respond in rich, tactile ways—hover states, click states, magnetic effects, and more.
Framework-Agnostic: While many components are framework-specific, GSAP’s animation engine allows me to create truly reusable, high-performance elements.
Community-Focused: Every component will be open-source and free, ready to plug into your projects.

My First Component: A Custom Cursor

I kicked things off with a high-performance Custom Cursor. Instead of the default browser cursor, this component introduces a fluid, dual-element pointer—a small dot and a ring—that reacts dynamically to user interactions.

Key Features:

Performance-Optimized: Uses gsap.quickTo() for instant response without taxing the frame budget.
State Machine: Handles default, hover, click, hover-click, and hidden states.
Smart Delegation: A single document-level listener manages hover detection, avoiding dozens of individual event listeners.
Touch-Friendly: Automatically disables on touch devices.
Always Visible: Uses mix-blend-difference so the cursor stands out against any background.

You can try it live here: Custom Cursor Demo

Implementation Overview

Install Dependencies

npm install gsap tailwindcss

Create the Component

Place logic in components/ui/CustomCursor.tsx.
Disable the native cursor globally in CSS:

html { cursor: none !important; }

Use gsap.quickTo() for smooth motion and gsap.ticker to update the cursor position efficiently.

Use Globally

Import <CustomCursor /> in your root layout:

import CustomCursor from "@/components/ui/CustomCursor";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <CustomCursor />
        {children}
      </body>
    </html>
  );
}

Make Elements Interactive

Add data-cursor="hover" to trigger the hover state:

<button data-cursor="hover" className="px-6 py-2 bg-white text-black rounded-full">
  Hover Me
</button>

Performance Notes

Ref-based positioning: Mouse coordinates and GSAP quickTo functions are stored in refs to prevent unnecessary React re-renders.
GPU-Accelerated Animations: Using will-change: transform ensures smooth, hardware-accelerated movement.
Ticker Sync: GSAP ticker avoids conflicts with React render cycles, keeping animations fluid.

This is just the beginning. My plan is to build a library of free GSAP components that are not only visually stunning but also lightweight, interactive, and easy to integrate. From dynamic cursors to scroll-triggered animations and beyond, my goal is to give developers tools they won’t find anywhere else—without charging a cent.

If you’re curious or want to contribute, check out the first demo here: Custom Cursor Live

Stay tuned—more components are coming soon!

Why Do Clicks “Stack Up” When JavaScript Blocks the UI?

Noor ul hassan — Mon, 23 Feb 2026 06:19:15 +0000

I recently noticed something interesting while experimenting with JavaScript.

I wrote a simple synchronous loop that runs for about 10 seconds:

const start = Date.now();
while (Date.now() - start < 10000) {
  // Block for 10 seconds
}

During those 10 seconds, the UI completely freezes. That part makes sense.

But here’s the interesting part:

While the loop was running, I kept clicking a button on the page. Nothing happened. No console logs. No UI updates.

Then the loop finished…

And suddenly, all my clicks fired at once.

It felt like the browser had “saved” them somewhere.

So what’s actually happening?

The Short Answer: OS Input Buffering

When JavaScript runs a heavy synchronous task, the main thread (Call Stack) is blocked.

But JavaScript freezing does not mean your entire system freezes.

Let’s break it down:

1️ Hardware Level

When you click your mouse, the hardware sends an interrupt signal to the Operating System.

2️ OS Level

The OS records that click in its input buffer.
Even if your browser tab is busy, the OS is still fully operational.

3️ Browser Level

The browser receives those events from the OS and places them into the Macrotask Queue (also called the Callback Queue).

Why Do They Execute After the Loop?

The Event Loop cannot check the Macrotask Queue until the Call Stack is empty.

During the 10-second loop:

The Call Stack is busy.
The Event Loop is stuck.
It literally cannot move to the next “tick” to process events.

After the loop finishes:

The Call Stack clears.
The Event Loop runs again.
It sees all the queued click events.
It processes them one by one.

That’s why everything fires at once.

The Big Insight

JavaScript is single-threaded.

But your Operating System is not.

Even when your JavaScript is frozen, the OS is still collecting user input and handing it to the browser.

The browser politely queues those events until JavaScript is ready again.

Why This Matters

Understanding this helps explain:

Why heavy synchronous code freezes the UI
Why clicks seem to “stack up”
Why long-running tasks should be avoided on the main thread
Why Web Workers exist

It also makes the Event Loop feel less magical and more mechanical.

Sometimes weird UI behavior isn’t magic — it’s just how the system is designed.

Tailwind A11y Checker 🌊♿ — Stop shipping inaccessible UIs by accident

Noor ul hassan — Mon, 09 Feb 2026 14:40:09 +0000

Real talk: I used to think "accessibility" meant running Lighthouse before deploy. Then a user emailed me saying they couldn't read half my app because the contrast was garbage.

Turns out bg-blue-500 + text-blue-600 looks "clean" but fails WCAG hard. And I'd shipped that combo everywhere.

So I built Tailwind A11y Checker — a VS Code extension that catches these mistakes while you code:

What it actually does:

✅ Real-time contrast checks — Flags unreadable text combos and shows the exact WCAG ratio

✅ One-click fixes — Suggests the closest Tailwind shade that actually passes (no more guessing blue-700 vs blue-800)

✅ Focus state reminders — Yells at you if your button has no focus: classes (keyboard users will thank you)

Works everywhere:

.html • .jsx/.tsx • .vue • .svelte • .js/.ts

No setup. No config. Just install and your editor starts keeping you honest.

👉 Grab it: VS Code Marketplace

👉 Found a false positive? Open an issue — I'm actively tweaking the rules

👉 Using a custom color palette? Let me know — planning to add support

Built this because I kept failing basic a11y checks. Figured if it helps me, it might help you too.

Made with ❤️ by codewithnuh

Peeking Behind the Scenes: How Python Makes Your Code Come Alive!

Noor ul hassan — Sat, 29 Mar 2025 10:33:33 +0000

Python! You've probably heard it's super easy to read and use. But have you ever wondered what happens behind the scenes when you type in some Python code and hit run? It's actually a pretty cool process where Python works its magic to bring your program to life! Even when you run a simple program from the command line, there's a fascinating journey your code takes.

While Python is known as an "interpreted" language, meaning it runs your code line by line, there's a sneaky little intermediate step involved. This article will take you on a tour of how Python actually executes your code, shining a light on the roles of the interpreter, a kind of "secret code" called bytecode, and the Python Virtual Machine (PVM) – think of it as the stage where your code performs!

Meet the Python Interpreter: Your Code's Best Friend

When you type python your_script.py in your terminal, you're calling on the Python interpreter. Think of it as the 'official' guide that knows how to read, understand, and ultimately run your Python instructions. The most common version of this guide is called CPython, and it's written in a programming language called C. There are other versions out there, like Jython (for running Python on Java systems) and IronPython (for Windows systems), but for our adventure today, we'll stick with CPython, as it's the one you're most likely to bump into.

The interpreter's first job is to take a peek at your Python source code file (that's your your_script.py file). Now, unlike some other programming languages like C++ or Java that get translated directly into a language your computer's processor understands, Python takes a slightly different path.

Turning Your Code into a Secret Code: Bytecode!

Before your code actually runs, CPython does a quick translation. But it doesn't translate it into your computer's specific language. Instead, Python turns your original code into an intermediate code called bytecode.

Think of bytecode as a secret code that the Python interpreter understands. It's like a translator has already done some of the work, making it easier for the interpreter to follow your instructions. This "secret code" is also special because it can run on any computer that speaks Python!

This translation to bytecode happens automatically in the background. Have you ever seen files ending in .pyc in your Python projects? Those are the saved versions of this bytecode for your Python programs. Python creates them to make running the same program faster next time. If you haven't changed your code since the last run, Python can just load up the bytecode from the .pyc file and skip the translation step. Pretty neat, huh?

Sneak Peek at the Secret Code!

Python even lets you peek at this "secret code" using a tool called the dis module (short for disassembler). Let's say you have a simple function:

def add(a, b):
    return a + b

We can see its bytecode by doing this:

import dis

def add(a, b):
    return a + b

dis.dis(add)

When you run this, you'll see something like this (don't worry if the exact details look a little different on your computer):

  2           0 LOAD_FAST                0 (a)
              2 LOAD_FAST                1 (b)
              4 BINARY_ADD
              6 RETURN_VALUE

This might look a bit strange, but it's basically the low-level instructions that tell the Python interpreter to: grab the values of a and b, perform the addition, and then give back the result.

The Python Virtual Machine (PVM): Where the Magic Happens!

Once your code is in bytecode "secret code", the next important player steps onto the stage: the Python Virtual Machine, or PVM for short. Now, don't let the name "machine" confuse you – it's not a physical piece of hardware like your computer. Instead, the PVM is like a software program that pretends to be a computer, specifically designed to understand and run that bytecode.

The PVM's main job is to take those bytecode instructions and actually make them happen! It does this by following a simple process, kind of like a little dance:

Fetch: It grabs the next instruction from the bytecode.
Decode: It figures out what that instruction means.
Execute: It performs the action that the instruction tells it to do.

This "fetch-decode-execute" dance keeps going until all the bytecode instructions have been processed.

Let's Watch a Simple Program Run!

Let's follow along as Python runs a super simple program:

# hello.py
print("Hello, World!")

Here's what happens when you type python hello.py in your terminal:

Invocation: You tell Python to run your hello.py file.
Interpreter Startup: The CPython interpreter wakes up and gets ready.
Code Reading: The interpreter takes a look at your hello.py file.
Compilation to Bytecode: Python translates your print("Hello, World!") line into its "secret code". This code basically tells the PVM: "Hey, show the words 'Hello, World!' on the screen." This bytecode might be quickly stored in memory or maybe even saved in a hello.pyc file (depending on your settings and Python version).
PVM Execution: Now it's the PVM's turn!
- It reads the first instruction: "Load the words 'Hello, World!'".
- Then it reads the next instruction: "Call the print function".
- Finally, it acts on this instruction, telling your computer's operating system to display "Hello, World!" on your screen.
Program Termination: Once the PVM has followed all the instructions, it finishes its job, and the Python interpreter goes back to sleep.

A Quick Look at Memory: Where Does Everything Go?

Now, before we wrap up, let's touch on something else that's happening behind the scenes: how Python handles memory. Imagine Python has a big storage room (the heap) where it keeps all the "things" your program creates, like our "Hello, World!" string. Python is also tidy and has a "garbage collector" that automatically cleans up things that are no longer needed, so the storage room doesn't get too cluttered. One of the ways Python keeps track of what's being used is called reference counting.

Wrapping Up: Python's Behind-the-Scenes Magic

So, even running a simple Python program involves a neat process happening under the hood. The Python interpreter is like the director, first translating your code into a platform-friendly "secret code" called bytecode. Then, the Python Virtual Machine acts as the stage crew, diligently following those instructions to bring your program to life on your screen. Understanding this basic process gives you a cool peek into how Python works and can even help you when you're trying to figure out why your code might be doing something unexpected. While we looked at a very simple program, the same fundamental steps happen even with much more complex Python projects, showing just how clever and efficient Python is!

Advanced JavaScript Concepts Every Developer Should Know

Noor ul hassan — Tue, 24 Sep 2024 10:21:22 +0000

JavaScript is a language that many developers use daily, but there are numerous hidden gems within its ecosystem that even experienced developers may not be familiar with. This article explores some lesser-known JavaScript concepts that can significantly enhance your programming skills. We’ll cover concepts like Proxies, Symbols, Generators, and more, demonstrating each with examples and solving problems to illustrate their power.

By the end, you'll have a deeper understanding of JavaScript and know when (and when not) to use these advanced features.

1. Proxies

What are Proxies?

A Proxy in JavaScript allows you to intercept and customize fundamental operations like property lookups, assignments, and function invocations.

Problem: Imagine you're building a system where users have objects that track their actions. Instead of modifying every part of your app to track property access, you can use a Proxy to intercept and log these actions.

Example:

const user = {
  name: "Alice",
  age: 25
};

const handler = {
  get(target, prop) {
    console.log(`Property '${prop}' was accessed`);
    return prop in target ? target[prop] : `Property ${prop} doesn't exist`;
  },
};

const userProxy = new Proxy(user, handler);

console.log(userProxy.name); // Logs: Property 'name' was accessed, Returns: Alice
console.log(userProxy.address); // Logs: Property 'address' was accessed, Returns: Property address doesn't exist

Pros:

Allows you to handle and intercept almost any interaction with an object.
Great for logging, validation, and dynamic behavior.

Cons:

Can introduce performance overhead if overused.
Harder to debug due to the abstraction layer between your logic and object behavior.

2. Symbols

What are Symbols?

Symbols are a new primitive type introduced in ES6. They provide unique keys for object properties, making them useful when you need to avoid property name collisions.

Problem: Let’s say you’re working on an object that integrates with third-party code, and you want to add custom properties without overwriting their keys.

Example:

const uniqueId = Symbol('id');
const user = {
  [uniqueId]: 123,
  name: "Alice"
};

console.log(user[uniqueId]); // 123
console.log(Object.keys(user)); // ['name'] - Symbol key is hidden from iteration

Pros:

Symbols are unique, even if they share the same description.
Prevents accidental property overwrites, making them ideal for use in libraries or API design.

Cons:

Symbols are not enumerable, which can make debugging or iteration slightly trickier.
Can reduce code readability if overused.

3. Generator Functions

What are Generators?

Generators are functions that can be paused and resumed, making them useful for managing async flows or producing data on demand.

Problem: Suppose you want to generate a sequence of Fibonacci numbers. Instead of generating the entire sequence up front, you can create a generator that yields values one by one, allowing lazy evaluation.

Example:

function* fibonacci() {
  let a = 0, b = 1;
  while (true) {
    yield a;
    [a, b] = [b, a + b];
  }
}

const fib = fibonacci();

console.log(fib.next().value); // 0
console.log(fib.next().value); // 1
console.log(fib.next().value); // 1
console.log(fib.next().value); // 2

Pros:

Efficient for generating sequences where you only need a few values at a time.
Allows for cleaner async flows when used with yield.

Cons:

Not as commonly used as Promises or async/await, so they have a steeper learning curve.
Can lead to complex code if overused.

4. Tagged Template Literals

What are Tagged Template Literals?

Tagged templates allow you to process template literals with a function, making them incredibly powerful for building DSLs (domain-specific languages) like CSS-in-JS libraries.

Problem: You need to build a template system that processes user input and sanitizes it to avoid XSS attacks.

Example:

function safeHTML(strings, ...values) {
  return strings.reduce((acc, str, i) => acc + str + (values[i] ? escapeHTML(values[i]) : ''), '');
}

function escapeHTML(str) {
  return str.replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;");
}

const userInput = "<script>alert('XSS')</script>";
const output = safeHTML`User said: ${userInput}`;
console.log(output); // User said: &lt;script&gt;alert('XSS')&lt;/script&gt;

Pros:

Allows for fine control over string interpolation.
Great for building libraries that require string parsing or transformation (e.g., CSS, SQL queries).

Cons:

Not commonly needed unless working with specific libraries or creating your own.
Can be difficult to understand and debug for beginners.

5. WeakMaps and WeakSets

What are WeakMaps and WeakSets?

WeakMaps are collections of key-value pairs where the keys are weakly referenced. This means if no other references to the key exist, the entry is garbage collected.

Problem: You’re building a caching system, and you want to ensure that once objects are no longer needed, they are automatically garbage collected to free up memory.

Example:

let user = { name: "Alice" };
const weakCache = new WeakMap();

weakCache.set(user, "Cached data");

console.log(weakCache.get(user)); // Cached data

user = null; // The entry in weakCache will be garbage collected

Pros:

Automatic garbage collection of entries, preventing memory leaks.
Ideal for caching where object lifetimes are uncertain.

Cons:

WeakMaps are not enumerable, making them difficult to iterate over.
Limited to only objects as keys.

6. Currying

What is Currying?

Currying transforms a function that takes multiple arguments into a sequence of functions that each take a single argument. It’s a functional programming technique that can increase code flexibility.

Problem: Let’s say you have a function that applies a discount based on a percentage. You want to reuse this function with different percentages throughout your app.

Example:

const applyDiscount = (discount) => (price) => price - price * (discount / 100);

const tenPercentOff = applyDiscount(10);
const twentyPercentOff = applyDiscount(20);

console.log(tenPercentOff(100)); // 90
console.log(twentyPercentOff(100)); // 80

Pros:

Can make functions more reusable by pre-applying arguments.
Allows you to easily create partial applications.

Cons:

Not intuitive for developers unfamiliar with functional programming.
Can lead to overly complex code if used excessively.

Conclusion

Each of these advanced JavaScript concepts — Proxies, Symbols, Generators, Tagged Template Literals, WeakMaps, and Currying — offers unique capabilities to solve specific problems in more efficient, scalable, or elegant ways. However, they come with trade-offs, such as increased complexity or potential performance issues.

The key takeaway is to understand when and where to use these concepts. Just because they exist doesn’t mean you should use them in every project. Instead, incorporate them when they provide clear benefits, like improving code readability, performance, or flexibility.

By exploring these advanced techniques, you’ll be able to tackle more sophisticated problems and write more powerful JavaScript.

# Learning JavaScript: A Beginner's Guide

Noor ul hassan — Sat, 12 Aug 2023 13:09:00 +0000

JavaScript is a versatile and widely used programming language that powers the interactive and dynamic elements of websites. Whether you're looking to enhance your web development skills or dive into programming for the first time, learning JavaScript can be a rewarding journey. In this guide, we'll walk you through the steps to learn JavaScript effectively.

Getting Started

1. Set Up Your Environment

Before you begin, ensure you have a text editor for writing code. Popular choices include Visual Studio Code, Sublime Text, and Atom. You'll also need a web browser for testing your JavaScript code.

2. Understand the Basics

Start by grasping fundamental concepts like variables, data types (numbers, strings, booleans), and basic operations (arithmetic, concatenation). This foundation will help you understand more complex topics.

Core Concepts

3. Control Structures

Learn about control structures such as if statements, for loops, and while loops. These structures allow you to make decisions and repeat actions based on conditions.

4. Functions

Functions are blocks of code that can be reused. Master how to create, call, and pass parameters to functions. Understanding functions is crucial for building organized and efficient code.

5. Objects and Arrays

JavaScript objects and arrays are used to store and organize data. Explore how to create and manipulate objects and arrays to manage information effectively.

Deepening Your Knowledge

6. DOM Manipulation

The Document Object Model (DOM) allows you to interact with web pages. Learn how to use JavaScript to modify HTML and CSS, enabling dynamic and responsive web experiences.

7. Events and Event Handling

Understand how to detect and respond to user actions like clicks and keyboard input. Event handling is vital for creating interactive web applications.

8. Asynchronous JavaScript

Explore asynchronous programming with concepts like callbacks, promises, and async/await. This is crucial for handling tasks that don't need to happen in a specific order, like fetching data from a server.

Practical Projects

9. Build Simple Projects

Apply your knowledge by building small projects. Create interactive forms, a to-do list, or a basic calculator. Practical projects help solidify your understanding and boost your confidence.

10. Work on Real-world Projects

As you become more comfortable with JavaScript, take on more complex projects. Build a portfolio website, a weather app that fetches data, or a simple game. Real-world projects showcase your skills and provide tangible results.

Learning Resources

11. Online Tutorials and Courses

Numerous online platforms offer JavaScript tutorials and courses, catering to different learning styles. Check out resources like Codecademy, freeCodeCamp, and MDN Web Docs.

12. Books and Documentation

Books like "Eloquent JavaScript" by Marijn Haverbeke and the Mozilla Developer Network (MDN) JavaScript Guide provide in-depth explanations and examples.

13. Practice, Practice, Practice

Consistent practice is key. Work on coding challenges from websites like LeetCode and HackerRank to reinforce your skills.

Final Thoughts

Learning JavaScript can be a rewarding endeavor that opens up countless opportunities in web development. Approach your learning journey with patience, curiosity, and a willingness to tackle challenges. Remember that programming is a skill that improves over time, so keep coding and experimenting to become a proficient JavaScript developer.# Learning JavaScript: A Beginner's Guide

Getting Started

1. Set Up Your Environment

Before you begin, ensure you have a text editor for writing code. Popular choices include Visual Studio Code, Sublime Text, and Atom. You'll also need a web browser for testing your JavaScript code.

2. Understand the Basics

Core Concepts

3. Control Structures

Learn about control structures such as if statements, for loops, and while loops. These structures allow you to make decisions and repeat actions based on conditions.

4. Functions

Functions are blocks of code that can be reused. Master how to create, call, and pass parameters to functions. Understanding functions is crucial for building organized and efficient code.

5. Objects and Arrays

JavaScript objects and arrays are used to store and organize data. Explore how to create and manipulate objects and arrays to manage information effectively.

Deepening Your Knowledge

6. DOM Manipulation

The Document Object Model (DOM) allows you to interact with web pages. Learn how to use JavaScript to modify HTML and CSS, enabling dynamic and responsive web experiences.

7. Events and Event Handling

Understand how to detect and respond to user actions like clicks and keyboard input. Event handling is vital for creating interactive web applications.

8. Asynchronous JavaScript

Practical Projects

9. Build Simple Projects

Apply your knowledge by building small projects. Create interactive forms, a to-do list, or a basic calculator. Practical projects help solidify your understanding and boost your confidence.

10. Work on Real-world Projects

Learning Resources

11. Online Tutorials and Courses

Numerous online platforms offer JavaScript tutorials and courses, catering to different learning styles. Check out resources like Codecademy, freeCodeCamp, and MDN Web Docs.

12. Books and Documentation

Books like "Eloquent JavaScript" by Marijn Haverbeke and the Mozilla Developer Network (MDN) JavaScript Guide provide in-depth explanations and examples.

13. Practice, Practice, Practice

Consistent practice is key. Work on coding challenges from websites like LeetCode and HackerRank to reinforce your skills.