Author Archives: Alexis Kinsella

Author Archives: Alexis Kinsella

QCon London – Développement Web mobile, Javascript et HTML5

QCon London – Développement Web mobile, Javascript et HTML5

Avec l’émergence de la mobilité dans notre quotidien, ce sont également de nouveaux besoins informatiques qui sont apparus dans nos SI. Au début, la problématique était simple puisque la plateforme iOS était sans concurrence. L’arrivée de nouveaux challengers a multiplié les nouveaux développements, et la fragmentation des développements est rapidement devenue un problème sérieux à adresser, voire même un véritable enjeu budgétaire: la fragmentation coûte cher et de prime abord ne semble pas toujours rentable à traiter. Certaines entreprises font ainsi le choix de supporter de nombreuses plateformes, tandis que d’autres ne supportent que le strict minimum, c’est à dire iOS et Android, voire même des fois uniquement iOS.

Avec l’avènement d’HTML5 et le bouillonnement actuel du web, des solutions innovantes ont commencé à pointer le bout de leur nez. Sont apparus tout d’abord des toolkits mimiquant l’interface utilisateur d’iOS, puis sont arrivés progressivement des frameworks plus ambitieux ayant pour objectif d’adresser ce problème de fragmentation. Le champion en la matière s’appelle jQueryMobile, il supporte la quasi totalité des plateformes mobiles à ce jour, et ses principaux concurrents sont Sencha Touch et Titanium d’Appcelerator. Même si ces outils sont relativement récents, ils permettent d’ores et déjà de développer des solutions sérieuses basées sur des technos web, et des nouveaux outils innovants fleurissent cette année à un rythme effréné (Rhodes, Jo, Wink, Dojo Mobile, Kendo, M Projecttrigger.io), ce qui montre une furieuse tendance à vouloir trouver des solutions à cette fragmentation via des standards déjà maîtrisés.

Il faut cependant reconnaître que ces idées sont nouvelles, et de nombreux gaps viennent compliquer légèrement les choses. A commencer par le fait que le parc mobile actuel propose des navigateurs plus ou moins matures, dont le support d’HTML5 varie de façon non négligeable selon la version de l’OS et le type de plateforme. Bien que les moteurs de rendu et de JavaScript des navigateurs mobiles évoluent de manière incroyable, tout comme leur matériel d’ailleurs, on est loin des performances natives de ces combinés. Il suffit pour cela de regarder la fluidité d’iOS pour s’en convaincre. Cela est toutefois à mettre dans la balance avec un univers web qui évolue (très) rapidement et qui chaque jour abat des barrières.

(suite…)

QCon London – Zero to ten million daily users in four weeks

QCon London – Zero to ten million daily users in four weeks


Jodi Moran, co-fondatrice et CTO de la société Plumbee, spécialisée dans le développement de jeux sur le web (Jeux Facebook en particulier), a présenté lors de QCon Londres un retour d’expérience sur les pratiques de développement mises en oeuvre au sein de sa société, et qui ont permis de répondre à des contraintes de croissance fulgurante.

Jodi démarre la présentation avec la définition de la notion de « Une vitesse soutenable »:

  • La vitesse est mesurée par le temps séparant l’expression du besoin à son changement effectif.
  • La durabilité est mesurée par la capacité à garder cette vitesse dans le temps.

Maintenir un rythme soutenable permet d’avoir de la réactivité, ce qui est primordial pour garder son audience. Mais cela permet également d’avoir un meilleur rendement et des investissements plus faibles.

(suite…)

QCon London – The Guardian, Simplifying Development

QCon London – The Guardian, Simplifying Development


Lors de la dernière journée de QCon Londres, dans le cadre du track The rise of Scala & Functional Programming, les équipes du journal The Guardian nous proposaient un second retour d’expérience via leur architecte Graham Tackley. L’objectif de cette session était de présenter comment les équipes sont passées à Scala et comment ce choix a simplifié les développements.

Tout d’abord, il faut savoir qu’entre 2006 et 2008, l’architecture applicative du site web du journal reposait sur un socle composé des technos Spring, Hibernate et Velocity. Assez rapidement, ce socle commença à poser des problèmes de maintenabilité aux équipes. En premier lieu, la cause incombait à la verbosité des technologies utilisées. Pour se faire une idée, il suffit de jeter un œil aux métriques et en particulier au cumul des lignes de code:

  • les classes Java représentaientnt 185.000 lignes,
  • les fichiers XML : 35.000 lignes correspondant en grande partie au code Spring,
  • les fichiers de templating (Velocity) : 72.000 lignes.

Ces totaux peuvent vous sembler importants, mais il faut se rappeler que Java n’est pas un langage appliquant particulièrement les principes DRY. De plus, les configurations XML des applications basées sur Spring étaient particulièrement verbeuses ce qui est moins le cas aujourd’hui depuis la généralisation de l’usage des annotations. Il faut cependant relativiser s’il faut ramener ces chiffres à la verbosité des tests unitaires qui représentaient à l’époque, accrochez-vous, 248.000 lignes de code.

Graham nous explique qu’un cycle de développement de deux semaines pour une application web est bien trop long. De plus, cela ne répond pas aux exigences du monde du web. Cependant, cela est trop rapide pour les équipes qui ne peuvent répondre aux cadences exigées par le monde du web avec un applicatif aussi lourd à faire évoluer.

Un autre aspect des problématiques de maintenabilité et de charge semblait venir de la partie ORM de l’application. Non pas qu’Hibernate, utilisé à l’époque, soit remis en cause, mais plutôt les concepts associés.

Une des premières initiatives prises pour remédier aux problèmes de cycles de développement a été de scinder l’application monolithique en différentes micros applications indépendantes avec des  cycles de développement très courts et dont la maintenabilité est facilitée par leur faible taille et leur découplage.

Rapidement, les équipes ont commencé à créer des micros applications dans différentes technologies telles que Python avec Django. Ces outils ont rapidement permis aux équipes de se focaliser sur des aspects métiers plutôt que sur des aspects techniques. Cependant, ces nouveaux environnements semblaient poser des problèmes d’exploitation puisque les environnements d’exécution associés impliquaient de nouvelles acquisitions de compétences. Cela avait pour effet de générer des problématiques d’exploitation qui jusqu’ici n’existaient pas. Comme Graham le rappelle, il vaut mieux privilégier les évolutions plutôt que les révolutions.

Afin de retrouver un environnement proche du monde Java, les équipes ont cherché de nouvelles solutions et se sont orientées vers le développement de composants basés sur Scala. L’objectif recherché étant d’avoir accès aux avantages que peuvent apporter la JVM et l’environnement Java : même infrastructures, même outils (Maven notamment), même bibliothèques, mêmes runtimes, etc. Le compilateur Scala génère du bytecode et un war, c’est à dire tout ce qu’il y a des plus standard dans le monde java. Scala étant opérable avec Java, il est possible de mixer les deux langages dans une même application et de pouvoir reprendre certaines parties de code de l’un ou de l’autre.

Scala est connu pour sa concision, ce qui est réellement important aux yeux de Graham vis-à-vis des problématiques engendrées par la taille de la base de code historique.

En novembre 2009, les équipes sont parties sur un socle technique basé sur Java + Guice + Guice Servlet + Apache Solr et 3 à 4 développeurs, pour switcher en février 2010 de Java à Scala. Graham explique qu’Il n’aura fallu que trois mois à l’équipe pour passer le projet en Scala et le porter en production. Par la suite, il insiste sur le fait que la mise en production s’est passée sans incident, et ce, même avec un changement aussi impactant.

Enfin en juillet 2010, les équipes sont passées à SBT afin de disposer d’un outils plus puissant et mieux adapté aux besoins des projets Scala. SBT permet en particulier d’outrepasser les problématiques de lenteur du compilateur Scala.

La stack actuellement exploitée par le site est composé de Scala + Lift + Apache Solr. On pourra s’interroger sur ces changements de technologies incessants. Mais comme le répète Graham, mieux vaut privilégier les évolutions que les révolutions.

Afin de faire taire certaines idées persistantes à propos de la supposée difficulté d’apprendre Scala, Graham prend les devants en expliquant que ce choix a été plus bénéfique que prévu pour les équipes. Les membres ont pris beaucoup de plaisir à apprendre ce langage, ce qui a favorisé une forte collaboration dans cet apprentissage. Cela a pris entre un et trois mois pour que chaque développeur devienne productif avec le langage. Graham insiste sur le fait que ses équipes n’ont pas rencontré tous ces problèmes énoncés dans différents articles qui ont enflammé la communauté Scala ces dernièrs mois.

Graham voit au final dans Scala plusieurs avantages pour ceux qui veulent l’utiliser ou bien encore l’apprendre :

  • Scala tend à favoriser l’immutabilité dans les développements,
  • La console Scala encourage la vision du code comme une entité vivante (qui évolue),
  • Les frameworks de tests sont d’une extrême simplicité,
  • Scala ne pousse pas à l’intégrer de frameworks complexes à tous les étages.

Parmi les inconvénients imputables au langage, Graham met en avant :

  • La relation de type « je t’aime, moi non plus » des développeurs (en général) avec SBT. On pourrait dire la même chose avec la communauté Java avec Maven…
  • Le support encore immature des outils,
  • Un compilateur lent,
  • Le rythme des évolutions du langage.

Enfin, Graham dit à demi-mot que le framework Play!2 semble très prometteur et qu’il faut garder un œil dessus dans les prochains mois.

Liens utiles:

QCon London – The Guardian, Architecting for failure

QCon London – The Guardian, Architecting for failure


La conférence QCon de Londres a été l’occasion pour les équipes du journal « The Guardian » de proposer des retours d’expériences extrêmement enrichissants sur l’architecture de leur site web et l’organisation de leurs équipes de développement. Michael Bruton-Spall, advocate pour le Guardian, a présenté le second jour de la conférence la session: Architecting for Failing.

Le pitch de la session est le suivant: « Your systems are going to fail, it might not be today, it might not be tomorrow, but sometime soon, probably at 2am, your systems are going to fail in new and exiting ways ».

Ce principe a été abordé au cours de plusieurs sessions et fait parti des sujets chauds cette année. La question n’est pas de savoir si votre système tombera, mais plutôt comment vous réagirez lorsque cela arrivera.

Avec la complexité croissante des systèmes informatiques et l’avènement du cloud, les causes de plantage deviennent plus variées et plus nombreuses, et vous ne maîtrisez plus forcement la chaîne d’exploitation de bout en bout. Il est donc nécessaire de monitorer vos systèmes, et d’être préparé à réagir lorsque les choses tournent mal.

Historiquement, le site web du journal The Guardian avait une architecture monolithique. Avec une base de code devenue difficilement maintenable, les équipes ont décidé de revoir le design de leur application et de passer à une architecture à base de micros applications. Le principe est de construire les pages web du site à partir d’un template qui sera complété par l’inclusion de morceaux de code générés par des applications indépendantes. L’idée peut être comparée aux « Servers Side Includes » de l’époque. 

Aujourd’hui, ce concept prend un sens nouveau puisqu’il permet de décomposer une application monolithique en de multiples applications indépendantes les unes des autres. Les implications de ce changement sont une maintenabilité bouleversée puisqu’il s’agit de maintenir des multiples applications ayant une complexité bien plus faible et une base de code unitaire réduite. Il devient ainsi plus simple d’appliquer un changement dans une seule des applications et de ne mettre en production qu’une partie de l’ensemble applicatif. Il n’est plus nécessaire d’attendre une release globale pour mettre en production une nouvelle fonctionnalité.

Cette diversification des applications a toutefois un coût puisqu’il est nécessaire de fournir un support et une maintenance pour chacune d’elles. Afin de simplifier les choses à ce niveau, les équipes de développement ont décidé que chaque nouvelle micro-application serait basée sur des technologies tournant sur la JVM.

L’architecture étant basée sur HTTP, il est possible de mettre en cache les données générées par les différentes micro-applications, et de gérer finement les état des différents caches utilisés. Il est ainsi possible de gérer simplement les pages en erreur au niveau du cache, et de ne pas écraser des données de cache valides par des données en erreurs (« stale-if-error » géré par Varnish).

L’architecture à base de micros-applications permet également de tester, releaser, déployer, et gérer un cycle de vie totalement différent pour chacune des applications. Cela permet de simplifier de façon drastique la maintenance de l’application et de  faciliter les évolutions. Ce changement d’architecture a toutefois impliqué la mise en place d’un cache systématique afin de limiter des coûts de latence élevés. 

Rétrospectivement, le choix d’éclater une application monolithique en de multiples applications indépendantes pouvait paraître risqué puisque cette refonte nécessitait une réécriture en profondeur des applications ainsi qu’une complexification importante de l’architecture, mais ce choix fut vraisemblablement le bon puisque ce changement a permis à l’équipe d’améliorer de façon drastique la maintenabilité de l’application et raccourcir les délais de livraison de nouvelles fonctionnalités.

Par la suite, Michael explique que les équipes ont prévu dans le système différents mécanismes permettant de gérer les imprévus. Les équipes ont ainsi mis en place un mode d’urgence permettant de gérer les pics de traffic: les pages dynamiques étant coûteuses en CPU ainsi qu’en mémoire, il est nécessaire de mettre en place des mécanismes d’urgence permettant de désactiver les traitements coûteux et de privilégier la vitesse. Par ailleurs, les caches de leurs applicatifs n’expirent pas en fonction du temps, mais sur une base de critères variés permettant d’éviter la regénération de contenus lors de pics d’affluence.

Michael explique qu’il est nécessaire de tout cacher, vraiment tout. Les caches in-memory des micros-applications ne sont pas suffisants dans certaines situations: il est nécessaire de cacher des pages entières afin de répondre plus rapidement. Les pages générées sont stockées sur disque et servies en tant que fichiers statiques. Ceci permet de servir plus de 1000 pages par secondes par serveur. Ce mécanisme de mise en cache de pages complètes a pour avantage de ne pas affecter les micros-applications par design.

Le monitoring applicatif est également un aspect essentiel, car il aide à trouver l’origine des problèmes. Il permet de savoir ce qui n’a pas été, quand un problème est survenu, et quel changement a déclenché le problème.

L’aggregation de statistiques dans cette architecture est faite à différents niveaux, et toutes les données monitorables le sont que ce soit des informations de CPU ou bien des informations provenant des micros-applications. Des switchs automatiques permettent d’activer / désactiver des valves, de passer en mode urgence, ou bien de gérer le cas d’une base de données inaccessible. Les valeurs d’activation des switchs correspondent à des valeurs plancher telles que le temps de réponse. Les tendances de ces switchs sont mesurées via leurs outils de monitoring et peuvent être analysées à tout moment.

Michael insiste sur l’importance d’avoir une plateforme applicative « facilement » monitorable. La surveillance des logs doit en être un élément central du système de monitoring. Les logs doivent être parsables, datés, et renseigner sur le code affecté. Enfin, la maîtrise d’outils Unix tels que ‘grep’, ‘cut’, ‘uniq’, ‘sort’, ‘sed’, ou bien encore ‘awk’ doit faire partie de la boîte à outils de chaque développeurs afin de faciliter l’analyse de logs applicatifs.

En fin de session, Michael explique qu’il existe des cas de défaillance prédictibles (Disque dur Fill, CPU à 100%, …), tout comme des cas de défaillance non prédictibles (MTBF, MTBR). Si  vous être en mesure d’anticiper ces défaillances du système, vous serez en mesure de récupérer plus rapidement et d’amoindrir l’impact sur vos utilisateurs. La Keynote du dernier jour de la conférence nous confirme d’ailleurs qu’il préférable privilégier le Mean Time To Recovery plutôt que le MTBR. Michael rappelle également qu’il ne faut jamais dépendre trop fortement de services ‘third parties’, car ils failliront toujours au moment le pire et laisseront vos équipes seules face à leurs problèmes. Michael conclut la session sur l’importance d’architecturer les applications de façon à les rendre résiliantes face à d’éventuelles défaillances de composants ou dépendances dont vous n’avez pas toujours la maîtrise complète.

Liens utiles:

QCon London – Developers Have a Mental Disorder

QCon London – Developers Have a Mental Disorder


La keynote de fermeture de cette première journée de conférence à la QCon de Londres est présentée par Greg Young, co-fondateur et CTO d’IMIS, cabinet d’analyse de marchés boursiers à Vancouver BC. Greg Young est ce qu’on peut appeler un agitateur doublé d’un showman. Le moins qu’on puisse dire c’est qu’il sait réveiller une assemblée un peu fatiguée après plus de 8 heures de sessions cloud, mobilité, hardcore java, et j’en passe.

Greg Young met d’entrée de jeu les pieds dans le plat en expliquant que les développeurs aiment résoudre des problèmes que personne n’a. Il met pour cela en avant le concept de réutilisation, qui est trop souvent avancé à tord et à travers pour justifier le développement d’architectures ou d’applications bien trop complexes pour avoir une chance d’être réutilisées par une autre application du SI. Ce problème vient du fait que, le plus souvent, les développeurs aiment construire de l’abstraction autour de concepts simples. Nous voulons abstraire tout ce qui nous passe sous la main mais en tirons rarement bénéfice. 

Il vaut mieux parfois réécrire le même code 2 ou 3 fois, plutôt qu’apporter du couplage dans le logiciel : abstraire les idées apporte de la complexité.

Pour argumenter le concept, il part d’un exemple qu’on rencontre souvent sur des projets informatiques qui démarrent. Lorsqu’on forme une équipe de développement pour un nouveau projet, l’équipe aura tendance à choisir les technologies avant même de connaître réellement le besoin (Tomcat, Spring, Hibernate et MySQL à tout hasard?). Oui, mais seulement en a-t-on vraiment besoin et est-ce seulement adapté à la problématique ?

Greg Young va plus loin en expliquant qu’il vaut mieux parfois « A piece of crap » réalisée en 2 semaines, plutôt qu’une vraie application bien codée réalisée en plusieurs mois (oui, c’est un brin provocateur). Une application réalisée rapidement amènera plus rapidement un feedback et suffira parfois à répondre au besoin.

La question n’est donc pas de savoir si l’application répond à l’état de l’art, mais surtout si elle répond aux besoins réels du client. Inutile de dire que les ORM, qui représentent l’abstraction et la surcomplexité par excellence, en ont pris pour leur grade. Si vous en doutez, posez vous la question de savoir sur quoi repose JPA :

  • JPA est un socle commun à différentes implémentations d’ORM
  • Les ORM sont eux-même des abstractions de la base de données
  • Les bases de données reposent elles-même sur un langage normalisé depuis les années 90, le SQL.

Faut-il en déduire que nous avons un tout petit rien de complexité inutile ? Oui ! Avez-vous déjà travaillé sur des projets pour lequels vous avez déjà eu à changer de base de données ? Si oui, combien de temps aurait coûté une adaptation du code quand bien même il y aurait des changements de requêtage SQL à faire ? En conclusion: oui, nous employons inutilement trop d’abstractions de concepts.

Et pour ôter tout doute de l’esprit, Greg Young prend un exemple frappant, mais ô combien révélateur : si on vous demandait de réaliser un blog, l’idée de proposer une stack de développement à base de Java, Spring, Hibernate vous viendrait-elle à l’esprit, alors que des solutions bien plus adaptées existent ? De mémoire, il existe bien des projets de blogs implémentés avec ces technologies, mais n’est-ce pas sortir un bazooka pour tuer une mouche ?

La keynote de Greg Young, volontairement provocatrice, a pour objectif premier de nous rappeler d’être pragmatique dans notre approche du développement et de garder une vision simple des choses. Nous devons toujours prendre du recul sur les différents choix qui s’offrent à nous. C’est notre travail d’artisan de l’informatique d’adapter nos outils aux besoins du client.

Une de mes phrases préférées de la keynote est la suivante : « Developers love to solve problems that nobody have ». Autant dire que lorsque la salle a été sondée à main levée, on pouvait voir qu’une très grande majorité se reconnaissait dans cette description! Oui, nous, développeurs, avons tendance à trouver des problèmes là où il n’y en a pas. A nous de rester pragmatique et simple pour éviter de tomber dans ce piège classique, et ainsi « éviter de coder un CMS pour gérer une flotte de camions à ordures », dixit Greg Young.

QCon London – Keynote d’ouverture – The Data Panorama

QCon London – Keynote d’ouverture – The Data Panorama

Chaque journée de la QCon de Londres est inaugurée par une keynote. Le premier jour de la conférence, ce sont Martin Fowler et Rebecca Parsons de ThoughtWorks qui se sont prêtés au rituel. Ils ont présenté une keynote d’ouverture nommée : « The Data Panorama ».

Pour eux, le sujet brûlant en 2012, c’est BigData. La donnée est partout et au centre de tout projet informatique. Plus exactement, la donnée est : distribuée, précieuse, connectée, et urgente.

La gestion de la donnée a évolué ces dernières années, notamment en terme de volume. Cependant, il existe aujourd’hui des solutions efficaces pour traiter cet afflux de données dans nos SI en passant par différents outils tels que les algorithmes Map/Reduce basés sur le principe de Divide & Conquer : il est plus intéressant de diviser en de multiples unités réduites de stockages et de traitements, plutôt que d’avoir une unité importante dont le coût d’acquisition peut être élevé. Le concept se décline aujourd’hui de façon optimale avec le cloud qui permet de payer uniquement des coûts d’exploitation correspondant à l’usage.

BigData n’est pas nécessairement un terme à définir. Il s’agirait plutôt d’une notion qui possède des caractéristiques. Le BigData est non relationel, open sourcecluster friendly, schemaless, et adapté aux besoins modernes du web et des entreprises.

Il existe différents types de bases de données NoSQL adaptés aux différents besoins de l’informatique : clé/valeur (Redis, …), document (CouchDB, MongoDB, …), colonne (HBase, Cassandra), et graph (Neo4j). En avril 2010, Michaël Figuière présentait ces différents types de bases NoSQL sur le blog de Xebia : NoSQL Europe: Tour d’horizon des bases de données. Martin Fowler estime toutefois que la base de données « classique » n’est pas à jeter aux oubliettes, mais plutôt à garder intégrée dans le SI en tant que partie de la solution globale à apporter à la problématique de gestion de la donnée.

Traditionnellement, les données en entreprise sont agrégées dans une base d’intégration (données de facturation, d’inventaire, etc.). Or, Martin Fowler met en avant le besoin de changer ce principe pour aller vers un nouveau design de stockage des données au niveau de chacune des applications. La donnée doit être alimentée par de l’Event Sourcing, ce qui revient à dire en des termes simplifiés que les systèmes informatiques doivent capturer les changements d’état des applications comme une séquence d’évènements. Ceci permet d’ouvrir de nombreuses perspectives telles que la reconstruction de données, ou bien la réexécution de scénarios rencontrés en production.

Le cloud est une des clés de la mise en œuvre de systèmes modernes de gestion des données. Martin Fowler le définit comme un outil disponible à la demande en self-service avec de fortes capacités d’élasticité accessibles rapidement. De plus, les outils Cloud doivent être monitorables, et agir en tant que pools de ressources.

Les aspects analytiques ont également changé pour évoluer depuis des besoins de tendance et de variance, vers des besoins de data mining, d’analyse de relations ou bien encore de reconnaissance de motifs. Hadoop, une implémentation de type Map/Reduce, est un outil qui permet de répondre à ces nouveaux besoins en distribuant les jobs de traitement de données sur différentes machines pour en extraire des données importantes et les grouper de façon à être exploitables. 

Martin Fowler aborde en fin de keynote l’importance de la visualisation des données. Il fait référence à un tableau périodique des méthodes de visualisation, qu’il est possible de trouver à l’adresse suivante: http://www.visual-literacy.org/periodic_table/periodic_table.html. Ce tableau permet de comprendre les différents types de données, de poser un visuel de celles-ci et rend compte de la complexité des données avec lesquelles nous travaillons. D’une certaine manière les informaticiens modernes deviennent des sortes des scientifiques ou plutôt des journalistes de la donnée : ils doivent être en mesure d’en extraire les informations pertinentes, afin de mieux anticiper et donc d’être plus réactifs face aux changements. Selon Martin Fowler, Il est de la responsabilité des développeurs de s’assurer qu’elles soient justes et qu’elle ne reflètent pas une visions déformée des informations.

Liens utiles:

Retours QCon Londres 2012

Retours QCon Londres 2012

Xebia m’a récemment donné la chance de me rendre à la conférence QCon 2012 de Londres. A travers différents articles rédigés pour le blog de Xebia, que vous pourrez retrouver sur le blog d’ici peu, je vous proposerai de découvrir un peu de cette fantastique conférence! En attendant, n’hésitez pas à visiter le site de la conférence pour en découvrir un peu plus ;)

Introduction aux nouveautés de Groovy 1.8, et Grails 1.4

Introduction aux nouveautés de Groovy 1.8, et Grails 1.4

Ce mardi 7 juin a eu lieu le Paris Groovy & Grail User Group (GUG) dans les locaux de VMware à la Défense. Nous avons le droit à une présentation de Guillaume Laforge introduisant les nouveautés de Groovy 1.8, ainsi que les fonctionnalités à venir dans Groovy 1.9. Cette présentation très intéressante a déjà été jouée lors de la Gr8Conf 2011 de Copenhague et au S2G Forum 2011 de Londres. Cependant si vous l’avez ratée, et que vous souhaitez la voir, vous pouvez vous rattraper en visionnant les slides de la présentation sur sur SlideShare à l’adresse suivante:

Nous avons également eu le droit à une présentation animée par Stéphane Maldini en seconde partie introduisant les nouvelles fonctionnalités de Grails 1.4, et il faut bien avouer que cette nouvelle version va envoyer du lourd au niveau killer features. Grails dans sa version 1.4 va proposer de nombreuses fonctions avancées particulièrement tournées vers la productivité.

Quelques liens intéressants concernant Grails 1.4 :

Vous reprendrez bien un peu de Git ?

Vous reprendrez bien un peu de Git ?

Les scm sont incontournables depuis de nombreuses années dans l’univers du développement informatique, et s’en passer aujourd’hui serait pure folie.

J’ai eu l’occasion de fricoter avec quelques uns d’entre eux (CVS, Subversion, Mercurial ou bien encore ClearCase). Pendant un temps Subversion semblait être l’outil incontournable. Comme on dit la roue tourne, aujourd’hui l’outil au top c’est Git.

Pour avoir joué un peu avec, on peut considérer que Git est très semblable à Mercurial puisque ces deux outils de gestion de source sont de type DVSC. Cependant je n’avais jamais eu l’occasion d’étudier Git plus en profondeur. C’est maintenant c’est chose faire grâce à la présentation de Sébastien Douche ( @sdouche ) au ParisJug d’avril.

Si vous avez manqué la présentation, je vous invite à aller lire le blog de #gitfr. Le blog est très complet et reprend un certain nombre de thèmes abordés pendant la présentation. Il semble que la présentation devrait être rejouée d’ici une dizaine de jours. L’annonce devrait être faite sur le site du ParisJug. Je vous encourage chaudement  à y assister si vous en avez l’occasion, d’autant plus si vous en avez marre de Subversion, puisque vous aurez l’occasion d’assister à un enterrement en règle de notre bon vieux Scm.

 

Lancement du PaaS « Cloud Foundry » par SpringSource

Lancement du PaaS « Cloud Foundry » par SpringSource

Vous n’avez peut-être pas suivi l’actualité ces derniers jours, mais SpringSource/WMware vient de lancer une version toute nouvelle de son offre Cloud via le site CloudFoundry.com. Cette offre de type PaaS est basée sur le projet Cloude Foundry, qui n’est autre qu’un projet open-source sous licence Apache 2.0 hébergé sur GitHub.

A l’occasion de cette sortie, j’ai rédigé un billet de présentation de Cloud Foundry sur le blog de Xebia. Si vous être curieux de ce qui peut se faire aujourd’hui en terme d’offre PaaS, je vous invite à aller lire mon article à l’adresse suivante:

En vrac, et pour teaser, SpringSource/VMware propose ni plus ni moins qu’une plateforme Cloud multi-langage: Java, Ruby, JavaScript, et autre langages de la JVM. Dans la foulée la plateforme propose différents supports de stockage de données: Redis (Base Clés/valeurs), MongoDB (Base Document), MySql (Base relationnelle). Il est par exemple possible de créer son application Web avec des frameworks tels que Rails, Grails ou bien encore avec Node.JS.

Tout cela, est bien alléchant et donne envie d’aller essayer cette offre. A côté de cela, il ne faut pas oublier que SpringSource/VMware propose également en preview une offre Dev at Cloud nommée Code2Cloud (Git, BugTracker, Hudson, …), ainsi qu’une suite logicielle basée sur Eclipse nommée STS (Spring Tool Suite) permettant d’exploiter parfaitement tous les produit SpringSource/VMware.

Aucun prix n’a pour le moment été communiqué, l’essai de la beta de la plateforme est pour le moment gratuit, mais l’attente d’activation de son compte semble longue. Vous pouvez toujours vous lancer dans le développer d’une application basée sur l’offre de SpringSource/VMware, en démarrant un projet avec STS. Une belle introduction est proposée aux URL suivantes: