logo

Bienvenue visiteur,

ETS2Routes est un site consacré au jeu Euro Truck Simulator 2. Pour plus d'informations, toute l'équipe te propose d'aller lire la FAQ, où tu trouveras réponses aux questions que tu te pose.

Joyeux noël
Catégorie : Général
Auteur : christophedlr
Bonjour,

Je vous souhaite à tous un joyeux noël. Malheureusement la nouvelle version du site n'est pas encore sous le sapin. Le travail reprendra dessus après les fêtes, sur un tout nouvel ordinateur plus puissant, plus efficace et qui va me permettre d'aller plus vite.
ETS2Routes "2.0" - Son avancement
Catégorie : Mise à jour
Auteur : christophedlr
Bonjour,

Cela fait un moment que je n'ai pas donné de nouvelles ici sur le site, en effet tout est sur la page Facebook mais je pense pas à en donner ici.

La nouvelle version du site que l'on pourrait appeler une version 2.0 est toujours en cours de développement. En effet, j'ai eu plusieurs difficultés notamment avec l'usage de Symfony qui ne correspond pas à mes besoins pour le coup.

Je suis entrain donc de refaire tout le site avec mon propre framework. Tout ce que je reprends de Symfony c'est Twig le moteur de template, le reste à savoir : moteur de routing, gestion des entités, générateur de requêtes (QueryBuilder), générateur de formulaire, services etc. tout est fait intégralement par moi.

Pourquoi cela ? Montrer aux employeurs (car oui de Janvier à Juillet j'étais en poste, ce n'est plus le cas donc il faut bien trouver un boulot ;) ) ce que je sais faire et les défis que je suis capable de relever.
De plus, concevoir mon propre framework me permettra lors de mes autres projets (certains seront avec Symfony tout de même), de les développer bien plus vite avec une solution que je connais très bien et qui s'améliorera au fil des projets et donc des besoins.

Pour l'instant, pas grand chose de déjà programmé, en effet pour gérer les news (système de module à créer et premier donc module qui sera fait), je dois déjà disposer d'utilisateurs. Hors la gestion utilisateur, implique de gérer la base de données.

Pour gérer la base de données, j'ai plusieurs solutions : les modèles, c'est à dire une classe qui exécute les requêtes et renvoi le résultat. Mon système d'entité, à la base était capable de récupérer le résultat des requêtes et de placer cela dans une classe à exploiter, ce qui est donc relativement bien.

Sauf que j'en arrive à des besoins particuliers dont la création de la base de données en automatique. Le système de modèles correspond donc pas à mon besoin avec un système d'entités (une classe contenant toutes les informations d'une table ou d'un fichier). Du coup je dois créer mon générateur de requêtes (un QueryBuilder).


Ainsi, je repars sur un principe de Symfony à savoir les entités (c'était prévu), et les "repository". Les entités sont gérés par mon outil Entiter (c'est son nom, pas très original lol), qui prend donc un tableau fournis par le repository (qui exécute les requêtes et bientôt les fera exécuter ;) ) et remplis donc l'entité.
Le repository est géré par Entiter, c'est donc lui qui appel les méthodes que l'on demande d'appeler du repository.

Pour l'instant ça va pour la lecture, l'écriture ou la mise à jour de données. Mais la création d'une table par exemple, ne relève pas du repository puisque ne relevant pas directement d'une classe d'entité.
Ca en relève en partie car l'entité dispose d'un fichier de définition de la table listant les correspondance entre les deux et la structure donc de la table SQL.

Sauf que ce n'est pas un retour d'entité, donc le repository ne doit pas s'en occuper mais directement le coeur : Entiter. Je me rends compte avec les tests pour créer les tables, que c'est très très lourd. Du coup, il me faut un générateur de requêtes (QueryBuilder).

Les QueryBuilder, sont des outils dont on appel différentes méthodes pour concevoir une requête SQL sans en connaître la syntaxe (les mots clés et la position). Tout ce qu'on a besoin de savoir, c'est qu'une requête de lecture par exemple, a besoin d'une (ou plusieurs) table de sélection, d'une liste de champs à sélectionnés ou un wildcard (*) pour tous les choisir sans en connaître la liste, sur quoi on se base (les champs et les valeurs), l'ordre de tri et éventuellement les différentes jointures.

Quand on sait ça, rien de plus simple, on dit au QueryBuilder de créer une requête de sélection, de sélectionner telles colonnes dans telle table suivant des critères et de nous retourner l'ensemble des lignes (ou que la première ligne trouvée).

On donne donc les instructions, il génère donc le code SQL, l'exécute (avec PDO dans mon cas) et en retourne le résultat demandé.

Un QueryBuilder bien construit, permet de générer la plupart des requêtes : sélection, ajout, suppression, mise à jour de données, création, vidage, suppression ou modification de tables et même créer ou supprimer carrément une base de données. En prime, un QB (QueryBuilder) bien fait, devrait être capable de pouvoir gérer les jointures, que se soit interne, gauche ou droite et les sélection distinctes (un seul exemplaire de chaque données).


Je suis donc à créer ça, quand se sera fait, il sera capable de gérer tout les types de requêtes que j'ai cités et donc concevoir même des requêtes complexe par ce biais (on pourrait par exemple générer une première requête, récupérer que le code SQL, que l'on fournirais en tan que valeur d'un champ d'une autre requête, faisant donc une requête imbriqué).

Ainsi, Entiter sera dégagé de tout travail : il se référera à l'outil indiqué (injection de dépendances), en appelant uniquement les méthodes de ce dernier. Si entre temps je souhaite utiliser un nouveau QueryBuilder pour pas exemple gérer SQLite (dont la structure des tables est un peu différentes) ou gérer des fichiers comme si on exécutais des requêtes, il suffirait alors de fournir à Entiter le nouvel outil à la place.

Le système étant prévu (via des Interface), pour que chaque QueryBuilder est obligatoirement la même structure, c'est à dire la structure que va utiliser Entiter ; à partir de là, l'outil lui fait son travail derrière. Ainsi, pas dépendance à un QueryBuilder particulier, on injecte la dépendance déjà plutôt que l'initialiser soit même, ensuite les méthodes étant toujours les mêmes, on change pas les appels.
Quelques nouvelles du projet
Catégorie : Général
Auteur : christophedlr
Je viens vous apporter des nouvelles de ce projet. Je viens tout juste de terminer ce qu'il manquait de l'administration : les news et leurs catégories.

Dans les prochains jours (à partir de lundi je pense), je vais faire ce qu'il manque : modifier son profil, gérer l'envoi du mal à l'inscription, la page de contact, l'avatar du compte utilisateur et l'icône pour les catégories de news.

A partir de demain et ce jusqu'à lundi, je vais commencer à faire des tests sur ce qui est déjà en place, à savoir regarder ce qui est en place, noter dans un document Excel le comportement de chaque parties en pensant à ce qu'il doit faire mais aussi ce qui ne doit pas apparaître (par exemple modifier le créateur de la news par exemple) etc.
Chaque éléments ainsi notés dans ce tableau Excel, me servira pour des "tests unitaires" faits à la main (sans l'aide d'outils qui teste le code pour moi type PHPUnit/Khalan).

Je pense que ce tableau sera prêt pour lundi, et j'y ajouterais au fur et à mesure (j'aurais du le faire dès le début) au développement, les différents tests.
Dès la fin de ce qu'il manque, je ferais une batterie de tests suivant ce document Excel donc, dans lequel sera noté la version testée, la date du test et si le point vérifié est bon ou non.

Chaque point qui n'est pas bon, fera l'objet d'un rapport de bug et d'une correction une fois tout les tests réalisés. La correction de bugs sera aussi l'occasion pour moi, de revenir sur certains éléments visuels comme les icônes de crayons et de croix (qui respectivement symbolisent l'édition et la suppression) qui sont en bleus et soulignés, comme pour tout les liens.

A l'issu des dites corrections, je referais tout les tests en totalités. Le développement ne reprendra pas tan que tout les bugs identifiés ne seront pas corrigés.
Plus tard, lors des autres développements, dès qu'une partie sera complète, elle sera testée par ce biais et corrigée au besoin avant de s'attaquer à un autre morceau.

Régulièrement, des tests globaux (donc même des parties déjà testées et fonctionnelles) seront réalisés, là encore pour vérifier que le développement n'a pas crée de régression.


J'ai à coeur que ce projet soit le plus exempte de bugs possibles, aussi faire tout ces tests de manière régulières, permettent d'éviter un bon nombre de problèmes. Les autres, ceux auxquels je n'aurais pas pensés (impossible de penser à tout ^^), seront corrigés au fur et à mesure de l'utilisation en production quand ils seront identifiés et la façon de les reproduire, ajouter à la liste des tests.

Faire tout ces tests prend beaucoup de temps, lors de mon stage par exemple, il m'a fallut 2j pour d'une part mettre au point les tests (penser à tout et noter) puis faire les tests et identifiés les problèmes (de plus j'avais pas accès au code, donc j'identifiais d'après le comportement actuel et celui attendu).
Ce que je veux dire par là, c'est que le travail est très important, en particulier pour un site tel que ETS2Routes, dont les fonctionnalités sont multiples et le fonctionnement rendu complexe par l'utilisation d'un framework.

Le site accuse beaucoup de retard sur la durée de développement initialement prévue, mais au moins je sais qu'à la fin se sera un produit, qui je l'espère vous comblera.