DEV Community: Priyank Sevak

Building a PR Review Agent: My Transition from Learning Scripts to Real Tools (Phase 3)

Priyank Sevak — Mon, 23 Mar 2026 10:41:20 +0000

In Phase 1, I just tried to understand the mental model of what an agent actually is. In Phase 2, I built a basic toy agent from scratch using raw Python to figure out how the LLM tool-calling loop actually works under the hood.

That was great for learning, but writing manual orchestrations for every tool quickly became a bottleneck. So for Phase 3, I forced myself to build something I could actually use, using a real framework.

Here is what I built, and more importantly, what building it taught me.

What I Built: A PR Review Agent

Instead of an abstract "code analyzer," I built a dedicated AI workflow that:

Takes a public GitHub Pull Request URL.
Fetches the raw .diff.
Analyzes the changes (lines added/removed, functions touched, nesting depth).
Fetches the target repository's CONTRIBUTING.md guidelines.
Generates a PR title and description matching the repo's rules.

Because this evolved from a "learning script" into a standalone tool, I extracted it into its own repository:
🔗 GitHub Repo: PR Review Agent

Moving to an Agentic Framework

In Phase 2, I wrote all the orchestration (the while loops, appending to conversation history, managing API retries) myself. It was tedious.

For this project, I used smolagents by Hugging Face. The difference was night and day, but it also forced me to change how I think about building.

1. Tool Descriptions are Contracts

In my previous raw Python agent, I had to write massive JSON schemas to explain my tools to the LLM.

smolagents abstracts that away with a simple @tool decorator. However, I quickly learned that the docstring of that function is the most critical code you will write. If your description is vague, the LLM will hallucinate parameters or ignore the tool entirely. I stopped thinking about "writing code" and started thinking about "designing clear contracts."

2. Single-Agent vs Multi-Agent

There is a lot of hype right now about "Multi-Agent Systems." It’s tempting to try and build a complex swarm of agents (a fetcher, a reader, a reviewer).

As a beginner in this space, I explicitly avoided that. I stuck to a Single-Agent + Tools architecture.

The CodeAgent (powered by the powerful open-weights Qwen2.5-Coder-32B-Instruct model) was more than capable of handling the linear task (fetch diff → read guidelines → write summary) on its own if I just gave it the right tools. Splitting it into multiple agents would have been over-engineering just for the sake of buzzwords.

3. Splitting Up Tools Increases Reliability

My first instinct was to write one giant tool: fetch_and_analyze_pr.

But I realized that tools should execute, not reason. I split it up: one tool just fetches the diff text, and another tool parses the metadata. By giving the LLM granular tools, it got visibility into both the raw code and the structured stats, which made its final PR description much more accurate.

What's Next

I am documenting this journey not because I’m an expert, but to demonstrate my capabilities as I transition into this field. Shipping this project showed me that open-source models (like Qwen via Hugging Face) are incredibly capable when you give them well-structured tools and a clean orchestration loop.

The PR Review Agent works, but there's a lot of room for improvement.

Until then, the rule remains: Build → Refine → Document → Move Forward.

If you are also navigating the shift into AI Engineering, you can follow the core learning tracking repository here:
🔗 Agentic-AI-Journey

Building my first AI Agent from scratch (Phase 2)

Priyank Sevak — Wed, 25 Feb 2026 08:54:48 +0000

In my last post, I broke down the mental model behind AI Agents: what they are, how they differ from chatbots, and the agent lifecycle (Observe → Think → Plan → Act → Repeat).

That was Phase 1: understanding.

Phase 2 was about building.

I went from "I can explain agents" to "I can build one from scratch." Here's what that looked like.

What I Built

A Code Analyzer Agent a simple tool-calling agent powered by Google Gemini.

You give it code. It runs a local tool to analyze it: extracting function names, class names, import counts, nesting depth, complexity hints, and more, then Gemini summarizes the results in plain English.

It follows the basic ReAct pattern:

User input → send to Gemini (with full conversation history)
Gemini decides → should I use a tool, or just respond?
If tool needed → execute locally, send result back to Gemini
Gemini responds → writes a friendly summary using the tool result
If no tool → respond directly
Loop until the user exits

Here's the GitHub repo if you want to look at the code.

The Architecture

The agent has three pieces:

1. The Reasoning Engine (Gemini)

Gemini acts as the brain. It reads the user's message, looks at the available tools, and decides "Should I call a function or just answer this myself?"

This is function calling — Gemini doesn't just generate text, it can generate structured function calls that your code executes.

2. The Tool (analyze_code)

A Python function that takes code as input and returns rich analysis:

{
  "total_lines": 26,
  "blank_lines": 6,
  "comment_lines": 1,
  "import_count": 3,
  "function_names": ["__init__", "load", "process", "helper"],
  "class_names": ["DataProcessor"],
  "has_main_guard": True,
  "longest_function": {"name": "load", "lines": 7},
  "complexity_hints": ["Deeply nested code detected (max depth: 5 levels)"]
}

The tool doesn't think. It just executes. It uses Python's re module (regex) to extract names and patterns.

But to make Gemini aware of it, I had to define a function declaration, a schema that describes the tool's name, what it does, and what parameters it expects:

analyze_code_declaration = types.FunctionDeclaration(
    name="analyze_code",
    description="Analyze a code snippet and return the number of lines, functions, and classes.",
    parameters=types.Schema(
        type=types.Type.OBJECT,
        properties={
            "code": types.Schema(
                type=types.Type.STRING,
                description="The code snippet to analyze",
            ),
        },
        required=["code"],
    ),
)

3. The Orchestrator (main.py)

The loop that ties it all together. Notice how history accumulates every message and how tool results are fed back to Gemini:

history = []  # Conversation memory

while True:
    user_input = input("You: ")

    # Add user message to history
    history.append(types.Content(role="user", parts=[types.Part.from_text(text=user_input)]))

    # Send FULL history to Gemini (not just latest message)
    response = client.models.generate_content(
        model="gemini-3-flash-preview",
        contents=history,
        config=config,
    )

    part = response.candidates[0].content.parts[0]

    if part.function_call:
        name = part.function_call.name
        result = available_tools[name](**dict(part.function_call.args))

        # Add tool call + result to history
        history.append(response.candidates[0].content)
        history.append(types.Content(role="user", parts=[
            types.Part.from_function_response(name=name, response=result)
        ]))

        # Send result BACK to Gemini for a friendly summary
        follow_up = client.models.generate_content(
            model="gemini-3-flash-preview",
            contents=history,
            config=config,
        )
        print(f"Agent: {follow_up.text}")
        history.append(follow_up.candidates[0].content)
    else:
        print(f"Agent: {response.text}")
        history.append(response.candidates[0].content)

What I Actually Learned

1. The LLM is too smart for your tools

This was the biggest surprise. I gave Gemini an analyze_code tool, sent it the code, and it... just analyzed the code itself instead of calling my tool.

Why? Because Gemini looked at the tool (counts lines and functions) and decided it could give a better answer by responding directly.

The fix: System instructions.

system_instruction = (
    "You are a code analysis agent. "
    "When the user provides any code snippet, "
    "you MUST use the analyze_code tool."
)

2. Function declarations are the contract

The FunctionDeclaration isn't just metadata it's the contract between your code and the LLM. The description and parameter names directly affect whether Gemini decides to call the tool.

A vague description = Gemini ignores your tool.
A clear description = Gemini uses it correctly.

3. Tool dispatch needs to be dynamic

In my first version, I hardcoded the tool call:

# Bad — doesn't scale
result = analyze_code(function_call.args["code"])

The fix is a simple dict that maps tool names to functions:

available_tools = {
    "analyze_code": analyze_code,
}

# Good — works for any number of tools
result = available_tools[name](**args)

This is exactly how you'd scale to a multi-tool agent.

4. Your agent needs memory

My first version sent only the latest user message to Gemini. It had zero memory. So when I said "What can I improve in the code above?", Gemini replied "Please provide the code" it genuinely didn't remember "above."

The fix: maintain a history list that accumulates every message (user + agent + tool calls). Send the full history to Gemini on every turn. Now follow-up questions just work.

5. Tool results must go back to the LLM

This was the biggest "aha" moment. My first agent loop looked like:

User → Gemini → Tool Call → Print raw result → Done

The tool result was just printed as a raw dictionary. Gemini never saw it! So it could never summarize it or reason about it.

The correct pattern is:

User → Gemini → Tool Call → Run Tool → Send result BACK to Gemini → Gemini responds

This "return trip" is what makes the agent actually useful. Without it, you're just printing JSON.

6. Yes, 2 API calls when using a tool — and that's OK

When a tool is used, you make 2 Gemini calls:

Call 1: User message → Gemini decides to call a tool
Call 2: Tool result → Gemini writes a friendly response

This is the standard pattern across every LLM API (OpenAI, Anthropic, Google). The LLM can't execute your code it can only ask you to run it. So there's always a round trip.

But when no tool is needed (follow-up questions), it's only 1 call — Gemini already has the context in the conversation history.

Lesson: Be mindful of LLM round-trips, but don't over-optimize. The 2-call pattern is the cost of giving your agent autonomy.

What's Next

Phase 2 gave me a working agent with a single tool, conversation memory, and a complete tool-feedback loop.

Next up:

Multi-tool agent — adding more tools and letting the LLM choose between them
Persistent memory — saving context across sessions (not just within one conversation)
Self-evaluation — having the agent check its own output

Building this agent taught me that the core of agentic AI is not the model itself, but the control flow that connects the model, tools, and memory into a coherent reasoning cycle.

🔗 GitHub: DecodersLord/Agentic-AI-Journey

📖 Phase 1 Post: AI Agent VS Chatbot

AI Agent VS Chatbot (Phase 1)

Priyank Sevak — Wed, 11 Feb 2026 14:21:48 +0000

What is a Chatbot?

Long before Large Language Model (LLMs) became mainstream, chatbots were already widely used in customer support, websites, and internal tools.

A traditional chatbot was essentially a structured decision tree, Set of predefined rules, flows and conditions if/else logic or state machines. Based on the user's response, the system would move to the next predefined step in the conversation.

While it worked well for predictable use cases, it had major limitations:

It could only handle scenarios that were explicitly programmed.
Any unexpected input would break the flow.
The chatbot can not reason, adapt, or decide new action dynamically.

At best, a chatbot could collect information and maybe trigger a fixed action (like creating a support ticket), but it could not actively try to solve the problem or adjust its strategy.

In short:
Chatbots were reactive, not intelligent.

Introduction of LLMs

Large Language Models (LLMs) introduced a fundamental shift.

Instead of treating every message as just another condition in a decision tree, LLMs interpret user input in a much deeper way:

understanding intent
extracting meaning
handling ambiguity
deciding whether to act or ask clarifying questions

This made conversations feel natural and human-like, rather than mechanical.

For the first time, a system could:

understand what the user really wants
reason about multiple possible responses
generate new solutions instead of following fixed scripts
LLMs provided the cognitive layer that chatbots were missing.

Introducing AI Agent

The rise of LLMs enabled something more powerful than chatbots: AI Agents.

An AI agent is not just a system that talks, it is a system that can:

observe the environment
reason about goals
plan steps
use tools
execute actions
evaluate results
and adapt based on feedback

This bridges the gap between:

"I can talk to you"
and
"I can actually help you achieve something."

Here's how an agent work better than a chatbot

In a chatbot:

The system mainly responds.
It cannot perform complex multi-step actions.
It depends heavily on predefined flows.

In an AI agent:

The system can decide what to do next.
It can call APIs and external tools.
It can retry, replan, and self-correct.
It can operate autonomously toward a goal.

Agent Lifecycle

A typical AI agent follows a loop like this:

Observe
- Receive user input or system state.
Think
- Interpret the situation using reasoning.
Plan
- Decide which actions or tools are needed.
Act
- Execute actions using APIs or services.
Result → Observe again
- Use the outcome as new input and repeat.

This feedback loop is what makes agents adaptive and intelligent, rather than static systems.

Tools at agent's disposal

Looking at the Agent Lifecycle, you can imagine that it needs more than just state machine and codes, it needs the capabilities to make smart decisions and then act upon them.

At high level, an agent usually consists of three core layers:

Reasoning Engine (LLM) The LLM acts as the cognitive core of the agent. It handles:

interpreting user queries
reasoning about context and intent. (i.e. understanding that user means Python programming language vs. reptile).
evaluate results from tools.
decide next steps.

Action (API/Tools) Tools represent everything an agent can do in real world:
- search engine
- databases
- payment services
- scheduling systems
- internal microservices

Tools perform action, they don't think but execute.

The agent can't perform any action on its own it needs access to external tools and APIs to perform action.

Control (Orchestrator) The orchestrator system is responsible for:
- Managing the agent loop.
- Track state and Memory.
- Route Decision to tools.
- Handle retries and failures.

An Orchestrator is implemented using:

workflow engines
task queues
state machines
agent workflows such LangGraph, CrewAI, etc.

Final Thoughts

Instead of writing rigid workflows and hardcoded logic, we are moving towards systems that can:

reason about goals.
adapt to changing environments.
orchestrate tools dynamically.
and improve through feedback loops.

System Design: Availability Patterns

Priyank Sevak — Wed, 02 Oct 2024 17:22:12 +0000

Imagine you're shopping online on a popular e-commerce platform. You've added items to your cart, entered your payment information, and clicked "Place Order." Suddenly, the website crashes. Your order is lost, and you're left frustrated and uncertain. This scenario highlights the critical importance of system availability.

Why Availability Patterns Matter

