Repeatable Execution - Mark Seemann - NDC Copenhagen 2022

Подписаться 195 тыс.

Просмотров 8 тыс.

50% 1

What should applications log? Much enterprise code has logging code liberally sprinkled over it. Often, too much. Programmers log lots of things out of fear of not being able to troubleshoot problems that might occur in production. Even if you log a lot, however, how do you know that you haven’t missed a piece of crucial information?
In this talk, I’ll discuss a formal method for deciding what to log, and what you don’t need to log. Learning from functional programming, distinguishing between pure and impure code holds the key to such decisions. Examples will be mainly in C#, with some Haskell as well. No knowledge of Haskell is necessary.
Check out more of our featured speakers and talks at
www.ndcconferences.com
ndccopenhagen.com/

Наука

Опубликовано:

18 авг 2022

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 8

@xybersurfer Год назад

very interesting! the only problem i can see is that the amount of impure data that needs to be logged, can become quite large when dealing with a database especially. i guess you have to limit testing to your own system as usual. it's good that Mark pointed out that he doesn't normally create that replay machinery, because i was already thinking it would be unproductive

@Endomorphism Год назад

Mark! Great talk as always

@djchrisi Год назад

16:14 . No, this is not deterministic. Since the method is not provided with a specific IFormatProvider object it will use the current culture and god knows what this is been set to.

@torstenmohrin2207 Год назад

CurrentCulture is one of the worst global variables in .NET.

@mackie1001 Год назад

Good spot! Establishing if something is pure or not in .Net requires pretty deep understanding of what you're looking at. Maybe a good rule of thumb is "look at all the overloads and be as specific as possible"

@MarkSeemann Год назад

Indeed, the CurrentCulture makes DateTime.TryParse subtly non-deterministic. It's not that I'm not aware of this issue, but I chose to gloss over that subtlety for didactic reasons. I sometimes simplify for educational reasons, but I try to do it only to a degree where the detail is largely irrelevant. The fix for this issue is to use an overload that specifically states which IFormatProvider to use, or to use TryParseExact. This makes the code look more complicated, but otherwise doesn't change the overall message of the talk. That's the reason I decided to pretend that the simpler code is deterministic. This may have been the wrong decision. Putting together a talk is an art, not a science.