DEV Community: chandra penugonda

🚨 Stop Picking the Wrong Queue: You’re Probably Killing Your System 🚨

chandra penugonda — Mon, 11 May 2026 16:01:59 +0000

You’re architecting a new system. You need asynchronous communication. Someone yells “Kafka!” Someone else says “RabbitMQ is easier.” Another person pipes up with “Just use SQS.”

They look similar on the surface. They are not interchangeable. They are not even in the same category. Picking the wrong one—and worse, misunderstanding the fundamental concepts—won’t just make your life harder. It will introduce cascading failures that take months to debug and fix.

Before you write a single line of code, there are four conceptual pillars you must master. If you get these wrong, your system will take itself down the first time a downstream service has a slight slowdown.

Let’s go.

Pillar 1: The Problem We’re Fixing (Decoupling)

Why are we even using queues? We’re trying to solve the problem of synchronous coupling.

Imagine your Checkout Service has to call your Inventory Service directly via an API.

Checkout calls Inventory directly. Inventory slows down (maybe it’s under high load, maybe the DB is lagging). It doesn’t crash; it just takes 5 seconds to respond instead of 50ms.

Because the connection is synchronous, Checkout’s threads pile up waiting. Then the internal pool exhausts. Then Checkout is out of threads. Now, anything depending on Checkout is also down.

This is Cascading Failure. It spreads like wildfire. The real cause isn’t the slow inventory; it’s the synchronous coupling that forces overload to feed on itself (retries, timeouts, waiting).

Now Watch What Happens With a Queue 🛡️

A queue acts as a buffer between the two services.

When Inventory slows down, messages simply accumulate in the queue. The Checkout service writes its “Order Placed” message and immediately moves on.

This is the whole point of a queue: It decouples the producer from the consumer in three critical dimensions:

Time ⏳: They don’t need to run at the same moment.

Availability ✅: One can be down for maintenance without taking the other down.

Speed ⚡️: The fast one isn’t held hostage by the slow one.

Pillar 2: Work vs. Events (Point-to-Point vs. Pub/Sub)

A team shipped a feature on a Friday. By Monday morning, every single user was getting 50 duplicate welcome emails. 📧🤯

The root cause was one simple conceptual mistake: They put a “Work Job” (Send This Email) onto a “Topic” (a fan-out mechanism). They had 50 worker processes. The topic did its job and fanned out one copy of the message to all 50 workers. One question asked in review would have saved their weekend:

“Should this message be handled ONCE, or should MULTIPLE services REACT to it?”

Handled Once (The Work Queue) 👷‍♂️

This is Point-to-Point. It’s a “Job” or “Work Queue.” Examples include: Resize this image, Charge this credit card, Send this one email. Any worker in the pool can grab it, but only one must process it. The message disappears once handled.

Reacted to by Many (The Event) 📣

This is Pub/Sub (Publisher/Subscriber), often called Topics.

An Event is a statement of fact: An order got placed. The Email Service cares (needs to send a receipt). The Shipping Service cares (needs to label a box). The Analytics Service cares (needs to update dashboards). Three independent, parallel reactions to the same fact. Each gets its own copy of the message.

The tool the team used (perhaps RabbitMQ or Kafka) wasn’t broken. Their semantic understanding of the message intent was wrong. Don’t argue about words (”Kafka Queue” vs. “RabbitMQ Topic”). Ask what actually happens to a message when it arrives.

Pillar 3: Delivery Guarantees (The Exactly Once Myth)

You’ll see three delivery guarantees advertised. One is, quite literally, impossible in general distributed systems.

At Most Once: Fire and forget. We send the message and don’t check. If it drops, it drops. Fine for metrics where one lost data point doesn’t matter.

At Least Once (The Real Default): The producer retries until it gets an acknowledgement (ACK) from the broker. If the ACK gets lost, the message gets resent. You will not lose data, but you will get duplicates. This is what most systems use by default.

Exactly Once: This is where vendors get creative with marketing.

The “Exactly Once” Reality 🛡️⚔️🛡️

Exactly once delivery across an unreliable network is not achievable. It’s tied to a result called the Two Generals Problem. Picture it: A producer sends a message. The broker gets it and sends back an ACK. The ACK vanishes. Now the producer has two choices: Retry (and maybe cause a duplicate) or Give Up (and maybe lose data). The network never tells you which scenario occurred.

When a system advertises “Exactly Once Semantics,” what’s actually happening is At Least Once Delivery PLUS either:

Idempotent Processing: The consumer is smart enough to handle duplicates.

Transactional Writes: The write to the final storage (DB) is part of a distributed transaction.

The distinct concept to keep in your head: Exactly Once Delivery over a network (No), exactly once EFFECT (Yes, through work).

🚨 Actionable Takeaway: Build Idempotent Consumers 🛡️

My advice: Assume “At Least Once” and build Idempotent Consumers. Every message handler must check: “Have I seen this unique Event ID before?” and skip if it has. This single pattern prevents standard nightmare bugs: double charges, duplicate emails, and inventory drifting.

If you do one thing after this post, check your handlers. If they aren’t idempotent, make them idempotent.

Pillar 4: When Things Fail (DLQs and Backpressure)

The Poison Message and the DLQ 🤮
Your consumer receives one malformed message. The code crashes. The message goes back to the queue, is retried immediately, crashes the consumer again... this creates a “retry storm” that consumes all CPU and blocks every message behind it.

The fix is the Dead Letter Queue (DLQ). After X failed attempts, the “poison message” is moved to a separate holding area, allowing the main pipeline to resume.

[Image suggestion: A standard, orderly queue line on one side. Below it, a large, dark graveyard pit with skeletons of messages.]

🚨 Crucial Check: A DLQ Without a Replay Path is a Graveyard 🪦

Most teams set up the DLQ, celebrate, and go home. Messages land in it, they fix the bug, and then... nothing. You must build tooling to replay messages back into the main queue. Without a replay path, your DLQ is just where problems go to be forgotten.

The Pager Goes Off: Memory Exhaustion and Backpressure 💥

It’s 3 a.m. The pager goes off. The broker is out of memory. Why? The producer was writing at 10,000 messages/second, but the consumer was only reading at 2,000/second—and had been for hours. The gap doesn’t close itself.

Backpressure is the umbrella term for how a slow consumer pushes back on a fast producer. You will reach for three techniques:

Bounded Queues (Cap it!): Set a max size. When full, the producer must fail or block. This is loud, fails early, and forces a resolution while you still have time.
Autoscale the Consumers: If the queue depth crosses a threshold, spin up more workers. (Works well for stateless consumers).
Credit-Based Flow Control: The consumer tells the producer: “I am ready for 5 messages.” The producer sends 5 and stops, waiting for the next request. This is the model behind reactive streams (Project Reactor, Akka).

The takeaway: Every queue has a limit. Either you pick it and plan, or the OS picks it for you by killing the process.

Decision Matrix: Kafka, RabbitMQ, or SQS?

These are not three flavors of the same tool. They are three different categories of technology.

RabbitMQ 🐇: The Broker

RabbitMQ’s superpower is Complex Routing 🛣️.

[Image suggestion: A complex transportation hub. An arrow points to an exchange (routing center). A dispatcher is configuring dials, directing messages via exact matches, broadcast patterns, or headers into specific destination queues.]

