Archive for Brève

CouchDB, …CouchDB, …

Javascript continue de faire des adeptes ! Après que d’autres aient essayé de mettre du XML, ou des triplets (ou du rdf, i.e. des triplets xml) dans une bd, des membres de la fondation Apache ont essayé de mettre des objets javascripts dans une BD (JSON): CouchDB. Et pourquoi pas aussi du code et du html ? le tout pour faire une application web, si c’est possible: CouchApp. Au final, on obtient donc une environnement NoSQL permettant le développement d’application web standard (client leger + bd) avec comme seul langage de programmation nécessaire le javascript (ni php, ni ruby, ni …). Le tout accessible, à partir d’un navigateur web et exposé à tous les utilisateurs (open de bout en bout, de la présentation, au code métier, jusqu’aux données !)

Seulement du javascript ? oui, enfin, c’est un peu vite dit, dans la version proposé initialement, c’est du javascript+jquery+evently+mustache+prototype. Mais bon, pour les puristes, on peut enlever le jquery+evently+mustache+prototype (il faut mesurer ce que cela apporte et ce que cela coute ! depuis que j’utilise javascript, j’ai eu le temps de voir arriver/passer : prototype, script.aculo.us, dojo, rico, ext, yui, mootools, mochikit, qooxdoo, jquery, node, underscore, evently, mustache, vanilla, commonJS, … sachant que les navigateurs sont de plus en plus conformes à la norme javascript.).

Enfin, bref, le temps de mettre au point quelques lignes (euh, disons un petit mois, mais seulement dans mes moments libres, ce qui limite pas mal le temps de travail effectif, mais permet de maturer et de mesurer la motivation), et voila une première appli (compte guest, mot de passe guest) chez un hébergeur « gratuit » (ce qui explique les nécessités de login/mdp ?) : https://denisb.couchappy.com/mem/_design/mem/index.html

Avec la bd au même endroit que le html/code, il n’y a plus de problème de « same origine policy », mais il reste à voir comment la gestion de la sécurité peut s’effectuer et si l’on arrive à partager le code/données facilement (même à l’intérieur du cadre « CouchDB/CouchApp »).

Résumé (english word from french)

Denis Bouhineau is an associate professor in Computer Science involved in the design and the evaluation of TEL environments (Technology Enhanced Learning Environments).

Alumnus of the École Normale Supérieure de Lyon (89-93), he received a PhD in Computer Science in 1997 on theoretical and practical aspects related to the teaching of geometry with Dynamic Geometry.  Thereafter, he evolved to the education of Algebra with a computer system that combined microworld and CAS features (2000-08: Aplusix). Since 2008, he has been working on web applications for teaching algorithms (EDBA). He is also an active member of the recent UnderTracks projects (2010) specifically concerned with the design of efficient, appropriate and applicable models for sharable data and analysis processes of learner’s interactions with TEL environments.

Plagiat, référence, hommage – originalité

Il semble y avoir continuité -du coté de l’objet- entre plagiat, emprunt, référence, hommage, … mais les contextes peuvent varier -qui entrainent des glissements de sens et de jugement-, et la dénomination que l’on en fait introduit des ruptures dans l’œil de l’observateur : entre la condamnation et le plaisir d’un clin d’œil partagé.

À l’université, coté étudiant, coté chercheur, le sujet diffère (et il y a d’autres points de vue possible), l’un doit faire preuve d’un travail personnel, l’autre d’un travail original ; l’un et l’autre peuvent faire des emprunts s’ils sont explicitement cités, référencés ; pour les autres (emprunts, emprunts non attribués), il faudrait connaitre l’intention de son auteur, un emprunt trop évident pour l’alourdir d’une référence ? un vol à dissimuler ? une absence d’intention (un emprunt inconscient, involontaire ou aléatoire) ? Selon, l’étudiant pourra être pardonné là où le chercheur sera condamné, mais il restera toujours un doute -l’intention réelle n’est pas accessible- lié à l’honnêteté ou à la bonne foi de l’individu, ainsi qu’à sa clairvoyance (à la distance entre ce qu’il croie et prend pour la vérité/réalité et la réalité elle-même).

Faire la preuve de la faute … difficile.

Peut-on croire à l’originalité ? Il me faudrait être omniscient pour être sûr que ce que je viens d’écrire, ou ce que j’ai écrit est/était original ; ça et là je sens des influences, je pourrais ailleurs remonter la piste vers des emprunts, faire l’analyse de « ma » culture, autre part encore je pourrais rendre explicite ce qui me semble une évidence, … ou en rester là, serein de ma bonne foi, n’ayant eu aucune volonté de voler une idée qui n’aurait été la propriété de tous, dans un raisonnement que chacun aurait pu faire -en quoi m’appartiendrait-il ?-, satisfait d’avoir, au moins pour moi, pu éclaircir un peu ce qui touche au plagiat et rencontre mon opposition par rapport à « ma » conception de la propriété intellectuelle.

en résumé, pour un étudiant, il y aura faute s’il copie là où il aurait dû faire un travail personnel, s’il emprunte consciemment sans citer, si la somme des emprunts conscients est plus importante que la partie qui lui revient, s’il a une intention malhonnête, … (?)

pour le chercheur, c’est encore à voir … les idées ont-elles des propriétaires ? …

Algorithmique, un art de la programmation ou simplement du bricolage informatique ?

D’un coté il y a l’algorithmique que l’on souhaite enseigner aux étudiants, avec des concepts spécifiques (les structures de contrôle, les structures de données, …), des problématiques de modélisation, de validation et d’évaluation, … Cette science repose sur les facultés de notre cerveau à organiser et prévoir, manipuler des objets, réaliser une action, une activité, pour « faire ». Elle nécessite et mobilise la pensée « algorithmique » (si on peut la définir ainsi).

Tant que l’on reste au niveau d’un petit problème, le travail se fait en contact quasi direct avec les objets manipulés ; quand le problème devient plus gros, l’habitude consiste à réduire le problème à un ensemble de sous-problèmes plus simples, à prévoir plusieurs couches (par exemple) pour résoudre le problème, et  à chaque niveau on est en contact avec des objets -certes- mais ceux-ci sont de plus en plus complexes. S’observe alors la nécessité d’un basculement vers une autre forme de pensée, plus organisatrice (de haut niveau), on passe de l’algorithmique au génie logiciel.

Le passage de l’algorithmique au génie logiciel s’accompagne souvent de l’introduction de bibliothèques de programmes prêts à l’emploi et, à la suite, permet une autre forme de programmation qui ne demande ni conceptualisation, ni sens de la prévision, ni sens de l’organisation : la programmation-bricolage. Qu’est-ce que la programmation-bricolage ? C’est -face au problème- regarder dans sa boîte à outils quel est l’ustensile le plus facile à utiliser pour arriver à résoudre le problème, quitte à utiliser l’outil à mauvais escient, à écraser une mouche avec un marteau. C’est déplacer le travail sur la recherche de l’outil plutôt que la construction du programme. C’est préférer un programme d’une ligne à une exécution en temps constant. C’est préférer un programme d’une ligne même s’il engendre une exécution en un temps indéterminé à une exécution en temps constant à partir du moment celui-ci demande l’écriture d’un long programme.C’est bien connu, tout a déjà été fait, il ne faut pas réinventer la roue, allons sur internet ou dans la boite à outils de notre langage voir si la fonction n’existe pas déjà ou comment d’autres ont résolut le problème et copions-collons le résultat.

Espérons que celui qui agit ainsi ne perd pas le sens de ce qu’il fait, qu’il a su construire des outils pour valider et évaluer son travail …

Même si la distance entre le programmeur maître de ce qu’il fait et celui qui agit en croisant les doigts est grande, la frontière entre ces deux pratiques est parfois difficile à définir (dans tel domaine on peut agir en connaissance de cause, et ailleurs [devoir] faire confiance ; -et il y a du bon aussi à ne pas toujours réinventer la roue), il est donc délicat d’encenser l’un et condamner l’autre, mais j’ai tout de même le sentiment de voir chez l’un de la responsabilité, là où je ne vois chez l’autre qu’une envie de finir son travail le plus vite possible, à moindre coût (pour lui).

 

Javascript – Faille de sécurité ?

Javascript a de nombreux avantages (open, indépendant d’un os, beaucoup utilisé, …), c’est pourquoi je milite pour que les développements dans le monde de l’éducation puissent aussi reposer dessus c’est possible, (j’en ai fait la preuve avec edba, lire cet article) et donnent lieu à des applications sous forme de pages web autonomes (seul besoin pour les faire fonctionner coté utilisateur : un navigateur web et une connexion au réseau ; coté développeur, une fois développée, la page web peut être déposée sur un serveur web minimal). Cependant, jusqu’à maintenant, j’avais un doute : très souvent, l’utilisation de javascript ne prends pas en compte les possibles tentatives de fraude et il s’avère qu’il est assez souvent facile d’arriver à répondre à un quizz, un qcm, … sans connaitre la réponse mais en allant chercher dans le code quelle est la réponse attendue. C’est particulièrement vrai pour des pages reposant uniquement sur javascript. Une solution pour éviter cela consiste à introduire un peu de PHP dans l’application, code déposé sur le serveur pour y faire l’analyse des réponses (laisser le javascript sur le poste client analyser les réponses, c’est prendre le risque de laisser la main à l’utilisateur pour qu’il regarde comment l’analyse se fait, ou la simuler pour voir le résultat, ou … -toute méthode de reverse engineering qui permet de retrouver les réponses), le code sur le serveur est inattaquable (enfin, presque …) et assure la sécurité du système. L’inconvénient, c’est que le projet n’est plus totalement open, qu’il ne peut plus tenir dans une page web unique et qu’il faut connaitre javascript+php pour le développer. Cela fait beaucoup.

Un autre soucis avec Javascript concerne des projets plus gros qui auraient besoin d’un base de  données centralisée sur un serveur (il y en a, et particulièrement dans le domaine de la recherche où l’on veut conserver une trace de l’activité pour en faire l’analyse). Tout faire en javascript semble difficile car l’accès aux bases de données se fait en général à partir des serveurs et non des clients (et donc à nouveau en php, par exemple), ou à partir d’application standard (hors navigateur) pour avoir des droits étendus sur l’accés au réseau (ou au disque dur). Pour les applications web tenant dans une page web, c’est à dire pour les application web fonctionnant dans un navigateur, cela passe par une partie du code sur le client (en général javascript), et une partie sur le serveur (en général php). Pour diverses raisons, et en particulier des raisons de sécurité, la part php est inévitable et ne se réduit pas à laisser rebondir la demande javascript directement vers le serveur. Pour certaines requêtes sur la base de données, le simple rebond est possible : pour la consultation des parties publiques de la base, par exemple ; pour d’autres requêtes un petit problème de confidentialité peut surgir : consultation d’informations personnelles ; pour d’autre encore, c’est un trop gros problème pour imaginer utiliser un simple rebond : par exemple pour l’accès en écriture/modification/suppression sur l’ensemble de la base (par erreur ou à dessein, un utilisateur peut alors altérer/détruire le contenu de la base).

Faut-il se résoudre à apprendre php … ? Non, pas nécessairement … Pour les problèmes de triches aux QCM, il y a moyen de compliquer un peu le code d’évaluation d’une réponse à un test pour que le reverse engineering soit difficile (sans que le travail demandé pour la modification de code soit très importante) : ne pas mettre en clair la réponse (éventuellement la coder, mais cela ne suffit pas toujours), au lieu d’analyser une seule réponse à la fois, il est préférable d’en prendre plusieurs en même temps (la combinatoire des réponses possibles est alors plus grande et ne peut être testée par essai/erreur), et utiliser une fonction asymétrique (type MD5) pour voir les résultats. Ce sera un résultat global, avec un mécanisme de type code-correcteur, on peut à partir de plusieurs résultats globaux de ce genre identifier le nombre d’erreur, et selon la méthode employée localiser les erreurs (mais alors il y a moyen de faire du reverse engineering). Pour l’accès au base de données, la solution vient d’un travail d’identification de la demande avec mot de passe, mais attention, un vrai identification, et qui prend en compte le fait que le code javascript est visible : cela peut se faire avec un système à clé publique (comme pour rsa). La bonne nouvelle, dans un cas comme dans l’autre, c’est que les algorithmes un peu compliqués (MD5, RSA) sont disponibles en javascript (il y a beaucoup de choses en javascript, c’était dèjà une bonne nouvelle il y a quelques années) :

exemple : essayer de trouver les dates de naissance/mort de Alan (pour la naissance, aide : regarder le code, pour la mort, aide ???). Autre exemple avec des réponses booléennes : essayer de trouver le sexe de ces anges (aide : regarder le code), ou de savoir si ceux-ci ont fait avancer l’informatique ( aide ???). Quand il n’y a pas d’aide immédiate (« aide ??? »), i.e. quand regarder le code ne suffit pas, il reste toujours la méthode dite « brutale » qui consiste à tout tester … lorsque le « tout » ne comporte qu’une dizaine de cas, l’étude exhaustive peut se faire à la main ; lorsque le « tout » comporte plusieurs milliers de cas, un programme peut le faire ; lorsqu’il y a des milliards de milliards de cas à voir, … ???