Archives mensuelles : octobre 2017

Un nouveau logi­ciel : WemaWema !

Il est des logi­ciels qui partent d’une idée à la con, et qui gran­dissent, gran­dis­sent… WemaWema est de ceux-ci.

L’idée à la con

Tout à commencé par une demande de Genma dans un pouet du 26 septembre :

Y a un « We make » gene­ra­tor en ligne ou pas encore ?

Un peu d’his­toire

Les stickers « We make » sont un mème du Teta­lab, un hackers­pace toulou­sain (même s’ils disent « choco­la­tine », c’est quand même des gens biens 😛) et dont voici l’origine :

L’ar­gu­ment prin­ci­pal utilisé pour la mise en place d’un système de filtrage sur Inter­net est toujours la porno­gra­phie et la pedo-porno­gra­phie.
Mais quand ce systèmes est en place on se rend vite compte que c’est rare­ment le ‘porn’ qui est filtrée.
‘We Make Porn’ rappelle a tout le monde que ses idées, son site inter­net ou son blog peuvent être filtrés.

Depuis, « We make porn » a été décliné de toutes les façons possibles et imagi­nables (voire l’ini­ma­gi­nable « We make Hummus » de Bram).

Bref.

WemaWema

TL;DR: allez jouez avec WemaWema sur https://luc.frama.io/wema­wema.

Le pouet de Genma date du 26 septembre à 15h42. À 19h56, la v1 de WemaWema était publiée ! Et depuis ce jour, ce ne sont pas moins de 14 versions qui sont sorties !

Alors oui, j’au­rais pu faire comme avec mes logi­ciels habi­tuels : commen­cer à la version 0.01 et monter tout douce­ment les versions. Mais là, c’était pour du pur fun, donc OSEF ! Une fonc­tion­na­lité = une nouvelle version ! Et tant pis si je sors plusieurs versions le même jour 😁

La fonc­tion­na­lité de départ est simple : deux lignes de textes, modi­fiables, et ça sort une image avec un fond jaune, les deux lignes de texte et un liséré noir inté­rieur.

Depuis cette première fonc­tion, il est possible :

  • choix de la taille, du posi­tion­ne­ment et de la couleur des textes
  • choix de la couleur du liséré
  • choix du fond : couleur unie, dégradé, direc­tion du dégradé (voire dégradé radiant), drapeau arc-en-ciel en dégradé, image de fond parmi les choix propo­sés, utili­sa­tion d’une image de fond que vous envoyez de votre ordi­na­teur
  • possi­bi­lité d’ajout d’un calque avec des « paillettes »
  • export SVG

Tout est fait côté client avec un canvas et du javas­cript tout tapé avec mes grosses pattes, sauf pour le SVG pour lequel j’uti­lise la biblio­thèque Canvas 2 Svg.

Il y a aussi un service en ligne qui génère auto­ma­tique­ment les images, utili­sable donc comme source d’une balise <img>. Ce service est aussi utili­sable dans les slash commands de Matter­most.

Prenons https://wema.fiat-tux.fr, l’en­droit où j’hé­berge ce service. Créez une slash command poin­tant vers cette URL avec, disons, /wemake comme appel. Quand vous écri­rez /wemake POUETS, le service vous renverra l’adresse de l’image « WE MAKE POUETS » du même service.

Le futur

Au moins deux chan­tiers sont à entre­prendre :

  • une refonte graphique : les para­mètres sont entre­po­sés pêle­mêle et on a déjà comparé ceux-ci au tableau de bord d’un Boeing 747
  • la possi­bi­lité de choi­sir la police des textes

Je pense aussi à ajou­ter la possi­bi­lité de redi­men­sion­ner l’ima­ge… bref, ça risque de deve­nir un géné­ra­teur de mèmes géné­rique 🙂

La license

C’est du AGPLv3.

Me soutenir sur Tipeee Me soutenir sur Liberapay

Mettre à jour un serveur umap vers Debian Stretch

Ayant bien galéré, voici un petit guide pour mettre à jour un serveur Debian Jessie héber­geant umap vers Debian Stretch.

Commen­cez à mettre à jour votre Debian de façon clas­sique et redé­mar­rez. C’est après que tout est cassé.

Mise à jour du virtua­lenv

Vous aviez créé votre virtua­lenv avec virtua­lenv­wrap­per en choi­sis­sant python3, mais malheu­reu­se­ment, c’était la version 3.4 et main­te­nant c’est la 3.5 qui est instal­lée dans Debian. Bah, rien de plus simple : relan­cez la commande de créa­tion de votre virtua­lenv.

mkvirtualenv umap --python=`which python3`

Par contre, umap n’est toujours pas installé pour python 3.5. Hop, on le réins­talle (à exécu­ter dans le virtua­lenv) :

pip install umap-project

C’est tout pour la partie python. Par contre uwsgi plante lamen­ta­ble­ment à coup de

could not access file "$libdir/postgis-2.1": No such file or directory

C’est la faute à la version de l’ex­ten­sion post­gis de Post­greSQL : la mise à jour a provoqué l’ins­tal­la­tion de Post­greSQL 9.6, ce qui a provoqué la mise à jour du paquet postgresql-9.4-postgis-2.1 en postgresql-9.6-postgis-2.3.

Réins­tal­la­tion de post­gis pour Post­greSQL 9.4

Malheu­reu­se­ment, il n’y a pas de paquet postgresql-9.4-postgis-2.3 et vous ne pouvez pas réins­tal­ler postgresql-9.4-postgis-2.1.

La solu­tion est de passer par les paquets four­nis par les dépôts de Post­greSQL :

echo "deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main" \
  | sudo tee /etc/apt/sources.list.d/pgdg.list
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc \
  | sudo apt-key add -
sudo apt update

À ce moment-là, j’ai voulu instal­ler postgresql-9.4-postgis-2.3, mais je me suis retrouvé avec postgresql-9.4-postgis-2.4, donc autant y aller gaie­ment en mettant à jour post­gis pour Post­greSQL 9.6 :

sudo apt install postgresql-9.4-postgis-2.4 postgresql-9.6-postgis-2.4

Connec­tez-vous à votre base de données Post­greSQL :

su postgres
psql umapdb

Véri­fiez la version de post­gis que vous indique Post­greSQL :

umapdb=# SELECT name, default_version, installed_version FROM pg_available_extensions WHERE name = 'postgis';
  name   | default_version | installed_version 
---------+-----------------+-------------------
 postgis | 2.4.0           | 2.4.0
(1 row)

Et mettez à jour l’ex­ten­sion :

umapdb=# ALTER EXTENSION postgis UPDATE TO "2.4.0";

Avec ça, ça devrait rouler. MAIS ! (bah oui, y a un « mais »)

Mais vous savez que vous avez main­te­nant deux versions de Post­greSQL sur votre serveur et qu’il vaudrait mieux passer sur la 9.6. J’y ai d’ailleurs consa­cré un article derniè­re­ment.

EDIT : atten­tion, le problème ci-dessous n’ar­ri­vera que si vous avez ajouté l’in­dex search_idx en suivant la recom­man­da­tion pour une grosse base. Ne modi­fiez pas les fonc­tions unaccent et to_tsvector sur votre nouveau clus­ter si vous n’aviez pas précé­dem­ment créé l’in­dex, cela risque­rait d’avoir des effets de bords indé­si­rables si jamais vous avez d’autres bases de données que celle d’umap sur votre Post­greSQL.

Problème : un index sur la table leaflet_storage_map empêche la migra­tion, et vous vous retrou­ve­rez avec le message

ERROR: functions in index expression must be marked IMMUTABLE

Réso­lu­tion du problème de l’in­dex

Ce n’est pas compliqué : on va suppri­mer l’in­dex sur le clus­ter 9.4 et le recréer une fois la migra­tion vers 9.6 effec­tuée.

umapdb=# DROP INDEX search_idx;

Hop, on fait la migra­tion en suivant mon tuto (ne suppri­mez pas tout de suite le clus­ter 9.4, faut d’abord véri­fier que tout fonc­tionne norma­le­ment).

Recon­nec­tons-nous sur la base d’umap, mais cette fois, ce sera sur le clus­ter 9.6 et tant qu’à faire, véri­fions que nous sommes bien connec­tés sur le bon clus­ter).

umapdb=# SELECT version();

Il est temps de recréer l’in­dex. Mais un bête

umapdb=# CREATE INDEX search_idx ON leaflet_storage_map USING gin(to_tsvector(unaccent(name)), share_status);

échouera avec le même problème que tout à l’heure. Il faut faire :

umapdb=# ALTER FUNCTION unaccent(text) IMMUTABLE;
umapdb=# ALTER FUNCTION to_tsvector(text) IMMUTABLE;
umapdb=# CREATE INDEX search_idx ON leaflet_storage_map USING gin(to_tsvector(unaccent(name)), share_status);

Et là on est bon ! Redé­mar­rez peut-être uwsgi pour qu’il prenne en compte le chan­ge­ment de clus­ter, mais je ne suis pas sûr que ce soit néces­saire.

Testez votre umap et si tout est bon, vous pour­rez virer votre clus­ter 9.4 et les paquets asso­ciés 🙂

Crédits : image d’illus­tra­tion by Himesh Kumar Behera on Unsplash

Me soutenir sur Tipeee Me soutenir sur Liberapay