sp.Blog

le blog de Stéphane Pouyllau

Catégorie : informatique

Un Macintosh Plus de 1986 connecté à Internet ?

Après l’opération « on échange des fichiers entre un Macintosh Plus de 1986 et un MacBook Pro » via Zterm et un cable série…

Zterm_MacOS10

Zterm_MacOS6

… voici l’opération « un Macintosh Plus de 1986 se connecte à Internet » réalisée ! J’avais mis cela sur Facebook il y a quelques semaines et j’en fait un mini billet pour les amateurs de rétro-informatique (je ferai un billet plus détaillé, avec captures d’écran « cathodique de 9 pouces » dans quelques temps).

Pour information le Macintosh Plus date de 1986, il a 4 méga-octets de RAM (!) et tourne sous Mac OS 6.0.8 et se connecte à Internet via MacPPP + MacTCP et une connexion série sur un Raspberry Pi équipé du programme SLIRP qui fait le pont vers internet (d’un port série à du RJ45). Le Raspberry Pi (modèle B) tourne sous Raspbian. SLIRP simule une connexion PPP et fait le pont vers le réseau TCP/IP. 

RaspberryPi

11147089_10153178469812910_1968912769725771678_nRésultat : on surfe à la vitesse ultra rapide de… 19200 bit/s (19 kbit/s) ! Cela est suffisant pour faire du… FTP ou du Telnet (haaaa NCSA Telnet !).

Cela permet de se rendre compte qu’entre 1990 et 1995 se connecter à Internet et à ses services ( gopher, WWW, etc.) n’était pas si évident pour qui avait investi dans les années 80 dans un macintosh. Il est intéressant de voir aussi que les « couches » de protocoles, services étaient encore bien visibles et séparées les unes des autres. PPP d’un coté pour établir la connexion, MacTCP pour la couche TCP/IP, MacWWW (de Robert Cailliau !), Eudora pour les emails (et encore sur le port 25 en SMTP c’est dur aujourd’hui… Mais mon synology est là pour faire le pont…)… Refaire vivre la technologie d’il y a juste 20 ans n’est pas simple mais on y arrive.

Prochaine étape :

1/ Mettre en place MacWeb premier navigateur web pour Mac OS ! Mais là j’ai besoin de passer le Macintosh Plus sous system 7.0.x, et là, les 4 Mio de RAM vont être justes…

2/ Ecrire un billet dans mon blog présentant tout cela !

PS : Je ne suis pas le premier à le faire … Jeff (http://www.keacher.com/…/how-i-introduced-a-27-year-old-co…/) m’a bien aidé d’ailleurs ! merci à lui…

Ca, mais si souviens toi, c’était où déjà ? ou le geocaching scientifique

Pour noël, j’ai eu un GPS ! Ceux qui me connaissent me diront que n’ayant pas de voiture à Paris, ce n’est pas très utile. Et pourtant, si l’ont veut géo-référencer les photos de noël et le déballage des cadeaux par les enfants, cet outil devient très pratique, testons un peu…

D90+GP-1

J’ai donc un GPS pour mon D90 : il s’agit de l’unité GP-1, qui se place à la place du flash ou sur le coté. Pour info, dans le Nikon P.6000, un compact, le GPS est en standard.

Mes grands-parents, s’ils étaient en vie, diraient : « Mais que fait Stéphane, dans le jardin, avec un appareil photographique pointant vers le ciel ? » Au début, la première capture des satellites est un peu longue : plus de 5 s., c’est déjà embêtant si vous devez déclencher tout de suite… passons. En laissant l’appareil en veille, ça va mieux. Ensuite cela semble assez précis (même dans le jardin), l’altitude aussi (testé avec un bon vieil altimètre).

D90+GP-1

Clic-clac, les coordonnées et l’altitude sont bien capturées et incluses dans les méta-données EXIF de l’image. Avec Exiftool (et tous les outils qui tourne autour), par exemple, il est facile de voir et d’exporter ces valeurs de positionnement (extrait) dans ExiftoolGUI…

D90+GPS_1

De les sortir sous la forme d’un tableau HTML (voir plus bas)…

EXIF GPSVersionID 2.2.0.0
EXIF GPSLatitudeRef North
EXIF GPSLongitudeRef West
EXIF GPSAltitudeRef Above Sea Level
EXIF GPSTimeStamp 11:24:24
EXIF GPSSatellites 05
EXIF GPSMapDatum
EXIF GPSDateStamp 2008:12:25
Composite GPSAltitude 36 m Above Sea Level
Composite GPSDateTime 2008:12:25 11:24:24
Composite GPSLatitude 44 deg 45′ 15.21″ N
Composite GPSLongitude 0 deg 34′ 31.58″ W
Composite GPSPosition 44 deg 45′ 15.21″ N, 0 deg 34′ 31.58″ W
Composite SubSecDateTimeOriginal 2008:12:25 13:21:45.00

…Et bien entendu, il est très facile d’exploiter cela avec un outil cartographique en local, tel que l’excellent GeoSetter dont une version en français est disponible :

D90+GPS_2

D90+GPS_3
ou bien via l’outil carte de Flickr (là, rien à faire de particulier, les photos sont positionnées par défaut lors du chargement).

Tout cela peut aussi ce faire via son Firefox avec IExif, Dans la monde Google avec Picasa et Google Earth, etc.

Si le format EXIF vous pose un problème, il est possible de stocker ces données dans du MIX. C’est évidement plus complexe pour l’exploitation, du moins pour le grand public.

Extraire ce type de méta-données avec du Perl est très facile : le programme perl exiftool de Phil Harvey est très bien pour cela : une petit ligne du type « Exiftool -exif:GPSAltitude -h  img > mes_exifs.html » et l’on récupère l’altitude d’une série d’images dans un tableau HTML.

Avec du PHP c’est possible aussi : il faut charger les extensions php_mbstring et exif (dans cet ordre) dans le php.ini ; ensuite il est possible d’utiliser la fonction exif_read_data.

Bref, bientôt TOUS les appareils géo-tagueront en automatique et l’on ne comprendra pas pourquoi les photos anciennes ne le sont pas (les documentalistes vont avoir du travail) : ainsi les interfaces d’intérogations vont évoluer : un fond de carte, des outils de sélection (ronds, carrés, etc.), des plots de couleurs, des requêtes externes, des réponses aux questions qui s’afficheront sous la forme d’un chapelet de marqueurs. Au CN2SV, nous avons commencé à le faire des cartes et des atlas anciens, j’imagine ce que nous allons faire dans quelques années !

Capture d'écran de l'application CN2SV pour les géodonnées

Mais j’y pense… le temps d’écrire ce billet et tout cela doit déjà exister, j’en suis sûr (et en open-source ?). En attendant la suite, j’espère que les artistes vont trouver des applications moins « utiles » que celles décrites ici. Je m’en retourne à mon mash-up de noël.

Joyeuses fêtes,

Stéphane.

Frises chronologiques sur le web : utilisation de Timeline pour faire un mashup AJAX avec PHP et MySQL

Bonsoir,

Je profite d’un week-end loin de Paris et d’un long voyage en train pour décrire (mais avec beaucoup de retard) un petit mashup que j’ai réalisé pour le site @.ampère et l’histoire de l’électricité. L’idée de départ était de développer des chronologies avec l’outil Timeline mis au point par le MIT et que pas mal de développeurs connaissent et utilisent. Timeline permet de créer des frises chronologiques à l’image de celles encore présentes dans les livres scolaires d’histoire (nous avons tous rêvés devant ces frises en couleurs présentant l’histoire de l’Homme par exemple). C’est outil utilise des éléments en javascript et du XML : c’est donc un système basé sur AJAX. Dans le site @.ampère nous voulions faire une frise avec des éléments historiques différents le tout devant être synchronisé :

  • une sous-frise sur les grands personnages de l’histoire de l’électricité
  • une sous-frise sur les grandes découvertes de ce même domaine

Dans Timeline, les évènements (events) sont stockés dans un fichier XML très simple. Dans le but d’inclure Timeline dans le système d’information (SI) du site, nous avons utilisé deux tables MySQL pour mettre les données brutes (date, contenu de l’évènement, etc.). Un script PHP utilisant DOM réalise alors une présentation XML de ces données : en sortie, nous avons deux fichiers XML, un pour chaque sous-frise, qui sont normés suivant le schéma des fichier nécessaire au fonctionnement de Timeline. Nos deux tables MySQL sont indépendantes du système AJAX de Timeline : c’est PHP/DOM qui formate les données en XML suivant la grammaire Timeline. Nous avons d’ailleurs un autre programme PHP qui présente ces même données sous la forme d’une page web classique. Le schéma suivant en résume le modèle :

Modèle informatique de frise chronologique (site www.ampere.cnrs.fr)

Les deux fichiers XML sont stockés dans un répertoire du serveur et chargé dans l’application AJAX qui gère Timeline. Le XML resemble à ceci :

<?xml version="1.0" encoding="iso-8859-1"?><data>

<event start="Jan 00 1544 00:00:00 GMT" end="Jan 00 1603 00:00:00 GMT" 
image="AMP_1015.jpg" isDuration="true" title="William GILBERT">(1544-1603)</event><event start="Jan 00 1666 00:00:00 GMT" end="Jan 00 1736 00:00:00 GMT" 
isDuration="true" title="Stephen GRAY">(1666-1736)</event> ...
</data>

Pour le tout fonctionne, il nous a fallu ajouter un petit programme php de vérification de la forme des dates/heures histoire de ne pas avoir de bug dans l’une des deux sous-frises. Pour terminer nous avons ajouté, dans le fichier javascript de la frise (main.js) qui pilote l’affichage écran, les instructions suivantes :

bandInfos[1].eventPainter.setLayout(bandInfos[1].eventPainter.getLayout());

tl = Timeline.create(document.getElementById("my-timeline"), bandInfos, Timeline.HORIZONTAL);

Timeline.loadXML("kronos1.xml", function(xml, url) { eventSourceA.loadXML(xml, url); });

Timeline.loadXML("kronos2.xml", function(xml, url) { eventSourceB.loadXML(xml, url); });

Nous avons une « bandInfos » dans laquelle nous « chargeons » les deux fichier XML : kronos1.xml et kronos2.xml. Ce chargement est réalisé au sein des deux eventSource (A et B). Ce fichier, main.js, qui est un fichier javascript pur est chargé dans une page HTML (ou PHP dans notre cas) par l’utilisation d’une simple balise <script> dans l’entête. La frise « double » est ensuite affiché dans le code HTML via un « id » de balise <div> :

<div id="my-timeline" style="height:800px; width:100%;"></div>

Le tour est joué, nous avons une belle frise chronologique présentant de façon synoptique ces deux types d’évènements. Voici le résultat :

FriseChronoAmpere

Bonne fin de week-end,

Stéphane.

PS : Merci à Marie-Hélène Wronecki pour le travail sur la base de données MySQL.

ICEberg 4 sur les rails.

Bonsoir,

Je profite des vacances pour avancer la mise en place d’ICEberg 4 ! Les tests avancent plutôt bien : il est sûr que préparer la nouvelle version de mon gestionnaire de corpus numériques au bord d’une piscine c’est assez génial : un plouf entre deux class php. Mes deux compagnons de programmation de cette nouvelle version : Romain et Frédéric ont maintenant terminé leur travail, j’ai pris la suite pour assembler les blocs, débuguer, relire, reprendre, améliorer le tout. ICEberg 4 s’appuyera sur MySQL et PHP 4 ou PHP 5 (nous avons prévu les deux versions au cas ou…la version « tout XML » : ICEbergXML reste toujours disponible…). La partie « berg » est nettement plus opérationnelle : les chercheurs maitrisant l’informatisation de leurs propres corpus vont être contents ! la partie ICE reste dans la même idée que celle de la version 3 : nous n’avons changé que de petites choses sur le plan de l’interface. Cependant, le code a été totalement ré-écrit par Frédéric avec des class en PHP 5.

L’autre jour, un chercheur me demandait pourquoi j’avais fait un outil « propre » alors qu’il en existe plein sur le web tel que PLEADE, ARCANE, etc. Je lui est dit qu’il arrive un moment ou il faut développer un outil dédié pour répondre à une demande forte qui apparaît. Il existe Photoshop, pourtant des programmeurs ont développé GIMP ! ICEberg répond à un besoin : la mise en ligne et la gestion de paquets de documents numériques (d’archives, issus de documents actuels, des photos, bref tout type de documents numérisés) en utilisant un gestionnaire de base de données « libre » ou du XML, rien de plus. J’ajoutais qu’il n’y a pas de moteur recherche puissant dans ICEberg, j’en prépare un avec l’aide du CNRS mais il ne sera pas dans ICEberg, mais il fonctionnera au-dessus ; balayant ainsi l’ensemble des corpus numériques, même chose pour le module OAI d’ICEberg.
Ainsi, ICEberg tend toujours vers le plus simple : des modules y sont ajoutés, mais toujours de façon annexe, sans toucher au noyau. Mais de temps en temps, nous réécrivons une nouvelle version de la partie « dure » d’ICEberg : nous y sommes.

Je m’en retour à mon code :-). Bonne soirée, Stéphane.

ICEberg 4 béta.

Bonjour, Nous allons sortir ICEberg 4.0.1 en version béta avec une démo sur le serveur du CRHST (http://www.crhst.cnrs.fr). ICEberg, le produit phare qui permet à nos corpus numériques de tourner a été totalement re-programmé par notre équipe (Frédéric Costantini, Romain Mindchella, sous ma direction et avec l’aide et les conseils de Lucie Secchiaroli, Delphine Usal, Christine Blondel, Marie-Hélene Wronesky et Françoise Cornière). Il est compatible avec PHP 5 et MySQL 4. D’un simple ensemble de scripts écrit en PHP, ICEberg est devenu un CMS ou plutôt un CM2S : Content Management System for Science.

Cette refonte d’ICEberg va d’ailleurs aller plus loin, ICEberg 4.0 changera de nom en octobre 2006 et il sera diffusé sous licence CeCILL. Car le concept de l’outil a évolué.

Stéphane.

ICEberg : présentation générale

ICEberg est un outil de gestion de corpus scientifiques en ligne. Il permet la mise sur internet de collections de documents numériques en séparant la nature du document de son traitement scientifique (qui peut-être réalisé par d’autres outils). Ce n’est pas un CMS (tel que SPIP, Plone, etc.) ni un outil de publication ou d’édition en ligne (avec une charte éditoriale et des styles par exemple), c’est un gestionnaire simple de données textes ou images (jpg, png ou gif), mais il est composé de deux blocs : ICE (partie de navigation) et berg (partie de gestion). Il est programmé en PHP et fonctionnant avec MySQL. Cet outil a une histoire qui est liée à mon parcours professionnel. Vous pouvez en savoir plus avec le powerpoint suivant sur les dernières infos d’ICEberg : http://halshs.ccsd.cnrs.fr/halshs-00006568.

1) L’histoire d’ICEberg : histoire de l’outil et parcours de fin d’étudiant

En 1997, au cours de ma maîtrise d’histoire (UMR Ausonius – Service Informatique de Recherche en Archéologie dépendant de l’Université de Bordeaux 3 et du CNRS), j’ai été confronté à la question de la mise en ligne de mes sources historiques. Très rapidement et sous la direction de Robert Vergnieux et de Gérard Louise, j’ai du trouver un outil simple de gestion de base de données en ligne (voir : http://www-sira.u-bordeaux3.fr/boisset/). Dans mon travail de maîtrise et de DEA j’ai travaillé avec le logiciel DBMAN créé par Gossamer Threads Inc. DBMAN est outil de gestion de fichier .txt écrit en perl. DBMAN est un shareware. Il est cependant limité car il ne permet pas de faire du relationnel entre les bases de données. J’ai donc commencé à concevoir un outil propre s’appuyant sur un modèle de table très simple dont le but fut de séparer le contenant du contenu. Travaillant sous la direction de Robert Vergnieux et avec Jacques Perconte sur ce sujet nous avons créer le tabloïde (là aussi du perl et des fichiers .txt pour les tables : permettant un stockage pérenne des données). Le tabloïde permet la gestion simple de galerie d’images en ouvrant un lien vers une gestion du contenu scientifique de façon ad hoc.

Lors de mon DEA d’histoire à Bordeaux 3, j’ai créé un autre outil à l’aide de DBMAN qui permet de gérer du VRML de façon dynamique : c’est le SIHA3D qui est d’ailleurs de précurseur d’ICEberg (voir : http://www-sira.montaigne.u-bordeaux.fr/boisset/cgi/vrml/db.cgi?db=default&uid=default) et surtout ce résumé du process : http://www.technart.net/metamorph/mem/STEPHANE/.

Je passe mon DEA…puis vint le PHP et MySQL…:-)

Entre 1999 et 2001 j’ai commencé à développer en PHP et avec MySQL des outils proches du SIHA3D à destination d’autres disciplines la géographie, l’histoire, la documentation (voir RAFID www.rafid.u-bordeaux.fr. C’est la période ou ICEberg est né. J’avais du temps – j’étais encore étudiant :-) – et PHP+MySQL m’ont permis de développer un outil simple (des scripts en PHP) et sur un modèle de tables relationnelles sous MySQL (nommé « la triplette ») qui permet de faire fonctionner le tout.

En 2002…Je rentre sur concours au CNRS en tant qu’IE !

Je suis affecté dans l’UMR 2139 (aujourd’hui regroupée avec le Centre Koyré – UMR 8560). Je suis le webmestre de l’équipe et je travaille sur le site www.lamarck.net créé par Pietro Corsi (Professeur à l’Université de Paris 1 et à l’EHESS et aujourd’hui professeur à Oxford). Le site Lamarck fonctionne en ASP+ACCESS avec l’outil PINAKES développé par Andrea Scotti en Italie (Florence). Le serveur est installé à l’ENS sur une machine windows. Très rapidement le développement du site nécessite un changement de technologie : l’ASP est peu fiable en terme de sécurité (c’est un mystère pour personne) et ACCESS est limite pour gérer les 10.000 pages de manuscrits + les 19.000 planches d’herbier que Pietro Corsi souhaite ajouter au site. Personnellement je connais bien mieux le PHP que l’ASP que je trouve lourd en terme de développement et gourmant en ressources. Sortant ICEberg de mes tiroirs, nous avons donc mis ICEberg en production pour le site Lamarck. Le basculement ACCESS vers MySQL n’a pas été simple. Nous avons tout re-modélisé en utilisant la triplette plutôt que les 40 tables ACCESS (je ne me souviens plus du chiffre exact en fait, mais c’était pas « migrable » en tout cas !).

En 2002, je réalise pour le Lamarck un ICEberg V0.1 qui fonctionne toujours sur le serveur. Nous créons avec cette version le site Lavoisier avec association avec Marco Beretta (Panopticon Lavoisier) et le site Science 1800 (créé par Pietro Corsi).

En 2003, Je sort la version 0.7 : première version ayant la forme actuelle (avec les menus en haut). Le site Lamarck bascule dans cette version. Bien entendu les version 0.1 et 0.7 sont compatibles…

En 2004-2005 : Nous montons les sites www.ampere.cnrs.fr, www.buffon.cnrs.fr, www.histmap.net, www.hstl.crhst.cnrs.fr/criminocorpus avec la version ICEberg 0.7 puis 1.0.

En juillet 2005, je réalise la version ICEberg-XML (expérimentale et n’utilisant plus MySQL, juste des fichiers XML). Nous avons donc aujourd’hui deux outils :

  • ICEberg-DB : PHP+MySQL
  • ICEberg-XML : PHP5+XML

ICEberg est le fruit d’un travail commencé en 1997 lors de ma maîtrise d’histoire et il n’aurait pas vu le jour sans le soutien de Robert Vergnieux (IR CNRS), Gérard Louise (Professeur des Universités) aujourd’hui décédé, Michel Bochaca (Professeur des Universités), Jean-Michel Roddaz (alors directeur d’Ausonius). Mais également de Daniel Pouyllau (IR CNRS), Marie-France Pouyllau et mon épouse Jannick.

Ainsi que Gwenaëlle Boulissière, Anne Dubois, Jacques Personte, Marie Péres, Pietro Corsi, Dominique Pestre (Directeur d’Etudes à l’EHESS), Vincent Leguy, Delphine Usal, Lucie Secchiaroli, Olivier Bertoncello.

2) Caractéristiques

ICEberg est un outil au sens ou il rend un service entre un serveur Apache et un chercheur : c’est donc un service web développé en PHP 4.3 et fonctionnant sous MySQL 4.0.x dans sa version actuelle. Il permet la diffusion de documents structurée. Il est un élément (une brique!) de base dans la construction d’un site web de recherche. Il est programmé en fonctions PHP. Il est compatible avec Verity via XVgateway.

3 ) Développement

J’assure le développement d’ICEberg. Le rythme n’est pas régulier pour le moment car je suis seul à y travailler en tant que codeur. Un jour, je monterai une équipe CNRS peut être ;-). J’ai en ce moment une petite équipe de bénévole qui travaille avec moi.

4) Mini-FAQ

ICEberg est-il libre ou open source ? :

Non, son code n’est pas encore ouvert et sa diffusion n’est pas encore possible car l’outil n’est pas terminé pour une exploitation par des tiers. Je pense mettre un jour ICEberg sous licence CeCILL.

Est-il gratuit ?

Quand il sera diffusable, il sera gratuit (sous licence CeCCIL).

Fièrement propulsé par WordPress & Thème par Anders Norén