Je vous proposes à travers une série d’articles, de suivre la création d’un projet Open Source, tel qu’il se présente le plus souvent.

Ce projet entrera t’il dans le Top 10 ou dans l’oubli ?

A ce stade, il est difficile de le savoir mais toute aventure apporte son lot d’incertitudes.

Je réaliserais en quelques jours (je l’espère), une plate-forme de génération d’Urls Courtes.

Toutes les phases du projets, jusqu’à la mise en service de l’application, seront décrites dans une série d’articles.

Ma démarche à plusieurs objectifs:

  • Vous donner un aperçu de la façon dont naissent beaucoup de projets Open Source.
  • Faire une démonstration de mes méthodes dans la réalisation d’une application.
  • Démontrer, ce que l’Open Source peut vous apporter.

Expression des besoins:

  • J’ai des sites qui exposent des urls externes, liés à des contrats d’affiliation.
  • Ces affiliations sont payés au clic.
  • Un dashboard est mis à disposition des affiliés par le fournisseur.
  • Mes sites sont construits à partir de fichiers Markdown sur Pelican comme ce blog.
  • Les fichiers Markdown sont générés à partir de données stockés dans MongoDB.

Voilà en résumé, ce qui va être le déclencheur du projet.

Ce qu’il me manque dans la situation actuelle:

  • De vérifier que le fournisseur de liens, comptabilise correctement les clics.
  • D’avoir des statistiques plus précises dans un format exploitable (json/xml).
  • De masquer mon identifiant d’affilié qui se trouve dans toutes les urls du site.

1. Recherche d’une solution existante sous forme de service gratuit ou payant:

Je commences toujours pas faire le tour des solutions existantes, même quand elles sont payantes.

Des services comme, Goo.gl, Bit.ly et TinyURL fournissent des API qui pourraient répondre à mes besoins.

Par contre, ils définissent des limites d’utilisations qui pourraient me gêner selon le volume d’url à générer.

Entre les limites d’utilisations et les performances d’un service distant, je pense qu’aucun de ces services ne répondra mes besoins qui sont, en premier lieu, de pouvoir générer plusieurs milliers de liens en quelques minutes.

La solution que je cherches, pourra être réutilisé par d’autres, je m’oriente donc, de préférence vers un produit qu’il est possible d’héberger soi-même.

2 - Recherche d’une solution Open Source:

Je cherches dans mon langage de prédilection (Python) pour garder la possibilité de corriger, d’améliorer ou de forker le projet.

  • https://github.com/ellisonleao/pyshorteners

    • Projets à jour et populaire (149 stars, 8 contributeurs)
    • C’est une api d’accès à des services d’url courtes comme Goo.gl
    • Ne correspond pas
  • https://github.com/Alir3z4/python-short_url

    • Projets à jour et suffisament populaire (73 stars, 4 contributeurs)
    • Bonnes pratiques: Travis, Gestion des numéros de version
    • Code testé mais sans afficher le taux de couverture
    • Peu de documentation et le site ne fonctionne pas
    • Ne correspond pas
  • https://github.com/lepture/flask-shorturl

    • Projet de Hsiaoming Yang, Auteur de plusieurs projets utilisés pour le Python/Flask
    • Une couverture de 93% par les tests
    • Pas de documentation
    • Le projet ne semble pas très actif
    • Pas d’utilisation de DB ou de cache
    • Ne correspond pas
  • https://github.com/pyr/url-shortener

    • Utilise Redis
    • Le dernier commit date du 15/04/2014
    • Pas de test
    • Ne correspond pas
  • https://github.com/narenaryan/Pyster

    • Projet récent, dernier commit le 23/02/2017
    • Pas de test
    • Pas de documentation
    • Utilisation en dur de sqlite3 au lieu d’un ORM comme Peewee
    • Ne correspond pas

Il existe beaucoup d’autres projets, en particulier sur Django mais je ne peux pas prendre le temps de tous les parcourir. A priori, aucun projet ne semble avoir réussi à percer dans ce domaine. Espérons que ce ne sera pas mon cas.

3. A priori, rien ne répond à 80% de mes besoins, je développes ma solution:

J’appliques souvent cette règle des 80/20, car l’énergie nécessaire aux développements d’une solution maison puis à son suivi, est considérable. Si un projet répond à 80% de mes besoins, il est inutile de réinventer la route.

Mais pourquoi développer cette solution en Open Source ?

Effectivement, en Open Source, le travail va me demander plus de rigueur car d’autres développeurs vont juger la qualité technique mes réalisations et que je n’ai aucune envie de me ridiculiser.

C’est justement l’une des valeurs que peut ajouter l’Open Source à un projet: son exposition publique et sa transparence.

Et puis nous sommes tous à la recherche de reconnaissance, non ?

Mon organisation:

  • Je trouves un nom au projet car c’est à mon sens, la base indispensable.

  • Je commences par définir les fonctionnalités d’une première version light pour me concentrer sur l’essentiel, ce qui est l’une des particularités des développeurs Open Source, du pragmatisme, du sens pratique et peu de fioriture.

  • Je définis les contraintes et difficultés qu’il va falloir gérer. Avec l’expérience, il devient plus facile de les déterminer à l’avance.

  • Je choisis les technologies et l’architecture de départ.

  • Je créer la structure du projet python. Un copier/coller d’un de mes projets, car l’on m’a appris très tôt qu’un bon informaticien est un bon fainéant.

  • Je créer un dépôt Github, privé dans un premier temps.

  • Je place dans une TodoList, les idées d’évolution et de fonctionnalités avancés qui me viennent à l’esprit sur le moment et que j’alimenterais pendant le développement du projet.

  • Je prend en compte, la possibilité de commercialisation d’un service autour de cette solution.

