GraphQL : le futur de REST ?

Attention : le contenu de cet article est plutôt technique.

Aujourd’hui : REST

À l’origine, il y avait SOAP. Une première forme de standardisation des services web utilisant XML.

Puis, avec les améliorations de Javascript, des navigateurs et des serveurs web est arrivée une nouvelle architecture : REST.

REST utilise XML mais aussi et surtout JSON. L’accès aux données est basé sur les URL. C’est standardisé et bien sécurisé sans être une usine à gaz.

Sauf qu’il y a aujourd’hui quelques limites qui commencent à être atteinte et quelques améliorations suggérées par les usages actuels des services web.

Demain : GraphQL ?

GraphQL a été présenté il y a environ 2 ans par Facebook.

En gros, il s’agit de s’appuyer sur un langage de requêtes côté client. C’est le client qui détermine son affichage et non le serveur.

Par exemple, pour aller chercher uniquement les nom, prénom, les URL des photos de l’utilisateur « john.doe » de ma base de données, je ferai une requête de type :

{
  user(username: "john.doe") {
    firstName
    lastName
    photos {
      url
    }
  }
}

Et je recevrai une réponse de type :

{
  "data": {
    "user": {
      "firstName": "John",
      "lastName": "Doe",
      "photos": [
        {
          "url": "https://..."
        },
        {
          "url": "https://..."
        },
        {
          "url": "https://..."
        }
      ]
    }
  }
}

C’est plutôt pratique, même s’il reste encore des points à éclaircir pour en faire un véritable standard.

En tout cas, avec REST, cela aurait été une horreur à intégrer !

Quel avenir pour GraphQL et REST ?

Aujourd’hui, REST est bien en place dans l’industrie et pour une bonne dizaine d’années encore.

GraphQL pourra cohabiter avec REST. Dans un premier temps sous forme d’API secondaire, puis progressivement sous forme d’API principale.

D’autant que son intégration est assez rapide et plutôt pratique côté client avec des outils comme React + Relay (Javascript), Apollo (iOS / Swift, Android / Java) et autres.

Node.js (Javascript), Ruby on Rails (Ruby) et Symfony (PHP) permettent de créer des services GraphQL côté serveur.

Qui utilise GraphQL aujourd’hui ?

Parmi les early adopters de GraphQL, nous pouvons citer :

  • Facebook
  • GitHub
  • Pinterest
  • Shopify
  • 20 minutes
  • Allociné
  • Club Med

L’avenir semble donc bien être à GraphQL 🙂

[API] Forcer les réseaux sociaux à actualiser votre contenu

Vous utilisez OpenGraph mais voilà : votre contenu a été récemment actualisé et les réseaux sociaux n’ont pas actualisé la miniature.

Voici la procédure à exécuter.

Facebook

La documentation officielle dit ceci.

Vous pouvez exécuter une requête POST sur /?id={url}&scrape=true où {url} représente l’URL canonique de votre page.

Le cache par défaut dure 30 jours.

Twitter

Pour Twitter, vous devez :

  • créer un faux tweet avec les nouvelles données, en faisant attention au raccourcisseur d’URL (bit.ly, etc) qui garde les données en cache
  • pour les images, utiliser un identifiant en paramètre de l’URL qui force à actualiser le cache (ex. http://example.com/myimage.jpg?4362984378)

En clair, c’est un peu nul.

Idéalement, il faut partager les liens avec des paramètres dans l’URL. Genre un timestamp, qui force à actualiser le cache si nécessaire.

A priori, le cache Twitter dure 7 jours maximum. Mais c’est vrai que c’est toujours pénible.

Pinterest & les autres

Pinterest utilise le même procédé et va plus loin grâce aux Rich Pins qui proposent du contenu exploitant Schema.org.

La Search API d’Apple utilise le même procédé.

Si vous pouvez utiliser des systèmes de signature unique pour vos URL, c’est donc optimal.

Mais le meilleur système est – pour l’instant – celui de Facebook.

Des petits problèmes entre CORS et CloudFront ?

Information : si vous souhaitez juste comprendre l’illustration jointe, rendez-vous directement à la fin de l’article. 😀

Si vous aussi vous avez rencontré depuis quelques mois (avril 2016 a priori) des petits problèmes entre CloudFront et les polices CSS par exemple, voici la solution.

Dans la configuration de CloudFront, section Behaviour de votre distribution, vous avez la possibilité de transférer des en-têtes en liste blanche. (Forward Headers -> Whitelist)

Dans cette liste blanche, il vous faut :

  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Origin
  • Access-Control-Max-Age
  • Origin

C’est en effet ce dernier petit en-tête qui doit être ajouté.

En gros, cela permet de forcer l’interprétation par CloudFront du « Vary: Origin » renvoyé par votre implémentation de CORS.

C’est curieux, mais c’est comme ça.

Du coup, j’ai ramé pendant quelques jours. J’espère vous éviter cette galère !

Vous souhaitez savoir qui connait vos mots de passe ?

Le titre est un peu racoleur, mais il fait suite à une expérience menée récemment par Morin Innovation.

Selon l’appareil et le réseau que vous utilisez, des informations sensibles vous concernant (mot de passe, coordonnées bancaires, coordonnées sécurité sociale, etc) peuvent être interceptées de manière manuelle ou automatique.

La démarche précise ne va pas être évoqué ici : inutile de donner aux hackers en herbe les techniques de piratage qu’ils pourraient eux-même utiliser.

Première faille : ne pas mettre à jour

Vous utilisez Windows XP « parce que c’était mieux avant » ? Sachez que Windows XP ne reçoit plus de mises à jour. Les nouvelles failles trouvées ne sont donc plus corrigées. C’est un terrain de jeu idéal pour récupérer vos informations personnelles.

Il en va de même pour les anciennes versions de OS X, le système du Mac, dont la mise à jour est gratuite.

Et c’est également la même chose sur les smartphones.

Bien choisir son smartphone

Les smartphones de plus de 4 ans représentant environ 5 % des utilisateurs, et tous les 2 ans en moyenne.

Si votre iPhone a plus de 5 ans, il ne reçoit plus les mises à jour du système iOS. Les iPhone 4S et plus récent ont toujours droit à leur mise à jour. Et sont donc protégés au maximum possible.

Si vous vous orientez vers Android, vous avez le choix entre plusieurs milliers d’appareils. Choisissez plutôt du haut de gamme. Le Galaxy S2 peut être mis à jour avec la dernière version d’Android en passant par l’outil CyanogenMod (si vous êtes un peu geek, vous devriez vous en sortir sans soucis). Les modèles de moyenne gamme ont des mises à jour pendant environ 1 à 2 ans. Les modèles d’entrée de gamme sont bien souvent déjà obsolètes à la sortie.

Pour ce qui est de Windows Phone, environ 80 % des appareils reçoivent des mises à jour récentes, dont la dernière version Windows 10. Les versions Windows 8.1 reçoivent malgré tout des mises à jour de sécurité. Ce qui est plutôt intéressant.

L’étude de la sécurité s’est limitée aux mises à jour concernant Windows Phone tant la part de marché reste – encore – mince.

Le navigateur web

Utilisateurs d’Internet Explorer : toutes les versions inférieures à la version 11 sont obsolètes.

Les autres navigateurs sont mis à jour automatiquement et de manière régulière.

« HTTPS » ne signifie pas toujours « sécurité absolue »

Quand vous vous connectez sur un site en HTTPS, la connexion est sécurisée. Les données qui transitent entre votre ordinateur / smartphone et le site ne sont pas visibles.

Une personne (ou un robot) malintentionnée qui « observerait » la connexion ne verrait passer que des chiffres et lettres sans aucune cohérence.

On distingue les connexion HTTPS par un petit cadenas dans l’adresse du site (la barre en haut), souvent en vert, à gauche ou à droite de l’adresse.

HTTPS

Cependant, les certificats sont parfois obsolètes. En conséquence de quoi un pirate peut interférer entre vous et le site web. En gros, il se fera passer pour le site web vis à vis de vous. Et il se fera passer pour vous vis à vis du site web. Ainsi, il pourra récupérer les informations déchiffrées.

Les techniques modernes et les navigateurs modernes permettent justement d’éviter ça.

Dans Chrome, vous pouvez distinguer un site véritablement sécurisé :

Morin_Innovation

Et un site à la sécurité douteuse :

RSI_–_Authentification_et_Developer_Tools_-_http___localhost_8080_rwd_maiffr_dist_www_transverse_services_simulateur_html

Attention : de nombreuses banques et autres organismes « de confiance » utilisent des procédés obsolètes en matière de sécurité.

Comment aller sur Internet en toute sécurité ?

Il y a 2-3 règles simples pour être en sécurité sur Internet.

Disposer d’un appareil à jour

En allumant votre PC / Mac / Smartphone / What else vérifiez vos mises à jour.

C’est un premier niveau de protection.

Utiliser votre propre ordinateur et votre propre réseau

Les ordinateurs des lieux publics sont des cibles faciles pour les pirates. Ils peuvent souvent se mettre en intermédiaire : l’accès aux connecteurs réseaux n’est pas forcément sécurisé, ce qui permet d’intercepter les communications si on maîtrise la chose.

Et les ordinateurs des lieux publics sont rarement à jour.

Connectez-vous soit chez vous, soit chez un proche. Eventuellement sur une box de votre fournisseur d’accès ou un procédé similaire reconnu.

A défaut, utilisez votre connexion 3G/4G.

Les applications mobiles (ça fait mal…)

L’étude de la sécurité qui a été faite a été réalisée sur des applications mobiles iOS et Android.

La responsabilité de la sécurité dépend à la fois du système d’exploitation et du concepteur de l’application.

La faille courante sur mobile

La faille la plus courante sur mobile n’est pas d’essayer de casser la sécurité de la connexion à un service, mais de baisser le niveau de sécurité pour le rendre obsolète et ainsi récupérer les informations.

En gros, en utilisant un appareil Android « rooté » (ou non mis à jour) ou un iPhone « jailbreaké », on peut faire croire au site web que nous n’avons pas la capacité de mettre en place le niveau de sécurité maximum. On demande donc à communiquer au travers d’une connexion sécurisée obsolète.

Et là, le pirate peut se mettre entre les deux.

IOS : sécurisé par défaut

Les applications iOS sont sécurisées par défaut. Elles sont compilées, chiffrées et le système bloque beaucoup d’accès de sorte à protéger vos données.

Si vous êtes encore sur iOS 8 (il en reste quelques uns), passez rapidement à iOS 9. La dernière mise à jour permet de forcer la sécurité des connexions des applications mobiles grâce à une technologie appelée ATS. Cependant, certains développeurs désactive cette fonctionnalité par paresse de la mise à jour.

Pour le reste, on peut réaliser des applications ne contenant aucun identifiant dans le code (pour se connecter au serveur) et donc totalement sécurisées.

On peut éventuellement renforcer la sécurité avec des techniques complémentaires, au cas où iOS aurait une faille non connue permettant de casser les mécanismes de sécurité en place. Mais, si c’était le cas, le FBI n’aurait pas fait de procès à Apple pour accéder aux informations d’un iPhone.

Sauf si vous ne mettez pas à jour votre iPhone, et si le développeur ne se donne pas la peine de respecter les règles de sécurité par défaut ou n’utilise pas les outils à disposition, votre iPhone est globalement très bien sécurisé.

Ce qui est normal : après tout, vous payez le prix fort – entre autre – pour que vos données soient en sécurité.

Android : sic!

Avant d’être accusé de quoi que ce soit, je tiens à préciser que j’ai lancé plusieurs appels sur la toile ces derniers jours et ils sont restés sans réponse. Si vous avez des réponses à me donner, n’hésitez pas, je complèterai l’article.

J’ai testé plusieurs applications Android, dont celles d’organisations qui devraient protéger la sécurité de leurs utilisateurs. Je ne les citerai pas, par bienveillance et parce que l’erreur est humaine. Et, de toutes manières, il est très difficile de faire mieux que pas terrible avec Android. Je vais expliquer précisément pourquoi.

En premier lieu, j’ai pu découvrir le code source de toutes les applications téléchargées. Et donc récupérer les identifiants de connexion au service web permettant de gérer les données.

J’ai même eu accès à un service d’envoi automatique de SMS. Bref, ça craint. Imaginez que je sois un pervers un peu taré et que j’utilise ce service pour envoyer des SMS salaces : qui se ferait accuser ?

En plus, une faille Android anéantit la sécurité mise en place sur les autres appareils.

Certaines techniques permettent de « masquer » le code source, dont l’obfuscation, qui consiste à complexifier artificiellement le code. Sur une dizaine d’apps, une seule était réellement compliquée à lire. Pour les autres, on s’y retrouvait tout de même facilement. Donc, ça craint. Y compris pour le développeur qui n’y peut rien.

On pourrait utiliser, comme avec iOS, des services Google qui permettraient de récupérer les identifiants sensibles via une connexion établie par l’application et exploitable uniquement par l’application. Ça n’existe pas. Et, même si ça arrivait dans la prochaine version, ce ne serait pas compatible avec la majorité des appareils Android avant plusieurs années.

Bref : on est condamné à laisser en clair les informations.

Si toutefois on utilise une bonne technique pour bien cacher les identifiants de connexion au service web, il n’y a malheureusement aucune technique permettant de forcer la protection de la connexion (aucun équivalent à ATS) : en conséquence, on doit utiliser des techniques particulières pour s’assurer qu’il n’y a personne entre notre serveur et notre application.

J’en ai déjà perdu la plupart d’entre vous : c’est normal, ce domaine qu’est la sécurité est très spécifique.

Pour les développeurs, c’est pareil : la plupart ne connaisse pas tellement la sécurité. Vu que le système n’est pas suffisamment sécurisé par défaut, l’application n’est pas sécurisée. Et, encore une fois, inutile de leur jeter la pierre : la sécurité est un domaine très spécifique et doit avant tout être géré par le système en lui-même.

Je ne dis pas qu’Android n’est pas sécurisé : il y a tout pour bien faire. C’est juste que dans plus de 90 % des cas ce n’est pas sécurisé. Et, malheureusement, on ne peut pas y faire grand-chose.

Faut-il responsabiliser l’utilisateur ? Faut-il responsabiliser le développeur d’application ? Faut-il responsabiliser les concepteurs d’Android ?

Ça ne vous a pas coûté cher : vous savez maintenant pourquoi.

Si un jour votre compte est débité ou votre identité falsifiée, vous saurez que vous n’avez pas eu de chance à la roulette russe. Mais vous saurez surtout d’où peut venir le problème.

« C’est malin, j’ai les boules : t’as pas une solution quand même ? »

Hormis mettre votre Android à la poubelle et acheter un Windows Phone ou un iPhone, vous pouvez tout de même protéger un peu plus vos informations personnelles en évitant que vos données soient volées par n’importe qui.

Cette solution est très utile et doit être appliquée quelle que soit votre smartphone ou ordinateur.

Vous savez maintenant qu’un mot de passe de connexion n’est absolument pas une sécurité : n’importe quel pingouin mal luné peut le récupérer en allant voir 3 tutoriels sur le piratage.

Pour autant, il existe une solution : l’identification à plusieurs facteurs.

Le premier facteur est le mot de passe, totalement « has been » aussi compliqué soit-il.

Le second facteur est l’envoi d’un SMS ou l’envoi d’un code dans une application spécifique.

Et là, c’est malin. Car, pour pouvoir accéder à votre compte, le petit malin devra posséder à la fois votre mot de passe (facile) ET votre téléphone sur lequel sera envoyé un SMS ou un code dans une app. Et, si votre smartphone est bien protégé (mot de passe ou mieux : TouchID), le petit malin pourra aller se brosser.

Si vous souhaitez en savoir plus, j’ai rédigé un petit article à ce sujet.

Le plus triste est que – malheureusement – les banques, assurances et autres établissements ayant à leur disposition des informations sensibles vous concernant utilisent rarement ce système d’identification. (par contre, Google, Facebook, Apple, Microsoft et autres le proposent)

Sur ce, dormez tranquilles… On vous surveille ! (rire sardonique)

Je rigole. 🙂 Mais faites attention quand même.

 

Quoi de neuf chez Morin Innovation ?

Après avoir fait des blagues potaches pour le 1er avril, il est toujours intéressant de connaître la – véritable – actualité de l’entreprise.

Et bien, de nombreux projets en cours et à venir. Notamment grâce à Hopwork et aux rencontres Niort Numeric.

Du service web sécurisé et performant

Dans le cadre d’un projet de startup, j’ai mis en place un service web garantissant une sécurité optimale. Pas parfaite, je n’ai pas cette prétention. Mais répondant à de hauts critères en matière de sécurité et de performances.

Ruby on Rails : on passe la 5ème

Le service web étant mis en production cet été, le développement a été réalisé avec Ruby on Rails 5, la dernière mouture du framework web, actuellement dans ses dernières versions beta.

Comme toujours, l’outil tient ses promesses et propose un socle solide pour le développement en mode agile.

OAuth2 : authentification sécurisée

Le service web étant destiné à une application mobile, l’accès à ce dernier doit être sécurisé tout en conservant une certaine souplesse et de bonnes performances.

Le protocole OAuth2 offre cette possibilité tout en restant sur une architecture standard.

Ajoutez à cela une protection SSL solide, le bon suivi des règles de sécurité OWASP et le tour est joué.

Authenticité des utilisateurs

Quand on échange des données confidentielles, on aime que les personnes sur le réseau soient des personnes de confiance.

La mise en place d’une validation par email et/ou SMS en amont de l’inscription permet de s’assurer – dans une certaine mesure – que les utilisateurs de la plateforme sont de vraies personnes.

Authentification à plusieurs facteurs

Un simple mot de passe peut parfois suffire.

Pour un service web nécessitant un certain niveau de sécurité et de confidentialité, ce n’est pas suffisant.

L’utilisateur à le choix d’activer l’authentification à plusieurs facteurs.

S’il l’active, il reçoit un SMS permettant de valider son identité lors de la première connexion au service sur un même appareil.

Liens courts

Les liens courts permettent de faciliter l’échange de liens : un lien court est facile à recopier et très efficace en QRCode.

En plus, dans un SMS, ça prend moins de place.

Une app iOS moderne sécurisée

IOS offre de nombreux mécanismes de sécurité. Encore faut-il savoir les utiliser à bon escient.

Deeplinking et liens universels

Le deeplinking permet d’ouvrir une app via un format de lien spécifique.

Le lien universel – introduit par iOS 9 – permet d’ouvrir directement une app au bon endroit grâce à un lien vers un site.

Ce procédé permet de renforcer la qualité de l’expérience utilisateur tout en conservant un niveau de sécurité élevé.

Connexion sécurisée aux services web

L’application actuelle est – comme la plupart des applications – connectée à un service web.

Même si la connexion est sécurisée, les identifiants permettant de se connecter aux services web avaient – jusqu’à récemment encore – la fâcheuse habitude d’être intégrés au code source de l’application. Et donc potentiellement récupérables en cassant la sécurité l’application.

Depuis iOS 8, on peut s’affranchir du stockage de ces précieuses données. L’accès au code source en lui-même ne permet pas le piratage car il ne contient pas les identifiants de connexion. (si vous voulez savoir comment je fais, n’hésitez pas à me contacter 🙂 )

Stockage sécurisé des données

IOS propose des mécanismes permettant de sécuriser le stockage des données : autant les exploiter. Toutes les données personnelles de l’app sont chiffrées par le système.

La sécurité des données confidentielles est une question de confiance vis à vis des utilisateurs. Il est essentiel de la garantir.

Accès sécurisé au contenu

Souvent, la sécurité concernant les images et autres contenus stockés sur des CDN se résume à « cacher » l’URL de la ressource en espérant que le contenu ne soit pas vu.

Le système mis en place nécessite l’utilisation d’une signature générée grâce à un identifiant et une clé pouvant eux-même changer. En clair, on ne tombe pas dessus par hasard.

Les performances et l’expérience utilisateur

Ceux-ci sont également essentiels, mais restent plus « classiques ».

On utilise les dernières techniques iOS 8 et iOS 9, avec une bonne dose de Swift, un usage intelligent des différents niveaux d’exécution des tâches et le tour est joué.

To be continued…

Le projet est en cours. D’autres projets vont arriver.

Et, cet été, ce sera – normalement – l’arrivé du successeur de iOS 9 : tout un programme !

À suivre…

L’évolution du web : 2015-2016 (statistiques et prospective)

Il est toujours bon d’avoir en tête les statistiques d’usage des différents navigateurs web afin d’exploiter au mieux les technologies disponibles.

Cette synthèse s’appuie sur un échantillon de plusieurs dizaines de milliers utilisateurs sur le 4ème trimestre 2015.

Le site en question étant responsive, les plateformes ciblées sont aussi bien ordinateur que tablette ou mobile.

Le site en question est destiné à un public français.

ORdinateur, tablette, mobile ?

69 % des utilisateurs sont sur un ordinateur de bureau, 17,5 % sur mobile et 13,5 % sur tablette.

Ignorez le mobile et la tablette : vous perdrez 1/3 des utilisateurs. Sans parler des conséquences en termes de référencement.

Les navigateurs web

Ces statistiques s’appuient sur l’ensemble des navigateurs, toute plateforme confondue.

Chrome reste le favori, avec 32,8 % des parts de marché.

Il est suivi par Firefox, à 23,4 %. Puis Safari, notamment grâce à sa version mobile, qui est à 19,75 % des parts. Internet Explorer est – toutes versions confondues – à 16,14 %. Suivi par son successeur Edge, navigateur par défaut de Windows 10, qui s’octroie seulement 3,6 % du marché. Le reste (~ 5 %) est réparti entre Opera, quelques navigateurs Android natifs et autres appareils spécifiques.

Le cas Internet Explorer

Après la déclaration officielle de désuétude de Windows XP (et donc Internet Explorer 8) depuis le 8 avril 2014, Microsoft a récemment renforcé sa démarche de modernisation en n’assurant plus le support des versions inférieures à la version 11 de son navigateur historique Internet Explorer à partir du 12 janvier 2016.

La réaction des utilisateurs ne s’est pas faite attendre.

Parmi l’ensemble des utilisateurs d’Internet Explorer, seuls 16,5 % utilisent une version obsolète. Ramené à l’ensemble des navigateurs, cela représente seulement 2,7 % des utilisateurs.

Côté mobile et tablette

Les 3 systèmes les plus populaires sont iOS, Android et Windows.

Si iOS (47,2 %) et Android (47 %) sont au coude à coude, Windows reste en retrait avec seulement 5 % du marché. Blackberry et les autres ne sont plus représentatifs.

iOS

Sur l’ensemble des versions de iOS, les 3 dernières sont les plus représentées.

iOS 9 en représente 66,3 %, iOS 8 est à 16,9 % et iOS 7 à 12,3 %. Les 4,5 % restants sont partagés par iOS 6 et les versions inférieures.

En visant iOS 7 et supérieurs, on atteint 95,5 % des utilisateurs iOS.

Android

Pour Android, les choses sont un peu différentes.

La dernière version du système (6) est peu représentée à 1,2 % des parts. L’avant-dernière version (5) commence à émerger à 37 %. La version la plus représentée est la version 4 à 60 % des installations.

Sur cette version 4, les différentes déclinaisons se partagent ainsi les parts de marché du système : la 4.0 n’est pas très représentative (2 %), la 4.1 est plus présente (12 %), la version 4.2 est à 7 %, la 4.3 à 4 % et la 4.4 à 35 %.

En conclusion, en visant Android 4.1 et supérieurs, on peut atteindre 95 % des utilisateurs Android.

Les technologies de 2016

En conclusion, les navigateurs les plus utilisés sont ceux de Android 4.1 et iOS 7 ainsi que les navigateurs de type Internet Explorer 11 et supérieurs.

HTML5

Voici une synthèse des possibilités des différents navigateurs : https://html5test.com/compare/browser/chrome-44/firefox-40/ie-11/android-4.0/ios-7.0.html .

Le HTML5 est donc particulièrement bien supporté. Notamment tout ce qui concerne :

  • la gélocalisation,
  • la vidéo (H264 de préférence),
  • l’audio (MP3 de préférence),
  • les canvas 2D,
  • le PNG pour les images avec transparence,
  • le format SVG pour les visuels vectoriels,
  • le WebGL sur ordinateurs de bureau,
  • l’envoi de fichiers côté Javascript,
  • la communication via WebSocket,
  • le copier-coller dans les navigateurs de bureau,
  • CORS,
  • le cache dans les applications,
  • le stockage local de données par système de « clé-valeur »,
  • les bases de données locales sur ordinateurs de bureau,
  • la gestion des données binaires et des fichiers.

CSS3

Le support des composants HTML est une chose. Le support des éléments de style en est une autre.

Là-dessus, les choses se présentent encore mieux. On pourra maintenant utiliser les propriétés suivantes :

  • align-*
  • border-image-*
  • flex-*
  • justify-content
  • order
  • transform-style
  • etc.

Javascript

La technologie Javascript a déjà connu une première révolution avec son arrivée sur les serveurs grâce à Node et Express.

Les performances du Javascript sont aujourd’hui telles qu’il faut maintenant en combler le principale défaut : la standardisation et la fiabilité.

Le travail est en cours grâce aux standards ECMAScript et TypeScript, qui permettent une évolution en douceur.

A cela s’ajoutent des technologies de plus en plus performantes, telles que asm.js qui permet d’obtenir des performances impressionnantes.

Cette technologie évolue très vite, et cette évolution pourrait bien s’accélérer encore en 2016. Au sein des navigateurs web comme ailleurs.

Impact sur les frameworks

Chaque frameworks va pouvoir profiter d’un allègement. En particulier en se déchargeant de bibliothèques externes – telles que jQuery – dont l’intérêt pour le framework n’est plus justifié. Mais également en allégeant le code par la suppression du code supplémentaire lié aux navigateurs obsolètes.

De plus, de nombreux frameworks se standardisent en utilisant des langages tels que TypeScript qui permettent d’avoir un code Javascript plus fiable et plus performant.

Parmi ceux qui en tirent les bénéfices des nouveaux navigateurs, on peut citer :

  • Angular 2.0, standardisé grâce au TypeScript, qui lui permet une compatibilité IE9 et supérieurs, IE11 et supérieurs très rapidement, puis Edge et autres navigateurs Evergreen à terme,
  • Bootstrap 4, compatible IE9 et supérieurs, standardisé grâce à ECMAScript 6 (similaire dans les grandes lignes à TypeScript)
  • jQuery 3, compatible IE9 et supérieurs, pourra obtenir un allègement important, bien que son usage devienne de moins en moins justifié, si ce n’est pour les animations.

Les tendances

Avec des moteurs Javascript performants et une compatibilité étendue, il est clair que la face du web va encore changer.

Les serveurs web vont pouvoir se libérer d’une partie de leurs tâches en profitant des capacités des navigateurs web.

Les graphistes et autres concepteurs d’interface vont enfin pouvoir montrer au monde le vrai visage de leurs créations grâce au SVG qui leur permet d’afficher des contenus de qualité, sans pixels grossiers, tout en permettant une légèreté optimale.

La 3D sur le web va enfin pouvoir devenir une réalité, grâce au support du WebGL. Une technologie également supportée par les principaux moteurs de jeu vidéo, dont le fameux Unity.

MEAN : le futur de LAMP ?

Le développement web a régulièrement évolué depuis quelques années. Les standards évoluent et une nouvelle révolution est en marche.

Les années 95-2000 : LAMP

LAMP réunit plusieurs technologies nées dans les années 95 :

  • Linux qui fait référence au système d’exploitation GNU/Linux
  • Apache : le serveur web
  • MySQL : la base de données relationnelle
  • PHP : le langage de programmation.

Ces 4 outils étaient à l’époque une petite révolution dans le monde du web.

Grâce à des outils gratuits (et libres), tout le monde pouvait créer une site web dynamique. C’est à dire un site dont le code HTML était généré par un script et dont les données étaient issu d’une base de données.

A cette époque, les machines virtuelles n’existaient pas encore. Du moins, pas comme on les connait aujourd’hui.

On était déjà contents d’avoir un environnement de programmation relativement rapide et facile à appréhender.

Côté client (ce qui est vu par le navigateur web), on faisait en sorte de structurer le code HTML, utiliser à fond le CSS et éviter au maximum le javascript qui était alors un langage très lent à l’exécution. En plus, il fallait faire attention à la compatibilité avec Internet Explorer, qui prenait certaines libertés.

MEAN : une approche nouvelle

Fin 2008, le web a connu un tournant majeur avec l’arrivée du navigateur web Chrome de Google et en particulier son moteur Javascript V8 qui était déjà relativement performant.

En quelques années, le Javascript est passé d’un langage très lent à l’un des plus rapides au monde. Une véritable révolution qui allait changer les choses.

En parallèle, les différents navigateurs se sont standardisés. Internet Explorer a bien évolué – même s’il est devenu obsolète avec l’arrivée de son successeur Edge.

Tous les navigateurs web ont commencé à avoir des performances très correctes, y compris les navigateurs mobiles.

Le Javascript s’est standardisé (ECMAScript / TypeScript / AtScript / Babel / Dart) et celui qui se distingue est TypeScript. Notamment grâce à son support par Microsoft et son intégration dans Angular 2 (et autres).

Tout ceci est représenté par l’ensemble MEAN (MongoDB Express Angular Node).

Node

Node est une plateforme logicielle utilisant le moteur Javascript V8 de Google. En gros, grâce à node, on peut exécuter du Javascript. Et, cerise sur le gâteau, Node intègre les capacités d’un serveur web rudimentaire.

L’avantage est qu’un serveur web très performant et utilisant peut de ressources peut être monté grâce à quelques lignes de code.

Un atout idéal à l’ère de la scalabilité, des technologies IoT et autres solutions utilisant des ressources minimales.

Angular

Angular : une première révolution apportée par le Javascript.

Dans sa version 1, Angular propose une architecture MVC (modèle vue contrôleur) côté client. En clair, le serveur web ne charge qu’une fois du HTML. Puis c’est le Javascript qui modifie la page pour charger à la volée le contenu. La charge côté serveur est donc amoindrie ce qui améliore les performances globales en laissant le navigateur faire le job.

En gros, Angular 1 a apporté les premières applications web clientes qui se détachent du serveur.

Dans sa version 2 (en version développement), qui est une réécriture complète en se basant sur l’expérience de Angular 1, on va encore plus loin.

Déjà, la standardisation est à l’ordre du jour avec l’utilisation de TypeScript. TypeScript permet d’utiliser un javascript « avancé » qui est compilé pour être compatible avec la majorité des navigateurs.

Egalement, l’approche MVC devient une approche MV, orientée composants. (à l’instar des Web Components)

Plus besoin de JQLite (JQuery allégé) : les navigateurs modernes intègrent la majorité des concepts apportés par cette version allégée de JQuery.

Pour la version 2, il va falloir attendre un peu car elle est encore en version Alpha et risque de passer en Beta uniquement début 2016. Mais c’est à surveiller quand même. En attendant, Angular 1 fait bien le job.

Ce qu’il faut retenir de Angular, c’est que le navigateur devient une puissance de calcul au coeur de la plateforme web tout en ayant des capacités de travail hors ligne et un détachement de l’aspect serveur, qui devient adapté à de multiples usages (services web).

MongoDB et le NoSQL

Le NoSQL (Not only SQL) est une approche récente qui veut que les bases de données relationnelles ne soient pas forcément indispensables pour le web et le Big Data. D’autant que l’idée est généralement de traiter de grandes quantités de données.

Le SQL était assez lourd à appréhender. Le NoSQL est certes moins structuré, mais bien plus performant sur la recherche dans de gros volumes de données et surtout plus souple.

C’est idéal pour des recherches utilisant la géolocalisation par exemple. Et bien d’autres usages que l’on retrouve dans les services web justement.

MongoDB a une force : V8, le fameux moteur javascript de Google, qui lui permet d’être performant tout en utilisant un langage connu de tous. Non seulement les données extraites sont directement exploitables en Javascript sans transformation pour dire. MongoDB stocke les données en BSON (Binary JSON). Ces données sont facilement transformable en JSON (JavaScript Object Notation) par nature. Le JSON est efficacement compressé grâce à l’algorithme GZip utilisé par les serveurs web. Et, bien entendu, les données JSON peuvent être directement exploitées par le Javascript côté client, à savoir par le navigateur web.

De plus, afin d’obtenir de meilleures performances, certaines fonctions Javascript peuvent être pré-compilées directement dans MongoDB.

Express

Node est puissant mais limité en termes de fonctionnalités.

Express est un framework qui apporte un ensemble d’outils permettant de concevoir une solution web structurée exploitant pleinement les performances et la souplesse de Node.

Seul, le framework Express reste relativement simpliste, ce qui peut être problématique lorsque l’on recherche une solution professionnelle efficace.

Pour cela, le framework LoopBack, construit au dessus du framework Express, permet d’apporter des services complémentaires. Il intègre aisément les API REST, la sécurité et plein d’autres fonctionnalités. Avec un support professionnel payant de qualité.

D’ailleurs, la société à l’origine de LoopBack a récemment été rachetée par IBM, ce qui est une bonne garantie pour l’avenir.

Faut-il abandonner tout le reste ?

si vous utilisez un bon framework (Ruby on Rails, Django, Symfony, Play) et que vous êtes content, ne changez pas tout. N’y perdez pas en productivité.

Pour ma part, j’utilise ces technologies sur des projets de taille modeste ou pour des usages ciblés. Je reste globalement fidèle à Ruby on Rails (RoR) qui reste à ce jour plus productif et plus fiable sur les gros projets. Mais la solution MEAN atténue chaque jour cette limite.

Ils m’arrivent également d’en faire un usage ponctuel, là où RoR a ses limites. Par exemple sur tout ce qui est temps réel via les WebSockets. Ou bien pour les sites statiques, où les enjeux sont moindres et où on n’a pas besoin de sortir l’artillerie lourde.

Ceci étant, pour un débutant, le gros avantage est qu’il peut tout faire avec un seul langage de programmation. Un atout non négligeable.

Les technologies autour de Node sont de plus en plus populaires et son adoption récente par la plateforme de blog WordPress au détriment du PHP en est un indicateur significatif.

Retour vers le futur… du web

Un petit rafraîchissement de mémoire ne fait jamais de mal.

Dans cet article, nous allons suivre toute l’évolution de l’hébergement. L’idée est de comprendre ce qui a construit le web d’aujourd’hui et ce qui construira le web de demain.

Ce document reste une vulgarisation de l’histoire. Google vous aidera à trouver les éléments précis, mais l’idée est là.

En avant pour un fabuleux voyage dans le temps !

L’an zéro du net

Au début, il y avait juste des ordinateurs qui voulaient communiquer à longue distance. Avant même d’avoir défini un protocole.

1969 : ARPANET

Avant internet et le web, il y avait déjà un premier réseau inter-connecté. L’idée était de connecter des machines entre elles en envoyant des paquets de données. Le 20 septembre 1969, ce réseau fut enfin fonctionnel. Le projet était alors porté par les militaires et les universitaires.

En 1974, le protocole TCP/IP (Transmission Control Protocol / Internet Protocol) est développé afin de standardiser les communications. Il sera adopté en 1983 par ARPANET.

Il n’y avait que 23 noeuds de communication en 1971. En 1984, il y en avait déjà plus de 4 millions !

1973 : Internet est né

Même si le terme Internet est déjà utilisé en 1972, il est officialisé à partir de 1973.

Il regroupe ARPANET ainsi que différents autres réseaux.

A l’origine, Internet permettait d’échanger des messages et des fichiers. Mais ça, c’était avant l’arrivée du web

1990 : émergence du Web

Au début des années 90 est arrivé le format HTML, permettant de rédiger du contenu interactif : un lien permet d’aller d’un document à un autre. Le World Wide Web (www) est né.

Et, pour faire communiquer ces pages entre elles, un protocole spécifique est également né : le HTTP (HyperText Transfer Protocol).

Sans le savoir, le premier service web est né : la consultation de pages web.

Le web de la génération 1.0

Dans les années 90, le web est donc rudimentaire. L’hébergement qui va avec l’est également.

Service minimal

À cette époque, les ordinateurs n’étaient pas performants. Les connexions internet étaient encore assez lentes. Les pré-requis étaient donc à hauteur du besoin.

Hébergement minimal

L’hébergement était très simple à l’époque. Un serveur physique (un ordinateur) fournissait des fichiers HTML, des images et même parfois du son.

En général, on envoyait le tout au travers du protocole FTP (File Transfer Protocol).

Un contenu souvent statique

Les technologies permettant de générer du contenu dynamiquement émergeaient à peine. Généralement, un site était juste un ensemble de page web entreposées et liées entre elles.

GNU/Linux et la scène underground

À cette époque, Microsoft et Apple se partageaient le monde. UNIX était présent, mais à un prix prohibitif. Le projet GNU visant à concevoir un système UNIX libre peinait à émerger.

Cependant, en 1991, le jeune Linus Torvald avait créé un noyau (lien entre le logiciel et le matériel) permettant d’améliorer un système d’exploitation de l’époque, Minix, reposant sur UNIX.

Comme son noyau n’est pas adopté par Minix, il décide de le distribuer sur le réseau Usenet, qui est l’un des moyens de communication web de l’époque. Son noyau – Linux – est alors adopté et amélioré par la communauté. Puis il est greffé au projet GNU, qui a tout sauf le noyau. GNU/Linux est né.

En 1993 naquit le projet Debian, qui a permis l’émergence de GNU/Linux en qualité de serveur sur Internet.

La sécurité

En 1995 est arrivé le protocole SSH, permettant de chiffrer les communications. En parallèle, le protocole SFTP est né en apportant la sécurité au protocole FTP de l’époque.

Egalement, étant donné que plusieurs utilisateurs pouvaient se partager un serveur, il fallait éviter que l’un puisse aller voir ce qui se passait chez l’autre. Pour cela, on utilisait « chroot » qui permettait de limiter la visibilité d’un utilisateur.

1995 : l’arrivée du web dynamique

À partir de 1995, la révolution du web est entrée dans nos foyers et nos entreprises.

Nous sommes devenus des consommateurs de contenu. Et c’est à cette époque qu’émergea le web dynamique.

Que l’on soit plutôt CGI, plutôt Python, Perl, PHP, ASP, Java ou bien Ruby, un seul mot d’ordre : les scripts devaient générer à la volée du HTML.

En d’autres termes, on ne faisait plus appel à des pages HTML qui affichaient du contenu HTML : on faisait appel à des scripts qui affichaient du contenu HTML.

2000-2005 : l’émergence du web dynamique

Malgré la fameuse bulle de l’Internet à la fin des années 90, le web a continué sa fulgurante croissance au début des années 2000.

2002 : Xen révolutionne la virtualisation

A cette époque, la virtualisation se résumait à simuler un environnement matériel dans un système d’exploitation. En clair, s’était lent et lourd à gérer.

C’est alors qu’est apparu le projet Xen : un système pouvait être virtualisé en utilisant directement les ressources du noyau. C’est là que tout a changé : en utilisant directement les ressources matérielles, un ordinateur pouvait faire fonctionner en parallèle 3 systèmes d’exploitation sans subir de contraintes énormes en termes de performances.

Et tout à changer en matière d’hébergement. Un ordinateur pouvait héberger 3 serveurs, un serveur pouvait migrer en temps réel d’un ordinateur à l’autre sans être arrêté.

La paravirtualisation est née. Et elle a depuis fait beaucoup de chemin.

2004 : les réseaux sociaux

L’interaction entre les personnes au travers d’Internet existait déjà depuis un certain temps.

La simplicité nécessaire est alors née de l’idée de passer par le web pour communiquer. Les réseaux sociaux sont nés, notamment Facebook dont la première version est sortie en 2004.

Et ils connaîtront un essor énorme, révolutionnant le web.

2005 : le web 2.0 et les services web

Petit à petit, les performances des navigateurs web se sont améliorées. Et notamment le fameux langage Javascript qui est passé progressivement de très lent à correct pour faire partie aujourd’hui des plus rapides.

Le web 2.0

Derrière ce terme marketing se trouve une révolution des usages du web : les utilisateurs interagissent sur le contenu. Dorénavant, une page web peut en générer une autre (principe du blog), on peut gérer une boutique en ligne, on peut partager des photos.

Le tout à partir d’une simple page web, contenant du HTML, du Javascript et du CSS pour la mise en forme.

Les services web

Le web 2.0 a apporté de nouveaux usages. Le contenu dynamique nécessite de nouvelles technologies.

C’est l’émergence du format XML, qui permet de représenter des données dans un format balisé. Son successeur sera par la suite JSON, plus performant en matière de compression, de compréhension et d’analyse.

Les services web SOAP et REST sont apparus, permettant de tout connecter au web et ouvrant cette interactivité à de nouveaux horizons.

2006 : le cloud

C’est Amazon qui fut l’un des pionniers du marché, avec ses fameux Amazon Web Services (AWS).

L’idée est simple : vous ouvrez un compte AWS et vous utilisez des services à disposition. Tout est virtualisé, vous ne payez que ce que vous consommez.

Les machines virtuelles proposées sont extensibles, sauvegardables, transférables.

Les données sont stockées sans limite.

C’est une véritable révolution dans le monde de l’informatique. Tout devient possible.

2007 : le web sort de l’ordinateur

Avec la démocratisation des smartphones (Nokia puis Apple, suivis par Google et Microsoft), le web n’est plus rattaché au navigateur de l’ordinateur.

Les applications mobiles sont interconnectées avec des services web. On peut prendre une photo depuis une application pour qu’elle s’affiche sur un site web. Et le tout est hébergé chez Amazon. C’est l’histoire d’Instagram.

Les réseaux sociaux sont connectés. Tout émerge.

2010-2015 : l’émergence de nouveaux besoins

Fin 2008, le monde a connu une crise sans pareil.

Le web s’est développé au travers des smartphones. Les réseaux sociaux sont devenus de plus en plus présents.

Des services professionnels se sont développés. Le web est devenu une source d’opportunité de développement pour de nombreuses structures.

Le cloud est rentré dans les moeurs et s’est banalisé.

Les objets connectés ont fait leur apparition.

IaaS, PaaS, Saas

Grâce au cloud, de nouveaux services sont apparus.

Les IaaS (Infrastructure as a Service) permettent de disposer d’un serveur virtualisé instantanément. Et ces serveurs peuvent être démarrés à la demande, pour gérer par exemple une affluence exceptionnelle ponctuelle sans avoir à débourser une fortune en amont.

Les PaaS (Platform as a Service) permettent d’aller encore plus loin. Les serveurs virtualisés sont prêts à l’emploi : sécurisés, optimisés. Il n’y a plus qu’à envoyer le contenu l’application web dessus, généralement au travers d’un dépôt de code source type Git. A chaque mise à jour du code (pouvant être automatiquement validée), l’application web est déployée sur tous les serveurs disponibles. Et, bien entendu, en un clic on peut revenir à la version précédente.

Les SaaS (Software as a Service) sont les logiciels connectés que nous utilisons tous aujourd’hui : Google Apps, Office Online, et autres. Le logiciel évolue en permanence et est 100% hébergé. Généralement facturé mensuellement, il permet une souplesse de gestion.

Le web de 2016

Plusieurs révolutions pourraient bien intervenir dans les prochains mois.

Docker et Kubernetes : la révolution des conteneurs

Jusqu’à aujourd’hui, la meilleure solution pour déployer une application web était la machine virtuelle, avec les avantages qu’on lui connait.

Docker et son partenaire Kubernetes proposent un fonctionnement complémentaire : à l’instar de « chroot », mais de manière plus poussée, il est possible de déployer une application dans un conteneur isolé. Quelle que soit la plateforme d’accueil.

Ce procédé est plus léger qu’une machine virtuelle et répond à un réel besoin pour le déploiement rapide d’applications web.

C’est également un excellent outil DevOps dans le sens où on peut parfaitement développer et tester une application dans un environnement exactement identique à l’environnement de production.

Docker permet de concevoir ces conteneurs et Kubernetes permet de les gérer.

Les objets connectés

Plus ou moins limités en ressources, avec des usages et des profils différents, les objets connectés sont une véritable révolution.

Cette révolution va, une nouvelle fois, nous forcer à inventer de nouvelles technologies et de nouveaux usages.

La 3D et la réalité virtuelle

Avec l’émergence de la 3D dans le navigateur web grâce au WebGL, de nouveaux usages sont à imaginer.

D’autant que la réalité virtuelle va très certainement prendre une dimension sociale et sociétable dans les années à venir.

2020 : apogée du Web 3.0 ?

Ces nouveaux usages qui se présentent à nous sont les indicateurs d’une nouvelle révolution du numérique.

Ces usages sont encore timides, jusqu’à ce qu’ils deviennent standards. Dès lors, nous pourront parler du Web 3.0.

A nous de le construire !

Projet AMP : pour un web mobile plus rapide

Le projet AMP (AMP = Accelerated Mobile Pages) est un projet open-source à l’initiative de Google.

Cette initiative est venue des éditeurs de contenu (les journaux, les blogs) et des éditeurs technologiques (Twitter, LinkedIn, etc) afin d’accélérer le chargement du contenu sur mobile.

Quel intérêt ?

Une page de contenu se chargerait entre 15 % et 85 % plus rapidement sur un mobile.

C’est donc un confort de lecture optimal pour tout ce qui touche au contenu rédactionnel.

Comment ça fonctionne ?

Pour faire simple :

  • un framework Javascript simplifié optimisant le chargement du contenu
  • très peu de Javascript
  • du HTML amélioré avec une syntaxe allégée
  • du CSS minimal pour un rendu personnalisé
  • des composants optimisés clés en main (amp-video, amp-img, amp-twitter, amp-lightbox, amp-ad, etc)

Quelle est la date de disponibilité ?

Le projet est accessible en open-source sur GitHub depuis le 7 octobre 2015.

Il va ainsi évoluer avec les avancement de la communauté de sorte à pouvoir progressivement définir des spécifications précises.

Les principaux contributeurs

Côté éditeurs, parmi les plus connus :

  • BBC
  • BuzzFeed
  • The Economist
  • Financial Time
  • El Pais
  • The Guardian
  • Les Echos
  • The Huffington Post
  • The New York Times
  • Time
  • The Wall Street Journal
  • The Washington Post
  • Mashable

Pour ce qui est des partenaires technologiques :

  • Google
  • Adobe Analytics
  • LinkedIn
  • Twitter
  • Pinterest
  • WordPress.com

Ruby : le développement agile

Chez Morin Innovation, société orienté « startup », nous travaillons à 100 % en mode agile. L’enjeu est de pouvoir être réactif tout en sécurisant le travail. Un bon équilibre en qualité et productivité.

Pour cela, nous nous appuyons sur Ruby, un langage orienté agilité de par sa conception.

Idée reçue n°1 : tout projet peut être mené quel que soit le langage utilisé

Cette idée, souvent répandue par les chefs de projets qui n’ont pas forcément de connaissances techniques, est théoriquement vraie. Mais théoriquement seulement.

Je peux théoriquement construire une maison en bois avec beaucoup d’allumettes. La maison sera théoriquement aussi solide. Mais il sera plus rapide et plus adapté d’utilisé le matériau adéquate.

Pour le développement, c’est pareil. C’est dans cet esprit qu’a été conçu Ruby dès ses origines : pour le développement agile.

Le langage et son environnement permettent de réaliser très rapidement des développements robustes. Dans la limite de ce que permettent les langages de script.

Idée reçue n°2 : les performances du langage déterminent les performances de l’application

Ne confondons pas performances et efficacité. Si l’interpréteur Ruby n’est pas le meilleur (ni le pire) en termes de performances, il permet un développement rapide. Et son environnement lui permet d’être optimal en termes d’efficacité.

Rien ne sert de courir, il faut partir à point.

Ruby propose une syntaxe optimale et minimaliste pour le développement. La relecture en est donc simplifiée. La correction de bugs est plus rapide. L’optimisation est également plus facile car plus simple à appréhender.

Également, le gain de temps obtenu sur la réalisation permet, si nécessaire, de passer du temps sur l’optimisation.

De plus, Ruby possède un système de packages (des composants à installer) qui fournissent du code open-source très simple à intégré et déjà optimisé.

Car, s’il y a une force dans Ruby, c’est également son système de plugins natifs, qui permet d’appeler du code natif (performant) depuis le langage Ruby. Idéal pour les portions de code critique (analyse de contenu XML/HTML, génération d’images, etc).

Enfin, le code Ruby peut être exécuté au travers d’une machine virtuelle Java (JVM) grâce à JRuby, ce qui apporte un gain de performances conséquent tout en profitant de l’efficacité de l’outil.

Ruby en environnement agile

Passées ces idées reçues, venons-en aux faits. En quoi Ruby est-il meilleur qu’un autre en environnement agile (SCRUM ou autres) ?

Développement souple et rapide

Comme évoqué, la syntaxe même de Ruby lui permet de faciliter le travail du développeur, que ce soit seul ou en équipe.

Un petit bout de code « pour tester » peut être très rapidement déployé. En quelques minutes, on peut avoir un outil d’extraction de données ou de quoi tester un service web.

Adapté aux tests unitaires

Que ce soit via ses modules de tests intégrés (Test::Unit) ou via des outils externes plus élaborés (RSpec), les tests unitaires sont une partie intégrante de l’environnement de développement Ruby.

Au delà de l’apport évident en termes de sécurité et de fiabilité du code, c’est un atout majeur pour le travail en équipe et le développement par les tests (Test Driven Development) qui est un des socles du développement agile.

Bien entendu, de nombreux outils permettent une intégration continue optimale et naturelle, ce qui est également un atout des méthodes de travail agiles.

Idéal pour le travail en équipe

Le code étant basé sur le script, son intégration dans les dépôts de code source (Git et autres) est totalement adapté.

Egalement, son système de packages (les gems) et la configuration des dépendances via le fameux Gemfile permettent d’installer rapidement l’environnement de développement adapté au projet.

Egalement, les gems pouvant être privés et stockés sur Git, le partage de code entre les projets est totalement optimisé.

Un atout majeur pour rejoindre les équipes. Que l’on travaille sur un même réseau ou à distance. Et dans un environnement de travail hétérogène.

Ruby on Rails : le développement web agile

Ruby on Rails est un framework web conçu en Ruby.

Son avantage est sa structure, copiée par de nombreux autres projets dans d’autres langages (Symfony, Play! et autres) : mais la copie ne vaut jamais l’original. Cette structure permet non seulement de s’y retrouver dans son propre code, mais permet également de facilement intégrer des développeurs sur un projet. Et, par extension, faciliter la reprise du code.

Ruby on Rails intègre évidemment les tests unitaires, un impératif pour l’intégration continue (via Codeship par exemple).

Le tout en profitant des atouts de Ruby. Et d’une logique orienté efficacité plus que performances.

La souplesse de l’outil permet un déploiement en environnement « scalable » très simple. Notamment grâce à des solutions comme Heroku, qui proposent un hébergement sans ce soucier de l’aspect administration réseau (tout se fait au travers d’un simple dépôt Git sécurisé).

La sécurité est au rendez-vous, avec un respect scrupuleux des recommandations OWASP.

Les performances « effectives » sont également au RDV, grâce – notamment – à des mécanismes de mise en cache simplifiés.

Success Stories

Travaillant en marque blanche (invisible pour le client final), je ne peux présenter les success stories de Morin Innovation. Je peux juste dire que Ruby nous permet de tenir nos délais de manière systématique (sauf rares exceptions indépendantes de l’équipe), tout en ayant une réactivité maximale sur la correction de bugs et avec des performances très honorables. (on a pu monter jusqu’à 1000 utilisateurs simultanés sur un projet web sans blocage ni lenteur)

Plusieurs sociétés se sont développées grâce à Ruby, et plus particulièrement Ruby on Rails :

  • Twitter
  • Shopify
  • LinkedIn
  • GitHub
  • Basecamp
  • Drivy
  • Airbnb
  • et bien d’autres.

Quid des autres solutions ?

D’autres solutions se développent, bien souvent en « copiant » le modèle de Ruby on Rails, mais dans d’autres langages.

NodeJS, par exemple, est à la mode. On entend souvent des responsables de projets informatiques en faire la promo en amont, dire ensuite que c’est génial… mais ne jamais le déployer à grande échelle. CQFD 🙂

En PHP, Symfony s’approche de Ruby on Rails. En Java (Scala), c’est Play qui reprend le même modèle.

Mais bon, la syntaxe joue beaucoup. Le langage Python, et son framework web Django, est probablement un des seuls à être du niveau de Ruby en termes d’efficacité.

L’évolution en environnement Java

Bien souvent, de nombreuses structures se sont orientées vers Java. Et elles souhaitent ensuite évoluer vers des solutions plus agiles.

L’avantages de Ruby est qu’il possède son environnement d’exécution Java : JRuby.

Non seulement JRuby peut s’exécuter dans un environnement Java, mais en plus on peut appeler du code Java depuis JRuby et vice versa.

Et maintenant ?

Je vous ai présenté l’environnement de développement Ruby.

Si vous souhaitez en savoir plus, n’hésitez pas à contacter Morin Innovation.

La cité niortaise devient la cité des startups et de l’innovation. Ce sera un plaisir pour nous de contribuer à l’accélération de vos développements.