DEV Community: Felix Twoli

Event-Driven Architecture: Why Your App Should Stop Talking to Itself (And Start Listening)

Felix Twoli — Thu, 01 Jan 2026 22:54:49 +0000

Reading time: 8 minutes

You know what's wild? Most applications today are basically playing telephone. Service A calls Service B, which calls Service C, which calls Service D... and suddenly your innocent "add to cart" button takes 3 seconds to respond because seventeen different services need to have a meeting about it.

There's a better way. It's called Event-Driven Architecture, and once you understand it, you'll see why companies like Netflix, Uber, and Amazon have bet their entire infrastructure on it.

The Aha Moment

Let me paint you a picture. You're building an e-commerce app. When someone places an order, you need to:

Save the order to the database
Send a confirmation email
Update inventory
Notify the warehouse
Create a shipping label
Update analytics
Charge the payment method
Send a notification to the mobile app

The traditional way? Your order service calls each of these services one by one. If the email service is slow, everyone waits. If the analytics service is down, your entire order fails. It's a house of cards.

The event-driven way? Your order service says "Hey everyone, an order was placed!" and goes back to sleep. Every interested service hears about it and handles their part independently. The user gets instant feedback, and everything else happens in the background.

Mind. Blown. 🤯

What Actually Is Event-Driven Architecture?

At its core, EDA is dead simple: services communicate by producing and consuming events instead of calling each other directly.

Think of it like a radio station. The DJ (producer) doesn't call each listener personally. They just broadcast, and whoever's tuned in (consumers) hears it. If someone's radio is off, the show goes on.

Traditional: "Hey Inventory Service, I need you to reduce stock NOW."
Event-Driven: "📢 ORDER_PLACED happened. Anyone who cares, do your thing."

The Three Core Concepts

1. Events (The Messages)

An event is just something that happened. Past tense. Immutable. Done.

{
  "eventType": "OrderPlaced",
  "timestamp": "2024-01-02T10:30:00Z",
  "orderId": "ORD-12345",
  "userId": "user-789",
  "items": [...],
  "total": 99.99
}

Notice it's "OrderPlaced" not "PlaceOrder". That's not a typo. Events describe what happened, not what should happen. This subtle shift changes everything.

2. Producers (The Broadcasters)

Producers emit events when something interesting happens. They don't know or care who's listening. They just publish and move on.

// Order service (producer)
async function createOrder(orderData) {
  const order = await saveToDatabase(orderData);

  // Publish event and forget
  await eventBus.publish('OrderPlaced', {
    orderId: order.id,
    userId: orderData.userId,
    total: order.total
  });

  return order; // User gets instant response
}

3. Consumers (The Listeners)

Consumers subscribe to events they care about. They process events independently, at their own pace.

// Email service (consumer)
eventBus.subscribe('OrderPlaced', async (event) => {
  await sendConfirmationEmail(event.userId, event.orderId);
});

// Inventory service (consumer)
eventBus.subscribe('OrderPlaced', async (event) => {
  await reduceStock(event.items);
});

// Analytics service (consumer)
eventBus.subscribe('OrderPlaced', async (event) => {
  await trackPurchase(event);
});

See the beauty? Each service minds its own business. If the email service is slow, inventory doesn't care. If analytics crashes, orders still process.

Real-World Example: Building a Notification System

Let's build something practical. Imagine you're creating a social media app where users need notifications for various actions.

The Old Way (Request-Response Hell)

// Post service calling everything
async function createPost(postData) {
  const post = await db.posts.create(postData);

  // Oh god, here we go...
  await notificationService.notifyFollowers(post.userId);
  await searchService.indexPost(post);
  await analyticsService.trackPost(post);
  await recommendationService.updateFeed(post);
  await moderationService.checkContent(post);

  // 5 seconds later...
  return post;
}

Users wait forever, and if any service fails, your entire post creation fails. Not fun.

The Event-Driven Way

// Post service stays simple
async function createPost(postData) {
  const post = await db.posts.create(postData);

  // One event to rule them all
  await events.publish('PostCreated', {
    postId: post.id,
    userId: post.userId,
    content: post.content,
    timestamp: new Date()
  });

  return post; // Instant response!
}

// Meanwhile, everyone does their thing independently...

// Notification service
events.subscribe('PostCreated', async (event) => {
  const followers = await getFollowers(event.userId);
  await sendNotifications(followers, event.postId);
});

// Search service
events.subscribe('PostCreated', async (event) => {
  await elasticSearch.index(event);
});

// Analytics service
events.subscribe('PostCreated', async (event) => {
  await trackEngagement(event);
});

The Tools That Make It Happen

You can't do event-driven architecture without the right infrastructure. Here are the MVPs:

Message Brokers

Apache Kafka is the heavyweight champion. It's fast, durable, and can handle millions of events per second. Companies like LinkedIn and Netflix run their entire infrastructure on it.

// Publishing to Kafka
await kafka.producer.send({
  topic: 'orders',
  messages: [{ value: JSON.stringify(orderEvent) }]
});

// Consuming from Kafka
await kafka.consumer.subscribe({ topic: 'orders' });
kafka.consumer.run({
  eachMessage: async ({ message }) => {
    await handleOrder(JSON.parse(message.value));
  }
});

RabbitMQ is more traditional but incredibly reliable. It's perfect for task queues and has great routing features.

AWS SNS/SQS combo is fantastic if you're already on AWS. SNS broadcasts, SQS queues messages. Together they're powerful and require zero maintenance.

Google Pub/Sub is Google's answer. Simple, scalable, and integrates beautifully with other GCP services.

Redis Streams works great for simpler use cases. If you're already using Redis, this is a no-brainer starting point.

Event Streaming Platforms

Apache Pulsar is like Kafka but more flexible. Multi-tenancy built in, geo-replication is easier.

NATS is incredibly lightweight and fast. Perfect for microservices that need to chat quickly.

Patterns That'll Save Your Life

1. Event Sourcing

Instead of storing current state, store every event that led to that state. Your database becomes an append-only log of everything that happened.

// Traditional: Store current balance
{ userId: 123, balance: 1000 }

// Event Sourcing: Store every transaction
[
  { type: 'AccountCreated', userId: 123, initialBalance: 0 },
  { type: 'MoneyDeposited', amount: 1000 },
  { type: 'MoneyWithdrawn', amount: 50 },
  { type: 'MoneyDeposited', amount: 50 }
]
// Balance = sum of events = 1000

Why? You get complete audit trail, time travel (replay to any point), and perfect debugging. Made a mistake? Just replay events with a fix.

2. CQRS (Command Query Responsibility Segregation)

Separate reads from writes. Write to one database optimized for writes, read from another optimized for reads.

// Write side: Process commands, emit events
async function placeOrder(command) {
  const order = createOrder(command);
  await events.publish('OrderPlaced', order);
}

// Read side: Build optimized views from events
events.subscribe('OrderPlaced', async (event) => {
  await readDB.orders.create(event); // Optimized for queries
});

This pattern lets you scale reads and writes independently. Most apps read 10x more than they write, so this is huge.

3. Saga Pattern

For distributed transactions across services, use sagas. Each step publishes events, and compensating transactions handle failures.

// Booking flow
events.publish('BookingRequested');
  ↓
events.subscribe('BookingRequested') → Reserve flight
  ↓
events.publish('FlightReserved');
  ↓
events.subscribe('FlightReserved') → Charge payment
  ↓ (fails!)
events.publish('PaymentFailed');
  ↓
events.subscribe('PaymentFailed') → Cancel flight reservation

No distributed transactions needed. Each step is independent and compensatable.

The Gotchas (Because Nothing's Perfect)

Eventual Consistency

Events don't happen instantly. There's a delay between event publication and processing. Your user places an order, but it takes 100ms for inventory to update.

Solution: Design your UI to handle this. Show "Processing..." states. Set user expectations.

Event Ordering

Events might arrive out of order. User updates their profile twice, but the old update arrives last. Now their profile is wrong.

Solution: Use timestamps or version numbers. Process events idempotently.

async function handleProfileUpdate(event) {
  const current = await db.profiles.get(event.userId);

  // Only update if this event is newer
  if (event.version > current.version) {
    await db.profiles.update(event);
  }
}

Debugging Is Harder

When something breaks, you can't just follow a stack trace. Events bounce around asynchronously.

Solution: Correlation IDs. Tag every event with a unique ID that tracks the entire flow.

const correlationId = uuid();

await events.publish('OrderPlaced', {
  correlationId,
  orderId: order.id
});

// Every subsequent event carries the same ID
await events.publish('PaymentProcessed', {
  correlationId, // Same ID!
  orderId: order.id
});

Now you can grep logs and see the entire journey of a single order.

Duplicate Events

Network issues, retries, and bugs can cause events to be processed twice.

Solution: Make your consumers idempotent. Processing the same event twice should have the same effect as processing it once.

async function handleOrderPlaced(event) {
  // Check if already processed
  const exists = await db.processedEvents.exists(event.eventId);
  if (exists) return; // Skip duplicates

  // Process event
  await processOrder(event);

  // Mark as processed
  await db.processedEvents.create({ eventId: event.eventId });
}

When to Use Event-Driven Architecture

EDA isn't always the answer. Here's when it shines:

✅ Use EDA when:

Multiple services need to react to the same action
You need loose coupling between services
You have async workflows (emails, notifications, reports)
You need audit trails and event history
You're building microservices
You need to scale different parts independently

❌ Avoid EDA when:

You have a simple CRUD app with one database
You need immediate consistency everywhere
Your team isn't ready for the complexity
You're just starting out (seriously, start simple)

Getting Started: Your First Event-Driven Feature

Don't rebuild your entire app. Start small. Pick one feature that's async and annoying.

Step 1: Choose a message broker. If you're new, start with Redis Streams or AWS SQS. They're simple.

Step 2: Identify one event. Maybe "UserRegistered" or "OrderPlaced".

Step 3: Create one producer and one consumer. Just get events flowing.

// Producer
await redis.xadd('events', '*', 
  'type', 'UserRegistered',
  'userId', user.id
);

// Consumer
const events = await redis.xread('BLOCK', 0, 'STREAMS', 'events', '0');
for (const event of events) {
  await handleUserRegistered(event);
}

Step 4: Add more consumers as needed. Each one independent.

Step 5: Add monitoring. Track event lag, processing time, failures.

That's it. You're event-driven now. Congratulations! 🎉

The Real-World Impact

I've seen teams transform their architecture with EDA:

Before: Deployment took 2 hours because everything was coupled. One bug broke everything. Scaling meant scaling everything.

After: Deploy individual services independently. Bugs are isolated. Scale only what needs scaling. New features take days, not weeks.

One team I worked with reduced their API response time from 3 seconds to 200ms by making background tasks event-driven. Users were thrilled.

Common Questions

Q: Isn't this just message queues?
Sort of, but EDA is the pattern. Message queues are the tool. You can do EDA with queues, streams, or even webhooks.

Q: Do I need Kafka for this?
No! Start simple. Redis Streams, RabbitMQ, or cloud services work great. Kafka is for when you're processing millions of events.

Q: What about transactions?
Use sagas for distributed transactions. Each step is a local transaction that emits events.

Q: How do I test this?
Unit test individual handlers. Integration test with a real message broker (use Docker). E2E test the entire flow.

Resources to Level Up

Books:

"Designing Event-Driven Systems" by Ben Stopford
"Enterprise Integration Patterns" by Gregor Hohpe

Online:

Martin Fowler's event-driven articles
AWS's event-driven architecture patterns
Confluent's Kafka tutorials

Tools to Try:

LocalStack (AWS services locally)
Kafka in Docker
RabbitMQ tutorials

Final Thoughts

Event-Driven Architecture isn't just a buzzword. It's a fundamental shift in how we think about building software. Instead of services commanding each other around, they simply announce what happened and let others decide how to react.

It's more resilient, more scalable, and honestly more fun to work with once you get the hang of it.

Start small. Pick one async workflow in your app. Make it event-driven. See how it feels. Then gradually expand. Before you know it, you'll be designing everything event-first.

The future is event-driven. Might as well get comfortable with it now.

What's your experience with event-driven architecture? Have you tried it? What challenges did you face? Drop your thoughts in the comments. Let's learn from each other.

If this helped you understand EDA, share it with your team. And follow me for more deep dives into software architecture and engineering.

Beyond Chatbots: What Exactly Are AI Agents?

Felix Twoli — Sat, 04 Oct 2025 09:43:26 +0000

AI is no longer about simple chatbots or prompt-based assistants. We’re entering the age of AI agents — autonomous systems that can perceive, reason, act, and learn.

🧩 What is an AI Agent?

An AI Agent is software capable of sensing its environment, making decisions, and taking actions to achieve goals — independently.

Unlike traditional scripts, agents can adapt dynamically, using memory, logic, and machine learning.

⚙️ The Core Traits
1. Autonomy – No constant human supervision.
2. Perception – Data from APIs, sensors, or user input.
3. Reasoning – AI models or logic to choose actions.
4. Action – Executes operations to meet goals.
5. Learning – Improves with experience.

🧱 Agent Architecture (High-Level)

[ Sensors ] → [ Reasoning Engine ] → [ Memory ] → [ Actuators ]

🧠 Cursor: AI Agent in Action

Cursor’s /fix and /test features embody the goal-based agent model.
It perceives your project context, reasons about bugs or missing tests, and acts — writing or refactoring code autonomously.

This is where AI becomes a true coding collaborator rather than just an assistant.

🚀 The Big Picture

AI agents are transforming how developers build software — automating the repetitive and freeing us to focus on system design, performance, and creativity.

💬 What’s your favorite AI agent framework or project? Drop it in the comments!

Why Developers Should Stop Hashing Passwords and Start Using KDFs

Felix Twoli — Sat, 04 Oct 2025 09:23:20 +0000

For years, developers have followed the mantra:
“Don’t store passwords in plain text. Hash them.”

This advice was well-meaning, but in 2025 it’s dangerously outdated.
If you’re still relying on SHA-256, SHA-512, or MD5 for password storage, you’re putting your users at risk.

⸻

The Problem with Simple Hashing

General-purpose hashing algorithms (SHA-256, SHA-512, MD5, etc.) were designed to be fast and efficient. That’s perfect for checksums, digital signatures, or data integrity — but disastrous for password storage.

Why?
• Speed favors attackers: GPUs and ASICs can compute billions of SHA-256 hashes per second.
• Parallelism is cheap: attackers can run millions of password guesses in parallel.
• No built-in protections: general hashes don’t enforce salts, iteration counts, or memory-hardness.

This means that if your database is leaked, a simple hash provides almost no resistance against brute-force cracking.

⸻

Enter Key Derivation Functions (KDFs)

A Key Derivation Function (KDF) is specifically designed for secure password storage. Instead of speed, KDFs focus on defense.

Key properties of KDFs:
• 🔑 Unique Salt — ensures the same password produces different hashes, preventing rainbow table attacks.
• 🕒 Work Factor / Iterations — slows down each password guess, making brute-force expensive.
• 💾 Memory Hardness (Argon2, scrypt) — forces attackers to use significant RAM, reducing the effectiveness of GPUs/ASICs.

With KDFs, every password guess is deliberately slow and resource-intensive, raising the cost of cracking attempts.

⸻

Which KDF Should You Use?

According to the OWASP Password Storage Cheat Sheet (2023) and NIST SP 800-63B Digital Identity Guidelines, recommended algorithms include:
• Argon2id – Winner of the Password Hashing Competition, memory-hard, side-channel resistant.
• bcrypt – Battle-tested and still widely used, though not memory-hard.
• scrypt – Memory-hard, but less widely adopted than Argon2.
• PBKDF2 (with HMAC-SHA256) – Acceptable if configured with very high iterations, but considered weaker than Argon2/bcrypt.

Example Starting Parameters (OWASP guidance)
• Argon2id: memory cost = 64 MB, time cost = 2, parallelism = 1
• bcrypt: cost factor = 12–14
• scrypt: N=2^15, r=8, p=1
• PBKDF2-HMAC-SHA256: 200,000+ iterations

Always benchmark for your environment and set parameters so hashing takes ~100–300 ms on your server.

⸻

Implementation Example (Node.js with Argon2id)

`const argon2 = require('argon2');

// Hash a password
const hash = await argon2.hash("UserPassword123", {
type: argon2.argon2id,
timeCost: 2,
memoryCost: 65536, // 64 MB
parallelism: 1,
});

// Verify later
const isValid = await argon2.verify(hash, "UserPassword123");`

The stored string includes algorithm, parameters, salt, and hash — making it future-proof.

⸻

Best Practices
1. Never use raw hashes (SHA-256, SHA-512, MD5, etc.) for passwords.
2. Always use a unique cryptographic salt per password.
3. Store algorithm + parameters with the hash (for migration and upgrades).
4. Benchmark and adjust so hashing is slow enough to deter attacks but fast enough for user logins.
5. Rehash periodically when parameters or algorithms improve.
6. Add layers of defense: HTTPS, account lockouts, 2FA, and possibly a server-side “pepper” stored separately.

⸻

Closing Thought

Password security is not just about avoiding plain-text storage — it’s about resisting modern cracking techniques.
• Hashing with SHA-256 is no longer enough.
• KDFs like Argon2id, bcrypt, or scrypt are purpose-built for defense.
• OWASP and NIST explicitly recommend them.

If you’re still hashing passwords, it’s time to move on.
Your users — and their security — deserve better.

⸻

🔗 References:
• OWASP Password Storage Cheat Sheet
• NIST SP 800-63B Digital Identity Guidelines
• Password Hashing Competition

Why Developers Should Stop Hashing Passwords and Start Using KDFs

Felix Twoli — Wed, 01 Oct 2025 17:50:26 +0000

For years, developers have followed the mantra:
“Don’t store passwords in plain text. Hash them.”

This advice was well-meaning, but in 2025 it’s dangerously outdated.
If you’re still relying on SHA-256, SHA-512, or MD5 for password storage, you’re putting your users at risk.

⸻

The Problem with Simple Hashing

This means that if your database is leaked, a simple hash provides almost no resistance against brute-force cracking.

⸻

Enter Key Derivation Functions (KDFs)

A Key Derivation Function (KDF) is specifically designed for secure password storage. Instead of speed, KDFs focus on defense.

With KDFs, every password guess is deliberately slow and resource-intensive, raising the cost of cracking attempts.

⸻

Which KDF Should You Use?

Always benchmark for your environment and set parameters so hashing takes ~100–300 ms on your server.

⸻

Implementation Example (Node.js with Argon2id)

const argon2 = require('argon2');

// Hash a password
const hash = await argon2.hash("UserPassword123", {
  type: argon2.argon2id,
  timeCost: 2,
  memoryCost: 65536, // 64 MB
  parallelism: 1,
});

// Verify later
const isValid = await argon2.verify(hash, "UserPassword123");

The stored string includes algorithm, parameters, salt, and hash — making it future-proof.

⸻

Closing Thought

If you’re still hashing passwords, it’s time to move on.
Your users — and their security — deserve better.

⸻

🔗 References:
• OWASP Password Storage Cheat Sheet
• NIST SP 800-63B Digital Identity Guidelines
• Password Hashing Competition

Why Developers Should Stop Hashing Passwords and Start Using KDFs

Felix Twoli — Wed, 01 Oct 2025 17:50:26 +0000

For years, developers have followed the mantra:
“Don’t store passwords in plain text. Hash them.”

This advice was well-meaning, but in 2025 it’s dangerously outdated.
If you’re still relying on SHA-256, SHA-512, or MD5 for password storage, you’re putting your users at risk.

⸻

The Problem with Simple Hashing

This means that if your database is leaked, a simple hash provides almost no resistance against brute-force cracking.

⸻

Enter Key Derivation Functions (KDFs)

A Key Derivation Function (KDF) is specifically designed for secure password storage. Instead of speed, KDFs focus on defense.

With KDFs, every password guess is deliberately slow and resource-intensive, raising the cost of cracking attempts.

⸻

Which KDF Should You Use?

Always benchmark for your environment and set parameters so hashing takes ~100–300 ms on your server.

⸻

Implementation Example (Node.js with Argon2id)

const argon2 = require('argon2');

// Hash a password
const hash = await argon2.hash("UserPassword123", {
  type: argon2.argon2id,
  timeCost: 2,
  memoryCost: 65536, // 64 MB
  parallelism: 1,
});

// Verify later
const isValid = await argon2.verify(hash, "UserPassword123");

The stored string includes algorithm, parameters, salt, and hash — making it future-proof.

⸻

Closing Thought

If you’re still hashing passwords, it’s time to move on.
Your users — and their security — deserve better.

⸻

🔗 References:
• OWASP Password Storage Cheat Sheet
• NIST SP 800-63B Digital Identity Guidelines
• Password Hashing Competition

Web Development Made Simple: A Visual Roadmap for Beginners

Felix Twoli — Fri, 15 Aug 2025 21:53:10 +0000

Imagine the last time you used an app or visited a website—maybe you ordered food online, scrolled through social media, or checked your bank account balance.

Have you ever wondered how that software was built?
Every button you clicked, every smooth animation, every piece of information fetched from a server—it was all crafted by web developers working with a specific set of tools and technologies.

The challenge? For beginners, the sheer number of options can feel like an endless maze.

I recently came across this brilliant mind map (below) that cuts through the noise and makes web development simple. It clearly breaks the field into two main pillars—Front End and Back End—and organizes the key languages, frameworks, and tools you’ll encounter.

If you’ve been unsure where to start, this visual guide—paired with step-by-step resources from roadmap.sh—can be the map that leads you from zero to confident web developer.

The Two Pillars of Web Development

At its core, web development is split into:
• Front End – what users see and interact with in their browser.
• Back End – the behind-the-scenes logic, database storage, and server communication that power the site.

Think of Front End as the “shop front” and Back End as the “kitchen and inventory” of a restaurant.

⸻

The Front End (Client-Side)

The front end is built with three core technologies:
1. HTML – the structure of your page.
2. CSS – the visual design and layout.
3. JavaScript – the interactivity and dynamic behavior.

Once you’ve mastered the basics, you can dive deeper:

Frameworks
• React – component-based UI library from Meta.
• Vue – flexible, approachable, beginner-friendly.
• Angular – complete front-end framework from Google.

Libraries
• jQuery – older but still relevant for some projects.
• Tailwind CSS – utility-first CSS for rapid styling.
• Bootstrap – pre-built components and responsive grid system.

📌 Extra Resource: The Frontend Developer Roadmap from roadmap.sh offers an in-depth breakdown of all front-end skills and topics in a logical sequence.

The Back End (Server-Side)

The back end handles user authentication, data processing, and connecting your front end to a database.

Languages
• JavaScript (Node.js) – lets you write server-side code using the same language as your front end.
• Python – clean syntax, strong frameworks like Django and Flask.
• PHP – powers WordPress and many existing web systems.
• Ruby – popularized by Ruby on Rails.
• Java – enterprise-grade stability and scalability.

Databases
• MySQL – popular relational database.
• PostgreSQL – powerful, feature-rich relational database.
• MongoDB – NoSQL database for flexible data models.

APIs
• REST – the most common API architecture.
• GraphQL – query-based alternative for more precise data fetching.

📌 Extra Resource: The Backend Developer Roadmap offers a step-by-step learning path for mastering back-end technologies.

Going Full Stack

A Full Stack Developer is skilled in both front-end and back-end development. They can build a complete application—from designing the interface to managing the database and server logic.

📌 Extra Resource: The Full Stack Developer Roadmap combines both front-end and back-end learning paths, perfect for anyone aiming to become a full-stack professional.

How to Use This Roadmap
1. Start with HTML, CSS, and JavaScript—the universal foundation.
2. Pick one front-end framework (React, Vue, or Angular).
3. Learn one back-end language.
4. Understand database basics (MySQL, PostgreSQL, or MongoDB).
5. Explore how APIs connect everything together.

💡 Pro Tip: Don’t try to learn all tools at once. Focus on mastering one thing before moving on to the next.

Conclusion

When you view web development through a structured roadmap, it stops being a confusing jungle and becomes a clear, navigable path.

Whether you choose to specialize in front end, back end, or go full stack, combining visual overviews like this with structured guides from roadmap.sh can fast-track your journey.

So—where are you right now on this roadmap? Share your stage in the comments.

Promises in JavaScript: A Beginner’s Guide

Felix Twoli — Thu, 06 Apr 2023 11:33:05 +0000

JavaScript is a language that allows you to write asynchronous code, which means that you can perform multiple tasks at the same time without waiting for one to finish before starting another. For example, you can send a request to a server and continue with other operations while waiting for the response.
However, asynchronous code can also be challenging to write and understand, especially when you have to deal with nested callbacks, error handling, and complex logic. That’s where promises come in handy.
A promise is a JavaScript object that represents the eventual outcome of an asynchronous operation. It can either be fulfilled (resolved) with a value or rejected with a reason (error). A promise lets you write cleaner and more readable code by avoiding callback hell and providing a clear way to handle success and failure scenarios.
To create a promise, you use the Promise constructor, which takes a function as an argument. This function receives two parameters: resolve and reject, which are themselves functions that you can call to settle the promise.
For example, the following code creates a promise that resolves after 2 seconds with the message “Hello”:

To use a promise, you can call its then method, which takes two callbacks as arguments: one for success and one for failure. These callbacks are called when the promise is settled, either by resolving or rejecting.
For example, the following code uses the promise p from above and logs its value or error to the console:

You can also chain multiple then calls on a promise, creating a sequence of asynchronous operations. Each then call returns a new promise that is resolved with the return value of its callback. This way, you can pass data along the chain and handle errors at any point.
For example, the following code chains three then calls on a promise that resolves with a number. Each then call increments the number by one and returns it. The final then call logs the result to the console:

If any of the then callbacks throws an error or returns a rejected promise, the subsequent then callbacks are skipped and the error is passed to the next catch callback in the chain. The catch method is similar to then, but it only takes one callback for handling errors.
For example, the following code adds a catch callback to handle any errors that may occur in the previous then callbacks:

Finally, you can use the finally method to execute some code regardless of whether the promise is fulfilled or rejected. This is useful for performing some cleanup or final actions after an asynchronous operation.
For example, the following code adds a finally callback to log “Done” after the promise is settled:

In conclusion, promises are a powerful feature of JavaScript that allow you to write asynchronous code in a more elegant and manageable way. By using promises, you can avoid callback hell, handle errors gracefully, and chain multiple operations together. Promises are also compatible with other modern JavaScript features, such as async/await and generators. If you want to learn more about promises and how to use them effectively, you can check out some of the resources below:

I hope you enjoyed this article and learned something new. Happy coding!

Getting started in programming

Felix Twoli — Tue, 07 Feb 2023 09:12:16 +0000

Getting started in programming can seem overwhelming, but it can be a rewarding and fulfilling career path. Whether you're looking to build websites, develop mobile apps, or automate processes, there are many reasons why you should consider learning to code. In this article, we'll cover the basics of programming and provide some tips to help you get started.

What is programming?

Programming is the process of designing, writing, testing, and maintaining computer software. It involves using a programming language to write instructions that a computer can understand and execute. There are many different programming languages, each designed for different purposes, but the most popular ones include Java, Python, C++, and JavaScript.

Why should you learn programming?

There are many reasons why you should learn programming, including:

Career opportunities: The demand for software developers and IT professionals is high, and it's a growing field with many job opportunities.
Creative outlet: Programming allows you to turn your ideas into reality and create something from scratch.
Problem-solving skills: Programming requires critical thinking and problem-solving skills, which can be applied to other areas of your life.
Financial rewards: Software developers and IT professionals are typically well-paid, and the salaries in the field continue to grow.

How to get started in programming

Choose a programming language: Decide which programming language you want to learn. There are many resources online that can help you choose the right language based on your goals and interests.
Invest in resources: Invest in books, online courses, or attend a coding bootcamp to learn the basics. Make sure to choose a reputable source and set a schedule for your learning.
Practice: The best way to improve your programming skills is to practice, practice, practice. Try to build small projects or work on existing ones to gain practical experience.
Join a community: Join online forums or attend meetups to connect with other programmers and get help when you need it.
Keep learning: Technology is constantly evolving, so it's important to continue learning and stay up-to-date with the latest developments in the field.

Conclusion

Even though learning to program might be difficult, it can also be fascinating and gratifying. You can quickly master programming with the correct tools and a strong commitment to studying. Ask for assistance, get involved in a community, and constantly pushing yourself to grow personally and reach your objectives. Good fortune!

Difference between =, == and === operators

Felix Twoli — Tue, 22 Nov 2022 15:09:09 +0000

The =, ==, and === operators are all used for comparison in programming.

= operator

The = operator is used to assign a value to a variable.

Depending on the value of the operand that is available on the right side, the = JavaScript operator assigns a value to the left operand. A variable should be the first operand.

let x = 10
= has been used to assigned value of 10 to x

== operator

The == operator is used to check if two values are equal.

x == y

=== operator

The === is a strict equality comparison operator in JavaScript, which returns false for the values which are not of a similar type.
The === operator is used to check if two values are equal and of the same type.
When two variables have numerical values, they are regarded as equal if they both have the same value and neither is NaN (Not a Number).
x ==== y Returns true if the operands are equal and of the same type.

Data Analytics for Beginners: A Complete Guide to Getting Started

Felix Twoli — Tue, 11 Oct 2022 08:13:42 +0000

Data analytics is a fast-growing field with the potential to transform businesses of all sizes. According to the American Internet Council, data analytics will become a $170 billion sector by 2020. Since data analytics involves identifying trends in large sets of data, it’s a perfect fit for an era when almost every business stores and analyzes massive amounts of information digitally. Data Analytics refers to the use of statistical techniques and processes to find insights in data and convert them into actionable information. It helps businesses understand their customers better and make informed decisions on how best to serve them.

What is Data Analytics?
Data analytics is a method of extracting meaningful insights from data to help companies make better business decisions. It is a process that can be applied to any type of data, whether structured or unstructured, to generate insights that can inform your business decision-making. Data analytics can be used to gain insight into customer behaviour, marketing effectiveness, sales performance, product demand, supply chain issues, and more. Additionally, data analytics can be applied to both structured data (data that is organized in a way that computers can read and understand it, like numbers in a spreadsheet) and unstructured data (data that is not easily readable by computers, like a transcript of a voicemail or a tweet). Data analytics can be used to draw insights from all of these types of data.

Importance of Data Analytics
Data Analytics is a process used to find insights in large amounts of data and make informed decisions based on the insights discovered. It is an important part of almost every organization because it helps them to understand their customers better and give them a better experience. In order to do that, business needs to have some information about what type of customers they have, how they behave and what they want. Data analytics helps to gather data and process it to get some information so that company can make decisions based on this information. It can be a simple decision like what to offer next to a customer or a big decision like where to open next office.

Types of Data Analysis
Quantitative Analysis - It is the process of working with structured data to draw conclusions that are primarily based on numbers. It is a widely used method of data analytics that can include a wide range of statistical techniques, such as frequency analysis, hypothesis testing, and regression analysis.

Qualitative Analysis - It is an analysis of unstructured data to determine patterns and draw conclusions about human behaviour and attitudes. In marketing, qualitative analysis is often used to understand customer needs and motivations, which can then be applied to quantitative analysis to conclude data.

Steps to follow for effective data analytics

Define the Problem - The first step before you start your data analysis is to define the problem. As we mentioned above, the data analytics software can be applied to different fields, so it’s important to decide what exactly you need. For example, you may have to research how many customers you have each week, how much money they spend, how often they buy a product, etc. - Set up your Data Source - There are two ways to get your data. You can manually enter it into the database or use an automated feed. The feed is more convenient, but it takes some time to set up. The best way to get data is to use a database, like Microsoft Excel or Google Sheets. - Choose the right Data Analytics Software - Every business has different needs, and it’s important to choose the right software to meet them. When you don’t know which software to use, you are most likely to fail, and that’s why we built this guide. - Prepare your Data - Once you have chosen the software, prepare your data for analysis. This means organizing the data and cleaning it up to ensure it is ready for analysis. Organizing data often means sorting it into categories and putting it in order. Cleaning data means removing any erroneous data that is incorrect or incomplete. - Run the Analysis - Now it’s showtime. Start running the analysis to get some useful insights. - Analyze the Results - After you finish running the analysis, review the results and draw your conclusions. - Create a Report - Now that you’ve got the results, you are ready to create a report. A report is a written summary of your data analysis. It is almost always necessary to include charts and graphs in your report. - Present your Data Analysis - Once you’re done with the report, it’s time to present your data analysis to your team members or your clients. You can do it in person, give them a written report or just send them the graphs. - Use the Results to Make Strategic Decisions - Once you’ve presented the data analysis, it’s time to make strategic decisions based on the results and use them to further grow your business.

Bottom line
Data Analytics is a process of identifying patterns and trends in data to make better decisions. It can be applied to both structured and unstructured data, and it can be used to generate insights on a wide range of topics. To be effective, it’s important to define the problem, set up your data source, choose the right data analytics software, prepare your data, run the analysis, analyze the results, create a report, present your data analysis, and use the results to make strategic decisions.

Scopes of variables JavaScript

Felix Twoli — Sat, 13 Nov 2021 09:29:15 +0000

Scope reffers to extent at which Variables/variable is accesible within a program
There are mainly two types of variables scopes:
1.local variables
2.Global varibles
Local Variable:
When you use JavaScript, local variables are variables that are defined within functions. They have local scope, which means that they can only be used within the functions that define them.

In contrast, global variables are variables that are defined outside of functions. These variables have global scope, so they can be used by any function without passing them to the function as parameters.
Global Variable: Since global variables are defined outside there function so variables with the same name can not be used in different functions.
All the scripts and functions on a web page can access it.