afternoons are spent reading/researching/online classes.This has really helped me avoid burn out. I go into the weekend less exhausted and more motivated to return on Monday and implement new stuff. It has also helped generate some inspiration for weekend/personal projects.

Second, in my experience working with ex-FAANG - these engineers, while they all tend to be very smart, tend to be borderline junior engineers in the real world. They simply don't know how to build or operate something without the luxury of the mature tooling that exists at FAANG. You may be in for a reality shock when you leave the FAANG bubble

We want to learn, but we worry that we might not like what we learn. Or that learning will cost us too much. Or that we will have to give up cherished ideas.

When People Work Together

In our experience, the best way to prevent a useless meeting is to write up our goals and thoughts first. Despite working in the same office, our team at Nuclino has converted nearly all of our meetings into asynchronously written reports.

Choose health insurance (Krankenkasse) - in Switzerland you have to pay your health insurance separately (it’s not deducted from your salary). You can use the Comparis website to compare the options. You have 3 months to choose both the company and your franchise.

Other important things - if you plan to use public transport, we recommend you to buy the Half Fare card. It gives you a 50% discount on most public transport in Switzerland (it costs 185 CHF per year).

There are also some general expat groups like Zurich Together

we think the async culture is one of the core reasons why most of the people we’ve hired at Doist the past 5 years have stayed with us. Our employee retention is 90%+ — much higher than the overall tech industry. For example, even a company like Google — with its legendary campuses full of perks from free meals to free haircuts — has a median tenure of just 1.1 years. Freedom to work from anywhere at any time beats fun vanity perks any day, and it costs our company $0 to provide

Find a results-oriented job if you’re fiercely independent and opinionated. Climb the ladder in a big corporation if you’re highly diplomatic or a crowd-pleaser.

According to a Dice Tech Jobs report released in February, demand for data engineers was up 50% and demand for data scientists was up 32% in 2019 compared to the prior year.

Praca w Facebooku - doskonała znajomość JSa, React, zarządzanie projektem OSS na GitHubie, prowadzenie społeczności, pisanie dokumentacji i wpisów na blogu.Szkolenia - dobra znajomość JSa, React, tworzenie szkoleń (struktura, zadania, itd), uczenie i swobodne przekazywanie wiedzy, marketing, sprzedaż.Startupy - dobra znajomość JSa, React, praca w zespole, rozmawianie z klientami, analiza biznesowa, szybkie dowożenie MVP, praca w stresie i dziwnych strefach czasowych.

Some of the people in the company are your friends in the current context. It’s like your dorm in college.

It’s also okay to take risks. Staying at a company that’s slowly dying has its costs too. Stick around too long and you’ll lose your belief that you can build, that change is possible. Try not to learn the wrong habits.

Defining what “time well spent” means to you and making space for these moments is one of the greatest gifts you can make to your future self.

Research shows that humans tend to do whatever it takes to keep busy, even if the activity feels meaningless to them. Dr Brené Brown from the University of Houston describes being “crazy busy” as a numbing strategy we use to avoid facing the truth of our lives.

A few takeaways

Simulations show that for most study designs and settings, it is more likely for a research claim to be false than true.

There is increasing concern that most current published research findings are false.

golden rule: If someone calls saying they’re from your bank, just hang up and call them back — ideally using a phone number that came from the bank’s Web site or from the back of your payment card.

“When the representative finally answered my call, I asked them to confirm that I was on the phone with them on the other line in the call they initiated toward me, and so the rep somehow checked and saw that there was another active call with Mitch,” he said. “But as it turned out, that other call was the attackers also talking to my bank pretending to be me.”

It is difficult to choose a typical reading speed, research has been conducted on various groups of people to get typical rates, what you regularly see quoted is: 100 to 200 words per minute (wpm) for learning, 200 to 400 wpm for comprehension.

DevOps tools enable DevOps in organizations

While talking about DevOps, three things are important continuous integration, continuous deployment, and continuous delivery.

Basic prerequisites to learn DevOps

DevOps benefits

