Je suis de retour!

Ce billet simplement pour discuter du vaste sujet d’automatisation.
L’automatisation c’est simplement modéliser assez finement un processus afin de le rendre plus simple, plus accessible et plus rapide en exécution. Il en naît une rationalisation du processus en question ainsi que -lorsque c’est bien fait- un gain en rapidité de traitement et une facilité à propager ce processus.

Ma réflexion a donné naissance à un concept d’automatisation simple : ASMR
Adaptation / Submission / Monitoring / Reporting

=> Ne sont-ce pas là des besoins que l’on rencontre tous les jours ? Pourtant, une approche si simple n’est pas adoptée par tous ! Certains se compliquent la vie à mon goût. Rappelez-vous que dans les 80% des métiers de l’informatique de type service logiciel, on part sur ces phases-là. ASMR !

Je m’explique, si un processus est connu pour sa complexité, et sa difficulté à être appréhendé, c’est qu’il lui manque une « newbie-oriented frontend ». Si on ne comprend pas un sujet c’est qu’il est diffus et travaille avec beaucoup de concepts. On ne peut pas tout comprendre et maîtriser. Mais a-t-on besoin de tout maîtriser ?
Certains processus ne sont importants et utiles que parce qu’ils donnent des reporting utilisables. Ce sont ces reporting qui sont des résultats effectifs pas le processus en soit. Alors pourquoi ne pas le masquer derrière un bouton « Run », cliquable par n’importe quel collaborateur ?

Mais comment procéder ?

Tout part d’une bonne compréhension. Il est important de toucher au processus dans ses entrailles. Comment faire ? Des entrevues avec les key-users, ou devenir un key-user est très utile. Ensuite, il faut bien sûr dimensionner les phases, identifier les états… bref tout ce que l’on sait faire dans notre métier de consultant ou d’AMOA ou autre.

Mais plus simplement, ne pourrait-on pas trouver une approche générique ?

La mienne est la suivante :

• J’identifie les tâches à produire, les E/S, le degré de reporting nécessaire, les goulots d’étranglement… bref je comprends le process et je cherche le superflus et les besoins
• Je crée un lanceur de tâches multi-threadé. Ne nécessite que très peu de temps en développement.
• Je crée des tâches pouvant être intégrés dans des templates (XML pour la description). Ces tâches sont exécutables et sont regroupés selon 4 groupes Adaptation, Submission, Monitoring, Reporting

=> ASMR est né !

Le concept est sympa mais par quoi commencer ?
1. Identifier le processus de A à Z
2. Le décomposer selon A, S, M, R
3. Intégrer les tâches définies en les optimisant si possible selon leur boîte d’appartenance (ASMR toujours !)
3.1 Gestion d’E/S => Adaptation (A)
3.2 Soumission d’une tâche d’exécution (je parle d’une tâche générique pour le moment) => Submission (S)
3.3 Suivi de l’état de cette tâche => Monitoring (M)
3.4 Analyse des résultats de la tâches et soumission des données obtenues dans un moteur de reporting => Reporting (R)

4. Intégration
4.1 On obtient un workflow d’automatisation
4.2 Dans notre processus initial, on a des états et des conditions à respecter.
4.3 On dégage des « domaines » pour construire des plugins respectant les points du §3
4.4 Ces plugins doivent pouvoir être ajoutés/retirés/mis à jour
4.5 Un plugin se construit selon les points suivant
4.5.1 Développement d’un formulaire d’entrée
4.5.2 Conditionnement de l’exécution
4.5.3 Moteur d’exécution fourni par l’outil appelant les plugins (pool de threads, batch pour calculs, queues d’exécution, …)
4.5.4 Monitoring fourni par l’outil appelant donc nécessité de donner des KPIs (indicateurs, déclencheurs…)
4.5.5 Tous les plugins doivent avoir la même forme pour garder de la simplicité que ce soit dans le front end (GUI du plugin).

