steph1978 a écrit 3405 commentaires

Cependant, désolé pour mon premier message, il était un peu brut et sans explications…

Pas de soucis, c'est aussi une façon d'ouvrir le débat.

La vidéo n'est pas une démonstration scientifique. N'oublions pas que les vidéastes sont là pour faire des vues. Mais l'étude/expérience sur laquelle elle s'appuie montre bien une perte de capacité cognitive… chez la souris.

En fait, la dérive : les jeunes […]

Je n'ai pas parlé de jeune initialement. Je sais que les utilisateurs de tiktok sont plus jeunes en moyenne que ceux des autres gros réseaux sociaux mais ceux que je coutoies/vois ne sont pas si jeunes.

La vidéo souligne l'addiction. Ce que je vois aussi sur ce réseau c'est un culte du paraître, du consumérisme.

Cela me gène encore plus depuis que nos gouvernants se servent des réseaux sociaux pour expliquer tout un tas de maux de notre société

Pourtant plus haut tu parles d'alcoolisme et en effet les mécanismes physiologiques sont les mêmes.

Mais je t'accorde que c'est une perche facile tendu à un gouvernement libérale dont l'idéologie fondamentale est de saper les services publiques pour les privatiser.

Alors que, IMHO c'est justement plus de service publique (éducation, santé, police) qui serait nécessaire pour endiguer ces maux.

J'ai du mal à voir

Ta clim ne consomme pas d'électricité ?

Si ta clim comsomme 2000W pour faire du froid bah elle crée 2000W de chaleur en plus de la chaleur qu'elle remet dans l'atmosphère et qui y était déjà.

Multiplie ça par le nombre de bureaux, de maisons, d'appartements, de m2 de centre commerciaux.

Donc une clim chauffe.

Les goûts les couleurs …

Mois j'aime bien parce que y a une base de réalité : https://invidious.tiekoetter.com/watch?v=FALDuZ5pPxc

Pour le cerveau des utilisateurs de tiktok.

Alors que si il y a un vrai problème écologique c'est plus avec les chats domestiques qu'avec les chats sauvages.

Les chats sauvages, si la population de leurs proies (oiseaux) diminue, leur propre population diminue (famine).

Par contre les chats domestiques peuvent continuer à décimer la population de leurs proies sans conséquence pour eux car ils sont nourris par ailleurs.

Heureusement qu'il n'est pas nécessaire de recourir à un ORM pour faire du nettoyage d'input.

C'est énervant, ça marche même sous windows. Je l'ai testé au taf.
C'est bien pour ça Rust (comme Go et Zig), ça cross compile facilement.

Je l'utilise depuis toujours.
Rien à envier à un DBBeaver ou un SquirelSQL si ce n'est qu'il ne gère que du SQLite.
Surtout beaucoup plus léger.

Je l'avais ouvert en // de faire le tuto proposé par l'OP. Ça permet de voir ce qui se passe dans la base tant que toutes les fonctionnalités ne sont pas là.

Super projet en effet, c'est clean

Je partage le sentiment qu'il y a trop de couches à gérer manuellement dans les applications web dites "modernes". Et qui dans une grande majorité des cas n'apporte pas de valeur, seulement de la complexité. Je pense que cela titille pas mal de développeurs.

Les ORM sont une plaie à utiliser et à débugger. J'ai subit Hibernate en début de carrière. Aujourd'hui j'utilise Ecto qui est un peu plus maîtrisable et qui permet d'écrire du SQL directement en Elixir et donc de bénéficier de l'aide du compilateur et d'avoir un langage de programmation généraliste et plutôt agréable.

Mais quitte a écrire du SQL alors en effet pourquoi pas l'utiliser pour tout!

Je ne sais pas si un développement en SQLApp peut passer à l'échelle. Cela demande de changer de mindset ; utiliser les vues par exemple. Mais c'est super pour un PoC ou une application simple.

Ce qui va être rapidement indispensable c'est de pouvoir gérer les droits (admins, membre, visiteurs) et donc l'authentification (OAuth2) sinon le nombre de cas d'usage va être très restreint, surtout en entreprise.

Je sais que je suis bassement terre à terre et que le débat se situe surtout sur la liberté privée mais concrètement ça marche comment ?

Moi rien que le Google concent, ça passe pas. Et ensuite, les suggestions de la une, wouatch quelle horreur.

J'ai tellement d'"artists" au taf qu'il faudrait inventer un châtiment quand qqun t'envoie une copie d'écran d'un truc qui pourrait être copié-collé.

Avant elles s'appelait "vidéo surveillance", elles faisaient leur taf.
On (sarko ?) les a renommé "vidéo-protection", et elles font pas leur taf. Sûrement un manque de formation.

le tweet, en plus net

Je n'ai pas testé toutes tes options mais rien qu'en partant de la première jq ., je ne sais pas si on parle de la même chose.

$ jq '.' <<< '{"a":{"b":"c"}}'
{
  "a": {
    "b": "c"
  }
}

vs

$ gron <<< '{"a":{"b":"c"}}'
json = {};
json.a = {};
json.a.b = "c";

Jq indente alors que gron donne le chemin complet pour chaque ligne (l'idée de "flatten", mettre à plat).

Donc avec gron je peux faire une décision local (si chemin est "a.b", faire un uppercase à la valeur). Alors que pour jq, je vais devoir maintenir un état (pile ?) contenant le chemin actuel.

D'autre part, cf "ti bench", jq ne fonctionne pas en flux, par défaut, il charge tout en mémoire.

Le mode flux existe et est efficace (21MB de RAM dans mon "ti bench"), mais difficilement exploitable sans post-traitement :

jq --stream '.' <<< '{"a":{"b":"c"}}'
[
  [
    "a",
    "b"
  ],
  "c"
]
[
  [
    "a",
    "b"
  ]
]
[
  [
    "a"
  ]
]

Bref, je cherche un gron rapide, économe en RAM et avec une sortie stable.

Y a ça dans tes options ?

Super ! Tu crois qu'il y moyen de le mettre sur F-Droid pour celles et ceux (celui ?) qui n'ont pas le ggplay ?

Dispo sur toutes les plateformes : linux, windows, android.

Et pour tous les âges.

C'est de la balle

Pour ne pas laisser ma fille seul devant l'écan, je fais avec elle. Sur son écran le temps qu'elle comprenne puis sur le mien quand je me fais jeter ("toute seule!").

Je dirai que l'empreinte mémoire est linéaire - O(N) - au lieu d'être constante - O(1), comme c'est le cas pour wc qui compte les lignes.

Concernant les scripts, rien de bien folichon, je me contente mesurer une lecture complète d'un gros fichier : /usr/bin/time -f %M,%P,%e,%U,%S,%W,%c,%w,%x <command> < big.json > /dev/null. Pour chaque commande.

Concernant les données, j'utilise des trucs qui traînent sur mon DD mais dont je ne me rappelle pas trop la provenance et que j'ai pas trop la possibilité de rediffuser mais je suppose qu'en cherchant un peu sur le web on peut trouver des gros json. Ou peut être les générer.

Merci cher Canari pour ton message. J'essaye de compléter un peu.

Mobilizon est un produit jeune. Il y a plein de pistes à explorer tant sur les fonctionnalités que la stabilité ou l'interopérabilité.

Pour aller chercher une subvention faut d'abord expliquer ce qu'on veut faire et qui le ferai bien avant de pisser la première ligne de code.

On ne cherche pas un développeur dans le langage Truc pour x euros de l'heure. On cherche une contribution au projet qui participe aussi à la construction du produit.

L'intégralité de la subvention servira à cette contribution. Un petit coup de méthode de fermi : une subvension de 50k€. Un TJM de 500e. On peut en gros réaliser 100 JH. On peut en faire des choses avec ça. Mais il faut se poser un peu avant. Ouvrir le champ des possibles, les prioriser (intérêt vs complexité).

Voilà ce qui est proposé. C'est peut être plus flou qu'un bête pige mais peut être plus intéressant aussi.

Je m'étais lancé dans un benchmark sur gros fichiers, fut un temps. J'ajoute une ligne.

Sample file

• 74MB
• 2.7M tokens
• 267k objects

result

tool            RAM (KB)    time
--------------- ----------- ------
wc (baseline)       1'924    0.34
jq                247'364    2.36
gron            1'103'992    5.47
nron              263'824    1.19
json-flatten      402'708    3.18
json-search       413'196    0.96

 analyse

• gron, j'en ai parlé juste au dessus
• jq s'en sort pas si mal compte tenu de tout ce qu'il sait faire
• nron, c'est une tentative de ma part de réimplémenter gron en nim. Je n'y suis pas encore.
• json-flatten en une implémentation en python
• json-search est sacrément véloce

Tous sont très gourmands en RAM. Alors que de ma compréhension ils font un traitement local - O(1) - qui ne devrait pas dépendre de la taille des données - O(N). Au pire de la profondeur des données (longueur du path). Surement les parseurs sous-jacents qui seraient à revoir.

J'aime bien gron parce qu'il permet d'utiliser des outils de traitement ligne à ligne comme AWK.

gron in.json | awk '{truc de ouf}' | gron -u out.json

Par contre il est

1. très mal optimisé, en RAM comme en CPU
2. non stable dans le sens ou les objets ne sont pas restitués dans l'ordre d'origine mais triés par clés. Je sais que c'est conforme à la spec. Mais dans les faits un peu pénible quand on veut faire un traitement qui utilise des données sensées arriver "avant".

Les site agrégateurs de RSS ont été popularisés par google reader. Sûrement une façon de savoir ce qui intéresse leurs utilisateurs Geek. Mais sûrement pas assez intéressant pour eux puisque décommissionné en 2013.

De nombreuses alternatives opensource (et pas que) ont vu le jour. D'ailleurs si vous essayez de trouver une application RSS sur iPhone, vous n'aurez que ça: des clients pour des agrégateurs de flux propriétaires soumis à abonnement et blindés de pub. Heureusement sous Android, de très bonnes apps existents.

J'avoue je comprends pas l'intérêt d'un agrégateur en ligne sachant que pour moi le principal intérêt du RSS est justement d'être offline. Mais vu l'offre abondante, j'imagine qu'il y a un public. Quoi qu'il en soit ils ont au moins l'intérêt de ne pas avoir à configurer un client RSS sur chaque device. Un site web qui marche sur PC marche sur mobile.

Du coup, c'est quoi ton soucis ?

A noter que Feeder permet une synchronisation de la liste de RSS et de l'état de lecture des articles entre device. Le meilleur des deux mondes selon moi.

Merci

Je n'arrive pas trop à comprendre que ceux qui défendent l'automobile n'arrive pas à intégrer ça. 1.5T de métal lancé à 50km/h, ça sera toujours mille fois plus dangereux qu'70k de chaire lancé à 15 km/h.

Et ça c'est que la physique. Ajouter le sentiment de protection et l'usage massif du téléphone en conduisant et la dangerosité est décuplée.

Est-ce que les automobilistes vont un jour intégrer qu'un passage piéton avec un piéton qui s'engage c'est comme un feu rouge ou un stop, on s'arrête ?

Et là c'est pareil, devant chez moi c'est 99% qui s'arrêtent pas.

Et les voitures sont devenues trop grosses et trop haute (SUV). La semaine dernière un mec s'est engagé sur le trottoir (sortie d'une rue piétonne) Mais petite de quatre ans sur son petit vélo a freiné in extremis et a tapé le bas de la porte. Le gars avait rien compris ce qu'il se passait. Sous le choc je n'ai même rien dit. J'ai juste rassuré ma petite et félicité pour son réflexe.

Qui peut encore défendre ça !

pareil

moi j'en utilise réellement 4 (contact + 3 collaborateurs) ce qui me ferai 4*4e*12 = 192e contre 22e, soit 8.7x plus cher.

Y a pas une obligation d'avoir au moins une adresse de contact par domaine (genre posmaste@domain.tld) ou un truc dans le genre ?

Je pensais que c'était ça qui poussait les regitrars à t'en proposer une (et donc une deuxième, genre "contact" ou autre).

Du coup si c'est bien une obligation et que ce n'est plus fourni par Gandi, cela veut dire que l'obligation se reporte sur le client qui doit obligatoirement trouver une solution de mail pour tout domaine loué ?