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 :

dimanche 25 octobre 2009

Soirée entres potes

La semaine derniere, à l'initiative d'alexandre , nous nous sommes retrouvés le soir dans un restaurant (près de nation). Je vais essayé de faire le compte rendu à la façon des soirées Perl mongueur Paris.
La voix du secrétaire (eric) qui s'est permis de copier-coller quelques messages sur twitter

Présents à la réunion, en fonction de la place autour de la table :

  • Casimir,
  • Jean-pascal,
  • alexandre,
  • Eric
  • Absent excusé : Arnaud

Nous avons mangé des cotes de boeuf accompagnées de gratin dauphinois. En désert: Casimir à pris un gateau de riz sous une boule de glace et son coulis au miel , JIPAI un fondant au chocolat et moi un clafoutis aux pommes et au beurre de caramel salé.Nous avons bu de la bière et de la bière. Puis nous avons conclu le repas par des cafés.

Nous avons parlé de photos , des enfants ,du travail et très peu d'informatique.

(à mon grand regret : je voulais parler de base de données vectorielles, d'erlang mais l'attention était difficile à maintenir....) .

Alexandre avait amener son nouvel appareil Nikon D700 ,le même que celui de casimir. Casimir à fait 50 photos pendant la soirée.




Casimir possède cette appareil depuis le mois de janvier, il a fait 90.000 photos avec (un compteur interne tient le décompte) : Cela fait 300 photos par jours et il en garde 20 % (60) . Le résultat du calcul donne un nombre important de disque dur nécessaire pour stocker les images. Une images est au format 'RAW' qui occupe 10 Mo d'espace disque. Ce format permet d'utiliser un parseur jpeg différent du parseur natif de l'appareil (qui est très bon du reste) . Celui ci est équipé de 2 microprocesseurs, cela permet l'affichage instantané des clichés. Les LEICA numériques ou les CANONS n'ont pas cette puissance. Cet appareil est limité par la vitesse de transfert des cartes mémoires. Le comble de la sophistication est de pouvoir 'simuler' une marque de film argentique (tri-x ,agfa etc.)
IMAGE_024.jpg


8831_1262971611670_1151112691_30836059_2319210_n

8831_1262971891677_1151112691_30836061_1610155_n

8831_1262972571694_1151112691_30836065_2209734_n


samedi 24 octobre 2009

Twitter: quelques bonnes adresses

Je tweete , tu tweetes , il tweete ....
J'étais septique sur l'utilité de cet outil. Envoyer un message de 140 caractères pour expliquer ce que l'on est en train de faire ? . Bof. J'ai essayé un petit peu le service et depuis je le trouve très intéressant et utile. Grâce à ce petit truc, je peux suivre l'orientation des centres d'intérêts de personnalités de mon choix. Cela va de la collègue de travail au manager du projet Rails, ou de la vedette trucmuche.
Je peux signaler à mes suiveurs les liens qui retiennent mon attention ou de signaler des nouveaux posts sur le blog.
Hélas l'envoi de SMS ne fonctionne en france pour twitter.

Quelques bonnes adresses :
  • Pour envoyer des photos: twitpic.
  • Pour préparer ses envois (scheduler) : twuffer.
  • Un site pour obtenir le guide de survie ,ce guide permet d'apprendre à personnaliser le fond de page.
  • Un site qui indexe les tweets. tweepz.
  • Un moteur de recherche pour les tweets: crowdeye.
  • Un autre moteur multi-site (twiter-facebook-scribd-wikipedia: Mr Sapo.
A méditer toutefois : lu sur le blog Le Post.

----------------------------------------------------------------------------------------------------------------------------------------
Un sondage du site Retrevo.com l'affirme, près de 36% des moins de 35 ans se précipitent sur Facebook ou Twitter après du sexe. Histoire de raconter ses exploits ? Element notable du sondage : cela concerne très majoritairement les hommes. Tiens, bizarre, bizarre...
----------------------------------------------------------------------------------------------------------------------------------------

vendredi 23 octobre 2009

Modèle SOA vs ROA

Deux mondes s'affrontent : d'un coté l'informatique en Entreprise de l'autre l'informatique d'Internet destinée à l'utilisateur final.
La frontière n'est pas étanche ,et parfois des technologies se diffuse de part et d'autre, comme par exemple le web 1.0 et les services de messagerie.

Ce schémas illustre mon propos:


soaroa2


Il y a quelques années , le modèle SOA (AOS) était vu comme le modèle qui répondait au mieux au mouvement de la général de mondialisation (globalisation - restructuration ) . Une entreprise X rachetait une entreprise Y , elle devait pouvoir intégrer le système d'information de Y à moindre coût.
Dans un monde SOA , le service informatique 'rentre dans le rang' , il ne dicte plus ses lois (organisation, processus ) au reste des services.
Hélas les retours sur investissement est long ,difficile et hasardeux.

De l'autre coté du fossé , on trouve un autre monde en perpétuelle agitation avec des effets de mode, des coups de poker. Internet est massivement orienté 'ressources' (uri/url ). Plus le système est léger mieux c'est ! (KISS : Keep It Simple and Stupid).

On trouve donc deux philosophie : une prônant les services ,l'autre les ressources :

soavsroa1

L'émergence des frameworks légers (en complexité pas en fonctionnalité offerte) comme Rails ou Django dans un premier temps sur Internet et maintenant dans l'entreprise est un signe fort qui n'est pas neutre dans le choix des statégies à mettre en place.
Les applications RestFull (à base de CRUD , AJAX ) sont les seules à pouvoir offrir à l'entreprise un ROI rapide et sûr. Elles evitent les effets tunnel d'un projet qui sera terminer et qu'il faudra immediatement modifier pour plaquer aux évolutions. Les entreprises doivent se préparer à la vague déferlante du WEB 2.0 dans l'entreprise et commencer à se familiariser avec le SAAS (cloud) qui est massivement SAAR (R comme ressource) .
(ici un comparatif Rails/django ). La cote de popularité des langages illustre mes propos : Javascript à le vent en poupe , ainsi que Python , Ruby et PHP (qui n'a pas encore son killer framework ), alors que JAVA piétine voir le The TIOBE Programming Community index.

lundi 19 octobre 2009

La méthode de DHH pour :Travailler moins pour en faire plus


Le créateur de ruby on Rails David Heinemeier Hansson (DHH) et son ami Jason Fried co-fondateur de la société 37 Signals' publient un livre : Rework.

Ce livre s'adresse aux personnes voulant se lancer dans la création d'entreprise de type start-up.

Je n'ai pas lu ce livre mais je connais bien ses auteurs: ils se sont illustrés dans la mise en pratique de méthodes de management et de gestion de temps. Je suis admiratif des personnes qui peuvent à la fois gérer leur société , travailler sur des projets et trouver le temps d'écrire un livre.

Je vais présenter deux méthodes que j'utilise : GTD et inbox zero.



DHH est un adepte de la méthode GTD: Getting Things Done, the art of stress-free productivity ("Faire les Choses, l'art de la productivité sans pression") .
J'applique depuis un an cette méthode adaptée à ma sauce. Le principe est simple :
  1. Lister toutes les taches entrantes
  2. Réaliser immédiatement les taches qui demandent moins de 15 minutes (à adapter).
  3. Ventiler les autres taches par thème ou par action ('a lire' , 'a faire avant..' , 'budget' etc ) EN indiquant la prochaine action à réaliser pour faire avancer la tache (ex : contacter Mr X, 'tester la fonction y')
  4. Parcourir régulièrement ses listes de tache.

Voila pour les principes. La mise en pratique demande un travail de reprise de stock important.
Il faut aussi choisir le support: Cahier, site web , fiches etc .
j'ai commencé par un cahier avec des fiches mais sans succès. Depuis j'ai développé une application Rails qui me permet de gérer des taches prédéfinies comité , réunion , budget etc. en regard de projets prédéfinis . L'unité de travail est la journée, et mais l'affichage est regroupé par semaine.


L'application est sur mon pc portable et elle est accessible par tous depuis le wiki du secteur quand mon portable est connecté.

ProjetXX
COPIL le matin- voir planning
2009-10-14 2009-10-14 Fermé par le système eric


ProjetYYY
Rappel audit anssi recuperation du code 2009-10-19 2009-10-19 Ouvert eric


PROJETZZ
Réunion architecture applicative et lotissement
2009-10-16 2009-10-16 Fermé par le système eric


BUREAU
Rappel visite du ..
prevoir une fiche. 2009-10-19
Ouvert eric


MISSION
Important deplacement le 20/11 à clermont horaires billets 2009-10-19 2009-10-23 Ouvert eric


PROJETXXX
Réunion Portail de l'élu par audio et support Avec bordeaux et clermont



DHH et les gens de google pratiquent la méthode 'inbox zero ' : je ne suis pas encore parvenu à maitriser parfaitement mes mails. J'ai organisé ma boite en sous dossier 'a repondre' , 'en attente d element' , 'maj wiki' puis un répertoire par projets gérés par GTD. Le principe fondamental est le suivant : "il ne faut pas seulement prendre une commande d'hamburger, il faut aussi le fabriquer" . Cette phrase est extraite d'une conférence donnée par un responsable Google qui doit faire face à des avalanches de mail (300/j). En clair , il ne suffit pas de lire le mail, il faut le traiter. Pour cela il faut éviter la dispersion en relevant sa boite à des moments précis et non pas au fil de l'eau. Le matin en arrivant, je relève mes mails, je les traite ou je les ventile , puis je fais le tour des équipes pour demander des précisions ou pour dire simplement 'bonjour'.

Concernant le management. Pour un geek, le passage d'une activité technique à une activité de management est un exercice difficile. J'ai donc consulté les RFC relatives au sujet. L'expérience de Joel on the sofware est riche d'enseignement. Il distingue 3 types de management :
  • La méthode militaire
  • La méthode 'machine à café' (cours d'économie 101)
  • La méthode basée sur l'identification de la personne à l'entreprise.
(il existe quelques traductions françaises des articles) .
-Pour résumer la méthode militaire en deux mots:ordre et discipline
- La méthode machine à café: je mets une piece et tu travailles

La dernière méthode est plus intuitive: exposer la stratégie de l'entreprise pour dégager des objectifs connus et compris par tous.

Je reviendrai dessus dans un autre post.






samedi 10 octobre 2009

Le protocole HIP : un pas de plus vers la mobilité

Actuellement, TCP/IP donc (Internet) connait deux espaces de nommage universellement reconnus : Le DNS et les adresses IP. Mais de plus en plus les machines changent d'adresse IP pour des raisons diverses dont :
  • L'utilisation de serveur DHCP .
  • L'usage des portables dans l'environnement du travail et de la maison.
  • L'utilisation dans des spots wifi.
  • L'utilsation d'un portable loin de son domicile
Tous ceci complique l'administration des équipements réseaux dont les pare-feux.

Avec HIP , la machine et plus précisément l'interface réseau est authentifiée. Le protocole utilise pour cela un système de clé comme pour le protocole SSH.
Mais contrairement au protocole SSH, HIP s'intercale dans la pile TCP/IP entre la couche IP et les couches transports TCP/UDP. Si les deux extémités utilisent HIP , il est alors possible de monter un tunnel ipsec en mode ESP/ BEET (Bound End-to-end Tunnel). Le serveur et le client ne se connaissent que par leur HIT (Host identify Tag) et les adresses IP ne sont plus significatives.

lien HIP ici. et la RFC 4423 ici