Naissance d’un Kougelhopf

Le Kougelhopf est l’un des symboles de l’Alsace. Certains le nomme Kouglopf ou encore Kouglof mais ce n’est pas ce qui importe. Ce qu’il faut savoir c’est comment lui donner vie.

Après plusieurs essais, je vous livre la recette qui a le mieux marché pour moi.

Ingrédients pour un grand kougelhopf

  • 125g de beurre
  • 125g de lait
  • 40g de levure fraiche
  • 3 œufs
  • 125g de raisins secs
  • 2 cuillères de rhum ou de kirsch
  • 500g de farine
  • 2g de sel
  • 60g de sucre
  • une poignée d’amandes

Étapes

  • Dans une casserole
  • Faire tiédir le lait et le beurre jusqu’à ce qu’il soit liquide
  • Une fois en dessous de 37° y délayer la levure (elle doit rester vivante)
  • Ajouter les œufs (ils ne doivent pas cuire)
  • Ajouter le sucre
  • Ajouter le sel
  • Dans un bol
  • Peser les raisins secs
  • Arroser de rhum ou de kirsch
  • Dans un grand saladier
  • Peser la farine

Incorporer en 3 ou 4 fois le liquide de la casserole dans le saladier tout en commençant à amalgamer le tout de votre main libre.

Une fois tout le liquide et le solide dans le saladier pétrissez le tout à l’aide de vos deux mains. Jusqu’à obtenir une pâte homogène et souple arrêtez vous quand la pâte se détache de vos mains et du saladier.

Ensuite n’oublier pas d’ajouter les raisins en enlevant tout le jus qu’ils n’auraient pas adsorbé. Ce sans quoi vous auriez une pâte bien trop collante. Pétrissez encore un peu la pâte pour y mélanger uniformément les raisins.

Beurrer votre moule à Kougelhopf jusqu’au bord supérieur. Placer au fond les amandes une à une dans le sens des stries (c’est meilleur). Déposer ensuite la pâte dans le moule. Placer ensuite un linge propre et attendez qu’elle pousse à 1 ou 2 centimètres au dessus du bord.

Mettre au four à 180° pendant 30 à 40 minutes.

Photos

Bon appétit, n’hésitez pas à partager ou commenter cette recette

Sauvegarde vers Backblaze B2 avec duplicity

Étant donné les difficultés rencontrées lors de la dernière restauration de mon serveur à partir des données sauvegardées dans hubic, mais également lors de la tentative de restauration précédente, je suis parti à la recherche d’un second lieu de sauvegarde. Après quelques recherches, je me suis décidé à essayer le service fournit par la société Backblaze, en particulier avec sa solution B2 Cloud Storage.

Parmi les points qui m’ont orienté ma décision, on notera :

  • la compatibilité avec duplicity, outil que j’utilise actuellement pour réaliser mes sauvegardes.
  • 10 GB de stockage gratuit
  • Pas de nécessité de saisir des informations de paiement pour pouvoir tester.
  • Un coût de stockage de 0,005$ par GB et par mois.

Du côté tarification, nous sommes proches de ce qu’on retrouve du côté d’Amazon Glacier qui propose une tarification à 0,004$ par Go/mois pour le choix des régions de stockage les moins chers. Si les offres Amazon peuvent également être intéressantes, mais l’utilisation avec duplicity n’est pas disponible en l’état. De plus, il semble que la difficulté se situe au minimum du côté de l’option verify qu’il faudrait désactiver car comptant comme une demande de restauration. Une autre difficulté se situe du côté de la restauration des fichiers à proprement parlé, étant donné le temps nécessaire à Glacier pour rendre les fichiers disponibles après leur sauvegarde. Bref, à tester, mais dans un autre contexte.

Passons à la configuration de duplicity pour B2. Une version de duplicity v0.7.12 ou plus récente est nécessaire. La vérification s’effectue avec :

duplicity --version

La version installée sur mes serveurs depuis les dépôts de Debian était trop ancienne, j’ai donc compilé le programme à partir des sources du projet disponible sur le site du projet. Après récupération du dossier compressé des sources, petit tour dans le README pour prendre connaissance des pré-requis et des instructions de compilation. On procède donc à l’installation des dépendances demandées :

sudo aptitude install python-dev librsync-dev intltool python-fastener

Passage ensuite à l’étape de compilation, après décompression des sources :

python setup.py build

Puis désinstallation de la version en provenance du gestionnaire de paquet et installation de la version compilée à l’instant.

sudo aptitude remove duplicity
sudo python setup.py install

Enfin, vérification de la version de duplicity installée et vérification de l’emplacement de l’exécutable.

duplicity --version
which duplicity

Après mon premier test de sauvegarde, j’ai noté que les composants suivants sont également nécessaires au bon fonctionnement de duplicity avec B2 :

pip install b2
pip install backports.functools_lru_cache

À ce stade, on peut passer à un premier test de sauvegarde vers la solution de stockage de Backblaze. La commande duplicity reste des plus classiques et prends la forme suivante :

duplicity ~ b2://[applicationKeyId]:[application key]@[B2 bucket name]

Attention, la clé d’application doit être sauvegardée dans un endroit sûr, au hasard, dans son gestionnaire de mot de passe préféré. En effet, une fois la fenêtre contenant la clé fermée, il n’est plus possible d’afficher la clé et une nouvelle clé devra être générée en cas de perte de la première.

Autre point, la documentation Backblaze est en partie erronée dans la structure de la commande duplicity proposée, puisque y est fait mention d’un paramètre account_id en lieu et place du paramètre applicationKeyId ci-dessus. C’est bien ce dernier paramètre qu’il faut choisir, car utiliser l’account_id ne conduira qu’à des erreurs d’autorisation et à de la frustration

Quelques lignes encore pour terminer cet article. Je dispose désormais d’une double sauvegarde de mes serveurs vers hubic et maintenant B2. Le volume de données sauvegardées n’excède pas, pour l’instant, la tranche gratuite du service. Par la suite, j’envisage de tester d’autres outils de sauvegarde en particulier Restic et Borg. En outre le coût relativement faible du stockage m’encourage à envisager la sauvegarde externe de données froides comme mes photos numériques et ma bibliothèque de musique. La réflexion suit son cours.

Citation [9] – Patricia Briggs

Il était plus petit que la moyenne, et paraissait dix ans de moins que son âge réel. Il s’habillait modestement et observait plus qu’il parlait. Phöran l’avait tout d’abord considéré comme un homme impassible, aussi vrai que l’acier, certes, mais qui devait beaucoup réfléchir avant d’agir. C’était le cas, sauf qu’il réfléchissait très vite.

Corbeau – Patricia Briggs

Il avait toujours su qu’elle l’aimait, lui, autant qu’elle aimait leurs enfants. Mais il savait aussi également que depuis l’enfance, on l’avait entraînée à maîtriser ses émotions; et que l’intensité des sentiments qu’elle éprouvait la perturbait beaucoup. C’est justement parce qu’il la connaissait si bien, et qu’il la comprenait, qu’il ne l’avait jamais poussée à lui avouer ce qu’il savait déjà.

Corbeau – Patricia Briggs

Le problème, c’est qu’elle ne savait pas quoi dire. Il lui arrivait rarement d’être maladroite, pourtant. Mais c’était devenu une habitude ces derniers temps, lorsqu’il était à côté d’elle. Elle n’était pas bavarde comme Tiër et se plaisait dans ses silences. Ou, du moins, était-ce ce qu’elle avait cru. A présent, elle avait envie de parler à Jës, mais ne savait pas quoi dire, ni comment le dire. Elle préféra donc se taire.

Corbeau – Patricia Briggs

Formatage de code avec husky et prettier

Petit point rapide pour la mise en place d’un formatage automatique des portions de code modifiées au moment du commit (en environnement JS : Angular/Node).

Installation des dépendances :

npm install --save-dev husky prettier precise-commits

Configuration à ajouter dans package.json :

"husky": {
"hooks": {
"pre-commit": "precise-commits"
}
},

À noter que prettier n’arrive pas toujours à formater un extrait de fichier JSON, l’intérêt de precise-commits peut s’en voir grandement diminuer si le projet contient de nombreux fichiers JSON régulièrement modifiés.

Modification des informations d’auteur d’un commit

Après avoir récupéré l’ensemble de mes dépôts git avec repo, je souhaitais effectuer un peu de « nettoyage » dans mes informations d’auteur de commit afin de les harmoniser. Bien entendu, cette opération n’est pas du tout neutre puisqu’elle implique une réécriture de l’historique, et dans le cas d’un changement d’email, cela concerne chaque SHA-1 des commits de l’historique (car un commit contient le SHA-1 de son parent).

Intéressons-nous à la commande de changement des informations d’auteur à proprement parler. Celle-ci est extraite de la documentation de github (si besoin, en cas d’opération successive, ajouter l’option -f avant –env-filter):

$ git filter-branch --env-filter '

OLD_EMAIL="your-old-email@example.com"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="your-correct-email@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_AUTHOR_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

Avant d’être en mesure de réécrire les commits, on commence par déterminer les informations existantes à l’aide de la commande suivante (que l’on pourra par ailleurs exécuter sur tous les dépôts avec repo forall -c <commande>) :

git log | grep Author: | sort | uniq

Une fois les changements terminés, on pousse ces derniers vers le serveur:

git push --force --tags origin 'refs/heads/*'

En cas de message du type :

erreur fatale: 'origin' does not appear to be a git repository

Il convient de vérifier le remote configuré avec git remote -v, soit dans mon cas :

github  ssh://git@github.com/vvision/eslint-config (fetch)
github ssh://git@github.com/vvision/eslint-config (push)

On remplace alors origin par github dans la commande git push et le tour est joué (configuration héritée de repo).

De cette manière, l’ensemble de mes dépôts dispose désormais des informations de contact nettoyées.