wilk a écrit 1248 commentaires

On dépend des GAFAM qui sont pourtant implantés physiquement sur notre territoire. Et bien c'est simple il suffit de les annexer, c'est tendance en ce moment.

Le problème n'est effectivement pas la valeur, qui est assez virtuelle à ce stade, mais plutôt le pouvoir que ça lui donne. Par exemple, parait-il, d'avoir influencé l'autre à ne pas nommer une première ministre de gauche.

Les utilisateurs non plus ne tombent pas en panne, ils vont se charger d'envoyer les mails de notification 😂

Pfff, facile. Moi c'est mes enfants qui n'ont pas eu de smartphone ni réseau avant la majorité. Et toc.
Et non ils ne sont pas nés au siècle dernier.
Est-ce que c'était facile ?
Oui (j'en n'avais pas non plus et je n'ai pas eu à les forcer).
Est-ce que ça le serait aujourd'hui ?
Non.

Currently, he said that Vim is more-or-less in maintenance mode.

Ca tombe bien, moi aussi.

On peut dire la même chose du "deux tu-l-auras-peut-être-plus-tard" à propos du nucléaire. Il n'y a actuellement aucune chance pour qu'il ait une part significative dans les délais requis au niveau mondial. Au mieux ce sera un petit plus pour une toute petite minorité de pays et à un coût probablement exorbitant.
Le plus important dans la stratégie Negawatt c'est le principe de jouer sur la demande plus sobre et efficace, pas les nouvelles technologies de production.

Justement c'est d'autant plus marrant et paradoxal de voir qu'un outil comme HTMX qui n'est pas un framework, qui n'invente rien (on utilise les iframe pour faire la même chose depuis plus de 20 ans) et qui revendique l'intérêt d'en rester là (cf le lien indiqué), arrive à dépasser les autres sur ce terrain.

Depuis un an il y a la possibilité d'ouvrir un compte pro (obligatoire pour faire des virements TVA) gratuit chez Indy, ça passe par Swan. Je me demande ce que ça vaut. Sur le papier ça à l'air juste simple et pratique mais quand on regarde les avis sur Swan à droite à gauche ça à l'air catastrophique (je parle de Swan, pas de Indy avec qui je n'ai franchement aucun soucis).
Des avis ?

Sinon il se trouve que je suis aussi chez Fortuneo pour le compte particulier. RAS.

C'est le problème avec les énergies intermittentes.

Comment ça c'était pas une bonne idée ?

https://www.lindependant.fr/2024/12/21/energie-nouveau-retard-pour-le-reacteur-nucleaire-epr-de-flamanville-finalement-raccorde-au-reseau-ce-samedi-matin-12406570.php

On lance la prod un vendredi soir, aucune raison de s'inquiéter avant lundi.

En 2022 y a eu une conf Devoxfr sur leur bourbier.
En gros, et de mémoire, ils ne s'attendaient pas à grossir si vite (covid) et leur application RoR n'était pas du tout prévue pour ça. Genre des requêtes avec +20 jointures.
Ils avaient le choix entre reprendre l'application ou trouver une DB magique (qui puisse faire x10 sans rien changer d'autre).
Reprendre l'application impliquerait de payer des devs, donc niet.
Reste la DB magique, pas de bol rien ne fait mieux qu'Aurora (AWS).
Du coup plan B, trouver une solution sans avoir à tout changer (ForeingDataWrappers, une ext PG par ex).

https://www.youtube.com/watch?v=1PtPVpFWtKQ

Y a un truc qui me semble contradictoire car le problème semble venir du fait que l'application n'était pas prévue pour ça car pensée trop petite (hébergée chez Heroku au départ) mais en même temps ils ont trouvé trop coûteux de la réécrire. Après tout, c'est une "simple" (c'est le terme qu'ils emploient) application de prise de rendez-vous au départ.

Ils ont attendu le dernier moment pour réagir et du coup au pied du mur effectivement c'est plus difficile de réécrire une application au moment où elle tourne à plein régime. Et de là la bonne excuse pour dépendre d'AWS.

Bref, faudrait songer à payer les devs si on veut avoir le choix de l'infra !

On parle d'apprentissage.
Pour ma part le fait d'avoir commencé par apprendre le fonctionnement d'un ordinateur "à fond" en commençant par l'assembleur plus le C m'a énormément simplifié la vie par la suite.
Le réinventage de roue est également un excellent moyen d'apprendre car on peut ensuite regarder comment d'autres ont fait ces mêmes roues.

"Faire un truc" et "bien plus rapide" c'est très relatif.
Si tu fais un truc mais que tu ne le comprends pas, est-ce que tu as appris réellement ?
Par exemple si tu dois faire une intersection entre deux ensembles, en Python tu vas utiliser set, c'est plié en 3 lignes. En C tu vas faire des boucles, c'est beaucoup plus difficile mais à la fin tu aura appris un algo.

Tendance paranoïaque. C'est noté, merci. Voulez-vous que l'on rajoute autre chose sur votre dossier ?

Je vends mon numéro de sécu si quelqu'un est intéressé. Faire offre.

De plus en plus souvent je me retrouve à simplement utiliser vim et taper du html directement pour n'importe quelle présentation.

Non, l'idée du fil était d'intégrer les fonctionnalités de base de htmx au html, en natif (voir le lien que j'ai indiqué, la branche proposal).

Par exemple <a target=xyz xyz ne peut être qu'un frame, on est obligé d'utiliser JS pour avec un target vers un autre élément. L'idée est que target puisse être #id et renvoyer vers un quelconque élément et qu'un button puisse se comporter comme un a.

J'ai fait un inventaire de mes applications, ça représente la quasi totalité des cas où j'ai du utiliser du JS (ou htmx).

Ceci dit je ne sais pas si c'est le JS qui pose problème pour écrire un browser… J'ai plus peur pour le css !

La question est de savoir si ce JS était réellement indispensable. En app d'entreprise je n'en ai quasiment jamais besoin et le peu de cas où j'en ai besoin c'est pratiquement tout le temps remplaçable par htmx. Et même la plupart du temps les utilisateurs ne voient même pas la différence entre une page qui se réaffiche ou juste un morceau tellement c'est déjà rapide avec les réseaux actuels quand justement on ne s'encombre pas de futilités.

On pourrait très bien se passer de JS dans la grande majorité des cas et le peu qui pourrait être utile pourrait être intégré au html.

Quelqu'un travaille dessus par rapport à htmx :

https://github.com/alexpetros/triptych

Par contre il y a de telles évolutions dans le CSS que ça ne va pas arranger les choses.

Il me semble qu'il sera plus difficile de trouver une faille volontaire dans un ramassis de code généré.

Si, le PCA/PRA c'est le fait de connaître quelqu'un qui s'y connait. Au cas où.

On se sent moins seul quand une panne survient !

Ca n'empêche pas. C'est déjà difficile de lire le code de quelqu'un d'autre, alors le code d'un robot ça rajoute une couche. C'est justement un des problèmes majeur des IA que même quand ça marche on ne sait pas vraiment pourquoi à part que ça se rapproche de quelque chose qui a déjà du avoir lieu quelque part.

Pareil, content d'une laser n&b après avoir été tellement déçu des HP.
La mienne arrive en fin de garantie, je me pose la questions des toners génériques. Est-ce qu'il y a des inconvénients ?