» Blog

2012
Feb
1

Morphing

Dans le cadre de l'enseignement Algorithmie et complexité de ce Master 1ère année, moi et mon binôme avons implémenté un Morphing. Un Morphing peut être vu sous deux formes différentes ; une première, qui consiste à fabriquer une animation qui transforme de la façon la plus naturelle et la plus fluide possible une image initiale vers une image finale. Et la deuxième, qui consiste à “fusionner” les deux images en une seule image qui comporte des caractéristiques des deux autres. En réalité ces deux définitions sont équivalentes. En effet, pour obtenir la “fusion”, il suffit de prendre une image intermédiaire de l’animation assez proche du milieu de celle-ci. Le Morphing est la plupart du temps utilisé pour transformer un visage en un autre. Voici le résultat :

A noter que dans le rendu vidéo, je suis le gas à la fin :)

La principale difficulté du projet a été de trouver de la documentation sur le Morphing. En effet, le Morphing n'est pas une simple transformation géométrique qui met en œuvre un unique algorithme mais il repose plutôt sur un enchainement d'algorithmes qui mit bout à bout donne ce résultat.

Ainsi, l'étude du morphing entre deux images nous a permis de nous familiariser avec deux grandes familles d'algorithmes que sont les algorithmes de triangulation et les algorithmes d'interpolation. A noter que l'intégralité du projet a été réalisée en OCaml (beurk). Ce projet a donné lieu à une présentation orale (entre autres) dont vous pouvez télécharger le support réalisé sous Xmind. Elle est suffisante pour résumer le projet.

2012
Jan
31

ToolBib

Préambule

Je suis très heureux de partager aujourd’hui sur mon blog ma première expérience en tant que chef de projet. J’ai eu la responsabilité d’une équipe de 12 personnes et pas n’importe qui : des étudiants, comme moi, en 3ème année de Licence en informatique.

Plus qu’un challenge personnel, j’ai particulièrement souhaité occuper ce poste afin de témoigner de mon expérience professionnelle acquise chez Opendev. En effet, je souhaitais partager ces 9 mois en entreprise avec l’ensemble des membres de mon groupe spécifiquement à travers ma gestion de projet.

Ce billet s’articulera selon plusieurs axes :

ToolBib

C’est en effet dans le cadre de l’enseignement de Technologie du Web que M. CHABRIER m’a confié la conduite du projet ToolBib. Il s’agit d’un projet web réalisé dans le cadre scolaire et qui compte dans la note finale de l’UE. Celui-ci s’est étalé sur 16 semaines, de février à mai 2011. Ce billet est tardif simplement parce que je souhaitais avoir du recul lors de sa rédaction.

Le projet

Mais qu’est-ce que ToolBib ? Quelle vaste question ; et c’est d’ailleurs pour y fournir une réponse adaptée que le document de vulgarisation a été créé. Ce document répond brièvement aux principales questions concernant le projet à travers :

L’idée de ce document est d’intégrer rapidement une nouvelle ressource à un projet sans devoir le briefer oralement. Dans l’idéal, en plus de leur rôle, devrait figurer à côté de chaque intervenant un moyen de le contacter (email et/ou numéro de téléphone).

Dans le cadre du projet ToolBib et afin de conserver la vie privée des intervenants, ces renseignements n’apparaissent pas sur ce document mais dans un autre intitulé email des intervenants.

Le document de vulgarisation d’un projet est, en outre, un excellent mémo. Pensez bien qu’un vrai chef de projet travaille rarement sur un seul projet à la fois.

ToolBib est [donc] une application web collaborative destinée à faciliter l’exploitation d’une base de données bibliographique par une communauté de chercheurs. Une partie de leur travail de recherche documentaire consiste à parcourir des documents de proche en proche. En effet, chaque document cite et/ou est cité par d’autres documents.

Les fonctionnalités de cet outil recouvrent :

  • la gestion et la maintenance de la base de données bibliographique et de ses utilisateurs ;
  • la mise à disposition graphique et personnalisable de cette base de connaissance.

L’équipe

Très tôt dans le projet, l’ensemble des ressources a été divisé en trois groupes supervisés chacun par un chef d’équipe :

La liste des étudiants impliqués dans le projet détaille les responsables d’équipe. L’organigramme est disponible dans une présentation PowerPoint. Avec le recul, je pense qu’il serait bon à l’avenir de proposer un organigramme exhaustif dans un document isolé.

Chaque responsable d’équipe a créé un diagramme de GANTT afin de répartir le travail entre ses ressources. J’ai personnellement validé et enrichi ces diagrammes. J’ai aussi apporté quelques retouches afin de synchroniser aux mieux les équipes.

Il faut savoir que j’ai veillé à ce que chaque responsable tienne un GANTT réel afin de le confronter avec le GANTT prévisionnel. Au final, ToolBib a été livré conformément au planning général. Certaines tâches ont pris parfois du retard mais les marges programmées ont joué leur rôle.

Les livrables de l’équipe de Base de Données

En plus du document de vulgarisation décrit précédemment, l’équipe de base de données était en charge de la réalisation du document de spécifications fonctionnelles et du dossier d’analyse.

Le but du document de spécifications fonctionnelles est de réunir exhaustivement toutes les fonctionnalités qui seront implémentées dans un projet. Chaque fonctionnalité est décrite précisément. L'ensemble de ces fonctionnalités définit le domaine, le périmètre d’un projet.

Les fonctionnalités sont regroupées par blocs fonctionnels. Un bloc fonctionnel est une entité logique élémentaire qu'on peut considérer de façon indépendante et qui regroupe plusieurs fonctionnalités. Afin de reprendre l'ensemble du brainstorming, une section du document liste les fonctionnalités qui ont été écartées mais qui pourraient être réalisées dans une version ultérieure.

Conserver les fonctionnalités écartées est, je pense, une bonne initiative à reproduire. Dans le monde professionnel, il faut être fort de proposition et cette section répond parfaitement à cet exercice.

L’intérêt du document est donc de lister les fonctionnalités principales d’un projet. C’est d’autant plus pratique qu’il sert plusieurs fois de support :

Le dossier d’analyse quant à lui répond principalement à un besoin primaire : analyser un projet.

Cette analyse est menée à l'aide d'outils et méthodes du génie logiciel, notamment via UML qui est un langage de modélisation graphique basé sur des pictogrammes.

Dans un premier temps, nous utilisons des diagrammes des cas d'utilisation afin de modéliser le logiciel d'un point de vue global. Dans un second temps, nous utilisons un diagramme de classes afin de modéliser l'application d'un point de vue informatique. Enfin, dans un dernier temps, nous passons du diagramme de classes à un schéma relationnel afin de concevoir la structure de la base de données.

Il constitue la suite logique du précédent document.

Les livrables de l’équipe de développement

En règle générale, à chaque profil d’utilisateur qui se sert de l’application finale correspond un manuel. Dans le cadre du projet ToolBib, il y a deux profils et donc deux documents :

Ces manuels sont indispensables afin d’offrir une explication claire, détaillée et surtout illustrée de comment utiliser l’application.

Le manuel de maintenance est destiné aux développeurs intéressés à connaître la structure et le fonctionnement d’un projet. Que ce soit pour faire de la maintenance ou pour poursuivre le développement de l'application. Il explique clairement les technologies utilisées et pourquoi elles ont été choisies. Il recouvre uniquement les particularités liées au développement de certains modules techniques qui composent une application.

A titre indicatif, je ne suis pas satisfait de la version de ce manuel pour ToolBib. En effet, à mon sens, la présentation des langages et technologies a été bâclée faute d’investissement.

Les livrables de l’équipe Graphisme / Interface

Le document de spécifications supplémentaires pour l’équipe de Graphisme / Interface est un document qui a été rédigé par la responsable de cette équipe et à son initiative afin de clarifier certains points et énoncer des pistes de réflexions.

Deux études ont été menées de front par cette équipe :

En parallèle des études, la charte de navigation a été créé. Il s’agit de modéliser l’enchainement des fenêtres et la navigation de l’utilisateur sur le site.

Deux dossiers explicatifs accompagnent les planches de recherches réalisées :

Enfin, un dossier d’explications des maquettes a été réalisé afin d’illustrer concrètement les visuels du site.

La gestion de projet

Outils

Plusieurs outils ont été mis à disposition de l’équipe afin de faciliter les échanges et la communication entre les membres du projet :

J’ai en effet imposé que chaque membre rédige les documents dans un wiki afin qu’il s’intéresse plus au fond qu’à la forme. Ca permet notamment de régler les problèmes liés à l’utilisation de traitements de texte hétérogènes. Un documentaliste aurait dû s’occuper de la forme une fois les documents validés mais devant le peu d’effectif de l’équipe, nous avions choisis de ne pas définir de documentaliste attitré.

En effet, il avait été convenu lors d’une réunion que chacun contribuerait à la rédaction des documents via l’utilisation du wiki et que chaque responsable de section veillerait à la qualité des documents finaux. Dans la pratique, j’ai beaucoup joué ce rôle de relecteur et correcteur. Pour l’anecdote, M. CHABRIER a pointé le fait que nos documents étaient exempts de fautes et que c’était assez rare pour être signalé.

En outre, un wiki facilite l’aspect communautaire puisque chacun peut participer, corriger, adapter, etc. Malheureusement, ça a très mal fonctionné : non pas que l’outil était inadapté mais l’idée que des étudiants s’intéressent aux documents d'autres était vraiment une utopie. Pour être clair, c’était à chacun son taff... Je mets ce comportement sur le fait que la scolarité continuait et que ce projet n’était pas à temps complet.

En tant que chef de projet, j’ai remonté à mon équipe les décisions ou les remarques du client à travers la publication de compléments d’informations :

Réunions

Des réunions entre les membres de l’équipe ont eu lieu régulièrement. Il s’agit souvent de faire le point. Chaque réunion donne lieu à un compte rendu. L’assiduité est vérifiée par des feuilles de présence. Parfois, afin de préparer convenablement une réunion, un support est créé.

Trois réunions particulières ont eu lieu avec le client. Chacune a donné lieu à une présentation PowerPoint de l’état d’avancement du projet :

Les deux dernières réunions se sont appuyées sur les Xmind suivant :

Un Xmind est une carte conceptuelle. Il s'agit de schématiser ses propos sous la forme d'un graphe. Ce support est très intéressant à utiliser dans le cadre d'une présentation orale et remplace parfaitement le classique Powerpoint.

Conclusion du projet

En fin de projet, des fiches de travail ont été réalisées par chaque étudiant afin de témoigner de leur expérience et de leur investissement au sein du projet. J’avais réalisé une trame. Voici le plan de chaque fiche :

Les documents

Si vous avez été attentif à chaque document, vous avez constaté un encart commun composés des informations suivantes :

Je juge qu’il est important de savoir qui l’a rédigé et qui y a participé ; si les informations qu’il contient ont été actualisées récemment ou pas et à qui je peux le transmettre sans enfreindre la politique de l’entreprise.

C’est une notion que j’ai acquis lors de mon passage à Opendev et à laquelle je voulais sensibiliser les étudiants avec qui j’ai travaillé.

Pour moi, tous les documents étaient « vivants » et chacun pouvait y contribuer.

2011
Jan
21

Le point sur les propriétés CSS

Définition

Une feuille de style en cascade (CSS) est un langage informatique qui permet de décrire la présentation des documents Xhtml, Html et Xml. Concrètement, un ensemble de propriétés est appliqué sur des éléments du document. Si beaucoup de développeurs exploitent chaque jour cette technologie, peu d'entre eux connaissent l'étendue des fonctionnalités que ces propriétés recouvrent.

Historique

La première version de CSS proposait 53 propriétés qui agissaient sur le rendu visuel du document. C'est justement parce que le CSS enrichissait uniquement l'expérience visuelle de l'utilisateur qu'une seconde version a fait son apparition seulement 2 ans après la première. Il s'agit de la 2.1. Forte de 135 propriétés, cette nouvelle version respecte l'accessibilité et l'handicap. L'idée majeure est qu'un même document peut être consulté avec des dispositifs hétérogènes : un écran, un mobile, une télévision, une plage braille, un vidéoprojecteur, etc. Le CSS offre alors aux développeurs la possibilité d'habiller leur document au mieux pour chacune de ces situations. Le développeur jongle alors entre ces propriétés afin d'améliorer l'expérience utilisateur.

Les types de médias

La spécification officielle du W3C définit la notion de type de média. Chaque type de média correspond à un usage de la vie réelle et s'associe à un jeu de propriétés CSS. Au sein du document, il est possible de spécifier qu'une feuille de style s'applique uniquement pour tel type de média. La citation ci-dessous liste les types de média :

all
convient pour tous les appareils ;
aural
destiné aux synthétiseurs de parole ;
braille
destiné aux appareils braille à retour tactile ;
embossed
destiné aux appareils à impression braille ;
handheld
destiné aux appareils portatifs (typiquement ceux avec petits écrans, monochromes et à bande passante limitée) ;
print
destiné à un support paginé opaque et aux documents vus sur écran en mode aperçu avant impression ;
projection
destiné aux présentations en projection, par exemple avec des projecteurs ou des impressions pour des transparents ;
screen
destiné principalement aux moniteurs couleurs ;
tty
destiné aux médias utilisant une grille de caractères fixe, tels les télétypes, les terminaux ou les appareils portatifs aux capacités d'affichage réduites. Les développeurs ne devraient pas utiliser de valeurs exprimées en pixel avec ce type de média ;
tv
destiné aux appareils du type télévision (avec ces caractéristiques : basse résolution, couleur, défilement des pages limité, sonorisé).

Une approche naïve consiste alors à créer autant de feuilles de style que de types de média. C'est d'ailleurs souvent le cas. La solution courante consiste en effet à créer deux feuilles de styles : all et print. Au fur et à mesure de la vie de l'application web, on constate dans le all des propriétés CSS qui font référence à plusieurs types de médias, voire même qui se contredisent.

Vers une proposition d'organisation

Afin de faciliter la maintenance et la factorisation du code, d'optimiser l'application web et de respecter les recommandations du W3C, il est alors intéressant de réfléchir à une meilleure organisation du code CSS. Puisqu'une propriété CSS est ignorée si elle n'a aucun sens pour le type de média courant, il serait alors intéressant de chercher à les regrouper par thème et de les placer dans plusieurs fichiers séparés. Côté serveur, les fichiers CSS peuvent alors être optimisés en retirant la ou les déclarations inutiles. Côté client, le dispositif (Ex. : un navigateur) ne charge et interprète que les fichiers nécessaires qui correspondent à son type de média.

Avant de vous livrer cette organisation, il faut savoir que chaque type de média possède une ou plusieurs caractéristiques. Un type de média peut être :

Relations entre les types de médias et ces caractéristiques
Types de médiasCaractéristiques
continu/paginévisuel/auditif/tactilegrille/bitmapinteractif/statique
auralcontinuauditifsans objetles deux
braillecontinutactilegrilleles deux
embossedpaginétactilegrilleles deux
handheldles deuxvisuelles deuxles deux
printpaginévisuelbitmapstatique
projectionpaginévisuelbitmapstatique
screencontinuvisuelbitmaples deux
ttycontinuvisuelgrilleles deux
tvles deuxvisuel, auditifbitmaples deux

Exemple de la déclaration des feuilles de styles CSS 2.1 dans un document XHTML

Chaque caractéristique est intimement liée à un ensemble de propriétés CSS qu'on associe aux types de média concernés. Chaque type de propriétés CSS se trouve alors dans un unique fichier. Par exemple, toutes les déclarations de background sont dans le fichier visuel.css que seul les types de média visuel chargeront et interpréteront (handheld, print, projection, screen, tty, tv).

<link href="../res/css/auditif.css" media="aural, tv" rel="stylesheet" type="text/css" />
<link href="../res/css/interactif.css" media="aural, braille, embossed, handheld, screen, tty, tv" rel="stylesheet" type="text/css" />
<link href="../res/css/pagine.css" media="embossed, handheld, print, projection, tv" rel="stylesheet" type="text/css" />
<link href="../res/css/tous.css" media="all" rel="stylesheet" type="text/css" />
<link href="../res/css/visuel.css" media="handheld, print, projection, screen, tty, tv" rel="stylesheet" type="text/css" />

Propriétés autorisées dans les types de média auditif

Propriétés autorisées dans les types de média interactif

Propriétés autorisées dans les types de média paginé

Propriétés autorisées dans tous les types de média

Propriétés autorisées dans les types de média visuel

2010
Jul
10

Comment détecter l'encodage d'un fichier ?

C’est une question délicate qui a mérité quelques recherches et une longue réflexion de ma part. Étonnamment, la réponse n’est pas triviale. Pour situer rapidement le contexte, l’idée était de détecter en PHP le charset d’un fichier afin de le manipuler proprement. Delphiki, auteur du site www.u-sub.net, souhaitait effectuer des statistiques, des ajustements et des conversions automatiques dans plusieurs formats et normes des sous-titres qu’il propose.

Réponse

Détecter l’encodage d'un fichier en fonction du contenu est impossible. La fonction PHP mb_detect_encoding() et la commande file -i d'Unix font toutes les deux une supposition. L'avantage de file -i par rapport à la fonction PHP est que l'ordre de détection des charsets a déjà été pensé. Ainsi, le charset détecté est le plus souvent le bon. Si on arrive à déterminer comment les charsets doivent être ordonnés, on peut reproduire le même comportement en PHP à l'aide de la fonction mb_detect_order().

On ne peut pas deviner quel est le charset d'un fichier simplement parce qu'une même représentation binaire d'un caractère en machine peut correspondre à deux caractères différents suivant le charset. Comment alors dire qu'un charset est plus correct qu'un autre ?

Explications par des exemples

Exemple n°1

Prenons par exemple, le ANSI et l'UTF8.

J'ai un fichier que j'ai enregistré avec mon éditeur de texte avec un charset ANSI. Mon script peut très bien dire qu'il s'agit d'un fichier UTF8 sans BOM. Effectivement pour lui, tous les caractères du fichier correspondent au charset UTF8 sans BOM même si le fichier n'a pas été enregistré réellement dans ce format. Il fait une supposition. Il ne peut pas faire autrement ! Cette information n'est pas présente dans les méta-données du fichier.

On peut effectivement affiner cette supposition. Il suffit de regarder si tous les caractères appartiennent au charset ANSI avant de vérifier l'UTF8. Ça fonctionne dans ce cas simplement parque l'UTF8 est un dérivé de l'ANSI.

Exemple n°2

Prenons maintenant deux charsets totalement différent mais recouvrant le même nombre de représentation de caractères : 2 (c'est pour illustrer). Dans le premier, le caractère E est codé en 0000 et dans le second 0001. La seconde lettre est le X. Comment déterminer quel est le charset utilisé pour ce fichier ? Bon courage.

Charset n°1
Représentation binaireLettre
0000E
0001X
Charset n°2
Représentation binaireLettre
0000X
0001E

Prenons ce contenu binaire d'un fichier quelconque : 00000001

C'est seulement après conversion avec la table de caractère du charset que le texte apparait graphiquement ; et c'est seulement à ce moment là que le lecteur peut dire s'il a du sens ou pas.

Après conversion avec le charset 1, on obtient EX.
Après conversion avec le charset 2, on obtient XE.

Avec le second charset, le contenu ne veut plus rien dire mais pourtant les représentations binaires des deux caractères étaient valides pour le charset2.

Comment s'en sortent les systèmes d'exploitations ?

Maintenant qu'on voit le fond du problème, comment font les OS s'ils n'ont pas l'information ? Il s'appuie simplement sur la localisation de l'utilisateur. Inutile de chercher une correspondance avec un charset chinois si l'utilisateur est français. L'OS fait une hypothèse.

Pour insister sur le fait que cette notion est un joyeux bordel. Concaténons, par exemple, deux fichiers UTF8 avec BOM, on se retrouve avec des bytes de déclaration de l'encodage au milieu du fichier résultat... C'est bêtement ce que fait la commande COPY sous Windows. Quelque part, ça revient à dire que le même fichier est encodé de deux manières différentes (la même pour cet exemple, mais pas forcément). Bref ; et comme chaque OS gère ça à sa sauce...

Conclusion

Que devrais-faire, selon moi, une classe confrontée à ce problème ? Laisser le choix au développeur de préciser le charset des fichiers qu'il manipule pour conserver le sens du texte. A défaut, choisir un charset compatible avec l'ensemble des caractères du fichiers pour faire le traitement souhaité et tant pis pour le développeur si le texte ne veut plus rien dire...

A lire aussi :

Notes :

2010
Apr
19

Koyöt Team

Page d'accueil du site de la Koyöt Team J'aime tout ce qui touche à l'informatique. Vous ne serez pas surpris d'apprendre que cela recouvre également le jeu vidéo. Ainsi, je joue régulièrement à Team Fortress 2.

J'ai d'ailleurs une team. Il s'agit des Koyöt. Nous n'avions jusqu'alors pas réellement de site pour nous organiser. C'est maintenant chose faite. La partie publique est pour le moment plutôt légère mais comporte de nombreuses jokes que je vous laisse découvrir. La partie privée constitue un espace réservé aux membres de notre équipe. Elle permet de gérer les membres, les différentes line-up et les nombreux événements auxquels nous participons. Cette année, nous nous inscrivons dans un tournoi officiel : la ligue.

Pour information, ce site est une application web de taille moyenne (~ 70 pages) réalisée avec Atom, Xml, Xhtml, CSS, PHP, MySQL et sans Framework.

Page suivante »