DEV Community: Dyami Connell

Hey: The Surprisingly Deep Art of Saying Hello in Software Systems

Dyami Connell — Mon, 20 Apr 2026 04:03:23 +0000

When was the last time you thought deeply about a greeting? In human conversation, "hey" is effortless — a throwaway syllable that opens a channel of communication. But in software systems, that simple act of saying hello is one of the most architecturally significant moments in any interaction. The humble greeting encapsulates authentication, protocol negotiation, state initialization, and connection management all at once.

This article dives deep into the mechanics of "saying hello" in software — from TCP handshakes to API health checks, from WebSocket upgrades to distributed system heartbeats. By the end, you'll never look at a simple greeting the same way again.

The TCP Handshake: The Original "Hey"

Before any web request, API call, or WebSocket message, two machines have to formally introduce themselves. This is the TCP three-way handshake — arguably the most important "hey" in all of computing.

Client                          Server
  |                               |
  |-------- SYN (Hey!) --------->|
  |                               |
  |<------ SYN-ACK (Hey back!) --|
  |                               |
  |-------- ACK (Cool, let's talk)|
  |                               |

The process goes like this:

SYN: The client sends a synchronization packet. "Hey, I want to talk. Here's my initial sequence number."
SYN-ACK: The server acknowledges and responds with its own sequence number. "Hey back! Got your number, here's mine."
ACK: The client acknowledges the server's sequence number. "Perfect. Let's communicate."

This seemingly simple exchange establishes something profound: a reliable, ordered, bidirectional channel. Each side knows the other is alive, reachable, and ready.

In modern TLS connections, this greeting becomes even more elaborate:

import ssl
import socket

# Python demonstrates the layers of "hello" involved in a secure connection
context = ssl.create_default_context()

with socket.create_connection(("example.com", 443)) as sock:
    with context.wrap_socket(sock, server_hostname="example.com") as ssock:
        print(f"Protocol negotiated: {ssock.version()}")
        print(f"Cipher suite chosen: {ssock.cipher()}")
        # Only NOW can we actually say hello at the application layer
        ssock.sendall(b"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n")

After the TCP handshake, TLS adds a ClientHello and ServerHello — yes, those are the actual names in the specification. Each hello carries capabilities, supported cipher suites, and certificates. The protocol was literally designed around the concept of greeting.

Health Checks and Heartbeats: Saying "I'm Still Here"

In distributed systems, the greeting doesn't happen just once. Systems need to continuously reassure each other that they're alive. This is where health checks and heartbeat mechanisms come in.

A basic HTTP health check endpoint is one of the first things you should build into any service:

// Express.js health check endpoint
const express = require('express');
const app = express();

app.get('/health', (req, res) => {
  const healthData = {
    status: 'ok',
    timestamp: new Date().toISOString(),
    uptime: process.uptime(),
    environment: process.env.NODE_ENV,
    version: process.env.APP_VERSION || '1.0.0',
    dependencies: {
      database: checkDatabaseConnection(),
      cache: checkCacheConnection(),
      messageQueue: checkQueueConnection()
    }
  };

  const isHealthy = Object.values(healthData.dependencies)
    .every(dep => dep.status === 'ok');

  res.status(isHealthy ? 200 : 503).json(healthData);
});

function checkDatabaseConnection() {
  try {
    // Perform a lightweight query
    db.query('SELECT 1');
    return { status: 'ok', latency: db.lastQueryTime };
  } catch (err) {
    return { status: 'error', message: err.message };
  }
}

Kubernetes uses this concept extensively through liveness and readiness probes:

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: my-service
      image: my-service:latest
      livenessProbe:
        httpGet:
          path: /health/live
          port: 8080
        initialDelaySeconds: 10
        periodSeconds: 5
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /health/ready
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 3

The distinction between liveness ("Am I alive?") and readiness ("Am I ready to receive traffic?") is a masterclass in nuanced greeting design. A service can be alive but not yet warmed up — just like a person who's awake but not ready to take your call.

WebSockets: The Greeting That Changes Everything

HTTP is inherently a request-response protocol — it's like sending letters. WebSockets, on the other hand, open a persistent, bidirectional channel. But to get there, you first need a very special greeting: the WebSocket upgrade handshake.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

The server's 101 Switching Protocols response is one of the most dramatic status codes in HTTP — it literally says "the rules of our conversation are changing." That initial HTTP greeting bootstraps an entirely different protocol.

Here's a practical implementation showing how to handle this gracefully:

import { WebSocketServer, WebSocket } from 'ws';
import { IncomingMessage } from 'http';

const wss = new WebSocketServer({ port: 8080 });

interface Client {
  id: string;
  socket: WebSocket;
  connectedAt: Date;
  lastHeartbeat: Date;
}

const clients = new Map<string, Client>();

wss.on('connection', (ws: WebSocket, req: IncomingMessage) => {
  const clientId = generateId();
  const client: Client = {
    id: clientId,
    socket: ws,
    connectedAt: new Date(),
    lastHeartbeat: new Date()
  };

  clients.set(clientId, client);

  // The first message after "hey" - send the client their identity
  ws.send(JSON.stringify({
    type: 'WELCOME',
    clientId,
    timestamp: new Date().toISOString(),
    message: 'Hey! Connection established successfully.'
  }));

  // Set up heartbeat
  const heartbeatInterval = setInterval(() => {
    if (ws.readyState === WebSocket.OPEN) {
      ws.ping();
    }
  }, 30000);

  ws.on('pong', () => {
    client.lastHeartbeat = new Date();
  });

  ws.on('close', () => {
    clearInterval(heartbeatInterval);
    clients.delete(clientId);
    console.log(`Client ${clientId} said goodbye.`);
  });
});

Notice how even after the connection is established, we immediately send a WELCOME message. This is an application-level hello layered on top of the protocol-level hello — greetings all the way down.

gRPC and Protocol Buffers: The Strongly-Typed Hello

REST APIs say hello in plain, human-readable JSON. But gRPC takes a different approach — its greetings are strictly typed, compiled, and efficient. The canonical example in every gRPC tutorial is, fittingly, a greeting service:

// hello.proto
syntax = "proto3";

package hello;

service Greeter {
  // Unary: simple hello
  rpc SayHello (HelloRequest) returns (HelloReply);

  // Server streaming: hello that keeps talking
  rpc SayHelloStream (HelloRequest) returns (stream HelloReply);

  // Bidirectional streaming: conversation
  rpc Chat (stream HelloRequest) returns (stream HelloReply);
}

message HelloRequest {
  string name = 1;
  string language = 2;
  map<string, string> metadata = 3;
}

message HelloReply {
  string message = 1;
  string server_id = 2;
  int64 timestamp = 3;
}

# gRPC server implementation
import grpc
import hello_pb2
import hello_pb2_grpc
from concurrent import futures
import time

class GreeterServicer(hello_pb2_grpc.GreeterServicer):

    def SayHello(self, request, context):
        greetings = {
            'en': f'Hey, {request.name}!',
            'es': f'¡Hola, {request.name}!',
            'fr': f'Salut, {request.name}!',
            'de': f'Hallo, {request.name}!',
        }

        message = greetings.get(request.language, f'Hey, {request.name}!')

        return hello_pb2.HelloReply(
            message=message,
            server_id='server-001',
            timestamp=int(time.time())
        )

    def SayHelloStream(self, request, context):
        for i in range(5):
            yield hello_pb2.HelloReply(
                message=f'Hey {request.name}, message {i+1} of 5',
                server_id='server-001',
                timestamp=int(time.time())
            )
            time.sleep(1)

def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    hello_pb2_grpc.add_GreeterServicer_to_server(GreeterServicer(), server)
    server.add_insecure_port('[::]:50051')
    server.start()
    print("gRPC server started — ready to say hey on port 50051")
    server.wait_for_termination()

The gRPC greeter is deliberately chosen as the "Hello World" of RPC frameworks because it perfectly encapsulates what the framework is for: establishing a typed, efficient, reliable communication channel between services.

Practical Conclusion: Design Your Greetings Intentionally

Every layer of your software stack has a concept of "hey" — and each one carries critical information and establishes important contracts. Here are the key takeaways to bring into your next project:

1. Make health checks meaningful, not ceremonial.
A /health endpoint that just returns 200 OK is better than nothing, but an endpoint that validates your database connection, cache availability, and downstream dependencies is genuinely useful. Design your health checks to reflect real readiness.

2. Never neglect the handshake.
Whether you're building a WebSocket server, a gRPC service, or a custom TCP protocol, invest time in the connection establishment phase. This is where you negotiate capabilities, authenticate clients, and set expectations.

3. Heartbeats are mandatory in distributed systems.
Silence doesn't mean success — it might mean failure. Implement heartbeat mechanisms in any long-lived connection, and define what you'll do when a heartbeat is missed.

4. Layer your hellos appropriately.
A TLS connection has a TCP hello, a TLS hello, and then an application-level hello. Don't try to collapse these — each layer serves a distinct purpose. Respect the separation of concerns.

5. Your first message sets the tone.
When a WebSocket connection opens or a new gRPC stream begins, the first message you send should orient the client: their session ID, server capabilities, protocol version, and anything else they need to participate effectively.

The next time you type "Hey" in a Slack message, take a moment to appreciate the dozens of protocol handshakes, heartbeats, and health checks that made that single word possible. In software, as in life, a good greeting is the foundation of everything that follows.

What's your favorite "hello" in software? Drop a comment below — I'd love to hear about interesting connection protocols or handshake implementations you've encountered in the wild.

Vibe Coding Is Genuinely Incredible (But Let's Talk About the Business Model Problem Too)

Dyami Connell — Mon, 20 Apr 2026 03:57:51 +0000

The future of software development has arrived, and it looks nothing like what we expected. Instead of meticulously typing every semicolon and debugging stack traces at 2am, a growing wave of developers — and even non-developers — are building real, functional, deployed applications by simply describing what they want. This is vibe coding, and if you haven't tried it yet, your mind is about to be thoroughly blown.

But here's the thing: as someone who has been deeply impressed by these tools, I also think we need to have an honest conversation about the business practices surrounding them. Because being a fan of the technology doesn't mean we should be uncritical cheerleaders for every decision these companies make. The best developer communities hold their tools accountable, and that's exactly what we're going to do today.

What Even Is Vibe Coding?

The term "vibe coding" was coined by Andrej Karpathy earlier in 2025 and it immediately resonated with a massive audience because it perfectly captures a real phenomenon. The idea is beautifully simple: you describe your application in natural language, the AI builds it, you iterate by describing what you want changed, and you largely ignore the underlying code. You go by the vibe of what you're building.

This sounds like heresy to classically trained engineers. But the results are genuinely hard to argue with.

Tools like Lovable, Bolt.new, Cursor, and v0 by Vercel have made it possible to go from zero to a deployed, functional web application in under an hour without writing a single line of code yourself. For prototyping, for MVPs, for solo founders, for designers who want to test an idea — this is transformative.

Here's a classic example of the kind of prompt that might generate an entire application:

Build me a full-stack task management app with:
- User authentication
- A dashboard showing tasks by priority
- The ability to assign due dates and tags
- A clean, minimal UI using shadcn components
- Supabase as the backend
Deploy it and give me the live URL.

That prompt, in Lovable, will genuinely produce something functional. Not a mockup. Not a wireframe. A real, deployed application with authentication, a database, and a live URL. That's wild. That's the technology we've always dreamed about.

Why Lovable Specifically Stands Out

Let me be direct: Lovable (formerly GPT Engineer) is genuinely one of the most impressive pieces of software I have encountered in years of working in tech. The quality of the generated code, the way it handles multi-file projects, its understanding of modern React patterns, its Supabase integration, its ability to take screenshots and fix visual bugs — it's exceptional.

The product experience of iterating on an application by just talking to it is addictive. You find yourself thinking about problems differently. Instead of asking "how do I implement this?" you ask "what do I actually want this to do?" That cognitive shift is valuable even if you go back to writing code manually afterward.

The generated code isn't garbage either. It produces typed TypeScript, follows component architecture patterns, uses proper hooks, and integrates with real services. Developers can actually look at what was generated and learn from it:

// Example of the kind of typed, structured code Lovable generates
interface Task {
  id: string;
  title: string;
  priority: 'low' | 'medium' | 'high';
  dueDate: Date | null;
  tags: string[];
  completed: boolean;
}

const useTaskManager = () => {
  const [tasks, setTasks] = useState<Task[]>([]);

  const addTask = async (newTask: Omit<Task, 'id'>) => {
    const { data, error } = await supabase
      .from('tasks')
      .insert([{ ...newTask, id: crypto.randomUUID() }])
      .select();

    if (error) throw error;
    setTasks(prev => [...prev, data[0]]);
  };

  return { tasks, addTask };
};

That's clean. That's readable. That's something a junior developer could extend and learn from. The tool is genuinely good, and I want to be clear about that before moving into criticism.

The Credits Problem: When Deceptive Design Erodes Trust

Now we need to talk about the part that genuinely angers me, because I think it's important and the developer community shouldn't just shrug it off.

I lost $400 in credits on Lovable. Not because I misused the platform. Not because I made a purchase mistake I understood at the time. Because the credits expired, and the expiration policy was not communicated clearly, prominently, or repeatedly. By the time I noticed, the credits were simply gone.

This is not a minor UX quibble. This is a pattern in SaaS pricing that has a name: dark patterns. Specifically, this falls into the category of hidden costs and terms — a design approach where the unfavorable conditions of a purchase are technically disclosed but buried, minimized, or otherwise obscured so that a normal, reasonable user would not notice them until it was too late.

Let's think about this from a pure product ethics standpoint:

ETHICAL CREDIT SYSTEM DESIGN:
✅ Expiration date shown prominently at purchase
✅ Remaining credits visible on every session
✅ Email warnings at 30 days, 7 days, 1 day before expiry
✅ In-app banner notifications as expiry approaches
✅ Option to extend or convert credits before loss
✅ Clear, plain-language terms in the checkout flow

WHAT ACTUALLY HAPPENED:
❌ Expiration buried in terms or fine print
❌ No prominent dashboard warning
❌ No proactive email sequence about expiring credits
❌ Credits silently vanished
❌ $400 gone with no recourse

The frustrating irony is that this doesn't even make good business sense. Lovable is a genuinely excellent product. If someone spends $400 with you and has a great experience, they will almost certainly spend more. They will tell their developer friends. They will write articles like this one recommending the platform. But when you silently drain $400 from someone's account? You lose not just that customer's future spend, but their advocacy, their trust, and — yes — you turn what would have been a glowing recommendation into a mixed review with a warning label attached.

Loyalty is earned. And you cannot earn loyalty through deception, even if it's technically legal deception buried in terms of service.

How Vibe Coding Fits Into a Real Development Workflow

Despite the frustration, I want to pivot back to something constructive, because vibe coding genuinely deserves a place in the modern developer's toolkit. The question isn't "should I use these tools?" — it's "where do they fit?"

Here's how I've seen the most effective developers integrate vibe coding:

1. Rapid Prototyping and Validation
Before writing a single line of production code, spin up a vibe-coded prototype to validate the concept with real users. This can replace weeks of design and development with hours.

2. Boilerplate Elimination
Auth systems, CRUD interfaces, admin panels, landing pages — all of this can be vibe-coded and then refined by hand. Let the AI handle the scaffolding, let the engineer handle the differentiation.

3. Learning by Reading Generated Code
For newer developers, vibe coding tools can be powerful learning accelerators. Generate a working example, then read through it and understand why each piece works.

# A practical vibe coding workflow
1. Describe your full application concept to Lovable/Bolt
2. Get a deployed prototype in under an hour
3. Download or connect to the GitHub repo
4. Review the generated code structure
5. Identify what needs custom logic vs what's fine as-is
6. Hand-code only the truly differentiated pieces
7. Use the AI tool for continued iteration on standard features

4. Solo Founders and Indie Hackers
If you're building alone, vibe coding can effectively give you the output of a small team for the standard, repeatable parts of your application. This is a genuine competitive advantage for early-stage products.

What We Should Demand From AI Development Tools

The technology is exciting. The business practices sometimes aren't. As a developer community, we have both the voice and the leverage to push back. Here's what fair, developer-respecting AI tools should look like:

Transparent pricing with zero hidden gotchas. If credits expire, that should be impossible to miss at the point of purchase and throughout usage.
Proactive communication about usage and limits. We should never discover something has expired. We should be warned aggressively before it happens.
Credit extensions or rollover policies. Unused credits that vanish are a consumer trust killer. Offer to roll them over, apply them to a subscription, or at minimum give significant notice.
Responsive support for pricing disputes. When a customer comes to you having lost significant money due to unclear terms, treating them well costs you almost nothing and retains a customer. Treating them poorly is a PR disaster in slow motion.

The best developer tools win long-term through genuine product quality and community trust — not through extracting maximum value from confusion. Stripe, Vercel, Supabase, GitHub — the developer tools that have achieved true loyalty did so by being transparent, generous, and developer-first in their thinking.

Conclusion: Vibe Coding Is the Future, But We Deserve Better Business Practices

Here's where I land after all of this: vibe coding is real, it's impressive, and it's going to fundamentally change who can build software and how fast they can build it. Lovable is one of the best implementations of this technology available today, and the core product genuinely deserves the excitement it has generated in the community.

And also: losing $400 to unexplained, unexpired, silently disappearing credits is not okay. Both things are true at the same time.

We should enthusiastically adopt tools that make us more productive. We should recommend tools that genuinely impress us. And we should be loud and clear when the business practices of those tools fall short of what we deserve as paying customers. The two are not in conflict.

If you're going to try Lovable or any similar platform — and you absolutely should — go in with eyes open. Read the credit terms carefully. Set your own calendar reminders for when credits expire. Screenshot your purchase confirmation. Don't rely on the platform to protect you from losing money, because as I learned the hard way, that protection may not be there.

Build cool things. Use incredible tools. And demand that the companies behind those tools treat you with the same respect you bring to your craft.

Have you had experiences — good or bad — with vibe coding platforms? Drop them in the comments. The more we share transparently, the better informed our community becomes.

Vibe Coding: A Workflow Guide (From Zero to SaaS)

Dyami Connell — Sat, 18 Apr 2026 19:11:22 +0000

A few months ago, I had zero coding skills and zero dollars from my own online project. Today, I've crossed the $1,000 mark with my side project protooltrack.com — and I owe almost all of it to vibe coding.

If you haven't heard the term yet, vibe coding is the practice of building software by describing what you want in plain English to an AI assistant, iterating on the output, and shipping fast — without needing to master every line of code yourself. It's messy, it's fun, and apparently it works.

Here's the full story.

The Idea: ProToolTrack

I work in construction, and one problem I kept running into was tracking expensive power tools. Who has the drill? Where's the laser level? When does that compressor need servicing? Spreadsheets were a nightmare, and the existing apps felt like overkill.

So I thought: what if there was a simple, no-fuss tool tracking app for small contractors and tradespeople?

That became ProToolTrack — a web app where you can log your tools, assign them to team members, and get reminders when maintenance is due.

The Build: Pure Vibe Coding

I had dabbled in HTML back in the day, but I couldn't have built a full-stack web app on my own. So I leaned entirely into AI-assisted development.

My workflow looked like this:

1. Describe the feature, get the code
I'd open up an AI coding assistant and literally say things like: "Build me a form where a user can add a tool with a name, serial number, category, and assigned team member." It would spit out React components, database schema suggestions, API routes — the works.

2. Paste, run, break, fix
I'd paste the code, run it, inevitably hit an error, paste the error back into the AI, and get a fix. Rinse and repeat. It felt more like conducting than coding.

3. Ship early, iterate fast
I launched with just three features: add a tool, assign it to someone, and mark it as returned. That was it. No fancy dashboard, no analytics, just a working MVP.

Getting to $1,000

The money didn't come overnight. Here's how it broke down:

Month 1 — $0: I launched quietly and shared the project in a few subreddits (r/Entrepreneur and r/SideProject). Got some encouraging feedback but no paying customers yet.
Month 2 — $147: I added a simple $9/month subscription tier and announced it to the small email list I'd built. A handful of early supporters signed up.
Month 3 — $389: Word started spreading in a Facebook group for small contractors. A few guys tried it, liked it, and told their crews.
Month 4 — $464 more: By month four, I crossed the $1,000 total mark. Nothing viral, just steady growth from people genuinely finding it useful.

What Vibe Coding Actually Feels Like

Honestly? It's humbling and exciting at the same time.

There were moments where I had no idea why a piece of code worked — I just knew it did. That felt weird at first. But I got over it. A contractor doesn't need to understand the metallurgy of their drill bits; they need to know how to build a deck.

The real skill with vibe coding isn't writing prompts — it's judgment. Knowing when the AI is steering you wrong, when to push back, when to ask for a simpler solution, and when to just ship the thing.

Some lessons I picked up:

Start with the simplest possible version. The AI will suggest features you don't need. Resist.
Keep your prompts focused. One feature at a time. Vague prompts produce vague code.
Don't skip testing. Use the app yourself, daily. You'll find bugs faster than any automated test.
Talk to users early. Real feedback beats imagined features every time.

The $1,000 Is Just the Beginning

I'm not going to pretend $1,000 is life-changing money. But it validated something important: a real problem, a real product, real people paying for it.

I'm now working on a mobile-friendly version, team dashboards, and barcode scanning for quick tool check-in/check-out. All vibe coded, of course.

If you're sitting on an idea and waiting until you "know how to code" — stop waiting. The tools are here. The barrier is lower than it's ever been.

Just start vibing.

Have you tried vibe coding for your own projects? I'd love to hear your experience in the comments. And if you're in the trades and want to try ProToolTrack, check it out at protooltrack.com — there's a free tier to get you started.

How I Built a Custom Search Engine for Browning Motor Sheaves

Dyami Connell — Fri, 16 Jan 2026 18:38:02 +0000

The Problem
I work in HVAC Test & Balance (TAB). A big part of the job is identifying specific pulleys (sheaves) on rooftop units to adjust fan speeds.

The old way involved carrying a physical catalog, measuring the part with calipers, and then manually flipping through pages to find a match. If the measurement was slightly off, or the catalog was missing a page, you were stuck guessing.

I realized I could speed this up significantly if I just had a digital database I could search from my phone.

The Build: The "Browning" Engine
I built TestAndBalance.xyz, a simple web app that replaces the catalog.

Here’s how I broke it down:

The Database: I needed the data first. I digitized the specs for over 2,000 Browning sheaves, mapping the physical dimensions (Outside Diameter, Pitch) to the actual Part Numbers and Bore sizes. Now, instead of a book, I have a queryable dataset.
The Search Logic: Field measurements are rarely perfect. A sheave might be rusted, or the angle might be awkward. I set up the search to handle a bit of variance.

If I input 3.4, the logic searches a range (like 3.35 to 3.45) to find the closest valid part number. It acts as a "fuzzy search" for hardware.

The Hardware Interface (Calipers) Since this tool relies on physical inputs, I still need to carry calipers. The software is only as good as the measurement I type in. It helps confirm I'm looking at a "3V" belt profile vs an "A" profile, which is hard to tell by eye but obvious when you measure it.

The Physics Layer
To make it more than just a lookup tool, I added the Fan Laws (fluid dynamics formulas) into the frontend.

When I select a new sheave size, the app automatically calculates the resulting Brake Horsepower (BHP). Since power increases with the cube of speed, a small change can ramp up power usage fast. The app flags the new BHP so I can verify it’s safe for the motor before I even order the part.

Summary
I built this because I wanted a tool that fit my specific workflow. It’s a PWA, so it loads instantly on a job site, and it saves me a few hours of manual lookup time every week.

If you’re interested in automation for the trades or just want to see how it works, you can check it out here: TestAndBalance.xyz

I’m Dyami Connell, an HVAC TAB Technician.

Hacking the Trades: Why I Chose Python for HVAC Field Automation

Dyami Connell — Thu, 01 Jan 2026 04:02:03 +0000

By Dyami Connell

I recently wrote a breakdown of how I built the frontend interface of my tools using JavaScript (you can read that on my Dev.to profile here: [LINK TO YOUR DEV POST]).

But today, I want to talk about the backend—the heavy lifting.

As a TAB (Testing, Adjusting, and Balancing) Technician, the math I deal with isn't just "A + B." It involves fluid dynamics, fan laws, and air density corrections that change based on altitude and temperature.

While JavaScript handles the web interface, I turned to Python to handle the actual engineering logic.

The Problem: The "Bay Area" Factor Here in San Francisco, we deal with microclimates. One job site is at sea level; another is in the hills. Standard calculators often ignore Air Density ratios, which can throw a balance report off by 5-10%.

The Python Solution I built a simple Python library for TestAndBalance.xyz that standardizes these corrections.

Fan Laws: It iterates RPM/BHP changes instantly.

Data Handling: Python allows me to eventually pump this data into Excel or PDF reports using libraries like pandas (something I'm working on now).

Why Open Source Matters for Trades Most HVAC software is proprietary and expensive. I believe the basic math of our trade should be free. By using open-source languages like Python and JS, we can build tools that are accessible to every apprentice and journeyman in the field.

Check out the tools live at TestAndBalance.xyz or view my full portfolio at dyamiconnell.com.

How I Automated HVAC Field Calculations with JavaScript (No more paper)

Dyami Connell — Thu, 25 Dec 2025 00:54:06 +0000

I work as a TAB (Testing, Adjusting, and Balancing) Technician in the HVAC industry.

One of the biggest pain points in the field is doing repetitive math for duct traverses while standing on a ladder. The standard industry formulas (NEBB/AABC) aren't complicated, but doing them on a phone calculator leads to human error.

The Problem Existing apps are either expensive, require a login (impossible in dead zones), or are filled with ads.

The Solution I decided to build my own lightweight tool using React. It's a simple PWA (Progressive Web App) that handles:

Round Duct Traverses (Log-Tchebycheff method)

Rectangular Duct Grids

Zero data collection

The Stack

Frontend: React

Hosting: Netlify/Lovable

Logic: Custom JS for the fluid dynamics formulas.

You can try the live demo here: TestAndBalance.xyz

I'm currently working on a Python script to take these inputs and auto-generate the PDF reports we send to clients.

If you are in the trades and interested in how automation can help field work, check out my other projects at DyamiConnell.com.