Compare commits

..

10 commits

20 changed files with 945 additions and 131 deletions

View file

@ -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
View 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

View file

@ -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"

View file

@ -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**:
![Schéma: les six artefacts](./imgs/6_artefacts.svg)
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)

View 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.

View 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*.

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 45 KiB

View 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é.
![Pyramides des tests](./imgs/pyramides_tests.svg)
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.

View 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*)

View file

@ -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
---

View file

@ -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
View 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
View 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
];
};
}

View 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
View file

@ -0,0 +1,8 @@
{ ... }:
{
imports = [
./packages.nix
./devshells.nix
];
}

28
nix/devshells.nix Normal file
View 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
View 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
];
};
};
});
}

View file

@ -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
View 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
View 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