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 !