samedi 31 octobre 2009

Décisionnel vs gestion : définir une application décisionnelle.








Où est la frontière entre une application décisionnelle et une application de gestion? . Qu'est ce qui peut définir une application décisionnelle ?. Voici les questions posées, place aux réponses.

Dans le cadre de mon travail, je suis confronté à ces deux familles d'application et je note une confusion dans leur classification. La question n'est pas anodine car elle conditionne souvent le choix des technologies à utiliser : soit une plateforme décisionnelle, soit un simple framework. Les conséquences ne sont pas neutres.

Les concepts qualifiant le plus souvent le décisionnel sont:

  • La source des données
  • Le caractère multidimensionnel
  • Les restitutions
  • Les simulations
La source des données.

La présence d'une multitude de source de données, hétérogènes n'est pas à lui seul un critère discriminant. Par contre la collecte de type aspiration ('pumping') des données qui seront contrôlées puis injectées dans un entrepôt de données est un élément fondateur d'un système décisionnel. La donnée sera intégrée puis historisée dans un processus qui fournira de la 'traçabilité' sur la donnée. Un vrai entrepôt doit permettre de suivre tout le cycle de vie de la donnée.
Cette notion de 'pumping' s'oppose à la notion de 'mashup' qui elle, n'intègre pas la fonction de prise en charge de la donnée. Dans le décisionnel, la granularité n'est pas la même que dans une application de gestion. Souvent le directeur financier va manipuler des agrégats en Keuros. Dans le même ordre d'idée, le processus d'intégration dans l'entrepôt sera tolérant sur la présence ou le format d'une donnée, alors que pour une application de gestion, la donnée doit etre exactement calibrée et présente.


Le caractère multidimensionnel.
Le cube avec un système OLAP est l'élément clé du décisionnel. Un tel système offre la possibilité de définir des axes d'analyse, à commencer par l'axe temporel
A partir de là, l'analyste pourra explorer son cube dans les dimensions souhaitées.
Un requêteur 'universel' viendra compléter la boite à outil mise à disposition.
C'est l'utilisateur final qui choisit la requête et son domaine et non plus le concepteur de l'application. Tel un peintre qui mélange ses couleurs à partir d'un nuancier: l'entrepôt de données.

Les restitutions.

L'utilisateur final doit pouvoir choisir son format de restitution à partir d'une liste de composant . Cela peut aller du radar en passant par l'histogramme en 3D jusqu'au simple fichier csv.

Un tableau de bord aussi sophistiqué qu'il soit n'est pas le propre d'une application décisionnelle. L'utilisateur doit pouvoir choisir ses indicateurs KPI, le format d'affichage etc.
Une application de statistiques ne relève pas non plus forcement du décisionnel, elle peut etre 'immunable' sans interaction possible.

Les simulations.
Enfin, la simulation est une fonction importante demandée par les décideurs. Comment va évoluer le marché ? , quelles seront les projections dans un an ou deux ?. Il faut pour répondre à ces questions, embarquer dans le système toutes une panoplie d'outil de modélisation mathématiques.


Ainsi le critère de classification repose en grande partie sur le type de l'utilisateur final. Dans le cas du décisionnel ,c'est l'utilisateur qui compose son application, il y aura autant de forme d'application que d'utilisateur. Le nombre d'utilisateur ayant les compétences pour tirer parti d'un système décisionnel est forcement limité.

En conclusion: Les éditeurs du décisionnel cherchent à prendre des parts de marché aux éditeurs traditionnels et réciproquement : voir l'exemple de SAP qui propose du décisionnel dans son ERP. Le parc d'application décisionnelle doit normalement être marginal par rapport à celui des applications de gestion.

vendredi 30 octobre 2009

Rails: contourner un problème par l'utilisation de la méthode send.


Dans le cadre d'utilisation d'association de type 'belongs_to' avec clés étrangères absentes.


Comment par simple baquette magique remplacer une dizaine de blocs identiques par un petit bloc de 4 lignes ?














Voici l'exposé du problème :j'ai une table principale Projet qui utilise plusieurs clés étrangères pour afficher des libellés .

class Projet < ActiveRecord::Base
belongs_to :moe
belongs_to :moa
belongs_to :domaine
belongs_to :techno
belongs_to :filiere
belongs_to :didev
belongs_to :diprod


Parfois, la clé étrangère n'est pas renseignée et cela provoque une erreur dans l'affichage de l'objet principal. Ce cas arrive pour ma part, principalement dans deux situations:


  • En phase de développement: je n'ai pas encore finalisé les écrans permettant de rattacher la table principale avec ses tables associées (à faire sous forme de liste déroulantes)
  • Par choix fonctionnel, la valeur ne doit etre servie. Dans ce cas, il est toujours possible d'ajouter une entrée factice dans la table (non satisfaisant)
