Journal J'avais envie de coder ce soir

Posté par (page perso) . Licence CC by-sa
14
21
sept.
2013

Et je voulais un petit truc qui se torcherait facilement, en une soirée.
Le but était de faire un truc le plus compact possible, déployable et migrable rapidement. Et éventuellement utile.

Un raccourcisseur d'URL m'est venu à l'esprit. Comme ça, pour le fun.

Les outils :
* pour le langage, Perl bien sûr, y pas mieux ;
* pour le framework, Mojolicious, c'est évident ;
* pour la tronche du truc, Twitter bootstrap (build custom pour plus de légèreté), parce que j'avais pas envie de réfléchir ;
* pour la base de données, SQLite, parce que j'avais pas envie de sortir un bazooka pour tuer une mouche ;
* enfin, Carton, un gestionnaire de dépendances pour Perl, qui permet d'installer toutes les dépendances qui vont bien en un tournemain.

Au final, il n'y a qu'un fichier qui contient toute l'application, grâce à Mojolicious::Lite qui permet de réunir les templates, le route dispatcher et l'intelligence de l'appli. Le seul autre fichier nécessaire, est le cpanfile qui indique à Carton quelles sont les dépendances. Et encore, il suffirait de regarder rapidement le code pour installer les dépendances à la main. Donc l'appli peut se réduire à un fichier.

