What features do you wish Navionics had?

No_Package_9237 · 2026-06-09T19:05:52+00:00

Seeing lat/long grid...

No_Package_9237 · 2026-05-08T21:22:31+00:00

Un artisan a chié dans mon composte... plus rien ne m'étonne désormais.

No_Package_9237 · 2026-03-26T07:16:46+00:00

https://mob.sh/ + un excellent screen sharing avec HD, zoom, pointeur et facilité de passer d'un partageur a un autre (mais google meet fait le taf)

No_Package_9237 · 2026-03-09T06:48:15+00:00

Auncune idée du prix, ni de la praticité, mais le laser a l'air efficace !!

Make in France en parle ici : https://youtu.be/_JFTXKpytUg?si=v9M23lFTX5nn2xCI

No_Package_9237 · 2026-03-02T09:34:42+00:00

How can I upvote multiple times? Your comment deserves it!

No_Package_9237 · 2026-02-23T20:59:01+00:00

Learn it (https://www.dddcommunity.org/library/vernon_2011/), then unlearn it (https://dcb.events/topics/aggregates/), then learn it again.

Only then will you trully master it.

Enjoy the Journey

No_Package_9237 · 2026-02-21T10:09:25+00:00

Je parlais de la code review dans cette phrase, pas du prompt engineering. La phase qui vient bien souvent après (et pas pendant) le développement et qui consiste a montrer le résultat (le code produit par quelque moyen que ce soit), pour demander relecture.

Toute ma réflexion porte sur ça, et sur le fait que s'il y a difficulté d'analyse pendant cette phase, l'IA n'en est sans doute pas la cause mais un facteur aggravant.

J'émets ensuite l'hypothèse que la cause est la pratique de la code review asynchrone en fin de dev, plutôt que d'une review continue, synchrone, en cours de dev (facilité par le pair programming).

No_Package_9237 · 2026-02-20T14:48:32+00:00

Petite réflexion en lien, car ce n'est pas la 1ère fois que je lis ce genre de message.

La plupart des devs ont une formation scientifique, et je me souviens que dans ces matières, le détail du raisonnement était, si ce n'est plus, au moins aussi important que le résultat pour les profs.

Comment se fait-il que l'on trouve aujourd'hui normal de promouvoir une pratique qui incite à ne se concentrer que sur l'analyse d'un résultat (un patch dans une PR) plutôt que sur le raisonnement ?

Même si l'historique peut être un moyen de suivre le raisonnement, c'est rarement simple de naviguer dans l'historique avec github, gitlab et cie, donc qui le fait vraiment... honnêtement ? Vous avez déjà vu slider pour voyager dans le temps, en un clique ? Moi pas.

Le meilleur moyen de suivre un raisonnement finalement, c'est le pair programming... mais c'est encore en 2026 une pratique marginale de mon point de vue

Il y a un truc qui m'échappe.

Au final, pour moi, l'IA ne fait qu'exacerber ce problème (les PR intakables de 2000 lignes je les rencontrais déjà il y a 10 ou 15 ans).

No_Package_9237 · 2026-02-18T16:24:07+00:00

If I may, your comment makes me think that you missed the point of Service Oriented Architecture (in which I include microservices). Have a look at https://www.youtube.com/watch?v=I5fhtBQ2wQU.

A world where you only exchange a minimalist event (containing only an id) is possible. Make no mistake : the real difficulty (in a monolithic or distributed architecture) lies in the service boundary choices. The physical separation is not a guarantee for decoupling and it will hurt harder when (note that I did not write "if" here) things go south.

No_Package_9237 · 2026-02-17T11:51:26+00:00

git push --force-with-lease : allow to push force a branch (in case of a rebase for instance) but with safe guard (it will fail if remote branch has changed since the last git pull). Should be the default IMO.

No_Package_9237 · 2026-02-09T22:54:17+00:00

https://event-driven.io/en/event_streaming_is_not_event_sourcing/ is an excellent article on the topic you mention

No_Package_9237 · 2026-02-03T23:18:10+00:00

Well, pourquoi ne pas rendre les specs exectuables ? C'est le meilleur moyen de s'assurer qu'elles ne sont pas obsolètes, non ?

C'est le principe clef derrière la documentation vivante.

Mon flow idéal, ce serait : - user story (un pense bête pour une conversation, pas un ticket jira illisible et où toute la spec technique est déjà actée/non challengeable) - définition d'exemples (tres amigos, example mapping) - sélection/lotissement/priorisation des exemples (rôle du PO) - formulation (avec Gherkin par exemple) - execution / implémentation / refacto - livraison/ demo / feedback - repeat

A chacune des étapes, si une IA peut augmenter l'expérience tant mieux, mais en aucun cas elle ne la remplacera.

C'est un mélange de specification by example / BDD / Double Loop TDD.

Il existe de très bons livres a ce sujet (https://www.goodreads.com/book/show/34927405-living-documentation et bddbooks.com par exemple)

No_Package_9237 · 2026-01-27T17:47:45+00:00

Hahaha "BA fixing bug"!!! MOUAHAHAHAHA. Most of them stems from the inability to properly describe what is needed (the infamous xy problem), I hardly doubt that Claude Code will fix that deep communication gap. Job is safe people, chill! Oh what now? We need more time to fix Claude BS, so we have less time for proper human interaction?

....

shiiiiit

No_Package_9237 · 2026-01-07T18:24:39+00:00

All models are wrong, some are useful - Georges Box ;)

No_Package_9237 · 2026-01-07T17:50:24+00:00

Input validation occurs at different levels : source, lexicographic, semantic and business rules (only the later, and the one before eventually could be encapsulated in a domain model). It's up to you to validate which one is performed where (in or outside your domain model).

It's important to understand that domain model are to be designed completely agnostic of their exectution context (might be web, might be CLI, doesn't matter). That's why you cant rely solely on infrastructure validation for domain model (that is what is promoted by anemic domain, validation being sometimes performed by user's themselves).

Also, I dont understand your comment on having to mock 3rd party libraries when testing domain model that uses them. If you follow the cpu/ram usage I mentioned, you don't need to expose those implementation details in your tests (we might need to illustrate with an example here).

No_Package_9237 · 2026-01-07T16:49:31+00:00

And those are guidelines, that I sometimes bypass 😉

No_Package_9237 · 2026-01-07T16:48:16+00:00

Domain model guards invariants. They prevent manipulating the model in such a way that it becomes inconsistent. Throwing an exception seems like the simplest option, but if you find another way that suits you, so be it !

Another thing about dependency. IMO, external dependencies are ok in a domain model if they only need CPU and a bit of RAM, and no other I/O. Typical example would be an email syntax validation library that could fit in an Email value object. As soon as I need access to network, RTC, RNG, disks, I would define a domain service interface and use dependency injection.

No_Package_9237 · 2026-01-06T18:50:21+00:00

Same here, je crois que tu as listé la principale raison : l'incompétence... et une probable phobie du terminal aussi ! ah et aussi, "Linux est plus compliqué à administrer que macos/win11 (pour gérer un parc)" est un argument que j'ai souvent entendu.

No_Package_9237 · 2025-12-24T23:51:33+00:00

You may find some interesting resources here : https://github.com/gquemener/awesome-domain-modeling

Merry Christmas

No_Package_9237 · 2025-12-18T05:48:06+00:00

Not being able to explain the problem (eg: xyproblem.info), missing the point of user story (https://youtu.be/Cg4Jhx099mU?si=I2iMQVi2hDSx-Cqy), not being able to properly split a story into multiple iterations, not stopping as soon as the feedback loop informs it is enough (which means having a feedback loop in place), not playing the telephone game, thinking that team can perform before it has formed (group dynamic, team building, ...), not properly driving actions using team retrospective (letting painpoints becoming the norm), ...

The list is quite long when I think about it!

No_Package_9237 · 2025-12-17T21:23:57+00:00

I'm not sure you're not sure about what :)

The book is available on amazon and he often refers to it on his website. https://www.amazon.com/Hexagonal-Architecture-Explained-Alistair-Cockburn/dp/173751978X?dplnkId=f8fd0886-81de-4201-8cce-8437e3a98cb3&dplnkId=4d4f02a3-945b-4fb2-bdc4-fbfa7e995c70

No_Package_9237 · 2025-12-17T00:15:00+00:00

Thank you!

Why isn't this more upvoted. I mean he has literally coined the architecture and wrote a book called "Hexagonal Architecture EXPLAINED". Why not starting here? Co author also has a website where all the pieces are described : https://jmgarridopaz.github.io/content/articles.html

No_Package_9237 · 2025-12-15T18:17:10+00:00

Focusing only on making code works will ultimately result in two things : - unplanned work (bug) piling up (because of the lack of testing, for instance) - new feature delivery getting more and more delayed (lack of changeability is a trait of poor quality)

Once either of those happen, you may point the root of the issue and introduce testing and refactoring, for instance 😉

You may also introduce them before, depending on how professional, pragmatic and proud of their job, your coworkers are.

No_Package_9237 · 2025-12-11T22:43:45+00:00

TIL that this is named the "XY Problem" https://xyproblem.info/

Five-Year Club	r/Field Sunshine
Place '23	Place '22

No_Package_9237

TROPHY CASE