Vous pouvez retrouver Olivier Lombard :

• Sur son compte Twitter – @OLombardPilote
• Sur sa page Facebook – Olivier Lombard / Pilote
• Son site internet – Olivier Lombard site officiel

Souhaitons lui bonne chance pour Mugello les 6/7 juillet prochains.

Bonjour,

Si vous n’avez pas eu le temps de regarder jusque tôt ce matin la Google IO qui a commencé ce mercredi 15 Mai, je l’ai fait pour vous. ;-)
Je ne vous parlerai pas des Google Glass ou encore du Samsung GalaxyS4 version Google avec la dernière ROM Android, sans la couche du constructeur. Mais je vais vous parler des choses qui concernent plus les développeurs.

IntelliJ

Parmi les choses qui m’ont intéressé, j’ai pu noter un nouvel IDE Basé sur ItelliJ.
On récupère ainsi toute la puissance de cet IDE au niveau de l’intelligence de complétion Java ou encore les propositions de résolutions des erreurs.
La recherche rapide, de classes ou tout simplement de texte dans tout votre code.

En plus des choses dont on disposait déjà dans IntelliJ, Google y a ajouté des outils spécifiques pour Android. Par exemple, on peut remplacer visuellement dans le code Java la valeur des R.string.XXX. On peut avoir un rendu visuel d’un layout en même temps qu’on l’écrit.
On dispose également d’outils assez puissant comme le test d’expression régulière.

L’IDE est disponible ici :
http://developer.android.com/sdk/installing/studio.html#download

Volley

Une petite librairie a également été présentée. Elle permet de gérer les requêtes HTTP.
La bibliothèque à l’air assez légère, elle ne comprend que 40 classes, groupées en 2 packages.
Cette bibliothèque permet de gérer les points suivant:

- gestion des événements d’erreur et de retour avec des callback respectives.

- Gestion des requêtes avec DefaultHttpClient pour les devices sous froyo et antérieur et avec la classe HttpURLConnection pour ICS et supérieur.

- Gestion des priorités dans les requêtes HTTP. IL y a 3 niveaux HIGT, MEDIUM, et LOW

- On peut annuler des requêtes HTTP (je pense que cela empêche uniquement l’appel de la callback onResponse()

- Possibilité d’utiliser une classe spéciale pour les downloads d’images: ImageLoader.

- Gestion d’un cache mémoire et d’un cache fichier.

La bibliothèque est disponible ici : https://android.googlesource.com/platform/frameworks/volley

Level up your android game

C’était une petite session à 2h30 du matin durant laquelle ont été présenté des conseils, pour faire en sorte qu’une application soit populaire sur le Play store. Surtout pour les jeux donc.

Parmi ces conseils, qui peuvent s’appliquer à tout type d’application, j’ai pu noter :
- se préoccuper de la compatibilité avec les différentes tailles et résolutions d’appareil Android : smartphone, tablette 7 et 10 puces. Gérer des interfaces appropriées ;
- éviter les permissions non populaires comme celles qui permettent d’exécuter des tâches au démarrage, ou lire les logs du téléphone, etc… ;
- bien tester l’application avant chaque livraison ;
- faire des mises à jour avec des ajouts de fonctionnalités ;
- se préoccuper du support des langues ;
- utiliser les interactions avec les réseaux sociaux ;
- mettre une vidéo de démonstration de l’application sur le market, via YouTube.

La suite…

Voilà je vous laisse découvrir par vous-même la suite en live streaming ici :
https://developers.google.com/events/io/

Il faudra attendre encore un peu, Juin 2013, pour découvrir les versions CC des softs Adobe !

Au travers de ces différentes conférences, la tendance incite à bâtir nos nouvelles applications sur une architecture Web Oriented Architecture (WOA), leurs données stockées dans des bases NoSQL et leurs interfaces utilisateur basées sur HTML5, CSS3 et Javascript. Bâties de cette manière ces applications sont scalables mais aussi supervisables une fois déployées dans un Cloud.

Pour mon planning et les pointeurs vers les technologies que j’ai retenu, vous pouvez vous référez ici.

Architecture WOA

Je vous conseille pour bien comprendre pourquoi Habib Guergachi fait tant l’apologie des applications basées sur une architecture WOA, de coupler les conférences du Devoxx France 2012 puis celle de 2013. Habib Guergachi est très pédagogique et a l’art de la formule et des images pour faire passer son message.

Ce que j’en ai retenu, c’est de bâtir nos futures applications en exposant nos services via une API REST accessibles via le protocole HTTP. Vous pouvez lire sur le sujet cet article de Martin Fowler.
L’autre grand point est de se concentrer sur les services qui sont le cœur de métier de l’entreprise et de consommer les autres services spécifiques via des services exposés par des prestataires externes. Ces mêmes services étant eux aussi des services REST.

Habib démontre bien qu’aujourd’hui nous arrivons aux limites du tout intégré. Les entreprises veulent avoir tout les services en interne et les intégrer ensemble avec des technologies complexes. Cela à un coût et c’est très complexe contrairement à une architecture type WOA où tout les services inter-opèrent en exposant des ressources accessibles via une URI. C’est le fameux RELAX d’Habib (Rest + Stateless + Asynchrone).

Cette nouvelle architecture ne vas pas sans de nouveaux défis à appréhender telle que la sécurité et l’authentification. Aujourd’hui, les briques techniques sont là, il nous reste à bien les faire fonctionner. Elles se basent sur du concret, du solide et ont fait leurs preuves : HTTP et la sécurité via OAuth, par exemple, déjà utilisés par les grands du web.

Stockage des données et bases NoSQL

La meilleure démo, à laquelle j’ai pu assister, est celle du basculement d’une application courante de SQL en NoSQL. A remettre en perspective avec les discours d’Habib du Devoxx2012 et 2013 sur les applications WOA. C’est typiquement une mise en œuvre de ces principes.

En effet, nos deux speakers nous démontrent qu’il est assez aisé de basculer d’une application JEE standard vers une application WOA, et ainsi de la rendre scalable. De lui permettre de remonter des données très rapidement, les indexer et faire des recherches fulltext dignes du moteur de recherche de google. A ce propos rafraîchissez vous la mémoire avec l’exemple de la conférence d’Habib avec le moteur de recherche de la BNF qui est loin derrière celui de google pour retrouver ou proposer des résultats même mal orthographiés.
Voici les étapes du rafraîchissement de l’application :
1-Exposer les services via une API Rest
2-Mettre en place une base de données NoSQL CouchBase accessible depuis une URI
3-Remplacer les requêtes des services pour appeler cette URI via un client HTTP
4-Délégation de l’indexation à ElasticSearch pour gérer la recherche fulltext

ElasticSearch est configuré avec CouchBase et inversement. La vitesse où le million d’enregistrements sont gérés par les deux outils est tout simplement ahurissante !

ElasticSearch possède des plugins dont un est particulièrement efficace pour faire du reporting sur les datas, il s’agit de Kibana. Pour ceux qui ont déjà utilisés les produits de BI du marché, vous allez être tout simplement stupéfaits, écœurés et vous empresser de tester ce nouvel outil.

Allez lire les articles de Gaëtan Le Brun sur le sujet notamment son retour du Devoxx 2013 et sa comparaison SQL versus NoSQL.

Le trio : HTML5, CSS3 et l’écosystème JS

Nous avons vu le côté Back avec les services et la persistance des données. Quid du Front ? Ne cherchez pas plus loin pour vos frontaux web, dirigez-vous vers AngularJS.
Aujourd’hui l’écosystème javascript n’a rien à envier à celui de Java. Vous avez tout les outils et frameworks qui vous rendent plus productif pour :
- faire des tests unitaires
- automatiser votre build
- gérer vos dépendances
- et pour le déploiement ? c’est juste un zip :)

Sur ce dernier point, il est aisé de comparer avec l’univers JEE et le packaging de l’application via un EAR, qui peut-être complexe à construire selon les projets.

Pour ceux qui seraient restés sur des aprioris, « le JS c’est pas propre », allez voir cette conférence. Avec tout les conseils des speakers, il est aisé de construire du code JS propre, lisible et maintenable. Pour avoir un aperçu des outils utilisés côté écosystème JS, je vous suggère de lire les articles de Gaëtan Le Brun, ici et ici.

Comme dirait Habib encore une fois, qu’attendons nous pour y aller ? De nous faire virer dans la honte où bien de démissionner dans l’honneur ?

A nous d’être agiles et de saisir ce qui se présente devant nous pour enfin développer des services focalisés uniquement sur les problématiques métiers et passer moins de temps sur des problématiques techniques de développement et d’intégration, liés aux technologies d’aujourd’hui mâtures qui sont celles d’hier et qui nous font souvent souffrir au quotidien.

Héberger ces applications dans un Cloud

En parallèle et dans le même esprit, rien ne sert de prendre en charge l’infrastructure. Mieux vaut s’appuyer sur du Cloud en mode PaaS et avoir une supervision de la consommation et des coûts réels de chaque service. A ce titre, regarder la keynote d’Alexis Moussine-pouchkine qui présente bien les enjeux du basculement dans ce mode. Ni plus, ni moins de savoir exactement combien coûte un service par utilisateur !

Pour de petites structures, il est difficile de pouvoir gérer toute l’infrastructure. En s’appuyant sur le Cloud, elles peuvent s’abstraire de ces contraintes qui sont gérées par des spécialistes.

Un autre avantage du Cloud est sa capacité à rendre supervisable les applications sur différents critères, et ainsi de rendre les entreprises capables de valoriser un coût par utilisateur, et ainsi permettre au DSI d’identifier, de décider, d’améliorer les services à destination des utilisateurs ou de partenaires externes. Il peut faire le lien entre budget investi et retour sur investissement, et ce de manière précise.

Pour se rendre compte de la puissance et de la simplicité du Cloud, testez CloudBees.

Conclusion

En développant des applications basées sur les concepts WOA, l’entreprise déploie ses services et les expose en se basant sur des technologies connues et éprouvées qui résolvent nativement un grand nombre de problématiques (découplage, scalabilité, …).

L’entreprise doit être pragmatique et se concentrer sur des services liés à son cœur de métier et s’appuyer sur des services tiers pour les autres besoins. Cette manière de voir les choses est à l’encontre de ce qui se fait aujourd’hui, comme l’indique Habib, où les entreprises ressemblent plus à des châteaux forts et sont moins ouvertes sur l’extérieur. A l’inverse, celles qui ont pris le virage inverse sont faciles à identifier :).

Pour se concentrer encore plus sur son cœur de métier, l’entreprise peut aussi déporter son infrastructure dans un Cloud privé ou public pour se décharger d’une lourde charge et laisser des experts du secteur gérer les problématiques de scalabilité.

Ces conférences auront rappelé, si ce n’était pas encore une évidence, que la qualité des développements passent par des tests automatisés et la mise en place d’usines logicielles en évitant d’être dogmatique sur les pratiques et les méthodes.

Pour mon planning et les pointeurs vers les technologies que j’ai retenu, vous pouvez vous référez ici.

De compiletout.bat a l’Usine Logicielle pour Java

La conférence de Guillaume Rams est exhaustive et synthétique et permet d’avoir un rapide tour d’horizon des outils :
- de gestion de sources
- d’automatisation du build
- de gestion des dépendances
- de référentiel d’artifact
- d’intégration continue
- de déploiement continue
- de développement intégré (IDE)
- de qualimétrie
- de cloud computing (plateforme as a service)

