Wow, so awesome.
I do hope at some point we can see some language improvements to PLPGSQL. More basic data structures could go a long way in making that language really useful, and I still consider views/stored procedures a superior paradigm to client side sql logic
I agree with you that stored procedures are superior to client-side logic, because it means that you can have multiple routes of access to the database and all of them enforce the same business logic. But what exactly do you mean by "more basic data structures"?
PL/SQL has various types of collections, for example, that are super-useful when you need to do more complicated processing without having to create temporary tables and such.
At my last job we finally got our front-end devs to move all client side db work to calls to stored procedures or views. After doing so, nearly all of them fell completely in favor of this method. This is escpecially true with large, complex DBs or data warehouses, where the model is subject to change and reliance on back-end devs better knowledge of the database is more important.
That said, despite some of the tradeoffs - for example with testing, or migrating to a new db (which is extremely rare anyway) - it is ultimately far better for client code not to have to know back-end implementation. I think things like graphql are finally making this abundantly clear.
What I have been dying for is a real time DB BAAS that is ACID compliant, preferably relational, has a simple rest api, and allows me to write stored procedures that I can call from my client code. Horizon is probably the closest thing out there. Right now using firebase, and sick of the absurd amount of client side code I have to commmit to to pull data from various parts of the database. Requires huge amounts of overfetching, unecessary coupling of client-server code, horrible consistency support, overly loose type structuring, etc.
If somebody writes a postgres version of horizon I will pay big money to use it :)
That said, the real-time aspect is what I'm really dying for, plus a company supporting a BAAS. The ease of firebase is so nice, and you can make really cool real time apps with it very fast. I'm not sure if switching to a relational model would make impose some technical limitation that json stores don't (besides obvious complexity). Postgraphql + socket.io is kind of what i'm thinking is the start
I had forgotten about this actually. Thanks for the reminder :)
Curious if anyone has tried using this for real time apps and what their experience was
You might want to take a look at dreamfactory[1]. They have a nice app that wraps all manner of services to become a self-hosted MBaaS. I've used it to put a REST interface on my postgres database, views, and stores procs.
You cite this as the primary reason, but how much easier would this have been without stored procedures and especially views? I would think harder if anything.
It can be the primary reason, but it is generally one of a few very good reasons (performance is often another big one, as this article points out).
I will say its importance is somewhat contextual though. The 3 principal contextual factors that make this reason significant are: (1) A large, complex database/model, (2) A rapidly evolving data model (such as during development or prototyping and fast business requirement changes, and (3) a clear division between back-end and front-end guys on your team. Those are the most important factors, but they are not the only ones. When these factors are significant, you really want to encapsulate DB access from client work. The client should simply declaratively say what they want, and this enforced contract is maintained by the back-end team while the back-end team is free to implement the details, presumably better than the front-end team could. For example, if a query initially involves just joining a fact to a dimension, a front-end user might think they could simply write this in their ORM. But, if the model changes and this later requires 4 or 5 other joins to the get the needed data (because the modeler or business or whatever decided it to be so), then the client code can remain as is while the back-end team can rewrite the implementation details, maintaining performance and correctness of implementation as needed.
Because they are interesting and fun to think about?
Because they may create new ideas which impact models, frameworks, directions, and analogies of thought in experimental and theoretical disciplines of the same or differing subjects?
Because not everything is testable, or even when it is the number of variables simply makes controlling the experiment for accurate causal derivations difficult to impossible? (increasingly true as science progresses, often leading to false levels of confidence).
> Because they may create new ideas which impact models, frameworks, directions, and analogies of thought in experimental and theoretical disciplines of the same or differing subjects?
How do you figure? Whether we are in a simulation is a) unknowable by definition, or it's not a very good simulation, and b) doesn't change anything about how our universe works from our perspective. Why would speculation about "why" impact anything about the decisions we make?
If someone thought they were in a simulation, they might try to find a way out of it, or might start not taking life seriously.
If, as most people, you think that one's beliefs shape one's actions, then it should be pretty clear that a belief that we live in a simulation could lead to some people acting differently based on that belief.
Only if one did not have free will or if one's beliefs did not shape one's actions would such a belief have no potential impact.
> If someone thought they were in a simulation, they might try to find a way out of it
This is completely nonsensical.
> or might start not taking life seriously.
People already do this just fine.
> Only if one did not have free will or if one's beliefs did not shape one's actions would such a belief have no potential impact.
Free will is a pretty thought, not anything to do with a simulation theory. Why does it matter whether you are forced to bow down to physical laws vs simulated physical laws? You can tell yourself whatever you want, but you gotta bow.
> > If someone thought they were in a simulation, they might try to find a way out of it
> This is completely nonsensical.
It really depends on the nature of the simulation. For example, if the simulation was something like what was depicted in The Matrix, where one's experience or senses were being simulated while one's real body was outside the simulation, then it could be possible to find a way out.
Of course, if your entire existence was simulated and you had no existence outside the simulation, then it would be more difficult, but perhaps even then not impossible, depending on whether you believed that a copy of yourself was still you. For instance, one could conceivably "upload" a copy of one's mind/brain in to a robot that was external to the simulation and that robot could then potentially have access to sensations/experience outside the simulation. Of course, then it could be argued whether that's another simulation.
But the potential for whatever is "outside" the simulation being just another simulation (ala Inception) is always there. And I'm not sure how one could ever be certain one was ever really "outside" and not just in another simulation -- though it might be possible that one really is "outside" without being certain of it. Or one could be certain and mistaken, or certain and correct. But then one could always be mistaken.
> > or might start not taking life seriously.
> People already do this just fine.
I meant people who took their life seriously because they thought it was "real" and then finding out that they and everyone/everything around them was simulated might decide, as a result of this realization, to no longer take life seriously. For example, they could have valued human life before, but when realizing that the beings they thought were alive before actually weren't, then they could start not valuing them anymore.
Of course, some people don't value their own lives or those of others regardless, and don't take their life seriously anyway.. but I'm not talking about them.
> Free will is a pretty thought, not anything to do with a simulation theory.
The point of bringing up free will was to show under what circumstances one's beliefs would not have any impact on one's actions. Those circumstances are ones in which one does not have free will.
If one does have free will, and one's actions really are shaped by one's beliefs, then the belief that one is in a simulation could have an effect on what one does.
If one does not have free will, or one's actions are not shaped by one's beliefs, then the same belief would not have any effect one what one does. One would do what one was determined to do regardless.
Second that, MobX has been a total game changer for me. Used redux and really like the philosophy of it, but overall feel mobx is much easier to use while accomplishing just as much, and the simplicity and lack of boilerplate actually makes reasoning about state, testing, etc much easier than redux. I disagree about large apps (switched to mobx on a large app now), but I can roughly see what you are saying. Still, I think MobX is great on large apps
This is awesome! However, when I add it to my webpack config it does load the dashboard, but afterward still produces all the scrolled output. Anyone now how to remove the scrolled output and just show the dash?
How to you run webpack-dev-server during development? You might have a script in your package.json that runs it - if so, add --quiet to the end of the script there.
I find a mix is good. I went without a flux implementation for a while and eventually ran into issues with figuring out what components to implement business logic and typical action reducer type work.
I'd say really good advice I wish I had known was don't start with a flux implementation. Build out your app with standard react state, use state only at last cost (ie derive logic off of props or whatever else via functions before storing state data), and only when you get into a bit of mess with a really large application and too much difficulty deciphering what components are providing logic and how they interact with each other should you implement a flux.
Also, it's worth watching Dan Abramov's learning redux course on egghead just for how it gets you to think about react, javascript, and GUI development in general.
Not sure what you mean on component state, as I've never heard anyone say that is explicitly harmful, but I think what you might be getting at is the principal in react of creating MINIMAL state such that any logic - for example something that renders an item - can compute off that MINIMAL state, rather than creating a new state that's the result of processing that basic state. The example given in Thinking in React[1] is having an array in state, but computing it's length somewhere (say in render), rather than making the length of the array also part of the state.
On this note, I find that I rarely use state in child components, because as much as possible I have functions that compute values off props and simply return that where I need them, rather than storing them as state variables.
> while wages for the poorest have stagnated. But that means the percent of disposable income spent on food by the poorest might not be falling at all
No, that's not true at all. If wages are stagnant and goods are getting cheaper, then you are getting richer. I see this "stagnant wages" meme brought up all the time, but I don't see why nobody ever talks about cost of goods. Ex: Even the poorest today in the US can afford amazingly complex cellphones and computers, which was unthinkable 25 years ago (if we were to somehow make one of the same capacity)
> If wages are stagnant and goods are getting cheaper, then you are getting richer. I see this "stagnant wages" meme brought up all the time, but I don't see why nobody ever talks about cost of goods.
Because the wages are stagnant in real (that is, inflation-adjusted) terms, which means that the cost of goods is already considered.
Considered for the most part. You will expectedly still be able to find goods and services that cost considerably more or less than in past, real terms.
Does anyone know any good companies working on technology that identifies and categorizes aspects of the gut microbiome? This is a field I'd be very interested in getting into
One issue that separates software from most other industries is that software is not a physical entity. This makes the desire to change - refactor, add features, redefine use cases, etc - all the more tempting, since the only cost is getting someone to fix/alter some code (despite the fact that labor is obviously very expensive). In contrast, in aerospace for example, you have to get it right the first time, else you have millions of dollars worth of payload and equipment exploding. In these industries it means teams will probably be more reluctant to accept rapid change in development and deployment since the cost of failure is so much higher than software. This isn't the only reason for bugs in software by any means, but the sheer innate mutability of software makes the desire to pile on requirements, iterate frequently, and just generally not be averse to change a massive reason for buggy code
