De la génération du code à la génération des applications (1/3)

Au début des année 2000, lorsque j'ai commencé la programmation, RAD vivait sa plus belle époque. Le développement se basait (pratiquement pour tous les langages) sur un ensemble d'outils d'édition visuelle et de composants réutilisables regroupés dans le même environnement. C'était l'époque des EDI (IDE). Durant cette époque, on a vu la naissance de Visual Studio, Delphi, C++ Builder, NetBeans, Eclipse et bien d'autres. Il y avait même des efforts sérieux pour des éditeurs visuels pour HTML.

Le principe est très simple : l'EDI traduit les actions visuelles vers un code. Si des ressources et des bibliothèques externes étaient nécessaires pour le projet alors il était nécessaire de les intégrer (télécharger et importer) au niveau de l'EDI; donner juste l'URL n'était pas suffisant. Dans cet article, je présente, pour illustrer ce point, le choix du LayoutManager d'une JFrame (sous Java) et les conséquence de la manipulation visuelle sur le code généré.

Cette approche a duré jusqu'au début des années 2010 lorsque le développement web a connu des grands changements. jQuery, NodeJS, AWS, NoSQL, les gestionnaires de dépendances et plein d'autres technologies peuvent être citées pour justifier ces changements. Les CMS tels que Drupal et Joomla ont perdus leur place pour ces nouvelles technologies et les outils RAD ont perdu aussi leur place pour un nouveau mode de développement. Un mode imposé par Node et son écosystème (aka npm) qui est considéré, aujourd'hui, comme le plus grand entre toutes les plateformes.

A mon avis, ce nouveau mode repose sur quelques principes :

• Utilisation massive des dépendances et une orientation totale vers la réutilisation,
• Utilisation des éditeurs simples avec des Copier/Coller : c'est très fréquent de trouver une bibliothèque dont la documentation (presque) entière est basée sur des exemples à Copier/Coller (Oracle Jet, présenté ici, à titre d'exemple),
• La génération des applications, non pas du code.

Personnellement, je me positionne contre cette nouvelle école. Je ne suis pas d'accord avec ces trois principes.

Premièrement, l'utilisation massive des dépendance en comptant exclusivement sur le gestionnaire des dépendances (maven, gradle, npm, gulp) a prouvé ses limites surtout lorsqu'un bon nombres des dépendances sur lesquels les projets sont fondés changement très fréquemment. L'exemple de lfetPad reste le cas le plus connu mais pas l'unique.

Deuxièmement, le Copier/Coller ne remplacera jamais l'écriture du code. Ne pas préparer une bonne documentation qui explique le principe de fonctionnement et l'architecture de la plateforme pour ensuite proposer des exemples du code a donné naissance à ce mode bizarre de développement. Si cela marche dans les cas ordinaires, les développeurs se trouvent coincés dès qu'une erreur imprévue dans l'exemple apparaît ce qui engendre par la suite une réduction considérable de la productivité.

source me.me

Finalement, la génération des applications (presque) entière vient pour remplacer la génération du code. En effet, la norme actuelle repose sur l'utilisation des outils (en ligne de commande généralement) qui génère, non pas seulement la structure de l'application, mais aussi une bonne partie du code de l'application. Ruby on Rails, Grails et Maven représentaient le début.
La philosophie de ce dernier principe suppose que malgré les grandes différences entre les applications développées, elles peuvent être catégoriser en un nombre limité, et même petit, de types. Les applications de même type partagent toutes la même architecture, le même style et (presque) les mêmes fonctionnalités. Ainsi, il est possible de créer des outils qui peuvent générer une bonne partie de code de l'application en se basant sur son type. Par la suite, le développeur doit introduire les "différences" seulement.
Si je suis en désaccord avec les deux premiers principes, je suis particulièrement contre le troisième. Il cache une simplification à la fois dangereuse et coûteuse.
Dangereuse : parce que la supposition de base est vraiment discutable. Si je ne peux pas prouver qu'il est impossible de catégoriser les applications, il est aussi impossible de prouver le contraire. Tenant compte de cela, il est complètement justifiable de dire que les applications "de même type" ou "similaires" ne sont pas nombreuses et, ainsi, s'investir dans l'acquisition et l'apprentissage d'un outil pour l'utiliser deux ou trois fois seulement peut être une mauvaise décision.
Coûteuse : parce que ces outils reposent sur d'autres plateformes, bibliothèques et services. Ainsi, tout changement au niveau de l'un de ces dépendances peut influencer d'une manière considérables les applications développées.
Ce dernier inconvénient reste toujours présent avec chaque projet (la passerelle ODBC en Java constitue un excellent exemple), mais avec une telle dépendance sur plusieurs couches d'outils et d'API utilisés pour générer, compiler et exécuter l'application en question le risque devient des dizaines de fois plus importants.
Dans cet article, une brève démonstration d'une telle génération en utilisant Yeoman.

[En Deux Mots] Ne faites pas de longues ruptures

Même si ce conseil paraît évident, j'ai fait cette erreur de ne pas le suivre. J'ai pris une longue rupture qui a atteint les 3 ans, durant lesquelles, je n'ai pas réalisé des projets complets. Mon travail de développement se limitait à ce que j'avais besoin pour assurer les Travaux Pratiques en Algorithmique (pour les étudiants en première année Mathématique et Informatique - MI). Deux ans en Pascal et une dernière année en C.
La cause principale de ce désastre était mes débuts en doctorat. entamer un nouveau domaine n'est pas toujours une chose facile, surtout s'il s'agit d'un domaine loin de l'informatique. Je me trouvais étudier les livres de psychologie, psychopédagogie, psychologie du développement, théorie de l'action et les théories des émotions.

Sloman, A. (2004, March). What are emotion theories about. In Invited talk at cross-disciplinary workshop on Architectures for Modeling Emotion at the AAAI Spring Symposium at Stanford University in March.

Les résultats de cette rupture étaient catastrophiques. Premièrement, mes productions étaient des codes dispersés qui visaient des exercices d'introduction à l'algorithmique, des exemples sur les boucles et quelques exercices très classiques comme la vérification d'une grille Sudoku ou bien trouver les nombres amis. Si mes participations sur les forums des débutants ont devenus plus détaillées et plus pédagogiques, mes participations sur les forums plus avancés commençaient à diminuer avant de s'arrêter complètement. Mon repository sur Source Forge a stagné complètement aussi.
Deuxièmement, je n'ai pas pu suivre du près les nouvelles approches révolutionnaires qui ont vu le jour durant ces années. Groovy était un langage des amateur, Docker était dans ces débuts et semblait avancé un peu doucement et l'école fonctionnelle semblait encore endormie. Après trois ans, Groovy n'est plus le langage pour les amateurs; il est devenu un langage et une plateforme très intéressante. Je ne pouvait même pas reconnaître des parties telles que Grail qui a changé complètement. Docker a aussi changé, maintenant, il est doté d'un écosystème complet et il est devenu la base d'autres plateformes telles que Fn. Cette dernière prouvait qu'une l'approche fonctionnelle est du retour et avec puissance; l'approche Objet sur laquelle je me basais complètement a commencé à montrer sa lourdeur sur le côté serveur.
Finalement, je ne reconnaissais plus ma plateforme préférée : Java (J2SE/J2EE). La J2EE 6 était une vrai révolution, les fichiers XML que j'ai tant utilisé ne sont plus nécessaires et ils sont généré automatiquement à partir des annotations. Les services web RESTful ont devenus plus simples et plus rapides à développer. Les annotations se multipliaient et les outils aussi. Java 8 et les expressions Lambda ont été introduites, je n'en savait rien sauf quelques articles très brefs que j'ai lus.
Comment je me suis réveillé ? Je préparé une formation Java pour des étudiants. C'était avant l'introduction du module Programmation Orientée Objet avec des Travaux Pratiques en Java. Tout simplement, j'ai trouvé du mal à écrire ma fonction main, c'était aussi grave. Durant les deux années suivantes, j'ai essayé de récupéré. Même si je me débrouille pas mal, je pense que tout ce la était facile à éviter si je ne me suis pas émergé complètement dans mon doctorat et mon enseignement.
Alors, Ne prenez jamais de longues vacances et ne faites jamais de grandes ruptures. Restez près de votre éditeurs et travaillez sur des projets, même les plus simples, d'une manière continue. Ne vous contentez pas des articles, installez les nouvelles versions et essayez les, ce n'est pas une perte du temps, c'est même un gain du temps.
(Pourquoi cet article ? Jetez un coup d’œil par ici)

