13 liens privés
Au programme :
- un tuto rust,
- des tips sur linux et son kernel
- des tips git
A voir.
Les design-pattern sont une /des méthode(s) pour résoudre des problèmes que d'autres personnes ont employé avant nous. Ils sont un modèle à suivre (ou pas ...) lorsque nous sommes confrontés aux même problèmes.
On y retrouve quelques définitions de la méthode agile et de ses composants :
-
scrum
Le terme ‘scrum’ vient du monde du rugby et signifie ‘mêlée’. En effet le scrum s’appuie fortement sur les notions de collectif, d’esprit d’équipe et de solidarité. Scrum est la méthode agile la plus populaire, notamment au sein des DSI.
Son cadre comprend :- des itérations courtes et répétitives (appelées sprint) et leurs cérémonies — les itérations durent 2 à 4 semaines, souvent 2 semaines, et sont rythmées et égales,
- une équipe composée de 3 rôles clés,
- un backlog contenant toutes les demandes fonctionnelles à traiter.
La méthode Scrum repose sur ces 3 piliers : - La transparence
Toute l’équipe et les parties prenantes peuvent visualiser la répartition des tâches et l’avancement du projet grâce au management visuel et aux différentes cérémonies qui jalonnent le projet. Et au delà du travail réalisé, l’on partage aussi les succès et les difficultés rencontrées. - L’inspection
Il ne s’agit pas de contrôler mais de s’harmoniser pour avancer dans la même direction et s’améliorer en équipe.
L’adaptation
-
scrum master
Ce rôle est souvent incompris et associé à tort à un rôle de chef de projet.
Il s’agit à la fois d’un rôle de facilitateur, qui aide l’équipe à lever les obstacles de tout type (logistique et matériel, organisation, …), mais aussi d’animateur lors des cérémonies et également de médiateur au besoin. [...] -
product owner
Véritable responsable fonctionnel, il est chargé de créer et de maintenir le backlog (listing de l’ensemble des demandes fonctionnelles du projet).
Il n’y a pas de cahier des charges complet établi dès le départ du projet, mais des lots de demandes qui sont définies et réalisées au fur et à mesure des sprints.
Le product owner est alors responsable de la priorisation fonctionnelle des demandes à prendre en charge lors des sprints, en accord avec les parties prenantes. -
dev-team
En l’absence de chef de projet dans cette organisation, les développeurs sont autonomes et auto-organisés, et assument ensemble la responsabilité et les décisions techniques du projet. En plus du développement, ils réalisent donc aussi la documentation et l’architecture technique et sont responsables de la qualité technique.
Les étapes et cérémonies de la méthode Scrum
- En premier lieu, le client fait part de son besoin et de ses demandes à minima au product owner, voire à l’ensemble de l’équipe. [...]
- À l’issue de ce point, le product owner prépare le backlog avec les différentes demandes fonctionnelles définies.
- Le sprint démarre alors par un sprint planning, lors duquel le product owner présente les demandes fonctionnelles à essayer de réaliser (selon la capacité de travail de l’équipe) à l’ensemble de l’équipe. [...]
- S’ensuit un sprint, généralement de 15 jours, qui comprend chaque jour une daily de 15 minutes. Ce point quotidien a pour but de s’harmoniser et de partager ce qui a été accompli.
- À la fin du sprint, une review est organisée. Lors de ce point de 30 minutes — 1h, le product owner et la dev team présente le travail réalisé et l’avancement des objectifs aux parties prenantes, si possible en s’appuyant sur une démo. C’est l’occasion de récupérer du feedback sur le travail accompli.
- L’équipe se retrouve ensuite lors d’une rétrospective tous ensemble, pour faire une introspection du sprint réalisé et acter des axes d’améliorations à mettre en place. [...]
- Si nécessaire, le product owner peut organiser un product backlog refinement. Ce point d’1 heure maximum, qui peut peut être réalisé chaque semaine, a pour but d’affiner le backlog pour les sprints à venir.
Les indicateurs de la méthode Scrum
L’indicateur principal, que l’on peut mettre en place pour la méthode Scrum, est la vélocité de l’équipe. Il s’agit de comptabiliser le nombre de point d’effort des tickets réalisés et passés en done à la fin de chaque sprint.
L’indicateur est observé uniquement au niveau de l’équipe, et non au niveau individuel. [...]Il s’agit d’un indicateur de suivi plus qu’un objectif à atteindre.
TOML (Tom’s Obvious, Minimal Language) est un format de fichier de configuration conçu afin d'être facile à lire et à écrire en raison d’une sémantique plus évidente qui se veut minimale.
La syntaxe de TOML ressemble quelque peu à celle des fichiers INI, mais est un format avec spécification formelle. Un fichier TOML consiste principalement en des sections ( [section.sous-section]), des paires (cle = valeur, "clé" = "valeur"), et des commentaires (# commentaire).
TOML prend en charge les type de données suivants :
- chaînes de caractères ;
- nombres entiers ;
- nombres à virgule flottante ;
- booléens ;
- dates et heures ;
- tableaux ;
- dictionnaires.
Ex. :
# Ceci est un document TOML.
title = "Exemple de fichier TOML"
[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00 # Les dates et heures forment un type natif
[database]
server = "192.168.1.1"
ports = [ 8001, 8001, 8002 ]
connection_max = 5000
enabled = true
[servers]
# L'indentation (tabulations et/ou espaces) est autorisée mais pas obligatoire
[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[servers.beta]
ip = "10.0.0.2"
dc = "eqdc10"
[clients]
data = [ ["gamma", "delta"], [1, 2] ]
# Les sauts de ligne sont acceptables à l’intérieur des tableaux
hosts = [
"alpha",
"omega"
]YAML : un hybride simplifié de XML et de JSON, en plus lisible.
Voir aussi : [https://www.youtube.com/watch?v=7gmW6vxgsRQ]
- Les commentaires sont signalés par le signe dièse (#) et se prolongent sur toute la ligne. Si par contre le dièse apparait dans une chaine, il signifie alors un nombre littéral.
- Une valeur nulle s'écrit avec le caractère tilde (~)
- Il est possible d'inclure une syntaxe JSON dans une syntaxe YAML.
- Les éléments de listes sont dénotés par le tiret (-), suivi d'une espace, à raison d'un élément par ligne.
- Les tableaux sont de la forme clé: valeur, à raison d'un couple par ligne.
- Les scalaires peuvent être entourés de guillemets doubles ("), ou simples ('), sachant qu'un guillemet s'échappe avec un antislash (), alors qu'une apostrophe s'échappe avec une autre apostrophe4. Ils peuvent de plus être représentés par un bloc indenté avec des modificateurs facultatifs pour conserver (|) ou éliminer (>) les retours à la ligne.
- Plusieurs documents rassemblés dans un seul fichier sont séparés par trois traits d'union (---) ; trois points (...) optionnels marquent la fin d'un document dans un fichier.
- Les nœuds répétés sont initialement signalés par une esperluette (&) puis sont référencés avec un astérisque (*) ; JSON, un langage concurrent de YAML, est compatible avec la syntaxe de JavaScript mais ne supporte pas cette notion de référence.
- L'indentation, par des espaces, manifeste une arborescence.
- Il est aussi possible de préciser le type (anglais tag) d'une donnée. Cependant, cette précision n'opère aucune contrainte, et fonctionne plutôt comme un marquage, ou une modélisation.
Exemple de fichier yaml :
--- <-- entête d'un fichier yaml (les tirets sont facultatifs, mais par convention ils signifient qu'on a affaire à un fichier yaml)
clef: valeur
#Ceci est un commentaire
script: | <-- le pipe définit une clef avec une valeur sur plusieurs lignes
ligne 1
ligne 2
ligne 3
commande: > <-- le chevron définit une clef avec une valeur très longue sur une seule ligne, mais découpée en plusieurs ligne pour plus de lisibilité
très longue ligne 1/n
très longue ligne 2/n
...
très longue ligne n/n
modele: &template <-- modèle de structure pré-valorisée (`template` n'est pas un mot-clef, c'est le symbole & qui fait tout)
nom: lacan
prenom: guillaume
qui: *template <-- `grâce au symbole `*`, qui` reprend la structure et les valeurs de `modele`
qui_bis:
<< : *template <-- le double-chevron signifie qu'on reprend la structure et les valeurs par défaut de `template`, et qu'on va "overwrite" ledit `template`
age: 8 <-- ajoute une clef à la structure héritée
prenom: camille <-- écrase la valeur par défaut
tableau_yaml:
- toto
- tata
tableau_json: [ "toto", "tata" ]
... <-- fin (facultative) d'un fichier yaml
Peyton Quinn a 4 règles très pratiques pour éviter et désescalade les situations violentes. Elles sont simples à comprendre :
- Ne l’ignorez pas
- Ne l’insultez pas
- Ne le provoquez pas, ni n’acceptez ses provocations
- Laissez-lui une porte de sortie honorable
