new Blog( perso );

vive Maven.

Arnaud et moi avons aujourd'hui reçu ce courrier :


Bon bref, cette expérience d'édition a été instructive :

• le travail sous Word avec un template barbare est une horreur
• le processus de relecture et de PAO est une horreur
• ça prend un temps fou
• ça rapport très peu par rapport aux heures consacrées

Nous avons donc décidé de diffuser le contenu librement, après conversion au format AsciiDoc. La conversion étant loin d'être parfaire il reste pas mal de couacs, en plus de ceux présents dans le texte lui même, mais globalement, vous pouvez à présent nous lire de manière totalement gratuite et libre (license CC BY-SA).

https://github.com/ndeloof/apache-maven-book

Si vous voulez nous aider à faire vivre ce livre, vos contributions sont les bienvenues. Sinon il finira de mourir tranquillement en attendant que Maven 4.0 voie le jour. Et si vous regrettez l'époque où vous pouviez nous rémunérer pour ce travail (1,23€ par vente, imposable), nous sommes à votre disposition pour une bière ;-)

OAuth

SecureSocial

Olivier Croisier a publié un article sur ses expérimentations avec Java 8, plus précisément l'introduction des default methods dans les interfaces. Cette nouveauté dans la syntaxe Java a été introduite initialement pour permettre à l'API Collections d'évoluer sans nécessiter à tout un écosystème de librairie de produire de nouvelles versions mises à jour pour Java 8, autrement dit d'attendre 2020 pour que ce soit utilisable concrètement.

Comme l'a très bien analysé Olivier, ces default methods apportent à Java le concept de trait très utilisé en Scala. La tournure fonctionnelle que Java 8 va permettre de faire prendre au langage est un pas majeur, bien plus important amha que l'introduction des génériques en Java 5.

Pour rebondir sur le problème du diamant exposé par Olivier, mon interrogation sur les conflits de méthodes introduites pas les default methods se pose un peu différemment :

nous avons donc une classe Clazz qui implémente deux interfaces Foo et Bar.

1 public interface Foo {
2     public default void helloWorld() {
3         System.out.println("Hello World");}
4 }

1 public interface Bar {
2 }

1 public class Clazz implements Foo, Bar {
2 
3     public static void main(String args[]) throws Exception {
4         new Main().helloWorld();
5     }
6 }

Disons que la première déclare une default method helloworld(). Si Bar définit lui aussi la même default method le compilateur détecte le conflit. Supposons cependant que dans un premier temps Bar n'a pas de telle méthode et que nous compilons notre projet. Nous ajoutons alors a Bar la default method conflictuelle, et re-compilons la classe Bar (et elle seule).

Question : est-ce que notre programme continue de fonctionner comme avant - en gros, est-ce que le bytecode produit fait directement référence à la méthode Foo.helloworld(). Ce qui veut dire que nous ne pouvons plus le re-compiler depuis les sources. Une bonne raison de configurer votre intégration continue avec un "mvn clean install" :)

Je vous laisse essayer par vous même pour avoir la réponse :-D

Java 8 apporte des changements profonds, et expérimenter est la seule façon concrète de comprendre leur impact. Voir ce que fait Yan sur https://github.com/ybonnel/Jdk8Experiments par exemple, je vous encourage à en faire autant.

Je suis en ce moment (exactement en ce moment, dans le TGV Rennes-Paris, connecté en tethering) en train de lire le livre "Functional Programming for Java Developers". Si le livre n'est pas tout juste sorti des presses et ne parle donc qu'à peine de Java 8, et avec une syntaxe obsolète, les concepts fondamentaux sont bien présents et très utiles.


J'entend beaucoup de monde me dire qu'ils n'utiliseront pas Java 8 avant une décennie, bloqués par les contraintes client d'un runtime websphere 6. C'est évidement une réalité, et clairement vous n'aurez pas de traits dans vos applications. Ca n'empêche pas de commence à appréhender les concepts fonctionnels, qui sont un excellent complément à l'approche objet.

En dehors de l'approche fonctionnel que va (mieux) permettre Java 8, ces changements annoncent aussi des bouleversements dans l'écosystème des librairies et frameworks. Exemple type, de nombres frameworks définissent des classes abstraites, que votre code doit étendre. Un jeu d'interface serait plus propre, mais alors impossible de faire évoluer les API. Jenkins par exemple comporte une quantité phénoménale de classes abstraites pour cette raison.

