ZEP-38 : mise en place d'un raccoucisseur d'URL

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet
Cartouche
ZEP 38
Titre Mise en place d'un raccourcisseur d'URL
Révision 1
Date de création 26 décembre 2015
Dernière révision 26 décembre 2015
Type Feature
Statut Rédaction

Problème

Cette ZEP concerne les URLs des articles, des tutoriels et des sujets sur le forum. Par exemple :

Vous remarquez que ce n'est pas très élégant à publier sur les réseau sociaux.

Solution au problème

Je propose de mettre en place un raccourcisseur d'URL qui génère des adresses raccourcies pour chaque article, tutoriel et sujet. Cette URL serait utilisée pour les boutons "Partager" dans le menu de gauche et, pour le forum qui ne possède pas de tels boutons, on pourrait l'insérer directement dans le menu.

Au final une adresse telle que zds.com/1fmO6Z1 (par exemple) pointerait vers un tutoriel tel que celui de Viki53 que j'ai cité plus haut. Ce serait quand même plus sympa à mettre dans un tweet :p .

Mise en œuvre technique

Pour le nom de domaine on a deux possibilités, soit on utilise le zestedesavoir.com, soit on en acquiert un plus court (je fais confiance à votre imagination) comme zds.com (je ne sais pas si il est disponible).

Pour le service de réduction d'URLs, on peut coder un script maison ou utiliser quelque chose de déjà fait comme YOURLS.

Voilà, dites-moi ce que vous en pensez.

Édité par Croal

hello, world !

+3 -2
Staff

Je suis totalement et définitivement contre. On ne devrait jamais utiliser de raccourcisseur d'URL tant qu'on y est pas contraint et forcé. Ce qui couvre 2 cas :

  1. Les URLs sur papier, parce que c'est plus simple à taper (cf ce que fait Canard PC avec cpc.cx)
  2. Les services qui imposent une limite forte de caractères (ex : Twitter).

Or, il se trouve que :

  1. C'est un cas à la marge, dont la résolution ne rentre pas dans les attributions de Zeste de Savoir.
  2. Aujourd'hui, tous les services du genre qui sont très utilisés raccourcissent eux-mêmes les URLs.

Pourquoi les URLs raccourcies ne doivent pas être utilisées tant que ce n'est pas indispensable ? La raison dépend du choix technologique utilisé pour raccourcir l'URL.

  • Utilisation d'un service externe : l'URL devient dépendante d'un tiers, qui peut fermer (c'est arrivé, même chez de très gros), tomber en panne, être lent à mourir, etc. Ça fait une redirection supplémentaire par raccourcisseur d'URL utilisé1, ce qui ralentit l'utilisateur, spécialement sur mobile. De plus, tous ces intermédiaires peuvent collecter des données sur l'utilisateur (et ne s'en privent généralement pas).
  • URL raccourcie interne : il faut gérer les URLs en double, ce qui peut vite devenir lourd et poser des problèmes de cohérence, de persistance dans le temps, et de duplication de contenu si un nom de domaine court est utilisé. Plus les coûts additionnel (NDD court = souvent cher, etc.)

  1. Car il y en a souvent plusieurs. Par exemple, Twitter utilise systématiquement le sien même si l'URL est déjà courte (PS : c'est pourquoi vous ne devez jamais utiliser d'URL déjà raccourcie avec Twitter). C'est aussi fréquent de voir des partages via raccourcisseurs d'URLs déjà raccourcies. 

Édité par SpaceFox

Merci pour cette proposition de cette ZEP.

Toutefois, je n'y suis pas très favorable. Le seul objectif de ce raccourcisseur d'URs serait de pouvoir partager sur les réseaux sociaux : ceux-ci ont proposent déjà tout un tas d'outils.

+0 -0
Staff

Alors je suis en partie d'accord avec SpaceFox mais j'aimerai rajouter quelques informations.

Utiliser un système externe c'est en être dépendant. Demain ce service ferme ou est hors ligne et les liens ne fonctionnent plus. Là SpaceFox a entièrement raison.

Ce qui est possible en revanche c'est faire quelque chose d'interne assez simple pour les contenus publiés avec le pk.

On pourrait avoir https://zestedesavoir/c/558 pour https://zestedesavoir.com/tutoriels/558/les-arbres-binaires-de-recherche-1/ ou encore https://zestedesavoir/f/4935 pour https://zestedesavoir.com/forums/sujet/4935/zep-38-mise-en-place-dun-raccoucisseur-durl. À réfléchir.

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0
Staff

Le pk est un identifiant unique pour chaque objet en Django. C'est une Primary Key.

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0
Staff
  • Utiliser un service externe est effectivement une mauvaise idée.
  • Intégrer un raccourciceur à ZdS me semble inutile.
  • Acheter un .com à 3 lettres n'est pas réaliste (on m'a fait une offre à 97'000$ pour un .com de 3 lettres il y a moins de 2 mois).
  • Avoir des URLs alternatives pour les contenus, plus courtes que les actuelles, me semble en revanche indispensable, et je suis pour une solution à base de routes telle que décrite par gustavi.

Je parle de JavaScript et d'autres trucs sur mon blog : https://draft.li/blog

+0 -0
Staff
Cartouche
ZEP 38
Titre Mise en place d'URL courtes
Révision 1
Date de création 26 décembre 2015
Dernière révision 21 janvier 2016
Type Feature
Statut Rédaction

Problème

Cette ZEP concerne toutes les URLs potentiellement longues. C'est à dire celles de tous les modèles présents et futurs. En effet, on se dirait volontiers "Ouais mais les pages de profiles feront pas des URLs de 12 pieds de long", mais la limite de longueur d'un username est de 150 caractères sur ZdS.

  • https://zestedesavoir.com/tutoriels/686/arduino-premiers-pas-en-informatique-embarquee/745_les-grandeurs-analogiques/3430_les-entrees-analogiques-de-larduino/#2-10725_les-convertisseurs-analogiques-numerique-ou-can
  • https://zestedesavoir.com/membres/voir/lorem-ipsum-dolor-sit-ameta-consectetur-adipiscing-elita-curabitur-aliquam-dui-orcia-at-ullamcorper-sapien-porttitor-nona-curabitur-varius-dui-nullama/

Vous remarquez que ce n'est pas très élégant à publier sur les réseau sociaux. Et c'est pas cool pour des raisons purement techniques, typiquement l'utilisation d'URLField (max 255) au lieu de TextFields pour stocker ces URLs en base de donnée.

Solution au problème

Je propose de mettre en place des routes "courtes" pour chaque route utilisant actuellement un slug.

Ces routes se passeront de slugs pour ne reposer que sur des PK.

Mise en œuvre technique

  1. Facile techniquement
  2. Peu de travail donc vite fait
  3. Sans grand risque
  4. C'est "gratuit" en terme de ressources serveur
  5. Ca permet d'économiser plein de ressources serveur (si on admet que la ZEP-24 utilise un TextField)

PS : Oui j'ai renommé cette ZEP. Si ça se fait pas, je veux bien ouvrir une nouvelle ZEP avec un plus joli numéro que 38. C'est banal, 38.

Je parle de JavaScript et d'autres trucs sur mon blog : https://draft.li/blog

+2 -0

Facile techniquement

C'est intégré à Django ? Ou faut écrire des routes mappées sur /{typeDeContenu}/{slugId} et lui faire renvoyer une 302;Location=...

(par pure curiosité technique)

Happiness is a warm puppy

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte