Accéder au contenu principal

JavaCampParis7



Encore une réussite ce JavaCampParis7 organisé par @LucBizeul, @PhilippeAntoine et Google FR. Nous nous sommes une fois de plus retrouvés dans les locaux de Google à Opéra entre une bonne cinquantaine de dévers de tout poil pour parler de pas mal de choses, mais finalement peu de Java. Journée difficile oblige, je n'ai pu participer qu'à une seule session : FP / Scala...

Comme à l'accoutumé, j'ai croisé mes anciens camarades de Vidal Software où l'utilisation de la programmation fonctionnelle dans des projets sérieux n'est pas une légende. En effet, @ugobourdon, @a_thieriot et @tonyskn nous ont fait part de leur retour d'expérience sur l'utilisation de Scala comme outil de développement du gestionnaire de mise à jour pour l'un de leur produit. Après une courte introduction sur les raisons expliquant en quoi Scala avait sa place chez Vidal, nous avons débattu sur les façons/raisons d'intégrer cette technologie en entreprise. En effet, nous constatons que bien souvent, les organisations ne perçoivent pas l'intérêt d'utiliser un nouveau langage de programmation et ont l'impression de subir un caprice de développeur.
Loin s'en faut, je pense que la mission d'un développeur est d'une part d'assurer sa veille technologique, mais aussi de corréler/axer cette veille technologique, suivant les besoins business de son entreprise : chose que certain d'entre nous ont trop tendance à occulter, j'ai l'impression.
Bref, j'arrête de digresser pour revenir au débat principalement animé par les gens de Vidal et Zenexity, où j'ai retenu deux informations intéressantes. La première par Ugo qui expliquait que l'utilisation des listes en Scala était un pur bonheur et que via cette API, il avait pu faire ses premières lignes de codes réellement fonctionnelle. La seconde par @mrspeaker qui m'a tendu un livre à lire pour vraiment se mettre à le programmation fonctionnelle, il s'agit de The Haskell School of Expression: Learning Functional Programming Through Multimedia Il m'a assuré que c'est un pro de programmation fonctionnelle qui lui a conseillé... et comme je vois de qui il parle, je ne peux que le croire :)

En résumé, encore une soirée passée auprès de gens bien capables, qui mettent les mains dans le cambouis, qui n'hésitent pas à venir parler de leur travail et à partager leurs expériences. Donc merci à ces barcampers et à la prochaine !

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Faire sa machine virtuelle sous Debian ARM avec QEMU

Introduction L'objet de ce article est de vous expliquer comment faire  pas à pas,  sa machine virtuelle Debian Wheezy   tournant sur un processeur ARM   avec QEMU . Il est relativement simple de trouver des ressources à ce sujet sur le Web, mais je voulais apporter ma pierre à l'édifice sous forme d'un petit  tutorial prêt à l'emploi. A propos d'ARM et d'émulation, il faut savoir qu'au jour d'aujourd'hui, VirtualBox est incapable de virtualiser un OS tournant sur ARM, cela m'a donc obligé à m'intéresser de plus prêt à QEMU. Et si vous vous demandez pourquoi, je veux émuler de l'ARM, vous le serez au prochain épisode... QEMU QEMU est un logiciel développé à l'origine par le célébrissime programmeur  Fabrice Bellard . Le succès de cet émulateur vient principalement du fait, qu'il est tout aussi capable d'émuler que de virtualiser. La principale différence entre l'émulation et la virtualisation est qu'un ...
2 commentaires
Lire la suite

Create and use a result captor in Mockito

Today I will show you how to create a Mockito captor In Mockito it exists the possibilty to use ArgumentCaptor to allow developers to verify the arguments used during the call of mocked method, but not the result itself. Indeed, in the current release of Mockito it's not possible to capture it and my solution to do that is to build a ResultCaptor class which implements the Answer interface and generify it for more conveniance. Let's take a look. Create the ResultCaptor class public static class ResultCaptor < T > implements Answer < T > { private T result = null ; public T getResult () { return result ; } @Override public T answer ( InvocationOnMock invocationOnMock) throws Throwable { //noinspection unchecked result = ( T ) invocationOnMock.callRealMethod(); return result ; } } In this quite simple implementation we see that the ResultCaptor class implements the Answer interface which force to override the...
Lire la suite

Retour sur Rework

Je me suis pour une fois sorti la tête des ouvrages techniques, de mon GoogleReader/programming/languages et autres joyeusetés de ce genre, pour me plonger dans le livre à la mode, Rework . Ce livre co-écrit par Jason Fried et David Heinemeier Hansson est un cookbook destiné aussi bien aux boss, qu'à leurs employés, désirant comprendre et décrypter les clés de la réussite de cette entreprise : 37signals , qui est au passage la boite qui a crée le website Basecamp et le framework ROR . L'ensemble repose sur un enchainement intéressant de chapitres courts mais percutants, avec des illustrations assez plaisantes. Tout est écrit en noir & blanc dans un anglais assez compréhensif, qui permet de le terminer en un clin d'œil, si vous n'avez pas fait comme moi et pris des notes quasiment à chaque chapitre. Je ne vais pas coucher toutes mes notes sur cette page, mais vous en énumérez les premiers points qui m'ont le plus marqué, car ce livre a été pour moi et sera je...
4 commentaires
Lire la suite