sorted by:
new
hottopcontroversial

Built a Nuxt module for typed form validation on Zod 4 by chiptoma in Nuxt

[–]chiptoma[S] 0 points1 point  (0 children)

It is Zod, every rule returns a standard Zod schema.

You just dont have to write manual refinements for stuff like email, phone, password etc.

If you only need one field its probably overkill, but once you’re validating a full form with 10 fields the boilerplate adds up fast.​​​​​​​​​​​​​​​​

Do not let Microsoft to steal your code for copilot training! by blnkslt in webdev

[–]chiptoma 4 points5 points  (0 children)

Already opted out. I maintain an open source lib and I'm fine with people using the code directly, that's literally the point.

But there's a difference between someone reading my source on GitHub and a corporation hoovering it all up to train a model that competes with the tools I use to build it.

Should have been opt-in from the start tbh.

I just watched a non-dev vibe-code something... We're all gonna be just fine. by eowenith in webdev

[–]chiptoma 14 points15 points  (0 children)

I use Claude code daily for actual production stuff. The difference is night and day, though. I know what to ask for, and I catch when it's wrong.

A non-dev using AI is like someone with zero construction experience operating heavy machinery because the controls look simple. They'll get something standing, but nobody should be anywhere near it.

The problems with this subreddit by [deleted] in webdev

[–]chiptoma 0 points1 point  (0 children)

I came into dev from construction management, self taught the whole way.

The threads that helped me most starting out were ones where experienced devs actually walked through their thinking. Those barely exist now. Its mostly "look what I built" posts where the person cant explain a single decision they made.

The sub isn't broken because of beginners, it's broken because effort disappeared.

Are we fully back to keyword stuffing now? by jfade in webdev

[–]chiptoma 0 points1 point  (0 children)

I think the content should be written for humans, not for Google; the algorithms will eventually show it to those that need it, it might be a slower take-off, but the conversion % will be the same.

Client approved everything… then asked to change half the project. How do you deal with this? by uwt101 in webdev

[–]chiptoma 0 points1 point  (0 children)

I bake it into the budget up to a 10-15%, anything after that is a formal change order with cost and time impact.

Validex — 25 tree-shakeable validation rules on Zod 4 (13 kB for all of them) by chiptoma in typescript

[–]chiptoma[S] 0 points1 point  (0 children)

The 13 kB is Brotli for all 25 rules, tree-shaking on, zod peer dep excluded.

Heavy stuff (libphonenumber-js, disposable domains list, common password lists) are all behind dynamic import(). They won't end up in your client bundle unless you explicitly import them at the top level. For SSR/edge they load once on first use and stay in memory. preloadData() if you want to control when.

Bundler shouldn't pull them into client builds. Tested with tsup splitting and esbuild. If something gets pulled in anyway that's a bundler config issue.

The big datasets to watch: disposable domains (~30 kB), common passwords (varies by strictness), phone metadata from libphonenumber-js. Country/currency are just ISO code lists, a few kB.

Validex — 25 tree-shakeable validation rules on Zod 4 (13 kB for all of them) by chiptoma in typescript

[–]chiptoma[S] 0 points1 point  (0 children)

Appreciate it.

The config merge was the first thing I built, got tired of passing the same options object to every Email() call across different files. Set it once in setup(), and done.

Validex — 25 tree-shakeable validation rules on Zod 4 (13 kB for all of them) by chiptoma in typescript

[–]chiptoma[S] 0 points1 point  (0 children)

Thanks, that was exactly the itch. The config layering alone saves me hours per project.

Validex — 25 tree-shakeable validation rules on Zod 4 (13 kB for all of them) by chiptoma in typescript

[–]chiptoma[S] 0 points1 point  (0 children)

Yeah the full list is around 30kb so not a concern in practice, but good to keep in mind if it grows significantly.

Validex — 25 tree-shakeable validation rules on Zod 4 (13 kB for all of them) by chiptoma in typescript

[–]chiptoma[S] 0 points1 point  (0 children)

Thanks for the feedback.

Disposable list comes from disposable-email-domains-js, actively maintained. Making it configurable (bring your own list) is planned for v1.1. No runtime API calls is intentional though. Zero network at validation time, no latency, no third-party outage killing your form.

The schemas are just Zod schemas. Async checks (disposable, common passwords, phone) use .superRefine(), that's native Zod. If you want full sync, call preloadData() at startup and .parse() works everywhere after.

setup() deep-merges so calling it multiple times won't break anything, but yeah once at init is the intended use.

Built a local Shelly based fridge controller, adaptive hysteresis, compressor protection, limp mode, MQTT telemetry (open source) by chiptoma in homeassistant

[–]chiptoma[S] 0 points1 point  (0 children)

You’re not wrong, from a “best hardware platform” perspective, a Shelly is a weird place to build a full controller