Guillaume rappel et met en avant que :
- le déploiement doit être automatisable car il nécessite un grand nombre de paramétrages en fonction des environnements de test, d’intégration, de recette et de production (données, conf serveurs web, conf bdd, …).
- certains outils sont très encadrants donc dogmatiques, tel Maven, si vous devez les tordre alors ne les utilisez pas
- les outils de qualimétrie ne remplacent pas le pair-programming et la transmission de savoir dans l’équipe. Ils sont là pour alerter et challenger.
- vérifier que les outils fonctionnent en déconnecté pour ne pas perdre en productivité et facilité l’utilisation nomade (ex: gestion de source décentralisée avec Git)
- UML ne peut pas tout décrire, mais le garder pour définir des diagrammes de séquences complexes

Très bonne idée de Guillaume d’avoir structuré sous la forme : pratiques usuelles, challengers, perte de vitesse.  J’y ai retrouvé mes outils du quotidien, à savoir : Eclipse, Git, Gradle bien loin de nos premiers .bat :). Et vous ? N’hésitez pas, c’est ici pour les slides.

XWiki et Sonar, de très bons retours d’expériences

Les retours issus des projets XWiki et Sonar sont très instructifs. Les speakers précisent bien que leur expérience est valable dans leur contexte et si certaines de leurs solutions peuvent s’appliquer à votre contexte tant mieux.

En effet, dans un projet de nombreux facteurs interviennent (ressources disponibles, politique de l’entreprise, maturité des mentalités, compétences, et bien d’autres encore …) qui peuvent empêcher la mise en oeuvre de ces solutions.

Si vous ne connaissez pas et si vous voulez connaître d’autres manières d’appliquer Scrum dans vos projets, vous pouvez lire l’excellent « Scrum depuis les tranchées » d’Henrik Kniberg.

REX XWiki : Implémenter la qualité sur un projet Java

Implémenter de la qualité sur un projet de développement fait appel à de nombreuses techniques (méthodologies, design du code,  design des packages, design des modules, …), c’est pourquoi Vincent Massol s’est focusé sur 5 pratiques, à savoir :
- Test Coverage
- Track Bugs
- Stable Automated functionnal Test
- Ensure API Stability
- Prevent Jar Hell

Pour chacune des pratiques, il rappelle les problématiques associées, et dans le contexte de XWiki quelles solutions ont été mises en oeuvre, principalement en s’appuyant sur des plugins maven.

Test Coverage

- Problème : sans stratégie de code coverage possibilité que les bugs augmentent
- Stratégie : jacoco-maven-plugin avec une configuration basée sur un ratio par module qui bloque le build

Track Bugs

- Problème : nombre de bugs créés est supérieur au nombre de bugs clôturés
- Stratégie : 1 jour par semaine consacré à réduire le nombre de bugs (requiert un leader pour challenger l’équipe :) avec un tableau de suivi.

Stable Automated functionnal Test

- Problème : beaucoup de faux positifs liés aux environnements d’exécution, des données corrompues, ressources non disponibles, …
- Stratégie : ajouter sur Jenkins les plugins groovy postbuild, Email-ext (PreSend Script),Scriptler pour gérer ce comportement sur tout les jobs.

Ensure API Stability

- Problème : assurer la bonne utilisation des api publiques et/ou privées au cours de leurs évolutions
- Stratégie : @Deprecated, plugin maven clirr, package internal, module legacy, création annotation custom @Unstable (garde fou pour les jeunes api), Java8 et Virtual Extension/Defender method.

Prevent Jar Hell

- Problème : Runtime Class Not Found / Method Not Found (ex: slf4j-api 1.4.0 et logback-0.9.9)
- Stratégie : maven-duplicate-finder-plugin (No duplicate Class au Runtime), maven-enforcer-plugin

REX Sonar : 5 ans et 500 releases en 50 minutes !

Pour ce retour d’expérience, très bien mené, ce que j’en ai retenu de nouveau.

La maintenance des Tests d’Intégration (TI) devient un véritable investissement. Chez Sonar, ils ont développés un framework pour aider à bâtir les TIs.

Il faut se protéger des TIs faux positifs en écrivant des tests qui prennent en compte l’absence des ressources (timeout, messages explicites d’erreurs, …)

