ewi_
Does Noise Protocol provide what you're looking for? http://www.noiseprotocol.org/
Your event is initially in the user's timezone (e.g. 10am 20th of June 2024 in France), if you store it as a number then you are fixing the exact second at which it will happen. However, if the timezone in question has some changes you didn't anticipate (new law voted, no more summer time), then you will either be triggering your event 1h before (e.g. 9am instead of 10am) which is probably not what your user wanted, or you'll have to recompute all your timestamps to take that change into account.
Instead, you could store rhe event with the target timezone, and let your datetime library that is up to date figure out next year.
Went storing the time at which an event happened (e.g. for a system log) then a UTC or UNIX time works, and it will be transformed at display time depending on the user's timezone.
When storing a future time at which to do something, it should be stored with its target timezone so you can always make sure it happens at the right moment. For this iso datetime representation makes a lot of sense.
That's most of the article. If you're asking yourself that, you should read it
As you say, you can describe a system in a few paragraphs, explaining the relationship between the main components. However, as paragraphs it can harder to grok, and also harder to write with no ambiguity.
Now, part of what I say above can be seen as personal preference (text vs image), but in practice I have found that when using tools like plantuml or mermaid to make C4 diagrams, the result is easier to use, remember, and update than plaintext.
--
Pure UML is pretty rare in my experience, and most likely used only in very strict environment that don't change often (security, airplanes,...).
UML concepts and diagrams however are extremely useful to collaborate on complex systems or flows. However people don't tend to make good diagrams, unless they're very restrictive. I find that sequence diagrams are usually the ones with the best quality out there because you have to adhere to a strict (and rather simple) représentation.
For things that are not flows-like I would recommend using the C4 Model https://c4model.com/ :
- It provides a simple and constrained way to describe systems and their interactions.
- The first two levels are the most useful IMO as they provide a lot of information, while being rather static over time. Level 3 and 4 typically require frequent changes as your code evolves.
> > pattern matching
> We have that in Python 3.10.
> > immutability-by-default for lists and dictionaries
> We do have tuples and frozendict.
3.10 like the version that is not released yet?
Tuples an frozendicts, so precisely non default list and dicts?
"If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity."
- Pointing to a common reference instead of simply stating your opinion in a review will get the improvement you want done faster
- Writing a single comment for a repeated error is faster to do for the reviewer
- Explicit communication instead of emojis and sarcastic comments will bypass the need for further explanation, which will make the whole process faster
Finally, you seem to take issue with only a few of the author's points ('some of these rules go beyond a reasonable "don't be an asshole" line'), could you explain which ones and why? I am interested to know what exactly makes the process too taxing for you.
However, I fail to see how Sandya's observations are BS. A code review is a place to improve code and oneself, and there's a pretty large distinction between constructive criticism and sarcastic/aggressive comments. Being respectful/mindful of your colleague in that situation is in my opinion the minimal requirement.