The trashiest blog in the World...

Aller au contenu | Aller au menu | Aller à la recherche

WorkLand

Tout pour le travail... Que du bonheur :-@

Fil des billets - Fil des commentaires

mardi 21 février 2012

git-flow sous Fedora

Il y a quelques semaines, j'entendais parler de git-flow, un ensemble d'extensions Git qui aide à respecter le modèle de développement Git de Vincent Driessen ; modèle que je ne connaissais pas d'avantage. git-flow simplifie les choses pour suivre ce modèle.

À l'occasion de la sortie de la nouvelle version de Galette (pleins de nouveautés !! :-p ), et de la migration des sources du projet de Subversion vers Git ; j'ai décidé d'utiliser git-flow.

Premier constat : pas de paquet disponible dans les dépôts :'(
Un RPM de git-flow pour Fedora 16 est donc désormais disponible dans le dépôt trashy (si d'aventure quiconque aurait envie de l'intégrer dans les dépôts officiels, le fichier SPEC et le SRPM sont disponibles ;) )

Une fois le RPM installé, la commande git flow est disponible :

 % git flow version
0.4.2-pre

L'autocomplétion des commandes Git est une aide plus qu'appréciable au quotidien, si vous souhaitez en bénéficier pour git-flow ; il vous faudra installer un script d'autocompleteion pour git-flow (bash ou zsh). Une fois le fichier correspondant à votre shell récupéré, il suffit de faire un source fichier pour que la complétion soit disponible :-)

Bien que je n'aie encore que peu d'expérience avec cet outil, je trouve assez pratique que ce soit lui et non moi qui soit en charge de savoir quelle doit être la branche d'origine, ou encore qu'il se charge automatiquement lors d'une correction de bogue du merge vers les branches de développement et stable, ainsi que la création du tag.
Tout dans git-flow peut être fait à l'aide de commandes Git uniquement, on peut donc facilement choisir de l'utiliser ou non...

Un outil fort intéressant à mes yeux !

vendredi 16 avril 2010

Java et internationalisation

Je développe régulièrement en Java ; que ce soit pour des projets personnels (applications « de bureau » basées sur Swing principalement) ou pour le boulot.

Dans le développement d'une application, songer à un système d'internationalisation assez rapidement est je pense généralement bénéfique pour deux raisons :

  • il est alors possible de traduire rapidement et facilement votre application en d'autres langues (ben oui, c'est fait pour !),
  • la relecture des chaînes originales ou traduites par une tierce personne est grandement facilitée ; nul besoin de pousser l'application dans ses derniers retranchements pour qu'elle affiche le message d'erreur qui ne devrait jamais être affiché :-p

Lorsque j'ai débuté en Java, je travaillais sur un logiciel de gestion de cantines scolaires, et l'implémentation d'un système i18n - bien que non requis par le « cahier des charges » de l'époque - m'est apparue naturelle.
J'ai en conséquence potassé un peu Java, et découvert les histoires de ResourceBundle et de fichiers .properties. J'ai rapidement trouvé un plugin pour l'IDE que j'utilisais (et que j'utilise toujours d'ailleurs - Eclipse) qui facilitait la saisie des chaînes.

Voici en gros à quoi ressemble une telle chaîne dans un programme java, en deux parties. D'abord, dans le fichier source .java :

System.out.println(Messages.getString("myapp.says.hello"));

Ensuite, dans le fichier .properties localisé qui va bien (ici, le français) :

myapp.says.hello=Un bonjour de mon application

Premier problème : la chaîne contenue dans le fichier Java est totalement dénuée de sens, et par moments (voire même souvent), il faut se référer au fichier .properties pour savoir quel était le message prévu.

Second problème : depuis quelques années, je n'avais pas ou très très peu utilisé ce système (pour le boulot, on utilise Cocoon qui fournit son propre système d'internationalisation, basé sur des fichiers XML) ; et le plugin que j'avais trouvé à l'époque ne fonctionne plus avec les versions récentes de Eclipse. Pire : je ne suis pas parvenu à trouver une quelconque application qui me permette de gérer « facilement » ces fichiers.

Et là, c'est un gros problème. En effet, les fichiers .properties sont de simples fichiers textes ; mais dans lesquels les caractères spéciaux tels les accents, les guillemets («»), etc doivent être encodés en unicode. Pour vous donner un exemple :

myapp.prefs=Pr\u00E9f\u00E9rences

Relire et éditer pareilles chaînes de caractères est difficile sinon impossible (personnellement, j'abandonne au bout de moins de 5 lignes en lecture). Une faute de frappe dans les caractères unicode empêche le catalogue complet de se charger, et à priori sans lever d'exception (nous n'avons tout du moins pas trouvé comment faire :-( ).

Je me suis très récemment décidé à essayer de travailler un peu sur mon logiciel de gestion de Cantines, et me suis retrouvé face à ce problème lorsque j'ai voulu modifier une chaîne existante. ; du bonheur en barres :-D

En cherchant un peu, j'ai découvert le projet gettext-commons qui permet d'internationaliser des applications Java avec les méthodes gettext ! Dans l'application, on se retrouve donc avec quelque chose dans le genre de :

System.out.println(i18n.tr("Preferences"));

Chaîne qui sera ensuite extraite automatiquement du code source, ajoutée dans un fichier .po lequel fichier vous pourrez traduire en utilisant un des nombreux outils disponibles. Je préfère nettement cette solution à la première :-)
Pour ne rien gâcher au plaisir, gettext-commons supporte la pluralisation, la contextualisation, le remplacement de variables dans les chaînes, ... La documentation est assez claire pour mettre en place ce système facilement et rapidement dans un projet.

Seul bémol pour le moment : il faut générer le fichier jar localisé pour voir le résultat dans votre application, c'est parfois un peu lourd (ou bien j'ai sauté la partie de la doc qui explique comment faire autrement :-p )

Petite note tant que j'y suis ; c'est normalement documenté (mais je n'ai pas retrouvé la page) ; méfiez-vous des apostrophes dans les chaînes où vous souhaitez effectuer un remplacement de variables. En effet, la chaîne suivante (quel que soit le système utilisé) :

L'application {0} est perdue.

S'afficherait de la sorte :

Lapplication {0} est perdue.

Sans apostrophe, et sans que la variable n'ait été remplacée, donc !
Pour ces cas de figure, il suffit d'échapper l'apostrophe avec une autre apostrophe (!) et le tour est joué. Ainsi :

L''application {0} est perdue.

Donnera :

L'application monappli est perdue.

mercredi 7 octobre 2009

Nouvelle galette : 0.63.2

J'avais annoncé ici même en début d'année (le 06 Janvier pour être précis) la sortie de Galetre 0.63.

Depuis - le 21 mai - une version corrective à vu le jour, et je remet le couvert aujourd'hui, avec Galette 0.63.2 ! Vous pourrez récupérer cette version à l'adresse : http://download.gna.org/galette/galette-0.63.2.tgz

Il s'agit principalement d'une version corrective, voici la liste (non exhaustive) des modifications :

  • pour la 0.63.1
    • certaines préférences n'étaient pas correctement initialisées à l'installation
    • sur certains hébergeurs, les fonctions exif ne sont pas disponibles, on utilise GD dans ce cas (bogue #12836)
    • le XHTML était parfois mal formé en raison des sessions PHP (bogue #13071)
    • correction de notices PHP dans les logs (patch #1133)
    • suppression des fonctions posix qui sont dépréciées dans PHP 5.3
    • ajout d'un fichier .htcaccess pour interdire la lecture du dossier des images depuis le web
  • pour la 0.63.2
    • la date de fin d'adhésion était incorrecte pour un exercice (bogue #13010)
    • les dons n'apparaissaient pas dans la bonne couleur dans le tableau (bogue #13009)
    • les entrées d'historique lors de l'ajout ou de la modification d'une contribution ne comportaient pas le login de l'adhérent - comme c'est le cas lors de l'ajout/la modification d'un adhérent (bogue #13011)
    • lors d'une installation sous windows, certains caractères du chemin étaient interprétés - “\n” par exemple (bogue #14162)
    • lors de l'enregistrement d'une photo ou d'un logo personnalisé avec un canal PNG transparent, ce canal n'était pas sauvegardé, et l'image se voyait donc attribuer une couleur de fond par défaut (bogue #14327)
    • l'ajout de restrictions (depuis la 0.63.1) sur l'affichage des photos envoyées empêchait tout logo personnalisé de s'afficher correctement (bogue #14442)
    • lorsque l'on modifiait la langue d'un adhérent, la session courante se trouvait traduite dans cette langue (bogue #14443)
    • certains caractères, comme les apostrophes, étaient mal encodés dans le sujet des mailings (bogue #14449)
    • l'envoi de mail était toujours tenté, même si la fonctionnalité avait été désactivée dans les préférences (bogue #14450)

Je ne suis pas forcément mécontent des améliorations apportées à cette version, mais il faut tout de même avouer que c'est un peu léger... En deux ans de Galette (et, oui, cela fait déjà deux ans...) j'ai tout de même fait un peu plus que cela, mais sans encore avoir eu l'occasion (ou le courage, peut-être) de sortir une nouvelle version).

La prochaine version de Galette sera entièrement récrite en php5/objet, possèdera de nombreuses nouvelles fonctionnalités (dont je n'ai pas forcément la paternité - nous rendrons à César ce qui lui appartient en temps voulu) ; ainsi qu'un nouveau design (pas à la hauteur du récent changement de design du site, mais ce sera déjà pas mal :-D).

Pour vous, fidèles lecteurs ( ! :-D ), une nouveauté presque en primeur (beh oui, les listes de Galette ont les vraies primeurs...) : j'ai commencé l'intégration d'un système de plugins dans Galette, qui demanderait à être bien amélioré : mais qui m'a déjà permis (sur une demande spécifique) de développer un plugin pour la gestion de clubs automobiles. En espérant que ce sera utile au plus grand nombre ! Prochaine étape côté plugins : un plugin Sport qui reprendrait les fonctionnalités de feu Galette-sport, que je n'ai pas eu l'occasion de faire évoluer depuis que je me suis retrouvé propulsé à la tête du projet... Amis sportifs, je pense à vous (je vais même au boulot en vélo tous les jours désormais !!! ;-)).

Voilà les quelques news du pays enchanté de Galette, @ bientôt !

jeudi 16 octobre 2008

Subversion : comment créer un miroir de façon sécurisée ?

Sur un serveur (que nous nommerons s_svn), nous avons un dépôt SVN, nous souhaitons mettre un miroir de ce dépôt sur un second serveur (s_miroir).

Nous verrons comment utiliser la commande svnsync avec SSH pour parvenir à nos fins.

Tout d'abord, un peu de réflexion (ça fait mal, mais on va se forcer :-D). Nous avons, sur chacun des deux serveurs, un utilisateur nommé 'svn'. Depuis s_miroir, l'utilisateur devra avoir un accès SSH sur s_svn, de préférence avec une clé SSH dépourvue de mot de passe, afin de pouvoir automatiser le processus. Il faudra donc penser à restreindre un peu cet accès, nous ne souhaitons pas que l'utilisateur svn de s_miroir ait un accès inconditionnel à s_svn sans mot de passe aucun ;-)

Commençons par mettre en place la clé SSH. Sur s_miroir, créons la clé :

[svn@s_miroir ~]$ ssh-keygen
enerating public/private rsa key pair.
Enter file in which to save the key (/home/svn/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/svn/.ssh/id_rsa.
Your public key has been saved in /home/svn/.ssh/id_rsa.pub.

La clé créée, nous pouvons l'installer sur le serveur qui héberge le dépôt SVN :

[svn@s_miroir ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub svn@s_svn

Pour plus de sécurité, nous allons restreindre l'accès sur s_svn à la seule commande dont s_miroir ait besoin. La commande en question est svnserve -t, nous allons utiliser les possibilités de SSH pour cela.

[svn@s_svn ~]$ vim ~/.ssh/authorized_keys

Cherchez la ligne qui permet à s_miroir de s'authentifier. Chaque ligne est constituée par défaut de la façon suivante :

type     identifiant_cle     utilisateur

Dans notre cas, nous aurons donc (où {identifiant} est une suite de caractères alphanumériques imbuvable) :

ssh-rsa {identifiant} svn@s_miroir

Pour restreindre à la seule commande qui nous intéresse, il suffit d'ajouter command="svnserve -t" au début de la ligne, ce qui donne donc :

command="svnserve -t" ssh-rsa {identifiant} svn@s_miroir

Avec cette méthode, svnserve -t sera systématiquement utilisée lors d'une connexion avec la clé de l'utilisateur svn sur s_miroir.

Mettons en place maintenant le miroir en lui même. Il faut tout d'abord créer un dépôt svn :

[svn@s_miroir ~]$ mkdir ~/depot_svn
[svn@s_miroir ~]$ svnadmin create ~/depot_svn

Certaines opération sur les propriétés des révisions seront changées lors de la synchronisation, il peut donc être bienvenu de restreindre ces opérations sur le dépôt. Pour ce faire, créez le fichier hooks/pre-revprop-change dans votre dépôt :

[svn@s_miroir ~]$ vim ~/.depot_svn/hooks/pre-revprop-change

Et insérez-y le contenu suivant :

#!/bin/sh
USER="$3"

if [ "$USER" = "svnsync" ]; then exit 0; fi

echo "Only the svnsync user can change revprops" >&2
exit 1
EOF

Pensez ensuite à rendre ce script exécutable :

[svn@s_miroir ~]$ chmod +x ~/.depot_svn/hooks/pre-revprop-change

On initialise le nouveau dépôt :

[svn@s_miroir ~]$ svnsync init --username svnsync file:///home/svn/depot_svn svn+ssh://s_svn/chemin/vers/le/depot
Copied properties for revision 0

Et enfin on lance la procédure :

[svn@s_miroir ~]$ svnsync sync --username svnsync file:///home/svn/depot_svn
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
Committed revision 3.
Copied properties for revision 3.
...

Notez l'utilisation de l'utilisateur 'svnsync' dans ces deux commandes. Si vous l'omettez, le script créé plus tôt interdira la modification des propriétés de révision, et la synchronisation ne pourra pas avoir lieu.

Une fois la synchronisation initiale terminée, vous avez un miroir de votre dépôt svn sur s_miroir :-) Pour automatiser la tâche, vous pouvez créer une tâche cron sur la commande de synchronisation (la seconde donc, le 'svnsync init' ne devra plus être exécutée).

lundi 5 novembre 2007

Galette 0.63 RC2

La seconde Release Candidate pour la version 0.63 de Galette vient de voir le jour !

La « bête » est disponible sur l'espace de téléchargement de Gna! :
http://download.gna.org/galette/galette-0.63-RC2.tgz

N'hésitez pas à tester cette mouture, à la pousser dans ses derniers retranchements, et éventuellement à rapporter les bogues et autres coquilles que vous pourriez constater (en espérant qu'il n'y en aie pas :-p).

mardi 20 juin 2006

Une brique dans le ventre... ou un pavé dans la vitrine ! (2)

Suite du périple avec mon ancien employeur...

L'affaire est désormais entre les mains du tribunal des Prud'Hommes, néanmoins...

Il semble que cette société soit gérée inconsciemment ou encore malhonnêtement ! En effet, outre le fait que plusieurs mois de salaires et plusieurs fiches de paie manquent à l'appel, il se trouve aujourd'hui que la société (et son patron) ne peuvent être joints ; les numéros de téléphone n'existent simplement plus !! J'ai d'autre part eu confirmation dernièrement par le tribunal de commerce qu'aucune action de liquidation ou de dépôt de bilan n'a été engagée à ce jour. Il semblerait de plus qu'un déménagement des locaux soit en cours...

Alors, qu'en penser ? Difficultés insurmontables ou désir d'aller se la couler douce à l'étranger ? Une telle malhonnêteté ne saurait rester sans conséquences, je l'espère.

Dans cette affaire, non seulement les employés ont été lésés ; mais également les clients (bris de matériels lors de maintenances, aucun suivi des logiciels et sites vendus, ...) ; où cela s'arrêtera-t-il ?

La suite au prochain épisode.

mardi 2 mai 2006

Une brique dans le ventre... ou un pavé dans la vitrine ! (1)

Petite remarque pour ceux que ça pourrait intéresser : "une brique dans le ventre" est le nom d'une émission de télévision traitant de l'immobilier et de la décoration intérieure sur - je vous le donne en mille - une chaîne belge :)

Trève de plaisanteries. Je débute ce billet alors que je m'apprête d'ici quelques malheureuses heures à engager une procédure auprès du tribunal des Prud'Hommes contre mon ancien employeur. Quatre mois intégral de salaire me sont encore dûs ; je n'ai même pas pu me payer de vacances bien méritées !!

Je pense m'être (une fois de plus) fait avoir, mais je commence à sévir. Ce qui m'ennuie dans cette procédure, c'est que je crains qu'elle soit longue et pénible. L'entreprise ne fais plus un Euro de chiffre d'affaire depuis plusieurs mois déjà, le patron s'accroche à ses rêves fous (il doit être atteint de la folie des grandeurs...) et totalement irréalisables. Sa dernière excuse en date : il est en train de créer (enfin de faire créer par des stagiaires) un système dynamique de je-ne-sais-quoi pour des CCI qui va lui rapporter au moins dix mille euros par mois... C'est cela oui, et la marmotte, comme dirait l'autre...

Bref, la suite au prochain épisode !

mercredi 12 avril 2006

Projet Cantine

Je suis actuellement en train de travailler à mettre en ligne un site pour mon projet de gestion de Cantine en Java réalisé sous licence GNU/GPL lors de mon dernier emploi.

Le site était initialement censé être hébergé sur l'espace sourceforge ; mais de nombreuses restrictions se sont mises en travers de mon chemin :

  • impossible d'écrire dans un répertoire ou un fichier (même avec un chmod 777), sourceforge restreint cela. En lieu et place, il faut recourir à au répertoire /tmp/persistent/cketuveux/ et créer des liens de l'autre côté
  • il est impossible d'envoyer des mails depuis leur hébergement. La fonction mail() et sendmail sont désactivés depuis le site ; et il n'est même pas possible de recourir à un SMTP externe (connection refused !!). Il semble qu'on ne puisse pas faire d'accès externes à leurs serveurs...

Bref, migration vers free ; où je pense que j'aurais moins de problèmes. De plus, l'upload vers sourceforge est carrément lent (le download aussi d'ailleurs...). Cela fait un moment que je n'ai plus utilisé réellement les services des hébergements free (uniquement à des fins de sauvegarde de données et de mirroring de x-tnd.be). En définitive, free pour le site et les services web ; sourceforge pour les services programmation (CVS/SVN, mailing listes, etc...) et les hippopotames seront bien gardés !

Gageons que je ne serai pas trop déçu (mais avec tous les problèmes - pour parler poliment - que je viens d'avoir chez sourceforge, ce serait un comble d'être déçu :) )