Vous avez besoin de faire des petits diagrammes de séquences, mais vous ne voulez (ou pouvez) pas sortir la grosse artillerie, du genre Visual Paradigm, Eclipse, Netbeans, etc. ? Voici la solution http://websequencediagrams.com/, un outil en ligne très simple, mais que je pense suffisamment souple pour répondre à des petits besoins. Voici un petit exemple, sous la forme d’une image finale, et voici sa source. Pour information cela représente l’obtention d’un ticket TGT et de TGS, c’est à une dire pour une authentification Kerberos.
Surtout, penser à essayer les différents thèmes (pour ma part j’ai un petit faible pour le thème blue modern), et à consulter l’aide. Tout simplement bluffant je trouve ! Juste un petit bémol, je n’ai pas trouvé d’option pour avoir une numérotation des actions. Mais j’imagine que ce n’est qu’une question de temps !
Encore un billet dans la série XWiki, mais décidemment, cet outil me rend vraiment beaucoup de services. Ma dernière oeuvre (sic) consiste en la création d’une mini gestion des membres de l’association (GUSES, pour ceux qui ne le savent pas déjà !). Nous utilisons déjà Galette pour gérer les cotisations, mais malheureusement il n’y a rien (à ma connaissance) pour y brancher des hooks, dans mon cas ajouter l’utilisateur à la liste de diffusion de l’assocation.
Bref, quel rapport avec XWiki me direz vous ? Et bien, gràce à la bibliothèque SSH Trilead pour Java j’ai écrire une classe Groovy qui me permet d’exécuter des commandes (au sens unix) à distance. Et via quelques scripts shell et perl, il m’est désormais possible lors de l’ajout d’un utilisateur dans XWiki, d’automatiquement l’ajouter dans la base Galette, mais aussi l’inscrire à la liste de diffusion. D’autant plus que ces deux opérations étaient jusqu’alors réalisé par deux personnes différentes, n’arrangeant rien.
Un petit d’exemple d’utilisation de ma classe Groovy (sshhelper), en Groovy :
Il est à noter que j’ai eu des problèmes (avec la bibliothèque Trilead) d’authentification en login / mot de passe vers des serveurs Linux (Debian) alors que cela fonctionne vers des serveurs Solaris. Cependant, l’authentification par clé a fonctionné vers les deux OS.
À la demande de Vincent, je me lance dans un retour d’expérience sur XWiki, néanmoins même si cela fais quelques mois que j’utilise le produit, je n’ai passé que quelques jours à l’utiliser (enfin plutôt à le programmer) de manière avancée, donc à prendre avec un peu de recul. De plus, j’ai mis un certain temps à écrire ce billet, que j’ai repris de nombreuses fois, donc la trame n’est pas forcément fameuse, je m’en excuse par avance.
Commençons par le début : l’installation. Alors, cette étape est très facile, néanmoins il n’est pas toujours facile de bien comprendre les différentes versions, ce qu’elles font, etc. Pour ma part, ce billet ne parle que du produit XWiki Enterprise, en version 1.5 et 1.6, ne connaissant pas les autres produits.
Une fois le produit installé, la prise en main est assez rapide, et assez intuitive. Néanmoins à mes débuts (version 1.5 donc) j’ai été quelque peu déçu par la syntaxe assez pauvre, surtout pour moi qui utilise beaucoup dokuwiki, où la syntaxe permet par exemple de gérer l’alignement d’une cellule au sein d’un tableau. Cependant, la version 1.6 apporte de nouvelles syntaxes (dont une compatibilité avec des syntaxes répandues, comme celle de mediawiki), donc cela est en bonne voie.
Concernant mon expérience, j’utilise principalement XWiki pour sa partie développement d’application, c’est à dire la capacité de créer des petites applications (métier ? j’exagère peut être un peu, encore que…) à l’intérieur de XWiki, sans jamais modifier une seule ligne de code de XWiki. Ces développements s’effectuent via les capacités de scripting velocity, et d’extension via Groovy. C’est un vrai bonheur, en effet je ne connais peu (ou pas) d’autres moyens simples de développer rapidement une petite application Web, sans me préocccuper du rendu, du modèle, etc.
Coté produit, la partie Wiki pure est relativement bien documenté, avec une page sur la syntaxe très complète (mais pas tout à fait exhaustive), mais un petit regret concernant la documentation associé à la partie développement. Il existe plein de choses qui ne sont pas (encore) documentés, notamment pour les attributs lors de l’ajout d’une propriété à un objet. Mais après avoir discuté avec Jean-Vincent de XWiki, il semblerais que la partie dev ne soit pas la plus utilisée, ce qui peut expliquer… Et cela est peut-être liée ou pas, mais l’impossiblié de supprimer une propriété existante est vraiment pénible. Cela rend la création des objets assez périlleuses, et il faut savoir exactement à l’avance ce qu’on a besoin de mettre dans les objets
Pour finir avec la documentation, XWiki est très bien documenté d’une manière générale, mais il n’est pas facile de s’y retrouver entre les différentes sources de documentation. Je pense qu’il manque de tutoriaux, celui-ci (création d’une application de FAQ) est vraiment bien, il en faudrais d’autres selon moi. Cependant, la communauté (que ce soit liste de diffusion ou IRC) étant vraiment très réactive, et d’une aide précieuse, cela compense un peu le fouillis (je vais me faire gronder par les gens de XWiki dans la documentation.
Un autre bémol réside dans la customisation graphique. Bien que je n’ai pas regardé de prêt, il me semble difficile, voire très difficile, de modifier la forme de XWiki. Certes, il est très simple de modifier son apparence par CSS, mais faire des modifications plus profondes me semble vraiment très difficile.
Côté technique, un des plus grands reproche concerne la gestion de la mêmoire. Il existe par exemple une fonctionnalité très intéressante permettant l’import/export du contenu du wiki sous forme d’un xar (Xwiki ARchive) mais il semblerais que le moteur à besoin de tout monter en mémoire avant de mettre à disposition le fichier d’archive, ce qui est assez embêtant quand il y a un certain nombres de pages. De plus, du fait (enfin c’est mon interprétation) de l’utilisation d’hibernate, XWiki procède quelques fois à de *très* grosse requête SQL. Par exemple dans le cas d’une suppression d’une page avec des commentaires, l’ensemble des données (et donc pas juste l’id de la page) sont passées dans la requête, ce qui nécessite donc de paramètrer son serveur SQL pour accepter des requêtes SQL allant jusqu’à plusieurs dizaines de MB..
En conclusion, pour ceux qui ne l’ont pas encore compris, et malgré ces quelqus points négatifs, je suis devenu un très grand fan de XWiki ! Mais cela ne m’empêche pas de rester fan de dokuwiki, considérant les deux comme complémentaires. Son développement avancant à grand pas, avec des fonctionnalités probablement inédites (import de documents MS Office, OpenOffice.org) XWiki est en passe de devenir le leader (si ce n’est déjà pas le cas) sur le marché des wikis d’enterprises.
Hier, je cherchais à manipuler une liste en velocity, mais malheureusement en suivant l’exemple de cette page, cela ne fonctionnais pas. Je pensais que les extensions n’étaient pas utilisées par xwiki, mais en fait elles sont disponibles, comme l’indique le fichier META-INF/plexus/components.xml, contenu dans xwiki-core-velocity (donc si jamais vous voulez rajouter d’autres extensions, c’est donc ici que cela se passe).
C’est plus ue note personnelle qu’un vrai article, mais il m’arrive assez souvent d’avoir besoin de mettre en évidence un élément d’une image, et à chaque fois je perds du temps à retrouver comment faire avec GIMP. Donc au cas où cela vous intéresse, et surtout pour m’en souvenir, voici la démarche :
sélectionner la partie à mettre en évidence
en utilisant le menu contextuelle (click droit ou menu de l’image), choisir l’option « Sélection » puis « Bordure », définir la taille de la bordure, puis utiliser l’outil de remplissage.
Salomé TMF est un outil opensource pour gérer ses campagnes de test, un peu à la test director (sic). Il permet de créer ses scénarios, puis de les jouer, etc. Bon, a priori ca semble pas grand chose, mais pourtant c’est très intéressant. En effet, via des plugins, il permet d’importer (pas encore testé cette fonctionnalité cependant) des tests depuis un fichier Excel (personne n’est parfait), et aussi d’exporter, ce qui peut s’avérer très pratique par exemple pour produire un cahier de recette livrable au client.
Néanmoins, comme beaucoup (tous ? ahah je suis méchant) de produits opensource, l’interface est très mal pensé, et totalement contre productive (cependant je pense que testlink est encore pire). Mais si le sujet vous intéresse, je ne peux que vous recommander de jetter un oeil à ce produit. Je ne l’ai pas encore testé pour de vrai, mais cela ne saurait tarder.
Premier post dans cette catégorie, je me tente à un nouvel exercice. Travaillant le domaine de la PKI (identification, signature numérique, chiffrement, etc.) et devenant de plus adepte de service en ligne, je me pose beaucoup de questions sur la confidentialité et l’intégrité des données que je consulte à travers différents portails.
Imaginons un utilisateur (en l’occurence moi) d’un portail type netvibes. Ce dernier propose un widget gestion de tâches, idée très intéressante. Néanmoins, dans un souci de confidentialité, je n’ai guère envie que ces tâches soient stockées en clair quelque part (typiquement chez l’hébergeur du portail). Je souhaiterais donc être en mesure de pouvoir créer une tâche, tout en assurant la confidentialité via un mécanisme de chiffrement. Ca tombe très bien, j’ai déjà un certificat de chiffrement pour mon courrier électronique.
Je pousse quelques secondes ma réflexion, une page web (en utilisant du xhtml) n’est rien d’autre qu’un document XML valide. Heureuse coincidence, il existe un schéma XML, à savoir XAdES (surcouche à xmldsig) qui permet de chiffrer et/ou signer tout ou une partie d’un document XML (bon, je résume, ce schéma apporte également bien d’autre chose).
Donc, imaginons un navigateur qui en plus d’implémenter les fonctions classiques, sait interpréter la norme XAdES, en relation avec des certificats clients, aussi bien logiciel que matériel (pour information Firefox est déjà capable d’utiliser ces deux supports). Cela permettrait donc de disposer d’une portion (un div !) - dans mon cas une tåche - chiffrée dont seule la clé privée de mon certificat à moi permet la lecture de cette tâche.
Voilà un premier exemple d’utilisation de mon idée du soir, mais il y en a bien plus, comme par exemple la possibilité de signer les donnés d’un formulaire, etc.
N’hésitez pas à commenter si vous avez des questions, c’est juste une idée qui m’est passée, et la mettre (rapidement) à plat n’est pas forcément un exercice facile !
Note pour les spécialistes, le chiffrement n’est pas assuré directement par XAdES, mais c’est pour rester simple.
Derrière ces termes que certains qualifient de “mots pour décideur pressés lisant 01 informatique” se cache pourtant des vrais concepts, je vais tacher en quelques phrases de les expliquer, et surtout de montrer les intérêts.
le data warehouse (entrepôt de données dans notre chère langue maternelle) est un composant technique (le plus souvent une base de données) où sont exportées des données métiers. Imaginons une application XYZ (qui elle même utilise une base de données pour ses besoins internes), qui exporte à intervalle régulier l’état de ses données métiers.
L’ETL (Extract Transform Load) est l’étape suivante, celle qui permet d’extraire les données des différentes base warehouse, et éventuellement les transformer.
et finalement, il nous reste à présenter les données métiers sous forme graphique, c’est ce qu’on appelle du BI - Business Intelligence (informatique décisionnelle en bon français).
Vous pourriez vous demander “mais à quoi tout cela sert ?” et bien, c’est relativement. A traiter ses données en fonction de ses besoins, et pas en fonction des fonctionnalités de reporting que propose un logiciel. De plus, l’utilisation d’outil dédiés (typiquement pour le reporting) permet de regrouper l’ensemble des rapports sous une même interface (un portail) plutôt que de devoir se rendre sur chaque applicaiton pour y consulter les rapports proposés par les N interfaces d’administrations des N logiciels utilisés (et qui de toute façon sont rarement adaptés).
