HN user

kbouck

525 karma
Posts1
Comments190
View on HN

my interest in this would be to customize the cleaning plan/logic... especially regarding traversing difficult carpets edges (which my roborock struggles with)

maybe something like:

  - this specific part of the carpet is the best place to enter onto it
  - once successfully on a carpet, stay on it until done cleaning it

That was my experience too. The experience with powerline ethernet adapters was unbearable on a daily basis.

We had an unused coax (which we disconnected from the outside world) and used MoCA adapters (actiontek) and it's been consistently great/stable. No issues ever... for years.

moving toward a world where coding isn't really about sitting down and grinding out syntax

Love the idea of "coding" while walking/running outside. For me those outside activities help me clear my mind and think about tough problems or higher level stuff. The thought of directing agents to help persist and refine fleeting thoughts/ideas/insights, flesh out design/code, etc is intriguing

I really like the nest encoder/button feel, so I was considering trying to hack mine into a becoming desktop volume control/button... but probably lacking the skills to not make a mess of it. Would love to see how you interface with the existing hardware!

didn't read article due to paywall, but the answer is most likely yes. i was able to build a basic 2-degrees-of-freedom robot-arm grabber using lego technic and power functions and was controlled by scratch on a raspberry pi. lego also has pneumatics.

Did same but for Asteroids. Had a working wireframe version after only a couple of prompts! I think using the term "Asteroids" in my original prompt was a bit of cheat/shortcut.

My lessons learned for prompting were to have project broken down into clearly defined modules (duh...), and to constantly feed the latest module source back in as context along with the prompts. This helps ground the responses to only adjust the code related to the prompt, and to not break stuff that was already working.

Proposed Solution 1 is preferable in that it accounts for both DB outage, slowness, and worker crash, and you describe additional safety mechanisms to prevent queue becoming blocked by poison/invalid messages.

Proposed Solution 2 without ACKs would be vulnerable to message loss if a worker were to crash before successful message delivery.

If you disable ARP, you can have a group of servers on the same network configured with the same IP! and if a server acting as a routing frontend can forward packets to a backend server's network interface by mac address (need a kernel extension for this trickery), that backend server will recognize itself as the destination, swap the source/dest IP and respond directly back to the client (without going back through the routing frontend)

Alternatively, you can accomplish the same without disabling ARP and by just adding the common IP address as an alias to the loopback interface, which allows the backend to recognize itself as the destination, but avoids ARP conflicts.

This was a trick used by IBM's WebSphere software load balancer back in the 90's-00's

When I'm stumped troubleshooting production problems, I try to think how I can get more information out of the system.

Exporting telemetry events with a wide set of attributes to an observability platform is a great approach which can provide an extensible way to expose additional information about the events.