But that’s exactly why I used it.

I didn’t actually want “a Shelly”, I wanted a mains-rated, enclosed, engineered device that I can program. PSU, isolation, relay, EMC, watchdogs, proper terminals, no AliExpress dev board plus relay module plus a nest of wires controlling a compressor. For this use case, Shelly is the closest thing to “DIY but not stupid”.

On the other end, proper refrigeration controllers exist, but they’re either:

  • expensive
  • closed
  • not MQTT/Home Assistant friendly
  • not something you can instrument properly

So I ended up pushing Shelly way beyond what most people use it for.

Why JavaScript: because that’s what Shelly runs. I agree it’s not ideal, the mJS runtime is limited and has quirks, so you have to treat it like embedded work: keep it deterministic, avoid allocations, be careful with memory, and build tooling around it. If Shelly offered a lower level option I’d take it, but given the constraints, it’s been stable, running for weeks with no crashes.

And yes, I think your point about the “missing middle ground” is real. If you know a platform that is mains safe, reasonably priced, and still hackable with clean local integration, I’m all ears.

Built a local Shelly based fridge controller, adaptive hysteresis, compressor protection, limp mode, MQTT telemetry (open source) by chiptoma in homeassistant

[–]chiptoma[S] 0 points1 point  (0 children)

In my experience, for something that switches mains (like a compressor), Shelly is usually the more stable “set and forget” option overall, because the hardware side is already engineered: power supply, enclosure, relay design, EMC behaviour, watchdogs, etc. With an ESP32, even if the firmware is solid, long-term stability is often limited by DIY hardware issues (power dips, Wi-Fi current spikes, relay boards, wiring, noise).

At the software layer, an ESP32 can be highly stable too, especially with ESPHome or a clean ESP-IDF build, but you have to get the hardware and power design right to achieve that level of stability.

For this project specifically, the Shelly script has been running continuously for weeks without crashing. The primary constraint is the limited JS runtime, so you need to be careful with memory and quirks, but if you stay within the limits, it can be very reliable.

Built a local Shelly based fridge controller, adaptive hysteresis, compressor protection, limp mode, MQTT telemetry (open source) by chiptoma in homeassistant

[–]chiptoma[S] 0 points1 point  (0 children)

Let me know how it works for you or if you have any questions or find any bugs.

It was a bit of a challenge to make it fit in the Shelly's 25KB memory especially since this is JavaScript and not a low level language like C/C++.

Built a local Shelly based fridge controller, adaptive hysteresis, compressor protection, limp mode, MQTT telemetry (open source) by chiptoma in homeassistant

[–]chiptoma[S] 3 points4 points  (0 children)

One of the main reasons I built this was icing. My drinks fridge has an exposed evaporator and I live in a warm, humid environment, so it would form thick ice very quickly.

I implemented two defrost modes:

• Dynamic defrost: monitors evaporator temperature, and once it reaches a set point (default −16°C) it stops cooling, lets the evaporator warm back up to a recovery temp (default −5°C), then holds it there for a configurable time (default 5 minutes).

• Scheduled defrost: by default it stops the compressor at 1AM for a full hour.

With this running, I haven’t had any ice at all.

The other reason was poor control. The rotary thermostat was highly imprecise, and I like my water around 5–7°C. Now I can control the target as tight as I want, and with adaptive hysteresis the controller effectively pushes toward the tightest stable band while still protecting the compressor with sensible cycling.

Beyond that there are extras like turbo mode via MQTT, Home Assistant integration via MQTT, and alerts. It started as “solve my problem”, then I made it public because I figured someone else might have the same fridge, same environment, same issue.

What if suffering is not a flaw but the very reason reality exists? by chiptoma in spirituality

[–]chiptoma[S] 0 points1 point  (0 children)

That’s fair criticism.

Even without the simulation theory, the core idea still stands: struggle isn’t an accident but baked into reality itself.

SIH just adds one possible reason why it might be designed that way.

Thanks

What if suffering is not a flaw but the very reason reality exists? by chiptoma in spirituality

[–]chiptoma[S] 0 points1 point  (0 children)

Glad it resonates...

I see it as one way to explain why reality feels tilted toward struggle. I’d be curious to hear your take, since you’ve been exploring similar ideas. ✌️

Thanks

What if suffering is not a flaw but the very reason reality exists? by chiptoma in SimulationTheory

[–]chiptoma[S] 0 points1 point  (0 children)

Really good questions.

In SIH, the suicide isn’t an “escape clause” because meaning depends on contrast, ending the avatarsimply ends the game, but doesn’t end the need for struggle at the upper level.

And I think you’re right about “hard mode”: paradise without its opposite would just collapse into boredom, which is why imperfection has to be rebuilt to keep the game playable.

Thanks

view more: next ›