Cypress : Une variante en bien mieux de PhantomJS

Dans un récent post, je parlais de Nightwatch, qui prend toute son ampleur lorsque l’on plug le bousin à Browserstack afin de lancer les tests d’intégration sur plusieurs browsers et différents OS (y compris mobile).

Mais, si vous ne voulez vraiment pas comprendre que Nightwatch + Browserstack, c’est trop bien, lisez ce qui suit.

Continuer la lecture de « Cypress : Une variante en bien mieux de PhantomJS »

Rendre le passage des tests unitaires obligatoires avant de commit / push

Il arrive parfois (souvent) (tout le temps) que l’on ai besoin de s’assurer qu’on balance pas du code pété lors un commit / push. Bien entendu on dispose des pipelines de nos CI habituels pour lancer les tests unitaires après coup, mais dans l’idéal, chaque commit et chaque push sur le repo devrait obligatoirement avoir été testé en amont.

On va voir comment arranger ça.

Continuer la lecture de « Rendre le passage des tests unitaires obligatoires avant de commit / push »

React & TypeScript

Le plus intéressant dans Angular 2 / 3 / 4 / 5, c’est TypeScript (Allez BAM ! Punchline dès le départ !).

Oui bon, j’ai rien contre Angular 2 / 3 / 4 / 5 qui est une façon très compliquée de faire des choses qu’on pourrait faire simplement avec React (BAM ! Seconde punchline !).

Angular est vraiment plein de qualités et est très clairement en tête (EXPLOSIOOOOOOOONS ! MI BLABLA SPLOSIOOOOONS ! Bon ok, ok, j’arrête)

Non, vraiment, en toute honnêteté, j’ai rien contre Angular. C’est un bon choix dans beaucoup de projets.

Mais j’aime bien React aussi (surtout), et aujourd’hui on va voir comment utiliser TypeScript au sein de notre application.

Continuer la lecture de « React & TypeScript »

Publier un APK pour diffuser une app React Native sur Google Play

Ayé, votre application avec ZE KILLER FEATURE est développée. Vous avez testé tout ça avec vos émulateurs, diffusé un APK non signé pour tester sur de vrais devices, tout est ok, y a plus qu’à, youpi tagadoum tsouin tsouin

Sauf que, maintenant, Google Play vous demande de signer votre APK et de l’aligner.

Signer ?

Aligner ?

WHAT ???

Continuer la lecture de « Publier un APK pour diffuser une app React Native sur Google Play »

Utiliser un bucket aws s3 en sous domaine

Imaginons que vous voulez servir les assets d’un bucket s3 avec une url propre liées à votre nom de domaine.

Avec AWS, c’est possible et c’est très simple, il vous suffit de :

  • De créer un bucket dont le nom sera, par exemple medias.babonaux.com, en settant les ACL en public-read si vous voulez que les gens puissent lire les fichiers qui y sont stockés
  • De récupérer l’url complète de votre bucket  fraichement créé (medias.babonaux.com.s3.amazonaws.com)
  • De créer un CNAME chez votre dealer de nom de domaine : medias -> medias.babonaux.com.s3.amazonaws.com

Et le tour est joué.

Attention à bien autoriser un accès public à vos fichiers.

Ceci dit, vous pouvez faire la même chose avec CloudFront, ce qui vous apportera beaucoup plus d’avantages puisque vos assets fonctionneront alors comme sur un CDN (vu que c’est un peu la base de CloudFront…)

 

[Snippet] Upload des fichiers sur un Bucket AWS S3

Allez hop, j’introduis une nouvelle catégorie d’articles dont l’objectif est de fournir de petits morceaux de code bien pratiques. Aujourd’hui, on va uploader un fichier sur un bucket S3 avec PHP (mais la logique est la même avec du NodeJS).

Un commence par petit

php composer.phar install aws-sdk

Et ensuite, dans une petite classe PHP :

$bucket = 'nomdevotrebucket';
 $filepath = 'path/to/file';
 $destinationpath = 'dossier/nomdefichiersurvotrebuckets3'
 $s3options = array(
 'region' => 'eu-west-1',
 'version' => 'latest',
   'credentials' => array(
              'key' => 'votrecleaws',
              'secret' => 'votresecretaws',
         ),
 );

// Instantiate the client.
 $s3 = S3Client::factory($s3options);

// Upload file.
 $result = $s3->putObject(array(
 'Bucket' => $bucket,
 'Key' => $destinationpath,
 'SourceFile' => $filepath,
       'ACL' => 'public-read',
 ));

La partie credentials est optionnelle si vous avez pris la bonne habitude de stocker vos clés dans votre .credentials, ou si votre machine est un EC2.

La partie region est à adapter en fonction de l’endroit où vous avez choisi de créer votre bucket.

J’ai mis ici l’ACL public-read en partant du principe que l’accès au fichier était… public. Vous pouvez bien sûr adapter en fonction de vos besoins.

Voilou !

Passez offline avec Redux Persist et LocalForage

(image généreusement piquée sur http://blog.marketo.com/2016/05/live-from-marketing-nation-summit-digital-transformation-resilience-and-authenticity.html)

Le marketing vient d’avoir une idée. Une super idée même.

Une idée tellement géniale qu’il l’a déjà vendu aux clients de votre société, contacté la presse, et les investisseurs sont également très enthousiastes.

Tout va pour le mieux dans le meilleur des mondes, à un détail près : On vient tout juste de vous mettre au courant, vous, les gens de l’informatique, de cette idée. Et maintenant que le dossier de relation presse est dans les tuyaux, que le champagne est commandé et que le musée d’art contemporain de St Plessy le Boujounou a été privatisé en vue de la sortie officielle – dans 10 jours, ça va être difficile d’expliquer à tout le monde que ça aurait été sympa de vous mettre dans la boucle un petit peu avant.

Cette feature de votre app-ki-ravage tout, judicieusement appelée « Plus de 4g dans le train » par un marketeux bourré d’inspiration, consiste à pouvoir continuer à travailler avec l’application même quand la 4g part en sucette dans le train. C’est un peu comme utiliser Gmail en mode offline. Ou Google Doc en mode offline.

Bref, il va donc falloir la sortir les doigts dans le nez cette feature, en moins de dix jours. Tests compris. Validé par le marketing.

Non, aucun raison d’être aigri ou sarcastique. Vraiment. Ca ne vous ressemble pas. Vous avez fait les bons choix en amont. Votre application tourne sur React / Redux.

Ca va bien se passer. Même si on dit généralement « ça va bien se passer » dans une soirée où un truc très long en silicone et un pot de vaseline ne sont jamais bien loin.

Continuer la lecture de « Passez offline avec Redux Persist et LocalForage »

Intégration continue avec GitLab

Dans la continuité de ce qu’on a fait précédemment en se créant des tests unitaires et des tests end to end, on va maintenant plugger tout ça (et un peu plus) à un pipeline Gitlab afin de :

  • Lancer nos tests unitaires directement après un push
  • Builder notre application et la balancer sur un FTP
  • Jouer avec les variables d’environnement afin de choisir sur quel FTP on veut envoyer notre build (dev / prod)
  • Lancer nos tests end to end pour s’assurer qu’on a pas pété notre UI

Let’s go !

Continuer la lecture de « Intégration continue avec GitLab »