mohd-faraz

_blogs

// blogs / 20260606.md

Dev Log: June 06 Wrap-up

2026-06-06
#java#crm#iot#arduino#refactoring

Overview

Today was one of those days where I felt like a digital plumber—lots of time spent making sure data flows through the pipes correctly without leaking. I spent the bulk of my time on some recursive logic for our CRM filters and finally fixed a nagging data gap in our deal conversion flow.

What I Worked On

Recursive Query Normalization

I’ve been digging into how we handle complex filters in our Leads module. We have this system for building database expressions, but it was struggling with deeply nested queries. I had to implement a way to recursively normalize these expressions so that whether a user is doing a simple search or a complex multi-condition filter, the backend processes it the same way.

It’s one of those things where you have to be really careful with logical operators like AND and OR to make sure you aren't accidentally breaking the query tree. Seeing the complex filters finally resolve correctly was a huge relief.

The Missing Partner Data

While I was looking at how Customers convert into Deals, I noticed we were dropping the PartnerName. We had the ID, the country, and the phone number (which I fixed yesterday), but for some reason, the name wasn't tagging along for the ride. It’s a tiny change in the decorator, but it saves the sales team from having to look up IDs manually in a different table.

// Ensuring the deal record captures all relevant partner metadata
target_record.set_partner_id(source_record.get_partner_id());
target_record.set_partner_name(source_record.get_partner_name());
target_record.set_contact_info(source_record.get_contact_info());

service.save_updated_record(ctx, target_record);

IoT Maintenance: HomeAlone

On the personal side, I did a quick update to my HomeAlone project. After running the device for a few weeks, I noticed it occasionally gets into a weird state with the network. Instead of hunting down every tiny memory leak or connection quirk in the libraries I'm using, I took the pragmatic route: a daily scheduled reboot.

I added a small check against the NTP time to trigger a restart at 6:00 AM IST. It’s a bit of a "brute force" fix, but for an IoT device, it's often the best way to keep things fresh.

void checkScheduledRestart() {
  if (restartFlag) return;

  struct tm timeInfo;
  if (!getLocalTime(&timeInfo, 0)) return; 

  if (timeInfo.tm_hour == REBOOT_HOUR && timeInfo.tm_min == 0) {
    restartFlag = true;
    Serial.println("Daily maintenance reboot...");
    delay(1000);
    system_restart_call();
  }
}

Wrapping Up

Everything feels a lot more stable than it did at the start of the week. The CRM logic is more robust, and my home automation shouldn't need a manual power cycle anymore. Tomorrow, I’m planning to look more into the reporting engine performance. Catch you then.