Blog Arolla

[DevoxxFr 2014] : Un autre compte rendu de l’événement 2/2

… Suite de mon retour sur DevoxxFR 2014. La première partie est disponible ici.

Software Cfraftsmanship

agile_programming

Software Craftsmanship is about professionalism in software development

Sandro Mancuso commence sa prez centrée sur la culture du craftsman par un petit rappel sur les valeurs de l’agilité. Il n’a pas fallu beaucoup de temps pour que les méthodes agiles soient largement adoptées dans les projets. Par la suite de nouveaux acteurs sont apparus dans le domaine, coach, chefs de projet agile et organismes de certifications. Et le constat est que les valeurs de l’agilité sont en train d’être noyées par ce succès, plus on parle d’agilité moins on s’intéresse aux principes évoqués dans le manifeste agile.

Sur l’attitude du craftsman, il doit garder à l’esprit que l’objectif de toute pratique et process agile de développement (XP, TDD, BDD, DDD, …) est avant tout de produire de la valeur logicielle pour la satisfaction du client. Sans toutefois oublier que le client n’a pas à inférer sur la méthode de travail, le choix de faire du TDD ou non, c’est un problème entre le développeur et son code. Tout comme ”on ne demande pas à son dentiste comment il doit soigner notre dent”.

Who own your carrier ? Le craftsman est le seul propriétaire de sa carrière professionnelle. Tous les moyens nécessaires à sa promotion, à son épanouissement intellectuel, de la formation à la documentation, sa participation aux communautés et katas, relèvent de sa responsabilité. L’ancienneté n’est pas tout le temps synonyme d’expérience. Répéter les mêmes gestes pendant 10 ans ce n’est pas avoir dix années d’expérience, c’est plutôt avoir 10 fois la même expérience.

How it is done is as important as having it done :Solving problems is what we are paid for and what we do at work.”. La manière de résoudre un problème est aussi importante que la résolution du problème. C’est en se focalisant sur les techniques de résolution d’un problème qu’on arrive à améliorer le niveau de son code. Résoudre un problème ne peut pas se limiter à être une activité quotidienne, mais aussi une nouvelle occasion de mettre en ouvre les bonnes pratiques.

Bitcoin

Il a aussi été question de money à Devoxx, sans le contexte juridique bien sûr, ni financier. C’est Grégory Paul qui nous offre une visite guidée de l’univers Bitcoin. La monnaie cryptographique qui fait le buzz sur le net (ne pas confondre avec monnaie virtuelle) . “Le genre de sujets dont tout le monde parle, sans que ce soit facile de croiser quelqu’un qui sait de quoi il s’agit”.

Une session soigneusement préparée. On en sort avec l’impression d’avoir tout compris, mais au moment d’en parler à son tour on se rend compte qu’on n’a qu’un vague aperçu de l’ensemble. Ceci n’est donc qu’un petit résumé par rapport à la complexité du système Bitcoin. Si vous avez besoin d’en savoir plus je vous invite à consulter les liens que vous trouverez en bas de page et qui font partie de mes sources.

Tout démarre avec la publication en 2008 du papier de Satoshi Nakamoto (personne ou groupe de personnes) dont l’identité reste jusque là un mystère.

Nous sommes en 2014, Internet a plus de 20 ans, et le commerce électronique reste toujours assuré par les institutions financières traditionnelles. C’est un système de paiement qui est géré par un organe centrale, l’ “Autorité de confiance” – banque ou société de cartes de crédit – qui décide de qui a le droit d’envoyer/recevoir de l’argent, applique des taxes et valide les transactions. Le système Bitcoin veut rendre les opérations financières accessibles à tous, à moindre coût, sans contrainte administrative, comme l’est la messagerie électronique, tout en garantissant la sécurité par l’utilisation de chiffrement et de signature numériques. C’est un système de monnaie électronique décentralisé où les transactions se font en ligne directement d’un tiers à un autre sans passer par une Autorité de confiance.

bitcoin-overview

Clés et signature

L’intégration du réseau Bitcoin commence par l’installation du logiciel bitcoin (sur PC, tablette ou smarphone). Juste après, une paire de clés publique/privée est générée automatiquement. La clé publique constitue l’adresse de l’utilisateur, elle peut être communiquée aux autres. Elle est aussi utilisée pour vérifier l’authenticité du message envoyé par l’utilisateur. La clé privée permet de signer les messages à envoyer (signature numérique) et de déchiffrer les messages reçus.

sign(message, privatekey) = n67n54n6l10xf15
verify(“n67n54n6l10xf15”, message, publickey) = valid or invalid

Transaction décentralisée

Dans un système monétaire classique les transactions passent par l’Autorité de confiance qui les valide à son tour. Dans Bitcoin les transactions sont décentralisées, A peut envoyer directement à B. La transaction, une fois validée, est diffusée sur le réseau. Étant donné que tous les utilisateurs disposent de toutes les infos, chacun peut valider une transaction, ça consistera à vérifier qu’elle (la transaction) vient de A et que ce dernier dispose bien du moment spécifié dans la transaction. Le nombre de validations nécessaires pour une transaction dépendra du montant en jeu.

Une nouvelle transaction se trouve provisoirement dans une liste, puis une fois validée elle est ajoutée à la liste des transactions validées qui sont regroupées dans une chaine de blocks.

bitcoinchain

Mining and “Proof of work”

Après la transaction, le minage est le second type d’opération bancaire, c’est un moyen d’injecter des bitcoins dans le réseau. Pour en avoir, il faut fournir de l’effort, “Proof of work”. Le travail consiste à résoudre un problème mathématique, trouver le message initial d’un hash unidirectionnel à partir du digest (hash(X) = digest). Résoudre l’équation relève plus d’une question de chance et de puissance de calcul que d’intelligence. Le premier qui trouve la solution gagne des bitcoins, et l’information est enregistrée sur la liste de blocks et diffusée dans tout le réseau. “A a gagné x bitcoins”. La complexité croissante du problème à résoudre fait que le nombre de bitcoins en circulation ne dépassera pas le montant de 21,000,000 BTC.

Total_bitcoins_over_time_graph

Pour plus de lectures sur le sujet.
L’url de la prez : http://paulgreg.me/bitcoin-cryptocurrencies/
http://preshing.com/20140127/what-is-a-bitcoin-really/
http://brikis98.blogspot.fr/2014/04/bitcoin-by-analogy.html

40 tips with Idea

Quand on travaille plus de 8 heures par jour avec le PC, l’utilisation continue de la souris devient très vite une contrainte. Le click ne fait travailler qu’un doigt et le bras reste sur une position pendant longtemps. Un bon IDE doit faciliter le travail, en permettant d’utiliser le clavier le plus possible, avec des raccourcis pour les tâches les plus courantes, le clavier étant plus rapide que la souris. Avec IDEA, en plus de la réactivité de l’IDE, on peut quasiment se passer de la souris, répartir la charge de travail sur tous les doigts et gagner en vitesse. Il y a toujours un raccourci pour ce qu’on veut faire. Hadi Hariri nous en a montré 40 qui sont incontournables:

CTRL + N puis “MMC:45″ : “MyMainClasse” (ligne 45)
CTRL + E : fichiers récemment ouverts
CTRL + ALT : Navigation en arrière
CTRL + ALT + V : extraire une variable
CTRL + ALT + F : extraire un champs
SHITF + ALT + DOWN (TOP) : déplacer un block de codes vers le bas (haut)
SHITF + CTRL + ENTER : compléter un “statement”
SHITF + CTRL + SPACE : compléter un nom

Bon testeur & Mauvais testeur

Le bon testeur il teste, le mauvais testeur il teste aussi. La différence entre les deux, quelques éléments importants que Agnès Crepet et  Guillaume Ehret nous ont présentés dans un format livecoding. Le code de test est soumis aux même exigences de maintenabilité que le code de production, puisqu’ils sont appelés à évoluer ensemble. Voici quelques règles que le bon testeur peut utiliser comme axes d’amélioration pour assurer à ses tests un bon niveau de qualité :

  • Choisir des noms de méthodes de sorte à exprimer sans ambiguïté l’état initial du test et le comportement qui est attendu (shouldDoSomeThingWhenThisConditionIsTrue, should_send_email_when_event_happen)
  • Disposer des outils de tests qui simplifient l’écriture d’un code plus concis et plus lisible. Avec AssertJ (ou FestAssert pour certains) on peut avoir des assertions plus fluentes que le simple assertEquals ou assertTrue.
  • Avoir une bonne connaissance de son framework de tests (JUnit, TestNG, Mockito, PowerMock, …). JUnit offre plusieurs annotations comme @Rule qui permet de partager du comportement entre classes de test sans passer par l’héritage, @Parameterized qui permet de paramétrer une méthode de test avec un jeu de données, @ExcpectedException pour tester les exceptions, …
  • Choisir une base de données embarquée (derby, h2, dbUnit, …) pour rendre fluide les tests qui nécessitent l’accès à une base de données.
  • Savoir distinguer un mock d’un stub quand on fait du mocking.
  • Tester le comportement et non l’implémentation.

La salle était achi comble pour cette session, avec des gens assis par terre, ce qui prouve que le sujet passionne encore. Le contenu était d’un niveau élevé et la forme de la présentation n’était pas négligée. Mais 50 minutes c’est insuffisant pour le sujet dont chaque point pourrait faire l’objet de discussion et de retour d’expériences. Je crois qu’un Lab de trois heures serait plus adapté.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *