Blog d'un ingénieur informaticien parmi d'autres...
Blog myBlog = BlogFactory.getWordPressBlog();
Installer Gitorious avec RVM
8/10/12
Introduction
Il y a quelques temps, je me suis lancé dans l’installation de Gitorious. Celle-ci n’est pas évidente (mais je ne suis pas très familier des déploiements d’applications Ruby on Rails).
Heureusement, pour palier à cette complexité, il existe un certain nombre de ressources pour aider. Voici donc une liste de liens qui m’ont aidé :
- Sur Bitnami, il est possible de se procurer des images « prêtes à l’emploi », dont Gitorious (parfaites pour tester le programme, mais qui ne sont pas recommandées pour la production).
- Des recettes Chef sont disponibles, pour automatiser l’installation.
- Sur le site officiel, plusieurs guides d’installation en fonction de l’environnement.
En particulier, ce tutoriel est beaucoup plus simple que la version originale. C’est donc à partir de cet article que j’ai monté mon installation de Gitorious, avec quelques adaptations, que je me propose de partager ici, en espérant qu’elles aideront ceux qui veulent se lancer dans l’installation de Gitorious.
Rapidement, voici les modifications que je présenterai ici :
- L’installation a été réalisée sur une Ubuntu Server 12.04 LTS.
- Au lieu d’utiliser les paquets natifs, tout ce qui touche à Ruby sera géré par RVM, qui offre l’avantage de permettre de combiner comme on le souhaite plusieurs versions de Ruby et de gems, sans être limité par les versions disponibles dans le gestionnaire de paquets.
- Les répertoires d’installations ne sont pas ceux du tutoriel.
Avertissement avant d’aller plus loin : n’étant ni développeur Ruby, ni administrateur système, il est possible que certains choix d’installation ou de configuration que je vais présenter ne soient pas recommandés. Dans ce cas, je vous remercierai d’apporter des précisions en commentaires.
Compte-rendu heuristique du Paris JUG
14/06/12
Ce mardi soir avait lieu la soirée « Serveurs d’application » au Paris JUG. Après avoir pendant un temps pris mes notes en markdown (avec Mou), j’ai voulu tester la prise de note en carte heuristique. J’ai pour cela utilisé le logiciel XMind, que j’ai trouvé excellent pour cela.
Sans plus attendre, voici donc le résultat de ce test (zoomez ou téléchargez l’image pour voir ce que ça donne) :
Soirée Serveurs d’application
Maven au pays des proxys
15/01/12
Le problème…
Il y a quelques temps, j’ai eu pour mission de stabiliser et de « mavenizer » une application legacy, dont le build était devenu ingérable (dépendances dans divers répertoires, mélanges de scripts shell, Ant, etc.).
Au sujet de la mavenization elle-même, je vous recommande cet article, donnant une méthode fiable permettant de retrouver la version exacte des dépendances lorsqu’elles ne sont pas connues. Je passe cependant rapidement sur cette étape qui n’est pas le sujet ici. Nous arrivons donc directement au moment où nous avons un fichier « pom.xml » convenable, dont nous voulons vérifier le bon fonctionnement pour assurer le packaging de l’application. Et c’est là que les choses commencent à se compliquer.
Car ce que j’ai oublier de préciser, c’est que cette mission est effectuée pour « Gros client », chez qui les règles de sécurité sont strictes : l’accès internet se fait uniquement au travers d’un proxy. Et plus particulièrement le modèle PALC avec toutes les options : identification individuelle obligatoire sur ledit proxy, mot de passe à modifier tous les 3 mois, verrouillage du compte après 5 tentatives ratées, etc. Pour Maven qui aime bien « télécharger l’univers », c’est problématique.
Petite digression sur une mauvaise surprise découverte lors de cette mission… Ubuntu 11.10 n’est pas du tout adapté au travail dans un environnement utilisant un proxy : il souffre en effet d’une régression empêchant le paramétrage d’exceptions (pour les serveurs du réseau local).
Paramétrer le proxy pour Maven
Maven fournit un guide pour paramétrer un proxy. L’opération consiste à renseigner les paramètres du proxy dans le « settings.xml » :
1 2 3 4 5 6 7 8 9 10 11 | <proxies> <proxy> <active>true</active> <protocol>http</protocol> <host>palc.grosclient.com</host> <port>8080</port> <username>user</username> <password>password</password> <nonProxyHosts></nonProxyHosts> </proxy> </proxies> |
Une fois ce paramétrage effectué, les dépôts sont bien résolus et les dépendances téléchargées. Mais il reste un soucis : certains dépôts irréductibles résistent encore… Par exemple le dépôt JBoss, ou encore Sonatype OSS. La cause est vite identifiée : ces dépôts utilisent le protocole « https » et non « http ».
Qu’à cela ne tienne : on duplique le bloc « proxy » en modifiant le protocole. A ceci près que ça ne marche pas… Maven ne sait utiliser qu’un seul proxy à la fois. Si on utilise le proxy « https », on pert le « http », et inversement. Peut-être une idée de correction à implémenter pour le hackergarten de mercredi prochain…
La seule solution que j’ai pu trouver à ce jour est de paramétrer les proxys au niveau de la ligne de commande :
1 2 3 4 5 6 7 8 9 10 | mvn -Dhttp.proxyHost=palc.grosclient.com -Dhttp.proxyPort=8080 -Dhttp.proxyUser=user -Dhttp.proxyPassword=password -Dhttps.proxyHost=palc.grosclient.com -Dhttps.proxyPort=8080 -Dhttps.proxyUser=user -Dhttps.proxyPassword=password install |
Il est possible de paramétrer un proxy dans le « settings.xml » et le deuxième en ligne de commande mais ce n’est pas très intuitif. J’aime autant que tous les paramètres soient au même endroit.
Une fois les paramètres correctement configurés, on peut les pérenniser en les enregistrant dans la variable d’environnement MAVEN_OPTS.
Utiliser un dépôt Maven interne
Suite au paramétrage correct des proxys (http et https), Maven peut à nouveau télécharger tout internet… et le build peut fonctionner. Nous pouvons donc aller plus loin et installer un dépôt Maven chez « Gros client », afin d’y publier les artefacts produits.
Cependant, ce serveur peut également servir à régler autrement notre problème de proxy. Pour cela, il y a un pré-requis : le serveur doit être accessible directement depuis le réseau de développement, et avoir accès à internet (si possible sans proxy). Dans notre cas, c’est Nexus qui fait office de dépôt Maven (mais la même technique doit fonctionner avec Artifactory ou autre…). Ensuite :
- On configure différents dépôts de type « proxy » vers chacun des dépôts externes dont on a besoin.
- On ajoute tous ces dépôts au dépôt groupe « public ».
Enfin, nous devons expliquer à Maven qu’il doit systématiquement utiliser notre serveur interne au lieu de tenter d’accéder directement aux dépôts externes (Maven central, etc.). Pour cela, retour dans « settings.xml », mais cette fois dans le bloc mirrors. Il suffit d’expliquer à Maven que tous les dépôts dont ont a besoin ont pour miroir notre serveur interne :
1 2 3 4 5 6 7 8 | <mirrors> <mirror> <id>nexus.grosclient.com</id> <name>Serveur Nexus de Gros client</name> <url>http://nexus.grosclient.com/content/groups/public</url> <mirrorOf>*</mirrorOf> </mirror> </mirrors> |
Avec cette configuration, le paramétrage des proxys fait précédemment doit être supprimé (ou une exception doit être ajoutée pour le dépôt interne).
Cette dernière configuration présente plusieurs avantages :
- L’ensemble des dépôts susceptibles d’être utilisés dans les différents projets de l’entreprise sont configurés de manière centrale, au niveau du dépôt. Cela permet
à l’équipe agileau chef de projet (rappel : nous sommes chez Gros client) de contrôler les dépôts/librairies utilisées sur le projet. - Le premier développeur qui demande une librairie au serveur Nexus va déclencher son téléchargement depuis son dépôt initial. Mais celle-ci sera ensuite mise en cache sur le serveur. Ainsi, les appels suivants (par les autres développeurs) se contenteront d’effectuer un téléchargement sur le réseau local, avec un gain de temps (voire de bande passante) non négligeable.
Utiliser Java 7 dans Talend Open Studio
31/10/11
Il y a quelques temps que je n’avais pas retouché à Talend Open Studio. Mais le Talend Partner Summit du mois dernier m’a donné l’occasion de recroiser des connaissances, et d’en apprendre un peu plus sur l’avenir du produit (« plate-forme unifiée », « big-data avec Hadoop« , etc.). Et surtout, ce fut une journée qui m’a donné envie de me replonger un peu dans le produit. En particulier, je me suis posé la question de la possibilité de développer de nouveaux composants en utilisant Java 7. En particulier l’API NIO2 qui apporte de nombreuses fonctionnalités qu’il me semble intéressant d’exploiter :
- accès (en lecture et en écriture) à de nouvelles propriétés des fichiers : propriétaire, permissions, gestion des liens symboliques et des fichiers cachés, etc.
- surveillance native des évènements (création/modification/suppression d’un fichier)
- plus grande simplicité et meilleures performances lors de l’accès et du parcours des fichiers avec Files
- etc.
Configurer Talend Open Studio
Lancer Talend Open Studio avec Java 7
La première étape est évidemment de se procurer et d’installer le JDK 7. Une fois celui-ci installé, il faut forcer Talend Open Studio à utiliser celui-ci. Cette étape est nécessaire pour permettre l’exécution de traitements utilisant du Java 7 au sein du studio. L marche à suivre ne surprendra pas les habitués d’Eclipse : il faut modifier le fichier ini correspondant à votre programme de lancement à la racine du produit, en lui ajoutant 2 lignes permettant de préciser la JVM de lancement. Dans mon cas (sous Ubuntu), le fichier est TalendOpenStudio-linux-gtk-x86_64.ini :
1 2 | -vm /usr/lib/jvm/java-7-jdk/bin/java |
Evidemment, tant le nom du fichier que le chemin du JDK sont à adapter à votre environnement.
Enregistrer le JDK 7 dans le studio
Encore une fois, il s’agit d’une étape classique de l’utilisation d’Eclipse : il faut se rendre dans les « Préférences » du Studio (menu « Fenêtre > Préférences »). De là, le menu qui nous intéresse est « Java > JRE installés ». Il faut alors ajouter le JDK 7, et le définir comme étant celui utilisé par défaut :
Configuration Java dans Talend Open Studio
Au passage, on remarque que dans les préférences « Java > Compilateur », le niveau de compatibilité du compilateur ne va que jusqu’à la version 1.6. Cela signifie qu’on ne pourra pas utiliser dans un composant les syntaxes introduites dans Java 7 (Try with resources, « diamond », etc.). En revanche, cela n’interdit pas d’utiliser les nouvelles classes du JDK 7, ce qui nous intéresse !
Enfin, avant de quitter les préférences, faisons un détour par « Java > Style de code > Formateur », afin d’y modifier le style par défaut. En effet, Talend utilise des nom de variables particulièrement longs (car ils contiennent l’identifiant du composant), tels que tos_count_tMSSqlLastInsertId_1. Aussi, lorsque plusieurs de ces variables sont utilisées dans une même instruction, la limite par défaut de 80 caractère à vite fait de la découper en 3 ou 4 lignes, ce qui est particulièrement pénible à relire.
C’est pourquoi je recommande vivement de passer cette limite à 120, 160… voire à 1000 lignes. Le code généré n’en sera que plus facile à relire, pour comprendre ce qui ne va pas.
Utiliser du Java 7 dans Talend Open Studio
L’ensemble des préparatifs étant terminé, il est maintenant possible d’utiliser les classes de Java 7 dans Talend Open Studio :
- dans les différents composants permettant d’écrire du code directement (tJava, tJavaRow, tJavaFlex, etc.).
- en créant soit-même de nouveaux composants.
Afin de vérifier le bon fonctionnement de cette manipulation, un premier composant a été créé : le bcFileProperties. Ce composant dérivé du tFileProperties, ajoute la lecture des droits du fichier ainsi que de son propriétaire. Les sources de ce composant sont comme d’habitude disponibles sur GitHub. D’autres composants utilisant les optimisations offertes par Java 7 devraient suivre de la même manière (dès que j’aurai le temps…).
Exécution du composant bcFileProperties
Sauvegarde automatique de l’historique d’un document
27/09/11
Il est des semaines où on doit troquer son IDE préféré pour des outils bizarres tels que OpenOffice LibreOffice, Microsoft Office, voire pire… Microsoft Project. Or avec ces outils, on a vite fait de perdre plusieurs heures de travail avec une fausse manipulation. Afin de palier à ce problème, j’ai mis à contribution un de mes outils préférés : git. Il n’y a pas de raison que les documents ne soient pas versionnés, au même titre que du code. D’autant plus que le coût de mise en place d’une telle sauvegarde est très faible :
1 2 3 | git init git add mondocument git commit -m 'Première sauvegarde de mon document' |
Diff entre deux versions
En commitant régulièrement son document, on en constitue un historique. Et avec les branches, on peut même le décliner en plusieurs versions. Je n’ai par contre pas réussi à créer de « feature branch » documentaire, la fusion automatique de documents binaires avec git se passant bizarrement assez mal.
L’autre problème avec des documents binaires, c’est qu’ils passent assez mal dans le « diff », ce qui fait perdre à la gestion de configuration une partie de son intérêt. Mais pour ce problème là, il existe une solution. Il suffit d’avoir un outil permettant d’afficher un document un mode texte. Dans le cas du format OpenDocument, on peut par exemple utiliser odt2txt.
Il faut ajouter dans .gitconfig le bloc suivant, pour déclarer le convertisseur associé au format odf :
1 2 | [diff "odf"] textconv=odt2txt |
Enfin, dans le répertoire du dépôt du projet, il faut associé ce convertisseur avec les extensions des fichiers OpenOffice. Ca se passe dans le fichier info/attributes :
1 2 3 | *.odt diff=odf *.ott diff=odf # idem pour les formats ods, ots, odp et otp |
Cette modification effectuée, on récupère la possibilité de calculer le différentiel entre deux commits, et toutes les fonctionnalités associées.
Le seul inconvénient, c’est qu’il faut répéter cette opération pour chaque dépôt de documents. Je n’ai pas trouvé le moyen de définir ces comportements dans la configuration globale de git. Si quelqu’un a une solution, je suis preneur !
Automatisation de la sauvegarde
Afin d’améliorer un peu le processus, il suffit d’un petit script shell qui automatise l’enregistrement du document à intervalles réguliers :
1 2 3 4 5 6 7 8 9 | #!/bin/sh # Intervalle entre deux enregistrements SAVE_PERIOD_IN_SECONDS=120 while : do echo "Autosave : $(date)" git commit -a -m "Autosave $(date)" sleep $SAVE_PERIOD_IN_SECONDS done |
Ce script utilise une des particularités intéressantes de git : si le fichier n’a pas évolué pendant l’intervalle, le commit n’est pas effectué. Ainsi, l’historique des versions du document pourra sauter des enregistrements (si on a oublié d’enregistrer le document entretemps par exemple).
Pour finir, voici donc le script en action :
Sauvegarde automatique de document avec git
Premiers pas sur CloudBees
10/07/11
Mardi dernier se tenait le traditionnel Paris JUG, recevant Patrick Chanezon venu nous parler du Cloud. Au passage, félicitons l’organisation qui est passée de JugEvent à EventBrite, beaucoup plus fiable (et qui m’a permis d’avoir une des dernières places libérées le jour même de la conférence).
Dans la nuit qui a suivi, Olivier et Nicolas ont respectivement publié des excellents comptes-rendus de cette soirée. Merci et félicitations à eux donc :
- Paris JUG « Cloud »
- Patrick Chanezon au Paris JUG, Didier Girard, SFEIR, Création de valeur et compétitivité avec le Cloud, et CloudFoundry présenté par Guillaume Laforge, Soirée Patrick Chanezon
Voici donc, modestement, un petit compte-rendu de tests que j’ai eu l’occasion de faire sur deux des plate-formes dont il était question à cette soirée.
La suite >
Retour sur le BreizhCamp
23/06/11
Vendredi dernier, j’ai eu la chance de pouvoir participer au premier BreizhCamp, organisé entre autres par Nicolas de Loof. Cette journée, agrémentée d’un temps « breton », fût très enrichissante, tant par les conférences elles-mêmes que par les discussions que nous avons pu avoir entre ces sessions.
Une des particularité de cette journée était de ne pas tourner qu’autour de Java, mais aussi d’autres langages (Python, Ruby, .NET). Autre particularité (par rapport à la What’s Next notamment), les thèmes de cette journée étaient moins orienté Cloud, et plus NoSQL.
Voici un petit résumé des conférences qui m’ont le plus intéressé :
99 Scala problems : les 22 premiers
9/06/11
Après quelques articles et tutoriels, ainsi que quelques tests sur les interactions avec Java, j’ai commencé mon apprentissage du Scala par les 99 Scala problems.
Avant de me lancer dans la résolution des problèmes en question, et en application des bonnes pratiques du TDD, j’ai écrit les signatures des méthodes, et les tests associés à ces 22 problèmes. Si vous voulez vous lancer, je vous épargne cette première étape : vous pouvez télécharger directement ce squelette.
Vous pourrez vérifier que les 22 tests échouent. Ces tests sont cependant rudimentaires, et les faire passer au vert ne garantira pas que vous avez la bonne solution (même si c’est encourageant).
D’autres personnes se sont lancées avant moi dans la résolution de ces problèmes. Comme il est toujours intéressant de comparer les différentes approches, en voici quelques unes (en plus des solutions du site original) :
Mettre en place un workflow git
2/06/11
Si vous avez été à une ou deux présentations de git, vous avez sans doute déjà vu ce diagramme (ou un équivalent).
Après avoir un peu pratiqué git, ce genre de workflow devient naturel, et est particulièrement appréciable :
- les fonctionnalités ont chacune leur branche dédiée : la lecture de son historique n’est donc pas gêné par le reste des développements
- les livraisons peuvent être préparées sans empêcher les personnes qui travaillent sur les futures fonctionnalités de partager leur travail
- etc.
Voila pour la théorie : sur le papier, ça laisse absolument rêveur ! Mais dans la pratique, tout ne fonctionne pas aussi bien, surtout au début. Et c’est là que commence mon retour d’expérience sur la mise en place de ce workflow.
Deuxième journée de What’s Next
27/05/11
Aujourd’hui, j’ai réussi à obtenir une connexion WIFI (reste à savoir pour combien de temps…). Je vais donc tenter de résumer cette deuxième journée de conférences en direct.
La journée commence de manière très conviviale, autour d’un café avec Nicolas de Loof, qui nous quittera précipitamment pour aller tester git rerere et mettre à jour sa présentation de ce soir. J’en profite pour faire la publicité des ateliers git attitude qui m’ont appris l’existence et l’utilisation de cette commande !
Keynote de Neal Gafter
Neal Gafter est une des figures emblématiques du langage Java, ayant contribué à son commencement. Il commence par nous présente un historique complet du langage, et des évènements survenus lors de son développement (problème des TCK et du projet Harmony, etc.). Au passage, quelques tests tirés de son livre Java Puzzlers (sur lesquels je me suis fait avoir : j’ai encore quelques révisions à faire…).
Nous passons maintenant à une partie qui m’intéresse : le cloud (encore !), mais à la sauce Microsoft : Azure. La plate-forme de cloud tourne en environnement Windows, mais se veut ouverte à tous les langages de développement.
Avec la plate-forme Azure, on ne s’occupe pas des machines virtuelles : la plate-forme le gère pour nous, et fournit les VMs clés-en-main, en appliquant automatiquement les patchs de sécurité, etc. Le but est de permettre aux développeurs de se concentrer sur les applications. De même, la plupart des briques techniques sont gérées automatiquement : le load-balancing, l’ajout d’une base de données, etc.
Sur ces points, la description de cette plate-forme me rappelle fortement ce que j’ai pu voir de Cloud Foundry.
Apparemment, Azure est Java Ready : SDK Java, support de JDBC4 (et donc des frameworks de persistence comme Hibernate). Il y a également un Starter Kit permettant de configurer un projet Java sur le cloud.
RabbitMQ par Rob Harrop
Pas de WIFI pendant cette présentation, j’écris le compte-rendu à postériori. Rob était absolument impressionnant (je le soupçonne d’être en fait Chuck Norris déguisé) : démonstration live sans aucun « effet démo » sur 4 langages différents (Java, Erlang, Ruby, Python) pour montrer l’inter-opérabilité de la plate-forme. Ca donne vraiment envie de l’essayer !
A suivi une phase de questions-réponses assez pointues sur la scalabilité, la résistance à la panne, les différences d’approche par rapport à d’autres technologies de messagerie, etc.
Pause déjeuner
Tirage au sort de l’iPad 2 : encore perdu… Je ne perds pas espoir d’en gagner un prochainement.
Comme hier, au Mc Donald’s d’en face, mais sans passer par la case sandwichs.
Le découplage de services par Theo Schlossnagle
Un contributeur à presque 20 projets OpenSource, ça force le respect…
Début de conférence sur les chapeaux de roue : on met les pieds dans le plat avec les raisons du choix d’une architecture NoSQL ou Cloud.
Très bonne démonstration du fait qu’on n’a pas besoin de milliers de machines pour scaler, mais de repenser son modèle dans la majorité des cas.
Le découplage d’une application en systèmes élémentaires indépendants donne de la flexibilité, mais est une opération très complexe. Elle nécessite des systèmes de files (ActiveMQ, RabbitMQ, etc.).
Pour bien concevoir un système, on doit faire la part des choses entre ce que l’on veut (un résultat instantané), et ce que l’on peut obtenir (calcul trop long pour permettre un résultat instantané). Dans ce cas, il faut découpler ce calcul dans un système asynchrone.
Conseils pour parvenir à ses fins :
- Programmation défensive (timeouts, points de vérification, etc.)
- Mise en place de monitoring (vitesse de traitement, taille des files d’attente, nombre de connexions concurrentes, etc.)
Si une application doit tomber en erreur, il faut qu’elle tombe en erreur rapidement (timeouts, etc.) !
Résumé final : excellente conférence pleine de très bons conseils d’architecture !
Tirage au sort des gagnants de places VIP pour Rolland Garros
Félicitations Alexandre !
Architecturer l’expérience utilisateur, par Michaël Chaize
Conférence en français (ça mérite d’être souligné).
L’architecture est impactée par l’expérience utilisateur qu’on veut donner à ses clients
Flex est devenu Open Source en 2007, et peut être codé en ActionScript 3 ou en MXML. Il génère ensuite un fichier Flash. Flex est utilisé à 90% pour des applications internes [Mode mauvaise langue]par honte de les exposer au public[/Mode mauvaise langue].
Depuis 2007, la fondation OpenScreen a permis de travailler avec les acteurs du marché mobile pour optimiser le player Flash sur les terminaux, à l’exception d’un acteur du marché qui a refusé. On se demande bien lequel…
Flex 4.5 semble effectivement assez adapté au développement mobile :
- prise en compte des différentes résolutions d’écran
- développement unique pour Android 2.2 et 2.3, Blackberry Playbook, et les tablettes Apple (moyennant une conversion de code)
Présentation intéressante, et qui donne envie. Mais malheureusement, je n’ai pas vraiment le temps en ce moment de faire du développement mobile (trop d’autres choses dans ma todo-list d’études).
Conférence Akka par Jonas Bonér (CTO de TypeSafe)
Il est difficile de construire des systèmes gérant correctement la concurrence et la scalabilité. Akka (et Scala) a été créé pour tenter de proposer des solutions à cette problématique.
Les trois briques principales de Akka :
- Tolérance à la panne (supervision)
- Scalabilité (système des Actors et clustering)
- Concurrence (Actors, STM, Agents, Dataflow)
Plus tout un ensemble de modules add-on (JPA, etc.)
Qu’est ce qu’un acteur ? un acteur ressemble à un objet : c’est un état, et un comportement. Un acteur est indépendant, isolé, et ne partage pas son état : il n’y a donc pas de mécanisme de lock à implémenter pour gérer la concurrence. Les acteurs communiquent par un système de messages. Les acteurs sont indépendants des threads (à ceci près qu’un acteur est MonoThread) : la seule limitation du nombre d’acteurs est la mémoire.
L’envoi d’un message à un acteur n’attend aucun retour. Le traitement du message est asynchrone. On peut cependant attendre un résultat futur (associé à un timeout) :
1 2 3 4 5 | actor ! message val future = actor !!! message future.await val result = future.result |
Le comportement des acteurs est complètement déterministe.
Travailler avec des acteurs distribués sur plusieurs machines est presque transparent pour le code. Le runtime fournit un mécanisme de clustering (gérant le failover) pour les acteurs, avec plusieurs stratégies de choix du serveur d’exécution (CPU utilisé, mémoire utilisée, etc.).
Elastic Search, par Shay Banon
Présentation très originale, qui s’est déroulée sans aucun slide, mais juste avec une console, et l’outil cURL, qui servait à attaquer l’API REST d’Elastic Search. Pour résumer, Elastic Search est un outil construit autour de Lucene avec les grandes fonctionnalités suivantes :
- Fonctionnement en cluster (avec une gestion très simple de l’ajout d’un serveur au cluster)
- API d’accès entièrement construite en REST, avec des données JSON
L’ensemble de la présentation consistait à nous montrer des fonctionnalités de plus en plus complexes :
- utilisation d’un noeud, puis d’un cluster de noeuds
- création d’index simples, puis complexes (en imposant un format de mapping)
- recherches simples, puis complexes (filtrage, etc.)
Je n’ai encore jamais eu l’occasion de travailler sur une problématique d’indexation de documents (à l’exception d’une mise en place d’une GED Alfresco, mais où l’indexation est déjà gérée). Mais si ça devait arriver, l’API d’Elastic Search en fait un produit qui a l’air particulièrement intéressant.
L’avenir de l’intégration continue par Kohsuke Kawaguchi
La présentation commence par un bilan : la puissance des machines de développement augmente de manière exponentielle. Or, les compétences des développeurs ne suivent pas cette même évolution. Par rapport à la puissance des machines, le développeur est donc une denrée précieuse : il faut donc veiller à ce que l’outillage exploite eu mieux cette puissance machine pour permettre aux développeurs de gagner du temps.
Pour cela, plusieurs pistes :
- utiliser au mieux les gestionnaires de configuration distribués (git par exemple)
- faire exécuter les tests sur le serveur d’intégration continue au lieu de les exécuter sur les machines des développeurs
- etc.
Epilogue
Voilà deux journées très intéressantes, sans aucun bémol majeur : c’est donc une grande réussite pour Zenika (dont je remercie toute l’équipe au passage), qui nous a d’ors et déjà invités à revenir l’année prochaine.
La soirée s’est achevée pour moi par plus d’une heure de discussions techniques passionnées sur les quais du métro avec Alexandre (rencontré hier par l’intermédiaire d’Antoine).
Félicitation à Nicolas qui a le courage de rempiler pour la soirée Jenkins… J’aurai une pensée émue pour sa présentation de ce soir (et j’en suis quitte pour un prochain article sur git, sauf si Sébastien me devance).
[Mise à jour : quelques autres compte-rendus]
- http://hypedrivendev.wordpress.com/2011/05/28/whats-next/
- http://blog.loof.fr/2011/05/merci-zenika.html
- http://www.lemondeinformatique.fr/actualites/lire-what-s-next-le-monde-java-pense-a-l-avenir-sans-oracle-33817.html
- http://www.touilleur-express.fr/2011/05/31/whats-next-2eme-journee-neal-gafters-keynote/
- http://pro.01net.com/editorial/533707/what-s-next-les-retrouvailles-de-la-communaute-java/
[Et ça continue…]
