Je suis un peu partagé sur ce point et je voudrais recueillir certains avis sur le sujet. Pour la partie front vous l'avez vu au travers des différents live je compte utiliser le principe des Custom Element afin d'avoir des éléments réutilisable et compatible. La pluspart de ces Custom Element ont une logique assez simple qu'il est possible d'écrire en JavaScript pur. Cependant certains composants sont un peu plus complexes (je pense au composant commentaire, qui doit gérer l'affichage imbriqué des commentaires et gérer aussi le traitement du formulaire) et je ne pense pas qu'il soit judicieux de se passer de l'utilisation d'un framework pour ce besoin là.

Maintenant la question se pose sur le choix du framework sachant que :

• Le framework doit être léger en perf et en poid cas il ne sera utilisé que par petite touches.
• Le framework doit s'intégrer au code actuel avec un minimum d'effort en terme d'outils.
• Le framework doit disposer d'une documentation convenable.

Par rapport à ces critères j'ai 2 candidats potentiel (mais je suis ouvert aux propositions)

Svelte

Svelte a un poid léger et une approche assez simple avec des fonctions d'animations qui peuvent être utile pour certains besoins. Cependant la syntaxe est un peu étrange et son approche de la réactivité peut parfois amener à devoir écire des choses étranges pour qu'il capture bien les changements.

arr.push('lol') // Ne délenche rien
arr = arr // déclenche les changements

Aussi je trouve que le code peut rapidement être fouilli car il n'est pas forcément possible de morceler un composant sans créer des sous composants (donc un fichier séparé).

Preact

Preact est une version "light" de react et utilise la syntaxe JSX beaucoup plus familière. Cela donne parfois un code plus verbeux et le VDom ne facilité pas la création d'animations de base (il faut rapidement créer des composants en plus pour gérer ça). L'autre inconvénient est que le vdom rajoute une étape supplémentaire au niveau du navigateur ce qui peut avoir un impact négatif sur les performances (le traitement de l'arbre occupe de la mémoire et l'algo de diffing peut couter au CPU).
Mais l'avantage est qu'il permet de créer des fonctions pour certaines parties du code

function monIcon () {  return <svg ....> }

Je pense personnellement aussi que la syntaxe sera plus familière aux personnes qui souhaite intervenir sur le code. L'autre avantage est que l'on peut imaginer changer de framework plus facilement tant que le nouveau framework support le JSX.

Ma position

Pour le moment mon coeur balance. D'un point de vue utilisateur j'aurais tendance à partir sur Svelte, mais d'un point de vu dev j'aurais tendance à partir sur preact :(

Le message initial sur un forum est compté comme une réponse.

ex on voit "2 réponses" mais 1 seule visible :

D'ailleurs le nombre n'est pas incrémenté après avoir posté une réponse. (Mais au rechargement de la page oui)

L'utilisateur est accessible depuis le token, il n'est donc pas nécessaire de le passer ici. De même, l'evenement devrait être renommé PasswordResetTokenCreatedEvent

ERROR: manifest for typesense/typesense:0.12.0-rc2 not found: manifest unknown: manifest unknown

Pas de soucis avec la 0.13.0

J'ai commencé à travailler un peu sur la partie front et je m'interroge sur le choix du langage

Pourquoi Typescript ?

Permet de mieux organiser le code et d'avoir une vérification statique du code. Le problème est qu'en contrepartie je trouve que le code peut devenir moins lisible avec des cas où le type doit être forcé.

https://github.com/Grafikart/Grafikart.fr/blob/master/assets/js/elements/RecapLiveElement.ts

Aussi, le typescript semble sur certains point s'écarter du JavaScript classique (private / public, décorateur...) et il y a un risque de breaking change qui oblige plus tard à repenser le code :( .

Pourquoi pas ?

Si on retire typescript on retire aussi un outil nécessaire à la compilation du code. On peut aussi imaginer que dans un avenir le support des modules et des outils comme https://www.snowpack.dev/ permettront de ne plus avoir aucune étape de compilation.

Il faudra alors utiliser des commentaires (jsdoc) pour spécifier le typage. Mais je ne suis pas sûr qu'il existe un outil capable d'analyser le code par ce biais là.

Problématique

Un méchant hacker peut trouver le mot de passe d'un utilisateur en essayant de se connecter avec différents mots de passe

Solution

On mémorise les tentatives de connexion échouées de l'utilisateur

• Si l'utilisateur a plus de 3 échecs dans les 10 dernières minutes, il ne peut pas se connecter
• Au bout du 3ème échec un email est envoyé et permet de débloquer le compte

Bonjour @Grafikart

Je ne sais pas si c'est déjà le cas mais je suggère l'utilisation d'Elasticsearch pour le search & filters.

Il me semble que dans une de tes videos tu expliquais avoir du mal a faire ressortir les formations qui sont les plus récentes.
L’idée serait de booster le score des résultats en fonction de leur date de creation. Voici un topic stackoverflow qui parle du sujet:
https://discuss.elastic.co/t/how-to-prioritize-more-recent-content/134100/2

Bonjour,

Un utilisateur, non admin, ne peut pas éditer son message dans Forum. Une erreur HTTP 403 sera affiché.

Exemple :

 curl --request PUT \
  --url http://grafikart.localhost:8000/api/forum/messages/87 \
  --header 'content-type: application/json' \
  --header 'cookie: PHPSESSID=c86fa75cd214236b74c6c79cb27f8834' \
  --cookie PHPSESSID=c86fa75cd214236b74c6c79cb27f8834 \
  --data '{
	"content": "content message UPDATED"
}'

Je ne sais pas trop comment formulé ça et je me doute que ça va ajouter, un peu de complexité. Mais l'idée serait en deux ou trois mots que dès l'inscription l'on puisse choisir son type de profil. J'en vois 2 qui me viennent à l'esprit pour le moment :

• Profil simple consommateur
• Profil étudiant/pro/Spécifique orienté sur une techno ou objectif particulier

Le premier c'est un compte normal tout ce qu'il y a de plus classique.
Le second, l'inscription serait un poil plus longue et on aurait différents choix pour ensuite être mieux orienté sur le site avec des mises en avant des contenus qui correspondent à nos attentes.
Par exemple on pourrait imaginer un objectif "simple" : Je souhaite être capable de créer un site web et l’héberger par moi même.
De là ensuite sur la homepage (qui serait plus en fait une page perso) on aurait une sorte d'arbre de tutos/formations à suivre pour arriver à cet objectif.
Le but n'étant pas de faire quelque chose d'ultra poussé mais de répondre dès l'inscription à l'une des problématiques citées dans ton README sur les problèmes d'organisation / d'UX.

C'est un peu fichu en vrac comme ça et c'est assez mal construit dans mon esprit mais ça peut donner une base à d'autre idée qui iraient dans ce sens.

Lorsqu'on lance la commande make import, on obtient cette erreur:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'grafikart_dev.forum_forums' doesn't exist

Dans le forum importer, c'est la ligne 28, qui pose problème:
// On importe les tags $query = $this->pdo->prepare(<<<SQL SELECT * FROM forum_forums SQL);

visiblement, la table forum_forums n'existe pas !

La question se posera au moment du développement mais pour le moment j'hésite entre Laravel / Symfony et Rails.

Ruby on Rails

J'aime le langage et je trouve que le framework permet d'avancer rapidement et offre de bons outils. En revanche, le code peut rapidement être difficile à parcourir à cause du méta-programming qui est fréquent dans le framework et pas sûr que tout le monde soit en mesure de participer dans ce choix technique.

Avantages

• Tests unitaires avec rspec
• Code facile à lire et à écrire
• Moteur de template slim

Inconvénients

• Performance à surveiller
• L'ORM qui engendre des "fat model"
• Je n'ai pas autant d'expérience qu'avec PHP
• Absence de typage
• Le meta programming est à double tranchant

Symfony

J'aime bien l'approche Data Mapper de l'ORM Doctrine fournit dans le framework mais il a de nombreuses limitations qui bloquent assez rapidement (relation polymorphique, hydratation des liaisons pas forcément évidente...) du coup j'ai peur de perdre un temps considérable sur cette partie là.

Avantages

• Facile de trouver des personnes pour collaborer
• Code bien séparé au niveau de la couche base de données par défaut
• Moteur de template Twig

Inconvénients

• Code en général plus long qu'avez les autres frameworks
• L'ORM risque d'être limitant rapidement

Laravel

J'aime bien le code (un peu comme pour rails) mais d'expérience le code devient rapidement difficile à gérer au niveau des Model qui finissent pas englober pas mal de logique (relation, persistance, mutateurs...).

Avantages

• Code facile à écrire / lire
• L'ORM contient les fonctions nécessaire au site

Inconvénients

• L'ORM qui engendre des "fat model"
• Il faudra penser à éviter d'utiliser les façades
• Les mises à jours peuvent être difficiles

Le reste ?

Evidemment il existe d'autres frameworks / langage mais je préfère rester sur qqchose que je maitrise pour créer un code propre ce coup ci ;)

Avant de choisir un type de base de données on va réfléchir à la structure de la base de données. Dans cette conception on ne prends pas en compte le framework qui sera utilisé, on se focalise sur la structure qui permettra une bonne structure et de bonnes performances.

Voila un premier jet :

• 21/10/2019
• 22/10/2019 Ajout de la table login attempt et simplification des commentaires

Le gros changement par rapport à ma structure actuelle est l'utilisation d'une table "Content" qui permet de représenter un contenu et d'éviter les relations polymorphiques.

Questions :

• Est-ce qu'on sépare l'historique du visionnage et la watchlist (à regarder plus tard). Sur cette version j'utilise un booléen "watched" car je pense qu'un contenu ne peut être à la fois vu et à regarder plus tard.
• Les notifications vont être un problème (relation polymorphique)
• Est-ce qu'on laisse les commentaire sans compte utilisateur ?

Erreur Ajax dans l'ajout de commentaire

curl -X POST "http://localhost:8000/api/comments" -H  "accept: application/json" -H  "Content-Type: application/json" -d "{\"username\":\"user_fake\",\"content\":\"loremipsum\",\"target\":\"80\",\"email\":\"[email protected]\",\"parent\":null}"

target doit être numérique.

Uncaught PHP Exception ApiPlatform\Core\Exception\InvalidArgumentException: "The type of the "target" attribute must be "int", "string" given." at /var/www/vendor/api-platform/core/src/Serializer/AbstractItemNormalizer.php line 373

Bonjour,

Il y a un comportement bizarre avec les fixtures qui font planter les tests!
Quand on lance cette fixtures on est censé avoir 5 lignes en base de données mais pas 15

// tests/fixtures/comments.yaml:10
App\Domain\Comment\Comment:
  comment{1..5} (extends comment):

mêmes choses comment{1..10} ajoute 110 ligne etc (les deux points sont ignorées)...

D'où le fail des tests U.

vendor/bin/phpunit --filter test* tests/Domain/Comment/CommentTest.php
1) App\Tests\Domain\Comment\CommentTest::testCascadeDeleteForUser
Failed asserting that 2 matches expected 3.

/var/www/tests/Domain/Comment/CommentTest.php:55

j'ai fait tourné deux outils d'analyse d'analyse disponible gratuitement pour des repositories open-source: sonarcloud.io et scrutinizer-ci.

Les résultats sont disponibles publiquement:

• https://scrutinizer-ci.com/g/Mcdostone/Grafikart.fr/
• https://sonarcloud.io/project/issues?id=Mcdostone_Grafikart.fr

Leurs mises en place est très simple. J'ai regardé en diagonale les résultats, ceux de scrutinizer-ci me paraissent plus intéressants.

Pourquoi mettre toute la logique dans src/domain voir meme les entités ?
A quoi servira le dossier natif Entity (même celui des repository) ?

Merci

Il y a des problèmes d'accessibilités au niveau des couleurs.

Par exemple pour le main menu:
https://color.review/check/5F6461-252827

Pour les cards aussi avec le nombre de videos et longueur de video.
https://color.review/check/919191-F9F9F9

Ca doit être pareil pour les badges "facile", "difficile", etc.

je propose cette license :

Attribution-NonCommercial-ShareAlike 4.0 International

You are free to:

• Share — copy and redistribute the material in any medium or format
• Adapt — remix, transform, and build upon the material

under the following terms :

• Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

• NonCommercial — You may not use the material for commercial purposes.

• ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

• No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.

Pas vraiment un problème, mais il serait peut-être mieux que les slides prennent toute la largeur non ?
Par ex : https://beta.grafikart.fr/tutoriels/css-in-js-1363

Et j'ai l'impression qu'au niveau du responsive ça casse un peu ;)

Voici une liste non exhaustive de badge à mettre en place (ou pas).
Tout le monde peut amener ces idées, plus on est de fous moins y a de riz !

• "Usurpateur" : si on va sur la page premium?success=1 sans avoir procédé au paiement
• "Poisson rouge" : si on effecture plus de X (3?) fois la même recherche sur le site
• "Inception" : si on recherche Grafikart sur le site Grafikart
• "source anonyme/indic" : lorsque l'on remonte un bug/spam/faute de typo/... à grand manitou Grafikart
• "Contributeur" : Si on est contributeur sur Github
• "SwithFr" : un badge que seul moi peut avoir (et si un utilisateur à le pseudo "moi") il peut aussi l'avoir :)
• "Confiné" : Idée de Grafikart pour les comptes créés avant le confinement ;)
• "Motivé" : Si on regarde X vidéos à la suite (hors formation sinon c'est trop facile)

L'objectif est de créer une carte pour représenter une formation. Cette carte serait repris dans les différents listings. Pour moi les informations importantes sont

• La technologie / sujet de la formation
• Le nombre de vidéo / chapitres
• La durée de la formation
• Le niveau nécessaire pour suivre la formation (est-ce que si je débute dans la techno je peux suivre la formation ?)

La suppression d'une réponse au forum est bien effective, mais visuellement le message n'est pas supprimé.

Fameuse erreur du Illegal constructor

Les forums passent maintenant a une structures de tag. La question est donc de trouver une organisation convenable.

Ma première idée est de séparer par langage et d'avoir en enfant les framework technos. Le souci est alors: comment dire "ma question concerne PHP brut"

L'objectif est d'avoir à gauche du forum une navigation permettant d'accéder rapidement au sujet qui nous intérèsse : https://discuss.flarum.org/t/meta

Lors de l'initialisation du projet, le README.md nous dit que pour participer on peut lancer le serveur avec la commande "make dev" or cette commande ne suffit pas à initialiser le projet. Il est nécessaire de lancer un make install pour générer les assets. serait-il possible de détailler un peu plus le process d'initialisation ?

https://www.figma.com/file/Gi73ZypyKWAukwNBfu1aPW/Site-Copy?node-id=21%3A2

Il serait intéressant de proposer des contenus à regarder lorsqu'un utilisateur complète une formation en lui envoyant un email ou via une alerte sur le site.

Fonctionnement

Pour mettre en place ce système il faudrait créer dans un premier temps un système qui permettrait de définir les contenus "relatifs" à une formation (une liaison n-n entre Content et Content). Ensuite, il serait possible d'écouter l'évènement ProgressEvent et de déclencher l'envoie de l'email en suggérant X contenu relatif.

Au lancement de docker avec make dev, j'obtient une erreur sur vite et du coup le container node plante