English version available

Il n’y a pas si longtemps, je vous parlais du « Mobile theme » inclus dans l’extension Jetpack pour que votre blog WordPress soit accessible de manière lisible et adaptée sur les appareils mobiles.

Je ne reviens pas sur mes dires à propos de ce thème mobile, car il fonctionne très bien et chaque nouvelle version du plugin Jetpack apporte son lot d’améliorations. Surtout, il a un avantage certain: une configuration quasi proche du néant, il suffit d’un clic pour activer le thème, on peut difficilement faire mieux. Oui, mais… si un peu de développement ne vous fait pas peur, il y a encore mieux!

Je parle du Responsive Web Design (conception de sites web adaptatifs), en plus c’est très tendance en ce moment, et ce n’est pas qu’une mode passagère. Grâce au Responsive Web Design, le site reste le même pour toutes les plateformes et s’adapte automatiquement à la taille de l’écran. L’identité de votre site reste la même (thème, images, couleurs…) et cela vous évite de faire de la gestion de multi-versions: une version desktop, mobile, tablette… La gestion du site est donc simplifiée et la maintenance facilitée.

Avant, les tailles d’écran étaient peu nombreuses (une bonne vieille résolution 1024 x 768 ou, pour les plus chanceux, une résolution 1280 x 1024), c’était le temps des écrans 17 et 19 pouces à tube cathodique (aïe, mes yeux, ça pique… Bon ok je ça commence à dater). Aujourd’hui, il y a des centaines de tailles différentes, Internet est partout que ce soit sur la télévision, dans votre voiture ou même dans votre frigo (bon là je vois un peu trop loin, mais le tout-connecté n’est peut-être pas si loin). Bref, il n’est plus envisageable de travailler sur des résolutions fixes au cas par cas.

Bien sûr dans le cas d’une application spécifique, il y a des arguments contre le Responsive Design. Une application web aura des performances plus lentes comparée à une application native, mais ce n’est pas l’objet de cet article. Cet article met le focus sur les sites web, disons grand public (site d’un journal, site marchand…), qui veulent se rendre accessibles sur mobile et veulent éviter des versions mobiles dédiées (les fameuses URL commençant par « m »). Par exemple m.facebook.com, m.linkedin.com ou encore m.lequipe.fr qui vont disparaitre tôt ou tard.

Testez vous-même

Vous pouvez dès maintenant modifier la taille de la fenêtre de votre navigateur, vous verrez que ce blog s’adaptera automatiquement en conséquence (si vous voyez des bogues ou des idées d’amélioration, je suis preneur!).

CarmaBlog en 1024 x 768

CarmaBlog en 400 x 768

Vous l’aurez sans doute remarqué, voici les impacts lorsque la taille de la fenêtre diminue:

• Le menu principal devient plus petit avant de se transformer en une liste déroulante.
• Des blocs passent à la ligne (icône RSS et boîte de recherche).
• Le contenu secondaire disparait au profit du principal. Sur un petit écran, on veut aller à l’essentiel (ici les articles) et éviter au maximum les scrolls.
• L’effet d’ombre et d’arrière-plan disparait. Sur les petits écrans, quelques dizaines de pixels de gagné peuvent représenter 10% de la résolution totale, ce n’est pas négligeable.
• Les images se redimensionnent pour éviter des disproportions trop fortes.

Des frameworks Responsive, en veux-tu en voilà…

De nombreux frameworks existent pour vous aider à réaliser un site responsive. Le plus connu est sans doute Bootstrap, d’ailleurs c’est le seul que j’ai pu utiliser sur un projet. Il y en a plein d’autres:

• Foundation
• Gumby
• Unsemantic
• Skeleton
• Pure
• KnaCSS

Du Responsive fait-maison!

