Archives du blog

Mix-it 2012 : toutes les sessions et pourquoi !

  L’une des tâches les plus intéressantes quand on organise une conférence reste la confection du programme. Pour Mix-it, ce programme est fait en deux phases. Tout d’abord il y a les speakers que nous invitons : nous passons quelques semaines a spammer les personnes que nous avons envie de faire venir ou à chercher des speakers sur des thèmes précis que nous souhaitons voir aborder. Quand je dis spammer, c’est vraiment spammer, aussi parce que nous tentons d’avoir des personnes très connues (Oui je pense à toi Joel Spolski!) pour une conférence assez petite dans une ville pas forcément très connue à l’international. Parfois nous n’avons pas de réponse, parfois un non très clair et des remerciements, ou une façon plus “subtile” de le dire (“je viens mais je facture la prestation 50000€, plus les frais de déplacement bien évidement”). Et, parfois (souvent), le speaker accepte ! Et nous voilà avec un programme qui nous fait très plaisir, surtout avec notre objectif de rester une conférence avec un prix d’entrée abordable. Comme nous passons du temps à chercher les speakers, ce sont parfois des noms que vous ne connaissez pas mais je peux vous assurer qu’ils déchirent !

  Faisons un petit tour des speakers invités :
Pamela Fox : l’une des premières à avoir accepter notre invitation. Cette fille est une ancienne dév Google à Mountain View, sur Maps puis Wave. Ce qui déjà, amène un certain respect. Elle était de plus Google Advocate, c’est à dire qu’elle représentait Google dans les conférences. Elle a maintenant lancé sa propre startup, où elle réalise tous les développements dont une application mobile multi plateforme utilisant un framework qui fait du bruit : Phonegap. Nous sommes très heureux de la voir accepter de venir depuis San Francisco pour en parler, et cela s’annonce passionnant.
Petra Cross : est, elle, encore chez Google, où elle fait partie de l’équipe qui développe App Engine. Et comme Mix-it a l’agilité dans ses gènes, elle viendra nous parler de la façon dont Google en fait. Je trouve particulièrement intéressant de voir comment les teams de devs utilisent les méthodes agiles chez Google et notamment leur workflow de développement et release.

  Ne serait-ce que pour ces deux talks, vous en avez pour vos 30€ (repas et goodies compris), non ? Mais ce sont seulement 2 des 30 speakers. Dans les invités, nous comptons également :
Pieter Hintjens, l’un des leaders du projet ZeroMQ et des rédacteurs de la spécification AMQP. Il nous serait difficile de faire meilleur speaker pour parler de messaging, ZeroMQ ayant une approche innovante dans le domaine en étant brokerless !
– Parce que nous voulions parler de Node, mais en parler avec quelqu’un qui connaisse vraiment le sujet, nous avons le plaisir d’accueillir l’un des rares core committer Node.js européen, j’ai nommé Felix Geisendorfer ! En plus de posséder une solide expérience technique sur le sujet, il a également lancé une startup dont Node est la principale brique technique. Il nous parlera de javascript côté serveur et si cette solution est vraiment plus scalable que d’autres technologies. Et y a-t-il sujet plus chaud en ce moment ?

  Je pourrais vous parler des 10 autres invités, mais je vois que ce post est déjà plus long que prévu… Bref, il nous restait alors 11 places. C’est là qu’entre en jeu le call for paper, sachant que ni les sponsors, ni les amis ne bénéficient de faveurs. Nous avons eu 64 propositions de talks! Et très peu ne nous plaisaient pas! La soirée de choix a donc été agitée. Il n’a pas toujours été simple de trancher, et nous avons essayé d’expliquer aux speakers refusés pourquoi, individuellement. Mais nous avons enfin notre programme, avec du Play! 2 (par l’un de ses développeurs), du Kanban, du Hadoop, du MongoDB (par une startup qui l’utilise tous les jours), du Devops (par une entreprise qui en fait tous les jours)… Ce genre de session avec un retour d’expérience concret nous intéresse beaucoup, et je suis sûr qu’elles vous plairont.

  Une programmation dont nous sommes très contents ! Amis lecteurs, j’espère vous voir nombreux le 26 Avril (Lyon, c’est pas loin, 30€ c’est pas cher et c’est éligible au DIF, pas besoin de poser de congés) !

Publicités

Getting Started with Hadoop : Part 2

Disclaimer : Ce billet est la deuxième partie d’un article écrit pour la revue Programmez  (n°144) et traite de la technologie Hadoop. Si vous avez manqué la première partie, la voici. J’en profite également pour citer un article de businessinsider qui vous donnera peut être envie découvrir cette techno :  les startups qui emploient les ex-Yahoo, ex-Facebook et ex-Google. Et l’article est parfaitement dans l’actualité avec la release de la version 1.0.0 !

Exemple
Prenons un exemple pratique : vous voulez trier une pile de pizzas, chaque pizza ayant un parfum (4 fromages, margarita…) et une forme (ronde, carrée, triangle..). Pour cela vous avez à votre disposition 3 serveurs (3 noeuds dans votre cluster). Quelles vont être les phases map et reduce ?
La phase map va consister à répartir les pizzas selon leur forme. Chaque serveur va recevoir une pile de pizzas à traiter et pour chaque pizza va écrire un couple (clé, valeur) de sortie composé de la forme de la pizza et de la pizza.
(ronde, pizza1), (ronde, pizza2), (carrée, pizza3) …

Une fois toutes les pizzas traitées par les serveurs, on se retrouve avec une liste de couple (clé, valeur) avec les clés représentant les formes de pizza. Hadoop va alors redistribuer cet ensemble de données sur nos 3 serveurs en envoyant les pizzas carrées sur le premier, les rondes sur le second etc… Éventuellement, si les pizzas carrées sont trop nombreuses pour être traitées sur un seul serveur, elles seront envoyées en partie sur le serveur un et en partie sur le serveur deux.

Chaque reducer va alors donner un couple (clé, valeur) en sortie indiquant le nombre de chaque saveur pour les clés qu’il a reçues. On crée ici une nouvelle clé composée de la forme et de la saveur.
(carrée_4fromages, 234), (ronde_margarita, 128), (triangle_margarita,6) …

Cet exemple est un cas d’école, et même si vous allez rarement trier des pizzas, vous pouvez chaîner plusieurs mappers et/ou reducers pour arriver à vos fins sur des opérations plus compliquées.

Parmi les exemples notables d’utilisation, nous avons bien sûr Twitter, Google ou Facebook qui s’en servent massivement pour toutes les opérations d’indexation, de traitement de leurs logs serveur (avec plusieurs teraoctets traités chaque jour) ou encore les prédictions de tendances. Mais on retrouve aussi Hadoop chez des opérateurs de téléphonie mobile (test de nouveaux forfaits sur de vastes volumes de données), ou dans des banques pour des calculs de prime, ou pour des calculs de facturation complexes mais ponctuels. Ou encore dans l’industrie pour les suivis RFID qui peuvent générer des quantités incroyables de données.

Un dernier exemple intéressant est celui du New York Times. Afin de générer plusieurs teraoctets de PDFs à partir de leurs archives et de les ouvrir au public, leur équipe a implémenté un programme map/reduce pour réaliser efficacement cette tâche. Et plutôt que d’acheter de nouvelles machines qui ne leur serviraient plus par la suite, elle s’est appuyée sur des instances Amazon : 100 instances, pendant 24h pour un coût en infrastructure dérisoire de 240$. Résultat : 1.5 To de PDF générés dans la journée, avec le résultat hébergé dans le stockage S3 (Simple Stockage Service, service de stockage dans le cloud de la société Amazon) et prêt à être utilisé.

HDFS
Hadoop n’est pas seulement le framework qui vous permet d’écrire des programmes distribués en vous simplifiant la tâche, il met aussi a disposition un système de fichier pensé pour ce type de traitement. Dans un cluster Hadoop, les données sont réparties entre les différents noeuds du cluster. Chaque bloc de données est même répliqué sur plusieurs noeuds pour éviter toute perte (la valeur par défaut de cette redondance est de 3, la donnée se trouvera donc sur 3 noeuds distincts de votre cluster).

Pour répartir ces données de façon performante, un système de fichier distribué a été créé : Hadoop Distributed File System (HDFS) inspiré là aussi de Google et de son Google File System. Ce système de fichier est écrit en Java et vous assure un système de fichier portable. Même si les données sont réparties, elles sont accessibles par n’importe quel noeud lors du traitement (et sont alors transférées si nécessaires depuis leur noeud de stockage vers le noeud affecté au traitement). Ce système de fichier est également capable de monitorer les noeuds, de répliquer et de répartir les données en cas de perte de serveur. Chaque noeud de votre cluster est, en régle générale, également un noeud de stockage.

Lorsque l’on veut traiter un ensemble de données (par exemple un fichier XML de plusieurs centaines de Mo), on va d’abord monter ces données sur le système de fichier HDFS. Pour cela Hadoop fournit un ensemble de commandes très proches de celles que l’on trouve dans l’univers Unix : ls pour lister, put pour ajouter, rm pour supprimer, cat pour lire… Une fois les données montées, on peut démarrer le traitement ; HDFS va alors diviser chaque fichier d’entrée en bloc de données (par défaut de 64Mb) et l’envoyer à un noeud pour calcul, en privilégiant bien sûr les blocs présents physiquement sur le serveur. L’idée est plutôt de déplacer les traitements vers les données que l’inverse, ce qui est beaucoup moins coûteux en performance et en bande passante.

Ecosystème
Hadoop a aussi un très riche écosystème d’outils qui répondent à des besoins différents.

  • Apache Pig est un langage de requête pour analyser un vaste ensemble de données, né chez Yahoo. C’est une abstraction comme peut l’être SQL pour écrire des requêtes qui sont alors traduites en job Map/Reduce et exécutées de façon distribuée sur le cluster. Cela peut simplifier considérablement l’écriture d’une requête !
  • Apache Hive : un data warehouse libre implémentant un langage de requête orienté SQL (HiveSQL) dont la mise en œuvre se traduit par l’exécution de jobs Map/Reduce orchestrés par Hadoop.
  • Sqoop va, lui, vous permettre d’importer vos données stockées dans une base SQL dans HDFS. Le nom vient d’ailleurs de la contraction SQL-to-Hadoop. Il peut également importer les données dans Hive.
  • Flume permet également de collecter des données, mais plutôt des logs.
  • Apache HBase est une base de données orientée colonne s’inscrivant dans la mouvance NoSQL dont le design s’inspire de BigTable (Google). Elle supporte jusqu’à plusieurs millions de lignes et fonctionne au dessus de HDFS.
  • Oozie est un moteur de workflow pour orchestrer vos programme Map/Reduce ou vos scripts Pig.
  • Hue (Hadoop User Experience) est une interface graphique web qui permet d’administrer Hadoop, de parcourir votre répertoire HDFS, de voir les programmes en cours d’exécution etc…


Bref, beaucoup d’utilitaires sont là pour vous aider !

Comment démarrer simplement ?
Une société s’est spécialisée dans le support d’Hadoop auprès des entreprises : il s’agit de la société Cloudera, qui compte dans ses rangs nombre de commiters du projet, dont Doug Cutting. Cloudera fournit un ensemble de ressources très utiles pour aller plus loin, des vidéos mais aussi une machine virtuelle Ubuntu avec tous les outils précités d’ores et déjà installés et configurés. C’est donc un moyen simple de tester ce que peut vous offrir Hadoop. Le framework est d’ailleurs fourni avec quelques exemples de programmes sous forme de jar, que vous pouvez lancer dans la VM. Le navigateur installé vous permettra de monitorer l’avancement de votre programme lors de son exécution.

Hadoop est donc un outil à connaître et qui vous sera peut être utile dès demain. Il ouvre des perspectives intéressantes sur la façon de traiter vos données et n’est pas seulement réservé aux ‘big players’ du web. Si votre application produit trop de données pour que les outils classiques puissent les traiter, ou que ceux-ci les traitent trop lentement, ou de façon trop coûteuse, pensez Hadoop ! Son implémentation du pattern Map/Reduce vous permettra de découvrir en douceur les joies de la scalabilité, et son formidable éco-système, à peine abordé ici, vous ouvrira un univers sans limite. Et quand on voit le nombre de startups qui se lancent sur cette techno, on se dit que Hadoop, c’est définitivement hype!

Back from Devoxx : Play! 2, hopes and fears

Le mois de Novembre est de loin le préféré des Javaistes et tous ceux qui le peuvent se rendent à Devoxx, la plus grande conférence européenne sur Java. Plutôt que de commenter chaque session vue, je vais essayer de synthétiser mes impressions sur ces 3 jours de conférences.

Devoxx c’est 5 jours, 2 d’universités et 3 de conférences, à Anvers avec 3300 développeurs. C’est beaucoup de rencontres, des gens que l’on apprécie mais que l’on ne croise qu’aux conférences, et d’autres que l’on voit pour la première fois (et que l’on tente de reconnaître des avatars twitter, avec plus ou moins de succès!). L’organisation est extrêmement bien rodée (10 ème édition) et l’équipe de Stephan fait un travail incroyable (vous imaginez servir 3300 geeks affamés pendant une semaine dans un cinéma où se déroulent 6 tracks en parallèle?).

Il y avait de nombreux sujets traités mais je vais me concentrer sur les sujets qui n’étaient pas ou peu présents l’année précédente, en commençant par Play! dans ce premier article.

Avec aucun talk l’année dernière et 3 cette année, on peut dire que Play! a fait du bruit! Nous avons notamment eu l’annonce de la beta release de la version 2.0 et du rapprochement avec la société Typesafe. Une version qui comme le laisse supposer l’intégration dans la stack de Typesafe s’oriente vers Scala, même si Java sera toujours supporté (l’animation en haut à droite de ce site vous donne une bonne idée de l’évolution).

Fears

Cette décision me gêne un peu personnellement et d’après les échos que j’en ai eu, n’est pas forcément très populaire. Vous pouvez installer cette bêta et vous faire une idée par vous même avec la documentation disponible, mais la simplicité que l’on aimait dans la version 1 disparaît un peu. J’ai attendu quelques jours avant de faire ce billet, car je voulais tester un peu par moi même et prendre la température autour de moi et sur le web. Que nous amène donc cette v2 ?

Même si il est possible de rester sur une version Java pour la partie serveur, le moteur de template est pour l’instant en Scala uniquement, alors que Groovy jusqu’à présent faisait un très bon travail en se faisant oublier. Scala amène un typage plus fort donc une détection plus en amont des erreurs éventuelles, ce qui est louable. Trois exemples d’application sont disponibles avec la bêta, et pour avoir joué un peu avec, ce changement ralentit pas mal la compilation des templates : là où on passait son temps à rafraîchir le navigateur pour avoir instantanément le résultat, on attend maintenant un peu que la compilation se fasse, malgré le fait que mon laptop (MacBook Pro) soit relativement puissant. Le système de template Groovy sera peut être sauvé par la communauté  et réintroduit.

Et Scala est certainement un très bon outil lorsqu’on le maîtrise mais il demande globalement plus d’investissement, et là ou la v1 permettait de se plonger rapidement dans le code, cette v2 inquiète un peu par sa complexification inutile. La documentation est encore un peu légère (normal pour une bêta) donc ces craintes sont peut être inutiles mais j’en doute…

La compatibilité est de plus brisée, vous ne pourrez pas upgrader votre application sans un peu de travail. Le système de build est maintenant confié à SBT, le maven-like de Scala : plus de fichier dependencies.yml donc, et l’ensemble de commande est devenu un wrapper de SBT. A voir à l’utilisation, un peu de lecture si vous voulez approfondir.

Hopes

Tout n’est heureusement pas à jeter dans cette nouvelle version! On peut noter l’utilisation d’IO non bloquant (à la nodejs entre autre), et le traitement asynchrone plus développé (concept Iteratee/Numerator issu de Haskell). L’introduction d’Akka permet de supporter une lourde charge tranquillement et le framework Play! a lui même été en partie réécrit pour en utilisant ces concepts. La démo montre que 10000 requêtes ne posent pas de problème au serveur qui monte au maximum à 15Mo de RAM, et redescend à 2Mo une fois la vague passée : impressionnant, même si les requêtes ne faisaient aucun traitement métier. Play! pourrait devenir un outil de choix pour les applications à très fortes volumétries.

L’abstraction de l’accès aux données est réduite au maximum pour laisser aux développeurs le choix du datastore approprié. On retrouve tout de même les entités avec annotations JPA, et Ebean a remplacé Hibernate et amène un finder pratique pour requêter la base, et plus stateless que son prédécesseur. Dans mes rapides tests, on n’est pas vraiment dérangé par cette nouveauté, à creuser plus en détails.

Côté client, l’objectif est de permettre d’intégrer les excellentes technologies que l’on voit apparaître comme Jade, Less (c’est mon prochain billet de la série Nodejs), Backbone.js, Coffeescript. Un répertoire ‘assets’ a été ajouté à la structure du projet et les fichiers contenus sont automatiquement compilés et disponibles comme si ils étaient des ressources (par exemple les .coffee sont compilés en js et disponibles comme si le js était dans le répertoire public).

Les routes sont également compilées et ça c’est très pratique ! Si le controller ou la méthode indiqué dans le fichier route est inexistant, vous le savez immédiatement.

Dans les petits bonus plaisants, on peut maintenant écrire (en Scala) « def index = TODO » qui permet de continuer à écrire son code sans se préoccuper de l’implémentation du controller. Si on appelle cette méthode, elle affiche dans votre navigateur une belle page avec TODO. Le genre de détail ‘nice to have’.

Si vous voulez approfondir et vous faire votre avis, voici quelques liens qui peuvent vous intéresser :  la page officiellele blog Ipponle blog du Touilleur.

So what ?

Play est définitivement devenu populaire, et apprécié par beaucoup. Je fais partie de ceux qui apprécient son côté simple, productif, efficace et fun et qui l’ont utilisé pour faire des sites actuellement en ligne. Cette v2 me laisse un peu sceptique, n’étant pas spécialement un fanatique de Scala. C’est un excellent langage et très puissant, mais aussi très exigeant à produire et maintenir (des personnes autrement plus qualifiées que moi se sont déchainées sur le sujet ces derniers temps). Là où Play! faisait merveille pour commencer une application en 10 minutes après la lecture de 3 pages de tutorial, la v2 s’oriente vers une stack haute performance plus élitiste. Peut être que dans un an Scala/Play nous aura conquis. Dans tous les cas la hype est toujours là, il va falloir tester ça!

fOSSa 2011 : retours sur la track Dev

Les 26,27,28 Octobre se tenait à Lyon fOSSa, une conférence par ordinaire organisée par l’INRIA. Comme le laisse supposé le OSS du nom, le thème central est l’open source, et le but de la conférence est de partager l’expérience entre les participants issus de l’industrie ou de la recherche, entre utilisateurs et producteurs de contenu open source. Les 3 jours abordaient des thèmes différents, je me suis pour ma part concentré sur la track Développement, qui proposait un programme sur une matinée rassemblant des speakers bien connus de nos JUGs (on reconnait bien là les goûts de @jponge, organisateur et maître de cérémonie ce matin là).

Il faut préciser que les talks sont courts, en anglais, et que la conférence était gratuite !

Oracle, 18 mois plus tard

Le premier talk est donné par @alexismp qui nous parle d’Oracle et du changement que le rachat a amené, par rapport à la politique de Sun, qui était clairement positionné sur l’open source.

Photo par Julien Ponge

Alexis commence par un rapide sondage sur ce que nous évoque Oracle :
– base de données
– argent
– open source
Les bras se lèvent plus majoritairement pour les deux premiers avec quelques rires pour le second, que la troisième option. Le but du talk d’Alexis est justement d’éclairer la position d’Oracle à ce sujet. Il nous rappelle du déroulement de l’acquisition et les doutes que l’on a connu (problème avec l’UE, les produits en double dans le catalogue Sun/Oracle sur lequel un doute planait comme NetBeans…). Oracle veut garder un Java attractif, malgré ce que la presse informatique en dit et malgré les départs emblématiques (dont James Gosling le papa de Java). Alexis nous parle aussi des points fachants, comme le procès avec Google pour l’utilisation de Java sur Android puis enchaîne sur une partie plus technique, HotSpot qui va récupérer les fonctionnalité de JRockit, OpenJDK rejoint par IBM, Apple et SAP.
Puis le départ de la fondation Apache du JCP, regretté par tout le monde et les différents projets qui ont forkés : Hudson, MySQL, OpenOffice. Dans les points positifs, Alexis note le soutien d’Oracle à GlassFish, qui dans sa version 3.1 inclue le clustering, ce qu’il ne proposait pas jusqu’a présent et dont Oracle aurait pu se passer avec WebLogic qui propose déjà cette option.

Au niveau communautaire il y a également des progrès, avec l’inclusion d’un JUG dans le JCP et JCP.next (JSR 348) approuvé ce mois-ci.
Le futur de Java, c’est Java FX2, Java 8/9, JavaEE7, et la convergence SE/ME.
Alexis conclue avec humour sur le « real evil plan » d’Oracle : investir, collaborer, encourager l’eco système.

OpenDJ, life after Sun-set

Ludovic Poitou prend la suite : c’est un ex employé de Sun, community manager OpenDJ chez ForgeRock, fork OSS de OpenDS.

Photo par Emmanuel Hugonnet

Quel est le modèle rêvé du projet oss : démarrer un projet seul, être rejoint par une communauté et commencer à gagner de l’argent avec. Modèle qui n’est pas le reflet de la réalité, si l’on en croit le rapide sondage dans la salle !
OpenDS a commencé par une volonté de réécrire SunDS et de l’open sourcer : stratégie un peu suicidaire qui sabotait la propre ligne de produit de l’entreprise, mais Sun était capable de faire ces choix. 30 personnes pour faire le développement, mais seulement 3 contributions externes en 4 ans. Ludovic nous montre les métriques de téléchargement au cours du temps, avec en parallèle les téléchargements réels (par ip) qui sont bien plus réalistes (et aussi plus faibles  évidemment).
Le rachat par Oracle va changer la donne : pas de volonté de poursuivre le développement d’OpenDS, mais le produit est conservé “ouvert”. Avec quelques personnes, Ludovic a forké le produit, ainsi est né OpenDJ et ForgeRock. ForgeRock est 100% OpenSource et spécialisé dans la gestion des identités (OpenAM, OpenIDM…). La communauté migre peu à peu vers OpenDJ, malgré seulement 4 développeurs. Déjà plus de contributions externes en un an que durant la vie d’OpenDS, il semblerait qu’une petite équipe de développeurs facilite la contribution en « effrayant » moins les contributeurs qu’une grosse équipe lancée à plein régime. Les challenges : rebatir une communauté, faire connaitre OpenDJ, réécrire la doc. Beaucoup de releases (tous les deux mois), beaucoup de bugfixes, OpenDJ est prêt pour la production. On a quelques chiffres sur 3 sociétés qui ont souscris à l’offre support : plusieurs millions d’utilisateurs, jusqu’à 200000 sessions parallèles, toutes utilisent de 6 a 12 serveurs.
Pour conclure, Ludovic explique qu’il n’y a pas une seule voie pour faire de l’OSS, trop de ressources fait peur aux contributeurs externes potentiel, alors que la participation est un reflet de l’ouverture.

Projet ALERT

Photo par Julien Ponge

Clara Pazuela nous parle de la façon de faire de l’OSS a ATOS :
– beaucoup de développeurs, qui communiquent par chat/mail et ne parlent pas tous anglais.
– Beaucoup d’utilisateurs qui rapportent des bugs mais peu de code.
Les bugs même très simples peuvent prendre très longtemps a être corrigé avec beaucoup d’interactions entre différentes personnes (mailing list, irc, forum, bugs liés…). ALERT est destiné a faire un “bus” qui centralise les informations, et fonctionne en publish/suscribe entre les sources d’informations et les consommateurs, avec un des informations sémantiques. C’est un projet de recherche soutenu par l’UE et dont le développement n’a commencé que depuis un an et pas encore releasé ou open sourcé.

Involvement of software engineering companies in OSS contributions

Jerome Petit, travaillant chez SERLI et JUG Leader du PoitouJUG nous parle des contributions OSS dans sa société et de l’impact que ces contributions peuvent avoir.

Photo par Orianne Tisseuil

SERLI c’est 65 personnes, beaucoup de Java et 10% du temps consacré à l’OSS. Ils offrent du temps pour contribuer aux projets OSS, de quelques jours à plusieurs mois sur différents projets (GlassFish, Sonar pour les produits d’éditeurs, Selenium, Jonas pour les produits communautaires, ou même Ceylon, le nouveau langage JVM de RedHat). La contribution va du bugfix à la core feature, parfois guidée par le besoin ou l’envie d’ajouter des fonctionnalités ‘bleeding edge’.
Cela change plusieurs choses dans leur entreprise :
– organisation : cela amène de la visibilité, de la crédibilité avec des speakers dans les grands events, des articles de blogs etc…
– business : il est plus facile de convaincre des clients, des missions plus pointues, de nouvelles opportunités (développer l’i18n pour Sonar, payé par les clients de Sonar). Les développeurs impliqués dans l’OSS sont très rapidemment visibles et demandés. Depuis l’ajout de l’OSS  le CA a plus que doublé en 5 ans, et  la part de Java dans l’activité a explosé.
– personne : pas de meilleure école de code que l’OSS, différente culture, motivation des développeurs et développement de leur potentiel.
C’est un cercle vertueux : contribution -> credit/visibilité/skills -> clients -> plus de revenus/recrutement de meilleur qualité -> contribution.
Il faut savoir garder un équilibre entre business et oss, faire les bonnes contributions, en respectant les différentes règles d’un projet ciblé, sa roadmap etc… Les core features sont les plus intéressantes et motivantes.
Pour SERLI, les retombées valent largement les investissements.
Très bon talk, inspirant sur la façon de faire du business et de l’OSS et comment les deux peuvent se marier et s’enrichir.

Opensource & Business at Cloudbees

Nicolas de Loof, employé de Cloudbees et JUG Leader à Rennes nous parle également de marier le plaisir et les affaires

Photo par Jerome Petit

