jihele a écrit 1143 commentaires

Oui, j'ai un fixe avec un répondeur qui me renvoie les messages par courriel en mp3 en direct.

Le numéro est renseigné dans Paypal.

J'ai essayé le SMS dessus mais ça marche pas, il se passe rien. (C'est dommage, j'ai souvenir d'une soirée jadis où on s'amusait à envoyer des SMS avec plein de consonnes sur des fixes juste pour se marrer à entendre la voix automatique les prononcer.)

Je peux aussi demander un appel sur le fixe, mais l'appel ne donne pas un code sur le message, il demande à celui qui décroche de rentrer un numéro à 4 chiffres donné par Paypal avant l'appel. Donc il faut être sur place pour décrocher.

La page écrit "next At 07:00" et si tu cliques sur next, ça affiche les prochaines échéances.

Pour faire de l'alcool il faut du sucre qui vient soit de l'amidon du malt soit du sucre ajouté. Rajouter du sucre permet d'avoir plus d'alcool en économisant du malt. C'est plus fort mais ça a moins de corps. Perso je le fais pas. En tant qu'amateur, je rapine pas sur le malt, quitte à y passer la journée. Ça serait peut-être différent si j'avais un équilibre économique à trouver.

Pour refermenter un bouteille on rajoute un peu de sucre. C'est pas pour l'alcool (0.5° à la louche), c'est pour les bulles. Il y a pas vraiment d'alternative en amateur. Un pro peut avoir une embouteilleuse qui embouteille sous pression.

On a brassé dans une cuve de 70 L avec deux paliers de 30 minutes à 64°C et 68°C. Parce qu'on est pas des rigolos qui font du mono-palier.

Ça c'est la théorie. En pratique, la température est pas homogène, le thermomètre a de l'inertie, le liquide aussi, la marmite aussi.

Bref, on a des écarts énormes.

Mais ça marche quand-même. Comme du mono-palier…

J'utilise ça aussi (j'ai pas de mobile). J'ai un boîtier à la maison et un au bureau.

Mais je reconnais que si un jour je suis coincé quelque part et je dois acheter un billet de train par internet, par exemple, je suis emmerdé.

Et depuis quelques temps je dois l'utiliser pour entrer dans l'interface web de la banque même pour juste une consultation, ce qui est bien relou, si bien que je vérifie moins souvent mes comptes qu'avant.

Le T-OTP est standardisé et existe dans plein d'implémentation open-source. La solution ne peut pas être retenue dans le cadre des transactions bancaires car le contexte est requis

Tu saurais détailler ça ?

Je râle depuis longtemps sur le 2FA pour les accès aux sites bancaires ou aux paiements sur internet parce que ça nécessite un téléphone (SMS), voire une appli (parce que SMS est pas assez sécurisé).

Chez Paypal, j'utilise OTP. Dans mon profil j'ai demandé un numéro qui doit faire une dizaine de caractères et que je donne à une appli (libre) d'OTP pour me connecter. Ce mécanisme ne convient-il pas ?

C'est juste que c'est pas le même qui rédige l'intro, la description technique et la formule de politesse.

Ils sont un peu silotés.

Pareil.

J'ai un disque dur externe avec

• une partition lisible avec musique et films, pour partager, voire faire des transmissions ponctuelles de fichiers
• une partition chiffrée avec mon home (sauf les films et la musique)

En fait j'en ai deux identiques. J'en laisse toujours un au bureau et une fois par semaine j'amène celui de la maison au bureau pour échanger.

S'il est volé ou perdu, c'est pas grave, c'est chiffré. C'est juste chiant à refaire (achat, partitionnement, adaptation script de sauvegarde, etc).

un disque dur chiffré je vois pas trop le problème (sauf si tu bosses dans une société "militaire" ou similaire avec besoin d'habilitation aux secrets). Tu peux m'expliquer ?

Même question. Je n'envisage pas une seconde que mon boulot me foute dehors sans me laisser prendre mes affaires et je comprends même pas le problème, hors peut-être certains cas spécifiques.

Effectivement, c'était confus pour moi. Je viens de vérifier et le paquet fourni dans leurs dépôts (celui que j'utilise) est bien celui de la version "Community", qui est couvert par leur licence "TSL".

