Revue de presse Inno #7

Mobile

Protocoles génériques et Type Erasure en Swift

Avec Swift, vous pouvez définir des protocoles en leur associant un ou plusieurs types génériques. Ces types sont définis en utilisant le mot-clé « associatedtype ».  L’appellation « type générique » est un peu usurpée ici, nous devrions plutôt parler d’un espace réservé pour un type inconnu. En effet, nous verrons que de tels protocoles n’offrent pas une grande souplesse d’utilisation lorsqu’il s’agit de réellement les considérer comme génériques.
En savoir plus :

Développement Web

Django 2.0 Release Candidate désormais disponible

Par Kévin Barralon

Le framework Django dont la prochaine version 2.0 est prévue autour du 1er décembre vient de publier sa version Candidate ce jeudi 15 novembre. Contrairement à ce que l’on pourrait penser, cette nouvelle version ne va pas apporter d’incompatibilités majeures au sein du framework. Les changements seront donc du même acabit que les versions précédentes.

Cependant, le changement important de cette version 2 sera l’incompatibilité avec Python 2.7, dont la fin du support est programmée pour 2020. Django 2.0 supportera donc au minimum la version 3.4, même s’il est chaudement recommandé de passer directement à la dernière version de Python (3.6 actuellement).

Routage d’URL

Au niveau des nouveautés, la nouvelle fonction django.urls.path() rend la syntaxe du routage des URL beaucoup plus simple et lisible. Ainsi, au lieu d’écrire : url(r'^articles/(?P[0-9]{4})/$', views.year_archive)

vous pourrez écrire : path('articles/<int:year>/', views.year_archive)

Cette nouvelle syntaxe permettra également de recevoir dans la vue (views) les arguments avec le typage défini (un nombre entier dans le cas de year au lieu d’une string).

Dans cet exemple, il n’y a toutefois pas de possibilité d’ajouter une contrainte (une année à 4 chiffres dans notre exemple). Pour cela, la fonction actuelle django.conf.urls.url() sera remplacée par django.urls.re_path(), qui permettra de conserver la possibilité de mettre des expressions régulières dans la définition de l’URL.

La fonction django.conf.urls.include() sera également directement disponible via django.urls. Pour pourrez ainsi importer vos modules de la manière suivante from django.urls import include, path.

Autres nouveautés

  • Pour les autres nouveautés : L’admin de Django 2.0 sera désormais responsive, donc adapté aux appareils mobiles.
  • Une nouvelle classe Window a été ajoutée afin de permettre l’utilisation du mot-clé OVER dans les requêtes SQL.
  • Une liste de tous les ajouts mineurs est disponible dans le communiqué officiel.
En savoir plus :

Déployer des services entiers avec Docker Swarm et Gitlab CI

Chez Savoir-faire Linux, je travaille (entre autres) sur l’infrastructure de déploiement pour plusieurs services que l’on héberge, et je suis toujours à l’affût de méthodes innovantes pour améliorer notre pratique DevOps. Présentement, le système de déploiement est axé autour de l’utilisation de Ansible pour « provisioner » un service dans une machine virtuelle, et l’ajuster au besoin après. Mais pour améliorer la stabilité de nos builds, de déploiements et l’agilité avec laquelle on peut faire des déploiements en continu, nous regardons d’autres approches DevOps, comme l’utilisation des containeurs Docker hébergés dans un Registry et déployés par un outil comme Gitlab CI.
Parmi les outils disponibles pour déployer une architecture de « microservice » (créée avec docker-compose), nous trouvons Docker Swarm. En utilisant un certain nombre de serveurs proprement configuré, on peut déployer un « stack » de containeurs avec un simple docker stack deploy. Docker va choisir par la suite la meilleure configuration pour le déploiement des différents containeurs à travers l’infrastructure du Swarm. Il va même aller jusqu’à configurer la réseautique entre les containeurs automatiquement, comme si tu utilisais docker-compose sur un ordinateur en local.
 
La meilleure partie, c’est le fait que ça marche bien avec notre système d’automatisation des builds déjà existant, GitLab CI. Nous pouvons faire le pipeline « build – test – release – deploy » à travers toute notre infrastructure avec GitLab CI et le GitLab Container Registry. Il y a toujours des parties casse-têtes à régler, mais ce système représente déjà un grand bond vers l’avant pour la simplicité et l’efficacité de notre pratique DevOps.
En savoir plus :

Publié par

Savoir-faire Linux

Savoir-faire Linux est le chef de file de l’informatique à code ouvert sous licence libre au Québec et au Canada. Moteur d’une économie nouvelle fondée sur le savoir, Savoir-faire Linux développe depuis 1999 une expertise exceptionnelle qu’elle met au service des entreprises et des organisations publiques afin de répondre aux défis d’évolution de leurs systèmes d’information.
Forte d’une équipe multidisciplinaire de plus de 145 experts de 24 nationalités différentes dans 5 villes et sur 2 continents, Savoir-faire Linux fournit des services à plus de 500 organisations à travers le monde.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *