Compare commits
10 commits
d29f1128f2
...
831e4d978d
Author | SHA1 | Date | |
---|---|---|---|
831e4d978d | |||
6d76ed6575 | |||
e99be7fc23 | |||
29b4399ff8 | |||
558fc24911 | |||
b5179b97ac | |||
44404f4034 | |||
6389fa0d42 | |||
ec94f9df2f | |||
7ca4460a8d |
20 changed files with 945 additions and 131 deletions
29
Makefile
29
Makefile
|
@ -1,29 +0,0 @@
|
|||
# Includes
|
||||
-include include.mk
|
||||
|
||||
# deploy variables
|
||||
DEPLOY_BIN?=rsync
|
||||
DEPLOY_OPTS?=-avz --delete
|
||||
|
||||
BUILD_OPTS?=--gc --cleanDestinationDir
|
||||
BUILD_DEST?=public
|
||||
|
||||
.PHONY: serve
|
||||
serve:
|
||||
@hugo server -D --disableFastRender -v
|
||||
|
||||
.PHONY: build
|
||||
build:
|
||||
@hugo -d $(BUILD_DEST) $(BUILD_OPTIONS)
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
@[ -d $(BUILD_DEST) ] && rm -rf $(BUILD_DEST)
|
||||
|
||||
.PHONY: deploy
|
||||
deploy: build
|
||||
|
||||
ifeq ($(DEPLOY_SERVER),)
|
||||
$(error DEPLOY_SERVER is not defined)
|
||||
endif
|
||||
[ -d $(BUILD_DEST) ] && $(DEPLOY_BIN) $(DEPLOY_OPTS) $(BUILD_DEST)/ $(DEPLOY_SERVER):$(DEPLOY_FOLDER)
|
10
Taskfile.dist.yaml
Normal file
10
Taskfile.dist.yaml
Normal file
|
@ -0,0 +1,10 @@
|
|||
version: "3"
|
||||
set: [errexit, pipefail, nounset]
|
||||
shopt: [globstar]
|
||||
dotenv:
|
||||
- .env
|
||||
includes:
|
||||
site:
|
||||
taskfile: ./taskfiles/site.yaml
|
||||
latex:
|
||||
taskfile: ./taskfiles/latex.yaml
|
22
config.toml
22
config.toml
|
@ -9,10 +9,6 @@ rssLimit = 10
|
|||
paginate = 10
|
||||
enableRobotsTXT = false
|
||||
|
||||
[Author] # Used in authorbox
|
||||
name = "ephase"
|
||||
bio = "Adminstrateur système, j'ai d'abord intégré la Licence Pro ADSILLH et maintenant le Master IDI à l'Université de Bodreaux"
|
||||
avatar = "assets/images/souris.svg"
|
||||
|
||||
[taxonomies]
|
||||
category = "categories"
|
||||
|
@ -23,19 +19,12 @@ enableRobotsTXT = false
|
|||
toc = true
|
||||
post_navigation = true
|
||||
mainSections = [
|
||||
"reseaux_protocoles",
|
||||
"ia",
|
||||
"secu_systeme",
|
||||
"conception_formelle",
|
||||
"secu_logicielle",
|
||||
"bdd_avancees",
|
||||
"systemes_exploitation",
|
||||
"admin_reseau",
|
||||
"secu_reseaux"
|
||||
"conduite_projet",
|
||||
"introduction_verification"
|
||||
]
|
||||
post_meta = ["author", "date", "categories", "translations"]
|
||||
mathjax = true
|
||||
mathjaxPath = "https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.6/MathJax.js" # Specify MathJax path
|
||||
mathjaxPath = "https://cdnjs.cloudflare.com/ajax/libs/mathjax/3.2.2/es5/tex-svg.js" # Specify MathJax path
|
||||
mathjaxConfig = "TeX-AMS-MML_HTMLorMML" # Specify MathJax config
|
||||
[Params.sidebar]
|
||||
home = "right" # Configure layout for home page
|
||||
|
@ -43,3 +32,8 @@ enableRobotsTXT = false
|
|||
single = false # Configure layout for single pages
|
||||
# Enable widgets in given order
|
||||
widgets = ["search", "categories", "taglist"]
|
||||
|
||||
[Params.Author] # Used in authorbox
|
||||
name = "ephase"
|
||||
bio = "Adminstrateur système, j'ai d'abord intégré la Licence Pro ADSILLH et maintenant le Master IDI à l'Université de Bordeaux"
|
||||
avatar = "assets/images/souris.svg"
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Conduite de projet: introduction"
|
||||
date: 2024-09-10
|
||||
tags: [""]
|
||||
date: 2024-09-16
|
||||
tags: ["besoins", "conception"]
|
||||
categories: ["Conduite de projet", "Cours"]
|
||||
mathjax: true
|
||||
---
|
||||
|
@ -10,7 +10,7 @@ Les projets informatiques peuvent prendre plusieurs formes:
|
|||
|
||||
* **Projet de développement logiciel** pour livrer la première version
|
||||
utilisable du logiciel.
|
||||
* **Projet de tierce maintenance applicatice** pour en assurer la maintenance.
|
||||
* **Projet de tierce maintenance applicative** pour en assurer la maintenance.
|
||||
* **Projet de mise en production** pour assurer la production (exploitation).
|
||||
|
||||
Mener à bien ces différents projets est un long chemin, il est facile de se
|
||||
|
@ -47,7 +47,8 @@ aussi **le chiffrer**. Le *MOE* peut refuser de aire telle ou telle
|
|||
spécification du budget et de ses capacités.
|
||||
|
||||
Au niveau du chiffrage, on évalue en **jour/homme**, c'est une tâche qui demande
|
||||
de l'expérience car semée de pièges.
|
||||
de l'expérience car semée de pièges. Par exemple, il est souvent pas possible de
|
||||
factoriser, en effet 2 jours/homme ne signifie pas 2 fois 1 jour/homme.
|
||||
|
||||
## La conception
|
||||
|
||||
|
@ -60,45 +61,6 @@ alors plusieurs points de vies:
|
|||
|
||||
Il faut aussi choisir **une architecture** (3 tiers, en couche, par service).
|
||||
|
||||
## Les besoins
|
||||
|
||||
Nous pouvons utiliser la méthode sur **6 artefacts**:
|
||||
Nous pouvons utiliser la méthode sur **6 artefacts**:
|
||||
|
||||

|
||||
|
||||
L'expression des besoin contient elle aussi des pièges:
|
||||
|
||||
* les besoins fantômes;
|
||||
* les besoins mal exprimés.
|
||||
|
||||
Un besoin se caractérise par deux stades:
|
||||
|
||||
1. en cours de rédaction;
|
||||
2. rédigé et en attente de qualification.
|
||||
|
||||
6 bonnes pratiques:
|
||||
|
||||
* un besoin doit être identifié par un numéro de besoin
|
||||
* un besoin doit être précis
|
||||
* un besoin doit être qualifié (type, difficulté, priorisé)
|
||||
* un besoin doit être planifié (échéance, unité de temps)
|
||||
* un besoin doit être clos (à un moment donné)
|
||||
* les besoins doivent être homogénéisés
|
||||
|
||||
Nos besoins contiennent dont un *identifiant*, une *description*, un *objectif*
|
||||
et un *contrôle*. Il faut absolument **tuer tout espace laissé au flou et à
|
||||
l'interprétation**. Nous avons besoin de précision.
|
||||
|
||||
**Homogénéiser**: chacun des besoins doivent avoir le même point de vue, exprimé
|
||||
de la même façon avec la même granularité.
|
||||
|
||||
Un besoin doit être **priorisé** selon 3 critères: `élevé`, `normal`, `bas`
|
||||
|
||||
### 4 types de besoins
|
||||
|
||||
* Nouvelle fonctionnalité.
|
||||
* Bugfix / amélioration
|
||||
* Amélioration de performances
|
||||
* Refactoring (visibilité du code)
|
||||
|
||||
|
||||
|
|
49
content/conduite_projet/2_besoins/index.md
Normal file
49
content/conduite_projet/2_besoins/index.md
Normal file
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
title: "Conduite de projet: les besoins"
|
||||
date: 2024-09-16
|
||||
tags: ["besoins", "conception"]
|
||||
categories: ["Conduite de projet", "Cours"]
|
||||
mathjax: true
|
||||
---
|
||||
Une fois le cahier des charge et les spécifications effectué, nous pouvons
|
||||
passer aux besoins.
|
||||
|
||||
Mais attention, l'expression des besoin contient des pièges:
|
||||
|
||||
* les besoins fantômes;
|
||||
* les besoins mal exprimés.
|
||||
|
||||
Un besoin se caractérise par deux stades:
|
||||
|
||||
1. en cours de rédaction;
|
||||
2. rédigé et en attente de qualification.
|
||||
|
||||
6 bonnes pratiques:
|
||||
|
||||
* un besoin doit être identifié par un numéro de besoin
|
||||
* un besoin doit être précis
|
||||
* un besoin doit être qualifié (type, difficulté, priorisé)
|
||||
* un besoin doit être planifié (échéance, unité de temps)
|
||||
* un besoin doit être clos (à un moment donné)
|
||||
* les besoins doivent être homogénéisés
|
||||
|
||||
Nos besoins contiennent dont un *identifiant*, une *description*, un *objectif*
|
||||
et un *contrôle*. Il faut absolument **tuer tout espace laissé au flou et à
|
||||
l'interprétation**. Nous avons besoin de précision.
|
||||
|
||||
Ils doivent être auto-contenus.
|
||||
|
||||
**Homogénéité**: chacun des besoins doivent avoir le même point de vue, exprimé
|
||||
de la même façon avec la même granularité. Il ne faut **laisser aucune place au
|
||||
flou et à l'interprétation**.
|
||||
|
||||
Un besoin doit être **priorisé** selon 3 critères: `élevé`, `normal`, `bas`
|
||||
|
||||
### 4 types de besoins
|
||||
|
||||
* Nouvelle fonctionnalité.
|
||||
* Bugfix / amélioration
|
||||
* Amélioration de performances
|
||||
* Refactoring (visibilité du code)
|
||||
|
||||
Une fois les besoins définis, nous passer aux tâches.
|
95
content/conduite_projet/3_taches/index.md
Normal file
95
content/conduite_projet/3_taches/index.md
Normal file
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
title: "Conduite de projet: les tâches"
|
||||
date: 2024-09-23
|
||||
tags: ["tâche", "scum", "agile"]
|
||||
categories: ["Conduite de projet", "Cours"]
|
||||
mathjax: true
|
||||
---
|
||||
|
||||
Maintenant que les besoins sont définis, nous allons les décomposer en tâches
|
||||
pour les passer à l'équipe. Là encore il est question de bonnes pratiques,
|
||||
d'abord concernant leurs rédactions:
|
||||
|
||||
* il faut limiter le travail;
|
||||
* et aussi le préciser;
|
||||
* il faut lier les tâches aux besoins.
|
||||
|
||||
Mais aussi concernant l'organisation:
|
||||
|
||||
* Organiser les tâches;
|
||||
* suivre leurs avancements.
|
||||
|
||||
## Rédaction
|
||||
|
||||
La granularité d'une tâches doit être la plus fine possible et représenter un
|
||||
élément atomique du projet. Une tache doit se tenir dans un périmètre donné, par
|
||||
exemple:
|
||||
|
||||
> Écrire du code et documenter sont deux choses.
|
||||
|
||||
Une tâche doit en général monopoliser un dévelloppeur pendant un/deux jours
|
||||
maximum. Si elle demande plusieurs dévellopeur sur plusieurs jours alors **nous
|
||||
avons un problème de granularité**.
|
||||
|
||||
Elle doit être écrite pas l'équipe qui va la réaliser. Il faut définir
|
||||
précisément ses objectifs en définissant le **DoD* -- *Definition of done* qui
|
||||
représente la ligne d'arrivée. une tâche est **obligatoirement** être
|
||||
**rattachée à un besoin**.
|
||||
|
||||
Le **niveau de précision** d'une tâche doit permettre à n;importe quel
|
||||
dévellopeur de l'équipe de savoir **exactement quoi faire**.
|
||||
|
||||
## Plannification
|
||||
|
||||
Une fois les tâches rédigée, nous pouvons passer à la plannification. Il est
|
||||
toujours question de composer avec le facteur *humain*. Il s'agit ici de
|
||||
disposer les tâche sur *un calendrier* et d'affecter les resources nécessaires.
|
||||
|
||||
Nous pouvons utiliser des diagrammes de *Gantt* pour cette étape
|
||||
|
||||
## Suivi
|
||||
|
||||
Pour le suivi est tâches, nous pouvons utiliser la méthode Kanban. Il sera
|
||||
alors question de "changer" les tâches de colonnes aux fur et à mesure de leurs
|
||||
avancement.
|
||||
|
||||
## Scrum / agilité
|
||||
|
||||
Alors que le le projet avance, les besoins peuvent changer. Si dans un cycle de
|
||||
production classique comme celui en V, les besoin sont figé tout au long du
|
||||
project, *SCRUM* permet d'ajuster les besoins tout au long du cycle.
|
||||
|
||||
C'est alors le propriétaire -- appelé ici *Product Owner* -- qui est repsonsable
|
||||
des changements. L'équipe de dévellopement comporte aussi un *scrum master*, qui
|
||||
anime l'équipe. Le *product owner* détermine les priorité.
|
||||
|
||||
L'équipe itère lors de *sprints* d'une durée définie (en général entre deux et
|
||||
quatre semaines). Une nouvelle version du logiciel est livrée à la fin du
|
||||
*sprint*.
|
||||
|
||||
Deux *backlogs* coexistent: le backlog **produit** et celui du **sprint**
|
||||
|
||||
### Le backlog
|
||||
|
||||
Il est orienté *user stories*, mais nous pouvons y ajouter des *US* non
|
||||
fonctionnelles comme les temps de réponses ou les tolérances aux pannes
|
||||
|
||||
#### Chiffrage du backlog
|
||||
|
||||
Chaque tâche a un coût, il faut l'estimer. On utilise un chiffrage abstrait
|
||||
relatif à la difficulté et défini par comparaison.
|
||||
|
||||
### Conception et suivi des tâches
|
||||
|
||||
Les choix architecturaux impactent les sprints.
|
||||
|
||||
Pour organiser les tâches et gérer leurs avancement, des réunions quotidienne --
|
||||
les *daily* -- sont organisés. Il est question de savoir **qui fait quoi**.
|
||||
|
||||
En fait de *sprint*, une réunion bilan est organisée pur faire le point de ce
|
||||
qui est a été réalisé, les points dur, les amélioration à effectuées que se soit
|
||||
le produit lui même ou l'organisation du travail. Lors de cette réunion, on
|
||||
calcule la **vélocité** : la sommes des coûts des tâches réalisées sur le
|
||||
*sprint*.
|
||||
|
||||
Deux méthodes existent pou gèrer le suivi des tâches : *GANTT* et *PERT*.
|
230
content/conduite_projet/4_tests/imgs/pyramides_tests.svg
Normal file
230
content/conduite_projet/4_tests/imgs/pyramides_tests.svg
Normal file
File diff suppressed because one or more lines are too long
After Width: | Height: | Size: 45 KiB |
75
content/conduite_projet/4_tests/index.md
Normal file
75
content/conduite_projet/4_tests/index.md
Normal file
|
@ -0,0 +1,75 @@
|
|||
---
|
||||
title: "Conduite de projet: les tests"
|
||||
date: 2024-09-30
|
||||
tags: ["tests", agile"]
|
||||
categories: ["Conduite de projet", "Cours"]
|
||||
mathjax: true
|
||||
---
|
||||
|
||||
Il existe plusieurs granularités et niveaux de tests. au plus haut niveau nous
|
||||
avons l'adéquation entre ce que l'utilisateur veut et ce qui est proposé.
|
||||
|
||||

|
||||
|
||||
Les niveaux de tests peuvent être représentés sous la forme d'une pyramide, plus
|
||||
on monte:
|
||||
|
||||
* plus les tests coûtent cher;
|
||||
* plus ils sont nombreux;
|
||||
* plus ils sont fragiles.
|
||||
|
||||
Chaque unité de test dépends du contexte: procédure, fonction, méthode, classe.
|
||||
Chaque développeur a sa façon d'écrire des tests.
|
||||
|
||||
Les tests ne doivent pas faire parti des éléments à tester, ils doivent seulement
|
||||
interagir avec eux.
|
||||
|
||||
Nous avons:
|
||||
|
||||
* Les **tests unitaires ou de composants** qui servent à tester les bouts de codes;
|
||||
* les **tests d'intégration** pour tester les intégrations de composants entre
|
||||
eux.
|
||||
* les **tests systèmes** au niveau le plus haut. permet de tester l'absence de bug au niveau de l'utilisateur
|
||||
|
||||
|
||||
## Les tests unitaires
|
||||
|
||||
Ils doivent permettre d'améliorer la confiance accordée au code et agir comme
|
||||
garde-fou. Il permettent aussi de trouver les fautes le plus tôt possible. Les
|
||||
tests doivent être le plus léger possible, facile à lancer. Ainsi ils seront
|
||||
exécutés le plus souvent possible.
|
||||
|
||||
De facto, ils deviennent des **test de non régressions**. Ainsi tout travail de
|
||||
refactorisation du code sera plus simple et plus confortable.
|
||||
|
||||
### Tester quoi?
|
||||
|
||||
En général, les fautes viennent des cas limites, nous voulons que **les
|
||||
résultats obtenus** soient égaut **aux résultats attendus**
|
||||
|
||||
### Anomalies et bugs
|
||||
|
||||
Une anomalie dans le code fait que notre programme ne fonctionne pas comme il le
|
||||
devrait, elle déclenche un bug.
|
||||
|
||||
Un bon développeur ne doit pas avoir peur des anomalies et il doit pouvoir les
|
||||
fixer. Un **bon testeur** doit trouver ces anomalies. Comme nous l'avons vu, si
|
||||
`RO != RA` alors nous avond un bug. Pour le testeur, il faut préciser *l'état
|
||||
initial*, la *suite de traitement*, et *le résultat attendu*.
|
||||
|
||||
### Les oracles
|
||||
|
||||
Parfois, il n'est pas possible de définir les **cas aux limites**. Dans ce cas
|
||||
il est possible de passer par une **oracle**: une fonction test qui vérifie les
|
||||
sorties pour un ensemble de valeurs en entrée. Dans le cadre d'une fonction de
|
||||
tri, il est par exemple possible de créer une fonction qui définira une suite de
|
||||
nombres choisi aléatoirement en entrée et vérifiera la sortie.
|
||||
|
||||
|
||||
## Test d'intégration
|
||||
|
||||
Ici nous testons les appels necessaires, il faut alors vérifier que nous n'avons pas d'erreurs et les valeurs qui nous sont retournées (validités du JSON par exemple).
|
||||
|
||||
## Tests de validation
|
||||
|
||||
Il faut "*scripter*" un scénario d'utilisation, définir le résultat attendu et le lancer et jouer notre scénario. Des outils spécialisés existent comme *Scelenium* pour tester les application web.
|
30
content/conduite_projet/5_code/index.md
Normal file
30
content/conduite_projet/5_code/index.md
Normal file
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
title: "Conduite de projet: le code"
|
||||
date: 2024-10-07
|
||||
tags: [ "code", "bonnes pratiques"]
|
||||
categories: ["Conduite de projet", "Cours"]
|
||||
---
|
||||
|
||||
Il est question ici d'adopter les bonnes pratiques en matière de code. en voici une liste non exhastive.
|
||||
|
||||
## Coder proprement
|
||||
|
||||
Il est question de rendre le code lisible. Un code peu lisible a plus de chance de contenir des bugs ou failles de sécurité. Il faut alors le normliser en utilisant des conventions de nommage (variables, classes, methodes, fonctions etc.).
|
||||
|
||||
## Coder sans vulnérabilité
|
||||
|
||||
La lisibilité du code aide à éviter des failles, mais il est aussi nécessaire de se tenir au courant des bonnes pratiques en matière de sécurité. On peut utiliser un analyseur statique de code ou encore faire appel à un expert (audit de code).
|
||||
Si des biliothèques sont necessaires au fonctionnement de notre logiciel, il faut alors s'assurer que ces dernières ne contiennes pas non plus de vulnérabilités.
|
||||
|
||||
## Porter la conception
|
||||
|
||||
Pour tout projet logiciel, il est nécessaire de passer par une phase de conception et ainsi choisir une architecture. Le code doit nous premettre de comprendre l'architecture.
|
||||
|
||||
## Organiser les modifications de code
|
||||
|
||||
Un code source doit être versionné, et les moddifications apportées à celui-ci enregistrées sous forme de *commits*.
|
||||
Ces **commits** doivent être cloisonnés afin d'identifier clairement sur quelle tâche / issue il porte.
|
||||
Le cloisement soit être connu à l'avance des dévellopeurs.
|
||||
Un *commit* se soit d'être **atomique**, la modification doit porter sur une seule finalité.
|
||||
|
||||
Les modifications sur le code soivent être le plus précise et contrôlées (*pair-reviewing*)
|
|
@ -2,7 +2,7 @@
|
|||
title: "Installation : Postfix + LDAP"
|
||||
categories: ["Installation", "TD machine"]
|
||||
tags: ["Postfix", "LDAP", "maildir"]
|
||||
date: 2018-10-4
|
||||
date: 2018-10-04
|
||||
lastmod: 2018-10-18
|
||||
---
|
||||
|
||||
|
|
|
@ -3,8 +3,6 @@ title: "Sécurité logicielle : TD 9 Hackme"
|
|||
date: 2023-04-14
|
||||
tags: ["Assembleur", "x86"]
|
||||
categories: ["Sécurité logicielle", "TD"]
|
||||
author:
|
||||
- Yorick Barbanneau
|
||||
---
|
||||
|
||||
## Level 0
|
||||
|
|
107
flake.lock
generated
Normal file
107
flake.lock
generated
Normal file
|
@ -0,0 +1,107 @@
|
|||
{
|
||||
"nodes": {
|
||||
"flake-parts": {
|
||||
"inputs": {
|
||||
"nixpkgs-lib": "nixpkgs-lib"
|
||||
},
|
||||
"locked": {
|
||||
"lastModified": 1736143030,
|
||||
"narHash": "sha256-+hu54pAoLDEZT9pjHlqL9DNzWz0NbUn8NEAHP7PQPzU=",
|
||||
"owner": "hercules-ci",
|
||||
"repo": "flake-parts",
|
||||
"rev": "b905f6fc23a9051a6e1b741e1438dbfc0634c6de",
|
||||
"type": "github"
|
||||
},
|
||||
"original": {
|
||||
"owner": "hercules-ci",
|
||||
"repo": "flake-parts",
|
||||
"type": "github"
|
||||
}
|
||||
},
|
||||
"nixpkgs": {
|
||||
"locked": {
|
||||
"lastModified": 1737885589,
|
||||
"narHash": "sha256-Zf0hSrtzaM1DEz8//+Xs51k/wdSajticVrATqDrfQjg=",
|
||||
"owner": "NixOS",
|
||||
"repo": "nixpkgs",
|
||||
"rev": "852ff1d9e153d8875a83602e03fdef8a63f0ecf8",
|
||||
"type": "github"
|
||||
},
|
||||
"original": {
|
||||
"id": "nixpkgs",
|
||||
"ref": "nixos-unstable",
|
||||
"type": "indirect"
|
||||
}
|
||||
},
|
||||
"nixpkgs-lib": {
|
||||
"locked": {
|
||||
"lastModified": 1735774519,
|
||||
"narHash": "sha256-CewEm1o2eVAnoqb6Ml+Qi9Gg/EfNAxbRx1lANGVyoLI=",
|
||||
"type": "tarball",
|
||||
"url": "https://github.com/NixOS/nixpkgs/archive/e9b51731911566bbf7e4895475a87fe06961de0b.tar.gz"
|
||||
},
|
||||
"original": {
|
||||
"type": "tarball",
|
||||
"url": "https://github.com/NixOS/nixpkgs/archive/e9b51731911566bbf7e4895475a87fe06961de0b.tar.gz"
|
||||
}
|
||||
},
|
||||
"nixpkgs_2": {
|
||||
"locked": {
|
||||
"lastModified": 1735554305,
|
||||
"narHash": "sha256-zExSA1i/b+1NMRhGGLtNfFGXgLtgo+dcuzHzaWA6w3Q=",
|
||||
"owner": "nixos",
|
||||
"repo": "nixpkgs",
|
||||
"rev": "0e82ab234249d8eee3e8c91437802b32c74bb3fd",
|
||||
"type": "github"
|
||||
},
|
||||
"original": {
|
||||
"owner": "nixos",
|
||||
"ref": "nixpkgs-unstable",
|
||||
"repo": "nixpkgs",
|
||||
"type": "github"
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"inputs": {
|
||||
"flake-parts": "flake-parts",
|
||||
"nixpkgs": "nixpkgs",
|
||||
"systems": "systems",
|
||||
"treefmt-nix": "treefmt-nix"
|
||||
}
|
||||
},
|
||||
"systems": {
|
||||
"locked": {
|
||||
"lastModified": 1681028828,
|
||||
"narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
|
||||
"owner": "nix-systems",
|
||||
"repo": "default",
|
||||
"rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
|
||||
"type": "github"
|
||||
},
|
||||
"original": {
|
||||
"id": "systems",
|
||||
"type": "indirect"
|
||||
}
|
||||
},
|
||||
"treefmt-nix": {
|
||||
"inputs": {
|
||||
"nixpkgs": "nixpkgs_2"
|
||||
},
|
||||
"locked": {
|
||||
"lastModified": 1738070913,
|
||||
"narHash": "sha256-j6jC12vCFsTGDmY2u1H12lMr62fnclNjuCtAdF1a4Nk=",
|
||||
"owner": "numtide",
|
||||
"repo": "treefmt-nix",
|
||||
"rev": "bebf27d00f7d10ba75332a0541ac43676985dea3",
|
||||
"type": "github"
|
||||
},
|
||||
"original": {
|
||||
"owner": "numtide",
|
||||
"repo": "treefmt-nix",
|
||||
"type": "github"
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": "root",
|
||||
"version": 7
|
||||
}
|
24
flake.nix
Normal file
24
flake.nix
Normal file
|
@ -0,0 +1,24 @@
|
|||
{
|
||||
description = "Nix flake for building latex document";
|
||||
|
||||
inputs = {
|
||||
nixpkgs.url = "nixpkgs/nixos-unstable";
|
||||
flake-parts.url = "github:hercules-ci/flake-parts";
|
||||
treefmt-nix.url = "github:numtide/treefmt-nix";
|
||||
};
|
||||
|
||||
outputs =
|
||||
inputs@{
|
||||
nixpkgs,
|
||||
flake-parts,
|
||||
systems,
|
||||
...
|
||||
}:
|
||||
flake-parts.lib.mkFlake { inherit inputs; } {
|
||||
systems = [ "x86_64-linux" ];
|
||||
imports = [
|
||||
inputs.treefmt-nix.flakeModule
|
||||
./nix/default.nix
|
||||
];
|
||||
};
|
||||
}
|
134
latex/includes/preambule.tex
Normal file
134
latex/includes/preambule.tex
Normal file
|
@ -0,0 +1,134 @@
|
|||
% Packages
|
||||
\RequirePackage[left=2cm, right=2cm, top=2cm, bottom=3cm]{geometry}
|
||||
\RequirePackage{fontawesome}
|
||||
\RequirePackage{xcolor}
|
||||
\usepackage{float}
|
||||
\usepackage[french]{babel}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{array}
|
||||
\usepackage{pdfpages}
|
||||
\usepackage[explicit]{titlesec}
|
||||
\usepackage{soul}
|
||||
\usepackage[
|
||||
labelfont={small,bf,color=LightGrey},
|
||||
textfont={small,color=SlateGrey}
|
||||
]{caption}
|
||||
\usepackage{listings}
|
||||
\lstset{
|
||||
basicstyle=\ttfamily\footnotesize,
|
||||
breaklines=true
|
||||
}
|
||||
|
||||
\renewcommand{\FrenchLabelItem}{\textbullet}
|
||||
\pagestyle{fancy}
|
||||
|
||||
\renewcommand{\headrulewidth}{0pt}
|
||||
\renewcommand{\arraystretch}{1.4}
|
||||
% OPTIONS
|
||||
|
||||
% Captions
|
||||
\captionsetup[table]{name=tableau}
|
||||
\captionsetup[figure]{name=figure}
|
||||
|
||||
% Graphx
|
||||
\graphicspath{ {./images/} }
|
||||
|
||||
% Colors and fonts
|
||||
\definecolor{ElectricMagenta}{HTML}{F268B3}
|
||||
\definecolor{ElectricGreen}{HTML}{1CD180}
|
||||
\definecolor{SlateGrey}{HTML}{2E2E2E}
|
||||
\definecolor{LightGrey}{HTML}{CCCCCC}
|
||||
\definecolor{UltraLightGrey}{HTML}{EFEFEF}
|
||||
\definecolor{Black}{HTML}{000000}
|
||||
\setulcolor{ElectricMagenta}
|
||||
|
||||
% Fonts
|
||||
\setmainfont[SizeFeatures={Size=8}]{Lato}
|
||||
% \setmonofont{FiraCode-Regular}
|
||||
\newfontfamily\quotefont[SizeFeatures={Size=10}]{Linux Libertine O}
|
||||
|
||||
|
||||
\AtBeginEnvironment{quote}{%
|
||||
\vspace{-15pt} % Reduce space above the quote
|
||||
}
|
||||
\newcommand*\openquote{\makebox(30,-30){\scalebox{3}{\flqq{}}}}
|
||||
\newcommand*\closequote{\makebox(30,0){\scalebox{3}{\frqq{}}}}
|
||||
|
||||
% Quote
|
||||
\AtBeginEnvironment{quote}{\color{LightGrey}\large\quotefont\openquote\color{SlateGrey}}
|
||||
\AtEndEnvironment{quote}{\color{LightGrey}\closequote}
|
||||
|
||||
% figures
|
||||
\AtEndEnvironment{figure}{%
|
||||
\color{ElectricMagenta}\noindent\rule{\textwidth}{0.4pt}
|
||||
}
|
||||
\AtEndEnvironment{table}{%
|
||||
\color{ElectricMagenta}\noindent\rule{\textwidth}{0.4pt}
|
||||
}
|
||||
\AfterEndEnvironment{lstlisting}{%
|
||||
{\color{ElectricMagenta}\noindent\rule{\textwidth}{0.4pt}}
|
||||
}
|
||||
|
||||
\BeforeBeginEnvironment{itemize}{%
|
||||
\vspace{5pt}
|
||||
}
|
||||
|
||||
% Code
|
||||
\lstset{
|
||||
backgroundcolor=\color{UltraLightGrey},
|
||||
captionpos=b,
|
||||
numbers=left,
|
||||
xleftmargin=5pt,
|
||||
xrightmargin=5pt,
|
||||
frame=single,
|
||||
framesep=5pt,
|
||||
rulecolor=\color{UltraLightGrey},
|
||||
keywordstyle=\color[rgb]{0,0,1},
|
||||
commentstyle=\color[rgb]{0.133,0.545,0.133},
|
||||
stringstyle=\color[rgb]{0.627,0.126,0.941},
|
||||
}
|
||||
|
||||
% Hyperlink
|
||||
\usepackage[hidelinks]{hyperref}
|
||||
\newcommand{\link}[2]{
|
||||
\href{#1}{\ul{{\color{ElectricGreen}\faLink} #2}}
|
||||
}
|
||||
|
||||
%\newcommand{\link}[2]{
|
||||
% {\ul{{\color{ElectricGreen}\faLink} #2}
|
||||
% \footnote{\ul{{\color{ElectricGreen}\faLink} #1}}}
|
||||
%}
|
||||
|
||||
% Paragraph ...
|
||||
\parindent=0em
|
||||
\renewcommand{\baselinestretch}{1.2}
|
||||
|
||||
% pagehead, pagefoot
|
||||
\fancyhead[LE]{\footnotesize\color{SlateGrey}Yorick Barbanneau}
|
||||
\fancyhead[RO]{\footnotesize\color{SlateGrey}Introduction à la vérification}
|
||||
\fancyhead[LO]{\footnotesize\color{SlateGrey}Yorick Barbanneau}
|
||||
\fancyhead[RE]{\footnotesize\color{SlateGrey}Introduction à la vérification}
|
||||
|
||||
|
||||
% chapter titles
|
||||
%\titleformat{hcommand}[hshape]{format}{label}{sep}{before-code}[after-code]
|
||||
\titleformat{\chapter}[display]{}{
|
||||
\Large\color{ElectricMagenta}\chaptertitlename\ \thechapter~
|
||||
\huge\color{Black}\textbf{#1}
|
||||
}{0pt}{}[]
|
||||
|
||||
\titleformat{name=\chapter, numberless}[display]{}{
|
||||
%\Large\color{ElectricMagenta}\chaptertitlename\ \thechapter~
|
||||
\huge\color{Black}\textbf{#1}
|
||||
}{0pt}{}[]
|
||||
|
||||
\titleformat{\section}
|
||||
{\normalfont\large\bfseries}{\thesection}{1em}{#1}
|
||||
|
||||
\titleformat{\subsection}
|
||||
{\normalfont\normalsize\bfseries}{\thesubsection}{1em}{#1}
|
||||
|
||||
\titlespacing{\section}{0pt}{7pt}{5pt}
|
||||
\titlespacing{\subsection}{0pt}{7pt}{2pt}
|
8
nix/default.nix
Normal file
8
nix/default.nix
Normal file
|
@ -0,0 +1,8 @@
|
|||
|
||||
{ ... }:
|
||||
{
|
||||
imports = [
|
||||
./packages.nix
|
||||
./devshells.nix
|
||||
];
|
||||
}
|
28
nix/devshells.nix
Normal file
28
nix/devshells.nix
Normal file
|
@ -0,0 +1,28 @@
|
|||
_: {
|
||||
config.perSystem =
|
||||
{
|
||||
config,
|
||||
inputs',
|
||||
pkgs,
|
||||
...
|
||||
}:
|
||||
{
|
||||
devShells = {
|
||||
default = pkgs.mkShell {
|
||||
name = "hugo-shell";
|
||||
nativeBuildInputs = config.develPackages
|
||||
++ config.hugoBuildPackages
|
||||
;
|
||||
shellook = ''
|
||||
mkdir -p themes
|
||||
ln -snf "${config.themePackage}/" "themes/mainroad"
|
||||
'';
|
||||
};
|
||||
latex = pkgs.mkShell {
|
||||
name = "latex-shell";
|
||||
nativeBuildInputs = config.develPackages
|
||||
++ config.latexBuildPackages;
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
81
nix/packages.nix
Normal file
81
nix/packages.nix
Normal file
|
@ -0,0 +1,81 @@
|
|||
{
|
||||
lib,
|
||||
inputs,
|
||||
...
|
||||
}:
|
||||
let
|
||||
inherit (lib) mkOption mdDoc types;
|
||||
inherit (inputs.flake-parts.lib) mkPerSystemOption;
|
||||
in
|
||||
{
|
||||
options.perSystem = mkPerSystemOption (
|
||||
{
|
||||
pkgs,
|
||||
config,
|
||||
...
|
||||
}:
|
||||
{
|
||||
options = {
|
||||
latexBuildPackages = mkOption {
|
||||
description = mdDoc "Packages needed to build latex file";
|
||||
type = types.listOf types.package;
|
||||
default = with pkgs; [
|
||||
(pkgs.texlive.combine {
|
||||
inherit (pkgs.texlive)
|
||||
babel-french
|
||||
caption
|
||||
collection-luatex
|
||||
float
|
||||
fontawesome
|
||||
fontspec
|
||||
lato
|
||||
libertine
|
||||
listings
|
||||
lstfiracode
|
||||
pdfpages
|
||||
pdflscape
|
||||
scheme-basic
|
||||
soul
|
||||
titlesec
|
||||
xcolor
|
||||
;
|
||||
})
|
||||
fira-code
|
||||
];
|
||||
};
|
||||
|
||||
hugoBuildPackages = mkOption {
|
||||
description = mdDoc "Packages needed to build latex file";
|
||||
type = types.listOf types.package;
|
||||
default = with pkgs; [
|
||||
hugo
|
||||
];
|
||||
};
|
||||
|
||||
themePackage = mkOption {
|
||||
description = mdDoc "Theme user for my course note";
|
||||
default = pkgs.stdenvNoCC.mkDerivation {
|
||||
name = "hugo-theme-mainroad";
|
||||
pname = "hugo-theme-mainroad";
|
||||
src = pkgs.fetchFromGitHub {
|
||||
owner = "vimux";
|
||||
repo = "mainroad";
|
||||
rev = "13e04b3694ea2d20a68cfbfaea42a8c565079809";
|
||||
sha256 = "sha256-td8xQhAz/TnjZmOKIEiQjRgzdoicRrVN9h41Uxnnaso=";
|
||||
};
|
||||
installPhase = ''
|
||||
cp -r $src $out
|
||||
'';
|
||||
};
|
||||
};
|
||||
develPackages = mkOption {
|
||||
description = mdDoc "Python package used to development";
|
||||
type = types.listOf types.package;
|
||||
default = with pkgs; [
|
||||
convco
|
||||
go-task
|
||||
];
|
||||
};
|
||||
};
|
||||
});
|
||||
}
|
26
shell.nix
26
shell.nix
|
@ -1,26 +0,0 @@
|
|||
with (import <nixpkgs> {});
|
||||
let
|
||||
hugo-theme-mainroad = pkgs.stdenvNoCC.mkDerivation {
|
||||
name = "hugo-theme-mainroad";
|
||||
src = pkgs.fetchFromGitHub {
|
||||
owner = "vimux";
|
||||
repo = "mainroad";
|
||||
rev = "13e04b3694ea2d20a68cfbfaea42a8c565079809";
|
||||
sha256 = "sha256-td8xQhAz/TnjZmOKIEiQjRgzdoicRrVN9h41Uxnnaso=";
|
||||
};
|
||||
installPhase = ''
|
||||
cp -r $src $out
|
||||
'';
|
||||
preferLocalBuild = true;
|
||||
};
|
||||
in
|
||||
mkShell {
|
||||
buildInputs = [
|
||||
hugo
|
||||
];
|
||||
|
||||
shellHook = ''
|
||||
mkdir -p themes
|
||||
ln -snf "${hugo-theme-mainroad}/" "themes/mainroad"
|
||||
'';
|
||||
}
|
15
taskfiles/latex.yaml
Normal file
15
taskfiles/latex.yaml
Normal file
|
@ -0,0 +1,15 @@
|
|||
version: "3"
|
||||
vars:
|
||||
LATEX_BUILD_DIR: build
|
||||
LATEX_BIN: lualatex
|
||||
LATEX_OPTS: --interaction=nonstopmode
|
||||
tasks:
|
||||
build:
|
||||
desc: Build PDF from LaTeX source
|
||||
cmds:
|
||||
- |
|
||||
mkdir {{.LATEX_BUILD_DIR}} -p
|
||||
{{.LATEX_BIN}} {{.LATEX_OPTS}} --output-directory {{.LATEX_BUILD_DIR}} {{.CLI_ARGS}}
|
||||
preconditions:
|
||||
- sh: 'test -f {{.CLI_ARGS}}'
|
||||
msg: file `{{.CLI_ARGS}}` does not exists
|
29
taskfiles/site.yaml
Normal file
29
taskfiles/site.yaml
Normal file
|
@ -0,0 +1,29 @@
|
|||
version: "3"
|
||||
vars:
|
||||
HUGO_BIN: hugo
|
||||
BUILD_OPTS: --gc --cleanDestinationDir
|
||||
BUILD_DEST: public
|
||||
SERVE_OPTS: -D --disableFastRender
|
||||
DEPLOY_BIN: rsync
|
||||
DEPLOY_OPTS: -avz --delete
|
||||
tasks:
|
||||
test:
|
||||
cmds:
|
||||
- echo "$DEPLOY_SRV"
|
||||
build:
|
||||
cmds:
|
||||
- |
|
||||
{{.HUGO_BIN}} {{.BUILD_OPTS}} -d {{.BUILD_DEST}}
|
||||
serve:
|
||||
cmds:
|
||||
- |
|
||||
{{.HUGO_BIN}} {{.SERVE_OPTS}}
|
||||
deploy:
|
||||
deps: [build]
|
||||
cmds:
|
||||
- |
|
||||
{{.DEPLOY_BIN}} {{.DEPLOY_OPTS}} {{.BUILD_DEST}} {{.DEPLOY_SRV}}:{{.DEPLOY_DEST}}
|
||||
requires:
|
||||
vars:
|
||||
- DEPLOY_SRV
|
||||
- DEPLOY_DEST
|
Loading…
Add table
Add a link
Reference in a new issue