Créer des applications métier, ça fatigue, surtout quand on doit passer des heures à régler des problèmes de validation de formulaires ou de mauvais typages...

Mais tout ça c'est du passé ! Nous avons crée le framework CASE spécialement pour développer des applications dites "data-intensive", c'est à dire ou le CRUD (Create Read Update Delete) et la gestion des resources est primoridale.

‌Comment ça fonctionne ?

CASE est framework full stack basé sur 2 autres frameworks: Angular (Framework TS client) et NestJS (framework TS seveur basé sous NodeJS). Une CLI vient compléter ce monorepo pour pouvoir créer des resources en une commande.

Une commande ?

Oui, en une commande on génère tout ce qui concerne une ressource, de la base de données, au colonnes et au type d'input dans sa page "create-ed‌it". Par example la commande ci-dessous va générer le concept de produit mais aussi toutes ses propriétés.

cs generate resource product --props=name,price:currency,photo:image

Pour essayer CASE, suivez notre quickstart guide et donnez-nous votre avis ! On cherche des BETA testeurs, faites nous signe sur Discord si cela vous intéresse.

‌

En 2014, Google sort le Material Design, prémisse du design system.

En 2016, je participais à une conférence de Brad Frost dans laquelle il introduisait son Atomic Design.  A ce moment là, j’étais convaincu qu’à l’avenir, toutes les marques et entreprises auraient un design system, même basique. Et pourtant, nous voilà 3 ans plus tard, et il m’arrive encore de discuter avec des équipes projet qui ne voient pas l’intérêt de cet outil et ni en quoi il diffère d’une charte graphique, d’un styleguide ou d’une librairie de composants.  

J’ai eu envie d'écrire cet article car j’aimerai mettre en avant l'importance de l'implémentation du design system au sein d'une entreprise.

C'est quoi un design system ?

Un design system est un ensemble de composants réutilisables, guidés par des normes claires, qui peuvent être assemblés pour créer plusieurs applications.

• Les normes : Elles définissent la structure des fichiers, les conventions de nommage, l’utilisation des composants ou encore les interactions. Elles peuvent s'appliquer à tous les métiers.
• Les composants : Les composants sont des parties réutilisables dans votre système et servent de blocs de construction à l'interface de votre application. Un composant peut être inclu dans un autre composant.

Voici quelques design systems que j'apprécie :

• Uber
• Polaris de Shopify
• Atlassian
• Carbon Desing System de IBM
• Audi
• U.S Web Design System : Ce n'est pas le plus complet, mais je trouve intéressant de voir qu'un gouvernement ait mis en place un design system pour améliorer l'UX de son public.

Design System de SAP

Dans son Design System, Uber donne des principes à respecter pour les casting photo. Les sujets ne doivent pas ressembler à des mannequins; Ils doivent transmettre une forte personnalité et refléter la diversité dans leur région.

Finalement, quelle est la différence entre un design system, un styleguide ou une librairie de composants ?

Un design system est bien plus qu’un ensemble de composants que vous utilisez pour créer vos applications métiers.  Pour faire simple, le design system comprends tous les aspects du styleguide, du language visuel et des libraires. Il comprend un guide pour que tous les métiers puissent utiliser des éléments valides.

Voici un petit exemple pour imager mon propos  :

Nous plaçons une boite contenant 100 briques Lego® devant 1 personne et lui demandons de créer une voiture uniquement avec ces Lego®.

Nous réitérons l'expérience avec une autre personne.

Puis nous comparons les 2 voitures. Il est sûr à 100% que ces 2 personnes auront créé une voiture différente.

Pourtant elles avaient toutes les deux les mêmes composants à disposition (100 briques Lego®).

Maintenant, nous faisons le même test en ajoutant une documentation.  Celle-ci va préciser que les pneus doivent être bleus et les phares jaunes. Les feux arrières peuvent être rouges pour indiquer que la voiture freine.

Si la documentation est claire et si les 2 personnes la comprennent, alors nous sommes sûrs que la voiture aura des pneus bleus et des phares avant jaunes. Nous saurons même si la voiture est en train de freiner ou non.  La boite de briques Lego, accompagnée de nos instructions et du guide d’utilisation forment un Design System.  

Ce dernier est perfectible puisque nos deux protagonistes pourraient gagner du temps avec plus d’informations (la taille d’un pneu, le type de brique nécessaire pour un phare, la couleur de la voiture...).

Les valeurs ajoutées du design system

En 8 ans d'expérience en tant que chef de projets, j'ai côtoyé à la fois des équipes qui n'étaient pas du tout familières avec l'outil, et d’autres qui l'avaient complètement intégré. Le design system leur ont permis de fournir des produits cohérents, pragmatiques et de qualité.

Un design scalable

En integrant un design system, on pourra proposer un accès à une source de directives et bonnes pratiques validées.

Qu'une équipe grandisse ou soit remaniée, tout le monde est sur la même longueur d’onde. Les différents styles graphiques restent cohérents, le travail en équipe est alors agréable et intelligent.

Un Design homogène / cohérent

Le design system permet d’avoir une interface prévisible et plus facile à comprendre. C’est un plus pour les utilisateurs et également pour les développeurs. Ces derniers peuvent ainsi se concentrer sur la production d’une fonctionnalité et sa performance sans se soucier du style.

Une conception graphique rapide

Lorsqu'une équipe travaille avec un design system, le lancement d’un nouveau produit devient assez rapide. Le designer pourra prototyper plusieurs variantes de composants et les retours de son équipe seront plus concrets. Il pourra réaliser des tests, analyser des comportements utilisateurs et de ce fait, proposer une interface plus qualitative.

Des évolutions faciles à mettre en place

Si le style d’une interface doit évoluer, le design system permet de réduire considérablement l’effort des développeurs et intégrateurs. Les itérations sont rapides et aucun conflit CSS ou Javascript n'est causé. L’équipe peut passer plus de temps sur l’expérimentation d’un produit plutôt que sur sa conception.

Les idées reçues du design system

Malgré tous ses avantages, le design system ne fait pas toujours l'unanimité dans une équipe. Certains membres pourraient craindre d'avoir trop de restrictions, trop peu de travail, ou une perte de créativité.

L'ajout d'une nouvelle fonctionnalité peut affecter plusieurs composants. Prendre en considération tous les éléments qui en sont impactés est très intéressant et relève de beaucoup de créativité.

En effet lors de la conception graphique, notre équipe sera amenée à créer des composants qui devront parfaitement s'adapter au design system. Les designers auront à prendre en compte l'existant et à faire en sorte que le résultat soit homogène et fonctionnels dans plusieurs situations.

Imaginez que votre nouvelle application nécessite une multi-search qui n'existe pas encore dans votre design system. Le designer va commencer par faire des recherches sur l'usage de ce composant (qui sont les utilisateurs ? Comment et pourquoi ils utilisent la multi-search ?). Il proposera un design cohérent avec d'autres composants. Il testera le bon fonctionnement du composant dans diverses situations. Et il le documentera pour que les développeurs puissent l'intégrer facilement.

En conclusion, pourquoi mettre en place un design system ?

Les méthodologies de développement ou d’ingénierie ont évoluées rapidement. Le design system est un moyen d'élever les méthodes de conception graphique à la même hauteur que celles du développement web. Il apporte des avantages considérables. En voici 4 qui justifient pourquoi mettre en place un design system :

• Il permet de créer une cohésion au sein d’une équipe.
• Il améliore nettement l’expérience utilisateur de vos outils.
• Il renforce l’image de l’entreprise. A titre d’exemple, un visuel bichrome est immédiatement associé à Spotify. Cela est dû au respect du design system sur toutes les application de la marque.
• Le coût de mise en place de nouvelles features est nettement plus faible avec un design system.

Et si on profitait de la rentrée pour partir sur de bonnes bases en se mettant en conformité avec le RGPD ?

Et oui, car une page "politique de confidentialité", ce n'est pas seulement pour les GAFA mais pour tout le monde... Grand ou petit, public ou privé, en Europe le RGPD vous oblige à afficher certaines informations si  :

• Votre site web collecte des données de façon directe (formulaire de contact, email, etc.)
• Votre site web collecte des données de façon indirecte (cookies, analytics, ads, trackers, etc.)

Il y a donc de grandes chances que vous soyez concerné. De toutes façons si vous consultez cet article, c'est que vous étiez déjà sur la sellette !

~ Disclaimer ~

Avis aux personnes pressées: pas de copier-coller vite fait sur le modèle pour être conforme au RGPD. Au delà d'écrire des informations sur une page, le RGPD impose de nombreuses restrictions par rapport aux données personnelles, notamment leur confidentialité et leur sécurité. Il impose aussi des actions comme la notification en cas de violation des données et la création d'un registre (oui un registre).

Si ce dernier paragraphe vous dépasse totalement, passez donc un petit coup de fil à la direction juridique pour qu'ils s'en occupent ! Et si vous n'avez pas de direction juridique, ou même pire, si vous faites partie de la direction juridique, poursuivons donc cette merveilleuse aventure.

Notre exemple: site web avec un formulaire et Analytics

Chaque site web doit avoir une politique de confidentialité spécifique en fonction des données collectées et de la façon dont elles sont utilisées.

Nous allons donc prendre comme exemple un site web simple avec Google Analytics installé, ainsi qu'un formulaire de contact classique avec les champs suivants : nom, email, téléphone, entreprise, objet, message.

Attention, si vous affichez du contenu embarqué (vidéo YouTube, fil Twitter...) ou bien que vous utilisiez des plugins ou tags (LinkedIn, Facebook...) il faudra consulter leurs conditions par rapport à leur collecte de données.

Dans tous les cas, je vous suggère fortement de passer du temps sur le site de la CNIL. Les infos sont plutôt bien présentées et, avouons-le, il n'est pas si dégueulasse pour un site juridique.

Les obligations légales du RGPD pour les sites web

Pour être en accord avec la loi dite "Informatique et Libertés", notre petit site doit donc respecter tout un tas de règles et d'afficher certaines informations.

Tout d'abord, les cookies Google Analytics ne seront installés qu'après confirmation de l'utilisateur (la fameuse "cookie popup"). Ensuite, pour le formulaire de contact, nous nous assurerons que l'utilisateur accepte l'utilisation de ses données en cochant une case.

Officiellement, il n'est pas obligatoire de rédiger une page "politique de confidentialité", mais les informations sur les données personnelles doivent être présentées (je cite...) "de façon concise, compréhensible et aisément accessible, en des termes clairs et simples".

Le contenu de la politique de confidentialité

On y arrive ! Dans notre exemple, la politique de confidentialité doit répondre aux questions suivantes :

• Quelles sont les données personnelles collectées et comment ?
• Pourquoi sont-elles collectées ?
• Qui est le responsable du traitement de ces données ?
• Quelle est la base juridique de la collecte ?
• Qui pourra consulter ses données ? Seront-elles transmises à des tiers ?
• Combien de temps seront conservées les données ?
• Quels sont les cookies utilisés dans le site web ?
• Quels sont les droits de l'utilisateur vis-à-vis des données ?
• Quel est le contact du DPO ?

Pour en savoir plus sur chaque question, cliquez sur le lien pour aller sur le site de la CNIL à la section correspondante.

Le modèle gratuit de politique de confidentialité

Voici donc le modèle de la page "politique de confidentialité" pour notre exemple. Attention, comme expliqué plus haut, ces mentions légales sont à adapter à votre site web.

Introduction

Dans le cadre de son activité, la société [Société], dont le siège social est situé au [Adresse du siège social], est amenée à collecter et à traiter des informations dont certaines sont qualifiées de "données personnelles". [Société] attache une grande importance au respect de la vie privée, et n’utilise que des donnes de manière responsable et confidentielle et dans une finalité précise.

Données personnelles

Sur le site web [Adresse du site], il y a 2 types de données susceptibles d’être recueillies :

• Les données transmises directement
  Ces données sont celles que vous nous transmettez directement, via un formulaire de contact ou bien par contact direct par email. Sont obligatoires dans le formulaire de contact le champs « prénom et nom », « entreprise ou organisation » et « email ».
• Les données collectées automatiquement
  Lors de vos visites, une fois votre consentement donné, nous pouvons recueillir des informations de type « web analytics » relatives à votre navigation, la durée de votre consultation, votre adresse IP, votre type et version de navigateur. La technologie utilisée est le cookie.

Utilisation des données

Les données que vous nous transmettez directement sont utilisées dans le but de vous re-contacter et/ou dans le cadre de la demande que vous nous faites. Les données « web analytics » sont collectées de forme anonyme (en enregistrant des adresses IP anonymes) par Google Analytics, et nous permettent de mesurer l'audience de notre site web, les consultations et les éventuelles erreurs afin d’améliorer constamment l’expérience des utilisateurs. Ces données sont utilisées par [Société], responsable du traitement des données, et ne seront jamais cédées à un tiers ni utilisées à d’autres fins que celles détaillées ci-dessus.

Base légale

Les données personnelles ne sont collectées qu’après consentement obligatoire de l’utilisateur. Ce consentement est valablement recueilli (boutons et cases à cocher), libre, clair et sans équivoque.

Durée de conservation

Les données seront sauvegardées durant une durée maximale de 3 ans.

Cookies

Voici la liste des cookies utilisées et leur objectif :

• Cookies Google Analytics (liste exhaustive) : Web analytics
• [Nom du cookie] : Permet de garder en mémoire le fait que vous acceptez les cookies afin de ne plus vous importuner lors de votre prochaine visite.

Vos droits concernant les données personnelles

Vous avez le droit de consultation, demande de modification ou d’effacement sur l’ensemble de vos données personnelles. Vous pouvez également retirer votre consentement au traitement de vos données.

Contact délégué à la protection des données

[Nom du contact] - [Idéalement au moins 2 façons de le contacter]

Bravo, vous êtes arrivés jusque là ! A vous de jouer pour une super page de "politique de confidentialité" !

Le RGPD (ou GDPR) réglemente l’utilisation des données personnelles dans l’ère du digital. Si vous avez un site web avec Google Analytics, vous êtes concernés. En effet, Analytics envoie des cookies et conserve des données considérées comme personnelles (les adresses IP).

Le visiteur n'a pas la possibilité de refuser les cookies sur cet exemple.

Nous allons donc réaliser 2 actions pour mettre Google Analytics en conformité avec le RGPD :

• Rendre les adresses IP anonymes (rapide)
• N’installer des cookies que chez les visiteurs qui les acceptent (long)

On voit souvent des bandeaux cookie qui indiquent simplement que le site web utilise des cookies, comme sur l’image ci-dessus. Ceci n’est pas suffisant car on installe instantanément des cookies sur le navigateur du visiteur alors qu’il n’a pas encore lu le bandeau.

Avouons-le: le RGPD est long à comprendre et à mettre en place. C’est un grand pas avant pour la privacité et les utilisateurs, mais il oblige les petites et moyennes organisations a prendre des mesures souvent chères et pénibles pour leur taille. Je vous conseille vivement de comprendre le sens général du RGPD et son application sur les cookies avant d’aller plus loin.

Le déroulement

Nous allons mettre en place le processus suivant :

On demande au visiteur s’il accepte les cookies, puis on lui envoie s’il accepte. S’il avait déjà accepté auparavant, on ne lui demande plus.

Nota Bene : L’utilisateur ne peut pas refuser “une fois pour toutes” de recevoir des cookies pour les sessions suivantes. En effet, dans ce cas il faudrait lui envoyer un cookie pour garder en mémoire le fait qu’il refuse les cookies.

Voici donc les ingrédients de la recette :

• Google Analytics (bien sûr)
• Google Tag Manager
• Du Javascript (sous n’importe quelle forme)

Si vous ne pouvez pas effectuer ces opérations, l’agence Buddyweb réalise des mises en conformités RGPD.

1 . Configuration de Google Tag Manager

Google Tag Manager (ou GTM) est un outil qui permet de gérer les balises tierces sur votre site web. Aujourd’hui, il y a une balise pour tout : Facebook, Twitter, LinkedIn, Google Analytics, Adwords, Hotjar… Au début ça va, on ajoute le script dans le code source, mais cela peut s’entasser au bout d’un moment. De plus, chaque configuration impose de modifier ce code et peut entrainer un nouveau déploiement.

GTM dispose d’une interface de type CMS qui permet de configurer chaque balise, ses paramètres et quand et comment elle se déclenche. Lançons-nous dans l’aventure !

A) Créer la variable accept_cookies

Une fois votre compte créé (copiez les 2 snippets de code GTM pour plus tard), commençons par créer directement une variable accept_cookies (en snake_case comme il est convention pour les cookies) à partir de l’onglet “variables”. Ceci permettra à GTM de lire le cookie accept_cookies sur le navigateur de l’utilisateur.

B) Créer le déclencheur “Accept Cookies Button Click”

Etant donné que nous allons lancer (ou re-lancer) Analytics à l’acceptation des cookies, nous allons créer un déclencheur customisé. Il sera relié au bouton “J’accepte les cookies” sur notre site web et exécutera le code des balises au clic sur ce bouton. On peut créer un déclencheur directement dans l’onglet “Déclencheurs”. Pour la propriété “Click ID”, choisissez “accept-cookies”, ce sera l’ID de notre bouton HTML.

C) Créer la balise qui active/désactive le tracking Google Analytics

Nous allons créer un script qui va aller voir si le cookie accept_cookies est présent chez l’utilisateur et faire un User Opt-Out si ce n’est pas le cas.

Cette balise sera reliée à 2 déclencheurs :

All pages : Se déclenche à l’arrivée sur une page

Accept Cookies Button Click : Prendre en compte l’acceptation de cookies au click sur le bouton “j’accepte les cookies”

D) Créer la balise Google Analytics et configurer son déclenchement

La 2ème balise que nous allons créer est celle de Google Analytics. Pour cela sélectionnez “Google Analytics — Universal Analytics” comme Type de balise et ajoutez votre ID de suivi (UA-XXXXXXXX-XX) après avoir coché la case Autoriser le remplacement des paramètres dans cette balise.

Reliez-la aux 2 mêmes déclencheurs et réglez le séquençage de la balise pour qu’elle se déclenche APRES l’autre balise (très important). En effet, nous voulons que GA se lance après que la balise précédente ait activé le tracking lors du click sur le bouton “accepter les cookies”.

Profitez-en pour définir le champ anonymizeIp à true comme sur l’image ci-dessous.

AnonymizeIp doit être à “true” pour être RGPD-compliant car de ce fait, les informations stockées ne sont pas reliées à un IP identifiable

2 . Configuration du front-end (site web)

Une fois notre gestion de balises réalisée, place au travail sur le site web. Nous devons le connecter avec GTM et demander aux utilisateurs s’ils acceptent les cookies avec un bandeau cookie RGPD.

A) Ajouter le script GTM

Il y a 2 scripts en réalité : un dans le <head> et l’autre dans le <body>. On peut les retrouver dans Admin > Installer Google Tag Manager. Les 2 scripts doivent être accessibles depuis toutes les pages.

B) Créer un bandeau cookie (ou cookie modal)

A partir d’ici, la méthode diffère en fonction du framework ou de la technologie utilisée. Ceci-dit, la logique reste la même :

• A l’arrivée sur le site : vérifier si l’utilisateur a le cookie accept_cookies. Si ce n’est pas le cas, on affiche notre bandeau RGPD.
• Dans notre bandeau, un bouton “accept-cookies” déclenche une fonction qui ajoutera le cookie accept_cookies et qui fermera le bandeau.

Pour ma part j’utilise Angular et ngx-cookie-service, mais vous pouvez faire de même avec React, Vue, jQuery ou d’autres. Voici la template de la modal ainsi que le composant :

3 . Tester avec la prévisualisation de Tag Manager

Google Tag Manager offre la possibilité de prévisualiser les modifications avant de les publier. Pour cela je vous conseille d’utiliser Google Chrome et d’ouvrir un nouvel onglet dans la même fenêtre avec votre site web. Vous pourrez ensuite tester le fonctionnement et valider le comportement suivant:

A la 1ère arrivée sur le site :

• Aucun cookie ne s’enregistre sur le navigateur
• La cookie modal s’affiche

Au click sur “accepter les cookies”

• Le cookie “accept_cookies” et les cookies de Google Analytics s’enregistrent sur el navigateur
• La cookie modal disparaît

Lors d’une suivante visite après acceptation (recharger la page)

• Les cookies sont toujours là
• La cookie modal n’apparait pas

Lors d’une suivante visite SANS acceptation des cookies

• Pareil qu’à la 1ère arrivée sur le site

Attention ! Pensez à effacer vos cookies avant de commencer et d’actualiser les cookies à chaque changement (bouton “refresh” en haut de la liste du devTools).

Si les tests sont concluants, vous n’avez qu’à publier vos modifications sur GTM et sur votre front-end pour passer en production. Si l’appel de gtm.js renvoie une erreur 404, c’est que les modifications n’ont pas été correctement publiées.

Conclusion : Une utilisation de cookies Google Analytics conformes au RGPD

Grâce à cette méthode nous avons réussi à envoyer des cookies uniquement aux visiteurs qui les ont acceptés. La différence avec un bandeau strictement informatif “ce site utilise des cookies” est importante car le visiteur a le choix de les accepter ou non.

De plus, l’IP du visiteur ne sera pas conservé en tant que tel, mais transformé pour devenir anonyme. En effet, l’adresse IP “en clair” permet l’identification d‘une personne et relève donc des données personnelles. Le RGPD vous obligerait donc à prendre en compte tout un tas de trucs supplémentaires.

Et voilà pour la plupart ! Par contre si vous envoyez à Google Analytics des données personnelles (identifiants, valeurs de formulaires, etc.), il vous faudra bien évidemment vous mettre en accord avec le RGPD sur ce point là aussi.

Bon courage !

Dans ce tutoriel nous allons créer une application concrète de A à Z avec Angular. La documentation officielle est bien faite, mais on a souvent besoin de voir des examples concrets pour avancer.

Nous allons donc partir de zéro pour créer une application pragmatique qui va afficher des résultats de matchs de foot (c’est un exemple, la même méthode peut nous aider à récupérer n’importe quelle donnée). Nous irons chercher ces résultats sur une API externe et les afficherons dans notre app. Voici donc les différentes étapes:

1. Installer Angular
2. Configuration SCSS
3. Installation kit UI
4. Création des composants
5. Routing
6. Création des services
7. Interfaces
8. Appels HTTP
9. Affichage des variables dans les templates

Info: Le code source de l’application est disponible ici. Cet article est le résumé des 2 vidéos suivantes :

Installer Angular

Pour créer un nouveau projet Angular, vous avez besoin de la CLI d’Angular et de NodeJS. CLI signifie Command Line Interface, c’est un outil qui vous permettra de taper des commandes commençant par “ng” sur votre terminal.

Une fois ces dépendances téléchargées, tapez dans votre terminal :

ng new angular-tutorial

Ce qui va créer un nouveau dossier à votre emplacement actuel et installer un projet Angular dedans. Cela va prendre quelque temps à s’installer, puis vous pouvez vérifier en servant l’app :

cd angular-tutorial
ng serve

Et en allant sur https://localhost:4200 avec votre navigateur. Vous devriez maintenant voir un gros logo Angular. Tout va bien pour l’instant.

Configuration SCSS sur Angular

Par défaut les fiches de style sont en .css sur Angular. Si on veut passer à SASS par défaut (je vous le recommande), il faut modifier les paramètres du fichier angular.json :

"schematics": {        
  "@schematics/angular:component": {          
    "styleext": "scss"        
  }
}

A partir de maintenant, lorsque vous allez créer un composant, sa fiche de style sera par défaut en SCSS. Il me semble que la même configuration permet de faire la même chose pour du LESS.

Installer un kit UI (framework CSS) sur Angular

Dans notre example nous allons utiliser un kit UI très puissant et très simple qui s’appelle Bulma. Installons le avec une commande NPM. Dans le terminal à la racine du projet faites :

npm i bulma --save

Angular prône une philosophie d’encapsulation de ses composants, y compris pour le style. Ce principe permet d’éviter que vos déclarations “débordent” des composants, par exemple vous pouvez appeler un élément “title” sur chacun de vos composants et lui donner des propriétés différentes sans qu’elles se superposent. Chaque composant contient sont “title” et ses définitions qui se limitent à lui-même. Chacun chez soi, tout le monde est content.

Ceci est très bien et très utile, surtout sur les grosses apps, mais nous voulons faire une seule exception à la règle pour que notre kit impacte tous les composants avec un style par défaut. Chaque composant pourra ensuite ajouter ou surcharger ces propriétés avec des déclarations spécifiques et limitées à lui-même.

Nous allons donc retirer l’encapsulation du composant principal et de faire un lien vers une nouvelle feuille de style qui importe notre kit :

Utilisation de la propriété “encapsulation” du décorateur @Composant

Dans cet example, on a crée un fichier main.scss dans /assets/styles. Ce fichier ne comprend qu’une ligne qui importe notre kit Bulma :

@import '../../../node_modules/bulma/bulma';

Et voilà, en retournant sur notre page d’accueil on doit déjà voir que le style à légèrement changé (typo plus ronde et couleur plus grisées). On avance !

Création de composants

Créons un composant pour le header afin de diviser nos templates :

ng g c partials/header

La commande “generate component” (abrégée “g c”) va créer un composant header que nous allons pouvoir appeler dans app.component.html avec la balise app-header.

<app-header></app-header>

Il est possible d’en faire de même pour le footer ou d’autres éléments de l’app. Il vaut mieux beaucoup de petits fichiers qu’un seul gros fichier.

Routes et URLs dans Angular

Maintenant nous allons créer 2 vues différentes : MatchList et MatchDetail pour afficher respectivement la liste des matches et le détail d’un match

ng g c resources/matches/match-detail
ng g c resources/matches/match-list

Et nous allons créer un nouveau fichier app.routes dans /app avec le contenu suivant :

