Après avoir assisté à la session sur Kotlin, nous ne pouvions pas faire l’impasse sur la présentation du langage Ceylon animée par Emmanuel Bernard et Stéphane Epardaud. Cette session était focalisée sur les motivations qui ont poussé à développer ce langage et devait nous montrer les possibilités de ce dernier.
Le projet Ceylon a été initié par Gavin King dont nous connaissons tous la renommée. Emmanuel explique que pour des raisons de frustrations avec le langage Java, Gavin et son équipe ont décidé de monter ce projet. Ils souhaitent développer un langage avec l’esprit Java et étant aussi pratique que ce dernier.
Les buts du développement du langage Ceylon sont les suivants :
- facile à apprendre,
- moins verbeux tout en restant lisible,
- type safety améliorée,
- avoir un nouveau SDK (plateforme),
- possibilité de faire du meta-programming.
Lire la suite de cet article »
Depuis quelques mois, Kotlin fait parler de lui. Rien de tel qu’une conférence comme Devoxx pour prendre la température de ce nouveau langage.
Lors de cette session, Andrey Breslav nous a expliqué d’abord les motivations qui ont poussé JetBrains à investir dans le développement de Kotlin :
- se détacher des limitations du langage Java dues à la compatibilité ascendante,
- avoir un outillage performant. Notamment, une intégration de qualité dans les IDE, un debugger et un compilateur au moins aussi rapide que celui de Java. Pour garantir cela, JetBrains développe en parallèle du langage et du compilateur, un plugin pour l’intégration dans leur IDE IntelliJ ainsi qu’un plugin simple pour Eclipse,
- avoir une syntaxe plus expressive.
Lire la suite de cet article »
Comme nous l’avons déjà évoqué sur le blog, à l’occasion du challenge USI 2011, nous nous sommes intéressés à différents serveurs et framework web NIO en Java. Le principe était simple en mettant à plat la spécification du challenge, nous avons identifié quelques besoins techniques :
- Une solution pour le marshalling JSON
- Un serveur web NIO supportant le long polling
- Une solution pour la persistence et le partage des données
Notre démarche a été de réaliser des POCs implémentant la création des utilisateurs et le long polling pour retenir la meilleure solution. La solution devait être simple et rapide à implémenter, et tenir une charge conséquente en la testant à l’aide de ab l’outil de benchmark Apache et de la librairie Async Http Client. Pour le JSON, nous nous sommes tous rapidement mis d’accord sur l’utilisation de la librairie Jackson. Nous étions tous convaincus qu’il nous faudrait un serveur web NIO sans passer par la case Servlet. C’est à partir de là que notre tour d’horizon des API NIO en Java a commencé.
Lire la suite de cet article »
Xebia vous propose de découvrir la mise en place d’une solution de monitoring basée sur des outils Open Source pour des applications Java.
Vous verrez au cours de cet atelier la mise en place d’une solution de monitoring pour une application déployée sur un cluster Tomcat. Pour cela, nous avons retenu les outils suivants :
- Graphite : Une solution de graphing de la génération d’après Cacti. Graphite est notamment utilisé par Google, Orbitz, Media Temple et Etsy ;
- JMXTrans : Un pont simple à mettre en œuvre entre les monde java/jmx et les outils de monitoring/time-series comme Graphite, Cacti ou Ganglia ;
- Nagios : « The Industry Standard In IT Infrastructure Monitoring » pour reprendre leur devise qui est assez méritée.
Cet atelier aura lieu le mercredi 2 novembre dans les locaux de Xebia au boulevard Haussmann. Vous pouvez dès maintenant vous inscrire sur Eventbrite. Nous vous tiendrons informés par Twitter et sur la page des Tech Event Xebia.
Xebia et Zenika s’étaient associés ce Jeudi 28 Juillet pour fêter la sortie de Java 7. La soirée fût l’occasion de présenter les nouveautés du JDK à travers deux présentations et une démonstration du Fork-Join. Nous tenons tout d’abord à remercier tous les participants pour cette belle soirée qui s’est d’ailleurs terminée tard dans la nuit ou tôt le matin selon le point de vue.
Voici pour celles et ceux qui n’étaient pas à la soirée où qui souhaiteraient en profiter encore une fois, les slides de notre présentation sur NIO 2.
Merci encore et à bientôt !
Nous avons déjà eu le plaisir d’annoncer sur ce blog que nous figurions parmi les trois équipes finalistes. Et nous sommes fiers d’annoncer que l’équipe Xebia, menée par Julien Buret et Séven Le Mesle, a remporté, mardi dernier, lors de l’USI, le challenge « Et si vous codiez une application qui supporte 1 milliard d’utilisateurs ? ».
Nous sommes certes restés loin du milliard… Mais sur 10 Vms (le challenge devait aboutir à un portage sur 100 vms, qui n’a pu être réalisé, faute de temps), l’application de quizz développée pour l’occasion offrait toujours des temps de réponses acceptables avec plus de 200 000 utilisateurs simultanés (des problèmes d’infrastructure ont empêché de monter la charge plus avant).
L’équipe Jaxio & Friends, ainsi que l’équipe Avricot (2 étudiants branchés C) complètent le podium.
Ce challenge donnera lieu à une rétrospective complète lors d’une soirée du Paris Jug, à la rentrée. Néanmoins, nous pouvons d’ores et déjà révéler certains choix architecturaux qui ont permis d’atteindre ces performances. Tout d’abord, fidèles à notre « ADN », l’application a été développée 100% en Java. Pour le reste, voici quelques uns des choix que nous avons faits :
- un frontal NIO, utilisant Netty. Etant données les contraintes du challenge, une architecture non bloquante était une nécessité. Après un phase d’intense prototypage, Netty est ressorti comme le serveur NIO répondant le mieux à nos besoins en terme d’utilisateurs simultanés et de temps de réponse. Les points qui nous ont fait pencher en sa faveur sont nombreux (100% Java, mise en œuvre simple et rapide, code source disponible et compréhensible, documentation correcte). Nous aurons l’occasion de développer ce choix et les différentes expérimentations que nous avons mené dans un article ultérieur.
- un cache et une persistance distribués reposant sur le produit commercial Gemfire, fournis dans les instances vFabric de VmWare. En utilisant Gemfire en mode peer-to-peer, la persistance et la distribution des données sont gérées de manière quasi transparente pour le client Java, et l’accès aux données n’est pas plus couteux (en terme de performance comme de complexité) que l’accès à une Map en mémoire.
- un choix de ne pas spécialiser les Vms : chacune des 10 Vms utilisées en phase finale était un clone de notre Vm initiale. Nous avons ainsi gagné en facilité de déploiement, d’administration et de débogage (et donc d’optimisation).
Ce challenge a donc été riche d’enseignements, tant au niveau de la technique (avec la mise en œuvre de produits assez inédits dans les architectures d’entreprise standard) qu’au niveau infrastructure (avec le déploiement sur un large cluster virtualisé).
Mais au delà de ces considérations, c’est avant tout une grande joie d’avoir pu exprimer notre savoir faire face à la crème des javaistes français.
Quelques liens :
Complet
Twitter