La gestion d’équipe agile est difficile avec le télétravail (national ou international) et nécessite une rigueur dans les horaires de chacun pour être là quand l’équipe est au complet. Le développeur qui travaille jusqu’à 3h du matin et n’est pas là pour la Daily Scrum c’est pénalisant.

Les tests: pourquoi et comment ?

Les 3 speakers étaient excellents d’autant plus qu’ils travaillent chacun dans des domaines différents, à savoir : définition des besoins en tant qu’assistant PO, Développeur Back Office Java, Développeur Front Office JS.

Leur expérience est basée sur leur mission actuelle chez Mappy qui a fait naître des bonnes pratiques de test dans chacun de ses domaines. De plus, ils indiquent les outils qu’ils ont utilisés, de quoi enrichir notre boîte à outils.

Ils ont conduit leurs conférences selon 3 axes : Pourquoi tester ? Comment ? Notre expérience.

Pourquoi tester ? et Comment ?

Pourquoi tester ?
- Nous pouvons obtenir la spécification du produit directement dans le code grâce au test.
- Rend plus lisible l’objectif du code et aide au Definition of Done (DoD) et le Reste à Faire (RAF)
- Permet de détecter les problèmes au plus tôt pour les débugger

Comment ?
Il faut définir une stratégie en amont pour que l’équipe soit alignée :
- frameworks à utiliser et manière d’écrire les tests
- mise en place de Code Review
- mise en place de Coding Dojo pour résoudre des problèmes simples et ainsi respecter les principes et obtenir une homogénéité des développements
- essayer de faire cela en mode jeu, par exemple avec des plugins sous eclipse (PairHero, TDGotchi)
- mettre un binôme responsable de la maintenance du build

Notre Expérience

Aider et accompagner les équipes à se former sur TDD. Il ne faut pas être dogmatique sur les tests et diffuser la pratique du TDD par le lead, c’est à dire l’avoir pratiqué soit même et montrer les bienfaits par la pratique pour que autres membres de l’équipe adhèrent ou non mais sur des bases concrètes.

Un petit tableau récapitulatif des axes à suivre.
—

—
Savoir prioriser
- vérifier les contrats des APIs en priorité avec des tests sur les services
- utiliser la priorisation verticale (pyramide de Mike Cohn)
- utiliser la priorisation horizontale (chemin critique)
- utiliser The MoSCoW principle sur les fonctionnalités
- savoir créer des tests boîtes noires de plus haut niveau sans faire de tests sur les éléments constitutifs

Partager
- tests écris par l’équipe et le PO via Fitnesse
- le produit est accessible à tout le monde
- les tests sont accessibles à tout le monde

Lisibilité
- utilisation du Given/When/Then (les tests doivent êtres moins compliqués que le code)
- utilisation des underscore (_) plutôt que CamelCase (intention du test dans le nom de méthode devrait être suffisant)
- soyez explicite en détaillant avec des variables
- asserThat(xml).isWellFormed() (factoriser les assertions)

Facilité d’écriture
- passer très peu de temps à écrire les tests en s’appuyant sur des frameworks de test (bien lire les fonctionnalités)
- utiliser des Fixtures pour alimenter les datas
- factorisation des données avec des Factory
- factoriser le code avec @Parameters

Choix de technos reconnues et partagées par l’équipe
- CasperJS (valider interface web) au lieu de code java Selenium
- PhantomJS (création de screenshots des pages webs)
- Webkit ou V8

Rapidité d’exécution
- @test(timeout=1000)
- Assume.assumeTrue(canWriteInThatEnvironnement())  (vérification de Ressources avec JUnit)
- @BeforeClass et @AfterClass (rendre très petite l’empreinte mémoire et CPU)
- Fixture vs Factory
- éviter les injections de dépendances au profit des Mock/Stub
- 1 besoin par test
- tools Infinitest pour prioriser les tests et avoir un feedback au plus tôt.
- utiliser AssertThat au lieu de AsserTrue et utiliser la chaine texte si jamais KO dans les tests

