Réussir sa présentation à Devoxx France par Nicolas Martignole sur Vimeo.

3 jours, avec donc un format 1+2. Le mercredi sera consacré à la formation, avec des sessions de 3 heures en matinée (University) et des sessions de 30mn à 1h l’après-midi. Si vous voulez +20 en Level « Développeur » en quelques heures, cette journée est importante. Jeudi et vendredi : le matin nous aurons des plénières, par des conférenciers prestigieux. L’après-midi : des conférences d’une heure. Le soir : tu seras sur une table avec des multi-prises. Peut-être que tu iras faire une « BOF »(Bird of a Feather) afin de croiser les gars du NoSQL User Group, la communauté des développeurs Android ou encore les gars du ParisJS… Bref tu auras une vie sociale de développeur. Et ne fais pas l’erreur de rentrer chez toi à 18h, tu louperas le meilleur.

Le prix mon ami : 350 EUR HT pour les 2 jours. C’est un prix que votre entreprise doit investir. Notez que je dis « investir« . Si vous pensez « payer, dépenser » vous n’avez pas compris en quoi consiste une conférence. C’est tout à fait normal : à Paris nous n’avons pas encore révolutionné le monde et le regard du développeur. Si vous pensez « c’est cher » c’est que vous auriez préféré que la conférence soit gratuite. Je vais vous dire un secret : c’est peut-être faisable. Par contre, nous serons obligé de vous imposer des présentations effectuées par des sociétés, que nous n’aurons pas sélectionné. Comprenez quelque chose : le prix d’entrée que votre entreprise paye est la garantie de l’indépendance. Grâce à votre ticket d’entrée, nous pouvons dire oui ou non aux sponsors. Au final c’est bon pour vous, c’est bon pour le contenu et c’est comme cela que Devoxx fonctionne.

Comment venir gratuitement ? Devenez speaker. Si votre présentation est retenue comme Conférence, University ou Tools in Action, vous recevez un badge speaker valable 3 jours d’une valeur de 450 EUR HT. Pour cela, réfléchissez à un sujet qui vous intéresse, commencez à travailler votre présentation, et dépechez-vous de soumettre un sujet sur le site cfp.devoxx.com en Français. Un comité de sélection de 12 indépendants est chargé du programme de Devoxx France. Vous saurez fin février si votre présentation est retenue ou non. Soyez imaginatif, allez sur le site www.parleys.com pour voir des présentations de Devoxx 2011. Il est important de comprendre comment et quoi présenter à Devoxx. Si vous pensez débarquer avec vos slides et nous faire de l’enfumage, prenez votre deuxième doigt, posez le sur la paupière, et poussez très fort jusqu’au coude : vous vous mettez le doigt dans l’oeil. Devoxx c’est juste la crème du top de la chantilly des speakers. Il y aura 50 présentations en Français et une vingtaine en Anglais. Pour la version Anglaise, nous allons avoir d’excellents speakers qui viennent des USA et d’Angleterre, qui travaillent chez Google, LinkedIn ou JBoss RedHat par exemple.

Si vous voulez être speaker, il y a aussi l’opportunité de faire un Quickie (15mn). Voyez où j’en suis, pour moi Devoxx en 2008 c’était le petit Nicolas dans une salle de 600 personnes, avec le trouillomètre à 100%. Mais quel pied, quel plaisir de se jeter dans le grand bain et de se dire : « ouais, j’ai fait une présentation à Devoxx ». Et du coup, dans 3 ans vous serez à l’aise pour faire des présentations. Un gars de Salesforce ou de Google viendra vous voir et vous dira « We want you ! ». Vous vous ferez graver « Devoxx France 2012″ sur le bras en souvenir de ce passage… Bref tentez le Quickie, il est plus facile d’être retenu et c’est très fun.

Pourquoi venir à Devoxx France 2012 ?
Tout d’abord, c’est l’occasion de rencontrer des personnes. Avant de s’assoir dans une salle et de baver devant Matt Raible ou Joshua Bloch, vous pourrez socialiser avec d’autres personnes. Vous verrez : vous n’êtes pas seul. En fait, nous sommes très nombreux. Et nous sommes de plus en plus important dans le monde de l’entreprise car nous avons une compétence sur le CV qui vaut de l’or : nous sommes passionnés.

Soit un numéro IBAN simple, présenté sous la forme d’une grosse chaîne de caractère :
FR7630057410821012122045021

Comment l’afficher à l’écran en le formatant de cette façon ?

FR76 3005 7410 8210 1212 2045 021

Voici un premier bout de code écrit en juillet dernier par votre serviteur :

val iban="FR7630057410821012122045021"

iban.zipWithIndex.map{p=>p match{case(t,idx) if (idx+1)%4==0=>{print(t+" ")} ; case(t,idx)=>{print(t)}}}

// si, si ça marche

Et voici le même code après avoir lu la doc et aussi après avoir vu un email sur la liste du Scala User Group :

for(p < - iban.sliding(4,4).toList){ print(p+" ")}

Conclusion : lisez la documentation avant de vous lancer dans des "expérimentations" pour dire ensuite "dans skala' c'est compliqué". ]]> http://www.touilleur-express.fr/2011/12/08/le-gars-qui-connait-scala-et-celui-qui-debute/feed/ 36 http://www.touilleur-express.fr/2011/11/26/le-cloud-mythe-ou-realite-par-sacha-labourey/ http://www.touilleur-express.fr/2011/11/26/le-cloud-mythe-ou-realite-par-sacha-labourey/#comments Sat, 26 Nov 2011 14:11:35 +0000 Nicolas Martignole http://www.touilleur-express.fr/?p=5948 Xebia passe la seconde, en organisant presque chaque mois des ateliers ou des soirées autour du Cloud. Rendez-vous pris donc mercredi dernier non pas pour aller dans le Cloud mais au 7ème étage chez Xebia France. Sacha Labourey, CEO de CloudBees et François, présentent le Cloud et les solutions de Cloud Bees. Cyrille Le Clerc, l’un des deux responsables techniques de Xebia France, avait bien préparé la soirée. Tout d’abord une présentation assez générale par Sacha, puis une bonne heure de discussions et de débats, animés avec des questions, que j’ai aussi embarqué pour pouvoir écrire ce billet (bon en fait Cyrille me les a donné).

Sacha Labourey ouvre la soirée. Ancien CTO de JBoss, futur speaker à Devoxx France 2012 et accessoirement Suisse de son état, il est venu accompagné de François Déchery, VP of International Business Development. Ils sont co-fondateurs de la société Cloud Bees.

Le Cloud en ce moment, c’est tout d’abord beaucoup de commentaires et aussi beaucoup d’émotions dans le sujet. Les changements et la rupture d’architecture et organisationelle sont importants. Ce sont des changements fondamentaux. Ce soir, Sacha va simplement démontrer les changements qui nous attendent. Le futur est quelque chose que l’on ne voit pas, mais que l’on créé.

Sacha s’arrête sur quelques idées pour ancrer son discours. Par exemple, votre enfant ne vous a-t-il jamais demandé pourquoi les vieux téléphones ont des fils ? Ma fille de 4 ans par exemple a découvert la cassette VHS chez les grand-parents, mais elle appelle cela un « gros DVD ».

Imaginez dans quelques années une discussion avec un informaticien. Peut-être qu’il sera étonné d’apprendre que vous développiez en local sur votre poste de travail. En tous les cas, je suis sûr qu’il sera étonné d’apprendre que vous travaillez avec Eclipse (et toc, ça c’est fait…).

Cette évolution et cet impact est comparable dans une certaine mesure à l’arrivée de l’électricité. A la fin du XIXème siècle, le luxe est de générer de l’électricité et de le partager avec d’autres. Les premiers générateurs d’électricité permettent de mutualiser le coût de production d’une ressource. De nombreuses entreprises se créent et l’électricité connait un essor important.

En 1881 Edison présente une génératrice à l’exposition universelle de Paris.

L’électricité connait un essor rapide de 1870 à 1907 à Paris. Le choix entre le continu et l’alternatif et les différents standards rendent assez compliqué s la distribution de l’électricité. Mais à cette époque, peu de bâtiments et de sociétés utilisent l’électricité. Celle-ci n’est pas encore une commodité.

En 1902 on se retrouve par exemple avec un découpage de Paris, où chaque secteur a son standard.

Ce que Sacha explique, c’est que l’informatique aujourd’hui est un peu prêt dans le même état que le réseau électrique en 1900 à Paris. Il existe différents producteurs, il n’y a pas de standards, le consommateur est encore un conso-acteur qui doit s’inquiéter du format, de l’ampérage et du type de courant…

Alors qu’en 2011, une prise standard vous donne de l’électricité. Aujourd’hui, nous avons de la résilience, et il est même possible de changer de fournisseur. Chaque mois, votre entreprise paye une facture d’électricité, comme une simple commodité. Pourquoi ne pas voir dans quelques années la même approche pour l’informatique d’entreprises ?

Sacha Labourey passe ensuite sur les centres de données. Quoique l’on en dise, les data-centers ne sont pas aussi beaux que sur les publicités IBM. Dans les faits, ils coutent chers, ils dégagent de la chaleur et ils demandent de l’électricité. Dans le futur, les lois et la protection des données seront peut-être plus stricte, à un tel point que les entreprises ne seront plus en mesure d’avoir un data-center rentable.

Aujourd’hui, l’informatique c’est de la haute couture : peu de réutilisabilité, peu de services, une intégration assez compliquée, un sentiment de parfois être un Artiste Héroïque plutôt qu’un vague Ingénieur…

Le Cloud c’est avant tout de l’infrastructure, avec au départ non pas des hébergeurs, mais des utilisateurs. Quelle est la société qui gagne le plus d’argent avec le Cloud ? Ce n’est pas un hébergeur, c’est Amazon. Un site qui vend des livres… Et qui aujourd’hui a créé un nouveau business model.

Sacha fait ensuite le parrallèle entre le coût d’un centre de données pour une entreprise, et l’intérêt à moyen-long termes pour une grande entreprise. Cette immobilisation financière n’est pas forcément stratégique pour des entreprises de taille moyenne. Par contre, il l’est pour un Google et un Amazon. La question du Cloud se pose donc avant tout pour les utilisateurs finaux et les entreprises classiques.

Sacha espère que le Cloud Computing sera une commodité, comme l’électricité aujourd’hui. Vouloir faire de la haute-couture pour tout, ce n’est pas rentable. La crise financière actuelle aura même peut-être un effet sur les DSI. Nous pouvons même supposer que les équipes du métier, qui continuent à avoir besoin de l’informatique, n’attendrons pas que la DSI s’en remettent.

Je rêve aussi personnellement que certaines DSI qui ne vivent que grâce à deux ou trois grosses SSII iront se planter rapidement, histoire de laisser la place à une nouvelle relation entre le client, et les gens qui codent, nous.

Sacha termine par une citation à méditer :

If you don’t like change, you’re going to like irrelevance even less.
General. Erik Shineski

J’en ajoute une aussi pour la route et qui colle bien à CloudBees :

“Never doubt that a small group of committed people can change the world. Indeed it is the only thing that ever has.”
Citation de Margaret Mead

Définition du cloud

Sacha Labourey présente ensuite les différents types d’architectures dans le Cloud. SaaS, PaaS ou IaaS, tout ceci c’est pas mal de jargon. Mais il est important de comprendre qu’il y a différentes architectures, pour différents usages.

• SaaS (SalesForce, NetSuite, ZenDesk,HubSpot)
• Paas( CloudBees, heroku, app engine vmForce database.com)
• Iaas (Amazon Web Services, RackspaceCloud, terremark, Eucalyptus System)
• Cloud computing->informatique à la demande, accès à des ressources virtualisées.

Le SaaS : solution assez rigide, c’est l’utilisation du service qui prime sur les principes d’architecture. Le SaaS est particulièrement adapté à l’approche orientée solutions comme SalesForce. Quelque part, votre GMail c’est du SaaS si vous voulez.

PaaS : le Platform as a Service est l’étage où vous pouvez placer CloudBees. Cette couche intermédiaire redonne l’environnement de développement et surtout de production habituel. Les serveurs, les logiciels, la montée en charge sont cependant gérées par la plate-forme. Il y a différentes philosophies selon les vendeurs sur PaaS. Personnellement j’aime beaucoup Heroku pour l’approche orientée production.

IaaS : c’est de l’Infrastructure as a Service. A cette étage de la fusée, vous avez plus ou moins un méga réseau élastique, mais il faut travailler pas mal pour réellement tirer partie de l’IaaS. Amazon Web Services est la solution la plus populaire mais il en existe d’autres.

CloudBees

Alors que fait CloudBees ?

Solution de PaaS, CloudBees gère le cycle complet du logiciel. De la compilation à la mise en production, puis à l’exploitation. Cloud Bees veut devenir le leader de la solution Java pour Cloud. Fort de l’expérience de JBoss, Sacha vise rapidement une place sur le podium, afin d’apporter tout le savoir faire du monde Java Enterprise vers le Cloud.

Cloud Bees c’est aussi déjà un bon nombre d’outils et de services d’entreprises, prêt à l’emploi. Côté développement, vous pouvez démarrer un projet avec une forge logiciel, avec JFrog, Sonar ou XWiki. Côté production, on retrouve des outils populaires comme New Relic ou Mongo HQ. Il y a encore un peu de travail avant de rattraper la liste des AddOns d’Heroku, mais franchement c’est bien.

CloudBees c’est donc 2 ruches distinctes : Dev@Cloud et Run@Cloud. J’en ai déjà parlé sur le Touilleur Express à l’occasion de la présentation de N.De Loof au RivieraDev.

DEV@Cloud est un environnement de développement avec intégration continue basée sur Jenkins, repository Maven privé, et j’imagine rapidement des outils comme bug tracking ou autre.

RUN@Cloud est l’environnement d’exécution de votre application. C’est donc avant tout le moyen le plus simple de déployer une application Java dans le Cloud.

Conclusion

Sacha Labourey a quelque chose d’indispensable : une vision. Loin de la soupe technique, il sait ce que CloudBees doit faire pour réussir. Alors que pas mal de monde s’intéresse aux caractéristiques du Cloud, lui s’intéresse à la finalité et aux futurs services. Cette approche est importante, car certains éditeurs de logiciels empilent les version de leurs logiciels les unes après les autres, mais n’ont pas de mission. Ils ne savent pas expliquer « POURQUOI » leur solution est intéressante. Ils empilent les présentations sur ce que FONT TECHNIQUEMENT leurs solutions, alors que le plus important est de savoir pourquoi elles existent.

Ensuite, CloudBees si j’ai correctement compris, fait le choix de ne travailler qu’avec Java pour l’instant. Pas de Groovy ou de Scala. A voir à moyen-long terme si cela ne change pas.

CloudBees est clairement une solution pour les développeurs Java modernes. Si vous êtes habitué à utiliser Maven, à faire de l’intégration continue avec Jenkins, à faire de la mise en production vers un Apache Tomcat, c’est une solution qui vous fera gagner du temps. Un autre intérêt, c’est que finalement CloudBees abstrait l’IaaS et offre de la fléxibilité sans vous locker sur une infrastructure.

Les concurrents de CloudBees ? Le premier qui me vient en tête c’est Heroku. J’aime beaucoup l’approche différente d’Heroku. Les Add-Ons sont plus nombreux que ceux de CloudBees pour l’instant. Vous pouvez faire du Ruby, du Scala, du Java, du PHP ou du Python… et avec 510 000 applications en production, Heroku n’est pas un petit joueur.

CloudFoundry est assez similaire, et permet déjà de faire tourner autre chose que du Java. C’est surtout une solution open-source. N’ayant pas testé CloudFoundry, je n’ai pas d’avis sur la plateforme.

Il existe beaucoup de PaaS, mais je retiendrai que CloudBees est avant tout pensé et adapté aux développeurs Java.

Et mine de rien, on est 10 millions de développeurs dans le monde.

A suivre donc…

Ressources
Vous pouvez tester et découvrir les solutions CloudBees en version d’évaluation sur leu

Guillaume Bort and Sadek Drobi made two big announcements last Wednesday, 16th November at the Devoxx 2011 conference. First off, Play! 2.0 is available in beta form for download on the Play! Framework web site. Within hours, there were over 4,000 downloads (see Twitter here).
Secondly is that Play Framework is now the official web stack of the Typesafe products, Typesafe being the company created by Martin Odersky, creator of Scala. And last but not least, Guillaume Bort is joining the company’s Advisory Board, alongside James Gosling and Doug Lea.

Nice, hey?

But let’s back to the Devoxx presentation and what I thought of it. I’ll try to not be too enthusiastic, but this will be hard (as I am a Play Framework evangelist as part of my daily work).

Sadek Drobi is Zenexity’s CTO. Guillaume Bort is the co-founder of the company, and the original author of Play! Framework. As Sadek explained, Play! was born because of internals needs for their company, as a secret weapon to rapidly develop Java applications. The framework has been open-source as of the end of 2008. But right from the beginning, it’s was a framework designed for « real-life projects » for « real-life customers ». Not as a project you use to solve non-existant problems.

(Sadek with its hat and Guillaume)

I remember when Play! Framework was presented at a BOF at Devoxx 2009. 2 years later, there’s 3 conferences at Devoxx and one BOF. I’m looking at Devoxx 2011′s schedule, I don’t see any other web framework that had such exposure this week. This makes some of my friends cringe, but it definitely shows the interest the community has for this framework.

Why Play 2.0 ?

Since the beginning, Zenexity worked closely with the community. Play 1.x is now a very popular web framework, being simple and productive. However, adding functionalities is like creating a mega sandwich (or burger… or whatever) : that is, it becomes less maintainable and harder to patch. Plus, there’s a lot of “magic” going on in the core of Play 1.x (Maybe a little too much).

Second point is that meanwhile, the Web is evolving. People, especially in the Java community, are discovering a new world where a stateful approach might not be the only way to build web applications. Sadek and Guillaume say that we can really feel that architectures are changing, and this will have an impact on web frameworks. The very first Web frameworks were based on a static page approach. A single page generated by Perl, PHP or simple Java techniques. And this is still OK… if your content is static.

Web architectures on the server side needed to adapt to be able to work asynchronously with web clients. For instance, Ajax and related techniques like partial page refreshes gave birth to great web applications such as GMail. From a static page view, we moved to a dynamic approach on the server. Web frameworks were proud of this… especially JSF folks. One needs to understand that when usages changes, all web frameworks are impacted. Some are good for AJAX, some suck… I won’t give any names, but you see what I mean.

Today in 2011, the new challenge is easy web service integration and asynchronous processing. On a lot of web applications, you have to be able to link and reuse APIs such as Facebook API, Twitter OAuth, Google OpenID, or maybe your company SSO system that cost a tank… We know that to build a modern web application, the web framework has to be able to glue all these services together. And it has to be able to handle huge amounts of data, and the huge amount of things that can go wrong. Maybe tomorrow, a really good Web Developer will be the person that has a strong knowledge on Web APIs (OAuth, Github API, OpenID), and that is able to create value-added services from these external APIs.

From a technical point of view, Sadek explains that the Java Servlet API is very limited. We hope that Java EE 7 will propose a more modern approach. Java Servlet is just too… low-level. One important issue is that it’s impossible to split a task and configure threads, memory and CPU in a Web application. If you visit a page, you go through a Servlet. If you upload a file, another Servlet. Wouldn’t it be interesting to route the content in your application (and not in a crappy “web.xml”) and really focus on the business part ? It’s not normal that your application’s home page can blow up if someone else starts uploading a large file in another part of your application.

Web frameworks have been created to be the central point of the architecture, whereas Sadek and Guillaume think that being Client-focused (as in, clients of your application) and having an adaptive server are more important.

Basically, “server” should be written with a lower-case “s” and “Client” with an upper-case “C”.

What is also important to keep in mind is that the amount of data and the flow of data between Clients (browsers, other web apps, your iPhone…) and the server are evolving at a very fast pace. It’s not at all easy to write concurrent code, and this was something that Play 1.x was not designed for. Play 2.0 is not here as an evolution or replacement of Play 1.x. It’s here because we’re moving forward, baby. We have to adapt and be ready for these new kinds of applications we haven’t thought of before. You see what I mean ?

Sadek Drobi goes on to say that when a Java developer creates an application for the Web, he tends to have a sort of “automatic behaviours”. The first one, regarding the datastore, is to pick an ORM. And this is stupid. What for ? Because you can forget SQL ? ORM are a perfect tool… when you need it. And no, you don’t need an ORM every time, every where.

Take a look at your application. First, do you use honestly use advanced relational mapping in the database ? Yes ? And is it really useful ? How much time did you lose on Play 1.x with @OneToMany, @ManyToOne, @MaybeOneOrTwoToTooMany annotations ?

On the client side, especially in the browser, we have also new web technologies that ease the web app development. Personally (and I usually blog about this in French), I think that if you (yes, you there in the back) don’t want to learn HTML/CSS/HTTP, then you are in serious trouble. OK, let me be honest : you suck. Either learn basic web stuff or go back to your Cobol stuff.

Now, back to the presentation. So we have these new tools such as Sass, CoffeeScript, Less or jQuery. Guillaume explains that it would be also interesting to integrate these tools in Play 2.0 so that you get compilation and validation for CoffeeScript or Sass, for instance.

In a sense, Play 2.0 was born because they (Sadek and Guillaume) wanted to create not a v2 of Play, but a v2011 version of it. Something that is more mature, less magic, more type-safe, more solid. Something that is able to handle all the new use cases they talked about.

This is important point : Play 2.0 is more of a whole new framework that just an evolution of Play 1.x.

When we explain what is Play! Framework to someone for the very first time, especially to Java developers, we present it as a full-stack framework. You write java code in your editor, you switch to your web browser, hit refresh, and it works.

Java developer : No more console and maven hell. Play 1.x relies on Eclipse’s IDT compiler, the one we’ve been using for years : it just works.

Java developer : No more crappy logs in a console Play 1.x reports errors in the web browser. If there’s a compilation error, well, you see it in the browser. Forget about looking at logs files like a teenager with an adult magazine : no more logs.

What is also important is that Play 1.x is not a stateless web framework, but a « framework sans état conversationnel du côté serveur » wich translate into English as « a framework that respects web standard, has no conversation, thus no state on the server, as HTTP is from the beginning… »

The code editor and a web browser. That is all you need to work. Even better, you can use VI/Emacs/TextMate or any basic text editor, since all the work is done by Play! Framework. However I recommend IntelliJ for its good web support (JS/HTML/CSS/Java/bla bla bla).

Guillaume worked really hard to keep exactly the same spirit in Play 2.0 : productive, simple, no logs for dummies, no maven/gradle stuff, no xml… just being productive (and having fun, but that is another story).

Play 2.0 is a web framework that is able to compile, deploy, download dependencies, launch asynchronous jobs, runs tests, send emails and even (but we’re not 100% sure about this feature) prepare a good coffee if you need it.

Démonstration

Guillaume did a good demonstration of Play 2.0. Firstly : no more Python for the tooling and no more Groovy for the templating (compared to Play 1.x). Play 2.0’s engine is Scala. But hold on… don’t run away… no, you won’t have to learn Scala. You can write your code in Java or Scala, Play doesn’t care. The template language is Scala. But it’s very simple and there’s only a few tags to learn. It took me 1 day to understand how it works. And I’m happy to be able to do advanced stuff with Scala, when needed, in the view.

For Java, Guillaume removed Hibernate and took Avajé EBean. It’s a lightweight stateless ORM, that is less powerful than Hibernate. But it’s perfect for Play, it’s JPA compatible if I’m remember correctly. For the Scala part, Sadek implemented a simple SQL engine called Anorm. I started to use Anorm in May, spent some time with Sadek in August to fix some bugs, and I like it. Simple, easy to learn, not too much « scaletist » and just fine for a Scala beginner like me. You can also use some other Scala/SQL libraries such as ScalaQuery : it’s very easy to flip from one lib to another.

The very first characteristic of Play 2.0 is that it’s based on SBT, Simple Build Tool. As you can imagine, SBT is now the one in charge of dependencies, incremental compilation, tests, packaging, documentation and maybe (but not sure about this one) preparing a good coffee. It’s even easy to launch SBT and import Play commands into SBT. You also get tooling support for Eclipse and IntelliJ with SBT.

The template engine is new in Play 2.0. This is maybe the biggest difference between the 2 versions of the framework. I know that one of the Play core developer is working on porting the Groovy engine to Play 2.0. It will work, but does it makes sense ? Not sure about that.

Templates are HTML files with very little Scala code in them. Everything is strongly typed. Less errors, more validation at compile time, and maybe fewer tests since there’s less dynamic in the code. Each page declares the list of parameters, everything is transformed to Scala then compiled to byte-code. In terms of performance, the new template engine is 15 times faster than the previous one.

One important point : in order to write a view page with Play 2.0’s new template language, you don’t have to be a Scala Jedi Master. The syntax is easy to learn, and you have access to the power of Scala when needed. I also think that this is a good way to discover and learn Scala, if you only use Java for the controller side.

I had a really nice use-case recently, where Scala was really powerful. I wrote a Contact application. There’s a web page with a list of people ordered by last name. Here is an extract of one of my templates for Play 2.0 :

Play 2.0 in details

Sadek and Guillaume then go on and explain what is really new in Play 2.0. First, existing solutions in the Java world suffers from a very low-level approach. Let’s say you want to implement a file upload functionality. With the traditional approach, based on java.io.InputStream, it’s very complex to correctly write an application that does not block on I/O. The read() method in InputStream reads one byte after another. This is OK if the server is able to handle the reception of the byte stream. However, it tends to create resource deadlocks, where the server hangs and does not respond to incoming requests anymore. Sadek, who is also a very good Haskell developer, explains that they decided to adapt the Enumerator and Iteratee pattern in Play 2.0

Play 2.0 has a completely new approach, it applies inversion of control on the way the controller and the client exchange information. What is really awesome is the way it handles an incoming request. First, in the connection layer, Play 2.0 is like Play 1.x : a single thread listens for and dispatches any incoming requests (just like Node.JS, for instance). The request is then dispatched to either a limited pool of workers. If you annotate a part of your code in the controller with the @Asynchronous annotation, Play is then able to suspend your request, thus freeing one thread, while an asynchronous activity does something. Enumerator and Iteratee is a nice pattern where the asynchronous task tells the Enumerator when it completes its work, and that it can resume. It is much more efficient than the classical Future + Pooling approach we had in Play 1.x. And this is also why you now understand that Play 2.0 doesn’t care about the Servlet API, it just wouldn’t be able to work like this.

An Enumerator sends data to an Iteratee. The Iteratee executes a function, does something, and sends a signal back to the Enumerator with a status. See also the Continuation passing style » that is explained in Haskell documentation.

Well, you may say : why is this interesting ? Why should I care ? Well my friend, now you can start to write asynchronous web servers « à la Node.JS » (this is French) but with Scala or Java. Play 2.0 is much more functional. The code is easier to read, it’s also easy to split up long processing operations to speed-up your server.

To orchestrate everything, Guillaume and Sadek decided to use Akka. It’s a very powerful and simple Actor-based framework. I wrote an application for a startup, where we had to post-process uploaded images and generate PDFs : Akka is great. The code is easy to test, there’s no middleware stuff, ant it’s simple and very easy to develop in.

Akka is a powerful tool that lets you write asynchronous code very easily in your application. What I particularly like about it is that the thread pool and all the general fine-tuning is managed outside of your code. If there’s a new framework you need to look at, definitely check out Akka. Great tool.

Here is a sample from Play 2.0 that Guillaume showed at Devoxx. The search function receive a keyword. The AsyncResult is interesting because it tells Play to handle the code as an asynchronous function. While the search operation is done, the server frees up the resource and let the system handles another request. The Iteratee pattern is then used : when the search result is available, the html.results template is executed to generate the HTML response. The double-bang (!!) means : send the « keywords » to the searchInternet’s Actor. As you can see, the searchInternet could be anything, there’s no functional code here.

def search(keywords: String) = Action {
	 AsyncResult {
		(searchInternet !! keywords).map{
			found => Ok(html.results(found))
		}
	}
}

Sadek talked also a little about the data layer in Play 2.0 : either a relational database or NoSQL databases like MongoDB, etc. Play 2.0 does not try to hide the fact that there’s a data layer in your application. If you want to use Neo4J or PostgresSQL, well you can.

In Play 2.0, Guillaume decided to drop Hibernate 3 in favour of EBean. Why ? Well, Hibernate is a great tool and all, but it’s just too powerful for what we usually need for Play. It was really hard to set up the asynchronous part with Hibernate sessions. On the other hand, the java community really wants an ORM in Play for the Java part. EBean is simple to use, and offers good compatibility. There’s also some Spring 3 in Play 2.0 for the Bean binding and JSR-303. So EBean is simpler and better-adapted to Play 2.0.

For Scala, Sadek wrote Anorm (An Not ORM). Based on Scala’s complex parser, it’s a very simple parser technology that removes the JDBC boilerplate and offers a nice match/case engine. But if you don’t like Anorm, you can use ScalaQuery or whatever your favorite Scala technology is.

Guillaume also demonstrated that Play 2.0 is bundled with support for client-side tools such as CoffeeScript, Less or SASS. Play is a full stack framework. So it will compiles your CoffeeScript to Javascript. And last but not least, it is also capable of reporting errors in a CoffeeScript page for instance. This is just great.

With regards to “Cloud computing” support, Play 2.0 works on Heroku and soon, will also work on CloudBees.

Thanks to Akka, it will also be easy to distribute a work on multiple Play Servers. For instance, it will be possible to have a Play server as some sort of Front controller, that dispatches to another Play Server the « Image resize » operation (for example), and to another server the « Generate a PDF »… I don’t know if you realize how powerful this is. It will be easy to split up and create a flexible architecture. Something Java J2EE tried to sell 8 years ago.

The actual Play 2.0 core is not very complex. I spent a day with Guillaume and was able to understand how it works. In fact, there’s x4 less code. It’s thus easier to find your way around in your code.

On the performance side, Play 2.0 is 2 to 3 times faster than Play 1.x. On a MacBook Pro with an i7 processor with 8 cores, a simple Apache bench command shows that Play 2.0 manages just fine 40 000 requests per seconds. The network stack is JBoss Netty, one of the most powerful stacks for Asynchronous NIO in Java.

On the memory footprint side, their tests show that after a full GC, the heap is back to 2 MB…

Personally, if I have a negative feedback to give, it’s that the compilation is much slower with Scala. You lose the very quick turn-around/compilation experience we had with Play 1.x. Yes, it’s slower. Scala being more complex, it takes more time to generate the code and compile it.

Type safe

Play 2.0 also brings strong typing to the HTML template part. The first reflex is : damn, I prefer the groovy way. But bit by bit, I moved to Scala and started to really appreciate the type safe template engine.

The « routes » file is also compiled. Everything is compiled in Play 2.0. This is less error-prone. If you update a function in your controller and you forget to rename it in the “routes” file, Play will properly report the error. No more « 404 What the hell » exception.

To wrap things up, Guillaume did a nice presentation of the 3 applications they wrote in September. You have a complete CRUD application, an advanced HelloWorld and a complete application with authentication. I was happy to see that Guillaume took into consideration a suggestion I had back in September : don’t bother to give a stupid helloworld example. Give me a real application so that I can start to learn the framework, see how to set-up authentication, start to read some nice code… And please : no pet-store and no stupid hotel booking application.

By the way, dear reader, did you know that the Pet-store was actually a joke ? The idea to create a Petstore was suggested by a guy at 4:00 am after too many beers at SUN. Stop and think about this for a minute : would you really buy a bird on the Internet and have it shipped in a little box ? Come on… You can’t be serious… But apparently nobody was really surprised and we still believe that we can buy birds with a J2EE application… Ah ah ah.

What you won’t like in Play 2.0

Now my friends, let’s me be honest : Play 2.0 is not for dummies. A lot of people want to port their code and every day, they post a bunch of questions about migration patches and yada yada yada on the mailing-list. The question is : do you really need to migrate ? Do you really need to use Play 2.0 ? Maybe ya do, maybe ya don’t.

The templates are different, but it’s not too hard to port your code. The controller side is completely new. You can write it in Java or Scala. So don’t be scared : you don’t have to be a Scala developer (yet).

Play 2.0 was created to solve new issues and new architecture patterns. It’s more like a cousin than the little brother of Play 1.x.

However, and please read this carefully : Play 1.x is a community project and will be maintained by its core contributors (Guillaume Bort, Nicolas Leroux from Lunatech, Peter Hausel, Morten Kjetland, Erwan Loisant, Peter Hilton…). Zenexity has a lot of customers with live apps in production using Play 1.x. So Play 1.x is here to stay and is still a very interesting solution to look at.

If you want to learn Scala, Play 2.0 is really a great tool. I started to learn Scala in May with Play 1.x and play-scala, and it took me one month to start, maybe 2 months to really understand Scala and appreciate the language. As a Java developer with no functional background, I really like this language. Less verbose and not that hard to learn. Don’t be afraid of the fact that there’s are some hippie-guru-functional-heretics that talk about Scala like it’s their girlfriend. If you’re just a java developer, trust me : it’s easy to learn and to work with. Don’t give a shit about people that try to look smart with « Monad or higher-order function ». Soon you will be writing more Scala code than those pseudo-evangelists ever have…

One important point is that Play 2.0 is more like a new framework. If you want to write rock-solid applications and you need asynchronous/flexibility, then Play 2.0 is your guy.

I talked with Guillaume and at one point, I suggested that they change its name of the Framework to Play² ([plèy square]).

But we will keep Play 2.0, that’s already a big evolution.

Other interesting and great resources:
- Play 2.0 official web site
- Another great article by Matt Raible. I hope to see him in Paris for Devoxx France 2012
- James Ward also wrote great articles about Scala, Play and Heroku
- Play! Framework also has a Twitter account : @PlayFramework

This article was reviewed by Roland MALAPRADE (@rmalaprade).

Nicolas Martignole is a freelance developer. He lives in France, in Paris. He is a Play evangelist. He created the eXpress-Board, a job board for enthusiastic developers, with Play 1.2. He is also a member of the Paris JUG team and he’s one of the 4 crazy geeks that decided to organize Devoxx France, a conference for developers created by freelance developers, from the 18th to the 20th of April 2012. You can follow him on Twitter @nmartignole.

Original article in French here.

Emmanuel démarre avec l’exemple d’un indexer de fréquences d’apparition des mots. Quelques lignes unix avec des pipes, finalement on peut par analogie expliquer le fonctionnement de Map et Reduce en quelques lignes.

Une fonction de Map prend en entrée une partie des données, et en sortie retourne une collection de paires clé-valeur. La tâche Reduce va prendre en entrée toutes les valeurs pour une clé et va retourner le résultat final.

La tâche Map doit pouvoir s’exécuter en parrallèle en étant capable de traiter de manière indépendante les données. La tâche Reduce doit agréger les données d’une seule clé. Cela permet de distribuer le traitement.

En pratique, la distribution est est effectuée via HDFS, le file-system partagé d’Hadoop. Un fichier est découpé en bloc de taille fixe de 64Mo. HDFS est donc efficace avec des gros fichiers de données. Chaque bloc de votre fichier est alors alloué sur un data node. Le Name node sert à reconstruire l’ensemble du fichier. Mais attention, HDFS est un système distribué qui cependant ne fait pas de la haute disponibilité. En effet, ce Name Node est un SPOF (Single Point Of Failure).

Concernant la gestion des Jobs, JobTracker et Task Tracker permettent de synchroniser les traitements.

L’API Java d’Hadoop est en Java. Ecrire finalement pour Hadoop est simple. Vous implémentez une class avec l’interface Mapper, une autre classe avec l’interface Reduce, vous construisez un JAR et Hadoop se chargera ensuite de distribuer votre algo sur le cluster.

Vous pouvez aussi faire du streaming avec un binaire pour la partie map, un binaire pour la partie reduce et simplement la définition des entrées et des sorties. Pratique pour tester, mais les performances sont moins bonnes que l’API native Java.

Apache Hive est un langage pseudo-SQL pour générer des jobs Hadoop. Un autre projet, Apache Pig venu de Yahoo! Emmanuel présente ensuite un exemple en Ruby avec Cascading/JRuby. Plus verbeux que Pig, il utilise le même exemple afin de nous montrer les différents types de DSL existants.

Pour terminer nous avons vu une démonstration avec Cloudera. Cette société propose un support et des outils professionnels pour Apache Hadoop.
D’autres services comme Amazon Elastic MapReduce et bientôt le support d’Hadoop sur Microsoft Windows Azure. Le framework est utilisable sur Amazon WS très facilement.

Pour tester Hadoop vous pouvez récupérer une VM sur le site de Cloudera avec l’ensemble des outils d’Hadoop. Pratique si vous voulez simplement regarder.
Tout est sur http://www.cloudera.com

Une présentation simple et intéressante sur Hadoop.

Avant tout, je ne vais pas vous donner mon avis, mais simplement vous faire partager ce que j’ai vu. Ce qui suit est donc plus une simple retranscription de la présentation.

Ceylon est un langage inventé par Gavin King, salarié de Red Hat, qui a lancé Hibernate, Seam et CDI avec d’autres développeurs comme Emmanuel Bernard. C’est un langage sur la JVM. Il a pour but d’être facile à apprendre, moins verbeux et plus lisible que Java. Par exemple, quelques principes comme se débarrasser de tout ce qui est XML, promouvoir un style plus fonctionnel, supporter la méta-programmation, et la modularité.

class Rectangle() {
 Integer width = +0;

 Integer height = +0;

 Integer area() = {
  return width * height;
 }
}

Voyons cela avec un peu plus de Ceylon :

shared class Rectangle(Natural height) {
  shared Natural height = height

  shared Natural area() {
   return height;
  }

}

Notez tout d’abord que le constructeur est dans le corps de la classe, principe que l’on retrouve aussi sur les case class en Scala.
Les opérateurs de portée sont plus simples. shared est public, le défaut est scope-private. Pas de protected, package, private. Le type Natural est utilisé pour les entiers positifs. Les attributs sont par défaut immuables. En pratique, pareil que des propriétés Java Bean. Ceylon encourage aussi les objets immuables.

On peut faire des abstractions, avec attributs, méthodes et classes redéfinissantes. Il n’y aura pas de surcharge de méthodes en Celyon contrairement à Java. La surcharge de méthode est utilisée habituellement pour 2 raisons : gérer le cas des paramètres optionnels et gérer les différentes types. Prenez une méthode sum(int a, int b) et sum(float a, float b) en Java, il faudra trouver un nom différent à chaque méthode en Ceylon. Avec les paramètres par défaut, il n’est pas nécessaire de prévoir de la surcharge de méthode. Si vous voulez utiliser une méthode différente par type de paramètre, vous pouvez aussi simplement utiliser des noms différents. Ce principe est aussi en perte de vitesse avec Scala, car il rend très compliqué l’utilisation des fonctions, qui sont des objets dans une classe comme n’importe quel type. Ce ne sera donc pas révolutionnaire si vous codez déjà en Scala (voir ce bon article sur StackOverflow).