Autre approche si on aime pas les classes abstraites, faire à la façon d'Eclipse, en définissant des interfaces HelloWorld1, HelloWorld2, HelloWorld3, et en testant au runtime quelle interface est implémentée, bref une solution pire que le mal lui même.

Bref, tous les frameworks pre-java 8 - en dehors d'Eclipse - se basent sur des classes abstraites, et pourrissent nos arbres d'héritage. Une opportunité apparaît donc avec Java 8 pour une nouvelle génération de frameworks, basés sur des traits. Le même genre de changement qui a laissé commons-collections sur le carreau avec l'arrivée des génériques et une mise à niveau jamais aboutie, qui a laissé la place à Guava et quelques autres.

Donc, oui, votre client a du Java 5 en production. Oui, c'est une version "End of Life" mais il s'en fout, et vous n'y pouvez rien. Et pourtant, si vous ne voulez pas passer pour un développeur avec des faux airs de Cobol dans quelques années, il est temps pour vous de regarder ce qu'apporte Java 8, d'expérimenter, de découvrir les bénéfices et les concepts de la programmation fonctionnelle, et de pleurer en revenant à votre code sans lambdas ;)

Même si on atteint pas la prolifération de S*UG (Scala | Scrum | Spring | ... | user-groups) qu'offre la capitale, Rennes n'est pas en reste d'activité communautaire. Il y a bien sur le BreizhJUG, devenu au fil du temps une institution locale, mais aussi de plus petit groupes plein de bonnes idées, comme par exemple Rennes Devops.

Avec la possible venue d'OVH dans la capitale Bretonne, le groupe veut démontrer son dynamisme, et organise le 25 janvier un BootCamp DevOps à la Cantine Numérique Rennaise.


Pour ma part, j'ai proposé d'y parler un peu de déploiement continu avec Jenkins, mais surtout de Docker. Donc si vous voulez passer un bon moment et élargir un peu vos horizon d'architecte Java EE, bloquez votre agenda !

Interview de Nicolas Ledez, initiateur du BootCamp :

À l'origine, c'était une idée de Frédéric Alix (http://blog.fredalix.com). Qui pour différentes raisons n'a pas pu y donner suite. Et finalement, pour les développeurs, il y a l'excellent Breizhcamp, mais rien pour les ops - donc… Et j'ai aussi un petit coté maso :p

Hou là !!! Oui beaucoup. Je vais démarrer des cours pour débutant de développement Web dans le cadre du http://labfab.fr/ + Breizhcamp, Devcamp, et plein d'autre trucs  ok, rendez vous le 25 pour te voir à l'oeuvre

infos et inscriptions : http://rennesdevops.fr/bootcamp-rennes-devops/

Devoxx France a ouvert son Call for Paper début décembre, et se pose pour moi la question de quoi proposer.

L'an dernier j'ai mis tout ce que j'avais en magasin, au risque de passer pour un spam-bot. J'ai constaté que les sujets "cloud" ou "continuous delivery" qui me sont chers ne font pas rêver le comité de sélection - ou alors je ne suis pas bon vendeur.

Bref, suivant une suggestion de Nico Martignole, je lance un Google Moderator :

Quel sujet voudriez-vous me voir présenter à Devoxx 2014

A vous de jouer !

J'enchaine les coups de stress ces temps ci

la semaine dernière, en plein pendant un week-end dans la famille, mon Galaxy S3 me fait le coup de la "mort subite". J'ai retiré 25 fois la batterie, épluché les forums ... en vain.


Bon, allez, y'a pas mort d'homme, et en plus voilà un prétexte tout trouvé pour commander le Nexus 5.

Lundi, allez hop soyons fou je migre mon MacBook sous Maverick. "upgrade gratuit" de la part d'Apple, j'aurais de me méfier. Aucun changement notable.

petite parenthèse : j'essaye "plan" vite fait, dont j'ai entendu tant de mal, et la photo aérienne de mon chez-moi est plus à jour et de bien meilleure qualité que google maps. Donc pour un gars qui vit dans sa campagne comme moi c'est plutôt positif ;)




Après l'ugrade, mon code d'accès à https (je bosse sur le plugin git jenkins) se met à planter - j'apprends qu'il faut réinstaller le java 6 Apple.

Bon, allez, y'a pas mort d'homme, c'est pas méchant ça m'a "juste" fait perdre une journée de taf, c'est pas comme si j'était grave à la bourre juste avant Devoxx.
Sinon R.A.S, ça reste un OSX quasiment tout pareil - ça m'aurait fait mal de payer un upgrade pour ça - jusqu'à ce que je décide de rebooter (quand git n'arrive plus à résoudre "github.com", c'est pas bon), après tout un reboot une fois par semestre ça peut pas faire de mal.

Titre tapageur - serais-je un peu provocateur ?


Non, je ne vais pas faire l'apologie de Clearcase, je suis très content de Git en tant que développeur et je n'ai absolument pas l'intention de changer, même pour un autre DVCS.

Par contre, je suis mainteneur du plugin Git pour jenkins. J'ai hérité de ce plugin sans trop savoir comment, au départ en backportant des correctifs utilisés par CloudBees puis rapidement faute d'une mainteneur en place. Et j'ai rapidement compris pourquoi : ce plugin est un amalgame de pull-requests en tout genre.

Le problème de la pull-request, c'est

1. quand on crée un patch, et donc une pull-request, on essaie de faire minimaliste. On ne fait pas un gros refactoring juste pour la beauté du geste. On va donc ajouter un "if (foo) { ... } else" dans le code existant. 25 pull requests plus tard la méthode fait 400 lignes et est incompréhensible.
2. si c'est un mécanisme de revue de code formidable, en opensource la pull-request a ce désagréable effet de bord de permettre à un contributeur de "balancer" du code par dessus le mur, sans s'impliquer forcément dans le projet. D'où l'absence de continuté sur ce plugin.

I recently discovered project to start a JSR for Configuration Management. Mike Keith introduced this project at JavaOne, you can download slides for his presentation here. I wasn't aware so didn't attend the live talk, but reviewing the slides I have few comments.

Proposal (afaik)

Scope for such a JSR is difficult to establish. If you want to embrace the existing tools, there is overlap with generic platform provisioning. I don't think this is a good idea to consider this until there's a reasonable consensus on application-level configuration management. Looks like this is also the diagnostic for this JSR.

The current state for JavaEE configuration is "JNDI" : if you need to inject some resources / parameter to an application, you have to provide some container-specific xml file in your WAR archive. This suppose Ops will unzip the WAR, edit xml to put production resource binding and credentials, then re-archive and deploy using container-specific commands. Nobody never did this. So this is a great idea to review this and provide something to better match actual practices and tools.

Also have to consider the DevOps impact on development/deployment practices.

Contract for configuration management is also complex to establish. Reviewing slides, the proposal seems to be to package application configuration in a CAR (configuration archive).


I think this is a very bad idea. For the same reason Ops don't unzip WAR to edit xml files, they won't do this to create CAR files. Ops tools and practices are based on scriptable solutions from system shell. I don't think we will see JavaEE apps packaged as RPM/DEB system packages, at least because Java is supposed to "run everywhere", not just on Linux distros. But a configuration management JSR must primarily focus on Ops practices, not on JavaEE developers. JSR use to define Java based API, I think this specific JSR must NOT use Java as primary language. My main concern with a java-based approach is that this will result in a new java.util.prefs.Preferences nobody is using.

My vision

I'd prefer the JSR to define a REST API application container (or platform as a service) have to expose to allow defining the configuration for an application. REST is neutral, well supported both from Java tooling and base script shell (using curl).

So, you can imagine a REST endpoint on your application server that let you define an "application" (unique ID) and bind server resources / configuration parameters to this application. Application server is responsible to implement actual persistence.

Deploying an application would then be :

1. create the application with unique ID
2. set application configuration 
• resource bindings (JDBC DataSource, JavaMail session, JMS queues, etc)
• simple parameters
• structured parameters (? - see later)
3. deploy WAR/EAR for application ID

Application configuration has to be persistent : it will survive application restart and redeployment, as long as application unique ID is unchanged. It's also idempotent: binding same resource twice don't result in a duplicated resource. This is a requirement for infrastructure automation tools (like Chef/Puppet) to work in this context.

Without any surprise, you probably notice how this proposal mimic CloudBees configuration management. We also support cloudbees-web.xml and some of us like it, but I consider this legacy. Using SDK to bind a Database to my application, whatever application server I'm using - Tomcat, JBoss, Glassfish, Jetty - and getting it injected as a JNDI DataSource is awesome.


How does application access configuration ?

Based on slides, JSR proposal defines a new API for application code to access configuration. So, you'll have to wait for all frameworks to be updated to benefit this API :-/

To workaround design issue for JavaEE to miss a configuration API, most framework rely on placeholders, the common denominator being support for system properties. I never have seen a JavaEE application to use String declared in JNDI, but I not a bunch of apps to get runtime settings from system properties. For adoption of a configuration management JSR, and immediate support on most frameworks, system properties must be considered as first-class citizens in configuration land.

Injecting a simple parameter in an application should result in getting the equivalent system property set. With system properties, you already can manage a bunch of use-cases. I'm not sure there's actual need for structured parameters. This could be addressed by JAXB / JSONB data binding anyway.

Conclusion

I'd be very happy to contribute this JSR. I've been looking for an "incubator" page for it but can't find this on jcp.org. I'm not sure then how expert group is established, but if I can join I'd be very happy to compare my point of view with others and help as much as possible to make this JSR a useful one.

1. Cloud != DataCenter

• ressources (quasi) illimitées, disponibles à la demande - ce qui ne veut pas dire sans quotas ni restrictions,
• accès direct par API, sans passage par la case "formulaire bleu à envoyer à l'admin signé par le CdP",
• mutualisation des ressources et facturation à l'usage,
• délégation complète de la maintenance et du support.

J'ai enfin trouvé le temps de publier la première release du plugin Jenkins "build graph view". Ce plugin permet de visualiser de manière graphique les builds impliqués par un build initial. La mise en place d'un workflow complexe sur Jenkins implique en effet souvent de distribuer le travail dans plusieurs jobs, liés les uns aux autre par des relations "upstream-downstream" orchestrées par une série de plugins.

Le plugin build-pipeline existe déjà sur ce créneau et est très populaire, mais se limite à des exécutions statiques, comprenez que les jobs impliqués sont toujours les mêmes à chaque exécution.
Dans de nombreux cas, cet ordre peut évoluer, certains jobs étant lancés de manière conditionnelle, et on peut aboutir à des chemins d'exécution complètement différents. Build Graph View plugin aborde donc le problème en proposant un graphe dédié à chaque exécution :
Ce n'est "qu'une" 1.0, ce qui signifie que de nombreux liens entre builds ne sont pas supportés à ce stade (plugin join, copy-artifact, promoted builds...). Cependant elle couvre déjà pas mal de cas, et le plugin est facilement extensible, contributions are welcome ;)


Le code de ce plugin est issue d'un autre de mes plugin, le build-flow. Ayant enfin pu finaliser l'extraction dans un plugin dédié, en ajouté les bouts de code qui assurent la complémentarité entre ces deux plugins, j'enchaine avec la release 0.10 de celui-ci. Build Flow va dans le même sens, en constatant que définir un workflow complexe dans Jenkins est bien compliqué, à base de plugins en tout genre pour gérer le passage de paramètres, l'exécution concurrente, etc. L'orchestration des jobs est donc confiée à un DSL, chargé de lancer les jobs. On a ainsi une séparation entre les tâches élémentaires et le wrokflow de plus haut niveau, sans que ce dernier soit dispatché un peu partout et difficile à gérer.

Rien de fondamentalement nouveau dans cette release, désolé pour ceux qui espéraient de grand changements, et surtout pour ceux qui espéraient que cette version soit une 1.0, car on en est pas là ... Ce qui manque au build flow ?

• Un sandboxing du DSL groovy. En effet, les droits "RUN_SCRIPT" (administrateur) sont nécessaire pour éditer le DSL, sans quoi un utilisateur standard pourrait accéder aux API Jenkins et à la JVM sans contrôle ... ce qui rend le plugin assez inutilisable dans un contexte d'entreprise avec un Jenkins mutualisé. A part un SecurityManager bien trempé je ne vois pas de solution viable pour le moment
  =>  JENKINS-16980.

• L'exécution asynchrone du DSL. Actuellement, le DSL est lancé comme un simple script, et de ce fait ne peut être interrompu ou relancé. Groovy ne propose pas de "Continuations" qui permettraient de capturer la call-stack pour la relance plus tard. La piste que j'envisage pour le moment est de rendre le script "rejouable" à volonté, les étapes déjà exécutées se transformant alors en NOP. Autre solution pas triviale, utiliser les AST Transformation pour convertir le script impératif dans un format CPS ... Si vous avez la super solution idée du siècle, je suis preneur.
  => JENKINS-19118

• notre reconnaissance !
• une bonne bière à l'anniversaire du JUG pour le gagant
• les noms de chaque contributeur sur le site, par ordre de mérite

Le BreizhCamp 2013 a été un événement magnifique, et je remercie chaleureusement l'équipe qui m'a accompagnée dans ce challenge et a relevé tous les défis, par ordre psuedo-aléatoire :

Nicolas Ledez, Laurent Huet, Guillaume Collic, Yan Bonnel, Sébastien Brousse, Michel David, Horacio Gonzalez, Sylvain Guernion, Alex Thomazo, Julien Coste

ansi que Quang Hung et Jean-François Garreau qui nous ont accompagnés côté sponsors.

Le questionnaire que nous avons diffusé donne des résultats intéressants sur vos attentes :
Premier point, cette troisième édition vous a plu. C'est déjà un très bon point, mais nous ne sommes pas encore au 100% de satisfaction, aussi nous allons chercher à faire encore mieux.



Les nombreuses sessions "hands-on" de la première journée on été appréciées, et d'après vos retours il n'en faut pas nécessairement plus - ou en tout cas être rigoureux sur la sélection pour ne proposer que des sujets bien préparés.



La diversité des sujets a été appréciée, même si elle est encore améliorable. Sans surprise, le call for paper nous a amené essentiellement des sujets Java et HTML5/JavaScript, aucun sujet PHP, un seul sur Python, pas grand chose dans le monde Microsoft. Il faut que nous travaillions avec les communautés pour attirer ces speakers et démontrer l'intérêt de voir "ce qui se fait ailleurs".

... car vous jouez le jeu de sortir de votre zone de confort pour aller voir ce qui se passe dans le pré d'à côté, et c'est le but de la conférence donc j'en suis ravi.


Votre réaction fàce aux quelques sujets hardware est intéressante. Une moitié à globalement apprécié sans plus, un quart sont enthousiastes, l'autre quart n'en voient pas l'intérêt. Il y a donc clairement deux populations ici, une qui aime les talks où l'informatique rencontre le monde physique - dans 10 à 20 ans, le moindre objet sera connecté et communiquant - et une qui est sans doute plus pragmatique sur ses pratiques professionnelle et ne vois pas d'intérêt dans une raspberry pi autre que le côté gadget - je fais des applis de gestion, alors un minitel je ne vois pas bien l'intérêt.


Nos sponsors cette année ont été très présents, et leur implication pour animer la conférence a été appréciée. Tant mieux, car ils ne sont pas que nos financiers dans cette aventure, ils sont nos partenaires et il est important qu'ils prennent part à l'événement et que les participants y trouvent leur compte.



Notre buffet a été apprécié pour sa qualité, mais les quantités on posé problème. Avec les quickies sur la pause déjeuner, et l'enthousiasme des premiers arrivés à gouter à tout, certains on du se contenter d'un repas léger. Il est clair que nous corrigerons le tir sur les prochaines éditions.


L'absence de WiFi pour les participants, lié aux contraintes du campus universitaire, est de plus en plus contraignante pour vous. Malgré plusieurs mois de préparation, les solutions de replis mises en place dans deux salles pendant les hands-on n'ont couvert qu'une partie du besoin. Par ailleurs, nous devrons à l'avenir être vigilant pour les propositions de Hands-on, en insistant auprès de nos speakers pour expliciter les pré-requis dans la présentation de leur talk et toujours prévoir un "plan B" en cas de défaillance de l'infrastructure.

Enfin, 50% d'entre vous est prêt à revenir de manière inconditionnelle, 90% une fois le programme publié, voici des chiffres qui nous font honneur. 50% font d'ailleurs déjà du lobbying actif pour motiver leur collègues - si par la même occasion vous pensez pouvoir transmettre notre dossier de sponsoring 2014 contactez-nous - et si on considère que vous connaissez presque tous une personne qui n'a pas pu participer il semble évident que nous devons augmenter notre capacité d'accueil.



Quand à vos nombreuses suggestions ... laissez nous un peu de temps pour les éplucher :P

Merci en tout cas pour tous vos messages d'encouragement, et rendez-vous après l'été pour la rentrée du BreizhJUG, et l'inauguration du GDG-Rennes !

def selection( format: String, talks: List[talk] ) : List[talk] = 

        check(talks). // relecture des propositions

        sort( talk => talk.note ). // tri par note

        filter( talk => agree )