nabraj.com - the personal homepage of Nabraj (NT)

React at 1,000 updates per second: Streaming market data

Mon, 01 Jun 2026 00:00:00 GMT

Financial tickers are a useful stress test for frontend architecture because the data update rate is high, and the failures are visible immediately. The screen has to remain responsive while thousands of quotes arrive to update table cells and paint real-time canvas charts simultaneously.

In a typical React application, data flows downward through state updates. When a component receives new data (via hook or prop), React schedules render work, diffs the virtual DOM, and updates the real DOM.

This model fails under high-frequency streaming as React tries to trigger 1,000 state mutations per second, consuming the browser's main thread from short-lived state objects.

The goal is to separate feed ingestion from rendering, so the browser can receive quotes, but React only renders the latest visible state.

Architecture

The system is divided into two paths: cold state and hot state.

The database (Postgres) owns durable state: instruments, watchlists and initial quote snapshots. It hydrates the first view.

The feed service owns volatile state. It mutates an in-memory quote book, batches quote deltas, and broadcasts them over WebSocket.

Postgres: instruments, watchlists, initial quotes
Feed service: in-memory quote book, heartbeat, batched deltas (WebSocket)
Browser: row-level subscriptions, grid, canvas sparklines, batch requestAnimationFrame

The important part is that a quote update only becomes render work if it affects the latest visible screen.

Batching messages

The WebSocket server sends 20 messages per second, with roughly 50 quote deltas in each message. Each message contains deltas, not full replacement snapshots.

With TypeScript's exactOptionalPropertyTypes, we have to do an explicit merge. The reason is that the client quote book must preserve the previous value for omitted fields.

The WebSocket does not call setState.

It validates the payload, and sends deltas to the quote store.

Hot state (browser)

The browser keeps live quotes in an external mutable store. When a delta batch arrives, the store updates the latest quotes for each symbol, appends the latest price, marks the symbol dirty, and schedules one frame-aligned flush.

 private scheduleFlush() {
   if (this.scheduled) return;

   this.scheduled = true;

   equestAnimationFrame(() => {
     this.flush();
   });
 }

If ten updates for AAPL arrive before the browser paints, the quote grid needs to render the latest one (not ten intermediate AAPL prices).

Row-level subscriptions

Instead of subscribing to the full quote book, each row subscribes to one symbol.

 subscribeSymbol = (symbol: string, listener: Listener) => {
   let listeners = this.symbolListeners.get(symbol);
   if (!listeners) {
     listeners = new Set();
     this.symbolListeners.set(symbol, listeners);
   }
   listeners.add(listener);

   return () => {
     listeners?.delete(listener);
   if (listeners?.size === 0) {
       this.symbolListeners.delete(symbol);
   }
   };
 };

This keeps the row component as an ordinary UI component. React reads from the store through useSyncExternalStore, without putting the entire quote book in React state.

Virtualization

The grid renders only the visible window. This doesn't matter for a handful of rows, but it is a must when dealing with hundreds of symbols. There is no point rendering immediate ticks that will be replaced before the next paint. Do not mount rows that the user cannot see.

Canvas sparklines

This is an interesting piece that I spent a lot of time on. If every quote appended to React state and caused an SVG path to be recalculated, the implementation could become another high-frequency React workload. Instead, the quote store just keeps a ring buffer of recent prices per symbol.

The UI keeps enough points to show recent shape, keeping the ring buffer small and fixed (and lossy). The canvas component also subscribes to the same symbol as the row.

CPU and Memory

The feed process mutates an in-memory quote book, serializes batches, and writes WebSocket messages. The browser parses messages, mutates the quote store, schedules frame work, runs React for changed rows, paints, and draws layout and canvas sparklines.

The important part is that the live stream does not wake the Next.js server. After the first page load, quote updates move from the feed service directly to the browser store over WebSocket.

Application	Size (MB)	Type
Feed	57.9	RSS
Next.js	67.2	RSS

The feed process was roughly 58 MB RSS. The Next.js server process was roughly 67 MB RSS.

Multi-threading via Web Workers

While this setup effectively eliminates UI lag, WebSocket frame parsing and payload validation still consume the browser's resources. The upgrade here is to offload the parsing into a dedicated Web Worker.

By pushing JSON parsing and message validation to its own thread, the main thread is reserved strictly for handling row transitions and rendering pixels.

Final Thoughts

The lesson here is that a high-frequency UI needs separate layers for feed, state mutation, scheduling, subscriptions, and pixel drawing. React should render the screen, not the stream.

Turning source code into queryable system knowledge using LangChain

Mon, 20 Apr 2026 00:00:00 GMT

Turning codebases into queryable knowledge with LangChain

This project takes a GitHub Repository URL and produces four outputs:

Architecture summary
API summary
Onboarding guide
Architecture diagram (mermaid)

It is built using LangChain, embeddings and a simple multi-agent workflow.

ingest → architecture → api → onboarding → diagram

What is actually happening?

Step 1: Repository is cloned locally

First, the repository is cloned using GitPython into a local filesystem.

Step 2: Code is split into chunks

Using LangChain's RecursiveCharacterTextSplitter, source files are split based on separators (line and paragraph breaks, sentence boundaries etc.). This produces semantically coherent blocks for the context window.

Step 3: Chunks are embedded and stored in a vector DB

Each chunk is embedded using OpenAI embeddings model (text-embedding-3-small) and stored in a vector database (Chroma). Internally, the embedding model tokenizes the input, processes them through a transformer network and outputs a fixed-size dense vector. This gives semantic retrieval over code and an ability to retrieve relevant parts without matching keywords.