Ceylon offre donc un support des valeurs par défaut pour les paramètres, ce qui évite de devoir déclarer plusieurs signatures de méthodes.

Ceylon proposera de l’héritage multiple, plus proche cependant d’un héritage de type mixin. Sans état, l’ordonnancement et la gestion des super-types est réalisable. Ceylon aura aussi de l’inférence de type.

Une idée intéressante aussi : par défaut il n’est pas possible d’affecter une valeur null sur un type. Si vous voulez qu’un type puisse contenir null, vous devez explicitement utiliser un point d’interrogation comme sur la photo ci-dessous. Ceylon me fait penser à l’Elvis operator en Groovy.

Voici quelques exemples de type en Ceylon :

Les listes et séquences :

Certains opérateurs sont polymorphes, mais on ne peut pas utiliser de symboles comme nom de méthodes, contrairement à Scala. C’est un point qui évitera peut-être d’avoir des APIs trop complexes, une critique que l’on entend parfois sur Scala.

La modularité est très importante dans Ceylon. Chaque unité de code fait partie d’un fichier. Chaque package fait partie d’un module. Les modules Ceylon se distribuent à la Maven.

Une autre idée intéressante est l’intersection de type (ou union de type) démontrée avec cet exemple :

Pour terminer, Stéphane nous laisse avec un dernier slide sur ce qui sera aussi présenté dans les mois qui viennent petit à petit :

Le compilateur ceylonc prend du code java et ceylon et génère des .class. Vous pouvez aussi créer une archive, des fichiers .car.
Stéphane nous a montré une belle démonstration du plugin Eclipse, codé en partie par David Festal de SERLI. Bien entendu d’autres outils sont prévus comme un générateur de documentation. Stéphane n’a pas parlé pour l’instant des APIs comme par exemple une API collections. Mais j’imagine que cela sera prévu aussi plus tard.

Enfin Stéphane montre en avant première mondiale le futur site et la documentation de Ceylon, qui devrait être prêt pour la mi-novembre au moment de Devoxx 2011. Y’a encore du travail mais la documentation est assez complète. Nous devrions avoir cela d’ici un mois ou deux.

Conclusion

En cette fin d’année 2011, Ceylon c’est déjà un compilateur bien avancé, une documentation, une spécification et bientôt quelques outils. J’ai compté 3 Français sur le projet : Stéphane Epardaud, Emmanuel Bernard de JBoss RedHat, et David Festal de SERLI, qui a travaillé sur le plugin Ceylon pour Eclipse. Gavin King est basé au Mexique pour l’instant, il se charge de la définition des bases du langage. Stéphane travaille sur les outils, l’équipe est constitué au total d’environ 10 personnes pour l’instant.

J’ai le sentiment que Ceylon est d’abord fait pour adresser la frustration et la complexité de Java. Ce qui est intéressant, c’est que le langage est d’abord markété par rapport à Java, alors qu’en voyant la présentation je n’ai cessé de le comparer à Scala. J’ai forcément du mal à me projeter et à imaginer un développeur Java entrain d’apprendre Ceylon, alors qu’il s’intéresse déjà mollement à Scala.

Je trouve que Scala continue à être présenté comme un langage universitaire par les personnes qui en parlent lors des conférences. Ceylon parle tout de suite au développeur en entreprise avec une approche plus pragmatique. Scala vient de l’enseignement, Ceylon est porté par un éditeur présent dans notre industrie depuis quelques années. Il y a forcément une approche différente.

Ce n’est pas une petite montagne mais une véritable chaîne montagneuse qui attend les développeurs de Ceylon. Lorsque le compilateur sera stabilisé, il faudra attaquer l’écriture de différentes API comme les collections ou la gestion du réseau. Il faudra ensuite prévoir des frameworks pour faciliter la vie des développeurs, aider à l’écriture des tests, permettre d’écrire une application web. Enfin nous pourrons imaginer des logiciels d’entreprise pour proposer des services avancés comme du Cloud ou du Grid Computing. Mais pouvons-nous attendre autant ? Est-ce que ce créneau n’est pas déjà pris par Java, qui monopolise le monde de l’entreprise ? Par ailleurs, lorsque l’on voit Scala, les livres, l’écosystème, le support de la société TypeSafe et les différents frameworks déjà disponibles, est-ce que finalement Scala n’est pas le pire concurrent de Ceylon et Kotlin ?

Mon oeil de geek est intéressé par l’effort et le travail. Mon oeil de développeur d’entreprise est forcément plus réservé sur les chances de réussite. Il faut se concentrer non pas sur ce que propose le langage, mais sur les raisons de son existence. Si le débat tourne autour du choix de l’héritage multiple ou non, cela n’est pas intéressant. Le langage doit pouvoir répondre à la question « Pourquoi » avec par exemple 2 ou 3 phrases chocs. Java ne s’est pas vendu sur ses caractéristiques en tant que langage, mais sur les problèmes qu’il adressait : multi-plateforme, pensé pour le développement web, fonctionne pour le monde du mobile et de l’embarqué, évite de gérer les problèmes d’allocation mémoire, facile à enseigner. Bref si Java est un langage, c’est aussi une plateforme, une machine virtuelle, une communauté, un bon paquet de livres… Quelque chose qu’aucuns langages ne pourra remplacer.

Ceylon, ton ennemi c’est Scala. Ce n’est pas Java.

English version:
At the end of 2011, Ceylon already has a good compiler, some documentation, a specification and some tools such as the Eclipse plugin. I counted three French developers on this project: Stéphane Epardaud, Emmanuel Bernard of JBoss RedHat, and David Festal of SERLI, who worked on the Ceylon plugin for Eclipse. Gavin King is based in Mexico for now, he is responsible for defining the bases of language. Steph has worked on the tools, the team consists of a total of about 10 people for now.

I had the feeling during the presentation that Ceylon is first made to address the frustration and the complexity of Java. What is interesting is that the language is first marketed as a better solution than Java, but while I was watching this presentation I could not stop to compare Ceylon with Scala. I also thought that it won’t be that easy for a lazy Java developer, that has no clue about Scala and does not want to move his ass, to learn Ceylon. However, my general feeling is that it was interesting and still worth to look at it, cause it’s well designed.

For those who regularly attend a conference, and have the opportunity to see a Scala presentation, it’s somehow still presented with a lot of « universitary keywords », as if it was an obscure language that no Java developer could learn. Ok, this is a bit strong. But you see what I mean, if you had a Scala presentation recently. Ceylon on the other side speaks clearly to the Java developer in a company, with a more pragmatic approach. And this is good. Scala’s roots are in the Universitary, whereas Ceylon is proposed to the community by a software editor, RedHat. This is, I’m sure, something that will have an impact on how Ceylon is presented to the community. More pragmatic. Less « monad-type inference-functional-kick my ass » and more « this is how it works ».

This is not a small mountain but a real Everest that awaits Ceylon’s developers. When the compiler will be ready, they will have to start to write some nice API’s such as Collections or network management. They will have to provide some frameworks to ease developers’s life such as testing framework, web application framework or [your_favorite_use_case]-framework. Maybe, with the help of JBoss RedHat, some application software, but I doubt so.
But can we wait 1 or 2 years to wait for a stable and nice API ? To build frameworks, you need a community. Something you cannot buy. You need a lot of passionated developers. Maybe also you need good books, a lot of presentation in various conferences… Something we already have with Scala. Maybe Scala (and not Java) is the most serious competitor for Ceylon and Kotlin all in all…

Me as a geek, is interested by the effort and the work, by the clever ideas that Gavin King had in the language. On the other side, me as an enterprise developer is more skeptical about the Ceylon’s chances to succeed. To succeed, a language and the associated marketing materials have to focus not on the « What » but on the « Why ». When you present a new language, it’s really easy to explain « WHAT » it does, it’s harder to explain « WHY ». I think you need 3 or 4 « WHY » to succeed.

Java for instance is easy to explain : it’s a language that solves the multi-platform issue with a write once/run everywhere solution. It has been designed for the web development with a network api. It also removed from the developers’s hands the memory management issue, with a Garbage Collector. So it provides more solutions and less problems.

Ceylon, maybe Scala is your enemy, but not Java.

DevOps

3 cercles : le développement, la partie QA et la production. Henri explique que l’on ne peut pas embaucher un Devops, ce serait finalement essayer d’embaucher de la Collaboration.

Devops n’est pas un produit, ni une personne : ce serait quelqu’un capable de faire 3 domaines. Ce n’est pas une méthodologie stricte mais de bons principes et des idées fortes. Ce n’est pas une recette miracle.

C’est un mouvement, avec de l’agilité sur l’ensemble de la chaine jusqu’à la production. C’est une nouvelle donne technique en partie en raison des personnes qui ont donné un nom à ce mouvement. C’est la possibilité d’avoir un autre rapport que celui de la force entre la production et le développement. Ce mouvement de 2009 est lié au fait que les initiateurs de ce mouvenent sont des technophiles.
Devops se veut la réponse à de nouveaux problèmes : déploiement massif et régulier. PRA Persistence Resilience Availability, continuité et Cloud.

C’est de l’Agile sur toute la chaine. Elles ont fait leurs preuves en dev, elles sont applicables sous conditions en QA et en production.
Une opération de production doit être dans le processus du développement du logiciel. Finalement il faut que la mise en production soit régulière, au même rythme que celui des releases. En effectuant souvent des mises en production vous réduisez le mode « héroïque ». Les déploiements fréquents rassurent les développeurs, les testeurs et les équipes de production.
Cela permet de roder la mécanique de production et de réduire les risques de découvertes tardives des incidents.
Lorsque vous livrez régulièrement, les équipes de production peuvent détecter rapidement les soucis et les faire remonter aux développeurs.
DevOps c’est aussi une pensé différent : Scale out au lieu de Scale in. Vous n’allez pas ajouter des centaines de processeurs à une seule machine, mais plutôt ajouter des machines moins puissantes et distribuer le travail. Cela demande de l’opérationnel.

Une touche de Dev pour les Ops : les gens de la production aiment faire du code et du développement pour automatiser et répéter rapidement certaines tâches. Les développeurs ont aussi à apprendre de la production, comment logger des messages, comment gérer proprement les connexions avec la base de données, où stocker les fichiers. Bref isoler ces 2 mondes correspond à une fausse perception du métier de développeur et de l’exploitation. C’est souvent une demande de l’organisation ou de la DSI, alors que le bon sens voudrait que les équipes soient co-localisées, que les personnes de l’exploitation soient aussi dédiées à un ou deux projets maximums…

Les équipes d’exploitations ont développé des outils puissants comme Chef ou Puppet, tous les deux écrits en Ruby. Ils savent utiliser un SCM et ils peuvent aider les développeurs, en travaillant en étroite collaboration avec les développeurs. En écoutant Henri, je ne peux m’empêcher de penser que beaucoup de développeurs ne s’intéressent pas à la production. Quelques uns sont incapables d’utiliser Unix. Comme ils sont incapables d’utiliser Firebugs lorsqu’ils font du web…

Faut-il séparer les opérationnels des développeurs ?

Le constat c’est que lorsque l’on oppose les équipes, cela mène à l’échec. Surtout entre les équipes de production et de développement. Or finalement si l’on met 2 chefs pour diriger chacun des départements, il est évident que chacune des équipes n’a pas les mêmes intérêts. Les développeurs veulent de la flexibilité et de l’innovation, là où la production souhaite des noyaux stables et des procédures de suivi bien documentées. Comment cela peut-il fonctionner ? Comment voulez-vous travailler avec un développeur qui n’a jamais ouvert un terminal ou une console Weblogic ?

Henri parle aussi de vocabulaire. Si vous brillez en société avec OOM, jar, war, Maven ou CI, est-ce que vous maitrisez aussi Selenium, appliance F5 ou zfs ?
Là où le développeur trouve normal de coder en dur les urls ou les paramètres, c’est une hérésie pour une personne de la production. Sécurité, monitoring et suivi métier de l’application… c’est aussi cela l’architecture. Peut-être pas uniquement votre cravate et vos slides powerpoint avec SOA/SOO/SCA/SPA…

Les backups et la reprise d’activité après un incident… Certains applications ne sont pas prévues pour être arrêtées. Au premier crash, il devient impossible de relancer des SI ou des applications. Le développeur dit : « t’inquiète pas, il est 18h20 et tu peux faire la mise en production… » et le responsable d’exploitation a alors l’impression d’être un vampire qui ne vit que la nuit…

Le principe de DevOps c’est aussi d’en finir avec la patate chaude. Pour cela il faut faire une analyse des besoins de chacun, du fonctionnel jusqu’à la production. Et chacun doit être considéré d’égal à égal.
Pour mieux travailler, vous pouvez aussi définir les livrables. Un fichier toto-SNAPSHOT.jar ce n’est pas un livrable. Il ne faut pas non plus entrer dans des grosses procédures lourdes inventées uniquement par des managers incompétents pour justifier finalement leur existence…

Chez eXo Platform

eXo Platform : 160 personnes dont 20 personnes en France, est une entreprise distribuée avec des équipes aux USA, en Ukraine, au Viet-nam et en Tunisie. Tout fonctionne avec des outils adaptés aux besoins d’un éditeur.

Henri parle un peu de l’infrastructure et des outils utilisés par eXo. Les outils sont classiques, mais les outils communs : JIRA, SVN/Git, Nexus, Confluence pour wiki et jenkins. Cela permet d’avoir les mêmes outils pour toutes les équipes : développeurs, productions, assurance qualité… Bref une réduction des coûts et une meilleur synergie entre les équipes.

Une demande de déploiement chez eXo c’est un ticket Jira. Cela permet d’utiliser les outils de planification de Jira, de décrire les opérations en cours et de faire des retours.
Les incidents de production sont des tickets : les données de production sont alors attachées au ticket, tout l’historique est attaché au ticket. Le développeur a donc directement l’ensemble des informations collectées par les opérationnels. On gagne du temps, et on comprend lorsqu’une nouvelle version est livrée qu’elle corrige un ticket donné.

SVN/Git est utilisé pour les sources des applications (dév) les sources des tests, les source du packaging, les manifests Puppets pour la pros et les sources des jobs Jenkins. Tout est librement accessible : comme dit Henri, on travaille tous dans la même maison.

Nexus est un repository des jars. Cela évite d’avoir des jars « bidouillés ». Cela renforce la livraison via Nexus. Pas de livraison par email. Cela rassure les équipes QA et production. Il n’y aura pas d’éléments déviants. On est dans une vraie démarche Editeur. eXo Platform est un éditeur avec une chaine logicielle très outillée.

La documentation par équipe est sur un seul repository. Des macros JIRA permettent d’avoir l’état de certaines tâches directement dans le wiki Confluence. C’est aussi un outil participatif.

Jenkins est aussi massivement utilisé. C’est un enchaineur d’événement. Connu d’abord comme un moteur d’intégration continue, c’est aussi un moteur de déploiement, de packaging et de tests continus. Tout ce qui est répété est automatisé, une vraie production au sens industriel du terme.
Henri présente en détail chacun des cas d’usage de Jenkins, qui dépasse largement la simple compilation d’un projet.

Conclusion

Il n’y a pas de cloisonnement chez eXo Platform. Chacun peut accéder à l’ensemble des informations. La participation et les échanges sont encouragés. Tout le monde utilise les mêmes outils. Jenkins qui était utilisé par la QA n’était pas utilisé par les équipes développements au début. Il a été mis en place rapidement pour toutes les équipes.

DevOps c’est une culture de la communication, comme l’Agile est finalement une culture de travail entre les équipes métiers et les développeurs.

C’est parti pour 2 jours de conférence à Sophia-Antipolis, sur les hauteurs de Nice. Au programme, 34 conférences sur 2 jours, avec 28 speakers, environ 180 personnes, et un site magnifique à l’INRIA.

Keynote d’ouverture par Stéphane Epardaud, organisateur de la conférence du Riviera DEV qui a récemment rejoint JBoss RedHat. Il travaille sur le langage Ceylon. La conférence se déroule dans des bâtiments de Sophia-Antipolis dans la montagne, qui me font penser à Palo Alto ou Mountain View. Ambiance américaine. Au détour d’un café j’apprends qu’un 20ème Java User Group ouvre à Brest, le FinistJUG (@FinistJUG et http://finistjug.fr/). Après le LavaJUG à Clermont-Ferrand il y a quelques semaines, content de voir encore un nouveau JUG.

Cloud Bees par Nicolas de Loof

Je commence ma matinée avec Nicolas de Loof, sur CloudBees. Ancien commiter de Maven, co-auteur du livre Apache Maven avec Arnaud Héritier. Pour débuter, ça parle Forge logicielle. Nicolas prend l’image d’un plan de métro pour expliquer les différents métiers et besoins d’une équipe logicielle. L’intégration continue dépasse la simple intégration du code et des tests. C’est aujourd’hui un outil indispensable, pour répondre aux demandes des différents métiers : développeur, testeur, chef de projet et intégrateur.

Nicolas demande qui utilise un SCM ? Majoritairement SVN, peu de personnes utilisent Git dans la salle. Pour le build, Maven2 et maintenant Maven3, qui après quelques années est enfin dispo. Mais Maven3 est bien différent du côté licence. Le coeur Maven-core est en licence Apache Software Fundation. Mais le repo central est hébergé par une société commerciale, Sonatype. Il y a aussi Plexus qui est obsolète, Aether fait par sonatype en licence EPL et Sisu en licence EPL. Or tôt ou tard, Sonatype pourra faire payer certaines fonctionalités du repo central, comme faire payer les statistiques de téléchargement des librairies. SpringSource par exemple pourrait payer pour connaître le nombre de chargements de leurs librairies.

Côté Apache Maven, Sonatype ne fait plus partie du PMC. Trouver des contributeurs pour Maven3 devient difficile. Il y a une grande communauté de plugins avec beaucoup de commiters. Pour comprendre Maven3 il faut comprendre Eclipse Aether. Nicolas a une vision assez noir de l’avenir de Maven au sein de la fondation Apache.
A part Maven, il y a aussi Graddle, Apache Ant, Buildr ou même simplement make. Maven va continuer à être utilisé encore un bon moment. Personnellement, je trouve SBT, l’outil de Scala, très bien fait. Je ne serai pas étonné de voir des projets s’en servir.

Pour automatiser le tout, Nicolas présente maintenant le projet Jenkins, anciennement Hudson. Oracle étant propriétaire de la marque Hudson, a demandé à faire fixer des bugs avant la sortie d’Hudson. Or la gouvernance d’un projet n’est pas faite par une société mais par des personnes. Finalement, le fondateur d’Hudson, Kohsuke Kawaguchi, a quitté Oracle et travaille maintenant chez CloudBees. La gouvernance du projet Jenkins est ouverte. La gestion du projet est distincte de la gouvernance technique. Cela évite les collisions et les conflits d’intérêts. Le projet est sur GitHub. Il n’y a pas de CLA ou de license à signer pour les Plugins.

Lancer un projet, c’est installer des outils comme un SCM, un build tools, un outil d’intégration continue, une sécurité à faire rougir la CIA pour le DSsI de la société, des tableaux Sonar avec des indicateurs de qualité, des jobs, des serveurs de démonstration, des gestionnaire de répo… bref… c’est long.

Alors on peut faire une superbe forge, cliquer sur Clone, et avoir son projet au bout de 10 mn. Mais finalement, il faut bien une équipe qui créé cette forge et qui s’assure de sa maintenance… Si un éditeur peut mettre en place une équipe « outils », les clients finaux comme une Banque n’ont pas forcément les mêmes moyens (cela dit j’ai vu un exemple qui marche bien dans une Grande Banque Française).

Option 2 : on peut aussi scripter notre installation avec Chef ou Puppet.

Il faut enfin avoir une machine. Vous commandez une machine, l’équipe technique met 3 semaines à vous installer une « VM » sous Windows alors que vous aviez besoin pour hier d’un serveur sur Linux… Bref c’est compliqué.

On arrive donc au Cloud. Première idée : la mise à disposition de ressources et la notion de « self-service ». En écoutant Nicolas de Loff, j’ai cette image : le Cloud finalement c’est le Mac Drive du développeur. Soit tu t’assois, tu attends patiemment que le gros barbuvienne prendre ta commande, pour découvrir au final que le contenu de l’assiette n’est pas identique à la photo, soit tu décides toi-même de ce que tu veux, et au dernier moment.

Le Cloud c’est aussi de l’élasticité et de la flexibilité. Côté investissement, vous passez à un paiement à l’usage, qui vous permet d’expérimenter avant de passer à l’achat de vos machines.

C’est là que CloudBees propose de la valeur, avec une porte d’entrée gratuite.
CloudBees DEV@Cloud est une plateforme as a service, avec un Jenkins hosté sur Amazon AWS, différents niveaux de souscription et des outils complémentaires. Vous pouvez par exemple utiliser SauceLabs OnDemand pour tester votre application web avec Selenium sur différents browsers, jFrog ou Sonar pour la partie DEV@Cloud.
Pour la partie RUN@Cloud, vous avez de l’hébergement avec Java/MySQL, et des outils supplémentaires comme NewRelic par exemple.

Par rapport à Heroku, CloudBees adresse donc d’une part la vie et la compilation de votre projet, et d’autre part l’hébergement dans le Cloud. Il y a aussi RedHat OpenSHift, CloudFoundry par VMWare, Amazon Web Service et docCloud.

Nicolas fait ensuite une démonstration avec CloudBees et le plugin Eclipse. Démon assez sympa, dans laquelle il créé à la volée un projet, une compilation avec Jenkins.
Mais si vous ne voulez pas faire de Cloud ou utiliser des plateformes externes, vous pouvez aussi utiliser les produits de CloudBees dans votre propre réseau. Cela vous offrira de la flexibilité et sera peut-être plus facile à placer dans votre SI.
Pensez que CloudBees permet de construire votre projet et de vous donner la main sur votre processus de build.

La version gratuite vous permet de faire 5 heures de build par mois, vous pouvez avoir 2 exécuteurs, vous êtes limités en nombre de plugin. Ensuite la version Base pour 15 USD par mois vous permet de dépasser les 5 heures de build. La version Pro et Entreprise répondent aux besoins des entreprises.

Allez je file, je vais voir la présentation Node.JS par Mathilde Lemée et Romain Maton… Vous continuez à compiler avec Maven ou vous me suivez ?

Au programme : Java, Recherche et Web.
Vous pourrez par exemple voir des présentations de Node.JS, CloudBees, DevOps, GitHub, Scala, Grails, Play! Framework, CoffeScript ou encore Ceylon. Bref une belle conférence technique, avec des sujets pointus et d’actualité.

Pour vous inscrire : rendez-vous sur cette page. Pour 60 EUR vous pouvez participer à 2 jours très intéressants.

Faites suivre aussi l’information à vos contacts dans la région, et rendez-vous la semaine prochaine.

Sur Twitter : @RivieraDEV