Semaine du 26 au 30 janvier

Journal de stage : semaine du lundi 26 au vendredi 30 janvier 2015

Voici mes entrées de journal pour cette troisième de stage semaine de stage. Cette semaine je continuerais le développement web de l’application de l’atelier et j’aurais une petite réunion de mise au point avec l’équipe de l’atelier vendredi.

► Lundi 26 janvier 2015

Aujourd’hui j’ai poursuivi l’écriture de mon algorithme pour construire mes requêtes SQL afin de créer plusieurs tableau, lesquels seront construit suivant les choix de l’utilisateur. Pour faire cet algorithme j’utilise beucoup de switch, ça me simplifie la vie et je peux gérer au cas par cas, je pourrais sûrement améliorer ce système plus tard mais j’ai d’abord besoin que cela fonctionne.

J’ai également commencer à créer un petit formulaire pour que l’utilisateur puisse faire ses choix dans le tri des résultats, j’ai d’abord commencé par la faculté de regroupement des tableaux, je pense que c’est l’essentiel puisque maintenant l’interface est plutôt claire, selon moi.

formtri

Pour le moment ce formulaire ne fais rien, puisque le script derrière ne fonctionne pas encore très bien. Je continue de faire mes tests sans celui-ci, manuellement donc.

J’ai remarqué qu’il manquait certain ticket, afficher dans la base que je voyais avec phpMyAdmin mais que mon script n’affichait pas. En y regardant de plus près j’ai découvert qu’il y avait des valeurs différentes entre les clés étrangère stockés dans la base de données et des les clés primaire des tables, ce qui fait qu’on se retrouve avec des valeurs (avec les clés étrangères) qui n’existe que dans la table ticket ! Logiquement ce n’est techniquement pas possible, c’est plutôt étrange …

Par exemple, je vais trouver « 0 » comme valeur pour la colonne « importance » de la table « ticket », ors il n’y a pas de colonne ayant pour valeur « 0 » dans la table « importance » … Ce qui est problématique lorsque l’on fait des jointures comme moi dans le requêtes, aucun résultat ne sors !

Pour parer ce problème j’ai dû ajouté les valeurs manquantes dans les tables, en faite cela apparaissait uniquement lorsque aucune des valeurs n’a été mise dans les tables, par exemple on peut créer un ticket sans niveau d’urgence, alors on le créer avec le niveau d’urgence « 0 », qui ne correspond à rien.

J’ai finalement réussi à arranger mes jointures pour que les noms des tableaux de regroupement apparaisse, plutôt que leurs numéros.

libtabr

J’avais également un petit problème, lorsque le titre du ticket était le même que la description, mon script ne faisait pas la différence et n’affichait pas le titre sur la ligne lorsque celui ci correspondait à la description (puisque je n’affiche la description dans la ligne suivante, cachée). C’était à cause de mes comparaisons, je comparais 2 cases de tableau PHP l’une avec l’autre, alors qu’il me fallait comparer seulement la clé du tableau.

A la fin de la journée, Mme Fichet m’a rendu visite, pour faire rapidement le point puisqu’elle ne sera pas présente mercredi, le rendez-vous est avancé. Pour voir si j’étais dans les temps par rapport à mercredi dernier.

Comme je suis dans les temps et que la nouvelle version de l’application commence à prendre forme nous avons convenu de faire une nouvelle réunion avec l’équipe concerné par cet application, nous avons convenu que nous nous retrouverons à nouveau vendredi à 10h30. J’ai envoyer un mail à tout le monde pour confirmer cette réunion. De cette façon ils pourront voir où le développement en est, qu’ils soient au courant et qu’il puisse faire des remarques sur ce qui ne vas pas, afin de me corriger si je fais fausse route.

J’ai expliquer à Mme Fichet mon problème de comparaison de tableau, c’est vrai que c’est assez pragmatique et compliqué comme question mais avec son intervention mon algorithme marche enfin, j’avais juste ce problème à régler. Il suffisait juste d’utiliser correctement une des deux syntaxe du foreach de PHP.

<?php

foreach ($row as $key => $value) {
	if ($key != 'description' && $key != 'ticketid')
	$tbody .= "<td>".$value."</td>";
}

?>

En essayant d’expliquer mon problème j’ai bien saisi que c’était assez complexe techniquement et surtout à expliquer, je pense faire un logigramme de mon script pour le modéliser, et pour que les personnes externes au développement comprenne bien son principe.

Demain je ferrais la liaison entre mon formulaire et le script permettant le tri sur les tickets, de façon à mettre l’interface utilisateur fonctionnelle. Ensuite je continuerais par faire toute les différentes listes de tickets avec leurs modules de tri.


 ► Mardi 27 janvier 2015

J’ai commencé ma journée par créer la liaison entre mon formulaire et mon script, et en vérifiant que tout fonctionnait j’ai eu une petite idée, avec les données que j’ai déjà je pourrais facilement faire un petit sommaire des différents tableaux de regroupement, rendant la navigation plus aisée. J’ai fais cela très rapidement et le rendu est plutôt bon, je trouve que ça améliore beaucoup la qualité de la navigation.

<a href="#Menuiserie">Menuiserie</a>

summ

J’ai fais cela très simplement avec du HTML seulement, il suffit de faire un lien vers un élément HTML grâce à son identifiant (sélecteur CSS) et le navigateur nous amène directement sur l’élément, on remarque d’ailleurs que l’URL change.

summmm

Dans la foulé, j’ai créé un bouton flottant du type « Aller vers le haut de page », de façon à retourner sur le sommaire facilement. J’ai suivi le même principe que pour le sommaire, un simple lien sur un élément situé en haut de la page.

totop

J’ai ensuite créé une page affichant les détails du ticket qu’on sélectionne, on y accède en cliquant simplement sur l’icône de feuille dans la liste des tickets. La page de détail qu’on obtient via la liste de tous les tickets ne permet de rien faire comme action, conformément au diagramme des cas d’utilisation, on peut seulement consulter en détails les informations liés à un ticket et, plus tard, l’historique et les commentaires de ce ticket.

En allant faire une pause j’ai croisé Samuel Josseau dans les couloirs, il m’a dit qu’il était intéressé pour la réunion de vendredi et qu’il viendrait.

J’ai créé une petite fonction qui permet d’afficher une icône différente en fonction du niveau d’importance, afin d’ajouter du « visuel » sur cette page, comme c’est une fonction je pourrais facilement la réutiliser sur d’autre page.

iconimp

Ensuite j’ai créer la liste des tickets à attribuer, en prenant exemple sur la première page de liste que j’ai créer, j’ai juste eu à adapter ma requête SQL pour ne sélectionner que les tickets dont le statut est à attribuer, et j’ai donc retirer la possibilité de pouvoir filtrer par statut.

Ensuite j’ai commencer à créer ma fiche de détail pour ces tickets à attribuer, afin de leurs définir une importance et un agent responsable (attribuer).

attribuer

J’ai commencer à créer les bouts de formulaire permettant de faire ces actions, il faut que je gère tout les cas puisque l’agent ou l’importance ou aucun des deux ne peuvent être attribué.

Pour demain je continuerais l’implémentation du formulaire pour les tickets à attribuer, j’ajouterais peut être une fonctionnalité « attribution rapide » depuis la liste et non seulement depuis la page de détails.


► Mercredi 28 janvier 2015

J’ai démarrer ma journée en créant un petit script pour mettre une casse de phrase (première lettre en majuscule et le reste du mot en minuscule) sur les noms et prénoms des utilisateurs, ils avaient des majuscules ou des minuscule placé un peu de façon aléatoire.

<?php

$nom = ucfirst(strtolower($row['nom']));
$prenom = ucfirst(strtolower($row['prenom']));

?>

Ensuite j’ai finaliser le formulaire sur la page de détail des tickets à attribuer afin d’affecter un agent et de définir une importance, j’aurais juste un peu d’ajax à ajouter pour modifier l’icône de l’importance en fonction du choix de l’utilisateur.

ajaxxx

J’ai créer la liste des tickets en cours et la page de détails correspondantes. Dans la page contenant la liste des tickets en cours, je trouve les résultats un peu trop nombreux et redondant, en faite j’avais fait un petite erreur de calcul booléen dans ma requête SQL, de ce fait j’avais trop de résulats.

SELECT `ticket`.`id` AS `ticketid`,
	   `titre`, `description`, `id_responsable`
	   `categorie`.`nom` AS `categorie`,
	   `importance`.`nom` AS `importance`,
	   `lieu`.`nom` AS `lieu`
FROM `ticket`
INNER JOIN `categorie`
		ON `ticket`.`categorie` = `categorie`.`num`
INNER JOIN `importance`
		ON `ticket`.`importance` = `importance`.`num`
INNER JOIN `lieu`
		ON `ticket`.`lieu` = `lieu`.`num`
