Si vous n'avez pas suivi l'histoire, depuis deux semaines les Panama Papers c'est une fuite de documents d'un cabinet d'avocats du Panama qui crée et administre des sociétés écran dans des paradis fiscaux. Procédé utilisé par les riches et les criminels pour blanchir de l'argent sale ou le cacher des services fiscaux. Dans les documents révélés on trouve de nombreux noms : chefs d'état, PDG, sportifs, avocats et autres membres de la caste des 1%. On constate aussi que les banques (françaises notamment) sont largement partie prenante du procédé malgré des promesses main sur le cœur que non on n'a rien à voir avec les paradis fiscaux.

Ce qu'il faut se rappeler c'est que si certains pays ou noms sont un peu épargnés par cette fuite massive (dûe probablement à un Wordpress dépassé et troué de failles de sécurité !) c'est que ce n'est qu'un seul cabinet spécialisé dans ce business, mais il y en a des milliers dans le monde ! Et ça m'étonnerait fort que ce genre de pratique ne soit pas répandu chez une large majorité des 1% les plus riches, ceux-là même qui abusent des médias pour dire qu'il y a trop d'impôts et de charges, alors qu'ils ne payent qu'une infime partie de ce qu'ils devraient payer. Et pendant ce temps-là on nous rabache que le problème c'est la fraude des chômeurs et des allocations familiales, qui ne représente absolument rien par rapport à cette fraude massive, organisée et soutenue par les plus grandes entreprises.

Mais ce n'est pas là ce dont je veux parler. Ce qui m'étonne le plus dans tous ces montages fumeux c'est que ce sont vraiment des montages douteux. Comment peut-on être multi-millionnaire et être assez bête pour confier des dizaines de millions d'euros à une entreprise créée dans un pays où on a jamais mis les pieds et dirigée par un prête-nom qui gagne probablement à peine plus qu'un SMIC français ? Enfin je sais pas vous mais moi je vois bien la faille du dirigeant prête-nom qui se barre avec l'argent de la société-écran, disparaissant à jamais. C'est un risque énorme. Et si ça arrive vous faites quoi, vous allez porter plainte que l'argent que vous blanchissez a été volé ?

Pour illustrer cette chaîne de confiance complètement stupide on peut prendre pour exemple ce qui se passe dans le reportage de Cash Investigation où un journaliste se rend chez une société suisse pour créer une société offshore. Cette dernière est enregistrée au Delaware (USA), et il reçoit ensuite une carte bancaire et un compte d'une banque néo-zélandaise. C'est déjà assez suspect comme ça, mais c'est dommage que les journalistes n'aient pas cherché un peu plus loin sur cette fameuse banque, car quand j'ai entendu le nom ça m'a rappelé quelque chose… En cherchant j'ai retrouvé un article que j'avais lu sur un journal de Nouvelle-Zélande, et c'est accablant : cette banque (Breder Suasso) n'en est pas vraiment une. Elle n'a aucun client en Nouvelle-Zélande (et les refuse), et pire n'a aucun compte en Nouvelle-Zélande. Donc le compte du journaliste en Nouvelle-Zélande est en réalité soit dans les Iles Marshall ou en Pologne, on ne sait pas vraiment (selon cet article).

Vous avez donc envoyé de l'argent dans une société basée au Delaware, avec un compte dans une entité néo-zélandaise, mais l'argent serait en réalité dans un autre pays, vous ne savez pas vraiment lequel. Pour moi ça ressemble plus à un scam à large échelle qu'à un montage offshore. Et si Breder Suasso ne vous semble pas suffisamment douteuse comme ça, apprenez que son seul actionnaire et président est résident de l'Île Maurice. L'entreprise n'a pas vraiment de locaux en NZ, un simple bureau partagé avec plusieurs entreprises. Vous sentez venir le gag ? Et oui : la banque est en réalité elle aussi une société-écran, une coquille vide qui ne sert que de façade.

Franchement moi j'aurais peur de confier mon argent à des compagnies comme ça, ça n'inspire aucune confiance. Mais bon en même temps, je ne suis pas multi-millionnaire, alors je n'ai pas les même problèmes !

Autant j'aime beaucoup les namespaces, la séparation claire des fonctions et autres sucreries en PHP, autant j'ai l'impression qu'on est maintenant dans un excès inverse. Avant on avait des gros fichiers monolithiques remplis de fonctions sans rapport les unes avec les autres c'était crade. Mais maintenant on a un énorme bordel de fichiers et classes qui ne servent à rien et ne font que détruire les perfs du serveur.

Évidemment ça ne se voit pas trop sur un serveur qui ne sert qu'une seule application car le code et les fichiers restent en RAM, mais quand on est en mutualisé avec des milliers d'applis sur le même dédié, ça se ressent bien. D'abord car charger un fichier depuis le disque à un coût, et ensuite parce qu'une classe en PHP occupe pas mal d'espace mémoire, même si elle est vide (cf. notamment la conférence de Julien Pauli).

Prenons quelques exemples. En premier picoFeed de Frédéric Guillot, qui lui sert notamment pour miniflux, que j'apprécie beaucoup (même si c'est pas encore ça à mon avis). C'est un parseur de flux RSS/Atom qui se veut "simple" et "rapide" qui fait tout un tas de choses genre récupération du contenu des articles pour les flux qui ne fournissent rien, la possibilité de générer des flux, des filtres de contenu, etc. Mais ça reste un exemple quand même. Cette librairie (une fois supprimées les règles de récupération de contenu) fait 47 fichiers, dont 16 qui font moins de 200 octets. Prenons un exemple, de 125 octets, Parser/Rss92.php:

namespace PicoFeed\Parser;

/**
 * RSS 0.92 Parser.
 *
 * @author  Frederic Guillot
 */
class Rss92 extends Rss20
{
}

Et toutes ces classes sont comme ça, elles ne servent à rien à part avoir un nom différent. Pourquoi ne pas faire un if/else ou switch case pour gérer ces cas plutôt que de créer des classes vides ? C'est moche.

Et ce n'est qu'une seule lib qui ne sert qu'à faire du RSS/Atom. Imaginez une appli complète avec des dizaines de libs de la même manière. Oh évidemment on ne charge pas tous les fichiers de toutes les libs (et donc toutes les classes) à chaque requête mais bon niveau perfs ça se ressent quand même.

Je suis aussi particulièrement admiratif quand je vois une lib (ou appli etc.) avec des dizaines ou centaines de classes pour gérer des exceptions (record : 450 !). Chaque classe ne faisant qu'étendre une autre classe d'exceptions. picoFeed est un peu victime de ça, même si vu la taille de la lib ça reste correct. On va dire que je me répète à force mais : à quoi ça sert d'avoir une classe pour chaque type d'exception imaginable ? Vous avez oublié que le second paramètre du constructeur d'une exception c'est $code ? Et à quoi ça sert $code ? Et bien à passer un code d'erreur !

Ainsi dans picoFeed on a ClientException (qui étend Exception), et des classes qui l'étendent : InvalidUrlException, InvalidCertificateException, MaxRedirectException, MaxSizeException, et TimeoutException.

Pourquoi ne pas avoir une seule classe/exception et un code d'erreur différent pour chaque situation ? Ces exceptions ne servent à rien, 99% des utilisateurs de la lib ne vont pas les récupérer individuellement. De même que ça n'aurait aucun sens que MySQL rejette une classe d'exception différente à chaque erreur différente, qui irait vraiment utiliser MySQLException_ER_CANT_CREATE_TABLE par exemple ? Quasiment personne, et c'est pour ça que ça a du sens d'utiliser le code d'erreur.

Je pourrais parler aussi de UA-Parser, une lib qui permet de parser l'User-Agent du navigateur. Bon je sais que c'est devenu compliqué de parser ce bordel d'UA avec le temps, mais quand même, 27 classes pour ça ? 130 Ko de code, et ça ne comprend même pas le fichier avec les regexs utilisées pour reconnaître l'user-agent !

Bref il y aurait de quoi simplifier ici, et tendre vers plus de légèreté et cesser un peu cette expansion lyrique qui n'a pas grande utilité, vous ne pensez pas ?

PS : pour ceux/celles qui demandent une alternative à picoFeed je ne peux que conseiller ma propre solution (modestie oblige ;-) ), FeedParser, issu du Framework KD2 (qui n'est pas un vrai framework structurant mais un ensemble de libs pratiques, légères et utiles, utilisables indépendamment les unes des autres). La stratégie de parsing est complètement différente : FeedParser n'utilise pas DOMDocument ou SimpleXML pour parser un document car les sites génèrent souvent du XML invalide. De ce fait FeedParser fait du parsing/lexing directement sur le flux, même s'il est invalide. Et ça marche ! Dans mes tests j'ai 100% de succès (aucun flux n'est illisible) sur plus de 20.000 flux, dont 15% de flux invalides. Et évidemment une seule classe, 17 Ko de code, contre pas loin de 400 Ko pour picoFeed par exemple.

Autant j'aime beaucoup les namespaces, la séparation claire des fonctions et autres sucreries en PHP, autant j'ai l'impression qu'on est maintenant dans un excès inverse. Avant on avait des gros fichiers monolithiques remplis de fonctions sans rapport les unes avec les autres c'était crade. Mais maintenant on a un énorme bordel de fichiers et classes qui ne servent à rien et ne font que détruire les perfs du serveur.

Évidemment ça ne se voit pas trop sur un serveur qui ne sert qu'une seule application car le code et les fichiers restent en RAM, mais quand on est en mutualisé avec des milliers d'applis sur le même dédié, ça se ressent bien. D'abord car charger un fichier depuis le disque à un coût, et ensuite parce qu'une classe en PHP occupe pas mal d'espace mémoire, même si elle est vide (cf. notamment la conférence de Julien Pauli).

Prenons quelques exemples. En premier picoFeed de Frédéric Guillot, qui lui sert notamment pour miniflux, que j'apprécie beaucoup (même si c'est pas encore ça à mon avis). C'est un parseur de flux RSS/Atom qui se veut "simple" et "rapide" qui fait tout un tas de choses genre récupération du contenu des articles pour les flux qui ne fournissent rien, la possibilité de générer des flux, des filtres de contenu, etc. Mais ça reste un exemple quand même. Cette librairie (une fois supprimées les règles de récupération de contenu) fait 47 fichiers, dont 16 qui font moins de 200 octets. Prenons un exemple, de 125 octets, Parser/Rss92.php:

namespace PicoFeed\Parser;

/**
 * RSS 0.92 Parser.
 *
 * @author  Frederic Guillot
 */
class Rss92 extends Rss20
{
}

Et toutes ces classes sont comme ça, elles ne servent à rien à part avoir un nom différent. Pourquoi ne pas faire un if/else ou switch case pour gérer ces cas plutôt que de créer des classes vides ? C'est moche.

Et ce n'est qu'une seule lib qui ne sert qu'à faire du RSS/Atom. Imaginez une appli complète avec des dizaines de libs de la même manière. Oh évidemment on ne charge pas tous les fichiers de toutes les libs (et donc toutes les classes) à chaque requête mais bon niveau perfs ça se ressent quand même.

Je suis aussi particulièrement admiratif quand je vois une lib (ou appli etc.) avec des dizaines ou centaines de classes pour gérer des exceptions (record : 450 !). Chaque classe ne faisant qu'étendre une autre classe d'exceptions. picoFeed est un peu victime de ça, même si vu la taille de la lib ça reste correct. On va dire que je me répète à force mais : à quoi ça sert d'avoir une classe pour chaque type d'exception imaginable ? Vous avez oublié que le second paramètre du constructeur d'une exception c'est $code ? Et à quoi ça sert $code ? Et bien à passer un code d'erreur !

Ainsi dans picoFeed on a ClientException (qui étend Exception), et des classes qui l'étendent : InvalidUrlException, InvalidCertificateException, MaxRedirectException, MaxSizeException, et TimeoutException.

Pourquoi ne pas avoir une seule classe/exception et un code d'erreur différent pour chaque situation ? Ces exceptions ne servent à rien, 99% des utilisateurs de la lib ne vont pas les récupérer individuellement. De même que ça n'aurait aucun sens que MySQL rejette une classe d'exception différente à chaque erreur différente, qui irait vraiment utiliser MySQLException_ER_CANT_CREATE_TABLE par exemple ? Quasiment personne, et c'est pour ça que ça a du sens d'utiliser le code d'erreur.

Je pourrais parler aussi de UA-Parser, une lib qui permet de parser l'User-Agent du navigateur. Bon je sais que c'est devenu compliqué de parser ce bordel d'UA avec le temps, mais quand même, 27 classes pour ça ? 130 Ko de code, et ça ne comprend même pas le fichier avec les regexs utilisées pour reconnaître l'user-agent !

Bref il y aurait de quoi simplifier ici, et tendre vers plus de légèreté et cesser un peu cette expansion lyrique qui n'a pas grande utilité, vous ne pensez pas ?

PS : pour ceux/celles qui demandent une alternative à picoFeed je ne peux que conseiller ma propre solution (modestie oblige ;-) ), FeedParser, issu du Framework KD2 (qui n'est pas un vrai framework structurant mais un ensemble de libs pratiques, légères et utiles, utilisables indépendamment les unes des autres). La stratégie de parsing est complètement différente : FeedParser n'utilise pas DOMDocument ou SimpleXML pour parser un document car les sites génèrent souvent du XML invalide. De ce fait FeedParser fait du parsing/lexing directement sur le flux, même s'il est invalide. Et ça marche ! Dans mes tests j'ai 100% de succès (aucun flux n'est illisible) sur plus de 20.000 flux, dont 15% de flux invalides. Et évidemment une seule classe, 17 Ko de code, contre pas loin de 400 Ko pour picoFeed par exemple.

Fotoo Hosting est (toujours) un script permettant de créer un service d'hébergement d'images auto-hébergé (comme imgur par exemple), gérant les albums, mais aussi et surtout le redimensionnement en javascript des images avant envoi, ce qui est très pratique pour envoyer des photos depuis une connexion lente, du coup au lieu d'envoyer des fichiers de 5 Mo ou plus on n'envoie qu'environ 400 Ko par image.

Cette nouvelle version 2.1.0 ajoute des options pour l'administration : stockage des adresses IP des uploaders (avec effacement automatique après la période légale de conservation), possibilité de bannir des IPs (ou des masques ou des ranges même, supporte IPv6), et la suppression de plusieurs images ou albums en même temps.

Toutes les infos ici : Fotoo Hosting

Et bien sûr toujours la démo : i.kd2.org

Fotoo Hosting est (toujours) un script permettant de créer un service d'hébergement d'images auto-hébergé (comme imgur par exemple), gérant les albums, mais aussi et surtout le redimensionnement en javascript des images avant envoi, ce qui est très pratique pour envoyer des photos depuis une connexion lente, du coup au lieu d'envoyer des fichiers de 5 Mo ou plus on n'envoie qu'environ 400 Ko par image.

Cette nouvelle version 2.1.0 ajoute des options pour l'administration : stockage des adresses IP des uploaders (avec effacement automatique après la période légale de conservation), possibilité de bannir des IPs (ou des masques ou des ranges même, supporte IPv6), et la suppression de plusieurs images ou albums en même temps.

Toutes les infos ici : Fotoo Hosting

Et bien sûr toujours la démo : i.kd2.org