adatavizguy

How did the farmer get his donkey out of the deep ditch? He filled it in with dirt. This is just Aesop's fable. But it falls into the same abstract thinking as where does fat go, C55H104O6+78O2 --> 55CO2+52H2O+energy[0], or what happens to a tree when it burns, CH4+4O2→CO2+H2O (plus heat!)[0]. We have a hard time seeing air (sic) as something tangible. Also, this inability to visualize abstract concepts leads to political points of view such as whether or not aerosol of breath contains disease or invisible gases causes global warming.

[0] Grabbed from first search results.

Likewise, where does that tree in your backyard come from? It is the product of carbon dioxide and water.

edit: The significance of this thought is when a child is asked where a tree or plant comes from, at least in the US, they inevitably answer the ground when the answer should be rain that falls from the sky and air. With the naive notion a tree comes from the ground we miss the obvious which is the ground doesn't sink when a tree grows from it.

Off topic. When something is on the tip of my tongue, I don't search for it because I have a strange belief that what my mind is trying to do to remember it is fire off neurons associated with the thought or idea, near it, to create the action potential. It is strange that I will eventually remember it within hours or the next day. When the action potential fires the neuron, dendrites are formed between neurons strengthening the memory.

I wonder if there is any truth to that notion? That to solidify a memory, there can't be outside help, that electric chemical signal has to trigger firing the neurons associated with the memory to strengthen their connections.

I wonder if the Cheesecake Factory and Applebees use A/B testing with their menus the same way Netflix uses A/B testing? There is probably a huge demand for data driven decision making for restaurants rather than these spares studies mentioned in the article which most likely are anecdotal. Simply have four different menus with the same items and look at the analytics provided by point of sale system. That is a fun start - up idea.

Most of your favorite restaurants in places like San Francisco, Portland, and New York City engineer their menu by removing least popular menu items once a month or once a season and replace them with what they think their customers currently demand at a price to insure that the restaurant is running at the point of highest efficiency. There are other considerations such a cost of product but most restaurants increase overall demand by using analytics from the point of sale system and the most profitable dishes are not always the most popular. Engineering a kitchen -- and dining room for that matter -- to be efficient without cooks tripping over each other is another whole discussion nonetheless even this ties into what can be added to the menu.

The two biggest mistakes an independent restaurant can make is hard coding a menu and putting the word in Bistro or Basserie in the restaurant name -- the restaurant can't evolve after that. Have any of you been to La Folie on Polk and Green in Russian Hill? That restaurant first opened as a casual French Bistro but the demand was for their caviar by the ounce and Tournedos Rossini which oddly enough was not only their most popular menu item but also not on the menu. So in the mid nineties the average customer was spending $150 - $300 instead of $40 per person.

It is interesting that recipes are not art but rather fact. The same with fashion. I think that SpaceX has trade secrets rather than patents because there is nothing stopping China using the information in a patent whereas a trade secret is obfuscated.

I read the title and thought this article might have more to do with my spending 10 minutes finding the perfect variable name.

Elixir is synonymous with Phoenix. If that is the only reason to choose using Phoenix over NestJS, the later is clearly the better choice.

> I admittedly struggle with is knowing when to create a new Nest Module versus a new service in an already existing module

I use the same logic as where to put a font end component. If I'm creating a component for the first time, it sits in the same folder as the parent component. If I need to use it with another component, I refactor it into a common folder. If I create a string transformation function, it exists in the same file that is using it. If I need to use it somewhere else, it gets refactored into utils/strings.js which is a starting place for creating a library.

It solves the problem of 'where does this go?' and 'where did I put it?' 95% of code that I need to find will be physically next to the code that uses it in a file system. If not it will be neatly organized into a common use directory.

For the few times I need to refactor functionality, at that point, I will invest time to make a clear and adaptable API input and output contract.