samedi 4 octobre 2014

Jenkins et Scritpler : comprendre l'execution en mode distribué

Pour la mise en place de jobs de construction un peu tordu, la définition dans Jenkins est vite compliquée à gérer.
Il est plus judicieux de créer de scripter son job dans ce cas. Groovy est un intéressant, notamment pour les développeurs issus du monde Java.

Scriptler permet d’exécuter des scripts Grrovy sur Jenkins. Il est intéressant sur plusieurs points :

  • Permet de centraliser les scripts à un même endroit. Facilite la maintenance et la réutilisabilité
  • Les scripts sont paramétrables.
  • les scripts sont commités sur un repo Git local accessible via http://MON_SERVER_JENKINS/scritpler.git à chaque modification. C’est idéal pour pouvoir par la suite pusher vers d’autres repos et assurer ainsi leur sauvegarde. Dommage pour ce point il n’est pas possible de créer de hooks pour pusher automatiquement vers un repository remote, car JGit (le moteur Git de Jenkins) ne prends pas en compte les hooks. Il faudra donc trouver une autre solution pour pusher les commits vers un repo remote (via un Job Jenkins par exemple)
  • offre la possibilité de gérer l’exécution sur le master ou le slave. C’est sur ce point qu’il est utile de connaitre quelques subtilités.
  • Le job Jenkins execute les scripts Groovy de scripter en les référencant dans un build Step.

Scriptler possède deux systèmes d’exécution de scripts, pas ou peu documenté, voici les subtilités à connaitre lors d’un exécution en mode distribué :

Execution sur Master

Appelé “Restriction - Script is always executed on Master“. Dans ce mode, le script s’exécute sur le master dans la même VM que l’exécution du Job :

  • On dispose de l’API de Jenkins pour interagir avec les informations de build (par exemple, renommer un build).
  • On dispose des logs de construction.
  • On dispose des variables d’environnements du build dispo via http://MON_SERVEUR_JENKINS/env-vars.html/?.
    Attention : certaines variables sont relatives à l’exécuteur. Par exemple, $WORKSPACE indique le chemin du workspace sur l’exécuteur et donc, en mode distribué, sur le slave d’exécution.
  • Si l’exécuteur est un slave, le workspace - et donc les sources - ne sont pas accessibles.

Execution sur Slave

Type de script par défaut. Dans ce mode, le script s’exécute sur la même machine que l’exécuteur Jenkins (donc le slave) dans une VM différente. Il s’agit à un mode equivalent à l’execution de script via une commande groovy externe, hors Jenkins.

  • On ne dispose pas de l’API Jenkins.
  • On ne dispose des variables d’environnements du build. Il faudra passer en paramètres du scripts les variables dont on a besoin.
  • On dispose du workspace et donc, de toutes les ressources checkoutées, construites, etc.
  • On n’as pas accès aux logs construction.

En mode distribué, on se rend compte donc de certaines limitations.
un exemple concret :
Lire une information d’un fichier du workspace pour alimenter une description de build n’est pas faisable en mode distribué. Les sources du workspace sont sur le slave, et l’API de modification de description de build n’y est pas disponible (elle est disponible seulement sur le master). Mon billet sur “Afficher la révision comme numéro de build” n’est donc pas fonctionnel en mode distribué… :-(

A suivre…

mercredi 1 octobre 2014

Retour de DroidCon 2014

Pour cette seconde édition française, la conférence a eu lieu le 22 et 23 Septembre 2014 à Paris. 500 personnes étaient présentes. Trois thèmes sont abordés :

  • Android Everywhere
  • UI/UX
  • Android Development

Je suis loin d’être exhaustif, mais voici un rapide compte-rendu de ce que j’ai vu voir et ressentir de cette conférence.

Android Everywhere

Evidemment le gadget de cette année, c’était la montre connectée. Google ne pouvait évidemment pas reprendre Android tel quel car l’interface est trop petite et doit être adaptée : d’ou l’arrivée d’Android Wear : l’OS spécialisé pour les Wearables.

D’un point de vue ergonomie, on réduit l’approche disruptive de l’utilisation du téléphone (on checke son téléphone, pour vérifier si on a pas de messages, d’appels manqués, tout ça pendant qu’on parle à des amis). L’idée est donc de checker l’information plus souvent, plus rapidement, mais surtout que ce soit l’information qui arrive à l’utilisateur par rapport à son contexte : “show me the information before I even know I need it”. L’information est ensuite oubliée - approche “Fire and Forget”.

Concernant l’ergonomie, on est principalement sur des interactions minimalistes switch/tap. Pour les commandes plus avancées, on utilise la commande vocale “OK Google”.
La montre sous AndroidWear est un objet connecté, certes, mais surtout un objet “compagnon”. Elle a besoin d’un device maitre pour interagir. Dans le cas de gestion de la commande vocale, la montre se connecte au téléphone, puis le téléphone envoi la commande vocale aux serveurs de Google qui analysent puis redescendent l’information vers le téléphone, puis vers la montre.

On a donc 2 types d’applications :

  • Les notifications : toutes les applications qui apparaissent sur le téléphone apparaissent également sur la montre. Pas de développement spécifique dans ce cas.
  • Les applications. utilisées pour envoyer des données. Pour un UI spécifique, ou encore pour les commandes vocales.

Quelques ressources sympa :

UI/UX

Facebook, Twitter sont présents pour nous parler de leur processus de développement de leur application mobile. Un des points qui ressort de ces conférences, c’est que les applications mobiles ne sont clairement plus des “gadgets que l’on propose en plus de l’application Web”.

Il y’a clairement eu des ratés sur le développement d’applications mobiles. Un cas concret : Facebook et sa première application mobile : développée en HTML5 pour simplifiée les développements. Résultat : les développements ont en effet été simplifié, mais expérience utilisateur n’as pas été au rendez vous. Il est nécessaire de revoir la philosophie Web et de se tourner vers une philosophie “Mobile-first”, dans laquelle, on privilégie l’expérience utilisateur. Performance, ergonomie et interface adaptée au device (proche du natif).

Il est important aussi de prendre en compte l’expérience Cross-Plateforme comme favorisant la boucle d’engagement de l’utilisateur : Lui proposer un même application sur plusieurs platformes assure qu’il utilise cette application plus fréquemment. L’idée étant de fidéliser un utilisateur avec un application, peut importe le support. Plus il s’engage et plus la monétisation est potentiellement importante.
(c’est l’approche proposée par Amazon GameCircle pour les jeux : on commencer une partie sur un device et on la continue sur un autre).
Mais avant tout il faut savoir ce que veut l’utilisateur. le comment et pas le pourquoi. L’utilisation et pas application.
L’idée pour connaitre l’engagement, c’est de mesurer, d’apprendre des utilisateurs. Mesurer, Itérer et améliorer.
L’approche A/B Testing et de feature flipping est beaucoup mise en avant pour le développement mobile. Le Feature-flipping a une vraie plus-value, notamment pour corriger rapidement des features non compatibles sur certains devices.
Enfin, il est toujours utile de tester l’application sur soi même : Eat you own dogfood est également une bonne pratique pour tester l’application en condition réelle sur soit même. Pour les bêta tests, il est bon de savoir que Google propose des canaux de distributions pour les applications en cours de développement : Google Play Alpha Channel et Google Play Bêta Channel.

Côté UI, c’est évidemment le Material Design est qui est la grosse évolution graphique apportée par Android L. On retrouve des concepts nouveaux (Floating Action Button) ou qui sont mis beaucoup plus en avant (Cards). Ces deux dernières fonctionnalités sont rétro-compatibles avec le support v7.
Les animations et les Ripple Effets sont par contre spécifiques à Android L (API 21).
L’idée derrière Material Design est de proposer un thème Cross-platform qui devienne le standard graphique pour les applications Google, que ce soit les apps Web (Google Drive récemment), Android ou Chrome OS.

aucun rapport mais rigolo : Gource. Un outils de visualisation graphique d’un dépot SVN.

Quelques ressources intéressantes :

Android Development

Beaucoup de présentation sur des libraries ou langages permettant de simplifier les développements Android. Ce qu’il en ressort, c’est que le développement d’application Android est assez boiler-plate et qu’il faut mettre en place des approches pour simplifier le développement et faciliter la maintenance. Plusieurs approches :

  • Injection de ByteCode à la compilation via Mimic ou AfterBurner ( Stéphane Nicolas).
  • Développement en Groovy sur Android (Guillaume Laforge). Java est trop verbeux. Groovy réduit les coûts de développement, facilite la lecture et la maintenance.
  • utilisation de la Functional Reactive Programming via RxJava et RxAndroid pour fluidifier les compositions d’appels asynchrones.

Zoom sur les bibliothèques d’annotations : ButterKnife / RoboGuice (@InjectViews), Dagger / RoboGuice (@Inject), Otto / RoboGuice / EventBus (@Observes), Memento / IcePick (@Statefull), Hugo (@Log). Il serait judicieux que ces annotations deviennent des standards intégrés à une prochaine version d’Android (…mais quand? )

Zoom sur les bibliothèques pour mieux découper son application : Dagger (dependency injection), Mortar découpage MVC.

Aucun rapport mais utile : Droid@Screen, l’outil que les conférenciers utilisent pour partager leur écran pendant les conférences. Il souffre toujours d’un petit problème de lag, mais reste un outil super utile pour les présentations.

Concernant les processus de développements, les retours laissent apparaitre que les outils manquent parfois de maturité.
C’est notamment le cas sur les frameworks de tests d’intégration (Functional Testing). Deux challengers se démarquent : Robotium et Espresso. Malgré que ce dernier soit encore en version bêta, il semble plus prometteur : meilleurs performances, développement plus cohérents, système de matchers issus de Hamcrest plus adaptable.
Concernant les IDE, tout le monde semble être passé à Android Studio (lui aussi encore en bêta) et utilise Gradle pour la construction des applications.
Beaucoup de bêta et les retours laissent à penser que l’écosystème n’est pas encore tout à fait mature !

Les stands

Microsoft est présent pour nous parler de Xamarin, mais également de remettre en avant Visual Studio qui intègre Unity - la plateforme de développement de jeux 3D - et également Cordova et le debugger JS intégré.

Amazon est présent pour nous présenter son écosystem Amazon App Store, qui porte pour l’instant 240’000 applications mais qui a pour vocation de rattraper le Play Store (qui lui en a quelques 1 400 000 !). L’idée de l’Amazon App Store est de centraliser les achats ( qu’ils soient physiques, virtuels ou in-app) et de faciliter la monétisation des apps en proposant des achats One-Click in-app (Acheter un T-shirt Angry bird dans son jeu sera possible !). Ils présentent également leur gamme Fire, notamment le FirePhone et son interface Dynamic Perspective qui suit les mouvements de tête.

Intel présente les outils de tracking permettant d’optimiser les performances des applications, notamment via GPA orienté GPU ou INDE.
Il y’avait aussi Alcatel qui présentait sa gamme One Touch, notamment un téléphone “compagnon” qui se connecte en bluetooth sur une tablette trop grosse pour tenir dans la poche; ID.Apps, éditeur d’applications mobiles, Xebia, Octo, et également GenyMobile qui présentait notamment GenyMotion, son “super-fast Android Emulator”.

zoom sur : GenyMotion, anciennement AndroVM, propose une VM Android qui s’éxecute dans un VirtualBox. Il ne s’agit pas d’émulation, mais bien de VM (sur archi x86). Bien plus performant. GenyMotion intègre en plus un ensemble d’interface pour simuler les capteurs. Approche très intéressante pour les tests. avec prochainement une possibilité de scripting à la Vagrant.

Pour finir

Pour ceux qui souhaitent voir des photos, vous pouvez jeter un oeil sur Flickr BeMyApp
Tous les talks ont été filmés : je mettrai le lien dès que les vidéos seront dispo.
Vous pouvez quand même jeter un oeil sur le site officiel.

Petit apparté : Après plusieurs mois de non-blogging, je me décide enfin à reprendre l’écriture. La plateforme Blogger est sympa, mais l’éditeur WYSIWYG, me laisse un peu…perplexe, d’autant plus qu’il me crache du code HTML pas forcément tip-top que je dois me retaper à la main.
Du coup, je tente une nouvelle approche, en écrivant en Markdown dans StackEdit qui permet de publier vers Blogger (entre autre).