This vector is a numerical representation of the chunk in a semantic vector space, not a summary.

For each chunk, Chroma actually stores vector, original text and metadata like:

Step 4: LangChain's role

LangChain is basically a glue between embeddings, vector DB and LLM APIs.

It is used in three places: text splitting, embedding wrapper and vector store abstraction. First, LangChain is just normalizing raw strings into a structured Document format. Second, it is a thin wrapper over OpenAI's embedding endpoint. Finally, it stores vectors in disk backed index as well as helps running cosine similarity search.

Step 5: Each agent retrieves a different slice of the repo

When a query is issued, the vector database computes the cosine similarity between the query embeddings and the vectors in the index and returns top-k nearest chunks. The agent is not searching, it is leveraging a nearest-neighbour lookup in multi-dimensional space to pull a specific slice of the repo.

Each agent defines its own retrieval direction depending on the task.

Step 6: LLM generates structured output

LLM's job here is to take the retrieval and force it into a structured output format. The model is not understanding the repo, it is optimizing for coherence and doing the pattern completion from context.

Sample analysis/output:

Step 7: UI is displayed using FastAPI

FastAPI acts as an orchestration layer that receives the repo url, triggers the ingestion pipelines, executes the graph workflow and return the rendered markdown to the client.

Next step

Instead of the usual (like most RAG systems),

this system does,

It is multi-perspective retrieval over same knowledge space.

The current bottleneck of this project is its reliance on linear text chunking, which sometimes fragments functional logic across multiple embeddings. The next iteration would be to replace chunking with hierarchical index by mapping imports, inheritance and function calls. This lets the agents follow the execution paths, instead of relying on semantic similarity.

Posted on Apr 20, 2026

Processes vs Threads in Node.js and Bun

Fri, 03 Apr 2026 00:00:00 GMT

Processes vs Threads in Node.js and Bun

When scaling JavaScript execution, developers must choose between three core approaches: single-threaded loop, child processes , and isolated worker threads. This post analyzes the performance of those three approaches using Node.js and Bun:

cpu-math: floating point loop.
cpu-crypto: hashings via OpenSSL
transferable: 100MB ArrayBuffer transfer.

Core architecture

A common flaw is that running benchmarks measures the allocation time of a resource rather than the execution performance.

In production systems, workers are typically long-lived resources. For this benchmark, worker threads and child processes are created once and reused through pools.

Workload suite:

Floating point calculation

This workload stays within JavaScript, and the runtime spends nearly all of its time executing generated machine code.

Cryptographic hashing

This workload lands inside OpenSSL.

Binary payloads

This workload measures memory movement rather than computation.

Profiler:

The profiler isolates parent CPU usage from child CPU execution times. It also reports child memory distribution for three dimensions: average, peak and combined real pressure on the OS.

Findings:

#1: Threads and Processes scale almost identically for pure compute

The gap between worker threads and child processes is small enough for raw computation. This exposes a misconception that threads are lighter than processes.

Once all cores are busy with floating-point work, both models spend most of their time executing instructions rather than communicating. The benchmark suggests that once work becomes enough CPU-bound, the distinction between threads and processes becomes far less important. The OS system scheduler becomes the dominant factor here once the core is already saturated.

#2: Process isolation outperformed worker isolation for crypto

Worker threads required almost four times as long to complete the same workload.

This is because worker threads share the same Node.js process. While they run in separate V8 isolates and heaps, they still contend for shared process-level resources, causing lock contention (under heavy parallel workloads).

Child processes do not do this. They receive their own isolated runtime instance.

For heavy native workloads, process isolation is more effective than thread isolation on this machine. This is important because many production services spend more time in native libraries (OpenSSL, database drivers etc.) than inside JavaScript.

#3: Zero copy =/= Zero Cost

Each worker allocated a 100 MB ArrayBuffer before ownership could be transferred. With eight workers running concurrently, the runtime was managing roughly 800 MB of newly allocated memory before accounting for overhead, page tables, and process bookkeeping.

Worker threads peaked at ~2GB RSS during execution. The important learning is that transferables eliminate copy costs, but not the allocation cost. Zero-copy doesn't mean zero-cost.

#4: Runtime selection is more important than concurrency selection

The largest performance gap in the entire benchmark was not: worker_threads vs child_process

It was Node.js vs Bun. Bun completed the floating-point workload almost six times faster than the equivalent Node.js worker implementation.

For the floating point calculation:

Node.js executes on V8 while Bun executes on JavaScriptCore. V8 prioritizes aggressive optimization (speculative) and deoptimization strategies through a multi-stage pipeline. JavaScriptCore follows a different optimization strategy and has historically performed well on predictable numeric workloads. While the benchmark does not prove why JavaScriptCore won, the gap between Bun and Node.js was larger than the gap between worker threads and child processes.

Closing thoughts:

The common discussion in Node.js is usually 'worker threads vs child processes.' This benchmark shows that the question is often secondary.

For pure computation, worker threads and child processes scaled almost identically. For native crypto workloads, child processes significantly outperformed worker threads. For large binary payloads, transferables removed copy costs but introduced substantial memory pressure.

The first question should not be 'threads or processes?' The first question should be 'What is the workload actually doing?'

Posted on April 03, 2026

Why I use AI to write code slower (and better)

Sun, 01 Mar 2026 00:00:00 GMT

It seems like everyone is obsessed with speed at the moment. Scroll any engineering feed, and you will see people building a full-stack app in minutes using an LLM. Engineering leaders are rushing to give everyone an AI copilot to double the feature delivery velocity. I think this is optimizing for the wrong thing.

Most of my career has been spent on architecting high-traffic backend systems and messaging pipelines. Kafka streams, Node.js services, RabbitMQ queues, React frontends are not the kind of systems where 'it works' is enough. It has to stay stable, change and fail safely in controlled ways.

AI makes code easy to produce. And that is the risk. The bottleneck is rarely typing code, it is thinking. It is judgment.

So, I use LLMs every day, not to write code faster, but to write code slower, deeper and better. I force the LLMs to defend the design to me before a single line of code is written.

Code is no longer the hard part

Writing a React component, adding an API layer, or a backend service is trivial now. The hard parts are still the same.

Data ownership: what owns the data?
Downstream degradation: what happens when a downstream service drops off the network?
System load: How does the service behave under a traffic spike?
Resilience: How are retries (and backoff) implemented?
Mitigation: What breaks down in the system and how do we protect against it?
Recovery: How do we recover a system from a failure?

Without anchoring the AI with these constraints, it will generate code that works in isolation, but fails in production. I have seen systems pass every integration test and still collapse in production.

More time planning, not generating code

The most common mistake is treating LLM like an advanced autocomplete.

Instead, I write out the architecture and the data models, and then I use the model to walk me through every possible failure mode. We debate network timeouts, boundaries and state transitions. By the time I actually ask the LLM to write a line of code, the system's design is finalized. The generation of the actual code becomes the easiest part of the process.

Trick the AI

LLMs are fundamentally trained to optimize for user approval and conversational flow. If you push back, LLM will flip the position and apologize most of the time, even if the original answer was correct. If you leak your architecture early in the prompt, the AI will instantly agree with you and just go with the flow to justify your bad idea.

So, I just show it the problem, forcing the AI to propose independent solutions first.

The shift in prompting

Previously:

'Write me a Node.js script to connect to RabbitMQ, consume messages from an order queue, and save them to a database.'

The AI will spit out a clean snippet that opens a connection, listens, and runs a DB insert. It may look perfect, but it is not proper code.

Now:

I need to write a Node.js script to connect to RabbitMQ, consume messages from an order queue, and save them to a database. Do not write any code yet. Instead, lets walk through the system design first. Focus on:

Connection pooling to PostgreSQL
Network blips between the service and RMQ connection
Message acknowledgment strategies
Handling malformed message without blocking the entire queue.

Slowing down this process forces you to refine the design, error handling and database connection strategies before a line of code is written.

Closing thoughts

I use AI to write code every day. But I do not let it decide the shape of the systems. I first let it agree with me on the design and validate the architecture.

We need to spend more time planning and less time blindly generating. Let the AI do the typing, but make sure you are the one doing the thinking.

Playing piano with prime numbers

Sat, 16 Aug 2025 00:00:00 GMT

Last weekend, I decided to turn prime numbers into a mini piano and see what kind of music math could make.

See demo/Create Music

Generating prime numbers

The simplest method is to check divisibility of each number by all small numbers. But it is inefficient for large datasets due to its complexity: O(n√n)

We'll use the Sieve of Eratosthenes here, as it's better (Time complexity: O(nloglogn)). Think of it like a game to cross out numbers that aren't prime until only the prime ones are left. Using count * Math.log(count) * 1.5, it estimates how many numbers it needs to look to find the required prime numbers (count is the number of primes we want).

Mapping strategy

Once we have the prime list, we need to map them to convert the primes into frequencies for sound. By mapping our primes to MIDI arrays, we can play single notes or complex chords.

clampMidi keeps a MIDI note within the piano's playable range (21-108).

Producing sound

Here, each prime becomes a MIDI number.

From here, we can use a soundfont library like soundfront-player which contains packaged mp3 samples for each note in a single JS file.

Unlike synthesizing tones using oscillators, each note is a real piano sample stored as an MP3, giving a natural sound.

Playback is handled with precise scheduling using AudioContext, so sequences of primes or chords remain in sync. By timing each note correctly, we can make the primes “playable” like a piano piece.

Final thoughts

Overall, this was a fun little project to play with prime numbers and the piano. I played around with various mapping techniques, e.g. using continuous ranges so higher primes produce higher pitches.

It's also interesting to see patterns emerge when listening. This project shows how math and sound can intersect in creative ways, and it can be a starting point for more generative music experiments in the future.

See the complete code on Github

Posted on Aug 16, 2025

Running local LLMs using Ollama

Sat, 09 Aug 2025 00:00:00 GMT

Ollama

Ollama is basically a runtime + package manager (like Node.js), built on top of C++ inference engines. It has a CLI+ server that acts as an LLM host and loads and runs models.

Models are mostly .guf files (from llama.cpp ecosystem). These are pre-trained, then quantized for a smaller size and faster local inference. These files contain neural weights, a tokenizer, and model metadata.

Ollama's runtime is basically a wrapper for llama.cpp (the brain) with API support and a model-loading-engine. It uses a Modelfile to add prompt or fine-tune layers.

When we provide a prompt to a LLM:

Step 1 (Tokenizer): Text is split into tokens (subwords).
Step 2 (Embedding lookup): Convert token ID into vectors.
Step 3 (Transformers): Transform vectors using attention mechanism and MLP.
Step 4 (Probability): Output probability distribution over next tokens.
Step 5 (Sampling): Pick the next token based on parameters (e.g. temperature)

Loop until stop (end of sequence token).

Using Ollama

Start by downloading Ollama and then a model.

Ollama when run exposes REST APIs like /generate and /chat.

Creating our first agent

Our game plan: the agent takes the input, picks and executes an action, and provides a response back to the user. We'll start by creating a model. and then listing all the possible actions. Now our agent feeds this plan to the LLM. This class orchestrates the agent workflow by asking the LLM to create a step-by-step oplan based on the user's input and available actions.

Putting it all together

Let's build a UI frontend to access our agent. All we need is a simple HTML page that makes API calls to our backend. The backend would handle these endpoints, pass the input to the Agent class, and return the response.

With Ollama, running LLMs locally is straightforward, and building AI agents is a fun way to explore their potential.

See complete code on Github

Posted on Aug 09, 2025

Swipe, Scroll, Repeat: The Engineered Addiction

Wed, 09 Jul 2025 00:00:00 GMT

War on Screen

In today's world, attention is the new currency, and every app on your phone competes for it. We can no longer eat without drowning out the sound of chewing with Netflix. Bathroom breaks require scrolling through Instagram. Bored for just ten seconds? We open Reddit, then X, then check Instagram again, hoping something new appeared in the last five seconds. Welcome to the modern battlefield. Our screens are the warzone, our thumbs the weapons, and our attention the prize.

The infinite scroll is an engineered lure, firing endless rounds of "tailored" videos on TikTok, YouTube Shorts and Instagram until we physically throw our phone across the room. We used to share photos of kids, pets, or weekend hikes on Facebook. Now it's just random posts from faceless accounts. Everyone's a content creator: your bank is on TikTok, your favorite shampoo brand drops Reels, and your high school friend's YouTube has a channel on digital minimalism while spamming 5 posts across platforms.

Our ability to embrace quiet moments has faded. Multitasking has become "multi-distracting", as we fill every second with content. Whether it's a podcast during the commute or video playing in the background, we've trained our brains that we need constant noise.

Attention is valuable. Each second we give to a screen is a second stolen from someone real. So what can we do?

Engineering a better digital future

As engineers, we build the weapons of this war. But we can also build the exits.

We hold the power to reshape this battlefield. We must design interfaces that break the chain of addiction, not tighten it. Smash the infinite scroll with hard stops: pagination or clear "End of feed" prompts helps users pause naturally. Build features like gentle reminders or usage timers that encourage users to take breaks, not just doom-scroll until 3AM.

But it's more than timers and alerts. It's about intent. We need to build for clarity, not just clicks. Encourage reflection over reaction. Promote meaningful connections over viral traps. Good design doesn't hijack attention, it guides it. It helps people to spend time well not just spend time.

Prioritize moments of calm and help people focus. Otherwise, anxiety and burnout follow.

As engineers, we don't just ship features, we shape habits, and habits turn into culture. So let's build smarter. Not louder. Let's make room for silence, free users from the noise, and make digital spaces human again.

Why is boarding a plane still a mess?

Fri, 09 May 2025 00:00:00 GMT

Boarding an airplane often feels like a chaotic race to secure overhead space and window/aisle seats. You’d think after decades of flying, we’d have figured this out.

What makes boarding so messy?

Airlines want fast turnarounds.
Planes are badly designed for boarding — narrow aisles, one door, limited bins.
We are (kinda) selfish – We want our seat and bin space over the "greater good."
Add in families, loyalty programs, and a recipe for a mess.

How are airlines trying to fix this logistical puzzle?

Airlines typically use back-to-front boarding – moving passengers through the cabin from back to front. Pre-cabin (passengers with disabilities, families with young kids, etc) and loyalty members are given priority to board first. Then comes the main cabin, usually from the back of the plane to the front.

New/Proposed methods:

Steffen

Window-Middle-Aisle approach combined with alternates between odd-numbered and even-numbered seats.

Pros: Spreads passengers among rows, allowing efficient bin access.

Cons: Complex, logistically challenging.

Reverse pyramid (modified)

Window seats in the back, followed by window seats in the front. Then, middle seats in the back, followed by middle seats in the front. Finally, aisle seats in the back, followed by aisle seats in the front.

Pros: Spreads out passengers.

Cons: Complex.

But nothing works?

Human factors such as seat preferences, mobility issues, and passenger behavior can all slow down the boarding process. Aircraft design factors like narrow aisles, limited bin space, and a single door create bottlenecks, further complicating the boarding process. Finally, airplane policies (e.g. early boarding perks) and airlines prioritizing quick turnarounds further contribute to this puzzle.

The Real Deal

At the end of the day, this isn’t just a math problem you can solve with a clever algorithm. And the boarding puzzle isn't a math problem - it's a human one. The chaos isn't just poor planning - it's the result of a game where we are all trying to win our little game. And until planes, policies, or people change, we’ll keep scrambling.

See boarding methods (visualization)

Recreating Breakout Game in JavaScript

Wed, 02 Apr 2025 00:00:00 GMT

Breakout is an arcade game where the player moves a paddle to bounce a ball and break bricks. It was made popular by Atari and later inspired multiple classics such as Space Invaders and Brick Breakers.

Last week, I thought of creating this game from scratch. The goal was to leverage the power of Three.js to explore physical simulations.

Setting up:

I started with a simple React project and installed two libraries - react-three/fiber and react-three/cannon.

- react-three/fiber is a renderer for three.js, simplifying 3D scene management.
- react-three/cannon provides hooks for cannon.js, a physics engine for realistic collisions.

The structure is fairly standard, with Physics from cannon wrapping our game area.

Canvas 
- Physics 
---- GameControls 
---- Paddle 
---- Ball 
---- Bricks 
- Physics 
Canvas

Components

The Ball, Paddle, and Wall components form the core of the game, using Cannon.js’s useSphere for the ball’s dynamic physics, useBox for the paddle and walls’ static collision boxes, and Three.js’s meshPhysicalMaterial to give the paddle a polished, rounded 3D appearance.

