If they can reasonably argue that you're being hired because you sound like Morgan Freeman and you wouldn't get the job otherwise, then they likely have a case.
When you store the time of a future event (like a reminder for 1 year from now), and integer since epoch does not work.
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.
Very good point, which is a reminder that you have different "types" of dates that you may want to store.
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.
I believe that the way we represent information is key to understanding. Data points in a list are usually way less insightful than a good graph (emphasis on good).
What I have found is that it's the case in describing system architecture as well.
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.
A password manager can generate nice passphrases. Really, generating a nice and secure passphrase is no different from a nice and secure password at this point. It's all about entropy and byte mapping.
TL;DR: Not the UML you're taught in school, but check out C4 Model https://c4model.com/
--
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.
Actually, if what you are looking for is "to the point" reviews, then you should agree with the article's advices. To name a few:
- 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.
I'd like to believe that one of the reasons Linus has that kind of reaction is because of the scope and impact his decisions and this kind of patches can have on people all around the world. This is a very specific situation, in which the advices in Sandya's article may not apply.
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.
Great work! it brings back so many memories =)
I was trying it in Chrome on iOS and it seems that it considers each color square as a text entry, kinda annoying