Ensemble d’outils pour faire de l’édition collaborative de documents. Ce genre d’outils est parfait pour réaliser des documentations techniques où il faut parfois intervenir à plusieurs :
Etherpad, en licence Apache V2. Outil vraiment orienté vers l’édition à plusieurs : il est possible d’écrire à plusieurs sur le même document et il y a une zone de discussion
Substance, en GPLv3. Outil pour faire plus un travail de révision sur des documents : il est possible de commenter chaque paragraphe. Il permet d’avoir plusieurs sorties pour chaque document (ebook, page web, etc…). Se concentre plus sur la sémantique que sur l’apparence.
booktype, en AGPLv3. Présenté sur LinuxFR. Orienté sur l’édition de livres. Permet de générer des formats e-book ou pour édition papier
J’ai rapidement mis en ligne ce que j’appelle la version 1.a. Il est donc maintenant possible de trouver et d’afficher son adresse IP via ipso.me.
J’ai mis à disposition le code source du projet sur Kenai.com (en). Leur service est vraiment clair et pratique. J’ai ouvert un dépôt Mercurial : http://kenai.com/projects/ipsome/sources/hg/show (en). Je découvre l’utilisation d’un gestionnaire de code décentralisé, je ne suis pas encore 100% à l’aise avec car cela change de SVN, mais c’est assez pratique. Il faudra qu’un jour je prenne le temps de lire Subversion Re-education (en).
Pour l’instant le code est vraiment minimaliste, il y a juste un contrôleur qui récupère l’IP du client et la passe à une vue. Mes premières impressions sur l’utilisation de Play! Framework (en) sont très bonnes. C’est vraiment très simple à mettre en place, très simple pour commencer, le tutoriel de départ est bon. J’ai d’ailleurs fait cette version 1.a directement en suivant le tutoriel “Première application (en)” .
Pour le style, j’ai récupéré un template que j’ai déjà utilisé par ailleurs, il a l’avantage d’utiliser le framework CSS1140 CSS Grid (en) qui permet de s’adapter à la largeur de l’écran. Le rendu s’adapte jusqu’aux résolutions des smartphones.
Ce qu’il me reste à faire pour avoir une vrai version 1 :
J’ai trouvé un nom qui va avec un domaine disponible : ipso.me. Bon, maintenant, bien entendu le domaine n’est plus disponible. Pourquoi ipso ? Car c’est court, le domaine en .me est libre. Il contient IP qui fait bien référence à l’adresse IP qu’on veut arriver à déterminer. Le so peut faire référence à « solve » ou « solution ».
IP + SOlve = ipso. Le “.me” indiquant qu’il s’agit de résoudre mon adresse ip.
Ça me parait bien. Le projet sera donc nommé « ipso.me » et ce sera à la fois le nom du projet et du domaine.
La forge
Pour la forge, j’ai envie de tester le système de gestion de version Mercurial. Je m’oriente donc vers la plateforme Kenai qui est très bien intégrée à Netbeans, l’IDE que j’utilise couramment. Depuis le rachat de Sun par Oracle, il était question que Kenai disparaisse pour laisser la place à java.net qui utilise maintenant la plateforme Kenai. Mais il semble que les deux sont actifs en simultanés. Donc on verra, il sera toujours temps de changer. Les autres choix possibles pour Mercurial sont :
Construire une application web permettant d’afficher l’adresse IP des visiteurs. Afficher le maximum d’informations sur :
utilisation d’un proxy,
localisation,
IP dynamique ou statique
Ce projet sera développé de façon itérative et doit me permettre de tester diverses technologies. Le code sera en Java et open-source sous licence Apache 2.0.
Prévision de versions
Version 0 :
Trouver un nom au projet,
Trouver un nom de domaine pour l’installation publique,
Trouver une forge où publier l’application
Version 1 :
Afficher l’adresse IP du visiteur,
Mettre en ligne l’application,
Publier le code sur la forge choisie
Version 1.1 :
Afficher les informations sur l’utilisation de proxy
Version 1.2 :
Afficher les informations de localisation de l’IP via une base de localisation
Version 1.3 :
Permettre à l’utilisateur de tracer ses changements d’adresse via un cookie, ainsi depuis un même poste, il pourra déterminer si il a une adresse IP dynamique.
Version 1.4 :
Si l’utilisateur le permet et si son navigateur le supporte, demander la localisation de l’utilisateur.
Version 2.0 :
Permettre à l’utilisateur d’avoir un compte sur l’application, proposer plusieurs systèmes d’authentification :
Système interne au site,
OpenID
Facebook
Google
Avoir un compte permet de :
Avoir un historique de ses IP, localisations
Supprimer son compte et ainsi effacer toutes les données
La collecte d’information va nécessiter une déclaration à la CNIL
Lorsqu’on développe un programme qui expédie des emails, plutôt que d’utiliser un vrai serveur de mails, il peut être avantageux d’utiliser un faux serveur. L’avantage c’est que cela est intégrable à des tests unitaires et qu’on évite l’erreur de manipulation qui envoie un email à tous les contacts de la base de données.
Il existe plusieurs bibliothèque pour réaliser cela :
devnull smtp : faire un “java -jar DevNullSmtp.jar” pour lancer une interface graphique simple qui permet de lancer un fake serveur sur le port désiré. Il ne peut pas être intégré à des tests unitaires, mais on peut visualiser en direct les messages reçus dans l’interface. Gratuit mais non libre.
Wiser : Bibliothèque Java qui peut être intégrée à des tests unitaires. Licence Apache 2.0
Dumbster : Bibliothèque Java qui peut être intégrée à des tests unitaires. Licence Apache 2.0. Projet sans mise-à-jour depuis 2005.
Des idées, des astuces et archives de toutes sortes sur Java, Linux et le web.