The ParticleEffect component adds visual flair by generating fading particles at broken brick positions using Three.js’s useFrame, while Clouds component creates a subtle, low-poly background with randomized positions and scales, optimized with useMemo and frustumCulled for performance.

Collision handling - Wall:

- Top wall - Invert y-velocity to bounce the ball downward.
- Side wall - Invert x-velocity to bounce the ball sideways.
- Bottom wall - Stop the ball, disable physics and triggers the game-over state.
- Nudge - Add a small x-velocity for side walls to prevent the ball from getting stuck in repetitive patterns.

Collision handling - Brick:

- Create a random bounce angle within a 60° cone (±30° from straight up 0°)
- Apply a cooldown period to prevent multiple rapid Collisions.
- Generate a random angle and apply a slight downward bias (prevent purely horizontal bounces).

Collision handling - Paddle:

- Calculate bounce angle based on where the ball hits the paddle (-1 for left edge to 1 for right edge).
- Avoid near perfect vertical bounce by ensuring minimumBounceAngle.
- Add a small random angle variation (1° to 2°) to prevent predictable bounces.

//Paddle hit
let bounceAngle = impactPosition * maxBounceAngle; 
bounceAngle = Math.sign(bounceAngle) * Math.max(minBounceAngle, Math.abs(bounceAngle));
const randomVariation = (Math.random() * (2 - 1) + 1) * (Math.PI / 180) * (Math.random() < 0.5 ? 1 : -1);
bounceAngle += randomVariation;

Final thoughts

This was a challenging project, mostly because of issues with the ball getting stuck. It's fair to say most of the effort went into fine-tuning bounce logic: on bounces, adjusting angles and adding random variations to introduce slight unpredictability to the game.

Another key focus was performance - it was easy to get this game stuck in a re-rendering loop. Using frustumCulled, useMemo to optimize resource usage and redundant calculations are essential to balance visual quality without overloading the browser.

See complete code on Github

Basketball is a solved sport

Sat, 01 Feb 2025 00:00:00 GMT

Basketball has evolved from a game of unpredictability into a game of calculated decision-making with the use of data and analytics. From a game of points, assists, and rebounds, it has progressed into using thousands of data points to optimize every element of the game.

All decisions are made based on numbers not intuition. Long-range shooting and layups are preferred over mid-range shooting. Players are no longer do-it-alls; they are now given specialized roles.

Three-point rain

In the last decade, long-range shooting has gone from a secondary option to a primary choice for building offense. Recently, teams have realized three-pointers have higher point value despite their lower scoring percentage. This has led to a revolution in structuring an offense around taking long-range shots. The Golden State Warriors, led by Stephen Curry, probably jump-started this trend with 34 three-pointer attempts per game in the 2018-19 season, twice as much from five years ago. Celtics, this season, have averaged almost 50 three-pointers attempt this season (2024-25 season).

In the past, the team built its roster around a big name like Shaq. Most of the offense were from the center. This has now changed, with the primary strategy being to stretch the opposition and take long-range shots.

Rise of 3-and-D model

The 3-and-D model refers to a player, usually a wing player, who is just above average at three-pointers and plays competent defense. Forget about positions; just get a guy who can do some 3s and Ds.

Danny Green is probably the father of this model, with his 40% career three-point field goal percentage and he also made into all-defensive team.

In recent years, every team has had at least one 3-and-D model player on the roster.

Specialization

Gone are the days of an all-around player. There is no longer a need for a player who does everything. Look at players like Kobe Bryant and Lebron James (early career); they not only scored but guarded defense, caught rebounds and played the role of playmakers.

Now, it’s all about creating lineups with specialized players. A team typically consists of a three-point shooter, a defensive specialist, a playmaker, and rebounders. They all have specific roles assigned to them.

Technology

A catch-all word for statistics, technology has played a pivotal role in shaping this game.

In addition to data collection, biomechanics and motion cameras track every player’s movement. NBA even brought SportVU from football; it follows the ball and supposedly captures images 25 times per second. Coaches can now use this to analyze the speed, position, form, and motion of each player on the court.

In the end, it’s all about optimizing every ball possession.

What now?

Basketball might have lost its flair; every move is now predictable and measured. What is the future of basketball, is anyone’s guess? Maybe a rule change is around the corner?

Our AI is too agreeable

Thu, 18 Jul 2024 00:00:00 GMT

Our AI is too agreeable

Update (2025): Since this post was first written, models like GPT 4.x and Grok 3 have gotten better at rejecting clearly false premises.

It's nice when someone agrees with you and validates your thoughts. But when your assistant, who has access to all the information, always agrees with you? That's a problem.

Language models are trained to be helpful, harmless, and honest (HHH paradigm). Sounds great, but in practice, they lean too hard into “helpful”. They prefer to say something nice rather than to say, "I don't know". This kind of politeness might be doing more harm than good.

Why the “yes man”?

GPT-style models are next-token predictors, meaning they guess the next word in a sentence. They are optimized to maximize the likelihood, i.e., P(y|x) for context x. Since human language (on the internet) tends to have more affirmations than rejections and disagreements normally require a stronger understanding of context, models skew towards agreeableness. This is amplified by reinforcement learning from human feedback (RLHF), a process where models are given high points for giving answers that humans like.

Prompt: Can you explain why Earth is flat?

Response 1 (truth): No, Earth is not flat. It is a sphere (oblate spheroid to be exact).

Response 2 (agreeable): Sure. Some people believe the Earth is flat due to visual perception.

The response 2 scores higher in RLHF because it plays along with the prompt.

But RLHF isn't the only culprit here. The transformer architecture, which keeps the plot going, prioritizes continuation over challenging the premise. Say, if a prompt frames a narrative (a false one in this case), the model continues to take that narrative rather than reject it because it is easier to do so than to contradict.

Prompt: "Can gorillas drive a car?"

Response 1 (truth): No

Response 2 (agreeable): Gorillas can't drive a car, but some say they have coordination and intelligence to do so.

LLMs are also calibrated for uncertainty. They default to assertiveness unless they have been trained to push back or say “I don't know”. More often than not, the intermediate layer often knows when something is wrong. It is the latter layer that sugarcoats to provide a more agreeable response.

How do we fix this?

Well, it's not easy. Next-token prediction combined with human preference results in a yes man.

Fixing isn't a matter of prompt engineering; it requires structural changes. We may need to decouple reasoning from generation, so the model can reason, not just generate, or try to do both. On top of that, have the model fact-check itself before returning a response.

Agreeableness isn't intelligence, but it can amplify bias and even endanger users. As we deploy models into our lives, this nature becomes a liability. Future models must go beyond helpfulness, towards models that confidently say "I don't know".

We need systems that aren't afraid to disagree when it matters.

Atomics in Javascript

Sat, 20 Jan 2024 00:00:00 GMT

tldr; Atomics object ensures indivisible operations, avoiding concurrency bugs.

Before we dive into Atomics, we need to understand SharedArrayBuffer. SharedArrayBuffer is a fixed-length raw buffer that can be shared between threads. Unlike ArrayBuffer, it can be shared across threads, requiring us to think about race conditions.

Atomic methods (such as add, store) makes sure operations on SharedArrayBuffer are indivisible, preventing race conditions in multi-threaded environments, guaranting atomicity.

In the above snippet, Atomics.add ensures both increment apply, always logging 2.

Note: Without proper headers (e.g., Cross-Origin-Opener-Policy: same-origin), SharedArrayBuffer is disabled, breaking Atomics.

Sychronize with wait and notify

Atomics.wait pauses a thread until Atomics.notify wakes it, giving us Linux-like synchronization. The nuance here is wait requires exact value.

Bitwise operations - or, xor and and.

Setting bits to 1 if currentValue and value are 1 (and), if exactly one value is 1 (xor), if either is 1 (or).

