Probably we should say "union" instead of sum, as typescript unions are not discriminated. string | string in typescript is exactly the same as just string, while Either[String, String] is a type which is exactly a sum of two string types. Plus Either is biased towards R, the happy path value.
If you put the panels in a diagonal (NW - SE), and you rotate each panel on its vertical axis, the need for space would be limited to a series of circles the diameter of the panel width.
No expert on the topic but surely a manually rotated system achieves the benefits of tracking without the overhead of installation and maintenance for an automatic system. As long as the panels are easily reverted to default position when no one can go and rotate them through the day (thinking domestic setup in the garden).
Plenty of people have gardens and land that is tended to multiple times through the day anyway (for gardening, animals, workshop activity etc).
We're very satisfied customers since January of this year.
We use it as an extension of our node app, for all things asynchronous (long or short). The fact that it's the same codebase on our server and trigger cloud is a huge plus.
For me, it's the most accessible incarnation of serverless. You can add it to your stack for one task and gradually use it for more and more tasks (long or short). Testing and local development is easy as can be. The tooling is just right. No complex configurations. You can incrementally use the queuing, wait points, batch triggers for more power.
We've had some issues with migrating from v3 to v4. The transition felt rushed (some of the docs / examples are still showing v3 code, that is deprecated in v4). I understand that it might take some time to update the docs and examples, because there is a lot of content.
That's great to hear, and thanks for the kind words.
Sorry you had some issues migrating. You're right, it was our biggest docs update so far, and unfortunately a few things did get missed which we have (hopefully) since rectified. Please do let us know if there's anything else we missed and we'll get it sorted.
If it sounds impractical, it's because the whole industry got used to not learning databases beyond most basic SQL, and doing everything by hand in application code itself. But given how much of code in most applications is just ad-hoc reimplementation of databases, and then how much of the business logic is tied to data and not application-specific things, I can't help but wonder - maybe a better way would be to treat RDBMS as an application framework and have application itself be a thin UI layer on top?
On paper it definitely sounds like grouping concerns better.
While stored procedures/triggers etc. can be powerful, it has been taught for decades now that it is an antipattern to put business logic to the RDBMS (for more or less valid reasons). Some concerns I would have would be vendor lock-in and limits of the provided language.
In very simple systems that makes sense. But as soon as your validation requires talking to a third party, or you have side effects like sending emails you have to suddenly move all that logic back out. You end up with system that isn't very easy to iterate on.
You can model external system interactions with tables representing "mailboxes" - so for example if a DB stored procedure needs to call a third-party API to create a resource, it writes a row in the "outbox" table for that API, then application-level code picks that up, makes the API call, parses the response (extracts the required fields) and stores it in an "inbox" table so now the database has access to the response (and a trigger can run the remainder of the business process upon insertion of that row).
Surely some RDBMS has the ability to run REST queries, possibly via SQL by pretending it's a table or something.
I can imagine that working on a good day. I don't dare imagine error handling (though would love to look at examples).
Ultimately, it probably makes no sense to do everything in the database, but I still believe we're doing way too much in the application, and too little in the DB. Some of the logic really belongs to data (and needs to be duplicated for any program using the same data, or else...; probably why people don't like to share databases between programs).
And, at a higher level, I wonder how far we could go if we pushed all data-specific logic into the DB, and the rest (like REST calls) into dedicated components, and used a generic orchestrator to glue the parts together? What of the "application code" would remain then, and where would it sit?
> treat RDBMS as an application framework and have application itself be a thin UI layer on top?
Stored procedures have been a thing. I've seen countless apps that had a thin VB UI and a MSSQL backend where most of the logic is implemented. Or, y'know, Access. Or spreadsheets even!
And before that AS/400&al.
But ORMs came in and the impedance mismatch is then too great. Splitting data wrangling across two completely differing points of views makes it extremely hard to reason about.
If you think of an existing database, like Postgres, sure. It’s not very convenient.
What I am saying is, in a perfect world, database and server will be the one and run code _and_ data at the same time. There’s really no good reason why they are separated, and it causes a lot of inconveniences right now.
Sure in an ideal world we don't need to worry about resources and everything is easy. There are very good reason why they are separated now. There have been systems like 4th dimension and K that combine them for decades. They're great for systems of a certain size. They do struggle once their workload is heavy enough, and seem to struggle to scale out. Being able to update my application without updating the storage engine reduces the risk. Having standardized backup solutions for my RDBMS means is a whole level of effort I don't have to worry about. Data storage can even be optimized without my application having to be updated.
Something similar but in the opposite direction of lessening DB-responsibilities in favor of logic-layer ones: Driving everything from an event log. (Related to CQRS, Event-Sourcing.)
It means a bit less focus on "how do I ensure this data-situation never ever ever happens" logic, and a bit more "how shall I model escalation and intervention when weird stuff happens anyway."
This isn't as bad as it sounds, because any sufficiently old/large software tends to accrue a bunch of informal tinkering processes anyway. It's what drives the unfortunate popularity of DB rows with a soft-deleted mark (that often require manual tinkering to selectively restore) because somebody always wants a special undo which is never really just one-time-only.
I think that's the main issue. It's not enough to have a database that can automatically sync between frontend and backend. It would also need to be complex enough to keep some logic just on the backend (because you don't want to reveal it and entrust adherence to the client) and reject some changes done on frontend if they are invalid. Database would become the app itself.
I don't think a stored procedure that operates only on master copy of the database can reject update comming from a second copy and nicely comminicate thus happened so that the other copy can infrom the user through some ui.
It's the same issue that killed the image-based programming in favor of edit-compile-run cycle we're all doing. "How do I test? How do I do version control? How do I migrate?".
These are valid concerns, but $deity I wish we focused on finding solutions for them, because the current paradigm of edit/compile/run + plaintext single source of truth codebase, is already severely limiting our ability to build and maintain complex software.
While I don't like the idea of putting logic to the DBRMS (if not for a really good reason), you can do unit tests and code reviews. In a serious project you already should have a way to make migrations and versioning of the DB itself (for example using prisma, drizzle, etc.). Procedures would be just another entry in the migrations and unit tests can create testing temporary DB, run the procedures and compare the results. I agree tooling is (AFAIK) not good and there will be much more work around that, but it is possible.
The other issue, from experience, is needing to reimplement logic as well -- you end up with stored procedures that duplicate logic that also must be run either in your server or on your client. eg given the state of the system, is this mutation valid.
Then those multiple implementations inevitably suffer different bugs and drift, leading to really ugly bugs.
Personally I would argue that the addiction simply shifted for most Americans. It was cigarettes, now it is food, particularly ultra-processed food.
There's a large subset of people, the majority in my opinion, who are somewhat prone to addiction. Most are just a wee bit prone. They certainly won't peruse the streets for drugs. But, if something is readily available and socially accepted, they'll do it.
Before this was smoking, now its ultra-processed foods. Fast food, junk food, sweets type stuff.
It's probably still a boon, I'd say. I mean, I think being obese is probably healthier than smoking. But we didn't really "solve" anything, we just moved the problem.
The connection is even closer. Tobacco company extensively invested in the highly processed food industry and brought their advertisement experts in. The obesity crisis (and addiction to sugary and fatty processed foods) is not an accident, it's the result of a sophisticated advertisement campaign directed by the brains behind tobacco and alcohol campaigns.
I mean, of course I have no evidence because nobody is really looking into it. In my opinion, despite the fact we have many tens if not hundreds of millions of people eating themselves to death, we (socially) are incredibly hesitant to consider overconsumption an addiction.
But when people are dying slowly, and painfully, by their own hand and they can't stop, I personally consider that an addiction. In addition, we know ultra-processed foods are designed to invoke as much pleasure in the user as possible. In many ways, they suffer the same hyper-optimization that modern cigarettes do.
There's also some* evidence that part of the Tobacco industry shifted to food as Tobacco in the US died off. This is more circumstantial evidence. I think the "hard" evidence is that everyone smoked and was thin, now nobody smokes, and everyone is obese.
Regardless, I think we need harder and more proven solutions to the obesity epidemic. I think "willpower!" isn't working out for us, on a large scale. I'm rooting for Ozempic. And, fun fact, Ozempic also curbs nicotine and alcohol addiction.
Not very surprising, considering it’s the same companies using the same playbook. I’m not so sure that being obese is healthier than smoking, being obese might not give you cancer but it will certainly mess with your heart, and I would not be surprised if someone who smoked for the same amount of time someone else was obese ends up having a better prognosis after quitting.
I don't think so, are you sure? The Conseil d'Etat has two distinct roles (and thus two distinct branches):
- serving as the supreme court for the administrative "order" - as a judge, the CE does not check if laws are constitutionnal
- serving as legal counsel to the government - in which case it does check if bills put forward by the governement (i.e. not laws already adopted) are constitutionnal but this is merely advisory.
They’re probably different kids we’re talking about. My personal perception is that the gap of basic reading/math skills between the top 10% and the bottom 90% is widening.
Why ? I’d say parental (real, no phone) presence in the kids life / education.
You're right that it's not new. But now that women are getting tons of degrees for degrees sake, without even taking into account the school, it's creating pressure on men to do the same.
I have an BS in Mechanical Engineering from Berkeley, and I've had women from no name schools with a masters in marketing try to talk down my education.
For sure the top kids are doing alright, and sure those kids are taking some programming as well. I suppose they should just modify most articles by saying 'Top students' and stop implying that the school system that can't teach kids how to subtract fractions is going to teach programming as well to the average kid.
So if you want to register xyz.ci.pemberton.nj.us, you need to ask for DNS delegation from the owner/manager of ci.pemberton.nj.us or a higher level.
It's a lot easier to buy the xyz-ci-pemberton-nj.us domain.