5. Constuction de l’IHM de l’outil
5.1 l’IHM doit être simple pour toutes les vues pour tous les plugins
5.2 l’IHM doit fournir des formulaires simples, courts autant que possibles
5.3 l’IHM ne doit pas afficher trop d’information. Souvenez-vous du KISS (Keep It Simple Stupid!)
5.4 l’IHM doit founir un état de progression et des KPIs simples, sélectionnables
5.5 Le passage d’une vue plugin à une autre doit être simple (navigateur sur le côté)
5.6 La partie reporting doit pouvoir afficher des graphes et aider l’utilisateur à construire des rapports personnalisés

6. Coût d’un tel outil
6.1 Le moteur ASMR doit être assez générique pour être réutilisable à volonté !!! Restons simples et orientés plugin
6.2 Les plugins doivent aussi être génériques ! Décomposez tant que vous le pouvez. Si ça sert de faire des sous-étapes. Même s’il s’agit de gérer la création de répertoire ou juste de gérer des soumissions de jobs batch ou d’ouvrir un fichier Excel pour lire une information particulière. Ce n’est pas une API ! Mais un plugin !
6.3 L’appel d’un processus particulier passe pas sa description dans un fichier XML (par exemple).
6.4 Chaque étape appelle UN plugin avec des arguments et signifie des dépendances vis-à-vis des étapes la précédant ou son indépendance et sa possibilité d’être joué en parallèle.

NB : Il faut pouvoir récupérer un déclencheur pour les étapes suivantes dépendantes de cette étape.

6.5 Il est important de faire des templates de fichiers de descriptions et de prévoir une IHM dédiée pour les instancier avec des données réelles

=> CONCLUSION
Au final, on se retrouve avec un coût « important » pour la coquille de l’outil mais pas pour les plugins !
Les plugins sont développés au fur et à mesure selon un formalisme simple (objet!) et identique pour tous (besoin d’une interface stricte à implémenter par chaque plugin).
Si votre plugin fait plus de 2 actions, c’est qu’il faut le découper !

Les processus ou sous-processus sont ensuite décrits dans des fichiers XML. L’IHM est mise à jour grâce aux méthodes graphiques des plugins. On peut imaginer que les plugins fournissent des composants graphiques par simple appel à une fonction que l’on peut placer dans une zone d’accueil pour les plugins.

Je compléterai ceci avec un exemple concret dès que possible pour vous montrer qu’un peu de développement interne dans une SSII par exemple peut rapporter pas mal de budget en respectant cette approche ! Ca marche pour moi pour donc pourquoi pas vous ?

En bref, un éditeur de code en ligne… Prometteur.

Bonne lecture

Lecture manuelle des rôles et mise en cache

Dans le développement d’application nous sommes souvent amenés à traiter du « qui a droit à quoi ». La solution la plus simple est l’utilisation de la méthode User.IsinRole(). Je ne vais pas m’étendre sur ce point mais plutôt sur la mise à disposition de ces rôles à votre application. Nous allons voir dans cet article comment intégrer les rôles de l’utilisateur et les mettre en cache.

Je vous souhaite donc à toutes et à tous une excellente année 2008.

A+

L’annonce originale fait la part belle à l’intégration du noyau GNU/Linux 2.6.21.5. 14 ans après la naissance de cette merveilleuse distribution, ce nouveau noyau apporte donc des performances avancés concernant les fonctionnalités comme le support des volumes SCSI ou ATA RAID, le support du SATA, le RAID applicatif, le LVM (Logical Volume Manager) et des systèmes de fichiers cryptés.
Aussi, le support du noyau pour X DRI (Direct Rendering Interface) apporte avec lui les possibilités de prendre en charge les fameuses « high-speed hardware accelerated 3D graphics ».
Le volumineux XFree laisse sa place à X11 de X.org, ce qui laisse espérer une maintenance facilitée et accélérera considérablement le développement de nouvelles fonctionnalités pour X (comme les effets de transparence sur les systèmes de fenêtrage, même si c’est loin d’être nécessaire).

Cette annonce a été reprise sur LinuxFR de manière bien sympathique en nous « invitant à une fête »… Ils ajoutent même la liste des invités :

Pour cette sortie, notre ami a donc invité:

* Ses copains KDE 3.5.7 Xfce 4.4.1, qui s’occuperont de la déco.
* HAL (Hardware Abstraction Layer) qui s’occupera de la logistique des autres invités comme les périphériques USB.
* Son nouvel ami le noyau 2.6.21.5. Plus branché que ça, on ne fait pas.
* Un autre invité de marque est le petit X.org (avec tous ses petits modules) qui a remplacé le gros XFree.
* L’indispensable GNU C Library 2.5 et le non moins fidèle gcc-4.1.2.
* Les très branchés Perl 5.8.8, Python 2.5.1, Ruby 1.8.6, Subversion 1.4.4, git-1.5.2.2, mercurial-0.9.4, Qt designer and KDevelop.
* Firefox et Thunderbird 2.0.0.4
* Quelques invitations ont aussi été données à des applications Gtk+ : Pidgin 2.0.2, Gimp 2.2.15, Gkrellm 2.2.10

Attention, lecture conseillée !

Voici simplement des liens intéressants :
–> page de téléchargement des différentes moutures de VS2008

–> Annonce sur le blog de Scott Guthrie

Amusez-vous bien !

Pour les curieux, voici la présentation éditeur :

Présentation

Après avoir rappelé l’importance de principes fondamentaux tel celui de la défense en profondeur, cet ouvrage explique comment sécuriser une application professionnelle en PHP et MySQL à tous les niveaux, depuis la configuration du serveur jusqu’à la protection de la base de données MySQL, sans oublier toutes les vulnérabilités propres aux sites web dynamiques basés sur des langages de script.

Maîtriser la sécurité pour les applications en ligne

De nouvelles vulnérabilités apparaissent chaque jour dans les applications en ligne et les navigateurs. Pour mettre en place une politique de sécurité à la fois efficace et souple, sans être envahissante, il est essentiel de maîtriser les nombreux aspects qui entrent en jeu dans la sécurité en ligne : la nature du réseau, les clients HTML, les serveurs web, les plates-formes de développement, les bases de données… Autant de composants susceptibles d’être la cible d’une attaque spécifique à tout moment.

Une référence complète et systématique de la sécurité informatique

Écrit par deux experts ayant une pratique quotidienne de la sécurité sur la pile LAMP, ce livre recense toutes les vulnérabilités connues, les techniques pour s’en prémunir et leurs limitations. Très appliqué, il donne les clés pour se préparer à affronter un contexte complexe, où les performances, la valeur des données et la complexité des applications pimentent la vie des administrateurs responsables de la sécurité.

Au sommaire

* Risques liés aux applications web
o Introduction à la sécurité des applications web
o Vulnérabilités des pages web
o Formulaires et téléchargement ; valider les données
o Cookies et sessions
* Mesures de sécurité pour PHP
o Installation et configuration de PHP
o Intégrité des scripts PHP
o Risques liés aux bases de données
o Vulnérabilités des base de données
o Mesures de sécurité pour MySQL
* Mesures de sécurité pour les technologies connexes
o Mesures de sécurité côté serveur
o Techniques de sécurisation des applications web
o Mener un audit de sécurité
* Annexes
o A. Fonctions de sécurité et caractères spéciaux
o B. Sauvegardes
o C. Ressources web

A force de me ruiner les yeux à analyser en debug les sources de cet IDE formidable, j’ai décidé de chercher des infos sur des blogs ou autres sources d’infos (au passage, je n’ai pas trouvé de source navigable), j’ai trouvé sur DotNetGuru, plus précisément sur le blog de Laurent Desmons un lien vers un ebook gratuit en anglais (of course !) : Dissecting a C# Application – Inside SharpDevelop. Ce livre passe en revue le code et les méthodes de développement employés pour l’élaboration de l’outil.

C’est un régal. Et une belle partie est consacrée à la coloration syntaxique et « l’intellisense » (l’auto-complétion du code et l’inspection des méthodes).

Bonne lecture