revvx

"Multirepo" is the term I see the most

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.

You're probably thinking of "monolith".

https://en.wikipedia.org/wiki/Monorepo

Nope. Not even for safe (image, music, etc) files.

And even if I had, PKG files don't install themselves on macOS, they open the installer interface, AFAIK.

EDIT: And, as I mentioned, the file was downloaded by some Zoom client, not by my browser.

I think I found out: there's a daemon process that I somehow missed the first time around.

Deleting the .app file as instructed is not enough.

This StackExchange reply [1] showed me how to solve it, at least on macOS.

[1] https://apple.stackexchange.com/questions/358651/unable-to-c...

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.

Sorry in advance for the off topic message

[1] https://support.zoom.us/hc/en-us/articles/201362983-How-to-u...

Avoiding the use of reduce/fold is a good thing even in teams with more experience in functional programming.

The problem is not reduce itself, it's the code that uses it.

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.

For instance, Safari doesn't allow localstorage while in incognito

It does allow (at least in the version I'm using), but doesn't persist the data between sessions. Which is the whole point of Icognito mode.

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.

The conference organizer denied a speaker position in a conference. All that happened in private.

The person and a third-party engaged (allegedly) in doxxing and public shaming.

Even if the conference organizer was in the wrong, there's a world of difference between those two things.

I watched this unfold on Twitter, and it was a third-party related to the woman that decided to "out" themselves.

It's not an easy position for a conference organizer to be in.

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.

It's a difficult situation to be in.

The answer here confirms what you said: http://answers.google.com/answers/threadview?id=500807

Probably because 2003 requires Flash!

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.

After checking the archived content on [1], as posted by Updtrenda, it seems that it was just a bunch of HTML files indeed.

If this is really the case, I don't see why they can't just put it on a Torrent and distribute it. Or even host a mirror on S3 or Netlify.

[1] http://web.archive.org/web/*/http://kaiserpapers.org/*

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.

For those curious about how the website looked before the removal, here's a Web Archive link:

http://web.archive.org/web/20181122020124/https://kaiserpape...

The parent asked about Low End Stock, not about Netlify

IME: It really depends. It's not a silver bullet, you HAVE to measure and calculate [1]. The pricing is transparent, so it's more predictable.

My experience with single-function lambdas in JS was very positive, because they're quick to run and don't consume too much memory. They're also quicker to write and to publish, IMO. Some apps are virtually free to run.

Bloated-but-low-traffic enterprise apps are also a good fit, because the low traffic offsets the memory/execution time. I think Microsoft is in a great position here, because of Azure.

Customer facing app using an MVC framework? No way. Even Heroku can be 100x to 1000x cheaper.

[1] Here's a calculator: http://serverlesscalc.com

The "write-raw-SQL-with-raw-strings" approach has one serious issue -- sql-injections.

Nobody has advocated writing "raw SQL with raw strings" in years.

The valid way of using Raw SQL is using prepared statements and parametrized queries.

This method will protect you from SQL injection, will handle most issues with type/conversions and the queries are cacheable, so it's fast too.

Parametrization is handled by the database itself (not the specific driver), so it is battle tested.

https://stackoverflow.com/questions/8263371/how-can-prepared...

Dapper is similar and it got some traction in the .NET community.

https://github.com/StackExchange/Dapper

For example, manual memory management is a detail that should almost always be someplace else because it isn't relevant to solving the problem at hand. So we did this with garbage collectors. However, sometimes we need this detail present (high performance computing and/or constrained hardware ie video games etc).

That's a great example.

IMO looping is another case: I think it is clearer to use constructs like map/filter/group/sum/reduce instead of for/while/break/continue/etc. You only really need the procedural ones in hot-paths and such.

Concurrency too: in Javascript you had to nest callbacks and promises, and they were also "too noisy". Async/await helps you keep your code more readable. I think Fibers in Ruby (and other languages) were a good idea too.

-

If you push too many things together that do not belong together, then you end up with code that is hard to comprehend.

That sums it up nicely.

Cross-cutting concerns should be abstracted (but not hidden), as they don't belong together.

All IMO:

However, I've never seen a convincing and objective description of clear code.

I take "clever code" to mean "code that looks pretty on surface the but requires the reader to dig in in order to understand the intent".

The problem with clever code is that it is misleading. It lacks empathy. You assume the next programmer will understand it at first glance just because it looks cool or pretty, but they'll struggle to parse it.

---

Sometimes people mean that clear code is verbose code.

I also consider some verbose code to be "clever code" too. Most of the time it is just people using hammers where screwdrivers would be more appropriate:

- Unnecessary structures - eg: classes that could be functions taking 2x or 3x more space

- Unnecessary usage of polymorphism - eg: inheritance chain that could be a simple if

- Excessive indirection - eg: layered code where most of the time the layers don't do anything

- Plain wrong abstractions - eg: using query builders to build queries that would be smaller and more readable in SQL

- Fear of making classes too big - eg: instead of adding a method to a class, making a second class that knows too much about the innards of the first one

- Procedural code disguised as OOP - eg: breaking up a method into multiple private ones, but ending up having a lot of instance variables that were local variables before. When everything could be a single function.

---

The best we have is cyclomatic complexity, but there's some reason to believe that line count may be a better indicator (which can't be good). And cyclomatic complexity completely misses the effect of mutable or immutable state, the presence of bad APIs, poor variable naming, etc.

Great observations. I agree 100%.

Since you mentioned it, I find cyclomatic complexity a bit too easy to game. I always wanted to have a metric that prevented people doing that, and took multiple methods into account.

When you break a method in three or four without adding REAL abstractions (a.k.a. "things you don't have to follow with the debugger to understand"), you're not making it easier to read, in fact you're making it harder because the reader has to jump around your code.

Of course, it's harder for machines to know the difference between good and bad abstractions. But I think we should take that into account in code reviews and such.

I agree 100%.

In my experience, loops and recursion are lower level constructs that should ideally be used only in libraries (map, filter, limit, sum, distinct, etc [1]) and in hot code paths (for optimization).

Kevlin Henney makes a good observation on one of his talks about how "you have written all the loops you will never need in your life" [2], and those are constructs such as map/filterand friends, present in LINQ, Java Streams, Ruby Enumerables, etc.

His argument is that code made with those primitive is clearer than code made than procedural loops, because when you read it you don't have to "execute the code in your head".

I'd argue that using procedural loops is what's actually "too clever" here, despite being more verbose!

-

[1] I have mixed feelings about "Reduce". It is hard to use and, most of the time, hard to read as well. It's too low-level.

[2] https://youtu.be/APUCMSPiNh4?t=3317

Yeah. I always see the De Morgan's Law being used to make the code look prettier or look less complicated.

I'd say it's objectively prettier most of the time, but unfortunately that's exactly what introduces double negatives or other ambiguous stuff and makes the code more confusing.

It's a nice refactoring step, though: apply it, extract the condition into a well-named variable and test that condition.

If you trust your automation, you put private key rotation into it.

If you don't trust it your automation, you rotate the keys manually, as you would normally.

There are no valid reasons to throw the baby away with the bathwater.