There is a popular quote that occasionally gets tossed around among software developers:
There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton
When invoked with the intent to emphasize the latter of the two hard things–naming–it is often in response to frustration with trying to mentally evaluate source code or read documentation that someone else wrote.
The following are at least two common issues with names that I have seen lead to frustration:
Technically services in Ember are just singletons in an application instance’s DI container. They are often used to own state and handle effects because they live for the life of the application instance, they have access to the container and can inject or be injected, and they can be stubbed when testing.
But, let’s be honest. Services can be kind of clunky.
A while back a coworker shared with me a great article by Peter Livesey entitled “Pirates with PhDs”. In the article Peter shared an interesting yet accessible thought experiment that for me illuminated Game theory and Nash equilibriums in a way that Economics courses in college never had.
That is, the puzzle as presented excludes a consideration of time. The pirates are simply interested in maximizing their return from a single transaction. But, our lives…
This is equivalent to asking are the majority of people a youngest or only child since there are as many oldest children as there are youngest children.
So, let’s be more precise. Are a majority of people first children?
I personally am a first, and I know quite a few first children. But, are a majority of the people I meet also first children?
Human fertility dictates that in a large enough population at least a plurality of people are first children since any mother that has children for sure has a first child but may or may not have…
The following are a few useful component design patterns. I am not the inventor of any of these patterns, but I hope this article can serve as a useful reference.
I favor React and Ember because those are the two frameworks with which I am most familiar. But, the principles are relevant to other component systems as well.
This article is also strongly biased towards web client development, but I acknowledge that the component abstraction is more generally applicable and useful.
I apologize in advance for any misuse of distributed system terminology or misapplication or misrepresentation of distributed system principles. Please call me out on my mistakes.
With that out of the way, to reiterate the title, your web client is part of a distributed system. The following are several things to keep in mind about the role your web client plays in that distributed system.
Web clients are hanging on to more data for longer. …
Components and services are relatively new to the Ember framework, but since their introduction they have begun taking over many of the responsibilities once allocated to routes and controllers. Frameworks like React have proven that even routing can be handled quite elegantly using components, and it’s not unimaginable that routes and controllers may one day completely disappear from Ember. (Or Ember may simply be supplanted by Glimmer, which like React focuses on components as the core building block.)
The following is a list of reasons why and how I recommend developers start reducing their reliance on routes and controllers, and…
If this sentence is true, I like cherry tomatoes.