Il est aussi possible de faire du Responsive Web Design soi-même, sans framework. C’est ce que j’ai fait pour mon blog. Un peu de CSS, un peu de Javascript et quelques heures de boulot suffiront. Ce ne sera peut-être pas compatible avec IE6, ça n’affichera sûrement pas de superbes animations bling-bling, mais cela suffira dans la majorité des cas.

Le secret, c’est l’utilisation des media queries disponibles depuis CSS3, voici des exemples de code:

@media all and (max-width:1000px) {
	.sidebar div {
		display:none;
	}
}

Quand l’écran fait moins de 1000 pixels en largeur, on masque les sidebars à gauche et à droite.

@media all and (min-width:870px) and (max-width:975px) {
	#menu ul li {
		font-size:.7em;
	}
	#header_image {
		height:150px;
	}
}

Quand l’écran fait entre 870 pixels et 975 pixels, on rétrécit le menu (la taille de la police) et le header.

@media all and (max-width:870px) {
	#menu {
		display:none;
	}
	#menuselect select {
		display:block;
	}
	#header_image {
		height:80px;
	}
}

Quand l’écran fait moins de 870 pixels, on cache le menu et le remplace par la liste déroulante et on rétrécit encore l’image du header.

@media all and (max-width:585px) {
	img:not(.fixed):not(.avatar):not(.wp-smiley):not(#sb-player) {
		height:auto !important;
		max-width:80%;
		min-width:70px;
	}
}

Toutes les images dépendent de la taille de l’écran quand celui-ci fait moins de 585 pixels. Les images avec les classes CSS « fixed », « avatar », « wp-smiley » ou ayant l’ID « sb-player » ne sont pas concernées. J’ai eu le problème d’avoir des images grossies avec certaines icônes comme les smileys ou le lecteur d’images Shadowbox.js… Aussi, une image ne peut faire moins de 70 pixels de hauteur (en dessous, je pense qu’il faudrait une très bonne vue).

A noter: j’utilise le mot clé « !important » pour redéfinir un style déjà présent. La valeur spécifiée avec le « !important » écrasera toujours les autres.

J’ai aussi écrit un peu de Javascript pour la création de la liste déroulante qui remplace le menu. Je ne mets pas le code ici (c’est très spécifique à mon site), mais sachez que la fonction ne fait pas plus de 15 lignes. J’ai profité du fait que la librairie jQuery était déjà incluse dans le projet pour utiliser quelques-unes de ses fonctions, histoire d’économiser quelques lignes de code.

En tout, il m’aura fallu environ 200 lignes de code CSS (avec le formatage ci-dessus donc beaucoup de lignes contenant une seule accolade fermante) pour rendre mon site responsive. Ce n’est pas aussi compliqué qu’on aurait pu le penser.

Enfin, il y a une dernière chose importante. Dans le header de vos pages, ajoutez cette balise meta pour indiquer que votre site est adapté pour les mobiles.

<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Vérification

Finalement, le plus long et fastidieux aura été l’affinage des styles en fonction de la résolution. Pas de secret, c’est un processus manuel itératif: on modifie le CSS, on rafraîchit la page et on inspecte.

A ce propos, le site Responsinator teste un site sous les résolutions d’écran les plus fréquentes correspondant à des appareils grand public. Vous pouvez aussi installer Firesizer, une extension Firefox pour connaitre la résolution de la fenêtre du navigateur, très utile lors de la construction des media queries.

 English version available

Raphaël Delaporte (@rafdelaporte) nous a proposé de dompter un chameau cette semaine au JUG Nantes.

Et ne vous fiez pas à cette photo ! Notre chameau d’informaticien n’est pas un paresseux, bien au contraire ! Retour sur une présentation forte intéressante d’Apache Camel.

Apache Camel s’appuie et reprend les Entreprise Integration Patterns – EIP (à ne pas confondre avec les Design Patterns qui sont utilisés pour la conception objet).

Les patterns EIP

Voici les principaux patterns du plus simple au plus complexe (extrait de la présentation).

Entreprise Integration Patterns

En les combinant, les possibilités sont quasi-infinies. Vous trouverez la liste des Patterns implémentés dans Camel sur le site officiel du framework.

Un livre complet sur le sujet existe « Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions ». L’auteur n’est autre que le créateur de ce concept, autant dire que c’est la référence dans ce domaine.

Faire des EIP avec Apache Camel

Pour mettre en oeuvre les EIP, on trouve trois éléments de base dans Camel :

• Route
• Processor
• Endpoint (dans la littérature française, le terme est parfois traduit par « point d’extrémité »)

Une route est conceptualisée de la manière suivante : la liaison de deux endpoints par un processor. Ainsi, nous avons un endpoint de départ et un endpoint de fin, un endpoint est associé à une ressource. Une route symbolise un traitement plus ou moins complexe en fonction du traitement voulu (processor) et de l’EIP choisi.

Pour répondre au besoin, on peut imbriquer les routes, les chainer, appliquer des traitements différents tout au long de la route, etc.


Dans Apache Camel, la définition de routes peut se faire de deux manières :

• Soit en utilisant le langage Java (domain specific language – DSL). Apache Camel fournit une API. Très pratique pour l’autocomplétion dans l’IDE.
• Soit en utilisant le langage XML. Plus verbeux donc un peu moins lisible et finalement un peu moins pratique. Avec Camel, on préconise l’utilisation du DSL lorsque les routes sont complexes.

Dans la suite, nous privilégierons donc l’écriture en code Java. Dans tous les cas, un minimum de code XML est nécessaire pour la configuration de Camel (le contexte Camel, les sources de données, etc.).

Voici un exemple de route :

import org.apache.camel.builder.RouteBuilder;

public class MyFirstRoute extends RouteBuilder {
    @Override
    public void configure() thwrows Exception {
        // Ma première route
        from('file:/Users/fabian/src').to('file:/Users/fabian/dest').end();

        // D'autres routes peuvent être définies
        // ...
    }
}

Le mot clé .end() n’est pas obligatoire, mais il est conseillé pour bien délimiter les routes et permettre de s’y retrouver (maintenabilité). Dans cet exemple, le traitement est très simple et il n’y a qu’une seule route, il n’est pas vraiment indispensable.

La présentation était ponctuée de nombreuses démos. A partir d’un projet Maven bien configuré (dépendances Spring, Camel, contextes…), Raphaël nous a montré quelques cas d’utilisation écoles :

• Déplacer les fichiers d’un répertoire à un autre (il s’agit du bout de code ci-dessus). Tous les fichiers créés dans le répertoire src seront déplacés dans le répertoire dest. Cette route s’écrit en une ligne, témoignant de la puissance d’un tel outil.
• Créer des fichiers correspondants à chaque message poolé dans une queue JMS. Pour la présentation, Raphaël a utilisé Apache ActiveMQ, un message broker JMS. Ce cas illustre le pattern Splitter.
• Transférer des messages JMS vers une queue en fonction de leurs contenus. Ce cas illustre le pattern Content-based Router.

La route est la suivante, en supposant que queue.in existe dans ActiveMQ et qu’on y poole des messages :

import org.apache.camel.builder.RouteBuilder;

public class MyContentBasedRoute extends RouteBuilder {
    @Override
    public void configure() thwrows Exception {
        from('amq:queue.in')
            .choice()
                .when(header('JMSCorrelationID').isEqualTo('nantes'))
                    .to('amq:queue.nantes')
                .when(header('JMSCorrelationID').isEqualTo('rennes'))
                    .to('amq:queue.rennes')
                .otherwise()
                    .to('amq:queue.others')
        .end();
    }
}

Depuis la console d’admin d’ActiveMQ, on crée quelques messages de test avec les différents cas possibles. En fonction de son header, le message est routé vers la bonne queue.

Il est possible de chainer des prédicats avec les opérateurs logiques habituels afin de créer des critères de routage plus complexe. Ici, le prédicat est simple et se base seulement sur le header du message. On aurait pu également se baser sur le body pour faire un routage plus fin des messages.

• Créer des messages JMS à partir du contenu d’un fichier XML. Ce cas illustre le pattern Dynamic Router.

Voici le contenu du fichier messages_jug.xml :

<jug>
    <nantes>Hello from Nantes</nantes>
    <paris>Hello from Paris</paris>
    <rennes>Hello from Rennes</nantes>
    <nantes>Hello again from Nantes</nantes>
    <paris>Hello again from Paris</paris>
    [...]
</jug>

Avec Camel, on veut extraire les différents messages pour les envoyer dans une queue.

Voici le code de la route correspondante :

import org.apache.camel.builder.RouteBuilder;

public class MyDynamicRoute extends RouteBuilder {
    @Override
    public void configure() thwrows Exception {
        from('files:/Users/fabian/src/messages_jug.xml')
            .split(xpath('/jug/child::*'))
        .to('amq:queue.jugs');
    }
}

On aurait pu router vers un autre fichier en filtrant sur les messages de Nantes. Les possibilités sont multiples.




Optimisations Camel

On peut se poser le problème de l’indisponibilité… Que se passe-t’il dans le cas du traitement d’un message si la machine crashe et n’a pas le temps de router le message ? Malheureusement, vous perdez le message ! Celui-ci a été consommé dans la queue de départ, mais n’a jamais pu atteindre sa destination. La solution est de passer la route en mode transactionnel. Cela se fait en ajoutant .transacted() juste après le .from(...) et en prenant soin d’indiquer à votre source JMS de se mettre en mode transactionnel (configuration XML).

On peut aussi noter que, par défaut, le traitement est monothread. Une amélioration est d’activer la parallélisation sur le processor (ici split) en ajoutant l’option .parallelProcessing() juste après le .split(...).

Nous avons parlé de file et de jms, mais les composants disponibles dans Camel sont légion grâce à une communauté très active. Cette page recense l’ensemble des composants disponibles. Citons jdbc, ftp, gmail, atom, pop, imap entres autres.




Faire des EIP avec Spring Integration

Raphaël nous a parlé de Spring Integration, une alternative à Camel. Spring Integration ne laisse pas le choix à l’utilisateur et s’utilise avec la notation XML exclusivement.

D’après Raphaël, il s’intègre mieux avec Spring Batch, mais l’objectif n’était pas de juger les deux outils. Chacun a ses avantages et ses inconvénients.

Voici l’exemple du transfert des fichiers d’un répertoire à un autre, cette fois écrit avec Spring Integration :

<channel id='myFirstChannel' />

<file:inbound-channel-adapter id='filesIn'
        channel='myFirstChannel'
        directory='file:/Users/fabian/src' />

<file:outbound-channel-adapter id='filesOut'
        channel='myFirstChannel'
        directory='files:/Users/fabian/dest' />

La notion de route n’est pas présente, on parle de channel. Une channel relie deux composants. On se rapproche clairement de la philosophie de Spring qui place la notion de composant au centre. Des composants que l’on injecte et que l’on relie entre eux (et c’est logique puisqu’il s’agit du même éditeur SpringSource).

En fait, le terme route n’est utilisé que par Camel. Spring Integration est plus fidèle aux concepts des EIP en utilisant des termes similaires comme channel.

Autre différence, la channel apparait concrètement dans Spring Integration alors que la route dans Camel est implicite (pas de mot-clé route()). Si on reprend notre première route :

from('file:/Users/fabian/src').to('file:/Users/fabian/dest');

La route est symbolisée par le « . » entre les deux endpoints. Il n’est pas possible de la configuer. A ce niveau, Spring Integration est un peu plus poussé avec la possibilité de configurer le type de channel notamment.