Pour bien cicatriser il faut

• Éviter coûte que coûte le soleil sur la plaie !
• De la vitamine A (et des vitamines d'une manière générale).
• Du silicium.
• Des protéines.
• Bien dormir.

Pour le soleil

• Ne pas s'exposer / Rester à l'ombre.
• Casquette ou voile obligatoire si c'est sur le visage (oui c'est moi qui écrit ça 😝).
• Crème cicatrisante non étalée sur la plaie (et qui soit compatible avec les UV).

Pour les vitamines (dont la A)

• Fruits et legumes notamment carotte, citrouille, épinards, brocolis, poivrons rouges, melon, abricot...

Pour le silicium

• Des céréales comme le riz complet ou l’avoine complet.
• Des fruits et légumes/légumineux comme le concombre, poireau, betterave et oignon.

Pour bien dormir

• Pas d'écrans passé 20h.
• Pas de news alarmantes.
• Prendre quelques congés, 15 jours ce n'est rien face à une cicatrice qui tiendrait 20 ou 30 ans.

Article très intéressant que m'a proposé @Chlouchoutte sur comment les individus d'une entreprise se passent la patate chaude, à savoir le TAF ici appelé The Monkey.

Je ne peux que vous recommander sa lecture surtout si vous gérez une ou plusieurs équipes, ce qui est mon cas.

Article très intéressant sur le vocabulaire que je vais essayé de résumer.

La Programmation Dynamique (DP)

La programmation dynamique consiste à réorganiser un arbre d'appels récursifs en graphe orienté convergent, où des embranchements impliquant la même exécution vont voir leurs résultats mémorisés afin de ne pas être recalculés.

Typiquement pour le calcul d'une suite de Fibonacci nous avons cet arbre avant :

Transformé en ce graphe après (ou le résultat de **fib(1) a été mémorisé) :

La memoization

La mémoïsation en français est une technique qui consiste à mettre en cache les valeurs déjà calculée.

L'exemple de l'article est le suivant :

fun square(x) {
    return x * x
}

fun square_memoized(x) {
    if (mem[x] is not set) {
        mem[x] = x * x
    }
    return mem[x]
}

La tabulation

Cette technique ressemble un peu à la memoization mais consiste à remplir le cache systématiquement jusqu'au moment où l'on trouve la bonne valeur, alors que la memoization va se concentrer sur la valeur à retourner directement.

L'exemple donné est le suivant :

fun fib_tab(n) {
    mem[0] = 0
    mem[1] = 1
    for i = 2...n
        mem[i] = mem[i-2] + mem[i-1]
    return mem[n]
}

Donc l'exécution réelle donne ceci :

mem[0] = 0
mem[1] = 1
mem[2] = mem[0] + mem[1]
mem[3] = mem[1] + mem[2]
mem[4] = mem[2] + mem[3]

On voit bien que le cache est surutilisé dans le cadre de la tabulation puisque chaque valeur suivante s'appuie sur la précédente forcément cachée. De facto, la tabulation consomme plus de mémoire mais garantie un accès instantané à la valeur dès la seconde utilisation, à l'image des caches gloutons finalement ("goutons" au sens algorithmes gloutons du terme).

Je m'intéresse en ce moment à l'éciture, notamment sur la capacité non pas de représenter une émotion à l'écrit, mais de parvenir à faire ressentir l'émotion désirée au lecteur.

Je cite :

Sollicitez tous vos sens

Pour obtenir cet effet, vous devez considérer le sens de la vue comme un acquis et mettre l’accent sur les autres sens afin d’élaborer des descriptions multidimensionnelles. Prendre en compte uniquement le sens de la vue crée presque toujours un effet plat. Lors de votre phase de réécriture, prenez donc quelques minutes pour vous assurer que chaque scène présente au moins un détail provenant d’un autre sens que la vue. De cette façon, le lecteur se trouvera plongé dans l’histoire et la ressentira réellement.

Je cite cette section car elle résume à elle seule l'intégralité du propos :

Tutorials

A tutorial:

• is learning-oriented
• allows the newcomer to get started
• is a lesson

Analogy: teaching a small child how to cook

How-to guides

A how-to guide:

• is goal-oriented
• shows how to solve a specific problem
• is a series of steps

Analogy: a recipe in a cookery book

Explanation

An explanation:

• is understanding-oriented
• explains
• provides background and context

Analogy: an article on culinary social history

Reference

A reference guide:

• is information-oriented
• describes the machinery
• is accurate and complete

Analogy: a reference encyclopaedia article

Via Tiger 222.

Je vais faire ma mijaurée mais pas grave.

Quand je lis :

L’architecture applicative apporte une réponse à la question suivante :

Comment les éléments fonctionnels sont ils implémentés ? Le COMMENT ?

Cette architecture représente l’implémentation des services fonctionnels sous forme d’éléments applicatifs.

Elle est composée d’éléments applicatifs (ex : composants Java, .net, objets BDD,…). L’architecture applicative représente le premier niveau d’une projection entre une architecture fonctionnelle (et ses services métiers) et des technologies qui vont devoir supporter ces services. Elle est une instanciation de l’architecture fonctionnelle.

et ceci :

L’architecture technique apporte une réponse la question suivante :

Avec quels éléments techniques, les éléments applicatifs sont ils déployés ? Le AVEC QUOI ?

Cette architecture décrit l’infrastructure sur laquelle les éléments applicatifs ont été déployés.

Elle est décomposée en deux couches :

• Une couche de logiciels médiateurs (ou middleware) qui est composée des progiciels : moteurs des bases de données, serveur d’application, serveur web, annuaire LDAP, ordonnanceur, gestionnaires de flux (EAI, ESB, ETL, …), etc.

• Une couche matérielle qui est composée des logiciels de base (systèmes d’exploitation), des serveurs et des réseaux.

Mon petit cerveau de lémurienne fait tilt ! Sur quel critères rationnels, objectifs et argumentés LDAP serait plus du côté de l"architecture technique que du côté de l'architecture applicative ? Même question mais dans l'autre sens pour Java ? Quid des "objets BDD", de l'ordonnanceur, du gestionnaire de flux, ie. un BPM ? Un F5 ? Un load-balancer ?

Bref, la réalité est simple : l'architecture applicative et l'architecture technique constituent le même objet, elle sont la même chose ! Et le choix d'architecture doit être uniquement pris par les équipes produits constituées de développeurs.

Car oui, l'architecture, c'est du code point. Un design orienté micro-service, c'est du code. Le choix de frameworks, c'est du code qui impact du code. Les flux de données, c'est du code sous contrainte.

Les architectes sont dans un délire pluri-décennal consistant à croire que c'est leur compréhension qui part en production, or c'est archi-faux ! Leur position est d'être celle du dirigeant, du leader alors qu'elle devrait se contenir à celle d'un documentaliste ou d'un bibliothécaire #CommentCaCoupBas.

Moins d'architecte & Plus de développeurs => meilleurs logiciels de meilleurs qualité.

Quant à tout ceux qui pensent le contraire, les logiciels les moins fiables sur terre ont des équipes bardées d'architectes (coucou Microchiotte) tandis que ceux qui sont les plus fiables n'ont quasiment que des développeurs (coucou Linux, les logiciels libres & stuff).

Aussi, c'est certes un sophisme que de conclure + d'architectes => + de problèmes car corrélation n'implique pas une causalité, mais ce sera quand même ma conclusion car je n'ai aucun contre-exemple depuis 15 années passées sur le terrain !

Pour @Strawberry :D

Comment sont rendues les frames du jeu vidéo Rise of the Tomb Raider (2015).

L'article reprend une par une toutes les techniques de filtres, lumières, ombres, brouillards et shap-erendering pour expliquer leur intérêt et leurs optimisation.

Très beau travail de vulgarisation ! Via le Styx.

Ou comment obtenir en un clique toutes les informations de positionnement de votre écran (PC, Mobile ou Tablette). Très pratique !

Chlouchloutte, cette vidéo est à regarder.