app.routes.ts

Puis l’importer dans app.module.ts avec appRoutes en paramètre de forRoot :

imports: [BrowserModule, RouterModule.forRoot(appRoutes)]

Pour finir, il nous faut ajouter une balise dans le HTML (app.component.html) qui va nous indiquer ce qui va changer en changeant de route :

<app-header></app-header> 
<router-outlet></router-outlet> 
<p>FOOTER</p>

Dans cet example, le header et le <p> footer vont rester là tandis que le contenu de <router-outlet> sera remplacé par le contenu de nos composants si la route change.

Créer des services HTTP dans Angular

Pour cette étape nous allons utiliser un outil gratuit nommé Bridge, qui va nous permettre de créer des APIs en JSON depuis un tableau CSV.

Outil Postman

L’API est ouverte est accessible à l’URL :
- https://bridge.buddyweb.fr/api/tutorials/matches pour la liste des matchs
- https://bridge.buddyweb.fr/api/tutorials/matches/1 pour le détail

Nous allons donc créer un service qui va récupérer ces données là.

ng g s common/services/match

Et nous voilà avec un MatchService.

Interfaces

Les interfaces sont une fonctionnalité de TypeScript qui va nous permettre de définir précisément ce qu’on va recevoir, en l’occurrence un “match”. Qu’est ce qu’un match ? Pour notre application nous allons définir ce concept en créant une interface Match dans un fichier match.ts :

L'interface Match détaille les défférentes propriétés d'un Match.

Appels HTTP depuis les services Angular

Maintenant que nous savons quel type de données nous allons recevoir et l’URL à laquelle nous allons les recevoir, il ne manque plus qu’à passer l’appel. Commençons par doter notre service de 2 fonctions, une pour récupérer la liste de matchs (sans paramètres), et l’autre qui va récupérer un seul match en fonction de son ID.

Tout d’abord nous avons besoin d’ajouter le HttpClientModule dans app.module.ts, nous avions déjà touché cette ligne pour ajouter les routes :

imports: [BrowserModule, RouterModule.forRoot(appRoutes), HttpClientModule],

Voici le service avec nos 2 fonctions :

La fonction list() retourne un Observable qui se résout en array de Match tandis que la fonction show(id) renvoie un Observable qui se résout par un Match unique.

Les outils sont prêts, il ne reste plus qu’à s’en servir. Utilisons la fonction ngOnInit() pour lancer notre requête HTTP instantanément en arrivant sur la MatchList :

NgOnInit() nous permet de charger la liste des Matchs et de la stocker dans la propriété matches de MatchListComponent.

Même combat pour la MatchDetail, avec cette fois-ci une différence: le paramètre “id” sera récupéré directement depuis l’URL grâce à ActivatedRoute.

Pour tester les 2 réponses, il suffit de se rendre sur l’url http://localhost:4200 et sur http://localhost:4200/matches/1 par exemple. Ensuite regarder si l’appel HTML a bien été réalisé dans la console/DevTools de votre navigateur.

Afficher les variables dans les templates

Et le plus facile pour la fin ! Une fois les matches disponibles, il suffit de les appeler en utilisant la double accolade, ainsi que les directives Angular nécessaires comme *ngFor ou *ngIf

match-list-component.html

Je vous laisse faire de même (ou mieux que moi) pour le match-detail-comonent.html

Conclusion

Nous avons parcouru beaucoup de chemin depuis l’installation de Angular ! Ces fonctionnalités sont basiques et utilisées dans la plupart des projets Angular.

Like many of you, I grew up watching hackers in movies. I was really thrilled to see those hacking scenes in the late-90’s and 2000s movies. The hackers were some kind of modern-era super heroes. This image shaped the way people perceived the job of developers. It actually made people believe that that those movie-hackers had the requirements to be good developers.

Nowadays, to build a website or a platform, we have plenty of diverse profiles, skills and sensitivities collaborating together. But before the digital labour got divided, there was a single person doing everything such as server monitoring, UX design and even comment moderation.

That “webmaster” had indeed a lot of responsabilities back then. Even more than you think, as most people didn’t get anything about computers at that time. They needed someone to do what seemed magic for them: They needed a wizard, and in response to that, developers acted like wizards.

You don’t need to be a wizard anymore

Many things changed since that era, one thing in particular : developers are not alone anymore. They came out of the cave to sit on nice office chairs. They became a valuable and acknowledge part of a workforce, and their non-technical pairs can now understand most of their concepts because they are daily IT users too. Magic became craft, and it’s a good thing.

The most important change is that a large part of the developers work in team. Working in a team means a lot of things. First of all, you cannot be an a**hole anymore. You owe respect to all of your teammates and you must develop a new set of skills : Discipline, communication, empathy and pedagogy. None of those are tech-related skills.

In my 10-year developer experience, I met and worked with many of those so-called wizards or geniuses. Speaking loudly technical terms, making you feel bad if you don’t know this or that technology. In my junior years, I was really impressed by them. I often felt ashamed, because, as a developer, I thought I should have understood them but I didn’t get a word of their jargon.

But you know what ? That’s bullshit. Our job is to make complex things easy, not the opposite. I say that for junior developers like I was at that time, and for anyone impressed by their speeches.

Let’s make it easy instead !

Ok, let’s face it : Our job is not that difficult. Very few developers are working on really hard-to-grab concepts. Most of us, including myself, are basically sending, receiving and manipulating data. I am not saying this in a bad way, the point is that those concepts are mainly understandable. Don’t you think we should be able to talk about them simply with non-tech savvy people ?

There was a time where computing was not for everybody. The tools were rudimentary (if they even existed), there was a lot of calculation involved and you needed a lot of will to make anything work as you wanted. But right now ? Day-to-day there is not that much to invent or to hack. We need people who think clearly.

In order to remove that sticky wizard-hacker prejudice, we need to change the perception of our job. It starts with changing ourselves : to communicate inclusively and understand that we are now part of a production chain.

Code katas for example (coding exercices) or coding contests are overrated in my opinion. Of course it’s a good way to learn code and have fun, but companies should not overlook that point : A developer that understand the business value and respects the job frame is way more profitable than a developer that can find all prime numbers in one (illegible) line of code.

Or… let’s be a part-time wizard

If you are a developer and reading this post, you are wandering since when developing became that boring, I can tell you : Since it pays good.

Coding as a job is not an adventure in the wild, it’s full of methodology, meetings, explaining yourself, testing and many more boring stuff. But it is still super fun to do. And in addition to that, you still can be a wizard in your free time and have a lot of experimental side-projects in obscure languages !

That’s it ! What do you think about the evolution of the job of a developer ? What are the qualities that you think a developer should have or not have ? I would be glad to see your opinion (for devs AND non-devs) in the comments :)

Overscroll-behavior est une propriété CSS qui permet de contrôler le comportement par défaut du navigateur lorsqu’on dépasse une zone de scroll.

Contexte

Le Scroll-chaining

L’interaction de certains éléments lorsqu’on scroll sur une application web ou mobile peut paraitre intuitive. Et pourtant, il faut parfois surcharger le comportement proposé par le navigateur pour obtenir le résultat attendu.

Prenons l’exemple d’une modale qui s’ouvre par dessus un article. Il faut scroller dans cette modale pour pouvoir lire tout son contenu.

Par défaut, si on scroll en dépassant la limite de défilement de ce contenu, alors la page sous-jacente défilera sous la modale.

On appelle ça le scroll-Chaining.

Dans notre cas, ce comportement est gênant car, après la fermeture de la modale, on ne se retrouve plus au même endroit sur notre article.

Le pull-to refresh

Un autre exemple est celui du pull-to-refresh. Certains navigateurs mobile proposent de rafraichir du contenu en défilant jusqu’en haut ou en bas d’une page.

Dans certains cas, cet effet n’est pas souhaité. Il est alors nécessaire de le désactiver pour avoir un comportement intuitif.

Introduction de overscroll-behavior.

overscroll-behavior permet de contrôler le comportement de ce qui se produit lorsque vous faites défiler un conteneur.

Il peut être utiliser pour annuler le scroll-chaining ou le pull-to-refresh. Cette propriété n’a aucun impact négatif sur la performance.

Les valeurs de la propriété

auto Le dépassement de la zone de défilement se déroule normalement. C’est la valeur initiale.

contain Le défilement a un comportement normal sur l’élément concerné. Les éléments sous-jacents ne sont pas impactés par ce défilement.

none Même chose que contain, les effets de défilement sont aussi évités à l'intérieur de l’élément.

La propriété est un raccourci de overscroll-behavior-x et overscroll-behavior-y. Elle est définie par l’une de ces valeurs pour l’axe x puis y.

Si une seule valeur est indiquée, alors elle s’applique à la foie pour x et y.

Overscroll-behavior est une propriété non héritée. La spécification est consultable sur le Github du WICG.

Mise en pratique

Dans notre cas, on affiche une modale ouverte par dessus un article. Cette modale a suffisamment de contenu pour être scrollable.

Si je scroll dans la modale en dépassant sa limite de défilement, le comportement par défaut sera d’appliquer un scroll à l’élément qui est en arrière-plan. A savoir, l’article.

Nous ne voulons pas appliquer cet effet. Notre souhait est d’empêcher le scroll sur l’article pendant que la modale est ouverte. Tout ça, sans utiliser javascript.

Pour cela on utilise overscroll-behavior-y: contain.

Vous pouvez tester l’impact de cette propriété sur l’utilisation du scroll en activant et désactivant la valeur “contain” de la modale sur ce pen.

Compatibilité navigateurs

Plus d’informations sur la compatiblité sur CanIuse.

On me demande souvent oú trouver de l’inspiration, que ce soit pour définir une typo, des couleurs ou une mise en page. Il existe des centaines de ressources UX, des portfolios aux outils de présentation en passant par des librairies de composants. Je liste ici une sélection de ressources que nous utilisons à l’agence.

Outils

http://diytoolkit.org/tools/ : C’est une boîte à outils très complète. Les outils sélectionnés sont bien documentés.

Inspiration

https://www.awwwards.com/ : On ne le présente plus je pense. C’est la plateforme que j’utilise le plus pour m’inspirer des dernières tendances.

https://thefwa.com/ : Une alternative à AWWWARDS. Il y a d’autres plateformes comme celle-ci qui récompensent les meilleurs sites web. A vous de voir laquelle vous préférez utiliser. Ces 2 là sont mes favorites.

https://www.behance.net/search?field=132&content=projects&sort=featured_date&time=week&featured_on_behance=true : J’aime bien m’inspirer sur Behance parce qu’on trouve beaucoup de Web Design Concepts. Les designers proposent des interfaces très innovantes. Parfois même trop puisqu’on trouve souvent des interfaces impossibles à développer. Pour l’inspiration, car reste une plateforme parfaite.

https://reallygoodemails.com/ : Ce site recense des mails HTML avec le code source parfois. Dans certaines situations, c’est plus simple d’utiliser cette plateforme plutôt qu’un framework email qui peut prendre du temps de développement.On peut trouver la template mail de MeetUp, Uber ou encore AirBnb.

Really Good Email : Filtrez les mails par catégories, sélectionnez une template mail, puis éditez son code source.

https://www.pages.xyz : Une sélection de pages web

https://www.lapa.ninja : Une sélection de jolies Landing Pages

https://www.designspiration.net

https://fontface.ninja/ : Une extension pour Chrome géniale ! Elle permet de savoir quelle typo est utilisée sur un site consulté. On peut ensuite tester la typo via l’outil.

https://mobbin.design : Une collection des derniers patterns piochés dans le meilleur du design mobile.

https://www.typographicposters.com/ : Une belle plateforme pour l’inspiration. On trouve une sélection d’affiches avec une utilisation des typos très bien faite. Petit bémol : Le filtre est assez compliqué à utiliser je trouve.

Design de composants

https://savee.it : Une sélection de designs de composants. C‘est idéal quand on travaille sur une fonctionnalité. Vous pouvez par exemple faire une recherche de type « Calendar » ou « landing page ».

http://collectui.com/designs : Une liste de composants sélectionnés pour la qualité de leur design depuis dribbble et catégorisés par composant. C’est plutôt cool !

http://styleguides.io : Une sélection de styleguides.

https://www.calltoidea.com : Une alternative à Savee.it. Vous pouvez trouver des mockups de pages 404, Popups, players, listes d’offres d’emploi, et plein d’autres éléments …

http://uigarage.net : Au cas ou ça ne vous suffirait pas, encore une alternative à Savee.IT ou calltoidea.

https://uimovement.com : Une sélection qualitative d’animations. Tapez “carousel”, “scroll” ou “menu” et vous verrez…

http://emptystat.es : C’est une liste de designs qui correspondent à des états vides. Qu’affiche tableau de bord sans information ou une application de gestion de projet sans projet ?. C’est intéressant et il y a peu de ressources comme celles-ci.

https://undraw.co/illustrations : Une liste d’illustrations libres de droit. On peut attribuer une couleur principale à chaque illustration avant de la télécharger.

R&D

https://www.productmanual.co : Ce site est très complet. Pour chaque thème il liste des articles, livres, podcasts et outils.

https://muz.li : C’est top juste TOP ! Muzli est une extension de Chrome qui offre des histoires et des idées de design pertinentes. Tout est pioché parmi les meilleurs sources de contenus web (webdesignerdepot, Abduzeedo, Designspiration, etc…). J’adore cette extension. Elle me permet de faire de la veille plus facilement. Je ne vais pas chercher l’information. C’est elle qui vient à moi.

https://www.webdesignerdepot.com/category/community-inspiration/ : la catégorie “community inspiration” de webdesignerdepot. C’est un classique mais la sélection des tendances à venir est superbe . Un indispensable pour moi.

https://design.google/news

https://designshack.net

https://uxmyths.com

Photos

https://unsplash.com

https://www.pexels.com

Icons

https://feathericons.com : Une petite librairie d’icônes.

Outils

https://getavataaars.com : Une générateur d’avatars.

https://www.palettable.io/ : J’utilise cet outil pour sélectionner mes couleurs. Je trouve ça bien fait pour un premier jet. La sélection des couleurs n’est pas forcément définitive mais ça me permet de débloquer certaines situations. Ensuite je travaille aussi avec d’autres outils comme ceux-ci :

https://hihayk.github.io/wheel/?ref=webdesignernews.com

https://coolors.co/app

https://color.adobe.com/fr

Et voilà ! J’espère que vous avez découverts de nouvelles ressources.

For developers, IDE/Text-editor choice has passed beyond rational debate long time ago : it’s something personal. For that reason, I don’t want to create another VSCode VS WebStorm post, but instead relate how and why I came to switch from JetBrains WebStorm to Microsoft VS Code.

Why change from one to another ?

First of all, let me say that both softwares are really good.

I have been working for 4 years on IntelliJ IDEA (IntelliJ, WebStorm, PHPStorm, PyCharm are basically “flavors” of the same product). I loved my experience and I even wrote a post about it at that time.

Both WebStorm and Microsoft Visual Studio Code are VERY similar, so why loose time to learn something new ? All started with performance. As my MacBook Pro started its third year of existence, it became a bit slow (thanks planned obsolescence), an its 8gb of RAM are not that much when WebStorm only itself often uses 2gb.

I heard that VS Code was more lightweight and I decided to take the opportunity to try the thing that everybody is talking about. When I say everybody, I mean the louder ones, the JS and NodeJS developers :)

Actually, I’m one of them without being one of them. I’ve started with PHP and did many Laravel projects, then started with AngularJS when it came out and evolved to Angular. I fell in love with TypeScript and I’m still learning to do some server-side programming with a Node.js/TypeScript framework called Nest.

Ok, let’s go back to performance. Using VS Code did a huge change in overall performance and my Mac seems young again. One point for VS Code !

Starting with VS Code

To reduce the learning curve, you can start by installing some plugins : IntelliJ IDEA Keybindings, Code Spell Checker, Prettier, goto-last-edit-location, Auto Rename Tag, TODO Highlight. Those features are available out-of-the-box on WebStorm but we have to download them as plugins in VS Code. There is huge difference in their philospohy : As WebStorm comes with key-packages included from start, Microsoft VS Code comes half-naked and you have to dress it (like a PHP project in comparison to a NodeJS project). It’s neither good or bad, but the approach is different.

Settings are easy to change, JSON-style make it easy to search and to make the difference between the default ones and the ones you specifically changed.

Global UI is cleaner than WebStorm. For minimalist-lovers like me, you can use Zen Mode to focus even more.

Day-to-day work on VS Code

After few days, I’m still adapting but I am quite happy with my new editor. Code’s Source Control is so much nicer that WebStorm. I use the Git Extension Pack and everything is smooth. I actually don’t really know which features are native or from the plugin, it’s probably a good thing.

Regarding the terminal,I found out that VS Code is more convinient. With your keyboard you can Create New Integrated Terminal, split panes and navigate between them just with shortcuts. Maybe that shortcut exists on IntelliJ but I couldn’t find out.

Angular on VS Code

Let me introduce you to Material Icon Theme. I’m actually not a huge fan of material design, but the point of this theme is that file icons represent not only their extension but their roles.

Components, pipes, and services have different colors to distinguish them.

Another good thing for Angular developers : VS Code doesn’t save the file on highlighting other applications. That means that your browser will not reload unexpectedly. If you know what I’m talking about, you know it’s bothering.

TypeScript on VS Code

Did I already told you that I love TypeScript ? TypeScript is great because it’s a fail-fast language that solidifies your apps. And there is a greater benefit, TypeScript helps IDEs to understand your code, and IDEs rewards you by providing you a better code completion and highlight errors. Unless you are still in the samouraï era and use emacs or vim, TypeScript will save you a lot of time and prevent mistakes.

VS Code was made by Microsoft that created TypeScript too. I had great expectations on that point. But WebStorm is already excellent on understanding TypeScript… Unless one tiny point : WebStorm doesn’t get ES6 Template strings, VSC does. Anyway, both IDEs manage very well this language. Maybe VS Code will have a better / quicker implementation of future versions ?

PHP on VS Code

On the other hand, PHP support is way better on IJ. If you work exclusively in PHP, stop reading here and keep IntelliJ.

The future

Before investing your precious time into something, it’s important to ensure that this thing will not die tomorrow. When I decided to learn Laravel (42k stars on Github today), around 4 years ago, it was way less used than Symphony (17k) , CakePHP (7k) or Yii (5k). But they where clues : overall quality was really good and acknowledged by thrusted developers, Github repo was well maintained and even the website design was nice and clean.

IDE choice is less community-dependent than an open-source framework but still it’s important to check if people are still going to use it in the future. Digging around the web, I found that VS Code seems having more and more enthusiasts whereas the other one is stagnating.

Did you heard about Solidity ? It’s a quite new language to create decentralized apps on the Ethereum blockchain. Let’s say that it’s the new BIG thing alright ? So, witch editor do you think has more Solidity support ? Again, VS Code.

Conclusion

If you don’t have a good reason to change from one to another, you’re not missing much by not doing it. Those are both really good software. If you have to choose between both, I would say that PHP and Java devs should go IntelliJ and JS/TS devs with VSCode. For myself, I’ll keep VS Code. And you ?

VS Code pros

• Open Source
• Lightweight : less RAM and CPU usage
• Bigger community : plugins, tutorials, etc.
• A bit better with JavaScript and TypeScript
• More “future-proof”

WebStorm pros

• Better PHP / Java support
• Less Intrusive
• More configurable
• More stable

# Non-technical paper

Betting is a juicy business, but mostly for the casino. Even in sports betting, which requires a lot of strategy, very few people can bet for a living. The house always wins because they are keeping some of the money. Inevitably, bettors end up loosing.

Can the blockchain change this ?

The blockchain is a technology that empowers communities by cutting middle-men and bottlenecks in many configurations.

In this paper, we will demonstrate how we can make “fair bets” using two key features of the blockchain : crypto-currencies and smart contracts.

With this explanation comes a functional proof-of-concept (POC) : the betdemocracy.org sports betting platform. Why sports betting ? Sports betting is huge on the internet and bookmaker margins are up to 10 times bigger that in any other betting types.

What is a “fair game” ?

A fair game is a game where the rules are not favorable to a specific side. Let’s say that two players play heads or tails for 1 € each throw, and get 2 € in case of win. In the long term, they will almost finish in the position they started in. We can say that this game is fair.

If players get rewarded 1,80 € per win by a middle-man (the coin-thrower), they will both finish broke soon if they keep playing. That game is not fair and it’s more or less what happends in casino games like black jack or roulette.

Real life case

In our example, we will use 1X2 soccer bets on the World Cup 2018 in Russia. In this kind of game, you can bet for the 3 possible outcomes : a home team win, an away team win or a draw. As stronger teams have more chances to win, each of the 3 outcomes has a specific odd. In other words, you will get a bigger reward if you betted for the underdog than if you betted for the favorite. Let’s have a look to the odds for France X Peru in one of the major betting sites in the world (odds are almost similar in all platforms).

Odds for France X Peru soccer game. Fractional and moneyline odds are calculated from decimal values.

The total exceeds 100 %. This represents a bookmaker margin of 5,01%, which is not bad, margins are usually between 5% and 15% in those bets.

Now, let’s compare it with a “perfect” situation where the bookmaker doesn’t take any margin :

We estimate odds with cross-multiplication. Fractional and moneyline odds are calculated from decimal values, rounded to 0.01.

As you can see, all odds are better without the bookmaker margin. You may think that 5% doesn’t count very much, but it’s a huge difference. Have a look of betting experts’ yields on this website and you will struggle to find a pro better with a ROI > 5% .

How can we get rid of bookmaker margin ?

To get rid of the bookmaker margin, we have to get rid of the bookmaker itself. That is where the blockchain can help us.

A blockchain is a network were the power is decentralized and shared to the whole network. Our choice for this project is the Ethereum blockchain for many reasons :

• It’s the 2nd biggest in market cap (right after Bitcoin), so many people own Ethers, its crypto-currency
• Unlike Bitcoin, it support smart contracts. There is a well-documented language for those contracts : Solidity
• There is a strong community and there is many projects on top of it

Ethereum acts like a single universal computer where you can add pieces of code : smart contracts. A smart contract is like a digital contract between one or several entities. It also acts like a wallet as it can receive and store money. Our smart contract will store opponents’ bets safely and return the money back to the winner.

Betting against each other

At this point there is a big difference: in betting sites, you always play against the house. The casino takes all bets.

Without casino, you have to play against someone betting for the exact opposite. For “France X Peru”, if you bet for a “France win”, you need someone betting for a “Peru win or draw” and agree on the odds and the stake. With that said, we are clear that we must have a platform to connect people.

To keep it simple, we look for one person to complete the player’s bet using double-chance bets (like “Peru win or draw”). It can work with more opponents : a “draw” bettor and a “Peru win” bettor. We also can have several players that join their stake to meet opponents requirements. But let’s keep it simple for now.

Indeed, our proof-of-concept is like a marketplace, but we can imagine an automated platform like an exchange it the future.

The cost of the bet

Let’s be clear : at the time we are writing this, crypto-currency transactions and smart contract execution require (small) fees. We will not achieve a “perfect” fair bet because the cost is not zero BUT we will consider that a bet is fair if the cost is ≤ 0,01 % of the total stake.

To make that number more visual, imagine that you bet for the 3 possible outcomes of a game (just for the example). It means that just one bet per match would be correct. In traditional betting sites, your initial stake will reduce by more than half after 14 games. With what we consider a fair game, you need to do the same for 6931 games to see your stake reduce to half of what it was. It is a ridiculously high amount of games so we can agree that the bet is “fair”.

In blockchains, fees are not based in the amount of money that is sent, but on the computation power that is needed to process the transaction. It means that fees are fixed costs. The higher the stake, the lower the cost in percentage.

Based on previous transactions on Bet Democracy, we found out that the average bet needs around 35 000 gas to be processed. In Ethereum, gas is the basic unit for computing power. The more complicated the function you call, the more gas you spend. And, of course, you have to pay your gas : )

You can choose the price you pay to skip the line or save money (or somewhere in the middle). In this example, we are using the SafeLow gas price of 1 gwei, it’s the lowest price then ensures you that the transaction will be validated for sure. As this is a non-technical paper I don’t want to enter too much into details, but another paper will be created with more explanations.

At today’s rate of 1 ETH = 401,49 €, the price of the bet is 0,15 € divided by the bettors. Let’s make a chart.

Bet cost in percentage based on total stake in Euros (logarithmic scale).

There is 2 important points in this chart :

• At 3 € of bet total stake (your stake plus your opponent’s), the bet is cheaper than in almost all betting sites (< 5%).
• At 935 € of bet total stake, the fees are equal to 0.01 % and we consider it a “fair bet”.

Conclusion

With this paper and the Bet Democracy platform example, we proved that we can achieve a virtually “fair game” in Sports betting.

We strongly believe that we can decrease the gas needed by optimizating the smart contract to lower that 935 € “fair bet” step. In addition to that, as blockchain technology quickly improves, transaction prices are lowering. Transactions are already free in many blockchains.

So, YES, blockchains can provide “fair bets” and YES it is probably going to disrupt the betting industry. Blockchain betting enables many possibilities, especially everything about reducing costs, bet trading and anymousity.

Of course, there is some obstacles : crypto-currencies are not yet widely used by bettors and people need to gain confidence in blockchains. Security can be a big deal too, as we already saw smart contracts being robbed by hackers. But we are really confident about the fact that there is a bright future for blockchain betting.

If you read until this point, we recommend that you have a look at the POC version of Bet Democracy that enables bets with dummy-money (Ropsten Ethers). Make sure to have the MetaMask extension on your browser.

Our plan is to build a fully functional version on the main Ethereum network with real money. We are looking for funding, sponsoring and anything that can help us achieve our goal. If you are interested, write us at hello@betdemocracy.org.

Il y a plein de raisons d’arrêter d’utiliser Google : privacité, éthique, pratique, ou tout simplement pour arrêter de nourrir le monstre qui est bien parti pour en finir avec l’humanité un de ces jours.

On a donc testé quelques alternatives pour vous. Différentes approches, différentes promesses. Découvrez tout de suite les moteurs de recherche de l’internet d’aujourd’hui.

DuckDuckGo : Le moteur de recherche respectueux de la privacité

DuckDuckGo est le “moteur de recherche qui ne vous espionne pas”. Soucieux du respect de la vie privée, il n’y a pas de trackers ni sur le moteur de recherche, ni sur les publicités. Aucune information personnelle n’est conservée. La classe.

Ecosia : Le moteur de recherche écolo

Ecosia : “lancer une recherche pour planter des arbres”. Ils gagnent de l’argent avec les liens sponsorisés et reversent 80% des ces revenus à des associations environnementales. Ecosia est en fait un meta-moteur de recherche : sous le capot, c’est en fait les résultats de Bing qui s’affichent. Ecosia est totalement transparent sur son activité et publie des rapports financiers tous les mois.

Lilo : La recherche solidaire

Lilo est également un moteur de recherche engagé. Chaque recherche permet d’obtenir des “gouttes” que l’on peut convertir en don pour une association de son choix. Sympa ! Comme Ecosia, ils agissent comme une sur-couche d’autres moteurs de recherche (Google et Bing pour le coup).

Bing : Le challenger qui n’a pas su s’imposer

Conçu par Microsoft en copiant clairement Google sur tous les points, Bing n‘a jamais vraiment réussi à inquiéter Google. Pourtant, Microsoft avait soi-disant réalisé un test qui prouvait que ses résultats étaient meilleurs que ceux de Google… Malgré son éternelle 2ème place ils est néanmoins un très bon moteur de recherche.

Personnellement, en tant que développeur, j’aime bien leur API de recherche qui m’a bien servi pour certains projets.

Twitter : L’information LIVE

Si vous cherchez l’actualité immédiate sur un évènement qui se passe en ce moment même, Twitter est votre meilleur allié.

Twitter n’obéit pas aux mêmes règles que les moteurs de recherches : Il n’a pas à indexer des millions de sites pour en trier l’information. Tout est déjà sur sa plate-forme.

Google Maps : Recherche de lieux

Bon j’avoue, ce n’est pas une “vraie” alternative à Google, mais cela vaut quand même le détour !

Avec toujours plus de lieux répertoriés, Google Maps permet de rechercher des lieux et de consulter les photos et les avis des utilisateurs. La disposition des résultats sur une carte et le fort côté social en font un moteur de recherche très efficace pour des recherches de restaurants, attractions touristiques et lieux particuliers.

Quora : Des questions et des réponses

Comme nous l’avons vu, un moteur de recherche ce n’est pas forcément des résultats soulignés en bleu sur un fond blanc ! Quora en est l’exemple : c’est une plate-forme de questions et réponses, un peu comme Yahoo Questions/Réponses mais avec des gens intelligents.

La version anglaise a pratiquement la réponse à tout, tandis que la version française est un peu moins fournie. Et dans tous le cas, vous pouvez toujours poser votre propre question si vous ne trouvez pas ce que vous voulez…

Siri / Alexa : Les assistants vocaux

2017 est l’année de sortie de l’Amazon Echo, du Google Home et du HomePod d’Apple. Tous investissent dans la sortie d’un assistant vocal, même si leur arrivée dans nos salons en intimide plus d’un.

Ces assistants sont déjà présents sur nos smartphones et sur quelques ordinateurs. Ils nous permettent une recherche vocale et non plus visuelle. Le recherche vocale est pressentie pour remplacer petit à petit la recherche textuelle.

Lycos : L’oublié

Et pour finir on vous laisse avec Lycos, qui autrefois faisait concurrence à Google pour ceux qui s’en souviennent (va chercher Lycos !).

Eh oui, le moteur de recherche est toujours sur internet. C’est moche, c’est kitch et c’est lent, mais ça fait du bien une fois de temps en temps !

Bridge is a free tool to create REST APIs for your mocks or Open Data projects.

Quick tutorial to go from an Excel or CSV file to an open REST API in JSON in just 2 minutes with Bridge.

Which kind of API can we create ?

Bridge is a free tool that creates and hosts simple APIs. If you need API that calculates the distance from your current position to the moon, it’s definitely not the right tool. But if you just need a standard API that returns a static set of data (GET requests only), this tutorial is made for you.

We don’t need to install and configure any kind of server (and neither pay for it). Bridge takes care of the dirty work. Basically, we just have to upload the data.

Create a new API

Ok, let’s click on “sign up” and create an account (one step only). Once in the dashboard click on “create a new API”.

We will pretend that we are a museum that wants to list its works in this example.

Create easily an API for your organisation.

The API name should be general, like the name of your organisation/project/company… (the museum’s name in our case). You will be able to add spreadsheets later on.

Add a spreadsheet to our API

Let’s continue and click on “add a new spreadsheet”. We are going to upload our Excel or CSV file with the data we want to open.

We want to import this spreadsheet with a list of works. Notice the “field with no values”, the field is empty for all our works but we could have a 4th work with a value in this field.

In our example, we will import a simple spreadsheet with a list of the museum’s works. The spreadsheet name will be “works”.

Bravo

That’s it ! The Excel / CSV spreadsheet has been imported in the API and it is now open to the public. If you want to update the data later, you would just need to upload un updated Excel file.

Back on the API page of “The Peach Museum”, we will click on “see documentation”. If you are a developper, we will instantanelly have 2 thoughts :

• Cool, the doc has been automatically generated !
• Wow, it’s really nice.

If you are not a developper, just know that this documentation contains all the elements needed for others to connect to your new API.

Your API documentation is available ! Check the example responses at right, one for each endpoint.

It was fast, right ? Let’s test what we created.

Test our new REST API

The documentation shows us 2 RESTful endpoints :

• GET /works for the list of works
• GET /works/{id} to get a specific work

Let’s copy-paste the full URL to see what happens. I am using Postman but you can do it in the web browser you are using right now. As you can see, wee receive clean JSON with our data.

We receive clean JSON from the API. The “field with no values” is still here because it was in our Excel spreadsheet.

We can filter those results if we want, using one or several parameters in our HTTP request. Bridge automatically extracts parameters from the uploaded spreadsheets. Just try it yourself :

• https://bridge.buddyweb.fr/api/thepeachmuseum/works?artist=Picasso

Retreive a single item

There is no “id” property in our data. If it was the case, we could retreive a defined item by its id.

If there is no “id” column like in our case, Bridge will consider each item’s position in the array as it’s id :1 to get the first item, 2 for the second etc. Technically it’s an “index + 1” :)

• https://bridge.buddyweb.fr/api/thepeachmuseum/works/3

Conclusion

We just created an open REST API incredibly fast.

API URLs are RESTful, on “https” and deliver clean JSON based on your Excel or CSV file.

Bridge permet de créer rapidement des APIs REST pour vos mocks ou pour des projets d’Open Data

Tutoriel rapide et pour passer d’un tableau Excel à une API REST ouverte en 2 minutes avec Bridge.

Quelle genre d’API pouvons-nous créer ?

Bridge est un service gratuit qui permet de créer et d’héberger des APIs ouvertes.

Nous allons créer une API simple avec des données d’exemple. Si vous voulez une API qui calcule la distance de la terre à la lune, passez votre chemin. Par contre, si vous souhaitez une API qui permette d’accéder à une liste de données simples (requêtes GET seulement), ce tuto est fait pour vous !

Pas besoin d’installer soi-même un serveur et d’en payer les frais (en temps et en argent). Bridge est là pour réaliser le sale travail.

Créer une nouvelle API

En cliquant sur “s’inscrire”, nous créons un compte (en une étape) et arrivons sur le dashboard. Il est vide, allons donc créer une nouvelle API !

Nous allons prendre l’exemple d’un musée qui va référencer ces oeuvres.

Créez une API simplement pour votre organisation.

Le nom de l’API doit correspondre au nom de votre organisation ou projet (le musée dans notre cas). Vous pourrez ensuite ajouter plusieurs tableaux de données dans cette API.

Ajouter un tableau de données

On continue et on clique sur “ajouter un tableau”. Nous allons ici uploader le tableau Excel ou CSV avec les données à intégrer sur l’API.

Voici le tableau de la liste des oeuvres du musée. Notez le “field sans valeurs”, il est vide pour les 3 tableaux mais on pourrait avoir un 4ème tableau avec une valeur sur ce champ.

Dans cet exemple, nous allons importer un tableau des oeuvres disponibles dans notre musée d’exemple. Nous imaginons que ce musée veut rendre public et accessible la liste de ses oeuvres. Le nom du tableau sera “oeuvres”.

Bravo

Ca y est ! Le tableau a été importé dans l’API et elle est désormais ouverte au public. Pour mettre à jour les données, il vous suffira d’uploader un nouveau fichier Excel actualisé.

De retour sur la page de l’API du “Musée de la Pomme”, nous allons cliquer sur “voir la doc”. Si vous êtes développeur, instantanément, vous vous dites 2 choses :

• Cool, la documentation a été générée automatiquement !
• Cool, elle est jolie en plus.

Si vous n’êtes pas développeur, sachez que cette documentation contient tous les éléments nécessaires pour qu’on se connecte à votre nouvelle API.

La documentation de l’API a été générée automatiquement ! Vous pouvez voir à droite une example de la réponse pour chaque endpoint.

Rapide non ? Allons donc tester tout ça.

Tester notre nouvelle API REST

Sur la doc, on peut voir qu’on a 2 endpoints (très RESTful) :

• GET /oeuvres pour la liste des oeuvres
• GET /oeuvres/{id} pour une seule oeuvre

On va donc copier cette adresse pour la tester. Ici j’utilise Postman mais on peut très bien le faire depuis le navigateur que vous utilisez en ce moment même. Comme vous pouvez le voir, nous recevons du JSON avec les données envoyées.

L’API renvoie un JSON propre. Le “field sans valeurs” est également présent dans la réponse car il était dans le tableau Excel importé.

Il est également possible de filtrer ces résultats en spécifiant un ou plusieurs paramètres dans notre requête. Bridge a automatiquement généré des paramètres à partir des données fournies. On vous laisse tester par vous-même :

• https://getbridgeapp.co/api/museedelapomme/oeuvres?artiste=Picasso

Récupérer un élément unique

Il n’y a pas de propriété “id” dans les données que nous avons fourni. Si c’était le cas, nous aurions pu recevoir un élément spécifique en fournissant son id.

Néanmoins, si aucun “id” n’est spécifié, Bridge va considérer la position de l’élément dans le tableau comme “id” : 1 pour récupérer le 1er élément, 2 pour le 2ème, etc. Techniquement il s’agit de “index + 1” :)

• https://getbridgeapp.co/api/museedelapomme/oeuvres/3

Conclusion

Nous avons créé une API REST ouverte au public très rapidement. L‘API est en “https” et la réponse est en JSON.

On a tous vécu ce bug-surprise qui n’apparait qu’en production. Tout allait bien en local, puis une fois déployé, c’est le drame.

Avoir une maîtrise des environnements (local, pré-production, production) permet d’éviter 99,99%* de ces problèmes (voir la conclusion pour le petit astérisque). En plus de cela, vous allez gagner du temps et votre code sera plus solide et safe.

On fait communément la différence entre l’environnement local (ou développement, en gros: mon ordinateur) et remote (serveur distant de pré-production ou production).

On appelle production la version “live”, c’est celle qui est utilisée par vos utilisateurs et qui tourne en ce moment même. Vous êtes actuellement sur la version de production de Medium.

La pré-production est un environnement à part entière qui peut être sur le même serveur que la production ou non. Il a pour but de réaliser des tests et validations avant le déploiement en production.

Les variables d’environnement

Comme son nom l’indique les variables d’environnement dépendent de l’environnement dans lequel l’application est installée. Examples : l’URL de l’application ou de l’API, les identifiants (base de données, services tiers…), les configurations, etc.

Quel que soit votre techno, les bonnes pratiques nous poussent à réunir toutes ces variables dans un seul et même fichier.

Dotenv (.env) est un design pattern disponible sous forme de module pour quasiment tous les languages. Même le mal-aimé (ou bien-aimé) Wordpress dispose de solutions comme Bedrock qui intègrent dotenv.

Prenons l’example de l’utilisation de dotenv du framework Laravel :

APP_NAME=Laravel
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_LOG_LEVEL=debug
APP_URL=http://localhost

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

[...]

C’est simple, non ?

Notez que ce fichier s’appelle .env.example et non pas .env car le “vrai” fichier .env est personnel et privé (il ne doit jamais être commité sur git). Chaque développeur est prié de copier ce fichier, de le renommer en .env et de remplir ses propres identifiants. Rien d’autre, tout est là.

Cela permet d’améliorer la sécurité car il n’y pas d’identifiants qui se promènent en dur dans le code. Cette pratique permet aussi de faciliter la collaboration avec d’autres développeurs qui pourront faire tourner rapidement votre app.

En plus des identifiants, on peut aussi réaliser des actions différentes en fonction de l’environnement dans lequel on est.

Dans l’exemple ci-dessous, on récupère l’adresse email d’un vendeur (sales person) pour lui envoyer un email. Dans un environnement local ou de pré-production (staging), l’email ne sera pas envoyé au vrai vendeur mais sur un mail de test (le mien). Pour finir, ce mail de test est également stocké dans une variable d’environnement TEST_EMAIL, ce qui fait que les développeurs avec qui je collabore pourront le recevoir sur leur propre email :

public function getSalesPersonEmail()
{
    if (env('APP_ENV') == 'local' || env('APP_ENV') == 'staging') {
        return env('TEST_EMAIL');
    }
    return $this->sales_person_email;
}

Ce type de code doit être fréquent dans votre application. Cela va vous permettre de pouvoir utiliser l’application en profondeur sans rien changer au code.

Les task runners (Gulp, Webpack, Grunt…)

Si vous utilisez des task runners, différencier les environnements vous apporte des avantages :

• Rapidité de compilation en ne minimifiant les images et assets qu’en production
• Sécurité : ne générer des sourcemaps qu’en local
• Propreté : ne pas polluer votre code de développement avec de l’inline-css ou des scripts de web analytics par exemple

Je vais prendre Gulp comme example mais on peut le faire avec d’autres task runners. Le module gulp-util permet de faire la différence entre

gulp

et

gulp —-production

Une fois téléchargé le module, vous pouvez l’utiliser dans votre gulpfile.js. Le code ci-dessous permet de minimifier (avec uglify) en environnement de production uniquement :

var gulp = require('gulp'),
    // ajouter les autres dépendances ici
    util = require('gulp-util');

// deux points d'exclamation pour changer le undefined en false
var production = !!util.env.production;

// pour le tester vous-même
console.log(production);

gulp.task('scripts', function () {
  return gulp.src([
    // ajouter vos dépendences 
  ])
      .pipe(concat('all.js'))
      .pipe(production ? uglify() : util.noop())
      .pipe(gulp.dest('./dist/js'));
});

La virtualisation

On ne peut pas parler de différences d’environnement sans parler de virtualisation bien entendu. La virtualisation a reproduire un système sur un autre. Example : je développe mon application sous Mac mais mon serveur de production est sous Linux, je vais donc créer une machine virtuelle Linux pour mon développement.

L’objectif est simple : travailler en se rapprochant le plus possible de l’environnement de production.

Si j’utilise Apache (MAMP, WAMP et autres) en local et que mon serveur de production fonctionne avec NGINX, je ne peux pas prévoir les erreurs qui vont se produire après mon déploiement.

J’utilise Vagrant pour résoudre ce problème. Docker est un outil permettant une approche différente qui est de plus en plus adopté par les développeurs.

Attention : la virtualisation ne reproduit en aucun cas les performances d’un serveur de production. Si votre application est gourmande en ressources, il faut le tester dans un environnement similaire.

Est-ce que c’est obligatoire ?

Personnellement j’ai eu l’habitude pendant longtemps de ne pas créer d’environnement virtuel pour les “petits” projets. Ma réponse était la suivante: “Je connais mes serveurs et mon environnement local, il n’y aura pas de problème”. Ce manque de considération m’a parfois joué des tours et m’a forcé à passer beaucoup de temps sur des petites choses. Je recommande donc de le faire pour tous les projets. Gardez en tête qu’une minime différence de version de PHP ou NodeJS peut vous bloquer totalement votre application.

Conclusion

Comme vous avez pu le constater, cet article présente une vision générale et non pas détaillée des problématiques liées au changement d’environnement. Chaque technologie est différente et vous trouverez de très bons articles adaptée à votre cas en cherchant sur internet.

Maîtriser les changements d’environnement apporte de la solidité dans votre code, réduit nettement les possibilités de bugs, améliore la sécurité et la collaboration avec d’autres développeurs.

Tout cela aux prix de quelques lignes de code en plus, qui vous feront gagner bien plus de temps qu’elle n’ont prit à être écrites !

*Pourquoi éviter 99,99% des problèmes et pas 100% ? Pour cela, il faudrait un environnement parfaitement identique lors du développement et de la production, ce qui n’est pas possible dans la pratique. Mais cela relève plus du détail qu’autre chose. Allez, au travail !