Il commence par l’histoire de Jenkins : commencé en 2004 comme un projet perso par Kosuke Kawaguchi, qui a rapidement gagné une communauté. Les releases sont très fréquentes (1 par semaine) , les contributions très simples, extensible par plugins (dont le nombre augmentent toujours). Petite comparaison des stats Hudson/Jenkins histoire d’enfoncer le clou!
La communauté de Jenkins est une SPI : Software in the Public interest, différente d’Apache, qui permet de diriger son projet simplement, avec un board constitué de différents acteurs (Cloudbees, Cloudera, Yahoo).
Différents modèles sont possibles pour faire du business et de l’oss :
– Double licence, principalement supporté par une entreprise, CLA à signer pour contribuer, suit une roadmap commerciale (SpringSource, Sonatype) -> pas vraiment OpenSource, difficile de contribuer, pas pour Jenkins
– Support et service : ce qui est fait sur toutes les versions de Jenkins
– Formation (aussi pratiquée à Cloudbees)
– Version Pro : plus stable, sécurité, virtualisation (aussi pratiqué à Cloudbees)
– Hosting : avec le Saas Dev@Cloud
Cloudbees est parti de Jenkins pour bâtir toute une plateforme de services à la demande (Repo de code, Sonar, XWiki …) pour obtenir une forge logicielle complète. Si le sujet vous intéresse, les slides et l’enregistrement de Sacha Labourey (CEO Cloubees) sont disponibles sur le site du JUG et sur Cast-it.

From a legacy proprietary application to a modern libre solution

Emmanuel Hugonnet, travaillant chez Silverpeas et JUG Leader à Grenoble conclue la matinée.

Photo par Jerome Petit

Le projet Silverpeas a démarré en 99 avec 40 développeurs, en Java 1.2 et Weblogic. Après quelques années, le développement devient difficile : trop de bugs, pas assez de tests. Emmanuel est alors embauché pour ouvrir le projet et le ressuciter. Emmanuel nous explique les différentes étapes :
– Changement de licence
– Problème du build (1/2 journée) -> standardisation avec Maven
– Gestion des sources CVS -> SVN -> Git
– JPA2, migration vers API REST
– UI plus sexy avec GWT
– Ecrire moins de code, simplifier la communication entre modules.
Maven et Git est un combo gagnant et donne de la flexibilité et reproductibilité. L’utilisation de Jenkins et de Sonar les a également aidé pour améliorer la qualité du code.
Les résultats sont visibles : le projet évolue plus rapidement et simplement, moins de régressions, plus de plaisir à coder pour les développeurs. Le tout accompagné de musique !

Une matinée sympa autant pour les talks que pour les échanges en off entre passionnés d’open source, avec une organisation très bien réglée.

Allez, c’est pas tout ça, mais j’ai des patchs à proposer moi.

Getting Started with Hadoop : Part 1

Disclaimer : Ce billet est la première partie d’un article écrit pour la revue Programmez qui est en kiosque ce mois de Septembre  (n°144) et traite de la technologie Hadoop (une petite pause au milieu de la série consacrée à Node.js).

Avez vous déjà essayé d’indexer le web ? Non ? Et bien Google l’a fait, et le fait tous les jours. En quasi temps réel. Grande nouvelle me direz vous, on le sait depuis longtemps ! Mais ne vous êtes vous jamais demandé comment ? Avoir les plus grandes fermes de serveurs et embaucher les cerveaux les plus brillants ne suffit pas : il s’agit aussi de faire ça intelligemment ! Comment effectuer des traitements sur un ensemble de données de cette taille? La firme de Mountain View a partagé quelques uns de ses secrets en Décembre 2004 dans un whitepaper nommé “MapReduce: Simplified Data Processing on Large Clusters”. Un nom un peu barbare pour dévoiler les principes d’un algorithme simple, MapReduce, pour traiter des données sur des clusters de machines, mais sans en révéler les détails d’implémentation.

Qu’à cela ne tienne, quelques passionnés, Doug Cutting (créateur du projet Apache Lucene, un moteur d’indexation de documents) en tête, se mettent à réaliser une implémentation open source de MapReduce : Apache Hadoop était né ! L’objectif est alors pour Doug d’accélérer un autre de ses projets open source, le projet Apache Nutch, un moteur d’indexation web. Après quelques temps, une version de Nutch basée sur ce qui deviendra Hadoop, est rendue disponible. Et elle se révèle bien plus rapide et simple que la précédente. Yahoo pressent l’intérêt de la chose et va alors employer Doug. Ce dernier et une équipe travaille à plein temps sur le projet Hadoop (nommé d’ailleurs avec le surnom du jouet du fils de Doug, un éléphant qui est aussi devenu le logo). Aujourd’hui la détection de spam et l’indexation des sites web chez Yahoo se basent sur Apache Hadoop, dont la première release date de 2008.

