how the code maps to the real world

why the code maps to the real world

the programmer can respond to a change request

lien avec l’importance que j’accorde au fait de faciliter l’onboarding

lien avec mon goût pour tout ce qui facilite le fait de se construire simplement un modèle mental (accès simple aux données, outils ergonomiques, etc.).

Teaching is an undervalued skill, especially in senior developers

Retaining talent is even more important than you might think.

The Theory Building View also gives us insights on how to structure onboarding processes. It helps to explain why new developers often takes a very long time until they reach full productivity

par exemple : en value-semantics, si on ne travaille pas sur l’objet lui-même mais sur une copie qui a la même valeur, ça n’est pas grave

par exemple : si on veut trier un tableau in-place, on veut trier le tableau lui-même (on veut le muter), et non pas une copie qui a le même contenu

plus simple, car c’est ce qu’on a par défaut

plus proche du concept mathématique de fonction (functional programming FTW)

pas de memory-management à faire, car les objets ont un storage duration automatique

pas de problème de reference aliasing. Chaque thread a sa propre copie → pas de data-race.

referential transparency (TL;DR : on peut remplacer l’invocation d’une fonction par son résultat, ce qui n’est pas le cas si la fonction mute ses paramètres, car elle a alors des side-effects)

pour que plusieurs entités modifient le même objet, ils doivent manipuler une référence (e.g. std::cout, qui est global, et qui peut être utilisé à plusieurs endroits du code)

pour profiter de fonctionnalités nécessitant des pointeurs ou des références (e.g. polymorphisme)

pour gagner en perf en évitant de recopier de gros objets

général purpose cpu

GPU

embedded processors

C’est le point principal du talk : When we write C++ code, we are writing to the C++ abstract machine

En résumé, le dev est en charge d’écrire du code pour l’abstract machine, le compilo est en charge d’écrire du code pour la physical machine (fort heureusement nommé code machine)

L’observable behaviour de l’abstract machine et de la physical machine sera identique.

Memory

Objects

Threads

C’est un concept plus général que les atomic du C++ : c’est le A de Acid, par exemple (alors même qu’une transaction peut concerner des milliers d’istructions)

Sans memory barriers, chaque cpu (donc chaque thread) voit un état indépendant de la mémoire. La MB permet de synchroniser les cachelines des cpus.

Relaxed = pas de garantie sur l’ordre des instructions mémoire

Acquire = aucune opération ne peut être déplacée avant la barrière

Release = le contraire : aucune opération ne peut être déplacée APRÈS la barrière (valable même pour tout le code, y compris pour les variables non-atomiques !)

Utilisées conjointement sur la même atomic, release store dans un thread1 + acquire load dans un thread2 permet de synchroniser des threads, y compris sur des lectures / écritures de variables non atomic

Il y a deux autres memory order.

Si on ne précise pas l’ordre, le défaut est d’utiliser le plus fort : plus safe, mais moins efficace

03:00 with locks, either simplicity or scalability

03:30 mesurer avant (pour vérifier qu’on adresse bien le bon problème), et après (pour vérifier qu’on a bien avancé dans la bonne direction)

05:00 useful to see locks as trafic lights

06:00 analogie intéressante avec échangeur d’autoroute

07:30 lockfree = transactional thinking + atomic

17:00 wait-free vs lock-free vs obstruction-free

18:30 double check locking (pour ne pas avoir à prendre le lock pour rien) utile pour initialiser un singleton, mais l’atomic reste indispensable

22:00 les atomics ont des memory-barriers implicites (donc ne sont pas réordonnées).

24:40 atomic store peut avoir un fort overhead, mais pas atomic load.

27:00 call_once pour initialiser un truc une seule fois

36:30 les invariants doivent être vrais aux frontières des sections critiques

38:00 locking + lockfree

45:00 et autour : ce qui est important pour le lockfree, c’est de comprendre comment les différents threads travaillent avec l’atomic

55:00 (environ) : la question de savoir si travaille le plus vite (donc qui sera sous-utilisé) entre le producer et les consumers est importante pour choisir comment implémenter l’algo lockfree.

~13:00 ABA problème : on a un pointeur sur un T*, mais la même adresse pointe successivement vers deux objets différents (le premier a été détruit, et son adresse a été réutilisée pour créer le second)

~26:00 utilisation de référence counting (shared ptr) pour être robuste à la concurrency.

28:30 linearizability = même si deux opérations overlappent, tout se passe comme si elles avaient plutôt été successives car protégées par mutex.

Ndm : compare_exchange permet le pattern suivant, permettant de remplacer p par p→next, y compris en cas d’utilisation concurrente, tout en évitant les problèmes de TOCTOU :

auto p = head.load();
while(p && head.compare_exchange_weak(p, p->next)) {}

L’idée est que s’il n’y a pas d’accès concurrent, on fera l’échange directement. Mais si p a changé depuis qu’on l’a lu (ou plutôt load), alors on recommence avec la NOUVELLE valeur de p (car en cas d’échec, compare_exchange fait un load de la NOUVELLE valeur de p)

51:00 :

La façon de mesurer les perfs dans un contexte concurrent (sur les 20 dernières minutes) est très intéressante. (À 01:07:15, il y a un autre graphique intéressant)

Plus généralement, c’est un rex concret d’optimisation multithread super (et guidé par des mesures!)

56:30 pour améliorer les perfs, un point intéressant : je peux dégrader les perfs d’un thread (e.g. en faisant plus de heap allocation) si ça permet plus de parallelisation (e.g. en ayant moins de code dans une section critique).

01:06:00 alignas pour éviter le false sharing

01:09:40 si on dépasse la "subscription boundary" (i.e. si on commence à avoir plus de threads que de cores), il y a une brutale discontinuité dans les perfs

01:10:00 to improve scalability, minimize contention

Le réseau est fiable.

Le temps de latence est nul.

La bande passante est infinie.

Le réseau est sûr.

La topologie du réseau ne change pas.

Il y a un et un seul administrateur réseau.

Le coût de transport est nul.

Le réseau est homogène.

"sainte-trinité" = règle de 3, de 5 ou de zéro selon les versions

TL;DR : soit tu ne définis aucune des 5 fonctions suivantes toi-même, soit tu les définis tous :

attention : il y a des règles particulières indiquant si le compilo définira ou non lui-même ces fonctions

Plutôt qu’une règle absolue, c’est une bonne pratique, qui invite à double-checker lorsqu’on est amenés à ne pas la suivre.

le cas où il faut les définir soi-même est le cas où la classe est responsable d’une ressource (et dans ce cas, mieux vaut que ce soit sa seule responsabilité)

règle étendue = 3½ / 5½ : ajoute la fonction swap aux 5 fonctions ci-dessus

par ailleurs, l’article porte un regard intéressant sur les langages qui poussent la value-semantic, et ceux qui poussent la reference-semantic

soit tu implémentes les 3(5) opérateurs, soit tu n’en implémentes aucun

tu implémentes les 3(5) :

si tu n’en implémentes aucun :

accès à un objet

ça veut dire quoi construire l’objet

ça veut dire quoi finaliser l’objet (aka destruction)

ça veut dire quoi dupliquer l’objet

construction par copie = appeler le constructeur de copie de chacun des attributs

affectation = appeler l’affectation de chacun des attributs

destruction = appeler le destructeur de chacun des attributs

constructeur = mettre en place les invariants de l’objet construit

opérations de copie = maintenir ces invariants (parmi d’autres rôles)

destructeur = assurer la saine libération des ressources dont est responsable l’objet

allocation dynamique de mémoire

ouverture d’un stream (NdM ou d’un fichier)

prise en charge d’un mutex ou autre mécanisme de synchronisation

(NdM : database connection, …​)

NdM : à mes yeux, cette guideline est la plus importante qui va avec la règle de 5 : si un objet prend la responsabilité d’une ressource, il faut définir les 5 opérations

en effet : si l’objet n’est pas RESPONSABLE des objets pointés (dans le sens où il doit penser à les détruire), il n’est pas oblité de définir les 3 opérations de la sainte-trinité

NdM : l’opposition reference-semantic vs. value-semantic semble être regroupée sous le terme "sémantique d’accès".

java/C# = reference-semantic :

C++ = value-semantic :

L’article explique qu’avoir une sémantique de valeur implique qu’il est plus important de savoir ce que représente une copie d’objet :

De même l’implication avec le fait qu’il est plus important (qu’avec une reference-semantic) de bien savoir ce qu’est un destructeur n’est pas claire…​

EDIT : il clarifie ailleurs :

EDIT 2 : et il détaille encore plus dans le chapitre "Risques du partage" :

EDIT 3 : cette autre ressource listée en bas de page donne des billes :

comme la classe est responsable d’une ressource, il faut savoir quoi faire à la copy-construction, ou à la copy-affectation

en l’occurence, unique_ptr n’est pas copiable ou assignable par copie : deux instances de unique_ptr ne peuvent pas gérer le même objet.

(mais il peut transférer la responsabilité de l’objet qu’il gère via des move-operations)

les 5 opérations de la règle des 5 sont générées automatiquement par le compilateur, sauf si l’utilisateur en a défini au moins une lui-même

si l’utilisateur empêche le compilo de définir les autres opérations parmi les 5, elles sont considérées comme =delete

règle de zéro : pour une classe qui n’est pas explicitement responsable de ressources, mieux vaut ne coder aucune des opérations de la règle de cinq

https://en.cppreference.com/w/cpp/language/rule_of_three

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-zero

type-erased = "interface" = on est générique vis-à-vis du type réel sur lequel on travaille

le fil rouge de l’article est la recherche dans un conteneur trié via un binary search

pas de type-erasure, templatization → le plus rapide, mais on a les inconénients des templates

void* type-erasure = pas terrible car pas type-safe + ne fonctionne qu’avec des arrays

OO-based type-erasure = pas terrible car nombreux problèmes (notamment, force d’hériter d’un type)

template-based type-erasure = pas parfait, mais mieux que le reste, notamment : type-safe + templatization uniquement sur le type de l’objet lui-même

l’article se poursuit avec deux autres articles : part II, part III

Le compilateur choisit statiquement la bonne spécialisation de cout en fonction du type de s ou i.

void print (string s, int i)
{
    cout << s;
    cout << i;
}

Ici, le type (non-erased) contient donc des informations utiles au compilateur.

cout::operator<< est polymorphic, car il se comporte différemment lorsqu’appelé avec des variables différentes.

Point important : il n’y a PAS de runtime-dispatch : c’est bien au compile-time que le dispatch a lieu → pas d’overhead au runtime.

en C : bsearch, utilisant une fonction de comparaison, qui accepte des void*

en C++ : std::equal_range

int c_bigger (const void * a, const void * b)
{
    return *(int*)b - *(int*)a;
}

l’équivalent en C++ utilise une lambda comme fonction, et est plus rapide qu’en C

en C, le compilo n’est pas aware du type de la fonction de comparaison, et du fait qu’elle travaille sur deux int → pas d’optimisation possible, on déréférencera au runtime le pointeur de fonction

du coup, ici, l’utilisation de template permet d’aller plus vite au runtime

TL;DR : on fait un trade-off : utiliser les templates (fast-runtime, slow build) ou ne pas les utiliser (le contraire)

binaire plus gros (vu qu’on a une instanciation par "spécialisation")

compile-time slow down

le body de la fonction doit être visible (dans le header), et on doit donc exposer toutes les dépendances (les headers dont notre template a besoin) → compile-time encore plus lent

messages d’erreur des template-instanciation souvent illisibles

programmes plus rapides que leurs équivalents non-templates

type-safety par rapport aux équivalents non-templates

exemple = le bsearch de C : au runtime, on a une indirection pour utiliser un pointeur de fonction

note : cf. "man bsearch" la signature de bsearch attend un pointeur de fonction qui a cette signature :

int (*compar)(const void *, const void *)

le code de la fonction de comparaison va caster les void* en int pour pouvoir les comparer (c_bigger plus haut)

citation : bsearch is in fact an example of basic type erasure. It is one function, with one interface that works for arrays of any element type.

TL;DR : en C, void* permet d’être générique sur le type des éléments qu’on passe à une fonction

utiliser void* permet d’overloader bsearch au runtime, qui marche dorénavant avec TOUT type de tableau

problèmes :

tous les objets héritent d’un même classe, toutes les classes filles implémentent un opérateur de comparaison avec un autre Object* (qui throw lorsque l’Object auquel on compare n’est pas du bon type)

int i_bigger (const Object* a, const Object* b)
{
  auto ia = dynamic_cast<MyInteger const*>(a);
  auto ib = dynamic_cast<MyInteger const*>(b);

  if (ia == nullptr || ib == nullptr) {
    throw SomeException{};
  }

  return ib->getInt() - ia->getInt();
}

Object* OO_search (Object** base,
                   size_t size,
                   int (*comp)(const Object*, const Object*)

on a UN PEU amélioré la situation : au lieu d’un UB, on a une exception au runtime lorsqu’on compare des objets non-comparables

beaucoup de problèmes :

pour être type-safe, on n’aura pas le choix, faut rester sur des templates…​

on utilise std::function pour abstraire le type de la fonction de comparaison (qui peut être n’importe quoi, tant qu’on peut lui appliquer f(int, int)) :

std::function<bool(int,int)> predicate;

alias template :

template <typename T>
using AnyBinaryPredicate = std::function<bool(T const&, T const&)>;

citation :

de la même façon qu’on a fait une "interface template" pour représenter des fonctions, on va faire une "interface template" pour représenter des itérateurs sur un type T.

On utilise une lib "any_iterator", le code est très illustratif :

std::vector<int> vec {1, 2, 3};
std::list<int> list {2, 4, 6};

AnyForwardIter<int> it { vec.begin() }; // initialize
it = list.begin();                      // rebind

on peut aussi utiliser un type-erased range :

boost::any_range, le code est très illustratif :

std::vector<int> vec {9, 8, 5, 4, 2, 1, 1, 0};
std::set<int> set {1, 2, 3, 5, 7, 9};

AnyForwardRange<int> rng = vec; // initialize interface
std::distance (boost::begin(rng), boost::end(rng));

rng = set;                      // rebind interface
std::distance (boost::begin(rng), boost::end(rng));

note : ça a l’air important : les interface typed-erased ci-dessus préservent la "value-semantic" = ce qui nous intéresse, c’est pas les objets eux-mêmes, c’est leur contenu

grâce à range et std::function, on a un algo qui n’est plus que templaté sur T (alors que pour une version template-pure, il était également templaté sur le type du conteneur (via l’iterator) et le type du prédicat) :

Thus, we have two value-semantic type-erased interfaces: AnyForwardRange<T> and AnyBinaryPredicate<T>. Using them we can define our (partially) type-erased searching function:

template <typename T>
AnyForwardRange<T> Search (AnyForwardRange<T> rng, T const& v,
                           AnyBinaryPredicate<T> pred)
{
  auto ans = std::equal_range (rng.begin(), rng.end(), v, pred);
  return {ans.first, ans.second};
}

défauts :

rwPosition : variable represents a row ("rw");

usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)

lAccountNum : variable is a long integer ("l");

strName : Variable represents a string ("str") containing the name, but does not specify how that string is implemented.

bad car fait doublon avec le type-system (d’où p.ex. possible désynchro entre le type préfixé et le type réel). Tire son origine d’une incompréhension de la notation hongroise par l’équipe système de Microsoft.

la console est "ce qui permet d’interagir avec l’ordinateur" (par analogie avec le meuble), c’est l’ensemble terminal+shell

le terminal reçoit le signal du clavier, et en déduit une séquence de caractères ASCII à envoyer au shell

le shell est un REPL autour du kernel, c’est un wrapper permettant d’interagir avec le kernel (y compris de lancer des programmes)

le shell reçoit et interprète la séquence de caractère, en fonction du terminal qui l’a envoyé

p.ex. l’envvar du shell a p.ex. la valeur VT100 alors qu’on utilise un terminal VT220

et le terminal VT220 utilise TATA comme séquence de caractères identifiant "Fin", alors que VT100 utilise TOTO

du coup, à l’appui sur "Fin", notre terminal VT220 envoie "TATA"

le shell reçoit "TATA", et regarde si c’est une séquence spéciale pour le TERM qu’il utilise (VT100)

ce n’est pas le cas (en effet, VT100 utilise "TOTO" pour "Fin"), du coup il considère que la séquence n’est pas spéciale, et l’affiche…​

terminal réel (sur les consoles physiques de l’époque, ou un teletype, ou encore un terminal hardware spécifique comme le VT100)

terminal virtuel (sur l’ordinateur, p.ex. Ctrl+Alt+F1)

terminal émulé (e.g. xterm, gnome-terminal, …​.)

terminal multiplexé (e.g. tmux, gnu screen)

A virtual terminal or virtual console is a program that simulates a physical terminal.

For example, both the Linux kernel and BSD kernels support virtual terminals - terminals that are logically separate, but which access the same physical keyboard and monitor.

The virtual terminal gives the impression that several independent terminals are running concurrently.

Each virtual terminal can be logged in with a different user and it can run its own shell and have its own font settings.

Il faut comprendre ces phrases comme :

à chaque terminal virtuel est associé un /dev/ttyX

(attention à ne pas confondre un terminal virtuel avec un terminal émulé)

A terminal emulator is a computer program that emulates a physical terminal within some other display architecture, such as the X Window System.

Un terminal parent permettant de se connecter à l’ordinateur (ici, le serveur X, mais ça pourrait être un terminal virtuel) va lancer un programme qui émule un terminal

Ce programme va donc capturer les inputs clavier (et transmettre des caractères ASCII à un shell) et afficher les outputs du shell (ou de ses sous-programmes).

À la base, ces terminaux émulent des machines physiques (e.g. VT100)

The purpose of the terminal emulator is to allow access to the command line (NdM : to the shell, plutôt) while working in a graphical user interface, such as the X Window System.

Since the shell is "expecting" to interface with a human through a terminal, and we don’t use a physical terminal while in a graphical environment, we need the terminal emulator.

Ma compréhension est qu’un émulateur de terminal donné peut émuler plusieurs terminaux (dit autrement, il peut associer plusieurs séquences ASCII différentes à la touche "Fin")

Il est important de comprendre qu’un émulateur de terminal est un programme GRAPHIQUE (car il émule la sortie vidéo du terminal, et donne accès à une console)

The environment variable TERM tells applications the name of a terminal description to read from the terminfo database (see man terminfo).

Each description consists of a number of named capabilities which tell applications what to send to control the terminal.

For example, the cup capability contains the escape sequence used to move the cursor up.

Ma compréhension : grâce à TERM, une application sait que si elle reçoit "TOTO", il faut qu’elle bouge le curseur en fin de ligne.

The terminal interprets these ANSI sequences as commands, rather than text to display verbatim.

An escape sequence is a combination of characters that has a meaning other than the literal characters contained therein.

ANSI sequences were introduced in the 1970s to replace vendor-specific sequences

Although hardware text terminals have become increasingly rare in the 21st century, the relevance of the ANSI standard persists

because a great majority of terminal emulators and command consoles interpret at least a portion of the ANSI standard.

[The VT100] was one of the first terminals to support ANSI escape codes for cursor control and other tasks, and added a number of extended codes for special features like controlling the status lights on the keyboard.

This led to rapid uptake of the ANSI standard, becoming the de facto standard for terminal emulators.

sur la page wikipedia :

The operating system is the interface between the user and the hardware.

A shell process is the program that prompts you for input, takes your commands, and runs them for you.

It is a computer program that serves as a command-line interpreter. The shell implements a read-eval-print loop (REPL).

The most generic sense of the term "shell" means any program that users employ to type commands.

You enter commands at this input prompt and the shell acts as a "command interpreter".

The shell takes each command and passes it to the operating system kernel to handle.

The shell then parses the result of this action back to the terminal.

The shell is both an interactive command language and a scripting language, and is used by the operating system to control the execution of the system using shell scripts.

The shell exposes the operating system’s services to a human user or other programs.

The shell knows nothing about displaying characters on the monitor or about handling input keystroke codes from the keyboard - that is up to the hardware and software that is implementing the terminal.

ce groupe de 6 pages contient les bonnes pratiques à suivre lorsqu’on fait de la revue de code, en tant que reviewer

il existe également l’équivalent en tant que reviewee

il n’y a que 6 courtes pages, très faciles à lire, et contenant des conseils très concrets → ne pas hésiter à y revenir (d’ailleurs, je vais les mettre dans mes références)

The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time. (NdM : j’ai un objectif supplémentaire = m’améliorer/aider le reviewee à s’améliorer ; cf. la section Mentoring).

trade-off entre être très picky, mais ne jamais faire avancer le schmilblick, ou être trop lâche, et dégrader la qualité

In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.

A key point here is that there is no such thing as “perfect” code—there is only better code. Reviewers should not require the author to polish every tiny piece of a CL before granting approval.

A CL that, as a whole, improves the maintainability, readability, and understandability of the system shouldn’t be delayed for days or weeks because it isn’t “perfect.”

Reviewers should always feel free to leave comments expressing that something could be better, but if it’s not very important, prefix it with something like “Nit: “ to let the author know that it’s just a point of polish that they could choose to ignore.

Principles :

Don’t let a CL [=ChangeList] sit around because the author and the reviewer can’t come to an agreement.

Design

Functionality

Complexity

Tests

Naming

Comments

Style

Consistency

Every Line : Look at every line of code that you have been assigned to review. […​] If it’s too hard for you to read the code and this is slowing down the review, then you should let the developer know that and wait for them to clarify it before you try to review it.

Good Things : If you see something nice in the CL, tell the developer, especially when they addressed one of your comments in a great way.

Le summary de la page donne de nouveau des conseils très concrets et très intéresssants.

Does the change make sense? Does it have a good description?

Look at the most important part of the change first. Is it well-designed overall?

Look at the rest of the CL in an appropriate sequence.

If the CL is too large for you to figure out which parts are the major parts, ask the developer what you should look at first, or ask them to split up the CL into multiple CLs.

If you see some major design problems with this part of the CL, you should send those comments immediately, even if you don’t have time to review the rest of the CL right now.

TL;DR : avoir un process de code-review trop lent est très impactant pour l’équipe.

One business day is the maximum time it should take to respond to a code review request (i.e. first thing the next morning).

On parle bien du temps entre le moment où un dev soumet une PR, et le moment où il obtient des retours (et non du temps entre le moment où la PR est soumise, et le moment où elle est mergée)

It is important that reviewers spend enough time on review that they are certain their “LGTM” means “this code meets our standards.” However, individual responses should still ideally be fast.

If somebody sends you a code review that is so large you’re not sure when you will be able to have time to review it, your typical response should be to ask the developer to split the CL into several smaller CLs that build on each other,

note : le cas des urgences est un cas particulier, et traité à part

Be kind.

Explain your reasoning.

Balance giving explicit directions with just pointing out problems and letting the developer decide.

Encourage developers to simplify code or add code comments instead of just explaining the complexity to you.

Explanations written only in the code review tool are not helpful to future code readers.

TL;DR : échanger en bonne intelligence, ne pas retarder le cleanup.

une façon de lutter contre les râleries "ta revue est trop stricte", c’est de les faire rapidement

constructeur = laisse l’objet dans un état utilisable

on peut copier proprement un objet

on peut le détruire, et la destruction cleane proprement les états

(NdM : la quote s’applique aux objets qui gèrent des ressources)

En pratique, on ne peut pas toujours suivre la Rule of Zero, et il faut parfois gérer explicitement les membres (e.g. si on implémente une classe de type string, il faut gérer le buffer accueillant la string) ; dans ce cas, il faut respecter la Rule Of Five.

Write a destructor that deletes any owned resource.

Write a copy constructor that duplicates any owned resource and takes ownership of it.

Write a non-throwing swap() function that will exchange the contents of two containers by swapping the internal bits.

Write the copy-assignment operator by making a temporary copy of the source object, then swap the copy with this.

T& operator=(const T& rhs)
{
  T tmp(rhs);  // pas d'impact si exception ici
  swap(tmp);  // non-throwing
  return *this;
}

à s’assurer d’être robuste aux exceptions dans l’implémentation du copy-assignment operator :

L’intérêt : le swap ne peut pas throw + la construction a lieu dans un objet temporaire, détruit en fin de scope → ce code, pourtant simple, est robuste aux exceptions.

(et l’idiome a un frère-jumeau pour le move-assignment operator)

heap-allocation systématique, car la classe gère des ressources (sans quoi on n’aurait pas besoin de suivre la rule of five)

exemple : si la classe T est une classe gérant un array de int (un genre de vector<`int`>)

si elle contient actuellement 5 ints

si on essaye de lui copy-assigner un T contenant 5 autres int

alors en pratique, on n’a PAS besoin d’une allocation dynamique, vu qu’il suffit de remplacer les 5 ints précédents par les 5 nouveaux ints

or, avec le Copy-And-Swap, on va créer un objet temporaire (avec la heap-allocation qui va avec) quoi qu’il arrive.

les 5 ints du T rhs depuis lequel on copy-assign

les 5 ints que le T contient AVANT la copy-assignation

les 5 ints du T temporaire que l’on vient de construire

Alors qu’en pratique, seuls les deux premiers sont indispensables.

les compromis sont pas toujours bons (tractations, capitulation, …​)

