Présentation

C'est mon deuxième article de blog sur Pravatar et ma troisième semaine au sein de l'équipe Belighted est déjà terminée, le temps passe si vite !

Dans celui-ci, je vais partager avec vous les sujets qui m'ont semblé les plus intéressants à aborder.

Afin de ne pas vous perdre dans mes explications ni de vous surcharger de détails sur le SaaS, je vais commencer par un petit résumé des principales fonctionnalités de Pravatar au moment de la rédaction de cet article, puis je parlerai du back-end et du front-end.

Pravatar

Pravatar dispose désormais d'une page par défaut sur laquelle les clients peuvent s'inscrire au service, gérer leurs comptes et définir un avatar par défaut.

L'extrait de code client permet désormais à une application de demander différentes versions d'un avatar, de télécharger un avatar pour un profil et de créer des comptes à la volée.

Sur le back-end

Les principales tâches du back-end étaient de continuer à développer l'API et à adapter l'application afin de répondre aux besoins des clients, mais cela m'a amené à apporter des modifications majeures à l'application.

Interacteur

L'un d'eux dit :

Manettes Skinny Models Fat.

Mais Philippe m'a appris que mettre toute la logique dans des modèles n'est pas non plus la solution.
Ce que nous voulons, c'est conserver dans les modèles leur propre logique spécialisée, mais nous pouvons extraire la logique métier dans une quatrième couche appelée Interactor, et qui reflète (comme le disent les créateurs de la gemme) ce que notre application faire.

J'ai construit un interacteur pour représenter enregistrement processus, il crée simplement un utilisateur et son compte avec des paramètres donnés, et renvoie un contexte avec un succès ou un échec.
Ce interacteur est alors appelé par manette, qui effectuera en outre ses actions les plus spécifiques.

AWS S3

Même si cela me semblait obscur, configurer S3 pour stocker le avatars C'était très amusant.

La gemme fog fournit une bibliothèque de services cloud, qui peut facilement être utilisée avec CarrierWave pour télécharger vos fichiers sur S3.
Mes exigences étaient de conserver le stockage local pour test, et de cibler trois catégories différentes pour développement, mise en scène et production.

Cela a été fait simplement en donnant à fog mes informations d'identification AWS, en faisant en sorte que CarrierWave utilise fichier ou brouillard stockage en fonction de l'environnement actuel, et définir le bon des seaux pour les environnements non destinés aux tests.

Une fois configuré, aucune modification n'a été nécessaire dans l'implémentation des avatars, CarrierWave fonctionne à merveille.

Sur le front-end

Gulp : tests et flux de travail confortables

Enfin, mes tests javascript se trouvaient dans le dossier spec qui concerne normalement les tests RSpec sur l'application Rails uniquement.
Le projet a deux aspects distincts, mais nous voulions garder le client à proximité de celui du serveur, afin de maintenir facilement l'ensemble du package et simplement parce que l'extrait js est fourni par l'application Rails.

J'ai donc créé un répertoire dédié à la racine de l'application pour toutes les applications frontales, et je lui ai donné l'outil miraculeux qu'est Gulp.

Gulp s'est révélé être une solution vraiment géniale à tout un tas de problèmes actuels ou futurs :

• Comment lancer facilement des tests tout en travaillant sur l'application
• Comment gérer le regroupement avec jQuery à chaque fois que la source de l'extrait change ?
• Comme les tests et les sources sont écrits en coffeescript, comment éviter la première solution qui consistait à utiliser le précompilateur rails assets ?

Le flux de travail sur le widget se présente désormais comme suit :

1. Lancez gulp pour surveiller tout changement dans mes sources .coffee, pour les compiler si cela se produit
2. Rédigez les tests
3. Écrivez l'extrait de code, qui sera compilé et groupé à la volée, et également testé automatiquement par gulp & karma avec les tests que je viens d'écrire.

Désolée de t'avoir détesté il y a deux semaines.

Améliorations apportées au widget

Récupération des avatars

Tout d'abord, afin d'avancer vers ce que sera le projet ultérieurement, les avatars sont désormais récupérés par la combinaison d'un identifiant de compte et d'un identifiant externe faisant référence au profil.
Cela signifie qu'une application peut enregistrer les profils de ses utilisateurs en fournissant à Pravatar leur »clé primaire«, quels qu'ils soient (mails, noms d'utilisateur,...).

Téléchargement et avatar par défaut

Les titulaires de comptes peuvent désormais définir un avatar par défaut pour leur profil, qui sera automatiquement affiché si le profil demandé n'existe pas ou n'a pas d'avatar.

Une fonctionnalité de téléchargement a été ajoutée au widget, un div de pravatar peut désormais être utilisé pour définir une zone de téléchargement pour un utilisateur demandé, existant ou non.
Si un téléchargement a lieu sur un profil inexistant, il sera créé à la volée par Pravatar sur le compte correspondant.
Il s'agit d'une évolution vers la caractéristique plug'n'play de Pravatar, un service facile à utiliser et sans contraintes pour l'application qui l'utilisera.

Conclusion

Pas à pas, pas à pas, le SaaS prend progressivement forme.

Ce n'est que le début, mais j'aime vraiment travailler dessus, apprendre des choses précieuses chaque jour et travailler avec toutes les personnes de Belighted.