https://noblogo.org/sknob/faites-quelque-chose
| Articles | https://sroccaserra.fr |
| Code | https://git.sr.ht/~sroccaserra/ |
| Code | https://codeberg.org/sroccaserra/ |
| Articles | https://sroccaserra.fr |
| Code | https://git.sr.ht/~sroccaserra/ |
| Code | https://codeberg.org/sroccaserra/ |
I do prefer @jbrains’s usage of “complication” rather than “complexity”, BTW.
If you haven’t seen this talk, entitled “7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development”, click:
Hi @romeu, you said some time ago that you use eshell as your main shell. Do you have some tips to share, or specific reasons to recommend it? I would be interested.
Also, how do you start it? Do you have Emacs open anyway, so you start it from there, or do you have a specific startup script to start it as a separate app?
J'ai apprécié cet article de @jbrains. Quand on simplifie du code, paradoxalement il y a un risque de le rendre moins familier (ce n'est plus comme avant, ce n'est plus comme on a toujours fait). Ça peut être une raison d'accepter de ne pas simplifier. Mais si on ne prend jamais ce risque, on passe à côté d'opportunités de simplifications. Compromis... Je trouve intéressant d'avoir ça en tête collectivement.
=> https://blog.jbrains.ca/permalink/a-central-conflict-in-readable-code
Sometimes we struggle getting buy-in from others about improving our software designs. I think I know one of the ways that happens:
https://blog.jbrains.ca/permalink/a-central-conflict-in-readable-code
RE: https://mastodon.social/@librairieguillaume/115609944825476923
Ce soir à Caen !
Why do I want automated tests before refactoring?
Because the code has value, is in production, and is useful to many users. So I want tests as a safety net for myself (work with less stress, work faster), but more importantly for the users, because if I break the existing behavior, most of the unhappy consequences will be for them. And the responsibility is mine to check that I did not change the observable behavior.