gleu's blog - Développement

Geany, suite

Guillaume Lelarge — Tue, 11 Mar 2008 13:32:00 +0100

Je trouve que Geany est un excellent éditeur de code source. Il me manquait surtout un navigateur pour ouvrir rapidement un fichier. Je savais que la prochaine version en avait un, mais je ne voulais pas me lancer dans la compilation de la version SVN. Pas la peine, un .deb version 0.14-svn est disponible sur ce site. Et ça marche trop bien. Merci au packageur

Écriture d'un script bash

Guillaume Lelarge — Fri, 05 Oct 2007 17:50:00 +0200

Depuis quelques semaines, j'ai pris de bonnes résolutions pour mes scripts bash. Je suis arrivé à les structurer efficacement.

Je commence tout d'abord par les variables configurables. Cela donne en gros ceci :

##### Variables configurables #####
# outils
PGDUMP=$(which pg_dump)
PSQL=$(which psql)
# cet outil
ME=`basename $0`
# répertoires de travail
DIRBASE=${REPBASE:-"/opt/${ME}"}
# fichiers temporaires
FICTMP="/tmp/${ME}.$$"
# journaux
FICLOG="$DIRBASE/${ME}.log"
FICERR="$DIRBASE/${ME}.err"
# fichiers de configuration
FICCONF=${1:"/etc/${ME}.conf"}
##### Fin des variables configurables #####

En premier lieu, les outils. Par défaut, j'indique $(which mon_outil) pour que l'emplacement système par défaut soit utilisé. Cependant, si l'utilisateur de ce script a compilé et installé lui-même cet outil dans un répertoire particulier, il peut directement modifier cette ligne en y mettant le chemin complet. Ensuite, nous avons les répertoires de travail, les fichiers temporaires, de configuration et les journaux. L'initialisation de la variable DIRBASE est intéressante : elle signifie que DIRBASE sera initialisée avec le contenu de la variable REPBASE si cette variable est déjà initialisée et que, dans le cas contraire, elle prendra la valeur /opt/${ME}. Cela a un très gros intérêt : cela me permet de modifier une variable suivant mon environnement. Je n'ai donc pas besoin de modifier le script pour que DIRBASE considère un autre répertoire de travail. FICCONF=${1:"/etc/${ME}.conf"} est un autre exemple de ce type de construction. La variable FICCONF prendra la valeur du premier argument en ligne de commande, s'il y en a un. Dans le cas contraire, FICCONF sera initialisée avec /etc/${ME}.conf. Cela me permet donc de modifier temporairement le fichier de configuration en le proposant sur la ligne de commande.

Une fois les initialisations réalisées, il faut vérifier un certain nombre de points. Par exemple, je propose à l'utilisateur de modifier certaines variables. Il est donc essentiel que je vérifie que les modifications réalisées sont valides. Voici la vérification des variables :

for variable in "PGDUMP" "PSQL" "ME" "DIRBASE" \
                "FICTMP" "FICLOG" "FICERR" "FICCONF"
do
  eval valeur=\$$variable
  if test -z "$valeur"
  then
    echo "ERREUR: mauvaise configuration de la variable $variable (actuellement vide)"
    exit 1
  fi
done

Je vérifie ensuite l'existence des outils et leur « exécutabilité » :

for outil in "$PSQL" "$PGDUMP"
do
  if test ! -x "$outil"
  then
    echo "ERREUR: $outil inexistant ou non exécutable"
    exit 2
  fi
done

Ensuite, je vérifie les répertoires. Généralement, ce sont des répertoires de travail, donc, s'ils n'existent pas, il faut les créer :

if test ! -d "$DIRBASE"
then
  mkdir -p "$REP_DUMP"
  if test $? -eq 0
  then
    echo "création du répertoire de sauvegarde '$REP_DUMP'"
  else
    echo "ERREUR lors de la création du répertoire de sauvegarde '$REP_DUMP'"
    exit 3
  fi
fi

Voilà. Du coup, mes scripts comportent généralement plus de tests que de code réalisant la fonction première, mais bon, au moins, c'est assez blindé.

Quelques trucs glanés au boulot...

Guillaume Lelarge — Sat, 03 Mar 2007 16:47:00 +0100

En fait, deux.

Le premier concerne trac. Vous pouvez modifier les pages générées par trac car elles sont créées à partir d'un template. Par exemple, pour la page de la roadmap, vous pouvez modifier le fichier roadmap.cs. Vous pouvez le faire de deux façons : le modifier dans le répertoire global (sur ma Debian, il s'agit de /usr/share/trac/templates) ou le copier dans le répertoire templates de votre session trac et le modifier là-bas. Le deuxième point est plus intéressant quand vous utilisez plusieurs trac sur une même machine et que vous ne voulez pas que les modifications sur un trac se voient sur l'autre.

Le deuxième concerne Firebug et jQuery. Le premier est un outil vraiment génial pour concevoir des sites web, le second est une excellente bibliothèque JavaScript. Pas étonnant que son auteur soit parti bosser à la fondation Mozilla. Les deux ensemble, c'est du bonheur

Ce matin, sur #postgresql

Guillaume Lelarge — Sat, 09 Dec 2006 09:30:00 +0000

Petite discussion entre deux personnes sur #postgresql ce matin :

[09:26] <guy1> VB sucks
[09:26] <guy1> i wish i never learned it
[09:26] <guy2> guy2; I agree, but its the cobol of this decade

J'ai anonymisé les noms mais je n'ai pas modifié les messages... Je suis en total accord avec eux.

Deux livres que j'ai fini, un troisième en cours (enfin presque terminé)

Guillaume Lelarge — Wed, 27 Jul 2005 23:59:35 +0000

Quand j'ai pris connaissance de la liste de bouquins que tout bon développeur doit avoir lu d'après Joël Spolski, j'ai commandé les deux plus intéressants, à mon goût, « Peopleware : Productive Projects and Teams » et « The Pragmatic Programmer: From Journeyman to Master ».

Ils sont tous les deux très bons, même si je suis un peu resté sur ma faim. « Peopleware : Productive Projects and Teams » n'est pas spécialement orienté chef de projet. Tout développeur peut le lire pour tenter de comprendre les différents événements dans son travail de tous les jours. C'est très instructif et on retrouve plein d'événements du quotidien : des réunions qui n'en finissent pas, des dates de livraison qui sont soit rallongés soit écourtés, des certitudes qui n'en sont pas. Le deuxième, « The Pragmatic Programmer: From Journeyman to Master », est orienté vers le développeur. C'est un ensemble de recettes permettant de passer de l'état développeur débutant (ie sortant de l'école d'ingé ou de la fac) à l'état de développeur confirmé/expert. Là-aussi, j'y ai retrouvé beaucoup de choses qui font mon quotidien... autant dans les mauvais points que dans les bons. À force de lire mes problèmes de tous les jours, il faut avouer que cela fait un peu liste d'idées totalement évidentes mais je pense qu'il est bon de les dire quand même.

Un des conseils les plus frappants (donnés dans les deux livres) est de laisser du temps au développeur pour augmenter ses connaissances. Le deuxième livre préconise notamment d'apprendre un nouveau langage tous les ans Mais en fait, peu importe ce dernier conseil. L'important est de lire, de se tenir au courant des nouveautés, de l'évolution des technologies. Je l'avais beaucoup fait à un moment. Je lisais énormément de livres informatiques, j'imprimais des tonnes d'articles publiés sur Internet. J'apprenais énormément de choses. Il me semble que j'ai plus appris dans les livres qu'à la fac. Si je me souviens bien, à la fac, je faisais gentimment mon TD mais je n'allais pas voir plus loin. Ça ne m'intéressait pas. Quand j'ai commencé à bosser, certains problèmes se posaient à moi (par exemple, créer une documentation, la mettre à disposition des autres facilement)... je ne pouvais compter sur personne. C'est là que j'ai commencé à lire, à tester, à chercher à comprendre. C'est là que j'ai commencé à devenir un geek (mentalement, parce que physiquement, je manque de barbe).

Le gros avantage de ces deux livres, c'est qu'ils insistent tous les deux sur cet aspect formation, qu'il s'agisse d'une auto-formation ou d'une formation donnée par quelqu'un d'autre. Et que c'est quelque chose très difficile à faire admettre à une direction.

Du coup, je me suis dit que j'allais me remettre un peu à lire des bouquins informatiques. Nessie m'ayant parlé du « Programmation système en C sous Linux » comme d'une oeuvre de référence, je l'ai commandé chez Eyrolles. Je le dévore depuis, j'apprends des nouveaux trucs qui me rappellent de vieux souvenirs de fac... le problème avec les études, c'est qu'il faut apprendre pour apprendre. Quand vous bossez, vous devez apprendre pour résoudre un problème immédiat. Le problème, quand vous bossez, c'est que vous n'avez plus le temps d'apprendre... J'espère qu'un jour j'aurais un boulot où on me laissera un peu de temps pour apprendre quelque chose de nouveau, y compris si cela n'a aucun rapport avec mon projet immédiat.

Qt - stage 2

Guillaume Lelarge — Fri, 17 Jun 2005 23:58:41 +0000

Comme une image est souvent plus parlante...

Ça m'a pris une heure, montre en main. Il est vrai que mon code n'est pas très beau, que j'ai des fonctions qui se ressemblent beaucoup. Mais tout de même... mon application ne se connecte à PostgreSQL qu'à partir du moment où je clique sur le bouton « Se connecter » puis elle remplit les quatres tableaux avec les valeurs attendues. Les champs booléans disposent de cases à cocher, plutôt que d'un texte indiquant si l'option est active ou non.

Je ne pensais pas que cela serait aussi rapide et aussi simple

Il faudrait maintenant que j'affiche aussi les stats une fois une base de données sélectionnée... ça attendra demain. Là, je vais aller me coucher.

Qt - stage 1

Guillaume Lelarge — Fri, 17 Jun 2005 00:24:14 +0000

En dehors de la réunion du CA ce soir, j'ai de nouveau attaqué un peu Qt. Je suis très étonné d'arriver à faire un petit programme simple en si peu de temps. J'avais peur que cela soit une galère en C++ mais j'arrive à me débrouiller plutôt bien.

J'ai créé une classe représentant ma fenêtre. L'application se connecte à une base de données PostgreSQL, récupère la version du serveur, lance une requête sur la table des adhérents de galette et les affiche dans un tableau. Ça n'est pas aussi simple que cela paraît mais j'ai mis peu de temps. Je ne pense pas que j'aurais été plus vite en PHP ou en VC++. Voici le code de ma classe :

#include "pggl.h"

#include <qapplication.h>
#include <qsqldatabase.h>
#include <qsqlquery.h>
#include <qlabel.h>
#include <qtable.h>


pggl::pggl(QWidget* parent, const char* name, WFlags fl)
    : Form1(parent,name,fl)
{
    db = QSqlDatabase::addDatabase("QPSQL7");
    db->setDatabaseName("galette");
    db->setUserName("guillaume");
    db->setPassword("");
    db->setHostName("localhost");

    if ( ! db->open() ) {
      qWarning( "Failed to open database : " + db->lastError().text() );
    }

    QSqlQuery query( "SELECT version()", db );
    if ( query.isActive() ) {
      query.next();
      lblVersion->setText(query.value(0).toString());
    }
}

void pggl::initialiseTable()
{
    int i = 0;
    QSqlQuery query2( "select nom_adh, prenom_adh, ville_adh, activite_adh from adherents ", db );
    table1->setNumRows(query2.size());
    table1->setNumCols(4);
    table1->setColumnMovingEnabled(true);
    table1->setShowGrid(false);
    table1->setSelectionMode(QTable::SingleRow);
    table1->setReadOnly(true);
    table1->verticalHeader()->hide();
    table1->setLeftMargin(0);
    QHeader *header = table1->horizontalHeader();
    header->setLabel( 0, "Nom" );
    header->setLabel( 1, "Prénom" );
    header->setLabel( 2, "Ville" );
    header->setLabel( 3, "Actif" );

    QCheckTableItem* chk;

    while ( query2.next() ) {
      table1->setText( i, 0, query2.value(0).toString() );
      table1->setText( i, 1, query2.value(1).toString() );
      table1->setText( i, 2, query2.value(2).toString() );
      chk = new QCheckTableItem( table1, "");
      chk->setChecked( query2.value(3).toBool() );
      table1->setItem( i, 3, chk );
      i++;
    }
}

Bref, simple, facile, rapide... ceci dit, j'arrive quand même à ajouter des cases à cocher dans mon tableau, à autoriser le drag and drop parmi les colonnes, etc. Je suis incapable de faire cela en VB ou en VC++.

Évidemment, ce n'est qu'un début. Je ne suis pas très à l'aise en C + +. L'aide sur les API de Qt est remarquable. Le site « The Code Skipper » est très utile. Je me lance donc dans un projet : recoder phpPgInfo en C + +/Qt. Un projet assez simple, mais qui va me permettre d'apprendre des tas de choses... et c'est tant mieux.

Travail du développeur

Guillaume Lelarge — Wed, 15 Jun 2005 00:58:58 +0000

Bon, pour être un peu plus gai que mon précédent billet, voici un lien vers un article très intéressant sur le travail des développeurs. Notamment, l'article aborde trois dominantes dans la vie d'un développeur, ou plus généralement d'un intellectuel (comprendre ici le contraire du manuel) : le flux^[1] (the flow), le blocage^[2] (stuckness) et les interruptions (déplorables dans certains cas, tout à fait intéressantes autrement).

Cet article m'a beaucoup fait penser à un livre que je suis en train de lire, « Peopleware ». Il n'est donc pas étonnant de le trouver dans les références de l'article

J'essaierais de poster un billet plus long sur ce sujet une fois que j'aurais terminé de lire ce livre. En attendant, lisez cet article.

Notes

[1] lorsque vous savez exactement ce que vous devez coder et qu'on ne doit pas vous déranger pour ne pas interrompre ce flux

[2] lorsqu'une réflexion est complètement bloquée, qu'il est du coup impossible de coder et qu'il vaut cent fois mieux vous interrompre

Dotclear, analyse de l'assistant d'installation

Guillaume Lelarge — Tue, 25 Jan 2005 00:17:22 +0000

Ce document n'a pas pour but de donner les étapes pour installer DotClear. Il existe pour cela d'autres ressources sur le web. Non, le but de ce document est de plonger dans le code qui anime ce logiciel. Pourquoi l'analyser ? J'ai toujours entendu dire qu'Olivier Meunier est un formidable codeur... autant le vérifier soi-même. Et puis, j'ai besoin de me replonger un peu dans du code. Ça me change un peu de la traduction et ce n'est pas un mal.

Commençons par dire qu'il n'usurpe pas du tout sa réputation (même si j'aurais pris des conventions de codage un peu plus strict). Ceci étant fait, passons aux choses sérieuses.

Tout d'abord, je me demandais si Olivier utilisait un système de template. En effet, il est conseillé de séparer forme et fond. En ce qui concerne l'assistant d'installation, ce n'est pas le cas. Le code XHTML est complètement imbriqué dans le code PHP. En haut du script, un require dirname(FILE).'/__top.php'; amène les en-têtes du standard XHTML avec encodage dépendant de la configuration. En bas du script, l'équivalent pour la fin de page se nomme __bottom.php.

Comme il n'utilise pas de template mais qu'il fait usage d'un grand nombre de formulaires dans l'assistant, il a créé une classe form (lib.form.php) lui permettant d'ajouter facilement une liste de sélection ou un ensemble de boutons radio, voire même un simple champ texte. L'avantage est de clarifier le fichier exécuté. Un simple appel de fonction permet d'ajouter un élément du formulaire avec quatre ou cinq caractèristiques (id, taille, taille max, valeur par défaut, ordre de tabulation, etc.). Les listes déroulantes sont créées à partir d'un élément de type array, moyen très élégant si les informations proviennent d'une base de données ou d'un fichier (type CSV par exemple).

Un autre point qui m'impressionne dans son assistant est la liste de points de vérifications effectués ou d'actions réalisés. Là aussi, il utilise une classe (class.checklist.php). Après l'avoir instancié, la fonction addItem permet d'ajouter des tests à effectuer. Après quelques ajouts, nous pouvons demander le code HTML représentant tous les tests, réussis et en échec (avec les images) puis de nous donner le résultat final.

Tous les écrans de l'assistant d'installation fonctionnent ainsi :

test si le formulaire a déjà été rempli
si oui,
vérification des arguments donnés, récupérés via la session php (pour la base de données, tentative de connexion ou de création des tables)
si la vérification est positive, un simple header ('location: fonction_suivant.php') permet d'accèder à la fenêtre suivante de l'assistant
si non,
affichage du formulaire

Bref, c'est simple, c'est clair, c'est propre. Les fichiers sont petits, plutôt bien codés, très facile à comprendre. Olivier n'usurpe vraiment pas sa réputation. Sans parler des feuilles de style très jolies... un artiste en plus

De l'art du déboguage

Guillaume Lelarge — Sat, 20 Nov 2004 14:24:03 +0000

Une petite citation de Brian Kernighan :

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

En voici une petite traduction pour les anglophobes :

Le déboguage est deux fois plus difficile que l'écriture de code. Donc, si vous écrivez du code aussi intelligemment que possible, vous êtes, par définition, pas assez intelligent pour le déboguer.

NSIS : fin de la création de l'installeur

Guillaume Lelarge — Tue, 31 Aug 2004 21:55:00 +0000

J'indiquais sur ce billet qu'il me manquait encore quelques fonctionnalités sur NSIS que j'avais sur InstallShield. Entre autres, il y avait l'enregistrement de composants VB6, du pilote ODBC de PostgreSQL et des modifications sur les bases de registre.

Pour le premier point, au lieu de demander un « scan » de votre projet VB, éditez-le avec notepad ou gvim (oui, il existe sous Windows ). Vous y trouverez la liste des OCX et autres DLL que vous devez enregistré. La commande
!insertmacro InstallLib REGDLL $ALREADY_INSTALLED REBOOT_NOTPROTECTED "msvbvm60.dll" "$SYSDIR\msvbvm60.dll" "$SYSDIR"
vous copiera et enregistrera la DLL msvbvm60.dll. Copiez ce code pour les autres OCX et DLL dont vous avez besoin et le tour est joué. Pour plus de détails, voir la documentation utilisateur de NSIS.

Le pilote ODBC a été plus dur. Le seul moyen que j'ai trouvé a été de lancer l'installation du fichier MSI du pilote (disponible sur le site du projet psqlodbc). Pour cela, utilisez la commande
msiexec.exe /i psqlodbc.msi /qn
/i pour demander une installation et /qn pour demander une exécution silencieuse. La définition des arguments en ligne de commande de msiexec.exe est disponible sur le site du MSDN.

Les lectures/écritures sur la base de registre sont très simples. Là aussi, tout se trouve dans la documentation utilisateur de NSIS.

Un point que j'avais négligé concerne l'ajout d'interface personnalisée mais cela se réalise assez facilement avec l'outil HM NIS EDIT.

En tout cas, je vais certainement pouvoir jeter InstallShield rapidement

NSIS, Sunbird et un PC qui a du mal...

Guillaume Lelarge — Fri, 20 Aug 2004 00:18:00 +0000

J'ai passé une heure aujourd'hui à travailler sur NSIS. Pas de soucis pour des installations simples sous Windows Si vous pouvez vous contenter de copier quelques fichiers, de créer des raccourcis et autres modifications de fichiers .ini, ce programme vous permettra de vous en sortir avec les honneurs. Je vous conseille tout de même de récupérer HM NIS EDIT car il dispose d'un assistant facilitant grandement le début de la création d'un installeur. Pour mes besoins, il me manque encore quelques points comme l'enregistrement de composants VB6, du pilote ODBC de PostgreSQL et des modifications sur les bases de registre.
Sunbird vient de sortir en version autonome et cela vaut vraiment le détour. Je vais m'arranger pour tester cela au travail, voire l'intégrer à certaines applications.
Enfin, mon PC n'en finit plus de planter. Ça sent la réinstallation... mais avec une Debian Sarge

Installeur libre sous Windows

Guillaume Lelarge — Tue, 17 Aug 2004 00:13:00 +0000

Cherchant un remplaçant libre à Install Shield, j'ai fini par tomber sur celui de NullSoft : NSIS. Celui-ci a l'air assez costaux pour mes besoins. Il a surtout un avantage sérieux. Son fichier de configuration est un simple fichier texte, facile à conserver dans un CVS.

J'ai trouvé aussi quelques liens intéressants :

le manuel utilisateur ;
un éditeur libre pour le format NSIS ;
un outil de déboguage ;
un exemple frappant de ce qu'il est possible de faire.

Vivement que je teste ça.