Operations in the software industry include administrative processes and support for both hardware and software for clients as well as internal to the company. Infrastructure management, quality assurance, and monitoring are the basic roles for operations.

I set it with a few clicks at Travis CI, and by creating a .travis.yml file in the repo

language: node_js
node_js: node

before_script:
  - npm install -g typescript
  - npm install codecov -g

script:
  - yarn lint
  - yarn build
  - yarn test
  - yarn build-docs

after_success:
  - codecov

I set it with a few clicks at Travis CI, and by creating a .travis.yml file in the repo

language: node_js
node_js: node

before_script:
  - npm install -g typescript
  - npm install codecov -g

script:
  - yarn lint
  - yarn build
  - yarn test
  - yarn build-docs

after_success:
  - codecov

Continuous integration makes it easy to check against cases when the code: does not work (but someone didn’t test it and pushed haphazardly), does work only locally, as it is based on local installations, does work only locally, as not all files were committed.

In Python, when trying to do a dubious operation, you get an error pretty soon. In JavaScript… an undefined can fly through a few layers of abstraction, causing an error in a seemingly unrelated piece of code.

function add(a,b) { return + (a + b) }
add(2,2)
add('2', 2)

With Codecov it is easy to make jest & Travis CI generate one more thing:

I would use ESLint in full strength, tests for some (especially end-to-end, to make sure a commit does not make project crash), and add continuous integration.

It is fine to start adding tests gradually, by adding a few tests to things that are the most difficult (ones you need to keep fingers crossed so they work) or most critical (simple but with many other dependent components).

I found that the overhead to use types in TypeScript is minimal (if any).

I need to specify types of input and output. But then I get speedup due to autocompletion, hints, and linting if for any reason I make a mistake.

TSDoc is a way of writing TypeScript comments where they’re linked to a particular function, class or method (like Python docstrings).

ESLint does automatic code linting

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Write a new test and the result. If you want to make it REPL-like, instead of writing console.log(x.toString()) use expect(x.toString()).toBe('') and you will directly get the result.

interactive notebooks fall short when you want to write bigger, maintainable code

I recommend Airbnb style JavaScript style guide and Airbnb TypeScript)

Creating meticulous tests before exploring the data is a big mistake, and will result in a well-crafted garbage-in, garbage-out pipeline. We need an environment flexible enough to encourage experiments, especially in the initial place.

Continuous Deployment is the next step. You deploy the most up to date and production ready version of your code to some environment. Ideally production if you trust your CD test suite enough.

the limitations of the PPS

Although the PPS has many advantages over the correlation, there is some drawback: it takes longer to calculate.

How to use the PPS in your own (Python) project

The PPS clearly has some advantages over correlation for finding predictive patterns in the data. However, once the patterns are found, the correlation is still a great way of communicating found linear relationships.

Let’s compare the correlation matrix to the PPS matrix on the Titanic dataset.

Let’s use a typical quadratic relationship: the feature x is a uniform variable ranging from -2 to 2 and the target y is the square of x plus some error.

how do you normalize a score? You define a lower and an upper limit and put the score into perspective.

For a classification problem, always predicting the most common class is pretty naive. For a regression problem, always predicting the median value is pretty naive.

Let’s say we have two columns and want to calculate the predictive power score of A predicting B. In this case, we treat B as our target variable and A as our (only) feature. We can now calculate a cross-validated Decision Tree and calculate a suitable evaluation metric.

More often, relationships are asymmetric

there are many non-linear relationships that the score simply won’t detect. For example, a sinus wave, a quadratic curve or a mysterious step function. The score will just be 0, saying: “Nothing interesting here”. Also, correlation is only defined for numeric columns.

There are many types of CRDTs

Some of our main takeaways:CRDT literature can be relevant even if you're not creating a decentralized systemMultiplayer for a visual editor like ours wasn't as intimidating as we thoughtTaking time to research and prototype in the beginning really paid off

traditional approaches that informed ours — OTs and CRDTs

CRDTs refer to a collection of different data structures commonly used in distributed systems. All CRDTs satisfy certain mathematical properties which guarantee eventual consistency. If no more updates are made, eventually everyone accessing the data structure will see the same thing. This constraint is required for correctness; we cannot allow two clients editing the same Figma document to diverge and never converge again

They’re a great way of editing long text documents with low memory and performance overhead, but they are very complicated and hard to implement correctly

Even if you have a client-server setup, CRDTs are still worth researching because they provide a well-studied, solid foundation to start with

Figma’s multiplayer servers keep track of the latest value that any client has sent for a given property on a given object

Figma doesn’t store any properties of deleted objects on the server. That data is instead stored in the undo buffer of the client that performed the delete. If that client wants to undo the delete, then it’s also responsible for restoring all properties of the deleted objects. This helps keep long-lived documents from continuing to grow in size as they are edited

it's important to be able to iterate quickly and experiment before committing to an approach. That's why we first created a prototype environment to test our ideas instead of working in the real codebase

Designers worried that live collaborative editing would result in “hovering art directors” and “design by committee” catastrophes.

We had a lot of trouble until we settled on a principle to help guide us: if you undo a lot, copy something, and redo back to the present (a common operation), the document should not change. This may seem obvious but the single-player implementation of redo means “put back what I did” which may end up overwriting what other people did next if you’re not careful. This is why in Figma an undo operation modifies redo history at the time of the undo, and likewise a redo operation modifies undo history at the time of the redo

operational transforms (a.k.a. OTs), the standard multiplayer algorithm popularized by apps like Google Docs. As a startup we value the ability to ship features quickly, and OTs were unnecessarily complex for our problem space

Every Figma document is a tree of objects, similar to the HTML DOM. There is a single root object that represents the entire document. Underneath the root object are page objects, and underneath each page object is a hierarchy of objects representing the contents of the page. This tree is is presented in the layers panel on the left-hand side of the Figma editor.

When a document is opened, the client starts by downloading a copy of the file. From that point on, updates to that document in both directions are synced over the WebSocket connection. Figma lets you go offline for an arbitrary amount of time and continue editing. When you come back online, the client downloads a fresh copy of the document, reapplies any offline edits on top of this latest state, and then continues syncing updates over a new WebSocket connection

An important consequence of this is that changes are atomic at the property value boundary. The eventually consistent value for a given property is always a value sent by one of the clients. This is why simultaneous editing of the same text value doesn’t work in Figma. If the text value is B and someone changes it to AB at the same time as someone else changes it to BC, the end result will be either AB or BC but never ABC

We use a client/server architecture where Figma clients are web pages that talk with a cluster of servers over WebSockets. Our servers currently spin up a separate process for each multiplayer document which everyone editing that document connects to

CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be. There is some unavoidable performance and memory overhead with doing this. Since Figma is centralized (our server is the central authority), we can simplify our system by removing this extra overhead and benefit from a faster and leaner implementation

Sometimes it's interesting to explain some code (How many time you spend trying to figure out a regex pattern when you see one?), but, in 99% of the time, comments could be avoided.

When we talk about abstraction levels, we can classify the code in 3 levels: high: getAdress medium: inactiveUsers = Users.findInactives low: .split(" ")

The ideal is not to mix the abstraction levels in only one function.

There is another maxim also that says: you must write the same code a maximum of 3 times. The third time you should consider refactoring and reducing duplication

Should be nouns, and not verbs, because classes represent concrete objects

Uncle Bob, in clean code, defends that the best order to write code is: Write unit tests. Create code that works. Refactor to clean the code.

int d could be int days

