Two reasons why I couldn’t go for image generation via AI though:

• My organization’s internal AI gateway didn’t support multimodal output, and they had no plans to do it anytime soon.

• Even if I did find a way, generating images for hundreds of products would take forever. Certainly it could be done in the background, but it would be costly and would negate the purpose it was trying to solve in the first place.

The Solution: You Don’t Need Image Generation

What if instead of generating, we fetch images online and rank them?

I started looking for image search APIs and found Openverse. The ranking part could be done by an LLM, which is much more efficient than generation, both in terms of cost and time. The ranking could also be done by humans, which is why I added this functionality to the manual mode of my application as well.

The overall pipeline still took around 2–3 minutes (sometimes up to 5). I worked around this limitation by using push notifications when the ranking was done. But it still wasn’t great user experience. And frankly, only slightly better than doing it manually. On top of that, Openverse was failing for most products, often returning irrelevant images or nothing at all. Because of this, many products ended up without images at all. So we had multiple problems at once:

• latency
• poor UX
• reliability issues
• and incomplete coverage

Too many products simply had nothing to rank, and this half-baked workflow was still taking too much time.

I found that one of my colleagues had used the Pexels API for their application and it performed surprisingly well, even with technical product names. I replaced Openverse in my application using it just as a fallback.

Pexels API was much more reliable, which meant it was fetching images for hundreds of products without failing. But that also meant the LLM now had to rank all those images.

From Minutes to Milliseconds: Local embeddings over LLMs

The LLM ranking was now taking 5–10 minutes and sometimes even 15 minutes when the number of products was high.

This is when I decided to revisit the requirement again. All I really needed was that the image be relevant to the product name.

I looked online and found a good number of models that can be used for exactly this purpose. These models work by converting images and corresponding text into vectors. They then calculate similarity using a dot product (or cosine similarity).

LLMs only make sense when you have to ask back-and-forth questions regarding the images.

My requirement was way more straightforward. No generation, no reasoning.

I replaced the LLM calls with a local inference using the clip-ViT-B-32 model, and the amount of time to process all those images dropped to milliseconds. In fact, the API calls to fetch the images were now taking longer than ranking them.

You may not need LLMs either

In hindsight, this wasn’t an image generation problem at all. It was a retrieval and ranking problem.

The biggest takeaway for me was this: look closely at your actual requirement before reaching for LLMs or generative AI. Sometimes, not using LLMs is the better engineering choice.

The mechanism used for this purpose is Server-Sent Events (SSE).

Server Sent Events (SSE)

SSE is an HTTP response format described by WHATWG HTML Living Standard for servers to push data to a browser over a persistent HTTP connection.

Web Hypertext Application Technology Working Group or WHATWG maintains the HTML Living Standard which specifies how browsers should work. Which makes SSE more of a browser thing rather than an internet standard which are maintained by IETF and W3C.

The server sends a response with Content-Type: text/event-stream and keeps the connection open, writing events whenever it has something to say. The client receives them as they arrive.

The wire format is minimal. Each event is one or more data: lines followed by a blank line:

data: This is the first message.

data: This is the second message, it
data: has two lines.

data: This is the third message.

Events can also carry these other fields:

• id: Used for reconnection. The browser sends the last received ID in a Last-Event-ID header when it reconnects.
• event: For named event types. But in practice you often skip both and just put all the information in the data: JSON payload itself.

The browser exposes this via the EventSource API:

const source = new EventSource('/api/stream');
source.onmessage = (e) => console.log(JSON.parse(e.data));

That's all the client needs. The browser handles reconnection automatically if the connection drops.

Why Not WebSockets

At this point, you might have this question if you're familiar with WebSockets since it also pushes data from server to client without the client polling.

And you can actually use WebSockets for this purpose as well, but it would be like using a bulldozer to hammer a nail. WebSockets are bidirectional and work great for chat, collaborative editing, multiplayer games. But for the much simpler use case of streaming text, the client just sends one request and only listens - unidirectional.

SSE also runs over plain HTTP. It's just a long-lived response. While WebSockets require a connection upgrade and a lot of custom logic just to work.

SSE is just the right tool for this use case. But I don't use it as it is.

My Setup

It has three participants: an LLM API, my Node.js server, and the browser. The LLM API itself streams SSE. So the server receives a stream and has to forward it to the browser as a new stream.

On the server side, I use Axios with responseType: 'stream' to consume the LLM's SSE response as a Node.js readable stream, then call res.write() to push each event down to the browser.

const response = await axios.post(LLM_ENDPOINT, payload, {
  responseType: 'stream'
});

response.data.on('data', (chunk) => {

  for (const line of chunk.toString().split('\n')) {

    if (!line.startsWith('data: ')) continue;

    const raw = line.slice(6).trim();

    if (raw === '[DONE]') continue;

    const parsed = JSON.parse(raw);
    const content = parsed.generations?.[0]?.text || '';

    if (content) {
      buffer += content;
      const partial = tryParsePartialJson(buffer);
      if (partial) {
        res.write(`data: ${JSON.stringify({ type: 'partial', data: partial })}\n\n`);
      }
    }
  }
});

response.data.on('end', () => {
  const final = JSON.parse(buffer);
  res.write(`data: ${JSON.stringify({ type: 'complete', data: final })}\n\n`);
  res.end();
});

The server also needs three headers:

• Content-Type: text/event-stream: Standard SSE header. Tells the browser to treat it as a stream rather than a regular one-shot response body.
• Cache-Control: no-cache: Prevents proxies and the browser from caching the response. Without this, intermediaries might buffer the entire response before forwarding it.
• Connection: keep-alive: Instructs the underlying TCP connection to stay open. Without it, the connection could be closed after what looks like a complete HTTP response.

❗️If you're using a reverse proxy, this can break production. Reverse proxies buffer HTTP responses by default, waiting to accumulate enough data before forwarding. SSE events held in a buffer don't reach the browser until the buffer is flushed, defeating the whole point.

For Nginx, the fix is one header: res.setHeader('X-Accel-Buffering', 'no'). This is an Nginx directive that can be set via a response header. Setting it to no tells Nginx to pass each write through immediately. Other reverse proxies have their own equivalent mechanisms.

Out of the SSE Box

SSE was originally meant for live feeds and stock tickers - much lighter use cases. With AI applications, the requirements go further. But there are common patterns and practices already.

fetch() Instead of EventSource

The browser has a native EventSource API for SSE. You'd think to use it here, but there's a catch: EventSource only supports GET requests. My endpoint needs a request body (the user's prompt, some config), so I can't use GET.

The standard approach across LLM apps and SDKs is using fetch() with the Streams API.

const response = await fetch('/api/ai/suggest/stream', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ prompt, pricebookId }),
  signal: abortController.signal
});

const reader = response.body.getReader();
const decoder = new TextDecoder();
let buffer = '';


while (true) {
  const { done, value } = await reader.read();
  if (done) break;

  buffer += decoder.decode(value, { stream: true });
  const lines = buffer.split('\n');
  buffer = lines.pop(); // keep the incomplete last line

  for (const line of lines) {
    if (!line.startsWith('data: ')) continue;
    const data = JSON.parse(line.slice(6));
    handleEvent(data);
  }
}

The buffer = lines.pop() line is the important bit. A TCP chunk can arrive mid-event. The data: line might be split across two reader.read() calls. Keeping the last (potentially incomplete) line in the buffer and prepending it to the next chunk handles this correctly.

The AbortController signal gives you cancellation for free: pass it to fetch, and calling abort() tears down the connection. I use this when the user navigates away or explicitly cancels.

Streaming Structured Data

Streaming plain text is straightforward. My case had the LLM generating structured JSON. When formed completely, this JSON would fill up a table on the front-end. But I wanted to stream this table, which would involve parsing the half-baked JSON as it poured in and putting the values in the right rows and column.

The problem is that JSON is only valid once it's complete. A mid-stream buffer like {"items":[{"name":"Cloud S will fail JSON.parse.

I used a library called partial-json for this. It parses whatever is valid so far in an incomplete JSON string. So {"items":[{"name":"Cloud S becomes { items: [{ name: "Cloud S" }] }. It handles open arrays, open objects, truncated strings.

import { parse } from 'partial-json';

// On each chunk from the LLM:
buffer += newContent;
try {
  const partial = parse(buffer);
  if (partial && typeof partial === 'object') {
    onChunk(partial); // send to frontend
  }
} catch (_) {
  // buffer not yet parseable, keep accumulating
}

This lets the UI show suggestions appearing one by one as the LLM generates them, even though the final response is a single JSON object.

One Stream, Multiple Concerns

A streaming LLM call isn't just one thing happening. Before the LLM even runs, my server does some prep work (extracting context, building a plan). I wanted the UI to reflect each of these phases, not just sit on a spinner until the first chunk arrived.

Instead of opening multiple connections, I used a typed event protocol over the same SSE stream:

// Server emits these as the pipeline progresses:
{ type: 'phase',    phase: 'extracting_context' }
{ type: 'phase',    phase: 'building_plan' }
{ type: 'partial',  data: { items: [...] } }      // LLM streaming
{ type: 'complete', data: { items: [...] } }       // final result
{ type: 'error',    message: '...' }               // on failure

The client switches on data.type and updates the UI accordingly, changing the status message during the pipeline phases, then rendering incremental suggestions as partial events arrive.

Using JSON payloads over a single typed channel is simpler than SSE's native event: field, because you can carry arbitrary structured data alongside the type. And since you're already parsing lines manually via fetch(), the native event: field would just be one more thing to parse out.

Error Handling

Errors during streaming are awkward: you've already sent a 200 OK status and started writing the body, so you can't send an HTTP error code anymore. The solution is to send an error event over the stream and close it.

res.write(`data: ${JSON.stringify({ type: 'error', message: err.message })}\n\n`);
res.end();

On the client, the error event triggers the same cleanup and user-facing message as any other error path. The important thing is to always call res.end(). Leaving the connection open after an error will hang the client.

The Before/After

Streaming is becoming an increasingly common pattern in AI applications, and for good reason. The non-streaming version was a regular async/await call: send request, wait several seconds, return JSON. Straightforward to write, but the UX was a fixed spinner with no indication of progress.

This created an impression of a slow application, with users saying they might just do it manually.

The streaming version is more moving parts but the result is that the user sees each phase as it happens and suggestions start appearing well before the LLM finishes. For a feature people are waiting on, that matters.

Too Many Round-Trips

The standard Composite API (/services/data/v*/composite) has a hard limit of 25 subrequests per request.

For each product we need:

• 1 subrequest for Product2
• 1 subrequest for the Standard PricebookEntry
• N subrequests for custom pricebook entries

So with 5 custom pricebooks, each product uses 7 subrequests: fitting only 3 products per batch (25 ÷ 7 ≈ 3). Saving 30 products meant 10 sequential round-trips, each adding its own network latency.

const subrequestsPerProduct = 1 + 1 + customPricebooks.length;
const batchSize = Math.floor(25 / subrequestsPerProduct); // Often 3-8 products

Composite Graph API + sObject Collections

We moved to the Composite Graph API (/services/data/v56.0/composite/graph) for Product2 creation, and sObject collections (/composite/sobjects) for PricebookEntries.

• Product2: one graph per product, all sent in a single API call. Products are created in parallel without sharing the 25-subrequest limit.
• PricebookEntries: sObject collections support up to 200 records per request, so all Standard and Selected PricebookEntries go in one or two calls.

// 1) Create all Product2s via composite/graph (parallel graphs)
const graphResp = await sendRequest(req, `/services/data/v56.0/composite/graph`, POST, graphPayload);

// 2) Create all Standard PricebookEntries (up to 200 per request)
await sendRequest(req, `/services/data/v56.0/composite/sobjects`, POST, { records: stdRecords });

// 3) Create Selected PricebookEntries (if different from standard)
if (shouldCreateSelectedPbe) {
  await sendRequest(req, `/services/data/v56.0/composite/sobjects`, POST, { records: selRecords });
}

2-3 API calls total, regardless of how many products.

Time Savings

Each round-trip adds roughly 100-300 ms. For 30 products, that's about 2-3 seconds saved per save.

A Few Design Choices Worth Noting

Separate graphs per product: each product gets its own graph so one failure doesn't roll back the others. Users still get partial success when some products fail.

sObject collections with allOrNone: false: lets us create up to 200 PricebookEntries per call while still handling per-record failures gracefully.

Only the selected pricebook: we create PricebookEntries for the standard pricebook and the selected one, not every custom pricebook. Keeps things simple for the main use case.

Takeaways

The Composite Graph API removes the 25-subrequest ceiling by running graphs in parallel. Combined with sObject collections for bulk child records, you go from N round-trips to 2-3 regardless of scale. If you're building similar batch operations on Salesforce, it's worth the switch.

I used free models on Open Router since I was just building an MVP and wasn’t willing to pay just yet.

Following are some of the models I tested and the results. Keep in mind that all of these are free variants of the models.

DeepSeek: R1 Distill Llama 70B

This is a distilled LLM based on Llama-3.3-70B-Instruct model. This is the model I tested for the longest since it was one of the few available free models a while ago. This also gave me the best summaries out of the available free models at the time, both in terms of adherence to instructions and accuracy.

The only issue with it was the consistency. 1 in 10 summaries went wrong, quite frequently. Sometimes the format would be unexpected, other times it would outright deny being able to summarize. Occasionally it would also return some random response. For example, some tags for the article instead of summary. It fared well on accuracy though. Never gave any incorrect or outside information.

To be fair I didn’t try adjusting the temperature since I wanted somewhat witty output and I was afraid fiddling with temperature might hamper that. Also, the hugging face page for the model explicitly states not to give the model any system prompts, which I did anyway. I guess, I didn’t give it a fair chance.

MoonshotAI: Kimi K2

Since this was a mixture-of-experts model, I figured why not give it a chance as my use case required summarization of articles from different domains.

This gave good results overall. I was not completely satisfied with the impactful article selection. The summaries and their titles lacked clarity as well. Although, it didn’t give me any buggy data.

DeepSeek V3-0324

I abandoned it soon since it called Trump, ‘former’ POTUS. While not entirely wrong, but still a red flag for my use-case. Also some summaries were too small.

Dolphin Mistral 24B - Venice Edition

This is a collaborative project between cognitivecomputations and Venice.ai to create an uncensored version of Mistral 24B.

I included this in my testing since this is an uncensored model, which could be particularly useful for my use case of summarizing news articles. But the impactful article selection was not great so I moved along.

DeepSeek R1 0528

This was the best one until this point in summarization, but it was incredibly, dare I say, even painfully slow. That would not be a deal breaker for my use case since I’m not summarizing in a user-facing application at runtime. Only issue could be that it would make testing it a bit difficult and time consuming.

Another issue was adherence to the format. With the title generation for the summary, it provided an “Alternative title”. I could fix this via prompt, but I decided to keep it aside and give other models a try.

Qwen3 Coder

Because why not? Its the state-of-the-art coding model right now, and I thought it might be fun to see how a coding model performs as a journalist summarizing articles. Not so surprisingly, this model was fastest one of the bunch. The issue however, was that it didn’t stick to the tone I asked for, which was a bit witty and clever. It also included some html tags like <div> in the response along with some inline styling.

Its exactly what you’d expect from a coder though.

Microsoft: MAI DS R1

This is a post-trained variant of DeepSeek-R1 developed by the Microsoft AI team improve the model’s responsiveness on previously blocked topics while enhancing its safety profile. Safety was an important parameter for me and I already had good experience with DeepSeek R1 models, so I decided to give it a try.

This was the best performing model without a doubt. It adhered to all the instructions, remained factually correct and covered all the important points while summarizing while maintaining the tone and format I was going for.

Needless to say, this was the one I ended up using for my use-case.

If you’re exploring summarization for your own project, I hope this gives you a head start. Let me know if you’ve found a model that worked well for you. I’d love to hear.

My intention with these notes is not to go too deep into the mathematics involved. Where required, some mathematical information is included. The assumption is also that you are familiar with high-school level mathematics. Maybe you don't remember all of it, but if you hear something and you can recognize the concept, it should be enough to understand these largely. I also assume that you understand how a model is trained at a very basic level.

I’d also recommend reading this alongside the original paper. It helps to refer to the figure and notations directly as you go.

Figure from the paper illustrating the approach

Terminology

• Upstream Tasks: Tasks which affect the model -> tasks which help the model make sense of the unlabelled data. (not that important for this paper)
• Downstream Tasks mean the specific language tasks we want to solve after pretraining a language, like QnA, sentiment analysis, summarization etc.
• Pretraining refers to the initial training phase where model learns general language patterns by processing large amount of unlabelled data.
• Parametric memory: Trained part of the model. Parameters of the model are fixed after training phase. This can't be changed without training.
• Non-parametric memory: Things stored outside the model, fetched via a 'retriever'.
• seq2seq model: sequence-to-sequence model. maps one sequence to another for tasks of taking one sequence as input and emitting other as output.
• Extractive downstream tasks: Extracting information from documents.
• Differentiable access mechanism: Mechanism to retrieve the relevant documents.

Overview

• Pretrained models with just parameterized knowledge base are fixed. Its difficult to revise their memory.
• You can't see where the predictions are coming from -> prone to hallucinations
• Solution: Hybrid models combining parameterized and non-parameterised memory
  • knowledge can be revised and expanded
  • accessed knowledge can also be inspected
• REALM and ORQA are two such models but they only extract the information.
• Components
  • Parametric memory: pretrained seq2seq transformer (BART)
  • Non-parametric memory: Dense vector index of Wikipedia
  • Retriever: Dense Passage Retriever (DPR)
• Top-K approximation used for the document retrieval
• Previous models with non-parametric memory for were trained for specific tasks. This paper just uses pre-trained memory components.
• These are tasks which even humans can't perform without access to an external knowledge source.
• These RAG models achieve remarkable results on multiple benchmarks also outperforming other approaches in one.
• Models generate more factual, specific and diverse responses than BART baseline.
• In a fact verification benchmark, model performs within 4.3% of other state of the art models.
• Changing the memory is also demonstrated.

Methods

Mathematical Sidenote

The notation pₖ(y|x) is used to represent conditional probability distribution of y, for a given x. k represents the parameters of the distribution.

Latent variables are unknown variables which can't be observed directly, but they affect the outcome.

Marginalization is way to calculate the total probability of something by considering all possible values of the unkown (latent) variables. Since latent variables are unobserved, we can't pick one, so all of them are included.

Components and Notation

• x : input sequence
• y : output/target sequence
• z : text documents

Based on above, the components are denoted as:

1. Retriever
   • Retriever is supposed to fetch the documents z, given the input sequence x.
   • It does that by determining probability for different documents, based on x.
   • The distribution is parameterized by η. These are the parameters within the model which are tuned as part of the training.
2. Generator
   • Generator is supposed to generate tokens based on the input sequence x, documents z and the previous tokens.
   • This again depends on the probability distribution of the tokens.
   • θ refers to the parameters of the model, tuned via training.
   • Generators have been using this technique of predicting the next token for a while. This wasn't the breakthrough of 'Attention is all you need'.

The documents are treated as latent variables.

'Marginalizing the document to get the generated sequence' just means calculating the probability for output sequence using the identified relevant documents, each weighted by relevance.

Models

As discussed before, two different ways are used to generate the output sequence:

1. RAG-Sequence Model
   • Uses same retrieved document to generate the complete sequence.
   • Retrieved document treated as a single latent variable
   • The probability of getting output for a given input is denoted by:
   • The output depends on the token coming before each, so if we write in terms of each $i$:
   • Since the document z is going to be common for all tokens, p(z|x) doesn't need to be part of the term for each i. Its kept separate from the product.
2. RAG-Token Model
   • Draw from a different latent documents for each target token.
   • The probability of output for a given input is denoted as:
   • For each token, the document is retrieved. So this time $p(z|x)$ is part of the product term.

The summation in both cases is performed for the top-K documents retrieved for the input.

For sequence classification case, where target sequence of length one is considered, both models are equivalent.

Components

Both RAG models, RAG-Sequence and RAG-Token use the same retriever (DPR) and generator (BART). Its the manner of their usage, which differs.

Retriever - DPR

• The documents are first encoded by BERT (base) document encoder. This converts the documents into vector embeddings. This is denoted as d(z).
• The query (input) is also encoded by the same. This is denoted as q(z).
• DPR retrieves the top-k documents with highest probabilty using MIPS
• MIPS (Maxiumum Inner Product Search) is a similarity search method. It retrieves the documents whose embeddings have the highest dot (inner) product with a query embedding. This is represented in the paper as: pη​(z∣x)∝exp(d(z)⊤q(x))

Generator - BART

• BART (large) is used here. Its a seq2seq transformer with 400M parameters
• Any encoder-decoder could have been used for this purpose
  • The model selection depends on what's state-of-the-art at the time and also what's more accessible. Since this research originated at Facebook (now, Meta), using BERT made sense since it was already state-of-the-art at that time, and since it was a model from facebook, they would have more understanding and more control over tweaking it.
• When predicting the next token, it is based on what has been predicted till now. To do this, the retrieved content and input is concatenated.
• This model has previously also achieved state-of-the-art results on various generation tasks and outperformed similar models at the time.
• BART generators internal parameters (parametric memory) is denoted as θ.

Training

This is quite interesting. So the mechanism requires the documents to be encoded via a document encoder. But if you train the document encoder again, the previous embeddings become meaningless, and you'd have to perform the encoding again.

This was attempted by another model REALM during pre-training and obviously turned out to be quite costly. Instead, here the document encoder is kept fixed along with the encoded index.

Only the query encoder and the generator are fine tuned.

Now the purpose of any learning is to minimize a loss function. The minimization of the 'negative marginal log-likelihood' is just a standard for seq2seq models. Basically, you want to tune the parameters in such a way that you maximize the probability of the correct answer getting picked. You can also turn it around and say, you want to minimize the negative probability of the correct answer getting picked.

Training is done via gradient descent and most optimizers (used for training) support this downhill roll, rather than an uphill climb, which is why its flipped. You keep moving downhill, until you're in the valley's deepest point (the minimum).

Logarithmic just makes the gradient more stable and turns product into sum. If you keep multiplying the probabilities for each pair, it could limit zero.

Decoding

Decoding process of both models is different.

RAG-Token

The per-token nature of generation was established as a standard up until that time. So, RAG-Token model simply used that. It does that using beam search.

Beam search predicts possibility of next-token from its vocabulary, takes the top-k tokens, predicts the next possible token for each of those $k$ tokens, and continues to do so until end-of-sequence.

In RAG-Token, the vocabulary is the entire document index. So this can be used directly.

RAG-Sequence

In RAG-sequence though, the vocabulary can't be the entire document index. It needs to pick a single document which is most relevant. Thus, beam search is performed for each document. This results in a set of hypotheses Y. These are the set of output sequences from each document.

Thorough decoding: The decoder is re-run for each hypotheses y, against each document z except for the one it was generated from.

Fast decoding: Additional pass is skipped for longer output sequences for efficiency. In this case, its assumed that the probability for y, against each document it was not generated from is 0. That is:

These give the probability of how likely y is, if model had access to just z. Each such term is multiplied with the p(z|x), which is the probability of z being the right document for the input x. Combining both (summation) gives us the marginal probability of y emerging from x.

After this, the hypotheses with the highest probability is selected as the output sequence.

The experiments, results, model comparison etc will be covered in a follow-up.

We may regard the present state of the universe as the effect of its past and the cause of its future. An intellect which at a certain moment would know all forces that set nature in motion, and all positions of all items of which nature is composed, if this intellect were also vast enough to submit these data to analysis, it would embrace in a single formula the movements of the greatest bodies of the universe and those of the tiniest atom; for such an intellect nothing would be uncertain and the future just like the past could be present before its eyes.

— Pierre Simon Laplace

Laplace introduced this concept of a “vast intellect” while talking about determinism in classical physics. Here we take it a step further and apply it to literally everything (and see if we can create God).

There have been arguments against this demon based on the non-deterministic nature of quantum mechanics or thermodynamic systems. But we don’t really care about determinism, reversibility, or the past, since we are trying to create God. A being of such perception would already know what has already happened. We are mainly concerned with predictability. If this being even knows all the possible futures, that should be sufficient. There have also been arguments citing the unpredictability of chaotic systems or free will acts. However, I think (in my limited knowledge) that this “unpredictability” is a result of our limited human precision. Such a creature would have unlimited precision, making what seems unpredictable to us entirely predictable to it.

Suppose such a vast intellect exists, having access to all the parameters and knowledge necessary to determine at any point in time how things will unfold. It would require an enormous amount of processing power. Is it possible? There is, in fact, a computational limit of the universe defined by Bremermann's limit, which places an upper bound on the computational capacity of a finite system. Since computation is a physical process, it is bound by the constraints of the physical universe. There is obviously limited mass and energy in the universe, hence, a limit to computations. While this limit is far beyond human capability, it still is a limitation. However, since this is a thought experiment, let’s hold that thought for now and assume it has the necessary computational power. Perhaps everything played in its favor (like human evolution), leading to its emergence over time without self-destruction (unlike humans). It could have neurons—or some equivalent processing units—billions of times more numerous than those in human brains. The sheer scale of such an entity is incomprehensible. Imagine the sensory input required to gather that much data, process it based on the corresponding knowledge, and determine its consequences.

Talking about senses - since its not just the processing, but also the ingestion of this data, The creature might possess a multitude of senses, allowing it to perceive reality at both the most microscopic and macroscopic levels, spanning atomic interactions to universal-scale events. Such a creature would be able to see past, present and future alike. Since I mentioned past, present and future, this creature might even be a higher-dimensional being. This simply means it can observe the (block) universe from any coordinate system, such that it can view what is past or future from our point of view. For this entity, past and future would be as real and coexisting with present as “forward” and “behind” are to us three-dimensional beings. Making even the calculation unnecessary because past present and future exist simultaneously for Him. It could also “interfere” in the system from time to time to tweak the events according to its will.

Its almost scary seeing this vastness. But assuming this creature does have intellect, it would be fair to assume that he has understanding of Game theory, and would want to keep the system stable and would want to induce balance in order to protect it from collapsing.

Interestingly, such a being also wouldn’t need to approximate. If you think about it, physics and chemistry (largely) are approximations of particle and quantum physics, economics is an approximation os individual psychology, medicine is an approximation of molecular and cellular biology. Such segregations won’t exist for this entity. Segregations only exists to make it comprehensible to our limited human perception.

In such a vast universe though, would it matter to this creature whether humans live or die? Maybe its not as vast as we imagined then. Still baffling.

Remember how we talked about a limit to the computational capability of this being. It still would be smart enough to figure out a way of delegating responsibilities and appointing lesser beings to oversee specific domains. Or, if it is advanced enough, it might generate smaller versions of itself to manage different aspects of existence.

Who or what is this higher entity then? Is the universe itself alive? Or is this an entity bigger/higher than the universe itself? Is it Bradley Cooper?

Who is to say? I just created God and every concept associated with Him sitting in my bedroom. Human mind and intellect itself is puzzling.

Maybe God is indeed a thought experiment.
(typical human arrogance)

Wait!

That sounds counterintuitive. And it is.

It is particularly useful in scenarios where there could be multiple optimal solutions or multiple right answers. But since you are greedy, you just go with one — whichever one is best for you.

For example, consider the following scenario:

You want to find the least possible cost to go from A to B. There are two paths here which give you the least cost — two right answers. But the problem is not to identify the path, but to get the least cost. So you go with any one of them.

Another characteristic of a greedy algorithm is that it makes locally optimal choices — assuming it will eventually lead to a globally optimal result.

I am fascinated by how much this method applies to real life and how well it applies to our decision making. Of course, in real life, there are lot more input parameters and lot more outputs which you are trying to optimize. You might often use this method without even realizing it. When deciding which exercises to select for your particular goal, when deciding which car you need to buy, in fact, it applies to almost every decision of your life.

It might even yield better results if we apply it consciously. Take task prioritization as an example. (I am going to try this from my next sprint).

Write down the tasks you are assigned and score it according to the benefit that the task offers. This benefit could be personal (since we are being greedy) or for your product or team. Now write the deadline for each task. For each task, you want to maximize the profit, but you also want to pick the task which is more urgent first.

Final Score = Benefit/Deadline

Sort your tasks in descending order of their final score and you have a rough order for taking up these tasks. It’s a knapsack problem!

At each point in your life, you make or rather, should make the “locally optimal choice”. And in the end you hope, if you make enough locally optimal choices — you will end up with a globally optimal life!

What Are Runtime Dependencies?

At their core, runtime dependencies boil down to two categories:

1. Execution Order Dependencies: When one task must finish before another can start.
2. Data or Resource Dependencies: When one task requires data or resources generated by another or when tasks share the same resource(s).

These dependencies create challenges that need careful handling to avoid bottlenecks, resource contention, or cascading failures. Let’s dive into some strategies to manage them.

Decoupling with a Third Component

Whenever you’re dealing with runtime dependencies, the most reliable solution is to decouple them using a third component. This component acts as a mediator and can take various forms, such as a messaging queue, a buffer, or even a simple asynchronous function call.

The decoupling can happen in several ways:

• The third component might live within one of the dependent components.
• It might be an entirely separate entity.

Think of any runtime dependency you’ve resolved—chances are, the solution involved some flavor of this approach.

Three Key Strategies to Handle Dependencies

Runtime dependencies often manifest as "X needs to happen before Y." Whether the dependency is about shared data or sequential execution, you generally have three options:

1. Make Y Wait for X: This is the simplest approach: Y patiently waits until X is done. While it works fine for systems with low concurrency needs, it’s not scalable. Waiting introduces bottlenecks, slowing down the overall system.

2. Separate Independent Parts of Y: If only some parts of Y depend on X, isolate the dependent elements. The independent parts of Y can proceed while the dependent ones wait. This minimizes delays and keeps your system moving as efficiently as possible.

3. Precompute Multiple Instances of X: For systems that need to scale, this strategy is a game-changer. Execute X in advance, store the results, and let Y access them when needed. This approach:

   1. Decouples timing between X and Y.
   2. Reduces single points of failure by spreading the workload.
   3. Enables reusability: if multiple instances of Y rely on X, precomputed results avoid redundant processing.
   4. Boosts fault tolerance: if Y fails, X’s results are still intact.

Real-Life Example: A Buffer-Based System

Here’s how I applied these principles to a real-world problem:

I was working on a service for generating and scheduling automated tests for some declarative Infrastructure-as-Code (IaC) services. These tests had both order and data dependencies. For instance, you can’t unblock something that hasn’t been blocked, and you can’t block something that hasn’t been set up yet.

Initial Approach: Chained Scheduling

We initially considered a straightforward approach: chain the test executions together. However, this quickly became problematic:

• Tight Coupling: Delays in one test could cascade down the chain, impacting all dependent tests.
• Cascading Failures: If one service failed, it could take other tests down with it.
• Resource Contention: Multiple operations competing for shared resources caused conflicts.

Final Solution: A Buffer-Based System

The solution was to decouple dependencies using a buffer. Each application had its own "buffer group" with individual queues for each test. This setup allowed tests to execute independently while filling the buffer with data for subsequent operations. If one test failed, its buffer data remained available for retries or debugging.

We opted to persist buffer data in a database rather than a queue. While some queue systems support persistence, databases provided greater flexibility for accessing and managing data in the long term. The principle, however, remains the same: decouple dependencies with a third component.

Wrapping Up

While this article focused on technical solutions, the underlying principle of decoupling dependencies applies beyond software design. Do your part well asynchronously and bring in a mediator where things get out of hands.

How can you optimize the below code?

LinkedList<Integer> list;
Long sum = 0;

for (int i = 0; i < list.size(); ++i) {
  Long value = list.get(i); 
  sum += value;
}

Identifying Initial Bottlenecks

The first major issue with this code is the use of list.get(i). Since LinkedList doesn’t support O(1) retrieval by index, each get() call iterates up to that index, making the overall complexity O(n²). To fix this, we can use an Iterator to traverse the LinkedList or switch to an ArrayList, which offers O(1) access time due to its contiguous memory structure.

Another inefficiency is the unnecessary auto-boxing when initializing Long sum = 0, which could be simplified. Let’s address these two points in our first optimization:

LinkedList<Integer> list;
Long sum = 0L;

for (Integer value : list) { 
  sum += value;
}

Using an enhanced for-loop with an Iterator or switching to an ArrayList ensures O(n) traversal. Additionally, initializing sum with 0L avoids any auto-boxing.

At this point, we have an optimized, generic version of the code suitable for most situations. However, for the sake of experimentation, let’s explore further optimizations without focusing on edge cases. This exercise will give us insight into different performance trade-offs, touching on some core Java and computer science concepts along the way.

Going Further with Arrays

Instead of a LinkedList, we can use a primitive int array, which offers significant advantages:

1. Cache Locality

Arrays in Java are contiguous blocks of memory, which allows the CPU to load large chunks of the array into the cache after the first access. This enables faster access to subsequent elements due to spatial locality. Here’s a simplified memory layout comparison to illustrate:

Address      Contents      | Address      Contents
ffff 0000    data[0]       | ffff 1000    l_data
ffff 0040    data[1]       |   ....
ffff 0080    data[2]       | ffff 3460    l_data->next
ffff 00c0    data[3]       |   ....
ffff 0100    data[4]       | ffff 8dc0    l_data->next->next
                           | ffff 8e00    l_data->next->next->next
                           |   ....
                           | ffff 8f00    l_data->next->next->next->next

When we access data[0], the CPU loads a chunk of memory starting at ffff 0000 into the cache, enabling quick access to data[1], data[2], and so on. By contrast, a LinkedList has scattered nodes, each pointing to the next. Accessing l_data->next requires loading a different part of memory, resulting in more cache misses and reduced efficiency.

2. Dereferencing Overhead

In a LinkedList, each element resides in a node with a pointer to the next element. This design causes:

• Indirect Access: Accessing elements requires traversing pointers, adding multiple memory lookups and slowing access.
• Pointer Chasing: Nodes are scattered in memory, leading to frequent cache misses as the CPU fetches each pointer location separately, increasing access latency.
• Memory Overhead: Each node’s pointer and wrapper object (e.g., Integer) consume extra memory, which reduces cache efficiency and adds garbage collection overhead.

In contrast, an int[] array stores values contiguously, allowing direct access without pointers, minimizing cache misses, and avoiding the extra memory and garbage collection costs. This results in faster, more efficient sequential access.

Utilizing Parallel Streams

Since we’re using Java, we can leverage parallel streams to speed up summation over large datasets. Here’s a quick overview of how parallel streams operate:

1. Splitting the Data Source: A parallel stream divides the data source (e.g., a collection or array) into chunks. Each chunk is assigned to a separate thread for concurrent processing, leveraging multiple CPU cores.
2. Work-Stealing: Java’s ForkJoinPool powers parallel streams and supports work-stealing. If one thread finishes early, it can take over work from another thread that’s still processing.

Parallel streams work best with large data sources, as the overhead of splitting and managing multiple threads is only worth it when there’s significant computation. In this example, we’ll assume a large dataset and implement parallel streams:

Optimizing Further: Choosing int over long

Finally, to squeeze out the last bits of performance, we can replace long with int, which has some subtle advantages:

• Memory Efficiency: int uses 4 bytes, whereas long uses 8. For large datasets, this reduces memory footprint.
• Cache Efficiency: Smaller data types like int occupy less space in the cache, which may reduce cache misses when handling large arrays.
• Avoiding Type Promotion: In Java, mixing int and long in expressions promotes int values to long, introducing minor overhead. By keeping everything as int, we skip this conversion.

With all these optimizations, here’s our final optimized code:

int[] array = { /* your integers */ }; 

int sum = java.util.Arrays.stream(array).parallel().sum();

Although the result itself is not of much use, the journey was worth it. We ventured through several fundamental concepts trying to optimize it to the extreme.

I think this is as far as you can go staying in bounds of the language. Can you go any further?

I’ve come to accept Bollywood as a money-making machine, endlessly recycling anything that becomes a hit. So, when I stumbled upon Mere Dholna 3.0, I was skeptical. While I have no plans to see the film, I decided to give the track a chance—it’s Sonu Nigam, after all.

This version of the song is set in a different context than the original, exploring themes of betrayal and hatred instead of romance. It starts off well, showcasing a classic Sonu Nigam style—though initially, it bears little resemblance to the original. However, as soon as we reach the chorus (which remains the same as in the original), the emotion shifts dramatically, altering the cadence as well. At that point, I could no longer hear Sonu Nigam; it felt more like Kishore Kumar. While Sonu often draws inspiration from legends like Md. Rafi and Kishore Kumar, this interpretation didn’t resonate with me. It made me question Pritam’s choice to feature Sonu Nigam for this version.

Unless…

Around the 2:50 mark, the song switches the raga—which was totally unexpected since I had assumed it would be the same song wrapped in new lyrics. The song transitions to using a minor second, augmented fourth, and minor sixth—the Hungarian minor scale. This darker raga elevates the song’s themes of betrayal and hatred, making it more than just a recycled melody.

This was a beautiful surprise and exactly how a remake should be done. Transitioning from the former, telling a story, and giving people something new (and I don’t mean just a new beat). Art should be anything but lazy.

Any push notification flow is mainly orchestrated using two entities, push providers and push service. The complexity of how you manage these notification subscriptions or how the events are queued or handled could vary. But these core concepts remain the same.

A push notification system involves:

• Service Worker: The worker (just a JavaScript file) which runs in the background even when the application is closed, to receive the notifications.
• Client: The application or browser/OS receiving the notification (usage is contextual at least in this article).
• Push service: The service provided by the browser/mobile OS to register clients, receive and authenticate notifications and forward them to the designated client.
• Push provider: The service responsible for receiving a call from your application and sending notification to the push service.
• Application Server: Your application’s backend.

Registering with Push Service

When an application which intends to send notifications opens up for the first time, it requests permission to send notifications. This does a bunch of things:

• Grants the application, permissions on browser and OS level to send the notification
• The application registers a service worker with the browser which would run in the background even when application is closed, listening for any “push”.
• The application also “subscribes” to the push service using PushManager API provided by the browser or mobile OS.

(All these have to be handled by the application, of course).

Now app permissions and background workers are topics of their own. For push notifications, we’ll mainly be focusing on the Push Service registration — the last step, which generates a subscription object. This contains an endpoint along with some authentication keys.

{
  endpoint: "https://fcm.googleapis.com/fcm/send/dFDkl2U:APA91bGJ14dMIPffpA118U9P9DZ_zFDF3Ag_Ce8XdGQ78FB8OXX5cmBwr",
  expirationTime: null,
  keys: {  
    p256dh: "BIa2ZOsi4-hZ2A1VH-gSwTiEQVcR8CxbBeUG0t6....",
    auth: "Reh74y36Laj9873hCJWyUA"
  }
}

This subscription object is unique to each subscription and needs to be persisted to the application server along with the client/user information to send the notification to this particular client.

Notice the subscription object mentioned above, provides a Firebase Cloud Messaging (FCM) endpoint. This is because this endpoint was requested using Chrome. The push service being used depends on the client(browser/mobile OS). If it was Edge, the endpoint would look something like “https://wns2-pn1p.notify.windows.com/w/?token=BQYAAADjsm1etl…”.

Sending Notification via Push Provider

Push provider is part of the backend which is responsible to actually send the notifications. It could be a managed service or a custom one. Most cloud platforms offer a push provider service. But if you want more control, or don’t use a cloud provider — you will need to build a custom notification service.

To send the notification, when any notification-worthy event happens, you need to use the subscription object persisted in the previous section.

Libraries like web-push make sending the notifications easier.

webpush
.sendNotification(subscription, payload)
.then((response) => {
  console.log("Notification sent successfully:", response);
  res.status(201).json({ message: "Notification sent" });
  })
.catch((error) => {    
  console.error("Error sending notification:", error);  
  res.status(500).json({ error: "Failed to send notification", cause: error.body });
});

Internally, it uses the endpoint from the subscription object to send the request with ‘payload’ as the body.

This request is sent to the push service, which in turn notifies the client. If the client is offline at that moment, the push service stores and queues the notification for some duration (maybe few weeks), and notifies the client once online. The push event is then caught by the service worker — which can handle it or show it as a notification to the user.

There’s one missing piece in what we have talked about up until now — is this secure? Letting anyone subscribe and push to your machine can have dangerous consequences — someone not authorized to send notifications can send you the notification if the person gets hold of the subscription object. That’s where VAPID comes into picture.

VAPID Keys

VAPID (Voluntary Application Server Identification) is used by the push provider to identify and authenticate your application server. You can say it’s your application’s identifier.

From abstract of VAPID specification:

An application server can voluntarily identify itself to a push service using the described technique. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. This can used to reduce the secrecy for push subscription URLs by being able to restrict subscriptions to a specific application server. An application server is further able to include additional information that the operator of a push service can use to contact the operator of the application server.

If you’re using a cloud push provider, it should offer you some way to get the VAPID keys associated with your push provider instance. If you are implementing a custom push provider, here’s how to generate VAPID keys:

const webpush = require('web-push');

const vapidKeys = webpush.generateVapidKeys();
console.log('VAPID Public Key:', vapidKeys.publicKey);
console.log('VAPID Private Key:', vapidKeys.privateKey);

Run this for once and save them (in an environment variable maybe). You can also use some VAPID key generator service.

These VAPID keys are used at two junctions of the above notification flow:

• When registering a client with the push provider: The request for subscription is made with the VAPID public key. This lets the push provider know, that the client requesting the subscription is associated with your app — and it stores this information.

navigator.serviceWorker.ready.then(function(serviceWorkerRegistration) {
  serviceWorkerRegistration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: urlBase64ToUint8Array('<Your Public VAPID Key>')
  })
  .then(function(subscription) {
    console.log('Received PushSubscription: ', JSON.stringify(subscription));
    // Send the subscription to your server to save it in your database
  });
});

• When sending the push notifications: The push provider signs the notification being sent to push provider with the VAPID private key. Upon receiving this request, the push provider uses the VAPID public key it already has to verify that the request is actually coming from your application using asymmetric cryptography. It also verifies that your application is authorized to send notification to the specified client.

To summarize:

• Application/push provider generates VAPID keys for itself.
• Application requests permission from user to send notifications.
• If user accepts:
  Application registers a service worker with the browser.
  Application requests subscription via PushManager from the Push service of the underlying browser/OS along with the VAPID public key.
• Push service stores the VAPID public key corresponding to the client and application information and grants a subscription object with an endpoint to send notifications and some auth keys.
• Subscription is persisted on the application’s backend along with the user and client information.
• When notification needs to be sent, application notifies a push provider.
• The push provider sends request to the “subscription” endpoint persisted on application side. This request is signed with the VAPID private key.
• Push service verifies using the VAPID public key it stored earlier that the request is legit and the application is authorized to send notification to the said client.
• Push service triggers a “push” event on the service worker.
• Service worker handles or displays the notification.

In the beninging, there were no modules.

Then, BANG! ✨Common JS ✨

Then, BANG! ✨ES Modules ✨

It has been constant bangs since.

JavaScript was not intended to be used on such a scale as it is today. For this reason, it had minimal features. One feature which was missing from the language was modules. As the usage and code base of the language grew, fueled by node JS, libraries like Common JS popped up providing this option. The ECMA guys, who release newer JavaScript versions, thought this was a cool idea too, and decided to support it natively starting JavaScript version ES6. This led to a whole bunch of mess and clashes which hasn’t stopped since then.

Here’s why —

Differences and Incompatibility

The common JS library uses the require and module.exports syntax for importing and exporting modules, while the ES module system uses import and export syntax.

Common JS importing mechanism is synchronous, while ES modules are imported asynchronously. Which is one reason ECMA didn’t use the already existing require syntax.

The problem, however, arose with the incompatibility of the two. While you can import Common JS modules in an ES project, it doesn’t work the other way round. So, there is an interoperability problem at its core, which cascaded to cause conflicts.

ES did decide to keep itself backwards compatible to allow for gradual adoption of its module system. Keeping ES as default would mean rewriting or transpiling all that code. Keeping CommonJS as default maintains compatibility with existing projects.

What went wrong is —

• CommonJS not allowing to import ES modules.
• Limited browser support for Common JS: Most modern browsers natively support ES Modules, but they have limited to no support for CommonJS module. So if your ES code is going to be used in a browser and it imports a CommonJS module, it will break.

The incompatibility goes both ways.

Co-existence?

What if both Common JS and ES Modules could co-exist. It would be great for everyone, and JavaScript developers could live happily ever after quarrelling over other conflicts in the JS land.

To date, there are only some workarounds to achieve this in node JS and browsers, but there are still gaps because of the incompatibility.

If you’re shipping a package, you have to be careful. Depending on the consumers of your package, you have to ship the versions or even different versions to cater to both kinds of users.

Shipping different versions is one option. But again, if your consumers somehow end up importing both versions of your package, this could cause Dual Package Hazard.

The One True King

ESM is the one module system which works everywhere. All node versions with long term support are now using ESM.

If you’re starting with a project, or even have an existing project, it’s time you adopt ES Modules and make the JavaScript world a little less complex place to code.

WARNING: What you emit is who you really are

Bundlers offer a sort of workaround for this, by converting all your code to a single module system. But the bundler lies.

You might be thinking that you are using ES module system, but it is possible your bundler is transpiling your modules into common JS.

Game Theory

Any scenario where there are two or more “players” with ability to think and which involves some payoffs can be treated as a game.

Game theory studies how these players interact with each other. If you loan a bowl of sugar to your neighbor, do they return the favor or exploit your kindness. If the Khaleesi launches a dragon attack on King’s Landing, will King’s Landing retaliate with a nuclear attack? Game theory explores these scenarios.

It's a great way to understand strategy and decision making in all aspects of life, from personal decisions to decisions at national level.

Prisoner’s Dilemma

To understand it better, we take a classic thought experiment from game theory called Prisoner’s Dilemma.

This game can be formulated or described in many ways, but the basic structure of the game is that there are two prisoners. Let's call them A and B. Both are accused of some crime. Now, both prisoners are taken into separate rooms and questioned.

Neither A, nor B knows how the other one is going to act. They can choose to cooperate or defect. Based on how they choose to act, the prisoners will get Payoffs.

Now the payoff could be reduced sentence for cooperation with the police or defection against the other prisoner. But let’s consider it to be points for simplicity.

Here’s a representation of the game in form of (points for A, points for B) in each scenario:

The dilemma for prisoners is to choose whether to defect or to cooperate.

One-shot

Of course, the best outcome for both players in this case will be if both choose to cooperate.

But what if the other person defects, in that case you will be stuck with zero points while the other person gets all the rewards.

But if you defect, and the other person cooperates, you get all the reward.

Therefore, no matter what, the dominant Strategy seems to be, to always defect.

If your opponent is rational, they will also reach the same conclusion and always defect.

In such cases, both agents are stuck with the suboptimal reward 1-1, where they could both have gotten 3-3 each if they chose to cooperate.

Series

Most real-world problems are not a single prisoner's dilemma. It's a series of such games. If you defect and your opponent cooperates for the first time, your opponent will know you defected last time and that can change their behavior. You have to be long-sighted when deciding your strategy.

In 1980, Robert Axelrod hosted a computer competition to determine this. He pitted multiple computer programs based on different strategies against each other in a series of Prisoner’s Dilemma. Here are some of the participating strategies:

• Friedman: It starts by cooperating, but if its opponent defects even once, it defects for the rest of the game.
• Joss: It starts by cooperating and copies what its opponent did in the last move. It also sneaks in a defection 10% of the time.
• Graaskamp: Same as Joss but it defects on the 50% round.
• Tit-for-tat: Starts by cooperating and copies what its opponent did in the last move. No random or probabilistic defections.

Effectiveness of TFT

To assess the effectiveness of tit-for-tat, let’s compare it with two extreme strategies of ‘always defect’ and ‘always cooperate’ and against itself.

Let the respective payoffs for always-cooperate, always-defect and tit-for-tat be:

Case 1: TFT vs. Always Cooperate

When Tit for Tat plays against a strategy that always cooperates:

• Both players always cooperate after the first round.
• Payoff per round: (3, 3)
• Over n rounds:

Case 2: TFT vs. Always Defect

When Tit for Tat plays against a strategy that always defects:

• Round 1: TFT cooperates, opponent defects. Payoff: (0, 5)
• Subsequent rounds: Both defect. Payoff per round: (1, 1)
• Over n rounds:

Case 3: TFT vs. TFT

When Tit for Tat plays against another Tit for Tat:

• Both players always cooperate after the first round.
• Payoff per round: (3, 3)
• Over n rounds:

Comparing the averages:

Any guesses on which strategy won Axelrod’s competition? Although, it seemed like the craziest thing at the time, the simplest strategy ended up winning, there’s a reason tit-for-tat does so good against all strategies.

Defecting strategies like Always defect, seemed to be good strategy in one-shot to get a payout of 5 over your opponent’s 0. But when both parties always defect, they end up getting lower payout of (1,1), which isn’t good for either of them.

Always cooperate would be great in an ideal world, with both players winning (3,3), but it performs poorly due to the fact that there can be nasty players who will sneak in a defection and even continue to do so if they see cooperation from the other side. Always cooperate is overly nice.

TFT is at the sweet spot, where its nice enough to cooperate first, but it punishes the opponent in the next round if they defect. However, it doesn’t keep defecting, it forgives the opponent as soon as they get back to cooperating and they both get a higher payout of (3,3) instead of (1,1).

Axelrod found that all the best performing strategies shared these qualities:

1. They’re nice: They start with cooperation, setting a precedence for a positive, cooperative relationship.
2. They’re provokable: They mimic the opponent's previous move, directly punishing defection and rewarding cooperation, fostering a stable environment where mutual cooperation can thrive.
3. They’re forgiving: They don't hold grudges and only respond to the last move. A player who defects once and then returns to cooperation will be met with cooperation, preventing a downward spiral of mutual defection.

There is a misconception that TFT can never do better than its opponent.

By design, TFT can only loose or at best have a draw with its opponent.

On the other hand, the "Always deflect" strategy will always draw or win.

While this is true in a one-on-one game series with a single opponent, most of life is not like that. When there are multiple agents involved with different strategies and different noises at play, the results are totally different. When most people think of games, or in general anything in life, they think someone has to lose in order for them to win. But that’s not the case with Prisoner’s Dilemma and certainly not the case in real life.

In such games, winning is not as important as securing the greatest number of points. Since you are not getting your reward from the other player, but from a third-party. And TFT eventually ends up gaining most points even by just drawing most games. With mutual cooperation we can ensure a win-win outcome for everyone. Tit-for-tat does exactly that.

These words were written by the mathematician, Pierre de Fermat, in the margin of a book he was reading, after coming up with a theorem. He died shortly after, and with him, the proof to his theorem, which would remain unsolved for over 350 years!

Pierre de Fermat actually used to work as a judge in 17th Century France and would study Mathematics as a hobby.

One evening, he looked at the famous Pythagoras theorem — x² + y² = z². There are a lot of whole number solutions to this equation.

But what if we change the equation a little. Instead of the squared, what if we changed the exponentials to 3. For example, x³ + y³ = z³.

He couldn’t find any solutions to this. Not only that, but he also believed he had found a proof, that shows that there are no three positive integers a, b, and c that satisfy the equation a^n + b^n = c^n for any integer value of n greater than 2.

And he wrote in the margin of a book he was reading - Diophantus's Arithmetica —

Cuius rei demonstrationem mirabilem sane detexi. Hanc marginis exiguitas non caperet.

Translation: I have discovered a truly marvelous proof of this, which this margin is too narrow to contain.

And then he drops dead.

After his death, his son discovered this book, which was full of such notes. His son published a new version of this book with all his notes. People began looking for these proofs, and in every case where Fermat said he had a proof - there did exist a proof. Except this one secret proof.

It is called Fermat’s Last Theorem because it is the last one which anybody could prove.

But the story has a happy ending.

It starts with a 10-year-old child, Andrew Wiles, who was reading a book one day. The book was The Last Problem by ET Bell. It was all about Fermat’s Last Theorem.

And little Andrew decides he is going to solve that problem. A bright 10-year-old can in fact understand the problem. It's the solution which takes a PhD.

In his late 30s, he comes across Taniyama-Shimura Conjecture (an idea which is not proven), which was proposed in the 50s. Somebody had proven there is a link between this conjecture and the Last theorem. That is, if you could prove the conjecture, it would automatically prove Fermat’s Last Theorem.

Wiles’ childhood passion is reignited. But since, it was such an absurd challenge, Wiles worked on it in complete secrecy for 7 years!

At the end of it, he did find a proof. He became an overnight star in the mathematics world. But someone found a mistake in his proof. Fermat’s Last Theorem was fighting back.

It was a great embarrassment for Wiles.

He worked for another year, with another mathematician, Richard Taylor. Finally, he managed to fix the proof.

Wiles' proof of Fermat's Last Theorem marked a significant milestone in the history of mathematics. It not only solved a centuries-old problem but also demonstrated the power of endless perseverance and the depth of human intellect in unraveling the mysteries of the universe.

Here’s is Andrew Wiles talking about it —

Topological sort for a directed acyclic graph is a way of sorting the graph in an order, where for any edge u -> v, u always comes before v in the final sorting, where u and v are the nodes of the graph.

You can think of the directed acyclic graph as a sequence of tasks or a process, where different nodes are tasks. If a task X has some prerequisites, those prerequisites will point towards X, and if X is a prerequisite for any other tasks, X will point to those tasks.

Depth First Search, but postorder

Depth first search as the name suggest takes a node and starts going to its depth visiting nodes along the way. This is preorder traversal, where you visit or process a node as you are moving along the depth.

In postorder DFS, we go to the extreme depth of a node and visit or process a node once we reach the dead-end or the leaf-nodes.

Its only obvious

The tasks with no prerequisites are actually these leaf nodes, since they won't be pointing to any other node. When we do a postorder DFS, these leaf nodes come first and we trace back our steps from there. While in a topological sort, these leaf nodes come last. And this order is maintained throughout the traversal. It only seems natural that reversing the result of a postorder search will result in a topological sort.

In my team, it was being implemented via background jobs. This GDPR job would filter out data based on certain status fields and delete them.

There are however certain cases where it doesn't make sense to introduce a 'status' just for data retention. For example, we had a database table created just to store some parameters related to another object. Once that object is deleted by the job based on its status, there was no point keeping the parameters. In such cases, database triggers could come in as a sweet alternative.

Database triggers are a little piece of procedural codes that are automatically executed in response to events occurring within a database. The event can be data manipulation event like insert, delete or update, or it could be a system event like login/logout. The trigger code can perform a variety of actions, such as updating other tables, enforcing business rules, or logging information.

Triggers can be created via some database management tool or via SQL commands.

For example, in this specific scenario -

CREATE TRIGGER delete_parameter
AFTER DELETE ON plans
FOR EACH ROW
BEGIN
DELETE customers
WHERE customer_id = plans.customer_id;
END;

Thats it, the entries in the dependent table get deleted as soon as the entries in the main table are deleted.

Imagine rules like this one defining a landscape, where maintainable code lives in the valleys. As you add new behavior, it’s like rain landing on your code. Initially you put it wherever it lands. Then you refactor to allow the forces of good design to push the behavior around until it all ends up in the valleys.

I once had to design classes for a configuration and resource manager, where there are different kinds of resources or configurations all sharing a similar structure and behavior with a little difference in some fields. But mostly the functionality would be same for all these resources.

Considering the pros, cons and ideal use cases for interfaces and abstract classes; and what was more suitable for this scenario, I went with abstract class as the base for these classes, since these were a group of closely related classes with some behavioral differences.

I was almost through with the implementation, when I came across this post from Stack overflow (as we all do at some point in our day). Basically, the answers all advised to not use Abstract classes at all. And the answer from Nigel Thorne almost led me to refactor my code. But the same answer also made me wait and let my code age.

The only two uses of Abstract class

Abstract classes are used in one-of-two or a combination of the following two ways.

Abstract Classes for providing flexible behavior for related classes

If the child classes have a common interface, it means you are using inheritance to change certain behavior. It is usually advisable to prefer Composition over Inheritance.

Thus, you should try strategy pattern for tweaking the behavior.

Abstract Classes as a helper class

If it is some common functionality which you want to share among these classes, it is better to move this functionality to a concrete class instead.

Abstract Class as a Stepping Stone

Going back to my use-case from the beginning of this blog post. Even though I was using Abstract Classes for providing flexible behavior for related classes and also Abstract Classes as a helper class, a little. If I went with implementing a third class as a utility to be consumed in all these classes, I would have more useless code for initializing these objects and calling the methods instead of the logic. Hence, I decided to go with the Abstract class.

As the code and requirements evolved, I made the base class as concrete and more dynamic and removed the child classes. I now only have to use a child class for very specific scenarios. But that might change too.

Sometimes on this journey towards perfection, bad code can lead to good code.

A beautiful excerpt from Nigel Thorne’s answer to How to Unit Test Abstract Classes?

Update 2: Abstract Classes as a stepping stone (2014/06/12)

I had a situation the other day where I used abstract, so I’d like to explore why.

We have a standard format for our configuration files. This particular tool has 3 configuration files all in that format. I wanted a strongly typed class for each setting file so, through dependency injection, a class could ask for the settings it cared about.

I implemented this by having an abstract base class that knows how to parse the settings files formats and derived classes that exposed those same methods but encapsulated the location of the settings file.

I could have written a “SettingsFileParser” that the 3 classes wrapped, and then delegated through to the base class to expose the data access methods. I chose not to do this yet as it would lead to 3 derived classes with more delegation code in them than anything else.

However, as this code evolves and the consumers of each of these settings classes become clearer. Each settings user will ask for some settings and transform them in some way (as settings are text, they may wrap them in objects of convert them to numbers etc.). As this happens, I will start to extract this logic into data manipulation methods and push them back onto the strongly typed settings classes. This will lead to a higher-level interface for each set of settings, that is eventually no longer aware it’s dealing with ‘settings’.

At this point the strongly typed settings classes will no longer need the “getter” methods that expose the underlying ‘settings’ implementation.

At that point I would no longer want their public interface to include the settings accessor methods; so, I will change this class to encapsulate a settings parser class instead of deriving from it.

The Abstract class is therefore: a way for me to avoid delegation code at the moment, and a marker in the code to remind me to change the design later. I may never get to it, so it may live a good while… only the code can tell.

I find this to be true with any rule… like “no static methods” or “no private methods”. They indicate a smell in the code… and that’s good. It keeps you looking for the abstraction that you have missed… and lets you carry on providing value to your customer in the meantime.

I imagine rules like this one defining a landscape, where maintainable code lives in the valleys. As you add new behavior, it’s like rain landing on your code. Initially you put it wherever it lands. Then you refactor to allow the forces of good design to push the behavior around until it all ends up in the valleys.

सपने के शमशान पे बैठा
एक अकेला काँच का पुतला

फिर रात भर बारिश हुई,
सुबह सूरज निकल आया,
अब कोई निशाँ नहीं

रात भर रोया बुग्याल,
सुबह यूँ मुस्कुराया,
अब कोई निशाँ नहीं

है ये बंजर ज़मीन,
यहाँ बारिश नहीं होती
है ये नफ़रतों में लीन,
हमदर्दी की नुमाइश नहीं होती

रहते हैं बस हिंदू-मुस्लिम, दलित-पंडित, काले-गोरे, मर्द-औरत
यहाँ, अब इंसानों की रिहाइश नहीं होती

यहाँ बारिश नहीं होती

अब माँगें तो क्या-क्या माँगें,
ख़ुदा से करने को अब,
कुछ ख़्वाहिश भी नहीं होती

है बात और कुछ
(कोई समझता नहीं,
और समझने की गुंजाइश भी नहीं होती)

बह रही हाथों से रोशनाई,
कई दिनों से,
महीनों से,
कई सालों से

रुकते नहीं,
ये ख़्वाब,
ये ख़याल,
ये सवाल

ना सुझावों से,
ना जवाबों से,
ना अज़ाबों से

'cause I am not going to

No, I don't need you

to judge me for what I did

'cause you can't see the war from my side

the wars fought on the inside

the wars that I've fought alone for years

with the monsters in my head

the nights I've spent, shedding tears

shivering on my bed

I might be evil personified

on your side of the border

But I'm an angel on my side

bringing peace and order

Look inside my kaleidoscope

see the colours that hide

behind its dirty lens

come, let me show you your dark side

a dove with a gun in its nib

flying on the other side of the fence

When you're far

and I don't care

Notice how free I feel

when I talk,

Do you see freedom,

in the way I walk?

But everytime I attack, a child dies

can't see another mother with tears in her eyes

So go away! Don't make it bad for me

lets just part ways

let my people live in peace

I'm going back to my land

out of this warzone

where people sleep

where people don't feel alone

I'll now leave you behind, spread my wings to fly

and let this be my final good bye.