Un GPS tracker dans votre TomTom

Vous avez un TomTom.
Très bien.
Vous en êtes contents et l'histoire pourrait s'arrêter là.

Mais vous en attendez plus. Par exemple, vous aimeriez qu'il vous aide à progresser dans votre entrainement de course (running). Et malheureusement, TomTom ne fournit pas de fonctionnalité de "tracking". C'est ballot tout de même toute cette technologie et pas possible de lui faire enregistrer les positions GPS qu'il acquiert si régulièrement!

Et ben double coup de bol:

1. TomTom est un système ouvert basé sur un Linux
2. Il y a des "bienfaiteurs de l'humanité" (terme consacré d'un de mes meilleurs potes)

Il existe au moins deux solutions pour ajouter cette fonction de tracking à votre TomTom (je suis d'ailleurs persuadé qu'il en existe d'autres et que des solutions équivalentes sont disponibles pour d'autres "GPS"). J'ai donc testé: Event_Logger et Tripmaster.

Pour chacun, on a un site Web très complet mais comme on en faisait il y a plus de 10 ans... (chargé, pas clair, long, ...).

Pour chacun, je n'ai noté aucun problème une fois installé sur le TomTom. Ouf.

Je confesse que je n'ai jamais réussi à obtenir d'Event_Logger qu'il me "suive" lors d'une sortie course (heureusement d'ailleurs, car la dernière n'était pas brillante brillante : j'ai fini le dernier km à 5km/h...). Je n'ai donc pas trop insisté car je suis tombé très vite sur Tripmaster qui est nettement mieux (et a marché du premier coup).

Là où Event_Logger n'a pas vraiment d'IHM dédiée sur le TomTom (on modifie un fichier de config, on court et on espère récupérer un fichier .gpx), Tripmaster vous offre une IHM spécifique (avec une boussole et un tas d'autres fonctions inutiles quand on court ;-) Son paramétrage se fait par une IHM sur le TomTom (la version fichier de config existe bien entendu aussi).

Je le recommande donc très fortement. La seule limite, c'est lors de l'enregistrement des fichiers au format XML (comme .gpx ou .kml), il faut penser à indiquer à Tripmaster de "fermer" le fichier (ben oui, il faut bien fermer toutes ces balises ouvrantes quoi! J'ai souvent été confronté à ce problème quand je développais, et je suis sûr que l'auteur pourrait trouver une solution plus élégante [note to myself: penser à en parler au développeur]).

XML on client-side: the Return (or the Birth, at last!)

Je me souviens qu'il y a qq années, dans les slides des cours sur XML que je donnais, j'avais beaucoup de mal à présenter une solution dans laquelle le processing d'un XML venant du serveur se faisait sur le client (pas de Xeulteu sur le client, temps de transformation prohibitif dans la plupart des cas, ...). Et je préférais donc la solution où le serveur bossait et le client affichait (je vous rappelle que cela remonte à l'époque frénétique de l'ultra-léger sur le poste client et DHTML était pire que de l'assembleur!). Ouf, j'avais donc des excuses! 

Mais maintenant les chose changent (en particulier avec le retour en force des clients "moins" légers; quand on est snob, on dit "smart" en jouant sur les 2 sens de ce terme anglais [joli et intelligent]; quand on est plein de thunes, on va même jusqu'à dire "rich client"). 
Et ben voilà t'y pas que notre bon vieux XML issu du serveur pourrait parfaitement être acceptable dans nos navigateurs (de là à penser mettre Struts et consors à la poubelle?). Vu le nombre de retour (et articles associés) sur XMLHttpRequest (et en particulier XMLHttpRequest et un article de présentation de Sarissa), il est certainement indispensable de conserver cette technique dans un coin de mon cerveau encombré (heureusement que mon //WebLog[@author="ChAP"] est là pour me servir de meta-bookmark!)

Java, DB mapping and XML: a new comer

This is an old problem.
A new player is coming in: iBatis (OSS, of course!). It is really a light framework for accessing a DB allowing you to have total control over the SQL statements your gonna use.
An interesting article on OnJava is presenting the component.
It should be kept in mind that such a framework has its own limitation (one of the most important being not to be used in complex O/R mapping cases).
Obviously, such a solution should be compared to other existing ones (Hibernate, ...)

Oh, XML.

I remember when I posted a project on SourceForge, I had to categorize it (aka Trove Software Map). Among the different attributes I filled in, there was the language (used for development). Because my code was heavily based on XML (for describing a MMI, a little bit 'à la' XUL), I intended to declare XML.
But when browsing through the available languages, I noticed that XML was not promoted as "first class" language (neither second class, BTW!). Which scared me (I avoided a heart-attack, at last ;-)
I e-mailed something like "I know that XML is not a 'real' programming language, but due to the increase of its usages in programming technics, why not adding it". No answers (apart from two other 'sourceforgers': one who agreed and another who talked me about the non-LALR(1) aspect of XML, sic).

Things are perhaps changing with the arrival of o:XML. I let you go through an interesting overview on XML.com (don't be put off by the classical 'HelloWorld' code snippet: the power of that language is not there!). Let me quote something really important about the strength of o:XML:

o:XML is a practical language, designed to solve practical problems. For many types of applications it already provides faster, easier, better solutions than any other technology. If you are writing code that processes or produces XML, chances are you will benefit from using o:XML.

In fact you really can avoid the pain of XSLT (sometimes), and use o:XML to script your output XML (like JSP in fact). But that's not the only use case: it is far more productive to write o:XML than Java (or C#) to produce simple XML.

So, when you have to produce XML as an output, you have the choice of XSLT, XQuery AND o:XML. The later shares with XQuery the advantage of being output format-oriented (try to picture what the output will look like by reading an XSLT stylesheet ;-)

Est-ce Végé?

(For once, I post in this category a french news about SVG; for non french-aware brains, they should retain that: 1°) the title is a (sort of) play on words about SVG, 2°) there are (at least) two OpenSource SVG editor available out there 3°) there is a very good zine in french on SVG - That's all folks!)

Je viens de découvrir 2 éditeurs SVG en OpenSource:

• www.inkscape.org
• www.sodipodi.com

Chacun avec des galleries amusantes (pas mal de manga, mais aussi des logos comme Tux pour Solipodi).
D'ailleurs, à propos de gallerie, il y a http://openclipart.org qui contient tout un lot de dessins bien sympaSVG

Et bien sûr le site français traitant du sujet (http://svgfr.org/). Lequel nous apprend que les fabriquants de téléphones portables s'emballent pour SVG (Sony, Nokia, Siemens).

XSL:for-each-group: a starter

Have you ever encoutered a flat XML file? 
I know it sounds a little bit weird, but they exist; even more, they are very commons. 
In fact, they could be seen as an XML-isation of a trivial flat file (think csv file) or a single RDMS table (I do not mean it is a best practice in the later cases) 
But where I find them very useful is for resources/properties/configuration files (or whatever you call them!): they are files generally edited by hand which contain every single parameter your application mandates for running. 
The flatness comes from the absence of hierarchy: in french, we would say it is a "rateau" (a rake). Here is an exemple of such a rake-file ;-)

<Resources>
   <user name="Gosling" firstname="James" company="Sun" group="guru"/>
   <user name="Kay" firstname="Michael" company="SoftwareAG" group="guru"/>
   <user name="Poirier" firstname="Charles-Antoine" company="WorldCompany" group="beginner"/>
</Resources>

From such a file, very often comes the need to get a hierarchical view; by instance, one focused on 'company' or 'group'.

That hierarchical view could be needed for producing another XML file, sending a stream over the wire or get an in-memory tree-view of those resources.

An example of such an hierarchical perspective could be as follow (I apologize for being too much 'hierarchical' in that example ;-)):

 
<Groups>
   <Group type="guru">
      <Member fromCompany="Sun">
         <FirstName>James</FirstName>
         <LastName>Gosling</LastName>
      <Member>
      <Member fromCompany="SofwareAG">
         <FirstName>Michael</FirstName>
         <LastName>Kay</LastName>
      <Member>
   </Group>
   <Group type="beginner">
      <Member fromCompany="WorldCompany">
         <FirstName>Charles-Antoine</FirstName>
         <LastName>Poirier</LastName>
      <Member>
   </Group>
</Groups>

Obviously to go from <Resources>-XML to <Groups>-XML, you are already thinking to ... XSLT.

To be more precise, you certainly envision XSLT 2.0 which contains a very rich new feature: xsl:for-each-group. It enables you to get something similar to SQL-'Group-By'.

As an example, here the XSLT which allow the aforementioned transformation:

 
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output indent='yes' method='xml' encoding="ISO-8859-1" />
 
<xsl:template match="/">
   <Groups>
      <!-- "sort" 'user' by 'group' -->
      <xsl:for-each-group select="//user" group-by="@group"> <!-- group-by group is not a joke!!! -->
         <xsl:element name="Group"> <!-- Creates a new 'Group' element as needed -->
            <xsl:attribute name="type"><xsl:value-of select="@group"/></xsl:attribute>
 
               <xsl:for-each select="current-group()"><!-- Iterate over the XSL-group to create 'Member's -->
                  <xsl:element name="Member">
                     <xsl:attribute name="fromCompany"><xsl:value-of select="@company"/></xsl:attribute>
                     <FirstName><xsl:value-of select="@firstname"/></FirstName>
                     <LastName><xsl:value-of select="@name"/></LastName>
                  </xsl:element>
               </xsl:for-each>
 
         </xsl:element>
      </xsl:for-each-group>
   </Groups>
</xsl:template>
</xsl:transform>

This is a very simple case where you can take advantage of this wonderful new feature (using Saxon makes it rock!). It leads to very elegant (and readable) XSLT code (and that's not the least)

Robin, c'est un gars 'bat'

Toujours sans polémique sur les navigateurs, il faut quand même reconnaître que Mozilla (ou son prochain successeur: Firebird) permet de faire de bien belles choses.

Vous pointez donc le meilleur navigateur du monde (arrggh çà y est, j'ai craqué! J'suis tombé dans la Paule-Emique! Mais j'me soigne: je rédige ce blog sous IE ;-) Donc vous allez sur Robin chef sf.net (sans tricher: IE ne vous conduira nulle part [du moins ce coup-ci!])
Et là, vous tombez sur une page qui représente ... un desktop; si si, un desktop avec son petit bouton "Démarrer" (enfin "Launch" dans le texte) accompagné de son petit menu déroulant et de l'heure à droite, son fond d'écran psychédélique et le menu associé.
Bon, alors on peut commencer à faire joujou avec les menus. Et là, c'est le festival de l'inutile (donc de l'indispensable): un démineur, un tétris, un pac-man, un astéroïd, un snake, un invaders, ... Chacun dans sa petite fenêtre dans la page Web; et elles bougent, s'iconifient, se maximisent et meurent! Vraiment balaise le gars...

Et c'est quoi qui permet donc ce petit miracle (à part le meilleur navigateur du ...)?
XML bien sûr. En l'occurrence: XUL (prononcer "zul") pour XML User interface Language. Avec un chouia d'aide de JavaScript, of course.

Ah oui, j'oubliais de mentionner la seule appli utile: un navigateur Web... (dur le coup dans l'estomac en fin de blog, hein?) Et "oui", la réponse est "oui" (sachant que la question normale que vous devriez vous poser est: "est-ce que ce navigateur permet de recharger Robin?"). Bien sûr que je me suis amusé à récurrencer: je n'ai pas eu la patience de trouver à partir de quand çà plante (je me suis arrêté à 3 niveaux!)

Modify an XML file with ANT

Recently, while using the wonderful Glue for building WebServices (WS), I came up with the following problem: how to modify an XML file with Ant? 
(The rationale of this is: when creating a new WS, you have to use a special deployment tool [a shell script] and manually patch one of the many generated XML files; and of course, I want to automate the "manually" part of the cycle! But I guess such a problem is more general and when using EJB, one could encounter same wondering). 
First, I rejected the idea of using an Ant task that deals with TEXTUAL modifications of regular text files: I simply could not see an XML file as a regular file! Let me tell you that I didn't even think about creating a dedicated task in Java for solving that particular problem: that would have been crazy! 

Then, I ended up with 2 ideas: 
 - using an XML Ant task (such as the xmltaskone) 
 - using a templating engine (Velocity or FreeMarker) 

I preferred the first option which fits nicely to my needs (design-to-cost approach ;-) and allow me to write XPaths expression to patch the original XML file. Great! 
Templating engine was ... tempting, but too far from both my real need and time-frame to achieve it! 

So as to conclude, one of my best friends and colleagues (best applies to both nouns!) would probably have envisioned the possibility to write an XSLT file to perform that stuff with variables passing and modification of the XML file: let's forgive him!