I finally switched to duck duck go, not because of the AI push of google, but because of the constant nagging popups to download the google app. Just let me google things in mobile safari in peace!
Truly a great library. I have become so reliant on it, because I can basically have a guarantee that some complex process will run eventually, instead of manually catching and handling every error that might happen and write the 50th retry logic manually.
> The typical way to do schema migration is to compose a list of ALTER TABLE statements. This becomes hard to track the latest schema state as the migration accumulates. It's more intuitive for the developers to specify the desired state. Ideally, PostgreSQL could allow developers to specify the desired CREATE TABLE schema, the engine then reconcile it with the latest schema, figure out the diff, and plan the migration path internally.
This is a terrible idea. The behaviour of engines that do this is unpredictable and suddenly you lose data because the engine deleted a column.
Think about having one plane (the entire glass) pressing 2 microswitches. Debouncing one switch is hard enough, now you've got to debounce 2, and detect if the user was doing a really fast double click, or just pressed in the center of the mouse.
I still want some app that makes the awesome brouter algorithm usable on iOS. They have an android app which is "easy" to do since the routing module is written in Java, but alas, iOS doesn't support Java.
IMO, brouter generates the best routes for bicycling with lots of options to customize for what kind of riding you want to do (road, trekking, gravel, recreational, commuting, safe and quiet vs. quick, etc.).
Right now I use brouter-web on my iPhone but it's really hard to use since the UI is really small and it's very simple to accidentally place a waypoint.
After that, I send the GPX file to my bike computer.
Then I'm afraid it's not possible. The reason the input switch takes so long is because of the HDID negotiation.
A video mixer acts as the source and sink for the output and the inputs respectively, where a HDMI switch will just physically disconnect and connect the output port to a different input port, meaning the HDID negotiation has to be re-done every time.
Thanks, but I'm really happy with our vector tileset solution, and don't want to downgrade to raster tiles. They are pretty slow compared to vector tiles with mapbox/maplibre gl.
That is usually out of the question, because raster tiles don't allow you to customize the map (colors, which features to display at which zoom levels, etc). I find openstreetmap way too busy as a backdrop for data.
As I've said, the solutions are there, and there is an actual demand for cheap vector tile hosting without all of the other cruft that is bundled in the commercial solutions but isn't actually needed.
There are lots of usecases for apps that don't need these advanced features, and just want a nice backdrop for their geo data.
The current offerings of google, mapbox, bing, etc are prohibitively expensive when you just need a small subset of their features.
The company I work for is a happy customer of maptiler.com which even offers routing and reverse geocoding. It might not be as great and up to date as google's, but it's more than enough for our apps.
Nobody is talking about taking away cars from people who live outside of cities. Yet this argument always comes up when problems with cars in densely populated areas are discussed.