Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Mobilité

Web

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Mobilité

Android Developers sur Google+

Depuis début février, sur le site d’Android Developers, on peut voir que Google a créé sa propre page Android Developers sur son réseau social Google+. Cette dernière permet de suivre toute l’actualité concernant la plateforme Android (release, tips, hangouts, interviews…).

De nombreuses vidéos (dont la qualité n’est pas toujours optimale, il faut l’admettre) sont d’ores et déjà mises en ligne. Une des plus intéressantes reste le tutoriel sur la création de graphiques 9-patch pour apprendre à personnaliser ses composants. Avec le temps ce fil d’actualités sera une véritable mine d’informations pour tous les développeurs Android.

Un nouveau site pour le design d’applications Android

Avec désormais plus de 500 000 applications sur l’android market, les détenteurs de smartphone Android ont tous au moins une fois téléchargé une application dont le graphisme laissait à désirer. Hors l’UI est LA première accroche lorsqu’un utilisateur lancera votre application une fois téléchargée.

Des conseils de design étaient déjà prodigués dans le developer guide, malheureusement ces derniers étaient dispatchés dans diverses sections sans corrélation évidente. Google a donc décidé de regrouper tous ces conseils et bonnes pratiques en un seul lieu avec des exemples illustrés clairs, passant en revue les différentes parties graphiques d’une application :

  • icônes
  • nouveau design d’Android 4.0
  • navigation
  • structure d’une application
  • prise en compte des différentes tailles d’écran

N’hésitez pas à aller faire un tour, le site est vraiment bien conçu et peut se révéler extrêmement utile.

Web

Sortie de Dartium

Il y a maintenant plus d’un an, une note interne de chez Google déclarait que « Dash » (l’ancien nom du langage Dart) devait à terme s’imposer sur le Web et remplacer Javascript…

Google continue dans cette lancé en livrant sa première release du navigateurChromium- rebaptisé Dartium pour l’occasion – incluant la VMDart, cette mouture permet donc de faire tourner Dart directement, alors que jusqu’à maintenant le langage devait être traduit en Javascript pour pouvoir s’exécuter sur le navigateur. Cette dernière solution reste d’ailleurs nécessaire pour faire fonctionner le langage sur les autres navigateurs du marché.

En décembre dernier, Google avait proposé aux développeurs de WebKit d’intégrer une VM multi-langages au sein du moteur, par le biais d’un patch déjà fonctionnel. Ce dernier était fourni avec une implémentation partiellement fonctionnelle d’une VM Dart. La proposition avait cependant été rejetée par crainte de voir des applications ou des sites ne fonctionnant qu’avec un nombre réduit de navigateurs. On notera d’ailleurs que cette position est également tenue par Microsoft, qui n’approuve pas l’initiative et préfère que l’on améliore Javascript.

Pour rappel Dart est un langage de programmation web côté client proposant, entre autre :

  • Le typage statique optionel : Permettant le production rapide de poc, mais aussi de projet plus large.
  • Une approche orienté Objet (à l’inverse du paradigme prototype de Javascript)
  • Un outillage plus évolué : L’éditeur déjà existant et le design du langage permettront un support et des contrôles supplémentaires en phase de développement.

Dartium est disponible sous Linux et Mac (les utilisateurs de Windows devront attendre encore un peu), désormais on attend un comparatif de performance des deux langages !

Le coin de la technique

Kotlin devient Open-Source

Etrange cadeau pour la Saint Valentin, JetBrains a annoncé, le 14 février, que son langage Kotlin devenait officiellement Open-Source.

Kotlin est un langage de programmation qui peut être compilé en bytecode sur la JVM ou en Javascript. Côté syntaxe, Kotlin se veut à mi-chemin entre Java et Scala : il n’offre pas autant de possiblités que Scala mais adresse de nombreuses problématiques de Java.

Plus exactement, voici les composants qui sont passés sous licence Apache2 :

  • Le compilateur
  • Les plugins Kotlin des outils de build comme Maven, Ant et Gradle
  • Le plugin pour IntelliJ
  • Diverses améliorations de librairies Java

Bien que toujours en cours de développement, cette annonce pourrait bien accélérer le développement et l’adoption de ce langage.

Le code source de Kotlin est disponible sur le GitHub du projet.

Les quatre principes fondamentaux du Continuous Delivery

Si vous vous intéressez au sujet « Continuous Delivery », vous avez certainement entendu parler de Jez Humble, le coauteur du livre repère sur le sujet. Jez revient dans un billet sur le site www.informit.com sur les quatre principes fondamentaux pour arriver selon lui à un déploiement continu et sans risque :

  • Les livraisons à moindre risque sont incrémentales
  • Découpler la livraison du déploiement
  • S’engager à réduire la taille des itérations de livraison
  • Optimiser le processus pour la résilience

Schémas à l’appui, Jez revient sur les notions de blue-green-deployment, de canary-deployment, cluster immune system ou encore Dark Launching. Que ces exemples viennent de son expérience propre, de Flickr ou Facebook, le but est toujours le même: livrer le plus souvent possible le produit en production toute en maitrisant le risque. Cette idée est en accord avec le manifeste agile. Livrer régulièrement son travail permet d’avoir une boucle de retour plus efficace. Cela permet aussi de réduire le temps de mise sur le marché d’une solution, le fameux time-to-market.

Si on travaille selon ces 4 axes, il est possible d’avoir des livraisons plus fréquentes car moins risquées et incrémentales. Si chaque livraison n’écrase pas la précédente, on peut revenir rapidement en arrière. Jez nous indique qu’il est important de découpler la livraison de la mise à disposition des utilisateurs. On réduit encore le risque en maîtrisant la population d’utilisateurs qui a accès à certaines fonctionnalités, ce qui facilite la montée en charge.
Pour Jez, mieux vaut avoir un système simple, capable d’être remis en état rapidement plutôt qu’un système complexe, sensé être robuste, mais qu’il est impossible de restaurer facilement.

Bien sûr, il y a un surcoût en développement et un ticket d’entrée qui peut être important. Mais le retour sur investissement peut être rapidement identifié. Combien de Product Owners s’inquiètent du temps entre la sortie de leur stories dans le backlog et sa mise à disposition aux utilisateurs ?

Evènements de notre communauté en France et à l’étranger

Premier meetup du Hadoop User Group France, le 15 mars à Paris

Un nouveau user group est en train de se former : le Hadoop User Group France. Un premier rendez-vous est prévu pour le 15 mars. L’évènement est en cours d’organisation. Si vous souhaitez y assister, que cela soit en tant que simple spectateur ou afin de présenter un sujet, n’hésitez pas à vous manifester.

Un commentaire

  • Bon, hé bien, en résumé, il y a les options suivantes sur la table pour améliorer le support des langages coté client (ce qui permettrait de faire du dev un peu plus à la Flex par ex) :

    1) amélioration JavaScript, par exemple, en lui associant la notion de package, de type statique optionel…
    Les dev pourraient tjrs utiliser le noyau non typé de JavaScript, et ceux qui voudraient un meilleur langage pour programmer « en masse », avec de meilleurs perfs, seraient aussi servis. Au moins, on pourrait utiliser le même langage, mais en tirant parti de caractéristiques différentes, pour le dev des pages web et pour le développement d’apps web (à la Flex, ou HTML 5).

    2) une JVM multi-langage
    Dans les navigateurs, il existe une VM mais pour un langage dynamique seulement (JavaScript).
    Pourquoi pas y adjoindre une VM mais cette fois-ci pour les langages à typage statique ? Normalement, une telle VM devrait faire consensus si seule est définie la spec du byte-code qu’elle supporte et qu’elle soit libre de supporter divers langages (idem la JVM et la VM de .Net).
    En fait, on a eu précédemment une telle VM, coté client, pour langages à typage statique, i.e. la JVM, mais la JVM et/ou l’intégration avec le navigateur étaient moyennes.

    3) un processus de compilation (via LLVM) produisant du JavaScript optimisé, à partir d’un langage source
    Quant on voit – http://blog.mrale.ph/post/12396216081/the-trap-of-the-performance-sweet-spot – à quel point il faut complexifier un code JavaScript pour le rendre vraiment performant, on se dit qu’il vaut mieux que le code JavaScript soit généré.

    Mais bon, dans les faits:
    1) ces améliorations JavaScript (ECMAScript Harmony) sont sur la table depuis qques temps et ne semblent pas avoir trouvé preneur (opposition de Brendan Eich)
    2) l’idée d’avoir 2 VM dans un navigateur est sous-optimal (comparé à 1), mais pkoi pas. Pas de bol pour Google qui a reçu un refus des gars de WebKit, alors que sa VM avait bien l’air multi-langage.
    3) reste que cette option pour produire du JS performant. Mais la chaine de compilationn se complexifie encore et encore.

    Ca me rappelle les propos d’un développeur Flex à propos de HTML/JS : « Instead of investing time in thinking about creativity, features and functionality of the app, we have to waste time just making it work. »

    Conclusion: leur guéguerre continue à rendre le web dev bien chiant…

Laisser un commentaire