Christophe Jacquet — Carnet — Mot-clé : Programmation

Généralement, quand on évoque une base de données disposant du langage SQL, on pense serveur à mettre en place, comptes utilisateurs à créer, et éventuellement bibliothèques à installer lorsque l'on veut accéder à la base depuis un programme. Bref, une lourdeur certaine, rédhibitoire pour stocker, par exemple, quelques données depuis un script lancé épisodiquement...

Cet article explique comment l'utilisation de bases de données devient simple avec SQLite : pas de serveur à installer, pas gestion des utilisateurs. L'utilisation est aussi simple que celle de fichiers textes. De plus, à partir de Python 2.5, le langage inclut en standard la bibliothèque d'accès aux bases sqlite3. SQLite est notamment utilisé par Firefox 3.

À l'occasion de quelques amusements en C# effectués en ce moment...

Il y a deux ans, je m'étais plaint des generics de Java. En effet, le paramétrage des types est effacé à la compilation, ce qui rend certaines opérations impossibles à faire. Par exemple la méthode toArray de l'interface List doit recevoir en paramètre un tableau du type paramètre, car celui-ci est oublié à la compilation. Mais hors de question de pouvoir écrire :

public static <T> T[] truc(T a) {
	List<T> liste = new ArrayList<T>();
	liste.add(a);
	return liste.toArray(new T[] {});
}

L'expression soulignée est incorrecte, parce que justement, à l'exécution la JVM ne connaît pas T... Problème insoluble.

Dans .Net, la CLR n'oublie pas le type des paramètres. Dans une méthode paramétrée par <T>, on peut donc parfaitement écrire une expression du type new T[] { ... }. Et la méthode ToArray n'a donc pas besoin qu'on lui fournisse un tableau du type paramètre. Le code ci-dessus, incorrect en Java, s'écrit de façon élégante en C# :

public static T[] truc<T>(T a)
{
	List<T> liste = new List<T>();
	liste.Add(a);
	return liste.ToArray();
}

Notons que pour ne rien simplifier, les concepteurs de Java et C# ont forcément trouvé le moyen de faire différer la syntaxe au niveau de la place du paramètre <T> dans la déclaration de fonction... Mais clairement, les generics me semblent avoir été traités à la légère en Java. Le système de l'erasure des informations de type, même s'il est suffisant pour assurer la type safety dans la plupart des cas, et même s'il permettait de garder la JVM inchangée, conduit à des solutions vraiment épouvantables (cast + @SuppressWarnings("unchecked")) dans des cas un peu complexes...

Soit le problème « ferroviaire » suivant :

• On dispose d'une fiche horaire généreusement fournie par la SNCF ;
• On voudrait générer un joli graphique de circulation correspondant à cette fiche horaire.

Ce billet explique comment y arriver simplement, à l'aide d'un petit script en Ruby et de Gnuplot.

Lorsqu'on veut créer un objet distant avec Java/RMI (i.e. un objet compilable avec rmic), il ne suffit pas de dériver d'une classe qui implémente java.rmi.Remote, il faut que l'objet implémente directement une interface qui dérive de java.rmi.Remote. Ne me demandez pas pourquoi, mais c'est comme ça, et ça peut être bien de le retenir pour éviter de tourner en rond... À noter qu'il faut aussi que l'objet descende de UnicastRemoteObject.

J'ai dû installer une vieille version de Java sur ma Gentoo : ça ne marchait pas lors du lancement du fichier .bin auto-extractible, en raison d'une syntaxe non reconnue de tail : au début du .bin, il y a un tail +292 $0.... Le changer en tail -n +292.... Ensuite, le programme m'a indiqué des erreurs de checksum. Dans ce cas, lancer directement à la main le fichier install.sfx.* généré... Ce n'est pas grand-chose, mais si ça peut éviter des galères à certains...

Grâce à de nombreux retours, j'ai pu corriger des bugs dans Server Spy et proposer une version 0.1.1. Le reviewer du site Firefox Add-ons a été très réactif, mais lorsqu'il s'est agi de propager le nouveau fichier sur le FTP, il y a eu quelques minutes de retard, d'où l'angoisse d'un utilisateur !

Ceci me conduit à un début de liste de « trucs » pour le développement d'extensions à Mozilla:

• le livre « Creating Applications with Mozilla » (O'Reilly) est très bien. Même s'il date un peu (2002), il est en grande partie toujours d'actualité pour Firefox 1.5. Par contre, attention, il y a pas mal de typos (mauvaise capitalisation des noms de fonction notamment), donc il faut faire attention ;
• sur le web, developer.mozilla.org, XUL Planet ;
• l'extension FireBug est très pratique pour détecter les exceptions JavaScript levées par ses extensions ;
• il y a plein de bonnes choses dans l'Extension Developer Extension, notamment le très pratique « reload all chrome ». Ceci dit, cette fonction m'a créé quelques soucis (perte de contexte JavaScript) ;
• lorsqu'on teste une extension, penser à désactiver toutes les autres extensions. J'en étais ainsi venu à croire que Server Spy marchait correctement, alors que ce n'était pas le cas si une extension manquait (je n'ai même pas pu identifier laquelle...)

En parlant de développement, un geek de mes amis a publié des choses intéressantes : solveur de Sudoku en Java, logueur d'URL qui passent sur IRC en Perl.