Koder Cloud - Blog

FlyEnv : Un serveur local pour tous

Mon, 24 Feb 2025 00:00:00 +0100

Si vous souhaitez essayer 299Ko en local avant de le déployer sur un serveur en ligne, FlyEnv est une solution puissante et flexible. Ce logiciel open source permet de configurer facilement un environnement de développement complet avec des serveurs web (Apache, Nginx), des bases de données (MySQL, PostgreSQL), et plusieurs langages de programmation (PHP, NodeJS, Go etc.) — le tout avec une interface graphique intuitive.

Les avantages de FlyEnv par rapport à Docker et XAMPP/WAMP

Plus simple et plus rapide que Docker

Contrairement à Docker, FlyEnv ne repose pas sur des conteneurs virtuels. Il fonctionne comme une application native, ce qui le rend plus rapide et moins gourmand en ressources. Pas besoin de créer des fichiers Dockerfile complexes ou de gérer des images — tout se fait via une interface claire et directe. C'est l'idéal si vous voulez simplement faire tourner un site PHP comme 299Ko sans vous perdre dans des configurations réseau compliquées.

Plus flexible que XAMPP ou WAMP

FlyEnv permet également d'installer plusieurs versions de PHP, allant de la 5.x à la 8.x, et de basculer entre elles facilement. Là où XAMPP et WAMP vous enferment souvent dans des versions spécifiques (et parfois obsolètes), FlyEnv vous donne une liberté totale pour tester 299Ko dans différents environnements. Vous pouvez par exemple créer un projet avec PHP 7.4 pour vérifier la compatibilité, puis passer à PHP 8.2 en un clic.

Configuration de 299Ko avec FlyEnv

Étapes d'installation

Téléchargez FlyEnv depuis son GitHub.
Installez-le sur votre système (Windows, macOS ou Linux).
Lancez FlyEnv et configurez un serveur local avec Apache ou Nginx.
Ajoutez PHP (7.4 ou supérieur) via l'interface de FlyEnv.
Créez un nouveau site en un clic dans FlyEnv, et sélectionnez le serveur web de votre choix (Apache ou Nginx).
Téléchargez 299Ko depuis son site officiel et décompressez-le dans le répertoire du site FlyEnv.
Démarrez le serveur local et accédez à votre site via http://localhost:8000 (ou le domaine personnalisé que vous avez configuré).

Tester et développer 299Ko

FlyEnv vous permet d'éditer facilement les fichiers de configuration d'Apache ou Nginx grâce à son éditeur intégré. Vous pouvez aussi ajuster les paramètres PHP (comme les extensions activées) directement depuis l'application, sans avoir à fouiller dans des fichiers ini cachés.

Conclusion

Avec FlyEnv, tester 299Ko devient simple, rapide et flexible. Que vous soyez un développeur confirmé ou débutant, vous apprécierez la possibilité de jongler entre différentes versions de PHP et de configurer facilement vos serveurs web. C'est une alternative moderne et puissante à Docker, XAMPP et WAMP.

Avez-vous déjà testé 299Ko avec FlyEnv ? Partagez vos retours dans les commentaires !

PicoCSS : Un framework CSS pour les amoureux de la sémantique HTML

Fri, 26 Jan 2024 00:00:00 +0100

Aujourd'hui je voulais vous parler d'un petit framework CSS, PicoCSS.

Si je l'aime bien, celui-là, c'est parce qu'il n'utilise pas ou extrêmement peu de classes. Il est léger, sous license MIT, et si on connait Sass, assez facile à modifier.

Think different

Alors non, d'habitude, je n'aime vraiment pas ces bêtes là. Noms de classes à rallonge dans le genre Bootstrap et autres usines à gaz.
Ce que je leur reproche, c'est que le nom des classes utilisées définissent l'aspect du conteneur, genre :

<button class="button is-white">White</button>
<button class="button is-light">Light</button>
<button class="button is-dark">Dark</button>
<button class="button is-black">Black</button>
<button class="button is-text">Text</button>
<button class="button is-ghost">Ghost</button>

Vous avez compris le principe.

Ici on a 2 problèmes :

is-white : Ici, on définit la couleur du bouton grâce à une classe, et pas à son contexte. Le problème c'est que si je construis une page sur fond noir, j'aurai tendance à utiliser ces boutons blancs. Si un jour me prend l'envie de balancer mon fond sombre et de passer en clair, soit je modifie mes is-white en is-black, soit je modifie la couleur des boutons blancs. Je me retrouve donc avec des boutons is-white qui sont noirs.
<button class="button" : Y'a rien qui choque là ? Il faut définir un bouton comme un bouton, et un input comme un input ? Qui est tenté par faire un <button class="div"> ? Les frameworks n'utilisent pas la sémantique HTML, et c'est un problème qui peut être simplifié.

Pas de classe

PicoCSS revendique n'utiliser presque aucune classe. Presque, car le système de grilles en a besoin, mais une version classless existe également.
Sa force à lui, c'est d'utiliser la sémantique. Pour styliser un bouton, il n'y a aucune classe à ajouter, seule la sémantique suffit :

<button>Texte</button>

Si vous voulez donner un style de bouton à un lien, toujours pas de classe, on utilise ce qui est disponible en HTML5 :

<a role="button">Lien bouton</a>

Et je peux vous garantir que ça fait la différence.
Sur une page simple, avec uniquement des tags HTML, le fait d'inclure le fichier css de Pico change toute la page :

<section id="preview">
    <h2>Preview</h2>
    <p>
        Sed ultricies dolor non ante vulputate hendrerit. Vivamus sit amet suscipit sapien. Nulla
        iaculis eros a elit pharetra egestas.
    </p>
    <form>
        <input type="text" name="firstname" placeholder="First name" aria-label="First name" required />
        <input type="email" name="email" placeholder="Email address" aria-label="Email address" required />
        <fieldset>
            <label for="terms">
                <input type="checkbox" role="switch" id="terms" name="terms" />
                I agree to the <a href="#" onclick="event.preventDefault()">Privacy Policy</a>
            </label>
        </fieldset>
        <button type="submit">Subscribe</button>
    </form>
</section>

Le rendu sans CSS :

Le rendu avec Pico, simplement en ajoutant la feuille de styles :

Simple et efficace non ?

Il vous laisse le soin d'ajouter vos propres classes. Par exemple, pour un bouton, on peut imaginer un button.error, que vous mettrez en rouge.

Mise en place

Si vous êtes plutôt du genre à tout héberger chez vous, vous pouvez récupérer les fichiers CSS compilés, et le mettre dans l'entête de votre site :

<link rel="stylesheet" href="css/pico.min.css">

Si vous êtes plus fainéants, il y a toujours la solution du CDN (par jsDelivr) :

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@picocss/pico@1/css/pico.min.css">

Sinon, il est également disponible via npm et composer.

Simplicité, légèreté et efficacité

PicoCSS ne pèse que 10ko. Si l'on compare ça aux mastodontes, ça en fait un concurrent très léger.
Pour autant, ce framework CSS n'est pas en reste sur pas mal de points :

Mode clair / sombre
Complètement responsive (taille du texte incluse)
Conteneurs fluides
Système de grilles
...

Je vous laisse lire la documentation de PicoCSS pour découvrir tout ça. Un générateur de thème simple est également présent, qui vous permettra de choisir la couleur dominante de votre site, si n'êtes pas fan du bleu ;)

A l'heure actuelle, une v2 est en préparation (la v2RC3 est déjà sortie). D'après les sources, les dévs restent dans le même esprit, à savoir la simplicité.

L'outil idéal ?

Alors non, bien sûr. Même si je n'en ai fait que des éloges, PicoCSS n'est pas la réponse à tout, et ne gère pas tout.

Si vous n'êtes pas à l'aise avec Sass, la modification du CSS sera tout simplement longue et barbante.
De plus, il n'y a pas de Javascript. Aussi, oubliez les menus dynamiques ou les animations trop hypes, mais pour un petit blog, un site léger, c'est l'outil parfait.

Docker : Se créer un environnement de développement PHP

Fri, 19 Jan 2024 00:00:00 +0100

Je vous parlais de Docker il y a peu. Aujourd'hui on va aller un peu plus loin dans ce qui est pour moi, l'intérêt premier de Docker.
En effet, avant même de vouloir tester des CMS, des scripts etc, ce que je souhaite faire moi, c'est développer mes trucs à moi, en PHP.

Pas à pas, on va voir ensemble comment faire ça, avec la persistence et tout ce qui va bien.

Une première version simple

On va clarifier notre besoin : On a un projet sur Github qu'on souhaite tester. Le projet ? 299ko, un CMS qui nécessite au moins PHP 7.4 sur un serveur Apache, c'est tout.
Pas de base de données, rien, ça va être très simple.

Pour la continuité de l'article, vous aurez simplement besoin de Docker installé sur votre machine, pas plus.

L'image

La première chose à faire, c'est de construire l'image dont on a besoin.
Docker fonctionne avec des conteneurs, qui sont tous isolés les uns des autres. Pour lancer un conteneur, il faut une image, qui comprend l'ensemble des fichiers et des services qui lui sont nécessaires.

Une fois qu'on a notre image, on peut en créer autant de conteneurs qu'on souhaite. Mais avant ça, il faut bien créer notre image.
Pour ça, on a à notre disposition un outil formidable : Docker Hub.

Le Docker Hub est une plateforme où l'on peut récupérer des images Docker prêtes à l'emploi, pour tester des scripts, serveurs etc, mais où chacun a le droit d'en mettre également.
Le mieux, c'est qu'il est possible de récupérer une image, la modifier pour notre besoin et la partager à tout le monde.

On en revient à notre image. J'ai dit qu'on avait juste besoin d'un serveur Apache et PHP pour tester notre petit CMS. Ca tombe bien, l'équipe webdevops a déjà créé une image avec tout ce qui nous faut.

Récupérer l'image

Pour récupérer une image trouvée sur le hub docker, il nous suffit d'ouvrir une console et de lancer :

docker pull webdevops/php-apache:8.0

Cette commande va télécharger l'image (ici php-apache), de l'auteur webdevops, au tag 8.0, qui correspond ici à une version supérieure de PHP que celle dont nous avons besoin.

Lister les images

Nous venons de télécharger notre première image.
Pour lister l'ensemble des images que vous avez déjà téléchargé, il suffit de lancer :

docker image ls                                                                               
REPOSITORY             TAG       IMAGE ID       CREATED       SIZE
webdevops/php-apache   8.0       aaa9c0647b41   5 weeks ago   1.06GB

Et notre image ressort.

Créer notre premier conteneur

On va lancer notre premier conteneur, avec l'image fraîchement récupérée :

docker run --name 299ko -p 8080:80 webdevops/php-apache:8.0

docker run permet de créer un conteneur depuis une image
l'option --name attribut le nom 299ko au conteneur créé
-p 8080:80 "mappe" le port 80 de notre machine créée vers le port 8080 de la machine hôte (machine physique). En gros on utilisera le port 8080 sur notre navigateur pour arriver sur le port 800 de notre conteneur
enfin, le nom de l'image avec le tag. Si l'image n'a pas été téléchargée, elle le sera automatiquement. Si le tag n'est pas spécifié, ce sera la dernière version (:lastest) qui sera recherché.

A partir de ce moment, votre conteneur Apache + PHP est en fonctionnement. Si vous prenez votre navigateur et que vous vous rendez à l'adresse http://localhost:8080, vous aurez bien une réponse du serveur Apache qui vous affichera certainement une erreur 403 (forbidden).

Lister les conteneurs

Une fois le conteneur créé, vous pouvez retrouver les détails de celui-ci :

Lister les conteneurs actifs :

docker ps

Lister tous les conteneurs :

docker ps -a

Stopper, relancer

Arrêter le conteneur :

docker stop 299ko

Lancer le conteneur :

docker start 299ko

En stoppant le conteneur, vous verrez que la page http://localhost:8080 n'est plus accessible.

Et les fichiers ?

Vous avez raison. Si le service est actif, il faut pouvoir modifier les fichiers pour faire apparaître quelque chose.
Mais où doit-on mettre les fichiers pour que le serveur les prennent en compte ?

Alors là, faut se pencher sur la doc de webdevops. Je vous donne le chapitre concerné, et la réponse : dans le repertoire /app . Donc tout ce qui est dans le repertoire /app sera visible à l'adresse http://localhost:8080 .

Mais comment avoir accès à ce repertoire ?
Vous allez ouvrir une autre console, en laissant le conteneur créé précédemment actif. Et on va taper dedans :

docker exec -ti 299ko bash

Cette commande va simplement exécuter le programme bash dans notre conteneur 299ko. En gros, on ouvre un terminal dans la machine hôte, comme si on se connectait en SSH dessus.

On peut alors taper un ls pour lister les fichiers et dossiers du / (root) du conteneur :

On voit notre dossier 'app', et on va pouvoir se positionner dedans :

cd app

Si vous retapez un ls, vous verrez que le dossier /app est vide. On va ensuite utiliser vi, l'éditeur en terminal présent dans l'image, pour créer un fichier que l'on pourra voir sur notre serveur. Au hasard, on va créer un fichier 'index.php', qui nous servira simplement de phpinfo, pour afficher la configuration PHP présente :

vi index.php

Pour les non initiés à vi, on va le faire ensemble :

Avec la touche "i", on va basculer du mode de commandes au mode édition
On va pouvoir taper notre texte. Ici, on ne tapera que 2 lignes : <?php et phpinfo();
Pour revenir au mode de commande, apuyez sur la touche "Echap"
Tapez ":w" puis "Entrée" pour enregistrer le fichier, et ":q" puis "Entrée" pour quitter Vi.

Enfin, accèdez à l'adresse http://localhost:8080, et vous devriez voir le magnifique phpinfo apparaître :

Voilà, vous avez créé votre premier conteneur Apache, mis votre premier fichier PHP, et ça fonctionne. Mais c'est vrai, c'est pas ouf non plus...

Dockerfile

Les images pour Docker sont organisés par dépendance. Par exemple, notre image initiale webdevops va dépendre d'une image PHP, qui dépend elle d'une image Debian Buster.

Ici, on va s'aider de notre image pour monter, comme tout à l'heure, notre combo Apache + PHP, mais au lieu d'aller modifier les fichiers à la main, on va aller récupérer les fichiers d'un dépôt Git. Pour ça, nous allons utiliser un Dockerfile, un simple fichier texte qui va automatiser toutes ces tâches.

Je vous laisse, sur votre ordinateur physique, choisir un dossier, et y créer un fichier appelé "Dockerfile". C'est tout, pas d'extension, rien. Dedans, nous y mettrons simplement ceci :

# syntax=docker/dockerfile:1
FROM webdevops/php-apache:8.0
RUN apt-get update && apt-get install -y git
RUN git clone --depth 1 -b v1.3.2 https://github.com/299Ko/299ko.git /app
RUN chown -R application:application /app/

La première ligne est une directive pour Docker, afin de spécifier la version de syntaxe utilisée.
FROM : On récupère l'image webdevops/php-apache:8.0 existante (la même que plus haut).
A partir de cette image, on va exécuter la commande (RUN) qui permet d'installer git
On clône un dépôt Git (ici https://github.com/299Ko/299ko.git, sur sa branche 1.3.2) on on place les fichiers dans le dossier /app
Et on change le propriétaire de ce dossier, pour ne pas avoir de soucis de droits en écriture dessus.

On sauvegarde et on ouvre un terminal dans le dossier où se trouve notre dockerfile. Nous allons simplement construire cette image pour pouvoir en créer des conteneurs. Pour cela, on lance juste un :

docker build .

Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM webdevops/php-apache:8.0
 ---> aaa9c0647b41
Step 2/4 : RUN apt-get update && apt-get install -y git
 ---> Running in b70c4885ba15
..............
Removing intermediate container 7cf8e8b4db0a
 ---> 1731c4fa143b
Step 4/4 : RUN chown -R application:application /app/
 ---> Running in c0be2d884c19
Removing intermediate container c0be2d884c19
 ---> 54b25dd63d40
Successfully built 54b25dd63d40

Le point final est important, il permet de spécifier que le Dockerfile à construire est dans le repertoire courant.

Ici, le nom de l'image créée est 54b25dd63d40. Si on veut ajouter un nom à l'image que l'on va créer (par exemple, testdf, il suffit de le spécifier comme ceci :

docker build --tag=testdf .

Puis on va pouvoir créer un conteneur de cette image testdf, qu'on appelera "contdf", sans oublier de changer le port pour l'accès :

docker run --name contdf -p 8081:80 testdf

Puis, en allant, sur l'adresse http://localhost:8081/, vous pourrez voir le CMS 299ko en action :

A ce stade, l'application est parfaitement fonctionnelle. Vous pouvez tester l'installation etc, le script peut modifier les fichiers de la machine.

Avec notre fichier Dockerfile, on a trouvé un vrai moyen de partager notre petit CMS. Ce n'était pas notre but premier, mais on avance.
Le vrai problème c'est vous, comment vous pouvez modifier les fichiers ?

Premier volume

On va faire différemment. Plutôt que de récupérer les fichiers distants et les balancer automatiquement dans le conteneur, on va créer un conteneur sans données d'application, comprenez sans les fichiers de notre CMS.
La particularité, c'est qu'on va créer un volume , un espèce de système de fichiers destiné à notre conteneur, mais qui aura la particularité d'être utilisable après la suppression de celui-ci.

En effet, Docker a été initialement dans le but de lancer des systèmes sans état, c'est à dire que si on supprime le conteneur, toutes les modifications sont perdues. Si c'est bien pour celui qui veut toucher à tout sans tout péter, pour développer des scripts en PHP c'est plutôt chiant.
Les volumes de Docker sont donc un moyen pour faire de la persistance, garder les données même si on pète tout.

Il existe 2 types de volumes dans Docker : Les volumes nommés, qui seront utiles lorsque vous voudrez partager des données entre 2 conteneurs par exemple, et les volume bind, comprenez volumes liés.
Ces derniers utilisent un dossier ou un fichier pour être monté dans le conteneur, là où vous le souhaitez.

Petit exemple

Pour tester les volumes bind, on va recréer un conteneur à partir de notre première image, Apache + PHP. La particularité, c'est qu'on va identifier au préalable un dossier sur notre machine physique que l'on utilisera pour monter dans le fameux dossier '/app' du conteneur.
Vous m'avez suivi ? C'est parti.

On va choisir un dossier, que l'on créera avant tout. J'ai choisi ici /home/maxk/docker, mais vous pouvez choisir celui que vous voulez, tant que vous avez les droits d'y placer et modifier des fichiers. C'est dans ce repertoire qu'on stockera les fichiers de notre application, et qui seront accessibles dans notre conteneur.

On va simplement lancer cette commande, pour créer un nouveau conteneur à partir de notre première image :

docker run --mount type=bind,source=/home/maxk/docker/,target=/app --name dockervolume -p 8083:80 webdevops/php-apache:8.0

docker run, comme d'habitude, pour créer un conteneur
--mount type=bind : Indique qu'on souhaite monter un volume bind
source=/home/maxk/docker/,target=/app : J'ai expliqué au dessus
--name dockervolume : Le nom de notre conteneur du coup
Puis vient le port utilisé, et le nom de notre image.

On lance ça, et on a un vrai conteneur de développement !

Il suffit de mettre vos fichiers dans le repertoire source, ici mon dossier /home/maxk/docker, et vous pouvez développer :)

Si vous supprimez le conteneur, les fichier sont gardés. Et mieux, si vous souhaitez tester vos scripts avec d'autres extensions, une autre version de PHP etc, vous pouvez. Il suffit de recréer un conteneur avec la même source, en changeant uniquement l'image d'origine :

docker run --mount type=bind,source=/home/maxk/docker/,target=/app --name dockervolumephp83 -p 8084:80 webdevops/php-apache:8.3

N'oubliez pas de changer le nom du conteneur et du port utilisé bien sûr, chacun doit être unique pour ne pas avoir de conflit.

Configuration

Je n'en ai pas parlé, mais il est évidemment possible de configurer l'environnement de PHP et Apache sur vos conteneurs. Je vous envoie vers la doc des images dont on a parlé, avec ce qu'on a vu vous avez toutes les cartes en main pour faire ça sans soucis ;)

Nous verrons dans un prochain article comment créer vos propres images, et les proposer sur le Docker Hub. Enjoy !

Manjaro : Erreurs de mise à jour

Wed, 03 Jan 2024 00:00:00 +0100

J'ai un soucis avec mon portable qui me sert essentiellement pour la navigation et le développement web.
C'est un Lenovo Thinkpad W540 de 2014 qui fonctionne très bien, mais dont les composants principaux vieillissent et me causent de plus en plus de soucis.
Le principal problème ? Ne plus pouvoir installer aucune distribution récente...

Un matériel qui fonctionne

Malgré les 10 ans de la bête, je n'ai pas envie d'en changer. En effet, il est encore plus puissant que la majorité des brouettes que l'on peut trouver dans les grandes surfaces par exemple. Avec 16 Go de RAM, un I7 à 8 coeurs, SSD et tout ce qui va bien, c'est encore un PC performant, malgré les gouffres que deviennent les OS.
Donc bon, en changer, j'en ai vraiment pas envie.

J'ai même pu y installer Windows 11, et il tourne très bien. Mais bon, c'est pas le but de la manip, et se dire qu'on ne peut pu installer Linux (Fedora, Manjaro, Debian, ...) mais que Windows tourne, ça la fout mal.

Pourquoi je ne peux pas installer

En fonction de la distribution, j'ai plusieurs symptômes. Mais sur tous les OS sortis il y a moins d'un an, le problème est récurrent, et il vient à chaque fois d'une même (grande) cause : Le Kernel.

J'ai remarqué que sur tous les OS qui ont dépassé le kernel 5.15, aucun ne fonctionne plus chez moi. Certains ne démarrent pas du tout, même en live (Fedora, Mageia, avec notamment Dracut qui pose soucis), d'autres ne se lancent plus après l'install (Arch, Garuda), et d'autres me causent des erreurs plus "légères". Manjaro ne s'éteint plus par exemple...

En parcourant les forums, j'ai lu beaucoup mais peu de réponses satisfaisantes. En gros, il faut changer le kernel ou alors se passer des fonctions qui posent soucis, comme la virtualisation.
Pas le but non plus.

Ancienne distro

Du coup, la solution que j'ai trouvé est de télécharger une ancienne version de Manjaro (la distribution que j'utilise quotidiennement depuis 2017 de mémoire), avec un kernel en 5.15 (LTS), et d'essayer de mettre à jour.
Le problème de Manjaro et d'autres, c'est qu'en rolling, télécharger des vieilles versions c'est déjà un peu compliqué, mais mettre à jour c'est encore pire.

J'ai eu des problèmes de dépendances qui seraient cassés (trop de passages de versions d'un coup), les miroirs en 404, et d'autres joies qui ne sont pas importantes ici.

Forcer la mise à jour

Au début, j'ai tenté une mise à jour via pamac. Mais j'ai rapidement vu que ça ne serait humainement pas possible à moins de démonter toutes les pièces de la distrib une à une :

sudo pamac upgrade
Préparation...
Synchronisation des bases de données des paquets...
Avertissement : kpeoplevcard : la version locale (0.1+r38.32d50a9-1) est plus récente que extra (0.1-2)
Résolution des dépendances...
Recherche des conflits entre paquets...
Erreur: La préparation de la transaction a échoué:
la satisfaction des dépendances a échoué:
- la suppression de kpeople casse la dépendance « kpeople » requise par kpeoplevcard
- la suppression de kcontacts casse la dépendance « kcontacts » requise par kpeoplevcard

En mettant à jour kpeople (qui devient kpeople5), la dépendance de kpeoplecard (qui doit passer en kpeoplevcard5) est cassée. La mise à jour s'arrête donc là.
Je tente une désinstallation de kpeoplevcard avant la MaJ, mais ce paquet est une dépendance de kdeconnect. Vous le voyez le problème ?

Sachant que j'ai 1015 paquets à mettre à jour, on va arrêter là.

On va plutôt essayer d'autoriser le downgrade :

sudo pamac upgrade --enable-downgrade

L'option --enable-downgrade autorise le passage à une version antérieure.
Si cette option est surtout utile pour ceux qui sont sur la branche unstable, ici elle permet de résoudre des cycles de dépendance.

A noter qu'il existe dans les paquets de Manjaro un outil pour downgrader un logiciel.

Miroir miroir

Pour ma part, même l'option downgrade n'a pas suffit.
J'avais tout un tas d'erreurs qui me disaient que les miroirs de téléchargements étaient injoignables :

https://mirror.tuchola-dc.pl/manjaro/stable/extra/x86_64/x264-3:0.164.r3108.31e19f9-1-x86_64.pkg.tar.zst: Impossible de se connecter : Connexion refusée
https://mirror.tuchola-dc.pl/manjaro/stable/extra/x86_64/zimg-3.0.5-1-x86_64.pkg.tar.zst: Impossible de se connecter : Connexion refusée
http://mirror.infotronik.hu/mirrors/pub/manjaro/stable/extra/x86_64/zimg-3.0.5-1-x86_64.pkg.tar.zst: Erreur 404
http://mirror.infotronik.hu/mirrors/pub/manjaro/stable/extra/x86_64/x264-3:0.164.r3108.31e19f9-1-x86_64.pkg.tar.zst: Erreur 404
Téléchargement de x264 (3:0.164.r3108.31e19f9-1) démarré
Téléchargement de zimg (3.0.5-1) démarré
Téléchargement de zimg (3.0.5-1) terminé
Téléchargement de x264 (3:0.164.r3108.31e19f9-1) terminé
427,2 Mo/2,5 Go Environ 21 minutes restantes
https://mirror.tuchola-dc.pl/manjaro/stable/extra/x86_64/onevpl-2023.4.0-1-x86_64.pkg.tar.zst: Impossible de se connecter : Connexion refusée
https://mirror.tuchola-dc.pl/manjaro/stable/extra/x86_64/ocl-icd-2.3.2-1-x86_64.pkg.tar.zst: Impossible de se connecter : Connexion refusée
https://mirror.tuchola-dc.pl/manjaro/stable/extra/x86_64/hidapi-0.14.0-2-x86_64.pkg.tar.zst: Impossible de se connecter : Connexion refusée
https://mirror.tuchola-dc.pl/manjaro/stable/extra/x86_64/sdl2-2.28.5-1-x86_64.pkg.tar.zst: Impossible de se connecter : Connexion refusée

Du coup, j'ai dû mettre à jour les miroirs avec pacman :

sudo pacman-mirrors --fasttrack && sudo pacman -Syu

En gros, j'ai demandé la mise à jour des miroirs, en sélectionnant le plus rapide pour les mises à jours.
Si vous voulez, la doc sur pacman-mirrors est bien fournie.

L'opération prend 3 à 4 minutes, et une fois cela fait, j'ai pu mettre à jour avec pamac et downgrade, comme cité plus haut.

Mon seul ennui maintenant est de savoir combien de temps ce kernel LTS sera supporté, car il y a fort à parier que je ne pourrais plus en installer d'autres plus récents. Ce PC est donc destiné à finir inutilisé, alors qu'il fonctionnerait encore très bien...

Installer Docker sous Manjaro

Sat, 02 Dec 2023 00:00:00 +0100

Je suis passé sous Arch depuis 6 ou 7 ans, et plus précisément avec Manjaro. Et pour ma culture d’homme du monde (ahah), mais surtout pour ne plus subir les railleries des puristes (joke bis), je me suis dit que moi aussi, j’allais me mettre à Docker.

J'ai longtemps utilisé Docker avec une surcouche, Lando, qui n'est plus trop fonctionnel avec les dernières versions du système de containers.
En plus, Lando (et les autres, comme DevilBox de mémoire), consomment pas mal de ressources pour uniquement un système qui va gérer pour vous les images et la persistence des données.

L’intérêt que je vois à cela, comparé à Xampp, est que je puisse tester diverses versions de PHP pour mes scripts, et surtout tester sur un serveur Nginx, ce que je ne peux pas faire actuellement.
Allez, c’est le week-end, il neige, autant en profiter et plonger la tête dans le shell plutôt que dans le moteur de la voiture : Ce soir, j’aurai installé Docker sur Manjaro.

Sincèrement, il n’y a rien d’intéressant ici pour ceux qui connaissent un peu. C’est plus un mémo pour moi et un tremplin pour pouvoir aller plus loin dans un autre billet que j’espère pouvoir sortir sous peu.

Mises à jour

Avant d’installer quoi que ce soit, on va si besoin installer les mises à jour disponibles et vérifier l’existence des nouveaux paquets. Faudrait pas se retrouver à installer un vieux bouzin…

Donc on va vérifier l’existence de mises à jour depuis les dépôts et paquets AUR (-a) :

pamac checkupdates -a

Puis installer les mises à jour (si disponibles) :

pamac upgrade -a

Oui je préfère pamac à pacman, cependant sachez que si j’avais lancé pacman -Su, ça revenait à la même chose. Cependant, pamac étant le gestionnaire de logiciels (la logithèque graphique, c’est lui) choisi par les dévs de Manjaro, celui-ci a l’avantage d’aller chercher dans tous les dépôts, et pas seulement les dépôts officiels.

Sinon, remarquez que je n’utilise pas sudo devant pamac : Si besoin, pamac vous demandera l’autorisation et donc le mot de passe pour exécuter l’action avec les droits nécessaires.

Installation de Docker

Venons en au but. Comme dans beaucoup de distributions, Docker est déjà dans les dépôts, pas besoin de s’enquiquiner plus que ça. Ouf 🙂

pamac install docker

Avant l’installation, il vous sera demandé d’installer une dépendance (PIGZ), qui permet d’utiliser plusieurs cœurs lorsque plusieurs images seront à compresser. L’intérêt semble nul puisque cette librairie ne sert que pour la compression. Or dans la pratique, c’est plutôt la décompression qui est utilisée (lorsque vous téléchargerez des images (conteneurs).

Petit test

Avant de vous laisser partir, on va tester que l’installation a été faite correctement et surtout, glisser quelques commandes à savoir.
On va en premier lieu chercher à connaître la version de Docker :

sudo docker version

Si l’installation s’est bien passée, vous devriez avoir ceci :

Client:
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.21.3
 Git commit:        afdd53b4e3
 Built:             Sun Oct 29 15:42:02 2023
 OS/Arch:           linux/amd64
 Context:           default

Server:
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.21.3
  Git commit:       311b9ff0aa
  Built:            Sun Oct 29 15:42:02 2023
  OS/Arch:          linux/amd64
  Experimental:     false
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

On a là un tas d’informations. En revanche en bas, on voit que Docker n’arrive pas à se connecter au daemon (serveur). Normal, on ne l’a pas lancé, on va faire ça.

Lancer Docker

Pour démarrer le serveur (daemon), il nous suffit de taper dans un shell :

sudo systemctl start docker

Et pour l’arrêter :

sudo systemctl stop docker

Pour info, la commande systemctl est inhérente à systemd, le système d’initialisation choisi par Manjaro. C’est cet outil qui nous permet de gérer les différents services d’une machine. Si vous voulez un peu d’histoire sur systemd, je vous renvoie vers LinuxFr.org.
Artix Linux par exemple, aussi basée sur Arch, utilise principalement OpenRC en tant qu’alternative à systemd.

Une fois le serveur Docker lancé, vous devriez avoir plus d’informations le concernant en lançant un sudo docker version :

sudo docker version                                              ✔ 
Client:
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.21.3
 Git commit:        afdd53b4e3
 Built:             Sun Oct 29 15:42:02 2023
 OS/Arch:           linux/amd64
 Context:           default

Server:
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.21.3
  Git commit:       311b9ff0aa
  Built:            Sun Oct 29 15:42:02 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.9
  GitCommit:        4f03e100cb967922bec7459a78d16ccbac9bb81d.m
 runc:
  Version:          1.1.10
  GitCommit:        
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Lancement au démarrage

Pour que Docker se lance automatiquement au démarrage du système, il suffit de lancer un petit :

sudo systemctl enable docker

Ainsi plus besoin de taper la commande pour lancer activer Docker.
Enfin, si au contraire vous souhaitez qu’il ne se lance plus au démarrage, lancez :

sudo systemctl disable docker

Sudo or not sudo

Enfin, il faut savoir que seul l’utilisateur root (ou un utilisateur avec les droits de super administrateur) a le droit de manager Docker. Si ne voulez plus avoir à monter les droits à chaque commande docker, il va falloir ajouter l’utilisateur courant au groupe docker, créé normalement par le script d’installation de Docker :

sudo usermod -aG docker $USER

Notez qu’il faut redémarrer la machine pour que les modifications sur le groupe soient effectives.
Pour les impatients, vous pouvez toujours vous connecter en tant que groupe docker :

newgrp docker

Hello world

Finalement, on se le fait ce test ?
Pour savoir si tout a fonctionné, on va lancer un conteneur de test, créé pour cela : hello-world :

docker run hello-world

Et vous devriez avoir à peu près ceci :

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete 
Digest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

La commande run suivi du nom de l’image va tenter de lancer l’image hello-world depuis le disque dur local. S’il ne la trouve pas, il ira la chercher sur le hub officiel. Puis il créé un conteneur à partir de cette image.
Sachez que chaque fois que vous lancerez cette commande, un nouveau conteneur sera créé. Relancer un conteneur arrêté est possible bien sûr, mais pas de la même façon. On verra cela dans un prochain billet.

J’arrête ici pour l’installation. L’usage viendra plus tard, j’attends vraiment de me familiariser et surtout comprendre les rouages de Docker, et voir comment je peux l’adapter à mon besoin.

Exécuter une requête asynchrone avec PHP et cURL

Sun, 19 Nov 2023 00:00:00 +0100

Je vous parlais de cURL et d’API il y a quelques jours. Aujourd’hui, j’enfonce le clou avec une méthode que j’expérimente pour un futur projet : Comment exécuter une requête asynchrone avec PHP et cURL.

L’origine du problème

Pour rappel, PHP est un langage de programmation séquentiel, impératif ou encore synchrone. C’est à dire qu’à l’exécution d’un script, il va exécuter chaque instruction séquentiellement, l’une après l’autre.
Avant de passer à la suivante, il attendra obligatoirement le résultat de la dernière instruction.

De plus, le protocole HTTP est également synchrone. Cela signifie qu’à chaque requête, le navigateur attend une réponse qu’il va ensuite afficher.

Dans la plupart des cas, ce fonctionnement suffit. L’utilisateur souhaite accéder à une ressource ou la mettre à jour : Pas de problème, la réponse est envoyée dans la foulée. Mais ce n’est pas toujours suffisant.

Quel problème ?

Je l’ai dit : Généralement le fonctionnement séquentiel est suffisant pour nos besoins. Mais il y a des tas de raisons pour vouloir faire de l’asynchrone avec PHP : Écriture de logs, de nombreux UPDATE à la DB, lancement d’une requête cURL à une API, envoie d’un pouet sur Mastodon lorsque j’écris une news, … Ces opérations peuvent être longues et donc donner la sensation aux visiteurs que votre serveur est en rade, ou que votre script est à chier.

Comprenez bien que si vous, en tant que visiteur, ne voulez pas attendre qu’une page s’affiche, il en est de même pour les usagers qui viendront sur votre site.

La requête asynchrone

La solution à cela est en effet la requête asynchrone. Pendant que votre script enregistre les logs ou se connecte à une API, il est inutile de faire attendre l’utilisateur.
On va donc chercher à faire travailler PHP en fond sur ces tâches lourdes, et continuer nos instructions plus légères jusqu’à l’envoi de la réponse au navigateur.

Plusieurs méthodes possibles

Il existe en fait d’autres approches que celle que je vais vous présenter :

fsockopen : ou stream_socket_client. Permet d’ouvrir une connexion par socket, afin d’enregistrer par exemple des données avec fwrite.
exec : Cette fonction permet de lancer une instruction, comme si vous la tapiez dans un terminal. En ajoutant un & à la fin de cette ligne de commande, l’exécution sera réalisée en tâche de fond et PHP n’attendra pas le résultat avant de continuer le script.
pg_send_query : Celle-ci supporte une ou plusieurs requêtes asynchrones à une connexion PostgreSQL. A ma connaissance, il n’existe pas d’équivalent pour MySQL.
curl_multi_init : Enfin, cette dernière autorise l’exécution de multiples gestionnaires cURL de façon asynchrone.

Pour ma part, voilà comment je procède.

Une requête asynchrone avec PHP et cURL

Le principe est simple si vous connaissez un peu la librairie cURL. Il suffit de lancer une requête cURL à laquelle on définit un timeout, afin que PHP n’attende pas la réponse et passe à la suite :

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://monsite.com/async/update');
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 1000);
curl_exec($ch);
curl_close($ch);

Oui, c’est tout.
L’option intéressante est CURLOPT_TIMEOUT_MS, qui permet de définir un temps maximum d’exécution de la fonction cURL, en millisecondes.

Attention : Évidemment, cette ressource ne doit être fait que sur le même site, sans quoi le timeout défini ne permet pas de garantir qu’un autre serveur distant ait le temps de répondre.

A la seconde près

J’ai mis 1000, soit une seconde. Cela permet de ne pas trop gêner le visiteur mais c’est aussi le délai minimum pour la résolution du hostname sur les systèmes Unix/Linux, sans quoi une erreur 28 (timeout) sera envoyée à PHP :

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://monsite.com/async/update');
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 10);
curl_exec($ch);
echo curl_errno($ch);
curl_close($ch);
// 28

En faisant mes recherches, j’ai trouvé quelques articles qui mettaient une valeur de 1ms. Je ne sais pas sur quel type de serveur ils tournent, mais ça ne fonctionne pas, vous pouvez essayer.

Outrepasser cette limite

Mais on peut le faire !
Malheureusement ces articles n’en parlent pas, alors j’ai cherché pour vous 🙂

En effet, avec l’option CURLOPT_NOSIGNAL, on peut ignorer les fonctions qui causent l’envoi d’un signal au processus PHP :

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://monsite.com/async/update');
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 10);
curl_setopt($ch, CURLOPT_NOSIGNAL, 1);
curl_exec($ch);
curl_close($ch);

Un cas concret

A présent, voyons comment cela peut nous être utile.

Imaginons un réseau social décentralisé (parait que c’est la mode), où chaque utilisateur peut suivre n’importe qui sur n’importe quelle instance. Le B.A.-BA en somme.
Lorsqu’un utilisateur, suivi par 100 personnes, poste un nouveau contenu, comment géreriez-vous cela ? Comment informer les 100 autres utilisateurs, possiblement sur 100 instances différentes, que notre bon utilisateur a posté quelque chose ? Et surtout, sans gêner l’auteur du post.
Avec cURL et notre pseudo méthode asynchrone, c’est possible.

Il suffit d’appeler une page sur le même domaine/serveur, qui traitera ces 100 requêtes cURL par exemple, en tâche de fond, à la manière d’une tâche CRON.
Pour l’utilisateur, rien ne transparaît, et le message peut se répliquer tranquillement sur chaque instance sans craindre un timeout execution.

Un autre exemple ? J'ai récemment créé une classe pour envoyer des pingback en PHP. En gros, lorsque vous enregistrez un article de blog, la classe parcourt tout le contenu de la page, cherche les liens, teste l'existence d'une adresse de pingback, envoie un ping, attend une réponse, ...
A chaque enregistrement, on perd facilement 5 secondes le temps que tout le monde ne se réponde. Avec une requête asynchrone, c'est invisible pour l'utilisateur ;)

cURL : Dialogue avec une API en PHP

Sun, 05 Nov 2023 00:00:00 +0100

Il y a quelques années, j’ai été confronté à l’API de Mastodon. J'avais d'ailleurs créé une librairie TootoPHP pour récupérer des pouets et en poster depuis PHP, peut-être que je l'utiliserai un jour ^^). Et me suis rendu compte que j’utilisais en fait 2 méthodes pour dialoguer avec une API en PHP. J’étais initialement parti pour vous présenter les 2, mais je ne détaillerai que la plus efficace : cURL.
La seconde, plus aisée et rapide fera l’objet d’un second article à venir.

Euh, Jamie, c’est quoi une API ?

Vous avez raison, avant tout cela, posons les bases.

API

Je suis sûr que vous avez déjà entendu parler d’API, même sans savoir ce que c’est. API signifie Application Programming Interface, ou Interface de Programmation Applicative. Ouais, moi non plus ça m’aide pas beaucoup. Ce qui est important là dedans, c’est le mot Interface.

En programmation comme dans la vie quotidienne, une interface désigne un moyen accessible (dans le sens facile) d’interagir avec un programme, une classe, une chaîne HiFi ou votre lave-vaisselle.
Pour imager, prenons l’exemple classique d’une télévision et sa télécommande. Cette dernière est l’interface entre vous et la TV.

Pour changer une chaîne, il suffit d’appuyer sur le bouton du canal désiré, et la télécommande va envoyer un signal au récepteur de la TV afin qu’elle change de fréquence. Personnellement, j’ai encore en mémoire la vieille TV de mes grands-parents où il fallait changer la fréquence avec un potar en façade. Ça change la vie
Et donc, comme dans chaque interface, une API impose une procédure qu’il faut respecter si l’on souhaite que ça fonctionne. Vous n’imaginez pas allumer votre voiture en appuyant sur le bouton des phares ? Ici c’est pareil.

Comment ça marche ?

Je l’attendais celle-là. Et bien, ça marche plutôt bien.

Plus sérieusement, voilà comment ça fonctionne en très gros :
Un site web propose d’héberger des photos. Il est alors possible de s’inscrire sur ce site, et d’y envoyer des photos. Le site vous donne en retour une URL que vous pouvez donner à vos amis pour montrer vos prouesses.
Et bien généralement, ces services web proposent une API pour utiliser leurs services sans passer par leur site. C’est le cas de Twitter (récupérer des tweets), PayPal pour les solutions de paiement, Facebook, … où l’on peut récupérer des informations où en poster via PHP, ou une console, …

Pour notre exemple d’hébergement de photos, on peut imaginer qu’on effectuera une première requête vers l’API pour s’authentifier sur le site, puis une seconde en envoyant la photo, et le serveur nous renverra alors l’URL de l’image en ligne si la transaction a été effectuée.

REST, SOAP, RESTful, …

Je ne détaillerai pas ici les différents types d’API, mais sachez, même si l’on entend parler que de lui, qu’il n’existe pas que REST.
SOAP est à ma connaissance le plus vieux (90), mais aussi moins utilisé, et repose sur des échanges basés sur du XML. Certains prétendent qu’il connaîtra un essor dans quelques années, à voir.

Enfin RESTful désigne simplement une application REST, plus récent (2000) mais également voulu moins lourd et plus simple. Dans la suite de ce billet, je ne parlerai que de ce type d’API.

cURL

La bibliothèque cURL de PHP est certainement la plus efficace et la plus utilisée des méthodes pour se connecter à une API. Il est possible de faire des tas de choses avec, comme l’utilisation de web services, de proxy, de faire du téléchargement, un crawler, gérer un FTP, …
Si cURL est bien connu des utilisateurs de Linux, c’est un outil multi-plateforme rapide, pas très compliqué à utiliser et qui gère l’authentification sécurisée.

Pour pouvoir l’utiliser avec PHP, il suffit d’activer la bibliothèque libcurl. Un petit

phpinfo();

pour vérifier si elle est bien activée et c’est parti.

Initialiser cURL

Pour créer une nouvelle ressource cURL, la syntaxe est simple:

$curl = curl_init();

A cela, on peut ajouter un argument : L’URL de destination. Ou l’on peut l’ajouter plus tard, c’est la méthode que je préfère.

Mise en place des paramètres

Il existe 2 façons pour ajouter des options à une ressource cURL :

Par l’array

J’aime bien le jeu de mots
Il est possible de fournir à notre ressource un tableau préalablement créé afin de lui spécifier des paramètres avec la fonction curl_setopt_array() :

$opts = [
    CURLOPT_SSL_VERIFYPEER => false,
    CURLOPT_HTTPHEADER     => $headers,
    CURLOPT_URL            => $this->domainURL . $url,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_TIMEOUT        => 30,
    CURLOPT_CONNECTTIMEOUT => 30
];

curl_setopt_array($curl, $opts);

Le premier argument à fournir est la ressource à paramétrer. La seconde contient notre tableau associatif, avec les options.

A l’ancienne

Quand je dis à l’ancienne, ne pas comprendre que cette fonction est plus vieille que l’autre. C’est juste la forme redondante que prend cette méthode à écrire. Bref, il est possible de passer les arguments un à un avec la fonction curl_setopt() :

curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);

Cette fonction attend en argument :

La ressource cURL à paramétrer
Le paramètre
La valeur

Quelques options intéressantes

Je vous livre ici quelques options de cURL, les plus utiles et basiques selon moi :

CURLOPT_URL : URL de l’hôte à utiliser pour la connexion.
CURLOPT_CONNECTTIMEOUT : Durée maximale que pourra prendre la tentative de connexion à l’hôte, en secondes.
CURLOPT_TIMEOUT : Durée maximale d’exécution de la requête, en secondes
CURLOPT_HEADER : Permet d’inclure l’entête dans la valeur de retour.
CURLOPT_RETURNTRANSFER : Retourne le transfert sous une chaîne au lieu de l’afficher.
CURLOPT_HTTPHEADER : Permet d’envoyer des entêtes HTTP avec la transaction. Nous verrons ça plus bas.
CURLOPT_SSL_VERIFYPEER : Si cette option est à true (par défaut), alors cURL vérifiera l’authenticité du certificat. Si vous n’utilisez pas de connexion SSL ou TLS, passez la à false.
CURLOPT_POST : Indique que la requête est de type POST. Si cette ligne n’est pas présente, cURL enverra par défaut une requête GET.
CURLOPT_POSTFIELDS : Dans une requête POST, tableau associatif avec les données à envoyer à l’hôte.
CURLOPT_FOLLOWLOCATION : Si cURL doit suivre les redirections éventuelles.
CURLOPT_USERAGENT : Spécifier un User-agent dans l’entête d’une requête HTTP. Liste de quelques user-agent sur Wikipédia.

Exécution de la session

Pour exécuter la requête, rien de plus simple. Il suffit d’utiliser la fonction curl_exec() :

$response = curl_exec($curl);

Vous l’aurez compris, l’argument à passer à cette fonction est notre ressource cURL. Cette fonction retourne simplement la réponse de l’hôte distant.

Fermer la ressource

Pour libérer de la mémoire, il est vivement conseillé, une fois la transmission terminée, de fermer la ressource :

curl_close($curl);

Testons cela alors.

Récupérer le contenu d’une page web

Ici, nous allons tenter de récupérer le contenu d’une page web. Vous allez voir que le code est très simple :

<?php

$curl = curl_init();

$opts = [
    CURLOPT_URL => 'www.google.fr',
    CURLOPT_RETURNTRANSFER => true,
];

curl_setopt_array($curl, $opts);

$response = curl_exec($curl);
curl_close($curl);

Ici on définit peu de paramètres :

L’URL de la page à récupérer
Le souhait de retourner la réponse et non de l’afficher.

La variable $response contient en sortie la réponse de la requête. Ici, c’est une chaîne de caractères comprenant le code HTML de la page de google.
Vous pouvez donc exploiter comme n’importe quelle string ce résultat.

Petit rappel : Pour parser un document HTML, vous pouvez vous aider de la classe DOMDocument ou de l’extension SimpleXML.
Sinon, il suffit d’un echo pour l’afficher sur la page.

L’utilité du User-Agent

Brève petite astuce : Je vous ai mis l’option CURLOPT_USERAGENT dans la liste des paramètres tout à l’heure. Celle-ci peut nous permettre par exemple de simuler une connexion à Google comme si nous nous connections avec un smartphone.

Dans le code précèdent, ajoutons simplement un user-agent de navigateur mobile dans les paramètres de la transmission :

<?php

$curl = curl_init();

$opts = [
    CURLOPT_URL => 'www.google.fr',
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_USERAGENT => 'Mozilla/5.0 (Android 13; Mobile; rv:109.0) Gecko/114.0 Firefox/114.0'
];

curl_setopt_array($curl, $opts);

$response = curl_exec($curl);
curl_close($curl);

echo $response;

On voit ainsi que Google a pris en compte notre requête, et a adressé la réponse en fonction du user-agent spécifié :

Transmission avec une API

Maintenant que nous avons vu sommairement l’utilisation de cURL, nous allons nous attaquer à ce qui nous intéresse : Dialoguer avec une API.

Requête GET

Selon l’API, comme avec le protocole HTTP que vous connaissez, il faut parfois effectuer une transaction GET ou POST.
GET est généralement utilisée lorsque votre application ne doit que récupérer des données de l’hôte, mais il est possible d’y passer des arguments.

Pour tester cela, nous allons nous servir de l’API Random User Generator, que j’ai découvert il y a peu, grâce au blog de ShevAbam. Il s’agit uniquement de pouvoir récupérer des informations d’utilisateurs aléatoires (factices), utiles pour vos éventuels tests.

La documentation, portée sur jQuery, permet tout de même d’en comprendre le fonctionnement.

On y apprend que l’URL d’entrée pour cette API, celle qui représente la ressource à récupérer, appelée endpoint, est https://randomuser.me/api/ , et que la ressource récupérée est un objet JSON.

Passons au code :

<?php

$curl = curl_init();

$opts = [
    CURLOPT_URL => 'https://randomuser.me/api/'
    CURLOPT_RETURNTRANSFER => true,
];

curl_setopt_array($curl, $opts);

$response = json_decode(curl_exec($curl), true);

print_r($response);

Si vous avez bien suivi, il ne devrait rien y avoir de compliqué.
J’ai renseigné le endpoint dans le paramètre CURLOPT_URL, et décode ensuite l’objet JSON que l’API me renvoie.

Voilà le résultat produit :

Array
(
    [results] => Array
        (
            [0] => Array
                (
                    [gender] => male
                    [name] => Array
                        (
                            [title] => mr
                            [first] => leon
                            [last] => hübner
                        )

                    [location] => Array
                        (
                            [street] => 9377 parkstraße
                            [city] => bayreuth
                            [state] => hamburg
                            [postcode] => 29972
                        )

                    [email] => leon.hübner@example.com
                    [login] => Array
                        (
                            [username] => heavyladybug706
                            [password] => dogwood
                            [salt] => iSK8r2hd
                            [md5] => ce2261b02d713de1b6f25710f40a38e0
                            [sha1] => e640a316dca46761476458eb17fbf8f8018949f7
                            [sha256] => 9c919250c04e2c3b925434c56a0aae210cd96b70e6b5a65cc1ddf764067f8260
                        )

                    [dob] => 1982-10-19 09:48:01
                    [registered] => 2004-04-06 02:49:59
                    [phone] => 0658-4413331
                    [cell] => 0174-7427152
                    [id] => Array
                        (
                            [name] => 
                            [value] => 
                        )

                    [picture] => Array
                        (
                            [large] => 
                            [medium] => 
                            [thumbnail] => 
                        )

                    [nat] => DE
                )

        )

    [info] => Array
        (
            [seed] => 04b9f8b8ed62a4a6
            [results] => 1
            [page] => 1
            [version] => 1.1
        )

)

Des paramètres ?

Je vous ai dit tout à l’heure qu’il était possible de spécifier des paramètres dans la requête. Voyons ça.

Comme dans n’importe quelle requête HTTP GET, les paramètres se mettent dans l’URL, tout simplement :

CURLOPT_URL => 'https://randomuser.me/api/?results=2&gender=male&inc=gender,name,nat',

J’ai fourni plusieurs paramètres, récupérés dans la doc. Le résultat :

Array
(
    [results] => Array
        (
            [0] => Array
                (
                    [gender] => male
                    [name] => Array
                        (
                            [title] => mr
                            [first] => adam
                            [last] => addy
                        )

                    [nat] => CA
                )

            [1] => Array
                (
                    [gender] => male
                    [name] => Array
                        (
                            [title] => mr
                            [first] => benjamin
                            [last] => martin
                        )

                    [nat] => NZ
                )
        )

    [info] => Array
        (
            [seed] => 52b8ab0ce31a8031
            [results] => 2
            [page] => 1
            [version] => 1.1
        )
)

Requête POST

Ce type de requête n’est pas plus compliquée. Il suffira généralement de quelques paramètres en plus dans notre ressource cURL.

Pour cet exemple, je me servirais de JSONPlaceholder. Pour ceux qui ne connaissent pas, c’est une fausse API en ligne qui existe uniquement à but de tests et prototypes. C’est parfait pour nous !

Encore une fois, la documentation est écrite pour Javascript, mais l’usage est simple. Vous pouvez si vous le souhaitez vous amuser avec les requêtes GET, mais ce qui nous intéresse ici est la création d’un nouveau post.

Pour faire cela, il va falloir envoyer une requête HTTP POST, avec 3 paramètres :

title : Le titre du post
body : Le corps du billet
userId : ID (entier) de l’auteur

Je vous donne le code :

<?php
 
$curl = curl_init();
 
$params = [
    'title' => 'Welcome Bro !',
    'body' => 'Lorem Ipsum etc etc',
    'userId' => 5
];
 
$params_string = http_build_query($params);
 
$opts = [
    CURLOPT_URL => 'http://jsonplaceholder.typicode.com/posts',
    CURLOPT_POST => true,
    CURLOPT_POSTFIELDS => $params_string,
    CURLOPT_RETURNTRANSFER => true,
];
 
curl_setopt_array($curl, $opts);
 
$response = json_decode(curl_exec($curl), true);
 
print_r($response);

J’ai mis en évidence les paramètres à modifier dans la ressource cURL pour exécuter correctement la requête.

Un point cependant, concernant la variable $params_string . C’est en fait la génération des paramètres encodés en URL, grâce à la fonction http_build_query($params).

Encore une fois, on décode la réponse et on observe le résultat :

Array
(
    [title] => Welcome Bro !
    [body] => Lorem Ipsum etc etc
    [userId] => 5
    [id] => 101
)

C’était vraiment compliqué ?

Pour aller plus loin

J’ai testé ici des exemples très scolaires et simples. Lors de l’utilisation d’une API plus complexe, par exemple avec une authentification par OAuth, des procédures et paramètres plus avancées sont requis.

N’hésitez pas d’y aller de vos commentaires si je peux améliorer cet article, merci !

PHP : Classe abstraite ou Interface

Fri, 27 Oct 2023 00:00:00 +0200

Ce week-end en discutant avec un ami, je me suis aperçu que l’utilité des classes abstraites et des interfaces n’était pas forcément très simple à saisir pour tout le monde. Que font-elles ? Quand utiliser l’une ou l’autre ? C’est le sujet du jour !

Classes abstraites

Tout d’abord, une classe abstraite est une classe qui ne peut être instanciée : Elle doit forcément être étendue.

La réelle utilité de ces classes est la factorisation : Chaque classe qui en hérite hérite également de ses attributs et méthodes déjà implémentées, comme toute autre classe. La différence réside dans le fait qu’elles puissent forcer l’utilisateur à implanter certaines méthodes.

Un exemple :

abstract class ParentClass
{
    protected $value;
    
    public function __construct($value)
    {
        $this->value = $value;
    }
    
    abstract public function showValue();
}

class ChildClass extends ParentClass
{
    public function showValue()
    {
        echo $this->value;
    }
}

$boy = new ChildClass(18);
echo $boy->showValue();
// 18

Ici, la classe ParentClass force ses héritiers à définir eux mêmes la méthode showValue() grâce au mot clé abstract devant cette méthode. En revanche, rien n’empêche ChildClass de ré-implémenter le constructeur si le mot clé final n’est pas présent dans la classe.

Si vous aviez une dizaine de classes ‘enfant’, imaginez le gain de code et de maintenabilité 🙂

Interfaces

Passons maintenant aux interfaces. J’aime voir une interface comme un contrat que doit remplir chaque classe qui l’implémente, c’est à dire que l’interface va fixer les contraintes de la classe, sans en définir le comportement interne. En effet, toutes les méthodes d’une interface doivent être déclarées publiques, libre à chaque classe de remplir le contrat comme elle le souhaite.

Une interface et une classe qui l’implémente :

interface ExampleInterface
{
    public function showValue();
        
    public function setValue($param);    
}

class ABC implements ExampleInterface
{
    private $value;
    
    public function setValue($var)
    {
        if ($this->testValue($var))
        {
            $this->value = $var;
        }
        else
        {
            $this->value = 'defaut';
        }
    }
    
    public function showValue()
    {
        echo $this->value;
    }
    
    private function testValue($var)
    {
        return is_string($var) ? $var : false;
    }
}

L’exemple est ici très scolaire mais suffisant à la compréhension : L’interface ExempleInterface définit un contrat simple : Chaque classe qui l’implémente doit obligatoirement définir 2 fonctions : showValue() et setValue($var) .

La classe ABC implémente ces fonctions comme elle le souhaite, tant qu’elle respecte la visibilité publique des fonctions et les arguments passés aux méthodes. D’ailleurs, nous allons maintenant voir cela en profondeur.

Les arguments de méthodes

Les interfaces et les classes abstraites qui définissent des méthodes abstraites peuvent imposer de recevoir un ou plusieurs arguments :

abstract class Foo
{
    abstract public function bar($var);
}


interface BobInterface
{
    public function bar($var, $var2);
}

Cependant, il faut impérativement que chaque classe qui les implémente ou les étend respecte ces arguments, la seule liberté laissée à la classe concrète étant de renommer ces arguments.

Dans le cas contraire, une erreur fatale sera levée.

Typage des arguments

Intéressons nous maintenant au type-hinting, c’est à dire le typage des arguments passés à nos méthodes.

Il en va de même que pour les arguments : Chaque méthode concrète doit respecter le type d’argument définit par la méthode abstraite (d’une classe ou d’une interface).

Aussi, ce genre de bidouillage soulèvera une erreur fatale :

interface BobInterface
{
    public function bar(\Foo $foo);
}

class Plop implements BobInterface
{
    public function bar(\OtherClass $foo)
    {
        echo 'Houston, nous avons un problème';
    }
}

Héritage

Parlons maintenant un peu d’héritage. En effet, les classes abstraites et les interfaces ont un sens de l’héritage quelque peu différent l’un de l’autre.

Classes abstraites

Concernant l’héritage, les classes abstraites ont le même comportement qu’une classe concrète, c’est à dire qu’elles ne peuvent hériter que d’une seule classe, et ne peuvent en étendre qu’une seule également. En revanche, une classe abstraite peut très bien en étendre une autre :

abstract class Foo
{
    abstract public function showValue();
}

abstract class Bar extends Foo
{
    abstract public function showValue();
    
    protected function testValue($var)
    {
        return is_int($var) ? $var : false ;
    }
}

class Concrete extends Bar
{
    public function showValue()
    {
        if ($this->testValue($var))
        {
            echo $var;
        }
    }
}

Notez que, comme les classes concrètes, si la méthode testValue($var) avait une visibilité ‘private’, la classe Concrete n’y aurait pas accès.

Interfaces et implémentation

Comme les pour traits, une classe, même abstraite, peut implémenter plusieurs interfaces. De plus, une interface peut très bien en étendre elle-même une autre. Voici un petit exemple d’implémentations et d’héritage :

interface FooInterface
{
    public function showValue();
}

interface BarInterface
{
    public function setValue($var);
}

interface AnotherInterface extends FooInterface
{
    public function prepareValuetoShow();
}

class TestClass implements BarInterface, AnotherInterface
{
    private $value;
    
    public function prepareValuetoShow()
    {
        $this->value = 'La valeur est ' . $this->value . '.<br/>';
    }
    
    public function showValue()
    {
        echo $this->value;
    }
    
    public function setValue($var)
    {
        $this->value = $var;
    }
}

Comme d’habitude, ce cas est très simple. Notez juste l’implémentation de AnotherInterface , qui étend elle-même FooInterface . La classe doit donc déclarer toutes les fonctions de ces 2 interfaces.

Ça va aller ? 😉

La compréhension par l’exercice

Afin de vérifier si vous avez bien compris quand utiliser l’un ou l’autre, je vous propose un petit exercice (avec ma correction :p ) tout simple :

Nous possédons 3 véhicules : Une voiture, un camion-benne et un vélo attelé d’une remorque. Ces 3 engins doivent pouvoir remplir la fonction seDeplacer . La voiture et le camion doivent implémenter une fonction ouvrirLeVehicule() .Pour ouvrir la voiture, nous utiliserons une télécommande et pour le camion, la clé.
Enfin, le camion et le vélo peuvent embarquer du matériel donc doivent pouvoir charger() et decharger() .

Bien sûr il est possible de créer 3 classes et tout définir à l’intérieur, mais évidemment, le but est ici de structurer et factoriser tout cela. A vous de jouer !

Je vous donne ma solution, et j’explique ensuite :

interface TransportInterface
{
    public function seDeplacer();
}

interface ChargementInterface
{
    public function charger();
    
    public function decharger();
}

abstract class VehiculeMotorise
{
    abstract public function ouvrirLeVehicule();

    public function seDeplacer()
    {
        echo 'Appuyer sur la pédale d\'accélérateur';
    }
}

class Voiture extends VehiculeMotorise implements TransportInterface
{
    public function ouvrirLeVehicule()
    {
        echo 'Appuyer sur la télécommande';
    }
}

class CamionBenne extends VehiculeMotorise implements TransportInterface, ChargementInterface
{
    public function ouvrirLeVehicule()
    {
        echo 'Mettre la clé dans la serrure, tourner la clé';
    }
    
    public function charger()
    {
        echo 'Ouvrir la benne, charger, fermer la benne';
    }
    
    public function decharger()
    {
        echo 'Ouvrir la benne, tout décharger, fermer la benne';
    }
}

class VeloPlusRemorque implements TransportInterface, ChargementInterface
{
    public function seDeplacer()
    {
        echo 'Pédaler...';
    }
    
    public function charger()
    {
        echo 'Mettre le chargement dans la remorque';
    }
    
    public function decharger()
    {
        echo 'Tout ôter de la remorque';
    }
}

$camion = new CamionBenne();
$camion->ouvrirLeVehicule();
$camion->charger();
$camion->seDeplacer();
$camion->decharger();

Ici, j’ai choisi d’utiliser 2 interfaces pour remplir les rôles majeurs. Notez que je n’ai pas mis la fonction ouvrirLeVehicule() dans une interface, car son rôle n’est pas majeur.

Le reste se passe de commentaires, excepté peut-être qu’il était possible de mettre une autre classe abstraite comme VehiculeNonMotorise. D’ailleurs, il existe une multitude de solutions possibles 😉

En résumé

J’espère que ce billet plus long que prévu permettra à ceux qui hésitent encore de mieux définir le rôle des classes abstraites et des interfaces, et savoir quand utiliser l’un ou l’autre.
Le plus important à retenir est qu’une classe abstraite ne doit pas définir le contrat que les classes concrètes vont remplir, mais à les ‘guider’ en leur fournissant des méthodes abstraites ou pas généralistes, que les classes concrètes viendront spécialiser, contrairement aux interfaces, qui ne peut contenir aucun code.

Bienvenue sur le blog KoderCloud !

Sun, 01 Oct 2023 00:00:00 +0200

Bienvenue sur mon blog, un espace où je partage ma passion pour le développement web, le monde du libre, Linux, mes merdes, mes réflexions personnelles, ... Permettez-moi de me présenter et de vous expliquer ce que vous pouvez attendre de ce blog.

Qui suis-je ?

Je m'appelle Max, depuis bientôt 40 ans. Je suis jeune de tout, parce que j'aime bien me définir comme ça.
Electronicien de formation, j'ai une grande passion pour l'informatique depuis ma réelle jeunesse. Je bidouille des scripts, des programmes (ça fait longtemps), de l'électronique, de la 3D, de la plomberie, la mécanique, domotique, et sûrement plein d'autres choses.
Très auto-didacte, j'essaye toujours d'apprendre par moi-même, sur tous les sujets. Très orienté depuis une vingtaine d'années sur le développement web, j'essaye d'explorer tous les sujets qui me tombent dessus comme le bricolage (les travaux, les vrais) dans une vieille maison.

J'ai 2 sales gamins, à qui je tente de donner une bonne éducation. Ca me permet de voir que malgré le temps que je passe sur le net, je suis totalement dépassé par les "tendances" des jeunes ^^

Ce que vous trouverez ici

J'écris ce que j'ai envie. En général, sur des sujets que je maîtrise (c'est mieux), mais parfois sur mes réflexions personnelles.

Surtout orienté développement web, parfois sur des généralités. J'aime le Libre, parce que le Libre c'est bien. Mais je n'aime pas les guerres de clan, j'en reste loin. Comme pour tout, je fais mon truc dans mon coin, j'en parle un peu à qui s'intéresse, et ça reste là.
Vous ne me verrez jamais dire qu'un truc c'est de la merde, parce que ce n'est pas ma philosophie de vie. Je ne vise pas les coups de gueule, les clashs ou quoi que ce soit.

L'informatique n'est pas mon métier. Aussi, je ne ferai quasiment pas d'articles pointus au possible. J'ai envie d'écrire comme j'aurai aimé lire : Rester simple, ça aurait pû être le slogan de ce blog, tant je ne comprends pas l'évolution des langages de programmation que j'utilise.
Ici le but est d'être compris par celui qui fait effort de lire, et celui qui est intéressé. J'essaye d'introduire des concepts à ma manière, à un public amateur, et pas seulement aux pros du métier.

Dans le même esprit, je m'intéresse à ce qui touche à Linux. Plutôt Manjaro que Ubuntu, j'essaye de temps en temps une distribution qui semble offrir autre chose. Mais je le fais de moins en moins...

Max Koder

Ce n'est pas mon premier blog. J'en avais ouvert un, qui n'a pas survécu aux éléments. Ma première expérience avec l'auto-hébergement était sur une carte Micro-SD dans un Raspberry. Les régulières coupures de courant dans mon village ont eu raison de la mémoire Flash, et aucune sauvegarde n'a pû être restaurée.
Soyons clairs : L'auto-hébergement sur un Pi n'a aucun avenir à long terme à partir du moment où vous commencez à avoir du traffic.
Loin de chez moi à cette période, j'avais laissé tombé jusqu'à ce que l'envie ne me reprenne.

Chez moi

Oui, vous êtes chez moi. Ce blog tout d'abord, c'est moi, mon vrai moi. Pas un moi fabriqué à la manière d'un instagram filtré au possible, avec une bouche en bec de canard. Non, c'est moi, sans filtre.

Puis, il faut savoir que ce blog est auto-hébergé. Dans de meilleures conditions à présent : J'ai un HP Proliant qui m'offre la possibilité d'avoir un vrai RAID 5, le tout avec des sauvegardes hebdomadaires sur des supports externes. Enfin, j'ai pu passer au VDSL an attendant la fibre qui ne devrait pas tarder.
Mais ça a l'air de fonctionner plutôt bien.

Mais surtout, vous verrez qu'il n'y a pas de Wordpress ici. Je n'ai rien contre bien sûr, mais j'ai choisi autre chose : Ce blog est propulsé par un petit CMS quasiment inconnu : 299Ko. Ce petit soft, développé en PHP et n'utilisant pas de base de données (flat-file), est très léger et surtout, open source.
Son plus gros inconvénient ? J'en suis le principal et seul développeur.

Le mot de la fin

Si jamais vous m'avez reconnu, re-bienvenue ici. Sinon, bienvenue, prenez ce qu'il y a à prendre, et au plaisir ;)