Add several links

readme.md

@@ -92,29 +92,29 @@ Lorsqu’il le souhaite (par exemple lorsqu’il est de retour à la maison), le
 
 ## Notes techniques
 
-Ce travail assez simple (le cahier des charges décrit en détail le contexte et des scénarios d’utilisation pour vous aider à sentir les besoins, mais les fonctionnalités sont basiques et peu nombreuses. La modélisation de la DB est simple également) propose des occasions d’enrichissement des interfaces. Vous devez créer un produit qui respecte les règles habituelles de l’accessiblité et peut donc fonctionner sans JS mais il est _impératif_ d’enrichir ensuite l’interface pour qu’elle propose une expérience moderne et confortable. En plus, elle doit être utilisable sur tout device (téléphone, tablette, desktop) que le membre du jury ou le professeur jugera utile d’utiliser.
+Ce travail assez simple (le cahier des charges décrit en détail le contexte et des scénarios d’utilisation pour vous aider à sentir les besoins, mais les fonctionnalités sont basiques et peu nombreuses. La modélisation de la DB est simple également, même si il y a quelques relations) propose des occasions d’enrichissement des interfaces. Vous devez créer un produit qui respecte les règles habituelles de l’accessiblité et peut donc fonctionner sans JS mais il est _impératif_ d’enrichir ensuite l’interface pour qu’elle propose une expérience moderne et confortable. En plus, elle doit être utilisable sur tout device (téléphone, tablette, desktop) que le membre du jury ou le professeur jugera utile d’utiliser.
 
 Il y a beaucoup de formulaires dans cette application. Efforcez-vous de les rendre séduisants, qu’ils fassent oublier qu’ils sont des formulaires d’encodage mais sans casser non plus l’affordance. Tout est dans l’équilibre.
 
 Le backend doit être implémenté à l’aide d’une architecture MVC existante. Vous êtes libres de choisir celle qui vous convient mais pour des raisons contingentes à l’infrastructure scolaire, elle doit être basée sur le langage PHP et la base de données Mysql. [Laravel](http://www.laravel.com) ou [Lumen](https://lumen.laravel.com/docs/5.4) s’imposent donc assez naturellement.
 
-_Idéalement_, un modèle de développement qui abstrait l’accès aux données et permet de les consommer avec des clients variés est souhaitable. Une API, REST idéalement, serait donc un vrai plus. Ne pas la faire ne sera pas une cause d’échec, mais la faire vous amènera un bon bonus. En tout état de cause, vous pouvez aussi partir sur l’idée que vous faites une application Web _normale_, ce n’est pas une cause de pénalisation.
+_Idéalement_, un modèle de développement qui abstrait l’accès aux données et permet de les consommer avec des clients variés est souhaitable. Une API, [REST](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) idéalement, serait donc un vrai plus. Ne pas la faire ne sera pas une cause d’échec, mais la faire vous amènera un bon bonus. En tout état de cause, vous pouvez aussi partir sur l’idée que vous faites une application Web _normale_, ce n’est pas une cause de pénalisation.
 
-Si vous choisissez de faire une API REST, n’oubliez pas qu’elle doit être stateless, donc que nous ne pouvez pas compter sur de la persistance côté serveur et que donc, vous devez renvoyer systématiquement des informations qui identifient le contexte de votre requête, comme par exemple, l’identifiant de l’événement _jury_ en cours.
+Si vous choisissez de faire une API REST, n’oubliez pas qu’elle doit être [stateless](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3), donc que nous ne pouvez pas compter sur de la persistance côté serveur et que donc, vous devez renvoyer systématiquement des informations qui identifient le contexte de votre requête, comme par exemple, l’identifiant de l’événement _jury_ en cours.
 
-Dans les fichiers associés à ce repo, j’ai introduit un exemple de ce type d’architecture. Une route Web dispatche une requête vers une route d’API pour récupérer les infos d’un événements, en y incluant les étudiants concernés et la cote finale manuelle obtenue (une occasion aussi de voir un cas d’eager loading).
+Dans les fichiers associés à ce repo, j’ai introduit un exemple de ce type d’architecture. [Une route Web dispatche une requête vers une route d’API](https://github.com/hepl-pw/jiri/blob/master/files/app/Http/Controllers/DashboardController.php#L12) pour récupérer les infos d’un événement, en y incluant les étudiants concernés et la cote finale manuelle obtenue (une occasion aussi de voir un cas d’[eager loading](https://laravel.com/docs/5.4/eloquent-relationships#eager-loading)).
 
 Dernier point, basique mais important, le(s) client(s) doi(ven)t pouvoir fonctionner sans JS, mais ne pas enrichir l’expérience de JS sera une cause de malus.
 
 ### Aides
 
 Pour vous aider à démarrer et vous permettre de vous concentrer le plus vite possible sur le client et son interface, un travail de modélisation de la db a été réalisé. Vous pouvez naturellement modifier tout ce qui vous semble utile pour coller au cahier des charges, ou encore utiliser un autre type de base de données, mais sinon, vous avez déjà quelque chose. Il est possible qu’il reste des champs mal défini. D’avance, je m’en excuse, il n’y a pas de piège, mais on ne termine vraiment les choses qu’en les faisant jusqu’au bout. J’ai déjà mené quelques tests concluants avec ce modèle, mais il peut recevoir des améliorations ou des simplifications.
 
-Vous trouverez sur Laravel Schema Designer [une représentation graphique du modèle](http://www.laravelsd.com/share/Tbwhdr). Vous pouvez la forker dans votre compte et repartir de là pour la modifier ou voir les meta informations associées aux tables (les relations par exemple). LaravelSD permet d’exporter des migrations, des modèles, des controleurs, des formulaires, des fichiers de seed. On rencontre vite des limites à les utiliser tels quels, mais ça peut servir de base. En tout état de cause, vous trouverez dans ce repo des modèles avec un certain nombre de relations (je crois, mais de nouveau, je peux me tromper, qu’elles fonctionnent toutes. Cependant, pour rencontrer complètement le cahier de charges, vous devrez certainement enrichir le modèle et retourner certaines relations personnalisées ou encore transformer certaines valeurs), des fichiers de migration et des fichiers de seed. Vous pouvez donc créer votre db en une seule commande artisan, ce qui vous fera gagner beaucoup de temps.
+Vous trouverez sur Laravel Schema Designer [une représentation graphique du modèle](http://www.laravelsd.com/share/Tbwhdr). Vous pouvez la forker dans votre compte et repartir de là pour la modifier ou voir les meta informations associées aux tables (les relations par exemple). LaravelSD permet d’exporter des [migrations](https://laravel.com/docs/5.4/migrations), des [modèles](https://laravel.com/docs/5.4/eloquent), des [controleurs](https://laravel.com/docs/5.4/controllers), des formulaires, des fichiers de [seed](https://laravel.com/docs/5.4/seeding). On rencontre vite des limites à les utiliser tels quels, mais ça peut servir de base. En tout état de cause, vous trouverez dans ce repo des modèles avec un certain nombre de [relations](https://laravel.com/docs/5.4/eloquent-relationships) (je crois, mais de nouveau, je peux me tromper, qu’elles fonctionnent toutes. Cependant, pour rencontrer complètement le cahier de charges, vous devrez  enrichir les modèles et retourner certaines relations personnalisées ou encore transformer certaines valeurs), des fichiers de migration et des fichiers de seed. Vous pouvez donc créer votre db en une seule commande [artisan](https://laravel.com/docs/5.4/artisan), ce qui vous fera gagner beaucoup de temps.
 
 #### Avertissement sur la base de données
 
-Laravel est fondé sur un grand nombre de conventions. Par exemple, les tables pivots sont normalement nommées en combinant avec un underscore le nom des tables qu’elles unissent, au singulier, et dans l’ordre alphabétique. Ceci présente l’avantage de permettre d’écrire moins de code. Pour ma part, je préfère que mes relations portent le nom de ce que fait la relation. Ainsi, je peux y associer un modèle dont le nom va faire sens dans une API Rest. Voici donc le détail des tables :
+Laravel est fondé sur un grand nombre de conventions. Par exemple, les tables pivots sont normalement nommées en combinant avec un underscore le nom des tables qu’elles unissent, au singulier, et dans l’ordre alphabétique. Ceci présente l’avantage de permettre d’écrire moins de code. Pour ma part, je préfère que mes relations portent le nom de ce que fait la relation. Ainsi, je peux y associer un modèle dont le nom va faire sens dans une API REST. Voici donc le détail des tables :
 
 - `events` liste les événements de type jury. Par exemple, _le jury de Design Web de 2e en juin pour 2016 - 2017_ ou _le jury de Projets Web de 3e en septembre pour 2016 - 2017._ Une clé étrangère, `user_id`, permet de savoir qui est le créateur/propriétaire de l’événement en question ;
 - `users` liste les utilisateurs du système, donc les profs et les membres du jury. Les profs ont une valeur 1 pour la colonne `is_admin`, les membres, une valeur 0. Grâce au système des `gates` et `policies` de Laravel, vous pourrez très facilement gérer les droits de vos utilisateurs selon la valeur de ce flag ;