This keeps the power lines stable and compensates for factors like lack of wind in wind power stations, startup/shutdown times of thermal power plants, differing consumption patterns because of colder weather etc.
1,196 karma · joined October 10, 2022
Senior Software Architect @ Austrian railways ÖBB
Blog: https://www.fabianzeindl.com/
This keeps the power lines stable and compensates for factors like lack of wind in wind power stations, startup/shutdown times of thermal power plants, differing consumption patterns because of colder weather etc.
That is completely untrue. Efficient, creative writing is a skill that can be learned by anyone by following a handful of rules.
Ron Pressler always was an advocate for blocking code and even joined oracle to add virtual threads to the JVM, thus invalidating the performance argument of the async/await/non-blocking crowd.
I really wish young developers would be taught about the actor model and communicating sequential processes before falling for the false promises of async/await-land.
And I wish JavaScript runtimes had a way of expressing continuations /blocking threads on their eventloop.
* comprehensive transaction model using different modes
* PostGIS and lots of other great extensions
* supports most of the current SQL standard and is clear on interpretation of edge-cases in the documentation
* support for writing stored procedures in any major programming language
* many useful functions regarding dates, sets, ranges, json, xml, ...
* custom datatypes
* extremely thought-out and standardized approach to development: if a feature is included it generally works well in interaction with everything else
* syntax, semantics and performance are all very predictable
* great documentation
Regarding MySQL / MariaDB: MySQL optimized for performance first. Until 2010 the standard-storage-engine MyISAM didn't even support transactions.
PostgreSQL always focused on correctness and stability and then made sure everything performed.
I tried pencil at first but with ink I liked that I can’t erase and can’t shade by using pressure.
So every mistake has to be transformed into something agreeable.
It is very productive to think about drawing in a logical way, e.g. how can I achieve what I want to achieve in a part of my picture. What also helps is knowing that a perfect drawing is a photo and I don’t want to produce a photo. And I try drawing what I actually see, not what my mind abstracts and thinks the picture should look like.
https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...
It is hard to foresee how the world of development would look like today, had companies used the waterfall process twice on each project.
How is this old style? At least in software development / IT-consulting in Europe cost plus is done all the time now, since there were too many legal battles about fixed price not being finished according to spec.
So JavaScript gets what Java got in version 8, 10 years ago?
To put it shortly: Writing single-threaded blocking code is far easier for most people and has many other benefits, like more understandable and readable programs: https://www.youtube.com/watch?v=449j7oKQVkc
The main reason why non-blocking IO with it's style of intertwining concurrency and algorithms came along is that starting a thread for every request was too expensive. With virtual threads that problem is eliminated so we can go back to writing blocking code.
It depends, but yes. Martial arts is not just boxing. Take the following choreography from one style of Pencak silat:
good dancing like good fighting isn‘t mechanical either, it is good because it relies on little imperfections. Just like MIDI files cannot replace a concert pianist.
In the end I think motion capture of extremities along with some easing of paths and compression of point-clouds (think bezier curves) might be more worthwhile than a notation.
This is called defunctionalization and useful without LLMs as well.
You mean defused? "Diffused" kind of turns the meaning of your sentence around.
Or both continue to work together in a healthy, never ending discussion, that has temporary victories on both sides and ultimately benefits all, because nothing happens and the company strives.
They can be used in a view that is then exposed. Parameterized functions for more complex queries can also be exposed.
I do think this is fairly simply for many companies.
> But I agree. These sort of "just keep wiring boxes together until it works" architectures cause so many headaches IME; so many pieces, each with its own failure modes and bugs. This is where I find the claim the OP makes,
I agree, but PostgREST is a very very simple box...
> With wired-together-boxes-of-random-tooling like this, I have to pray my change fits into the whims of its config files.
... that needs almost no configuration except the database connection string.
That way you can change your schema internally.
You can do flexible auth in PostgREST, but also on an api-gateway. Are you right now doing rate limiting in the backend?
If your existing endpoints already support vertical and horizontal filtering, proper pagination, joining, limiting etc. then you won't get much benefit.
> Also what about caching if people can "craft" random queries and send them straight to your PG instance?
Queries can be blocked or rewritten on the reverse-proxy.
This is not correct. Whenever you need to change an API you need to upgrade your clients or you add a new version of the API. With PostgREST the versions of the API are served as views or functions that internally map to internal tables. It is absolutely possible to change the tables without changing the API.