> My previous job was doing microservices for frontend and current job is doing monorepos. I prefer monorepo for frontend because:
I think you're misusing the term "monorepo", no? Monorepo is just a technique for organizing source control repositories. It's possible to have microservices AND monorepos.
This is weird, I had Zoom installed a long time ago but uninstalled according to their instructions [1]. I'm a macOS user.
As soon as I clicked that link, the client downloaded a PKG file, installed itself and launched itself without asking me if I wanted to share my camera or audio.
I uninstalled according to their instructions again, searched for all "zoom" files in my disk and rebooted.
This leads me to believe that following their uninstall instructions is insufficient, and there are hidden files left on my computer.
> After a year or so of trial and error, we have pretty much stopped using reduce
I see Reduce (along with recursion itself) as the equivalent of a "low-level" construct in functional programming.
It is a great building block for other functions like sum/product, and even those demonstrated in the article, but not something that programmers should be using everyday.
I think it's very appropriate to have a rule to only use reduce (and recursion too!) inside "utility" libraries.
IME the thing that matters the most is focus, both on the micro and macro level. It's way too easy to get caught on things that won't make an iota of difference in your future. Focus is the first thing that goes out the window as soon a a company reach just a bit of momentum.
I've seen several startups suffering from not being able to decide what they were. Engineering teams fractured because the company wanted half of them working on their bottom line and the other half working in some offshoot product.
Even gigantic companies need that: notice how people criticize Google for creating and killing way too many products, and at the same time praising their minimalist webpage (since 1998), early GMail, etc. Same with Apple when Jobs returned to Apple and streamlined their product line, etc.
> Don't invite someone and when they arrive tell them they are not welcome to speak. Post a list of speakers before, get your feedback and live with your decisions.
The speaker was notified in April 25. The conference will happen in mid-June. She was given fair warning.
> It does not really seem that he tried to talk to the person whose talk was cancelled (and who had probably already bought plane tickets, etc).
You missed that as well. He and another person of his group reached out to her beforehand. Here's the part in the article that says so:
> Therefore, on April 25, 2019, I, along with an employee of my company, communicated to her our decision in a meeting held in a place of her choice. She took it badly.
The conference will happen next June.
--
> Whatever, it is a bit absurd to have an opinion on this question without information from both sides.
The people who were denied were the ones who came forward and they never addressed nothing of the sort. They only engaged in doxxing, harassment of other speakers and false accusations.
This is not a proportional response.
All that happened in public. If you need info, just ask instead of assuming.
I watched this unfold on Twitter, and you're misrepresenting the situation.
The people removed from the conference have a history of disruption and harassment in the community. They were removed because of previous behavior that the organizer was not aware beforehand. He relied on the testimony of people he trust.
--
> Being able to deal with people that make you very uncomfortable without creating a fuss is a fundamental requirement of adulthood
The only people who engaged in "creating a fuss" were the speaker and a third-party related to her. They decided to come forward and "out" themselves. Up to that point, everything had been handled in private. There was no need to involve other people such as the organizer's girlfriend or other speakers.
--
> It is exactly the same behavior.
The organizer denied a speaking position and did so in private, without incurring any shame or denying participation in general.
The speaker and a third party started a campaign of doxxing, harassment and, as other commented put it: "public shaming using false allegations of stalking and harassment".
There's a world of difference between those two behaviors.
I watched this unfold on twitter, and in the organizer's defense, he only addressed the situation and the culprits after those people started a public discussion regarding the ban. The organizer was defending himself.
I think you have answered your own question: it's one less thing to worry about in your stack.
If you're targeting modern evergreen browsers you already have a lot of modern features at your disposal, including ES6 modules, async/await, string interpolation, but we're not using them.
In fact, I'd say that it's way more than "one thing" that you can stop worrying about: you won't need Webpack/Rollup/etc, Babel, NPM/Yarn, Node.js itself, etc.
This is similar to Brazilian banks too. Both public and private.
They stoped using ActiveX in the 00s but then started requiring the user to install some rootkit-like security software that was nearly impossible to uninstall and was probably able to spy on users.
Now they some of them have an app that is basically a bundled browser accessing their regular website.