Récupération d'articles d'archives

content/interets/informatique/2015/01/15/je-n-aime-pas-le-code-moderne/index.md

@@ -0,0 +1,139 @@
+---
+comments_url: https://com.richard-dern.fr/post/540
+date: '2015-01-15 02:43:38'
+links:
+- lang: fr
+  name: Page d'origine sur LinuxFr
+  url: https://linuxfr.org/users/richarddern/journaux/je-n-aime-pas-le-code-moderne
+tags:
+- PHP
+- Composer
+- Fancy
+- Bibliothèque
+- PSR
+- PEAR
+title: Je n'aime pas le code moderne
+weather:
+  humidity: 83
+  illuminance: 0.0
+  precipitations: false
+  pressure: 1012.0
+  source:
+  - open-meteo
+  temperature: 4.6
+  wind_direction: 205
+  wind_speed: 19.0
+---
+
+Cher journal,
+
+## Avant propos #
+
+Développeur PHP depuis près de dix ans, internaute depuis quinze et geek depuis vingt-cinq, comme tout bon geek, je fais de la veille.
+Je m'intéresse aux nouveautés, j'étudie scrupuleusement les spécifications des langages que j'utilise (soit PHP, Javascript, CSS et HTML), en bref, je me tiens au courant et j'applique les recommandations les plus récentes.
+
+### C'était mieux avant ##
+
+J'adorais Internet.
+Je l'aime toujours, mais moins qu'avant.
+"Avant" ?
+Avant l'avènement des réseaux sociaux.
+
+Similairement, bien que j'aime toujours coder, j'aime le code moins qu'avant.
+"Avant" ?
+Avant l'avènement des frameworks usines-à-gaz qui ne respectent même pas les principes élémentaires de codage ou du modèle [MVC](https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur) (du code logique dans des commentaires ?
+du code brut dans les templates ?).
+
+### Mon framework à moi ! ##
+
+Je travaille depuis quelques temps sur un framework maison, composé d'un loader du même genre que celui de [CakePHP](http://cakephp.org/) mais en plus lisible (```CoreLoader::load_vendor('phpmailer')``` ou ```CoreLoader::load_controller('home')``` par exemple), d'un routeur particulièrement complet (prenant en charge des routes automatiques, les droits des utilisateurs en fonction de la route demandée, etc.), de templates, etc.
+
+Bien que j'ai codé moi-même le gros du framework, l'idée reste qu'il s'agisse d'une agrégation des meilleures librairies dans leur domaine respectif:
+
+- [PHPMailer](https://github.com/PHPMailer/PHPMailer)
+- [Redbean](http://www.redbeanphp.com/welcome)
+- [Smarty](http://www.smarty.net)
+- etc.
+
+## Changement de cap #
+
+### La philosophie du Libre ##
+
+Hier, j'ai eu une épiphanie:
+
+> "Hey, coder toi-même ce qui existe déjà ?
+> Pas trop la philosophie du Libre !"
+
+Ok.
+Ça implique - apparemment - d'utiliser des trucs ~~tout moches~~ modernes du genre [composer](https://getcomposer.org/).
+Bon, allez, je m'y colle.
+
+Je cherche un peu une librairie pour remplacer mon routeur, et je tombe sur un certain nombre d'entre elles:
+
+- [klein](https://github.com/chriso/klein.php)
+- [Toro](https://github.com/anandkunal/ToroPHP)
+- [Aura](https://github.com/auraphp/Aura.Router)
+
+Et puis tiens, [PHP-Error](https://github.com/JosephLenton/PHP-Error) pourrait être pas mal.
+
+### La déconvenue ##
+
+> Oh !
+> Il y a un éditeur intégré pour modifier le code en direct quand une erreur se présente !
+> Cool !
+> Oh, ça m'enregistre un fichier presque vide quand il y a un antislash dans un namespace !
+> Bon, ben encore une application moderne qui mise sur l'apparence et qui en fait est tout bugguée...
+
+Mon application de test n'est pas à la racine.
+Aucun problème pour mon routeur, mais _klein_ ne fonctionne pas sans _.htaccess_ pour le rewrite, _Aura_ est beaucoup trop gros et aucun des trois ne matche mes routes sur la variable _PATH_INFO_ mais sur le chemin relatif depuis _DOCUMENT_ROOT_.
+Bizarre...
+
+### Cause et effet ##
+
+De façon assez étrange, ni _Smarty_, ni _Redbean_ ne mentionnent _composer_ dans leur documentation, et _PHPMailer_ s'en passe parfaitement.
+D'ailleurs, j'aime beaucoup [la raison avouée pour laquelle l'auteur de _Redbean_ ne propose pas de package _composer_](http://www.redbeanphp.com/download).
+Certe, les trois peuvent s'installer via le gestionnaire de dépendances, mais de manière plus ou moins officieuse.
+
+Personnellement, j'ai bien envie de tomber dans la facilité et voir un lien entre la qualité des librairies, le fait que _composer_ soit obligatoire ou non pour les installer, et la vétusté/simplicité de leur site Internet.
+
+J'ai testé pas mal d'autres librairies encore et je constate une chose: une grosse partie a une page web créée avec [Bootstrap](http://getbootstrap.com/).
+Encore des clones de _bootstrap_...
+Certains mieux réalisés que d'autres toutefois, mais on sent toujours cette patte _bootstrap_, c'en est désespérant.
+Ni _Redbean_, ni _Smarty_ n'utilisent _bootstrap_ sur leur site.
+
+Là encore, j'ai envie de tomber dans la facilité: comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de _bootstrap_, ou du moins, faire en sorte que ça ne se voit pas ?
+
+Du coup, je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.
+
+### Le mal-aimé ##
+
+En parlant de popularité, autre exemple: [PEAR](http://pear.php.net/).
+
+_PEAR_ existait avant _composer_.
+Avoir sa librairie disponible sur _PEAR_ était, à une époque, la quintessence, l'aboutissement, une reconnaissance extrême.
+Bien sûr, _PEAR_ est un framework alors que _composer_ est un gestionnaire de dépendances, mais tout de même.
+Aujourd'hui, tout le monde boude _PEAR_, à part [Horde](http://www.horde.org/) et quelques irréductible de ce que j'appelle l'artisanat du web, vestige d'une époque où le code devait être bien écrit, quasiment exempt de bugs, et fonctionner partout sans la moindre nécessité d'adaptation.
+Il semblerait qu'on ait perdu cette versatilité au prix d'artifices plus ou moins alambiqués (genre certains design-patterns, les [namespaces](http://php.net/manual/en/language.namespaces.php), les [traits](http://php.net/manual/en/language.oop5.traits.php), etc.).
+
+### Interopérable ? ##
+
+Le pire, c'est que toutes ces libs modernes suivent les recommandations [PSR](https://github.com/php-fig/fig-standards), donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.
+
+D'ailleurs, je crois que les "standards" recommandés par le PHP-FIG ne servent qu'à _composer_.
+Il y a évidemment quelques bonnes idées dedans (UTF-8 sans BOM, _LoggerInterface_, etc.) qui contribuent effectivement et efficacement à l'interopérabilité des librairies PHP, mais désormais, je fuirai les librairies arborant fièrement avoir suivi ces recommandations parce que cela signifie qu'il va être pratiquement impossible de les utiliser sans _composer_ (qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives).
+
+### On n'est jamais mieux servis que par soi-même ##
+
+Au final, je vais faire ce que j'ai toujours fais: continuer de tester des librairies, et intégrer à mon framework les meilleures d'entre elles, les plus simples à installer et utiliser, même si elles devaient être quelque peu obsolètes ([simplepie](https://web.archive.org/web/20150302151026/http://simplepie.org/) par exemple).
+
+Pour ceux que ça intéresse, voici les différentes librairies que j'utilise, outre _Redbean_, _PHPMailer_ et _Smarty_ (sans _composer_ et sans les avoir modifier de quelque manière que ce soit):
+
+- [Munee](http://mun.ee/) - concaténation et minification à la volée de CSS et JS avec support de less, scss, coffescript, etc.
+- [Parsedown](https://github.com/erusev/parsedown) - parser [markdown](http://daringfireball.net/projects/markdown/syntax)
+- [phpass](http://sunnyis.me/blog/secure-passwords/) - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish
+
+### Happy end, quand même ##
+
+Je note tout de même que cette expérience m'a tout de même apporté de bonnes surprises, comme [monolog](https://github.com/Seldaek/monolog), [sentry](https://github.com/cartalyst/sentry) ou [climate](https://github.com/thephpleague/climate) que j'intégrerai peut être à mon framework, malgré l'utilisation "nécessaire" de _composer_ et leur usage abusif des namespaces...
+
+Ou bien je coderai mes propres libs, les distribuerai sous licence Libre, hors _composer_, en mentionnant que j'ai une approche plus conservatrice du dév...

content/interets/informatique/2015/02/05/auto-hebergement-pas-toujours-evident/index.md

@@ -0,0 +1,158 @@
+---
+comments_url: https://com.richard-dern.fr/post/541
+date: '2015-02-05 15:54:27'
+links:
+- lang: fr
+  name: Page d'origine sur LinuxFr
+  url: https://linuxfr.org/users/richarddern/journaux/auto-hebergement-pas-toujours-evident
+tags:
+- NAS
+- Cloud
+- Serveur
+- Auto-hébergement
+- Edward Snowden
+- Heartbleed
+- Shellshock
+title: 'Auto-hébergement: pas toujours évident...'
+weather:
+  humidity: 69
+  illuminance: 17484.600000000002
+  precipitations: false
+  pressure: 1013.1
+  source:
+  - open-meteo
+  temperature: -1.5
+  wind_direction: 46
+  wind_speed: 23.9
+---
+
+L'auto-hébergement a toujours été défini comme une alternative saine aux offres de stockage en ligne proposées par exemple par Amazon, Google ou Microsoft.
+Héberger chez soi ses propres données est un gage de sécurisation et de préservation de la confidentialité de ses données personnelles.
+
+Il y a eu une période au cours de laquelle on trouvait toute une panoplie d'applications Libres pour réussir son auto-hébergement.
+On avait du choix, les applications étaient techniquement abouties et complètes.
+Puis il y a eu une période de creux.
+Une période pendant laquelle de nombreux projets ont été abandonnés, faute de temps et de moyens.
+
+L'auto-hébergement retrouve désormais des couleurs, non pas sans rapport avec l'affaire Snowden, les atteintes quotidiennes à la liberté d'expression ou à la confidentialité, ou le vol de données privées.
+Malheureusement, le florilège des applications libres destiné à cet usage s'est réduit, et concilier sécurité, simplicité et fonctionnalités devient difficile.
+
+## Auto-hébergement et NAS #
+
+_**Sécurité:** moyen_ _**Simplicité:** excellent_ _**Fonctionnalités:** bon, mais..._
+
+Les NAS "physiques" (comprendre: Synology, QNAP, etc.) offrent généralement un système de paquets logiciels permettant d'étendre leurs fonctionnalités: serveur web, serveur multimédia, serveur mail, etc. Cela permet de grandement simplifier leur installation bien sûr, mais au détriment - généralement - de leur "paramétrabilité".
+
+Quand on a un accès root au système sous-jacent, les manques sont rapidement comblés par les connaisseurs.
+Quant aux utilisateurs lambda, ils utilisent ce qu'ils ont sous la main.
+
+Le problème avec les NAS concerne surtout leur niveau de sécurité.
+Plus exactement, leur niveau de sécurité dépend de la réactivité des constructeurs à sortir des mises à jour en cas de problème.
+L'actualité récente ([HeartBleed](https://linuxfr.org/news/nouvelle-vulnerabilite-dans-l-implementation-openssl), [ShellShock](https://linuxfr.org/news/une-faille-nommee-shellshock), etc.) nous a montré - si besoin était encore - que les systèmes fermés contraignent les utilisateurs à attendre que les constructeurs sortent des correctifs.
+Un paradigme insupportable pour les défenseurs du Libre, à juste titre puisque cela affecte la sécurité et la confidentialité des données.
+Cela soulève donc la question de la confiance que l'on choisi d'accorder à un système de stockage de données qui contiendra - a fortiori - des données privées.
+Autrement dit, confier ses données à un NAS dont le système n'est pas (totalement) libre serait équivalent à confier ses données à un hébergeur dans le cloud.
+
+Au final, les NAS offrent une grande simplicité (l'installation peut se faire en un gros quart d'heure), au détriment des fonctionnalités et surtout de la sécurité.
+Je ne crois pas qu'il s'agisse d'une bonne solution pour faire de l'auto-hébergement à cause de ça.
+Quand on veut s'auto-héberger, c'est pour contrôler le stockage, et donc avoir confiance dans son système de stockage.
+
+## Un serveur _home-made_ #
+
+_**Sécurité:** excellent_ _**Simplicité:** peut mieux faire_ _**Fonctionnalités:** excellent mais..._
+
+À l'autre opposé, on a la possibilité de monter son propre serveur.
+Dans ce cas là, la sécurité n'est plus dictée "que" par le bon sens de l'administrateur, et sa connaissance des outils de base.
+Bien sûr, on ne joue plus dans la même cours que les NAS: monter un serveur soi même est loin d'être aussi simple et requiert un certain nombre de compétences pour être capable de le sécuriser.
+Mais le gain en terme de fonctionnalités est incommensurable, sauf que...
+
+Le problème avec le serveur fait soi-même, je l'ai évoqué dans le premier paragraphe de ce journal.
+Il y a pour ainsi dire une certaine pénurie d'applications Libres dédiées à l'auto-hébergement.
+
+### Cas du client mail ##
+
+#### Le webmail, tout simple ###
+
+Un exemple concret: le webmail.
+
+Il y a quelques temps, on avait:
+
+- [Squirrelmail](http://www.squirrelmail.org/)
+- [Horde + IMP](http://www.horde.org/)
+- [Roundcube](http://roundcube.net/)
+- [@mail](http://www.atmail.org/)
+- [Xuheki](https://web.archive.org/web/20150511043342/http://www.xuheki.com/)
+- [Hastymail](http://www.hastymail.org/)
+
+Aujourd'hui, on a:
+
+- Roundcube
+- [Mailpile](https://www.mailpile.is/)
+
+Ces listes sont loin d'être exhaustives, mais le but est de montrer que le choix s'est grandement limité avec le temps, pour différentes raisons.
+
+Squirrelmail n'est pratiquement plus utilisable aujourd'hui, et Horde non plus dans une moindre mesure.
+Dans le cas du premier, l'austérité de son interface rebute les nouveaux utilisateurs, déjà habitués aux interfaces léchées, claires, pleines d'icônes et dynamiques.
+Et bien que Horde ait su mieux moderniser son interface, elle reste en retrait par rapport à la concurrence.
+D'ailleurs, son remplacement au profit de Roundcube dans un certain nombre de packages est révélateur (par exemple, [Kolab](http://kolab.org/) n'offre plus Horde comme client depuis la version [3.0](http://kolab.org/news/2014/11/29/final-version-kolab-3.0-released)).
+
+Les développeurs des autres solutions Libres ont simplement jeté l'éponge depuis 2013, voire avant.
+@mail est d'ailleurs probablement l'exemple le plus décevant puisque le projet Libre a été abandonné au profit d'une version sous licence non libre et qu'aucun fork n'existe depuis six ans.
+
+Tout cela importerait peu si Roundcube et Mailpile n'étaient pas si "pauvres".
+Roundcube par exemple, bien que doté d'un système de [plugins](http://plugins.roundcube.net), souffre du manque de support du chiffrement et de la signature des mails: cela fait quelques années déjà que le support de GPG/PGP/SMIME est dans [leur roadmap](http://trac.roundcube.net/milestone/later), et leur dépôt de plugins ne liste que des modules pour vérifier les signatures, pas pour chiffrer.
+Pas possible non plus d'envoyer un mail différé par exemple.
+
+D'autre part, le seul plugin existant pour gérer un calendrier est celui de...
+[Kolab](https://web.archive.org/web/20150407045310/http://plugins.roundcube.net/packages/kolab/calendar), et [ne supporte que des backends MySQL ou Kolab](http://git.kolab.org/roundcubemail-plugins-kolab/tree/plugins/calendar/README).
+Exit donc caldav ou les rappels automatiques.
+
+Quant à Mailpile, bien que l'accent soit mis sur la sécurité, et donc un support natif de GPG, il n'a pas de gestion de dossiers, pas de panneau de visualisation, et encore moins de calendrier avec rappel, ou de gestion des filtres.
+Il est en phase de beta, ces manques pourraient être comblés à l'avenir, mais pour l'heure, ce n'est pas une solution viable pour le commun des mortels.
+
+#### La solution tout-en-un ###
+
+Il apparait donc qu'une solution plus adéquate, ou en tout cas plus souple, plus complète, est la solution tout-en-un, _aka_ groupwares.
+C'est un compromis entre l'abondance des fonctionnalités, la simplicité d'installation et d'utilisation, et la sécurité.
+
+Et là, les outils Libres sont un peu plus nombreux.
+Sans parler de Kolab qui repose sur Roundcube, je citerai [Citadel](http://www.citadel.org), mais surtout [Zimbra](http://www.zimbra.com/), que j'ai adopté avec une immense satisfaction.
+
+### Le cas des galeries photos ##
+
+Un autre exemple auquel j'ai été récemment confronté: la gestion de galeries de photos.
+
+Historiquement, je me suis toujours tourné vers [Gallery](http://galleryproject.org/).
+Et puis j'ai eu un Synology entre les mains, avec PhotoStation, que je trouvais tout simplement parfait: l'authentification se faisait auprès du serveur LDAP, les permissions d'accès étaient celles du système de fichiers, et les photos étaient dans l'arborescence du dossier dédié.
+
+Gallery pourrait toujours faire tout ça, et remplacer avantageusement PhotoStation, non libre.
+Mais le projet est mort.
+En "hibernation" depuis juin dernier.
+Plus de mises à jour, donc potentiellement plus sécurisé.
+
+Je n'ai pu trouver aucun remplaçant à Gallery, bien que cette fois, les solutions soient nombreuses.
+Pas de support de LDAP, obligation de stocker les photos dans l'arborescence de l'application, pas de liberté dans la structure des fichiers, pas d'affichage des données EXIF, il manque toujours quelque chose.
+
+### Le cas de la gestion des utilisateurs ##
+
+Quand on monte son serveur et qu'on gère quelques utilisateurs, on a envie de le faire bien, et permettre aux utilisateurs d'utiliser le même identifiant et le même mot de passe pour tous les services hébergés.
+Cela permet aux utilisateurs d'utiliser une seule interface pour gérer leur compte.
+Par ailleurs, l'attribution et la gestion des droits en est simplifiée pour l'administrateur.
+Tout simplement une bonne pratique héritée des grosses structures.
+
+Là encore on doit faire face à l'absence d'un tel système, pourtant bien présent dans les NAS.
+
+Suite à un [commentaire de NeoX](https://linuxfr.org/nodes/104672/comments/1586596), j'utilise désormais [SSP](http://ltb-project.org/wiki/documentation/self-service-password).
+C'est parfait pour changer son mot de passe, mais quid des autres informations personnelles ?
+On pourrait par exemple supposer que certains utilisateurs préfèreraient un shell différent de celui attribué par défaut, ou la possibilité de changer son avatar, son téléphone, son adresse, etc. Je n'ai pas pu trouver une telle application.
+
+Il y a bien [MDS](http://projects.mandriva.org/projects/mmc/wiki/Start) qui offre ces fonctionnalités, mais apparemment ne supporte pas les champs LDAP _SambaNTPassword_ et _SambaLMPassword_, qui évitent notamment une manipulation dans le registre des clients Windows relative au chiffrement des mots de passe.
+
+## Conclusion #
+
+**L'auto-hébergement est vital**.
+C'est peut être long et fastidieux, mais c'est enrichissant, intéressant, en plus d'être gage de protection de la confidentialité.
+
+Malheureusement, tant qu'on ne retrouvera pas la diversité des applications existantes avant l'avènement du cloud, et tant qu'elles ne conjugueront pas la simplicité des applications livrées avec les NAS avec l'exhaustivité typique des applications Libres, je crois que l'auto-hébergement (hors NAS) restera plus ou moins marginal, réservé à une population de connaisseurs, et par conséquent, et malgré les faits d'actualité, le commun des mortels ne pourra pas pleinement mesurer son importance.
+
+Il faut voir le bon côté des choses: on pourra toujours leaker des photos compromettantes...

content/interets/informatique/2015/03/02/cyca-gestionnaire-de-signets-et-de-flux-open-source/index.md

@@ -0,0 +1,52 @@
+---
+comments_url: https://com.richard-dern.fr/post/542
+date: '2015-03-02 17:15:30'
+links:
+- lang: fr
+  name: Page d'origine sur LinuxFr
+  url: https://linuxfr.org/users/richarddern/journaux/cyca-gestionnaire-de-signets-et-de-flux-open-source
+tags:
+- RSS
+- Signet
+- Marque-page
+title: 'Cyca: gestionnaire de signets et de flux open-source'
+weather:
+  humidity: 82
+  illuminance: 19385.100000000002
+  precipitations: false
+  pressure: 1011.0
+  source:
+  - open-meteo
+  temperature: 5.7
+  wind_direction: 267
+  wind_speed: 30.3
+---
+
+Bonjour à tous.
+
+J'aimerais vous parler aujourd'hui du projet personnel qui me tient le plus à coeur, celui sur lequel je travaille depuis le plus longtemps.
+L'application s'appelle Cyca, et c'est un gestionnaire de signet et de flux.
+
+![Titre de l'image](images/cyca.jpeg "Source : http://athaliasoft.com/files/cyca.jpeg")
+
+Son histoire commence il y a une dizaine d'années.
+Elle était écrite en C# à l'origine, s'appellait Bookmarks Manager et s'inspirait de NetSignets.
+Elle s'est appelée Cyca pour la première fois lorsque [je l'ai publiée en closed-source en 2008](http://www.toucharger.com/fiches/windows/cyca/26686.htm).
+Trop timide pour exposer son code...
+
+Depuis, je l'ai écrite en PHP, et plusieurs versions se sont succédées, sans jamais être publiées.
+Là encore, question de timidité.
+
+Mais aujourd'hui, je suis plus confiant dans mon code, dans l'intérêt que Cyca peut représenter, et de la fiabilité globale de l'application.
+Malgré tout, j'ai souhaité revoir mon versionning.
+C'est pourquoi aujourd'hui, ce n'est pas Cyca 8 ou 9 que je vous présente, mais Cyca 0.0.1.
+Du coup, j'ai opté pour une licence libre (GNU GPL).
+
+Réécrite from scratch, plus souple, plus esthétique, le moment est venu de se montrer sous un nouveau jour, une nouvelle naissance en quelque sorte.
+
+En conséquence, j'avais envie de partager ce moment avec vous, et que vous partagiez avec moi vos retours.
+Si l'application vous intéresse et que vous tentez l'installation, pensez à jeter un oeil aux [tickets ouverts](https://git.athaliasoft.com/athaliasoft/Cyca/issues).
+
+- [Site officiel](https://web.archive.org/web/20150315003033/https://getcyca.com/)
+- [Captures d'écran](https://web.archive.org/web/20150315003033/https://getcyca.com/screenshots/)
+- [Dépôt git](https://git.athaliasoft.com/athaliasoft/Cyca)