Dans tous les cas c'est une manière de se définir par la négation d'autre chose au lieu de dire ce que c'est vraiment. Et du coup c'est un fourre-tout.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Les migrations auto générées peuvent être problématiques en terme de performance.
Mais tu le dis toi-même : il faut faire des migrations (SQL ou python, peu importe). Et la structure des bases SQL assuré l'intégrité des données largement mieux que des migrations écrites à la main et garantes de l'intégrité et de la cohérence des données.
À l'époque j'avais regardé orientdb qui était séduisant notamment pour son approche orientée graphe, mais au final je suis resté sur Postgresql et ça répond à tous les besoins auxquels j'ai eu à faire face.
Les projets sur lesquels j'ai vu du Mongo ont migré sur des solutions SQL dès qu'il a fallu s'assurer de l'intégrité forte des données.
J'ai vu des projets utiliser efficacement du Redis (-valeur) voire Elastic search comme base.
Le principe de se définir en "non quelque chose" n'a pas de sens pour moi : une base orientée graphe ne réponds pas aux mêmes usages qu'une base orientée documents ou une clé valeur.
À mon sens (rôle d'architecte logiciel) le sujet des migrations est le dernier des arguments pour choisir une base NoSQL : l'intégrité et la cohérence des données doit être assurée dans une application pérenne, et SQL est le meilleur outil pour que ces qualités soient assurées (bien plus que la performance des ingénieurs qui vont écrire les migrations).
Dernier retour d'expérience : avec le JSON embarqué dans Postgresql, tu peux faire du requêtage spécifique du coup je n'ai pas en tête de cas de figure où Postgresql ne répondrait pas.
Note : tout ce que je dis ici n'intègre pas les problématiques de scalabilité mais uniquement les problématiques de stockage, requêtage, d'intégrité des données et de maintenabilité du code associé.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je ne crois pas plus à CalVer qu’aux bonnes résolutions du nouvel an. ^
C'est pas une croyance c'est une stratégie de sorties :
soit tu établis une roadmap basée sur des fonctionnalités dans des versions et du coup tu sais ce que va contenir telle ou telle version mais tu ne sais pas quand elle va sortir
soit tu établis une roadmap et un rythme de versions et tu sais qu'elles sont les priorités, à quelle date sortent les versions mais tu ne sais pas quelle fonctionnalité arrive dans quelle version.
Un logiciel n'étant jamais terminé, le rythme régulier semble une bonne stratégie.
Quelques années en arrière, rappelons nous des versions Debian qui sortaient quand elles sortaient… Un certain nombre ont migré vers d'autres distributions faute de nouveauté disponible dans Debian stable.
Si l'on s'intéresse à la valeur apportés aux utilisateurs, il vaut mieux sortir des versions souvent car à chaque fois on apporte un peu plus de valeur (même s'il s'agit "juste" de quelques corrections de bugs) plutôt que des gros apports mais qui tardent à arriver.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Évidemment que ça ne remet pas en cause le fait de faire des notes de release.
Ce que je dis c'est que les clients qui sont en SaaS ils se fichent de la numérotation.
Les clients on premise veulent savoir que ça bouge et quand. Les livraisons régulières sont là pour ça ; une numérotation des versions basée sur la date va dans le même sens.
Contrairement à ce que tu dis une numérotation temporelle aide les clients à voir que ça bouge car à tout moment ils peuvent faire le lien spontanément entre la date courante et la date de sortie de la dernière version. Ce n'est pas le cas avec notre numérotation actuelle.
C'est là toute la subtilité de ce type de nommage des versions : pas besoin de connaître la stratégie de sortie des versions pour savoir de quand ça date. C'est intuitif et immédiat.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
on sort des versions de développement toutes les 2 ou 4 semaines
on sort des versions officielles chaque trimestre
les migrations de données sont intégrées à chaque version officielle
les migrations de configuration sont documentées à chaque version officielle
on ne casse les APIs qu'exceptionnellement - ça peut se documenter (c'est d'ailleurs ce qu'on fait)
les clients "on premise" veulent des mises à jour et des notes de release pour les nouveautés. Un versioning ou un autre n'a jamais été réclamé
les clients "SAAS" ne se posent pas de questions : ils ne s'intéressent pas aux numéros de version.
même pour nous, on ne sait pas de quelle version vient une fonctionnalité : on se rappelle grosso modo quand elle a été développée mais impossible de faire un lien spontané avec un numéro de version - il faut passer par les notes de release.
En écrivant ce commentaire ça me conforte encore un peu plus d'aller vers ce type de numérotation…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Déjà le sujet m'interpelle : avoir moins de 2% de parts de marché et être au bord du gouffre sont deux choses décorrélées. On peut avoir des parts de marché conséquentes et être au bord du gouffre, et inversement. Les marché de niche, ça a toujours existé et c'est des pouillèmes de PDM. Mais ça veut dire "accepter d'être sur un marché de niche"
L'article dit ceci :
Firefox se rapproche ainsi dangereusement des 2 % de part de marché en dessous duquel certains sites Web gouvernementaux (américains et britanniques, par exemple) cessent de supporter un navigateur.
Ce qui signifie effectivement que le seuil des 2% est critique … aux États-Unis (et en Angleterre si je suis ce qui est dit dans l'article) mais quid du reste du monde ? Oui ok ça fait pas rêver, mais le principe des marchés de niche c'est ça justement : ne pas être partout.
Mozilla est aujourd'hui en compétition avec Google et Apple … n'est-ce pas juste qu'il faut accepter de perdre cette bataille et s'attaquer à une bataille qui serait adaptée aux moyens de la fondation ? (qui n'ont rien à voir avec les moyens de Google, il faut rester lucide)
Une telle situation pourrait précipiter l'effondrement du navigateur.
L'effondrement n'est pas lié aux 2% mais au modèle économique de la fondation qui est largement tributaire du financement qu'elle obtient … de son principal concurrent.
Le monde du logiciel libre n'aime pas l'idée de "faire de l'argent" mais la réalité c'est que l'argent c'est juste la représentation de la valeur que les gens donnent à ce que l'on fait et le moyen de transférer le fruit de son travail à une autre personne ou organisation.
Trouver un modèle économique viable, c'est la base, qu'on soit une entreprise, une association, un individu (tu veux une belle maison, bah il faut en face le revenu qui permet d'avoir cette belle maison - ou alors faire des efforts sur ton temps libre pour réduire les coûts d'acquisition et d'entretien).
Dans la communauté, le débat est très animé, la question étant de savoir comment Firefox en est arrivé à ce stade.
La question n'est pas tellement de savoir comment on en est arrivé là - ou plutôt comment Firefox en est arrivé là mais où ça peut aller.
La fondation appelle-t-elle à l'aide sa base d'utilisateurs convaincus ? Fait-elle le nécessaire pour que ces utilisateurs mettent la main à la pâte ?
Comme dit par ailleurs : les utilisateurs cherchent d'abord des fonctionnalités. La protection des données en est une, la performance aussi … mais aujourd'hui ça n'a pas l'air d'être les fonctionnalités les plus recherchées.
Innover, c'est le principe pour rester dans la course. La fondation est largement capable d'innover - Rust vient de chez eux, il me semble. Mais aujourd'hui, je ne vois plus d'innovation dans Firefox.
Je fais partie des utilisateurs convaincus et pourtant à chaque mise à jour Firefox ne met à ne plus fonctionner en attendant que je le redémarre. Ça me gonfle mais je suis pour le moment toujours convaincu. Mais je n'ai aucun argument pour dire à mon entourage de passer sur Firefox au lieu de Chrome ou Opéra. Le seul argument que j'ai, c'est "google c'est mal" ; mais un véritable argumentaire se base sur des aspects positifs, pas sur du négatif.
L'article évoque un point intéressant à travers un commentaire obtenu durant l'étude de Wray :
la seule chose qui arrête Firefox en ce moment, c'est Mozilla lui-même. C'est ridicule. Mozilla rapporte un demi-milliard de dollars par an. S'ils ne peuvent pas construire un navigateur Web largement utilisé pour cet argent, il y a quelque chose qui ne va pas
Ça me semble lucide …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
J'avais entendu parler d'une distinction chez Nextcloud aussi mais de ce que j'avais compris, c'était plutôt une approche type Redhat (c'est open source mais pas public).
Mais je n'ai pas trouvé d'information confirmant ça.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Cela marque une nouvelle étape dans la décentralisation informatique à l’échelle mondiale.
Je suis dubitatif, je ne vois pas ce qu'apporte Nextcloud en terme de décentralisation par rapport à ce que permettait déjà Roundcube.
Développer le produit, l'activité en respectant les valeurs du libre : oui.
Ou alors Nextcloud prévoit de faire du marketing pour mettre Roundcube sur le devant de la scène à des endroits où les organisations utilisent aujourd'hui du logiciel propriétaire ou du logiciel centralisé ?
Fonctionnellement, j'avais cru comprendre que SOGo était plus riche (délégation de gestion de dossiers par exemple) - et plus proche de ce que permettent les solutions concurrentes avancées (Microsoft, Bluemind), ce qui me laisse penser que les organisations s'orienteraient plutôt vers ces solutions.
Mais là, justement, ce discours aurait plutôt tendance à éveiller ma vigilance car ça sonne creux (ce qui n'est généralement pas le cas avec Nextcloud)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Ça c'est sûr que c'est un carnage le web. Le business s'en est emparé… Ya qu'à faire un tour en ligne sans bloqueur de pub :-(
Mais c'est aussi un environnement extrêmement complexe si tu veux faire les choses bien. On parlait de cache ; mais si tu veux faire qqchose d'adaptatif, accessible, bien référencé, performant, sexy, …
En tout cas on a bien fait de discuter :-)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
C'est pas un comportement nouveau : le support utilisateur ça existe depuis des années et c'est à l'opposé de la pureté qu'on cherche quand on fait de la conception (de site, de logiciel, etc). C'est du "damage control".
Ce que je dis c'est pas que le site est bien et que tout va bien ; ce que je dis c'est qu'il faut critiquer avec un peu d'humilité.
Concernant le cache quand on développe un site on est tributaire de la stratégie des navigateurs. Par défaut on ne fait rien mais le butineurs décide de mettre des trucs en cache. Du coup on peut passer des entête HTTP pour dire "ne met pas ça en cache", ce genre de truc, mais en fait c'est pas unanimement respecté.
Du coup la solution pour avoir un truc qui marche et qui est maîtrisé, c'est :
de régénérer des urls à chaque mise à jour du contenu pour être certain que le contenu ne viendra pas du cache. Exemple : https://mon.site/JS/all.js?token=abcd. On se fait ch… à développer des trucs pour empêcher le browser de mettre en cache
comme c'est pourri d'un point de vue performance, on ajoute les entêtes pour dire au navigateur de mettre en cache pendant 1 an, comme ça ça va pas recharger.
Au final on est obligé de réimplanter le mécanisme d'optimisation tout en s'assurant qu'on court-circuite les initiatives du navigateur.
À chaque ajout de ressources il faut être vigilant et forcément il arrive qu'il y ait des ratés.
Donc non, c'est pas un problème de compétence.
C'est un sujet complexe et fragile.
Je comprends que ça fait ch… Mais c'est pas les dev ni le support le problème - en tout cas pas plus que l'utilisateur. (Note : je suis pas concerné par ce problème directement, c'est juste un comportement que je retrouve régulièrement et qui m'agace)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Il a suivi une voie alternative …et la réaction du support montre que ce n’est pas un conseil mais la récitation d’un mantra ou d’une prière.
le support a identifié que c'est un problème de cache au niveau du navigateur, ou plus exactement qu'on peut contourner le problème en purgeant le cache
le support sait que purger le cache des autres sites n'a rien à voir mais le support met au point une réponse standard qui permet de résoudre le problème pour tous les utilisateurs, quel que soit leur compréhension et leur dextérité technique
parenthèse, l'auteur du journal est également incompétent puisque il ne sait pas que l'outil qu'il utilise au quotidien permet de purger distinctement les données site par site, ce qui devrait l'inciter à un jugement un peu moins définitif et à un peu plus d'humilité (paille, poutre, tout ça)
quand on fait du support on rationalise les solutions et on évite les hypothèses difficiles à évaluer (le niveau de compréhension de l'interlocuteur fait partie de ces sujets) et on ne cherche pas à optimiser la manière de faire mais à maximiser les chances de réussite.
Pour le reste, je te laisse juger de la pertinence du titre et du ton du journal à la lumière de ces éléments.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Les email tu les perds. Et tu redemandes l'info. Comme c'est dématérialisé personne n'y accorde d'importance - il faut donc que pôle emploi garde une copie.
À partir de là, quel intérêt d'envoyer des documents par email alors qu'on peut proposer qqchose de mieux sur le plan du suivi historique d'un dossier ? Tous les documents sont centralisés et accessibles via un site unique. La conservation des données est assurée par pôle emploi qui n'aura donc pas de litige à gérer parce qu'un chercheur d'emploi a supprimé "par erreur son mail"…
Il ne faut pas prendre les utilisateurs pour des c.. mais il est attendu aujourd'huide tous les services numériques qu'ils protègent les utilisateurs d'eux même.
Ça vaut pour tous les services numériques, des serveurs OVH (souvenez-vous l'hiver mais pas le dernier) aux drive Google (coucou l'actu) en passant par tous les services gratuits ou payants (qui va se retenir de grogner si twitter, linuxfr ou autre perd toutes les données des utilisateurs ?)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Si tu prévois de faire les choses via des liens <a href="xxx">Supprimer</a> alors il faut utiliser des GET et du coup l'archi serait plutôt :
GET pour des requêtes en lecture uniquement ou des action simples (exemple : supprimer une entité, activer/désactiver un utilisateur, etc)
POST pour tout le reste (création, modification)
Routage
À partir de ce qui a été dit au dessus, le routage suivant me semble clair et intuitif :
GET http://foo.bar/entities pour récupérer la liste
GET http://foo.bar/entities/<id> pour récupérer une entité précise
POST http://foo.bar/entities pour créer une entité
POST http://foo.bar/entities/<id> ou POST http://foo.bar/entities/<id>/update pour modifier une entité
POST http://foo.bar/entities/<id>/delete pour supprimer une entité
Ce à quoi tu peux envisager d'ajouter des routes du style :
POST http://foo.bar/entities/<id>/activate pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)
POST http://foo.bar/entities/<id>/archive pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)
D'une manière générale
cherche à standardiser ton architecture de routage. si tu mets la suppression en GET car accédé via un lien, alors utilise uniquement POST pour la création et modification et mets toutes les actions spécifiques en GET
dis-toi que tout ce qui est en GET va rester dans l'historique du navigateur et donc proposé en auto-complétion - donc potentiellement ça peut poser problème d'un point de vue utilisateur (par exemple : re-suppression sans faire exprès car mauvaise URL sélectionnée dans l'autocomplétion de firefox)
tout ce qui passe en GET est visible sur les intermédiaires. Tu trouves dans les logs Apache / NGINX les routes avec les paramètres GET. Typiquement, ne mets pas de données sensibles en GET (exemple : mot de passe, email, etc)
les paramètres GET sont généralement exploités pour faire du filtrage, par exemple : http://foo.bar/events/?owner=4&category=birthday&after=2023-10-16T00:00:00
s'il s'agit de pages accessibles publiquement, les GET sont généralement crawlés par les moteurs de recherche
J'ai fait un petit tour de ce qui me vient à l'esprit, n'hésite pas si tu veux approfondir des trucs.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: PostgreSQL partout
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4. Dernière modification le 28 décembre 2023 à 21:50.
Dans tous les cas c'est une manière de se définir par la négation d'autre chose au lieu de dire ce que c'est vraiment. Et du coup c'est un fourre-tout.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: PostgreSQL partout
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Les migrations auto générées peuvent être problématiques en terme de performance.
Mais tu le dis toi-même : il faut faire des migrations (SQL ou python, peu importe). Et la structure des bases SQL assuré l'intégrité des données largement mieux que des migrations écrites à la main et garantes de l'intégrité et de la cohérence des données.
À l'époque j'avais regardé orientdb qui était séduisant notamment pour son approche orientée graphe, mais au final je suis resté sur Postgresql et ça répond à tous les besoins auxquels j'ai eu à faire face.
Les projets sur lesquels j'ai vu du Mongo ont migré sur des solutions SQL dès qu'il a fallu s'assurer de l'intégrité forte des données.
J'ai vu des projets utiliser efficacement du Redis (-valeur) voire Elastic search comme base.
Le principe de se définir en "non quelque chose" n'a pas de sens pour moi : une base orientée graphe ne réponds pas aux mêmes usages qu'une base orientée documents ou une clé valeur.
À mon sens (rôle d'architecte logiciel) le sujet des migrations est le dernier des arguments pour choisir une base NoSQL : l'intégrité et la cohérence des données doit être assurée dans une application pérenne, et SQL est le meilleur outil pour que ces qualités soient assurées (bien plus que la performance des ingénieurs qui vont écrire les migrations).
Dernier retour d'expérience : avec le JSON embarqué dans Postgresql, tu peux faire du requêtage spécifique du coup je n'ai pas en tête de cas de figure où Postgresql ne répondrait pas.
Note : tout ce que je dis ici n'intègre pas les problématiques de scalabilité mais uniquement les problématiques de stockage, requêtage, d'intégrité des données et de maintenabilité du code associé.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Déjà annoncé
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien LibreOffice 24.2, prochain successeur de LibreOffice 7.6, est disponible en version beta. Évalué à 3.
C'est pas une croyance c'est une stratégie de sorties :
Un logiciel n'étant jamais terminé, le rythme régulier semble une bonne stratégie.
Quelques années en arrière, rappelons nous des versions Debian qui sortaient quand elles sortaient… Un certain nombre ont migré vers d'autres distributions faute de nouveauté disponible dans Debian stable.
Si l'on s'intéresse à la valeur apportés aux utilisateurs, il vaut mieux sortir des versions souvent car à chaque fois on apporte un peu plus de valeur (même s'il s'agit "juste" de quelques corrections de bugs) plutôt que des gros apports mais qui tardent à arriver.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Ça me donne un peu envie de versionner comme ça pour Tracim...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien LibreOffice 24.2, prochain successeur de LibreOffice 7.6, est disponible en version beta. Évalué à 5.
Évidemment que ça ne remet pas en cause le fait de faire des notes de release.
Ce que je dis c'est que les clients qui sont en SaaS ils se fichent de la numérotation.
Les clients on premise veulent savoir que ça bouge et quand. Les livraisons régulières sont là pour ça ; une numérotation des versions basée sur la date va dans le même sens.
Contrairement à ce que tu dis une numérotation temporelle aide les clients à voir que ça bouge car à tout moment ils peuvent faire le lien spontanément entre la date courante et la date de sortie de la dernière version. Ce n'est pas le cas avec notre numérotation actuelle.
C'est là toute la subtilité de ce type de nommage des versions : pas besoin de connaître la stratégie de sortie des versions pour savoir de quand ça date. C'est intuitif et immédiat.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Ça me donne un peu envie de versionner comme ça pour Tracim...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien LibreOffice 24.2, prochain successeur de LibreOffice 7.6, est disponible en version beta. Évalué à 6. Dernière modification le 14 décembre 2023 à 23:29.
En écrivant ce commentaire ça me conforte encore un peu plus d'aller vers ce type de numérotation…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Les bases
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Auto-hebergement mail et sous domaine. Évalué à 4.
Aucun problème de réputation IP n'est insolvable ; tout dépend du temps et de l'énergie que tu as pour le résoudre.
Sur les IPs fournies par des hébergeurs, l'historique qui te précède a un impact et ça ne se résoud pas nécessairement en 1 clic ou 2.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Au bord du gouffre ? moins de 2% de parts de marché ? Quel lien ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Firefox serait au bord du gouffre avec une part de marché qui baisse vers le seuil critique de 2%. Évalué à 4.
C'est déjà le cas en fait. Et en plus le modèle économique repose sur la (bonne) volonté de son concurrent de le maintenir artificiellement à flot
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Au bord du gouffre ? moins de 2% de parts de marché ? Quel lien ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Firefox serait au bord du gouffre avec une part de marché qui baisse vers le seuil critique de 2%. Évalué à 8.
Déjà le sujet m'interpelle : avoir moins de 2% de parts de marché et être au bord du gouffre sont deux choses décorrélées. On peut avoir des parts de marché conséquentes et être au bord du gouffre, et inversement. Les marché de niche, ça a toujours existé et c'est des pouillèmes de PDM. Mais ça veut dire "accepter d'être sur un marché de niche"
L'article dit ceci :
Ce qui signifie effectivement que le seuil des 2% est critique … aux États-Unis (et en Angleterre si je suis ce qui est dit dans l'article) mais quid du reste du monde ? Oui ok ça fait pas rêver, mais le principe des marchés de niche c'est ça justement : ne pas être partout.
Mozilla est aujourd'hui en compétition avec Google et Apple … n'est-ce pas juste qu'il faut accepter de perdre cette bataille et s'attaquer à une bataille qui serait adaptée aux moyens de la fondation ? (qui n'ont rien à voir avec les moyens de Google, il faut rester lucide)
L'effondrement n'est pas lié aux 2% mais au modèle économique de la fondation qui est largement tributaire du financement qu'elle obtient … de son principal concurrent.
Le monde du logiciel libre n'aime pas l'idée de "faire de l'argent" mais la réalité c'est que l'argent c'est juste la représentation de la valeur que les gens donnent à ce que l'on fait et le moyen de transférer le fruit de son travail à une autre personne ou organisation.
Trouver un modèle économique viable, c'est la base, qu'on soit une entreprise, une association, un individu (tu veux une belle maison, bah il faut en face le revenu qui permet d'avoir cette belle maison - ou alors faire des efforts sur ton temps libre pour réduire les coûts d'acquisition et d'entretien).
La question n'est pas tellement de savoir comment on en est arrivé là - ou plutôt comment Firefox en est arrivé là mais où ça peut aller.
La fondation appelle-t-elle à l'aide sa base d'utilisateurs convaincus ? Fait-elle le nécessaire pour que ces utilisateurs mettent la main à la pâte ?
Comme dit par ailleurs : les utilisateurs cherchent d'abord des fonctionnalités. La protection des données en est une, la performance aussi … mais aujourd'hui ça n'a pas l'air d'être les fonctionnalités les plus recherchées.
Innover, c'est le principe pour rester dans la course. La fondation est largement capable d'innover - Rust vient de chez eux, il me semble. Mais aujourd'hui, je ne vois plus d'innovation dans Firefox.
Je fais partie des utilisateurs convaincus et pourtant à chaque mise à jour Firefox ne met à ne plus fonctionner en attendant que je le redémarre. Ça me gonfle mais je suis pour le moment toujours convaincu. Mais je n'ai aucun argument pour dire à mon entourage de passer sur Firefox au lieu de Chrome ou Opéra. Le seul argument que j'ai, c'est "google c'est mal" ; mais un véritable argumentaire se base sur des aspects positifs, pas sur du négatif.
L'article évoque un point intéressant à travers un commentaire obtenu durant l'étude de Wray :
Ça me semble lucide …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Nouvelle étape dans la décentralisation informatique ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien NextCloud rachète/reprend RoundCube, après que son mainteneur principal quitte le projet. Évalué à 3.
J'avais entendu parler d'une distinction chez Nextcloud aussi mais de ce que j'avais compris, c'était plutôt une approche type Redhat (c'est open source mais pas public).
Mais je n'ai pas trouvé d'information confirmant ça.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Nouvelle étape dans la décentralisation informatique ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien NextCloud rachète/reprend RoundCube, après que son mainteneur principal quitte le projet. Évalué à 3.
Oui j'ai la même lecture
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Nouvelle étape dans la décentralisation informatique ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien NextCloud rachète/reprend RoundCube, après que son mainteneur principal quitte le projet. Évalué à 5.
Interview croisée du boss de Nextcloud et du créateur de Roundcube : https://nextcloud.com/blog/roundcubes-future-at-nextcloud-an-interview-with-the-founders/
J'aime bien l'idée d'embaucher des gens / développeurs sans avoir de plans pour commercialiser quelque chose.
Sur le papier pourquoi pas, mais alors avec un statut loi 1901, pas avec une structure commerciale.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Nouvelle étape dans la décentralisation informatique ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien NextCloud rachète/reprend RoundCube, après que son mainteneur principal quitte le projet. Évalué à 4.
Cette information m'intéresse particulièrement …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Nouvelle étape dans la décentralisation informatique ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien NextCloud rachète/reprend RoundCube, après que son mainteneur principal quitte le projet. Évalué à 3.
Nextcloud n'est pas libre du sol au plafond ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Nouvelle étape dans la décentralisation informatique ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien NextCloud rachète/reprend RoundCube, après que son mainteneur principal quitte le projet. Évalué à 6. Dernière modification le 29 novembre 2023 à 21:43.
L'article dit
Je suis dubitatif, je ne vois pas ce qu'apporte Nextcloud en terme de décentralisation par rapport à ce que permettait déjà Roundcube.
Développer le produit, l'activité en respectant les valeurs du libre : oui.
Ou alors Nextcloud prévoit de faire du marketing pour mettre Roundcube sur le devant de la scène à des endroits où les organisations utilisent aujourd'hui du logiciel propriétaire ou du logiciel centralisé ?
Fonctionnellement, j'avais cru comprendre que SOGo était plus riche (délégation de gestion de dossiers par exemple) - et plus proche de ce que permettent les solutions concurrentes avancées (Microsoft, Bluemind), ce qui me laisse penser que les organisations s'orienteraient plutôt vers ces solutions.
Mais là, justement, ce discours aurait plutôt tendance à éveiller ma vigilance car ça sonne creux (ce qui n'est généralement pas le cas avec Nextcloud)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mail -> site web -> authentification -> attestation de lecture
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Incompétence Web. Évalué à 4.
Ça c'est sûr que c'est un carnage le web. Le business s'en est emparé… Ya qu'à faire un tour en ligne sans bloqueur de pub :-(
Mais c'est aussi un environnement extrêmement complexe si tu veux faire les choses bien. On parlait de cache ; mais si tu veux faire qqchose d'adaptatif, accessible, bien référencé, performant, sexy, …
En tout cas on a bien fait de discuter :-)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mail -> site web -> authentification -> attestation de lecture
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Incompétence Web. Évalué à 5.
C'est pas un comportement nouveau : le support utilisateur ça existe depuis des années et c'est à l'opposé de la pureté qu'on cherche quand on fait de la conception (de site, de logiciel, etc). C'est du "damage control".
Ce que je dis c'est pas que le site est bien et que tout va bien ; ce que je dis c'est qu'il faut critiquer avec un peu d'humilité.
Concernant le cache quand on développe un site on est tributaire de la stratégie des navigateurs. Par défaut on ne fait rien mais le butineurs décide de mettre des trucs en cache. Du coup on peut passer des entête HTTP pour dire "ne met pas ça en cache", ce genre de truc, mais en fait c'est pas unanimement respecté.
Du coup la solution pour avoir un truc qui marche et qui est maîtrisé, c'est :
https://mon.site/JS/all.js?token=abcd
. On se fait ch… à développer des trucs pour empêcher le browser de mettre en cacheAu final on est obligé de réimplanter le mécanisme d'optimisation tout en s'assurant qu'on court-circuite les initiatives du navigateur.
À chaque ajout de ressources il faut être vigilant et forcément il arrive qu'il y ait des ratés.
Donc non, c'est pas un problème de compétence.
C'est un sujet complexe et fragile.
Je comprends que ça fait ch… Mais c'est pas les dev ni le support le problème - en tout cas pas plus que l'utilisateur. (Note : je suis pas concerné par ce problème directement, c'est juste un comportement que je retrouve régulièrement et qui m'agace)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mail -> site web -> authentification -> attestation de lecture
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Incompétence Web. Évalué à 10. Dernière modification le 29 novembre 2023 à 07:55.
Pour le reste, je te laisse juger de la pertinence du titre et du ton du journal à la lumière de ces éléments.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mail -> site web -> authentification -> attestation de lecture
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Incompétence Web. Évalué à 4.
Ce journal montre qu'en suivant les conseils du support ça fonctionne, non ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La "chance"
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Incompétence Web. Évalué à 2.
Je voyais la virgule de cette manière :
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: La "chance"
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Incompétence Web. Évalué à 3.
Le sujet est sans doute un peu plus complexe qu'un problème de compétences.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mail -> site web -> authentification -> attestation de lecture
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Incompétence Web. Évalué à 3.
Je pense que le sujet est plus subtile.
Les email tu les perds. Et tu redemandes l'info. Comme c'est dématérialisé personne n'y accorde d'importance - il faut donc que pôle emploi garde une copie.
À partir de là, quel intérêt d'envoyer des documents par email alors qu'on peut proposer qqchose de mieux sur le plan du suivi historique d'un dossier ? Tous les documents sont centralisés et accessibles via un site unique. La conservation des données est assurée par pôle emploi qui n'aura donc pas de litige à gérer parce qu'un chercheur d'emploi a supprimé "par erreur son mail"…
Il ne faut pas prendre les utilisateurs pour des c.. mais il est attendu aujourd'huide tous les services numériques qu'ils protègent les utilisateurs d'eux même.
Ça vaut pour tous les services numériques, des serveurs OVH (souvenez-vous l'hiver mais pas le dernier) aux drive Google (coucou l'actu) en passant par tous les services gratuits ou payants (qui va se retenir de grogner si twitter, linuxfr ou autre perd toutes les données des utilisateurs ?)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Des API directement dans le navigateur ? Ou des routes
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Choix des URL "propres" pour du REST. Évalué à 3.
REST est un principe d'architecture ; ça peut s'appliquer à des APIs mais aussi simplement au routage d'une application web classique.
REST et API sont orthogonaux, comme REST et JSON ou JSON et API
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Des API directement dans le navigateur ? Ou des routes
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Choix des URL "propres" pour du REST. Évalué à 10.
J'ai l'impression que le terme
REST
a orienté la lecture de certains utilisateurs qui comprennent que tu veux faire des APIs, maisREST
n'est pas spécifique aux APIs - cf la page wikipedia qui parle de Representational state transferPOST
ouGET
?L'idée derrière une architecture est d'avoir qqchose de carré et si possible le + intuitif possible.
Du coup je suggère d'utiliser :
GET
pour des requêtes en lecture uniquementPOST
pour tout le reste (création, modification, suppression)Ce principe fonctionne bien si tu es ok d'organiser la navigation via des formulaires (
Si tu prévois de faire les choses via des liens
<a href="xxx">Supprimer</a>
alors il faut utiliser desGET
et du coup l'archi serait plutôt :GET
pour des requêtes en lecture uniquement ou des action simples (exemple : supprimer une entité, activer/désactiver un utilisateur, etc)POST
pour tout le reste (création, modification)Routage
À partir de ce qui a été dit au dessus, le routage suivant me semble clair et intuitif :
GET http://foo.bar/entities
pour récupérer la listeGET http://foo.bar/entities/<id>
pour récupérer une entité précisePOST http://foo.bar/entities
pour créer une entitéPOST http://foo.bar/entities/<id>
ouPOST http://foo.bar/entities/<id>/update
pour modifier une entitéPOST http://foo.bar/entities/<id>/delete
pour supprimer une entitéCe à quoi tu peux envisager d'ajouter des routes du style :
POST http://foo.bar/entities/<id>/activate
pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)POST http://foo.bar/entities/<id>/archive
pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)D'une manière générale
POST
pour la création et modification et mets toutes les actions spécifiques en GETGET
est visible sur les intermédiaires. Tu trouves dans les logs Apache / NGINX les routes avec les paramètresGET
. Typiquement, ne mets pas de données sensibles enGET
(exemple : mot de passe, email, etc)GET
sont généralement exploités pour faire du filtrage, par exemple :http://foo.bar/events/?owner=4&category=birthday&after=2023-10-16T00:00:00
GET
sont généralement crawlés par les moteurs de rechercheJ'ai fait un petit tour de ce qui me vient à l'esprit, n'hésite pas si tu veux approfondir des trucs.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Formulation
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 4.
Merci pour le retour sur le site. Ta formulation est plus fluide, je vais voir pour rectifier ça.
Le service repose sur Dovecot mais je ne saurais pas dire si on supporte les dossiers virtuels. Je vais me renseigner.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Paliers
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal [publicité] galae, le service email éthique et libre (et français) est désormais ouvert \o/. Évalué à 1.
Je voulais dire "L'enjeu du commentaire initial"
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo