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 :

Revue de presse Inno #7

Mobile

Protocoles génériques et Type Erasure en Swift

Avec Swift, vous pouvez définir des protocoles en leur associant un ou plusieurs types génériques. Ces types sont définis en utilisant le mot-clé « associatedtype ».  L’appellation « type générique » est un peu usurpée ici, nous devrions plutôt parler d’un espace réservé pour un type inconnu. En effet, nous verrons que de tels protocoles n’offrent pas une grande souplesse d’utilisation lorsqu’il s’agit de réellement les considérer comme génériques.
En savoir plus :

Développement Web

Django 2.0 Release Candidate désormais disponible

Par Kévin Barralon

Le framework Django dont la prochaine version 2.0 est prévue autour du 1er décembre vient de publier sa version Candidate ce jeudi 15 novembre. Contrairement à ce que l’on pourrait penser, cette nouvelle version ne va pas apporter d’incompatibilités majeures au sein du framework. Les changements seront donc du même acabit que les versions précédentes.

Cependant, le changement important de cette version 2 sera l’incompatibilité avec Python 2.7, dont la fin du support est programmée pour 2020. Django 2.0 supportera donc au minimum la version 3.4, même s’il est chaudement recommandé de passer directement à la dernière version de Python (3.6 actuellement).

Routage d’URL

Au niveau des nouveautés, la nouvelle fonction django.urls.path() rend la syntaxe du routage des URL beaucoup plus simple et lisible. Ainsi, au lieu d’écrire : url(r'^articles/(?P[0-9]{4})/$', views.year_archive)

vous pourrez écrire : path('articles/<int:year>/', views.year_archive)

Cette nouvelle syntaxe permettra également de recevoir dans la vue (views) les arguments avec le typage défini (un nombre entier dans le cas de year au lieu d’une string).

Dans cet exemple, il n’y a toutefois pas de possibilité d’ajouter une contrainte (une année à 4 chiffres dans notre exemple). Pour cela, la fonction actuelle django.conf.urls.url() sera remplacée par django.urls.re_path(), qui permettra de conserver la possibilité de mettre des expressions régulières dans la définition de l’URL.

La fonction django.conf.urls.include() sera également directement disponible via django.urls. Pour pourrez ainsi importer vos modules de la manière suivante from django.urls import include, path.

Autres nouveautés

  • Pour les autres nouveautés : L’admin de Django 2.0 sera désormais responsive, donc adapté aux appareils mobiles.
  • Une nouvelle classe Window a été ajoutée afin de permettre l’utilisation du mot-clé OVER dans les requêtes SQL.
  • Une liste de tous les ajouts mineurs est disponible dans le communiqué officiel.
En savoir plus :

Déployer des services entiers avec Docker Swarm et Gitlab CI

Chez Savoir-faire Linux, je travaille (entre autres) sur l’infrastructure de déploiement pour plusieurs services que l’on héberge, et je suis toujours à l’affût de méthodes innovantes pour améliorer notre pratique DevOps. Présentement, le système de déploiement est axé autour de l’utilisation de Ansible pour « provisioner » un service dans une machine virtuelle, et l’ajuster au besoin après. Mais pour améliorer la stabilité de nos builds, de déploiements et l’agilité avec laquelle on peut faire des déploiements en continu, nous regardons d’autres approches DevOps, comme l’utilisation des containeurs Docker hébergés dans un Registry et déployés par un outil comme Gitlab CI.
Parmi les outils disponibles pour déployer une architecture de « microservice » (créée avec docker-compose), nous trouvons Docker Swarm. En utilisant un certain nombre de serveurs proprement configuré, on peut déployer un « stack » de containeurs avec un simple docker stack deploy. Docker va choisir par la suite la meilleure configuration pour le déploiement des différents containeurs à travers l’infrastructure du Swarm. Il va même aller jusqu’à configurer la réseautique entre les containeurs automatiquement, comme si tu utilisais docker-compose sur un ordinateur en local.
 
La meilleure partie, c’est le fait que ça marche bien avec notre système d’automatisation des builds déjà existant, GitLab CI. Nous pouvons faire le pipeline « build – test – release – deploy » à travers toute notre infrastructure avec GitLab CI et le GitLab Container Registry. Il y a toujours des parties casse-têtes à régler, mais ce système représente déjà un grand bond vers l’avant pour la simplicité et l’efficacité de notre pratique DevOps.
En savoir plus :