smac8

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

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.

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

Cool, hadn't seen that. There is also postgraphql, which I have become a big fan of and is a great foundation:

https://github.com/calebmer/postgraphql

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

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 :)

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).

Hmm......

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

Apparently! Thanks for linking

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?

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.

[1] https://facebook.github.io/react/docs/thinking-in-react.html

> 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)

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

Yes, but I suppose this is more the JVM than the language itself. The JVM is quite convincing though, hence Clojure, Scala, etc.

I'm a fan of Java in some senses, but curious to here what things you discovered in the language or JVM that changed how you thought about programming

Huh? What's wrong with measuring in price/watt? Price/watt is actually the standard for comparing electricity generation due to not having to create arbitrary units of time to compare with

This is awesome, thank you!

Just to add a comment on page rank, from what I've heard that is a actually a very small contributor to the overall google algorithm. That is - at least in the way it was originally conceived by Larry Page - PageRank is now only a minuscule tuner amongst 100's of other tuners in the overall search algorithm now, but because it was the first and core part of the google algorithm, people still continue to assume it is the predominant one.

That assumes that consciousness only correlates to brain activity, which is unsubstantiated