J'avais déja parlé du projet de cartographie libre :openstreetMap dans un post précedent.
Christophe CAZIN a lui, posté ce message sur le forum 'service public' :
Une série d'articles très intéressants sur OpenStreetmap et ses acteurs.
"Mais la vraie bonne surprise était que la DGFiP a offert à OpenStreetMap l’accès à son Web Map Service. Concrètement, cela signifie qu’un plug-in pour le logiciel JOSM peut télécharger les données cadastrales directement depuis les serveurs de cadastre.gouv.fr, et les afficher par-dessus les tracés de routes comme un calque supplémentaire." (extrait d'un des articles)
Merci donc à la DGFiP ...
J'ai constaté récemment que mon téléphone Galaxy Android n'est pas le seul à pouvoir afficher les cartes d'Openstreetmap (avec l'application AndNav2): les GPS de marque Garmin, pour certains modèles, peuvent intégrer des cartes extérieures sur des modules mémoires sd-card et proposer les cartes d'Openstreetmap (L'europe entière est disponible).
Pas besoin donc de connections 3G et d'abonnement web illimité pour profiter d'une cartographie mobile de terrain libre ...
Voici un des modèles :
http://www.maisondugps.com/GPS-de-randonnee/GARMIN/6520,(010-00630-01)-GPS-Garmin-Etrex-Vista-Hcx.html
La chaine de liaison usb avec les modèles GARMIN fonctionne parfaitement sous Linux (Mandriva et Ubuntu ): J'ai testé !
Cartes de France pour GPS GARMIN :
http://fredericbonifas.free.fr/osm/garmin.html
Des dizaines d'applications libres arrivent tout les jours sous Linux, Windows , (et ANDROID) pour exploiter ces données dont le spectre d'utilisation libre laisse place à une grande créativité ! (sport, transports, tourisme, services, urgences, radars , surveillance etc ...)
Quelques logiciels : Navit, Viking , Gpsbabel , Gpsd , JOSM etc ...
Christophe
PS: je suis en train de corriger le plan de la Baule pour ajouter tous les sens uniques que j'ai relevé il y a quelques semaines sur le terrain !
Les routards du web : « Nous sommes comme des fourmis »
http://www.ecrans.fr/Les-routards-du-web-Qui-sont-ils,7888.html
par Camille Gévaudan
mardi 25 août 2009
lundi 24 août 2009
Le sinclair ZX81
J'ai remis en marche mon prmier ordinateur le zinclair ZX81 acheté en 1980. D'une capacité de 1ko , il était doté d'une extension mémoire de 16ko.
Je l'avais démonté pour le loger dans un boitier muni d'un vrai clavier.
Le guide utilisateur était vraiment très bien fait. Il donnait toutes les adresses système.
J'ai même retrouvé des vidages de programmes en langage machine
quelques liens sur le zx81:
wikipedia
jeudi 23 juillet 2009
Prise en main de couchDB
L'installation de couchDB ne pose de problème avec les gestionnaires de paquets. Le système installe le programme erlang/OTP qui comporte un shell erlang. C'est dans ce langage que seront traité les requetes HTTP et traduite les fonctions javascript.
Sur une Debian, l'installation lance les programmes suivants:
Un script qui gèrera le daemon (usr/bin/couchdb) et le shell erlang (beam) .
Configuration
Le fichier de configuration couch.ini se trouve sous le répertoire /etc/couchdb
Il ressemble à ceci : (j'ai ajouté des commentaires en fin de ligne)
(remarque : couchDB est un projet Apache mais n'utilise pas de serveur Apache.)
L'interface d'administration: FUTON
Elle s'affiche à l'adresse suivante : http://127.0.0.1:5984/_utils
Cette interface permet de tout faire : création d'une entrée, réplication , statistiques.
Créer deux instances de couchDB.
Pour réaliser des essais de réplication , il est parfois necessaire de creer deux instances sur la même machine. Il faudra définir deux ports d'ecoute , avoir deux répertoire de données etc.
Commencons par duppliquer le fichier couch.ini en couch2.ini
Puis il faut éditer couch2.ini et modifer ces lignes :
Il faut créer avec les bons droits les répertoires pour la deuxième instance. Et copier les fichiers existants de la première instance vers les répertoires de la deuxième instance. Le répertoire DbRootDir des fichiers BTREE peut etre vide. Il sera mis à jour par le mécanisme de la réplication.
Afin on lancera les deux services par en prenant soin d'arrêter préalablement le service couchDB (/etc/init.d/couchdb stop )
couchdb -c /etc/couchdb/couch.ini &
couchdb -c /etc/couchdb/couch2.ini &
Voila , on est prêt pour essayer la réplication.
Sur une Debian, l'installation lance les programmes suivants:
2575 ? S 0:00 /bin/sh -e /usr/bin/couchdb -c /etc/couchdb/couch.ini -b -r 5 -p /var/run/couchdb.pid -o /dev/null -e /dev/null -R
2576 ? Sl 0:01 /usr/lib/erlang/erts-5.6.3/bin/beam -Bd -- -root /usr/lib/erlang
-progname erl (),.........
receive done -> done end. -couchini /etc/couchdb/couch.ini -pidfile /var/run/couchdb.pid -heart
Un script qui gèrera le daemon (usr/bin/couchdb) et le shell erlang (beam) .
Configuration
Le fichier de configuration couch.ini se trouve sous le répertoire /etc/couchdb
Il ressemble à ceci : (j'ai ajouté des commentaires en fin de ligne)
[Couch]
ConsoleStartupMsg=Apache CouchDB is starting. #message d'accueil
DbRootDir=/var/lib/couchdb # repertoire des fichiers BTREE
Port=5984 # port d'ecoute
BindAddress=127.0.0.1 # adresse de l'interface reseau
DocumentRoot=/usr/share/couchdb/www # repertoire de stockage des pages web d'administration
LogFile=/var/log/couchdb/couch.log # les logs
UtilDriverDir=/usr/lib/couchdb/erlang/lib/couch-0.8.0-incubating/priv/lib
LogLevel=info #log level (info ,debug)
[Couch Query Servers]
javascript=/usr/bin/couchjs /usr/share/couchdb/server/main.js
(remarque : couchDB est un projet Apache mais n'utilise pas de serveur Apache.)
L'interface d'administration: FUTON
Elle s'affiche à l'adresse suivante : http://127.0.0.1:5984/_utils
Cette interface permet de tout faire : création d'une entrée, réplication , statistiques.
Créer deux instances de couchDB.
Pour réaliser des essais de réplication , il est parfois necessaire de creer deux instances sur la même machine. Il faudra définir deux ports d'ecoute , avoir deux répertoire de données etc.
Commencons par duppliquer le fichier couch.ini en couch2.ini
Puis il faut éditer couch2.ini et modifer ces lignes :
portable:~# diff /etc/couchdb/couch.ini /etc/couchdb/couch2.ini
5c5
< consolestartupmsg="Apache"> ConsoleStartupMsg=Apache CouchDB instance 2 is starting.
7c7
< dbrootdir="/var/lib/couchdb"> DbRootDir=/var/lib/couchdb2
9c9
< port="5984"> Port=5985
13c13
< documentroot="/usr/share/couchdb/www"> DocumentRoot=/usr/share/couchdb2/www
15c15
< logfile="/var/log/couchdb/couch.log"> LogFile=/var/log/couchdb/couch2.log
Il faut créer avec les bons droits les répertoires pour la deuxième instance. Et copier les fichiers existants de la première instance vers les répertoires de la deuxième instance. Le répertoire DbRootDir des fichiers BTREE peut etre vide. Il sera mis à jour par le mécanisme de la réplication.
Afin on lancera les deux services par en prenant soin d'arrêter préalablement le service couchDB (/etc/init.d/couchdb stop )
couchdb -c /etc/couchdb/couch.ini &
couchdb -c /etc/couchdb/couch2.ini &
Voila , on est prêt pour essayer la réplication.
Des petites amies comme ca , c'est de la science fiction
C'est trop beau pour étre vrai. vous avez une adresse ?
D'un autre coté à la place du mec , j'aurais un peu des scrupules.
C'est peu etre un faux? , Une fille ne dit pas 'xbox' elle dit: ta p..... de console de m.... qui va voler par la fenêtre.
mardi 21 juillet 2009
Hacker gentiment une imprimante
Un petit coup de telnet sur le port de l'imprimante :
portable:~# telnet ip.ip.ip.ip 9100
Trying ip.ip.ip.ip...
Connected to ip.ip.ip.ip.
Escape character is '^]'.
@PJL RDYMSG DISPLAY="je suis une imprimante qui a besoin d'affection"
^]
telnet> quit
Connection closed.
Hop => le message s'affiche sur le panneau de controle de l'imprimante.
Le concours du meilleur message est ouvert.
lundi 20 juillet 2009
On a marché sur la lune
Il y a 40 ans, j'étais aux Lecques en bord de mer a attendre désespérement que le LEM se pose. On était tous autour de la télé, la nuit était chaude, l'attente était longue parfois meublée par des dessins animés. Je ne comprenais pas pourquoi la NASA n'utilisait pas la même technique que celle du professeur Tournesol dans tintin : la fusée de départ se pose tout simplement sur la lune pour repartir à la fin de la mission. Je me suis couché, puis mon frère est venu me réveiller pour assister aux premiers pas sur la lune. A partir de cet instant, j'ai regardé la lune d'un air différent. Mais pour moi, le professeur Tournesol restera le meilleur.
mercredi 15 juillet 2009
CouchDB : plus qu'un composant phrare du web 2.0: un révolution
CouchDB se présente comme une base de données documentaire. Cette phrase est réductrice par rapport aux concepts mis en pratique par couchDB. C'est en effet un concentré de technologies et de bonnes idées.
Je vais détailler 5 idées de base et aborder des concepts généraux..
CouchDB est une base de données orientée document. Elle stocke des documents et leurs pièces jointes comme les images par exemple.
CouchDB est capable d'exécuter des procédures stockées, ecrites en javascript.
Enfin coucheDB est ecrit en Erlang afin d'optimiser les performances. Il possède une interface de communication HTTP de type REST qui délivre ses réponses en JSON.
Principes
1) Les bases de données relationnelles ne sont pas toujours adaptées à notre 'vrai' univers.
Exemple : comment stocker des cartes de visites dans une BDDR ? : il faut créer une table pour les noms , prénoms , une autre table pour les téléphones une autre pour les mails. Une base de données relationnelle doit au moins respecter les trois formes normales (voir les rappels ici) . On se retroucve parfois avec des tables avec des champs vides.
2) On utilise de plus en plus souvent comme index un champ numérique autoincrémenté.
Cette solution permet d'avoir un identifiant technique non significatif. Mais cela rend très difficile le partitionnement des données. En fusionnant plusieurs sources de même nature, il va y avoir forcement des doublons dans les identifiants.
3) Les techniques d'historisation dans une BDDR coûtent chères et sont complexes. Pourtant, il existe une solution simple dans le monde du développement : le versionning (Subversion , GIT)
4) Les applications qui ont besoin de performance doivent êtres simples : Architecture REST, pas de verrous bloquants.
Avec REST , le client et non pas le serveur est chargé de conserver l'état des transaction. Cette opération est très limitée car les transactions sont atomiques et auto-suffisantes.
Un document qui est en cours de modification ne doit pas empêcher les services de délivrer sa version la plus récente à d'autres clients.
5) Il doit être possible de réaliser des opérations de masse sur les éléments stockés dans la base : c'est l'utilisation du Map and Reduce comme procédures stockées par le serveur.
Concepts généraux : le diagramme de CAP.
Ainsi couchDB se veut comme un système de base de données 'documentaires' évolutif et performant.
Le positionnement de couchDB peut se faire par rapport au diagramme de 'CAP'
C = Consistance des données , A = disponibilité des données (availability) et P = tolérance au Partitionnement des données. Chaque notion est un cercle, chaque cercle possède 2 points d'intersection avec les autres cercles (comme une rosace)
A l'intersection du cercle de la disponibilité et de la consistance des données on trouvera un protocole comme 'paxos' qui est utilisé dans le projet Chubby de Google : Les données sont disponibles et consistantes mais centralisées.
Les BDDR se placeront à l'intersection du cercle 'consistance' et 'partitionnement' : les données sont intègres , partageables sur des nœuds de cluster mais la disponibilité reste un problème. Exemple : il est facile de faire une base de données 'maitre' et des replicats, mais l'opération d'écriture ne pourra se faire que sur l'instance Maitre.
CouchDB se place à l'intersection de consistance et de disponibilité. Les données d'une base ne peuvent pas être nativement partitionnées sur plusieurs serveurs. Cette dernière contraintes est mineure par rapport aux deux autres facteurs. Cela ne vaut pas dire qu'il n'y ait pas un système de réplique, bien au contraire , couchDB est multi-maitre.
Les versions de document.
CouchDB utilise le MVCC (multi Version concurrency control) : gestion des versions multiples concurrentes. Cela veut dire qu'il n'utilise pas de verrou. Le client peut toujours obtenir la version la plus récente de l'entrée. Dès que le changement sera 'propagé' , c'est cette version qui sera disponible. Un client désirant envoyer une modification doit toujours indiquer sur quelle version il travaille.
L'identifiant des documents
CouchDB utilise des Universally Unique Identifiers (UUID) qui sont déterminés soit par le client soit par le serveur.
Un exemple d'entrée:
Exemples de manipulations
curl http://localhost:5984/_all_dbs
Curl est un client HTTP en ligne de commande
La réponse du serveur :
["essaidb"]
La réponse est en JSON.
Interrogation de tous les documents :
curl http://localhost:5984/essaidb/_all_docs
{"total_rows":5,"offset":0,"rows":[
{"id":"7a1f52b2a0a7c74de7cba2f35b314ce9","key":"7a1f52b2a0a7c74de7cba2f35b314ce9","value": {"rev":"425879379"}},
{"id":"cbc79bccbc338e05abfb2932cf67a888","key":"cbc79bccbc338e05abfb2932cf67a888","value": {"rev":"707723218"}},
{"id":"encoreunessai","key":"encoreunessai","value":{"rev":"517881535"}},
{"id":"essaieric","key":"essaieric","value":{"rev":"12590446"}},
{"id":"essaisuite","key":"essaisuite","value":{"rev":"3012959012"}}
Mais aussi
CouchDB permet de redéfinir le mode de sortie, en remplaçant le JSON par du HTML. De même, il permet de programmer ses propres vues. Ainsi ,il est possible de réaliser des véritables apllications sans rien d'autre que couchDB
Je vais détailler 5 idées de base et aborder des concepts généraux..
CouchDB est une base de données orientée document. Elle stocke des documents et leurs pièces jointes comme les images par exemple.
CouchDB est capable d'exécuter des procédures stockées, ecrites en javascript.
Enfin coucheDB est ecrit en Erlang afin d'optimiser les performances. Il possède une interface de communication HTTP de type REST qui délivre ses réponses en JSON.
Principes
1) Les bases de données relationnelles ne sont pas toujours adaptées à notre 'vrai' univers.
Exemple : comment stocker des cartes de visites dans une BDDR ? : il faut créer une table pour les noms , prénoms , une autre table pour les téléphones une autre pour les mails. Une base de données relationnelle doit au moins respecter les trois formes normales (voir les rappels ici) . On se retroucve parfois avec des tables avec des champs vides.
2) On utilise de plus en plus souvent comme index un champ numérique autoincrémenté.
Cette solution permet d'avoir un identifiant technique non significatif. Mais cela rend très difficile le partitionnement des données. En fusionnant plusieurs sources de même nature, il va y avoir forcement des doublons dans les identifiants.
3) Les techniques d'historisation dans une BDDR coûtent chères et sont complexes. Pourtant, il existe une solution simple dans le monde du développement : le versionning (Subversion , GIT)
4) Les applications qui ont besoin de performance doivent êtres simples : Architecture REST, pas de verrous bloquants.
Avec REST , le client et non pas le serveur est chargé de conserver l'état des transaction. Cette opération est très limitée car les transactions sont atomiques et auto-suffisantes.
Un document qui est en cours de modification ne doit pas empêcher les services de délivrer sa version la plus récente à d'autres clients.
5) Il doit être possible de réaliser des opérations de masse sur les éléments stockés dans la base : c'est l'utilisation du Map and Reduce comme procédures stockées par le serveur.
Concepts généraux : le diagramme de CAP.
Ainsi couchDB se veut comme un système de base de données 'documentaires' évolutif et performant.
Le positionnement de couchDB peut se faire par rapport au diagramme de 'CAP'
C = Consistance des données , A = disponibilité des données (availability) et P = tolérance au Partitionnement des données. Chaque notion est un cercle, chaque cercle possède 2 points d'intersection avec les autres cercles (comme une rosace)
A l'intersection du cercle de la disponibilité et de la consistance des données on trouvera un protocole comme 'paxos' qui est utilisé dans le projet Chubby de Google : Les données sont disponibles et consistantes mais centralisées.
Les BDDR se placeront à l'intersection du cercle 'consistance' et 'partitionnement' : les données sont intègres , partageables sur des nœuds de cluster mais la disponibilité reste un problème. Exemple : il est facile de faire une base de données 'maitre' et des replicats, mais l'opération d'écriture ne pourra se faire que sur l'instance Maitre.
CouchDB se place à l'intersection de consistance et de disponibilité. Les données d'une base ne peuvent pas être nativement partitionnées sur plusieurs serveurs. Cette dernière contraintes est mineure par rapport aux deux autres facteurs. Cela ne vaut pas dire qu'il n'y ait pas un système de réplique, bien au contraire , couchDB est multi-maitre.
Les versions de document.
CouchDB utilise le MVCC (multi Version concurrency control) : gestion des versions multiples concurrentes. Cela veut dire qu'il n'utilise pas de verrou. Le client peut toujours obtenir la version la plus récente de l'entrée. Dès que le changement sera 'propagé' , c'est cette version qui sera disponible. Un client désirant envoyer une modification doit toujours indiquer sur quelle version il travaille.
L'identifiant des documents
CouchDB utilise des Universally Unique Identifiers (UUID) qui sont déterminés soit par le client soit par le serveur.
Un exemple d'entrée:
{
_id:”234567BCD4621D373CADE4E832627B345”,
_rev: 413123,
“Corps”: “ceci est le texte du document“,
"date" :"unbe_date"
}Exemples de manipulations
curl http://localhost:5984/_all_dbs
Curl est un client HTTP en ligne de commande
La réponse du serveur :
["essaidb"]
La réponse est en JSON.
Interrogation de tous les documents :
curl http://localhost:5984/essaidb/_all_docs
{"total_rows":5,"offset":0,"rows":[
{"id":"7a1f52b2a0a7c74de7cba2f35b314ce9","key":"7a1f52b2a0a7c74de7cba2f35b314ce9","value": {"rev":"425879379"}},
{"id":"cbc79bccbc338e05abfb2932cf67a888","key":"cbc79bccbc338e05abfb2932cf67a888","value": {"rev":"707723218"}},
{"id":"encoreunessai","key":"encoreunessai","value":{"rev":"517881535"}},
{"id":"essaieric","key":"essaieric","value":{"rev":"12590446"}},
{"id":"essaisuite","key":"essaisuite","value":{"rev":"3012959012"}}
Mais aussi
CouchDB permet de redéfinir le mode de sortie, en remplaçant le JSON par du HTML. De même, il permet de programmer ses propres vues. Ainsi ,il est possible de réaliser des véritables apllications sans rien d'autre que couchDB
Inscription à :
Articles (Atom)