Bref, je vous présente donc LSTU (pour Let's Shorten That Url). Il ne fait pas grand chose, mais il le fait bien.
On peut créer une url réduite via le formulaire de la page d'accueil ou en donnant son URL comme ceci :

http://lstu.fiat-tux.fr/a/http://linuxfr.org

Et puis on peut aller sur une URL réduite et se retrouver sur l'URL de destination.

C'est tout ! Je vous disais bien qu'il ne faisait pas grand chose :D

La base de données contient la date de création de l'URL réduite, ainsi que le nombre de fois où elle a été utilisée. Je sais pas trop si j'en ferais quelque chose, mais ça peut toujours servir pour des stats.

Pour ceux qui voudraient tester :
sudo cpan Carton
git clone https://github.com/ldidry/lstu.git
cd lstu
carton install
carton exec ./Lstu daemon -m production

Par défaut, ça écoute sur le port 3000, mais ça se change avec les options kivonbien (carton exec ./Lstu help).

Dépôt git chez moi (=> pour garder mes données chez moi)
Dépôt github (=> pour la visibilité et le système de tickets)
Instance chez moi (=> je sais que mon nom de domaine est un peu long et fait perdre l'intérêt d'un raccourcisseur d'URL, mais c'est du test, pis je suis pas sûr que ça vaille le coup d'investir dans un nom de domaine optimisé pour un truc dont je ne vais sans doute pas me servir)

Voilà, si vous avez des remarques, des questions, des demandes, toussa, je ne demande que ça !

  • # Zut, une typo !

    Posté par (page perso) . Évalué à 3.

    C'est pas LTSU mais LSTU. Qq'un peut corriger siouplait ?

    It's a fez. I wear a fez now. Fezes are cool !

  • # Engouement

    Posté par . Évalué à 10.

    Je n'ai jamais bien compris l'engouement concernant les réductions d'url ou plutôt le nombre de projets là dessus, wikipedia me dit ça :

    Au même titre que la compression de données, réduire une adresse web (URL) permet d'économiser plusieurs octets. Cela offre quelques avantages parmi lesquels:

    • diminuer la taille des requêtes HTTP, sous condition (pour l'appel des pages) que le service de réduction d'URL proposé soit propre au site web et qu'il ne s'agisse pas d'un service de redirection (comme le proposent TinyURL ou Google url shortener). En réduisant la taille des liens hypertexte d'une page web on allège la taille de la page à charger, notamment si elle en contient plusieurs. Ce service s'avère indispensable pour les abonnés d'un fournisseur d'accès à internet ou d'un opérateur mobile dont l'accès à internet est limité.

    Je ne vais pas cracher dessus, mais il vaudrait mieux avancer sur la compression des user-agent ou le groupement des en-têtes communs. Ou plutôt tout ce qui est indiqué dans cette dépêche. On y gagnerait surement un peu plus d'octets.

    • permettre l'échange d'une adresse Web dans des services de communication où le nombre de caractères par message est limité, comme dans les messageries instantanées ou les microblogs (tels que Twitter ou Identi.ca).

    Rien à redire ici.

    Je n'ai jamais vu quelqu'un s'en servir ainsi. Je ne connais personne qui soit rapidement capable de retenir http://osm.org/go/G0ke520. Au pire, si on est en train de consulter une page sur un téléphone et qu'on veut continuer sur une ordinateur ou une autre périphérique avec navigateur web.

    Je trouve que cela donne surtout un outil pour renvoyer vers des liens qu'on attend pas comme expliqué ici.

    Même pour le micro-blogging je ne suis pas tellement convaincu, entre les avantages que cela offre et l’inconvénient illustré ci-dessus.

    • [^] # Re: Engouement

      Posté par (page perso) . Évalué à 4.

      Il me semble que sur Twitter, l'utilisateur n'a pas besoin de raccourcir son URL, c'est fait automatiquement. Et en dehors du microblogging, je l'ai vu souvent utilisé comme un moyen d'obtenir des stats sur le nombre de clics.

      • [^] # Re: Engouement

        Posté par . Évalué à 0.

        'Il me semble que sur Twitter, l'utilisateur n'a pas besoin de raccourcir son URL, c'est fait automatiquement'
        Les url raccourcies par twitter sont plus longues que celles procurées par un vrai raccourcisseur d'url

        • [^] # Re: Engouement

          Posté par (page perso) . Évalué à 2.

          Les url raccourcies par twitter sont plus longues que celles procurées par un vrai raccourcisseur d'url

          Bah oui, ils sont obligés d'avoir 10 caractères dans le lien raccourci : ils doivent juste avoir une bdd bien remplie :) (avec 8 caractères, on atteint plus de 8 milliards de combinaisons, donc leur base doit être vraiment TRÈS bien remplie)

          It's a fez. I wear a fez now. Fezes are cool !

    • [^] # Re: Engouement

      Posté par . Évalué à 3.

      Des fois c'est rigolo pour cacher l'url.
      D'autres fois ça permet de savoir si quelqu'un a bien suivi l'url (certains services proposes de compter le nombre de fois que l'url est requêtée).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Engouement

      Posté par . Évalué à 7.

      Je ne connais personne qui soit rapidement capable de retenir http://osm.org/go/G0ke520.

      Non, mais il existe encore des journaux papiers qui contiennent quelquefois des liens vers un réseau de communication mondial. Il est mille fois plus simple d'ouvrir un navigateur et de recopier avec ses petits doigts: http://petitlien.fr/az et arriver au bon endroit plutôt que de recopier sans erreur http://www.openstreetmap.org/?lat=-27.1261&lon=-109.3503&zoom=13&layers=M.

      • [^] # Re: Engouement

        Posté par (page perso) . Évalué à 1.

        Oui mais c'est triste pour celui qui va trouver le journal (ou le livre) après l’arrêt du service tiers petitlien ou lstu.fiat-tux. Son URL ne mènera plus nulle part.

        • [^] # Re: Engouement

          Posté par (page perso) . Évalué à 1.

          indépendamment de ce cas, ces liens ont une durée de vie limitée, style quelques mois.

          If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

          • [^] # Re: Engouement

            Posté par (page perso) . Évalué à 4.

            Je suis pas trop sûr : si twitter et son t.co étaient limités dans le temps, ça foutrait bien le bordel vu qu'il raccourcit automatiquement toutes les URL.

            Je n'ai pas implémenté de telle limite car je trouve ça complètement useless et que ça foutrait la zone.

            Sinon, j'ai oublié de dire un truc : les mots-clés sont fait en random (non prédictibles donc) mais pour une même URL, je réutilise l'enregistrement existant. C'est con à dire comme ça, ça paraît évident, mais il fallait juste y penser pour éviter des enregistrements inutiles.
            Après, il y a plus de 8 milliards de combinaisons possibles, donc la limite est assez haute :) Problème : le temps de création prendra de plus en plus de temps au fur et à mesure du remplissage de la bdd :
            perl
            do {
            $short = give_me_a_random();
            } while (short_already_exists($short));

            Je me demande à partir de quand on risque de sentir un ralentissement.

            It's a fez. I wear a fez now. Fezes are cool !

            • [^] # Re: Engouement

              Posté par . Évalué à 0.

              Je crois qu'il ne parle pas de limite technique mais plutôt de pages qui n'ont plus d'intérêt après quelques mois.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Engouement

                Posté par (page perso) . Évalué à 1.

                Heu, mais c'est pareil dans les deux cas (intéressant, pas intéressant)..? Un lien qui ne mène nulle part, sans aucun moyen d'évaluer cet intérêt… :(

              • [^] # Re: Engouement

                Posté par (page perso) . Évalué à 3.

                Ah, parce que twitter a un intérêt ?

            • [^] # Re: Engouement

              Posté par . Évalué à 6.

              Je me demande à partir de quand on risque de sentir un ralentissement.

              Avec du matos moderne, tu peux estimer la performance d'un PNRG basé sur un XOR-shift ou une congruence linéaire à ~500M/s. Je te laisse faire le calcul d'à partir de quel taux de remplissage de l'espace tu passes plus de 100ms à générer des nombres.

              Après tu vas requêter ta BDD comme un bourrin pour voir si l'enregistrement existe, là ça va faire beaucoup plus mal et beaucoup beaucoup plus vite. En gardant une archi pourrie comme celle la, une technique est de minimiser le nombre de requêtes que tu vas faire pour vérifier si une URL existe déjà ou pas. Si tu as de la RAM avec un espace de 8G clés, utiliser un bitmap ça passe sans soucis. Mais tu peux faire un compris en utilisant des structures probabilistes à occupation mémoire sous linéaire. Soit de type set membership avec un bloom-filter, soit avec de la détection de doublon avec un Streaming Quotient Filter. Ca va vachement alléger le goulot qu'est la base.

              Après la conception reste pourrie pour faire un truc sérieux, le service est voué à se dégrader alors qu'on peut très bien faire du non prédictible sans brute-forcer de pleins de manière. La plus conne serait de faire un shuffle une bonne fois pour toute de ton espace de clé, et ensuite de consommer élément par élément. Ca coûte n log(n), soit rien pour 8G élément, une bonne fois pour toute et après c'est constant. Mais il y a 100 façons différentes de faire un truc propre.

              Après encore une fois, pondre un truc pour 2 utilisateurs ou 1 milliards c'est pas vraiment les mêmes objectifs dans la conception et la notion de "good enough"

              • [^] # Re: Engouement

                Posté par (page perso) . Évalué à 5.

                Ca coûte n log(n),

                Je ne sais pas vraiment ce que tu entends par « shuffle », mais mélanger une liste de nombre, cela est plutôt en O(n).

                A la louche

                int clef[] = { 0, 1, 2, ...}  // enfin tout l'espace
                
                for (int i=0 ; i < nbr_clefs-1 ; i++)
                 {
                   r = tire, au hasard, un nombre dans [i, nbr_clefs-1];
                   echange(clef[i], clef[r]);
                 }

                Cela ne fonctionne que pour un petit espace de clefs…

                • [^] # Re: Engouement

                  Posté par . Évalué à 2.

                  Je ne sais pas vraiment ce que tu entends par « shuffle », mais mélanger une liste de nombre, cela est plutôt en O(n).

                  Tout à fait. J'ai mis mon cerveau en court circuit faignant: sort -R ou équivalent

                  Cela ne fonctionne que pour un petit espace de clefs…

                  Bien sur la discussion n'était que rhétorique vu le projet. Par contre des points intéressants sont il me semble:

                  • Pour un projet comme ça, on s'en balance tout pétera avant
                  • Ça vaut quand même le coût de bien comprendre ses contraintes pour ne pas s'en mettre qui empêchent de faire des trucs simples qui juste marchent. Ici on dit clé non prédictible, ca vaut le coup de réfléchir à deux fois à ce que ça veut dire exactement avant de faire un random de goret: séquence non prédictible, correspondance URL -> URL courte, rapport à la requête de création etc. En levant une contrainte qui n'existe pas ca ouvre souvent pleins de portes pour avoir un design propre.
                  • Trouver des solutions simples face un problème due à une mauvaise solution (ici on pourra toujours sharder: quand ça ralenti on ajoute un nouvel espace de nom et c'est reparti)
                  • Outils à utilisation mémoire non linéaire pour éviter de frapper un service comme un bourrin quand on peut éviter >90% des appels inutiles contre quelques Ko/Mo/Go. Bien entendu ici c'est totalement hors sujet.
                  • [^] # Re: Engouement

                    Posté par . Évalué à 2.

                    séquence non prédictible

                    J'ai pas bien compris à quoi ça sert ça.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Engouement

          Posté par (page perso) . Évalué à 2.

          Oui mais c'est triste pour celui qui va trouver le journal (ou le livre) après l’arrêt du service tiers petitlien ou lstu.fiat-tux. Son URL ne mènera plus nulle part.

          C'est un vrai problème, je l'avoue. Mais y a plusieurs façons de se prémunir de ça :
          * y a qu'à utiliser un service trop gros pour tomber : bit.ly et consorts (ok, ça c'est moyen) ;
          * se reposer sur un tiers de confiance : le geek de service (allez, me faites pas croire que vous êtes le geek de service de personne), son FAI associatif, Framasoft, l'APRIL…
          * héberger son propre raccourcisseur (mais il n'y a que la personne qui gère le raccourcisseur qui est assuré d'avoir un service qui tourne).

          Perso, la 2ème solution me paraît la meilleure.

          Les raccoucisseurs peuvent être pratiques (twitter, sms, journal papier, raccourcir l'URL d'une vidéo de chatons, rickroller les gens), mais ils doivent être consommés avec modération. Faut juste apprendre aux gens à s'en servir correctement.

          It's a fez. I wear a fez now. Fezes are cool !

    • [^] # Re: Engouement

      Posté par (page perso) . Évalué à 3.

      Je n'ai jamais vu quelqu'un s'en servir ainsi. Je ne connais
      personne qui soit rapidement capable de retenir http://osm.org/go/G0ke520.
      Au pire, si on est en train de consulter une page sur un
      téléphone et qu'on veut continuer sur une ordinateur ou une
      autre périphérique avec navigateur web.

      Dans ce cas la, non.
      Par contre, il existe des systèmes ou tu peux choisir l'url, ce qui du coup permet d'avoir http://ti.ny/fete_2013 , et ce genre de choses plus facile à retenir.

      Mais en général, c'est des trucs "internes". Dans ma boite, on s'en sert pour compenser les sites webs avec des urls impossibles à retenir.

    • [^] # Re: Engouement

      Posté par (page perso) . Évalué à 3.

      Un autre intérêt : dans les courriers. Il y a certains MUA daubés (ou mal configurés ?) qui coupent les URL un peu longs, et quand Mme Michu clique sur le lien, elle se paye une 404.

    • [^] # Partout où on ne peut pas copier les URL

      Posté par (page perso) . Évalué à 0.

      Je me sert régulièrement des raccourcisseurs d'url parce que j'utilise un type de logiciel à la c… qui ne permet pas de copier/cliquer sur un lien qui passe dans le chat : les mmorpg. Ouais, y'a quelques jeux comme ça qui ne permettent pas de sélectionner directement le texte que les copains viennent d'écrire et donc, faut retaper à la main l'adresse dans la barre de notre navigateur. Le racourcisseur d'url est un vrai soulagement.

      Bon, c'est précis comme type d'utilisation, mais ça me sert régulièrement, donc : merci à ceux qui font des raccourcisseurs :)

  • # !

    Posté par . Évalué à 10.

    Ça raccourci vachement bien ! :D

    http://linuxfr.org => http://lstu.fiat-tux.fr/yc64yJO1

  • # Merci

    Posté par (page perso) . Évalué à -1.

    C'est très instructif comme petit projet et ça nous change des trucs dégueulasses en php!

    • [^] # Re: Merci

      Posté par (page perso) . Évalué à 4.

      Hi hi! C'est vrai que le PHP, bon, hein. On n'est pas trolldi mais je n'en pense pas moins.

      Bon, je dois dire que je ne suis pas ultra fan des templates de pages directement dans le fichier exécutable, je trouve ça crade et peu lisible (j'ai été obligé de mettre le twitter bootstrap dedans, j'ai pas réussi à le mettre dans son template à part[1]), mais je voulais vraiment faire un truc qui se suffit à lui-même (mais c'est en train de changer, maintenant y a un fichier de conf).

      [1] il est dans le template "layout" de la page. J'aurais pu le mettre dans un dossier à part, mais encore une fois, je ne voulais qu'un fichier.

      It's a fez. I wear a fez now. Fezes are cool !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.