Thoughts, terms, and ideas I’ve come across over the last few months.

• Data center power = 50% for Store/Retrieve/Transmit and 50% for cooling.
• Social Signal - A Like, +1, etc.
• Mixin = Small, specific, orthogonal
• This worked for me! The for me is silent.
• The standard you tolerate is the standard you accept.
• Localize related concerns. Components that frequency interact should be kept close! Avoid cross-network calls. Chatty (fine grained) vs. Chunky (course-grained).
• Service vs. Libary - Service is updated at the same time as the client while a library can be updated independently.
• Don’t start with generic - Concentrate on your features and specific use cases first. Later you can think about a generic solution if it satisfies the rule of three.
• Ad-hoc Analytics - Issues dynamic queries on the data store and system responds. Used to explore the dataset.
• Streaming Analytics - Issue static queries and system processes them as time ordered data comes in without storing. Examples are windows, joins, counting, temporal event sequence detection.
• Store an immutable sequence of events. Model data transformations as a series of materialized stages from the original input. Can debug and test each state independently. When code changes, you can re-run to get new output (Reprocessing/Regenerating output).
• Time to first byte - How to measure startup times
• Environmental Viscosity - When the dev environment is slow devs are tempted to make minimal changes, so they don’t have to wait. Do what’s easy instead of doing what’s right.
• Are the portions of the code with highest fan-in (used in the most places) exercised by automated tests?
• Are there volatile parts of the codebase that get changed with every commit?
• Testing Pyramid - 70% unit tests / 20% integration tests / 10% end to end tests.
• 1/2 the world is 20000km and a ping is there and back (40000km) at the speed of light so 133ms minimum.
• Constructor injected dependencies and method arguments are both input arguments applied at different times in the application lifecycle.
• Represent side effects as intents to perform actions transparent objects that expose the details of side effects without actually performing them.
• It is impossible to completely decouple a code base without damaging coherence. It is impossible to have fully cohesive code without introducing coupling.
• Domain Events - Bones of a domain model. Stable because they only change if the business changes. Many choices for how to implement behavior and represent in data.

Interval trees store a set of intervals and can be used to find all intervals that overlap with the query interval. In the augmented variant, each node maintains the maximum end value of the node and all of its children. We can use this extra information during searches to rule out subtrees that cannot possibly contain the query interval.

The Code

An amazing New York Times article on what makes an effective team. There were two key things they noticed about effective teams:

… members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘equality in distribution of conversational turn-taking.’ On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount. ‘As long as everyone got a chance to talk, the team did well,’ Woolley said. ‘But if only one person or a small group spoke all the time, the collective intelligence declined.’

Second, the good teams all had high ‘average social sensitivity’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues.

Link

This seems like common sense but I haven’t encountered a non-coding architect as of yet.

This provides empirical evidence on why software architect should write code or, at least, be engaged in the development of tactical fragments in a system.

Link