Intérêt

Hadoop ne se destine pas à être utilisé en temps réel, c’est un outil qui vous permet d’effectuer vos traitements batchs. Il se base sur l’algorithme MapReduce afin d’effectuer le traitement de vastes volumes de données sur un serveur ou, et c’est toute sa puissance, sur un cluster de serveurs. Ce n’est pas une solution de stockage de données, et Hadoop ne s’inscrit donc pas dans la mouvance NoSQL, même si on les retrouve souvent associés en pratique (car pour traiter de grandes quantités de données, il faut déjà les stocker et c’est là que NoSQL a tout son sens). Ceci étant dit, quel intérêt pour vous et moi qui ne sommes ni Google, ni Twitter et qui ne possédons pas une ferme de serveurs ? Tout d’abord avec le prix de l’espace de stockage qui diminue, on serait bien tenté de stocker de plus en plus d’informations dans nos applications (de la donnée texte à la photo ou vidéo), et, pour les traiter, d’utiliser quelques serveurs au lieu d’un. Voire même d’utiliser la puissance du Cloud pour le faire grâce à son prix dérisoire, Amazon par exemple permettant de louer un serveur pendant une heure pour 0.085$. Ou peut être pour gagner en vitesse de traitement : au lieu d’acheter un magnifique serveur octocore, peut être que vos deux vieux serveurs qui prennent la poussière viennent de retrouver un intérêt…

Principe

Mais sur quoi repose ce modèle de traitement des données ? Tout s’articule sur le découpage de vos programmes en deux parties distinctes dont les exécutions vont être successives : la phase ‘map’ et la phase ‘reduce’. Le mapper est là pour filtrer et transformer les entrées en une sortie que le reducer pourra agréger une fois la première phase terminée, aboutissant alors au résultat souhaité, que ce soit un simple calcul statistique ou un traitement métier plus complexe. Ces deux phases ne sont pas issues de l’imaginaire des développeurs, mais bien des retours terrains constatés par les Googlers qui travaillaient sur ces problématiques.

Chaque phase est en fait une simple méthode, écrite en Java ou éventuellement dans votre langage préféré (Python, Ruby…), de traitement de données à implémenter. Lors de la première phase, MapReduce reçoit les données et donne chaque élément à traiter à chaque mapper (sur chaque noeud de votre cluster, soit de 1 à n machines). A l’issue de cette phase les données traitées sont redistribuées à chaque reducer (idem, chaque noeud de votre cluster, de 1 à n machines) pour arriver au résultat final.

Même si parfois découper votre traitement en deux phases vous semblera non trivial, une fois cette étape réalisée, passer l’exécution de votre programme sur un cluster de n machines ne sera pas plus compliqué qu’un changement de fichier de configuration. Quand vous écrivez votre programme en suivant le modèle MapReduce, Hadoop se charge ensuite pour vous de passer à l’échelle supérieure.

Si nous n’utilisions pas un framework comme Hadoop, nous devrions aussi écrire une fonction de partitionnement pour répartir les données entre les différents noeuds, une autre méthode pour les redistribuer entre les deux phases, gérer le load-balancing, les possibles échecs de traitement, les inévitables pannes matérielles serveur, etc… Beaucoup de travail pas forcément passionnant !  Mais Hadoop se charge là aussi des tâches ingrates et les optimise probablement mieux que ce que nous aurions pu faire. En résumé, écrire un programme Hadoop est donc aussi simple qu’écrire une méthode Map et une méthode Reduce, et à vous la scalabilté !

Dans un programme MapReduce, aucune valeur n’est traitée sans une clé associée. Les fonctions map et reduce ne reçoivent pas de simples données mais des paires (clé, valeur). Même chose pour les données sortantes des fonctions. Le mapper peut produire 0, 1 ou n couples (clé, valeur) pour un couple (clé, valeur) entrant. Le reducer, lui, va réduire une liste de couples (clé, valeur) produite par les mappers en une seule valeur par clé.

To be continued : si vous êtes impatient, foncez au bureau de presse le plus proche. Sinon je mettrai en ligne la suite dans quelques temps. Ce numéro de Programmez contient également un article de @AgnesCrepet, mon amie JDuchess, sur le BDD (si vous ne savez pas ce que c’est vous avez deux bonnes raisons d’acheter ce numéro). Et c’est un très bon article, écrit avec Mauro Talevi, commiter JBehave, je ne le dis pas juste parce que c’est une amie!