Availability patterns are essential for ensuring that systems remain operational and accessible, even in the face of hardware failures, software bugs, or other disruptions. They provide redundancy, fault tolerance, and disaster recovery capabilities, ultimately improving the user experience and protecting valuable data.

Factors Affecting System Availability

Network Connectivity:
Imagine an online banking system. If there's a network outage in a specific region, customers in that area will be unable to access their accounts or perform transactions.
Hardware and Software Failures:
A data center experiencing a power outage can lead to hardware failures and system downtime. Additionally, software bugs or vulnerabilities can cause crashes or unexpected behavior.
Scalability Issues:
During peak shopping seasons, an e-commerce website may experience a surge in traffic. If the system is not designed to scale effectively, it could become overwhelmed and experience slowdowns or outages.
Security Breaches:
A ransomware attack on a healthcare provider's network could encrypt patient data, making it inaccessible and disrupting critical operations.
External Dependencies:
A social media platform relies on third-party services for image hosting and video streaming. If these services experience downtime, the social media platform's functionality will be affected.

Measuring Availability:

To assess the reliability and performance of distributed systems, several metrics are commonly used:

Uptime Percentage: This measures the proportion of time a system is operational. A higher percentage indicates greater availability.
Mean Time Between Failures (MTBF): This metric represents the average time between system failures. A higher MTBF suggests a more reliable system.
Mean Time To Repair (MTTR): This measures the average time required to restore a system after a failure. A lower MTTR indicates faster recovery and higher availability.
Service Level Agreements (SLAs): These are formal contracts that define the expected level of service, including availability targets. Meeting or exceeding SLAs is crucial for ensuring customer satisfaction.
Nine's of Availability:

The availability is measured using Nines rather than percentages.

Availability Patterns:

Consider a large-scale banking system. If the system were to go down, customers would be unable to access their accounts, make transactions, or pay bills. This could lead to significant financial losses, operational disruptions, and damage to the bank's reputation.

To mitigate these risks, banks employ various availability patterns:

Fail-Over Pattern:

In a typical failover setup, there's a primary component handling the workload, and a secondary component waiting in the wings. The primary component is constantly monitored for signs of failure. If it goes down, the secondary component is automatically activated to ensure uninterrupted service.

There are several ways to implement failover, including:

Active-Active: Both primary and secondary components are active, handling requests simultaneously.

Active-Passive: The secondary component is inactive until the primary fails.

Disadvantages of Failover

Fail-over adds more hardware and additional complexity.
There is a potential for loss of data if the active system fails before any newly written data can be replicated to the passive.

Replication Pattern:

Replication is a strategy that involves storing multiple copies of data across different locations. This redundancy ensures that even if one location experiences a failure, the data can still be accessed from another.

Master-Master: In this setup, both systems can serve as both the primary and secondary components. They can handle both read and write operations, providing high availability and fault tolerance.

Both Master-Master replication and Active-Active failover involve multiple active components. However, the focus is different:

Master-Master: Primarily concerned with data replication and redundancy. Both systems can handle read and write operations, ensuring high availability and fault tolerance.
Active-Active: Primarily focused on load balancing and performance. Both systems share the workload, improving scalability and response times.
Master-Slave:
Here, one system acts as the master, handling write operations, while the others (slaves) replicate the data for read operations. This provides data redundancy and offloads read traffic from the master.

In both Master-Slave replication and Active-Passive failover, one component is primary and the other is secondary. However, their roles differ:

Master-Slave: The primary system handles writes, while the secondary (slave) replicates data for reads. This provides data redundancy and offloads read traffic.
Active-Passive: The primary system handles requests, while the secondary is on standby, ready to take over if the primary fails. This ensures high availability but may introduce latency during failover.

Conclusion

This post provides a comprehensive overview of availability patterns in distributed systems. It covers the importance of availability, factors affecting it, key metrics, and common patterns like failover and replication. The post also discusses the challenges and best practices for implementing these patterns.

Leave a like.
Leave a comment, Always open to discuss and learn.

Salesforce: Leveling Up with Apex Testing

Priyank Sevak — Mon, 30 Sep 2024 16:16:12 +0000

Think of your code as a house. Testing is like a home inspector – it reveals hidden flaws before they become major problems.

Just like a home inspector ensures your dream home is structurally sound, testing your code is crucial for guaranteeing its reliability and functionality. In the world of Salesforce development, Apex testing plays this vital role. It's a structured approach to simulating real-world scenarios and verifying if your code behaves as intended. Here's how Apex testing empowers you as a developer:

Benefits of Apex Testing:

Uncover Hidden Defects: Imagine deploying code riddled with production errors! Testing acts as a safety net, identifying and eliminating potential bugs before they disrupt your users' experience.
Confidence in Code Changes: Ever hesitate to modify existing code for fear of breaking something? Robust testing provides peace of mind, allowing you to confidently enhance functionalities without introducing regressions.
Meeting Deployment Requirements: Salesforce enforces a minimum code coverage of 75% for deployment. Effective Apex testing ensures your code meets this threshold, enabling smooth deployments.

The Solution - Diving into Apex Testing:

@isTest
private class MyTestClass{
  @isTest
  static void myTest(){
     //Your Test codes
  }

}

Sandbox Testing: A Clean Slate

In Salesforce, Apex test classes operate in a sandbox environment, isolated from your production data. This means you can create and manipulate test data without affecting real-world records.

Understanding Data Access:

While test classes can't directly access your existing data, they can access setup and metadata objects like Users and Profiles. This provides a controlled environment for testing without risking production data.

Leveraging Test Data:

Creating test data is essential for effective testing. You can generate it within your test classes or use utility classes for reusable data creation. This allows you to simulate various scenarios and ensure your code functions as expected.

Benefits of Sandbox Testing:

Isolated Environment: Prevents accidental changes to production data.
Controlled Testing: Enables focused testing without external factors.
Data Flexibility: Create and modify test data to simulate different scenarios.

Utilizing `@testSetup`:

@isTest
private class CommonTestSetup {

    @testSetup static void setup() {
        // Create common test accounts
        List<Account> testAccts = new List<Account>();
        for(Integer i=0;i<2;i++) {
            testAccts.add(new Account(Name = 'TestAcct'+i));
        }
        insert testAccts;        
    }

    @isTest static void testMethod1() {
        // Get the first test account by using a SOQL query
        Account acct = [SELECT Id FROM Account WHERE Name='TestAcct0' LIMIT 1];
        // Modify first account
        acct.Phone = '555-1212';
        // This update is local to this test method only.
        update acct;

        // Delete second account
        Account acct2 = [SELECT Id FROM Account WHERE Name='TestAcct1' LIMIT 1];
        // This deletion is local to this test method only.
        delete acct2;

        // Perform some testing
    }
}

Things to remember while using `@testSetup`:

Each test class can only have one @testSetup method.
The entire test class fails if this method encounters a critical error, like a failed DML operation or assertion.
Additionally, if the @testSetup method calls a non-test method, code coverage won't be calculated for that non-test method.

Escape the Mothership

Priyank Sevak — Sun, 29 Sep 2024 03:39:24 +0000

This is a submission for the Web Game Challenge, Build a Game: Alien Edition

What I Built

I built a web game inspired by the alien abduction story. The game puts you in the shoes of a normal person going about their daily routine. However, a sudden twist awaits! You'll encounter an unexpected situation that forces you to make a crucial choice: run or fight.

RUN:

Dodge and jump over a never-ending stream of aliens as they charge towards you. How long can you survive?

FIGHT:

Note to Self NEVER START A PROJECT LATE

I had the brilliant idea of introducing a "Cuphead" style boss fight to defeat the alien. But I got carried away fixing the bugs in the existing games purely from a code-base perspective. I should have focused on the implementation of this brilliant new feature. Still, my mind kept getting annoyed with the code dumped into my ".js" file and I wasted my time re-arranging and making performance enhancements to the existing game. Which I doubt had any real effect on the game.

//TO-DO
// "Fight" Button will not work... You might just see alien and our hero have a staring contest.

Demo

Live Demo: Try it here
Github Repo: Github

Journey

Choosing the Tools:

I opted for building it using HTML Canvas and JavaScript. This combination provides a lightweight and versatile framework for creating web-based games.

Creating the Sprites:

I started looking for free sprite sheets on craftpix and other resources but had no luck finding good alien sprite. I do not have a good drawing background let alone an animation, which I believe is one of my major drawbacks while trying to create attractive games. While I managed to find good sprites for our "Hero" my search continued to find a good "alien".

To my surprise, I found the Universal LPC Spritesheet Generator. This amazing tool allowed me to customize the "alien" character, I can modify the characters from human to bizarre-looking creatures. This tool is a complete win for me.

Collision Detection & scoring:

To ensure a smooth player experience, I implemented collision detection between the player and the aliens. simply scoring if you are able to jump over the alien accurately.

Challenges and Learnings:

Working with sprite sheets involved learning how to define specific frames from the larger sheet and then manipulating them within the HTML Canvas. Additionally, ensuring proper collision detection required understanding how to calculate bounding boxes for the player and aliens.

I was late to the party, I saw the challenge but took too much time thinking about my game theme and playability. I will implement the fighting scenario in the future and encourage you to check back here for the update.

DevOps: Linux Performance Monitoring

Priyank Sevak — Thu, 26 Sep 2024 18:54:21 +0000

In my previous post DevOps: Understanding Process Monitoring on Linux I discussed how a Linux process works and why it's important to monitor process.

Let's dig deeper into how we can keep an eye out for how a Linux server is "Performing".

TL;DR:

This article dives into Linux process monitoring tools and techniques, helping you keep an eye on your server's performance. It covers command-line tools like top, htop, vmstat, and sar for in-depth monitoring, along with system utilities like System Monitor for a graphical overview. The article also demonstrates a sample script using top and uptime to monitor CPU, memory, and system uptime, laying the groundwork for integrating push notifications.

Performance Monitoring

1.`/proc`

In my previous post, I explained that "Everything is a File in Linux system" so where are these process files stored?

go to your CMD and just type ls /proc and you will see your PIDs in there. This is where the Linux process resides. the /proc directory contains files that contain (including but not limited to):

Current state of Linux Kernel.
Information about System Hardware.
Currently running process.

Try running the below commands to find out more about what does /proc consists of:

cat /proc/cpuinfo

cat /proc/devices #list serial ports, Network Interface, etc.

cat /proc/cmdline #useful in boot failures

/proc can be modified and can be used to communicate configurational changes directly to the kernel.

The Linux kernel is equipped with procps package which contains useful tools such as ps, top, iostat, etc. to help us in performance and process monitoring.

In addition to previously discussed top and ps there are other alternatives to the top which can provide additional or graphical alternatives to the traditional top.

`htop`

htop offers a more visually appealing interface with color-encoded bars for CPU and memory utilization.

It views processes in a tree-like structure making it easier to understand the relationship between processes.

`atop`

atop has the ability to be configured and run on remote systems, making it suitable for large-scale monitoring environments.

atop provides long-term monitoring and analysis. It logs system data to a file which allows to review historic trends and identifies performance issue over time.

2.Where's my task manager?

Isn't it easy to find out what's going on in my system and process on Windows by just hitting "Ctrl+Alt+Del" and going to "Task Manager"? Why doesn't Linux provide something like that?

If you are in a GNOME environment you can find a similar tool under your apps by searching for "System Monitor". System Monitor has 4 tabs:

System: Shows basic system info. -Process: Lists all the running processes. Can sort them and also perform operations such as Kill, stop, or terminating that process.
Resources: Lists current CPU usage, Memory and Swap usage, Network usage, and Disk usage.
File System: Lists all currently mounted file systems and additional info such as mount point, system type, and memory usage.

3.Virtual Memory statistics: `vmstat`

As the name suggests the vmstat command provides detailed info regarding the processes, memory, paging, Input/Output blocks, traps and disk and CPU activity.

The first time you run vmstat it lists the average since the last reboot. the subsequent reports are from the sampling period of provided 'delay'.

Some useful options with vmstat:

vmstat -s #lists memory and scheduling statistics

From the above image you can see that running vmstat -s gives you info regarding:

Amount of used memory: Total memory, currently used memory, Active/Inactive memory, Free, Buffer, Cache, etc.
CPU statistics: High and low priority process, Kernel Process, I/O management, Software interrupts, etc.
Memory Paging: Total pages paged in and paged out from virtual memory, total pages read from and written to swap memory.
Event Counters: Total interrupts, context switches, timestamps, and forks since last boot time.

4.System Activity Reporter: `sar`

Go to your terminal and write the below command:

ls /var/log/sysstat

You will see a bunch of directories either named saDD or saYYYYMMDD where YYYY, MM, and DD stand for Year, Month, and Day. These are "Standard System Activity Daily Data Files".

These are the directories created by sar, which collects and reports information about system activity that has occurred so far since the system started. It is possible to store the output of sar to a different file by the below command:

sar -o [filename] #save output to a different file

sar -1 # shows sar output from the previous day

Real world example:

Problem statement:

You want to keep a check on the current performance of your Linux server. You want to get notified if either CPU usage, Memory Usage, or System usage is going over a certain threshold and prevent unintentional system overutilization.

Assumptions & lab setup

I will be using the below command which is provided by Linux and is a way to benchmark the hardware or software component. It can generate various types of load, including I/O, CPU, Memory, and Network:

stress --cpu 8 --io 4 --vm 4 --vm-bytes 1024M --timeout 10s

I have specified:

CPU load equivalent to 8 CPU cores.
4 I/O concurrent operations.
1024 MB of 4 virtual memory workload.

Solution & Explaination:

#!/bin/bash

# Set the interval for monitoring (in seconds)
interval=5

while true; do
  # Get CPU usage and average load
  cpu_usage=$(top -n 1 | grep 'Cpu(s):' | awk '{print 100 - $8}')
  avg_load=$(uptime | awk '{print $8, $9, $10}')

  # Get memory usage
  mem_total=$(free -m | grep Mem | awk '{print $2}')
  mem_used=$(free -m | grep Mem | awk '{print $3}')
  mem_free=$(free -m | grep Mem | awk '{print $4}')
  mem_usage=$(( ($mem_used * 100) / $mem_total ))

  # Get network statistics
  echo "Network Packets:"
  # Iterate over each interface
  for interface in $(ifconfig | grep 'flags' | awk '{print $1}' | cut -d':' -f1); do
    # Get RX packets and bytes
    packets_transferred=$(ifconfig $interface | grep 'RX packets')


    # Print the interface name and transfer the data
    echo "$interface : $packets_transferred"
  done

  # Get system uptime
  uptime_hours=uptime | awk -F, '{sub(".*up ",x,$1);print $1,$2}'


  echo "CPU Usage: $cpu_usage%"
  echo "Average Load: $avg_load"
  echo "Memory Usage: $mem_usage%"
  echo "System Uptime: $uptime_hours"
  echo


  sleep $interval
done

Code explanation:

Getting the CPU usage:

top -n 1 | grep 'Cpu(s):' | awk '{print 100 - $8}'

Running the top and grepping details regarding the CPU. The top command will show the details regarding the tasks, CPU details, Swap, and Physical Memory in the system.

Getting the Average system load:

In addition to vmstat and sar commands, we can use uptime command to get concise details about the system. uptime command will output the current time, how long the system has been running, how many users are currently logged on, and the system load averages for the past 1, 5 and 15 minutes.

avg_load=$(uptime | awk '{print $8, $9, $10}')

I am simply manipulating the output to only fetch the required average system load from uptime.

Later in the script, I manipulated the same uptime output to get the current uptime. I am using some RegEX to accommodate different uptime. i.e. 15 days, 12 hours, 2 minutes, and 45 seconds

uptime_hours=uptime | awk -F, '{sub(".*up ",x,$1);print $1,$2}'

Getting the Memory usage:

free is another useful command to get detailed output regarding the memory available, used, and free on the system. You can think of it as a more concise version of vmstat -s.

I am manipulating the string returned by free to get the precise memory currently being used.

The output

Here's the output, I am printing out the CPU usage, Memory Usage, or System usage for now. We can extend the bash code and use Push notification services such as pushover, sendmail, etc.

Additional Performance Monitoring Tools:

I would just want to list some additional GUI tools which can help you monitor performance of your linux server better:

1.stacer:
GUI for CPU/Memory and other things

2.saidar:
similar to atop or htop

3.cpu-x:

My personal favorite as it gives very precise details on the CPU, memory and Disk usage and feels familiar to use.

You can also run the stress command that I ran in the beginning to benchmark and stress test the CPU directly inside the cpu-x

Conclusion:

This article effectively explores various Linux process monitoring tools. From command-line utilities offering detailed insights to GUI tools providing a visual representation, you're equipped to choose the tools that best suit your needs. The provided script example demonstrates the practical application of these tools and opens doors for further customization with push notifications.

Feel free to ask any questions or share your preferred monitoring tools and techniques! Let's keep the discussion going!

System Design: Consistency Patterns

Priyank Sevak — Wed, 25 Sep 2024 15:27:12 +0000

TL;DR:

Distributed systems store data across multiple servers for better performance and scalability. This introduces challenges in keeping data consistent across all servers. Consistency patterns determine how updates are propagated:

Strong Consistency: Ensures all servers have the latest data, but can be slow and resource-intensive. Used in file systems, databases, and financial services.
Weak Consistency: Prioritizes availability over perfect data accuracy. May have temporary inconsistencies. Used in VoIP, multiplayer games, and cache servers.
Eventual Consistency: All servers will eventually have the same data, but reads may return outdated data temporarily. Used in CDNs, email systems, and social media platforms.

Distributed Systems

You probably know by now that the website or data we access daily does not necessarily reside on a single server. Everything in today's world mostly works on Distributed Systems meaning that data is scattered across several servers/nodes, these servers can be within the same country or across multiple countries. Distributed System solves problems such as fault tolerance, Scalability, and reliability.

Consider an e-commerce website with a global customer base. To provide fast and reliable service, the website's data is distributed across multiple servers.

However, this distribution can introduce challenges related to data consistency. For instance, imagine two customers, Alice and Bob, trying to purchase the last item of a popular product. If Alice places an order on Server A, the system might initially show the item as in stock. However, before the updated stock information is propagated to Server B, Bob could also place an order, leading to a situation where both customers believe they've successfully purchased the same item.

When Bob later discovers the item is out of stock, it can negatively impact the customer experience and erode trust in the company. This scenario highlights the importance of consistency in distributed systems.

The "Consistency Patterns" will determine how the state is propagated within the distributed systems.

Consistency Patterns

Strong Consistency

As the name suggests, strong consistency prioritizes data consistency over system availability. This pattern is essential for applications where accuracy and reliability are paramount, even if it comes at the cost of performance.

Challenges of Strong Consistency:

Reduced Performance: Ensuring strong consistency can lead to increased latency and slower response times.
Resource Intensive: Implementing strong consistency mechanisms can be computationally expensive, consuming significant system resources.

Applications of Strong Consistency:

File Systems: File systems typically require strong consistency to ensure data integrity and prevent corruption.
Relational Database Management Systems (RDBMS): RDBMSs often implement strong consistency to maintain data accuracy and prevent inconsistencies.
Financial Services: Banking systems and financial transactions demand strong consistency to prevent errors and ensure accurate record-keeping.
Distributed Protocols: Protocols like Paxos and two-phase commit (2PC) are designed to achieve strong consistency in distributed systems.

Weak Consistency

As the name suggests, weak consistency prioritizes availability and fault tolerance over strict data consistency. This pattern is suitable for services where data accuracy is less critical than ensuring the system remains accessible and operational.

Challenges of Weak Consistency:

Data Loss: Data might be lost or corrupted due to inconsistencies between nodes.
Data Conflicts: Conflicting updates to the same data can occur, leading to inconsistencies.

Applications of Weak Consistency:

Voice over IP (VoIP): While audio quality is important, occasional glitches or brief interruptions are often tolerated.
Multiplayer Games: Real-time updates and responsiveness are prioritized over absolute consistency.
Live Streams: Slight delays or buffering are acceptable for a smooth viewing experience. Cache Servers: Caches may contain stale data, but the goal is to provide fast access to frequently requested information.

Eventual Consistency:

Eventual consistency is a relaxed consistency model that guarantees that all replicas of data will eventually converge to the same value if no new updates are made. In other words, while reads may return stale data temporarily, the system will eventually reach a consistent state.

Challenges of Eventual Consistency:

Debugging: Identifying and resolving inconsistencies can be challenging, especially in complex distributed systems.
Data Loss: In rare cases, data loss can occur due to network failures or synchronization issues.
User Experience: Stale data can negatively impact user experience, especially in applications that require real-time updates.

Applications of Eventual Consistency:

Content Delivery Networks (CDNs): CDNs distribute content across multiple servers to improve performance and availability. Eventual consistency allows for quick updates to be propagated, but users might see slightly outdated content temporarily.
Email Systems: Email delivery systems often use eventual consistency to ensure that emails are eventually delivered to their recipients, even if there are temporary network delays or server failures.
Social Media Platforms: Social media feeds often rely on eventual consistency to display updates quickly, even if a user's recent posts might not appear immediately on other users' timelines.

Conclusion:

Choosing the right consistency pattern depends on your application's needs. Strong consistency guarantees accuracy but can be slow. Weak consistency offers high availability but may have temporary inconsistencies. Eventual consistency balances these concerns, ensuring data eventually becomes consistent. Understanding these patterns helps design efficient and reliable distributed systems.

Popver API VS dialog Modal : Same Same but Different

Priyank Sevak — Tue, 24 Sep 2024 18:08:36 +0000

I was reading through some tech news blogs and stumbled upon the heading Popover API lands in Baseline. I was confused, during my recent dive into front-end development, I recently with a very hard time getting accustomed to using Elements in HTML. While going over the blog I was constantly confused as to how was I using the element up until now.

TL;DR

Choose <dialog> for:

Modal popups requiring user focus
Accessibility and keyboard interaction

Choose popover for:

Non-modal popups with light-dismissal
Easy implementation with minimal code

`<dialog>` element

According to the MDN The Dialog element

The HTML element represents a modal or non-modal dialog box or other interactive component, such as a dismissible alert, inspector, or subwindow.

A is generally used and displayed over the content when the website needs to draw the attention of the user to something important. i.e. Subscribing to a newsletter, requesting(more like forcing) to disable the adblocker, or accepting terms and conditions.

`<dialog>` element as Modal

As you might have come across multiple times on multiple websites, some of these popups will be drawn on your entire screen while blurring the background or disabling the background and focusing the user only on the task at hand, the user must either dismiss(only if allowed) the popup or enter the required information for it to go away. This behavior is called the ' element as a modal'. These Modal elements are shown at the top layer of the page.

//To open dialog as a modal.

dialog.showModal();

// To close the dialog.

dialog.close();

element when shown using the showModal() method can be dismissed using the esc key. Keyboard users expect such behaviour which needs to be maintained and is provided by the browser. If multiple modal dialogs are open, only the last dialog will be closed using the esc key.

element as non-modal

You might not always want to stop the user's natural flow of using your webpage, to stop doing everything else and focus on what you want to show but still your content, such as a toast notification, a cookie consent, or general tooltip info. should appear at the top layer of the page, above any other content that can or can not be interacted with by the user. These types of pop-ups are called non-modal pop-ups. Users can dismiss these manually or generally time and will disappear on their own. These non-modal dialogs are still shown at the top layer of the page but their priority can be controlled using the z-index and the modal element will take a higher z-index than this and will make this non-accessible.

//To open dialog as a modal.

dialog.show();

// To close the dialog.

dialog.close();

Code Example

Some Issues

I had hard time grasping the working and usage of non-modal elements. According to me the non-modal element behaved inconsistently and needed Javascript code to handle situations such as:

There's no light dismissal functionality. Clicking outside the model will not close the .
esc key does not dismiss the and needs Javascript to handle that scenario.
need to manage z-index manually if you want to draw the on top layer.

To my surprise popover API answered or fixed these issues and more....

`popover` API

popover are attribute that can be added to any HTML attribute. Here's an example.

<button popovertarget="mypopover">Toggle the popover</button>
<div id="mypopover" popover>Popover content</div>

Main difference between `popover` and `<dialog>` element

The main difference between the popover and <dialog> elements is that popover is always non-modal. The <dialog> element comes with a role=dialog attribute this role attribute is attached to various HTML elements and behaves in a certain way. i.e. h1 has a heading role a has an anchor/Link role. This role is used to determine and help assistive technologies such as screen readers to determine the elements. However, the popover is an attribute to an HTML element as it has no default role attached to it. This helps the <div> in the above example to be hidden until the button is clicked.

The popover attribute can be used with minimal code and while it can be controlled using Javascript it is not required at all times like the <dialog>.

popover can have 2 characteristics:
1.popover=auto: Has functionality for light-dismissal and requires no JS interaction.
2.popover=manual: Needs Javascript interaction such as clicking a button or timer to explicitly close it.

popover is always shown at the top-layer no need to set z-index explicitly.

Code Example:

You can see I can achieve the same behavior with almost no Javascript code. Designing and managing various popover is much easier.

Some Design considerations

popover can have : backdrop set using CSS which can be used to blur or grey out the background of the popover but that does not take-away the light-dismissal functionality of it, and still user can click outside if the pop-up and interact with other elements of your web-page. You should be very careful while determining when to choose popover over <dialog>.

The main thing to consider here is: is the component being displayed the only thing that should have focus at the moment? can user be allowed to interact with anything else?

Conclusion

In conclusion, the element and the popover API offer versatile options for creating interactive popups in your web applications. By understanding their distinct characteristics and use cases, you can make informed decisions to enhance user experience and streamline your development process.

References

Salesforce Automation: Flow

Priyank Sevak — Mon, 23 Sep 2024 15:00:53 +0000

I had a challenging task in front of me. I had recently worked on a user story in one of my sprints and one of my colleagues pinged me today telling me that there is a better and faster way to do this. Let me go over it with you to help you understand too.

TL;DR:

Problem: Needed to send automated emails based on Opportunity stage changes and owner.
Initial Approach: Writing Apex code triggers - complex and time-consuming.
Better Solution: Using Salesforce Flow - more efficient and requires minimal coding.
Flow Steps:
1. Create Record-Triggered Flow for Opportunity object.
2. Add "Decision" element to check for "Closed Won" stage.
3. Create Email Templates for different scenarios.
4. Use "Send Email Alert" action instead of "Send Email" due to recipient limitations.

Problem statement

As a user/agent I need to send the update regarding the newly created opportunity to the opportunity owner. I need to email the opportunity owner regarding the current stage of the opportunity and who updated the stage. If the stage has been set to "Closed won" the owner should receive a congratulatory email with the opportunity amount mentioned in the email.

My initial approach

Being a traditional web developer my instinct falls towards coding out the solution. I quickly laid out the following solution and mailed my colleague to check if that was the correct approach or not.

Create an apex trigger for after insert and after update on the opportunity.
Check for the current stage of the opportunity and determine which "email to be sent out"
Set the email body and subject.
Fetch the relative opportunity and their respective ownerId.
Set the message ToAddress to the opportunity owner email address.
send the email.

I knew there was some sharpening needed to my logic, so I approached my colleague. However, to my surprise, he responded with a laugh and said there is a much easier way that require almost no coding.

Salesforce Flow Automation

Salesforce could automate many tasks by using triggers, Process builders, and Flow.

Here are the type of flows available in salesforce and when we can use them.

REFERENCE: Trailhead FLow Builder Basics

Renewed Approach: Record-Trigger Flow

1.Based on the options provided I quickly understood that I need to create Record-Trigger flow and configure it as below:

Object field: let us specify which object the flow needs to be triggered on.
We can trigger the flow: I have selected when "A record is created or updated" as I need to send the email when the Opportunity is created and updated.
Entry Condition: We can define entry condition which can determine whether to continue with the trigger or not. I can define conditions such as not triggering this flow if the opportunity amount is less than $1000.
Optimize the flow: Basically lets you select whether you want to trigger the flow before or after the object is created/updated. For sending emails it is advised to select after trigger.

2.I need to introduce a "decision" in the flow:

In the "Outcomes" section you can define which outcome should fire which event or flow.
"Default outcome" is something that will be followed if no other match is found.
"closed won" I have introduced a new outcome here and determined based on the current stage of the opportunity in the conditions.

3.Create Email Template "Classic Email Template":

We hit a snag!!

We need to understand the 2 ways we can send an email using the Flow.

1.Using the Flow Action's "Send email Core Action":

This is the easiest and quickest way to send an email. However, Salesforce has a strict rule to include "Recipient ID" when using Email Template. and "Recipient ID" can only be "Lead, Contact or person account", while I want to send the email to Opportunity owner.

2.Using the "Email Alert":

"Email Alerts" are part of Salesforce Process automation and can be set up on any type or object, even custom objects. We can also define the Email template we want to use and the and can also select Recipients. Thus, getting rid of the limit we faced in the Flow action and can directly use the Email alert in the flow. We need to create another action for "Closed won opportunity" selecting the "Closed won email template" and adding recipient as above.

Continue the flow creation:

4.We can now go back to the flow we were working on and can now add "Send Email Alert":

This is also a straightforward way to send an email alert. We just need to make sure to select "Record ID" so that it can be used inside the "Email Template Merge Fields".

And that's it, at the end, your flow should look something like the below:

-Make sure you debug and save the flow. You also need to activate the flow to make sure the record change will trigger this flow.

Output

Now, Whenever you Create a new opportunity and/or update the stage on the current opportunity you receive an email like below:

Conclusion:

Salesforce Flow offers a powerful and low-code solution for automating tasks like sending emails based on record changes. By leveraging Flows, you can streamline processes and improve efficiency compared to traditional coding methods.

Reference:

1.Flow Builder Basics Trailhead
2.Salesforce Geek on Youtube

Leetcode: 624. Maximum Distance in Arrays

Priyank Sevak — Sat, 21 Sep 2024 02:55:16 +0000

Problem Statement 624. Maximum Distance in Arrays

You are given m arrays, where each array is sorted in ascending order.

You can pick up two integers from two different arrays (each array picks one) and calculate the distance. We define the distance between two integers a and b to be their absolute difference |a - b|.

Return the maximum distance.

My Thought Process

As the subarrays are sorted in ascending order, the first element will always be smallest and the last element will always be the largest. I came up with below algorithm:

Mark the first element of the first subarray as min. and the last element of the first subarray as max.
iterate over the array and check if the current subarray's first element is smaller than our min and the last element of the current subarray is higher than our max. replace min and max accordingly.
return the difference between max and min.

My algorithm mainly succeeded but failed for the test case like below.

[[1,4],[0,5]]

as you can see for our algorithm we are replacing min and max based on the current subarray and if both min and max elements exist in the same array we are returning incorrect answers as the problem statement specifically asks to choose elements from 2 Different arrays.

I updated my algorithm as below:

Mark the first element of the first subarray as min. and the last element of the first subarray as max.
iterate over the array and mark the current subarray's first element as localMin and the last element as localMax.
find the difference between localMax and min, the difference between max and localMin. this will give us 2 absolute differences between 2 separate subarrays. i.e. for [[1,2,3],[4,5]] this will be 4 and 1 respectively we need to select the maximum difference between these 2.
find the maximum between the above calculated max difference and the previously calculated result. set the result to whichever is higher.
return the result.

Output

Time and Space complexity

Time Complexity: we iterate over all the elements in the array and can directly access the first and last elements and don't need to iterate inside the subarrays. so the time complexity will be O(n)

Space Complexity: O(1) as we do not need any additional space.

DevOps: Understanding Process Monitoring on Linux

Priyank Sevak — Thu, 19 Sep 2024 15:22:04 +0000

As a DevOps engineer, ensuring system stability and performance is crucial. Occasionally, processes can go rogue, causing resource bottlenecks or unexpected behavior. Identifying these problematic processes requires effective monitoring techniques. Here's where Bash scripting and process monitoring tools like ps and lsof come in handy!

Understanding Linux Process:

In Linux, everything that you run/use is a type of file. As soon as you start your system, the kernel creates an init process, which every other process forks from.

We need a forked system call to create/fork a new process. These new processes can be created as a child of an existing process.

Suppose we have an existing child process. The child process will let the kernel know by setting its terminal status to 0. The parent needs to acknowledge the termination of the child process using something called a wait call. After all, we need the parent process to know that a child process has died. This exact operation can lead us to 2 possible issues:

1.Orphan process:

What happens if the parent process is exited/terminated before the child process? The children's process is left an orphan and is transferred over to the init process and marked as "orphan". These processes now wait for wait call from init to be terminated.

2.Zombie process: 🧟

What is a zombie? someone who is mindlessly running trying to eat human brains!! A MANACE. A zombie process is something similar, A process has gone zombie when the child process is terminated but the parent process has not called for wait call yet.

A zombie process' resources are freed up. However, the process still appears in the ps table. You can't manually kill the zombie process, the entry of this process is cleared when the parent process eventually makes the wait call.(Just like a real-world zombie you need to shoot it twice, in our case the second bullet needs to come from the parent process).

Command use and output:

Linux provides us with an in-built package called procps which contains useful tools such as ps, top, iostat, etc. to help us in performance and process monitoring. I will discuss a couple of them here which are used for performance monitoring.

1.ps

ps aux

a - list all processes even owned by other users
u - list more details regarding the process
x - list process that doesn't have TTY associated with them.

2.top

Do you want to know which thread is consuming how much CPU, and memory? Which user or group executed the thread?

The top command provides a dynamic real-time view of a running system. It can display a various type of information, such as from list of tasks currently being managed, Memory and CPU utilized by the current process, etc.

as displayed above running top would list:
The top part of the top command displays a summary of the current process running on the kernel.

PID (Process ID) - The task's unique process ID.
USER - Task owner's username.
PR - Scheduling priority of the task.
NI - Nice value - A bit confusing but it simply shows the priority of the task within the same autogroup. A positive value means lower priority and a negative value means higher priority.
VIRT - Virtual memory size - The total amount of virtual memory used by the task.
RES - Resident memory size - Non-swapped physical memory a task is currently using.
SHR - Shared memory size - Part of RES which can be utilized by other process.
S - Process status.
- D - Uninterruptible sleep
- I - Idle
- R - Running
- S - Sleeping
- T - Stopped by job control signal
- t - Stopped by debugger during trace
- Z - Zombie
- %CPU usage
- %MEMORY usage
- TIME - CPU time.
- COMMAND - Command name or command line.

Everything is a file

One of the core principles of Linux is that everything is treated as a file. This means that not only traditional files like documents and images but also devices, network connections, and even processes are represented as files within the operating system. This unified approach simplifies system management and provides a consistent interface for interacting with various system components. By treating everything as a file, Linux allows for a more flexible and efficient way to handle and manipulate different types of resources.

lsof helps us to narrow down current open files (running process) and we can even sort it based on the ports, user, ipv4, ipv6, etc. The best way to learn about them is to use them. Here's the best resource I found: lsof cheatsheet

Real world example:

Problem statement:

Imagine your server experiences performance issues. Users complain about slow applications, and resource usage is through the roof. You suspect a single process is to blame, but pinpointing it can feel like searching for a needle in a haystack.

Assumptions & lab setup

Before I go over the solution. Just as part of the setup in the lab environment, I have created a python code that runs infinitely generating some random numbers using the code below, This is just to create a process that is actually eating up a bunch of resources:

import time
import random

def calculate_something_complex():
    # Simulate a computationally intensive task
    result = 0
    for i in range(10000000):
        result += random.random()
    return result

def long_running_task():
    while True:
        result = calculate_something_complex()
        print(result)
        time.sleep(1)

if __name__ == "__main__":
    long_running_task()

Before going any further we must define a basic flow of the solution:

Determine how to find which is the process eating up most of the resources? - using top will be a very straightforward approach as it is purposefully used to list processes that are using most of the resources.
We do not only need the process ID but also list the files it is running to determine what can be the root cause. - lsof is your answer to do this.
We also need to be able to perform this task multiple times and probably automated based on a CRON job. - Writing a bash file that can be executed easily is a good option.

Solution & Explaination:

Here's the code I came up with to get the CPU-intensive task and list the open files under that PID.

#!/bin/bash

find_cpu_hog() {
top -b -n 1 | grep -A99 PID | grep -v COMMAND | head -n 1 | awk '{print $1}'

}

list_open_files() {
  pid="$1"
  lsof -p "$pid"
}

main() {
  cpu_hog_pid=$(find_cpu_hog)
  echo "$cpu_hog_pid"   

  if [ -z "$cpu_hog_pid" ]; then
    echo "No high CPU processes found."
    exit 0
  fi

  list_open_files "$cpu_hog_pid"
}

main

I believe the most important code above is

top -b -n 1 | grep -A99 PID | grep -v COMMAND | head -n 1 | awk '{print $1}'

Basically, what I am trying to do is get the top and manipulate it's result to get the process Id. Here's how in detail:

top -b -n 1: this will get the CPU intensive process by running the top command in a batch.
grep -A99 PID:

if you have ran the top command before you know that the top provides a very useful info. such as uptime, tasks, %CPU usage etc. read more here: What the first five lines of Linux’s top command tell you

So to omit that data and only get the process table I am performing a grep on PID and by -A99 I am getting everything after that.

grep -v COMMAND: To omit the first line of the heading in the process table.
head -n 1: getting only the first line, Most CPU-intensive process.
awk '{print $1}': getting the first argument of the output, PID.

Running the above code with the Python script running in the background I get the below result. Looking at the output we can determine that we have a Python code running which is CPU-intensive, we can also pinpoint the user who is performing this.

Corrections and comments are welcome.

DEV Community: Priyank Sevak

Building a PR Review Agent: My Transition from Learning Scripts to Real Tools (Phase 3)

What I Built: A PR Review Agent

Moving to an Agentic Framework

1. Tool Descriptions are Contracts

2. Single-Agent vs Multi-Agent

3. Splitting Up Tools Increases Reliability

What's Next

Building my first AI Agent from scratch (Phase 2)

What I Built

The Architecture

1. The Reasoning Engine (Gemini)

2. The Tool (analyze_code)

3. The Orchestrator (main.py)

What I Actually Learned

1. The LLM is too smart for your tools

2. Function declarations are the contract

3. Tool dispatch needs to be dynamic

4. Your agent needs memory

5. Tool results must go back to the LLM

6. Yes, 2 API calls when using a tool — and that's OK

What's Next

AI Agent VS Chatbot (Phase 1)

What is a Chatbot?

Introduction of LLMs

Introducing AI Agent

Here's how an agent work better than a chatbot

Agent Lifecycle

Tools at agent's disposal

Final Thoughts

System Design: Availability Patterns

Why Availability Patterns Matter

Factors Affecting System Availability

Measuring Availability:

Availability Patterns:

Fail-Over Pattern:

Disadvantages of Failover

Replication Pattern:

Conclusion

Salesforce: Leveling Up with Apex Testing

Benefits of Apex Testing:

The Solution - Diving into Apex Testing:

Sandbox Testing: A Clean Slate

Understanding Data Access:

Leveraging Test Data:

Benefits of Sandbox Testing:

Utilizing @testSetup:

Things to remember while using @testSetup:

Escape the Mothership

What I Built

RUN:

FIGHT:

Demo

Journey

Challenges and Learnings:

DevOps: Linux Performance Monitoring

TL;DR:

Performance Monitoring

1./proc

htop

atop

2.Where's my task manager?

3.Virtual Memory statistics: vmstat

4.System Activity Reporter: sar

Real world example:

Problem statement:

Assumptions & lab setup

Solution & Explaination:

Code explanation:

Getting the CPU usage:

Getting the Average system load:

Getting the Memory usage:

The output

Additional Performance Monitoring Tools:

Conclusion:

System Design: Consistency Patterns

TL;DR:

Distributed Systems

Consistency Patterns

Strong Consistency

Utilizing `@testSetup`:

Things to remember while using `@testSetup`:

1.`/proc`

`htop`

`atop`

3.Virtual Memory statistics: `vmstat`

4.System Activity Reporter: `sar`

`<dialog>` element

`<dialog>` element as Modal

`popover` API

Main difference between `popover` and `<dialog>` element