La solution 'brute' consiste à tester avant d'afficher la validité de la clé étrangère , et de répéter ce test tout le long de la vue.
Dans l'illustration suivante, je montre comment factoriser son code :
(cliquez sur l'image pour agrandir)


L'astuce consiste à remplacer l'appel d'une méthode par l'envoi d'un message à la methode 'send' de l'objet.

Dans cet exemple, j'appelle une fonction avec trois paramètres:
L'objet (projet)
Le nom de la classe decrivant les libellés (nom de la table au singulier)
L'attribut à afficher
Je procède à un appel imbriqué de méthode.





Ces trois formes d'appel produisent le même résultat :
  • mon_projet.methode
  • mon_projet.send('methode')
  • mon_projet.send(:methode)
Dans le cas présent, en raison de l'utilisation d'une clé étrangère je suis obligé de passer par une syntaxe imbriquée:
mon_projet.send('objet_libelle').send('attribut_a_afficher')

Et en bonus, comment afficher une liste déroulante à partir d'un table libellé ?

Par une simple ligne :
<%= select(:projet, "domaine_id", Domaine.find(:all).collect {|p| [ p.libelle, p.id ] }, :include_blank => true) %>

Good hacking!

une bonne idée pour une table de jardin

mercredi 28 octobre 2009

Les modèles gros contre les maigres


Le titre est racoleur comme cette illustration que j'ai volontairement floutée.
(L'originale est disponible sur google image)

Rails est un framework MVC : modele/view/controleur

La philosophie de Rails est aussi dans la re-factorisation du code, de manière à éviter d'avoir des gros contrôleurs. Ce défaut est source de toutes les difficultés : maintenance , réutilisation du code et évolution de l'application.


J'illustre mon propos par un exemple de projet qui gère un portefeuille applicatif. Ces applications sont de différentes technologies ,et on doit pouvoir filtre les applications sur leur type de technologie :









Dans une première version , jamais mis en dur dans le contrôleur les options de filtre possible.

Après modifications , j'arrive à :
Un modèle plus 'gros':


Ce modèle contient toute la logique de sélection (Select SQL)
Il ne faut pas hésiter à faire des méthodes 'find' taillées sur mesure.











Le contrôleur:


Le contrôleur est allégé pour ne contenir que la partie 'métier' du traitement. Dans cette solution , non seulement les tests 'en dur' ont disparus mais en plus l'ajout d'une nouvelle catégorie ne nécessitera aucune modification de code.








La vue est elle aussi simplifiée:

D'une manière générale, il faut éviter de mettre trop de traitement dans les vues. Cela rend l'application, très difficile à maintenir et le code inséré dans les vues est assez contraignant à écrire.












Où se trouve alors tout le traitement qui génère l'affichage de la console de bouton radio ? . Car malheureusement, il faut bien qu'a un moment donné une méthode prenne en charge :
a) Afficher toutes les options
b) Pré-selection de l'option 'cochée'.
Cette méthode va etre placée dans les 'helpers' de l'application qui prendra cette forme:


Je n'ai pas forcement le bon style d'écriture du code. Ici on fabrique le HTML utile pour les boutons radio.
Cette méthode n'est possible que parce ma liste des options était contenue dans une table.






En résumé : toujours re-factoriser son code : DRY : don't Repeat Yourself ou Duplication is Evil . Dans mon exemple la logique de la gestion des options est dans le helper et que dans lui. Le resultat donne un système qui evoluera sans modification à apporter au code.
En conclusion je me pose la question suivante : Pourquoi doit on re-factoriser dans les langages proceduraux et ne pas le faire dans les langages fonctionnels ?.

mardi 27 octobre 2009

Etherpad avant googlewave


J'ai réalisé une deuxième réunion avec le site collaboratif Etherpad.
Cette audio-conférence était complétée par une prise de note en direct sur le site.
Etherpad préfigure ce que sera googlewave mais à la différence de celui ci, il est ouvert à tous. Un simple mail permet d'inviter les personnes sur le document. Pas besoin de compte ou de mail spéciaux.
A sa connexion, chaque contributeur se voit attribuer une couleur de police, il peut compléter son nom de connexion.
La frappe est en direct et chacun peut taper en même temps. Ainsi, une personne repasse souvent derrière moi pour corriger mes erreurs de dyslexie :-))).

Pour qu'une réunion de cette sorte se passe bien, il faut si possible prévenir les invités à l'avance afin de vérifier leur bon accès au site. Puis, commencer par déposer sur le site l'ordre du jour de la réunion, qui servira ainsi de fil conducteur.

Il faut prendre l'habitude de taper en parlant tout en écoutant. C'est assez difficile, des entrainements réguliers s'imposent. Les timides n'osent pas écrire, aussi le rapporteur aura à taper les propos d'un autre , tout en essayant de comprendre l'argumentation. Dans un monde idéal , chacun doit prendre en charge sa partie.
A la fin de la réunion, il suffit d'exporter le texte et le compte rendu de réunion est fait.
Avec Etherpad , il est possible d'inclure des copier/coller de documents externes, mais pas de photos ou de schémas (googlewave:oui ) .
Attention, les documents sont publics et ils ne sont pas protégés ni indexés. Une version entreprise complète le dispositif dans ce sens.

Faire des bulles de navigation sur youtube


En remplaçant : le mot 'watch' par warp.swf dans une url de youtube on obtient le système de navigation ci-contre.
Concrètement la manipulation revient à prendre l'url d'une vidéo youtube comme celle-ci :
'http://www.youtube.com/watch?v=6XiMfpiUFX8&feature=player_embedded' et à remplacer watch par warp.swf pour avoir ceci :
'http://www.youtube.com/warp.swf?v=6XiMfpiUFX8&feature=player_embedded'

Il est possible alors de 'voyager' de bulle en bulle parmi les vidéos.

lundi 26 octobre 2009

Golf : Le trou en UN de tous les temps.

La balle rebondit 4 fois sur la surface de l'eau , puis roule vers le drapeau ,revient en arrière et tombe dans le trou ! Vijay Singh a réalisé un coup d'anthologie: a voir ici



Ce coup est-il vraiment un 'coup de chance' , A mediter: plus je m'entraine ,plus j'ai de la chance.

Ce n'est pas non plus un trucage (autre angle de vision) , ce coup est réalisé lors d'un entrainement :