Un autre résumé de semaine!
Pas grand chose à dire là dessus cette semaine, puisque je ne me suis pas attardé à du code très complexe.
J'ai plutôt cherché, tout au long de la semaine, à retravailler les différentes interfaces que nous trouvons moins jolies. Je n'ai vraiment fait que ça cette semaine....
lundi 27 avril 2009
lundi 20 avril 2009
Résumé des deux dernières semaines
Premièrement, bonjour et désolé pour le retard dans mes billets. Les deux dernières semaines ont été assez mouvementés. Pas tellement mouvementées au niveau de mon travail ici, mais plutôt du côté personnel! Avec mon déménagement assez récent et les travaux dans l'appartement, la création de mon entreprise, contrats ici et là... tenir mon journal à jour m'est complètement sorti de la tête!
Donc voici un résumé, en une seule entrée, des deux dernières semaines:
Semaine du 6 avril
Durant la semaine, j'ai travaillé surtout sur le portail Tuteur.. ET oui! Le portail étudiant est pratiquement terminé et nous débutons même le portail Tuteur! J'ai donc travaillé sur la fenêtre de paramétrages des préférences du tuteur. Dans cette page, il sélectionne ses préférences quand à l'envoi de courriel et l'affichage du résumé de ses assignation (Page appelé sommaire).
J'ai décidé, pour garder de la cohérence entre les différentes interfaces des portails, d'utiliser une radGrid de Telerik pour afficher les paramètres.
Comme je l'ai déjà mentionné, avec une radGrid, on a pas le choix de lier celle-ci avec une source de données. C'est ici que j'ai frappé un problème. La table dans laquelle sont stockés les données contient une entrée pour chacun des paramètres: donc pour chacun des paramètre, j'obtiens une donnée me disant s'il est activé, une me disant s'il désire le recevoir de façon hebdomadaire ou quotidienne et une autre me disant quelle journée de la semaine il désire recevoir un courriel. Il a donc fallu mettre de l'ordre dans ces données et les regroupe dans un joli DataTable bien ordonné.
Ceci m'a prit beaucoup de temps pour trouver une solution efficace et sur laquelle il serait facile d'effectuer de la maintenance. J'ai ensuite réalisé l'interface, ici, ce fut beaucoup de "Tapponage", mais comme je suis rendu assez habitué avec les RadGrid, ce fut assez rapide.
Mais j'ai frappé un autre mur qui m'a encore une fois prit pas mal de temps à surmonter! Mes données bien ordonnées, il faut que je sois capable des les "désordonner" pour être en mesure de les sauvegarder dans la BD! Zut alors! Un joli select case et beaucoup de constantes ont réglé le problème. Beaucoup de commentaires se sont imposés alors, mais le résultat final est clair.
Semaine du 13 avril
La page de sommaire du portail tuteur semblait assez simple à réaliser à première vue. Elle n'est composée que d'un petit résumé des assignations du tuteur et de leurs changement depuis la dernière visite. Mais Oh comble de malheur! Elle est comme qui dirait une vraie "Pain in the ass", pardonnez-moi l'expression anglaise, à réaliser.
Pour commencer, il me faut au minimum une bonne trentaine de requêtes pour obtenir les données pour la peupler. De plus, aucun WebService ou fonction dans la BD n'est réalisée pour les obtenir. Évidemment, il faut une très bonne compréhension du diagramme pour arriver à les réaliser.
J'en ai donc parlé avec des personne d'ici connaissant bien le système et ils vont les réaliser pour moi. Je n'aurai donc qu'à réaliser les WebServices appelant les fonctions.
J'ai passé un bon moment à préparer l'interface pour acceuillir les données.
J'ai aussi travaillé sur plusieurs interfaces au courant de la semaine. J'ai préparé quelques formulaire pour augmenter la rapidité à les programmer quand sera venu le temps de travailler sur ces pages.
Nous avons aussi eu une réunion sur les prochaines étapes dans la réalisation du portail étudiant. Nous l'avons passé au peigne fin pour déceler ce qui restait à faire et j'ai corrigé quelques bugs trouvé et appliqué certaines améliorations.
J'ai aussi repassé sur quelques interfaces de Sébastien qui n'étaient pas cohérentes avec le reste du portail.
Et en date d'aujourd'hui, je travaille toujours à cette tâche!
Donc voici un résumé, en une seule entrée, des deux dernières semaines:
Semaine du 6 avril
Durant la semaine, j'ai travaillé surtout sur le portail Tuteur.. ET oui! Le portail étudiant est pratiquement terminé et nous débutons même le portail Tuteur! J'ai donc travaillé sur la fenêtre de paramétrages des préférences du tuteur. Dans cette page, il sélectionne ses préférences quand à l'envoi de courriel et l'affichage du résumé de ses assignation (Page appelé sommaire).
J'ai décidé, pour garder de la cohérence entre les différentes interfaces des portails, d'utiliser une radGrid de Telerik pour afficher les paramètres.
Comme je l'ai déjà mentionné, avec une radGrid, on a pas le choix de lier celle-ci avec une source de données. C'est ici que j'ai frappé un problème. La table dans laquelle sont stockés les données contient une entrée pour chacun des paramètres: donc pour chacun des paramètre, j'obtiens une donnée me disant s'il est activé, une me disant s'il désire le recevoir de façon hebdomadaire ou quotidienne et une autre me disant quelle journée de la semaine il désire recevoir un courriel. Il a donc fallu mettre de l'ordre dans ces données et les regroupe dans un joli DataTable bien ordonné.
Ceci m'a prit beaucoup de temps pour trouver une solution efficace et sur laquelle il serait facile d'effectuer de la maintenance. J'ai ensuite réalisé l'interface, ici, ce fut beaucoup de "Tapponage", mais comme je suis rendu assez habitué avec les RadGrid, ce fut assez rapide.
Mais j'ai frappé un autre mur qui m'a encore une fois prit pas mal de temps à surmonter! Mes données bien ordonnées, il faut que je sois capable des les "désordonner" pour être en mesure de les sauvegarder dans la BD! Zut alors! Un joli select case et beaucoup de constantes ont réglé le problème. Beaucoup de commentaires se sont imposés alors, mais le résultat final est clair.
Semaine du 13 avril
La page de sommaire du portail tuteur semblait assez simple à réaliser à première vue. Elle n'est composée que d'un petit résumé des assignations du tuteur et de leurs changement depuis la dernière visite. Mais Oh comble de malheur! Elle est comme qui dirait une vraie "Pain in the ass", pardonnez-moi l'expression anglaise, à réaliser.
Pour commencer, il me faut au minimum une bonne trentaine de requêtes pour obtenir les données pour la peupler. De plus, aucun WebService ou fonction dans la BD n'est réalisée pour les obtenir. Évidemment, il faut une très bonne compréhension du diagramme pour arriver à les réaliser.
J'en ai donc parlé avec des personne d'ici connaissant bien le système et ils vont les réaliser pour moi. Je n'aurai donc qu'à réaliser les WebServices appelant les fonctions.
J'ai passé un bon moment à préparer l'interface pour acceuillir les données.
J'ai aussi travaillé sur plusieurs interfaces au courant de la semaine. J'ai préparé quelques formulaire pour augmenter la rapidité à les programmer quand sera venu le temps de travailler sur ces pages.
Nous avons aussi eu une réunion sur les prochaines étapes dans la réalisation du portail étudiant. Nous l'avons passé au peigne fin pour déceler ce qui restait à faire et j'ai corrigé quelques bugs trouvé et appliqué certaines améliorations.
J'ai aussi repassé sur quelques interfaces de Sébastien qui n'étaient pas cohérentes avec le reste du portail.
Et en date d'aujourd'hui, je travaille toujours à cette tâche!
vendredi 3 avril 2009
RÉsumé du reste de la semaine
Bon bon bon... désolé je n'ai pas été assidu à ma tâche de journalisation cette semaine, je l'avoue. Avec mon déménagement la fin de semaine dernière ainsi que lundi, en plus de l'après-midi au cégep mercredi... j'ai pas mal été à la course! C'est pourquoi je résume mercredi, jeudi et vendredi en un seul billet de blog qui va comme suit:
Durant ces trois jours, j'ai finalement réussi à optimiser la requête grâce au DBA. Premièrement, l'une de mes jointures n'était pas bonne (Ex: Table1.id = Table1.id ... héhé, sans commentaire!). Deuxièmement, pour des raisons obscures, Oracle faisait certains Table Access Full alors qu'il ne devait pas. Le DBA a corrigé mon problème en ajoutant un mot clé après le SELECT de la requête, qu'il m'a fait jurer de ne jamais utiliser et d'oublier immédiatement... Ce que j'ai plus ou moins fait et me suis renseigné question d'approfondir la matière. Cemot clé permet de forcer le compilateur d'Oracle de fonctionner différemment... je n'en dit pas plus!
J'ai aussi travaillé sur la page d'affichage des résultats d'un étudiant, que j'avais déjà commencé. Je l'ai amélioré et terminé.
J'ai aussi travaillé sur le système d'authentification et testé plus en profondeur certaines pages déjà réalisées.
Ceci résume ma semaine en gros!
Durant ces trois jours, j'ai finalement réussi à optimiser la requête grâce au DBA. Premièrement, l'une de mes jointures n'était pas bonne (Ex: Table1.id = Table1.id ... héhé, sans commentaire!). Deuxièmement, pour des raisons obscures, Oracle faisait certains Table Access Full alors qu'il ne devait pas. Le DBA a corrigé mon problème en ajoutant un mot clé après le SELECT de la requête, qu'il m'a fait jurer de ne jamais utiliser et d'oublier immédiatement... Ce que j'ai plus ou moins fait et me suis renseigné question d'approfondir la matière. Cemot clé permet de forcer le compilateur d'Oracle de fonctionner différemment... je n'en dit pas plus!
J'ai aussi travaillé sur la page d'affichage des résultats d'un étudiant, que j'avais déjà commencé. Je l'ai amélioré et terminé.
J'ai aussi travaillé sur le système d'authentification et testé plus en profondeur certaines pages déjà réalisées.
Ceci résume ma semaine en gros!
mardi 31 mars 2009
Mardi
Bon, il semble que j'ai d'importants problèmes de performances dans ma requête de suivi des activités. Ça prend plusieurs secondes à s'exécuter. J'ai donc tenté de la corriger et de l'optimiser à la façon dont je l'ai fait avec la requête pour obtenir les résultats.
Comble de malheur, ce fut un échec. Au lieu de l'améliorer, je n'ai fait que l'empirer et la rendre encore moins performante. Après avoir passé quelques heures dessus, j'ai fait appel à Éric, l'un des DBA de la Teluq. J'attend toujours sa réponse...
lundi 30 mars 2009
vendredi 27 mars 2009
Vendredi
Bon! Une grosse journée pour terminer la semaine!
Aussitôt arrivé au travail aujourd'hui, je me suis mit à "taponner" sur la requête que m'a pondu Sébastien hier. J'ai du contacter Iannick Légaré pour m'assurer de l'endroit où je devais récupérer certaines données. Il me fallait en autre rajouter une jointure pour récupérer la note globale pour le cours d'un étudiant. C'est là que j'ai frappé un problème.
Premier problème: la requête était extrêmement lente à s'exécuter: je parle ici d'assez gros problèmes de performance: 18 secondes d'exécution!
Deuxième problème: 894 résultats depuis l'ajout de ma jointure au lieu des 50 que j'étais censé recevoir!
J'ai préféré, pour m'assurer de rendre la requête plus performante, la reconstruire à partir de zéro. En effet, nous faisions une jointure sur une vue, cela faisait des "full table access" à chacune des jointures... assez gourmand en performance on peut dire!
J'ai donc réussi à régler les problèmes de performance. Et pour ce qui est du deuxième problème, Éric Bédard, notre DBA, m'a expliqué comment réalisé un vrai outer join dans la clause where avec Oracle. Il faut mettre un (+) à côté du table1.id = table2.id.
Voilà! Tout fonctionne. Reste plus qu'à corriger l'affichage!
Aussitôt arrivé au travail aujourd'hui, je me suis mit à "taponner" sur la requête que m'a pondu Sébastien hier. J'ai du contacter Iannick Légaré pour m'assurer de l'endroit où je devais récupérer certaines données. Il me fallait en autre rajouter une jointure pour récupérer la note globale pour le cours d'un étudiant. C'est là que j'ai frappé un problème.
Premier problème: la requête était extrêmement lente à s'exécuter: je parle ici d'assez gros problèmes de performance: 18 secondes d'exécution!
Deuxième problème: 894 résultats depuis l'ajout de ma jointure au lieu des 50 que j'étais censé recevoir!
J'ai préféré, pour m'assurer de rendre la requête plus performante, la reconstruire à partir de zéro. En effet, nous faisions une jointure sur une vue, cela faisait des "full table access" à chacune des jointures... assez gourmand en performance on peut dire!
J'ai donc réussi à régler les problèmes de performance. Et pour ce qui est du deuxième problème, Éric Bédard, notre DBA, m'a expliqué comment réalisé un vrai outer join dans la clause where avec Oracle. Il faut mettre un (+) à côté du table1.id = table2.id.
Voilà! Tout fonctionne. Reste plus qu'à corriger l'affichage!
jeudi 26 mars 2009
Jeudi
Comme je n'ai pas eu le temps de réaliser entièrement la page des résultats d'un étudiant hier, j'ai poursuivi cette tâche aujourd'hui. J'ai expérimenté pas mal avec le contrôle RadPanelBar de Telerik. Pour gérer mon affichage, il est complètement super! Je peux mettre un contrôle Literal dans celui-ci et comme cela, à moi de gérer les possibilités infinies d'affichage!!! Héhé!
Sébastien a terminé une requête censé me retourner tous les résultats nécessaires pour ma page, alors j'ai réalisé le web service pour la faire exécuter et récupérer les données. Une fois terminé, je me suis rendu compte qu'il me manquais certaines données pour ma page, dont la note globale pour un cours ainsi que la bonne date de fin pour le cours en question. Je n'ai plus le temps de faire cela aujourd'hui, je ferai cela demain!
Sébastien a terminé une requête censé me retourner tous les résultats nécessaires pour ma page, alors j'ai réalisé le web service pour la faire exécuter et récupérer les données. Une fois terminé, je me suis rendu compte qu'il me manquais certaines données pour ma page, dont la note globale pour un cours ainsi que la bonne date de fin pour le cours en question. Je n'ai plus le temps de faire cela aujourd'hui, je ferai cela demain!
Inscription à :
Articles (Atom)