Le principe est simple :
1) On dispose d’un fichier .xml qui contient toutes les modification effectuées, par exemple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="UTF-8"?>
 
<databaseChangeLog
  xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd">
 
     <changeSet id="1" author="marc">
        <createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>
            <column name="name" type="varchar(50)">
                <constraints nullable="false"/>
            </column>
            <column name="active" type="boolean" defaultValueBoolean="true"/>
        </createTable>
    </changeSet>
</databaseChangeLog>

2) Ensuite on lance Liquibase qui se charge d’effectuer les opérations de mise à jour de la base. Pour effectuer cette opération, il est possible d’utiliser par exemple un plugin maven :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

 
<plugin>
    <groupId>org.liquibase</groupId>
    <artifactId>liquibase-maven-plugin</artifactId>
    <version>2.0.3</version>
    <configuration>
        <changeLogFile>src/test/resources/liquibase_test.xml</changeLogFile>
        <driver>com.mysql.jdbc.Driver</driver>
        <url>jdbc:mysql://localhost:3306/orioai_indexing_test</url>
        <username>orioai</username>
        <password>orioai</password>
    </configuration>
    <executions>
        <execution>
            <phase>process-resources</phase>
            <goals>
                <goal>update</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Parmi les options proposées très intéressantes, grâce à Liquibase on va pouvoir :

• Connaitre le statut de la base par rapport aux opérations décrites dans le fichier xml (mvn liquibase:status)
• Effectuer la mise à jour (mvn liquibase:update)
• Effectuer un rollback à un point donné (mvn -DrollbackCount=1 liquibase:rollback)

Il existe également la possibilité d’utiliser Liquibase via Spring.

• Ajouter dans votre /etc/apt/sources.list les deux lignes suivantes :
  deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu oneiric main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu oneiric main
• Exécuter ensuite les commandes suivantes :
  sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa
sudo apt-get update
sudo apt-get install firefox

EDIT : suite aux remarques de certains lecteurs, il n’y a pas besoin d’ajouter de dépôts, dans /etc/apt/sources.list, la commande add-apt-repository se charge de tout.

Domogik est une solution libre d’automatisation de votre habitat basée sur le protocole xPL. Huit plugins sont livrés avec cette version :

Une interface graphique est fournie avec Domogik : Domoweb. C’est une application web utilisant les dernières technologies (HTML5, CSS3) afin de vous permettre de contrôler votre maison depuis un navigateur internet. Une application pour Android est en cours de développement (Domodroid) : elle est déjà fonctionnelle mais toujours en phase de test.

Domogik a pour but de simplifier le contrôle des équipements de votre maison, quelles que soient les technologies. Pour ce faire, Domogik est modulaire : le support d’une nouvelle technologie peut être simplement ajouté à l’aide d’un plugin et chacun peut créer sa propre interface avec le langage de son choix grâce à son API REST.

Grâçe au wiki, une documentation très complète est disponible. Elle détaille l’installation, l’utilisation ainsi que les possibilités d’extension de Domogik.

A propos des versions futures

La prochaine version (les développements sont déjà bien avancés) concernera plus  particulièrement les plugins. Domogik sera livré nu, pour installer seulement les plugins dont vous avez besoin, il suffira de passer par l’administration, et choisir les plugins présents dans un des dépôts. Cette indépendance entre les plugins et le coeur de Domogik apportera beaucoup plus de souplesse et de rapidité pour la mise à disposition des plugins. Il sera par exemple possible de tester les plugins en cours de développement en activant le dépôt « experimental » ou encore de se contenter des plugins stables avec la configuration par défaut.

La version suivante concernera la fonctionnalité la plus attendue de Domogik, à savoir la possibilité de créer des scénarios.

Téléchargement et documentation

Support et autres liens

• Il faut bien évidemment avoir préalablement déclaré le plugin dans votre fichier central pom.xml, dans la section <plugins> :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.8</version>
</plugin>

• On exécute ensuite les tests unitaires avec la commande :

mvn clean test

• On peut n’exécuter qu’une classe parmi toutes les classes de tests :

mvn -Dtest=MyClass clean test

• On peut n’exécuter qu’une méthode de la classe en question (attention uniquement à partir de la version 2.8 du plugin :

mvn -Dtest=MyClass#myMethod clean test

• Il est possible également d’afficher le résultat (les erreurs) des tests directement dans la console (plutôt que dans le fichier de log de surefire), pour cela ajouter l’option :

-Dsurefire.useFile=false

Pour la doc complète de ce plugin, voir son site officiel.

Voyons tout d’abord, grossièrement, ce qu’est un service web : c’est « un programme informatique permettant la communication et l’échange de données entre applications et systèmes hétérogènes dans des environnements distribués » (source Wikipédia). Il s’agit donc d’une application qui expose (met à disposition) des fonctionnalités. Celles-ci sont accessibles par Internet ou en mode plus restreint (Intranet). Un exemple de service web pourrait être un moteur de recherche qui met à disposition des fonctions permettant la recherche et/ou l’indexation de documents.
L’intérêt d’un service web, outre le fait qu’il soit accessible à distance, est qu’il peut être accessible par une application qui est écrite dans un langage différent de celui de l’application qui expose ses services web. Pour reprendre l’exemple précédent, je peux très bien avoir une plateforme de recherche de documents écrite en Java et accéder à ses services par un programme réalisé en Python.
Concernant le protocole de communication utilisé, il existe deux grandes familles : REST ou SOAP / WSDL. Je ne rentrerai pas ici dans les détails concernant les différences vous pouvez approfondir en lisant cet article sur Wikipédia. Disons que si REST est très flexible et simple à mettre en oeuvre, SOAP est assez utilisé dans le monde de l’entreprise. Vous pouvez aussi lire cet article qui explique bien la philosophie de ces deux protocoles.

Nous utiliserons ici SOAP. La première chose est d’installer la bibliothèque Python qui va nous permettre d’utiliser SOAP pour communiquer avec notre service web. Il existe plusieurs bibliothèques, citons :

• Pour les « anciennes » :
  SOAPpy (simple à utiliser mais n’est plus maintenue), ZSI (plus complexe à utiliser)
• Pour les « nouvelles » :
  SUDS (simple à utiliser pour déclarer un client, plus complexe pour un serveur, soaplib (le contraire).

Comme ici nous souhaitons accéder à un service web existant, il nous faut un client SOAP. J’ai donc choisi SUDS.

Installation de la bibliothèque

sudo easy_install suds

Accès au service web

from suds.client import Client
URL = 'http://localhost:8180/ori-oai-indexing-solr/xfire/IndexingService?wsdl'
my_ws = Client(URL)
if my_ws is None:
exit(msg="Error can't connect to :%s" % URL)
print("service : %s" % my_ws)
print("Connected to %s" % URL)

URL est donc l’url de mon service web.
Je pense que ces lignes se passent de commentaires tellement elles sont explicites. A noter que l’avant dernière ligne permet d’afficher l’ensemble des fonctionnalités (fonctions) qui sont exposées par le service web.

Ensuite pour accéder à une fonction, il suffit d’utiliser l’attribut service :

my_ws.service.my_function(...)

Evidemment la fonction my_fonction doit avoir été exposée et donc se retrouver dans la liste affichée par print(my_ws).

J’extrait de ma base oa_dev les champs cli_nom et cli_vil de ma table tbd_cli vers le fichier cli.csv.

Simple non ?

Reste à savoir quel gestionnaire de version utiliser : personnellement j’ai commencé par CVS puis sa version améliorée Subversion. Il y a quelques temps lors du démarrage du projet Domogik, mon collègue m’a proposé d’utiliser Mercurial. Je ne connaissais pas spécialement et j’ai dit “Ok pourquoi pas”. Il m’a vaguement expliqué les différences en me précisant que Mercurial était un gestionnaire de versions décentralisé. Cela n’a pas fait “tilt” chez moi et j’ai à peine relevé la remarque. Lorsqu’on a commencé à travailler, en bon informaticien, je n’ai pas pris le temps de lire la documentation de Mercurial et je me suis dit : “Bon à part la syntaxe des commandes qui change ça reste un gestionnaire de versions”.

Et là grave erreur, j’ai utilisé pendant des mois Mercurial comme j’aurais fait avec Subversion. Du coup j’ai fréquemment pesté envers Mercurial, avec toute la mauvaise foi qui s’impose, avançant des arguments tels que “Mercurial c’est beaucoup trop compliqué pour notre projet” etc. Je dis grave erreur, car par hasard un autre collègue m’a donné le lien vers un excellent tutoriel qui explique les différences fondamentales entre Subversion et Mercurial. Là je me suis dit que j’avais perdu pas mal de temps en sous-exploitant la souplesse offerte par Mercurial. En voici un (très gros) résumé :

• Mercurial est effectivement décentralisé, ainsi chaque développeur possède son propre dépôt (repository). Ainsi vous pouvez effectuer des commits locaux sans affecter le dépôt central tout en bénéficiant d’un historique de vos modifications.
• Mercurial utilise la notion de changeset plutôt que de revision. Cela signifie, en gros, qu’il mémorise l’historique des changements qui ont été appliqués pour passer d’une version à l’autre. Subversion lui mémorise les versions de chaque fichier.
• La notion de fusion (merge) est parfaitement gérée par Mercurial, et je dirais qu’il s’agit même d’une opération qu’on est amené à effectuer assez fréquemment. Si vous êtes plusieurs développeurs qui travaillent sur une même version et que vous effectuez régulièrement des commits sans les publier sur le dépôt central, alors lorsque vous souhaiterez récupérer les mises à jour de vos collègues, un merge sera nécessaire, même si vous n’avez pas travaillé sur les mêmes fichiers (je sais,  lorsqu’on vient du monde de Subversion cela peut paraître étrange, mais vous comprendrez le pourquoi du comment si vous suivez le tutoriel dont je vous parle à la fin). Notons qu’avec Subversion la notion de merge fait souvent peur et doit être appliquée très prudemment, avec Mercurial il y a rarement des soucis.

Bon les différences que j’expose ci-dessus peuvent vous paraître énigmatiques si vous ne connaissez pas Mercurial, mais elles sont fondamentales. Pour ceux qui sont confrontés à la gestion de versions (et qui lisent la langue anglaise), je vous recommande très chaudement cet excellent tutoriel. Après l’avoir lu, alors que j’étais initialement réticent à Mercurial, j’ai été définitivement convaincu sur la supériorité de Mercurial. Il n’est pas plus compliqué à utiliser que Subversion et offre à mon sens beaucoup plus de possibilités.

Bonne gestion de versions !

Références :

• Tutoriel hginit [en]
• Le livre de référence de Mercurial [en]

Voici les étapes à suivre :

1) Créer dans le répertoire conf de Dokuwiki un fichier nommé userstyle.css.
2) Définir dans ce fichier les styles pour chaque niveau de titre, par exemple :
div.dokuwiki h1 a {color: #1f1f52 !important;}
div.dokuwiki h2 a {font-weight: bold; color: #1c1cf4 !important;}
div.dokuwiki h3 a {color: #5b5bf6 !important;}

Remarque 1 : la présence de l’élément !important est impérative pour pouvoir changer la couleur.
Remarque 2 : évidemment il n’y a pas que les titres qu’il est possible de modifier. Par exemple on peut aussi modifier l’apparence des portions de code :
div.dokuwiki pre.code {
border: none;
border-left: 2px solid #F99451;
background-color: #e8e4e4;
color: #000053;
font-family: monospace;
font-size: 120%;
}
Remarque 3 : pour repérer les styles, aller sur la page et utiliser l’excellente extension de Firefox : firebug.

A partir d’un petit programme Java tout simple, je tentais de me connecter à une base de données mysql locale.

1) Premier problème j’obtenais un « Communications link failure … Connection refused ».

La solution est de commenter la variable skip-networking dans le fichier /etc/mysql/my.cnf. En effet l’accès à la base via jdbc se fait par TCP/IP. Si skip-networking est activé, mysql refuse les connexions en TCP/IP…

2) Second problème (celui qui m’a fait tourner en rond pendant des heures) : j’obtenais un « Communications link failure … java.io.EOFException: Can not read response from server ».

La solution est d’ajouter les lignes suivantes dans /etc/hosts.allow

mysqld: ALL : ALLOW
mysqld-max: ALL : ALLOW

A noter que ces manipulations sont propres à Archlinux. J’ai testé sur Ubuntu et là ça marche « out of the box ».

Ces informations ont été trouvées sur le wiki d’Archlinux.

Lieu de stockage des templates

Surtout pas (ce qui pourrait paraître logique), /mon_projet/app1/templates/index.html et /mon_projet/app2/templates/index.html. Si vous le faites vous risquez de charger le fichier index.html de app1 lorsque vous appelez app2.

Vous avez le choix :

• dans /mon_projet/app1/templates/app1/index.html (idem pour app2 évidemment).
• dans /mon_projet/templates/app1/index.html (idem pour app2).

Personnellement je préfère la deuxième solution car le chemin est moins compliqué.

Configuration du fichier settings.py

• Au niveau de la variable TEMPLATE_LOADERS, vous devez avoir la ligne suivante :
  'django.template.loaders.filesystem.Loader'

• Au niveau de la variable TEMPLATE_DIRS, les chemins d’accès aux templates doivent être déclarés :
  Si vous avez choisi la première option pour le stockage des templates :
  os.path.join(ROOT, "app1/templates"),
os.path.join(ROOT, "app2/templates"),
  Si vous avez choisi la seconde option :
  os.path.join(ROOT, "templates"),
  Ceci suppose que vous avez déclaré en début de fichier :
  ROOT = os.path.dirname(os.path.abspath(__file__))

Chargement des templates

Lors du chargement des templates, il faut préciser le nom de l’application : app1/index.html et app2/index.html