Maven au pays des proxys

15/01/12

Posté par Benoît Courtine dans Java

Aucun commentaire

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 agile au 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.

, ,
Ajout d'un JDK dans Talend Open Studio

Utiliser Java 7 dans Talend Open Studio

31/10/11

Posté par Benoît Courtine dans Talend

Aucun commentaire

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

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

Exécution du composant bcFileProperties

,
Sauvegarde automatique de document avec git

Sauvegarde automatique de l’historique d’un document

27/09/11

Posté par Benoît Courtine dans Systèmes d'information

1 commentaire

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

Sauvegarde automatique de document avec git

,
Logo CloudBees

Premiers pas sur CloudBees

10/07/11

Posté par Benoît Courtine dans Systèmes d'information

4 commentaires

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 :

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 >

, , , ,
Quatrième (voire cinquième) mi-temps

Retour sur le BreizhCamp

23/06/11

Posté par Benoît Courtine dans Divers

1 commentaire

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é :

La suite >

, , , ,

99 Scala problems : les 22 premiers

9/06/11

Posté par Benoît Courtine dans Java

1 commentaire

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) :

La suite >

, ,
Workflow Subversion utilisé dans Git

Mettre en place un workflow git

2/06/11

Posté par Benoît Courtine dans Systèmes d'information

4 commentaires

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.

La suite >

, , , ,

Deuxième journée de What’s Next

27/05/11

Posté par Benoît Courtine dans Java

Aucun commentaire

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]

[Et ça continue…]

, ,

Première journée à la What’s Next

26/05/11

Posté par Benoît Courtine dans Java

3 commentaires

Je vais certainement manquer de temps pour résumer l’ensemble de cette journée… d’autant plus qu’on repart dès demain pour une deuxième journée de conférences toute aussi intéressante que la première.

Une logistique perfectible

Commençons par le sujet qui fâche… la logistique ! A la décharge de Zenika, c’est la première édition de la What’s Next. Et gérer la logistique pour une conférence de plus de 600 participants, ce n’est pas une mince affaire. Voici donc quelques points perfectibles :

  • Le Grand Rex n’a visiblement pas l’habitude de recevoir en même temps 500 geeks, tous équipés de leur {smartphone/tablette/ ordinateur portable} (rayer les mentions inutiles). Les 3 réseaux WIFI disponibles ont rapidement été saturés, et n’attribuaient plus d’adresse IP. Heureusement qu’il restait la 3G d’urgence pour couvrir l’évènement via Twitter (le hashtag officiel wsnparis ayant bien servi).
  • Un seul point de ravitaillement en café pour les mêmes 500 geeks, c’est l’embouteillage assuré à chaque pause (encore qu’il faille relativiser : la distribution restait suffisamment fluide, et que j’ai toujours pu avoir mon café).
  • Le déjeuner a convaincu une bonne partie des participants de se retrouver au Mc Donald’s d’en face. Cependant, vu le rapport entre le prix d’entrée et la qualité des conférenciers présents, je ne regrette pas le déjeuner un peu léger. J’aime autant que la conférence reste à prix abordable, quitte à devoir sacrifier sur la nourriture.

Le choix du Grand Rex a pourtant un certains nombres d’avantages indéniables :

  • bien placé, au centre de Paris
  • des sièges bien plus confortables que dans la majorité des salles de conférences

Une ambiance géniale et des rencontres très sympatiques

Comme d’habitude, la journée a été très riche en rencontres. Outre les personnes déjà croisées au Paris JUG (ou autres évènements), j’ai pu faire la connaissance aujourd’hui de David Gageot, Nicolas de Loof, Arnaud Héritier, Florian Boulay, ainsi qu’un bon nombre d’autres personnes…

L’ambiance générale de l’évènement était très agréable : très détendue, très geek (sur l’ensemble des participants, on n’a pu dénombrer que quelques cravates). Sur ce sujet, la palme revient d’ailleurs certainement à Jevgeni Kabanov.

Enfin, la fin de journée sur une discussion autour d’une bière était une super-idée pour permettre un debriefing et des débats passionnés dans une bonne ambiance, même si j’ai dû m’absenter assez rapidement, étant attendu.

De très bonnes conférences

Les conférences étaient très bonnes. Parmi celles-ci, j’ai particulièrement apprécié :

  • La keynote d’Adrian Colyer, où il était question surtout question de cloud, de cloud… et de cloud ! Cette conférence m’a donné envie de me repencher sur Cloud Foundry, après quelques premiers tests. Au passage, on notera l’apparition d’un nouveau buzzword qui devrait faire fureur dans les prochaines : le microcloud (j’aurai peut-être l’occasion de revenir sur ce concept dans un prochain article).
  • La présentation du projet Eclipse Orion, par Boris Bokowski. Elle ne m’a pas convaincu d’abandonner IntelliJ IDEA, mais la démonstration des possibilités d’édition était impressionnante : on ne se croirait pas dans une application web ! Parmi mes appréhension, je me pose en particulier la question suivante : l’IDE web est-il résistant à la perte de la connexion réseau et permet-il de travailler offline ?
  • La présentation de Clojure par Howard Lewis Ship était intéressante : elle rappelait bien les différents paradigmes de la programmation fonctionnelle. Cependant, le langage lui-même ne m’a pas du tout convaincu : les exemples de code étaient particulièrement difficiles à relire, et me rappelaient la syntaxe sur-parenthésée du LISP. Sur les langages fonctionnels, je vais donc certainement continuer de faire l’impasse sur Clojure, et poursuivre ma découverte de Scala.
  • La présentation de Jevgeni Kabanov sur la gestion de la mémoire en Java était passionnante. En particulier, la modélisation du CPU et de la gestion mémoire par du code Java était impressionnante ! En résumé, un excellent cours de culture générale sur la gestion de la mémoire en Java. Pour revoir cette conférence (éventuellement au ralenti), c’est dans l’ordre ici, ici, et ici.
  • Enfin, la présentation des Web Sockets parBrad Drysdale m’a là encore donné envie d’étudier cette API de plus près. Par chance, je me souviens avoir lu rapidement un article parlant des Web Sockets et de Play Framework.

Après cette conférence, je sens que je vais avoir un programme d’étude chargé ces prochains week-ends… Vivement demain pour la suite !

[Mise à jour] Pour un résumé beaucoup plus détaillé de cette première journée, conférence par conférence (et avec des photos), foncez chez Nicolas.

, ,

Premiers pas en Scala

24/05/11

Posté par Benoît Courtine dans Java

4 commentaires

Cela fait maintenant pas mal de temps que j’entends parler de Scala, mais je n’avais jamais pris le temps m’y attarder. Il y a maintenant deux semaines, l’annonce du lancement de Typesafe (on pourra lire l’article de Nicolas pour plus d’informations) m’a donné envie de regarder de plus près ce langage.

En attendant mon prochain passage par la FNAC pour trouver un bon livre sur la question, j’ai été glaner quelques informations pour débuter :

J’ai eu la chance d’avoir des cours de Caml Light en prépa et de Lisp en école d’ingénieurs : la programmation fonctionnelle ne m’est donc pas inconnue, ce qui m’a grandement facilité l’entrée en matière (même si j’ai rapidement dû me mettre à niveau avec les Case Class et autres concepts que je n’avais encore jamais rencontré).

Les cours de prépa que j’ai pu avoir sur la question étaient excellents. Même s’ils concernent le langage Caml, ils fournissent des exemples originaux dans lesquels la programmation fonctionnelle permet de s’en sortir bien plus facilement qu’en programmation procédurale. Je propose donc aux curieux d’aller les consulter sur le site de notre enseignant.
La suite >

, ,
12345»10...Fin »