il y a deux types de désaccord : bloquant ou "je peux vivre avec", à traiter différemment (ça fait

c’est ok d’avancer avec une solution qui ne satisfait pas tout le monde, tant que l’insatisfaction est "j’aurais pas fait ça mais je peux vivre avec"

Coming to consensus by looking for objections, (plutôt que de voter, p.ex.)

tracking open issues, (pour savoir si oui ou non il y a consensus)

using hums as the start of discussions (technique rigolote, mais n’a pas une valeur mirobolante à mes yeux)

“Not the best choice” versus fundamental flaws feedback

Once everyone can live with a given solution, you’ve reached rough consensus, even if there are outstanding objections.

bloquant (e.g. il y a un défaut fatal dans le design)

"j’aurais pas fait comme ça mais je peux vivre avec"

tractations = j’accepte tes remarques si tu acceptes les miennes

capitulation = j’abandonne la défense de mes idées par flemme ou fatigue

il faut ABSOLUMENT qu’on atteigne le degré maximal de qualité

il faut avancer, et le fait que la solution retenue n’est pas optimale n’est pas critique

Any finding of rough consensus needs, at some level, to provide a reasoned explanation to the person(s) raising the issue of why their concern is not going to be accommodated.

A good outcome is for the objector to understand the decision taken and accept the outcome, even though their particular issue is not being accommodated in the final product.

we come to consensus by looking at the open issues and not counting heads (aka pas de vote)

One hundred people for and five people against might not be rough consensus […​] If there is a minority of folks who have a valid technical objection, that objection must be dealt with before consensus can be declared. It’s the existence of the unaddressed open issue, not the number of people, which is determinative in judging consensus.

Coming to consensus is not the goal in itself. Coming to consensus is what we do during our processes to arrive at the best solution. In particular, "declaring" consensus is not an end goal. Attempts to declare consensus at the end of a discussion just for the sake of being able to say that there is consensus often get us back into the voting mentality that we’re trying to avoid.

Five people for and one hundred people against might still be rough consensus.

Sometimes, the hum will make it clear that choice "foo" has a significant amount more support than choice "bar", and it is therefore likely easier to start the discussion by saying, "OK, 'foo' seems to have quite a bit of support. Let’s have the people that think 'foo' is a bad idea come up and tell us why it is problematic." […​] All that the hum does is give the chair a starting point

The advantage of the hum (par rapport au vote) is that it makes it perfectly clear that the chair is simply figuring out the direction of the conversation.

20:05 si j’essaye d’être futé À TORT, le compilo est capable de s’en rendre compte et de me corriger

21:05 il vaut mieux essayer d’être explicite sur l’intention que j’ai, pour que le compilo puisse trouver la meilleure façon de le faire

21:20 trust the compiler to do the right thing, don’t try to be clever

30:20 version lisible de la vectorization effectuée par le compilateur

31:05 le même algo implémenté "correctement" (i.e. de façon idiomatique)

33:10 le compilo N’EST PAS CAPABLE (sur x86-64, en tout cas) de vectoriser la somme des carrés d’un vector de char → il vaut mieux rester à des ints !

34:25 vu par un processeur, l’addition de flottants n’est pas commutative ou associative ! (alors que l’addition d’entiers l’est). C’est à cause de la précision relative des flottants : la précision d’un flottant dépend de sa valeur (cf. https://fabiensanglard.net/floating_point_visually_explained/)

41:30 clang reconnaît qu’on essaye de compter les bits, et utilise l’instruction dédiée

44:30 idem pour le fait de changer d’endianness

45:00 comparaison futée pour savoir si un caractère appartient à un jeu donné

49:20 si on utilise une fonction qui n’est pas visible par le compilo (e.g. pas dans l’unite de compilation), il ne pourra pas optimiser

50:30 on peut tout de même donner de l’info au compilo via pour dire que la fonction est pure → il retrouve la possibilité d’opitmiser

51:40 en plus de la vtable, les fonctions virtuelles EMPÊCHENT les compilos de savoir quels sont les effets des fonctions, et donc de les optimiser (car une fonction virtuelle peut…​ faire n’importe quoi)

53:20 wow, inline virtual function ! "au cas où" la fonction appelée est bien la fonction qui m’intéresse, on l’optimise !!

55:00 le compilo peut pas optimiser, car il peut pas vérifier que mTotal n’overlappe pas avec le vector lu. Juste changer le type suffit à aider.

compilers are cleverer than we are + assembly isn’t THAT scary

trust your compiler

don’t compromise readability

attention à l’aliasing (si le compilo n’est pas capable de prouver l’absence d’aliasing, il ne pourra pas optimiser)

attention à la visibilité des fonctions (il faut que le compilo puisse inspecter pour optimiser)

un document papier que détient un collègue, sur lequel je dois travailler :

j’ai une bouteille que je veux remplir, et c’est quelqu’un d’autre qui a le robinet :

problème découpable en sous-problèmes discrets

le problème a une optimal substructure : la combinaison de solutions optimales à des sous-problèmes doit donner naissance à une solution optimale au problème global

NdM : j’ajoute "les sous-problèmes se recouvrent" (sans quoi inutile de faire de la prog dynamique, on peut faire un classique divide-and-conquer)

expression du problème sous forme d’une relation de récurrence ← c’est la partie difficile

condition d’arrêt

memoization

Les objets ont un poids wi et une valeur vi.

on récurse sur l’indice i de l’objet parmi les N objets (en partant de la fin du tableau des objets).

la donnée pertinente est V[i][w] = le valeur maximale qu’on peut transporter dans un sac de capacité w, en ne considérant que les i premiers objets. Elle est issue de la combinaison optimale des i premiers objets dans le tableau (ce sont les objets "restants", vu qu’on a commencé à la fin du tableau)

notamment, la relation de récurrence indique que lorsqu’on traite l’objet i, on retient le MAX entre :

en quelque sorte, ce max "choisit" si on mets ou non l’objet i dans le sac, en supposant connue la façon optimale d’agencer les i-1 objets précédents dans un sac (de poids w ou w-wi).

et c’est ce qu’on veut au plus haut niveau : V[N][W] choisit si on mets le dernier objet (d’indice N) dans le sac de poids W, en supposant connue la meillere façon de mettre les N-1 objets dans un sac de capacité W (si on ne retient pas l’objet N) ou de capacité W-wn (si on retient l’objet N)

dans le cadre du rendu de monnaie, commencer par se limiter à rechercher le nombre de pièces minimal

dans le cadre du sac à dos, commencer par se limiter à rechercher la valeur maximale

dans le cadre de Bellman-Ford, commencer par rechercher le poids du plus court chemin

à noter que lorsque la complexité algorithmique dépend d’une VALEUR plutôt que d’une TAILLE, on l’exprime sous forme du nombre de bits de sa représentation, i.e. complexité_VALEUR = log2(VALEUR)

ici, l’approche bottom-up avec deux boucles imbriquées montre que la complexité est en N.W où N est le nombre d’objets, et W la capacité du sac-à-dos

MAIS comme la capacité est une valeur, on utilise son nombre de bits : W = 2 ^ log2(W) = 2 ^ complexité_W, et la complexité de l’algo est en fait exponentielle en la taille de W

back pressure = resistance that opposes the flow of data through a system

back pressure management = moyen de faire en sorte que la back pressure ne pose pas problème

dans l’article (et ailleurs), on peut lire des choses comme this library doesn’t have back pressure, mais il faut lire this library doesn’t have back pressure MANAGEMENT

quand on veut faire voyager des bagages, on les mets (= produits) dans un container

lorsqu’un container est plein, il est alors chargé (= consommé) dans un avion

backpressure = quid si de nouveaux bagages arrivent alors qu’on n’a plus de containers de disponibles à charger ?

buffering = on garde le bagage de côté, et on attend qu’un nouveau container vide arrive

dropping = on brûle discrètement le bagage en trop sur le côté de l’aéroport

control the producer = on avertit l’aéroport de ne plus accepter de nouveau bagage

exemple donné avec un echo server

en asyncio : le serveur accepte toutes les connexions, y compris quand il ne pourra pas les traiter : mais si le write buffer est plein, la lib va bufferiser indéfiniment

en synchrone : lorsque le pool de threads capable d’accepter une connexion est vide (tous les threads sont occupés), la connexion va être mise en attente / refusée

le service doit être capable de connaître son état : "prêt à traiter" ou "surchargé, je ne traiterai pas une prochaine requête"

si une requête arrive alors que le service est surchargé, on retourne 503 (éventuellement, en indiquant dans combien de temps réessayer avec le header retry-after)

en gros : plutôt que d’essayer de répondre à toute requête qu’on nous passe (et c’est niveau OS que ça va bloquer), on faile early si on voit qu’on est surchargé

ce qui est exposé ci-dessus marche bien pour des patterns de type request→response, mais pour des patterns de type stream c’est plus compliqué

normalement, il y a du control-flow intégré dans TCP, mais en pratique, des mécanismes de flow-control custom sont souvent implémentés par dessus. Par exemple, en HTTP2, plusieurs streams peuvent être multiplexés sur une seule connexion TCP, d’où le besoin d’un mécanisme custom de flow-control.

MAIS le fait que le mécanisme de flow-control de TCP soit plutôt invisible (en effet, il n’est pas accessible via l’API socket) est DANGEREUX : le dev PEUT faire comme si c’était transparent pour lui, alor qu’il FAUT qu’il prenne en compte le cas où il y a de la backpressure : lorsqu’on implémente un protocole de streaming, il FAUT qu’il soit bidirectionnel : du client vers le serveur pour envoyer les données ET du serveur vers le client pour réguler la vitesse

et ça c’est pas trivial du tout !

buffering = on accumule les messages en trop dans un buffer, en espérant pouvoir les dépiler lorsque le pic de charge sera passé. inconvénient = attention à ce que le buffer ne grossisse pas indéfiniment + quid si le buffer est plein ?

dropping = on droppe les messages en trop. inconvénient = on perd des messages.

control the producer (flow control) = on avertit le producteur qu’il va trop vite, et qu’il doit ralentir. La meilleure solution si elle est disponible. inconvénient = pas toujours réalisable + peut-être compliquée à implémenter.

buffering = on garde le bagage de côté, et on attend qu’un nouveau container vide arrive

dropping = on brûle discrètement le bagage en trop sur le côté de l’aéroport

control the producer = on avertit l’aéroport de ne plus accepter de nouveau bagage

mathématiquement, les 32bits-CRC de deux messages différents seront obligatoirement inégaux si la différence de message est < 32 bits, quel que soit le message.

(ils seront sans doute inégaux même pour des différences plus importantes)

Mais même si les CRC sont inégaux, ils peuvent être très similaires, et on s’en fiche : l’important c’est qu’on puisse dire "si les CRC sont différents, le message a été altéré"

deux messages différents mais très proches doivent produire des digest aussi dissemblables que deux messages différents et très éloignés

dit autrement : étant donné deux digests différents, on ne doit pas être capables de dire si les messages initiaux étaient proches ou non (à la différence des CRC)

une autre façon de voir ça : si on change un seul bit sur un message d’entrée, chaque bit de son digest doit avoir une chance sur deux d’être modifié

si le receive buffer est vide, read bloque jusqu’à ce qu’on ait des données

si le receive buffer n’est pas vide, read retourne en copiant les données du receive buffer dans le userland buffer (éventuellement, partiellement si on n’en avait pas assez reçu)

si le receive buffer est plein, tout envoi de paquet sur la socket sera refusé par la pile TCP/IP (ACK ne sera pas envoyé). C’est ue partie de la TCP congestion control , déjà évoqué dans l’article What every developer should know about TCP

on a une queue = le receive buffer

on a un producteur = les paquets reçus par la stack TCP/IP (resp. envoyés, ou les demandes de connexions)

on a un consommateur = les appels à read (resp. write / accept) pour vider la queue

compétition pour des ressources partagées localement : temps CPU, cache, memory bandwidth, network bandwidth, …​

daemons : peu consommateur en moyenne, mais lorsqu’ils se déclenchent, peuvent consommer des ressources en burst

compétition pour des ressources partagées globalement : network switches, shared filesystems

maintenance automatiques : e.g. passage du garbage collector d’un runtime (e.g. java)

queuing : passage obligé dans une queue potentiellement déjà chargée

hardware power limit : throttling automatique si le CPU chauffe trop

hardware garbage collection : pour les SSD, il y a un GC hardware qui multiplie la latence par 100

hardware energy management : latence nécessaire pour sortir d’un mode "économie d’énergie"

leur approche est de regarder le 99ième percentile de temps de réponse (d’où le "tail")

si les services répondent en 10 ms mais que le 99ième percentile répond en une seconde, une requête sur cent sera longue

sur un service qui requête 100 sous-serveurs en parallèle, 63% des requêtes prendra plus d’une seconde (1 - 0.99^100)

même si seule 1/10000 requête est lente, si on a besoin de 2000 sous-requêtes, alors 1 requêtes sur 5 (0.18 = 1 - 0.9999^2000) prendra plus d’une seconde

prioriser les éléments d’une queue qui sont destinés à servir une requête qu’un utilisateur final attend (par opposition aux requêtes où c’est pas très grave si ça prend ponctuellement du temps, par exemple pour des tâches automatiques)

autoriser la préemption des requêtes, pour éviter qu’une seule requête très lente bloque toutes celles derrière elle (en effet, celles-ci pourront préempter la requête lente au bout d’un moment)

limiter l’impact des activités en tâche de fond (e.g. en ne les lançant que lorsque l’activité est faible)

note : le caching est hors de propos ici, puisqu’il n’adresse pas le problème de la queue de la distribution (car les requêtes responsables de la queue de la latency-distribution ne sont pas cachées)

hedged requests :

tied requests :

micro-partition : si on a 10 serveurs, au lieu de partionner le problème en 10 morceaux, on le partitionne en 100, et chaque serveur en traite 10. Si l’une des micro-partitions (on peut plus facilement redispatcher les micros-partitions si nécessaires)

selective replication : répliquer dynamiquement les morceaux qui sont cause de surcharge, pour les faire traiter par plus de serveurs. Deux exemples :

latency-induced probation : on sort temporairement du flux un serveur qui semble occupé, par exemple par un autre job sur le serveur (paradoxalement, c’est donc en réduisant les ressources qu’on améliore la latence moyenne)

good enough : de temps en temps, on n’attend pas que 100% des leaf-servers aient répondu, on se permet de répondre si une fraction suffisamment grande a déjà répondu, en supposant qu’il y a peu de chances que les réponses manquantes améliorent la réponse globale

canary requests : un risque est qu’une requête particulière fasse emprunter un chemin de code buggé, qui fait planter TOUS les leaf servers d’un coup. Pour éviter ça, on envoie d’abord la requête à 1 ou 2 leaf-servers, et seulement s’ils répondent correctement, on envoie la requête à tout le monde.

souvent les attentes sont moindres

les mutations peuvent être effectuées après avoir répondu à l’utilisateur, donc sans se presser

les services nécessitant des mutations peuvent être structurés pour être plus latency-tolerant

lorsqu’on cherche à muter, souvent on utilise un algo (genre Lamport-Paxos) pour recueillir un consensus, et on n’a pas besoin de la queue de la distribution

< 100 ms = le système semble répondre instantanément, l’utilisateur a l’impression d’agir directement sur les données

< 1 seconde = l’utilisateur perd l’impression d’agir directement sur les données, mais le système n’interrompt pas le "flow of thoughts" de l’utilisateur

< 10 secondes = le système interrompt le "flow of thoughts", mais est suffisamment réactif pour qu’on n’ait pas envie d’aller faire autre chose pendant qu’il mouline

> 10 secondes = l’utilisateur va aller faire autre chose pendant que le système mouline → il faut lui donner un indicateur de "quand la tâche sera finie" (e.g. un indcateur de pourcentage restant, ou spinner)

avant de s’arrêter, l’interpréteur python fait un dernier gc.collect (qui n’est pas bypassé par gc.set_threshold(0))

du coup TOUTES les COW des processus fils se déclenchent en même temps, augmentant fortement la consommation de RAM d’un seul coup → il n’y a plus de RAM libre, et le page-cache se vide

du coup quand le process redémarre, au moment de recharger en RAM toutes les pages disques du processus, elles NE SONT PLUS dans le page cache, il faut les relire depuis le disque dur, ce qui est très lent

en effet, à nombre de process identique, il y a moins de pages mémoire différentes existantes (vu qu’on a augmenté le partage des pages mémoires entre les process, en déclenchant moins souvent le COW)

et comme on a moins de pages mémoires différentes à code identique, on aura moins de cache-miss

or chaque cache-miss force le CPU à attendre, du coup diminuer les cache-miss implique qu’on augmente l’IPC \o/

les handshakes TCP et TLS nécessitent plusieur RT → le moment où on pourra envoyer le premier paquet dépend de la latency

cold start = le sender maintient une congestion window , le temps qu’elle prend pour augmenter (et donc pour que la bandwidth augmente) dépend du RTT, donc de la latency

congestion control = le sender adapte ses envois de paquets en fonction du receive buffer du receiver → le temps pris pour revenir à la normale après un timeout dépend du RTT, donc de la latency

y compris après un move, qui laisse l’objet dans un état "emptier than empty"

y compris avant un init, si des constructeurs défèrent la construction finale avec un init

error handling is about bad DATA (e.g. bad inputs), not bad STATE → it’s not about bugs

exemple de situation qui n’est PAS de l’error handling = ram défecteuse, programme incorrect, …​

exemple de situation qui est de l’error handling = plus d’espace disque, on a demandé à l’utilisateur un entier, et il a entré toto

monothread : 5s

2 threads sur deux cores : 10s

2 threads sur un seul core : 8s

2 threads sur deux cores avec un process fils qui mouline en plus : 7s

GIL relâché lors des io AINSI QUE lors du "check" (si un compteur de 100 ticks=instruction de la VM arrive a zéro), pour eviter qu’un thread cpubound ne monopolise le GIL

Lors du check, c’est l’os qui choisit quel thread va tourner : ça peut très bien rester celui qui tournait juste avant le check

Ce qu’on veut éviter c’est que l’os réveille un thread à tort : le thread essaye d’acquerir le GIL sans succès puis se rendort.

Quand on a autant de cores que de thread, c’est EXACTEMENT ce qui se passe, du coup, BEAUCOUP de travail supplémentaire de l’os pour rien, qui empêche le thread "en cours" d’avancer, d’où les mauvaises perfs du cas 2 ci-dessus.

on n’a plus de ticks pour empêcher les threads CPU-bounds de monopoliser le GIL

à la place, on a une variable globale, un thread CPU-bound tourne jusque a ce que cette variable soit mise à 1

pas hyper clair, mais il semblerait qu’à chaque instruction, le thread checke si la var est à 1, et si oui, relâche le GIL ?!

un thread tourne donc indéfiniment, tant que le GIL ne lui est pas réclamé (ou, bien sûr, tant qu’il ne fait pas d’io)

si un deuxième thread arrive, il commence par attendre un peu (par défaut 5 ms) voir si le premier thread relâche le GIL de lui même, puis met la variable globale à 1, ce qui force le premier thread à relâcher le GIL.

et pour éviter que l’os ne le refasse tourner immédiatement, le thread qui vient de relâcher le GIL sleep un peu.

tous les threads (notamment les threads importants ou qui doivent faire de l’io) doivent purger les 5 ms avant d’agir…​ manque de responsiveness

si beaucoup de threads, rien ne dit que c’est le thread qui a réveillé le GIL qui va être exécuté par l’os, il peut starve

pouvoir prioriser les threads (e.g. certains threads vont rendre le GIL très vite)

possibilité de preempter : les threads importants (e.g. qui répondent à une requête réseau) devraient pouvoir préempter

si un thread a rendu la main sans être préempté, il gagne en priorité

à l’inverse, si un thread a dû être préempté, il perd en priorité

Use the same deployable image for test, staging and production environments

Update systems without downtime

Fully automate the deployment process

Set up and rely on automatic monitoring for early problem detection (splitté en health monitoring et error monitoring)

Support rollback to earlier application versions

webhooks = endpoints chez les clients qu’on appelle quand on veut les avertir de quelque chose (e.g. gitlab peut appeler un webhook lorsqu’il se passe un évènement intéressant, comme un push)

database sharding + comment migrer

database replication (asynchrone vs. synchrone)

elasticssearch pour le full text search

pubsub

forcer les type-annotations pour les nouveaux fichiers de code

produire toutes les semaines un rapport sur la couverture de code

sensibilisation des équipes

prendre le retour des utilisateurs

améliorer les perfs pour faciliter l’adoption

ajouter des outils pour les IDE populaires

outils d’analyse statique

stub-files pour des librairies tierces

Interdit d’avoir de l’aliasing (i.e. deux pointeurs différents qui pointent vers la même zone mémoire) à moins qu’un seul des pointeurs aie les droits d’écriture

Borrow checker = seule une référence à la fois a le droit de muter (donc éventuellement détruire ou invalider) un objet

Dit autrement, une référence peut autoriser l’aliasing ou la mutabilité mais pas les deux en même temps

problèmes de classe P = étant donné un problème, on dispose d’un algo pour le résoudre "facilement", i.e. en trouver la solution.

problèmes de classe NP = étant donnée une solution supposée, on sait dire "facilement" si c’est bien une solution ou pas.

problème non-NP = étant donnée une solution supposée, on ne sait même pas dire "facilement" si c’est bien une solution ou pas.

on sait résoudre "facilement" signifie on peut trouver une solution en un nombre de steps polynomial par rapport à la "taille" du problème

(NP) résoudre un petit sudoku est facile vs. (P) multiplier deux petits nombres est facile

(NP) résoudre un très grand sudoku est impossible vs. (P) multiplier deux très grands nombre est certes moins trivial, mais reste facile

dit autrement : comment la difficulté du problème évolue lorsque la "taille" du problème augmente ?

lorsqu’on nous donne une proposition de solution, on ne sait même pas dire si elle est bonne (non-NP, du coup)

peut être facile en temps mais pas en espace, et vice versa

peut être exponentiel, probabiliste, dépendre d’un ordinateur quantique, etc.

type system avec une abstraction pour l’ownership

lib de support (GSL)

analyse statique pour enforce les rules

resource leak (= si un objet n’est pas détruit)

accesss through an invalid pointer

memory corruption (= on peut écrire des données d’un type T1 sur une zone mémoire qui est d’un type T2 → on corrompt T2)

confusion statique (pas besoin de delete) / dynamique (besoin de delete)

use after free / out of range access / null pointer

what = bit encodant l’ownership dans les LSB de l’adresse pointée par le pointeur

deux pointeurs "identiques" peuvent être owner ou non-owner :

(du peu que j’en connais, ça ressemble au borrowing de rust ?)

non-retenu car :

what = au lieu d’utiliser T*, on utiliser owner<T*> pour marquer l’ownership

pour rester ABI-compatible, owner<T*> est un alias vers T* (c’est ça qui est fourni par GSL)

ce marquage par owner NE FAIT RIEN, il permet surtout l’analyse statique

recommandation = quand c’est possible, utiliser plutôt les classes d’ownership (i.e. les resource-handlers) faîtes pour ça (e.g. vector, unique_ptr)

c’est pas rose non plus, il y a des limitations

créer le code source dans un fichier quelque part

le compiler/linker

l’exécuter

trouver où il a produit sa sortie

disposer du repo et savoir commiter/pusher

avoir choisi son IDE/ses outils

savoir builder le process

With multiple repos, you need to have some way of specifying and versioning dependencies between them.

With a monorepo, it’s easy to have one universal version number for all projects.

Using a monorepo where HEAD always points to a consistent and valid version removes the problem of tracking multiple repo versions entirely.

svn (=un commit modifie un fichier) → git (=un commit modifie plusieurs fichiers)

monorepo (= un commit modifie un repo) → multirepo (= un commit modifie plusieurs repos)

une API de test rigolote pour requêter des bières (usage : curl https://api.punkapi.com/v2/beers/)

time.perf_counter() est plus adapté aux mesures de perfs que time.time()

package memory-profiler = pour profiler l’utilisation de la mémoire par une fonction, ligne par ligne

en pratique, ce sont des goto (i.e. jump vers un endroit arbitraire du code)

et même encore pire que goto : pas immédiatement visible dans le code-source + il y en a beaucoup au sein d’une même fonction

ne jamais lancer d’exceptions

si on doit utiliser du code qui peut throw, catcher dès la ligne d’appel même si c’est verbeux

api.fakecompany.com = les appels à l’API

oauth2.fakecompany.com = récupération d’un token pour utiliser l’API

dev.fakecompany.com = portail develop de l’API

associe une plage d’adresses physiques à sa destination : RAM / video card / autre memory-mapped IO device

pour la consulter : sudo cat /proc/iomem

il y a des "trous" dans les plages attribuées à la RAM, pour autre chose : BIOS / video card / carte de périphériques / carte PCI

validate = on vérifie la condition à un moment donné, mais on n’en fait rien (plus loin dans le code, elle pourrait redevenir fausse)

parse = on vérifie la condition, et on stocke l’info dans un type contraint (le compilo s’assure donc qu’elle ne pourra jamais redevenir fausse)

situation n°1 = on représente une couleur avec un int :

int parse(const InputFile& f)
{
    int value = f.get_value();
    if (value != 0 || value != 1) { throw std::runtime_error("boum"); }
    return value;
}
int color = parse(input_file);
// ... some stuff, maybe very long ...

// should I check again that color is in [0,1] ?
// if no, what happens if color is not in [0,1] anymore ?
void do_something(Color) { /* something that relies on color being 0 or 1 */ }
do_something(color);

situation n°2 = on représente une couleur avec un enum class Color :

Color parse(const InputFile& f)
{
    int value = f.get_value();
    if (value == 0) { return Color::RED; }
    else if (value == 1) { return Color::BLACK; }
    else { throw std::runtime_error("boum"); }
}
Color color = parse(input_file);
// ... some stuff, maybe very long ...

// no need to check again that color is in [0,1] : it's in the type !
void do_something(Color) { /* something that relies on color being 0 or 1 */ }
do_something(color);

My advice: focus on the datatypes.

Use a data structure that makes illegal states unrepresentable

Push the burden of proof upward as far as possible (= parser au plus tôt les inputs en des types qui n’ont pas la possibilité de représenter des valeurs illégales)

Apigee EDGE API management product

un portail pour développeurs : découvrir, explorer, acheter, tester, s’enregistrer pour utiliser des API

une passerelle d’API : sécuriser et gérer le traffic entre les clients et les backends, et plus généralement entre une API et ses utilisateurs

un gestionnaire de cycle de vie : gérer la conception, le développement, la publication, le déploiement, et le versioning des API

éventuellement, un outil d’analyse d’utilisation des API, orienté business

éventuellement, un outil de monetization pour packager, pricer et publier les APIs, et pour faire payer les clients

+++ : language-agnostic : on décrit les données dans un fichier .proto, puis un outil (protoc) génère le code de (dé)sérialization pour le langage voulu.

+++ : très performant (aussi bien sur la taille de la donnée encodée, que sur la vitesse de (dé)sérialization)

--- : message en binaire plus dur à débugger que du json

--- : on a une couche de complexité (le fichier proto) en plus

limitation du volume de données qu’on peut transmettre dans une URL

mettre des données dans l’URL est moins flexible que dans le body (notamment : json ?)

Utiliser REPORT (safe + idempotent + body autorisé), verbe défini dans une extension WEBDAV à HTTP.

Utiliser GET avec un body : BAD car l’intérêt du GET (caching) est perdu + HTTP dit explicitement que le body n’a pas de sens.

(side-note : le gros intérêt de GET, c’est l’adressabilité → permettre de faire un simple lien vers une ressource est le top !)

Décorréler la requête (faite avec POST, donc avec body) et la récupération de la réponse (faite sur une autre URL, récupérée avec GET)

On va les livrer plus souvent, on va avoir plus de bugs.

De plus, on va naturellement mettre la librairie à jour moins souvent.

Et ça induit des problèmes de dépendances.

accepter d’avoir de la redondance pour rester indépendant

sortir la librairie dans un SERVICE partagé (plutôt qu’une lib partagée)

refactorer les microservices (ou leur architecture) pour ne plus avoir besoin de partager la librairie