Messages don’t go to queues directly; they go to an Exchange, and the Exchange decides which queues they belong in based on complex, configurable rules. The broker does all the routing for you. And when a message is acknowledged, it is gone.

Reach for RabbitMQ when: Routing is the interesting part of your problem; you need per-message delivery control; raw throughput isn’t the primary bottleneck.

Kafka 🪵: The Log

Kafka is fundamentally a Distributed, Append-Only Log 📜.

[Image suggestion: An endless reel of old, unrolling film tape (the log). A timeline shows consumers tracking their position (offsets). One new ‘fraud detection’ consumer is seen actively pulling the tape reel backward to re-read ‘last 30 days of data’ without disturbing other live readers.]

In Kafka, consumed messages stay in the log for 7 days, 30 days, or forever. Consumers track their own position (offsets). This means any consumer can rewind history.

Reach for Kafka when: You need stream processing, event sourcing, or “time travel” (replaying history); raw throughput is critical (millions of events/sec). (Kafka now supports queue-style share groups, but the log is still its core reason for being).

SQS ☁️: The Managed Queue

SQS is Zero Ops ☕. It is three API calls (Send, Receive, Delete) running inside AWS. Nothing to tune, nothing to patch.

[Image suggestion: A minimalist, clean conveyor belt stretching into a bright cloud (AWS). A small button is labeled ‘Just Send It.’ A single person sits relaxing with coffee, simply pushing ‘Receive.’]

It comes in two flavors: Standard (at least once, best effort ordering, massive throughput) and FIFO (strict ordering, at least once).

Reach for SQS when: You want a queue, not a new operations commitment; you value fast time-to-market over complex features.

Pick the Simplest Tool

The biggest architectural mistake isn’t picking SQS when you could use Kafka. It’s picking the most massive, operational-heavy tool because you “might” need it in three years.

I have seen systems running full Kafka clusters to handle 40 messages an hour. 40. Every incident on that team took longer because the tool was exponentially more complicated than the problem it was solving.

Pick the simplest tool that meets your real requirements. Use SQS or managed RabbitMQ first. You can migrate to Kafka the day you have a real reason—and on that day, you’ll know.

Hands-on Architecture:

Building an app like Instagram 📸 or Uber 🚗 is a great way to see these tools in action. Since these platforms handle millions of users, they use “polyglot messaging”—using different tools for different jobs.

Let’s look at Uber as an example. When you request a ride, the system has to:

Find a Driver: Send the request to nearby drivers (Work Queue).
Update Analytics: Track demand in that neighborhood (Event/Log).
Notify Billing: Prepare the transaction (Reliable Task).

The Design Challenge

Imagine we are building the “Driver Dispatch” part of the app.🚕

When a rider hits “Request,” we need to alert the closest 5 drivers. If a driver accepts, the request must disappear for the other 4 drivers immediately. We also need to ensure that even if our “Dispatch Service” crashes, we don’t “lose” the rider’s request.

Given what we’ve discussed, how should we handle the Rider Request?

Option A: SQS (Managed Queue). Easy to scale, ensures the request is handled, and handles retries if a driver’s app glitches.
Option B: Kafka (Distributed Log). Good for tracking where every driver has been for the last hour, but might be “overkill” for a simple one-to-one dispatch.
Option C: RabbitMQ (Message Broker). Excellent if we want to use “Geographic Routing” to send messages only to drivers in a specific “NYC-Brooklyn” exchange.

Which tool would you pick to ensure the request is routed correctly based on location and deleted the moment it’s accepted?

--
RabbitMQ 🐇 is the standout for this specific task because of its sophisticated routing capabilities.

While SQS is great for simple queues, Uber’s dispatching needs are more dynamic. Using RabbitMQ, you can leverage Exchanges 📂 to route rider requests to specific queues based on geographic metadata (like longitude/latitude or neighborhood IDs).

Why RabbitMQ fits the Dispatcher:

Selective Routing: You can create a “Topic Exchange” where the routing key is something like geo.us.nyc.brooklyn. Only drivers subscribed to that specific area will see the request.

Direct Interaction: Once a driver accepts the ride, the “Competing Consumer” pattern ensures that the message is acknowledged and removed from the queue so no one else can take it.

Low Latency: For real-time dispatching where every second counts, RabbitMQ’s push-based model is slightly snappier than the polling required by SQS.

The Architecture Final Check 🏗️

In a real system like Uber, we wouldn’t just use RabbitMQ. We’d likely use a combination of all three tools we discussed:

RabbitMQ for the “Hot” path: Finding and notifying the driver right now.

Kafka for the “Audit” path: Recording every location update and request for the data science team to analyze later.

SQS for the “Side” path: Sending the email receipt or a push notification after the ride is over—tasks that aren’t time-critical but must happen eventually.

Design Patterns in JavaScript — Explained with Practical Examples

chandra penugonda — Mon, 16 Feb 2026 02:22:16 +0000

🚀 Design Patterns in JavaScript — Explained with Practical Examples

Design patterns are reusable solutions to common software design problems.

Instead of memorizing definitions, understand this:

A design pattern solves a recurring engineering problem.

In this article, we’ll walk through Creational, Structural, and Behavioral patterns with simple JavaScript examples.

🏗 CREATIONAL PATTERNS

(How objects are created)

1️⃣ Factory Pattern

🧠 Core Idea

Hide object creation logic and delegate it to subclasses.

❓ Problem

You don’t want object creation logic scattered everywhere.

✅ Example

class UPI {
  constructor() {
    console.log('upi class');
  }
}

class Card {
  constructor() {
    console.log('card class');
  }
}

class PaymentFactory {
  createPayment(type) {
    if (type === 'UPI') {
      return new UPI();
    } else if (type === 'Card') {
      return new Card();
    }
  }
}

const paymentFactory = new PaymentFactory();
paymentFactory.createPayment('UPI');

🎯 When to Use

When object creation is complex
When multiple subclasses exist
When you want to hide instantiation logic

2️⃣ Builder Pattern

🧠 Core Idea

Construct complex objects step by step.

❓ Problem

Too many constructor parameters make code unreadable.

✅ Example

class Car {
  constructor() {
    this.car = {};
  }

  setCar(car) {
    this.car = car;
    return this;
  }

  getCar() {
    return this.car;
  }
}

class CarBuilder {
  constructor() {
    this.car = new Car();
  }

  build() {
    return this.car;
  }
}

const carBuilder = new CarBuilder();
const car = carBuilder
  .build()
  .setCar({
    name: 'Car',
    color: 'Red',
    price: 1000000
  })
  .getCar();

🎯 When to Use

When object creation involves many optional fields
When readability matters

3️⃣ Singleton Pattern

🧠 Core Idea

Only one instance of a class should exist.

❓ Problem

You don’t want multiple DB connections or config objects.

✅ Example

class DBConnection {
  static instance;

  constructor() {
    if (DBConnection.instance) return DBConnection.instance;
    DBConnection.instance = this;
  }
}

🎯 When to Use

Logger
Database connection
Configuration manager

4️⃣ Prototype Pattern

🧠 Core Idea

Clone an existing object instead of creating a new one.

❓ Problem

Object creation is expensive.

✅ Example

const existingObject = {
  name: 'Car',
  color: 'Red',
  price: 1000000
};

const newObject = Object.create(existingObject);
console.log(newObject.color);

🎯 When to Use

When object creation is costly
When cloning is cheaper than instantiation

🧱 STRUCTURAL PATTERNS

(How objects are composed)

5️⃣ Facade Pattern

🧠 Core Idea

Hide complex logic behind a simple interface.

❓ Problem

Clients shouldn’t know internal system complexity.

✅ Example

class AuthService {
  check() {}
}

class OrderService {
  process() {}
}

class PaymentProcessor {
  constructor() {
    this.payment = new PaymentFactory();
    this.order = new OrderService();
    this.auth = new AuthService();
  }

  placeOrder() {
    this.auth.check();
    this.order.process();
    this.payment.createPayment('UPI');
  }
}

const paymentProcessor = new PaymentProcessor();
paymentProcessor.placeOrder();

🎯 When to Use

To simplify large subsystems
To reduce coupling

6️⃣ Adapter Pattern

🧠 Core Idea

Convert one interface into another expected by the client.

❓ Problem

Legacy code doesn’t match your new interface.

✅ Example

class OldApi {
  getUser() {
    console.log('adaptor pattern');
  }
}

class NewApi {
  constructor() {
    this.oldApi = new OldApi();
  }

  getUser() {
    return this.oldApi.getUser();
  }
}

const newApi = new NewApi();
newApi.getUser();

🎯 When to Use

Integrating third-party libraries
Migrating legacy systems

7️⃣ Decorator Pattern

🧠 Core Idea

Add functionality without modifying original code.

❓ Problem

You want to extend behavior dynamically.

✅ Example

function logger(fn) {
  return (...args) => {
    console.log('Running...');
    return fn.apply(this, args);
  };
}

function sum(a, b) {
  console.log(a + b);
}

const loggerSum = logger(sum);
loggerSum(1, 2);

🎯 When to Use

Logging
Caching
Authentication wrappers

🧠 BEHAVIORAL PATTERNS

(How objects communicate and behave)

8️⃣ Strategy Pattern

🧠 Core Idea

Encapsulate algorithms and make them interchangeable.

❓ Problem

Too many if-else conditions for similar behaviors.

✅ Example

class Strategy {
  execute() {
    throw new Error('Must implement execute');
  }
}

class ConcreteStrategyA extends Strategy {
  execute() {
    console.log('Executing strategy A');
  }
}

class ConcreteStrategyB extends Strategy {
  execute() {
    console.log('Executing strategy B');
  }
}

class Context {
  constructor(strategy) {
    this.strategy = strategy;
  }

  setStrategy(strategy) {
    this.strategy = strategy;
  }

  executeStrategy() {
    this.strategy.execute();
  }
}

const context = new Context(new ConcreteStrategyA());
context.executeStrategy();
context.setStrategy(new ConcreteStrategyB());
context.executeStrategy();

9️⃣ Observer Pattern

🧠 Core Idea

Notify multiple objects when state changes.

❓ Problem

Many components depend on one object’s state.

✅ Example

class Subject {
  constructor() {
    this.observers = [];
  }

  addObserver(observer) {
    this.observers.push(observer);
  }

  notifyObservers() {
    this.observers.forEach(observer => observer.update());
  }
}

class ConcreteObserver {
  update() {
    console.log('Observer updated');
  }
}

const subject = new Subject();
const observer = new ConcreteObserver();
subject.addObserver(observer);
subject.notifyObservers();

🔟 State Pattern

🧠 Core Idea

Behavior changes when internal state changes.

❓ Problem

Too many conditional state checks.

✅ Example

class State {
  execute() {
    throw new Error('Must implement execute');
  }
}

class ConcreteStateA extends State {
  execute() {
    console.log('Executing state A');
  }
}

class ConcreteStateB extends State {
  execute() {
    console.log('Executing state B');
  }
}

class Context {
  constructor(state) {
    this.state = state;
  }

  setState(state) {
    this.state = state;
  }

  executeState() {
    this.state.execute();
  }
}

const context = new Context(new ConcreteStateA());
context.executeState();
context.setState(new ConcreteStateB());
context.executeState();

1️⃣1️⃣ Command Pattern

🧠 Core Idea

Encapsulate a request as an object.

❓ Problem

You want to queue, log, or undo actions.

✅ Example

class Command {
  execute() {
    throw new Error('Must implement execute');
  }
}

class ConcreteCommandA extends Command {
  execute() {
    console.log('Executing command A');
  }
}

class ConcreteCommandB extends Command {
  execute() {
    console.log('Executing command B');
  }
}

class Context {
  constructor(command) {
    this.command = command;
  }

  setCommand(command) {
    this.command = command;
  }

  executeCommand() {
    this.command.execute();
  }
}

const context = new Context(new ConcreteCommandA());
context.executeCommand();
context.setCommand(new ConcreteCommandB());
context.executeCommand();

🎯 Final Takeaway

Instead of memorizing names, remember problems:

Problem	Pattern
Hide object creation	Factory
Build complex object	Builder
Only one instance	Singleton
Clone object	Prototype
Simplify complex system	Facade
Convert interface	Adapter
Extend functionality	Decorator
Replace if-else logic	Strategy
Notify subscribers	Observer
Behavior changes by state	State
Encapsulate request	Command

🚀 Rebuilding useEffect From Scratch to Truly Understand React

chandra penugonda — Sat, 14 Feb 2026 11:50:38 +0000

Inside React: Rebuilding `useEffect` to Understand Hook Internals

Most developers can explain what useEffect does.

Very few can explain how React makes it work internally.

This article is not about usage.

It’s about rebuilding a minimal hook runtime to understand:

How React tracks hooks across renders
Why hook order is mandatory
How dependency arrays actually work
Why effects run after commit (not during render)
Where React’s real complexity lives

Let’s build a simplified version of useEffect and dissect it.

Step 1 — A Minimal Hook Runtime

Here’s a simplified custom implementation:

const hooks = [];
let currentHookIndex = 0;

function myUseEffect(effect, deps) {
  const hookIndex = currentHookIndex;
  const oldHook = hooks[hookIndex];

  let shouldRun = false;

  if (!deps) {
    shouldRun = true;
  } else if (!oldHook) {
    shouldRun = true;
  } else {
    const prevDeps = oldHook.deps;
    shouldRun =
      deps.length !== prevDeps.length ||
      prevDeps.some((ol, i) => !Object.is(ol, deps[i]));
  }

  if (shouldRun) {
    if (oldHook?.cleanup) oldHook.cleanup();

    const cleanup = effect();

    hooks[hookIndex] = {
      deps,
      cleanup
    };
  } else {
    hooks[hookIndex] = oldHook;
  }

  currentHookIndex++;
}

function resetHookIndex() {
  currentHookIndex = 0;
}

Now we use it inside a React component:

export default function App() {
  const [counter, setCounter] = useState(0);

  resetHookIndex();

  myUseEffect(() => {
    console.log(counter);
    return () => console.log("cleanup");
  }, []);

  return (
    <button onClick={() => setCounter(counter + 1)}>
      {counter}
    </button>
  );
}

Now let’s analyze what this reveals about React internals.

1️⃣ Hooks Are Indexed Slots, Not Named Bindings

The most important line:

const hookIndex = currentHookIndex;

Hooks are not tracked by variable name.
They are tracked by call order.

Internally, React stores hooks as a linked list attached to a Fiber node. Conceptually, though, it behaves like this:

Render 1:
Slot 0 → useState
Slot 1 → useEffect

Render 2:
Slot 0 → useState
Slot 1 → useEffect

If order changes, slot mapping breaks.

This explains the fundamental rule:

Hooks must be called unconditionally and in the same order.

This is not stylistic.
It’s architectural.

2️⃣ Dependency Arrays Are Deterministic Equality Checks

This logic:

deps.length !== prevDeps.length ||
prevDeps.some((old, i) => !Object.is(old, deps[i]))

That’s essentially what React does.

Important observations:

Comparison uses Object.is
Objects are compared by reference
No deep comparison
Length mismatch triggers re-run

So this:

useEffect(() => {}, [{}]);

Always re-runs.

Because each render creates a new object reference.

The “magic” is just shallow reference comparison.

3️⃣ Cleanup Is Just Stored State

Notice:

if (oldHook?.cleanup) oldHook.cleanup();

React stores cleanup functions alongside dependency arrays.

On dependency change:

Run previous cleanup
Execute new effect
Store returned cleanup

On unmount:

React iterates through all effect hooks and runs their cleanup.

There is no mystery.
It’s just stored state and deterministic lifecycle transitions.

4️⃣ The Critical Difference: Render vs Commit

Here’s where our implementation diverges from real React.

In our version:

const cleanup = effect();

Effect runs during render.

In real React:

Render phase (pure, no side effects)
Commit phase (DOM mutations applied)
Passive effects (useEffect) executed

Why does React separate this?

Because React supports:

Interruptible rendering
Concurrent mode
Multiple render passes before commit
Aborted renders

If effects ran during render:

Side effects could fire for aborted renders
Subscriptions could leak
State updates could cascade incorrectly

React instead builds an effect list during render and flushes it after commit.

Conceptually:

render()
collectEffects()
commit()
flushEffects()

This separation is what enables concurrency.

5️⃣ Why Resetting Hook Index Is Required

In our simplified runtime:

resetHookIndex();

We manually reset before each render.

React does this internally when it begins rendering a fiber.

During render:

A pointer walks through hook slots
Each hook call advances the pointer
After render completes, pointer resets

This is how state persists across renders while still maintaining order.

6️⃣ Where React’s Real Complexity Lives

The hook logic itself is simple.

The hard part is:

Fiber tree reconciliation
Cooperative scheduling
Priority lanes
Interruptible rendering
Effect queues
Batching

Hooks are just a deterministic layer on top of Fiber.

The true engine is the scheduler + reconciliation algorithm.

7️⃣ A Subtle Edge Case: State Updates Inside Effects

Consider:

myUseEffect(() => {
  setCounter(c => c + 1);
}, []);

In our implementation:

Effect runs during render
State updates synchronously
Potential infinite loops

In real React:

Effect runs after commit
State update schedules a new render
Batching prevents infinite loops
Strict Mode may double-invoke in dev

This difference shows why phase separation matters.

8️⃣ Why This Exercise Matters for Senior Engineers

Understanding this changes how you think about:

Stale closures
Dependency bugs
Infinite render loops
Memoization
Performance issues
React Strict Mode behavior

It also sharpens your mental model for:

Runtime systems
Deterministic execution
Slot-based state machines
Referential equality
Scheduling systems

This is the difference between:

Framework user
vs
Framework-aware engineer

9️⃣ Extending This Experiment

If you want to go deeper:

Implement myUseState
Add a render loop
Queue effects instead of running immediately
Simulate commit phase
Add batching logic
Model multiple component instances

At that point, you’ll start thinking like React’s runtime.

Final Takeaway

React Hooks are not magic.

They are:

Indexed state slots
Shallow dependency comparisons
Deterministic lifecycle transitions
Executed in strict render order

The complexity of React is not in the API.
It’s in the architecture that enables scheduling, concurrency, and deterministic rendering.

Once you see that, debugging React becomes much easier.

And your engineering intuition levels up permanently.

A 90-Day Plan to Become Job-Ready in Python (2026)

chandra penugonda — Tue, 20 Jan 2026 04:52:49 +0000

Python is one of the most practical skills you can learn right now. But most people get stuck because they either overlearn theory or jump into advanced topics too early.

This 90-day plan is designed for clarity, confidence, and employability. If you follow it with discipline, you will be junior-level job ready by the end.

No fluff. No “someday I’ll build projects.”
You build from Day 1.

Days 1–30: Foundations Without Fear

What to learn (only the essentials)

You don’t need everything. You need the core.

Focus on:

Variables & data types
Conditionals (if / else)
Loops (for, while)
Functions
Lists & dictionaries
File handling
Basic error handling (try / except)

The goal here is simple:

Write small Python scripts without panicking.

If you can read a problem and think, “I know how to start,” you’re winning.

Days 1–30: Build While You Learn

Do not wait until you “finish learning Python.”

Build immediately.

Tiny projects to build

Calculator
Password generator
File renamer
CSV cleaner

These projects:

Teach you how Python is actually used
Force you to debug
Build confidence fast

Tiny projects are not “beginner stuff.”
They are skill accelerators.

Days 31–60: Real-World Python

Now Python stops being syntax and starts being useful.

What to learn

Python standard library
Working with APIs (requests)
Basic SQL (CRUD, joins, simple queries)
Git & GitHub (non-negotiable)

This is where skills connect:

Python + data
Python + web services
Python + version control

If you skip this phase, you stay stuck at “tutorial level.”

Days 31–60: Practical Projects

Build things people actually use.

Project ideas

API data fetcher
Expense tracker
Automation script (files, emails, reports)
CLI tool

Rules

Push everything to GitHub
Write simple README files:
- What it does
- How to run it
- What you learned

Recruiters don’t want perfection.
They want proof of work.

Days 61–90: Job-Ready Skills

This phase separates hobbyists from professionals.

Focus on

Clean folder structure
Readable code
Debugging techniques
Logging (instead of print)
Virtual environments (venv)
Basic Linux commands

Key mindset shift:

Readable > clever

If someone else can understand your code, you’re already ahead of most juniors.

Days 61–90: Portfolio Phase

Now you go deeper, not broader.

Build 2–3 strong projects

Choose from:

Automation tool
Data analysis script
Small backend or API (Flask / FastAPI)

These should feel like:

“Yes, this could actually be used.”

Quality beats quantity here.

What “Job-Ready” Looks Like by Day 90

By the end of this plan, you should have:

6–10 total projects
An active GitHub profile
Ability to explain your code clearly
Confidence with Python basics
Comfort debugging problems on your own

That’s junior-level Python ready.

Final Advice

Consistency matters more than talent.
One hour a day for 90 days beats random weekend grinding.

Python rewards builders.
Start small.
Ship often.
Explain what you build.

That’s how you get hired.

If you stick to this plan, you won’t just “know Python.”
You’ll use Python — and that’s what companies pay for.