naming things, write better functions and a little about comments. Next, I intend to talk about formatting, objects and data structures, how to handle with errors, about boundaries (how to deal with another's one code), unit testing and how to organize your class better. I know that it'll be missing an important topic about code smells

Should be verbs, and not nouns, because methods represent actions that objects must do

decrease the switch/if/else is to use polymorphism

In the ideal world, they should be 1 or 2 levels of indentation

"The Big Picture" is one of those things that people say a whole lot but can mean so many different things. Going through all of these articles, they tend to mean any (or all) of these things

Considering that there are still a ton of COBOL jobs out there, there is no particular technology that you need to know

read Knuth, or Pragmatic Programming, or Clean Code, or some other popular book

Senior developers are more cautious, thoughtful, pragmatic, practical and simple in their approaches to solving problems.

In recent years we’ve also begun to see increasing interest in exploratory testing as an important part of the agile toolbox

When I began coding, around 30 years ago, waterfall software development was used nearly exclusively.

Mathematica didn’t really help me build anything useful, because I couldn’t distribute my code or applications to colleagues (unless they spent thousands of dollars for a Mathematica license to use it), and I couldn’t easily create web applications for people to access from the browser. In addition, I found my Mathematica code would often end up much slower and more memory hungry than code I wrote in other languages.

In the 1990s, however, things started to change. Agile development became popular. People started to understand the reality that most software development is an iterative process

a methodology that combines a programming language with a documentation language, thereby making programs more robust, more portable, more easily maintained, and arguably more fun to write than programs that are written only in a high-level language. The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer.

Development Pros Cons

This kind of “exploring” is easiest when you develop on the prompt (or REPL), or using a notebook-oriented development system like Jupyter Notebooks

notebook contains an actual running Python interpreter instance that you’re fully in control of. So Jupyter can provide auto-completions, parameter lists, and context-sensitive documentation based on the actual state of your code

They switch to get features like good doc lookup, good syntax highlighting, integration with unit tests, and (critically!) the ability to produce final, distributable source code files, as opposed to notebooks or REPL histories

Exploratory programming is based on the observation that most of us spend most of our time as coders exploring and experimenting

Developing in the cloud

Finding a database management system that works for you

Here are a few very prominent technologies that you can look into and what impact each one might have on your salary

What programming language should I learn next?

Android and iOS

Frontend Devs: What should I learn after JavaScript? Explore these frameworks and libraries

First, you’ve spread the logic across a variety of different systems, so it becomes more difficult to reason about the application as a whole. Second, more importantly, the logic has been implemented as configuration as opposed to code. The logic is constrained by the ability of the applications which have been wired together, but it’s still there.

the developer doesn’t need to worry about allocating memory, or the character set encoding of the string, or a host of other things.

“No Code” systems are extremely good for putting together proofs-of-concept which can demonstrate the value of moving forward with development.

With someone else’s platform, you often end up needing to construct elaborate work-arounds for missing functionality, or indeed cannot implement a required feature at all.

Summary

"Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes, and experiments — into production, or into the hands of users, safely and quickly in a sustainable way". -- Jez Humble and Dave Farley

Another approach is to use a tool like H2O to export the model as a POJO in a JAR Java library, which you can then add as a dependency in your application. The benefit of this approach is that you can train the models in a language familiar to Data Scientists, such as Python or R, and export the model as a compiled binary that runs in a different target environment (JVM), which can be faster at inference time

Continuous Delivery for Machine Learning (CD4ML) is a software engineering approach in which a cross-functional team produces machine learning applications based on code, data, and models in small and safe increments that can be reproduced and reliably released at any time, in short adaptation cycles.

In order to formalise the model training process in code, we used an open source tool called DVC (Data Science Version Control). It provides similar semantics to Git, but also solves a few ML-specific problems:

Machine Learning pipeline for our Sales Forecasting problem, and the 3 steps to automate it with DVC

Continuous Delivery for Machine Learning end-to-end process

common functional silos in large organizations can create barriers, stifling the ability to automate the end-to-end process of deploying ML applications to production

There are different types of testing that can be introduced in the ML workflow.

example of how to combine different test pyramids for data, model, and code in CD4ML

A deployment pipeline automates the process for getting software from version control into production, including all the stages, approvals, testing, and deployment to different environments

We chose to use GoCD as our Continuous Delivery tool, as it was built with the concept of pipelines as a first-class concern

Continuous Delivery for Machine Learning (CD4ML) is the discipline of bringing Continuous Delivery principles and practices to Machine Learning applications.

Sometimes, the best way to learn is to mimic others. Here are some great examples of projects that use documentation well:

“Code is more often read than written.” — Guido van Rossum

Documenting code is describing its use and functionality to your users. While it may be helpful in the development process, the main intended audience is the users.

Class method docstrings should contain the following: A brief description of what the method is and what it’s used for Any arguments (both required and optional) that are passed including keyword arguments Label any arguments that are considered optional or have a default value Any side effects that occur when executing the method Any exceptions that are raised Any restrictions on when the method can be called

Comments to your code should be kept brief and focused. Avoid using long comments when possible. Additionally, you should use the following four essential rules as suggested by Jeff Atwood:

From examining the type hinting, you can immediately tell that the function expects the input name to be of a type str, or string. You can also tell that the expected output of the function will be of a type str, or string, as well.

def hello_name(name: str) -> str:
    return(f"Hello {name}")

Docstrings can be further broken up into three major categories: Class Docstrings: Class and class methods Package and Module Docstrings: Package, modules, and functions Script Docstrings: Script and functions

According to PEP 8, comments should have a maximum length of 72 characters.

use `multiple line comment`

Docstring conventions are described within PEP 257. Their purpose is to provide your users with a brief overview of the object.

All multi-lined docstrings have the following parts: A one-line summary line A blank line proceeding the summary Any further elaboration for the docstring Another blank line

"""This is the summary line

This is the further elaboration of the docstring. Within this section,
you can elaborate further on details as appropriate for the situation.
Notice that the summary and the elaboration is separated by a blank new
line.

# Notice the blank line above. Code should continue on this line.

say_hello.__doc__ = "A simple function that says hello... Richie style"

def say_hello(name):
    print(f"Hello {name}, is it me you're looking for?")

say_hello.__doc__ = "A simple function that says hello... Richie style"

def say_hello(name):
    """A simple function that says hello... Richie style"""
    print(f"Hello {name}, is it me you're looking for?")

>>> help(say_hello)

Help on function say_hello in module __main__:

say_hello(name)
    A simple function that says hello... Richie style

class constructor parameters should be documented within the __init__ class method docstring

Scripts are considered to be single file executables run from the console. Docstrings for scripts are placed at the top of the file and should be documented well enough for users to be able to have a sufficient understanding of how to use the script.

Documenting your code, especially large projects, can be daunting. Thankfully there are some tools out and references to get you started

Commenting your code serves multiple purposes

In general, commenting is describing your code to/for developers. The intended main audience is the maintainers and developers of the Python code. In conjunction with well-written code, comments help to guide the reader to better understand your code and its purpose and design

Along with these tools, there are some additional tutorials, videos, and articles that can be useful when you are documenting your project

If you use argparse, then you can omit parameter-specific documentation, assuming it’s correctly been documented within the help parameter of the argparser.parser.add_argument function. It is recommended to use the __doc__ for the description parameter within argparse.ArgumentParser’s constructor.

There are specific docstrings formats that can be used to help docstring parsers and users have a familiar and known format.

Daniele Procida gave a wonderful PyCon 2017 talk and subsequent blog post about documenting Python projects. He mentions that all projects should have the following four major sections to help you focus your work:

Since everything in Python is an object, you can examine the directory of the object using the dir() command

Documenting your Python code is all centered on docstrings. These are built-in strings that, when configured correctly, can help your users and yourself with your project’s documentation.

Along with docstrings, Python also has the built-in function help() that prints out the objects docstring to the console.

The general layout of the project and its documentation should be as follows:

project_root/
│
├── project/  # Project source code
├── docs/
├── README
├── HOW_TO_CONTRIBUTE
├── CODE_OF_CONDUCT
├── examples.py

In all cases, the docstrings should use the triple-double quote (""") string format.

Each format makes tradeoffs in encoding, flexibility, and expressiveness to best suit a specific use case.

Computers can only natively store integers, so they need some way of representing decimal numbers. This representation comes with some degree of inaccuracy. That's why, more often than not, .1 + .2 != .3

Cross-platform development is now a standard because of wide variety of architectures like mobile devices, cloud servers, embedded IoT systems. It was almost exclusively PCs 20 years ago.

A package management ecosystem is essential for programming languages now. People simply don’t want to go through the hassle of finding, downloading and installing libraries anymore. 20 years ago we used to visit web sites, downloaded zip files, copied them to correct locations, added them to the paths in the build configuration and prayed that they worked.

IDEs and the programming languages are getting more and more distant from each other. 20 years ago an IDE was specifically developed for a single language, like Eclipse for Java, Visual Basic, Delphi for Pascal etc. Now, we have text editors like VS Code that can support any programming language with IDE like features.

Your project has no business value today unless it includes blockchain and AI, although a centralized and rule-based version would be much faster and more efficient.

Being a software development team now involves all team members performing a mysterious ritual of standing up together for 15 minutes in the morning and drawing occult symbols with post-its.

Language tooling is richer today. A programming language was usually a compiler and perhaps a debugger. Today, they usually come with the linter, source code formatter, template creators, self-update ability and a list of arguments that you can use in a debate against the competing language.

There is StackOverflow which simply didn’t exist back then. Asking a programming question involved talking to your colleagues.

Since we have much faster CPUs now, numerical calculations are done in Python which is much slower than Fortran. So numerical calculations basically take the same amount of time as they did 20 years ago.

I am not sure how but one kind soul somehow found the project, forked it, refactored it, "modernized" it, added linting, code sniffing, added CI and opened the pull request.

It is solved when you understand why it occurred and why it no longer does.

Let's reason through our memoizer before we write any code.

// Takes a reference to a function
const memoize = func => {
  // Creates a cache of results
  const results = {};
  // Returns a function
  return (...args) => {
    // Create a key for results cache
    const argsKey = JSON.stringify(args);
    // Only execute func if no cached value
    if (!results[argsKey]) {
      // Store function call result in cache
      results[argsKey] = func(...args);
    }
    // Return cached value
    return results[argsKey];
  };
};

Let's replicate our inefficientSquare example, but this time we'll use our memoizer to cache results.

The biggest problem with JSON.stringify is that it doesn't serialize certain inputs, like functions and Symbols (and anything you wouldn't find in JSON).

Memoization is an optimization technique used in many programming languages to reduce the number of redundant, expensive function calls. This is done by caching the return value of a function based on its inputs.

The best way to explain the difference between launch and attach is to think of a launch configuration as a recipe for how to start your app in debug mode before VS Code attaches to it, while an attach configuration is a recipe for how to connect VS Code's debugger to an app or process that's already running.

Logpoint is a variant of a breakpoint that does not "break" into the debugger but instead logs a message to the console. Logpoints are especially useful for injecting logging while debugging production servers that cannot be paused or stopped. A Logpoint is represented by a "diamond" shaped icon. Log messages are plain text but can include expressions to be evaluated within curly braces ('{}').

Here are some optional attributes available to all launch configurations

The following attributes are mandatory for every launch configuration

Many debuggers support some of the following attributes

Version control is at the heart of any modern engineering org. The ability for multiple engineers to asynchronously contribute to a codebase is crucial—and with notebooks, it’s very hard.

The priorities in building a production machine learning pipeline—the series of steps that take you from raw data to product—are not fundamentally different from those of general software engineering.

Reproducibility is an issue with notebooks. Because of the hidden state and the potential for arbitrary execution order, generating a result in a notebook isn’t always as simple as clicking “Run All.”

A notebook, at a very basic level, is just a bunch of JSON that references blocks of code and the order in which they should be executed.But notebooks prioritize presentation and interactivity at the expense of reproducibility. YAML is the other side of that coin, ignoring presentation in favor of simplicity and reproducibility—making it much better for production.

Notebook files, however, are essentially giant JSON documents that contain the base-64 encoding of images and binary data. For a complex notebook, it would be extremely hard for anyone to read through a plaintext diff and draw meaningful conclusions—a lot of it would just be rearranged JSON and unintelligible blocks of base-64.

There is no hidden state or arbitrary execution order in a YAML file, and any changes you make to it can easily be tracked by Git

Python unit testing libraries, like unittest, can be used within a notebook, but standard CI/CD tooling has trouble dealing with notebooks for the same reasons that notebook diffs are hard to read.

Use camelCase when naming objects, functions, and instances.

const thisIsMyFuction() {}

Use PascalCase only when naming constructors or classes.

// good
class User {
  constructor(options) {
    this.name = options.name;
  }
}

const good = new User({
  name: 'yup',
});

Use uppercase only in constants.

export const API_KEY = 'SOMEKEY';

If you'd just like to see refactorings without Quick Fixes, you can use the Refactor command (Ctrl+Shift+R).

Stary, dobry Uncle Bob mówi, że poza etatem trzeba na programowanie poświęcić 20h tygodniowo.Gdy podzielimy to na 7 dni w tygodniu, to wychodzi prawie 3 godziny dziennie.Dla jednych mało, dla innych dużo.

Suppose you have only two rolls of dice. then your best strategy would be to take the first roll if its outcome is more than its expected value (ie 3.5) and to roll again if it is less.

Therefore, En=2n+1−2=2(2n−1)

It's responsible for allocating and scheduling containers, providing then with abstracted functionality like internal networking and file storage, and then monitoring the health of all of these elements and stepping in to repair or adjust them as necessary.In short, it's all about abstracting how, when and where containers are run.

You’ll see pressure to push towards “Cloud neutral” solutions using Kubernetes in various places

Heroku? App Services? App Engine?

Kubernetes (often irritatingly abbreviated to k8s, along with it’s wonderful ecosystem of esoterically named additions like helm, and flux) requires a full time ops team to operate, and even in “managed vendor mode” on EKS/AKS/GKS the learning curve is far steeper than the alternatives.

Azure App Services, Google App Engine and AWS Lambda will be several orders of magnitude more productive for you as a programmer. They’ll be easier to operate in production, and more explicable and supported.

With the popularisation of docker and containers, there’s a lot of hype gone into things that provide “almost platform like” abstractions over Infrastructure-as-a-Service. These are all very expensive and hard work.

By using events that are buffered in queues, your system can support outage, scaling up and scaling down, and rolling upgrades without any special consideration. It’s normal mode of operation is “read from a queue”, and this doesn’t change in exceptional circumstances.

Reserved resources, capacity, or physical hardware can be protected for pieces of your software, so that an outage in one part of your system doesn’t ripple down to another.

The complimentary design pattern for all your circuit breakers – you need to make sure that you wrap all outbound connections in a retry policy, and a back-off.

Circuit breaking is a useful distributed system pattern where you model out-going connections as if they’re an electrical circuit. By measuring the success of calls over any given circuit, if calls start failing, you “blow the fuse”, queuing outbound requests rather than sending requests you know will fail.

“scaling out is the only cost-effective thing”, but plenty of successful companies managed to scale up with a handful of large machines or VMs

Scaling is hard if you try do it yourself, so absolutely don’t try do it yourself. Use vendor provided, cloud abstractions like Google App Engine, Azure Web Apps or AWS Lambda with autoscaling support enabled if you can possibly avoid it.

Hexagonal architectures, also known as “the ports and adapters” pattern

Good microservice design follows a few simple rules

What Microservices are supposed to be: Small, independently useful, independently versionable, independently shippable services that execute a specific domain function or operation. What Microservices often are: Brittle, co-dependent, myopic services that act as data access objects over HTTP that often fail in a domino like fashion.

In the mid-90s, “COM+” (Component Services) and SOAP were popular because they reduced the risk of deploying things, by splitting them into small components

all a design pattern is, is the answer to a problem that people solve so often, there’s an accepted way to solve it

Let’s do a quick run through of some very common ones:

CDNs are web servers run by other people, all over the world. You upload your data to them, and they will replicate your data across all of their “edges” (a silly term that just means “to all the servers all over the world that they run”) so that when someone requests your content, the DNS response will return a server that’s close to them, and the time it takes them to fetch that content will be much quicker.

Understanding how a distributed cache works is remarkably simple – when an item is added, the key (the thing you use to retrieve that item) that is generated includes the address or name of the computer that’s storing that data in the cache. Generating keys on any of the computers that are part of the distributed cache cluster will result in the same key. This means that when the client libraries that interact with the cache are used, they understand which computer they must call to retrieve the data.