Comment concevoir un thème personnalisé et léger sous Liferay ?

Cet article survient suite à la réalisation, par notre équipe Plateformes d’intégration et Intelligence Artificielle, d’un site informationnel pour l’un de nos clients, une grande entreprise canadienne de télécommunication et de médias, en utilisant Liferay 7 (la dernière version du portail Liferay).

Alexis, développeur front-end, vous partage son expérience sur ce projet afin de vous expliquer comment il est possible de créer un thème léger et rapide à charger avec Liferay.

En 2015, nous avons découvert le site de Bugaboo, réalisé sous Liferay 6.2. Une chose nous a surpris : l’absence des librairies front-end du thème Liferay.
Depuis l’idée a fait son chemin et un mandat similaire est arrivé à Savoir-faire Linux : Réaliser le site web informationnel d’une grande entreprise canadienne de télécommunications et média, avec Liferay.

Avant toute chose, nous devons nous accorder sur un point, la vitesse de chargement d’un site web est un élément déterminant de la rétention des utilisateurs : après 3 secondes [de chargement], jusqu’à 40% d’entre eux vont quitter le site » (Gomez Inc., 2010, en anglais). Pour plus d’informations, voir Lara Callender Hogan (en anglais).

Liferay n’est pas en soi une solution technique qui peut répondre à tous les besoins. Il est tout à fait possible de faire des sites web avec, mais malheureusement la méthode « recommandée », c’est-à-dire étendre le thème Liferay par défaut, aurait été un échec technique pour le site informationnel de notre client à cause d’un allongement considérable du temps de chargement. C’est alors que, basé sur nos expériences avec nos précédents projets, il a été choisi d’adapter en profondeur le thème Liferay afin de pouvoir répondre aux besoins précis de notre client. Dans ce qui va suivre, nous partageons avec vous notre retour et nos résultats.

Le portail Liferay, un outil puissant qui a besoin d’accompagnement

Liferay est un gestionnaire de contenu (CMS) et un portail écrit en Java fournissant de nombreuses fonctionnalités spécifiques aux développeurs comme une gestion avancée des utilisateurs, des droits d’accès, des documents, etc. Dans notre cas, en tant que société de services, nous avons la possibilité de l’adapter autant que nous le voulons aux besoins de nos clients. Par contre, étant pensé pour être un portail modulaire, il y a quelques défauts liés aux thèmes et aux performances à considérer avant de concevoir un site web avec. En voici la liste :

  • Le thème de base de Liferay charge par défaut toutes les librairies front-end ainsi que l’ensemble des styles que Liferay et ses portlets ont besoin. Cependant, une grande partie du code et des dépendances s’avère inutile pour un visiteur non-connecté (soit la majorité de nos utilisateurs dans le cadre de ce projet). De nombreux problèmes de performance apparaissent donc à cause de cette surcharge inutile de code.
  • Liferay impose la présence de son Design Language, Lexicon (ou plutôt, sa seule implémentation: Clay). Cela provoque également plusieurs problèmes :
    • Manque de correspondance entre le Design Language et les besoins visuels requis pour ce projet, limitant grandement les designs réalisables et ou en compliquant grandement la personnalisation,
    • Conflits au sein des règles CSS, augmentant le temps de développement,
    • Les mises à jour et corrections du thème de base de Liferay peuvent briser les styles développés provoquant alors une augmentation significative du temps de maintenance,
    • L’administration des contenus étant à même les pages, les styles développés peuvent briser le comportement des styles d’administration participant aussi à l’augmentation du temps de développement et de maintenance.

Comment alors réaliser un thème léger sous Liferay ?

La solution pour bénéficier de la puissance de Liferay tout en gardant le contrôle de la vitesse de chargement des pages est de créer un thème léger ne contenant aucune des librairies Liferay front-end comme senna.js, AlloyUi, Lexicon/Clay, etc.

Cependant, dans Liferay 7, ce n’est pas aussi facile que cela n’y paraît, notamment dû à l’impossibilité d’avoir une vue d’administration (indépendante) pour le site. Pour échapper à cela, nos fantastiques développeurs back-end de l’équipe ont développé un module, le « Theme Switcher », qui permet de forcer l’affichage d’un thème en fonction du rôle d’un utilisateur. Dans notre cas, cela nous permet d’afficher un thème classique Liferay uniquement aux administrateurs du site. Voici le lien vers le GitHub du « Theme Switcher » : savoirfairelinux/liferay-theme-switcher

5 étapes pour la mise en place d’un thème léger sous Liferay

Un exemple de thème léger pour Liferay disponible sur notre GitHub : savoirfairelinux/lightweight-liferay-theme. Ce thème utilise une architecture Maven, mais libre à vous de le modifier.

Étape 1 – Nettoyage du thème

Retirez les inclusions du fichier portal_normal.ftl, principalement: <@liferay_util["include"] page=top_head_include />. Mais aussi <@liferay_util["include"] page=body_top_include /> et j’en passe…

Étape 2 – Réparation du thème

Malheureusement la variable top_head_include ne contient pas que les librairies CSS et javascript de Liferay, mais aussi beaucoup d’autres choses. Il est donc nécessaire de ré-inclure les balises du head qui nous intéressent.

Par exemple,

  • Les meta-tags que l’utilisateur peut définir dans chaque pages (keywords, description, etc…):

<@liferay_theme["meta-tags"] />

  • La définition des urls canoniques:
<#if !is_signed_in && layout.isPublicLayout() > 
  <#assign completeURL = portalUtil.getCurrentCompleteURL(request) > 
  <#assign canonicalURL = portalUtil.getCanonicalURL(completeURL, themeDisplay, layout) > 

  <link href="${htmlUtil.escapeAttribute(canonicalURL)}" rel="canonical" /> 

  <#assign availableLocales = languageUtil.getAvailableLocales(themeDisplay.getSiteGroupId()) > 

  <#if availableLocales?size gt 1 > 
    <#list availableLocales as availableLocale> 
      <#if availableLocale == localeUtil.getDefault() > 
        <link href="${htmlUtil.escapeAttribute(canonicalURL) }" hreflang="x-default" rel="alternate" /> 
      </#if> 
      <link href="${htmlUtil.escapeAttribute(portalUtil.getAlternateURL(canonicalURL, themeDisplay, availableLocale, layout)) }" hreflang="${localeUtil.toW3cLanguageId(availableLocale)}" rel="alternate" /> 
  </#list> 
  </#if> 
</#if> 

Pour savoir quoi aller chercher, et comment, basez-vous sur la jsp qui est utilisée pour générer la variable top_head_include : https://github.com/liferay/liferay-portal/blob/7.0.x/portal-web/docroot/html/common/themes/top_head.jsp

Étape 3 – Organisation

Un des problèmes, et vous l’aurez peut-être deviné : les tâches liferay-theme-tasks fonctionneront difficilement.

Cependant, bonne nouvelle : Vous pouvez organiser votre futur thème de la manière dont vous le souhaiter et selon les standards de développement de votre équipe (sass, less, es6, etc.). Dans le cas de notre client, nous avons utilisé et agrémenté le gulpfile habituel pour nos projets web. Le tout chapeauté par Maven et des modules front-end.

Étape 4 – Automatisation du déploiement du thème léger

Cette partie a été la plus longue, je vous avoue, mais elle vous est maintenant disponible clé en main, dans la tâche gulp ‘deployLocal:syncTheme’ du thème d’exemple !

Il s’agit de la mise en place d’un déploiement « live » des fichiers du thème.

D’un point de vue global, le but est de ne pas avoir à compiler ni à attendre le déploiement du thème pour chaque modification de CSS ou de javascript (fonctionnalité normalement présente dans les liferay-theme-tasks). Dans le contexte OSGI de Liferay 7, il n’est pas facile d’accéder directement aux fichiers du thème (CSS, javascript, templates, etc.).

L’idée est alors de modifier la manière dont le thème est déployé dans OSGI, en le faisant pointer non pas vers le fichier .war du thème compilé (en mode webbundle, celui par défaut), mais plutôt vers le dossier extrait de ce .war (en mode webbundledir).

Étape 5 – Profitez

Vous avez maintenant un thème Liferay, qui contient uniquement ce que vous désirez pour votre projet, et qui est déployable comme n’importe quel autre thème Liferay.

Tests et résultats

Dans le but d’évaluer les avantages en terme de performances de la mise en place d’un thème léger, vous pouvez lancer un test, sur une même page avec le même contenu, avec 3 cas possibles de choix de thème. De notre côté, nous avons lancé ces tests sur un serveur Liferay configuré pour la production avec 8 CPU, 28Go de RAM et un disque SSD. Ci-dessous les 3 cas pour lesquels nous avons lancé le test.

Les 3 cas possibles de choix de thème

  1. Utilisation d’un thème vanille de Liferay, un thème classique
  2. Utilisation du thème léger que nous avons développé pour le site informationnel de notre client
  3. Utilisation du thème classique avec l’ajout des styles CSS et javascript du thème que nous avons développé pour notre client

Pour réaliser les mesures, nous avons utilisé une instance locale de speedtest.io (6.0.3) avec Chrome 62. Pour chacun des cas, 10 appels ont été réalisés. Ci-dessous un résumé des résultats :

Résultat du cas 1 : Le thème classique de Liferay

  • 52 requests
  • 1064.77 kb
  • DOMContentLoaded : 1.24s (±31.95ms)
  • Chargement : 2.06s (±52.89ms)
  • speedIndex : 1349 (±34.99)

Nous considérons ces résultats comme corrects car ils se trouvent dans la moyenne que l’on peut trouver actuellement sur le web. Néanmoins, il y a tout de même un grand nombre de requêtes, dépassant le seuil des 40, habituellement recommandé.

Résultat du cas 2 : Le thème léger

  • 37 requests
  • 800.38 kb
  • DOMContentLoaded : 588ms (±42.96ms)
  • Chargement : 1.17s (±55.17ms)
  • speedIndex : 863 (±39.57)

Moins de requêtes, une page plus légère, ce thème personnalisé est plus performant que le thème classique de Liferay !

Résultat du cas 3 : Le thème classique avec les CSS et javascript du thème léger de notre client

  • 56 requests
  • 1214.59 kb,
  • DOMContentLoaded: 2.22s (±457.34ms),
  • Load: 2.97s (±458.11ms)
  • speedIndex: 2475 (±456.71)

Ce résultat est très important, car il s’agit d’un cas qui pourrait être réel. Un thème Liferay, avec un visuel complètement personnalisé mais plus que deux fois plus lent à charger…

Conclusion

Dans l’ensemble, cette expérience fut instructive et nous a fourni, ainsi qu’à notre client, des résultats à la hauteur de nos espérances.

Néanmoins, la mise en place d’un thème léger ne peut pas s’appliquer pour n’importe quel type de site web et devenir une solution unique pour vos projets web. De plus, avec cette méthode, certaines fonctionnalités (front-end) de plusieurs Portlet Liferay se trouvent inaccessibles.

 

Revue de presse Inno #11

Développement Web

Bien démarrer avec le rendu côté serveur avec Angular

Par Kévin Barralon

Cette semaine, nous avons mis en ligne un tutoriel pour les développeurs qui utilisent le framework JavaScript Angular. Ce tutoriel a pour but de les aider à initialiser un projet Angular avec le rendu côté serveur pré-configuré. L’intérêt de la mise en place d’un rendu côté serveur permet de rendre le contenu d’une application lisible par les robots (Google, Facebook, Twitter) mais aussi d’améliorer les performances d’une application Angular, avec le transfert d’état entre le côté serveur et le côté client. Ces fonctionnalités étant une nouveauté du framework, la dernière version de Angular (v5) fut utilisée dans ce tutoriel.

Vous pouvez accéder à une version plus complète de ce tutoriel en lisant cet article : Comment créer une application Angular avec le rendu côté serveur ?

Emballer vos applis JavaScript avec Parcel

Par Jacob Cook

L’écosystème JavaScript est connu pour son évolution rapide et constante. Le développement d’une application moderne en JavaScript nécessite une panoplie d’outils et librairies, y compris des “bundlers”, qui gèrent la génération et emballement des “assets” nécessaires lors de la création d’une site Web. Jusqu’à présent, il y a eu deux grands projets de “bundlers” : Browserify et Webpack. Ils ne sont pas vraiment connus pour être faciles à apprendre ou à utiliser. On n’a qu’à aller chercher Google pour savoir “pourquoi est-ce que Webpack est si… lent ? …compliqué ?” et ainsi de suite.

Il est clair que l’écosystème a besoin d’un coup de pouce à ce sujet. Il y a un nouveau projet qui compte justement donner ce coup de pouce, et il s’appelle Parcel. Il fait pas mal les mêmes choses que Webpack à la base (code splitting, transpilation et transformation, hot module replacement) mais avec très peu de “bootstrapping” à faire, et pas beaucoup d’options ou de configurations à écrire pour assurer son bon fonctionnement. Il utilise aussi un système de compilation à multi-cœur, ce qui lui permet d’être bien mieux optimisé en terme de performance et d’utilisation CPU de votre ordinateur à travers plusieurs “workers”.

Reste à voir si Parcel sera couronné le “bundler” JavaScript par excellence, mais si les premiers retours d’utilisations se confirment, il apportera une bouffée d’air frais aux développeurs Web qui ne veulent que démarrer leur prochain projet moderne avec rapidité et efficacité. Et sans avoir besoin d’aspirine ! Pour en savoir plus sur Parcel : https://parceljs.org/

Pause Hivernale !

Merci de nous avoir suivi pendant ces 11 numéros. Toute l’équipe vous souhaite un joyeux temps des fêtes.

On se revoit en Janvier 2018 !
Votre équipe Inno Hebdo

Comment créer une application Angular avec le rendu côté serveur ?

Gestion du rendu côté serveur : Une nouveauté Angular imposant un défi

Angular est un framework utilisant le langage de programmation TypeScript. La version 5 a été mise en ligne en novembre 2017, avec de nouvelles fonctionnalités et corrections de bugs. Cette dernière version est accompagnée de l’outil en ligne de commande Angular CLI, mais aussi de nouveautés  attendues et réellement plébiscitées par la communauté, comme la gestion du rendu côté serveur.

Un des problèmes récurrents que l’on peut rencontrer lorsque l’on met en place un site web avec une librairie moderne (Angular, React, Vue.js, etc.) est que, de manière générale, les robots ne pourront pas lire votre site. Par conséquent, si vous souhaitez partager votre article sur Facebook, ou simplement être bien référencé sur les moteurs de recherche, la partie risque d’être compliquée (bien que dans le cas de Google, il semblerait que leurs robots soient capable de lire des pages générées par Javascript depuis récemment).

La raison est simple, la plupart des robots ne savent pas à quel moment votre page sera entièrement générée par Javascript. Par conséquent, ils ne seront en mesure de lire qu’une infime partie de votre HTML, à savoir, bien souvent, un petit ‘Loading…’ pas très explicite !

Comment peut-on alors créer une application Angular avec le rendu côté serveur ?

Angular CLI

Pour pallier à ce problème, Angular CLI (l’outil qui aide à la génération d’une application Angular) peut venir à la rescousse. Également, avec la version 5 d’Angular, il est désormais possible de gérer le transfert d’état serveur vers le client. Par exemple, une application qui fait une requête à une API Rest ne fera pas la même requête deux fois (une fois côté serveur, une autre fois côté client) mais transférera le résultat côté serveur au client. Nous allons étudier ces deux cas successivement afin de pouvoir bien démarrer une application avec le rendu côté serveur.

Comment initier le projet Angular?

Démarrons en installant l’outil Angular CLI :
npm i -g @angular/cli

On initialise ensuite notre projet :
ng new ssr-app style=scss # Parce que c'est mieux avec le SCSS

On va dans le répertoire de l’application générée et on lance le serveur de développement :

cd ssr-app
ng serve

Allez sur http://localhost:4200/ et enjoy ! Maintenant, nous devons configurer la gestion du rendu côté serveur.

Comment configurer le rendu côté serveur?

Commençons par installer le package platform-server : npm i -S @angular/platform-server

Dans le fichier .angular-cli.json à la racine du projet, il faut ajouter dans la partie « apps », la configuration suivante :

{
   "name": "universal",
   "platform": "server",
   "root": "src",
   "outDir": "dist-server",
   "main": "main.server.ts",
   "tsconfig": "tsconfig.server.json",
   "environmentSource": "environments/environment.ts",
   "environments": {
      "dev": "environments/environment.ts",
      "prod": "environments/environment.prod.ts"
   }
}

Dans notre dossier src/app, on a désormais besoin d’un fichier app.server.module.ts à côté de notre fichier app.module.ts. Ce sera notre point d’entrée pour notre application côté serveur. Son contenu :

import {NgModule} from '@angular/core';
import {ServerModule} from '@angular/platform-server';

import {AppModule} from './app.module';
import {AppComponent} from './app.component';

@NgModule({
   imports: [
      AppModule,
      ServerModule
   ],
   bootstrap: [AppComponent]
})
export class AppServerModule {
}

Le fichier hérite simplement des modules du fichier app.module.ts et ajoute le module ServerModule.

Quant au fichier main.server.js renseigné dans le .angular-cli.json, nous devons le créer à côté du fichier main.ts dans le répertoire src/ avec le contenu suivant :

import {enableProdMode} from '@angular/core';
export {AppServerModule} from './app/app.server.module';

enableProdMode();

Nous devons également créer un fichier tsconfig.app.server.json pour la compilation de TypeScript à côté du tsconfig.app.json dans le même répertoire :

{
   "extends": "./tsconfig.app.json",
   "compilerOptions": {
      "outDir": "../out-tsc/server",
      "module": "commonjs"
   },
   "exclude": [
      "test.ts",
      "**/*.spec.ts"
   ],
   "angularCompilerOptions": {
      "entryModule": "app/app.server.module#AppServerModule"
   }
}

Dans le répertoire src/app, il nous faut désormais modifier le fichier app.module.ts en ajoutant une méthode à notre module BrowserModule :

import {BrowserModule} from '@angular/platform-browser';
import {NgModule} from '@angular/core';
import {AppComponent} from './app.component';

@NgModule({
   declarations: [
      AppComponent
   ],
   imports: [
      BrowserModule.withServerTransition({ appId: 'universal' })
   ],
   providers: [],
   bootstrap: [AppComponent]
})
export class AppModule {
}

On peut désormais builder notre application côté serveur/côté client. Pour cela, rajoutons une ligne dans les scripts de notre package.json :

"scripts": {
   ...
   "universal": "ng build --prod &amp;&amp; ng build --prod --app universal --output-hashing=none",
   ...
}

A quoi sert cette commande ? Tout simplement à générer d’une part, une build côté client et, d’une autre part, une build côté serveur (avec la référence à notre app configurée dans le fichier .angular-cli.json). Pour le côté serveur on enlève la création d’un hash sur le fichier généré main.bundle.js pour pouvoir y faire référence plus tard.

Si on lance la commande npm run universal, on obtient bien nos deux builds dans deux fichiers respectifs dist/ et dist-server/.

Désormais, on souhaite pouvoir lancer notre serveur. Pour l’instant, le package Universal d’Angular ne supporte que Node.js et ASP.NET. Nous allons écrire notre serveur en Node.js.

Il faut tout d’abord installer le package @nguniversal/express-engine qui permettra de bootstraper notre serveur Node.js avec le framework Express. Il suffit donc de lancer la commande npm i -S @nguniversal/express-engine.

On va ensuite écrire un fichier server.js à la racine de notre projet avec ce contenu :

require('zone.js/dist/zone-node');

const express = require('express');
const ngUniversal = require('@nguniversal/express-engine');

/**
* On charge le seul fichier de notre build côté serveur
*/
const bootstrap = require('./dist-server/main.bundle');

/**
* On crée motre instance Express
*/
const app = express();

app.get('/', (req, res) =&gt; res.render('index', {req, res}));

/**
* Obtient les fichiers statics provenant de la build dist/
*/
app.use(express.static(`${__dirname}/dist`));

/**
* Configuration de Express Engine
*/
app.engine('html', ngUniversal.ngExpressEngine({
   bootstrap: bootstrap.AppServerModuleNgFactory
}));
app.set('view engine', 'html');
app.set('views', 'dist');

/**
* Toutes les URLs renvoient à l'index.html du répertoire dist/
* Angular se charge se rediriger vers les bonnes routes
*/
app.get('*', (req, res) =&gt; res.render('index', {req, res}));

/**
* On lance notre serveur
*/
app.listen(3000, () =&gt; console.log(`Listening on http://localhost:3000`));

Champagne ! Nous avons enfin configuré notre application Angular ainsi que notre serveur Node.js.

Lancez le serveur en tapant ‘node server.js’ et accédez à l’URL http://localhost:3000. Votre page est générée côté serveur au lancement, puis prise en charge par la build côté client une fois chargée. Si vous désactivez le Javascript de votre navigateur, miracle ! Votre page est tout de même générée grâce à notre configuration.

Comment transférer l’état de l’application ?

Bien que notre application fonctionne parfaitement avec cette configuration, celle-ci n’est pas complètement optimale.

Si votre application nécessite des requêtes via une API Rest par exemple, celles-ci seront effectuées deux fois au lieu d’une. En effet, si le serveur est sollicité pour effectuer une requête, le navigateur ne le sait pas et effectuera cette même requête une seconde fois lorsque le côté serveur prendra le relai.

Pour l’exemple, nous allons commencer par ajouter le HttpClientModule dans notre app.module.ts et notre app.server.module.ts (l’idéal serait d’avoir un fichier de modules en commun, mais je vous laisse la liberté de le faire !) :

import {HttpClientModule} from '@angular/common/http';

@NgModule({
   ...
   imports: [
      ...
      HttpClientModule
   ],
   ...
})
export class AppModule {
}

Allons dans notre app.component.ts et supprimons le contenu que nous allons remplacer par :

import {Component, OnInit} from '@angular/core';
import {HttpClient} from '@angular/common/http';

@Component({
   selector: 'app-root',
   templateUrl: './app.component.html'
})
export class AppComponent implements OnInit {
   image: any;

   constructor(private http: HttpClient) {
}

ngOnInit() {
   this.http.get('http://www.splashbase.co/api/v1/images/random')
      .subscribe(data =&gt; this.image = data);
    }
}

Nous nous chargeons d’afficher une image random récupérée via une API Rest.

Pour le rendu, éditons notre fichier app.component.html que nous remplacerons par cette unique balise :

< img *ngIf="image" [src]="image.url" >

Cette image sera donc le résultat de notre requête à l’API.

Si nous démarrons une build avec npm run universal et que nous lançons notre serveur avec ‘node server.js’, nous avons bien notre page qui fonctionne correctement. Petit bémol : l’image apparaît quelques millisecondes et est remplacée par une autre image.

La raison est le même que précédemment : une requête est faite côté serveur, et une autre est faite côté client une fois la page chargée. Le requête côté client est donc inutile.

L’idée est donc de transférer l’état de notre requête vers le côté client afin de ne pas multiplier les requêtes inutiles.

Pour cela, nous allons importer le ServerTransferStateModule dans notre app.server.module.ts et le BrowserTransferStateModule dans notre app.module.ts :

/* app.server.module.ts */
import {ServerTransferStateModule} from '@angular/platform-server';

@NgModule({
   imports: [
      ServerTransferStateModule /* Ici ! */
   ],
   bootstrap: [AppComponent],
})
export class AppServerModule {}

/* app.module.ts */
import {BrowserTransferStateModule} from '@angular/platform-browser'

@NgModule({
imports: [
   ...
   BrowserTransferStateModule /* Ici ! */
   ],
   bootstrap: [AppComponent],
})
export class AppServerModule {}

Une fois la configuration effectuée, on peut se rendre dans notre fichier app.component.ts. On crée ensuite une clef avant la déclaration de notre Class et on ajoute TransferState dans notre constructeur :

import {makeStateKey, TransferState} from '@angular/platform-browser';

const IMAGE_KEY = makeStateKey('image');

@Component({
   selector: 'app-root',
   templateUrl: './app.component.html'
})
export class AppComponent implements OnInit {
   ...
   constructor(private http: HttpClient,
      private state: TransferState) {
   }
...
}

Ensuite on modifie notre méthode ngOnInit de cette manière :

ngOnInit() {
   const image: any = this.state.get(IMAGE_KEY, null);

   /**
   * Si l'image n'est pac contenue dans notre clef, on effectue la requête
   */
   if (!image) {
      this.http.get('http://www.splashbase.co/api/v1/images/random')
         .subscribe(data =&gt; {
            this.image = data;
            this.state.set(IMAGE_KEY, data as any);
          });
   }

   /**
   * Sinon, on récupère le contenu de notre clef
   */
   else {
      this.image = image;
   }
}

On lance ensuite une build de notre application ainsi que notre serveur :

npm run universal
node server.js

Désormais, le contenu de l’image est transféré du serveur au client et la requête n’est effectuée qu’une fois !

Conclusion

Vous avez maintenant toutes les cartes en mains pour démarrer une application Angular avec le rendu côté serveur configuré.

Il suffit maintenant de faire attention à ne pas appeler des objets disponibles uniquement sur le navigateur (comme window par exemple) sans condition.

Par exemple pour vérifier que l’on est côté client ou non :

import { PLATFORM_ID, Inject } from '@angular/core';
import { isPlatformBrowser } from '@angular/common';

   constructor(
      @Inject(PLATFORM_ID) private platformId: Object,
      @Inject(APP_ID) private appId: string) {
      if (isPlatformBrowser(platformId)) {
         console.log('Je suis appelé côté client !')
      }
    }

Toutes ces astuces simplifieront vos développements Angular avec tous les avantages du rendu côté serveur !

Revue de presse Inno #10

Design

Qu’est ce que design system ?

Par Patrick Bracquart

Depuis plusieurs années, la complexité des sites et applications nous ont poussé à repenser le design et les méthodologies tant les champs de compétences nécessaires se sont élargis (analyste web, designer UI/UX, designer d’interaction, développeur front-end, …). C’est dans ce contexte qu’est apparu le design system.

Le design system est le référentiel UI/UX d’un projet. C’est un guide qui va servir de support pour toute la chaîne de production, peu importe le sujet (style de vie, alimentation, services…), le terminal (ordinateur portable, mobile, montre intelligente…), ou encore le livrable (site web, application mobile, interface de gestion…).

Design System

Plus complet qu’une ligne directrice, le design system ne fait pas qu’annoncer les éléments du design (atomic) et les interactions. Il renseigne aussi sur les normes de développement à suivre, l’accessibilité, l’iconographie, la vidéo, etc. afin que tout reste parfaitement cohérent.

Mobile

Comment utiliser les espaces de nommage versatiles en Swift ?

Par Thibault Wittemberg

Avec Swift, certaines API, telles que RxSwift, utilisent une technique qui confine le code qu’elles exposent dans un espace de nommage dédié. Cela facilite grandement la lecture du code et permet par ailleurs d’étendre cet espace de nommage pour lui ajouter vos propres fonctionnalités.

Espaces de nommage versatiles en Swift

Dans cet article (en anglais), nous verrons qu’il est assez simple de créer votre propre espace de nommage et d’une façon si générique, que cela permet à un contributeur externe de l’étendre de façon élégante.

Revue de presse Inno #9

Spécial PyCon Canada 2017 (Suite !)

Que retenir de la dernière PyCon Canada ? Quelques éléments de réponse avec les développeurs de l’équipe Innovation de Savoir-faire Linux !

Conférence ‘Double Click: Continue Building Better CLIs’

Par Kévin Barralon

Cette conférence donnée lors de la PyCon Canada visait à présenter Click, un package Python permettant de créer des CLIs (Commande Line Interface) en peu de lignes de code.

L’utilisation est simple et intuitive : la configuration d’une commande passe essentiellement par l’ajout de décorateurs à votre fonction.

Par exemple, voici une fonction simple chargée de répéter un nom passé en argument :

# hello.py
import click

@click.command()
@click.option('--count', default=1, type=int, help='Number of greetings.')
@click.option('--name', prompt='Your name',
              help='The person to greet.')
def hello(count, name):
    for _ in range(count):
        click.echo(f'Hello {name}!') # Syntaxe de Python 3.6 !

if __name__ == '__main__':
    hello()

En quelques lignes de codes, vous avez créé une commande qui :

  • prend une option --count avec une valeur par défaut de 1 et dont le type exigé est un integer.
  • prend une option --name qui permet grâce à l’argument prompt passé dans votre décorateur de proposer à l’utilisateur de renseigner son nom.

Ces valeurs sont transmises directement aux paramètres count et name de la fonction décorée. Ci-dessous le code pour lancer la commande dans votre terminal :

python3 test.py --count=3

Your name: Casimir
Hello Casimir!
Hello Casimir!
Hello Casimir!

L’autre point intéressant (et pratique également !) est que si vous passez l’option --help à l’appel de votre fichier, vous obtenez l’affichage de la Docstring de votre fonction, ainsi que les informations pour chaque option fournies grâce à l’argument help passé dans vos décorateurs :

python3 hello.py --help

Usage: test.py [OPTIONS]

Simple program that greets NAME for a total of COUNT times.

Options:
--count INTEGER Number of greetings.
--name TEXT The person to greet.
--help Show this message and exit.

Plutôt que de passer des options à votre commande, vous pouvez également définir des arguments. Pour l’exemple :

@click.command()
@click.argument('filename')
def touch(filename):
    click.echo(filename)

Puis :

python3 touch.py foo.txt
foo.txt # Résultat

Comme vous pouvez le constater, les possibilités de Click sont vraiment nombreuses. Quelques unes en supplément pour l’occasion :

  • possibilité d’ajouter l’argument multiple=True dans votre décorateur @click.option qui vous renverra un tuple des options passées à l’appel de votre commande.
  • ajouter un callback en argument du @click.option qui changera le comportement de votre commande (par exemple pour définir des règles de validations sur-mesures).
  • de passer des variables d’environnement à votre décorateur (ex: envar="USERNAME").
  • définir un nombre limité ou illimité d’arguments qui retourneront un tuple.
  • ajouter une méthode File en guise de type dans votre décorateur (par exemple : @click.argument('input', type=click.File('rb'))) qui se chargera également d’ouvrir votre fichier et de le fermer automatiquement.

La liste de toutes les possibilités offertes par le package est disponible dans la documentation, très bien faite par ailleurs.

Bonus !

La conférence sur f-strings a vraiment motivé les troupes ! Voici un article de Maxime qui fait écho à celui de Sébastien la semaine dernière :

Les f-strings, qu’est-ce que ça mange en hiver?

Par Maxime Dupuis

Les chaînes de caractères-f, ou f-strings, sont une nouvelle façon de faire de l’interpolation en Python. Elles se définissent en mettant un f (ou F) en amont de la déclaration d’une chaîne de caractères : f'Ma chaîne f'.

Elles sont très semblable en comportement aux chaînes patrons (template strings) en JavaScript qui, elles, sont définies en utilisant le caractère `.

L’utilité des f-strings vient du fait qu’elles peuvent contenir des variables qui seront automatiquement interpolées avec les valeurs des variables locales définies du même nom :

>>> age = 42
>>> prenom = 'Maxime'
>>> f"Je m'appelle {prenom} et j'ai {age} ans"
"Je m'appelle Maxime et j'ai 42 ans"
>>> # L'utilisation d'une variable non-définie nous donnera une erreur de type NameError :
>>> f"{nondefini}"
Traceback (most recent call last):
File "", line 1, in
NameError: name 'nondefini' is not defined

Là où l’utilisation de chaînes de caractères-f devient intéressante est notamment du fait que ce type de chaînes est très rapide ! Si on les compare aux autres façons de créer des chaînes en Python, on a :

python3.6 -m timeit -c 'age=42; prenom="Maxime"; f"Mon nom est {prenom} et mon age est {age} ans"'
10000000 loops, best of 3: 0.172 usec per loop
python3.6 -m timeit -c 'age=42; prenom="Maxime"; "Mon nom est {prenom} et mon age est {age} ans".format(prenom=prenom, age=age)'
1000000 loops, best of 3: 0.714 usec per loop
python3.6 -m timeit -c 'age=42; prenom="Maxime"; "Mon nom est %s et mon age est %s ans" % (prenom, age)'
1000000 loops, best of 3: 0.283 usec per loop
python3.6 -m timeit -c 'age=42; prenom="Maxime"; "Mon nom est " + prenom + " et mon age est " + str(age) + " ans"'
1000000 loops, best of 3: 0.449 usec per loop
python3.6 -m timeit -c 'from string import Template; age=42; prenom="Maxime"; Template("Mon nom est $prenom et mon age est $age").substitute(prenom=prenom, age=age)'
100000 loops, best of 3: 8.75 usec per loop

Mais l’utilité des f-strings ne réside pas uniquement dans sa rapidité : Il est également possible d’appeler des fonctions, faire du traitement, et toutes autres choses :

>>> total = 10.0
>>> taxes = 1.15
>>> f'Total: {total + taxes}'
'Total: 11.15'
>>> prenom = 'Maxime'
>>> f'Mon nom est {prenom.upper()}'
'Mon nom est MAXIME'

Si cela vous intéresse et que vous n’avez pas encore découvert toutes les nouveautés que Python 3.6 peut vous offrir, consultez les notes de version : «What’s New In Python 3.6».

Mobilité

SwiftGen

Par Thibault Wittemberg

Lorsque nous développons une application iOS, nous avons régulièrement besoin d’accéder à des ressources. La façon traditionnelle pour les utiliser dans le code est de les instancier avec leurs identifiants (chaînes de caractères) :

let avatar = UIImage(named: ‘darthVader’) // gets the ‘darthVader’ image from the assets folder
let name = NSLocalizedString (‘darthVader’, comment: ‘’) // gets the localized string with the key ‘darthVader’ from the Localizable.strings file

Il en va de même pour les fonts, les storyboards et les couleurs.

Pour rappel, Swift se veut un langage assez strict sur la gestion des types et favorise la détection d’erreurs lors de la phase de compilation plutôt que lors de la phase d’exécution. Ceci étant, que se passe-t-il si l’une des ressources que l’on souhaite instancier n’est pas trouvée à l’exécution ? Puisque cette instantiation se base sur une chaine de caractères, elle est soumise à des erreurs (fautes de frappe par exemple).

La solution ? L’outil Swiftgen, qui nous permet de sécuriser cette manipulation :

  • Il évite les erreurs de frappes,
  • Il permet la complétion syntaxique,
  • Il assure que la ressource existe au moment de la compilation.

Son principe de fonctionnement est le suivant :

  • L’exécutable « Swiftgen » est installé sur le poste de développement (soit via Homebrew soit via CocoaPods),
  • Une phase de build custom lance cet exécutable lors de chaque compilation,
  • Swiftgen parcours les ressources du projet et génère le code Swift les représentant de façon « type safe ».

Les identifiants des ressources seront ainsi transformés en « enum » dont l’utilisation est bien plus sécurisée et facile. Notre exemple deviendrait :

let avatar = Asset.darthVader.image
let name = L10n.darthVader

Il est même possible de customiser les templates qui serviront à la génération du code si l’on souhaite appliquer un coding style différent de celui offert par défaut.

Lorsqu’il est combiné au framework « Reusable » (du même auteur), nous disposons d’outils quasiment indispensables (et que nous mettons en place systématiquement chez Savoir-faire Linux) et dont on souhaiterait disposer par défaut dans l’environnement de développement d’Apple.

Swiftgen est pensé pour être intégré à l’environnement d’intégration continue d’un projet (l’exécutable peut être embarqué dans une dépendance CocoaPods, évitant ainsi de l’installer sur la machine de build).

Contribution

Nouvelle version de savoirfairelinux/num2words 0.5.6

Par Ernesto Ortiz

Cinq mois depuis la version précédente de num2words v0.5.5, cinq mois vraiment actifs.

Beaucoup de nouveaux contributeurs ont apporté de grandes améliorations et ont ajouté un support pour de nouvelles langues !
Voici quelques-uns des nouveaux changements avec des « remerciements spéciaux » aux contributeurs !

  • Num2words a changé les conventions de codage pour suivre PEP8,
    La couverture du code a beaucoup augmenté et nous avons besoin de votre aide pour continuer à améliorer cela, alors regardez les problèmes,
  • Maintenant, nous pouvons utiliser d’autres convertisseurs to_currency, to_year, to_ordinal_num,
  • Merci à Tufan Kaynak d’avoir apporté son soutien à la localisation turque,
  • Merci à Jesús Leganés-Combarro d’avoir soutenu la localisation franco-algérienne,
  • Merci à Armin Oliya pour son soutien à la localisation néerlandaise,
  • Merci à Sergio Zholudov pour son soutien à la localisation ukrainienne,
  • Remerciements à Blaž Bregar pour son soutien à la localisation slovène,
  • Merci à Mārtiņš Šulcs d’avoir apporté de nombreuses améliorations au code de base, aux fonctionnalités de to_currency et plus encore !

Un merci spécial à tous ceux qui ont pris le temps de signaler de nouveaux problèmes, de faire une pull request et de partager leur temps dans ce projet !

Vous pouvez vérifier la nouvelle version dans :