WHERE `ticket`.`d_ouverture` = "2015-01-27" AND `ticket`.`statut` = 2 OR `ticket`.`statut` = 3
ORDER BY `d_ouverture`, `importance` ASC;
Requête SQL générée

Dans cette liste de ticket en cours, je veux uniquement les tickets en cours OU en attente. Finalement je devais juste mettre des parenthèse pour faire l’opération OR, sinon l’opérateur AND prenait la priorité et ma requête ne faisait pas ce que je voulais.

WHERE `ticket`.`d_ouverture` = "2015-01-27" AND (`ticket`.`statut` = 2 OR `ticket`.`statut` = 3)

Je finalise mes listes, en terminant par la liste des tickets résolus. Avec cette liste de terminée, elles le sont toutes maintenant ! L’application commence à prendre forme. Évidement il faut que je m’occupe des fonctionnalités derrières ces listes mais c’est déjà un bon début.

J’ai seulement un problème que j’ai besoin d’éclaircir, par rapport à la base de données, je ne comprend pas à quoi correspond la colonne « id_responsable » de la table « ticket », quand je regarde les valeurs, cela ne correspond à rien, pourtant d’après le code SQL de création de la base c’est une clé étrangère pour la table « responsable », qui elle même contient une colonne « id_responsable » …

wtf

Comme je n’arrive pas à éclaircir ce point je continu sans, mais je pense qu’il faudra revoir la base de données, c’est de toute façon ce que je devrais faire pour mieux gérer les commentaires et l’historique du ticket.

J’ai continuer le développement du formulaire pour résoudre le ticket, c’est ce que je continuerais pour demain. Ensuite je commencerais (finalement) le formulaire pour valider le ticket et je finaliserais l’adaptation des dernières fonctionnalités d’administration dans la nouvelle interface.


 ► Jeudi 29 janvier 2015

Plus je regarde la base de données et plus je pense qu’il faut l’améliorer, il y a beaucoup de choses farfelues (du moins que je ne comprend pas) et d’après moi ça peut se simplifier sans trop se compliqué. Seulement si de trop grand nombre de changement sont effectués sur la base de données elle ne sera plus compatible avec l’ancienne, ce qui est problématique pour conserver les données déjà existante. Une solution peut consister à faire coexister les versions : gardez l’ancienne pour terminer les tickets déjà stocké, et la nouvelle pour les prochains tickets.

En réfléchissant sur mon problème pour colorier les colonnes des tableau de liste avec le sélecteur CSS, j’ai remarquer que le sélecteur n’était rien d’autre qu’une suite mathématique d’entier, j’ai pris le problème sur une feuille de papier et j’ai trouver la solution, qui était plutôt simple en faite … 4n – 1 !

table tbody tr:nth-of-type(4n - 1){
	background-color: #C8E6C9; /* vert légérement plus sombre */
}
:nth-of-type(4n - 1)

J’ai commencer brièvement à adapter l’ancien code pour la nouvelle application pour ce qui concerne le module « administration », gestion des utilisateurs … C’est assez chronophage au final puisque qu’il y au moins 3 ou 4 fichiers pour un seul cas d’utilisation, il faut rechanger les liens à chaque fois … Je ne pense pas continuer sur cette piste, puisque de toute façon la base de données risque de changer, j’ai seulement intégrer le cas d’utilisation « purger la base de données », même si je ne comprend pas l’intérêt de supprimés des données, cela à surement dû être réfléchit, si j’avais eu une documentation …

package admin

En début d’après midi Mme Fichet est venu me voir pour faire un petit point pour la réunion de demain, je lui ai montré un peu tout ce que j’avais produit depuis lundi, notamment le module de tri, j’avais ajouté la possibilité de regroupé la liste de ticket par date, mais le regroupement se faisait par jour, et cela fait beaucoup de tableau avec seulement une ligne. Il aurait été plus judicieux de pouvoir regrouper par mois ou par semaine plutôt.

J’ai brièvement expliqué les problèmes que j’ai remarqué sur la base de données avec Mme Fichet, et effectivement il sera préférable de changer la base de données, car son fonctionnement n’est vraiment pas clair. En réalité la colonne « id_reponsable » de la table « ticket » correspondait tout simplement à l’identifiant du ticket lui même, la données est donc redondante dans la table et le nom de la colonne est ambiguë (pas pour le moteur SQL mais pour le développeur).

Suite à cela j’ai voulu faire un MCD de ce que à quoi la base pourrait ressembler, j’ai commencer par faire un brouillon sur le tableau de la salle où je travaille, B0 209, et ensuite j’ai continuer sur le logiciel Win’Design, mais tout le travail que j’avais fais dessus à été perdu puisque il a planter sans raison, je travail et hop, « Win’Design à cesser de fonctionner » … J’ai perdu beaucoup de temps là dessus je me suis dis que je ferra cela au propre avec Mme Fichet.

windesign

J’ai commencer à modifier le regroupement par date, c’est plutôt simple dans un premier temps, j’utilise la fonction SQL DATE_FORMAT sur mon champ contenant la date, pour faire mes requêtes, j’ai seulement des problèmes pour trier les résultats une fois les données sélectionnées

SELECT DISTINCT DATE_FORMAT(`d_ouverture`, '%m;%Y')
DATE_FORMAT(date, format)

The DATE_FORMAT() function is used to display date/time data in different formats.

w3schools

Pour demain j’essayerais de terminer mes différents formulaire pour toute les étapes de « vie » (création jusqu’à clôture) du formulaire du ticket afin de le montrer pour la réunion prévue.


 

 ► Vendredi 30 janvier 2015

J’ai brièvement terminer mes différentes pages pour gérer le ticket, tout fonctionne excepté le formulaire pour clôturer le ticket, ce n’est qu’une question de temps et non de difficulté. Je suis prêt pour la réunion de 10h30.

Je me suis finalement acheter un adaptateur VGA/HDMI comme celui que l’on m’avait prêter, ça ne sera pas la première fois que ça me gênera et je pense que ça fait parti de mon rôle de technicien de savoir s’adapter à son environnement. Donc problème résolu !

La réunion à été plutôt longue mais en présentant ce que j’avais déjà produit je pense que l’équipe de l’atelier à bien pu voir ce que j’ai fais, et je pense que ça leur plait. Globalement ce que j’ai produit est satisfaisant mais on voit toujours des petites amélioration à faire mais il faut savoir se fixer un cahier des charges et s’y tenir sinon les délais ne suive plus, et pour mon cas les délais sont intangibles (du fait de la duré de mon stage).

Nous avons aussi décider qu’il valait mieux refonder la base de données, ça me simplifierais le travail pour après et je pourrais mieux la documenter si le besoin se fait. De cette façon nous avons conclu qu’il fallait faire coexister les deux version de l’application avec leurs base de données respectives, l’atelier se chargera de finir le travail sur l’ancienne pour passer sur la nouvelle, petit à petit. De plus cette solution me réduira les temps de mise en place, puisque je n’aurais pas, ou très peu, à faire migrer les anciennes données vers la nouvelle base.

Pour ce qui concerne le tri par date, c’est effectivement plus simple que je regroupe par mois, j’ai donc continuer cette piste dans l’après midi, j’ai également terminer mon dernier formulaire qui ne fonctionnait pas, pour clôturer le ticket.

Pour le regroupement par date tout fonctionne sauf que les mois s’affiche en anglais, il faut donc les traduire et pour cela j’ai plusieurs options :

  • Traduire avec MySQL avec des clauses CASE (complexe à utilisé)
  • Traduire manuellement sur des conditions avec PHP
  • Traduire automatiquement avec PHP (en utilisant des fonctions et des attributs de langues)

datemois

J’essaye d’opter pour la troisième option, qui est plutôt simple mais j’ai un problème assez récurrent avec la langue française : l’affichage des accents. Ce problème est assez compliqué à gérer puisque qu’il est souvent dû à l’encodage des caractères, et ce dernier peut être changé à quasiment tout les niveaux …

  • Serveur Web (Système d’exploitation hôte)
  • Base de données
  • Scripts serveur
  • Fichiers
  •  etc.

Je vais faire sans pour le moment, si ça se trouve cela se résoudra tout seul lors de la mise en place, sur un serveur LAMP et non WAMP comme mon serveur de développement.

Il faut juste que l’application soit plus bavarde, avec des messages de confirmation , ou d’erreur, pour informer l’utilisateur que tout s’est bien passé (ou pas). Il faudra également ajouté la gestion des commentaires, la suppression d’un ticket, l’historique du ticket et la partie « back office » (gestion des fonctionnalités disponibles pour les utilisateurs, par l’application), ce que je ferrais pour la semaine prochaine.

⇐ Page de journal pour la semaine précédente 

Page de journal pour la semaine suivante ⇒

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *