Reorganize repository

SandBox/Links

@@ -0,0 +1,4 @@
+LAB: OWNCLOUD SERVER USING CEPH-RBD FOR PRIMARY BACKING STORAGE AND CEPH-S3 FOR ADDITIONAL EXTERNAL STORAGE + NEXTCLOUD WITH FULL CEPH-S3 PRIMARY STORAGE BACKEND
+https://github.com/tigerlinux/tigerlinux-extra-recipes/tree/master/recipes/misc/ceph-owncloud-lab
+
+

SandBox/Mail_1.txt

@@ -0,0 +1,7 @@
+Dear colleagues,
+
+Climate data (climate simulations, palaeo reconstructions, reanalyses or observational references) make the heart of our scientic work, our teaching activities and dissemination of our research to wider audiences including the media and social networks. Maintaining a well-organized climate data base at TECLIM is therefore essential to facilitate our everyday work and in particular that of early-stage scientists (Master and PhD students) who are not necessarily aware of data availability nor where and how to obtain them. An up-to-date climate data base is also an asset in case a seemingly extreme climate event occurs and a journalist wants to know more about it. It would be painful to explain that you can't precisely answer how unusual the event was, just because you don't have the data at hand.
+
+In light of these needs, and the current lack of a coordinated data management strategy in our pole, Pierre-Yves and myself would like to call a meeting to discuss several issues and how to move forward towards a more integrated and consistent data management at TECLIM. Your participation to that meeting is highly encouraged if you plan to be a user of these data in the future, because this meeting will the place where conventions, meta-data specification, standards and best practices will be discussed.
+
+Please, fill in the following doodle before this Thursday night (the 12th of January). In the mean time, Pierre-Yves and myself will prepare an agenda of items to be discussed.

SandBox/Mail_2.txt

@@ -0,0 +1 @@
+Je mets quelques infos sur les serveurs THREDDS en pièce jointe. En gros, si je suis bien, ça te permet de travailler sur des fichiers sans les avoir localement, et ça c'est vachement pratique. Si tu as besoin de plus amples infos n'hésite pas à contacter Pierre-Antoine (pierre-antoine.bretonniere@bsc.es) qui gère ça là-bas. Hugues, Antoine et moi allons à Barcelone les 8-9 juin pour un meeting, si tu penses que c'est nécessaire tu peux voir si c'est pas possible d'y aller en même temps que nous pour rencontrer les gens qui bossent sur cette thématique (ça te fera gagner du temps!). 

SandBox/Projet_brevet_02.txt

@@ -0,0 +1,65 @@
+Conception du projet
+plan de travail, ressources,
+
+Choix techniques
+
+Outils de mise en oeuvre
+
+L'objectif est la création d'une interface de gestion de données sous forme d'une application web service. 
+
+Framework
+
+Un framework est un cadre qui permet de structurer le travail de développement grâce à un ensemble d'outils, une structure et des modèles prêts-à-l'emploi.
+Étant donné l'étendue des développements à effectuer pour concevoir une application web moderne, un framework est indispensable.
+
+Django est un framework Backend Open Source développé en Python. Il a été spécialement créé pour réaliser des sites Web puissants et de haut niveau. Il embarque tous les composants utiles, que ce soit la gestion de vues, l'authentification, le mapping objet-relationnel, une documentation détaillée, etc.
+Python est un avantage car c'est le langage le plus utilisé par les chercheurs en ELIC. En outre, les services IT de l'UCL utilisent également ce framework pour les nouveaux développements web.
+Une alternative solide serait Ruby on Rails (RoR). Il est le framework libre le plus populaire ces 5 dernières années. Ce framework a été conçu pour développer des applications Web plus rapidement. Il permet aux développeurs de créer des fonctionnalités avec moins de code que d'autres frameworks. 
+Mais si RoR nécessite peu de configuration, il exige aussi plus de conventions. En outre, Le niveau d'expertise pour se lancer est une barrière à l'entrée pour les débutants. Enfin Ruby nécessite des ressources serveur plus importantes que Django et des frameworks PHP, et sa technologie comme son utilisation sont en déclin.
+
+Python/Django sera utilisé pour la conception du projet.
+C'est un framework Full-Stack - il est très facile de combiner Django et Angular par exemple - et tout clé en main : modèles, côté serveur, panneau d'administration pour configurer un site sans coder, etc.
+Il utilise le patron de conception modèle-vue-contrôleur (MVC), c'est à dire que la structure du framework sépare les données (models) qui sont séparées des traitements (controller) qui sont eux-mêmes séparés de la vue (view/template).
+C'est également un outil idéal pour un projet collaboratif.
+Enfin, Django étant très populaire auprès des développeurs web, de nombreux projets sont apparus autour du framework. Par exemple dans notre cas, Ncdjango est un ensemble d'outils de gestion de données et de géotraitement écrits en Python qui fonctionnent sur des données NetCDF.
+
+Environnement
+
+Cette application sera conteneurisée. La conteneurisation logicielle permet une gestion simplifiée des dépendances: une application et toutes ses dépendances sont placées dans une seule unité. Le système hôte ne doit pas se soucier de ces dépendances.
+L'application conteneurisée est donc indépendante de l'architecture ou des ressources de l'hôte. Elle est donc plus flexible et plus facilement distribuable.
+Si cette conteneurisation apporte son lot d'avantages en développement et pour les tests de validation, son utilisation reste plus discutable dans le contexte d'une mise en production. Nous en rediscuterons plus en avant dans ce projet.
+
+Docker est la solution de conteneurisation la plus utilisée aujourd’hui. C'est un logiciel libre qui utilise une interface de programmation « Libcontainer » pour démarrer, gérer et arrêter des conteneurs. Il est basée sur le fonctionnement de LXC et y ajoute des capitée de niveau supérieur. Les conteneurs Docker peuvent servir d’images à d'autres conteneurs et le partage de conteneurs en public est possible via un service en ligne appelé Docker Hub. Il contient des images de conteneurs, ce qui permet aux utilisateurs de faire des échanges. Cela rend l’installation d’un conteneur extrêmement facile.
+
+Outils de développement
+
+PyCharm est un environnement de développement intégré utilisé pour développer en Python ainsi qu'avec Django. Il propose la possibilité de débuger en direct dans un conteneur Docker.
+
+Vagrant est un logiciel libre et open-source pour la création et la configuration des environnements de développement virtuel. Il peut être considéré comme un wrapper autour de logiciels de virtualisation comme VirtualBox.
+
+Méthodologie
+
+L'application sera donc standardisée MVC, c'est-à-dire selon une architecture classique à 3 couches.
+
+La couche de vue sera développées très simplement sur base de templates existants à l'UCL.
+
+Les couches traitement et modèle présenteront les cas de figure suivants:
+- données locales: traitement "on the fly" sur DB(s) locales 130.104
+- données distantes
+  - à posteriori (DB & protocoles connus)
+  - à priori (infos de structures à soumettre)
+- données distantes
+  - indexées: traitement "on the fly" (batch process possible sur DB distante)
+  - non-indexées: traitement différé (DB distante accessible en interactif uniquement)
+
+Scénarios pour les données à posteriori et non-indexées:
+- téléchargement tiers + demande d'intégration aux DB locales
+- téléchargement à travers l'appli + intégration automatique aux DB locales
+
+Comme nous souhaitons mettre à disposition des données pour quelles soient utilisées sur d’autres plateformes et qu'elles puissent intéragir avec d’autres données, une architecture REST ("REpresentational State Transfer") semble appropriée ici.
+L'architecture REST est plus axée sur un modèle orienté ressources (les données, dans notre cas) que sur un modèle orienté fonctions. Elle imite la façon dont le web lui-même fonctionne dans les échanges entre un client et un serveur.
+REST constitue donc une méthode d'intégration efficace puisque le service à développer ici concerne surtout la récupération de données. Aussi, plutôt que de définir toute une API (interfaces de programmation d'application) personnalisée mieux vaut utiliser un standard de manipulation des données CRUD (Create, Read, Update, Delete : créer, lire, mettre à jour, supprimer), qui "correspond" aux opérations HTTP (HyperText Transfert Protocol) GET, PUT, POST et DELETE. Ce fonctionnement ne repose pas sur la seule utilisation de ces opérateurs, mais sur une combinaison avec des URI.
+
+Le "Django REST framework" va nous permettre de créer plus facilement une API REST sur notre application Django.
+
+Un interfacage avec Amazon S3 serait un atout supplémentaire.

SandBox/ToDo_ELIC.txt

@@ -0,0 +1,23 @@
+ncview OK
+
+Keep original files in their native format
+
+Important: what do we do with data that was given by a colleague but is unofficial? Add a tag telling what privacy is? Restrict permissions? Important to archive such data.
+
+Not clear what we do with
+
+naming: stick to CMIP conventions for model output.
+
+The
+
+put variable at lower level, then institution.
+
+don't worry about non-gridded data right now, just store them.
+
+scripts don't force
+
+scripts : 1) to dowload: 2) to process: 3) others are welcome.
+separate scripts into official/dirty. Documentation is important.
+
+
+We start by a prototype 

SandBox/brevet.txt

@@ -0,0 +1,137 @@
+GridFTP is an extension of the File Transfer Protocol (FTP) for grid computing.
+There are multiple implementations of the protocol; the most widely used is that provided by the Globus Toolkit.
+
+Infrastructure
+
+trouver l'infrastructure de test --> elixir (ELIC), ELI ? SGSI ?
+connexion en GB: CISM (DCIII) ou SGSI (Pythagore, Cyclotron)
+configuration: environnement Linux, gateway, vrtualisation (docker, virtualBox ?), agrégation de liens, etc
+using a GridFTP client
+installing and configuring a GridFTP server
+persistence et reproductibilité aisée de la configuration (via Ansible ?)
+trouver l'infrastructure de production (stockage, contrôle, etc)
+versionning du projet: git ou mercurial
+synergie: CISM - SRI - ELI/ELIC
+
+Application
+
+architecture 3-tiers à client léger
+
+couches présentation & middleware:
+plusieurs langages possibles: PHP, R, python, Java, Nodejs
+choix (ou pas) de frameworks associés: Zend ou Symfony, Shiny, Django, Spring, Express, etc.
+
+couche middleware:
+objectif de programmation fonctionnelle (scala ?)
+Idéal: "Language Agnostic" pour les différentes tâches 
+
+couche accès aux données: MongoDB, MySQL, PostgresSQL
+1) simple (via MySQL)
+2) puis via DB distribuée.
+   - multi-sites UCL
+   - puis multi-sites extérieurs ?
+
+Données
+
+- données locales, traitement "on the fly", DB(s) locales 130.104
+- données externes 
+  - à posteriori (DB & protocoles connus)
+  - à priori (infos de structures à soumettre)
+- données externes
+  - indexées: traitement "on the fly" (batch process possible sur DB distante)
+  - non-indexées: traitement différé (DB distante accessible en interactif uniquement)
+
+Scénarios pour les données à posteriori et non-indexées:
+- téléchargement tiers + demande d'intégration aux DB locales
+- téléchargement à travers l'appli + intégration auto aux DB locales
+
+Catégorie(s): Application scientifique, application web, application de gestion
+
+Ce projet a pour but de créer une interface de gestion de données sous forme de web service. Le but étant de créer une application web conforme à l'architecture REpresentational State Transfer (REST), une architecture orientée services (SOA) avec le patron de conception modèle-vue-contrôleur (MVC). 
+
+https://en.wikipedia.org/wiki/Minimum_viable_product
+
+    Introduction
+        Contexte : Décrire brièvement l’environnement dans lequel s’inscrit le projet (stratégie, enjeux, domaine, etc.)
+        Historique : Donner un bref historique du contexte dans lequel s’inscrit le projet
+    Description de la demande
+        Les objectifs : Définir les résultats que le projet doit atteindre
+        Produit du projet : Proposer une description générale de ce produit
+        Les fonctions du produit : Lister et justifier les principales fonctionnalités du produit
+    Contraintes
+        Contraintes de délais : Spécifier la date de livraison du produit et les éventuelles échéances intermédiaires
+        Contraintes matérielles : Spécifier le matériel nécessaire au bon fonctionnement du produit
+        Autres contraintes : Spécifier les éventuelles contraintes à prendre en compte dans le cadre du projet (normes techniques, clauses juridiques, etc.)
+    Déroulement du projet
+        Planification : Représenter les grandes phases du projet et les étapes principales
+        Ressources : Lister les ressources humaines et matérielles
+        Organisation : Décrire l’ensemble des activités introduites dans l’organigramme des tâches de la gestion de projet (Décomposition en tâches, Structure des équipes)
+
+https://www.appvizer.fr/magazine/services-informatiques/framework/django/developpement-web-serveur-ou-client
+
+http://apprendre-python.com/page-django-introduction-python
+
+Un framework est un cadre qui permet de structurer le travail des développeurs grâce à un ensemble d'outils, une structure et des modèles prêts-à-l'emploi.
+Étant donné l'étendue des développements à effectuer pour concevoir une application Web moderne, un framework est indispensable.
+
+Django est un framework Backend Open Source développé en Python. Il a été spécialement créé pour réaliser des sites Web puissants et de haut niveau.
+Python est un avantage car c'est le langage le plus utilisé par les chercheurs en ELIC. En outre, les services IT de l'UCL utilisent également ce framework pour les nouveaux développements web.
+Une alternative solide est Ruby on Rails (RoR). Il est le framework MVC libre le plus populaire. Ce framework a été conçu pour développer des applications Web plus rapidement. Il permet aux développeurs de créer des fonctionnalités avec moins de code que d'autres frameworks. 
+Mais si RoR nécessite peu de configuration, il exige aussi plus de conventions. En outre, Le niveau d'expertise pour se lancer est une barrière à l'entrée pour les débutants. Enfin Ruby nécessite des ressources serveur plus importantes que Django et des frameworks PHP, et sa technologie comme son utilisation sont en déclin.
+
+Framework Full-Stack (il est très facile de combiner Django et Angular) et tout clé en main : modèles, côté serveur, panneau d'administration pour configurer un site sans coder, etc.
+Il utilise le patron de conception modèle-vue-contrôleur (MVC), c'est à dire que la structure du framework sépare les données (models) qui sont séparées des traitements (controller) qui sont eux-mêmes séparés de la vue (view/template).
+C'est également un outil idéal pour un projet collaboratif.
+
+Enfin, Django étant très populaire auprès des développeurs web, de nombreux projets sont apparus autour du framework. Par exemple dans notre cas, Ncdjango est un ensemble d'outils de gestion de données et de géotraitement écrits en Python qui fonctionnent sur des données NetCDF.
+
+Application web serveur Python/Django (raison: choix en interne UCL) + Docker
+
+https://blog.imirhil.fr/2016/10/09/docker-container-hell.html
+
+Environnement de développement avec Vagrant
+
+Docker est un logiciel libre qui automatise le déploiement d'applications dans des conteneurs logiciels. "Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur Linux". Ceci permet d'étendre la flexibilité et la portabilité d’exécution d'une application.
+
+Django est un cadre applicatif open-source de développement web en Python (Framework), et il a pour objectif de rendre le développement web simple et rapide. Il embarque tous les composants utiles, que ce soit la gestion de vues, authentification, le mapping objet-relationnel, une documentation détaillée, etc.
+
+PyCharm est un environnement de développement intégré utilisé pour développer en Python ainsi qu'avec Django. Il propose la possibilité de débuger en direct dans un conteneur Docker.
+
+Vagrant est un logiciel libre et open-source pour la création et la configuration des environnements de développement virtuel. Il peut être considéré comme un wrapper autour de logiciels de virtualisation comme VirtualBox.
+
+https://www.supinfo.com/articles/single/5779-bien-debuter-avec-django-docker
+
+Scaling Django: https://djangobook.com/scaling-django/
+
+Django est généralement considéré par de nombreux développeurs comme un framework Web MVC, mais il peut également être utilisé pour créer un back-end (développement orienté serveur), qui dans ce cas est une API.
+
+Comme nous souhaitons mettre à disposition des données pour quelles soient utilisées sur d’autres plateformes ou que nos données intéragissent avec d’autres, une architecture REST ("REpresentational State Transfer") semble appropriée ici.
+L'architecture REST est plus axée sur un modèle orienté ressources (les données, dans notre cas) que sur un modèle orienté fonctions. Elle imite la façon dont le web lui-même fonctionne dans les échanges entre un client et un serveur.
+REST constitue donc une méthode d'intégration efficace puisque le service à développer ici concerne surtout la récupération de données. Aussi, plutôt que de définir toute une API (interfaces de programmation d'application) personnalisée mieux vaut utiliser un standard de manipulation des données CRUD (Create, Read, Update, Delete : créer, lire, mettre à jour, supprimer), qui "correspond" aux opérations HTTP (HyperText Transfert Protocol) GET, PUT, POST et DELETE. Ce fonctionnement ne repose pas sur la seule utilisation de ces opérateurs, mais sur une combinaison avec des URI.
+
+Le "Django REST framework" va nous permettre de créer plus facilement une API REST sur notre application Django.
+
+Un interfacage avec Amazon S3 serait un atout supplémentaire
+
+https://medium.com/backticks-tildes/lets-build-an-api-with-django-rest-framework-32fcf40231e5
+
+https://medium.com/python-pandemonium/building-and-deploying-an-enterprise-django-web-app-in-16-hours-79e018f7b94c
+
+L'URI constitue la clé unique d'une ressource spécifique. Si cette ressource affiche des relations avec d'autres ressources – par exemple, une Commande associée à une Personne – les URI jouent le rôle des clés étrangères qui permettent de parcourir ces relations. Sachant que l'architecture REST tire parti de la technologie d'hypermédia en tant que moteur de l'état des applications HATEOAS (Hypermedia As The Engine Of Application State), il ne reste plus à l'utilisateur qu'à extraire l'URI de la représentation de la ressource et d'exécuter une opération HTTP GET pour accéder aux informations.
+
+La seule élimination de WSDL et SOAP ne donne pas une architecture REST.
+
+Parallèlement, la technologie HATEOAS est essentielle à la flexibilité. Que se passe-t-il lorsque la structure doit changer ? Si le parcours vers ces relations est spécifié dynamiquement via des liens intégrés à la réponse, vos utilisateurs n'ont pas forcément besoin de changer. De plus, ne pas être contraint à une définition et une validation d'interface rigides permet d'ajouter des éléments en fonction des besoins. Si c'est important pour l'utilisateur, il modifiera son code ; mais ce serait le cas avec n'importe quelle autre technologie.
+
+L'approche HATEOAS est très importante mais malheureusement souvent oubliée. Beaucoup pensent que l'architecture REST consiste simplement à se débarrasser de l'enveloppe SOAP et du langage WSDL (Web Services Description Language), mais ce n'est pas le cas. L'architecture REST ne nécessite aucun langage de description d'interface, comme WSDL, et fonctionne parfaitement non seulement avec le langage XML (eXtensible Markup Language), mais aussi avec JSON (JavaScript Object Notation) et tout autre type de support que vous souhaitez prendre en charge.
+
+C'est là sa grande force ; elle favorise la compatibilité au niveau de la couche de présentation, qu'il s'agisse d'une application bureautique, Web ou mobile. La seule élimination de WSDL et SOAP ne donne pas une architecture REST. Dans l'exemple Personne/Commande ci-dessus, le retour d'un code XML pour une Commande comportant un élément appelé <ID_Personne> ne rend pas le fonctionnement compatible REST, ou « RESTful », si l'utilisateur n'est pas en mesure d'effectuer une simple opération HTTP GET sur la valeur de cet identifiant. Un simple code XML/HTTP ne donne pas une architecture REST.
+
+Autre défi de l'architecture REST, elle peut conduire à un modèle plus fin. Quand fournissez-vous un lien dans vos réponses, plutôt que les données réelles issues d'une relation ? Argument à décharge, il s'agit d'un choix conceptuel qui reste possible. Ainsi, rien ne vous empêche de renvoyer un lien à suivre, en même temps qu'une partie des données elles-mêmes. Considérez l'opération comme une jointure à laquelle s'ajouterait le renvoi d'une clé étrangère permettant d'obtenir davantage de données.
+Enfin, si la simplicité de REST s'avère plutôt attrayante, elle rend parallèlement plus difficile la création d'outils adaptés. Si vous envisagez des services SOAP ou XML pour ces outils, WSDL ou XSD (ou les deux) sont essentiels à leur mise en oeuvre.
+
+Avec REST, l'affaire est toute autre... Certains outils accepteront les POJO (Plain Old Java Object) ou un schéma relationnel, qu'ils exposeront via REST. De même, rien ne vous empêche de définir un schéma XML pour une représentation XML renvoyée par un service RESTful, et d'utiliser un genre d'API JAXB pour la conversion en Java. Ne perdez cependant pas de vue que s'appuyer sur ces fichiers – notamment si le schéma est repris au moment de l'exécution – génère des contraintes supplémentaires susceptibles de rendre plus coûteuse la prise en charge des modifications.
+
+Globalement, je suis content que la question se soit posée de cette manière, et non du point de vue du classique débat SOAP ou REST. Dans des décisions de ce type, rien n'est absolu ; il y a des avantages et des inconvénients. Quiconque a travaillé dans un service informatique connaît les passions que déchaîne chaque approche et les nombreux exemples de réussites et d'échecs. Il est bien plus important de comparer les forces et les faiblesses de chaque approche à celles de votre organisation.
+
+Pour résumer, si vous publiez une API complexe vers l’extérieur, SOAP vous sera plus utile. Mais pour quelque chose avec une courbe d’apprentissage rapide, des transactions simples et des résultats rapides, ma préférence va à REST.

SandBox/nextcloud.txt

@@ -0,0 +1,3 @@
+ORCID
+Registration 
+