Passons à la pratique:

Le choix d’un nom en Anglais pour un projet, lui donne une dimension internationale.

Le nom du projet sera: url-shortener

  • 1ère étape, ce nom n’était pas l’idée de départ car je prévoyais plutôt mongo-shortener. C’était une mauvaise idée car je fermais le projet aux possibilités d’être étendu dans l’avenir, à d’autres solutions NoSQL ou SQL, ce qui poserait un problème d’identité au projet.

  • 2ème étape, comme il s’agit d’un projet Python, je vérifie que ce nom n’est pas déjà utilisé avec une recherche sur pypi et la commande pip show url-shortener.

  • 3ème étape, la recherche d’un nom de domaine disponible, qui soit si possible, identique au nom du projet.

Je fais une recherche multiple sur Gandi en créant plusieurs variantes de url-shortener, en inversant les mots, avec ou sans le - de séparation.

Si vous vous demandez, pourquoi une recherche en .io, l’explication se trouve sur Wikipédia.

url-short.io
shortener-url.io
urlshort.io
**shorturl.io**
**url-shortener.io**
short-url.io
shortenerurl.io
urlshortener.io

Le résultat est qu’ils sont tous libres sauf:

  • shorturl.io
  • url-shortener.io

Les sites correspondants à ces Urls ne semblent pas en ligne.

  • 4ème étape, avant le choix du nom de domaine, je veux m’assurer du nombre de résultat qu’il renvoi dans une recherche Google.

Je fais la recherche pour chacun, sans l’extension .io et en remplaçant le - par un espace, car les composantes d’un nom de domaine, peuvent devenir des mots clés pour le référencement.

url-short.io
    Search: url short
    Résultats: 43 700 000 dont le service de Google en 1er (https://goo.gl/)

shortener-url:
    Search: shortener url
    Résultats: 567 000 avec toujours les mêmes ténor en 1ère position

...
A peu prêt les mêmes résultats pour chaque domaine sauf le suivant:
...

shortenerurl:
    Search: shortenerurl
    Résultats: 51 500

Bon, au final, je dois reprendre du début car:

  • Dès que short et url se trouvent dans une recherche, je ferais toujours face à la concurrence de Google.

  • Il faudrait plutôt se baser sur les mots clés utilisés par ceux qui recherches une telle solution mais c’est une tâche difficile et incertaine.

Comme j’ai hâte de développer, j’arrête de passer trop de temps sur ce sujet et je choisi finalement shortener-url.io.

Pour faire connaître le projet, je compterais sur les réseaux sociaux, les échanges de liens et la communauté Open Source.

Nouveau nom du projet: shortener-url

J’en vois déjà qui sont prêt à courir acheter le domaine shortener-url.io avant moi mais il est trop tard, je l’ai fait avant la fin de ce chapitre.

Définir les fonctionnalités d’une première version:

  • Api REST Json pour délivrer rapidement une url Short ou plusieurs dans la même requête.
  • Demande d’url par Formulaire.
  • Service de redirection à partir des urls shorts.
  • Gestion des urls par son propriétaire.
  • Accès administrateurs à toutes les urls

Contraintes et difficultés à gérer:

  • Définir correctement les indexes Mongodb
  • Utiliser provisoirement Flask-Cache pour un cache en RAM
  • L’Api REST nécessite une authentification par clé, dans l’url et une formulaire de création de cette clé
  • Le service de redirection doit être très rapide pour charger l’url correspondante à partir de la DB, il faudra utiliser un cache Redis.
  • Il faut sécuriser les formulaires avec un CAPTCHA
  • L’interface d’administration des Urls nécessite une authentification. Commencer avec une authentification social Github
  • Attention au Referer car la plate-forme de redirection devient la source de tous les liens

Choix des technologies de départ:

  • MongoDB
  • Python 3.4
  • Flask
  • Gevent
  • Bootstrap/Jquery
  • Hébergement OVH soyoustart

Création de la structure du projet python:

shortener-url/
.... shortener_url/
........ __init__.py
........ tests/
............ __init__.py
.... docs/
.... .gitignore
.... .travis.yml
.... MANIFEST.in            
.... setup.py       
.... setup.cfg
.... README.md
.... requirements.txt
.... Dockerfile

Création d’une TodoList:

Fonctionnalités à venir:

  • Chargement en cache des liens les plus souvent utilisés
  • Collecte d’information sur l’utilisateur d’une url (Ip, Geoip, UserAgent)
  • Agrégation des données collectés
  • API d’accès aux données statistiques collectés
  • Dashboard avec les statistiques d’utilisation des urls shorts
  • Vérification des liens pour éviter d’avoir trop de lien mort et signalement de ces liens à leurs propriétaires.
  • Envoi de rapports périodiques par mail aux propriétaires des liens
  • L’Api doit utiliser des X-Rate-Limit
  • Servir l’api sur un serveur différent
  • Cluster ou Shards MongoDB

Possibilité de commercialisation:

  • Étude des tarifs déjà pratiqués par la concurrence.
  • Évaluer le coût d’une version gratuite, limité en nombre d’url.

Conclusions:

  • Le projet est définit et lancé
  • Le développement commence dès demain

Suite du projet, jour par jour:

Stéphane RAULT


Commentaires

comments powered by Disqus