One place for hosting & domains

      ajouter

      Comment ajouter Swap sur Ubuntu 20.04


      Introduction

      Une façon de se prémunir contre les erreurs de mémoire dans les applications est d’ajouter un espace swap à votre serveur. Dans ce guide, nous verrons comment ajouter un fichier swap à un serveur Ubuntu 20.04.

      Warning : Bien que le swap soit généralement recommandé pour les systèmes utilisant des disques durs tournants traditionnels, le fait de placer le swap sur des SSD peut entraîner des problèmes de dégradation du matériel au fil du temps.   Pour cette raison, nous ne recommandons pas de permettre le swap sur DigitalOcean ou tout autre fournisseur qui utilise le stockage SSD.

      Qu’est-ce que le swap?

      Le swap est une partie du stockage du disque dur qui a été mise de côté pour que le système d’exploitation puisse stocker temporairement les données qu’il ne peut plus conserver en mémoire vive.   Cela vous permet d’augmenter la quantité d’informations que votre serveur peut conserver dans sa mémoire de travail, avec quelques réserves. L’espace swap sur le disque dur sera utilisé principalement lorsque l’espace en mémoire vive ne sera plus suffisant pour contenir les données des applications en cours d’utilisation.

      Les informations écrites sur le disque seront nettement plus lentes que celles conservées dans la mémoire vive, mais le système d’exploitation préférera conserver les données des applications en mémoire et utiliser le swap pour les données plus anciennes. Dans l’ensemble, le fait de disposer d’un espace swap comme solution de repli lorsque la mémoire vive de votre système est épuisée peut constituer un bon filet de sécurité contre les exceptions de sortie de mémoire sur les systèmes disposant d’un stockage non-SSD.

      Étape 1 – Vérification du système d’information sur les swaps

      Avant de commencer, nous pouvons vérifier si le système dispose déjà d’un espace swap disponible. Il est possible d’avoir plusieurs fichiers swap ou partitions swap, mais en général, un seul devrait suffire.

      Nous pouvons voir si le système dispose d’un échange configuré en tapant :

      Si vous ne récupérez pas les résultats, cela signifie que votre système ne dispose pas actuellement d’espace swap disponible.

      Vous pouvez vérifier qu’il n’y a pas de swap actif en utilisant l’utilitaire free :

      Output

      total used free shared buff/cache available Mem: 981Mi 122Mi 647Mi 0.0Ki 211Mi 714Mi Swap: 0B 0B 0B

      Comme vous pouvez le voir dans la ligne Swap du résultat, aucun swap n’est actif sur le système.

      Étape 2 – Vérifier de l’espace disponible sur la partition du disque dur

      Avant de créer notre fichier swap, nous vérifierons notre utilisation actuelle du disque pour nous assurer que nous avons suffisamment d’espace. Faites ceci en entrant :

      Output

      Filesystem Size Used Avail Use% Mounted on udev 474M 0 474M 0% /dev tmpfs 99M 932K 98M 1% /run /dev/vda1 25G 1.4G 23G 7% / tmpfs 491M 0 491M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 491M 0 491M 0% /sys/fs/cgroup /dev/vda15 105M 3.9M 101M 4% /boot/efi /dev/loop0 55M 55M 0 100% /snap/core18/1705 /dev/loop1 69M 69M 0 100% /snap/lxd/14804 /dev/loop2 28M 28M 0 100% /snap/snapd/7264 tmpfs 99M 0 99M 0% /run/user/1000

      L’appareil avec / dans la colonne Mounted on est ici notre disque. Nous avons beaucoup d’espace disponible dans cet exemple (seulement 1,4 G utilisé). Votre usage sera probablement différent.

      Bien qu’il existe de nombreuses opinions sur la taille appropriée d’un espace swap, cela dépend vraiment de vos préférences personnelles et des exigences de votre demande. En général, une quantité égale ou double de la quantité de mémoire vive de votre système est un bon point de départ. Une autre bonne règle de base est que tout ce qui dépasse 4G de swap est probablement inutile si vous l’utilisez simplement comme solution de repli de la RAM.

      Étape 3 – Créer d’un fichier swap

      Maintenant que nous connaissons l’espace disponible sur notre disque dur, nous pouvons créer un fichier swap sur notre système de fichiers. Nous allons attribuer un fichier de la taille que nous voulons appelé swapfile dans notre répertoire root (/).

      Le meilleur moyen de créer un fichier swap est le programme fallocate. Cette commande crée instantanément un fichier de la taille spécifiée.

      Comme le serveur de notre exemple a 1G de mémoire vive, nous allons créer un fichier de 1G dans ce guide. Ajustez cela pour répondre aux besoins de votre propre serveur :

      • sudo fallocate -l 1G /swapfile

      Nous pouvons vérifier que la quantité d’espace correcte a été réservée en tapant :

      • -rw-r--r-- 1 root root 1.0G Apr 25 11:14 /swapfile

      Notre dossier a été créé avec la bonne quantité d’espace réservé.

      Étape 4 – Activer le fichier Swap

      Maintenant que nous disposons d’un fichier de la bonne taille, nous devons le transformer en espace swap.

      Tout d’abord, nous devons verrouiller les permissions du fichier afin que seuls les utilisateurs ayant les privilèges root puissent en lire le contenu. Cela empêche les utilisateurs normaux de pouvoir accéder au fichier, ce qui aurait des implications importantes en matière de sécurité.

      Rendre le fichier accessible uniquement au root en tapant : 

      Vérifiez la modification des autorisations en tapant :

      Output

      -rw------- 1 root root 1.0G Apr 25 11:14 /swapfile

      Comme vous pouvez le voir, seul le root user a les drapeaux de lecture et d’écriture activés.

      Nous pouvons maintenant marquer le fichier comme espace swap en tapant :

      Output

      Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes) no label, UUID=6e965805-2ab9-450f-aed6-577e74089dbf

      Après avoir marqué le fichier, nous pouvons activer le fichier swap, ce qui permet à notre système de commencer à l’utiliser :

      Vérifiez que le swap est disponible en tapant :

      Output

      NAME TYPE SIZE USED PRIO /swapfile file 1024M 0B -2

      Nous pouvons vérifier à nouveau les résultats de l’utilitaire free pour corroborer nos conclusions :

      Output

      total used free shared buff/cache available Mem: 981Mi 123Mi 644Mi 0.0Ki 213Mi 714Mi Swap: 1.0Gi 0B 1.0Gi

      Notre swap a été mis en place avec succès et notre système d’exploitation commencera à l’utiliser si nécessaire.

      Étape 5 – Rendre le fichier swap permanent

      Nos récents changements ont permis d’activer le fichier swap pour la session en cours. Cependant, si nous redémarrons, le serveur ne conservera pas automatiquement les paramètres du swap. Nous pouvons changer cela en ajoutant le fichier swap à notre fichier /etc/fstab.

      Sauvegardez le fichier /etc/fstab au cas où quelque chose n’irait pas :

      • sudo cp /etc/fstab /etc/fstab.bak

      Ajoutez les informations du fichier swap à la fin de votre fichier /etc/fstab en tapant : 

      • echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

      Ensuite, nous allons revoir certains paramètres que nous pouvons mettre à jour pour régler notre espace swap.

      Étape 6 – Réglage de vos paramètres swap

      Il existe quelques options que vous pouvez configurer et qui auront un impact sur les performances de votre système lors de la gestion des swaps.

      Ajuster la propriété du swappiness

      Le paramètre swappiness permet de configurer la fréquence à laquelle votre système échange des données de la mémoire vive vers l’espace swap. Il s’agit d’une valeur comprise entre 0 et 100 qui représente un pourcentage.

      Avec des valeurs proches de zéro, le noyau n’échangera pas de données sur le disque à moins que cela ne soit absolument nécessaire. N’oubliez pas que les interactions avec le fichier swap sont « lourdes » dans la mesure où elles prennent beaucoup plus de temps que les interactions avec la mémoire vive et qu’elles peuvent entraîner une réduction significative des performances. Le fait de dire au système de ne pas trop dépendre du swap rendra généralement votre système plus rapide.

      Les valeurs plus proches de 100 tenteront de mettre plus de données dans le swap afin de garder plus d’espace RAM libre. En fonction du profil de mémoire de vos applications ou de l’utilisation que vous faites de votre serveur, cela peut être préférable dans certains cas.

      On peut voir la valeur actuelle du swap en tapant :

      • cat /proc/sys/vm/swappiness

      Output

      60

      Pour un ordinateur de bureau, un paramètre de swappiness de 60 n’est pas une mauvaise valeur. Pour un serveur, vous voudrez peut-être le rapprocher de 0.

      Nous pouvons régler le swappiness à une valeur différente en utilisant la commande sysctl.

      Par exemple, pour régler le swappiness sur 10, nous pourrions taper :

      • sudo sysctl vm.swappiness=10

      Output

      vm.swappiness = 10

      Ce réglage persistera jusqu’au prochain redémarrage. Nous pouvons fixer cette valeur automatiquement au redémarrage en ajoutant la ligne à notrefichier /etc/sysctl.conf : 

      • sudo nano /etc/sysctl.conf

      En bas, vous pouvez ajouter :

      /etc/sysctl.conf

      vm.swappiness=10
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Ajuster le réglage de la pression du cache

      Une autre valeur connexe que vous pourriez vouloir modifier est la vfs_cache_pressure.   Ce paramètre configure la quantité que le système choisira pour mettre en cache les informations d’inode et de dentry sur d’autres données.

      Fondamentalement, il s’agit de données d’accès au système de fichiers. Il est généralement très difficile à consulter et très souvent demandé, c’est donc une excellente chose pour votre système de mettre en cache. Vous pouvez voir la valeur actuelle en interrogeant à nouveau le système de fichiers proc :

      • cat /proc/sys/vm/vfs_cache_pressure

      Output

      100

      Dans sa configuration actuelle, notre système supprime trop rapidement les informations d’inode du cache. Nous pouvons fixer ce chiffre à un niveau plus conservateur, comme 50, en tapant :

      • sudo sysctl vm.vfs_cache_pressure=50

      Output

      vm.vfs_cache_pressure = 50

      Encore une fois, ceci n’est valable que pour notre session actuelle. Nous pouvons changer cela en l’ajoutant à notre fichier de configuration comme nous l’avons fait avec notre réglage du swappiness :

      • sudo nano /etc/sysctl.conf

      En bas, ajoutez la ligne qui spécifie votre nouvelle valeur :

      /etc/sysctl.conf

      vm.vfs_cache_pressure=50
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Conclusion

      En suivant les étapes décrites dans ce guide, vous aurez une certaine marge de manœuvre dans les cas qui, autrement, entraîneraient des exceptions hors mémoire. L’espace de swap peut être incroyablement utile pour éviter certains de ces problèmes courants.

      Si vous rencontrez des erreurs OOM (out of memory), ou si vous constatez que votre système est incapable d’utiliser les applications dont vous avez besoin, la meilleure solution est d’optimiser vos configurations d’applications ou de mettre à niveau votre serveur.



      Source link

      Comment ajouter les tests unitaires à votre projet Django


      L’auteur a choisi le Open Internet/Free Speech Fund pour recevoir un don dans le cadre du programme Write for Donations.

      Introduction

      Il est presque impossible de construire des sites web qui fonctionnent parfaitement du premier coup sans erreurs. C’est pourquoi vous devez tester votre application web pour trouver ces erreurs et y remédier de manière proactive. Afin d’améliorer l’efficacité des tests, il est courant de décomposer les tests en unités qui testent des fonctionnalités spécifiques de l’application web. Cette pratique est appelée les tests unitaires.   Il est plus facile de détecter les erreurs, car les tests se concentrent sur de petites parties (unités) de votre projet indépendamment des autres parties.

      Tester un site web peut être une tâche complexe à entreprendre car il est constitué de plusieurs couches de logique comme le traitement des requêtes HTTP, la validation des formulaires et les modèles de rendu. Cependant, Django fournit un ensemble d’outils qui permettent de tester votre application web en toute transparence.   Dans Django, la façon préférée d’écrire des tests est d’utiliser le module Python unittest, bien qu’il soit possible d’utiliser d’autres cadres de test. 

      Dans ce tutoriel, vous allez mettre en place une suite de tests dans votre projet Django et écrire des tests unitaires pour les modèles et les vues de votre application. Vous effectuerez ces tests, analyserez leurs résultats et apprendrez comment trouver les causes des échecs.

      Conditions préalables

      Avant de commencer ce tutoriel, vous aurez besoin des éléments suivants :

      Étape 1 – Ajouter une séquence de tests à votre demande Django

      Une séquence de tests dans Django est une collection de tous les scénarios de test de toutes les applications de votre projet. Pour permettre à l’utilitaire de test de Django de découvrir les scénarios de test que vous avez, vous écrivez les scénarios de test dans des scripts dont le nom commence par test.   Au cours de cette étape, vous allez créer la structure des répertoires et des fichiers de votre séquence de tests, et y créer un scénario de test vide.

      Si vous avez suivi la série de tutoriels Django Development, vous aurez une application Django appelée blogsite.

      Créons un dossier pour contenir tous nos scripts de test. Tout d’abord, activez l’environnement virtuel :

      • cd ~/my_blog_app
      • . env/bin/activate

      Ensuite, naviguez vers le répertoire appblogsite, le dossier qui contient les fichiers models.py et views.py, puis créez un nouveau dossier appelé tests :

      • cd ~/my_blog_app/blog/blogsite
      • mkdir tests

      Ensuite, vous transformerez ce dossier en un paquet Python, ajoutez donc un fichier __init__.py :

      • cd ~/my_blog_app/blog/blogsite/tests
      • touch __init__.py

      Vous allez maintenant ajouter un fichier pour tester vos modèles et un autre pour tester vos vues :

      • touch test_models.py
      • touch test_views.py

      Enfin, vous allez créer un scénario de test vide dans test_models.py. Vous devrez importer la classe Django TestCase et en faire une super classe de votre propre classe de test case. Plus tard, vous ajouterez des méthodes à ce scénario de test pour tester la logique de vos modèles. Ouvrez le fichier test_models.py :

      Ajoutez maintenant le code suivant au fichier :

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      
      class ModelsTestCase(TestCase):
          pass
      

      Vous avez maintenant ajouté avec succès une séquence de tests à l’appli blogsite. Ensuite, vous remplirez les détails du modèle de cas test vide que vous avez créé ici.

      Étape 2 – Tester votre code Python

      Dans cette étape, vous allez tester la logique du code écrit dans le fichier models.py. En particulier, vous testerez la méthode de sauvegarde du modèle Post afin de vous assurer qu’il crée la bonne portion du titre d’un message lorsqu’il est appelé. 

      Commençons par regarder le code que vous avez déjà dans votre fichier models.py pour la méthode de sauvegarde du modèle Post :

      • cd ~/my_blog_app/blog/blogsite
      • nano models.py

      Vous verrez ce qui suit :

      ~/my_blog_app/blog/blogsite/models.py

      class Post(models.Model):
          ...
          def save(self, *args, **kwargs):
              if not self.slug:
                  self.slug = slugify(self.title)
              super(Post, self).save(*args, **kwargs)
          ...
      

      On peut voir qu’il vérifie si le message sur le point d’être sauvegardé a une valeur de slug, et si ce n’est pas le cas, il appelle slugify pour lui créer une valeur de slug. C’est le type de logique que vous pourriez vouloir tester pour vous assurer que les slugs sont effectivement créés lors de la sauvegarde d’un message.

      Fermez le dossier.

      Pour le tester, retournez à test_models.py :

      Mettez-le ensuite à jour en ajoutant les parties surlignées :

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      from django.template.defaultfilters import slugify
      from blogsite.models import Post
      
      
      class ModelsTestCase(TestCase):
          def test_post_has_slug(self):
              """Posts are given slugs correctly when saving"""
              post = Post.objects.create(title="My first post")
      
              post.author = "John Doe"
              post.save()
              self.assertEqual(post.slug, slugify(post.title))
      

      Cette nouvelle méthode test_post_has_slug crée un nouvel article avec le titre « My first post », puis donne à l’article un auteur et l’enregistre. Ensuite, à l’aide de la méthode assertEqual du module Python unittest, il vérifie si le slug du message est correct. La méthode assertEqual vérifie si les deux arguments qui lui sont transmis sont égaux tels que déterminés par l’opérateur « == » et signale une erreur s’ils ne le sont pas.

      Sauvegarder et quitter test_models.py.

      Voici un exemple de ce qui peut être testé. Plus vous ajoutez de logique à votre projet, plus il y a de choses à tester. Si vous ajoutez plus de logique à la méthode de sauvegarde ou créez de nouvelles méthodes pour le modèle Post, vous voudriez ajouter plus de tests ici. Vous pouvez les ajouter à la méthode test_post_has_slug ou créer de nouvelles méthodes de test, mais leurs noms doivent commencer par test.

      Vous avez créé avec succès un cas test pour le modèle Post où vous avez affirmé que les slugs sont correctement créés après la sauvegarde. Dans l’étape suivante, vous rédigerez un scénario de test pour tester les vues.

      Étape 3 – Utiliser le client test de Django

      Dans cette étape, vous allez écrire un scénario de test qui teste une vue en utilisant le client de test Django. Le test client est une classe Python qui agit comme un navigateur web factice, vous permettant de tester vos vues et d’interagir avec votre application Django de la même manière qu’un utilisateur le ferait. Vous pouvez accéder au client test en vous référant à self.client dans vos méthodes de test. Par exemple, créons un cas test dans test_views.py Tout d’abord, ouvrez le fichier test_views.py :

      Ajoutez ensuite ce qui suit :

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 200)
      

      Le ViewsTestCase contient une méthode test_index_loads_properly qui utilise le client de test Django pour visiter la page d’index du site (http://your_server_ip:8000, où your_server_ip est l’adresse IP du serveur que vous utilisez). Ensuite, la méthode de test vérifie si la réponse a un code de statut de 200, ce qui signifie que la page a répondu sans aucune erreur. Vous pouvez donc être sûr que lorsque l’utilisateur se rendra sur le site, il répondra lui aussi sans erreur.

      Outre le code de statut, vous pouvez lire d’autres propriétés de la réponse du client de test que vous pouvez tester dans la page des réponses de test de la documentation de Django.

      Au cours de cette étape, vous avez créé un scénario de test pour vérifier que la vue rendant la page d’index fonctionne sans erreur. Il y a maintenant deux scénarios de test dans votre séquence de tests. Au cours de l’étape suivante, vous les exécuterez pour voir leurs résultats.

      Étape 4 – Effectuer vos tests

      Maintenant que vous avez terminé la construction d’une séquence de tests pour le projet, il est temps d’exécuter ces tests et de voir leurs résultats. Pour effectuer les tests, naviguez dans le dossier blog (contenant le fichier manage.py de l’application) :

      Puis, exécutez-les :

      Vous verrez un résultat similaire à ce qui suit dans votre terminal :

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .. ---------------------------------------------------------------------- Ran 2 tests in 0.007s OK Destroying test database for alias 'default'...

      Dans cette sortie, il y a deux points .., dont chacun représente un cas de test réussi. Vous allez maintenant modifier test_views.py pour déclencher un test d’échec. Ouvrez le fichier avec :

      Ensuite, changez le code en surbrillance pour :

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Ici, vous avez changé le code de statut de 200 à 404. Maintenant, refaites le test à partir de votre répertoire avec manage.py :

      Vous verrez la sortie suivante :

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .F ====================================================================== FAIL: test_index_loads_properly (blogsite.tests.test_views.ViewsTestCase) The index page loads properly ---------------------------------------------------------------------- Traceback (most recent call last): File "~/my_blog_app/blog/blogsite/tests/test_views.py", line 8, in test_index_loads_properly self.assertEqual(response.status_code, 404) AssertionError: 200 != 404 ---------------------------------------------------------------------- Ran 2 tests in 0.007s FAILED (failures=1) Destroying test database for alias 'default'...

      Vous voyez qu’il y a un message d’échec descriptif qui vous indique le script, le cas de test et la méthode qui a échoué. Il vous indique également la cause de l’échec, le code de statut n’étant pas égal à 404 dans ce cas, avec le message AssertionError: 200 !  404. L’AssertionError est ici soulevée à la ligne de code surlignée dans le fichier test_views.py :

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Il vous indique que l’affirmation est fausse, c’est-à-dire que le code de statut de réponse (200) n’est pas ce à quoi on s’attendait (404). Précédant le message d’échec, vous pouvez voir que les deux points .. sont maintenant passés à . F, qui vous indique que le premier cas test a réussi alors que le second ne l’a pas fait.

      Conclusion

      Dans ce tutoriel, vous avez créé une suite de tests dans votre projet Django, ajouté des scénarios de test au modèle de test et à la logique de visualisation, appris comment exécuter des tests et analysé les résultats des tests. Dans un deuxième temps, vous pouvez créer de nouveaux scripts de test pour le code Python qui n’est pas dansmodels.py et views.py.

      Voici quelques articles qui peuvent s’avérer utiles pour créer et tester des sites web avec Django :

      Vous pouvez également consulter notre page thématique sur Django pour d’autres tutoriels et projets.



      Source link

      Comment ajouter Sidekiq et Redis à une application Ruby on Rails


      Introduction

      Lors du développement d’une application Ruby on Rails, il se peut que certaines tâches d’application doivent être exécutées de manière asynchrone. Le traitement des données, l’envoi d’e-mails par lots ou l’interaction avec des API externes sont autant d’exemples de travaux qui peuvent être effectués de manière asynchrone avec des travaux en arrière-plan. L’utilisation de travaux en arrière-plan peut améliorer les performances de votre application en déchargeant des tâches potentiellement longues dans une file d’attente de traitement en arrière-plan, libérant ainsi le cycle original de requête/réponse.

      Sidekiq est l’un des frameworks de travail en arrière-plan les plus utilisés que vous pouvez implémenter dans une application Rails. Il est soutenu par Redis, un magasin clé-valeur en mémoire connu pour sa flexibilité et ses performances. Sidekiq utilise Redis comme un magasin de gestion de travaux pour traiter des milliers de travaux par seconde.

      Dans ce tutoriel, vous allez ajouter Redis et Sidekiq à une application Rails existante. Vous allez créer un ensemble de classes de travailleurs Sidekiq et de méthodes à manipuler :

      • Un téléchargement par lots d’informations sur les requins menacés dans la base de données de l’application à partir d’un fichier CSV dans le référentiel du projet.
      • La suppression de ces données.

      Lorsque vous aurez terminé, vous aurez une application de démonstration qui utilise les travailleurs et les travaux pour traiter les tâches de manière asynchrone. Ce sera une bonne base pour vous permettre d’ajouter des travailleurs et des travaux à votre propre application, en utilisant ce tutoriel comme point de départ.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      Étape 1 – Clonage du projet et installation des dépendances

      Notre première étape consistera à cloner le référentiel rails-bootstrap à partir du compte GitHub de DigitalOcean Community. Ce référentiel comprend le code de la configuration décrite dans le tutoriel Comment ajouter Bootstrap à une application Ruby on Rails, qui explique comment ajouter Bootstrap à un projet Rails 5 existant.

      Clonez le référentiel dans un répertoire appelé rails-sidekiq :

      • git clone https://github.com/do-community/rails-bootstrap.git rails-sidekiq

      Naviguez vers le répertoire rails-sidekiq :

      Pour travailler avec le code, vous devrez d’abord installer les dépendances du projet, qui sont listées dans son Gemfile. Vous devrez également ajouter le gem sidekiq au projet pour travailler avec Sidekiq et Redis.

      Ouvrez le Gemfile du projet pour le modifier en utilisant nano ou votre éditeur préféré :

      Ajoutez le gem n’importe où dans les dépendances principales du projet (au-dessus des dépendances de développement) :

      ~/rails-sidekiq/Gemfile

      . . .
      # Reduces boot times through caching; required in config/boot.rb
      gem 'bootsnap', '>= 1.1.0', require: false
      gem 'sidekiq', '~>6.0.0'
      
      group :development, :test do
      . . .
      

      Enregistrez et fermez le fichier lorsque vous avez terminé d’ajouter le gem.

      Utilisez la commande suivante pour installer les gems :

      Vous verrez dans la sortie que le gem redis est également installé, cela étant exigé pour sidekiq.

      Ensuite, vous allez installer vos dépendances Yarn. Étant donné que ce projet Rails 5 a été modifié pour servir des ressources avec webpack, ses dépendances JavaScript sont maintenant gérées par Yarn. Cela signifie qu’il est nécessaire d’installer et de vérifier les dépendances listées dans le fichier package.json.

      Exécutez yarn install pour installer ces dépendances :

      Ensuite, exécutez vos migrations de base de données :

      Une fois vos migrations terminées, vous pouvez tester l’application pour vous assurer qu’elle fonctionne comme prévu. Démarrez votre serveur dans le contexte de votre bundle local avec la commande suivante si vous travaillez localement :

      Si vous travaillez sur un serveur de développement, vous pouvez démarrer l’application avec :

      • bundle exec rails s --binding=your_server_ip

      Naviguez vers localhost:3000 ou http://your_server_ip:3000. Vous verrez la page d’accueil suivante :

      Page d'accueil de l'application

      Pour créer un requin, cliquez sur le bouton Get Shark Info (Obtenir des informations sur les requins), qui vous amènera à la route sharks/index :

      Route sharks/index

      Pour vérifier que l’application fonctionne, nous pouvons y ajouter quelques informations de démonstration. Cliquez sur New Shark (Nouveau Requin). Un nom d’utilisateur (sammy) et un mot de passe (shark) vous seront demandés, grâce aux paramètres d’authentification du projet.

      Dans la page New Shark (Nouveau Requin), entrez « Great White » (Grand Blanc) dans le champ Name (Nom) et « Scary » (Effrayant) dans le champ Facts (Faits) :

      Créer un requin

      Cliquez sur le bouton Create Shark (Créer le requin) pour créer le requin. Une fois que vous voyez que votre requin a été créé, vous pouvez tuer le serveur avec CTRL+C.

      Vous avez désormais installé les dépendances nécessaires pour votre projet et testé sa fonctionnalité. Ensuite, vous pouvez apporter quelques modifications à l’application Rails pour travailler avec vos ressources concernant les requins menacés.

      Étape 2 – Génération d’un contrôleur pour les ressources concernant les requins menacés

      Pour travailler avec nos ressources sur les requins menacés, nous allons ajouter un nouveau modèle à l’application ainsi qu’un contrôleur qui contrôlera la manière dont les informations sur les requins menacés sont présentées aux utilisateurs. Notre objectif ultime est de permettre aux utilisateurs de télécharger vers le serveur un grand nombre d’informations sur les requins menacés sans bloquer la fonctionnalité générale de notre application, et de supprimer ces informations lorsqu’ils n’en ont plus besoin.

      D’abord, créons un modèle Endangered (Menacés) pour nos requins menacés. Nous allons inclure un champ de chaîne dans notre table de base de données pour le nom du requin, et un autre champ de chaîne pour les catégories de l’Union internationale pour la conservation de la nature (UICN) qui déterminent le degré de risque pour chaque requin.

      En fin de compte, la structure de notre modèle correspondra aux colonnes du fichier CSV que nous utiliserons pour créer notre téléchargement par lots. Ce fichier est situé dans le répertoire db, et vous pouvez vérifier son contenu avec la commande suivante :

      Le fichier contient une liste de 73 requins en voie de disparition et leurs statuts : vu pour vulnérables, en pour menacés et cr pour en voie de disparition.

      Notre modèle Endangered sera en corrélation avec ces données, ce qui nous permettra de créer de nouvelles instances Endangered à partir de ce fichier CSV. Créez le modèle avec la commande suivante :

      • rails generate model Endangered name:string iucn:string

      Ensuite, générez un contrôleur Endangered avec une action index :

      • rails generate controller endangered index

      Cela nous donnera un point de départ pour développer les fonctionnalités de notre application, mais nous devrons également ajouter des méthodes personnalisées au fichier de contrôleur que Rails a généré pour nous.

      Maintenant, ouvrez ce fichier :

      • nano app/controllers/endangered_controller.rb

      Rails nous a fourni un schéma de base que nous pouvons commencer à remplir.

      Tout d’abord, nous devons déterminer les routes nécessaires pour travailler avec nos données. Grâce à la commande generate controller, nous disposons d’une méthode index pour commencer. Cela correspondra à une vue index, où nous présenterons aux utilisateurs la possibilité de télécharger vers le serveur des requins menacés.

      Toutefois, nous voudrons également traiter les cas où les utilisateurs ont déjà téléchargé les requins et n’ont donc pas besoin d’une option de téléchargement. Nous devrons d’une manière ou d’une autre évaluer combien d’instances de la classe Endangered existent déjà, puisque plus d’une instance indique que le téléchargement par lots a déjà eu lieu.

      Commençons par créer une méthode set_endangered private qui récupérera chaque instance de notre classe Endangered dans la base de données. Ajoutez le code suivant au fichier :

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      class EndangeredController < ApplicationController
        before_action :set_endangered, only: [:index, :data]
      
        def index
        end
      
        private
      
          def set_endangered
            @endangered = Endangered.all
          end
      
      end
      

      Notez que le filtre before_action fera en sorte que la valeur de @endangered ne soit définie que pour les routes index et data, qui seront les endroits où nous traiterons les données sur les requins menacés.

      Ensuite, ajoutez le code suivant à la méthode index afin de déterminer le chemin correct pour les utilisateurs qui visitent cette partie de l’application :

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      class EndangeredController < ApplicationController
        before_action :set_endangered, only: [:index, :data]
      
        def index          
          if @endangered.length > 0
            redirect_to endangered_data_path
          else
            render 'index'
          end
        end
      . . .
      

      S’il y a plus de 0 instance de notre classe Endangered, nous redirigerons les utilisateurs vers la route data, où ils pourront consulter des informations sur les requins qu’ils ont créés. Sinon, ils verront la vue index.

      Ensuite, sous la méthode index, ajoutez une méthode data, qui correspondra à une vue data :

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      . . .
        def index          
          if @endangered.length > 0
            redirect_to endangered_data_path
          else
            render 'index'
          end
        end
      
        def data
        end
      . . .
      

      Ensuite, nous ajouterons une méthode pour gérer le téléchargement des données lui-même. Nous appellerons cette méthode upload, et elle fera appel à une classe de travailleurs Sidekiq et à une méthode pour effectuer le téléchargement des données à partir du fichier CSV. Nous allons créer la définition de cette classe de travailleurs, AddEndangeredWorker, dans la prochaine étape.

      Pour l’instant, ajoutez le code suivant au fichier pour appeler le travailleur Sidekiq afin d’effectuer le téléchargement :

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      . . .
        def data
        end
      
        def upload
          csv_file = File.join Rails.root, 'db', 'sharks.csv'   
          AddEndangeredWorker.perform_async(csv_file)
          redirect_to endangered_data_path, notice: 'Endangered sharks have been uploaded!'
        end
      . . .
      

      En appelant la méthode perform_async sur la classe AddEndangeredWorker et en utilisant le fichier CSV comme argument, ce code garantit que les données du requin et le travail de téléchargement sont transmis à Redis. Les travailleurs de Sidekiq que nous mettrons en place surveilleront la file d’attente des travaux et réagiront lorsque de nouveaux travaux se présenteront.

      Après avoir appelé perform_async, notre méthode upload redirige vers le chemin data, où les utilisateurs pourront voir les requins téléchargés.

      Ensuite, nous ajouterons une méthode destroy pour détruire les données. Ajoutez le code suivant sous la méthode upload :

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      . . .
        def upload
          csv_file = File.join Rails.root, 'db', 'sharks.csv'   
          AddEndangeredWorker.perform_async(csv_file)
          redirect_to endangered_data_path, notice: 'Endangered sharks have been uploaded!'
        end
      
        def destroy
          RemoveEndangeredWorker.perform_async
          redirect_to root_path
        end
      . . .
      

      Comme notre méthode upload, notre méthode destroy comprend un appel à perform_async sur une classe RemoveEndangeredWorker – l’autre travailleur Sidekiq que nous allons créer. Après avoir appelé cette méthode, elle redirige les utilisateurs vers le chemin root de l’application.

      Le fichier terminé ressemblera à ceci :

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      class EndangeredController < ApplicationController
        before_action :set_endangered, only: [:index, :data]
      
        def index          
          if @endangered.length > 0
            redirect_to endangered_data_path
          else
            render 'index'
          end
        end
      
        def data
        end
      
        def upload
          csv_file = File.join Rails.root, 'db', 'sharks.csv'   
          AddEndangeredWorker.perform_async(csv_file)
          redirect_to endangered_data_path, notice: 'Endangered sharks have been uploaded!'
        end
      
        def destroy
          RemoveEndangeredWorker.perform_async
          redirect_to root_path
        end
      
        private
      
          def set_endangered
            @endangered = Endangered.all
          end
      
      end
      

      Enregistrez et fermez le fichier lorsque vous avez terminé de le modifier.

      Pour terminer la consolidation des routes de notre application, nous allons modifier le code dans config/routes.rb, le fichier où se trouvent nos déclarations de routes.

      Maintenant, ouvrez ce fichier :

      Actuellement, le fichier ressemble à ceci :

      ~/rails-sidekiq/config/routes.rb

      Rails.application.routes.draw do
        get 'endangered/index'
        get 'home/index'
        resources :sharks do
                resources :posts
        end
        root 'home#index'
        # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html
      end
      

      Nous devrons mettre à jour le fichier pour inclure les routes que nous avons définies dans notre contrôleur : data, upload et destroy. Notre route data correspondra à une requête GET pour récupérer les données sur les requins, tandis que nos itinéraires upload et destroy redirigeront vers des requêtes POST qui téléchargeront et détruiront ces données.

      Ajoutez le code suivant au fichier pour définir ces routes :

      ~/rails-sidekiq/config/routes.rb

      Rails.application.routes.draw do
        get 'endangered/index'
        get 'endangered/data', to: 'endangered#data'
        post 'endangered/upload', to: 'endangered#upload'
        post 'endangered/destroy', to: 'endangered#destroy'
        get 'home/index'
        resources :sharks do
                resources :posts
        end
        root 'home#index'
        # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html
      end
      

      Enregistrez et fermez le fichier lorsque vous avez terminé de le modifier.

      Maintenant que vous avez mis en place votre modèle Endangered et votre contrôleur, vous pouvez passer à l’étape de définition des classes de travailleurs Sidekiq.

      Étape 3 – Définition des travailleurs Sidekiq

      Nous avons appelé des méthodes perform_async sur nos travailleurs Sidekiq dans notre contrôleur, mais nous devons encore créer les travailleurs eux-mêmes.

      Tout d’abord, créez un répertoire workers pour les travailleurs :

      Ouvrez un fichier pour le travailleur AddEndangeredWorker :

      • nano app/workers/add_endangered_worker.rb

      Dans ce fichier, nous ajouterons un code qui nous permettra de travailler avec les données dans notre fichier CSV. Premièrement, ajoutez du code au fichier qui créera la classe, incluez la bibliothèque CSV Ruby et assurez-vous que cette classe fonctionne comme un travailleur Sidekiq :

      ~/rails-sidekiq/app/workers/add_endangered_worker.rb

      class AddEndangeredWorker
        require 'csv'
        include Sidekiq::Worker
        sidekiq_options retry: false
      
      end
      

      Nous incluons également l’option retry: false pour nous assurer que Sidekiq ne réessaie pas de relancer le téléchargement si celui-ci échoue.

      Ensuite, ajoutez le code pour la fonction perform :

      ~/rails-sidekiq/app/workers/add_endangered_worker.rb

      class AddEndangeredWorker
        require 'csv'
        include Sidekiq::Worker
        sidekiq_options retry: false
      
        def perform(csv_file)
          CSV.foreach(csv_file, headers: true) do |shark|
          Endangered.create(name: shark[0], iucn: shark[1])
        end
       end
      
      end
      

      La méthode perform reçoit des arguments de la méthode perform_async définie dans le contrôleur, il est donc important que les valeurs d’argument correspondent. Ici, nous transmettons csv_file, la variable que nous avons définie dans le contrôleur, et nous utilisons la méthode foreach à partir de la bibliothèque CSV pour lire les valeurs dans le fichier. Définir headers:true pour cette boucle vous garantit que la première ligne du fichier sera traitée comme une ligne d’en-têtes.

      Le bloc lit ensuite les valeurs du fichier dans les colonnes que nous avons définies pour notre modèle Endangered : name et iucn. Exécuter cette boucle créera des instances Endangered pour chacune des entrées dans notre fichier CSV.

      Une fois que vous avez terminé de le modifier, enregistrez et fermez le fichier.

      Ensuite, nous allons créer un travailleur pour gérer la suppression de ces données. Ouvrez un fichier pour la classe RemoveEndangeredWorker :

      • nano app/workers/remove_endangered_worker.rb

      Ajoutez le code pour définir la classe, et pour vous assurer qu’il utilise la bibliothèque CSV et fonctionne comme un travailler Sidekiq :

      ~/rails-sidekiq/app/workers/remove_endangered_worker.rb

      class RemoveEndangeredWorker
        include Sidekiq::Worker
        sidekiq_options retry: false
      
      end
      

      Ensuite, ajoutez une méthode perform pour gérer la destruction des données sur les requins menacés :

      ~/rails-sidekiq/app/workers/remove_endangered_worker.rb

      class RemoveEndangeredWorker
        include Sidekiq::Worker
        sidekiq_options retry: false
      
        def perform
          Endangered.destroy_all
        end
      
      end
      

      La méthode perform appelle destroy_all sur la classe Endangered, elle supprimera toutes les instances de cette classe de la base de données.

      Enregistrez et fermez le fichier lorsque vous avez terminé de le modifier.

      Une fois vos travailleurs en place, vous pouvez passer à la création d’une mise en page pour vos vues endangered, et de modèles pour vos vues index et data, afin que les utilisateurs puissent télécharger et visualiser les requins menacés.

      Étape 4 – Ajout de mises en page et de modèles de vues

      Pour que les utilisateurs puissent profiter de leurs informations sur les requins menacés, nous devrons nous occuper de deux choses : la présentation des vues définies dans notre contrôleur endangered, et les modèles de vue pour les vues index et data.

      Actuellement, notre application utilise une mise en page pour l’ensemble de l’application, située à l’adresse app/views/layouts/application.html.erb, un fichier partiel pour la navigation et une mise en page pour les vues sharks. La mise en page de l’application vérifie la présence d’un bloc de contenu, ce qui nous permet de charger différentes mises en page en fonction de la partie de l’application à laquelle notre utilisateur s’intéresse : pour la page home index, il verra une mise en page, et pour toute vue relative à un requin en particulier, il en verra une autre.

      Nous pouvons réadapter la mise en page sharks à nos vues endangered, car ce format permettra également de présenter les données sur les requins en vrac.

      Copiez le fichier de configuration sharks pour créer une mise en page endangered :

      • cp app/views/layouts/sharks.html.erb app/views/layouts/endangered.html.erb

      Ensuite, nous allons travailler à créer les modèles de vue pour nos vues index et data.

      Ouvrez le modèle index en premier :

      • nano app/views/endangered/index.html.erb

      Supprimez le code standard et ajoutez à la place le code suivant, qui donnera aux utilisateurs des informations générales sur les catégories menacées et leur offrira la possibilité de télécharger des informations sur les requins menacés :

      ~/rails-sidekiq/app/views/endangered/index.html.erb

      <p id="notice"><%= notice %></p>
      
      <h1>Endangered Sharks</h1>
      
      <p>International Union for Conservation of Nature (ICUN) statuses: <b>vu:</b> Vulnerable, <b>en:</b> Endangered, <b>cr:</b> Critically Endangered </p>
      
      <br>
      
        <%= form_tag endangered_upload_path do %>
        <%= submit_tag "Import Endangered Sharks" %>
        <% end %>
      
        <br>
      
      <%= link_to 'New Shark', new_shark_path, :class => "btn btn-primary btn-sm" %> <%= link_to 'Home', home_index_path, :class => "btn btn-primary btn-sm" %>
      

      Un form_tag rend possible le téléchargement de données en pointant une action post sur endangered_upload_path – la route que nous avons définie pour nos téléchargements. Un bouton créé avec submit_tag invite les utilisateurs à "Import Endangered Sharks" (Importer les requins menacés).

      En plus de ce code, nous avons inclus quelques informations générales sur les codes ICUN, afin que les utilisateurs puissent interpréter les données qu’ils verront.

      Enregistrez et fermez le fichier lorsque vous avez terminé de le modifier.

      Ensuite, ouvrez un fichier pour la vue data :

      • nano app/views/endangered/data.html.erb

      Ajoutez le code suivant, qui ajoutera un tableau avec les données sur les requins menacés :

      ~/rails-sidekiq/app/views/endangered/data.html.erb

      <p id="notice"><%= notice %></p>
      
      <h1>Endangered Sharks</h1>
      
      <p>International Union for Conservation of Nature (ICUN) statuses: <b>vu:</b> Vulnerable, <b>en:</b> Endangered, <b>cr:</b> Critically Endangered </p>
      
      <div class="table-responsive">
      <table class="table table-striped table-dark">
        <thead>
          <tr>
            <th>Name</th>
            <th>IUCN Status</th>
            <th colspan="3"></th>
          </tr>
        </thead>
      
        <tbody>
          <% @endangered.each do |shark| %>
            <tr>
              <td><%= shark.name %></td>
              <td><%= shark.iucn %></td>
            </tr>
          <% end %>
        </tbody>
      </table>
      </div>
      
      <br>
      
        <%= form_tag endangered_destroy_path do %>
        <%= submit_tag "Delete Endangered Sharks" %>
        <% end %>
      
        <br>
      
      <%= link_to 'New Shark', new_shark_path, :class => "btn btn-primary btn-sm" %> <%= link_to 'Home', home_index_path, :class => "btn btn-primary btn-sm" %>
      

      Ce code comprend les codes de statut ICUN, une fois de plus, et un tableau Bootstrap pour les données produites. En bouclant notre variable @endangered, nous affichons le nom et le statut ICUN de chaque requin dans le tableau.

      Sous le tableau, nous avons un autre ensemble de form_tags et de submit_tags, qui s’affichent sur le chemin destroy en offrant aux utilisateurs la possibilité de "Delete Endangered Sharks" (Supprimer les requins menacés).

      Enregistrez et fermez le fichier lorsque vous avez terminé de le modifier.

      La dernière modification que nous apporterons à nos vues sera dans la vue index associée à notre contrôleur home. Vous vous souvenez peut-être que cette vue est définie comme la racine de l’application dans le fichier config/routes.rb.

      Ouvrez ce fichier pour le modifier :

      • nano app/views/home/index.html.erb

      Trouvez la colonne dans la ligne qui indique Sharks are ancient (les requins sont anciens) :

      ~/rails-sidekiq/app/views/home/index.html.erb

      . . .
              <div class="col-lg-6">
                  <h3>Sharks are ancient</h3>
                  <p>There is evidence to suggest that sharks lived up to 400 million years ago.
                  </p>
              </div>
          </div>
      </div>
      

      Ajoutez le code suivant au fichier :

      ~/rails-sidekiq/app/views/home/index.html.erb

      . . .
              <div class="col-lg-6">
                  <h3>Sharks are ancient and SOME are in danger</h3>
                  <p>There is evidence to suggest that sharks lived up to 400 million years ago. Without our help, some could disappear soon.</p>
                  <p><%= button_to 'Which Sharks Are in Danger?', endangered_index_path, :method => :get,  :class => "btn btn-primary btn-sm"%>
                  </p>
              </div>
          </div>
      </div>
      

      Nous avons inclus un appel à l’action pour que les utilisateurs en apprennent davantage sur les requins menacés, en partageant d’abord un message fort, puis en ajoutant un assistant button_to qui soumet une requête GET à notre route endangered index, donnant aux utilisateurs l’accès à cette partie de l’application. À partir de là, ils pourront télécharger et visualiser les informations sur les requins menacés.

      Enregistrez et fermez le fichier lorsque vous avez terminé de le modifier.

      Avec votre code en place, vous êtes prêt à démarrer l’application et à télécharger quelques requins vers le serveur !

      Étape 5 – Démarrage de Sidekiq et test de l’application

      Avant de démarrer l’application, nous devrons gérer les migrations sur notre base de données et démarrer Sidekiq pour activer nos travailleurs. Redis devrait déjà être en marche sur le serveur, mais nous pouvons vérifier pour en être sûr. Avec tout cela, nous serons prêts à tester l’application.

      D’abord, vérifiez que Redis fonctionne :

      Vous devriez voir une sortie similaire à la suivante :

      Output

      ● redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-11-12 20:37:13 UTC; 1 weeks 0 days ago

      Ensuite, exécutez vos migrations de base de données :

      Vous pouvez maintenant démarrer Sidekiq dans le contexte de notre bundle de projet actuel en utilisant la commande bundle exec sidekiq :

      Vous verrez une sortie comme ceci, vous indiquant que Sidekiq est prêt à traiter les travaux :

      Output

      m, `$b .ss, $$: .,d$ `$$P,d$P' .,md$P"' ,$$$$$b/md$$$P^' .d$$$$$$/$$$P' $$^' `"/$$$' ____ _ _ _ _ $: ,$$: / ___|(_) __| | ___| | _(_) __ _ `b :$$ ___ | |/ _` |/ _ |/ / |/ _` | $$: ___) | | (_| | __/ <| | (_| | $$ |____/|_|__,_|___|_|__|__, | .d$$ |_| 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: Running in ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: See LICENSE and the LGPL-3.0 for licensing details. 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: Upgrade to Sidekiq Pro for more features and support: http://sidekiq.org 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: Booting Sidekiq 6.0.3 with redis options {:id=>"Sidekiq-server-PID-17621", :url=>nil} 2019-11-19T21:43:00.543Z pid=17621 tid=gpiqiesdl INFO: Starting processing, hit Ctrl-C to stop

      Ouvrez une deuxième fenêtre de terminal, naviguez vers le répertoire rails-sidekiq, et démarrez votre serveur d’application.

      Si vous exécutez l’application localement, utilisez la commande suivante :

      Si vous travaillez avec un serveur de développement, exécutez ce qui suit :

      • bundle exec rails s --binding=your_server_ip

      Naviguez vers localhost:3000 ou http://your_server_ip:3000 dans le navigateur. Vous verrez la page d’accueil suivante :

      Accueil Sidekiq App

      Cliquez sur le bouton Which Sharks Are in Danger?​​​​​​ (Quels sont les requins menacés ?) . Comme vous n’avez pas téléchargé de requin menacé, cela vous amènera à la vue endangered index :

      Vue Endangered Index

      Cliquez sur Import Endangered Sharks​​​ (​​Importer des requins menacés) pour importer les requins. Vous verrez un message vous indiquant que les requins ont été importés :

      Commencer l'importation

      Vous verrez également le début de l’importation. Rafraîchissez votre page pour voir le tableau complet :

      Rafraîchir le tableau

      Grâce à Sidekiq, notre important téléchargement par lots de requins menacés a réussi sans verrouiller le navigateur ni interférer avec les autres fonctionnalités de l’application.

      Cliquez sur le bouton Home (Accueil) en bas de la page, ce qui vous ramènera à la page principale de l’application :

      Accueil Sidekiq App

      De là, cliquez à nouveau sur Which Sharks Are in Danger? . Cela vous amènera maintenant directement à la vue data, puisque vous avez déjà téléchargé les requins.

      Pour tester la fonctionnalité de suppression, cliquez sur le bouton Delete Endangered Sharks (Supprimer les requins menacés) sous le tableau. Vous devriez être redirigé vers la page d’accueil de l’application une fois encore. Cliquez sur Which Sharks Are in Danger?​​​​​ une dernière fois vous renverra à la vue index, où vous aurez la possibilité de télécharger à nouveau des requins :

      Vue Endangered Index

      Votre application fonctionne maintenant avec les travailleurs Sidekiq en place, qui sont prêts à traiter les travaux et à s’assurer que les utilisateurs ont une bonne expérience en travaillant avec votre application.

      Conclusion

      Vous disposez désormais d’une application Rails fonctionnelle avec Sidekiq activé, ce qui vous permettra de décharger des opérations coûteuses dans une file d’attente de travail gérée par Sidekiq et soutenue par Redis. Cela vous permettra d’améliorer la vitesse et la fonctionnalité de votre site au fur et à mesure de son développement.

      Si vous souhaitez en savoir plus sur Sidekiq, les documents sont un bon point de départ.

      Pour en savoir plus sur Redis, consultez notre bibliothèque de ressources Redis. Vous pouvez également en savoir plus sur le fonctionnement d’un cluster Redis géré sur DigitalOcean en consultant la documentation du produit.



      Source link