AWS Pricing Models Explained: (A Beginner's Guide)

chandra penugonda — Sun, 11 Jan 2026 12:01:24 +0000

AWS Pricing Models Explained: How I Saved 75% on Cloud Costs (A Beginner's Guide)

Day 1 of the 7 Days of AWS Challenge 🚀

📋 Table of Contents

AWS Pricing Models: The Complete Breakdown
Real-World Cost Comparison
Cloud Models: On-Premises vs Cloud vs Hybrid
IaaS vs PaaS vs SaaS: Finally Explained
AWS History: From Bookstore to Cloud Giant
The Free Tier: Your Best Friend
Key Takeaways
What's Next?

AWS Pricing Models: The Complete Breakdown

Most developers default to Pay-as-you-go pricing because it's the default option. Big mistake. You're likely overpaying by 50-75%.

AWS offers four main pricing models, each designed for different use cases:

💳 Pay-as-you-go

Best for: Testing, development, and unpredictable workloads

Pros:

No upfront costs
Complete flexibility
No long-term commitments

Cons:

Most expensive option
Hard to predict costs

Use when: You're learning or testing new services

📦 Reserved Instances

Best for: Steady, production workloads

Pros:

Up to 75% cost savings
Capacity reservation
Predictable budgeting

Cons:

1-3 year commitment
Less flexibility

Use when: You know you'll use the service 24/7 for 1+ years

⚡ Spot Instances

Best for: Fault-tolerant, interruptible workloads

Pros:

Up to 90% discount
Massive cost savings
Perfect for batch processing

Cons:

Can be interrupted by AWS
Not suitable for databases
Requires fault-tolerant architecture

Use when: Running batch jobs, CI/CD, data processing

🎁 Free Tier

Best for: Learning and small projects

AWS offers 12 months of free services including:

750 hours/month of EC2 (t2.micro or t3.micro)
5GB of S3 storage
1M Lambda requests per month
25GB of DynamoDB

Value: Approximately $150-200/month in free services

Real-World Cost Comparison

Let's say you need an EC2 instance running 24/7 for a year. Here's how each pricing model compares:

Pricing Model	Annual Cost	Savings	Best For
Pay-as-you-go	$1,000	-	Testing, learning
Reserved (1-year)	$600	40%	Production apps
Reserved (3-year)	$350	65%	Stable workloads
Spot Instances	$100	90%	Batch processing

Example Scenario:

You're running a web application that needs to be always available.

# Pay-as-you-go approach
$0.08/hour × 24 hours × 365 days = $700/year

# Reserved Instance (1-year)
$0.04/hour × 24 hours × 365 days = $350/year

# You save: $350/year (50% savings)

Pro Tip: Start with the Free Tier for learning, then switch to Reserved Instances once you move to production.

Cloud Models: On-Premises vs Cloud vs Hybrid

When I started, I thought "cloud" meant putting everything on AWS. I was wrong. Here's when to use each model:

🏢 On-Premises Infrastructure

Definition: You own and manage all hardware and software in your own data center.

Use On-Premises when:

You're a bank/government with strict compliance
You have massive data transfer requirements
You need complete control over security
You have specialized hardware needs

Avoid when:

You're a startup
You need to scale quickly
You want to minimize upfront costs

Real-world example: Financial institutions processing millions of transactions daily often keep core systems on-premises for compliance.

☁️ Cloud Computing (AWS, GCP, Azure)

Definition: Rent computing resources from a cloud provider.

Use Cloud when:

You're a startup or growing company
You need to scale quickly
You want to minimize upfront costs
You have a distributed team

Best for: 95% of startups and modern businesses

Why I chose AWS for my learning journey:

200+ services available
Largest market share (32%)
Most documentation and community support
Free tier for learning

🔄 Hybrid Cloud

Definition: A mix of on-premises and cloud resources.

Use Hybrid when:

You're a large enterprise migrating slowly
You have regulatory requirements for some data
You want cloud burst for peak loads

Challenges:

Complex architecture
Requires skilled team
Higher operational overhead

When to Choose What

Company Type	Recommended Model
Startup	Cloud (AWS)
Small business	Cloud (AWS)
Medium enterprise	Cloud (AWS)
Large enterprise	Hybrid or Cloud
Bank/Government	On-Premises or Hybrid

IaaS vs PaaS vs SaaS: Finally Explained

This topic confused me for weeks. Here's the breakdown that finally made it click:

IaaS (Infrastructure as a Service)

You rent: Virtual hardware

You manage: Operating system, runtime, data, applications

AWS manages: Physical hardware, networking

AWS Examples:

EC2 (Virtual servers)
S3 (Storage)
EBS (Block storage)
VPC (Networking)

Think of it as: Renting a computer in the cloud

Best for: Full control, learning infrastructure

Example: You want to set up a web server from scratch.

# Launch EC2 (IaaS)
# Install OS (Ubuntu/Amazon Linux)
# Configure web server (Nginx/Apache)
# Deploy your application
# You control everything!

PaaS (Platform as a Service)

You rent: A platform for running applications

You manage: Data, applications

AWS manages: Runtime, operating system, hardware, networking

AWS Examples:

AWS Lambda (Serverless functions)
Elastic Beanstalk (App deployment)
AWS Fargate (Container orchestration)

Think of it as: Renting a platform to run your code

Best for: Developers who want to focus on code, not infrastructure

Example: You want to deploy an app without managing servers.

// Lambda function (PaaS)
exports.handler = async (event) => {
  // Just write your code!
  return {
    statusCode: 200,
    body: 'Hello from AWS Lambda'
  };
};
// AWS handles everything else

SaaS (Software as a Service)

You rent: Complete software solution

You manage: Nothing (just use the software)

AWS manages: Everything

AWS Examples:

WorkMail (Email service)
WorkDocs (Document sharing)
Amazon Chime (Video conferencing)

Think of it as: Using software in your browser

Best for: End users, businesses wanting turnkey solutions

Comparison Table

Layer	IaaS	PaaS	SaaS
Applications	✅ You manage	✅ You manage	❌ AWS manages
Data	✅ You manage	✅ You manage	❌ AWS manages
Runtime	✅ You manage	❌ AWS manages	❌ AWS manages
OS	✅ You manage	❌ AWS manages	❌ AWS manages
Infrastructure	❌ AWS manages	❌ AWS manages	❌ AWS manages
Example	EC2, S3	Lambda, Beanstalk	WorkMail

Recommended Learning Path

Start with IaaS (EC2) to understand infrastructure
Move to PaaS (Lambda) to increase productivity
Use SaaS when appropriate for your needs

AWS History: From Bookstore to Cloud Giant

Understanding AWS's evolution helps you appreciate why certain services exist:

Key Milestones

2002: AWS launched (just a few services)
2004: Simple Queue Service (SQS) - AWS's first service
2006: EC2 and S3 launched 💡 The game changers
2011: AWS CloudFormation (Infrastructure as Code)
2014: AWS Lambda introduced (Serverless revolution)
2016: 1 million active customers
2020: $45 billion in revenue
2024: 200+ services, $85 billion annual revenue

The Origin Story

AWS didn't start as a product—it was born from necessity.

Amazon had excess infrastructure capacity after the holiday season. Instead of letting it sit idle, they realized they could rent it out to other companies.

The insight that changed everything:

"We built AWS for ourselves, then realized others needed it too."
— Andy Jassy, AWS CEO

Why AWS Dominates

Market Share: 32% (largest cloud provider)
Services: 200+ and counting
Availability: 30 geographic regions, 96 availability zones
Customers: From startups to Netflix, Disney, and the CIA

Lessons for Developers

Build internal tools, then turn them into products
Solve your own problems first
Launch early, iterate often
Customer obsession drives innovation

The Free Tier: Your Best Friend

The AWS Free Tier is the best way to learn without spending money. Here's how to make the most of it:

What's Included (12 Months)

Compute:

750 hours/month of EC2 (t2.micro or t3.micro)
1,000 GB-month of Elastic Load Balancing

Storage:

5 GB of S3 storage
30 GB of EBS storage
1 GB of snapshot storage

Database:

25 GB of DynamoDB
750 hours of db.t2.micro or db.t3.micro

Serverless:

1M Lambda requests per month
400,000 GB-seconds of compute time

Total Value: $150-200/month in free services

⚠️ Critical Warning

I know someone who racked up $500 in ONE DAY by accidentally using non-free tier services.

How to protect yourself:

Set up billing alerts immediately

# Go to AWS Console → Billing → Budgets
# Create a budget with $0 limit
# Set email alerts at 80% and 100%

Monitor your usage regularly

# Check your free tier usage
aws ce get-cost-and-usage \
  --time-start StartOfCurrentMonth \
  --time-end EndOfCurrentMonth \
  --granularity MONTHLY \
  --metrics BlendedCost

Know what's NOT free

Not Free Tier Services (Common Mistakes):

Large instance types (m5.large, c5.xlarge)
NAT Gateways ($0.045/hour + data transfer)
Data transfer out (first 100GB/month free)
Elastic IPs (free when attached, $0.005/hour when idle)
AWS Support (Business & Enterprise plans)

Free Tier Checklist

[ ] Create AWS account with Free Tier
[ ] Set up billing alerts (DO THIS NOW!)
[ ] Enable AWS Budgets with $0 limit
[ ] Launch your first EC2 instance (Free Tier eligible)
[ ] Upload files to S3 (First 5GB free)
[ ] Create a Lambda function (First 1M requests free)

Key Takeaways

After spending Day 1 deep-diving into AWS fundamentals, here are my top takeaways:

✅ Do This

✓ Start with the Free Tier for learning
✓ Use Reserved Instances for steady production workloads (save 40-75%)
✓ Consider Spot Instances for batch processing (save up to 90%)
✓ Set up billing alerts IMMEDIATELY
✓ Learn IaaS first (EC2), then move to PaaS (Lambda)
✓ Choose Cloud over On-Premises unless you have specific compliance needs
✓ Use AWS Budgets to cap your spending at $0 while learning

❌ Avoid This

✗ Defaulting to Pay-as-you-go for production (too expensive)
✗ Using Spot Instances for databases (they will be interrupted)
✗ Leaving EC2 instances running when not in use
✗ Skipping billing alerts (it will cost you)
✗ Ignoring the Free Tier limits
✗ Using On-Premises when Cloud would suffice
✗ Launching services without understanding pricing

💰 Cost-Saving Cheat Sheet

Scenario	Best Choice	Savings
Learning & testing	Free Tier	100%
Steady production workload	Reserved Instances (1-year)	40%
Long-term stable workload	Reserved Instances (3-year)	75%
Batch processing jobs	Spot Instances	90%
Development environment	Pay-as-you-go (small instances)	-

What's Next?

This is Day 1 of my 7-day AWS learning journey. Here's what's coming:

Week Overview

Day 1 ✅: AWS Fundamentals & Pricing Models
Day 2: EC2 Deep Dive (Launch your first server!)
Day 3: S3 & Storage Services
Day 4: VPC & Networking
Day 5: Databases (RDS, DynamoDB)
Day 6: Lambda & Serverless
Day 7: Final Project & Certification Prep

Day 2 Preview

Tomorrow, I'll dive deep into Amazon EC2—the heart of AWS compute. I'll cover:

How to launch your first EC2 instance
Security Groups (don't get hacked!)
Choosing the right instance type
Connecting via SSH
Deploying a web application
Cost optimization strategies

📚 Resources & Links

Official AWS Resources:

My Learning Path:

Challenge: 7 Days of AWS by @trainwithshubham
Hashtag: #AWSwithTWS

🙏 Discussion

Question for you:

What's your biggest AWS cost surprise or mistake?

Drop a comment below—I'd love to hear your experiences (and learn from them)!

Also, let me know:

Which pricing model do you use most?
Did I miss anything important about AWS pricing?
What AWS topic should I cover in an upcoming article?

🏷️ Tags

aws #cloudcomputing #devops #beginners #tutorial #awstutorial #cloud #awspricing #serverless #7daysofaws #tech #programming #webdev #learning #certification

Follow me for daily AWS articles this week!

Use the hashtag #7DaysOfAWS and #AWSwithTWS to share your progress!

This is Day 1 of my 7-day AWS learning journey. Follow along for daily tutorials and insights!

Next: Day 2 - EC2 Deep Dive (Coming soon!)

Dockerizing a Node.js To-Do List and Deploying to AWS ECS

chandra penugonda — Sat, 03 Jan 2026 10:27:12 +0000

Building full-stack projects is a great way to learn modern development tools.

In this post, we’ll take our glassmorphic Todo List application and deploy it to the cloud using Docker, Amazon ECR, and Amazon ECS (Fargate). (code on GitHub) that uses Express . We’ll show how to build the app locally, containerize it with Docker (using a Dockerfile and Docker Compose), and then deploy it to AWS ECS (Elastic Container Service). Along the way, we’ll explain key technical concepts and steps in detail. This tutorial is aimed at developers interested in Node.js, Docker, and AWS container deployments.

The Stack

Our project is built with:

Express: A lightweight web framework for Node.js.
Vanilla JS: Managing state locally in-memory (no external database like Redis required for this simplified version).
CSS3: Modern glassmorphism design.

Prerequisites and Setup

Node.js & npm: Install Node.js (which includes npm) to run the app and manage dependencies.
Git: Clone the GitHub repository:

  git clone https://github.com/chandrakumarreddy/docker_node-todo-list.git
  cd docker_node-todo-list

Docker: Install Docker Desktop to build and run containers.

Once you have Node, run npm install to fetch dependencies. The project’s package.json defines the main packages: it uses Express as a lightweight web framework for Node.js. The code defines routes to add/delete to-do items, and Redis is used to persist them.

To test locally (without Docker), start the app with:

npm start

Then visit http://localhost:3000. The Express server listens on port 3000 by default, rendering the to-do list

Containerizing the App with Docker

Next, we’ll containerize the Node.js app. A Dockerfile describes how to build a Docker image that contains the app and its runtime. For example, a typical Dockerfile might look like:

FROM node:16-alpine        # Base image with Node.js
WORKDIR /app              # Set working directory
COPY package*.json ./     # Copy package.json and package-lock.json
RUN npm install           # Install dependencies
COPY . .                  # Copy app source code
EXPOSE 3000               # Expose port
CMD ["node", "app.js"]    # Default command

This Dockerfile starts from a small Alpine Linux Node image, copies in the app, installs its npm packages, and defines the startup command. Running docker build -t todo-app . will build the image.

After building, verify the image and run a container:

docker build -t todo-app .
docker run -p 3000:3000 todo-app

Now the app is running in a container on port 3000.

Deploying to AWS ECS

With a Docker image ready, we can deploy to AWS ECS. ECS (Elastic Container Service) is Amazon’s way to run Docker containers at scale.

Good catch 👍 — you’re right. For a Dev.to-quality, beginner-friendly post, ECR repo creation must be explicit. Below is a drop-in replacement section you can paste into your .md file under Deploying to AWS ECS.

Push Docker Image to AWS ECR (Step-by-Step)

Before ECS can run your container, we must store the Docker image in Amazon ECR (Elastic Container Registry). ECR is AWS’s managed Docker image registry.

1. Create an ECR Repository

You can create the repository either via AWS Console or AWS CLI.

Option A: Using AWS Console (Beginner Friendly)

Go to AWS Console → ECR
Click Create repository
Choose:

Visibility: Private
Repository name: todo-app
1. Click Create repository
2. Copy the Repository URI, it will look like:

   123456789012.dkr.ecr.us-east-1.amazonaws.com/todo-app

Option B: Using AWS CLI (Recommended for Devs)

Make sure AWS CLI is configured:

aws configure

Create the ECR repository:

aws ecr create-repository \
  --repository-name todo-app \
  --region us-east-1

Output will include:

"repositoryUri": "123456789012.dkr.ecr.us-east-1.amazonaws.com/todo-app"

2. Authenticate Docker with ECR

Docker must authenticate before pushing images.

aws ecr get-login-password --region us-east-1 \
| docker login \
--username AWS \
--password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

If successful, you’ll see:

Login Succeeded

3. Build the Docker Image

From your project root:

docker build -t todo-app .

Verify:

docker images

4. Tag the Image for ECR

docker tag todo-app:latest \
123456789012.dkr.ecr.us-east-1.amazonaws.com/todo-app:latest

5. Push Image to ECR

docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/todo-app:latest

Once complete, your image will appear in the ECR console.

Create an ECS Cluster
Task Definition: Example JSON:

   {
     "containerDefinitions": [{
       "name": "todo-app",
       "image": "<aws_account_id>.dkr.ecr.<region>.amazonaws.com/todo-app:latest",
       "portMappings": [{"containerPort": 3000}],
       "environment": [{"name":"NODE_ENV","value":"production"}]
     }],
     "requiresCompatibilities": ["FARGATE"],
     "cpu": "256",
     "memory": "512"
   }

Create a Service: Create a new service in your cluster using the above task definition.

How It Works

The Node.js app uses Express to handle web requests and EJS to render HTML pages. When you visit /, it reads to-do items from Redis and displays them in a Bootstrap-styled page.

In Docker, the Dockerfile specifies the runtime environment. When running a container, Docker Compose sets up networking so that the Redis container and the app container communicate seamlessly.

On AWS ECS, the Fargate service pulls the Docker image and runs it in the cloud. The ECS task definition acts like our Docker Compose profile.

Conclusion

This tutorial covered building a Node.js to-do app, containerizing it with Docker, and deploying on AWS ECS Fargate.

Resources

Amazon ECS clusters - Amazon Elastic Container Service
Express/Node introduction - Learn web development | MDN
Containerize | Docker Docs - Containerize a Node.js application

Background vs. Foreground Containers

chandra penugonda — Sun, 07 Dec 2025 15:57:15 +0000

Background vs. Foreground Containers

Foreground: Attaches to your terminal (e.g., -it); stops on exit.

Background (detached): Runs silently; use -d flag.

Run clock demo in background:

docker run -d jpetazzo/clock

-d: Detached mode—container runs without tying to terminal.
Starts jpetazzo/clock image (displays time); ID returned for reference.
Frees terminal for other commands.

Monitoring Containers

Check processes:

ps

Lists host processes; Docker containers appear as child processes of dockerd.

List running containers:

docker ps

Shows active containers: ID, image, status, ports.
Filters to running only; use for quick status.

View last container:

docker ps -l

-l: Latest—shows most recent container (running or stopped).

Quiet IDs:

docker ps -q

-q: Quiet—outputs only container IDs.
Pipe to other commands (e.g., docker ps -q | xargs docker stop).

All containers:

docker ps -a

-a: All—includes stopped/exited ones.
Useful for cleanup or history.

Last ID only:

docker ps -ql

Combines -q and -l: Single ID of latest container.

Logs and Introspection

View logs:

docker logs container-ID

Fetches stdout/stderr output since start.
Replace container-ID with ID from docker ps; no real-time.

Follow logs:

docker logs container-ID -f

-f: Follow—tails logs in real-time like tail -f.
Monitors ongoing output; Ctrl+C to stop.

Stopping Containers

Graceful stop:

docker stop containerId

Sends SIGTERM; allows cleanup (e.g., save state).
Waits up to 10s default; container stops cleanly.

Immediate kill:

docker kill containerId

Sends SIGKILL; forceful shutdown—no cleanup.
Use for hung processes; risks data loss.

Resource Limits

Limit memory:

docker run -it --memory 100M python

--memory 100M: Caps container RAM at 100MB.
Prevents OOM kills; enforces isolation (e.g., Python script).
Other limits: --cpus 0.5 for CPU shares.

Pulling and Running Images

Pull image:

docker pull busybox

Downloads image from registry (Docker Hub default).
Prepares for offline use; checks for updates if tagged latest.

Run multiple versions:

Use tags (e.g., redis:7 vs. redis:6).

docker run -d redis:7
docker run -d redis:6

Tags specify versions; run side-by-side without conflict.
Containers isolated—ports/names differentiate.

Ports: Container vs. Host

Containers expose internal ports; map to host for access.

Map ports:

docker run -p 6000:6379 redis

-p 6000:6379: Binds host port 6000 to container's 6379 (Redis default).
Access via localhost:6000; host:container direction.
TCP default; UDP via -p 6000:6379/udp.

Custom name:

docker run -d -p 6000:6379 --name redis-old redis

--name redis-old: Assigns human-readable name.
Easier reference than IDs; prevents auto-naming.
Unique per host; use docker rm to reuse.

Executing in Containers

Shell into running container:

docker exec -it containerID /bin/bash

exec: Runs command in live container.
-it: Interactive terminal; /bin/bash starts shell.
Modifies running state (e.g., install tools); exit returns to host.

Dive Deeper: Ubuntu Container with figlet

Launch:

docker run -it ubuntu

Pulls Ubuntu image.
-it: Interactive root shell (bare-bones system).

Install:

apt-get update
apt-get install figlet

update: Refreshes repos.
install: Adds figlet (ASCII art); root skips sudo.

Test:

figlet hello

Prints "HELLO" art; install if missing—shows isolation.

Key Takeaways

Containers: foreground for dev, background for services. Monitor with ps/logs, limit resources, map ports. Pull/tag for versions; name/exec for control. Experiment safely—docker rm cleans.

Day 1: Containers mastered—detach and conquer!

Docker Basics: Getting Started with Containers

chandra penugonda — Sat, 06 Dec 2025 16:27:10 +0000

What is Docker?

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications.

Installing Docker sets up Docker Engine (background daemon managing containers like VMs) and CLI (interacts via API; other tools use it too).

Running Your First Container

Echo test:
docker run busybox echo "hello world"

docker run: Starts container from image.
busybox: Minimal Linux image; echo outputs message. Pulls if absent; runs once, exits.

Interactive:

docker run -it busybox

-it: -i (stdin connect) + -t (pseudo-terminal).
Shell access; exit stops/removes.

Packages count:

dpkg -l | wc -l

dpkg -l: Lists Debian packages.
| wc -l: Counts lines (minimal: <100).

Dive Deeper: Ubuntu Container with figlet

Launch:

docker run -it ubuntu

Pulls Ubuntu image.
-it: Interactive root shell (bare-bones system).

Install:

apt-get update
apt-get install figlet

update: Refreshes repos.
install: Adds figlet (ASCII art); root skips sudo.

Test:

figlet hello

Prints "HELLO" art; install if missing—shows isolation.

Key Takeaways

Containers isolate/reproduce envs. Start with docker run. Experiment, exit to clean. Next: Images/volumes.

Topics for Frontend

chandra penugonda — Tue, 27 Feb 2024 06:46:42 +0000

• How web works?
• Protocols (http, https)
• Rest API
• GraphQL
• Rendering of web page (DOM, CSSOM, paint, Render tree, Layout)
• http2, http3, tcp, udp, smtp, ftp
• Contribute in rest API(header, status code,methods)
• Query/Mutation,dataloader, batching
• gRPC
• RealTime Data(Short polling,webscokets)
•*Long polling,Server sent event, webhooks
Input/Output Sanitization
• XSS
• CSRF
• Https
• CORS
• Auth
Security Headers
• SSRF
• SRI
Permissions Policy
Compliance
Dependency Security
• Why performance is important?
• Performance metrics?
• React Optimization
• Performance monitoring
• Build optimization
• Network optimization
• Asset optimization Performance tools.
Rendering Patterns (CSR, SSR, SSG, RSC)
Caching/Database
• Local Storage
Cookie
Normalization
• State Management
• Session Storage
IndexedDB
Http Caching
• Service Worker
• API caching
• Unit Testing
• Test driven development (TDD)
• Component Testing
• E2E testing
• A/B testing
. Basic of Service worker
• Service worker
• Blob
• PWA
• IndexedDB
Accessbility
Keyboard accessbility
screen recorder
color contracts
Logging and Monitoring

Telemetry
Tools
Alerting
Fixing

LLD For Early Engineer
• State management
• Routing
• Solid principle Autocomplete
• TicTacToe
• Todo App Pagination
• Carousal
HLD for Senior Engineer
• Facebook Feeds
• Diagram Tools
• Live Commentary
• Photo Sharing
• Video Streaming
• Google Doc

Unlocking Rust Development in Visual Studio Code: A Comprehensive Guide and Top Extensions

chandra penugonda — Fri, 19 Jan 2024 04:05:12 +0000

Introduction:

Rust, with its emphasis on performance, safety, and concurrency, has gained popularity among developers for systems programming. Visual Studio Code (VSCode), a versatile and lightweight code editor, has become a favorite among developers for its extensibility and support for a wide range of programming languages. In this blog post, we'll explore the seamless integration of Rust in Visual Studio Code, along with some essential extensions that enhance the development experience.

Getting Started with Rust in Visual Studio Code

Installation of Rust:

Start by installing the Rust programming language on your machine. Visit the official Rust website (https://www.rust-lang.org/tools/install) for instructions on installing Rust. This includes the Rust compiler (rustc), package manager (Cargo), and other essential tools.

VSCode Installation:

If you haven't already, download and install Visual Studio Code from https://code.visualstudio.com/.

Rust Extension:

The official Rust extension for Visual Studio Code is a must-have. Search for "Rust" in the Extensions view (Ctrl+Shift+X), and install the one provided by the Rust Programming Language.

This extension provides features like syntax highlighting, autocompletion, and integration with Cargo, making it an indispensable tool for Rust development.

Essential Rust Extensions for Visual Studio Code:

rust-analyzer:

The extension enhances the Rust development experience by providing features such as advanced code analysis, intelligent code completion, and quick error feedback. Make sure to install it to take full advantage of Rust's capabilities within VSCode.

Even Better TOML:

Syntax highlighting for TOML documents with TextMate grammar.

CodeLLDB:

For debugging Rust applications, the "CodeLLDB" extension is invaluable. It integrates the LLDB debugger seamlessly with Visual Studio Code, allowing you to set breakpoints, inspect variables, and step through your Rust code with ease.

Error Lens:

ErrorLens turbo-charges language diagnostic features by making diagnostics stand out more prominently, highlighting the entire line wherever a diagnostic is generated by the language and also prints the message inline.

crates Simplify Dependency Management in Rust & VSCode

Welcome to Crates, the ultimate Rust extension for VSCode! Simplify your dependency management with ease while using Cargo.toml for your project.

Using Promise.all,Implement mapLimit async function

chandra penugonda — Tue, 31 Oct 2023 11:45:26 +0000

Implement a mapLimit function that is similar to the Array.map() which returns a promise that resolves on the list of output by mapping each input through an asynchronous iteratee function or rejects it if any error occurs. It also accepts a limit to decide how many operations can occur at a time.

The asynchronous iteratee function will accept a input and a callback. The callback function will be called when the input is finished processing, the first argument of the callback will be the error flag and the second will be the result.

Solution:

function getNameById(id, callback) {
  // simulating async request
  const randomRequestTime = Math.floor(Math.random() * 100) + 200;

  setTimeout(() => {
    callback(id === 3 ? true : false, "User" + id);
  }, randomRequestTime);
}

function mapLimit(arr, limit, iterator, cb) {
  return new Promise((resolve) => {
    const output = [];
    let startIndex = 0;
    while (startIndex < arr.length) {
      const slicedArr = arr.slice(startIndex, startIndex + limit);
      startIndex += limit;
      output.push(
        Promise.allSettled(
          slicedArr.map((item) => {
            return new Promise((resolve, reject) => {
              iterator(item, (err, result) => {
                if (err) {
                  reject(err);
                } else {
                  resolve(result);
                }
              });
            });
          })
        )
      );
    }
    return resolve(Promise.all(output));
  });
}

let numPromise = mapLimit([1, 2, 3, 4, 5], 3, getNameById, (result) => {
  console.log(result);
});

numPromise
  .then((result) => console.log("success:", result[0], result[1]))
  .catch(() => console.log("no success"));

Credits: https://learnersbucket.com/examples/interview/implement-maplimit-async-function/

Concatenate new array

chandra penugonda — Tue, 22 Aug 2023 04:18:27 +0000

Implement a function that takes an array and additional arrays and/or values as arguments and returns a new array by concatenating them together.

Example

function customConcat(array, ...values) {

}

var array = [1];
console.log(customConcat(array, 2, [3], [[4]]));
// [1, 2, 3, [4]]

Solution

function customConcat(array, ...values) {
  return array.concat(...values)
}

var array = [1];
console.log(customConcat(array, 2, [3], [[4]]));
// [1, 2, 3, [4]]