Paralléliser
- utiliser GNU Parallel
- paramétrer votre usine logicielle pour qu’elle soit scalable (ici un exemple avec Jenkins)

Analyser
- analyser les traces des tests
- les traces doivent être utilisables par d’autres services (ex: cellule qualité logicielle)

Améliorer
- détection en continue des problèmes dans les données
- mise en place de Watchdog pour vérifier que les données sont correctes et non corrompues
- passer les tests sur les environnements de prod
- ne pas couvrir le code à 100% mais plutôt s’orienter sur une couverture fonctionnelle du code (le PO est ainsi satisfait car le produit réponds aux attentes)
- un bug = un nouveau test ou = une correction de test ou = une modification de test existant si c’est un nouveau besoin produit
- détection des comportements utilisateurs en analysant les logs

Refactorer
- type 1, pas de changement du périmètre fonctionnel seulement en terme de performance et de design
- type 2, changement du périmètre  fonctionnel nécessite de changer le test
- attention à ne pas faire les deux en même temps

Comprendre les bug
Par exemple entre 2 releases si des problèmes de performances apparaissent et vous souhaitez savoir quel commit a introduit la défaillance ? Vous pouvez utiliser git-bisect.

Conclusion

Pour que votre investissement dans vos tests ne représentent que 50% de charge en plus : Soignez vos tests en vous appuyant sur des outils reconnus par l’équipe et suivez les bonnes pratiques !

Pour mon planning et les pointeurs vers les technologies que j’ai retenu, vous pouvez vous référez ici.

Programmation fonctionnelle avec Scala

En suivant le Hands-on Scala et la keynote de Martin Odersky, ce que j’en ai retenu c’est la puissance du paradigme de la programmation fonctionnelle et surtout la nécessité de programmer avec des structures immutables pour se prémunir des effets de bord, faciliter l’optimisation et la scalabilité des applications en les rendant ThreadSafe.

Scala est conçu nativement avec cette notion d’immutabilité. Il faut ajouter des mot clés pour rendre mutable des champs ce qui n’est évidemment pas le cas en Java où il faut du code technique supplémentaire pour y arriver. A ce titre, jetez un œil à l’api gs-collections.

Le paradigme de la programmation fonctionnelle apporte des nouveaux concepts qu’il faut impérativement maîtriser pour éviter de développer à 10 000 pieds. Je vous conseille cette très bonne vidéo Abstraction Distraction du Devoxx 2012. Neal Ford rappelle très justement que l’utilisation des abstractions nécessite la compréhension de leur niveau n-1.

Le Hands-On sur scala m’aura permis d’appréhender que ce langage, bien que puissant,  est à mettre entre des mains expérimentées. Il faut bien comprendre les concepts et les mécanismes que masque le langage lors du développement. Ce qui rend peu aisé en première approche la création de son code d’une part et aussi sa relecture.

Si vous êtes intéressez pour faire de la programmation fonctionnelle avec le langage Scala allez sur l’excellent site Coursera et sinon jetez un œil à OCaml.

Bien sûr comme tout langage, il faut un temps d’adaptation et ce n’est pas en 3 heures que je peux juger mais c’est mon ressenti.

Groovy langage dynamique et DSL

Concernant la conférence Groovy et les DSL statiquement typés, je ne peux malheureusement en retirer que très peu de choses car je pensais trouver une conf sur comment utiliser Groovy pour créer des DSL :(.

Factuellement, cette présentation très technique montrait quelles fonctionnalités de Groovy permettaient de typer statiquement son DSL créé avec Groovy.

Il fallait une très bonne connaissances de Groovy pour assister à cette présentation ainsi que des bases en création de langage (structure, arbre de syntaxe abstraite, éditeur, syntaxe concrète, sémantique et comportement, …).

Afin que vous aillez aussi d’autres pointeurs, je vous conseille de vous renseigner sur Xtext qui vous permet d’arriver au même but, c’est à dire créer un DSL, mais avec une autre approche. Il permet de créer des DSLs et des langages puis de générer un IDE Eclipse avec tout les plugins paramétrés pour ce DSL ou langage . Un exemple concret d’implémentation est le langage Xtend. Si vous êtes intéressés aller voir Xtext et  Xtend.

Il ne s’agit en aucun cas de comparer le langage Groovy et Xtext, mais au contraire de montrer qu’il existe des approches différentes pour atteindre le même but, en l’occurence créer un DSL, avec différentes technologies.

Dans les deux cas, il vous faudra décrire votre langage avec les apis de l’un des outils. De plus, ce ne sont pas les outils les plus importants mais votre connaissance de comment concevoir un DSL ou un langage adapté à votre contexte métier afin de vous faciliter les développements.

Mon planning pour les 3 jours au Devoxx France 2013 étaient assez variés avec quelques erreurs de casting sur certains choix de conférence.

Néanmoins, ce que j’ai pu en retirer se résume aux trois thèmes suivants :
- Programmation fonctionnelle, langage dynamique et DSL
- La qualité des développements :  tests automatisés et usines logicielles
- Les nouvelles applications à bâtir :  architecture WOA, NoSQL et Javascript

Vue d’ensemble en images

Voici quelques pointeurs en images que je garde pour cette session Devoxx France 2013.

Le Planning

Mon planning afin d’avoir quelques pointeurs vers des ressources qui ne sont pas toutes disponibles sur Parleys à l’heure où j’écris ces lignes.

Day1

Day2

Day3

Les thèmes

- Programmation fonctionnelle, langage dynamique et DSL
- La qualité des développements :  tests automatisés et usines logicielles
- Les nouvelles applications à bâtir :  architecture WOA, NoSQL et Javascript

Des attributs avec des valeurs multiples :
background-image
background-position

En effet, depuis CSS3, on peut spécifier des images de background multiples, pour peu que l’on se soit donné la peine de bien déclarer tous les paramètres.
Si nous voulons variabiliser tout ça, il faut donc un mélange d’éléments au sein d’un code less :
- Un ou plusieurs backgrounds
- Autant de paires de positions

Évidemment, il est possible de créer une fonction qui va réaliser cette opération, et cela deviendra nécessaire à partir d’un niveau supérieur de complexité – quand par exemple le nombre de backgrounds n’est pas connu !

Bref, avec la 1.3.2 (et toujours avec la 1.3.3) nous pouvons écrire ceci :
.bgs(@bg1;@bg2;@t;@t2){
background-image: url(@bg1),url(@bg2);
background-position: @t, @t2;
background-repeat: no-repeat;
background-color: rgba(0, 0, 0, 0.1);
}
h1 {display: inline-block;width: 350px;height: 350px;}
.not{
.bgs("oxbg01.png";"oxbg03.png";15%,80%;60%,75%);
}
.selected{
.bgs("oxbg05.png";"oxbg09.png";6%,22%;82%,63%);
}

Le code est rapide à lire et le plus léger possible.
Comme noté dans la doc, nous avons mélangé les point-virgules et les virgules, il n’est pas toujours très clair de faire la différence entre appel et déclaration dans cette doc officielle, mais on voit bien ici que l’utilisation de la virgule se fait dans l’appel (et dans ce cas, la virgule sert donc à séparer les éléments d’un attribut css).

On pourra même ajouter quelques cas supplémentaires en jouant sur les valeurs par défaut, puisque less va reconnaitre le nombre d’arguments du mixin.
Voilà, amusez vous avec LESS.

Le site a également été développé par nos soins, sous WordPress.
L’application mobile consomme les flux RSS très facilement mis à disposition sur wordpress, via les custom post types et les custom taxonomies.

Nous avons sorti deux versions :
Disponible sur Google Play

Disponible sur App Store

L’application Android utilise entre autres une sympathique librairie de chargement asynchrone d’images : Universal Image Loader.