Dependency injection into Scala object (singleton)

L'injection de dépendance en Scala est une chose plutôt aisée du fait des possibilités de la syntaxe et des API à disposition. Il existe ainsi plusieurs méthodes permettant de le faire programatiquement, sans fichier de configuration, sans framework comme Spring ou Guice.
Le propos de cet article n'est pas de lister et de comparer toutes les méthodes disponibles pour ce faire; ceci sera traité dans un article ultérieur; mais de décrire une manière d'injecter les dépendances dans un contexte précis.
J'ai récemment eu a participer au développement d'une application web "classique" avec des Dao et des Services.
Ces Dao et Services sont naturellement indiqués pour être utilisés comme des singletons. En Scala, nous disposons d'un mot-clé pour déclarer des singletons : object.
Je vais donc essayer d'illustrer comment injecter une dépendance dans un object Scala et de rendre cet object lui même injectable dans une classe tierce.

Devoxx France 2014 - Préparer sa conférence grâce à onecalendar.fr

Ca y est Devoxx France 2014 c'est partir ! Enfin à l'heure où j'écris ces lignes, c'est demain. Comment faire pour préparer sa conférence, faire un petit tri à l'avance des talks que l'on veut aller voir ?

Grâce à l'application web OneCalendarToMeetThemAll et à votre client agenda préféré vous pouvez récupérer tous les horaires, lieux et descriptions de conférence Devoxx France pour les 3 jours et faire votre choix.
Vous pouvez ainsi le consulter sur votre smartphone durant la conférence pour ne pas perdre de temps au milieu des milliers de développeurs qui parcourront les couloirs de l'hôtel Mariott avec vous.
Voyons dans le détails comment faire, vous verrez c'est très simple, un simple clic et c'est parti !

Embedded MongoDB in Scala !

La première fois que j'ai du utiliser une base mongoDB c'était pour stocker les objets métier de l'application OneCalendar, une application écrite en Scala avec playframework 2.

A cette époque (début 2012), on m'avait assuré qu'il était impossible de démarrer une base mongoDB via un test et que si je voulais tester je devais installer une base MongoBD sur mon poste de dev et le démarrer avant.
Je trouvais ça vraiment dégeu mais ne connaissant pas du tout l'écosystème mongo je me suis exécuté.

Depuis lors, j'ai trouvé un super projet JAVA qui permet d'utiliser une base mongoDB embarquée pour ses tests et je me suis amusé à écrire un petit utilitaire pour le porter sur SCALA.

C'est hyper simple, il suffit de récupérer une dépendance "maven com.github.simplyscala" %% "scalatest-embedmongo" % "0.2.1" et d'utiliser une api accessible via l'extension d'un trait com.github.simplyscala.MongoEmbedDatabase

La version ou encore le port de connexion à la base sont configurables, et après la librairie s'occupe seule de télécharger la base dont vous avez besoin pour vos tests. Tout est automatique c'est très puissant ! (juste un peu long la première fois que vous téléchargez la base).

Transformez vous ! Manifeste pour une agilité relative !

Amusons-nous à une petite étude de texte sur les 4 valeurs du manifeste agile pour mieux le comprendre et se rendre compte que le contexte d'application est primordial pour une transition agile réussie.

Pair Programming Swapping

Dans un article précédent, j'ai essayé d'introduire le Pair Programming.
Ceux qui s'essaient à cette formidable pratique professionnelle, se sont sûrement  demandés à quel moment il fallait permuter les binômes.
Peut-être même certaines équipes ne permutent quasiment jamais leurs binômes.
Je vais essayer de vous montrer comment, en introduisant la pratique de Revue de Pair, nous pouvons rythmer le binômage dans une équipe.

Egoless Programming Manifesto

Lors de la keynote de Pierre Piezardi à Devoxx France 2012, il a été fait mention du manifeste Egoless Programming. Cela m'a tout de suite frappé et intéressé.
Cette collection cohérente de "règles de vie" du développeur est une pierre utile à l'édifice "AGILE", une façon d'incarner ces valeurs.

1. Comprendre et accepter que nous pouvons faire des erreurs
2. Nous ne sommes pas notre code
3. Peu importe combien nous connaissons le karate, il y aura toujours quelqu'un qui en connaîtra plus que nous
4. Ne pas réécrire le code d'un autre programmeur sans le consulter avant
5. Traitons les gens qui en savent moins que nous avec respect, déférence et patience
6. La seule constante dans le monde est le changement
7. La seule vrai autorité vient du savoir et non de la position
8. Battons-nous pour ce que nous croyons mais acceptons gracieusement la défaite
9. Ne soyons pas "the guy in the room"
10. Critiquons le code plutôt que le codeur. Soyons gentil avec le codeur, pas avec le code

Pourquoi tu programmes ?

Pourquoi programmons nous ? Je ne pose pas la question dans un sens existentiel ou motivationnel.
A travers cette question je cherche à faire apparaître un sens à ce que nous faisons, pour la plupart de nous, plusieurs heures chaque jours.

Functional Programming Principles in Scala - Les certifications sont arrivées

Pour ceux qui ont participé à la classe Functional Programming Principles in Scala sur Coursera, les "certificats" sont publiés sur votre page profil dans le menu "Course Records".

Le mien :

Smarter pojo

Je vous ai montré, dans un article précédent, comment écrire un pojo immuable fournissant une API d'instanciation sémantique. Dans ce premier article sur Scala, je vais montrer comment faire de même et ceci beaucoup plus simplement, grâce aux concepts et aux différents sucres syntaxiques fournit par le langage.

Le bon matériel

Je soutiens l'appel qu'a fait Olivier Croisier sur son blog équipez vos développeurs et en ce sens j'affiche ce que coûterais divers ustensile utile pour mon travail suivant mon taux de facturation et le temps que je perds par jour à cause d'un build de l'application sur laquelle je travail (uniquement à cause de cela). image disponible sur le blog d'Olivier

Je parle en connaissance de cause car j'ai effectué les mêmes calculs qu'Olivier récemment sur mon projet, où nous somme sur windows 7 32 bits, avec des pentium duo core et un disque dur 5400 tours/minutes.

Le temps de build du projet sans les tests d'intégration était de 2minutes et 56 secondes.
Sur mon PC portable perso (un core i7, 16 Go de RAM, disque dur ssd 256 Go et Ubuntu 12 64 bits) le même build prenait 46 secondes !!!
Vous calculez plus de 2 minutes de perdus (toujours sans compter les tests d'intégration) par build, sachant que je fais plus d'une vingtaine de build par jour, je vous laisse vérifier c'est énorme.
Tout cela sans compter que lorsque votre machine mets plus de 4 minutes à builder votre application (la c'est en comptant les tests d'integ), vous ne rester pas à attendre derrière votre écran, vous faites autre chose (regarder ses mails, twitter, etc...) et ainsi vous perdez plus que les minutes nécessaires au build.

La réalité est pourtant que la plupart des développeurs, même s'ils expliquaient cela à leur client/hiérarchie n'auraient pas de meilleur matériel.
C'est pour cela que je réalise qu'il est nécessaire de choisir les gens avec qui ont travaille. Savoir si on préfère travailler avec des gens qui visent la qualité, l’efficacité dans le travail ou pas.
Qu'en pensez-vous ?

Moi je pair pas je gagne !

Après mon premier article sur le TDD, où j'ai remis en cause certains mythes sur le sujet, je m'attaque au Pair Programming, pratique soeur du TDD en eXtreme programming.

C'est la pratique XP qui a le moins de succès au sein de la communauté large de l'IT. On voit fleurir quantité de billet de blog pour dénigrer cette pratique, on lui préfère la revue de pair (faite par un chef, tu m'étonnes ...), on trouve cela stupide de dépenser deux fois le temps nécessaire pour faire la même chose.

Nous allons voir en quoi cette vision relève d'une incompréhension profonde de ce qu'est le pair programming et l'agile en général. Je vais essayer de briser quelques mythes et de montrer en quoi cette pratique donne toute son efficacité au TDD et à l'eXtreme programming.

TDD n'est pas tester !

Tu fais du TDD toi ?
Bah ouais, des fois j'écris mes tests en premier.
Et ton taux de couverture du code par les tests ?
Bah j'essaie d’atteindre les 80 %, y parait que c'est une bonne moyenne.
Souvent je rencontre des développeurs qui me parles du TDD comme cela.
Mais malheureusement il n'ont pas saisi ce qu'était le TDD, les objectifs qu'il permet d'atteindre, la façon de le mettre en œuvre.
Je vais essayer d'expliquer comment je vois et pratique le Test Driven Development, avec succès depuis quelques années.

Distribuer ses dividendes grâce à l'intelligence collective

Vous cherchez à mettre en place dans votre organisation une culture d'innovation, de coopération plutôt que de compétition et de politique.
Cela va passer notamment par les modes de rémunérations de cette organisation qui doivent récompenser d'avantage l'innovation et la coopération, pour encourager ces comportements.
Mais en tant que manager, il n'est pas aisé de savoir qui coopère ou qui joue pour sa pomme, qui innove réellement ou qui sait mieux se vendre en terme d'image.
Certaines organisations ont mis en place une façon efficace de distribuer leur dividendes : utiliser l'intelligence collective de leur membres.

Smart pojo

Dans cet article je vous propose de la description d'un pojo respectant certaines bonnes pratiques de développement que sont l'immuabilité et une API sémantique et facile à utiliser et à relire.

S'iou plaît, chef !

Chef, chef ! Est-ce que je peux installez linux sur ma machine ?
Chef, chef ! Est-ce que je peux utiliser IntelliJ comme IDE ?
Chef, chef ! Est-ce que je peux faire du TDD et du pair programming avec mon copain ?
Chef, chef ! Est-ce que je pourrais avoir plus de 2 Go de RAM et un deuxième écran ?
Chef, chef ! Est-ce que je peux utiliser backbone.js c'est vachement bien ?

Doit-on demander la permission à notre hiérarchie à chaque fois que l'on souhaite prendre une initiative ?

A chacun de se poser la question selon ses filtres et ses croyances.

Personnellement, dans le travail, je préfère demander pardon que s'iou plait (et même pardon je le demande pas LoL).
Pour moi, la hiérarchie est un frein immense à l'innovation et à la prise d'initiative.
Les organisations plates types "agile" ou "sociocratique" sont bien plus intéressantes à mon goût.

la sociocratie
le manifeste agile
l'eXtreme programming
LateralThoughts : une SSII sociocratique

Scala Dojo #2

Le mardi 24 juillet a eu lieu le deuxième ScalaDojo du Paris Scala User Group chez Valtech.
Le but de cette rencontre est d'échanger sur Scala, autour d'une bonne pizza et d'un paquet de stroumph, en mettant les mains dans le cambouis.

Au programme, cette lors de la soirée :
- Task sbt
- Les DataType
- Utilisation de Either
- test d'un controller Play 2
- Implémenation du dilemne du prisonnier en scala avec emacs et sbt

Merci à @un_jon et à Lateral Thoughts qui ont financés les pizzas et les boissons.

A bientôt pour un ScalaDojo #3 !