ajoute la repertoire doc de l'application

_config.yml

@@ -5,13 +5,37 @@ description: >- # this means to ignore newlines until "baseurl:"
 baseurl: "" # the subpath of your site, e.g. /blog
 url: "" # the base hostname & protocol for your site, e.g. http://example.com
 twitter_username: dossiersco
+collections:
+  posts:
+    title: Actualités
+    output: true
+    permalink: "/posts/:title/"
+  tutoriels:
+    title: Tutoriels
+    output: true
+    permalink: "/tutoriels/:title/"
+  hypotheses:
+    title: Hypotheses
+    output: true
+    permalink: "/hypotheses/:title/"
+  decisions:
+    title: Décisions
+    output: true
+    permalink: "/decisions/:title/"
+    sort_by: date
+collections_dir: collections
+defaults:
+  -
+    scope:
+      path: ""
+    values:
+      layout: "page"
 
 # Build settings
 markdown: kramdown
 theme: minima
 plugins:
   - jekyll-feed
-
 # Exclude from processing.
 # The following items will not be processed, by default. Create a custom list
 # to override the default setting.

_includes/header.html

@@ -2,14 +2,20 @@
   <div class="navbar__container">
     <a class="navbar__home" href="/">
       <img class="navbar__logo" src="/assets/images/republique_francaise.svg" alt="logo Dossiersco" />
-      <span class="navbar__domain">DossierSCO : le blog</span>
+      <span class="navbar__domain">DossierSCO : documentation</span>
     </a>
     <ul class="nav__links">
       <li class="nav__item">
-        <a href="/">Tous les articles</a>
+        <a href="/">Actualités</a>
       </li>
       <li class="nav__item">
-        <a href="/tutoriel">Tutoriel</a>
+        <a href="/tutoriels">Tutoriels</a>
+      </li>
+      <li class="nav__item">
+        <a href="/hypotheses">Hypothèses</a>
+      </li>
+      <li class="nav__item">
+        <a href="/decisions">Décisions</a>
       </li>
       <li class="nav__item">
         <a href="/faq">Foire aux questions</a>

_layouts/decisions.html

@@ -0,0 +1,19 @@
+---
+layout: default
+---
+
+<div class="home">
+  {%- if page.title -%}
+    <h1 class="page-heading">{{ page.title }}</h1>
+  {%- endif -%}
+
+  {{ content }}
+  {%- if site.decisions.size > 0 -%}
+  {% assign decisions = site.decisions | reverse %}
+  <ul>
+      {%- for decision in decisions -%}
+      <li><a href="{{ decision.url | relative_url }}"><b>{{ decision.title | escape }}</b></a></li>
+      {%- endfor -%}
+  </ul>
+  {%- endif -%}
+</div>

_layouts/hypotheses.html

@@ -0,0 +1,18 @@
+---
+layout: default
+---
+
+<div class="home">
+  {%- if page.title -%}
+    <h1 class="page-heading">{{ page.title }}</h1>
+  {%- endif -%}
+
+  {{ content }}
+  {%- if site.hypotheses.size > 0 -%}
+  <ul>
+      {%- for hypothese in site.hypotheses -%}
+      <li><a href="{{ hypothese.url | relative_url }}"><b>{{ hypothese.title | escape }}</b></a></li>
+      {%- endfor -%}
+  </ul>
+  {%- endif -%}
+</div>

_layouts/tutoriels.html

@@ -0,0 +1,18 @@
+---
+layout: default
+---
+
+<div class="home">
+  {%- if page.title -%}
+    <h1 class="page-heading">{{ page.title }}</h1>
+  {%- endif -%}
+
+  {{ content }}
+  {%- if site.tutoriels.size > 0 -%}
+  <ul>
+      {%- for tuto in site.tutoriels -%}
+      <li><a href="{{ tuto.url | relative_url }}"><b>{{ tuto.title | escape }}</b></a></li>
+      {%- endfor -%}
+  </ul>
+  {%- endif -%}
+</div>

collections/_decisions/20100531-propose-enregistrer-uniquement-les-changements.md

@@ -0,0 +1,14 @@
+---
+title: Enregistrer uniquement les changements
+---
+
+## Contexte
+
+Enregistrer uniquement les changements... event sourcing.
+
+Beaucoup d'activité sur DossierSCO on pour objectif d'observer des changements. Ça semble une occasion intéressante pour essayer d'utiliser un format de stockage basé sur l'event sourcing.
+
+## Decision
+
+## Conséquences
+

collections/_decisions/20180322-accepte-change_de_base_de_donnee.md

@@ -0,0 +1,49 @@
+---
+title: Changer de base de donnée
+---
+
+## Contexte
+
+_
+### Le problème de la dualité chaines/symboles
+
+Jeudi 15 Mars un problème de duplication de champs des objets stockés
+(deux "lv2" avec des valeurs différentes "Allemand" et "Espagnol")
+est diagnotiqué le lendemain en mob programming comme un ennième problème
+de la dialectique Ruby entre chaines et symboles.
+
+Systématiquement utiliser des chaines de caractères dans le code est
+vu comme insuffisant par @Morendil : les symboles vont revenir par la
+fenêtre un jour ou l'autre.
+
+Après un carrottage, le choix est fait de passer à une base SQL avant que
+davantage de code dépendant de Redis ne soit écrit.
+
+### Les temps de réponse sont dégradés par le passage à PostgreSQL
+
+Une augmentation des temps de réponse de près de 50 % est constatée :
+
+* redis : accueil servi en ~ 770 ms
+* postgres : accueil servi en ~ 1100 ms
+
+Ces temps de réponse sont dus à l'emploi du server shotgun pour relancer
+à chaque requête le serveur.
+
+En passant au serveur builtin de sinatra (rackup) on descent vers 30 ms.
+Changements à faire :
+
+* "bundle exec rackup -p9393 --host 0.0.0.0" dans docker-compose.yml
+* require 'rack' dans dossiersco_web.rb
+
+
+## Decision
+
+La configuration de postgres dans docker-compose.yml est plus légère que
+celle de mysql. Les plans financiers sur les services d'hébergement en
+europe sont raisonnables pour postgres :
+
+* scalingo : gratuit jusqu'à 500 Go, 14 Euros pour 1 Go / 60 connexions simultanées
+* heroku : gratuit jusqu'à 10000 lignes, 9$ pour 10 Millions de lignes /
+ 20 connexions simultanées, 50$ pour 64 Go / 120 connexions
+
+

collections/_decisions/20181219-accepte-change_de_framework.md

