Devoxx Fr 2014, en attendant Parleys

Par Aude Amarrurtu et Betty Moreau

NF : L'équipe des Brown Bag Lunch RH nous a présenté leurs idées et leurs valeurs. L'open source semble avoir déteint sur cette équipe. Elles ont présenté des pistes pour que les RHs aident le consultant à développer son savoir-faire et d'autres pistes pour que les consultants reprennent leur carrière en main. En faisant des raccourcis, une ressource semble interchangeable, alors qu'un individu qui s'exprime par des blogs, des présentations dans les communautés, etc. est connu et contacté pour son savoir-faire.

RLR : La vision de notre métier à travers le prisme de deux RH 2.0 qui ne veulent pas limiter leur métier à celui de recruteur et rédacteur de fiche de paie, mais surtout d'accompagner les ingénieurs dans leur carrière. Pour elles, leur rôle est de nous aider à prendre en main notre carrière, à faire connaître notre savoir faire sous la forme de "personnal branding", les SS2I doivent se transformer en SS3I et tout le monde y gagnera car au final le développeur expérimenté pourra justifier sa facturation supérieure à celle d'un junior vendu comme un vulgaire bout de viande par une SS2I classique.

Un petit bémol cependant, la présentation s'éloigne de son sujet en cassant du sucre sur le droit du travail et en idéalisant le fait de devenir indépendant. Et, à mon sens, si le rôle de la SS2I est de vendre de la flexibilité à ses clients, c'est aussi d'apporter de la sécurité à ses employés et de leur épargner les tâches administratives et commerciales pour que nous puissions nous concentrer sur notre métier. Et puis qui sera là pour nous bichonner si nous devenons freelance ?

Le bon testeur il teste.... et le mauvais testeur aussi....

Par Agnès Crepet et Guillaume Ehret

NF : Cette conférence est un tools in action dont vous êtes l'outil principal. Ils y présentent quelques bonnes pratiques et quelques bons outils utiles aux tests. Ça se regarde une fois en notant les quelques bonnes idées qu'on a loupé de notre côté (JunitParam pour ma part qui permet de lancer la même méthode de test sur des jeux de données différents).

33 things you want to do better

Par Tom Bujok

NF : Tom Bujok est un Suisse qui aime les librairies qui lui simplifient la vie. Dans sa vision : on constate une gène dans notre code, et on cherche une solution par une pratique ou une librairie. Lorsque l'on s'est entraîné au nouvel usage, on peut alors le mettre en pratique sur nos projets professionnels et ainsi remplacer une mauvaise habitude par une meilleure.

Développer en mode Kick-Ass

Par Samuel le Berrigaud

RLR : L'orateur présente les bonnes pratiques mises en places chez Atlassian pour sortir des logiciels "qui déchirent" en ayant des développeurs aux quatre coins du monde. Si il ne se gêne pas pour casser un peu de sucre sur l'Agilité, il n'en fait pas trop et reste bien constructif : il n'y a pas besoin d'une méthode ni de gourou pour faire du bon travail, il faut surtout en avoir envie.

Pour cela ils se sont attachés à rapprocher au maximum le développeur du testeur et du designer en échangeant leur rôle de temps en temps (créer des full stack développeurs ?) mais aussi en responsabilisant tout le monde sur la qualité du produit fini mais aussi à faciliter la vie de celui-ci en lui permettant d'aménager son lieu et son temps de travail comme il l'entend, en rendant plus fluides les développements en branche et les code reviews, en automatisant l'intégration continue, en raccourcissant les tests, en éliminant les faux positifs, en privilégiant les modes de communication asynchrones (chat rooms).

Pour conclure, développer en mode kick-ass c'est :

• Automatise-toi toi-même, marre des cordonniers mal chaussées.
• Partage tes échecs, c'est en se trompant qu'on apprend.
• Développe une culture, la qualité c'est l'affaire de tous.

Pourquoi vous devriez essayer sérieusement les Object Calisthenics

Par Guillaume Duquesnay

RLR : Guillaume lève le voile sur ce mot barbare qui est la qualification des exercices que vous faites tous pour transformer votre bedaine en plaquettes de chocolat et sculpter votre corps d'athlète.

Comme nous sommes des développeurs, on va se contenter de se muscler le cerveau grâce à des exercices de code qui nous pousseront naturellement à rédiger du code propre et lisible. Pour les allergiques aux bouquins comme moi, l'efficacité sera décuplée.

D'ailleurs les Jams de code d'Arolla permettent de faire ce genre de choses en groupe avec de la bière et des chips !

Extremist Programming

Par Eric Lefevre-Ardant et Cyrille Martraire

NF : Cette conférence ne se prend pas au sérieux pour nous diffuser un message pourtant important : écrire du code étant une activité littéraire, nous sommes des écrivains et par extensions des artistes ! En prenant exemple sur des génies de notre métier comme Ward Cunningham et Kent Beck, le duo nous montre qu'il est utile d'essayer nos idées folles pour constater leurs effets AVANT de les rejeter. Qu'une idée soit folle n'est pas une garantie de pertinence, mais voir ces effets nous permettra d'affiner notre jugement sur les idées suivantes ! En tout cas, si vous avez envie de vous faire plaisir en programmant, cette conférence vous démontrera avec brio que vous avez bien raison !

RLR : Une présentation qui ne se prend pas au sérieux : Distribution de cookies et pipo bingo au menu ! Faites passer le mot, nous sommes des artistes et pour révéler le génie que nous avons en nous, il ne faut pas hésiter à tenter tout ce qui peut nous passer par la tête, au pire on se rendra compte que l'idée n'est pas bonne, au mieux on aura peut-être inventé le nouveau truc qui va changer le monde du développement logiciel.

2 méthodes rigolotes que j'ai noté :

• Le Mob programming : un écran (panoramique), un PC, un clavier, et toute l'équipe dessus pour du pair programming poussé à l'extrême.
• L'Anarchy Programming : Supprimez tout, manager, PO, marketing, fonctionnel, ne gardez que l'essentiel : un client et un développeur.

Fifty New Features of Java EE 7

Par Arun Gupta

RLR : Un marathon ! L'orateur à 50 points à passer en 50 minutes. Une présentation à garder dans un coin de sa tête lors de son passage de JEE 6 à JEE 7 pour éviter de réinventer une roue déjà intégrée à l'API.

Tout ce que vous avez toujours voulu savoir sur les lambdas et plus encore

Par Rémi Forax

RLR : Une conférence très instructive qui explique pourquoi et comment la programmation fonctionnelle apparaîtra dans Java 8. On commencera par l'envie d'éviter de dupliquer du code en passant des fonctions en paramètres et la frustration de ne pouvoir le faire en Java. Suivront la Grande Guerre des Closures de 2006/2007 entre BGGA (les gourous du compilo Java), CICE (les gourous de l'API Java), et FCM (les utilisateurs). Une explication de la syntaxe (le coloncolon et la simple flèche '->'). Mais aussi en détail ce que cela donne au niveau du bytecode.

Java 8 Lambdas in the Stream

Par  Paul Sandoz

RLR : Une très belle présentation expliquant l'API Stream couplé avec les lambda dans Java 8. Voici comment passer d'un code très séquentiel, impératif, à un code qui s'attache à l'essentiel, la manipulation de son jeu de données qui pourra être parallélisé aisément par la JVM.

50 nouvelles choses que l’on fait avec Java 8

Par José Paumard

NF : Vous suivez l'actualité de Java, vous connaissez tout des lambdas et des streams... Et bien, voici le reste des changements apportés par Java 8. Et les singletons se font avec des Enum n'ayant qu'une seule valeur depuis Java 5.

RLR : Parler de Java 8 sans évoquer les Lambdas, ni les Streams tient de l'exploit que l'orateur relève aisément. A noter une simplification de l'API date orienté développeur, le StringJoiner qui permet d'éviter les traitements "aux limites" ie supprimer cette dernière virgule qui rend le code tout moche, une manipulation de fichier simplifiée, et le CompletableFuture...

Linux 101, domptez le pingouin

Par Pierre-Antoine Grégoire et Frédéric Weisbecker

NF : L'introduction sur Linux ne m'a pas appris beaucoup, mais les slides sont déjà disponibles. De mon point de vue, j'aurais ajouté quelques commandes comme :

• "reset" qui réinitialise le terminal après avoir affiché le contenu d'un fichier binaire
• "file" qui lit les premiers octets pour nous afficher le type de fichier. Ce dernier nous dit si l'exécutable est un lien, un script shell/perl/... lisible ou un exécutable compilé (elf/a.out).
• "lsof" liste les fichiers ouverts dans le système. Sachant que les sockets sont des fichiers au même titre que les binaires, les librairies, les fichiers de log.
• et enfin, "strace" que liste les appels système fait par un process, voire par un process et ses fils.

Votre Livrable avec Docker en prod dès demain

Par Jean-Batiste Note et Loïc Le Bel

NF : Ils ont eu besoin d'un cloud privé, de le provisionner, de déployer, d'upgrader à chaud, de le déménager... C'est un boulot un peu dingue et l'aventure qu'ils présentent doit être passionnante. Elle continue et ils recrutent si ça vous intéresse.

RLR : Un retour d'expérience des gourous du réseau et d'Hadoop de Critéo. Quelques citations :

- A propos de la mise en place d'Hadoop à l'échelle de Critéo : "Anything that could go wrong - will go wrong" (Loi de Murphy).

- A propos de la mise en place d'un cloud : "Qui fait les choses à la main tombe dans le ravin !".

- A propos de leur topologie de réseau : "Un hypertore à N dimensions" (qui se résume en un triangle ne vous inquiétez pas ;)".

RLR : L'orateur présente un outil de calcul de recommandations. Cet outil permet en 10 lignes de code de faire abstraction de tous les calculs mathématiques qui se cachent derrière ce système qui permet de booster les ventes de son site e-commerce ou de faire se retrouver sur votre réseau social des amis perdus de vue depuis 10 ans. Cependant il ne faut pas oublier qu'utiliser un outil n'empêche pas d'être intelligent, Mahout propose différents algorithmes et il est vivement recommander de valider l'utilisation de l'un ou de l'autre, voire de réaliser un panachage de plusieurs algorithmes en lui demandant de tourner sur 90% de son échantillon avant de le confronter au 10% restant.

Bitcoin et monnaies cryptographiques

Par Paul Greg

RLR : J'ai enfin pu comprendre comment marchaient les bitcoins grâce à cette présentation. Si je résume, il s'agit d'une monnaie pour laquelle la validation des transactions, au lieu d'être centralisée (par les banques) peut être validée par n'importe qui à partir de calculs cryptographiques.

Quand je me connecte au réseau, je récupère le montant de mon compte en fonction d'un dernier "bloc" validé.

Quand je veux réaliser une transaction, je demande au réseau de la rajouter au prochain bloc à valider.

C'est dans la validation du bloc que les "mineurs" interviennent. Ceux-ci, forts de la connaissance intégrale de l'historique des transaction (20Go actuellement) sont en concurrence pour valider un bloc qui comprendra les transactions en attente de validation, la signature du mineur ainsi qu'un nombre qui permettra au bloc d'avoir certaines propriétés (une valeur de "hash" commençant par un certain nombres de 0). Une fois cette valeur trouvée, elle sera soumise au réseau et le mineur sera récompensée de quelques bitcoins, et les mineurs commenceront à travailler sur le bloc suivant.

Plusieurs mineurs pouvant trouver une validation en même temps, on pourra se retrouver temporairement avec un arbre plutôt qu'une chaîne de blocs. Les mineurs devront éliminer les branches les plus courtes. Le souci est que, du coup, si une "ferme de minage" dispose de plus de la moitié de la puissance de calcul, elle pourra faire croître des branches originalement plus courte pour dépasser la branche principale, invalidant ainsi beaucoup de transactions et brisant la confiance dans le bitcoin : cela ne doit pas arriver.

Le calcul de hash pour le bitcoin demande beaucoup de CPU, il n'est pas rentable de miner avec son propre PC, mais il est possible de faire partie d'une ferme de minage qui partage les gains à la validation d'un bloc. La difficulté du calcul est mis à jour régulièrement afin de garder un rythme de validation de blocs de 1 toutes les 10 minutes.

Le bitcoin est donc adapté pour le e-commerce ou la validation d'une commande peut attendre un peu et la mise en place d'un service de CB demande à passer par une banque qui prendra sa commission au passage. Il est par contre moins approprié pour acheter sa baguette de pain.

A noter aussi qu'il existe d'autre monnaies cryptographiques basées sur d'autres algorithmes (le Litecoin demande de la mémoire et non du CPU).