Je crois pas utiliser les fonctionnalités supplémentaires et je sais pas si j'en aurai besoin un jour, mais en tout cas j'utilise le packaging officiel.

Au final, je rentre dans le cadre de la version TSL : j'utilise la base dans une application, potentiellement je pourrais vendre un service utilisant l'application, mais je vends pas de la base de données.

Reste que c'est pas 100% libre, OK.

Peut-être qu'on aurai pu partir sur postgres. Pour être honnête, j'ai pas fait de benchmark. Et on était intéressés par certaines fonctionnalités, notamment time_bucket (qui est dans la version libre).

Wow. C'est pas de la mauvaise foi. J'étais pressé et j'ai juste mis un lien rapide avec juste le minimum.

J'utilise Timescale sur un projet et en voyant ton message j'ai eu peur d'avoir raté quelque-chose sur la licence donc je suis allé voir et j'ai été rassuré.

Effectivement, la version libre n'a pas toutes les fonctionnalités, je sais pas si je dois m'en inquiéter ou pas sur le long terme.

En tout cas mon message n'était pas plus faux que le tien qui disait que c'était pas libre, quand-même. J'ai juste pas pris le temps de détailler.

Un bon remplacement peut etre https://www.timescale.com/, notamment parce que c'est base sur postgres, mais attention ce n'est pas libre.

https://www.timescale.com/legal/licenses

TimescaleDB Open Source is made available under the Apache 2.0 License

Il me semble que OTP (one time password) serait une bonne alternative.

C'est proposé par PayPal, même si j'ai bien galéré pour trouver. Logiciellement, ça s'utilise avec du libre, notamment logiciels stockeurs de mots de passes, et il y a aussi des applis proprios connues (Google Authenticator, je crois). Pour moi, c'est le top, pas besoin d'appli ni même de mobile pour SMS.

C'est équivalent à ce qui est utilisé par le "lecteur sésame" proposé par ma banque (crédit coopératif), sorte de petite calculette dans laquelle je m'authentifie avec la CB pour avoir un code à usage unique. Plus contraignant parce qu'il faut trimballer le lecteur, sortir la CB, etc. Mais pas de dépendance au mobile non plus.

Si tu reformatte un vieux commit, bon courage pour le rebase, tu vas avoir un conflit imbitable à chaque commit.

L'inconvénient c'est si tu l'as dans ta config globale et tu dois bosser sur un projet qui black pas, tu te retrouves à modifier plein de lignes de code sur lesquelles tu interviens pas à chaque fois que tu commites. Je sais pas comment ça se gère.

Bonne idée, j'ai pas pensé à le faire à l'enregistrement, mais c'est encore mieux.

J'ai aussi flake8/pylint qui s'exécutent dans mon éditeur (et chez moi, c'est mieux, c'est vim) et ce depuis longtemps, donc je code propre "naturellement" par habitude. Mais avec black, je m'emmerde même plus à corriger certains trucs parce que je sais que ça se fera tout seul.

Absolument.

J'ai appris énormément en contribuant à umongo puis marshmallow et consorts. Ça m'a permis d'injecter des bonnes pratiques (CI, etc.) dans les projets au boulot. Mieux qu'une formation. C'est comme ça que je suis devenu mainteneur.

Mais ça marchait parce que j'avais besoin de fonctionnalités, puis j'y ai pris goût et je fais des choses donc je n'ai pas besoin directement. Mais si je ne suis plus utilisateur, je n'ai plus d'intérêt à y passer du temps.

J'ai déjà vu quelqu'un sur GitHub qui cherchait à contribuer pour contribuer, pour ajouter des lignes à son profil. Il proposait des modifs inutiles ou sans grand intérêt et il fallait le prendre par la main pour faire sa pull-request parce qu'il comprenait rien au process de développement du projet. Au final ça fait plus perdre de temps au mainteneur qu'autre chose.

J'ai compris que dans ton cas c'est pas tout à fait l'idée, mais je plussois quand-même le conseil. Contribue à un projet que tu trouves utile.

Il y a quelques logiciels utilisateur final en Python dans nos environnement. Logiciel de recherche de fichiers, lecteur multimédia, etc.

En Python, on a black. Je l'utilise avec pre-commit pour formater le code avant de commiter.

Au début, j'étais un peu gêné par certains choix, mais à l'usage, je trouve que le bénéfice en vaut la peine.

Je n'ai plus besoin de fignoler le formatage pendant que je code, je laisse les choses vaguement propres et au commit black met tout au carré.

Je l'ai utilisé trois jours et quand je l'ai plus, ça me gêne.

Je m'étais cassé la tête à trouver des solutions pour faire de l'autorisation avec des périmètres, pas juste du RBAC (un utilisateur peut lire les documents), mais la possibilité par exemple de dire qu'un utilisateur peut lire les documents qui sont dans son groupe.

J'avais rien trouvé d'utile. Pour le RBAC, il y a du monde, mais dès qu'il y a en plus du relationnel, c'est tout de suite métier et on trouve pas de code générique.

Oso est arrivé à pic. La partie relationnelle est bien abstraite. Pour l'instant je suis assez bluffé.

Ça me revient, en effet, c'est avec toi que j'avais échangé sur apispec que vous utilisez dans Hapic. Ca remonte un peu et on avait un gros refactor en cours sur apispec. C'est plus calme maintenant. C'est vrai aussi pour webargs et marshmallow.

Anéfé, j'avais pas vu la précision en bas et tiqué sur la formulation en haut.

J'ai pas d'autre exemple courant. On doit pouvoir décorer une variable dans un module, un attribut dans une classe,… mais c'est pas quelque chose que je fais couramment.

N'importe quel objet, pas forcément une fonction.

C'est aussi souvent une classe, par exemple.

Merci. Ça aurait mérité un journal, mais j'ai pas pris le temps et j'attends d'avoir un peu plus joué avec.

Salut.

Je bosse sur des environnements un peu similaires mais synchrones. Dans nos projets, on utilise flask-smorest, framework basé marshmallow, apispec, webargs. Il me semble que vous l'utilis(i|)ez aussi, j'avais eu des discussions avec des gens de chez vous sur Github. Et on utilise de plus en plus SQLAlchemy.

Au début j'ai utilisé flask-sqlalchemy mais je l'ai viré rapidement pour faire les quelques lignes de codes qui suffisaient. De mémoire, il apportait pas grand-chose et me gênait si je voulais accéder à la base sans passer par flask. En gros, c'était trop raccourci et j'étais plus à l'aise à faire un code que je comprenais. J'utilise scoped_session, et j'ai une classe qui reproduit une interface similaire à flask-sqlalchemy, avec une instance de db globale (créée à l'import) qui traîne partout dans le code et dont j'initialise l'accès à la base à l'init de l'application.

J'utilise souvent le combo ContextVar / ContextManager, en particulier pour passer des sessions. Je l'ai fait dans umongo (MongoDB ODM basé marshmallow) pour pouvoir faire des transactions sans passer la session via toute la pile de fonctions. Dans l'app sur laquelle je bosse en ce moment, j'ai une ContextVar CURRENT_USER que je renseigne dans le décorateur qui authentifie chaque route de l'app et que je lis dans la couche qui gère les permissions. Le coeur du code, qui contient la couche permissions, expose donc un context manager qui permet de renseigner l'utilisateur, et c'est ce context manager que j'utilise dans l'app.

Au passage, pour les permissions, j'ai utilisé Oso que j'ai découvert via le blog de StackOverflow et j'ai trouvé ça franchement pratique. Bien mieux que le code spaghetti maison que j'avais fait avant. Pour la peine, je viens de poster un lien ici.

Il y a un pain avec le formattage de code de ton article, après "Pour les curieux, voici la partie du code transmettant le contexte aux threads".

Le moteur de mon ancien mixeur Seb a cassé.

J'ai acheté 30€ un mixeur Magimix (basique) d'occasion et j'ai revenu les pièces de mon mixeur cassé (les bols, les lames,…). Grâce à ça je pense avoir "sauvé" 4 ou 5 mixeurs et en plus j'ai récupéré à peu près 30€. C'est un peu pénible à faire mais je ne regrette pas l'opération.