air - User contributions [en]

File:VT2018 kafka presentation.pdf

2020-10-12T15:47:02Z

Timothee.Depriester: Timothee.Depriester uploaded a new version of File:VT2018 kafka presentation.pdf

PROJET-1FO5 1819 CampusIoT

2019-03-19T10:43:01Z

Timothee.Depriester:

=Le projet en quelques mots=
Ce projet à pour but de travailler sur la platforme CampusIoT en rajoutant certaines fonctionnalitées, sécuriser l'application et améliorer la gestion de l'authentification. La plateforme CampusIoT est un réseau LoRaWAN pour l'enseignement pratiques des technologies IoT long-range dans les établissements d'enseignement supérieur sur Grenoble et Valence. Ce réseau comporte plusieurs stations de base réparties dans des batiments des Campus.

=L'équipe et leurs rôles=

* William Weill - Chef de projet
* Timothée Depriester - DevOps
* Benjamin Besnier - Leading React software development
* Guillaume Besnard - Node Orchestrator
* Théo Lévesque - Operations Manager (installation master)

=Avancé équipe=
==Sprint 1 - Du 28/01/18 au 03/02/18 ==
Prise en main d'outils :
* LoRa Gateway et émetteur.
* Test déploiement LoRaServer.
* Lecture de documentation et test de création de cluster Kubernetes sur VPS.

==Sprint 2 - Du 04/02/18 au 10/02/18 ==
* Création organisation github et fork Lora Geo Server et Lora App Server.
* Mise en place d'environnement Docker de développement pour pouvoir compiler et déployer rapidement des modifications au Lora App Server et Lora Geo Server.
* Design et implémentation d'un calcul de géolocalisation RSSI.

==Sprint 3 - Du 11/02/18 au 17/02/18 ==
* Design et implémentation d'un calcul de géolocalisation TDDOA.
* Implémentation d'une API en go pour cette géolocalisation.
* Compréhension et modification de Lora Geo Server pour pouvoir utiliser un autre backend de géolocalisation et lancement de tests correspondants.
* Problème pour l'implémentation de Gateway Tokens : impossible de recréer l'api (make api). [Bug ref](https://github.com/brocaar/lora-app-server/issues/293)
* Début d'utilisation de 3 gateways pour avoir une résolution de géolocalisation.

==Sprint 4 - Du 18/02/18 au 24/02/18 ==
==Sprint 5 - Du 25/02/18 au 03/03/18 ==

=Remarque concernant le duty cycle=

==Rappel==

Pour rappel, le duty cycle consiste en la limitation du temps de parole de chaque objet est limité à 1% (plus d'informations [ici](https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html) ).

==Cas du LoRaServer==

Dans notre cas, en temps que LoRaServer, nous avons la responsabilité de toutes les passerelles de notre réseau. Cela permet au LoRaServer de connaître à tout moment l'état de l'utilisation de chaque passerelle et de répartir la charge pour améliorer l'efficacité globale.
Pour cela, plusieurs solutions s'offrent à nous, elles ont été discuté avec Brocaar, mainteneur de LoRaServer [ici](https://github.com/brocaar/loraserver/issues/383) :

* Estimer l'utilisation de chaque passerelle en calculant le duty cycle au niveau de la fonction d'envoi "sendDownlinkFrame" du fichier "internal/downlink/data/data.go". En effet, grâce aux informations théoriques contenues dans la structure "txInfo" (puissance d'émission, slot d'émission, fréquence, gain, ...), il est possible d'estimer le "Time Over the Air".

* Une autre solution qui semble être le parti pris de Broocar serait de déléguer le calcul de son propre duty cycle à chaque passerelle: cela permettrai de ne plus avoir d'informations théoriques mais des informations réelles et correctes. Cela permettrai aussi plus de modularité et dé-complexifierai le code coté LoRaServer en déléguant la difficulté au packet forwarder. Il faudrait par contre que les firmwares des passerelles calculent leur propre utilisation du réseau et envoient régulièrement des messages en MQTT pour en informer le LoRaServer qui pourrrait donc répartir la charge. Cela crée donc une dépendance du LoraServer avec les packet forwarder et demande du travail de ces fournisseurs (ex: Semtech).

Finalement, lors de l'envoi réel de l'information à la passerelle, une structure contenant toutes les passerelles triées en fonction du SNR et rssi (lorsque le SNR est considéré comme suffisamment bon, on trie par rssi). Au lieu d'utiliser la première gateway du tableau pour envoyer, on pourrait boucler dessus et prendre la première gateway du tableau ayant un duty cycle respecté. A défaut de gateway disponible (SNR/Rssi trop mauvais et/ou duty cycle non respecté), le message est perdu. On pourrait imaginer journaliser l'information dans le but d'avertir l'administrateur qui pourrait constater un nombre de passerelles insuffisant.

==Remarque==
Ce controle du duty cycle ne s'appliquerait qu'aux messages envoyés en unicast et as ceux en multicast qui utilisent une autre méthode d'envoi.

PROJET-1FO5 1819 CampusIoT

2019-03-18T15:22:34Z

Timothee.Depriester: /* Avancé équipe */

=Le projet en quelques mots=
Ce projet à pour but de travailler sur la platforme CampusIoT en rajoutant certaines fonctionnalitées, sécuriser l'application et améliorer la gestion de l'authentification. La plateforme CampusIoT est un réseau LoRaWAN pour l'enseignement pratiques des technologies IoT long-range dans les établissements d'enseignement supérieur sur Grenoble et Valence. Ce réseau comporte plusieurs stations de base réparties dans des batiments des Campus.

=L'équipe et leurs rôles=

* William Weill - Chef de projet
* Timothée Depriester - DevOps
* Benjamin Besnier - Leading React software development
* Guillaume Besnard - Node Orchestrator
* Théo Lévesque - Operations Manager (installation master)

=Avancé équipe=
==Sprint 1 - Du 28/01/18 au 03/02/18 ==
Prise en main d'outils :
* LoRa Gateway et émetteur.
* Test déploiement LoRaServer.
* Lecture de documentation et test de création de cluster Kubernetes sur VPS.

==Sprint 2 - Du 04/02/18 au 10/02/18 ==
* Création organisation github et fork Lora Geo Server et Lora App Server.
* Mise en place d'environnement Docker de développement pour pouvoir compiler et déployer rapidement des modifications au Lora App Server et Lora Geo Server.
* Design et implémentation d'un calcul de géolocalisation RSSI.

==Sprint 3 - Du 11/02/18 au 17/02/18 ==
* Design et implémentation d'un calcul de géolocalisation TDDOA.
* Implémentation d'une API en go pour cette géolocalisation.
* Compréhension et modification de Lora Geo Server pour pouvoir utiliser un autre backend de géolocalisation et lancement de tests correspondants.
* Problème pour l'implémentation de Gateway Tokens : impossible de recréer l'api (make api). [Bug ref](https://github.com/brocaar/lora-app-server/issues/293)
* Début d'utilisation de 3 gateways pour avoir une résolution de géolocalisation.

==Sprint 4 - Du 18/02/18 au 24/02/18 ==
==Sprint 5 - Du 25/02/18 au 03/03/18 ==

# Remarque concernant le duty cycle

## Rappel

Pour rappel, le duty cycle consiste en la limitation du temps de parole de chaque objet est limité à 1% (plus d'informations [ici](https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html) ).

## Cas du LoRaServer

Dans notre cas, en temps que LoRaServer, nous avons la responsabilité de toutes les passerelles de notre réseau. Cela permet au LoRaServer de connaître à tout moment l'état de l'utilisation de chaque gateway et de répartir la charge pour améliorer l'efficacité globale.
Pour cela, plusieurs solutions s'offrent à nous, elles ont été discuté avec Brocaar, mainteneur de LoRaServer [ici](https://github.com/brocaar/loraserver/issues/383) :

- Estimer l'utilisation de chaque passerelle en calculant le duty cycle au niveau de la fonction d'envoi "sendDownlinkFrame" du fichier "internal/downlink/data/data.go". En effet, grâce aux informations théoriques contenues dans la structure "txInfo" (puissance d'émission, slot d'émission, fréquence, gain, ...), il est possible d'estimer le "Time Over the Air".

- Une autre solution qui semble être en train de devenir le nouveau standard serait de déléguer le calcul de son propre duty cycle à chaque passerelle: cela permettrai de ne plus avoir d'informations théoriques mais des informations réelles et correctes. Cela permettrai aussi plus de modularité et dé-complexifierai le code coté LoRaServer en déléguant la difficulté au packet forwarder. Il faudrait par contre que les firmwares des passerelles calculent leur propre utilisation du réseau et envoient régulièrement des messages en MQTT pour en informer le LoRaServer qui pourrrait donc répartir la charge.

Finalement, lors de l'envoi réel de l'information à la passerelle, une structure contenant toutes les passerelles triées en fonction du SNR et rssi (lorsque le SNR est considéré comme suffisamment bon, on trie par rssi). Au lieu d'utiliser la première gateway du tableau pour envoyer, on pourrait boucler dessus et prendre la première gateway du tableau ayant un duty cycle respecté. A défaut de gateway disponible (SNR/Rssi trop mauvais et/ou duty cycle non respecté), le message est perdu. On pourrait imaginer journaliser l'information dans le but d'avertir l'administrateur qui pourrait constater un nombre de passerelle insuffisant.

## Remarque
Ce controle du duty cycle ne s'appliquerait qu'aux messages envoyés en unicast et as ceux en multicast qui utilisent une autre méthode d'envoi.

PROJET-1FO5 1819 CampusIoT

2019-03-18T15:22:21Z

Timothee.Depriester: /* Sprint 5 - Du 25/02/18 au 03/03/18 */

PROJET-1FO5 1819 CampusIoT

2019-03-18T15:21:55Z

Timothee.Depriester: /* Avancé équipe */

=Le projet en quelques mots=
Ce projet à pour but de travailler sur la platforme CampusIoT en rajoutant certaines fonctionnalitées, sécuriser l'application et améliorer la gestion de l'authentification. La plateforme CampusIoT est un réseau LoRaWAN pour l'enseignement pratiques des technologies IoT long-range dans les établissements d'enseignement supérieur sur Grenoble et Valence. Ce réseau comporte plusieurs stations de base réparties dans des batiments des Campus.

=L'équipe et leurs rôles=

* William Weill - Chef de projet
* Timothée Depriester - DevOps
* Benjamin Besnier - Leading React software development
* Guillaume Besnard - Node Orchestrator
* Théo Lévesque - Operations Manager (installation master)

=Avancé équipe=
==Sprint 1 - Du 28/01/18 au 03/02/18 ==
Prise en main d'outils :
* LoRa Gateway et émetteur.
* Test déploiement LoRaServer.
* Lecture de documentation et test de création de cluster Kubernetes sur VPS.

==Sprint 2 - Du 04/02/18 au 10/02/18 ==
* Création organisation github et fork Lora Geo Server et Lora App Server.
* Mise en place d'environnement Docker de développement pour pouvoir compiler et déployer rapidement des modifications au Lora App Server et Lora Geo Server.
* Design et implémentation d'un calcul de géolocalisation RSSI.

==Sprint 3 - Du 11/02/18 au 17/02/18 ==
* Design et implémentation d'un calcul de géolocalisation TDDOA.
* Implémentation d'une API en go pour cette géolocalisation.
* Compréhension et modification de Lora Geo Server pour pouvoir utiliser un autre backend de géolocalisation et lancement de tests correspondants.
* Problème pour l'implémentation de Gateway Tokens : impossible de recréer l'api (make api). [Bug ref](https://github.com/brocaar/lora-app-server/issues/293)
* Début d'utilisation de 3 gateways pour avoir une résolution de géolocalisation.

==Sprint 4 - Du 18/02/18 au 24/02/18 ==
==Sprint 5 - Du 25/02/18 au 03/03/18 ==

# Remarque concernant le duty cycle

## Rappel

Pour rappel, le duty cycle consiste en la limitation du temps de parole de chaque objet est limité à 1% (plus d'informations [ici](https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html) ).

## Cas du LoRaServer

Dans notre cas, en temps que LoRaServer, nous avons la responsabilité de toutes les passerelles de notre réseau. Cela permet au LoRaServer de connaître à tout moment l'état de l'utilisation de chaque gateway et de répartir la charge pour améliorer l'efficacité globale.
Pour cela, plusieurs solutions s'offrent à nous, elles ont été discuté avec Brocaar, mainteneur de LoRaServer [ici](https://github.com/brocaar/loraserver/issues/383) :

- Estimer l'utilisation de chaque passerelle en calculant le duty cycle au niveau de la fonction d'envoi "sendDownlinkFrame" du fichier "internal/downlink/data/data.go". En effet, grâce aux informations théoriques contenues dans la structure "txInfo" (puissance d'émission, slot d'émission, fréquence, gain, ...), il est possible d'estimer le "Time Over the Air".

- Une autre solution qui semble être en train de devenir le nouveau standard serait de déléguer le calcul de son propre duty cycle à chaque passerelle: cela permettrai de ne plus avoir d'informations théoriques mais des informations réelles et correctes. Cela permettrai aussi plus de modularité et dé-complexifierai le code coté LoRaServer en déléguant la difficulté au packet forwarder. Il faudrait par contre que les firmwares des passerelles calculent leur propre utilisation du réseau et envoient régulièrement des messages en MQTT pour en informer le LoRaServer qui pourrrait donc répartir la charge.

Finalement, lors de l'envoi réel de l'information à la passerelle, une structure contenant toutes les passerelles triées en fonction du SNR et rssi (lorsque le SNR est considéré comme suffisamment bon, on trie par rssi). Au lieu d'utiliser la première gateway du tableau pour envoyer, on pourrait boucler dessus et prendre la première gateway du tableau ayant un duty cycle respecté. A défaut de gateway disponible (SNR/Rssi trop mauvais et/ou duty cycle non respecté), le message est perdu. On pourrait imaginer journaliser l'information dans le but d'avertir l'administrateur qui pourrait constater un nombre de passerelle insuffisant.

## Remarque
Ce controle du duty cycle ne s'appliquerait qu'aux messages envoyés en unicast et as ceux en multicast qui utilisent une autre méthode d'envoi.

PROJET-1FO5 1819 CampusIoT

2019-03-18T15:21:23Z

Timothee.Depriester: /* L'équipe et leurs rôles */

File:ECOM-1FO 1819 PROJETmyCAMPING.pdf

2018-12-18T09:53:09Z

Timothee.Depriester:

ECOM-1FO 1819 Camping

2018-12-18T09:51:44Z

Timothee.Depriester: /* Auto-évaluation */

[[ECOM-1FO|<<<< Retour vers la page ECOM 2018-2019]]

Le projet ECOM consiste en la conception logistique et au développement d'une application de e-commerce.

=Le projet en quelques mots=

L’objectif de notre projet est de mettre en place un service de recherche, réservation et mise en location d'emplacement de camping de particulier à particulier. Nous avons 12 semaines (7h par semaine) pour réaliser ce projet, de la conception au développement en suivant la méthodologie Scrum.

=L'équipe et leurs rôles=

* Timothee Depriester : Chef de projet (+ Devops, Backend, Code review)
* Sekina Belguendouz : Scrum Master (+ Frontend)
* Florian Cuzin : Développeur (+ Backend)
* Servan Charlot : Lead Développeur (+ Backend, Code review, git)
* Samuel Bamba : Développeur (+ Frontend)

=Gestion de projet=

Choix des outils :

* ''Gitlab'' : pour le dépôt, pour la documentation, l'intégration en continu
* ''Trello'' : pour la répartition et la gestion des tâches hors code
* ''Drive'' : pour le partage de documentation de conception

=SCRUM=
==Sprint 1: 02/10 au 30/10==
===But===

Implémentation des scénarios 1 et 2. (V1.0 - Fonctionnalités locataire, recherche, réservation et transaction)

===Taches effectuées===

* Découverte du projet et mise en place des rôles au sein de l’équipe.
* Détermination des dates clés du projet et établissement de la longueur des sprints: 3 semaines.
* Identification des besoins client.
* Réalisation de documents de conception.
** Diagramme de contexte.
** Liste des fonctionnalité.
** Méthode de taches des scénario 1 et 2.
** IHM abstraite des scénario 1 et 2.
** Maquette (à la main).
* Choix et découverte des technologies (Lecture des docs, ...).
* Génération du projet JHipster.
* Mise en place de la BDD et du développement continu.
* Codage des templates des différentes page, selon la maquette, pour le frontend

===Audit 1: 09/10===

Ce qui est ressorti de l'audit 1 est que notre planning prévisionnel est trop audacieux et que l'on va sûrement pas être capable de le respecter. Ce dernier souhaitant que les scénarios 1 et 2 soient implémentés d'ici la fin de ce premier sprint.

===Bilan===

Nous avons effectivement manqué de temps pour réaliser le but de ce sprint. Nous avons passez du temps à rédiger les documents de conception et la mise en place de la base de donnée et du déploiement a pris plus temps que prévu à cause de bugs.

===Remarque===

V1.0 - Base de donnée et template du frontend fonctionnels

==Sprint 2: 06/11 au 27/11==

===Audit 2: 06/11===

Ce qui est ressorti de l'audit 2 est que notre planning prévisionnel est trop audacieux et que l'on va sûrement pas être capable de le respecter. Ce dernier souhaitant que les scénarios 1 et 2 soient implémentés d'ici la fin de ce premier sprint.

===But===

Implémentation des scénarios 1 et 2. (V2.0 - Ajout des fonctionnalités locataire : recherche, réservation et profil utilisateur)

===Taches effectuées===

* Mise en ligne du site
* Codage des templates des différentes page, selon la maquette, pour le frontend (accommodation, payement)
* Mise en place de la BDD et du développement continu.
* Travail sur l’api coté backend, création de nouvelle fonction pour filtrer le catalogue
* Sécurisation du serveur
* Sécurisation du token JWT
* Ajout du mail
* Requête API reliant frontend et backend

===Bilan===

Nous avons encore surestimer nos capacités. Malgré notre succès avec les requêtes à l'API. Le backend a rencontré un problème avec la création de le fonction de filtre. En attendant, on a pu avancer sur le frontend et sur d'autre fonctionnalités supplémentaires.

==Sprint 3: 04/12 au 18/12==
===But===

Implémentation des scénarios 1 et 2. (V2.0 - Ajout des fonctionnalités locataire : recherche, réservation et profil utilisateur)

===Taches effectuées===

* Ajout du mail
* Travail sur l’api coté backend, création de nouvelle fonction pour filtrer le catalogue
* Codage des templates des différentes page, selon la maquette, pour le frontend (accommodation, payement)
* Révisions des différentes page pour qu'elle puisse faire appel à la BDD. Lien frontend-backend
* Réalisation du SRS
* Réalisation de la présentation
* Modification de la base de donnée (ajout d’une colonne)
* Sécurisation accrue de l’application
* Correction d’un bug prévenant la mise en production et l’envoi de mail

===Bilan===

Nous n'avons pas pu implémenter les scénarios voulus néanmoins nous en somme très proche. Il suffirait de réaliser quelques fonctions pour l'API en backend et de les adapter au frontend:
* Nous avons besoin d'une fonction qui récupère le user avec un username.
* Nous avons besoin de faire une page profile pour les utilisateurs et de passer les requêtes a l'API pour réserver un camping.
* Mais surtout il nous faut implémenter la possibilité de payer en CB ou par Paypal.

===Remarque===

V1.1 - Implémentation du scénario 1

= Livrables =

==Analyse des scénarios clients ==
===Scénario 1===

====Profil utilisateur====

* Homme
* Majeur (Fiancé)
* Habite à Marseille (Français)
* Moyens limités
* Beaucoup de places requises
* A l'aise avec internet

====Storie====

En tant que Paul (Utilisateur), je veux pouvoir afficher le catalogue complet afin de rechercher une location.

En tant que Paul (Utilisateur), je veux pouvoir rechercher un emplacement par période et par localisation afin d'affiner ma recherche.

En tant que Paul (Utilisateur), je veux pouvoir sélectionner une annonce afin de voir les détails de la location.

====Fonctionnalités====

* Indiquer une période (filtre du catalogue)
* Cibler une région (filtre du catalogue)
* Données inter-camping par région (espaces disponibles)
* Indiques les détails des emplacements (Nombre de place, localisation, points d’intérêts à proximité ou sur l'emplacement)

===Scénario 2===

====Profil utilisateur====
* Retraités
* Pas de contrainte de temps
* Aime aller chez l'habitant
* Française
* Paye en CB

====Storie====

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir préciser un type de location et des options de confort afin d'affiner ma recherche.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir choisir un moyen de payement afin d'effectuer le payement.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir choisir un format de facturation afin de récupérer ma facture.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir consulter la disponibilité d'un logement afin de sélectionner une plage de réservation.

====Fonctionnalités====

* Cibler une commodité (place pour camping car) et afficher les resultats sans dates ni lieu.
* Lister les services additionnels. (Piscine, machine a laver, manger avec des hotes)
* Avoir une descirption sur les offres.
* Indiquer la disponibilité de l'espace choisi sur le calendrier.
* Indiquer une reduction par date.
* Pop-up de promotion pour des nuits consecutives.
* Mode de paiement en fonction de la somme (Paypal, CB).
* Facture envoyée par email ou téléchargeable en pdf.

===Scénario 3===

====Profil utilisateur====

Même profil que précédemment.

====Storie====

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir retrouver mes réservation avec un petite description et une possibilité de réimpression de la facture.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir y trouver le mail du propriétaire.

====Fonctionnalités====

* Session
* Consulter les dernières réservations (page profil)
* Par réservation : Description + télécharger la facture + Contact.

===Scenario 4===
====Profil utilisateur====

* Homme
* Père
* Propriétaire foncier

====Storie====

En tant que Claude (Utilisateurs), je veux pouvoir mettre mon camping a disposition et remplissant un formulaire sur le site.

En tant que Claude (Utilisateurs), je veux pouvoir modifier les informations de mon camping dans le futur.

En tant que Claude (Utilisateurs), je veux pouvoir recevoir par email un récapitulatif de mon enregistrement via pdf.

====Fonctionnalités====

* Ajouter un camping a la base de donnée (via formulaire)
* Différencier les utilisateur (client et propriétaire)

==Maquette==

<gallery>
File:ECOM2018-MC-M_Home.png
File:ECOM2018-MC-M_Checkout.png
File:ECOM2018-MC-M_Anonce.png
File:ECOM2018-MC-PC_Home.png
File:ECOM2018-MC-PC_Checkout.png
File:ECOM2018-MC-PC_Annonce.png
</gallery>

==SRS==
[[ECOM-1FO_1819_mycamping_L5_SRS|SRS]]

==Diagrammes UML==
<gallery>
File:ECOM2018-MC-DDC.jpeg| Diagramme de contexte.
File:ECOM2018-MC-VL.png| Vue logique.
File:ECOM2018-MC-VD.png| Vue dynamique.
File:ECOM2018-MC-VP.png| Vue physique.
File:ECOM2018-MC-BDD.png| Base de données.
</gallery>

==Modèles des tâches==
<gallery>
File:Modèle_de_Taches_Scénario_1MYCAMPING.jpg| Modèle de Taches 1
File:Modèle_de_Taches_Scénario_2MYCAMPING.jpg| Modèle de Taches 2
</gallery>

==Journal==
[https://docs.google.com/document/d/1AkqKwr9z-VgLfGpc05VFVxMH07-DId45AICF0lewxgk/edit?usp=sharing Journal de l'équipe]

==Dépôt Git==

[https://gitlab.com/ECOM-Mycamping/mycamping Lien vers les dépôts de l'organisation]

==Application en ligne==

[https://mycamping.timotheedepriester.fr/ website]

[https://mycamping.timotheedepriester.fr/#/admin/docs API OpenAPI]

==Evaluation IHM réalisée==

<gallery>
File:IHM-Abstraite1_MYCAMPING.png| IHM Abstraite 1
File:IHM-Abstraite2_MYCAMPING.png| IHM Abstraite 2
</gallery>

==Evaluation qualité du projet==

* Rapports SonarQube

[https://sonarcloud.io/dashboard?id=edu.ecom.mycamping%3Amycamping Rapports]

==Evaluation économique du projet==

Nous avons consacré l'équivalent de 450 heures/homme pour ce projet.

Si un freelanceur payé 350€ par jour avait développé l'application, celle-ci vaudrait approximativement 22.500€.

==Slides des Audits==
* [[Media:ECOM-1FO_1819_MC_Audit1.pdf]]

* [[Media:ECOM-1FO_1819_MC_Audit2.pdf]]

* [[Media:ECOM-1FO_1819_MC_Audit3.pdf]] ([https://docs.google.com/presentation/d/1KGMlplKFiRpWnBGrZNOaxKKcj3szHnQgvSBDqCEoi5Y/edit?usp=sharing Slides])

==Auto-évaluation==
* [[Media:ECOM-1FO_1819_PROJETmyCAMPING.pdf]]

==L22. Privacy Policy==

===Personal information===

Here is a list of the information we collect about you:
* First Name
* Last Name
* Mail address
* Phone number

Here is a list of the information we collect if you submit a campsite:
* Camping name (if any)
* Location
* Type of campsite
* Campiste number (if any)
* Campsite surface
* Campsite utilities
* Campsite rent price
* Campsite description

===How we collect information===

We collect information through forms on the website.

===How we use your information===

We use your first and last name to identidy you on the website. We use you mail adress to send you the invoice when you rent a campsite or when you need to reset your password.

If you create a campsite offer, those information can be used by the people renting it to contact you.

The information relative to your campiste are visible on the website to help clients decide where they want to go.

===When we share your information===

We don't share your information with any partner.

===How we store your information===

We store your information in a secured database on our server.

We keep the information forever.

===About===

Contact: mycamping2018@google.com

ECOM-1FO 1819 Camping

2018-12-18T08:40:37Z

Timothee.Depriester: /* Evaluation économique du projet */

[[ECOM-1FO|<<<< Retour vers la page ECOM 2018-2019]]

Le projet ECOM consiste en la conception logistique et au développement d'une application de e-commerce.

=Le projet en quelques mots=

L’objectif de notre projet est de mettre en place un service de recherche, réservation et mise en location d'emplacement de camping de particulier à particulier. Nous avons 12 semaines (7h par semaine) pour réaliser ce projet, de la conception au développement en suivant la méthodologie Scrum.

=L'équipe et leurs rôles=

* Timothee Depriester : Chef de projet (+ Devops, Backend, Code review)
* Sekina Belguendouz : Scrum Master (+ Frontend)
* Florian Cuzin : Développeur (+ Backend)
* Servan Charlot : Lead Développeur (+ Backend, Code review, git)
* Samuel Bamba : Développeur (+ Frontend)

=Gestion de projet=

Choix des outils :

* ''Gitlab'' : pour le dépôt, pour la documentation, l'intégration en continu
* ''Trello'' : pour la répartition et la gestion des tâches hors code
* ''Drive'' : pour le partage de documentation de conception

=SCRUM=
==Sprint 1: 02/10 au 30/10==
===But===

Implémentation des scénarios 1 et 2. (V1.0 - Fonctionnalités locataire, recherche, réservation et transaction)

===Taches effectuées===

* Découverte du projet et mise en place des rôles au sein de l’équipe.
* Détermination des dates clés du projet et établissement de la longueur des sprints: 3 semaines.
* Identification des besoins client.
* Réalisation de documents de conception.
** Diagramme de contexte.
** Liste des fonctionnalité.
** Méthode de taches des scénario 1 et 2.
** IHM abstraite des scénario 1 et 2.
** Maquette (à la main).
* Choix et découverte des technologies (Lecture des docs, ...).
* Génération du projet JHipster.
* Mise en place de la BDD et du développement continu.
* Codage des templates des différentes page, selon la maquette, pour le frontend

===Audit 1: 09/10===

Ce qui est ressorti de l'audit 1 est que notre planning prévisionnel est trop audacieux et que l'on va sûrement pas être capable de le respecter. Ce dernier souhaitant que les scénarios 1 et 2 soient implémentés d'ici la fin de ce premier sprint.

===Bilan===

Nous avons effectivement manqué de temps pour réaliser le but de ce sprint. Nous avons passez du temps à rédiger les documents de conception et la mise en place de la base de donnée et du déploiement a pris plus temps que prévu à cause de bugs.

===Remarque===

V1.0 - Base de donnée et template du frontend fonctionnels

==Sprint 2: 06/11 au 27/11==

===Audit 2: 06/11===

Ce qui est ressorti de l'audit 2 est que notre planning prévisionnel est trop audacieux et que l'on va sûrement pas être capable de le respecter. Ce dernier souhaitant que les scénarios 1 et 2 soient implémentés d'ici la fin de ce premier sprint.

===But===

Implémentation des scénarios 1 et 2. (V2.0 - Ajout des fonctionnalités locataire : recherche, réservation et profil utilisateur)

===Taches effectuées===

* Mise en ligne du site
* Codage des templates des différentes page, selon la maquette, pour le frontend (accommodation, payement)
* Mise en place de la BDD et du développement continu.
* Travail sur l’api coté backend, création de nouvelle fonction pour filtrer le catalogue
* Sécurisation du serveur
* Sécurisation du token JWT
* Ajout du mail
* Requête API reliant frontend et backend

===Bilan===

Nous avons encore surestimer nos capacités. Malgré notre succès avec les requêtes à l'API. Le backend a rencontré un problème avec la création de le fonction de filtre. En attendant, on a pu avancer sur le frontend et sur d'autre fonctionnalités supplémentaires.

==Sprint 3: 04/12 au 18/12==
===But===

Implémentation des scénarios 1 et 2. (V2.0 - Ajout des fonctionnalités locataire : recherche, réservation et profil utilisateur)

===Taches effectuées===

* Ajout du mail
* Travail sur l’api coté backend, création de nouvelle fonction pour filtrer le catalogue
* Codage des templates des différentes page, selon la maquette, pour le frontend (accommodation, payement)
* Révisions des différentes page pour qu'elle puisse faire appel à la BDD. Lien frontend-backend
* Réalisation du SRS
* Réalisation de la présentation
* Modification de la base de donnée (ajout d’une colonne)
* Sécurisation accrue de l’application
* Correction d’un bug prévenant la mise en production et l’envoi de mail

===Bilan===

Nous n'avons pas pu implémenter les scénarios voulus néanmoins nous en somme très proche. Il suffirait de réaliser quelques fonctions pour l'API en backend et de les adapter au frontend:
* Nous avons besoin d'une fonction qui récupère le user avec un username.
* Nous avons besoin de faire une page profile pour les utilisateurs et de passer les requêtes a l'API pour réserver un camping.
* Mais surtout il nous faut implémenter la possibilité de payer en CB ou par Paypal.

===Remarque===

V1.1 - Implémentation du scénario 1

= Livrables =

==Analyse des scénarios clients ==
===Scénario 1===

====Profil utilisateur====

* Homme
* Majeur (Fiancé)
* Habite à Marseille (Français)
* Moyens limités
* Beaucoup de places requises
* A l'aise avec internet

====Storie====

En tant que Paul (Utilisateur), je veux pouvoir afficher le catalogue complet afin de rechercher une location.

En tant que Paul (Utilisateur), je veux pouvoir rechercher un emplacement par période et par localisation afin d'affiner ma recherche.

En tant que Paul (Utilisateur), je veux pouvoir sélectionner une annonce afin de voir les détails de la location.

====Fonctionnalités====

* Indiquer une période (filtre du catalogue)
* Cibler une région (filtre du catalogue)
* Données inter-camping par région (espaces disponibles)
* Indiques les détails des emplacements (Nombre de place, localisation, points d’intérêts à proximité ou sur l'emplacement)

===Scénario 2===

====Profil utilisateur====
* Retraités
* Pas de contrainte de temps
* Aime aller chez l'habitant
* Française
* Paye en CB

====Storie====

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir préciser un type de location et des options de confort afin d'affiner ma recherche.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir choisir un moyen de payement afin d'effectuer le payement.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir choisir un format de facturation afin de récupérer ma facture.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir consulter la disponibilité d'un logement afin de sélectionner une plage de réservation.

====Fonctionnalités====

* Cibler une commodité (place pour camping car) et afficher les resultats sans dates ni lieu.
* Lister les services additionnels. (Piscine, machine a laver, manger avec des hotes)
* Avoir une descirption sur les offres.
* Indiquer la disponibilité de l'espace choisi sur le calendrier.
* Indiquer une reduction par date.
* Pop-up de promotion pour des nuits consecutives.
* Mode de paiement en fonction de la somme (Paypal, CB).
* Facture envoyée par email ou téléchargeable en pdf.

===Scénario 3===

====Profil utilisateur====

Même profil que précédemment.

====Storie====

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir retrouver mes réservation avec un petite description et une possibilité de réimpression de la facture.

En tant que Janine et Hervé (Utilisateurs), je veux pouvoir y trouver le mail du propriétaire.

====Fonctionnalités====

* Session
* Consulter les dernières réservations (page profil)
* Par réservation : Description + télécharger la facture + Contact.

===Scenario 4===
====Profil utilisateur====

* Homme
* Père
* Propriétaire foncier

====Storie====

En tant que Claude (Utilisateurs), je veux pouvoir mettre mon camping a disposition et remplissant un formulaire sur le site.

En tant que Claude (Utilisateurs), je veux pouvoir modifier les informations de mon camping dans le futur.

En tant que Claude (Utilisateurs), je veux pouvoir recevoir par email un récapitulatif de mon enregistrement via pdf.

====Fonctionnalités====

* Ajouter un camping a la base de donnée (via formulaire)
* Différencier les utilisateur (client et propriétaire)

==Maquette==

<gallery>
File:ECOM2018-MC-M_Home.png
File:ECOM2018-MC-M_Checkout.png
File:ECOM2018-MC-M_Anonce.png
File:ECOM2018-MC-PC_Home.png
File:ECOM2018-MC-PC_Checkout.png
File:ECOM2018-MC-PC_Annonce.png
</gallery>

==SRS==
[[ECOM-1FO_1819_mycamping_L5_SRS|SRS]]

==Diagrammes UML==
<gallery>
File:ECOM2018-MC-DDC.jpeg| Diagramme de contexte.
File:ECOM2018-MC-VL.png| Vue logique.
File:ECOM2018-MC-VD.png| Vue dynamique.
File:ECOM2018-MC-VP.png| Vue physique.
File:ECOM2018-MC-BDD.png| Base de données.
</gallery>

==Modèles des tâches==
<gallery>
File:Modèle_de_Taches_Scénario_1MYCAMPING.jpg| Modèle de Taches 1
File:Modèle_de_Taches_Scénario_2MYCAMPING.jpg| Modèle de Taches 2
</gallery>

==Journal==
[https://docs.google.com/document/d/1AkqKwr9z-VgLfGpc05VFVxMH07-DId45AICF0lewxgk/edit?usp=sharing Journal de l'équipe]

==Dépôt Git==

[https://gitlab.com/ECOM-Mycamping/mycamping Lien vers les dépôts de l'organisation]

==Application en ligne==

[https://mycamping.timotheedepriester.fr/ website]

[https://mycamping.timotheedepriester.fr/#/admin/docs API OpenAPI]

==Evaluation IHM réalisée==

<gallery>
File:IHM-Abstraite1_MYCAMPING.png| IHM Abstraite 1
File:IHM-Abstraite2_MYCAMPING.png| IHM Abstraite 2
</gallery>

==Evaluation qualité du projet==

* Rapports SonarQube

[https://sonarcloud.io/dashboard?id=edu.ecom.mycamping%3Amycamping Rapports]

==Evaluation économique du projet==

Nous avons consacré l'équivalent de 450 heures/homme pour ce projet.

Si un freelanceur payé 350€ par jour avait développé l'application, celle-ci vaudrait approximativement 22.500€.

==Slides des Audits==
* [[Media:ECOM-1FO_1819_MC_Audit1.pdf]]

* [[Media:ECOM-1FO_1819_MC_Audit2.pdf]]

* [[Media:ECOM-1FO_1819_MC_Audit3.pdf]] ([https://docs.google.com/presentation/d/1KGMlplKFiRpWnBGrZNOaxKKcj3szHnQgvSBDqCEoi5Y/edit?usp=sharing Slides])

==Auto-évaluation==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L22. Privacy Policy==

===Personal information===

Here is a list of the information we collect about you:
* First Name
* Last Name
* Mail address
* Phone number

Here is a list of the information we collect if you submit a campsite:
* Camping name (if any)
* Location
* Type of campsite
* Campiste number (if any)
* Campsite surface
* Campsite utilities
* Campsite rent price
* Campsite description

===How we collect information===

We collect information through forms on the website.

===How we use your information===

We use your first and last name to identidy you on the website. We use you mail adress to send you the invoice when you rent a campsite or when you need to reset your password.

If you create a campsite offer, those information can be used by the people renting it to contact you.

The information relative to your campiste are visible on the website to help clients decide where they want to go.

===When we share your information===

We don't share your information with any partner.

===How we store your information===

We store your information in a secured database on our server.

We keep the information forever.

===About===

Contact: mycamping2018@google.com

File:VT2018 kafka presentation.pdf

2018-12-17T14:08:44Z

Timothee.Depriester: Timothee.Depriester uploaded a new version of "File:VT2018 kafka presentation.pdf"

File:VT2018 kafka presentation.pdf

2018-12-17T13:35:33Z

Timothee.Depriester: Timothee.Depriester uploaded a new version of "File:VT2018 kafka presentation.pdf"

VT2018 kafka Demo

2018-12-17T12:30:48Z

Timothee.Depriester: Created page with "On va utiliser le quickstart fourni par Kafka : https://kafka.apache.org/quickstart"

On va utiliser le quickstart fourni par Kafka : https://kafka.apache.org/quickstart

VT2018 Kafka

2018-12-17T12:29:44Z

Timothee.Depriester: /* Démonstation */

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_topic_2018.png|390px|thumb|right|API Kafka]]
[[File:Kafka_topic2_2018.png|390px|thumb|right|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

== Démonstation ==

On va utiliser le quickstart proposé par Kafka qui est très bien réalisé.

https://kafka.apache.org/quickstart

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

VT2018 Kafka

2018-12-17T10:47:56Z

Timothee.Depriester: /* Démonstation */

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_topic_2018.png|390px|thumb|right|API Kafka]]
[[File:Kafka_topic2_2018.png|390px|thumb|right|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

== Démonstation ==

On va se reposer sur le quickstart proposé par Kafka qui est très bien réalisé.

https://kafka.apache.org/quickstart

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

VT2018 Kafka

2018-12-17T10:47:18Z

Timothee.Depriester: /* Garantie */

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_topic_2018.png|390px|thumb|right|API Kafka]]
[[File:Kafka_topic2_2018.png|390px|thumb|right|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

== Démonstation ==

On va se reposer sur le quickstart proposé par Kafka qui est très bien réalisé.

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

VT2018 Kafka

2018-12-17T10:47:08Z

Timothee.Depriester:

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_topic_2018.png|390px|thumb|right|API Kafka]]
[[File:Kafka_topic2_2018.png|390px|thumb|right|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

== Démonstation

On va se reposer sur le quickstart proposé par Kafka qui est très bien réalisé.

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

VT2018 Kafka

2018-12-17T10:44:42Z

Timothee.Depriester:

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_topic_2018.png|390px|thumb|right|API Kafka]]
[[File:Kafka_topic2_2018.png|390px|thumb|right|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

File:Kafka topic2 2018.png

2018-12-17T10:44:02Z

Timothee.Depriester:

File:Kafka topic 2018.png

2018-12-17T10:43:48Z

Timothee.Depriester:

VT2018 Kafka

2018-12-17T10:43:13Z

Timothee.Depriester:

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_topic_2018.png|390px|thumb|left|API Kafka]]
[[File:Kafka_topic2_2018.png|390px|thumb|left|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

VT2018 Kafka

2018-12-17T10:42:30Z

Timothee.Depriester:

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_topic_2018.png|390px|thumb|left|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

VT2018 Kafka

2018-12-17T10:42:04Z

Timothee.Depriester: /* Synthèse */

=Auteur=
*Nom : Timothée depriester
*Sujet : Kafka

=Résumé=

Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un système d'envoi et réception de messages, de sauvegarder ces informations de façon durable et de pouvoir les traiter à la volée.

C'est une technologie à haute performance et permettant une distribution horizontale très élevé.

L'utilisation d'un système tel que Kafka permettra d'avoir un système de message plus cohérent, fiable et évoluable.

=Abstract=

Apache Kafka is a distributed streaming platform. This technology manage to publish and subscrib to stream of records, to keep this records safe and substainable, and to compute them on the fly.

It's a powerfull technology allowing high horizontal scalability.

Usage of a technology such as Kafka will allow you to keep your system more relaible and adaptable.

=Synthèse=

Kafka est utilisé par des entreprises à très grande échelle avec des niveaux de performance très élevé. Par exemple, des entreprises tels que Linkedin ou Netflix y font transiter plus d'un trillion de messages par jour.

Il permet de centraliser tous les envois de messages à travers un seul système, cela permet une plus grande modularité et c'est primordial pour un système d'information de grande envergure. Kafka est différent de ses concurrents tel que RabbitMQ puisqu'il permet de stocker les messages pour une grande période de temps: que vous manipuliez 50kB ou 50 Tb, les performances seront les mêmes alors que RabbitMQ (ou autres) auront du mal si les données ne sont pas gérées en temps réel. C'est d'ailleurs pour cela que Kafka peut être utilisé comme une base de données. On peut citer par exemple l'offre DBAAS de OVH reposant sur la technologie Kafka.

== APIs ==

[[File:Kafka_API_2018.png|390px|thumb|right|API Kafka]]

Kafka nous fournis 4 APIs majeurs:

Les APIs Productor et Consommator qui permettent de fournir et consulter les données dans le système Kafka.

L'API Connector permettant de relier le système Kafka à d'autres services tel que des base de données.

L'API Stream permettant de traiter certaines informations envoyées dans le système Kafka (Agrégation, filtrage, calcul, ...).

Ces API sont utilisables dans une majorité des langages les plus courants (Java, Scala, Go, Python, ...)

== Système de topic ==

[[File:Kafka_API_2018.png|390px|thumb|left|API Kafka]]

Les données dans Kafka sont sauvegardé dans ce que l'on appelle des topics. C'est une représentation abstraite de comment est sauvegarder la donnée. Cette donnée est ensuite partitionné (de 1 à n partitions) ce qui permet de paralléliser les écritures sur un topic et de découper les données. Un topic peut être éparpillé sur plusieurs machines (logique ou physique), la seule contrainte est qu'une partition ne doit pas être découpé. Ensuite c'est l'une des machines qui devient leader sur cette partition et qui s'occupe de gérer les demandes d'écritures, les autres sont des followers.

Lors de l'insertion d'un nouveau record (d'une donnée), Kafka y ajoute des métadonnées (offset: numéro dans la file, temps, persistance, ...) et est ajouter à l'un des partitions du topic selon un pattern spécifié (algorithme basique de round robin ou trié selon la donnée).

Le fait que Kafka persiste les données et ajoute un offset n'oblige pas à travailler en temps réel (bien que Kafka soit aussi très adapté au temps réel) et permet aussi de pouvoir totalement rejouer les états d'une application grace à la sauvegarde de toutes les opérations.

== Garantie ==

Kafka permet une réplication configurable de toutes les données.

Kafka permet de prendre en compte la géo-localisation pour optimiser les temps d'accès.

Kafka garantie un ordre, c'est à dire que si un producteur P1 envoi un message M1 sur le topic T1 et qu'ensuite il envoit un message M2 sur le même topic, l'offset du message M1 sera strictement inférieur à celui du message M2.

==Références==

https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations

https://kafka.apache.org

https://github.com/apache/kafka/blob/2.1/streams/examples/src/main/java/org/apache/kafka/streams/examples/wordcount/WordCountDemo.java

http://confluent.io/product/

https://hackernoon.com/distributed-log-analytics-using-apache-kafka-kafka-connect-and-fluentd-303330e478af

VT2018 Kafka

2018-12-17T10:29:58Z

Timothee.Depriester: /* Références */

VT2018 Kafka

2018-12-17T10:28:26Z

Timothee.Depriester: /* APIs */

VT2018 Kafka

2018-12-17T10:27:18Z

Timothee.Depriester: /* Synthèse */

File:Kafka API 2018.png

2018-12-17T10:26:51Z

Timothee.Depriester:

VT2018 Kafka

2018-12-17T10:26:01Z

Timothee.Depriester: /* Synthèse */

VT2018 Kafka

2018-12-17T10:16:42Z

Timothee.Depriester:

File:VT2018 kafka presentation.pdf

2018-12-17T10:06:48Z

Timothee.Depriester:

VT2018

2018-12-17T10:06:33Z

Timothee.Depriester: /* Planning */

[[VT2017|<< Etudes 2017]] [[VT|Sommaire]] [[VT2019|Etudes 2019 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?

La présentation peut être réalisée avec [[reveal.js]]

[[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]

=Affectation des sujets=
[[File:AffectationSujetsVT2018.pdf]]

=Planning=
* Vendredi 7/9: présentation et choix des sujets
[[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* Lundi 12/11: (GPB,DD en visio)
** 1: Julien COURTIAL - Apollo 2.0, [[VT2018_Apollo|Fiche de synthèse]], [[Media:Apollo_Auto_Platform.pdf|Transparents]], [https://github.com/ApolloAuto/apollo/tree/master/docs/demo_guide Démo]
** 2: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]] (Reporté)
** 3: Servan CHARLOT - [[OpenWhisk]] : [[VT2018_OpenWhisk|Fiche de synthèse]], [[Media:VT2018_OpenWhisk_presentation.pdf|Transparents]], [[VT2018_OpenWhisk_Demo|Démo]]
** 4: Théo ECHEVET - Fabric8, [[VT2018_fabric8|Fiche de synthèse]], [[Media:Fabric8_Pres_Theo_Echevet.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 5: Bastien TERRIER - [[Performance_Monitoring|Performance Monitoring]], [[VT2018_Performance_Monitoring|Fiche de synthèse]], [[Media:VT2018_Performance_Monitoring_presentation.pdf|Transparents]], [[VT2018_Performance_Monitoring_Demo|Démo]]
* Lundi 19/11: (GPB,DD en visio)
** 6: Samuel BAMBA - DevSecOps, [[VT2018_DevSecOps|Fiche de synthèse]], [[Media:VT2018_DevSecOps.pdf|Transparents]], [https://github.com/CoolerVoid/codewarrior Démo]
** 7: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]] (reporté)
** 8: Thibaud VEGREVILLE, Techniques et technologies de "Lag Compensation" dans les jeux en ligne, [[VT2018_Lag_Compensation|Fiche de synthèse]], [[Media:Lag_Compensation_in_Games.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 9: Hugo GROS-DAILLON - [[ActionHero.js]], [[VT2018_ActionHero|Fiche de synthèse]], [[Media:VT2018ActionHero.pdf|Transparents]], [https://github.com/HugoSecteur4/DemoVT2018ActionHero/tree/master/ActionHero Démo]
** 10: Vincent AUBERT - Apache MXNet : Demo avec Intel Movidius, [[VT2018_Apache_Mxnet|Fiche de synthèse]], [[Media:VT2018_Mxnet_presentation.pdf|Transparents]], [[VT2018_Mxnet_Demo|Démo]]
* Lundi 10/12: (GPB+DD)
** 11: Joffrey FERREIRA - Keycloak, [[VT2018_Keycloak|Fiche de synthèse]], [[Media:VT2018_Keycloak_presentation.pdf|Transparents]], [[VT2018_Keycloak_Demo|Démo]]
** 12: Loris GENTILLON - Gceasy, [[VT2018_GCeasy-synthese|Fiche de synthèse]], [[Media:GCeasy_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 13: Thomas OZENDA - Zipkin et Daper, [[VT2018_Zipkin|Fiche de synthèse]], [[Media:VT2018_Zipkin_presentation.pdf|Transparents]], [[VT2018_Zipkin_Demo|Démo]]
** 14: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 15: Enzo MOLION - Web3j, [[VT2018_Web3j|Fiche de synthèse]], [[Media:Presentation_Web3j.pdf|Transparents]], [https://air.imag.fr/index.php/VT2018_Web3j#D.C3.A9monstration Démo]
* Lundi 17/12: (GPB)
** 16: Quentin FOMBRAON - Web Assembly, [[VT2018_WebAssembly|Fiche de synthèse]], [[Media:VT2018_WebAssembly_presentation.pdf|Transparents]], [[VT2018_WebAssembly|Démo]]
** 17: Timothée DEPRIESTER - Kafka Stream, [[VT2018_Kafka|Fiche de synthèse]], [[Media:VT2018_kafka_presentation.pdf|Transparents]], [[VT2018_kafka_Demo|Démo]]
** 18: Benjamin BESNIER - Apache Beam, [[VT2018_ApacheBeam|Fiche de synthèse]], [[Media:VT2018_ApacheBeam_presentation.pdf|Transparents]], [[VT2018_ApacheBeam#Demonstration|Démo]]
** 19: Théo LEVESQUE - OpenShift, [[VT2018_OpenShift|Fiche de synthèse]], [[Media:VT2018_OpenShift.pdf|Transparents]], [[VT2018_OpenShift#D.C3.A9monstration|Démo]]
** 20: William WEILL - CMS, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
* Lundi 07/01/2019: (GPB+DD)
** 21: Tim LEPAGE - Moby, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 22: Cédric LAFRASSE - SIG, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 23: Léo VALETTE - Architectures de processeurs pour le Deep Learning (NPU): Démo de l'Intel Movidius, , [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 24: Florian CUZIN - , [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 25: Raphael MANGER - Apache Solr, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
* Lundi 14/01/2019: (GPD, DD absent)
** 26: Amina BOUCHERIMA - Content delivery networks, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 27: Najwa EZ-ZINE - FIDO, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 28: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]]
** 29: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]]
** 30:

=Sujets non sélectionnés=
# [[Single Sign On]] : démonstration de [[Keycloak]] avec [[JHipster]].

# [[gVisor]]: a new kind of sandbox that helps provide secure isolation for containers

# Portails et l'API [[Portlet]] : Démo avec [[Liferay]]

# [[Hazelcast]] : Démo avec Spring Boot ([https://dzone.com/storage/assets/6459742-dzone-rc247-gettingstartedwithspringbootandmicrose.pdf lien]) dans un projet [[JHipster]]

# [[In-Memory Data Grids]] : Démonstration de [[Gigaspaces]] et [[XAP]] Open Source
# Insport Video
# Gestionnaires de contenu : démonstration de [[Apache Jackrabbit]] dans le projet [[eCOM]]
# [[Memory-centric virtual distributed storage system]]

# [[ESB]] : démonstration de [[Mule ESB]]
# [[MemCached]]

# [[Low-Power Global Area Network]]s ([[Sat-IoT]])

VT2018 XXX

2018-12-16T22:27:48Z

Timothee.Depriester: Replaced content with "=Auteur= *Nom : xxx *Sujet : xxx =Résumé= =Abstract= =Synthèse= ==Références=="

=Auteur=
*Nom : xxx
*Sujet : xxx

=Résumé=

=Abstract=

=Synthèse=

==Références==

VT2018 Kafka

2018-12-16T22:27:08Z

Timothee.Depriester: Created page with "=Auteur= *Nom : Timothée depriester *Sujet : Kafka =Résumé= Apache Kafka est une plateforme de streaming distribuée. Cette technologie permet de servir de tampon dans un..."

VT2018

2018-12-16T22:26:31Z

Timothee.Depriester: /* Planning */

[[VT2017|<< Etudes 2017]] [[VT|Sommaire]] [[VT2019|Etudes 2019 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en RICM5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?

La présentation peut être réalisée avec [[reveal.js]]

[[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]

=Affectation des sujets=
[[File:AffectationSujetsVT2018.pdf]]

=Planning=
* Vendredi 7/9: présentation et choix des sujets
[[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* Lundi 12/11: (GPB,DD en visio)
** 1: Julien COURTIAL - Apollo 2.0, [[VT2018_Apollo|Fiche de synthèse]], [[Media:Apollo_Auto_Platform.pdf|Transparents]], [https://github.com/ApolloAuto/apollo/tree/master/docs/demo_guide Démo]
** 2: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]] (Reporté)
** 3: Servan CHARLOT - [[OpenWhisk]] : [[VT2018_OpenWhisk|Fiche de synthèse]], [[Media:VT2018_OpenWhisk_presentation.pdf|Transparents]], [[VT2018_OpenWhisk_Demo|Démo]]
** 4: Théo ECHEVET - Fabric8, [[VT2018_fabric8|Fiche de synthèse]], [[Media:Fabric8_Pres_Theo_Echevet.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 5: Bastien TERRIER - [[Performance_Monitoring|Performance Monitoring]], [[VT2018_Performance_Monitoring|Fiche de synthèse]], [[Media:VT2018_Performance_Monitoring_presentation.pdf|Transparents]], [[VT2018_Performance_Monitoring_Demo|Démo]]
* Lundi 19/11: (GPB,DD en visio)
** 6: Samuel BAMBA - DevSecOps, [[VT2018_DevSecOps|Fiche de synthèse]], [[Media:VT2018_DevSecOps.pdf|Transparents]], [https://github.com/CoolerVoid/codewarrior Démo]
** 7: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]] (reporté)
** 8: Thibaud VEGREVILLE, Techniques et technologies de "Lag Compensation" dans les jeux en ligne, [[VT2018_Lag_Compensation|Fiche de synthèse]], [[Media:Lag_Compensation_in_Games.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 9: Hugo GROS-DAILLON - [[ActionHero.js]], [[VT2018_ActionHero|Fiche de synthèse]], [[Media:VT2018ActionHero.pdf|Transparents]], [https://github.com/HugoSecteur4/DemoVT2018ActionHero/tree/master/ActionHero Démo]
** 10: Vincent AUBERT - Apache MXNet : Demo avec Intel Movidius, [[VT2018_Apache_Mxnet|Fiche de synthèse]], [[Media:VT2018_Mxnet_presentation.pdf|Transparents]], [[VT2018_Mxnet_Demo|Démo]]
* Lundi 10/12: (GPB+DD)
** 11: Joffrey FERREIRA - Keycloak, [[VT2018_Keycloak|Fiche de synthèse]], [[Media:VT2018_Keycloak_presentation.pdf|Transparents]], [[VT2018_Keycloak_Demo|Démo]]
** 12: Loris GENTILLON - Gceasy, [[VT2018_GCeasy-synthese|Fiche de synthèse]], [[Media:GCeasy_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 13: Thomas OZENDA - Zipkin et Daper, [[VT2018_Zipkin|Fiche de synthèse]], [[Media:VT2018_Zipkin_presentation.pdf|Transparents]], [[VT2018_Zipkin_Demo|Démo]]
** 14: Aurélien SURIER - CloudFoundry, [[VT2018_CloudFoundry|Fiche de synthèse]], [[Media:VT2018_CloudFoundry_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 15: Enzo MOLION - Web3j, [[VT2018_Web3j|Fiche de synthèse]], [[Media:Presentation_Web3j.pdf|Transparents]], [https://air.imag.fr/index.php/VT2018_Web3j#D.C3.A9monstration Démo]
* Lundi 17/12: (GPB)
** 16: Quentin FOMBRAON - Web Assembly, [[VT2018_WebAssembly|Fiche de synthèse]], [[Media:VT2018_WebAssembly_presentation.pdf|Transparents]], [[VT2018_WebAssembly|Démo]]
** 17: Timothée DEPRIESTER - Kafka Stream, [[VT2018_Kafka|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 18: Benjamin BESNIER - Apache Beam, [[VT2018_ApacheBeam|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 19: Théo LEVESQUE - OpenShift, [[VT2018_OpenShift|Fiche de synthèse]], [[Media:VT2018_OpenShift.pdf|Transparents]], [[VT2018_OpenShift#D.C3.A9monstration|Démo]]
** 20: William WEILL - CMS, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
* Lundi 07/01/2019: (GPB+DD)
** 21: Tim LEPAGE - Moby, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 22: Cédric LAFRASSE - SIG, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 23: Léo VALETTE - Architectures de processeurs pour le Deep Learning (NPU): Démo de l'Intel Movidius, , [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 24: Florian CUZIN - , [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 25: Raphael MANGER - Apache Solr, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
* Lundi 14/01/2019: (GPD, DD absent)
** 26: Amina BOUCHERIMA - Content delivery networks, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 27: Najwa EZ-ZINE - FIDO, [[VT2018_XXX|Fiche de synthèse]], [[Media:VT2018_XXX_presentation.pdf|Transparents]], [[VT2018_XXX_Demo|Démo]]
** 28: Sekina BELGUENDOUZ - Service Mesh, [[VT2018_Service_Mesh|Fiche de synthèse]], [[Media:VT2018_Service_Mesh_presentation.pdf|Transparents]], [[VT2018_Service_Mesh_Demo|Démo avec Istrio]]
** 29: Zoran CHANET - [[Wildfly_Swarm|<strike>Wildfly Swarm</strike>]] [[Thorntail|Thorntail]], [[VT2018_Thorntail|Fiche de synthèse]], [[Media:VT2018_Thorntail_presentation.pdf|Transparents]], [[VT2018_Thorntail_Demo|Démo]]
** 30:

=Sujets non sélectionnés=
# [[Single Sign On]] : démonstration de [[Keycloak]] avec [[JHipster]].

# [[gVisor]]: a new kind of sandbox that helps provide secure isolation for containers

# Portails et l'API [[Portlet]] : Démo avec [[Liferay]]

# [[Hazelcast]] : Démo avec Spring Boot ([https://dzone.com/storage/assets/6459742-dzone-rc247-gettingstartedwithspringbootandmicrose.pdf lien]) dans un projet [[JHipster]]

# [[In-Memory Data Grids]] : Démonstration de [[Gigaspaces]] et [[XAP]] Open Source
# Insport Video
# Gestionnaires de contenu : démonstration de [[Apache Jackrabbit]] dans le projet [[eCOM]]
# [[Memory-centric virtual distributed storage system]]

# [[ESB]] : démonstration de [[Mule ESB]]
# [[MemCached]]

# [[Low-Power Global Area Network]]s ([[Sat-IoT]])

VT2018 XXX

2018-12-16T22:23:42Z

Timothee.Depriester: /* Abstract */

VT2018 XXX

2018-12-16T22:22:35Z

Timothee.Depriester: /* Résumé */

VT2018 XXX

2018-12-16T22:21:33Z

Timothee.Depriester: /* Abstract */

VT2018 XXX

2018-12-16T22:21:27Z

Timothee.Depriester: /* Résumé */

VT2018 XXX

2018-12-16T22:21:12Z

Timothee.Depriester:

VT2018 XXX

2018-12-16T22:15:46Z

Timothee.Depriester:

ECOM-1FO 1819 Camping

2018-12-14T10:33:57Z

Timothee.Depriester: /* How we use your information */

[[ECOM-1FO|<<<< Retour vers la page ECOM 2018-2019]]

PRIERE DE NE PAS UTILISER XXX COMME NOM DE PROJET DANS LES REFERENCES VERS LES DOCUMENTS

=Le projet en quelques mots=
L’objectif de notre projet E-com est de mettre en place un service en ligne (et une application mobile) permettant la location d'emplacement de camping de particulier à particulier.

=L'équipe et leurs rôles=

* Timothee Depriester : Chef de projet (+ Devops, Backend, Code review)
* Sekina Belguendouz : Scrum Master (+ Lead Developer, Frontend)
* Florian Cuzin : Développeur (Backend)
* Servan Charlot : Développeur (Backend, Code review, git)
* Samuel Bamba : Développeur (+ Frontend)

=Gestion de projet=
Choix des outils :

* ''Gitlab'' : pour le dépôt, pour la documentation, l'intégration en continu
* ''Trello'' : pour la répartition et la gestion des tâches hors code (rédaction de documents etc)

=SCRUM=
==Sprint 1 02/10 au 30/10==
* Découverte du projet
* Mise en place des rôles au sein de l’équipe
* Détermination des dates clés du projet
* Etablissement de la longueur des sprints

===Audit 1===
Le planning prévisionnel était un peu audacieux et n'a pas été respecté.
===Remarque===

V1.0 - Base de donnée et template du front end fonctionnels

==Sprint 2 XX au XX==

==Sprint 3 XX au XX==

= Livrables =
==L2. Dossier de conception système ==

[[File:ECOM-1FO_1819_PROJETXXXX_L2_DCS.pdf]]

==L3. Analyse des scénarios clients ==
* Scan des feuilles

==L4. Maquette==

<gallery>
File:ECOM2018-MC-Mobile Home.png
File:ECOM2018-MC-Mobile Home 2.png
File:ECOM2018-MC-Mobile Checkout.png
File:ECOM2018-MC-Mobile Anonce.png
File:ECOM2018-MC-Home 2.png
File:ECOM2018-MC-Home.png
File:ECOM2018-MC-Checkout.png
File:ECOM2018-MC-Anonce.png

</gallery>

==L5. SRS==
[[ECOM-1FO_1819_mycamping_L5_SRS|SRS]]

==L6. Diagrammes UML==
<gallery>
File:ECOM2018-MC-DDC.jpeg| Diagramme de contexte.
File:ECOM2018-MC-VL.png| Vue logique.
File:ECOM2018-MC-VD.png| Vue dynamique.
File:ECOM2018-MC-VP.png| Vue physique.
File:ECOM2018-MC-BDD.png| Base de données.
</gallery>

==L7. Modèles des tâches==
<gallery>
File:Modèle_de_Taches_Scénario_1MYCAMPING.jpg| Modèle de Taches 1
File:Modèle_de_Taches_Scénario_2MYCAMPING.jpg| Modèle de Taches 2
</gallery>

==L8. Scrum==

==L9. Journal==
[https://docs.google.com/document/d/1AkqKwr9z-VgLfGpc05VFVxMH07-DId45AICF0lewxgk/edit?usp=sharing Journal de l'équipe]

==L10. Dépôt Git==

[https://gitlab.com/ECOM-Mycamping/mycamping Lien vers les dépôts de l'organisation]

==L11. Application en ligne==

[https://mycamping.timotheedepriester.fr/ website]

[https://mycamping.timotheedepriester.fr/#/admin/docs API OpenAPI]

==L12. Evaluation IHM réalisée==

==L13. Evaluation qualité du projet==

* Rapports SonarQube

[https://sonarcloud.io/dashboard?id=edu.ecom.mycamping%3Amycamping Rapports]

==L14. Evaluation économique du projet==

===COCOMO===

===Evaluation économique du projet===
Vous pouvez utiliser les évaluations des salaires avec cette [https://stackoverflow.com/jobs/salary calculatrice] pour connaître les salaires des membres de l'équipe. (pensez à ajouter les charges).

==L15. Evaluation de la cybersécurité du projet (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_RGPD_Report.pdf]] (1 page de type checklist)

==L16. Evaluation des performances (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]] (résultat des injections de charge JMeter, Gatling, ...)

==L17. Gestion des risques (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L18. Slides de présentation conception==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L19. Slides de présentation finale==
*[[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L20. Auto-évaluation==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L21. Slides de présentation client==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L22. Privacy Policy==

===Personal information===

Here is a list of the information we collect about you:
* First Name
* Last Name
* Mail adress

Here is a list of the information we collect if you summit a campsite:
* Camping name (if any)
* Location
* Type of campsite
* Campiste number (if any)
* Campsite surface
* Campsite utilities
* Campsite rent price
* Campsite description

===How we collect information===

We collect information through forms on the website.

===How we use your information===

We use your first and last name to identidy you on the website. We use you mail adress to send you the invoice when you rent a campsite or when you need to reset your password.

If you create a campsite offer, those information can be used by the persons renting it to contact you.

The information relative to your campiste are visible on the website to help clients decide where they want to go.

===When we share your information===

We don't share you information with any partner.

===How we store you information===

We store your information in a secured database on our server.

We keep the information forever.

===About===

Contact: mycamping2018@google.com

ECOM-1FO 1819 Camping

2018-12-14T10:32:46Z

Timothee.Depriester: /* About */

[[ECOM-1FO|<<<< Retour vers la page ECOM 2018-2019]]

PRIERE DE NE PAS UTILISER XXX COMME NOM DE PROJET DANS LES REFERENCES VERS LES DOCUMENTS

=Le projet en quelques mots=
L’objectif de notre projet E-com est de mettre en place un service en ligne (et une application mobile) permettant la location d'emplacement de camping de particulier à particulier.

=L'équipe et leurs rôles=

* Timothee Depriester : Chef de projet (+ Devops, Backend, Code review)
* Sekina Belguendouz : Scrum Master (+ Lead Developer, Frontend)
* Florian Cuzin : Développeur (Backend)
* Servan Charlot : Développeur (Backend, Code review, git)
* Samuel Bamba : Développeur (+ Frontend)

=Gestion de projet=
Choix des outils :

* ''Gitlab'' : pour le dépôt, pour la documentation, l'intégration en continu
* ''Trello'' : pour la répartition et la gestion des tâches hors code (rédaction de documents etc)

=SCRUM=
==Sprint 1 02/10 au 30/10==
* Découverte du projet
* Mise en place des rôles au sein de l’équipe
* Détermination des dates clés du projet
* Etablissement de la longueur des sprints

===Audit 1===
Le planning prévisionnel était un peu audacieux et n'a pas été respecté.
===Remarque===

V1.0 - Base de donnée et template du front end fonctionnels

==Sprint 2 XX au XX==

==Sprint 3 XX au XX==

= Livrables =
==L2. Dossier de conception système ==

[[File:ECOM-1FO_1819_PROJETXXXX_L2_DCS.pdf]]

==L3. Analyse des scénarios clients ==
* Scan des feuilles

==L4. Maquette==

<gallery>
File:ECOM2018-MC-Mobile Home.png
File:ECOM2018-MC-Mobile Home 2.png
File:ECOM2018-MC-Mobile Checkout.png
File:ECOM2018-MC-Mobile Anonce.png
File:ECOM2018-MC-Home 2.png
File:ECOM2018-MC-Home.png
File:ECOM2018-MC-Checkout.png
File:ECOM2018-MC-Anonce.png

</gallery>

==L5. SRS==
[[ECOM-1FO_1819_mycamping_L5_SRS|SRS]]

==L6. Diagrammes UML==
<gallery>
File:ECOM2018-MC-DDC.jpeg| Diagramme de contexte.
File:ECOM2018-MC-VL.png| Vue logique.
File:ECOM2018-MC-VD.png| Vue dynamique.
File:ECOM2018-MC-VP.png| Vue physique.
File:ECOM2018-MC-BDD.png| Base de données.
</gallery>

==L7. Modèles des tâches==
<gallery>
File:Modèle_de_Taches_Scénario_1MYCAMPING.jpg| Modèle de Taches 1
File:Modèle_de_Taches_Scénario_2MYCAMPING.jpg| Modèle de Taches 2
</gallery>

==L8. Scrum==

==L9. Journal==
[https://docs.google.com/document/d/1AkqKwr9z-VgLfGpc05VFVxMH07-DId45AICF0lewxgk/edit?usp=sharing Journal de l'équipe]

==L10. Dépôt Git==

[https://gitlab.com/ECOM-Mycamping/mycamping Lien vers les dépôts de l'organisation]

==L11. Application en ligne==

[https://mycamping.timotheedepriester.fr/ website]

[https://mycamping.timotheedepriester.fr/#/admin/docs API OpenAPI]

==L12. Evaluation IHM réalisée==

==L13. Evaluation qualité du projet==

* Rapports SonarQube

[https://sonarcloud.io/dashboard?id=edu.ecom.mycamping%3Amycamping Rapports]

==L14. Evaluation économique du projet==

===COCOMO===

===Evaluation économique du projet===
Vous pouvez utiliser les évaluations des salaires avec cette [https://stackoverflow.com/jobs/salary calculatrice] pour connaître les salaires des membres de l'équipe. (pensez à ajouter les charges).

==L15. Evaluation de la cybersécurité du projet (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_RGPD_Report.pdf]] (1 page de type checklist)

==L16. Evaluation des performances (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]] (résultat des injections de charge JMeter, Gatling, ...)

==L17. Gestion des risques (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L18. Slides de présentation conception==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L19. Slides de présentation finale==
*[[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L20. Auto-évaluation==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L21. Slides de présentation client==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L22. Privacy Policy==

===Personal information===

Here is a list of the information we collect about you:
* First Name
* Last Name
* Mail adress

Here is a list of the information we collect if you summit a campsite:
* Camping name (if any)
* Location
* Type of campsite
* Campiste number (if any)
* Campsite surface
* Campsite utilities
* Campsite rent price
* Campsite description

===How we collect information===

We collect information through forms on the website.

===How we use your information===

We use your first and last name to identidy you on the website. We use you mail adress to send you the invoice when you rent a campsite.

If you create a campsite offer, those information can be used by the persons renting it to contact you.

The information relative to your campiste are visible on the website to help clients decide where they want to go.

===When we share your information===

We don't share you information with any partner.

===How we store you information===

We store your information in a secured database on our server.

We keep the information forever.

===About===

Contact: mycamping2018@google.com

File:ECOM2018-MC-Mobile Checkout.png

2018-12-14T10:30:18Z

Timothee.Depriester:

ECOM-1FO 1819 Camping

2018-12-14T10:29:37Z

Timothee.Depriester:

[[ECOM-1FO|<<<< Retour vers la page ECOM 2018-2019]]

PRIERE DE NE PAS UTILISER XXX COMME NOM DE PROJET DANS LES REFERENCES VERS LES DOCUMENTS

=Le projet en quelques mots=
L’objectif de notre projet E-com est de mettre en place un service en ligne (et une application mobile) permettant la location d'emplacement de camping de particulier à particulier.

=L'équipe et leurs rôles=

* Timothee Depriester : Chef de projet (+ Devops, Backend, Code review)
* Sekina Belguendouz : Scrum Master (+ Lead Developer, Frontend)
* Florian Cuzin : Développeur (Backend)
* Servan Charlot : Développeur (Backend, Code review, git)
* Samuel Bamba : Développeur (+ Frontend)

=Gestion de projet=
Choix des outils :

* ''Gitlab'' : pour le dépôt, pour la documentation, l'intégration en continu
* ''Trello'' : pour la répartition et la gestion des tâches hors code (rédaction de documents etc)

=SCRUM=
==Sprint 1 02/10 au 30/10==
* Découverte du projet
* Mise en place des rôles au sein de l’équipe
* Détermination des dates clés du projet
* Etablissement de la longueur des sprints

===Audit 1===
Le planning prévisionnel était un peu audacieux et n'a pas été respecté.
===Remarque===

V1.0 - Base de donnée et template du front end fonctionnels

==Sprint 2 XX au XX==

==Sprint 3 XX au XX==

= Livrables =
==L2. Dossier de conception système ==

[[File:ECOM-1FO_1819_PROJETXXXX_L2_DCS.pdf]]

==L3. Analyse des scénarios clients ==
* Scan des feuilles

==L4. Maquette==

<gallery>
File:ECOM2018-MC-Mobile Home.png
File:ECOM2018-MC-Mobile Home 2.png
File:ECOM2018-MC-Mobile Checkout.png
File:ECOM2018-MC-Mobile Anonce.png
File:ECOM2018-MC-Home 2.png
File:ECOM2018-MC-Home.png
File:ECOM2018-MC-Checkout.png
File:ECOM2018-MC-Anonce.png

</gallery>

==L5. SRS==
[[ECOM-1FO_1819_mycamping_L5_SRS|SRS]]

==L6. Diagrammes UML==
<gallery>
File:ECOM2018-MC-DDC.jpeg| Diagramme de contexte.
File:ECOM2018-MC-VL.png| Vue logique.
File:ECOM2018-MC-VD.png| Vue dynamique.
File:ECOM2018-MC-VP.png| Vue physique.
File:ECOM2018-MC-BDD.png| Base de données.
</gallery>

==L7. Modèles des tâches==
<gallery>
File:Modèle_de_Taches_Scénario_1MYCAMPING.jpg| Modèle de Taches 1
File:Modèle_de_Taches_Scénario_2MYCAMPING.jpg| Modèle de Taches 2
</gallery>

==L8. Scrum==

==L9. Journal==
[https://docs.google.com/document/d/1AkqKwr9z-VgLfGpc05VFVxMH07-DId45AICF0lewxgk/edit?usp=sharing Journal de l'équipe]

==L10. Dépôt Git==

[https://gitlab.com/ECOM-Mycamping/mycamping Lien vers les dépôts de l'organisation]

==L11. Application en ligne==

[https://mycamping.timotheedepriester.fr/ website]

[https://mycamping.timotheedepriester.fr/#/admin/docs API OpenAPI]

==L12. Evaluation IHM réalisée==

==L13. Evaluation qualité du projet==

* Rapports SonarQube

[https://sonarcloud.io/dashboard?id=edu.ecom.mycamping%3Amycamping Rapports]

==L14. Evaluation économique du projet==

===COCOMO===

===Evaluation économique du projet===
Vous pouvez utiliser les évaluations des salaires avec cette [https://stackoverflow.com/jobs/salary calculatrice] pour connaître les salaires des membres de l'équipe. (pensez à ajouter les charges).

==L15. Evaluation de la cybersécurité du projet (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_RGPD_Report.pdf]] (1 page de type checklist)

==L16. Evaluation des performances (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]] (résultat des injections de charge JMeter, Gatling, ...)

==L17. Gestion des risques (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L18. Slides de présentation conception==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L19. Slides de présentation finale==
*[[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L20. Auto-évaluation==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L21. Slides de présentation client==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L22. Privacy Policy==

===Personal information===

Here is a list of the information we collect about you:
* First Name
* Last Name
* Mail adress

Here is a list of the information we collect if you summit a campsite:
* Camping name (if any)
* Location
* Type of campsite
* Campiste number (if any)
* Campsite surface
* Campsite utilities
* Campsite rent price
* Campsite description

===How we collect information===

We collect information through forms on the website.

===How we use your information===

We use your first and last name to identidy you on the website. We use you mail adress to send you the invoice when you rent a campsite.

If you create a campsite offer, those information can be used by the persons renting it to contact you.

The information relative to your campiste are visible on the website to help clients decide where they want to go.

===When we share your information===

We don't share you information with any partner.

===How we store you information===

We store your information in a secured database on our server.

We keep the information forever.

===About===

Contact: mycamping2018@google.fr

ECOM-1FO 1819 Camping

2018-12-14T10:28:42Z

Timothee.Depriester:

[[ECOM-1FO|<<<< Retour vers la page ECOM 2018-2019]]

PRIERE DE NE PAS UTILISER XXX COMME NOM DE PROJET DANS LES REFERENCES VERS LES DOCUMENTS

=Le projet en quelques mots=
L’objectif de notre projet E-com est de mettre en place un service en ligne (et une application mobile) permettant la location d'emplacement de camping de particulier à particulier.

=L'équipe et leurs rôles=

* Timothee Depriester : Chef de projet (+ Devops, Backend, Code review)
* Sekina Belguendouz : Scrum Master (+ Lead Developer, Frontend)
* Florian Cuzin : Développeur (Backend)
* Servan Charlot : Développeur (Backend, Code review, git)
* Samuel Bamba : Développeur (+ Frontend)

=Gestion de projet=
Choix des outils :

* ''Gitlab'' : pour le dépôt, pour la documentation, l'intégration en continu
* ''Trello'' : pour la répartition et la gestion des tâches hors code (rédaction de documents etc)

=SCRUM=
==Sprint 1 02/10 au 30/10==
* Découverte du projet
* Mise en place des rôles au sein de l’équipe
* Détermination des dates clés du projet
* Etablissement de la longueur des sprints

===Audit 1===
Le planning prévisionnel était un peu audacieux et n'a pas été respecté.
===Remarque===

V1.0 - Base de donnée et template du front end fonctionnels

==Sprint 2 XX au XX==

==Sprint 3 XX au XX==

= Livrables =
==L2. Dossier de conception système ==

[[File:ECOM-1FO_1819_PROJETXXXX_L2_DCS.pdf]]

==L3. Analyse des scénarios clients ==
* Scan des feuilles

==L4. Maquette==

<gallery>
File:ECOM2018-MC-Mobile Home.png
File:ECOM2018-MC-Mobile Home2.png
File:ECOM2018-MC-Mobile Checkout.png
File:ECOM2018-MC-Mobile Anonce.png
File:ECOM2018-MC-Home 2.png
File:ECOM2018-MC-Home.png
File:ECOM2018-MC-Checkout.png
File:ECOM2018-MC-Anonce.png

</gallery>

==L5. SRS==
[[ECOM-1FO_1819_mycamping_L5_SRS|SRS]]

==L6. Diagrammes UML==
<gallery>
File:ECOM2018-MC-DDC.jpeg| Diagramme de contexte.
File:ECOM2018-MC-VL.png| Vue logique.
File:ECOM2018-MC-VD.png| Vue dynamique.
File:ECOM2018-MC-VP.png| Vue physique.
File:ECOM2018-MC-BDD.png| Base de données.
</gallery>

==L7. Modèles des tâches==
<gallery>
File:Modèle_de_Taches_Scénario_1MYCAMPING.jpg| Modèle de Taches 1
File:Modèle_de_Taches_Scénario_2MYCAMPING.jpg| Modèle de Taches 2
</gallery>

==L8. Scrum==

==L9. Journal==
[https://docs.google.com/document/d/1AkqKwr9z-VgLfGpc05VFVxMH07-DId45AICF0lewxgk/edit?usp=sharing Journal de l'équipe]

==L10. Dépôt Git==

[https://gitlab.com/ECOM-Mycamping/mycamping Lien vers les dépôts de l'organisation]

==L11. Application en ligne==

[https://mycamping.timotheedepriester.fr/ website]

[https://mycamping.timotheedepriester.fr/#/admin/docs API OpenAPI]

==L12. Evaluation IHM réalisée==

==L13. Evaluation qualité du projet==

* Rapports SonarQube

[https://sonarcloud.io/dashboard?id=edu.ecom.mycamping%3Amycamping Rapports]

==L14. Evaluation économique du projet==

===COCOMO===

===Evaluation économique du projet===
Vous pouvez utiliser les évaluations des salaires avec cette [https://stackoverflow.com/jobs/salary calculatrice] pour connaître les salaires des membres de l'équipe. (pensez à ajouter les charges).

==L15. Evaluation de la cybersécurité du projet (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_RGPD_Report.pdf]] (1 page de type checklist)

==L16. Evaluation des performances (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]] (résultat des injections de charge JMeter, Gatling, ...)

==L17. Gestion des risques (option)==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L18. Slides de présentation conception==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L19. Slides de présentation finale==
*[[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L20. Auto-évaluation==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L21. Slides de présentation client==
* [[Media:ECOM-1FO_1819_PROJETXXXX_YYYYYY.pdf]]

==L22. Privacy Policy==

===Personal information===

Here is a list of the information we collect about you:
* First Name
* Last Name
* Mail adress

Here is a list of the information we collect if you summit a campsite:
* Camping name (if any)
* Location
* Type of campsite
* Campiste number (if any)
* Campsite surface
* Campsite utilities
* Campsite rent price
* Campsite description

===How we collect information===

We collect information through forms on the website.

===How we use your information===

We use your first and last name to identidy you on the website. We use you mail adress to send you the invoice when you rent a campsite.

If you create a campsite offer, those information can be used by the persons renting it to contact you.

The information relative to your campiste are visible on the website to help clients decide where they want to go.

===When we share your information===

We don't share you information with any partner.

===How we store you information===

We store your information in a secured database on our server.

We keep the information forever.

===About===

Contact: mycamping2018@google.fr

File:ECOM2018-MC-Mobile Home.png

2018-12-14T10:24:27Z

Timothee.Depriester:

File:ECOM2018-MC-Mobile Home 2.png

2018-12-14T10:24:15Z

Timothee.Depriester:

File:ECOM2018-MC-Mobile Anonce.png

2018-12-14T10:24:01Z

Timothee.Depriester:

File:ECOM2018-MC-Home 2.png

2018-12-14T10:23:44Z

Timothee.Depriester:

File:ECOM2018-MC-Home.png

2018-12-14T10:23:31Z

Timothee.Depriester:

File:ECOM2018-MC-Anonce.png

2018-12-14T10:22:46Z

Timothee.Depriester: