Quality Assurance (QA) is a critical aspect of software development, ensuring that the final product meets the desired standards and functions as intended. While QA practices are integral to all development methodologies, the approach to QA can vary significantly depending on whether a project follows the Agile or Waterfall methodology. In this blog post, we’ll compare these two methodologies, focusing on their impact on QA processes, workflows, and outcomes.

What is Waterfall QA?

The Waterfall model is a linear and sequential approach to software development. In this methodology, each phase — from requirements gathering to design, development, testing, and deployment — is completed before moving to the next. QA in the Waterfall model is typically conducted during a dedicated testing phase after development is complete.

Key Characteristics of Waterfall QA:

1. Late Involvement: QA is often involved only after development is finished.
2. Fixed Scope: Testing is based on a predefined set of requirements and test cases.
3. Extensive Testing: Since QA occurs after development, it often involves extensive end-to-end testing.
4. Minimal Flexibility: Changes to requirements or functionality after testing begins can be costly and disruptive.
5. Predictability: The linear nature of the process makes timelines and deliverables more predictable.

Advantages of Waterfall QA:

1. Clear documentation and test plans.
2. Structured processes provide clarity on responsibilities and timelines.
3. Suitable for projects with well-defined requirements and minimal expected changes.

Challenges of Waterfall QA:

1. Delayed feedback loops can prolong the discovery of critical issues.
2. Limited ability to adapt to changes or new requirements.
3. Potential for larger defects due to the lack of continuous testing.

What is Agile QA?

Agile methodology emphasizes flexibility, collaboration, and iterative development. Unlike Waterfall, Agile integrates QA throughout the development lifecycle, ensuring continuous testing and feedback.

Key Characteristics of Agile QA:

1. Early Involvement: QA begins during the initial stages of development, such as planning and requirement gathering.
2. Continuous Testing: QA is performed at every iteration or sprint, often using automated testing tools.
3. Collaborative Approach: QA teams work closely with developers, product owners, and other stakeholders.
4. Flexibility: Agile accommodates changing requirements and evolving priorities.
5. Incremental Delivery: Testing is focused on small, manageable increments of the product.

Advantages of Agile QA:

1. Faster identification and resolution of defects.
2. Improved collaboration between teams.
3. Greater adaptability to changing requirements.
4. Higher product quality due to continuous testing.

Challenges of Agile QA:

1. Requires strong communication and collaboration skills.
2. Frequent testing can increase workload if not automated effectively.
3. Documentation may be less comprehensive than in Waterfall.

How to transition from Waterfall QA to Agile QA efficiently?

1. Resistance to Change: Teams habitual to the structured approach of Waterfall may resist Agile practices. Providing clear communication on the benefits of Agile and offering training and workshops would build confidence in the new methodology.
2. Lack of Agile Expertise: Hiring Agile coaches to guide teams during the transition would help teams struggling to understand Agile principles and practices.
3. Start Small: Initiate Agile QA practices on a smaller project or a single team before scaling to the entire organization.
4. Coordination Issues: Agile requires closer collaboration between teams, which can be challenging. Establish regular communication channels, such as daily stand-ups and cross-team meetings.
5. Automation: Prioritise test automation to handle repetitive manual tasks.
6. Transitional Expectations: Stakeholders may expect immediate results from the transition which might be a bit unrealistic. Manage expectations by highlighting that the transition is a gradual process with incremental improvements.
7. Documentation Needs: Agile’s lightweight documentation approach may be a cultural shift for teams used to detailed Waterfall documentation. Document critical aspects without compromising Agile’s flexibility.

Which Approach is Right for You?

The choice between Agile and Waterfall QA depends on various factors, including the nature of your project, team dynamics, and organizational goals. Waterfall QA might be suitable for projects with clearly defined requirements and rigid timelines. In contrast, Agile QA is better suited for dynamic projects requiring frequent updates and iterative development.

By understanding the strengths and challenges of each methodology, we can make informed decisions that align with our project needs and deliver high-quality software efficiently.

Agile vs. Waterfall QA: A Comparative Guide was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In an age where artificial intelligence (AI) and machine learning (ML) are integral to almost every aspect of our lives, ensuring the effectiveness, fairness, and reliability of ML models is paramount. Observability plays a crucial role in maintaining the performance of these models, allowing us to detect and resolve issues promptly. At Helpshift, we recognized the need for robust ML observability to keep our models running smoothly and efficiently.

This blog post explores our journey in building a custom ML observability solution tailored to our specific needs. We’ll delve into the concept of ML observability, discuss the limitations of existing tools, and share how we implemented our own solution based on the idea of “Wide Events.”

Understanding ML Observability

ML observability is the ability to monitor and understand the performance, behavior, and outputs of machine learning models in real-time. It enables us to proactively identify potential issues and anomalies, facilitating timely interventions and mitigating risks. ML observability encompasses several key components:

• System Monitoring: Tracking the performance of the infrastructure where ML services are deployed, including metrics like CPU and memory usage, network traffic, disk space, and service performance.
• Inference Monitoring: Evaluating and auditing the real-time performance of deployed ML models in production by tracking incoming requests and the accuracy of model predictions.
• Model Monitoring: Observing the long-term accuracy of ML models by monitoring key metrics such as accuracy, precision, recall, and F1-score, and detecting any drift over time.

Why Observability Matters

If you’ve ever played Age of Empires, you know how crucial it is to explore the map to manage resources proactively and strategize effectively. Similarly, ML observability is about exploring properties and patterns not determined in advance. It allows us to be proactive in debugging and improving our systems, ensuring that our ML models remain reliable and efficient.

As my colleague @Utkarsh aptly put it, observability is like having a comprehensive map of your ML environment, enabling you to navigate challenges and seize opportunities before they impact your system.

The Limitations of Existing Observability Tools

The market offers a variety of observability tools, ranging from traditional telemetry solutions to the latest language model (LLM) monitoring systems, as well as system monitoring and logging tools like Kibana. While these tools are powerful and feature-rich, they come with complexities and challenges:

• Complexity and Overhead: Many solutions require significant setup and maintenance, adding complexity to the observability process.
• Cost: High licensing and operational costs can be a burden, especially for small to mid-sized companies.
• Flexibility: Off-the-shelf solutions might not align perfectly with specific needs, leading to either overkill or insufficient coverage.
• Data Silos: Different tools for metrics, logs, and traces can lead to fragmented data, making it difficult to correlate events and gain holistic insights.

Embracing Wide Events: A New Approach to Observability

Inspired by the concept discussed in the article “All You Need is Wide Events, Not ‘Metrics, Logs and Traces’”, we realized that logging wide events provided the granularity and context needed for effective monitoring and debugging.

What Are Wide Events?

Wide events are comprehensive, structured logs that capture a broad set of key-value pairs, encompassing all relevant information about an event or operation in your system. Unlike traditional metrics or logs, wide events are designed to include as much context as possible, making them highly versatile for analysis.

For example, a wide event for an ML prediction might include:

• Timestamp
• Model Version
• Input Features
• Predicted Output
• Actual Output (if available)
• Latency
• User ID
• Request ID
• System Metrics (CPU, Memory usage at the time)

By capturing detailed information in each event, we can perform granular analyses, correlate different aspects of our system, and uncover insights that might be missed with traditional observability approaches.

Advantages of Wide Events

• Granularity: Provides detailed context for each event, enabling deep dives into system behavior.
• Flexibility: Allows for dynamic querying and filtering without the need for predefined metrics.
• Simplification: Eliminates the need to manage separate systems for logs, metrics, and traces.

Why We Built Our Own Observability Solution

Recognizing the limitations of existing tools and the benefits of wide events, we decided to build our own observability solution based on simple logging. This approach provided several key benefits:

• Simplicity and Control: By leveraging a logging-based approach with wide events, we gained complete control over our observability processes, tailoring the system precisely to our needs without the overhead of complex telemetry tools.
• Focused Use Case: Our main objective was to efficiently monitor ML observability events. A focused, logging-based solution allowed us to design the system specifically for our requirements.
• Cost-Effectiveness: By utilizing our existing infrastructure and open-source tools, we maintained low costs while achieving robust observability.
• Unified Data: Storing all observability data as wide events in a single system eliminated data silos, making it easier to correlate events and gain holistic insights.

How We Implemented Our Observability Pipeline

Architecture Overview

Our observability pipeline consists of three main components:

1. Application Services Generating Wide Events: Our ML services generate detailed observability logs as wide events, capturing all relevant data points about each prediction or operation.
2. Logging in a Distributed Event Store and Stream-Processing Platform (Kafka): We use Kafka to handle the high volume of logs generated, efficiently ingesting and distributing ML observability events in real-time.
3. Consuming and Storing in Cloud Storage (Secor and S3): We utilize Secor to consume logs from Kafka, process them as needed, and store them in Amazon S3 for durable, scalable storage.

Data Visualization and Analysis

To derive insights from the stored logs, we use Amazon Athena, which allows us to query and analyze data directly from S3 using standard SQL. This setup eliminates the need for complex processing pipelines and enables us to create dashboards, generate meaningful metrics, and perform deep dives into our observability data.

Implementation Details

• Kafka Integration: Our application services publish wide events to Kafka topics dedicated to ML observability. Kafka’s scalability and fault-tolerance ensure that we can handle large volumes of data without loss.
• Secor Processing: Secor consumes events from Kafka, partitions them appropriately (e.g., by date or event type), and writes them to S3 in a structured format like Parquet or JSON, optimizing for query performance.
• Athena Queries: We define schemas for our wide events in Athena, allowing us to run ad-hoc SQL queries, create views, and integrate with visualization tools like Amazon QuickSight or Grafana.

What We Log: Data and Events

Our logging focuses on capturing detailed ML observability events as wide events. Key types of data and events include:

• Prediction Results: Details of each prediction made by our ML models, including input features, predicted outputs, and confidence scores.
• Performance Metrics: Metrics such as latency, throughput, and error rates at the time of each prediction.
• Anomalies and Exceptions: Any detected anomalies, exceptions, or errors encountered during model execution.
• User Feedback: Feedback from users, such as corrections or satisfaction ratings, which can be correlated with model performance.

Example of a Wide Event

{
  "timestamp": "2023-10-01T12:34:56Z",
  "model_name": "intent_classifier_v2",
  "model_version": "2.3.1",
  "input_text": "How do I reset my password?",
  "predicted_intent": "password_reset",
  "confidence_score": 0.92,
  "actual_intent": null,
  "user_feedback": null,
  "latency_ms": 45,
  "request_id": "abc123xyz",
  "user_id": "user_789",
  "cpu_usage": 55.3,
  "memory_usage": 1024,
  "host": "ml-service-1"
}

By capturing all relevant information in a single event, we enable comprehensive analysis and debugging capabilities.

Benefits of Our Approach

• Scalability: Kafka and S3 ensure the pipeline handles large data volumes without bottlenecks.
• Flexibility: Wide events allow for dynamic querying and analysis without the need for predefined metrics.
• Cost-Effectiveness: Utilizing open-source tools and existing infrastructure keeps costs low.
• Improved Debugging: Detailed logs enable us to quickly identify and resolve issues, maintaining model reliability.
• Enhanced Insights: The ability to slice and dice data in Athena allows us to uncover patterns and insights that inform model improvements.

Overcoming Challenges

Versioning and Schema Evolution

One of the challenges we faced was managing versioning and schema changes in our logs. As our models and logging requirements evolved, we needed a strategy to handle changes without disrupting analysis.

Solution:

• Schema Versioning: We include a schema_version field in each wide event, allowing us to track changes and apply appropriate parsing logic.
• Flexible Schemas: By using formats like JSON and tools that support schema-on-read (like Athena), we can handle missing or additional fields gracefully.

Data Quality and Consistency

Ensuring the quality and consistency of the logged data is crucial for accurate analysis.

Solution:

• Validation: Implement validation checks in our application services to ensure that all required fields are present and correctly formatted.
• Monitoring: Set up alerts for anomalies in the logging pipeline, such as sudden drops in event counts or unexpected field values.

How It Benefits Helpshift

Our custom observability solution has brought significant benefits to Helpshift:

• Derived Metrics: We can derive meaningful metrics from logged events, such as model accuracy over time, latency distributions, and error rates.
• Enhanced Debugging: Detailed, contextual logs enable rapid identification and resolution of issues, minimizing downtime and impact on users.
• Continuous Improvement: Incorporating user feedback into our logs allows us to refine our models continuously, enhancing user satisfaction and engagement.
• Proactive Monitoring: Real-time analysis capabilities enable us to detect anomalies and address them before they escalate into larger problems.

Conclusion

At Helpshift, our journey to building a robust ML observability solution was driven by the need for simplicity, control, and cost-effectiveness. By focusing on logging wide events, we created a scalable and flexible pipeline that meets our needs and helps us maintain the reliability and performance of our ML models.

Our approach demonstrates that with thoughtful design and leveraging existing open-source tools, small to mid-sized companies can implement effective observability solutions tailored to their specific needs.

References

• “All You Need is Wide Events, Not ‘Metrics, Logs and Traces’” by Charity Majors
• “Levels of Complexity in RAG Applications”

Join the Conversation

We’d love to hear about your experiences with ML observability. Have you implemented a similar solution or faced challenges in monitoring your ML models? Share your thoughts and let’s learn together.

From Data to Insight: Helpshift’s Journey with ML Observability was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Quality Assurance in the data-driven systems extends beyond UI validation and backend verification. Such systems rely heavily on data precision and accuracy.

A recent QA focused on validating a productivity analytics framework, ensuring that every event, metric and data flow accurately represented real-world user behaviour. The process was primarily manual, involving live simulations, event validation and detailed metric verification across environment which emphasised logic and data accuracy over automation.

Simulating Real-World Scenarios

Extensive simulations were conducted for multiple user roles as Agent, Supervisor, Admin and Super admin. Each governed by specific dashboard permissions and access rules.

Actions tested included :

• Logging in and logging out from the dashboard
• Marking presence states such as Available, Online, Or Away
• Switching between workzones
• Navigating through dashboards

These test conditions generated diverse event streams used to verify how accurately the system captured and processed state transitions.

Parallel Event Validation Through Kafka

Real-time validation was a key aspect of this QA process. Event streams were observed directly through kafka consoles, enabling verification of generated events and their payloads, data structures, and JSON fields as actions were executed.

Each dashboard or SDK action was simulated while the corresponding kafka stream was monitored in parallel, confirming that events triggered correctly and carried accurate data information. Testing covered sandbox, staging, and production environments, ensuring reliability and consistency across all setups.

Data Verification with Metabase and Calculations

After events were processed by the analytics pipeline, metabase queries were used to validate computed metrics against expected outcomes from simulations.

To cross-check results, timestamps (ex. UTC vs IST) were analysed and durations recalculated according to the defined formulas. This combinations of query-based data verification with calculated data confirmed the accuracy of each metric and its alignment with underlying event data.

Testing Across Workzones

Validation extended to multiple workzones to ensure consistent data aggregation and metric computation globally. The process confirmed that analytics logic produced uniform results regardless of context and configuration.

Edge-Case and Event-Order Testing

The QA process also included detailed validation of edge conditions such as:

• Network interruptions during event capture
• Out-of-order or missing event sequences
• Duplicate triggers or delayed events

Since event order and timing directly affect metric accuracy, verifying event sequence integrity was essential to maintaining trustworthy analytics output.

Understanding and Validating Metric Types

Three core catagories of metrics were validated through this effort :

1. Simple Counter Metrics : Direct counts of user or system actions.
2. Complex Metrics : Aggregated or state-based computations across multiple events or entities.
3. Timer Metrics : Duration based calculations between event pairs, used to measure productivity or performance trends.

Each category demanded tailored validation to confirm that event logic, aggregation and computation aligned with business definitions and customer expectations.

Why Accuracy Matters?

Accurate data builds confidence. Every decision informed by analytics relies on the assumption that metrics reflect reality. When analytics are powered by real-time event tracking and computed metrics, even minor errors in the event capture, time-stamping or sequence logic can lead to misleading conclusions.

Through structured simulations, real-time kafka validation and detailed data verification, this QA effort ensured that the analytics system produced metrics users could trust.

Key Takeaways

• QA for analytics systems requires end-to-end validation from event capture to final metric output.
• Kafka-based event monitoring provides clear visibility into live data accuracy.
• Role-based and multi-environment testing ensures consistency across contexts.
• Timestamp precision and event sequencing are critical for data reliability.
• Thorough QA directly strengthens business trust and decision quality.

Challenges and Limitations in Analytics QA

Validating analytics isn’t always straightforward. Testing event-based systems involves several obstacles that demand patience and precision.

Challenges:

• Data Dependency & Delays : QA must account for delays as events take time to reflect in the system..
• Environment Differences : Behaviour can vary across staging, sandbox, and production environments due to distinct configurations or filters.
• Test Data Management : Managing and maintaining realistic test data across multiple workzones and Time Zones can be tedious and error-prone.
• Manual Validation Load : With manual validations, coverage and consistency rely heavily on detailed documentation and repetition.

Limitations:

• Gaps in simulations : Some metrics depend on large-scale or real-time user behaviour, which can’t always be perfectly simulated in test environments.
• Human Factors : Manual interpretation introduces the risk of human error, especially when analysing large event payloads or long sessions.
• Dynamic Systems : Frequent updates in data models or computation logic can impact consistency, calling for continuous revalidation.

Closing Thoughts

Validating analytics pipelines is part science, part investigation. It demands attention to data logic, event behaviour, timing and the patience to trace results back to their source.

Through complex and time-intensive, such QA ensures that what businesses see on their dashboards truly represents what happens in reality. In the end, that accuracy is what turns analytics from just numbers into trust.

The Hidden Layer of Analytics: How QA Builds Trust in Data was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

In every growing organisation, mentorship quietly powers progress. It’s not just about reviewing work or assigning tasks but it’s about helping people discover their potential, learn faster, and build confidence in their expertise.

Strong mentorship programs help create a culture where learning is continuous, team alignment improves , and quality becomes a shared mindset rather than an individual effort.

🎯 Why Mentorship Is Important?

1. Skill Growth Happens Faster

Learning becomes faster and more meaningful with the right guidance. Mentorship helps bridge gaps that could otherwise take years to overcome whether it’s technical depth, communication, or accountability.

2. Builds Confidence and Accountability

When someone knows there’s support and guidance available, they are more likely to take ownership, ask questions, and explore solutions without fear of failure. Mentorship creates a safe environment for experimentation and growth.

3. Aligns Individual and Team Goals

Most of the times individual OKRs (Objectives and Key Results) often feel abstract until someone helps translate them into personal growth plans. Effective mentorship bridges that gap ensuring skill development aligns with both personal and organizational success metrics.

4. Encourages a Culture of Feedback

Mentorship promotes open communication. Each session becomes an opportunity to exchange constructive feedback and insights. Over time, this fosters a culture of transparency and continuous improvement across the team.

🧭 What Effective Mentorship Looks Like

A good mentorship rhythm involves consistent check-ins, clear goals, and space for reflection.

• Regular discussions/sync-ups on personal OKRs help mentees focus on targeted skill improvement.
• Weekly or biweekly meetings provide structure for reviewing progress and addressing blockers.
• During high-priority feature or project work, flexibility is key. Short async updates or quick syncs can keep the mentorship active without adding pressure.

The intent is to ensure growth remains continuous, even when schedules become demanding.

⚖️ Balancing Mentorship Goals with Organizational Priorities

In mentorship, there are times when a proposed learning topic or framework might not align with organisational priorities. For example, when a new tool poses a potential security risk or when leadership decides the focus area isn’t strategically valuable at that time.

Such situations highlight the importance of adaptability. Effective mentorship is not only about proposing ambitious learning ideas but also helping mentees navigate changes in direction without losing focus and motivation. Finding alternative topics that balance personal development with business direction ensures that learning remains meaningful and sustainable.

When growth goals are aligned with the organisation’s vision, mentorship efforts translate into outcomes that strengthen both the individual and the team.

💡 Lessons from Successful Mentorship Models

• Mentorship is not always about giving answers . It’s about enabling the right questions.
• Progress often comes from small, consistent guidance rather than occasional large sessions.
• Mentorship benefits both sides such as, mentors refine their leadership, empathy, and clarity, while mentees gain direction and confidence.
• Adapting to feedback and changing circumstances keeps the mentorship relevant and effective.

🌱 The Other Side of Mentorship

• Mentorship is never one-sided. Mentors grow too, gaining new perspectives and refining their own leadership approach.
• Every mentorship exchange offers the mentor fresh insights, patience, and renewed curiosity.

🌟 Conclusion

• Mentorship is not an additional task; it’s an investment in people, culture, and collective success.
• Every conversation, no matter how brief, contributes to a stronger, more self-driven team.
• When mentorship becomes part of the work culture, growth becomes inevitable for individuals, for teams, and for the organisation as a whole.

Mentorship promotes open communication. Each session becomes an opportunity to exchange constructive feedback and insights. Over time, this fosters a culture of transparency and continuous improvement across the team.

Why Mentorship Matters? Beyond Tasks and Deadlines was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a data engineer, I used to see metrics as just numbers on a dashboard — until I realized they’re the lens through which customers view and run their operations. In customer support, for example, agent productivity metrics aren’t just figures, they’re actionable insights that drive efficiency, shape staffing decisions, and directly impact customer satisfaction.

These aren’t just charts — they help customers understand the value we provide, how well things are working, and what decisions to make next. Realizing this changed how I think about building analytics.

➡️💡The Question That Shifted Our Perspective

In customer support, how well the team works really matters. It affects how much the company spends, how happy the customers are, and how the team feels about their work.

Support managers often ask:

• Are we staffed correctly for the volume we’re handling?
• Are agents spending their time productively?
• How can we optimize scheduling and performance?

When we began our Agent Workforce Management project, we already had a few standard metrics in place like online time, login time, and available time. These told us when agents were present — but not what they were actually doing.

Customers weren’t asking “Are our agents online?”

They were asking “How productive are our agents?”

And truthfully, we didn’t have a good answer.

There was no visibility into how much time was being spent on real work versus idle time. No way to differentiate between being “available” and being “productive”. This made it hard for teams to identify gaps, support high performers, or spot patterns that needed attention.

This project was all about answering that question in the right way.

🔍📊 Custom Metrics We Built

We designed a set of new metrics that give a clearer picture of how agents spend their time. These metrics give us a deeper understanding of how time is actually being spent, helping us move beyond assumptions and focus on what really drives productivity.

Engagement Metrics

These show how much time agents actively engage with different parts of the dashboard, giving insight into focused work and task-level activity.

• Dashboard Interaction Time — Time spent by the agent actively using the main dashboard, with the browser tab in focus. It helps indicate general engagement during working hours.
• Issues Page Interaction Time — Measures how much time agents spend in the “Issues” section of the dashboard. This shows how long they are reviewing or managing tickets.
• Issues Interaction Time — Covers the time an agent has a specific ticket open and is actively working on it. It’s a direct view of task-level engagement.

Idle/Availability State Metrics

These track time when agent is technically available but not handling any work.

• Unallocated Available Time — Tracks when an agent is marked as ‘Available’ but has no pending tickets to reply to. It highlights unused agent capacity.
• Unallocated Unavailable Time — Represents periods when the agent is not marked as ‘Available’ and also has no active tickets. Often includes breaks or idle time.

Anomaly & Attention Metrics

Even when agents are online or marked as available, it doesn’t always mean they’re engaged or productive. Sometimes they get distracted, stuck, or step away without logging out properly. Anomaly metrics surface these blind spots.

• Untracked Time — Time during which the agent is online, but the dashboard browser tab is not in focus. It may point to distractions or periods of inactivity.

Each of these metrics plays a different role, but together they give a fuller, more accurate view of agent productivity.

🛠️🕵️‍♂️ Behind the Scenes

We knew what we wanted to measure — time spent actively engaging with dashboards, tickets, and actual tasks. But the problem? We had no way to capture the signals behind those actions. We couldn’t tell if their browser tab was in focus, if they opened a ticket, or even if they were looking at the right page.

At first, it seemed easy 🤷‍♀️ just track what agents are doing and for how long. But as we got into the details, we realized it was more complicated than it looked.

It took us few 🧠 brainstorming sessions to land on a set of custom client-side events that gave us the visibility we needed.

🎯 The Events That Made It Possible

To track meaningful activity, we created and instrumented focus events — signals that fire based on what the agent is doing or which tab/page is in view.

For example, we started tracking events that captured whether an agent was on the main dashboard or had navigated away, whether they were viewing the Issues page or another section, and when they were focused on a specific ticket.

To detect whether agents were really present and engaged, we initially used the browser’s visibilitychange event. We set up the visibility tracking by adding an event listener as soon as the HsPage component loaded.

