Reminds me of a funny story - the first day at Google (2018) I got a chat from an SVP, I forgot who, saying "Hi!". At first I was blown, wow, what a company! SVPs greeting new engineers! A minute later they were like "oops, my bad, wrong person".
They intended to message someone else with my first name, so my guess is they used to type that name and hit tab to start the chat, and that person was no longer the first option in the auto-complete since I joined.
(side note - the most bad-ass response to this would have been to just send back "go/no-hello" ;) )
* When RSS was a thing but in my country a lot of news/content websites hadn't adopted yet, I wrote a service to quickly define scrapers that turn those sites into RSS feeds.
* In one of my former workplaces I wrote (alongside another person) a gamified shared playlist app that allowed everyone to participate in being a DJ for our company hackathon (people getting more upvotes getting more playtime, songs getting many downvoted being skipped in the middle, etc). That was a lot of fun and surprisingly a very emotionally engaging experience for everyone.
Pretty sure the first monitor on my first PC (~1988) was amber, later replaced by black and white that did not "smear" as much so was better for games, and later replaced by a color one (that might have been on a newer PC).
One thing that makes SO an easy target for this is that they let you download all their data and you don't even need to crawl and scrape the content from the website. Just download a dump, put it in an database, slap an HTML template on top of it, splash a few ads, and boom.
I've had this idea for a long time but haven't gotten to actually doing it, to create a physical dashboard for production services using that aesthetic. Controlled by some Raspberry Pi or something, exposing an API, so I can hook it to real dashboard data for my work.
With the API you bridge it to something like Grafana etc, to make the gauges and lights go, and for bonus points have some buttons do things like silence alerts, a big red button to roll back a deployment, and a missile-launch like button with a key you need to turn to deploy to production.
The closest thing I've found on eBay that could be used as a base and was somewhat similar in design, was the control panel of a Soviet tank. But I think it will just have to be made from scratch using bought gauges and buttons.
If you consider all the trade-offs (performance / simplicity / security / etc), and you need to create robust RPC services, whether microservices or outward facing API frontends - Go (to me at least) will be the best choice considering all aspects (C++ may be faster but harder to write/debug in, Java more widely adopted but a nightmare in every other aspect, Python easier but slower and less stable, etc etc).
Think about successful tools use Go - they would have been a nightmare in some aspect in most other languages. Can you imagine Kubernetes in Java? Docker in Python? It shines where it shines for a reason.
In general good "experienced professional programmers" don't have one "tool of choice" but their tool of choice varies by what they're doing. I would choose Go for a lot of things, but not for everything.
I don't disagree, I'm just saying that time drift between nodes is not an issue with this algorithm. Also, using monotonic clock as antirez says he intends to in the post, will take care of most of these scenarios besides VM migration pauses.
yes, that goes back to the first issue in Martin's article, and he mentioned the tokens thing for this. But time drift between the machines is not an issue, is my point.
but the expiration time is relative to the redis server's time, and the time measurement on the client side is done relative to the client's time. Other clients don't care about your clock and you don't care about redis' clock AFAIK. From TFM:
> The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
They intended to message someone else with my first name, so my guess is they used to type that name and hit tab to start the chat, and that person was no longer the first option in the auto-complete since I joined.
(side note - the most bad-ass response to this would have been to just send back "go/no-hello" ;) )