Um a lot of US zip codes map to multiple cities. Some even to multiple states. If you build a picker for city/state this works fine but your premise is easily refuted if you look at the data!
I had kept my Plus subscription just because I was lazy, and it was inexpensive and convenient… but this turn definitely helped me get off the fence. I am exporting and deleting my data now, and the cancellation is already done.
I’m building an ETL tool that “just works” and gets out of the way. I can write shell scripts and python to do this stuff but honestly I just want to drop my files/API results into a GUI tool and have it combine things for me. Landing page is at https://eetle.com
Yes I was very excited to see the new json encoding changes land, can’t wait to try them out! The new omitempty and map key marshalling in particular will help clean up some of my ugly code.
Probably gets pretty costly if you’re running a lot of data through it. Now if you could implement a Tailscale DERP server in a lambda that would be pretty amazing: https://tailscale.com/kb/1232/derp-servers
I have a variety of Shelly 1 devices in my house, one of which is on the oldschool Garage Door opener (with a reed switch for open/close tracking) - Very inexpensive, flexible for other applications, and works with HA etc.
API tool to automate all the stuff Postman makes painful: https://callosum.dev
Spec generation from request logs, automatic schema generation and validation, test generation (eventually), totally offline, no accounts or cloud sync necessary!
Been taking longer than I hoped but should be released soon (next few days)
Re: the grid connection backlog - much of the challenge of turning on new generation is simulating the increasingly complex ways the grid can fail due to all the interconnections. It’s a huge computational challenge and there’s really not much incentive to speed it up
Spec generation from request logs, automatic schema generation and validation, test generation (eventually), totally offline, no accounts or cloud sync necessary!
Been taking longer than I hoped but should be released soon (next week or two)
How granular are the durations? If days for example you could bucket into N-week intervals (eg intervals with 7N consecutive days) to reduce the search scope. Then you only need to store start times, and can join or use a set to combine other ranges with the same availability.
Yeah... They are using a single-core 13W measurement to project out. For a 64x parallelization - no mention of any overhead due to parallelization or power needs of the supporting hardware. This is a key quote for me (page 12 of the PDF):
> The 1.3B parameter model, where L = 24 and d = 2048, has a projected runtime of 42ms, and a throughput of 23.8 tokens per second.
e.g. 64 x 13.67W = 874 Watts to run a 1.3B model at 23.8 t/s... I'm pretty sure my phone can do way better than that! Even half that power given their assertions in the table are still overpowered for such a small model.
I mean shared hosting certainly existed but "the cloud" as we think of it today was much simpler and not nearly as ubiquitous. It doesn't really change the principles themselves but it certainly affects aspects of the risk calculus that dominates the table of contents.
Zip codes map to postal routes, not polygons