Having a sink and a source for spikes aids grid stability and somewhat helps to reduce the need to build more infrastructure to handle transmitting power from the generators during those peaks.

It also helps avoid the viability of gas powered generators which are very expensive and carbon intensive.

Rereading the Lies of Locke Lamure. If only the sequel were half as good as it...

feds: "unlock your phone or else" victim: "um, you're stressing me man. It's either 1234 or 4321, I forget. One of them wipes the phone, the other will unlock it."

Whichever PIN they try, it wipes the phone, but the feds can't claim it was deceitful, just unlucky.

You should be able to write a message and not rely on the recipient being available when you press send. You should also be able to run nodes to cache messages for longer, and opt in to holding messages for a greater time period. This would among other things allow couriers between disjoint groups of users.

For example, if supporting a dev tag to serve assets from the filesystem, why not include a simple webserver which embeds the contents?

This would allow aspiring gophers to go straight to the high value modification of a project rather than effectively spend most of the time writing scaffolding and tests.

I'm not sure how well this will work on a mobile; the service worker might be stopped after a few hours, particularly with the screen off overnight

A 13kWh system is over $AUD10k, and the ROI is on par with the expected lifespan of the battery.

If sodium cells can bring the price down to $AUD100 it would indeed be a massive game changer.

By avoiding needing to add lots of client side logic to still get very low latency updates, it's given me the best of both worlds.

The way Django's template system works also makes it so easy to render a full page initially, then expose views for subcomponents of that page with complete consistency.

On a tangent, Django's async support is still half-baked, meaning it's not great for natively supporting long polling. Using htmx to effectively retrieve pushed content from the server is impeded a little by this, but I slotted in a tiny go app between nginx and gunicorn and avoided needing async he'll without running out of threads.

Maybe I'm missing something, but i would use a simpler algorithm which doesn't need ML. On day 0, plug in the latitude and allow the system to traverse the range of angles, finding the optimal one at the time - ie: yielding maximum power. Let it run 3-5 times during the day, then fit those points to the theoretical path of the sun across the sky. Now your system is calibrated, without needing any other input. As the seasons change, the system will always know which angle to face for optimal power.

The main driver for getting it done is mostly to set the groundwork for the websocket autosave feature, which would be exceeding dangerous without this.

Remember that this is not a SPA, so websockets are recreated each time a page containing models marked for dynamic updates is served. This means there should be fewer problems associated with long-lived connections, and any instability will have more limited impact.

The "killer" features I am hoping to bring to the Django community is the ability to have strong data consistency assurances between requests when editing data, as well as realtime server-driven validation of form inputs, alongside optional realtime "autosaving" of fields as changes are made. You can see how this looks here: https://user-images.githubusercontent.com/236562/153730557-a...

I have also attempted to minimise how much an existing codebase needs to be altered to use or test this. No database schema changes are required, and mostly it's just a matter of changing import statements from "django..." to "nango..."

This is very much a proof-of-concept at the moment and certainly not fit for production, and I welcome all suggestions and critiques. A quickstart script is included in the repo which should minimise the pain in running the code locally.

Comments URL: https://news.ycombinator.com/item?id=30317397

Points: 20

# Comments: 5

https://gist.github.com/nicois/e7f90dce7031993afd4677dfb7e84...