@@ -0,0 +1,22 @@
+---
+title: Change de framework
+---
+
+## Contexte
+
+Sinatra n'est pas un _framework_ mais une librairie. Sinatra est peut connu. La
+mise en place de certaine chose (comme l'upload de document) semble plus
+compliqué avec Sinatra qu'avec Rails.
+
+Il commence à y avoir beaucoup de route, et les controlleurs manque.
+
+## Decision
+
+Basculer sur Ruby On Rails avant d'ajouter plus de code dans Sinatra.
+
+## Conséquences
+
+Plus de fichiers et de code, mais une organisation plus classique pour qui
+connais le framework Ruby On Rails.
+
+L'organisation des tests devrait également être un peu modifié.

collections/_decisions/20181219-acceptee-enregistre_decisions_architecture.md

@@ -0,0 +1,36 @@
+---
+title: Utiliser les Enregistrement de Décision d'Architecture (ADR en anglais)
+---
+
+## Contexte
+
+Les équipes se suivent et ne se ressemble pas forcement. L'oralité ne suffit
+pas pour transmettre des informations, des décisions prises, un historique.
+
+DossierSCO etant accessible en licence libre, c'est important de pouvoir être
+transparant, et de communiquer, y compris sur nos décisions d'architecture.
+
+## Décision
+
+Documenter simplement, et prêt du code, nos décisions d'architecture en
+utilisant la forme simple de fichier dans le repo git. Voir l'article source de
+notre décision :
+http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions.
+
+Nous utiliserons (pour le moment) un simple fichier dans un répertoire
+particulier `doc/architecture` dans le nom suivra la convention
+`YYYYMMDD-titre.md` et le contenu sera en markdown (organisé suivant la
+structure visible dans le fichier `doc/architecture/_template.md`
+
+## Consequences
+
+L'équipe devra écrire et commenté les décisions d'architecture qu'elle souhaite
+prendre.
+
+Nous pouvons aussi envisager d'utiliser ces fichiers pour soumettre une
+proposition de modification d'architecture par le biais d'une revue (à
+l'occasion d'une demande de fusion). L'équipe prendra soin, dans cette
+situation, de reporter une partie des échanges qui aurons eu lieu dans un autre
+endroit que le fichier d'enregistrement de la décision.
+
+

collections/_decisions/20181219-acceptee-utiliser-makefile.md

@@ -0,0 +1,15 @@
+---
+title: Change de framework
+---
+
+## Contexte
+
+Pour rester le plus proche possible de l'environnement de production, nous voulons utiliser des containers. Cela permet aussi de partager des envivonnement le plus proche possible entre nous.
+
+Les commandes `docker-compose` sont parfois un peu longue, avec beaucoup d'option, alors que nous utilisons souvent les même.
+
+## Decision
+
+Utiliser un fichier Makefile pour avoir un set de commande simple à utiliser.
+
+Cette décision est très largement inspiré de l'article [Standardizing interfaces acress projets with makefiles](https://blog.trainline.eu/13439-standardizing-interfaces-across-projects-with-makefiles) lu sur le blog de Trainline.eu (ex-CapitainTrain).

collections/_decisions/20190114-en-cours-changement-de-mailer.md

@@ -0,0 +1,11 @@
+---
+title: Changement de mailer
+---
+
+## Contexte
+
+- en utilisant le compte mailjet mutualisé de betagouv, on risque d'imposer aux autres Startups nos erreurs de config qui affectent la réputation (et inversement)
+
+## Decision
+
+- on crée un compte mailjet dédié DossierSco

collections/_decisions/20190116-remplacer-les-fixtures.md

@@ -0,0 +1,16 @@
+---
+title: Remplacer les fixtures
+---
+
+## Contexte
+
+L'utilisation de _fixture_ ne permet pas d'avoir un environnement neutre au démarrage d'un test, éloigne des tests les informations du contexte.
+
+La construction des données telle quelle existe aujourd'hui, n'utilise même pas les fixtures minitest, mais l'appel d'une fonction étrange.
+
+## Decision
+
+- Mettre en place [Fabrication](https://www.fabricationgem.org/).
+
+- Déplacer la procédure d'initialisation de quelques données fictives dans une tache `Rake` permettant de peupler n'importe quelle base de donnée.
+

collections/_decisions/20190117-abandonnee-une-instance-par-college.md

@@ -0,0 +1,14 @@
+---
+title: Deployer une instance par collège
+---
+
+## Contexte
+
+Dans beaucoup de table, nous conservons l'identifiant établissement. Dans chaque requête, nous faisons un filtre avec ce code établissement.
+
+## Decision
+
+Déployer une instance par collège permettrais de ne pas avoir à stocker l'identifiant établissement et faire des filtres dessus.
+
+Après discussion avec Scalingo, et entre nous, nous avons décidé que le coup n'en vaut pas la chandelle. Le nombre d'instance serait trop grand, alors que le problème n'est pas vraiment grave ou génant. On décide d'abandonner (pour le moment du moins)
+

collections/_decisions/20190121-acceptee-structure-le-fichier-de-locale.md

@@ -0,0 +1,15 @@
+---
+title: Structure le fichier de locale
+---
+
+## Contexte
+
+Il existe plusieurs façons de structurer les locales :
+- clés absolues (qui permettent une grande liberté de structurer par domaine fonctionnel ou technique, ...) ou clés relatives à l'arborescence proposée par Rails
+
+
+## Decision
+
+Nous choisissons les clés relatives :
+- pour avoir des clés plus courtes à manipuler
+- tous les textes du même écran sont regroupés

collections/_decisions/20190125-acceptee-remplace-carrierwave-par-active-storage.md

@@ -0,0 +1,16 @@
+# Remplace Carrierwave par ActiveStorage
+
+## Contexte
+
+- Lorsque nous utilisions le framework Sinatra, nous utilisions Carrierwave pour l'upload de fichiers.
+- Nous avons migré de Sinatra à Rails
+
+- Rails 5 permet grâce à ActiveStorage d'uploader et de référencer simplement des documents dans des services de cloud (comme Amazon S3, Google Cloud Storage ou Microsoft Azure Storage)
+
+## Decision
+
+Nous choisissons de ne plus utiliser Carrierwave et de s'appuyer maintenant sur ActiveStorage pour simplifier la configuration (et limiter le nombre de librairie que nous utilisons)
+
+## Conséquences
+
+- lorsque nous stockerons nos fichiers sur l'object storage d'ovh, nous devrons développer un service openstack qui hérite de https://github.com/rails/rails/blob/master/activestorage/lib/active_storage/service.rb

collections/_decisions/20190130-acceptee-code-sans-accent.md

@@ -0,0 +1,11 @@
+---
+title: Code sans accent
+---
+
+## Contexte
+
+En ruby, les fonctions et classe peuvent être écrit avec des accents. Nous avons décidé d'écrire en français dans le code. Utiliser les accents est plus élégants. Mais dans la console, cela pose problème.
+
+## Decision
+
+Nous continuerons à écrire en français, mais sans accent.

collections/_decisions/20190131-acceptee-remplace-active-storage-par-carrierwave.md

@@ -0,0 +1,14 @@
+---
+title: Remplace ActiveStorage par Carrierwave
+---
+
+## Contexte
+
+- ActiveStorage est un module de Rails très récent, et peu documenté.
+- Nous avons passé beaucoup de temps à essayer de faire fonctionner l'upload, sans succès
+- Nous souhaitons à terme utiliser un object store français, sûrement celui d'OVH. ActiveStorage n'a pas actuellement de service pour openstack (techno utilisée pour l'object storage d'OVH)
+
+## Decision
+
+_On revient sur CarrierWave_
+

collections/_decisions/20190414-rejetee-deploiement_pas_automatique.md

@@ -0,0 +1,25 @@
+---
+title: Déploiement pas automatique
+---
+
+## Contexte
+
+Après avoir reconstruit l'environnement de démo depuis zéro, nous ne pouvons
+plus déployer en automatique depuis CircleCI. Puisque le CircleCI utilise la
+clef SSH publique de Christophe, il faut qu'il accède à l'application.
+
+Ça crée une relation très (trop ?) forte entre la plateforme de déploiement et
+un membre de l'équipe.
+
+## Decision
+
+Après avoir envisager de revenir à un script qui permet de déployer facilement à partir de la
+branche courante, nous avons finalement opté pour garder un déploiement automatique.
+
+Par contre, pour résoudre le soucis du déploiement à partir de CircleCI avec la
+clef publique d'un membre de l'équipe, nous allons branché directement Scalingo
+à notre github.
+
+Nous allons également déployer automatiquement en production et en démo à
+partir d'une seule branche, renomé Master; Gestion en
+[trunk-based](https://en.wikipedia.org/wiki/Trunk_%28software%29).