• When the dashboard tab became visible, we logged an Agent Helpshift (HS) In Focus event. It tells us whether the agent actually has the Helpshift dashboard in focus, rather than just having it open in the background.
• When it became hidden, we logged an Agent HS Out Focus event.

But this came with some challenges-

While visibilitychange worked well in many scenarios (like switching tabs, minimizing the window, or full-screening another app), it didn’t trigger when-

• The tab was covered by an overlay screen using CMD + Tab
• The user used gestures like three-finger swipe to switch between open applications
• The app was searched via Spotlight (macOS)

In these cases, the HS tab remained “In Focus”, technically it was still visible to the browser. As a result, the “Out of Focus” event wasn’t triggered, and we couldn’t reliably track focus loss.

To make tracking more accurate, we moved to using focus and blur event listeners. These events are fired more consistently when:

• A user switches away from or returns to the browser window
• The browser itself loses or gains focus — regardless of how the switch happens

componentDidMount: function () {
    window.addEventListener("focus", handleFocus);
    window.addEventListener("blur", handleBlur);
  }

But in case of session expiry, manual logouts or when dashboard is manually closed or refreshed, the blur event wasn’t getting triggered. So we used beforeunload event listener to capture “Out of Focus” event.

componentDidMount: function () {
    window.addEventListener("focus", handleFocus);
    window.addEventListener("blur", handleBlur);
    window.addEventListener("beforeunload", handleBeforeUnload);
  }

The beforeunload event listener will get triggered when the current window, contained documents are about to be unloaded:

componentWillUnmount: function () {
    window.removeEventListener("focus", handleFocus);
    window.removeEventListener("blur", handleBlur);
    window.removeEventListener("beforeunload", handleBeforeUnload);
  }

These events gave us start and end timestamps for focused interactions — a key ingredient in our metric calculations.

🧑‍💻📈Agents Pipeline Overview

Before diving deeper, let’s first understand how the foundation of our data platform is structured

How our Data Platform works

Our data platform is built with multiple layers on AWS S3, each serving a specific purpose.

We capture all events coming in from Kafka and store in the Silver Layer on S3 as Parquet files. Data from the Silver layer is cleaned, transformed, and aggregated into half-hour intervals and stored in Hudi format in the Gold Layer, still as Parquet files.

The Gold data feeds into Redshift, making it easier to run fast queries and integrate with BI tools. This layer supports both internal analytics (like Metabase reports) and customer-facing use cases.

👉 In short, Kafka → Silver → Gold → Redshift → Analytics is the pipeline that takes raw events and turns them into insights for both our teams and our customers.

Turning Events into Metrics

With the pipelines setup and events in place, next task was to implement these agents productivity metrics in Agents Fact table.

But defining the metrics wasn’t just about dropping numbers into a table, it was about deciding how exactly we calculate them. Some were straightforward, based on simple “in” and “out” events, while others required more context and logic.

Calculating something like Dashboard Interaction Time sounds simple at first:

• In event (agent_hs_in_focus) marks the start
• Out event (agent_hs_out_focus) marks the end
• The difference gives you the time spent

Easy, right? Well, not always.

Because we aggregate metrics in half-hour windows, things get tricky when the in and out events don’t fall in the same window.

Example

Imagine an agent comes in focus at 00:20 and goes out of focus at 01:12. Instead of just one number, we need to break this time into chunks, one for each 30-minute window:

• 00:00–00:30 → 10 minutes
• 00:30–01:00 → 30 minutes
• 01:00–01:30 → 12 minutes

Total dashboard interaction time → 52 minutes

The State Table

To handle this, we keep track of the agent’s last known state in a state table. That way, when the pipeline runs for the next window, it knows whether the agent was already in focus and can continue the calculation until the corresponding out event arrives.

agents_state table

| agent_id   | version_ts     | is_currently_hs_in_focus |
|------------|----------------|--------------------------|
| profile_1  | 1757500200000  | 1                        |

In the state table, we store previous half an hour state as boolean value. This ensures metrics are accurate across windows, even if an agent stays focused for hours without switching tabs.

Unallocated Time metrics

Unallocated time, however, was a whole different story. We had to figure out: Were they available but idle? Were there no issues to pick up? Did they go unavailable without actually working on anything?

Step 1: Understanding the waiting_for_agent State

We relied heavily on a state called waiting_for_agent count — a counter representing how many tickets are actionable for a specific agent.

Tickets can land in this state due to several triggers:

• A new ticket is assigned to the agent
• A customer replies to an ongoing conversation
• The status changes, making the issue actionable for the agent

This count is crucial:
 — If it’s greater than 0, the agent has work.
 — If it’s 0, the agent is idle and “unallocated”.

Step 2: Starting With a Clean State Daily

Since ticket states fluctuate constantly throughout the day, we need a stable starting point.

Every day at 00:00 hours, we take a snapshot of waiting_for_agent count for each agent from Elasticsearch (ES). This acts as our baseline.

This helps avoid compounding errors due to missed or delayed events.

Step 3: Calculating the Metric via Spark UDF

To compute Unallocated Time, we combined:

• The daily snapshot from ES
• Real-time state transition events (like ticket assignments or replies)
• Agent availability status

We built a Spark UDF (User Defined Function) for this. Why a UDF?

Because we needed to apply a custom logic across millions of rows of event data, which native Spark functions couldn’t handle flexibly.

Example: A Day in the Life of Agent

Let’s visualize how this logic plays out for an agent named Alice

Timeline:

From the above, we can calculate:

• First unallocated window: 09:00–09:15 = 15 mins
• Second unallocated window: 09:45–10:00 = 15 mins
• Total unallocated time for Alice: 30 minutes

How We Manage State Across Runs

State management is critical to avoid errors during reruns or failures.

agents_state table

| agent_id   | version_ts     | waiting_for_agent_count  |
|------------|----------------|--------------------------|
| profile_1  | 1757500200000  | 0                        |

• We persist the last known state (i.e was the timer running or not) at the end of each run.
• During the next run, we pull the ES snapshot for the first day of the run or fetch the last saved state from the previous run
• Continue from where we left off

It helps maintain consistency, especially in distributed systems where task failures can happen.

🔖Final Thoughts

Yes, there were plenty of technical hurdles — missing events, tricky edge cases and complex implementation logic. But tackling those challenges helped us build something truly meaningful.

Ultimately, it’s all about transforming raw data into real insights — that’s where the real impact begins.

How Data Powers Agent Productivity was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

When building systems that process large volumes of messages synchronously, performance bottlenecks can quickly become a challenge specially with single-threaded designs. In this post, we’ll look at how leveraging worker threads in a Clojure-based Kafka consumer can significantly boost throughput & reduce total processing time. Using simple concurrency primitives, it’s possible to achieve parallelism & scale gracefully, all while keeping the codebase clean & maintainable. We’ll start with a baseline, introduce worker threads using Clojure’s core.async & measure the impact.

Setup & Context

• Kafka & Zookeeper
• For observability: Grafana
• Kafka producer: A simple script that sends messages to a Kafka topic at a configurable rate (messages per minute) for a fixed duration. After each event is pushed, a counter metric is emitted
• Kafka consumer: A simple script that listens to a topic & consumes messages & simulates processing time finding square-root of a number (henceforth, assume that it takes ~1 second to find the square root) . A counter metric is emitted after processing each message

The Baseline: Single-Threaded Consumer

If each message takes t seconds to process & there are n messages, total processing time becomes n × t seconds. This provides a clean baseline to evaluate the impact of using channel moving forward.

Adding workers with core.async

Values are conveyed on queue-like channels. By default channels require producer and consumer to rendezvous for the transfer of a value through the channel
https://clojuredocs.org/clojure.core.async

• To improve throughput, we introduce parallelism using Clojure’s core.async channels. Messages from Kafka are fed into a channel, & multiple worker threads read from this channel to process messages concurrently
• Here, we used >!! (blocking put) & <!! (blocking take) to communicate via channels & future to execute the business-logic on a separate thread

Who gets blocked & when :

• The thread putting message into the channel will get blocked when there is no space in the buffer
• The thread consuming message from the channel will get blocked when there is no message in the buffer

Benchmarking

The producer script runs for 5 minutes, producing 200 messages per minute into a topic

• Single-threaded consumer: Time taken to process 1k events 16min 30sec
• With 3 workers using core.async : Time taken to process 1k events 5min 42sec (65% faster than Single-threaded)
• With 10 workers using core.async: Time taken to process 1k events 5min (70% faster than Single-threaded & 12% faster than 3 worker-setup)

Please note that we are using just one machine to benchmark the single & multi threaded consumer setup, this might not be ideal in production but is suffice to gauge the impact of adding worker threads on throughput & processing-time.

Consider another scenario, where the producer script runs for 5 minutes again, but this time it produces 500 messages per minute into the topic

• Single-threaded consumer: Time taken to process 2.5k events 40min 28sec
• With 3 workers threads: Time taken to process 2.5k events 13min 39sec (66% faster than Single-threaded)
• With 10 workers threads: Time taken to process 2.5k events 5min 6sec (87% faster than Single-threaded & 62% faster than 3 worker-setup)

Comparing load averages

• One of the primary trade-off between single-threaded & multi-threaded consumers lies in balancing system load with processing throughput.
• While multi-threaded consumers provide higher parallelism & faster event handling, they also lead to increased CPU usage & a noticeably higher system load average. On the other hand, single-threaded consumers maintain a lower & more predictable system load but process events at a slower rate.
• During the benchmarking, it was observed that transitioning to a multi-threaded model caused the load average to rise significantly. This increase — measured using the uptime command — highlights the computational overhead introduced by concurrency & highlights the need to tune thread count & workload based on the system’s capacity

Analysing the logs & threads

Consider the below function gets invokes by the kafka consumer for processing each message

(defn process-event
  [event]
  (let [start-time (System/currentTimeMillis)]

    ;; simulate work : find square-root
    (dotimes [_ (* 10000 10000)]
      (Math/sqrt (* 1000 1000)))

    ;; logging 
    (let [end-time (System/currentTimeMillis)
          elapsed-seconds (/ (- end-time start-time) 1000.0)]
      (println {:id (:id event)
                :thread (.getName (Thread/currentThread))
                :duration elapsed-seconds}))

    ;; increment metric
    (clj-statsd/increment "event-processing.done")))

Below are the logs when run with :

Single-threaded consumer

[INFO] {:id 1 :thread clojure-agent-send-off-pool-6 :duration 1.001}
[INFO] {:id 2 :thread clojure-agent-send-off-pool-6 :duration 1.000}
[INFO] {:id 3 :thread clojure-agent-send-off-pool-6 :duration 1.002}
[INFO] {:id 4 :thread clojure-agent-send-off-pool-6 :duration 1.000}
[INFO] {:id 5 :thread clojure-agent-send-off-pool-6 :duration 1.001}
... and so on

Consumer with 3 worker threads

[INFO] {:id 1 :thread clojure-agent-send-off-pool-9 :duration 1.001}
[INFO] {:id 2 :thread clojure-agent-send-off-pool-7 :duration 1.000}
[INFO] {:id 5 :thread clojure-agent-send-off-pool-8 :duration 1.002}
[INFO] {:id 3 :thread clojure-agent-send-off-pool-9 :duration 1.000}
[INFO] {:id 4 :thread clojure-agent-send-off-pool-7 :duration 1.001}
... and so on

Consumer with 10 worker threads

[INFO] {:id 1  :thread clojure-agent-send-off-pool-10 :duration 1.001}
[INFO] {:id 2  :thread clojure-agent-send-off-pool-11 :duration 1.000}
[INFO] {:id 4  :thread clojure-agent-send-off-pool-12 :duration 1.002}
[INFO] {:id 3  :thread clojure-agent-send-off-pool-13 :duration 1.000}
[INFO] {:id 6  :thread clojure-agent-send-off-pool-14 :duration 1.001}
[INFO] {:id 5  :thread clojure-agent-send-off-pool-3  :duration 1.001}
[INFO] {:id 7  :thread clojure-agent-send-off-pool-4  :duration 1.000}
[INFO] {:id 9  :thread clojure-agent-send-off-pool-7  :duration 1.002}
[INFO] {:id 8  :thread clojure-agent-send-off-pool-8  :duration 1.000}
[INFO] {:id 10 :thread clojure-agent-send-off-pool-9  :duration 1.001}
... and so on

We can use VisualVM to check the JVM threads, doing this for the setup with 10 workers is shown below :

Conclusion

• By carefully orchestrating channels & worker threads, we can increase throughput & reduce the total processing time.
• If you have a similar use-case, Clojure’s core.async might be just what you need to scale without sacrificing simplicity.
• We can also infer, from the above VisualVM thread visualizer, that it is a scenario of parallel (& not concurrent) execution by looking at the overlapping running status of multiple threads.

You can checkout the implementation details here : https://github.com/abhinavdubey8989/clj-core-async-poc

Using Clojure channels to increase throughput was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

At Helpshift, our data platform follows a Lakehouse architecture, combining the best of both data lakes and data warehouses. This architecture allows us to store and analyze large amounts of raw data in a structured and organized manner, while also providing the scalability and low-cost storage of a data lake. It consists of three key components:

• Amazon S3 for storing historical data efficiently.
• Amazon EMR for running Spark pipelines on ephemeral compute.
• Amazon Redshift as the data warehouse powering customer-facing analytics, which includes Embedded Dashboard analytics, Power BI template apps, and Analytics APIs.

We serve the analytics data models to our customers using AWS Redshift through the following customer channels:

1. Embedded Analytics dashboard with Luzmo as the BI vendor.
2. PowerBI integration using REST API as a datasource. PowerBI apps allow customers to also create customized reports on the data models.
3. REST APIs to query/download analytics data models. These APIs allow custom aggregations and filters. (e.g., hourly or daily rollups, ad hoc filtering, etc.)

We have isolated our read path traffic for the above customer-facing analytics channels in a separate Redshift cluster from the write path traffic. However, in recent months, the team has noticed a few issues during peak hours of read traffic. One of the main challenges that the team faces is performance issues with serving analytics data on the above-mentioned customer channels.

Why This Matters

With increasing adoption of our analytics interfaces — Power BI integrations and REST APIs — the Redshift cluster is under growing pressure from concurrent query workloads. These workloads are latency-sensitive and often power downstream operational or reporting workflows. Failures, timeouts, or inconsistent response times can disrupt customer pipelines, delay business-critical decisions, and increase retry or error-handling complexity on the client side. Ensuring predictable performance and horizontal scalability under load is critical to meeting SLAs, minimizing operational noise, and maintaining a consistent analytics experience across all customer-facing endpoints.

Problem

1. Difficulty in Handling High-Concurrent Traffic
   Redshift offers Multi-Cluster Concurrency Scaling, but it comes at an additional cost and only partially resolves traffic spikes. During peak loads, we observed:

• API failures and timeouts due to query queuing and resource contention.
• Slow query execution despite concurrency scaling, leading to degraded user experience. Query duration varied from 10 seconds to 3 minutes for similar OLAP queries.

2. Vacuum & Sorting Overhead Under High Load

During high-concurrency execution, we noticed:

• Table fragmentation and sort order degradation: As tables are continuously updated with new data, especially under high write throughput, rows become increasingly unsorted. This leads to fragmentation, which degrades scan performance and increases query latencies — particularly for queries relying on sort keys for efficient filtering. High write throughput leads to fragmentation, increasing query execution times.
• Increased query execution time due to on-the-fly sorting: Instead of reading pre-sorted blocks, Redshift spent a substantial portion of query execution time re-sorting fragmented data at runtime, resulting in higher and inconsistent query durations.
• VACUUM operations failing under load: Redshift requires periodic VACUUM operations to reclaim disk space and restore sort order. However, under heavy read and write workloads, VACUUM processes are deprioritized or delayed in favor of query execution. Since VACUUM is resource-intensive, it competes for the same I/O and CPU resources as live queries. On a saturated cluster, this leads to VACUUM jobs stalling, timing out, or failing entirely — leaving tables fragmented and causing query performance to degrade over time.

These challenges prompted us to explore alternative solutions for handling high-concurrency workloads efficiently. To evaluate alternatives, we conducted a performance benchmarking POC between Redshift and Snowflake using load testing tools like Newman and K6.

Tools

Newman and Graphana K6

To effectively simulate traffic and test the performance of our queries, we used Newman and k6, the powerful duo that helped us simulate the load.

Newman is a command-line tool built by Postman to run collections of API requests directly from the terminal. It’s particularly useful for automating and running tests for APIs, making it a great tool for testing query performance. It helps to execute postman collections via command line and supports parameterization, i.e., you can specify variables like the number of runs, parallel executions, and delay between requests.

Graphana K6 is an open source tool that is optimized for minimal resource consumption and designed for running high-load performance tests.

Let's quickly walk through the setup steps for these tools.

Setup Steps

I. Newman

We already had the postman collection of our Analytics API’s. To setup Newman. Ensure npm is installed and upgraded to version 16. Install Neman and check if its working correctly.

--> npm install -g newman
--> newman run Sunbird\ -\ Analytics\ API.postman_collection.json

This executes the API requests from the collection and provides important metrics, such as total run time, average request time, and other performance stats.

II. k6

Next, to simulate more realistic traffic using k6, which can handle a higher load and more complex testing scenarios, install k6.

--> brew install k6
--> npm install -g postman-to-k6 ;; a tool to convert Postman collections to k6 scripts
--> postman-to-k6 Sunbird\ -\ Analytics\ API.postman_collection.json -o scriptIssue.js

The last command generates a scriptIssue.js file that contains the necessary k6 script to perform load testing on the API.

III. Testing Steps

We tested the Issue entity API, which has a from and to parameter required for date ranges.

Step 1: To simulate a realistic dataset, we created a CSV file with random values for the from and to parameters. For example, in a file named IssueWeeklyData.csv with sample data.

Step 2: Created a new file for the k6 script, namedIssueScript.jsin the same directory as our CSV file. Sample k6 script: The script lets us define the stages, http_req_duration, etc.

This script will:

• Randomly select values from the csv file for the from and to parameters.
• Make HTTP GET requests to the API endpoint with those parameters.
• Check the response status and time, ensuring the queries run within the expected time limits.

k6 run IssueScript.js

This will simulate the load, making concurrent requests to the API, and output performance metrics like response times, throughput, and error rates. Sample output looks like —

✗ status is 200
      ↳  95% — ✓ 97 / ✗ 5
     ✗ response time < 3000ms i.e 3 secs
      ↳  2% — ✓ 3 / ✗ 99

     checks.........................: 49.01% ✓ 100      ✗ 104
     data_received..................: 14 MB  940 kB/s
     data_sent......................: 19 kB  1.3 kB/s
     http_req_blocked...............: avg=256.57µs min=2µs      med=26.99µs max=1.52ms   p(90)=669.4µs  p(95)=697.49µs
     http_req_connecting............: avg=191.59µs min=0s       med=0s      max=820µs    p(90)=534.3µs  p(95)=555.85µs
   ✗ http_req_duration..............: avg=3.43s    min=271.48ms med=2.11s   max=8.08s    p(90)=6.49s    p(95)=7.11s
       { expected_response:true }...: avg=3.56s    min=479.34ms med=4.65s   max=8.08s    p(90)=6.57s    p(95)=7.13s
     http_req_failed................: 4.90%  ✓ 5        ✗ 97
     http_req_receiving.............: avg=82.49ms  min=25µs     med=14.53ms max=549.84ms p(90)=220.58ms p(95)=292.28ms
     http_req_sending...............: avg=50.84µs  min=10µs     med=40.5µs  max=161µs    p(90)=101.6µs  p(95)=117.89µs
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s      max=0s       p(90)=0s       p(95)=0s
     http_req_waiting...............: avg=3.35s    min=271.42ms med=2.09s   max=7.87s    p(90)=6.3s     p(95)=7.03s
     http_reqs......................: 102    6.851256/s
     iteration_duration.............: avg=4.43s    min=1.27s    med=3.11s   max=9.08s    p(90)=7.49s    p(95)=8.11s
     iterations.....................: 102    6.851256/s
     vus............................: 20     min=3      max=50
     vus_max........................: 50     min=50     max=50


running (14.9s), 00/50 VUs, 102 complete and 0 interrupted iterations
default ✓ [======================================] 00/50 VUs  10s
ERRO[0016] thresholds on metrics 'http_req_duration' have been crossed

Approach

Key variables tested:

To evaluate the performance of both Redshift and Snowflake under varying loads, we simulated API queries under different scenarios. Several key parameters were used to assess how each platform performs under different levels of demand and customer data sizes:

1. Number of concurrent queries: We tested with different numbers of concurrent queries being executed within 1 second to simulate various load scenarios. This helped us understand how each platform scales under high traffic and whether it can handle bursty traffic spikes.
2. Snowflake Warehouse Size: We used different warehouse sizes on Snowflake—XS(Extra Small), S (Small), and M (Medium) — to simulate performance across various configurations. The warehouse size plays a significant role in determining how much compute power is available to handle queries, particularly during peak usage.
3. Snowflake Cluster’s Maximum Capacity: Snowflake’s ability to scale automatically by adding or removing clusters was tested to see how well it handled increases in concurrent queries. We simulated workloads pushing Snowflake’s cluster capacity to its limit to evaluate its auto-scaling capabilities.
4. Customer Data Size: We simulated queries for customers with small, medium, and large datasets to assess how Snowflake handles different data volumes.

Results & Findings

For our Analytics and Power BI API load test, we selected two heavily used APIs: Issues Entity API and Agents Entity API. We ran these APIs against both Redshift and Snowflake, evaluating total execution time under different conditions. Overall, Snowflake has a much better query execution time under heavy workload for our use cases and proved to be relatively better than Redshift.

• These preliminary performance tests showed ~30 to 50 % improved query performance on Snowflake read path compared to our current Redshift Database.
• Cost of Operation: By extrapolating the numbers based on POC runs, Snowflake has a 2x or 3x jump in cost as compared to Redshift.
• Scalability: Snowflake is very easy to scale up or down automatically and can cater to high concurrency with high performance.

Conclusion

Snowflake offered significant performance improvements in handling high-concurrency workloads, especially in terms of query latency and scalability. However, these benefits came at a higher operational cost, highlighting the trade-offs between performance and budget.

This POC was a valuable exercise in defining the right architectural decisions to support the growing demand on our customer-facing analytics platform. It validated the need for more elastic and maintenance-free architectures as concurrency continues to scale.

Future work will focus on evaluating cost optimization strategies within Snowflake, including compute sizing, auto-suspend configurations, and query tuning, to ensure that the improved performance aligns with our operational efficiency goals.

Thanks to Abhishek and Aqeel for the valuable support.

Load Testing API’s on Redshift & Snowflake — A Quick POC was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forms are everywhere online, from signing up for newsletters to making purchases. But let’s be honest — nothing’s more frustrating than a form that’s hard to fill out or riddled with unclear error messages. In this post, we’ll dive into practical tips and tricks to make your form validation seamless, user-friendly, and maybe even enjoyable!

We’ll walk through tips for using built-in HTML features and creating custom validation with JavaScript. No complicated jargon — just practical steps to improve your forms.

# Tip 01: Use the Correct HTML Input Types

If you set the input type as “text” for a password field, the password will not be obscured as you type. Similarly, if you use the “text” input type for an email field, the browser’s default email pattern check will not be triggered.

When you use the correct input type, the password field will obscure the characters being typed, which is the desired behavior. Additionally, if you type an incorrect email address in the email field, the browser will notify you with a pop-up because of the built-in validation it provides.

• Email should use type="email".
• Password should use type="password".
• Confirm Password should also be used type="password".

Code:

Add Form Validation Tip #1 · hritik5102/Form-Validation-Tips@502e416

# Tip 02: Built-in HTML Validators

If the username is the required field in your form. To ensure that the username field contains valid data, mark it as “required.” If the user tries to submit the form without filling in this field, the browser will prompt them to complete it. You can also restrict the number of characters by using the “minlength” attribute.

• For Username, mark it as “required.” If empty upon submission, the browser will ask: "Please fill out this field."
• Use minlength="5" to require a minimum of five characters.

Code:

Add Form Validation Tip #2 · hritik5102/Form-Validation-Tips@cd8abbb

# Tip 03: Using Regex for Pattern Matching

• For instance, to require a number in the username, use the pattern attribute: pattern="^[0-9]+$".
• If a string is entered instead of a number, an HTML tooltip will appear, prompting: “Please match the requested format.”

Code:

Add Form Validation Tip #3 · hritik5102/Form-Validation-Tips@3b3230b

# Tip 04: Custom Tooltip Validation Messages

• The tooltip message “Please match the requested format” doesn’t clearly explain the specific format we expect from the user.
• We can use the title attribute to display custom tooltips. For example, on the username field, set title="Username must be at least 5 characters and include a number."

Code:

Add Form Validation Tip #4 · hritik5102/Form-Validation-Tips@9e64865

# Tip 05: Create Custom Tooltip Messages with JavaScript

• reportValidity() is a method available on form elements (<form>, <input>, <select>, <textarea>, etc.) that triggers the browser's built-in form validation.
• setCustomValidity(message) is a method on input elements that lets you set a custom validation message, overriding the browser’s default message for specific constraints.
• Together, they provide a robust mechanism for client-side form validation in web applications.

Code:

Add Form Validation Tip #5 · hritik5102/Form-Validation-Tips@73c63bc

# Tip 06: Avoid Early Validation

• Wait until the user moves to the next input or loses focus on the current input before validating. Replace the onInput event handler with onChange for this purpose.

Notice how the error message is displayed only when the end user shifts focus to the next input field.

Code:

Add Form Validation Tip #6 · hritik5102/Form-Validation-Tips@1ed19a1

# Tip 07: Show Specific Validation Message At A Time

• Assume the validation accepts both letters and numbers and requires a minimum of 8 characters. If the user enters ‘james,’ they will see an error indicating that a number is required. If they enter ‘james12,’ but it is too short, they will see an error stating that the input must be at least 8 characters long. Display the errors when the user moves to the next field.
• Instead of displaying a tooltip for an error message, we can show a custom validation message in red. You can choose either approach based on the UI/UX design of your application.

Code:

Add Form Validation Tip #7 · hritik5102/Form-Validation-Tips@a83908c

# Tip 08: Static Height for Error Messages

• Notice that when an error message appears, the UI shifts slightly, which can look unappealing.
• To prevent this, set a fixed height for error messages to ensure the form’s layout remains consistent and visually appealing.

Code:

Add Form Validation Tip #8 · hritik5102/Form-Validation-Tips@138ae47

# Tip 09: Highlight Errors with Danger Indicators

• Use a red color, danger icon, or tooltip for errors if it fits your UI guidelines. Ensure the tooltip is accessible for screen readers.
• Highlight the input field with a red border when there’s an error.

# Tip 10: Remove Error Messages When Fixed

• Clear error messages as soon as the user meets the required conditions.

# Tip 11: Indicate Required Fields With Red asterisk *️⃣

• How do you know if a field is required? A visual clue, right?
• The red asterisk (*) is one of the most common visual patterns used to indicate that a field is required.
• It allows users to quickly identify mandatory fields, reducing trial and error and speeding up form completion.

Code:

Add Form Validation Tip #9 · hritik5102/Form-Validation-Tips@068226b

# Tip 12: Always Perform Server-side Validation

• Frontend validation can be bypassed if someone tampers with the form or submits it via Postman. Server-side validation is crucial for security.
• Would highly recommend reading this out, this explains why both client and server validations are important.

Why should one validate data if it is already sanitized?

# Tip 13: Ensure your form is not only usable but also accessible

• Adding validation to improve a form’s usability is only half the challenge. The other half is ensuring the form is accessible, meaning that individuals with disabilities can understand whether a field is invalid and know how to correct it.

Accessibility ensures everyone can access the content, while usability focuses on how easy it is to use the website. Together, they create the best possible user experience.

From an accessibility perspective, we must ensure that everyone not only knows the field is invalid but also understands the error message.

Below is a demonstration of the form running on VoiceOver, the built-in screen reader for macOS.

Code:

Form Validation Tip #10 · hritik5102/Form-Validation-Tips@3d96464

You can find the source code for the above tips and tricks in the below repository:

GitHub - hritik5102/Form-Validation-Tips: Form Validation Tips Every Web Developer should know!

Thank you for taking the time to read the post until the end. Your attention and interest are greatly appreciated.

Please 👏🏻 if you like this post. It will motivate me to continue creating high-quality content like this one.

Support Me

Thank you for taking the time to read my blog post! If you found it valuable, I would greatly appreciate it if you could share the post on Twitter and LinkedIn, etc. Your support in spreading the word about my content means a lot to me. Thank you again!

Follow me

I hope you found this post helpful. If you want to stay up-to-date with my latest work, be sure to follow me on Twitter, LinkedIn, and GitHub.

Form Validation Tips Every Web Developer Should Know! was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

A simple guide on how to connect Snowflake data in Power BI to create reports, publish them, and schedule refreshes.

Pre-requisites

Well, since you’ve already reached this page, I’m assuming that you know of, and have access to both the tools — Snowflake as well as Power BI.

In case you do not have both / any of these accounts, you can try signing up below:

• Snowflake
• Power BI

Once you have completed the setup and have things up & running, you can proceed to the next steps.

Creating some dummy data in Snowflake

For our demo purposes, we will create some dummy data.

1. Using the list of SQL queries below, we will create an employee database, an employee schema, & an employee table.

CREATE DATABASE employee_database; 

CREATE SCHEMA employee_database.employee_schema; 

CREATE TABLE employee_database.employee_schema.employee_table
(
    id NUMBER, 
    name VARCHAR,
    salary NUMBER
); 

2. Our newly created Snowflake structure for “employee” data should look like this —

3. Let’s add some test data to the table & see how it looks. Also, you can “describe” the table to view the schema.

DESC TABLE employee_database.employee_schema.employee_table; 

INSERT INTO employee_database.employee_schema.employee_table(id, name, salary) 
    VALUES (111, 'Max', 50000), 
           (222, 'Irene', 55000),
           (333, 'Tim', 70000), 
           (444, 'Harris', 41000), 
           (555, 'Isabelle', 97000), 
           (666, 'Lennon', 87000); 

SELECT * FROM employee_database.employee_schema.employee_table;

→ Now that we have the required data set up in Snowflake, we can move to Power BI Desktop for the next section of this process. ✅

Setting up the Snowflake connection in Power BI Desktop and creating reports

1. Open Power BI Desktop → Get Data → Snowflake → Connect. Click “Advanced options” on the dialog box that appears next.

2. You will now need to add some credentials for the connection details. Although some of these may be optional, it is recommended to include them.

• Server: <your server name>[Note: It will be in the format of <account_name/locator>.<region_id>.snowflakecomputing.com and remember to EXCLUDE the https://]
• Warehouse: <your warehouse name>
• Role: <your role name>
• Database: <your database name> [Note: This should be in CAPITAL LETTERS only]
• SQL statement: <your SQL query>

In the next step, I will explain where to find this information in your Snowflake account.

For our use case, we can add the following details —

• Server: <your server name>
• Warehouse: COMPUTE_WH
• Role: ACCOUNTADMIN
• Database: EMPLOYEE_DATABASE
• SQL statement: SELECT * FROM employee_database.employee_schema.employee_table

3. Now, let’s go back to our Snowflake account to fetch some credentials.

For the Server name, click on your initials on the bottom right → Account → ID → Copy account URL. Don’t forget to remove the “https://” when pasting it.

Role and Warehouse names can be taken from the top right. For a new account, they are usually the same default names.

In a larger organization, you will be provided with these details during your Snowflake account setup, based on your restricted access.

4. Back to Power BI now. After saving the credential details, you will be asked for a “Username” and “Password”.

👉 This is your login information from your Snowflake account.

5. If everything works out as expected, you should be able to see the result of your SQL query. Simply click “Load”.

6. Finally, to wrap on the connection side - choose a mode. Pretty self-explanatory here.

• Import:
  - Data from the source is loaded into Power BI and stored within the file itself.
  - Faster for small to medium-sized datasets. Can perform extensive data transformations, modeling, and calculations on the imported data.
  - Data can be refreshed based on a schedule.
• Direct Query:
  - Power BI connects directly to the data source in real-time and queries the data on-demand.
  - Allows you to work with the most current data available in the source system.
  - Can be slower for large datasets or complex queries because it relies on the performance of the source system.

Personally, I prefer to use the “Import” mode for my use case since I need faster reporting.

7. Time to create reports! To demonstrate, I’ve just made a simple bar chart based on “employee_name” and “employee_salary” using our sample data.

8. Let’s save the report & then publish it to “My Workspace” in the Power BI Service online.

Note: When you publish a Power BI report to your workspace, it also publishes the corresponding dataset automatically.

9. Voila, your report & dataset aka semantic model have been published! 🥳

Scheduling Snowflake data refresh in Power BI Service

1. Now that we can access our report in the Power BI Service online, it is time to connect Power BI Service with our Snowflake account, so that if we make any changes to the database, it is reflected in our reports as well as the PBI semantic model.

For this, Click on the Semantic Model → Settings

2. Under “Data source credentials”, you will notice an error. That’s okay, we’ll fix it now. Click on “Edit credentials”

3. Now enter your Snowflake account login details / credentials, and click “Sign in”.

You can choose any Privacy level setting that fits your purpose.

4. You will notice that the error has disappeared because we have connected our Power BI Service account with our Snowflake account.

Moving on to scheduling a data refresh automatically.

5. Turn on the toggle under “Refresh” and select a frequency, time, and notification (if required). Click “Apply”.

Done! 👍

Testing the connection in Power BI Service

1. To check if our “refresh” would work as expected, let’s make some changes in our “employee_table” in Snowflake and see if it is reflected in our Power BI report.

I will just add some additional records to the table.

INSERT INTO employee_database.employee_schema.employee_table(id, name, salary) 
    VALUES (777, 'Onyx', 100000), 
           (888, 'Selena', 115000), 
           (999, 'Wren', 120000), 
           (123, 'Ariana', 175000),  
           (456, 'Linda', 142000); 

SELECT * FROM employee_database.employee_schema.employee_table; 

2. Instead of waiting for the scheduled refresh to kick in, we’ll perform a “manual” refresh in Power BI to check the updated data.

Go back to the Semantic Model in Power BI Service → Refresh → Refresh now.

3. Wait for the refresh to complete, and then open the “Snowflake Employee Report” that we had published earlier.

You should see the new additional records in the chart!

Conclusion

There you have it. A simple but detailed guide on connecting Snowflake and Power BI.

Cheers!

Breaking the Ice: Integrating Snowflake with Power BI was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

When it comes to JavaScript loading strategies, it’s all about optimizing how and when your Javascript files are downloaded and executed in the browser. This directly affects your web page’s performance, user experience, and overall efficiency of a web application.

Here’s a breakdown of some common strategies:

1. Synchronous Loading ( aka Blocking Script )
2. Asynchronous Loading
3. Defer Loading
4. Dynamic Script Loading
5. Lazy Loading

By choosing the appropriate loading strategy, developers can optimize the loading of JavaScript resources to ensure fast page load times, smooth user interactions, and overall better performance.

Let’s understand the basics

When you load a webpage there are 2 major things happen in your browser:

1. HTML parsing
2. Loading of the script (two ways)
   a. Fetching it from the network
   b. Actually executing script line by line

1️⃣ How HTML is parsed with image attributes?

HTML parsing starts from the top and goes on until it ends, if in between it finds any image tag, it will send a request for downloading that image in the background and continue parsing the HTML even if the image is not downloaded.

But this not the case with script tag. In modern websites, scripts are often “heavier” than HTML, their download size is larger, and processing time is also longer.

When the browser loads HTML and comes across a

<script>…</script> 

It can’t continue building the DOM. It must execute the script right now. The same happens for external scripts <script src=”…”></script> the browser must wait for the script to download, execute the downloaded script, and only then can it process the rest of the page.

2️⃣ Normal script ( without any attribute )

<!-- is fetched and run immediately -->
<script src="index.js"></script>

Black : HTML Parsing
Green : Fetching JS file from the network
Red : Executing that JS file

When browser is loading a webpage, from the above example. It will parse the html first, then if it encounter a script tag in between, it will stop the parsing of the html at that point and it will fetch the script tag from the network and execute that script then and their itself.

After the script is fully executed, HTML parsing continues where it was stopped earlier.

This is the reason script are added at the end of the body tag. so that normal script does not block rendering of the page.

Example:

Output:

What is DOMContentLoaded ? 🤔

The DOMContentLoaded event fires when non-async scripts have arrived and executed and initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images to finish loading.

non-async scripts : JS code present inside <script>... </script tag.

async script : Using async and defer attribute.

3️⃣ Async (load-first order)

// script might run anytime, before OR after HTML is parsed
<script src="index.js" async></script>

With async attribute, HTML parsing and fetching script from the network is done parallelly, once the async script is downloaded and the script execution starts, HTML parsing is stopped and when script is done with its execution then HTML parsing continues, at the point where it had stopped earlier.

Here, if the script download is in progress, then HTML parsing won’t stop. It will keep parsing the HTML, and parsing might get completed even before the script download is finished and it starts its execution. So, in this case, it won’t block HTML parsing.

Independent Execution:

Once the async script is downloaded, the browser executes it as soon as possible, regardless of where the <script> tag is positioned in your HTML or whether other scripts have finished running.

This asynchronous execution allows the browser to continue rendering the page content while the script runs in the background.

if we’ve multiple script tags.

<script src="index.js" async></script>
<script src="main.js" async></script>
<script src="handler.js" async></script>

In above case, the file will be executed randomly based on the which file is downloaded quickly.

💡 Async does not guarantee the order of the execution of the script

Point to be noted

• DOMContentLoaded and async scripts don’t wait for each other:
• DOMContentLoaded may happen both before an async script ( if an async script finishes loading after the page is complete )
• …or after an async script (if an async script is short or was in HTTP-cache)

Example: Index.html

Output:

Summary

• Usually, The page content shows up immediately: async doesn’t block it.
• DOMContentLoaded may happen both before and after async, no guarantees here.
• Async scripts run in the “load-first” order. So whichever script loads first will run first. Here, ‘long.js’ runs first, probably because it might be cached. However, it may happen that ‘small.js’ will run first because it loads before ‘long.js’.

Async scripts are great when we integrate an independent third-party script into the page: counters, ads and so on, as they don’t depend on our scripts, and our scripts shouldn’t wait for them:

<!-- Google Analytics is usually added like this -->
<script async src="https://google-analytics.com/analytics.js"></script>

4️⃣ Defer

The defer attribute tells the browser not to wait for the script. Instead, the browser will continue to process the HTML, build DOM. The script loads “in the background”, and then runs when the DOM is fully built.

As a name suggest, defer means delaying or postponing some event. so here script execution will get delayed.

<!-- blocks DOMContentLoaded, but page might display early -->
<!-- & defer means that the DOM will be ready before run -->
<script src="index.js" defer></script>

With defer attribute, HTML Parsing and fetching script from the network is done parallelly and once the HTML parsing is completed, script execution will start.

Important point to mention:

• Defer is non blocking, in a sense that scripts with defer never block the rendering of the DOM.
• Scripts with defer always execute when the DOM is ready (but before DOMContentLoaded event).

💡 Note: Unlike async, defer guarantees the order of the execution of the script and it will run in the order they’ve defined.

Example

Output:

1. The page content shows up immediately.
2. DOMContentLoaded event handler waits for the deferred script. It only triggers when the script is downloaded and executed.

Deferred scripts keep their relative order, just like regular scripts.

Let’s say, we have two deferred scripts: the long.js and then small.js:

// Long script
<script defer src="https://javascript.info/article/script-async-defer/long.js"></script>

// short script
<script defer src="https://javascript.info/article/script-async-defer/small.js"></script>

Browsers scan the page for scripts and download them in parallel, to improve performance. So in the example above both scripts download in parallel. The small.js probably finishes first.

…But the defer attribute, besides telling the browser “not to block”, ensures that the relative order is kept. So even though small.js loads first, it still waits and runs after long.js executes

That may be important for cases when we need to load a JavaScript library and then a script that depends on it.

The defer attribute is only for external scripts

💡 The defer attribute is ignored if the <script> tag has no src.

I’m not covering the dynamic script and lazy loading strategies in this blog post, as the post has already gotten slightly longer. However, if you want to read about them, here is the article you can check out:

• Javascript.info, “Dynamic scripts”, Aug 26th 2021
• Logrocket, “Understanding lazy loading in JavaScript”,
  Jun 7, 2023

Thank you for taking the time to read the post until the end. Your attention and interest are greatly appreciated.

Please 👏🏻 if you like this post. It will motivate me to continue creating high-quality content like this one.

Support Me

Thank you for taking the time to read my blog post! If you found it valuable, I would greatly appreciate it if you could share the post on Twitter and LinkedIn, etc. Your support in spreading the word about my content means a lot to me. Thank you again!

Follow me

I hope you found this post helpful. If you want to stay up-to-date with my latest work, be sure to follow me on Twitter, LinkedIn, and GitHub.

JavaScript Loading Strategies: Normal vs Async vs Defer was originally published in helpshift-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.