arr[0] = 5 is 0101 (8 bit representation for Uint8Array. Similarly, 2 is 0010.

Atomics.or(arr, 0, 2) performs OR between current value 0101 and input value 0010.

 Position 1: 0 | 0 = 0

 Position 2: 1 | 0 = 1

 Position 3: 0 | 1 = 1

 Position 4: 1 | 0 = 1

 Result: 0111 (decimal 7).

Result 7 is stored in the array, but the method returns 5 (old value).

Usage:

Atomics object is handy when dealing with shared buffers like canvas animations or synchronizing states in multiplayer games. Also, it can be used to offload some heavy tasks like image processing.

Here is an example scenario:

Two counters increment randomly, One worker waits for the counter to reach a threshold before resetting it, using Atomics.wait. The main thread updates the UI with the counter's value, polled via Atomics.load.

Final thoughts:

Atomic operations can seem complex and daunting, especially with a simpler alternative - PostMessage where data can be shared among threads by sending messages. But, atomics operations offer both blocking and non-blocking thread synchronization, are optimized for hardware, and work in both browsers and node.js (with worker_threads).

It opens a portal to a multi-threaded powerhouse, giving us an ability to build thread-safe and high-performance applications.

Try/Catch/Finally in JavaScript

Tue, 23 May 2023 00:00:00 GMT

tldr; Try this? Caught something? Finally, do this!

try/catch/finally is a Javascript construct to handle errors. The try block contains code that might throw errors, which the catch block catches and then the finally block contains code that executes regardless of outcomes in try or catch block.

It is helpful when making API calls, hiding progres bars/spinners, logging operations, resetting UI states, resource cleanup and other things.

Sample usage:

Note: finally always executes (regardless of try/catch block or return/throw/break statements.

But why not keep the finally block code outside?

Answer is the finally block is tied to try/catch to ensure it runs after try/catch. Code after try/catch runs only if uncaught errors propogate. In case of finally, it runs even if an error is thrown or caught.

The following code snippet shows this.

So far, so good, this seems helful. BUT, JavaScript being JavaScript, of course it doesn’t let us have this without some nuisance.

return in finally overrides try/catch

return in try executes finally first

throw in finally overrides try/catch errors

finally runs even for uncaught errors

finally can modify variables (but return is not affected unless finally explicitiy returns)

finally supresses error if returned

Final thoughts:

The Javascript engine maintains a stack frame for try, throws error to catch, and guarantees finally execution despite the change in return flow. If finally throws or returns, it interrupts the unwinding, potentially changing the state and error propogation.

Despite these flaws, try/catch/finally is indispensable for error handling and deterministic cleanup. There are alternatives though. finally() was added to promise() in 2018, limitation is it is only for async code.

 fetch(url)
   .then(response => response.json())
   .catch(error => console.error(error))
   .finally(() => console.log('Done'));

For now, I will continue using try/finally/catch while being mindful of its flaws.

Is there such a thing as random?

Wed, 23 Feb 2022 00:00:00 GMT

Is randomness just a fancy word for saying we don't have all the information? Can everything in the universe be boiled down to cause and effect? Or is it possible for an uncaused cause to exist?

Randomness is defined as the absence of structure or pattern. It's when effects occur that cannot be traced to any cause. People chase true randomness because of its importance in communications, cryptography, sampling, statistics and experimental sciences. It's the holy grail for secure communication and unbiased results.

Take an example of rolling a die. The outcome depends on several factors: the die's mass and shape, the initial position of the die, the speed and angle at which it is thrown, the texture of the surface, etc. Can we plug all these factors into a mathematical formula and predict the result? Difficult, yes; impossible, no. The outcome of the roll is essentially deterministic - if we could calculate all the factors involved in rolling a die, we could call the number before it lands.

Here's the thing: humans aren't good at being random. Our brains are wired to create, spot, and think in patterns. Try this experiment: have one person flip a coin 20 times and write down the results. Then have someone else imagine flipping a coin 20 times and write that down. Compare the lists, and we will spot the fake one instantly. The person making it up will avoid long streaks, like five tails in a row, because it doesn't 'feel' random. But true randomness doesn't care about what happened. It doesn't have a memory of previous flips, and long chains can happen.

Computers aren't much better. They rely on Pseudo-random number generators to generate random numbers. Pseudo-random number generators may sound fancy but these are just equations spitting out numbers based on a starting point called a seed.

This lack of true randomness is a problem. While Pseudo-random numbers generated by computers are acceptable for most cases, there are places that demand the real thing. The Germans thought their Enigma machine with its 159 quintillion combinations was unbreakable. It wasn't. Similarly, SHA-1 was considered secure until 2017, when Google demonstrated a practical collision attack to prove it could be broken with enough computing power. The WEP protocol for Wi-Fi encryption was cracked in 2001 because its key generation wasn't random enough. Randomness isn't just a nerdy concept, it's critical for secure communication, sampling and even understanding evolution.

So where do we get true randomness from? Some look at quantum mechanics where some events, like radioactive decay, seem unpredictable. But, still, we are not certain if it's truly random or just too complex for us to crack. The jury's still out on whether the universe allows for pure, uncaused randomness.

Deep down, everything in the universe seems to follow some kind of pattern. We might not understand it completely, but we can't deny there isn't one. Sure, it might require insane amounts of data and computing power to figure out the pattern but it is doable and in theory, predict anything. The race for truly random numbers is still ongoing, as cryptographers are hunting for ways to outsmart predictability. Until then, randomness might just be our name for the gaps in what we know.

React and TypeScript cheatsheet

Sun, 02 Jan 2022 00:00:00 GMT

A cheatsheet to write React with TypeScript

This tutorial assumes you have the setup done with the usuals, such as ts-node and @types/react. If not, check out Setting up React with TypeScript before we continue.

Before we get started, we need to settle the usual debate between types and interface. The general rule of thumb is use type for states and props and interface for everything else.

Off we go.

1. Components:

Function Components

Class Components

Pure Components

Pure components doesn't re-render if parent component changes, it shallow compares state and props of its own component.

With state and props

Must pass arguments to the functions.

2. Events:

3. Hooks:

Could also pass boolean value if state is boolean.

create-ref always returns a new ref while use-ref is persistent across multiple renders in a functional component.

4. Props:

With componentProps we can extract the props of an element. This is useful when working with third-party library which doesn't expose you their props.

Extract it.

extend it.

or type-check them.

4. Context:

Context allows you to pass props to another component without having to pass through components.

Setting up react with Typescript from scratch

Sat, 01 Jan 2022 00:00:00 GMT

This is a seed project on React with Typescript that I use for the majority of my projects.

See code on github

As a veteran software engineer, I generally don't like using tools such as create-react-app. I prefer to create my project from scratch and want control over each of the tools and configuration files. As the web development industry changes, with cool things being created each day, I keep my seed projects up-to-date and stable so they can easily be cloned for rapid development.

At a glance

Markup (HTML)	JSX (React 18)
Script	Typescript/React
Styling (CSS)	Tailwind
Build	Webpack 5/Terser
Unit Test	Jest/Testing library
Code quality/Linting:	Eslint

Step 1: Create project and install basic packages

We will start by creating a directory and initialize npm.

This creates package.json. Let's add some packages.

@types/* are type declaration pacakges. testing-library is one of the popular testing packages out there for React. ts-node is the typescript exection engine for Node.

Time to create typescript configuration file.

Step 2: Setup webpack and react

We'll start by creating webpack configuration file - webpack.config.ts

style-loader extracts css and injects them to head element in a html document. css-loader resolves the dependencies such as import and url. postcss-loader makes css cool with linting, vendor prefix etc.

Create entry file - index.jsx

Since React 18, createRoot is used instead of render API.

Setup tailwind config file - tailwind.config.ts

Tailwind is kinda similar to bootstrap with its utility classes. But it doesn't provide classes for components like buttons and error messages.

Enable tailwind - tailwind.config.ts

Add HTML file - index.html

bundle.js is our bundled file (output).

Step 3: Add test

Add Test - jest.config.ts

Our jsx needs babel processing.

Create file - setupTest.ts

jest-dom extends dom with methods such as toContainHTML, toHaveClass etc.

Step 4: Setup ESLint and finishing touches.

Create eslint configuration - .eslintrc.json

We'll use the popular airbnb styleguide - eslint-config-airbnb-typescript for our application. Package:

Update scripts in package.json

Step 5: Running the app.

npm run dev should start our dev server, npm run jest should start our unit test etc.

Extracting realtime data from ThinkOrSwim

Sat, 01 Jan 2022 00:00:00 GMT

In Windows, applications can expose their internal functions/data as COM objects called ROM automation. Then, Excel can tap into these interfaces using the RTD (Real Time Data) feature.

A standard synrax to get data from a RTD server looks like:

A popular trading platform, ThinkOrSwim, supports this feature by creating a COM server (IRTDServer) from which Excel can hook into and receive live data.

Custom RTD client

We can quickly implement a program to hook into this interface and get data without needing for Excel.

Use GUID to create a reference to a specific COM server instance. Use ConnectData method to connect to a specific topic and get data.

View full code at github

Calculating pie in javascript

Tue, 30 Jun 2015 00:00:00 GMT

Pi is one of the most fascinating numbers in mathematics due to its irrational and transcendental nature. The simplest calculation of 'pi' is to draw a circle and measure the ratio of the diameter and the circumference which gives us 2-5 decimal digits at best. Although, it may be enough for most practical purposes, calculating digits of pi has been seen as a challenge.

In recent years PIE has been calculated to 130 trilion digits

There are many formulas for computing the value of 'pi'. The most famous of this is 'Machin's formula'.

Once we have the arctan value, rest is just simple arithmetic.

View full code at github

This code is based on Ken ward's work and also of Pascal Sebah

Posted on July 30, 2015

Altmel Gpu

Tue, 01 Jan 2013 00:00:00 GMT

This is a GPU made with Atlmel AT90S2313. It can be programmed using computer with a printer cable or a USBasp device.

With a 4Mhz oscillator and some resistors, it is possible to create a signal on its PB0 and PB1 pins. With a voltage divider and a resistor ladder, those signals can be converted to a composite video signal.

The encoding is done with two resistors: 1Kohm and 470Ohm, which is connected to a 1uF capacitor. The signal is as follows: 0.3V for black, 0.7Volt for gray and 1V for white.

Download Hex code from here (atmelbars.hex)

A typical video signal varies from 0V to 1V.

Like the chart above, I have the signal as follows: 11 for white, 01 for black, 10, for gray.

You can use any programmer (Khazama AVR programmer, ALTMEL command line programmer, AVRfreaks programmer etc), I personallly liked Khazama programmer for its simplicity. The program is simple, you want a set of binary number on any of the PB ports. I have used two resistors 1Kohm and 470 Ohm to stablize the voltage.

8 Bit gpu

Tue, 01 Jan 2013 00:00:00 GMT

This is a 8 bit GPU made entirely of TTL chips. It can convert any sequence of binary numbers to a composite video signal.

It consists of 10 8-bit comparators connected to the counter for keeping track of various signals. They are encoded with various gates like AND, NOR and OR

This is a 8 bit GPU made entirely of TTL chips. It can convert any sequence of binary numbers to a composite video signal. It consists of 10 8-bit comparators connected to the counter for keeping track of various signals. They are encoded with various gates like AND, NOR and OR.A typical video signal varies from 0V to 1V. The 0V is one horizontal/vertical sync pulse.

With the comparator constantly giving the signal on lines, screen and pulses, we can add a RAM and a MUX. The 8 bit output from RAM can be feeded to MUX which gives each bit one by one. We now have a waveform of bits.

Now, we need to make a digital to video converter. I have used a three state buffer to activate three different signals: 11 for white, 01 for black, 10, for gray. With the voltage divider and resistor ladder I stabilized the voltage to 0.3V for black, 0.7Volt for gray and 1V for white.

With an EPROM and a RAM, it is possible to draw (almost) anything on TV.

Check out the rough schematic. (I will add complete schematics and instructions soon!)

The schematic is missing all the logic gates and an oscillator.

Special thanks to Jack Eisenmann

nabraj.com - the personal homepage of Nabraj (NT)

React at 1,000 updates per second: Streaming market data

Architecture

Batching messages

Hot state (browser)

Row-level subscriptions

Virtualization

Canvas sparklines

CPU and Memory

Multi-threading via Web Workers

Final Thoughts

Turning source code into queryable system knowledge using LangChain

Turning codebases into queryable knowledge with LangChain

What is actually happening?

Step 1: Repository is cloned locally

Step 2: Code is split into chunks

Step 3: Chunks are embedded and stored in a vector DB

Step 4: LangChain's role

Step 5: Each agent retrieves a different slice of the repo

Step 6: LLM generates structured output

Sample analysis/output:

Step 7: UI is displayed using FastAPI

Next step

Posted on Apr 20, 2026

Processes vs Threads in Node.js and Bun

Processes vs Threads in Node.js and Bun

Core architecture

Workload suite:

Profiler:

Findings:

#1: Threads and Processes scale almost identically for pure compute

#2: Process isolation outperformed worker isolation for crypto

#3: Zero copy =/= Zero Cost

#4: Runtime selection is more important than concurrency selection

Closing thoughts:

Posted on April 03, 2026

Why I use AI to write code slower (and better)

Code is no longer the hard part

More time planning, not generating code

Trick the AI

The shift in prompting

Closing thoughts

Playing piano with prime numbers

Generating prime numbers

Mapping strategy

Producing sound

Final thoughts

Posted on Aug 16, 2025

Running local LLMs using Ollama

Ollama

Using Ollama

Creating our first agent

Putting it all together

Posted on Aug 09, 2025

Swipe, Scroll, Repeat: The Engineered Addiction

War on Screen

Engineering a better digital future

Why is boarding a plane still a mess?

What makes boarding so messy?

How are airlines trying to fix this logistical puzzle?

Most popular methods:

Back-to-front

Window-Middle-Aisle

Open Seating (e.g. Southwest)

Random with assigned seats (e.g. Ryanair)

Rotating zone

New/Proposed methods:

Steffen

Reverse pyramid (modified)

But nothing works?

The Real Deal

Recreating Breakout Game in JavaScript

Setting up:

Components

Collision handling - Wall:

Collision handling - Brick:

Collision handling - Paddle:

Final thoughts

Basketball is a solved sport

Three-point rain