Groovy pour l'enseignement intial de la programmation

Le choix d'un langage du départ pour l'enseignement de l'algorithmique est crucial pour l'apprenant. La première impression qu'il forme sur le module et la programmation de manière générale peut influencer ses performances durant l'apprentissage. Cette influence peut dépasser le module algorithmique pour affecter les autres modules qui dépend fortement de la programmation.

Le choix pris à l'université de Jijel, par exemple, est le langage Pascal. Ce choix est encore présent dans plusieurs autres universités. Ce choix est justifié par la similitude entre l'algorithmique et le langage Pascal et la nature pédagogique de ce dernier. En suivant une formation en français, l'étudiant peut vite obtenir un programme en Pascal par effectuer une traduction vers l'anglais.

Algorithme Exemple;
Var
    a, b, c : Entiers;
Debut
    Lire(a);
    Lire(b);
    c <- a + b;
    Ecrire(c);
Fin.

Program Exemple;
Var
    a, b, c : Integer;
Begin
    ReadLn(a, b);
    c := a + b;
    WriteLn(c);
End.

Néanmoins, la syntaxe de Pascal n'est pas retenue par d'autres langages. En effet, délimiter les blocs par "Begin" et "End" ne trouve pas d'autre utilité que dans le langage Delphi (que je considère comme Object Pascal, c'est à dire, Pascal). Apprendre un autre langage, tel que C, C++ et Java, nécessitera la reprise de la syntaxe et des mots clés à nouveau.

Nous avons tenté, durant une année universitaire, de commencer avec le langage C. Un choix qui peut être justifié par deux points essentiels :

1. Le langage C est parmi les langages les plus utilisés et les mieux classés au monde. A mon avis, il le restera tant que les noyaux des systèmes, les pilotes et la programmation niveau bas reposent sur le langage C.
2. La syntaxe du langage C est reprise par plusieurs autres langages. Si vous pouvez écrire la boucle "for" en C, alors vous pouvez l'écrire en C++, Java, C#, PHP, Perl, Ruby, Groovy et bien d'autres.

Le résultat était satisfaisant : les étudiants ont pu assimiler le langage vu qu'il n'ont pas connu un autre langage plus simple. C'est à peu près comme Linus Torvalds qui a commencer à développer en binaire pensant qu'il est le langage assembleur.

Néanmoins, l'effort fournis était bien supérieur. La tâche était fatigante à la fois pour les enseignant et les étudiants. Le passage n'était pas intuitif entre l'algorithmique et l'étudiant devait faire un effort supplémentaire et un temps additionnel, ainsi, les séances du TP devenaient de moins en moins productives, particulièrement lorsque nous abordions les pointeurs. Les messages d'erreur sont moins claires et plus difficiles à comprendre par les débutants. Sous Pascal, ce problème n'était pas posé vu qu'il s'arrête et affiche la première erreur rencontrée et ses messages sont plus compréhensibles. Pascal cache, aussi, l'étape de création des liens et le rassemblement des parties du code.

Ainsi, chaque option possède ses avantages et ses inconvénients. Heureusement, de nouveaux langages sont proposés chaque jour et la liste des options est devenue très riche.

A mon avis, le langage Java doit être le centre de la formation. Il partage quelques caractéristiques de simplicité avec Pascal et il reprend la syntaxe du langage C. Avec une API bien conçue et une convention du nommage très claire, il est possible à tout débutant de se lancer en Java et vite comprendre ses bases et qu'est ce qu'il faut faire. Il commence à trouver sa place dans l'enseignement de l'algorithmique dans plusieurs universités (Stanford, par exemple). A l'université de Jijel et à la région Est de l'Algérie, le programme de formation normalisé prévoit le module "Programmation Orientée Objet" qui repose entièrement sur le langage Java comme langage d'application. Les messages d'erreur sont très claires et les éditeurs disponibles facilitent leur repérage et leur correction (des éditeurs comme Eclipse et NetBeans vont jusqu'à la proposition de solution au développeur, ils signalent les erreurs pendant la saisie du programme et avant même d'entamer la compilation).

Malheureusement, ce choix n'est pas sans inconvénients. Le premier inconvénient, qui l'inconvénient majeur de Java, est l'obligation de respecter strictement les notions de la programmation Orientée Objet. C'est à dire que tout le code (toutes les fonctions) doivent faire partie d'une classe. Dans un contexte d'apprentissage, ce point peut être problématique pour l'étudiant parce qu'il écrit un code qu'il ne comprenne pas. En effet, il est très difficile d'expliquer la signification de "class" et de "static" si l'apprenant essaie d'apprendre le sens de "variable" et "bloc".

Le deuxième inconvénient est ce mélange entre type primitifs et classes. Les types de base "int", "long", "float", "double" et "boolean" (liste non-exhaustive) ne sont pas considérés comme des classes mais String est une classes. Cela peut créer une confusion qui dure, des fois, plusieurs semaines.

Pour remédier à ces inconvénients, Groovy peut être la solution. Groovy est un langage de la JVM (la machine virtuelle Java), c'est à dire, il compile son code vers un code Java qui repose sur la machine virtuelle pour son exécution. Il peut faire appel à des API Java comme il possède ses propres classes (compatibles avec Java) qui "corrige" les manque du langage Java et le rend plus "moderne" (si nous pouvons le dire).

Parmi les éléments du java, nous citons les deux suivantes :
1. Il n'est plus nécessaire de mettre tout le code dans une classe. Il est possible d'opter pour un code "script". Il est possible, aussi, d'utiliser la fonction "main()" tout cours (comme le font le C et le C++).

println "Hello World!"

2. Tous les types sont des Objets. Les types primitifs sont automatiquement enveloppé dans leurs "Wrapper"s. Ainsi, la déclaration d'un int implique la déclaration d'un Integer. Cela est fait en toute transparence.

Sous Groopy, les premiers exemples seront beaucoup plu faciles et nécessiteront mois d'explication. Il nous éviteront aussi cette "écrivez le code tel qu'il est, nous allons l'expliquer plus tard" sur la partie "class" et "public static void main()".

def a = 10;
println a.class

Groovy n'est pas le seul. Plusieurs autres langages JVM peuvent être utilisés comme un point de départ pour apprendre l'algorithmique avant de passer vers Java. D'ailleurs, des langages JVM sont conçus spécifiquement pour l'enseignement; Javascool en ai un exemple. Les comités pédagogiques doivent laisser les choix ouverts et profiter des différents langages disponibles.

Drag & Drop sous Processing en quelques lignes

L'interactivité sous Processing est très impressionnates. En quelque lignes, il est possible de récupérer et traiter les différents évènements prevenant de la souris ou bien du clavier. Cet exemple vise à donner un avant-goût de ces capacités.
Le Drag Drop consiste à lever un objet en cliquant dessus, le déplacer (le voir se déplacer) en gardant le clique et le déposer en relâchant le clique.

Sous Processing, nous pouvons exploiter les éléments suivants :

•  Il est à tout moement possible de récupérer la position de la souris grâce à deux variables prédéfinies : museX, mouseY. Aucun code ou fonction ou Listener sont nécessaires.
• Pour récupérer l'évènement du clique, il suffit d'implémenter la méthode "mousePressed()"; elle sera appelée si l'un des deux bouttons de la souris est enfoncé. mouseBoutton permet de connaître est ce qu'il s'agit d'un clique droit (RIGHT) u gauche (LEFT).
• Pour récupérer l'évènement du relâche de la souris, il suffit d'implémenter la méthode "mouseReleased()".

Le seul élément que nous allons ajouter est une variable booléenne pour garder trace est ce que l'objet est entrain d'être déplacé ou pas. Le code suivant est le code de l'objet (nommé Activite, préparé dans un contexte précis) :

class Activite {
  
  int x, y;
  final int HEIGHT = 180;
  final int WIDTH = 180;
  
  public Activite(int x, int y){
    this.x = x;
    this.y = y;
  }
  
  void draw(){
    rect(x, y, HEIGHT, WIDTH);
  }
  
  void setX(int x){
    this.x= x;
  }
  
  void setY(int y){
    this.y = y;
  }
  
  int getX(){
    return x;
  }
  
  int getY(){
    return y;
  }
  
}

Ce code est presque un JavaBean, à l'exception de la méthode draw() qui déssine un rectangle.
Le code du Drag & Drop est :

Activite a;

int diffx, diffy;
boolean drawing = false;

void setup(){ 
  size(960, 480);
  a = new Activite(100, 100);
}

void draw(){
  background(240);
  
  if(drawing){
    a.setX(mouseX + diffx);
    a.setY(mouseY + diffy);
  }
  
  a.draw();
}

void mousePressed(){
  diffx = a.getX() - mouseX;
  diffy = a.getY() - mouseY;
  drawing = true;
}

void mouseReleased(){
  drawing = false;
}

Les deux variables diffx et diffy c'est pour garder la distance entre la position de la souris et la position de l'objet au départ de l'action.

Une version abrégée de ce code peut montrer qu'il est possible d'implémenter le tout avec toutes les données et les fonctions en moins de 30 lignes en gardant notre code claire at aéré:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

int x, y, h, w; int diffx, diffy; boolean drawing = false; void setup(){ size(960, 480); x = 100; y = 100; h = 100; w = 250; } void draw(){ background(240); if(drawing){ x = mouseX + diffx; y = mouseY + diffy; } rect(x, y, w, h); } void mousePressed(){ diffx = x - mouseX; diffy = y - mouseY; drawing = true; } void mouseReleased(){ drawing = false; }

Le trésor caché

L'évolution rapide des différentes technologies liées à la programmation et au développement complique de lus en plus la tâche du développeur. Être un développeur d'une technologie particulière veut dire suivre ses différentes avancées et faire la mise à jour de ses connaissances pour pouvoir exploiter et bénéficier des nouvelles versions et des nouvelles frameworks. Cette tâche devient très difficile vu le rythme suivant lequel les nouvelles propositions sont déployées. Ainsi, le développeur se trouve face à deux solutions.
La première solution est la spécialisation dans un ensemble donné de technologies. A mon avis, c'est la solution suivie par la plus part des développeurs. Chaque développeur choisit la technologie qu'il trouve meilleure pour lui (comme préférence personnelle) ou bien pour son travail (exigence professionnelle). Après plusieurs années d'expérience, il sera un expert dans ces technologies. La plus part des auteurs des livres font partie de cette catégorie.
La deuxième solution est l'apprentissage limité selon le besoin. Dans le cas où le développeur se trouve obligé de travailler sur plusieurs projets avec des technologies différentes, il peut apprendre une partie ou une API d'un langage ou d'une plate-forme donné suffisamment pour pouvoir satisfaire son engagement professionnel mais pas pour mériter le titre d'expert ou pour occuper le poste de consultant dans cette technologie. Je ferai beaucoup moins confiance dans un livre si je trouve que son auteur soit de cette catégorie.
Dans les deux cas, il restera probablement des trésors cachés. Et par trésor, je veux dire un outil, un langage, une API ou une extension que vous ne connaissez même pas l'extasient ou que vous n'utilisez pas son potentiel d'une manière correcte.
C'est mon cas avec le langage Processing. Processing : "(autrefois typographié Proce55ing) est une bibliothèque Java et un environnement de développement libre (sous licence GNU GPL), créé par Benjamin Fry et Casey Reas, deux artistes américains. Processing est le prolongement « multimédia » de Design by numbers, l'environnement de programmation graphique développé par John Maeda au Media Lab du Massachusetts Institute of Technology" (Wikipedia, simplement). Processing cache une grande partie de la complexité relative à la programmation Orientée Objet que nous trouvons dans Java. Il permet aussi de créer facilement des graphiques et des animations en implantant une grande partie des notions relatives à l'animation; la chose qui est complètement absente dans Java.
Dans mon cas, j'ai toujours utilisé les Applets pour implanter des animations de base à des fin pédagogiques et d'enseignement. Avec l'abondant des Applets, j'ai cherché une solution alternative et j'ai tombé sur Processing. Ma première impression était un regret profond de toutes les années que j'ai perdues en utilisant les Applets au moment où je pouvait faire appel à Processing. En effet, pour dessiner un carré, il vous suffit 2 lignes de code :

size(600, 400);
rect(100, 100, 400, 200);

Processing est le plus grand trésor sur lequel j'ai tombé cette année. Avec les possibilités qu'il offre (quelques exemples), il fera, probablement, partie de mon quotidien durant les prochains jours où  je tenterai de l'explorer et de l'exploiter.
Note Importante : Apprendre une technologie ou un langage ne se résume pas dans l'apprentissage du syntaxe de base ou bien de l'API de base seulement. Le développeur doit avoir des connaissances plus approfondie et doit pouvoir faire face aux problèmes et erreurs souvent rencontrés ou même non-documentées.

Ecrire des outils personnels, pourquoi est-ce important ?

Il est possible, aujourd'hui, de trouver toute sorte de logiciel sur le marché. De plus petit utilitaire au plus grand logiciel, les offres se multiplient, soit pour les logiciels payants, soit pour les logiciels Open Source. Il est même possible de faire appel aux outils en ligne, suivant (presque) la philosophie de SAAS. Ainsi, il est possible d'utiliser des outils pour dessiner des graphes, prendre des notes ou même écrire et compiler des programmes sans rien installer sur la machine.
Néanmoins, nous nous trouvons des fois face à des problématiques particulières, ou bien, face à des exigences particulières imposées par notre propre environnement de travail et la combinaison unique des logiciels installés et leur utilisation dans le cadre de notre propre activité quotidienne. Cette combinaison est, à mon avis, unique et c'est pourquoi le phénomène "Work on my machine" est toujours présent entre les développeurs.
Cet environnement unique nécessite, par conséquent, une configuration unique. Il faut adapter les différents outils et logiciels ainsi que le système d'exploitation installé pour répondre à nos exigences particulières. Ainsi, nous nous trouvons entrain de lire les différentes ressources de documentation, de visiter les sites dédiés des logiciels installer et sauter entre les différents dossiers pour modifier tel ou tel fichier en ajoutant des commandes par ci et en "dé-commentant" une ligne par là.
Une situation plus délicate est le passage d'un système à un autre; dans l'état actuel des choses, ces actions de configuration manuelle sont (pratiquement) impossibles à transmettre entre l'ancienne version et la nouvelle version (ou l'ancien environnement et le nouvel environnement). Ma récente expérience avec une mise à niveau majeure de mon système m'a fait vivre cette situation avec tous ses détails : j'étais obligé de reprendre l'installation de mes outils à zéro (chose qui n'est pas vraiment pénible), en plus, il fallait les configurer. J'étais, à titre d'exemple, surpris de voir mon installation locale de la plateforme Moodle s'arrêter malgré le respect des différentes consignes et après plusieurs heures de vérification j'ai trouvé que la cause est le manque d'une extension PHP qui n'est plus installée avec l'installation par défaut.
La question qui se pose est : pourquoi dépendre de tous ces outils "prêt-à-porter" et leur pénible configuration ? Une autre solution que je propose est le développement de nos propres outils lorsqu'il s'agit des petits utilitaires ou bien des logiciels que nous n'utilisons qu'une faible partie de leurs fonctionnalités (nous n'utilisons, en général, que 10% des fonctionnalités des logiciels installés sur nos machines). L'idée de ce blog m'est venue en lisant, depuis quelques minutes, une question sur un forum où son auteur se demandait est ce que nous devéloppons nos propres logiciels. La liste des réponses étaient longue : des logiciels de gestion des dépenses, d'autres pour gérer l'emploi du temps des enfants, des outils pour convertir entre différents formats, et plein d'autres outils que les développeurs développent pour eux-même et pour faciliter leurs activités quotidiennes.
A mon avis, avoir un ensemble des outils personnels est une nécessité pour chacun d'entre nous. Avoir le courage de développer les fonctionnalités les plus utilisées dans un logiciel pour ne plus dépendre de ce dernier me semble très justifié quoique la tradition soit de ne plus réinventer la roue. Mais est-ce cette roue est vraiment utile pour moi ? Et si c'est le cas, pourquoi je me trouve obligé de la modifier pour l'agrandir par ci et la réduire par là ?
Durant ma dernière mise à niveau, l'outil que j'étais sûr qu'il fonctionnerait était un simple outil que je développais pour les séances de TP ou j'étais obligé de créer rapidement des classes et des scripts SQL; l'outil me permet de créer les deux en exécutant une seule (mais longue) commande. Pourquoi être sûre ? Parce qu'il s'agit de mon outil, je connais tous ses détails et je peux me retrouver facilement entre les lignes de son code source et de sa documentation. Je n'ai plus besoin de faire des recherches, de poser des questions sur les forums ou bien de contacter son support technique. Et c'est exactement là que réside la puissance des outils personnels.

Voilà comment "un cours" devient "une chaîne de caractères"

La conception et la réalisation d'un système quelconque nous pousse à travailler, dans la plus part des cas, avec des niveaux d'abstraction différents. L'idée est de commencer par un niveau élevé d'abstraction et de descendre, étape par étape, vers le niveau physique qui est l'implémentation de la solution. Ce passage n'est pas souple, ni sans risque; une chose qui m'a pris deux années et deux projets pour la réaliser.
Les niveaux d'abstraction sont utilisés depuis les premières approches d'analyse et de conception des systèmes informatiques et des systèmes d'information. Merise, l'une des premières approches, définit trois niveaux d'abstraction :

• Le niveau conceptuel : le niveau d'abstraction le plus élevé. A ce niveau, on est supposé donner une première modélisation du système en essayant de répondre à la question "Quoi" pour les deux dimensions statique (données) et dynamique (traitements) du système.
• Le niveau logique (organisationnel) : le deuxième niveau d'abstraction. A ce niveau, on commence à détailler la modélisation donnée au niveau conceptuel en ajoutant les réponses aux questions "Qui" et "Quand".
• Le niveau physique : le niveau d'abstraction le plus bas; on parle de l'implémentation physique. A ce niveau, la conception (la modélisation) détaillée donnée au niveau logique est traduite à un ensemble de programmes, logiciels, fichiers et bases des données.

Cette définition (très) simplifiée nous montre qu'il est possible de faire une conception et une réalisation souples avec des passages claires entre les différentes étapes. Malheureusement, deux projets durant les deux dernières années ont prouvé que, sous certaines circonstances, c'est pas aussi évident que cela.
En travaillant sur deux projets en e-Learning (comme toujours), les étudiants impliqués ont montré le même comportement malgré que les deux projets étaient complètement indépendants. Le comportement peut être résumé par un constat que me frappait il y a environ deux semaines en essayant d'expliquer à un collègue ce qui ne marche pour le projet en cours : "le cours de l'enseignant est, pour eux, une chaîne de caractère".
Sur ce point, vous allez me dire que c'est normal : toute donnée sera, quelque part durant le processus, traduite vers une donnée binaire pour être implémentée sur la machine. Ainsi, le solde bancaire d'un employé n'est qu'un nombre réel, la valeur d'un crédit qui peut contrôler la vie d'une famille n'est qu'un nombre réel aussi, un avion civil avec des centaines de passagers n'est qu'un cercle de quelques pixels sur un écran et même une déclaration de guerre entre deux pays n'est qu'une chaîne de caractères. Tout cela semble être vrai mais il n'est pas du tout.
Comme étant des humains, nous essayons toujours de donner plus de sens à des évènements qui semblent beaucoup plus simples que ceux cités ci-dessus. Nous tentons, aussi, de détecter des modèles, des lois, des principes et de proposer des théories pour les phénomènes qui nous entourent. En ajoutant ces capacités à nos capacités de manipulation des symboles, nous nous trouvons face à l'intelligence humaine (encore une fois, les définitions sont simplifiées : chaque définition peut nous conduire à écrire un livre entier). Ainsi, au moment où l'enseignant voit son cours comme le fruit d'un effort particulier d'analyse, de résumé et de synthèse, le développeur le voit comme une chaîne de caractères à insérer dans une base des données et à le récupérer plus tard. Ce décalage me semble anormal pour ne pas dire inquiétant pour le projet.
La cause principal, à mon avis, est la mauvaise division des tâches entre les membres de l'équipe, et plus particulièrement, les division de type : "tu fais l'état de l'art et je me charge de ma programmation". Une telle division semble marcher : le résultat finale de la première moitié est un ensemble de schéma descriptifs qui expliquent au moindre détail les composants du système, les traitements à effectuer pour chaque composant et les données à manipuler par chaque traitement. La deuxième moitié du travail consiste à reprendre cette description et à la traduire vers une technologie (niveau physique) pour terminer le projet. Et c'est ce passage qui n'est pas évident : sans suffisamment d'information sur le domaine, les préférences des clients et la nature des besoins, la conception détaillée sera vue par le développeur vide, sans âme et même sans importance particulière. C'est à ce niveau que le cours d'un enseignant et l'adresse d'un apprenant deviennent de la même importance, très similaires et
implémentées de la même façon : une chaîne de caractère.

Un dernier mot

Pour cet article, j'ai fait deux grandes simplifications (ce n'est pas sans risques) en essayant de comprendre ce phénomène qui pousse les étudiants (ou les employés) à vider un projet donné de son sens. L'objectif visé n'est pas de prouver ses origines parce que je ne les connais pas, c'est ma première réflexion sur le sujet. Ce que j'espère est d'exposer ce risque au sein des équipes de développement.

Mon niveau technique a baissé? Et un mot sur les frameworks.

Depuis presque cinq ans, je me suis orienté vers la vie académique. J’étais fortement inspiré par mon projet de fin d’étude qui portait sur l’application des techniques de Recherche d'information (RI) pour résoudre des problèmes liés à l’e-Learning. Il était déjà très clair dans ma tête que je veux continuer l’aventure académique.

Depuis, j’ai travaillé sur plusieurs aspects techniques et conceptuels touchant directement  à la problématique de l’apprentissage à distance. Au milieu de tout cela, j’ai ignoré un aspect important dans ma carrière comme étant informaticien, avant d’être un jeune-chercheur : c’est l’aspect technique, maintenant, je sens que mon niveau technique a baissé! Comment ça s’est arrivé?

Durant les cinq années, j’ai travaillé en Free-lance, c’est très pratique quand il est difficile d’occuper un poste à plein temps (parce que ça sera un sacrifice de la carrière académique). En Free-lance, on a la possibilité de garder un certain niveau de pratique technique, et je suis sûr que je garde le même niveau que j’ai eu depuis quatre à cinq ans alors où est le problème?

Le problème c’est le style de développement, les habitudes des développeurs et les techniques de développement. Il n’est plus possible de suivre le même rythme en commençant chaque fois “from scratch” ou de développer suivant un modèle MVC personnel, il est important de ne plus écrire un code personnel à 100%, il faut réfléchir à utiliser les frameworks disponibles. 

“Il n’y a plus de Javascript, il y a maintenant jQuery”, affirme Scott Hanselman, et de la même façon, dans quelques années, nous n’allons plus entendre de Java, PHP et C# sous la même forme d’aujourd’hui, les frameworks deviendront inséparable des projets de développement les plus simples. Mon niveau technique n’a pas baissé, il n’a pas évolué et c’est ça le problème.

Il est évident qu’il est difficile de suivre deux chemins au même temps, qu’il est impossible de tenter d’attraper deux lapins au même temps, mais, des fois il est amusant d’essayer. Ainsi, mon conseil à vous aussi : les habitudes de programmation changent, il faut que nous changions aussi, sinon, nous perdrons la bataille, tout comme les dinosaures.