I’ve been using lightwaverf for around 10 years now and find it to be a decent solution. I originally bought a light switch and some of their pass through plugs, but recently I’ve been expanding with more light switches and a relay, mostly to control hard-to-reach-the-switch things like outside lights but now I’m thinking about replacing more indoor lights and sockets for a more complete solution
Lighting-wise their dimmers just replace your regular dimmers, though they are push buttons rather than switches and they have led indicators on them (that you can turn off). They work without the hub, not that the hub has ever failed for me
I’ve never had a problem with range like tfa suggests, even in places that struggle to get a wifi signal and out in the garden (125 year old Victorian terrace over 3 floors)
Their stuff is fairly expensive but my oldest equipment is maybe 10 years old now, still works well and is compatible with the newer generation. My wife is even coming around to it - being able to say “Alexa turn on garden lights” instead of trudging outside in the rain to turn them on has convinced her I think!
If/when we move I can mostly just put the old light switches back in and a) keep my kit for the next house and b) not have to subject the new owners to my home automation addiction
We’ve used Avro in production for a number of years now. We use it to define the schema for Kafka messages passing between parts of the system and it has worked well - but you want some downsides, so..
Compatibility: Avro deals with this well, but there are gotchas especially when you need/want to have “forward compatibility” as well as “backward compatibility” in your messages. Adding a new type to a union? Breaking change. Adding a new element to an enum? Breaking change. Want to add a new member to a type? Best give it a default, or.. breaking change. We use the Confluent schema registry to manage our schemas on kafka and we find ourselves having to do carefully managed rollouts (stop all producers, put schema-reg into compat mode, upgrade consumers, upgrade and start producers) every now and again
Performance: we frequently see Avro as the “hot” code in our apps - mainly I suspect because we’ve got a fairly large schema with lots of union types etc, and our messages are up to 2kb or so in size. This results in our applications topping out at low tens of thousands of messages per second, though it scales linearly with number of cores. The most recent java version has a “fast read” flag that promises to speed up our use-case but we haven’t tried it yet
I remember having another type of cartridge - one that let you plug a UK and a US “shape” cart into so you could play the US cart on your UK machine. Like the “Noah’s Ark” cart it’d use the region code from the UK cart to boot up the US cart on your UK (PAL) machine. IIRC the UK cart had to be the SuperFX type for some reason
I used one to play SFII: Turbo months before it came out over here. Unfortunately it wasn’t very well made and knocking the machine while in use would cause the game to cut out & restart, which happened quite a lot during intensive 2p matches!
Prototype all you want without tests, but once you've settled on a design & are ready to make it production-ready you should spend time at least writing unit tests for your work or (ideally) take what you've learned & re-apply to a clean design written in a test-first manner.
You might think this is a waste of time, but putting code into production without tests is going to give you more trouble in the long run.
It’ll look at your pods’ cpu and memory requests and choose an appropriate instance type for you, and the cheapest spots where appropriate