it's thread safe on operations on the dict but not on the values. Same relates to other immutable structures like tuples. Lock will not help here cause unsafety comes from operation on value after value is obtained.
I'm against easter eggs, at least right now. First of all not of them are harmless, can you make sure that it wouldn't break anything important, would it tolerate race, religion, gender and after all of these would it remain fun? It's hard to be responsible and fun in the same time.
Well… I find your conclusion a bit sad, and turned upside down. Instead of banning all things fun for fear of misstepping, maybe it’s time to take things less personally, be more tolerant towards others, and push for positive change instead of trying to punish others for not being ”aware“ enough?
I'm not trying to punish others, I just don't find it fun anymore with all respect to everyone who keeps up. Before it was naïve and simple, right now it just more complicated, often looks commercialized or not appropriate.
I didn’t mean to imply you personally aim to punish others, but that we should collectively strive to foster a culture of positivity rather than instilling fear of offending others, until people say nothing at all anymore (or say a lot that doesn’t mean anything).
Why on Earth would jokes have to "tolerate" race, religion and gender or anything else? The point of (some) jokes is to challenge anything and everything you deem to be a norm.
I'm starting to think that many tolerance-preaching people are the most intolerant bunch by far.
Well, my 2-cent is that you can laugth of everything but not with everybody... So defying the norms with Easter Eggs sent to the wild can be an issue. You have to know your audience to properly chose your level of impertinence.
I completely agree with the first sentence - however I would argue that normal, level-headed and sane person either laughs or just shrugs and moves on if that particular joke is not to their taste.
Is the Google "Minecraft" easter egg intolerant of gender?
Easter eggs can certainly be problematic when used in APIs (or similar) where access is intended to be automated (and therefore vulnerable to surprises).
But in user facing code, easter eggs are perfectly fine.
I'm sure some companies use easter eggs as marketing/recruiting tools.
That said, I've put a small number of user-facing easter eggs in publicly-traded MegaCorp code before. In every case, it was an inside joke among devs that the higher-ups never knew about it. The C-Suite is uptight and we definitely would have been reprimanded if they were aware.
I don't say it's bad. It's commercialized experiense and it's cool if you love it. I just wouldn't treat it the same as devs fun of hiding things for valuable user who loves their product and I'm talking from dev prospective, not user.
This will never happen. No matter what you think, sending you reject email is opening can of worms with no benefits for the company. You can start arguing, wasting their time and resources and one day all these emails can go public with harm to their reputation.
I have received many refusal emails for job applications ranging from "Unfortunately, we have filled that position" to "Following your interview, we have selected another applicant, but we'll keep your resume" to "We do not have an open position currently, but we may contact you later". I really don't see how these answers could harm these companies. Some of them actually incited me to followup a couple years later, and land a job.
On the other hand, the rude option of not answering harms the company's HR brand.
Moreover, candidates might prefer bland non-responses that demonstrate more savoir faire than explaining, honestly but stupidly, the reasons of a rejection.
The talent pool is not infinite, and a rejection means "we don't have a vacancy for which you are the right candidate right now", not necessarily "No way will you ever work for this company". So the core benefit of treating rejected applicants fairly, and perhaps providing them conditions under which they can re-apply ("We won't accept further applications from you in the next year, but we'd encourage you to re-apply for a suitable role after then"), and some things to work on before they could be successful in the company, then they might be an asset for the company in the future.
Likewise, companies which have a reputation for providing feedback and a polite thanks but no thanks are more likely to get applications than companies that have a reputation for ghosting.
> You can start arguing
Just have a rule that all communications with the candidate go through HR (or the person responsible for coordinating hiring overall in a smaller company), and then if they reply at all to candidates arguing, just have them be firm that under policy, the decision has been made, and can't be reviewed. It's okay to ignore further correspondence if they argue.
> these emails can go public with harm to their reputation
What's worse though, a reputation for ghosting candidates, or a reputation for privately sending transparent but polite feedback based on the interviews?
When I was trying to apply for jobs, I got two replies of any kind out of the over a hundred applications I sent out. One of them got to a pre-interview stage before rejecting me, with reasons. I currently work at the other place. How many people contest their job rejection emails when they get to a pre-interview stage or later? How many would contest them if they were immediately rejected?
I think there’s some selection bias: your experience is of being a normal person where you think ‘I and the people like me are not like that’ but in the set of people that a company rejects, a higher percentage will be eg people who apply to and get rejected from a lot of jobs (and are therefore still applying to more) and so they may behave differently. I don’t really believe the thing about opening a can of worms though. My guess is more that there isn’t much upside to doing this, and companies maybe want to ‘leave doors open’ sometimes by eg not responding in case the person they’re hoping to hire turns them down and they need to interview more candidates again.
> in the set of people that a company rejects, a higher percentage will be eg people who apply to and get rejected from a lot of jobs (and are therefore still applying to more) and so they may behave differently.
We send rejections. I haven't heard of any complaints or arguments ever
I also once offered someone to privately help them make the career switch they were trying to make but were clearly not ready for (I didn't word it like that to them). The applicant reminded me of someone in school who wasn't the technical best performer but always kept high spirits while working hard (within reason, nothing extreme, but it set a good example for... you know how most kids in group work usually perform) and they just needed a little bit of help to be a great teammate. Never heard back from that applicant :(
This is all for an IT position in Germany (though remote work in adjacent timezones is fine and more than half our employees aren't German currently; we basically hire anyone qualified who applies), perhaps it's different if you hire for different types of jobs or in other cultures
We had a case when some dude was arguing against our location requirements. The listing said "the EU" and he was from Armenia or thereabouts and kept sending long emails saying that our requirement was wrong, that we should consider people from elsewhere, how good it will be for the company, etc. It was really bizarre, because he did all that before applying.
So, yeah, a can of worms. They are rare, but they sure are pungent.
Just ignore replies, especially when they're argumentative or rude. It's not a hard problem to solve.
Not sending a simple "sorry, we're proceeding with other candidates" is detrimental to everyone, because without knowing if you've been rejected or not you're just incentivised to send out more applications, which doesn't really benefit anyone, including companies who will now have even more applications to sift through.
Also I've had companies ghost me after doing several what seemed like promising interviews. It's okay they decided to pick someone else, but outright ignoring at this stage is just being a dick. "Begone peasant, you're not even worth talking to".
If they don't have this courtesy, should they expect anything from the candidates in various parts of the process? Like maybe the offer was not good enough. So is it reasonable for candidate to just totally stop communicating?
It does happen considerably more than "never"... happened plenty of times for me! They generally won't accept risk and make a dialogue about it, getting into details like 'why'... keeping it high-level informative.
I've also had places keep it ambiguous and send an offer nearly a year after interviewing. Game theory applies, as always.
This is the exact kind of "treating people like shit" even before they start working that feed quiet quitting and the sentiment for employees (a word banned in the corporate lingo of my country, we are "collaborators") that jobs and companies are totally disposable too.
I had only one problem, all certificates were outdated, so all https resources didn't work (like 99% of web). I had to download certificate updates to flash drive on another PC to install them, then all worked fine, I used outdated Firefox but it still good.
How is this different from GET arguments in the URL? I mean is this relates only to URL fragment, because javascript can parse URL parameters as well and any spam site can abuse it even with rewrite in the path part in the URL.
GET arguments are not redirected to the spam site because when the url redirection site has received the GET argument, the GET argument would generally be discarded/disregarded before redirecting the user to the spam site.
But you're not in control of fragment part. Server doesn't receive fragment for request, it's all managed completely by the browser. To handle this you need to do client side redirect with javascript.
So my idea would be getting looo.ong to create a special client-side redirection webpage that would remove the fragment part using Javascript before performing the redirection with Javascript. And no. Using HTTP redirection response on server side won't work.
EDIT: I've actually seen URL redirection websites that removes the fragment part so it should be doable. Perhaps the purpose of that is to avoid spam abuse.
thanks to the need for ES to accommodate SPA (one of the worse thing that has ever happens to the web), that allows ES/JS to change the URL of the page as long as it is within the same domain. What could go wrong. Don't try to make web a QT replacement. Crete your own freaking interface. Stop hijacking web as document based platform to squeeze everything in there.
Clickbait. "The toxicity and health effects of brake wear particles are largely unknown". Is there any real harm found? What's the concentration of them close to the dangerous road? What's effect of them comparing to pm10 or pm2.5?
Well I meant other particles treated in the regular study of them. Because effect of pm10 and pm2.5 is studied. Do break pad particles somehow worse than usual.
Do you really need an independent peer-reviewed study to know if inhaling brake dust is bad for you or not?
At some point, it's important to trust your instincts. I don't think you need a medical degree to understand that inhaling tiny particles made of nasty stuff leads to bad health outcomes.
Instincts often cheat you. I'm not saying that it's healthy but Does it really have any effect at all? What's the concentration of particles? How harful is it comparing to cooking or peeling onions? Do we need to care about it at all?
It is the opposite. Amazon would have released MongoDB as a service, same as they do for PostgreSQL or MySQL. As MongoDB changed license they implemented DocumentDB instead.
Note AWS significantly contributes to PostgreSQL and MySQL communities (though you could always want even more) but of course does not to MongoDB. While this is fine for MongoDB Inc I think it is not great for MongoDB community at large
SQS has eventual consistency, you can get the same message twice on 2 different intances for example (which was often the case for my projects). I would rather suggest Amazon MQ.
This is often possible to work around by adding a UUID to the message, on the sender side. Then either handle dupes at the DB level by ignoring duplicate inserts, or using something like redis. In practice, even with other queue systems, you can wind up with dupes due to bugs, timeouts, retries, like duplicate sends when the first one actually went through but wasn't acknowledged. I worked on systems sending thousands of messages/second through rabbitmq, originating from various third parties, and dupes would happen often enough that we needed to work around it on the receiving "worker" side.
SQS is weird in that you can get the same message in Japan and Germany at the exact same time and "race" to process the message. It's annoying af. I do not recommend SQS unless you are at some kind of scale (in company/team size, not revenue) where you can deal with it properly.
I used extensively at a previous company for longer running background tasks. It was simpler to use SQS than dealing with standing up our own RabbitMQ cluster. Their Amazon MQ service did not exist at the time. Our system was built to tolerate duplicates and it worked well enough. For something higher volume I'd definitely use RabbitMQ though.
A cluster! Yeah, if you have enough messages warranting a cluster, SQS might be simpler (but probably far more expensive). It's always tradeoffs I guess.
